JP2000148636A - アドレス統合方法、装置、及び記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】サービス毎の複数アドレスを各ユーザにユニー
クに付与されるユーザＩＤに統合し、ユーザはサービス
を意識しなくても宛先に同一のユーザＩＤを利用するこ
とを可能にするアドレス統合方法を提供することを目的
とする。 【解決手段】あるサービスの発信に係る第１のメッセー
ジを受信したアプリケーションが、必要に応じて該メッ
セージ内の宛先アドレスと該サービスの種別を表すサー
ビス種別情報とを含む第２のメッセージをアドレス変換
を行う装置に送信することによりアドレス変換を要求
し、該アドレス変換を行う装置が該宛先アドレスと該サ
ービス種別情報とから該宛先アドレスを該サービスに固
有のアドレスである正規アドレスに変換し、該正規アド
レスを含む第３のメッセージを該アプリケーションに返
信し、該アプリケーションが該第１のメッセージにおけ
る該宛先アドレスを該正規アドレスに置き換えて送信を
行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワーク上の
サービスにおけるアドレス統合に係り、特に、ＩＰ電話
・電子メール・ファイル転送・ホームページ・インター
ネットファックス等の複数のサービスを同一のアドレス
を用いて利用するアドレス統合方法、装置、アドレス変
換等を行うプログラムを記録した記録媒体に関する。

【０００２】

【従来の技術】ＩＰ（インターネットプロトコル）電話
・電子メール・ファイル転送・ホームページ・インター
ネットファックス等のサービスは実現の形態（プロトコ
ル）がそれぞれ異なるため、このようなサービスを提供
するネットワークにおいては、同じ一人のユーザに対し
てサービス毎に複数のアドレスが付与されている。すな
わち、インターネットでサービスを利用する主な形態に
は、直接相手端末に対して通信を行う形態（例えばＩ
Ｐ電話）、サービスを提供するアプリケーションサー
バと通信を行う形態（例えば電子メール）等があり、そ
のため同じユーザに対する通信であっても複数の宛先が
存在し、これらの複数の宛先はアドレッシング方法が異
なるため、サービス毎に異なるアドレス体系が発生し、
結果として同じユーザがサービス毎に異なる複数のアド
レスを持つことになる。

【０００３】例えば、“suzuki”というユーザに対し
て、 電子メール：suzuki(a)abc.co.jp（（ａ）はアットマー
ク） ファイル転送：ftp.abc.co.jp/suzuki ホームページ：http.abc.co.jp/suzuki ＩＰ電話：suzuki.abc.co.jp のようにそれぞれのサービスに対して異なるアドレスが
付与される。

【０００４】また、従来技術におけるアドレス解決方法
として例えばＴＣＰ／ＩＰネットワークにおいては、ホ
スト名（コンピュータ名）とＩＰアドレスを解決するＤ
ＮＳ（Domain Name System) 等がある。図１は、サービ
ス毎のアドレス体系及びＤＮＳによるアドレス解決の範
囲を示す図であり、メールサービスを提供するメールサ
ーバ１、ＦＴＰやＨＴＴＰを提供するファイルサーバ
２、ＩＰ電話やメッセージサービスを提供する利用端末
３を示している。同図に示すようにそれぞれがＴＣＰ／
ＩＰにおけるアドレスとアプリケーションのポート番号
を有し、メールサーバ１とファイルサーバ２は、ユーザ
が接続毎に上位アプリケーションで指定するアドレスも
有している。また、各サーバ等はＴＣＰ／ＩＰアドレス
に対応するドメイン名（domain name ）を有しており、
ＤＮＳによりドメイン名からＴＣＰ／ＩＰアドレスが解
決される。

【０００５】

【発明が解決しようとする課題】上記従来の技術による
と、発信元のユーザは同一ユーザに対する通信であって
も宛先としてサービス毎に異なる体系のアドレスを指定
して通信をする必要があり、サービス毎にアドレスを付
与、管理しなければならないという問題点があった。ま
た、ＤＮＳ等の既存のネームシステムは、ネームから解
決できる宛先は基本的にはホスト（コンピュータ）であ
り、コンピュータを利用するユーザをネームシステムが
指定することはできない。

【０００６】本発明は、上記の点に鑑みなされたもので
あり、サービス毎の複数アドレスを各ユーザにユニーク
に付与されるユーザＩＤに統合し、ユーザはサービスを
意識しなくても宛先に同一のアドレス、つまりユーザＩ
Ｄを利用することを可能にするアドレス統合方法、装
置、アドレス変換等を行うプログラムを記録した記録媒
体を提供することを目的とする。

【０００７】

【課題を解決するための手段】上記の目的を達成するた
めに本発明は次のように構成される。ネットワーク上で
提供される複数のサービスにおけるユーザのアドレスを
サービスに依らないアドレスに統合するアドレス統合方
法であって、あるサービスの発信に係る第１のメッセー
ジを受信したアプリケーションが、必要に応じて該メッ
セージ内の宛先アドレスと該サービスの種別を表すサー
ビス種別情報とを含む第２のメッセージをアドレス変換
を行う装置に送信することによりアドレス変換を要求す
る要求ステップと、該アドレス変換を行う装置が該宛先
アドレスと該サービス種別情報とから該宛先アドレスを
該サービスに固有のアドレスである正規アドレスに変換
する変換ステップと、該アドレス変換装置が該正規アド
レスを含む第３のメッセージを該アプリケーションに返
信するステップと、該アプリケーションが該第１のメッ
セージにおける該宛先アドレスを該正規アドレスに置き
換えて送信する送信ステップとを有するアドレス統合方
法である。

【０００８】上記構成において本発明のアドレス統合方
法は、前記アプリケーションが前記要求ステップと前記
送信ステップとを含む処理モジュールのみから、又は、
該処理モジュールと前記サービスに係るアプリケーショ
ンとからなる構成でもよい。上記構成において本発明の
アドレス統合方法は、前記アプリケーションが前記要求
ステップと前記送信ステップとを含む処理モジュールを
内蔵するアプリケーションでもよい。

【０００９】また、上記構成において本発明のアドレス
統合方法は、前記要求ステップと前記送信ステップとを
含む処理モジュールが、汎用コンピュータ上又は前記ア
ドレス変換を行う装置上に配置される構成でもよい。更
に、上記構成において、前記変換ステップは、前記アド
レス変換を行う装置が、ユーザ固有のアドレスに対応す
る各サービスに固有の前記正規アドレスが記述されたテ
ーブルを参照することによりアドレスを変換するステッ
プを有してもよい。

【００１０】上記の目的を達成するために本発明は次の
ようにも構成される。本発明は、あるアドレスを、ネッ
トワーク上で提供されるサービスに固有のアドレスに変
換するアドレス変換装置であって、一のアドレスと、サ
ービスの種別を示すサービス種別情報とを含む第１のメ
ッセージを受信する手段と、該一のアドレスと該サービ
ス種別情報とから該一のアドレスを該サービスに固有の
アドレスである正規アドレスに変換する変換手段と、該
正規アドレスを含むメッセージを該第１のメッセージの
送信元に返信する手段とを有するアドレス変換装置であ
る。

【００１１】上記の構成において、前記変換手段は、ユ
ーザ固有のアドレスに対応する各サービスに固有の前記
正規アドレスが記述されたテーブルを参照することによ
り前記一のアドレスを変換する手段を有してもよい。上
記の目的を達成するために本発明は次のようにも構成さ
れる。本発明は、あるアドレスを、ネットワーク上で提
供されるサービスに固有のアドレスに変換するアドレス
変換プログラムを記録したコンピュータ読み取り可能な
記録媒体であって、該プログラムは、一のアドレスと、
サービスの種別を示すサービス種別情報とを含む第１の
メッセージを受信し、該一のアドレスと該サービス種別
情報とから該一のアドレスを該サービスに固有のアドレ
スである正規アドレスに変換する変換処理を行い、該正
規アドレスを含むメッセージを該第１のメッセージの送
信元に返信することをコンピュータに実行させるアドレ
ス変換プログラムを記録したコンピュータ読み取り可能
な記録媒体である。

【００１２】上記構成において、前記変換処理は、ユー
ザ固有のアドレスに対応する各サービスに固有の前記正
規アドレスが記述されたテーブルを参照することにより
前記一のアドレスを変換する処理を含む構成でもよい。
上記の目的を達成するために本発明は次のようにも構成
される。本発明は、あるアドレスをネットワーク上で提
供されるサービスに固有のアドレスに変換するアドレス
変換手段と連携して、ユーザ固有のアドレスをサービス
に固有のアドレスに置き換えるアドレス処理プログラム
を記録したコンピュータ読み取り可能な記録媒体であっ
て、該プログラムは、あるサービスの発信に係る第１の
メッセージを受信し、必要に応じて該メッセージ内の宛
先アドレスを抽出し、該宛先アドレスが前記ユーザ固有
のアドレスである場合に該宛先アドレスと該サービスの
種別を表すサービス種別情報とを含む第２のメッセージ
を前記アドレス変換手段に送信し、該アドレス変換手段
から該サービスに固有のアドレスである正規アドレスを
含む第３のメッセージを受信し、該第１のメッセージの
宛先アドレスを該正規アドレスに置き換えて送信を行う
アドレス処理をコンピュータに実行させるアドレス処理
プログラムを記録した記録媒体である。

【００１３】また、上記構成において本発明の記録媒体
に記録されたプログラムはＳＭＴＰパケットを監視し、
ＲＣＰＴパケットのみを前記第１のメッセージとして受
信して前記アドレス処理を行うようにも構成される。ま
た、上記構成において本発明の記録媒体に記録されたプ
ログラムは、前記アドレス処理が前記ユーザ固有のアド
レスをＦＴＰサーバにおけるユーザディレクトリに変換
する処理を含み、ＦＴＰサーバへの接続のためのパケッ
トを前記第１のメッセージとして受信して前記アドレス
処理を行い、該ＦＴＰサーバへのログイン完了メッセー
ジを一時蓄積し、該アドレス処理により得られた該ユー
ザディレクトリへの変更を該ＦＴＰサーバに要求し、該
ユーザディレクトリへの変更が完了すると該ログイン完
了メッセージを送信することとしてもよい。

【００１４】更に、上記構成において本発明の記録媒体
に記録されたプログラムは、ＨＴＴＰパケットを監視
し、リクエストメッセージのみを前記第１のメッセージ
として受信して前記アドレス処理を行う構成でもよい。
本発明によれば、サービス毎の複数アドレスを各ユーザ
にユニークに付与されるアドレスすなわちユーザＩＤに
統合し、ユーザはサービスを意識しなくても宛先に同一
のアドレスを利用することが可能になる。

【００１５】また、本発明によれば、アプリケーション
サーバヘのユーザアドレス置き換えの処理を行うモジュ
ール追加やそのような処理モジュール内蔵アプリケーシ
ョンの追加によりユーザアドレス変換が実現できるた
め、アプリケーションプロトコルには変更の必要がな
く、サーバ側、クライアント側のいずれのアプリケーシ
ョンも既存のソフトウェアを無改造で利用することがで
きる。

【００１６】

【発明の実施の形態】図２は本発明の一実施例における
全体構成を示す図である。同図に示すように、本実施例
は、アドレス解決サーバ１０、アプリケーションサーバ
１２〜１８、ユーザ端末２２〜２４から構成されてお
り、各装置はＴＣＰ／ＩＰネットワーク接続され、各装
置はＴＣＰ／ＩＰネットワークを介してインターネット
３２及びＨ．３２３ゲートウェイ２８経由で電話交換網
３０と接続されている。また、インターネット３２はド
メイン名とＩＰアドレスの変換を行う上位ＤＮＳ３４と
接続されている。更に、インターネットにはユーザ端末
２２等と通信を行うユーザ端末３６が接続されている。

【００１７】次に、各装置の機能の概要を説明する。ア
ドレス解決サーバ１０は、クライアントもしくはアプリ
ケーションサーバからの要求を受け、アドレス解決を行
う機能を有する。本実施例ではアドレス解決サーバ１０
内にはサービスにかかわりなくユーザ毎にユニークに付
与されるユーザＩＤと各サービスの本来のアドレス群が
データベースに管理されている。アドレス解決要求時に
はサービス種別を示すサービス種別情報を付加されてた
情報を受信することにより、該当するサービスのアドレ
スを解決する。既存のＤＮＳ（Domain Name System）／
ＡＮＳ（ATM Name System ）インタフエースを備えるこ
とで、ＤＮＳ／ＡＮＳのプロトコルによる解決にも対応
可能である。

【００１８】アプリケーションサーバ１２〜１８は各サ
ービスを提供する機能を有する。メールサーバ１２はＳ
ＭＴＰ（Simple Mail Transfer Protocol ）によりメー
ルサービスを提供し、ｈｔｔｐプロキシー１４はＨＴＴ
Ｐ（Hyper Text Transfer Protocol）によりＷＷＷによ
るサービス等を提供し、ｆｔｐプロキシー１６はＦＴＰ
（File Transfer Protocol）によりファイル転送サービ
スを提供する機能を有する。また、Ｈ．３２３ゲートキ
ーパ１８はＩＰ電話サービスを提供する機能を有し、宛
先電話番号を基に宛先ゲートウェイのＩＰアドレスを割
り出す等の機能を有している。アプリケーションサーバ
１２〜１８に後述のユーザＩＤ処理モジュール２０を内
蔵することによりユーザＩＤのアドレス指定による通信
を受け付けることが可能になる。

【００１９】ユーザＩＤ処理モジュール２０は、通信の
宛先情報を監視し、宛先アドレスがユーザＩＤで指定さ
れている場合には、ユーザＩＤを本来のアドレスに置き
換えを行う機能を有するモジュールである。ユーザＩＤ
処理モジュール２０は、アドレス解決サーバ１０と連携
して動作する。ユーザ端末２２、２４はユーザが実際に
利用する端末であり、クライアント側アプリケーション
がユーザ端末２２、２４に搭載される。また、ユーザ端
末２２、２４はアドレス変換サーバ１０とのインタフエ
ースを有する後述のクライアントモジュール２６を搭載
することで、ユーザＩＤ変換機能を持ったクライアント
アプリケーションの利用も可能である。

【００２０】クライアントモジュール２６はアドレス解
決サーバ１０上ヘユーザログイン位置登録や設定変更を
行う機能を有する。また、ユーザＩＤ対応アプリケーシ
ョンが直接アドレス解決サーバ１０にアドレス解決を要
求するための前述したユーザＩＤ処理モジュールの機能
を提供する。次に、図３を用いて本実施例の基本的動作
を説明する。同図はユーザ１（４０）がユーザ２（４
２）とアプリケーション４４、４６にて通信を行う場合
を示している。アプリケーション４４は前述のユーザＩ
Ｄ処理モジュールを含み、図２におけるユーザ端末２
２、２４上のクライアント又はアプリケーションサーバ
１２〜１８上にあり、どちらの場合でも基本的な動作は
同様である。また、同様にしてアプリケーション４６
は、ユーザ端末３６上のクライアントアプリケーション
又はユーザ端末３６にサービスを提供するアプリケーシ
ョンサーバ（図２には示していない）上のアプリケーシ
ョンである。ここでは、ユーザ１（４０）のユニークな
ユーザＩＤをuser１、ユーザ２（４２）のユニークなユ
ーザＩＤをuser２、この例で使用するアプリケーション
４４のサービス種別情報をapl ＿a とし、アプリケーシ
ョン４４に固有のユーザ１（４０）のアドレスをTE１、
apl ＿aに固有のユーザ２（４２）のアドレスをTE２と
する。

【００２１】同図において、ユーザ１（４０）は宛先ア
ドレス指定を通信相手のユーザＩＤすなわちuser２にて
行う（ステップ１）。ユーザＩＤであるuser２を受け取
ったアプリケーション４４は、user２が本来のアドレス
かユーザＩＤか識別を行う（ステップ２）。この識別は
アプリケーション固有の形式か否かを比較することによ
り容易に識別できる。識別の結果、本来のアドレスであ
ればアドレス解決サーバ１０との通信を行わずにそのま
ま送信処理を続行する。ユーザＩＤであればユーザ情報
データベースを持つアドレス解決サーバ１０に対し、本
来のアドレスヘの変換要求を行う（ステップ３）。この
際、アプリケーション４４はあらかじめ規定されている
サービス種別情報（apl ＿a ）を付加する。要求を受け
取ったアドレス解決サーバ１０はユーザＩＤ（user２）
とサービス種別情報（apl ＿a ）により解決すべきアド
レスとユーザ情報データベースからTE２を検索し、要求
元のアプリケーション４４に対してTE２を回答する（ス
テップ４）。アプリケーション４４は受け取ったアドレ
スTE２を宛先として置き換え、ユーザ２（４２）側のア
プリケーション４６にアドレスTE２を宛先として発信し
（ステップ５）、通信を実行する（ステップ６）。な
お、上記アプリケーション４４における動作は、ユーザ
ＩＤ処理モジュールにより行われている。

【００２２】図４はアドレス解決サーバ１０内のユーザ
情報データベースの例を示す図である。同図に示すよう
に、各ユーザＩＤに対し、ログインする端末のＩＰアド
レス、及びメールアドレス、ホームページアドレス等の
サービス種類に対応したアドレスが格納されている。図
５はアドレス解決サーバ１０の動作を示すフローチャー
トである。同図を用いてアドレス解決サーバ１０の動作
を説明する。ユーザＩＤ処理モジュールからユーザＩＤ
とサービス種別情報を含むアドレス解決要求を受信（ス
テップ１０）すると、受信したユーザＩＤ及びサービス
種別情報を基にして図４で説明したアドレス解決サーバ
１０内のユーザ情報データベースを検索する( ステップ
１１）。該当するアドレスがユーザ情報データベース内
にない場合は、該当するアドレスが存在しない旨の情報
を返信する等の検索失敗処理等（ステップ１２）を実行
する。該当するアドレスがある場合には、そのアドレス
を含むメッセージをアドレス解決要求送信元に返信する
（ステップ１３）。

【００２３】本実施例のアドレス解決サーバは、例え
ば、一般のコンピュータシステムにおける構成と同様な
図６に示す構成により実現できる。同図に示すように、
本アドレス解決サーバは、ＣＰＵ１００、メモリ１０
１、外部記憶装置１０２、ディスプレイ１０３、キーボ
ード１０４、通信処理装置１０５を備え、メモリ１０１
又は外部記憶装置１０２に記録されたプログラム及びデ
ータがＣＰＵ５０において処理されて上記のフローチャ
ートに示した動作を行う。また、キーボード１０４及び
ディスプレイ１０３で入出力が行われ、通信処理装置１
０５によりネットワークに接続され外部と通信する。

【００２４】次に、アドレス解決要求メッセージの構成
について説明する。図７はユーザＩＤ処理モジュールか
らアドレス解決サーバに送信されるアドレス解決要求メ
ッセージの例を示す図である。同図に示すように、アド
レス解決要求メッセージはヘッダ、ユーザＩＤ、サービ
ス種別からなる。図７は、検索結果の回答メッセージの
例を示す図であり、アドレス解決要求メッセージに検索
により得られたアドレスを付加した構成をとる。

【００２５】アドレス解決要求及び回答はＤＮＳプロト
コルで実現することも可能であり、その場合には図９に
示すように、アドレス解決要求メッセージとして、ＱＮ
ＡＭＥ部にユーザＩＤを記述し、ＱＴＹＰＥ部にサービ
ス種別を記述する。回答メッセージとしては、図１０に
示すように、ＮＡＭＥ部にユーザＩＤを記述し、ＴＹＰ
Ｅ部にサービス種別を記述し、ＲＤＡＴＡ部に検索結果
のアドレスを記述する。

【００２６】その他ＬＤＡＰ（Lightweight Directory
Access Protocol ）プロトコルを使用することも可能で
ある。図１１は、アドレス解決要求メッセージに含まれ
るサービス種別を表す図である。同図に示すように、サ
ービス種別はサービス番号により識別され、サービス種
別毎に情報種別を規定している。例えば、サービス種別
がＨＴＴＰの場合の情報種別はＵＲＬである。ＤＮＳプ
ロトコルを使用する場合はサービス番号として未使用の
数値を使用する。

【００２７】図２に示した本発明の実施例において、ユ
ーザＩＤ処理モジュールの配置については種々の方法が
可能である。次にそれらの例について説明する。図１２
は、アプリケーションサーバにおけるアプリケーション
内にユーザＩＤ処理モジュールを内蔵する例を示す。こ
の場合、クライアント５０がアプリケーションサーバ５
２に対してユーザＩＤで発信し、アプリケーションサー
バ５２からアドレス解決サーバ５４にアドレス解決を要
求し、正規のアドレスを得ると、アプリケーションサー
バ５２は宛先のサーバやクライアントと通信を行う。

【００２８】図１３は、クライアントのアプリケーショ
ン内にユーザＩＤ処理モジュールを内蔵する例である。
この場合は、まずクライアント５６からアドレス解決サ
ーバ５８に対してアドレス解決要求を送り、正規のアド
レスを受信してから、そのアドレスで宛先のクライアン
トやサーバと通信する。以上は、ユーザＩＤ処理モジュ
ールをアプリケーション内に内蔵する例である。

【００２９】図１４は、クライアントとアプリケーショ
ンサーバの間に、ユーザＩＤ処理モジュールを有してア
ドレス解決サーバと連携してアドレス変換を行うプロキ
シを設置する例である。同図に示すように、クライアン
ト６０がユーザＩＤにてアドレス変換プロキシ６２に発
信を行い、アドレス変換プロキシ６２はアドレス解決サ
ーバ６４と連携して正規アドレスを得ると、アプリケー
ションサーバ６６に正規アドレスでクライアントから受
けたメッセージを転送し、アプリケーションサーバ６６
は宛先のサーバやクライアントと通信を行う。

【００３０】図１５は、アドレス解決サーバにユーザＩ
Ｄ処理モジュールを備えることによる例を示す。クライ
アント６８はアドレス解決サーバ７０にユーザＩＤで発
信し、アドレス解決サーバ７０でアドレス解決が行われ
て得られた正規のアドレスでアプリケーションサーバ７
２にメッセージの転送を行い、アプリケーションサーバ
７２は宛先のサーバやクライアントと通信を行う。

【００３１】図１６は、アプリケーションサーバ内にユ
ーザＩＤ処理モジュールを備える例を示す。クライアン
ト７４はユーザＩＤでアプリケーションサーバ７６に発
信を行い、アプリケーションサーバ７６内のユーザＩＤ
処理モジュールによりアドレス解決サーバ７８にアドレ
ス解決要求がなされ、ユーザＩＤ処理モジュールがアド
レス解決サーバ７８よりアドレス解決の結果を受信する
と、それをサーバアプリケーションに渡し、サーバアプ
リケーションが宛先のサーバやクライアントと通信を行
う。

【００３２】図１７は、クライアント側にユーザＩＤ処
理モジュールを備える例である。クライアント８０内の
クライアントアプリケーションがユーザＩＤ処理モジュ
ールにユーザＩＤを渡し、ユーザＩＤ処理モジュールは
アドレス解決サーバ８２にアドレス解決を要求して、正
規のアドレスを受信すると、ユーザＩＤ処理モジュール
が宛先のサーバやクライアントと通信する。

【００３３】図１４〜１７で示した例では、既存のアプ
リケーションの前段にユーザＩＤ処理モジュールを備え
てアドレス解決を行うため、既存のアプリケーションを
無改造で使用できる。次に、ユーザ端末、アプリケーシ
ョンサーバ、又はアドレス解決サーバ等に備えられるユ
ーザＩＤ処理モジュールの動作の詳細を、図１８、１９
に示すフローチャートを用いて説明する。ユーザＩＤ処
理モジュールの動作は、単独のサービスを提供するＦＴ
Ｐ、ＳＭＴＰ等のプロトコルと複数のサービスが提供可
能なＨＴＴＰ等のプロトコルで異なり、単独サービスに
おける処理フローを図１８で示し、複数サービスにおけ
る処理フローを図１９で示す。また、図１８、１９に示
すフローチャートは、上記の図１４〜１７に示した全て
の構成に同様に適用される。図１２及び１３で示したユ
ーザＩＤ処理機能をアプリケーション内に備える方法で
は、クライアントアプリケーションやサーバアプリケー
ション固有の処理が追加されるが、ユーザＩＤ処理とし
ては同様のフローで処理が行われる。

【００３４】単独サービスの場合である図１８におい
て、ユーザＩＤ処理モジュールがクライアントから発信
されたパケットを受信（ステップ２０）すると、そのパ
ケットが宛先アドレス指定パケットかどうかを判断（ス
テップ２１）し、宛先アドレス指定パケットでなければ
そのまま送信（ステップ２６）を続行し、宛先アドレス
指定パケットであれば、そのパケットから宛先アドレス
部を抽出（ステップ２２）する。次に、抽出した宛先ア
ドレスがユーザＩＤかどうかを判断し（ステップ２
３）、ユーザＩＤでなければそのまま送信（ステップ２
６）を行い、ユーザＩＤであれば、図７等で説明した要
求メッセージをアドレス解決サーバに送信することによ
りアドレス解決要求を実行（ステップ２４）し、正規ア
ドレスを含む回答メッセージを受信し、最初に受信した
パケットの宛先アドレス部をその正規アドレスで置き換
え（ステップ２５）、送信を行う（ステップ２６）。

【００３５】図１９に示す複数サービスの場合は次の通
りである。ユーザＩＤ処理モジュールがクライアントか
ら発信されたパケットを受信（ステップ３０）すると、
そのパケットが宛先アドレス指定パケットかどうかを判
断（ステップ３１）し、宛先アドレス指定パケットでな
ければそのまま送信（ステップ３７）を続行し、宛先ア
ドレス指定パケットであれば、そのパケットから宛先ア
ドレス部を抽出（ステップ３２）する。次に、抽出した
宛先アドレスがユーザＩＤかどうかを判断し（ステップ
３３）、ユーザＩＤでなければそのまま送信（ステップ
３７）を行い、ユーザＩＤであれば、複数サービスの中
からサービスを識別するために、受信したパケットから
サービス種別を抽出（ステップ３４）する。このサービ
ス種別の抽出にあたっての方法は、例えば、リクエスト
メッセージの中にサービス種別が記述してあるので、そ
のメッセージの解読を行なうことにより容易にサービス
種別を識別できる。次に、図７等で説明した要求メッセ
ージをアドレス解決サーバに送信することによりアドレ
ス解決要求を実行（ステップ３５）し、正規アドレスを
含む回答メッセージを受信し、最初に受信したパケット
の宛先アドレス部をその正規アドレスで置き換え（ステ
ップ３６）、送信を行う（ステップ３７）。

【００３６】続いて具体的なアプリケーションにおける
宛先情報の抽出及び処理についてシーケンスチャートを
用いて詳細に説明する。なお、以下で説明する処理は、
ユーザＩＤ処理モジュールの配置の形態の違いによら
ず、前述したどのような形態においても同様に適用可能
である。ＳＭＴＰの場合の例を図２０に示す。同図にお
いて、ユーザＩＤ処理モジュールはＳＭＴＰパケットを
監視し、ＲＣＰＴ（送信先メールアドレスリスト）コマ
ンド（ステップ４２）のみを取り出し（ステップ４
３）、その他のコマンドはそのまま転送する。すなわ
ち、ＳＭＴＰサーバへの送信開始を要求するＭＡＩＬＦ
ＲＯＭ（ステップ４０）、その応答である２５０ ＯＫ
（ステップ４１）等のパケットはそのまま転送する。Ｒ
ＣＰＴパケットに記述されているアドレスがユーザＩＤ
であればアドレス解決サーバと連携してアドレス解決を
行い（ステップ４４、ステップ４５））、ＲＣＰＴパケ
ットに記述されているアドレスを本来のアドレスに置き
換え（ステップ４６）、置き換えたＲＣＰＴコマンドを
転送する（ステップ４７）。そして、ＯＫの応答を受け
（ステップ４８）、本文の送信開始を示すＤＡＴＡコマ
ンドを送信し（ステップ４９）、正常応答コード３５４
を受信し（ステップ５０）、その後、本文の送信等が行
われる。

【００３７】次にＦＴＰの場合を図２１に示す。図２１
ではユーザＩＤ処理モジュールがＦＴＰプロキシサーバ
上にある例を示している。同図に示すように、クライア
ントがＦＴＰプロキシへの接続を要求し（ステップ６
０）、新たなユーザのためのサービス準備完了の応答を
受信すると（ステップ６１）、サーバへユーザＩＤ指定
により接続要求し（ステップ６２）、ＦＴＰプロキシす
なわちユーザＩＤ処理モジュールはアドレス変換により
本来のサーバアドレス＋ユーザディレクトリを解決し
（ステップ６３〜６６）、サーバアドレスにより接続を
行う（ステップ６７）。目的のサーバからの準備完了応
答を受け（ステップ６８）、ユーザ名を送信し（ステッ
プ６９）、ユーザＯＫ、要パスワードの応答を受けると
（ステップ７０）、パスワードを送信（ステップ７１）
する。接続処理中はメッセージを監視しており、ログイ
ン完了メッセージ２３０（ステップ７２）があった場
合、メッセージを一時ＦＴＰプロキシに蓄積する。そし
て、解決したユーザディレクトリヘの変更ＣＷＤ（チェ
ンジワーキングディレクトリ）（ステップ７３）をサー
バに要求する。ディレクトリの変更が完了したところ
（ステップ７４）で、ログイン完了メッセージをクライ
アントヘ送信する（ステップ７５）。

【００３８】更にＨＴＴＰの場合を図２２に示す。同図
に示すように、ユーザＩＤ処理モジュールにてＨＴＴＰ
パケットを監視し、リクエストメッセージのみを取り出
し（ステップ８０）、その他のメッセージはそのまま転
送する。リクエストメッセージに記述されているＵＲＬ
がユーザＩＤであればアドレス解決を行い（ステップ８
１、８２）、本来のアドレスヘ置き換え（ステップ８
３）、置き換えたリクエストメッセージを目的のサーバ
に転送する（ステップ８４）。続いてレスポンスを受信
し（ステップ８５）、以降の処理を行う。

【００３９】次にユーザＩＤ形式について説明する。ユ
ーザＩＤ形式はディレクトリ構造を備えることにより、
大規模ユーザに対応する。また、ＤＮＳ、ＡＮＳなどの
ドメインネームと同様の形式にすることにより外部のＤ
ＮＳ、ＡＮＳシステムと連携することも可能である。例
えば、ネットワーク部第一システム“鈴木”：suzuki
(a)1sys.net というユーザＩＤでＤＮＳに接続する場合
には、suzuki(a)1sys.net.ntt.co.jp とする。

【００４０】次に本発明におけるプログラムを記録した
記録媒体について説明する。本発明の記録媒体は、図６
に示すものと構成を同じくする一般的なコンピュータシ
ステムにおけるメモリ１０１又は外部記憶装置１０２の
いずれか又は両方に相当する。また、電子メモリ、ハー
ドディスク等のみならず、光磁気ディスク、磁気ディス
ク、磁気テープ等の可搬媒体も本発明の記録媒体に相当
し、これらの記録媒体に格納された本発明のアドレス変
換プログラムをコンピュータシステムにローディング
し、ネットワーク接続することにより、そのコンピュー
タシステムは本発明のアドレス解決サーバとして使用で
き、本発明のアドレス処理プログラムをコンピュータシ
ステムにローディングし、ネットワーク接続することに
より、そのコンピュータシステムは本発明のユーザＩＤ
処理モジュールを搭載したコンピュータとして使用でき
る。

【００４１】なお、本発明は上記の実施例に限定されて
おらず、特許請求の範囲内で種々変更・応用が可能であ
る。例えば、実施例はＴＣＰ／ＩＰネットワークを使用
しているが、本発明は他のネットワークにも同様に適用
可能である。

【００４２】

【発明の効果】上述した通り、本発明によれば、サービ
ス毎の複数アドレスを各ユーザにユニークに付与される
ユーザＩＤに統合し、ユーザはサービスを意識しなくて
も宛先に同一のアドレスを利用することが可能になる。
また、本発明によれば、アプリケーションサーバヘのユ
ーザＩＤ処理モジュール追加やユーザＩＤ処理モジュー
ル内蔵プロキシの追加によりユーザＩＤ変換が実現でき
るため、アプリケーションプロトコルには変更の必要が
なく、サーバ側クライアント側のいずれのアプリケーシ
ョンも既存のソフトウェアを無改造で利用することがで
きる。

【００４３】更に、本発明によれば、ネームの階層構造
やＤＮＳプロトコルのメッセージフォーマットに従うこ
とによりＤＮＳと接続して運用することも可能である。

【図面の簡単な説明】

【図１】サービス毎のアドレス体系及びＤＮＳによるア
ドレス解決の範囲を示す図である。

【図２】本発明の実施例の全体構成を示す図である。

【図３】本発明の実施例における基本的動作を示す図で
ある。

【図４】本発明の実施例におけるユーザ情報データベー
スの例を示す図である。

【図５】本発明の実施例におけるアドレス解決サーバの
動作を示すフローチャートである。

【図６】本発明の実施例におけるアドレス解決サーバの
ハードウェア構成を示す図である。

【図７】本発明の実施例におけるアドレス解決要求メッ
セージの例を示す図である。

【図８】本発明の実施例におけるアドレス解決要求への
回答メッセージの例を示す図である。

【図９】本発明の実施例においてＤＮＳプロトコルを使
用する場合のアドレス解決要求メッセージの例を示す図
である。

【図１０】本発明の実施例においてＤＮＳプロトコルを
使用する場合のアドレス解決要求への回答メッセージの
例を示す図である。

【図１１】本発明の実施例においてサービス種別を示す
識別番号の例を示す図である。

【図１２】本発明の実施例においてユーザＩＤ処理モジ
ュールをサーバアプリケーションに内蔵する例を示す図
である。

【図１３】本発明の実施例においてユーザＩＤ処理モジ
ュールをクライアントアプリケーションに内蔵する例を
示す図である。

【図１４】本発明の実施例においてユーザＩＤ処理モジ
ュールをクライアントとアプリケーションサーバの間に
設置する例を示す図である。

【図１５】本発明の実施例においてユーザＩＤ処理モジ
ュールをアドレス解決サーバ内に設置する例を示す図で
ある。

【図１６】本発明の実施例においてユーザＩＤ処理モジ
ュールをアプリケーションサーバ内に設置する例を示す
図である。

【図１７】本発明の実施例においてユーザＩＤ処理モジ
ュールをクライアント内に設置する例を示す図である。

【図１８】本発明の実施例において単独サービスの場合
のユーザＩＤ処理モジュールの動作を示すフローチャー
トである。

【図１９】本発明の実施例において複数サービスの場合
のユーザＩＤ処理モジュールの動作を示すフローチャー
トである。

【図２０】本発明の実施例においてＳＭＴＰの場合の処
理を示すシーケンスチャートである。

【図２１】本発明の実施例においてＦＴＰの場合の処理
を示すシーケンスチャートである。

【図２２】本発明の実施例においてＨＴＴＰの場合の処
理を示すシーケンスチャートである。

【符号の説明】

１、１２ メールサーバ ２ ファイルサーバ ３ 利用端末 １０、５４、５８、６４、７０、７８、８２ アドレス
解決サーバ １４ ｈｔｔｐプロキシー １６ ｆｔｐプロキシー １８ Ｈ．３２３ゲートキーパ ２０ ユーザＩＤ処理モジュール ２２、２４、３６ ユーザ端末 ２６ クライアントモジュール ２８ Ｈ．３２３ゲートウェイ ３０ 電話交換網 ３２ インターネット ３４ 上位ＤＮＳ ４０ ユーザ１ ４２ ユーザ２ ４４、４６ アプリケーション ５０、５６、６０、６８、７４、８０ クライアント ５２、６６、７２、７６ アプリケーションサーバ ６２ アドレス変換プロキシ １００ ＣＰＵ １０１ メモリ １０２ 外部記憶装置 １０３ ディスプレイ １０４ キーボード １０５ 通信処理装置

───────────────────────────────────────────────────── フロントページの続き (72)発明者 岡 克也 東京都新宿区西新宿三丁目19番２号 日本 電信電話株式会社内 (72)発明者 瀬口 有美 東京都新宿区西新宿三丁目19番２号 日本 電信電話株式会社内 (72)発明者 千徳 真也 東京都新宿区西新宿三丁目19番２号 日本 電信電話株式会社内 Ｆターム(参考） 5B089 GA12 GA23 GB08 HB04 HB05 HB07 JA40 JB22 KA03 KA04 KB06 KC37 KH03 LB02 LB08 LB24 5K033 AA09 CB01 CB09 DA01 DA06 DB12 EC03 5K034 AA17 DD03 FF01 FF13 HH04 HH61 LL01 NN04

Claims (13)

【特許請求の範囲】
1. 【請求項１】ネットワーク上で提供される複数のサービ
   スにおけるユーザのアドレスをサービスに依らないアド
   レスに統合するアドレス統合方法であって、 あるサービスの発信に係る第１のメッセージを受信した
   アプリケーションが、必要に応じて該メッセージ内の宛
   先アドレスと該サービスの種別を表すサービス種別情報
   とを含む第２のメッセージをアドレス変換を行う装置に
   送信することによりアドレス変換を要求する要求ステッ
   プと、 該アドレス変換を行う装置が該宛先アドレスと該サービ
   ス種別情報とから該宛先アドレスを該サービスに固有の
   アドレスである正規アドレスに変換する変換ステップ
   と、 該アドレス変換を行う装置が該正規アドレスを含む第３
   のメッセージを該アプリケーションに返信するステップ
   と、 該アプリケーションが該第１のメッセージにおける該宛
   先アドレスを該正規アドレスに置き換えて送信する送信
   ステップとを有することを特徴とするアドレス統合方
   法。
2. 【請求項２】前記アプリケーションは、前記要求ステッ
   プと前記送信ステップとを含む処理モジュールのみか
   ら、又は、該処理モジュールと前記サービスに係るアプ
   リケーションとからなる請求項１記載のアドレス統合方
   法。
3. 【請求項３】前記アプリケーションは、前記要求ステッ
   プと前記送信ステップとを含む処理モジュールを内蔵す
   るアプリケーションである請求項１記載のアドレス統合
   方法。
4. 【請求項４】前記要求ステップと前記送信ステップとを
   含む処理モジュールが、汎用コンピュータ上又は前記ア
   ドレス変換を行う装置上に配置される請求項１記載のア
   ドレス統合方法。
5. 【請求項５】前記変換ステップは、 前記アドレス変換を行う装置が、ユーザ固有のアドレス
   に対応する各サービスに固有の前記正規アドレスが記述
   されたテーブルを参照することによりアドレスを変換す
   るステップを有する請求項１記載のアドレス統合方法。
6. 【請求項６】あるアドレスを、ネットワーク上で提供さ
   れるサービスに固有のアドレスに変換するアドレス変換
   装置であって、 一のアドレスと、サービスの種別を示すサービス種別情
   報とを含む第１のメッセージを受信する手段と、 該一のアドレスと該サービス種別情報とから該一のアド
   レスを該サービスに固有のアドレスである正規アドレス
   に変換する変換手段と、 該正規アドレスを含むメッセージを該第１のメッセージ
   の送信元に返信する手段と、 を有することを特徴とするアドレス変換装置。
7. 【請求項７】前記変換手段は、 ユーザ固有のアドレスに対応する各サービスに固有の前
   記正規アドレスが記述されたテーブルを参照することに
   より前記一のアドレスを変換する手段を有することを特
   徴とする請求項６記載のアドレス変換装置。
8. 【請求項８】あるアドレスを、ネットワーク上で提供さ
   れるサービスに固有のアドレスに変換するアドレス変換
   プログラムを記録したコンピュータ読み取り可能な記録
   媒体であって、該プログラムは、 一のアドレスと、サービスの種別を示すサービス種別情
   報とを含む第１のメッセージを受信し、 該一のアドレスと該サービス種別情報とから該一のアド
   レスを該サービスに固有のアドレスである正規アドレス
   に変換する変換処理を行い、 該正規アドレスを含むメッセージを該第１のメッセージ
   の送信元に返信することをコンピュータに実行させるア
   ドレス変換プログラムを記録したコンピュータ読み取り
   可能な記録媒体。
9. 【請求項９】前記変換処理は、 ユーザ固有のアドレスに対応する各サービスに固有の前
   記正規アドレスが記述されたテーブルを参照することに
   より前記一のアドレスを変換する処理を含む請求項８記
   載のアドレス変換プログラムを記録したコンピュータ読
   み取り可能な記録媒体。
10. 【請求項１０】あるアドレスをネットワーク上で提供さ
    れるサービスに固有のアドレスに変換するアドレス変換
    手段と連携して、ユーザ固有のアドレスをサービスに固
    有のアドレスに置き換えるアドレス処理プログラムを記
    録したコンピュータ読み取り可能な記録媒体であって、
    該プログラムは、 あるサービスの発信に係る第１のメッセージを受信し、 必要に応じて該メッセージ内の宛先アドレスを抽出し、 該宛先アドレスが前記ユーザ固有のアドレスである場合
    に該宛先アドレスと該サービスの種別を表すサービス種
    別情報とを含む第２のメッセージを前記アドレス変換手
    段に送信し、 該アドレス変換手段から該サービスに固有のアドレスで
    ある正規アドレスを含む第３のメッセージを受信し、 該第１のメッセージの宛先アドレスを該正規アドレスに
    置き換えて送信を行うアドレス処理をコンピュータに実
    行させるアドレス処理プログラムを記録した記録媒体。
11. 【請求項１１】ＳＭＴＰパケットを監視し、ＲＣＰＴパ
    ケットのみを前記第１のメッセージとして受信して前記
    アドレス処理を行う請求項１０記載のアドレス処理プロ
    グラムを記録した記録媒体。
12. 【請求項１２】前記アドレス処理は前記ユーザ固有のア
    ドレスをＦＴＰサーバにおけるユーザディレクトリに変
    換する処理を含み、 ＦＴＰサーバへの接続のためのパケットを前記第１のメ
    ッセージとして受信して前記アドレス処理を行い、 該ＦＴＰサーバへのログイン完了メッセージを一時蓄積
    し、該アドレス処理により得られた該ユーザディレクト
    リへの変更を該ＦＴＰサーバに要求し、該ユーザディレ
    クトリへの変更が完了すると該ログイン完了メッセージ
    を送信する請求項１０記載のアドレス処理プログラムを
    記録した記録媒体。
13. 【請求項１３】ＨＴＴＰパケットを監視し、リクエスト
    メッセージのみを前記第１のメッセージとして受信して
    前記アドレス処理を行う請求項１０記載のアドレス処理
    プログラムを記録した記録媒体。