MXPA01000872A

MXPA01000872A - Sistema de conmutacion de telecomunicaciones que utiliza un mecanismo de acceso canalizado a bases de datos.

Info

Publication number: MXPA01000872A
Application number: MXPA01000872A
Authority: MX
Inventors: Patrick J Melampy
Original assignee: Priority Call Man Inc
Priority date: 1998-07-24
Filing date: 1999-02-19
Publication date: 2002-07-02
Also published as: AU2872099A; BR9912411A; EP1101365A1; WO2000005919A1; CA2338593A1

Abstract

Se proporciona un sistema de base de datos de telecomunicaciones que permite que una plataforma periferica inteligente (IP) tenga acceso canalizado hacia una pluralidad de bases de datos. La plataforma de IP puede localizar el dato en cualquiera de la pluralidad de bases de datos a traves de un mapa de canales que es derivado del dato de configuracion suministrado por una base de datos por omision y el dato suministrado por una llamada que entra o la peticion a la plataforma IP. Una vez que el mapa de canales es derivado, la plataforma de IP puede seleccionar un canal para tener acceso a una base de datos local o remota con base en el dato suministrado por la llamada que entra o la peticion. Este dato puede ser una peticion para la informacion, la id del circuito de servicio, DNIS de la llamada que entra, la direccion introducida por un llamador, OCN/Redireccion de la llamada, ANI de la llamada, y/o indicadores de progreso.

Description

SISTEMA DE CONMUTACIÓN DE TELECOMUNICACIONES QUE UTILIZA UN MECANISMO DE ACCESO CANALIZADO A BASES DE DATOS CAMPQ DE LA INVENCIÓN La presente invención se refiere a un sistema de base de datos. Más particularmente, la presente invención se refiere a un sistema de base de datos de telecomunicaciones que permite que un periférico inteligente tenga acceso canalizado de base de datos hacia una pluralidad de bases de datos.

ANTECEDENTES DE LA INVENCIÓN Los requerimientos de datos en el campo de las telecomunicaciones están cambiando. Los conmutadores de telecomunicaciones y los periféricos inteligentes hoy en día requieren acceso en tiempo real a grandes cantidades de datos. Estos datos incluyen, pero no están limitados a, perfiles de suscriptores, datos de configuración, grabaciones de voz, y plantillas de reconocimiento de voz. El Periférico Inteligente CIP) de hoy en día contiene Ref: 127002 un arreglo cada vez mayor de objetos de datos. El acceso a estos objetos debe ser en tiempo real, distribuido, y escalable. No obstante, es encontrado un inconveniente en que los mecanismos de almacenamiento de base de datos convencionales desplegados, tienden a limitar el tamaño y la complejidad de los IP's. Otro inconveniente más encontrado es que el procedimiento convencional de replicar los datos del suscriptor ya no es factible. Se tiene acceso a las bases de datos comúnmente a través de los Puntos de Control de Servicio (SCP's). Estos SCP's proporcionan típicamente acceso a los productos de base de datos de Lenguaje de Búsqueda Estructurada fuera de anaqueles (SQL) tales como Oracle, Sybase, o Informix. Las plataformas de computadora SCP son usualmente computadoras tolerantes a las fallas de extremo intermedio a alto o computadoras flexibles a las fallas. Frecuentemente, los contenidos de las bases de datos SCP son replicados para proporcionar el rendimiento preferido. Por ejemplo, este es el caso con las bases de datos de número 800 portátil. Una base de datos número 800 está localizada sobre la red mediante el uso de direcciones conocidas de antemano, ya sean físicas o lógicas. Estas direcciones pueden ser manejadas y cambiadas a través de las funciones de manejo de Conexión de Señalización y Parte de Control (SCCP) , o a través de arquitecturas de red altamente disponibles, similares. Cada base de datos contiene el universo completo de datos disponibles, y puede cumplir las necesidades de un IP. No obstante, la replicación de las bases de datos es logísticamente difícil. Como resultado, la latencia para los cambios de número 800 es medida en semanas. Además, los datos personalizados tales como los perfiles del suscriptor, las plantillas de reconocimiento de voz, y otros de este tipo no son fácilmente replicados a un número de sitios SCP dispersos. Además, los datos que son cambiados frecuentemente (tales como mensajes de voz) no son candidatos para la replicación debido a los problemas de latencia. Un inconveniente adicional encontrado es que el equipo físico (hardware) , para el IP no es aceptable para el uso en las bases de datos. Los sistemas de computadora que son sintonizados a los requerimientos de base de datos en tiempo real de estos productos de base de datos fuera de anaquel, son frecuentemente inapropiados para la inclusión en IPs y en dispositivos de conmutación. Por ejemplo, un canm ta-dar de a Xc-Lna- fixia-X ATT 5E.SS de la Clase 5 no es por naturaleza un buen candidato para la inclusión del Servidor Paralelo Oracle 7.2. Los componentes de procesamiento de voz no son en general compatibles con el equipo físico de la computadora en la base de datos de extremo alto. Los componentes de Integración Telefónica de Computadora Abierta como el Dialogic D242SC-T1 requieren una computadora con barra colectiva ISA, y son incapaces de correr en el modo de multiprocesador requerido por la mayoría de las bases de datos de extremo alto. Debido a las razones anteriores, la arquitectura de la Red Inteligente (IN) muestra claramente al SCP como un componente distinto separado. Un inconveniente adicional encontrado es el uso de las bases de datos globales en vez de distribuidas. Las plataformas de IP son usualmente distribuidas a todo lo largo de una red. Esto permite que los puertos de procesamiento de voz sean directamente conectados al sitio que requiere servicios mejorados. Para la mayoría de las redes telefónicas, incluyendo redes celulares, las Plataformas de IP están dispersas a todo lo largo del área de cobertura. El costo de la larga distancia de los circuitos telefónicos hacia los sitios centrales es menos económico que la replicación de las plataformas de IP. Cuando los servicios de datos basados en el suscriptor no están centralizados, todos los servicios de IP podrían tener que ser procesados fuera del IP que contiene el dato del suscriptor. El modelo general para la infraestructura de la red alámbrica es tener una base de datos global para cada IN, que esté fragmentada por categoría de acceso. La recomendación es una serie de SCP's separados, uno por cada categoría. Algunas categorías incluyen: 1. La Base de Datos de Servicios de Manejo de Llamadas (CMSDB) 2 ^ lia Bas-e de Datas- de Información de Línea (LIDB) 3. La Base de Datos de Información Mercantil (BSDB) 4. El Registro de Localización Doméstica (HLR) 5. El Registro de Localización del Visitante (VLR) Otro inconveniente más encontrado es que las bases de datos IP actuales están centralizadas. El modelo de IN es centralizar el dato del suscriptor para una región en una CMSDB singular. En el modelo de red inalámbrica, un HLR es definido para retener la información alrededor de los suscriptores, y es en efecto una base de datos distribuida. Los proveedores de la red de deambulación celular distribuyen una tabla que traza en mapa los rangos de los Números de Identificación Móvil (MIN) a las bases de datos HLR particulares. Si el volumen de las transacciones excede la capacidad de la base de datos de HLR, el proveedor de servicio tiene pocas opciones. Una es dividir la base de datos en dos piezas, pero esto es operacionalmente complejo y dará como resultado interrupciones del servicio. Más particularmente, los vendedores de IP conectan típicamente sus computadoras del circuito de servicio sobre una red que sirve a los datos provenientes de una computadora remota que corre la base de datos SQL. El procedimiento convencional es construir una base de datos grande y simple que debe, por necesidad, desarrollarse al tamaño requerido. Al agregar procesadores adicionales, la fragmentación de la base de datos en piezas distintas que permanecen lógicamente sobre una base de datos, y realizando el manejo de base de datos cuidadoso, la base de datos puede crecer para cumplir los requerimientos de los circuitos de servicios de IP. Al final, la base de datos crece hasta un tamaño que es difícil de manejar, o incluso imposible de expandir. En este punto, los circuitos de servicio de IP ya no pueden expandirse para manejar tráfico adicional. De este modo, una población simple de usuarios crece a un punto donde la base de datos previene la expansión del servicio. Es difícil y casi imposible dividir la base de datos en dos piezas manejables, ya que el tráfico telefónico de entrada no es segmentado de ningún modo. Si la base de datos puede ser dividida, la acción perturbará el servicio por un periodo sustancial de tiempo. Para hacer las cosas peores, las nuevas aplicaciones que son desarrolladas y comercializadas requieren cantidades significativamente más grandes de datos que las previamente requeridas. Por ejemplo, la tarjeta para hacer llamadas da como resultado bases de datos con cientos de millones de registros. Debido a que los circuitos del servicio de la tarjeta de llamada no tienen control sobre dónde se origina una llamada, la base de datos debe ser ubicua, siendo disponible para todos los circuitos de servicio. Problemas de complicación adicionales son que las tarjetas para hacer llamadas son frecuentemente dejadas con un saldo pequeño insignificante el cual debe ser mantenido hasta que la tarjeta expire. El periodo de tiempo es frecuentemente de uno- a má-s. añas... Otro problema más con la infraestructura de IP de telecomunicaciones, convencional, es la incapacidad de utilizar los datos a través de diferentes plataformas. Las compañías celulares típicamente tienen una plataforma de Marcación Activada por Voz completamente separada y distinta del MTSO (Computador Telefónico Móvil), el cual a su vez. es distinto de un s-iste a de correo de voz. De este modo, cada usuario será provisionado en tres bases de datos separadas. Algunas de estas bases de datos son accesibles en red ancha, y algunas no lo son. El correo de voz y la marcación activada por la voz, por lo tanto, puede únicamente ser disponible en ciertas regiones basadas en la disponibilidad de los datos. Otro problema más con la infraestructura de IP de telecomunicaciones, convencional, es la falta de Interconexiones de Red Estándares. Todas las bases de datos de SQL actuales requieren accionadores específicos del vendedor e interconexiones que son diseñadas para la computadora del cliente. JDe este modo, la dotación lógica informática (software) proveniente de Oracle debe correr sobre un modo de computadora IP para tomar ventaja completamente de la base de datos SQL de Oracle. Na existen, estándares industriales de cómo un cliente puede conectarse a, y realizar las transacciones de SQL. La Conectividad de Base de Datos Abierta (ODBC) y CORBA proporcionan Interconexiones de Programación de Aplicación (API's), pero utilizan accionadores para inplementar los mecanismos de transporte específicos del vendedor. Por ejemplo, para correr Oracle Client u Oracle ODBC, la red de SQL* es requerida sobre el sistema de la computadora del cliente.

VENTAJAS DE. LA OtVEMCIÓN Una ventaja de la presente invención es proporcionar un sistema de base de datos que supera los inconvenientes de la técnica anterior, descritos anteriormente . Estas y otras ventajas de la presente invención se volverán aparentes para una persona de experiencia en la técnica en vista de las figuras y la descripción de las figuras dadas más adelante.

BREVE DESCRIPCIÓN DE LA INVENCIÓN De manera contraria a la industria de correo de voz, la industria de tarjetas para llamar requiere configuraciones de base de datos muy grandes. Estas configuraciones son frecuentemente de muchos millones de registros. Muchos clientes tienen sistemas de servicio de cliente extensos que típicamente requieren acceso de Lenguaje de Búsqueda Estructurada (SQL), y pueden incluso aprovisionar una base de datos de tarjeta de llamada, paralela, debido a los campos faltantes y a la información faltante. El diseño de la presente invención es una migración de la arquitectura de base de datos convencional a una nueva arquitectura más escalable y abierta. Utilizando el diseño de la presente invención, los clientes serán capaces de escribir a un Servidor Proxy para tener acceso a las bases de datos existentes. La división de los clientes será asignada a un canal de la base de datos. Estos canales señalarán hacia una base de datos física, la cual puede ser ya sea una base de datos local o externa. El sistema será de este modo capaz de soportar un gran número de bases de datos externas físicas. El diseño de la presente invención también permite "la expansión al vuelo", sin la necesidad de reiniciar el sistema. Además, el diseño de la presente invención permitirá que los canales o fragmentos de la base de datos sean retirados del servicio por razones de mantenimiento, individualmente o en grupos. El sistema de la base de datos de la presente invención requiere varios elementos, los cuales tomados conjuntamente, proporcionan un sistema que enfrenta los inconvenientes encontrados por los sistemas convencionales, como se discutió anteriormente. Cualquier número de IP' s en una red será capaz de tener acceso a cualquier número de base de datos de una manera consistente y manejable. Una base de datos simple (llamada la base de datos por omisión de la red) sirve y maneja la coherencia de antememoria (cache) para un grupo de registros que identifican la red completa de bases de datos, cómo tener acceso a las bases de datos, y qué registros y omisiones van a ser utilizados. Debido a que los registros de datos son utilizados en cada transacción, éstos son almacenados temporalmente en la memoria sobre cada IP que participa. Una vez en la memoria, la presente invención maneja la coherencia de antememoria de una manera que es apropiada para la tarea. De este modo, la propagación de cambios es permitida para tener alguna latencia. Las plataformas de IP reciben y procesan llamadas telefónicas. Las llamadas llegan a la IP con información que es implícita y explícita. Por ejemplo, está implicado el circuito efectivo utilizado, mientras que la Identificación de Número Automático (ANI) puede ser proporcionada explícitamente. El dato que llega con una llamada de entrada incluye aquellos casos identificados en el Instituto de Estándares Nacionales Norteamericanos (ANSÍ) o los estándares de Partes de Usuario de Red Digital de Servicios Integrados (ISUP) de las Uniones de Telecomunicaciones Internacionales (ITU) , e incluye, entre otras cosas, la Parte que Llama, la Parte Llamada, el Número de Redirección, el Número para Redirigir, una Parte que Llama Original, los Indicadores del Progreso de la Llamada. Una lista completa de posibles campos puede ser encontrada en los Documentos de la Unión Internacional de Telecomunicaciones Q_.761-Q..767 para las redes basadas en SS7, y Q..931 para las redes basadas en Velocidad o Proporción Primaria, las cuales son incorporadas por referencia en la presente. Los algoritmos descritos aquí utilizan los datos implícitos y explícitos para determinar cómo deben ser accedidos los datos. Cada IP que participa en el mecanismo de Base de Datos Canalizada' de la presente invención debe tener lo siguiente: 1. una conexión a una red (SS7, o TCP/IP); 2. acceso a una o más bases de datos (SCP, Servidores SQL, Servidores de Propietarios) a través de la red; y 3. acceso a una base de datos por omisión para mantener la configuración alrededor de los canales de la base de datos disponibles. Cuando se requiere el dato, el dato implícito y explícito es utilizado para determinar qué mapa de canales va a ser utilizado para tener acceso al dato (como se discute con detalle en la descripción de las Figuras 4A-4E) . El mapa contiene toda la información respecto a cada tipo de registro de datos utilizado por el IP. Se tiene acceso al mapa a partir de una base de datos por omisión, y es almacenada temporalmente en la memoria local. La notificación de los cambios de mapa es requerida para nivelar la entrada vieja de la antememoria. Este es un servicio requerido de la base de datos por omisión, utilizada para almacenar el mapa. El mapa contiene una lista de tipos de registro utilizados por el IP. Los tipos de registro tienen cada uno un canal físico asociado con ellos. Los canales físicos pueden ser numerados. Por ejemplo, los canales físicos pueden estar numerados del 1 al 99. En tal caso, el canal físico 1 está reservado como la base de datos por omisión. Los sistemas pequeños, o sistemas sin mapas de canal, utilizarán siempre el canal 1 para todos los requerimientos de datos. También contenida lógicamente dentro de la configuración del mapa de canales, está una serie de campos por omisión para ser suministrados si faltan en el servidor. Los campos por omisión son listados para cada tipo de registro utilizado en el IP. Estos campos no están contenidos dentro de la base de datos por omisión. Para facilitar la identificación precisa y sustentada de los registros y campos, la presente invención implementa la Interconexión de Sistemas Abiertos (OSI) que cumple con el esquema de identificación. Este esquema proporciona la jerarquía para el originador del registro, el registro mismo, y cualesquiera campos dentro del registro . Una vez que se determina el canal físico, un segundo registro de datos que describe el canal físico es accedido. Este registro es también almacenado temporalmente en la memoria local, y se tiene acceso a él a partir de la base de datos por omisión. La configuración del canal físico contiene todos los datos requeridos para tener acceso a la base de datos. Típicamente, éste contiene la dirección y la localización del servidor proxy primario, el servidor secundario, y otros datos como sean necesarios para configurar el enlace de comunicación. Por ejemplo, si la red es SS7 o el ErotocoLo de Control de Iraní sm i. si?a/Protocolo Interno (TCP/IP) , si la capa de sesión es el Protocolo de Información de Manejo Común (CMIP) , el Elemento de Servicio de Operaciones Remotas (ROSE) , el Protocolo de Aplicación de Capacidades Transaccionales (TCAP) , o el Protocolo de Manejo de Red Simple (.SNMP) . La localización de la base de datos puede ser expresada como un código de punto SS7, la dirección TCP/IP, o un nombre lógico que es resuelto a uno de éstos-. Si la resolución del nombre lógico a la dirección física es requerida, se utiliza la Traslación de Título Global para las redes de SS7, y un Servidor de Nombre del Sistema de Nombre de Dominio (DNS) es utilizado en las direcciones TCP/IP. Si se manejan servidores redundantes o múltiples por la dotación lógica informática SCCP SS7, se emplea este mecanismo de superación de fallas. En la operación, se envía un mensaje de petición de transacción al procesador del servidor de IP. La petición de transacción puede ser un llamador que utiliza una tarjeta de llamada, marcando un número 800, verificando el correo de voz, o alguna otra petición de telecomunicaciones. El proceso del servidor IP recibe la transacción y procesa la transacción. Los pasos incluyen la contabilización de la transacción para la replicación a un proceso del servidor IP de espera, los contadores estadísticos de actualización y las tablas de verificación periódica de funcionamiento, etc. La transacción es convertida al formato de capa de sesión, y transportada vía la red definida al servidor proxy. El servidor IP espera entonces una respuesta. Nótese en el caso general, los servidores Ip no son entretejidos de manera simple, y pueden manejar cualquier número de peticiones de base de datos pendientes. El servidor proxy recibe la petición de transacción, y descodifica la petición en el formato requerido por la base de datos residente. Típicamente, esto es descodificado en campos, y luego una interconexión de usuario para acceso bruto a la base de datos SQL, es utilizada. Por ejemplo,. cuando se utiliza Oracle, se utiliza la interconexión de los programadores OCI. La transacción es luego realizada contra la base de datos. Los resultados de la transacción son luego devueltos al proceso del servidor IP después de ser codificados para las capas de transporte y sesión. (NOTA: Un servidor proxy puede no ser requerido si el mecanismo de la base de datos soporta transacciones ROSE o TCAP nativamente) . El servidor IP recibe la respuesta, descodifica la respuesta en formatos locales, cubre los campos por omisión para el registro particular accedido, y luego envía la transacción completada al proceso de petición dentro de la plataforma de IP. Todas y cada una de las transacciones contienen los campos clave requeridos para la identificación de registro, y así entonces únicamente los campos que van a ser cambiados (o puestos en instantáneo sobre una transacción de crear) . Los valores de los campos y cómo éstos reemplazan o se modifican a sí mismos serán definidos con base en sus tipos de datos. Por ejemplo, los campos que son secuencias de texto simplemente se reemplazarán a sí mismos completamente después de la actualización. Los campos que contienen valores numéricos serán ya sean cada vez mayores o absolutos dependiendo de los parámetros de la transacción. Por ejemplo, supóngase que fuera a ser mantenido un campo de saldo o balance. Cada ajuste normal podría ser un valor con signo el cual es agregado a los contenidos actuales del balance o saldo. Ya que cada ajuste es realizado únicamente en la base de datos, no se requiere aseguramiento fuera de la base de datos. Los IP' s no tienen que asegurar o poner candado al registro para sustraer el costo de una llamada conforme ' ésta ocurre, o agregarse al saldo de los suscriptores después de una recarga exitosa. Esta forma de manejo de transacción es simplificada por el rompimiento de cada registro utilizado sobre un IP en sus campos, y luego además en sus tipos de almacenamiento fundamentales. Estos tipos son fáciles de identificar, y están también construidos en muchos de los codificadores y descodificadores de Notación de Extracto Syntex (ASN.l) . Mediante el uso de las herramientas de la dotación lógica informática orientadas al objeto, la tarea de manejar las transacciones de campo por campo es simplificada mediante el uso de la herencia proveniente de estos tipos de almacenamiento fundamentales, base. Los tipos de almacenamiento fundamentales tienen métodos asociados con ellos para la conversión hacia y desde las formas codificadas binariamente Proporción de Error de Bitios CBER) utilizadas durante el transporte. Existen otros métodos para realizar diversos tipos de transacciones en una base de campo por campo. El uso de las clases de datos orientadas por objetivos simplifica en gran medida el manejo de los campos a través de múltiples plataformas de computadora. Las bases de datos externas son mantenidas externamente utilizando herramientas proporcionadas como parte de la base de datos externa. El aprovisionamiento de estas bases de datos podría ser realizado con los mecanismos de acceso con SQL, o mecanismos de acceso equivalentes. Un concepto clave es que los requerimientos de datos IP en tiempo real son cumplidos a través del servidor proxy, mientras que el acceso administrativo y de aprovisionamiento en tiempo real es cumplido a través ya sea del acceso directo a la base de datos, o a través del acceso canalizado proporcionado por la presente invención. El acceso directo a la base de datos es deseable, ya que las bases de datos SQL por definición están mejor adecuadas para el acceso administrativo y el reporte ad-hoc. Dicho brevemente, se proporciona una base de datos de telecomunicaciones que permite que un periférico inteligente (IP) tenga acceso canalizado a la base de datos hacia una pluralidad de bases de datos. El IP puede colocar el dato en cualquiera de la pluralidad de bases de datos a través de un mapa de canal que es derivado del dato de configuración suministrado por una base de datos por omisión y el dato suministrado por una llamada que entra o la petición al IP. Una vez que el mapa de canal es derivado, el IP puede seleccionar un canal para tener acceso a una base de datos local o remota, con base en el dato suministrado por la llamada que entra o la petición. Este dato puede ser una petición para información, id del circuito de servicio, DNIS de la llamada que entra, la dirección introducida por un llamador, OCN/Redirección de la llamada, ANI de la llamada, y/o indicadores de progreso . Una característica de la presente invención incluye un sistema de base de datos que tiene un dispositivo periférico inteligente, una base de datos conectada al dispositivo periférico inteligente a través de un medio de comunicaciones, una base de datos por omisión conectada al dispositivo periférico inteligente a través del medio de comunicaciones, conteniendo la base de datos por omisión los datos de configuración alrededor de la base de datos, y el dispositivo periférico inteligente tiene acceso al dato almacenado en la base de datos, al adquirir el dato de configuración proveniente de la base de datos por omisión, y comunicándose con la base de datos de acuerdo con el dato de configuración. Otra característica más de la presente invención incluye un sistema de base de datos que tiene un dispositivo periférico inteligente, una pluralidad de bases de datos conectadas al dispositivo periférico inteligente a través de un medio de comunicaciones, una base de datos por omisión conectada al dispositivo periférico inteligente a través del medio de comunicaciones, la base de datos por omisión que contiene el dato de configuración respecto a la pluralidad de bases de datos, y el dato de acceso al dispositivo periférico inteligente, almacenado en una de la pluralidad de bases de datos mediante la adquisición del dato de configuración proveniente de la base de datos por omisión y comunicándose con la pluralidad de bases de datos de acuerdo con el dato de configuración. Una característica adicional de la presente invención incluye un sistema de base de datos canalizada que tiene un dispositivo periférico inteligente, una pluralidad de canales de comunicación conectados al dispositivo periférico inteligente, cada canal de comunicación asociado con una base de datos, y un elemento de memoria conectado al dispositivo periférico inteligente para proporcionar el dato de configuración alrededor de la pluralidad de canales de comunicación hacia el dispositivo periférico inteligente, tal que el dispositivo periférico inteligente puede colocar y tener acceso al dato almacenado en una base de datos, asociada con una pluralidad de canales de comunicación.

Una característica adicional de la presente invención incluye un método para tener acceso a una pluralidad de bases de datos incluyendo los pasos de recibir una petición para el dato proveniente de un usuario, teniendo acceso a una base de datos por omisión para el dato de configuración para la pluralidad de bases de datos, la derivación de un mapa de base de datos proveniente del dato requerido, el dato de configuración, y la información del usuario, teniendo el acceso a una base de datos de la pluralidad de bases de datos para el dato requerido, con base en el mapa de la base de datos, la recepción del dato requerido proveniente de la base de datos, y la transmisión del dato requerido hacia el usuario.

BREVE DESCRIPCIÓN DE LOS DXBUÚ.OS Las ventajas anteriormente mencionadas de la presente invención así como las ventajas adicionales de la misma, serán más claramente comprendidas de aquí en adelante como resultado de una descripción detallada de una modalidad preferida de la invención, cuando se toma en conjunto con los siguientes dibujos, en los cuales: La Figura 1 es una vista diagramática de las bases de datos múltiples de acceso a IP's múltiples, a través de los canales dentro del sistema de bases de datos de la presente invención. La Figura 2 es un diagrama que ilustra los elementos utilizados para determinar un canal de datos dentro del sistema de base de datos de la presente invención. La Figura 3 es un diagrama que ilustra el sistema de identificación de registro y de campo de la presente invención. Las Figuras 4A-4E son diagramas de flujo que ilustran el método de selección de canal dentro del sistema de la base de datos de la presente invención. La Figura 5 es un diagrama que ilustra un elemento de información utilizado dentro del sistema de la base de datos de la presente invención. La Figura 6 es un diagrama que ilustra un elemento de la información de texto utilizado dentro del sistema de la base de datos de la presente invención . La Figura 7 es un diagrama que ilustra un elemento de información del número telefónico, utiliz-ada dentr-a deX sistema de base de datas de la presente invención. La Figura 8 es un diagrama que ilustra un elemento de información de número entero de 32 bitios, utilizado dentro del sistema de base de datos de la presente invención. La Figura 9 es un diagrama que ilustra un elemento de información de número entero de 16 bitios, utilizado dentro del sistema de base de datos de la presente invención. La Figura 10 es un diagrama que ilustra un elemento de información de número entero de 8 bitios, utilizado dentro del sistema de base de datos de la presente invención. La Figura 11 es un diagrama que ilustra un elemento de información de clase decimal, utilizado dentro del sistema de base de datos de la presente invención. La Figura 12 es un diagrama que ilustra un elemento de información de referencia cruzada de la base de datos utilizado dentro del sistema de la base de datos de la presente invención. La Figura 13 es un diagrama que ilustra una clase de registro DB utilizada dentro del sistema de base de datos de la presente invención.

La Figura 14 es un diagrama que ilustra una clase de registro de dato DB utilizada dentro del sistema de base de datos de la presente invención. La Figura 15 es un diagrama que ilustra una clase de transacción DB utilizada dentro del sistema de base de datos de la presente invención. Las Figuras 16A-16F muestran el código de la fuente de la clase del elemento de información, de la presente invención. Las Figuras 17A-17C muestran el código de la fuente de la clase de registro DB, de la presente invención. La Figura 18 es un diagrama que ilustra un paquete XCP de la presente invención. La Figura 19 es un diagrama que ilustra los campos del encabezado XCP de la presente invención. La Figura 20 es una tabla que ilustra los estados válidos entendidos por el servidor XCP de la presente invención. La Figura 21 es una tabla que ilustra los tipos de paquete XCP de la presente invención. La Figura 22 es una tabla que ilustra los estados XCP de la presente invención. La Figura 23 es un diagrama que ilustra el protocolo XCP de la presente invención.

La Figura 24 es una tabla que ilustra diversas estadísticas de XCP mantenidas por el DCM de la presente invención. La Figura 25 es un diagrama de flujo que ilustra las funciones principales llevadas a cabo por diversas líneas de servidores DCM de la presente invención. La Figura 26 es un diagrama de flujo que ilustra las funciones principales llevadas a cabo por diversas líneas o filas de servidores PROXY de la presente invención.

DESCRXECIÓN DE-TALLADA DE LQS DIBUJOS La presente invención crea una arquitectura de base de datos que permite que sea compartida una pluralidad de servidores de base de datos por una pluralidad de IP's, que permitirán que ocurra lo siguiente : 1. Los IP's pueden conectarse a y utilizar una multitud de soluciones de base de datos (incluyendo SCP's) simultáneamente, sin accionadores ni componentes específicos del vendedor. 2. Cualquier IP puede utilizar datos en cualquier servidor de base de datos, a través de un mapa de canal donde: a. El canal es determinado por tipo de dato requerido; b. El canal es determinado por circuito de servicio; c. El canal es determinado por DNIS de una llamada; d. El canal es determinado por dirección introducida por el usuario; e. El canal es determinado por OCN/Redirección de una llamada; f. El canal es determinado por ANI de una llamada; y g. El canal es determinado por indicadores de progreso. 3. Los canales de base de datos proporcionarán los tipos de transacción universal donde : a. Todos los datos que atraviesan los canales son convertidos a formatos específicos de máquina, configurables, después de entrar o abandonar el canal, incluyendo: 1. CMIP sobre TCP/IP, 2. SNMP sobre TCP/IP, 3. TCAP sobre SS7, 4. TCAP sobre TCP/IP (TR1129+), 5. ROSE sobre SS7, 6. Transferencia Ordenada por Final Grande Bruto, 7. Transferencia Ordenada por Final Pequeño Bruto; y b. Los valores de campo por omisión pueden ser establecidos con base en el canal utilizado para cada tipo de registro. Esto proporciona datos consistentes entre las bases de datos disc rdantes . 4. El manejo dinámico del acceso al servidor de la base de datos permite: . La adición de bases de da1os adicionales al vuelo; b. Acceso controlado para permitir el mantenimiento programado de instancias de base de datos ex.i-stentes ; c. Campos por omisión cambiables en una base de canal por canal; y d. Destino cambiante de la base de datos en tiempo real, permitiendo que las bases de datos existentes sean reconstruidas y activadas en tiempo real. 5. Todos los campos de datos serán convertidos a un puñado de tipos de almacenamiento universales donde: a. Los tipos de almacenamiento definirán los mecanismos de conversión; y b. Los tipos de almacenamiento definirán los mecanismos de actualización 6. Toda la comunicación entre la base de datos y el IP será manejada por una sesión que cumple con OSI y las capas de transporte. Los mensajes de datos se conformarán a CMIP, SNMP, TCAP, ROSE, o Bruto. 7. Los servidores de IP manejarán el lado IP del canal donde: a. El servidor mantendrá la coherencia de antememoria sobre el IP; b. El servidor proporcionará los registros de base de datos estándares y los formatos utilizados por el IP; c. El servidor cubrirá los campos por omisión después de leer un registro; d. El servidor convertirá las peticiones de la base de datos a formatos binarios configurables; e. El servidor mantendrá las características de funcionamiento para cada canal, completo con las funciones de manejo de la red para alarmar cuando el funcionamiento esté por debajo del estándar; y f. El servidor proporcionará conexión continua a un sitio redundante si el funcionamiento del canal se vuelve inadecuado. 8. Los servidores proxy manejarán el lado remoto de la base de datos del canal donde: a. El proxy enviará los cambios de configuración para manejar la coherencia de antememoria ; b. El proxy ejecutará los programas específicos de la base de datos para realizar las transacciones requeridas; c. El proxy convertirá las transacciones codificadas a transacciones nativas adecuadas para la base de datos; y d. El proxy omitirá cualesquiera campos no almacenados en la base de datos. 9, Las transaccion.es serán convertidas campo por campo con relación a los cambios donde: a. Todo el aseguramiento de los registros y campos no será requerido; y b. Únicamente los campos que tienen reemplazo o cambios en incremento serán transaccionados . 10. Pueden ser utilizadas bases de datos de legado y tener acceso a ellas a través de un canal donde : a. Las omisiones lógicas proporcionan ajustes por omisión inteligentes para los campos de datos faltantes; y b. Los servidores proxy convertirán y ajustarán el dato de legado a los requerimientos de IP. 1L~ Todo e2L mantenimiento de ia base de datos (actualizaciones de creación, de supresión, administrativas) puede ser realizado externamente, lo cual significa: a. Se utilizan rutinas de mantenimiento con herramientas externas (SQL) ; b. Se escriben reportes de propósitos generales utilizando herramientas externas; c. El mantenimiento de la base de datos se realiza externamente también; y d. Únicamente el acceso en tiempo de corrida para los registros de datos es necesario. 12. Todos los registros de datos y los campos serán identificados por un sistema de identificación que cumple con O.I.S.

Con referencia ahora a la Figura 1, el sistema de conmutación de telecomunicaciones 10 de la presente invención es mostrado. El sistema 10 incluye una red o medio 12 (por ejemplo, SS7, TCP/IP, etc.), que interconecta una pluralidad de plataformas IP 14 a una pluralidad de bases de datos 16-28. La red 12 incluye, pero no está limitada a, una pluralidad de canales 30. Los canales 30 interconectan cada IP 14 a cada base de datos 16-28 sobre la red 12. Una base de datos por omisión 16 almacena los mapas de canal (ver Figura 2) que contienen toda la información de cada tipo de registro de dato utilizado por las plataformas IP 14 y los canales 30 asociados con los tipos de registro. Una serie de campos por omisión están también contenidos lógicamente dentro de cada configuración de mapa de canal. Los campos por omisión son listados para cada tipo de registro utilizado para la plataforma IP 14, y son suministrados a la plataforma IP si están de otro modo faltantes. La base de datos por omisión 16 también almacena la información de configuración de canal físico alrededor de cada canal físico 30 en la red 12. La información de configuración de canal físico contiene todos los datos requeridos para tener acceso a las bases de datos 18-28. Típicamente, esta información contiene la dirección y la localización de un servidor primario SCP/proxy 32-40, servidor secundario, y otros datos como sean necesarios para configurar una conexión de comunicaciones entre una plataforma de IP 14 y una base de datos 18-28. Por ejemplo, si la red es SS7 o el Protocolo de Control de Transmisión/Protocolo Interno (TCP/IP) , si la capa de sesión es el Protocolo de Información de Manejo Común (CMIP) , Elemento de Servicio de Operaciones Remotas (ROSE) , el Protocolo de Aplicación de Capacidades Transaccionales (TCAP), o el Protocolo de Manejo de Red Simple (.SNMP) . La localización de las bases de datos 18-28 puede ser expresada como un código de punto SS7, dirección TCP/IP, o un nombre lógico que es resuelto a uno de éstos. Si la resolución del nombre lógico a la dirección física es requerida, se utiliza la Traducción de Título Global para las redes SS7, y un Servidor de Nombre del Sistema de Nombre de Dominio (D?S) es utilizado en las direcciones TCP/IP. Si se manejan servidores redundantes o múltiples por la dotación lógica informática SCCP SS7, es empleado este mecanismo de superación de fallas. Las bases de datos 18-28 almacenan registros de datos necesarios para llevar a cabo las peticiones de transacción recibidas por los IPs 14. Algunos ejemplos de registros de datos son los registros de datos de Calificación de Llamada (divididos en bases de datos 18 y 20) , los registros de datos de Servicio Global (almacenados en la base de datos 22), y los registros de datos del suscriptor (almacenados en la base de datos 24-28). Se debe notar que una persona experta en la técnica podría reconocer que las bases de datos que contienen registros de datos adicionales podrían ser incorporadas en el sistema 10 de la presente invención. En operación, es enviado un mensaje de petición de transacción a la plataforma de IP 14. La petición de transacción puede ser un llamador que utiliza una tarjeta de llamada, la marcación de un número 800, la verificación del correo de voz, o la realización de alguna otra petición de telecomunicaciones. Un proceso de servidor de IP (no mostrado) dentro de la plataforma 14 de IP recibe la transacción y procesa la transacción. Los pasos del proceso incluyen la contabilidad de la transacción para la replicación a un proceso de servidor de IP en espera, los contadores estadísticos de actualización, las tablas de verificación periódica de funcionamiento, etc., y el acceso a un mapa de base de datos desde la antememoria o la base de datos por omisión, si es necesario. La transacción es convertida al formato de capa de sesión, y transportada vía un canal seleccionado de la red definida 12 del servidor proxy 32-40 de una base de datos relevante 18-28. El IP 14 espera luego una respuesta. Nótese que en el caso general, los servidores dentro de las plataformas de IP 14 no son de línea simple, y pueden manejar cualquier número de peticiones de bases de datos pendientes. El servidor proxy 32-40 recibe la petición de transacción, y descodifica la petición en el formato requerido por la base de datos residente 18-28. Típicamente, ésta es descodificada en campos, y luego se utiliza una interconexión de usuario para el acceso bruto a la base de datos de SQL. Por ejemplo, cuando se utiliza Oracle, se utiliza la interconexión de los programadores OCI . La transacción es luego realizada contra la base de datos. Los resultados de la transacción son luego devueltos al IP 14 después de ser codificados para las capas de transporte y sesión. Se debe notar que un servidor proxy 32-40 puede no estar requerido si el mecanismo de la base de datos 18-28 soporta las transacciones ROSE o TCAP nativamente^ El servidor dentro de la plataforma IP 14 recibe la respuesta, descodifica la respuesta en formatos locales, cubre los campos por omisión (recibidos de la base de datos por omisión 16 y almacenados en la antememoria) para el registro particular al que es accedido, y luego envía la aa transacción completada al proceso de petición dentro de la plataforma IP 14. Con referencia ahora a la Figura 2, se ilustra la relación de las configuraciones y los mapas utilizados por la plataforma de IP 14 para la selección de canal. En general, existen dos configuraciones de servicio, siendo una configuración 42 de servicio por omisión y la otra que es una configuración 44 de servicio DNIS. Cuando se recibe una llamada o petición de dato por la plataforma IP 10 de la presente invención, la plataforma IP 10 manejará la petición de conformidad a la configuración 42 del servicio por omisión o la configuración 44 del servicio DNIS, como se discute en la descripción de las Figuras 4A-4E. La configuración 42 de servicio por omisión y la configuración 44 de servicio DNIS contienen un número de tablas 46-52 de mapa de canales. En operación, la plataforma de IP 10 selecciona la tabla de mapa de canales 46-52 con base en la configuración 42 ó 44 del servicio seleccionado, y el dato recibido proveniente de la llamada que entra o la petición. Las tablas de mapas de canales pueden incluir, pero no están limitadas a, la tabla 46 de mapa de ANI-para-Canal, la tabla 48 del mapa F D de Llamada-para-Canal, la tabla 50 de mapa de DNIS-para-Canal y la tabla 52 del mapa de PIN/Acct/Número-para-Canal . Una tabla 54 de mapa de canales seleccionada contiene el número de canal que corresponde a un registro requerido, una lista de campos remotos asociada con el canal, y una lista de campos por omisión para combinarse con la petición de datos si la petición es campos de datos necesarios, faltantes. El mapa 54 de canales seleccionados también contiene una tabla 56 de configuración de canales que lista el protocolo asociado con cada canal, la dirección del servidor primario SCP/proxy, y la dirección del servidor secundario SCP/proxy. Determinación de Selección de Canal Las Figuras 4A-4E ilustran la determinación de un canal a través del cual encaminar una transacción de base de datos requerida. Como se muestra, las Figuras 4A-4E describen la determinación de un canal en respuesta a una llamada de entrada. Aunque una determinación de canal en respuesta a una acción administrativa requerida, no es mostrada, tal determinación es muy similar a la determinación del canal en respuesta a una llamada de entrada. Antes de describir los diagramas de flujo ilustrados en las Figuras 4A-4E, puede ser útil alguna discusión antecedente. Al recibir una llamada que entra, es cargada una configuración por omisión a partir de una base de datos por omisión en el IP, y el mapa de canales es ajustado a los valores por omisión. La llamada que entra puede ser asociada con un puerto del IP que está configurado para asumir que la llamada es enviada. Esto es requerido para algunas instalaciones que no proporcionan indicaciones de que las llamadas son enviadas. Si el indicador de progreso indica que la llamada es enviada, o directa, el "asumir que la llamada es enviada" anula este ajuste. De otro modo, la indicación de enviada o directa es utilizada, como es suministrada desde la red. La caracte z-ac ?n de enviada a directa de la llamada es importante ya que ésta indica si el DNIS efectivo debe o no ser utilizado para determinar el mapa de canales . Cada llamada de entrada será ya sea un número marcado explícito o implícito. El número marcado puede ser utilizado para determinar una de dos posibilidades. La primera es que ésta concuerde o se ajuste a un suscriptor sobre el sistema. Si ese es el ' caso,, el número marcado "implícito" asociado con el grupo de puerto es utilizado para determinar cuál mapa de canales utilizar. Si el grupo marcado explícito se ajusta a un "número telefónico de inicio de servicio" registrado con la plataforma, entonces se define el servicio de arranque, y el proceso continúa. Frecuentemente, las llamadas llegan después del envío o la redirección desde otro sitio. El número originalmente marcado puede efectivamente representar el "suscriptor" o "número de arranque de servicio". Esta es la manera general en la que se proporcionan los servicios mejorados. De este modo, una llamada al domicilio de los suscriptores queda sin respuesta, y envía al sistema de "mensajería de voz" después de un cierto número de sonidos de campana. La llamada será presentada por la red ya sea un Número de Llamada Original (OCN) o un Número de Redirección, que identifica el número del suscriptor. El canal a utilizar en estos casos será determinado por el número en que la llamada es enviada hacia (el DNIS efectivo) o el número asociado con el puerto de la llamada o entrada ue llega sobre (DNIS implícito) si el DNIS efectivo o implícito se ajusta a una configuración del s.ervicio . Ciertas aplicaciones requieren observación en la fuente de la llamada. Por ejemplo, en las aplicaciones de llamada de débito celular (servicio prepagado), el origen de la llamada (ANI) determina quién está pagando la llamada. De este modo, la ANI representa la cuenta del suscriptor, y el canal determinado ya sea por DNIS explícito o el DNIS implícito. Para permitir que los puertos de entrada sean utilizados para aplicaciones múltiples, el servicio de inicio o arranque puede después de la falla localizar un suscriptor, proporcionar otros servicios para la llamada de entrada. Finalmente, frecuentemente ninguno de los datos suministrados a la red es suficiente para determinar el mapa de canales o el suscriptor. En estos casos, el mapa de canales a utilizar está basado en el DNIS explícito de entrada o el DNIS implicado, y la llamada es respondida. El llamador es luego persuadido a identificarse a sí mismo. El mapa del canal a utilizar es determinado por el DNIS o el DNIS implicado.

Regresando ahora a la Figura 4A, después de la recepción dé una llamada de entrada (paso 100) el IP carga una configuración por omisión y selecciona un mapa de canal por omisión basado en la configuración por omisión (paso 102) . El IP determina luego si éste es programado para asumir que la llamada es enviada (paso 104) . Si es así, el tipo de llamada es ajustado para enviar (paso 106) y el DNIS es verificado para observar si éste se ajusta a una configuración del servicio (paso 108) . Si no es así, el DNIS de la llamada, suministrado por la red, es verificado para observar si éste se ajusta a una configuración de servicio (.paso 108) . Si el DNIS se ajusta a una configuración de servicio, el IP lee el registro de configuración y reemplaza la configuración por omisión (paso 110) . Después de esto, la nueva configuración es verificada para observar si la configuración contiene un mapa de canales a utilizar (paso 112) . Si la configuración contiene un mapa de canales a utilizar, el IP selecciona un mapa de canales para el uso (paso 114) . Como se muestra en la Figura 2 y en las Figuras 4B-4E, el mapa de canales puede trazar en mapa las bases de datos con base en ANI (Figura 4B) , Redirección/OCN (Figura 4C) , o la información DNIS (Figura 4D) suministrada por la llamada que entra, o con base en un PIN, una cuenta, o un número telefónico (Figura 4E) suministrado por el llamador en respuesta a una petición. Enseguida, el IP verifica para observar si la ANI de la llamada que entra corresponde a un suscriptor (paso 116) si la configuración no contiene un mapa de canales para el uso o después de que el IP selecciona un mapa de canales para el uso (ver paso 114) . Si la ANI no corresponde a un suscriptor, el IP procede a través de la rutina ilustrada en la Figura 4B. Si la ANI no corresponde a un suscriptor, el IP procede a través de la rutina ilustrada en la Figura 4C. Regresando ahora a la Figura 4B, el IP observa el mapa de canales (establecido en el paso 114) para determinar si la tabla de mapa de ANI-para-Canal es ajustada para el uso (paso 118). Si la tabla de mapa de ANI-para-Canal no es ajustada para el uso, el intento del IP para acceder a la información del suscriptor (pasos 126 y 28) fallará y el IP procederá a la rutina ilustrada en la Figura 4C. Si la tabla de mapa ANI-para-Canal es ajustada para el uso, el IP buscará la Tabla de mapa de ANI-para-Canal para una entrada que corresponde a la ANI de la llamada que entra (paso 120) . Si la entrada no es localizada, el intento del IP para acceder a la información del suscriptor (pasos 126 y 128) fallará y el IP procederá a la rutina ilustrada en la Figura 4C. Si una entrada es localizada (paso 122), el IP selecciona el canal que se conecta a la base de datos correspondiente al ANI de la llamada que entra (paso 124) . Después de esto, el IP intenta tener acceso a la información del suscriptor vía el canal seleccionado (paso 126) . Si es encontrada la información del suscriptor (paso 128), el IP lleva a cabo la aplicación requerida por la llamada de entrada (paso 130) . Si la información del suscriptor no es encontrada, el IP procede a la rutina ilustrada en la Figura 4C. Regresando ahora a la Figura 4C, el IP determina si la llamada es enviada (paso 132) . Si la llamada no es enviada, el IP procede con la rutina ilustrada en la Figura 4D. Si la llamada es enviada, el IP determina si está disponible la información del número de redirección del número llamado original (OCN) (paso 134). Si no es así, el IP procede con la rutina ilustrada en la Figura 4D. Si es así, el IP observa el mapa de canales (establecido en el paso 114) para determinar si la tabla de mapa de Enviar Llamada-para-Canal es ajustada para el uso (paso 136) . Si la tabla de mapa de Enviar Llamada-para-Canal no es ajustada para el uso, el intento del IP para acceder a un registro del suscriptor (paso 144) fallará y el IP procede con la rutina ilustrada en la Figura 4D. Si la tabla de mapa de Enviar Llamada-para-Canal es ajustada para el uso, el IP buscará la tabla de mapa para una entrada que corresponde al Número de Redirección o el OCN de la llamada que entra (paso 138) . Si no se localiza la entrada, el intento del IP para tener acceso a un registro del suscriptor (paso 144) fallará y el IP procede con la rutina ilustrada en la Figura 4D. Si se localiza una entrada (paso 140), el IP selecciona el canal que se conecta a la base de datos correspondiente al Número de Redirección u OCN de la llamada que entra (paso 142) . Después de esto, el IP intenta tener acceso a un registro del suscriptor vía el canal seleccionado (paso 144) . Si el registro del suscriptor es encontrado, el IP lleva a cabo la aplicación requerida por la llamada que entra (paso 146) . Si el registro del suscriptor no es encontrado, el IP procede a la rutina ilustrada en la Figura 4D.

Con referencia ahora a la Figura 4D, el IP determina si el DNIS fue utilizado para tener acceso a una configuración (paso 148) . Si es así, el IP procede a la rutina ilustrada en la Figura 4E. Si no es así, el IP observa el mapa de canales (establecido en el paso 114) para determinar si la tabla de mapa DNIS-para-Canal es ajustada para el uso (paso 150) . Si la tabla de mapa de DNIS-para-Canal no es ajustada para el uso, el IP es incapaz de tener acceso a un subregistro (paso 158) y el IP procede a la rutina ilustrada en la Figura 4E. Si la tabla de mapa de DNIS-para-Canal es ajustada para el uso, el IP buscará la tabla de mapa DNIS-para-Canal para una entrada que corresponda al DNIS de la llamada que entra (paso 152) . Si no se encuentra la entrada, el IP es incapaz de tener acceso a un subregistro (paso 158) y el IP procede a la rutina ilustrada en la Figura 4E. Si se encuentra una entrada (paso 154), el IP selecciona el canal que conecta la base de datos correspondiente al DNIS de la llamada que entra (paso 156) . Después de esto, el IP intenta tener acceso a un sub-registro vía el canal seleccionado (paso 158). Si el sub-registro es encontrado, el IP lleva a cabo la aplicación requerida por la llamada que entra (paso 160) . Si 4a el registro del suscriptor no es encontrado, el IP procede a la rutina ilustrada en la figura 4E . Con referencia ahora a la Figura 4E, el IP determina si el registro de configuración incluye o no el servicio de impulsar al llamador para un PIN, número de cuenta, y/o número telefónico (paso 162) . Si no es así, el llamador es informado que el número que el llamador ha marcado no está en servicio (paso 164) y el IP se desconecta de la llamada (paso 166) . Si es así, el llamador es impulsado para un PIN, un número de cuenta, y/o un número telefónico (paso 168) . Después de esto, el IP observa el mapa de canales (establecido en el paso 114) para determinar si la tabla de mapa de PIN/cuenta/Número-para-Canal es ajustado para el uso (paso 170) . Si la tabla de mapa de PIN/cuenta/número-para-Canal no es ajustada para el uso, el IP intenta, no exitosamente, tener acceso al registro del suscriptor (paso 178). Si la tabla de mapa de PIN/cuenta/número-para-Canal es ajustada para el uso, el IP buscará la tabla de mapa PIN/cuenta/Número-para-Canal para una entrada que corresponde al PIN/cuenta/Número de la llamada que entra (paso 172) . Si se encuentra una entrada (paso 174), el IP selecciona el canal que conecta la base de datos correspondiente al PIN/cuenta/Número de la llamada que entra (paso 176) . Después de esto, el IP intenta tener acceso a un registro de suscriptores vía el canal seleccionado (paso 178). Si el registro del suscriptor es encontrado, el IP lleva a cabo la aplicación requerida por la llamada que entra (paso 180) . Si el registro del suscriptor no es encontrado, el IP determina cuántos intentos ha realizado el llamador para tener acceso al registro de suscriptores (paso 182) . Si el número de los reintentos no excede un límite predeterminado, el llamador es avisado que el número no está en servicio (paso 186) . Después de esto, el llamador es nuevamente requerido para un PIN, número de Cuenta, o número telefónico (paso 168). No obstante, si el número de reintentos excede un número predeterminado, el usuario es avisado con un gracias por llamar (paso 184) y el IP desconecta la llamada (paso 188) .

Identificación de Registros y Campos La clasificación e identificación de tipos de datos y campos es requerida para proporcionar la base de datos canalizada. La mayoría de las bases de datos requieren resolución campo por campo de las peticiones, donde los campos se ajustan en uno de los tipos definidos en la base de datos. Por ejemplo, si la base de datos fuera una base de datos Oracle 7.2, los números enteros pueden ser convertidos a los tipos DECIMALES como son requeridos por la base de datos externa. El sistema de clasificación e identificación de la presente invención cumple los siguientes obj etivos : 1. permite que el fabricante del IP extienda el número de tipos de registro, infinitamente; 2. permite que el Usuario de IP extienda el número de tipos de registro infinitamente; 3. permite que el fabricante del IP extienda el número y tipos de campos dentro de un registro definido; 4. permite que el Usuario de IP agregue campos definidos por el usuario, a los registros definidos, fabricados, existentes; y 5. permite que el Usuario de Ip agregue campos definidos por el usuario a los registros definidos por el usuario. Con referencia ahora a la Figura 3, es mostrado gráficamente el esquema de identificación.

El diagrama a la izquierda da los detalles de un procedimiento en estructura de árbol para identificar los cuatro elementos requeridos para identificar los campos, y los dos elementos requeridos para identificar los registros. Adicionalmente, el diagrama a la derecha indica cómo es traducido esto en una representación de 24 bitios de la identificación para los campos, y una identificación de 10 bitios para los registros. El primer elemento en la dirección es la Autoridad de Nombramiento de Registro 190. Éste es ajustado a cero cuando el registro es nombrado por el fabricante del IP, y uno cuando el registro es creado para el uso por el usuario/propietario del IP. Esto separa el espacio de nombramiento de registro en dos áreas distintas para prevenir el traslape. Es concebible que el número de bitios que representan la Autoridad de Nombramiento de Registro 190, pudieran ser expandidos para incluir cualquier número de entidades. El segundo elemento es el tipo de registro 192. Cada autoridad de nombramiento puede crear 512 diferentes tipos de registros dentro del IP. Al expandir el número de bitios más allá de nueve, el número de .registros disponibles para la creación de cualquier entidad, podria ser expandido infinitamente . Los primeros dos elementos describen todos los registros únicamente. Los registros son simplemente una colección de campos a los que se puede tener acceso vía las claves búsqueda. No tiene que existir un trazado de mapa uno a uno de los registros de IP a los registros de SCP. El servidor proxy es responsable de devolver los registros IP con base en la petición proveniente del IP. La documentación completa de los registros y campos requeridos sobre el IP, es importante para la interconexión adecuada a las bases de datos SCP. Los siguientes dos elementos describen el campo. Debido a que los campos requieren todos los primeros dos elementos, los campos pueden únicamente ser definidos dentro del alcance de un registro. El primer elemento es la Autoridad de Nombramiento de Campos 194, la cual cuando es ajustada a cero indica que el campo es nombrado y utilizado por el Fabricante de la IP. Cuando se ajusta a 1, el campo es nombrado y utilizado por el Usuario de IP/Propietario del IP. Esto permite que sean insertados campos en el registro, los cuales no son requeridos por el IP, pero pueden ser llevados con el registro y utilizados por la dotación lógica informática de creación de servicio sobre el IP. De este modo, cuando se obtiene un registro del suscriptor, el SCP puede insertar los datos adicionales del suscriptor, no utilizados sobre el IP, y luego los lenguajes de escritura utilizados para crear los flujos de llamada especializados, pueden utilizar este dato. Adicionalmente, este dato puede ser colocado en los registros de facturación de salida generados por los suscriptores, aun cuando el campo de datos sea extraño al sistema de IP. El segundo elemento es el Identificador de Campo 196. Éste identifica el campo dentro del registro. Existen 13 bitios para identificar campos, proporcionando 8192 campos separados dentro de cada registro. Éste podría ser expandido como se requiera. Todos y cada uno de los identificadores de campo se asume que es "inmutable" por la vida del IP: si un campo ya no es requerido para el procesamiento de llamadas sobre el IP, el identificador de campos es retirado, y nunca utilizado nuevamente. Este registro y la convención de nombramiento de campos se requieren para procesar los datos correctamente a partir de los SCP's remotos y las bases de datos elaboradas por muchos fabricantes diferentes. El único método empleado por la presente invención, proporciona ventajas significativas no actualmente utilizadas en el mercado. Éstas incluyen: 1. La provisión de campo infinito y adición de registro para fines lógicos y de facturación, de Creación de Servicio; y 2. La provisión de un mecanismo para manejar versiones disparadas de dotación lógica informática de IP que es servida por el SCP. Debido a que las I.D.'s del campo son inmutables, si los contenidos del campo cambian, se puede asignar una nueva I.D. con los nuevos contenidos .

Clasificación de Tipos de Datos en tipos Universales Con el fin de conectarse a cualquier base de datos, la presente invención ha tomado todos los elementos de datos utilizados en el IP e identificado su tipo de almacenamiento de denominador menos común (mostrado en la Figura 3) . Por ejemplo, el registro del suscriptor tiene un nombre, apellido, departamento, y compañía. Todos estos campos son Secuencias de Texto y comparten muchas, si no es que todas las mismas propiedades. Se han identificado los tipos universales listados enseguida. 1. TEXTO- Una secuencia de texto (ASCII) que es terminada nula "\0". La secuencia es de longitud variable, con una longitud máxima permitida (mostrada en la Figura 6) . 2. TELNUM- Un número telefónico completo.

Cada parte del número es almacenada separadamente. El código de país, el código de área o ciudad, el número, y la extensión de la red privada son todos incluidos. El número es convertible a cualquier formato conocido (mostrado en la Figura 7) . 3. LARGO- Contiene un número entero de 32 bitios (mostrado en la Figura 8) . 4. CORTO- Contiene un número entero de 16 bitios (mostrado en la Figura 9) . 5. BYTE- Contiene un número entero de 8 bitios (mostrado en la Figura 10) . 6. DECIMAL- Contiene un número que tiene un punto decimal. Éstos son almacenados como dos números enteros separados para evitar cualesquiera problemas con las matemáticas de punto flotante (mostrado en la Figura 11) . 7. DB_REFERENCI - Una referencia a otro registro de la base de datos. La referencia puede referirse a la base de datos que existe en una base de datos diferente, y de hecho, muy frecuentemente sí existe (mostrado en la Figura 12).

Elementos de Información Para identificar y contener los tipos de almacenamiento fundamentales anteriores, la presente invención u-t liz-a un contenedor de datos universales llamado un Elemento de Información (IE) 200 (mostrado en la Figura 5) . El IE 200 es un contenedor de datos utilizado por muchos protocolos de telecomunicaciones. Los principios de programación orientados a objetivos son utilizados en el diseño del IE 200. La Clase Base, o fundamento para la bandeja de almacenamiento universal, es la Clase de Elemento de Información. Esta clase, mostrada en la Figura 5, contiene la información base que tiene cada elemento de información. Ésta incluye también los métodos para manejar los elementos de información. La especificación C++ completa para la clase base es mostrada en la Figura 16A-16F. Con referencia ahora a la Figura 5, la Clase del Elemento de Información es la Clase Base para todos los tipos fundamentales almacenados en la base de datos. El IE 200 contiene la información que pertenece al tipo de datos 202, qué campo 204 está en el registro de datos, si el campo actual es indizado 206 en la base de datos de búsqueda, y la longitud de la porción del dato. La información contenida en el IE 200 es utiliziada ara vaciar el dato a la clase apropiada, y utilizar los métodos definidos para esa clase, para llevar a cabo la acción especificada. A partir de la clase base, los contenedores de almacenamiento son derivados para cada uno de los tipos de almacenamiento fundamentales. Son agregados métodos especiales, como sea requerido, para e emplificar, actualizar, ajustar y suprimir estos elementos de datos en/de un registro de datos. Cada uno de los tipos fundamentales contiene métodos específicos para llevar a cabo las acciones requeridas sobre ese dato. Todas las clases fundamentales contienen métodos para ajustar, obtener y mostrar los elementos de datos del miembro. Ciertas clases fundamentales contienen métodos especiales para acceder/actualizar el dato del miembro. La Clase Decimal (mostrada en la Figura 11) es un ejemplo de este tipo. La Clase Decimal contiene un método para ajustar el dato al valor dado, borrando el valor previamente establecido (Ajustar CantidadO) y un método para agregarse al valor numérico previamente establecido (Actualizar CantidadO) . Con referencia ahora a la Figura 6, se ilustra el elemento 209 de la información de texto. El elemento de la información de texto incluye el IE 200, el campo 210 de longitud, y el campo 212 de secuencia. El campo 210 de longitud contiene la longitud máxima permitida para la secuencia definida. El campo de secuencia 212 contiene el dato de caracteres efectivos. Con referencia ahora a la Figura 7, se ilustra el elemento 213 de información de número telefónico. El elemento 213 de información de número telefónico incluye IE 200, el campo 214 del código del país, el campo 216 del código de área, el campo 218 del número telefónico, y un campo de extensión 220. El campo 214 de código de país almacena la porción del código de país del número telefónico como un arreglo de caracteres. El campo 216 de código de área almacena la porción del código del área del número telefónico como un arreglo de caracteres. El campo 218 de número telefónico almacena la porción de número telefónico, del número telefónico como un arreglo de caracteres. El campo de extensión 220 almacena la porción de extensión del número telefónico como un arreglo de caracteres. Con referencia ahora a la Figura 8, se ilustra el elemento 221 de información de número entero de 32 bitlas- El elemento 221 de información de número entero de 32 bitios incluye IE 200 y el campo de valores 222. El campo de valores 222 almacena el dato de longitud larga. Con referencia ahora a la Figura 9, se ilustra el elemento 223 de información de número entero de 16 bitios. El elemento 221 de información de número entero de 16 bitios incluye IE 200 y el campo de valores 224. El campo de valores 224 almacena el dato de longitud corta. Con referencia ahora a la Figura 10, se ilustra el elemento 225 de información de número entero de 8 bitias. El elementa 225 de información de número entero de 8 bitios incluye IE 200 y el campo de valores 226. El campo de valores 226 almacena el dato de longitud de bytes. Con referencia ahora a la Figura 11, se ilustra el elemento 227 de información de la clase decimal. El elemento 227 de información de la clase decimal incluye el IE 200, el campo de número 228 y el campo de fracción 230. El campo de número 228 retiene la porción de un número decimal colocado sobre el lado izquierdo de un punto decimal. El campo de fracción 230 mantiene la porción del número decimal colocada sobre el lado derecho del punto decimal . Con referencia ahora a la Figura 12, se ilustra un elemento 231 de información de Clase de Referencia DB . El elemento 231 de información de Clase de Referencia DB incluye el IE 200, el campo 232 de Cliente/Instancia de Registro, campo 234 de Subclase, y el campo 232 de Instancia. El campo 232 de Cliente/Instancia de Registro mantiene la referencia del cliente en sus primeros 22 bitios y mantiene el tipo de registro en sus últimos 10 bitios. El tipo de registro corresponde al registro de la base de datos señalado por el elemento 231 de información de la clase de referencia DB . El campo 234 de Subclase almacena la subclase del registro de base de datos referido por el elemento de información 231 de la Clase de Referencia DB . El campo de instancia 236 almacena la instancia del registro de la base de datos referido por el elemento de información 231 de la Clase de Referencia DB .

Registros: Grupos de Elementos de Información Cada grupo de elementos de información es llamado registro. Cada registro que es creado es almacenado con la in ormación de identificación respecto a ese registro, y un bloque de Elementos de Información que comprende los elementos individuales efectivos del registro. El registro es también una clase C++.

Clase de Registro DB : El grupo BASE de Elementos de Información Con referencia ahora a la Figura 13, la Clase de Registro DB contiene la instancia 238 del cliente, del mapa de canales asociado con el registro, el tipo de registro 239 del registro, la subclase 240, y la instancia ID 242. Este dato comprende una dirección única para un registro particular. El mapa de canales y el tipo de registro son almacenados en la misma palabra larga; el mapa de canales es almacenado en los primeros 22 bitios y el tipo de registro está en los 10 bitios restantes. La subclase 240 es almacenada en su propia palabra larga; el campo de subclase es la ID única de orden superior para el registro. Éste puede ser utilizado para obtener un valor de agrupamíento, si es requerido, o como una simple extensión del número dirigible. El campo de instancia 242 tiene su propia palabra larga y mantiene la ID única de menor orden para el registro de la base de datos. La combinación de los cuatro campos anteriores hace una clave única a través de la red completa de IP's y SCP's.

Clase de Registro de Datos DB Con referencia ahora a la Figura 14, el Registro de Datos Db 243 es el grupo base de datos clave, junto con un contenedor para elementos de información 200 que van a ser sometidos a transacción. Además de la información heredada de la clase 237 de Registro DB (que sirve también como una clave única) , la Clase de Registro de Dato DB también contiene el tamaño del registro 244 (el tamaño describe únicamente el tamaño del registro de dato efectivo), una ID de continuación 246 (si este campo es ajustado a cero, no existe continuación para el registro actual, de otro modo, la ID de continuación 246 es utilizada para los datos adicionales en cadena sobre el registro base) , un número de versión 248, y el dato de registro efectivo almacenado como un trozo de elementos de información 200 con su dato asociado.

Clase de Transacción DB Con referencia ahora a la Figura 15, el registro 250 de Transacción DB es el contenido efectivo de las transacciones que son pasadas entre los clientes y los servidores. La clase de transacción DB hereda de la clase 243 de Registro de Dato DB y por lo tanto tiene todos sus miembros, así como una bandera 252 que describe qué acción va a ser realizada sobre el 'dato contenido en el Registro de Dato DB . Únicamente las siguientes acciones pueden ser realizadas sobre los registros de datos: crear, leer, actualizar, ajustar, suprimir, y encontrar.

Transacciones La clase de transacción Db es la base para todas las transacciones realizadas por la base de datos. Una transacción es enviada desde el usuario/proceso de petición hacia el servidor IP. La transacción incluye todos los datos necesarios para completar la transacción, y una bandera que describe la acción que va a ser realizada. La clase de Transacción Db proporciona los métodos para pedir transacciones, así como los métodos para realizar la acción adecuada cuando una transacción es recibida por la base de datos. El proceso de usuario/petición crea una transacción con el dato apropiado y llama los métodos correspondientes a la acción deseada. La transacción alcanza la vía daemon SCP/Proxy apropiada vía el servidor IP donde la bandera de transacción es consultada para llamar al método apropiado . Se pueden realizar seis acciones sobre el dato: 1. CREAR: Escribe un nuevo registro a la base de datos. 2. LEER: Lee un registro existente de la base de datos. 3. ACTUALIZAR: Actualiza los campos en un registro existente y modifica cualesquiera claves de búsqueda que han sido modificadas. 4. AJUSTAR: Únicamente disponible para campos que son del tipo Decimal ! esto permite la habilidad para agregar o sustraer de un número decimal. 5. SUPRIMIR: Suprime el registro existente de la base de datos y elimina todas las claves de búsqueda asociadas con el registro a partir de la base de datos de búsqueda. ENCONTRAR: Busca las bases de datos de búsqueda para los registros que se ajustan a la clave de búsqueda. Transacciones de Petición (Lado del Cliente) Petición de Crear Con el fin de enviar una petición de crear a la base de datos, debe ser primeramente creada una transacción. La transacción debe ser creada con el mapa de canales apropiado, el tipo de registro, la subclase, y la instancia, si es conocida. La base de datos asignará una instancia si la instancia es desconocida. Después de que ha sido creada la transacción, los elementos individuales de registro necesitan ser agregados a la transacción. La adición de los elementos individuales se ajustará al tamaño de la transacción adecuadamente. Una vez que todos los elementos de datos han sido agregados, el método apropiado para enviar una petición de crear a la base de datos, es invocado (Crear Registro 0) . Este método ajusta la bandera a "crear", crea el mensaje que va a ser enviado, determina a qué base de datos enviar la petición (utilizando el mapa de canal de datos), envía el mensaje fuera de esa base de datos, y espera una respuesta de la base de datos .

Petición de Leer Una petición de leer requiere que una transacción sea creada con los elementos de la clave única. Estos elementos son el mapa de canales/tipo de registro, la subclase, y la instancia. Una vez que se crea la transacción con esta información, el método para leer de la base de datos (Leer Registro 0) es invocado. Este método ajusta la bandera a "leer", crea el mensaje para enviar, determina a qué base de datos enviar la petición (utilizando el mapa de canal de datos), envía el mensaje fuera de esa base de datos, y espera una respuesta de la base de datos. Si se encontró el registro especificado en la base de datos, ese registro es devuelto. Se debe notar que puede ser utilizada una transacción de encontrar para obtener un registro cuando los elementos de la clave única no son conocidos.

Petición de actualización Con el fin de actualizar un registro existente, se debe crear una transacción con los elementos de la clave única (mapa de canales/tipo de registro, subclase e instancia) que se ajustan al registro deseado. Después de que se crea la transacción, cualesquiera campos que van a ser modificados o cualesquiera nuevos campos que van a ser agregados, deben ser agregados a la transacción. Una vez que todos los elementos de datos deseados han sido agregados, es invocado el método para actualizar un registro (Actualizar Registro 0) . 6 Este método ajusta la bandera a "actualizar", crea el mensaje a enviar, determina a qué base de datos enviar la petición (utilizando el mapa del canal de datos), envía el mensaje fuera de esa base de datos, y espera una respuesta de la base de datos.

Petición de Ajuste Para ajustar un registro existente, debe ser creada una transacción con los elementos de la clave única (mapa de canales/tipo de registro, subclase e instancia) que se ajusta al registro deseado.

Después de que se crea la transacción, cualesquiera campos decimales que van a ser ajustados deben ser agregados para la transacción. Una vez que todos los elementos de datos deseados han sido agregados, es invocado el método para ajustar un registro (Ajustar Registro 0) . Este método ajusta la bandera a "ajustar", crea el mensaje para ser enviado, determina a qué base de datos enviar la petición (utilizando el mapa de canal de datos) , envía el mensaje fuera de esa base de datos y espera una respuesta de la base de datos.

Petición de Suprimir Una petición de suprimir requiere que sea creada una transacción con los elementos de la clave única (mapa de canales/tipo de registro, subclase e instancia) . Una vez que la transacción es creada con esa información, es invocado el método para suprimir de la base de datos (Suprimir Registro 0) . Este método ajusta la bandera a "suprimir", crea el mensaje a enviar, determina a qué base de datos enviar la petición (utilizando el mapa de canales de datos), envía el mensaje fuera de esa base de datos, y espera una respuesta de la base de datos.

Petición de encontrar Una petición de encontrar requiere que sea creada una transacción con una id del mapa de canales. De este modo, un encontrar está limitado a un canal de base de datos conocido. Para buscar un registro en todas las bases de datos, el cliente tiene que realizar una búsqueda para cada canal, y combinar los resultados. Una vez que se crea la transacción, debe ser creado un elemento fundamental que se ajusta al campo deseado a buscar (por ejemplo, un nombre de usuario, apellido, o número telefónico) y es agregado a la transacción. Una vez que el elemento es agregado, el método para encontrar un registro en la base de datos (Encontrar Registro 0) es invocado con un tipo de búsqueda (Parcial o Exacta) , un señalador para un arreglo de n Registros de Db (n igual al número máximo de concordancias permitidas para la petición de encontrar) , el número máximo de concordancias permitidas para ser devueltas para este encuentro, y un señalador para un largo rato almacenar el último registro leído de la base de datos. Este método ajusta la bandera a "encontrar", crea el mensaje a enviar, determina a qué base de datos enviar la petición (utilizando el mapa del canal de datos), envía el mensaje fuera de esa base de datos, y espera una respuesta de la base de datos. Si la petición de encontrar fue exitosa (al menos encontró una concordancia) , el último señalador de registro es ajustado al último registro leído, el o los registros Db que concuerdan encontrados es/son copiados en el señalador asignado para mantener los registros de concordancia, y es devuelto el número de concordancias.

Transacciones de Recepción (Lado del Manejador del Canal de Datos) El manejador del canal de datos recibe las transacciones, y luego con base en el protocolo entre el SCP/Proxy y el DCM, codifica el dato para la transmisión. Antes de que sea enviado el dato, éste es buscado en una lista para la retransmisión después de la falla. Adicionalmente, el estado del servicio del canal es verificado para determinar si la transacción debe proceder. Si el canal está fuera de servicio, la transacción es regresada al enviador con un código de retorno que indica que el servidor de la base de datos está fuera de servicio.

Transacciones de Recepciones (Lado SCP/Proxy) Petición de Crear Cuando una petición de crear entra al SCP/Proxy, el registro es removido de la transacción. Si el tamaño del registro excede aquel del tamaño del registro máximo permitido para la base de datos física, se crea un registro que se ajusta al tamaño permitido, y el dato remanente es almacenado como uno o más registros en la base de datos de sobreflujo. El manejo de cualesquiera relaciones de base de datos o claves de índice es realizado, como sea requerido.

Petición de Lectura Cuando una petición de lectura entra al SCP/Proxy, el registro que concuerda con las claves especificadas, es leído de la base de datos utilizando las herramientas específicas para la base de datos. Por ejemplo, si la base de datos es una base de datos SQL, las peticiones SQL son gestionadas con la base de datos. Si la lectura es exitosa, se realiza una verificación para ver si existe sobreflujo para ese registro. Si existe sobreflujo, el sobreflujo es leído de la base de datos de sobreflujo y agregado al registro ya leído de la base de datos principal.

Petición de actualización Cuando una petición de actualización entra al SCP/Proxy, el registro existente es leído de la base de datos (incluyendo cualquier sobreflujo si está presente) . Los elementos del registro existentes son comparados a aquellos elementos del nuevo registro. Si un elemento en el nuevo registro concuerda con aquél de uno en el registro existente, los contenidos del registro viejo son reemplazados con los contenidos del registro nuevo. Cualesquiera elementos en el nuevo registro que no estaban en el registro existente, son agregados. El registro es luego guardado, agregando cualquier nuevo sobreflujo, como sea necesario.

Petición de Ajuste Cuando una petición de ajuste entra al SCP/Proxy, el registro existente es leído de la base de datos (incluyendo cualquier sobreflujo si está presente) . Los elementos de registro existente son comparados a aquellos elementos del nuevo registro. Si un elemento en el nuevo registro concuerda con uno en el registro existente, los contenidos del nuevo registro son agregados a los contenidos del registro viejo. (La petición de ajuste es únicamente permitida sobre los elementos del tipo Decimal ) . El registro es luego guardado.

Petición de. Suprimir Cuando es recibida una petición de suprimir por el SCP/Proxy, el registro existente es leído de la base de datos (incluyendo cualquier sobreflujo si está presente) . Todo el mantenimiento de índice que es requerido debe ser mantenido para los IE's contenidos dentro del registro. Cualquier sobreflujo asociado en el registro es removido de la base de datos. Finalmente, el registro del dato es removido de la base de datos principal.

Petición de Encontrar Cuando es recibida una petición de encontrar por el SCP/Prox?, una búsqueda apropiada para la base de datos que es utilizada, es construida a partir de los IE's contenidos en la transacción. Si existe una concordancia y el número máximo de concordancias permitidas para esta búsqueda no ha sido excedido, la I.D. del registro de la base de datos, asociada con el registro de búsqueda, es agregada a la lista de los registros que concuerdan, y es incrementado el número de la cuenta de concordancias. Una vez que no más concordancias pueden ser encontradas en la base de datos de búsqueda o ha sido alcanzado un número máximo de concordancias, esa información es regresada al proceso de petición. El proceso recibe de este modo una lista de I.D's únicas que concuerdan.

XCP: Protocolo de Canal Externo El Protocolo de Canal Externo (XCP) es un protocolo de capa de sesión simple construido sobre la parte superior del Protocolo de Control de Transmisión (TCP) que es utilizado para transportar las Peticiones de Transacción de base de datos (DTR's) y sus respuestas entre, por ejemplo, un servidor de IP, un Manejador de Canal de Datos (DCM) , y el servidor proxy (PROXY) , el cual es una interconexión remota, típicamente a una base de datos SQL. Cada par DCM/PROXY tiene únicamente una conexión simple entre ellos, sobre los cuales son transportados paquetes de XCP. Los DTR's son enviados como la parte de dato de un paquete XCP, donde un paquete XCP está constituido de dos partes: el encabezado de XCP y su dato (DTR) . En general, un DTR será justo un objeto de transacción Db suministrado por el proceso de cliente de inicio, y el DCM envuelve justo este paquete XCP y lo envía sobre el PROXY. Con referencia a la Figura 18, se ilustra un paquete 260 XCP representativo. El paquete 260 de XCP contiene un encabezado 262 de XCP y el dato 264 de XCP. Con referencia ahora a la Figura 19, los campos 266 en el encabezado 262 de XCP son ilustrados. El tamaño normal del encabezado 262 de XCP es de 28 bytes (siete campos de cuatro bytes cada uno) . La versión/galleta mágica contiene la galleta mágica XCP (OxdeaddOdO) xor'd con la versión del protocolo XCP que" es utilizado (la versión de protocolo actual es 1). Cada paquete recibido ya sea por DCM o PROXY es verificado utilizando este campo para los problemas de sincronización. Si el campo de paquetes no coincide con el que se esperaba, la conexión actual es cerrada y se abre una nueva. Los paquetes enviados entre los servidores utilizando diferentes versiones, provocarán que la conexión se cierre, y esto será observado como un problema de sincronización. El estado DCM/PROXY contiene el estado ya sea el DCM para los paquetes enviados al PROXY, o el estado del PROXY para los paquetes enviados al DCM.

Con referencia ahora a la figura 20, se ilustran los estados 268 del servidor XCP, válidos, comprendidos por el servidor XCP. Con referencia ahora a la figura 21, se listan los tipos 270 de paquetes XCP válidos. El tipo de paquete indica la naturaleza del paquete enviado/recibido. Ciertos tipos de paquetes pueden ser ignorados por un servidor dado dependiendo del estado del servidor que envía; de manera contraria, algunos pueden ser aplicables únicamente si los servidores están en un estado específico. También, el estado de PROXY puede determinar si el DCM envía o no cualesquiera nuevos DTR's a éste. De este modo, el campo de estado, junto con el campo de clientes se utilizan para implementar el control de flujo rudimentario de paquetes entre DCM y PROXY. El número de secuencias es utilizado para fines de identificación. Cuando DCM envía un DTR a PROXY, éste busca la petición esperando la respuesta. Ya que pueden existir múltiples DTR's pendientes, y el orden en que éstos son respondidos por el PROXY es desconocido, el número de secuencias es utilizado para modificar y equiparar las respuestas a sus peticiones originales. Este es un proceso de concordancia necesario, ya que esta es la petición original que contiene la información respecto al cliente que inició el DTR. La elección de la etiqueta "número de secuencias" es un bitio de una designación errónea ya que los DTR' s no están relacionados uno al otro y no pueden ser hechas garantías respecto a su orden de ejecución PROXY. El campo del número de secuencia debe únicamente ser considerado como un código de identificación para equiparar peticiones con sus respuestas. Este campo también es utilizado para evitar que PROXY ejecute el mismo DTR dos veces. Ya que DCM retransmitirá un paquete si éste se desincroniza, PROXY utiliza este campo para ver si éste está ya actualmente procesando el DTR dado. Si es así, éste ignora el paquete duplicado y el DTR asociado. El campo de clientes de número contiene el número de DTR' s no reconocidos pendientes que el PROXY está deseando manejar. Éste representa el número de paquetes que DCM puede enviar a PROXY que no han sido respondidos todavía. Este valor es negociado por DCM y PROXY durante la fase de unión del establecimiento de la conexión. PROXY puede también cambiar este valor con el fin de lograr algún control de flujo conforme éste lo considera adecuado. (Éste está usualmente basado en el número de clientes que una base de datos SQL asociada puede manejar, o sobre el tiempo de respuesta promedio para manejar un DTR) . El tamaño de dato es el número de bytes de datos en el paquete. El tamaño de datos no incluye el tamaño del encabezado del paquete mismo, de modo que la longitud total del paquete es el tamaño del encabezado (28 bytes) más el valor del campo del tamaño. El valor de este campo puede ser de 0 bytes, lo cual podría indicar un paquete sin datos (por ejemplo, sólo un encabezado), como es el caso, por ejemplo, con un paquete PING. La condición DTR indica el éxito o la falla del acceso/búsqueda de la base de datos. Este valor es pasado luego por el DCM hacia el cliente de inicio de la transacción. El estado de todos los paquetes del DCM al PROXY, es inespecificado, ya que éste no tiene significado en este contexto. La condición o estado es únicamente válida para tipos de paquetes XCP_RSQT_RSP . Con referencia a la Figura 22, las condiciones 272 de XCP válidas, incluidas con la versión 1 de XCP, son listadas .

Establecimiento de una Conexión XCP Con referencia a la Figura 23, el protocolo 276 XCP para establecer una conexión entre DCM 278 y PROXY 280 puede ser mostrado como una serie de paquetes 282 intercambiados, entre servidores y los estados DCM 278 y PROXY 280. PROXY 280 ejecuta una abertura pasiva 284 sobre un puerto TCP (por ejemplo, en enchufes BSD esto podría involucrar una llamada de la función aceptar 0) y actúa como el servidor del par DCM/PROXY. El DCM 278, por otra parte actúa como el fin de la petición o el cliente del par y emite una abertura activa 286 (nuevamente, en los enchufes estilo BSD esto podría ser una llamada para la función conectar 0. La abertura activa 286 ejecutada por DCM 278 es de no bloqueo y regresa inmediatamente antes de la conexión TCP/IP que ha sido necesariamente establecida. Así pues, con el fin de conocer que la conexión TCP/IP está activa, DCM 278 espera para que PROXY 280 envíe el paquete 288 XCP_H0LA. El propósito de este paquete es simplemente dejar que DCM 278 sepa que éste puede ahora escribir a la conexión sin que ocurran cualesquiera errores.

Después de que DCM 278 ha recibido y validado el paquete 288 XCP_HOLA, el DCM 278 y PROXY 280 deben estar en el estada de UNIÓN -. Después de recibir el paquete 288 XCO_HOLA, DCM 278 envía a PROXY 280 un paquete 290 de XCP_UNIÓN. El paquete 290 contiene como uno de los campos de encabezado XCP, el número de clientes que DCM 278 está esperando que maneje PROXY 280. PROXY 280 recibe el paquete 290 XCP_UNIÓN, _y con base en el número máximo de clientes que éste puede manejar y el número requerido de clientes por DCM 278, como es indicado por el paquete 290, PROXY 280 decide sobre los clientes máximos permitidos para esta conexión. Éste devuelve este valor en el paquete 292 XCP_UNIÓN_RSP que envía nuevamente DCM 278. DCM 278 lee ese valor de los clientes a partir del paquete 292 de respuesta de unión y ajusta su valor de clientes en consecuencia. Como lo sugiere este protocolo, PROXY 280 tiene la última palabra sobre el número final de clientes soportados por una conexión dada entre DCM 278 y PROXY 280. Después del paso de unión, ambos procesos deben estar en el estado de LISTO. Existen varios casos cuando una conexión no puede ser establecida; por ejemplo, si los paquetes de unión están corrompidos, PROXY 280 se inactiva, o PROXY 280 y DCM 278 están utilizando diferentes versiones de XCP. Para prevenir que DCM 278 espere indefinidamente, XCP limita el número de intentos que DCM 278 realiza para establecer una conexión exitosa. Después de cada abertura activa, si no ha sido enviado ningún paquete XCP_HOLA por PROXY 280, DCM 278 espera nueve segundos antes de la sincronización. DCM 278 intentará reconectar un total de siete veces para un total de 63 segundos de tiempo transcurrido antes de que DCM 278 asuma que la conexión está permanentemente inactiva. Estos valores fueron elegidos para dar a PROXY 280 suficiente tiempo para leer su abertura pasiva TCP después de un error. Ya que el puerto pudo ser dejado en un estado de TIEMPO_ESPERAR después de un cierre inesperado, los estados de TIEMPO_ESPERAR pueden durar hasta 60 segundos, DCM 278 debe esperar al menos la cantidad de tiempo TIEMPO_ESPERAR. DCM 278 puede también sincronizarse (después de la misma espera de nueve segundos) si la respuesta de unión toma demasiado tiempo, en cuyo caso el proceso es iniciado desde arriba, pero con una conexión menos de reintento disponible. Se debe notar que después que ha sido establecida una conexión exitosa y el aa DCM 278 y PROXY 280 están en el estado de LISTO, la cuenta de reintento de conexión es reajustada a siete, tal que si la conexión es abandonada o necesita ser resincronizada, será realizada una lista completa de intentos. El protocolo de número de clientes es como sigue. Si DCM 278 no tiene cuidado en cuántas peticiones no reconocidas pendientes está procesando PROXY 280, entonces éste envía un cero en el campo de clientes de encabezado XCP. El PROXY 280 puede luego ajustar el número de peticiones no reconocidas a lo que éste desee. Si DCM 278 envía un número positivo en el paquete de unión, el número positivo es tomado como el número máximo de peticiones no reconocidas que el DCM 278 desea dejar pendiente cualquier tiempo dado, y así pues el PROXY 280, está libre de elegir un valor basado en sus propias capacidades, es decir, entre uno y el número máximo. El valor elegido es enviado nuevamente al DCM 278 en el paquete de respuesta. El DCM 278 acepta el valor del cliente de respuesta de unión como el valor final, y ajusta sus parámetros en consecuencia. Se debe notar por este punto que PROXY 280 ha ajustado el valor para el número de clientes a cualquiera que sea el valor final, de modo que DCM 278 necesita sólo registrar el valor para el uso futuro.

Cronómetros XCP u-tiliz-a cuatro diferentes sincronizadores o cronómetros lógicos para mantener su conexión entre DCM y PROXY. Esto se describe más adelante en el orden aproximado de su aparición durante el tiempo de vida de una conexión. Los cuatro cronómetros son utilizados por DCM y no tienen nada que ver con PROXY. DCM es el proceso más activo en establecer la conexión, mientras que PROXY tiende al extremo pasivo de cosas, ya que DCM está a cargo de decidir si el intento de conexión fue o no exitoso. 1. Un cronómetro de establecimiento de conexión arranca cuando el puerto de conexión es abierto por el DCM, por ejemplo, cuando la función Serial_abrirO es llamada o cuando es enviado un paquete XCP_UNIÓN nuevamente por el DCM. Si no es recibida una respuesta (por ejemplo un XCP_HOLA o XCP_UNIÓN_RSP en paquete, respectivamente) dentro de un tiempo especificado (nueve segundos), el establecimiento de la conexión es abortado y reiniciado . El_ i nt ent o de conexión es únicamente reiniciado un total de siete veces antes de que el intento de conexión falle completamente. 2. Un cronómetro de expiración ajustado cada vez que un nuevo DTR es recibido por DCM. Éste es utilizado para llegar al final del intervalo de un DTR si está tomando demasiado tiempo tener un acceso a una base de datos, o si éste ha estado esperando demasiado tiempo sobre una de las búsquedas mantenidas por DCM. Este cronómetro es ajustado a 50 segundos. 3. Un cronómetro de retransmisión es ajustado cuando DCM envía un paquete a PROXY. Si no es recibida una respuesta antes de que expire el cronómetro, el paquete es enviado nuevamente. El valor de este cronómetro (por ejemplo, la cantidad de tiempo que DCM espera para una respuesta) es calculado dinámicamente, con base en los tiempos de ronda de viaje medidos por DCM para los paquetes XCP previos. El valor para este cronómetro es unido por XCP a entre 0.5 y 15 segundos. 4. Un cronómetro de impulso es ajustado cada vez que un paquete es recibido por DCM desde PROXY. Un paquete XCP_IMPULSO es enviado a PROXY para verificar el estado de la conexión y verificar y actualizar el parámetro de los clientes de PROXY. Si otro paquete es recibido de PROXY antes de que el cronómetro de impulso haya expirado, el cronómetro de impulso es reajustado. De este modo, los paquetes de impulso son únicamente transmitidos cuando no está presente otra actividad sobre la conexión. El valor para el cronómetro de impulso es de 25 segundos: si una conexión ha estado inactiva por más de 25 segundos, DCM iniciará a impulsar PROXY para verificar una conexión activa. Parte del propósito de DCM que impulsa a PROXY, es cuando PROXY anuncia el número de clientes como cero, un paquete de algún tipo necesita ser enviado y recibido, de otro modo, DCM nunca obtendrá una actualización del parámetro de los clientes a un valor de no cero, y nunca será capaz de iniciar el nuevo envío de DTR's a PROXY. De este modo, DCM impulsa a PROXY para ver si PROXY ha comenzado a aceptar los DTR's para el procesamiento. Siguiendo una lógica similar, ya que todos los paquetes contienen la misma información en sus encabezados, XCP evita el tráfico de paquetes redundantes al no impulsar PROXY cuando la información está ya disponible de otros paquetes, a saber los paquetes XCP RQST RSP.

Como se mencionó anteriormente, el valor del cronómetro de retransmisión (RTO) es calculado dinámicamente al medir el tiempo de viaje de ida y vuelta (MRTT) de las transmisiones en paquete previamente exitosas y manteniendo el rastreo del estimador de tiempo del viaje de ida y vuelta suavizado (SRTT) y un estimador de desviación media suavizada (VRTT) . Las siguientes ecuaciones se utilizan para actualizar estos estimadores y calcular un valor para RTO: DELTA = MRTT - SRTT SRTT = SRTT + 0.125 * DELTA VRTT = VRTT + 0.25UDELTAI - VRTT) RTO = SRTT + 4 * VRTT Se debe notar que las ecuaciones son parcialmente tomadas de Stevens y Wright' s TCP/IP Illustrated Volumen . DELTA es la diferencia entere el viaje de ida y vuelta medido, recién obtenido (MRTT) y el estimador de tiempo de viaje de ida y vuelta, suavizado, actual (SRTT) . Se utiliza una variación del algoritmo de Jacobson en DCM. Ya sue XCP es un protocolo de capa de sesión basado en la capa de transporte de TCP confiable, no se utiliza respaldo exponencial para la retransmisión. Debido a que se sabe que el paquete es recibido por PROXY, pero que PROXY lo perdió o su ejecución está tomando más tiempo de lo que se esperaba, el valor actual para RTO es utilizado para todas las retransmisiones. En cualquier caso, cuando es recibida una respuesta para un paquete que fue retransmitido, el MRTT para ese paquete no es utilizado para actualizar los estimadores debido al problema de ambigüedad de retransmisión. DCM utiliza integradores de punto fijo para mantener los dos estimadores suavizados SRTT y VRTT. Los integradores de punto fijo evitan los cálculos de punto flotante en el código. Diseño del Servidor DCM El servidor DCM es un diseño concurrente de líneas múltiples. Con referencia a la Figura 25, se muestra un diagrama de flujo de la dotación lógica informática que ilustra las funciones principales llevadas a cabo por los diversas hilos o líneas y las interacciones de los hilos uno con el otro. El servidor DCM tiene tres hilos principales que se comunican a través del uso de dos estructuras de datos compartidas. Los tres hilos principales son el hilo de búsqueda 300, el hilo de escritura 302, y el hilo de lectura 304. Implicadas en el diagrama de flujo están dos búsquedas que son utilizadas para pasar las transacciones Db (DTRs) entre los diferentes hilos de ejecución. Una búsqueda es la búsqueda pendiente donde reside un DTR hasta que éste es escrito hacia el PROXY. La otra búsqueda que es la búsqueda escrita donde un DTR espera hasta que éste es reconocido/respondido por el PROXY. 1. El hilo de búsqueda 300 acepta los 'DTR' s provenientes de los procesos del cliente donde cada transacción Db representa una búsqueda de base de datos. El hilo de búsqueda 300 verifica las condiciones de sobreflujo. Por ejemplo, más de 100 DTRs pendientes sobre la búsqueda pendiente. Si existe una condición de sobreflujo, tal como demasiados DTRs en el sistema, DCM regresa inmediatamente a un estado fallido. De otro modo, si el sistema no está sobrecargado, el hilo 300 de búsqueda agrega el DTR a la búsqueda pendiente para el hilo de escritura 302 para recoger y escribir al PROXY. 2. El hilo de escritura 302 verifica para observar si el PROXY asociado no tiene su cantidad asignada de DTRs pendientes ya transmitidos a éste. aa Esto está basado en el parámetro de los clientes, que fue negociado durante la fase de establecimiento de la conexión previamente descrita. Si PROXY es capaz de aceptar un DTR adicional, el .hilo de escritura 302 envuelve el DTR en un paquete XCP, rellenando los campos de encabezado XCP apropiadamente. El hilo de escritura 302 transmite luego el XCP que contiene el DTR al PROXY para la ej ecución . 3. El hilo de lectura 304 verifica para observar si cualesquiera respuestas han sido regresadas por el PROXY sobre la conexión. Si es así, el hilo de lectura 304 equipara el DTR regresado con aquellos sobre la búsqueda escrita, con base en el número de secuencia DTR's. Si el número de secuencia de DTR no concuerda con ninguno de aquellos sobre la búsqueda escrita, el DTR es descartado. Típicamente, esto sucede únicamente si el DTR sobre la búsqueda escrita ha expirado previamente y no ha sido removido. De otro modo, algunos parámetros del sistema deben ser ajustados (por ejemplo, los estimadores del tiempo de viaje redondo, el valor de sincronización de impulsos, y los parámetros del cliente) y un estado de DCMS_ÉXITO debe ser regresado al proceso del cliente. (Esto es únicamente si el estado de paquete XCP indicó un éxito; La Figura 25 muestra únicamente lo que sucede en el caso esperado y no muestra todos los casos de error) . Si existen cualesquiera DTRs de la búsqueda pendiente esperando hacer escritos, y la búsqueda escrita tiene espacio para ellos, el hilo de escritura 302 debe ser enviado para encenderse de modo que éste puede transmitir hasta el PRQX.Y. Nótese que el tamaño de la búsqueda de escritura y por lo tanto el número de DTRs transmitidos al PROXY sin una respuesta, es igual al parámetro de los clientes, que es incluido en cada encabezado de paquete XCP. Si el PROXY altera este parámetro menor que la búsqueda escrita y el hilo de escritura 302 se están utilizando actualmente, no más DTRs serán movidos a la búsqueda de escritura a partir de la búsqueda pendiente por el hilo de escritura 302 hasta que sean recibidas respuestas suficientes del PROXY para llevar el tamaño de petición escrita hasta un nivel consistente con el nuevo parámetro de los clientes. Esto es cómo un nivel básico del control de flujo es implementado entre DCM y PROXY.

Además de las funciones anteriormente descritas, la búsqueda y los hilos de escritura 300 y 302 también manejan expiraciones sobre los DTRs. El total de tiempo que un DTR puede estar en el sistema DCM-PROXY está limitado a un total de 50 segundos. Si el DTR reside sobre la búsqueda pendiente por más de este tiempo, éste expira y el hilo de búsqueda regresa a un estado DCMS_EXPIRADO al proceso del cliente de inicio. La búsqueda de escritura mantiene rastreo de dos valores de expiración para un DTR dado. Preferentemente, un DTR puede únicamente residir sobre la búsqueda de escritura para un tiempo total igual a 50 segundos, discutido anteriormente, menos el tiempo que el DTR gasta en la búsqueda pendiente. Nuevamente, si el DTR alcanza este tiempo, éste es regresado al cliente de inicio con un estado de DCMS_EXPIRADO. Nótese que el estado DCMS_EXPIRADO es dado al estado genérico DCMS_FALLA en el diagrama de flujo. La búsqueda escrita tiene también un ' valor de expiración de retransmisión el cual, si éste se enciende provoca que el hilo de escritura 302 reescriba el DTR al PROXY. Este valor de expiración de retransmisión es siempre menor que el valor remanente sobre la expiración de anchura del sistema .

Diseño del Servidor SCP/PROXY El servidor PROXY tiene también un diseño concurrente multihilado que se comunica a través del uso de una estructura de datos compartidos. Con referencia ahora a la Figura 26, los tres tiempos principales de hilos del servidor PROXY son mostrados. Los tres hilos son el hilo 306 progenitor/DCM, el hilo 308 progenitor/hijo, y el hilo hij o 310. De manera contraria al diseño del servidor DCM descrito anteriormente, el cual tiene únicamente una copia de cada tipo de hilo activo a un tiempo dado, el diseño PROXY tiene dos hilos lógicos 306 y 308 que tienen únicamente una instancia de sí mismos activa, y un hilo 310 (el hilo hijo) que tiene múltiples copias activas a cualquier tiempo dado. El número de copias activas debe ser igual al parámetro de los clientes que se pasa entre el DCM y PROXY en el encabezado de paquete XCP. El hilo 306 progenitor/DCM escruta la conexión DCM/PROXY para observar si existen cualesquiera XCP de entrada que necesiten procesamiento. El hilo 306 progenitor/DCM lee un paquete XCP de la conexión y verifica las condiciones de sobreflujo y si el paquete recibido es o no un duplicado del paquete previamente enviado. Se debe notar que el DCM controla el número de paquetes enviados con base en el parámetro de los clientes, de modo que ha ocurrido un error serio si un paquete recibido por el hilo progenitor/DCM 306 provoca un sobreflujo. De otro modo, si existe un hilo hijo 310 disponible para procesar la transacción de la base de datos, el paquete es agregado a la búsqueda de espera y colgado al hilo hijo 310 para el procesamiento. El hilo progenitor/hijo 308 escruta el hilo hijo 310 para la respuesta de vuelta a partir del procesamiento de una transacción Db . El hilo progenitor/hi o 308 utiliza el número de secuencia para equiparar la respuesta con el paquete XCP sobre la búsqueda de espera. Si el paquete XCP ha expirado ya, el número de secuencia no se equiparará o concordará con ninguno de los paquetes XCP de espera, y éste será descartado. Si se encuentra una concordancia, el paquete XCP recibido por PROXY tiene su búsqueda DTR reemplazada por la respuesta de DTR de vuelta por el proceso hijo, y el nuevo paquete XCP es devuelto a DCM. El hilo hijo 310 representa las copias múltiples de los clientes de la base de datos que realiza la interconexión efectiva con la base de datos SQL dada. El hilo hijo 310 lee los DTRs a partir del hilo 306 progenitor/DCM, convierte cada DTR a una búsqueda de formato SQL, y busca la base de datos. La respuesta SQL es luego convertida nuevamente al formato de estilo DTR, y el DTR enviado al hilo progenitor/hijo 308. Ademas de las funciones anteriormente descritas, el hilo progenitor/DCM 306 también maneja expiraciones sobre las transacciones Db recibidas. La cantidad total de tiempo que un DTR puede estar en el sistema PROXY está limitado a un total de 45 segundos. Si el DTR reside sobre la búsqueda de espera por más de este tiempo, éste expira y el hilo regresa al paquete XCP con una condición DBT_EXPIRADA al DCM.

Estadística de XCP Con referencia ahora a la Figura 24, se ilustran diversas estadísticas de XCP (dcmstats MEMBER) 274 mantenidas por el DCM en una estructura global dcmtats. DCM incrementa estos contadores en diversas etapas en su ejecución. Estas estadísticas son disponibles a través del uso de las pruebas útiles dcmstats <canal> comando disponibles como parte del equipo servidor IP/DCM. El tiempo de viaje redondo actual (SRTT) y la varianza en SRTT son también mantenidos por DCM por el tiempo de viaje redondo de un DTR como es percibido por el proceso de cliente de inicio, y para el tiempo de viaje redondo de un paquete XCP enviado y recibido entre DCM y el PROXY. La diferencia entre los dos es que el segundo no incluye el tiempo de espera que un DTR puede encontrar antes de que éste sea transmitido al PROXY para la ejecución. Se mantienen dos, diferentes estadísticas SRTT debido a que la primera es una medida más significativa del tiempo de respuesta como se observa por un proceso del cliente, mientras que el segundo es utilizado para calcular el valor utilizado para la expiración y la retransmisión de un paquete XCP hacia el PROXY desde el DCM. Nuevamente, estas variables son accesibles por los programas de prueba útiles. Una descripción general del aparato y método de la presente invención, así como de las modalidades preferidas de ambos ha sido descrita anteriormente. Una persona experta en la técnica reconocerá y será capaz de practicar muchos cambios y muchos aspectos del aparato y del método descrito anteriormente, incluyendo variaciones que caen dentro de las enseñanzas de esta invención.

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

REIVINDICACIONES Habiéndose descrito la invención como antecede, se reclama como propiedad lo contenido en las siguientes reivindicaciones:

1. Un sistema de base de datos, caracterizado porque comprende: al menos un dispositivo periférico inteligente; al menos una base de datos conectada al menos a un dispositivo periférico inteligente, a través de un medio de comunicaciones; una base de datos por omisión conectada al menos a un dispositivo periférico inteligente a través del medio de comunicaciones, la base de datos por omisión contiene el dato de configuración respecto de al menos una base de datos; y al menos un dispositivo periférico inteligente tiene acceso al dato almacenado en al menos una base de datos, al adquirir el dato de la configuración proveniente de la base de datos por omisión y comunicándose con al menos una base de datos de acuerdo con el dato de configuración.

2^ El sistema de base de datos de conformidad con la reivindicación 1, caracterizado porque al menos un dispositivo periférico inteligente es un sistema de computadora.

3. El sistema de base de datos de conformidad con la reivindicación 1, caracterizado porque al menos un dispositivo periférico inteligente es un conmutador de telecomunicaciones.

4. El sistema de base de datos de conformidad con la reivindicación 1, caracterizado porque al menos un dispositivo periférico inteligente tiene acceso al dato almacenado en al menos una base de datos, con base en un mapa de la base de datos derivado del dato de configuración, y una petición de dato recibida por al menos un dispositivo periférico inteligente.

5. El sistema de base de datos de conformidad con la reivindicación 4, caracterizado porque al menos un dispositivo periférico inteligente almacena el mapa de la base de datos en una antememarX-a . 1ÜQ

6. El sistema de base de datos de conformidad con la reivindicación 4, caracterizado porque el mapa de la base de datos es derivado del dato de configuración y un DNIS de una llamada que generó la petición del dato.

7. El sistema de base de datos de conformidad con la reivindicación 4, caracterizado porque el mapa de la base de datos es derivado del dato de configuración y un OCN/Redirección de una llamada que generó la petición del dato.

8. El sistema de base de datos de conformidad con la reivindicación 4, caracterizado porque el mapa de la base de datos es derivado del / dato de configuración y una ANI de una llamada que generó la petición del dato.

. El sistema de base de datos' de conformidad con la reivindicación 4, caracterizado porque el mapa de la base de datos es derivado del dato de configuración y una dirección introducida por un llamador, que inició la petición de dato.

10. El sistema de base de datos de conformidad con la reivindicación 1, caracterizado porque al menos una base de datos es una primera base de datos y una segunda base de datos, teniendo la primera base de datos un protocolo de acceso diferente que la segunda base de datos.

11. El sistema de base de datos de conformidad con la reivindicación 1, caracterizado porque al menos un dispositivo periférico inteligente combina el dato por omisión con el dato que es recuperado de al menos una base de datos accedida tal que el dato por omisión reemplaza cualesquiera campos de datos faltantes en el dato recuperado.

12. El sistema de base de datos de conformidad con la reivindicación 11, caracterizado porque el dato por omisión está contenido en el dato de configuración adquirido por al menos un dispositivo periférico inteligente.

13. Un sistema de base de datos, caracterizado porque comprende: al menos un dispositivo periférico inteligente; una pluralidad de bases de datos conectadas al menos a un dispositivo periférico inteligente a través de un medio de comunicaciones; una base de datos por omisión, conectada al menos a un dispositivo periférico inteligente a través del medio de comunicaciones, la base de datos por omisión contiene los datos de configuración alrededor de la pluralidad de bases de datos; y al menos un dispositivo periférico inteligente tiene acceso al dato almacenado en al menos una de la pluralidad de bases de datos, al adquirir el dato de la configuración de la base de datos por omisión y comunicándose con al menos una de la pluralidad de bases de datos de acuerdo con el dato de configuración.

14, El sistema de base de datos de conformidad con la reivindicación 13, caracterizado porque al menos un dispositivo periférico inteligente es un sistema de computadora.

15. El sistema de base de datos de conformidad con la reivindicación 13, caracterizado porque al menos un dispositivo periférico inteligente es un conmutador de telecomunicaciones.

16. El sistema de base de datos de conformidad con la reivindicación 13, caracterizado porque al menos un dispositivo periférico inteligente tiene acceso al dato almacenado en al menos una de la pluralidad de bases de datos, con base en un mapa de base de datos derivado del dato de configuración y una petición de dato, recibida por al menos un dispositivo periférico inteligente.

17. El sistema de base de datos de conformidad con la reivindicación 16, caracterizado porque al menos un dispositivo periférico inteligente almacena el mapa de la base de datos en una antememari.a .

18. El sistema de base de datos de conformidad con la reivindicación 16, caracterizado porque el mapa de la base de datos es derivado del dato de configuración y un DNIS de una llamada que generó la petición del dato. 1Ü4

19. El sistema de base de datos de conformidad con la reivindicación 16, caracterizado porque el mapa de la base de datos es derivado del dato de configuración y un OCN/Redirección de una llamada que generó la petición del dato.

20. El sistema de base de datos de conformidad con la reivindicación 16, caracterizado porque el mapa de la base de datos es derivado del dato de configuración y una ANI de una llamada que generó la petición del dato.

21. El sistema de base de datos de conformidad con la reivindicación 16, caracterizado porque el mapa de la base de datos es derivado del dato de configuración y una dirección introducida por un llamador, que inició la petición de dato.

22. El sistema de base de datos de conformidad con la reivindicación 13, caracterizado porque la pluralidad de bases de datos incluye al menos dos bases de datos que tienen diferente protocolo de acceso.

23.. El sistema de base de datos de conformidad con la reivindicación 13, caracterizado porque al menos un dispositivo periférico inteligente combina el dato por omisión con el dato que es recuperado de al menos una base de datos accedida de la pluralidad de bases de datos, tal que el dato por omisión reemplaza cualesquiera campos de datos faltantes en el dato recuperado.

24. El sistema de base de datos de conformidad con la reivindicación 23, caracterizado porque el dato por omisión está contenido en el dato de configuración adquirido por al menos un dispositivo periférico inteligente.

25. Un sistema de base de datos canalizado, caracterizado porque comprende: al menos un dispositivo periférico inteligente ; una pluralidad de canales de comunicación conectados al menos a un dispositivo periférico inteligente, cada canal de comunicación está asociado con una base de datos; y un elemento de memoria conectado al menos a un dispositivo periférico inteligente para proporcionar el dato de configuración respecto a la pluralidad de canales de comunicación hacia al menos un dispositivo periférico inteligente tal que al menos dispositivo periférico inteligente puede localizar y tener acceso al dato almacenado en al menos una base de datos asociada con al menos uno de la pluralidad de canales de comunicación.

26. El sistema de base de datos de conformidad con la reivindicación 25, caracterizado porque al menos un dispositivo periférico inteligente es un sistema de computadora.

27. El sistema de base de datos de conformidad con la reivindicación 25, caracterizado porque al menos un dispositivo periférico inteligente es un conmutador de telecomunicaciones.

28. El sistema de base de datos de conformidad con la reivindicación 25, caracterizado porque al menos un dispositivo periférico inteligente tiene acceso al dato almacenado en al menos una base de datos, con base en un mapa de canales derivado del dato de configuración, y una petición de dato recibida por al menos un dispositivo periférico inteligente.

29. El sistema de base de datos de conformidad con la reivindicación 286, caracterizado porque al menos un dispositivo periférico inteligente almacena el mapa de canales en una antememoria .

30. El sistema de base de datos de conformidad con la reivindicación 28, caracterizado porque el mapa de la base de datos es derivado del dato de configuración y un DNIS de una llamada que generó la petición del dato.

31. El sistema de base de datos de, conformidad con la reivindicación 28, caracterizado porque el mapa de la base de datos es derivado del dato de configuración y un OCN/Redirección de una llamada que generó la petición del dato.

32. El sistema de base de datos de conformidad con la reivindicación 28, caracterizado porque el mapa de la base de datos es derivado del aa dato de configuración y una ANI de una llamada que generó la petición del dato.

33. El sistema de base de datos de conformidad con la reivindicación 28, caracterizado porque el mapa de la base de datos es derivado del dato de configuración y una dirección introducida por un llamador, que inició la petición de dato.

34. El sistema de base de datos de conformidad con la reivindicación 25, caracterizado porque al menos una base de datos es una primera base de datos y una segunda base de datos, teniendo la primera base de datos un protocolo de acceso diferente que la segunda base de datos.

35. El sistema de base de datos de conformidad con la reivindicación 25, caracterizado porque al menos un dispositivo periférico inteligente combina el dato por omisión con el dato que es recuperado de al menos una base de datos accedida tal que el dato por omisión reemplaza cualesquiera campos de datos faltantes en el dato recuperado .

36. El sistema de base de datos de conformidad con la reivindicación 35, caracterizado porque el dato por omisión está contenido en el dato de configuración proporcionado por el elemento de memaria.

37. Un método para tener acceso en una pluralidad de bases de datos, caracterizado porque comprende los pasos de: recibir una petición para el dato desde un usuario; tener acceso a una base de datos por omisión para el dato de configuración para la pluralidad de base de datos; derivar un mapa de base de datos a partir del dato requerido, el dato de configuración, y la información del usuario; tener acceso al menos a una base de datos de la pluralidad de bases de datos para el dato requerido, con base en el mapa de la base de datos; la recepción del dato requerido desde al menos una base de datos; y la transmisión del dato requerido hacia el usuario.

38. El método de conformidad con la reivindicación 37, caracterizado porque comprende además el paso de: almacenar el mapa de la base de datos en una antememoria.

39. El método de conformidad con la reivindicación 37, caracterizado porque comprende además el paso de: combinar el dato recibido de al menos una base de datos con el dato por omisión contenido del dato de configuración, para generar el dato requerido.

40. El método de conformidad con la reivindicación 37, caracterizado porque la información del usuario es un DNIS de una llamada proveniente de dicho usuario.

41. El método de conformidad con la reivindicación 37, caracterizado porque la información del usuario es un OCN/Redirección de la llamada proveniente del usuario.

42. El método de conformidad con la reivindicación 37, caracterizado porque la información del usuario es una dirección introducida por el usuario.

43. El método de conformidad con la reivindicación 37, caracterizado porque la información del usuario es el DNIS de una llamada proveniente del usuario.