JP2005025431A - 情報保管システム、情報保管方法、および情報保管プログラム - Google Patents
情報保管システム、情報保管方法、および情報保管プログラム Download PDFInfo
- Publication number
- JP2005025431A JP2005025431A JP2003189310A JP2003189310A JP2005025431A JP 2005025431 A JP2005025431 A JP 2005025431A JP 2003189310 A JP2003189310 A JP 2003189310A JP 2003189310 A JP2003189310 A JP 2003189310A JP 2005025431 A JP2005025431 A JP 2005025431A
- Authority
- JP
- Japan
- Prior art keywords
- content
- update
- unit
- information
- notification
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】信頼性および利便性を高める。
【解決手段】所定のコンテンツ提供システムから提供されたコンテンツを所定のコンテンツ保管部に保管しておき、ユーザが通信端末から出力要求を送信してきたときには、コンテンツを通信端末へ供給する情報保管システムにおいて、コンテンツ提供システムと通信することにより、コンテンツ提供システムから提供されるコンテンツの更新が行われたことを検出するコンテンツ更新検出部または、すでにコンテンツ保管部に保管されているコンテンツに付随する制御情報を検査することにより、コンテンツの更新が行われると予想される時期を検出するコンテンツ更新推測部のいずれかを備え、コンテンツ更新検出部またはコンテンツ更新推測部による検出結果を、ユーザに通知する更新情報通知部を有する。
【選択図】 図5
【解決手段】所定のコンテンツ提供システムから提供されたコンテンツを所定のコンテンツ保管部に保管しておき、ユーザが通信端末から出力要求を送信してきたときには、コンテンツを通信端末へ供給する情報保管システムにおいて、コンテンツ提供システムと通信することにより、コンテンツ提供システムから提供されるコンテンツの更新が行われたことを検出するコンテンツ更新検出部または、すでにコンテンツ保管部に保管されているコンテンツに付随する制御情報を検査することにより、コンテンツの更新が行われると予想される時期を検出するコンテンツ更新推測部のいずれかを備え、コンテンツ更新検出部またはコンテンツ更新推測部による検出結果を、ユーザに通知する更新情報通知部を有する。
【選択図】 図5
Description
【0001】
【発明の属する技術分野】
本発明は情報保管システム、情報保管方法、および情報保管プログラムに関し、例えば、コンテンツプロバイダから提供されるコンテンツを、仮想プリントサーバに保管しておき、求めに応じて各ユーザに供給する場合などに適用して好適なものである。
【0002】
【従来の技術】
従来、インターネット上では、Webページなどの形で各ユーザに様々なコンテンツが提供されている。
【0003】
所定の仮想プリントサービスを提供する仮想プリントサーバは、会員として、コンテンツの提供元であるコンテンツプロバイダ(コンテンツ提供会員)と、そのコンテンツの提供を受けるユーザ(コンテンツ利用会員)を登録し、会員制の仮想プリントサービスを提供している。
【0004】
当該仮想プリントサーバは、前記コンテンツ提供会員が運用するWebサーバ等と、前記コンテンツ利用会員のあいだに介在し、コンテンツ利用会員からの要求に応じてコンテンツを提供する。
【0005】
すなわち、前記Webサーバ等から供給されるコンテンツは、いったん仮想プリントサーバ内に保管された上で、前記コンテンツ利用会員からの要求に応じて仮想プリントサーバから送信し、当該コンテンツ利用会員が操作するMMK端末などから出力(印刷出力または画面表示出力)する構成となる。
【0006】
【発明が解決しようとする課題】
ところで、上述したコンテンツの種類は多種多様であり、ほとんど更新されないものもあるが、更新されるものも多い。当該コンテンツが例えば、天気予報やニュースなどである場合には、更新は頻繁に行われる。そのコンテンツの提供を希望する以上、前記コンテンツ利用会員は、そのコンテンツの更新については関心があるはずであるが、従来は、コンテンツの更新が行われたことをコンテンツ利用会員に通知する方法がなかった。
【0007】
そのため、例えば、すでに更新が行われたにもかかわらず、更新前の古いコンテンツを最新のコンテンツとして利用する等の矛盾が起きる可能性があるなど、信頼性や利便性に欠けていた。
【0008】
この意味の信頼性や利便性を高めることは、コンテンツ提供会員にとっても重要である。
【0009】
【課題を解決するための手段】
かかる課題を解決するために、第1の本発明では、所定のコンテンツ提供システム(例えば、コンテンツサーバ15など)から提供されたコンテンツ(例えば、コンテンツCT11など)を所定のコンテンツ保管部(例えば、保管部RC1など)に保管しておき、ユーザ(例えば、ユーザU1など)が通信端末(例えば、携帯電話機16など)から出力要求を送信してきたときには、前記コンテンツを当該通信端末へ供給する情報保管システム(例えば、仮想プリントシステム10など)において、
前記コンテンツ提供システムと通信することにより、当該コンテンツ提供システムから提供される前記コンテンツの更新に関連する更新関連情報を検出するコンテンツ更新検出部(例えば、更新通知受付部33など)または、すでに前記コンテンツ保管部に保管されているコンテンツに付随する制御情報(例えば、HTTPレスポンスメッセージに含まれる更新日、有効期限など)を検査することにより、当該コンテンツの更新に関連する更新関連情報を推測するコンテンツ更新推測部(例えば、更新予測部37など)のいずれかを備え、前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果を、前記ユーザに通知する更新情報通知部(例えば、通知メール生成部38など)を有することを特徴とする。
【0010】
また、第2の本発明では、所定のコンテンツ提供システムから提供されたコンテンツを所定のコンテンツ保管部に保管しておき、ユーザが通信端末から出力要求を送信してきたときには、前記コンテンツを当該通信端末へ供給する情報保管方法において、コンテンツ更新検出部が、前記コンテンツ提供システムと通信することにより、当該コンテンツ提供システムから提供される前記コンテンツの更新に関連する更新関連情報を検出するか、または、コンテンツ更新推測部が、すでに前記コンテンツ保管部に保管されているコンテンツに付随する制御情報を検査することにより、当該コンテンツの更新に関連する更新関連情報を推測し、前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果を、更新通知部が、前記ユーザに通知することを特徴とする。
【0011】
さらに、第3の本発明では、所定のコンテンツ提供システムから提供されたコンテンツを所定のコンテンツ保管機能に保管しておき、ユーザが通信端末から出力要求を送信してきたときには、前記コンテンツを当該通信端末へ供給する情報保管プログラムにおいて、コンピュータに、前記コンテンツ提供システムと通信することにより、当該コンテンツ提供システムから提供される前記コンテンツの更新に関連する更新関連情報を検出するコンテンツ更新検出機能または、すでに前記コンテンツ保管部に保管されているコンテンツに付随する制御情報を検査することにより、当該コンテンツの更新に関連する更新関連情報を推測するコンテンツ更新推測機能のいずれかを実現させ、前記コンテンツ更新検出機能による検出結果またはコンテンツ更新推測機能による推測結果を、前記ユーザに通知する更新情報通知機能を実現することを特徴とする。
【0012】
これによれば、前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果として、更新関連情報を、前記ユーザに通知することができる。
【0013】
【発明の実施の形態】
(A)実施形態
以下、本発明にかかる情報保管システム、情報保管方法、および情報保管プログラムを、仮想プリントシステムに適用した場合を例に、実施形態について説明する。
【0014】
仮想プリントシステムは、インターネット上に配置した仮想プリントサーバを中心としたシステムで、このシステムに会員として登録した前記コンテンツ利用会員は、仮想プリントサービスが提供するコンテンツを利用することができる。仮想プリントサービスでは、各コンテンツ利用会員は、自身が携帯する携帯電話機などを活用しながら、コンビニエンスストアや駅など、人が多く集まる場所に設置されたMMK(マルチメディアキオスク)端末から所望の画像の印刷出力や画面表示出力を受けることができる。必要に応じて、MMK端末の替わりに当該携帯電話機から当該コンテンツの画面表示出力を行ってもよいことは当然である。
【0015】
(A−1)実施形態の構成
本実施形態の仮想プリントシステム10の全体構成例を図1に示す。
【0016】
図1において、当該仮想プリントシステム10は、インターネット11と、携帯電話ネットワーク12と、仮想プリントサーバ13と、MMK端末14と、コンテンツサーバ15と、携帯電話機16とを備えている。
【0017】
このうち携帯電話機16は、直接的には、所定の携帯電話事業者が運営する携帯電話ネットワーク12に属するが、当該携帯電話ネットワーク12およびインターネット11を経由することで、コンテンツサーバ15および仮想プリントサーバ13と通信することができる。当該携帯電話機16は、前記コンテンツ利用会員の一人であるユーザU1によって携帯され、使用される。
【0018】
本実施形態の構成上、当該携帯電話機16はWebブラウザとメーラを搭載している必要がある。
【0019】
コンテンツサーバ15は、前記コンテンツ提供会員(コンテンツプロバイダ)の一つであるコンテンツプロバイダCP1によって運営されるサーバで、所定のコンテンツCT11を提供する機能を備えている。当該コンテンツサーバ15が提供するコンテンツは、1種類であってもよく、複数種類であってもよい。コンテンツサーバ15は、コンテンツを提供することができさえすれれば、どのような方法で提供してもかまわない。例えば、FTPプロトコルなどを利用してコンテンツを提供するものであってもかまわないが、ここでは、HTTPプロトコルを利用してコンテンツを提供するものとする。したがって、当該コンテンツサーバ15は、Webサーバ機能を備えている。
【0020】
仮想プリントサーバ13は、前記仮想プリントサービスを提供する事業者EP1によって運営されるサーバである。上述したように、コンテンツプロバイダCP1はコンテンツ提供会員として仮想プリントサーバ13に会員登録されており、ユーザU1はコンテンツ利用会員として仮想プリントサーバ13に会員登録されている。
【0021】
図1にはコンテンツ提供会員とコンテンツ利用会員を一人ずつしか図示していないが、仮想プリントサーバ13には通常、コンテンツ提供会員もコンテンツ利用会員も、多数が登録される。
【0022】
仮想プリントサーバ13は、コンテンツサーバ15などが提供するコンテンツ群のなかから、ユーザU1が指定するもの(それが、前記CT11であるとする)を、ユーザU1のために保管しておき、ユーザU1がMMK端末14を操作すること等によって要求すると、保管していたコンテンツCT11を送信し、当該MMK端末14から出力(印刷出力または画面表示出力)させる。
【0023】
携帯電話機16も画面表示を行う機能を搭載しているため、コンテンツCT11が携帯電話機向けに小さなサイズ(ビット数)で構成されたものであれば、携帯電話機16の画面で表示することも可能である。ただし、携帯電話機16の画面は寸法が小さいため、より大きなMMK端末14の画面に表示したほうがユーザU1にとって好都合なことも多い。また、携帯電話機16には印刷機能がないため、外出先など所望の場所で当該コンテンツCT11の印刷出力を行うにはMMK端末14を利用することが必要になる。
【0024】
図1には1つのMMK端末14しか図示していないが、仮想プリントシステムには通常、多数のMMK端末が含まれる。
【0025】
表示画面が小さく、印刷出力の機能を持たない携帯電話機16の機能を補完し、十分な大きさで高精細な画面表示出力や印刷出力を、ユーザU1の移動先の近傍で行わせ、仮想プリントサービスの実効性を高めるためには、高い密度でMMK端末を分布させることが必要となるからである。少なくとも市街地の人が多く集まる場所には、高い密度でMMK端末が分布しており、仮想プリントサーバ13と携帯電話機16のあいだで行うメッセージ交換に応じて、ユーザU1の現在位置の近傍に存在する複数のMMK端末のなかから所望のMMK端末を選択する構成となる。また、この選択を受けて、仮想プリントサーバ13や該当するMMK端末(例えば、14)は、当該ユーザU1が求めるコンテンツCT11を速やかに出力(画面表示出力または印刷出力)するための準備を整え、実際にそのユーザU1が選択したMMK端末(例えば、14)まで移動して所定の操作を行ったときには、当該MMK端末から、当該画像の出力が直ちに実行される手順になる。
【0026】
コンテンツ出力用の端末として、携帯電話機16を選ぶか、MMK端末14を選ぶかは、予めユーザU1が指定することができる。コンテンツCT11の種類が上述したニュースや天気予報などの場合には、印刷出力する必要性は高くないので、出力用の端末として携帯電話機が選ばれる可能性も高い。なお、本実施形態は、当該ニュースや天気予報などのように、高頻度で、ほぼ定期的に更新されるコンテンツに対しても有効であるが、いつ更新されるかは不明(予測困難)であるが、その更新に対しユーザU1が重大な関心を持っているコンテンツなどに対して、より有効であるといえる。
【0027】
ユーザU1が携帯する前記携帯電話機16の内部構成は、例えば、図2に示す通りである。また、前記MMK端末14の内部構成もこれと同じであってよい。ただし、MMK端末14の場合、印刷機能をともなうことは上述した通りである。この印刷機能は、MMK端末14に内蔵されている場合と、MMK端末14とは別個の装置(プリンタなど)としてMMK端末14に接続されている場合がある。
【0028】
(A−1−1)携帯電話機の内部構成例
図2において、当該携帯電話機16は、通信部20と、制御部21と、操作部22と、表示部23と、記憶部24とを備えている。
【0029】
このうち通信部20はインターネット11および携帯電話ネットワーク12を経由した前記仮想プリントサーバ13との通信のために機能する部分である。また、必要に応じて、インターネット11および携帯電話ネットワーク12経由で、コンテンツサーバ15との通信も行う。
【0030】
制御部21は、ハードウエア的には当該携帯電話機16のCPU(中央処理装置)に相当し、ソフトウエア的にはOS(オペレーティングシステム)、Webブラウザ、メーラなどの各種プログラムに相当する部分である。本実施形態では、基本的に、仮想プリントサーバ13から送信されたコンテンツCT11を携帯電話機16で画面表示する場合には、Webを使用し、各種の通知を仮想プリントサーバ13から受け取るためには、電子メール(通知メールME1)を使用するため、携帯電話機16はWebブラウザとメーラを搭載していることが必要である。
【0031】
携帯電話機の場合、電子メールが着信したことは着信音やバイブレーションによって即座にユーザに伝えられるため、携帯電話機16に届けられる通知メールME1の内容は、直ちにユーザU1に閲覧される可能性が高い。
【0032】
操作部22は、当該携帯電話機16を利用するユーザU1によって操作される部分である。携帯電話機の場合、操作部22は、パソコンのキーボードなどに比べると、はるかに寸法が小さく、操作キーの数も少ない。ただし、図2にMMK端末14を示したものとみる場合、操作部22は、携帯電話機よりもはるかに大きく、操作キーの数も十分であるので、携帯電話機16に比べると操作性が高い。
【0033】
表示部23は、前記ユーザU1が目視するための画面を表示するディスプレイ装置(例えば、LCD(液晶表示装置))に対応する部分で、前記操作部22とともにユーザインタフェースを構成する。コンテンツCT11を仮想プリントサーバ13から携帯電話機16に送信した場合には、ユーザU1は、この表示部23を介して、コンテンツCT11の内容を閲覧することになる。携帯性を要求される携帯電話機の性質上、携帯電話機16のボディサイズは小さくなり、必然的に、表示部23の画面サイズも小さくなる。
【0034】
これに対し、MMK端末14の場合には、固定的に設置して利用されるものであって、携帯性を要求されないため、表示部23の画面サイズも、携帯電話機16に比べるとはるかに大きい。したがって、携帯電話機16では、正確に表示することが困難な画像や、ビット数が大きすぎるために表示できない画像でも、MMK端末14には正確に表示することが可能である。
【0035】
前記記憶部24はハードウエア的には、RAM(ランダムアクセスメモリ)や、ハードディスクなどによって構成される記憶資源であり、ソフトウエア的には、各種のファイルがこの部分に含まれ得る。前記Webブラウザやメーラなどのプログラムファイルや、前記コンテンツCT11を収容したファイルなどもこのようなファイルの一例であるから、これらのファイルも、その物理的な実体は、この記憶部24に位置する。
【0036】
一方、インターネット11および携帯電話ネットワーク12を介して当該携帯電話機16と通信する仮想プリントサーバ13の内部構成は、例えば、図3に示すものであってよい。当該仮想プリントサーバ13は、携帯電話機16のほか、コンテンツサーバ15およびMMK端末14とも通信する。
【0037】
(A−1−2)仮想プリントサーバの内部構成例
図3において、当該仮想プリントサーバ13は、通信部30と、制御部31と、記憶部32と、更新通知受付部33と、予定通知受付部34と、定期アクセス部35と、比較解析部36と、更新予測部37と、通知メール生成部38と、更新内容要約部39と、フィルタリング部40と、通知条件制御部41とを備えている。
【0038】
このうち通信部30は前記通信部20に対応し、制御部31は前記制御部21に対応し、記憶部32は前記記憶部24に対応するので、その詳しい説明は省略する。
【0039】
ただし仮想プリントサーバ13はサーバ機能を提供する側なので、制御部31には、前記Webブラウザの替わりにWebサーバソフトなど各種サーバ機能が搭載される。また、当該制御部31には、CGIプログラムやWebサービス用のアプリケーションプログラムなどが搭載され得る。
【0040】
さらにまた、仮想プリントサーバ13は、携帯電話機16のほかに、コンテンツサーバ15やMMK端末14とも通信するので、通信部30もそのような通信に対応したものであることが必要である。
【0041】
ユーザU1からの指定に応じて、仮想プリントサーバ13が、コンテンツサーバ15から該当するコンテンツCT11を取得し、保管するための方法としては様々なものが考えられるが、この方法は、ユーザU1と仮想プリントサーバ13とのあいだの通信などとも関連する。
【0042】
例えば、ユーザU1が携帯電話機16でアクセス(HTTPリクエストメッセージHRQ1を送信)してくると、仮想プリントサーバ13が所定の構成のWebページ(HTTPレスポンスメッセージHRS1の本体)を当該携帯電話機16に返し、ユーザU1が前記表示部23により画面表示された当該Webページを目視しながら前記操作部22を操作して、当該Webページ上の所定の入力欄にコンテンツCT11を指定する情報(例えば、そのコンテンツCT11を指すURL)を入力してその入力内容(前回とは別個のHTTPリクエストメッセージHRQ2の本体)を送信すると、仮想プリントサーバ13側でも当該URLが分かるため、例えば、前記Webサービス用のアプリケーションが、当該URLをもとに前記コンテンツサーバ15へアクセス(HTTPリクエストメッセージHRQ3を送信)し、当該URLが指定するコンテンツCT11(HTTPレスポンスメッセージHRS2の本体)を、当該コンテンツサーバ15から受け取るという方法であってもよい。
【0043】
また、携帯電話機16(あるいは、図示しないユーザU1のパソコンなど)から直接、コンテンツサーバ15にコンテンツCT11の送信を指示し、この指示に応じて、コンテンツサーバ15から仮想プリントサーバ13へ当該コンテンツCT11を送信するという方法を用いることもできる。この場合には、通信手段として、FTPプロトコルの利用が可能である。
【0044】
前記記憶部32には、仮想プリントサーバ13が各コンテンツ提供会員やコンテンツ利用会員を管理するためのユーザ管理データベースUM1や、各コンテンツ利用会員のためにコンテンツを保管する保管部が設けられている。ここで、前記ユーザU1のための保管部をRC1とする。したがって、前記コンテンツCT11は、当該保管部RC1に保管されることになる。
【0045】
さらに、当該記憶部32は、仮想プリントサーバ13内の各構成要素33〜41が処理を実行するために必要な各種の情報や、作業用の記憶領域などを提供する。
【0046】
構成要素33〜41のうち定期アクセス部35は、前記コンテンツサーバ15に対して繰り返しHTTPリクエストメッセージを送信することによって、コンテンツサーバ15からHTTPレスポンスメッセージを取得するための部分である。
【0047】
HTTPレスポンスメッセージにどのような情報が含まれるかは、HTTPリクエストメッセージのメソッドに応じて変化する。一般的なGETメソッドを用いた場合、ヘッダ情報(制御情報)とともに、ファイルの本体(すなわち、ここでは、コンテンツCT11そのもの)が当該HTTPレスポンスメッセージに含まれる。これに対しHEADメソッドを用いると制御情報だけが当該HTTPEレスポンスメッセージに含まれる。
【0048】
この制御情報には多種多様な情報が含まれているが、本実施形態にとって重要なものは、更新日と有効期限である。更新日とは、コンテンツ(ここでは、CT11)を更新した日時を示す情報であり、有効期限とは、コンテンツプロバイダCP1側が指定する当該コンテンツCT11の有効期限である。
【0049】
有効期限は、ユーザ(例えば、U1)に提供されるコンテンツが更新後の最新のものであること(コンテンツの最新性)を確保するために設定される制御情報で、キャッシュサーバ(あるいは、多くのWebブラウザ)によって使用される。キャッシュサーバ(あるいは、多くのWebブラウザ)は、一度、HTTPレスポンスメッセージによって取得したコンテンツは、ローカルの記憶資源にキャッシュしておく機能がある。コンテンツをキャッシュしてある場合、URLを指定すること等によりそのコンテンツ(例えば、CT11)の取得をユーザ(例えば、U1)がふたたび要求すると、基本的に、コンテンツの提供元のWebサーバにHTTPリクエストメッセージを送信することなく、キャッシュしてあるコンテンツを読み出して画面表示し、ユーザU1に閲覧させる。これによって、通信トラフィックを抑制し、見かけ上のレスポンス性能を高めるものである。
【0050】
しかしながら、当該キャッシュサーバ(あるいは、多くのWebブラウザ)は、前記有効期限が切れた場合には、キャッシュしてあるコンテンツを削除し、コンテンツの提供元のWebサーバにHTTPリクエストメッセージを送信して、直接、コンテンツを取得することになる。したがって、有効期限はコンテンツの最新性を確保するための制御情報であるといえ、コンテンツプロバイダCP1側でそのコンテンツCT11を近い将来、更新しようと意図している場合には、短い有効期限を設定し、更新の予定がない場合などには長い有効期限を設定する傾向がある。
【0051】
更新日や有効期限などの制御情報は、本来、このようにWebブラウザやキャッシュサーバなどが制御用に利用するための情報であるから、通常は、ユーザU1の目に触れることはない。
【0052】
また、前記制御情報のうちコンテンツのデータ形式(MIMEタイプ)やファイルサイズ(ビット数)などを示す制御情報も、有用である。
【0053】
例えば、データ形式が変わっていれば更新があったことが分かるし、ファイルサイズが変わっていても更新があったことがわかる。ただし、データ形式やファイルサイズが変わっていなかったとしても、それをもって更新がなかったと判定することはできないことは当然である。
【0054】
定期アクセス部35による前記コンテンツサーバ15に対するHTTPリクエストメッセージの送信は、予め設定した時間間隔(例えば、3時間など)にしたがって周期的に行ってもよく、予め設定したスケジュール(例えば、毎日、午前9時と、午後12時と、午後6時に送信するというスケジュールなど)にしたがって行ってもよい。また、その周期やスケジュールは、ユーザU1からの指示に応じて動的に変更できるようにすることも望ましい。
【0055】
前記比較解析部36は、当該定期アクセス部35が送信したHTTPリクエストメッセージに対してコンテンツサーバ15から返送されてきたHTTPレスポンスメッセージの内容などを解析する部分で、解析結果として、更新の有無や日時などを得る。
【0056】
HTTPレスポンスメッセージに含まれる例えば前記更新日を、保管部RC1に保管してあるコンテンツCT11の更新日と比較すれば、保管してあるコンテンツCT11が最新のものであるか否か、すなわち、当該コンテンツCT11の保管後にコンテンツサーバ15側で当該コンテンツCT11の内容の更新が行われたか否かが分かる。
【0057】
このように更新日などの制御情報を取り扱うことは、一般的に、コンテンツの内容そのものを取り扱う場合に比べ、仮想プリントサーバ13の処理能力にかかる負荷がはるかに小さく、短時間で処理を行うことができるので効率的である。
【0058】
ただし更新日などの情報は、コンテンツサーバ15側で適切な管理が行われていなければ、不正確なこともあり、例えば、実際にはコンテンツCT11の内容が更新されているのに、制御情報としての更新日の情報は従前のままである等ということも起こり得る。このような矛盾を検出し正確な対応を行うためには、予め保管してあったものと、今回、HTTPレスポンスメッセージに含まれて届いたものとのあいだで、コンテンツCT11の内容そのものを比較することが必要になる。
【0059】
したがって、当該比較解析部36は、必要に応じて、前記更新日などの制御情報ではなく、コンテンツCT11の内容そのものを比較することで、更新の有無などを検出するようにしてもよい。また、内容そのものを比較することにより、更新の程度(内容が大幅に更新されたか、一部だけ更新されたか等)を検出したり、更新の詳細を検出すること等も可能となる。
【0060】
なお、制御情報として更新日ではなく、有効期限を比較することも有用である。
【0061】
例えば、前回に比べて短い有効期限を設定してきた場合には、コンテンツCT11の更新が近いと予測することもできるからである。このような方法で、更新の予測を行うのが、前記更新予測部37である。
【0062】
更新通知受付部33は、コンテンツサーバ15側が明示的に更新したことを通知してきた場合、その通知情報(明示的更新通知情報)を受け付ける部分である。
【0063】
前記比較解析部56による処理は、コンテンツサーバ15側が特別な処理を行わなくても、通常のHTTPプロトコルによる通信によって得られる情報だけをもとに実行可能であったが、この更新通知受付部33は、コンテンツサーバ15側が明示的更新通知情報を生成し、送信してくることが前提となる。
【0064】
上述したように、仮想プリントサーバ13のコンテンツ提供会員は多数であるので、コンテンツ提供会員によっては、運用するコンテンツサーバ(15に対応)が、明示的更新通知情報を生成し、送信する機能を持たないこともあり、また、そのような機能を持っているコンテンツサーバであっても、コンテンツによっては、明示的更新通知情報の生成を行わない場合などもあり得るので、仮想プリントサーバ13側では、ほぼ同一の目的を達成するために、このように多様な手段を用意しておくことは好ましいといえる。
【0065】
明示的更新通知情報を、コンテンツサーバ15から仮想プリントサーバ13まで届けるための通信手段としては様々なものが利用可能である。例えば、コンテンツサーバ15側の特定のURL(明示的更新通知情報のためのURL)に仮想プリントサーバ13側から短い時間間隔(例えば、600秒間隔程度。この時間間隔が十分に短ければ、実質的にコンテンツサーバ15側からプッシュ型の通信を行うのに等しいといえる)で定期的にHTTPリクエストメッセージを送信し、HTTPレスポンスメッセージの本体として当該明示的更新通知情報を取得すること等も可能であるが、電子メールを利用することも簡便である。ここでは、当該電子メール(この電子メールを、中間通知メールMECとする)を使用するものとする。
【0066】
前記予定通知受付部34は当該更新通知受付部33に対応する構成要素である。受け付ける情報が、更新通知受付部33のように、更新があったことを明示的に通知する明示的更新通知情報ではなく、更新の予定があることを明示的に通知する明示的更新予定通知情報である点が相違するだけである。したがって、当該明示的更新予定通知情報を届けるための通信手段も、前記中間通知メールMECである。
【0067】
なお、この明示的更新予定通知情報の持つ意味は、前記制御情報の1つである有効期限に類似しているといえるが、有効期限を短く設定したからといって必ず更新が近いという保証がないのに対し、明示的更新予定通知情報で通知される更新予定日時は、更新の予定日時を示すものであることが保証されている点が相違する。換言するなら、短い有効期限を設定したからといってコンテンツプロバイダCP1側に近日中に更新を行う責任が発生するわけではないが、明示的更新予定通知情報を通知した場合には、その明示的更新予定通知情報で指定した更新予定日時に更新を行う責任が発生するといえる。
【0068】
通知メール生成部38は、前記ユーザU1に更新があったこと等を伝える所定の通知メールME1を生成する部分である。実際に更新があったこと(前記比較解析部36または更新通知受付部33によって得られる)のほか更新の予測結果、(前記更新予測部37による)や、(前記予定通知受付部34によって得られる)更新の予定日時(明示的更新予定通知情報の内容)などの各種情報が当該通知メールME1に記載される。
【0069】
また、次の更新内容要約部39が機能する場合には、更新内容の要約を示す要約情報(例えば、更新の内容を説明する説明文など)が、当該通知メールME1に含まれることになる。
【0070】
当該更新内容要約部39は、前記要約情報を生成する部分である。当該要約情報は、コンテンツCT11に関して行われた更新がどのようなものであるかを示す情報である。例えば、前記比較解析部36がコンテンツCT11の内容そのものを比較することによって、更新の有無を検出した場合などには、その比較の過程で使用されたコンテンツCT11の内容から、当該要約情報を生成することも可能である。
【0071】
また、コンテンツサーバ15側で当該要約情報を作成し、明示的更新通知情報や明示的更新予定通知情報とともに、前記中間通知メールMECによって、仮想プリントサーバ13側へ届けるようにしてもよい。明示的更新予定通知情報とともに届ける要約情報は、現に実行された更新の要約ではなく、これから実行される更新の要約を示す予告である。ただし現実には、このような要約を生成することは必ずしも容易ではない。
【0072】
そこで、更新の要約の替わりに、更新の概要を、例えば、ファイル名などの形で示すようにすれば簡便である。これは、あるコンテンツCT11の更新前と更新後でそのファイル名が変更された場合には、変更前と変更後のファイル名を表示するものである。ファイル名の付け方に注意すれば、ファイル名によって更新の概要を適切に表現することは可能である。
【0073】
なお、更新の概要とともに、または更新の概要に替えて、当該更新に関連性のある情報や、ユーザU1に伝えたい情報をトピックスとして通知することも望ましい。
【0074】
このトピックスは、コンテンツサーバ15側で生成してもよく、仮想プリントサーバ13側で生成してもよい。
【0075】
更新の概要とトピックスを通知メールME1の本文部分に記載した場合、当該通知メールME1を受信した携帯電話機15の表示部23には、例えば、図10に示す画面が表示されることになる。
【0076】
図10において、「コンテンツN11」はコンテンツCT11の更新前のファイル名であり、「コンテンツM11」は当該コンテンツCT11の更新後のファイル名である。また、図10の例では、トピックスとして、日経平均株価や天気予報に関する情報などが含まれている。
【0077】
前記フィルタリング部40は、更新等が行われたコンテンツの内容に応じて、前記通知メールME1を送信するか否かを決定する部分である。どのような更新が行われた場合(または、これから行われる場合)に通知してほしいかを示すフィルタリング条件を、予めユーザU1が指定しておけば、そのフィルタリング条件に応じて、当該フィルタリング部40が前記通知メールME1を送信するか否かを決定することになる。
【0078】
これにより、ユーザU1は真に必要とする通知メールME1だけを受信し閲覧することができる。同様なフィルタリング条件は、コンテンツサーバ15(コンテンツプロバイダCP1)側からも指定できるようにすることが望ましい。
【0079】
例えば、コンテンツを予め分野(カテゴリ)別に分類しておき、ユーザU1やコンテンツプロバイダCP1にとっての各カテゴリの重要さ(重要度)を指定することをもって、当該フィルタリング条件の設定とすることができる。
【0080】
この場合、ユーザU1およびコンテンツプロバイダCP1のフィルタリング条件をまとめると、例えば、図11に示すフィルタリング表のようになる。図11において、「×」はフィルタリングされて通知(送信)されないことを示し、「○」はフィルタリングされず通知(送信)されることを示す。
【0081】
例えば、コンテンツプロバイダCP1がコンテンツとして各種のニュースを提供しているものとする。この場合、ニュースはいくつかの分野(例えば、「政治情報」分野、「証券情報」分野などの各分野)に分かれ、個々のコンテンツ(個々のニュース)はいずれかの分野に属する。ニュースの分野のうち、コンテンツプロバイダCP1は、「証券情報」分野の重要度を3に、「政治情報」分野の重要度を2に指定したものとし、ユーザU1が、「証券情報」分野の重要度を5に「政治情報」分野の重要度を1に指定したものとすると、「政治情報」分野のニュースは、図11上で位置PX2に相当し、「証券情報」分野のニュースは、位置PX1に相当する。したがって、「証券情報」分野のニュース(コンテンツ)が更新された場合などには、前記通知メールME1を送信してユーザU1に通知することになるが、「政治情報」分野のニュースが更新された場合などには、通知メールME1の送信を行わず、通知しない。
【0082】
このケースで、ユーザU1が例えば「政治情報」分野の重要度を1から4に変更すると、図11上の位置はPX2からPX3に移動するから、「政治情報」分野のニュースが更新された場合などにも、それを伝えるための通知メールME1が送信されることになる。
【0083】
通知条件制御部41は、前記通知メールME1を送信するか否かを決定する点は当該フィルタリング部40と同じであるが、その決定の根拠となる通知条件がコンテンツの内容(コンテンツの属する分野)ではなく、通知の外形的な条件である点が相違する。通知の外形的な条件には様々なものがあり得るが、例えば、通知メールME1を受け取ることのできる時刻、時間帯、1日に受け取ることが許容できる最大の通知メールME1の数などがあてはまる。
【0084】
また、CP1以外に多数のコンテンツプロバイダがコンテンツ提供会員として登録されており、なおかつ、ユーザU1が特にコンテンツプロバイダを指定せずに、コンテンツの種類を指定すること等により、前記通知メールME1の送信を依頼してあるケースなどでは、特定のコンテンツプロバイダを指定して、そのコンテンツプロバイダが提供するコンテンツの更新に関しては、通知メールME1を送信しないでほしいという条件を、当該通知条件として設定することも可能である。
【0085】
さらに、仮想プリントサーバ13側が前記携帯電話事業者から、携帯電話ネットワーク12内で管理している携帯電話機16の現在位置を示す位置情報や、当該位置情報をもとに生成でき、携帯電話機16が(したがってユーザU1が)移動中であるか否かを示す移動情報などを取得できる場合には、当該位置情報などを利用して通知条件を設定することもできる。例えば、当該位置情報を使用し、ある場所にいるときには通知メールME1を送信しないように指示する通知条件を設定したり、移動情報を使用して移動中には通知メールME1を送信しないように指示する通知条件を設定すること等も可能である。
【0086】
このような通知条件は、コンテンツ利用会員(例えば、U1)をグループ分けした上でグループごとに設定したり、全コンテンツ利用会員について包括的に同じ条件を設定したりすることも可能であるが、個々のコンテンツ利用会員からの指示に応じて設定できるようにすれば、コンテンツ利用会員にとって便利である。例えば、ユーザU1は、携帯電話機16などを用いて、自身のための通知条件を設定することができるものであってよい。
【0087】
次に、前記コンテンツサーバ15の内部構成例を図4に示す。
【0088】
(A−1−3)コンテンツサーバの内部構成例
図4において、当該コンテンツサーバ15は、通信部50と、制御部51と、記憶部52と、更新通知生成部53と、更新予定通知生成部54とを備えている。
【0089】
このうち通信部50は、前記通信部30に対応し、制御部51は前記制御部31に対応し、記憶部52は前記記憶部32に対応するので、その詳しい説明は省略する。
【0090】
更新通知生成部53は、上述した明示的更新通知情報を生成して中間通知メールMECを送信する際に機能する部分である。
【0091】
また、更新予定通知生成部54は、上述した明示的更新予定通知情報を生成して中間通知メールMECを送信する際に機能する部分である。
【0092】
以下、上記のような構成を有する本実施形態の動作について、図6〜図9のフローチャートを参照しながら説明する。
【0093】
図5のフローチャートはS10〜S15の各ステップから構成されており、図6のフローチャートはS20〜S25の各ステップから構成されており、図7のフローチャートはS30〜S34の各ステップから構成されており、図8のフローチャートはS40〜S43の各ステップから構成されており、図9のフローチャートはS50〜S54の各ステップから構成されている。
【0094】
(A−2)実施形態の動作
図5において、前記コンテンツサーバ15がユーザU1からの指示に応じてコンテンツ(ここでは、CT11とする)を仮想プリントサーバ13に送信すると、これを受信した仮想プリントサーバ13では、当該コンテンツCT11を前記保管部RC1に保管する(S10、S11)。
【0095】
このあと、仮想プリントサーバ13内の前記定期アクセス部35が例えば一定時間間隔で周期的に、コンテンツサーバ15へHTTPリクエストメッセージを送信し、このHTTPリクエストメッセージに対する応答としてコンテンツサーバ15から届くHTTPレスポンスメッセージを受信して、コンテンツCT11,すなわち、当該コンテンツCT11を格納したファイルの更新の有無を検査する(S12)。
【0096】
検査の結果、更新されていなければそのまま処理を終了し(S13,S15)、更新されていれば、前記通知メールME1を携帯電話機16宛てに送信することで、更新の事実をユーザU1に伝えてから(S14)、処理を終了する(S13,S15)。
【0097】
このように図5のフローチャートでは、仮想プリントサーバ13側から自動的にユーザU1にコンテンツCT11の更新があったことを通知するが、次の図6のフローチャートでは、ユーザU1からの問い合わせに応じて更新の有無を通知する。
【0098】
図6において、携帯電話機16を用いてユーザU1が仮想プリントサーバ13にコンテンツCT11の更新状況を問い合わせると(S20,S21)、仮想プリントサーバ13は前記コンテンツサーバ15にHTTPリクエストメッセージを送信すること等により、当該コンテンツCT11の更新の有無を確認する(S22)。
【0099】
当該ステップS22以降の各ステップは、図5と同様である。すなわち、ステップS23は前記ステップS13に対応し、ステップS24は前記ステップS14に対応し、ステップS25は前記ステップS15に対応する。
【0100】
ただし図6の場合、ユーザU1側から積極的に問い合わせてきたのであるから、更新が行われていないケースでも、更新が行われていない旨を通知するようにすることも望ましい。ここで、更新が行われていない旨を通知するためにも、前記通知メールME1が利用されることは当然である。
【0101】
図5,図6のフローチャートでは、ステップS13,S23でどのようにしてコンテンツの更新の有無を検査するかに関して特段、具体的に示していないため、すでに詳述したあらゆる方法を利用することができる。これに対し、図7のフローチャートは、コンテンツサーバ15側から、前記明示的更新通知情報(中間通知メールMEC)を積極的に送信してくるケースに対応するものである。
【0102】
図7において、ステップS30は前記ステップS10に対応し、ステップS31は前記ステップS11に対応する。
【0103】
ステップS31につづくステップS32では、前記中間通知メールMECにより、明示的更新通知情報が仮想プリントサーバ13に届けられる。これを受信した仮想プリントサーバ13では、更新の事実をユーザU1に伝えるため前記通知メールME1を送信して処理を終える(S33,S34)。
【0104】
次に、図8のフローチャートは、コンテンツサーバ15がコンテンツCT11を仮想プリントサーバ13へ送信する際、必要に応じて、当該コンテンツCT11とともに、前記明示的更新予定通知情報を送信するケースに対応するものである。コンテンツCT11を収容したファイルなどに、当該明示的更新予定通知情報を含めるようにしてもよいが、ファイルに明示的更新予定通知情報を配置するための標準的な規格などは存在しないので、そのような配置を行うには、コンテンツサーバ15と仮想プリントサーバ13のあいだで整合性の取れた固有の通信プロトコルを用いること等が必要になる。
【0105】
そのため、例えば、コンテンツCT11を送信した前後、所定の時間範囲内に前記中間通知電子メールMECを用いて明示的更新予定通知情報を通知すること等をもって、当該コンテンツCT11とともに明示的更新予定通知情報を送信したものとみなすことも簡便である。
【0106】
図8において、コンテンツサーバ15がコンテンツCT11を送信すると(S40)、それを受信した仮想プリントサーバ13では、当該コンテンツCT11とともに、前記明示的更新予定通知情報が含まれているか否かを検査して(S41)、含まれていれば、その明示的更新予定通知情報が示す更新の日時にユーザU1へ前記通知メールME1を送信し(S42)、含まれていなければ、直ちにこの処理を終了する(S43)。
【0107】
なお、明示的更新予定通知情報が示す更新の日時に通知メールME1を送信することに替えて(あるいは、送信することとともに)、「コンテンツN11は、○月×日に更新される予定です。」などと本文部分に記載した通知メールME1を、携帯電話機16に宛てて、更新予定日である○月×日の前に送信することも望ましい。
【0108】
最後に、図9のフローチャートには、上述した通知条件に対応する処理を示す。
【0109】
図9において、携帯電話機16などを用いて、ユーザU1が、仮想プリントサーバ13に自身のための前記通知条件を設定すると(S50,S51)、仮想プリントサーバ13が前記通知メールME1を送信しようとするときには、前記通知条件制御部41が動作して、当該通知条件に適合する送信のみを許可する(S52,S53,S54)。これにより、例えば、電子メールME1を受け取りたくない時間帯などに電子メールME1が着信することがなくなり、ユーザU1の利便性が高まる。
【0110】
(A−3)実施形態の効果
本実施形態によれば、ユーザ(U1)は、コンテンツ(CT11)の更新があった場合や、更新が予定される場合などに、その旨の通知(ME1)を受けることができるため、仮想プリントサービスの信頼性や利便性が向上する。
【0111】
これにより、例えば、すでに更新が行われたにもかかわらず、更新前の古いコンテンツを最新のコンテンツとして利用する等の矛盾が起きることも防止することが可能である。
【0112】
また、このような信頼性や利便性の向上は、コンテンツの最新性を確保してコンテンツの価値を高めることにも寄与するため、コンテンツを利用する側のコンテンツ利用会員(U1)にとって有益であるだけでなく、コンテンツを提供する側のコンテンツ提供会員(CP1)にとっても有益である。
【0113】
なお、本実施形態は、ニュースや天気予報などのように、高頻度で、ほぼ定期的に更新されるコンテンツに対しても有効であるが、いつ更新されるかは不明(予測困難)であるが、その更新に対しユーザ(U1)が重大な関心を持っているコンテンツなどに対して、より有効であるといえる。
【0114】
高頻度で更新されるコンテンツに対しては、頻繁に携帯電話機(16)などからHTTPリクエストメッセージを送信することもそれほど非効率ではないし、ほぼ定期的に更新されるコンテンツであれば、定期的な更新時期に合わせてHTTPリクエストメッセージを送信することも効率的であるが、更新時期が予測困難なコンテンツに対し、携帯電話機などから頻繁にHTTPリクエストメッセージを送信することは著しく非効率であるからである。
【0115】
本実施形態により、ユーザ(U1)は、このように更新時期が予測困難なコンテンツの更新時期を、効率的に知ることが可能となる。これにより、利便性が著しく向上することが期待できる。
【0116】
(B)他の実施形態
上記実施形態において、仮想プリントサーバ14に設けた構成要素33〜41の一部は省略することも可能である。例えば、更新予測部37と予定通知受付部34はいずれかを省略してもよい。また、フィルタリング部40と通知条件制御部41はいずれかを省略してもよい。さらに、更新通知受付部33と予定通知受付部34はいずれかを省略してもよい。さらにまた、更新内容要約部39は省略してもよい。また、更新通知受付部33または予定通知受付部34を設ける場合には、コンテンツサーバ15のほうから積極的に通知してくるのであるから、定期アクセス部35は省略してもよい。
【0117】
なお、上記実施形態において、コンテンツサーバ15に設けた更新通知生成部53、更新予定通知生成部54は、いずれか一方または双方を省略することが可能である。
【0118】
さらに、本発明の構成上、前記MMK端末14は必ずしも必須ではない。
【0119】
なお、前記電子メールME1やMECに含まれる各種の情報(明示的更新通知情報など)は、電子メールの本文部分に記載するのではなく、メールヘッダに専用の拡張フィールドを用意し、その拡張フィールドに記載するようにしてもよい。
【0120】
上記実施形態における携帯電話機は、PHS端末など、その他の移動情報端末に置換可能であることは当然である。
【0121】
また、前記通知メールME1を受け取るための通信端末は、携帯電話機などのように移動性のあるものが望ましいが、例えば、据え置き型のパソコンなどのように移動性のない通信端末であっても、一定の効果は期待できる。
【0122】
さらに、上記実施形態では電子メール(通知メールME1)を用いて通知を行ったが、ユーザU1の通信端末がプッシュ型のクライアントソフトを搭載している場合などには、必ずしも電子メールを用いる必要はない。
【0123】
例えば、当該通信端末のWebブラウザに、十分に短い時間間隔で定期的にHTTPリクエストメッセージを送信し、HTTPレスポンスメッセージの本体として前記通知メールME1と同様な内容を有するファイルを受信できるようにした上、有効なファイルが受信できた場合にのみ画面表示などを実行してユーザU1に伝える機能を搭載することによって、当該電子メール(ME1)に替えることが可能である。
【0124】
なお、前記インターネットは、その他のネットワークに置換可能である。例えば、特定の通信事業者が構築したIPネットワーク、IP−VPN網、広域イーサネット(登録商標)網や、その他のWAN(ワイドエリアネットワーク)などで置換することも可能である。
【0125】
以上の説明では主としてハードウエア的に本発明を実現したが、本発明はソフトウエア的に実現することも可能である。
【0126】
【発明の効果】
以上に説明したように、本発明によれば、信頼性および利便性を高めることができる。
【図面の簡単な説明】
【図1】実施形態に係る仮想プリントシステムの全体構成例を示す概略図である。
【図2】実施形態で使用する携帯電話機の内部構成例を示す概略図である。
【図3】実施形態で使用する仮想プリントサーバの内部構成例を示す概略図である。
【図4】実施形態で使用するコンテンツサーバの内部構成例を示す概略図である。
【図5】実施形態の動作例を示すフローチャートである。
【図6】実施形態の動作例を示すフローチャートである。
【図7】実施形態の動作例を示すフローチャートである。
【図8】実施形態の動作例を示すフローチャートである。
【図9】実施形態の動作例を示すフローチャートである。
【図10】実施形態で使用する携帯電話機の受信画面の一例を示す概略図である。
【図11】実施形態の動作説明図である。
【符号の説明】
10…仮想プリントシステム、11…インターネット、12…携帯電話ネットワーク、13…仮想プリントサーバ、14…MMK端末、15…コンテンツサーバ、16…携帯電話機、20,30,50…通信部、21,31,51…制御部、22…操作部、23…表示部、24,43,52…記憶部、33…更新通知受付部、34…予定通知受付部、35…定期アクセス部、36…比較解析部、37…更新予測部、38…通知メール生成部、39…更新内容要約部、40…フィルタリング部、41…通知条件制御部、53…更新通知生成部、54…更新予定通知生成部、MEC…中間通知メール、ME1…通知メール、CT11…コンテンツ。
【発明の属する技術分野】
本発明は情報保管システム、情報保管方法、および情報保管プログラムに関し、例えば、コンテンツプロバイダから提供されるコンテンツを、仮想プリントサーバに保管しておき、求めに応じて各ユーザに供給する場合などに適用して好適なものである。
【0002】
【従来の技術】
従来、インターネット上では、Webページなどの形で各ユーザに様々なコンテンツが提供されている。
【0003】
所定の仮想プリントサービスを提供する仮想プリントサーバは、会員として、コンテンツの提供元であるコンテンツプロバイダ(コンテンツ提供会員)と、そのコンテンツの提供を受けるユーザ(コンテンツ利用会員)を登録し、会員制の仮想プリントサービスを提供している。
【0004】
当該仮想プリントサーバは、前記コンテンツ提供会員が運用するWebサーバ等と、前記コンテンツ利用会員のあいだに介在し、コンテンツ利用会員からの要求に応じてコンテンツを提供する。
【0005】
すなわち、前記Webサーバ等から供給されるコンテンツは、いったん仮想プリントサーバ内に保管された上で、前記コンテンツ利用会員からの要求に応じて仮想プリントサーバから送信し、当該コンテンツ利用会員が操作するMMK端末などから出力(印刷出力または画面表示出力)する構成となる。
【0006】
【発明が解決しようとする課題】
ところで、上述したコンテンツの種類は多種多様であり、ほとんど更新されないものもあるが、更新されるものも多い。当該コンテンツが例えば、天気予報やニュースなどである場合には、更新は頻繁に行われる。そのコンテンツの提供を希望する以上、前記コンテンツ利用会員は、そのコンテンツの更新については関心があるはずであるが、従来は、コンテンツの更新が行われたことをコンテンツ利用会員に通知する方法がなかった。
【0007】
そのため、例えば、すでに更新が行われたにもかかわらず、更新前の古いコンテンツを最新のコンテンツとして利用する等の矛盾が起きる可能性があるなど、信頼性や利便性に欠けていた。
【0008】
この意味の信頼性や利便性を高めることは、コンテンツ提供会員にとっても重要である。
【0009】
【課題を解決するための手段】
かかる課題を解決するために、第1の本発明では、所定のコンテンツ提供システム(例えば、コンテンツサーバ15など)から提供されたコンテンツ(例えば、コンテンツCT11など)を所定のコンテンツ保管部(例えば、保管部RC1など)に保管しておき、ユーザ(例えば、ユーザU1など)が通信端末(例えば、携帯電話機16など)から出力要求を送信してきたときには、前記コンテンツを当該通信端末へ供給する情報保管システム(例えば、仮想プリントシステム10など)において、
前記コンテンツ提供システムと通信することにより、当該コンテンツ提供システムから提供される前記コンテンツの更新に関連する更新関連情報を検出するコンテンツ更新検出部(例えば、更新通知受付部33など)または、すでに前記コンテンツ保管部に保管されているコンテンツに付随する制御情報(例えば、HTTPレスポンスメッセージに含まれる更新日、有効期限など)を検査することにより、当該コンテンツの更新に関連する更新関連情報を推測するコンテンツ更新推測部(例えば、更新予測部37など)のいずれかを備え、前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果を、前記ユーザに通知する更新情報通知部(例えば、通知メール生成部38など)を有することを特徴とする。
【0010】
また、第2の本発明では、所定のコンテンツ提供システムから提供されたコンテンツを所定のコンテンツ保管部に保管しておき、ユーザが通信端末から出力要求を送信してきたときには、前記コンテンツを当該通信端末へ供給する情報保管方法において、コンテンツ更新検出部が、前記コンテンツ提供システムと通信することにより、当該コンテンツ提供システムから提供される前記コンテンツの更新に関連する更新関連情報を検出するか、または、コンテンツ更新推測部が、すでに前記コンテンツ保管部に保管されているコンテンツに付随する制御情報を検査することにより、当該コンテンツの更新に関連する更新関連情報を推測し、前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果を、更新通知部が、前記ユーザに通知することを特徴とする。
【0011】
さらに、第3の本発明では、所定のコンテンツ提供システムから提供されたコンテンツを所定のコンテンツ保管機能に保管しておき、ユーザが通信端末から出力要求を送信してきたときには、前記コンテンツを当該通信端末へ供給する情報保管プログラムにおいて、コンピュータに、前記コンテンツ提供システムと通信することにより、当該コンテンツ提供システムから提供される前記コンテンツの更新に関連する更新関連情報を検出するコンテンツ更新検出機能または、すでに前記コンテンツ保管部に保管されているコンテンツに付随する制御情報を検査することにより、当該コンテンツの更新に関連する更新関連情報を推測するコンテンツ更新推測機能のいずれかを実現させ、前記コンテンツ更新検出機能による検出結果またはコンテンツ更新推測機能による推測結果を、前記ユーザに通知する更新情報通知機能を実現することを特徴とする。
【0012】
これによれば、前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果として、更新関連情報を、前記ユーザに通知することができる。
【0013】
【発明の実施の形態】
(A)実施形態
以下、本発明にかかる情報保管システム、情報保管方法、および情報保管プログラムを、仮想プリントシステムに適用した場合を例に、実施形態について説明する。
【0014】
仮想プリントシステムは、インターネット上に配置した仮想プリントサーバを中心としたシステムで、このシステムに会員として登録した前記コンテンツ利用会員は、仮想プリントサービスが提供するコンテンツを利用することができる。仮想プリントサービスでは、各コンテンツ利用会員は、自身が携帯する携帯電話機などを活用しながら、コンビニエンスストアや駅など、人が多く集まる場所に設置されたMMK(マルチメディアキオスク)端末から所望の画像の印刷出力や画面表示出力を受けることができる。必要に応じて、MMK端末の替わりに当該携帯電話機から当該コンテンツの画面表示出力を行ってもよいことは当然である。
【0015】
(A−1)実施形態の構成
本実施形態の仮想プリントシステム10の全体構成例を図1に示す。
【0016】
図1において、当該仮想プリントシステム10は、インターネット11と、携帯電話ネットワーク12と、仮想プリントサーバ13と、MMK端末14と、コンテンツサーバ15と、携帯電話機16とを備えている。
【0017】
このうち携帯電話機16は、直接的には、所定の携帯電話事業者が運営する携帯電話ネットワーク12に属するが、当該携帯電話ネットワーク12およびインターネット11を経由することで、コンテンツサーバ15および仮想プリントサーバ13と通信することができる。当該携帯電話機16は、前記コンテンツ利用会員の一人であるユーザU1によって携帯され、使用される。
【0018】
本実施形態の構成上、当該携帯電話機16はWebブラウザとメーラを搭載している必要がある。
【0019】
コンテンツサーバ15は、前記コンテンツ提供会員(コンテンツプロバイダ)の一つであるコンテンツプロバイダCP1によって運営されるサーバで、所定のコンテンツCT11を提供する機能を備えている。当該コンテンツサーバ15が提供するコンテンツは、1種類であってもよく、複数種類であってもよい。コンテンツサーバ15は、コンテンツを提供することができさえすれれば、どのような方法で提供してもかまわない。例えば、FTPプロトコルなどを利用してコンテンツを提供するものであってもかまわないが、ここでは、HTTPプロトコルを利用してコンテンツを提供するものとする。したがって、当該コンテンツサーバ15は、Webサーバ機能を備えている。
【0020】
仮想プリントサーバ13は、前記仮想プリントサービスを提供する事業者EP1によって運営されるサーバである。上述したように、コンテンツプロバイダCP1はコンテンツ提供会員として仮想プリントサーバ13に会員登録されており、ユーザU1はコンテンツ利用会員として仮想プリントサーバ13に会員登録されている。
【0021】
図1にはコンテンツ提供会員とコンテンツ利用会員を一人ずつしか図示していないが、仮想プリントサーバ13には通常、コンテンツ提供会員もコンテンツ利用会員も、多数が登録される。
【0022】
仮想プリントサーバ13は、コンテンツサーバ15などが提供するコンテンツ群のなかから、ユーザU1が指定するもの(それが、前記CT11であるとする)を、ユーザU1のために保管しておき、ユーザU1がMMK端末14を操作すること等によって要求すると、保管していたコンテンツCT11を送信し、当該MMK端末14から出力(印刷出力または画面表示出力)させる。
【0023】
携帯電話機16も画面表示を行う機能を搭載しているため、コンテンツCT11が携帯電話機向けに小さなサイズ(ビット数)で構成されたものであれば、携帯電話機16の画面で表示することも可能である。ただし、携帯電話機16の画面は寸法が小さいため、より大きなMMK端末14の画面に表示したほうがユーザU1にとって好都合なことも多い。また、携帯電話機16には印刷機能がないため、外出先など所望の場所で当該コンテンツCT11の印刷出力を行うにはMMK端末14を利用することが必要になる。
【0024】
図1には1つのMMK端末14しか図示していないが、仮想プリントシステムには通常、多数のMMK端末が含まれる。
【0025】
表示画面が小さく、印刷出力の機能を持たない携帯電話機16の機能を補完し、十分な大きさで高精細な画面表示出力や印刷出力を、ユーザU1の移動先の近傍で行わせ、仮想プリントサービスの実効性を高めるためには、高い密度でMMK端末を分布させることが必要となるからである。少なくとも市街地の人が多く集まる場所には、高い密度でMMK端末が分布しており、仮想プリントサーバ13と携帯電話機16のあいだで行うメッセージ交換に応じて、ユーザU1の現在位置の近傍に存在する複数のMMK端末のなかから所望のMMK端末を選択する構成となる。また、この選択を受けて、仮想プリントサーバ13や該当するMMK端末(例えば、14)は、当該ユーザU1が求めるコンテンツCT11を速やかに出力(画面表示出力または印刷出力)するための準備を整え、実際にそのユーザU1が選択したMMK端末(例えば、14)まで移動して所定の操作を行ったときには、当該MMK端末から、当該画像の出力が直ちに実行される手順になる。
【0026】
コンテンツ出力用の端末として、携帯電話機16を選ぶか、MMK端末14を選ぶかは、予めユーザU1が指定することができる。コンテンツCT11の種類が上述したニュースや天気予報などの場合には、印刷出力する必要性は高くないので、出力用の端末として携帯電話機が選ばれる可能性も高い。なお、本実施形態は、当該ニュースや天気予報などのように、高頻度で、ほぼ定期的に更新されるコンテンツに対しても有効であるが、いつ更新されるかは不明(予測困難)であるが、その更新に対しユーザU1が重大な関心を持っているコンテンツなどに対して、より有効であるといえる。
【0027】
ユーザU1が携帯する前記携帯電話機16の内部構成は、例えば、図2に示す通りである。また、前記MMK端末14の内部構成もこれと同じであってよい。ただし、MMK端末14の場合、印刷機能をともなうことは上述した通りである。この印刷機能は、MMK端末14に内蔵されている場合と、MMK端末14とは別個の装置(プリンタなど)としてMMK端末14に接続されている場合がある。
【0028】
(A−1−1)携帯電話機の内部構成例
図2において、当該携帯電話機16は、通信部20と、制御部21と、操作部22と、表示部23と、記憶部24とを備えている。
【0029】
このうち通信部20はインターネット11および携帯電話ネットワーク12を経由した前記仮想プリントサーバ13との通信のために機能する部分である。また、必要に応じて、インターネット11および携帯電話ネットワーク12経由で、コンテンツサーバ15との通信も行う。
【0030】
制御部21は、ハードウエア的には当該携帯電話機16のCPU(中央処理装置)に相当し、ソフトウエア的にはOS(オペレーティングシステム)、Webブラウザ、メーラなどの各種プログラムに相当する部分である。本実施形態では、基本的に、仮想プリントサーバ13から送信されたコンテンツCT11を携帯電話機16で画面表示する場合には、Webを使用し、各種の通知を仮想プリントサーバ13から受け取るためには、電子メール(通知メールME1)を使用するため、携帯電話機16はWebブラウザとメーラを搭載していることが必要である。
【0031】
携帯電話機の場合、電子メールが着信したことは着信音やバイブレーションによって即座にユーザに伝えられるため、携帯電話機16に届けられる通知メールME1の内容は、直ちにユーザU1に閲覧される可能性が高い。
【0032】
操作部22は、当該携帯電話機16を利用するユーザU1によって操作される部分である。携帯電話機の場合、操作部22は、パソコンのキーボードなどに比べると、はるかに寸法が小さく、操作キーの数も少ない。ただし、図2にMMK端末14を示したものとみる場合、操作部22は、携帯電話機よりもはるかに大きく、操作キーの数も十分であるので、携帯電話機16に比べると操作性が高い。
【0033】
表示部23は、前記ユーザU1が目視するための画面を表示するディスプレイ装置(例えば、LCD(液晶表示装置))に対応する部分で、前記操作部22とともにユーザインタフェースを構成する。コンテンツCT11を仮想プリントサーバ13から携帯電話機16に送信した場合には、ユーザU1は、この表示部23を介して、コンテンツCT11の内容を閲覧することになる。携帯性を要求される携帯電話機の性質上、携帯電話機16のボディサイズは小さくなり、必然的に、表示部23の画面サイズも小さくなる。
【0034】
これに対し、MMK端末14の場合には、固定的に設置して利用されるものであって、携帯性を要求されないため、表示部23の画面サイズも、携帯電話機16に比べるとはるかに大きい。したがって、携帯電話機16では、正確に表示することが困難な画像や、ビット数が大きすぎるために表示できない画像でも、MMK端末14には正確に表示することが可能である。
【0035】
前記記憶部24はハードウエア的には、RAM(ランダムアクセスメモリ)や、ハードディスクなどによって構成される記憶資源であり、ソフトウエア的には、各種のファイルがこの部分に含まれ得る。前記Webブラウザやメーラなどのプログラムファイルや、前記コンテンツCT11を収容したファイルなどもこのようなファイルの一例であるから、これらのファイルも、その物理的な実体は、この記憶部24に位置する。
【0036】
一方、インターネット11および携帯電話ネットワーク12を介して当該携帯電話機16と通信する仮想プリントサーバ13の内部構成は、例えば、図3に示すものであってよい。当該仮想プリントサーバ13は、携帯電話機16のほか、コンテンツサーバ15およびMMK端末14とも通信する。
【0037】
(A−1−2)仮想プリントサーバの内部構成例
図3において、当該仮想プリントサーバ13は、通信部30と、制御部31と、記憶部32と、更新通知受付部33と、予定通知受付部34と、定期アクセス部35と、比較解析部36と、更新予測部37と、通知メール生成部38と、更新内容要約部39と、フィルタリング部40と、通知条件制御部41とを備えている。
【0038】
このうち通信部30は前記通信部20に対応し、制御部31は前記制御部21に対応し、記憶部32は前記記憶部24に対応するので、その詳しい説明は省略する。
【0039】
ただし仮想プリントサーバ13はサーバ機能を提供する側なので、制御部31には、前記Webブラウザの替わりにWebサーバソフトなど各種サーバ機能が搭載される。また、当該制御部31には、CGIプログラムやWebサービス用のアプリケーションプログラムなどが搭載され得る。
【0040】
さらにまた、仮想プリントサーバ13は、携帯電話機16のほかに、コンテンツサーバ15やMMK端末14とも通信するので、通信部30もそのような通信に対応したものであることが必要である。
【0041】
ユーザU1からの指定に応じて、仮想プリントサーバ13が、コンテンツサーバ15から該当するコンテンツCT11を取得し、保管するための方法としては様々なものが考えられるが、この方法は、ユーザU1と仮想プリントサーバ13とのあいだの通信などとも関連する。
【0042】
例えば、ユーザU1が携帯電話機16でアクセス(HTTPリクエストメッセージHRQ1を送信)してくると、仮想プリントサーバ13が所定の構成のWebページ(HTTPレスポンスメッセージHRS1の本体)を当該携帯電話機16に返し、ユーザU1が前記表示部23により画面表示された当該Webページを目視しながら前記操作部22を操作して、当該Webページ上の所定の入力欄にコンテンツCT11を指定する情報(例えば、そのコンテンツCT11を指すURL)を入力してその入力内容(前回とは別個のHTTPリクエストメッセージHRQ2の本体)を送信すると、仮想プリントサーバ13側でも当該URLが分かるため、例えば、前記Webサービス用のアプリケーションが、当該URLをもとに前記コンテンツサーバ15へアクセス(HTTPリクエストメッセージHRQ3を送信)し、当該URLが指定するコンテンツCT11(HTTPレスポンスメッセージHRS2の本体)を、当該コンテンツサーバ15から受け取るという方法であってもよい。
【0043】
また、携帯電話機16(あるいは、図示しないユーザU1のパソコンなど)から直接、コンテンツサーバ15にコンテンツCT11の送信を指示し、この指示に応じて、コンテンツサーバ15から仮想プリントサーバ13へ当該コンテンツCT11を送信するという方法を用いることもできる。この場合には、通信手段として、FTPプロトコルの利用が可能である。
【0044】
前記記憶部32には、仮想プリントサーバ13が各コンテンツ提供会員やコンテンツ利用会員を管理するためのユーザ管理データベースUM1や、各コンテンツ利用会員のためにコンテンツを保管する保管部が設けられている。ここで、前記ユーザU1のための保管部をRC1とする。したがって、前記コンテンツCT11は、当該保管部RC1に保管されることになる。
【0045】
さらに、当該記憶部32は、仮想プリントサーバ13内の各構成要素33〜41が処理を実行するために必要な各種の情報や、作業用の記憶領域などを提供する。
【0046】
構成要素33〜41のうち定期アクセス部35は、前記コンテンツサーバ15に対して繰り返しHTTPリクエストメッセージを送信することによって、コンテンツサーバ15からHTTPレスポンスメッセージを取得するための部分である。
【0047】
HTTPレスポンスメッセージにどのような情報が含まれるかは、HTTPリクエストメッセージのメソッドに応じて変化する。一般的なGETメソッドを用いた場合、ヘッダ情報(制御情報)とともに、ファイルの本体(すなわち、ここでは、コンテンツCT11そのもの)が当該HTTPレスポンスメッセージに含まれる。これに対しHEADメソッドを用いると制御情報だけが当該HTTPEレスポンスメッセージに含まれる。
【0048】
この制御情報には多種多様な情報が含まれているが、本実施形態にとって重要なものは、更新日と有効期限である。更新日とは、コンテンツ(ここでは、CT11)を更新した日時を示す情報であり、有効期限とは、コンテンツプロバイダCP1側が指定する当該コンテンツCT11の有効期限である。
【0049】
有効期限は、ユーザ(例えば、U1)に提供されるコンテンツが更新後の最新のものであること(コンテンツの最新性)を確保するために設定される制御情報で、キャッシュサーバ(あるいは、多くのWebブラウザ)によって使用される。キャッシュサーバ(あるいは、多くのWebブラウザ)は、一度、HTTPレスポンスメッセージによって取得したコンテンツは、ローカルの記憶資源にキャッシュしておく機能がある。コンテンツをキャッシュしてある場合、URLを指定すること等によりそのコンテンツ(例えば、CT11)の取得をユーザ(例えば、U1)がふたたび要求すると、基本的に、コンテンツの提供元のWebサーバにHTTPリクエストメッセージを送信することなく、キャッシュしてあるコンテンツを読み出して画面表示し、ユーザU1に閲覧させる。これによって、通信トラフィックを抑制し、見かけ上のレスポンス性能を高めるものである。
【0050】
しかしながら、当該キャッシュサーバ(あるいは、多くのWebブラウザ)は、前記有効期限が切れた場合には、キャッシュしてあるコンテンツを削除し、コンテンツの提供元のWebサーバにHTTPリクエストメッセージを送信して、直接、コンテンツを取得することになる。したがって、有効期限はコンテンツの最新性を確保するための制御情報であるといえ、コンテンツプロバイダCP1側でそのコンテンツCT11を近い将来、更新しようと意図している場合には、短い有効期限を設定し、更新の予定がない場合などには長い有効期限を設定する傾向がある。
【0051】
更新日や有効期限などの制御情報は、本来、このようにWebブラウザやキャッシュサーバなどが制御用に利用するための情報であるから、通常は、ユーザU1の目に触れることはない。
【0052】
また、前記制御情報のうちコンテンツのデータ形式(MIMEタイプ)やファイルサイズ(ビット数)などを示す制御情報も、有用である。
【0053】
例えば、データ形式が変わっていれば更新があったことが分かるし、ファイルサイズが変わっていても更新があったことがわかる。ただし、データ形式やファイルサイズが変わっていなかったとしても、それをもって更新がなかったと判定することはできないことは当然である。
【0054】
定期アクセス部35による前記コンテンツサーバ15に対するHTTPリクエストメッセージの送信は、予め設定した時間間隔(例えば、3時間など)にしたがって周期的に行ってもよく、予め設定したスケジュール(例えば、毎日、午前9時と、午後12時と、午後6時に送信するというスケジュールなど)にしたがって行ってもよい。また、その周期やスケジュールは、ユーザU1からの指示に応じて動的に変更できるようにすることも望ましい。
【0055】
前記比較解析部36は、当該定期アクセス部35が送信したHTTPリクエストメッセージに対してコンテンツサーバ15から返送されてきたHTTPレスポンスメッセージの内容などを解析する部分で、解析結果として、更新の有無や日時などを得る。
【0056】
HTTPレスポンスメッセージに含まれる例えば前記更新日を、保管部RC1に保管してあるコンテンツCT11の更新日と比較すれば、保管してあるコンテンツCT11が最新のものであるか否か、すなわち、当該コンテンツCT11の保管後にコンテンツサーバ15側で当該コンテンツCT11の内容の更新が行われたか否かが分かる。
【0057】
このように更新日などの制御情報を取り扱うことは、一般的に、コンテンツの内容そのものを取り扱う場合に比べ、仮想プリントサーバ13の処理能力にかかる負荷がはるかに小さく、短時間で処理を行うことができるので効率的である。
【0058】
ただし更新日などの情報は、コンテンツサーバ15側で適切な管理が行われていなければ、不正確なこともあり、例えば、実際にはコンテンツCT11の内容が更新されているのに、制御情報としての更新日の情報は従前のままである等ということも起こり得る。このような矛盾を検出し正確な対応を行うためには、予め保管してあったものと、今回、HTTPレスポンスメッセージに含まれて届いたものとのあいだで、コンテンツCT11の内容そのものを比較することが必要になる。
【0059】
したがって、当該比較解析部36は、必要に応じて、前記更新日などの制御情報ではなく、コンテンツCT11の内容そのものを比較することで、更新の有無などを検出するようにしてもよい。また、内容そのものを比較することにより、更新の程度(内容が大幅に更新されたか、一部だけ更新されたか等)を検出したり、更新の詳細を検出すること等も可能となる。
【0060】
なお、制御情報として更新日ではなく、有効期限を比較することも有用である。
【0061】
例えば、前回に比べて短い有効期限を設定してきた場合には、コンテンツCT11の更新が近いと予測することもできるからである。このような方法で、更新の予測を行うのが、前記更新予測部37である。
【0062】
更新通知受付部33は、コンテンツサーバ15側が明示的に更新したことを通知してきた場合、その通知情報(明示的更新通知情報)を受け付ける部分である。
【0063】
前記比較解析部56による処理は、コンテンツサーバ15側が特別な処理を行わなくても、通常のHTTPプロトコルによる通信によって得られる情報だけをもとに実行可能であったが、この更新通知受付部33は、コンテンツサーバ15側が明示的更新通知情報を生成し、送信してくることが前提となる。
【0064】
上述したように、仮想プリントサーバ13のコンテンツ提供会員は多数であるので、コンテンツ提供会員によっては、運用するコンテンツサーバ(15に対応)が、明示的更新通知情報を生成し、送信する機能を持たないこともあり、また、そのような機能を持っているコンテンツサーバであっても、コンテンツによっては、明示的更新通知情報の生成を行わない場合などもあり得るので、仮想プリントサーバ13側では、ほぼ同一の目的を達成するために、このように多様な手段を用意しておくことは好ましいといえる。
【0065】
明示的更新通知情報を、コンテンツサーバ15から仮想プリントサーバ13まで届けるための通信手段としては様々なものが利用可能である。例えば、コンテンツサーバ15側の特定のURL(明示的更新通知情報のためのURL)に仮想プリントサーバ13側から短い時間間隔(例えば、600秒間隔程度。この時間間隔が十分に短ければ、実質的にコンテンツサーバ15側からプッシュ型の通信を行うのに等しいといえる)で定期的にHTTPリクエストメッセージを送信し、HTTPレスポンスメッセージの本体として当該明示的更新通知情報を取得すること等も可能であるが、電子メールを利用することも簡便である。ここでは、当該電子メール(この電子メールを、中間通知メールMECとする)を使用するものとする。
【0066】
前記予定通知受付部34は当該更新通知受付部33に対応する構成要素である。受け付ける情報が、更新通知受付部33のように、更新があったことを明示的に通知する明示的更新通知情報ではなく、更新の予定があることを明示的に通知する明示的更新予定通知情報である点が相違するだけである。したがって、当該明示的更新予定通知情報を届けるための通信手段も、前記中間通知メールMECである。
【0067】
なお、この明示的更新予定通知情報の持つ意味は、前記制御情報の1つである有効期限に類似しているといえるが、有効期限を短く設定したからといって必ず更新が近いという保証がないのに対し、明示的更新予定通知情報で通知される更新予定日時は、更新の予定日時を示すものであることが保証されている点が相違する。換言するなら、短い有効期限を設定したからといってコンテンツプロバイダCP1側に近日中に更新を行う責任が発生するわけではないが、明示的更新予定通知情報を通知した場合には、その明示的更新予定通知情報で指定した更新予定日時に更新を行う責任が発生するといえる。
【0068】
通知メール生成部38は、前記ユーザU1に更新があったこと等を伝える所定の通知メールME1を生成する部分である。実際に更新があったこと(前記比較解析部36または更新通知受付部33によって得られる)のほか更新の予測結果、(前記更新予測部37による)や、(前記予定通知受付部34によって得られる)更新の予定日時(明示的更新予定通知情報の内容)などの各種情報が当該通知メールME1に記載される。
【0069】
また、次の更新内容要約部39が機能する場合には、更新内容の要約を示す要約情報(例えば、更新の内容を説明する説明文など)が、当該通知メールME1に含まれることになる。
【0070】
当該更新内容要約部39は、前記要約情報を生成する部分である。当該要約情報は、コンテンツCT11に関して行われた更新がどのようなものであるかを示す情報である。例えば、前記比較解析部36がコンテンツCT11の内容そのものを比較することによって、更新の有無を検出した場合などには、その比較の過程で使用されたコンテンツCT11の内容から、当該要約情報を生成することも可能である。
【0071】
また、コンテンツサーバ15側で当該要約情報を作成し、明示的更新通知情報や明示的更新予定通知情報とともに、前記中間通知メールMECによって、仮想プリントサーバ13側へ届けるようにしてもよい。明示的更新予定通知情報とともに届ける要約情報は、現に実行された更新の要約ではなく、これから実行される更新の要約を示す予告である。ただし現実には、このような要約を生成することは必ずしも容易ではない。
【0072】
そこで、更新の要約の替わりに、更新の概要を、例えば、ファイル名などの形で示すようにすれば簡便である。これは、あるコンテンツCT11の更新前と更新後でそのファイル名が変更された場合には、変更前と変更後のファイル名を表示するものである。ファイル名の付け方に注意すれば、ファイル名によって更新の概要を適切に表現することは可能である。
【0073】
なお、更新の概要とともに、または更新の概要に替えて、当該更新に関連性のある情報や、ユーザU1に伝えたい情報をトピックスとして通知することも望ましい。
【0074】
このトピックスは、コンテンツサーバ15側で生成してもよく、仮想プリントサーバ13側で生成してもよい。
【0075】
更新の概要とトピックスを通知メールME1の本文部分に記載した場合、当該通知メールME1を受信した携帯電話機15の表示部23には、例えば、図10に示す画面が表示されることになる。
【0076】
図10において、「コンテンツN11」はコンテンツCT11の更新前のファイル名であり、「コンテンツM11」は当該コンテンツCT11の更新後のファイル名である。また、図10の例では、トピックスとして、日経平均株価や天気予報に関する情報などが含まれている。
【0077】
前記フィルタリング部40は、更新等が行われたコンテンツの内容に応じて、前記通知メールME1を送信するか否かを決定する部分である。どのような更新が行われた場合(または、これから行われる場合)に通知してほしいかを示すフィルタリング条件を、予めユーザU1が指定しておけば、そのフィルタリング条件に応じて、当該フィルタリング部40が前記通知メールME1を送信するか否かを決定することになる。
【0078】
これにより、ユーザU1は真に必要とする通知メールME1だけを受信し閲覧することができる。同様なフィルタリング条件は、コンテンツサーバ15(コンテンツプロバイダCP1)側からも指定できるようにすることが望ましい。
【0079】
例えば、コンテンツを予め分野(カテゴリ)別に分類しておき、ユーザU1やコンテンツプロバイダCP1にとっての各カテゴリの重要さ(重要度)を指定することをもって、当該フィルタリング条件の設定とすることができる。
【0080】
この場合、ユーザU1およびコンテンツプロバイダCP1のフィルタリング条件をまとめると、例えば、図11に示すフィルタリング表のようになる。図11において、「×」はフィルタリングされて通知(送信)されないことを示し、「○」はフィルタリングされず通知(送信)されることを示す。
【0081】
例えば、コンテンツプロバイダCP1がコンテンツとして各種のニュースを提供しているものとする。この場合、ニュースはいくつかの分野(例えば、「政治情報」分野、「証券情報」分野などの各分野)に分かれ、個々のコンテンツ(個々のニュース)はいずれかの分野に属する。ニュースの分野のうち、コンテンツプロバイダCP1は、「証券情報」分野の重要度を3に、「政治情報」分野の重要度を2に指定したものとし、ユーザU1が、「証券情報」分野の重要度を5に「政治情報」分野の重要度を1に指定したものとすると、「政治情報」分野のニュースは、図11上で位置PX2に相当し、「証券情報」分野のニュースは、位置PX1に相当する。したがって、「証券情報」分野のニュース(コンテンツ)が更新された場合などには、前記通知メールME1を送信してユーザU1に通知することになるが、「政治情報」分野のニュースが更新された場合などには、通知メールME1の送信を行わず、通知しない。
【0082】
このケースで、ユーザU1が例えば「政治情報」分野の重要度を1から4に変更すると、図11上の位置はPX2からPX3に移動するから、「政治情報」分野のニュースが更新された場合などにも、それを伝えるための通知メールME1が送信されることになる。
【0083】
通知条件制御部41は、前記通知メールME1を送信するか否かを決定する点は当該フィルタリング部40と同じであるが、その決定の根拠となる通知条件がコンテンツの内容(コンテンツの属する分野)ではなく、通知の外形的な条件である点が相違する。通知の外形的な条件には様々なものがあり得るが、例えば、通知メールME1を受け取ることのできる時刻、時間帯、1日に受け取ることが許容できる最大の通知メールME1の数などがあてはまる。
【0084】
また、CP1以外に多数のコンテンツプロバイダがコンテンツ提供会員として登録されており、なおかつ、ユーザU1が特にコンテンツプロバイダを指定せずに、コンテンツの種類を指定すること等により、前記通知メールME1の送信を依頼してあるケースなどでは、特定のコンテンツプロバイダを指定して、そのコンテンツプロバイダが提供するコンテンツの更新に関しては、通知メールME1を送信しないでほしいという条件を、当該通知条件として設定することも可能である。
【0085】
さらに、仮想プリントサーバ13側が前記携帯電話事業者から、携帯電話ネットワーク12内で管理している携帯電話機16の現在位置を示す位置情報や、当該位置情報をもとに生成でき、携帯電話機16が(したがってユーザU1が)移動中であるか否かを示す移動情報などを取得できる場合には、当該位置情報などを利用して通知条件を設定することもできる。例えば、当該位置情報を使用し、ある場所にいるときには通知メールME1を送信しないように指示する通知条件を設定したり、移動情報を使用して移動中には通知メールME1を送信しないように指示する通知条件を設定すること等も可能である。
【0086】
このような通知条件は、コンテンツ利用会員(例えば、U1)をグループ分けした上でグループごとに設定したり、全コンテンツ利用会員について包括的に同じ条件を設定したりすることも可能であるが、個々のコンテンツ利用会員からの指示に応じて設定できるようにすれば、コンテンツ利用会員にとって便利である。例えば、ユーザU1は、携帯電話機16などを用いて、自身のための通知条件を設定することができるものであってよい。
【0087】
次に、前記コンテンツサーバ15の内部構成例を図4に示す。
【0088】
(A−1−3)コンテンツサーバの内部構成例
図4において、当該コンテンツサーバ15は、通信部50と、制御部51と、記憶部52と、更新通知生成部53と、更新予定通知生成部54とを備えている。
【0089】
このうち通信部50は、前記通信部30に対応し、制御部51は前記制御部31に対応し、記憶部52は前記記憶部32に対応するので、その詳しい説明は省略する。
【0090】
更新通知生成部53は、上述した明示的更新通知情報を生成して中間通知メールMECを送信する際に機能する部分である。
【0091】
また、更新予定通知生成部54は、上述した明示的更新予定通知情報を生成して中間通知メールMECを送信する際に機能する部分である。
【0092】
以下、上記のような構成を有する本実施形態の動作について、図6〜図9のフローチャートを参照しながら説明する。
【0093】
図5のフローチャートはS10〜S15の各ステップから構成されており、図6のフローチャートはS20〜S25の各ステップから構成されており、図7のフローチャートはS30〜S34の各ステップから構成されており、図8のフローチャートはS40〜S43の各ステップから構成されており、図9のフローチャートはS50〜S54の各ステップから構成されている。
【0094】
(A−2)実施形態の動作
図5において、前記コンテンツサーバ15がユーザU1からの指示に応じてコンテンツ(ここでは、CT11とする)を仮想プリントサーバ13に送信すると、これを受信した仮想プリントサーバ13では、当該コンテンツCT11を前記保管部RC1に保管する(S10、S11)。
【0095】
このあと、仮想プリントサーバ13内の前記定期アクセス部35が例えば一定時間間隔で周期的に、コンテンツサーバ15へHTTPリクエストメッセージを送信し、このHTTPリクエストメッセージに対する応答としてコンテンツサーバ15から届くHTTPレスポンスメッセージを受信して、コンテンツCT11,すなわち、当該コンテンツCT11を格納したファイルの更新の有無を検査する(S12)。
【0096】
検査の結果、更新されていなければそのまま処理を終了し(S13,S15)、更新されていれば、前記通知メールME1を携帯電話機16宛てに送信することで、更新の事実をユーザU1に伝えてから(S14)、処理を終了する(S13,S15)。
【0097】
このように図5のフローチャートでは、仮想プリントサーバ13側から自動的にユーザU1にコンテンツCT11の更新があったことを通知するが、次の図6のフローチャートでは、ユーザU1からの問い合わせに応じて更新の有無を通知する。
【0098】
図6において、携帯電話機16を用いてユーザU1が仮想プリントサーバ13にコンテンツCT11の更新状況を問い合わせると(S20,S21)、仮想プリントサーバ13は前記コンテンツサーバ15にHTTPリクエストメッセージを送信すること等により、当該コンテンツCT11の更新の有無を確認する(S22)。
【0099】
当該ステップS22以降の各ステップは、図5と同様である。すなわち、ステップS23は前記ステップS13に対応し、ステップS24は前記ステップS14に対応し、ステップS25は前記ステップS15に対応する。
【0100】
ただし図6の場合、ユーザU1側から積極的に問い合わせてきたのであるから、更新が行われていないケースでも、更新が行われていない旨を通知するようにすることも望ましい。ここで、更新が行われていない旨を通知するためにも、前記通知メールME1が利用されることは当然である。
【0101】
図5,図6のフローチャートでは、ステップS13,S23でどのようにしてコンテンツの更新の有無を検査するかに関して特段、具体的に示していないため、すでに詳述したあらゆる方法を利用することができる。これに対し、図7のフローチャートは、コンテンツサーバ15側から、前記明示的更新通知情報(中間通知メールMEC)を積極的に送信してくるケースに対応するものである。
【0102】
図7において、ステップS30は前記ステップS10に対応し、ステップS31は前記ステップS11に対応する。
【0103】
ステップS31につづくステップS32では、前記中間通知メールMECにより、明示的更新通知情報が仮想プリントサーバ13に届けられる。これを受信した仮想プリントサーバ13では、更新の事実をユーザU1に伝えるため前記通知メールME1を送信して処理を終える(S33,S34)。
【0104】
次に、図8のフローチャートは、コンテンツサーバ15がコンテンツCT11を仮想プリントサーバ13へ送信する際、必要に応じて、当該コンテンツCT11とともに、前記明示的更新予定通知情報を送信するケースに対応するものである。コンテンツCT11を収容したファイルなどに、当該明示的更新予定通知情報を含めるようにしてもよいが、ファイルに明示的更新予定通知情報を配置するための標準的な規格などは存在しないので、そのような配置を行うには、コンテンツサーバ15と仮想プリントサーバ13のあいだで整合性の取れた固有の通信プロトコルを用いること等が必要になる。
【0105】
そのため、例えば、コンテンツCT11を送信した前後、所定の時間範囲内に前記中間通知電子メールMECを用いて明示的更新予定通知情報を通知すること等をもって、当該コンテンツCT11とともに明示的更新予定通知情報を送信したものとみなすことも簡便である。
【0106】
図8において、コンテンツサーバ15がコンテンツCT11を送信すると(S40)、それを受信した仮想プリントサーバ13では、当該コンテンツCT11とともに、前記明示的更新予定通知情報が含まれているか否かを検査して(S41)、含まれていれば、その明示的更新予定通知情報が示す更新の日時にユーザU1へ前記通知メールME1を送信し(S42)、含まれていなければ、直ちにこの処理を終了する(S43)。
【0107】
なお、明示的更新予定通知情報が示す更新の日時に通知メールME1を送信することに替えて(あるいは、送信することとともに)、「コンテンツN11は、○月×日に更新される予定です。」などと本文部分に記載した通知メールME1を、携帯電話機16に宛てて、更新予定日である○月×日の前に送信することも望ましい。
【0108】
最後に、図9のフローチャートには、上述した通知条件に対応する処理を示す。
【0109】
図9において、携帯電話機16などを用いて、ユーザU1が、仮想プリントサーバ13に自身のための前記通知条件を設定すると(S50,S51)、仮想プリントサーバ13が前記通知メールME1を送信しようとするときには、前記通知条件制御部41が動作して、当該通知条件に適合する送信のみを許可する(S52,S53,S54)。これにより、例えば、電子メールME1を受け取りたくない時間帯などに電子メールME1が着信することがなくなり、ユーザU1の利便性が高まる。
【0110】
(A−3)実施形態の効果
本実施形態によれば、ユーザ(U1)は、コンテンツ(CT11)の更新があった場合や、更新が予定される場合などに、その旨の通知(ME1)を受けることができるため、仮想プリントサービスの信頼性や利便性が向上する。
【0111】
これにより、例えば、すでに更新が行われたにもかかわらず、更新前の古いコンテンツを最新のコンテンツとして利用する等の矛盾が起きることも防止することが可能である。
【0112】
また、このような信頼性や利便性の向上は、コンテンツの最新性を確保してコンテンツの価値を高めることにも寄与するため、コンテンツを利用する側のコンテンツ利用会員(U1)にとって有益であるだけでなく、コンテンツを提供する側のコンテンツ提供会員(CP1)にとっても有益である。
【0113】
なお、本実施形態は、ニュースや天気予報などのように、高頻度で、ほぼ定期的に更新されるコンテンツに対しても有効であるが、いつ更新されるかは不明(予測困難)であるが、その更新に対しユーザ(U1)が重大な関心を持っているコンテンツなどに対して、より有効であるといえる。
【0114】
高頻度で更新されるコンテンツに対しては、頻繁に携帯電話機(16)などからHTTPリクエストメッセージを送信することもそれほど非効率ではないし、ほぼ定期的に更新されるコンテンツであれば、定期的な更新時期に合わせてHTTPリクエストメッセージを送信することも効率的であるが、更新時期が予測困難なコンテンツに対し、携帯電話機などから頻繁にHTTPリクエストメッセージを送信することは著しく非効率であるからである。
【0115】
本実施形態により、ユーザ(U1)は、このように更新時期が予測困難なコンテンツの更新時期を、効率的に知ることが可能となる。これにより、利便性が著しく向上することが期待できる。
【0116】
(B)他の実施形態
上記実施形態において、仮想プリントサーバ14に設けた構成要素33〜41の一部は省略することも可能である。例えば、更新予測部37と予定通知受付部34はいずれかを省略してもよい。また、フィルタリング部40と通知条件制御部41はいずれかを省略してもよい。さらに、更新通知受付部33と予定通知受付部34はいずれかを省略してもよい。さらにまた、更新内容要約部39は省略してもよい。また、更新通知受付部33または予定通知受付部34を設ける場合には、コンテンツサーバ15のほうから積極的に通知してくるのであるから、定期アクセス部35は省略してもよい。
【0117】
なお、上記実施形態において、コンテンツサーバ15に設けた更新通知生成部53、更新予定通知生成部54は、いずれか一方または双方を省略することが可能である。
【0118】
さらに、本発明の構成上、前記MMK端末14は必ずしも必須ではない。
【0119】
なお、前記電子メールME1やMECに含まれる各種の情報(明示的更新通知情報など)は、電子メールの本文部分に記載するのではなく、メールヘッダに専用の拡張フィールドを用意し、その拡張フィールドに記載するようにしてもよい。
【0120】
上記実施形態における携帯電話機は、PHS端末など、その他の移動情報端末に置換可能であることは当然である。
【0121】
また、前記通知メールME1を受け取るための通信端末は、携帯電話機などのように移動性のあるものが望ましいが、例えば、据え置き型のパソコンなどのように移動性のない通信端末であっても、一定の効果は期待できる。
【0122】
さらに、上記実施形態では電子メール(通知メールME1)を用いて通知を行ったが、ユーザU1の通信端末がプッシュ型のクライアントソフトを搭載している場合などには、必ずしも電子メールを用いる必要はない。
【0123】
例えば、当該通信端末のWebブラウザに、十分に短い時間間隔で定期的にHTTPリクエストメッセージを送信し、HTTPレスポンスメッセージの本体として前記通知メールME1と同様な内容を有するファイルを受信できるようにした上、有効なファイルが受信できた場合にのみ画面表示などを実行してユーザU1に伝える機能を搭載することによって、当該電子メール(ME1)に替えることが可能である。
【0124】
なお、前記インターネットは、その他のネットワークに置換可能である。例えば、特定の通信事業者が構築したIPネットワーク、IP−VPN網、広域イーサネット(登録商標)網や、その他のWAN(ワイドエリアネットワーク)などで置換することも可能である。
【0125】
以上の説明では主としてハードウエア的に本発明を実現したが、本発明はソフトウエア的に実現することも可能である。
【0126】
【発明の効果】
以上に説明したように、本発明によれば、信頼性および利便性を高めることができる。
【図面の簡単な説明】
【図1】実施形態に係る仮想プリントシステムの全体構成例を示す概略図である。
【図2】実施形態で使用する携帯電話機の内部構成例を示す概略図である。
【図3】実施形態で使用する仮想プリントサーバの内部構成例を示す概略図である。
【図4】実施形態で使用するコンテンツサーバの内部構成例を示す概略図である。
【図5】実施形態の動作例を示すフローチャートである。
【図6】実施形態の動作例を示すフローチャートである。
【図7】実施形態の動作例を示すフローチャートである。
【図8】実施形態の動作例を示すフローチャートである。
【図9】実施形態の動作例を示すフローチャートである。
【図10】実施形態で使用する携帯電話機の受信画面の一例を示す概略図である。
【図11】実施形態の動作説明図である。
【符号の説明】
10…仮想プリントシステム、11…インターネット、12…携帯電話ネットワーク、13…仮想プリントサーバ、14…MMK端末、15…コンテンツサーバ、16…携帯電話機、20,30,50…通信部、21,31,51…制御部、22…操作部、23…表示部、24,43,52…記憶部、33…更新通知受付部、34…予定通知受付部、35…定期アクセス部、36…比較解析部、37…更新予測部、38…通知メール生成部、39…更新内容要約部、40…フィルタリング部、41…通知条件制御部、53…更新通知生成部、54…更新予定通知生成部、MEC…中間通知メール、ME1…通知メール、CT11…コンテンツ。
Claims (17)
- 所定のコンテンツ提供システムから提供されたコンテンツを所定のコンテンツ保管部に保管しておき、ユーザが通信端末から出力要求を送信してきたときには、前記コンテンツを当該通信端末へ供給する情報保管システムにおいて、
前記コンテンツ提供システムと通信することにより、当該コンテンツ提供システムから提供される前記コンテンツの更新に関連する更新関連情報を検出するコンテンツ更新検出部または、すでに前記コンテンツ保管部に保管されているコンテンツに付随する制御情報を検査することにより、当該コンテンツの更新に関連する更新関連情報を推測するコンテンツ更新推測部のいずれかを備え、
前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果を、前記ユーザに通知する更新情報通知部を有することを特徴とする情報保管システム。 - 請求項1の情報保管システムにおいて、
前記コンテンツ更新検出部は、
所定の時間間隔で前記コンテンツ提供システムと通信し、前記コンテンツそのもの、またはコンテンツに付随する制御情報を取得する定期通信部と、
当該定期通信部が取得したコンテンツまたは制御情報を解析することによって、コンテンツの更新が行われたことを検出する更新解析部とを備えることを特徴とする情報保管システム。 - 請求項1の情報保管システムにおいて、
前記コンテンツの更新を行ったとき、そのコンテンツの提供元である前記コンテンツ提供システムがその旨を通知し、前記コンテンツ更新検出部が当該通知を受け取ることを特徴とする情報保管システム。 - 請求項1の情報保管システムにおいて、
前記コンテンツの更新に関する予定を明示する予定情報を、そのコンテンツの提供元である前記コンテンツ提供システムが送信してくると、当該予定情報を受け取る予定情報取得部を備えたことを特徴とする情報保管システム。 - 請求項1の情報保管システムにおいて、
前記更新情報通知部は、
前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果とともに、または、前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果に替えて、すでに実行された、または予想されるコンテンツの更新の概要を示す更新概要情報を生成する概要情報生成部を備え、
前記ユーザに当該更新概要情報を伝えることを特徴とする情報保管システム。 - 請求項1の情報保管システムにおいて、
予め設定された選択条件に基づいて、前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果それぞれに関して、内容に応じた選択を行う選択実行部を備え、
当該選択実行部が、前記検出結果または推測結果を選択した場合、前記更新情報通知部は、選択された検出結果または推測結果を、前記ユーザに伝えることを特徴とする情報保管システム。 - 請求項6の情報保管システムにおいて、
前記選択条件は、前記コンテンツ提供システム側またはユーザ側からの指定に応じて決定することを特徴とする情報保管システム。 - 請求項1の情報保管システムにおいて、
前記更新情報通知部が通知を行う場合の条件である通知条件を、前記ユーザからの指定に応じて決定する通知条件決定部を備え、
当該通知条件決定部が、当該通知条件に基づいて、前記更新情報通知部による通知を制御することを特徴とする情報保管システム。 - 所定のコンテンツ提供システムから提供されたコンテンツを所定のコンテンツ保管部に保管しておき、ユーザが通信端末から出力要求を送信してきたときには、前記コンテンツを当該通信端末へ供給する情報保管方法において、
コンテンツ更新検出部が、前記コンテンツ提供システムと通信することにより、当該コンテンツ提供システムから提供される前記コンテンツの更新に関連する更新関連情報を検出するか、または、コンテンツ更新推測部が、すでに前記コンテンツ保管部に保管されているコンテンツに付随する制御情報を検査することにより、当該コンテンツの更新に関連する更新関連情報を推測し、
前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果を、更新通知部が、前記ユーザに通知することを特徴とする情報保管方法。 - 請求項9の情報保管方法において、
前記コンテンツ更新検出部では、
定期通信部が、所定の時間間隔で前記コンテンツ提供システムと通信することにより、前記コンテンツそのもの、またはコンテンツに付随する制御情報を取得し、
更新解析部が、当該定期通信部が取得したコンテンツまたは制御情報を解析することによって、コンテンツの更新が行われたことを検出することを特徴とする情報保管方法。 - 請求項9の情報保管方法において、
前記コンテンツの更新を行ったとき、そのコンテンツの提供元である前記コンテンツ提供システムがその旨を通知し、前記コンテンツ更新検出部が当該通知を受け取ることを特徴とする情報保管方法。 - 請求項9の情報保管方法において、
前記コンテンツの更新に関する予定を明示する予定情報を、そのコンテンツの提供元である前記コンテンツ提供システムが送信してくると、予定情報取得部が、当該予定情報を受け取ることを特徴とする情報保管方法。 - 請求項9の情報保管方法において、
前記更新情報通知部では、
概要情報生成部が、前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果とともに、または、前記コンテンツ更新検出部による検出結果またはコンテンツ更新推測部による推測結果に替えて、すでに実行された、または予想されるコンテンツの更新の概要を示す更新概要情報を生成し、
前記ユーザに当該更新概要情報を伝えることを特徴とする情報保管方法。 - 請求項9の情報保管方法において、
選択実行部が、予め設定された選択条件に基づいて、前記コンテンツ更新検出部またはコンテンツ更新推測部による検出結果それぞれに関して、内容に応じた選択を行い、
当該選択実行部が、前記検出結果または推測結果を選択した場合、前記更新情報通知部は、選択された検出結果または推測結果を、前記ユーザに伝えることを特徴とする情報保管方法。 - 請求項14の情報保管方法において、
前記選択条件は、前記コンテンツ提供システム側またはユーザ側からの指定に応じて決定することを特徴とする情報保管方法。 - 請求項9の情報保管方法において、
通知条件決定部が、前記更新情報通知部が通知を行う場合の条件である通知条件を、前記ユーザからの指定に応じて決定し、
当該通知条件決定部が、当該通知条件に基づいて、前記更新情報通知部による通知を制御することを特徴とする情報保管方法。 - 所定のコンテンツ提供システムから提供されたコンテンツを所定のコンテンツ保管機能に保管しておき、ユーザが通信端末から出力要求を送信してきたときには、前記コンテンツを当該通信端末へ供給する情報保管プログラムにおいて、コンピュータに、
前記コンテンツ提供システムと通信することにより、当該コンテンツ提供システムから提供される前記コンテンツの更新に関連する更新関連情報を検出するコンテンツ更新検出機能または、すでに前記コンテンツ保管部に保管されているコンテンツに付随する制御情報を検査することにより、当該コンテンツの更新に関連する更新関連情報を推測するコンテンツ更新推測機能のいずれかを実現させ、
前記コンテンツ更新検出機能による検出結果またはコンテンツ更新推測機能による推測結果を、前記ユーザに通知する更新情報通知機能を実現することを特徴とする情報保管プログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003189310A JP2005025431A (ja) | 2003-07-01 | 2003-07-01 | 情報保管システム、情報保管方法、および情報保管プログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003189310A JP2005025431A (ja) | 2003-07-01 | 2003-07-01 | 情報保管システム、情報保管方法、および情報保管プログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2005025431A true JP2005025431A (ja) | 2005-01-27 |
Family
ID=34187561
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003189310A Abandoned JP2005025431A (ja) | 2003-07-01 | 2003-07-01 | 情報保管システム、情報保管方法、および情報保管プログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2005025431A (ja) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007065819A (ja) * | 2005-08-30 | 2007-03-15 | Seiko Epson Corp | POS端末装置及びWebページの表示方法 |
JP2009025887A (ja) * | 2007-07-17 | 2009-02-05 | Nippon Digital Kenkyusho:Kk | 情報通知方法、ファイアウォール装置、情報通知システムおよび情報通知プログラム |
JP2009070355A (ja) * | 2007-09-14 | 2009-04-02 | Koichi Suzuki | インターネットの更新情報をrssに頼らないでサイトの更新情報を取得するシステム |
JP2010027061A (ja) * | 2008-07-16 | 2010-02-04 | Sony Corp | 遠隔にあるコンピュータ装置からのメディアを出力するために仲介装置を用いたオンデマンドメディア |
JP2010128662A (ja) * | 2008-11-26 | 2010-06-10 | Fujitsu Ltd | 中継サーバ、モバイル端末、情報閲覧システム及びプログラム |
JP2010205237A (ja) * | 2009-02-27 | 2010-09-16 | Yahoo Japan Corp | キャッシュ保持期間よりもブラウザ保持期間を長く設定するデータ配信装置及びキャッシュサーバ及び方法 |
JP2012043398A (ja) * | 2010-07-21 | 2012-03-01 | Canon Inc | コンテンツ印刷システム、および印刷中継システム、および制御方法、およびプログラム |
JP2012178031A (ja) * | 2011-02-25 | 2012-09-13 | Canon Inc | 印刷中継サーバ、印刷中継サーバを制御する制御方法、その制御方法のプログラム、および印刷処理方法 |
-
2003
- 2003-07-01 JP JP2003189310A patent/JP2005025431A/ja not_active Abandoned
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007065819A (ja) * | 2005-08-30 | 2007-03-15 | Seiko Epson Corp | POS端末装置及びWebページの表示方法 |
JP2009025887A (ja) * | 2007-07-17 | 2009-02-05 | Nippon Digital Kenkyusho:Kk | 情報通知方法、ファイアウォール装置、情報通知システムおよび情報通知プログラム |
JP2009070355A (ja) * | 2007-09-14 | 2009-04-02 | Koichi Suzuki | インターネットの更新情報をrssに頼らないでサイトの更新情報を取得するシステム |
JP2010027061A (ja) * | 2008-07-16 | 2010-02-04 | Sony Corp | 遠隔にあるコンピュータ装置からのメディアを出力するために仲介装置を用いたオンデマンドメディア |
JP2010128662A (ja) * | 2008-11-26 | 2010-06-10 | Fujitsu Ltd | 中継サーバ、モバイル端末、情報閲覧システム及びプログラム |
JP2010205237A (ja) * | 2009-02-27 | 2010-09-16 | Yahoo Japan Corp | キャッシュ保持期間よりもブラウザ保持期間を長く設定するデータ配信装置及びキャッシュサーバ及び方法 |
JP2012043398A (ja) * | 2010-07-21 | 2012-03-01 | Canon Inc | コンテンツ印刷システム、および印刷中継システム、および制御方法、およびプログラム |
JP2012178031A (ja) * | 2011-02-25 | 2012-09-13 | Canon Inc | 印刷中継サーバ、印刷中継サーバを制御する制御方法、その制御方法のプログラム、および印刷処理方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9900398B2 (en) | Apparatus and method for context-aware mobile data management | |
US6889264B2 (en) | Imposing a delay for indication of a status board to provide a time for self-rectification of a service event detected from peripheral status information | |
US6920488B1 (en) | Server assisted system for accessing web pages from a personal data assistant | |
JP3693938B2 (ja) | 情報配信システム、広告配信システム、情報配信プログラム、サーバ、情報配信サーバ、広告情報配信方法、およびセーバページ表示方法 | |
US20030033283A1 (en) | Data access | |
EP1844591B1 (en) | System architecture and method for scheduled downloading services | |
JP2002055870A (ja) | データ提供装置、データ取得装置及びデータ処理システム | |
JP2008546115A (ja) | 警告インタフェースにおける広告 | |
JP5013789B2 (ja) | ウェブページ生成システム、ウェブページ生成装置、およびウェブページ生成方法 | |
JP2002334033A (ja) | 情報配信方法、システム、装置、及びプログラム、並びに記録媒体 | |
JP2005025431A (ja) | 情報保管システム、情報保管方法、および情報保管プログラム | |
JP4825533B2 (ja) | 携帯端末装置、コンテンツ管理システム、データキャッシュ方法 | |
KR100729687B1 (ko) | 정보 배신 시스템 및 정보 배신 방법 | |
US20060031414A1 (en) | Method and apparatus for web service communication | |
JP2010129013A (ja) | 広告配信のためのシステム、方法、装置およびプログラム | |
US7581227B1 (en) | Systems and methods of synchronizing indexes | |
WO2010135816A1 (en) | System and method for reporting advertising metric data | |
JP2002328874A (ja) | 電子メールの管理方法と管理装置 | |
KR101076713B1 (ko) | 브라우저를 탑재한 단말기 및 그 인터넷 접속 방법, 및 브라우저를 탑재한 단말기용 무선 인터넷 지원 시스템 및 그 지원 방법 | |
JP4467385B2 (ja) | 情報処理システム、情報処理方法、および情報処理プログラム | |
JP2008033628A (ja) | 広告システム、端末装置、サーバ、広告情報処理方法 | |
JP2005293491A (ja) | サーバシステム | |
JP2002132657A (ja) | 情報配信システム | |
JP2003044390A (ja) | コンテンツ共有方法、コンテンツ共有管理装置、コンピュータプログラム及び端末装置 | |
JP2001312654A (ja) | インターネット上の広告・情報提供システム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060606 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20081201 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081216 |
|
A762 | Written abandonment of application |
Free format text: JAPANESE INTERMEDIATE CODE: A762 Effective date: 20090107 |