1)パソコン通信サービス用通信端末装置
次に、本発明の実施の形態を実施例に基づき説明する。図1は本発明の第1の実施例としての通信端末装置の構成を示すブロック図である。本実施例は、いわゆるパソコン通信サービスを受けるための通信端末装置であり、後述するようなコンピュータによって実現されている。
ここで、パソコン通信とは、一般に、パソコン(パーソナルコンピュータ),ワープロ(ワードプロセッサ専用機),家庭用ゲームコンピュータなどで実現される通信端末装置を使って、通信回線を介してパソコン通信センタに置かれたホストコンピュータやサーバなどの通信ホストにアクセスし、通信ホストの蓄積・処理機能を利用して、メッセージやデータなどの送受信を行なうものである。このようなパソコン通信を介して提供されるパソコン通信サービスとしては、電子メール、電子会議、電子掲示板(BBS)、チャットなどのコミュニケーションサービスや、ニュース、天気予報、ライブラリなどの情報提供サービスなどがある。
1−1)通信端末装置を実現するコンピュータの構成
図2は図1の通信端末装置を実現するコンピュータの概略構成を示すブロック図である。
まず、説明の都合上、図2に従って、本実施例の通信端末装置を実現するコンピュータの全体構成について説明する。
図2に示すように、このコンピュータ10は、ローカルバス22に接続された演算処理部20、ローカルバス22を外部バスの一つであるPCIバス32に接続するPCIブリッジ30、PCIバス32を介して演算処理部20のCPU21等によりアクセスを受けるコントローラ部40、各種のI/O装置等を制御する機器が低速の外部バスであるISAバス42に接続されたI/O部60、および周辺機器であるキーボード72,スピーカ74,モニタ(カラーCRT)76などから構成されている。
演算処理部20は、中央演算処理装置としてのCPU21(本実施例ではインテル社製PentiumTMを使用)、キャッシュメモリ23,そのキャッシュコントローラ24およびメインメモリ25から構成されている。PCIブリッジ30は、高速のPCIバス32を制御する機能を備えたコントローラである。CPU21が扱うメモリ空間は、CPU21の内部に用意された各種レジスタにより、実際の物理アドレスより広い論理アドレスに拡張されている。
コントローラ部40は、モニタ76への画像の表示を司るグラフィックスコントローラ(以下、CRTCと呼ぶ)44、接続されるSCSI機器とのデータ転送を司るSCSIコントローラ46、PCIバス32と下位のISAバスとのインタフェースを司るPCI−ISAブリッジ48から構成されている。CRTC44は、モニタ(カラーCRT)76に対して、640×480ドット、16色表示が可能である。なお、表示用のフォントを記憶したキャラクタジェネレータや所定のコマンドを受け取って所定の図形を描画するグラフィックコントローラ、更には描画画像を記憶するビデオメモリ等は、このCRTC44に実装されているが、これらの構成は周知のものなので、図2では図示を省略した。
PCI−ISAブリッジ48を介して接続されたISAバス42は、各種のI/O機器が接続される入出力制御用のバスであり、DMAコントローラ50、リアルタイムクロック(RTC)52、複合I/Oポート54、サウンドI/O56、キーボード72および2ボタンマウス73とのインタフェースを司るキーボードインタフェース64、優先順位を有する割り込み制御を行なう割り込みコントローラ66、各種の時間カウントやビープ音を発生するタイマ68等から構成されている。なお、ISAバス42には、拡張ボードが実装可能なISAスロット62が接続されている。
複合I/Oポート54には、パラレル入出力,シリアル入出力の他、フロッピディスク装置82やCD−ROM装置83やハードディスク84を制御する信号を入出力するポートが用意されている。また、パラレル入出力には、パラレルポート86を介してプリンタ88が、シリアル入出力には、シリアルポート90を介してモデム92が、各々接続されている。また、サウンドI/O56には、上述したスピーカ74の他、マイクロフォン96が接続可能とされている。
このコンピュータ10のハードディスク84には、DOS(Disk Operating System )およびそのDOSに組み込まれる種々のデバイスドライバが記憶されており、コンピュータ10は、立ち上げ時にDOSを読み込み、更にDOSが参照するファイルの内容に従って、必要なデバイスドライバを組み込む。デバイスドライバとして、複合I/Oポート54を介してのプリンタ88への印字を可能にするプリンタドライバなどがある。
ハードディスク84には、「WINDOWS」というGUIを備えたオペレーティングシステムが記憶されており(「WINDOWS」はマイクロソフト社の商標)、コンピュータ10は、このオペレーティングシステムを読み込み、その後アプリケーションプログラムを、このオペレーティングシステム上で動作するようメインメモリ25上に読み込んで実行する。
1−2)本実施例の通信端末装置の構成
次に、図1に従って本実施例の通信端末装置について説明する。この通信端末装置は、上述したコンピュータ10において、そのハードウェアとソフトウェアが一体となって実現するものであり、図1は、ソフトウェアにより実現される部分も含めてブロック図として表わしたものである。
この通信端末装置は、アクセス管理部100を中心として、ユーザーI/F(インタフェース)部200と、通信制御部300と、データ管理部400と、通信I/F部500と、自動通信処理部600と、を備えている。
このうち、ユーザーI/F部200はキーボード72やマウス73を介して入力される利用者からの種々の指示をアクセス管理部100に伝えたり、アクセス管理部100から入力された各種のデータをモニタ76の画面上に表示したりする。また、利用者から後述する通信予約や定期巡回などの指示があった場合には、その指示された通信予約や定期巡回の内容を自動通信処理部600に送る。
アクセス管理部100は、ユーザーI/F部200を介して伝えられた利用者からの指示に従って、通信制御部300やデータ管理部400に種々の要求を出したり、通信制御部300を介して通信ホスト(図示せず)から送られてきたデータをデータ管理部400に渡したり、或いは、データ管理部400を介してハードディスク84内のデータベース410より読み出されたデータをユーザーI/F部200に出力したりする。
アクセス管理部100は、書き込み部100a,読み出し部100b,差分データ取得部100c,新着マーク付加部100d,新着マーク検索部100e,転送要求部100f,特定通信サービス開始要求部100g,特定通信サービス中止要求部100h及び本文情報転送要求部100iなどを備えている。
データ管理部400は、アクセス管理部100の書き込み部100aからの要求に従って、書き込み部100aから渡されたデータをデータベース410に書き込んだり、アクセス管理部100の読み出し部100bからの要求に従って、データベース410に記憶されているデータを読み出して読み出し部100bに渡したりする。なお、データベース410内にアクセス管理部100から要求されたデータがない場合には、アクセス管理部100に対しエラー信号を返す。また、必要に応じてデータベース410内のデータに対してソートや検索や削除などを行なう。ハードディスク84内のデータベース410は、データ管理部400によって管理されるローカルのデータベースであって、後述するように、通信ホストからの各種受信データが階層構造の下で通信ホストの提供する各種サービス毎に整理されて記憶されている。
通信制御部300は、アクセス管理部100の各要求部100f〜100iなどから、例えば「○○サービスの○○メニューの○○番タイトルを○○する」という要求が来た場合に、その要求を通信ホストの各サービス毎のメニュー番号やコマンドに翻訳して、通信I/F部500に送る。また、通信ホストから送信されてきたデータを通信I/F部500から受け取った場合は、そのデータから必要な部分を切り出して、アクセス管理部100が要求しているフォームに変換した上で、アクセス管理部100に渡す。通信I/F部500は、モデム92を介して通信回線の先につながった通信ホストとの間でデータの送受信を行なう。
自動通信処理部600は、ユーザーI/F部200から送られてきた通信予約や定期巡回の内容をハードディスク84内の予約ファイル610や巡回ファイル620に書き込んで保存する。そして、利用者からの自動通信開始指示やタイマによる自動通信起動指示があった場合に、予約ファイル610や巡回ファイル620に保存された内容に従って、通信ホストの間で自動通信を行なう。
自動通信処理部600は、整理部600aと転送部600bを備えている。
図1に示した各ブロックは、既述したように、ハードウェアにより実現されている部分とソフトウェアにより実現されている部分とを含む。例えば、ユーザーI/F部200は、ハードウェアとしては図2に示したキーボードインタフェース64やCRTC44が存在するが、現実には入力や表示を制御するソフトウェアがあって初めて動作する。従って、図1におけるユーザーI/F部200などは、両者を含めたものである。
なお、ソフトウェア部分については予めアプリケーションプログラムの形でハードディスク84に記憶されており、キーボード72やマウス73を使って利用者から起動の指示がなされて、上述のオペレーティングシステムによってハードディスク84からメインメモリ25上に読み込まれることによって、ハードウェアとソフトウェアが一体となった図1に示す通信端末装置が実現する。
また、上記アプリケーションプログラムが図2に示すCD−ROM85に記録されている場合には、このCD−ROM85をCD−ROM装置83に挿入し、上記アプリケーションプログラムをCD−ROM装置83で読み取ることによって、メインメモリ25に転送するようにしても良い。また、上記アプリケーションプログラムが図2に示すフロッピディスク81に記録されている場合には、このフロッピディスク81をフロッピディスク装置82に挿入し、上記アプリケーションプログラムをフロッピディスク装置82で読み取ることによって、メインメモリ25に転送するようにしても良い。また、上記アプリケーションプログラムは光磁気ディスクなどの他の携帯型記録媒体(可搬型記録媒体)上からメインメモリ25に転送するようにしても良い。
また、上記アプリケーションプログラムが図2に示すプログラム供給サーバ9000に格納されている場合には、モデム92によって通信回線93を介してプログラム供給サーバ9000にアクセスし、プログラム供給サーバ9000から上記アプリケーションプログラムを送信してもらうことによって、メインメモリ25に転送するようにしても良い。なお、通信回線93としては、電話回線やネットワーク回線などの有線回線の他、通信衛星などを利用した無線回線などが考えられる。
1−3)本実施例の通信端末装置の動作
次に、このようにして構成された本実施例の通信端末装置の動作について説明する。なお、以下の説明では、NIFTY-Serve(ニフティ株式会社運営)と呼ばれる大手のパソコン通信サービスを受ける場合を例として説明する。
本実施例の通信端末装置における通信の形態には手動通信と自動通信の2種類がある。手動通信の場合は、通信中に、利用者がキーボード72やマウス73を操作して直接指示を出すことにより、通信ホストに対して要求が出されるのに対し、自動通信の場合は、予め作成された予約ファイル610や巡回ファイル620の内容に従って、自動的に要求が出される。なお、通信ホストに対する要求は、各サービス毎のメニュー番号やコマンドとして通信ホストに送られる。
1−4)手動通信によるサービスの利用
例えば、手動通信の場合は、利用者がキーボード72,マウス73を操作して手動通信開始の指示を出すと、アクセス管理部100は、通信制御部300等を介して、通信ホストに電話をかけて、通信ホストとの接続を開始する。通信ホストとの間で回線がつながると、アクセス管理部100は、利用者識別番号やパスワードの送信など一連のログイン手続きを行なう。これにより、通信ホストから許可が得られると、通信ホストによる通信サービスの提供が開始される。このように、手動通信であっても、通信サービスの提供が開始されるまでの間は、通信端末装置が自動的に通信動作を行なう。
通信サービスの提供が開始されると、通信ホストから通信サービスのメニューが送信されてくる。アクセス管理部100は、送信されてきたメニューに基づいて、リストボックスやボタンなどのグラフィカルなユーザインタフェース、すなわち、マウスでも操作できるGUIメニュー画面を作成し、モニタ76上に表示する。そして、このGUIメニュー画面内にあるボタン等が利用者によって適宜選択されると、アクセス管理部100は、さらにその下の階層のGUIメニュー画面をモニタ76上に表示する。
また、利用者によってサービス切替画面表示の指示が出されると、アクセス管理部100は、図3に示すようなサービス切替画面を作成してモニタ76上に表示する。このサービス切替画面は、利用者が指示すればいつでも表示される。これはショートカットが可能である。すなわち、階層メニューをたどることなく、直接、所望のサービスへ移動できる。
サービス切替画面を表示する際、アクセス管理部100は、データベース410内に記憶されているサービスリストファイルや各サービスに対応して作成されているディレクトリなどを参照して、通信ホストによって提供される主なサービスのリストSLを、サービス切替画面の左側に表示する。なお、ここで言うサービス(狭義のサービス)とは、例えば、「GO」コマンドを使って直接そのサービスに移動することができるサービスを言う。
なお、利用者よりサービス切替画面表示の指示が取り消された場合には、アクセス管理部100は、通信ホストから送信されてきたメニューに基づいてGUIメニュー画面を作成し、モニタ76上に表示する状態(モード)に戻る。
さて、サービス切替画面が表示されているときに、利用者が、キーボード72,マウス73を使って、このサービスリストSLの中で自分の求めるサービス(狭義のサービス)を指示すると、アクセス管理部100は、指示されたサービスが通信ホストから受けられるように、通信制御部300等を介して通信ホストに対し、そのサービスに移動するための「GO」コマンドを送信する。例えば、「AISOFT Application Station」フォーラムというサービスが指示された場合は、そのサービスに移動するために、「GO SAISAP」というコマンドを送信する。これにより、通信ホスト側では、提供するサービスを指示されたサービス(この例では、「AISOFT Application Station」フォーラム)に移行する。こうして、利用者は指示したサービスを受けることができる。
なお、このように、通信ホスト側で提供するサービスが移行して、利用者が指示したサービスを受けられる状態になったことを、以下、「サービスに入った」と表現する場合がある。
また、アクセス管理部100は、上記した通信ホストに対するサービス提供要求と並行して、さらに、次のような処理を行なう。即ち、指示されたサービスに対応するフォルダ一覧索引ファイルを、データ管理部400によってデータベース410内より読み出して、そのフォルダ一覧索引ファイルに基づいて、指示されたサービス内にある各フォルダのリストFLを作成して、サービス切替画面の右側に表示する。例えば、上記したように「AISOFT Application Station」フォーラムというサービスが指示された場合は、図3に示すように、サービス切替画面の右側に「AISOFT Application Station」フォーラム内にある各フォルダのリストFLを表示する。
このように、利用者から所望のサービスが指示されると、アクセス管理部100は、そのサービスの提供を通信ホストに対し要求すると共に、そのサービスに対応したフォルダ一覧ファイルをデータベース410から読み出し、そのファイルに基づいてそのサービス内にある各フォルダのリストFLをモニタ76上に表示する。
ここで、フォルダとは、例えば、一つのサービス(狭義のサービス)内でさらに細分化された各サービス形態を言う。例えば、前述した「AISOFT Application Station」フォーラムというサービスでは、掲示板(フォーラム内の掲示板),お知らせ(フォーラム内のお知らせ),ライブラリ,電子会議などが提供されている。このうち、ライブラリには複数のライブラリ室が、電子会議には複数の会議室が存在する。これらのうち、フォルダとは、掲示板,お知らせ,ライブラリ内の各ライブラリ室,電子会議内の各会議室をそれぞれ指す。
次に、各種データが記憶されているデータベース410内の構造について説明する。図4は図1のデータベース410内の構造を示す説明図である。データベース410は図4に示すように階層構造となっており、各データファイルをいくつかのディレクトリに分けて格納し、そのディレクトリに上下の階層を設定して管理している。
最上階層のディレクトリはNIFTY-Serveに関する通信データを集めたディレクトリと言うことで「nifdata」となっており、その下の階層にはNIFTY-Serveが提供する各種サービスに対応したディレクトリ(掲示板,課金情報,クリッピングサービス,フォーラム,電子メール,ニュース,天気予報及び今週のお知らせの各ディレクトリ)が設けられている。この階層にあるディレクトリは通信ホストに初めてアクセスした際に、データ管理部400によって自動的に作成される。
これらディレクトリのうち、フォーラム(SIG;Special Interest Group)のディレクトリである「forum」を開くと、その下の階層として各フォーラムのディレクトリが現れる。一つのフォーラムに対して3つのディレクトリ(「*」,「*.lib」,「*.mes」)がそれぞれ設けられている。例えば、前述の「AISOFT Application Station」フォーラムの場合は、「saisap」,「saisap.lib」,「saisap.mes」の3つのディレクトリが設けられる。これら各フォーラムのディレクトリは、通信ホストに初めてアクセスした際に、通信ホストから既に利用者が入会しているフォーラムの一覧情報を送信してもらい、その一覧情報に基づいて作成される。
さて、「AISOFT Application Station」フォーラムに対する3つのディレクトリ「saisap」,「saisap.lib」,「saisap.mes」のうち、「saisap」のディレクトリ内には、フォーラム−掲示板の索引ファイル「fbbsfldr.idx」及びフォーラム−お知らせの索引ファイル「fnewfldr.idx」が格納されている。また、「saisap.lib」のディレクトリはフォーラム−ライブラリ専用のディレクトリであって、その中には、ライブラリ一覧の索引ファイル(フォルダ一覧索引ファイル)「libfldr.idx」が格納されている。さらに、「saisap.mes」のディレクトリはフォーラム−会議室専用のディレクトリであって、その中には、会議室一覧の索引ファイル(フォルダ一覧索引ファイル)「mesfldr.idx」が格納されている。
なお、図3のサービス切替画面の右側に示したように、サービス(この場合、フォーラム)内にある各フォルダのリストFLをモニタ76上に表示する際には、これらフォルダ一覧索引ファイル「*fldr.idx」に基づいて各フォルダのリストFLを作成して表示する。
これらフォーラムのフォルダ一覧索引ファイルは、そのフォーラムに初めて入った際に、通信ホストからそのフォーラム内にあるフォルダの一覧情報を送信してもらい、その一覧情報に基づいて作成される。
図5は会議室一覧の索引ファイル(フォルダ一覧索引ファイル)の内容の一例を示す説明図である。即ち、図5は図4に示す会議室一覧の索引ファイル「mesfldr.idx」の内容を示している。
図5に示すように、会議室一覧の索引ファイル(フォルダ一覧索引ファイル)には、会議室名、各会議室に登録されているタイトル数、利用者がその会議室を前回巡回した日付、フォルダ名、新着マークの有無などが含まれている。なお、フォーラム−掲示板の索引ファイル,フォーラム−お知らせの索引ファイル,ライブラリ一覧の索引ファイルなどの他のフォルダ一覧索引ファイルについてもほぼ同様な構成となっている。
ところで、前述したフォーラム−ライブラリ専用のディレクトリ「saisap.lib」には、さらに、ライブラリ室毎に索引ファイル「lib*.idx」とデータファイル「lib*.dat」が2つずつ格納されており、フォーラム−会議室専用のディレクトリ「saisap.mes」にも、会議室毎に索引ファイル「mes*.idx」とデータファイル「mes*.dat」が2つずつ格納されている。
このうち、索引ファイル「lib*.idx」,「mes*.idx」には、ライブラリ室,会議室(即ち、フォルダ)内に登録されているタイトルのデータが主として書き込まれる。これら索引ファイル「lib*.idx」,「mes*.idx」は、そのフォーラムに初めて入った際に、通信ホストから送信されてくるフォルダの一覧情報に基づいて作成される。但し、フォーラム内に入っても実際に会議室やライブラリ室内に入らない限り、索引ファイルのサイズは0のままである。
また、データファイル「lib*.dat」,「mes*.dat」には、ライブラリ室,会議室(即ち、フォルダ)内に登録されている本文のデータが主として書き込まれる。なお、データファイル「lib*.dat」,「mes*.dat」については、フォーラム内に入っただけでは作成されず、会議室やライブラリ室内に初めて入ったときに作成される。
そこで、図3に示したように、サービス切替画面で右側に各フォルダのリストFLが表示されているときに、利用者が、キーボード72,マウス73を使って、このフォルダリストFLの中で自分の求めるフォルダを指示すると、アクセス管理部100は、指示されたフォルダについてのサービスが通信ホストから受けられるように、通信制御部300等を介して通信ホストに対し、そのフォルダに移動するためのメニュー番号を送信する。これにより、通信ホスト側では、提供するサービスを指示されたフォルダに移行する。
こうして、利用者の指示したフォルダに入ると、アクセス管理部100は、後述するようなタイトル更新処理として、通信ホストにおける利用者の指示したフォルダから未読のタイトルデータを取得し、データベース410内における該当するフォルダの索引ファイルに対してタイトルデータの更新を行なった後、その索引ファイルより読み出されるタイトルデータに基づいて、モニタ76上にフォルダ画面として、そのフォルダ内の各タイトルを表示する。
図6は図1のモニタ76上に表示されるフォルダ画面の一例を示す説明図である。図6では「AISOFT Application Station」フォーラム内の会議室18番である「EasyConnection」会議室が、求めるフォルダとして指示された場合を示している。このフォルダ画面では、上側部分にフォルダ内の各タイトルが表示されている。このタイトルリストTLは、該当する会議室(この場合、会議室18番)の索引ファイル「mes*.idx」(この場合、索引ファイル「mes18.idx」)に基づいて作成され表示される。なお、この時、この索引ファイルは、その会議室に入った(会議室に移行した)直後に行なわれたタイトル更新処理によって、既に更新されている。
図7は会議室の索引ファイルの内容の一例を示す説明図である。図7では前述した「AISOFT Application Station」フォーラム内の会議室18の索引ファイル「mes18.idx」の内容を示している。
図7に示すように、会議室の索引ファイル「mes*.idx」は、タイトルが通信ホスト内に登録された日付、タイトル名、そのタイトルに対応した発言本文のデータファイル内での位置(オフセットで示されている)、新着マークの有無などが含まれている。なお、ライブラリ室の索引ファイル「lib*.idx」以外の他の索引ファイルについてもほぼ同様な構成になっている。図6の上側に示したタイトルリストTLは、図7に示す索引ファイル「mes18.idx」に基づいて作成され表示されている。
なお、図6において、タイトルリストTL中のいくつかのタイトルには*印が付されているが、これは、そのタイトルについて本文データがデータベース410内のデータファイルに記憶されており、本文の表示が可能であることを示している。従って、逆に、*印の付されていないタイトルについては、本文データがデータファイル記憶されていないことを示している。このような表示をすることによって、利用者は、どのタイトルについて本文を読むことができるかを容易に判断することができる。
よって、このようなタイトルリストTLが表示されているときに、利用者が、キーボード72,マウス73を使って、このタイトルリストTLの中で、発言本文を読みたいタイトルとして*印の付されたタイトルを指示すると、アクセス管理部100は、データ管理部400にそのタイトルに対応した本文データの読み出しを要求する。これにより、データ管理部400は、データベース410内の当該会議室のデータファイル「mes*.dat」を検索し、該当する本文データを読み出してアクセス管理部100に渡す。アクセス管理部100は、その渡された本文データにユーザーI/F部200に送る。ユーザーI/F部200ではその本文データに基づいてモニタ76上に発言本文を表示する。この結果、指示された発言本文が図6に示すようにフォルダ画面の下側に表示される。図6では「RE:自動通信への要望」というタイトルが指示された場合を示している。
即ち、当該会議室として、前述したように「AISOFT Application Station」フォーラム内の会議室18番が選択されている場合、その会議室のデータファイルは図4に示すように「mes18.dat」である。また、図7に示したように、「RE:自動通信への要望」というタイトルに対応した本文データの位置は「1024」である。従って、図6の下側に示した発言本文は、データファイル「mes18.dat」内の「1024」の位置に存在する本文データに基づいて表示される。
一方、タイトルリストTLの中で、発言本文を読みたいタイトルとして*印の付されていないタイトルを指示すると、当該会議室のデータファイル「mes*.dat」には該当する本文データが記憶されていないので、データ管理部400は、アクセス管理部100にエラー信号を返す。これにより、アクセス管理部100の転送要求部100fは、通信制御部300に対して、指示されたタイトルに対応した本文データの取得を要求する。通信制御部300は、通信I/F部500を介して通信ホストの間で通信を行なって、通信ホストに対して上記本文データの送信を要求する。こうして、通信ホストから上記本文データが送信されてきたら、通信制御部300は通信I/F部500を介してこれを受信し、アクセス管理部100に出力する。アクセス管理部100は、取得した本文データをデータ管理部400に渡して、データベース410への書き込みを要求する。データ管理部400は、渡された本文データをデータベース410内の当該会議室のデータファイル「mes*.dat」に書き込む。そして、アクセス管理部100は、再度、データ管理部400に対し、指示されたタイトルに対応した本文データの読み出しを要求する。今度は、当該会議室のデータファイル「mes*.dat」に該当する本文データが記憶されているので、データ管理部400は、その本文データを読み出し、アクセス管理部100に渡す。これによって、最終的には、指示されたタイトルに対応した発言本文がモニタ76上に表示される。
なお、データファイル「mes*.dat」に該当する本文データが記憶されていない場合に、その本文データの送信を通信ホストに対し要求するか否かについては、利用者が自由に選択できるようにしても良い。
以上のように、本実施例においては、通信ホストにアクセスすることによって、データベース410内に、通信ホストにおけるサービスやフォルダ毎に、自動的にディレクトリが作成される。また、通信ホスト内のサービスやフォルダに入ることによって、タイトルデータを格納する索引ファイルや本文データを格納するデータファイルが自動的に作成される。そして、その後は、通信ホストとの間でデータ通信を行なう度に、タイトルデータや本文データなどの受信データはサービス毎、フォルダ毎に自動的に分類、整理されて、対応するディレクトリ、さらにはファイルに書き込まれる。従って、利用者は、データベース410内に自らディレクトリ構造を構築したり、受信データを対応するディレクトリに格納したりする手間が省ける。また、受信データも整理されて記憶されるため、利用者による受信データの活用も容易となる。
1−4−1)タイトル更新処理
次に、本実施例の一つ目の特徴であるタイトル更新処理について説明する。このタイトル更新処理は受けるサービスの種類毎によって異なる。
図8及び図9は会議室に移行した直後に行なわれるタイトル更新処理の流れを示すフローチャートである。このうち、図8は初めてその会議室に入ったときの処理の流れを示し、図9は2回目以降に入ったときの処理の流れを示している。
会議室に初めて入る場合、前述したように、その会議室についての索引ファイルは既に作成されているが、データファイルについてはまだ作成されていない。そこで、図8に示すように、その会議室に初めて入った直後には、まず、その会議室についてのデータファイルを新規に作成する(ステップS20)。即ち、アクセス管理部100はデータ管理部400によってデータベース410内に会議室のデータファイル「mes*.dat」を作成させる。
次に、未読分のタイトルをすべて読むコマンドを送信する(ステップS22)。即ち、アクセス管理部100は、通信制御部300を介して通信ホストに対して、発言されたタイトルのうちの未読分のタイトルだけを読み込むコマンドを送信する。通信ホストでは、各会議室毎に、未読分のタイトルの番号(未読番号)をそれぞれ記憶し管理しているので、上記コマンド受け取ると、未読番号に対応するタイトルを全て利用者に対して送信する。こうして、通信ホストからは未読分のタイトルのデータが送信されてくる。続いて、送信されてきたそのデータを受信し(ステップS24)、その受信データから、タイトル毎に切り出し、タイトルデータを取得する(ステップS26)。そして、その会議室についての索引ファイルに、タイトルデータを書き込む(ステップS28)。即ち、通信制御部300は通信I/F部500から受信データを受け取ると、その受信データからタイトル毎に切り出して、タイトルデータを取り出し、アクセス管理部100に渡す。アクセス管理部100は、データ管理部400を介して、そのタイトルデータをデータベース410内の索引ファイル「mes*.idx」に書き込む。こうして、一連のタイトル更新処理が終了する。
次に、2回目以降にその会議室に入った場合は、まず、未読分のタイトルをすべて読むコマンドを送信する(ステップS30)。通信ホストでは、既に送信したタイトルは既読のタイトルとして扱うので、上記コマンドを受け取った場合、前回の通信以降に新たに登録された未読のタイトルを利用者に対して送信する。次に、送信されてきたそのデータを受信し(ステップS32)、その受信データから、タイトル毎に切り出し、タイトルデータを取得する(ステップS34)。そして、その会議室についての索引ファイルに、取得したタイトルデータを既存のタイトルデータに続けて書き込む(ステップS36)。こうして、一連のタイトル更新処理が終了する。
このように、会議室についてのタイトル更新処理においては、通信ホストによって、既に送信されたタイトルは全て既読扱いとなり、未読タイトルを読むコマンドによっては再度送信されてこないので、データベース410内の索引ファイルに同一のタイトルデータを重複して書き込むことがない。しかも、送られてきたタイトルデータを、索引ファイル内で既存のタイトルデータに続けて書き込むだけで、最新のタイトルデータを既存のタイトルデータにシームレスに連結することができる。
図10はこのような会議室についてのタイトル更新処理を具体的に説明するための説明図である。例えば、3月2日の9時00分に或る会議室に初めて入ったものとする。この場合、通信ホスト側では全てのタイトル番号を未読番号として記憶しているので、上述したように、未読分のタイトルを全て読むコマンドを通信ホストに送信すると、図10(a)に示すように、その会議室に登録されている全てのタイトルのデータが通信ホストから送られてきて、その会議室の索引ファイルに書き込むことになる。なお、通信ホストでは、最新のタイトルが最終番号となるようにタイトル番号を管理すると共に、各タイトルをタイトル番号の小さいものから順番に配置している。
続いて、同日の10時00分に同じ会議室に入る。この場合、通信ホスト側では、既に送信したタイトルは既読として扱っているため、前回の通信時刻(9時00分)以降に新たに登録されたタイトル番号のみが未読番号として記憶されている。従って、未読分のタイトルを全て読むコマンドを通信ホストに送信すると、図10(b)に示すように、9時00分以降に新たに登録されたタイトルのデータだけが通信ホストから送られてきて、索引ファイルに書き込むことになる。この時、前回の通信で記憶されたタイトルデータに続けて今回送られてきたタイトルデータを書き込むだけで、索引ファイル内では、前回の通信で記憶された最新タイトルである「553」番のタイトルデータに続いて、今回の送信されてきた「554」番以降のタイトルデータがシームレスに連結される。
図11及び図12はライブラリ室に移行した直後に行なわれるタイトル更新処理の流れを示すフローチャートである。このうち、図11は初めてそのライブラリ室に入ったときの処理の流れを示し、図12は2回目以降に入ったときの処理の流れを示している。
ライブラリ室に初めて入る場合も、会議室の場合と同様に、そのライブラリ室についての索引ファイルは既に作成されているが、データファイルについてはまだ作成されていない。そこで、図11に示すように、ライブラリ室に初めて入った直後には、アクセス管理部100はそのライブラリ室のデータファイルを新規に作成する(ステップS38)。
次に、アクセス管理部100は、一度に読む件数を設定して(ステップS40)、その設定件数だけタイトルを読むコマンドを通信ホストに対し送信する(ステップS42)。初めてライブラリ室に入った場合であり、そのライブラリ室に登録されている全てのタイトルを取得する必要があるため、一度に読む件数は100件などなるべく大きな値に設定する。通信ホストでは、上記コマンド受け取ると、設定件数分のタイトルを利用者に対して送信するので、その送信されてきたデータを受信する(ステップS44)。なお、ライブラリの場合、通信ホストでは、最新のタイトルが最終番号となるようにタイトル番号を管理しており、各タイトルをタイトル番号の大きいもの(即ち、新しいタイトルのもの)から順番に配置している。そこで、次に、そのライブラリ室に登録されているタイトルのうち、最も古いタイトルのデータを受信したか否かを判定し(ステップS46)、未だ受信していなければ、ステップS42に戻って、再度コマンドを送信して、次の設定件数分のタイトルのデータの送信を要求する。最古タイトルのデータを受信したか否かは、送信されてきたデータが途中で尽きて設定件数分に満たなかったり、或いは、上記コマンドを送信してもデータが送られてこなかったりすることによって、判定することができる。
最古タイトルのデータを受信した場合は、それまでに受信したデータから、タイトル毎に切り出して、タイトルデータを取得する(ステップS48)。そして、そのライブラリ室についての索引ファイルに、タイトルデータを書き込む(ステップS50)。こうして、一連のタイトル更新処理が終了する。
次に、2回目以降にそのライブラリ室に入った場合は、図12に示すように、まず、アクセス管理部100は、そのライブラリ室の索引ファイル内の既存のタイトルデータから、最新のタイトルの登録日付を求める(ステップS52)。即ち、前回、索引ファイルに書き込んだ全てのタイトルデータの中から、最新の登録日付を見つけだす。そして、アクセス管理部100は、その登録日付以降のタイトルを読むコマンドを通信ホストに対して送信する(ステップS54)。
ライブラリについては、会議室の場合のように、通信ホストによって未読番号の記憶や管理が行なわれていないので、通信ホストから未読のタイトルのみを送ってもらうことはできない。しかし、登録日付を指定しさえすれば、その日付以降のタイトルを送信してもらうことは可能である。そこで、この場合、登録日付として、前回における最新の登録日付を指定する。
通信ホストでは、上記コマンドを受け取ると、指定された登録日付以降のタイトルのデータを送信するので、その送信されてきたデータを受信し(ステップS56)、その受信データから、タイトル毎に切り出して、タイトルデータを取得する(ステップS58)。こうして、前回における最新の登録日付以降のタイトルデータを取得することによって、前回の通信から今回の通信までの間に新たに通信ホストにおいて登録されたタイトルデータを取得することができる。
しかし、今回取得したタイトルデータは前回における最新の登録日付以降のタイトルデータであるため、前回既に取得した、最新の登録日付当日のタイトルデータも含んでおり、そのまま、索引ファイルに書き込むと、重複してタイトルデータを記憶することになる。
そこで、次に、アクセス管理部100の差分データ取得部100cは、今回取得したタイトルデータから、そのライブラリ室の索引ファイル内にある既存のタイトルデータと重複するデータを削除した上で(ステップS60)、書き込み部100aがその索引ファイルに取得したタイトルデータを書き込む(ステップS62)。こうすることによって、前回の通信から今回の通信までに登録されたタイトルデータのみを索引ファイルに書き込むことができる。こうして、一連のタイトル更新処理が終了する。
このように、ライブラリ室についてのタイトル更新処理においては、通信ホストから前回における最新の登録日付以降のタイトルデータを送ってもらい、それらタイトルデータから、既に記憶済みの最新の登録日付当日のタイトルデータを削除した上で、索引ファイルに書き込んでいるので、会議室の場合と同様に、データベース410内の索引ファイルに同一のタイトルデータを重複して書き込むことがなく、しかも、索引ファイル内で、送られてきた最新のタイトルデータを既存のタイトルデータにシームレスに連結することができる。
図13はこのようなライブラリ室についてのタイトル更新処理を具体的に説明するための説明図である。例えば、1月中旬に或るライブラリ室に初めて入ったものとする。この場合は、通信ホストに対して、そのライブラリ室に登録されているタイトルのデータを所定の件数ずつ全て送信するように要求する。そして、この要求に従って送られてきた図13(a)に示すようなタイトルのデータを受信して、そのライブラリ室の索引ファイルに書き込む。
この時に取得したタイトルデータの中で、最新タイトルの登録日付はタイトル番号「56」番の1995年12月14日となっている。なお、ライブラリの場合、通信ホストでは、前述したように、最新のタイトルが最終番号となるようにタイトル番号を管理すると共に、各タイトルはタイトル番号の大きいものから順番に配置している。また、通信ホストにおいて、ライブラリのデータは削除される場合があるが、この場合はタイトル番号が欠番となるだけで、以降のタイトル番号がずれることはない。
続いて、2月中旬に同じライブラリ室に入る。この場合、通信ホストに対して、前回における最新タイトルの登録日付(1995年12月14日)以降のタイトルのデータを全て送信するように要求する。この要求に従って、通信ホストからは図13(b)に示すような1995年12月14日以降のタイトルのデータが送られてくる。このタイトルデータを見ると、前回の最新タイトルである「56」番のタイトルデータは通信ホストにおいて削除されていなかったことがわかる。
しかし、このタイトルデータは前回において既に索引ファイルに書き込まれているので、このタイトルデータをそのまま索引ファイルに書き込んでしまうと、データが重複してしまう。そのため、「56」番のタイトルデータだけは書き込みデータから削除する。従って、索引ファイルには、「57」番以降のタイトルデータを書き込むことになる。
この結果、索引ファイル内では、前回の通信で記憶された最新タイトルである「56」番のタイトルデータに続いて、今回の送信されてきた「57」番以降のタイトルデータがシームレスに連結される。
図14及び図15はニュースのサービスに移行した直後に行なわれるタイトル更新処理の流れを示すフローチャートである。このうち、図14は初めてそのニュースのサービスに入ったときの処理の流れを示し、図15は2回目以降に入ったときの処理の流れを示している。
なお、ニュースのサービスに初めて入った場合の処理内容は、図11に示したライブラリの場合と同様であるので、説明は省略する。
ニュースの場合も、ライブラリの場合と同様に、通信ホストによって未読番号の記憶や管理が行なわれていないので、通信ホストから未読のタイトルのみを送ってもらうことはできない。また、ニュースの場合は、通信ホストにおける登録データの更新が激しく、一日の間に登録されるデータの数も膨大であるので、ライブラリの場合のように、登録日付を用いて、前回の通信から今回の通信までの間に新たに登録されたタイトルデータを取得することは困難である。そこで、ニュースの場合は、以下のようにしてタイトル更新処理を行なう。
即ち、2回目以降にそのニュースのサービスに入った場合は、図15に示すように、まず、一度に読む件数を設定して(ステップS78)、その設定件数だけタイトルを読むコマンドを通信ホストに対し送信する(ステップS80)。
なお、初めてニュースのサービスに入った場合は、全てのタイトルのデータを取得する必要があるため、前述したように設定件数を100件などの大きな値に設定するが、2回目以降の場合は、設定件数を余り大きな値に設定すると、オーバーランによって、既に取得したタイトルのデータを再度受信してしまい、無駄となるので、10〜20件などの比較的小さい値に設定する。但し、前回の通信からかなり日時が経っている場合には、それに応じて設定件数を大きな値(例えば、100件など)に増やしても良い。
通信ホストでは、上記コマンド受け取ると、設定件数分のタイトルを利用者に対して送信するので、その送信されてきたデータを受信する(ステップS82)。
次に、アクセス管理部100は、受信したタイトルのデータと索引ファイル内の既存のタイトルデータとを比較して(ステップS84)、受信したタイトル及びその提供日時が、索引ファイル内の最新タイトル及びその提供日時と一致するか否かを判定する(ステップS86)。
前述したように、ニュースの場合は、一日の間に登録されるデータの数が膨大であるため、受信したタイトルが前回における最新のタイトルと同じであるかどうかを、登録日付を用いて判定することは困難である。
また、ニュースの場合、通信ホストでは、最新のタイトルが常に「1」番となるようにタイトルを管理しているため、新たなタイトルが登録される度に以下の番号は「1」ずつ増加する。そして、各タイトルをタイトル番号の小さいもの(即ち、最新のもの)から順番に配置している。従って、受信したタイトルが前回における最新のタイトルと同じであるかどうかを、タイトル番号によって判定することも不可能である。
そこで、本実施例では、タイトル自体とそのタイトルのニュースが通信ホストに登録された日時(提供日時)とによって判定するようにしている。ニュースの場合、通信ホストでは、データの登録を日付だけでなく時刻まで管理しているので、例え、同日に多数のデータが登録されていたとしても、登録された時刻まで比較するようにすれば、ある程度まで判定することは可能である。但し、同日の同時刻に複数のデータが登録される場合もある得るので、その場合には、タイトルの違いによって判定するようにする。タイトル自体については、ニュースの場合、タイトルが変更されることはなく、同じタイトルが付されることも希であるので、十分判定できる。
なお、ニュースの場合、通信ホストに登録されているデータは、古いものから順番に削除されるが、その順番を超えて途中のデータが削除されることはない。
さて、判定の結果、タイトル及び日時が一致する場合は、ステップS90に進んで、受信データからタイトル毎に切り出して、タイトルデータを取得する。このように、前回における最新のタイトルと同じタイトルのデータを受信したことを確認した上で、それまでに受信してきたタイトルデータを全て取得することによって、前回の通信から今回の通信までの間に新たに通信ホストにおいて登録されたタイトルデータも取得することができる。
但し、今回取得したタイトルデータのうち、前回における最新のタイトルデータと一致するタイトルデータ、及びその提供日時より過去のタイトルデータについては、前回既に索引ファイルに書き込んであるので、そのまま、索引ファイルに書き込んでしまうと、重複してタイトルデータを記憶することになる。そこで、次に、差分データ取得部100cが、今回取得したタイトルデータから、その索引ファイル内にある既存のタイトルデータと重複するデータを削除した上で(ステップS92)、書き込み部100aがその索引ファイルに取得したタイトルデータを書き込む(ステップS96)。こうすることによって、前回の通信から今回の通信までに登録されたタイトルデータのみを索引ファイルに書き込むことができる。
一方、ステップS86による判定の結果、タイトル及び日時が一致しない場合は、ステップS88に進んで、ニュースとして登録されているタイトルのうち、最も古いタイトルのデータを受信したか否かを判定する。そして、最古タイトルのデータを未だ受信していなければ、ステップS80に戻って、再度コマンドを送信して、次の設定件数分のタイトルデータの送信を要求する。
索引ファイル内の最新タイトル及び提供日時と一致しないにも関わらず、最古タイトルのデータを受信した場合には、それまでに受信したデータから、タイトル毎に切り出し、タイトルデータを取得する(ステップS94)。このように、索引ファイル内の最新タイトル及び提供日時と一致しないにも関わらず、最古タイトルのデータを受信したということは、当該ニュースのサービスについて通信ホストに登録されている全てのタイトルのデータを受信したにも関わらず、その受信したタイトルデータの中に、前回受信したタイトルデータと一致するものが一つもないことを意味する。即ち、これは、前回の通信時から今回の通信時までの間に、通信ホストにおいて、前回における最新タイトルも含めて古いタイトルが全て削除された場合(中抜け状態)である。
そこで、このような中抜け状態の場合には、最古タイトルのデータまでを受信して、通信ホストに現在登録されている全てのタイトルのデータを取得するようにする。なお、ニュースや掲示板のような登録データの更新が激しいサービスにおいては、数日間空けて入ると、中抜け状態になってしまうことが多々ある。
このような中抜け状態の場合には、取得したタイトルデータは、全て、前回の通信時から新たに登録されたデータであるので、索引ファイル内の既存のタイトルデータと重複することはない。従って、取得したタイトルデータを全て索引ファイルに書き込む(ステップS96)。こうして、一連のタイトル更新処理が終了する。
このように、ニュースのサービスについてのタイトル更新処理においては、通信ホストから所定の件数ずつ前回における最新タイトルと一致するまでタイトルデータを送ってもらい、それらタイトルデータから既存のタイトルデータを削除した上で、索引ファイルに書き込んでいるので、データベース410内の索引ファイルに同一のタイトルデータを重複して書き込むことがなく、しかも、索引ファイル内で、送られてきた最新のタイトルデータを既存のタイトルデータにシームレスに連結することができる。
図16はこのようなニュースのサービスについてのタイトル更新処理を具体的に説明するための説明図である。例えば、3月1日の9時00分に或るニュースのサービスに初めて入ったものとする。この場合は、通信ホストに対して、登録されているタイトルのデータを所定の件数ずつ全て送信するように要求する。そして、この要求に従って送られてきた図16(a)に示すようなタイトルのデータを受信して、そのニュースの索引ファイルに書き込む。この時に取得したタイトルデータの中で、最新タイトルは「A病院で患者10人が死亡」であり、その提供日時は3月1日8時53分となっている。
続いて、同日の9時30分に同じニュースのサービスに入ったものとする。この場合、通信ホストに対して、所定の件数、例えば6件ずつタイトルのデータを送信するように要求する。この要求に従って、通信ホストからは図16(b)に示すように、6件のタイトルのデータが送られてくる。
これらタイトルデータを見ると、前回における最新のタイトル及び提供日時が一致するのはタイトル番号「4」番のタイトルデータであり、その「4」番よりもタイトル番号が小さい3件のタイトルデータは前回の通信時(9時00分)から今回の通信時(9時30分)の間に新たに登録されたタイトルデータである。従って、この3件のタイトルデータが新たに登録されたことによって、前回の最新タイトルも、それ以降の2つのタイトルもタイトル番号が3つずつ増えている。
しかし、これら前回の最新タイトル以降のタイトルデータ(即ち、「4」〜「6」のタイトルデータ)は前回において既に索引ファイルに書き込まれているので、重複するデータとして書き込みデータからは削除する。従って、索引ファイルには、「1」〜「3」番のタイトルデータのみを書き込むことになる。この結果、索引ファイル内では、前回の通信で記憶された最新タイトルのデータに続いて、今回の送信されてきた「1」〜「3」番のタイトルデータがシームレスに連結される。
図17及び図18は掲示板のサービスに移行した直後に行なわれるタイトル更新処理の流れを示すフローチャートである。このうち、図17は初めてその掲示板のサービスに入ったときの処理の流れを示し、図18は2回目以降に入ったときの処理の流れを示している。
なお、掲示板のサービスに初めて入った場合の処理内容は、図11に示したライブラリや図14に示したニュースの場合と同様であるので、説明は省略する。
前述したように、ニュースの場合、通信ホストに登録されているデータは、古いデータから順番に削除される。掲示板の場合も、通信ホストに登録可能なデータの最大件数が512件に制限されているので、その件数を越えた古いデータからから順番に削除される。従って、何れの場合も、索引ファイルに記憶されているタイトルデータが、通信ホストにおいては、登録データから既に削除されている可能性がある。このようなとき、ニュースの場合は、タイトルデータをそのまま記憶しておいても、後ほど過去のニュース情報として再利用することは可能であるが、掲示板の場合は、タイトルデータをそのまま記憶しておいても、通信ホストにおいて登録データが削除されているのであれば、何ら利用価値はない。そこで、本実施例では、以下のようにしてタイトル更新処理を行なう。
即ち、2回目以降にそのニュースのサービスに入った場合は、図18に示すように、1回目の場合と同様に、通信ホストに登録されている全てのタイトルのデータを取得する(ステップS112〜ステップS120)。そして、全てのタイトルデータを取得したら、データベース410内の当該掲示板についての索引ファイルに、取得したタイトルデータを上書きで書き込む(ステップS122)。これによって、索引ファイル内のタイトルデータが、通信ホストから取得したタイトルデータに全て書き換えられる。こうして、一連のタイトル更新処理が終了する。
このように、掲示板についてのタイトル更新処理においては、毎回、通信ホストから登録されている全てのタイトルデータを送ってもらい、それらタイトルデータによって、データベース410内の索引ファイルに記憶されているタイトルデータを全て書き換える。従って、データベース410内の索引ファイルに同一のタイトルデータが重複して書き込むことがない。
ところで、以上説明した更新処理は、フォルダ内の各タイトルについての更新処理であった。しかし、サービス内の各フォルダについても、時折であるが、通信ホスト側で、追加されたり、変更されたり、或いは、削除されたりする場合がある。そこで、このような場合にも対応できるように、サービス内の各フォルダについても同様に更新処理を行なうようにしても良い。
即ち、利用者が、キーボード72,マウス73を使って、自分の求めるサービス(狭義のサービス)を指示すると、アクセス管理部100は、通信制御部300等を介して通信ホストに対し、そのサービスに移動するための「GO」コマンドを送信する。これにより、通信ホスト側では、提供するサービスを指示されたサービスに移行する。こうして、利用者の指示したサービスに入ると、アクセス管理部100は通信ホストに対してフォルダの一覧情報を送信を要求する。そして、通信制御部300等を介して通信ホストからの一覧情報を受け取ると、アクセス管理部100は、データ管理部400を介して、データベース410内にあるフォルダ一覧索引ファイルを読み出し、受け取った一覧情報と比較する。サービス内のフォルダに追加,変更,削除などがある場合には、受け取った一覧情報に基づいてフォルダ一覧索引ファイルを更新する。
その後、アクセス管理部100は、その更新したフォルダ一覧索引ファイルに基づいて、指示されたサービス内にある各フォルダのリストFLを作成して、モニタ76上に表示する。
以上のようにして、フォルダの更新処理を行なうことができる。
1−4−2)課金節約処理
ところで、通信ホストが提供する通信サービスのうち、前述したニュースなどは基本料金以外に追加料金がかかる有料サービスとなっている。このような有利サービスを受ける場合、一般には、その有料サービスを利用しているトータルの時間に対して課金されるため、その有料サービスに入っている時間(即ち、有料サービスを利用している時間)はできる限り短くなるようにした方が良い。しかし、このような有料サービスを手動通信によって受ける場合、利用者は操作や判断に多くの時間を要してしまい、サービスに入っている時間が長くなるため、費用がかさんでしまうという問題があった。
そこで、本実施例では、手動通信によって有料サービスを受ける場合には次のような課金節約処理を行なうようにしている。では、本実施例の二つ目の特徴である課金節約処理について説明する。
図19は有料サービスを受ける際に行なわれる課金節約処理の流れを示すフローチャートである。通信ホストの提供する通信サービス上において、利用者は、今、例えば、ニュースなどの有料サービスのサービストップメニューの位置にいるものとする。このサービストップメニューでは、その有料サービスの利用の仕方などが情報として利用者に提供されており、そのメニューの位置にいる限りは追加料金はかからない。
そこで、利用者がキーボード72,マウス73を使って、有料サービスに入る旨の指示を出すと、図19に示す処理ルーチンが開始され、アクセス管理部100の特定通信サービス開始要求部100gは、通信制御部300を介して通信ホストに対し、指示された有料サービスのメニュー番号を送信して、サービストップメニューから有料サービスに入る(ステップS132)。有料サービスに入ると、通信ホストでは利用時間のカウントが開始されて、その利用時間に応じた課金が行なわれる。
次に、アクセス管理部100は、前述したようなタイトル更新処理を行なって、索引ファイル内に記憶されている最新のタイトルデータと連結するか或いは通信ホスト内の登録されたデータが尽きるまで、その有料サービスについてのタイトルデータを取得して、データ管理部400を介してデータベース410内の索引ファイルに書き込む(ステップS134)。
その後、アクセス管理部100は、データベース410内の索引ファイルから取得したタイトルデータを読み出して、ユーザーI/F部200を介してモニタ76上のフォルダ画面に表示する(ステップS136)。これによって、モニタ76上には有料サービスのタイトルの一覧が表示される。
またこの時、同時に、アクセス管理部100の特定通信サービス中止要求部100hは、通信制御部300を介して通信ホストに対し、有料サービスの中止のコマンドを送信して、有料サービスから無料のサービストップメニューに退避する(ステップS138)。これにより、通信ホストでは利用時間のカウントが停止されて、利用時間に応じた課金も停止される。アクセス管理部100は、この状態で、利用者からの本文読み込みを求めるタイトルの指示があるまで、待機する(ステップS140)。従って、この間、利用者は追加料金がかからない状態で、モニタ76のフォルダ画面に表示されたタイトル一覧を見ながら、自分の求めるタイトルをゆっくり選択することができる。
次に、利用者がキーボード72,マウス73を使って、フォルダ画面の中から、本文読み込みを求めるタイトルを指示すると、アクセス管理部100の特定通信サービス開始要求部100gは、再度、通信制御部300を介して通信ホストに対し、有料サービスのメニュー番号を送信して、サービストップメニューから有料サービスに入る(ステップS142)。そして、有料サービスに入ると、通信ホストでは再び利用時間のカウントが開始されて、その利用時間に応じた課金が行なわれる。
続いて、アクセス管理部100は、再び、タイトル更新処理を行なって、最新のタイトルデータを取得し、データベース410内の索引ファイルに書き込む(ステップS134)。これによって、前回有料サービスに入ってから今回有料サービスに入るまでの間に、新たなタイトルが登録されたとしても、十分対処することができる。しかし、通常は有料サービスから退避した時間は短時間であるため、新たなタイトルが登録されることは少なく、タイトル更新処理も短時間で済む。
ところで、この有料サービスがニュースである場合、前述したように、通信ホストでは、最新のタイトルが常に「1」番となるようにタイトルを管理しており、新たなタイトルが登録された場合は、その度ごとに以下の番号が「1」ずつ増加する。従って、有料サービスから退避している間に、新たなタイトルが登録されたとすると、通信ホスト内におけるタイトルの番号は新たに登録されたタイトルの数だけ増加していることになる。従って、利用者によって指示されたタイトルの番号を、そのまま通信ホストに送信しても、利用者の求めるタイトルの本文データを取得することはできない。
そこで、アクセス管理部100の本文情報転送要求部100iは、利用者によって指示されたタイトルの番号に、タイトル更新処理によって新たに取得したタイトルの数(即ち、通信ホストに新たに登録されたタイトルの数)を加算した上で(ステップS146)、そのタイトル番号の、本文を読むコマンドを通信ホストに対して送信する(ステップS148)。これによって、通信ホストに対して、利用者が本来求めていたタイトルに対応する本文データの送信を正確に要求することができる。
こうして、通信ホストからは、利用者の求める本文データが送信されるので、アクセス管理部100は、通信制御部300を介してその本文データを取得して、データ管理部400を介してデータベース410内のデータファイに書き込む(ステップS150)。
その後、アクセス管理部100は、データベース410内のデータファイルから取得した本文データを読み出して、ユーザーI/F部200を介してモニタ76上のフォルダ画面に表示する(ステップS152)。これによって、モニタ76上には利用者の求めていたタイトルに対応する本文が表示される。
またこの時、同時に、通信制御部300を介して通信ホストに対して、有料サービスの中止のコマンドを送信して、有料サービスから無料のサービストップメニューに退避する(ステップS154)。これにより、通信ホストでは利用時間のカウントが停止されて、利用時間に応じた課金も停止される。こうして、一連の課金節約処理が終了する。
ところで、上記した説明では、有料サービスのトータルの利用時間に対して課金される場合を例として説明したが、その他にも、100円/分のように単位時間毎に一定の料金を課金し、且つ、有料サービスに入る度に新たに課金する場合がある。このような場合には、例えば、有料サービスに入ってからの時間が例えば1分を1秒でも超えれば、切り上げで2分として計算されるが、2分を超えない限りは、一定料金であるので、1分1秒でも1分59秒でも同一の料金で済む。従って、この例の場合は、1分59秒まで待ってから有料サービスより退避するようにする。このようにすることによって、アクセス管理部100は、本文読み込みの指示など次の動作に対する備えを十分にすることができる。
また、アクセス管理部100は、有料サービスに入ってからの経過時間を計って、ユーザーI/F部200を介してモニタ76上に表示するようにしても良い。また、追加料金の計算方法が予めわかっているなら、課金される料金を実際に計算してモニタ76上に表示するようにしても良い。このようにすることによって、利用者は有料サービスに入っている間の時間やかかった費用などを即座に知ることができる。
以上のように、図19に示した課金節約処理によって、手動通信によって有料サービスを受ける場合にも、有料サービスに入っている時間をできる限り短くすることが可能となる。しかも、有料サービスから退避する操作は、利用者に代わってアクセス管理部100が最適なタイミングで行なうので、利用者の負担が少なくて済む。但し、有料サービスからの退避の指示は、利用者が必要に応じて出せるようにしても、何ら支障はない。
1−4−3)オフラインでの動作
さて、以上は、手動通信によって通信ホストとデータ通信を行なっている間の動作、即ち、オンラインでの動作について説明したが、本実施例の通信端末装置では、通信ホストとデータ通信を行なっていない場合、即ち、オフラインの場合にも、オンラインの場合と同じような動作を行なうことができる。
つまり、本実施例では、データベース410内に通信ホストからの受信データを階層構造に従って整理して記憶しているので、これら記憶データを基にして、オンラインの場合と同様の動作を行なうことができる。
例えば、図3に示したようなサービス切替画面が表示されているときに、利用者が、キーボード72,マウス73を使って、このサービスリストSLの中で自分の求めるサービス(狭義のサービス)を指示すると、アクセス管理部100は、指示されたサービスに対応するフォルダ一覧ファイルを、データベース410内よりデータ管理部400によって読み出させ、そのフォルダ一覧ファイルに基づいて、指示されたサービス内にある各フォルダのリストFLを作成して表示する。
その後、フォルダリストFLが表示されているときに、利用者が、キーボード72,マウス73を使って、このフォルダリストFLの中で自分の求めるフォルダを指示すると、アクセス管理部100は、指示されたフォルダの索引ファイルを、データベース410内よりデータ管理部400によって読み出させ、その索引ファイルに基づいて、指示されたフォルダ内の各タイトルを図6に示したフォルダ画面に表示する。
さらに、タイトルリストTLが表示されているときに、利用者が、キーボード72,マウス73を使って、このタイトルリストTLの中で、本文を読みたいタイトルを指示すると、アクセス管理部100は、指示されたタイトルに対応する本文データが、データベース410内のデータファイルに記憶されていれば、データ管理部400にその本文データを読み出させ、そのデータに基づいて本文を図6に示したフォルダ画面に表示する。
このように、オフラインの場合にも、オンラインの場合と同じような動作を行なうことができる。従って、利用者は、通信ホストとの間でデータ通信を実際に行なっていなくても、通信ホストとデータ通信を行なっているときと同じような感覚で、受信データをモニタ76上に表示して、利用することができる。
なお、このようなオフラインの場合、利用者が本文の読み込みを指示したときに、データベース410内のデータファイルに該当する本文データが記憶されていなければ、モニタ76のフォルダ画面には利用者の求める本文は表示されない。従って、そのような場合には、後述するような通信予約によって対処することもできるが、次のように処理することも可能である。
即ち、アクセス管理部100の転送要求部100fは、データベース410内に求める本文データがないとして、データ管理部400からエラー信号を受けた場合には、直ちに、通信制御部300を介して、通信ホストに電話をかけて通信ホストとの接続を図り、通信ホストによる通信サービスの提供が開始されたら、通信ホストに対し、求める本文データの送信を要求するようにする。
これによって、通信ホストから求める本文データを取得して、データベース410内のデータファイルに書き込ませることができ、さらには、モニタ76上に本文を表示させることができる。
1−5)自動通信によるサービスの利用
さて、今までは、主に手動通信によって通信サービスを利用する場合について説明した。そこで、次に自動通信によって通信サービスを利用する場合について説明する。
本実施例では、自動通信の際に巡回する巡回先や巡回先での処理内容を予め設定する方法として、定期巡回指定によって設定する方法と、通信予約による設定する方法がある。このうち、定期巡回指定は、利用者が自分の求める特定のサービス(フォルダ)について定期的なデータの取得を希望する場合に用いられ、通信予約は、利用者が自分の興味を引いた個々のデータの取得を希望する場合に用いられる。
1−5−1)定期巡回指定
まず、定期巡回指定について説明する。図20は図1のモニタ76上に表示される定期巡回指定画面の一例を示す説明図である。定期巡回の指定を行なう際には、利用者が、キーボード72,マウス73を使って、定期巡回指定の指示を出すことより、モニタ76上には、例えば、図20に示すような画面が表示される。図20に示す画面は掲示板のサービスについての定期巡回指定画面である。
画面左側に表示されたフォルダリストFLBの中から、マウス73を使って、所望のフォルダ名を指示すると、そのフォルダに関して、種々の設定が可能な状態となる。そこで、画面右側にある「定期巡回する」の項目をチェックすると、上記フォルダが定期巡回の対象として登録される。続いて、「間隔:」の項目において、そのフォルダについて定期巡回を実行する時間間隔(巡回間隔)を日数にて指定し、その下の「読込方法」の項目で「タイトルのみ読む」か「本文も読む」かの指定を行なう。また、1回の巡回によってデータの読み込むべき件数を制限したい場合は、「件数で制限する」の項目をチェックして、その読み込むべきデータの件数を指定する。なお、この定期巡回指定画面では、読み込むべきデータを件数によって制限するようにしているが、登録日や提供日などの日付によって制限するようにしても良い。
このようにして、定期巡回を希望する各サービス(フォルダ)について、それぞれ、定期巡回指定を行なうことができる。定期巡回指定によって指定された内容は図1に示すハードディスク84内の巡回ファイル620に保存される。
図21は図1の巡回ファイル620に保存された指定内容の一例を示す説明図である。巡回ファイル620には、図21に示すように、各サービス毎に、定期巡回すべきフォルダ名の他、指定した読込方法(タイトルのみか本文も読むか)や巡回間隔(日数)、さらには読込制限条件(件数や日付)などが記憶される。なお、図21では、読込制限条件については記載を省略してある。また、定期巡回指定の場合、1つのフォルダに対しては一つの処理しか指定できないため、同一サービス名で同一フォルダ名のものが2つ以上保存されることはない。
こうして巡回ファイル620に保存された内容は、自動通信処理部600によって、直ちにソートして整理される。即ち、図21に示すように、サービス名順に並ぶようにソートして、同一サービス名がひとまとまりとなるようにしている。なお、後述するように、巡回ファイル620の記憶内容は、自動通信を行なう際に、予約ファイル610の記憶内容と共に、ソートして整理されるので、定期巡回指定時に必ずしもソートする必要はない。しかし、上記のように、巡回ファイル620には、同一サービス名で同一フォルダ名のものが2つ以上記憶されることはなく、しかも、定期巡回指定の場合、指定内容は固定的であるため、巡回ファイル620の記憶内容については定期巡回指定時にソートした方が、自動通信時に毎回ソートを行なう場合よりも、時間的な無駄が省けて良い。
次に、このような巡回ファイルに基づく自動通信の具体的な動作手順について説明する。図22及び図23は巡回ファイルに基づく自動通信の動作手順を示すフローチャートである。
自動通信は、利用者がキーボード72,マウス73を操作して自動通信開始の指示を出したとき、あるいは、予め自動通信開始時刻をタイマ68に設定しておき、タイマ68がその開始時刻になったことを検知したときに開始される。
自動通信の処理が開始されると、自動通信処理部600は、アクセス管理部100,通信制御部300等を介して、通信ホストに電話をかけて、通信ホストとの接続を図り、図22に示す処理ルーチンを開始する。まず、自動通信処理部600は、年月日や時刻を管理しているRTC52から今日の日付TDを取得する(ステップS156)。次に、ハードディスク84内から巡回ファイル620を読み出し、その巡回ファイル620から、巡回先となるサービス名及びフォルダ名を取得する(ステップS158)。続いて、上記サービス名及びフォルダ名が取得できたか否かを判定し(ステップS160)、取得できた場合には、ステップS162に進む。
ステップS162では、自動通信処理部600は、データベース410から、取得したサービス名に対応するフォルダ一覧索引ファイルを、データ管理部400を介してデータベース410内より読み出し、そのフォルダ一覧索引ファイル(図5参照)から、取得したフォルダ名について記憶されている前回巡回日BDを取得する。さらに、自動通信処理部600は、ステップS158で読み出した巡回ファイル620から、取得したびフォルダ名について記憶されている巡回間隔NDを取得し(ステップS164)、その巡回間隔NDが0日であるか否かの判定を行なう(ステップS166)。巡回間隔が0日であると言うことは、そのフォルダについては、自動通信を行なう度に毎回巡回を行うように設定していることを意味している。従って、巡回間隔が0日である場合には、そのフォルダについて巡回の処理を行うよう図23のステップS170に進む。
巡回間隔が0日でない場合には、上記フォルダについて、ステップS162で取得した前回巡回日BDにステップS164で取得した巡回間隔NDを加算して、それにより得られた日付(BD+ND)が今日の日付TDより後であるか、今日の日付TD以前であるかを判定する(ステップS168)。即ち、加算により得られた日付が今日の日付より後である場合には、前回の巡回日から今日までの間に未だ巡回間隔の日数が経過していないので、そのフォルダについては、今回の自動通信によって巡回する必要がない。そのため、巡回の処理は行なわずに、ステップS158に戻る。逆に、加算により得られた日付が今日の日付以前である場合には、前回の巡回日から今日までの間に巡回間隔の日数が既に経過しているので、そのフォルダについては、今回の自動通信によって巡回する必要があり、そのため、巡回の処理を行なうように、図23のステップS170に進む。
図23に示すように、ステップS170では、自動通信処理部600の転送部600bは、アクセス管理部100,通信制御部300等を介して、通信ホストに対し、巡回対象となったフォルダに移行するためのコマンドを送信する。即ち、まず、巡回対象であるフォルダの属するサービスに入るために、そのサービスに移行するためのコマンドを送信する。これによって、通信ホスト側では、提供するサービスを指定されたサービスに移行する。そのサービスに入ったら、巡回対象であるフォルダに入るために、そのフォルダに移行するためのメニュー番号を送信する。これによって、通信ホスト側では、提供するサービスを巡回対象であるフォルダにさらに移行する。
こうして、指示したフォルダに入ると、自動通信処理部600は、ステップS158で読み出した巡回ファイル620から、そのフォルダ名について記憶されている読込方法と読込制限条件を取得し(ステップS172)、その読込方法と読込制限条件に従って通信ホストに対してデータの送信要求を出す(ステップS174)。これによって、通信ホストから求めるデータが送信されてくると、自動通信処理部600は、そのデータを通信制御部300等を介して受信して、データ管理部400によってデータベース410に書き込む(ステップS176)。このようにして、自動通信処理部600は、通信ホストから一連のデータの読み込みを行なう。
例えば、読込方法としてタイトルのみの読み込みが指定されている場合には、通信ホストから読み込むデータはタイトルデータだけであるので、索引ファイルに書き込む。また、本文の読み込みが指定されている場合には、通信ホストから読み込むデータはタイトルデータと本文データであるので、タイトルデータについては索引ファイルに書き込み、本文データについてはデータファイルに書き込む。また、読込制限条件が指定されている場合には、その制限条件を満たすまで、通信ホストに登録されている未読のタイトル(またはタイトル及び本文)のデータを読み込む。なお、この時、読み込んだデータが索引ファイル(または索引ファイル及びデータファイル)に既に記憶されている最新データに連結するか、あるいは、通信ホストにおいて登録されているデータ(そのフォルダについて登録されているデータ)の全てを読み込んだ場合には、読み込みの処理を終了する。
次に、自動通信処理部600は、ステップS162で読み出したフォルダ一覧索引ファイルに、上記フォルダに対応する前回巡回日BDとして、新たに今日の日付TDを書き込む(ステップS178)。これによって、前回巡回日は更新される。
こうして、一つのフォルダについて巡回の処理が終了すると、ステップS158に戻って、巡回ファイル620から次の巡回先となるサービス名とフォルダ名を取得して、前回と同様な処理を繰り返す。
以上のようにして、巡回ファイル620に基づく自動通信が行なわれる。
1−5−2)通信予約
次に、通信予約について説明する。通信予約は、前述したようなオフラインの状態で、データベース410に記憶されているデータをモニタ76上に表示している際に、利用者が、その表示画面を見ながら、必要な時にその都度行なうようにする。例えば、利用者が、モニタ76上に表示されたタイトルの一覧の中に興味の引いたタイトルがあって、その本文を読もうとした時に、その本文のデータがデータベース410に記憶されていない場合に、その本文データの読み込みを通信予約する。また、利用者が、会議室における本文データを読んでいる際に、その本文に対し何らかのコメント文を書いて、通信ホスト上の上記会議室に発言したい場合に、そのコメント文のアップロードを通信予約する。
図24は図1のモニタ76上に表示されるコメント発言画面の一例を示す説明図である。即ち、例えば、図6に示したフォルダ画面上側のタイトル一覧において、利用者がマウス73を使って、一番下のタイトル「こんなやり方もありますよ」を指定し、画面内の「コメント」ボタンCBを押すと、図24に示すようなコメント発言画面に切り換わり、画面上側に上記タイトルについての本文が表示される。そこで、画面下側でその本文に対するコメント文を作成して、画面右上にある「発言予約」ボタンSBを押すと、その作成したコメント文が、予約情報と共に、ハードディスク84内の予約ファイル610に書き込まれ、図25に示すように予約が追加される。
図26は図1の予約ファイル610に保存された予約内容の一例を示す説明図である。予約ファイル610には、図26に示すように、予約された順番に各予約内容が記憶されている。各予約内容は、サービス名、フォルダ名及び予約事項などの予約情報の他、必要に応じて、該当するタイトル番号や上記したコメント文などの発言内容が記憶される。
このように、予約ファイル610には、利用者がオフライン状態であちらこちらのフォルダ等を見て回りながら予約した内容が、予約した順序で記憶されている。よって、図26に示すように、サービス名もフォルダ名もランダムな順序のままとなっている。なお、予約ファイル610については、巡回ファイル620のように、通信予約時に特に記憶内容のソートは行なわないが、ソートを行なうようにしても構わない。
次に、このような予約ファイルに基づく自動通信の動作について簡単に説明する。通信ホストとの接続を図るまでの動作については、前述の定期巡回の場合と同様である。その後、例えば、予約内容が会議室やライブラリについての本文の読み込みである場合には、自動通信処理部600は、自動通信によって、まず、その会議室やライブラリ室に移行し、その上で、本文を読みたいタイトルの番号を通信ホストに対して送り、そのタイトル番号の本文データの送信を要求する。会議室やライブラリの場合、通信ホストでは、一旦付されたタイトル番号はその後ずれることはないので、予約ファイル610に記憶されているタイトル番号をそのまま使って、本文データの送信を要求することができる。
通信ホストから該当する本文データが送信されてきたら、自動通信処理部600は、その本文データを受信してデータベース410内のデータファイルに書き込む。こうして、予約した本文データが取得され、データベース410に書き込まれる。その後、その会議室やライブラリについてタイトルの更新が必要なら、前述したタイトル更新処理も併せて行なう。
また、予約内容がニュースや掲示板についての本文読み込みである場合には、まず、ニュースや掲示板のサービスに移行し、その上で、本文を読みたいタイトルの番号を通信ホストに対して送る。
しかし、ニュースや掲示板の場合は、前述したように、通信ホストでは、新たなタイトルが登録されると、それ以前に登録されたタイトルの番号は「1」ずつ増加してずれることになるので、会議室やライブラリの場合のように、予約ファイル610に記憶されているタイトル番号をそのまま使って、本文データの送信を要求することはできない。
そこで、ニュースや掲示板の場合は、次のように処理を行なう。即ち、ニュースの場合、ニュースサービスに入ったら、まず、通信ホストに対しタイトルデータの送信を要求し、約10件分ずつタイトルデータを取得して、データベース410の索引ファイルに記憶されているタイトルデータと順番に比較する。そして、取得したタイトルデータの中から、予約ファイル610に記憶されているタイトル番号に対応するタイトル及び提供日時と一致するタイトルデータを見つける。そして、そのタイトルデータのタイトル番号を通信ホストに対して送り、本文データの送信を要求する。
例えば、予約ファイル610に、予約内容として、図16(a)に示したタイトル番号「2」(タイトル「高速道路で交通事故発生」,提供日時「3月1日8時41分」)が記憶されており、通信ホストからは、図16(b)に示すようなタイトルデータが送信されてきたとすると、それらタイトルデータのうち、タイトル番号「5」のタイトルデータが、予約したタイトル番号「2」に対応するタイトル及び提供日時と一致するため、そのタイトル番号「5」を通信ホストに対して送り、本文データの送信を要求する。
また、前述したように、ニュースの場合、通信ホストに登録されているデータは、古いものから順番に削除されるが、その順番を超えて途中のデータが削除されることはない。そのため、複数のタイトルについて本文の読み込みを行なう場合には、上記した処理により、一つのタイトルについてタイトル番号が確定したら、その他のタイトルについては、予約ファイル610に予約内容として記憶されているタイトル番号に、オフセットを加算するだけで、通信ホストに送るべきタイトル番号を求めることができる。
例えば、予約ファイル610に、予約内容として、図16(a)に示したタイトル番号「2」(タイトル「高速道路で交通事故発生」,提供日時「3月1日8時41分」)の他に、タイトル番号「4」(タイトル「サッカーでCチーム勝利」が記憶されている場合、上記したように、タイトル番号「2」は、通信ホストではタイトル番号「5」にずれているので、そのずれ分を表すオフセットは「3」(=5−2)である。従って、予約したタイトル番号「4」にそのオフセット「3」を加算すれば、そのタイトル番号「4」についての通信ホスト上での現在のタイトル番号「7」(=4+3)を得ることができる。よって、このタイトル番号「7」を通信ホストに送ることで、求める本文データの送信要求を行なうことができる。
一方、掲示板の場合は、掲示板のサービスに入ったら、まず、通信ホストに対しタイトルデータの送信を要求し、約10件分ずつタイトルデータを取得して、データベース410の索引ファイルに記憶されているタイトルデータと順番に比較する。そして、取得したタイトルデータの中から、予約ファイル610に記憶されているタイトル番号に対応するタイトル及び登録者識別番号(登録者ID)と一致するタイトルデータを見つけ、そのタイトルデータのタイトル番号を通信ホストに対して送り、本文データの送信を要求する。
図27は掲示板のサービスについての本文読み込み処理を説明するための説明図である。図27において、(a)は当該掲示板についての索引ファイルに既に記憶されているタイトルデータを示し、(b),(c)は当該掲示板について通信ホストより送信されてきたタイトルデータを示す。
前述したように、ニュースの場合は、通信ホストから送信されてきたタイトルデータと、索引ファイルに記憶されているタイトルデータと、が一致するか否かを、タイトル及び提供日時によって判断していた。しかし、掲示板の場合、通信ホストでは、データの登録を日付だけでしか管理しておらず、時間によっては管理していないので、登録時刻によって判断することはできない。また、掲示板の場合も、ニュースの場合と同様に、通信ホストにおける登録データの更新が激しく、一日の間に登録されるデータの数も膨大であるので、ライブラリの場合のように、登録日に基づいて判断することも難しい。
そこで、本実施例では、上述の如く、登録者識別番号(登録者ID)とタイトルとによって判断するようにしている。掲示板の場合、登録者IDも、タイトル自体も、登録後に変更されることはなく、しかも、同一のIDについて同一のタイトルが付されることはないからである。
例えば、予約ファイル610に、予約内容として、図27(a)に示すタイトル番号「6」(タイトル「ISDN−TA売り」,登録者ID「FFF66666」)が記憶されているのに対し、通信ホストからは、図27(b)に示すような10件分のタイトルデータが送信されてきたものとする。これら10件のタイトルデータを見ると、この10件の中には、予約したタイトル番号「6」に対応するタイトル及び登録者IDと一致するタイトルデータは見つからない。そこで、次に、図27(c)に示すような10件のタイトルデータが送られてきたものとする。これら10件のタイトルデータを見ると、予約したタイトル番号「6」に対応するタイトル及び登録者IDと一致するタイトルデータが見つかる。そこで、このタイトルデータのタイトル番号「17」を通信ホストに対して送り、本文データの送信を要求する。
ところで、ニュースの場合は、通信ホストにおいて、古いデータがまとめて削除される以外には、途中のデータが削除されることはないが、掲示板の場合は、登録者等によってデータが自由に削除され得る。従って、複数のタイトルについて本文の読み込みを行なう場合には、一つのタイトルについてタイトル番号が確定したからと言って、その他のタイトルについてはタイトル番号が確定するわけではない。よって、掲示板の場合は、予約した各タイトル番号毎に、上記した処理を行なって、通信ホストに送るべき正しいタイトル番号を求める必要がある。
なお、掲示板の場合は、上記した処理によって、本文データの送信要求を行なう他にも、サーチコマンドを用いることによって、本文データの送信を直接的に通信ホストに対して要求することもできる。即ち、サーチコマンドを用いれば、タイトルや登録者IDを検索条件とすることで、通信ホスト内の本文データを検索して送信してもらうことが可能である。
以上のようにして、予約ファイル610に基づく自動通信が行なわれる。
1−5−3)自動通信の効率化
自動通信は、上記したように、予約ファイル610及び巡回ファイル620に記憶されている内容に基づいて行なわれる。しかし、1回の自動通信を行なうに当たり、一方のファイルの内容に従って巡回を行なってから、他方のファイルの内容に従って巡回を行なうと、例えば、両方のファイルに、巡回先として同一のフォルダ名がそれぞれ記憶されている場合には、そのフォルダを巡回した後、他のフォルダを巡回してから、再び同じフォルダを巡回することになるため、通信に無駄な時間がかかることなる。また、同様のことは、予約ファイル610,巡回ファイル620の各ファイル毎でも言える。即ち、ファイルに記憶されている順番に巡回を行うものとすると、例えば、予約ファイル610の内容が図26に示した内容である場合、3番目に記憶されているサービス「AISOFTステーション」を巡回し、4番目に記憶されているサービス「掲示板」を巡回してから、再び、3番目と同じサービス「AISOFTステーション」を5番目に記憶されているサービスとして巡回しなければならず、上記と同様に、通信に無駄な時間がかかることになる。
即ち、予約ファイル610及び巡回ファイル620内には、巡回先として、同一のサービス名,同一のフォルダ名が重複して記憶されている場合があり、そのような場合に、1回の自動通信で、同じサービスや同じフォルダを何度も巡回することになれば、通信の効率は極端に低下してしまう。そこで、本実施例では、自動通信の効率化を図るために、予約ファイル610及び巡回ファイル620内に同一のサービス名,同一のフォルダ名が重複して記憶されている場合には、それら記憶内容を整理して、そのような重複するサービスやフォルダについては、1回の巡回で、そのサービスやフォルダ内で行なうべき処理を全て終えることができるようにしている。
即ち、本実施例では、自動通信を実行するに際して、次に述べるような巡回順序効率化処理を行なう。図28は自動通信時に行なわれる巡回順序効率化処理の流れを示すフローチャートである。予約ファイル610及び巡回ファイル620の両方を用いて自動通信を行なう場合、自動通信処理部600は、まず、図28に示すように、予約ファイル610及び巡回ファイル620から記憶内容をそれぞれ読み出す(ステップS180)。次に、自動通信処理部600の整理部600aは、予約ファイル610から読み出した内容の後に、巡回ファイル620から読み出した内容を配置するようにして、両者の内容をまとめる(ステップS182)。このように、巡回ファイル620の内容が予約ファイル610の内容の後にくるように配置することにより、後述するようにソートしたとしても、常に予約ファイル610の内容が巡回ファイル620の内容より前になるため、同じ巡回先(同一サービス名,同一フォルダ名)においては、常に予約ファイル610の内容に従った処理が、巡回ファイル620の内容に従った処理よりも先に行なわれることになる。
その後、整理部600aは、まとめた内容をソートして整理する。即ち、まず、「GOコマンド」を用いたサービスからサービスへの移動回数を最少にするために、まず、サービス名順になるようにソートを行なう(ステップS184)。次に、サービス内でのフォルダからフォルダへの移動(メニューの入り直し)回数を最少にするために、フォルダ順になるようにソートを行なう(ステップS186)。このようにして、巡回ファイル620及び予約ファイル610から得られた内容について、ソートを終えたら、処理を終了する。
なお、自動通信処理部600は、上記したソートと併せて、次のような処理も行なう。即ち、巡回ファイル620から読み出した内容については、各サービス名毎にデータベース410内のフォルダ一覧索引ファイルから、それぞれ、各フォルダ名についての前回巡回日を調べて、予め指定した巡回間隔の日数が未だ経過していないフォルダ名がある場合には、そのフォルダについては、今回の自動通信における巡回先の指定から外すようにする。また、予約ファイル610の内容と巡回ファイル620の内容とで巡回先が同じ場合(サービス名,ファイル名が同じ場合)であって、その巡回先での予約ファイル610についての処理内容がタイトルの更新を伴う処理(例えば、「本文の読み込み」)であり、巡回ファイル620についての処理内容が「タイトルの読み込み」などであるような場合には、同一の処理が2回行なわれることになるため、巡回ファイル620についての処理内容は省略するようにする。
図29は図28に示した巡回順序効率化処理に従ってソートされた巡回内容の一例を示す説明図である。図29において、◎印は予約ファイル610から読み出した内容のうち、今回の自動通信で巡回が実行される内容を示し、○印は巡回ファイル620から読み出した内容のうち、今回の自動通信で巡回が実行される内容を示している。また、<印は巡回ファイル620から読み出された内容のうち、巡回間隔未経過のため、巡回先の指定から外された内容を示し、×印は巡回ファイル620から読み出された内容のうち、予約ファイル610の内容と処理内容が重複するため、省略された内容を示している。
また、図30は図29に示した巡回内容に従って行なわれた自動通信時の通信履歴を示す説明図である。ログイン手続きによって自動通信が開始され、その後、「GOコマンド」によって各サービスを巡回し、サービス内では「メニュー番号」によって各フォルダを巡回して、それぞれの巡回先で、所定の処理内容が実行され、最後のログアウト処理によって、自動通信が終了する。
なお、巡回ファイル620についての処理内容に従って、タイトルの更新が行なわれた場合だけでなく、予約ファイル610についての処理内容に従って、「本文の読み込み」などのタイトルの更新を伴う処理が行なわれた場合にも、フォルダ一覧索引ファイル内の該当するフォルダ名についての前回巡回日を、今回の自動通信の行なわれた日付に書き換えるようにする。こうすることによって、例え、そのフォルダ名について、定期巡回指定として、「タイトルの読み込み」の処理が指定されていたとしても、今回の自動通信を行なった日付からさらに巡回間隔の日数を経なければ、次の定期巡回が行われないため、無駄な定期巡回をなくすことができる。
1−5−4)新着マークの付与及び表示
ところで、手動通信の場合は、利用者がモニタ76上に表示される通信画面を見て直接指示を出しながら通信が行なわれるため、手動通信中に通信ホストより取得してデータベース410内に書き込んだデータは、利用者が一度は見たデータであると言える。これに対し、自動通信の場合は、例えば、利用者の不在中にタイマを用いて自動通信を開始する場合のように、必ずしも通信時に利用者がモニタ76の画面を見ているとは限らない。また、例え、利用者がモニタ76の画面を見ながら自動通信開始の指示を出し、自動通信が開始されたとしても、通信中に通信ホストより取得しているデータを通信中にモニタ76の画面上で視認することは難しい。従って、自動通信中に通信ホストより取得してデータベース410内に書き込んだデータは、利用者が未だ見ていないデータであると言える。
しかし、自動通信中に通信ホストより新規なデータを取得してとしても、データベース410に一度書き込んでしまったら、どのデータが今回の自動通信によって新規に得られたデータであるのかを識別することは難しい。そのため、自動通信が終わってから、利用者がオフラインの状態で新規に得られたデータをモニタ76の画面上で見ようとしても、利用者はどのサービス,どのフォルダ、さらにはどのタイトルについて新規なデータが得られたのかを知ることができない。
そこで、本実施例では、自動通信中に通信ホストより新規なデータを取得した場合には、アクセス管理部100の新着マーク付加部100dが、そのデータについてフォルダあるいはタイトルに、新規なデータである旨を示す新着マークを付した上で、書き込み部100aがデータ管理部400を介してデータベース410に書き込むようにしている。具体的には、フォルダについては、図5に示したように、フォルダ一覧索引ファイル内の該当するフォルダに新着マーク(+)が付される。また、タイトルについては、図7に示したように、索引ファイル内の該当するタイトル新着マーク(+)が付される。
これによって、データベース410に新たに書き込まれたデータは、既に記憶されている他のデータと区別が付くようになる。従って、この新着マークを利用すれば、新規に得られたデータをモニタ76の画面上で見る場合にも利用者はどのサービス,どのフォルダ、さらにはどのタイトルについて新たなデータが得られたのかを知ることが可能となる。
なお、新着マークをどのように付けるかは、自動通信時の処理内容によって異なる。即ち、例えば、自動通信時の処理内容が「本文の読み込み」である場合には、該当するフォルダ自体に新着フォルダマークを付けると共に、新規に得られたタイトルにも新着タイトルマークを付けるようにしている。
これに対し、自動通信時の処理内容が「タイトルの読み込みのみ」である場合には、該当するフォルダ自体に新着フォルダマークを付けるだけで、取得したタイトルには新着タイトルマークを付けないようにしている。「タイトルの読み込みのみ」である場合に取得したタイトルに新着タイトルマークを付けてしまうと、後述する新着ツアーを行なった際に、そのツアーの進み方が遅くなるからである。しかし、サービスやフォルダによっては、取得されるタイトルも少なくて新着ツアーの進み方にも支障がでない場合もあり得るので、そのようなサービスやフォルダについては、タイトルに新着タイトルマークを付けるようにしても良い。
そこで次に、このような新着マークを使って、通信ホストから新規なデータを取得したことを、どのようにして利用者に知らせるかについて説明する。
自動通信が終わってから、オフラインの状態でモニタ76に初めて画面を表示する場合、利用者に自動通信時に新規にデータを取得した旨を知らせるために、メインメニュー画面,サービス切替画面及びフォルダ画面では、次のようにして表示される。
メインメニュー画面の場合は、まず、アクセス管理部100の新着マーク検索部100eが、データ管理部400を使って、データベース410内に記憶されている全てのフォルダの中から、新着フォルダマークの付いているフォルダを検索する。具体的には、全てのフォルダ一覧索引ファイルの中から、新着マーク(+)の付されているフォルダを検索する。そして、新着フォルダマークの付いているフォルダが見つかったら、アクセス管理部100は、ユーザーI/F部200を使ってモニタ76上にメインメニュー画面を表示する際に、そのフォルダを含むサービス名に、目立つ色(例えば、黄色など)で下線を引く。
図31はモニタ76上に表示されるメインメニュー画面の一例を示す説明図である。図31に示すメインメニュー画面では、本実施例の通信端末装置によって提供される主なメニューが絵メニューとして表示されている。このうち、自動通信によって新規なデータが取得されているサービス名(図31の例の場合、傘の絵で示された「天気予報」のサービス)に目立つ色で下線が引かれている。
また、サービス切替画面の場合も、まず、アクセス管理部100が、データベース410内に記憶されている全てのフォルダの中から、新着フォルダマークの付いているフォルダを検索する。そして、新着フォルダマークの付いているフォルダが見つかったら、アクセス管理部100は、サービス切替画面を表示する際に、図3に示すように、画面左側のサービスリストSLについては、その見つかったフォルダを含むサービスに+印を付けて表示する。また、画面右側のフォルダリストFLについては、そのフォルダに+印を付けて表示する。
さらに、フォルダ画面の場合は、まず、アクセス管理部100が、データベース410内に記憶されている全てのタイトルの中から、新着タイトルマークの付いているタイトルを検索する。具体的には、新着フォルダマークの付されていたフォルダに関する索引ファイルの中から、新着マーク(+)の付されているタイトルを検索する。そして、新着タイトルマークの付いているタイトルが見つかったら、アクセス管理部100は、モニタ76上にフォルダ画面を表示する際に、そのフォルダに+印を付けて表示する。
こうして、自動通信終了後、利用者が初めてモニタ76の画面を見る場合に、利用者は、自動通信中に、どのサービス,どのフォルダ、さらにはどのタイトルについて新規なデータが得られたのかを容易に知ることができる。
1−5−5)新着ツアー処理
次に、新着ツアー処理について説明する。新着ツアーとは、自動通信終了後に、オフライン状態で、自動通信時に新規に取得し利用者が未だ見ていないデータ(即ち、新着データ)を順番にモニタ76の画面上に表示して、新着データのみを自動的に巡回して見せる機能である。
図32は新着ツアー処理の流れを示すフローチャートである。利用者がキーボード72、マウス73を操作して、新着ツアーの開始を指示すると、アクセス管理部100は図32に示す処理を開始する。新着ツアーは、図3に示すサービス切替画面左側のサービスリストSLに掲載された順に、新着フォルダマークの付されたフォルダを含むサービスについてのみ行なわれる。
まず、アクセス管理部100は、新着フォルダマークの付されたフォルダを含むサービスについて、データベース410内に記憶されているフォルダ一覧索引ファイルを読み出して、そのファイル内に新着フォルダマークの付されたフォルダがあるか否かを判定する(ステップS188)。新着フォルダマークの付されたフォルダがある場合には、モニタ76上に、そのフォルダについてのフォルダ画面を表示する(ステップS190)。そして、上記フォルダについて、データベース410内に記憶されている索引ファイルを読み出して、そのファイル内に新着タイトルマークの付されたタイトルがあるか否かを判定する(ステップS192)。
新着タイトルマークの付されたタイトルがある場合には、モニタ76上に表示されたフォルダ画面において、そのタイトルの位置にカーソルを移動する(ステップS194)。これにより、利用者は新着データのタイトルが何であるかを知ることができる。また、この時、そのタイトルについて本文の表示を指示すると、自動通信時に本文データも取得しているものについては、その本文が画面上に表示される。
そして、アクセス管理部100は、利用者から次の新着データのタイトル位置への移動指示があるまで、そのままの状態で待機する(ステップS196)。その後、利用者から移動指示があった場合には、索引ファイル内の上記タイトルについて付されていた新着タイトルマークを外して(ステップS198)、再び、ステップS192に戻り、上記フォルダについて次の新着タイトルマークがあるか否かを判定する。
ステップS192の判定の結果、上記フォルダの索引ファイル内において、新着タイトルマークが全て外されていて、新着タイトルマークの付されているタイトルがもはや無い場合には、前述のフォルダ一覧ファイル内のそのフォルダについて付されていた新着フォルダマークを外して(ステップS200)、ステップS188に戻り、次の新着フォルダマークの付されたフォルダがあるか否かを判定する。
こうして、新着フォルダマークの付されたフォルダを含んでいた全てのサービスについて、新着フォルダマークの付されたフォルダが全て無くなったら、アクセス管理部100は、モニタ76の画面上に新着ツアー終了の旨を表示し(ステップS202)、利用者に新着ツアーが全て終了したことを知らせる。このようにして、図32に示す新着ツアー処理は終了する。
以上のように、自動通信時に新着データを得た場合に、新着ツアー処理を行なうことによって、利用者は未だ見ていないデータを、自らデータベース410内より探し出すことなく、モニタ76の画面上で自動的に見ることができるので、利便性が向上する。
なお、以上の実施例では、パソコン通信サービスを受ける場合を例として説明したが、これに限定されるものではなく、例えば、ビデオテックスなど、他のVAN(付加価値通信網)サービスを受ける場合に適用することが可能である。
2)インターネット通信サービス用通信端末装置
さて、上記した実施例では、パソコン通信サービスを受けるための通信端末装置について説明したが、本発明は、最近流行のインターネット通信サービスを受けるための通信端末装置にも適用することができる。インターネットによって提供される通信サービスとしては、電子メール、ネットニュース(NetNews)、FTP(File Transfer Protocol)、Telnet、WWW(World Wide Web)などの情報提供サービスなどがある。
2−1)ネットニュースのサービスを受ける場合
このうち、まず、本発明の通信端末装置によって、ネットニュースの通信サービスを受ける場合について説明する。ネットニュースとは、インターネット上での電子掲示板を使った不特定多数との相互連絡を意味し、このネットニュースを中心とした集まりをニュースグループという。言うなれば、ニュースグループはパソコン通信サービスにおけるフォーラム(SIG)に相当するもので、インターネット上には1万数千ものニュースグループが存在する。
このようなネットニースの通信サービスを受ける場合、通信端末装置の構成としては図1に示した構成をそのまま用いることができ、通信端末装置の動作としても、前述したパソコン通信サービスを受ける場合の動作と同様の動作を行なうことになる。しかしながら、ネットニースの通信サービスを受ける場合、次の点が異なる。
ネットニュースの場合は複数の階層構造を持ったニュースグループに別れている。例えば、図33(a)に示すように、「aisoft.general」,「aisoft.comp.pc98」,「aisoft.comp.dosv」というNewsグループがあったとすると、これらはいずれも「aisoft」というニュースグループに含まれる。そして、その中に、「general」と「comp」というグループがあり、「comp」というグループがさらに「pc98」「dosv」というグループに別れていることになる。
前述したように、パソコン通信サービスにおけるフォーラムというサービスを受ける場合には、図4に示したように、データベース410内に「forum」というディレクトリを設け、さらにその下の階層にフォーラム毎にディレクトリを設けて、各フォーラムから取得したデータをそれぞれ分類して管理していた。これに対し、インターネットのニュースグループの場合は、上記したように、階層構造が深いため、それに対応するように、データベース410内のディレクトリ構造も階層をもっと深くすることで、ニュースグループについても同様に、取得したデータをそれぞれ分類して管理することができる。具体的には、例えば、図33(a)に示したニュース・グループに対しては、データベース410内において、図33(b)に示すようなディレクトリ構造を構築することによって対応することができる。
なお、各ディレクトリ内には、例えば、前述したようなパソコン通信サービスにおけるフォーラム内のタイトルを管理する索引ファイルの代わりに、ネットニュースの記事を管理する索引ファイルを作成して格納するようにすれば良い。
2−2)WWWのサービスを受ける場合
次に、本発明の通信端末装置によって、インターネットにおけるWWWの通信サービスを受ける場合について説明する。WWWとは、インターネット上の文字やグラフィックなどの情報を、キーワードで有機的に結びつけたハイパーテキスト形式によって見ることができるサービスをいう。
このようなWWWの通信サービスを受ける場合、通信端末装置の構成としては図1に示した構成を概ねそのまま用いることができ、通信端末装置の動作としても、基本的には、前述したパソコン通信サービスを受ける場合の動作と同様の動作を行なうことになる。しかしながら、WWW自体の持つ独自の特徴によって、パソコン通信サービスを受ける場合と異なる動作形態を採る場合もある。
WWWにおけるデータは、基本的には、HTML(Hyper-Text Markup Language)と呼ばれる言語によって記述されたハイパーテキストデータによって構成されている。ハイパーテキストデータは、「ページ」という単位から成り立っており、1つの「ページ」が1つのファイルを構成することになる。これらハイパーテキストデータは、それぞれ、インターネット上に接続されたWWWサーバ内にファイルとして格納されている。なお、WWWサーバには、ハイパーテキストデータの他、画像データ(静止画,動画など)や音声データさらには種々のプログラムデータなどが格納されている。
通信端末装置は、インターネットを介してそれらWWWサーバにアクセスすることによって、それらのWWWサーバに格納されているハイパーテキストデータなどを取得することができる。これらハイパーテキストデータは、通信端末装置におけるブラウザと呼ばれるソフトウェアを使った機能によって、モニタ76の画面上に表示させることができる。ハイパーテキストデータでは、ページ中に「リンク」という特別な情報を入れ、このリンクによってキーワードと別のページとを関連付けることができる。このリンク機能を用いると、例えば、利用者はモニタ76の画面に表示されたページ内のキーワードをマウス73によってクリックするだけで、関連づけられたページを即座に見ることができる。
ところで、インターネット上にあるオブジェクト(例えば、データのファイル)は、全て、それが置かれている場所をURL(Uniform Resource Locator)によって一意的に表すことができる。従って、例えば、URLが、「http://www.epson.co.jp/index.htm」である場合には、「www.epson.co.jp」というWWWサーバ内に「index.htm」というファイルがあることを表している。なお、「http」はプロトコルの指定であって、WWWで一般的に使用されるプロトコル名である。
また、HTMLによって記述されたハイパーテキストデータ内において、<>に括られた部分をタグといい、このタグによって、例えば、下線などの文字属性や、イメージの表示方法、或いはリンク等を指定する。
図34はHTMLによって記述されたハイパーテキストデータの一例を示す説明図である。図34を用いて、リンクの指定方法について説明する。図34に示すハイパーテキストデータは上記した「www.epson.co.jp」というWWWサーバ内に格納されているものとする。
図34のm行では、「<A>」と「</A>」で囲まれた部分がリンクの指定(HTMLでは、アンカーという)である。「HREF="/epson/index/index.htm"」の部分がリンク先の指定で、「クリックされたら、「/epson/index/index.htm」というファイルの内容を表示せよ」ということを表している。「/epson/index/index.htm」の部分はWWWサーバ内でのパス指定であって、「www.epson.co.jp」というWWWサーバ内でのファイルのある位置を示している。
また、「<IMG SRC="/epson/image/haruj.gif">」というのは、その部分にイメージを表示するための指定であり、ここでは、「/epson/image/haruj.gif」というイメージファイルの内容を表示することを示している。なお、「<P>」は改行の指定である。
また、リンクの指定は、WWWサーバ内だけでなく、別のサーバへも行える。図34のn行では、「HREF="http://www.aisoft.co.jp/index.htm"」の部分で外部へのリンク指定を行なっている。これは、「www.aisoft.co.jp」というWWWサーバに接続して、「index.htm」というファイルの内容を表示せよ」という指定である。
2−2−1)ハイパーテキストデータ等の取得
では、本実施例において、WWWサーバに格納されたハイパーテキストデータなどを取得する場合の動作について説明する。一般に、通常の利用者がWWWサーバにアクセスするには、予め登録した回線プロバイダに、モデム92を利用して公衆回線経由で接続し、そのプロバイダを介してインターネットに接続する必要がある。
そこでまず、利用者がキーボード72,マウス73を使ってインターネットへの接続を指示すると、アクセス管理部100は通信制御部300等を介して回線プロバイダに電話をかけ、そのプロバイダを介してインターネットへの接続を図る。その後、利用者が所望のWWWサーバ内に格納されているハイパーテキストデータ等の取得を指示すると、アクセス管理部100は、通信制御部300を介してそのWWWサーバに対しデータの送信を要求する。
この時、取得すべきデータの指定として、取得すべきデータの置いてあるアドレスの指定や、データのリンクレベルの指定や、データの種別の指定などが行える。このうち、アドレス指定では、「http://www.aisoft.co.jp」といったWWWサーバの指定や、その中の特定のページを指定することができる。また、リンクレベルの指定では、ページ内のリンクをどのレベルまで辿るかを指定することができる。例えば、リンクを何レベル辿るかといった数値の指定や、指定したWWWサーバ内のレベルまでといった指定ができる。さらに、種別の指定では次のような指定を行なうことができる。即ち、ページ内には、次のページへのリンクだけでなく、画像データや音声データを貼り込むことができる。また、FTPといったファイルそのものを転送するための参照も含まれている。このようなデータの種類別に、そのデータを取得するか、しないかを指定することもできる。さらに、サイズの上限を設定することにより、サイズの小さいデータだけを取得することもできる。
以上のようにして指定したハイパーテキストデータ等がWWWサーバから送信されてきたら、アクセス管理部100は、通信制御部300等を介してそれらデータを取得し、データ管理部400を介してデータベース410内に記憶する。この時、アクセス管理部100は、取得したデータを後述するように分類,整理して、データベース410に書き込む。
こうして、所望のWWWサーバよりハイパーテキストデータを取得し、データベース410内への書き込みが全て終了したら、アクセス管理部100は、通信制御部300等を介して、インターネットとの接続を断つ。その後、オフラインの状態で、アクセス管理部100は、データ管理部400を介してデータベース410内よりデータを読み出して、ブラウザの機能を使ってユーザーI/F部200を介してモニタ76の画面上に表示する。これにより、利用者はインターネットに接続している時と全く同様にデータのブラウジングを行なうことができる。
この際の最も大きなメリットは、通信時間がデータ転送の時間とほぼ等しくなるので、通信回線を最大限に活用できるようになり、回線プロバイダとの接続料金、公衆回線の通信料金も安価になることである。
また、データベース410に記憶したデータを、通信回線と接続されていない別のパソコンに保存してブラウジングすることもできるので、通信回線のないところ(例えば、通勤の電車の中等)でデータの内容を見ることもできる。
ところで、前述したパソコン通信サービスを受ける場合と同様に、WWWのサービスを受ける場合にも、自動通信を行なうことは可能である。例えば、予めタイマ68で指定した時刻に、インターネットに自動接続して、所望のデータを取得するようにする。
一般に、接続領域や通信料金は時間帯で価格が変り、特に深夜ほど安くなる場合が多い。従って、データの取得を行なう際にも、昼間の時間帯よりも、深夜の方が料金が安価になる。さらに、回線の込み具合も変動するため、深夜ほど回線プロバイダへ繋がりやすいということもある。このとき、深夜の特定の時刻に自動通信を行なうように、設定しておくことで、利用者の介在なしに自動的にWWWサーバから所望データを取得することができる。
なお、自動通信実行のスケジューリングは、特定の日時指定の他、「毎日X時」、「毎週月曜日X時」といった指定もできる。さらに、接続するWWWサーバ毎に異なった指定を行なうこともできる。
2−2−2)データベースへの取得データの記憶及び記憶データの表示
ところで、アクセス管理部100は、WWWサーバより取得したハイパーテキストデータ等をデータベース410内に書き込む際には、各ページのリンク関係に配慮しながら、次のように分類、整理して書き込むことになる。
例えば、今、各ページが図35(a)に示すようなリンク関係であったとすると、ホームページからまずA、B等のページへリンクし、次にA−1、B−1等のページへリンクし、さらにその先のA−3、D等のページへリンクしていく。
そして、このようなリンク関係を反映するように、各ページのファイルがWWWサーバに格納されていたとする。即ち、「A」の以下のページがWWWサーバ内で図35(b)に示すように格納されていたとする。
このような場合には、アクセス管理部100は、WWWサーバより取得したデータの各ページに付されているURLを検知して、そのURLに基づいて、WWWサーバ内の図35(b)に示したディレクトリ構造を保ったまま、取得したデータをデータベース410内に書き込むようにする。
また、このようにWWWサーバ内のディレクトリ構造を保ったままデータベース410に書き込む方法の他、そのようなディレクトリ構造と無関係にフラットな状態でデータベース410にデータを書き込むこともできる。即ち、図35(c)に示すように、例えば、取得したデータを全て「\LOCAL」というディレクトリに格納するのである。だが、この際、WWWサーバ内において別のディレクトリにも同一ファイル名が存在する可能性があるが、そのような場合には、一方のファイル名を変更するようにする。例えば、図35(b)において、A−2,A−3の各ページが、図35(d)に示すように、両方とも「A-2.html」という同一のファイル名となっている場合、後から書き込むファイル名を「A-2_00.html」というように変更して格納するようにする。
ところで、このように、WWWサーバより取得したハイパーテキストデータをデータベース410に書き込む場合、次の点に留意する必要がある。即ち、取得したハイパーテキストデータ内には、前述したように、多くの場合、リンクの指定が設けられており、しかも、そのリンク先は、リンクされるファイルのインターネット上での格納場所を表したままとなっている。従って、データベース410に書き込む際には、そのようなリンク先を全て、リンクされるファイルのデータベース410内での書き込み場所を表すように書き換える必要がある。
リンク先を表すURLとしては、ローカルのハードディスク上のファイルを指定することも可能であるのでこれを利用する。例えば、データベース410が格納されているハードディスク84が「C」ドライブである場合、そこに書き込まれている「\Epson\index.htm」というファイルはURLとして「file:///C|/Epson/index.htm」と表すことができる。
従って、例えば、図34に示したハイパーテキストデータをデータベース410に書き込む場合には、図36に示すように「HREF」の部分をリンクされるファイルの書き込み場所に変更し、全てのリンク先を書き換えることで、リンク関係を全てデータベース410内に収めることができる。この時、取得しないサーバへのリンクを含む場合もあるが、これはそのまま格納して変更しない。
さて、以上のようにして、データベース410内に書き込まれたハイパーテキストデータ等は、前述したように、アクセス管理部100により、データ管理部400を介してデータベース410から読み出されて、ブラウザの機能を使ってユーザーI/F部200を介してモニタ76の画面上に表示される。この場合は、オンライン状態にある場合と同様に、利用者は、各ページをリンクに従って順に見ていくことができる。例えば、図35(a)の例では、最初にホームページを表示し、そこからA,B等のページに移り、さらにその先のページを順に見ていくことになる。取得しないサーバへのリンクはそのまま残っているので、オンライン状態にして見ていくこともできる。この結果、利用者はデータの位置を意識せずに内容を見ることができる。
また、本実施例では、このような通常のブラウジング画面のような表示の仕方の他、データベース410内の記憶データの全体の構造を表すような表示の仕方を行なうことも可能である。このような場合、データベース410内のディレクトリ構造に合わせて表示するようにしても良いが、通常は、実際のリンク関係に合わせて表示するようにする。
図37はデータベース410内の記憶データをツリー形式でモニタ76に表示した場合の表示画面の一例を示す説明図である。図37(a)に示す画面では、最上位に「A.I.SOFT Home Page」というホームページがあり、そこからリンクしているページとして、「A.I.SOFT English Home Page」というページがあることを示している。また、各ページに埋め込まれているイメージや音声データも、図37(b)に示す「aisoft/image/title/gif」のように、同様の方法で表示することで、各ページにどのようなデータが含まれているかを表示することもできる。
図中の「−」の記号はそれ以上リンクされる先がないページを示し、「+」の記号は未だリンクされる先があるページを示している。従って、利用者がマウス73を使って「+」の記号の付されたページ名を順番にクリックすることにより、次々とリンク先のページ名を表示させることができる。
また、利用者がブラウジングしたいページがある場合には、そのページをマウス73で指定してブラウジングを行なう旨の指示を行なうことによって、モニタ76の画面上には、ブラウジング機能を利用してそのページが表示される。さらにまた、特定の文字列やデータを含むページを検索したりすることも可能となっており、より効率的なブラウジングを行なうことができる。そしてまた、図37に示す画面左側の開いている部分に覚え書き等のコメントやメモを付加することも可能となっており、アクセスした日時などを管理することもできる。
以上のように、データベース410に記憶された各ページのリンク関係をツリー形式で表示することによって、全体の構造を簡単に把握できるようになると共に、オフライン状態でのブラウジングを効率的に行なうことが可能となる。
また、図37に示したようなツリー形式を採らずに、図38に示すように、フラットな状態で画面上に表示するようにすることもできる。図38は何れもブラウザ機能を利用してモニタ76上に表示された画面を示している。図38において、下線部分はリンクが埋め込まれた部分であり、マウス73によってここをクリックすると、リンク先のページに移行する。
図38(a)では図37に示した「A.I.SOFT English Home Page」をタイトル名として、1階層下の各ページ名を羅列して表示している。なお、このように、1階層下のページ名だけ羅列して表示するでなく、複数の階層をフラットに羅列して、全体を一度に表示するようにしても良い。
また、特定のWWWサーバにおける下位の階層に格納されている特定のページに、利用者が関心を持っている場合には、データベース410に書き込まれているそのページのデータに簡単にアクセスして表示できるようにするために、モニタ76の画面上に表示する内容を図38(b)に示すようにカスタマイズするようにしても良い。図38(b)では予め設定したページ名だけを一覧表示して、それらのページが容易に開けるようにしている。
ところで、新聞社等のWWWサーバにおいて提供されるページ(ハイパーテキストデータ)の内容は、その時に起きたニュースに合わせて毎日更新される。従って、このような新聞社等のWWWサーバからハイパーテキストデータ等を毎日取得してデータベース410に書き込むと、過去に書き込んだハイパーテキストデータは、更新されたハイパーテキストデータによって次々に上書きされるため、消えてしまって残らない。しかし、利用者によっては、1週間分のページをまとめておいて、後で内容を見たい場合や内容を保存しておきたい場合がある。そのような場合に、過去に書き込んだデータを消さずに新たに書き込んだデータと共に蓄積できれば便利である。
そこで、このような新旧のハイパーテキストデータ等を共に記憶して管理する機能の実現方法について説明する。このような新旧のハイパーテキストデータの記憶は、これらデータをデータベース410に書き込む際に、格納すべきディレクトリを別々にすることで実現する。
図39はデータベース410内のディレクトリ構造の一例を示す説明図である。例えば、図39(a)に示すように、データベース410内に日付毎にディレクトリを作成して、取得したハイパーテキストデータ等を、毎日、その日付に対応するディレクトリに格納するようにする。
この時、毎日、WWWサーバ内に格納されているほとんどのページの内容が変わる場合には、その日のディレクトリまたはその下位のディレクトリに、そのWWWサーバ内の必要なページを全て格納するようにする。また、毎日、WWWサーバ内に格納されている一部のページだけが変るような場合には、前日のデータと比較して、リンク先のページ等が変更されていなければ、そのリンク先のページについては格納せずに、前に既に書き込んであるページにリンク先を変更してから格納することもできる。
また、以上のようなやり方の他、特定のWWWサーバから取得したページということでなく、予め設定しておいたキーワードを含むページのみを上記のように日付等により分類して、日付毎のディレクトリに格納することも可能である。
また、図39(b)に示すように、日付分類とせずにキーワードによる分類として、キーワード毎のディレクトリを作成し、キーワードを含むページを対応するディレクトリに格納することもできる。このようにした場合には、特定のトピックに関する内容を時間順にブラウジングすることもできる。
また、以上のように、WWWサーバから取得したハイパーテキストデータ等を日付別或いはキーワード別に分類、整理して、データベース410に書き込む場合には、各日時或いは各キーワードへのリンクを埋め込んだインデックスとしてページ、即ち、ハイパーテキストデータを別に作成し(例えば、図39(a),(b)の「index.html」)、ブラウザ機能によってそのインデックスページをモニタ76上に表示することによって、利用者は、各日時に対応したページ或いは各キーワードに対応したページに容易にアクセスすることができる。
ところで、以上のように、取得したデータを日時別或いはキーワード別に分類、整理して、データベース410へ書き込む方法、及び、それら分類ファイルの読み出しを可能とするインデックス画面の表示などは、インターネットの通信サービスを受ける場合だけでなく、前述したパソコン通信サービスを受ける場合に同様に適用可能である。即ち、通信ホストから取得した受信データを、通信ホストの提供する通信サービス毎に分類、整理するだけでなく、日時毎或いはキーワード毎に分類、整理してデータベース410に書き込むようする。そして、モニタ76上には日時の一覧或いはキーワードの一覧から成るインデックス画面を表示し、利用者がそのインデックス画面から所望のデータを指示すれば、そのデータをデータベース410より読み出してモニタ76上に表示するようにする。
2−2−3)WWWサーバに対するデータ更新の監視
ところで、インターネット上に、利用者が特別な関心を持っている情報を公開しているWWWサーバがある場合に、利用者は、そのWWWサーバに公開されている情報の内容が追加されたり、変わったりしていた場合に、できるだけ早くその情報を取得したいと思うことがある(例えば、企業が公開する新製品情報など)。
しかし、このような場合に、手動通信によって、利用者が自ら定期的にそのWWWサーバにアクセスし、公開されている情報を実際に見て、情報の内容に変更があるか否かを判断していたのでは、非常に手間がかかる。また、興味ある情報を公開しているWWWサーバが増えてくるにつれ、その作業は非常に膨大になり、手間がかかりすぎて事実上不可能となる。
そこで、本実施例では、自動通信によって、特定のWWWサーバに公開されている情報に変更がないか監視するようにしている。即ち、前述したパソコン通信サービスを受ける場合に用いた定期巡回の機能を利用するのである。
その動作を簡単に説明すると、自動通信処理部600は、利用者によって指定された監視すべきWWWサーバを予めハードディスク84内に登録しておく。そして、自動通信処理部600は、自動通信によって、定期的に、その登録されたWWWサーバに対しアクセスし、そのWWWサーバに格納されているデータ(即ち、情報)に変更があったか否か調べる。
格納データに変更があるか否かは次のように調べる。即ち、HTMLプロトコルによれば、WWWサーバから格納されたハイパーテキストデータ等の本データを取り出すことなく、そのデータに付随した更新日時などの情報を取得することができるので、これを利用する。この更新日時としてはファイルの最終更新日時が推奨されているので、この更新日時を最終更新日時として取得して、その日時を、自動通信処理部600側で予め保存してある最終アクセス日時と比較することで、WWWサーバに格納されているデータが変更されているかどうかわかる。
また、上記したような更新日時がサポートされていないデータについては、WWWサーバからハイパーテキストデータを取得した際に、そのデータからチェックサムを計算して、その値を自動通信処理部600側で保存する。そして、再び、そのWWWサーバにアクセスし、データを取得してチェックサムを計算し、保存した値と比較することによって、格納データの変更の有無がわかる。
以上のような、格納データの変更の有無のチェックは、通常、ページ単位で行なうことになるが、さらにページ内のある特定部分の変化や、ページからリンクしている先のデータの変化をもチェックするようにしても良い。
なお、以上のようなWWWサーバに対する格納データの変更の有無を監視することが可能な通信端末装置については、後ほど、別の実施例として、詳しく説明する。
3)データ更新監視サーバ
さて、上記したように、WWWサーバに対する格納データの変更有無の監視は、通信端末装置独自によって行なうことも可能であるが、以下に述べるようなデータ更新監視サーバをインターネットに接続して、専用に行なうこともできる。
3−1)データ更新監視サーバの構成
図40は本発明の第2の実施例としてのデータ更新監視サーバの構成を示すブロック図である。図40に示すように、データ更新監視サーバ1000は、他のWWWサーバ4000,5000などと同様にインターネット3000に接続されている。また、通信端末装置から成るクライアント2000は、プロバイダ用サーバ6000を介してインターネット3000に接続されている。従って、データ更新監視サーバ1000とクライアント2000とはインターネットを介して互いに接続されている。
また、データ更新監視サーバ1000は、主として、WWWサーバ4000,5000に格納されている格納データ4100,5100の更新の有無を監視する監視部1100と、監視すべきデータの格納場所(即ち、URL)などの登録を行なう登録管理部1200と、インターネット3000を介してクライアント2000との間やWWWサーバ4000,5000との間でデータ通信を行なうための通信部1300と、登録された格納場所の情報やWWWサーバ4000,5000から取得したデータを記憶するための記憶部1400と、を備えている。WWWサーバ4000,5000にはそれぞれ格納データ4100,5100としてハイパーテキストデータなどが格納されている。
データ更新監視サーバ1000は、図2に示したようなコンピュータによって構成されており、図40に示すデータ更新監視サーバ1000内の各ブロックは、ハードウェアにより実現されている部分とソフトウェアにより実現されている部分とを含んでいる。
なお、ソフトウェア部分については予めアプリケーションプログラムの形で図2に示したハードディスク84に記憶されており、利用者から起動の指示がなされて、オペレーティングシステムによってハードディスク84からメインメモリ25上に読み込まれることによって、ハードウェアとソフトウェアが一体となった図40に示すデータ更新監視サーバ1000が実現する。
また、上記アプリケーションプログラムが図2に示すCD−ROM85に記録されている場合には、このCD−ROM85をCD−ROM装置83に挿入し、上記アプリケーションプログラムをCD−ROM装置83で読み取ることによって、メインメモリ25に転送するようにしても良い。また、上記アプリケーションプログラムが図2に示すフロッピディスク81に記録されている場合には、このフロッピディスク81をフロッピディスク装置82に挿入し、上記アプリケーションプログラムをフロッピディスク装置82で読み取ることによって、メインメモリ25に転送するようにしても良い。また、上記アプリケーションプログラムは光磁気ディスクなどの他の可搬型記録媒体上からメインメモリ25に転送するようにしても良い。
また、上記アプリケーションプログラムが図2に示すプログラム供給サーバ9000に格納されている場合には、モデム92によって通信回線93を介してプログラム供給サーバ9000にアクセスし、プログラム供給サーバ9000から上記アプリケーションプログラムを送信してもらうことによって、メインメモリ25に転送するようにしても良い。なお、通信回線93としては、電話回線やネットワーク回線などの有線回線の他、通信衛星などを利用した無線回線などが考えられる。
3−2)データ更新監視サーバの動作
本実施例の動作を簡単に説明する。
利用者は、まず、クライアント2000を用いてデータ更新監視サーバ1000に対しユーザの登録を指示する。その指示は、プロバイダ用サーバ6000,インターネット3000を介してデータ更新監視サーバ1000に伝えられ、データ更新監視サーバ1000内において、通信部1300を介して登録管理部1200に入力される。登録管理部1200では、利用者からの指示に従って、ユーザ登録を行なう。
次に、利用者は、クライアント2000を介してデータ更新監視サーバ1000に対し、監視すべきデータの格納されている場所、即ち、URL(以下、監視URLという)の登録を指示する。これにより、登録管理部1200は、利用者からの指示に従って、監視URLの登録を行なう。登録された情報は記憶部1400に書き込まれる。
こうして、監視URLの登録が行なわれると、通信部1300は、その監視URLに基づいて、その監視URLが示すWWWサーバにインターネット3000を介してアクセスする。例えば、監視すべきデータが格納データ4100であった場合には、通信部1300は、監視URLに従ってWWWサーバ4000にアクセスする。次に、監視部1100は、WWWサーバ4000内の格納データ4100が更新されたか否かをチェックし、その更新チェックの結果を記憶部1400に保存する。監視部1100は、このような更新チェックを、登録されている全ての監視URLについて定期的に行なう。
一方、利用者は、格納データの更新の有無が知りたい場合には、クライアント2000を用いてデータ更新監視サーバ1000に、更新有無の問い合わせを行なう。これに対し、登録管理部1200は、その利用者の登録した監視URLに格納されているデータについての更新チェックの結果を、記憶部1400より読み出して、クライアント2000に転送し、利用者に知らせる。この時、登録管理部1200は、クライアント2000が監視対象となっているWWWサーバに対してアクセスして格納データを取得した最終アクセス日時を把握しており、その日時以降の最新チェックの結果をクライアント2000に対し転送する。
そこで、利用者は、その更新チェックの結果から、格納データの更新があったことを確認した場合には、必要に応じて、クライアント2000をプロバイダ用サーバ6000を介してインターネット3000に接続し、そのデータの格納されているWWWサーバにインターネット3000を介してアクセスする。そして、そのWWWサーバから所望のデータを取得する。
従って、利用者は、格納データが更新されたか否かをデータ更新監視サーバ1000にアクセスするだけで、知ることができるため、更新されたか否かを調査する手間も省け、通信時間も短くて済み、より効率的な格納データの監視を行うことができる。
なお、登録管理部1200は、格納データの更新チェックの結果を、利用者がデータ更新監視サーバ1000にアクセスした時に転送するだけではなく、電子メールを用いて利用者に転送することもできる。或いは、データ更新監視サーバ自ら公衆回線等を介してクライアント2000にアクセスして転送するようにしても良い。
また、監視部1100は、前述したように、格納データの更新有無のチェックを定期的に行なっているので、記憶部1400には最新のチェック結果を保存している。従って、利用者からの問い合わせがあった場合には、監視しているWWWサーバにアクセスすることなく、即座に、最新の更新有無のチェック結果を転送することができる。
また、図40では一つのクライアントしか記載していないが、実際には、多数のクライアントが存在することになるため、データ更新監視サーバ1000は、多数の利用者によって利用されることになる。従って、複数の利用者が同一のWWWサーバに格納されているデータの監視を希望することも十分予想される。そのような場合、そのWWWサーバに対して1回アクセスするだけで、監視部1100は、複数の利用者についての更新有無のチェックを行なうことができるので、非常に効率が良くなる。
また、監視部1100は、WWWサーバにアクセスした際に、監視している格納データ自体を取得し、そのデータを記憶部1400に記憶するようにしても良い。この場合に、登録管理部1200は、クライアント2000を介して利用者からデータ送信の要求があったら、その要求に従って、記憶しているデータをクライアント2000に対し送信するようにしても良い。このようにすることによって、利用者は、WWWサーバに格納されていたデータをデータ更新監視サーバ1000を介して容易に取得することができる。
また、監視部1100は、上記したようにWWWサーバから格納データ自体を取得した場合に、その取得したデータを図39に示したように日時毎或いはキーワード毎に分類、整理して記憶部1400に記憶すると共に、登録管理部1200は、各日時或いは各キーワードへのリンクを埋め込んだインデックスページを作成し、利用者からデータ送信の要求があったら、その要求に従って、その分類、整理したデータとインデックスページをクライアント2000に対し送信するようにしても良い。また、インデックスページのみを先に送信し、利用者からそのインデックスページを用いてさらにデータの要求があった場合に、分類、整理したデータの中から要求されたデータを送信するようにしても良い。
また、登録管理部1200は、記憶しているデータを所望のフォーマットに編集し、利用者からの要求に応じたフォーマットのデータを送信するようにしても良い。ここで、所望のフォーマットに編集するとは、例えば、リンクされたデータを文字、画像情報に展開して、フラットな表示を可能にすることである。具体的には、例えば、ニュース速報等を各新聞社のWWWサーバから入手して、特定の日付、特定の分野等で一枚のいわゆる「電子新聞」として編集、表示を行なうなどの応用が可能になる。これにより、利用者は、各WWWサーバを見て回る必要が無く、データ更新監視サーバ1000に接続するのみで、所望の情報を見やすい表示形態で一読することができる。利用者個々に対して、データの検索条件や表示フォーマットを用意すれば、その利便性はさらに増すことになる。
なお、このように、データ更新監視サーバ1000からクライアント2000に上記データを送信する際には、電子メールを用いて送信することもできる。特に、無線によってネットワークに接続された携帯型コンピュータなど、回線能力が小さい場合には、転送データの少ない電子メールは有効である。さらに、画像データを割愛して送信データ量を減らす編集フォームを、上記携帯型コンピュータ用に用意することも好適である。また、データ更新監視サーバ1000からクライアント2000にアクセスして、クライアント2000に接続されているプリンタ等を起動して、そのプリンタ等からデータを印刷して出すようにすることもできる。さらに、データ更新監視サーバ1000から公衆回線等を介して利用者に直接電話をかけ、ファクシミリ等でデータを送るようにすることもできる。
また、記憶部1400にWWWサーバから取得したデータを記憶している場合において、監視部1100は、格納データの更新があったことを確認した場合に、WWWサーバから更新後のデータを取得し、記憶部1400に記憶されている更新前のデータを更新後のデータで書き換えるようにしても良い。このようにすることによって、利用者がデータの送信を要求した場合に、利用者に対して最新のデータを送信することができる。
また、記憶部1400にWWWサーバから取得したデータを記憶している場合において、監視部1100は、格納データの更新があったことを確認した場合に、WWWサーバから更新後のデータを取得し、記憶部1400に記憶されている更新前のデータと比較して、データ中の更新された箇所を検出し、その検出結果を記憶部1400に保存するようにしても良い。さらに、利用者から更新箇所の問い合わせがあった場合には、登録管理部1200は、記憶部1400から前記検出結果を読み出して、クライアント2000に通知するようにしても良い。
ところで、本実施例においては、データの管理形態の相違によって次の2つの場合がある。
(1)利用者毎の監視URLをデータ更新監視サーバで管理する場合
この場合、利用者毎の監視URLはデータ更新監視サーバ1000で管理しており、クライアント2000では管理していない。従って、クライアント2000は利用者の指示した監視URLを保存する必要はないが、その代わりに、データ更新監視サーバ1000が保存することになるので、データ更新監視サーバ1000の記憶しているデータの容量が多くなる。しかし、格納データの更新の有無を通知するのに電子メールで知らせるなどのサービスを行なうことができる。
(2)利用者毎の監視URLを各クライアントで管理する場合
データ更新監視サーバ1000では、利用者の管理と監視URLの管理のみを行っており、各監視URLがそれぞれどの利用者によるものなのかについては管理していない。このため、各利用者は、監視URLをクライアント2000内のローカルデータベース(ローカルDB)に保存し、データ更新監視サーバ1000に格納データの更新の有無を問い合わせる際には、保存した監視URLをデータ更新監視サーバ1000に通知して、問い合わせる。クライアント2000で保存されるデータは、クライアント2000がWWWサーバの格納データを取得する際に用いる管理データと共用できるので、保存データの容量は大きくはならない。また、データ更新監視サーバ1000においても、管理データは少なくて済む。
では、各場合について、それぞれ、管理データの概要と、データ監視サーバ−クライアント間のトランザクションの概要をそれぞれ説明する。
まず、(1)の場合について説明する。図41は利用者毎の監視URLをデータ更新監視サーバで管理する場合における各管理データの概要を示す説明図である。
データ更新監視サーバ1000は、図41に示すように2つのユーザ管理テーブルと監視URLデータを持っている。このうち、ユーザ管理テーブルAには、図41(a)に示すようにユーザIDとパスワードを格納している。また、ユーザ管理テーブルBには、図41(b)に示すように、ユーザIDと、そのユーザの監視URLと、属性と、クライアントが監視対象のWWWサーバにアクセスした最終アクセス日時を格納している。ここで、属性としては、監視URLに格納されているデータのみを監視するか、そのデータからリンクしているデータについても監視するかといったような付属情報を格納する。
また、監視URLデータには、図41(c)に示すように、監視すべきデータの格納されているURLと、データ更新監視サーバが最後に更新されたか否かを調べた最終チェック日時と、現在の状態(格納データが変更されていた、削除されていた、エラーのリトライ中であったなどの各状態)を示すステータスと、エラー数と、監視している格納データの最終更新日時が含まれている。ここで、エラー数は、監視のためにアクセスを試みたがアクセスできなかった回数であり、一定時間間隔でアクセスを試みたときに、一定回数以上アクセスできない場合には、対象とするURLが削除されたと判定するために用いる。
なお、監視URLデータは、登録されている監視URL毎に1つずつ存在する。
図42は利用者毎の監視URLをデータ更新監視サーバで管理する場合におけるデータ監視サーバ−クライアント間のトランザクションの概要を示す説明図である。図42において、(a)はユーザの登録時のトランザクションを、(b)は監視URLの登録時のトランザクションを、(c)は格納データの更新有無の問い合わせ時のトランザクションを、それぞれ示している。各図とも、それぞれ、上から下に向かって時間が進行している。
図42(a)に示すように、ユーザ登録時には、クライアント2000からユーザ名、登録パスワードまたはシリアル番号等を送ると、データ更新監視サーバ1000は、そのシリアル番号等の認証を行ない、ユーザIDとパスワードを発行する。登録パスワード、シリアル番号はサービスを限られた利用者に対してのみ提供するために用いる。従って、不特定者に提供する場合は無くても良い。
図42(b)に示すように、監視URL登録時には、クライアント2000からユーザ名、パスワード、監視URLを送ると、データ更新監視サーバ1000は、登録処理を行なってステータスを返す。
図42(c)に示すように、更新問い合わせ時には、クライアント2000からユーザID、パスワードを送り、格納データの更新有無を問い合わせる。データ更新監視サーバ1000は、ユーザIDから、登録されている監視URLと最終アクセス日時を取得する。そして、既に格納してある調査結果から、監視URLに格納されているデータについて、最終アクセス日時以降の更新有無をチェックして、更新有無の結果を更新URLリストとしてクライアント2000に送る。クライアント2000は、その更新URLリストを保存する。
その後、クライアント2000は、WWWサーバにアクセスして、更新されている格納データを取得する。そして、データ更新監視サーバ1000に対し、ユーザID,パスワードと共に、取得したデータの監視URL(即ち、どの監視URLに格納されているデータを取得したかという情報)と、データを取得した日時を送り、データ更新監視サーバ1000は、それらユーザデータを更新する。
次に、(2)の場合について説明する。図43及び図44は利用者毎の監視URLを各クライアントで管理する場合における各管理データの概要を示す説明図である。このうち、図43はデータ更新監視サーバ1000で管理される管理データを、図44はクライアント2000で管理される管理データを、それぞれ示す。
データ更新監視サーバ1000は、図43に示すようにユーザ管理テーブルと監視URLデータを持っている。このうち、ユーザ管理テーブルには、前述のユーザ管理テーブルAと同様に、図43(a)に示すようにユーザIDとパスワードを格納している。また、監視URLデータには、図43(b)に示すように、前述の図41(c)と同様のURLと、最終チェック日時と、ステータスと、エラー数と、最終更新日時が含まれている。
一方、クライアント2000は、図44に示すように監視URLデータを持っている。基本的には、データ更新監視サーバ1000で管理される監視URLデータと同じような構成となるが、監視チェック中の状態を示す「エラー数」がなくなり、クライアント2000が最後にアクセスした「最終アクセス日時」を保持する。なお、WWWサーバから格納データを取得する場合には、このデータは、更新問い合わせ時と格納データ取得時とで共通して利用することができる。
図45は利用者毎の監視URLを各クライアントで管理する場合におけるデータ監視サーバ−クライアント間のトランザクションの概要を示す説明図である。図45において、(a)は監視URLの登録時のトランザクションを、(c)は格納データの更新有無の問い合わせ時のトランザクションを、それぞれ示している。各図とも、それぞれ、上から下に向かって時間が進行している。なお、ユーザ登録時のトランザクションについては、前述の図42(a)と同様なので説明は省略する。
図45(a)に示すように、監視URL登録時には、クライアント2000からユーザ名、パスワード、監視URLを送ると、データ更新監視サーバ1000は、登録処理を行なってステータスを返す。クライアント2000は、ローカルDBへも登録を保存しておく。
図45(b)に示すように、更新問い合わせ時には、クライアント2000からユーザID、パスワードの他、監視URLのリストと最終アクセス日時のリストを送り、格納データの更新有無を問い合わせる。データ更新監視サーバ1000では、各利用者毎の監視URLや最終アクセス日時は管理していないからである。データ更新監視サーバ1000は、既に格納してある調査結果から、監視URLに格納されているデータについて、最終アクセス日時以降の更新有無をチェックして、更新有無の結果を更新URLリストとしてクライアント2000に送る。クライアント2000は、その更新URLリストをローカルDBに格納して、厳重に保管する。その後、クライアント2000は、WWWサーバにアクセスして、更新されている格納データを取得する。
以上説明したように、本実施例によれば、インターネット3000上にデータ更新監視サーバ1000をたちあげることにより、利用者はクライアント2000を用いてデータ更新監視サーバ1000にアクセスするだけで、格納データが更新されたか否かを知ることができるため、より効率的な格納データの監視を行うことができる。
なお、以上のようなWWWサーバに対する格納データの変更の有無を監視することが可能なデータ更新監視サーバについては、後ほど、別の実施例として、詳しく説明する。
上記した実施例においては、インターネット上の通信サービスを受ける場合を例として説明したが、これに限定されるものではなく、インターネットのみならず、WAN,LANなどのネットワーク上でのサービスを受ける場合にも適用できる。
4)データ更新監視が可能な通信端末装置の別の実施例
図46は本発明の第3の実施例としての通信端末装置の構成を示すブロック図、図47は図46のエージェント実行部702の構成を示すブロック図である。本実施例の通信端末装置700は、インターネット通信サービスにおけるWWWのサービスを受けるのに適した通信端末装置であり、特に、WWWサーバに対する格納データの変更の有無を監視することが可能な通信端末装置である。
4−1)本実施例の通信端末装置の構成
図46に示すように、この通信端末装置700は、エージェント実行部702を中心として、データ管理部704と、新着情報データベース706と、比較対象データ格納部708と、エージェント管理部710と、ユーザI/F部712と、モニタ713と、スケジュール管理部714と、キーボード715と、ネットワークアクセス部716と、マウス717と、サーバアクセス部718と、を備えており、プロバイダ用サーバ750等を介してインターネットに接続されている。また、インターネットにはWWWサーバ900をはじめ、複数のWWWサーバが接続されている。その他、インターネットにはWWWサーバ850を介してデータ更新監視サーバ800が接続されている。
なお、本実施例の通信端末装置700は、図2に示したようなコンピュータによって構成されており、図46に示す通信端末装置700内の各ブロックは、ハードウェアにより実現されている部分とソフトウェアにより実現されている部分とを含んでいる。
なお、ソフトウェア部分については予めアプリケーションプログラムの形で図2に示したハードディスク84に記憶されており、利用者から起動の指示がなされて、オペレーティングシステムによってハードディスク84からメインメモリ25上に読み込まれることによって、ハードウェアとソフトウェアが一体となった図46に示す通信端末装置700が実現する。
また、上記アプリケーションプログラムが図2に示すCD−ROM85に記録されている場合には、このCD−ROM85をCD−ROM装置83に挿入し、上記アプリケーションプログラムをCD−ROM装置83で読み取ることによって、メインメモリ25に転送するようにしても良い。また、上記アプリケーションプログラムが図2に示すフロッピディスク81に記録されている場合には、このフロッピディスク81をフロッピディスク装置82に挿入し、上記アプリケーションプログラムをフロッピディスク装置82で読み取ることによって、メインメモリ25に転送するようにしても良い。また、上記アプリケーションプログラムは光磁気ディスクなどの他の可搬型記録媒体上からメインメモリ25に転送するようにしても良い。
また、上記アプリケーションプログラムが図2に示すプログラム供給サーバ9000に格納されている場合には、モデム92によって通信回線93を介してプログラム供給サーバ9000にアクセスし、プログラム供給サーバ9000から上記アプリケーションプログラムを送信してもらうことによって、メインメモリ25に転送するようにしても良い。なお、通信回線93としては、電話回線やネットワーク回線などの有線回線の他、通信衛星などを利用した無線回線などが考えられる。
通信端末装置700において、エージェント実行部702では、予め登録されている複数のエージェントの中の所定のエージェントを実行する。ここで、エージェントとは、マン−マシン・インターフェースの一種であって、オブジェクトに、状況認識や価値基準による判断や実行を付け加えたものをいう。データ管理部704では、新着情報データベース706や比較対象データ格納部708に対し、データの書き込みや読み出しを行う。新着情報データベース706は、後述する新着情報データのほか、エージェントデータやURLデータなどを格納する。比較対象データ格納部708は、後述する比較対象データを格納する。エージェント管理部710では、エージェントの登録や設定内容の変更のほか、データ管理部704を介してエージェントデータの読み出しなどを行う。ユーザI/F部712では、利用者からの指示をキーボード715やマウス717などを介して受けたり、モニタ713の画面上に後述する新着情報などを表示したりする。スケジュール管理部714では、後述するデータ更新監視動作を定期的に実行する場合などにおいて時間管理を行う。ネットワークアクセス部716では、インターネットを介してWWWサーバなどに対しアクセスを行う。サーバアクセス部718では、後述するようにデータ更新監視サーバ800にデータ更新監視動作を行ってもらう場合に、ネットワークアクセス部716を介してデータ更新監視サーバ800に対しアクセスを行う。
また、エージェント実行部702は、図47に示すように、エージェント実行管理部720と、WWWサーバアクセス部722と、更新検出部724と、差分解析エンジン726と、HTML解析エンジン728と、クリッピングエンジン730と、を備えている。
このうち、エージェント実行管理部720は、エージェント実行部702内のの他の構成要素の実行などを制御する。なお、エージェント実行管理部720は書き込み部720aと読み出し部720bを備えている。WWWサーバアクセス部722は、WWWサーバにアクセスして、後述する内容データなどを取得する。なお、WWWサーバアクセス部722はリンク先内容データ取得部722aを備えている。更新検出部724は、後述する更新監視対象データが更新されたかどうかをチェックする。差分解析エンジン726は、後述する更新監視対象データと比較対象データとを比較し、両者の差分データを導き出す。HTML解析エンジン728は、差分データを解析して、後述する見出し情報とリンク情報を切り出す。クリッピングエンジン730は、後述するクリッピング処理を行なう。
4−2)新着情報について
前述したように、インターネット上のWWWサーバにおいて公開されている種々の情報(即ち、通信端末装置がアクセス可能な情報)の中には、利用者が特別な関心を持っている情報があり、そのような情報については、内容の追加や変更などをいち早く知るために、データの更新の有無を定期的に監視したいという要求がある。このような利用者が関心を持つ情報としては、企業などが公開する「What'new」などの新着情報が挙げられる。
そこで、このような新着情報及びそのデータの特徴について説明する。一般に、新着情報は、新着情報の見出しを示す見出し情報と、新着情報の詳しい内容を示す内容情報と、で構成されている。見出し情報とそれに対応する内容情報とはリンク情報によってリンクされている。見出し情報は、通常、インデックスページ内に、複数、箇条書きに列記されている。内容情報は、通常、情報毎に1ページずつ記載されている(但し、新着情報によっては、1ページに複数の内容情報が記載される場合もある。)。複数の見出し情報が列記されたインデックスページは、HTMLデータで構成されるインデックスページデータとして、WWWサーバ内に格納されている。また、内容情報を記載した各ページも、それぞれ、HTMLデータで構成される内容データとして、WWWサーバ内に格納されている。
図48は複数の見出し情報を列記したインデックスページの一例を示す説明図である。図48に示す画像は、HTMLデータであるインデックスページデータを、一般的な通信端末装置において、ブラウザにより画面上に表示したものである。図48に示す例では、インデックスページ内に、複数の見出し情報が各情報の発信年月日と共に列記されている。
図49は図48に示すインデックスページのHTMLデータ(インデックスページデータ)の内容を示す説明図である。図49に示すインデックスページデータ内において、見出し情報を表す各見出しデータには、それぞれ、その見出し情報にリンクされた内容データの格納場所(即ち、URL)を示すリンク情報が含まれている。例えば、図49の下線で示す見出しデータにおいては、“「DiskXplorer for Windows」 を発表”という見出し情報に対し、その内容データの格納場所を示す“HREF="../ainews/news/dxplorer.htm"”というリンク情報が含まれている。従って、この内容データは、WWWサーバ内において、ファイル名“dxplorer.htm”というHTMLデータとして格納されていることがわかる。
一般的な通信端末装置において、画面上に図48に示すような画像が表示されている際に、例えば、下線で示された“「DiskXplorer for Windows」 を発表”という見出し情報をマウス等でクリックすると、WWWサーバにおける上記リンク情報によって示された格納場所より内容データが取得され、画面上には、その内容データに基づいて内容情報が表示される。
図50は図48の“「DiskXplorer for Windows」 を発表”という見出し情報にリンクされた内容情報を記載したページを示す説明図である。図50に示す画像は、HTMLデータである内容データをブラウザによって画面上に表示したものである。
以上説明した各データ及び各情報の関係を図面に表すと図51に示す如くになる。図51はWWWサーバに格納されているインデックスページデータと複数の内容データとの関係を示す説明図である。WWWサーバに格納されているデータのうち、インデックスページデータWNPは、図51に示すように、複数の見出しデータαa,βb,…を備えており、各見出しデータは見出し情報とリンク情報を含んでいる(例えば、見出しデータαaは見出し情報αとリンク情報aを含んでいる)。従って、各見出し情報は、対応するリンク情報によって指示される内容データにそれぞれリンクしている(例えば、見出し情報αはリンク情報aによって指示される内容データAにリンクしている)。
4−3)本実施例における通信端末装置の動作の概要
以上のことを踏まえた上で、本実施例の動作の概要について説明する。今、利用者が図48等に示したような新着情報についてデータ更新の監視を希望しており、それらのデータである図51に示すインデックスページデータWNPや内容データA,B,…が図46に示すWWWサーバ900内に格納されているものとする。
4−3−1)新着情報を初めて取得する場合
そこで、WWWサーバ900に公開されている新着情報を初めて取得する場合、通信端末装置700は、次のように動作する。まず、通信端末装置700には、利用者から更新の監視を行なうべきデータ(即ち、更新監視対象データ)であるインデックスページデータWNPのURL(以下、更新監視対象データのURLをターゲットURLということがある。)が与えられる。そして、通信端末装置700は、ターゲットURLに基づいて、WWWサーバ900にアクセスして、そこに格納されているインデックスページデータWNPの送信を要求する。
その後、通信端末装置700は、WWWサーバ900からのインデックスページデータWNPを受け取ると、インデックスページデータWNPにおいて、各見出しデータ内の見出し情報がいつWWWサーバ900で公開されたかを調べ、利用者が希望する年月日以後の新たな見出し情報のみを求める。図49に示すように、見出しデータ内に見出し情報の発信年月日が含まれている場合には、その発信年月日を参照して見出し情報の公開年月日を求めれば良いが、見出しデータ内にそのような情報がない場合には、その見出し情報にリンクされている内容データを同じ見出しデータ内のリンク情報によって求めて、その内容データの更新年月日(作成年月日を含む)等を参照して見出し情報の公開年月日を求めるようにする。
そして、通信端末装置700は、上記所望年月日以後の見出し情報と、各々の見出し情報に対応するリンク情報と、各リンク情報に基づいて得られる内容データと、をそれぞれ取得し、後述するようなクリッピング処理を行なった後、それら情報を、上記ターゲットURLについての新着情報データとして、図46に示す新着情報データベース706に格納する。従って、例えば、図51において、インデックスページデータWNPに含まれる複数の見出し情報のうち、見出し情報α〜δが上記所望年月日以後に公開されており、見出し情報ε以降は全てそれ以前に公開されているものとすると、新着情報データベース706には、その見出し情報α〜δと、それらに対応するリンク情報a〜dと、それらにリンクされている内容データA〜Dと、を上記ターゲットURLについての新着情報データWNとして格納し、それ以外の情報は全て破棄する。
図52は図46の新着情報データベース706に格納される新着情報データの一例を示す説明図である。上記ターゲット新着情報データWNは、図52に示すように、見出し情報,リンク情報及び内容データ等を1組として各組毎に順番に配置され、さらに、情報IDとして、公開年月日の古い組から順に番号が付されている。なお、図52は新着情報データを概念的に示したものであり、実際のものとは相違する。
また、通信端末装置700は、新着情報データベース706に新着情報データWNを格納する際に、図51に示したインデックスページデータWNPも、比較対象データとして比較対象データ格納部708に併せて格納する。
4−3−2)新着情報を2回目以降取得する場合
続いて、2回目以降に新着情報を取得する場合は、次のように動作する。まず、通信端末装置700が、ターゲットURLに基づいて、WWWサーバ900にアクセスして、そこに格納されているインデックスページデータWNPが更新されているか否かをチェックし、更新されていれば、そのインデックスページデータWNPをWWWサーバ900より取り込む。
そして、通信端末装置700は、取り込んだインデックスページデータWNPを、比較対象データ格納部708に格納されている比較対象データ(即ち、前回取得したインデックスページデータWNP)と比較し、取り込んだデータのうち、比較対象データと重複する部分以外の部分を差分データとして取得する。
図53はWWWサーバに格納されている更新後のインデックスページデータと内容データとの関係の一例を示す説明図である。例えば、図53に示すように、前回の新着情報取得時点より、見出しデータωzが新たに追加されて、インデックスページデータWNPが更新されている場合、そのインデックスページデータWNPを、比較対象データ格納部708に格納されている図51に示したインデックスページデータWNP(即ち、比較対象データ)と比較すると、重複部分以外の部分は新たに追加された見出しデータωzの部分であるので、その見出しデータωzが差分データとして得られる。
次に、通信端末装置700は、差分データとして得られた見出しデータωzを解析して、図53に示す見出し情報ωと、それに対応するリンク情報zと、そのリンク情報zに基づいて得られる内容データZと、をそれぞれ取得し、後述するクリッピング処理を行なった後、それら情報を図46に示す新着情報データベース706に格納する。
図54は図46の新着情報データベース706に格納された更新後の新着情報データの一例を示す説明図である。上記した情報が新着情報データベース706に格納されると、上記ターゲットURLについての新着情報データWNには、図54に示すように、見出し情報ω,リンク情報z及び内容データZを1組とした情報が新たに追加され、その組には、情報IDとして、新たな番号「5」が付される。なお、図54は新着情報データを概念的に示したものであり、実際のものとは相違する。
また、通信端末装置700は、新着情報データベース706に上記した情報を格納する際に、図53に示したインデックスページデータWNPも、次回の比較対象データとして比較対象データ格納部708に併せて格納する。
以上のように、本実施例においては、WWWサーバによって公開されている新着情報について、データの更新を監視して、データの更新がなされている場合には、その差分データを取得して、新たな情報を得るようにしている。
4−4)エージェントデータについて
本実施例における通信端末装置700では、各ターゲットURL毎にエージェントがそれぞれ登録されており、主として、図46のエージェント実行部702が、ターゲットURL毎にエージェントを実行することによって、各ターゲットURLに格納されているデータの更新監視の動作を行なう。また、各エージェントの設定情報であるエージェントデータは、それぞれ、図55に示すような内容を持ち、新着情報データベース706に格納されている。なお、各エージェントの登録や、設定情報の変更などは、エージェント管理部710が、データ管理部704を介して行なう。
図55は第3の実施例で用いられるエージェントデータの内容を示す説明図である。図55において、1列目の欄はデータベースの属性を、2列目の欄は名称を、3列目の欄は意味を、それぞれ示している。なお、1列目の欄において、Iはインデクスを作成することを示し、Pはプライマリキーとなることを示している。
では、各行の項目の内容を説明する。
・エージェントIDはそのエージェントに対して一意に決まる番号である。
・無効フラグはデータ更新監視動作を実行するかしないかを示すフラグである。
・エージェント名は、そのエージェントに付けられた名称である。
・CSタイプは、データ更新の監視をローカル(クライアント)である通信端末装置700が自ら行なうか、後述するデータ更新監視サーバ800に行なってもらうのかを示すものである。
・監視タイプは、データ更新監視の動作として、新着情報の取得まで行なうか、単に更新チェックのみを行なうかを示すものである。
・チェック頻度IDはデータ更新監視動作を行なう頻度を表すものであり、例えば、0:毎時(1時間に1回)、1:毎日(1日1回)、2:毎週(1週間に1回)、3:毎月(1ヶ月に1回)とする。
・チェック頻度(日,週,月)は、曜日、日の情報を表すものである。
・チェック頻度(表示用)は、プロパティなどの表示用として、上記のチェック頻度の内容を文字列にしたものである。
・最終チェック日時は、最後にそのエージェントを実行した日時である。
・最終ステータスは、最後にそのエージェントを実行したときの状態を示すものである。例えば、更新チェックの際には、エラーやタイムアウト等のエラーになることがあり、そのような際に、そのエラー情報などが記される。
・URL−IDは、ターゲットURLに付けられたIDである。
・URL文字列は、ターゲットURLの文字列(http://.....)である。
4−5)URLデータについて
また、ターゲットURLに関連する情報も、URLデータとして、それぞれ、新着情報データベース706に格納されている。各URLデータは、それぞれ、図56に示すような内容を持っている。なお、本実施例では、ターゲットURLは、エージェントとそれぞれ一対一に対応するため、URLデータもエージェントとそれぞれ一対一に対応する。
図56は第3の実施例で用いられるURLデータの内容を示す説明図である。図56において、各列の欄は、図55に示した各列の欄と同様である。
では、図56における各行の項目の内容を説明する。なお、図55に示した項目と同じ項目については、内容も同じであるため、その説明は省略する。
・最終更新日時は、その更新監視対象データが最後に更新された日時である。その対象データを通信端末装置700が実際に取得した日時でなく、HTTPプロトコルによりWWWサーバより得た日時を記載する。WWWサーバがその対象データの更新日時を提供しない場合には、その更新監視対象データを通信端末装置700が取得した日時とする。
・最新情報IDは、通信端末装置700が取得した最新の情報IDである。後述するように、データ更新監視サーバ800にデータ更新の監視を行なってもらう場合などに用いられる。
・ユーザ名,パスワードは、WWWサーバにアクセスする際に使用するものである。WWWサーバによっては、更新監視対象データ等を取得するのに、ユーザ名とパスワードが必要な場合があるからである。
・内容のパス名は、比較対象データ格納部708に格納された比較対象データへのパス名である。比較対象データは特別のディレクトリに格納されており、パス名は、基準ディレクトリからその特別ディレクトリまでのパスと、比較対象データのファイル名と、で構成される。
・解析情報は、更新監視対象データを解析して、その対象データから各見出しデータ等を取り出すために用いる情報である。
4−6)新着情報テーブルについて
また、図52や図54に示したような新着情報データは、新着情報データベース706内において、図57に示すような内容の新着情報テーブルに格納される。
図57は第3の実施例で用いられる新着情報テーブルの内容を示す説明図である。図57において、各列の欄は、図55に示した各列の欄と同様である。
では、図57における各行の項目の内容を説明する。
・最新情報IDは、新着情報(見出し情報及び内容情報の1組)毎にユニークなIDである。
・取得日時は、その新着情報を取得した日時である。
・エージェントIDは、その新着情報の取得処理を実行したエージェントのIDである。
・エージェント名は、その新着情報の取得処理を実行したエージェントの名称である。エージェント名は、エージェントIDから取得できるが、高速化のために文字列を保持する。
・URL文字列は、ターゲットURLの文字列(http://.....)である。URLの文字列は、URL−IDから取得できるが、高速化のために持つ。
・URLタイトルは、ターゲットURLに格納されているページ(例えば、インデックスページ)の<TITLE>である。
・フォルダIDは、その新着情報が分類されているフォルダのIDである。
・フォルダ名は、上記フォルダの名称である。フォルダ名はフォルダIDから取得できるが、高速化のために文字列を保持する。
・見出しは、新着情報の見出しである。即ち、取得した見出し情報が格納される。
・リンク先URLは、新着情報の見出しにリンクしているURLである。即ち、見出し情報と共に取得したリンク情報が格納される。なお、リンク情報がない場合はNULLとする。
・既読フラグは、利用者がその新着情報の内容を見たか否かを示すフラグであるり、0:既読(内容を見た)、1:未読(見ていない)とする。新着情報を取得したときに、1にセットされ、利用者がその内容を見た時点で、0にリセットされる。
・CSタイプは、その新着情報がローカル(クライアント)である通信端末装置700自らが取得したのか、データ更新監視サーバに取得しもらったのかを示す。
・情報IDは、ターゲットURL毎に、新着情報データ内の新着情報に順番に次付けられるIDである。即ち、例えば、図52または図54に示したように、或るターゲットURLについての新着情報データにおいて、各新着情報(見出し情報及び内容情報の組)に、公開年月日の古いものから順に付される番号である。後述するように、データ更新監視サーバ800にデータ更新の監視を行なってもらう場合などに用いられる。
・情報内容は、新着情報の内容である。即ち、取得した内容データ(HTMLデータ)が格納される。新着情報の種類によって内容データが取得できない場合があるが、そのような場合には、代わりに、内容データのURL(即ち、リンク情報)の文字列を格納する。
また、新着情報データベース706には、エージェントデータ,URLデータ,新着情報テーブルの他に、フォルダテーブルも格納されている。このフォルダテーブルには、クリッピング処理の際に用いられるフォルダの名称やIDと、各フォルダ毎に設定されているキーワードなどの検索条件(クリッピング条件)が格納されている。なお、各エージェントには、通常、クリッピング処理を行なうためにフォルダが指定されている。
5−7)本実施例における通信端末装置の動作の詳細
それでは、本実施例の動作をさらに詳細に説明する。図58は図46に示す通信端末装置700における主な処理手順を示すフローチャートである。図58に示すように、まず、エージェント管理部710が、データ管理部704を介して、新着情報データベース706に格納されているエージェントデータの中から、処理すべきエージェントデータを1つ読み出して(ステップS220)、エージェント実行部702に渡す。次に、エージェント実行部702内のエージェント実行管理部720は、渡されたエージェントデータからチェック頻度の情報を取り出して、データ更新監視動作の実行時期に来ているかどうかを調べ、データ更新監視動作を実行する必要があるかどうかを判定する(ステップS222)。実行時期にまだ至らない場合には、データ更新監視動作を実行せず、ステップS234に進み、実行時期に来ている場合は、データ更新監視動作を実行すべく、ステップS224に進む。
ステップS224では、エージェントデータからCSタイプの情報を取り出して、その情報に基づいて、データ更新監視動作をローカル(即ち、クライアント)である通信端末装置700が自ら行なうのか、データ更新監視サーバ800に行なってもらうのかを判定する。データ更新監視サーバ800に行なってもらう場合は、後述するデータ監視サーバ対応処理(ステップS232)を実行し、通信端末装置700が自ら行なう場合は、ステップS226に進む。
ステップS226では、エージェントデータから監視タイプの情報を取り出して、その情報に基づいて、データ更新監視動作として新着情報の取得を行なうのか、単に更新チェックのみを行なうのかを判定する。更新チェックを行なう場合には、エージェント実行部702内の更新検出部724等が後述する更新チェック処理(ステップS230)を実行し、新着情報の取得を行なう場合には、エージェント実行部702内の各構成部が後述する新着情報取得処理(ステップS228)を実行する。
最後に、エージェント管理部710は、新着情報データベース706内に、処理すべきエージェントデータがあるかどうかを判定し(ステップS234)、ない場合は一連の処理を終了し、ある場合は再びステップS220に戻り、同様の処理を繰り返す。
4−7−1)新着情報取得処理について
図59は図58における新着情報取得処理の具体的な処理手順を示すフローチャートである。図59に示す処理ルーチンが開始されると、エージェント実行部702内のエージェント実行管理部720は、まず、データ管理部704を介して、新着情報データベース706に格納されているURLデータのうち、実行中のエージェントに対応するターゲットURLについてのURLデータを読み出す。そして、そのURLデータから更新監視対象データの最終更新日時の情報と比較対象データへのパス名の情報を取り出し、そのうち、パス名の情報に基づいて比較対象データ格納部708にアクセスし、格納されている比較対象データを読み出す(ステップS240)。
なお、このとき、比較対象データ格納部708に比較対象データが格納されていない場合には、ステップS262に進む。このような比較対象データが格納されていない場合としては、例えば、前述したような、新着情報を初めて取得する場合などが該当する。
次に、ネットワークアクセス部716が上記ターゲットURLに基づいてWWWサーバにアクセスし、エージェント実行部702内の更新検出部724が、ネットワークアクセス部716を介して、WWWサーバ内の更新監視対象データが更新されているかどうかをチェックする(ステップS244)。具体的には、最終更新日時をIF-Modified-Sinceヘッダとして、GETメソッドをWWWサーバに発行する。もし、更新監視対象データが更新されていれば、WWWサーバからその更新された更新監視対象データがネットワークアクセス部716によって自動的に取得される(ステップS246)。更新されていなければ、更新監視対象データは取得されないため、図59に示す処理ルーチンから抜ける。
なお、ヘッダ情報で最終更新日時の情報が取れなかった場合には、WWWサーバから更新監視対象データを取得し、その更新監視対象データの内容を比較対象データの内容と比較して、内容に変更があった場合には、データの更新があったものと見なす。このときの最終更新日時は、上記比較処理を実行した日時とする。
次に、エージェント実行管理部720は、上記ターゲットURLについて先に読み出したURLデータから解析情報を取り出し(ステップS248)、HTML解析エンジン728等に与える。
次に、差分解析エンジン726は、WWWサーバから取得したHTMLデータである更新監視対象データと比較対象データ格納部708から読み出したHTMLデータである比較対象データ(上記ターゲットURLについての比較対象データ)とを比較し、更新監視対象データのうち、比較対象データと重複する部分以外の部分を差分データとして導き出す(ステップS250)。即ち、この差分データがデータの更新された部分に該当する。
例えば、差分解析エンジン726は、差分解析用の命令に従って、まず、イメージデータ部分を除外するために、両者のHTMLデータからイメージデータへのリンクを示すIMGタグの部分を削除し、次に、両者のHTMLデータの差分を採り、その後、その差分の内容を出力する。
このような差分解析用の命令は、ターゲットURL毎に予め定義され、新着情報データベース706内に格納されている。また、ターゲットURLによっては、このような命令が定義されていない場合もあり、そのような場合には、すべてのHTMLデータに汎用的に利用できる命令を用いて、差分データを導き出すようにする。
続いて、HTML解析エンジン728は、導き出された差分データを解析情報に基づいて解析して、その差分データから新着情報の見出し情報とリンク情報(リンク先のURL)を切り出す(ステップS252)。なお、ターゲットURLによっては、解析情報がない場合もあり、そのような場合には、すべてのHTMLデータに汎用的に利用できる情報を用いて、解析を行なう。
次に、WWWサーバアクセス部722のリンク先内容データ取得部722aは、ネットワークアクセス部716を介して、切り出されたリンク情報に基づきWWWサーバにアクセスし、リンク先のURLから新着情報の内容データ(HTMLデータ)を取得する(ステップS254)。このとき、リンク先のURLに格納されているHTMLデータ内に、複数の内容データが含まれている場合には、上記解析情報に基づいて、必要な内容データのみを切り出して、取得するようにする。
なお、リンク先が、更新監視対象データの格納されていたWWWサーバ内ではなく、別のWWWサーバ内である場合には、リンク先の内容データを得るのに、改めて、そのWWWサーバにアクセスする必要が生じるので、そのような場合には、内容データを取得しないようにしても良い。
次に、クリッピングエンジン730は、実行中のエージェントに対して指定されているフォルダ毎にクリッピング処理を行なう(ステップS256)。即ち、指定されているフォルダ毎に、フォルダについて設定されている検索条件(クリッピング条件)を、データ管理部704を介して新着情報データベース706のフォルダテーブルから取り出し、取得した新着情報(即ち、見出し情報と内容情報の組)の一つ一つについて、検索条件に合致するかどうかを調べる(ステップS256)。例えば、或るフォルダについて設定されている検索条件が「インターネットかつイントラネット」である場合には、各新着情報の一つ一つについて、見出し情報または内容情報(内容データ)内に、「インターネット」,「イントラネット」の両方のキーワードが含まれているか否かを検索する。
そして、検索条件に合致する新着情報があった場合には、エージェント実行管理部720の書き込み部720aが、データ管理部704を介して、その合致する新着情報を新着情報データとして、新着情報データベース706内の新着情報テーブルに格納する(ステップS258)。その際、上記検索条件に合致した新着情報は、全て、その検索条件に対応するフォルダに属するものと考えて、書き込み部720aは、それら新着情報に、図57に示したように、付加情報として、その対応するフォルダ名を付加する。
なお、このようなクリッピング処理を行う際、キーワードとの一致を見る検索を行なうだけでなく、キーワードの類義語との一致も見るシソーラス検索を行うようにしても良い。
次に、エージェント実行管理部720の書き込み部720aは、データ管理部704を介して、比較対象データ格納部708に格納されている上記ターゲットURLについての古い比較対象データを削除し、ステップS246で取得した更新監視対象データを新たな比較対象データとして保存する(ステップS260)。以上の処理が終了したら、図59に示す処理ルーチンから抜ける。
以上説明したように、本実施例によれば、更新監視対象データにデータの更新があった場合には、更新部分に該当する差分データを取得し、さらに、そのリンクデータである内容データも取得することができる。
なお、本実施例では、新着情報として取得し新着情報データベース706に格納する情報はテキストデータのみであるが、本発明は、これに限るものではなく、画像データ、音声データ、スクリプトやプログラムなども、新着情報として取得するようにしても良い。
また、本実施例においては、差分データに含まれるリンク情報によってリンクされるリンクデータ(内容データ)を取得しているが、そのリンクデータにさらにリンク情報が含まれる場合には、そのリンク情報によってリンクされるリンクデータも併せて取得するようにしても良い。また、リンクがさらに何階層かある場合には、予め定められた階層までのリンクデータを併せて取得するようにしても良い。
また、本実施例では、ターゲットURLとエージェントとを一対一に対応させていたが、本発明は、これに限るものではなく、1つのターゲットURLに複数のエージェントを対応させるようにしても良いし、1つのエージェントに複数のターゲットURLを対応させるようにしても良い。
また、本実施例では、クライアントである通信端末装置700は、プロバイダ用サーバ750を介してインターネットに接続されているが、プロバイダ用サーバ等を介さず、直接、インターネットに接続するようにしていても良い。
ところで、図59に示すステップS240において、比較対象データ格納部708内に、実行中のエージェントに対応するターゲットURLについての比較対象データが格納されておらず、ステップS262に進んだ場合は、WWWサーバアクセス部722が、ネットワークアクセス部716を介して、上記ターゲットURLに基づきWWWサーバにアクセスし、更新監視対象データを取得する(ステップS262)。
次に、エージェント実行管理部720は、データ管理部704を介して、新着情報データベース706に格納されている上記ターゲットURLについてのURLデータを読み出し、そのURLデータから解析情報を取り出し(ステップS264)、HTML解析エンジン728等に与える。
次に、HTML解析エンジン728は、取得された更新監視対象データを解析情報に基づいて解析して、その更新監視対象データから新着情報の見出し情報とリンク情報をそれぞれ切り出す(ステップS266)。続いて、WWWサーバアクセス部722のリンク先内容データ取得部722aは、ネットワークアクセス部716を介して、切り出されたリンク情報に基づきWWWサーバにアクセスし、リンク先のURLから新着情報の内容データを取得する(ステップS268)。なお、このとき、新着情報としては、前述したように、利用者が希望する公開年月日以降の情報だけを取得するようにする。
その後は、ステップS256に進み、クリッピング処理以降の各処理を順次行なう。
4−7−2)新着情報の表示
以上のようにして、図58及び図59に示す一連の処理が終了すると、新着情報データベース706内には、各ターゲットURLについての新着情報データとして、最新の新着情報が格納されていることになる。そこで、ユーザI/F部712が、利用者からキーボード715やマウス717等を介して、或るターゲットURLについての新着情報を表示する旨の指示を受けると、エージェント実行管理部720の読み出し部720bは、データ管理部704を介して、新着情報データベース706から、そのターゲットURLについての新着情報データを読み出し、ユーザI/F部712を介して、モニタ713の画面上に新着情報を表示させる。表示の形態としては、例えば、まず、読み出し部720bが新着情報データベース706から、複数の見出し情報を分類しながら読み出して、それら見出し情報だけをツリー状にモニタ713の画面上に表示する。次に、表示された複数の見出し情報の中で、利用者が内容を見たい見出し情報をマウス717等でクリックすることにより選択したら、読み出し部720bは、その選択した見出し情報に付随するリンク情報に基づいて、新着情報データベース706から、選択した見出し情報に対応する内容データを読み出して、その内容データによりモニタ713の画面上に内容情報を表示するようにする。
図60は図46におけるモニタ713の画面上に表示される新着情報の一例を示す説明図である。画面中の左側の領域には、複数の見出し情報が読み出し部720bによって各カテゴリー毎に段階的に分類されて、ツリー状に表示されている。そして、画面中の右側の領域には、利用者によって選択された“「DiskXplorer for Windows」 を発表”という見出し情報について、その内容情報が表示されている。なお、見出し情報を分類するためのカテゴリーとしては、図57の新着情報テーブルにおいて説明したような「日時」,「URL」,「URLタイトル」,「フォルダ」などが挙げられる。
図61は複数の見出し情報をツリー状に表示した場合の表示例を示す説明図である。図61では、ツリーの第1レベルを「日付」による分類(1996/11/14,1996/11/15など)とし、第2レベルを「フォルダ」による分類(インターネット,マルチメディアなど)とし、第3レベルを「URLタイトル」による分類(○○○のホームページ,×××のホームページなど)としている。このような場合において、例えば、図61に示す見出し情報A,Bは、次のような絞り込み検索によって、分類され画面上に表示されている。即ち、読み出し部720bが、新着情報データベース706内の新着情報テーブルに格納されている全ての見出し情報の中から、「日付」が“1996/11/15”である見出し情報を検索により抽出し、得られた見出し情報の中から「フォルダ」が“インターネット”である見出し情報を抽出し、さらに、得られた見出し情報の中から「URLタイトル」が“○○○のホームページ”である見出し情報を抽出して、モニタ713の画面上に表示させる。なお、ツリーの各レベルをどの様なカテゴリーによる分類とするかは、上記したようなカテゴリーの中から自由に設定することができる。
4−7−3)更新チェック処理
図62は図58における更新チェック処理の具体的な処理手順を示すフローチャートである。図62に示す処理ルーチンが開始されると、エージェント実行管理部720が、まず、データ管理部704を介して、新着情報データベース706に格納されているURLデータのうち、実行中のエージェントに対応するターゲットURLについてのURLデータを読み出し、そのURLデータから更新監視対象データの最終更新日時の情報を取り出す。そして、ネットワークアクセス部716がターゲットURLに基づいてWWWサーバにアクセスし、更新検出部724が、取り出された最終更新日時の情報に基づいて、WWWサーバ内の更新監視対象データが更新されているかどうかをチェックする(ステップS270)。
そして、更新検出部724は、更新監視対象データが更新されていれば、WWWサーバからその更新日時を取得して、データ管理部704を介して、新着情報データベース706内における上記ターゲットURLについてのURLデータ内の最終更新日時を変更する(ステップS272)。さらに、更新監視対象データが更新されたことを示す情報を作成し(ステップS274)、その情報を新たな見出し情報として、新着情報データベース706内の新着情報データテーブルに格納する(ステップS276)。また、更新監視対象データが更新されていなければ、そのまま、図62に示す処理ルーチンから抜ける。
こうして、新着情報の取得ではなく、単に、更新チェックのみを行なった場合は、更新監視対象データについての最終更新日時が変更されると共に、更新監視対象データが更新されたことを示す新たな見出し情報が、新着情報データに追加される。従って、この新着情報データに基づいてモニタ713の画面上に新着情報として複数の見出し情報を表示すると、他の見出し情報と共に、更新監視対象データが更新されたことを示す見出し情報が表示されることになる。
また、更新監視対象データが更新されている場合、新着情報データベース706内の新着情報データテーブルには、更新監視対象データが更新されたことを示す見出し情報を格納するだけでなく、次のような情報も併せて格納するようにしても良い。即ち、WWWサーバから、更新監視対象データの更新日時を取得するだけでなく、更新された更新監視対象データ自体も取得して、その上で、新着情報データベース706内の新着情報データテーブルには、更新監視対象データが更新されたことを示す情報を見出し情報として格納すると共に、取得した更新監視対象データも内容データとして格納するようにする。なお、このとき、上記見出し情報に上記内容データをリンクさせるためにリンク情報も併せて格納するようにする。このようにすることによって、モニタ713の画面上に新着情報を表示した際に、利用者が更新監視対象データが更新されたことを示す見出し情報を選択すると、その見出し情報についての内容情報として、更新監視対象データ自体の内容(インデックスページ)が表示されることになる。
5)データ更新監視サーバの別の実施例
図63は本発明の第4の実施例としてのデータ更新監視サーバの構成を示すブロック図、図64は図63のエージェント実行部802の構成を示すブロック図である。本実施例のデータ更新監視サーバ800は、インターネット上の所望のWWWサーバに対する格納データの変更の有無を監視することが可能なサーバである。即ち、本実施例では、クライアントである通信端末装置に代わって、データ更新監視サーバ800がデータ更新監視動作を行なう。
5−1)本実施例のデータ更新監視サーバの構成
図63に示すように、このデータ更新監視サーバ800は、エージェント実行部802を中心として、データ管理部804と、新着情報データベース806と、比較対象データ格納部808と、エージェント管理部810と、ユーザI/F部812と、モニタ813と、スケジュール管理部814と、キーボード815と、ネットワークアクセス部816と、マウス817と、リクエスト処理部818と、クリッピングエンジン830と、データ加工エンジン840を備えており、このうち、リクエスト処理部818がWWWサーバ850を介してインターネットに、ネットワークアクセス部816が直接インターネットに接続されている。なお、図63において、図46に示した構成要素と同じ構成要素には、同じ番号を付してある。従って、図63に示すクライアント700は、図46で示した通信端末装置700に相当する。
また、エージェント実行部802は、図64に示すように、エージェント実行管理部820と、WWWサーバアクセス部822と、更新検出部824と、差分解析エンジン826と、HTML解析エンジン828と、を備えている。このうち、エージェント実行管理部820は書き込み部820aと読み出し部820bを備えている。WWWサーバアクセス部822はリンク先内容データ取得部822aを備えている。
本実施例のデータ更新監視サーバ800は、図2に示したようなコンピュータによって構成されており、図63に示すデータ更新監視サーバ800内の各ブロックは、ハードウェアにより実現されている部分とソフトウェアにより実現されている部分とを含んでいる。
ソフトウェア部分については予めアプリケーションプログラムの形で図2に示したハードディスク84に記憶されており、利用者から起動の指示がなされて、オペレーティングシステムによってハードディスク84からメインメモリ25上に読み込まれることによって、ハードウェアとソフトウェアが一体となった図63に示すデータ更新監視サーバ800が実現する。
また、上記アプリケーションプログラムが図2に示すCD−ROM85に記録されている場合には、このCD−ROM85をCD−ROM装置83に挿入し、上記アプリケーションプログラムをCD−ROM装置83で読み取ることによって、メインメモリ25に転送するようにしても良い。また、上記アプリケーションプログラムが図2に示すフロッピディスク81に記録されている場合には、このフロッピディスク81をフロッピディスク装置82に挿入し、上記アプリケーションプログラムをフロッピディスク装置82で読み取ることによって、メインメモリ25に転送するようにしても良い。また、上記アプリケーションプログラムは光磁気ディスクなどの他の可搬型記録媒体上からメインメモリ25に転送するようにしても良い。
また、上記アプリケーションプログラムが図2に示すプログラム供給サーバ9000に格納されている場合には、モデム92によって通信回線93を介してプログラム供給サーバ9000にアクセスし、プログラム供給サーバ9000から上記アプリケーションプログラムを送信してもらうことによって、メインメモリ25に転送するようにしても良い。なお、通信回線93としては、電話回線やネットワーク回線などの有線回線の他、通信衛星などを利用した無線回線などが考えられる。
本実施例のデータ更新監視サーバ800は、図63及び図64に示すように、図46及び図47に示した通信端末装置700と構成がほとんど同じであるが、サーバアクセス部718の代わりにリクエスト処理部818が設けられた点と、クリッピングエンジン830がエージェント実行部の内部でなく、エージェント実行部802とリクエスト処理部818の間に配置されている点と、新たにデータ加工エンジン840が設けられ、エージェント実行部802とリクエスト処理部818の間に配置された点で異なる。
では、データ更新監視を、図46に示したクライアントである通信端末装置700に代わって、図63に示すデータ更新監視サーバ800が行なう場合の動作について説明する。
5−2)クライアントである通信端末装置側の動作
図65は図58におけるデータ監視サーバ対応処理の具体的な処理手順を示すフローチャートである。前述したように、図46に示した通信端末装置700において、エージェントデータから取り出したCSタイプの情報が、データ更新監視動作のデータ更新監視サーバによる実行を示している場合(図58のステップS224)、データ監視サーバ対応処理(ステップS232)として、図65に示す処理ルーチンが開始される。
まず、エージェント実行管理部720が、リクエストデータを作成してサーバアクセス部718に渡し、サーバアクセス部718は、そのリクエストデータをHTTP(ハイパー・テキスト・トランスファ・プロトコル)リクエストとして、ネットワークアクセス部716を介してデータ更新監視サーバ800に送信する(ステップS280)。
図66はクライアントである通信端末装置からデータ更新監視サーバへ送信されるリクエストデータの内容を示す説明図である。図66において、1列目の欄はHTTPでの名称を、2列目の欄は名称を、3列目の欄は意味を、それぞれ示している。
では、各行の項目の内容を説明する。
・ユーザIDとパスワードは、データ更新監視サーバ800にアクセスするために各利用者に与えられたユーザ識別用IDとパスワードである。これらは予めデータ更新監視サーバ800に登録されている。
・チェックするURLは、利用者がデータ更新監視を希望しているターゲットURLの文字列である。
・処理種別は、データ更新監視サーバ800に実行してもらう処理の種別(新着情報取得か更新チェックか)を示すものである。
・最終取得情報IDは、そのターゲットURLについて取得している新着情報データ内の新着情報の中で、最も新しい新着情報のIDである。
・最終取得日時は、そのターゲットURLについて新着情報を最後に取得した日時である。
・最終チェック日時は、そのターゲットURLについて最後にチェックした日時である。
・フォルダ数は、実行中のエージェントに対して指定されているフォルダの数である。
・フォルダ情報は、各フォルダのIDとキーワード(即ち、検索条件)である。
・クライアントの種類は、後述するように、クライアントである通信端末装置700がパソコンではなく、通信機能を備えた携帯情報機器(PDA;Personal Digital Assistant)やプリンタである場合に、そのPDA,プリンタの機種やバージョンなどを示す情報である。
・加工情報1は、クライアントがプリンタである場合に、プリンタで用いている印刷用紙のサイズや紙質や向きなどの情報である。
・加工情報2は、クライアントがプリンタである場合に、データ更新監視サーバ800で行なわれる色補正処理に対する指示内容である。
・加工情報3は、クラアイアンがプリンタである場合に、データ更新監視サーバ800で行なわれる2値化処理に対する指示内容である。
・位置情報は、クライアントがPDAである場合に、そのPDAが存在する位置の情報である。具体的には、例えば、利用者がそのPDAを携帯してどの市や町にいるかを表す情報である。
なお、クライアントがプリンタやPDAである場合には、上記情報のほか、画像の解像度やカラー表地色数などの情報を含むようにしても良い。
従って、以上説明したリクエストデータの内容を要約すると、「ターゲットURLは×××です。当方では、既に情報ID×××番(即ち、最終取得情報ID)までの新着情報を既に取得しています。フォルダの数は×××個あります。1個目のフォルダについてのフォルダ情報(即ち、検索条件)は×××です。2個目のフォルダについてのフォルダ情報(即ち、検索条件)は×××です。……。クライアントの種類は×××で、加工情報は×××です。……」となる。
5−3)データ更新監視サーバ側の動作
クライアントである通信端末装置700から送信されたリクエストデータは、インターネットに接続されているWWWサーバ850を介して、データ更新監視サーバ800に受信される。WWWサーバ850は、一般的なWWWサーバであり、クライアントからのリクエストデータを受け付け得る。具体的には、そのWWWサーバ850内の特定のURLへのアクセスが、データ更新監視サーバ800へのリクエストであると判定されるようになっており、そのリクエストによってデータ更新監視サーバ800内のリクエスト処理部818が起動される。
図67は図63に示すデータ更新監視サーバ800における主な処理手順を示すフローチャートである。データ更新監視サーバ800では、通信端末装置700から送信されたリクエストデータを受信すると、リクエスト処理部818がそれを処理して、リクエストデータの内容をエージェント実行部802に伝える。そして、図67に示すように、まず、エージェント実行部802内の各処理部が、そのリクエストデータに基づいて、前述した通信端末装置700の場合と同じ様な(図59に示した様な)処理手順で新着情報取得処理を行なう(ステップS290)。但し、データ更新監視サーバ800の場合は、新着情報を新着情報データベースへ格納するに際して、クリッピング処理は行なわず、全ての新着情報を新着情報データベース806に格納するようにする。これは、クリッピング処理を行なう際の検索条件がクライアント毎(即ち、利用者毎)に異なるためである。従って、データ更新監視サーバ800では、クリッピング処理は後述するように各クライアントに新着情報を送信する際に行なう。
こうして、ターゲットURLについて新着情報取得処理を行なうことによって、ターゲットURLの更新監視対象データが更新されている場合には、その更新により得られる新着情報が新着情報データベース806に格納され、データの更新内容が新着情報データベース806にも反映されることになる。
次に、エージェント実行部802のエージェント実行管理部820は、受信したリクエストデータから最終取得情報IDを得て、新着情報データベース806内に格納されているターゲットURLについての新着情報データから、その最終取得情報IDよりも番号の大きい情報IDを持つ新着情報を一つ読み出す(ステップS292)。クライアントである通信端末装置700は、最終取得情報IDと同じかそれよりも小さい番号を持つ新着情報については、既に所有しており、それら以外の未だ所有していない新着情報のみを欲しているからである。なお、新着情報を読み出す順番は、情報IDの番号の小さいものからとする。
次に、リクエスト処理部818は、受信したリクエストデータからフォルダ情報を得て、クリッピングエンジン830に渡し、クリッピングエンジン830は、読み出された新着情報に対し、受け取ったフォルダ情報に基づいてクリッピング処理を行なう(ステップS294)。即ち、その新着情報がフォルダ情報に含まれる検索条件(クリッピング条件)に合致するかどうかをチェックする。そして、検索条件に合致しない場合には、その新着情報を通信端末装置700に送信する必要がないので、ステップS298に進む。
一方、新着情報が検索条件に合致した場合には、リクエスト処理部818が、その新着情報をHTMLデータにして、WWWサーバ850を介して、クライアントである通信端末装置700に送信する(ステップS296)。
そして、エージェント実行部802のエージェント実行管理部820は、新着情報データベース806内のターゲットURLについての新着情報データに、最終取得情報IDよりも番号の大きい情報IDを持つ新着情報があるかどうかを判定し(ステップS298)、ある場合には再びステップS290に戻り、同様の処理を繰り返す。また、ない場合は一連の処理を終了する。なお、順番に読み出された新着情報のうち、最後に読み出された新着情報の情報IDが後述する最終チェックIDとなる。
図68はデータ更新監視サーバからクライアントである通信端末装置へ送信される新着情報送信データの内容を示す説明図である。図68において、1列目の欄は名称を、2列目の欄は意味を、それぞれ示している。
では、各行の項目の内容を説明する。
・ステータスは、データ更新監視サーバが更新監視動作を実行したときの実行結果の状態を示すものである。
・最終更新日時は、ターゲットURLの更新監視対象データが最後に更新された日時である。
・最終チェック情報IDは、前述したように、そのターゲットURLについて、新着情報データベース806から最後に読み出された新着情報の情報IDである。
・取得情報IDは、取得されたその新着情報の情報IDである。
・情報種別は、その新着情報が差分データから得られたものであるか、ページデータから得られたものであるかの別を示すものである。
・タイトルは、その新着情報に含まれる見出し情報である。具体的には、見出し情報の他、リンク情報を含む見出しデータ(HTMLデータ)である。
・フォルダIDは、その新着情報について検索条件が合致したフォルダのIDである。
・リンク先内容は、新着情報に含まれる内容情報である。なお、内容情報がない場合には、その内容情報の格納場所を示すリンク情報が送信される。
以上の各項目のうち、「最終更新日時」以降の各項目は、ステータスがデータ更新有りの場合にのみ送信される。また、「取得情報ID」以降の各項目は、取得した新着情報毎に繰り返される。
従って、以上説明した新着情報送信データの内容を要約すると、「データ更新監視動作を実行した結果は○○○です。今回は情報ID○○○番(即ち、最終チェック情報ID)までの新着情報をチェックしました。フォルダの検索条件に合致した新着情報は○○○個あります。1個目の新着情報は、フォルダID○○○番の検索条件に合致した○○○です。2個目の新着情報は、フォルダID○○○番の検索条件に合致した○○○です。……」となる。
5−4)クライアントである通信端末装置側の動作
データ更新監視サーバ800から送信された新着情報送信データは、インターネットに接続されているプロバイダ用サーバ750を介して、クライアントである通信端末装置700に受信される。
通信端末装置700では、図65に示すように、データ更新監視サーバ800から送信された新着情報送信データを受信すると(ステップS282)、エージェント実行部702が、その新着情報送信データから新着情報を取り出して、データ管理部704を介して新着情報データベース706に格納する(ステップS284)。その後は図65に示す処理ルーチンから抜ける。
以上説明したように、本実施例によれば、クライアントである通信端末装置の代わりに、データ更新監視サーバがデータ更新監視の動作を行なうことができる。従って、クライアント自ら、更新監視対象データについて更新有無を調べたり、新着情報を取得したりしなくても、データ更新監視サーバが全て代行するので、クライアントを利用する利用者の手間が大幅に省けると共に、通信時間も短くて済む。
なお、本実施例においては、新着情報として、見出し情報の他に、その内容情報もクライアントに送信しているが、見出し情報だけをクライアントに提供し、内容情報については送信しないようにしても良い。
また、本実施例では、データ更新監視サーバ800においてクリッピング処理を行なう際に用いるフォルダ情報(即ち、検索条件など)は、利用者毎に、クライアントである通信端末装置700が、毎回、リクエストデータに含ませて、データ更新監視サーバ800に伝えているが、予め、利用者毎に、データ更新監視サーバ800に登録しておき、必要に応じて読み出すようにしても良い。
5−5)データ更新監視動作の実行時期
本実施例では、データ更新監視サーバ800は、クライアントからのリクエストデータを受信した際に、ターゲットURLについて新着情報取得などのデータ更新監視動作を行なう。しかし、クライアントからのリクエストデータの送信の有無に関係なく、所定の時刻が来たら、バッチ処理的に全てのターゲットURLについてデータ更新監視動作を行なうようにしても良い。例えば、このようなデータ更新監視動作を、ネットワーク回線の空いている深夜などに行なうようにすれば、非常に効率よくデータ更新監視動作を行なうことができる。なお、このようなデータ更新監視動作の定期的な実行は、スケジュール管理部814によって管理される。
6)データ更新監視サーバのイントラネットでの利用
上記した実施例においては、データ更新監視サーバ800は、図63に示したように、インターネットにおいて利用されている。しかし、図69に示すように、WANあるいはLANにおいて構築されるイントラネット(Intranet)において利用するようにしても良い。
図69はデータ更新監視サーバをイントラネットで利用する場合の接続形態の一例を示す説明図である。図69に示す例では、社内LANにイントラネットを構築している。そのイントラネットには、社内の各クライアント1700,1710が接続される他、社内用WWWサーバ1900が接続されている。また、そのイントラネットはファイアーウォール2100を介してインターネットに接続されている。
以上のような社内イントラネットに、図63で示したような構成を持つデータ更新監視サーバ1800を接続すると、以下のようなメリットが得られる。
●イントラネットの外部へのトラフィックを低減できる。
即ち、社内イントラネットにデータ更新監視サーバ1800がない場合には、社内の各クライアント1700,1710は、クライアント毎に、更新監視対象データの格納されているインターネット上のWWWサーバ2200,2210にアクセスして、データの更新があるかどうかをチェックする必要があり、イントラネットの外部に対するアクセス数が多くなり、その分、外部へのトラフィックが増大する。しかし、社内イントラネットにデータ更新監視サーバ1800を設け、これを利用することによって、更新監視対象データについて、新着情報があるかどうかは、イントラネット内の上記サーバ1800へアクセスするだけでわかるので、イントラネット外部へのトラフィックを低減することができる。
●社内用WWWサーバ内の社内向けデータについても更新監視が可能である。
即ち、データ更新監視の対象として、社内用WWWサーバ1900内の社内向けデータを設定することにより、社内向けデータについても新着情報を社内の各クライアントに提供することができる。
●情報配信のインフラとして利用できる。
社内イントラネットのネットワーク管理者等が、社内に配信したい情報を新着情報としてデータ更新監視サーバ1800内に直接登録することにより、その情報を自動的に社内に配信することができるため、効率的な情報配信システムを構築することができる。具体的には、キーボード815やマウス817等によって入力された配信したい情報を、エージェント実行管理部820の書き込み部820aが新着情報データベース806に書き込むことによって、新着情報として登録し、その後、エージェント実行管理部820の読み出し部820bが、新着情報として登録された配信したい情報を読み出し、リクエスト処理部818が、その情報を社内イントラネットを介して社内の各クライアント1700,1710などに転送するようにする。
なお、以上の各メリットは社内イントラネットに限りものではなく、一般的なイントラネットにおいても同様に得ることができる。
7)データ更新監視サーバにおけるデータの加工
ところで、前述の図63で示したような実施例においては、クライアントである通信端末装置700がパソコンなどによって構成されているが、前述したように、通信機能を備えたPDAやプリンタなどによって構成するようにしても良い。
図70は図63に示すデータ更新監視サーバ800に対し、クライアントとしてPDAやプリンタを用いた場合の接続例を示す説明図である。図70において、プリンタ1850及びPDA1910は、それぞれ、インターネットに接続するための通信機能を備えている。そして、この例では、プリンタ1850は直接、PDA1910はプロバイダ用サーバ1950を介して、それぞれインターネットに接続されている。
図70に示すように、クライアントとしてPDA1910やプリンタ1850を用いる場合、クライアントからデータ更新監視サーバ800へ送信されるリクエストデータには、図66で説明したように、「クライアントの種類」や「加工情報」などの情報が含まれている。そこで、データ更新監視サーバ800では、送信されてきたリクエストデータを受信すると、リクエスト処理部818が、そのリクエストデータから上記した各情報を得て、データ加工エンジン840に渡し、データ加工エンジン840は、新着情報送信データをクライアントに送信する際に、リクエスト処理部から受け取った各情報を元にして、新着情報送信データに、クライアントの種類に応じて所定の加工を施す。
なお、データ加工エンジン840における加工処理において必要な情報のうち、クライアントから送信されてこない情報については、リクエスト処理部818が予め所持しており、必要に応じてデータ加工エンジン840に渡すようになっている。
図71は図63におけるデータ加工エンジン840の構成を示すブロック図である。図71に示すように、データ加工エンジン840は、加工管理部842と、プリンタドライバ部844と、PDAドライバ部846と、を備えている。 このうち、プリンタドライバ部844は、レンダリング部844aと、色補正処理部844bと、色変換処理部844cと、2値化処理部844dと、データ圧縮処理部844eと、を備えており、また、PDAドライバ部846は、減色処理・間引き処理部846aと、フォーマット変換処理部846bと、データ圧縮処理部846cと、を備えている。
なお、図71では、データ加工エンジン840が、プリンタドライバ部844,PDAドライバ部846をそれぞれ一つずつしか備えていないが、クライアントとなり得るプリンタやPDAの各機種にそれぞれ対応するように、機種毎に、プリンタドライバ部やPDAドライバ部を備えるようにしても良い。
例えば、クライアントがPDA1910である場合、データ加工エンジン840の加工管理部842は、リクエスト処理部818から受け取った「クライアントの種類」の情報によって、クライアントがPDAであることを認識すると、PDAドライバ部846を起動する。
PDAドライバ部846では、減色処理・間引き処理部846aが、送信される新着情報送信データのうち、画像データに対しては、減色処理やピクセル情報の間引き処理などを行なって、PDA1910に送信されるデータの量を減らす。
次に、フォーマット変換処理部846bが、送信される新着情報送信データに対して、次のようなフォーマット変換処理を施す。即ち、一般にPDA1910は表示画面が小さいので、画面の横方向の桁数が、PDA1910で横スクロールすることなく表示できる桁数となるように、データを整形して、小さい画面でも利用者が見やすくなるようにする。また、一般にPDA1910は記憶容量も少なく処理能力も劣るので、大量のデータをPDA1910に送信しなくて済むように、データを加工して、送信内容として要約のみを送るようにする。
次に、データ圧縮処理部846cが、送信される新着情報送信データにデータ圧縮処理を施して、データ自体(例えば、HTMLデータ自体)を圧縮する。なお、このデータ圧縮処理部846cによる処理は、必要な場合にのみ行なうようにしても良い。
一方、例えば、クライアントがプリンタ1850である場合、データ加工エンジン840の加工管理部842が、「クライアントの種類」の情報によってクライアントがプリンタであることを認識すると、プリンタドライバ部844を起動する。
プリンタドライバ部844では、まず、レンダリング部844aが、送信される新着情報送信データをR(赤),G(緑),B(青)のビットマップ画像データに展開すると共に、必要に応じてデータの間引き処理や補間処理を行なう。また、このとき、リクエスト処理部818から受け取った「加工情報1」(すなわち、印刷用紙のサイズなどの情報)に基づいて、書式変換などの処理も併せて行なう。
次に、色補正処理部844bが、リクエスト処理部818から受け取った「加工情報2」(すなわち、色補正処理に対する指示内容)に基づいて、レンダリング部844aからのビットマップ画像データに対し、γ補正などの色補正処理を行なう。なお、この色補正処理部844bによる処理は、必要な場合にのみ行なうようにしても良い。
次に、色変換処理部844cが、「クライアントの種類」の情報に基づき、プリンタの種類に応じて次のような色変換処理を行なう。即ち、プリンタ1850がカラープリンタである場合には、R,G,Bの色画像データをC(シアン),M(マゼンタ),Y(黄),K(黒)やC(シアン),M(マゼンタ),Y(黄)の色画像データに変換し、また、プリンタ1850がモノクロプリンタである場合は、R,G,Bの色画像データをモノクロ画像データに変換する。
次に、2値化処理部844dが、リクエスト処理部818から受け取った「加工情報3」(すなわち、2値化処理に対する指示内容)に基づいて、色変換処理部844cから得られた多値の画像データに対し、ディザ処理や誤差拡散処理などの2値化処理を行なって、2値の画像データを得る。
次に、データ圧縮処理部844eが、得られた2値の画像データに対してデータ圧縮処理を施して、データ自体を圧縮する。なお、このデータ圧縮処理部844eによる処理は、必要な場合にのみ行なうようにしても良い。
なお、プリンタドライバ部844では、必要に応じて、情報の途中でページが切れないように改ページを挿入するような処理を施すようにしても良い。
このように、クライアントがプリンタ1850である場合、以上のような色変換処理や2値化処理やデータ圧縮処理を施すことによって、データ更新監視サーバ800からプリンタ1850へ送信されるデータの量を大幅に減らすことができる。色変換処理や2値化処理などの複雑な処理を、処理能力の高いデータ更新監視サーバにおいて行なっているので、プリンタ1850で用いられるCPUは、処理能力の低いCPUでも、十分間に合う。また、画像データを記憶する画像メモリも、例えば2ライン分のメモリで済むため、構成が簡素化されると共に、コストも安価で済む。
さて、データ更新監視サーバ800のリクエスト処理部818は、以上のようにして加工された新着情報送信データを、WWWサーバ850を介してインターネットに送り、プリンタ1850或いはPDA1910はこれを直接受信する。このうち、プリンタ1850では、受信した新着情報送信データをそのままプリンタエンジンに流して、表示文字と画像を印刷用紙に印刷する。また、PDA1910では、受信した新着情報送信データに基づいて画面上に情報を表示する。
なお、データ更新監視サーバ800は、上記したように、加工した新着情報送信データをインターネットを介して直接プリンタ1850或いはPDA1910に直接送信するようにしても良いが、インターネットにWWWサーバ1650,1750を介して接続されたプリンタ専用サーバ1600やPDA専用サーバ1720に送り、これら専用サーバ1600,1720からインターネットを介してクライアントであるプリンタ1850,PDA1910に送るようにしても良い。
ところで、図66で説明したように、クライアントとしてPDAを用いる場合、クライアントから送信されるリクエストデータには、「位置情報」が含まれている。この位置情報は、前述したように、クライアントであるPDAの存在する位置の情報を表している。そこで、データ更新監視サーバ800では、このPDAの位置情報を用いて、クリッピングエンジン830において、次のような処理を行なうようにしても良い。
まず、リクエスト処理部818が、クライアントから送信されてきたリクエストデータから上記した位置情報を得ると、その情報をクリッピングエンジン830に渡す。クリッピングエンジン830では、このような位置情報を受け取ると、その位置情報に関連した情報を、新着情報データベース806から読み出される新着情報の中から検索して、情報をリクエスト処理部818に渡す。リクエスト処理部818では、受け取った情報をWWWサーバ850を介して、クライアントであるPDA1910に送信するようにする。
なお、このとき、位置情報に関連した情報としては、例えば、新聞社等のWWWサーバから得られたニュースなどの情報が考えられる。即ち、新着情報データベース806内に、地方の新聞社を含む全国の新聞社のWWWサーバから取得した新着情報が格納されているものとすると、PDAの利用者が或る地方に出かけた場合に、PDAがその地方の位置情報をリクエストデータとしてデータ更新監視サーバ800に送ることによって、データ更新監視サーバ800からは、その地方の新聞社のWWWサーバから取得したローカルニュースが送信され、その地方のニュースを直ちに知ることができる。
8)メール配信システム
図72は本発明の第5の実施例としての、データ更新監視サーバを利用したメール配信システムの構成を示すブロック図である。本実施例のメール配信システムは、図72に示すように、データ更新監視サーバ800とメール配信サーバ1500とを備えている。このうち、データ更新監視サーバ800は図63で示したデータ更新監視サーバである。一方、メール配信サーバ1500は、インターネットを介して電子メールを配信することが可能なサーバである。
図72において、メール配信サーバ1500は、ユーザ管理部1502と、配信制御部1504と、メール配信部1506と、リクエスト処理部1508と、新着情報取得部1510と、ユーザデータ格納部1512と、スケジュール管理部1514と、を備えており、このうち、リクエスト処理部1508がWWWサーバ1550を介してインターネットに、メール配信部1506と新着情報取得部1510が直接インターネットに接続されている。
図72において、メール配信サーバ1500におけるユーザデータ格納部1512には、このメール配信システムを利用する各利用者の情報が格納されている。利用者の情報としては、例えば、各利用者のユーザID、パスワード、メールアドレスなどの他、各利用者のデータの更新監視を希望するターゲットURLや、クリッピング処理に用いるフォルダ情報などが挙げられる。ユーザ管理部1502は、それら情報を用いて利用者の管理、新着情報の取得、メール配信などを行なう。
利用者が、登録されたターゲットURLやフォルダ情報の変更などを行なう場合は、インターネットに接続されたクライアントである通信端末装置700等を用いて、メール配信サーバ1500にアクセスし、リクエストを送信する。メール配信サーバ1500では、クライアント700からのリクエストを受信すると、リクエスト処理部1508がそれを処理して、リクエストの内容をユーザ管理部1502に伝える。ユーザ管理部1502では、そのリクエストに応じてユーザデータ格納部1512内に格納された利用者の情報の変更などを行なう。
また、メール配信サーバ1500では、スケジュール管理部1514による時間管理の下で、新着情報取得部1510が、データ更新監視サーバ800に定期的にアクセスする。そして、ユーザデータ格納部1512に登録されている各ターゲットURLについての新着情報を、データ更新監視サーバ800より取得する。この時、データ更新監視サーバ800は、新着情報をHTMLデータからテキストデータに変換してメール配信サーバ1500に渡す。
そして、取得した新着情報を、メール配信部1506は、配信制御部1504による制御によって、取得した新着情報を、電子メールを用いて定期的に、クライアント700をはじめとする各クライアントに配信する。なお、配信制御部1504は、新着情報を配信する際には、配信先の各利用者に対応したクリッピング処理を行なった上で、新着情報を配信するようにしても良い。
以上のように構成することによって、利用者が更新監視を希望するターゲットURLの新着情報は、定期的に、利用者の元に配信されるので、利用者自らがデータ更新監視サーバ800にアクセスして、新着情報を取得する手間が省ける。
なお、本実施例においては、新着情報の配信を電子メールを用いて行っていたが、電話やファクシミリなどを用いて行っても良いし、或いは、有線放送や衛星放送などを利用して行っても良い。
本発明は上記した実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様にて実施することが可能である。
例えば、上記した実施例のうち、第3ないし第5の実施例では、データの更新監視を行なうべき情報として、「What'new」などの新着情報を例として説明したが、本発明は、これに限定されるものではなく、種々の情報を対象とすることができる。