JP2004310464A - 共有コンテンツファイルの更新管理方法 - Google Patents

Abstract

【課題】サーバに登録された各ユーザ端末の共有コンテンツファイルの更新管理方法において、各ユーザ端末から能動的に更新を監視して更新情報が得られるようにする。
【解決手段】ユーザ端末３，４…から共有コンテンツファイルの更新要求があると、サーバ２側では、そのファイルは加工せず、個々の加工処理方法とその所要パラメータとからなるエフェクトオブジェクト及び加工順序を記述したエフェクトファイルと日時情報とを作成してＨＤＤ２５に登録する。ユーザ端末３の監視アプレット３６はサーバ２側の更新状態を監視し、更新検知によりサーバ２へ更新情報の要求を行い、サーバ２は前記日時情報と加工情報からなる更新情報をユーザ端末３へ送信する。また、各ユーザ端末３，４…からのファイル閲覧要求に対しては、エフェクトファイルを用いて共有コンテンツファイルを加工・再生して送信する。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明はネットワーク上の共有ファイル更新管理方法に係り、サーバ上に設けた共有コンテンツファイルを各ユーザ端末側から加工処理できるようにしてコミュニケーションの場を提供する場合に、共有コンテンツファイルの更新情報を各ユーザ端末側から確認でき、またサーバ側においても更新される共有コンテンツファイルを少ないデータ量で保存できる方法に関する。
【０００２】
【従来の技術】
近年、パーソナルコンピュータに加えて電子メール・ブラウザ機能を備えた携帯電話等の各種端末の広範な普及により、電子メールの送受信、Ｗｅｂページの作成・閲覧、データのアップ・ダウンロード等のインターネットを介したコミュニケーションが多種多様な方式で行われるようになっている。
【０００３】
電子メールによる通信では、電話通信のようにリアルタイムな相手の都合や時間を気遣うことなく送信先へ文字データを送信し、ネットワーク上のトラフィック等に問題がない限り、直ちに送信先の端末又はＩＳＰ（Ｉｎｔｅｒｎｅｔ ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）のネットワークストレージに電子メールを届けることができる。
一方、送信先では任意の時間に電子メールを読めるため、送信元と送信先の双方が時間を問わずに文字データによるコミュニケーションが行える。
そして、多くの電子メールツールは添付ファイル機能も備えており、画像等のコンテンツファイルを添付して送信できることから、文字データだけでなく各種コンテンツによるコミュニケーションも可能であり、そのための支援システムについては下記の特許文献１〜３等のように各種の提案がなされている。
また、前記電子メール以外のインターネットを介したコミュニケーション方式としてチャットがある。
この方式は、インターネット上に設けた文字記入画面に対して複数の端末から文字が書き込まれて時系列的に追記更新されるものであり、これも文字によるリアルタイムなコミュニケーションの場を提供するものである。
【０００４】
しかし、前記の電子メールによる通信は、基本的にはＰｅｅｒ−ｔｏ−Ｐｅｅｒの一方的な連絡手段であると共に、電子メールにファイルを添付して送信すると送信先にはそのファイルがコピーされ、特に、添付ファイルが画像データであるような場合には、送信先の端末のメモリスペースを圧迫してリソースの無駄遣いになることが少なくない。
また、前記のチャットは文字に限定されたコミュニケーションだけであり、リアルタイムにやり取りを行いたい場合には、各端末側でそのためのアプリケーションを立ち上げてログオンした後、チャットウィンドウを継続的に開いておかねばならない。
即ち、電子メールやチャットはインターネット上の最も一般的なコミュニケーションの方式であるが、前記のような問題点を含んでいる。
【０００５】
一方、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）では、Ｗｅｂサーバ上のＷｅｂページや画像・音声等のコンテンツファイルに複数の端末からアクセスでき、それらコンテンツの内容を見聞きすることができる。
また、Ｗｅｂページの中には、コンテンツファイルの提示だけでなく、任意の又は特定のユーザ端末から書き込みが行える“電子掲示板”を設けておき、文字による相互コミュニケーションの場を提供しているようなＷｅｂサイトもある。
そして、そのようなＷｅｂサイトを監視するユーザ端末側のアプリケーションソフトとしてＷＷＷＣ（Ｗｅｂページの更新チェッカ）がある。
このＷＷＷＣは、予めユーザによって監視対象とするＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）をユーザ端末に登録させておき、指示を与えることにより、又は指定した時刻や定期的な間隔で前記ＵＲＬに接続してＷｅｂページを確認できるようにしたものである。
従って、ＷＷＷＣを用いると、コンテンツファイルに記述された特定のメタデータやファイルサイズや更新時刻からコンテンツファイルの更新の有無を判断することが可能である。
尚、このようなシステムに関連したものとして、例えば、下記の特許文献４，５等のように各種の提案がなされている。
【０００６】
【特許文献１】
特開２００１−３４５４７号公報
【特許文献２】
特開２００１−２１１４３８号公報
【特許文献３】
特開２００２−１９０８３３号公報
【特許文献４】
特開２００２−１４０３２３号公報
【特許文献５】
特表２００２−５２３８４２号公報
【０００７】
【発明が解決しようとする課題】
【０００８】
ところで、前記のＷｅｂサーバ上のＷｅｂページも、基本的にはコンテンツの作成者がその内容を多くのユーザに対して一方的に見聞きさせるものであって、そのコンテンツファイルの管理者以外の者にコンテンツファイル自体の変更を認めるものではない。
そして、ＷＷＷＣのようにＷｅｂサーバ上のコンテンツファイルに関する更新チェッカは存在するが、通常はコンテンツファイルの変化を目視的に観察して更新の有無を確認できるに過ぎない。
即ち、コンテンツファイル内に前記の更新通知システムが解読可能なメタデータが記述されているような場合には、それから何等かの更新情報が得られることもあるが、メタデータはコンテンツファイルの作成者が自由に記述する任意情報であって、それを記述していないものも多数ある。
【０００９】
一方、Ｗｅｂサーバ上に共有データファイルを置いて各ユーザ端末からそのファイルの閲覧及び変更を行えるようにした場合、ファイルのバージョン管理システム（例えば、ＣＶＳやＲＣＳ等）を利用すれば、ファイルの閲覧・変更に係る詳細な情報を通知することができる。
具体的には、前記のバージョン管理システムによれば、データファイル内に訂正・修正情報等を記述でき、指定したデータファイルの更新時にその更新通知を電子メールで指定した宛先に通知することが可能であると共に、データファイルの差分を別ファイルに保存しておいて後から各バージョンのデータファイルの差分を比較したり、個々のユーザが変更したデータファイルをマージすることも可能になる。
【００１０】
しかし、共有データファイルの更新情報に関しては、前記のバージョン管理システムも電子メールで更新通知をユーザ端末へ送信するだけである。
そして、共有データファイルの更新がなされる度に一方的に送られてくる更新通知に対して、ユーザ端末側は自らが管理できない立場にあり、頻繁に更新がなされるデータファイルのような場合には電子メールの整理等が煩わしくなる。
また、データファイルの差分をとって管理できることは、プログラム言語や文書等のテキストで記述されたファイルについては有効であるが、画像ファイル等のバイナリデータの場合には、更新された変更部分のみを差分として保存できないことが多い。
即ち、画像ファイルの変更は全体に効果をかけたり色を変更したりして加工することが多いため、変更部分のみを差分として保存する方法は馴染まず、また、ＪＰＥＧ等の圧縮フォーマットの画像データは見た目上は画像の一部分に加工を施していてもデータ全体が変更されてしまうことも考えられるために変更のマージが極めて困難である。
更に、画像ファイル自体はフォーマットが決まっているため、ファイル中にメタデータを記述できるフォーマットの画像を用いるか、又は画像データ中にメタ情報を埋め込むための特殊なアプリケーションを利用しない限り、版の相違を画像ファイル内に記述することは難しい。
従って、データファイルが画像ファイル等のバイナリデータの場合には、結局、更新される度にそれ以前のデータと共に更新データを一括して新たに保存することになる。
その場合、例えば、最近のディジタルカメラ等で撮った画像等は一般に数百ＫＢ〜数ＭＢのデータ量になり、更新の度に大きなデータ量のファイルができることになるため、サーバ上のメモリスペースを圧迫してゆくことになる。
【００１１】
要約すると、Ｗｅｂサーバ上のコンテンツファイルや共有データファイルについて変更がなされた場合に、ユーザ端末側ではサーバ側の更新通知システムやバージョン管理システムによって更新の事実を確認できることになるが、それ以上の情報は得られず、また、画像ファイル等のバイナリデータについては、更新の度にサーバのメモリスペースが圧迫されるために、大容量の記憶装置を設けておかなければならないという問題がある。
【００１２】
そこで、本発明は、サーバ上の共有コンテンツファイルを各ユーザ端末側から加工でき、サーバ側では加工後の共有コンテンツファイルを少ないデータ量で保存できると共に、各ユーザ端末側から更新情報を監視して更新後の加工情報や共有コンテンツファイル自体を所望のタイミングで閲覧できる共有コンテンツファイル更新管理方法を提供し、もって、ユーザ端末同士で共有コンテンツファイルを介したよりリアルタイムでフレキシブルなコミュニケーションを可能にすることを目的として創作された。
【００１３】
【課題を解決するための手段】
本発明は、ネットワークを介してサーバと複数のユーザ端末とが配置され、前記サーバに対して前記ユーザ端末からアップロードされた共有コンテンツファイル又は前記サーバ側で作成した共有コンテンツファイルを前記サーバに登録せしめ、前記ユーザ端末から前記共有コンテンツファイルを閲覧・加工することが可能なネットワークシステムにおける共有コンテンツファイルの更新管理方法であって、前記サーバに登録されている前記共有コンテンツファイルに対して前記ユーザ端末側から加工要求がなされた場合に、前記サーバは、前記共有コンテンツファイルを加工することなく、前記ユーザ端末による個々の加工処理方法とその加工に必要なパラメータとからなるエフェクトオブジェクト及び前記加工処理の順序情報を記述したエフェクトファイルを作成する手順と、そのエフェクトファイルを少なくとも日時情報とそのエフェクトファイルから得られる加工情報とを含む更新情報と共に登録（但し、先の加工要求に係るエフェクトファイルと更新情報がある場合にはそれらを書き換えて登録）する手順とを実行し、一方、前記ユーザ端末は常時又は予め設定した時刻に前記サーバ側の共有コンテンツファイルの前記更新情報を監視する監視アプレットを備えており、前記ユーザ端末による前記サーバに登録されている前記共有コンテンツファイルの更新情報の確認に際しては、前記監視アプレットによる新規な更新の検知に基づいて、前記ユーザ端末が前記サーバに対して前記更新情報の閲覧要求を送信する手順と、前記サーバが前記閲覧要求に基づいて前記更新情報を前記ユーザ端末へ送信する手順と、
前記ユーザ端末側が前記サーバから受信した前記更新情報を表示手段で表示させる手順とによって行われることを特徴とする共有コンテンツファイルの更新管理方法に係る。
【００１４】
本発明によれば、ユーザ端末から共有コンテンツファイルの加工要求があった場合に、サーバは共有コンテンツファイル自体には加工を施さずに、エフェクトファイルと更新情報だけを書き換えながら登録する。
従って、加工がなされる度にその共有コンテンツファイルを保存してゆく場合と比較して、保存データ量は遥かに少なくなり、サーバ側のメモリスペースが圧迫されることはない。
そして、この発明ではユーザ端末の監視アプレットが共有コンテンツファイルの更新情報を監視して更新の事実を検知するようになっており、従来のようにサーバ側から通知を受けるような受身の立場ではなく所望の時点でユーザ端末側から能動的に更新の有無を監視でき、更にその時点での更新情報を自動的に受信できる。
特に、更新情報には日時情報に加えてエフェクトファイルから得られた加工情報が含まれるため、共有コンテンツファイルにどのような加工が施されたかも確認できるという利点がある。
【００１５】
また、本発明によれば、前記ユーザ端末による前記サーバに登録されている前記共有コンテンツファイルの閲覧については、前記ユーザ端末が前記サーバに対して前記共有コンテンツファイルの閲覧要求を送信する手順と、前記閲覧要求に基づいて、前記サーバが、前記エフェクトファイルを用いて前記共有コンテンツファイルを加工処理し、その加工処理後の共有コンテンツファイルを前記ユーザ端末側へ送信する手順とを実行させることによって行える。
即ち、少ないデータ量で共有コンテンツファイルの更新を管理しながら、閲覧要求に対しては加工後の共有コンテンツファイルを再生して提供できる。
【００１６】
また、前記ユーザ端末が前記サーバに対して共有コンテンツファイルの閲覧要求又はエフェクトファイルのみの閲覧要求を選択的に行えるようにしておき、エフェクトファイルのみの閲覧要求がなされた場合に、前記サーバが前記エフェクトファイルだけを読み出して前記ユーザ端末へ送信するようにすれば、前記ユーザ端末は前記エフェクトファイルのみを得ることができる。
その場合、前記エフェクトファイルは共有コンテンツファイルに対する加工処理の内容を記述したものであるが、前記ユーザ端末側において他のコンテンツファイルに前記エフェクトファイルを作用させることでその加工処理の面白さを体験することができ、単に共有ファイルを介したコミュニケーションだけでなく、エフェクトファイルを用いたコミュニケーションも可能になる。
【００１７】
また、前記サーバにおいて、前記共有コンテンツファイルをバックアップ用記憶手段に格納させておき、先の加工要求に係るエフェクトファイルと更新情報を今回の加工要求に係るエフェクトファイルと更新情報に書き換えて登録する場合に、先の加工要求に係るエフェクトファイルと更新情報を前記バックアップ用記憶手段に格納するようにしてもよい。
このバックアップによって、修復不能な加工処理や特殊なプログラムによる共通コンテンツファイルの消去等の予期しない操作が行われた場合にも直前の状態へ戻すことができる。
その場合、バックアップ用記憶手段に格納されるデータは、元の共有コンテンツファイルと直前の加工処理に係るエフェクトファイルと更新情報だけであり、通常の保存・登録用の記憶手段と同様に、バックアップ用記憶手段のメモリスペースが圧迫されることはない。
【００１８】
また、前記ユーザ端末が閲覧要求に係る共有コンテンツファイルを受信した際に、前記ユーザ端末がその共有コンテンツファイルを再生するための十分な機能を備えていない場合には、前記ユーザ端末が前記サーバに対して再生可能な条件を通知し、前記サーバが前記加工処理後の共有コンテンツファイルを前記条件に対応させるように更に加工処理を施して前記ユーザ端末へ送信するようにすれば、共有コンテンツファイルの属性等によってそのままでは前記ユーザ端末で再生できないような場合にも、前記サーバ側が適応的に加工処理を行うことでその不都合を解消できる。
【００１９】
【発明の実施の形態】
以下、本発明の「共有コンテンツファイルの更新管理方法」の実施形態を、図面を用いて詳細に説明する。
先ず、図１は、インターネット１を介してサーバ２とユーザ端末３，４が配置されており、サーバ２とユーザ端末３，４をブロック構成図として示した概略図である。但し、実際には多数のユーザ端末が接続されることになるが、図１では２つのユーザ端末３，４だけが接続されているネットワーク構成になっている。
この実施形態では、サーバ２側で作成した画像コンテンツファイル又は各ユーザ端末３，４，…で作成されてインターネット１を介してサーバ２側へアップロードされた画像コンテンツファイルを各ユーザ端末３，４，…の共有コンテンツファイルとし、サーバ２側がその共有コンテンツファイルを管理しながら、各ユーザ端末３，４，…に対して前記共有コンテンツファイルの加工・閲覧等を認めるネットワークシステムを例にとって説明する。
【００２０】
ここで、サーバ２は、インターネット１との間で通信制御を実行する通信制御部２１と、データの入出力やアクセス権等の管理を行うデータ管理部２２と、共有コンテンツファイルに対して加工がなされた場合にはその加工に係るエフェクトファイルを作成し、共有コンテンツファイルの閲覧要求があった場合に前記エフェクトファイルを用いて加工後のコンテンツファイルを生成させるデータ処理部２３と、アクセス権等に係るユーザ管理情報を格納したハードディスク装置（ＨＤＤ）２４と、共有コンテンツファイルやエフェクトファイル等を格納するＨＤＤ２５とからなる。
一方、各ユーザ端末３，４は、それぞれ、インターネット１との間で通信制御を実行する通信制御部３１，４１と、データの処理や入出力等を制御するデータ処理部３２，４２と、キーボード等からなる操作入力部３３，４３と、表示部３４，４４と、ＨＤＤ３５，４５を備えており、ユーザ端末３に関しては、更にインターネット１を介して常時又は定期的にサーバ２側の共有コンテンツファイルの更新状態を監視するための監視アプレット３６を備えている。
尚、この実施形態ではユーザ端末３だけが監視アプレット３６を有しているが、ユーザ端末４や他のユーザ端末が同様の監視アプレット３６を備えていてもよい。
【００２１】
［実施形態１］
この実施形態では、各ユーザ端末３，４，…からインターネット１を介してサーバ２が格納している共有コンテンツファイルを加工する場合の手順を、図２の通信シーケンスフローチャートを参照しながら説明する。
但し、ここではユーザ端末４から加工がなされる場合を例にとる。
先ず、前記のように、サーバ２のＨＤＤ２５には各ユーザ端末３，４，…が共有する画像コンテンツファイルが格納されており、サーバ２の通信制御部２１は各ユーザ端末３，４，…との通信の待ち受け状態にあり（Ｓ１）、ユーザ端末４の通信制御部４１も通信可能状態にある。
【００２２】
ここで、ユーザ端末４において、入力操作部４３でサーバ２に対する認証要求のための操作を行うと、データ処理部４２が通信制御部４１を制御して認証要求信号をサーバ２側へ送信する（Ｔ１）。
サーバ２は、インターネット１を介して通信制御部２１で認証要求信号を受信すると、データ管理部２２が受信した認証要求信号のユーザ情報とＨＤＤ２４のユーザ管理情報とを照合し、ユーザ端末４に対してその照合結果に基づいた認証応答を返送する（Ｓ２）。
そして、ユーザ端末４では、認証応答が許可応答であればリンクが確立して次の手順として共有コンテンツファイルの指定を行う操作へ移行するが（Ｔ２，Ｔ４）、認証応答が不許可応答である場合には再び認証要求操作を行って前記の手順を繰り返すことになる（Ｔ２，Ｔ３）。尚、再認証手順でもサーバ２側から許可応答が得られない場合には、サーバ２とのリンクが不能であり操作が終了する。
【００２３】
許可応答を受信したユーザ端末４では、操作入力部４３からサーバ２側の共有コンテンツファイルのファイル指定を行い、その指定情報をサーバ２側へ送信する（Ｔ４）。
一方、ファイル指定情報を受信したサーバ２は、データ管理部２２がＨＤＤ２５を検索し、指定された共有コンテンツファイルを開いてユーザ端末４側へ送信する（Ｓ３）。
尚、ここでは、共有コンテンツファイルが初めて加工される場合を例にとるが、既に各ユーザ端末３，４，…によってその共有コンテンツファイルに加工がなされている場合には、後述のエフェクトファイルを用いて共有コンテンツファイルを加工処理してユーザ端末４側へ送信することになる。
【００２４】
ファイル指定に係る共有コンテンツファイルを受信したユーザ端末４では、データ処理部４２がそのファイルをＨＤＤ４５へセーブさせた後、そのコンテンツ画像を表示部４４に表示させ、ユーザは共有コンテンツファイルの内容を確認する（Ｔ５）。
そして、表示画像を見ながら入力操作部４３によってその画像の加工処理を施すと、データ処理部４２がその加工に係る処理情報をサーバ２側へ送信させる（Ｔ６）。
【００２５】
一方、加工処理情報を受信したサーバ２では、データ管理部２２がデータ処理部２３を起動させ、ＨＤＤ２５の前記指定に係る共有コンテンツファイルをデータ処理部２３へ読み出し、データ処理部２３によって加工処理情報を用いた共有コンテンツファイルの加工処理を実行させる（Ｓ４）。
その場合、データ処理部２３では、受信した加工処理情報に基づいて読み出された共有コンテンツファイルを加工すると共に、その加工処理毎のエフェクトファイルを作成する（Ｓ４，Ｓ５）。
【００２６】
このエフェクトファイルは加工処理内容を記述したファイルであるが、画像の鮮鋭化、ぼかし、増色／減色、エンボス加工、拡大／縮小等の個々の処理とその処理に関するパラメータを１つのエフェクトオブジェクトとして扱い、複数の処理が行われた場合にはその処理数分のエフェクトオブジェクトとその処理順序を記述したものである。
例えば、特許第２９６５１１９号公報では「画像処理を個別のオブジェクト（原画像の一部を変更して変更画像を作り出す仮想レンズオブジェクト）としてまとめ、それらの追加，削除，修正を行えるようにして画像処理のフレキシビリティを向上させた画像処理システム」の提案がなされているが、エフェクトオブジェクトとしては前記提案の仮想レンズオブジェクトも適用できる。
従って、エフェクトファイルはユーザ端末４から要求された加工処理プログラムモジュールとしての性質を有し、逆に、共有コンテンツファイルに対してエフェクトファイルを適用することにより加工後の変更された画像ファイルを再生することが可能である。
【００２７】
また、データ処理部２３は共有コンテンツファイルを加工した後の画像データに係るプレビューを作成し、データ管理部２２がそのプレビューデータをユーザ端末４側へ送信させる（Ｓ６）。
一方、プレビューデータを受信したユーザ端末４では、それを表示部４４に表示させてユーザがその加工後の画像でよいかどうかを確認する（Ｔ７）。
そして、ユーザはその加工画像の内容でよければ入力操作部４５から保存要求を行うが（Ｔ７，Ｔ８）、その画像に納得できずに更に加工処理を行う必要があれば入力操作部４５から追加の加工処理を行い、所望の加工画像が得られるまでステップＴ６からステップＳ６の手順を繰り返して実行する（Ｔ７→Ｔ６，Ｓ４〜Ｓ６→Ｔ７）。
【００２８】
その場合、前記のようにデータ処理部２３では加工処理毎のエフェクトファイルを作成しているため、複数の加工処理を施したときにも、そのファイル内のエフェクトオブジェクトの時系列を逆に辿ることによって任意の段階まで戻ることができ、また不要であると思われる個別のエフェクトオブジェクトを選択的に削除することもできる。
また、それらのエフェクトオブジェクトに対する操作過程は前記の繰り返し手順においてプレビューに反映され、ユーザ端末４のユーザはプレビューを見ながら効率良く加工処理を行ってゆくことができる。
【００２９】
前記の加工処理において所望の加工画像のプレビューが得られると、ユーザは入力操作部４３から保存要求を行い、ユーザ端末４からサーバ２へ保存要求信号が送信される（Ｔ８）。
そして、その信号を受信したサーバ２では、データ管理部２２によって、データ処理部２３が作成した前記エフェクトファイルとその作成に係る日時情報と前記エフェクトファイルから得られる加工情報をＨＤＤ２５の前記共有コンテンツファイルに対応するアドレス領域に保存・登録させる（Ｓ７）。
但し、ここでの「加工情報」とは加工内容を示す要目（例えば、鮮鋭化、ぼかし、増色／減色、サイズ変更等）だけであり、その処理の詳細はエフェクトファイルに記述されている。
また、以下、前記の加工情報と日時情報とを「更新情報」と言うこととする。
尚、この場合は、共有コンテンツファイルに対するユーザ端末４からの加工処理要求が最初の処理であるために、エフェクトファイルと更新情報をそのまま保存・登録させるようにしているが、既に各ユーザ端末３，４，…から共有コンテンツファイルに対する加工処理がなされており、ＨＤＤ２５にエフェクトファイルと更新情報が存在している場合には、それらのファイルを更新する態様で保存・登録がなされる。
【００３０】
ところで、サーバ２では、前記の加工処理の過程においてＨＤＤ２５の共有コンテンツファイルをデータ処理部２３に読み出して処理を施しているだけであり、ＨＤＤ２５の共有コンテンツファイルは元のままの格納状態にある。
即ち、サーバ２では元の共有コンテンツファイルはそのままにしてエフェクトファイルと更新情報のみを保存・登録させ、また既に前回の加工処理に係るエフェクトファイルと更新情報が存在する場合にはそれを更新する態様で保存・登録させている。
従って、ＨＤＤ２５の共有コンテンツファイルとエフェクトファイル等の格納領域は加工処理内容によるエフェクトファイルのデータ量の変動があるだけであり、共有コンテンツファイルに対する加工処理がなされる度にデータ量が増大するようなことはない。
【００３１】
このようにしてエフェクトファイルと更新情報の保存・登録がなされると、サーバ２ではデータ管理部２２がエフェクトファイルの登録通知（既存のエフェクトファイル等が存在した場合には更新通知）を作成してユーザ端末４側へ送信する（Ｓ８）。
また、その保存（更新）通知を受信したユーザ端末４では、その通知を得ることで共有コンテンツファイルの更新が正常になされたことを確認する（Ｔ９）。
この場合、ユーザ端末４側からみると、見かけ上、共有コンテンツファイルが更新されたことになるが、サーバ２側では、前記のように共有コンテンツファイル自体には加工を施しておらず、エフェクトファイルと更新情報を保存（更新）しているだけである。
【００３２】
［実施形態２］
この実施形態では、各ユーザ端末３，４，…の内でユーザ端末３のように監視アプレット３６を備えた端末からインターネット１を介してサーバ２が格納している共有コンテンツファイルの更新情報を確認し、更に共有コンテンツファイルの閲覧やエフェクトファイルのみを得て利用する場合について説明する。
以下、その手順を図３の通信シーケンスフローチャートを参照しながら説明する。
先ず、サーバ２の通信制御部２１は各ユーザ端末３，４，…との通信の待ち受け状態にあり、またユーザ端末３の通信制御部３１も通信可能状態にあって、ユーザ端末３側からの認証要求に対してサーバ２側が認証応答を行うことでリンクを確立させることは、前記の実施形態１においてサーバ２とユーザ端末４による通信手順と同様である（Ｓ２１，Ｔ２１，Ｓ２２，Ｔ２２，Ｔ２３）。
従って、この実施形態ではその手順についての説明は省略する。
【００３３】
サーバ２とユーザ端末３の間でリンクが確立すると、ユーザ端末３では直ちに監視アプレット３６を起動させ、サーバ２側のエフェクトファイルの更新状態を監視する（Ｔ２４）。
この監視動作は、リンクが確立されている状態でサーバ２に対するアクセスを繰り返して常時監視するようにしてもよいし、また、入力操作部３３から予め所望の時刻や定期的な時刻を設定しておいて、その時刻になると監視アプレット３６がサーバ２をアクセスして監視するようにしてもよい。
【００３４】
その場合の監視シーケンスは次のような手順で実行される。
先ず、サーバ２は各ユーザ端末３，４，…に対して最新の更新情報（エフェクトファイルが作成された日時情報及びエフェクトファイルから得られる加工情報）を公開しており、ユーザ端末３の監視アプレット３６は前回の監視時に得られた更新情報を保存し、アクセス時に前回の更新情報と最新の更新情報とを比較して異なっていれば共有コンテンツファイルが更新されたと検知する。
従って、ユーザ端末３ではサーバ２側の共有コンテンツファイルが更新されたか否かを前記の監視時刻に直ちに検知することができる。
即ち、この実施形態では、ユーザ端末３がサーバ２側から更新通知を受けるのではなく、ユーザがリアルタイムに又は所望時刻に更新の有無を検知できる。
【００３５】
そして、ユーザ端末３の監視アプレット３６は、前記の手順で更新されたことを検知すると、直ちにサーバ２に対して更新情報の要求を行い、その要求を受けたサーバ２では、直ちにＨＤＤ２５から更新情報を読み出してユーザ端末３側へ送信する（Ｔ２５，Ｔ２６，Ｓ２３）。
更新情報を受信したユーザ端末３では取得した更新情報をＨＤＤ３５にセーブし、それを表示部３４に読み出して表示させることによりユーザの閲覧に供する（Ｔ２７）。
この場合、実施形態１で説明したように、更新情報には日時情報と共にエフェクトファイルから得られた加工情報が含まれているため、例えば、鮮鋭化やぼかしや増色／減色等の処理内容の要目も表示させることができ、ユーザは共有コンテンツファイルに対して直前になされた加工処理の内容も確認することができる。
【００３６】
ユーザ端末３のユーザは、前記の更新情報を閲覧して更新後の共有コンテンツファイルやエフェクトファイルを見たい場合には、入力操作部３３からファイル取得要求を行う（Ｔ２８，Ｔ２９）。
この場合の要求は、共有コンテンツファイル自体の閲覧要求とエフェクトファイルの取得要求を入力操作部３３で選択的に行うことができ、ユーザ端末３のデータ処理部３２はその選択に応じた要求信号をサーバ２側へ送信させる。
【００３７】
前記の要求信号を受信したサーバ２では、データ管理部２２が何れの要求かを判断し、共有コンテンツファイル自体の閲覧要求であった場合には、ＨＤＤ２５から共有コンテンツファイルとエフェクトファイルをデータ処理部２３へ転送し、データ処理部２３でエフェクトファイルを用いて共有コンテンツファイルに加工処理を施すことにより直前に更新されたコンテンツファイルを再生する（Ｓ２４，Ｓ２５，Ｓ２６）。
一方、エフェクトファイルの取得要求であった場合には、ＨＤＤ２５からエフェクトファイルのみを読み出す（Ｓ２７）。
そして、データ管理部２２は加工処理後のコンテンツファイル又はエフェクトファイルを通信制御部２１へ転送し、ユーザ端末３側へ送信させる（Ｓ２８）。
【００３８】
ユーザ端末３では、前記ファイルを受信するとデータ処理部３２がそのファイルをＨＤＤ３５に格納し、コンテンツファイルの場合にはそれを表示部３４へ転送して表示させる（Ｔ３０，Ｔ３１）。
従って、ユーザは現時点での更新されたコンテンツファイルの画像を見ることができる。
【００３９】
一方、エフェクトファイルだけを取得した場合には、元の共有コンテンツファイルが無いために更新されたコンテンツファイルを再生することはできない。
しかし、エフェクトファイルは画像データに対する加工処理プログラムモジュールとしての性質を有しており、共有コンテンツファイルだけでなく、他の画像ファイルに対しても使用できる（Ｔ３１）。
従って、例えば、ユーザ端末３のＨＤＤ３５にユーザが作成した画像ファイルをＨＤＤ３５に用意しておき、その画像ファイルに対して前記のエフェクトファイルを適用して加工処理を行い、エフェクトファイルに記述されている処理方法の面白さ等を独自に楽しむことが可能になる。
即ち、この実施形態によれば、共有コンテンツファイルの更新をエフェクトファイルの保存形式で行っていることにより、共有コンテンツファイルを介したコミュニケーションだけでなく、エフェクトファイルを介したコミュニケーションをも実現する。
【００４０】
［実施形態３］
前記の実施形態１及び実施形態２では、各ユーザ端末３，４，…がサーバ２に接続する場合に認証手順（図２のステップＳ１〜Ｔ３，図３のステップＳ２１〜Ｔ２３）を経ており、サーバ２が特定のユーザ端末３，４，…にのみ共有コンテンツファイルに対するアクセス権を認めているが、共有コンテンツファイルを広く一般に公開する場合もあり得る。
そのような場合には、図４に示すように、サーバ２’に一般公開用ファイルを格納するためのＨＤＤ２６を別途に設け、特定ユーザのファイルとは別に一般公開用ファイルを管理する。
そして、サーバ２’のデータ管理部２２は、ＨＤＤ２４のユーザ管理情報を用いて特定ユーザのユーザ端末３，４，…からのアクセスか一般ユーザのユーザ端末５からのアクセスかを判断し、特定ユーザ用のファイルはＨＤＤ２５に、一般公開用のファイルはＨＤＤ２６にそれぞれ別に格納させるようにして独立に管理する。
尚、公開用の共有コンテンツファイルに関するエフェクトファイルの登録（更新）やユーザ端末からの閲覧等については、サーバ２’は一般ユーザのユーザ端末５からのアクセスに対しても特定ユーザのユーザ端末３，４，…の場合と同様の手順で応答する。
【００４１】
ところで、一般公開用のファイルの場合には、その性質上、修復不能な加工や特殊なプログラムによる共通コンテンツファイルの消去等の予期しない操作が行われる可能性がある。
そこで、図４に示すように、この実施形態のサーバ２’にはバックアップ用のＨＤＤ２７を設け、予めそのＨＤＤ２７に元の共有コンテンツファイルのコピーを格納しておくと共に、一般ユーザのユーザ端末５から加工要求があってＨＤＤ２６の共有コンテンツファイルの更新を行う際には、その直前のエフェクトファイルと更新情報をＨＤＤ２７に格納させる。
尚、エフェクトファイルと更新情報をＨＤＤ２７に格納する際には、既に格納されているエフェクトファイルと更新情報を書き換えてもよいが、この場合にはエフェクトファイルと更新情報の履歴を全て残すようにしてもよい。
後者の場合には、ＨＤＤ２７が記憶するデータ量が増大してゆくことになるが、差分をとって圧縮する方法や一定期間毎に古いデータを消去する方法によってデータ量の増大を抑制できる。
【００４２】
［実施形態４］
前記の実施形態２で説明した共有コンテンツファイルの管理方法については、次のような拡張的方法を採用することも可能である。
（１） 実施形態２においては、ユーザ端末３からファイル取得要求がなされた場合に、サーバ２はエフェクトファイルを用いて加工処理した共有コンテンツファイルをユーザ端末３側へ送信するようにしている（図２：Ｔ２９，Ｓ２４〜Ｓ２６，Ｓ２８）。
しかし、一般には加工処理された共有コンテンツファイルは他のユーザ端末で更新されたものであるため、ユーザ端末３がそのファイルを再生するための十分な機能を備えていない場合もあり得る。
そのような場合には、ユーザ端末３がその再生機能での再生条件を予めサーバ２側へ通知しておき、サーバ２がその条件に適合するように加工処理後の共有コンテンツファイルを更に加工処理するようにすれば、ユーザ端末３側では自己の機能の制約を受けることなく全てのファイルを閲覧することができる。
尚、ユーザ端末３からの再生条件の通知は、サーバ２とユーザ端末３のリンク確立後からファイル送信前までの間に行えばよいが、ファイル取得要求（Ｔ２９）の際に行うのが合理的である。
（２） 実施形態２では特定の１つの共有コンテンツファイルを監視対象としているが、サーバ２が複数の共有コンテンツファイルを管理している場合には、監視アプレット３６によってそれらを一括して監視対象としてもよい。
（３） ユーザ端末３の監視アプレット３６は、サーバ２側の共有コンテンツファイルの更新を検知するとサーバ２に対して更新情報の要求を行うが、ユーザ端末３が音声出力機能を有していれば、更新の検知と同時に音声による通知を行わせるようにしてもよい。また、ユーザ端末３がＬＥＤ等を備えていれば、それを点滅させる等によって更新検知の通知を行わせることもできる。
尚、上記の各実施形態では画像データの共有コンテンツファイルについて説明したが、音楽やプログラム等の多種多様なコンテンツを扱うことが可能である。
【００４３】
【発明の効果】
本発明の共有コンテンツファイルの更新管理方法は、以上の構成を有していることにより、次のような効果を奏する。
請求項１の発明は、更新される共有コンテンツファイルをサーバのメモリスペースを圧迫することなく保存することができ、また、ユーザ端末側が監視アプレットで能動的にサーバ側の共有コンテンツファイルの更新状態を監視して、詳細な更新情報を自動的に得ることを可能にする。
これにより、共有コンテンツファイルを介したユーザ端末同士のコミュニケーションをよりリアルタイムに近い円滑な手順で実現できる。
請求項２の発明は、サーバ側において、少ないデータ量で共有コンテンツファイルの更新を管理しながら、閲覧要求に対しては加工後の共有コンテンツファイルを再生して提供することを可能にする。
請求項３の発明は、ユーザ端末側でエフェクトファイルによる加工処理を他のコンテンツファイルに適用して加工処理の面白さを体験でき、エフェクトファイルを用いたコミュニケーションを実現する。
請求項４の発明は、直前に更新された共有コンテンツファイルの状態をバックアップさせることで、修復不能な加工やファイルの消失に対処することを可能にする。特に、共有コンテンツファイルを特定ユーザだけでなく、一般に公開する場合において有効である。
請求項５の発明は、更新された共有コンテンツファイルの属性等によってユーザ端末側で再生不能になるような場合に、サーバ側でユーザ端末に適合した加工処理を行うことにより、ユーザ端末側においてその機能上の制約を受けることなく共有コンテンツファイルを再生できるようにする。
【図面の簡単な説明】
【図１】本発明の実施形態に適用されるサーバとユーザ端末のブロック構成図と、それらがインターネットを介して接続されたネットワークを示す概略図である。
【図２】実施形態１に係る共有コンテンツファイルの加工手順を示す通信シーケンスフローチャートである。
【図３】実施形態２に係る監視アプレットによる共有コンテンツファイルの更新確認及びその閲覧等の手順を示す通信シーケンスフローチャートである。
【図４】実施形態３（共有コンテンツファイルを一般に公開する場合）に適用されるサーバとユーザ端末のブロック構成図と、それらがインターネットを介して接続されたネットワークを示す概略図である。
【符号の説明】
１…インターネット、２，２’…サーバ、３，４，５…ユーザ端末、２１，３１，４１…通信制御部、２２…データ管理部、２３，３２，４２…データ処理部、２４，２５，２６，２７，３５，４５…ハードディスク装置（ＨＤＤ）、３３，４３…入力操作部、３４，４４…表示部、３６…監視アプレット。

Claims (5)

1. ネットワークを介してサーバと複数のユーザ端末とが配置され、前記サーバに対して前記ユーザ端末からアップロードされた共有コンテンツファイル又は前記サーバ側で作成した共有コンテンツファイルを前記サーバに登録せしめ、前記ユーザ端末から前記共有コンテンツファイルを閲覧・加工することが可能なネットワークシステムにおける共有コンテンツファイルの更新管理方法であって、
   前記サーバに登録されている前記共有コンテンツファイルに対して前記ユーザ端末側から加工要求がなされた場合に、
   前記サーバは、前記共有コンテンツファイルを加工することなく、前記ユーザ端末による個々の加工処理方法とその加工に必要なパラメータとからなるエフェクトオブジェクト及び前記加工処理の順序情報を記述したエフェクトファイルを作成する手順と、そのエフェクトファイルを少なくとも日時情報とそのエフェクトファイルから得られる加工情報とを含む更新情報と共に登録（但し、先の加工要求に係るエフェクトファイルと更新情報がある場合にはそれらを書き換えて登録）する手順とを実行し、
   一方、前記ユーザ端末は常時又は予め設定した時刻に前記サーバ側の共有コンテンツファイルの前記更新情報を監視する監視アプレットを備えており、
   前記ユーザ端末による前記サーバに登録されている前記共有コンテンツファイルの更新情報の確認に際しては、
   前記監視アプレットによる新規な更新の検知に基づいて、前記ユーザ端末が前記サーバに対して前記更新情報の閲覧要求を送信する手順と、
   前記サーバが前記閲覧要求に基づいて前記更新情報を前記ユーザ端末へ送信する手順と、
   前記ユーザ端末側が前記サーバから受信した前記更新情報を表示手段で表示させる手順と
   によって行われることを特徴とする共有コンテンツファイルの更新管理方法。
2. 前記ユーザ端末による前記サーバに登録されている前記共有コンテンツファイルの閲覧に際しては、
   前記ユーザ端末が前記サーバに対して前記共有コンテンツファイルの閲覧要求を送信する手順と、
   前記閲覧要求に基づいて、前記サーバが、前記エフェクトファイルを用いて前記共有コンテンツファイルを加工処理し、その加工処理後の共有コンテンツファイルを前記ユーザ端末側へ送信する手順と
   によって行われることとした請求項１に記載の共有コンテンツファイルの更新管理方法。
3. 前記ユーザ端末が前記サーバに対して共有コンテンツファイルの閲覧要求又はエフェクトファイルのみの閲覧要求を選択的に行うことができ、エフェクトファイルのみの閲覧要求があった場合に、前記サーバは前記エフェクトファイルだけを読み出して前記ユーザ端末へ送信することとした請求項１又は請求項２に記載の共有コンテンツファイルの更新管理方法。
4. 前記サーバは前記共有コンテンツファイルをバックアップ用記憶手段に格納させておき、先の加工要求に係るエフェクトファイルと更新情報を今回の加工要求に係るエフェクトファイルと更新情報に書き換えて登録する場合に、先の加工要求に係るエフェクトファイルと更新情報を前記バックアップ用記憶手段に格納することとした請求項１、請求項２又は請求項３に記載の共有コンテンツファイルの更新管理方法。
5. 前記ユーザ端末が閲覧要求に係る加工処理後の共有コンテンツファイルを受信した際に、前記ユーザ端末がその共有コンテンツファイルを再生するための十分な機能を備えていない場合には、前記ユーザ端末が前記サーバに対して再生可能な条件を通知し、前記サーバが前記加工処理後の共有コンテンツファイルを前記条件に対応させるように更に加工処理を施して前記ユーザ端末へ送信することとした請求項１、請求項２、請求項３、又は請求項４に記載の共有コンテンツファイルの更新管理方法。

Images