ES2409530B1

ES2409530B1 - Método para gestionar el reconocimiento del habla de llamadas de audio

Info

Publication number: ES2409530B1
Application number: ES201131647A
Authority: ES
Inventors: Miguel Ángel SANTIAGO; Diego URDIALES; Isabel ORDÁS
Original assignee: Telefonica SA
Current assignee: Telefonica SA
Priority date: 2011-10-14
Filing date: 2011-10-14
Publication date: 2014-05-14
Anticipated expiration: 2031-10-14
Also published as: ES2409530R1; ES2409530A2; WO2013053798A1

Abstract

Método para gestionar el reconocimiento del habla de llamadas de audio.#En el método de la invención dichas llamadas de audio se realizan en un sistema basado en protocolo de control de recursos de medios, o MRCP, y dicho reconocimiento del habla se lleva a cabo por un motor ASR controlado por un servidor de MRCP buscando una coincidencia entre un flujo de audio generado por un usuario y una gramática compilada.#El método se caracteriza porque comprende realizar dicho reconocimiento del habla de manera continua enviando, dicho servidor de MRCP, eventos regularmente a dicho usuario cuando se producen coincidencias, indicando cada uno de dichos eventos un resultado parcial de dicho reconocimiento del habla e ignorando coincidencias insatisfactorias, deteniendo dicho reconocimiento del habla cuando se recibe una petición de detención desde dicho usuario o cuando dicho flujo de audio finaliza.

Description

Método para gestionar el reconocimiento del habla de llamadas de audio

Campo de la técnica

La presente invención se refiere, en general, a un método para gestionar el reconocimiento del habla de llamadas de audio, realizándose dichas llamadas de audio en un sistema basado en un protocolo de control de recursos de medios, o MRCP, llevándose a cabo dicho reconocimiento del habla por un motor ASR controlado por un servidor de MRCP buscando una coincidencia entre un flujo de audio generado por un usuario y una gramática compilada, y más concretamente a un método que comprende realizar dicho reconocimiento del habla de manera continua enviando, dicho servidor de MRCP, eventos regularmente a dicho usuario cuando se producen coincidencias, indicando cada uno de dichos eventos un resultado parcial de dicho reconocimiento del habla e ignorando las coincidencias insatisfactorias, deteniendo dicho reconocimiento del habla cuando se recibe una petición de detención desde dicho usuario o cuando dicho flujo de audio finaliza.

Estado de la técnica anterior

Uno de los usos principales del reconocimiento del habla hasta ahora han sido los sistemas de IVR (Respuesta de Voz Interactiva). Los centros de llamadas usan sistemas de IVR para reducir costes, automatizando la gestión de peticiones de cliente. Para realizar esto, es necesario capturar el habla y luego procesarla mediante un motor ASR (Reconocimiento del Habla Automático). El ASR analiza el habla y produce una coincidencia si algo se ha detectado.

El motor ASR requiere una gramática para procesar el habla. Esta gramática contiene un conjunto limitado de palabras u oraciones esperadas. Los resultados son coincidentes sólo si la persona que habla dice algún elemento de la lista. Los resultados se analizan programáticamente y el sistema se comportará de una u otra manera dependiendo de ellos.

Para interactuar con un motor de reconocimiento del habla, el IETF define un protocolo denominado protocolo de control de recursos de medios (MRCP). El MRCP se describe en la RFC 4463 [1]. Este protocolo controla recursos de servicio de medios como sintetizadores de habla, reconocedores, etc. Tal como se define en esta RFC, el MRCP usa el RTSP como protocolo de control de sesión. Actualmente, hay un borrador para especificar el MRCP que usa el SIP (MRCP versión 2 [2]).

Con respecto a la arquitectura de MRCP, tal como se mostrará en la figura 1, consiste en un cliente que requiere flujos de medios generados (reconocedores) o necesita flujos de medios procesados (sintetizadores) y un servidor que tenga los recursos o dispositivos para procesar (reconocedores) o generar (sintetizadores) los flujos.

El cliente establece una sesión de control con el servidor para el procesamiento de medios usando un protocolo tal como RTSP (MRCPv1) o SIP (MRCPv2). Esto también configurará y establecerá el flujo de RTP entre el cliente y el servidor u otro punto de extremo de RTP.

El conjunto de mensajes de MRCP consiste en peticiones del cliente para el servidor, las respuestas del servidor al cliente y eventos asíncronos del servidor al cliente.

La figura 2 mostrará el intercambio de mensajes, tanto para sesiones de SIP como de MRCP. Inicialmente, el cliente de MRCPv2 (21) envía el SIP INVITE (211) al servidor de MRCPv2 (22) para establecer la sesión, indicando el tipo de recurso de servidor requerido (a=resource:speechrecog). El servidor de MRCPv2 debe responder con el identificador de canal completo y el puerto de TCP al que deben enviarse los mensajes de MRCPv2 (221).

SET-PARAMS (213) es un método que lleva un conjunto de parámetros en la cabecera para configurar el motor ASR. La respuesta del servidor al cliente cuando se ha configurado el ASR es 200 COMPLETE (222).

El método DEFINE-GRAMMAR (214), del cliente al servidor, proporciona una o más gramáticas y solicita al servidor acceder a, recoger y compilar las gramáticas que se necesitan. La respuesta del servidor al cliente cuando se ha realizado esto es 200 COMPLETE (223).

El método RECOGNIZE (215) solicita al recurso de reconocedor que comience el reconocimiento. La petición RECOGNIZE usa el cuerpo de mensaje para especificar las gramáticas aplicables a la petición. El MRCPv2 debe enviar la respuesta 200 IN-PROGRESS (224) para informar al cliente de MRCPv2 de que el reconocimiento acaba de comenzar.

START-OF-INPUT (225) es un evento del servidor al cliente que indica que el recurso de reconocimiento ha detectado habla.

RECOGNITION-COMPLETE (226) es un evento del recurso de reconocedor al cliente que indica que el reconocimiento se ha completado. El resultado de reconocimiento se envía en el cuerpo del mensaje de MRCPv2.

El método “STOP” (216) del cliente al servidor indica al recurso que detenga el reconocimiento si una petición está activa. El servidor confirma el fin del reconocimiento con 200 COMPLETE (227).

Finalmente, puesto que el canal de MRCPv2 ya no se usa, también puede finalizarse la sesión SIP (217, 228, 218).

Hay 2 modos de operación soportados para reconocimiento:

-: Reconocimiento de modo normal: intenta hacer coincidir todo el habla contra la gramática y devuelve un estado de no coincidencia si la entrada no coincide o se supera el límite de tiempo del método.

-: Reconocimiento de modo de palabras activas: el reconocedor busca una coincidencia con la gramática de habla específica e ignora el habla que no coincide. El reconocimiento se completa sólo para una coincidencia satisfactoria de gramática o si el cliente cancela la petición o si hay un límite de tiempo sin entrada o del reconocimiento.

Hay unos cuantos parámetros que pueden enviarse al servidor de MRCP dentro de las peticiones RECOGNIZE

(215) o SET-PARAMS (213) incluyendo sus valores en los campos de cabecera. Esos valores se usan para configurar el motor ASR y prepararlo para el reconocimiento. Por ejemplo, normalmente se usan valores de configuración tales como umbral de confianza, nivel de sensibilidad, etc. Los parámetros relacionados con los límites de tiempo que podrían ser significativos son los siguientes:

-: Límite de tiempo sin entrada: indica cuando se inicia el reconocimiento y no hay habla detectada durante un determinado periodo de tiempo. En ese caso, el reconocedor envía un evento RECOGNITION-COMPLETE al cliente y termina la operación de reconocimiento.

-: Límite de tiempo del reconocimiento: indica cuando se inicia el reconocimiento y no hay coincidencia durante un determinado periodo de tiempo. En ese caso, el reconocedor envía un evento RECOGNITION-COMPLETE al cliente y termina la operación de reconocimiento.

-: Límite de tiempo de habla completada: indica la longitud de silencio requerida tras el habla de usuario antes de que el reconocedor del habla finalice un resultado (o bien aceptándolo o bien generando un evento de no coincidencia).

-: Límite de tiempo de habla no completada: indica la longitud de silencio tras el habla de usuario después del cual un reconocedor finaliza un resultado. Una vez que se ha disparado el límite de tiempo, se rechaza el resultado parcial.

-: Duración máxima de palabras activas: indica la longitud máxima de unidad de habla que se considerará para el reconocimiento de palabras activas.

-: Duración en minutos de palabras activas: indica la longitud mínima de unidad de habla que se considerará para el reconocimiento de palabras activas.

Tal como se describió anteriormente, los recursos de medios que proporcionan una funcionalidad de reconocimiento del habla, tal como servidores de procesamiento del habla en IVR, se controlan a través de un protocolo convencional denominado MRCP. Este protocolo soporta 2 modos de reconocimiento diferentes, en los que un flujo de audio se hace coincidir con una gramática predefinida para producir un resultado de reconocimiento. Estos modos se seleccionan para aplicaciones con flujos de audio cortos y limitados, tal como la conversación que una persona mantiene con una máquina. Ninguno de los modos de operación existentes soporta flujos de audio de longitud arbitraria, tales como los que suceden en una conversación de persona a persona, que requieren un lazo continuo de peticiones de reconocimiento que no se controla de manera óptima.

De hecho, determinadas aplicaciones exigen que, durante una conversación de persona a persona, los resultados del reconocimiento aparezcan en tiempo real o al menos cuando la conversación aún sigue en curso. Para este propósito, los modos de reconocimiento del protocolo actual fuerzan un proceso de reconocimiento intermitente con iteraciones de petición-respuesta. No hay ningún mecanismo en el protocolo para controlar un recurso de medios de modo que pueda producir resultados de reconocimiento parcial continuos durante el transcurso del flujo.

Además, las gramáticas que van a aplicarse para el reconocimiento se cargan al principio de un proceso de reconocimiento y no pueden cambiarse hasta que este proceso termine. Sin embargo, en conversaciones naturales entre dos hablantes, las variaciones en los temas del contenido pueden requerir adaptación de las gramáticas durante la llamada. En tales casos, la posibilidad de cargar/descargar dinámicamente gramáticas es muy útil, pero no está cubierta por el protocolo MRCP actual.

Entrando en mayor detalle en la memoria descriptiva proporcionada por el IETF, el servidor de MRCPv2 se comporta tal como se representa en la siguiente máquina de estados (figura 3).

Estando en un estado IDLE (31), cuando una petición RECOGNIZE (312) llega del cliente, el estado cambia a RECOGNIZING STATE (32). Cuando el reconocedor produce un resultado de coincidencia, se envía un evento RECOGNITION-COMPLETE (321) al cliente y el estado pasa a RECOGNIZED (33). Esto significa que el proceso de reconocimiento ha terminado y que el cliente necesita comenzar de nuevo el proceso para continuar el reconocimiento, comenzar de nuevo con un mensaje DEFINE-GRAMMAR (311) y una petición RECOGNIZE (312).

Para los casos de uso mencionados anteriormente, se requiere un procedimiento más eficaz para tratar con las gramáticas dinámicas y el reconocimiento continuo, ya que el protocolo MRCP actual establece que el cliente necesita enviar una petición RECOGNIZE para comenzar de nuevo la máquina de estados después de cada resultado devuelto. Además, el método DEFINE-GRAMMAR (311) sólo se permite en el estado IDLE (31), y no mientras está en el estado RECOGNIZING (32).

Por otro lado, una comunicación de persona a persona implica 2 canales, una por cada parte, mientras que los sistemas de IVR tradicionales involucran sólo uno. El protocolo MRCP gestiona cada canal como una sesión independiente y deja que el lado del cliente rastree los resultados para cada canal. Se requiere la capacidad de cargar gramáticas dinámicas para adaptar el proceso de reconocimiento dependiendo de los resultados obtenidos por cada parte.

Descripción de la invención

Es necesario ofrecer una alternativa al estado de la técnica que cubra las lagunas que se encuentran en la misma, particularmente en relación con la falta de propuestas que realmente permitan realizar un reconocimiento del habla de flujos de audio de longitud arbitraria, en tiempo real o tiempo casi real, sin tener que esperar hasta que el final del flujo de audio devuelva resultados, y permitiendo el uso de diferentes gramáticas en el servidor de MRCP para adaptar el reconocimiento del habla mientras que el flujo está en curso.

Con este fin, la presente invención proporciona un método para gestionar el reconocimiento del habla de llamadas de audio, realizándose dichas llamadas de audio en un sistema basado en un protocolo de control de recursos de medios, o MRCP, y llevándose a cabo dicho reconocimiento del habla por un motor ASR controlado por un servidor de MRCP buscando una coincidencia entre un flujo de audio generado por un usuario y una gramática compilada.

A diferencia de las propuestas conocidas, el método de la invención, de una manera característica comprende además realizar dicho reconocimiento del habla de manera continua enviando, dicho servidor de MRCP, eventos regularmente a dicho usuario cuando se producen coincidencias, indicando cada uno de dichos eventos un resultado parcial de dicho reconocimiento del habla e ignorando las coincidencias insatisfactorias, deteniendo dicho reconocimiento del habla cuando se recibe una petición de detención desde dicho usuario o cuando dicho flujo de audio finaliza.

Se describen otras realizaciones del método de la invención según las reivindicaciones adjuntas 2 a 12, y en una sección posterior relativa a la descripción detallada de varias realizaciones.

Breve descripción de los dibujos

Las anteriores y otras ventajas y características se entenderán más completamente a partir de la siguiente descripción detallada de realizaciones, con referencia a los dibujos adjuntos (algunos de los cuales ya se han descrito en la sección del estado de la técnica anterior), que deben considerarse de una manera ilustrativa y no limitativa, en los que:

La figura 1 muestra una arquitectura de MRCP versión 2.

La figura 2 muestra el flujo de señalización entre el cliente de MRCP y el servidor de MRCP según el protocolo MRCP.

La figura 3 muestra una máquina de estados de MRCP versión 2 actual del servidor de MRCP.

La figura 4 muestra la máquina de estados modificada del servidor de MRCP según una realización de la presente invención.

La figura 5 muestra el flujo de señalización modificado entre el cliente de MRCP y el servidor de MRCP según una realización de la presente invención.

La figura 6 muestra el flujo de señalización entre el cliente de MRCP y el servidor de MRCP cuando se supera el límite de tiempo de carga de gramáticas, según una realización de la presente invención.

La figura 7 muestra el flujo de señalización entre el cliente de MRCP y el servidor de MRCP cuando se descarga una gramática, según una realización de la presente invención.

Descripción detallada de varias realizaciones

Esta patente presenta un nuevo procedimiento para un reconocimiento del habla continuo de llamadas de audio en un sistema basado en MRCP tal como se muestra en la figura 5. Específicamente, se propone un nuevo modo de operación, diferente de los dos modos definidos por el IETF (reconocimiento de modo normal, reconocimiento de modo de palabras activas). Dentro del alcance de este documento, este nuevo modo se denominará reconocimiento de modo de localización de palabras continua; sin embargo, ésta no es una denominación definitiva en lo que respecta a los propósitos de la patente.

En este modo de operación, el reconocedor busca una coincidencia según las gramáticas compiladas del servidor de MRCP e ignora todo lo que no coincide. Además, el reconocimiento continúa incluso si después se halla una coincidencia satisfactoria, y sólo termina cuando hay una petición STOP procedente del cliente, o finaliza el flujo de audio de entrada. Los eventos se envían del servidor al cliente en cualquier momento en el que haya una coincidencia de modo que el procesamiento del habla pueda ser en tiempo casi real. En este documento, esos eventos se han denominado PARTIAL RESULT.

En circunstancias normales, puede enviarse un PARTIAL RESULT del servidor al cliente en cualquier momento desde el principio del proceso de reconocimiento. Es el motor ASR el que decide que hay una coincidencia y que debe enviarse al cliente. Sin embargo, para los casos en los que se requiere un control total del cliente, se propone un mecanismo para el cliente para imponer la frecuencia mínima con la que el servidor comprobará resultados parciales no devueltos. Este mecanismo define un parámetro opcional, añadido a la colección definida en el protocolo MRCP. Este parámetro puede establecerse por las peticiones SET-PARAMS o RECOGNIZE de la norma. En este documento, este parámetro se denomina tasa de rastreo; representa el intervalo de tiempo máximo en el que el servidor debe comprobar resultados parciales no devueltos.

Además, la operación con flujos de audio no limitados abre las posibilidades de mejorar la calidad de los resultados usando diferentes gramáticas a medida que el flujo progresa. Para soportar esto, se propone una extensión al protocolo MRCP que permite una carga y descarga dinámicas de gramáticas. Para cargar una gramática adicional durante el estado de reconocimiento, se usará la petición DEFINE-GRAMMAR convencional. Adicionalmente, se propone un nuevo tipo de petición denominado UNLOAD GRAMMAR en el documento. Esta petición ordena al servidor que descargue la gramática especificada.

Para evitar retardos potencialmente demasiado largos en la carga de gramáticas, lo que podría dar como resultado que se perdieran coincidencias, se propone la inclusión de un límite de tiempo adicional a las especificaciones de MRCP. Este límite de tiempo se denomina límite de tiempo de carga de gramáticas. Debe establecerse al principio del proceso de reconocimiento y puede cambiarse en cualquier momento durante el proceso de reconocimiento por medio de una petición SET-PARAMS. Este parámetro es obligatorio y define el tiempo máximo que el cliente está dispuesto a esperar por una respuesta a la petición DEFINE-GRAMMAR. Esto es para mantener bajo control el tiempo que el servidor está sin una gramática apropiadamente configurada (y por tanto no puede producir resultados de reconocimiento).

A la luz de las especificaciones de la norma de MRCP [1], esta invención tiene como objetivo actualizar la máquina de estados del lado del servidor y proporcionar nuevos mensajes para el modo de localización de palabras continua propuesto.

MÁQUINA DE ESTADOS

La máquina de estados, tal como se muestra en la figura 4, incluye varios cambios con respecto a la máquina de estados de MRCPv2. En particular, pueden realizarse tres nuevas acciones durante el estado RECOGNIZING:

-: Enviar resultados parciales (424)

-: Descargar una de las gramáticas activas (425)

-: Definir una nueva gramática (426)

PROCESAMIENTO DEL HABLA DE UNA LLAMADA

Cuando se establece la llamada en la PBX, la primera etapa del protocolo MRCP es crear dos canales de procesamiento entre la PBX y el servidor de medios, uno por cada tramo de la llamada. Ambas sesiones se configuran con el protocolo SIP (en su lugar podría configurarse con el protocolo RTSP, se han abordado ambas elecciones en la norma) y se asocian con un identificador de canal de MRCP.

Una vez que los dos canales de MRCP se abren satisfactoriamente, el procedimiento para el nuevo modo continuo se ilustró en la figura 5. En primer lugar, el parámetro de límite de tiempo de carga de gramáticas se establece por medio del siguiente campo de cabecera del mensaje DEFINE-GRAMMAR (5102):

Load-grammar-timeout: <load-grammar-timeout>

Este límite de tiempo puede establecerse también con la petición SET-PARAMS (5101).

Ajustar este parámetro es un requisito para trabajar con gramáticas dinámicas que adaptan el reconocimiento al contexto de las conversaciones. De hecho, las gramáticas deben ser tan cortas como lo establecido por el tiempo en el que el servidor puede procesarlas según el límite de tiempo de carga de gramáticas.

El modo de localización de palabras continua se señaliza por las peticiones SET-PARAMS (5101) o RECOGNIZE (5103), que contienen las siguientes cabeceras:

Recognition-Mode: continuous-wordspotting

Tracebackrate: <time slice for partial results>

El parámetro de tasa de rastreo es opcional y su propósito es configurar el intervalo de tiempo máximo en el que el servidor debe comprobar resultados parciales no devueltos.

Una vez que el servidor ha recibido y procesado la petición RECOGNIZE, se envían resultados parciales, si están disponibles, al cliente en un determinado periodo de milisegundos dado por el parámetro de tasa de rastreo como máximo (5204, 5205, 5208, 5209). Si el motor ASR no ha producido ningún resultado dentro de este valor máximo, se le fuerza a comprobar si hay coincidencias.

Los resultados se procesan en tiempo real por el cliente de MRCP, que puede decidir añadir una(s) nueva(s) gramática(s) que va(n) a usarse para intentar obtener resultados más precisos. Para este propósito, se envía una nueva petición DEFINE-GRAMMAR (5104).

Sólo si el cliente solicita explícitamente el fin del reconocimiento con una petición STOP (5105), el estado del servidor cambiará de RECOGNIZING a IDLE. De lo contrario, el proceso continúa ilimitadamente controlado por los dos temporizadores definidos: Load-Grammar-Timeout, y Tracebackrate (si se establecen).

La figura 6 mostró lo que sucede en caso de superar el límite de tiempo de carga de gramáticas cuando está cargándose una gramática. En ese caso, el servidor envía una respuesta 503 COMPLETE (6206) al cliente con un campo de motivo de límite de tiempo de carga de gramáticas y el servidor continúa enviando resultados parciales (6207, 6208) con la(s) gramática(s) anterior(es). El cliente de MRCP podría solicitar que se cargue(n) otra(s) gramática(s) en su lugar.

El procedimiento mencionado anteriormente no tiene limitaciones relativas a la cantidad de gramáticas que van a usarse al mismo tiempo por el motor ASR. Dividir las reglas en varias gramáticas pequeñas favorece la modularidad y dinamicidad de carga y descarga de gramáticas, haciendo que este proceso sea más rápido. Por tanto, se describe a continuación el caso de uso en el que una gramática deba descargarse porque ya no va a usarse para el procesamiento de reconocimiento.

La figura 7 mostró la secuencia de peticiones y respuestas en el caso en el que se descarga una gramática. La petición UNLOAD-GRAMMAR (7104) se envía con el propósito de eliminar determinadas reglas en el motor ASR. Si la descarga es satisfactoria, se emite una respuesta 200 COMPLETE (7206).

Caso de uso de la invención

La presente invención tiene como objetivo establecer un procedimiento para localizar palabras en llamadas de audio de persona a persona para un sistema de MRCP. Cuando se gestiona un idioma natural, deben resaltarse algunas características:

-: Hay dos canales de audio (la parte que llama y la parte que recibe la llamada) y necesitan procesarse por separado para una mejor interpretación de los resultados, permitiendo un procesamiento posterior.

-: Incluso si se procesan por separado, estos dos canales deben estar asociados con la misma llamada (también para un procesamiento posterior).

- Los flujos de habla que van a procesarse tienen una longitud arbitraria,

-: El habla incluye potencialmente intervalos de silencio “largos”, debido a la interacción de dos vías, pero el reconocimiento no debe detenerse.

- Los resultados deben producirse y enviarse al cliente en tiempo (casi) real.

-: Las gramáticas que van a aplicarse para el procesamiento del habla deben cargarse y descargarse dinámicamente para permitir una adaptación basada en el contexto de la conversación,

-: El tiempo consumido en la carga de gramáticas debe ser lo suficientemente corto como para evitar retardos en el procesamiento.

Teniendo en cuenta todos los requisitos anteriores, esta patente propone un procedimiento para un

reconocimiento de llamadas de audio en un sistema de MRCP tal como sigue. Cuando se configura una llamada por PBX de VoIP, un módulo se encarga de configurar el protocolo MRCP con un servidor de medios. Este módulo actúa como cliente de MRCP que establece dos canales de MRCP con el servidor que se procesan por separado (habla de la parte que llama y la parte que recibe la llamada). En primer lugar, debe establecerse una sesión SIP entre el cliente y el servidor tal como se muestra en la figura 2 (211, 221, 212). La transacción SIP INVITE y la oferta/respuesta de SDP subyacente contienen líneas m que describen el canal de control de recursos que va a asignarse. Debe haber una línea m de SDP para cada recurso de MRCPv2 que va a usarse en la sesión. El campo de número de puerto de la línea m debe contener el puerto de escucha TCP en el servidor en la respuesta de SDP. A continuación, se proporciona un ejemplo de una negociación SIP/SDP. Ambos canales compartirán la misma conexión TCP para MRCP (m=application 32416 TCP/MRCPv2 1), pero diferente conexión UDP para flujos RTP (m=audio 48260 RTP/AVP 0 96; m=audio 48261 RTP/AVP 0 96). Por tanto, cada mensaje de MRCP para cualquiera de los canales se intercambiará por el puerto TCP 32416 del servidor, mientras que los mensajes RTP de uno de los canales se dirigirán al puerto UDP 48260 y los otros al puerto UDP 48261. La respuesta 200 OK contiene los identificadores de canales de MRCP para cada canal (a=channel:32AECB234338@speechrecog, a=channel:32AECB234339@speechrecog). Todos los mensajes de MRCP

posteriores indicarán este identificador de modo que el servidor pueda conocer a qué canal pertenece el mensaje de MRCP. C->S: INVITE sip:mresources@server.example.com SIP/2.0

Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bf3 Max-Forwards:6 To:MediaServer <sip:mresources@example.com>;tag=62784 From:sarvi <sip:sarvi@example.com>;tag=1928301774 Call-ID:a84b4c76e66710 CSeq:314162 INVITE Contact:<sip:sarvi@client.example.com> Content-Type:application/sdp Content-Length:... v=0 o=sarvi 2890844526 2890844527 IN IP4 192.0.2.4 s=- c=IN IP4 192.0.2.12 m=application 9 TCP/MRCPv2 1 a=setup:active a=connection:new a=resource:speechrecog a=cmid:1 m=audio 49170 RTP/AVP 0 96 a=rtpmap:0 pcmu/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15

a=sendonly a=mid:1 m=application 9 TCP/MRCPv2 1 a=setup:active a=connection:existing a=resource:speechrecog a=cmid:2 m=audio 49171 RTP/AVP 0 96 a=rtpmap:0 pcmu/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15 a=sendonly a=mid:2

S->C: SIP/2.0 200 OK Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bf3;received=192.0.32.10 To:MediaServer <sip:mresources@example.com>;tag=62784 From:sarvi <sip:sarvi@example.com>;tag=1928301774 Call-ID:a84b4c76e66710 CSeq:314162 INVITE Contact:<sip:mresources@server.example.com> Content-Type:application/sdp Content-Length:... v=0 o=- 2890842808 2890842809 IN IP4 192.0.2.4 s=-c=IN IP4 192.0.2.11 m=application 32416 TCP/MRCPv2 1 a=setup:passive a=connection: new a=channel:32AECB234338@speechrecog a=cmid:1 m=audio 48260 RTP/AVP 0 96 a=rtpmap:0 pcmu/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15

a=sendonly a=mid:1 m=application 32416 TCP/MRCPv2 1 a=setup:passive a=connection:existing a=channel:32AECB234339@speechrecog a=cmid:2 m=audio 48261 RTP/AVP 0 96 a=rtpmap:0 pcmu/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15 a=sendonly a=mid:2

C->S: ACK sip:mresources@server.example.com SIP/2.0 Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bf4 Max-Forwards:6 To:MediaServer <sip:mresources@example.com>;tag=62784 From:Sarvi <sip:sarvi@example.com>;tag=1928301774 Call-ID:a84b4c76e66710 CSeq:314162 ACK Content-Length:0 Una vez que se establece la sesión SIP, comienza el propio protocolo MRCP. Por motivos de simplicidad, se

considera sólo uno de los dos canales de llamada, 32AECB234338@speechrecog. Podría demostrarse que el flujo de mensaje para el otro canal es análogo.

El primero de los mensajes de MRCP corresponde a la definición de la gramática. A continuación en el presente documento, se muestra un ejemplo del contenido de la petición DEFINE-GRAMMAR que usa un formato xml para una gramática de localización de palabras.

C->S: MRCP/2.0 ... DEFINE-GRAMMAR 543257 Channel-Identifier: 32AECB234338@speechrecog Load-Grammar-Timeout: 2 Content-Type:application/srgs+xml Content-ID:<request1@form-level.store> Content-Length:... <?xml version="1.0"?>

<gramar xmlns=http://www.w3.org/2001/06/grammar xml:lang="en-EN" version="1.0"> <rule id="restaurant"> Restaurante

<one-of xml:lang="en-EN"> <item>Africa Kine </item> <item>Fishers of Men</item> <item>Make my Cake </item>

</one-of> </rule> </grammar>

S->C: MRCP/2.0 ... 543257 200 COMPLETE Channel-Identifier: 32AECB234338@speechrecog Completion-Cause:000 success El método RECOGNIZE del cliente al servidor señaliza al reconocedor que comience el procesamiento del

habla, indicando el modo de reconocimiento (Modo de reconocimiento: localización de palabras continua) en su cabecera. En este caso, se ha establecido la tasa de rastreo a 500 ms. C->S: MRCP/2.0 ... RECOGNIZE 543258 Channel-Identifier: 32AECB234338@speechrecog Confidence-Threshold:0.9 Recognition-Mode: continuous-wordspotting Tracebackrate: 500 S->C: MRCP/2.0 ... 543258 200 IN-PROGRESS Channel-Identifier: 32AECB234338@speechrecog

A partir de este momento, cada vez que el reconocedor detecte una palabra clave de la gramática definida, el servidor envía un evento PARTIAL-RESULT asociado con la petición RECOGNIZE a la que pertenece. Un estado IN-PROGRESS revela que el reconocedor aún está activo.

S->C: MRCP/2.0 ... PARTIAL-RESULT 543258 IN-PROGRESS Channel-Identifier: 32AECB234338@speechrecog Completion-Cause:000 success Content-Type:application/nlsml+xml Content-Length:... <?xml version="1.0"?> <result xmlns="http://www.ietf.org/xml/ns/mrcpv2" xmlns:ex="http://www.example.com/example" grammar="session:request1@form-level.store">

<interpretation> <instance name="Restaurant"> <ex:Restaurant> <ex:Name> Africa Kine </ex:Name> </ex:Restaurant> </instance>

<input> Africa Kine Restaurant</input> </interpretation> </result>

S->C: MRCP/2.0 ... PARTIAL-RESULT 543258 IN-PROGRESS Channel-Identifier: 32AECB234338@speechrecog Completion-Cause:000 success Content-Type:application/nlsml+xml Content-Length:... <?xml version="1.0"?>

<interpretation> <instance name="Restaurant"> <ex:Restaurant> <ex:Name> Fishers of Men </ex:Name>

</ex:Restaurant> </instance> <input> Fishers of Men Restaurant</input>

</interpretation> </result> Como resultado de cualquier cambio de contexto, el cliente decide modificar la gramática usando mensajes

UNLOAD-GRAMMAR y/o DEFINE-GRAMMAR respectivos tal como se indica más adelante. C->S: MRCP/2.0 ... UNLOAD-GRAMMAR 543259 Channel-Identifier: 32AECB234338@speechrecog

S->C: MRCP/2.0 ... 543259 200 IN-PROGRESS Channel-Identifier: 32AECB234338@speechrecog C->S: MRCP/2.0 ... DEFINE-GRAMMAR 543260 Channel-Identifier: 32AECB234338@speechrecog

Content-Type:application/srgs+xml Content-ID:<request1@form-level.store> Content-Length:... <?xml version="1.0"?>

<grammar xmlns=http://www.w3.org/2001/06/grammar xml:lang="en-EN" version="1.0"> <rule id="street"> Calle

<one-of xml:lang="en-EN"> <item>Downing</item> <item>Charlotte </item> <item>Fleet</item>

</one-of> </rule> </grammar>

S->C: MRCP/2.0 ... 543260 200 COMPLETE Channel-Identifier: 32AECB234338@speechrecog Completion-Cause:000 success Nuevamente, los resultados parciales se generan cuando el reconocedor halla cualquier coincidencia en el

canal de habla:

S->C: MRCP/2.0 ... PARTIAL-RESULT 543260 IN-PROGRESS Channel-Identifier: 32AECB234338@speechrecog Completion-Cause:000 success Content-Type:application/nlsml+xml Content-Length:... <?xml version="1.0"?>

<interpretation> <instance name="Street"> <ex:Street> <ex:Name> Downing</ex:Name>

</ex:Street > </instance> <input> Downing Street</input>

</interpretation> </result> Finalmente, el método STOP indica al servidor que detenga el reconocimiento para la sesión actual. La sección

de cabecera de respuesta contiene un campo de cabecera de lista de identificaciones de peticiones activas que contiene la identificación de petición de la petición RECOGNIZE que se terminó. C->S: MRCP/2.0 ... STOP 543261 200

Channel-Identifier: 32AECB234338@speechrecog

S->C: MRCP/2.0 ... 543261 200 COMPLETE Channel-Identifier: 32AECB234338@speechrecog Active-Request-Id-List:543258

SIP BYE desasignará todos los canales de control y recursos asignados en la sesión. C->S: BYE sip:mresources@server.example.com SIP/2.0

Via:SIP/2.0/TCP client.atlanta.example.com:5060;

branch=z9hG4bK74bg7

Max-Forwards:6

From:Sarvi <sip:sarvi@example.com>;tag=1928301774

To:MediaServer <sip:mresources@example.com>;tag=62784

Call-ID:a84b4c76e66710

CSeq:323126 BYE

Content-Length:0 Ventajas de la invención

El procedimiento explicado en esta invención llena la laguna de los mecanismos de control de recursos de medios convencionales actuales (concretamente, MRCP del IETF) para gestionar flujos de audio de longitud arbitraria de una manera eficaz. Específicamente, proporciona un nuevo modo de reconocimiento para un habla de larga duración que no espera hasta que el final del flujo de audio para producir coincidencias, sino que envía resultados en tiempo real siempre que se produzcan.

Con esta solución, se aumenta notablemente la eficacia en el protocolo de control puesto que no se requiere que las peticiones RECOGNIZE se envíen una y otra vez para reconocer gramáticas específicas, sino que se propone un modo continuo que conduce a resultados parciales.

Este método es particularmente adecuado para el reconocimiento del habla de conversaciones de persona a persona, en las que la naturaleza del audio no está limitada teóricamente (no restringida por ninguna gramática o formato conocido a priori).

Además, la idea de esta patente concibe la adaptación dinámica del reconocimiento del habla al contexto de la conversación de una manera que sea transparente para los usuarios del servicio. El protocolo de control se modifica en consecuencia, para aceptar cambios dinámicos de gramáticas durante el transcurso de la conversación.

Además, para ofrecer una interoperabilidad con otros operadores y compatibilidad con proveedores de motor de procesamiento del habla en el futuro, la normalización de la extensión al protocolo sería muy interesante.

Un experto en la técnica podría introducir cambios y modificaciones en las realizaciones descritas sin apartarse del alcance de la invención tal como se definió en las reivindicaciones adjuntas.

SIGLAS

ASR: Automatic Speech Recognition; Reconocimiento del habla automático

IETF: Internet Engineering Task Force; Grupo de trabajo de ingeniería de Internet

IP: Internet Protocol; Protocolo de Internet

5: IVR Interactive Voice Response; Respuesta de voz interactiva

MRCP: Media Resource Control Protocol; Protocolo de control de recursos de medios

MRCPv2: Media Resource Control Protocol v2; Protocolo de control de recursos de medios v2

PBX: Private Branch Exchange; Central automática privada

RFC: Request For Comments; Petición de comentarios

10: RTP Real Time Protocol; Protocolo en tiempo real

RTSP: Real Time Streaming Protocol; Protocolo de transmisión de flujo continuo en tiempo real

SDP: Session Description Protocol; Protocolo de descripción de sesión

SIP: Session Initiation Protocol; Protocolo de inicio de sesión

TCP: Transmission Control Protocol; Protocolo de control de transmisión

15: VoIP Voice over IP; Voz sobre IP

BIBLIOGRAFÍA

[1] IETF RFC 4463 (http://tools.ietf.org/html/rfc4463)

[2] IETF MRCP versión 2 (http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-25).

Claims

REIVINDICACIONES

1.

Método para gestionar el reconocimiento del habla de llamadas de audio, realizándose dichas llamadas de audio en un sistema basado en protocolo de control de recursos de medios, o MRCP, llevándose a cabo dicho reconocimiento del habla por un motor ASR controlado por un servidor de MRCP buscando una coincidencia entre un flujo de audio generado por un usuario y una gramática compilada, caracterizado porque comprende realizar dicho reconocimiento del habla de manera continua enviando, dicho servidor de MRCP, eventos regularmente a dicho usuario cuando se producen coincidencias, indicando cada uno de dichos eventos un resultado parcial de dicho reconocimiento del habla e ignorando coincidencias insatisfactorias, deteniendo dicho reconocimiento del habla cuando se recibe una petición de detención desde dicho usuario o cuando dicho flujo de audio finaliza.
2.

Método según la reivindicación 1, que comprende realizar dicho reconocimiento del habla según un modo de operación diferente del reconocimiento de modo normal y reconocimiento de modo de palabras activas definidos por el grupo de trabajo de ingeniería de Internet.
3.

Método según la reivindicación 2, que comprende indicar dicho modo de operación a dicho servidor de MRCP por medio de una petición SET-PARAMS o RECOGNIZE existente del protocolo MRCP.
4.

Método según cualquiera de las reivindicaciones anteriores, que comprende decidir, un módulo de reconocimiento del habla automático de dicho sistema basado en MRCP, cuándo se ha producido una coincidencia y enviar, dicho servidor de MRCP, un evento cada vez que se ha producido una coincidencia.
5.

Método según cualquiera de las reivindicaciones anteriores, que comprende incluir un parámetro en la petición SET-PARAMS y/o RECOGNIZE existente del protocolo MRCP, indicando dicho parámetro un intervalo de tiempo máximo en el que dicho servidor de MRCP debe comprobar resultados parciales no devueltos.
6.

Método según cualquiera de las reivindicaciones anteriores, que comprende usar diferentes gramáticas compiladas mientras que se realiza dicho reconocimiento del habla cargando, dicho usuario, una gramática dada por medio de la petición DEFINE-GRAMMAR existente del protocolo MRCP y compilar, dicho servidor de MRCP, dicha gramática dada.
7.

Método según la reivindicación 6, que comprende descargar un gramática concreta desde dicho servidor de MRCP cuando recibe, dicho servidor de MRCP, una petición UNLOAD-GRAMMAR, definiéndose dicha petición UNLOAD-GRAMMAR para el protocolo MRCP.
8.

Método según la reivindicación 6 ó 7, que comprende incluir un parámetro de límite de tiempo de carga de gramáticas en una petición SET-PARAMS o DEFINE-GRAMAR existente del protocolo MRCP, indicando dicho parámetro de límite de tiempo de carga de gramáticas el tiempo máximo que hay que esperar una respuesta de una petición DEFINE-GRAMMAR.
9.

Método según la reivindicación 8, que comprende enviar una respuesta COMPLETE del protocolo MRCP desde dicho servidor de MRCP hasta dicho usuario si se supera dicho parámetro de límite de tiempo de carga de gramáticas y continuar enviando dichos resultados parciales según una gramática anterior.
10.

Método según cualquiera de las reivindicaciones anteriores, que comprende cambiar el estado de dicho servidor de MRCP, según el protocolo MRCP, de un estado de reconocimiento a un estado en espera sólo cuando se recibe una petición STOP de dicho usuario a dicho servidor de MRCP.
11.

Método según cualquiera de las reivindicaciones anteriores, que comprende establecer una llamada en una central automática privada, o PBX, y crear dos canales de procesamiento entre dicha PBX y dicho servidor de MRCP, uno por cada parte de dicha llamada y usándose cada uno de dichos dos canales de procesamiento para realizar dicho procesamiento del habla sobre flujos de audio generados por la parte que llama.
12.

Método según la reivindicación 11, en el que dicho flujo de audio tiene una longitud arbitraria y contiene intervalos de silencio.

Figura 1

Figura 2 Figura 3

Figura 4 Figura 5

Figura 6 Figura 7

OFICINA ESPAÑOLA DE PATENTES Y MARCAS

N.º solicitud: 201131647

ESPAÑA

Fecha de presentación de la solicitud: 14.10.2011

Fecha de prioridad:

INFORME SOBRE EL ESTADO DE LA TECNICA

51 Int. Cl. : G10L15/26 (2006.01) H04L29/08 (2006.01)

DOCUMENTOS RELEVANTES

Categoría

56 Documentos citados Reivindicaciones afectadas

X

“Continuous speech recognition in (Uni)MRCP”. 02.12.2010 [recuperado el 02.10.2013]. Recuperado del correo electrónico de Internet UniMRCP Discussion Group: Continuous speech recognition in (Uni)MRCP. Recuperado de Internet: <URL:https://groups.google.com/forum/#!msg/unimrcp/pSaDbhHPh3M/cocDrqPi3aAJ>. 1-5

Y

Todo el documento. 6-12

Y

Anónimo: "Product Support Notice PSN002343u". 28.07.2009, páginas 1-6, Recuperado de Internet: URL:http://downloads.avaya.com/css/P8/documents/100060040 [recuperado 02.10.2013]. Todo el documento. 6-12

Y

BURNETT VOXEO S SHANMUGHAM CISCO SYSTEMS D et al.: "Media Resource Control Protocol Version 2 (MRCPv2);draft-ietf-speechsc-mrcpv2-25.txt", MEDIA RESOURCE CONTROLPROTOCOL VERSION 2 (MRCPV2); DRAFT-IETF-SPEECHSC-MRCPV2-25.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH1205 GENEVA, SWITZERLAND, no. 25, 12.07.2011), páginas 1-226, [recuperado 02.10.2013]. Páginas 9 -13,75-80. 1-12

Y

R. BROWN. “HTML Speech XG Proposed Protocol Approach”. Documento recuperado de internet <http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Jul/0011.html> [recuperado el 02.10.2013]. 06.07.2011. Epígrafes 2, 4 y 5. 1-12

A

US 2009037176 A1 (ARROWOOD JON A) 05.02.2009, resumen; figura 1; párrafos [0005-0009],[0018],[0025]. 1-12

Categoría de los documentos citados X: de particular relevancia Y: de particular relevancia combinado con otro/s de la misma categoría A: refleja el estado de la técnica O: referido a divulgación no escrita P: publicado entre la fecha de prioridad y la de presentación de la solicitud E: documento anterior, pero publicado después de la fecha de presentación de la solicitud

El presente informe ha sido realizado • para todas las reivindicaciones • para las reivindicaciones nº:

Fecha de realización del informe 02.10.2013

Examinador M. Rivas Sáiz Página 1/5

INFORME DEL ESTADO DE LA TÉCNICA

Nº de solicitud: 201131647

Documentación mínima buscada (sistema de clasificación seguido de los símbolos de clasificación) G10L, H04L Bases de datos electrónicas consultadas durante la búsqueda (nombre de la base de datos y, si es posible, términos de

búsqueda utilizados) INVENES, EPODOC, WPI, INSPEC

Informe del Estado de la Técnica Página 2/5

OPINIÓN ESCRITA

Nº de solicitud: 201131647

Fecha de Realización de la Opinión Escrita: 02.10.2013

Declaración

Novedad (Art. 6.1 LP 11/1986)

Reivindicaciones Reivindicaciones 1-12 SI NO

Actividad inventiva (Art. 8.1 LP11/1986)

Reivindicaciones Reivindicaciones 1-12 SI NO

Se considera que la solicitud cumple con el requisito de aplicación industrial. Este requisito fue evaluado durante la fase de examen formal y técnico de la solicitud (Artículo 31.2 Ley 11/1986).

Base de la Opinión.-

La presente opinión se ha realizado sobre la base de la solicitud de patente tal y como se publica.

Informe del Estado de la Técnica Página 3/5

OPINIÓN ESCRITA

Nº de solicitud: 201131647

1. Documentos considerados.-

A continuación se relacionan los documentos pertenecientes al estado de la técnica tomados en consideración para la realización de esta opinión.

Documento

Número Publicación o Identificación Fecha Publicación

D01

“Continuous speech recognition in (Uni)MRCP”. 02.12.2010 [recuperado el 02.10.2013]. Recuperado del correo electrónico de Internet UniMRCP Discussion Group: Continuous speech recognition in (Uni)MRCP. Recuperado de Internet: <URL:https://groups.google.com/forum/#!msg/unimrcp/pSaDbhHPh3M/cocDrqPi3aAJ>. 02.12.2010

D02

Anónimo: "Product Support Notice PSN002343u". 28.07.2009, páginas 1-6, Recuperado de Internet: URL:http://downloads.avaya.com/css/P8/documents/100060040 [recuperado 02.10.2013]. 28.07.2009

D03

BURNETT VOXEO S SHANMUGHAM CISCO SYSTEMS D et al.: "Media Resource Control Protocol Version 2 (MRCPv2);draft-ietf-speechsc-mrcpv2-25.txt", MEDIA RESOURCE CONTROLPROTOCOL VERSION 2 (MRCPV2); DRAFT-IETFSPEECHSC-MRCPV2-25.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH-1205 GENEVA, SWITZERLAND, no. 25, 12.07.2011), páginas 1-226, [recuperado 02.10.2013]. 12.07.2011

D04

R. BROWN. “HTML Speech XG Proposed Protocol Approach”. Documento recuperado de internet <http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Jul/0011.html> [recuperado el 02.10.2013]. 06.07.2011
2. Declaración motivada según los artículos 29.6 y 29.7 del Reglamento de ejecución de la Ley 11/1986, de 20 de marzo, de Patentes sobre la novedad y la actividad inventiva; citas y explicaciones en apoyo de esta declaración

El documento D01 se considera el más próximo del estado de la técnica a la invención solicitada.

Con relación a la reivindicación 1, D01 describe un método para gestionar el reconocimiento del habla basado en protocolo de control de recursos de medios, o MRCP, llevándose a cabo dicho reconocimiento del habla por un motor ASR controlado por un servidor de MRCP. En D01 se propone la realización de un reconocimiento del habla de manera continua enviando, dicho servidor de MRCP, eventos regularmente a dicho usuario cuando se producen coincidencias, indicando cada uno de dichos eventos un resultado parcial de dicho reconocimiento del habla. D01 divulga la detención de dicho reconocimiento del habla cuando se recibe una petición de detención desde el usuario.

La diferencia entre D01 y la reivindicación 1 es que D01 no menciona que se ignoren coincidencias insatisfactorias. Sin embargo, este modo de funcionamiento es una técnica habitual en el reconocimiento del habla y su mera aplicación es evidente para un experto en la materia. Por tanto, la reivindicación 1 no implica actividad inventiva (Artículo 8 LP.).

El documento D03 junto con el D04 también anula la actividad inventiva de la reivindicación 1. D03 describe un método para gestionar el reconocimiento del habla basado en protocolo de control de recursos de medios, o MRCP, llevándose a cabo dicho reconocimiento del habla por un motor ASR controlado por un servidor de MRCP buscando una coincidencia entre un flujo de audio generado por un usuario y una gramática compilada (páginas 9 a 13).

La diferencia entre la reivindicación 1 y D03 es que en D03 el servidor de MRCP no envía eventos regularmente a dicho usuario cuando se producen coincidencias, indicando cada uno de dichos eventos un resultado parcial de dicho reconocimiento del habla e ignorando coincidencias insatisfactorias. D03 únicamente indica en la página 75 la posibilidad de enviar eventos asíncronos para indicar condiciones de interés durante el proceso del método. El efecto técnico de esta diferencia es el reconocimiento de flujos de audio de larga duración en tiempo real o casi tiempo real ya que se permite enviar resultados parciales. El problema técnico es como reconocer flujos de audio de larga duración en tiempo real o casi tiempo real.

Este problema está resuelto en D04, donde se define un protocolo de control de recursos para el reconocimiento de voz (epígrafe 5) en el que se definen unas mensajes de comunicación de resultados parciales para el reconocimiento de flujos continuos. Por consiguiente un experto en la materia combinaría las características descritas en D03 con el problema resuelto en D04 para la obtener la reivindicación 1 sin hacer uso de la actividad inventiva.

Respecto a la reivindicación 2, ésta está descrita tanto en D01 como en D04 por lo que se concluye que no cumple el requisito de actividad inventiva (Artículo 8 LP).

Las reivindicaciones 3 a 5 describen pequeños detalles de diseño que o bien están descritos en los documentos D01 a D04 o son implementaciones directas de técnicas ampliamente conocidas para un experto en la materia. Por tanto las reivindicaciones 3 a 5 no implican actividad inventiva (Artículo 8 LP.).

Informe del Estado de la Técnica Página 4/5

OPINIÓN ESCRITA

Nº de solicitud: 201131647

Las reivindicaciones 6 a 8 incorporan la modificación de nuevas gramáticas durante el proceso de reconocimiento del habla. Estás técnicas están descritas en D02 y en D04 por lo que las reivindicaciones 6 a 8 no implican actividad inventiva (Artículo 8 LP.).

Al igual que sucedía con las reivindicaciones 3 a 5, las reivindicaciones 9 a 12 describen pequeños detalles de diseño que o bien están descritos en los documentos D01 a D04 o son implementaciones directas de técnicas ampliamente conocidas para un experto en la materia. Por tanto las reivindicaciones 9 a 12 implican actividad inventiva (Artículo 8 LP.).

Informe del Estado de la Técnica Página 5/5