(57)【要約】本発明は特殊キャラクタを含むインターネットアドレスを提供するための方法に関する。コンピュータからのユーザによるインターネットアドレスの呼び出しの際に、第１のドメインネームサーバ（ＤＮＳ）がコンタクトされる。これに少なくとも１つの更に別のＤＮＳが割り当てられ、この少なくとも１つの更に別のＤＮＳにおいて第１のＤＮＳによっては識別できない又は部分的にしか識別できないインターネットプロトコルアドレスが転送され、ここでシーケンシャルな比較処理の評価のもとの復号され、周知の数字鍵（ＩＰアドレス）としてユーザに返送される。
2004529539.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータネットワーク（インターネット）において特殊キャラクタを含むインターネットアドレス（ドメイン）を提供するための方法であって、
ドメインはユーザによる呼び出しの際にまず最初にキャラクタコードに変換され、該キャラクタコードは第１のドメインネームサーバ（ＤＮＳ）（１）に伝送され、前記キャラクタコードが前記第１のＤＮＳ（１）によって識別され得ない場合にはこのキャラクタコードは前記第１のＤＮＳ（１）から少なくとも１つの更に別のＤＮＳ（５）に転送され、この少なくとも１つの更に別のＤＮＳ（５）において前記キャラクタコードがシーケンシャルな比較処理の評価の下で復号され、前記キャラクタコードが前記第１のＤＮＳ（１）によって部分的に復号される場合には、識別された部分鍵に基づいて少なくとも１つの更に別のＤＮＳ（３〜５）とコンタクトを取り、該少なくとも１つの更に別のＤＮＳ（３〜５）は更に別の復号を行い、次いで前記キャラクタコードに周知の数字鍵（ＩＰアドレス）が割り当てられ、これが前記ユーザに返送される、コンピュータネットワーク（インターネット）において特殊キャラクタを含むインターネットアドレス（ドメイン）を提供するための方法において、
前記シーケンシャルな比較処理は割り当てテーブルに基づいて異なるブラウザ及び/又はリゾルバによって生成されるキャラクタコードに対する鍵を識別することを特徴とする、コンピュータネットワーク（インターネット）において特殊キャラクタを含むインターネットアドレス（ドメイン）を提供するための方法。
【請求項２】
所定の期間内にＤＮＳに送信される非コンベンショナルなキャラクタコードがＩＰアドレスの正しい要求と認められて記憶され、アルゴリズムを介して記憶されたキャラクタコードにおいて反復される非コンベンショナルな構成部分がもとめられ、類別化され、次いで同一の又は類似の構成部分を有する前記類別化されたキャラクタコードの構成部分がシーケンシャルな比較処理において使用されることを特徴とする、とりわけ請求項１記載の方法。
【請求項３】
コード構成部分の類別化は以下の規準、すなわち、
ａ）キャラクタコードの構成部分がリクエスタのアプリケーションプログラム、とりわけブラウザ及び/又はリゾルバに割り当てられるかどうかの検査、
ｂ）キャラクタコードに影響を与えるアプリケーションプログラムの所定のキャラクタセットが前記キャラクタコードの非コンベンショナルな構成部分の原因であるかどうかの検査、
ｃ）キャラクタコードに影響を与えるアプリケーションプログラムの所定のパラメータが前記キャラクタコードの非コンベンショナルな構成部分の原因であるかどうかの検査、
ｄ）キャラクタコードに影響を与えるオペレーティングシステムがホスト/リクエスタにおいて使用されるかどうかの検査、
ｅ）キャラクタコードに影響を与える入力位置及び/又は伝送路が前記キャラクタコードの非コンベンショナルな構成部分の原因であるかどうかの検査
のうちの１つ又は複数に関して行われる、請求項２記載の方法。
【請求項４】
類別化の結果がＤＮＳの割り当てテーブルの自動的な更新のための基礎として使用される、請求項２又は３記載の方法。
【請求項５】
ＤＮＳ（１〜５）によって受信されるキャラクタコードは使用される特殊キャラクタに関してフィルタリングされ、専ら前記キャラクタコードで利用される標準キャラクタ、とりわけ英数字のキャラクタ”Ａ“から”Ｚ“まで、”０“から”９“まで及び”−“が割り当てテーブルの後続のシーケンシャルな比較処理の基礎とされる、請求項１記載の方法。
【請求項６】
割り当てテーブルのＩＰアドレスへのフィルタリングされたキャラクタコードの一意的に可能な割り当てにおいて、この割り当てが行われ、前記ＩＰアドレスがリクエスタに伝達されることを特徴とする、請求項５記載の方法。
【請求項７】
フィルタリングされたキャラクタコードの一意的な割り当てにおいて、フィルタリングされないキャラクタコードがＤＮＳに受け入れられることを特徴とする、請求項６記載の方法。
【請求項８】
割り当てテーブルの各ＩＰアドレスには可変的な価値が割り当てられることを特徴とする、請求項１〜７のうちの１項記載の方法。
【請求項９】
割り当てテーブルのＩＰアドレスの呼び出しの頻度が記録され、前記ＩＰアドレスには呼び出し頻度に相応する価値が割り当てられることを特徴とする、請求項８記載の方法。
【請求項１０】
割り当てテーブルのＩＰアドレスへのフィルタリングされたキャラクタコードの一意的には可能ではない割り当てにおいて、リクエスタには全ての考慮の対象となる割り当てがオンライン選択のために伝達されることを特徴とする、請求項５記載の方法。
【請求項１１】
ＤＮＳでは、考慮の対象となる割り当てがそれらの価値の順番で記載されることを特徴とする、請求項１０記載の方法。
【請求項１２】
ＩＰアドレスへのフィルタリングされたキャラクタコードの一意的には可能ではない割り当てにおいて、このキャラクタコードには最高の価値を有するＩＰアドレスが割り当てられることを特徴とする、請求項８記載の方法。
【請求項１３】
可能な割り当ての個数に依存して、所定の個数及び/又は価値の差を上回る場合に自動的に請求項８〜１２までに記述された構成のうちの１つが実施されることを特徴とする、請求項８〜１２のうちの１項記載の方法。
【請求項１４】
シーケンシャルな比較処理及び/又は類別によって割り当てることができないキャラクタコードはエラーリストに手動的な後処理のために供給されることを特徴とする、請求項１〜１３のうちの１項記載の方法。
【請求項１５】
キャラクタコードはＤＮＳによるその割り当ての後でリクエスタのキャッシュに中間記憶されることを特徴とする、請求項１〜１４のうちの１項記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータネットワーク（インターネット）において特殊キャラクタを含むインターネットアドレス（ドメイン）を提供するための方法に関する。
【０００２】
インターネットアドレスの選択において、ブラウザにおいて識別子ｈｔｔｐ：／／の後ろにそれぞれのインターネットアドレスが、文字、数字、ハイフン等々の形式でいわゆるＡＳＣＩＩ（American Standard Code for
Information Interchange）のサブセットにおいて入力される。アドレスはインターネットに存在するドメインネームサーバ（ＤＮＳ）によって数字鍵、いわゆるＩＰアドレス（インターネットプロトコルアドレス）に変換され、コンタクトルーチンが開始される。
【０００３】
【数１】
2004529539.tif 000003
【０００４】
コンピュータネットワークでは多数のコンピュータが一つに結びつけられる。これらのコンピュータの各々はネットワーク内で一意的に識別できなければならない。今日の最大のネットワーク、すなわちインターネットでは、個々のコンピュータ（ホスト）はいわゆるＩＰアドレスによって一意的に識別される。
【０００５】
人間には多数のホストＩＰアドレスを覚えておくことは難しいので、ＩＰアドレスにドメインネームを割り当てるシステムが導入された。このシステムはドメインネームシステムと呼ばれる。いわゆるドメインネームサーバ（ＤＮＳ）はドメインネームのＩＰアドレスへの割り当てに関する情報を提供する。ドメインネームシステム内ではいくつかの取り決めがドメインネームに関して定められている。すなわち、ラベルは文字で始まり、文字又は数字で終わり、その間に文字か、数字か、ハイフンかのいずれかを有する。例えばｗｗｗ．ｍｕｅｌｌｅｒ．ｄｅ、ｗｗｗ．ｂｏｃｈｕｍ．ｄｅ、ｗｗｗ．ｅｕ．ｃｏｍ又はｗｗｗ．ｓｍｓ．ｔ−ｏｎｌｉｎｅ．ｄｅである。
【０００６】
ドメインネーム空間はツリー状の構造として作られている。根（ルート）から始まって“ｄｅ”、“ｃｏｍ”又は“ｏｒｇ”のようなふつうのトップレベルドメイン（ｇＴＬＤｓ）がつづく。これらは更なるサブドメインに分割される。図１は、サブドメイン“ｕｓ”及び“ｅｕ”を有するトップレベルドメイン“ｃｏｍ”の小さな一部を示す。最後にツリーのリーフが個々のネットワークリソース（大抵の場合ホスト又はルータ）を識別する。図１では例えば“ｗｗｗ”又は“ｍａｉｌ”である。
【０００７】
ドメインネーム空間のＤＮＳは、ドメインネーム空間ツリーの結節点及び全てのその下にある枝を含むゾーンを管理する。ツリーの異なるレベルにおけるネームサーバの存在によって異なるＤＮＳのゾーンが互いにオーバーラップする。ＤＮＳはそれぞれ自分の次に高いＤＮＳ及び自分の次に低いＤＮＳを知っている。
【０００８】
ＤＮＳの主な任務は、ＩＰアドレスをドメインネームに割り当てること及びその逆である。ユーザプログラム（例えばブラウザ）はこのような問い合わせ（クエリ）を自分自身では実装してはならない。大抵のオペレーティングシステムはこのサービスを統合している。ユーザプログラムはオペレーティングシステム呼び出しの助けによって情報を手に入れることができる。ＤＮＳへの実際のクエリはリゾルバが引き受ける。パフォーマンス向上のために全てのリゾルバはローカルキャッシュ（バッファメモリ）を自由に使用し、これにより多重問い合わせに比較的迅速に答えられる。図２にはこのような標準問い合わせが示されている：
標準ＤＮＳ問い合わせの経過は次のようなものである：
（１）ユーザプログラムはドメインネームを有し、これに所属するＩＰアドレスをもとめたい。
（２ａ）ユーザプログラムは問い合わせをリゾルバに送り、このリゾルバから応答を待つ。
【０００９】
リゾルバは解答がすでにキャッシュに存在するかどうかを検査し、存在する場合にはこの解答を返送する。
（２ｂ）解答がキャッシュにまだ存在しない場合には、リゾルバは自分からクエリをＤＮＳに送る。
（３）ＤＮＳはリゾルバに所望の解答を返送する。
（４）リゾルバはこの解答を自分のキャッシュにコピーし、これを同時にユーザプログラムに送る。
【００１０】
しかし、最初の問い合わせを受けたＤＮＳがリゾルバによって提出されたクエリに対する解答を供給できないこともあり得る。この場合には２つの方法がある。
【００１１】
最初の問い合わせを受けたＤＮＳが自分でクエリに応答することができる更に別のＤＮＳを探す。この場合、リゾルバにおいては何も変わらず、このリゾルバは単に「自分の」ＤＮＳから応答を得るまで待つ。この種のクエリは「リカーシブ」と呼ばれる。リカーシブな問い合わせは図３に図示されている。
【００１２】
リカーシブＤＮＳ問い合わせの経過は次のようなものである：
（１）リゾルバから所定のＤＮＳにクエリが送られる。このクエリには、このクエリは「リカーシブに」実施されるべきであるという情報も含まれている。
（２）最初の問い合わせを受けたＤＮＳがクエリに対する解答を知らない場合、このＤＮＳは解答を供給できそうな他のＤＮＳにこのクエリを転送する。
（３）このＤＮＳも解答を知らない場合には、このＤＮＳはこのことを返信し、さらに解答を知っていそうなＤＮＳを知っているかどうかを報告する。このプロセスが複数回繰り返される。
（４）最後に最初のＤＮＳが解答を知っているＤＮＳに到達する。大抵の場合、これはいわゆるオーソリテイティブネームサーバ（Authoritative Name Server）である。
（５）クエリに対する応答がリゾルバに返送される。
【００１３】
最初のＤＮＳがリゾルバにそのクエリに対してなんら結論を供給できない場合には、他のＤＮＳが提案され、この他のＤＮＳにリゾルバは改めてクエリを依頼しなければならない。このシナリオは、リゾルバが最終的に解答を供給することができるＤＮＳに問い合わせるまで何回も繰り返される。これは図４に図示されている。
【００１４】
ＷＯ００/５６０３５はドメインの国際化のための方法を論じている。この場合、中間プログラムが使用され、この中間プログラムは各ブラウザによってダウンロードされなければならない。このプログラムはドメインからＡＳＣＩＩキャラクタ列を生成し、これを転送する。これがドメインネームサーバ（ＤＮＳ）によって識別されるためには、キャラクタ列がそこに記録されていなければならない。特殊キャラクタを含むインターネットアドレスを記録するために、これがユニコードシステムに入力され、ローマ字に変換される。この変換はＲＡＣＥと呼ばれ、これは行ベースのＡＳＣＩＩコンパチプルエンコーディングの例である。従って、ＤＮＳによって識別されるために、ドメインはＤＮＳにおいてＡＳＣＩＩコードで、例えばｂｑ-ｂｈａｓｕｔｒ．ｃｏｍとして記録されなければならない。従って、このような特殊キャラクタを含むドメインを世界中で許可するためには、全ＤＮＳの変更が必要であるだろう。さらに、この場合、全ての問い合わせは最初に検査のためにハイパフォーマンスなｉＤＮＳサーバに転送されなければならない。なぜなら、さもなければ、その下位にある従来のＤＮＳに対する変換が行われないからである。
【００１５】
ＷＯ００/５０９６６からはコンピュータネットワークに中間サーバを設ける提案が喚起されている。この中間サーバは全ての問い合わせを受理し、ＤＮＳルートサーバに翻訳して転送する。この場合、先に記述したやり方に類似の識別が行われなければならない。ＩＰアドレスは中間サーバに返送され、この中間サーバは次いでユーザに返信を行う。同様の解決方法はＷＯ９９/４０５１１から公知である。
【００１６】
全ての上記の引用した解決案の共通点は、特殊キャラクタがドメインネームにおいて解決され許可されるために、既存のシステム、すなわちネットワーク要素における変更がブラウザに対して付加モジュールの形で必要である点、又は、特殊キャラクタによって負荷を受けないＤＮＳの変更が必要不可欠である点である。
【００１７】
本発明の課題は、特殊キャラクタを含むドメインネームの使用のためのより簡単かつ経済的な解決策を提供することであり、この解決策は即座に非特殊キャラクタドメインのための今日のＤＮＳサーバ構造を保持しつつ使用可能である。
【００１８】
上記課題は、請求項１記載の方法によって解決される。
【００１９】
本発明によれば、特殊キャラクタを含むインターネットアドレスを提供するための方法がコンピュータネットワークにおいて設けられ、ドメインはユーザによる呼び出しの際にまず最初に既存のリゾルバによってキャラクタコードに変換される。このキャラクタコードは最初のＤＮＳ、いわゆるルートサーバに伝送される。変換されたキャラクタコードは２値又は１６値キャラクタ列である。キャラクタコードが最初のＤＮＳによって識別されない場合、これは少なくとも１つの更に別のＤＮＳに転送され、この更に別のＤＮＳにおいてシーケンシャルな比較処理によってこのキャラクタコードに相応する既知の数字鍵（ＩＰアドレス）がもとめられ、これがユーザに返送される。
【００２０】
キャラクタコードが最初のＤＮＳによって部分的に復号される場合には、次いで識別された部分鍵に基づいて更に別のＤＮＳにコンタクトがとられ、この更に別のＤＮＳが更なる復号を行う。この順番で更に別のＤＮＳにコンタクトがとられ、呼び出されたインターネットアドレスの完全な復号が行われて最後にＩＰアドレスとしてユーザに伝送されるまでこれが行われる。
【００２１】
【数２】
2004529539.tif 000004
【００２２】
このナンセンスな数列は、ＤＮＳにおいてシーケンシャルな比較処理で復号され、この場合非コンベンショナルな質問として数列からなるコンベンショナルな解答に変換される。つまり、このキャラクタコードにシーケンシャルな比較処理に基づいて正しいＩＰアドレスが割り当てられ、ユーザに返送される。ユーザは次いでユーザが所望するインターネットページに到達する。
【００２３】
図５に基づいて特殊キャラクタ利用を有する本発明のドメインネーム解決及び未知の特殊キャラクタ乃至はコーディングの識別を説明する。
【００２４】
【数３】
2004529539.tif 000005
【００２５】
特殊キャラクタを有するドメインとしては、領域“Ａ/ａ”から“Ｚ/ｚ”まで、“０”から“９”まで及びトレマ“．、-、＠”以外のキャラクタを有するドメインである。たとえＡＳＣＩＩ領域“Ａ/ａ”から“Ｚ/ｚ”まで乃至は“０”から“９”までに含まれていても、オリジナルブラウザ、すなわちリクエスタにおいて万国共通記号として示されなかった場合には、どんな万国共通記号も特殊キャラクタと見なされる。
【００２６】
シーケンシャルな比較処理は、本発明によれば様々なブラウザ/リゾルバプログラムにより生成されるキャラクタコードに対する鍵を含む割り当てテーブルに基づいて行われる。これは、割り当てテーブルを連続的に経過してそこに格納されたシーケンスがユーザのブラウザ/リゾルバにより生成されるキャラクタコードと比較されることによって、行われる。
【００２７】
ブラウザ乃至はリゾルバは同じ特殊キャラクタを含むドメインを互いに異なる単一キャラクタ列又は複数キャラクタ列に変換するので、このような単一キャラクタ列又は複数キャラクタ列を含むキャラクタコードはこれまで使用されてきたＤＮＳによっては識別されなかった。この場合、本発明の重要な利点は、特殊キャラクタに対して、今や生成されたキャラクタのバイト毎の割り当て又はセグメント化が必要ではなく、むしろドメイン乃至は特殊キャラクタを含むドメインのキャラクタコードがまるごと、つまり全長においてシーケンシャルな比較処理によって識別されることである。割り当てテーブルに今や直接様々なブラウザ及び/又はリゾルバにより生成されたキャラクタコードがまるごと記述されていることによって、このようなドメインがちょうど従来の取り決めに相応するドメインのように識別され、ドメインネームサーバチェーンにおいて考慮される。
【００２８】
更に別の利点は、実際に特殊キャラクタがドメインに存在している場合には、シーケンシャルな比較処理によって特殊キャラクタを有するドメインを解決するＤＮＳが単に呼び出されるだけであることである。これによって、特殊キャラクタを有するドメインを解決するＤＮＳは負荷を軽減される。
【００２９】
本発明の方法がＤＮＳにおいて使用され、このＤＮＳが特殊キャラクタを復号できない場合には、ドメインネームサーバのプロバイダよりエラーメッセージが出力され、エラーリストに記入される。このエラーリストに基づいてプロバイダはまだ正しくコーディングされていない正確な入力を手動で選別し、場合によってはＤＮＳの割り当てテーブルに保存しなければならないだろう。
【００３０】
割り当てテーブルへのドメインの正確なエントリの検出は個々のメーカーのブラウザのフィールド“ｈｔｔｐ：／／．．．．”における手動テクスト入力によって実現された。次いで、どのようなキャラクタコードをブラウザが転送するのか及びどのようなＩＰアドレスがこのキャラクタコードに相応するのかが検査された。次いで、キャラクタコードの正しいＩＰアドレスへの手動割り当てが行われ、キャラクタコードはＤＮＳの割り当てテーブルに記入される。このことは典型的なブラウザファミリー毎に乃至はオペレーティングシステム毎に行われなければならず、この結果、これから少なくとも１つの付加的なエントリが又は最も不利な場合には典型的なブラウザファミリー毎に乃至はオペレーティングシステム毎に付加的なエントリがＤＮＳの割り当てテーブルにおいて行われなければならなかった。この手動による方法は特許請求項２の構成によって記述されているように自動化された方法によって大幅に改良される。従って、これらの構成に対して独立的な保護が要請される。
【００３１】
この場合、基本的な目的は、明らかな非識別エラーを可能な新しいキャラクタコードとして及び/又は新しい未知のブラウザ乃至はドメインネーム問い合わせとして識別し、場合によっては自動的に補正エントリをＤＮＳの割り当てテーブルに挿入するという要求によって、エラーリストを時間遅延して又はオンラインで処理することである。これによって、同一のリクエスタの将来の問い合わせが正確に解決され、つまり正しいＩＰアドレスが割り当てられ、返送されることが実現されるはずである。
【００３２】
特許請求項２の特徴部分記載の構成によれば、この場合、所定の期間内にＤＮＳに送信される非コンベンショナルなキャラクタコードがＩＰアドレスの正しい要求と見なされ、記憶され、アルゴリズムを介して記憶されたキャラクタコードにおいて反復する非コンベンショナルな構成部分がもとめられ、類別される。次いで、キャラクタコードの類別された構成部分が、シーケンシャルな比較処理での同一の又は類似の構成部材によるキャラクタコードの識別のための基礎として使用される。
【００３３】
所定の時間窓の中で及び非コンベンショナルなキャラクタコードがＩＰアドレスの正しい要求と見なされ得るという仮説の中で非コンベンショナルな、つまり従来の取り決めに相応しないキャラクタコードを収集することによって、これらのデータセットを所期の通りにアルゴリズムによって解析し、とりわけ反復する非コンベンショナルな構成部分をもとめ、さらにこれらを類別するという方法が存在する。
【００３４】
この場合、コード構成部分の類別は特許請求項３に記載された規準のうちの１つ又は複数によって行われる。まず最初に、この場合、キャラクタコードの構成部分をホストのアプリケーションプログラム、とりわけブラウザ及び/又はリゾルバに割り当てることができるかどうかが検査される。異なるブラウザ（リクエスタ）からの全ての受信されたアドレス要求はこの場合正当なものと見なされ、割り当てテーブルに予め設定されたＩＰアドレスに割り当てられる。複数のリクエスタのその都度の問い合わせが異なる場合には、割り当てテーブルにおける１つの又は複数のエントリも行われ得る。
【００３５】
リクエスタ固有の特殊性又は変則性の他に、特許請求項３の構成ｂ）によればローカルな、つまりナショナルな特殊性が識別されるべきである。ブラウザはなるほどプログラム言語でプログラミングされ、もちろんユーザとのインターフェースにおいて様々なキャラクタセットによって供給される。ときおりブラウザは他言語で及び異なる方言でも構成されている。従って、特許請求項３ｂ）による類別の際には、アプリケーションプログラムのキャラクタコードに影響を与える所定のキャラクタセットがキャラクタコードの非コンベンショナルな構成部分の原因であるかどうかが検査される。
【００３６】
さらに、特許請求項３の構成ｃ）によれば、アプリケーションプログラムのキャラクタコードに影響を与えるパラメータがキャラクタコードの非コンベンショナルな構成部分の原因であるかどうかの検査の可能性も存在する。アプリケーションプログラム乃至はブラウザの個々のパラメータはユーザによって変更可能である。例えば、ユーザは異なるキャラクタセットを使用することができる。この結果、同一のリクエスタとりわけブラウザが様々なパラメータ固有のキャラクタコードを送信することができ、これらのキャラクタコードがＤＮＳによって学習され、さらに割り当てテーブルへのエントリによって正しいＩＰアドレスに割り当てられなければならない。
【００３７】
少なからぬ比較的古いオペレーティングシステムでは、許容されないキャラクタはこのオペレーティングシステムにより許容されるキャラクタに制限される。他のキャラクタ、とりわけ特殊キャラクタは単に抑圧される。このキャラクタ抑圧も原理的には有効キャラクタコードと見なされる。このキャラクタコードはこの場合例えば特殊キャラクタをもはや含まないが、残りのキャラクタに基づいてこのキャラクタコードをＩＰアドレスに正確に割り当てることができるはずである。
【００３８】
従って、特許請求項３の構成ｄ）によれば、このやり方でキャラクタコードのオペレーティングシステム固有の変更を識別及び学習するために、キャラクタコードに影響を与えるオペレーティングシステムがホストにおいて使用されるかどうかを検査することが可能である。
【００３９】
最後に、キャラクタコードの非コンベンショナルな構成部分が入力位置及び/又は伝送路に起因することがありうる。特許請求項３の構成ｅ）によればこの方向で検査及び類別が行われるべきである。とりわけキャラクタの抑圧及び/又は付加によって又は伝送の間の個々のビットの故意ではない又は故意のマスキングによる歪曲によって、キャラクタコードが変更されてしまい、受信側のＤＮＳによってＩＰアドレスが割り当てられないことが起こりうる。ネットワークにおける入力位置の変化によって、とりわけ異なる大陸によって、場合によっては、できるだけ多くのＤＮＳがキャラクタコードを修正することが実現されうる。これらの修正の識別及び類別に基づいてＤＮＳの割り当てテーブルの調整が可能である。
【００４０】
有利には類別の結果がＤＮＳの割り当てテーブルの自動更新のための基礎として使用される（特許請求項４）。
【００４１】
基本的に２つの時間区間に分割される、すなわちデータ収集の第１のフェーズとデータ評価の第２のフェーズとに分割される特許請求項２〜４に記述された方法の他に、特許請求項５〜１３の特徴部分記載の構成によれば、場合によってはリアルタイムで実行されうる自動的な選択方法を推進するメカニズムを設けることが可能である。
【００４２】
この場合、受信されるキャラクタコードは次のように処理され、とりわけフィルタリングされる。すなわち、専らキャラクタコードにおいて利用される標準キャラクタ、とりわけ英数字“Ａ/ａ”から“Ｚ/ｚ”まで、“０”から“９”まで及びトレマ“．、-、＠”が割り当てテーブルの後続のシーケンシャルな比較処理の基礎とされる（特許請求項５）。この場合に重要なことは、割り当てテーブルにおいて相応にフィルタリングされたキャラクタコードが記入されており、この結果、新たになされるフィルタリングされた問い合わせの一意的な割り当てがシーケンシャルな比較処理によって可能であることである。
【００４３】
これに相応して、特許請求項６の構成によれば、割り当てテーブルのＩＰアドレスへのフィルタリングされたキャラクタコードの一意的に可能な割り当てにおいてこの割り当てが行われ、ＩＰアドレスがリクエスタに伝達される。
【００４４】
しかし、フィルタリングされたキャラクタコードの一意的な割り当てが可能であるので、キャラクタコードのフィルタリングは次の問い合わせに対しては余計であり、この結果、特許請求項７の構成によれば、フィルタリングされないキャラクタコードを割り当てテーブルに受け入れる。これによってフィルタ処理が節減され、割り当てテーブルのエントリについてキャラクタコードのより迅速な割り当てが可能である。
【００４５】
特許請求項８の対象は、割り当てテーブルの各ＩＰアドレスに可変的な価値が割り当てられることである。この場合、ＩＰアドレスの価値は強制的に変更されてはならず、様々な影響ファクタに依存して高められるか又は低められる。この場合、重要なファクタはＩＰアドレスの呼び出し頻度である（特許請求項９）。ＩＰアドレスへのアクセス数が通常はインターネットサービスプロバイダにより記録される間に、ＤＮＳへの所定のＩＰアドレスの呼び出し頻度を記録して割り当てテーブルのＩＰアドレスに呼び出し頻度に相応する価値を割り当てることも考えられる。
【００４６】
これによって次のような可能性が生じる。すなわち、割り当てテーブルのＩＰアドレスへのフィルタリングされたキャラクタコードの一意的には可能ではない割り当てにおいてホストに、つまりリクエスタに全ての考慮の対象となる割り当てがオンライン選択のために伝達される（特許請求項１０）。このオンライン選択はこの場合順番に関してリクエスタにＤＮＳによって通知される可能な割り当ての価値に基づいて行われる（特許請求項１１）。最高の価値を有するＩＰアドレス、とりわけ最も多い呼び出しを有するＩＰアドレスはこの場合第１のＩＰアドレスとして構成される。なぜなら、ユーザ/リクエスタが同様にこのアドレスにアクセスしたがる確率が最大であるからである。ユーザの選択はＤＮＳによって記録され、これによってキャラクタコードに正確なＩＰアドレスが自動的にかつとりわけオンラインで割り当てられる。ホストコンピュータ/リクエスタの側での記録によって、このドメインネームの次の呼び出しにおいて既に正確なＩＰアドレスを有する正しいウェブサイトが直ぐにＤＮＳにより伝えられた選択マスクを介して得られる。
【００４７】
任意選択的に、特許請求項１２の構成によれば、フィルタリングされたキャラクタコードのＩＰアドレスへの一意的には可能ではない割り当てにおいてこのキャラクタコードに最高の価値を有するＩＰアドレスを割り当てることが可能である。この種の割り当てはとりわけ簡単であり、迅速に結果に導く。この結果がリクエスタにとって実際に満足のいくものであるかどうかは、これが実際に最高の価値を有するＩＰアドレスを呼び出そうとしたか否かに依存する。この方法はとりわけ非常に大きく異なる価値を有する複数のＩＰアドレスが割り当てテーブルに存在し、この結果、比較的高い価値を有するＩＰアドレスの呼び出しに対する優勢な確率が明らかである場合に適している。
【００４８】
多数の可能な割り当て又は基本的に同じ価値を有する割り当てにおいて、特許請求項１３の構成によれば、自動的に特許請求項８〜１２までに記述された構成のうちの１つを判定ルーチンによって開始して実施すると有利である。これは所定の個数を上回る場合に及び/又は価値の差を上回る場合に可能な割り当ての個数に依存して行われるべきである。例えば同じ価値の５つのＩＰアドレスが割り当てテーブルに存在している場合、ホスト/リクエスタに考慮の対象になる全ての割り当てがオンライン選択のために伝達されると有利である。もちろんただ２つののエントリが割り当てテーブルに存在し、１つのエントリが非常に高い価値を有し、もう１つのエントリがごく低い価値を有する場合には、特許請求項１２の構成に従うことがより有利であり、伝達されるキャラクタコードにより高い価値を有するＩＰアドレスを割り当てる。この場合、どういうやり方で価値が設定されるのかは未決定のままでもよい。
【００４９】
キャラクタコードがシーケンシャルな比較処理及び/又は類別によって特許請求項１〜１３に記述された方法のうちの１つに従って割り当てテーブルのＩＰアドレスに割り当てることができない場合には、請求項１４によってこのキャラクタコードがエラーリストに手動による後処理のために供給される。
【００５０】
特許請求項１５の対象は、キャラクタコードがＤＮＳによるその割り当ての後でリクエスタのキャッシュに中間記憶される。これは特殊キャラクタを解決するＤＮＳの負荷の軽減を可能にし、所望のドメインへのリクエスタの加速されたアクセスを可能にする。従って、特定のドメインネームサーバ（図５の３．ドメインネームサーバを参照）の新たなコンタクトは再呼び出しにおいて必要ない。
【００５１】
本発明の方法及び基礎となるコンピュータネットワークが技術的に一般化されて図６の概略図に図示されている。コンピュータネットワークは第１のドメインネームサーバ（１）を有し、この第１のドメインネームサーバ（１）はコンピュータ（２）からのユーザによるインターネットアドレスの呼び出しの際にコンタクトされる。この第１のＤＮＳ１はインターネットアドレスから生成されるキャラクタコードから部分鍵、すなわち語尾“．ｃｏｍ“を識別する。次いで、問い合わせがここでは（？？？？？？１０１）によって図示されている部分鍵と共にＤＮＳｘ（３）に転送される。これは部分鍵”．ｅｕ．ｃｏｍ“を部分鍵（？？？？１１１０１）に相応して識別することができる。この部分鍵は次いでＤＮＳｙ（４）に伝送され、そこで更に復号が行われる。このチェーンの最後にＤＮＳｚ（５）がコンタクトされる。このＤＮＳｚ（５）はオーソリテイティブネームサーバ（Authoritative Name Server）であり、そこではシーケンシャルな比較処理によって正しいＩＰアドレスが指示される。こうしてもとめられた周知の数字鍵（ＩＰアドレス）はユーザに伝送される。ユーザは次いで自分の選択したインターネットページに到達する。
【００５２】
本発明によって、ドメインネームルートサーバ又は例えばブラウザのようなリクエスタに付加的な変換モードを割り当てる必要なしに又はここで各々個別ドメインが記憶される必要なしに、特殊キャラクタを含むインターネットアドレスが利用可能になる。チェーン復号によってＤＮＳｚ（５）においてツリー構造を介する割り当てに基づいて前置接続されたドメインネームサーバ１、３及び４によって識別され得なかったドメインの部分だけが復号されればよいのである。
【図面の簡単な説明】
【００５３】
【図１】ドメインネーム空間の部分図である。
【００５４】
【図２】ＤＮＳ標準問い合わせが示されている。
【００５５】
【図３】単一のリカーシブなＤＮＳ問い合わせが示されている。
【００５６】
【図４】多重のリカーシブなＤＮＳ問い合わせが示されている。
【００５７】
【図５】特殊キャラクタ利用を有する本発明のドメインネーム解決及び未知の特殊キャラクタ乃至はコーディングの識別を説明する図である。
【００５８】
【図６】発明の方法及び基礎となるコンピュータネットワークが技術的に一般化されて概略図に図示されている。
【符号の説明】
【００５９】
１  ＤＮＳ
２  コンピュータ
３  ＤＮＳｘ
４  ＤＮＳｙ
５  ＤＮＳｚ
【図１】
2004529539.tif 000006
【図２】
2004529539.tif 000007
【図３】
2004529539.tif 000008
【図４】
2004529539.tif 000009
【図５】
2004529539.tif 000010
【図６】
2004529539.tif 000011
【国際公開パンフレット】
2004529539.tif 000012
2004529539.tif 000013
2004529539.tif 000014
2004529539.tif 000015
2004529539.tif 000016
2004529539.tif 000017
2004529539.tif 000018
2004529539.tif 000019
2004529539.tif 000020
2004529539.tif 000021
2004529539.tif 000022
2004529539.tif 000023
2004529539.tif 000024
2004529539.tif 000025
2004529539.tif 000026
2004529539.tif 000027
2004529539.tif 000028
2004529539.tif 000029
2004529539.tif 000030
2004529539.tif 000031
2004529539.tif 000032
2004529539.tif 000033
2004529539.tif 000034
2004529539.tif 000035
2004529539.tif 000036
2004529539.tif 000037
【国際公開パンフレット（コレクトバージョン）】
2004529539.tif 000038
2004529539.tif 000039
【手続補正書】
【提出日】平成14年12月20日(2002.12.20)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータネットワーク（インターネット）において特殊キャラクタを含むインターネットアドレス（ドメイン）を提供するための方法に関する。
【０００２】
インターネットアドレスの選択において、ブラウザにおいて識別子ｈｔｔｐ：／／の後ろにそれぞれのインターネットアドレスが、文字、数字、ハイフン等々の形式でいわゆるＡＳＣＩＩ（American Standard Code for Information Interchange）のサブセットにおいて入力される。アドレスはインターネットに存在するドメインネームサーバ（ＤＮＳ）によって数字鍵、いわゆるＩＰアドレス（インターネットプロトコルアドレス）に変換され、コンタクトルーチンが開始される。
【０００３】
【数１】
2004529539.tif 000040
【０００４】
コンピュータネットワークでは多数のコンピュータが一つに結びつけられる。これらのコンピュータの各々はネットワーク内で一意的に識別できなければならない。今日の最大のネットワーク、すなわちインターネットでは、個々のコンピュータ（ホスト）はいわゆるＩＰアドレスによって一意的に識別される。
【０００５】
人間には多数のホストＩＰアドレスを覚えておくことは難しいので、ＩＰアドレスにドメインネームを割り当てるシステムが導入された。このシステムはドメインネームシステムと呼ばれる。いわゆるドメインネームサーバ（ＤＮＳ）はドメインネームのＩＰアドレスへの割り当てに関する情報を提供する。ドメインネームシステム内ではいくつかの取り決めがドメインネームに関して定められている。すなわち、ラベルは文字で始まり、文字又は数字で終わり、その間に文字か、数字か、ハイフンかのいずれかを有する。例えばｗｗｗ．ｍｕｅｌｌｅｒ．ｄｅ、ｗｗｗ．ｂｏｃｈｕｍ．ｄｅ、ｗｗｗ．ｅｕ．ｃｏｍ又はｗｗｗ．ｓｍｓ．ｔ−ｏｎｌｉｎｅ．ｄｅである。
【０００６】
ドメインネーム空間はツリー状の構造として作られている。根（ルート）から始まって“ｄｅ”、“ｃｏｍ”又は“ｏｒｇ”のようなふつうのトップレベルドメイン（ｇＴＬＤｓ）がつづく。これらは更なるサブドメインに分割される。図１は、サブドメイン“ｕｓ”及び“ｅｕ”を有するトップレベルドメイン“ｃｏｍ”の小さな一部を示す。最後にツリーのリーフが個々のネットワークリソース（大抵の場合ホスト又はルータ）を識別する。図１では例えば“ｗｗｗ”又は“ｍａｉｌ”である。
【０００７】
ドメインネーム空間のＤＮＳは、ドメインネーム空間ツリーの結節点及び全てのその下にある枝を含むゾーンを管理する。ツリーの異なるレベルにおけるネームサーバの存在によって異なるＤＮＳのゾーンが互いにオーバーラップする。ＤＮＳはそれぞれ自分の次に高いＤＮＳ及び自分の次に低いＤＮＳを知っている。
【０００８】
ＤＮＳの主な任務は、ＩＰアドレスをドメインネームに割り当てること及びその逆である。ユーザプログラム（例えばブラウザ）はこのような問い合わせ（クエリ）を自分自身では実装してはならない。大抵のオペレーティングシステムはこのサービスを統合している。ユーザプログラムはオペレーティングシステム呼び出しの助けによって情報を手に入れることができる。ＤＮＳへの実際のクエリはリゾルバが引き受ける。パフォーマンス向上のために全てのリゾルバはローカルキャッシュ（バッファメモリ）を自由に使用し、これにより多重問い合わせに比較的迅速に答えられる。図２にはこのような標準問い合わせが示されている：
標準ＤＮＳ問い合わせの経過は次のようなものである：
（１）ユーザプログラムはドメインネームを有し、これに所属するＩＰアドレスをもとめたい。
（２ａ）ユーザプログラムは問い合わせをリゾルバに送り、このリゾルバから応答を待つ。
【０００９】
リゾルバは解答がすでにキャッシュに存在するかどうかを検査し、存在する場合にはこの解答を返送する。
（２ｂ）解答がキャッシュにまだ存在しない場合には、リゾルバは自分からクエリをＤＮＳに送る。
（３）ＤＮＳはリゾルバに所望の解答を返送する。
（４）リゾルバはこの解答を自分のキャッシュにコピーし、これを同時にユーザプログラムに送る。
【００１０】
しかし、最初の問い合わせを受けたＤＮＳがリゾルバによって提出されたクエリに対する解答を供給できないこともあり得る。この場合には２つの方法がある。
【００１１】
最初の問い合わせを受けたＤＮＳが自分でクエリに応答することができる更に別のＤＮＳを探す。この場合、リゾルバにおいては何も変わらず、このリゾルバは単に「自分の」ＤＮＳから応答を得るまで待つ。この種のクエリは「リカーシブ」と呼ばれる。リカーシブな問い合わせは図３に図示されている。
【００１２】
リカーシブなＤＮＳ問い合わせの経過は次のようなものである：
（１）リゾルバから所定のＤＮＳにクエリが送られる。このクエリには、このクエリは「リカーシブに」実施されるべきであるという情報も含まれている。
（２）最初の問い合わせを受けたＤＮＳがクエリに対する解答を知らない場合、このＤＮＳは解答を供給できそうな他のＤＮＳにこのクエリを転送する。
（３）このＤＮＳも解答を知らない場合には、このＤＮＳはこのことを返信し、さらに解答を知っていそうなＤＮＳを知っているかどうかを報告する。このプロセスが複数回繰り返される。
（４）最後に最初のＤＮＳが解答を知っているＤＮＳに到達する。大抵の場合、これはいわゆるオーソリテイティブネームサーバ（Authoritative Name Server）である。
（５）クエリに対する応答がリゾルバに返送される。
【００１３】
最初のＤＮＳがリゾルバにそのクエリに対してなんら結論を供給できない場合には、他のＤＮＳが提案され、この他のＤＮＳにリゾルバは改めてクエリを依頼しなければならない。このシナリオは、リゾルバが最終的に解答を供給することができるＤＮＳに問い合わせるまで何回も繰り返される。これは図４に図示されている。
【００１４】
ＷＯ００/５６０３５はドメインの国際化のための方法を論じている。この場合、中間プログラムが使用され、この中間プログラムは各ブラウザによってダウンロードされなければならない。このプログラムはドメインからＡＳＣＩＩキャラクタ列を生成し、これを転送する。これがドメインネームサーバ（ＤＮＳ）によって識別されるためには、キャラクタ列がそこに記録されていなければならない。特殊キャラクタを含むインターネットアドレスを記録するために、これがユニコードシステムに入力され、ローマ字に変換される。この変換はＲＡＣＥと呼ばれ、これは行ベースのＡＳＣＩＩコンパチプルエンコーディングの例である。従って、ＤＮＳによって識別されるために、ドメインはＤＮＳにおいてＡＳＣＩＩコードで、例えばｂｑ-ｂｈａｓｕｔｒ．ｃｏｍとして記録されなければならない。従って、このような特殊キャラクタを含むドメインを世界中で許可するためには、全ＤＮＳの変更が必要であるだろう。さらに、この場合、全ての問い合わせは最初に検査のためにハイパフォーマンスなｉＤＮＳサーバに転送されなければならない。なぜなら、さもなければ、その下位にある従来のＤＮＳに対する変換が行われないからである。
【００１５】
ＷＯ００/５０９６６からはコンピュータネットワークに中間サーバを設ける提案が喚起されている。この中間サーバは全ての問い合わせを受理し、ＤＮＳルートサーバに翻訳して転送する。この場合、先に記述したやり方に類似の識別が行われなければならない。ＩＰアドレスは中間サーバに返送され、この中間サーバは次いでユーザに返信を行う。同様の解決方法はＷＯ９９/４０５１１から公知である。
【００１６】
全ての上記の引用した解決案の共通点は、特殊キャラクタがドメインネームにおいて解決され許可されるために、既存のシステム、すなわちネットワーク要素における変更がブラウザに対して付加モジュールの形で必要である点、又は、特殊キャラクタによって負荷を受けないＤＮＳの変更が必要不可欠である点である。
【００１７】
本発明の課題は、既存のＤＮＳサーバ構造への統合のための特殊キャラクタを含むキャラクタコードの簡単かつ経済的な処理のための方法を提供することであり、しかもこの場合リクエスタ/ユーザシステムの側において変更が必要ではなく、ならびに、この方法の枠内で改善されたフィルタ機構を提供し、このフィルタ機構によってキャラクタコードの反復する非コンベンショナルな構成部分がもとめられ、類別され、さらに後続処理に供給されることである。
【００１８】
上記課題は、請求項１記載の方法によって解決される。
【００１９】
本発明によれば、特殊キャラクタを含むインターネットアドレスを提供するための方法がコンピュータネットワークにおいて設けられ、ドメインはユーザによる呼び出しの際にまず最初に既存のリゾルバによってキャラクタコードに変換される。このキャラクタコードは最初のＤＮＳ、いわゆるルートサーバに伝送される。変換されたキャラクタコードは２値又は１６値キャラクタ列である。キャラクタコードが最初のＤＮＳによって識別されない場合、これは少なくとも１つの更に別のＤＮＳに転送され、この更に別のＤＮＳにおいてシーケンシャルな比較処理によってこのキャラクタコードに相応する既知の数字鍵（ＩＰアドレス）がもとめられ、これがユーザに返送される。
【００２０】
キャラクタコードが最初のＤＮＳによって部分的に復号される場合には、次いで識別された部分鍵に基づいて更に別のＤＮＳにコンタクトがとられ、この更に別のＤＮＳが更なる復号を行う。この順番で更に別のＤＮＳにコンタクトがとられ、呼び出されたインターネットアドレスの完全な復号が行われて最後にＩＰアドレスとしてユーザに伝送されるまでこれが行われる。
【００２１】
【数２】
2004529539.tif 000041
【００２２】
このナンセンスな数列は、ＤＮＳにおいてシーケンシャルな比較処理で復号され、この場合非コンベンショナルな質問として数列からなるコンベンショナルな解答に変換される。つまり、このキャラクタコードにシーケンシャルな比較処理に基づいて正しいＩＰアドレスが割り当てられ、ユーザに返送される。ユーザは次いでユーザが所望するインターネットページに到達する。
【００２３】
図５に基づいて特殊キャラクタ利用を有する本発明のドメインネーム解決及び未知の特殊キャラクタ乃至はコーディングの識別を説明する。
【００２４】
【数３】
2004529539.tif 000042
【００２５】
特殊キャラクタを有するドメインとしては、領域“Ａ/ａ”から“Ｚ/ｚ”まで、“０”から“９”まで及びトレマ“．、-、＠”以外のキャラクタを有するドメインである。たとえＡＳＣＩＩ領域“Ａ/ａ”から“Ｚ/ｚ”まで乃至は“０”から“９”までに含まれていても、オリジナルブラウザ、すなわちリクエスタにおいて万国共通記号として示されなかった場合には、どんな万国共通記号も特殊キャラクタと見なされる。
【００２６】
シーケンシャルな比較処理は、本発明によれば様々なブラウザ/リゾルバプログラムにより生成されるキャラクタコードに対する鍵を含む割り当てテーブルに基づいて行われる。これは、割り当てテーブルを連続的に経過してそこに格納されたシーケンスがユーザのブラウザ/リゾルバにより生成されるキャラクタコードと比較されることによって、行われる。
【００２７】
ブラウザ乃至はリゾルバは同じ特殊キャラクタを含むドメインを互いに異なる単一キャラクタ列又は複数キャラクタ列に変換するので、このような単一キャラクタ列又は複数キャラクタ列を含むキャラクタコードはこれまで使用されてきたＤＮＳによっては識別されなかった。この場合、本発明の重要な利点は、特殊キャラクタに対して、今や生成されたキャラクタのバイト毎の割り当て又はセグメント化が必要ではなく、むしろドメイン乃至は特殊キャラクタを含むドメインのキャラクタコードがまるごと、つまり全長においてシーケンシャルな比較処理によって識別されることである。割り当てテーブルに今や直接様々なブラウザ及び/又はリゾルバにより生成されたキャラクタコードがまるごと記述されていることによって、このようなドメインがちょうど従来の取り決めに相応するドメインのように識別され、ドメインネームサーバチェーンにおいて考慮される。
【００２８】
更に別の利点は、実際に特殊キャラクタがドメインに存在している場合には、シーケンシャルな比較処理によって特殊キャラクタを有するドメインを解決するＤＮＳが単に呼び出されるだけであることである。これによって、特殊キャラクタを有するドメインを解決するＤＮＳは負荷を軽減される。
【００２９】
本発明の方法がＤＮＳにおいて使用され、このＤＮＳが特殊キャラクタを復号できない場合には、ドメインネームサーバのプロバイダよりエラーメッセージが出力され、エラーリストに記入される。このエラーリストに基づいてプロバイダはまだ正しくコーディングされていない正確な入力を手動で選別し、場合によってはＤＮＳの割り当てテーブルに保存しなければならないだろう。
【００３０】
割り当てテーブルへのドメインの正確なエントリの検出は個々のメーカーのブラウザのフィールド“ｈｔｔｐ：／／．．．．”における手動テクスト入力によって実現された。次いで、どのようなキャラクタコードをブラウザが転送するのか及びどのようなＩＰアドレスがこのキャラクタコードに相応するのかが検査された。次いで、キャラクタコードの正しいＩＰアドレスへの手動割り当てが行われ、キャラクタコードはＤＮＳの割り当てテーブルに記入される。このことは典型的なブラウザファミリー毎に乃至はオペレーティングシステム毎に行われなければならず、この結果、これから少なくとも１つの付加的なエントリが又は最も不利な場合には典型的なブラウザファミリー毎に乃至はオペレーティングシステム毎に付加的なエントリがＤＮＳの割り当てテーブルにおいて行われなければならなかった。この手動による方法は特許請求項２の構成によって記述されているように自動化された方法によって大幅に改良される。従って、これらの構成に対して独立した保護が要請される。
【００３１】
この場合、基本的な目的は、明らかな非識別エラーを可能な新しいキャラクタコードとして及び/又は新しい未知のブラウザ乃至はドメインネーム問い合わせとして識別し、場合によっては自動的に補正エントリをＤＮＳの割り当てテーブルに挿入するという要求によって、エラーリストを時間遅延して又はオンラインで処理することである。これによって、同一のリクエスタの将来の問い合わせが正確に解決され、つまり正しいＩＰアドレスが割り当てられ、返送されることが実現されるはずである。
【００３２】
この場合、所定の期間内にＤＮＳに送信される非コンベンショナルなキャラクタコードがＩＰアドレスの正しい要求と見なされ、記憶され、アルゴリズムを介して記憶されたキャラクタコードにおいて反復する非コンベンショナルな構成部分がもとめられ、類別される。次いで、キャラクタコードの類別された構成部分が、シーケンシャルな比較処理での同一の又は類似の構成部材によるキャラクタコードの識別のための基礎として使用される。
【００３３】
所定の時間窓の中で及び非コンベンショナルなキャラクタコードがＩＰアドレスの正しい要求と見なされ得るという仮説の中で、非コンベンショナルな、つまり従来の取り決めに相応しないキャラクタコードを収集することによって、これらのデータセットを所期の通りにアルゴリズムによって解析し、とりわけ反復する非コンベンショナルな構成部分をもとめ、さらにこれらを類別するという方法が存在する。
【００３４】
この場合、コード構成部分の類別は１つ又は複数の規準によって行われる。まず最初に、この場合、キャラクタコードの構成部分をホストのアプリケーションプログラム、とりわけブラウザ及び/又はリゾルバに割り当てることができるかどうかが検査される。異なるブラウザ（リクエスタ）からの全ての受信されたアドレス要求はこの場合正当なものと見なされ、割り当てテーブルに予め設定されたＩＰアドレスに割り当てられる。複数のリクエスタのその都度の問い合わせが異なる場合には、割り当てテーブルにおける１つの又は複数のエントリも行われ得る。
【００３５】
リクエスタ固有の特殊性又は変則性の他に、特許請求項１の構成ｂ）によればローカルな、つまりナショナルな特殊性が識別されるべきである。ブラウザはなるほどプログラム言語でプログラミングされ、もちろんユーザとのインターフェースにおいて様々なキャラクタセットによって供給される。ときおりブラウザは他言語でかつ異なる方言でも構成されている。従って、特許請求項１ｂ）による類別の際には、アプリケーションプログラムのキャラクタコードに影響を与える所定のキャラクタセットがキャラクタコードの非コンベンショナルな構成部分の原因であるかどうかが検査される。
【００３６】
さらに、特許請求項１の構成ｃ）によれば、アプリケーションプログラムのキャラクタコードに影響を与えるパラメータがキャラクタコードの非コンベンショナルな構成部分の原因であるかどうかの検査の可能性も存在する。アプリケーションプログラム乃至はブラウザの個々のパラメータはユーザによって変更可能である。例えば、ユーザは異なるキャラクタセットを使用することができる。この結果、同一のリクエスタとりわけブラウザが様々なパラメータ固有のキャラクタコードを送信することができ、これらのキャラクタコードがＤＮＳによって学習され、さらに割り当てテーブルへのエントリによって正しいＩＰアドレスに割り当てられなければならない。
【００３７】
少なからぬ比較的古いオペレーティングシステムでは、許容されないキャラクタはこのオペレーティングシステムにより許容されるキャラクタに制限される。他のキャラクタ、とりわけ特殊キャラクタは単に抑圧される。このキャラクタ抑圧も原理的には有効キャラクタコードと見なされる。このキャラクタコードはこの場合例えば特殊キャラクタをもはや含まないが、残りのキャラクタに基づいてこのキャラクタコードをＩＰアドレスに正確に割り当てることができるはずである。
【００３８】
従って、特許請求項１の構成ｄ）によれば、このやり方でキャラクタコードのオペレーティングシステム固有の変更を識別及び学習するために、キャラクタコードに影響を与えるオペレーティングシステムがホストにおいて使用されるかどうかを検査することが可能である。
【００３９】
最後に、キャラクタコードの非コンベンショナルな構成部分が入力位置及び/又は伝送路に起因することがありうる。特許請求項１の構成ｅ）によればこの方向で検査及び類別が行われるべきである。とりわけキャラクタの抑圧及び/又は付加によって又は伝送の間の個々のビットの故意ではない又は故意のマスキングによる歪曲によって、キャラクタコードが変更されてしまい、受信側のＤＮＳによってＩＰアドレスが割り当てられないことが起こりうる。ネットワークにおける入力位置の変化によって、とりわけ異なる大陸によって、場合によってはできるだけ多くのＤＮＳがキャラクタコードを修正することが実現されうる。これらの修正の識別及び類別に基づいてＤＮＳの割り当てテーブルの調整が可能である。
【００４０】
有利には類別の結果がＤＮＳの割り当てテーブルの自動更新のための基礎として使用される。
【００４１】
基本的に２つの時間区間に分割される、すなわちデータ収集の第１のフェーズとデータ評価の第２のフェーズとに分割される特許請求項１に記述された方法の他に、特許請求項２〜１０の特徴部分記載の構成によれば、場合によってはリアルタイムで実行されうる自動的な選択方法を推進するメカニズムを設けることが可能である。
【００４２】
この場合、受信されるキャラクタコードは次のように処理され、とりわけフィルタリングされる。すなわち、専らキャラクタコードにおいて利用される標準キャラクタ、とりわけ英数字“Ａ/ａ”から“Ｚ/ｚ”まで、“０”から“９”まで及びトレマ“．、-、＠”が割り当てテーブルの後続のシーケンシャルな比較処理の基礎とされる（特許請求項２）。この場合に重要なことは、割り当てテーブルにおいて相応にフィルタリングされたキャラクタコードが記入されており、この結果、新たになされるフィルタリングされた問い合わせの一意的な割り当てがシーケンシャルな比較処理によって可能であることである。
【００４３】
これに相応して、特許請求項３の構成によれば、割り当てテーブルのＩＰアドレスへのフィルタリングされたキャラクタコードの一意的に可能な割り当てにおいてこの割り当てが行われ、ＩＰアドレスがリクエスタに伝達される。
【００４４】
しかし、フィルタリングされたキャラクタコードの一意的な割り当てが可能であるので、キャラクタコードのフィルタリングは次の問い合わせに対しては余計であり、この結果、特許請求項４の構成によれば、フィルタリングされないキャラクタコードを割り当てテーブルに受け入れる。これによってフィルタ処理が節減され、割り当てテーブルのエントリについてキャラクタコードのより迅速な割り当てが可能である。
【００４５】
特許請求項５の対象は、割り当てテーブルの各ＩＰアドレスに可変的な価値が割り当てられることである。この場合、ＩＰアドレスの価値は強制的に変更されてはならず、様々な影響ファクタに依存して高められるか又は低められる。この場合、重要なファクタはＩＰアドレスの呼び出し頻度である（特許請求項６）。ＩＰアドレスへのアクセス数が通常はインターネットサービスプロバイダにより記録される間に、ＤＮＳへの所定のＩＰアドレスの呼び出し頻度を記録して割り当てテーブルのＩＰアドレスに呼び出し頻度に相応する価値を割り当てることも考えられる。
【００４６】
これによって次のような可能性が生じる。すなわち、割り当てテーブルのＩＰアドレスへのフィルタリングされたキャラクタコードの一意的には可能ではない割り当てにおいてホストに、つまりリクエスタに全ての考慮の対象となる割り当てがオンライン選択のために伝達される（特許請求項７）。このオンライン選択はこの場合順番に関してリクエスタにＤＮＳによって通知される可能な割り当ての価値に基づいて行われる（特許請求項８）。最高の価値を有するＩＰアドレス、とりわけ最も多い呼び出しを有するＩＰアドレスはこの場合第１のＩＰアドレスとして構成される。なぜなら、ユーザ/リクエスタが同様にこのアドレスにアクセスしたがる確率が最大であるからである。ユーザの選択はＤＮＳによって記録され、これによってキャラクタコードに正確なＩＰアドレスが自動的にかつとりわけオンラインで割り当てられる。ホストコンピュータ/リクエスタの側での記録によって、このドメインネームの次の呼び出しにおいて既に正確なＩＰアドレスを有する正しいウェブサイトが直ぐにＤＮＳにより伝えられた選択マスクを介して得られる。
【００４７】
任意選択的に、特許請求項９の構成によれば、フィルタリングされたキャラクタコードのＩＰアドレスへの一意的には可能ではない割り当てにおいてキャラクタコードに最高の価値を有するＩＰアドレスを割り当てることが可能である。この種の割り当てはとりわけ簡単であり、迅速に結果に導く。この結果がリクエスタにとって実際に満足のいくものであるかどうかは、これが実際に最高の価値を有するＩＰアドレスを呼び出そうとしたか否かに依存する。この方法はとりわけ非常に大きく異なる価値を有する複数のＩＰアドレスが割り当てテーブルに存在し、この結果、比較的高い価値を有するＩＰアドレスの呼び出しに対する優勢な確率が明らかである場合に適している。
【００４８】
多数の可能な割り当て又は基本的に同じ価値を有する割り当てにおいて、特許請求項１０の構成によれば、自動的に特許請求項５〜９までに記述された構成のうちの１つを判定ルーチンによって開始して実施すると有利である。これは所定の個数を上回る場合に及び/又は価値の差を上回る場合に可能な割り当ての個数に依存して行われるべきである。例えば同じ価値の５つのＩＰアドレスが割り当てテーブルに存在している場合、ホスト/リクエスタに考慮の対象になる全ての割り当てがオンライン選択のために伝達されると有利である。もちろんただ２つののエントリが割り当てテーブルに存在し、１つのエントリが非常に高い価値を有し、もう１つのエントリがごく低い価値を有する場合には、特許請求項９の構成に従うことがより有利であり、伝達されるキャラクタコードにより高い価値を有するＩＰアドレスを割り当てる。この場合、どういうやり方で価値が設定されるのかは未決定のままでもよい。
【００４９】
キャラクタコードがシーケンシャルな比較処理及び/又は類別によって特許請求項１〜１０に記述された方法のうちの１つに従って割り当てテーブルのＩＰアドレスに割り当てることができない場合には、本発明の枠内ではこのキャラクタコードをエラーリストに手動による後処理のために供給することが可能である。
【００５０】
特許請求項１１の対象は、キャラクタコードがＤＮＳによるその割り当ての後でリクエスタのキャッシュに中間記憶される。これは特殊キャラクタを解決するＤＮＳの負荷の軽減を可能にし、所望のドメインへのリクエスタの加速されたアクセスを可能にする。従って、特定のドメインネームサーバ（図５の３．ドメインネームサーバを参照）の新たなコンタクトは再呼び出しにおいて必要ない。
【００５１】
本発明の方法及び基礎となるコンピュータネットワークが技術的に一般化されて図６の概略図に図示されている。コンピュータネットワークは第１のドメインネームサーバ（１）を有し、この第１のドメインネームサーバ（１）はコンピュータ（２）からのユーザによるインターネットアドレスの呼び出しの際にコンタクトされる。この第１のＤＮＳ１はインターネットアドレスから生成されるキャラクタコードから部分鍵、すなわち語尾“．ｃｏｍ”を識別する。次いで、問い合わせがここでは（？？？？？？１０１）によって図示されている部分鍵と共にＤＮＳｘ（３）に転送される。これは部分鍵“．ｅｕ．ｃｏｍ”を部分鍵（？？？？１１１０１）に相応して識別することができる。この部分鍵は次いでＤＮＳｙ（４）に伝送され、そこで更に復号が行われる。このチェーンの最後にＤＮＳｚ（５）がコンタクトされる。このＤＮＳｚ（５）はオーソリテイティブネームサーバ（Authoritative Name Server）であり、そこではシーケンシャルな比較処理によって正しいＩＰアドレスが指示される。こうしてもとめられた周知の数字鍵（ＩＰアドレス）はユーザに伝送される。ユーザは次いで自分の選択したインターネットページに到達する。
【００５２】
本発明によって、ドメインネームルートサーバ又は例えばブラウザのようなリクエスタに付加的な変換モードを割り当てる必要なしに又は各々個別ドメインが記憶される必要なしに、特殊キャラクタを含むインターネットアドレスが利用可能になる。チェーン復号によってＤＮＳｚ（５）においてツリー構造を介する割り当てに基づいて前置接続されたドメインネームサーバ１、３及び４によって識別され得なかったドメインの部分だけが復号されればよいのである。
【図面の簡単な説明】
【００５３】
【図１】ドメインネーム空間の部分図である。
【００５４】
【図２】ＤＮＳ標準問い合わせが示されている。
【００５５】
【図３】単一のリカーシブなＤＮＳ問い合わせが示されている。
【００５６】
【図４】多重のリカーシブなＤＮＳ問い合わせが示されている。
【００５７】
【図５】特殊キャラクタ利用を有する本発明のドメインネーム解決及び未知の特殊キャラクタ乃至はコーディングの識別を説明する図である。
【００５８】
【図６】発明の方法及び基礎となるコンピュータネットワークが技術的に一般化されて概略図に図示されている。
【符号の説明】
【００５９】
１  ＤＮＳ
２  コンピュータ
３  ＤＮＳｘ
４  ＤＮＳｙ
５  ＤＮＳｚ


【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンピュータネットワーク（インターネット）において特殊キャラクタを含むインターネットアドレス（ドメイン）を提供するための方法であって、
ドメインはユーザによる呼び出しの際にまず最初にキャラクタコードに変換され、該キャラクタコードは第１のドメインネームサーバ（ＤＮＳ）（１）に伝送され、前記キャラクタコードが前記第１のＤＮＳ（１）によって識別され得ない場合にはこのキャラクタコードは前記第１のＤＮＳ（１）から少なくとも１つの更に別のＤＮＳ（５）に転送され、この少なくとも１つの更に別のＤＮＳ（５）において前記キャラクタコードがシーケンシャルな比較処理の評価の下で復号され、前記キャラクタコードが前記第１のＤＮＳ（１）によって部分的に復号される場合には、識別された部分鍵に基づいて少なくとも１つの更に別のＤＮＳ（３〜５）とコンタクトを取り、該少なくとも１つの更に別のＤＮＳ（３〜５）は更に別の復号を行い、次いで前記キャラクタコードに周知の数字鍵（ＩＰアドレス）が割り当てられ、これが前記ユーザに返送され、前記シーケンシャルな比較処理は割り当てテーブルに基づいて異なるブラウザ及び/又はリゾルバによって生成されるキャラクタコードに対する鍵を識別し、所定の期間内にＤＮＳに送信される非コンベンショナルなキャラクタコードがＩＰアドレスの正しい要求と認められて記憶され、アルゴリズムを介して記憶されたキャラクタコードにおいて反復される非コンベンショナルな構成部分がもとめられて類別化され、次いで前記キャラクタコードの類別化された前記構成部分が同一の又は類似の構成部分を有するキャラクタコードの識別のための基礎として前記シーケンシャルな比較処理において使用され、コード構成部分の類別化は以下の規準、すなわち、
ａ）前記キャラクタコードの前記構成部分がリクエスタのアプリケーションプログラム、とりわけブラウザ及び/又はリゾルバに割り当てられるかどうかの検査、
ｂ）前記キャラクタコードに影響を与えるアプリケーションプログラムの所定のキャラクタセットが前記キャラクタコードの非コンベンショナルな構成部分の原因であるかどうかの検査、
ｃ）キャラクタコードに影響を与えるアプリケーションプログラムの所定のパラメータが前記キャラクタコードの非コンベンショナルな構成部分の原因であるかどうかの検査、
ｄ）キャラクタコードに影響を与えるオペレーティングシステムがホスト/リクエスタにおいて使用されるかどうかの検査、
ｅ）キャラクタコードに影響を与える入力位置及び/又は伝送路が前記キャラクタコードの非コンベンショナルな構成部分の原因であるかどうかの検査
のうちの１つ又は複数に関して行われる、コンピュータネットワーク（インターネット）において特殊キャラクタを含むインターネットアドレス（ドメイン）を提供するための方法。
【請求項２】
ＤＮＳ（１〜５）によって受信されるキャラクタコードは使用される特殊キャラクタに関してフィルタリングされ、専ら前記キャラクタコードで利用される標準キャラクタ、とりわけ英数字のキャラクタ“Ａ”から“Ｚ”まで、“０”から“９” まで及び“−”が割り当てテーブルの後続のシーケンシャルな比較処理の基礎とされる、請求項１記載の方法。
【請求項３】
割り当てテーブルのＩＰアドレスへのフィルタリングされたキャラクタコードの一意的に可能な割り当てにおいて、この割り当てが行われ、前記ＩＰアドレスがリクエスタに伝達されることを特徴とする、請求項２記載の方法。
【請求項４】
フィルタリングされたキャラクタコードの一意的な割り当てにおいて、フィルタリングされないキャラクタコードがＤＮＳに受け入れられることを特徴とする、請求項３記載の方法。
【請求項５】
割り当てテーブルの各ＩＰアドレスには可変的な価値が割り当てられることを特徴とする、請求項１〜４のうちの１項記載の方法。
【請求項６】
割り当てテーブルのＩＰアドレスの呼び出しの頻度が記録され、前記ＩＰアドレスには呼び出し頻度に相応する価値が割り当てられることを特徴とする、請求項５記載の方法。
【請求項７】
割り当てテーブルのＩＰアドレスへのフィルタリングされたキャラクタコードの一意的には可能ではない割り当てにおいて、リクエスタには全ての考慮の対象となる割り当てがオンライン選択のために伝達されることを特徴とする、請求項２記載の方法。
【請求項８】
ＤＮＳでは、考慮の対象となる割り当てがそれらの価値の順番で記載されることを特徴とする、請求項７記載の方法。
【請求項９】
ＩＰアドレスへのフィルタリングされたキャラクタコードの一意的には可能ではない割り当てにおいて、このキャラクタコードには最高の価値を有するＩＰアドレスが割り当てられることを特徴とする、請求項５記載の方法。
【請求項１０】
可能な割り当ての個数に依存して、所定の個数及び/又は価値の差を上回る場合に自動的に請求項５〜９までに記述された構成のうちの１つが実施されることを特徴とする、請求項５〜９のうちの１項記載の方法。
【請求項１１】
キャラクタコードはＤＮＳによるその割り当ての後でリクエスタのキャッシュに中間記憶されることを特徴とする、請求項１〜１０のうちの１項記載の方法。
【国際調査報告】
2004529539.tif 000043
2004529539.tif 000044
2004529539.tif 000045
2004529539.tif 000046
2004529539.tif 000047
2004529539.tif 000048
2004529539.tif 000049
2004529539.tif 000050
2004529539.tif 000051
2004529539.tif 000052