patent (AM, AZ, B Y, KG, KZ, MD, U, TJ, TM), European For two-ktter cades and other abbreviations, refer to the "G id- patent (AT, BB, CH, CY, DB, DK, ES, FI, FR, GB, GR, IB, ance Notes on Codes andAbbreviations" appearing at the begin- GG, LU, MC, L, PT, SE, TR), OAPI patent (BF, BJ, CFT ning ofeach regular issue ofthe PCT Gazétte. CG, CI, CM, GA, GN, G , ML, MR, E, SN, TD.-TG). Published: — with intemational search report
"SISTEMAS Y METODOS PARA ACCEDER A RECURSOS EN LA RED" ANTECEDENTES DE LA INVENCION Campo de la invención. La presente invención se relaciona con nombres de dominio de nivel superior, y en particular con métodos y sistemas para crear nombres de dominio de nivel superior que no usan el estándar ICANN. Descripción del Arte Previo. La red global de computadoras, mejor conocida como internet, es accesible usando una computadora cliente o similar ejecutando un navegador en la red y usando un medio de conexión para comunicaciones. La comunicación puede establecerse a través de una línea telefónica normal usando un modulador-demodulador, generalmente conocido como módem, una línea DSL digital de suscripción (Digital Suscriber Line), un módem para comunicación por cable, una tarjeta de interfaz para red NIC (Network Interface Card), una red de área local LAN (Local Area Network) o algún medio similar. A través de cualquiera de estas formas de comunicación, la computadora accede al Proveedor de los Servicios de Internet ISP (Internet Service Provider). Los proveedores ISP mas pequeños se conectaran entonces a proveedores ISP mas grandes. Como resultado de esto, cada computadora en el internet estará "conectada" a todas las - 1 - otras computadoras en el internet. Una vez conectado o en línea, un usuario utiliza el navegador de la red para acceder y ver portales o sitios en la red ingresando una dirección de internet en forma de un nombre de dominio, tal como www.nombrededominiol.com. por ejemplo, un localizador uniforme de recursos URL (Uniform Resource Locator), en la forma de http://www.nombrededomMol.com/index.htm. Así, por ejemplo, la dirección de internet para el portal de la Casa Blanca es www.whitehouse.gov. El uso de tales nombres de dominio comprensibles para el ser humano hace mas fácil que los usuarios recuerden direcciones de internet, sin embargo estos nombres de dominio necesitan traducirse a direcciones IP de protocolo de internet. Una dirección IP es un número de 32 bits, expresada normalmente como 4 octetos en un número con puntos decimales. Una dirección IP típica puede estar en forma de 216.27.61.137. El navegador extrae la dirección de internet, www.nombrededominiol.com, del localizador URL, mencionado antes, y transmite una solicitud o petición de búsqueda, que incluye la dirección extraída, a un servidor DNS de sistemas de nombre de dominio (Domain Ñame System Server). Este sistema da a cada computadora en el internet una dirección IP que corresponde a un nombre de dominio. Los servidores DNS incluyen bases de - 2 - datos que gestionan nombres de dominio para direcciones IP. En respuesta a la solicitud de búsqueda, el servidor DNS regresa la dirección EP correspondiente al nombre de dominio hacia el navegador. El navegador entonces usa la dirección IP para tener acceso a la computadora correspondiente. Puede tomar un número de servidores la localización de la dirección IP correspondiente. Por ejemplo, un primer servidor de nombres para el dominio de nivel superior ".com" almacena la dirección IP para un segundo servidor de nombres que almacena los nombres anfitrión. Una pregunta separada es enseguida hecha por el primer servidor de nombres al segundo servidor de nombres para la dirección IP real para el servidor del nombre de dominiol . Una base de datos que incluye cada nombre de dominio y la dirección IP numérica del servidor asociado con ese nombre de dominio es mantenida. El nombre de dominio para la dirección de internet www.nombrededominio 1.com. por ejemplo, es "nombrededominiol". La frase "dominio de nivel superior" (TLD) se refiere al sufijo adjunto al nombre de dominio de internet. De esta manera, por ejemplo, el sufijo ".com" se considera un nombre de dominio de nivel superior. Cada nombre TLD tiene su propia base de datos de nombres de dominio. Los nombres de dominio de nivel superior son definidos y aprobados por la Corporación de Internet para Nombres y Números Asignados, ICANN por - 3 - sus siglas en inglés, (Internet Corporation For Assigned ames and Numbers). La ICANN es una corporación privada con responsabilidad para asignación de espacios de dirección IP, cesión de parámetros de protocolo, manejo de sistemas de nombres de dominio y funciones de manejo del sistema del servidor principal o raíz. Desventajosamente, hay un número muy limitado de dominios de nivel superior en conformidad con la ICANN. Como resultado de ello, esto limita el número de nombres de dominio que usan en estándar ICANN disponible para los usuarios. Además, la rareza de los dominios de nivel superior hace mas difícil organizar el acceso al internet. Los nombres de dominio de nivel superior compatibles con la ICANN incluyen ".com", ".net", ".org", ".gob", ".mil", ".edu" y códigos de país de dos letras, tal como ".tv". La ICANN también ha aprobado recientemente los siguientes nuevos nombres de dominio de nivel superior, ".biz", ".info", ".ñame", ".pro", ".aero", ".museum". y ".coop",. Otros dominios TLD estándares incluyen ".arpa", " int". La extensión ".com" esta encaminada para negocios comerciales, ".net" esta dirigida para organizaciones en la red, ".edu" esta enfocada para escuelas o un lugar de aprendizaje superior, ".org" está orientada para organizaciones, ".gob" está dirigida para sitios del gobierno. Los nuevos nombres TLD de dominio de nivel superior están dirigidos para usarse como siguen, ".biz" esta enfocada para negocios, ".info" es para uso no restringido, ".ñame" esta enfocado para personas, ".pro" esta dirigido a profesionistas (ejemplo, contadores, abogados, físicos e ingenieros), ".aero" esta dirigida a la industria del transporte aéreo, ".museum" esta enfocada para los museos y ".coop" esta enfocada para cooperativas. Los nombres de dominio pueden duplicarse entre nombres de dominio de nivel superior diferentes. Por ejemplo, un usuario puede ver dos portales de internet completamente diferentes mgresando www.nombrededominiol.com y www.nombrededominio 1.net en una ventana del navegador. Como se describe previamente, los usuarios ingresan típicamente una dirección de internet del portal o sitio que ellos están buscando para entrar en una línea de dirección de sus navegadores (ejemplo, www.nombrededominio 1.com) o de lo contrario seleccionan la dirección de internet. El navegador funciona enseguida con el sistema operativo de la computadora para hacer contacto con un servidor del sistema de nombres de dominio que traduce el nombre de dominio alfanumérico a una dirección G? numérica, de manera que la solicitud pueda ser encaminada al servidor apropiado en el internet. La solicitud para "www.nombrededominiol.com", a manera de ejemplo, puede ser traducida a 183.52.148.72. La solicitud para esa página en la red específica puede ser entonces encaminada al servidor del nombre de dominio 1.
BREVE DESCRIPCIÓN DE LA INVENCIÓN La presente invención esta dirigida á métodos y sistemas utilizados para proporcionar nombres de dominio de nivel superior sobre y por encima de aquellos especificados por la ICANN u otra autoridad autorizada para aprobar nombres de dominio de nivel superior estandarizados. De acuerdo con una modalidad de la presente invención, se utiliza un programa de cómputo para la traducción o gestión de direcciones para alterar direcciones de internet mediante lo cual se posibilita que los navegadores y otros dispositivos o sistemas de conexión tengan acceso y/o utilicen dominios de nivel superior que aun no están activados o aprobados por ICANN. La interceptación y modificación de las direcciones de internet que utilizan nombres de dominio (TLD) no reconocidos por la ICANN pueden ser desarrolladas usando diferentes modalidades de procesos y sistemas de conformidad con la presente invención. En una modalidad, el proceso de manejar nombres de dominio TLD que usan el estándar ICANN se desarrolla definiendo primero una serie de nombres de dominio que no existen en la infraestructura de nombres de dominio de nivel superior del internet definida por ICANN. Algunos o todos estos nuevos nombres de dominio pueden ser vendidos a operadores de sitio o portales de internet, consumidores, o de lo contrario distribuidos. En una modalidad, se requiere opcionalmente que los nombres de dominio usen el estándar solicitud de Comentarios (RFC 1035), en la que ellos son limitados al conjuntos de caracteres definidos por RFC 1035, que incluyen caracteres seleccionados del conjunto de letras de la A a la Z, en mayúsculas o minúsculas, los números 0 al 9, y un guión De esta manera, los nombres de dominio usados en la siguiente descripción utilizan caracteres conforme al RFC 1035. El programa de cómputo de traducción de direcciones es distribuido correspondientemente a los usuarios. Este programa intercepta peticiones de una solicitud cliente, tal como un navegador, para direcciones de internet y evalúa si el usuario esta solicitando un dominio de nivel superior que no usa el estándar ICANN. Si la petición o solicitud contiene uno de los dominios que no usan el estándar ICANN, el programa de cómputo para traducción de direcciones convierte la solicitud o petición en una dirección de internet que usa el estándar ICANN. Opcionalmente, la conversión puede ser restringida a aquellas definidas como parte de un primer conjunto, en el que dicho primer conjunto esta definido por la entidad o compañía que maneja el procesamiento de dominios TLD qué no usan el estándar ICANN. Además, el programa de cómputo para traducción de direcciones convierte opcionalmente las direcciones de correo electrónico que usan los dominios que no están estandarizados con la ICANN, en direcciones de correo electrónico que están reconocidas por la infraestructura existente de correos electrónicos de internet. En una modalidad, el usuario baja o descarga un programa de cómputo para traducción de direcciones a un sistema de computadora cliente que incluye un elemento WinSock2 o un servicio equivalente que proporciona una interfaz hacia el proveedor (NSP) de espacio de nombres (Ñame Space Provider) y al proveedor (LSP) del servicio por capas o niveles (Layered Service Provider) para permitir la utilización de las direcciones de dominios que no usan el estándar ICANN, como se discute en mayor detalle adelante. El programa de cómputo para traducción de direcciones puede ser descargado o instalado desde un disco, un CD-ROM, vía una red, tal como el internet, o puede ser previamente instalado en la computadora cliente. El programa de cómputo para traducción de direcciones descargado intercepta solicitudes de dirección no estándares (aquellas direcciones que no terrninan en .com, .net, .org, .mil, un código de país, de dos letras, definido por ICANN, u otros dominios TLD especificados por ICAMM ) recibidas desde un navegador u otra aplicación y agrega una extensión que incluye un dominio válido que usa un estándar ICANN. Por ejemplo, la extensión ".new.net", puede ser anexada al final de la dirección solicitada. La dirección nuevamente modificada es entonces sometida o propuesta para resolución. Por ejemplo, un usuario descarga o baja el programa de cómputo para traducción de direcciones y enseguida, usando el navegador, solicita una dirección de internet que no usa el estándar ICANN, tal como elmejorprecio.auction (BestPrice.auction). Como en los sistemas convencionales, el proceso inicia con el navegador solicitando los servicios del sistema operativo para identificar la ubicación numérica del portal o sitio de internet solicitado. Al buscar la ubicación del servidor, el sistema operativo utiliza una herramienta de concatenación instalada por el programa de cómputo para traducción de direcciones. La herramienta de concatenación agrega una extensión, que incluye un dominio TLD que usa el estándar ICANN, a la solicitud del sitio o portal en el internet, tal como -".new.net", traduciendo la solicitud original a "elmejorprecio.auction.new.net" (BestPrice.auction.new.net) y enseguida vuelve a proponer la solicitud al sistema operativo. Con la extensión agregada, que usa el estándar ICANN, el sistema operativo conjuntamente con los servidores del sistema de nombres de dominio correspondientes identifica un servidor que este asociado con el sitio o portal solicitado. Los usuarios pueden también bajar o descargar, o de lo contrario instalar, un programa de cómputo para traducción de correo electrónico que modifica las direcciones de correo electrónico que incluyen dominios TLD que no usan el estándar ICANN. Opcionalmente, el programa para traducción de direcciones y el programa para traducción de correo electrónico se descargan juntos o como - 9 - una sola aplicación. El programa de cómputo para traducción de correo electrónico actúa en la etapa de envío de un correo electrónico para agregar ".new.net", u otra extensión designada que contenga un dominio de nivel superior TLD que usa un estándar ICANN, a una dirección de correo electrónico que tenga un dominio TLD que no usa el estándar ICANN. En la etapa de recepción, cuando se recibe un correo electrónico que tiene una dirección de correo electrónico que contiene una extensión, tal como ".new.net" en este ejemplo, anexa a la dirección de correo electrónico, la extensión es retirada. La dirección de correo electrónico es entonces exhibida al receptor como habiendo venido de una dirección que incluye el dominio TLD que no usa el estándar ICANN, pero que no incluye la extensión anexada que contiene el dominio TLD que usa el estándar ICANN. De esta manera, por ejemplo, al enviar un mensaje desde joe@jdealab.inc. donde ".inc" no es un dominio TLD que usa el estándar ICANN, el programa de cómputo para traducción de correo electrónico, en el lado del remitente, agrega o anexa la extensión que usa el estándar ICANN de manera que la dirección de retorno sea ahora joe@idealab.inc.new.net. Al recibir el mensaje de correo electrónico, el programa de cómputo para traducción de correo electrónico, en la parte receptora, detecta el proceso previo de adición de la extensión que usa el estándar ICANN, ".new.net", y retira la extensión - 10 - agregada para mostrar en pantalla la dirección de correo electrónico del remitente como joe(¾ideaIab.inc. Otra modalidad proporciona un proceso para tener acceso a las direcciones de internet, que no usan el estándar ICANN, a través del proveedor del servicio de internet ISP del usuario. Este acceso se lleva a cabo en forma transparente para el consumidor. Ventajosamente, la utilización de dominios que no usan el estándar ICANN atrae mas consumidores. A manera de ejemplo, el usuario ingresa o proporciona a un navegador una dirección de internet que no usa el estándar ICANN (por ejemplo, elmejorprecio.auction) de un sitio o portal o de otro recurso en la red. El navegador, en comunicación con el sistema operativo, envía una solicitud de búsqueda de dirección G? al servidor DNS del sistema de nombres de dominio del proveedor ISP del servicio de internet. El servidor del sistema de nombres de dominio ubica enseguida la dirección IP que representa el servidor de la página solicitada. En forma similar, las direcciones IP de los servidores de correo electrónico para direcciones de correo electrónico que usan nombres de dominio no estandarizados por ICANN son localizadas. Un aspecto de la presente invención es un método para tener acceso a recursos en la red usando una dirección de internet que tenga un nombre de dominio de nivel superior (TLD) que no usa el estándar ICANN, dicho método consiste en: recibir de la terminal cliente de un usuario datos que corresponden a - 11 - una primera dirección de internet que utiliza únicamente caracteres de coriformidad con RFC 1035, incluyendo dicha primera dirección de internet un dominio TLD que no usa el estándar ICANN, en el servidor DNS del sistema de nombres de dominio del proveedor ISP del servicio de internet de un usuario; recibir en la terminal cliente del usuario una respuesta negativa desde el servidor DNS del proveedor ISP del servicio de internet en respuesta a la recepción de los datos que corresponden a la primera dirección de internet; recibir la primera dirección de internet en un sistema convertidor de direcciones que se ejecuta en el terminal cliente del usuario, en donde dicho sistema convertidor anexa a la primera dirección de internet una extensión que incluye un dominio TLD que usa el estándar ICANN, mediante lo cual se crea una segunda dirección de internet; someter o proponer la segunda dirección al servidor DNS del proveedor ISP para localizar una dirección IP (de protocolo de internet) correspondiente; proporcionar la dirección IP correspondiente a un navegador del usuario; y conectar el navegador del usuario a un sistema que corresponde a la dirección IP de protocolo de internet. Otro aspecto de la presente invención es un sistema para tener acceso a recursos en la red usando direcciones de recurso en un ambiente conectado en red el cual requiere que las direcciones de recurso tengan un nombre de dominio de nivel superior que cumpla con un primer estándar, dicho sistema comprende: - 12 - una primera instrucción configurada para determinar si una primera dirección que usa el estándar RFC 1035 tiene un dominio TLD no estándar que pertenece a un primer conjunto de nombres de dominio TLD no estándares; una segunda instrucción configurada para anexar una extensión, que incluye por lo menos un dominio TLD de nivel superior estándar, a la primera dirección que usa el estándar RFC 1035 al menos parcialmente en respuesta a la primera instrucción que determina que la primera dirección tiene un dominio TLD no estándar que pertenece al primer conjunto de nombres de dominio TLD no estándares; y una tercera instrucción configurada para proporcionar la primera dirección con la extensió anexada, que incluye el nombre de dominio TLD estándar, a un servicio que convertirá la primera dirección con la extensión anexada, que incluye el nombre de dominio TLD estándar, en una dirección DP de protocolo de internet. Otro aspecto de la presente invención es un método para tener acceso a recursos en la red que usan una dirección de internet que tiene un dominio de nivel superior TLD no estándar, dicho método consiste en: proporcionar a un sistema cliente un proveedor de servicio por capas o niveles LSP (Layered Service Provider) configurado para filtrar direcciones de internet que contienen dominios no estandarizados y anexar a ellas dorninios TLD estándares correspondientes; recibir en el proveedor LSP una primera dirección de internet - 13 - que tiene un dominio TLD no estándar, en donde el proveedor LSP determina que el dominio TLD no estándar de la primera dirección de internet está en un primer conjunto de dominios TLD no estándares; al determinar que el dominio TLD no estándar está en el primer conjunto de dominios no estándares, agregar una extensión, que incluye al menos un dominio TLD estándar predeterminado, a la primera dirección de internet para crear una primera dirección de internet modificada; y proporcionar datos que corresponden a la primera dirección de internet modificada a un servidor intermediario de manera que éste pueda proporcionar la primera dirección de internet modificada a un servidor del sistema de nombres de dominio. Otro aspecto de la presente invención es un método para procesar direcciones de correo electrónico que tienen nombres de dominio de nivel superior no estándares, dicho método consistiendo en: usar un proveedor de servicio por capas o niveles (LSP) para interceptar, en un sistema cliente de un remitente, correo electrónico que tiene una primera dirección de correo electrónico del receptor con un dominio TLD no estándar; agregar, vía el proveedor LSP, una extensión, que incluye un dominio TLD estándar, a la primera dirección de correo electrónico del receptor para generar una dirección de correo electrónico del receptor modificada; someter o proponer la dirección de correo electrónico modificada del receptor al servidor SMTP de protocolo de - 14 - transferencia de correo simple (Simple Mail Transfer Protocol) del remitente; hacer contacto con un servidor DNS del sistema de nombres de dominio para localizar una dirección IP correspondiente para un sistema del servidor de correo electrónico asociado con la dirección de correo electrónico modificada del receptor; regresar la dirección IP correspondiente al servidor SMTP del remitente; someter el correo electrónico al sistema del servidor de correo electrónico para hacer la entrega al receptor usando la dirección IP correspondiente; y proporcionar el correo electrónico al receptor. Otro aspecto de la presente invención es un método para procesar direcciones de correo electrónico que tienen nombres de dominio TLD que no usan el estándar ICANN, dicho método comprende: determinar en el sistema cliente de un remitente si una primera dirección de correo electrónico para un correo electrónico que es despachado por el remitente contiene un nombre de dominio TLD que no usa el estándar ICANN, en el que la primera dirección de correo electrónico es asociada con un receptor de correo electrónico pretendido; anexar por lo menos un dominio TLD que usa el estándar ICANN a la primera dirección de correo electrónico al menos parcialmente en . respuesta a la determinación de que el correo electrónico contiene un nombre de dominio TLD que no usa el estándar ICANN, mediante lo cual se forma una segunda dirección de correo electrónico; someter la segunda dirección de correo electrónico a un - 15 - servidor DNS del sistema de nombres de dominio vía un servidor SMTP para localizar una dirección IP correspondiente a un servidor asociado con la segunda dirección de correo electrónico; localizar la dirección IP de protocolo de internet; y usar la dirección IP localizada para transmitir el correo electrónico de manera que pueda ser accedida por el receptor. Otro aspecto más de la presente invención es un sistema para procesar una dirección de correo electrónico que tenga un nombre de dominio TLD que no usa el estándar ICANN, consistiendo dicho método en: una primera instrucción configurada para determinar si una primera dirección de correo electrónico, para un mensaje de correo electrónico que es despachado por un remitente, contiene un nombre de dominio TLD que no usa el estándar ICANN, en el que dicha primera dirección de correo electrónico esta asociada con un receptor de correo electrónico pretendido; una segunda instrucción configurada para formar una segunda dirección de correo electrónico anexando una extensión, que incluye por lo menos un dominio TLD que usa el estándar ICANN, a la primera dirección de correo electrónico al menos en parte en respuesta a una determinación por parte de la primera instrucción que determina que la primera dirección de correo electrónico contiene un nombre de dominio TLD que usa el estándar ICANN; y una tercera instrucción configurada para proporcionar la segunda dirección de correo electrónico de manera que esta segunda dirección pueda ser sometida o - 16 - propuesta a un servidor DNS del sistema de nombres de dominio vía un sistema servidor para localizar con ello una dirección IP correspondiente. Un aspecto adicional de la presente invención es un sistema para procesar una dirección de correo electrónico que tenga un nombre de dominio TLD de nivel superior, que no usa el estándar ICANN, dicho sistema comprendiendo: una primera instrucción configurada para determinar si una primera dirección de correo electrónico, para un primer correo electrónico recibido, contiene un dominio predeterminado; y una segunda instrucción configurada para formar una segunda dirección de correo electrónico retirando de la pantalla el dominio predeterminado.
BREVE DESCRIPCIÓN PE LOS DIBUJOS La figura 1 ilustra un ejemplo de proceso para acceder a un recurso en la red utilizando una dirección de internet que contiene un nombre de dominio TLD, que no usa el estándar ICANN, de conformidad con una modalidad de la presente invención; Las figuras 2a-2b ilustran en mayor detalle un ejemplo de proceso para acceder a una dirección de internet que contiene un dominio TLD que no usa el estándar ICANN; La figura 3 ilustra un ejemplo de proceso para enviar un mensaje de correo - 17 - electrónico donde la dirección de correo electrónico del remitente contiene un dominio TLD que no es reconocido por ICANN; La figura 4 ilustra un ejemplo de proceso para enviar un mensaje de correo electrónico a una dirección del receptor, en donde dicha dirección del receptor incluye un dominio TLD que no esta reconocido por ICANN; La figura 5 ilustra un ejemplo de arquitectura que püede ser usada de conformidad con una modalidad de la presente invención; y La figura 6 ilustra un ejemplo de proceso para solicitar y ver una dirección de internet que contiene un dominio TLD, que no usa el estándar ICANN, utilizando un servidor intermediario de conformidad con una modalidad de la presente invención.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La presente invención esta dirigida a sistemas y métodos para tener acceso a recursos en la red que utilizan nombres de dominio de nivel superior no estandarizados. En particular, una modalidad de la presente invención provee sistemas y métodos para interceptar una dirección de internet que contiene un ; . : ·': ·? ? i- ¦ · nombre de dominio (TLD) de nivel superior, no reconocido por la ICANN, y lo traduce a una dirección de internet reconocido por la ICANN. El término ICANN, como se usa aquí, se refiere a la Corporación de Internet para Números - 18 - y Nombres Asignados (Internet Corporation for Assigned Ñames and Numbers) u otra entidad que tenga autoridad otorgada por el gobierno para aprobar o orear nombres de dominio de nivel superior estandarizados. A todo lo largo de la siguiente descripción, se hará referencia a varios detalles específicos de implementación, que incluyen, por ejemplo, convenciones de codificación, sistemas operativos, estándares de documentos y protocolos, sistemas de correo electrónico, sistemas de conexión a internet y registros en bases de datos. Estos detalles se proporcionan con el objeto de establecer completamente una modalidad preferida de la invención y no para limitar el alcance de la protección de la misma. Además, salvo que se indique lo contrario, las funciones descritas aquí son desarrolladas preferentemente mediante código que se puede ejecutar en una o más computadoras. Por ejemplo, las siguientes discusiones se refieren a utilizar navegadores de red para tener acceso al internet haciendo uso de la presente invención. Por supuesto, otras herramientas de conectividad, tales como FTP, Gopher o Telnet pueden ser utilizadas también. Ahora se describirá una modalidad que utiliza una implementación basada en cliente para procesar nombres de dominio TLD no reconocidos por ICANN. Un sitio o portal en el internet se trasmite desde un servidor hasta un sistema de computadora cliente. El servidor esta asociado opcionalmente con una entidad que registra, vende y rastrea nombres de dominio de nivel superior no - 19 - estandarizados, llamada aquí, compañía de nombres de dominio TLD. Por ejemplo, New.net es un proveedor bien conocido de dominios TLD que no usan el estándar ICANN. Actualmente, millones de usuarios tienen la posibilidad de resolver los dominios TLD no estandarizados ofrecidos por New.net. El programa de cómputo para traducción de direcciones utilizado para implementar la solución basada en cliente puede ser bajada o descargada vía el portal o sitio en internet. Insertado en el portal o sitio en el internet se haya un programa para traducción de direcciones que puede ser descargado, por ejemplo, un Java applet o un control ActiveX, que pueden ser firmados digitalmente para asegurar su autenticidad y proporcionar alguna medida de seguridad que el autor certifica que el programa de cómputo para traducción de direcciones es seguro de ejecutar y que no ha sido alterado. Al ver la página en el internet, usando un navegador basado en cliente, el usuario puede ser consultado por su navegador en el internet si el programa de cómputo para traducción de direcciones insertado deberá ser ejecutado, suponiendo que el navegador verifica que la firma digital es válida y que el contenido no ha sido alterado desde que éste fue firmado digitalmente. Una vez que el usuario esta de acuerdo en permitir que se ejecute el programa para traducción de direcciones insertado, dicho programa verifica que el sistema del usuario contiene Microsoft WinSock2, o una interfaz de - 20 - programación equivalente. WinSock, que es una abreviatura para Windows Sockets, es una interfaz de programación de la aplicación (API) para desarrollar programas compatibles con Microsoft Windows que pueden comunicarse con otras máquinas vía el protocolo TCP/IP o similar. Por supuesto, pueden utilizarse también otros sistemas operativos e interfaces API. Si el sistema del usuario contiene Winsock2 o un equivalente, el programa insertado instala un proveedor (NSP) de espacio de nombres Winsock2, también llamado, en este ejemplo, New.net o un proveedor TLD NSP, para proporcionar funcionalidad para el procesamiento de dominios no reconocidos por ICANN. Winsock2 utiliza el modelo de arquitectura WOSA de sistemas abiertos de
Windows (Windows Open Systems Arquitecture), el cual separa la interfaz API del proveedor del servicio de protocolo. La librería o fichero (DLL), de conexión dinámica (Dynamic Link Library) de WinSock proporciona la interfaz API estándar y el nivel o capa del proveedor del servicio de cada vendedor es instalada debajo de la interfaz API estándar. La capa API comunica a un proveedor del servicio vía una interfaz del proveedor del servicio (SPI) estandarizada, y puede multiplexarse entre múltiples proveedores del servicio simultáneamente. Winsock2 contiene un primer proveedor NSP, llamado aquí proveedor por omisión, y el proveedor NSP de New.net es agregado como un segundo proveedor NSP. El proveedor por omisión es instalado típicamente - 21 - cuando se instala un soporte de protocolo de control de transmisión/protocolo de internet (TCP/IP). Un proveedor NSP de Winsock2 es una librería de conexión dinámica (DLL) que permite la conversión de nombres alfanuméricos, tal como www.nombrededominiol.com, a direcciones numéricas, tal como 192.9.200.1, usadas para hacer contacto con computadoras específicas y sus servicios. Cuando una dirección de internet es ingresada en un navegador en la red, o referida mediante un vínculo en un documento HTML, el navegador usa Winsock2 o un programa equivalente para desarrollar la conversión usando la interfaz (SPI ) del proveedor del servicio de Winsock2. Por supuesto, la dirección de internet puede ser proporcionada a Winsock2 mediante otras aplicaciones, así como también por medio de un navegador. Si el usuario esta utilizando Windows 3.1 o Windows 95, por ejemplo, donde no esta disponible el modelo de red avanzado de Winsock2, entonces el usuario vuelve a nombrar "winsock.dll" y coloca una librería DLL con una interfaz API compatible que lleva a cabo el filtrado antes de llamar a la librería DLL de Winsock original. El proveedor NSP de New.net, una vez instalado como se describe antes, es puesto en la lista del catálogo de proveedores de espacio de nombres del servicio Winsock2 en adición al proveedor por omisión. Una vez que el - 22 - proveedor NSP New.net es puesto en la lista en el catálogo de proveedores NSP de Winsock2, una aplicación utilizada después de que se instala el proveedor NSP de New.net tiene acceso a los servicios NSP de New.net vía Winsock2, como en el ejemplo del navegador de la red descrito antes. En general, los proveedores NSP de espacio de nombres llevan a cabo conversiones de nombres de dominio usando el protocolo de búsqueda del servidor DNS para establecer una conexión con los servidores del sistema de nombres de dominio del usuario y localizar las direcciones IP de protocolo de internet que son típicamente proporcionadas por el proveedor del servicio de internet (ISP) de un usuario. Usando el protocolo del servidor DNS, un proveedor de espacio de nombres (NSP) envía la dirección alfanumérica al servidor DNS y recibe la o las direcciones IP, o cuando es apropiado, recibe una respuesta de que la dirección alfanumérica no es válida. Por ejemplo, si un usuario solicita una dirección de internet con un dominio que no usa el estándar ICANN, tal como www.idealab.inc. el proveedor por omisión no validaría la dirección, a menos que el proveedor ISP del servicio de internet haya previsto que sus servidores DNS reconozcan los dominios que no usan el estándar ICANN, como se describe más adelante. Sin embargo, si el dominio TLD que no usa el estándar ICANN no esta registrado con el proveedor, entonces con el proveedor NSP de New.net instalado, la dirección será resuelta. - 23 - La figura 1 ilustra un ejemplo de proceso 100 donde un nombre de
dominio de nivel superior que no usa el estándar ICANN, de conformidad con la
presente invención, es utilizado dentro de una dirección de internet. En una
modalidad, los nombres de dominio son requeridos opcionalmente para estar en
conformidad con RFC 1035, en la que ellos son restringidos a un conjunto de
caracteres definidos por RFC 1035, que incluye caracteres seleccionados del
conjunto de letras de lá A a la Z, en mayúsculas y minúsculas, los números del 0
al 9 y un guión
El usuario inicialmente ingresa, o de lo contrario proporciona, una
dirección de internet usando un navegador u otra aplicación en el estado 102. El
navegador intenta verificar la validez de la dirección haciendo contacto con el
servidor (ISP DNS) del sistema de nombres de dominio del proveedor del
servicio de internet del usuario en el estado 104. Si el nombre de dominioTLD
que no usa el estándar ICANN ha sido registrado previamente oon el servidor ; v > ! US O - · ISP DNS del usuario, entonces este servidor localiza y regresa una dirección IP
de protocolo de internet correspondiente en el estado 106. Una vez que se
regresa la dirección IP, el navegador se conecta al servidor representado por la
dirección IP en el estado 108. El navegador localiza entonces y despliega en el
monitor o pantalla del sistema cliente el recurso solicitado en el estado 118.
Alternativamente, si el nombre de dominio TLD que no usa el estándar
- 24 - ICANN, no esta registrado con el servidor ISP DNS del usuario, entonces
insock2 determina si esta disponible en el sistema cliente una conexión
apropiada, tal como un programa de cómputo para traducción de direcciones
descrito antes, en el estado 110. Si no se encuentra dicho programa, el usuario
recibe desde el navegador un error "No Encontrado" (Not Found error). Si el
programa de cómputo esta disponible, una extensión, que incluya un dominio
TLD que usa el estándar ICANN, es agregada al final de la dirección de internet
sometida usando una herramienta de concatenación en el estado 114. Por
ejemplo, se ingresa www.idealab.inc en el campo de dirección del navegador. El
proveedor NSP de New.net agrega ".new.net" al final de la dirección de internet,
haciendo la dirección compatible con el estándar ICANN, y así la dirección de
internet nuevamente modificada puede ser resuelta por el servidor del sistema de
nombres de dominio del proveedor del sistema de internet (ISP DNS). La
dirección de internet nuevamente modificada www.idealab.inc.new.net. es
entonces nuevamente propuesta al servidor ISP DNS del usuario en el estado • ..' ;on A .. .
116. El servidor DNS verifica la validez de la dirección de internet modificada y
localiza la dirección IP correspondiente en el estado 108. La dirección TP
correspondiente es devuelta al navegador y el sitio o portal en el internet es
localizado y desplegado usando el navegador en el estado 118
Las figuras 2a-2b ilustran un ejemplo de proceso 200 que utiliza dominios
- 25 - TLD no estándares. El proceso 200 puede ser usado también con otras direcciones de internet utilizando protocolos diferentes, tales como FTP (Protocolo de Transferencia de Archivos), Gopher, Telnet o uno similar. Además, mientras que la siguiente descripción supone que se esta utilizando un navegador para solicitar recursos en la red, la presente invención puede usarse con otras aplicaciones de solicitud. En el estado 202, un usuario selecciona o ingresa una dirección de internet en un navegador otro programa que lleve a cabo conversiones desde direcciones alfanuméricas a direcciones IP de protocolo de internet vía el Winsock2 o una interfaz equivalente. El proveedor por omisión y el proveedor NSP de espacio de nombres de New.net serán entonces contactados por el servicio de Winsock2 vía llamadas del proveedor ISP en el estado 204. En el estado 216, el proveedor NSP de New.net examina la dirección 206 de internet para determinar si ella satisface el criterio de terminación con una de las varias terminaciones o nombres de dominio predefinidos que no son normalmente válidos en el espacio de nombres del sistema DNS de ICANN. Una compañía de mercadeo de dominios TLD puede definir, registrar, vender y rastrear estos nombres de dominio de nivel superior predefinidos y nombres de dominio dentro de cada uno de los dominios de nivel superior definidos de la compañía. Estos dominios TLD no estandarizados pueden incluir terminaciones como ".inc", ".store", ".kids", ".furniture", ".hobbies", ".shop", ".law", ".family" - 26 - y así por el estilo. Por ejemplo, New.net ofrece actualmente 20 dominios TLD de nivel superior no estandarizados. En una modalidad de la presente invención, el proveedor NSP de New.net es actualizado periódicamente haciendo contacto con un servidor anfitrión para actualizar una lista de las terminaciones reconocidas o definidas no estandarizadas. Opcionalmente, el proveedor NSP de New.net puede buscar cualesquier terminación, incluyendo aquellas no definidas por la compañía de mercadeo de dominios TLD, que no sean parte del espacio de nombres del servidor del sistema de nombres de dominio DNS de ICANN, y que de esta forma no son estándares (es decir no terminan en ".com", ".org", ".mil", ".gob" o la terminación de dos letras de un país tal como ".uk", ".de", etc.). Si la dirección 206 de internet cumple con los criterios de tener una de las terminaciones no estándares definidas, el proveedor NSP de New.net convierte la dirección 206 en el estado 216 en una dirección de internet que incluye un dominio TLD que usa el estándar ICANN, asociada con los servidores DNS de la compañía que opera el sistema para el manejo de los dominios TLD no estándares, tal como New.net. Por ejemplo, una dirección solicitada, tal como www.idealab.inc. sería traducida internamente por el proveedor NSP de New.net a www.idealab.inc.new.net. La interfaz Winsock2 o una equivalente es entonces contactada por el proveedor NSP de New.net y recibe la dirección de internet traducida en el estado 218 como si hubiera venido de una aplicación - 27 - ordinaria de Winsock2 (no de un proveedor del servicio). Concurrentemente, la dirección 206 de internet se pasa al proveedor por omisión en el estado 208, lo cual da como resultado que el servidor DNS del proveedor ISP sea contactado en el estado 210 para localizar una dirección IP correspondiente al servidor para la dirección 206 solicitada. Debido a que la dirección 206 de internet termina en un nombre de dominio no estándar, ".inc" en este ejemplo, se envía de regreso un mensaje al proveedor por omisión en el estado 212 indicando que no se encontró una dirección IP correspondiente. El proveedor por omisión devuelve entonces una respuesta negativa a la interfaz Winsock2 en el estado 214, indicando qué el servidor DNS no tiene una dirección IP correspondiente para la dirección 206 de internet solicitada. Una solicitud o petición secundaria se hace en el estado 230 al proveedor NSP del proveedor por omisión y al proveedor NSP de New.net por medio de Winsock2 para buscar la dirección traducida, www.idealab.inc.new.net. Cuando el proveedor NSP de New.net recibe la solicitud secundaria en el estado 242, el proveedor NSP de New.net verifica nuevamente que la dirección de internet propuesta no tenga uno de los dominios TLD no estándares predefinidos en el estado 244. Debido a que la dirección tiene ahora una extensión que incluye un dominio TLD válido anexa a ella, el proveedor NSP de New.net responde entonces de regreso a Winsock2 en el estado 246 con una respuesta negativa. - 28 - Esto también evita que se presente un ciclo o circuito infinito. La misma segunda solicitud se hace también al proveedor por omisión. En el estado 232, el proveedor por omisión recibe la dirección traducida www.idealab.inc.new.net. El servidor del sistema DNS del proveedor ISP del servicio de internet es entonces contactado por el proveedor por omisión en el estado 234. El servidor DNS del proveedor ISP encuentra una dirección EP correspondiente para la dirección de internet solicitada. El servidor DNS usa ya sea un resultado previamente memorizado de una búsqueda válida, o hace contacto con servidores mas altos en la cadena hasta que alcanza aquellos controlados por la compañía de dominios TLD para desarrollar una búsqueda completa. Una vez encontrada, el servidor DNS del proveedor ISP devuelve dirección 238 IP correspondiente, de regreso hacia el proveedor por omisión en el estado 236. El proveedor por omisión devuelve entonces la dirección IP 238 a la interfaz Winsock2 en el estado 240. Para satisfacer la solicitud original hecha por el navegador en la red en este ejemplo, Winsock2 espera que todos los proveedores NSP contactados proporcionen sus resultados en el estado 248. Así, Winsock2 espera que la resolución de la solicitud 206 original, www.idealab.inc sea completada por ambos proveedores NSP. El proveedor NSP de New.net que da servicio a la solicitud original, a su vez, espera que se complete la resolución de su solicitud - 29 - secundaria, www.idealab.inc.new.net. La búsqueda de la dirección IP puede retrasarse mientras el proveedor por omisión usa el protocolo DNS y el servidor DNS del proveedor ISP para completar la solicitud secundaria. Una vez que todos los resultados descritos antes son recolectados por Winsock2 en el estado 248, el solicitante original, en este caso el navegador en la red, recibe los resultados en el estado 250 vía la interfaz de programación Winsock2 o una equivalente. A partir de la búsqueda original, Winsock2 recibe confirmación de que no existe una dirección IP correspondiente de la búsqueda del proveedor por omisión de www.idealab.inc en el estado 214. De la búsqueda secundaria, Winsock2 recibe una respuesta negativa de la búsqueda del proveedor NSP de New.net de www.idealab.inc.new.net en el estado 246 pero recibe la dirección o direcciones IP 238 de la búsqueda de www.idealab.inc.new.net del proveedor por omisión en el estado 240. El navegador en la red despliega entonces la página de la dirección de internet solicitada en el estado 252. De esta manera, el proceso 200 permite que direcciones no estándares sean convertidas en las direcciones IP correspondientes de recursos en la red, tales como computadoras, en el internet. Esto permite que un usuario vea páginas en la red u otro contenido (tal como datos FTP), como si la dirección no estandarizada fuera completamente estándar, es decir, compatible con un - 30 - estándar aprobado, tal como aquellos aprobados por ICANN. Otra modalidad de la presente invención prevé utilizar un proveedor (LSP) de servicio por niveles o capas suministrado por New.net, u otra compama de dominios TLD, para permitir la resolución de direcciones de internet que incluyen nombres de dominio de nivel superior que no usan el estándar ICANN. La solución del proveedor LSP se utiliza también para mensajes de correo electrónico que tengan direcciones de correo electrónico que incluyen nombres de dominio de nivel superior que no usan el estándar ICANN. La solución del proveedor LSP puede ser utilizada con clientes de correo electrónico, residentes u hospedados en sistemas de computadora cliente, y con sistemas de correo electrónico basados en la red, tal como Yahoo, Hotmail o similares. El proveedor LSP también se utiliza cuando se usa un servidor intermediario. Ventajosamente, el uso del proveedor LSP no necesita dos búsquedas separadas del proveedor del servicio, como fue descrito antes con respecto a la solución basada en el proveedor NSP, y por consiguiente es mas eficiente en tiempo. La interfaz Winsock2 permite la creación de proveedores LSP que pueden ser apilados en cadenas. El proveedor LSP es instalado en el nivel superior de un proveedor TSP por omisión del servicio de transporte (Transport Service Provider). Una función de un proveedor LSP es filtrar datos, por una variedad de razones, comunicados entre dos aplicaciones. El proveedor LSP puede ser - 31 - usado para filtrar, a manera de ejemplo, tráfico TCP y/o TJDP (User Datagram Protocol). El proveedor LSP puede ser entonces usado para comprobar o vigilar direcciones de internet que contienen dominios TLD que no usan el estándar ICANN de conformidad con una modalidad de la presente invención. En particular, el proveedor LSP puede ser usado para proporcionar el filtrado de tráfico a través de dispositivos de conexión (sockets). Vigilando el tráfico en dichos dispositivos de conexión, puede detectarse el uso de un protocolo de nivel de aplicación. El proveedor LSP detecta una dirección no estándar en el protocolo de nivel de aplicación HTTP o intermediaria, y modifica apropiadamente el localizador URL contenido en los encabezados apropiados en el protocolo. Así, una vez que se detecta una dirección de internet que no usa el estándar ICANN por medio del proveedor LSP, la modificación de la dirección por parte del proveedor LSP se lleva a cabo de conformidad. Cuando un usuario selecciona o ingresa una dirección de internet en un navegador de la red u otra aplicación, se envía la dirección de internet al servidor DNS para localizar una dirección de internet. Si la dirección de internet incluye un dominio TLD predefinido que no usa el estándar ICANN, entonces el proveedor LSP intercepta la dirección de internet y anexa una extensión que incluye un dominio TLD compatible con ICANN, tal como "new.net". En una modalidad de la presente invención, el proveedor LSP es actualizado - 32 - periódicamente entrando en contacto con un servidor anfitrión para actualizar una lista de las terminaciones no estándares reconocidas o definidas. En forma similar, si se utiliza un servidor intermediario, el proveedor LSP intercepta la dirección de internet si esta dirección incluye un dorninio TLD predefinido que no usa el estándar ICANN, como se describe antes. Un servidor intermediario es un servidor de Internet que generalmente actúa como un mediador entre el sistema de computadora cliente y otros servidores que alojan paginas en la red. El servidor intermediario puede, por ejemplo, ser miembro de un cortafuegos y proteger los sistemas cliente de acceso no autorizado vía el internet. Además, el servidor intermediario puede interceptar y bloquear selectivamente solicitudes de páginas en la red que vienen de usuarios dentro del cortafuegos. Un cortafuegos es un programa de cómputo o un equipo que filtra información que viene a través de internet, por ejemplo, sitios o portales ofensivos. El servidor intermediario puede también funcionar como un servidor de almacenaje o memoria. Utilizando las páginas en la red guardadas o memorizadas del servidor intermediario, este servidor desplegará páginas en la red previamente accedidas a usuarios sin requerir acceso de afuera hacia el internet, mejorando ventajosamente el desempeño de una red. Por supuesto, un servidor intermediario puede ser usado sin un cortafuegos. Debido a tales beneficios, muchos usuarios tienen acceso a internet por medio de un servidor - 33 - intermediario. Una modalidad del programa de cómputo para traducción de direcciones es, por consiguiente, compatible con usuarios quienes acceden al internet por medio de un servidor intermediario. Normalmente, usando una configuración intermediaria, cuando un usuario envía una solicitud para una dirección de internet, por ejemplo http://madonna.mp3, el navegador envía la serie "http://madonna.mp3/" directamente a la dirección IP del intermediario. El intermediario entonces desarrolla la búsqueda del servidor DNS para la solicitud, recupera el recurso solicitado y regresa los resultados al usuario. El problema potencial es que el servidor DNS del servidor intermediario puede no tener conocimiento de los nombres de dominio no estándares por tanto fallaría para resolver la solicitud para "madonna.mp3". Para superar esta dificultad, se usa un proveedor LSP proporcionado por New.net, u otra compañía de dominios TLD, para hacer posible la resolución de los nombres de dominio de nivel superior que no usan el estándar ICANN. La figura 6 ilustra un proceso 600 en donde se utiliza un proveedor LSP de dominios de nivel superior TLD para detectar y resolver una dirección de internet que contiene un dominio TLD que no usa el estándar ICANN, utilizando un servidor intermediario. En el estado 602 un usuario ingresa o selecciona una dirección de internet que no usa el estándar ICANN. En el estado 604, si el - 34 - proveedor LSP de dominios TLD esta disponible en el sistema de computadora cliente, entonces dicho proveedor LSP intercepta la dirección de internet que no usa el estándar ICANN. Si el dominio TLD que no usa el estándar ICANN esta enlistado dentro del proveedor LSP de dominios TLD entonces este proveedor agrega una extensión válida, tal como ".new.net", al final de la dirección de internet en el estado 606. En una modalidad, el proveedor LSP de dorninios TLD hace contacto periódicamente con un servidor anfitrión para actualizar la lista de dominios TLD que no usan el estándar ICANN. La dirección de internet modificada es entonces transmitida al servidor intermediario en el estado 608. A su vez, el servidor intermediario hace contacto con el servidor DNS en el estado 610. Debido a la adición de la extensión válida, la dirección IP correspondiente es localizada y devuelta al navegador en el estado 612. Una vez que el navegador recibe la dirección IP, en el estado 614 el navegador despliega o exhibe el localizador URL o la dirección de internet solicitada. Si el proveedor LSP de dominios TLD no esta disponible en el sistema de computadora cliente, entonces la dirección de internet que no usa el estándar ICANN se transmite al servidor intermediario en el estado 616. El servidor intermediario, a su vez, hace contacto con el servidor DNS en el estado 618. Puesto que no se modificó la dirección de internet, no se encuentra una dirección - 35 - IP válida y un mensaje de error es regresado al navegador en el estado 620. La figura 3 ilustra un ejemplo de proceso 300, en el que un programa de cómputo para traducción de correo electrónico, que utiliza un proveedor LSP, procesa el envío y recepción de mensajes de correo electrónico que tienen una dirección de correo electrónico con nombres de dominio TLD que no usan el estándar ICANN. En particular, el proceso 300 procesa una dirección de correo electrónico de un remitente la cual incluye un dominio TLD que no usa el estándar ICANN contenido dentro de la dirección de correo electrónico del remitente. El programa de cómputo para traducción de correo electrónico, que incluye, en una modalidad, un proveedor LSP de dominios TLD, es instalado en la computadora cliente de un usuario, en forma similar como se describe antes con respecto al programa de cómputo para traducción de direcciones. El proveedor LSP de dominios TLD, mientras vigila el tráfico de la conexión socket, determina que el usuario ha enviado un mensaje de correo electrónico con la dirección del usuario terminando en uno de los dominios TLD que no usan el estándar ICANN, tal como por ejemplo ioe@,ideaIab.ihc. El programa de cómputo para traducción de correo electrónico que incluye el proveedor LSP de dominios TLD, intercepta la dirección del mensaje de correo electrónico y le anexa una extensión, tal como ".new.net", que tiene un dominio TLD estándar al final de la dirección en el estado 304 creando así, en este ejemplo, - 36 - joe@ideaIab.inc.new.net. Un servidor SMTP de protocolo de transferencia de correo simple (Simple Mail Transfer Protocol) es contactado en el estado 306, el cuál a su vez entra en contacto con el servidor DNS del proveedor ISP del remitente en el estado 308. En el estado 310, el servidor DNS del proveedor ISP localiza un registro
(MX) de intercambio de correo para el nombre de dominio y una dirección IP. El registro MX especifica donde deberá ser entregado el correo electrónico para un nombre de dominio .Si la dirección de correo electrónico del receptor es válida, entonces se encuentra una dirección IP correspondiente. El correo electrónico es entonces transferido para entrega vía un servidor usado para almacenar correo electrónico para recuperación posterior por parte de una aplicación de correo electrónico cliente. Por ejemplo, un servidor POP de protocolo de correo que usa un protocolo POP3, un protocolo (IMAP) de acceso a mensajes en internet o uno similar, puede ser usado para entregar el mensaje de correo electrónico a la computadora cliente y a la aplicación de correo electrónico cliente del receptor en el estado 312. En el estado 314, si el programa de cómputo para traducción de correo electrónico esta disponible en el sistema de computadora cliente del receptor, entonces la dirección de correo electrónico del remitente es interceptada y la extensión, previamente anexada, del dominio TLD compatible con ICANN, ".new.net" en este ejemplo, es retirada por un proveedor LSP de - 37 - dominios TLD de la dirección de correo electrónico del remitente en el estado 316. De esta manera, se reproduce la dirección original, ioe@ideaIab.inc en este ejemplo. El proveedor LSP de dominios TLD puede ser configurado para solamente retirar dominios TLD que usan el estándar ICANN predeterminados o especificados, y no retirará otros dominios TLD. El receptor esta ahora habilitado para ver el correo electrónico con la dirección de correo electrónico del remitente libre o sin la extensión anexada previamente en el estado 318. Si el sistema de computadora cliente del receptor no tiene el programa de cómputo para traducción de correo electrónico, entonces el mensaje de correo electrónico llega a la computadora cliente del receptor en la misma manera como se indica antes. Sin embargo, en este ejemplo, el mensaje de correo electrónico no es interceptado en la parte receptora y por tanto el receptor ve el correo electrónico en el estado 320 con la dirección del remitente que tiene la extensión agregada anexa y aparecerá, en este ejemplo, como joe(¾idealab.inc.new.net. La figura 4 ilustra un proceso 400 de conformidad con una modalidad de la presente invención, en donde el remitente propone un correo electrónico a un receptor que tiene una dirección de correo electrónico que contiene un nombre de dominio TLD que no usa el estándar ICANN en el estado 402. Por ejemplo, un usuario que tiene una dirección de correo electrónico nombre@yahoo.con envía un correo electrónico a un segundo usuario que tiene una dirección de - 38 - correo electrónico ioe(¾idealab.inc. El servidor SMTP del remitente es contactado por el sistema de computadora cliente de correo electrónico anfitrión, el cual somete o propone la dirección del receptor y el mensaje de correo electrónico al servidor SMTP. Si el sistema de computadora cliente del remitente tiene el programa de cómputo para traducción de correo electrónico, en el estado 404, entonces el correo electrónico es interceptado por el proveedor LSP antes de que llegue al servidor SMTP. Una extensión que incluye un dominio TLD válido, tal como ".new.net", es entonces agregada al final de la dirección de correo electrónico del receptor en el estado 406 y enseguida enviada al servidor SMTP en el estado 408. A su vez, el servidor SMTP hace contacto con el servidor DNS del proveedor ISP solicitando un registro MX y una dirección IP correspondiente en el estado 410. Una vez que se encuentra la dirección IP, el correo electrónico del remitente es transmitido al servidor SMTP del receptor «n el estado 412, en donde el correo electrónico es entonces anexado al expediente de correo del receptor, donde puede ser más tarde accedido por el servidor POP3 del receptor en el estado 414 para entrega al cliente de correo electrónico del receptor. El servidor POP3 del receptor entrega el mensaje de correo electrónico al receptor con éxito en el estado 416. Opcionalmente, el dominio TLD agregado se retira de la dirección del receptor para propósitos de exhibición o despliegue. Si el programa de cómputo para traducción de correo electrónico no esta - 39 - disponible en el sistema de computadora cliente del remitente, el servidor SMTP del remitente es contactado, sin la intercepción del proveedor LSP de dominios TLD, y la dirección de correo electrónico del receptor, y el mensaje es sometido en el estado 418. El servidor SMTP del remitente hace contacto con el servidor DNS en el estado 420, solicitando una dirección IP correspondiente, asociada con el servidor SMTP del receptor, para la dirección de correo electrónico del receptor. En este momento, el servidor DNS regresa un mensaje de error "No Encontrado" en el estado 422, indicando que no hubo una dirección IP correspondiente para la dirección de correo electrónico que contiene el dominio TLD que no usa el estándar ICANN. El mensaje de error es entregado por el servidor SMTP a la dirección de regreso del correo electrónico, y el remitente recupera el mensaje de error vía el servidor POP/IMAP del remitente. La figura 5 ilustra un repaso de una arquitectura 500 de red que puede ser usada con una modalidad de la presente invención. Esta arquitectura incluye un servidor anfitrión 522, un sistema de computadora cliente 502, un proveedor 504 del servicio de internet y un servidor 506 del sistema de nombres de dominio. El sistema cliente 502 puede ser una computadora personal, un asistente digital personal, una televisión en red interactiva, un teléfono en red, u otra terminal con acceso a internet. El sistema de computadora cliente 502 contiene un sistema operativo 508, un navegador 510, un proveedor NSP del proveedor por omisión . . . . . . -. Ü t C . - 40 - dentro de Winsock2 512, un proveedor NSP 514 de dominios TLD, un cliente 516 de correo electrónico, que puede ser, a manera de ejemplo, Microsoft Outlook, Outlook Express, Eudora o Pegasus, y un proveedor 524 LSP de dominios TLD. Estos elementos toman parte en el proceso de resolución de dominios TLD no estándares y de adición de una extensión TLD válida. Por ejemplo, como se describe antes con referencia a las figuras 1 a 4 y 6, la extensión ".new.net" u otra extensión TLD estándar es anexada a una dirección de internet o de correo electrónico: En forma similar como se describe antes, se establece comunicación con el proveedor ISP 504 para peticiones o solicitudes iniciales de direcciones IP para direcciones de internet o direcciones de correo electrónico que usan dominios TLD no estandarizados con la ICANN. El proveedor ISP 504 entonces hace contacto con el servidor DNS 506 para desarrollar una búsqueda completa para las direcciones IP correspondientes. Para el envío y recepción de correos electrónicos, un sistema servidor de correo electrónico operado por el proveedor ISP 504, incluye un servidor SMTP 518 y un servidor POP3 520. El proveedor ISP 504, específicamente el servidor SMTP 518 dentro del servidor de corr-eo electrónico, se comunica también con el servidor DNS 506 para localizar una dirección IP correspondiente para la dirección de correo electrónico del receptor. En otra modalidad, como previamente se describe con respecto a la figura - 41 - 1, los dominios TLD que no usan el estándar ICANN son resueltos por -el proveedor ISP del usuario. Haciéndolo así, con estas ventajas, la utilización de un dominio TLD que no usa el estándar ICANN parece homogéneo o uniforme para el consumidor. El usuario primero ingresa la dirección de internet con el dominio TLD que no usa el estándar ICANN, en el navegador. El navegador enseguida somete una solicitud al servidor del sistema de nombres de dominio del proveedor ISP del sistema de internet para una dirección IP correspondiente. Puesto que el dominio TLD, que no usa el estándar ICANN, esta registrado con el proveedor ISP del usuario, el servidor del sistema de nombres de dominio puede encontrar una dirección IP correspondiente para la dirección de internet solicitada. Una vez encontrada, la dirección IP se transmite al navegador en la red. El navegador entonces utiliza la dirección IP para conectarse a la dirección de internet solicitada y exhibir o desplegar ésta. En forma similar, tal como los dominios TLD que no usan el estándar ICANN son traducibles vía el sistema del servidor DNS y de búsqueda del proveedor ISP, también lo son las direcciones de correo electrónico que contienen los nombres de dominio TLD que no usan el estándar ICANN. Una dificultad con este método es obtener la cooperación de los proveedores ISP para registrar los nombres de dominio TLD que no usan el estándar ICANN. De esta forma, como se describe antes, varias modalidades de la presente - 42 - invención proporcionan ventajosamente sistemas y métodos para interceptar y traducir direcciones de internet que contienen dominios TLD que no usan el estándar ICANN para validar direcciones de internet que usan -el estándar ICANN. Además, se proporcionan sistemas y métodos para traducir direcciones de internet que contienen dominios TLD que no usan el estándar ICANN utilizando un servidor intermediario. Asimismo, se proporcionan sistemas y métodos para traducir direcciones de correo electrónico que contienen doniinios TLD que no usan el estándar ICANN. Aunque esta invención ha sido descrita en ténninos de ciertas modalidades preferidas, otras modalidades que son evidentes para aquellos especialistas en la materia quedan también dentro del alcance de ésta invención. Por consiguiente, se pretende que el alcance de la presente invención quede definido únicamente mediante las reivindicaciones anexas.
- 43 -