ES2368019T3 - Navegación por la red en llamadas voip por medio de traspaso gestionado (mhos). - Google Patents

Abstract

Procedimiento para proporcionar información, en el que un primer sistema terminal (A0) y un segundo sistema terminal (Z0) están conectados mediante una conexión OSI y en el que el primer sistema terminal está asociado a una red local que presenta un dispositivo de acceso integrado de gestión (IAD0 local) que ejecuta las siguientes etapas: - dependiendo de la presencia, cuando se da, de un traspaso potencial o actual, proporcionar una información de conveniencia con respecto a la ejecución del traspaso potencial o actual en ambos sistemas terminales antes o al comienzo del traspaso - proporcionar además una comunicación comercial para una acción comercial en el primer y/o segundo sistema terminal - proporcionándose la comunicación comercial de manera correlacionada cuando se proporciona la información de conveniencia.

Description

Objeto de la invención

Esta solicitud de patente divulga un procedimiento de navegación por la red para un sistema terminal A0, con un A0-homeIAD0 virtual o real y una conexión A0 a un segundo terminal Z0, para su traspaso gestionado, MHO, a un IADx real de una red WLANx o a un IADx virtual para una red de telefonía móvil x (IAD= dispositivo de acceso integrado). El MHO se soporta mediante el A0-homeIAD0.

Una conexión A0 es a menudo relevada a través de un módulo MHO, MHOM, que está controlada por la especificación MHO, MHOS, del A0-homeAD0. Esto ofrece ventajas tanto a los operadores del sharedIADx/A0homeIAD0 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-iFMC. Es decir, el procedimiento de navegación por la red está orientado a corto plazo a la telefonía VoIP aunque no queda limitado a ella.

A. Limitación del estado de la técnica de traspaso, HO, con respecto al procedimiento de navegación por la red

El documento US 2006/0099948 A1 expone, 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 en la descripción de su procedimiento de forma precisa, 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 community-based 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 OH 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 las características innovadoras del procedimiento de navegación por la red no quedan plasmadas en dicho estado de la técnica, es decir, que no dejan ver que sus características son adecuadas:

•

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

•

para la producción de ventajas para el operador del homeIAD/sharedIAD y para el usuario del sistema terminal ocultando estas ventajas o usos al resto de operadores de la red.

El documento GB 2287614 A describe el traspaso de un canal de voz. El usuario recibe de su estación móvil un mensaje de que el canal de voz se tiene que cambiar y a continuación elige el usuario por medio de un botón de configuración del traspaso, si el traspaso se debe impedir o no. Además, la estación móvil recibe después de cada llamada terminada un mensaje con la información del gasto realizado de la red y calcula los costes acumulados de las llamadas.

La presente invención resuelve el problema en el estado de la técnica actual según las características de la reivindicación 1 del procedimiento y de la reivindicación 8 del dispositivo correspondiente a éste.

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 WO 2008/064918) al menos en cada caso una característica técnica adicional, esto es, su relevo posiblemente sin túneles (es decir la primera característica anterior) o su comunicación técnica para la realización de una acción comercial de un operador de homeIAD-IShared-IAD, que por regla general se realiza con respecto a ambos usuarios de los sistemas terminales de una llamada VoIP, por regla general por medio de diferentes mensajes a ambos y en concreto personalizados 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 o una comunicación (comercial) adicional técnicamente correlacionada con la “información de conveniencia”, no se materializan 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/VoIP) ni en el procedimiento HOCIS ni en un procedimiento de llamada esponsorizada (“sponsored-call”) (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).

B. Descripción básica de la invención por medio de los ejemplos más sencillos

La presente solicitud de patente divulga un procedimiento de navegación por la red para un sistema terminal A0, con un A0-homeIAD0 virtual o real y una conexión A0 a un segundo terminal Z0, para su traspaso gestionado, MHO, a un IADx real en una red WLANx o a un IADx virtual para una red de telefonía móvil x (IAD= dispositivo de acceso integrado). El MHO se soporta mediante el A0-homeIAD0.

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-homeIAD0 (en ambas implementaciones distribuidas y locales), lo que ofrece ventajas al operador del sharedIADx/A0homeIAD0 y al usuario de sus sistemas terminales locales. La MHOS es privada para el operador del A0-homeIAD0 y eventualmente individual para el sistema terminal local. Este control del relevo ofrece ventajas:

•

a un operador del sharedIADx 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 homeIAD0 y con ello su operador será responsable legalmente en caso de abuso en Internet de A0.

•

a un operador del homeIAD0 y a todos los operadores del sharedIADx que cooperan con él, por ejemplo,

o las variantes de MHO de la navegación por la red del sistema terminal local IAD0-/sharedIADx y las considerables posibilidades aparejadas de reducción de costes y aumento de la calidad en su funcionamiento

o posibilidades de negocio para el operador homeIAD0-/sharedWLANx 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 y 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 eventualmente, resulta incluso invisible para estos, por ejemplo, para operadores de red intermedios) pero que no excluye un soporte del procedimiento de la 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 mencionados anteriormente, pueden encontrar sharedWLAN más abiertas y sus MHO entre otras cosas a estas sharedWLAN son más cómodos que hasta la fecha sobre todo debido a su “correlación CI”.

La funcionalidad de un MHOM (incluyendo o excluyendo MHOS), con respecto al “agente local” (“home agent”), de la tecnología de Internet en movilidad resulta ampliada/limitada a las capas 3-7 del modelo OSI para poder poner en práctica esta gestión de HO también con los teléfonos WiFi-FMC y las sharedWLAN actuales que no están especializadas en ningún tunelado adecuado y/o para poder aprovechar las ventajas mencionadas anteriormente. Esto quiere decir que el procedimiento de navegación por la red se dirige a corto plazo a la telefonía VOIP y más específicamente a la “navegación por redes WLAN” también conocida como “WSurfing” de las llamadas VoIP, 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 uso del procedimiento WSurfing, por ejemplo, en el contexto de una transmisión de televisión IP, en lugar de una transmisión VoIP o que vayan aparejadas a ella,

o por ejemplo en el contexto de un seguimiento en tiempo real del usuario de A0 orientado a la seguridad. En todas estas aplicaciones de comunicaciones todas las realizaciones subsiguientes son aplicables igualmente a la navegación por la red/WSurfing, como en el caso de la aplicación de comunicaciones VoIP. Esta última se puede contemplar, por tanto, como representativa de todas estas muchas otras posibilidades de aplicación del procedimiento o del dispositivo según la invención, por lo que en lo que sigue sólo se recordarán ocasionalmente.

Un homeIAD 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, teniendo lugar esta última:

• o por una red sin hilos y en ella una región definible arbitrariamente (por ejemplo, la región de accesibilidad de un IAD o cualquier región, eventualmente, la región completa, de una red GSM), • o mediante conexión física (por ejemplo, cable de teléfono o cable coaxial).

La implementación de una WLAN en el sentido del presente documento 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 etc., en particular la tecnología “Wifi”, y puede comprender eventualmente IAD heterogéneos (que se llamaban incorrectamente AP, (AP= punto de acceso), y/o BS de una red de telefonía móvil (BS= estación base) y se extiende por una región de accesibilidad, definida como sea, 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, es decir, 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 los componentes HW 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 (“reparto de recursos abstractos” (“abstract resource sharing”) entre estos módulos, véase la sección C). A este respecto, un MHOM puede estar montado en cada sistema anfitrión “material”, por ejemplo, se puede alojar en un IAD o sistema material de/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 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 traducir a un código equivalente semánticamente y que se puedan cargar en el sistema anfitrión y así resulten ejecutables por los componentes HW MHOM antes mencionados. Esta concepción de un MHOM resulta demasiado estricta para la discusió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 conoce 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, OCO, (véase más abajo) 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 sharedWLAN de la 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 sharedIAD de ella, 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 sin duda identificar a un responsable de una OCO 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 la comprobación de la identidad de un usuario de un teléfono sin hilos en un sharedIAD, y no el operador de éste ú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 VoIP a Z0), en caso de que se trate de una llamada de emergencia (aún estando esto pendiente de aclaración legal).

Las variantes de realización a modo de ejemplo de este aspecto legal de la forma de uso de la navegación por la red de los sharedIAD 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 en base a 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 implementadas a este respecto se discuten en las figuras 6-8 y sus explicaciones en la sección D. El núcleo de negocio del procedimiento de navegación por la red y su “correlación CI” se aclaran en la sección C.

El escenario más sencillo de WSurfing o navegación por la red se muestra en la figura 1. Un MHO inmediato o indirecto del sistema terminal móvil A0 de un proceso técnico de comunicaciones, PTC, (ver la sección C), por ejemplo, un teléfono FMC y su usuario, de su WLAN0 local, abreviadamente W0, que significa lo mismo que IAD0 local, en el W1 o W2 no disjunto con respecto al mismo o el W1 o W2 disjunto por el trayecto 1 ó 2. La conexión de capa 7, L7, de un OCO existente eventualmente, a este respecto, entre A0 y Z0 la deja sin tocar el MHO en el trayecto 1 ó 2. 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 de W0. Las particularidades adicionales resultan conocidas en la técnica de Internet en movilidad (ver la sección A).

Téngase en cuenta que de ningún modo en este caso se limita de qué manera se establece la conexión respectiva de capa 3, L3, (segmento s) entre el sistema terminal móvil A0 en W1 o W2 y el IAD0 local/servidor local 0 de W0 durante un MHO. Esta solicitud de patente comprende por lo tanto todas las posibles variantes diferentes de este establecimiento de la conexión de capa 3, L3, entre la entidad de capa 3, L3, de A0 y la del MHOMO. Si el A0 es, por ejemplo, un teléfono, esta conexión de capa 3, L3, puede producirse entonces en particular a través de su llamada a MHOMO o viceversa, o puede existir de antemano (los detalles técnicos que favorecen esto son irrelevantes aquí). 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 realización del MHOMO tiene que estar concebida de forma adecuada en la capa 7, L7, (en el IAD0).

Después de está discusión de un “MHO inmediato”, es decir de una WLAN inmediatamente 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 el sistema terminal A0 cambia, no se solapan espacialmente o temporalmente entre sí (véase las WLAN W0 y W2 así como el trayecto 2 de la figura 1).

Hay que distinguir dos casos:

•

en la región espacial o temporal en la que no existe “ninguna WLAN”, A0 (por motivos administrativos

o técnicos) tampoco puede usar ninguna red. En este caso no puede realizarse una transmisión de información en la A0-OC0 a Z0, puesto que no dispone de una conexión de capa 3, L3, directa entre A0 y Z0. Las conexiones de capa 4-7, L4-L7, del A0-OC0 son sin embargo independientes y eventualmente pueden seguir existiendo 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 A0OC0, por medio de su IADx, entre A0 y el IAD0 local/servidor local 0, (y su MHOMO).

•

en esta región en la que no existe “ninguna WLAN” A0 puede usar otra red, por así decirlo, una red sustitutiva de Wsurfing, por ejemplo 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 abajo) a esta red de telefonía móvil, se puede establecer una conexión de Wsurfing para A0 entre A0 y el IAD0 local/servidor local 0, (mediante su MHOM0) 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 (eventualmente después de una prueba de seguridad en 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 discusiones minuciosas del “sistema terminal MHO que llama” 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' por ejemplo en un IAD' entre Internet y el sistema terminal Z0. El M' posibilita la conmutación de redes WLAN de A0 y la conexión Wsurfing entre A0 y M' mediante exactamente la misma funcionalidad MHO que en M, es decir M' también es un MHOM, sin embargo, eventualmente, con reducción de la protección de abuso de Internet descrita anteriormente.

Finalmente se observa que la OC0 entre A0 y Z0 también puede recibir soporte por supuesto en ambos sistemas terminales a través de cada MHOM, o sea MHOM0 y M' (véase la figura 3). En este caso ambos MHOM pueden efectuar un procedimiento, en caso de necesidad, posiblemente 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 así de otra manera su PTC.

Retornemos 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 notablemente el uso fraudulento de Internet y más en general volvamos a unos aspectos técnicos de la comunicación (relativos a la seguridad) del procedimiento según la invención.

Esta afirmación de que el uso fraudulento de Internet se ve dificultado resulta acertada puesto que cada uso fraudulento 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 abusos similares concediendo el acceso a su MHOM sólo a personas suficientemente conocidas. Adicionalmente para esto se podría emplear una variante de realización en la que, por ejemplo,

•

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

•

un dispositivo terminal móvil desconocido en IAD1, en este caso por ejemplo A0, cuando quiere usar para el Wsurfing el IAD1, no puede fijar su MHOM0 individual (por ejemplo, mediante una llamada corta inicial “a ciegas” a éste), sino que el IAD1 reenvía todas las peticiones 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 eventualmente establece la conexión de capa 3, L3, a través de sí mismo con el MHOMO, poniéndose esta comprobación de identidad a disposición de IAD1 para su uso compartido por ejemplo a través de un instituto de tarjetas de crédito o un operador de Internet o una cadena de tiendas, etc.

El procedimiento de navegación por la red permite, por tanto, la implementación de procedimientos totalmente distintos que exonera a un operador de sharedIAD de todos los riesgos legales de “VoIPsurfing” o “IPTVsurfing”, llámese la técnica según la invención como se quisiese. Las reivindicaciones de procedimiento dependientes relevantes orientadas a la seguridad concretan esto a modo de ejemplo. Se ve que el ámbito de protección del procedimiento Wsurfing permite formas de realización especiales que eliminan estos riesgos conocidos de WLANsharing prácticamente por completo.

En este contexto, haremos referencia para terminar al estado de la comunicación KS. É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/sentido de una conexión de navegación por la red entre 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. Aclaración de los términos/conceptos y descripción del modelo OSI del procedimiento de navegación por la red así como sus MHO, GeMaMHO y su “correlación CI”

Las descripciones del procedimiento o dispositivo según la invención en el presente documento son, al igual que los términos y conceptos, puramente funcionales, es decir, completamente abstractos, o sea absolutamente independientes de una implementación material. Sin embargo, por motivos de su inteligibilidad se explican también ocasionalmente algunas implementaciones materiales posibles de este procedimiento, de este dispositivo y sus nociones/conceptos/términos. A este respecto, hay que observar que las siguientes aclaraciones de estos términos/conceptos sólo sirven (en el sentido general del modelo OSI) solamente para la aclaración (de la esencia) del dispositivo o procedimiento según la invención, es decir, ninguna aclaración fundamental de otro tipo de cuestiones de tecnología de comunicación.

Un traspaso (HO) o un proceso HO de un sistema terminal y su proceso PTC, o sea su conmutación, se produce entre por lo menos dos 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 todas las combinaciones de las formas de HO mencionadas anteriormente.

Conceptualmente (es decir de manera puramente funcional, completamente abstracta)

• un “proceso de comunicaciones abstracto” o“proceso de telecomunicaciones, PTC” se produce entre varios de sus “participantes” (TLN) que pueden ser personas o no, 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: son “sistemas de aplicaciones de comunicaciones” (véase más abajo) de “sistemas terminales” (véase más abajo) y pertenecen a ellos, teniendo acceso estos sistemas terminales a al menos una red. Las redes/sistemas terminales/usuarios logran conjuntamente la realización abstracta de PTC.

A este respecto se denomina:

o un proceso de comunicaciones, o PTC,

•

“potencial” en caso de que para el mismo al menos en un sistema terminal PTC participante se ha aplicado una acción concreta pero aún no en ningún aparato de su sistema terminal PTC, (es decir, sólo en al menos un PCT-TLN en al menos uno de estos sistemas terminales PTC y estos pueden ser en el mismo todavía arbitrariamente vagos, es decir, por ejemplo, una intención de ello o incluso sólo el deseo o la necesidad),

•

“actual” en caso de que al menos en un dispositivo terminal de este tipo esto ya haya sucedido y

•

“inicializado” o “empezado” en cada uno de ambos casos,

•

“retrospectivo” o“terminado” en caso de que no se produzca para el mismo ninguna acción concreta más en ningún dispositivo terminal PTC que participa en el mismo,

•

es decir “existe” o“está presente” en todos estos casos.

Téngase en cuenta que un PTC se habrá iniciado o comenzado a más tardar cuando en al menos un dispositivo terminal (por ejemplo, un teléfono) de uno de sus sistema terminales al menos se ha iniciado/comenzado una acción que le afecta, por ejemplo, descolgar el auricular del teléfono o la introducción o salida de datos local o incluso sólo la marcación local del número de teléfono de la persona a la que se quiere llamar a través de un participante 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

•

mientras que esté “montando la conexión” hasta que haya empezado en el mismo el intercambio de datos TLN,

•

“puesto en marcha” tan pronto como el intercambio de datos TLN haya comenzado y

•

“bautizándose” tan pronto como el intercambio de información TLN haya comenzado,

habiendo comenzado el “intercambio” de datos en cuanto haya comenzado el intercambio de al menos un “dato TLN” o una “información TLN” de un TLN PTC entre al menos un sistema terminal PTC y al menos una red usada actualmente por el mismo. A este respecto, un dato TLN o una información TLN es una información que el TLN puede captar/generar en destino/origen que a través de este sistema terminal le llega al TLN o lo envía el TLN (ya sea una persona o no) o que fue seleccionado. La diferencia entre un dato TLN y una información TLN consiste en que

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

o la información TLN se intercambia para cumplir con el objetivo de un PTC, o sea durante su funcionamiento, es decir no durante el establecimiento o la gestión técnica como en el caso anterior;

en ambos casos entre sus (eventualmente respectivos) TLN o los representantes/funcionalidades parciales etc. mencionados anteriormente..

• todas las nociones/términos/conceptos 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 model” abreviadamente modelo de referencia ISO/OSI u OSI-RM. Para el experto en la materia forma los fundamentos vinculantes intelectuales/conceptuales de esta solicitud de patente. Los términos del dispositivo/procedimiento 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 y limitaciones de la tecnología de las comunicaciones que eliminan muchas de las indeterminaciones de un significado “puramente del lenguaje natural”. La descripción del procedimiento/dispositivo de navegación por la red según la invención va aún más allá y usa conceptos/términos del modelo OSI-RM, como por ejemplo conexión OSI/PDU/SDU/Capas/conexiones Li etc., que pertenecen a la terminología o conceptos del modelo OSI “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 no ambigüedad de la capacidad de articulación del experto en la materia vía conceptos/términos artificiales del OSI-RM (de los cuales algunos, por ejemplo, ya 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/dispositivo de navegación por la red en sus respectivas reivindicaciones independientes.

Para el uso en lo que sigue de la terminología/conceptos de OSI y en especial para los términos/conceptos artificiales del modelo OSI se hace notar de antemano en el presente documento que las reivindicaciones respecto a la descripción

o por un lado no la pueden recapitular completamente, de modo que en su lugar se remite al estándar internacional antes mencionado y en caso de duda el presente documento es el de referencia, y

o por otro lado en algunos lugares en relación con las eventualidades en caso de un MHO se ha simplificado algo o se ha explicado más a grosso modo (véase más abajo y la sección D).

Y finalmente se recalca que acudir a la terminología/conceptos del modelo OSI en esta solicitud de patente es indispensable: la “jerga de Internet” que hoy domina en la práctica no dispone ni se aproxima a la precisión conceptual deseable de los documentos legales, para alcanzarla, y mejorar con respecto a la confusión conceptual o lingüística en la tecnología de comunicaciones que siempre ha estado presente habitualmente en última instancia se desarrolló el modelo OSI. Las precisiones conceptuales de esta solicitud de patente sirven no sólo para establecer el fondo de las reivindicaciones independientes sino también para la comprensión, para facilitar o precisar sus descripciones del procedimiento/dispositivo según la invención y ante todo 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 esta solicitud de patente no quedan expuestos como ilícitos justo a partir de esta descripción. Por lo demás no se debe confundirse lo que se remarca en el párrafo anterior

o lo indispensable de recurrir al modelo OSI

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

Más bien basándose tan sólo en estos fundamentos, o sea cuando se observa el requerimiento mencionado en último lugar, el modelo OSI podría y puede definir las nociones, conceptos y términos elementales que resultan muy útiles o 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 dos de sus sistemas terminales arbitrarios, 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 como se explica más abajo. Cada conexión OSI se subdivide fundamentalmente según el modelo OSI en siete “conexiones Li” abstractas (1<=i<=7) “una sobre otra” mediante las que se realiza este PTC entre estos dos sistemas terminales A0 y Z0 (“L” representa “capa”).

El modelo OSI define así, en base a sus “7 capas” siempre en principio una “semántica de abstracción” igual de sus conexiones Li en cada conexión OSI, la “arquitectura de comunicaciones OSI”, que por su parte se sustenta en esta “estructura de 7 capas” de la semántica de la abstracción fundamental de todas las conexiones OSI. Estas 7 capas de abstracción fundamentales de su arquitectura de comunicaciones las llama el modelo OSI de forma totalmente independiente de las conexiones OSI individuales, obviamente, respectivamente “Li” 1<=i<=7.

En una conexión OSI individual para cada “i” pueden existir varias conexiones Li. Cada una de estas conexiones Li tiene que usar siempre para su materialización al menos una conexión Lj de la misma conexión OSI, siendo j < i sin tener en cuenta que:

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

o una conexión L1 por lo general usa un “medio físico”,

pudiéndose usar la conexión Lk (1<=k<=7) 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 TC específico que es la base de 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, que eventualmente manipulan personas en el mismo), la estructuració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 la comunicación de la “aplicación de comunicaciones”.

Esta conexión OSI “existe” entre A0 y Z0 y el terminal en cuanto un TLN del PTC, en uno de sus dos sistemas terminales (PTC) A0 y Z0 haya empezado este PTC, o sea en cuanto que exista el PTC, es decir ambas (OCO y su PTC0) pueden ser en este instante “potenciales” (véase anteriormente). Desde ese momento existe, a saber, entre A0 y Z0 la conexión L7 de estos A0-OCO-Z0 para esta PTC0. Seguirá existiendo hasta que ambos TLN del PTC consideren este PTC terminado (lo que en el modelo OSI se habría de entender como finalización de esta conexión L7 y de la conexión OSI). El PTC sigue existiendo después como PTC “retrospectivo” (véase anteriormente) en relación con su modelado OSI por así decirlo original.

En otras palabras una conexión OSI (de un PTC) “existe”

o espacialmente 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 incluso entre los TLN del PTC en los dos sistemas terminales A0 y Z0, y

o temporalmente en cuanto que este PTC haya empezado en uno de sus TLN, en particular la conexión L7 de esta conexión OSI existe desde ese instante entre los TLN de este PTC, y sigue existiendo hasta que estos TLN consideren esta PTC terminada.

Según esto, esta conexión OSI existe a más tardar desde el momento en el que se produce cualquier acción para él/ella en un dispositivo terminal del sistema terminal del TLN (PTC) que lo/la crea en A0 o Z0. Según él estándar OSI y en el sentido de la presente solicitud de patente resulta existente sin duda ya desde el instante en el que se ha acometido en un TLN del PTC en el que se basa y aunque solo sea profilácticamente, por ejemplo para la comprobación propia explícita o implícita de la accesibilidad de un número de llamada de emergencia (por ejemplo 110 ó 112) o de su accesibilidad para los que le llamen.

Cualquiera de las conexiones Li (1<=i<=7) de esta conexión OSI no necesita en este instante, sin embargo, que se haya realizado o pueda realizarse (abstractamente). La existencia de una conexión Li implica entonces no su realización o su posibilidad de realización (abstracta). 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 estar realizada abstractamente (implementaciones/realizaciones materiales no las contempla el modelo OSI de todos modos). Una realización (abstracta) de una conexión Li sólo necesita existir mientras se le da un uso actual (abstracto).

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 de los participantes entre A0 y Z0 de esta conexión OSI (abstractamente y/o materialmente) no está realizada, como sucede a menudo en los HO. Que la conexión L7 de una conexión OSI en el caso de un HO siga existiendo (al menos su realización abstracta o eventualmente también su realización material) se puede garantizar por medio del “procedimiento HOCIS” mencionado anteriormente (véase la sección A y más abajo la “correlación CI”).

•

Los “sistemas terminales” abstractos contienen además de sus usuarios humanos abstractos, y/o sus usuarios no humanos abstractos (usuario-autómata) y/o sus representantes/funcionalidades parciales, todos se deben entender como TLN PTC, “dispositivos terminales” abstractos cuyo conjunto en un sistema terminal a continuación y ocasionalmente también se designa como “dispositivo terminal”, es decir grupos de funciones no humanas como por ejemplo, la de LAN, WLAN, supercomputadoras, bases de datos, PBX, RAS, cortafuegos, switches de todo tipo aunque también la de los accesos a la red, IAD, dispositivos entrada-salida. Los grupos de funciones no humanas (implementaciones abstractas o materiales) en los sistemas terminales se designan en lo sucesivo a menudo por módulos.

•

los “dispositivos terminales” individuales abstractos de un sistema terminal pueden considerarse por separado, en particular

o un “dispositivo terminal terminal de participante” con su superficie de usuario electrónica/física/acústica/óptica/”lógica” (en el presente documento a menudo móvil, por ejemplo en un teléfono móvil),

o un “dispositivo terminal no terminal” con un “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,

o cooperando los dispositivos terminales no terminales y terminales de participante de un sistema terminal a través de interfaces físicos/de tecnología de comunicaciones y/u otros dispositivos terminales de los cuales por lo general sólo algunos están estandarizados y

o un dispositivo terminal no terminal (e incluso su TA y su NT) en particular un dispositivo terminal móvil terminal (por ejemplo, un teléfono móvil) puede estar integrado de modo que el primero resulta también móvil.

Se observa de este tipo de subdivisión de los sistemas terminales conformes al modelo OSI en personas abstractas y dispositivos abstractos que el modelo OSI a primera vista evita la subdivisión de sistemas terminales pero en último término sí resulta implícito aunque del todo claro que lo efectúa. La causa de esto es la necesidad conceptual de la subdivisión de las aplicaciones de comunicaciones que por lo general se sitúan en la L7 de los sistemas terminales para entenderlas en su esencia. Esta necesidad en las convenciones para la L7 (en el estándar internacional relevante ISO/IEC 7498 de 1994 y en la idéntica recomendación ITU-T X200, entre otras, las páginas 32/33 y su estándar internacional correspondiente como el ISO/IEC 9545 de 1994 y su idéntica recomendación ITU-T X.207) llevó a la definición de la estructura funcional de las aplicaciones de comunicaciones abstractas conformes al modelo OSI que lógicamente implica obligatoriamente 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 y que se ha introducido anteriormente o lo hará posteriormente para esta subdivisión) de sistemas terminales OSI en personas y dispositivos terminales de distintos tipos.

• Los “servidores” abstractos o “sistemas terminales servidores” o “sistemas terminales sin participante humano en el PTC” son grupos de funciones de una red o en una red, bajo la gestión de su operador de red o no, que en el presente documento se consideran igualmente como sistemas terminales

o dispositivos terminales, los segundos sin embargo no se subdividen 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 con ello é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 abajo, 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) se aclararán sus sentidos en primer lugar (por lo menos con el detalle que sea suficiente para esta solicitud de patente):

esta definición de “acceso” del experto en la materia (llanamente) reza: un sistema terminal o un dispositivo terminal tiene en un instante de tiempo un “acceso funcional a su red” cuando en ese instante de tiempo en las capas OSI 1 a 3 de su conexión se puede comunicar con el punto de acceso funcional de esta red, en el sentido de que puede gestionar 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 acceso funcional a la misma. De ello se desprende que el sistema terminal/dispositivo terminal de una red no tiene necesariamente que tener acceso permanente a ésta, como se conoce que sucede 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 del traspaso de la responsabilidad legal económica o 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 estos sistemas terminales/dispositivos terminales y su DÜA. El dispositivo de finalización abstracto del lado de la red de esta DÜA en el punto de acceso se llama de “terminador de red” (“network terminator” NT), el dispositivo de finalización abstracto del lado del usuario de esta DÜA en el punto de acceso se llama “adaptador de terminal” (“terminal adapter” TA). En una implementación material de un punto de acceso de red ambas unidades de funciones conceptuales, NT y TA, pueden estar integradas de la manera más amplia como ocurre en el caso de un teléfono móvil por lo general. (Especialmente para teléfonos móviles se ha de observar que: cuando esta capacidad de un teléfono de red móvil para el 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 se llama hoy a menudo teléfono FMC (FMC= fixed mobile conversion): soporta entonces concretamente en una llamada telefónica el uso tanto de la tecnología actualmente llamada de manera coloquial de redes fijas, WLAN VoIP, como la tecnología que se llama de red móvil, GSM/CDMA/satélite). Después de esta aclaración de los conceptos de “acceso” de red y de “punto de acceso” de red referido a cómo habitualmente se entienden legalmente para el experto en la materia (éste también conoce que estos términos se pueden ilustrar con otros conceptos que entonces si necesitan la denominación explícita de cada modelo de referencia respectivo (véase J. Schiller, sección A)) está claro que un sistema terminal/dispositivo terminal móvil que pueda estar implicado en un HO directo, en particular un teléfono móvil, comprende por lo general un dispositivo terminal terminal y al menos tres no terminales:

o su dispositivo terminal terminal sirve según la definición primordialmente para la realización de la capa funcional de usuario mecánica/óptica/acústica de un proceso de comunicaciones

o sus tres dispositivos terminales no terminales son necesarios por lo general para que pueda cooperar con las dos redes/puntos de acceso/características de servicio distintas durante un HO: están presentes en un “conmutador” funcional para proporcionar funcionalmente datos entre su dispositivo terminal terminal por un lado y por otro lado cada TA/NT funcional para o de la/s red/es móvil/es respectiva/s.

Esta aclaración del concepto de punto de acceso debería finalmente eliminar una confusión de concepto en esta solicitud de patente, que se ha producido por el concepto punto de acceso sin hilos (“Wireless access point”, WAP) de las nuevas publicaciones técnicas de la tecnología de Internet en movilidad en relación con dos aspectos:

o por un lado, este concepto de “punto de acceso sin hilos” (WAP) erróneamente se usa como sinónimo de “dispositivo de acceso integrado” (IAD) es decir 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 años de todos modos algo totalmente diferente en el campo de la tecnología sin hilos, concretamente “Protocolo de aplicación sin hilos” (“Wireless Application Protocol”) que no tiene nada que ver con el concepto de “punto de acceso” porque las aplicaciones quedan situadas en la L7 mientras que los puntos de acceso de la red

de los diferentes sentidos posibles por lo general están situados en las capas L1-L3 (y en el medio físico que están por debajo de las mismas).

•

Se llama un “HO” o“proceso HO” de un sistema terminal y su PTC (y sus dos OC), en analogía con el sentido de la PTC anterior (véanse los detalles ahí),

o “potencial” cuando no se han realizado para el mismo todavía sus acciones de conmutación en un dispositivo terminal pero al menos otra acción para ello en el mismo (por motivos en este caso irrelevantes y de forma aquí irrelevante) y/o se ha dirigido ya a un sistema terminal, y

o “actual” cuando para ello ya ha tenido lugar una acción de conmutación en el dispositivo terminal llamándose este sistema terminal/PTC “afectado” por este HO mientras tanto y “conmutación” designa un cambio en una red usada por este sistema terminal (y su PTC y sus dos OC) y/o del punto de acceso de red y/o de la característica de servicio de red durante el HO. A este respecto, un HO potencial se vuelve actual en cuanto para él en al menos uno de sus dispositivos terminales “de comienzo” o “empiece” al menos una acción de cambio de este tipo y un HO actual está “en marcha” tras esto hasta que la realización de todas las acciones de conmutación similares (con éxito o sin éxito), concluya.

•

Ambos sistemas terminales de una conexión OSI de un PTC pueden pertenecer a dos redes diferentes (como muestra la figura 1) de modo que un “sistema de tránsito OSI” abstracto “releve” (“redirija”, “conmute”) 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 “sistema de tránsito” de las conexiones OSI relevadas a través de él. 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 se produzcan más conexiones Li relevadas de la conexión OSI cuyo relevo sea individual y/o común. Hay que considerar en este caso que la 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 VoIP conocida comúnmente entre Internet y la red pública telefónica conmutada (PSTN)/ISDN/UMTS a través de la que se releva una llamada o conversación telefónica entre A0 y Z0 (al menos en parte) cuando el sistema terminal A0 está en Internet y el sistema terminal Z0 está en PSTN/ISDN/UMTS. El experto en la materia conoce también que las conexiones Li de una conexión OSI entre A0 y Z0 (temporal o permanentemente) pueden transcurrir a través de varios sistemas de relevo: en este ejemplo adicionalmente a la pasarela VoIP por ejemplo a través de un servidor SIP. Otro ejemplo de un sistema de relevo de este tipo es el IAD WLAN 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 usa para la comunicación con los sistemas terminales de Internet los protocolos de Internet correspondientes de las L1-L3, 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 también los protocolos y datos al hacer el relevo o tampoco.

El experto en la materia conoce todo esto y sabe además en particular que las conexiones Li pueden tener un “túnel” para producir “direcciones IP con significado extremo a extremo” (a pesar de la movilidad al menos de uno de los sistemas terminales de su conexión OSI, véase la sección A). En caso de prescindir del significado de estas direcciones IP extremo a extremo abre la posibilidad de poder situar funcionalidades de los tipos más diferentes en un relevo, como por ejemplo entremezclar varios PTC con distintos TLN en el relevo, por ejemplo, la importante y adecuada superposición para la presente invención de los canales de voz de este PTC (más información más adelante) para el usuario de un sistema terminal, es decir el TLN de este PTC, es decir en caso de prescindir de una capacidad de mezcla de este tipo en este sistema terminal (entre otras razones porque hoy los teléfonos FMC o los PDA o similares no disponen de una funcionalidad de este tipo). Por eso hay que distinguir si el relevo (eventual) 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 de tunelado” con su funcionalidad limitada y un “relevo sin túneles”. Un sistema puede usar o contener para una o varias conexiones OSI varios relevos de distinto tipo y entonces, eventualmente, poner en práctica paralelamente estas dos técnicas de relevo. Correspondientemente se diferencia entre dos tipos de MHO, “MHO sin túneles” y“MHO con tunelación” en función de si un MHO necesita para ello un relevo sin túneles o ningún relevo o relevo con tunelación.

Implícitamente ha quedado dicho con ello que la presente invención fundamentalmente (justo como se describe en el procedimiento HOCIS) “entremezcla” en un “PTC primario” de un sistema terminal A con un sistema terminal Z al menos un “PTC secundario” para el sistema A con por lo general al menos otro sistema Y. Los ejemplos más sencillos serían los del PTC de la TV IP de A con el servidor de TV Z, como PTC primario y entretanto una llamada VoIP entrante para A desde Y como PTC secundario. 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, esta mezcla tiene que quedar desplegada en el relevo en este sentido “sin túneles” mencionado anteriormente para el PTC primario, lo que no excluye el uso en el procedimiento de navegación por la red de la tecnología de tunelación que ofrece sobremanera simplificaciones mediante sistemas capaces de ello. Más acerca de la mezcla de al menos un PTC primario con al menos un PTC secundario sigue después de la introducción subsiguiente de las “acciones MHO”. Téngase en cuenta finalmente que 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 otra red WLAN a través de uno de sus IAD. La técnica de tunelación en teoría se puede emplear siempre que las informaciones que se intercambian a través de la red vayan en paquetes, independientemente, en particular, de la tecnología de transmisión de esta red.

• una “especificación de HO gestionado, MHOS” siempre

o está justo asociada a un IAD local real o virtual (véase más abajo) o servidor local o sistema local que se designa con el acrónimo único “homeMIAD”, o sea, no necesita estar contenido en el mismo (perteneciendo a un MIAD local (“homeMIAD”) un conjunto de sistemas terminales locales que pueden ser definidos como tales sólo por el gestor del MIAD local, de modo que este acrónimo nos recuerda el aspecto de seguridad/privacidad del MHOS),

o solo su gestor puede asignar el MHOS al MIAD local y definir el MHOS,

o al menos conoce dos clases de “acciones gestionadas por HO, MHOMa”, que por medio de un sistema terminal local controlado por ella se ejecutan en su MHO y más concretamente por un MIAD local que contiene el MHOS por sí mismo o bajo su control por otro sistema de los que al menos un tipo ocasiona una comunicación de usuario y

o especifica la cooperación de sus acciones, MHOMa, en una realización de un MHO,

diciéndose a partir de ahora en aras de la simplicidad ocasionalmente IAD local, en lugar de MIAD local. En el sentido de la terminología y los conceptos PTC primario y secundario anteriores del procedimiento HOCIS cada realización de MHOMa que al menos produzca una comunicación de usuario es un PTC secundario.

En una aplicación del procedimiento de navegación por la red no todos los HO de un PTC en el que aquella 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 implicados varias MHOS quizá definidos de forma distinta. De manera contraria, un MIAD local puede contener varios MHOS.

Es un asunto de un MHOS de un MIAD local fijar cuál de estos sistemas terminales locales controla en qué MHO en relación con qué acciones de estas, es decir cuáles de estas acciones para este sistema terminal en este MHO como en cooperación con otras acciones para ello se producen. En las figuras 6 a 8 de la sección D se discuten las implementaciones distribuidas de un MHOS (y del MHOM momentáneo) y sus aspectos de posibilidades de realización.

A las clases de MHO-Ma de un MHOS pertenece en esta solicitud de patente:

o un tipo opcional de MHO-Ma, las “acciones de control MHO, KoMa”, efectúa y controla la concesión de permisos y vigilancia del uso de una red x (Netx) de un sistema terminal local en un MHO y eventualmente la creación o la gestión adecuada de una conexión o un relevo de navegación por la red sin túneles (véase más abajo y anteriormente) para A0 y esta Netx, es decir para un MHO sin túneles.

o Con otro tipo opcional de MHO-Ma, con las “acciones HOCIS MHO, HOCISMa” (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 los llamados “GeMa-MHO”, que eventualmente pueden producirse sin túneles es indispensable al menos un tipo de “acción comercial MHO, GeMa” de MHO-Ma, mientras que para MHO es opcional. En ambos casos un MIAD local puede materializar con el control de la realización de una GeMa para su operador (y eventualmente para los operadores que cooperan comercialmente de los sharedIAD) las acciones comerciales del tipo más variado, por ejemplo, de tipo publicitario, durante un MHO o un GeMa-MHO. En este caso la realización de un acción comercial materializa siempre una comunicación del PTC-TLN, cuyo sistema terminal local justo haya quedado afectado por un HO, teniendo éste que enterarse o no de esta comunicación (es decir, de algún modo confirmar). o Otros tipos de acciones MHO-Ma opcionales para un MHOS o en un MHOS son definibles o especificables arbitrariamente, por ejemplo, para posibilitar una mezcla del tipo más distinto del PTC IP TV en un PTC VoIP (o al revés) y para dejar el control a quienquiera que sea.

o Por motivos de simplificación se contemplará también el HO en sí, es decir el proceso básico para un MHO, como acciones “MHO-HO, HOMa”, opcionales.

Una acción MHO individual y específica de este tipo, en lo que sigue se marcará por lo general mediante una terminación “0” (por ejemplo, como en “GeMa0” o “HOMa0”) y para confirmar con el prefijo MHO. Cada GeMa-MHO está “correlacionada CI” (CI= “información de conveniencia”) en el siguiente sentido: está característica GeMa-MHO caracteriza las circunstancias que durante la realización de una acción GeMa-MHO, la realización de su al menos una acción MHO-GeMa asociada se produce, implícitamente o explícitamente, en el contexto de la realización de una acción opcional MHO-Ma. Una GeMa en un MHO sin túneles no necesita estar CI-correlacionada pero puede estarlo.

Esta característica de correlación que intuitivamente quizá parezca de inmediata comprensión, de una realización MHO-GeMa con al menos una realización de una acción opcional MHO-Ma en una GeMa-MHO, es decir, por ejemplo, “la de un GeMa con la de un HOMa y/o KoMa y/o HOCISMa...” se describirá en más detalle a continuación para no dejar dudas.

Hay que diferenciar ante todo entre tal correlación CI implícita y una explícita siendo ambos tipos de correlaciones CI completamente independientes el una del otro. Una MHO-GeMa0 específica (y con ello el procedimiento de navegación por la red que usan) como al menos una de estas MHO-Ma0 opcionales, (ambas en el mismo procedimiento de navegación por la red):

o se denominará “correlacionada explícitamente” (independiente de la secuencia de realización GeMa0 especificada más abajo en relación con al menos una secuencia de realización Ma0 opcional específica) cuando el al menos un aviso de GeMa0 o de esta Ma0 (durante sus realizaciones) comunicado a al menos un TLN describe un contexto así de cualquier tipo o se refiere a él y

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

hay al menos una realización tanto de este Ma0 como de este GeMa0 y

el instante de comienzo de esta realización GeMa0 y/o de su anuncio al TLN queda como sigue:

•

después de 30 segundos antes del punto de comienzo de la realización de la Ma0 y

•

no después de 30 segundos del punto de finalización de este último

siendo irrelevante si/cuándo/cómo el TLN percibe esta realización Ma0.

Por medio de correlaciones similares de un GeMa, que el operador local efectúa, más concretamente su MHOS, para al menos un sistema gestionado por él/ella (y su usuario), la comunicación GeMa asociada se aloja en el PTC (el que es la base de la aplicación del procedimiento de navegación por la red eventualmente en una llamada VoIP), “en la medida de lo posible”. Y éste en la medida de lo posible ventajoso alojamiento de tal comunicación comercial (que desde el TLN originalmente ni se solicitó y por ello interpretada por él posiblemente como una molestia) se produce en el marco de los procesos HO. En éste caso más concretamente se puede concebir de tal manera que no solo moleste al TLN/PTC, “tan poco como sea posible” por la comunicación comercial, sino que estos lo consideren en este momento incluso de ayuda, lo que mejora determinantemente la aceptación o eficacia del o con el cliente de estas comunicaciones comerciales. Y causar estos “momentos favorables” en la medida de lo posible para todos los HO es la tarea de las actividades HOCIS concebidas adecuadamente para ello. A causa de su característica de correlación CI, que por su parte acepta todas las acciones MHO-Ma opcionales como base de correlación, el procedimiento de navegación por la red posibilita por tanto de una forma fácil, transformar el supuesto potencial de molestia de un HO en una llamada VoIP en el potencial de negocio y de comodidad que se acaba de exponer de este HO. O sea, esta correlación CI de GeMa-MHO podría considerarse como creadora de conveniencia (de ahí su nombre) incluso aunque sea para su “despliegue óptimo de productividad” en un procedimiento de navegación por la red por lo general una correlación HOCISMa. Para terminar con esta discusión de GeMa-MHO se ha de mencionar, que de los autores de esta solicitud de patente se espera que en el futuro la mayor parte de los MHO de la navegación por la red (o sea también en los casos en los que se pueda renunciar a un GeMa o a su correlación CI (ver reivindicación 2)) deberían poner en práctica el uso comercial que se acaba de discutir de los HO para GeMa ya que sus costes, usos, saldos para todos los participantes hablan a su favor. Lo último algo más concreto: esta técnica MHOS/GeMa-MHO realiza los dos fundamentos del procedimiento Wsurfing según la invención:

o por un lado el fundamento más bien comercial de hacer de los IAD locales internos a la empresa muelle de impulso de una actividad económica, con sentido y novedosa en el marco ante todo de las llamadas VoIP, en la medida de lo posible con la participación de sharedIAD públicos y

o por otro lado el fundamento más bien social, poner a disposición de cualquiera la tecnología de comunicaciones más cómoda y de mejores prestaciones en todas las zonas de aglomeración urbana a corto plazo y más económicamente para sus sistemas terminales multimedias futuros (en particular para

el uso de sus IP-TV) como tan sólo es posible hoy mediante la tecnología de red móvil (basadas en GSM, CDMA, UMTS, Wimax... y sus derivadas), manteniendo estas “tecnologías de reserva” una disponibilidad importante en todas las partes en las que la tecnología sharedWLAN no esté disponible o no resulte económica.

Varios ejemplos sencillos y comentarios acerca de la tecnología MHOS/GeMa-MHO que está correlacionada CI pueden ilustrar esto. Por medio de una:

o MHOS0/función1 opcional, asociada a un MIAD0 local, éste decide antes de empezar o al comienzo de un HO de un teléfono WiFi A0 (que es un sistema terminal local del MIAD0 local) si a este con su PTC/OC0 actual a otro teléfono Z0 (que esta relevado a través de un MHOM0) se le permite ejecutar un MHO a un IAD1 (MHO-KoMa),

o MHOS0/función2 opcional, igualmente asociado al MIAD0 local, éste informa antes del comienzo o al comienzo del HO anterior a los dos TLN de este PTC sobre la ejecución del HO potencial o actual (MHO-HOCISMa),

o para un GeMa-MHO, MHOS/función 3 obligatoria también asociada al MIAD0 local, éste último pone en práctica (o su MHOS) una acción comercial, por ejemplo la comunicación de una nota publicitaria al usuario del sistema terminal local-MIAD0 local implicado en este HO o a ambos TLN de su PTC, produciéndose esta comunicación técnica adicional antes o durante o después de la decisión previa (lo que aquí es irrelevante) una o varias veces y en cualquier momento (lo que aquí también es irrelevante) (MHO-GeMa).

Este pequeño ejemplo deja claro que la realización de esta MHO-GeMa se produce con la correlación CI más favorable junto con la realización de la MHO-KoMa anterior (no exigiendo esta correlación CI, que la realización de esta MHO-KoMa le fuera comunicada a uno de los TLN del PTC), aunque ante todo con la realización del MHO-HOCISMa anterior, haciendo uso la correlación CI por lo general ahora, ante todo en las llamadas VoIP de que la realización de esta MHO-HOCISMa por lo general de todos modos siempre se comunica con ambos TLN-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 fuera posible el procedimiento HOCIS: el primero visto tecnológicamente resulta absolutamente independiente del segundo y también son imaginables en cuanto al contenido los MHO del procedimiento de navegación por la red en los que una correlación CI de una MHO-GeMa con una MHO-HOCISMa tenga poco sentido.

A este respecto:

o se pueden concebir interactivamente tanto tales averiguaciones para la decisión (en base a tales MHO-KoMa) del MIAD0 local así como sus acciones HOCIS y comerciales definitivamente comunicativas en el sentido, por ejemplo de lo que se conoce comúnmente como un sistema IVR, por ejemplo interactivo tanto con usuarios de los sistemas terminales en los shareIAD soportados por los MIAD0 locales como con sus otros socios de negocio.

o el MHOS puede al menos prever un estado de comunicaciones y éste lo puede evaluar/modificar/registrar un MIAD0 local (por ejemplo por medio de su MHO-Ma) y quizá tenerse en consideración en la decisión mencionada anteriormente y este KS puede tener el efecto descrito en tal decisión.

o estos MHO-Ma controlados por MHOS del MIAD0 local pueden estar diseñados para ser sensibles al contexto (o sea quizá durante un PTC/OC potencial estar concebido de otra manera distinta que durante un PTC/OC en marcha) y/o de tipo multimedia (o sea copiar quizá después o al mismo tiempo que una señal de sonido a una TLN, una información gráfica o textual en su sistema terminal en paralelo y eventualmente sin afectar a la información de audio VoIP).

o en cada implementación abstracta y/o material de cada MHO-Ma, todos los tipos de MHO-Ma pueden estar entrelazados lo más estrechamente de tal forma que a un usuario de un sistema terminal afectado por ellas no le resulten identificables como tales tipos individuales y

o el operador del IAD local puede, al menos para una y/o todas las entidades de su sistema terminal local (por ejemplo las de sus OC y las de este mismo), establecer MHOS respectivamente iguales o diferentes en cuanto a contenido y diferenciarlas correspondientemente o concebirlas de forma muy sencilla. Lo último quiere decir: en un MHO-KoMa siempre especifican sólo limitaciones triviales (como por ejemplo: “nuevo sistema anfitrión MHOM= IAD local” y “nuevo sistema terminal= sistema terminal local”) y en una MHO-GeMa siempre prescriben sólo comunicaciones de usuarios triviales (como por ejemplo

•

“en caso de riesgo de HO para el sistema Ax> una señal de sonido corta” y un “parpadeo Id de operador del sharedIAD 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 de operador del sharedIAD 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 de operador del nuevo shared IAD” 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”).

Mientras la comunicación de las señales largas y cortas de sonido se pueda valorar como HOCISMa, los avisos sonoros de Id de operador del sharedIAD son definitivamente comunicaciones de información publicitaria (rudimentaria). Estos MHO-Ma pueden estar especificados globalmente para todos los sistemas terminales locales o selectivamente para sistemas terminales locales particulares y lo segundo puede estar ya configurado de antemano sin posibilidad de cambio (lo que aquí es del todo irrelevante, ya que estas cuestiones son de la configuración y la implementación material de la invención).

El experto en la materia sabe que el MHOS de un operador de un MIAD local virtual o real en una implementación material (forma de realización) del procedimiento Wsurfing es una especificación de este MIAD local, que el operador en parte o totalmente introduce en éste de alguna forma o/y ya está contenida en el mismo y el operador sólo la configura y/o está prefijada en el mismo sin posibilidad de cambio y la MHO-Ma de este MIAD local (que pertenece a este MHOS) se realiza a través de la interpretación de este MHOS por parte de este MIAD local. Conoce también que cualesquiera MHO-GeMa especiales y sus especiales correlaciones CI 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 GeMa-MHO está caracterizado por la característica técnica muy especial de una comunicación “limitada por la correlación CI” entre el usuario del sistema terminal “MHO” y su MIAD local para la realización de un MHO-GeMa de este tipo, aunque también otros MHO pueden presentar esta característica.

•

el atributo “homeMIAd privado” del MHOS sirve sólo para remarcar la “privacidad” de estas acciones de gestión MHO caracterizadas anteriormente para y sólo para el operador de este y sólo este MIAD local. Se ha de comentar a este respecto: el operador del MIAD local abstracto puede realizarse por medio de dos personas materiales diferentes, un “operador” abstracto puede representar un “operador humano material y/o un gestor humano material”.

Esta privacidad excluye, por tanto, que un segundo operador además de este operador MIAD local como primero, perciba el MHOS privado del MIAD local o lo fije o lo modifique sin que el primero lo conozca y lo consienta. Si este segundo es en particular un operador y/o gestor de una red de algún tipo (que no es la red de este MIAD local) o de un servicio (que no es el servicio de este MIAD local) entonces le resultan estos MHOS inaccesibles e incomprensibles. Esta privacidad no significa sin embargo que un segundo no supiera o pudiera saber qué MHOS puede asociarle un operador MIAD local fundamentalmente de alguna manera. No se entrará en la encriptación adicional de los datos TLN que en último término resulta necesaria y conocida.

•

hay dos tipos de MIAD locales: un tipo “real y uno virtual de MIAD local”, ambos tipos eventualmente tanto en la implementación material como en la abstracta. Para cada MIAD local (para un MIAD real o virtual) existe conceptualmente justo un gestor “lógico” y un operador “físico”. En el caso de un MIAD local real su gestor y el operador son idénticos, lo que en ambas interpretaciones no tiene que ser igual.

•

resulta obvio ya del uso lingüístico anterior que en el presente documento tanto los conceptos/términos “MHO”, “procedimiento MHO” y “proceso MHO” como “MHO-PDU” y “PDU” (PDU unidad de datos de protocolo) se usan respectivamente de forma ocasional como sinónimos, la terminología entonces de manera algo simplificada en el sentido de su escasa pérdida de precisión, (aunque esto en el primer caso resulte en sí no permitido ya que un “proceso” abstracto siempre es una aplicación abstracta de un “procedimiento” abstracto, es decir su “instanciamiento de la aplicación” abstracta).

•

ahora se realiza finalmente aún la aclaración de algunos conceptos/términos más adaptados a las eventualidades de esta solicitud de patente.

o “homeWLAN” o “homeNet”: en el presente documento un sistema terminal A0 está asociado administrativamente a una WLAN local o homeNet y a su al menos un MIAD local real o virtual según la invención. A0 es para esta WLAN local/homeNet/MIAD local un “sistema terminal local”. El ejemplo más sencillo de un MIAD local/WLAN local/homeNet según la invención se puede realizar por medio de una WiFi-IAD/WLAN y su sistema terminal local A0 (un particular con teléfono WiFi). Este teléfono WiFi A0 puede entonces por medio de una sharedWiFi-WLAN arbitraria Wx o Netx navegar por la red/Wsurfing según la invención con tal de que A0 se pueda “registrar” (véase más abajo) en Wx/Netx y el MIAD local de A0 contenga un MHOS/MHOM (y éste esté preparado ya para manejar una conexión Wsurfing con el IAD de Wx/Netx). Este concepto generalmente conocido de

WLAN local/homeNet se extiende en esta solicitud de patente en primer lugar al concepto aquí usado WLAN/Net (véase la sección B). En segundo lugar se extiende también a los posibles sistemas terminales locales “no de verdad” asociados, por ejemplo los teléfonos como el mencionado antes A0, pudiendo estar inducida esta característica “no de verdad” local de un sistema terminal a cualquier servidor/IAD mediante un KS (véase más abajo), por ejemplo su propio sistema, como el de su OC o el de su PTC o el de su otro sistema terminal o de toda la red WLAN local o este IAD/Servidor etc. O sea un KS puede también ocasionar que se releve o incluso que se tenga que relevar por parte de un IAD/servidor, un OC de un sistema terminal o PTC, por ejemplo con el MHOM “de verdad asociado” o aunque este sistema no sea un sistema terminal local “de verdad” de este MHOM/IAD/servidor (en el sentido antes mencionado). En esta solicitud de patente pertenece al WLAN local/homeNet/MIAD local tanto su sistema terminal local “de verdad” como “no de verdad”.

o “Registro”: un sistema terminal A0 que recibe una señal electrónica por ejemplo de una red WiFi WLAN o de otra red, puede usar ésta para la comunicación, en particular a través de Internet, por lo general sólo después de que haya solicitado a al menos uno (posiblemente varios) de sus IAD o estaciones base, etc., el permiso de uso de esta red. Si se le concede, entonces el terminal A0 queda registrado en esta red. Los procedimientos o protocolos entre A0 y este IAD/estación base según los cuales se produce esta solicitud y concesión o también oferta/aceptación de permisos de usos de una red, para esta solicitud de patente son irrelevantes. Sin embargo se define aún: A0 resulta “accesible” en una Netx cuando A0 está registrado o puede ser registrado. Eventualmente resulta suficiente que A0, esté registrado o pueda registrarse para Wsurfing, como se explica en la sección D, siendo modalidades e implementaciones posibles de una limitación del registro o una posibilidad limitada de registro irrelevantes en esta solicitud de patente.

o “Conexión netsurfing” (NSC): ésta es al menos una conexión L3 de un segmento OCO del OC0 entre A0 y Z0, concretamente entre A0 y un sistema S0 de/en una WLANx/Netx que sea diferente de WLAN0 local/homeNet0 de A0.

o “Estado de comunicación KS”: antes se ha explicado ya que un OC/PTC de una aplicación de comunicaciones específica sobre la base del procedimiento Wsurfing (por ejemplo en el caso del PTC con características específicas como la llamada de emergencia o llamadas de coste reducido de todo tipo o llamadas al centro de atención al cliente o las llamadas a vigilar, o llamadas de menores o llamadas desde redes Fem remotas o WLAN o lugares o acontecimientos de/en instantes concretos) se puede caracterizar mediante las características que en Wsurfing de un sistema terminal A0 conducen a que se trate preferentemente, por ejemplo, al poderse relevar su 0C o incluso tenerse que relevar, por quien sea, con tal de que sea técnicamente adecuado (no considerándose el fundamento comercial o legal o de otro tipo, de la necesidad o el sentido de esta preferencia en está solicitud de patente, sino sólo el hecho de que puede estar presente o no). Este KS también puede mantener sin embargo un tratamiento de relevo de otro tipo o que perjudique de un OC, mediante el que su IAD/servidor, y como siempre, hasta la negación de relevo, es decir el rechazo de una característica “home” para la entidad.

El sistema del procedimiento/dispositivo según la invención o de las entidades de un OCO (véase más abajo) perjudican entonces los conjuntos de características de relevo de los OC.

o “Entidades de un OCO”: se entenderá por ellas tanto las entidades Li de sus conexiones como las conexiones Li en sí, la al menos una red necesaria para su realización y eventualmente otro elemento necesario para ello.

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

De manera correspondiente, el presente documento considera en particular que su dispositivo abstracto para navegar por la red consta de componentes HW/SW de función abstractos, siendo esta asociación de un componente del dispositivo de navegación por la red funcional al HW o al SW totalmente irrelevante. Lo importante es únicamente que la realización abstracta de los componentes funcionales de un dispositivo de navegación por la red abstracto pueda producirse por medio de

•

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

•

componentes HW/SW de IAD/sistema terminal de la misma función y/o adecuados funcionalmente o

•

componentes HW/SW de la misma función y/o adecuados funcionalmente de otros sistemas (por ejemplo de un sistema operativo y componentes HW funcionales gestionados por éste).

Aparte del primer caso, se produce entonces un “reparto de recursos HW/SW abstracto” entre los componentes del dispositivo Wsurfing y los componentes funcionales de los otros sistemas mencionados. Este reparto de recursos HW/SW abstracto se puede encontrar nuevamente o no en una implementación material o forma de realización de este dispositivo de Wsurfing y se llama en el primer caso “reparto de recursos de HW/SW material”. Es decir: una realización abstracta de un dispositivo de navegación por la red en un IAD/sistema terminal abstracto del dispositivo de navegación por la red puede en ese caso respectivamente compartir por reparto de recursos abstracto componentes HW/SW abstractos de la misma función o adecuados para una función, por ejemplo, un sistema operativo (y los componentes HW abstractos gestionados por éste).

Concluyendo a la inversa: una implementación abstracta de un dispositivo de navegación por la red que deba completar un sistema terminal/IAD abstracto al que un procedimiento de navegación por la red le debe dar soporte no necesita para ello eventualmente ninguna extensión HW de este IAD/sistema terminal en absoluto, ya que sus componentes HW abstractos son suficientes para esta implementación, es decir, se puede conseguir mediante el reparto de recursos de HW abstracto, con el IAD/sistema terminal abstracto al que dar soporte. Esto se puede aplicar entonces también a una implementación material de este IAD/sistema terminal del dispositivo de navegación por la red por medio de un IAD/sistema terminal material y sus componentes HW materiales.

La discusión anterior del modelado de los componentes HW/SW abstractos del medio de un dispositivo de navegación por la red sirve para la aclaración del tipo puramente funcional del elemento según los términos/sentido de la reivindicación, en virtud de cuya materialización por medio de formas de realización concretas “sospechosas de navegación por la red” se ha de decidir si el segundo invade el ámbito de protección del presente documento o no.

Esta solicitud de patente se refiere primordialmente en primer lugar a formas de realización del procedimiento/dispositivo de navegación por la red que en relación con sus componentes HW materiales están implementadas totalmente por medio de componentes HW materiales de los IAD/sistemas terminales materiales a los que se da (debe dar) soporte por estas formas de realización, es decir, en conjunto sólo comprenden componentes SW materiales adicionales (dependientes del procedimiento/dispositivo de navegación por la red). La implementación material de un dispositivo de navegación por la red de este tipo se basa, consecuentemente, en su reparto de recursos material de sus componentes HW materiales con los de los IAD/ sistemas terminales materiales soportados.

Que la implementación material del procedimiento de navegación por la red sea posible completamente mediante componentes SW materiales resulta elemental para el experto en la materia. Y éste percibe al instante también que todos los medios de una reivindicación de dispositivo de navegación por la red son implementables mediante componentes SW materiales, en cuanto que no se basen en los componentes HW abstractos de la figura 5, que por su parte resultan implementables a través del reparto de recursos material (véase anteriormente). El ámbito de protección de esta solicitud de patente no está limitado sin embargo a tales formas de realización especiales sino que éstas deberían eventualmente contener componentes HW adicionales específicos para la navegación por la red.

D. Descripción detallada 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 formas de realización de ejemplo muy limitadas y se limite a las mismas, lo que si bien se desmarca de la “lógica de patentes” y que ante todo el derecho de patentes estrictamente no permite, no obstante le ha acontecido a los autores del presente documento en otras de sus patentes en pleitos legales y por eso se marca mucho la redacción de esta solicitud de patente, y no en base a sus términos de las reivindicaciones puestos intencionadamente de manera muy abstracta y por ello de mayor alcance. La forma de interpretación que debe primar, es decir, del procedimiento de determinación del sentido de una patente a partir de sus expresiones (con respecto a todas las demás posibilidades de interpretación de un procedimiento, de determinación del sentido o forma de interpretación 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 aclaración algo extensa de las reivindicaciones del procedimiento. Un comentario reiterativo y de extensión comparable de las reivindicaciones del dispositivo no resulta entonces necesario. La sección D es por tanto una parte de la descripción del procedimiento/dispositivo según la invención.

Para empezar recuérdense tres aspectos ya tratados parcialmente en el presente documento:

•

las características individuales del procedimiento o dispositivo según la invención no están sujetas a ninguna limitación no mencionada en el presente documento, en particular a ninguna limitación de un “contexto común” de las características individuales del procedimiento o dispositivo según la invención, sea quien sea el que concibiera un “contexto común” de este tipo y como estuviera construido, ya que no se podría justificar a partir de ninguna palabra del presente documento.

•

Puesto que todos los términos o sentidos de las reivindicaciones de esta solicitud de patente definen estas características del procedimiento o dispositivo según la invención únicamente y exclusivamente en su esencia, el presente documento no toca nada en absoluto de las variantes de implementación de estas características en cualquier forma de realización de la invención, más bien estas características son “funcionales” o “abstractas”, es decir puramente conceptuales.

•

En el presente documento (incluyendo sus reivindicaciones) la palabra “uno” (en el caso de que no exista “al menos”) y todas sus conjugaciones, declinaciones o variaciones representa “al menos uno”, siendo posible una sustitución con algún tipo de sentido.

Al respecto de las reivindicaciones 1 y 2: su primer párrafo establece las características y términos fundamentales de la disposición PT con la que funciona el procedimiento de navegación por la red.

•

Para esto acordémonos en primer lugar de que en esta solicitud de patente un OC0 según la reivindicación 1 ó 2 (véase la sección C) sólo necesita ser potencial. Un ejemplo conocido de esto es una conexión OSI que resulta establecida conceptualmente a más tardar con la decisión de un TLN de comenzar una llamada a cualquier número de emergencia, por ejemplo 110 ó 112, es decir existe (en el sentido potencial) desde el momento en el que el TLN (abstracto) (como parte del sistema terminal A0) piensa en llamarlo. Otro ejemplo de esto es una conexión OSI potencial entre el TLN A0 y un TLN Z0 potencial accesible para el primero cuando el segundo lo llama, considerándose como el instante del MHO aquél en que ya hubiera un TLN Z0, un supuesto cuya autorización resulta aquí irrelevante, (pero no está desautorizado). En el caso del uso de 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 a continuación una “selección de programa”.

En este caso se indica también una reducción de los términos en esta patente que no tienen efecto: cuando se habla de un PTC entre A0 y Z0 hay que entender siempre “un PTC entre cada uno de sus al menos un TLN en A0 y Z0”.

•

En segundo lugar se mencionan ya en este caso las características

o en la reivindicación 1 de un “MHO-GeMa” y

o en la reivindicación 2 del 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 la sección A y C).

También se hacen unas breves aclaraciones con respecto a las etapas a)-b) de la reivindicación 1 y 2, en las que debería resultar claro que existen otras etapas, no mencionadas en a)-b) pero evidentes para el experto en la materia, y por tanto no se consideran, que exige la navegación por la red..

•

La realización de un MHO de A0 en una Netx según la reivindicación 1/2 se inicia en la realización al menos una vez de la etapa de comprobación a) a través de cuya determinación de la “presencia de una señal de accesibilidad de A0 en la Netx”. Puesto que las descripciones anteriores de la invención no limitan en ningún modo esto, el contenido del sentido de estos términos a) es precisamente lo evidente intuitivamente: existe una señal, de cualquier tipo y detectada donde fuere y cómo fuere, cuya presencia dice que A0 puede comunicarse, puesto que A0 puede registrarse o está registrado en la Netx, por medio de su IAD o BSx y su MIAD0 local con los sistemas terminales en el conjunto de Internet y es accesible en la Netx (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) y b) puede efectuar un solapamiento suyo temporal arbitrario, l experto en la materia conoce por ejemplo que un procedimiento de comprobación previo separado de a) no es necesario para ejecutar a) y b). En particular se puede producir según el sentido o la terminología una ejecución de la comprobación a) una vez o varias veces.

•

La realización de acuerdo con la reivindicación 1 ó 2 de un MHO puede usar, implicar o presuponer una implementación material, además de las etapas a)-b), de otras etapas que eventualmente pueden producirse automáticamente y/o comprender otras MHO-Ma alternativas opcionales como quizá el uso de IP TV. Es decir: las reivindicaciones 1 y 2 no dicen absolutamente nada de cualesquiera cuestiones de la implementación material de sus procedimientos, por ejemplo cuando y cómo y bajo qué condiciones se puede y/o se tiene que producir el registro efectivo de A0 en la Netx. Para el experto en la materia resulta claro, sin embargo, que eventualmente ninguna de las etapas de procedimiento necesarias para el registro se tienen que ejecutar para que el MHO se pueda iniciar y/o ejecutar y/o terminar según a)-b) (como en particular debería ser posible en el caso de la implementación del protocolo IPv6 de Internet en sistemas terminales/IAD/BS). Es decir: el procedimiento Wsurfing/de navegación por la red puede transcurrir completamente y varias veces aunque el navegante o su sistema terminal no estén registrados en ningún sitio o en cualquier caso no en los IAD/BS reales o virtuales que eventualmente realizan el registro profilácticamente e implementados de forma distribuida o de forma local. Lo mismo se aplica para

su establecimiento y/o mantenimiento profiláctico de una conexión de navegación por la red NSSC0 completa o parcial para A0 y la A0-OCO y/o la conexión IP TV y/u otras conexiones MHO-Ma opcionales para A0 (por ejemplo para cualquier consejo relevante para la seguridad a su usuario y/o garante de seguridad en otro lugar) antes de registrarse y/o desrregistrarse A0 en la Netx, conociendo el usuario A0 la profilaxis de este tipo y/o haciendo uso o no de la misma).

O sea, para el experto en la materia ninguna de las variantes del procedimiento de este tipo según la invención, de las que aquí se han citado sólo algunas a modo de ejemplo, queda excluida a partir de los términos o el sentido de la reivindicación 1 ó 2 y su descripción en esta solicitud de patente. Es decir que el sentido o los términos de la reivindicación 1 ó 2, al menos por esta descripción del procedimiento según la invención, comprende todas las variantes similares.

•

El procedimiento Wsurfing de acuerdo con 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 para ello por tanto ninguna limitación de la “libertad de túneles”. Sin embargo su MHO está sujeto a una limitación con respecto a la reivindicación 2, en cuanto que tiene que materializar una GeMa y su correlación CI. Estas limitaciones no aparecen en la práctica como tal fenómeno, sino como una ventaja del procedimiento de navegación por la red (véase la sección C para las ventajas de una GeMa y su correlación CI en un MHO).

•

Un relevo abstracto se refiere a cada uno de los bits transmitidos a A0-OC0. Pero sí queda claro que cada implementación material del procedimiento de navegación por la red procederá de tal manera que solo necesite garantizar la materialización de esta característica de relevo sin túneles para ciertas condiciones (por ejemplo el volumen de información transmitida a A0-OC0). El experto en la materia conoce cómo ocurre esto y bajo qué condiciones y por qué esto resulta razonable.

•

En relación con el sentido y la terminología de la reivindicación 1/2 se menciona finalmente aún que

o las variantes de la implementación abstracta o material de una “gestión según MHOS0 de una realización de HO” (bajo el control del MIAD0 local virtual o real implementado de forma distribuida o local y sus respectivas partes MHOS) al menos según las aclaraciones precedentes resultan conocidas para el experto en la materia y por tanto resultan irrelevantes, o sea que 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”

•

no exige un intercambio adicional de PDU (sino que puede producirse mediante el intercambio de PDU que aún así se requiere),

•

ni queda tampoco limitada en relación con la red usada para la misma (puede usar otra red diferente a la que de todos modos usa).

Con respecto al ámbito de protección de la reivindicación 1 ó 2 esto implica en particular: que en cuanto una forma de realización determina por medio de cualquier no MHOM (supuesto) (que en el presente documento no queda limitado de ninguna forma) la presencia de una señal según a) y ocasionándose así la ejecución con éxito de la etapa b) de cualquier forma, entra (conjuntamente con este no MHOM) en su ámbito de protección.

Mediante las cinco figuras 6a-e se efectúan además aclaraciones fundamentales con respecto a las disposiciones PT, en las que el procedimiento de navegación por la red, Wsurfing sea aplicable, en las que su MHOM y/o su MIAD local virtual o real y/o su MHOS estén implementados de forma distribuida y de manera abstracta o material. Por simplicidad se parte en la figura 6a de que un sistema S0 con una parte de un MIAD local virtual podría controlar y eventualmente ejecutar sólo la KoMa y un sistema S1 con otra parte de un MIAD local virtual sólo podría controlar y eventualmente ejecutar GeMa (ambos las dos por completo). Las tres figuras 6 b-d se diferencian de la misma sólo en cuanto a que como en las figuras 6 b-c cada uno de los dos tipos y en la figura 6d ambos tipos de MHO-Ma están situados en un MIAD0 local real. A este respecto se observa que S0 y/o S1 y sus partes de MIAD local virtual (en las figuras 6a-c) se pueden situar en una red PT cuyo operador da soporte entonces por tanto al procedimiento Wsurfing, de modo que en estos casos se puede colocar funcionalmente de forma más sencilla eventualmente otro MIAD local real, como en la figura 6d, en particular puede ser un sharedIAD de los que se instalan actualmente (véase más abajo). Por supuesto existe una multiplicidad de formas híbridas de estas disposiciones PT prototípicas para un dispositivo o procedimiento de navegación por la red, que sean evidentes a partir de la terminología o sentido de la reivindicación 1 ó 2 y de la descripción anterior. Resumiendo esto: todas las formas o las estructuras de las implementaciones abstractas y/o materiales distribuidas del procedimiento según la invención quedan recogidas para el experto en la materia con esta descripción del sentido o los términos de las reivindicaciones 1 ó 2.

De interés económico evidente, como se ha mencionado antes, resulta la integración completa en cuanto al procedimiento según la invención de un MIAD local en una red, sea una red PT o una WLAN grande, o por ejemplo en un servidor de red, puesto que así se puede conseguir un “equipamiento funcional” de muchos IAD sin capacidad de Wsurfing ya instalados con la funcionalidad de navegación por la red de forma sencilla (“servidor MIAD local virtual” completo). La figura 6e muestra esta disposición PT con una red grande WLAN y sólo un único servidor MIAD local virtual. Para conseguir la “privacidad del MIAD local” deseada en este caso, es decir para garantizar que el operador/gestor de red del servidor que aloja el servidor MIAD local virtual no obtenga el acceso a los MIAD locales virtuales alojado, la comunicación de un operador o gestor de tal MIAD local debe resultar igualmente ininteligible para el operador o gestor de la red/servidor como, por motivos de esta comunicación, la MHOS almacenada en un MIAD local virtual de este tipo para ello. El experto en la materia 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 o dispositivo de navegación por la red, es decir de su MIAD local, de su MHOS, de su MHOM, y de los módulos que ejecutan las funciones.

Las figuras 6 describen por lo tanto posibles divisiones, es decir posibles implementaciones distribuidas, (sólo de las GeMa necesarias para los MHO) desde otras funcionalidades MHO-Ma. Las figuras 7a-e representan para cada una de ellas una separación posible, es decir una implementación distribuida posible, de su función de control del MIAD0 local de un módulo de la función a ejecutar en otro sistema, es decir, todo lo que no distribuya aún la implementación del MHOS. Las figuras 8a-e describen, por tanto, para cada funcionalidad MHO-Ma una separación posible de sus funciones de control del MIAD0 local de al menos una parte del MHOS que las controla mediante su distribución en dos sistemas. En este sentido se puede considerar al menos una parte del MHOS en sí como realizable, o por lo menos se presta a interpretación.

Las implementaciones distribuidas de este tipo adecuadas, en último término materiales, facilitan a los operadores de grandes redes o de servidores de Internet el ofrecer, sobre la base del procedimiento según la invención los servicios multimedia PT innovadores de lo más variado en todas las cooperaciones posibles, por ejemplo con operadores sharedWLAN y/o productores de programas para IP TV.

Después de esto resulta particularmente claro que “presenta” en los términos de las reivindicaciones no debería quedar limitado a “contiene” o “comprende” en el “momento actual” sino que para un “presenta” se aplican todo el resto de posibilidades de interpretación del lenguaje natural que tengan sentido en este contexto, por ejemplo “relacionada con” y/o “que tiene que observar/seguir”, y esto comprende también el futuro.

Claims (14)

1. REIVINDICACIONES

   1.

   Procedimiento para proporcionar información, en el que un primer sistema terminal (A0) y un segundo sistema terminal (Z0) están conectados mediante una conexión OSI y en el que el primer sistema terminal está asociado a una red local que presenta un dispositivo de acceso integrado de gestión (IAD0 local) que ejecuta las siguientes etapas:

   -dependiendo de la presencia, cuando se da, de un traspaso potencial o actual, proporcionar una información de conveniencia con respecto a la ejecución del traspaso potencial o actual en ambos sistemas terminales antes o al comienzo del traspaso -proporcionar además una comunicación comercial para una acción comercial en el primer y/o segundo sistema terminal -proporcionándose la comunicación comercial de manera correlacionada cuando se proporciona la información de conveniencia.

2. 2.

   Procedimiento de acuerdo con la reivindicación 1, caracterizado porque la comunicación comercial se refiere a la comunicación de una nota publicitaria al primer sistema terminal y/o al segundo sistema terminal.

3. 3.

   Procedimiento de acuerdo con la reivindicación 1 ó 2, caracterizado porque a través del dispositivo de acceso integrado de gestión se proporcionan a un sistema terminal después de o simultáneamente con una señal de sonido informaciones gráficas o textuales paralelamente, sin afectar a la información de sonido.

4. 4.

   Procedimiento de acuerdo con una de las reivindicaciones anteriores, caracterizado porque el primer sistema terminal es un teléfono WiFi.

5. 5.

   Procedimiento de acuerdo con una de las reivindicaciones anteriores, caracterizado porque el segundo sistema terminal es un teléfono.

6. 6.

   Procedimiento de acuerdo con una de las reivindicaciones anteriores, caracterizado porque la comunicación comercial correspondiente a la acción comercial se realiza sin el uso de una tecnología de tunelado.

7. 7.

   Procedimiento de acuerdo con una de las reivindicaciones anteriores, caracterizado porque se proporciona además una comunicación comercial correspondiente a la acción comercial de manera correlacionada cuando se proporciona, mediante el dispositivo de acceso integrado de gestión, una acción de control que controla y efectúa una concesión de permisos y vigilancia del uso de la red local del primer sistema terminal.

8. 8.

   Dispositivo de acceso integrado de gestión (IAD0 local) para la ejecución del procedimiento de acuerdo con la reivindicación 1 con medios que están adaptados y configurados de manera que el dispositivo de acceso integrado de gestión es adecuado para realizar las siguientes etapas:

   -dependiendo de la presencia, cuando se da, de un traspaso actual o potencial, proporcionar información de conveniencia con respecto a la ejecución del traspaso potencial o actual en dos sistemas terminales (A0, Z0) que están conectados a través de una conexión OSI, antes o al comienzo del traspaso, -proporcionar además una comunicación comercial correspondiente a una acción comercial al primer sistema terminal (A0) y/o al segundo sistema terminal (Z0); -proporcionándose la comunicación comercial de manera correlacionada cuando se proporciona la información de conveniencia.

9. 9.

   Dispositivo de acceso integrado de gestión de acuerdo con la reivindicación 8, caracterizado porque los medios están configurados y adaptados de manera que la comunicación comercial se refiere a la comunicación de una nota publicitaria al primer sistema terminal y/o al segundo sistema terminal.

10. 10.

    Dispositivo de acceso integrado de gestión de acuerdo con la reivindicación 8 ó 9, caracterizado porque los medios están configurados y adaptados de manera que se proporcionan a un sistema terminal después de

    o simultáneamente con una señal de sonido informaciones gráficas o textuales paralelamente, sin afectar a la información de sonido.

11. 11.

    Dispositivo de acceso integrado de gestión de acuerdo con una de las reivindicaciones 8 a 10, caracterizado porque los medios están configurados y adaptados de manera que el dispositivo de acceso integrado de gestión ejecuta las etapas mencionadas cuando el primer sistema terminal es un teléfono WiFi.

12. 12.

    Dispositivo de acceso integrado de gestión de acuerdo con una de las reivindicaciones 8 a 11, caracterizado porque los medios están configurados y adaptados de manera que el dispositivo de acceso integrado de gestión ejecuta las etapas mencionadas cuando el segundo sistema terminal es un teléfono.

13. 13.

    Dispositivo de acceso integrado de gestión de acuerdo con una de las reivindicaciones 8 a 12, caracterizado porque los medios están configurados y adaptados de manera que la comunicación comercial

    correspondiente a la acción comercial se realiza sin el uso de una tecnología de tunelado.

14. 14.

    Dispositivo de acceso integrado de gestión de acuerdo con una de las reivindicaciones 8 a 13, caracterizado porque los medios están configurados y adaptados de manera que se proporciona además una comunicación comercial correspondiente a la acción comercial de manera correlacionada cuando se proporciona, mediante el dispositivo de acceso integrado de gestión, una acción de control que controla y ejecuta una concesión de permisos y vigilancia del uso de la red local del primer sistema terminal.