JP3492580B2

JP3492580B2 - マルチリンガル・ドメイン・ネーム・サービス

Info

Publication number: JP3492580B2
Application number: JP2000033893A
Authority: JP
Inventors: ティン・ウィー・タン; チング・ホング・セング; ジュエイ・クワング・タン; コク・ヨング・レオング; ドン・アーウィン・トレイシー・デ・シルバ; クアン・シオング・リム; エドワード・エス．・テイ; サブラマニアン・サビア
Original assignee: アイ−ディーエヌエスドットネット・インターナショナル・インコーポレーテッド
Priority date: 1999-02-26
Filing date: 2000-02-10
Publication date: 2004-02-03
Anticipated expiration: 2020-02-10
Also published as: WO2000050966A3; SG91854A1; KR20000076575A; CN1266237A; EA200000136A2; HK1096499A1; US6446133B1; EP1059789A2; KR100444757B1; TW461209B; EP1059789A3; US20010025320A1; WO2000050966A2; EA002513B1; CN1812407B; EA200000136A3; US6314469B1; HK1029418A1; CN1238804C; JP2000253067A

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はネットワーク・ドメ
イン・ネームを対応するネットワーク・アドレスへリゾ
ルブするために使用するドメイン・ネーム・サービスに
関する。より詳細には、本発明はＡＳＣＩＩだけではな
く、多数の異なるエンコーディング・フォーマットで提
供されたドメイン・ネームを受け入れる従来にないドメ
イン・ネーム・サービス、即ち、修正を加えたドメイン
・ネーム・サービスに関する。

【０００２】

【従来の技術及び発明が解決しようとする課題】インタ
ーネットは純粋な調査及び学問を目的としたエンティテ
ィからグローバル・ネットワークへと進化しており、こ
のグローバル・ネットワークは異なる言語及び文化を有
する多様なコミュニティへ達している。インターネット
利用者が要求するローカリゼーションを実現するため
に、インターネットは全ての地域で発達してきた。今
日、電子メールは殆どの言語でやりとりされている。マ
ルチリンガルを可能にしたソフトウェア・アプリケーシ
ョンが急増したことにより、現在、ワールド・ワイド・
ウェブ上のコンテントは多くの異なる言語で公開されて
いる。電子メール・メッセージを別の人へ中国語で送信
したり、日本語のワールド・ワイド・ウェブ・ページを
見たりすることが可能である。

【０００３】今日、人が判読できる名前を数値であるＩ
Ｐアドレスへリゾルブしたり、逆に、ＩＰアドレスを人
が判読できる名前へリゾルブしたりするために、インタ
ーネットはドメイン・ネーム・システムに完全に依存し
ている。ドメイン・ネーム・システム（ＤＮＳ）はラテ
ン−１アルファベットのサブセット（したがって、主に
英語）を依然としてベースにしている。汎用性を提供す
るために、電子メール・アドレス、ウェブ・アドレス及
び他のインターネット・アドレス・フォーマットは、イ
ンターオペレーションを保証するグローバル・スタンダ
ードとしてＡＳＣＩＩを採用している。電子メール・ア
ドレスまたはウェブ・アドレスをＡＳＣＩＩでないネイ
ティブ言語で表記することを可能にする手段は形成され
ていない。このことは、インターネットの全てのユーザ
がＡＳＣＩＩキャラクタに関する多少の知識を有する必
要があることを意味している。

【０００４】英語をサイエンス、テクノロジー、ビジネ
ス及び政治の国際言語として理解できるテクニカル・ユ
ーザまたはビジネス・ユーザにとって、このことは問題
にならない。しかし、この事実は、英語が一般的に話さ
れていない国々におけるインターネットの急速な普及の
障害といえる。電子メール・アプリケーションはネイテ
ィブ言語をサポートし得るが、電子メール・アドレスは
ネイティブ言語をサポートできない。したがって、これ
らの国々では、インターネット初心者は電子メールを自
分のネイティブ言語で送信するための必要条件として、
基本的な英語を理解する必要がある。ファイルネーム及
びディレクトリ・パスはネイティブ・ロケール（native
locale）内ではマルチリンガルで表記できるが、プロ
トコルはＡＳＣＩＩ以外の言語をドメイン・ネーム・フ
ィールド内でサポートしていない。したがって、名前を
コーポレート・イントラネットのデパートメント・ドメ
イン・ネーム及びウェブ・ドキュメントへ付与するため
に、コーポレート・イントラネットはＡＳＣＩＩを使用
する必要がある。

【０００５】更に、ヨーロッパ言語のユーザは、アクセ
ントなどを使用することなく自分のドメイン・ネームを
似せる必要がある。コーポレート・アイデンティティを
堅持することを望むCitroenなどの企業は、自社の名前
を自社の名前に最も近いＡＳＣＩＩ相当語句に似せる必
要があり、よって、”www.citroen.fr”を使用してい
る。更に、フランスのFrancoisは自分の電子メール・ア
ドレスを故意に”francois@email.fr”とミスタイプし
なければならないことに対する苛立ちに常に耐える必要
がある（架空の例）。

【０００６】フォントを関連するロケール内で提供する
ために、オペレーティング・システムをローカライズす
ることが可能である。これにより、電子メール・アドレ
ス・フィールド内のユーザＩＤを、マルチリンガル・ス
クリプトで表記できる。更に、ディレクトリ及びファイ
ルネームもマルチリンガル・スクリプトで表記できる。
しかし、これらの名前のうちのドメイン・ネームの部分
はドメイン・ネーム・システムを定めた規格であるＲＦ
Ｃ１０３５のインターネット規格によって許可されたも
のに限られている。

【０００７】この状況を説明するもっともな理由の１つ
としては、ソフトウェア開発者がオーバーラップするコ
ードを使用する傾向がある点が挙げられる。例えば、中
国語のＢＩＧ５エンコーディング及びＧＢ２３１２エン
コーディング（即ち、グリフまたはキャラクタのディジ
タル表現）はオーバーラップしており、ほんの僅かな例
を挙げれば、日本語のＪＩＳ及びシフトＪＩＳ並びに韓
国語のＫＳＣ５６０１も同様に重複している。この結
果、ＢＩＧ５エンコーディング及びＪＩＳエンコーディ
ングの間の違い、またはＧＢ２３１２エンコーディング
及びＫＳＣ５６０１エンコーディングの間の違いは、情
報をエンコーディングを使用しているアプリケーション
・クライアントへ提供するために、このエンコーディン
グを特定する追加パラメータを含めない限り簡単に告げ
ることはできない。したがって、ドメイン・ネームの固
有性と、エンコーディングの確実性とを保証するため
に、ＤＮＳはＡＳＣＩＩに固執している。

【０００８】ＲＦＣ１０３５に基づき、有効なドメイン
・ネームは、アルファベット文字のＡ〜Ｚ（ケース・イ
ンセンシティブ）、数字の０〜９及びハイフン・シンボ
ル（−）のみを含むＩＳＯ−８８５９ラテン−１アルフ
ァベットのサブセットに現在のところ限定されている。
この制限により、ドメイン・ネームは、英語またはロー
マ字を使用する言語（マレー語若しくは日本語のローマ
字、または字訳されたタミル語などのローマ式字訳な
ど）を事実上サポートしている。これ以外のスクリプト
を受け入れることは不可能であり、拡張ＡＳＣＩＩキャ
ラクタであっても使用できない。

【０００９】ユニコード（Unicode）は殆どの重要な言
語のほぼ全てのキャラクタを１６ビット値へユニークに
マッピングしたキャラクタ・エンコーディング・システ
ムである。ユニコードは重複しないユニークなエンコー
ディング・システムの基礎を築いた。したがって、今日
の世界に存在する変化に富んだ多数の言語を受け入れ得
る未来のＤＮＳネームスペースのベースとしてのユニコ
ードの使い方の探求が、一部の研究者によって始められ
た。１９９８年７月現在のＩＥＴＦのホーム・ページ
（http://www.ietf.cnri.reston.va.us/ID.html）に掲
載されているM. Duerstによるインターネット・ドラフ
トである”draft-duerst-dns-i18n-02.txt”の”ドメイ
ン・ネームの国際化（Internationalization of Domain
Names）”と称される文献は、このことを開示してい
る。この文献の全ての内容は、この開示をもって本明細
書に開示したものとする。非英語使用者がインターネッ
トを使用することを更に容易にするマルチリンガルなマ
ルチスクリプト・ファンクショナリティを、新たなネー
ムスペースは提供する必要がある。

【００１０】新たなドメイン・ネーム・システムのため
のスタンダード・キャラクタ・セットとしてのユニコー
ドの採用によって、異なる複数の言語スクリプトのコー
ド・スペースの重複を防止できる。これにより、インタ
ーネット・コミュニティはwww.citroen.ch及びwww.gene
ve-city.chなどの自分達のネイティブ・スクリプトで表
記したドメイン・ネームを使用できる。

【００１１】しかし、不都合なことに、マルチリンガル
・ドメイン・ネーム・システムをインプリメントするた
めのＤＮＳサーバ及びクライアント・アプリケーション
の変更は、幾つかの問題点によって妨げられる。例え
ば、全ての未来のクライアント・アプリケーション及び
全ての未来のＤＮＳサーバの変更が必要になる。システ
ムが機能するためには、クライアント及びサーバの両方
の変更が必要なので、古いシステムから新しいシステム
への移行は困難である。更に、非常に僅かな数の利用可
能なクライアント・アプリケーションがネイティブ・ユ
ニコードを使用しているだけである。これに代わって、
殆どのマルチリンガル・クライアント・アプリケーショ
ンは非ユニコード・エンコーディングを使用するととも
に、強力な支持者を有する。

【００１２】これらの問題点及びその他の問題点に鑑み
て、多数の言語エンコーディング（linguistic encodin
gs）をＤＮＳシステム内で使用することを可能にする技
術を有することが非常に望ましい。本発明の目的は、ユ
ーザが非ユニコード・エンコーディング及び非ＡＳＣＩ
Ｉエンコーディングで表記されたドメイン・ネームを使
用することを可能にするマルチリンガル・ドメイン・ネ
ーム・システムをインプリメントするシステム及び方法
を提供することにある。

【００１３】

【課題を解決するための手段】本発明の方法は、様々な
システム内または複数のシステムの結合体内でインプリ
メント可能であるが、ここでは、本発明の方法をインプ
リメントするシステムは、インターナショナルＤＮＳサ
ーバ（international DNS server、即ち、”ｉＤＮＳ”
サーバ）と呼ぶものとする。ｉＤＮＳサーバがＤＮＳリ
クエストを最初に受信した際、ｉＤＮＳサーバはこのリ
クエストのエンコーディング形式を決定する。ドメイン
・ネームのトップ・レベル・ドメイン内のビット・スト
リングを検討し、次いで、このストリングを、様々なエ
ンコーディング形式における既知のトップ・レベル・ド
メインの既知のビット・ストリングのリストと照合し
て、マッチするものを見つけることによって、ｉＤＮＳ
サーバはエンコーディング形式を決定する。例えば、リ
スト内の１つのエントリは中国語のＢＩＧ５で表記され
た”.com”のビット・ストリングであり得る。ｉＤＮＳ
サーバがドメイン・ネームのエンコーディング形式を識
別した後、ｉＤＮＳサーバはドメイン・ネームのエンコ
ーディングを汎用言語エンコーディング形式（universa
l linguistic encoding type）（例：ユニコード）へ変
換する。ｉＤＮＳサーバは、この汎用言語エンコーディ
ング形式表現を汎用ＤＮＳスタンダードに準拠したＡＳ
ＣＩＩ表現へ翻訳する。次いで、このＡＳＣＩＩ表現は
従来のドメイン・ネーム・システムへ送信される。従来
のドメイン・ネーム・システムはＡＳＣＩＩフォーマッ
トのドメイン・ネームを認識し、かつ、これに関連する
ＩＰアドレスを返す。

【００１４】本発明の１つの態様は、ディジタル表現さ
れたドメイン・ネームの言語エンコーディング形式を検
出する方法を提供する。この方法は、以下の順序、即
ち、（ａ）ディジタル表現されたドメイン・ネームの所
定部分（例：トップ・レベル・ドメイン）のディジタル
・シーケンスを受信する工程と、（ｂ）前記のドメイン
・ネームから得られたディジタル・シーケンスを、既知
のディジタル・シーケンスのコレクションから得られた
既知のディジタル・シーケンスとマッチさせる工程と、
（ｃ）前記のドメイン・ネームから得られたディジタル
・シーケンスにマッチする既知のディジタル・シーケン
スに関連するエンコーディング形式を識別する工程とに
よって特徴付けできる。前記の（ｂ）の工程で使用する
既知のディジタル・シーケンスは、特定の言語エンコー
ディング形式に関連している。前記の既知のディジタル
・シーケンスのコレクションは、少なくとも２つの異な
る言語エンコーディング形式の既知のディジタル・シー
ケンスを含む点に注意する必要がある。

【００１５】多くの場合、前記のコレクションをテーブ
ル内に提供することが効果的であり、このテーブルは属
性を有するレコードを含み、前記の属性は既知のディジ
タル・シーケンス及びエンコーディング形式を含む。こ
の場合、エンコーディング形式の識別は、マッチする既
知のディジタル・シーケンスを有するレコードのエンコ
ーディング形式を識別することを要する。テーブル内に
示されているエンコーディング形式の例は、ＡＳＣＩ
Ｉ、ＢＩＧ５、ＧＢ２３１２、シフトＪＩＳ、ＥＵＣ−
ＪＰ、ＫＳＣ５６０１及び拡張ＡＳＣＩＩを含む。

【００１６】少なくとも２つの既知のディジタル・シー
ケンスがドメイン・ネームから得られたディジタル・シ
ーケンスとマッチする際、この多義性を解決する必要が
ある。これは、（ａ）ディジタル表現されたドメイン・
ネームの第２部分のディジタル・シーケンスを受信する
ことと、（ｂ）第２部分のディジタル・シーケンスを複
数回デコーディングし、各回ごとに、複数の言語エンコ
ーディング形式の中から選ばれた、異なる１つの言語エ
ンコーディング形式のデコーディング・スキームを使用
し、前記の各言語エンコーディング形式は少なくとも２
つの既知のディジタル・シーケンスに関連していること
と、（ｃ）最適な結果を提供するデコーディングを識別
することによって達成し得る。これに代わって、拡張デ
ィジタル・シーケンス（ドメイン・ネームの第１部分及
び第２部分の両方を含む）を最初にマッチさせ、次い
で、この拡張シーケンスを同拡張シーケンスに対応する
既知のディジタル・シーケンスとマッチさせることによ
って、多義性を解決できる。この場合、既知のディジタ
ル・シーケンスのコレクションは幾つかの拡張シーケン
スを含む必要がある。

【００１７】特定の実施形態では、レコードのコレクシ
ョンは”最小コード・リゾルビング・ストリング（mini
mum code resolving string、略して、ＭＣＲＳ）”の
ディジタル・シーケンス（またはディジタル・シーケン
ス表現）を含む。これはドメイン・ネームの部分のディ
ジタル・シーケンスであるとともに、このドメイン・ネ
ーム（特定のエンコーディング形式で表記されたドメイ
ン・ネーム）をコレクション内における他の全てのドメ
イン・ネーム／エンコーディング形式のコンビネーショ
ンから区別することが知られている。マッチングが生じ
た際に、多義性を防止できれば、ＭＣＲＳはトップ・レ
ベル・ドメインのサブ・ストリングであったり、トップ
・レベル・ドメインのスーパー・ストリングであった
り、第２レベル・ドメイン及び第３レベル・ドメインに
対するオーバーフローであったりする。

【００１８】前記のように、本発明の方法はＤＮＳリク
エストの処理に特に適用可能である。したがって、更
に、本発明の方法は、（ｉ）ディジタル表現されたドメ
イン・ネームを含むＤＮＳリクエストを受信する工程
と、（ｉｉ）識別されたエンコーディング形式のルート
・レベル・ドメインをリゾルブする責任を有するルート
・レベルＤＮＳサーバを識別する工程と、（ｉｉｉ）Ｄ
ＮＳリクエストをルート・レベルＤＮＳサーバへ送信す
る工程とを含み得る。ＤＮＳリクエストを送信する前
に、システムはドメイン・ネームのディジタル・シーケ
ンスを、識別されたエンコーディング形式からＤＮＳプ
ロトコルと互換性のあるＤＮＳエンコーディング形式
（例：ＡＳＣＩＩまたはユニコード若しくは将来的には
他の汎用言語エンコーディング形式）へ変換する必要が
ある。好ましい実施形態では、この変換は２つのオペレ
ーション、即ち、（ｉ）ドメイン・ネームのディジタル
・シーケンスを、識別されたエンコーディング形式から
汎用言語エンコーディング形式へ変換するオペレーショ
ンと、（ｉｉ）ドメイン・ネームのディジタル・シーケ
ンスを、前記の汎用言語エンコーディング形式からＤＮ
Ｓプロトコルと互換性のあるＤＮＳエンコーディング形
式へ変換するオペレーションとによって行われる。

【００１９】

【００２０】更に、本発明は以下の特徴、即ち、（ａ）
１つ以上のプロセッサと、（ｂ）前記の１つ以上のプロ
セッサのうちの少なくとも１つへ接続されたメモリと、
（ｃ）非ＤＮＳエンコーディング形式で表記されたドメ
イン・ネームを含む第１ＤＮＳリクエストを受信するこ
とと、ＤＮＳプロトコルと互換性のあるＤＮＳエンコー
ディング形式で表記されたドメイン・ネームを含むＤＮ
Ｓリクエストを送信することが可能な１つ以上のネット
ワーク・インターフェースとによって特徴付けることが
可能な装置に関する。非ＤＮＳエンコーディング形式で
表記されたドメイン・ネームを、ＤＮＳエンコーディン
グ形式で表記された対応するドメイン・ネームへ変換す
るために、前記の１つ以上のプロセッサのうちの少なく
とも１つは設計または形成されている。非ＤＮＳエンコ
ーディング形式で表記されたドメイン・ネームを提供す
るクライアントＤＮＳリクエストを、前記の装置が受信
することを可能にするように、前記の１つ以上のネット
ワーク・インターフェースをネットワークへ接続する必
要がある。前記の装置がＤＮＳリクエストをスタンダー
ドＤＮＳサーバへ送信することを可能にするように、前
記の１つ以上のネットワーク・インターフェースをネッ
トワークへ接続する必要があり、前記のＤＮＳリクエス
トは、ＤＮＳエンコーディング形式で表記されたドメイ
ン・ネームを提供する。

【００２１】本発明の装置は、メモリ上に少なくとも部
分的に存在するマッピング・テーブル（このマッピング
・テーブルは前記の複数のマッピング・テーブルのうち
の１つであり得る）を更に有することが好ましい。更
に、ドメイン・ネームを非ＤＮＳエンコーディング形式
からＤＮＳエンコーディング形式へ変換する前に、ドメ
イン・ネームの非ＤＮＳエンコーディング形式を識別す
るために、少なくとも１つのプロセッサを形成または設
計する必要がある。前記のものを含めた本発明の特徴及
び効果を図面に基づいて以下に詳述する。

【００２２】

【発明の実施の形態】１．ＤＮＳ及びユニコード本発明はマルチリンガル・マルチスクリプト名を、ＤＮ
Ｓ（例：１９９９年のＲＦＣ１０３５に開示されている
ＤＮＳ）に準拠したフォームへトランスフォームする。
次いで、トランスフォームした名前をＤＮＳクエリーと
して従来のＤＮＳサーバへリレーする。ローカライズさ
れたドメイン・ネームを数字のＩＰアドレスへリゾルブ
する方法を示す例示的プロセスを、図１に基づいて以下
に詳述する。しかし、図１を詳述する前に、基礎的な原
理及び用語を少し説明する。

【００２３】プログラムがホスト及び他のリソースを、
それらの２進数のネットワーク・アドレスで指し示すこ
とは希である。２進数の代わりに、プログラムはwww.po
box.org.sgなどのＡＳＣＩＩストリングを使用する。そ
れにもかかわらず、ネットワーク自体は２進数のアドレ
スしか理解できない。したがって、ＡＳＣＩＩストリン
グをネットワーク・アドレスへ変換するために、ある種
のメカニズムが必要である。このメカニズムはドメイン
・ネーム・システム（ＤＮＳ）が提供する。

【００２４】ＤＮＳの実体は、階層をなすドメイン・ベ
ースのネーミング・スキームと、このネーミング・スキ
ームをインプリメントするための分散データベース・シ
ステムとによって構成されている。ホスト・ネーム及び
電子メール・デスティネーションをＩＰアドレスへマッ
ピングするために、ＤＮＳは主に使用される。しかし、
ＤＮＳを他の目的で使用し得る。前記のように、ＤＮＳ
はＲＦＣ１０３４及びＲＦＣ１０３５に定義されてい
る。

【００２５】ＤＮＳの使用方法を以下に簡単に説明す
る。名前をＩＰアドレスへマッピングするために、アプ
リケーション・プログラムは”リゾルバ”と称されるラ
イブラリ・プロシージャを呼び出し、名前をパラメータ
としてリゾルバへ渡す。リゾルバはＵＤＰパケットをロ
ーカルＤＮＳサーバへ送信し、次いで、ローカルＤＮＳ
サーバは名前を探索し、ＩＰアドレスをリゾルバへ返
す。そして、リゾルバはこのＩＰアドレスをプログラム
へ返す。ＩＰアドレスを手にしたプログラムは、デステ
ィネーションとの間のＴＣＰコネクションを確立する
か、またはＵＤＰパケットをデスティネーションへ送信
し得る。

【００２６】概念的には、インターネットは多数のトッ
プ・レベル”ドメイン”へ分割されており、各ドメイン
は多数のホストをカバーしている。各ドメインはサブ・
ドメインへ分割され、これらのサブ・ドメインは更に分
割されている（以下同様に分割は続く）。これらの全て
のドメインはツリーによって表現できる。ツリーのリー
フは、サブ・ドメインを有さないドメインを表す（但
し、これらのドメインはマシンを勿論有している）。リ
ーフ・ドメインは単一ホストを含み得る。これに代え
て、リーフ・ドメインは何千ものホストを有する企業を
表し得る。

【００２７】トップ・レベル・ドメインは２つの種類、
即ち、一般トップ・レベル・ドメイン及国別トップ・レ
ベル・ドメインに分かれる。一般ドメインとしては、co
m（商業組織）、edu（教育機関）、gov（米国政府機
関）、int（特定の国際機関）、mil（米国軍）、net
（ネットワーク・プロバイダ）及びorg（その他の組
織）が挙げられる。ＩＳＯ３１６６に定められているよ
うに、国別ドメインは国ごとに１つのエントリを有す
る。各ドメインは、そこから名前のないルートへと上流
に向かって延びるパスによって名付けられている。複数
のコンポーネントはピリオド（”ドット”と発音する）
によって区切られている。

【００２８】原理的には、ドメインを２つの異なる方法
でツリーへ挿入できる。例えば、cs.ucb.ct.usと同じ様
に、cs.ucb.eduを国別ドメインであるus.の下に記載で
きる。しかし、実際には、米国内のほぼ全ての組織は一
般ドメインの下にあり、米国の国外にあるほぼ全ての組
織はそれぞれの国のドメインの下にある。２つのトップ
・レベル・ドメインの下での登録を禁止するルールは存
在しないが、これを実施することは混乱を生じ得る。し
たがって、僅かな数の組織がこれを実施しているだけで
ある。

【００２９】各ドメインは、該ドメインの下でのドメイ
ンの割り当て方法をコントロールしている。例えば、ed
u及びcomにそれぞれ対応するac.jp及びco.jpのドメイン
を、日本は有している。新たなドメインを形成するため
には、この新たなドメインが属そうとするドメインの許
可を得る必要である。例えば、人工的なインテリジェン
ス・グループをユニバーシティ・オブ・カリフォルニア
・バークレー校（theUniversity of California at Ber
keley）でスタートさせ、このグループがai.cs.ucb.edu
として知られることを望む場合、このグループはcs.uc
b.eduを管理する管理者からの許可を得る必要がある。
同様に、例えば、ユニバーシティ・オブ・レイク・タホ
（the University of Lake Tahoe）という新たなユニバ
ーシティを設立する場合、このユニバーシティ・オブ・
レイク・タホはulth.eduを自校へ割り当ててもらうこと
をeduドメインの管理者に頼む必要がある。これによ
り、名前の競合は防止され、各ドメインは自身の全ての
サブ・ドメインを常に把握できる。新たなドメインを形
成し、かつ、登録した後、ツリー内のこのドメインより
上位に位置するエンティティの許可を得る必要なしに、
この新たなドメインは自身のサブ・ドメイン（例：cs.u
lth.edu）を形成可能である。

【００３０】理論的には、少なくとも、単一のネーム・
サーバはＤＮＳデータベース全体を含み得るとともに、
このＤＮＳデータベースに関する全てのクエリーに応答
し得る。しかし、実際には、このサーバは機能不能を招
来するオーバーロードを起こし得る。更に、このサーバ
がダウンした場合、インターネット全体が機能しなくな
ることもある。単一情報源を有することに関連したこれ
らの問題を防止するために、ＤＮＳネーム・スペースは
重複しない”ゾーン”に分割されている。各ゾーンはツ
リーの一部を含むとともに、このゾーンに関するオーソ
リティ・インフォメーション（authoritative informat
ion）を保持するネーム・サーバを有する。通常、ゾー
ンは、自身の情報を自身のディスク上のファイルから獲
得する１つのプライマリ・ネーム・サーバと、自身の情
報をプライマリ・ネーム・サーバから獲得する１つ以上
のセカンダリ・ネーム・サーバとを有している。

【００３１】リゾルバがドメイン・ネームに関するクエ
リーを受信した際、リゾルバはこのクエリーを複数のロ
ーカル・ネーム・サーバのうちの１つへ送信する。cs.u
cb.eduに属するai.cs.ucb.eduのように、探し求めてい
るドメインが、このネーム・サーバの支配圏に属してい
る場合、このネーム・サーバはオーソリティ・リソース
・レコードを返す。オーソリティ・レコードは、そのレ
コードを管理するオーソリティから送られるものであ
る。したがって、オーソリティ・レコードは常に正し
い。このネーム・サーバは”キャッシュされたレコー
ド”も含み得る。この”キャッシュされたレコード”は
恐らく古い。

【００３２】関心のあるドメインがリモートであり、リ
クエストのあったドメインに関する情報がローカルに存
在しない場合、前記のネーム・サーバはクエリー・メッ
セージを前記のリクエストのあったドメインのトップ・
レベル・ネーム・サーバへ送信する。例えば、ai.cs.uc
b.eduのＩＰアドレスを探し求めるローカル・ネーム・
サーバは、ＵＤＰパケットをeduのサーバ（このサーバ
はedu-server.netを自身のデータベース内に有する）へ
送信する。このeduのサーバがai.cs.ucb.eduのアドレス
を知っていることは考えられないことであり、このサー
バはcs.ucb.eduについても知らないであろう。しかし、
このサーバは自身の全ての子を必ず知っている。したが
って、このサーバは前記のリクエストをucb.eduのネー
ム・サーバへ送信する。次いで、ucb.eduのネーム・サ
ーバは前記のリクエストをcs.ucb.edu（このサーバは該
当するオーソリティ・リソース・レコードを必ず有して
いる）へ送信する。各リクエストはクライアントからサ
ーバへ送信されたものであるため、リクエストのあった
オーソリティ・レコードは、ai.cs.ucb.eduのＩＰアド
レスをリクエストしたオリジナル・ネーム・サーバへ返
される。

【００３３】レコードがオリジナル・ネーム・サーバへ
返された後、後から必要な場合に備えて、このレコード
はオリジナル・ネーム・サーバのキャッシュへ格納され
る。しかし、cs.usb.eduでの変更は、cs.usb.eduを知る
世界中の全てのキャッシュへ伝達されないので、このイ
ンフォメーションはオーソリティ・インフォメーション
ではない。この理由から、キャッシュ・エントリは頻繁
に除去するか、または更新する必要がある。これは各レ
コードに含まれる”time_to_live（生存時間）”フィー
ルドによって実現し得る。

【００３４】ドメイン・ネームをリゾルブする前記の方
法の例は、リカーシブ・クエリーと称される。これ以外
の技術が存在する。ＤＮＳに関する更なる詳細は、ニュ
ージャージ州のアッパー・サドル・リバーに所在するプ
レンティス・ホール社（Prentice Hall）から１９９６
年に出版されたAndrew S. Tanenbaumの”コンピュータ
・ネットワーク”第３版（”Computer Networks,” 3^rd
Ed.）に開示されており、前記の説明の殆どはこの文献
に基づいている。更に、カリフォルニア州サンフランシ
スコに所在するマグローヒル社（McGraw-Hill）から１
９９８年に出版されたU.D.Blackの”ＴＣＰ／ＩＰ及び
関連するプロトコル”第３版（”TCP/IP and Related P
rotocols,” 3^rd Ed.）にも、ＤＮＳに関する更なる詳
細が開示されている。これらの引用文献の内容はこの開
示をもって本明細書に開示したものとする。

【００３５】前記のように、ＤＮＳプロトコルはＡＳＣ
ＩＩのサブセットを現時点ではベースとしており、よっ
て、ラテン・アルファベットに限定されている。多数の
他のエンコーディングは、世界の他のキャラクタ・セッ
トのディジタル表現を提供している。この例としては、
中国語キャラクタ・スクリプトのためのＢＩＧ５及びＧ
Ｂ−２３１２（それぞれ伝統的なエンコーディング及び
簡易化されたエンコーディングである）と、日本語キャ
ラクタ・スクリプトのためのシフトＪＩＳ及びＥＵＣ−
ＪＰと、韓国語キャラクタ・スクリプトのためのＫＳＣ
−５６０１と、フランス語キャラクタ及びドイツ語キャ
ラクタ等のための拡張ＡＳＣＩＩキャラクタとが挙げら
れる。

【００３６】これらの言語固有のエンコーディング形式
以外に、世界の文字言語で使用されている全てのキャラ
クタをエンコードする能力を提供するユニコード・スタ
ンダード（”汎用言語エンコーディング形式”）が存在
する。これは６５，０００個を越す数のキャラクタのコ
ード・ポイントを提供する１６ビット・エンコーディン
グを使用している。ユニコード・スクリプトは、ラテン
語、ギリシャ語、キリル文字、アルメニア語、ヘブライ
語、アラビア語、デーヴァナーガリー文字、ベンガル
語、グルムキー文字、グジャラート語、オリヤー語、タ
ミル文字、テルグ語、カナラ語、マラヤーラム語、タイ
語、ラオ語、グルジア語、チベット語、日本語仮名文
字、韓国語モダン・ハングル文字の完全なセット、及び
中国語／日本語／韓国語（ＣＪＫ）表意文字の統合セッ
トを含む。古代エティオピア語、カナダ語、音節文字、
チェロキー語、他の珍しい表意文字、シンハラ語、シリ
ア語、ビルマ語、クメール語及びブライユ点字を含む更
に多くのスクリプト及びキャラクタが間もなくこれに追
加される。

【００３７】１６ビットの単一の番号が、ユニコード・
スタンダードで定義された各コード・エレメントに対し
て割り当てられている。これらの１６ビットの番号はそ
れぞれコード値と呼ばれている。そして、テキスト内で
表す際、これらの１６ビットの番号は、接頭辞”Ｕ”に
続く１６進数のフォームでそれぞれ表記される。例え
ば、コード値のＵ＋００４１は１６進数の００４１（１
０進数の６５に等しい）である。これはユニコード・ス
タンダードにおけるキャラクタの”Ａ”を表している。

【００３８】更に、そのキャラクタのみを特定する固有
名が、各キャラクタへ割り当てられている。例えば、Ｕ
＋００４１はキャラクタ・ネームの”ラテン・キャピタ
ル・レターＡ（LATIN CAPITAL LETTER A）”を割り当て
られている。Ｕ＋０Ａ１Ｂはキャラクタ・ネームの”グ
ルムキー・レターＣＨＡ（GURMUKHI LETTER CHA）”を
割り当てられている。同一キャラクタに関しては、これ
らのユニコード・ネームはＩＳＯ／ＩＥＣ１０６４６ネ
ームと同一である。

【００３９】ユニコード・スタンダードは、キャラクタ
をスクリプトによってコード・ブロックへグループ分け
している。スクリプトは、互いに関連する複数のキャラ
クタからなる任意のシステムである。ユニコード・スタ
ンダードはソース・セット内におけるキャラクタの順番
を可能な限り維持している。スクリプトのキャラクタが
特定の順番（例：アルファベット順）で伝統的に配置さ
れている際、ユニコード・スタンダードは、これらを可
能な限り同じ順番を使用してそのコード・スペース内に
配置する。コード・ブロックのサイズは様々である。例
えば、キリル文字のコード・ブロックは２５６個のコー
ド値を超えないが、ＣＪＫコード・ブロックは何千もの
コード値を有する。

【００４０】コード・エレメントは”コードスペース”
と呼ばれるコード値の範囲全体にわたって論理的にグル
ープ分けされている。コーディングはＵ＋００００から
始められ、最初はスタンダードＡＳＣＩＩキャラクタの
コーディングを行い、ギリシア語、キリル文字、ヘブラ
イ語、アラビア語、インド語派及び他のスクリプトの順
に続き、次いで、シンボル及び句読点がこの後に続いて
いる。次いで、平仮名、カタカナ及びボポモフォ（Bopo
mofo）がコード・スペース内に続いている。統合漢字表
意文字（unified Han ideographs）の後には、モダン・
ハングル文字の完全なセットが続いている。コード値の
サロゲート・レンジは、ＵＴＦ−１６を使用した将来の
拡張のために予約されている。プライベートな用途のた
めに予約されたコード値のレンジが、コードスペースの
最後の方に配置されており、コンパチビリティ・キャラ
クタ（compatibility characters）がこれに続いて配置
されている。コンパチビリティ・キャラクタとは、初期
のスタンダードと、これらのスタンダードを使用した古
いインプリメンテーションとへのトランスコーディング
を可能にするためにのみエンコードされたキャラクタ・
バリアントのことである。

【００４１】キャラクタ・エンコーディング・スタンダ
ードは各キャラクタ及びその数値、即ち、コード・ポジ
ションのアイデンティティを定義するだけではなく、こ
の数値をビットで表現する方法も定義している。ユニコ
ード・スタンダードはＩＳＯ１０６４６トランスフォー
メーション・フォーマットに対応する少なくとも３つの
フォーム、即ち、ＵＴＦ−７、ＵＴＦ−８及びＵＴＦ−
１６を保証している。

【００４２】ＩＳＯ／ＩＥＣ１０６４６トランスフォー
メーション・フォーマットであるＵＴＦ−７、ＵＴＦ−
８及びＵＴＦ−１６は、エンコーディングをインプリメ
ンテーションで使用する実際のビットへ翻訳する実質的
な手段である。ＵＴＦ−１６は１６ビット・キャラクタ
を想定している。そして、１６ビット・キャラクタ・ペ
アを使用する何百万もの追加キャラクタへアクセスする
ために、特定の範囲のキャラクタを拡張メカニズムとし
て使用することを、ＵＴＦ−１６は可能にする。Addiso
n Wesley Longmanの１９９６年版のユニコード・スタン
ダード，バージョン２．０（The Unicode Standard, Ve
rsion 2.0）（これに関する更新情報及び追加情報はユ
ニコード・スタンダード，バージョン２．１を通じて追
加されている）は、ＩＳＯ／ＩＥＣ１０６４６に規定さ
れているこのトランスフォーメーション・フォーマット
を採用している。この文献の内容は、この開示をもって
本明細書に開示したものとする。

【００４３】第２のトランスフォーメーション・フォー
マットは、ＵＴＦ−８として知られている。これは全て
のユニコード・キャラクタをバイトの可変長エンコーデ
ィングへトランスフォームする手段である。よく知られ
たＡＳＣＩＩセットに対応するユニコード・キャラクタ
がＡＳＣＩＩと同じバイト値を最終的に有することと、
ＵＴＦ−８へトランスフォームしたユニコード・キャラ
クタを、ソフトウェアの大幅な書き直しを要することな
く多くの既存のソフトウェアと一緒に使用できることの
２つの効果を、ＵＴＦ−８は有する。ユニコード・コン
ソーシアムは、ユニコード・スタンダードをインプリメ
ントする手段としてのＵＴＦ−８の使用を保証してい
る。１６ビットのＵＴＦ−１６フォームで表記した任意
のユニコード・キャラクタは、情報を損失することなく
ＵＴＦ−８フォームへ変換し、かつ、元へ戻すことが可
能である。原理と、その原理に基づいて具体化したエン
コーディング・アーキテクチャとをスタンダードに適合
させることに関する明白な要件を、ユニコード・スタン
ダードは規定している。スタンダードに適合するインプ
リメンテーションは以下の特徴、即ち、（１）キャラク
タが１６ビット・ユニットであることと、（２）キャラ
クタをユニコード・セマンティクスによってインタプリ
トすることと、（３）割り当てられていないコードを使
用しないことと、（４）未知のキャラクタが損なわれて
いないこと、を最小限の要件として有する。

【００４４】ユニコード・キャラクタの各ＵＴＦ−８エ
ンコーディング（バイトのシーケンス）を、それに対応
する１６ビット・ユニットであるかのように扱い、さも
なければ、キャラクタをユニコード・スペシフィケーシ
ョンに基づいてインタプリトする限り、ユニコード・ス
タンダードのＵＴＦ−８インプリメンテーションはスタ
ンダードに適合している。全ての適合要件は本明細書中
に既に開示しているAddison Wesley Longmanの１９９６
年版のユニコード・スタンダード，バージョン２．０に
開示されている。７ビットのメディア／トランスポート
に効果的な７ビット・キャラクタを提供すべく、ＵＴＦ
−７は設計されている。例えば、ＲＦＣ８２２に明記さ
れている電子メールは７ビット・システムである。ＵＴ
Ｆ−１６は１６ビットのメディア／トランスポートのた
めに設計されており、ＵＴＦ−８は８ビットのメディア
／トランスポートのために設計されている。殆どのイン
ターネットは８ビット・トランスポータブルである。し
かし、７ビットを使用する遺物的なシステム（例：ＤＮ
Ｓ、ＳＭＴＰ電子メールなど）が存在する。

【００４５】２．専門用語本明細書で使用する幾つかの専門用語は当該技術分野で
一般的に使用されていない。本明細書で使用する他の幾
つかの専門用語は複数の意味を当該技術分野で有する。
したがって、以下の説明を理解する手助けとして、以下
の定義を提供する。但し、請求の範囲に開示する本発明
は、これらの定義に必ずしもとらわれない。

【００４６】言語エンコーディング形式（Linguistic e
ncoding type）…現在知られているか、または将来使用
されるキャラクタまたはグリフの任意のエンコーディン
グ形式（例：ＡＳＣＩＩまたはＢＩＧ５）。

【００４７】汎用言語エンコーディング形式（Universa
l linguistic encoding type）…キャラクタまたはグリ
フの１つを越す数のセットをそのエンコーディング内に
含む現在知られているか、または将来開発される任意の
言語エンコーディング形式。ユニコードはこの１つの例
である。ＢＩＧ５、ｉｓｏ−８８５９−１１及びＧＢ−
２３１２は別の例である。

【００４８】ディジタル表現（Digitally represente
d）…エンコーディングの結果として、キャラクタを表
現する方法（例：ビット・ストリーム内における１６進
法フォーマットなど）。

【００４９】ディジタル・シーケンス（Digital sequen
ce）…１及びゼロの特定のシーケンス、１６進法キャラ
クタの特定のシーケンス、またはディジタル表現内にお
ける他の構成要素の特定のシーケンス。

【００５０】ディジタル表現されたドメイン・ネーム
の”部分”（”Portion” of a digitally represented
domain name）…ドメイン・ネームの任意のセクション
または全体（例：トップ・レベル・ドメイン、第２レベ
ル・ドメイン、並びにトップ・レベル・ドメイン及び第
２レベル・ドメインの両方）。

【００５１】既知のディジタル・シーケンス（”Know
n” digital sequence）…関心のあるディジタル・シー
ケンスであり、このディジタル・シーケンスは特定のエ
ンコーディング形式でエンコードした一般的に使用され
ているある種のキャラクタ・コンビネーション（または
ドメイン・ネームの他のプロパティ）に関連しているこ
とが知られているので、このように呼んでいる
（例：”.com”のためのＢＩＧ５ディジタル・シーケン
ス）。

【００５２】既知のディジタル・シーケンスの”コレク
ション”（”Collection” of known digital sequence
s） …複数の既知のディジタル・シーケンスの任意の配
列または複数の既知のディジタル・シーケンス間のコネ
クション。必ずしもそうとはいえないが、一般的に、こ
れらはテーブル（例：本明細書中に開示する”マッピン
グ・テーブル”）として論理的に一緒に格納される。

【００５３】ＤＮＳエンコーディング形式（DNS encodi
ng type）…ネットワークまたはインターネットのＤＮ
Ｓプロトコルがサポートしているエンコーディング形式
（例：ＲＦＣ１０３５で指定されているＡＳＣＩＩの限
定セット）。

【００５４】非ＤＮＳエンコーディング形式（Non-DNS
encoding type）…問題のＤＮＳプロトコルがサポート
していないエンコーディング形式（例：ＲＦＣ１０３５
の下でのＢＩＧ５）。

【００５５】３．ｉＤＮＳのインプリメンテーション図１に示すように、本発明の実施形態で使用するネット
ワーク１０の幾つかの重要なコンポーネントは、クライ
アント１２と、クライアント１２が通信を望む対応する
ノード１４と、ｉＤＮＳサーバ１６と、従来のＤＮＳサ
ーバ１８とを含む。Paul Vixieが記述した一般的に使用
されているＤＮＳサーバであるバークレー・インターネ
ット・ネーム・ドメイン（Berkeley Internet Name Dom
ain、略して、”ＢＩＤＮ”と称され、その実行可能な
バージョンは”named”であり、この詳細については、h
ttp://www.isc.org/を参照のこと）を有する通常のＤＮ
Ｓサーバに代わって、ｉＤＮＳサーバ１６はマルチリン
ガル・ドメイン・ネーム・クエリーをＤＮＳポート（現
時点では、ドメイン・ネーム・ポート５３へアドレスさ
れている）で受信し得る。

【００５６】これらのコンポーネントの役割を理解する
ために、対応するノード１４を使用している香港の企業
における求人情報を問い合わせることを望む中国人学生
が、クライアント１２を使用しているものと仮定する。
この学生は前記の企業と過去に通信したことがあり、こ
の企業のドメイン・ネームを既に取得している。このド
メイン・ネームはネイティブ中国語キャラクタで提供さ
れている。クライアント１２は中国語キャラクタをタイ
プできるキーボードを有する。更に、エンコードされた
中国語キャラクタを認識し、かつ、これらの中国語キャ
ラクタをコンピュータ・スクリーン上へ正確に表示し得
るソフトウェアによって、クライアント１２は設定され
ている。

【００５７】現在、この学生は香港の企業へのメッセー
ジを作成しており、自分のレジメを同封し、かつ、デス
ティネーションとしてのドメイン・ネームを中国語でタ
イプしている。彼女が対応するノード１４へのメッセー
ジの送信をクライアント１２へ命令した際、図１に示す
システムは以下のアクションを起こす。最初に、ＤＮＳ
リクエストを介することによって、対応するノードのド
メイン・ネームをｉＤＮＳサーバ１６へ中国語で送信す
る。このドメイン・ネームが従来のＤＮＳサーバによっ
て処理できるフォーマットでないことを、ｉＤＮＳサー
バ１６は認識する。したがって、ｉＤＮＳサーバ１６は
中国語ドメイン・ネームを従来のＤＮＳサーバで使用で
きるフォーマット（通常は、ＡＳＣＩＩキャラクタの限
定セット）へ翻訳する。次いで、ｉＤＮＳサーバ１６は
翻訳された対応するノードのドメイン・ネームを使って
ＤＮＳリクエストをパッケージし直し、このリクエスト
を従来のＤＮＳサーバ１８へ送信する。そして、ＤＮＳ
リクエストで受信したドメイン・ネームのネットワーク
・アドレスを獲得するために、ＤＮＳサーバ１８は通常
のＤＮＳプロトコルを使用する。これによって得られた
ネットワーク・アドレスは対応するノード１４のネット
ワーク・アドレスである。ＤＮＳサーバ１８は従来のＤ
ＮＳプロトコルに基づいてこのネットワーク・アドレス
をパッケージし、かつ、このアドレスをｉＤＮＳサーバ
１６へ返す。そして、ｉＤＮＳサーバ１６は必要とされ
るネットワーク・アドレスをクライアント１２へ送信す
る。クライアント１２では、このネットワーク・アドレ
スは学生のメッセージに添えられる。メッセージはパケ
ット化され、各パケットはノード１４に対応するデステ
ィネーション・ネットワーク・アドレスを有する。次い
で、クライアント１２は、これらのメッセージ・パケッ
トをインターネットを通じてノード１４へ送信する。

【００５８】図２のインターアクション・プロセス・フ
ロー・チャートに示すオペレーションを検討することに
よって、このプロシージャを更に完全に理解できる。図
２に示すように、クライアント１２は図左側の垂直線に
よって表され、ｉＤＮＳサーバ１６は図中央の垂直線に
よって表され、ＤＮＳサーバ１８は図右側の垂直線によ
って表される。

【００５９】最初に、２０３において、クライアント１
２で実行中のアプリケーションは、ネットワーク・デス
ティネーションへ宛てたメッセージを形成する。このデ
スティネーションのドメイン・ネームは非ＤＮＳ互換テ
キスト・エンコーディング・フォーマット（non-DNS co
mpatible text encoding format）で入力される。した
がって、このテキストのキャラクタをディジタル表現す
る言語エンコーディング形式で、このテキストをエンコ
ードする。前記のように、実際、ＡＳＣＩＩは１つの言
語エンコーディング形式である。好ましい実施形態にお
いて、本発明は様々なエンコーディング形式を扱う。広
く使われているエンコーディング形式の幾つかの例とし
ては、ＧＢ２３１２、ＢＩＧ５、シフトＪＩＳ、ＥＵＣ
−ＪＰ、ＫＳＣ５６０１及び拡張ＡＳＣＩＩなどが挙げ
られる。

【００６０】クライアント・アプリケーションがメッセ
ージを２０３で形成した後、ドメイン・ネームをリゾル
ブするために、クライアント・オペレーティング・シス
テムはＤＮＳリクエストを２０５で形成する。このＤＮ
Ｓリクエストは殆どの点で従来のＤＮＳリクエストに似
ている。しかし、このＤＮＳリクエスト内のドメイン・
ネームは、非ＤＮＳエンコーディング・フォーマットで
提供される。クライアント・オペレーティング・システ
ムは、自身のＤＮＳリクエストをｉＤＮＳサーバ１６へ
２０７で送信する。ＤＮＳリクエストをｉＤＮＳサーバ
１６へ送信するように、クライアント・オペレーティン
グ・システムを設定し得る点に注意する必要がある。換
言するならば、クライアント１２のデフォルトＤＮＳサ
ーバは、ｉＤＮＳサーバ１６である。

【００６１】ｉＤＮＳサーバ１６はエンコードされたド
メイン・ネームをＤＮＳリクエストから引き出す。更
に、ｉＤＮＳサーバ１６は、ドメイン・ネームをＤＮＳ
互換エンコーディング・フォーマット（現時点では、Ｒ
ＦＣ１０３５で指定されている縮小セットＡＳＣＩＩ）
で提供するトランスフォームされたＤＮＳリクエストを
形成する。２０９を参照のこと。次いで、ｉＤＮＳサー
バ１６は、自身のＤＮＳリクエストを従来のＤＮＳネー
ム・サーバ１８へ送信する。２１１を参照のこと。次い
で、前記のクライアントの通信で使用されているドメイ
ン・ネームのＩＰアドレスを獲得するために、ネーム・
サーバは従来のＤＮＳプロトコルを使用する。２１３を
参照のこと。次いで、２１５において、ネーム・サーバ
はリクエストのあったＩＰアドレスをｉＤＮＳサーバへ
返す。次いで、ｉＤＮＳサーバ１６は、このＩＰアドレ
スをクライアント１２へ２１７で返す。最後に、ＩＰア
ドレスを手にしたクライアント１２は、自身の通信を意
図するデスティネーションへ送信する。２１９を参照の
こと。

【００６２】前記のように、ある時点において、ドメイ
ン・ネームを非ＤＮＳエンコーディング形式からＤＮＳ
互換エンコーディング形式へ変換する必要がある。前記
の例では、これはプロキシｉＤＮＳサーバによって達成
される。必ずしもこうである必要はない。しかし、変換
に必要なファンクショナリティとして、これをクライア
ントまたは従来のＤＮＳサーバ内で実現してもよい。

【００６３】別の実施形態では、前記のプロキシｉＤＮ
Ｓサーバが実施するファンクションの全部（または一
部）を、クライアント及び／またはＤＮＳサーバ上でイ
ンプリメントする。１つの実施形態では、エンコーディ
ング形式を検出することと、非ＤＮＳエンコーディング
されたドメイン・ネームをＤＮＳエンコーディングされ
たドメイン・ネームへ翻訳することと、デフォルト・ネ
ーム・サーバを識別することを含むオペレーション（以
下に詳述する図３のフロー・チャートのオペレーション
３０５〜３１１）を、インターネット・アプリケーショ
ン（例：マルチリンガルを可能にしたウェブ・ブラウ
ザ）上でインプリメントする。この実施形態では、ＤＮ
Ｓリゾリューション・リクエストをＤＮＳサーバへディ
スパッチする前に、コード検出及びコード変換を自動的
に実行する。幾つかの実施形態では、コード検出の必要
性を回避する手動で定義した言語エンコーディングを、
アプリケーションは提供し得る。

【００６４】別の実施形態では、オペレーション３０５
〜３１１はｉＤＮＳサーバ上でインプリメントできる。
他の実施形態はプロキシｉＤＮＳの前記の複数のオペレ
ーションの全てまたは一部をＤＮＳサーバ内にまとめる
ことを含む。例えば、幾つかのｉＤＮＳファンクション
のコードは、コンパイル可能なモジュールとしてのＢＩ
ＮＤコード内へまとめることが可能である。

【００６５】図２において、ドメイン・ネームを１つの
言語エンコーディング形式から第２の言語エンコーディ
ング形式（ＤＮＳ互換）へ変換することは、２０９で実
施される。図３に示すように、本発明の好ましい実施形
態に基づいて、この変換はプロセス３０１を通じて行い
得る。このプロセスは３０３で開始され、システムはＤ
ＮＳリクエスト内のドメイン・ネームのエンコーディン
グ形式を識別する。システムが複数の異なるエンコーデ
ィング形式に直面した際、これが必要となる。エンコー
ディング形式を識別した後、ドメイン・ネームがＤＮＳ
互換エンコーディング形式でエンコードされているか否
かを、システムは３０５で決定する。ドメイン・ネーム
が縮小セットＡＳＣＩＩエンコーディング形式でエンコ
ードされているか否かを決定することを、これは現時点
で必要とする。ドメイン・ネームが縮小セットＡＳＣＩ
Ｉエンコーディング形式でエンコードされている場合、
更なる変換は不必要であり、プロセス・コントロールは
以下に詳述する３１１へ移動する。

【００６６】この興味深いケースでは、ドメイン・ネー
ムは非ＤＮＳフォーマットでエンコードされている。ド
メイン・ネームが非ＤＮＳフォーマットでエンコードさ
れている際、プロセス・コントロールは３０７へ移動
し、システムはドメイン・ネームを汎用エンコーディン
グ形式へ翻訳する。好ましい実施形態では、この汎用エ
ンコーディング形式はユニコードである。このケースで
は、ネイティブ・エンコーディング形式で識別されたキ
ャラクタは、ユニコード・スタンダードで識別され、か
つ、これらのキャラクタのユニコード・ディジタル・シ
ーケンスへ変換される。

【００６７】次いで、新たに翻訳されたドメイン・ネー
ムは汎用エンコーディング形式からＤＮＳ互換エンコー
ディング形式へ更にトランスフォームされる。３０９を
参照のこと。したがって、この最終的なエンコーディン
グ形式は縮小セットＡＳＣＩＩとなり得る。ＤＮＳ非互
換フォーマットからＤＮＳ互換フォーマットへの翻訳
が、中間汎用エンコーディング形式を通じて２段階で行
われる点に注意する必要がある。この２段階プロシージ
ャを以下に詳述する。しかし、ＤＮＳ非互換ドメイン・
ネームをＤＮＳ互換ドメイン・ネームへ１段階で直接変
換できることを理解する必要がある。特定のエンコーデ
ィング形式をＡＳＣＩＩ（または他の未来のＤＮＳ互換
エンコーディング形式）へ変換すべくそれぞれ設計され
た複数の変換アルゴリズムを有するシステム内で、これ
を実現し得る。１つの例では、これらのアルゴリズムは
前記の”Duerstアルゴリズム”を模して作成できる。こ
れ以外の適切なアルゴリズムは周知であるか、または日
々の努力をもって開発し得る。

【００６８】ＤＮＳ互換ドメイン・ネームを手にしたシ
ステムは、ドメイン・ネームの送信先となる従来のＤＮ
Ｓネーム・サーバを決定するだけでよい。通常のＤＮＳ
プロトコルに基づき、ＤＮＳリクエストをトップ・レベ
ル・ネーム・サーバへ送信し得る。以下に詳述するよう
に、複数の異なるルート・ネーム・サーバがそれぞれ異
なる言語ドメインを処理することは効果的である。例え
ば、中国政府は中国語ドメイン・ネームのためのルート
・ネーム・サーバを維持し、日本政府または日本企業は
日本語ドメイン・ネームのためのルート・ネーム・サー
バを維持し、インド政府はヒンディー語ドメイン・ネー
ムのためのルート・ネーム・サーバを維持し得る。いず
れにしても、システムは適切なネーム・サーバを図３に
示す３１１で識別する必要がある。これを達成した後、
変換プロセスは完了し、ＤＮＳリクエストを規約に基づ
いて処理するＤＮＳシステムへ送信可能である。

【００６９】図３に示すプロセスはｉＤＮＳサーバ単独
で実施することが好ましい。しかし、プロセスの一部を
クライアントまたは従来のＤＮＳサーバで実施してもよ
い。例えば、３０３及び３０５をクライアント上で実施
し、３０９を従来のＤＮＳサーバ上で実施し得る。

【００７０】ｉＤＮＳファンクション（３２７）の好ま
しい役割分担を図４に示す。図示するように、ｉＤＮＳ
マッパ・サーバ（iDNS mapper server）３２１はオペレ
ーション３０５〜３１１を実施する。このため、ｉＤＮ
Ｓマッパ・サーバ３２１はマッピング・テーブル（この
例は図６に基づいて以下に詳述する）を有し、かつ、全
ての言語エンコーディング形式をユニコード（または他
の適切な汎用エンコーディング形式）へ変換可能であ
る。本実施形態では、クライアント３２５はオペレーシ
ョン３０３を実施し、従来のＤＮＳサーバ３２３はスタ
ンダードＤＮＳリゾルビング・プロトコル（standard D
NS resolving protocol）を実施する。

【００７１】１つのインプリメンテーションでは、ｉＤ
ＮＳマッパ・サーバ３２１を指定ポート（例：ポート番
号２０００）上のマシン（例えば、i2.i-dns.comによっ
て識別されるマシン）で実行する。ｉＤＮＳマッパ・サ
ーバ３２１は、任意の言語エンコーディング形式でディ
ジタル表現されたドメイン・ネームの部分全体を受信す
るとともに、ＤＮＳエンコーディング形式（ＵＴＦ−
５）へトランスフォームしたユニコードでディジタル表
現されたドメイン・ネームの部分全体を返す。マッピン
グ・テーブル及び変換プログラム・コードは非常に大き
く、これによって、ＤＮＳサーバ３２３のサイズを数倍
拡大する（もし、そこでインプリメントした場合）点に
注意する必要がある。オペレーション３０５〜３１１を
ＤＮＳプロトコルから分離し、かつ、独立して実行する
ことにより、ｉＤＮＳをディストリビュートするために
必要なコードの総数は減少する。

【００７２】図３の説明で述べたように、システムが複
数のエンコーディング形式を扱う必要がある際、このシ
ステムは１つのエンコーディング形式を次のエンコーデ
ィング形式と識別する能力を有する必要がある。このプ
ロセスはブロック３０３に示すとともに、図５に詳細に
示す。

【００７３】図５に示すように、エンコーディング形式
を識別するプロセス４０１は４０３で始まり、システム
はドメイン・ネームのトップ・レベル・ドメインのディ
ジタル・シーケンスを識別する。１９９９年３月に用意
できるシステムでは、トップ・レベル・ドメインは.co
m、 .edu、 .gov、 .mil、 .org、 .int、 .net及び２
文字の様々な国名称（例：.fr、.sg及び.krなど）を含
む。

【００７４】トップ・レベル・ドメインのディジタル・
シーケンスを識別した後、システムはこのシーケンスを
特定のエンコーディング形式とマッチさせる。好ましい
実施形態では、これはシーケンスをマッピング・テーブ
ル内のレコードと４０５でマッチさせることを含む。例
示的なマッピング・テーブルを以下に詳述する。ここで
は、システムが扱う様々な言語エンコーディング形式で
表記された様々なトップ・レベル・ドメインのディジタ
ル・シーケンスのリストを、テーブル（または他のロジ
カル・ストラクチャ）が含んでいるものとして単に取り
扱う。各独立レコードは関連するエンコーディング形式
識別子を更に含む。問題のディジタル・シーケンスをマ
ッピング・テーブルの複数のレコード内のシーケンスと
単に比較することによって、システムはこのディジタル
・シーケンスをマッチさせる（バイナリ・サーチ、ハッ
シュ・テーブル及びＢ−ツリーなどのスタンダード・デ
ータベース・ルック・アップ・プロシージャを使用して
行う）。一般的に、これは単一のマッチを提供する。し
かし、複数のエントリがトップ・レベル・ドメインの発
行に関する責任を有する場合（例えば、複数のエントリ
がそれぞれ異なる言語に関する責任を有する場合）、そ
れぞれ異なるエンコーディング・フォーマットで表記さ
れた２つのトップ・レベル・ドメインのディジタル・シ
ーケンスが同一になることが起こり得る。

【００７５】この可能性に取り組むために、複数のレコ
ードが問題のディジタル・シーケンスにマッチしている
か否かを、システムは４０７で決定する。複数のレコー
ドが問題のディジタル・シーケンスにマッチしていない
場合、プロセスは４１３で完了し、システムは、マッチ
する単一のレコード内で識別されたエンコーディングを
使用することを決定する。その一方、２つ以上のレコー
ドがマッチする場合、システムはこの多義性を解決する
必要がある。トップ・レベル・ドメインより下の下位ド
メイン（例：第２レベル・ドメインなどのサブ・ドメイ
ン）のディジタル・シーケンスを最初に識別することに
よって、システムはこの多義性を解決する。４０９を参
照のこと。換言するならば、問題のドメイン・ネームは
自身より下の下位ドメインに関連したディジタル・シー
ケンスを有する。この拡張したディジタル・シーケンス
を、マッピング・テーブル内のディジタル・シーケンス
と再びマッチさせる（４０５参照）。テーブルの幾つか
のレコードはトップ・レベル・ドメイン及び下位ドメイ
ンを組み合わせたディジタル・シーケンスを含み得る
（トップ・レベル・ドメインのシーケンスにおける可能
性のある多義性を解決する目的で）点に注意する必要が
ある。マッチを４０５で検出した後、前記のように、プ
ロセスは４０７へ移行する。

【００７６】別の実施形態では、トップ・レベル・ドメ
インのディジタル・シーケンスのみをマッピング・テー
ブル内で維持する。多義性を解決するための手段は、拡
張したシーケンスに対して提供されていない。このケー
スでは、肯定を示す答えが４０７で返された際（即ち、
複数のレコードがマッチする際）、システムは可能性の
ある各マッチ（候補のエンコーディング形式）を識別す
る。次いで、可能性のある各エンコーディング形式を用
いて、問題のシーケンスをデコードする。例えば、ルー
ト・ドメイン・ディジタル・シーケンスは.netのマッチ
を複数の日本語エンコーディング形式のうちの１つで検
出し、.comのマッチを複数の中国語エンコーディング形
式のうちの１つで検出し得る。

【００７７】デコードした複数のストリングのうちの１
つは、候補のエンコーディング形式の言語で理解できる
筈である。これ以外のストリングは意味不明の筈であ
る。したがって、システムは第２ドメインの最適なデコ
ーディングを提供する候補のエンコーディング形式を選
択する。次いで、プロセスは４１３で完了し、システム
は選択されたエンコーディング形式を使用する。

【００７８】図５の説明の４０５に示すように、ｉＤＮ
Ｓサーバはドメイン・ネーム・クエリーのトップ・レベ
ル・ドメインのディジタル・シーケンスを複数のエンコ
ーディング形式の既知のディジタル・シーケンスとそれ
ぞれ照合して、マッチするものを見つけ得る。マッピン
グ・テーブルは既知のディジタル・シーケンスを含み得
る。図６は本発明の１つの実施形態に基づくマッピング
・テーブル５０１を提供する。テーブル５０１内の各レ
コードは、特定のエンコーディング形式（例：ＢＩＧ５
の.com）の最小コード・リゾルビング・ストリング
（例：トップ・レベル・ドメイン）を特定している。

【００７９】図示するように、マッピング・テーブル５
０１は６つの独立したフィールドを有する。このうちの
最初のフィールドは、エントリ・キャッシュが期限切れ
になるまでの時間を特定する生存時間（time to live）
のフィールドである。次いで、最小コード・リゾルビン
グ・ストリング・フィールドはドメイン・ネームの部分
のディジタル・シーケンス（例：ＢＩＧ５での.comのデ
ィジタル・エンコーディング）を識別する。一般的に、
最小コード・リゾルビング・ストリングは８ビット・バ
イナリ・ストリングとして提供される点に注意する必要
がある。テーブル５０１内における最小コード・リゾル
ビング・ストリングのエントリ及びメインテナンスを簡
単にするために、図示するフォームを獲得すべく、トラ
ンスフォーメーションをバイナリ・ストリングへ適用し
得る。

【００８０】最小コード・リゾルビング・ストリングは
トップ・レベル・ドメインであることが多いが、必ずし
もそうである必要はない。幾つかの言語エンコーディン
グでは、多義性の問題を解決すべくストリング内のエン
コーディングのタイプをユニークにリゾルブするため
に、第２レベル・ドメインまたは更に上位のドメインを
ストリングへ含めることが必要となり得る。同様に、エ
ンコーディング形式をユニークに決定するために、トッ
プ・レベル・ドメイン全体を使用することは常に必要で
はない。これはマッチの検出速度を速める。

【００８１】テーブルに記載する”オーソリティ”と
は、レコードに示されているドメイン・ネームに対する
権限を有するエンティティのことである。このオーソリ
ティはサブ・ドメインを自身の権限で登録できる。例え
ば、”i-dns”エンティティがＢＩＧ５で表記された.co
mに対する権限を有する場合、この”i-dns”エンティテ
ィはＢＩＧ５で表記された.comの下の全てのサブ・ドメ
イン・ネームを発行する権限を有し得る。これによっ
て、固有のドメイン・ネームのみを割り当てることが保
証される。更に、ＤＮＳスペースのオーソリティの部分
におけるドメイン・ネームのＩＰアドレスを提供する”
オーソリティ”レコードを有するネーム・サーバに対す
る支配力を有するエンティティを、オーソリティは意味
する。テーブル５０１内の”エンコーディング”フィー
ルドは、レコードにマッチするドメイン・ネームのエン
コーディング形式を特定する。”トランスフォーム”フ
ィールドはドメイン・ネームの最終エンコーディングを
特定する。例えば、ＵＴＦ−５はユニコードへ適用され
たDuerstアルゴリズムである（以下に詳述）。最後
に、”コメント”フィールドは最小コード・リゾルビン
グ・ストリングに対応するドメイン・ネームの部分を識
別するテキスト・ストリングを含む。図７は中国語ドメ
イン・ネームをリゾルブするための例示的なドメイン・
ネーム・ツリーを示す。中国語エンコーディング形式を
検出するｉＤＮＳサーバは、ドメイン・ネームをリゾル
ブするデフォルト・ネーム・サーバによって設定され
る。図７に示すように、ルートの下には、複数のトップ
・レベル・ドメイン（例：.com、 .edu及び.sgなど）が
存在する。.sgトップ・レベル・ドメインの下には、ed
u.sgなどの複数の中国語第２レベル・ドメインが存在
し、その下には、nus.edu.sgを含む複数のドメインが存
在する（以下、同様に続く）。同じように、トップ・レ
ベルの.comの下には、email.comなどの複数の第２レベ
ル中国語サブ・ドメインが存在する。

【００８２】図３の実施形態の説明で述べたように、ｉ
ＤＮＳシステムはドメイン・ネームの汎用エンコーディ
ング形式（例：ユニコード）をＤＮＳエンコーディング
形式へ変換する。１つの好ましい実施形態では、前記の
Martin Duerstによる”ドメイン・ネームの国際化”と
称されるインターネット・ドラフトに定義されているト
ランスフォーメーション・アルゴリズムを使用して、こ
れは達成される。このアルゴリズムは可変長データ・エ
ンティティをＲＦＣ準拠ＡＳＣＩＩのモノケースのアル
ファベット及び数字のみからなるフォームへトランスフ
ォームする。以下の表１は、前記のインターネット・ド
ラフトに使用されているトランスフォーメーション・テ
ーブルを示す。

【００８３】

【表１】表１中の最初の２列は２進数（または１６進数）の値と
解釈される。そして、表１中の最後の２列はＡＳＣＩＩ
のＲＦＣ１０３５準拠キャラクタと解釈される。”最初
（Initial）”及び”続き（subsequent）”は、データ
・エンティティの最初のニブル（１バイトの１／２）
と、このデータ・エンティティの残りの部分とをそれぞ
れ意味する。データ・エンティティが２バイトの長さで
ある場合（ＵＣＳ−２の場合のように）、４つのニブル
がその特定のデータ・エンティティ内に存在する。

【００８４】前記のように、マルチリンガル・ドメイン
・ネームをリゾルブするために、クライアント・アプリ
ケーションはマルチリンガル非ＲＦＣ準拠クエリーをｉ
ＤＮＳプロキシ・サーバへ送信する。次いで、このプロ
キシ・サーバは、前記のクエリーをこのトランスフォー
メーション・アルゴリズムを使用してＲＦＣ準拠フォー
マットへトランスフォームし、かつ、このクエリーをＤ
ＮＳサーバへ送信する。

【００８５】ＤＮＳサーバ内には、U4B8O7E7RBB4U7BDP
1.U696R0E5OAA0U59DQ1 IN A 12.34.56.78などの有効な
ＩＰアドレスへマッピングされた前記のＲＦＣ準拠クエ
リーのエントリが存在する。

【００８６】次いで、ＲＦＣ１０３５に基づいて、ＤＮ
Ｓサーバは、このＩＰアドレスをｉＤＮＳプロキシ・サ
ーバへ返す。次いで、プロキシは、正しくリゾルブされ
たＩＰアドレスを含むメッセージをクライアントへリレ
ーする。トランスフォームされたドメイン・ネーム（Ａ
ＳＣＩＩで表記されたドメイン・ネーム）は、従来のＤ
ＮＳドメイン・ネームをコントロールし、かつ、発行す
る責任のあるオーソリティへの登録を常には必要とする
点に注意する必要がある。

【００８７】本発明の実施形態は前記のｉＤＮＳオペレ
ーションを実施する装置に関する。この装置は要求され
た目的のために特別に形成（設計）可能である。これに
代えて、この装置は、その内部に格納されたコンピュー
タ・プログラムによって選択的に駆動または再設定され
た汎用コンピュータであり得る。本明細書に開示するプ
ロセスは特定のコンピュータまたは他の装置に固有のも
のではない。特に、様々な汎用マシンを、本明細書の開
示内容に基づいて記述されたプログラムと一緒に使用で
きる。これに代えて、必要とされる方法の工程を実施す
るための更に特化された装置の形成が更に効果的なこと
もある。これらの様々なマシンに必要なストラクチャは
前記の説明から明白である。

【００８８】更に、本発明の実施形態は様々なコンピュ
ータ実行オペレーションを実施するためのプログラム命
令を含むコンピュータ読取り可能媒体に関する。この媒
体はデータ・ファイル、データ・ストラクチャ及びテー
ブルなどを単独で含むか、または前記のプログラム命令
と一緒に含み得る。前記の媒体及びプログラム命令は、
本発明の目的のために特別に設計され、かつ、形成され
たものであるか、またはコンピュータ・ソフトウェアの
技術分野の当業者がよく知っており、かつ、利用できる
ものであり得る。コンピュータ読取り可能媒体の例は、
ハード・ディスク、フロッピー・ディスク及び磁気テー
プなどの磁気媒体と、ＣＤ−ＲＯＭディスクなどの光媒
体と、フロプティカル・ディスクなどの光磁気媒体と、
リード・オンリ・メモリ・デバイス（ＲＯＭ）及びラン
ダム・アクセス・メモリ（ＲＡＭ）などのプログラム命
令を格納し、かつ、実行するために特別に形成されたハ
ードウェア・デバイスとを含む。更に、この媒体は、プ
ログラム命令及びデータ・ストラクチャなどを特定する
信号を伝送する搬送波を有するオプティカル・ライン、
メタル・ラインまたはウェーブ・ガイドなどの伝送媒体
であり得る。プログラム命令の例は、コンパイラなどに
よって形成されたマシン・コードと、コンピュータがイ
ンタプリタを使用して実行し得る更に高いレベルのコー
ドを有するファイルとを含む。

【００８９】図８は本発明の実施形態に基づく一般的な
コンピュータ・システムを示す。コンピュータ・システ
ム７００は任意の数のプロセッサ７０２（中央処理装
置、即ち、ＣＰＵとも称される）を有する。プロセッサ
７０２は、一次ストレージ（Ａ）７０６（一般的には、
ランダム・アクセス・メモリ、即ち、”ＲＡＭ”）及び
別の一次ストレージ７０４（ｂ）（一般的には、リード
・オンリ・メモリ、即ち、”ＲＯＭ”）を含むストレー
ジ・デバイスへ接続されている。当該技術分野で知られ
ているように、一次ストレージ（ｂ）７０４はデータ及
び命令を単方向でＣＰＵへ転送すべく機能する。その一
方、一次ストレージ（Ａ）７０６はデータ及び命令を両
方向で転送すべく一般的に使用される。これら２つの一
次ストレージ・デバイスは前記の任意の適切なコンピュ
ータ読取り可能媒体を含み得る。大容量ストレージ・デ
バイス７０８はＣＰＵ７０２へ両方向で接続され、か
つ、別のデータ・ストレージ能力を提供する。更に、大
容量ストレージ・デバイス７０８は前記の任意のコンピ
ュータ読取り可能媒体を含み得る。大容量ストレージ・
デバイス７０８はプログラム及びデータなどを格納する
ために使用可能であり、かつ、一般的には、一次ストレ
ージより遅いハード・ディスクなどの二次ストレージ媒
体である。適切なケースでは、大容量ストレージ・デバ
イス７０８内に保持されている情報は、バーチャル・メ
モリとして一次ストレージ７０６（Ａ）の一部にスタン
ダードな様式で組み込み得る。ＣＤ−ＲＯＭ７１４など
の特定の大容量ストレージ・デバイスは、データを単方
向でＣＰＵへ転送する。

【００９０】ＣＰＵ７０２は１つ以上の入出力装置を含
むインターフェース７１０へ接続されている。入出力装
置の例としては、ビデオ・モニタ、トラック・ボール、
マウス、キーボード、マイクロホン、タッチ・ディスプ
レイ、トランスデューサ・カード・リーダー、磁気テー
プ・リーダー、ペーパー・テープ・リーダー、タブレッ
ト、スタイラス、音声認識装置、手書き文字認識装置、
または他の周知の入力装置（他のコンピュータなど）が
挙げられる。符号７１２で示すように、ネットワーク・
コネクションを使用することにより、ＣＰＵ７０２をコ
ンピュータまたはテレコミュニケーション・ネットワー
クへ任意で接続できる。このネットワーク・コネクショ
ンにより、前記の方法の工程を実施する過程で、ＣＰＵ
は情報をネットワークから受信し、かつ、情報をネット
ワークへ出力し得る。前記のデバイス及びマテリアルは
コンピュータ・ハードウェア及びソフトウェアの分野の
当業者にはよく知られている。

【００９１】前記のハードウェア・エレメントは、本発
明のオペレーションを実施するための１つ以上のソフト
ウェア・モジュールとして機能すべく設定可能（一般的
には、一時的に設定可能）である。例えば、エンコーデ
ィング形式を検出するための命令、このエンコーディン
グ形式をトランスフォームするための命令及びデフォル
ト・ネーム・サーバを識別するための命令を、大容量ス
トレージ・デバイス７０８または７１４へ格納し、か
つ、一次メモリ７０６に関連してＣＰＵ７０８で実行で
きる。

【００９２】以上、理解を容易にする目的で、本発明を
ある程度詳しく説明したが、特定の変更及び修正を本発
明の請求の範囲内で実施しても良い。

【００９３】

【発明の効果】以上詳述したように、この発明によれ
ば、ユーザが非ユニコード・エンコーディング及び非Ａ
ＳＣＩＩエンコーディングで表記されたドメイン・ネー
ムを使用することを可能にするという優れた効果を発揮
する。

【図面の簡単な説明】

【図１】ＤＮＳサーバ及びクライアントの間に配置され
たｉＤＮＳサーバを含むネットワーク・アーキテクチャ
の概略図である。

【図２】本発明の１つの実施形態に基づく非ＤＮＳエン
コーディング形式で表記されたドメイン・ネームを提供
するＤＮＳリクエストのリゾリューションのプロセスを
示すフロー・チャートである。

【図３】非ＤＮＳエンコーディング形式で表記されたド
メイン・ネームをＤＮＳエンコーディング形式で表記さ
れた対応するドメイン・ネームへ変換するためのプロセ
スを示すフロー・チャートである。

【図４】ＤＮＳシステムのロジカル・コンポーネントを
示す図である。

【図５】ドメイン・ネームのエンコーディング形式を決
定するプロセスを示すフロー・チャートである。

【図６】本発明の１つの実施形態に基づくドメイン・ネ
ームのエンコーディング形式を識別するために使用する
ロジカル・マッピング・テーブルを示す図である。

【図７】中国語エンコーディングの階層を示す”ツリ
ー”の図である。

【図８】本発明のｉＤＮＳファンクションをインプリメ
ントするために使用できる汎用コンピュータ・システム
のブロック図である。

【符号の説明】

１０…ネットワーク１２…クライアント１４…対応するノード１６…ｉＤＮＳサーバ１８…従来のＤＮＳサーバ３２１…ｉＤＮＳマッパ・サーバ３２３…従来のＤＮＳサーバ３２５…クライアント３２７…ｉＤＮＳ７００…コンピュータ・システム７０２…プロセッサ７０４…一次ストレージ（ｂ）７０６…一次ストレージ（Ａ）７０８…大容量ストレージ・デバイス７１０…インターフェース７１２…ネットワーク・コネクション７１４…ＣＤ−ＲＯＭ

───────────────────────────────────────────────────── フロントページの続き (72)発明者ティン・ウィー・タンシンガポール共和国エス（309426）＃01−01，デュニアン・ロード，ブロック36エー (72)発明者チング・ホング・セングマレーシア国ジョホール州，ジョホールバル，タマン・イスカンダル 80050, ジャラン・イナング・デュア，150 (72)発明者ジュエイ・クワング・タンシンガポール共和国エス（520720）＃07−27，タムパインズ・ストリート, 72，ブロック720 (72)発明者コク・ヨング・レオングシンガポール共和国エス（310047）＃08−140，トア・ペイヨー・ロード, ６，ブロック47 (72)発明者ドン・アーウィン・トレイシー・デ・シルバシンガポール共和国エス（509726）＃04−02，フロラ・ロード，ブロック４ (72)発明者クアン・シオング・リムシンガポール共和国エス（120601）＃06−06，クレメンティ・ウエスト・ストリート，１，ブロック601 (72)発明者エドワード・エス．・テイシンガポール共和国エス（530317）＃11−45，ヒューギャング・アベニュー，７，ブロック317 (72)発明者サブラマニアン・サビアアメリカ合衆国カリフォルニア州 94025 メンロ・パーク，エルム・ストリート，102 (56)参考文献特表2002−523835（ＪＰ，Ａ) 国際公開00／050966（ＷＯ，Ａ１) ｄｒａｆｔ−ｉｅｔｆ−ｄｎｓｉｎｄ −ｄｅｎｓ−02．ｔｘｔｄｒａｆｔ−ｄｎｓｉｎｄ−ｅｄｎｓ０−01．ｔｘｔｄｒａｆｔ−ｄｎｓｉｎｄ−ｅｄｎｓ１−02．ｔｘｔｄｒａｆｔ−ｄｕｅｒｓｔ−ｄｎｓ− ｉ18ｎ−02．ｔｘｔｄｒａｆｔ−ｈａｌｌ−ｄｍ−ｉｄｎｓ−00．ｔｘｔＪａｍｅｓＳｅｎｇ，ＩｎｔｅｒｎａｔｉｏｎａｌｉｚｅｄＤＮＳ (58)調査した分野(Int.Cl.⁷，ＤＢ名) H04L 12/56 G06F 12/00 545

Claims

(57)【特許請求の範囲】

【請求項１】ディジタル表現されたドメイン・ネーム
の言語エンコーディング形式を検出するために装置上で
インプリメントされる方法であって、前記ディジタル表現されたドメイン・ネームの所定部分
のディジタル・シーケンスを受信する工程と、前記ドメイン・ネームから得られたディジタル・シーケ
ンスを、既知のディジタル・シーケンスのコレクション
から得られた既知のディジタル・シーケンスとマッチさ
せる工程であって、前記既知のディジタル・シーケンス
は特定の言語エンコーディング形式にそれぞれ関連して
おり、前記コレクションは少なくとも２つの異なる言語
エンコーディング形式の既知のディジタル・シーケンス
を含む工程と、前記ドメイン・ネームから得られたディジタル・シーケ
ンスにマッチする前記既知のディジタル・シーケンスに
関連するエンコーディング形式を識別する工程と、前記ドメイン・ネームのディジタル・シーケンスを前記
識別されたエンコーディング形式からＡＳＣＩＩ形式へ
と変換する工程と、ＤＮＳリクエストをＤＮＳサーバに送出する工程とを含
む方法。
【請求項２】前記ディジタル表現されたドメイン・ネ
ームを含むＤＮＳリクエストを受信する工程を更に含む
請求項１に記載の方法。
【請求項３】前記既知のディジタル・シーケンスのコ
レクションは、テーブル内に提供されており、前記テー
ブルは属性を有するレコードを含み、前記属性は既知の
ディジタル・シーケンス及びエンコーディング形式を含
む請求項１または２に記載の方法。
【請求項４】前記テーブルは、少なくとも以下のエン
コーディング形式、即ち、ＡＳＣＩＩ、ＢＩＧ５、ＧＢ
２３１２、シフトＪＩＳ、ＥＵＣ−ＪＰ、ＫＳＣ５６０
１及び拡張ＡＳＣＩＩを有するレコードを含む請求項３
に記載の方法。
【請求項５】前記エンコーディング形式を識別する工
程は、マッチする既知のディジタル・シーケンスを有す
るレコードのエンコーディング形式を識別する工程を含
む請求項３に記載の方法。
【請求項６】少なくとも２つの既知のディジタル・シ
ーケンスが、前記ドメイン・ネームから得られたディジ
タル・シーケンスとマッチする請求項１ないし５のいず
れか一項に記載の方法であって、前記ディジタル表現されたドメイン・ネームの第２部分
のディジタル・シーケンスを受信する工程と、前記第２部分のディジタル・シーケンスを、前記既知の
ディジタル・シーケンスのコレクションから得られた既
知のディジタル・シーケンスとマッチさせる工程とを更
に含む方法。
【請求項７】コンピュータ・プログラム製品であっ
て、請求項１ないし請求項６のいずれかに記載されたディジ
タル表現されたドメイン・ネームの言語エンコーディン
グ形式を検出する方法を、実施するためのプログラム命
令が格納されているマシン読取り可能媒体を含むコンピ
ュータ・プログラム製品。
【請求項８】１つ以上のプロセッサと、前記１つ以上のプロセッサのうちの少なくとも１つに接
続されたメモリと、非ＤＮＳエンコーディング形式で表記されたドメイン・
ネームを含む第１ＤＮＳリクエストを受信し得ると共
に、ＡＳＣＩＩ形式で表記されたドメイン・ネームを含
むＤＮＳリクエストを送信し得る１つ以上のネットワー
ク・インターフェースとを有する装置であって、前記１
つ以上のプロセッサのうちの少なくとも１つは、（１）
前記非ＤＮＳエンコーディング形式で表記された前記ド
メイン・ネームから得られたディジタル・シーケンス
を、特定の言語エンコーディング形式にそれぞれ関連付
けられている既知のディジタル・シーケンスのコレクシ
ョンから得られた既知のディジタル・シーケンスとマッ
チさせ、また前記コレクションは少なくとも２つの異な
る言語エンコーディング形式の既知のディジタル・シー
ケンスを含んでおり、（２）前記ドメイン・ネームから
得られたディジタル・シーケンスにマッチする前記既知
のディジタル・シーケンスに関連するエンコーディング
形式を識別し、そして（３）前記非ＤＮＳエンコーディ
ング形式で表記された前記ドメイン・ネームを、ＡＳＣ
ＩＩ形式へ変換するために設計または形成されている装
置。