JP2005535032A

JP2005535032A - 柔軟なトップレベルドメインのための、ローカルネームサーバを持つ内部自然ドメインサービスシステム

Info

Publication number: JP2005535032A
Application number: JP2004525862A
Authority: JP
Inventors: 榮錫韓
Original assignee: HOWNY
Current assignee: HOWNY
Priority date: 2002-08-05
Filing date: 2003-08-01
Publication date: 2005-11-17
Also published as: KR20040013215A; AU2003254961A1; EP1546914A1; CN1675634A; KR100463208B1; WO2004013764A1; US20060195609A1

Abstract

本発明は、公式のトップレベルドメインでないサイト名または固有名詞をトップレベルドメインとして使用することができる、分散型サービス方式を取る新しいＵＲＩ型の拡張型内部ドメインネームサービスに関する。本発明は、それぞれドメインサービス用のプログラムが組み込まれた中央ネームサーバ、ローカルネームサーバ、およびユーザコンピュータを有する。サービス準備ステップにおいて、ローカルネームサーバは、中央サーバにサイトの名前とアドレスを登録し、中央ネームサーバからトップレベルドメインが付与される。名前登録ステップにおいて、ローカルネームサーバは、サイト内のリソースに名前を付与し、または、サイトユーザが自分自身の情報の名前をローカルネームサーバに登録する。ドメイン問い合わせステップにおいて、ユーザがドメイン方式に従って内部ドメインを入力すると、ユーザコンピュータは、既存のドメインサービスに混乱をもたらすことなく、特定のローカルネームサーバに内部ドメインを問い合わせる。最後に、サービス実行ステップにおいて、ローカルネームサーバは、要求された方式に従って要求された名前に対する関連ドメインサービスを提供する。

Description

本発明は、従来のドメインネームサービスを改良する新しいネームサービスに関し、より詳しくは、トップレベルドメインでないサイト名または固有名詞をトップレベルドメイン（top-level domain）として使用することができる、分散型サービス方式（distributed service scheme）を取る新しいＵＲＩ型の拡張型内部ドメインネームサービスに関する。

インターネットが発展し普及するに従い、２００１年から、「com」や「gov」などの従来の公式のトップレベルドメインに加えて、新しい公式のトップレベルドメインが採用されている。この採用された公式のトップレベルドメインとして、「name」や「shop」、「biz」などがある。しかし、この採用されたトップレベルドメインは、数が非常に少ないのみならず、トップレベルドメイン「com」と比較して利用度が極めて低い。一方で、別のドメインサービスの形態として、韓国では、サイトのアドレス（名前）をハングル（朝鮮アルファベット）で表現することができる、「ハングルドメイン」と呼ばれるサービスが公表されている。

しかし、実際には、いくつかの新たに導入されたトップレベルドメイン、および、導入されたハングルドメイン名または自国語ドメイン名は、あまり広く普及していない。この理由は、既存のドメインに追加されたいくつかの新しいトップレベルドメインまたはハングルドメインサービスの主な用途が、サイトの検索であり、従来のトップレベルドメイン「com」の役割と同様であるためである。

従来技術におけるドメイン名は、サイト単位でリソース（resource）に名前を付与するのが困難である。したがって、従来技術においては、各サイトにある多数のコンテンツを検索するためには、関係するサイトを見つけた後、そのサイト内の検索方法を用いる必要がある。また、関係するサイトのドメイン名を知らない場合には、別のインターネット検索サイトを用いる必要がある。韓国では、この問題を解決するために、既存のネーム概念（name concept）を拡張する、「ドットアスタリスク（.*）（jumbyul）サービス」または「ドットアスタリスク名」と呼ばれるネーム方式（name scheme）が開発された。このサービスは、サイト内のコンテンツまたはリソースと見なされるデータベース内のリソースに名前を付けて１対１で直接アクセス可能にするという概念のサービスである点で、従来のネームサービスと区別される。本発明では、このような、ＵＲＩ（Uniform Resource Identifier）の概念のネーム方式を、「内部自然ドメイン（Internal Natural Domain）」と呼ぶ。

既存のＩＰアドレスおよびドメインシステムの限界を認識し、固有のＩＰアドレスをすべてのリソースに付与する時代を想定して、現在４バイトからなるＩＰアドレスを拡大する研究が国際的に行われている。すべてのリソースにアクセスするために作られたドメイン、つまり、ＵＲＩ（Uniform Resource Identifier）は、既存のＤＮＳに基づいてシステムを拡張しプロトコルを追加する方向で研究されている。（ＲＦＣ２３９６とＲＦＣ１７３８参照。定義されたプロトコルの総数は２００２年７月で４７個である。定義されたプロトコルの例として、「http」、「ftp」、「gopher」、「mailto」、「telnet」などがある）。しかし、これらのプロトコルは、文法がより複雑になるため、実施は困難であり、また、ドメインシステムが英字に基づいて構築されているという問題がある。

「ドットアスタリスク名」は、韓国で開発された新しい種類のＵＲＩであるプロトコルということができる。「ドットアスタリスク名」は、「com」や「kr」のような従来のトップレベルドメインというよりはむしろ既存のサイト名それ自体がトップレベルドメインになる点で、既存のネーム方式と異なる。そうすることにより、内部ドメイン（つまり、「内部−ドメイン.サイト名（internal-domain.site name）」など）がもう少し強調される。しかし、この「ドットアスタリスク名」は、集中ネームサービス方式であるため、情報が容易に露出可能であり、サービスの自律性が制限されるという問題がある。これは本発明の動機になっている。すなわち、本発明の目的は、既存の「ドットアスタリスク名」のようなネーミング方式（naming scheme）を持つ分散型のサービス方式を取る新しいＵＲＩプロトコルを設計することである。

一方で、既存のネームサーバは、ネームサービス機能と検索機能とが互いに分離された状態で運営されている。すなわち、ネームサーバは、１対１マッピングを行うが、この１対１マッピングが失敗すると、ＭＳＮ検索サービスのようなサービスで検索を行う。このようなデュアルシステムは、ユーザに対して自然でかつ正確な検索を提供することができない。

本発明は、従来技術の上記問題点に鑑みてなされたものであり、サイトネームまたは固有名詞をトップレベルドメインとして使用することができる、分散型のサービス方式を取る新しいＵＲＩ型のネームサービスを提供することを目的とする。

サービス方法の面において、本発明の目的は、以下の機能を提供するネーム検索アクセス方法（セキュリティ）を提供することである。１）トップレベルドメインをその時々に登録し削除することができる中央ネームサービスおよび内部ドメインの管理に適したローカルネームサービスを提供すること、２）拡張型内部ドメイン以外の既存の様々なドメインサービスに影響を与えることなく、ユーザコンピュータが関係サイトのローカルネームサーバに直接アクセスすることによって検索を要求すること、３）ネームサーバの基本機能として類似ドメイン検索機能を備えること、４）検索の最中には特定のユーザのみが特定の名前を検索できるようにすること。

セキュリティ概念を導入する理由は、本発明の適用されるサービス環境がシステム管理者のみならずサイトの一般ユーザにも提供されるからである。すなわち、本発明は、ドメインを完全に公的なリソースのみならず個人が自己の領域内で保護することを欲するリソースにも付与すべき場合をすべて処理しなければならない。

本発明は、サービスの内容、サービスの動機、およびサービスのアプリケーションの点で、例えば、既存の自国語ドメインシステムまたは既存のハングルドメインシステムと相違している。既存の自国語ドメインシステムまたは既存のハングルドメインシステムは、図７に示すように、トップレベルドメインとは関係なく動作するが、本発明は、トップレベルドメインに基づいて、互いに独立した様々なサービスを提供することができる。既存のハングルドメインサービスは、サイトごとに別々の内部ドメイン用ネームサーバを動作させることを前提とせず、ただ任意のハングルドメインサーバを前提としているだけであり、複数の（自国語）ネームサーバを利用してハングルドメインを処理するという概念にも欠けている。一方で、本発明には自国語という概念はなく、むしろすべての文字を包含している。したがって、本発明におけるドメインは、従来の英文字ドメインおよび文字コードと区別することができない。本発明によれば、トップレベルドメインは無限に生成され、ローカルネームサーバはトップレベルドメインの数に応じて存在することができるため、設計のキーポイントは、従来のドメインネームサービスとの調和である。また、本発明の他の目的は、従来技術では別々に提供されている検索サービスとセキュリティ機能とを含むドメインシステム設計を提供することである。

本発明は、従来のドメインネームサービスと異なる形態（form）の名前を異なる方式（scheme）のドメインネームサービスで提供する。すなわち、本発明は、名前の形態、サービス方式、サービスの利用、および使用の概念の点で、従来のドメインネームサービスと異なる。特に、本発明は、ＵＲＩ方式が目標とするように、サイトというよりはむしろ資料(material)および情報への直接アクセスを容易に実現できるようにしている。ドメインの適用をサイト単位の名前からサイト内のリソースに対する名前（内部ドメイン）に拡大し、かつ、英文字以外のハングルを含むすべての文字をサポートしようとする場合、既存のドメインシステムには、内部ドメインへの拡大およびすべての文字のサポートの点で一定の限界がある。特に、本発明は、サイト名の形態がトップレベルドメインであるドメイン形式のためのものであり、既存のドメインサービスシステムの方式と異なる方式でネームサービスを実施する内部ドメインサーバの設計を対象にする。本発明の内部ドメインは、ハングルや英文字に限定されず、任意の文字で表現することができる。また、本発明では、既存のドメインサーバにはないセキュリティ機能が付加されている。

本発明は、それぞれドメインサービス用のプログラムが組み込まれた中央ネームサーバ、ローカルネームサーバ、およびユーザコンピュータを有する。サービス準備ステップにおいて、ローカルネームサーバは、中央サーバにサイトの名前とアドレスを登録し、中央ネームサーバからトップレベルドメインが付与される。名前登録ステップにおいて、ローカルネームサーバは、サイト内のリソースに名前を付与し、または、サイトユーザが自分自身の情報の名前をローカルネームサーバに登録する。ドメイン問い合わせステップにおいて、ユーザがドメイン方式（domain scheme）に従って内部ドメインを入力すると、ユーザコンピュータは、既存のドメインサービスに混乱をもたらすことなく、特定のローカルネームサーバに内部ドメインを問い合わせる。最後に、サービス実行ステップにおいて、ローカルネームサーバは、要求された方式（scheme）に従って要求された名前に対する関連ドメインサービスを提供する。

本発明は、従来技術においてはトップレベルドメイン（つまり、「com」、「net」、「kr」、「jp」など）ではないサイトネームや固有名詞などをトップレベルドメインとして使用する。また、本発明に係る拡張型内部ドメインサービスは、従来のＤＮＳサーバでなく別のサーバによって提供され、かつ、すべてのユーザが登録し削除し管理することができるローカルドメインサービスである。さらに、本発明は、ドメインサービスと密接に関係する検索機能ならびに検索およびアクセスを制限するセキュリティ機能を提供する。

ネーミング方式
「内部−ドメイン.２次ドメイン.トップレベルドメイン（internal-domain.secondary domain.top-level domain）」（例えば、www.uspto.gov）のような形式を取る従来のドメイン表現に照らして、本発明は、「トップレベルドメイン」に対してサイト名、固有名詞、および普通名詞を自由に使用することができ、また、このトップレベルドメインに対する自由な登録および削除を可能にし、また、トップレベルドメインにおける使用に制限がない。記述用語「拡張型（extended）」は、トップレベルドメインの概念が拡張されているという点で用いられ、用語「内部ドメイン（internal domain）」は、内部リソースへのアクセスを目標とする点で定義されている。特に、「拡張型内部ドメイン」は、柔軟なトップレベルドメインのために、一般に使用される従来のドメインとは全く異なる方式（scheme）である。

本発明の上記目的および他の目的、特徴、ならびに他の利点は、添付の図面と共に以下の詳細な説明からもっと明確に理解されるであろう。

以下、添付図面を参照して本発明を詳細に説明する。

基本サービスモデル
本発明は、上記のように、トップレベルドメインを自由に定義することができるネーム構造を提供する。また、本発明は、それぞれ既存のＤＮＳとは異なる方式で動作しつつも既存のネームサービスに影響を与えない、中央ネームサーバ、ローカルネームサーバ、およびクライアントプログラムを提供する。本発明は、セキュリティ機能と検索機能とが互いに有機的に結合されたサービスを提供する。これは、結果として新しい形態のＵＲＩプロトコルをもたらす。

図１は、本発明に係る拡張型内部ドメインサービスのための各構成要素間の関係を示す図である。

ユーザが名前によってネットワーク上の他の情報にアクセスしようとする場合には、その名前に対するＵＲＬ（またはＩＰアドレス）を求めなければならない。情報に対するＵＲＬは、様々な場所に分散されたローカルネームサーバ１０２によって提供される。したがって、ユーザコンピュータ１０１は、まず、自分が所望するリソース（情報）に対するＵＲＬを格納しているローカルネームサーバのアドレスを知るために、ローカルネームサーバのアドレスに対する管理および検索のサービスを提供する中央ネームサーバ１０３に、ローカルネームサーバのアドレスを問い合わせる。この過程において、各ローカルネームサーバ１０２は、トップレベルドメインによって互いに区別され、従来のトップレベルドメイン（公式のトップレベルドメイン）とは無関係に動作する。

ローカルネームサーバ１０２は、ウェブサイトの内部ドメインサービスのためのローカルネームサーバプログラムを備える。ユーザコンピュータ１０１には、本発明のためのクライアントソフトウェアが組み込まれている。このクライアントソフトウェアは、ウェブブラウザと連携して動作し、あるいは、別々のインタフェースを用いてローカルネームサーバおよび中央ネームサーバと一緒に動作する。中央ネームサーバ１０３は、ローカルネームサーバおよびユーザコンピュータのクライアントソフトウェアを制御する。

各ローカルネームサーバ１０２には、一つまたは複数の固有のトップレベルドメインが付与され、このトップレベルドメインは、ローカルネームサーバ１０２と共に中央ネームサーバ１０３に登録される。また、ローカルサイト内のコンテンツ（情報ページ、会員ページなど）にも名前が付与される。付与された名前は、この名前を持つトップレベルドメインに対応するローカルネームサーバ１０２に格納される。

ユーザは、自分が探したい特定のサイトのコンテンツをウェブブラウザのアドレス入力窓（または専用ソフトウェア）にアクセス方式（access scheme）と共に「コンテンツ＿名前．サイト＿名前（contents_name.site_name）」のような名前で入力する。上記アクセス方式は、ＵＲＬの方式と類似しており、リソースにアクセスする方式を表している。このアクセス方式については後で詳しく説明する。

図２は、本発明に係る拡張型内部ドメインサービスのためのユーザコンピュータの動作手順を示すフローチャートである。図２を参照してユーザコンピュータ１０１の動作を詳しく説明する。

ステップ２０１において、ユーザコンピュータ１０１は、ユーザからユーザ問い合わせ表現Ｑを受け取る。ユーザ問い合わせ表現は、「コンテンツ_名前.サイト_名前（content_name.site_name）」の形態でも、通常のドメイン名でもよい。または、本発明に係る検索要求表現であってもよい。

ステップ２０２において、ユーザコンピュータ１０１は、ユーザから入力された名前表現Ｑからトップレベルドメイン（拡張子）ＩＤを抽出する。また、ユーザの要求が検索要求であるか、アプリケーションサービス要求であるかを判断する。ステップ２０３においては、抽出したトップレベルドメインが公式のトップレベルドメイン（つまり、「com」、「net」、「kr」、「jp」、「org」、「shop」、「biz」、「to」など）であるか否かを判断する。抽出したトップレベルドメインが公式のトップレベルドメインである場合は、ステップ２０８において、ユーザコンピュータ１０１は、ユーザ問い合わせ表現Ｑをブラウザ（または既存のＤＮＳに関係するアドレス処理システム）に渡して直接処理させる。

ステップ２０３において抽出されたトップレベルドメインが公式のトップレベルドメインでないと判断した場合は、ステップ２０４において、拡張子Ｄが、ユーザコンピュータ１０１に格納されたローカル拡張子テーブルに存在するか否かを判断する。拡張子Ｄがローカル拡張子テーブルに存在する場合は、ステップ２０９において、拡張子テーブルから拡張子Ｄに対応するローカルネームサーバのアドレスを獲得し、ローカルネームサーバにユーザ問い合わせ表現Ｑを送信して処理を要求する。ローカルネームサーバ１０２にページ要求をする場合には、要求されたサービスに基づいて処理が行われる。この処理については、図４を参照して後で詳しく説明する。

ステップ２０４において拡張子Ｄが拡張子テーブルに存在しないと判断した場合は、ユーザコンピュータ１０１は、ステップ２０５において、中央ネームサーバ２０５に拡張子Ｄを送信して拡張子Ｄに対応するローカルネームサーバのアドレスを要求する。

ユーザコンピュータ１０１の要求に応答して、中央ネームサーバ１０３は、拡張子Ｄに対応するローカルネームサーバのアドレスまたは「値無し」をユーザコンピュータ１０１に送信する。

中央ネームサーバ１０３から受信した値がローカルネームサーバのアドレス値である場合には（ステップ２０６）、ユーザコンピュータ１０１は、ステップ２０９において、該当するアドレスを持つローカルネームサーバに内部ドメイン表現および情報方式（サービス区分）を送信する。ユーザコンピュータ１０１が受信した値が「値無し」である場合には（ステップ２０７）、ユーザコンピュータ１０１は、ステップ２１０において、問い合わせ表現（名前および方式指示情報）Ｑをウェブブラウザ、つまり、ＤＮＳアクセスプログラムのようなアドレス処理モジュールに渡して処理させる。

図３は、本発明に係る拡張型内部ドメインサービスのための中央ネームサーバの動作手順を示すフローチャートである。図３を参照して中央ネームサーバ１０３の動作を詳しく説明する。

ステップ３０１において、中央ネームサーバ１０３は、ユーザコンピュータ１０１から拡張子Ｄと関連付けられたローカルネームサーバのアドレスに対する要求を受信する。ステップ３０２において、中央ネームサーバ１０３は、拡張子Ｄが中央ネームサーバに登録されたトップレベルドメインであるか否かを判断する。すなわち、中央ネームサーバ１０３は、拡張子Ｄが中央ネームサーバ１０３の拡張子テーブル（またはデータベース）に含まれているか否かを判断する。

ステップ３０２において要求された拡張子Ｄが中央ネームサーバ１０３に登録されていると判断した場合は、中央ネームサーバ１０３は、拡張子Ｄに対応するローカルネームサーバのアドレスをユーザコンピュータ１０１に送信する。ステップ３０２において要求された拡張子Ｄが自分の管理しないトップレベルドメインであると判断した場合には、「値無し」をユーザコンピュータ１０１に通知する。

図４は、本発明に係る拡張型内部ドメインサービスのためのローカルネームサーバの動作手順を示すフローチャートである。図４を参照してローカルネームサーバ１０２の動作を詳しく説明する。

ステップ４０１において、ローカルネームサーバ１０２がユーザコンピュータ１０１または中央ネームサーバ１０３からサービス要求を受信すると、要求されたサービスの特性（方式またはプロトコル）に従ってステップ４０２からステップ４０４を行う。

ステップ４０２は、ローカルネームサーバ１０２が受信した問い合わせ表現（名前および方式指示情報）Ｑがページアクセス要求である場合を処理する。この場合、ローカルネームサーバ１０２は、ステップ４０５において、要求されたドメインが自分の管理するドメインであるか否か（つまり、自己の内部ドメインテーブルに存在するか否か）を判断する。ステップ４０５において要求されたドメインが内部ドメインテーブルに格納されていると判断した場合は、ステップ４０７において、要求された内部ドメインに対応するＵＲＬをユーザコンピュータに送信する。ステップ４０５において要求されたドメインが内部ドメインテーブルに格納されていないと判断した場合は、ステップ４０６において、要求されたドメインと類似の名前または内容を持つドメインを検索し、その後、ステップ４０８において、検索したページをユーザコンピュータ１０１に送信する。

ステップ４０３は、検索が最初からローカルネームサーバ１０２において要求される場合を処理する。この場合は、直ちにステップ４０６およびステップ４０８を行って類似ドメイン検索結果をユーザコンピュータ１０１に送信する。

ステップ４０４は、ユーザからの要求がその他のアプリケーションサービスである場合を処理する。すなわち、その他の方式のサービスが要求される場合には、ステップ４０９において、要求されたドメインに対して定義されたアプリケーションサービスモジュールを実行し、その後、ステップ４１０において、そのアプリケーションサービスに従ってユーザに処理結果を送信する。

本発明に係るネームサーバの名前処理手順は、既存のネームシステム（階層方式、アルファベットに基づく体系、キーワード方式など）に混乱をもたらすことなく、既存の公式のトップレベルドメインを含むトップレベルドメインをすべて処理することができる。また、本発明は、トップレベルドメインを管理する中央ネームサーバの選択を優先的にサポートすることができる。すなわち、そうする理由は無いけれども中央ネームサーバが「com」を新しいトップレベルドメインとして使用しようとすれば、既存の「com」のような公式のトップレベルドメインを無駄にすることもできる。

上記基本サービス方法において、与えられたドメインに対するアクセス、検索、その他のサービスを広く「アクセス」サービスと見なすことができ、また、サービス方式またはプロトコルと見なすこともできる。すなわち、本発明は、例えば、既存のＵＲＩの場合、「http://」がウェブページを示すサービスに関するものであり、「ftp://」がファイルを送信するサービスに関するものであるように、様々なタイプのアクセスサービスを提供することができる。ローカルネームサーバは、ウェブページを示すこと（アクセス）、類似のドメインを検索すること（検索）、ファイルを送信すること（その他のアプリケーション）、電話をかけること（その他のアプリケーション）などを含むすべてのサービスを行う。

特定の実施の形態
名前を登録する手順における検索セキュリティおよびアクセスセキュリティのオプションを設定する方法

図５は、本発明の一実施の形態に係る、ローカルネームサーバがページアクセス要求（ＵＲＬ要求）またはその他のアプリケーションサービス要求を受信した場合における、ローカルネームサーバのアクセスセキュリティサービスの動作手順を示すフローチャートである。

本発明において、中央ネームサーバ１０３は、ローカルネームサーバ１０２のアドレスを管理し、ローカルネームサーバ１０２は、特定のサイト内の内部ドメインを管理し、ユーザコンピュータ１０１は、中央ネームサーバおよびローカルネームサーバへのアクセスを行う。

内部ドメイン表現や該当ページのアドレスなどを用いてローカルネームサーバ１０２に名前を登録する内部ドメイン登録者は、名前の検索ができないように、または、特定のユーザのみに検索／アクセス／アプリケーションのサービスが許可されるように、セキュリティを設定する。

ステップ５０１において、ローカルネームサーバ１０２が受信した要求が特定のＵＲＬに対するページアクセス要求またはその他のアプリケーションサービスに対する要求である場合には、ステップ５０２以降のステップを行う。ステップ５０２において、ローカルネームサーバ１０２は、あらかじめ設定されたアクセスセキュリティ情報をチェックする。チェックの結果として、何らセキュリティが設定されておらず、したがって無条件にアクセスが許可される場合には（ステップ５０３）、ステップ５０６において、対応するＵＲＬアドレスをユーザに送信し（要求されたサービスがページアクセス要求である場合）、または、要求された方式に従って関連するサービスを呼び出す（要求されたサービスがその他のアプリケーションサービス要求である場合）。

ステップ５０２のチェックの結果として、アクセスが特定のグループのみに許可されている場合には、ステップ５０４以降のステップを行う。ステップ５０５において、現在のユーザがセキュリティのセッティングで設定されたグループのメンバであるか否かを判断する。すなわち、ユーザに対する認証を行う。ユーザに対する認証が成功した場合には、ステップ５０６において、対応するＵＲＬアドレスをユーザに送信し（要求されたサービスがページアクセス要求である場合）、または、要求された方式に従って関連するサービスを呼び出す（要求されたサービスがその他のアプリケーションサービス要求である場合）。ユーザに対する認証が失敗した場合には、ステップ５０７において、サービスの失敗をユーザに通知する。

図６は、本発明の他の実施の形態に係るローカルネームサーバの類似ドメイン検索セキュリティサービスにおけるセキュリティの動作手順を示すフローチャートである。

図４のステップ４０８において類似ドメイン検索が要求される場合には、図６のステップ６０１以降のステップを行う。要求されたドメインと類似の名前または内容を持つドメインに対する検索は、ステップ６０１よりも前のステップ４０６で既に行われている。ステップ６０２において、ステップ４０６で検索された類似の名前（ドメイン）の各々に対してセキュリティが設定されているか否かを判断する。ステップ６０２の判断の結果として、セキュリティが設定されていない場合には（ステップ６０３）、ステップ６０７において、対応するドメインを検索結果に含め、その後、ステップ６０９において、検索結果をユーザに送信する。ステップ６０２の判断の結果として、セキュリティが無条件検索禁止、つまり、検索不可と設定されている場合には（ステップ６０５）、ステップ６０８において、検索された対応する名前（ドメイン）を検索結果から削除した後、ユーザに送信する。ステップ６０２の判断の結果として、セキュリティの設定が所定のユーザグループに制限されている場合には（ステップ６０４）、ステップ６０６において、現在のユーザがそのグループに属するか否かによって当該ユーザを認証する。ユーザが認証された場合には、ステップ６０７において、対応するドメインを検索結果に含める。ユーザが認証されなかった場合には、ステップ６０８において、対応するドメインを検索結果から削除した後、ステップ６０９において、類似ドメイン検索結果をユーザに送信する。

ユーザがウェブブラウザを用いる場合、一つのウェブブラウザで特定のサービスに対する認証を完了した後は、同じブラウザにおいて再度認証を行うことなく、その特定のサービスをいつでも利用することができる技術の一例として、セッション（session）技術がある。このような技術を用いて、本発明は、ユーザが一度認証された後は、自分がアクセス可能な名前を自由に検索できるように構成することができる。

内部ドメインが入力された場合の実施例
本実施例は、ローカルネームサーバプログラム１０２およびコンピュータを備える。ユーザコンピュータには、ウェブブラウザと連携して動作し別々のインタフェースを通じてローカルネームサーバおよび中央ネームサーバと一緒に動作するクライアントソフトウェア１０１が組み込まれている。また、中央ネームサーバは、ローカルネームサーバとユーザコンピュータのクライアントソフトウェアとを制御する。これは、他の実施例でも同様である。

例えば、インターネットウェブサイト「www.jumbyul.com」における会員および資料に対する内部ドメインサービスを行うとすれば、ウェブサイトの管理者は、ローカルネームサーバ１０２の設備を整えて、中央ネームサーバにトップレベルドメイン「ドットアスタリスク（jumbyul）」の登録をローカルネームサーバのＵＲＬアドレス情報（例えば、「jumbyul.com」）と共に申し込む。ウェブサイトの管理者は、ウェブサイト内の情報（リソース）に「サービス_紹介.ドットアスタリスク（service_introduction.jumbyul）」のような内部ドメインを与える。

ユーザは、自分のコンピュータ１０１でウェブページ「サービス_紹介.ドットアスタリスク（service_introduction.jumbyul）」を探すために、ウェブブラウザのアドレス入力窓（または専用ソフトウェア）に問い合わせ表現「サービス_紹介.ドットアスタリスク（service_introduction.jumbyul）」を入力する（ステップ２０１）。ユーザコンピュータは、入力された表現「サービス_紹介.ドットアスタリスク（service_introduction.jumbyul）」からトップレベル（拡張子）「ドットアスタリスク（jumbyul）」を抽出する（ステップ２０２）。また、問い合わせ表現に含まれる方式から、ユーザの要求がページアクセス要求であるか、検索要求であるか、その他のアプリケーションサービス要求であるかを判断する（ステップ２０２）。また、抽出されたトップレベルドメイン（本実施の形態では「ドットアスタリスク（jumbyul）」）が周知の公式のトップレベルドメイン（例えば、「com」、「net」、「kr」、「jp」、「org」、「shop」、「biz」、「to」など）であるか否かを判断する。「ドットアスタリスク（jumbyul）」は公式のトップレベルドメインでないため、ユーザコンピュータ１０１は、中央ネームサーバに問い合わせを送信する（ステップ２０５）。

中央ネームサーバ１０３は、「ドットアスタリスク（jumbyul）」が自分に登録されているドメインであるか否かを確認し（ステップ３０２）、「ドットアスタリスク（jumbyul）」に対応するローカルネームサーバのＵＲＬ（「jumbyul.com」）をユーザコンピュータに通知する（ステップ３０３）。ユーザコンピュータ１０１は、受信した「ドットアスタリスク（jumbyul）」に対応するローカルネームサーバのアドレス値として「jumbyul.com」を持つローカルネームサーバに問い合わせ表現「サービス_紹介.ドットアスタリスク（service_introduction.jumbyul）」および方式（ページアクセス、検索、その他のアプリケーションサービスなどの区分）の情報を送信する。

処理要求を受けたローカルネームサーバ（「jumbyul.com」）は、要求されたサービスの特性に従って対応するページをユーザのブラウザに送信する（ステップ４０７）。対応するページがない場合には、関連する名前または類似の名前のリストを持つ検索ページをユーザのブラウザに送信し（ステップ４０８）、または、その他のアプリケーションサービスを実行する（ステップ４１０）。

本発明において、ローカルネームサーバのテーブルに格納されユーザコンピュータに提供される情報は、ＵＲＬやＩＰなどの情報である。

既存のアルファベットドメインが入力された場合の実施例
ユーザは、自分自身のコンピュータ１０１に「www.aranes.com」のような通常のドメイン名を入力する。

ユーザコンピュータは、入力された表現「www.aranes.com」からトップレベルドメイン「com」を抽出する。このトップレベルドメイン「com」は、周知の公式のトップレベルドメイン（例えば、「com」、「net」、「kr」、「jp」、「org」、「shop」、「biz」、「to」など）であるため、「www.aranes.com」は、ユーザコンピュータの一般的なアドレス処理モジュールに送信されて処理される。

認識されない拡張子が入力された場合の実施例
ユーザが自分自身のコンピュータ１０１に「www.abc.cc」のような、公式のトップレベルドメインを持たない問い合わせ表現を入力すると、ユーザコンピュータは、上記表現からトップレベルドメイン「cc」を抽出する。

次に、ユーザコンピュータは、ユーザの要求が、ページアクセス要求であるか、検索要求であるか、その他のアプリケーションサービス要求であるかなどを、スキームを用いて判断する。このトップレベルドメイン（「cc」）は、周知のドメイン（例えば、「com」、「net」、「kr」、「jp」、「org」、「shop」、「biz」、「to」など）でないため、中央ネームサーバにアドレスの判断を要求する（ステップ２０５）。

中央ネームサーバ１０３は、トップレベルドメイン「cc」が登録されているか否かを判断する。「cc」が登録されていない場合には、中央ネームサーバ１０３は、「情報無し」をユーザコンピュータ１０１に通知する（ステップ３０４）。そして、ユーザコンピュータ１０１は、「情報無し」に応答して、「www.abc.cc」をユーザコンピュータの基本ドメイン処理モジュール（ブラウザまたは他の通信モジュール）に渡す（ステップ２０８）。

ドメインサーバの類似ドメイン検索機能の実施例
本実施例は、ユーザが「ワールドカップ準決勝.サッカー？（worldcupsemifinal.soccer?）」のように「?」を付加して検索を要求し、または、「ワールドコップ準決勝.サッカー（worldcopsemifinal.soccer）」のようにスペルの間違ったドメイン表現を入力した場合の処理に関する。ユーザコンピュータは、この問い合わせ表現に対してトップレベルドメイン「サッカー（soccer）」の内部ドメインを提供するローカルネームサーバ１０２のＵＲＬ（例えば、「jdns.sports.com」など）を中央ネームサーバから受信した後、入力されたドメイン表現をローカルネームサーバのアドレスに送信する。

「?」が末尾に付け加えられた場合、ローカルネームサーバ（この場合は「jdns.sport.com」）は、ユーザの要求が検索要求であると判断し、表現「ワールドカップ準決勝（worldcupsemifinal）」と全部または一部の文字列を共有しまたは意味的に共有する類似ドメインを検索する。「ワールドコップ準決勝.サッカー（worldcopsemifinal.soccer）」が１対１の方法で検索されない場合には、類似検索を同様に行い、検索結果をクライアントコンピュータ１０１に送信する。

名前を登録する手順においてサービスセキュリティオプションを利用する実施例
ユーザがＫＴ会社のローカルネームサーバ１０２に名前「ワールドカップ準決勝神話.ＫＴ（worldcupsemifinalmyth.KT）」を登録する場合、自分や自分の友達のみがＫＴ会社のローカルネームサーバによって提供されるサービス（ページアクセス、検索、その他のアプリケーション機能）にアクセスできるように、「公開（open）」、「非公開（secret）」、「グループのみ可能（allowed to only group）」のようなセキュリティ情報を設定する。

ローカルネームサーバは、名前「ワールドカップ準決勝神話.ＫＴ（worldcupsemifinalmyth.KT）」に対して要求されたサービス方式に従って、ＵＲＬを送信し、ＵＲＬを検索結果に含め、または、ＵＲＬを参照してアプリケーションサービスの提供前にあらかじめ設定されたセキュリティ情報を見る。設定されたセキュリティ情報が「公開（open）」である場合には、対応するＵＲＬを無条件にユーザに送信し、または、無条件に検索結果に含めてユーザに送信する。

設定されたセキュリティ情報が「非公開（secret）」である場合には、対応するネームドメインを無条件に検索から除外する（ステップ６０８）。

設定されたセキュリティ情報が「グループのみ可能（allowed to only group）」である場合には、サービスを要求したユーザがグループに属するユーザであるか否かを判断し、この判断の結果に従って、サービスを提供するか否かを決定する。

好適な実施例によれば、「非公開（secret）」セキュリティオプションは、類似ドメイン検索において類似ドメイン検索結果をユーザに提供する結果から除外する場合にのみ該当する。ＵＲＬサービスまたはその他のアプリケーションサービスを無条件に利用することができないというオプションの理由は、このオプションがドメイン登録の目的と矛盾するため現実的ではないからである。

方式（scheme）の指示（indication）の実施例
ユーザは、自分自身のコンピュータ１０１において拡張型内部ドメインで様々なサービスを受けようとするとき、サービス内容を指示する形式（format）を指定しなければならない。例えば、ユーザは、「特許登録.特許庁（patentregistration.kipo）」と入力する場合は、関係するページにアクセスするサービス（http://に対応）を意味し、「特許登録と.特許庁?（patentregistrationsection.kipo?）」と入力する場合は、類似ドメイン検索を意味し、「>email特許登録と.特許庁（>email patentregistrationsection.kipo）」と入力する場合は、内部ドメインに関連する電子メールアドレスにメールを書くことを意味し、「>tel特許登録と.特許庁（>tel patentregistrationsection.kipo）」と入力する場合は、関連する電話番号による音声通信を意味するように、形式を設定することができる。留意すべきは、前に付ける記号「＞」はただ単に模範的な例にすぎず、特定のトップレベルドメインに対するサブスキームを実施するその機能は、様々な構文（syntax）において具体化することができる。

ユーザが定義された文法に従ってサービス内容を選択し内部ドメインを入力すると、ユーザコンピュータ１０１は、その内部ドメインのトップレベルドメインを抽出する。ユーザコンピュータ１０１は、そのトップレベルドメインを対応するローカルネームサーバ１０２に送信してサービスを要求する。ローカルネームサーバは、内部ドメインおよびサービスの特性に従って関連プログラムを実行することにより、対応するサービスを実行する。

複数のアクセスサービスを表現し選択する方法はいろいろ考えられる。例えば、ユーザが本発明の対象である拡張型内部ドメインを用いてＦＴＰ（file transfer protocol）を希望する場合には、「>ftp内部名.トップレベル名（>ftp internalname.top-level name）」のような形式を取ることができる。ユーザが電子メールを希望する場合には、「>email名.トップレベル（>email name.top-level）」のような形式を取ることができる。

また、ＨＴＭＬやＸＧＭＬのような標準タグ言語において、本発明の対象である拡張型内部ドメインを指示し、これをユーザコンピュータのドメインサービスプログラムによって処理することにより、既存のドメインシステムのようなシステムを利用することができる。例えば、ユーザは、ＨＴＭＬ文書中に「<href=jbn://資料名.トップレベル名（<href=jbn://materialname.top-levelname）」を入力することによってウェブ文書を作成することができる。他のユーザがウェブブラウザによって上記文書を見て、「<href=jbn://資料名.トップレベル名（<href=jbn://materialname.top-levelname）」に対応する部分をクリックすると、ネームサービスプログラムは、リンク情報の「jbn://」を検出し、それを最初に処理する。同様に、ユーザが「jbn://>ftp資料名.トップレベル名（jbn://>ftp materialname.top-levelname）」を入力すると、「資料名.トップレベル名（materialname.top-levelname）」に格納されたファイルの転送サービスを提供することができる。この場合、「jbn://」は、本発明のネームサービスをその他のドメインサービスと区別するためのトップレベルスキームであり、「>email」などは「jbn://」の細部スキームであると言える。

また、本発明の各実施例は、様々な種類のコンピュータによって実施される動作を実行するためのプログラム命令を含むコンピュータ読み取り可能な媒体を含んでいる。

以上、本発明の好適な実施の形態について説明の目的で述べてきたが、当業者にとっては、添付の特許請求の範囲に記載された発明の範囲および精神を逸脱せずに、様々な修正、追加、および代替が可能であることは、明らかである。

国際標準フレームにおいて定義された公式のトップレベルドメイン（「com」、「net」、「org」、「kr」、「jp」など）や、「スウウォン大.大学.韓国（suwonuniversity.university.korea）」のような階層型ハングルドメイン、「スウウォン大（suwonuniversity）」のような、キーワード方式として知られている、拡張子の無いドメインを含むドメインサービスがあるが、これらすべてのドメインの利用は、サイトまたは主要サービスに名前を付与するためである。一方で、すべてのユーザが容易にインターネット空間に名前を付与し、当該名前を削除／管理することができ、または、あたかもサイト名が「com」に登録されるかのようにサイト名を持つトップレベルドメインを登録することができるということは、ある訳がない。ＵＲＩの研究はすべてのリソースに対するアクセスを容易にするために国際的に進歩しているが、それらは既存のドメイン名の形態と既存のサービス方式を堅持しており、英文字をまず第一に考慮しており、一般人には複雑すぎて使用できないため、どの研究も常用化には至っていない。

本発明は、トップレベルドメインを自由に登録／削除することができ、また、サイト単位でなくサイト内の多数の情報単位に名前を付与することができる「拡張型内部ドメイン」をサイト単位で別々に管理することができる技術を提供する。したがって、「拡張型内部ドメイン」の常用化が可能になり、その結果、次のような社会的変化が生じる。

ドメイン利用の概念がサイト管理者の範囲からインターネットユーザによる利用の範囲にまで拡大するため、現在の名前空間と比較して、ユーザは膨大な名前空間を利用することができる。数百万の名前を持つ一つの「.com」は今や飽和状態であるが、拡張型内部ドメインシステムは、天文学的な名前空間を持つため、飽和の問題はない。

各サイトにおいて内部リソースおよび会員にネームサービスを提供するために別々のネームサーバを管理／運営することにより、外部のドメインサーバに名前を登録／通知する必要がなくなり、商業的な要求事項を満たしつつ、セキュリティを向上することができる。

ユーザは、ウェブサイトにアクセスした後にウェブサイトの内部情報に入ることなく、必要とする内部情報に直接アクセスすることができるため、サイトの構築および情報の配列に大きな変化をもたらすことができる。これにより、インターネットの利用それ自体に根本的な変化を引き起こし、情報検索生産性の増大につながる。

インターネットがユーザ中心、情報中心のインターネットに再編されるため、電子商取引が盛んになり、サイト中心のインターネットからユーザおよび情報中心のインターネットへの質的変化をもたらすことができる。

本発明は、既存のドメイン概念から出発していくつかのアプリケーションを拡大し具体化したものと考えることができるが、一方で、既存のドメインシステムにおいて機能の拡張を図るためにＵＲＩ技術の限界を克服し、すべてのリソースにアクセスするというＵＲＩの目的を効果的に達成している。

本発明に係る拡張型内部ドメインサービスに必要な構成要素間の関係を示す図本発明に係る拡張型内部ドメインサービスのためのユーザコンピュータの動作手順を示すフローチャート本発明に係る拡張型内部ドメインサービスのための中央ネームサーバの動作手順を示すフローチャート本発明に係る拡張型内部ドメインサービスのためのローカルネームサーバの動作手順を示すフローチャート本発明の一実施の形態に係るローカルネームサーバのアクセスセキュリティサービスの動作手順を示すフローチャート本発明の他の実施の形態に係るローカルネームサーバの類似ドメイン検索セキュリティサービスにおけるセキュリティの動作手順を示すフローチャート従来のドメインサービスに係るハングルドメインサービスの動作手順を示すフローチャート

Claims

ユーザコンピュータに組み込まれたクライアントモジュールと、
ネットワークを介して前記ユーザコンピュータと接続されたローカルネームサーバに組み込まれたローカルネームサーバモジュールと、
ネットワークを介して前記ユーザコンピュータと接続された中央ネームサーバに組み込まれた中央ネームサーバモジュールと、
前記中央ネームサーバに格納され、拡張子及び前記拡張子に対応するローカルネームサーバのアドレスを保持する拡張子テーブルと、を備え、
前記クライアントモジュールは、
ユーザから入力されたユーザ問い合わせ表現から拡張子を抽出し、抽出した拡張子が公式のトップレベルドメインであるか否かを決定し、前記抽出した拡張子が公式のトップレベルドメインである場合には、前記ユーザ問い合わせ表現を前記ユーザコンピュータのアドレス処理モジュールに送信し、前記抽出した拡張子が公式のトップレベルドメインでない場合には、前記ユーザ問い合わせ表現を前記中央ネームサーバに送信し、
前記中央ネームサーバモジュールは、
前記拡張子テーブルを参照して、前記ユーザ問い合わせ表現から抽出された拡張子に対応するローカルネームサーバのアドレスを検索し、検索したアドレスを前記ユーザコンピュータに送信し、
前記ローカルネームサーバモジュールは、
前記ユーザ問い合わせ表現に対応するサービスを提供する、
拡張型内部ドメインサービスシステム。
前記ユーザコンピュータに格納され、第１拡張子及び第２拡張子に対応するローカルネームサーバのアドレスを保持するローカル拡張子テーブル、をさらに備え、
前記クライアントモジュールは、
前記抽出した拡張子が公式のトップレベルドメインでない場合には、前記ローカル拡張子テーブルを参照して、前記ユーザ問い合わせ表現から抽出された拡張子に対応するローカルネームサーバのアドレスを検索し、前記ローカルネームサーバのアドレスが前記ローカル拡張子テーブルを参照して検索されない場合には、前記ユーザ問い合わせ表現を前記中央ネームサーバに送信する、
請求項１記載のシステム。
前記ローカルネームサーバに格納され、内部ドメイン及び前記内部ドメインに対応するリソースのアドレスを保持する内部ドメインテーブル、をさらに備え、
前記ローカルネームサーバモジュールは、
受信したユーザ問い合わせ表現を分析し、ユーザのサービス要求がページアクセス要求か類似ドメイン検索要求かその他のアプリケーションサービス要求かを決定し、
ユーザのサービス要求がページアクセス要求である場合には、前記内部ドメインテーブルに保持された内部ドメインを前記ユーザ問い合わせ表現と比較し、対応するリソースのアドレスを前記ユーザコンピュータに送信する、
請求項１記載のシステム。
前記ローカルネームサーバモジュールは、
ユーザのサービス要求が類似ドメイン検索要求である場合には、前記内部ドメインテーブルに保持された内部ドメインの中から、前記ユーザ問い合わせ表現から抽出された内部ドメインと類似するドメインを検索し、検索したドメインを前記ユーザコンピュータに送信し、
ユーザのサービス要求がその他のアプリケーションサービス要求である場合には、要求された内部ドメインに対する定義されたアプリケーションサービスを実行し、当該実行の結果を前記ユーザコンピュータに送信する、
請求項３記載のシステム。
前記内部ドメインテーブルは、
前記内部ドメインテーブルに格納された内部ドメインと一緒にユーザの権限を保持し、
前記ローカルネームサーバモジュールは、
前記内部ドメインテーブルを参照して、前記サービスを要求したユーザを認証し、当該認証の結果に従って前記ユーザ問い合わせ表現に対応するサービスを前記ユーザに提供する、
請求項３記載のシステム。