System and method for service naming and related directory structure in a mobile data network

[0001] The present invention relates to systems and methods for accessing Internet-based information resources from a wireless mobile device. In particular, the invention concerns simplifying the manner in which a user is able to locate a desired information resource.

[0002] Mobile communication has become an important aspect of modern life. Mobile communication terminals (and related communication networks) have evolved from simple wireless telephony to now offering a multitude of services. In addition to wireless telephone service, many mobile communication terminals now offer access to the Internet and to other data communication networks.

[0003] FIG. 1 illustrates one existing method by which a mobile device accesses information resources via the Internet. Using browser software operating on a processor on mobile terminal 10, the user selects a desired information resource (“www.*news.com”). Fictitious resource names are used as illustrative examples throughout the Background and Detailed Description portion of this specification. These fictitious resource names (which include fictitious Internet domain names) will often include “*”, “#” and other characters not found in actual domain names under accepted Domain Naming System convention. Example resource names are also placed within quotation marks (e.g., “www.*website.com”).

[0004] Mobile terminal 10 communicates an information resource selection to the wireless network with which mobile terminal 10 is currently in communication (step 1). Although not shown, mobile terminal 10 transmits via wireless link to a base station, which then communicates via one or more wired or wireless network connections with a domain name server (DNS) maintained by the wireless network. The wireless network DNS receives the query from mobile terminal 10, and then forwards a query to a root server for the “.com” top level domain (TLD). In response, the “.com” root server returns to the wireless network DNS an Internet Protocol (IP) address of a name server for the “*news.com” domain (step 3). The wireless network DNS then forwards a domain name query via the Internet to the “*news.com” DNS (step 4). The DNS for “*news.com” then returns the IP address (183.124.54.153) for “www.*news.com” (step 5). The wireless network DNS returns the IP address for “www.*news.com” to mobile terminal 10 (step 6). Software within mobile terminal 10 then initiates a connection to the IP address for “www.*news.com” (step 7). In practice, a DNS query may be handled by a proxy instead of the mobile terminal. In other words, after the mobile terminal user selects the desired Internet information resource, the selection is communicated to a proxy within the wireless network. The proxy then communicates with the wireless network DNS and establishes the connection to the desired Internet information resource. The previous example also represents a recursive case wherein the wireless network DNS requests additional information from other DNS servers. In some systems, the wireless network DNS instructs the mobile terminal (or proxy) to directly request additional information from the “.com” root server.

[0005] Because of limited memory, many mobile terminals can only retain a limited number of URLs (such as “www.*news.com” from the preceding example), bookmarks, or other stored references to desired Internet information resources. When it is necessary to identify other resources, the user must typically browse through links from available on-line resources or find such resources using a search engine. For various reasons, browsing from a mobile terminal over a wireless network can be more difficult than when using a personal computer (PC) or other computer with more capabilities.

[0006] For example, mobile communication terminals often have smaller processing and data storage capacities by comparison to laptop, personal and other computers used for wired access to the Internet. Browser software operated on mobile terminals may have fewer features and capabilities than browser software operated on a laptop computer or PC. Many mobile terminals also have smaller display devices than are typically found on other types of computers. This often prevents a user from viewing more than a small number of selectable hyperlinks at any one time. Although it may be possible to scroll through selections, many users find it difficult to keep track of the available selections in screens that are not currently displayed. Consequently, it is often desirable in the wireless access context to use shorter service indices (e.g., shorter lists of available links) and fewer layers of such indices. This can present a challenge.

[0007] Other challenges of wireless Internet access can arise when services are provided via a wireless access protocol (WAP) portal maintained by a wireless network operator. Different operators do not always configure their portals in the same manner. A roaming user accessing an unfamiliar portal may be unaccustomed to that portal, and thus less likely to find the desired information resources. Indeed, finding the visited operator portal can be a challenge in itself.

[0008] Network access charges for wireless browsing are often more expensive that browsing from a PC or other computer having wired network access. Wireless communication networks typically offer a more restricted data transmission rate than is available for wired Internet access. Searching and browsing is therefore often slower than when using a wired connection. After entering a search term or selecting a hyperlink, a wireless network user may have to wait a relatively long time for additional selectable links to be downloaded.

[0009] These various challenges can be aggravated by the nature of mobile terminal use. In particular, mobile terminals are typically used in environments where convenience, ease of use and speed are major concerns. Often, a mobile terminal user is in transit or otherwise in a situation in which the mobile terminal may be the only information resource available. Users are often in a hurry and/or using a mobile terminal while standing or while located in a distracting environment (e.g., in an airport, etc.). Providing substantial amounts of user input before obtaining a desired information item or waiting for a response can be problematic under these conditions. Although some mobile terminals have an expanded keyboard or otherwise provide the capacity for entering specific text or other characters, input of text with a mobile terminal is often more time consuming that when using a larger keyboard.

[0010] As the foregoing illustrates, there remains a need for improved methods and systems for finding and selecting information resources when using a mobile communication terminal.

[0011] The present invention addresses many of the previously described challenges through the use of service names that are recognized as generic by multiple wireless networks. In response to a request by a mobile terminal for an information resource named under such a generic service name, one wireless network may provide an IP address for a first provider of information. Another wireless network, in response to the same generic service name, may provide an IP address for a different information provider. Other wireless networks will provide addresses for still other providers. Upper level generic service names may also include one or more hierarchically arranged lower levels of generic service names. This tree of generic service names may further be used to create, in a consistent manner in different wireless networks, a generic directory of accessible information resources. In certain embodiments, a mobile terminal determines its location and provides location information as part of (or in connection with submission of) a generic service name.

[0012] In a first embodiment, the invention includes a method for accessing Internet information resources via a wireless mobile terminal. A first generic service name is submitted to a first wireless network. In response to that submission, a mobile terminal accesses a first Internet information resource mapped to the first generic service name by the first wireless network. The mobile terminal submits a second generic service name to the first wireless network and then accesses a second Internet information resource mapped to the second generic service name by the first wireless network. The mobile terminal later submits one of the first or second generic service names to a second wireless network and accesses, in response to said submission to the second wireless network, a third Internet information resource. The third resource is mapped to the first or second generic service name by the second wireless network, and is distinct from the information resource mapped to the first or second generic service name by the first wireless network. In a second embodiment, the invention includes a mobile communication terminal having a communications interface, an input device, a processor and a memory. Stored on the memory are machine-executable instructions which, when executed by the processor, cause the mobile terminal to perform steps similar to the steps of the first embodiment. In a third embodiment, the invention includes a machine-readable medium having machine-executable instructions for performing steps similar to the steps of the first embodiment.

[0013] Additional embodiments, as well as other features and advantages of the present invention, will be apparent and understood from the following detailed description of preferred embodiments, taken in connection with the appended drawings.

[0030] As used herein, “mobile terminal” includes cellular and other wireless telephones, mobile devices communicating by General Packet Radio Service to send and receive data, devices permitting wireless Internet telephony, and any other mobile communication device that facilitates wireless two-way communication between a user of the device and another location (including, e.g., a cellular telephone coupled to a personal digital assistant or to a laptop or other portable computer). “Mobile terminal also includes terminals which can be connected to a network in different locations, but are not capable of supporting all functions of mobility.

[0031] FIG. 2 is a functional diagram of a mobile terminal 20 according to at least one embodiment of the invention. Mobile terminal 20 generally includes at least one communications interface 22, inputs (e.g., keypad 26 and audio/visual inputs 24), display 28, memory 30 and processor 32. Communications interface 22 includes components needed to transmit and receive information (whether voice, data or other information) via a wireless network. Audio/visual inputs 24 may include, e.g., a microphone and/or a camera. A user of the mobile terminal 20 provides input via keypad 26 to access features of mobile terminal 20. Operation of mobile terminal 20 is controlled by a processor 32, which receives instructions and data from, and stores data to, memory 30. One type of program operating upon mobile terminal 20 includes a browser 34, features of which are described below. Mobile terminal 20 is only one example of a possible mobile or portable terminal in accordance with the invention.

[0032] The present invention addresses many of the previously described challenges associated with accessing Internet information resources via a mobile terminal. Often, a user of a mobile terminal may not be concerned with accessing a specific provider of a type of information, so long as the information is quickly and conveniently obtained. For example, a user of mobile terminal 20 may be in a meeting or some other location and have a need to view the current news headlines or other information about major events. Often, the same general content (e.g., major news events of the day, stock market indices, etc.) is available from a variety of on-line sources, and a user is indifferent to the actual provider accessed. Instead, the user is more concerned with quickly finding a source of the desired information and then quickly accessing that information.

[0033] In at least one embodiment of the invention, a mobile terminal such as mobile terminal 20 utilizes generic service names to access various types of information. In at least one embodiment, a generic service name has the general format of an Internet domain name or of some other type of Uniform Resource Locator (URL) or Uniform Resource Identifier (URI). However, these generic service names are reserved for use by one or more wireless networks as described herein. In response to a request by mobile terminal 20 for an information resource associated with such a generic service name, one wireless network will provide an IP address for a first provider of information. Another wireless network, in response to the request seeking information with the same generic service name, will provide an IP address for a different information provider. Other wireless networks may provide addresses for still other providers.

[0034] In at least one embodiment, by previous agreement among multiple wireless network operators, certain domain names are reserved for use as (or in connection with) generic service names. As used herein, “domain name” (sometimes called a “DNS name”) refers to a name that is resolvable into an IP address for an Internet information resource. Each wireless network operator determines an actual domain name and (and thus IP address) to which one or more generic service names is mapped. As used herein, “actual domain name” refers to a domain name not set aside for use as a generic service name. The reserved domain names can be assigned one or more specific top level domains (TLDs) and/or assigned into sub-domains of one or more TLDs. Notably, the invention is not limited to geographic distinctions between wireless network operators. In some embodiments, two wireless networks operating within the same region and providing separate DNS services map the same group of generic service names to different actual domain names (and thus to different IP addresses).

[0035] FIG. 3 also shows mobile terminal 20, but shows some of the data stored in memory 30. As seen in FIG. 3, stored in memory 30 are multiple generic service names 36. For purposes of the example, generic service names are shown as having the top level domain “.mobi”, although other top level domains could be used. Generic service names 36 could have been stored in memory 30 in various manners. In certain embodiments, generic service names are allocated a short time-to-live (TTL) parameter within the DNS of a wireless network, thereby limiting the time these names are cached in a mobile terminal. In that embodiment, the generic service names are briefly stored after retrieval from a wireless network (so that, e.g., a user may select from among the retrieved names), but must be frequently re-requested from the wireless network. In other embodiments, one or more generic service names are cached for a longer period of time, and other generic service names are retrieved as needed. In these other embodiments, a TTL parameter for groups of names is defined based on a meaningful time any set of names is assumed be valid after retrieval. Longest TTL parameters may be used for service names having a global scope.

[0036] Each generic service name 36 corresponds to a generic category of information. For example, “news.mobi” corresponds to sources of information about news and current events. The generic service name “weather.mobi” corresponds to sources of information about weather conditions (not necessarily in the region in which mobile terminal 20 is currently located). The generic domain name “localinfo.mobi” corresponds to information about local attractions, restaurants, etc. The generic service name “games.mobi” corresponds to on-line games, puzzles, etc. These examples are only illustrations, and numerous other types of generic service names are possible.

[0037] FIG. 4 shows how the same generic service name is treated differently by two different wireless networks. A user of mobile terminal 20a is in communication with wireless network 40 operated by Operator A. A user of mobile terminal 20a selects “www.*localnews.mobi” on mobile terminal 20a. The user may select “www.*localnews.mobi” in various ways. As shown in FIG. 3, a user could be presented with a list of information categories. The user would then highlight the desired category and press a key corresponding to “Go” (or some other key signaling the selection). In other embodiments, a user could input “www.*localnews.mobi” or other generic service name into a text window. In at least one embodiment, generic service names are intuitively based on the type of information retrievable from the service provider selected by a wireless network operator.

[0038] After selecting “www.*localnews.mobi”, mobile terminal 20a transmits that generic service name in a query to DNS 42. The query is sent as a Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) packet over the IP network and includes a query type (QTYPE) code requesting translation of a name to an IP address. The query further includes the host name (“www.*localnews.mobi”) to be resolved. DNS 42 of wireless network 40 receives this transmission via a base station, intermediate switching center(s) and other facilities known in the art (not shown). Because the transmitted service name (“www.*localnews.mobi”) is one of a number of domain names previously set aside for use as a generic service name, a trigger within software operating on DNS 42 recognizes the generic service name, and consults a lookup table for generic service names. In this case, Operator A has previously determined that “www.*localnews.mobi” will be mapped to an IP address of an Internet web server operated by Provider X and having a host name “www.*news.com”. Accordingly, DNS 42 returns to mobile terminal 20a the IP address for “www.*news.com”. Using the IP address transmitted by DNS 42, mobile terminal 20a then connects with the web server operated by Provider X. In at least one preferred embodiment, connection to an Internet information resource is automatic upon selection of a generic service name. In other words, and using the present example, the user of mobile terminal 20a is not required to provide further input after selecting “www.*localnews.mobi”. In certain embodiments, mobile device 20a communicates with DNS 42 and with the Provider X web server via a proxy.

[0039] Mobile terminal 20b, which is similar to mobile terminal 20a but owned by another user, is in communication with wireless network 60 operated by Operator B. The user of mobile terminal 20b also selects “www.*localnews.mobi”. Wireless network 60 may be within the same geographic region as that served by wireless network 40, may be in a different region, or may be in a region partially overlapping that of wireless network 40. DNS 62 of wireless network 60 receives this transmission (also via a base station, intermediate switching center(s) and other facilities known in the art), and also recognizes a generic service name. In this case, Operator B has previously determined that “www.*localnews.mobi” will be mapped to an IP address for an Internet web server operated by Provider Y and having a host name of “www.#news.com”. Accordingly, DNS 62 returns to mobile terminal 20b the IP address for “www.#news.com”. Using the IP address transmitted by DNS 62, mobile terminal 20b then connects with the web server operated by Provider Y. As with mobile device 20a, and although not shown in FIG. 4, mobile device 20b could alternatively communicate with DNS 62 and with the Provider Y web server via a proxy.

[0040] Only two wireless networks and two mobile terminals are shown in FIG. 4 so as not to obscure the example with unnecessary detail. However, it is understood that additional mobile terminals would be operating within these two networks. The mobile terminals could be subscribers of network 40 or network 60, or merely roaming within one of these networks. Similarly, other wireless networks could be shown; these other networks could operate in the same geographic region as network 40 or network 60, could operate in regions that partially overlap the regions of network 40 and network 60, or could operate in different regions. Although each operator is free to determine which actual domain name (and thus which IP address) is mapped to a generic service name, multiple operators are not prevented from mapping the same generic service name to the same actual domain name.

[0041] Notably, recognition of generic service names by DNS 42 and DNS 62 does not prevent mobile terminals 20a and 20b from accessing other sources of news (or other) information available on the Internet. As previously indicated, “www.*localnews.mobi” is treated by wireless network 40 and wireless network 60 as a generic service name, and thus mapped to a provider of each operator's choosing. However, other conventional domain names and/or other URIs are routed in a conventional manner. For example, a user of mobile terminal 20a may have previously determined that he or she prefers the information provided by Provider Y, and could specifically transmit the URL “www.#news.com”. Upon receiving this request, Operator A DNS 42 could provide the IP address for “www.#news.com” (if that IP address was already cached by DNS 42), could obtain the IP address as set forth in FIG. 1, or could instruct mobile terminal 20a (or a proxy) to request the IP address directly from a DNS of domain “#news.com”. The user of mobile terminal 20a might instead prefer the news provided by some other company not used by Operator A or Operator B (e.g., “www.!news.com”), and specifically submit that URL to DNS 42.

[0042] In at least one embodiment, Operator A and Operator B, as well as operators of other wireless networks, share a generic service name such as “operator.mobi”. In other embodiments, specific generic service names point to the home operator portal and to a visited operator portal. For example, “home.operator.mobi” (or “homeoperator.mobi”) points to a home operator portal and “local.operator.mobi” (or “localoperator.mobi”) points to a visited operator's portal. Variations (e.g., “myoperator.mobi” and “thisoperator.mobi”) could also be used. The generic service name “localservices.homeoperator.mobi” could point to localized services offered by the home operator and the generic service name “localservices.localoperator.mobi” could point to localized services offered by the visited operator. In other embodiments, a generic service name such as “operator.mobi” is used as a basis for generic service names such as “localnews.operator.mobi”, “weather.operator.mobi”, etc.

[0043] In at least some embodiments, upper level generic service names include one or more hierarchically arranged lower levels of generic service names. This tree of generic service names is further used to create a generic directory of information resources that can be accessed in a consistent manner in different wireless networks. In one embodiment, for example, the upper level generic service name “news.mobi” contains sub-levels of generic service services names “world.news.mobi”, “money.news.mobi”, “sports.news.mobi”, etc. Under the generic service name “world.news.mobi” are additional sub-levels of generic service names for “usa.world.news.mobi”, “europe.world.news.mobi” and “asia.world.news.mobi”. Each of these sub-levels (as well as other upper level generic service names and their sub-levels) could have additional levels of generic service names. Each generic service name at every level is mapped to a default Internet resource. In at least one embodiment, each wireless network is free to override a default and re-map generic service names at one or more levels to non-default resources. If a user selects a generic service name for which a particular wireless network has not mapped a non-default resource, the generic service name is resolved in a conventional manner (e.g., as in FIG. 1) so as to allow access to the default resource. Although the entire tree for generic service names can be extensive, a mobile terminal is not required to store the entire tree. Instead, and as described below, the mobile terminal retrieves sub-levels of generic service names as they are needed. In one embodiment, a user may edit the offered selection of generic service names within a specific layer by adding or deleting generic service names.

[0044] In some embodiments, one or more sub-levels of generic service names can also be defined in a <domain name>/<file name> format. For example, instead of having a service name “boston_ma.us.%worldnews.mobi” a format of %worldnews.mobi/us/boston_ma could be used.

[0045] Returning to FIG. 3, a user is provided the opportunity, via display 28, to select a category corresponding to an upper level generic service name. In one embodiment, mobile terminal 20 retrieves a list of upper level generic service names (using a DNS “1s” list query) upon activation or otherwise commencing communication with a wireless network. These upper level names are then cached and built into a temporary service index within a terminal. A corresponding file structure can also be implemented in network-based servers if a hierarchical name structure is used for a related set of services. Upon selecting a generic service name (by, e.g., selecting a corresponding category on the display), browser software 34 of mobile terminal 20 transmits another “1s” list query to DNS 42 of wireless network 40. In response, DNS 42 returns service name sub-levels as a list of sub-domains registered for a selected upper level domain. In this case, and as shown in FIG. 5, the upper level generic service name (“news.mobi”) comprises the sub-levels “money.news.mobi”, “sports.news.mobi” and “world.news.mobi”. Mobile terminal 20 then provides the user, via display 28, with the opportunity to select a category corresponding to one of these generic service name sub-levels. The procedure can be iterated to reach sub-levels of other upper level generic service names or further sub-levels of a selected sub-level. For example, upon selecting “world news” on display 28, mobile terminal 20 transmits a list query for “world.news.mobi”. In response, DNS 42 returns a list of lower level generic service names: “usa.world.news.mobi”, “europe.world.news.mobi” and “asia.world.news.mobi”. In response to receiving these sub-level names, and as shown in FIG. 6, browser 34 displays subcategories “USA,” “Europe” and “Asia” on display 28 of mobile terminal 20. There may be additional sub-levels for some, all or none of these categories. In the example, USA (“usa.world.news.mobi”) and Asia (“asia.world.news.mobi”) have no lower sub-levels, and “Europe” (“europe.world.news.mobi”) has sub-levels for individual countries (e.g., “finland.europe.world.news.mobi”, “spain.europe.world.news.mobi”, etc.). Upon selecting “Europe,” these additional sub-levels would be retrieved and corresponding categories (e.g., “Finland,” “Spain,” etc.) displayed.

[0046] In at least one embodiment, mobile terminal 20 includes at least two separate functions for selecting a generic service name (or a category corresponding thereto). As seen in FIGS. 5 and 6, one command (“Discover”) instructs mobile terminal 20 expand the category into the next lower level of categories. Another command (“Go”) instructs mobile terminal 20 to browse the highlighted category by accessing the corresponding Internet information resource.

[0047] In at least one embodiment, certain generic service names (at both upper and lower levels) are mapped to Internet information resources and have further sub-levels. FIGS. 7 and 8 illustrate this aspect. Upon selecting “sports” (sports.news.mobi) in display 28 with a “Discover” command (FIG. 5), mobile terminal 20 queries DNS 42 for a list of any available sub-levels, as previously described. In response, and as shown in FIG. 7, DNS 42 provides an additional level of generic service name sub-levels: “baseball.sports.news.mobi”, “basketball.sports.news.mobi” and “football.sports.news.mobi”: Mobile terminal 20 then provides the user with the opportunity to select “sports,” “baseball,” “basketball” or “football.” Upon selecting “sports” with the “Go” command, mobile terminal 20 does not resubmit a list query, and instead transmits the generic service name “www.sports.news.mobi” to DNS 42 in order to obtain an IP address of an Internet resource. In response, and as shown in FIG. 8, mobile terminal 20 is automatically connected to an Internet information resource.

[0048] In other embodiments, separate “Go” and “Discover” commands are not provided. Instead, browser 34 assumes a second selection of “sports” represents the user's desire to access the corresponding Internet resource. This could be implemented in various manners. In one embodiment, the browser software operating on mobile terminal 20 stores the time at which it transmitted the last query for sub-levels of “sports.news.mobi” and does not transmit another such query until a preset time expires.

[0049] In some preferred embodiments of the invention, and as shown in FIGS. 3, 5, 6, 7, 10, 10A and 11, generic service names are invisible to the mobile terminal user. Instead, an application operating upon the mobile terminal (and using the naming structure described) displays an information category name or other descriptive material regarding information resource(s) accessible via corresponding (and hidden) generic service name(s). In some embodiments, the displayed material can be (or include) an icon or other graphic.

[0050] In still other embodiments, generic service name sub-levels are provided to a mobile terminal in other manners. In one such embodiment, a list of sub-levels is stored in a Naming Authority Pointer (NAPTR) record. For each domain, the domain naming system database allows storage of extra information in specific records such as the NAPTR record. The relevant sub-domains for each domain are stored in these records. In this manner, and instead of performing a list search, a mobile terminal or other client can retrieve all sub-levels by retrieving the NAPTR record in which the list of sub-levels is contained. The mobile terminal could then periodically update the retrieved NAPTR records with a new query, potentially reducing the load on the wireless link and the mobile terminal. A standard WAP or WEB directory can then be automatically generated based on the DNS service tree stored in the NAPTR record for a generic service name. In other embodiments, other standard domain naming system commands (such as are used for, e.g., iterative zone transfer) could be used to retrieve all levels of generic service names at once.

[0051] In at least one embodiment, and as shown in FIG. 9, the highest levels of the generic service name structure are updated automatically by a wireless network with which a mobile device is in communication. Upon initial activation within (or roaming into) a wireless network, the highest level menu structure is downloaded into the mobile terminal. In some variations of this embodiment, the user can configure the terminal to allow or not allow such automatic download. The highest level generic service name structure is then periodically, or on user request, updated by the wireless network and cached by the mobile terminal. In at least one embodiment, this update occurs during periods in which a data connection between a mobile terminal and the network is idle. The update system could further be optimized such that no updating occurs when network transmission traffic is at a predetermined percentage of maximum capacity. Lower level generic service names under an upper level recently visited by the user can be updated (automatically or on user request) in a similar manner.

[0052] In another embodiment, other existing features of the domain naming system structure facilitate services in multiple languages. In this embodiment, a mobile terminal presents information to a user in the user's preferred language. The preferred language is stored as a browser setting on the user's mobile terminal. If links to services in the preferred language are not available, related services in another language are offered. So as to facilitate management of service listings for multiple languages, each category (each generic service name level and/or sub-level belonging to a special class) is assigned a language field using standard DNS extensions. In one embodiment, language data for a generic service name is included in a NAPTR or text (TXT) record for a domain name set aside for use as a generic service name. Each generic service name is also given a name in an appropriate language. For example, and as shown in FIG. 10, the upper level service name “localinfo.mobi” includes the lower level generic service name “resto.localinfo.mobi” for accessing a French language information resource, “restaurante.localinfo.mobi” for accessing a Spanish language information resource, “ristorante.localinfo.mobi” for accessing an Italian language information resource, “restaurant.localinfo.mobi” for accessing an English language resource, etc. As shown schematically in FIG. 10, the NAPTR record for the “localinfo.mobi” domain, which contains these sub-levels, includes language identifiers. When a user having an English language preference expands the generic service name “localinfo.mobi”, the user's mobile terminal requests only generic service names having an English language identifier. In response, the DNS provides “restaurant.localinfo.mobi”, but not “restaurante.localinfo.mobi”, “resto.localinfo.mobi” or “ristorante.localinfo.mobi”. In other embodiments, all lower level generic service names are returned to the mobile terminal, but only the name corresponding to the preferred language is displayed. If no generic service names corresponding to the preferred language are available, all are returned and displayed.

[0053] For simplicity, FIG. 10 only shows one component of each generic service name sub-level in the language associated with that sub-level. In other embodiments, the generic service name tree is further organized by language at multiple levels (such that, e.g., “localinfo” would also be in an associated language). In some embodiments, language indication is in <domain name>/<file name> format, e.g. “localinfo.mobi/resto”. If this type of naming is used, however, an Is query may not be available to update the service listings.

[0054] In another embodiment shown in FIG. 10A, and instead of listing sub-domains with language attributes within a domain NAPTR record, a separate NAPTR record is attached to individual generic service names. FIG. 10A schematically shows an example of this embodiment for the generic service name “restaurant.localservices.mobi”. The NAPTR record for “restaurant.localservices.mobi” shows equivalent services available in other languages: <restaurant information in French>, <restaurant information in Spanish>, <restaurant information in Italian> and <restaurant information in German>. As used in FIG. 10A, “<restaurant information in _>” represents a resource in the identified language. That resource may be another generic service name or may be an actual domain name. When a user expands “restaurant.localservices.mobi” (by, e.g., selecting “Discover” in display 28 while “Restaurants” is displayed), the terminal retrieves the resource names for the service in alternative languages. These alternate language services (or corresponding titles, icons, etc. supplied by the browser or other application) are displayed to the user. In some versions of this embodiment, the equivalent service names in the NAPTR record for “restaurant.localservices.mobi” also contain separate language identifiers (which may be a specific portion of the service names). The language identifier is then be compared against a preferred language setting in mobile terminal 20 so that only resource names for services in a desired language are retrieved and/or displayed.

[0055] FIG. 11 illustrates another embodiment of the invention. In this embodiment, mobile terminal 20c determines its location and automatically completes a portion of a generic service name. As shown in FIG. 11, the user first selects “localmaps.mobi”, a generic service name for an information resource having maps of an area in which mobile terminal 20c is currently located. Similar generic service names could include “localattractions.mobi” for local tourist information, “localmedical.mobi” for local medical services, etc. Mobile terminal 20c then determines its location. In at least one embodiment, mobile terminal 20c is in communication with a Global Positioning System (GPS) satellite receiver 72, and is able to determine its longitude and latitude base on GPS signals. In one embodiment, mobile terminal 20c includes an integral GPS receiver.

[0056] After determining its longitude and latitude, mobile terminal 20c queries an external location service 74 to map those GPS coordinates to a location name (e.g., country, city, etc.). In one embodiment, external location service 74 is accessed via the wireless network with which the mobile terminal is communicating, but not operated by that wireless network. After receiving a response from the external location mapping service, mobile terminal 20c rewrites “localmaps.mobi” to “<location> maps.mobi”, where <location> represents the location information returned by the external mapping service. The rewritten generic service name is then transmitted to the wireless network. As previously indicated, different wireless network operators may provide different actual domain names for different resources in response to receiving this generic service name.

[0057] In another embodiment, some portions of the localization of a mobile terminal are performed by an extended DNS operated by the wireless operator. As shown in FIG. 12, mobile terminal 20d transmits, in addition to the generic service name “localmaps.mobi”, position information obtained from a GPS module. In response, extended DNS 43 queries a coordinate mapping system 44 to determine the country, city and/or other regional location of mobile terminal 20d. Extended DNS 43 could be implemented as an extension to server software for DNS 43, or as a separate component to process the localization information before querying DNS 43. Mapping system 44 may be a separate software application operating upon extended DNS 43 or upon another computer in communication with extended DNS 43. Coordinate mapping system 44 returns the location information for the submitted location data (e.g., New York City, USA) to extended DNS 43. Extended DNS 43 then consults a lookup table and returns a service provider name, e.g., “ny.***maps.com” (which is converted to an IP address) or an IP address for a service provider. Another operator may choose to map “localmaps.mobi” to a different resource (e.g., “new-york.mobilemaps.!!!maps.com”).

[0058] In another embodiment shown in FIG. 13, mobile terminal 20e transmits the generic service name “localmaps.mobi”. If the position co-ordinates are not included in the request, extended DNS 45 queries mobile terminal 20e for position information. In response, mobile terminal 20e provides position information obtained from a GPS receiver. Extended DNS 45 then queries a coordinate mapping system 46 to determine the country, city and/or other regional location of mobile terminal 20e corresponding to the GPS information provided by mobile terminal 20e. As before, mapping system 46 may be a separate software application operating upon extended DNS 45 or upon another computer in communication with extended DNS 45. Coordinate mapping system 46 returns the location information for the submitted location data to extended DNS 45. Extended DNS 45 then consults a lookup table and returns an IP address for an Internet resource having the desired information.

[0059] In additional embodiments, a mobile terminal stores Cell ID and/or Area ID data corresponding to the cell with which the terminal last communicated, as well as a pre-defined set of Internet domain names. These names are reserved for localized services. Examples include “news.localinfo#.tld”, “games.localinfo#.com”, “service.something#.xyz”. To illustrate these additional embodiments, these names are represented generically as “<localized name>”. When the terminal requests information corresponding to one of these localized names, the Cell ID and/or Area ID are appended to the request: “<Cell ID><Area ID><localized name>” or “<Area ID><localized name>”. Using, e.g., a local DNS or a local Web proxy, specific resources can be targeted to terminals requesting the same name from different locations, but to a higher degree of location granularity. When a user activates the mobile terminal, the terminal determines if the Cell ID or Area ID has changed since the last time the terminal was used. If changed, the terminal automatically checks to determine if new values for <localized name> are available for the new Cell ID/Area ID, and if so, downloads those new names. Checking for and downloading of new names could also be triggered by receipt of a new Cell ID or Area ID when the terminal moves to a new location while in use. Alternatively, and depending upon individual terminal configuration and/or capabilities, the names are only updated on request from the user.

[0060] FIG. 14 illustrates one of these additional embodiments, implemented using a localized DNS 142, receiving a request from a mobile terminal 20′. In this embodiment, DNS 142 has an entry for different Cell IDs and/or Area IDs. Localized DNS 142 is specific to a particular wireless network operator; other operators maintain separate localized DNSs. As shown in FIG. 14, entries in lookup table 151 are in the form “<CellID><AreaID><localized name>”, “<AreaID><localized name>” or simply “<localized name>”. “CNAME” in lookup table 151 is, e.g. a canonical name for an Internet information resource. If a particular localized service reserved name (<localized name_a>) is directed an Internet resource based on Cell ID of the incoming request, there will be separate entries in lookup table 151 for different Cell IDs (Cell ID₁, Cell ID₂, etc.). If a particular localized name (<localized name_b>) is not directed to separate Internet resources based on Cell ID but is directed based on Area ID, there will be separate entries in lookup table 151 based on Area ID (e.g., Area ID₂). If a particular localized name (<localized name_c>) is not directed to separate Internet resources based on Cell ID or Area ID, there may be a single entry in lookup table 151 simply for that localized name.

[0061] Localized DNS 142 can be implemented using a DNS proxy service front end configuration (not separately shown) or using a dedicated application (also not separately shown) as a front end for the mobile terminal clients. Upon receipt of a name request from a terminal, the front end checks the most significant part of the name request (<localized name>) to determine if this localized name is one having an entry in of localized DNS 142; if so, the front end routes the request to localized DNS 142. In alternate configurations, the front-end checks the least significant part of the name request from the mobile terminal (<Cell ID> and/or <Area ID>), recognizes name request as a localized request based on the presence of <Cell ID>and/or <Area ID>, and routes the name request to localized DNS 142. If there is no match for <localized name>, <Cell ID>or <Area ID>, the request is handled as a conventional name request (e.g., as in FIG. 1).

[0062] A request from a mobile terminal for <CellID><AreaID><localized name> will therefore return a resource corresponding to the smallest degree of granularity for which the wireless network operator assigns resources to a localized service request. The returned value from local DNS 142 to the mobile terminal will be a pointer to a resource assigned to the localized name requested by the terminal. This could be either a website pointer, and IP address, a URL or other resource identifier.

[0063] FIG. 15 illustrates another of these additional embodiments implemented using a localized web server 162. Localized web server 162 is a conventional web server modified as described below, and receives name requests directed to <localized name>. Upon receipt of a <Cell ID><Area ID><localized name> request, web server 162 rewrites the received request to a specific resource using lookup table 171. Similar to localized DNS server 142, entries in lookup table 171 are in the form <CellID><AreaID><localized name>. If a particular localized service reserved name (<localized name_a>) is directed to an Internet resource based on Cell ID of the incoming request, there will be separate entries in lookup table 171 based on Cell ID (Cell ID₁, Cell ID₂, etc.), and received requests will be rewritten to the corresponding URL. If a particular localized name (<localized name_b>) is not directed to separate Internet resources based on Cell ID but is directed based on Area ID, there will be separate entries in lookup table 171 based on Area ID (e.g., Area ID₂). If a particular localized name (<localized name_c>) is not directed to separate Internet resources based on Cell ID or Area ID, there may be a single entry in lookup table 171 simply for that localized name.

[0064] Localized web server 162 can be implemented using a web server front end configuration (not separately shown) or using a dedicated application (also not separately shown) as a front end for mobile terminal clients. Upon receipt of a name request from a terminal, the front end checks the most significant part of the name request (<localized name>) to determine if this localized name is one having an entry in localized web server 162; if so, the front end routes the request to localized web server 162. In alternate configurations, the front end checks the least significant part of the name request from the mobile terminal (<Cell ID>and/or <Area ID>), recognizes name request as a localized request based on the presence of <Cell ID> and/or <Area ID>, and routes the name request to localized web server 162. If there is no match for <localized name>, <Cell ID>or <Area ID>, the request is handled as a conventional name request and, e.g., routed to separate server or to a separate partition of localized web server 162.

[0065] In alternate versions of the embodiments of FIGS. 14 and 15, language preferences could also be included in a name request. For example, language preferences stored by a mobile terminal could also be appended to the name request: “<Cell ID><Area ID><language ID><localized name>”. The “<language ID>” component could identify more than one language. In these alternate versions of the embodiments of FIGS. 14 and 15, look up table 151 or 171 further assigns requests for Internet information resources based on the language ID. For example, “<Cell ID₁><Area ID₁><language ID₁><localized name>” would be assigned a first CNAME, while “<Cell ID₁><Area ID₁><language ID₂><localized name>” would be assigned another CNAME.

[0066] A DNS according to the above additional embodiments can be implemented with standard BIND (Berkeley Internet Name Daemon) software and require only the correct configuration for the selected implementation. The DNS Resource Record could also be used.

[0067] A mobile terminal 20′ according to the above additional embodiments includes a dedicated DNS Resolver and/or client application which tracks current Cell ID and Area ID, language preferences, etc., and incorporates this data into a DNS request to be resolved by the localized DNS or the localized content server. The localized content server is based on Web or other Internet resources for which the wireless network operator is a local provider and/or for which the operator provides Internet addresses (or other links).

[0068] Although specific examples of carrying out the invention have been described, those skilled in the art will appreciate that there are numerous variations and permutations of the above-described systems and methods that are contained within the spirit and scope of the invention as set forth in the appended claims. For example, the user interfaces and screen layouts described are only examples; other user interfaces and screen layouts are within the scope of the invention. The generic service names and information categories used to describe the invention are only examples; other service names and information categories could also be used. Similarly, the tree structure used to describe the invention is only an example. Other structures are also within the scope of the invention. As but one example, “restaurant.sicily.italy.mobi” (location based directory) could be implemented together with or instead of “restaurant.localservices.mobi” (service based directory). The invention may also be implemented as a machine-readable medium having machine-executable instructions stored thereon such that, when the instructions are read and executed by an appropriate device (or devices), steps of a method according to the invention are performed. These and other modifications are within the scope of the invention as defined in the attached claims.