JP2005025431A

JP2005025431A - 情報保管システム、情報保管方法、および情報保管プログラム

Info

Publication number: JP2005025431A
Application number: JP2003189310A
Authority: JP
Inventors: Akihiro Mizutani; 昭弘水谷
Original assignee: Toshiba Corp; Toshiba TEC Corp
Current assignee: Toshiba Corp; Toshiba TEC Corp
Priority date: 2003-07-01
Filing date: 2003-07-01
Publication date: 2005-01-27

Abstract

【課題】信頼性および利便性を高める。
【解決手段】所定のコンテンツ提供システムから提供されたコンテンツを所定のコンテンツ保管部に保管しておき、ユーザが通信端末から出力要求を送信してきたときには、コンテンツを通信端末へ供給する情報保管システムにおいて、コンテンツ提供システムと通信することにより、コンテンツ提供システムから提供されるコンテンツの更新が行われたことを検出するコンテンツ更新検出部または、すでにコンテンツ保管部に保管されているコンテンツに付随する制御情報を検査することにより、コンテンツの更新が行われると予想される時期を検出するコンテンツ更新推測部のいずれかを備え、コンテンツ更新検出部またはコンテンツ更新推測部による検出結果を、ユーザに通知する更新情報通知部を有する。
【選択図】図５

Description

【０００１】
【発明の属する技術分野】
本発明は情報保管システム、情報保管方法、および情報保管プログラムに関し、例えば、コンテンツプロバイダから提供されるコンテンツを、仮想プリントサーバに保管しておき、求めに応じて各ユーザに供給する場合などに適用して好適なものである。
【０００２】
【従来の技術】
従来、インターネット上では、Ｗｅｂページなどの形で各ユーザに様々なコンテンツが提供されている。
【０００３】
所定の仮想プリントサービスを提供する仮想プリントサーバは、会員として、コンテンツの提供元であるコンテンツプロバイダ（コンテンツ提供会員）と、そのコンテンツの提供を受けるユーザ（コンテンツ利用会員）を登録し、会員制の仮想プリントサービスを提供している。
【０００４】
当該仮想プリントサーバは、前記コンテンツ提供会員が運用するＷｅｂサーバ等と、前記コンテンツ利用会員のあいだに介在し、コンテンツ利用会員からの要求に応じてコンテンツを提供する。
【０００５】
すなわち、前記Ｗｅｂサーバ等から供給されるコンテンツは、いったん仮想プリントサーバ内に保管された上で、前記コンテンツ利用会員からの要求に応じて仮想プリントサーバから送信し、当該コンテンツ利用会員が操作するＭＭＫ端末などから出力（印刷出力または画面表示出力）する構成となる。
【０００６】
【発明が解決しようとする課題】
ところで、上述したコンテンツの種類は多種多様であり、ほとんど更新されないものもあるが、更新されるものも多い。当該コンテンツが例えば、天気予報やニュースなどである場合には、更新は頻繁に行われる。そのコンテンツの提供を希望する以上、前記コンテンツ利用会員は、そのコンテンツの更新については関心があるはずであるが、従来は、コンテンツの更新が行われたことをコンテンツ利用会員に通知する方法がなかった。
【０００７】
そのため、例えば、すでに更新が行われたにもかかわらず、更新前の古いコンテンツを最新のコンテンツとして利用する等の矛盾が起きる可能性があるなど、信頼性や利便性に欠けていた。
【０００８】
この意味の信頼性や利便性を高めることは、コンテンツ提供会員にとっても重要である。
【０００９】
【課題を解決するための手段】
かかる課題を解決するために、第１の本発明では、所定のコンテンツ提供システム（例えば、コンテンツサーバ１５など）から提供されたコンテンツ（例えば、コンテンツＣＴ１１など）を所定のコンテンツ保管部（例えば、保管部ＲＣ１など）に保管しておき、ユーザ（例えば、ユーザＵ１など）が通信端末（例えば、携帯電話機１６など）から出力要求を送信してきたときには、前記コンテンツを当該通信端末へ供給する情報保管システム（例えば、仮想プリントシステム１０など）において、
前記コンテンツ提供システムと通信することにより、当該コンテンツ提供システムから提供される前記コンテンツの更新に関連する更新関連情報を検出するコンテンツ更新検出部（例えば、更新通知受付部３３など）または、すでに前記コンテンツ保管部に保管されているコンテンツに付随する制御情報（例えば、ＨＴＴＰレスポンスメッセージに含まれる更新日、有効期限など）を検査することにより、当該コンテンツの更新に関連する更新関連情報を推測するコンテンツ更新推測部（例えば、更新予測部３７など）のいずれかを備え、前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果を、前記ユーザに通知する更新情報通知部（例えば、通知メール生成部３８など）を有することを特徴とする。
【００１０】
また、第２の本発明では、所定のコンテンツ提供システムから提供されたコンテンツを所定のコンテンツ保管部に保管しておき、ユーザが通信端末から出力要求を送信してきたときには、前記コンテンツを当該通信端末へ供給する情報保管方法において、コンテンツ更新検出部が、前記コンテンツ提供システムと通信することにより、当該コンテンツ提供システムから提供される前記コンテンツの更新に関連する更新関連情報を検出するか、または、コンテンツ更新推測部が、すでに前記コンテンツ保管部に保管されているコンテンツに付随する制御情報を検査することにより、当該コンテンツの更新に関連する更新関連情報を推測し、前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果を、更新通知部が、前記ユーザに通知することを特徴とする。
【００１１】
さらに、第３の本発明では、所定のコンテンツ提供システムから提供されたコンテンツを所定のコンテンツ保管機能に保管しておき、ユーザが通信端末から出力要求を送信してきたときには、前記コンテンツを当該通信端末へ供給する情報保管プログラムにおいて、コンピュータに、前記コンテンツ提供システムと通信することにより、当該コンテンツ提供システムから提供される前記コンテンツの更新に関連する更新関連情報を検出するコンテンツ更新検出機能または、すでに前記コンテンツ保管部に保管されているコンテンツに付随する制御情報を検査することにより、当該コンテンツの更新に関連する更新関連情報を推測するコンテンツ更新推測機能のいずれかを実現させ、前記コンテンツ更新検出機能による検出結果またはコンテンツ更新推測機能による推測結果を、前記ユーザに通知する更新情報通知機能を実現することを特徴とする。
【００１２】
これによれば、前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果として、更新関連情報を、前記ユーザに通知することができる。
【００１３】
【発明の実施の形態】
（Ａ）実施形態
以下、本発明にかかる情報保管システム、情報保管方法、および情報保管プログラムを、仮想プリントシステムに適用した場合を例に、実施形態について説明する。
【００１４】
仮想プリントシステムは、インターネット上に配置した仮想プリントサーバを中心としたシステムで、このシステムに会員として登録した前記コンテンツ利用会員は、仮想プリントサービスが提供するコンテンツを利用することができる。仮想プリントサービスでは、各コンテンツ利用会員は、自身が携帯する携帯電話機などを活用しながら、コンビニエンスストアや駅など、人が多く集まる場所に設置されたＭＭＫ（マルチメディアキオスク）端末から所望の画像の印刷出力や画面表示出力を受けることができる。必要に応じて、ＭＭＫ端末の替わりに当該携帯電話機から当該コンテンツの画面表示出力を行ってもよいことは当然である。
【００１５】
（Ａ−１）実施形態の構成
本実施形態の仮想プリントシステム１０の全体構成例を図１に示す。
【００１６】
図１において、当該仮想プリントシステム１０は、インターネット１１と、携帯電話ネットワーク１２と、仮想プリントサーバ１３と、ＭＭＫ端末１４と、コンテンツサーバ１５と、携帯電話機１６とを備えている。
【００１７】
このうち携帯電話機１６は、直接的には、所定の携帯電話事業者が運営する携帯電話ネットワーク１２に属するが、当該携帯電話ネットワーク１２およびインターネット１１を経由することで、コンテンツサーバ１５および仮想プリントサーバ１３と通信することができる。当該携帯電話機１６は、前記コンテンツ利用会員の一人であるユーザＵ１によって携帯され、使用される。
【００１８】
本実施形態の構成上、当該携帯電話機１６はＷｅｂブラウザとメーラを搭載している必要がある。
【００１９】
コンテンツサーバ１５は、前記コンテンツ提供会員（コンテンツプロバイダ）の一つであるコンテンツプロバイダＣＰ１によって運営されるサーバで、所定のコンテンツＣＴ１１を提供する機能を備えている。当該コンテンツサーバ１５が提供するコンテンツは、１種類であってもよく、複数種類であってもよい。コンテンツサーバ１５は、コンテンツを提供することができさえすれれば、どのような方法で提供してもかまわない。例えば、ＦＴＰプロトコルなどを利用してコンテンツを提供するものであってもかまわないが、ここでは、ＨＴＴＰプロトコルを利用してコンテンツを提供するものとする。したがって、当該コンテンツサーバ１５は、Ｗｅｂサーバ機能を備えている。
【００２０】
仮想プリントサーバ１３は、前記仮想プリントサービスを提供する事業者ＥＰ１によって運営されるサーバである。上述したように、コンテンツプロバイダＣＰ１はコンテンツ提供会員として仮想プリントサーバ１３に会員登録されており、ユーザＵ１はコンテンツ利用会員として仮想プリントサーバ１３に会員登録されている。
【００２１】
図１にはコンテンツ提供会員とコンテンツ利用会員を一人ずつしか図示していないが、仮想プリントサーバ１３には通常、コンテンツ提供会員もコンテンツ利用会員も、多数が登録される。
【００２２】
仮想プリントサーバ１３は、コンテンツサーバ１５などが提供するコンテンツ群のなかから、ユーザＵ１が指定するもの（それが、前記ＣＴ１１であるとする）を、ユーザＵ１のために保管しておき、ユーザＵ１がＭＭＫ端末１４を操作すること等によって要求すると、保管していたコンテンツＣＴ１１を送信し、当該ＭＭＫ端末１４から出力（印刷出力または画面表示出力）させる。
【００２３】
携帯電話機１６も画面表示を行う機能を搭載しているため、コンテンツＣＴ１１が携帯電話機向けに小さなサイズ（ビット数）で構成されたものであれば、携帯電話機１６の画面で表示することも可能である。ただし、携帯電話機１６の画面は寸法が小さいため、より大きなＭＭＫ端末１４の画面に表示したほうがユーザＵ１にとって好都合なことも多い。また、携帯電話機１６には印刷機能がないため、外出先など所望の場所で当該コンテンツＣＴ１１の印刷出力を行うにはＭＭＫ端末１４を利用することが必要になる。
【００２４】
図１には１つのＭＭＫ端末１４しか図示していないが、仮想プリントシステムには通常、多数のＭＭＫ端末が含まれる。
【００２５】
表示画面が小さく、印刷出力の機能を持たない携帯電話機１６の機能を補完し、十分な大きさで高精細な画面表示出力や印刷出力を、ユーザＵ１の移動先の近傍で行わせ、仮想プリントサービスの実効性を高めるためには、高い密度でＭＭＫ端末を分布させることが必要となるからである。少なくとも市街地の人が多く集まる場所には、高い密度でＭＭＫ端末が分布しており、仮想プリントサーバ１３と携帯電話機１６のあいだで行うメッセージ交換に応じて、ユーザＵ１の現在位置の近傍に存在する複数のＭＭＫ端末のなかから所望のＭＭＫ端末を選択する構成となる。また、この選択を受けて、仮想プリントサーバ１３や該当するＭＭＫ端末（例えば、１４）は、当該ユーザＵ１が求めるコンテンツＣＴ１１を速やかに出力（画面表示出力または印刷出力）するための準備を整え、実際にそのユーザＵ１が選択したＭＭＫ端末（例えば、１４）まで移動して所定の操作を行ったときには、当該ＭＭＫ端末から、当該画像の出力が直ちに実行される手順になる。
【００２６】
コンテンツ出力用の端末として、携帯電話機１６を選ぶか、ＭＭＫ端末１４を選ぶかは、予めユーザＵ１が指定することができる。コンテンツＣＴ１１の種類が上述したニュースや天気予報などの場合には、印刷出力する必要性は高くないので、出力用の端末として携帯電話機が選ばれる可能性も高い。なお、本実施形態は、当該ニュースや天気予報などのように、高頻度で、ほぼ定期的に更新されるコンテンツに対しても有効であるが、いつ更新されるかは不明（予測困難）であるが、その更新に対しユーザＵ１が重大な関心を持っているコンテンツなどに対して、より有効であるといえる。
【００２７】
ユーザＵ１が携帯する前記携帯電話機１６の内部構成は、例えば、図２に示す通りである。また、前記ＭＭＫ端末１４の内部構成もこれと同じであってよい。ただし、ＭＭＫ端末１４の場合、印刷機能をともなうことは上述した通りである。この印刷機能は、ＭＭＫ端末１４に内蔵されている場合と、ＭＭＫ端末１４とは別個の装置（プリンタなど）としてＭＭＫ端末１４に接続されている場合がある。
【００２８】
（Ａ−１−１）携帯電話機の内部構成例
図２において、当該携帯電話機１６は、通信部２０と、制御部２１と、操作部２２と、表示部２３と、記憶部２４とを備えている。
【００２９】
このうち通信部２０はインターネット１１および携帯電話ネットワーク１２を経由した前記仮想プリントサーバ１３との通信のために機能する部分である。また、必要に応じて、インターネット１１および携帯電話ネットワーク１２経由で、コンテンツサーバ１５との通信も行う。
【００３０】
制御部２１は、ハードウエア的には当該携帯電話機１６のＣＰＵ（中央処理装置）に相当し、ソフトウエア的にはＯＳ（オペレーティングシステム）、Ｗｅｂブラウザ、メーラなどの各種プログラムに相当する部分である。本実施形態では、基本的に、仮想プリントサーバ１３から送信されたコンテンツＣＴ１１を携帯電話機１６で画面表示する場合には、Ｗｅｂを使用し、各種の通知を仮想プリントサーバ１３から受け取るためには、電子メール（通知メールＭＥ１）を使用するため、携帯電話機１６はＷｅｂブラウザとメーラを搭載していることが必要である。
【００３１】
携帯電話機の場合、電子メールが着信したことは着信音やバイブレーションによって即座にユーザに伝えられるため、携帯電話機１６に届けられる通知メールＭＥ１の内容は、直ちにユーザＵ１に閲覧される可能性が高い。
【００３２】
操作部２２は、当該携帯電話機１６を利用するユーザＵ１によって操作される部分である。携帯電話機の場合、操作部２２は、パソコンのキーボードなどに比べると、はるかに寸法が小さく、操作キーの数も少ない。ただし、図２にＭＭＫ端末１４を示したものとみる場合、操作部２２は、携帯電話機よりもはるかに大きく、操作キーの数も十分であるので、携帯電話機１６に比べると操作性が高い。
【００３３】
表示部２３は、前記ユーザＵ１が目視するための画面を表示するディスプレイ装置（例えば、ＬＣＤ（液晶表示装置））に対応する部分で、前記操作部２２とともにユーザインタフェースを構成する。コンテンツＣＴ１１を仮想プリントサーバ１３から携帯電話機１６に送信した場合には、ユーザＵ１は、この表示部２３を介して、コンテンツＣＴ１１の内容を閲覧することになる。携帯性を要求される携帯電話機の性質上、携帯電話機１６のボディサイズは小さくなり、必然的に、表示部２３の画面サイズも小さくなる。
【００３４】
これに対し、ＭＭＫ端末１４の場合には、固定的に設置して利用されるものであって、携帯性を要求されないため、表示部２３の画面サイズも、携帯電話機１６に比べるとはるかに大きい。したがって、携帯電話機１６では、正確に表示することが困難な画像や、ビット数が大きすぎるために表示できない画像でも、ＭＭＫ端末１４には正確に表示することが可能である。
【００３５】
前記記憶部２４はハードウエア的には、ＲＡＭ（ランダムアクセスメモリ）や、ハードディスクなどによって構成される記憶資源であり、ソフトウエア的には、各種のファイルがこの部分に含まれ得る。前記Ｗｅｂブラウザやメーラなどのプログラムファイルや、前記コンテンツＣＴ１１を収容したファイルなどもこのようなファイルの一例であるから、これらのファイルも、その物理的な実体は、この記憶部２４に位置する。
【００３６】
一方、インターネット１１および携帯電話ネットワーク１２を介して当該携帯電話機１６と通信する仮想プリントサーバ１３の内部構成は、例えば、図３に示すものであってよい。当該仮想プリントサーバ１３は、携帯電話機１６のほか、コンテンツサーバ１５およびＭＭＫ端末１４とも通信する。
【００３７】
（Ａ−１−２）仮想プリントサーバの内部構成例
図３において、当該仮想プリントサーバ１３は、通信部３０と、制御部３１と、記憶部３２と、更新通知受付部３３と、予定通知受付部３４と、定期アクセス部３５と、比較解析部３６と、更新予測部３７と、通知メール生成部３８と、更新内容要約部３９と、フィルタリング部４０と、通知条件制御部４１とを備えている。
【００３８】
このうち通信部３０は前記通信部２０に対応し、制御部３１は前記制御部２１に対応し、記憶部３２は前記記憶部２４に対応するので、その詳しい説明は省略する。
【００３９】
ただし仮想プリントサーバ１３はサーバ機能を提供する側なので、制御部３１には、前記Ｗｅｂブラウザの替わりにＷｅｂサーバソフトなど各種サーバ機能が搭載される。また、当該制御部３１には、ＣＧＩプログラムやＷｅｂサービス用のアプリケーションプログラムなどが搭載され得る。
【００４０】
さらにまた、仮想プリントサーバ１３は、携帯電話機１６のほかに、コンテンツサーバ１５やＭＭＫ端末１４とも通信するので、通信部３０もそのような通信に対応したものであることが必要である。
【００４１】
ユーザＵ１からの指定に応じて、仮想プリントサーバ１３が、コンテンツサーバ１５から該当するコンテンツＣＴ１１を取得し、保管するための方法としては様々なものが考えられるが、この方法は、ユーザＵ１と仮想プリントサーバ１３とのあいだの通信などとも関連する。
【００４２】
例えば、ユーザＵ１が携帯電話機１６でアクセス（ＨＴＴＰリクエストメッセージＨＲＱ１を送信）してくると、仮想プリントサーバ１３が所定の構成のＷｅｂページ（ＨＴＴＰレスポンスメッセージＨＲＳ１の本体）を当該携帯電話機１６に返し、ユーザＵ１が前記表示部２３により画面表示された当該Ｗｅｂページを目視しながら前記操作部２２を操作して、当該Ｗｅｂページ上の所定の入力欄にコンテンツＣＴ１１を指定する情報（例えば、そのコンテンツＣＴ１１を指すＵＲＬ）を入力してその入力内容（前回とは別個のＨＴＴＰリクエストメッセージＨＲＱ２の本体）を送信すると、仮想プリントサーバ１３側でも当該ＵＲＬが分かるため、例えば、前記Ｗｅｂサービス用のアプリケーションが、当該ＵＲＬをもとに前記コンテンツサーバ１５へアクセス（ＨＴＴＰリクエストメッセージＨＲＱ３を送信）し、当該ＵＲＬが指定するコンテンツＣＴ１１（ＨＴＴＰレスポンスメッセージＨＲＳ２の本体）を、当該コンテンツサーバ１５から受け取るという方法であってもよい。
【００４３】
また、携帯電話機１６（あるいは、図示しないユーザＵ１のパソコンなど）から直接、コンテンツサーバ１５にコンテンツＣＴ１１の送信を指示し、この指示に応じて、コンテンツサーバ１５から仮想プリントサーバ１３へ当該コンテンツＣＴ１１を送信するという方法を用いることもできる。この場合には、通信手段として、ＦＴＰプロトコルの利用が可能である。
【００４４】
前記記憶部３２には、仮想プリントサーバ１３が各コンテンツ提供会員やコンテンツ利用会員を管理するためのユーザ管理データベースＵＭ１や、各コンテンツ利用会員のためにコンテンツを保管する保管部が設けられている。ここで、前記ユーザＵ１のための保管部をＲＣ１とする。したがって、前記コンテンツＣＴ１１は、当該保管部ＲＣ１に保管されることになる。
【００４５】
さらに、当該記憶部３２は、仮想プリントサーバ１３内の各構成要素３３〜４１が処理を実行するために必要な各種の情報や、作業用の記憶領域などを提供する。
【００４６】
構成要素３３〜４１のうち定期アクセス部３５は、前記コンテンツサーバ１５に対して繰り返しＨＴＴＰリクエストメッセージを送信することによって、コンテンツサーバ１５からＨＴＴＰレスポンスメッセージを取得するための部分である。
【００４７】
ＨＴＴＰレスポンスメッセージにどのような情報が含まれるかは、ＨＴＴＰリクエストメッセージのメソッドに応じて変化する。一般的なＧＥＴメソッドを用いた場合、ヘッダ情報（制御情報）とともに、ファイルの本体（すなわち、ここでは、コンテンツＣＴ１１そのもの）が当該ＨＴＴＰレスポンスメッセージに含まれる。これに対しＨＥＡＤメソッドを用いると制御情報だけが当該ＨＴＴＰＥレスポンスメッセージに含まれる。
【００４８】
この制御情報には多種多様な情報が含まれているが、本実施形態にとって重要なものは、更新日と有効期限である。更新日とは、コンテンツ（ここでは、ＣＴ１１）を更新した日時を示す情報であり、有効期限とは、コンテンツプロバイダＣＰ１側が指定する当該コンテンツＣＴ１１の有効期限である。
【００４９】
有効期限は、ユーザ（例えば、Ｕ１）に提供されるコンテンツが更新後の最新のものであること（コンテンツの最新性）を確保するために設定される制御情報で、キャッシュサーバ（あるいは、多くのＷｅｂブラウザ）によって使用される。キャッシュサーバ（あるいは、多くのＷｅｂブラウザ）は、一度、ＨＴＴＰレスポンスメッセージによって取得したコンテンツは、ローカルの記憶資源にキャッシュしておく機能がある。コンテンツをキャッシュしてある場合、ＵＲＬを指定すること等によりそのコンテンツ（例えば、ＣＴ１１）の取得をユーザ（例えば、Ｕ１）がふたたび要求すると、基本的に、コンテンツの提供元のＷｅｂサーバにＨＴＴＰリクエストメッセージを送信することなく、キャッシュしてあるコンテンツを読み出して画面表示し、ユーザＵ１に閲覧させる。これによって、通信トラフィックを抑制し、見かけ上のレスポンス性能を高めるものである。
【００５０】
しかしながら、当該キャッシュサーバ（あるいは、多くのＷｅｂブラウザ）は、前記有効期限が切れた場合には、キャッシュしてあるコンテンツを削除し、コンテンツの提供元のＷｅｂサーバにＨＴＴＰリクエストメッセージを送信して、直接、コンテンツを取得することになる。したがって、有効期限はコンテンツの最新性を確保するための制御情報であるといえ、コンテンツプロバイダＣＰ１側でそのコンテンツＣＴ１１を近い将来、更新しようと意図している場合には、短い有効期限を設定し、更新の予定がない場合などには長い有効期限を設定する傾向がある。
【００５１】
更新日や有効期限などの制御情報は、本来、このようにＷｅｂブラウザやキャッシュサーバなどが制御用に利用するための情報であるから、通常は、ユーザＵ１の目に触れることはない。
【００５２】
また、前記制御情報のうちコンテンツのデータ形式（ＭＩＭＥタイプ）やファイルサイズ（ビット数）などを示す制御情報も、有用である。
【００５３】
例えば、データ形式が変わっていれば更新があったことが分かるし、ファイルサイズが変わっていても更新があったことがわかる。ただし、データ形式やファイルサイズが変わっていなかったとしても、それをもって更新がなかったと判定することはできないことは当然である。
【００５４】
定期アクセス部３５による前記コンテンツサーバ１５に対するＨＴＴＰリクエストメッセージの送信は、予め設定した時間間隔（例えば、３時間など）にしたがって周期的に行ってもよく、予め設定したスケジュール（例えば、毎日、午前９時と、午後１２時と、午後６時に送信するというスケジュールなど）にしたがって行ってもよい。また、その周期やスケジュールは、ユーザＵ１からの指示に応じて動的に変更できるようにすることも望ましい。
【００５５】
前記比較解析部３６は、当該定期アクセス部３５が送信したＨＴＴＰリクエストメッセージに対してコンテンツサーバ１５から返送されてきたＨＴＴＰレスポンスメッセージの内容などを解析する部分で、解析結果として、更新の有無や日時などを得る。
【００５６】
ＨＴＴＰレスポンスメッセージに含まれる例えば前記更新日を、保管部ＲＣ１に保管してあるコンテンツＣＴ１１の更新日と比較すれば、保管してあるコンテンツＣＴ１１が最新のものであるか否か、すなわち、当該コンテンツＣＴ１１の保管後にコンテンツサーバ１５側で当該コンテンツＣＴ１１の内容の更新が行われたか否かが分かる。
【００５７】
このように更新日などの制御情報を取り扱うことは、一般的に、コンテンツの内容そのものを取り扱う場合に比べ、仮想プリントサーバ１３の処理能力にかかる負荷がはるかに小さく、短時間で処理を行うことができるので効率的である。
【００５８】
ただし更新日などの情報は、コンテンツサーバ１５側で適切な管理が行われていなければ、不正確なこともあり、例えば、実際にはコンテンツＣＴ１１の内容が更新されているのに、制御情報としての更新日の情報は従前のままである等ということも起こり得る。このような矛盾を検出し正確な対応を行うためには、予め保管してあったものと、今回、ＨＴＴＰレスポンスメッセージに含まれて届いたものとのあいだで、コンテンツＣＴ１１の内容そのものを比較することが必要になる。
【００５９】
したがって、当該比較解析部３６は、必要に応じて、前記更新日などの制御情報ではなく、コンテンツＣＴ１１の内容そのものを比較することで、更新の有無などを検出するようにしてもよい。また、内容そのものを比較することにより、更新の程度（内容が大幅に更新されたか、一部だけ更新されたか等）を検出したり、更新の詳細を検出すること等も可能となる。
【００６０】
なお、制御情報として更新日ではなく、有効期限を比較することも有用である。
【００６１】
例えば、前回に比べて短い有効期限を設定してきた場合には、コンテンツＣＴ１１の更新が近いと予測することもできるからである。このような方法で、更新の予測を行うのが、前記更新予測部３７である。
【００６２】
更新通知受付部３３は、コンテンツサーバ１５側が明示的に更新したことを通知してきた場合、その通知情報（明示的更新通知情報）を受け付ける部分である。
【００６３】
前記比較解析部５６による処理は、コンテンツサーバ１５側が特別な処理を行わなくても、通常のＨＴＴＰプロトコルによる通信によって得られる情報だけをもとに実行可能であったが、この更新通知受付部３３は、コンテンツサーバ１５側が明示的更新通知情報を生成し、送信してくることが前提となる。
【００６４】
上述したように、仮想プリントサーバ１３のコンテンツ提供会員は多数であるので、コンテンツ提供会員によっては、運用するコンテンツサーバ（１５に対応）が、明示的更新通知情報を生成し、送信する機能を持たないこともあり、また、そのような機能を持っているコンテンツサーバであっても、コンテンツによっては、明示的更新通知情報の生成を行わない場合などもあり得るので、仮想プリントサーバ１３側では、ほぼ同一の目的を達成するために、このように多様な手段を用意しておくことは好ましいといえる。
【００６５】
明示的更新通知情報を、コンテンツサーバ１５から仮想プリントサーバ１３まで届けるための通信手段としては様々なものが利用可能である。例えば、コンテンツサーバ１５側の特定のＵＲＬ（明示的更新通知情報のためのＵＲＬ）に仮想プリントサーバ１３側から短い時間間隔（例えば、６００秒間隔程度。この時間間隔が十分に短ければ、実質的にコンテンツサーバ１５側からプッシュ型の通信を行うのに等しいといえる）で定期的にＨＴＴＰリクエストメッセージを送信し、ＨＴＴＰレスポンスメッセージの本体として当該明示的更新通知情報を取得すること等も可能であるが、電子メールを利用することも簡便である。ここでは、当該電子メール（この電子メールを、中間通知メールＭＥＣとする）を使用するものとする。
【００６６】
前記予定通知受付部３４は当該更新通知受付部３３に対応する構成要素である。受け付ける情報が、更新通知受付部３３のように、更新があったことを明示的に通知する明示的更新通知情報ではなく、更新の予定があることを明示的に通知する明示的更新予定通知情報である点が相違するだけである。したがって、当該明示的更新予定通知情報を届けるための通信手段も、前記中間通知メールＭＥＣである。
【００６７】
なお、この明示的更新予定通知情報の持つ意味は、前記制御情報の１つである有効期限に類似しているといえるが、有効期限を短く設定したからといって必ず更新が近いという保証がないのに対し、明示的更新予定通知情報で通知される更新予定日時は、更新の予定日時を示すものであることが保証されている点が相違する。換言するなら、短い有効期限を設定したからといってコンテンツプロバイダＣＰ１側に近日中に更新を行う責任が発生するわけではないが、明示的更新予定通知情報を通知した場合には、その明示的更新予定通知情報で指定した更新予定日時に更新を行う責任が発生するといえる。
【００６８】
通知メール生成部３８は、前記ユーザＵ１に更新があったこと等を伝える所定の通知メールＭＥ１を生成する部分である。実際に更新があったこと（前記比較解析部３６または更新通知受付部３３によって得られる）のほか更新の予測結果、（前記更新予測部３７による）や、（前記予定通知受付部３４によって得られる）更新の予定日時（明示的更新予定通知情報の内容）などの各種情報が当該通知メールＭＥ１に記載される。
【００６９】
また、次の更新内容要約部３９が機能する場合には、更新内容の要約を示す要約情報（例えば、更新の内容を説明する説明文など）が、当該通知メールＭＥ１に含まれることになる。
【００７０】
当該更新内容要約部３９は、前記要約情報を生成する部分である。当該要約情報は、コンテンツＣＴ１１に関して行われた更新がどのようなものであるかを示す情報である。例えば、前記比較解析部３６がコンテンツＣＴ１１の内容そのものを比較することによって、更新の有無を検出した場合などには、その比較の過程で使用されたコンテンツＣＴ１１の内容から、当該要約情報を生成することも可能である。
【００７１】
また、コンテンツサーバ１５側で当該要約情報を作成し、明示的更新通知情報や明示的更新予定通知情報とともに、前記中間通知メールＭＥＣによって、仮想プリントサーバ１３側へ届けるようにしてもよい。明示的更新予定通知情報とともに届ける要約情報は、現に実行された更新の要約ではなく、これから実行される更新の要約を示す予告である。ただし現実には、このような要約を生成することは必ずしも容易ではない。
【００７２】
そこで、更新の要約の替わりに、更新の概要を、例えば、ファイル名などの形で示すようにすれば簡便である。これは、あるコンテンツＣＴ１１の更新前と更新後でそのファイル名が変更された場合には、変更前と変更後のファイル名を表示するものである。ファイル名の付け方に注意すれば、ファイル名によって更新の概要を適切に表現することは可能である。
【００７３】
なお、更新の概要とともに、または更新の概要に替えて、当該更新に関連性のある情報や、ユーザＵ１に伝えたい情報をトピックスとして通知することも望ましい。
【００７４】
このトピックスは、コンテンツサーバ１５側で生成してもよく、仮想プリントサーバ１３側で生成してもよい。
【００７５】
更新の概要とトピックスを通知メールＭＥ１の本文部分に記載した場合、当該通知メールＭＥ１を受信した携帯電話機１５の表示部２３には、例えば、図１０に示す画面が表示されることになる。
【００７６】
図１０において、「コンテンツＮ１１」はコンテンツＣＴ１１の更新前のファイル名であり、「コンテンツＭ１１」は当該コンテンツＣＴ１１の更新後のファイル名である。また、図１０の例では、トピックスとして、日経平均株価や天気予報に関する情報などが含まれている。
【００７７】
前記フィルタリング部４０は、更新等が行われたコンテンツの内容に応じて、前記通知メールＭＥ１を送信するか否かを決定する部分である。どのような更新が行われた場合（または、これから行われる場合）に通知してほしいかを示すフィルタリング条件を、予めユーザＵ１が指定しておけば、そのフィルタリング条件に応じて、当該フィルタリング部４０が前記通知メールＭＥ１を送信するか否かを決定することになる。
【００７８】
これにより、ユーザＵ１は真に必要とする通知メールＭＥ１だけを受信し閲覧することができる。同様なフィルタリング条件は、コンテンツサーバ１５（コンテンツプロバイダＣＰ１）側からも指定できるようにすることが望ましい。
【００７９】
例えば、コンテンツを予め分野（カテゴリ）別に分類しておき、ユーザＵ１やコンテンツプロバイダＣＰ１にとっての各カテゴリの重要さ（重要度）を指定することをもって、当該フィルタリング条件の設定とすることができる。
【００８０】
この場合、ユーザＵ１およびコンテンツプロバイダＣＰ１のフィルタリング条件をまとめると、例えば、図１１に示すフィルタリング表のようになる。図１１において、「×」はフィルタリングされて通知（送信）されないことを示し、「○」はフィルタリングされず通知（送信）されることを示す。
【００８１】
例えば、コンテンツプロバイダＣＰ１がコンテンツとして各種のニュースを提供しているものとする。この場合、ニュースはいくつかの分野（例えば、「政治情報」分野、「証券情報」分野などの各分野）に分かれ、個々のコンテンツ（個々のニュース）はいずれかの分野に属する。ニュースの分野のうち、コンテンツプロバイダＣＰ１は、「証券情報」分野の重要度を３に、「政治情報」分野の重要度を２に指定したものとし、ユーザＵ１が、「証券情報」分野の重要度を５に「政治情報」分野の重要度を１に指定したものとすると、「政治情報」分野のニュースは、図１１上で位置ＰＸ２に相当し、「証券情報」分野のニュースは、位置ＰＸ１に相当する。したがって、「証券情報」分野のニュース（コンテンツ）が更新された場合などには、前記通知メールＭＥ１を送信してユーザＵ１に通知することになるが、「政治情報」分野のニュースが更新された場合などには、通知メールＭＥ１の送信を行わず、通知しない。
【００８２】
このケースで、ユーザＵ１が例えば「政治情報」分野の重要度を１から４に変更すると、図１１上の位置はＰＸ２からＰＸ３に移動するから、「政治情報」分野のニュースが更新された場合などにも、それを伝えるための通知メールＭＥ１が送信されることになる。
【００８３】
通知条件制御部４１は、前記通知メールＭＥ１を送信するか否かを決定する点は当該フィルタリング部４０と同じであるが、その決定の根拠となる通知条件がコンテンツの内容（コンテンツの属する分野）ではなく、通知の外形的な条件である点が相違する。通知の外形的な条件には様々なものがあり得るが、例えば、通知メールＭＥ１を受け取ることのできる時刻、時間帯、１日に受け取ることが許容できる最大の通知メールＭＥ１の数などがあてはまる。
【００８４】
また、ＣＰ１以外に多数のコンテンツプロバイダがコンテンツ提供会員として登録されており、なおかつ、ユーザＵ１が特にコンテンツプロバイダを指定せずに、コンテンツの種類を指定すること等により、前記通知メールＭＥ１の送信を依頼してあるケースなどでは、特定のコンテンツプロバイダを指定して、そのコンテンツプロバイダが提供するコンテンツの更新に関しては、通知メールＭＥ１を送信しないでほしいという条件を、当該通知条件として設定することも可能である。
【００８５】
さらに、仮想プリントサーバ１３側が前記携帯電話事業者から、携帯電話ネットワーク１２内で管理している携帯電話機１６の現在位置を示す位置情報や、当該位置情報をもとに生成でき、携帯電話機１６が（したがってユーザＵ１が）移動中であるか否かを示す移動情報などを取得できる場合には、当該位置情報などを利用して通知条件を設定することもできる。例えば、当該位置情報を使用し、ある場所にいるときには通知メールＭＥ１を送信しないように指示する通知条件を設定したり、移動情報を使用して移動中には通知メールＭＥ１を送信しないように指示する通知条件を設定すること等も可能である。
【００８６】
このような通知条件は、コンテンツ利用会員（例えば、Ｕ１）をグループ分けした上でグループごとに設定したり、全コンテンツ利用会員について包括的に同じ条件を設定したりすることも可能であるが、個々のコンテンツ利用会員からの指示に応じて設定できるようにすれば、コンテンツ利用会員にとって便利である。例えば、ユーザＵ１は、携帯電話機１６などを用いて、自身のための通知条件を設定することができるものであってよい。
【００８７】
次に、前記コンテンツサーバ１５の内部構成例を図４に示す。
【００８８】
（Ａ−１−３）コンテンツサーバの内部構成例
図４において、当該コンテンツサーバ１５は、通信部５０と、制御部５１と、記憶部５２と、更新通知生成部５３と、更新予定通知生成部５４とを備えている。
【００８９】
このうち通信部５０は、前記通信部３０に対応し、制御部５１は前記制御部３１に対応し、記憶部５２は前記記憶部３２に対応するので、その詳しい説明は省略する。
【００９０】
更新通知生成部５３は、上述した明示的更新通知情報を生成して中間通知メールＭＥＣを送信する際に機能する部分である。
【００９１】
また、更新予定通知生成部５４は、上述した明示的更新予定通知情報を生成して中間通知メールＭＥＣを送信する際に機能する部分である。
【００９２】
以下、上記のような構成を有する本実施形態の動作について、図６〜図９のフローチャートを参照しながら説明する。
【００９３】
図５のフローチャートはＳ１０〜Ｓ１５の各ステップから構成されており、図６のフローチャートはＳ２０〜Ｓ２５の各ステップから構成されており、図７のフローチャートはＳ３０〜Ｓ３４の各ステップから構成されており、図８のフローチャートはＳ４０〜Ｓ４３の各ステップから構成されており、図９のフローチャートはＳ５０〜Ｓ５４の各ステップから構成されている。
【００９４】
（Ａ−２）実施形態の動作
図５において、前記コンテンツサーバ１５がユーザＵ１からの指示に応じてコンテンツ（ここでは、ＣＴ１１とする）を仮想プリントサーバ１３に送信すると、これを受信した仮想プリントサーバ１３では、当該コンテンツＣＴ１１を前記保管部ＲＣ１に保管する（Ｓ１０、Ｓ１１）。
【００９５】
このあと、仮想プリントサーバ１３内の前記定期アクセス部３５が例えば一定時間間隔で周期的に、コンテンツサーバ１５へＨＴＴＰリクエストメッセージを送信し、このＨＴＴＰリクエストメッセージに対する応答としてコンテンツサーバ１５から届くＨＴＴＰレスポンスメッセージを受信して、コンテンツＣＴ１１，すなわち、当該コンテンツＣＴ１１を格納したファイルの更新の有無を検査する（Ｓ１２）。
【００９６】
検査の結果、更新されていなければそのまま処理を終了し（Ｓ１３，Ｓ１５）、更新されていれば、前記通知メールＭＥ１を携帯電話機１６宛てに送信することで、更新の事実をユーザＵ１に伝えてから（Ｓ１４）、処理を終了する（Ｓ１３，Ｓ１５）。
【００９７】
このように図５のフローチャートでは、仮想プリントサーバ１３側から自動的にユーザＵ１にコンテンツＣＴ１１の更新があったことを通知するが、次の図６のフローチャートでは、ユーザＵ１からの問い合わせに応じて更新の有無を通知する。
【００９８】
図６において、携帯電話機１６を用いてユーザＵ１が仮想プリントサーバ１３にコンテンツＣＴ１１の更新状況を問い合わせると（Ｓ２０，Ｓ２１）、仮想プリントサーバ１３は前記コンテンツサーバ１５にＨＴＴＰリクエストメッセージを送信すること等により、当該コンテンツＣＴ１１の更新の有無を確認する（Ｓ２２）。
【００９９】
当該ステップＳ２２以降の各ステップは、図５と同様である。すなわち、ステップＳ２３は前記ステップＳ１３に対応し、ステップＳ２４は前記ステップＳ１４に対応し、ステップＳ２５は前記ステップＳ１５に対応する。
【０１００】
ただし図６の場合、ユーザＵ１側から積極的に問い合わせてきたのであるから、更新が行われていないケースでも、更新が行われていない旨を通知するようにすることも望ましい。ここで、更新が行われていない旨を通知するためにも、前記通知メールＭＥ１が利用されることは当然である。
【０１０１】
図５，図６のフローチャートでは、ステップＳ１３，Ｓ２３でどのようにしてコンテンツの更新の有無を検査するかに関して特段、具体的に示していないため、すでに詳述したあらゆる方法を利用することができる。これに対し、図７のフローチャートは、コンテンツサーバ１５側から、前記明示的更新通知情報（中間通知メールＭＥＣ）を積極的に送信してくるケースに対応するものである。
【０１０２】
図７において、ステップＳ３０は前記ステップＳ１０に対応し、ステップＳ３１は前記ステップＳ１１に対応する。
【０１０３】
ステップＳ３１につづくステップＳ３２では、前記中間通知メールＭＥＣにより、明示的更新通知情報が仮想プリントサーバ１３に届けられる。これを受信した仮想プリントサーバ１３では、更新の事実をユーザＵ１に伝えるため前記通知メールＭＥ１を送信して処理を終える（Ｓ３３，Ｓ３４）。
【０１０４】
次に、図８のフローチャートは、コンテンツサーバ１５がコンテンツＣＴ１１を仮想プリントサーバ１３へ送信する際、必要に応じて、当該コンテンツＣＴ１１とともに、前記明示的更新予定通知情報を送信するケースに対応するものである。コンテンツＣＴ１１を収容したファイルなどに、当該明示的更新予定通知情報を含めるようにしてもよいが、ファイルに明示的更新予定通知情報を配置するための標準的な規格などは存在しないので、そのような配置を行うには、コンテンツサーバ１５と仮想プリントサーバ１３のあいだで整合性の取れた固有の通信プロトコルを用いること等が必要になる。
【０１０５】
そのため、例えば、コンテンツＣＴ１１を送信した前後、所定の時間範囲内に前記中間通知電子メールＭＥＣを用いて明示的更新予定通知情報を通知すること等をもって、当該コンテンツＣＴ１１とともに明示的更新予定通知情報を送信したものとみなすことも簡便である。
【０１０６】
図８において、コンテンツサーバ１５がコンテンツＣＴ１１を送信すると（Ｓ４０）、それを受信した仮想プリントサーバ１３では、当該コンテンツＣＴ１１とともに、前記明示的更新予定通知情報が含まれているか否かを検査して（Ｓ４１）、含まれていれば、その明示的更新予定通知情報が示す更新の日時にユーザＵ１へ前記通知メールＭＥ１を送信し（Ｓ４２）、含まれていなければ、直ちにこの処理を終了する（Ｓ４３）。
【０１０７】
なお、明示的更新予定通知情報が示す更新の日時に通知メールＭＥ１を送信することに替えて（あるいは、送信することとともに）、「コンテンツＮ１１は、○月×日に更新される予定です。」などと本文部分に記載した通知メールＭＥ１を、携帯電話機１６に宛てて、更新予定日である○月×日の前に送信することも望ましい。
【０１０８】
最後に、図９のフローチャートには、上述した通知条件に対応する処理を示す。
【０１０９】
図９において、携帯電話機１６などを用いて、ユーザＵ１が、仮想プリントサーバ１３に自身のための前記通知条件を設定すると（Ｓ５０，Ｓ５１）、仮想プリントサーバ１３が前記通知メールＭＥ１を送信しようとするときには、前記通知条件制御部４１が動作して、当該通知条件に適合する送信のみを許可する（Ｓ５２，Ｓ５３，Ｓ５４）。これにより、例えば、電子メールＭＥ１を受け取りたくない時間帯などに電子メールＭＥ１が着信することがなくなり、ユーザＵ１の利便性が高まる。
【０１１０】
（Ａ−３）実施形態の効果
本実施形態によれば、ユーザ（Ｕ１）は、コンテンツ（ＣＴ１１）の更新があった場合や、更新が予定される場合などに、その旨の通知（ＭＥ１）を受けることができるため、仮想プリントサービスの信頼性や利便性が向上する。
【０１１１】
これにより、例えば、すでに更新が行われたにもかかわらず、更新前の古いコンテンツを最新のコンテンツとして利用する等の矛盾が起きることも防止することが可能である。
【０１１２】
また、このような信頼性や利便性の向上は、コンテンツの最新性を確保してコンテンツの価値を高めることにも寄与するため、コンテンツを利用する側のコンテンツ利用会員（Ｕ１）にとって有益であるだけでなく、コンテンツを提供する側のコンテンツ提供会員（ＣＰ１）にとっても有益である。
【０１１３】
なお、本実施形態は、ニュースや天気予報などのように、高頻度で、ほぼ定期的に更新されるコンテンツに対しても有効であるが、いつ更新されるかは不明（予測困難）であるが、その更新に対しユーザ（Ｕ１）が重大な関心を持っているコンテンツなどに対して、より有効であるといえる。
【０１１４】
高頻度で更新されるコンテンツに対しては、頻繁に携帯電話機（１６）などからＨＴＴＰリクエストメッセージを送信することもそれほど非効率ではないし、ほぼ定期的に更新されるコンテンツであれば、定期的な更新時期に合わせてＨＴＴＰリクエストメッセージを送信することも効率的であるが、更新時期が予測困難なコンテンツに対し、携帯電話機などから頻繁にＨＴＴＰリクエストメッセージを送信することは著しく非効率であるからである。
【０１１５】
本実施形態により、ユーザ（Ｕ１）は、このように更新時期が予測困難なコンテンツの更新時期を、効率的に知ることが可能となる。これにより、利便性が著しく向上することが期待できる。
【０１１６】
（Ｂ）他の実施形態
上記実施形態において、仮想プリントサーバ１４に設けた構成要素３３〜４１の一部は省略することも可能である。例えば、更新予測部３７と予定通知受付部３４はいずれかを省略してもよい。また、フィルタリング部４０と通知条件制御部４１はいずれかを省略してもよい。さらに、更新通知受付部３３と予定通知受付部３４はいずれかを省略してもよい。さらにまた、更新内容要約部３９は省略してもよい。また、更新通知受付部３３または予定通知受付部３４を設ける場合には、コンテンツサーバ１５のほうから積極的に通知してくるのであるから、定期アクセス部３５は省略してもよい。
【０１１７】
なお、上記実施形態において、コンテンツサーバ１５に設けた更新通知生成部５３、更新予定通知生成部５４は、いずれか一方または双方を省略することが可能である。
【０１１８】
さらに、本発明の構成上、前記ＭＭＫ端末１４は必ずしも必須ではない。
【０１１９】
なお、前記電子メールＭＥ１やＭＥＣに含まれる各種の情報（明示的更新通知情報など）は、電子メールの本文部分に記載するのではなく、メールヘッダに専用の拡張フィールドを用意し、その拡張フィールドに記載するようにしてもよい。
【０１２０】
上記実施形態における携帯電話機は、ＰＨＳ端末など、その他の移動情報端末に置換可能であることは当然である。
【０１２１】
また、前記通知メールＭＥ１を受け取るための通信端末は、携帯電話機などのように移動性のあるものが望ましいが、例えば、据え置き型のパソコンなどのように移動性のない通信端末であっても、一定の効果は期待できる。
【０１２２】
さらに、上記実施形態では電子メール（通知メールＭＥ１）を用いて通知を行ったが、ユーザＵ１の通信端末がプッシュ型のクライアントソフトを搭載している場合などには、必ずしも電子メールを用いる必要はない。
【０１２３】
例えば、当該通信端末のＷｅｂブラウザに、十分に短い時間間隔で定期的にＨＴＴＰリクエストメッセージを送信し、ＨＴＴＰレスポンスメッセージの本体として前記通知メールＭＥ１と同様な内容を有するファイルを受信できるようにした上、有効なファイルが受信できた場合にのみ画面表示などを実行してユーザＵ１に伝える機能を搭載することによって、当該電子メール（ＭＥ１）に替えることが可能である。
【０１２４】
なお、前記インターネットは、その他のネットワークに置換可能である。例えば、特定の通信事業者が構築したＩＰネットワーク、ＩＰ−ＶＰＮ網、広域イーサネット（登録商標）網や、その他のＷＡＮ（ワイドエリアネットワーク）などで置換することも可能である。
【０１２５】
以上の説明では主としてハードウエア的に本発明を実現したが、本発明はソフトウエア的に実現することも可能である。
【０１２６】
【発明の効果】
以上に説明したように、本発明によれば、信頼性および利便性を高めることができる。
【図面の簡単な説明】
【図１】実施形態に係る仮想プリントシステムの全体構成例を示す概略図である。
【図２】実施形態で使用する携帯電話機の内部構成例を示す概略図である。
【図３】実施形態で使用する仮想プリントサーバの内部構成例を示す概略図である。
【図４】実施形態で使用するコンテンツサーバの内部構成例を示す概略図である。
【図５】実施形態の動作例を示すフローチャートである。
【図６】実施形態の動作例を示すフローチャートである。
【図７】実施形態の動作例を示すフローチャートである。
【図８】実施形態の動作例を示すフローチャートである。
【図９】実施形態の動作例を示すフローチャートである。
【図１０】実施形態で使用する携帯電話機の受信画面の一例を示す概略図である。
【図１１】実施形態の動作説明図である。
【符号の説明】
１０…仮想プリントシステム、１１…インターネット、１２…携帯電話ネットワーク、１３…仮想プリントサーバ、１４…ＭＭＫ端末、１５…コンテンツサーバ、１６…携帯電話機、２０，３０，５０…通信部、２１，３１，５１…制御部、２２…操作部、２３…表示部、２４，４３，５２…記憶部、３３…更新通知受付部、３４…予定通知受付部、３５…定期アクセス部、３６…比較解析部、３７…更新予測部、３８…通知メール生成部、３９…更新内容要約部、４０…フィルタリング部、４１…通知条件制御部、５３…更新通知生成部、５４…更新予定通知生成部、ＭＥＣ…中間通知メール、ＭＥ１…通知メール、ＣＴ１１…コンテンツ。

Claims

所定のコンテンツ提供システムから提供されたコンテンツを所定のコンテンツ保管部に保管しておき、ユーザが通信端末から出力要求を送信してきたときには、前記コンテンツを当該通信端末へ供給する情報保管システムにおいて、
前記コンテンツ提供システムと通信することにより、当該コンテンツ提供システムから提供される前記コンテンツの更新に関連する更新関連情報を検出するコンテンツ更新検出部または、すでに前記コンテンツ保管部に保管されているコンテンツに付随する制御情報を検査することにより、当該コンテンツの更新に関連する更新関連情報を推測するコンテンツ更新推測部のいずれかを備え、
前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果を、前記ユーザに通知する更新情報通知部を有することを特徴とする情報保管システム。
請求項１の情報保管システムにおいて、
前記コンテンツ更新検出部は、
所定の時間間隔で前記コンテンツ提供システムと通信し、前記コンテンツそのもの、またはコンテンツに付随する制御情報を取得する定期通信部と、
当該定期通信部が取得したコンテンツまたは制御情報を解析することによって、コンテンツの更新が行われたことを検出する更新解析部とを備えることを特徴とする情報保管システム。
請求項１の情報保管システムにおいて、
前記コンテンツの更新を行ったとき、そのコンテンツの提供元である前記コンテンツ提供システムがその旨を通知し、前記コンテンツ更新検出部が当該通知を受け取ることを特徴とする情報保管システム。
請求項１の情報保管システムにおいて、
前記コンテンツの更新に関する予定を明示する予定情報を、そのコンテンツの提供元である前記コンテンツ提供システムが送信してくると、当該予定情報を受け取る予定情報取得部を備えたことを特徴とする情報保管システム。
請求項１の情報保管システムにおいて、
前記更新情報通知部は、
前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果とともに、または、前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果に替えて、すでに実行された、または予想されるコンテンツの更新の概要を示す更新概要情報を生成する概要情報生成部を備え、
前記ユーザに当該更新概要情報を伝えることを特徴とする情報保管システム。
請求項１の情報保管システムにおいて、
予め設定された選択条件に基づいて、前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果それぞれに関して、内容に応じた選択を行う選択実行部を備え、
当該選択実行部が、前記検出結果または推測結果を選択した場合、前記更新情報通知部は、選択された検出結果または推測結果を、前記ユーザに伝えることを特徴とする情報保管システム。
請求項６の情報保管システムにおいて、
前記選択条件は、前記コンテンツ提供システム側またはユーザ側からの指定に応じて決定することを特徴とする情報保管システム。
請求項１の情報保管システムにおいて、
前記更新情報通知部が通知を行う場合の条件である通知条件を、前記ユーザからの指定に応じて決定する通知条件決定部を備え、
当該通知条件決定部が、当該通知条件に基づいて、前記更新情報通知部による通知を制御することを特徴とする情報保管システム。
所定のコンテンツ提供システムから提供されたコンテンツを所定のコンテンツ保管部に保管しておき、ユーザが通信端末から出力要求を送信してきたときには、前記コンテンツを当該通信端末へ供給する情報保管方法において、
コンテンツ更新検出部が、前記コンテンツ提供システムと通信することにより、当該コンテンツ提供システムから提供される前記コンテンツの更新に関連する更新関連情報を検出するか、または、コンテンツ更新推測部が、すでに前記コンテンツ保管部に保管されているコンテンツに付随する制御情報を検査することにより、当該コンテンツの更新に関連する更新関連情報を推測し、
前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果を、更新通知部が、前記ユーザに通知することを特徴とする情報保管方法。
請求項９の情報保管方法において、
前記コンテンツ更新検出部では、
定期通信部が、所定の時間間隔で前記コンテンツ提供システムと通信することにより、前記コンテンツそのもの、またはコンテンツに付随する制御情報を取得し、
更新解析部が、当該定期通信部が取得したコンテンツまたは制御情報を解析することによって、コンテンツの更新が行われたことを検出することを特徴とする情報保管方法。
請求項９の情報保管方法において、
前記コンテンツの更新を行ったとき、そのコンテンツの提供元である前記コンテンツ提供システムがその旨を通知し、前記コンテンツ更新検出部が当該通知を受け取ることを特徴とする情報保管方法。
請求項９の情報保管方法において、
前記コンテンツの更新に関する予定を明示する予定情報を、そのコンテンツの提供元である前記コンテンツ提供システムが送信してくると、予定情報取得部が、当該予定情報を受け取ることを特徴とする情報保管方法。
請求項９の情報保管方法において、
前記更新情報通知部では、
概要情報生成部が、前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果とともに、または、前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果に替えて、すでに実行された、または予想されるコンテンツの更新の概要を示す更新概要情報を生成し、
前記ユーザに当該更新概要情報を伝えることを特徴とする情報保管方法。
請求項９の情報保管方法において、
選択実行部が、予め設定された選択条件に基づいて、前記コンテンツ更新検出部またはコンテンツ更新推測部による検出結果それぞれに関して、内容に応じた選択を行い、
当該選択実行部が、前記検出結果または推測結果を選択した場合、前記更新情報通知部は、選択された検出結果または推測結果を、前記ユーザに伝えることを特徴とする情報保管方法。
請求項１４の情報保管方法において、
前記選択条件は、前記コンテンツ提供システム側またはユーザ側からの指定に応じて決定することを特徴とする情報保管方法。
請求項９の情報保管方法において、
通知条件決定部が、前記更新情報通知部が通知を行う場合の条件である通知条件を、前記ユーザからの指定に応じて決定し、
当該通知条件決定部が、当該通知条件に基づいて、前記更新情報通知部による通知を制御することを特徴とする情報保管方法。
所定のコンテンツ提供システムから提供されたコンテンツを所定のコンテンツ保管機能に保管しておき、ユーザが通信端末から出力要求を送信してきたときには、前記コンテンツを当該通信端末へ供給する情報保管プログラムにおいて、コンピュータに、
前記コンテンツ提供システムと通信することにより、当該コンテンツ提供システムから提供される前記コンテンツの更新に関連する更新関連情報を検出するコンテンツ更新検出機能または、すでに前記コンテンツ保管部に保管されているコンテンツに付随する制御情報を検査することにより、当該コンテンツの更新に関連する更新関連情報を推測するコンテンツ更新推測機能のいずれかを実現させ、
前記コンテンツ更新検出機能による検出結果またはコンテンツ更新推測機能による推測結果を、前記ユーザに通知する更新情報通知機能を実現することを特徴とする情報保管プログラム。