MXPA01001822A - Logico transportable para facilitar una red de transaccion de tarjetas de llamada grande que soporta cambios dinamicos. - Google Patents

Logico transportable para facilitar una red de transaccion de tarjetas de llamada grande que soporta cambios dinamicos.

Info

Publication number
MXPA01001822A
MXPA01001822A MXPA01001822A MXPA01001822A MXPA01001822A MX PA01001822 A MXPA01001822 A MX PA01001822A MX PA01001822 A MXPA01001822 A MX PA01001822A MX PA01001822 A MXPA01001822 A MX PA01001822A MX PA01001822 A MXPA01001822 A MX PA01001822A
Authority
MX
Mexico
Prior art keywords
transaction network
dynamic transaction
network according
dynamic
database
Prior art date
Application number
MXPA01001822A
Other languages
English (en)
Inventor
Robert F Penfield
Original Assignee
Priority Call Man Inc
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 Priority Call Man Inc filed Critical Priority Call Man Inc
Publication of MXPA01001822A publication Critical patent/MXPA01001822A/es

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/305—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wired telephone networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/342—Cards defining paid or billed services or quantities
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/02—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices
    • G07F7/025—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices by means, e.g. cards, providing billing information at the time of purchase, e.g. identification of seller or purchaser, quantity of goods delivered or to be delivered
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1305—Software aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13095—PIN / Access code, authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13103—Memory
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1313—Metering, billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13176—Common channel signaling, CCS7
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13204—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13345—Intelligent networks, SCP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13349—Network management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389—LAN, internet
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • Y10S707/99953—Recoverability

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Telephonic Communication Services (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Se describe una red de transacciones dinamica que tiene una estacion de administracion (o estacion de manejo), una terminal y una base de datos. En respuesta a una peticion de transaccion de un llamador, la terminal hace acceso a la informacion almacenada en la base de datos via el logico transportable. El logico transportable deriva la ubicacion de informacion relevante en el arreglo de base de datos a partir de una (s) caracteristica (s) de entrada de la peticion de transaccion. El logico transportable almacenado en la terminal es actualizado con el logico transportable almacenado en la estacion de administracion si la terminal determina que hay una diferencia entre su logico transportable y el logico transportable de la estacion de administracion. Algunas diferencias pueden incluir un cambio en el numero de bases de datos en la red, un cambio en el numero de terminales en la red o un cambio en la ubicacion de la informacion almacenada en la base de datos.

Description

LÓGICO TRANSPORTABLE PARA FACILITAR UNA RED DE TRANSACCIÓN DE TARJETAS DE LLAMADA GRANDE QUE SOPORTA CAMBIOS DINÁMICOS CAMPO DE LA INVENCIÓN La presente invención es concerniente en general con el campo del procesamiento de transacciones electrónicas y más especificamente con el campo del procesamiento de transacciones en tiempo real para cuentas de tarjeta de llamada prepagadas.
ANTECEDENTES DE LA INVENCIÓN Las redes de procesamiento de transacciones en tiempo real consisten en general de dos componentes principales: terminales de entrada de transacciones (tales como clientes en una red de computadoras de cliente servidor) y bases de datos de manejo de transacciones (servidores) . Las redes de transacción utilizan diferentes clases de terminales y bases de datos para industrias diferentes, tales como bancos y telecomunicaciones. Sin embargo, a diferencia de los sistemas financieros mundiales, no se han adoptado estándares industriales para la inter-operabilidad en la industria de tarjetas de llamada. Las redes de transacciones de tarjetas de llamada disponibles utilizan teléfonos conectados a sistemas de procesamiento de voz tales como terminales, en donde el sistema de procesamiento de voz pide un número de cuenta o Ref: 127544 número de identificación personal (PIN) (con una contraseña opcional) . Bases de datos grandes para el manejo de transacciones son usadas para validar la cuenta e impedir el uso simultáneo. Comúnmente, los PIN o números de cuenta son ya sea asignados aleatoriamente o son recogidos por el consumidor. Frecuentemente, el número de PIN contiene alguna porción de un número telefónico existente. Sin embargo, puesto que no hay ningún estándar aceptado ampliamente para asignar números de cuenta y de PIN, la integración de varias redes de tarjetas de llamada para asignar números de cuenta y de PIN, integrar varias redes de tarjeta de llamada para inter-operar ha probado ser extremadamente difícil para la industria de telecomunicaciones. Con el advenimiento de los servicios de tarjetas de llamada telefónicas prepagadas, se han adoptado los servidores de base de datos para manejar un balance activo, con provisiones para impedir acumular un balance negativo. Puesto que los pagarés prepagados son vendidos comúnmente en los almacenes de venta al menudeo y luego desechados, el número de cuentas activas puede ser de cientos de millones. Por consiguiente los requerimientos del manejo y procesamiento de datos, extremadamente grandes, en tiempo real, proporcionan una preocupación adicional para el mercado prepagado. Debido a las limitaciones de la tecnología de base de datos, muy frecuentemente se requieren múltiples bases de datos para manejar el volumen de transacción, conduciendo a problemas de inter-operabilidad y exactitud de_ datos. Por consiguiente, hay necesidad de expansión de la tecnología de base de datos disponible para acomodar el crecimiento del volumen de transacción y datos en las industrias de tarjetas de llamadas e industrias relacionadas. La presente invención está dirigida a tratar las desventajas de las capacidades de procesamiento de transacciones disponibles para redes de tarjetas de llamada prepagadas (PPCC) , pero es aplicable a todas las redes de procesamiento de transacciones. Dos desventajas particulares de las redes de PPCC disponibles tratadas por la presente invención incluyen: (1) la capacidad de las terminales para determinar y ponerse en contacto con un servidor de base de datos para la autorización/débito/crédito de una cuenta especifica no es fácilmente alterada o actualizada y (2) la capacidad de las terminales para tener conocimiento de y ponerse en contacto con nuevos servidores de base de datos para expansión no es cambiada fácilmente. Esta segunda desventaja se deriva de dos características particulares de los sistemas de procesamiento de transacciones disponibles; en primer lugar, la carencia de redistribución dinámica de los datos de cuenta existentes crea la necesidad de tiempo de paralización y en segundo lugar, se requiere un conocimiento de especificidades (esquemas) de bases de datos para interactuar con cada base de datos. En tanto que las cuestiones anteriores son problemáticas para todas las redes de procesamiento de transacciones tradicionales, son especialmente difíciles de superar en las redes de PPCC debido a los aspectos de tiempo real de los requerimientos de manejo de balances. Asi, es casi imposible reestructurar una base de datos de PPCC fuera de linea y luego post-transacciones para actualizar a tiempo real como es la práctica en las situaciones de contabilidad financieras "post-pagadas" o de herencia.
Glosario Las siguientes definiciones y siglas ayudarán al lector a comprender la descripción adjunta de la presente invención . DTL Lógico Transportable Dinámico; IE Elemento de Información; IEC Colección de Elementos de Información; IP Protocolo de Internet; SS7 Sistema de Señalización Siete; OLTP Procesamiento de Transacciones en Linea; Fragmento Una "sub-sección" de una base de datos; Huésped Un solo elemento de cómputo; GrupoUn grupo de elementos de cómputo; Red Un grupo de grupos que comprende toda una red de operación.
BREVE DESCRIPCIÓN DE LA INVENCIÓN Para tratar las desventajas de la técnica previa, la presente invención proporciona una red de transacción dinámica que tiene una estación de manejo, una terminal y una base de datos. En respuesta a una petición de transacción de un llamador, la terminal accesa a información almacenada en la base de datos via un lógico transportable. El lógico transportable deriva la ubicación de información relevante en el arreglo de base de datos a partir de una(s) característica (s) introducida (s) de la petición de transacción. El lógico transportable almacenado en la terminal es actualizado con lógico transportable almacenado en la estación de manejo si la terminal determina que hay una diferencia entre su lógico transportable y el lógico transportable de la estación de manejo. Algunas diferencias pueden incluir un cambio en el número de bases de datos en la red, un cambio en el número de terminales en la red o un cambio en la ubicación de la información almacenada en la base de datos. Una primera ventaja de la presente invención es la distribución del lógico transportable ("DTL") , que permite que el equipo de terminal se ponga en contacto con un arreglo grande, distribuido y heterogéneo de servidores de datos, utilizando solamente información disponible en una terminal. Otra ventaja de la presente invención es la provisión de un mecanismo para actualizar el DTL de tal manera que la topología de una red de transacción puede cambiar "en el vuelo" de una manera basada solamente en información disponible en la terminal. Todavía otras ventajas de la presente invención incluyen: la provisión de múltiples tipos de DTL, de una manera basada en un aspecto físico de la terminal en tal (tal como el departamento en donde está la terminal o el número telefónico marcado en la terminal); la capacidad de agregar nuevos servidores de base de datos a una red en tiempo real; la capacidad de obtener direcciones y capacidades de todos los servidores , de datos disponibles para transacciones, de tal manera que cada terminal puede interactuar en redes seguras; la provisión de mecanismos de seguridad integrados para permitir transacciones de red públicas; por medio del uso de DTL y procesamiento distribuido, la capacidad de integrar redes de transacción muy grandes con desempeño escalable que cumplirán con cualesquier requerimientos de red de transacción; utilización de tecnología de transporte abierta para asegurar la modificación de la tecnología de red para soportar por lo menos redes de IP y de SS7; utilización de datos del Elemento de Información ("IE") para proporcionar almacenamiento de datos dentro de cualquier arquitectura de cómputo; utilización de Colecciones de Elementos de Información (IEC) para permitir que múltiples versiones de elementos de programación de la terminal compartan una instalación de almacenamiento de datos común; la provisión de un mecanismo para fragmentar bases de datos en un número muy grande de fragmentos lógicos que, tomados conjuntamente, representan fragmentos físicos. Una ventaja adicional de la presente invención incluye una red de transacción dinámica que tiene una estación de manejo que contiene lógico transportable (lógico de prisma) que facilita el acceso a la red de transacción dinámica, una base de datos conectada a la estación de manejo a través de un medio de comunicaciones, la base de datos tiene por lo menos un fragmento de base de datos almacenado en la misma y una terminal conectada a la estación de manejo a través del medio de comunicaciones, la terminal que recibe el lógico transportable de la estación de manejo después de la inicialización (ajuste a valores iniciales) de la red de transacción dinámica, la terminal que hace acceso al fragmento de base de datos vía el lógico transportable en respuesta a una petición de transacción de un usuario. Todavía una ventaja adicional de la presente invención incluye una red de transacción dinámica que tiene una estación de manejo que contiene datos de configuración del sistema que definen la red de transacción dinámica y Lógico Transportable Dinámico (DTL) que facilita el acceso a la red de transacción dinámica, una base de datos conectada a la estación de manejo a través de un medio de comunicaciones, la base de datos tiene por lo menos un fragmento de base de datos almacenado en la misma y una terminal conectada a la estación de manejo a través del medio de comunicaciones, la terminal que recibe los datos de configuración del sistema y el DTL de la estación de manejo, después del ajuste a valores iniciales de la red de transacción dinámica, la terminal que hace acceso al fragmento de base de datos vía el DTL en respuesta a una petición de transacción de un usuario.
BREVE DESCRIPCIÓN DE LOS DIBUJOS Las ventajas mencionadas anteriormente de la presente invención, también como ventajas adicionales de la misma, se comprenderán más claramente como resultado de una descripción detallada de una modalidad preferida de la invención, cuando se tome en conjunción con los siguientes dibujos en los cuales: La figura 1 es una vista esquemática de la red de transacción dinámica de la presente invención. La figura 2 es un diagrama de flujo que ilustra un método de configuración para un SCP de la presente invención.
La figura 3 es un diagrama de flujo que ilustra un método de configuración de un SSP de la presente invención. La figura 4 es un diagrama de flujo de un método para agregar un nuevo SSP a la red de transacción dinámica de la presente invención. Las figuras 5A, 5B y 5C son diagramas de flujo que ilustran un método para agregar un nuevo SCP a la red de transacción dinámica de la presente invención. La figura 6 es una vista esquemática del Lógico Transportable Dinámico (DTL) de la presente invención. La figura 7 es un diagrama de flujo que ilustra el flujo de llamada de tarjeta de llamada en la red de transacción dinámica de la presente invención. La figura 8 es un diagrama de flujo que ilustra la funcionalidad lógica de prisma en la red de transacción dinámica de la presente invención. La figura 9 es un diagrama de flujo que ilustra la ejecución del DTL en la red de transacción dinámica de la presente invención.
DESCRIPCIÓN DETALLADA DE LOS DIBUJOS Se requiere una breve discusión del término "fragmentos de base de datos" para comprender la operación de la presente invención. Un fragmento de base de datos es una "sección lógica" de una base de datos. Así, un solo servidor de datos puede dar servicio inicialmente a cientos de "fragmentos lógicos", que pueden finalmente crecer para ocupar cientos de servidores de datos. Así, la unidad de datos es un fragmento que, con el paso del tiempo, puede ser movido de un servidor físico a otro o a una pluralidad de servidores. La determinación de a cual fragmento de datos tener acceso en un tiempo dado es parte de la funcionalidad del lógico transportable dinámico. Así, en donde cada DTL tiene una pluralidad de entradas y salidas, por lo menos una de las salidas comprende la dirección del "fragmento lógico" para uso para la funcionalidad de la base de datos. Otro término significativo valioso de explicación preliminar es "red de transacción", cada uno de los cuales comprende tres bloques de construcción: la estación de manejo o SMP (Punto de Manejo del Sistema), la terminal o SSP (Punto de Conmutación de Servicio) y la base de datos o SCP (Punto de Control de Servicio) . El SMP es el administrador de configuración de red central para una red de transacción. El SMP proporciona control central y distribución de todos los DTL y topologías de red. Adicionalmente, el SMP proporciona verificación y funcionalidad de control Los SSP son los conmutadores reales que funcionan como el punto de entrada para todos los servicios ofrecidos en una red de PPCC. Los SCP son las bases de datos distribuidas utilizadas para controlar y determinar los servicios proporcionados durante las transacciones. Estas tres piezas funcionan conjuntamente para implementar una red de transacción escalable distribuida. La operación de esta red y cómo proporciona manejo dinámico o procesamiento de transacciones, se describe en detalle posteriormente en la presente. Con referencia ahora a la figura 1, se muestra una configuración 10 de red mínima. La configuración 10 de red mínima es comúnmente la configuración inicial encontrada después de la inicialización de la red de transacción dinámica. La red 10 incluye una terminal o SSP 12, una estación de manejo o SMP 14, una base de datos o SCP 16 y un medio de comunicación 18 que interconecta los SSP 12, SMP 14 y el SCP 16. Se supone que los mensajes en la red resultan de un método de escritura de datos confiable, tales como el método discutido en W. Richard Stevens, UNIX Network Programming, Prentice Hall, 1990, pp. 405-419, incorporado en la presente por referencia. Con referencia ahora a la figura 2, se muestra el método de configuración 20 para un SCP. Después del arranque de la red de transacción, en la etapa 22, el SMP no está configurado, de tal manera que el SMP lee su configuración de una base de datos local. Después de esto, en la etapa 24, el SCP se pone en contacto con el SMP con un mensaje de registro o señal de PING utilizando una escritura de datos confiable. Se debe notar que el SCP se pone en contacto periódicamente con el SMP con una señal de PING para asegurar que el SCP está almacenando todos los datos de configuración necesarios, como se describe en detalle adicional posteriormente en la presente. La señal de PING enlista los fragmentos de datos soportados por el SCP, también como estadísticas operacionales o estadísticas de operación del SCP por propósitos de verificación. La lista de fragmentos soportados es esencialmente un mensaje de registro que indica cuales servicios de bases de datos son soportados por el SCP. Las estadísticas operacionales o de operación pueden incluir, por ejemplo, datos de transacciones por segundo, memoria disponible y alarma de datos. La señal de PING también incluye un Número de Jornada de Configuración (CNJ) que representa el número de transacciones de configuración que se han presentado desde la instalación de la red. El número entero de CNJ puede ser usado para inspeccionar la exactitud de los datos de configuración distribuidos. Enseguida, en la etapa 26, el SMP responde al SCP con un mensaje que contiene una lista completa de SCP (que incluyen servidores de bases de datos y sus direcciones) , información acerca de a cuales "fragmentos" de la población de cuenta se da servicio, el estado actual del servicio de cada servidor y un número entero de CNJ que puede ser usado para inspeccionar la exactitud de los datos de configuración distribuidos. El mensaje también incluye de preferencia una lista completa de los SSP conectados a la red de transacción dinámica. Después que el SCP recibe la respuesta del SMP, el SCP, en la etapa 28, inspecciona la porción de "fragmentos servidos" de la respuesta contra el registro local del SCP. Si los fragmentos servidos han cambiado para excluir los fragmentos antiguos, en la etapa 30, entonces el servidor cesa de registrar aquellos fragmentos en la etapa 32. Si hay nuevos fragmentos que no estaban en la lista previa, en la etapa 34, entonces se inicia una operación de "adquirir fragmento" en la etapa 36. La operación de "adquirir fragmento" está dirigida a los propietarios previos (SCP) de los nuevos fragmentos. El SCP repite periódicamente las etapas 24-36 para asegurar que el SCP está almacenando todos los datos de configuración necesarios, esto es, si el SCP debe registrar los fragmentos excluidos y/o adquirir nuevos fragmentos. El SSP sufre un proceso de configuración 40 después que la configuración del SCP está consumada, como se muestra en la figura 3. Inicialmente, en la etapa 42, el SSP se pone en contacto con el SMP con un mensaje de PING. El mensaje de PING incluye estadísticas operacionales por propósitos de verificación. Las estadísticas operacionales incluyen, pero no están limitadas a, llamadas por hora, memoria disponible, espacio de disco y alarmas. El mensaje de PING también incluye un número entero de CJN que contiene el número de transacciones de configuración que se han presentado desde la instalación de la red. Como se explica previamente, el número entero de CJN puede ser usado para inspeccionar la exactitud de los datos de configuración distribuidos. Enseguida, en la etapa 44, el SMP responde al mensaje de PING del SSP con un CJN, una lista completa de servidores de bases de datos y sus direcciones, una indicación de a cuales "fragmentos" de la población de cuenta se les da servicio, el estado actual del servicio de cada fragmento y una lista completa de los SSP conectados a la red de transacción dinámica. Después de esto, en la etapa 46, el SSP determina si la base de datos de configuración está a una o más transacciones detrás del SMP. Si la base de datos de configuración del SSP no está detrás del SMP, el SSP regresa a la etapa 42 y transmite un mensaje de PING al SMP después del lapso de un período de tiempo predeterminado. Si la base de datos de configuración del SSP está detrás del SMP, el SSP envía una petición al SMP de las entradas de jornada perdidas. Después que el SMP responde con las entradas de jornada perdidas, el SSP está actualizado con las transacciones perdidas en la etapa 48. Las entradas de jornada son aplicadas de preferencia a la base de datos local y servidas a otros huéspedes en el grupo, asegurando mediante esto que todos los huéspedes (entidades de cómputo) en todos los grupos almacenen una copia idéntica de la base de datos de configuración. Después que la actualización está consumada, el SSP regresa a la etapa 42 y transmite un mensaje de PING al SMP después del transcurso de un período de tiempo predeterminado. El proceso descrito anteriormente se repite de manera continua, con un intervalo que tiene una longitud programable entre mensajes de PING. La latencia de actualizaciones de datos de configuración está basada por consiguiente solo en la frecuencia del mensaje de PING. Se debe notar que el SCP también actualiza transacciones perdidas utilizando el método mostrado en la figura 3. Con referencia ahora a la figura 4, se muestra un método 50 para agregar SSP (terminales de transacción) adicionales a la red de transacción dinámica. Los SSP recién agregados (por ejemplo, entidad o grupo de cálculo) no necesitan tener ninguna configuración particular antes de la inclusión del SSP a la red de transacción dinámica. En primer lugar, en la etapa 52, el nuevo SSP inicia el contacto con el SMP al transmitir un número de entrada de jornada de cero, indicando ninguna configuración, al SMP. Enseguida, en la etapa 54, el SMP responde al nuevo SMP al transmitir un número de entrada de jornada actual "n" para la red en operación. Después de esto, en la etapa 56, el SSP interroga al SMP por cada transacción en orden desde el número de entrada de jornada "1" al número de entrada de jornada "n". Luego, en la etapa 58, el SMP entrega las transacciones al SSP. Después de esto, en la etapa 60, el SSP aplica las transacciones y lleva a cabo las etapas de configuración asociadas con las transacciones en tiempo real. Un ejemplo de una transacción en tiempo real es copia de indicaciones de voz del cliente. Cuando el SSP llega al número de transacción de configuración actual, en la etapa 62, el SSP es traído al servicio. Con referencia ahora a las figuras 5A y 5B, se muestra un método para agregar SCP (servidores de base de datos) adicionales a la red de transacción dinámica. Inicialmente, en la etapa 72, el nuevo SCP (sin ninguna configuración) es conectado a la red. Enseguida, en la etapa 74, el nuevo SCP adquiere una base de datos de configuración y ajusta sus fragmentos de base de datos local en base a la configuración existente provista por la base de datos de configuración. Después de esto, en la etapa 76, el nuevo SCP inicia el contacto con el SMP al transmitir un número de entrada de jornada de cero al SMP: Un número de entrada de jornada de cero indica que el nuevo SCP no tiene ninguna configuración. El SMP, en la etapa 78, responde al nuevo SCP con el número de entrada de jornada actual "n" para la red en operación. Enseguida, en la etapa 80, el SCP interroga al SMP por cada transacción, en orden, desde el número de entrada de jornada "1" al número de entrada de jornada "n". Después de esto, en la etapa 82, el SCP aplica las transacciones y lleva a cabo las etapas de configuración asociadas con las transacciones en tiempo real. Un ejemplo de una transacción en tiempo real es la copia de indicaciones de voz del cliente, como se discute previamente. Cuando el SCP llega al número de transacción de configuración actual, en la etapa 84, el SCP puede comenzar a adquirir fragmentos. Dependiendo de la configuración inicial, el SCP puede no tener ningún fragmento lógico. Si es así, en la etapa 86, se invoca un cambio de configuración en el SMP para asignar fragmentos lógicos al- nuevo SCP. El nuevo SCP, en la etapa 88, determina si los fragmentos asignados fueron asignados previamente a SCP existentes. Esta etapa de determinación es efectuada para evaluar si se requiere una migración de un fragmento de otro SCP al nuevo SCP. Si el fragmento asignado no fue asignado previamente, el nuevo SCP, en la etapa 90, maneja cualesquier transacciones correspondientes al fragmento. Si el fragmento asignado fue asignado previamente, entonces se inicia una operación de adquirir -fragmento, en la etapa 92 y el nuevo SCP o SCP objetivo comienza inmediatamente a manejar transacciones para el fragmento asignado. Si el fragmento está en proceso de ser adquirido, las peticiones de transacción de registros de fragmentos todavía no adquiridos serán enviadas al administrador de fragmentos previo o SCP fuente (que reconoce que hay un nuevo administrador de fragmentos o SCP objetivo) . Luego, la respuesta del SCP fuente a las transacciones enviadas es transmitida de regreso al solicitante original. El SCP objetivo adquiere las entradas de fragmento asignadas previamente al efectuar un escrutinio del SCP previamente responsable por cada registro y al borrar cada registro del SCP fuente a medida que el SCP objetivo avanza a través de los fragmentos lógicos. Con referencia ahora a la figura 5C, se muestra un método alternativo 190 de la migración del fragmento de base de datos. Inicialmente, en la etapa 192, el SCP objetivo notifica al SCP fuente de la migración de un fragmento de base de datos (por ejemplo, fragmento 3) . Enseguida, en la etapa 194, el SCP fuente responde al SCP objetivo al proporcionar al SCP objetivo con un número de entrada de jornada (por ejemplo, 1003) y una copia del primer registro de base de datos en el fragmento de base de datos migrante. Después que el SCP objetivo recibe el primer registro de base de datos, el SCP objetivo, en la etapa 196, solicita el siguiente registro de base de datos para el fragmento de base de datos migrante. Antes de enviar una copia del siguiente registro de base de datos, el SCP fuente, en la etapa 198, determina si hay alguna transacción de jornada sobresaliente (por ejemplo 1004, 1005, etc.,...). Si hay transacciones de jornada sobresalientes, el SCP objetivo, en la etapa 200, es inspeccionado para determinar si ha copiado un registro de base de datos que corresponde a una transacción de jornada sobresaliente. Si el SCP objetivo no contiene un registro de base de datos correspondiente, la transacción de jornada, en la etapa 202, es aplicada al SCP fuente y el SCP fuente, en la etapa 198, determina si hay transacciones de jornada sobresalientes adicionales. Si el SCP objetivo -contiene un registro de base de datos correspondiente, la transacción de jornada, en la etapa 204, es aplicada al SCP fuente y el SCP objetivo y el SCP fuente, en la etapa 198, determina si hay transacciones de jornada sobresalientes adicionales. Se debe notar que este método asegura que el SCP fuente y el SCP objetivo contengan copias idénticas de un fragmento de base de datos después que la migración del fragmento de base de datos está consumada. Se debe notar que el SCP está en línea a través del procedimiento de migración y si, durante el procedimiento de migración, el SCP fuente o el SCP objetivo fallan por alguna razón, el procedimiento de migración puede ser reiníciado desde la última transacción copiada. Si no hay transacciones de jornada sobresalientes, el SCP fuente, en la "etapa 206, regresa una copia del siguiente registro de base de datos al SCP objetivo. Enseguida, en la etapa 208, el SCP objetivo determina si todo el fragmento de base de datos ha sido copiado. Si no, el SCP objetivo, en la etapa 196, solicita el siguiente registro de base de datos. Si es así, el SMP, en la etapa 210, re-mapea la ubicación del fragmento desde el SCP fuente al SCP objetivo. Después de esto, en la etapa 212, el fragmento de base de datos es retirado del SCP fuente. Se debe notar que se puede hacer referencia a cualquier número de fragmentos. Solamente depende que el DTL determine cual "número de fragmento" se debe usar. Puesto que el DTL puede ser reemplazado al vuelo (como se describe posteriormente) , el espacio del nombre del fragmento puede ser expandido o contraído durante la operación del sistema. Así, cualesquier limitaciones en el número de fragmentos de base de datos serían derivados del número de puntos del extremo de red direccionables. Además, el número de transacciones por segundo habilitadas por toda la red puede ser bastante masivo. Puesto que el número de SSP está limitado solamente por el número de SCP disponibles y fragmentos direccionables, el número de SSP es también igual al número de puntos del extremo de red direccionables. Así, el rendimiento teórico total de un sistema implementado utilizando la estructura y función de la presente invención es altamente escalable y virtualmente ilimitado .
Sin embargo, la velocidad con la cual los cambios de configuración son acomodados puede ser más que un factor limitante en el rendimiento del sistema total. No obstante, una jerarquía de configuración empalmada es de preferencia incluida para proporcionar rendimiento de transacción de configuración adicional. Para minimizar las transacciones de configuración, la jerarquía de configuración empalmada permite el envío de cambios de configuración a los SSP y SCP solamente como se requiera. Cuando un SSP necesita llevar a cabo una transacción (por ejemplo, inspeccionar y actualizar un balance para una tarjeta de llamada particular) , el SSP ejecutará su lógico de DTL, utilizando la técnica de procesamiento de transacciones en línea descrita posteriormente en la presente, para determinar cual fragmento lógico usar para la transacción. Si el fragmento lógico seleccionado tiene un estado de servicio ACTIVO, entonces una petición de transacción es creada y enviada al SCP que maneja actualmente el fragmento lógico. Luego el SCP se comunica directamente con el SSP solicitante cuando responde a la petición de transacción. Volviendo ahora al Procesamiento de Transacciones en Línea (OLTP) , se debe notar que un mecanismo clave para utilizar la tecnología de base de datos distribuida de la presente invención es una combinación de distribuir y administrar los datos de configuración, también como distribuir y utilizar el DTL para interconectarse con la red de transacción. El DTL de la presente invención se describe mejor como un "prisma" dinámicamente reemplazable, que refleja los rayos de transacciones a sus sitios correctos durante el uso de la red. Lenguajes de computadora tales como JAVA de Sun Microsystem se han desarrollado para distribuir lógicos ejecutables desde servidores a clientes para su ejecución. El _ DTL contemplado y descrito en la presente para uso con la presente invención tiene funcionalidad similar. En efecto, Java sería un candidato excelente para esta función. Otros mecanismos de DTL disponibles incluyen Pearl Penquin, Bell Labs Interferon y Active X de Microsoft. La sustitución e inclusión de cualquiera de estos lenguajes y métodos de distribución serían entendidos por aquellos experimentados en la técnica a la cual la presente invención pertenece. Con referencia ahora a la figura 6, se muestra un diagrama de "prisma" 100 que ilustra la funcionalidad de un elemento de DTL 102. Como se muestra, el elemento o algoritmo de DTL 102 dirige una transacción entrante 104 a un SCP 106 que corresponde a las características de entrada de la transacción entrante 104. Más específicamente, el elemento de DTL 102 utiliza una o más de las siguientes características de entrada para dirigir la petición de transacción. Una Identificación de Número Automática (ANI) que proporciona el número de fuente de una llamada entrante al SSP huésped. UN código del Sistema de Identificación del Número Marcado (DNIS) que proporciona el número marcado por el llamador para llegar al SSP huésped. Un número llamado originalmente (OCN) que proporciona un número marcado antes de que la llamada llegue al SSP huésped. (Se debe notar que el OCN es también denominado algunas veces como el Número Redirigido) . Un PIN o número de cuenta introducido por un usuario. (El PIN o número de cuenta es usualmente DTMF o palabras habladas procesadas en dígitos por el SSP) . Un puerto físico o circuito al que la llamada llega. Dígitos de información que proporcionan una indicación desde qué clase de terminal el llamador está marcando (por ejemplo, un teléfono pagado, teléfono de hotel o teléfono de prisión) . Cuando se determina a cual trayectoria dirigir la transacción entrante, el elemento de DTL genera un número de señales de salida. Una salida es una dirección de fragmento lógico en forma de un valor entero que denota la ubicación de la base de datos en la cual reside un registro, necesario para la transacción. Otra salida es un número de cuenta o de PIN que comprende una clave de base de datos digital que permite que una transacción gane acceso a los registros en una base de datos. Una salida adicional puede ser una contraseña opcional que contiene un número de PIN o número de cuenta cambiable por el usuario, en forma de un código incrustado. Sin embargo, se debe notar que la contraseña opcional no es parte de la clave de la base de datos. El elemento de DTL tiene mecanismos de encripción y suma de verificación integrados para impedir que transacciones no válidas lleguen a los servidores centrales (SCP) . Puesto que la clave de la base de datos y ubicación del fragmento de la base de datos son determinados por el DTL y se incluyen sumas de verificación y descifrado en el DTL, la transacción final puede ser encriptada con clave privada para su transporte a los servidores centrales (SCP) con el fin de usar de manera segura una red pública para portar la transacción final. ' Con referencia ahora a la figura 7, se muestra un método 110 de flujo de la llamada con tarjeta de llamada. Inicialmente, en la etapa 112, un SSP recibe una llamada entrante. El SSP responde a la llamada entrante reproduciendo un mensaje de bienvenida, en la etapa 114 y pidiendo al llamador, en la etapa 116, el número de PIN del llamador. Después de recibir el número de PIN, el SSP, en la etapa 118, transmite las características de llamada entrante (incluyendo el número de PIN) a su lógico de prisma. Enseguida, si el lógico del prisma (de la etapa 118) determina que el número de PIN introducido no es válido, el SSP, en la etapa 120, informa al llamador que el número introducido no es válido y en la etapa 116, pide al usuario que reintroduzca el número de PIN. Sin embargo, si el SSP, en la etapa 112, determina que el número de intentos del llamador por introducir un número de PIN excede un limite predeterminado, el SSP transmite un mensaje de "adiós", en la etapa 124 y desconecta la llamada. Si el lógico de prisma (de la etapa 118) determina que el número de PIN es válido, el SSP, en la etapa 126 evalúa una contraseña introducida por el llamador (véase figura 9) . Si la contraseña no es válida, el SSP, en la etapa 120, informa al llamador que el número introducido no es válido y en la etapa 116, pide al usuario que reintroduzca el número de PIN. Sin embargo si el SSP, en la etapa 122, determina que el número de intentos del llamador por introducir un número de PIN excede un límite predeterminado, el SSP transmite un mensaje de "adiós", en la etapa 124 y desconecta la llamada. Si la contraseña introducida es válida, el SSP, en la etapa 128, pide al llamador el número telefónico que el llamador desea marcar. Con referencia ahora a la figura 8, se muestra un ejemplo de la funcionalidad 130 del lógico de prisma. Inicialmente, en la etapa 132, el lógico de prisma recibe un conjunto de características de la llamada entrante del SSP (figura 7, etapa 118). Enseguida, en la etapa 134, el lógico de prisma detecta el DNIS de la llamada entrante y en la etapa 135, selecciona el DTL correspondiente al DNIS de una memoria local 136 del SSP. Como se describe previamente, la memoria local del SSP es actualizada periódicamente por el SMP. Una vez que el DTL ha sido seleccionado, el lógico de prisma, en la etapa 138, ejecuta el DTL. El lógico de prisma deriva la ubicación de un fragmento de base de datos de las características de llamada (por ejemplo, DNIS, ANI, OCN, PIN o contraseña) de una llamada entrante. Estas características son representadas comúnmente por una serie de dígitos. Si el DTL no tiene una serie completa de dígitos, entonces el DTL, en la etapa 140, emite una petición de un dígito adicional. Si el DTL tiene una serie completa de dígitos y determina que la petición de transacción no es válida (figura 9) , entonces el DTL, en la etapa 142, emite una señal no válida para el lógico de prisma que, a su vez, emite una señal no válida al SSP (figura 7, etapa 118) . Si el DTL deriva la ubicación del fragmento de base de datos (figura 9), entonces el DTL emite la dirección del fragmento al lógico de prisma. Después que el lógico de prisma recibe la dirección del fragmento de base de datos, el lógico de prisma, en la etapa 144, interroga a la base de datos relevante 146 y recibe la información almacenada en el fragmento de base de datos (por ejemplo, balance de la tarjeta de llamada) . Si el lógico de prisma determina que la información recibida permite que el llamador efectúe una llamada, entonces el • lógico de prisma, en la etapa 148, emite una señal válida y una contraseña, si es aplicable, al SSP. Con referencia ahora a la figura 9, se muestra un método 150 de ejecución del DTL. Inicialmente, en la etapa 151, el DTL comienza a recibir una serie de -dígitos del lógico de prisma (figura 8, etapa 138) . El DTL espera un dígito, en la etapa 154 y agrega el dígito recibido, en la etapa 154 a una serie de dígitos. Enseguida, en la etapa 156, el DTL determina si la serie de dígitos coincide con un patrón de dígitos almacenado en la tabla 158. Si la serie no coincide con un patrón de dígitos almacenado, el DTL, en la etapa 160, pide un dígito adicional y en la etapa 152, espera el dígito requerido. Si la serie de dígitos coincide con un patrón de dígitos almacenado, el DTL, en la etapa 162, se ramifica a un método almacenado de control de llamadas correspondiente al patrón de dígitos coincidente. Si el DTL se ramifica al método "A", el DTL, en la etapa 164, intenta descifrar la petición de transacción entrante. Si el DTL no es apto para descifrar la petición de transacción, el DTL, en la etapa 166/ emite una señal no válida al lógico de prisma. Si el DTL descifra exitosamente la petición de transacción, el DTL, en la etapa 168, determina si la suma de verificación es válida. Si la suma de verificación no es válida, el DTL, en la etapa 170, emite una señal no válida al lógico de prisma. Si la suma de verificación es válida, el DTL, en la etapa 172 deriva la dirección del fragmento de base de datos correspondiente a la petición de transacción y en la etapa 174, emite la dirección al lógico de prisma. Si el DTL se ramifica al método "B", el DTL, en la etapa 176, interroga al llamador, vía el lógico de prisma y SSP, en cuanto a dígitos de contraseña. Alternativamente, el DTL puede detectar una porción de contraseña de las características de llamada entrantes. Enseguida, en la etapa 178, el DTL determina si la contraseña completa es recibida. Si la contraseña es recibida solo parcialmente, el DTL regresa a la etapa 176 e interroga al llamador en cuanto a dígitos adicionales. Si la contraseña completa es recibida, el DTL transmite la contraseña al SSP que a su vez determina si la contraseña es válida (figura 7, etapa 126). Volviendo ahora a la etapa 182, el DTL deriva la dirección del fragmento de base de datos correspondiente a la petición de transacción al dividir el número de PIN por un número entero, tal como 999 y utilizando el residuo para determinar la dirección del fragmento de base de datos relevante. Enseguida, en la etapa 184, el DTL emite la dirección al lógico de prisma. Una descripción general del aparato y método de la presente invención, también como modalidades preferidas de ambos se han resumido anteriormente. El experimentado en la técnica reconocerá y será apto de llevar a la práctica muchos cambios en muchos aspectos del aparato y método descritos anteriormente, en los que se incluyen variaciones que caen en el alcance de la invención, como se define mediante las reivindicaciones adjuntas. Por ejemplo, la presente invención descrita utiliza términos de telecomunicaciones puesto que es el objetivo inicial de la presente invención. Sin embargo, muchos de los problemas de OLTP resueltos con esta invención se aplicarán a otras industrias. Se hace constar que, con relación a esta fecha, el mejor método conocido por la solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención.

Claims (64)

  1. REIVINDICACIONES Habiéndose descrito la invención como antecede, se reclama como propiedad, lo contenido en las siguientes reivindicaciones : 1. Una red de transacciones dinámica, caracterizada porque comprende: una sección de administración (o sección de manejo) que contiene un lógico transportable que facilita el acceso a la red de transacciones dinámica; una base de datos conectada a la estación de administración a través de un medio de comunicaciones, la base de datos tiene por lo menos un fragmento de base de datos almacenado en la misma y una terminal conectada a la estación de administración a través del medio de comunicaciones, la terminal recibe el lógico transportable desde la estación de administración después de la inicialización de la red de transacciones dinámica, la terminal hace acceso al fragmento de base de datos vía el lógico transportable en respuesta a una petición de transacción de un usuario.
  2. 2. La red de transacciones dinámica de conformidad con la reivindicación 1, caracterizada porque la estación de administración actualiza el lógico transportable almacenado en la misma en respuesta a un cambio en una estructura de la red de transacciones dinámica.
  3. 3. La red de transacciones dinámica de conformidad con la reivindicación 2, caracterizada porque el cambio en la estructura es una adición de una terminal a la red de transacciones dinámica.
  4. 4. La red de transacciones dinámica de conformidad con la reivindicación 2, caracterizada porque el cambio en la estructura es una remoción de una terminal de la red de transacciones dinámica.
  5. 5. La red de transacciones dinámica de conformidad con la reivindicación 2, caracterizada porque el cambio en la estructura es una adición de una base de datos a la red de transacciones dinámica.
  6. 6. La red de transacciones dinámica de conformidad con la reivindicación 2, caracterizada porque el cambio en la estructura es una remoción de una base de datos de la red de transacciones dinámica.
  7. 7. La red de transacciones dinámica de conformidad con la reivindicación 2, caracterizada porque el cambio en la estructura es una adición de un fragmento de base de datos a la red de transacciones dinámica.
  8. 8. La red de transacciones dinámica de conformidad con la reivindicación 2, caracterizada porque el cambio en la estructura es una remoción de un fragmento de base de datos de la red de transacciones dinámica.
  9. 9. La red de transacciones dinámica de conformidad con la reivindicación 2, caracterizada porque el cambio en la estructura es una migración de un fragmento de base de datos desde una primera base de datos a una segunda base de datos.
  10. 10. La red de transacciones dinámica de conformidad con la reivindicación 2, caracterizada porque la terminal reemplaza el lógico transportable almacenado en la misma con el lógico transportable actualizado almacenado en la estación de administración en respuesta a una determinación que hay una diferencia entre el lógico transportable almacenado en la misma y el lógico transportable actualizado almacenado en la estación de administración.
  11. 11. La red de transacciones dinámica de conformidad con la reivindicación 10, caracterizada porque la determinación es efectuada por la terminal después de una comparación del lógico transportable almacenado en la misma y el lógico transportable actualizado almacenado en la estación de administración.
  12. 12. La red de transacciones dinámica de conformidad con la reivindicación 1, caracterizada porque la terminal actualiza el lógico transportable almacenado en la misma con el lógico transportable almacenado en la estación de administración en respuesta a una determinación de que hay una diferencia entre el lógico transportable almacenado en la misma y el lógico transportable almacenado en la estación de administración .
  13. 13. La red de transacciones dinámica de conformidad con la reivindicación 12, caracterizada porque la determinación es efectuada por la terminal después de una comparación del lógico transportable almacenado en la misma y el lógico transportable actualizado almacenado en la estación de administración.
  14. 14. La red de transacciones dinámica de conformidad con la reivindicación 1, caracterizada porque la red es una red de tarjetas de llamada prepagada (PPCC) .
  15. 15. La red de transacciones dinámica de conformidad con la reivindicación 1, caracterizada porque el lógico transportable localiza un fragmento de base de datos correspondiente a una petición de transacción en base a una entrada proporcionada por la petición de transacción.
  16. 16. La red de transacciones dinámica de conformidad con la reivindicación 15, caracterizada porque la entrada es una identificación automática del número (ANI) de una llamada entrante a la terminal.
  17. 17. La red de transacciones dinámica de conformidad con la reivindicación 15, caracterizada porque la entrada es un DNIS de una llamada entrante a la terminal.
  18. 18. La red de transacciones dinámica de conformidad con la reivindicación 15, caracterizada porque la entrada es un OCN de una llamada entrante a la terminal.
  19. 19. La red de transacciones dinámica de conformidad con la reivindicación 15, caracterizada porque la entrada es un número redirigido de una llamada entrante a la terminal.
  20. 20. La red de transacciones dinámica de conformidad con la reivindicación 15, caracterizada porque la entrada es una entrada del usuario a la terminal.
  21. 21. La red de transacciones dinámica de conformidad con la reivindicación 20, caracterizada porque la entrada del usuario es un número de identificación personal (PIN) .
  22. 22. La red de transacciones dinámica de conformidad con la reivindicación 20, caracterizada porque la entrada del usuario es un número de cuenta.
  23. 23. La red de transacciones dinámica de conformidad con la reivindicación 20, caracterizada porque la entrada del usuario es un número de identificación personal . (PIN) derivado vía procesamiento de voz.
  24. 24. La red de transacciones dinámica de conformidad con la reivindicación 20, caracterizada porque la entrada del usuario es un número de cuenta derivado vía procesamiento de voz.
  25. 25. La red de transacciones dinámica de conformidad con la reivindicación 20, caracterizada porque la entrada del usuario es un número de identificación personal (PIN) derivado vía procesamiento de señales de multifrecuencia de tono dual (DTMF) .
  26. 26. La red de transacciones dinámica de conformidad con la reivindicación 15, caracterizada porque la entrada del usuario es un número de cuenta derivado vía procesamiento de señales de multifrecuencia de tono dual (DTMF) .
  27. 27. La red de transacciones dinámica de conformidad con la reivindicación 15, caracterizada porque la entrada es una dirección de un puerto de terminal al que ha llegado una llamada entrante.
  28. 28. La red de transacciones dinámica de conformidad con la reivindicación 15, caracterizada porque la entrada es una hora del día a la que ha llegado una llamada entrante a la terminal.
  29. 29. La red de transacciones dinámica de conformidad con la reivindicación 15, caracterizada porque la entrada es una indicación de un tipo de terminal que generó la llamada entrante.
  30. 30. La red de transacciones dinámica de conformidad con la reivindicación 15, caracterizada porque el lógico transportable localiza el fragmento de base de datos correspondiente a la petición de transacción y proporciona una dirección de base de datos del fragmento.
  31. 31. La red de transacciones dinámica de conformidad con la reivindicación 30, caracterizada porque el lógico transportable localiza el fragmento de base de datos correspondiente a la petición de transacción y proporciona una clave de base de datos para tener acceso al fragmento en la base de datos.
  32. 32. La red de transacciones dinámica de conformidad con la reivindicación 15, caracterizada porque el lógico transportable localiza el fragmento de base de datos correspondiente a la petición de transacción y proporciona una clave de base de datos para tener acceso al fragmento en la base de datos.
  33. 33. Una red de transacciones dinámica, caracterizada porque comprende: una sección de administración (o sección de manejo) que contiene datos de configuración del sistema que definen la red la red de -transacción dinámica y el lógico transportable dinámico que facilita el acceso a la red de transacción dinámica; una base de datos conectada a la estación de administración a través de un medio de comunicaciones, la base de datos tiene por lo menos un fragmento de base de datos almacenado en la misma y una terminal conectada a la estación de administración a través del medio de comunicaciones, la terminal recibe los datos de configuración del sistema y el lógico transportable dinámico de la estación de administración después de la inicialización de la red de transacciones dinámica, la terminal hace acceso al fragmento de base de datos vía el lógico transportable dinámico en respuesta a una petición de transacción de un usuario.
  34. 34. La red de transacciones dinámica de conformidad con la reivindicación 33, caracterizada porque la estación de administración actualiza los datos de configuración del sistema y el lógico transportable dinámico almacenado en la misma en respuesta a un cambio en una estructura de la red de transacciones dinámica.
  35. 35. La red de transacciones dinámica de conformidad con la reivindicación 34, caracterizada porque el cambio en la estructura es una adición de una terminal a la red de transacciones dinámica.
  36. 36. La red de transacciones dinámica de conformidad con la reivindicación 34, caracterizada porque el cambio en la estructura es una remoción de una terminal de la red de transacciones dinámica.
  37. 37. La red de transacciones dinámica de conformidad con la reivindicación 34, caracterizada porque el cambio en la estructura es una adición de una base de datos a la red de transacciones dinámica.
  38. 38. La red de transacciones dinámica de conformidad con la reivindicación 34, caracterizada porque el cambio en la estructura es una remoción de una base de datos de la red de transacciones dinámica.
  39. 39. La red de transacciones dinámica de conformidad con la reivindicación 34, caracterizada porque el cambio en la estructura es una adición de un fragmento de base de datos a la red de transacciones dinámica.
  40. 40. La red de transacciones dinámica de conformidad con la reivindicación 34, caracterizada porque el cambio en la estructura es una remoción de un fragmento de base de datos de la red de transacciones dinámica.
  41. 41. La red de transacciones dinámica de conformidad con la reivindicación 34, caracterizada porque el cambio en la estructura es una migración de un fragmento de base de datos desde una primera base de datos a una segunda base de datos .
  42. 42. La red de transacciones dinámica de conformidad con la reivindicación 34, caracterizada porque la terminal reemplaza los datos de configuración del sistema y el lógico transportable dinámico almacenado en la misma con los datos de configuración del sistema actualizados y el lógico transportable dinámico actualizado almacenado en la estación de administración en respuesta a una determinación que hay una diferencia entre los datos de configuración del sistema y el lógico transportable dinámico almacenado en la misma y los datos de configuración del sistema y el lógico transportable dinámico actualizado almacenado en la estación de administración.
  43. 43. La red de transacciones dinámica de conformidad con la reivindicación 42, caracterizada porque la determinación es efectuada por la terminal después de una comparación de los datos de configuración del sistema y el lógico transportable dinámico almacenado en la misma y los datos de configuración del sistema y el lógico transportable dinámico actualizado almacenado en la estación de administración .
  44. 44. La red de transacciones dinámica de conformidad con la reivindicación 33, caracterizada porque la terminal actualiza los datos de configuración del sistema y el lógico transportable dinámico almacenado en la misma con los datos de configuración del sistema y el lógico transportable dinámico almacenado en la estación de administración en respuesta a una determinación de que hay una diferencia entre los datos de configuración del sistema y el lógico transportable dinámico almacenado en la misma y los datos de configuración del sistema y el lógico transportable dinámico almacenado en la estación de administración.
  45. 45. La red de transacciones dinámica de conformidad con la reivindicación 44, caracterizada porque la determinación es efectuada por la terminal después de una comparación de los datos de configuración del sistema y el lógico transportable dinámico almacenado en la misma y el los datos de configuración del sistema y el lógico transportable dinámico actualizado almacenado en la estación de administración.
  46. 46. La red de transacciones dinámica de conformidad con la reivindicación 33, caracterizada porque la red es una red de tarjetas de llamada prepagada (PPCC) .
  47. 47. La red de transacciones dinámica de conformidad con la reivindicación 33, caracterizada porque el lógico transportable localiza un fragmento de base de datos correspondiente a una petición de transacción en base a una entrada proporcionada por la petición de transacción.
  48. 48. La red de transacciones dinámica de conformidad con la reivindicación 47, caracterizada porque la entrada es una identificación automática del número (ANI) de una llamada entrante a la terminal.
  49. 49. La red de transacciones dinámica de conformidad con la reivindicación 47, caracterizada porque la entrada es un DNIS de una llamada entrante a la terminal.
  50. 50. La red de transacciones dinámica de conformidad con la reivindicación 47, caracterizada porque la entrada es un OCN de una llamada entrante a la terminal.
  51. 51. La red de transacciones dinámica de conformidad con la reivindicación 47, caracterizada porque la entrada es un número redirigido de una llamada entrante a la terminal.
  52. 52. La red de transacciones dinámica de conformidad con la reivindicación 47, caracterizada porque la entrada es una entrada del usuario a la terminal.
  53. 53. La red de transacciones dinámica de conformidad con la reivindicación 52, caracterizada porque la entrada del usuario es un número de identificación personal (PIN) .
  54. 54. La red de transacciones dinámica de conformidad con la reivindicación 52, caracterizada porque la entrada del usuario es un número de cuenta.
  55. 55. La red de transacciones dinámica de conformidad con la reivindicación 52, caracterizada porque la entrada del usuario es un número de identificación personal (PIN) derivado vía procesamiento de voz.
  56. 56. La red de transacciones dinámica de conformidad con la reivindicación 52, caracterizada porque la entrada del usuario es un número de cuenta derivado vía procesamiento de voz.
  57. 57. La red de transacciones dinámica de conformidad con la reivindicación 52, caracterizada porque la entrada del usuario es un número de identificación personal (PIN) derivado vía procesamiento de señales de multifrecuencia de tono dual (DTMF) .
  58. 58. La red de transacciones dinámica de conformidad con la reivindicación 52, caracterizada porque la entrada del usuario es un número de cuenta derivado vía procesamiento de señales de multifrecuencia de tono dual (DTMF) .
  59. 59. La red de transacciones dinámica de conformidad con la reivindicación 47, caracterizada porque la entrada es una dirección de un puerto de terminal al que ha llegado una llamada entrante.
  60. 60. La red de transacciones dinámica de conformidad con la reivindicación 47, caracterizada porque la entrada es una hora del día a la que ha llegado una llamada entrante a la terminal.
  61. 61. La red de transacciones dinámica de conformidad con la reivindicación 47, caracterizada porque la entrada es una indicación de un tipo de terminal que generó la llamada entrante.
  62. 62. La red de transacciones dinámica de- conformidad con la reivindicación 47, caracterizada porque el lógico transportable dinámico localiza el fragmento de base de datos correspondiente a la petición de transacción y proporciona una dirección de base de datos del fragmento.
  63. 63. La red de transacciones dinámica de conformidad con la reivindicación 62, caracterizada porque el lógico transportable dinámico localiza el fragmento de base de datos correspondiente a la petición de transacción y proporciona una clave de base de datos para tener acceso al fragmento en la base de datos.
  64. 64. La red de transacciones dinámica de conformidad con la reivindicación 47, caracterizada porque el lógico transportable localiza el fragmento de base de datos correspondiente a la petición de transacción y proporciona una clave de base de datos para tener acceso al fragmento en la base de datos.
MXPA01001822A 1998-08-18 1999-08-16 Logico transportable para facilitar una red de transaccion de tarjetas de llamada grande que soporta cambios dinamicos. MXPA01001822A (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/135,607 US6263060B1 (en) 1998-08-18 1998-08-18 Transportable logic to facilitate a large calling card transaction network supporting dynamic changes
PCT/US1999/018580 WO2000011627A1 (en) 1998-08-18 1999-08-16 Transportable logic to facilitate a large calling card transaction network supporting dynamic changes

Publications (1)

Publication Number Publication Date
MXPA01001822A true MXPA01001822A (es) 2002-04-08

Family

ID=22468826

Family Applications (1)

Application Number Title Priority Date Filing Date
MXPA01001822A MXPA01001822A (es) 1998-08-18 1999-08-16 Logico transportable para facilitar una red de transaccion de tarjetas de llamada grande que soporta cambios dinamicos.

Country Status (7)

Country Link
US (2) US6263060B1 (es)
EP (1) EP1105853A1 (es)
AU (1) AU5564399A (es)
BR (1) BR9913466A (es)
CA (1) CA2340924C (es)
MX (1) MXPA01001822A (es)
WO (1) WO2000011627A1 (es)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6453032B1 (en) * 1998-04-02 2002-09-17 Lucent Technologies Inc. Method for creating and modifying similar and dissimilar databases for use in dialing plan configurations for telecommunication systems
DE60028874T2 (de) * 1999-07-06 2006-11-09 Canon K.K. System zum Suchen eines Gerätes im Netzwerk
WO2001022242A1 (fr) * 1999-09-17 2001-03-29 Sony Corporation Systeme et procede permettant de fournir des donnees
US7388953B2 (en) * 1999-09-24 2008-06-17 Verizon Business Global Llc Method and system for providing intelligent network control services in IP telephony
US6636596B1 (en) * 1999-09-24 2003-10-21 Worldcom, Inc. Method of and system for providing intelligent network control services in IP telephony
JP4292733B2 (ja) * 2001-08-10 2009-07-08 コニカミノルタビジネステクノロジーズ株式会社 画像配布システム、画像データ配布装置、画像配布方法ならびに画像データ配布装置用プログラムおよびこれを記録したコンピュータ読み取り可能な記録媒体
US20030144910A1 (en) * 2002-01-30 2003-07-31 Flaherty Stephen C. System and method for distributing inventory for point-of-sale activation services
US6954631B2 (en) * 2003-02-13 2005-10-11 Hewlett-Packard Development Company, L.P. Apparatus and method for telecommunications services
US7533126B2 (en) * 2003-05-05 2009-05-12 Cisco Technology, Inc. Managing contacts in a communication network
US7433455B1 (en) 2003-05-05 2008-10-07 Cisco Technology, Inc. Processing a communication session using a rules engine
US8159958B1 (en) * 2004-04-06 2012-04-17 At&T Intellectual Property Ii, L.P. Krone block dongle
MXPA06013340A (es) * 2004-05-18 2007-05-04 Rba International Inc Sistemas y metodos para el control de cuenta remota.
EP1610234B1 (en) * 2004-06-22 2007-08-01 Sap Ag Online transactional data processing system
US20070094507A1 (en) * 2005-10-21 2007-04-26 Rush Frederick A Method and system for securing a wireless communication apparatus
US7650367B2 (en) * 2006-01-13 2010-01-19 Tekelec Methods, systems, and computer program products for detecting and restoring missing or corrupted data in a distributed, scalable, redundant measurement platform database
US8688628B2 (en) * 2008-02-29 2014-04-01 Red Hat, Inc. Nested queued transaction manager
US8131700B2 (en) * 2008-09-25 2012-03-06 Microsoft Corporation Transitioning clone data maps and synchronizing with a data query
US8447834B1 (en) 2008-09-26 2013-05-21 Sprint Communications Company L.P. Wireless content loading
US9323758B1 (en) * 2009-12-22 2016-04-26 Emc Corporation Efficient migration of replicated files from a file server having a file de-duplication facility
CN101807286A (zh) * 2010-02-05 2010-08-18 南京联创科技集团股份有限公司 电信多系统7×24小时交易场景下精确对账的实现方法
US10367703B2 (en) * 2016-12-01 2019-07-30 Gigamon Inc. Analysis of network traffic rules at a network visibility node
US20180205611A1 (en) * 2017-01-13 2018-07-19 Gigamon Inc. Network enumeration at a network visibility node

Family Cites Families (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IT1154048B (it) 1981-06-09 1987-01-21 Urmet Sud Costr Elett Telefon Perfezionamento ai sistemi ed alle apparecchiature per la telefonia pubblica impiegante apparecchi urbani interurbani dotati di selettore
US4439636A (en) 1982-03-09 1984-03-27 Martha Newkirk Credit card actuated telecommunication access network
US5375161A (en) 1984-09-14 1994-12-20 Accessline Technologies, Inc. Telephone control system with branch routing
US4897870A (en) 1985-09-25 1990-01-30 Southlake Technologies, Inc. Network implemented pay telephone set
US4706275A (en) 1985-11-13 1987-11-10 Aerotel Ltd. Telephone system
US4860346A (en) 1986-12-22 1989-08-22 Protel, Inc. Telephone system and method operated from central office loop current
JPS63292257A (ja) * 1987-05-11 1988-11-29 インタ−ナショナル・ビジネス・マシ−ンズ・コ−ポレ−ション 複数の端末局へのデ−タまたはプログラムのロ−デイング方法
US5049873A (en) * 1988-01-29 1991-09-17 Network Equipment Technologies, Inc. Communications network state and topology monitor
US4942598A (en) 1988-03-04 1990-07-17 Motorola, Inc. Telephone answering machine in paging systems with automatic number identification based message operations
US5572572A (en) * 1988-05-05 1996-11-05 Transaction Technology, Inc. Computer and telephone apparatus with user friendly interface and enhanced integrity features
US5168446A (en) * 1989-05-23 1992-12-01 Telerate Systems Incorporated System for conducting and processing spot commodity transactions
JPH0346089A (ja) 1989-07-13 1991-02-27 Brother Ind Ltd カードに印字可能なプリペイドカード管理装置
US4975942A (en) 1989-07-21 1990-12-04 The Boston Communications Group Credit/calling card pay telephone method and system employing telephone unit local card-checking and other intelligence cooperative with local personal host computer
US5226073A (en) 1990-12-31 1993-07-06 At&T Bell Laboratories Telephone network credit card calling apparatus and method of telephone network operation with credit card companies
US5163086A (en) 1990-12-31 1992-11-10 At&T Bell Laboratories Telephone network credit card calling apparatus and method of operation to determine validation and fraudulent use of credit cards in placing telephone calls
US5359642A (en) 1991-10-30 1994-10-25 International Integrated Communications, Inc. Method and apparatus for prepayment of telecommunication connections by registered groups of subscribers in a telecommunication switching network
US5386467A (en) * 1992-07-31 1995-01-31 At&T Corp. Intelligent network communication system
AU693768B2 (en) 1992-08-26 1998-07-09 Bellsouth Corporation Personal number communications system
US5408519A (en) 1993-01-19 1995-04-18 Teledebit, L.P. Telecommunications system having a local area network with concurrently processing nodes
US5577109A (en) * 1994-06-06 1996-11-19 Call Processing, Inc. Pre-paid card system and method
US5815560A (en) * 1994-06-08 1998-09-29 Fujitsu Limited Communication service control apparatus
FR2724082A1 (fr) * 1994-08-30 1996-03-01 Info Telecom Dispositif telephonique
US5621727A (en) * 1994-09-16 1997-04-15 Octel Communications Corporation System and method for private addressing plans using community addressing
US5696906A (en) 1995-03-09 1997-12-09 Continental Cablevision, Inc. Telecommunicaion user account management system and method
US5978577A (en) * 1995-03-17 1999-11-02 Csg Systems, Inc. Method and apparatus for transaction processing in a distributed database system
US5706286A (en) * 1995-04-19 1998-01-06 Mci Communications Corporation SS7 gateway
WO1996038801A1 (en) * 1995-06-01 1996-12-05 American Express Trs Methods and apparatus for providing a prepaid, remote entry customer account
US5749075A (en) 1995-06-06 1998-05-05 Interactive Media Works, L.L.C. Method for providing prepaid internet access and/or long distance calling including the distribution of specialized calling cards
US5621787A (en) 1995-09-13 1997-04-15 Bell Atlantic Network Services, Inc. Prepaid cash card
US5712908A (en) * 1995-12-22 1998-01-27 Unisys Corporation Apparatus and method for generating call duration billing records utilizing ISUP messages in the CCS/SS7 telecommunications network
US5740229A (en) * 1996-03-15 1998-04-14 At&T Corp Method and apparatus for a pre-paid return call
US5937042A (en) * 1996-03-19 1999-08-10 Mci Communications Corporation Method and system for rehome optimization
US5734705A (en) * 1996-03-29 1998-03-31 Xiox Corporation Intelligent configuration server for PBX
US5764155A (en) * 1996-04-03 1998-06-09 General Electric Company Dynamic data exchange server
US5940478A (en) * 1996-05-31 1999-08-17 Octel Communications Corporation Method and system for extended addressing plans
US6038309A (en) * 1996-06-13 2000-03-14 Northern Telecom Limited Apparatus and method for externally controlling processing of a service call
US5999610A (en) * 1996-06-26 1999-12-07 Telcordia Technologies, Inc. Managing feature interactions in a telecommunications system such as an intelligent network
WO1998009256A1 (de) * 1996-08-30 1998-03-05 Siemens Aktiengesellschaft Verfahren zur vorbereitung der durchführung einer chipkarten-applikation und vorrichtungen zur durchführung dieses verfahrens
US6434611B1 (en) * 1996-12-20 2002-08-13 Mci Communications Corporation System and method for message-based real-time reconfiguration of a network by broadcasting an activation signal to activate a new connection configuration
US6188761B1 (en) * 1997-10-21 2001-02-13 Mci Communications Corporation System and method for providing operator and customer services
US6311186B1 (en) * 1998-02-20 2001-10-30 Priority Call Management, Inc. Telecommunications switching system utilizing a channelized database access mechanism

Also Published As

Publication number Publication date
AU5564399A (en) 2000-03-14
BR9913466A (pt) 2001-06-05
WO2000011627A9 (en) 2000-06-22
CA2340924C (en) 2004-11-02
US6263060B1 (en) 2001-07-17
WO2000011627A1 (en) 2000-03-02
US6636593B1 (en) 2003-10-21
CA2340924A1 (en) 2000-03-02
EP1105853A1 (en) 2001-06-13

Similar Documents

Publication Publication Date Title
MXPA01001822A (es) Logico transportable para facilitar una red de transaccion de tarjetas de llamada grande que soporta cambios dinamicos.
CA2050691C (en) Automatic system for forwarding of calls
NO20110211A1 (no) Kommunikasjonstjenester
US6608887B1 (en) Voice messaging system with ability to prevent hung calls
WO1996007265A1 (en) Telephone system under the control of its users
FR2804810A1 (fr) Activation de service par carte pre-payee virtuelle
JP2004527015A (ja) 資金記憶装置から電子的な金額を伝送するための方法及び装置
DE69828686D1 (de) System zur verwaltung von dienstdaten in fernmeldesystemen
EP1001591B1 (en) Redundant database storage of selected record information for an automated interrogation device
US5978462A (en) Method and system for automating updates to subscriber service accounts to accommodate numbering plan area splits
EP0450610A2 (en) Telecommunications voice and data services network architecture
US5761276A (en) Voice mail service apparatus and a controlling method thereof
US6891939B1 (en) Method and system for providing calling name identification with advanced intelligent network
WO1990011661A1 (en) Catalog ordering system with increased security
US20030172356A1 (en) Centralized management of a distributed database system
US6795537B1 (en) Method for updating a database using a telephone
BRPI0419129B1 (pt) método para provisão de informações de endereço de roteamento
US20050021779A1 (en) Localized knowledge-based intelligent network
US6590967B1 (en) Variable length called number screening
US7366287B2 (en) DTMF lockout utility epoch time stamp
US20200193431A1 (en) Systems and methods for wallet, token, and transaction management using distributed ledgers
KR0160347B1 (ko) 정보료수납대행 서비스에서 착신 번호 산출을 위한 호분배 처리 방법
AU734410B2 (en) Telephone call handling system
USRE30973E (en) Telephone station coin memory and control system
CN100382648C (zh) 管理交付服务指令的系统和方法

Legal Events

Date Code Title Description
FG Grant or registration
MM Annulment or lapse due to non-payment of fees