Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/90—Details of database functions independent of the retrieved data types
  • G06F16/95—Retrieval from the web
  • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
  • G06F16/9566—URL specific, e.g. using aliases, detecting broken or misspelled links
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F40/00—Handling natural language data
  • G06F40/20—Natural language analysis
  • G06F40/205—Parsing
  • G06F40/221—Parsing markup language streams
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F40/00—Handling natural language data
  • G06F40/40—Processing or translation of natural language
  • G06F40/53—Processing of non-Latin text

Definitions

• This invention relates to URL address retrieval.
• Each Internet website has a unique website URL (uniform resource location) address which a user enters using his web browser in order to access the site.
• the URL has two parts, a domain name, specifying the host or the IP (Internet Protocol) address and the path to the resource. These are entered by the user in a word form which is then translated into a numerical address.
• URLs are composed from a standard character set comprising Latin alphabet characters and numerals and are resolved using "root" registry facilities provided by ICANN in conjunction with "branch" national registries in each country.
• a method of resolving a non-Latin character URL, having a domain name, entered by a user comprising the steps of: selecting a character set in which the URL is written; inputting the URL in characters from the character set; determining, using the character set of the input URL, one or more name servers that support domain names in the selected character set; querying at least one said name server with the domain name; and fetching contents from the URL if the query is satisfied.
• a method of resolving a non-Latin character URL, having a domain name, entered by a user using an Internet browser comprising the steps of: contacting a website supporting non-Latin character URL resolution, downloading a non-Latin character URL input program from the website, inputting the URL using the program and sending the URL to the website; determining at the website, using the character set of the URL, one or more name servers that support domain names in the selected character set; querying from the website at least one said name server with the domain name; and fetching contents from the URL if the query is satisfied and passing the contents to the user.
• a user is allowed to use any internet browser that has JavaScript and/or Java support to enter a non-Latin character URL (uniform resource location) and be able to retrieve and view non-Latin character contents without installing any additional software on his computer and without changing any client-side settings.
• the embodiment allows different methods (solutions) of i18n (Internationalized) domains to be accommodated.
• a non-Latin character editor is provided to enter a non-Latin character URL and to convert non-Latin character web pages to graphics dynamically for viewing without additional software.
• a user selects an input method with a language encoding.
• a list of choices of the characters is displayed through graphics fetched from a web server to allow the user to select the character as the user types.
• Each character has a unique Unicode (Universal Character Set ISO/IEC 10646 implementation) representation and this allows the embodiment to keep track of the Unicode and to display the character using a graphic having the Unicode as its filename.
• Unicode Universal Character Set ISO/IEC 10646 implementation
• Unicode is only one example of a possible character encoding that the invention can use.
• a character graphics web server may contain multiple character graphics sets in different languages and character codings, each in a different folder and having a naming standard that maps the character code to a URL name.
• the fetched contents of the URL may be dynamically converted to a graphical representation which allows the user to view any non-Latin character contents without additional software.
• the described method can resolve an M8n domain URL that can include any implementation of an i18n domain.
• a domain name query is sent to a name server that supports a particular implementation of i18n domains.
• a function to allow a user to select one of the i18n implementation is preferably provided.
• a default ordering of the i18n methods is also preferably provided for resolving so that the IP address of the domain host of the first i18n domain method that returns an IP address successfully is used. After the contents are fetched, these may be filtered so that if a URL in the contents contains an i18n domain, this URL can be replaced with the JavaScript codes that are able to resolve the i18n domain.
• Figure 1 is a schematic diagram illustrating the principal components used in the embodiment of the invention.
• Figure 2 is a flowchart illustrating an embodiment of the method of the invention.
• Figure 3 is a flowchart to explain the step of obtaining the multi-lingual URL of Fig. 2.
• Figure 4 is a flowchart to explain the step of resolving the i18n domain of Fig. 2.
• Figure 5 is a flowchart to explain the fetch and filter contents step of Fig. 2 .
• FIG. 1 shows a high-level schematic view of the different components used.
• An Internet browser 110 is provided that is opened by a user whose computer is connected to the Internet 100.
• the user is connected to a web server 140 which contains downloadable programs namely a non-Latin character editor toolbar 120 and also a JavaScript and Java applet 125 supporting the method of the present invention.
• a name resolver program 145 is also disposed on the server 140 and is required to do domain name resolving on the server-side.
• Three different types of server may be connected to the Internet namely a normal name server 10 (e.g. Bind), a name server 11 using the i18n domain solution provided by IDNS and a name server 12 using the i18n domain solution provided by CNNIC.
• a user can open up the Internet browser 110 and browse to the web server site 140.
• the browser 110 retrieves the non-Latin character editor toolbar web page 120 with the associated JavaScript and the hidden Java applet 125.
• the non-Latin character editor 120 works in Unicode for essential resolution of international characters but may use any other coding scheme or allow the user to select the coding scheme to be used.
• the user selects an input method for the characters forming the address and any non-Latin character domain URL can then be entered by running the JavaScript program 125 in the client browser 110 which causes the toolbar to be displayed allowing character entry.
• the JavaScript program captures the address that the user has entered and decides the Unicode character the user has selected based on the input method the user has chosen.
• the JavaScript then displays the Unicode character by fetching a graphics file (which has a filename equivalent to the Unicode) from the web server 140 allowing a Unicode character to be dynamically converted to its graphical representation without requiring the user to install any non-Latin character software on his computer.
• the user then hits ⁇ enter> with the intention of browsing to the non-Latin character domain URL that he has just entered. It is important that the software of the present invention is used for entering the URL. For example, if the user has instead entered this URL with the help of other software into the browser 110 address bar and hit ⁇ enter>, the browser 110 will proceed to fetch the URL directly using the default name server as configured in the Operating Sysytem (usually) or the browser. If that name server is not capable of resolving i18n addresses, a host name lookup failure will occur. Even if the default name server is i18n capable, it is very likely that it comply to only one implementation of i18n domain name standard (e.g. iDNS or CNNIC, not both), and a host name lookup failure may occur (if the user wants a i18n domain in the iDNS standard, but the default name server setting is set to CNNIC, for example).
• iNS iNode
• the next step is to resolve the non-Latin character domain to an IP address.
• the name server settings on the computer will normally point to a normal name server 11 at this current date. If a domain name query is send to such a name server 11 , the name server 11 will return an error since the non-Latin character domain name is not a valid standard domain name (which is allowed only to consist of Latin alphabet, digits and hyphen).
• the domain name query is performed by either the Java applet 125 or the name resolver 145 which determines from the Unicode representation, if the URL is in Latin character form or not.
• the name resolver keeps a list of well-known IP servers that provides domain name service for each type of i18n domain implementation.
• the domain name query will be send to the correct name server that knows how to resolve the non-Latin character domain name.
• the non-Latin character domain name query can be sent to either the IDNS name server 11 or/and the CNNIC name server 12.
• the same non-Latin character domain may be registered by different parties, resulting in a conflict.
• This is resolved in the present method by allowing the user to choose the i18n domain solution provider.
• a client-side domain name query will use the Java applet 125 to perform the resolution while a server-side domain name query will use the name resolver to perform the resolution.
• Both solutions basically are similar except that the server-side solution is more flexible and can have better features. For example, it will be easier to update the name server list information on the name resolver 145 and it can support advanced caching.
• the Java applet 125 proceeds to fetch the contents of the URL based on the IP address that is resolved earlier.
• the Java applet After the contents are fetched, the Java applet filters the contents so that if a URL in the contents contains an i18n domain, this URL is replaced with JavaScript codes which will forward the request to the Java applet 125 to resolve M8n domain URL when a user clicks on it.
• the Java applet 125 displays the contents in another frame in the browser 110.
• the contents can be fetched and then filtered before the web server 140 returns the contents to the client browser 110.
• the present method is able to resolve any i18n domain names from different i18n domain implementations as long as their name server solutions supports the standard name server solution, that is to say, the concept and design of the name server should follow what is described in RFC 1034 and RFC 1035.
• DNS queries and responses should be carried in a standard message format as described in RFC 1034 and RFC 1035 so that the same resolver may be used to query each of the name servers independent of the i18n domain implementation.
• FIG. 2 presents a flow chart of the complete method.
• a user uses the non-Latin character editor to enter a non-Latin character URL.
• the domain part of the URL is resolved to obtain an IP address, (shown in block 21)
• the contents of the URL is fetched based on the IP address and the contents are filtered to replace URLs that contains an i18n domain with JavaScript codes, (shown in block 22)
• the contents are displayed on the user's browser even if the browser does not have non-Latin character support, (shown in block 23).
• the non-Latin character URL editor toolbar downloaded from a web page on server 140 is displayed in the browser frame.
• a user can conveniently connect to this web page by using an internet bookmark or the user can enter the URL directly in the internet address bar of the browser.
• the current Internet Explorer browser supports custom toolbars such as this that can be placed at the left or bottom side of the browser and which can be invoked from the links toolbar for easy access.
• the non-Latin character editor does not require any client-side installation or any configuration settings on the user computer and can be extended to support any kind of language and input methods and all of this can be updated in the server without the user being aware of it.
• the user's computer is not required to install any language fonts and the browser is not required to support non-Latin character languages.
• Each non-Latin character character is displayed using a graphics file that is stored in the web server.
• the representing graphics file can be named using the Unicode and thus, this allows any non-Latin character web page to be displayed.
• the user selects the language and input method.
• the JavaScript codes in the web page download the appropriate dictionary corresponding to the selected input method so that it is able to map what the user keys in to a character code.
• JavaScript is used as it is supported by most of the popular browsers including Internet Explorer and Netscape browser.
• the running JavaScript codes capture the keys entered by the user and the dictionary is checked for correspondence to any possible choices of characters. If there is only a single choice, then the character code is determined, otherwise the list of choices are displayed for the user to select as shown in block 204. All characters are displayed by fetching their representing graphics files from the web server.
• the user selects the graphic character from the list of choices displayed and thus the character code is determined.
• the JavaScript codes append the Unicode character code to an internal URL string and also display the graphics character in the URL editor. This process is then repeated as the user keys in the full URL before the user hits the ⁇ enter> key to signal that he has finished and wants to browse the web page indicated by the URL.
• Block 207 illustrates this repeat process.
• the user is able to switch to another language and input method and thus input a URL in multiple character sets at block 202 provided each character has a Unicode equivalent, although the existing language and method remaining as a default unless changed by the user in block 202.
• a different dictionary may be automatically downloaded by the Javascript codes.
• the JavaScript codes will store the Unicode string URL that the user has keyed in at the end of the process of block 20.
• the domain part of the URL is resolved to obtain the host IP address.
• This process is illustrated in greater detail in FIG. 4.
• IDNS the domain part of the URL is resolved to obtain the host IP address.
• CNNIC the domain name that can be resolved correctly against any i18n domain solutions.
• the i18n domain solution is compatible with the current standard domain name servers, the present method can accommodate this and if the i18n domain name server can accept the same kind of the standard domain name query and returns the IP address to the client that sends the query, it will be compatible.
• IDNS and CNNIC solutions are compatible.
• the present method needs to query the correct domain name server that supports the selected i18n domain solution or simply, all the name servers that support the i18n domain solution provided by IDNS or CNNIC can be queried. Since in general, it is not possible to distinguish in which i18n domain solution (domain registrar) a domain is registered, the user can select the i18n domain solution in the non-Latin character editor toolbar. A default ordering of the i18n domain solutions is also provided so that when the software queries a domain name this is done against the name servers of one domain solution before the name servers of another solution.
• the implementation may query name servers of different i18n domain solutions in parallel to speed things up and then return the IP addresses with the default ordering. If there is a conflict of a domain name registered in different domain solutions, the user is given the option to try the other hosts (IP addresses) if the default is not the one he wants.
• FIG. 4 the diagram depicts the process of the domain name query is carried out in series although this can be done in parallel also.
• the process checks whether the domain is in standard URL characters, if it is, the contents of the URL are retrieved as normal. If the domain is an i18n domain, the present method proceeds to resolve the domain by first retrieving the full list of i18n domain solutions shown in block 212. (e.g. IDNS and CNNIC). In block 213, a domain solution is selected and a list of domain name servers that support the selected domain name solution is retrieved. Currently, such a list of server IP addresses can be compiled manually and configured for the process to use. For each domain name server (as shown in block 214) in the list, the process sends a domain name query against it as shown in block 215.
• the process is complete (as shown in block 216) although in practice, more than one IP address from different i18n domain solutions can be returned as described earlier to solve domain name conflicts.
• the block 217 is executed to repeat the domain name query against another of the name servers in the list.
• the process is repeated for another domain name solution by sending the same domain name query against another list of name servers supporting the solution. (In practice, this can be done in parallel).
• the domain name resolving process can be implemented in either the client- side or the server-side.
• a client-side solution can be implemented using a Java applet.
• a server-side solution is more flexible and can have better features.
• the process of fetching and filtering the contents of the URL as shown in block 22 can also be implemented within the same Java applet.
• server-side name resolver 145 is used instead, there is a choice of either using client-side or server-side fetching and filtering.
• Client- side fetching and filtering has the advantage of offloading the server but it will make the client-side codes more complicated.
• Server-side filtering can resolve all i18n domains in the URLs of the contents all at once with good caching. '
• the contents of the URL are fetched based on the IP address and the contents is filtered to replace URLs that contains an i18n domain with Javascript codes which will forward the request to the Java applet to resolve i18n domain URL when a user clicks on it. If the original URL that contains an i18n domain is clicked on, the browser will use the default domain name query which may fail against a standard name server. Thus, the contents are filtered to solve this problem. Even if all such i18n domains are resolved before displaying the contents by replacing the domains with their IP addresses, it is not sufficient to ensure that it will work correctly in all cases.
• the solution used in the present method is to replace the URL with a Javascript function call and pass the parameter of the original URL to it. (An additional parameter for the host IP address can be passed if already resolved)
• the Javascript function is initiated to fetch the contents and this functionality is similar to fetching the contents of the URL the user keys in with the non-Latin character editor. This process of fetching and filtering is illustrated in FIG. 5 in greater detail.
• the contents of the URL are fetched.
• the process uses the resolved host IP address to connect to the web server and then fetches the contents of the original URL.
• the fetched contents are then parsed in block 222.
• each URL in the contents is extracted.
• the URL is checked to see whether it contains an i18n domain name in block 224. If it does, it is replaced by the Javascript function call as shown in block 225.
• Block 226 illustrates the process is repeated for each of the extracted URL in the contents.
• the updated contents are then returned and the process is completed. Next, the contents are written back to the browser frame as shown in block 23.
• a character graphics web server may contain multiple character graphics sets in different languages and character codings, each in different folder and a naming standard that maps the character code to the URL name, e.g. the word is (for the word 'six' in Chinese) is code 0xC1 F9 in GB2312 code, and its graphics can be stored in the web server under the folder gb, and thus have the URL http://[graphics_web_server_domain]/gb2312/C1 F9.gif The same word /% is also code 0x516D in Unicode version 3.0, and its graphics can be stored in the same web server under the folder unicode3, and have the URL http://[graphics_web_server_domain]/unicode3/516D.gif The naming for the folder and file name for each character is determined by the Javascript/Java code with consultation from the dictionary loaded.
• a "Hanyu- pinyin input method” dictionary built for the GB2312 coding may point the graphics for the input "Iiu4" for the word 'six' in Chinese to http://[graphics_web_server_domain]/gb2312/C1 F9.gif
• another "Hanyu- pinyin input method” dictionary built for the Unicode coding may point the graphics for the same input "Iiu4" for the word 'six' in Chinese to http://[graphics_web_server_domain]/unicode3/516D.gif .
• all the character graphics files may be arranged in Unicode, and all dictionaries customized to Unicode as far as possible (since Unicode contains characters of multiple languages), so as to minimize maintenance of a large number of different graphics sets and dictionaries.
• Reference to a non-Latin character URL includes reference to a URL which has a non-Latin character domain name and a Latin or non-Latin character path portion.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Audiology, Speech & Language Pathology (AREA)
• Computational Linguistics (AREA)
• General Health & Medical Sciences (AREA)
• Health & Medical Sciences (AREA)
• Artificial Intelligence (AREA)
• Databases & Information Systems (AREA)
• Data Mining & Analysis (AREA)
• Multimedia (AREA)
• Information Transfer Between Computers (AREA)
• Computer And Data Communications (AREA)

Priority Applications (4)

Applications Claiming Priority (1)

Publications (1)

Family

ID=20428824

Family Applications (1)

Country Status (4)

Cited By (2)

Citations (2)

• 2000
  • 2000-06-07 WO PCT/SG2000/000082 patent/WO2001095144A1/en active Application Filing
  • 2000-06-07 CN CNB008196206A patent/CN1210665C/zh not_active Expired - Fee Related
  • 2000-06-07 AU AU2000251209A patent/AU2000251209A1/en not_active Abandoned
  • 2000-06-07 JP JP2002502628A patent/JP2003536139A/ja active Pending

Patent Citations (2)

Also Published As

Similar Documents

Legal Events