ES2832502T3 - Proceso de traspaso WLAN-IAD - Google Patents

Abstract

Un procedimiento para proporcionar información al menos a uno de un primer sistema terminal (A0) con un Dispositivo de Acceso Integrado de una red local, real o virtual, (IAD0 local) y una conexión a un segundo sistema terminal (Z0), estando dicho primer sistema terminal (A0) y dicho segundo sistema terminal (Z0) conectados a través de una red y son objeto de un proceso de traspaso potencial, actual o completado, en donde el traspaso potencial está definido de manera que si para este ninguna de sus acciones de cambio se ha ejecutado todavía en un dispositivo terminal, pero al menos alguna otra acción para este ya se ha abordado en el mismo y/o en un sistema terminal, el procedimiento comprende: proporcionar al menos a uno del primer y segundo sistemas terminales (A0, Z0) información relevante para el traspaso sobre el proceso de traspaso potencial, actual o completado, en donde dicha información relevante para el traspaso incluye información sobre dispositivos de acceso integrado IAD locales/compartidos, potenciales, en un área de recepción de un IAD de una red local al que el primer sistema terminal (A0) está asignado, en donde el Dispositivo de Acceso Integrado de la red local es un WLAN-IAD.

Description

DESCRIPCIÓN

Proceso de traspaso WLAN-IAD

Antecedentes de la invención

La presente invención se refiere a un procedimiento de "navegación por la red" para un sistema terminal A0, con un Dispositivo de Acceso Integrado de una red local, real o virtual, (A0-IAD0 local) y una conexión A0 a un segundo sistema terminal Z0 con un "traspaso gestionado" (MHO) a un lADx real (por sus siglas en inglés de "Integrated Access Device") de una Red de Área Local Inalámbrica (WLANx) (por sus siglas en inglés de "Wireless Local Area Network") o a un lADx virtual para una red de telefonía móvil (redx). El MHO está soportado por el A0-lAD0 local.

Una conexión A0 es a menudo relevada a través de un módulo MHO, MHOM, que está controlado por la especificación MHO, MHOS, del A0-IAD0 local. Esto ofrece ventajas tanto a los operadores del lADx compartido/A0-lAD0 local como a los usuarios de sus sistemas terminales locales.

Un MHOM (incluyendo o excluyendo MHOS) se diferencia en esencia de un "agente local" ('home agent") de la tecnología de Internet en movilidad y por tanto puede dar soporte también a los actuales teléfonos WiFi/FMC convergencia fijo-móvil). Es decir, el procedimiento de navegación por la red está orientado a corto plazo a la telefonía VolP, aunque no queda limitado a ella.

Antecedentes de la tecnología HO existente

El documento US 2006/0099948 A1 expone adecuadamente, en su sección de ANTECEDENTES DE LA INVENCIÓN, el estado de la técnica en el caso del traspaso imperceptible ( 'seamless HO") y la descripción de su procedimiento, en especial en el caso de un "traspaso independiente del medio" (MIH). Las diferentes variantes técnicas de HO se discuten (más ampliamente documentadas) en el "documento de publicación de una visión general IEEE802.21" de V. Gupta y col.

(DCN 21-06-0706-00-0000), del mismo modo que el de la universidad de UCLA CSD-TR N.° 040012 de L.J. Chen, del mismo modo que el trabajo de G.A. Mills-Tetty y col. ("Mobile Voice over IP, (MVOIP)..." Proc. of the 21. IEEE International Performance, Computing and Commmunications Conference, 2002), del mismo modo que el de E. Edvardsen y col. ("Open Access Networks", Telenor Research and Development 2002) o H. Almus ("Open Broadband Access Networks" TERENA Networking Conference 2006) o P. A. Frangoulis ("Experimental evaluation of communitybased WLAN voice and data services", ICST 978-963-06-2670-5). La instrumentación completa de la tecnología de Internet en movilidad para una técnica futura de HO se discute en la presentación general, relevante y sin omisiones, del libro de J. Schiller ("Mobile Communications" Addison-Wesley 2003).

Estos trabajos describen el estado de la técnica de HO meticulosamente y dejan ver así que no plasman las características innovadoras del procedimiento de navegación por la red, es decir, que sus características son adecuadas:

■ para el soporte de MHO de los teléfonos WiFi o FMC y de WLAN-IAD compartidos actuales por su renuncia a la técnica actualmente no común (aún) de teléfonos WiFi/FMC y en particular

■ para la producción de ventajas para el operador del IAD local/IAD compartido y para el usuario del sistema terminal, a la par que se ocultan estas ventajas o usos al resto de operadores de la red.

El procedimiento de navegación por la red presenta con respecto a la tecnología de Internet en movilidad y con respecto al "procedimiento HOCiS" (documento PCT/EP2007/010485 DEL 3.12.2007)) al menos una característica técnica adicional: esta característica adicional , es su relevo posiblemente sin túneles (es decir la primera característica anterior) y su comunicación técnica con respecto a la implementación de una acción comercial de un operador de lAD local-/IAD compartido, que por regla general se realiza con respecto a ambos usuarios de los sistemas terminales de una llamada VolP, por regla general por medio de diferentes mensajes a ambos y en concreto deliberadamente con ocasión del HO de uno de ellos y entonces se correlaciona con la información de conveniencia, (es decir la segunda característica anterior). Ambas características técnicas, el relevo sin túneles y una comunicación (comercial) adicional técnicamente correlacionada con la "información de conveniencia", no se implementan ni en el estado de la técnica de HO ni de la técnica de Internet en movilidad, (esta última con sus documentos WO 2006/031379 A1 y WO 2006/031384 A1, que van en una dirección parecida, y que sin embargo, entre otras cosas, excluyen claramente una aplicación de telefonía/VolP) ni en el procedimiento HOCIS ni en un procedimiento de llamada esponsorizada Csponsored-calf) (véase, por ejemplo, "Rich Multimedia Applications on IMS Framework", agosto 2007, o "ARGELA Multimedia Sponsored Call White Paper" en las respectivas páginas Web). Además, el documento EP2071881 divulga un traspaso gestionado desde una macrocelda a una femtocelda (posiblemente una Wi-Fi BSS), proporcionando a intervalos de tiempo regulares, información sobre femtoceldas disponibles a las estaciones de telefonía móvil, cuyas femtoceldas están en el área de cobertura de la actual macrocelda.

Sumario de la invención

La presente invención proporciona un procedimiento de navegación por la red para un sistema terminal A0, con un A0-IAD0 local virtual o real y una conexión A0 a un segundo sistema terminal Z0, de acuerdo con la reivindicación independiente 1. Las reivindicaciones dependientes 2-12 describen realizaciones preferidas adicionales.

Una conexión A0 está relevada a menudo a través de un módulo MHO, MHOM, que está controlado según una especificación de MHO, MHOS, en el A0-IAD0 local (en ambas implementaciones distribuidas y locales), lo que ofrece ventajas a los operadores del lADx compartido/A0-IAD0 local y a los usuarios de sus sistemas terminales locales. La MHOS es privada para el operador del A0-IAD0 local y cuando es aplicable, individual para el sistema terminal local. Este control del relevo ofrece ventajas:

■ a un operador del lADx compartido en relación con alguien que navega por la red en A0: a este último no le supone un riesgo legal, ya que para A0 le resulta identificable el iAD0 local y con ello su operador será responsable legalmente en caso de abuso en Internet de A0.

■ a un operador del IAD0 local y a todos los operadores del lADx compartido que cooperan con él, por ejemplo, o las variantes de MHO de la navegación por la red del sistema terminal local IAD0-/lADx compartido y las considerables posibilidades aparejadas de reducción de costes y aumento de la calidad en su funcionamiento o posibilidades comerciales para el operador IAD0 local local-/WLANx compartida mediante la "correlación CI" de sus mensajes con la información "HOCIS" que genera simpatía y buena acogida y eventualmente la entrega de estos no sólo al que navega por la red sino también a su interlocutor, en concreto respectivamente concebidos en tecnología y contenido para satisfacer las necesidades, es decir, diferenciados,

o seguridad de uso de estas ventajas, (es decir, su uso deja al margen a terceros, cuando es necesario, resulta incluso invisible para estos, por ejemplo, para operadores de red intermedios) lo que, sin embargo, no excluye un soporte del procedimiento de navegación por la red de otros, por ejemplo, un operador de red.

■ a los usuarios de los sistemas terminales, porque, debido a los motivos que se acaban de mencionar, encuentran WLAN compartida más abiertas y sus MHO entre otras cosas a estas WLAN compartidas son más cómodos para ellos que hasta la fecha, en particular debido a su "correlación CI".

La funcionalidad de un MHOM (incluyendo o excluyendo MHOS), en comparación con el "agente local" ("home agent), de la tecnología de Internet en movilidad resulta ampliada/limitada a las capas 3-7 del modelo OSI RM para poder poner en práctica esta gestión de HO también con los teléfonos WiFi-FMC y las WLAN compartidas actuales que no tienen control sobre una tunelización adecuada y/o no pueden aprovechar las ventajas mencionadas anteriormente. Es decir, el procedimiento de navegación por la red se dirige a corto plazo a la telefonía VOIP e incluso más específicamente a la "navegación por redes WLAN" también conocida como "Wsurfing" de las llamadas VolP, que caracteriza a los ejemplos de esta sección B, a su seguridad/privacidad (véase la Sección C) y a su uso comercial, pero no queda limitado a nada similar.

Para subrayar esto se hará referencia a las posibilidades de usar el procedimiento Wsurfing, por ejemplo, en el contexto de una transmisión de televisión IP, en lugar de una transmisión VolP o que vayan aparejadas a ella, o posiblemente en el contexto de un seguimiento en tiempo real del usuario de A0 orientado a la seguridad. En todas estas aplicaciones de comunicaciones todos los comentarios sobre la navegación por la red/Wsurfing son igualmente relevantes, como en el caso de la aplicación de comunicaciones VolP. Esta última se puede considerar, por tanto, representativa de todas estas muchas otras posibilidades de aplicación del procedimiento/aparato según la invención, por lo que en lo que sigue sólo se recordarán ocasionalmente.

Un lAD local pequeño puede al menos facilitar a un sistema terminal (por ejemplo, a un teléfono y a su usuario) el acceso a al menos una red y darle soporte en el sentido descrito anteriormente, por ejemplo, a Internet y/o a la red pública conmutada de telefonía, PSTN, a través de un acceso a ella misma, en donde esta última tiene lugar:

■ o por una red inalámbrica y en ella cualquier región definible (por ejemplo, el rango de recepción de un IAD o cualquier región, eventualmente, la región completa, de una red GSM),

■ o mediante una conexión física (por ejemplo, cable de teléfono o cable coaxial).

La realización de una WLAN en el sentido de la presente memoria descriptiva se puede sustentar sobre la base de, por ejemplo, la tecnología "RFI" o "Bluetooth" o "Femtocelda" o "DECT" o "Wimax" o "GSM/CDMA/UMTS/GPRS/HSDPA/...", de manera más particular, la tecnología "Wifi", y cuando sea necesario, comprende IAD heterogéneos (que antes se denominaban incorrectamente AP, AP = punto de acceso), y/o BS de una red de telefonía móvil (BS = estación base) y se extiende a una región, definida como sea, del rango de recepción de un IAD o de una BS. Un IAD local/servidor local grande puede facilitar el acceso a la red a miles de sistemas terminales y darles soporte en el sentido antes mencionado, de modo que, por ejemplo, puede ser un servidor de Internet o un sistema de esta red o que está en esta red.

Un MHOM consta de componentes HW-ISW abstractos (= funcionales). No tiene por qué usar sus componentes HW (acrónimo de hardware) abstractos exclusivamente para su funcionalidad MHOM, alias funcionalidad de navegación por la red, sino que es adecuado para compartir su uso abstracto con al menos un no MHOM funcional (= "compartición abstracta de recursos" ("abstract resource sharing') entre estos módulos, véase la Sección C). Un MHOM puede estar para ello ubicado en cualquier sistema anfitrión "material", por ejemplo, se puede alojar en cualquier IAD o sistema material de o en una red, sin que éste necesite una extensión hW material para ello (véase el final de la Sección C). También los componentes SW (acrónimo de Software) de un MHOM (en su sistema anfitrión) pueden estar presentes en cualquier otro lugar en forma codificada, pero de modo que, antes de que se solicite una función de uno de estos componentes SW cuya parte sea responsable de esta función, se puedan compilar en un código equivalente semánticamente y cargar en el sistema anfitrión y así resulten ejecutables por los componentes MHOM-Hw antes mencionados. Este concepto de un MHOM resulta demasiado estricto para la exposición que se plantea a continuación y que en la sección C se subdividirá más, si bien de momento resulta suficiente. El experto en la materia pertinente está familiarizado con estos términos/conceptos.

El procedimiento de navegación por la red es una aplicación de comunicación (según la MHOS) que por lo general se sitúa en la capa 7, L7, de la conexión OSI/OC0, (véase más adelante) entre A0 y Z0. Independientemente de si esta funcionalidad MHOM está implementada en parte o totalmente en una WLAN0 (entonces, por ejemplo, en el IAD0 que la controla) o fuera (entonces, por ejemplo en un servidor de Internet o en un sistema de red y por tanto fuera del IAD0 que la controla) se le puede dar soporte con las funciones de los sistemas terminales A0 y/o Z0, lo que por lo general aumenta la comodidad de la navegación por la red, pero a lo que también se puede renunciar.

La seguridad jurídica mencionada anteriormente de la forma de uso de la WLAN compartida de navegación por la red (por ejemplo, de un teléfono móvil A0 en su llamada a Z0) se produce porque su solicitud según la invención, por ejemplo, de un lAD compartido de la misma, queda limitada a su uso exclusivamente como enrutador exclusivamente hacia un MHOM con dirección IP fija, o sea a un operador conocido. Este operador del MHOM puede identificar sin ninguna duda a un responsable de una OC0 relevada por el mismo (en caso de que acaso efectúe el relevo, y entonces, por ejemplo, al inicio de la llamada o antes, lo que es irrelevante en este caso, pero para lo que el experto en la materia conoce procedimientos adecuados). Así este operador del MHOM es responsable de descubrir la identidad de un usuario de un teléfono inalámbrico en un lAD compartido, y no el operador de este último. Es de notar: desviándose de esto, que el MHOM debería facilitar el acceso de A0 a Internet que se ha encaminado hacia el mismo, (y así a su llamada VolP a Z0), en caso de que se trate de una llamada de emergencia (si bien actualmente, esto está, sin embargo, pendiente de aclaración legal).

Las variantes aportadas a modo de ejemplo de implementación de este aspecto legal de la forma de uso de la navegación por la red de los lAD compartidos se bosquejan al final de esta sección B. En primer lugar, se representará, sin embargo, la visión de usuario exclusivamente del núcleo técnico del HO del procedimiento de Wsurfing a modo de ejemplos concretos en los que el MHOM0 está integrado en un IAD0 local/servidor local 0 de un sistema terminal A0. Las variantes de la separación de las funcionalidades usadas a este respecto se discuten en las figuras 6-8 y sus explicaciones en la Sección D. El núcleo comercial del procedimiento de navegación por la red y su "correlación CI" se explican en la Sección C.

Breve descripción de los dibujos

La figura 1 muestra un ejemplo de terminal móvil A0 que se mueve entre diferentes regiones WLAN de acuerdo con un aspecto de la invención;

la figura 2 muestra un ejemplo de un terminal móvil A0 que se mueve entre diferentes regiones WLAN de acuerdo con otro aspecto de la invención;

la figura 3 muestra un ejemplo de un terminal móvil A0 que se mueve entre diferentes regiones WLAN de acuerdo con otro aspecto más de la invención;

la figura 4 es un diagrama de flujo de un proceso de traspaso de acuerdo con un aspecto de la invención;

la figura 5 es un diagrama de bloques esquemático de componentes de hardware y software de un aparato de acuerdo con una realización de la invención;

las figuras 6a - 6e muestran unos ejemplos de disposiciones de telecomunicaciones a las que se puede aplicar el procedimiento de acuerdo con la invención;

las figuras 7a - 7e muestran ejemplos adicionales de disposiciones de telecomunicaciones a las que se puede aplicar el procedimiento de acuerdo con la invención;

las figuras 8a - 8e muestran ejemplos adicionales de disposiciones de telecomunicaciones a las que se puede aplicar el procedimiento de acuerdo con la invención.

Descripción detallada de la invención

El escenario más sencillo de Wsurfing o navegación por la red se muestra en la figura 1: un MHO directo o indirecto del sistema terminal móvil A0 de un PTC (= proceso técnico de comunicaciones, véase la sección C), por ejemplo, un teléfono FMC y su usuario, de su WLAN0 local, abreviadamente: WO, que significa lo mismo que IAD0 local, en el W1 o W2 no disjunto con respecto al mismo por el trayecto 1 o 2, respectivamente. La conexión de capa 7, L7, de una OC0 que puede existir entre A0 y Z0 permanece inalterada por estos MHO en los trayectos 1 o 2, respectivamente. Al menos una conexión de capa 3, L3, en la A0-OC0 sin embargo se releva, cuando el sistema terminal A0 se encuentra en W1 o W2, por parte del correspondiente IAD1/IAD2 (según la invención a través de un MHOMO en el IAD0 local del W0. Los detalles a este respecto se conocen de la técnica de Internet en movilidad (véase la Sección A).

Debería tenerse en cuenta que en este caso no se limita de qué manera se establece la conexión respectiva de capa 3, L3, (segmento) entre el sistema terminal móvil A0 en W1 o W2 y el IAD0 local/servidor local 0 de WO durante un MHO. Esta solicitud de patente comprende por lo tanto todas las posibles variantes diferentes de este establecimiento de una conexión de capa 3, L3, entre la entidad de capa 3, L3, de A0 y la del MHOMO. Si el A0 es, a modo de ejemplo, un teléfono, esta conexión de capa 3, L3, puede producirse entonces en particular a través de su llamada al MHOMO o viceversa, o pueden producirse inmediatamente (los detalles técnicos, que favorecen esto, son irrelevantes en el presente documento). Esto se aplica también al caso de una "reinicialización completa" de una llamada telefónica de un teléfono actual WiFi/FMC A0 saliendo de una WLANx a Z0 para cuya implementación el MHOMO tiene que estar debidamente diseñado en la capa 7, L7, (en el IAD0).

Después de esta exposición de un "MHO directo", es decir de una WLAN directamente a otra WLAN, resulta obvio cómo funciona un "MHO indirecto" según la invención, en el que por tanto ambas WLAN entre las que alterna el sistema terminal A0, no se solapan espacialmente o temporalmente entre sí (véase las WLAN WO y W2, así como el trayecto 2 de la figura 1).

En este punto, hay que distinguir dos casos:

■ en el rango en el que no existe "ninguna WLAN", durante un periodo de tiempo determinado o sección del trayecto A0 tampoco puede usar ninguna otra red, por motivos administrativos o técnicos. En este caso no puede realizarse una transmisión de información en la A0-OC0 a ZO, en este rango, puesto que no dispone de una conexión de capa 3, L3, continua entre A0 y Z0. Las conexiones de capa 4-7, L4-L7, del A0-OC0 son sin embargo independientes de esto y pueden seguir existiendo cuando sea necesario de modo que la comunicación actual entre A0 y Z0 mediante el A0-OC0, o sea el de la PTC suspendida, puede seguir existiendo y seguir realizándose, en cuanto A0 entra en una WLANx, se puede establecer una "conexión Wsurfing" para la conexión A0-OC0, por medio de su lADx, entre A0 y el IAD0 local/servidor local 0, (y su MHOMO).

■ en este rango en el que no existe "ninguna WLAN" A0 puede usar otra red, por así decirlo, una red sustitutiva de Wsurfing, posiblemente una red de telefonía móvil basada en GSM/CDMA/GpRS/HSDPA... o una red de telefonía fija. Si nos quedamos con el primer ejemplo y asumimos que A0 es un teléfono FMC y que tiene acceso (véase más adelante) a esta red de telefonía móvil, entonces se puede establecer una conexión de Wsurfing para A0 entre A0 y el IAD0 local/servidor local 0, (mediante su MHOMO) a través de esta red de telefonía móvil, que de nuevo puede dejarse sin tratar en detalle en este caso. En la subsiguiente entrada y registro de A0 en W2 se sustituye entonces, cuando sea necesario, después de una prueba de seguridad en el MHOMO según la invención, esta conexión Wsurfing basada en la red móvil para A0 por una conexión Wsurfing basada en Internet para A0.

Después de estas exposiciones detalladas del "sistema terminal MHO de llamada" de A0, es decir la "navegación por la red soportada para el que llama", tal como se muestra en la figura 1, resulta evidente que hay un MHO también para el “sistema terminal que recibe la llamada", es decir, la "navegación por la red soportada para el que recibe la llamada de A0" (véase la figura 2). Para la última variante de navegación por la red se aplica lo que se ha dicho en el párrafo anterior del mismo modo, pudiendo estar situado en este caso el MHOM M' en un IAD' entre Internet y el sistema terminal Z0. El M' posibilita la conmutación de redes WLAN por A0 y la conexión Wsurfing entre A0 y M' mediante exactamente la misma funcionalidad MHO que en M, es decir M' es asimismo un MHOM, sin embargo, en algunas circunstancias, con reducción de la protección de abuso de Internet descrita anteriormente.

Finalmente se puede observar que la OC0 entre A0 y Z0 naturalmente también puede recibir soporte en ambos sistemas terminales cada uno por un MHOM, o sea MHOMO y M' (véase la figura 3). En este caso ambos MHOM pueden efectuar cuando es posible un procedimiento, en caso necesario, de forma autónoma, de "reenrutamiento" de la conexión de capa 3, L3, de la OC0, entre sí para, por ejemplo, abaratar o mejorar el coste de su PTC o mejorarlo de alguna otra forma.

Volviendo a la afirmación anterior de que el procedimiento de navegación por la red en el caso de navegación por la red soportada para el que llama dificulta considerablemente el uso fraudulento de Internet y de manera más general a unos aspectos técnicos de comunicación (relativos a la seguridad) del procedimiento según la invención.

Esta afirmación con respecto a que el uso fraudulento de Internet se ve dificultado resulta acertada puesto que cada uso fraudulento de este tipo puede perjudicar seriamente al operador del MHOM M0, que es más fácilmente identificable (porque, por ejemplo, está estacionario durante un período más largo) de modo que el operador se protegerá de tales abusos concediendo el acceso a su MHOM sólo a personas suficientemente conocidas. Además de esto, se podría usar una variante de implementación en la que, por ejemplo,

■ sólo el MHOM M0 puede iniciar una conexión Wsurfing desde el A0, después de que se le haya informado de alguna forma distinta sobre su idoneidad, posiblemente mediante un "sistema de seguimiento A0 " o activamente desde el A0 a través de GPRS o SMS etc., de modo que un lAD1 compartido ni siquiera tiene la posibilidad de empezar a establecer una conexión Wsurfing con éxito, porque para empezar cada uno de esos intentos por parte del del MHOM M0 se le notificarán como denegados en el IAD0 local, o

■ un dispositivo terminal móvil desconocido en el IAD1, en este caso, por ejemplo, A0, cuando quiere usar para el Wsurfing el IAD1, no define su MHOMO individual (por ejemplo, mediante una llamada corta inicial "a ciegas" a éste), sino que el IAD1 reenvía todas las peticiones de este tipo de personas que le resultan desconocidas estereotípicamente a un servidor de comprobación de identidad en el que confía y éste es entonces el que establece la conexión de capa 3, L3, cuando sea necesario, a través de sí mismo con el MHOMO, en donde este servidor de comprobación de identidad se pone a disposición del IAD1 posiblemente mediante una institución de tarjetas de crédito o un operador de Internet o una cadena de tiendas, etc., para su uso compartido.

El procedimiento de navegación por la red permite, por tanto, la implementación de procedimientos totalmente distintos que exonera a un operador de lAD compartido de todos los riesgos legales durante la navegación "VolPsurfing" o "IPTVsurfing", tal y como también puede denominarse la tecnología según la invención. Las reivindicaciones de procedimiento dependientes relevantes orientadas a la seguridad concretan esto a modo de ejemplo. Resulta evidente a partir de esto que el ámbito de protección del procedimiento Wsurfing permite formas de ejecución especiales del mismo que eliminan estos riesgos conocidos de compartición de WLANs prácticamente por completo.

En este contexto, se hace referencia como conclusión terminar al estado de la comunicación CS. Éste se puede modificar, por ejemplo, temporalmente/espacialmente/por control remoto, por así decirlo "autónomamente" y con ello también la permisibilidad/no permisibilidad/viabilidad de una conexión de navegación por la red entre un A0 y su IAD0 local, aunque A0 no haya variado su posición en absoluto. Hacia el final, la Sección C contiene más al respecto. C. Definición de los términos/conceptos y descripción del modelo OSI RM del procedimiento de navegación por la red, así como sus MHO, ComMeMHO y su "correlación CI"

Las descripciones de esta memoria descriptiva del procedimiento/aparato según la invención son, al igual que los términos y conceptos, meramente funcionales, es decir, completamente abstractos, o sea absolutamente independientes de una implementación material. Sin embargo, a efectos de demostración se explican también ocasionalmente algunas posibles implementaciones materiales de este procedimiento, de este aparato y sus nociones/conceptos/términos. A este respecto, cabe observar que las siguientes explicaciones de estos términos/conceptos sólo sirven, en el sentido general del modelo OSI, para aclarar (la esencia) del procedimiento/aparato según la invención, es decir, ninguna aclaración fundamental de otro tipo de cuestiones relativas a la tecnología de comunicación.

Un traspaso (HO), alias un proceso HO de un sistema terminal y su PTC, es decir, su conmutación, tiene lugar entre por lo menos dos de cualesquiera redes de comunicación o puntos de acceso de una red o características de servicio en un punto de acceso de una red. La presente invención contempla, por tanto, no sólo los HO "verticales", es decir HO entre diversas redes, sino también los HO entre puntos de acceso y/o características de servicio de la misma red, conocidos como HO "horizontales" y cualquier combinación de todos los tipos de HO mencionados anteriormente. Conceptualmente (es decir, de manera meramente funcional, completamente abstracta)

■ un "proceso de comunicaciones" abstracto, alias "proceso de telecomunicaciones, PTC" se produce entre varios de sus "suscriptores" (SUBC) humanos y/o no humanos, que por su parte son "usuarios", o sus representantes/funcionalidades parciales/funcionalidades complementarias, como, por ejemplo, contestador automático, buzón de correo, reproductores MP3, sistemas IVR, procesadores/generadores de escritura a máquina/de escritura a mano/gráficos/símbolos, voz/generadores DTMF/reconocedores DTMF/Intérpretes/filtros de tipo activo y/o pasivo, en general: "sistemas de aplicaciones de comunicaciones" (véase más adelante) de "sistemas terminales" (véase más adelante) y pertenecen a estos, por lo que estos sistemas terminales tienen acceso a al menos una red. Las redes/sistemas terminales/usuarios consiguen colectivamente la implementación técnica (abstracta) de los PTC.

Por lo que se les denomina:

o un proceso de comunicaciones, alias PTC,

❖ "potencial" si se ha aplicado efectivamente una acción concreta para el mismo en al menos un sistema terminal PTC implicado en el mismo, pero aún no en ningún dispositivo de su sistema terminal PTC, (es decir, sólo en al menos un PCT SUBC en al menos uno de estos sistemas terminales PTC y esto puede ser en el mismo todavía “vagos de alguna manera", es decir, por ejemplo, una intención de ello o incluso sólo el deseo o la necesidad),

❖ "actual", si esto ya ha sucedido en al menos un dispositivo terminal de este tipo y

❖ "iniciado" alias "empezado" en cada uno de ambos casos,

❖ "retrospectivo" alias "terminado" si ya no se está produciendo para el mismo ninguna acción concreta en ningún dispositivo terminal PTC que participa en el mismo,

❖ es decir "está presente" alias "existe" en todos estos casos.

Se debe tener en cuenta que un PTC se habrá iniciado o empezado a más tardar cuando en al menos un dispositivo terminal (por ejemplo, un teléfono) de uno de sus sistemas terminales se ha iniciado/comenzado al menos una acción que le afecta, (por ejemplo, descolgar el auricular del teléfono o la introducción/salida local o incluso sólo la selección local de un número de teléfono de la persona a la que quiere llamar alguien que participa de alguna manera en el PTC, o la puesta en marcha manual o automática de un temporizador que al expirar da lugar a una llamada etc.)

o un PTC actual que estará

❖ "en un estado conectado" hasta que haya empezado en el mismo un intercambio de datos SUBC, ❖ "empezando a funcionar" tan pronto como este intercambio de datos SUBC haya comenzado, y ❖ "funcionando" tan pronto como el intercambio de información SUBC haya comenzado,

en donde un "intercambio" ha comenzado en cuanto haya comenzado el intercambio de al menos un "dato SUBC" o una "información SUBC" de un PTC SUBC entre al menos un sistema terminal PTC y al menos una red usada actualmente por este último. A este respecto, un dato SUBC o una información SUBC es una información que el SUBC puede percibir/generar en destino/origen que a través de este sistema terminal ha sido visualizada o introducida o seleccionada por medio de este sistema termina al/por este SUBC (ya sea humano o no humano).

La diferencia entre un dato SUBC y una información SUBC consiste en que

o los datos SUBC, por norma general, sólo se intercambian para una gestión eventualmente necesaria (= establecimiento, interrupción, ..., finalización) de un PTC o su conexión OSI o sus conexiones Li, o sea, por norma general, durante un estado de conexión Li y/o la puesta en marcha de ésta,

o mientras que la información SUBC se intercambia para cumplir con el objetivo de un PTC, o sea durante su funcionamiento, es decir no durante el establecimiento/gestión técnica como en el caso anterior, en ambos casos entre sus (cuando sea aplicable, en cada uno) SUBC o los representantes/funcionalidades parciales etc. mencionados anteriormente.

■ las nociones/conceptos/términos tecnológicos de comunicaciones usados en esta solicitud de patente están definidos en el estándar internacional "ISO 7498-1 Information technology - Open Systems Interconnection - Basic Reference Model: the basic modef abreviadamente: modelo de referencia ISO/OSI u OSI-RM. Para el experto en la materia pertinente forma los fundamentos vinculantes intelectuales/conceptuales de esta solicitud de patente. Los enunciados sobre el procedimiento/aparato de navegación por la red según la invención en la mayoría de las reivindicaciones se sustentan a pesar de su redacción en "pseudolenguaje natural" en los conceptos/terminología definida en el OSI-RM, han experimentado, por tanto, ya las precisiones/limitaciones de la tecnología del OSI-RM, que eliminan muchas de las indeterminaciones de su significado "puramente del lenguaje natural".

La descripción del procedimiento/aparato de navegación por la red según la invención usa términos/conceptos del modelo OSI-RM aún más amplios, como, por ejemplo, conexiones OSI/PDU/SDU/Capas/conexiones Li etc., que pertenecen a la terminología/conceptos del modelo OSI-RM "artificiales", o sea se han evitado en los términos/sentidos del pseudolenguaje natural de las reivindicaciones. Así la descripción hace uso de la capacidad del experto en la materia para articular sin ambigüedades a través de palabras/términos artificiales del OSI-RM (de los cuales algunos, por ejemplo, se acaban de nombrar). Esto le resultará de ayuda al experto en la materia para asegurarse de la correcta comprensión de la esencia de la descripción en pseudolenguaje natural del procedimiento/aparato de navegación por la red en sus respectivas reivindicaciones principales.

En cuanto al uso en lo sucesivo de la terminología/conceptos de OSI y en especial para las palabras/términos artificiales del modelo OSI RM en esta memoria descriptiva escrita se hace notar de antemano que estos últimos

o por un lado, no se pueden recapitular completamente, de modo que en su lugar se hace referencia al estándar internacional antes mencionado y en caso de duda, prevalecerá la presente memoria descriptiva escrita, y o por otro lado, en algunos sitios en relación con las condiciones en caso de un MHO se ha simplificado algo o se ha explicado más a grosso modo (véase más adelante y la sección D).

Y finalmente se recalca que recurrir a la terminología/conceptos del modelo OSI RM en esta solicitud de patente es indispensable: la "jerga de Internet" que hoy domina en la práctica no dispone, ni por aproximación, de la terminología específica deseable para los documentos legales, para alcanzarla y, en cualquier caso, para mejorar la confusión conceptual/lingüística habitual en la tecnología de comunicaciones en última instancia se desarrolló el modelo OSI RM. Los sentidos específicos de los términos de esta solicitud de patente sirven, por tanto, no sólo para establecer el sentido de su principal reivindicación, sino también para facilitar/especificar la comprensión de sus descripciones del procedimiento/aparato según la invención y, de manera más particular, para impedir los posibles intentos de sortear el ámbito de protección solicitado que consistieran en querer reducirlo por medio de limitaciones sólo porque en la presente solicitud de patente no quedan expuestos como inadmisibles, tan solo por medio de estas descripciones.

Por lo demás, es necesario no confundir

o la absoluta necesidad enfatizada en el párrafo anterior de recurrir al modelo OSI RM

o con el conocimiento que también es la base del modelo OSI RM de que una descripción clara de un sistema complejo, de cualquier procedencia, de todas formas, requiere su abstracción de sus múltiples detalles de implementación (material) y de su focalización incondicional en su funcionalidad (poro sea, de abstracción = abstracta),

Más bien, el modelo OSI RM podría y puede basándose tan sólo en estos fundamentos, o sea cuando se observa el requerimiento mencionado en último lugar, definir las nociones, conceptos y términos elementales que resultan muy útiles e incluso necesarios para una clara descripción de muchos aspectos, especialmente de los sistemas de comunicaciones.

■ en cada "proceso de comunicación de n puntos" n>=2 entre cualesquiera dos de sus sistemas terminales, por ejemplo, A0 y Z0, hay una "conexión OSI" abstracta, que también se extiende a los sistemas de aplicaciones de comunicaciones en estos dos sistemas terminales, como se explica más adelante. Cada conexión OSI siempre se subdivide fundamentalmente, según el modelo OSI RM, en siete "conexiones Li" abstractas (1<=i<=7) "una sobre otra" por medio de las cuales este PTC tiene lugar entre estos dos sistemas terminales A0 y Z0 (en donde "L" representa "capa").

El modelo OSI RM define así, en base a sus "7 capas" de "semántica de abstracción" en principio siempre idéntica de sus conexiones Li en cada conexión OSI, la "arquitectura de comunicaciones OSI", que por su parte se basa en esta "estructura de 7 capas" de la semántica de la abstracción fundamental de todas las conexiones OSI. El modelo OSI RM denomina a cada una de estas 7 capas de abstracción fundamentales de su arquitectura de comunicaciones, totalmente independiente de las conexiones OSI individuales, obviamente “Li", respectivamente, 1 <=i<=7.

Pueden existir varias conexiones Li para cada "i" en cualquier conexión OSI individual. Cada una de estas conexiones Li tiene que usar para su implementación al menos en una conexión Lj de la misma conexión OSI, en donde siempre j < i, excepto cuando

o una conexión L7 (es decir i=7) que puede usar para esto otra conexión L7 y

o una conexión L1 que usa para esto, como norma general, un "medio físico"

en donde una conexión Lk (1<=k<=7) puede ser usada por varias conexiones OSI o en una conexión OSI de varias conexiones Lk+i (1<=I<=7-k).

Una conexión L7 de una conexión OSI se denomina a menudo "conexión de comunicaciones" ya que en ella lo único de importancia es la "comunicación" en el sentido del proceso de telecomunicaciones específico en el que se basa esta conexión OSI o el "sistema de aplicaciones de comunicaciones" que le da soporte (este último situado en al menos ambos sistemas terminales de la conexión OSI). Es decir, una conexión L7 abstrae completamente las modalidades de la transmisión de información (= funcionalidad L1 a L4) usada en esta comunicación, de un sistema de aplicaciones de comunicaciones en el que, cuando es necesario, SUBC humanos operan en el mismo, la subdivisión de la información (= funcionalidad L5) y la presentación de la información (= funcionalidad L6): Una conexión L7 solamente conoce las "interacciones" en esta comunicación de la "aplicación de comunicaciones". Esta conexión OSI "existe" entre A0 y Z0, en cuanto unos de los SUBC del pTc , en uno de sus dos sistemas terminales (PTC) A0 y Z0 haya iniciado este PTC, o sea en cuanto exista este PTC, es decir: ambas (OC0 y su PTC0) pueden ser en este instante "potenciales" (véase lo que antecede). En concreto, desde ese momento existe la conexión L7, de estos A0-OC0-Z0 para este PTC0 entre A0 y Z0. Este seguirá entonces existiendo hasta que ambos SUBC del PTC consideren este PTC terminado (lo que en el modelo OSI RM se habría de entender como finalización de esta conexión L7 y de la conexión OSI). El PTC también sigue existiendo entonces como PTC "retrospectivo" (véase lo que antecede), o sea, es por así decirlo original, en comparación, con su modelización por OSI RM.

En otras palabras: "existe" una conexión OSI (de un PTC)

o localmente, no sólo entre los dos sistemas terminales (PTC) A0 y Z0, más exactamente: entre estos dos sistemas terminales A0 y Z0 existe la conexión L3 de esta conexión OSI, sino que a través de su conexión L7 también existe entre los sistemas de aplicación de comunicaciones e incluso entre los SUBC del PTC en estos dos sistemas terminales A0 y Z0, y

o temporalmente en cuanto se haya iniciado este PTC en uno de sus SUBC, más en particular, la conexión L7 de esta conexión OSI existe desde ese instante de tiempo entre los SUBC de este PTC, y sigue existiendo hasta que estos dos SUBC consideren que este PTC ha terminado.

En consecuencia, esta conexión OSI existe a más tardar desde el instante de tiempo en el que se produce cualquier acción para ello en un dispositivo terminal del sistema terminal del SUBC (PTC) que lo crea en Ao o Z0. Según él modelo OSI RM y en el sentido de la presente solicitud de patente ya existe sin duda desde el instante de tiempo en el que se ha acometido en un SUBC del PTC en el que se basa y aunque solo sea profilácticamente, por ejemplo, por su comprobación explícita o implícita de la disponibilidad de un número de llamada de emergencia (posiblemente el 911) o de su disponibilidad para los que le llamen.

Cualquiera de las conexiones Li (1<=I<=7) de esta conexión OSI no necesita, sin embargo, implementarse todavía o que pueda implementarse (abstractamente) en ese instante de tiempo. La existencia de una conexión Li no implica, por tanto, su implementación (abstracta) o posibilidad de implementación. Más en general: junto con una conexión OSI existen también sus al menos 7 conexiones Li de las cuales, sin embargo, para ningún j, 1<=j<=7, una conexión Lj, y su cooperación con las otras conexiones Li de esta conexión OSI, necesita implementarse abstractamente (el modelo OSI RM no contempla, de todos modos, las implementaciones/realizaciones materiales). Una implementación (abstracta) de una conexión Li sólo es necesaria durante el uso actual (abstracto) de la misma.

Esto implica que la conexión OSI entre ambos sistemas terminales A0 y Z0 para este PTC sigue existiendo incluso, en particular, cuando al menos la al menos una conexión L3 para la transmisión de los datos L3 del subscriptor entre A0 y Z0 no se implementa en esta conexión OSI (abstracta y/o materialmente), como sucede a menudo en los HO. Que la conexión L7 de una conexión OSI siga existiendo en el caso de un HO (al menos su implementación abstracta o cuando sea necesario también su implementación material) se puede garantizar por medio del "procedimiento HOCIS" mencionado anteriormente (véase la Sección A y más adelante, la "correlación Cl").

■ Los "sistemas terminales" abstractos contienen además de sus usuarios humanos abstractos, y/o sus usuarios no humanos (= usuario-autómata) y/o sus representantes/funcionalidades parciales, mencionados anteriormente, todos ellos se deben entender como SUBC PTC, "dispositivos terminales" abstractos, también designados colectivamente más adelante en un sistema terminal ocasionalmente "dispositivo terminal", es decir grupos funcionales no humanos, como posiblemente, los de LAN, WLAN, supercomputadoras, bases de datos, PBX, RAS, cortafuegos, conmutadores de todo tipo aunque también los de los accesos a la red, IAD, dispositivos entradasalida. Los grupos funcionales no humanos (implementaciones abstractas o materiales) en los sistemas terminales a menudo se designan en lo sucesivo "módulos".

■ Los "dispositivos terminales" individuales abstractos de un sistema terminal pueden considerarse por separado, más en particular

o un "dispositivo terminal, terminal, de subscriptor" con su superficie de usuario electrónica/física/acústica/óptica/"lógica" (en la presente memoria descriptiva escrita, a menudo móvil, por ejemplo, en un teléfono móvil),

o un "dispositivo terminal no terminal" con su "adaptador de terminal" (TA, Terminal adapter) específico de la red para la "finalización de red" (NT = terminador de la red, "Network terminator") de esta red, en donde o un terminal de subscriptor y dispositivos terminales no terminales de un sistema terminal interactúan entre si a través de interfaces físicos/de tecnología de comunicaciones y/u otros dispositivos terminales adicionales, de los cuales, por norma general, sólo algunos están estandarizados, y

o un dispositivo terminal no terminal (e incluso su TA y su NT) pueden estar integrados en particular en un dispositivo terminal móvil terminal (por ejemplo, un teléfono móvil) de modo que el primero es entonces un móvil, asimismo.

Con respecto a este tipo de subdivisión de los sistemas terminales conformes al modelo OSI RM en humanos abstractos y dispositivos abstractos cabe destacar que el modelo OSI RM a primera vista evita una subdivisión en sistemas terminales, pero, sin embargo, en último término sí emprende la misma implícitamente después de todo claro con bastante claridad. La razón para esto es la necesidad teórica de la subdivisión de las aplicaciones de comunicaciones que por norma general se sitúan en la L7 de los sistemas terminales para entenderlas en su esencia. Esta necesidad llevó para las definiciones de la L7 (en el estándar internacional pertinente ISO/IEC 7498 de 1994 y en la idéntica recomendación ITU-T X200, entre otras, las páginas 32/33 y sus estándares internacionales correspondientes, como el ISO/IEC 9545 de 1994 y la recomendación idéntica ITU-T X.207) a la definición de la estructura funcional de las aplicaciones de comunicaciones abstractas conformes al modelo OSI RM que lógicamente implica necesariamente la subdivisión funcional correspondiente a ella de los sistemas terminales que la albergan, en cualquier caso, en el ámbito de estas aplicaciones que albergan. La subdivisión antes mencionada de los sistemas terminales OSI en esta solicitud de patente es una subdivisión funcional especial y particularmente sencilla conforme al modelo OSI (con la terminología simplificada correspondientemente que se ha presentado anteriormente/posteriormente para esta subdivisión) de sistemas terminales OSI en humanos y dispositivos terminales de distintos tipos en la misma.

■ Los "servidores" abstractos, alias "sistemas terminales servidores" alias "sistemas terminales sin subscriptor humano en el PTC" son grupos funcionales de una red o en una red, bajo la gestión de su operador de red o no, que en la presente memoria descriptiva se consideran asimismo sistemas terminales/dispositivos terminales, no subdividiéndose los segundos, sin embargo, en terminal/no terminal.

■ Los "sistemas" abstractos son o bien sistemas terminales/dispositivos terminales o bien ordenadores integrados en la red.

■ Al menos uno de estos dispositivos no terminales de un sistema terminal y por tanto éste tiene "acceso" a más de una red (o a un punto de acceso a la red de una red o a una característica de servicio de la red en un punto de acceso a la red de una red), para que pueda ejecutar un HO, véase más adelante, y más concretamente a través de un "punto de acceso" respectivo de una red. Como estos dos términos a menudo se malinterpretan (que le resultan conocidos al experto en la materia pertinente) se aclararán sus dos sentidos en primer lugar (en cualquier caso, en la medida necesaria para esta solicitud de patente):

Esta definición profesional de "acceso" (llanamente) reza: un sistema terminal/dispositivo terminal tiene en un instante de tiempo una funcionalidad de "acceso a su red" cuando en ese instante de tiempo se puede comunicar en las capas OSI L1 a L3 de su conexión con un punto de acceso funcional de esta red, en el sentido de que puede llevar a cabo la transmisión de datos en particular con todos los sistemas terminales/dispositivos terminales de esta red que en este instante de tiempo también tienen funcionalmente acceso a la misma. De ello se desprende que un sistema terminal/dispositivo terminal de una red no tiene necesariamente que tener acceso permanente a ésta, como es de conocimiento general, este es a menudo en el caso de los sistemas terminales/dispositivos terminales de redes móviles.

Un "punto de acceso" a esta red es, a este respecto, un lugar de traspaso de la responsabilidad legal/comercial/técnica, para la capacidad funcional de estas tres capas en las secciones de transmisión de datos (DÜA) de esta conexión, del operador de esta red a los responsables de este sistema terminal/dispositivo terminal y sus DÜA. El dispositivo de finalización abstracto del lado de la red de estas DÜA en el punto de acceso se llama "Terminador de Red" ("network terminator" NT), el dispositivo de finalización abstracto del lado del usuario de estas DÜA en el punto de acceso se llama "Adaptador de Terminal" ("terminal adapter" TA). Estas dos unidades de funciones conceptuales, NT y TA, pueden estar tan integradas como sea posible en una implementación material de un punto de acceso de red, como es generalmente el caso de los teléfonos móviles. (Cabe destacar en particular con respecto a los teléfonos móviles: cuando esta capacidad de un teléfono de red móvil para un "HO directo de red móvil" se refiere a una red GSM/CDMA/satélite, por un lado, y, por otro lado, se refiere a una red WLAN, actualmente a menudo se denomina "teléfono FMC" (FMC = fixed mobile conversión): soporta entonces concretamente en una llamada telefónica el uso tanto de la tecnología actualmente llamada de manera coloquial de redes fijas, WLAN/VolP, como la tecnología denominada tecnología de red móvil, GSM/CDMA/satélite).

Después de esta aclaración de los términos "acceso" de red y "punto de acceso" de red con respecto a cómo habitualmente los entendería legalmente el experto en la materia pertinente, éste también sabe que estos términos se pueden expresar con otros conceptos que entonces si necesitarían la denominación explícita del respectivo "modelo de referencia" (véase J. Schiller, sección A), está claro que un sistema terminal/dispositivo terminal, en particular un teléfono móvil, que pueda estar directamente implicado en un HO, por norma general contiene un dispositivo terminal y al menos tres no terminales:

o su dispositivo terminal, terminal, sirve por definición primordialmente para implementar la interfaz de usuario funcional acústica/óptica/mecánica de un proceso de comunicaciones

o sus tres dispositivos terminales no terminales son necesarios, por norma general, para que pueda cooperar con las dos redes/puntos de acceso/características de servicio distintas durante un HO: consisten en un "conmutador" funcional para la transmisión de datos funcional entre su dispositivo terminal, terminal, por un lado, y, por otro lado, cada TA/NT funcional de/para la respectiva red móvil.

Esta aclaración del término punto de acceso debería finalmente eliminar, al menos en esta solicitud de patente, una confusión de concepto que surgió a partir del término "punto de acceso inalámbrico ("Wireless access point, WAP)" de las recientes publicaciones técnicas relacionadas con la tecnología de Internet en movilidad con respecto a dos aspectos:

o por un lado, este término "punto de acceso inalámbrico (WAP)" se usa erróneamente como sinónimo de "dispositivo de acceso integrado (IAD)", o sea como sinónimo de un dispositivo. Un dispositivo (abstracto o material), sin embargo, es conceptualmente algo totalmente distinto a un conjunto de puntos de traspaso de la responsabilidad jurídica relevante en las capas Li de una conexión OSI, es decir, un "punto de acceso" de esta solicitud de patente.

o por otro lado, el acrónimo "WAP" representa ya desde hace muchos años algo totalmente diferente en el campo de la tecnología inalámbrica, concretamente "protocolo de aplicación sin hilos" ("Wireless Application Protocot), que no tiene nada que ver con ningún concepto de "punto de acceso", porque las aplicaciones están situadas en la L7, mientras que los puntos de acceso de la red de los diferentes sentidos posibles, por norma general, están situados en las capas L1-L3 (y en el medio físico que están por debajo de las mismas).

■ un "HO" alias "proceso HO" de un sistema terminal y su PTC (y los OC de ambos), en una analogía adecuada con el PTC anterior (véanse los detalles ahí), se denomina

o "potencial" si para el mismo no se han ejecutado todavía ninguna de sus acciones de conmutación en un dispositivo terminal, pero al menos alguna que otra acción para este en el mismo (por motivos irrelevantes en este caso y de una forma aquí irrelevante) y/o se ha abordado ya en un sistema terminal, y

o "actual" cuando para el mismo ya ha tenido lugar tal acción de conmutación en un dispositivo terminal, en donde este sistema terminal/PTC se denomina entretanto "relacionado" con este HO y "conmutación" designa una alteración en el caso de una red (y su PTC y los OC de ambos) y/o del punto de acceso de red y/o de la característica de servicio de red que usa este sistema terminal durante e1HO. Un HO potencial se convierte en actual en cuanto para él en al menos uno de sus dispositivos terminales al menos una de dichas acciones de alteración se "inicia"/"empieza" y un HO actual está "en marcha" tras esto hasta que la ejecución de todas estas las acciones de alteración concluya, con éxito o sin éxito.

■ Ambos sistemas terminales de una conexión OSI de un PTC pueden pertenecer a dos redes diferentes, como se muestra en la figura 1, de modo que un "sistema de tránsito OSI" abstracto "releve" (= "red¡r¡ja"/"v¡ncule"/...) esta conexión OSI entre estas dos redes. La presente solicitud de patente considera este "sistema de relevo" abstracto a menudo como un sistema terminal de ambas redes y en cualquier caso como un "sistema de tránsito" de las conexiones OSI relevadas a través del mismo. Este "relevo" abstracto se realiza según la invención para al menos una de las conexiones Li abstractas, 1<=I<=7, de una conexión OSI, en el caso de que en este sistema de relevo haya varias conexiones Li relevadas por esta conexión OSI cuyo relevo se produzca de manera individual y/o colectiva.

Cabe destacar en este caso que esta funcionalidad de relevo de un sistema de tránsito se puede extender también a al menos una conexión OSI potencial, o sea, en particular, a la creación de una implementación (abstracta y/o material) de al menos una de sus al menos 7 conexiones Li. Un ejemplo de un sistema de relevo de este tipo es la pasarela VolP conocida comúnmente entre Internet y la red pública telefónica conmutada (PSTN)/ISDN/UMTS) a través de la cual se releva una llamada/conversación telefónica entre A0 y Z0 (en cualquier caso, en parte) cuando A0 es el sistema terminal en Internet y Z0 es el sistema terminal en la PSTN/ISDN/UMTS. El experto en la materia sabe también que las conexiones Li de una conexión OSI entre A0 y Z0 pueden transcurrir, temporal o permanentemente, a través de varios sistemas de relevo: en este ejemplo además de la pasarela VolP posiblemente a través de un servidor SIP.

Otro ejemplo de un sistema de relevo de este tipo es el WLAN-IAD en Internet. Éste se comunica en las capas L1-L3 con los sistemas terminales WLAN por medio de los protocolos "WLAN de interfaz de aire" de este IAD mientras que para la comunicación con los sistemas terminales de Internet en L1-L3 usa los protocolos de Internet correspondientes, lo que puede exigir en las correspondientes conexiones Li de una conexión OSI relevada por un IAD de este tipo considerables "conversiones de datos y de protocolos". Para sus conexiones L4-L7, el IAD puede modificar los protocolos y datos durante el relevo o bien no hacerlo.

El experto en la materia pertinente es consciente de todo esto y sabe a este respecto en particular que las conexiones Li pueden tener un "túnel" para producir "direcciones IP extremo a extremo con significado" (a pesar de la movilidad de al menos de uno de los sistemas terminales de su conexión OSI, véase la Sección A). El prescindir del significado de estas direcciones IP extremo a extremo abre la posibilidad de poder situar las funcionalidades más variadas en un relevo, como, por ejemplo, mezclar varios PTC con distintos SUBC en el relevo, por ejemplo, "la adecuada superposición de los canales de audio de este PTC importante para la presente invención (más información sobre esto más adelante)" para el usuario de un sistema terminal, es decir el SUBC de este PTC, o sea cuando se prescinde de esta "capacidad de mezcla" en este sistema terminal (entre otras razones porque incluso los teléfonos FMC o los PDA o similares actuales no disponen de una funcionalidad de este tipo). Por lo tanto, es necesario distinguir si el (posible) relevo de una conexión OSI tiene que ver o no con un túnel de este tipo, de modo que hay que distinguir también para ello entre un "relevo con tunelización " con su funcionalidad limitada y un "relevo sin túneles". Un sistema puede contener/usar para una o varias conexiones OSI varios relevos de distintos tipos y entonces puede poner en práctica paralelamente estas dos tecnologías de relevo cuando sea necesario. Por consiguiente, se diferencia entre dos tipos de MHO, "MHO sin túneles" y "MHO con tunelización" en función de si un MHO necesita para ello un relevo sin túneles o incluso ningún relevo o relevo con tunelización. Implícitamente ya se ha mencionado, por tanto, que la presente invención fundamentalmente, tal y como se ha descrito exactamente en el procedimiento HOCIS, "mezcla" en un "PTC primario (PTCP) " de un sistema terminal A con un sistema terminal Z al menos un "PTC secundario (PTCS)" para el sistema A con, por norma general, al menos otro sistema Y. Los ejemplos más sencillos serían los de un PTC de la TV IP de A con el servidor de TV Z, como PTCP y entretanto una llamada VolP entrante para A desde Y como PTCS. Si se quiere poner en práctica el procedimiento de navegación por la red con los teléfonos FMC actuales, es decir, ejecutar un MHO, por ejemplo, a otra WLAN en esta situación, entonces esta mezcla tiene que quedar desplegada en este sentido en el "relevo sin túneles" mencionado anteriormente para el PTCP, lo que no excluye el uso de la tecnología de tunelización, que ofrece definitivamente simplificaciones mediante sistemas capaces de ello en el procedimiento de navegación por la red. Se habla más sobre la mezcla de al menos un PTCP con al menos un PTCS sigue después de la introducción subsiguiente de las "acciones MHO".

Por último, debería tenerse en cuenta: un MHOM de un IAD o similar puede usar en lugar de un acceso a Internet un acceso a otra red, por ejemplo, un acceso a la red PSTN o un acceso a una red WLAN diferente a través de uno de sus IAD. La tecnología de tunelización en teoría se puede emplear básicamente siempre que la información que se intercambia a través de la red vaya en paquetes, independientemente, en particular, de la tecnología de conmutación de esta red.

■ Una "especificación de HO gestionado, MHOS" siempre

o se asigna exactamente a un IAD local real o virtual (véase más adelante) o servidor local o sistema local que se designa con el acrónimo único "MIAD local", o sea, no necesita estar contenido en el mismo (en donde una cantidad de sistemas terminales locales pertenece a un MIAD local que solo el gestor del MIAD local puede definir como tales, de modo que este acrónimo es un recordatorio del aspecto de seguridad/privacidad de la MHOS),

o solo su gestor puede definir la MHOS y asignárselo a su MIAD local,

o es consciente de al menos dos tipos de "acciones gestionadas por HO, MHO-Me", que se ejecutan en su MHO por medio de un sistema terminal local controlado por la misma y concretamente por un MIAD local que contiene la MHOS o bajo su control por otro sistema, de los que al menos un tipo ocasiona una comunicación de usuario, y

o especifica la interacción de las ejecuciones de sus acciones, MHO-Me, en la ejecución de un MHO, en donde en aras de una mayor simplicidad en lo sucesivo, ocasionalmente se denomina IAD local (en lugar de "MIAD local").

En el sentido de la terminología/conceptos PTCP/PTCS anteriores del procedimiento HOCIS cada ejecución de una MHO-Me, que produzca al menos una comunicación de usuario es un PTCS.

En una aplicación del procedimiento de navegación por la red no todos los HO de un PTC en el que esta se basa tienen que ser MHO, pero la MHOS produce en este PTC al menos un MHO. Esto se controla siempre mediante al menos una MHOS, es decir en su control pueden estar implicadas varias MHOS, posiblemente definidas de manera distinta. Por el contrario, un MIAD local puede contener varias MHOS.

El objetivo de un MHOS de un MIAD local es definir cuál de sus sistemas terminales locales controla en qué MHO con respecto a cuál de estas acciones, es decir, cuáles de estas acciones se proporcionan para este sistema terminal en este MHO interactuando con otras acciones para ello. En las figuras 6 a 8 de la sección D se exponen implementaciones distribuidas de un MHOS (y del MHOM previo) y aspectos de su capacidad de ejecución. En esta solicitud de patente, pertenecen a los tipos de MHO-Me de un MHOS:

o un tipo opcional de MHO-Me, las "acciones de control MHO, ConMe", que efectúa y controla la concesión de permisos y monitorización del uso de una red x (Redx) de un sistema terminal local en un MHO y, cuando sea necesario, la creación o la gestión adecuada de una conexión/relevo de navegación por la red sin túneles (véase más adelante y anteriormente) para A0 y esta Redx, o sea, para un MHO sin túneles.

o Con otro tipo opcional de MHO-Me, con las "acciones HOCIS-m Ho , HOCISMe" (HOCIS = "HO con soporte de información de conveniencia", véase la Sección B) se controlan y producen para los usuarios de los sistemas terminales locales las acciones de soporte de la más diversa clase en relación con sus HO potenciales y actuales.

o Para las denominadas "ComMe-MHO", que pueden producirse sin túneles, cuando sea necesario, es indispensable al menos un tipo de "acción comercial MHO, ComMe" de MHO-Me, mientras que para MHO es opcional. En ambos casos un MIAD local puede realizar una gran variedad de acciones de transacciones con el control de la ejecución de una ComMe para su operador, y cuando sea necesario, para los operadores de los lAD compartidos que cooperan comercialmente con este, durante un MHO o una ComMe-MHO. De este modo la ejecución de una ComMe siempre implementa una comunicación con el PTC-SUBC, cuyo sistema terminal local haya quedado precisamente afectado por un HO, en donde es necesario que éste último se entere o no de esta comunicación (es decir, de algún modo dar acuse de recibo).

o Otros tipos de acciones MHO-Me opcionales para un MHOS o en un MHOS pueden definirse o especificarse arbitrariamente, por ejemplo, para posibilitar las más variadas superposiciones de un PTC IP TV en un PTC VolP (o al revés) y para permitir que puedan ser controladas por quienquiera que sea.

o Por razones de simplificación del propio HO, por tanto, del proceso que constituye la base para un MHO, se contemplará también como una "acción MHO-HO, HOMe", opcional.

Una única acción MHO específica de este tipo se caracteriza, por norma general, mediante un sufijo "0" (por ejemplo, como en "ComMeO" o "HOMeO") y a efectos de reconfirmación está provisto del prefijo "MHO".

Cada ComMe-MHO está "correlacionada con CI" (Cl = "información de conveniencia") en el siguiente sentido: está característica ComMe-MHO caracteriza la situación de que durante la ejecución de una acción ComMe-MHO, la ejecución de su al menos una acción MHO-ComMe asociada se produce en relación, implícitamente o explícitamente, con la ejecución de una acción opcional MHO-Me. Una ComMe en un MHO sin túneles no necesita estar correlacionada con la CI, pero puede estarlo.

Esta característica de correlación que intuitivamente quizá parezca de inmediata comprensión, de la ejecución de una MHO-ComMe con al menos una ejecución de una acción opcional MHO-Me en una ComMe-MHO, es decir, por ejemplo, "la de un ComMe con la de un HOMe y/o ConMe y/o HOCISMe..." se describirá con más precisión más adelante para no dejar dudas.

Hay que diferenciar en particular entre una correlación CI implícita y una explícita de este tipo, en donde estos dos tipos de correlación CI son completamente independientes entre sí. Una MHO-ComMeO específica (y por tanto el procedimiento de navegación por la red que usan) como al menos una de estas MHO-MeO opcionales, ambas en el mismo procedimiento de navegación por la red -

o se denominará "correlacionada explícitamente" (independiente de la secuencia de ejecución ComMeO especificada más adelante en relación con al menos una secuencia de ejecución MeO opcional específica) cuando el al menos un mensaje comunicado por la ComMeO o por esta MeO (durante la ejecución de las mismas) a al menos un SUBC describe una asociación así de cualquier tipo o se refiere a ella, y

o se denominará "correlacionada implícitamente" cuando se aplica lo siguiente: hay un PTC para este procedimiento de navegación por la red tal que para uno de sus SUBC y un HO (potencial y/o actual) de su sistema terminal

❖ hay al menos una ejecución tanto de esta MeO como de esta ComMeO y

❖ y el instante de comienzo de esta ejecución ComMeO y/o de su visualización en el SUBC queda como sigue:

> después de 3O segundos antes del punto de comienzo de la ejecución de la MeO y

> no después de 3O segundos más tarde del punto de finalización de esta última, en donde es irrelevante si/cuándo/cómo el SUBC tiene conocimiento de esta ejecución MeO.

Por medio de una correlación de este tipo de una ComMe, que el operador MIAD local efectúa, más concretamente: su MHOS, para al menos un sistema gestionado por este (y su usuario), la comunicación ComMe asociada se coloca "en la medida de lo posible" en el PTC (que constituye la base de la aplicación del procedimiento de navegación por la red eventualmente en una llamada VolP). Y esta colocación en la medida de lo posible de tal comunicación comercial (que desde el SUBC no se solicitó originalmente y, por lo tanto, posiblemente puede ser percibida por este como una molestia) se produce durante el transcurso de los procesos HO. En este caso se puede concebir, concretamente, de tal manera que no solo moleste al SUBC/PTC, "tan poco como sea posible" con estas comunicaciones comerciales, sino que este puede incluso considerarlas en este momento de ayuda, lo que mejora decididamente la aceptación/eficacia de tales comunicaciones comerciales con el cliente. Y causar estos "momentos tan favorables" en la medida de lo posible para todos los HO es el objetivo de las actividades HOCIS concebidas adecuadamente para ello. Basándose en su característica de correlación CI, que por su parte acepta todas las acciones MHO-Me opcionales como base de correlación, el procedimiento de navegación por la red posibilita, por tanto, de una forma sencilla, transformar el supuesto potencial de molestia de un HO en una llamada VolP en el potencial de negocio y de comodidad que se acaba de exponer de este HO. Esta correlación CI de ComMe-MHO podría, por tanto, considerarse creadora de conveniencia (de ahí su nombre) incluso si para su "despliegue de productividad" óptimo en un procedimiento de navegación por la red es por norma general una correlación HOCISMe.

Para concluir esta exposición sobre las ComMe-MHO cabe destacar, que los autores de esta solicitud de patente esperan que en el futuro la mayor parte de los MHO de la navegación por la red, o sea, también en aquellos casos en los que se pueda renunciar a una ComMe o a su correlación CI (véase la reivindicación 2), pondrán en práctica el uso comercial que se acaba de exponer de los HO para las ComMe ya que sus balances de costes/usos para todos los participantes implicados hablan a su favor.

Por último, para precisar aún más: esta tecnología MHOS/ComMe-MHO implementa los dos principios básicos del procedimiento de Wsurfing según la invención:

o por un lado el principio básico más bien económico de hacer de los IAD locales internos-empresariales el principal resorte de una actividad económica, conveniente y novedosa en el marco particular de las llamadas VolP, en la medida de lo posible con la participación de lAD compartidos públicos y

o por otro lado el principio básico más bien social, de poner a disposición de cualquiera una tecnología de comunicaciones más cómoda y de mejores prestaciones en todos los centros urbanos rápidamente y más económicamente para sus sistemas terminales multimedia futuros (de manera más particular, para el uso de sus capacidades IP-TV) como tan sólo es posible hoy mediante las tecnologías actuales de red móvil (basadas en GSM, CDMA, UMTS, Wimax... y sus derivadas), en donde esto permanecerá significativamente como "tecnologías de reserva" siempre que la tecnología WLAN compartida no esté disponible o no resulte económica.

Algunos ejemplos sencillos y comentarios acerca de esta tecnología MHOS/ComMe-MHO de correlación Cl pueden ilustrar esto. Por medio de una:

o función 1/MHOS0 opcional, asignada a un MIADO local, éste último decide antes o al comienzo de un HO de un teléfono WiFi A0 (qué es un sistema terminal local del MIADO local), si este puede ejecutar un MHO a un IAD1 con su PTC/OCO actual a otro teléfono Z0 (que esta relevado a través de un MHo Mo ) (= MHO-ConMe), o función 2/MHOSO opcional, igualmente asignada al MIADO local, éste informa antes o al comienzo de1HO resultante a los dos SUBC de este PTC sobre la ejecución del HO potencial y/o actual (= MHO-HOCISMe), o función 3/MHOSO obligatoria, para un ComMe-MHO, también asignada a este MIADO local, éste último pone en práctica (o su MHOS) una acción comercial, posiblemente la comunicación de una referencia de promoción al usuario del sistema terminal local del MIADO local implicado en este HO o a ambos SUBC de su PTC, en donde, esta comunicación técnica adicional tiene lugar una vez o varias veces en cualquier momento (lo que aquí es irrelevante) antes o durante o después de esta decisión previa (lo que aquí es irrelevante) (= MHO-ComMe).

Este pequeño ejemplo deja claro que la ejecución de esta MHO-ComMe se produce mejor cuando la CI-está correlacionada con la ejecución de la MHO-ConMe anterior (en donde esta correlación Cl no requiere que la ejecución de esta MHO-ConMe se comunique a uno de los SUBC del PTC), aunque ante todo con la ejecución de la MHO-HOCISMe anterior, en donde la correlación Cl, particularmente, en las llamadas VolP ahora hace uso como norma general del hecho de que la ejecución de esta MHO-HOCISMe se comunica siempre, por norma general, de todos modos, a ambos SUBC-PTC. Esto no significa, sin embargo, que el uso del procedimiento de navegación por la red sólo pueda ser posible cuando también se usa el procedimiento HOCIS: el primero se considera tecnológicamente absolutamente independiente del segundo y también, en cuanto al contenido, se pueden contemplar los MHO del procedimiento de navegación por la red en los que una correlación de Cl de una MHO-ComMe con una MHO-HOCISMe tenga poco sentido.

De modo que:

o se pueden concebir interactivamente tanto tales tomas de decisión (en base a tales MHO-ConMe) del MIADO local como también sus acciones HOCIS y comerciales definitivamente comunicativas en el sentido de lo que se conoce comúnmente, por ejemplo, de un sistema IVR, interactivo a modo de ejemplo tanto con usuarios del sistema terminal en los lAD compartidos soportados por el MIADO local como con sus otros socios comerciales.

o el MHOS puede prever para al menos un estado de comunicaciones y éste lo puede detectar/modificar/evaluar un MIADO local, por ejemplo, por medio de su MHO-Me, y puede tenerse en consideración, por ejemplo, en la decisión mencionada anteriormente y este CS puede tener el efecto descrito en tal decisión.

o estos MHO-Me controlados por MHOS del MIADO local pueden estar diseñados para ser sensibles al contexto (por tanto, se pueden concebir de maneta diferente durante un PTC/OC potencial que durante un PTC/OC en marcha) y/o de tipo multimedia (o sea, por ejemplo, después o al mismo tiempo que una señal de audio a un SUBC para copiar una información gráfica o textual en su sistema terminal en paralelo y, cuando sea necesario, sin interferir con la información de audio VolP).

o en cualquier implementación abstracta y/o material de cualquier MHO-Me, todos los tipos de MHO-Me pueden estar entrelazados entre sí tan estrechamente que no puedan ser identificados como tales tipos individuales por ninguno de sus usuarios de un sistema terminal relacionado, y

o un operador del IAD local puede, al menos para una y/o todas las entidades de sus sistemas terminales locales (por ejemplo, aquellas de sus OC y las de este último), definir MHOS que sean iguales con respecto al contenido o diferentes y puede concebirlas correspondientemente sofisticadas o muy sencillas. Lo último quiere decir: especificar en un MHO-ConMe siempre sólo limitaciones triviales (tales como, por ejemplo: "nuevo sistema anfitrión MHOM = IAD local" y "nuevo sistema terminal = sistema terminal local") y en una MHO-ComMe siempre prescriben sólo comunicaciones de usuarios triviales (como, por ejemplo

❖ "en caso de riesgo de HO para el sistema terminal Ax> "'una vez, una señal de sonido corta" y un "parpadeo ID del operador del lAD compartido actual" y un "parpadeo de la potencia de la señal" ❖ "en caso de inicio de HO para el sistema terminal Ax> "dos veces una señal de sonido corta" y un "aviso sonoro de adiós, ID del operador del lAD compartido actual" y un "parpadeo de transferencia de señal" ❖ "en caso de una finalización de HO para un sistema terminal Ax> "tres veces una señal corta de sonido" y un "aviso sonoro de hola, ID del operador del nuevo IAD compartido" y un "parpadeo de potencia de señal nueva"

❖ "en caso de un error del HO para el sistema terminal Ax> "siete veces una señal corta de sonido" y "tres veces una señal larga de sonido").

Si bien es posible pensar en la comunicación de las señales largas y cortas de audio como HOCISMe, los avisos sonoros de ID del operador del lAD compartido son definitivamente comunicaciones de información promocional (rudimentarias). Estas MHO-Me se pueden especificar globalmente para todos los sistemas terminales locales o selectivamente para sistemas terminales locales individuales de un MHOS, y esto último puede estar ya configurado de antemano fijamente (todo lo cual es, sin embargo, irrelevante en el presente documento, ya que se trata de cuestiones de concepción e implementación material de la invención).

El experto en la materia pertinente sabe que el MHOS de un operador de un MIAD local virtual o real en una implementación material (= realización) del procedimiento de Wsurfing es una especificación de este MIAD local, que el operador introduce en cualquier caso en parte o totalmente en éste o/y ya está contenida en el mismo y el operador sólo la configura y/o está preestablecida en el mismo sin posibilidad de cambio y la MHO-Me de este MIAD local, que pertenece a este MHOS, se implementa a través de la interpretación de este MHOS por parte de este MIAD local. También sabe que cualquier MHO-ComMe especial y sus especiales correlaciones de Cl no pertenecen a la esencia de la invención, sino sólo el hecho de que estén ambas en cada MHOS (según la reivindicación 1), de modo que en cualquier caso cada ComMe-MHO está caracterizada por la característica técnica muy especial de una comunicación "limitada por la correlación de Cl" entre el usuario del sistema terminal "MHO" y su MIAD local para la implementación de una MHO-ComMe de este tipo, aunque también otros MHO pueden presentar esta característica.

■ el atributo "MIAD local privado" del MHOS sirve sólo para remarcar la "privacidad" de estas acciones de gestión MHO caracterizadas previamente para y sólo para el operador de este y sólo este MIAD local. Se ha de destacar a este respecto: que el operador del MIAD local abstracto puede estar personificado por dos personas materiales diferentes, un "operador" abstracto puede representar un "operador humano material y/o un gestor humano material".

Esta privacidad excluye que una segunda parte, además de este operador de MIAD local como primera parte, se entere o establezca o modifique el MHOS privado de su MIAD local sin conocimiento y sin el consentimiento del primero. Si esta segunda parte es en particular un operador y/o gestor de una red de cualquier tipo (que no sea la red de este MIAD local) o de un servicio (que no sea el servicio de este MIAD local) entonces, estos MHOS no son ni accesibles ni comprensibles para el mismo. Esta privacidad no significa, sin embargo, que un segundo no sepa ni pueda saber de hecho qué MHOS puede asignarle fundamentalmente un operador de MIAD local. En el presente documento no se proporcionan detalles sobre la encriptación de los datos de un SUBC que en último término es necesaria para esto y ya se conocen.

■ Hay dos tipos de MIAD locales: un tipo "real y uno virtual de MIAD local", ambos tipos son posibles, cuando sea necesario, tanto en una implementación material como en una abstracta. Para cada MIAD local, el real y de masera similar el virtual, hay conceptualmente exactamente un gestor "lógico" y un operador "físico". En el caso de un MIAD local real su gestor y operador son idénticos, lo que en ambas interpretaciones no tiene que ser necesariamente igual.

■ Resulta obvio ya del uso lingüístico anterior que en esta memoria descriptiva escrita tanto los términos/conceptos "MHO", "procedimiento MHO" y "proceso MHO" como "MHO-PDU" y "PDU" (PDU = unidad de datos de protocolo) se usan cada uno de forma ocasional como sinónimos, simplificando así ligeramente la terminología en el sentido de su escasa pérdida de precisión, (aunque esto en primera instancia resulte inadmisible de por sí, ya que un "proceso" abstracto es siempre una aplicación abstracta de un "procedimiento" abstracto, es decir su "instanciación de la aplicación" abstracta).

■ Por último, se lleva a cabo la aclaración de algunos términos/conceptos adicionales adaptados a las eventualidades de esta solicitud de patente.

o "WLAN local" alias "Red local". En esta memoria descriptiva escrita un sistema terminal A0 está asignado administrativamente a una WLAN local alias una Red local y a su al menos un MIAD local, real o virtual, según la invención. A0 es para esta WLAN local/Red local/MIAD local un "Sistema Terminal local". El ejemplo más sencillo de un MIAD local/WLAN local/Red local según la invención se puede implementar por medio de un IAD WiFi/WLAN y su Sistema Terminal local A0 (una única persona con un teléfono WiFi). Este teléfono WiFi A0 puede entonces por medio de cualquier WiFi-WLAN compartida Wx alias Redx navegar por la red/Wsurfing según la invención, siempre que A0 se pueda "registrar" en la Wx/Redx (véase más adelante) y el MIAD local de A0, según la invención, contenga un MHOS/MHOM (y éste esté preparado para operar una conexión de Wsurfing con el IADx de Wx/Redx). Este término generalmente conocido de WLAN local/Red local se extiende, en esta solicitud de patente, en primer lugar, al término aquí usado WLAN/Red (véase la sección B). En segundo lugar, se extiende a los posibles Sistemas Terminales locales "no realmente" asociados, por ejemplo, los teléfonos como el A0 mencionado antes, en donde esta característica no realmente "local" de un sistema terminal puede estar causado por cualquier servidor/IAD mediante un CS (véase más adelante), posiblemente el suyo propio o el de su OC o el de su PTC o de sus otros sistemas terminales o de toda la red WLAN local o de este lAD/Servidor o... . Un CS puede tener, por tanto, el efecto de que un OC de un sistema terminal o PTC pueda o incluso deba ser relevado por un lAD/servidor, por ejemplo, con un MHOM realmente responsable de ello, incluso si este sistema terminal no es realmente un sistema terminal local de este MHOM/IAD/servidor (en el sentido antes mencionado). En esta solicitud de patente, ambos sus Sistemas Terminales locales reales como no reales pertenecen a una WLAN local/Red local/MIAD local/MHOM.

o "Registro": un sistema terminal A0 que recibe la señal electrónica, por ejemplo, de una red WiFi WLAN o de otra red, puede usar ésta para una comunicación, de manera más particular a través de Internet, por norma general sólo después de que haya solicitado permiso para utilizar esta red a al menos uno (posiblemente varios) de sus IAD o estaciones base, o ... Si se le concede este permiso, entonces A0 queda registrado en esta red. Los procedimientos o protocolos entre A0 y este lAD/estación base, según los cuales tiene lugar esta solicitud y concesión o también oferta/aceptación de derechos de uso de una red, son irrelevantes para esta solicitud de patente.

Sin embargo, se puede definir sin más: A0 se considera "accesible" en una redx si A0 está o puede estar registrado en esta redx. Cuando sea necesario, basta con que A0 esté registrado o pueda "registrarse para Wsurfing", como se explica en la sección D, en donde las posibles modalidades e implementaciones de una limitación de registro de este tipo o posibilidad de registro limitada son irrelevantes en esta solicitud de patente.

o "Conexión de navegación por la red" (NSC): ésta es al menos una conexión L3 de un segmento OC0 del OC0 entre A0 y Z0, concretamente una entre A0 y un sistema S0 de/en una WLANx/redx que sea diferente de la WLAN0 local/Red localO de A0.

o "Estado de comunicación CS": ya se ha explicado antes que un PTC/OC de una aplicación de comunicaciones específica sobre la base del procedimiento de Wsurfing (por ejemplo, con PTC con características específicas, como llamadas de emergencia o llamadas de coste reducido de todo tipo o llamadas al centro de atención al cliente o llamadas a vigilar, o llamadas de menores de edad o llamadas desde redes de área amplia o WLAN o de ubicaciones o acontecimientos o en determinados momentos específicos, o . ) se puede caracterizar mediante las características que son el resultado de que a un sistema terminal A0 de le dé un tratamiento preferente mientras navega por la red, por ejemplo, al poderse relevar su OC o incluso tenerse que relevar, por quien sea, con tal de que sea técnicamente adecuado para ello (en donde no se considera el fundamento comercial o legal o de otro tipo, de la necesidad o el sentido de este tratamiento preferente en esta solicitud de patente, sino sólo el hecho de que puede existir o no).

Este CS (por sus siglas en inglés de "communications status", estado de comunicación) también puede incluir, sin embargo, un tratamiento de relevo discriminatorio o de otro tipo de un OC, mediante cualquiera de su lAD/servidor, no obstante, hasta una negación total de relevo, es decir el rechazo de una característica "local" para las entidades.

El CS de un procedimiento/aparato según la invención o de las entidades de un OCO (véase más adelante) perjudican así tales conjuntos de características del relevo de los OC.

o "Entidades de un OCO": se entenderá por ellas en el presente documento tanto las entidades Li de sus conexiones LI como también las propias conexiones Li, la al menos una red necesaria para su implementación y, cuando sea aplicable, medios adicionales necesarios para ello.

El diagrama de flujo de la figura 4 muestra las etapas del procedimiento de la reivindicación 1. La figura 5 muestra los componentes HW/SW de los medios abstractos de un aparato según la invención de acuerdo con las reivindicaciones 14-16. Al bus (1) están conectados, por norma general: la memoria (2) para el almacenamiento de entre otros los módulos del software del MHOM-SW que contienen los MHOMS, el procesador (3) para la implementación entre otras cosas de esta funcionalidad MHOM de acuerdo con la MHOS, los dispositivos de entrada/salida (4) para la transmisión/recepción de PDU de MHO a través de al menos una red, los dispositivos de entrada/salida (5) para el intercambio de al menos una PDU de MHO entre el MHOM y al menos un módulo no MHO local funcional (cuando sea aplicable, implementado a través de un aparato de acoplamiento local con un medio de las reivindicaciones principales del aparato).

De manera correspondiente, esta memoria descriptiva escrita considera en particular que su aparato abstracto para navegar por la red consiste en componentes HW/SW funcionales abstractos, en donde esta asignación de un componente funcional del aparato de navegación por la red al HW/SW es totalmente irrelevante. Solo es importante que la implementación abstracta de los componentes funcionales de un aparato de navegación por la red abstracto pueda producirse por medio de

■ componentes HW/SW autónomos funcionales del aparato de navegación por la red o

■ componentes HW/SW de lAD/sistema terminal funcionalmente idénticos y/o funcionalmente adecuados o ■ componentes HW/SW o de otros sistemas funcionalmente idénticos y/o funcionalmente adecuados (por ejemplo, de un sistema operativo y componentes HW funcionales gestionados por este último).

Por tanto, aparte del primer caso, se produce una "compartición de recursos HW/SW abstracto" entre los componentes del aparato de Wsurfing y los componentes funcionales de los otros sistemas mencionados. Esta compartición de recursos HW/SW abstractos se puede encontrar o no en una implementación material alias realización de este aparato de Wsurfing y en el primer caso se denomina "compartición de recursos de HW/SW materiales". Es decir: una implementación abstracta de un aparato de navegación por la red en un lAD/sistema terminal abstracto del aparato de navegación por la red puede compartir el uso de componentes HW/SW abstractos funcionalmente idénticos o funcionales adecuados, por ejemplo, de un sistema operativo (y los componentes HW abstractos gestionados por este último) mediante una compartición abstracta de recursos.

En contrapartida: una implementación abstracta de un aparato de navegación por la red que deba completar un sistema terminal/IAD abstracto al que el procedimiento de navegación por la red le debe dar soporte no necesita para ello en algunas circunstancias ninguna ampliación adicional de HW de este lAD/sistema terminal abstracto en absoluto, ya que sus componentes HW abstractos son suficientes para esta implementación del aparato abstracto, es decir, esto se puede conseguir mediante la "compartición de recursos de HW abstractos, con el lAD/sistema terminal abstracto al que se va a dar soporte. Esto se puede aplicar entonces también a una implementación material de este lAD/sistema terminal del aparato de navegación por la red por medio de un lAD/sistema terminal material y de sus componentes HW materiales.

La exposición anterior del modelado de los componentes HW/SW abstractos de los medios de un aparato de navegación por la red sirve para explicar la naturaleza meramente funcional de los medios según el enunciado/contenido de las reivindicaciones, a partir de cuya implementación a través de una realización concreta "sospechosa de navegación por la red" se ha de decidir si esta última coarta o no el ámbito de protección de la presente memoria descriptiva escrita.

Esta solicitud de patente, en el momento actual, se dirige primordialmente a las realizaciones del procedimiento/aparato de navegación por la red que en relación con sus componentes HW materiales están completamente implementadas por medio de componentes HW materiales de los lAD/sistemas terminales materiales a los que se da (debe dar) soporte mediante estas realizaciones, es decir, en conjunto sólo comprenden componentes SW materiales adicionales (dependientes del aparato de navegación por la red). La implementación material de un aparato de navegación por la red de este tipo se basa, en consecuencia, en su compartición material de recursos de sus componentes HW materiales con los de los IAD/ sistemas terminales materiales soportados.

Para el experto en la materia resulta elemental que la implementación material del procedimiento de navegación por la red es absolutamente posible por medio de componentes SW materiales. Y éste también percibe al instante que todos los medios de una reivindicación de aparato de navegación por la red pueden implementarse materialmente mediante componentes SW, en la medida en que no se basen en los componentes HW abstractos de la figura 5, que por su parte pueden implementarse materialmente mediante una compartición material de recursos (véase anteriormente). El ámbito de protección de esta solicitud de patente no está limitado, sin embargo, a tales realizaciones especiales, sino que éstas pueden contener, cuando sea necesario, componentes HW adicionales específicos para la navegación por la red.

D. Descripciones más extensas de la invención

Esta sección D debe ayudar a evitar que el sentido y/o el ámbito de protección de la presente solicitud de patente se determine a partir de sus muy limitados ejemplos de realización y quede restringida a los mismos, lo que de hecho es absurdo en cuanto a la "lógica de patentes" y de manera más particular en términos del derecho de patentes estrictamente inadmisible, aunque, no obstante, le ha pasado a los autores de la presente memoria descriptiva escrita en pleitos legales relacionados con sus otras patentes y por eso se marca mucho la redacción de esta solicitud de patente, y no en base al enunciado formulado intencionadamente de manera más abstracta y por ello de mayor alcance. El punto que debe primar en el procedimiento de interpretación, es decir, del procedimiento de determinación del contenido de una patente a partir del enunciado de sus reivindicaciones (en comparación con todas las demás posibilidades de interpretación de un procedimiento de interpretación/procedimiento de determinación del contenido de una patente) está concretamente fijada sin lugar a equívoco en todas las normas de derecho de patentes.

Por estos dos motivos la sección D describe a continuación la esencia de la invención de la presente solicitud de patente también por medio de una explicación ligeramente laboriosa de sus reivindicaciones de procedimiento. Un comentario reiterativo y comparativamente intricando de las reivindicaciones del aparato después de esto no parece necesario. La sección D es, por tanto, parte de la descripción del procedimiento/aparato según la invención.

En primer lugar, un recordatorio de tres aspectos, ya mencionados parcialmente en la presente memoria descriptiva escrita:

■ las características individuales del procedimiento/aparato según la invención no están sujetas a ninguna restricción de "contexto general" de las características individuales del procedimiento/aparato según la invención, por quienquiera que pueda suponer tal "contexto general" y como quiera que pueda interpretarse, ya que no se podría justificar a partir de ninguna palabra de la presente memoria descriptiva escrita.

■ Puesto que todos los enunciados/contenidos de esta solicitud de patente definen estas características del procedimiento/aparato según la invención únicamente en su esencia, esta memoria descriptiva escrita no dice nada en absoluto sobre las variantes de implementación material de estas características en cualquier realización de la invención, más bien estas características son "funcionales" alias "abstractas", por tanto, meramente conceptuales.

■ En esta memoria descriptiva escrita (incluyendo sus reivindicaciones) la palabra "uno" (sin ninguna expresión "al menos") y todas sus conjugaciones/declinaciones/variaciones de la misma representa "al menos uno(a)", en donde esta sustitución sea de algún modo razonablemente posible.

Ahora con respecto a las reivindicaciones 1 y 2: su primer párrafo identifica los términos/características fundamentales de las disposiciones de telecomunicaciones con las que funciona el procedimiento de Wsurfing.

■ Para esto debería recordarse, por un lado, que en esta solicitud de patente un OC0 según la reivindicación 1 o 2 (véase la sección C) sólo necesita ser potencial. Un ejemplo conocido de esto es una conexión OSI que se produce conceptualmente a más tardar con la decisión de un SUBC de iniciar una llamada a cualquier número de emergencias, posiblemente el 911 o el 112, es decir existe (en sentido potencial) desde el momento en el que el SUBC (abstracto) (como parte del sistema terminal abstracto A0) piensa en llamar a ese número. Otro ejemplo de esto es una conexión OSI potencial entre el subscriptor A0 y un subscriptor Z0 potencial para el que al primero le gustaría estar accesible si el segundo le llama, en donde para el instante de tiempo del MHO se asume que efectivamente habrá tal subscriptor Z0, una hipótesis cuya justificación resulta aquí irrelevante, (pero no está injustificada). En el caso de usar la aplicación de comunicaciones de IP-TV, su OC0 potencial existe a más tardar tan pronto como el usuario de A0 efectúe una "selección de programa" en la misma.

De este modo también se hace referencia a una abreviación ineficaz en esta memoria descriptiva escrita: cuando se hablar de un "PTC entre A0 y Z0" hay que entender siempre "un PTC entre uno de al menos uno de sus subscriptores en A0 y Z0, respectivamente".

■ Por otro lado, ya se han mencionado en el presente documento las características

o en la reivindicación 1 sobre una "MHO-ComMe" y

o en la reivindicación 2 sobre el relevo de A0-OC0 que no materializan ninguno de los procedimientos del estado de la técnica de HO o de la tecnología de Internet en movilidad: estas características de gestión HO no se conocían en absoluto hasta ahora (véase para ello las secciones A y C).

También se indican unas breves explicaciones para las etapas a)-b) de las reivindicaciones 1 y 2, de modo que debería resultar claro a priori que existen otras etapas posteriores, no mencionadas en a)-b), pero evidentes para el experto en la materia y, por tanto, no merece la pena mencionarlas en el presente documento, si bien son necesarias para la navegación por la red.

■ La ejecución de un MHO de A0 en una redx según la reivindicación 1/2 es iniciada por la ejecución al menos una vez de la etapa de comprobación a) por su descubrimiento de la "presencia de una señal de accesibilidad de A0 en la redx". Puesto que las descripciones anteriores de la invención no limitan en ningún sitio esto, el sentido de este enunciado a) es precisamente el que se podría esperar: hay una señal, de cualquier tipo y es descubierta donde fuere y cómo fuere, cuya presencia significa que: A0 puede comunicarse en la redx, puesto que A0 está o puede registrarse en ella, por medio de sus IADx o BSx y su MIADO local con todos los sistemas terminales en el conjunto de Internet y es accesible para ellos en la redx (véase el principio de la sección B y el final de la sesión C).

■ Una implementación abstracta o material de las etapas a)-b) puede efectuar un solapamiento suyo temporal de cualquier modo, el experto en la materia pertinente conoce, por ejemplo, que un procedimiento de comprobación preliminar separado en a) no es necesario para ejecutar a) y b). En particular se puede llevar a cabo según el enunciado/sentido una ejecución de la comprobación a) una vez o varias veces.

■ La ejecución según la reivindicación 1 o 2 de un MHO puede requerir/implicar/usar, en una implementación material, además de las etapas a)-b), otras etapas que, cuando sea necesario, pueden producirse automáticamente y/o comprender MHO-Me opcionales adicionales o alternativas, tal como, por ejemplo, para el uso de IP-TV. Es decir, las reivindicaciones 1 y 2 no mencionan absolutamente nada de cualesquiera cuestiones de la implementación material de sus procedimientos, por ejemplo, cuándo, cómo y bajo qué condiciones se puede y/o se tiene que producir el registro efectivo de A0 en la redx. Para el experto en la materia pertinente resulta claro, sin embargo, que en algunas circunstancias ninguna de las etapas del procedimiento, necesarias para el registro, se tienen que ejecutar para que el MHO se pueda iniciar y/o efectuar y/o completar según a)-b) (como podría ser posible, en particular, con la implementación del protocolo IPv6 de Internet en sistemas terminales/IAD/Bs/...). Es decir: el procedimiento Wsurfing puede transcurrir completamente y de manera repetitiva, aunque el navegante o su sistema terminal no estén registrados en ningún sitio o en cualquier caso no en los IADx/BSx reales o virtuales, distribuidos o implementados localmente, que está ejecutando de manera profiláctica cuando sea necesario. Lo mismo se aplica para su establecimiento profiláctico y/o mantenimiento de una conexión de navegación por la red NSSC0 completa o parcial para A0 y la A0-OC0 y/o la conexión IP-TV y/u otras conexiones MHO-Me opcionales para A0 (por ejemplo, para cualquier referencia relevante para la seguridad a su usuario y/o supervisor de seguridad en otro lugar) antes de que A0 se registre en y/o salga de la redx, en donde el usuario A0 descubre la profilaxis de este tipo y/o hace uso o no de la misma).

Por tanto, para el experto en la materia pertinente ninguna de las variantes del procedimiento según la invención, de las que en el presente documento se han mencionado explícitamente sólo algunas a modo de ejemplo, queda excluida del enunciado/sentido de la reivindicación 1/2 y de su descripción en esta solicitud de patente. Esto significa que el enunciado/sentido de la reivindicación 1/2, en cualquier caso, como resultado de esta descripción del procedimiento según la invención, comprende todas estas variantes.

■ El procedimiento de Wsurfing según la reivindicación 1 permite usar ambos procedimientos de relevo (tanto el relevo sin túneles como el relevo con túneles, véase para ello la reivindicación 3), no contiene, por tanto, ninguna limitación en cuanto a la "libertad de túneles" para ello. Sin embargo, su MHO está sujeto a una limitación con respecto a la reivindicación 2, en la medida que tiene que implementar una ComMe y su correlación Cl. No obstante, en la práctica, estas limitaciones no aparecen como tal, sino como una ventaja del procedimiento de navegación por la red (véase la sección C para las ventajas de una ComMe y su correlación Cl en un MHO).

■ Un relevo abstracto se refiere a cada bit transmitido en A0-OC0. Sin embargo, cada implementación material del procedimiento de navegación por la red procederá de tal manera que necesita garantizar la implementación de esta característica de relevo "sin túneles" solo para ciertas condiciones (tal como el volumen en la información transmitida en el A0-OC0). El experto en la materia pertinente sabe cómo ocurre esto y en qué circunstancias y por qué esto resulta razonable.

■ En relación con el enunciado/sentido de la reivindicación 1/2 se señala finalmente que

o las variantes de la implementación abstracta o material de una "gestión según la MHOS de una ejecución de HO' (bajo el control del MIADO local virtual o real implementado de manera local o distribuida y sus respectivas partes MHOS), en cualquier caso después de las aclaraciones anteriores, resultan conocidas para el experto en la materia pertinente y por tanto resultan irrelevantes en el presente documento, que, por tanto, en relación con su implementación abstracta o material no queda limitado de ninguna manera en absoluto y

o la "comunicación comercial adicional'

❖ ni requiere un intercambio adicional de PDU (sino que puede producirse mediante un intercambio de PDU que, de todos modos, es necesario),

❖ ni está limitada en relación con la red usada para la misma (puede usar, por tanto, una red diferente a la que de todos modos usa).

Con respecto al ámbito de protección de la reivindicación 1 o 2 este implica en particular: que en cuanto una realización descubre la presencia de una señal según a) por medio de algún no MHOM (supuesto) (que en la presente memoria descriptiva escrita no está limitado de ninguna forma) y, por tanto, la ejecución con éxito de la etapa b) se lleva a cabo de alguna forma, entra (conjuntamente con este no MHOM) en su ámbito de protección.

Mediante las cinco figuras 6a-e se proporcionan, además, algunas aclaraciones básicas con respecto a las disposiciones de telecomunicaciones, en las que el procedimiento de navegación por la red/Wsurfing puede aplicarse, en las que su MHOM y/o su MIAD local virtual o real y/o sus MHOS estén implementados de forma distribuida, de manera abstracta o material. Por simplicidad se asume en la figura 6a de que un sistema S0 con una parte de un MIAD local virtual solo puede controlar y, cuando sea necesario, ejecutar una ConMe y un sistema S1 con otra parte de un MIAD local virtual que sólo puede controlar y, cuando sea necesario, ejecutar una ComMe (ambas las dos por completo). Las tres figuras 6b-d solo se diferencian de la misma en la medida en que como en las figuras 6b-c respectivamente uno de estos dos y en la figura 6d ambos tipos de MHO-Me están ubicados en un MIADO local real. A este respecto cabe destacar que SO y/o S1 y sus partes de MIAD local virtual (en las figuras 6a-c) se pueden situar en una red de telecomunicaciones, cuyo operador da soporte entonces por tanto al procedimiento de Wsurfing, de modo que entonces en estos casos se puede establecer, cuando sea necesario, de una manera funcionalmente más sencilla que en la figura 6d, otro MIAD local real, de manera más particular puede ser un lAD compartido de los que se instalan actualmente (véase más adelante). Naturalmente, hay una serie de formas mixtas de estas disposiciones de telecomunicaciones prototípicas para un procedimiento/aparato de navegación por la red, que se revelan en el enunciado/sentido de la reivindicación 1/2 y de la descripción anterior. Resumiendo: todas las formas o estructuras de las implementaciones abstractas y/o materiales distribuidas del procedimiento según la invención están cubiertas para el experto en la materia pertinente por esta descripción del enunciado/sentido de la reivindicación 1/2.

De interés económico evidente, como ya se ha mencionado, resulta la integración completa con respecto al procedimiento según la invención de un MIAD local en una red, ya sea una red de telecomunicaciones o una WLAN grande o, por ejemplo, en un servidor de red, puesto que así se puede conseguir una "actualización funcional" de numerosos IAD sin capacidad de Wsurfing ya instalados con la funcionalidad de navegación por la red de una manera sencilla (= "servidor MIAD local virtual" completo). La figura 6e muestra esta disposición de telecomunicaciones con una red WLAN grande y un único servidor de MIAD local virtual. Para conseguir la "privacidad del MIAD local" deseada en este caso, es decir para garantizar que el operador/gestor de la red o del servidor que aloja el servidor MIAD local virtual no obtenga acceso a los MIAD locales virtuales alojados, la comunicación de un operador/gestor de tal MIAD local debe permanecer ininteligible para el operador/ gestor de la red/servidor del mismo modo que, en base a esta comunicación, la MHOS correspondiente almacenada en un MIAD local virtual de este tipo. El experto en la materia pertinente conoce cómo se puede conseguir esto tanto en una implementación abstracta como en una implementación material distribuida o centralizada de un procedimiento/aparato de navegación por la red, es decir su MIAD local, su MHOS, su MHOM y de los módulos que ejecutan las funciones.

Las figuras 6a-6e muestran, por tanto, posibles separaciones, es decir, posibles implementaciones distribuidas, sólo de las funcionalidades ComMe necesarias para los MHO, desde otras funcionalidades MHO-Me. Las figuras 7a-e representan para cada una de ellas una posible separación, es decir, una posible implementación distribuida, de su función de control del MIADO local a partir de un módulo funcional asociado que se ejecuta en otro sistema, por tanto, todo lo que no distribuya aún la implementación del MHOS. Las figuras 8a-e representan, por lo tanto, para cada una de las funcionalidades MHO-Me una posible separación de sus funciones de control del MIADO local desde al menos una parte del MHOS que las controla mediante su distribución en dos sistemas. En este sentido se puede considerar que al menos una parte del MHOS en sí misma es ejecutable, en cualquier caso, es interpretable.

Tales implementaciones distribuidas de este tipo, adecuadas, en último término materiales, hacen que para los operadores de grandes redes o de servidores de Internet sea más fácil ofrecer, basándose en el procedimiento según la invención, servicios multimedia de telecomunicaciones innovadores de lo más variado con todas las posibles cooperaciones, por ejemplo, con operadores de WLAN compartida y/o proveedores de programas IP TV.

Según esto resulta particularmente claro que el término "comprende" en el enunciado de las reivindicaciones no debería quedar limitado a "ahora contiene/cubre", sino que para dicho término "comprende" también se aplican otras posibilidades de interpretación razonables del lenguaje natural a este respecto, por ejemplo "guarda relación con" y/o " tiene que observarse/seguirse", y esto también incluye el futuro.

FUNCIONALIDAD ADICIONAL

A continuación, se describe una unidad funcional adicional de un IAD local/compartido, de acuerdo con otro aspecto de la invención.

La unidad funcional del lado del servidor determina información relevante de "traspaso gestionado" que está disponible en el entorno de un IAD local/compartido, y la proporciona de manera controlada a otros sistemas finales Ax para soportar sus decisiones de MHO.

La información, que puede ser recogida y proporcionada por el IAD, puede comprender, por ejemplo:

• IAD locales/compartidos potenciales en el área de recepción del IAD, así como la información sobre los servicios que ofrecen (Internet, VoIP, IPTV etc.), características de calidad, seguridad, etc.,

• especialmente información sobre el soporte y diseño de procesos MHO potenciales

• su ubicación y la ubicación de IAD adyacentes.

La determinación de información sobre IAD potenciales dentro del área de recepción se debe disponer de tal manera que no se vean afectadas las conexiones activas entre los sistemas finales y el IAD, si fuera necesario con la ayuda de una segunda unidad receptora o utilizando un procedimiento que permita recoger esta información de manera paralela sin interferencias.

No es necesario que la recuperación de información en este proceso se origine exclusivamente en el IAD, también se puede obtener información de una fuente externa adecuada (por ejemplo, una entrada de usuario o una consulta a una base de datos). Los datos ahora disponibles para el IAD local/compartido se pueden proporcionar a otros sistemas finales habilitados por el MHO para que puedan tomar una decisión de traspaso que esté adaptada a sus propios requisitos. Para esto se debe evitar, en particular, que la recogida de información por parte del sistema final sea cara y requiera mucho tiempo.

Por consiguiente, la provisión de esta información no tiene por qué producirse por completo, sino que también puede estar limitada en función de diversos criterios, que pueden depender, en particular, del sistema final que use la información.

Claims (12)

REIVINDICACIONES

1. Un procedimiento para proporcionar información al menos a uno de un primer sistema terminal (A0) con un Dispositivo de Acceso Integrado de una red local, real o virtual, (IAD0 local) y una conexión a un segundo sistema terminal (Z0), estando dicho primer sistema terminal (A0) y dicho segundo sistema terminal (Z0) conectados a través de una red y son objeto de un proceso de traspaso potencial, actual o completado, en donde el traspaso potencial está definido de manera que si para este ninguna de sus acciones de cambio se ha ejecutado todavía en un dispositivo terminal, pero al menos alguna otra acción para este ya se ha abordado en el mismo y/o en un sistema terminal, el procedimiento comprende: proporcionar al menos a uno del primer y segundo sistemas terminales (A0, Z0) información relevante para el traspaso sobre el proceso de traspaso potencial, actual o completado, en donde dicha información relevante para el traspaso incluye información sobre dispositivos de acceso integrado IAD locales/compartidos, potenciales, en un área de recepción de un IAD de una red local al que el primer sistema terminal (A0) está asignado, en donde el Dispositivo de Acceso Integrado de la red local es un WLAN-IAD.

2. El procedimiento de la reivindicación 1, en donde dicha información relevante para el traspaso comprende información sobre los servicios que ofrecen estos IAD locales/compartidos.

3. El procedimiento de la reivindicación 2, en donde dichos servicios comprenden al menos uno de Internet, VoIP, IPTV, características de calidad y seguridad.

4. El procedimiento de cualquiera de las reivindicaciones 1 a 3, en donde dicha información relevante para el traspaso comprende información sobre el soporte y diseño de procesos MHO potenciales.

5. El procedimiento de la reivindicación 4, en donde dicha información relevante para el traspaso además comprende información sobre la ubicación de dicho IAD de red local al que el primer sistema terminal está asignado y la ubicación de IAD adyacentes.

6. El procedimiento de cualquiera de las reivindicaciones 1 a 5, en donde dicha información relevante para el traspaso la proporciona un IAD local/compartido.

7. El procedimiento de cualquiera de las reivindicaciones 1 a 6, en donde dicha información relevante para el traspaso la proporciona una fuente externa a un IAD local/compartido.

8. El procedimiento de la reivindicación 7, en donde dicha fuente externa comprende una entrada de un usuario.

9. El procedimiento de la reivindicación 7 u 8, en donde dicha fuente externa comprende una base de datos.

10. El procedimiento de cualquiera de las reivindicaciones 1 a 9, en donde la determinación de la información sobre servicios se realiza sin influenciar las conexiones activas entre sistemas finales y dicho IAD local/compartido.

11. El procedimiento de cualquiera de las reivindicaciones 1 a 10, en donde el primer sistema terminal y el segundo sistema terminal participan en un proceso de telecomunicaciones primario, PTCP, en el que el proceso de traspaso potencial, actual o completado tendrá lugar, tiene lugar o tuvo lugar, y en donde la información relevante para el traspaso sobre el proceso de traspaso potencial, actual o completado se proporciona al menos a uno del primer y segundo sistemas terminales por medio de un proceso de telecomunicaciones secundario, STCP, que es independiente del proceso de telecomunicaciones primario, PTCP.

12. El procedimiento de cualquiera de las reivindicaciones 1 a 11, que además comprende proporcionar una comunicación comercial sobre una acción comercial en el primer y/o segundo sistema terminal, de modo que la provisión de información comercial se produzca en correlación con la provisión de la información relevante para el traspaso.