MXPA97002003A - Un mecanismo de registro de llamada flexible - Google Patents

Abstract

La presente invención demuestra un método y un sistema para un mecanismo de registro flexible en un sistema de telecomunicación, de preferencia a través de software, se hace posible ampliar el sistema son nuevos servicios y datos sin afectar un software de funcionamiento principal que ya existe del sistema usando el principio de media-llamada, almacenamiento de dato en el procesamiento de llamada de la sesión de ejecución por medio de los indicadores de memoria (PTR) en registros asociados con cada sesión ejecutada, estando los indicadores combinados con un elemento de marbete (TAG) por medio del cual los datos localmente almacenados se identificarán de manera singular y pueden, durante la duración de la sesión llamarse selectivamente y almacenarse en la base de datos externa para procesamiento subsecuente.

Description

"UN MECANISMO DE REGISTRO DE LLAMADA FLEXIBLE" CAMPO TÉCNICO La presente invención se refiere a un mecanismo de registro en un sistema de telecomunicación y particularmente a una estructura de datos que permite el registro fácil del dato necesario en un proceso de control de tráfico para una aplicación de telecomunicación.

ANTECEDENTES DE LA INVENCIÓN Durante el procesamiento de una llamada en un sistema de telecomunicación, necesita manejarse o recogerse una gran cantidad de datos. Este dato relacionado con la llamada difiere considerablemente entre llamadas que dependen en que clases de servicios se utilicen en la llamada especifica, cuyos protocolos se usan para comunicarse con las redes circundantes, etc. El dato contiene la información útil para clases diferentes de usuarios del sistema de telecomunicación. Un proveedor de red/servicio puede desear crear registros de facturación mientras que otro desea crear estadísticas de clases diferentes. Puesto que el vendedor desea ser independiente de cuales datos desea utilizar el usuario y todavía ser capaz de añadir nuevos datos junto con un nuevo servicio sin tener que cambiar el software ya existente, este registro del dato relacionado con la llamada tiene que manejarse de una manera eficiente nueva. Existe un número de soluciones posibles para manejar el dato relacionado con la llamada. Una manera evidente es usar una base de datos convencional para recoger la información que rápidamente se convierte en problemas de capacidad. Otras soluciones seleccionaron una solución declarativa en donde se hace una declaración del contenido (v.gr., compare un registro en Pascal). La inconveniencia de una solución declarativa como un registro Pascal es que no presenta la flexibilidad deseada. Todavía otro enfoque es enviar alrededor del dato entre los objetos cuando esto es necesario, lo cual crea duplicación de datos. En el estado actual de la técnica se encuentran distintos conceptos relacionados con estructuras de software orientadas hacia el objeto para procesarse en un sistema de telecomunicación moderno. La Patente Número EP-0 524 089 Al denominada "Structure de logiciel pour systéme de traite ent de données, notamment pour systéme de télécommunications" describe un sistema de estructura lógico para procesar datos, específicamente para sistemas de telecomunicación. La estructura simplifica particularmente la comunicación de tiempo real entre los objetos de acuerdo con las reglas de CCITT X 200. La Patente Número EP-0 524 077 Al denominada "Structure de logiciel pour systéme de traitement d'informations" describe una estructura que oculta las particularidades del sistema de hardware y software a los programas de aplicación. La Patente Número EP-0 470 415 A2 describe un método para suministrar un número de procesadores de aplicación en un acceso de sistema de telefonía a la información relacionada con la llamada en una base de datos común. La información se identifica y se almacena temporalmente como un registro en la base de datos hasta que dure la comunicación. La información está particularmente dirigida para verse directamente en un terminal de presentación para supervisión en un sistema de conmuntación controlado por el operario.

COMPENDIO DE LA INVENCIÓN Por lo tanto, hay una demanda en un sistema de telecomunicación, para crear un mecanismo de registro de llamadas que hace posible ampliar el sistema con nuevos servicios y datos sin afectar un software de funcionamiento que ya existe de un sistema que usa el principio de media-llamada. Un primer objeto de conformidad con la presente invención es, en una sesión de procesamiento de llamada ejecución, llevar a cabo el almacenamiento localmente temporal de datos por medio de indicadores de memoria en los registros asociados con cada sesión ejecutada, estando el indicador además combinado con un elemento de marbete por medio del cual el dato almacenado localmente se identificará de manera singular y puede a través de la duración de una sesión ser llamado selectivamente por una función de objeto de vista de registro y almacenado en una base de datos para procesamiento subsecuente. Un segundo objeto de conformidad con la presente invención es que la sesión especifica está usando un registro de sesión y un registro de transacción para almacenar indicadores y marbetes de objetos y datos, respectivamente en la sesión y desde cuyos registros será posible localizar todos los objetos y datos dentro de la sesión, si el elemento de marbete se conoce bajo el cual se almacena la información de datos deseada. Un tercer objeto de conformidad con la presente invención es que en el procesamiento de llamadas, se define un campo de acción del caso de tráfico que tiene una estructura semejante a un campo de acción de sesión y un registro del caso de tráfico se crea y se hace referencia desde la sesión para almacenar los objetos de ejecución de una llamada y además en el registro en caso de tráfico hay un dato de almacenamiento de registro de transacción que pertenece al caso de tráfico. Un cuarto objeto de conformidad con la presente invención es que los servicios se pueden cambiar en cualquier momento mediante una modificación sencilla de una lista de marbetes almacenada en una base de datos local sin interferir con el sistema total de funcionamiento existente. Un quinto objeto de conformidad con la presente invención es que el elemento de marbete está siendo realizado por un número entero de preferencia como una palabra binaria, asignada de manera singular a cada objeto de ejecución u objeto de dato usado en una sesión.

BREVE DESCRIPCIÓN DE LOS DIBUJOS La invención, junto con los objetos y ventajas adicionales de la misma, puede comprenderse mejor haciendo referencia a la siguiente descripción que se toma junto con los dibujos que se acompañan, en los cuales: La Figura 1 es una ilustración de una sesión que tiene un controlador de sesión, SC, que maneja los distintos casos de tráfico incluyendo para cada caso de tráfico una llamada de origen respectiva, OC, en comunicación con otros casos de tráfico incluyendo una llamada de terminación respectiva, TC; La Figura 2 demuestra un controlador de sesión, SC, que usa de conformidad con el método y sistema de la presente invención, un registro de sesión para almacenar referencias para llevar a cabo los objetos y un registro de transacción para almacenar las referencias a los objetos del dato; La Figura 3 demuestra las colecciones de conformidad con el método y el sistema de la presente invención para almacenar un objeto del caso de tráfico dentro de una llamada de origen, OC; La Figura 4 es una demostración de los objetos que controlan el flujo de datos en una sesión; La Figura 5 demuestra un ejemplo cuando el dato para una base de cargo se extrae de una sesión; La Figura 6 muestra en un ejemplo sencillo la relación entre los objetos administrados creados; La Figura 7 muestra la vista estática completa de conformidad con el ejemplo simple de la Figura 6; La Figura 8 es una gráfica de flujo sencilla de la colección del dato de llamada en un Registro de Transacción durante el procesamiento de la llamada; y La Figura 9 es una gráfica de flujo simple de las especificaciones de los datos para incluirse en una salida.

FUNDAMENTALES Para ser capaces de manejar el objeto de la solicitud presente de una manera eficiente, será práctico definir primero un número de términos técnicos que serán útiles a través de la siguiente descripción. Una manera común para estructurar el software en un sistema de conmutación de procesamiento de llamadas para telefonía es dividir el control de la llamada en dos mitades, una Media-Llamada A y una Media-Llamada B. El software que controla una Media-Llamada está llevándose a cabo en un proceso llamado una Sesión. Una sesión puede manejar uno o varios Casos de Tráfico simultáneamente (por ejemplo en una situación de llamadas múltiples) . El Caso de Tráfico define la funcionalidad y el dato que maneje una llamada en una Sesión. Obsérvese que una llamada de tres partes se maneja mediante dos Casos de Tráfico en una Sesión, una para cada pata la llamada. Por razones de simplificar, la sesión se estructura en campos de acción diferentes y por lo tanto se introduce el Campo de Acción de Sesión y el Campo de Acción de Caso de Tráfico. El Campo de Acción de Sesión se controla mediante el Controlador de Sesión de Flujo de Base, SC. La tarea principal para el controlador de sesión es actuar como un intérprete de mando contra el Protocolo de Acceso, ACP y hacer un análisis de servicio en estos mandos (Mensajes). Esto incluye entonces, por ejemplo, iniciar y terminar los nuevos Casos de Tráfico, distribuyendo la información desde el protocolo de Protocolo de Acceso al Caso de Tráfico correcto, iniciando nuevos servicios, etc. Cada Caso de Tráfico dentro de la Sesión se controla por un flujo de base. Este flujo de base puede ya sea ser una Llamada de Origen, OC o una Llamada de Terminación, TC. La tarea principal para este flujo de base es cuidar el manejo de la llamada básica. Esto incluye, por ejemplo establecer/desconectar una llamada (incluyendo el manejo del Protocolo de Servicio de Telecomunicación, TSP, entre las mitades de llamada) , ordenar el establecimiento/desconexión de las conexiones (por ejemplo una conexión de conversación), y ordenar análisis de información de dirección, etc. Para sustentar los diferentes campos de acción y funcionamiento lógico de control dentro de aquellos, hay necesidad de una estructura de datos semejante. De esta manera, el dato debe estructurarse de cierta manera para hacer posible implementar y mantener las aplicaciones.

Correspondientemente, existen dos tipos diferentes de objetos que en esta descripción se representan como Objetos de Ejecución y Objetos de Datos. Un Objeto de Ejecución ejecutará en la sesión, v.gr., los objetos de control, los objetos de protocolo, los objetos de recurso, etc. Un Objeto de Dato puro contendrá el dato recibido por ejemplo de un Mensaje de Protocolo de Teleservicio. También será posible hacer una salida de este tipo de datos para fines de cargar o de estadística. Los dos tipos de Objetos tiene semánticas diferentes y se almacenan en registros diferentes en las Sesión. A este registro se hace referencia como un Registro de Sesión y se usa para almacenar indicadores para objetos de protocolo y objetos de recurso instalados mediante los objetos de control y de recurso dentro de la Sesión. Los Objetos almacenados en un registro de Sesión son comunes para toda la Sesión. Para almacenar los Objetos de dato puro se usa un Registro de Transacción. De manera semejante, a aquella en que el Registro de Sesión almacena un indicador de los objetos, se usa el Registro de Transacción (llamado también registro de llamada) para almacenar los indicadores hacia los Objetos de Datos puros instalados mediante objetos de control, protocolo y de recurso dentro de la Sesión o un Caso de Tráfico que se ejecuta en la Sesión.

A una vista de usuarios de un Registro de Sesión se hace referencia como una Vista de Registro de Sesión y proporciona al usuario una interfaz hacia el el Registro de Sesión a un nivel de alta abstracción. De manera semejante, una vista de los usuarios de un Registro de Transacción se denomina como la Vista de Registro de Transacción y proporciona al usuario una interfaz hacia el Registro de Transacción a un nivel de abstracción elevado. Finalmente se encuentra también un Registro de Caso de Tráfico que es un registro en donde se almacenan los indicadores hacia los Objetos que pertenecen a un Caso de Tráfico. Solamente los indicadores hcia los Objetos de Protocolo y los Objetos de Recurso se almacenan en este registro. Para almacenar los Objetos de Datos puros debe usarse un Registro de Transacción. Una vista de los usuarios de un registro de Caso de Tráfico se denomina como una vista de Registro de Caso de Tráfico y proporciona al usuario una interfaz hacia el Registro de Sesión a un alto nivel de abstracción.

DESCRIPCIÓN DETALLADA DE LA MODALIDAD PREFERIDA Para sostener los campos de acción diferentes y la lógica de control correspondiente para un procesamiento de llamada en un sistema de telecomunicación, necesitamos una estructura de datos apropiada. El dato debe estructurarse para hacer posible implementar y mantener las aplicaciones. Por lo tanto introducimos dos tipos de objetos diferentes, los objetos de ejecución y los objetos de datos, respectivamente para mantenerse al tanto en una cesión. Estos dos términos que ya se definen en lo que antecede, tienen semánticas diferentes y se almacenan en registros diferentes en la sesión creada. Cuando se almacena un objeto en una colección sólo es cuetión de almacenar un indicador hacia el objeto que va a almacenarse y consecuentemente, no se hace en este paso ninguna duplicación del objeto mismo. Esto implica también que para este almacenamiento del indicador en realidad no hay necesidad de conocer el tamaño del objeto especifico. La Figura 1 es una vista generalizada del alcance de sesión que se controla mediante el controlador de sesión SC. El controlador de sesión está actuando como un intérprete de mando contra el protocolo de acceso ACP, que es el término genérico usado para accesos del abonado o de la red. Como es evidente de la Figura 1, la sesión contiene uno o varios casos de tráfico y aqui la sesión especifica contiene dos casos de tráfico que ambos son del tipo OC (llamada de origen) . Cada uno de los dos casos de tráfico del tipo OC se establece por medio del caso de tráfico respectivo hacia otro caso de tráfico del tipo TC (llamada de terminación) a través de un protocolo de servicio de telecomunicación de manejo, TSP. Como se indica en la Figura 2, hay en el campo de la acción de la sesión un registro de sesión que se usará para almacenar un indicador, PTR, hacia cada objeto de ejecución, por ejemplo a un llamado agente de sesión. El registro de sesión, SR, es por medio de otros indicadores la raiz para la estructura del dato en cada sesión. Los objetos de datos de toda la sesión se encuentran en el registro de transacción por medio de sus indicadores respectivos, PTR. Cada entrada en el registro de sesión tiene un nombre o clave especifico, TAG, que hace posible localizar cualquier objeto dentro del campo de acción de sesión si el operario del sistema especifico conoce el nombre especifico o el TAG. La Figura 3 es una vista generalizada de un campo de acción del caso de tráfico, conteniendo aqui un tipo de llamada de origen, OC, pero un tipo de llamada de terminación, TC, tendría la estructura correspondiente. Este campo de acción tiene que introducirse si la aplicación tiene necesidad de ejecutar un número arbitrario de casos de tráfico paralelos en la sesión. La estructura del campo de acción del caso de tráfico por lo tanto es semejante a aquel del campo de acción de sesión. Para cada caso de tráfico en una sesión se crea un registro de caso de tráfico para almacenar los objetos de ejecución. Al igual que el registro de sesión, se usa un nombre o TAG hacia un indicador PTR. El registro de caso de tráfico correspondientemente se adquiere del registro de sesión. Para almacenar los objetos de datos que pertenecen al caso de tráfico se usa consecuentemente un registro de transacción TR que crea un cuadro para los objetos de datos en este nivel de caso de tráfico. Cada usuario de una seción o registro de caso de tráfico, tiene un objeto de vista propio a través del cual se puede tener acceso a los objetos de ejecución u objetos de dato almacenados . La Figura 4 demuestra en mayor detalle el flujo de datos a través de una sesión que ejecuta una llamada de origen, OC. El flujo de datos comienza cuando cierto dato es recibido por un agente de acceso o el agente de entrada. El dato recibido se convierte en una representación interna AXE. El dato convertido luego se almacena en el registro de transacción, TR. El objeto del dato se almacena con un marbete. El marbete es un entero que se reserva para este objeto de dato especifico. Otros usuarios, v.gr., un Análisis de Aplicación, que necesita el objeto de dato puede recogerse del registro de transacción por medio del marbete y utilizando un objeto de vista de registro de transacción, TR Vista. El ejemplo anteriormente citado también ilustra cuando el dato es enviado mediante el agente de salida a otra Media-Llamada a través del protocolo del servicio de telecomunicación, TSP. El dato es enviado en un parámetro que además del dato contiene el marbete que lo identifica. Como se ha mencionado anteriormente, un objeto de datos se almacena en el registro de transacción (un sinónimo para registro de transacción, es también llamado un registro de llamada) . El registro de transacción, TR, como ya se ha manifestado tiene acceso siempre a través de un objeto de vista. El objeto de vista proporciona al usuario una interfaz de alto nivel hacia TR, que se describirá adicionalmente a continuación. Cada objeto de dato que es almacenado en el registro de transacción se identifica semánticamente por un nombre o clave al cual se hace referencia como TAG. El TAG es un entero en una modalidad de ejemplificación, una modalidad de 16 bit, que se ha reservado para un objeto de dato especifico. Usando un almacenamiento dinámico tal como el registro de transacción, en donde los objetos de datos se almacenan con marbetes, será posible sustentar un mecanismo de salida muy flexible. En otras palabras será extremadamente fácil sin influenciar el funcionamiento general del sistema de telecomunicación, en cualquier periodo de tiempo especifico extraer cualesquiera de los objetos de datos seleccionados a solicitud del usuario para un análisis posterior. Una consecuencia de esto es que será extremadamente fácil añadir servicios adicionales en un sistema que funciona de acuerdo con una manera se funcionamiento estructural. Supongamos que el agente recibe el parámetro "número de la parte que llama" en el protocolo, ACP. El dato se convertirá en una representación interna AXE y se almacenará en TR junto con un marbete dedicado, "AppCallingPartyNumberTag" . Otros usos del TR que necesita el número de la parte que llama puede luego dirigirse hacia TR y preguntar por el objeto de dato que está almacenado con TAG "AppCallingPartyNumberTag". Una Interfaz de Marbetes de Plataforma de Aplicación, ATI, contiene el número de marbetes usados por las funciones. ATI contiene también las reglas que deben seguirse cuando se reservan los nuevos marbetes. Como ya se ha mencionado, el TR siempre tiene acceso a través de un objeto de vista. El objeto de vista tiene dos tareas principales. La primera es presentar una interfaz hecha a medida del cliente hacia TR. Cada usuario de TR debe tener una interfaz dedicada al contenido en el TR. La segunda tarea es actuar como un objeto de mango hacia TR, y el mango asegura que TR no se remueve hasta que se supriman todos los mangos.

Los bojetos de vista también se usan para dar acceso al contenido de los otros dos tipos de registro que existen, el registro de sesión y el registro de caso de tráfico. Como se menciona en lo que antecede una tarea del objeto de vista es proporcionar al usuario con una interfaz hecha a la medida del cliente a un nivel de alta abstracción hacia un registro. La interfaz fabricada a gusto del cliente significa que la interfaz proporciona acceso a los usuarios solamente a los objetos necesarios que deben tener acceso lo cual puede ser solamente una parte del contenido total en un registro. La segunda tarea principal de los objetos de vista hacia el registro de transacción y el registro de caso de tráfico es que actúen como mangos. Siempre y cuando un registro tenga un mango no puede suprimirse. Cuando el último mango hacia un registro se remueve, el registro y todo su contenido también se remueve del almacenamiento de memoria local. Es evidente que esto cree una administración de almacenamiento de memoria local muy conveniente. El mecanismo de salida del registro de llamada ya mencionado se usa para enviar partes del contenido de un registro de transacción para pos-procesamiento. Debe tenerse en cuenta que el contenido del registro de sesión y el registro de caso de tráfico y un registro de transacción están existentes solamente a través de la duración de esa sesión especifica y que desaparecerán cuando se de por terminada la sesión. El mecanismo de salida se construye alrededor de un número de objetos administrados que contienen listas de marbete. En la operación de un sistema de telecomunicación por ejemplo hay una necesidad para cobrar el dato de cargo para ser capaces de facturar correctamente a los abonados diferentes. En la Figura 5 se ejemplifica lo que puede llevarse a cabo en una sesión. Un objeto de control "Carga" ha abierto un objeto Cro_Type. Este objeto Cro-Type especifico contiene una lista de Marbetes que se recogen de la base de datos representando los objetos de datos que van a extraerse del registro de transacción. El Cro_Type luego es ordenado de recopilar un informe que consiste de los objetos de dato identificados por la lista de marbetes que se almacena en la base de datos. El objeto de control luego usa la interfaz Cro_Type para ordenar que recoja el dato durante la existencia de la sesión especifica. El dato puede empacarse en un área de datos que se enviará a un nodulo de pos-procesamiento. Consecuentemente, una base de cargo debida a servicios aumentados puede cambiarse en cualquier momento mediante una modificación sencilla de la lista de marbetes sin interferir con el sistema existente que tiene una estructura de conformidad con la presente invención.

El resultado efectivo de esto es que aún cuando el contenido de las diferentes sesiones se definan como un dato local, es posible hacer uso simultáneo de partes deseadas del contenido como si constituyera el dato global. Una diferencia entre el dato local y global por ejemplo es que el último necesariamente tiene que asignarse normalmente en ubicaciones de memoria predeterminadas para ser capaz de dar acceso a otros usuarios. En la modalidad ilustrativa usamos tres tipos de objetos administrados para efectuar el mecanismo de salida flexible descrito aqui. Se representan como CroServiceTemplate, CroType y Cro-CustomerTemplate. El primer tipo de objeto administrado, el CroServiceTemplate se usa para la especificación del cuales objetos de datos son posibles de extraer para un servicio básico o suplementario especifico. El CroServiceTemplate contiene un atributo los TAG posibles que representan cual dato es posible de extraer del registro de transacción, TR, para un servicio especifico, por ejemplo, en este contexto una "Llamada Básica" o una "Llamada de Tres Partes". El segundo tipo de objeto administrado es CroType que se usa para especificación de un cierto tipo de salida. Cada caso de CroType se conecta con uno o más casos de CroServiceTemplate. La unión del dato en estos CroServiceTemplates determina que dato es posible enviar para un CroType especifico. El tipo de objeto administrado tercero y último es el CroCustomerTemplate, que es un objeto administrado que retiene la información de cual dato debe extraerse para un cliente especifico en un tipo de salida especifico CroType. La Figura 6 demuestra un ejemplo pequeño que tiene las condiciones: - Hay dos clientes, A y B Hay dos servicios, "Llamada Básica" y "Llamada de Tres Partes" . Hay dos CroTypes, CroType 1 y Crotype 2. Debido a que hay dos servicios necesitamos dos CroServiceTemplates: Llamada Básica de CroServiceTemplate, que contiene los Marbetes 1, 2, 5 y 8. Llamada de Tres Partes CroServiceTemplate, que contiene los Marbetes 1, 2, 6 y 9. Esto significa que para la "Llamada Básica" podemos enviar el dato almacenado en TR que tiene los Marbetes 1, 2, 5 y 8, mientras que para el servicio "Llamada de Tres Partes" podemos enviar el dato almacenado bajo los marbetes 1, 2, 6 y 9.

Luego, definimos dos tipos de salida, CroType 1 designado de tal manera que es capaz de dar salida al dato relacionado con ambos servicios y CroType designado de tal manera que será capaz de dar salida al dato relacionado con la Llamada Básica. En la Figura 6 se visualiza la estructura básica y la relación entre el objeto adminsitrado creado. Se requiere una CroCustomerTemplate para cada cliente y un CroType para hacer el mecanismo de salida "Salida de Registro de Llamada", CRO, capaz de llevar a cabo salidas de todos los CroTypes a todos los clientes. Esto da por resultado en este ejemplo un total de cuatro CroCustomerTemplates . En la Figura 7 se demuestra la estructura resultante. El cliente A requiere todos los marbetes posibles de Crotype 1 y el Marbete número 1 y 2 de CroType 2 y el cliente B requiere todos los Marbetes con un número menor de 8 de todos los CroTypes. Nosotros, entonces tenemos una estructura final en donde el mecanismo de salida CRO necesita hacer una distribución apropiada. Hemos especificado cuales campos de datos necesitan todos los diferentes clientes de todos los CroTypes diferentes. Una parte final del flujo de datos en la Figura 4 describe cuando el dato será enviado a otra Media-Llamada. Las Medias-Llamadas se comunican por medio del Protocolo de Servicio de Telecomunicación, TSP. El TSP lleva parámetros auto-identificadores . Un parámetro contiene un objeto de dato y se identifica mediante un marbete. El receptor puede determinar cual dato es recibido mirando el marbete. El marbete que se usa para identificar un parámetro en el TSP es el mismo marbete usado para identificar un dato almacenado en TR. En la Figura 8 se resume un número de pasos en una gráfica de flujo sencilla de una recolección de datos de llamada en un Registro de Transacción durante el procesamiento de llamada. Este procesamiento se inicia en un paso 100. En el primer paso 101 real del proceso, es recibido un mensaje a través de un protocolo externo. Es recibido en un agente de protocolo dentro de un proceso dinámico dentro del sistema. Luego en un paso 102, el dato se convierte desde una representación externa a una representación interna. Un Objeto del Dato se crea dentro de este proceso dinámico. Este Objeto de Dato luego contiene la representación interna del dato recibido. En un tercer paso 103, el Objeto de Datos se almacena bajo un elemento de marbete singular en un registro de transacción. Durante la llamada el dato de procesamiento se recoge en un cuarto paso 104 desde el registro de transacción usando un objeto de vista del registro de transacción y utilizando luego el elemento de marbete para obtener el indicador correcto PTR para recuperar el dato especificado. Cuando la llamada termina o cuando una salida del dato de llamada se desea para fines estadísticos o de cargo, la salida de registro de llamada de función se llama en un quinto paso 105. Esta función presta acceso a la base de datos para encontrar cual es el dato que se debe enviar. Como resultado la función obtiene una lista de elementos de marbete. El dato deseado se recoge de TR en el paso 104 y se coloca en una memoria intermedia de salida. Esta memoria intermedia luego se envia a un medio externo. El dato puede posteriormente pos-procesarse a fin de que por ejemplo, produzca la información de facturación, etc. Finalmente, en la Figura 9 se muestra por medio de tres pasos una gráfica de flujo sencilla una especificación del dato que debe incluirse en una salida. El procedimiento comienza en un paso 200. En un paso 201 el proveedor del servicio o cualquier otro operario que administre el sistema decide que dato debe ser enviado para tipos de llamada diferente. Estos tipos de salida diferentes se especifican en un segundo paso 202 llenando las plantillas con vistas de marbetes que se deben enviar. En un paso 203 final, estas plantillas se almacenan en la base de datos mediante por ejemplo admitiendo la lista de marbetes por medio de un terminal separado y/o un teclado.

Esta lista admitida de marbetes posteriormente se prestan de acceso durante el procesamiento de la llamada. La admisión de la lista de marbetes no interferirá con el procesamiento de llamada general en el sistema de telecomunicación para iniciar y dar por terminados los casos de tráfico, distribuyendo la información desde el protocolo de acceso al caso de tráfico correcto, iniciando nuevos servicios, etc., pero cuando se admiten decidirá cual dato debe almacenarse en la base de datos para pos-procesamiento. Se comprenderá por aquellas personas expertas en la técnica que pueden hacerse en la presente invención varias modificaciones y cambios sin desviarse del espíritu y alcance de la misma, que se define mediante las reivindicaciones anexas.

Claims (12)

REIVINDICACIONES ;

1. Un método para un mecanismo de registro de llamadas flexible en un sistema de telefonía o telecomunicación, que hace posible ampliar el sistema con nuevos servicios y datos sin afectar un software de funcionamiento principal ya existente del sistema usando el principio de media-llamada, caracterizado porque al tiempo de la ejecución de un procesamiento de llamada de sesión, el almacenamiento temporal localmente del dato se lleva a cabo por medio de indicadores de memoria (PTR) en los registros (SR, TR) asociados con cada sesión ejecutada, el indicador (PTR) se combina además con un elemento de marbete (TAG) por medio del cual el dato localmente almacenado deseado especifico se identificará de manera singular y puede durante la duración de la sesión ser llamado selectivamente por una función de objeto de vista de registro y almacenado subsecuentemente en una base de datos externa para procesamiento subsecuente.

2. El método de conformidad con la reivindicación 1, caracterizado porque la sesión especifica utiliza un registro de sesión (SR) y un registro de transacción (TR) para almacenar los indicadores (PTR) y marbetes (TAG) de objetos y datos, respectivamente, en la citada sesión, y desde cuyos registros será posible durante la existencia de la sesión extraer cualesquiera de los objetos o datos dentro de la sesión, si el elemento de marbete (TAG) se conoce bajo el cual está siendo almacenada la información de datos deseada.

3. El método de conformidad con la reivindicación 2, caracterizado porque el procesamiento de llamada se define como un campo de acción del caso de tráfico que tiene una estructura semejante al campo de acción de sesión y se hace referencia a un registro del caso de tráfico desde el registro de sesión (SR) y se crea un registro de caso del tráfico para almacenar los objetos de ejecución de una llamada.

4. El método de conformidad con la reivindicación 2, caracterizado porque en el registro del caso de tráfico un registro de transacción (TR) almacena los datos que pertenecen al caso de tráfico.

5. El método de conformidad con la reivindicación 4, caracterizado porque los servicios se pueden cambiar en cualquier momento mediante modificación sencilla de una lista de marbetes almacenada en una base de datos local sin interferir con el sistema total de funcionamiento existente.

6. El método de conformidad con la reivindicación 5, caracterizado porque el elemento de marbete (TAG) se realiza mediante un número entero, de preferencia como una palabra binaria, asignada de manera singular a cada objeto de ejecución u objeto de datos que vaya a almacenarse.

7. Un mecanismo de registro de llamadas para un sistema de telefonía o telecomunicación que hace posible ampliar el sistema con nuevos servicios y datos sin afectar un software de funcionamiento principal que ya existe del sistema usando el principio de media-llamada caracterizado porque mediante un indicador de memoria (PTR) los objetos de sesión temporales localmente o los datos se almacenan en registros asociados con cada sesión ejecutada en el procesamiento de llamada de ejecución, el indicador (PTR) se combina además con un elemento de marbete (TAG) por medio del cual los datos localmente almacenados temporalmente deseados específicos se identificarán de manera singular y pueden durante la duración de una sesión ser llamados selectivamente por una función del objeto de vista de registro y almacenados subsecuentemente en una base de datos externa para procesamiento subsecuente.

8. El sistema de conformidad con la reivindicación 7, caracterizado porque la sesión especifica utiliza un registro de sesión (SR) y un registro de transacción (TR) para almacenar indicadores (PTR) y marbetes (TAG) de objetos y datos, respectivamente en la sesión y desde cuyo registro durante la existencia de la sesión será posible extraer cualesquiera de los objetos y datos dentro de la sesión, si el elemento de marbete (TAG) se conoce bajo el cual está siendo almacenada la información de datos deseada.

9. El sistema de conformidaed con la reivindicación 8, caracterizado porque un campo de acción del caso de tráfico tiene una estructura semejante al campo de acción de la sesión y se hace referencia a un registro en el caso de tráfico desde el registro de sesión y el registro de caso de tráfico se crea para almacenar los objetos de ejecución de llamada.

10. El sistema de conformidad con la reivindicación 9, caracterizado porque el registro del caso de tráfico, un registro de transacción (TR) almacena los datos que pertenecen al caso de tráfico.

11. El sistema de conformidad con la reivindicación 10, caracterizado porque los servicios se pueden cambiar en cualquier momento mediante una modificación sencilla de la lista de marbetes almacenada en una base de datos local sin interferir con el sistema total de funcionamiento existente.

12. El sistema de conformidad con la reivindicación 11, caracterizado porque el elemento de marbete (TAG) se realiza mediante un número entero, de preferencia como una palabra binaria, asignada de manera singular a cada objeto de ejecución u objeto de datos que vaya a almacenarse.