JP4010041B2 - 表示形式調整システム、表示形式調整方法、及び記録媒体 - Google Patents
表示形式調整システム、表示形式調整方法、及び記録媒体 Download PDFInfo
- Publication number
- JP4010041B2 JP4010041B2 JP36153897A JP36153897A JP4010041B2 JP 4010041 B2 JP4010041 B2 JP 4010041B2 JP 36153897 A JP36153897 A JP 36153897A JP 36153897 A JP36153897 A JP 36153897A JP 4010041 B2 JP4010041 B2 JP 4010041B2
- Authority
- JP
- Japan
- Prior art keywords
- address
- user
- image data
- display format
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク・プロバイダ（以下、単に「プロバイダ」と呼ぶ）によるユーザのネットワーク接続管理システムに関し、より詳しくは、プロバイダが、ユーザの過去のアクセス情報に基づいて、そのユーザが過去にアクセスしたアドレスを再びアクセスするために選択可能な表示形式情報としてユーザに提供するシステムに関する。
【０００２】
【従来の技術】
近年、インターネット上で提供されるＷＷＷページを参照し、または作成することが流行しており、これらに関するツールや書籍等が多く流通している。ＷＷＷとは、ワールドワイドウエブ（World Wide Web）の略であり、インターネットを使用した全世界規模の情報網をいう。ＷＷＷページとは、Ｗｅｂドキュメントを構成する情報の単位であり、前記ＷＷＷ上に設置された任意のＷＷＷサーバ内に記憶された、ＨＴＭＬ（Hypertext Markup Language ）と呼ばれる言語で記述されたＨＴＭＬ文書、ＶＲＭＬ（Virtual Reality Modeling Language ）と呼ばれる言語で記述されたＶＲＭＬ文書、および関連するイメージデータ等から成る。
【０００３】
ＷＷＷブラウザは、このページを表示するためのデータをＷｅｂサイトから受信し、そのデータを解釈してＷＷＷブラウザが起動されているコンピュータの表示装置の画面上に表示させる。前記ページがＨＴＭＬ文書で構成されている場合、ＷＷＷでは、テキスト、図、動画、音などの２次元の情報を扱うことができる。また、ＶＲＭＬ文書を用いれば、３次元の情報を統一的に扱うことができ、３次元表示された物体をいろいろな角度から見たり、３次元の街を歩き回ったりすることが可能となり、いわゆるサイバースペース（３次元電脳空間）を表現することができる。
【０００４】
ＷＷＷブラウザのこうした機能によって、そのユーザは、家庭にいながらにして、全世界のページを参照または聴取することができる一方で、自分が作成したページを全世界に向けて発信することができる。
【０００５】
前記「ページ」を表示させるためのＨＴＭＬ文書、ＶＲＭＬ文書、及びイメージデータ等のデータは通常、前記ＷＷＷ上に設置されているＷＷＷサーバ内に、各ユーザ毎に記憶されており、前記ユーザには個人をはじめ、政府、企業、およびその他団体等が含まれる。前記各ユーザは、ＨＴＭＬ文書、またはＶＲＭＬ文書における指定によって、ページを階層的に構成することができ、各ユーザにおける最上位の階層のページを、特に「ホームページ」という。各ユーザは、ページに、いくつかの他のページへのリンクを設けることができ、そのリンク先のページは更に、いくつかの他のページへのリンクを有することができる。このリンクは通常「アンカー」と呼ばれ、前記ＷＷＷブラウザによって表示されたページ上に、そのリンク先のページを示すシンボル（例えば、そのページのアドレスやそのページの内容を間接的に表すイメージ等）として表示される。
【０００６】
ＨＴＭＬ文書とＶＲＭＬ文書の間では、互いに他の文書に対するアンカーを設定することができ、例えば、ＨＴＭＬ文書からＶＲＭＬ文書を呼び出し、またＶＲＭＬ文書からＨＴＭＬ文書を呼び出すこともできる。
【０００７】
ＷＷＷブラウザのユーザは、所望のリンク先を示すシンボルをマウスでクリックすると、ＷＷＷブラウザは、そのリンク先のページに表示を切り替える（リンク先へジャンプする）。また、こうしたリンク先としては、下位の階層のページだけでなく、上位の階層のページや他のＷｅｂサイトのページも指定することができる。
【０００８】
ＨＴＭＬ文書やＶＲＭＬ文書におけるページの指定には、ＵＲＬ（Uniform Resource Locator）と呼ばれる、インターネット上でそれぞれのページを識別するためのアドレスが使用され、例えば「http://www.xxx.co.jp/index.html 」、「http://www.xxx.co.jp/index.wrl」といった表記で表される。
【０００９】
ＷＷＷブラウザのユーザは、そのブラウザによって表示されているページ上の、他のページを示すシンボルをクリックすることによって、所望のページへ表示を切り替え、切り替えられたページ上の他のページを示すシンボルをクリックすることによって、更に他のページへ表示を切り替え、以降次々とページの表示を切り替えていくことができる。
【００１０】
この時、ＷＷＷブラウザは、クリックされた前記シンボルに対応するＵＲＬが示すアドレスのＷＷＷサーバに通常、プロバイダ及びインターネット経由でアクセスし、前記ＷＷＷサーバに格納されているＷｅｂサイトから対象データを、前記ＷＷＷブラウザが実行されているコンピュータのメモリまたは記憶装置にインターネット経由でダウンロードする。
【００１１】
次に、ＷＷＷブラウザは、これらのデータのダウンロードが終了するのを待って、またはダウンロードと共に前記データを前記コンピュータの表示装置上にページとして表示する。
【００１２】
現在、ネットスケープ社のネットスケープ・ナビゲータ、マイクロソフト社のインターネット・エクスプローラ等のＷＷＷブラウザが提供され、広く使用されている。
【００１３】
しかし、ＶＲＭＬ文書を表示させるためにはＶＲＭＬビューワを用意する必要があり、これは前記ネットスケープ社のネットスケープ・ナビゲータなどのＷＷＷブラウザとは別の専用のブラウザかまたは、ＷＷＷブラウザのＶＲＭＬ用プラグイン・モジュールあるいはヘルパーアプリケーション等によって提供される。
【００１４】
ＶＲＭＬは、前述したようにＷＷＷ上で３次元空間および物体(オブジェクト)を記述するための言語である。ユーザは、アバタという人型オブジェクトを利用することで、ＶＲＭＬにより作られた仮想空間の中を歩きまわったり(ウォークスルー)、他のオブジェクトとの会話などのコミニュケーションを可能にする。また更に、その仮想空間の中のシーン（風景）に対して、カメラを定義することによって、そのカメラを通して見る視点を設定することができる。
【００１５】
そのため、現在では、ＶＲＭＬを使って、エンターテイメント（バーチャル遊園地）、バーチャルモール（仮想商店街）、都市の３次元表示、人工生命、及びロボティックスなどへの応用がされつつある。
【００１６】
ＶＲＭＬは、１９９４年に誕生し、１９９５年にＶＲＭＬ１．０の仕様が正式に決まり、現在の仕様は、ＶＲＭＬ２．０である。この２つの仕様には大きな違いがある。ＶＲＭＬ１．０では時間の止まった３次元のシーンを作ることしかできず、音を出力することもできない。しかし、ＶＲＭＬ２．０では、置かれているオブジェクトが急に動き出しだり、クリックすると色が変わったりするシーンを作ることができ、音楽も出力可能な動的な世界を構築可能である。
【００１７】
また、実際のＶＲＭＬビューワでは、前記アバタやカメラなどの移動は通常、それらの位置をマウスのクリックなどによって直接指示するかまたは、それらの前進、後退、回転等の移動の指示を行うボタンをマウスのクリックなどによって操作するようになっている。
【００１８】
前述したような、ページを次々と切り替えていく方法でページを参照する、いわゆる「ネットサーフィン」のような参照方法の他に、表示したいページのＵＲＬが予め分かっている場合に、ＷＷＷブラウザやＶＲＭＬビューワのＧＵＩ（Graphical User Interface）画面上の場所指定エリアに直接ＵＲＬをタイプする方法がある。しかし、株価情報やニュースを表示するページなどを、毎日参照する必要のあるユーザもいる。このように、ある決まったページを毎回参照する必要がある場合には、毎回数十文字におよぶ前述したＵＲＬをタイプするのは不便であり、非効率でもある。そこで、こうしたページを容易に表示させるために、前記ＷＷＷブラウザ等は「ブックマーク機能」と呼ばれる機能を一般的に備えている。
【００１９】
「ブックマーク機能」とは、ＷＷＷブラウザやＶＲＭＬビューワなどで、気に入ったサイトや頻繁にアクセスするページを事前に登録しておく機能であり、表示させたいページのＵＲＬを予めブックマークデータの一情報として登録しておき、「ブックマークの表示」で、ブックマークとして登録されているページを一覧表示してから該当するページをマウスのクリック操作などで選択することによって、わずらわしいＵＲＬのタイプをすることなく、またタイプミスによる時間の浪費を生じさせることなく所望のページを表示させることができるというものである。
【００２０】
図１４にはＷＷＷブラウザの代表的なブックマーク表示画面１０００が示されている。同図に示すように、ブックマークは階層的に管理することができ、ブックマーク１１１１の集合を１つのフォルダ１１１０に収めて管理することができる。これによってユーザは、各ブックマーク１１１１をカテゴリ別に分類して調整することができ、多くのブックマーク１１１１がある場合にも効率的に所望のブックマーク１１１１を探すことができる。例えば、図１４のブックマーク表示画面１０００を参照すると、最上位フォルダとして「BOOKMARK」フォルダ１１００があり、その下の「WWW SEARCH ENGINE」というフォルダ１１１０の中に、「goo」と「Yahoo! JAPAN」というブックマーク１１１１がブックマークとして登録されており、これらのブックマーク１１１１は、前記フォルダ１１１０「WWW SEARCH ENGINE」をマウスなどでクリックすることによって同図のように一覧的に表示される。また、図１４には、フォルダ１１１０に含まれない「IBM Patent Server Home Page 」などのブックマーク１１１１も示されている。
【００２１】
前述の「goo 」や「Yahoo! JAPAN」といった、ブックマーク１１１１を識別するためのタイトルは、通常そのブックマーク１１１１に対応するページを作成した者が設定した、そのページのタイトルがそのまま用いられる。しかし、ＷＷＷブラウザやＶＲＭＬビューワのユーザは、図１４のブックマーク表示画面１０００で「goo 」などのブックマーク１１１１を示す行をマウスでダブルクリックしたり、こうしたブックマーク表示画面１０００以外の、別のブックマーク１１１１を簡易表示するポップアップウインドウ（不図示）で所望のブックマーク１１１１を示す行をクリックすることなどによって、容易に所望のページを選択し、表示させることができる。
【００２２】
ブックマーク１１１１の追加は、通常、最初にＵＲＬをＷＷＷブラウザやＶＲＭＬビューワの場所指定エリアにタイプして所望のページを表示させたとき、または前述したネットサーフィン等で所望のページを見つけたときなどに、そのページを表示させた状態で、マウスのクリックなどの操作で「ブックマークの追加」を指示することによって行われる。この時、そのページのＵＲＬやタイトルを含む情報が自動的にブックマーク１１１１として登録され、ページのタイトルはそのページに対応する登録されたブックマーク１１１１のタイトルとしてそのまま使用される。
【００２３】
また、図１４のブックマーク表示画面１０００で、ブックマーク１１１１を新規に追加する操作において、ＵＲＬやタイトル等をタイプすることによって所望のフォルダ１１１０の中に新たなブックマーク１１１１を追加することもできる。
【００２４】
ブックマーク１１１１内の情報は、例えば、図１４のブックマーク表示画面１０００で、対象のブックマーク１１１１のプロパティをマウスにより選択すること等によって表示されるブックマーク編集画面（不図示）上で編集することができる。更に、図１４のブックマーク表示画面１０００上において、マウス等の操作により、ブックマーク１１１１自体の削除、移動（他のフォルダへの移動を含む）が可能である。
【００２５】
また、近年では、個人または企業、その他の団体によって、インターネットのようなネットワークを経由するメールの送受信が盛んに行われている。これらのメールは、ネットワーク上に設置されたメールサーバ間で送受信され、個人などのユーザは、そのメールサーバを介して、他人にメールを送信し、また自分宛のメールを受信する。メールのアドレスは、メールアドレスによって識別され、インターネット・メールであれば、通常「user@xxx.or.jp」等のフォーマットで提供される。メールには、インターネット・メールの他、パソコン通信やその他の団体、企業内で送受信されるメールがあるが、これらは、ゲートウエイなどを介して相互に送受信される。
【００２６】
現在、こうしたメールの送受信を行うツール（いわゆる、メーラ）は、前述のＷＷＷブラウザとセットになっているものから、メール専用のツールまで様々である。しかし、これらのツールは、メールの送受信に関する基本機能について異なるところはない。ユーザは、ネットワークに接続して、前記メーラを起動し、自分宛のメールを受信する。これらのメールを受信する際には、それらのメールが誰から送信されたものか、またサブジェクトに何を含んでいるか等によって、異なるフォルダに分類して記憶することもできる。送信の際には、「アドレスブック」と呼ばれるところに予め記憶されている送信先のメールアドレスを、メールの送信先としてマウスのクリックなどで簡単に指定することができ、そのメールアドレスを送信の度にタイプする必要がない。もちろん、初めてメールを送信する相手には、メールアドレスのタイプ等が必要になるが、その際に登録処理を行っておけば、その相手に次に送信する際には、メールアドレスは上記のように簡単に指定でき、タイプは不要である。
【００２７】
また、前記アドレスブックに記憶された複数のメールアドレスは、前記ＷＷＷブラウザ等のブックマークと同様に、前記アドレスブック内で複数のフォルダに格納されうる。従って、ブックマークのような階層的な管理も可能である。例えば、友人、会社関係のメールアドレスを分けて管理することができ、また、社内のメール管理においては、各部署ごと、または支店ごとといった分類も可能である。
【００２８】
一般のユーザが、前記ＷＷＷページを見たり、メールの送受信を行うためにインターネットなどのネットワーク上の資源にアクセスするには、インターネットへの常時接続ポイントを有するプロバイダと呼ばれる接続業者のサーバに公衆回線等を介して、ユーザのコンピュータを接続する必要がある。このことによって、前記ユーザは、プロバイダの前記サーバを介してインターネットなどのネットワーク上の資源にアクセスでき、ＨＴＭＬ文書やメールを自分のコンピュータに転送することができる。
【００２９】
【発明が解決しようとする課題】
上述したように、従来のＷＷＷブラウザやＶＲＭＬビューワが有するブックマーク機能では、ページに関する長い文字数のＵＲＬを毎回入力することなく、予め登録してある複数のブックマークのうち所望のページのブックマークをマウス等で選択することによって、そのページをＷＷＷブラウザやＶＲＭＬビューワに表示させることができる。同様に、従来のメーラが有するアドレスブックにおいても、送信先のメールアドレスを毎回入力することなく、簡単な操作によってメールアドレスを選択することができる。
【００３０】
しかし、従来のＷＷＷブラウザやＶＲＭＬビューワ、及びメーラは、このように事前に登録されたアドレスについて、プロバイダ側で自動的にアクセスを行い、そのアクセス結果（例えば、ページの更新、ビジー、またはＮｏｔ Ｆｏｕｎｄなど）に基づいて、そのアドレスに対応するイメージ・データの表示位置や表示方法を変化させ、または関連する情報を付加する機能を提供するものではない。
【００３１】
本発明は、前記課題を解決するために、ＷＷＷブラウザやＶＲＭＬビューワによりアクセスされるページのアドレス、及びメーラによって送受信されるメールアドレスについて、プロバイダ側でユーザのアクセスとは別に、自動的にアクセスを行い、そのアクセス結果に基づいて、そのアドレスに対応するイメージ・データの表示位置や表示方法を変化させ、または関連する情報を付加する機能を提供することを目的とする。
【００３２】
【課題を解決するための手段】
上記本発明の課題を解決するため、請求項１に記載の発明は、ネットワーク上に存在する、それぞれが自己の格納位置を示すアドレスを有するソフトウエア資源に対するユーザからのアクセスを制御し、前記アクセスされたソフトウエア資源と前記ユーザとの間のデータの送受信を処理するネットワーク接続管理システムにおいて、前記ユーザが所定の期間においてアクセスした前記ソフトウエア資源のアドレスを記憶する履歴管理手段と、所定のタイミングで前記履歴管理手段に記憶された前記ソフトウエア資源のアドレスにアクセスし、その結果得られる少なくとも前記ソフトウエア資源に対する他のアクセスによる混雑によりアクセス不可となっている状態、及び、前記ソフトウエア資源のアドレスが存在しない状態を含むステータスを取得する取得手段と、前記取得手段によって取得されたステータスに基づいて、前記ユーザによって操作可能な当該ユーザ自身を特定するイメージデータを基準として該アドレスに対応するイメージデータを該アドレスの属性に応じて区分けして表示するよう表示形式データを調整する表示形式データ調整手段と、前記表示形式データ調整手段により調整された表示形式データで前記ユーザ自身を特定するイメージデータと前記アドレスに対応するイメージデータとを前記ユーザが操作する端末に表示させるよう制御する表示制御手段とを有することを特徴とする。
【００３５】
請求項２に記載の発明は、上記請求項１に記載の発明において、前記ステータスには、少なくとも前記ソフトウエア資源のアドレスによって提供されるサービス内容に関する情報が含まれることを特徴とする。
【００３６】
請求項３に記載の発明は、上記請求項１または２に記載の発明において、前記取得手段が前記ソフトウエア資源のアドレスにアクセスする前記所定のタイミングは、少なくとも前記ユーザ毎に設定できることを特徴とする。
【００３７】
請求項４に記載の発明は、上記請求項１ないし３の何れかに記載の発明において、前記表示形式データ調整手段は更に、前記イメージデータの色、大きさ、模様、及びその他の外見的特徴の変更、イメージデータ自体の変更、及び該イメージデータの上、または付近に他のイメージデータを追加する処理を行うことを特徴とする。
【００３８】
上記本発明の課題を解決するため、請求項５に記載の発明は、ネットワーク上に存在する、それぞれが自己の格納位置を示すアドレスを有するソフトウエア資源に対するユーザからのアクセスを制御し、前記アクセスされたソフトウエア資源と前記ユーザとの間のデータの送受信を処理するネットワーク接続管理方法であって、前記ユーザが所定の期間においてアクセスした前記ソフトウエア資源のアドレスを記憶する履歴管理ステップと、所定のタイミングで前記履歴管理ステップによって記憶された前記ソフトウエア資源のアドレスにアクセスし、その結果得られる少なくとも前記ソフトウエア資源に対する他のアクセスによる混雑によりアクセス不可となっている状態、及び、前記ソフトウエア資源のアドレスが存在しない状態を含むステータスを取得する取得ステップと、前記取得ステップによって取得されたステータスに基づいて、前記ユーザによって操作可能な当該ユーザ自身を特定するイメージデータを基準として該アドレスに対応するイメージデータを該アドレスの属性に応じて区分けして表示するよう表示形式データを調整する表示形式データ調整ステップと、前記表示形式データ調整ステップによって調整された表示形式データで前記ユーザ自身を特定するイメージデータと前記アドレスに対応するイメージデータとを前記ユーザが操作する端末に表示させるよう制御する表示制御ステップとを含むことを特徴とする。
【００３９】
上記本発明の課題を解決するため、請求項６に記載の発明は、ネットワーク上に存在する、それぞれが自己の格納位置を示すアドレスを有するソフトウエア資源に対するユーザからのアクセスを制御し、前記アクセスされたソフトウエア資源と前記ユーザとの間のデータの送受信を処理するコンピュータを、前記ユーザが所定の期間においてアクセスした前記ソフトウエア資源のアドレスを記憶する履歴管理手段、所定のタイミングで前記履歴管理手段によって記憶された前記ソフトウエア資源のアドレスにアクセスし、その結果得られる少なくとも前記ソフトウエア資源に対する他のアクセスによる混雑によりアクセス不可となっている状態、及び、前記ソフトウエア資源のアドレスが存在しない状態を含むステータスを取得する取得手段、前記取得手段によって取得されたステータスに基づいて、前記ユーザによって操作可能な当該ユーザ自身を特定するイメージデータを基準として該アドレスに対応するイメージデータを該アドレスの属性に応じて区分けして表示するよう表示形式データを調整する表示形式データ調整手段、前記表示形式データ調整手段によって調整された表示形式データで前記ユーザ自身を特定するイメージデータと前記アドレスに対応するイメージデータとを前記ユーザが操作する端末に表示させるよう制御する表示制御手段として機能させるためのプログラムを記録したことを特徴とする。
【００４０】
【発明の実施の形態】
以下に、本発明の実施の形態の例について、図面を参照して説明する。尚、各図において、同一または類似のものには同一の参照番号または、記号を付与して説明する。
【００４１】
図１は、本発明の一実施形態のネットワーク接続管理システム１００のシステム構成を示すブロック図である。ネットワーク接続管理システム１００は、プロバイダ・接続管理サーバ１１０、及び顧客データベース１２０を含む。前記プロバイダ・接続管理サーバ１１０は、加入者接続制御機能１１１、マップデータ処理機能１１２、及びリクエスト処理機能１１３を含む。
【００４２】
また、プロバイダ・接続管理サーバ１１０は、必要に応じてプロバイダ・メールサーバ１３０及びプロバイダ・ＷＷＷサーバ１４０に接続される。
加入者１５０の使用するコンピュータ１５０は、そのプロバイダに加入している複数の加入者１５１、１５２等からなり、ネットワーク上の資源にアクセスする際、加入者のコンピュータをプロバイダ・接続管理サーバ１１０に公衆回線等を経由して接続する。
【００４３】
ネットワーク１６０は、例えば、インターネットといった、不特定多数の者がアクセス可能なネットワークであるが、これに限られず、社内ＬＡＮ、ＷＡＮ、ＶＡＮ、イントラネット、及びエクストラネット、その他利用者の限られた特定のネットワーク、及びその他有線・無線に限定されない形態のネットワークを含む。
【００４４】
メールサーバ１７０及びＷＷＷサーバ１８０は、ここで説明の対象としているプロバイダ以外のメールサーバ及びＷＷＷサーバを集合的に示している。
前記加入者接続制御機能１１１は、加入者１５０から、公衆回線等を介して接続要求があった場合、加入者１５０のＩＤとパスワードをチェックし、正常であれば加入者１５０のコンピュータとのコネクションを確立し、インターネット等へのアクセスが可能となるよう制御する。
【００４５】
前記マップデータ処理機能１１２は、履歴管理機能１１２Ａ（履歴管理手段）、マップデータ更新機能１１２Ｂ、マップデータ送信機能１１２Ｃ（表示形式データ送信手段）、及びマップデータ調整・保守機能１１２Ｄ（表示形式データ調整手段）を含み、加入者１５０が過去にアクセスしたアドレスを、ブックマークやアドレスブックに代えて、再度容易に選択可能な３次元的な表現として表示するためにマップ（地図表示形式）データを更新する。このマップデータは、加入者１５０に３次元的な表示を提供するための「もと」となるデータであり、実際はＨＴＭＬ文書やＶＲＭＬ文書である。このように、加入者１５０にマップデータをもとに表示されたものを以降では、「マップ表示」と呼ぶ。
【００４６】
前記履歴管理機能１１２Ａは、加入者１５０が過去にアクセスしたＷＷＷページのアドレス及び送受信したメールアドレスを加入者１５０毎に記憶し、加入者１５０がＷＷＷページのアクセスまたはメールの送受信を行う際に、それらのアドレスがその加入者１５０によって過去に使用されたものかをチェックする。
【００４７】
前記マップデータ更新機能１１２Ｂは、加入者１５０のＷＷＷページへのアクセス状況及びメールの送受信状況に応じて、加入者１５０のコンピュータ上に、加入者１５０が過去にアクセスしたＷＷＷページのアドレス及び送受信したメールアドレスを３次元的に表示するためのマップデータを更新する。
【００４８】
前記マップデータ送信機能１１２Ｃは、加入者１５０のＷＷＷページへのアクセス及びメールの送受信の際、または、加入者１５０がプロバイダに接続した際に、加入者１５０のコンピュータに前記マップデータを送信する。
【００４９】
前記マップデータ調整・保守機能１１２Ｄは、加入者１５０のＷＷＷページへのアクセス及びメールの送受信とは関係なく、加入者１５０毎に（又は一律）設定された間隔で、加入者１５０が過去にアクセスしたＷＷＷページのアドレスを自動的にアクセスし、そのアクセス結果に基づいてマップデータを変更し、調整し、更新する。
【００５０】
リクエスト処理機能１１３は、プロバイダに接続された加入者１５０の要求に応じて、例えば、ＷＷＷページのＨＴＭＬ文書データ、ＶＲＭＬ文書データ、及び関連するその他のデータを、ネットワーク１６０を介して、所定のアドレスのＷＷＷサーバ１８０からダウンロードし、加入者１５０のコンピュータに送信するよう制御し、要求されたメールの送受信を行う。
【００５１】
前記加入者接続制御機能１１１及びリクエスト処理機能１１３は、従来のソフトウエアを用いて従来のプロバイダによって提供されてきた機能である。
前記顧客データベース１２０は、加入者情報テーブル１２１、接続履歴テーブル１２２、イエローページ・テーブル１２３、マップイメージ・テーブル１２４、及びマップ・テーブル１２５を含む。各テーブルの詳細な説明は後述する。
【００５２】
前記プロバイダ・メールサーバ１３０は、そのプロバイダの加入者１５０宛に、例えば、ネットワーク１６０を介して他のプロバイダから送信されてきたメールを記憶し、加入者１５０からの指示によって、その受信メールを加入者側のコンピュータに転送する。
【００５３】
プロバイダ・ＷＷＷサーバ１４０は、プロバイダ及びプロバイダの加入者１５０のＨＴＭＬ文書やＶＲＭＬ文書、及びその他必要なデータ、モジュール等を記憶している。プロバイダの加入者１５０は、一般的には公衆回線を介してそれらのデータにアクセスする。そのプロバイダ以外のプロバイダの加入者は、公衆回線及びネットワーク１６０を介してそれらのデータにアクセスする。通常プロバイダは、ＷＷＷページのアクセスに関するキャッシュ機能及びセキュリティ機能を提供するＰＲＯＸＹサーバを備えているが、この実施例では省略してある。
【００５４】
メールサーバ１７０及びＷＷＷサーバ１８０は、ここで説明の対象としているプロバイダ以外のプロバイダ等のメールサーバ及びＷＷＷサーバを集合的に示している。
【００５５】
図２〜８は、本発明の一実施例で使用する顧客データベース１２０内の各テーブル及びデータの内容を示している。
図２は、加入者情報テーブル１２１のファイル・フォーマットの例を示しており、加入者ＩＤ、加入者名、パスワード、マップデータ表示種別、実現タイプ、巡回間隔、及び前回巡回日時の各項目が示されている。加入者ＩＤ、加入者名、及びパスワードは、プロバイダによって従来から管理されてきた項目であり、加入者１５０がプロバイダへの接続を試みる際に、加入者１５０の接続権限をチェックするために前記加入者接続制御機能１１１によって使用される。マップデータ表示種別は、どのような区分に従って、加入者１５０のマップデータを作成するかを指定する。この例では、「アドレスのタイプ別の区分け」、「アクセス頻度別の区分け」、「アクセス頻度別の表示方法変更」などがある。実現タイプは、加入者１５０のコンピュータに表示されるマップデータのデータタイプであり、このタイプに応じて、適当なアプリケーションが選択され、そのアプリケーションによってマップデータが解釈され、加入者１５０のコンピュータ上にブックマーク及びアドレスブック機能を果たすマップ表示が表示される。この例では、ＨＴＭＬ、ＶＲＭＬといった言語タイプを採用しているが、ＷＷＷページ等へのアンカー機能を有する限り、その他のどのような言語または方法を選択することもできる。巡回間隔は、例えばプロバイダ側で、加入者１５０が過去にアクセスしたアドレスを、自動的に順にアクセス（巡回）する間隔を示している。図２に示す例では、日単位で記憶されているが、時間や秒と言ったその他の単位で記憶されても良い。また、この例では、加入者１５０毎に巡回間隔を管理できる設計になっているが、一律に間隔を設定することもでき、その場合にはこの項目は不要である。前回巡回日時は、その加入者１５０に関する巡回が何時行われたかを示している。プロバイダ側では、前回巡回日時から巡回間隔が経過した時点で前記巡回を行い、今度はその時点を前回巡回日時に設定する。
【００５６】
図３は、接続履歴テーブル１２２のファイル・フォーマットの例を示しており、加入者ＩＤ、接続アドレス、最新アクセス日時、頻度、及びステータスの各項目を含む。アクセスされたアドレスは、加入者ＩＤに割り当てられた加入者によってアクセスされたＷＷＷページのアドレス、または送受信されたメールのアドレスであり、ＷＷＷページのアドレスとメールアドレスが混在して記憶される。最新アクセス日時は、前記アドレスにアクセスした最新の日時を示す。頻度は、一定期間内でそのアドレスにアクセスした回数を示す。このテーブルの例では、同一の加入者が同じアドレスにアクセスした場合は、そのアドレスに対応するレコードの最新アクセス日時及び頻度が更新され、新しいレコードの追加は行われないようになっているが、アクセス等があった場合に新しいレコードを追加して、頻度情報が必要な際に、同じアドレスのレコードの件数をカウントするようにしてもよい。ステータスは、前述の巡回がプロバイダ等によって自動的に行われた場合に、各アドレスに対するアクセス結果のステータス（状況）を示すものである。例えば、前回のアクセス時から更新されている場合は更新日を、回線などの混雑でページにアクセスできなかったときは「ビジー」を、ページが見つからない場合には「Ｎｏｔ Ｆｏｕｎｄ」と、ページのアドレスが変わっている場合には「移動」というように、それぞれ状況に応じて、対応する識別を設定する。
【００５７】
図４は、イエローページ・テーブル１２３のファイル・フォーマットの例を示しており、アドレス、タイプ、及びサブタイプを含む。このテーブルには、インターネット上に存在するＷＷＷページのアドレスや、個人または企業のメールアドレスが予め記憶されており、更にそのそれぞれのアドレスがタイプ（大分類）、サブタイプ（小分類）のカテゴリで分類されている。例えば、図４の最初のレコードは、ＷＷＷページのアドレス「http://www.A1.co.jp/A1.html 」が、タイプがショッピングで、サブタイプが車であり、そのアドレスが車のショッピングに関するものであることを示している。こうした分類は、タイプ（大分類）のみの１階層でされてもよいし、より多くの階層によって分類されてもよい。このテーブルは、事前にプロバイダやその他の機関によって設定されていることが望ましい。また、前記分類を、そのアドレスからのキーワード検出により行うこともできる。
【００５８】
図５は、マップイメージ・テーブル１２４のファイル・フォーマットの例を示しており、タイプ、サブタイプ、ステータス、及びイメージ・データを含む。タイプ及びサブタイプは、前記イエローページ・テーブル１２３のタイプ及びサブタイプに対応し、ステータスは、前記接続履歴テーブル１２２のステータスに対応する。タイプ、サブタイプ、及びステータスの組み合わせが、１つのイメージ・データに対応する（タイプ、サブタイプ、及びステータスの連結キーがユニーク・キーとなる）。例えば、最初のレコードは、タイプ、サブタイプ、及びステータスの組み合わせ、即ちショッピング＋車＋通常に対応するイメージ・データがc: image shopping car1.gifであることを意味している。イメージ・データは、ここではｇｉｆデータが示されているが、アニメーションｇｉｆやｂｍｐファイル等のイメージを表現できるその他のデータを含むことができ、この例では示されていないが、ＶＲＭＬで使用する場合には、表示するイメージの立体表現を定義する座標データなどを格納する必要がある。
【００５９】
図６は、マップ・テーブル１２５のファイル・フォーマットの例を示しており、加入者ＩＤ毎にマップデータ（表示形式データ）が対応付けられている。このマップデータは、加入者１５０のコンピュータ上に表示されるマップ表示のもととなるマップデータであり、加入者情報テーブル１２１の実現タイプで、その加入者１５０が何を指定しているかによって、記憶されるデータ（ＨＴＭＬ文書、ＶＲＭＬ文書、またはその他の言語や方法）が異なる。ここでは、ＨＴＭＬ文書であれば、ファイルの拡張子をｈｔｍｌに、ＶＲＭＬ文書であれば、ｗｒｌとして表している。
【００６０】
図７は、マップイメージ・テーブル１２４内のイメージ・データを適当な編集画面で表示した例である。これらのイメージは、ＨＴＭＬ文書で使用されるＧＩＦファイルを編集画面上に表示した例であり、それぞれのイメージが、アドレスのタイプ、サブタイプ、及びステータスの全てを表現できるようなイメージとして設定されるのが好ましい。例えば、図７（Ａ）のcar1.gifは、通常のアクセスが可能な車のショッピングに関するページを表し、図７（Ｂ）のcar2.gifは、最近更新された車のショッピングに関するページを表し、図７（Ｃ）のcar3.gifは、アクセスが混んでいて時間がかかる車のショッピングに関するページを表し、図７（Ｄ）のcar4.gifは、存在しない可能性が高い車のショッピングに関するページを表している。
【００６１】
次に、図８〜１０の処理フローを参照して、プロバイダ・接続管理サーバ１１０の処理を詳細に説明する。図８は、加入者１５０がプロバイダに接続し、その後ネットワーク上の資源にアクセスする際の、前記プロバイダ・接続管理サーバ１１０の処理フローを示している。最初に、プロバイダ・接続管理サーバ１１０は、ステップＳ１００で加入者１５０からの接続要求を待つ。接続要求があると（ステップＳ１００、ｙｅｓ）、ステップＳ１０１で、加入者ＩＤとパスワードのチェックを行い、接続要求のない場合は（ステップＳ１００、Ｎｏ）、前記ステップＳ１００の判定を繰り返す。ここで、接続要求をしてきたユーザが入力した加入者ＩＤのパスワードを、加入者情報テーブル１２１の対応する加入者ＩＤのパスワードと比較し、一致しない場合は接続を拒否する。加入者ＩＤとパスワードが正しい場合、ステップＳ１０２に進み、接続要求してきたユーザを正しい加入者と認証し、プロバイダ・接続管理サーバ１１０と加入者のコンピュータとの間のセッションを確立する。
【００６２】
次に、ステップＳ１０３に進み、マップ・テーブル１２５から、対応する加入者ＩＤのマップデータ及びそのマップデータの表示に必要なデータを加入者のコンピュータに送信する。この時、プロバイダ・メールサーバ１３０内に対応する加入者の未読メールがあれば、その情報も前記マップデータに付加して送信し、加入者に未読メールがあることを通知する。
【００６３】
ステップＳ１０４で加入者１５０からネットワーク上の資源のアクセスが要求されたかを判定する。要求されていない場合（ステップＳ１０４、Ｎｏ）、この判定が繰り返される。一定の時間この繰り返しを行っても要求がない場合は、前記加入者１５０とのコネクションを切断するようにすることもできる。要求があった場合には（ステップＳ１０４、Ｙｅｓ）、ステップＳ１０５に進む。
【００６４】
ステップＳ１０５では、加入者１５０のアクセス内容に応じて、マップ・テーブル１２５内のその加入者に対応するマップデータを更新する。ステップＳ１０６では、加入者が要求したリクエストを処理する。この処理は、従来のプロバイダでの処理と同様であり、ＷＷＷページへのアクセス、メールの送受信、ＦＴＰサイトからのダウンロード等、ネットワーク上の資源に対するあらゆる処理を含む。ステップＳ１０６とステップＳ１０５の処理順序はこの逆でもよいし、また同時に処理されてもよい。ステップＳ１０６の処理が終わると、ステップＳ１０４の判定に戻り、再び加入者１５０のアクセス要求があるのを待つ。
【００６５】
次に、図９では、図８のステップＳ１０５に示されたマップデータ更新処理のフローを詳細に示す。最初に、ステップＳ２０１では、加入者１５０から要求されたアドレスが、その加入者が過去にアクセスされたものかどうかの判定がなされる。この判定は、接続履歴テーブル１２２内の、その加入者１５０に関するアドレスを検索することによって行われる。そのアドレスが過去にアクセスされたものである場合は（ステップＳ２０１、Ｙｅｓ）、ステップＳ２０２に進み、そこで、接続履歴テーブル１２２の対応するアドレスのレコードを、最新アクセス日時として現在の日時を設定し、頻度に１加算して更新する。接続履歴テーブル１２２のレコードをアクセスの度に追加する設計を採用している場合は、新しいレコードにアドレス、最新アクセス日時、頻度（＝１）を設定し、前記テーブル１２２に追加する。その後ステップＳ２０６に進む。
【００６６】
ステップＳ２０１で過去に使用されたアドレスでないと判定された場合は（ステップＳ２０１、Ｎｏ）、ステップＳ２０３に進み、接続履歴テーブル１２２に、そのアドレス、アクセス日時、頻度（＝１）を設定したレコードを追加する。
【００６７】
次に、ステップＳ２０４に進み、そのアドレスに対応するタイプ及びサブタイプを、イエローページ・テーブル１２３から取得する。一部、個人のメールアドレスに関しては、前記イエローページ・テーブル１２３にない可能性も考えられるが、アドレスのフォーマットをパターン識別したり、プロトコル・タイプの識別を加えることによって、それが個人のメールアドレスであると識別されうる。また、イエローページ・テーブル１２３内に対応するアドレスがない場合もあるが、そのような場合には、最終的にそのアドレスに対応するイメージ・データとして、その事実が分かるような任意のイメージを割り当てたり、強制的なメッセージを表示してもよい。
【００６８】
その後、ステップＳ２０５で、前記ステップＳ２０４で取得されたタイプ及びサブタイプを基に、マップイメージ・テーブル１２４から、対応するイメージ・データを取得する。ステップＳ２０６では、アクセスされたアドレス、前記加入者情報テーブル１２１内のマップデータ表示種別、実現タイプ、接続履歴テーブル１２２内の頻度、イエローページ・テーブル１２３内のタイプとサブタイプ、及び前記ステップＳ２０５で取得したマップイメージ・テーブル１２４内のイメージ・データに基づいて、加入者のマップデータを変更・調整・更新する。必要なデータは前記マップデータ表示種別によって異なり、必ずしも前述のデータ全てが必要な訳ではない。
【００６９】
ステップＳ２０５で取得されるイメージ・データは、前述した、図７の（Ａ）のような通常のケースのイメージである。しかし、ここで、後で詳細に説明するマップデータ調整・保守機能１１２Ｄと同様に、要求されたアドレスに対する実際のアクセス結果を接続履歴テーブル内のステータスとして記憶し、そのステータスに基づいて、対応するイメージ・データ（例えば、図７の（Ａ）〜（Ｄ））を取得するようにしてもよい。しかし、この場合は、後述するマップデータ調整・保守機能１１２Ｄとは異なり、要求した１つのアドレスに対してのみ処理がされる。
【００７０】
更新が終わると、ステップＳ２０７で、更新されたマップデータがマップ・テーブル１２５に記憶され、加入者１５０のコンピュータにそのマップデータ及び関連するデータを送信する。
【００７１】
これによって加入者１５０は、新しいアドレスにアクセスしたり、アクセスによってアクセス頻度の傾向が変化したような場合に、即時に加入者１５０のコンピュータ上にその内容を反映したマップデータが送信され、それに基づいてマップ表示が行われる。こうした送信を頻繁に行う必要のない加入者１５０は、加入者１５０がプロバイダに接続された時点でのみマップデータの送信が行われるようにしてもよい。
【００７２】
図１０には、図９で示したステップＳ２０６のマップデータの更新処理フローを、より詳細に示してある。最初に、ステップＳ３０１で、加入者情報テーブル１２１のマップデータ表示種別が何かを判定する。ここでは、「アクセス頻度別の区分け」、「アドレスのタイプ別の区分け」、及び「アクセス頻度別の表示方法変更」といった、３つのマップデータ表示種別が存在するものとして処理を考える。尚、必要に応じて、他の基準を用いたマップデータ表示種別を設定することも可能である。
【００７３】
マップデータ表示種別が、「アクセス頻度別の区分け」である場合、制御は左側の分岐に進み、ステップＳ３０２が実行される。ステップＳ３０２では、表示エリアを所定の区画（Ｐ１〜Ｐｉ）に分ける。この表示エリアは最終的に加入者１５０のコンピュータ上に表示されるエリアである。このステップＳ３０２の処理は、ＨＴＭＬやＶＲＭＬの生成という側面から見れば、それぞれの言語を使用して、前記区画（Ｐ１〜Ｐｉ）が表示されるようにステートメントを生成することを意味している。
【００７４】
次にステップＳ３０３に進み、加入者１５０が過去にアクセスしたアドレスを、そのアクセス頻度に応じて、ｉと同じ数に分類する。例えば、４つの区画（Ｐ１〜Ｐ４）に分類される表示が行われる場合、過去にアクセスしたアドレスＡ１〜Ａ６が、それぞれ１，２，３，４，５，６のアクセス頻度を有していたとする。この場合、最も高いアクセス頻度６を４で割り（結果は１．５）、そして、アクセス頻度が１．５以下のアドレスは区画Ｐ１に、アクセス頻度が１．５より上で３．０以下のアドレスは区画Ｐ２に、アクセス頻度が３．０より上で４．５以下のアドレスは区画Ｐ３に、アクセス頻度が４．５より上で６．０以下のアドレスは区画Ｐ４に分類する。この結果、区画Ｐ１には、アクセス頻度が１のアドレス１つが属し、区画Ｐ２には、アクセス頻度が２と３のアドレス２つが属し、区画Ｐ３には、アクセス頻度が４のアドレス１つが属し、区画Ｐ４には、アクセス頻度が５と６のアドレス２つが属することになる。もちろん、アクセス頻度に応じたこのような分類方法は、上記の線形的な分類方法に限られるものではなく、他の様々な方法が考えられる。
【００７５】
ステップＳ３０４では、ステップＳ３０３で分類されたアドレスを、対応する区画に割り当てる。このステップＳ３０４の処理は、ＨＴＭＬやＶＲＭＬの生成という側面から見れば、それぞれの言語のステートメントを使用して、前記区画（Ｐ１〜Ｐｉ）の中に、その区画に分類されたアドレスに対応するイメージ・データを表示するように指定をすることを意味している。イメージ・データはマップイメージ・テーブル１２４から取得されたものであり、ＨＴＭＬによる表示が行われる場合等で用いられる。ＶＲＭＬによる表示が行われる場合には、表示するイメージの立体表現を定義する座標データ等（不図示）が、前記マップイメージ・テーブル１２４から取得され、そのデータを基にＶＲＭＬによる指定が行われる。ステップＳ３０２〜ステップＳ３０４の処理によって、アクセス頻度別に区分けされたマップデータが生成される。このマップデータの内容は、図８に示すようなＨＴＭＬやＶＲＭＬで記述されたデータであり、加入者１５０のコンピュータに送信され、そこでＷＷＷブラウザやＶＲＭＬビューワによる解釈が行われた後、前記コンピュータ上に、ブックマークやアドレスブックの代わりとなるよう機能するマップ表示が提供される。
【００７６】
ステップＳ３０１で、マップデータ表示種別が「アドレスのタイプ別の区分け」であると判定されると、中央の分岐、即ち、ステップＳ３０５に進む。ステップＳ３０５では、ステップＳ３０２と同様、表示エリアを所定の区画（Ｐ１〜Ｐｊ）に分割する。
【００７７】
次に、ステップＳ３０６で、加入者１５０が過去にアクセスしたアドレスを、そのタイプ及びサブタイプに応じて分類する。前述したように、各アドレスは、イエローページ・テーブル１２３を参照することによって、そのアドレスのタイプ及びサブタイプを取得することができる。こうして得られたタイプ及びサブタイプを前記区画Ｐ１〜Ｐｊに分類する。こうした分類の数及び方法は、自由に設定することができ、例えば、前記タイプのみを各区画に対応させたり、タイプとサブタイプの組み合わせを各区画に対応させたりすることもできる。
【００７８】
次に、ステップＳ３０７では、ステップＳ３０６で分類されたアドレスを、対応する区画に割り当てる。このステップＳ３０７の処理は、ＨＴＭＬやＶＲＭＬの生成という側面から見れば、それぞれの言語のステートメントを使用して、前記区画（Ｐ１〜Ｐｊ）の中に、その区画に分類されたアドレスに対応するイメージ・データを表示するように指定をすることを意味している。イメージ・データはマップイメージ・テーブル１２４から取得されたものであり、ＨＴＭＬによる表示が行われる場合に用いられる。ＶＲＭＬによる表示が行われる場合には、表示するイメージの立体表現を定義する座標データ等（不図示）が、前記マップイメージ・テーブル１２４から取得され、そのデータを基にＶＲＭＬによる指定が行われる。ステップＳ３０５〜ステップＳ３０７の処理によって、アドレスのタイプ別に区分けされたマップデータが生成される。このマップデータの内容は、前述のように、ＨＴＭＬやＶＲＭＬで記述されたデータである。
【００７９】
ステップＳ３０１で、マップデータ表示種別が「アクセス頻度別の表示方法変更」であると判定されると、右側の分岐、即ち、ステップＳ３０８に進む。
ステップＳ３０８では、加入者１５０が過去にアクセスしたアドレスを、そのアクセス頻度に応じて所定の数Ｋに分類する。
【００８０】
次にステップＳ３０９に進み、そこで、前記Ｋ個の分類に応じて、アドレスに対応するイメージ・データの大きさ、色、方向、その他外見的特徴を変更する。また、複数のレベル（Ｋ）に段階的にイメージ・データの表示方法を変更するのではなく、アクセス頻度に比例するようにイメージ・データの表示方法を変更するよう制御することも考えられる。ここでは、アクセス頻度の高いものほど大きく、かつ手前に（表示エリアの下部に）なるよう割り当てる例について述べる。
【００８１】
ステップＳ３０９の処理は、ＨＴＭＬやＶＲＭＬの生成という側面から見れば、それぞれの言語を使用して、前記分類Ｋに応じて、前記イメージ・データの大きさとイメージ・データを表示する位置を指定をすることを意味している。イメージ・データはマップイメージ・テーブル１２４から取得されたものであり、ＨＴＭＬによる表示が行われる場合に用いられる。ＶＲＭＬによる表示が行われる場合には、表示するイメージの立体表現を定義する座標データ等（不図示）が、前記マップイメージ・テーブル１２４から取得され、そのデータを基にＶＲＭＬによる指定が行われる。ステップＳ３０８及びステップＳ３０９の処理によって、アクセス頻度別にイメージ・データの大きさを変更したマップデータが生成される。このマップデータの内容は、前述のように、ＨＴＭＬやＶＲＭＬで記述されたデータである。
【００８２】
図１１には、プロバイダにおけるマップデータ調整・保守機能の処理フローが示されている。この処理は、ユーザのネットワーク資源へのアクセスには関係なく、前述した所定のタイミングで実行される。マップデータ調整・保守機能は、加入者１５０が過去に接続したアドレス（基本的にＷＷＷページに関するアドレスであり、メールアドレスは除く）を、加入者１５０毎に設定されたタイミングで独自にアクセスし、その結果に応じて、その加入者１５０のマップデータを自動的に更新する。加入者１５０毎に設定されたタイミングが経過したかどうかを判定する間隔自体も任意にとることができる。これによって、加入者１５０が次に、マップ表示を行うときに、過去にアクセスしたアドレスに対応するイメージが、加入者１５０の関知しないうちに、その最近のアクセス状況を反映した状態で表示される。
【００８３】
図１１の処理フローは最初に、ステップＳ４０１で、加入者情報テーブル１２１から順に任意の加入者に対応するレコードを１件ずつ取り出す。次に、ステップＳ４０２で、レコードが実際に取り出されたかどうか判定し、レコードがない場合には（ステップＳ４０２、Ｎｏ）、フローは終了する。レコードが存在する場合（ステップＳ４０２、Ｙｅｓ）、ステップＳ４０３に進み、ここでそのレコード内の前回巡回日時から巡回間隔だけ経過した日時が現在、または現在より過去であるかどうかを判定する。前回巡回日時から巡回間隔だけ経過した日時が現在、または現在より過去である場合（ステップＳ４０３、Ｙｅｓ）、即ち前回巡回日時＋巡回間隔≦現在の日時である場合、ステップＳ４０７に進み、接続履歴テーブル１２２から、前記レコードに対応する加入者１５０が過去にアクセスしたアドレスを取得する。
【００８４】
次に、ステップＳ４０８に進み、ここで、その加入者１５０の、過去にアクセスしたアドレスに対応するレコードが存在するか判定する。レコードが存在する場合（ステップＳ４０８、Ｙｅｓ）、ステップＳ４０９に進み、そのアドレスが今回のプロバイダにおける一連の処理の中で、既にアクセスされたアドレスかどうかが判定される。アクセスされたことがなければ（ステップＳ４０９、Ｎｏ）、ステップＳ４１０で、そのアドレスに実際にアクセスが行われ、そのアクセスの際のステータス（アクセス結果）が記憶される。アクセスされたことがあれば（ステップＳ４０９、Ｙｅｓ）、ステップＳ４１１で、過去のアクセス記録からステータスを取得する。これは、プロバイダにおける１回の処理で、異なる加入者１５０が過去に、同じアドレスにアクセスしている場合などに、何度も同じアドレスへ巡回することを避けることができる。ステップＳ４１０またはステップＳ４１１の処理が終わるとステップＳ４１２に進み、マップイメージ・テーブル１２４から、そのアドレスのタイプ、サブタイプ、及びステータスに対応したイメージ・データを取得する。
【００８５】
このようにして、アクセス結果に応じて、そのアドレスに対応するイメージ・データ（ｇｉｆファイルやアニメーションｇｉｆなど）そのものを交換してしまう方法ではなく、そのアクセス結果を表すフラッグ（例えば、アドバルーン、看板、旗など）のイメージを、既存のイメージ・データの上、または付近に配置する方法も考えられる。この方法では、新たに、各アクセス結果に応じたフラッグのイメージを記憶するテーブルを設定する必要があるが、マップイメージ・テーブルには、タイプおよびサブタイプの組み合わせごとにステータス（アクセス結果）に応じたイメージを有する必要がなく、テーブルの容量を小さくすることができる。
【００８６】
こうしたステータス（アクセス結果）の把握は、接続に関するステータスに留まらず、そのホームページで内容が更新されたり、バーゲン、セール、プレゼント等が実施されているといった、ホームページの内容の意味的変化にも対応することができる。また、メールの開封通知の受信に応じて、メールアドレスに対応するイメージを前述のように、他のイメージや、色違いの同じ形状のイメージに変え、またはフラッグのイメージを既存イメージに付加するようにすることもできる。
【００８７】
ホームページが更新された日を把握するためには、例えば、ホームページのリンク情報に掲載された更新日付を取得する、ホームページのインデックスページに対応するＨＴＭＬ文書のファイル更新日を取得する、ＨＴＭＬ文書中の表示内容から、書式などのパターンを基に得られる日付情報を取得する、またはＨＴＭＬ文書内の非表示タグなどに一定の規則によって書かれた日付情報を取得する（ただし、将来の標準化等によって実現される）こと等によって実現される。
【００８８】
ホームページでバーゲン、セール、プレゼントなどを実施していることは、例えば、検索エンジンを用いて「バーゲン」等の文字列を特定の条件下で使用しているホームページを特定する、プロバイダ側で手動により判断し、特定のホームページにマークする（この場合、その情報はイエローページ・テーブル内に記憶されるのが望ましい）などによって判断可能である。
【００８９】
次に、ステップＳ４１３で、加入者単位に、そのアドレスと、そのアドレスに関して取得されたイメージ・データの組を、マップデータ更新用メモリに記憶する。その後、ステップＳ４１４で、接続履歴テーブル１２２から、前記レコードに対応する加入者１５０が過去にアクセスした次のアドレスを取得し、ステップＳ４０８に戻る。
【００９０】
ステップＳ４０３でＮｏ、またはステップＳ４０８でＮｏと判定された場合は、ステップＳ４０４に進む。ここで、前記マップデータ更新用メモリに記憶されたデータがある場合、そのデータに基づいて、その加入者１５０に対応するマップデータを更新する。この処理は、マップデータ更新に関して前述したのと同様の処理である。ただし、この時点では、取得されたイメージ・データには、ステータスに応じて様々なイメージが選択される。ステップＳ４０５では、前記マップデータ更新用メモリがクリアされ、新しい加入者１５０の処理に関する準備を行う。ステップＳ４０６では、加入者情報テーブル１２１から次の加入者のレコードを取得し、ステップＳ４０２に戻る。ステップＳ４０３でＮｏの判定がされた場合には、実質的にステップＳ４０６の処理のみがされてステップＳ４０２に戻る。
【００９１】
図１１の処理フロー及び前述したフローは、本発明の実施例の理解のために例示したに過ぎず、厳密にこうしたフローに制限される必要はない。また、この処理によって、各アドレスのアクセス状態であるステータスをも管理することができ、前述したアクセス頻度などによるイメージの区分けなどに代えて、前記ステータスに応じて、そのアドレスに対応するイメージを区分けするなどの表示方法を提供することもできる。
【００９２】
また更に、前述の処理において、加入者毎に巡回時間を設定せずに、一律で所定の時間間隔でアクセスを行い、その結果を取得したり、頻度の高いアドレスのみアクセス結果の取得を行ったり、接続ビジーやＮｏｔ Ｆｏｕｎｄの状況を、一過性のものである可能性を考え、これらの状況を最終的に判断する所定の基準（例えば、ビジーは過去５回連続してビジーであったときにビジーと判断するなど）を設定するなど、様々な変形例を考えることができる。
【００９３】
図１２は、加入者１５０のコンピュータ上に表示されるマップ表示の例を示している。
図１２は、加入者情報テーブル１２１のマップデータ表示種別が、「アドレスのタイプ別の区分け」であり、実現タイプがＶＲＭＬである場合の表示例である。図１２はまた、加入者１５０が過去にいくつかのアドレスに対してアクセスを行い、少なくとも１回、前述の図１１に示すようなマップデータ調整・保守機能１１２Ｄによる処理が実行されている場合のマップ表示の例である。
【００９４】
図１２のマップ表示２００は、大きくは４つの区画２１０〜２４０、その区画の間の道２５０、ホーム２６０、及びアバタ２７０からなる。区画２１０は、ホームページの検索に関するアドレスの区画として設定され、検索アドレス１、検索アドレス２に対応するイメージ・データ（２１１、２１２）が表示されている。これらのイメージ・データは、ＶＲＭＬにおいては立体表現であり、アバタ２７０の視点によってイメージが現実に近い態様で変化する。区画２２０は、メールアドレスの区画として設定され、メールアドレスＡ１、メールアドレスＡ２に対応するイメージ・データ（２２１、２２２）が表示されている。
【００９５】
検索アドレス１に対応するイメージ・データ２１１は、ここでは建物の前に多くの人が並んでいる、混雑したイメージを使用して表されており、前記マップデータ保守機能１１２Ｄによってアクセスされたときのステータスがビジーであったことを示している。
【００９６】
検索アドレス２に対応するイメージ・データ２１２は、ここでは建物の上に閉店という看板が立てられたイメージを使用して表されており、前記マップデータ調整・保守機能１１２Ｄによってアクセスされたときに（あるいは、それ以前の複数のアクセスにおいて）、見つからなかったことを示している。
【００９７】
区画２３０は、ショッピングに関するアドレスの区画として設定され、あるショッピングのページに関するイメージ・データ２３１が表示されている。区画２４０は空き区画であり、その中には内も表示されていない。
【００９８】
イメージ・データ２３１は、ここでは車のショッピングに関連するページであり、前回のアクセス時からそのページに更新が行われていることが、前記マップデータ調整・保守機能１１２Ｄによって判定されており、図７の（Ｂ）と同様のイメージが示されている。
【００９９】
前述したように、マップイメージ・テーブル１２４では、アドレスのタイプ（大分類）、サブタイプ（小分類）、及びステータスの組み合わせで異なるイメージ・データを使用しているが、ここでは説明の都合上、タイプ（大分類）とステータス毎にイメージ・データを割り当てるよう簡略化して表示する。ただし、ホーム２６０のイメージ・データは、ここでは固定のデータとする。
【０１００】
各イメージ・データに対応するアドレスや、そのサービスに関するタイトル（例えば、ＷＷＷページのタイトル）は、ここでは引き出し線を用いて表示されているが、イメージ・データに重ねて、または付近に関連づけたその他様々な方法で表示させることができる。
【０１０１】
加入者１５０は、アバタ２７０の動きをマウス等で制御して、所望のアドレスに向かう。アバタ２７０は通常、ホーム２６０から出発し、道２５０に沿って移動する。ここでは、カメラ位置が固定されているが、アバタ２７０の視点に基づいてカメラを設置し、そのシーンをリアルタイムに画面に表示することもできる。所望のアドレスに到達すると、そのアドレスがＷＷＷページのアドレスである場合には、そのページがＷＷＷブラウザ（不図示）によって表示され、メールアドレスである場合には、そのメールアドレスが送信先に設定された状態で、メール編集画面（不図示）が表示される。
【０１０２】
このマップ表示によって、加入者１５０は、検索を行おうとするのであれば、アバタ２７０を検索アドレスの区画２１０に進めて、その中の適当なアドレス（イメージ・データ）を選択し、ショッピングのページを見ようとするのであれば、ショッピングに関するアドレスの区画２３０に向かい、その中から適当なアドレス（イメージ・データ）を探す。
【０１０３】
ホーム２６０には、前述したように、未読メールがあるかどうかの情報を示すフラッグが付けられており、未読メールがある場合にはそのフラッグが上がるように設定されている。こうした情報は、他の適当な方法で示されてもよい。
【０１０４】
以上、本発明の実施例を、ＨＴＭＬやＶＲＭＬを使用し、ＷＷＷブラウザやＶＲＭＬビューワで表示するものとして例示してきたが、他のツール、言語及び方法を用いても本発明の特徴を達成することができることは当業者にとって明らかであり、本発明の実施をＨＴＭＬやＶＲＭＬを使用するものとして限定すべきではない。
【０１０５】
また、本発明におけるＷＷＷページの表示やメールの送受信は、現在インターネットを利用して行われることが多く、実施例の説明もそれに準じた表現となっているが、イントラネットやＶＡＮ、ＷＡＮなど、特定のユーザにのみ使用権限が与えられたネットワーク資源に関しても同様に実施することができる。
【０１０６】
また、本発明における前述した特徴を、プロバイダのサーバにおいて実現される実施例に基づいて説明しているが、本発明を加入者１５０におけるコンピュータやその他のコンピュータによって実現することも可能であり、プロバイダのサーバでのみ実現されるものとして限定する必要はない。
【０１０７】
また、本発明は、加入者１５０のネットワーク上の資源に対するアクセスに応じて、そのアドレスを選択しやすいような表示で加入者に提供するシステムであり、実施例では前記アクセスをＷＷＷページへのアクセスとメールの送受信を中心に述べてきた。しかし、こうしたアクセスを、これらに限定する必要はなく、ＦＴＰサイトからの特定のファイルのダウンロードなどを含む、その他の特定のネットワーク上のアドレスに対するアクセスに対して広く応用することができる。
【０１０８】
図１３は、上述した表示形式調整システム１００を実施するコンピュータ８００のハードウエア構成の一例を示している。該コンピュータ８００は、それぞれバス８５０に接続されたＣＰＵ８１０、メモリ８２０、記憶装置８３０、及びネットワーク・インタフェース部８４０からなる。ＣＰＵ８１０は、図１のプロバイダ・接続管理サーバ１１０の各機能１１１、１１２、及び１１３を実行する。メモリ８２０には、前記各機能を実行するプログラムが実行のためにロードされ、その他必要に応じて、加入者１５０から送信されたデータ、または顧客データベース１２０、プロバイダ・メールサーバ１３０、プロバイダ・ＷＷＷサーバ１４０から読み込まれたデータを一時的に記憶する。
【０１０９】
記憶装置８３０は、前記プロバイダ・接続管理サーバ１１０の各機能を実行するプログラムを記憶し、更に、顧客データベース１２０内の各テーブル等を記憶する。ネットワーク・インタフェース８４０は、図１のプロバイダ・接続管理サーバ１１０が、加入者１５０と公衆回線等を介してデータを送受信し、プロバイダ・メールサーバ１３０及びプロバイダ・ＷＷＷサーバ１４０とＬＡＮ等を介してデータを送受信し、更にインターネットなどのネットワーク１６０を介して他のメールサーバ１７０及びＷＷＷサーバ１８０とデータの送受信を行うために使用される通信インタフェース装置である。バス８５０は、前記各構成要素８１０〜８４０間でデータ、指令等の送受信を行うための共通伝送経路である。
【０１１０】
図１３には図示されていないが、その他、マウス、キーボードなどの入力装置、ＣＲＴディスプレイなどの表示装置、及びレーザ・プリンタなどの印刷装置を、必要に応じて付加することができる。
【０１１１】
また、加入者１５０が使用するコンピュータの構成も、基本的には、図１３に示す構成と同様であるが、ＷＷＷブラウザやＶＲＭＬビューワによる表示、及び操作が必要であるため、前記入力装置と表示装置は必須の構成要素である。
【０１１２】
【発明の効果】
本発明によって、ＷＷＷブラウザやＶＲＭＬビューワによりアクセスされるページのアドレス、及びメーラによって送受信されるメールアドレスについて、プロバイダ側でユーザのアクセスとは別に、自動的にアクセスを行い、その結果得られる少なくとも混雑によりアクセス不可となっている状態、及び、前記ソフトウエア資源のアドレスが存在しない状態を含むステータス基づいて、ユーザによって操作可能なユーザ自身を特定するイメージデータを基準としてこのアドレスに対応するイメージデータアドレスの属性に応じて区分けして表示、または、変更、更新し、またはそのアクセス結果に関連する情報を付加する機能を提供することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態の表示形式調整システムのブロック図である。
【図２】顧客データベースの加入者情報テーブルのファイル・レイアウトの例を示す図である。
【図３】顧客データベースの接続履歴テーブルのファイル・レイアウトの例を示す図である。
【図４】顧客データベースのイエローページ・テーブルのファイル・レイアウトの例を示す図である。
【図５】顧客データベースのマップイメージ・テーブルのファイル・レイアウトの例を示す図である。
【図６】顧客データベースのマップ・テーブルのファイル・レイアウトの例を示す図である。
【図７】マップイメージ・テーブルのイメージ・データの編集例を示す図である。
【図８】プロバイダ・接続管理サーバの全体処理フローを示す図である。
【図９】マップデータの調整・更新処理フローを示す図である。
【図１０】マップデータ表示種別毎のマップデータの更新処理フローをより詳細に示す図である。
【図１１】マップデータ調整・保守機能の処理フローを示す図である。
【図１２】マップデータ表示種別が「アドレスのタイプ別の区分け」であり、言語がＶＲＭＬである場合の、マップ表示例を示す図である。
【図１３】本発明を実施するコンピュータの構成を示す図である。
【図１４】従来のブックマーク表示画面を示す図である。
【符号の説明】
１００ 表示形式調整システム
１１０ プロバイダ・接続管理サーバ
１１１ 加入者接続制御機能
１１２ マップデータ処理機能
１１２Ａ 履歴管理機能（履歴管理手段）
１１２Ｂ マップデータ更新機能
１１２Ｃ マップデータ送信機能（表示形式データ送信手段）
１１２Ｄ マップデータ保守機能（表示形式データ調整手段）
１１３ リクエスト処理機能
１２０ 顧客データベース
１３０ プロバイダ・メールサーバ
１４０ プロバイダ・ＷＷＷサーバ
１５０ 加入者
１５０Ａ 加入者Ａ
１５０Ｂ 加入者Ｂ
１６０ ネットワーク
１７０ メールサーバ
１８０ ＷＷＷサーバ
【発明の属する技術分野】
本発明は、ネットワーク・プロバイダ（以下、単に「プロバイダ」と呼ぶ）によるユーザのネットワーク接続管理システムに関し、より詳しくは、プロバイダが、ユーザの過去のアクセス情報に基づいて、そのユーザが過去にアクセスしたアドレスを再びアクセスするために選択可能な表示形式情報としてユーザに提供するシステムに関する。
【０００２】
【従来の技術】
近年、インターネット上で提供されるＷＷＷページを参照し、または作成することが流行しており、これらに関するツールや書籍等が多く流通している。ＷＷＷとは、ワールドワイドウエブ（World Wide Web）の略であり、インターネットを使用した全世界規模の情報網をいう。ＷＷＷページとは、Ｗｅｂドキュメントを構成する情報の単位であり、前記ＷＷＷ上に設置された任意のＷＷＷサーバ内に記憶された、ＨＴＭＬ（Hypertext Markup Language ）と呼ばれる言語で記述されたＨＴＭＬ文書、ＶＲＭＬ（Virtual Reality Modeling Language ）と呼ばれる言語で記述されたＶＲＭＬ文書、および関連するイメージデータ等から成る。
【０００３】
ＷＷＷブラウザは、このページを表示するためのデータをＷｅｂサイトから受信し、そのデータを解釈してＷＷＷブラウザが起動されているコンピュータの表示装置の画面上に表示させる。前記ページがＨＴＭＬ文書で構成されている場合、ＷＷＷでは、テキスト、図、動画、音などの２次元の情報を扱うことができる。また、ＶＲＭＬ文書を用いれば、３次元の情報を統一的に扱うことができ、３次元表示された物体をいろいろな角度から見たり、３次元の街を歩き回ったりすることが可能となり、いわゆるサイバースペース（３次元電脳空間）を表現することができる。
【０００４】
ＷＷＷブラウザのこうした機能によって、そのユーザは、家庭にいながらにして、全世界のページを参照または聴取することができる一方で、自分が作成したページを全世界に向けて発信することができる。
【０００５】
前記「ページ」を表示させるためのＨＴＭＬ文書、ＶＲＭＬ文書、及びイメージデータ等のデータは通常、前記ＷＷＷ上に設置されているＷＷＷサーバ内に、各ユーザ毎に記憶されており、前記ユーザには個人をはじめ、政府、企業、およびその他団体等が含まれる。前記各ユーザは、ＨＴＭＬ文書、またはＶＲＭＬ文書における指定によって、ページを階層的に構成することができ、各ユーザにおける最上位の階層のページを、特に「ホームページ」という。各ユーザは、ページに、いくつかの他のページへのリンクを設けることができ、そのリンク先のページは更に、いくつかの他のページへのリンクを有することができる。このリンクは通常「アンカー」と呼ばれ、前記ＷＷＷブラウザによって表示されたページ上に、そのリンク先のページを示すシンボル（例えば、そのページのアドレスやそのページの内容を間接的に表すイメージ等）として表示される。
【０００６】
ＨＴＭＬ文書とＶＲＭＬ文書の間では、互いに他の文書に対するアンカーを設定することができ、例えば、ＨＴＭＬ文書からＶＲＭＬ文書を呼び出し、またＶＲＭＬ文書からＨＴＭＬ文書を呼び出すこともできる。
【０００７】
ＷＷＷブラウザのユーザは、所望のリンク先を示すシンボルをマウスでクリックすると、ＷＷＷブラウザは、そのリンク先のページに表示を切り替える（リンク先へジャンプする）。また、こうしたリンク先としては、下位の階層のページだけでなく、上位の階層のページや他のＷｅｂサイトのページも指定することができる。
【０００８】
ＨＴＭＬ文書やＶＲＭＬ文書におけるページの指定には、ＵＲＬ（Uniform Resource Locator）と呼ばれる、インターネット上でそれぞれのページを識別するためのアドレスが使用され、例えば「http://www.xxx.co.jp/index.html 」、「http://www.xxx.co.jp/index.wrl」といった表記で表される。
【０００９】
ＷＷＷブラウザのユーザは、そのブラウザによって表示されているページ上の、他のページを示すシンボルをクリックすることによって、所望のページへ表示を切り替え、切り替えられたページ上の他のページを示すシンボルをクリックすることによって、更に他のページへ表示を切り替え、以降次々とページの表示を切り替えていくことができる。
【００１０】
この時、ＷＷＷブラウザは、クリックされた前記シンボルに対応するＵＲＬが示すアドレスのＷＷＷサーバに通常、プロバイダ及びインターネット経由でアクセスし、前記ＷＷＷサーバに格納されているＷｅｂサイトから対象データを、前記ＷＷＷブラウザが実行されているコンピュータのメモリまたは記憶装置にインターネット経由でダウンロードする。
【００１１】
次に、ＷＷＷブラウザは、これらのデータのダウンロードが終了するのを待って、またはダウンロードと共に前記データを前記コンピュータの表示装置上にページとして表示する。
【００１２】
現在、ネットスケープ社のネットスケープ・ナビゲータ、マイクロソフト社のインターネット・エクスプローラ等のＷＷＷブラウザが提供され、広く使用されている。
【００１３】
しかし、ＶＲＭＬ文書を表示させるためにはＶＲＭＬビューワを用意する必要があり、これは前記ネットスケープ社のネットスケープ・ナビゲータなどのＷＷＷブラウザとは別の専用のブラウザかまたは、ＷＷＷブラウザのＶＲＭＬ用プラグイン・モジュールあるいはヘルパーアプリケーション等によって提供される。
【００１４】
ＶＲＭＬは、前述したようにＷＷＷ上で３次元空間および物体(オブジェクト)を記述するための言語である。ユーザは、アバタという人型オブジェクトを利用することで、ＶＲＭＬにより作られた仮想空間の中を歩きまわったり(ウォークスルー)、他のオブジェクトとの会話などのコミニュケーションを可能にする。また更に、その仮想空間の中のシーン（風景）に対して、カメラを定義することによって、そのカメラを通して見る視点を設定することができる。
【００１５】
そのため、現在では、ＶＲＭＬを使って、エンターテイメント（バーチャル遊園地）、バーチャルモール（仮想商店街）、都市の３次元表示、人工生命、及びロボティックスなどへの応用がされつつある。
【００１６】
ＶＲＭＬは、１９９４年に誕生し、１９９５年にＶＲＭＬ１．０の仕様が正式に決まり、現在の仕様は、ＶＲＭＬ２．０である。この２つの仕様には大きな違いがある。ＶＲＭＬ１．０では時間の止まった３次元のシーンを作ることしかできず、音を出力することもできない。しかし、ＶＲＭＬ２．０では、置かれているオブジェクトが急に動き出しだり、クリックすると色が変わったりするシーンを作ることができ、音楽も出力可能な動的な世界を構築可能である。
【００１７】
また、実際のＶＲＭＬビューワでは、前記アバタやカメラなどの移動は通常、それらの位置をマウスのクリックなどによって直接指示するかまたは、それらの前進、後退、回転等の移動の指示を行うボタンをマウスのクリックなどによって操作するようになっている。
【００１８】
前述したような、ページを次々と切り替えていく方法でページを参照する、いわゆる「ネットサーフィン」のような参照方法の他に、表示したいページのＵＲＬが予め分かっている場合に、ＷＷＷブラウザやＶＲＭＬビューワのＧＵＩ（Graphical User Interface）画面上の場所指定エリアに直接ＵＲＬをタイプする方法がある。しかし、株価情報やニュースを表示するページなどを、毎日参照する必要のあるユーザもいる。このように、ある決まったページを毎回参照する必要がある場合には、毎回数十文字におよぶ前述したＵＲＬをタイプするのは不便であり、非効率でもある。そこで、こうしたページを容易に表示させるために、前記ＷＷＷブラウザ等は「ブックマーク機能」と呼ばれる機能を一般的に備えている。
【００１９】
「ブックマーク機能」とは、ＷＷＷブラウザやＶＲＭＬビューワなどで、気に入ったサイトや頻繁にアクセスするページを事前に登録しておく機能であり、表示させたいページのＵＲＬを予めブックマークデータの一情報として登録しておき、「ブックマークの表示」で、ブックマークとして登録されているページを一覧表示してから該当するページをマウスのクリック操作などで選択することによって、わずらわしいＵＲＬのタイプをすることなく、またタイプミスによる時間の浪費を生じさせることなく所望のページを表示させることができるというものである。
【００２０】
図１４にはＷＷＷブラウザの代表的なブックマーク表示画面１０００が示されている。同図に示すように、ブックマークは階層的に管理することができ、ブックマーク１１１１の集合を１つのフォルダ１１１０に収めて管理することができる。これによってユーザは、各ブックマーク１１１１をカテゴリ別に分類して調整することができ、多くのブックマーク１１１１がある場合にも効率的に所望のブックマーク１１１１を探すことができる。例えば、図１４のブックマーク表示画面１０００を参照すると、最上位フォルダとして「BOOKMARK」フォルダ１１００があり、その下の「WWW SEARCH ENGINE」というフォルダ１１１０の中に、「goo」と「Yahoo! JAPAN」というブックマーク１１１１がブックマークとして登録されており、これらのブックマーク１１１１は、前記フォルダ１１１０「WWW SEARCH ENGINE」をマウスなどでクリックすることによって同図のように一覧的に表示される。また、図１４には、フォルダ１１１０に含まれない「IBM Patent Server Home Page 」などのブックマーク１１１１も示されている。
【００２１】
前述の「goo 」や「Yahoo! JAPAN」といった、ブックマーク１１１１を識別するためのタイトルは、通常そのブックマーク１１１１に対応するページを作成した者が設定した、そのページのタイトルがそのまま用いられる。しかし、ＷＷＷブラウザやＶＲＭＬビューワのユーザは、図１４のブックマーク表示画面１０００で「goo 」などのブックマーク１１１１を示す行をマウスでダブルクリックしたり、こうしたブックマーク表示画面１０００以外の、別のブックマーク１１１１を簡易表示するポップアップウインドウ（不図示）で所望のブックマーク１１１１を示す行をクリックすることなどによって、容易に所望のページを選択し、表示させることができる。
【００２２】
ブックマーク１１１１の追加は、通常、最初にＵＲＬをＷＷＷブラウザやＶＲＭＬビューワの場所指定エリアにタイプして所望のページを表示させたとき、または前述したネットサーフィン等で所望のページを見つけたときなどに、そのページを表示させた状態で、マウスのクリックなどの操作で「ブックマークの追加」を指示することによって行われる。この時、そのページのＵＲＬやタイトルを含む情報が自動的にブックマーク１１１１として登録され、ページのタイトルはそのページに対応する登録されたブックマーク１１１１のタイトルとしてそのまま使用される。
【００２３】
また、図１４のブックマーク表示画面１０００で、ブックマーク１１１１を新規に追加する操作において、ＵＲＬやタイトル等をタイプすることによって所望のフォルダ１１１０の中に新たなブックマーク１１１１を追加することもできる。
【００２４】
ブックマーク１１１１内の情報は、例えば、図１４のブックマーク表示画面１０００で、対象のブックマーク１１１１のプロパティをマウスにより選択すること等によって表示されるブックマーク編集画面（不図示）上で編集することができる。更に、図１４のブックマーク表示画面１０００上において、マウス等の操作により、ブックマーク１１１１自体の削除、移動（他のフォルダへの移動を含む）が可能である。
【００２５】
また、近年では、個人または企業、その他の団体によって、インターネットのようなネットワークを経由するメールの送受信が盛んに行われている。これらのメールは、ネットワーク上に設置されたメールサーバ間で送受信され、個人などのユーザは、そのメールサーバを介して、他人にメールを送信し、また自分宛のメールを受信する。メールのアドレスは、メールアドレスによって識別され、インターネット・メールであれば、通常「user@xxx.or.jp」等のフォーマットで提供される。メールには、インターネット・メールの他、パソコン通信やその他の団体、企業内で送受信されるメールがあるが、これらは、ゲートウエイなどを介して相互に送受信される。
【００２６】
現在、こうしたメールの送受信を行うツール（いわゆる、メーラ）は、前述のＷＷＷブラウザとセットになっているものから、メール専用のツールまで様々である。しかし、これらのツールは、メールの送受信に関する基本機能について異なるところはない。ユーザは、ネットワークに接続して、前記メーラを起動し、自分宛のメールを受信する。これらのメールを受信する際には、それらのメールが誰から送信されたものか、またサブジェクトに何を含んでいるか等によって、異なるフォルダに分類して記憶することもできる。送信の際には、「アドレスブック」と呼ばれるところに予め記憶されている送信先のメールアドレスを、メールの送信先としてマウスのクリックなどで簡単に指定することができ、そのメールアドレスを送信の度にタイプする必要がない。もちろん、初めてメールを送信する相手には、メールアドレスのタイプ等が必要になるが、その際に登録処理を行っておけば、その相手に次に送信する際には、メールアドレスは上記のように簡単に指定でき、タイプは不要である。
【００２７】
また、前記アドレスブックに記憶された複数のメールアドレスは、前記ＷＷＷブラウザ等のブックマークと同様に、前記アドレスブック内で複数のフォルダに格納されうる。従って、ブックマークのような階層的な管理も可能である。例えば、友人、会社関係のメールアドレスを分けて管理することができ、また、社内のメール管理においては、各部署ごと、または支店ごとといった分類も可能である。
【００２８】
一般のユーザが、前記ＷＷＷページを見たり、メールの送受信を行うためにインターネットなどのネットワーク上の資源にアクセスするには、インターネットへの常時接続ポイントを有するプロバイダと呼ばれる接続業者のサーバに公衆回線等を介して、ユーザのコンピュータを接続する必要がある。このことによって、前記ユーザは、プロバイダの前記サーバを介してインターネットなどのネットワーク上の資源にアクセスでき、ＨＴＭＬ文書やメールを自分のコンピュータに転送することができる。
【００２９】
【発明が解決しようとする課題】
上述したように、従来のＷＷＷブラウザやＶＲＭＬビューワが有するブックマーク機能では、ページに関する長い文字数のＵＲＬを毎回入力することなく、予め登録してある複数のブックマークのうち所望のページのブックマークをマウス等で選択することによって、そのページをＷＷＷブラウザやＶＲＭＬビューワに表示させることができる。同様に、従来のメーラが有するアドレスブックにおいても、送信先のメールアドレスを毎回入力することなく、簡単な操作によってメールアドレスを選択することができる。
【００３０】
しかし、従来のＷＷＷブラウザやＶＲＭＬビューワ、及びメーラは、このように事前に登録されたアドレスについて、プロバイダ側で自動的にアクセスを行い、そのアクセス結果（例えば、ページの更新、ビジー、またはＮｏｔ Ｆｏｕｎｄなど）に基づいて、そのアドレスに対応するイメージ・データの表示位置や表示方法を変化させ、または関連する情報を付加する機能を提供するものではない。
【００３１】
本発明は、前記課題を解決するために、ＷＷＷブラウザやＶＲＭＬビューワによりアクセスされるページのアドレス、及びメーラによって送受信されるメールアドレスについて、プロバイダ側でユーザのアクセスとは別に、自動的にアクセスを行い、そのアクセス結果に基づいて、そのアドレスに対応するイメージ・データの表示位置や表示方法を変化させ、または関連する情報を付加する機能を提供することを目的とする。
【００３２】
【課題を解決するための手段】
上記本発明の課題を解決するため、請求項１に記載の発明は、ネットワーク上に存在する、それぞれが自己の格納位置を示すアドレスを有するソフトウエア資源に対するユーザからのアクセスを制御し、前記アクセスされたソフトウエア資源と前記ユーザとの間のデータの送受信を処理するネットワーク接続管理システムにおいて、前記ユーザが所定の期間においてアクセスした前記ソフトウエア資源のアドレスを記憶する履歴管理手段と、所定のタイミングで前記履歴管理手段に記憶された前記ソフトウエア資源のアドレスにアクセスし、その結果得られる少なくとも前記ソフトウエア資源に対する他のアクセスによる混雑によりアクセス不可となっている状態、及び、前記ソフトウエア資源のアドレスが存在しない状態を含むステータスを取得する取得手段と、前記取得手段によって取得されたステータスに基づいて、前記ユーザによって操作可能な当該ユーザ自身を特定するイメージデータを基準として該アドレスに対応するイメージデータを該アドレスの属性に応じて区分けして表示するよう表示形式データを調整する表示形式データ調整手段と、前記表示形式データ調整手段により調整された表示形式データで前記ユーザ自身を特定するイメージデータと前記アドレスに対応するイメージデータとを前記ユーザが操作する端末に表示させるよう制御する表示制御手段とを有することを特徴とする。
【００３５】
請求項２に記載の発明は、上記請求項１に記載の発明において、前記ステータスには、少なくとも前記ソフトウエア資源のアドレスによって提供されるサービス内容に関する情報が含まれることを特徴とする。
【００３６】
請求項３に記載の発明は、上記請求項１または２に記載の発明において、前記取得手段が前記ソフトウエア資源のアドレスにアクセスする前記所定のタイミングは、少なくとも前記ユーザ毎に設定できることを特徴とする。
【００３７】
請求項４に記載の発明は、上記請求項１ないし３の何れかに記載の発明において、前記表示形式データ調整手段は更に、前記イメージデータの色、大きさ、模様、及びその他の外見的特徴の変更、イメージデータ自体の変更、及び該イメージデータの上、または付近に他のイメージデータを追加する処理を行うことを特徴とする。
【００３８】
上記本発明の課題を解決するため、請求項５に記載の発明は、ネットワーク上に存在する、それぞれが自己の格納位置を示すアドレスを有するソフトウエア資源に対するユーザからのアクセスを制御し、前記アクセスされたソフトウエア資源と前記ユーザとの間のデータの送受信を処理するネットワーク接続管理方法であって、前記ユーザが所定の期間においてアクセスした前記ソフトウエア資源のアドレスを記憶する履歴管理ステップと、所定のタイミングで前記履歴管理ステップによって記憶された前記ソフトウエア資源のアドレスにアクセスし、その結果得られる少なくとも前記ソフトウエア資源に対する他のアクセスによる混雑によりアクセス不可となっている状態、及び、前記ソフトウエア資源のアドレスが存在しない状態を含むステータスを取得する取得ステップと、前記取得ステップによって取得されたステータスに基づいて、前記ユーザによって操作可能な当該ユーザ自身を特定するイメージデータを基準として該アドレスに対応するイメージデータを該アドレスの属性に応じて区分けして表示するよう表示形式データを調整する表示形式データ調整ステップと、前記表示形式データ調整ステップによって調整された表示形式データで前記ユーザ自身を特定するイメージデータと前記アドレスに対応するイメージデータとを前記ユーザが操作する端末に表示させるよう制御する表示制御ステップとを含むことを特徴とする。
【００３９】
上記本発明の課題を解決するため、請求項６に記載の発明は、ネットワーク上に存在する、それぞれが自己の格納位置を示すアドレスを有するソフトウエア資源に対するユーザからのアクセスを制御し、前記アクセスされたソフトウエア資源と前記ユーザとの間のデータの送受信を処理するコンピュータを、前記ユーザが所定の期間においてアクセスした前記ソフトウエア資源のアドレスを記憶する履歴管理手段、所定のタイミングで前記履歴管理手段によって記憶された前記ソフトウエア資源のアドレスにアクセスし、その結果得られる少なくとも前記ソフトウエア資源に対する他のアクセスによる混雑によりアクセス不可となっている状態、及び、前記ソフトウエア資源のアドレスが存在しない状態を含むステータスを取得する取得手段、前記取得手段によって取得されたステータスに基づいて、前記ユーザによって操作可能な当該ユーザ自身を特定するイメージデータを基準として該アドレスに対応するイメージデータを該アドレスの属性に応じて区分けして表示するよう表示形式データを調整する表示形式データ調整手段、前記表示形式データ調整手段によって調整された表示形式データで前記ユーザ自身を特定するイメージデータと前記アドレスに対応するイメージデータとを前記ユーザが操作する端末に表示させるよう制御する表示制御手段として機能させるためのプログラムを記録したことを特徴とする。
【００４０】
【発明の実施の形態】
以下に、本発明の実施の形態の例について、図面を参照して説明する。尚、各図において、同一または類似のものには同一の参照番号または、記号を付与して説明する。
【００４１】
図１は、本発明の一実施形態のネットワーク接続管理システム１００のシステム構成を示すブロック図である。ネットワーク接続管理システム１００は、プロバイダ・接続管理サーバ１１０、及び顧客データベース１２０を含む。前記プロバイダ・接続管理サーバ１１０は、加入者接続制御機能１１１、マップデータ処理機能１１２、及びリクエスト処理機能１１３を含む。
【００４２】
また、プロバイダ・接続管理サーバ１１０は、必要に応じてプロバイダ・メールサーバ１３０及びプロバイダ・ＷＷＷサーバ１４０に接続される。
加入者１５０の使用するコンピュータ１５０は、そのプロバイダに加入している複数の加入者１５１、１５２等からなり、ネットワーク上の資源にアクセスする際、加入者のコンピュータをプロバイダ・接続管理サーバ１１０に公衆回線等を経由して接続する。
【００４３】
ネットワーク１６０は、例えば、インターネットといった、不特定多数の者がアクセス可能なネットワークであるが、これに限られず、社内ＬＡＮ、ＷＡＮ、ＶＡＮ、イントラネット、及びエクストラネット、その他利用者の限られた特定のネットワーク、及びその他有線・無線に限定されない形態のネットワークを含む。
【００４４】
メールサーバ１７０及びＷＷＷサーバ１８０は、ここで説明の対象としているプロバイダ以外のメールサーバ及びＷＷＷサーバを集合的に示している。
前記加入者接続制御機能１１１は、加入者１５０から、公衆回線等を介して接続要求があった場合、加入者１５０のＩＤとパスワードをチェックし、正常であれば加入者１５０のコンピュータとのコネクションを確立し、インターネット等へのアクセスが可能となるよう制御する。
【００４５】
前記マップデータ処理機能１１２は、履歴管理機能１１２Ａ（履歴管理手段）、マップデータ更新機能１１２Ｂ、マップデータ送信機能１１２Ｃ（表示形式データ送信手段）、及びマップデータ調整・保守機能１１２Ｄ（表示形式データ調整手段）を含み、加入者１５０が過去にアクセスしたアドレスを、ブックマークやアドレスブックに代えて、再度容易に選択可能な３次元的な表現として表示するためにマップ（地図表示形式）データを更新する。このマップデータは、加入者１５０に３次元的な表示を提供するための「もと」となるデータであり、実際はＨＴＭＬ文書やＶＲＭＬ文書である。このように、加入者１５０にマップデータをもとに表示されたものを以降では、「マップ表示」と呼ぶ。
【００４６】
前記履歴管理機能１１２Ａは、加入者１５０が過去にアクセスしたＷＷＷページのアドレス及び送受信したメールアドレスを加入者１５０毎に記憶し、加入者１５０がＷＷＷページのアクセスまたはメールの送受信を行う際に、それらのアドレスがその加入者１５０によって過去に使用されたものかをチェックする。
【００４７】
前記マップデータ更新機能１１２Ｂは、加入者１５０のＷＷＷページへのアクセス状況及びメールの送受信状況に応じて、加入者１５０のコンピュータ上に、加入者１５０が過去にアクセスしたＷＷＷページのアドレス及び送受信したメールアドレスを３次元的に表示するためのマップデータを更新する。
【００４８】
前記マップデータ送信機能１１２Ｃは、加入者１５０のＷＷＷページへのアクセス及びメールの送受信の際、または、加入者１５０がプロバイダに接続した際に、加入者１５０のコンピュータに前記マップデータを送信する。
【００４９】
前記マップデータ調整・保守機能１１２Ｄは、加入者１５０のＷＷＷページへのアクセス及びメールの送受信とは関係なく、加入者１５０毎に（又は一律）設定された間隔で、加入者１５０が過去にアクセスしたＷＷＷページのアドレスを自動的にアクセスし、そのアクセス結果に基づいてマップデータを変更し、調整し、更新する。
【００５０】
リクエスト処理機能１１３は、プロバイダに接続された加入者１５０の要求に応じて、例えば、ＷＷＷページのＨＴＭＬ文書データ、ＶＲＭＬ文書データ、及び関連するその他のデータを、ネットワーク１６０を介して、所定のアドレスのＷＷＷサーバ１８０からダウンロードし、加入者１５０のコンピュータに送信するよう制御し、要求されたメールの送受信を行う。
【００５１】
前記加入者接続制御機能１１１及びリクエスト処理機能１１３は、従来のソフトウエアを用いて従来のプロバイダによって提供されてきた機能である。
前記顧客データベース１２０は、加入者情報テーブル１２１、接続履歴テーブル１２２、イエローページ・テーブル１２３、マップイメージ・テーブル１２４、及びマップ・テーブル１２５を含む。各テーブルの詳細な説明は後述する。
【００５２】
前記プロバイダ・メールサーバ１３０は、そのプロバイダの加入者１５０宛に、例えば、ネットワーク１６０を介して他のプロバイダから送信されてきたメールを記憶し、加入者１５０からの指示によって、その受信メールを加入者側のコンピュータに転送する。
【００５３】
プロバイダ・ＷＷＷサーバ１４０は、プロバイダ及びプロバイダの加入者１５０のＨＴＭＬ文書やＶＲＭＬ文書、及びその他必要なデータ、モジュール等を記憶している。プロバイダの加入者１５０は、一般的には公衆回線を介してそれらのデータにアクセスする。そのプロバイダ以外のプロバイダの加入者は、公衆回線及びネットワーク１６０を介してそれらのデータにアクセスする。通常プロバイダは、ＷＷＷページのアクセスに関するキャッシュ機能及びセキュリティ機能を提供するＰＲＯＸＹサーバを備えているが、この実施例では省略してある。
【００５４】
メールサーバ１７０及びＷＷＷサーバ１８０は、ここで説明の対象としているプロバイダ以外のプロバイダ等のメールサーバ及びＷＷＷサーバを集合的に示している。
【００５５】
図２〜８は、本発明の一実施例で使用する顧客データベース１２０内の各テーブル及びデータの内容を示している。
図２は、加入者情報テーブル１２１のファイル・フォーマットの例を示しており、加入者ＩＤ、加入者名、パスワード、マップデータ表示種別、実現タイプ、巡回間隔、及び前回巡回日時の各項目が示されている。加入者ＩＤ、加入者名、及びパスワードは、プロバイダによって従来から管理されてきた項目であり、加入者１５０がプロバイダへの接続を試みる際に、加入者１５０の接続権限をチェックするために前記加入者接続制御機能１１１によって使用される。マップデータ表示種別は、どのような区分に従って、加入者１５０のマップデータを作成するかを指定する。この例では、「アドレスのタイプ別の区分け」、「アクセス頻度別の区分け」、「アクセス頻度別の表示方法変更」などがある。実現タイプは、加入者１５０のコンピュータに表示されるマップデータのデータタイプであり、このタイプに応じて、適当なアプリケーションが選択され、そのアプリケーションによってマップデータが解釈され、加入者１５０のコンピュータ上にブックマーク及びアドレスブック機能を果たすマップ表示が表示される。この例では、ＨＴＭＬ、ＶＲＭＬといった言語タイプを採用しているが、ＷＷＷページ等へのアンカー機能を有する限り、その他のどのような言語または方法を選択することもできる。巡回間隔は、例えばプロバイダ側で、加入者１５０が過去にアクセスしたアドレスを、自動的に順にアクセス（巡回）する間隔を示している。図２に示す例では、日単位で記憶されているが、時間や秒と言ったその他の単位で記憶されても良い。また、この例では、加入者１５０毎に巡回間隔を管理できる設計になっているが、一律に間隔を設定することもでき、その場合にはこの項目は不要である。前回巡回日時は、その加入者１５０に関する巡回が何時行われたかを示している。プロバイダ側では、前回巡回日時から巡回間隔が経過した時点で前記巡回を行い、今度はその時点を前回巡回日時に設定する。
【００５６】
図３は、接続履歴テーブル１２２のファイル・フォーマットの例を示しており、加入者ＩＤ、接続アドレス、最新アクセス日時、頻度、及びステータスの各項目を含む。アクセスされたアドレスは、加入者ＩＤに割り当てられた加入者によってアクセスされたＷＷＷページのアドレス、または送受信されたメールのアドレスであり、ＷＷＷページのアドレスとメールアドレスが混在して記憶される。最新アクセス日時は、前記アドレスにアクセスした最新の日時を示す。頻度は、一定期間内でそのアドレスにアクセスした回数を示す。このテーブルの例では、同一の加入者が同じアドレスにアクセスした場合は、そのアドレスに対応するレコードの最新アクセス日時及び頻度が更新され、新しいレコードの追加は行われないようになっているが、アクセス等があった場合に新しいレコードを追加して、頻度情報が必要な際に、同じアドレスのレコードの件数をカウントするようにしてもよい。ステータスは、前述の巡回がプロバイダ等によって自動的に行われた場合に、各アドレスに対するアクセス結果のステータス（状況）を示すものである。例えば、前回のアクセス時から更新されている場合は更新日を、回線などの混雑でページにアクセスできなかったときは「ビジー」を、ページが見つからない場合には「Ｎｏｔ Ｆｏｕｎｄ」と、ページのアドレスが変わっている場合には「移動」というように、それぞれ状況に応じて、対応する識別を設定する。
【００５７】
図４は、イエローページ・テーブル１２３のファイル・フォーマットの例を示しており、アドレス、タイプ、及びサブタイプを含む。このテーブルには、インターネット上に存在するＷＷＷページのアドレスや、個人または企業のメールアドレスが予め記憶されており、更にそのそれぞれのアドレスがタイプ（大分類）、サブタイプ（小分類）のカテゴリで分類されている。例えば、図４の最初のレコードは、ＷＷＷページのアドレス「http://www.A1.co.jp/A1.html 」が、タイプがショッピングで、サブタイプが車であり、そのアドレスが車のショッピングに関するものであることを示している。こうした分類は、タイプ（大分類）のみの１階層でされてもよいし、より多くの階層によって分類されてもよい。このテーブルは、事前にプロバイダやその他の機関によって設定されていることが望ましい。また、前記分類を、そのアドレスからのキーワード検出により行うこともできる。
【００５８】
図５は、マップイメージ・テーブル１２４のファイル・フォーマットの例を示しており、タイプ、サブタイプ、ステータス、及びイメージ・データを含む。タイプ及びサブタイプは、前記イエローページ・テーブル１２３のタイプ及びサブタイプに対応し、ステータスは、前記接続履歴テーブル１２２のステータスに対応する。タイプ、サブタイプ、及びステータスの組み合わせが、１つのイメージ・データに対応する（タイプ、サブタイプ、及びステータスの連結キーがユニーク・キーとなる）。例えば、最初のレコードは、タイプ、サブタイプ、及びステータスの組み合わせ、即ちショッピング＋車＋通常に対応するイメージ・データがc: image shopping car1.gifであることを意味している。イメージ・データは、ここではｇｉｆデータが示されているが、アニメーションｇｉｆやｂｍｐファイル等のイメージを表現できるその他のデータを含むことができ、この例では示されていないが、ＶＲＭＬで使用する場合には、表示するイメージの立体表現を定義する座標データなどを格納する必要がある。
【００５９】
図６は、マップ・テーブル１２５のファイル・フォーマットの例を示しており、加入者ＩＤ毎にマップデータ（表示形式データ）が対応付けられている。このマップデータは、加入者１５０のコンピュータ上に表示されるマップ表示のもととなるマップデータであり、加入者情報テーブル１２１の実現タイプで、その加入者１５０が何を指定しているかによって、記憶されるデータ（ＨＴＭＬ文書、ＶＲＭＬ文書、またはその他の言語や方法）が異なる。ここでは、ＨＴＭＬ文書であれば、ファイルの拡張子をｈｔｍｌに、ＶＲＭＬ文書であれば、ｗｒｌとして表している。
【００６０】
図７は、マップイメージ・テーブル１２４内のイメージ・データを適当な編集画面で表示した例である。これらのイメージは、ＨＴＭＬ文書で使用されるＧＩＦファイルを編集画面上に表示した例であり、それぞれのイメージが、アドレスのタイプ、サブタイプ、及びステータスの全てを表現できるようなイメージとして設定されるのが好ましい。例えば、図７（Ａ）のcar1.gifは、通常のアクセスが可能な車のショッピングに関するページを表し、図７（Ｂ）のcar2.gifは、最近更新された車のショッピングに関するページを表し、図７（Ｃ）のcar3.gifは、アクセスが混んでいて時間がかかる車のショッピングに関するページを表し、図７（Ｄ）のcar4.gifは、存在しない可能性が高い車のショッピングに関するページを表している。
【００６１】
次に、図８〜１０の処理フローを参照して、プロバイダ・接続管理サーバ１１０の処理を詳細に説明する。図８は、加入者１５０がプロバイダに接続し、その後ネットワーク上の資源にアクセスする際の、前記プロバイダ・接続管理サーバ１１０の処理フローを示している。最初に、プロバイダ・接続管理サーバ１１０は、ステップＳ１００で加入者１５０からの接続要求を待つ。接続要求があると（ステップＳ１００、ｙｅｓ）、ステップＳ１０１で、加入者ＩＤとパスワードのチェックを行い、接続要求のない場合は（ステップＳ１００、Ｎｏ）、前記ステップＳ１００の判定を繰り返す。ここで、接続要求をしてきたユーザが入力した加入者ＩＤのパスワードを、加入者情報テーブル１２１の対応する加入者ＩＤのパスワードと比較し、一致しない場合は接続を拒否する。加入者ＩＤとパスワードが正しい場合、ステップＳ１０２に進み、接続要求してきたユーザを正しい加入者と認証し、プロバイダ・接続管理サーバ１１０と加入者のコンピュータとの間のセッションを確立する。
【００６２】
次に、ステップＳ１０３に進み、マップ・テーブル１２５から、対応する加入者ＩＤのマップデータ及びそのマップデータの表示に必要なデータを加入者のコンピュータに送信する。この時、プロバイダ・メールサーバ１３０内に対応する加入者の未読メールがあれば、その情報も前記マップデータに付加して送信し、加入者に未読メールがあることを通知する。
【００６３】
ステップＳ１０４で加入者１５０からネットワーク上の資源のアクセスが要求されたかを判定する。要求されていない場合（ステップＳ１０４、Ｎｏ）、この判定が繰り返される。一定の時間この繰り返しを行っても要求がない場合は、前記加入者１５０とのコネクションを切断するようにすることもできる。要求があった場合には（ステップＳ１０４、Ｙｅｓ）、ステップＳ１０５に進む。
【００６４】
ステップＳ１０５では、加入者１５０のアクセス内容に応じて、マップ・テーブル１２５内のその加入者に対応するマップデータを更新する。ステップＳ１０６では、加入者が要求したリクエストを処理する。この処理は、従来のプロバイダでの処理と同様であり、ＷＷＷページへのアクセス、メールの送受信、ＦＴＰサイトからのダウンロード等、ネットワーク上の資源に対するあらゆる処理を含む。ステップＳ１０６とステップＳ１０５の処理順序はこの逆でもよいし、また同時に処理されてもよい。ステップＳ１０６の処理が終わると、ステップＳ１０４の判定に戻り、再び加入者１５０のアクセス要求があるのを待つ。
【００６５】
次に、図９では、図８のステップＳ１０５に示されたマップデータ更新処理のフローを詳細に示す。最初に、ステップＳ２０１では、加入者１５０から要求されたアドレスが、その加入者が過去にアクセスされたものかどうかの判定がなされる。この判定は、接続履歴テーブル１２２内の、その加入者１５０に関するアドレスを検索することによって行われる。そのアドレスが過去にアクセスされたものである場合は（ステップＳ２０１、Ｙｅｓ）、ステップＳ２０２に進み、そこで、接続履歴テーブル１２２の対応するアドレスのレコードを、最新アクセス日時として現在の日時を設定し、頻度に１加算して更新する。接続履歴テーブル１２２のレコードをアクセスの度に追加する設計を採用している場合は、新しいレコードにアドレス、最新アクセス日時、頻度（＝１）を設定し、前記テーブル１２２に追加する。その後ステップＳ２０６に進む。
【００６６】
ステップＳ２０１で過去に使用されたアドレスでないと判定された場合は（ステップＳ２０１、Ｎｏ）、ステップＳ２０３に進み、接続履歴テーブル１２２に、そのアドレス、アクセス日時、頻度（＝１）を設定したレコードを追加する。
【００６７】
次に、ステップＳ２０４に進み、そのアドレスに対応するタイプ及びサブタイプを、イエローページ・テーブル１２３から取得する。一部、個人のメールアドレスに関しては、前記イエローページ・テーブル１２３にない可能性も考えられるが、アドレスのフォーマットをパターン識別したり、プロトコル・タイプの識別を加えることによって、それが個人のメールアドレスであると識別されうる。また、イエローページ・テーブル１２３内に対応するアドレスがない場合もあるが、そのような場合には、最終的にそのアドレスに対応するイメージ・データとして、その事実が分かるような任意のイメージを割り当てたり、強制的なメッセージを表示してもよい。
【００６８】
その後、ステップＳ２０５で、前記ステップＳ２０４で取得されたタイプ及びサブタイプを基に、マップイメージ・テーブル１２４から、対応するイメージ・データを取得する。ステップＳ２０６では、アクセスされたアドレス、前記加入者情報テーブル１２１内のマップデータ表示種別、実現タイプ、接続履歴テーブル１２２内の頻度、イエローページ・テーブル１２３内のタイプとサブタイプ、及び前記ステップＳ２０５で取得したマップイメージ・テーブル１２４内のイメージ・データに基づいて、加入者のマップデータを変更・調整・更新する。必要なデータは前記マップデータ表示種別によって異なり、必ずしも前述のデータ全てが必要な訳ではない。
【００６９】
ステップＳ２０５で取得されるイメージ・データは、前述した、図７の（Ａ）のような通常のケースのイメージである。しかし、ここで、後で詳細に説明するマップデータ調整・保守機能１１２Ｄと同様に、要求されたアドレスに対する実際のアクセス結果を接続履歴テーブル内のステータスとして記憶し、そのステータスに基づいて、対応するイメージ・データ（例えば、図７の（Ａ）〜（Ｄ））を取得するようにしてもよい。しかし、この場合は、後述するマップデータ調整・保守機能１１２Ｄとは異なり、要求した１つのアドレスに対してのみ処理がされる。
【００７０】
更新が終わると、ステップＳ２０７で、更新されたマップデータがマップ・テーブル１２５に記憶され、加入者１５０のコンピュータにそのマップデータ及び関連するデータを送信する。
【００７１】
これによって加入者１５０は、新しいアドレスにアクセスしたり、アクセスによってアクセス頻度の傾向が変化したような場合に、即時に加入者１５０のコンピュータ上にその内容を反映したマップデータが送信され、それに基づいてマップ表示が行われる。こうした送信を頻繁に行う必要のない加入者１５０は、加入者１５０がプロバイダに接続された時点でのみマップデータの送信が行われるようにしてもよい。
【００７２】
図１０には、図９で示したステップＳ２０６のマップデータの更新処理フローを、より詳細に示してある。最初に、ステップＳ３０１で、加入者情報テーブル１２１のマップデータ表示種別が何かを判定する。ここでは、「アクセス頻度別の区分け」、「アドレスのタイプ別の区分け」、及び「アクセス頻度別の表示方法変更」といった、３つのマップデータ表示種別が存在するものとして処理を考える。尚、必要に応じて、他の基準を用いたマップデータ表示種別を設定することも可能である。
【００７３】
マップデータ表示種別が、「アクセス頻度別の区分け」である場合、制御は左側の分岐に進み、ステップＳ３０２が実行される。ステップＳ３０２では、表示エリアを所定の区画（Ｐ１〜Ｐｉ）に分ける。この表示エリアは最終的に加入者１５０のコンピュータ上に表示されるエリアである。このステップＳ３０２の処理は、ＨＴＭＬやＶＲＭＬの生成という側面から見れば、それぞれの言語を使用して、前記区画（Ｐ１〜Ｐｉ）が表示されるようにステートメントを生成することを意味している。
【００７４】
次にステップＳ３０３に進み、加入者１５０が過去にアクセスしたアドレスを、そのアクセス頻度に応じて、ｉと同じ数に分類する。例えば、４つの区画（Ｐ１〜Ｐ４）に分類される表示が行われる場合、過去にアクセスしたアドレスＡ１〜Ａ６が、それぞれ１，２，３，４，５，６のアクセス頻度を有していたとする。この場合、最も高いアクセス頻度６を４で割り（結果は１．５）、そして、アクセス頻度が１．５以下のアドレスは区画Ｐ１に、アクセス頻度が１．５より上で３．０以下のアドレスは区画Ｐ２に、アクセス頻度が３．０より上で４．５以下のアドレスは区画Ｐ３に、アクセス頻度が４．５より上で６．０以下のアドレスは区画Ｐ４に分類する。この結果、区画Ｐ１には、アクセス頻度が１のアドレス１つが属し、区画Ｐ２には、アクセス頻度が２と３のアドレス２つが属し、区画Ｐ３には、アクセス頻度が４のアドレス１つが属し、区画Ｐ４には、アクセス頻度が５と６のアドレス２つが属することになる。もちろん、アクセス頻度に応じたこのような分類方法は、上記の線形的な分類方法に限られるものではなく、他の様々な方法が考えられる。
【００７５】
ステップＳ３０４では、ステップＳ３０３で分類されたアドレスを、対応する区画に割り当てる。このステップＳ３０４の処理は、ＨＴＭＬやＶＲＭＬの生成という側面から見れば、それぞれの言語のステートメントを使用して、前記区画（Ｐ１〜Ｐｉ）の中に、その区画に分類されたアドレスに対応するイメージ・データを表示するように指定をすることを意味している。イメージ・データはマップイメージ・テーブル１２４から取得されたものであり、ＨＴＭＬによる表示が行われる場合等で用いられる。ＶＲＭＬによる表示が行われる場合には、表示するイメージの立体表現を定義する座標データ等（不図示）が、前記マップイメージ・テーブル１２４から取得され、そのデータを基にＶＲＭＬによる指定が行われる。ステップＳ３０２〜ステップＳ３０４の処理によって、アクセス頻度別に区分けされたマップデータが生成される。このマップデータの内容は、図８に示すようなＨＴＭＬやＶＲＭＬで記述されたデータであり、加入者１５０のコンピュータに送信され、そこでＷＷＷブラウザやＶＲＭＬビューワによる解釈が行われた後、前記コンピュータ上に、ブックマークやアドレスブックの代わりとなるよう機能するマップ表示が提供される。
【００７６】
ステップＳ３０１で、マップデータ表示種別が「アドレスのタイプ別の区分け」であると判定されると、中央の分岐、即ち、ステップＳ３０５に進む。ステップＳ３０５では、ステップＳ３０２と同様、表示エリアを所定の区画（Ｐ１〜Ｐｊ）に分割する。
【００７７】
次に、ステップＳ３０６で、加入者１５０が過去にアクセスしたアドレスを、そのタイプ及びサブタイプに応じて分類する。前述したように、各アドレスは、イエローページ・テーブル１２３を参照することによって、そのアドレスのタイプ及びサブタイプを取得することができる。こうして得られたタイプ及びサブタイプを前記区画Ｐ１〜Ｐｊに分類する。こうした分類の数及び方法は、自由に設定することができ、例えば、前記タイプのみを各区画に対応させたり、タイプとサブタイプの組み合わせを各区画に対応させたりすることもできる。
【００７８】
次に、ステップＳ３０７では、ステップＳ３０６で分類されたアドレスを、対応する区画に割り当てる。このステップＳ３０７の処理は、ＨＴＭＬやＶＲＭＬの生成という側面から見れば、それぞれの言語のステートメントを使用して、前記区画（Ｐ１〜Ｐｊ）の中に、その区画に分類されたアドレスに対応するイメージ・データを表示するように指定をすることを意味している。イメージ・データはマップイメージ・テーブル１２４から取得されたものであり、ＨＴＭＬによる表示が行われる場合に用いられる。ＶＲＭＬによる表示が行われる場合には、表示するイメージの立体表現を定義する座標データ等（不図示）が、前記マップイメージ・テーブル１２４から取得され、そのデータを基にＶＲＭＬによる指定が行われる。ステップＳ３０５〜ステップＳ３０７の処理によって、アドレスのタイプ別に区分けされたマップデータが生成される。このマップデータの内容は、前述のように、ＨＴＭＬやＶＲＭＬで記述されたデータである。
【００７９】
ステップＳ３０１で、マップデータ表示種別が「アクセス頻度別の表示方法変更」であると判定されると、右側の分岐、即ち、ステップＳ３０８に進む。
ステップＳ３０８では、加入者１５０が過去にアクセスしたアドレスを、そのアクセス頻度に応じて所定の数Ｋに分類する。
【００８０】
次にステップＳ３０９に進み、そこで、前記Ｋ個の分類に応じて、アドレスに対応するイメージ・データの大きさ、色、方向、その他外見的特徴を変更する。また、複数のレベル（Ｋ）に段階的にイメージ・データの表示方法を変更するのではなく、アクセス頻度に比例するようにイメージ・データの表示方法を変更するよう制御することも考えられる。ここでは、アクセス頻度の高いものほど大きく、かつ手前に（表示エリアの下部に）なるよう割り当てる例について述べる。
【００８１】
ステップＳ３０９の処理は、ＨＴＭＬやＶＲＭＬの生成という側面から見れば、それぞれの言語を使用して、前記分類Ｋに応じて、前記イメージ・データの大きさとイメージ・データを表示する位置を指定をすることを意味している。イメージ・データはマップイメージ・テーブル１２４から取得されたものであり、ＨＴＭＬによる表示が行われる場合に用いられる。ＶＲＭＬによる表示が行われる場合には、表示するイメージの立体表現を定義する座標データ等（不図示）が、前記マップイメージ・テーブル１２４から取得され、そのデータを基にＶＲＭＬによる指定が行われる。ステップＳ３０８及びステップＳ３０９の処理によって、アクセス頻度別にイメージ・データの大きさを変更したマップデータが生成される。このマップデータの内容は、前述のように、ＨＴＭＬやＶＲＭＬで記述されたデータである。
【００８２】
図１１には、プロバイダにおけるマップデータ調整・保守機能の処理フローが示されている。この処理は、ユーザのネットワーク資源へのアクセスには関係なく、前述した所定のタイミングで実行される。マップデータ調整・保守機能は、加入者１５０が過去に接続したアドレス（基本的にＷＷＷページに関するアドレスであり、メールアドレスは除く）を、加入者１５０毎に設定されたタイミングで独自にアクセスし、その結果に応じて、その加入者１５０のマップデータを自動的に更新する。加入者１５０毎に設定されたタイミングが経過したかどうかを判定する間隔自体も任意にとることができる。これによって、加入者１５０が次に、マップ表示を行うときに、過去にアクセスしたアドレスに対応するイメージが、加入者１５０の関知しないうちに、その最近のアクセス状況を反映した状態で表示される。
【００８３】
図１１の処理フローは最初に、ステップＳ４０１で、加入者情報テーブル１２１から順に任意の加入者に対応するレコードを１件ずつ取り出す。次に、ステップＳ４０２で、レコードが実際に取り出されたかどうか判定し、レコードがない場合には（ステップＳ４０２、Ｎｏ）、フローは終了する。レコードが存在する場合（ステップＳ４０２、Ｙｅｓ）、ステップＳ４０３に進み、ここでそのレコード内の前回巡回日時から巡回間隔だけ経過した日時が現在、または現在より過去であるかどうかを判定する。前回巡回日時から巡回間隔だけ経過した日時が現在、または現在より過去である場合（ステップＳ４０３、Ｙｅｓ）、即ち前回巡回日時＋巡回間隔≦現在の日時である場合、ステップＳ４０７に進み、接続履歴テーブル１２２から、前記レコードに対応する加入者１５０が過去にアクセスしたアドレスを取得する。
【００８４】
次に、ステップＳ４０８に進み、ここで、その加入者１５０の、過去にアクセスしたアドレスに対応するレコードが存在するか判定する。レコードが存在する場合（ステップＳ４０８、Ｙｅｓ）、ステップＳ４０９に進み、そのアドレスが今回のプロバイダにおける一連の処理の中で、既にアクセスされたアドレスかどうかが判定される。アクセスされたことがなければ（ステップＳ４０９、Ｎｏ）、ステップＳ４１０で、そのアドレスに実際にアクセスが行われ、そのアクセスの際のステータス（アクセス結果）が記憶される。アクセスされたことがあれば（ステップＳ４０９、Ｙｅｓ）、ステップＳ４１１で、過去のアクセス記録からステータスを取得する。これは、プロバイダにおける１回の処理で、異なる加入者１５０が過去に、同じアドレスにアクセスしている場合などに、何度も同じアドレスへ巡回することを避けることができる。ステップＳ４１０またはステップＳ４１１の処理が終わるとステップＳ４１２に進み、マップイメージ・テーブル１２４から、そのアドレスのタイプ、サブタイプ、及びステータスに対応したイメージ・データを取得する。
【００８５】
このようにして、アクセス結果に応じて、そのアドレスに対応するイメージ・データ（ｇｉｆファイルやアニメーションｇｉｆなど）そのものを交換してしまう方法ではなく、そのアクセス結果を表すフラッグ（例えば、アドバルーン、看板、旗など）のイメージを、既存のイメージ・データの上、または付近に配置する方法も考えられる。この方法では、新たに、各アクセス結果に応じたフラッグのイメージを記憶するテーブルを設定する必要があるが、マップイメージ・テーブルには、タイプおよびサブタイプの組み合わせごとにステータス（アクセス結果）に応じたイメージを有する必要がなく、テーブルの容量を小さくすることができる。
【００８６】
こうしたステータス（アクセス結果）の把握は、接続に関するステータスに留まらず、そのホームページで内容が更新されたり、バーゲン、セール、プレゼント等が実施されているといった、ホームページの内容の意味的変化にも対応することができる。また、メールの開封通知の受信に応じて、メールアドレスに対応するイメージを前述のように、他のイメージや、色違いの同じ形状のイメージに変え、またはフラッグのイメージを既存イメージに付加するようにすることもできる。
【００８７】
ホームページが更新された日を把握するためには、例えば、ホームページのリンク情報に掲載された更新日付を取得する、ホームページのインデックスページに対応するＨＴＭＬ文書のファイル更新日を取得する、ＨＴＭＬ文書中の表示内容から、書式などのパターンを基に得られる日付情報を取得する、またはＨＴＭＬ文書内の非表示タグなどに一定の規則によって書かれた日付情報を取得する（ただし、将来の標準化等によって実現される）こと等によって実現される。
【００８８】
ホームページでバーゲン、セール、プレゼントなどを実施していることは、例えば、検索エンジンを用いて「バーゲン」等の文字列を特定の条件下で使用しているホームページを特定する、プロバイダ側で手動により判断し、特定のホームページにマークする（この場合、その情報はイエローページ・テーブル内に記憶されるのが望ましい）などによって判断可能である。
【００８９】
次に、ステップＳ４１３で、加入者単位に、そのアドレスと、そのアドレスに関して取得されたイメージ・データの組を、マップデータ更新用メモリに記憶する。その後、ステップＳ４１４で、接続履歴テーブル１２２から、前記レコードに対応する加入者１５０が過去にアクセスした次のアドレスを取得し、ステップＳ４０８に戻る。
【００９０】
ステップＳ４０３でＮｏ、またはステップＳ４０８でＮｏと判定された場合は、ステップＳ４０４に進む。ここで、前記マップデータ更新用メモリに記憶されたデータがある場合、そのデータに基づいて、その加入者１５０に対応するマップデータを更新する。この処理は、マップデータ更新に関して前述したのと同様の処理である。ただし、この時点では、取得されたイメージ・データには、ステータスに応じて様々なイメージが選択される。ステップＳ４０５では、前記マップデータ更新用メモリがクリアされ、新しい加入者１５０の処理に関する準備を行う。ステップＳ４０６では、加入者情報テーブル１２１から次の加入者のレコードを取得し、ステップＳ４０２に戻る。ステップＳ４０３でＮｏの判定がされた場合には、実質的にステップＳ４０６の処理のみがされてステップＳ４０２に戻る。
【００９１】
図１１の処理フロー及び前述したフローは、本発明の実施例の理解のために例示したに過ぎず、厳密にこうしたフローに制限される必要はない。また、この処理によって、各アドレスのアクセス状態であるステータスをも管理することができ、前述したアクセス頻度などによるイメージの区分けなどに代えて、前記ステータスに応じて、そのアドレスに対応するイメージを区分けするなどの表示方法を提供することもできる。
【００９２】
また更に、前述の処理において、加入者毎に巡回時間を設定せずに、一律で所定の時間間隔でアクセスを行い、その結果を取得したり、頻度の高いアドレスのみアクセス結果の取得を行ったり、接続ビジーやＮｏｔ Ｆｏｕｎｄの状況を、一過性のものである可能性を考え、これらの状況を最終的に判断する所定の基準（例えば、ビジーは過去５回連続してビジーであったときにビジーと判断するなど）を設定するなど、様々な変形例を考えることができる。
【００９３】
図１２は、加入者１５０のコンピュータ上に表示されるマップ表示の例を示している。
図１２は、加入者情報テーブル１２１のマップデータ表示種別が、「アドレスのタイプ別の区分け」であり、実現タイプがＶＲＭＬである場合の表示例である。図１２はまた、加入者１５０が過去にいくつかのアドレスに対してアクセスを行い、少なくとも１回、前述の図１１に示すようなマップデータ調整・保守機能１１２Ｄによる処理が実行されている場合のマップ表示の例である。
【００９４】
図１２のマップ表示２００は、大きくは４つの区画２１０〜２４０、その区画の間の道２５０、ホーム２６０、及びアバタ２７０からなる。区画２１０は、ホームページの検索に関するアドレスの区画として設定され、検索アドレス１、検索アドレス２に対応するイメージ・データ（２１１、２１２）が表示されている。これらのイメージ・データは、ＶＲＭＬにおいては立体表現であり、アバタ２７０の視点によってイメージが現実に近い態様で変化する。区画２２０は、メールアドレスの区画として設定され、メールアドレスＡ１、メールアドレスＡ２に対応するイメージ・データ（２２１、２２２）が表示されている。
【００９５】
検索アドレス１に対応するイメージ・データ２１１は、ここでは建物の前に多くの人が並んでいる、混雑したイメージを使用して表されており、前記マップデータ保守機能１１２Ｄによってアクセスされたときのステータスがビジーであったことを示している。
【００９６】
検索アドレス２に対応するイメージ・データ２１２は、ここでは建物の上に閉店という看板が立てられたイメージを使用して表されており、前記マップデータ調整・保守機能１１２Ｄによってアクセスされたときに（あるいは、それ以前の複数のアクセスにおいて）、見つからなかったことを示している。
【００９７】
区画２３０は、ショッピングに関するアドレスの区画として設定され、あるショッピングのページに関するイメージ・データ２３１が表示されている。区画２４０は空き区画であり、その中には内も表示されていない。
【００９８】
イメージ・データ２３１は、ここでは車のショッピングに関連するページであり、前回のアクセス時からそのページに更新が行われていることが、前記マップデータ調整・保守機能１１２Ｄによって判定されており、図７の（Ｂ）と同様のイメージが示されている。
【００９９】
前述したように、マップイメージ・テーブル１２４では、アドレスのタイプ（大分類）、サブタイプ（小分類）、及びステータスの組み合わせで異なるイメージ・データを使用しているが、ここでは説明の都合上、タイプ（大分類）とステータス毎にイメージ・データを割り当てるよう簡略化して表示する。ただし、ホーム２６０のイメージ・データは、ここでは固定のデータとする。
【０１００】
各イメージ・データに対応するアドレスや、そのサービスに関するタイトル（例えば、ＷＷＷページのタイトル）は、ここでは引き出し線を用いて表示されているが、イメージ・データに重ねて、または付近に関連づけたその他様々な方法で表示させることができる。
【０１０１】
加入者１５０は、アバタ２７０の動きをマウス等で制御して、所望のアドレスに向かう。アバタ２７０は通常、ホーム２６０から出発し、道２５０に沿って移動する。ここでは、カメラ位置が固定されているが、アバタ２７０の視点に基づいてカメラを設置し、そのシーンをリアルタイムに画面に表示することもできる。所望のアドレスに到達すると、そのアドレスがＷＷＷページのアドレスである場合には、そのページがＷＷＷブラウザ（不図示）によって表示され、メールアドレスである場合には、そのメールアドレスが送信先に設定された状態で、メール編集画面（不図示）が表示される。
【０１０２】
このマップ表示によって、加入者１５０は、検索を行おうとするのであれば、アバタ２７０を検索アドレスの区画２１０に進めて、その中の適当なアドレス（イメージ・データ）を選択し、ショッピングのページを見ようとするのであれば、ショッピングに関するアドレスの区画２３０に向かい、その中から適当なアドレス（イメージ・データ）を探す。
【０１０３】
ホーム２６０には、前述したように、未読メールがあるかどうかの情報を示すフラッグが付けられており、未読メールがある場合にはそのフラッグが上がるように設定されている。こうした情報は、他の適当な方法で示されてもよい。
【０１０４】
以上、本発明の実施例を、ＨＴＭＬやＶＲＭＬを使用し、ＷＷＷブラウザやＶＲＭＬビューワで表示するものとして例示してきたが、他のツール、言語及び方法を用いても本発明の特徴を達成することができることは当業者にとって明らかであり、本発明の実施をＨＴＭＬやＶＲＭＬを使用するものとして限定すべきではない。
【０１０５】
また、本発明におけるＷＷＷページの表示やメールの送受信は、現在インターネットを利用して行われることが多く、実施例の説明もそれに準じた表現となっているが、イントラネットやＶＡＮ、ＷＡＮなど、特定のユーザにのみ使用権限が与えられたネットワーク資源に関しても同様に実施することができる。
【０１０６】
また、本発明における前述した特徴を、プロバイダのサーバにおいて実現される実施例に基づいて説明しているが、本発明を加入者１５０におけるコンピュータやその他のコンピュータによって実現することも可能であり、プロバイダのサーバでのみ実現されるものとして限定する必要はない。
【０１０７】
また、本発明は、加入者１５０のネットワーク上の資源に対するアクセスに応じて、そのアドレスを選択しやすいような表示で加入者に提供するシステムであり、実施例では前記アクセスをＷＷＷページへのアクセスとメールの送受信を中心に述べてきた。しかし、こうしたアクセスを、これらに限定する必要はなく、ＦＴＰサイトからの特定のファイルのダウンロードなどを含む、その他の特定のネットワーク上のアドレスに対するアクセスに対して広く応用することができる。
【０１０８】
図１３は、上述した表示形式調整システム１００を実施するコンピュータ８００のハードウエア構成の一例を示している。該コンピュータ８００は、それぞれバス８５０に接続されたＣＰＵ８１０、メモリ８２０、記憶装置８３０、及びネットワーク・インタフェース部８４０からなる。ＣＰＵ８１０は、図１のプロバイダ・接続管理サーバ１１０の各機能１１１、１１２、及び１１３を実行する。メモリ８２０には、前記各機能を実行するプログラムが実行のためにロードされ、その他必要に応じて、加入者１５０から送信されたデータ、または顧客データベース１２０、プロバイダ・メールサーバ１３０、プロバイダ・ＷＷＷサーバ１４０から読み込まれたデータを一時的に記憶する。
【０１０９】
記憶装置８３０は、前記プロバイダ・接続管理サーバ１１０の各機能を実行するプログラムを記憶し、更に、顧客データベース１２０内の各テーブル等を記憶する。ネットワーク・インタフェース８４０は、図１のプロバイダ・接続管理サーバ１１０が、加入者１５０と公衆回線等を介してデータを送受信し、プロバイダ・メールサーバ１３０及びプロバイダ・ＷＷＷサーバ１４０とＬＡＮ等を介してデータを送受信し、更にインターネットなどのネットワーク１６０を介して他のメールサーバ１７０及びＷＷＷサーバ１８０とデータの送受信を行うために使用される通信インタフェース装置である。バス８５０は、前記各構成要素８１０〜８４０間でデータ、指令等の送受信を行うための共通伝送経路である。
【０１１０】
図１３には図示されていないが、その他、マウス、キーボードなどの入力装置、ＣＲＴディスプレイなどの表示装置、及びレーザ・プリンタなどの印刷装置を、必要に応じて付加することができる。
【０１１１】
また、加入者１５０が使用するコンピュータの構成も、基本的には、図１３に示す構成と同様であるが、ＷＷＷブラウザやＶＲＭＬビューワによる表示、及び操作が必要であるため、前記入力装置と表示装置は必須の構成要素である。
【０１１２】
【発明の効果】
本発明によって、ＷＷＷブラウザやＶＲＭＬビューワによりアクセスされるページのアドレス、及びメーラによって送受信されるメールアドレスについて、プロバイダ側でユーザのアクセスとは別に、自動的にアクセスを行い、その結果得られる少なくとも混雑によりアクセス不可となっている状態、及び、前記ソフトウエア資源のアドレスが存在しない状態を含むステータス基づいて、ユーザによって操作可能なユーザ自身を特定するイメージデータを基準としてこのアドレスに対応するイメージデータアドレスの属性に応じて区分けして表示、または、変更、更新し、またはそのアクセス結果に関連する情報を付加する機能を提供することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態の表示形式調整システムのブロック図である。
【図２】顧客データベースの加入者情報テーブルのファイル・レイアウトの例を示す図である。
【図３】顧客データベースの接続履歴テーブルのファイル・レイアウトの例を示す図である。
【図４】顧客データベースのイエローページ・テーブルのファイル・レイアウトの例を示す図である。
【図５】顧客データベースのマップイメージ・テーブルのファイル・レイアウトの例を示す図である。
【図６】顧客データベースのマップ・テーブルのファイル・レイアウトの例を示す図である。
【図７】マップイメージ・テーブルのイメージ・データの編集例を示す図である。
【図８】プロバイダ・接続管理サーバの全体処理フローを示す図である。
【図９】マップデータの調整・更新処理フローを示す図である。
【図１０】マップデータ表示種別毎のマップデータの更新処理フローをより詳細に示す図である。
【図１１】マップデータ調整・保守機能の処理フローを示す図である。
【図１２】マップデータ表示種別が「アドレスのタイプ別の区分け」であり、言語がＶＲＭＬである場合の、マップ表示例を示す図である。
【図１３】本発明を実施するコンピュータの構成を示す図である。
【図１４】従来のブックマーク表示画面を示す図である。
【符号の説明】
１００ 表示形式調整システム
１１０ プロバイダ・接続管理サーバ
１１１ 加入者接続制御機能
１１２ マップデータ処理機能
１１２Ａ 履歴管理機能（履歴管理手段）
１１２Ｂ マップデータ更新機能
１１２Ｃ マップデータ送信機能（表示形式データ送信手段）
１１２Ｄ マップデータ保守機能（表示形式データ調整手段）
１１３ リクエスト処理機能
１２０ 顧客データベース
１３０ プロバイダ・メールサーバ
１４０ プロバイダ・ＷＷＷサーバ
１５０ 加入者
１５０Ａ 加入者Ａ
１５０Ｂ 加入者Ｂ
１６０ ネットワーク
１７０ メールサーバ
１８０ ＷＷＷサーバ
Claims (6)
- ネットワーク上に存在する、それぞれが自己の格納位置を示すアドレスを有するソフトウエア資源に対するユーザからのアクセスを制御し、前記アクセスされたソフトウエア資源と前記ユーザとの間のデータの送受信を処理するネットワーク接続管理システムにおいて、
前記ユーザが所定の期間においてアクセスした前記ソフトウエア資源のアドレスを記憶する履歴管理手段と、
所定のタイミングで前記履歴管理手段に記憶された前記ソフトウエア資源のアドレスにアクセスし、その結果得られる少なくとも前記ソフトウエア資源に対する他のアクセスによる混雑によりアクセス不可となっている状態、及び、前記ソフトウエア資源のアドレスが存在しない状態を含むステータスを取得する取得手段と、
前記取得手段によって取得されたステータスに基づいて、前記ユーザによって操作可能な当該ユーザ自身を特定するイメージデータを基準として該アドレスに対応するイメージデータを該アドレスの属性に応じて区分けして表示するよう表示形式データを調整する表示形式データ調整手段と、
前記表示形式データ調整手段により調整された表示形式データで前記ユーザ自身を特定するイメージデータと前記アドレスに対応するイメージデータとを前記ユーザが操作する端末に表示させるよう制御する表示制御手段と
を有することを特徴とする表示形式調整システム。 - 前記ステータスには、少なくとも前記ソフトウエア資源のアドレスによって提供されるサービス内容に関する情報が含まれることを特徴とする請求項１に記載の表示形式調整システム。
- 前記取得手段が前記ソフトウエア資源のアドレスにアクセスする前記所定のタイミングは、少なくとも前記ユーザ毎に設定できることを特徴とする請求項１または２に記載の表示形式調整システム。
- 前記表示形式データ調整手段は更に、前記イメージデータの色、大きさ、模様、及びその他の外見的特徴の変更、イメージデータ自体の変更、及び該イメージデータの上、または付近に他のイメージデータを追加する処理を行うことを特徴とする請求項１ないし３の何れかに記載の表示形式調整システム。
- ネットワーク上に存在する、それぞれが自己の格納位置を示すアドレスを有するソフトウエア資源に対するユーザからのアクセスを制御し、前記アクセスされたソフトウエア資源と前記ユーザとの間のデータの送受信を処理するネットワーク接続管理方法であって、
前記ユーザが所定の期間においてアクセスした前記ソフトウエア資源のアドレスを記憶する履歴管理ステップと、
所定のタイミングで前記履歴管理ステップによって記憶された前記ソフトウエア資源のアドレスにアクセスし、その結果得られる少なくとも前記ソフトウエア資源に対する他のアクセスによる混雑によりアクセス不可となっている状態、及び、前記ソフトウエア資源のアドレスが存在しない状態を含むステータスを取得する取得ステップと、
前記取得ステップによって取得されたステータスに基づいて、前記ユーザによって操作可能な当該ユーザ自身を特定するイメージデータを基準として該アドレスに対応するイメージデータを該アドレスの属性に応じて区分けして表示するよう表示形式データを調整する表示形式データ調整ステップと、
前記表示形式データ調整ステップによって調整された表示形式データで前記ユーザ自身を特定するイメージデータと前記アドレスに対応するイメージデータとを前記ユーザが操作する端末に表示させるよう制御する表示制御ステップと
を含むことを特徴とする表示形式調整方法。 - ネットワーク上に存在する、それぞれが自己の格納位置を示すアドレスを有するソフトウエア資源に対するユーザからのアクセスを制御し、前記アクセスされたソフトウエア資源と前記ユーザとの間のデータの送受信を処理するコンピュータを、
前記ユーザが所定の期間においてアクセスした前記ソフトウエア資源のアドレスを記憶する履歴管理手段、
所定のタイミングで前記履歴管理手段によって記憶された前記ソフトウエア資源のアドレスにアクセスし、その結果得られる少なくとも前記ソフトウエア資源に対する他のアクセスによる混雑によりアクセス不可となっている状態、及び、前記ソフトウエア資源のアドレスが存在しない状態を含むステータスを取得する取得手段、
前記取得手段によって取得されたステータスに基づいて、前記ユーザによって操作可能な当該ユーザ自身を特定するイメージデータを基準として該アドレスに対応するイメージデータを該アドレスの属性に応じて区分けして表示するよう表示形式データを調整する表示形式データ調整手段、
前記表示形式データ調整手段によって調整された表示形式データで前記ユーザ自身を特定するイメージデータと前記アドレスに対応するイメージデータとを前記ユーザが操作する端末に表示させるよう制御する表示制御手段
として機能させるためのプログラムを記録したことを特徴とする該コンピュータ読み取り可能な記録媒体。
Priority Applications (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP36153897A JP4010041B2 (ja) | 1997-12-26 | 1997-12-26 | 表示形式調整システム、表示形式調整方法、及び記録媒体 |
| EP98124520A EP0926591B1 (en) | 1997-12-26 | 1998-12-22 | Network-access management system and method |
| DE69831307T DE69831307T2 (de) | 1997-12-26 | 1998-12-22 | System und Verfahren zur Netzzugriffsverwaltung |
| US09/218,279 US6487557B1 (en) | 1997-12-26 | 1998-12-22 | Network-access management system and method applied to network and computer program product including computer program recorded on storage medium for creating display data |
| CNB981116868A CN1163837C (zh) | 1997-12-26 | 1998-12-25 | 网络访问管理系统和方法 |
| KR1019980058941A KR100313446B1 (ko) | 1997-12-26 | 1998-12-26 | 네트워크에적용되는네트워크접속관리시스템,네트워크접속관리방법및표시데이터작성프로그램을기억하는기억매체 |
| HK00102042A HK1023195A1 (en) | 1997-12-26 | 2000-04-05 | Network-access management system and method. |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP36153897A JP4010041B2 (ja) | 1997-12-26 | 1997-12-26 | 表示形式調整システム、表示形式調整方法、及び記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11195027A JPH11195027A (ja) | 1999-07-21 |
| JP4010041B2 true JP4010041B2 (ja) | 2007-11-21 |
Family
ID=18473983
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP36153897A Expired - Lifetime JP4010041B2 (ja) | 1997-12-26 | 1997-12-26 | 表示形式調整システム、表示形式調整方法、及び記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4010041B2 (ja) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3529040B2 (ja) * | 1999-12-21 | 2004-05-24 | 日本電気株式会社 | データベース装置、データベース管理方法及びデータベースの管理プログラムを格納する記憶媒体 |
| US7284232B1 (en) | 2000-05-15 | 2007-10-16 | International Business Machines Corporation | Automated generation of aliases based on embedded alias information |
| JP2002117062A (ja) * | 2000-10-05 | 2002-04-19 | Bellsystem 24 Inc | 履歴フッキングシステム |
| US7409441B2 (en) | 2001-05-18 | 2008-08-05 | Sony Computer Entertainment Inc. | Display apparatus for accessing desired web site |
| JP3556203B2 (ja) * | 2001-05-18 | 2004-08-18 | 株式会社ソニー・コンピュータエンタテインメント | 表示装置及び表示方法 |
| US7266847B2 (en) * | 2003-09-25 | 2007-09-04 | Voltage Security, Inc. | Secure message system with remote decryption service |
| JP2007133568A (ja) | 2005-11-09 | 2007-05-31 | Fuji Xerox Co Ltd | 多層ワーク支援装置、多層ワーク支援装置の割当方法並びに表示方法、及びプログラム |
| JP4842980B2 (ja) * | 2008-01-18 | 2011-12-21 | 芳光 鍵和田 | 情報検索システム及び情報検索プログラム |
-
1997
- 1997-12-26 JP JP36153897A patent/JP4010041B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11195027A (ja) | 1999-07-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100313446B1 (ko) | 네트워크에적용되는네트워크접속관리시스템,네트워크접속관리방법및표시데이터작성프로그램을기억하는기억매체 | |
| US6708172B1 (en) | Community-based shared multiple browser environment | |
| CN100458789C (zh) | 用于交换门户组件配置数据的方法和系统 | |
| US20060184886A1 (en) | Spatial chat in a multiple browser environment | |
| AU2007332917B2 (en) | Method and system for intellegent processing of electronic information | |
| JPH11195028A (ja) | 表示形式作成システム、表示システム、表示形式作成方法、及び記録媒体 | |
| US20020047868A1 (en) | Electronic bulletin board and bulletin board system | |
| US20050097180A1 (en) | System and method for improved customized portal web pages | |
| US20020091697A1 (en) | Virtual desktop in a computer network | |
| EP0848339B1 (en) | Server with automatic loading of menus | |
| WO2008103326A1 (en) | Systems and methods for sharing data | |
| JP2003521785A (ja) | 翻訳発注システム | |
| JP4010041B2 (ja) | 表示形式調整システム、表示形式調整方法、及び記録媒体 | |
| WO2005121982A1 (ja) | 情報提供システム、方法、プログラム、情報通信端末、および情報表示切り替えプログラム | |
| US20090030881A1 (en) | Data Handling | |
| KR20020004093A (ko) | 인터넷 광고 제작장치 및 방법 | |
| JP3737310B2 (ja) | Ｗｗｗサーバーシステム | |
| JP2000259485A (ja) | コンテンツ公開システムおよび自動公開処理方法 | |
| KR100546848B1 (ko) | 개인 홈페이지 통합 관리 방법 및 시스템 | |
| US7065529B1 (en) | Web page searching device for a portable telephone | |
| JPH11265331A (ja) | 表示形式作成システム、方法、及び記録媒体 | |
| JP3662857B2 (ja) | 検索システム、検索方法及び検索プログラム | |
| JP4445654B2 (ja) | ネットワークを用いたオークションシステム | |
| KR20010089124A (ko) | 네트워크를 기반으로 한 고객 홈페이지 작성 시스템 및 그방법 | |
| JP2002082883A (ja) | 電子メールを利用したユーザサポートシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060808 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061006 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070227 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070420 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070510 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070612 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070622 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070814 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070827 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100914 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100914 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100914 Year of fee payment: 3 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| R371 | Transfer withdrawn |
Free format text: JAPANESE INTERMEDIATE CODE: R371 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100914 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100914 Year of fee payment: 3 |
|
| R371 | Transfer withdrawn |
Free format text: JAPANESE INTERMEDIATE CODE: R371 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100914 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100914 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110914 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120914 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120914 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130914 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |