JP2004310464A - 共有コンテンツファイルの更新管理方法 - Google Patents
共有コンテンツファイルの更新管理方法 Download PDFInfo
- Publication number
- JP2004310464A JP2004310464A JP2003103358A JP2003103358A JP2004310464A JP 2004310464 A JP2004310464 A JP 2004310464A JP 2003103358 A JP2003103358 A JP 2003103358A JP 2003103358 A JP2003103358 A JP 2003103358A JP 2004310464 A JP2004310464 A JP 2004310464A
- Authority
- JP
- Japan
- Prior art keywords
- server
- file
- user terminal
- shared content
- content file
- 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.)
- Pending
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】サーバに登録された各ユーザ端末の共有コンテンツファイルの更新管理方法において、各ユーザ端末から能動的に更新を監視して更新情報が得られるようにする。
【解決手段】ユーザ端末3,4…から共有コンテンツファイルの更新要求があると、サーバ2側では、そのファイルは加工せず、個々の加工処理方法とその所要パラメータとからなるエフェクトオブジェクト及び加工順序を記述したエフェクトファイルと日時情報とを作成してHDD25に登録する。ユーザ端末3の監視アプレット36はサーバ2側の更新状態を監視し、更新検知によりサーバ2へ更新情報の要求を行い、サーバ2は前記日時情報と加工情報からなる更新情報をユーザ端末3へ送信する。また、各ユーザ端末3,4…からのファイル閲覧要求に対しては、エフェクトファイルを用いて共有コンテンツファイルを加工・再生して送信する。
【選択図】 図1
【解決手段】ユーザ端末3,4…から共有コンテンツファイルの更新要求があると、サーバ2側では、そのファイルは加工せず、個々の加工処理方法とその所要パラメータとからなるエフェクトオブジェクト及び加工順序を記述したエフェクトファイルと日時情報とを作成してHDD25に登録する。ユーザ端末3の監視アプレット36はサーバ2側の更新状態を監視し、更新検知によりサーバ2へ更新情報の要求を行い、サーバ2は前記日時情報と加工情報からなる更新情報をユーザ端末3へ送信する。また、各ユーザ端末3,4…からのファイル閲覧要求に対しては、エフェクトファイルを用いて共有コンテンツファイルを加工・再生して送信する。
【選択図】 図1
Description
【0001】
【発明の属する技術分野】
本発明はネットワーク上の共有ファイル更新管理方法に係り、サーバ上に設けた共有コンテンツファイルを各ユーザ端末側から加工処理できるようにしてコミュニケーションの場を提供する場合に、共有コンテンツファイルの更新情報を各ユーザ端末側から確認でき、またサーバ側においても更新される共有コンテンツファイルを少ないデータ量で保存できる方法に関する。
【0002】
【従来の技術】
近年、パーソナルコンピュータに加えて電子メール・ブラウザ機能を備えた携帯電話等の各種端末の広範な普及により、電子メールの送受信、Webページの作成・閲覧、データのアップ・ダウンロード等のインターネットを介したコミュニケーションが多種多様な方式で行われるようになっている。
【0003】
電子メールによる通信では、電話通信のようにリアルタイムな相手の都合や時間を気遣うことなく送信先へ文字データを送信し、ネットワーク上のトラフィック等に問題がない限り、直ちに送信先の端末又はISP(Internet service Provider)のネットワークストレージに電子メールを届けることができる。
一方、送信先では任意の時間に電子メールを読めるため、送信元と送信先の双方が時間を問わずに文字データによるコミュニケーションが行える。
そして、多くの電子メールツールは添付ファイル機能も備えており、画像等のコンテンツファイルを添付して送信できることから、文字データだけでなく各種コンテンツによるコミュニケーションも可能であり、そのための支援システムについては下記の特許文献1〜3等のように各種の提案がなされている。
また、前記電子メール以外のインターネットを介したコミュニケーション方式としてチャットがある。
この方式は、インターネット上に設けた文字記入画面に対して複数の端末から文字が書き込まれて時系列的に追記更新されるものであり、これも文字によるリアルタイムなコミュニケーションの場を提供するものである。
【0004】
しかし、前記の電子メールによる通信は、基本的にはPeer−to−Peerの一方的な連絡手段であると共に、電子メールにファイルを添付して送信すると送信先にはそのファイルがコピーされ、特に、添付ファイルが画像データであるような場合には、送信先の端末のメモリスペースを圧迫してリソースの無駄遣いになることが少なくない。
また、前記のチャットは文字に限定されたコミュニケーションだけであり、リアルタイムにやり取りを行いたい場合には、各端末側でそのためのアプリケーションを立ち上げてログオンした後、チャットウィンドウを継続的に開いておかねばならない。
即ち、電子メールやチャットはインターネット上の最も一般的なコミュニケーションの方式であるが、前記のような問題点を含んでいる。
【0005】
一方、WWW(World Wide Web)では、Webサーバ上のWebページや画像・音声等のコンテンツファイルに複数の端末からアクセスでき、それらコンテンツの内容を見聞きすることができる。
また、Webページの中には、コンテンツファイルの提示だけでなく、任意の又は特定のユーザ端末から書き込みが行える“電子掲示板”を設けておき、文字による相互コミュニケーションの場を提供しているようなWebサイトもある。
そして、そのようなWebサイトを監視するユーザ端末側のアプリケーションソフトとしてWWWC(Webページの更新チェッカ)がある。
このWWWCは、予めユーザによって監視対象とするURL(Uniform Resource Locators)をユーザ端末に登録させておき、指示を与えることにより、又は指定した時刻や定期的な間隔で前記URLに接続してWebページを確認できるようにしたものである。
従って、WWWCを用いると、コンテンツファイルに記述された特定のメタデータやファイルサイズや更新時刻からコンテンツファイルの更新の有無を判断することが可能である。
尚、このようなシステムに関連したものとして、例えば、下記の特許文献4,5等のように各種の提案がなされている。
【0006】
【特許文献1】
特開2001−34547号公報
【特許文献2】
特開2001−211438号公報
【特許文献3】
特開2002−190833号公報
【特許文献4】
特開2002−140323号公報
【特許文献5】
特表2002−523842号公報
【0007】
【発明が解決しようとする課題】
【0008】
ところで、前記のWebサーバ上のWebページも、基本的にはコンテンツの作成者がその内容を多くのユーザに対して一方的に見聞きさせるものであって、そのコンテンツファイルの管理者以外の者にコンテンツファイル自体の変更を認めるものではない。
そして、WWWCのようにWebサーバ上のコンテンツファイルに関する更新チェッカは存在するが、通常はコンテンツファイルの変化を目視的に観察して更新の有無を確認できるに過ぎない。
即ち、コンテンツファイル内に前記の更新通知システムが解読可能なメタデータが記述されているような場合には、それから何等かの更新情報が得られることもあるが、メタデータはコンテンツファイルの作成者が自由に記述する任意情報であって、それを記述していないものも多数ある。
【0009】
一方、Webサーバ上に共有データファイルを置いて各ユーザ端末からそのファイルの閲覧及び変更を行えるようにした場合、ファイルのバージョン管理システム(例えば、CVSやRCS等)を利用すれば、ファイルの閲覧・変更に係る詳細な情報を通知することができる。
具体的には、前記のバージョン管理システムによれば、データファイル内に訂正・修正情報等を記述でき、指定したデータファイルの更新時にその更新通知を電子メールで指定した宛先に通知することが可能であると共に、データファイルの差分を別ファイルに保存しておいて後から各バージョンのデータファイルの差分を比較したり、個々のユーザが変更したデータファイルをマージすることも可能になる。
【0010】
しかし、共有データファイルの更新情報に関しては、前記のバージョン管理システムも電子メールで更新通知をユーザ端末へ送信するだけである。
そして、共有データファイルの更新がなされる度に一方的に送られてくる更新通知に対して、ユーザ端末側は自らが管理できない立場にあり、頻繁に更新がなされるデータファイルのような場合には電子メールの整理等が煩わしくなる。
また、データファイルの差分をとって管理できることは、プログラム言語や文書等のテキストで記述されたファイルについては有効であるが、画像ファイル等のバイナリデータの場合には、更新された変更部分のみを差分として保存できないことが多い。
即ち、画像ファイルの変更は全体に効果をかけたり色を変更したりして加工することが多いため、変更部分のみを差分として保存する方法は馴染まず、また、JPEG等の圧縮フォーマットの画像データは見た目上は画像の一部分に加工を施していてもデータ全体が変更されてしまうことも考えられるために変更のマージが極めて困難である。
更に、画像ファイル自体はフォーマットが決まっているため、ファイル中にメタデータを記述できるフォーマットの画像を用いるか、又は画像データ中にメタ情報を埋め込むための特殊なアプリケーションを利用しない限り、版の相違を画像ファイル内に記述することは難しい。
従って、データファイルが画像ファイル等のバイナリデータの場合には、結局、更新される度にそれ以前のデータと共に更新データを一括して新たに保存することになる。
その場合、例えば、最近のディジタルカメラ等で撮った画像等は一般に数百KB〜数MBのデータ量になり、更新の度に大きなデータ量のファイルができることになるため、サーバ上のメモリスペースを圧迫してゆくことになる。
【0011】
要約すると、Webサーバ上のコンテンツファイルや共有データファイルについて変更がなされた場合に、ユーザ端末側ではサーバ側の更新通知システムやバージョン管理システムによって更新の事実を確認できることになるが、それ以上の情報は得られず、また、画像ファイル等のバイナリデータについては、更新の度にサーバのメモリスペースが圧迫されるために、大容量の記憶装置を設けておかなければならないという問題がある。
【0012】
そこで、本発明は、サーバ上の共有コンテンツファイルを各ユーザ端末側から加工でき、サーバ側では加工後の共有コンテンツファイルを少ないデータ量で保存できると共に、各ユーザ端末側から更新情報を監視して更新後の加工情報や共有コンテンツファイル自体を所望のタイミングで閲覧できる共有コンテンツファイル更新管理方法を提供し、もって、ユーザ端末同士で共有コンテンツファイルを介したよりリアルタイムでフレキシブルなコミュニケーションを可能にすることを目的として創作された。
【0013】
【課題を解決するための手段】
本発明は、ネットワークを介してサーバと複数のユーザ端末とが配置され、前記サーバに対して前記ユーザ端末からアップロードされた共有コンテンツファイル又は前記サーバ側で作成した共有コンテンツファイルを前記サーバに登録せしめ、前記ユーザ端末から前記共有コンテンツファイルを閲覧・加工することが可能なネットワークシステムにおける共有コンテンツファイルの更新管理方法であって、前記サーバに登録されている前記共有コンテンツファイルに対して前記ユーザ端末側から加工要求がなされた場合に、前記サーバは、前記共有コンテンツファイルを加工することなく、前記ユーザ端末による個々の加工処理方法とその加工に必要なパラメータとからなるエフェクトオブジェクト及び前記加工処理の順序情報を記述したエフェクトファイルを作成する手順と、そのエフェクトファイルを少なくとも日時情報とそのエフェクトファイルから得られる加工情報とを含む更新情報と共に登録(但し、先の加工要求に係るエフェクトファイルと更新情報がある場合にはそれらを書き換えて登録)する手順とを実行し、一方、前記ユーザ端末は常時又は予め設定した時刻に前記サーバ側の共有コンテンツファイルの前記更新情報を監視する監視アプレットを備えており、前記ユーザ端末による前記サーバに登録されている前記共有コンテンツファイルの更新情報の確認に際しては、前記監視アプレットによる新規な更新の検知に基づいて、前記ユーザ端末が前記サーバに対して前記更新情報の閲覧要求を送信する手順と、前記サーバが前記閲覧要求に基づいて前記更新情報を前記ユーザ端末へ送信する手順と、
前記ユーザ端末側が前記サーバから受信した前記更新情報を表示手段で表示させる手順とによって行われることを特徴とする共有コンテンツファイルの更新管理方法に係る。
【0014】
本発明によれば、ユーザ端末から共有コンテンツファイルの加工要求があった場合に、サーバは共有コンテンツファイル自体には加工を施さずに、エフェクトファイルと更新情報だけを書き換えながら登録する。
従って、加工がなされる度にその共有コンテンツファイルを保存してゆく場合と比較して、保存データ量は遥かに少なくなり、サーバ側のメモリスペースが圧迫されることはない。
そして、この発明ではユーザ端末の監視アプレットが共有コンテンツファイルの更新情報を監視して更新の事実を検知するようになっており、従来のようにサーバ側から通知を受けるような受身の立場ではなく所望の時点でユーザ端末側から能動的に更新の有無を監視でき、更にその時点での更新情報を自動的に受信できる。
特に、更新情報には日時情報に加えてエフェクトファイルから得られた加工情報が含まれるため、共有コンテンツファイルにどのような加工が施されたかも確認できるという利点がある。
【0015】
また、本発明によれば、前記ユーザ端末による前記サーバに登録されている前記共有コンテンツファイルの閲覧については、前記ユーザ端末が前記サーバに対して前記共有コンテンツファイルの閲覧要求を送信する手順と、前記閲覧要求に基づいて、前記サーバが、前記エフェクトファイルを用いて前記共有コンテンツファイルを加工処理し、その加工処理後の共有コンテンツファイルを前記ユーザ端末側へ送信する手順とを実行させることによって行える。
即ち、少ないデータ量で共有コンテンツファイルの更新を管理しながら、閲覧要求に対しては加工後の共有コンテンツファイルを再生して提供できる。
【0016】
また、前記ユーザ端末が前記サーバに対して共有コンテンツファイルの閲覧要求又はエフェクトファイルのみの閲覧要求を選択的に行えるようにしておき、エフェクトファイルのみの閲覧要求がなされた場合に、前記サーバが前記エフェクトファイルだけを読み出して前記ユーザ端末へ送信するようにすれば、前記ユーザ端末は前記エフェクトファイルのみを得ることができる。
その場合、前記エフェクトファイルは共有コンテンツファイルに対する加工処理の内容を記述したものであるが、前記ユーザ端末側において他のコンテンツファイルに前記エフェクトファイルを作用させることでその加工処理の面白さを体験することができ、単に共有ファイルを介したコミュニケーションだけでなく、エフェクトファイルを用いたコミュニケーションも可能になる。
【0017】
また、前記サーバにおいて、前記共有コンテンツファイルをバックアップ用記憶手段に格納させておき、先の加工要求に係るエフェクトファイルと更新情報を今回の加工要求に係るエフェクトファイルと更新情報に書き換えて登録する場合に、先の加工要求に係るエフェクトファイルと更新情報を前記バックアップ用記憶手段に格納するようにしてもよい。
このバックアップによって、修復不能な加工処理や特殊なプログラムによる共通コンテンツファイルの消去等の予期しない操作が行われた場合にも直前の状態へ戻すことができる。
その場合、バックアップ用記憶手段に格納されるデータは、元の共有コンテンツファイルと直前の加工処理に係るエフェクトファイルと更新情報だけであり、通常の保存・登録用の記憶手段と同様に、バックアップ用記憶手段のメモリスペースが圧迫されることはない。
【0018】
また、前記ユーザ端末が閲覧要求に係る共有コンテンツファイルを受信した際に、前記ユーザ端末がその共有コンテンツファイルを再生するための十分な機能を備えていない場合には、前記ユーザ端末が前記サーバに対して再生可能な条件を通知し、前記サーバが前記加工処理後の共有コンテンツファイルを前記条件に対応させるように更に加工処理を施して前記ユーザ端末へ送信するようにすれば、共有コンテンツファイルの属性等によってそのままでは前記ユーザ端末で再生できないような場合にも、前記サーバ側が適応的に加工処理を行うことでその不都合を解消できる。
【0019】
【発明の実施の形態】
以下、本発明の「共有コンテンツファイルの更新管理方法」の実施形態を、図面を用いて詳細に説明する。
先ず、図1は、インターネット1を介してサーバ2とユーザ端末3,4が配置されており、サーバ2とユーザ端末3,4をブロック構成図として示した概略図である。但し、実際には多数のユーザ端末が接続されることになるが、図1では2つのユーザ端末3,4だけが接続されているネットワーク構成になっている。
この実施形態では、サーバ2側で作成した画像コンテンツファイル又は各ユーザ端末3,4,…で作成されてインターネット1を介してサーバ2側へアップロードされた画像コンテンツファイルを各ユーザ端末3,4,…の共有コンテンツファイルとし、サーバ2側がその共有コンテンツファイルを管理しながら、各ユーザ端末3,4,…に対して前記共有コンテンツファイルの加工・閲覧等を認めるネットワークシステムを例にとって説明する。
【0020】
ここで、サーバ2は、インターネット1との間で通信制御を実行する通信制御部21と、データの入出力やアクセス権等の管理を行うデータ管理部22と、共有コンテンツファイルに対して加工がなされた場合にはその加工に係るエフェクトファイルを作成し、共有コンテンツファイルの閲覧要求があった場合に前記エフェクトファイルを用いて加工後のコンテンツファイルを生成させるデータ処理部23と、アクセス権等に係るユーザ管理情報を格納したハードディスク装置(HDD)24と、共有コンテンツファイルやエフェクトファイル等を格納するHDD25とからなる。
一方、各ユーザ端末3,4は、それぞれ、インターネット1との間で通信制御を実行する通信制御部31,41と、データの処理や入出力等を制御するデータ処理部32,42と、キーボード等からなる操作入力部33,43と、表示部34,44と、HDD35,45を備えており、ユーザ端末3に関しては、更にインターネット1を介して常時又は定期的にサーバ2側の共有コンテンツファイルの更新状態を監視するための監視アプレット36を備えている。
尚、この実施形態ではユーザ端末3だけが監視アプレット36を有しているが、ユーザ端末4や他のユーザ端末が同様の監視アプレット36を備えていてもよい。
【0021】
[実施形態1]
この実施形態では、各ユーザ端末3,4,…からインターネット1を介してサーバ2が格納している共有コンテンツファイルを加工する場合の手順を、図2の通信シーケンスフローチャートを参照しながら説明する。
但し、ここではユーザ端末4から加工がなされる場合を例にとる。
先ず、前記のように、サーバ2のHDD25には各ユーザ端末3,4,…が共有する画像コンテンツファイルが格納されており、サーバ2の通信制御部21は各ユーザ端末3,4,…との通信の待ち受け状態にあり(S1)、ユーザ端末4の通信制御部41も通信可能状態にある。
【0022】
ここで、ユーザ端末4において、入力操作部43でサーバ2に対する認証要求のための操作を行うと、データ処理部42が通信制御部41を制御して認証要求信号をサーバ2側へ送信する(T1)。
サーバ2は、インターネット1を介して通信制御部21で認証要求信号を受信すると、データ管理部22が受信した認証要求信号のユーザ情報とHDD24のユーザ管理情報とを照合し、ユーザ端末4に対してその照合結果に基づいた認証応答を返送する(S2)。
そして、ユーザ端末4では、認証応答が許可応答であればリンクが確立して次の手順として共有コンテンツファイルの指定を行う操作へ移行するが(T2,T4)、認証応答が不許可応答である場合には再び認証要求操作を行って前記の手順を繰り返すことになる(T2,T3)。尚、再認証手順でもサーバ2側から許可応答が得られない場合には、サーバ2とのリンクが不能であり操作が終了する。
【0023】
許可応答を受信したユーザ端末4では、操作入力部43からサーバ2側の共有コンテンツファイルのファイル指定を行い、その指定情報をサーバ2側へ送信する(T4)。
一方、ファイル指定情報を受信したサーバ2は、データ管理部22がHDD25を検索し、指定された共有コンテンツファイルを開いてユーザ端末4側へ送信する(S3)。
尚、ここでは、共有コンテンツファイルが初めて加工される場合を例にとるが、既に各ユーザ端末3,4,…によってその共有コンテンツファイルに加工がなされている場合には、後述のエフェクトファイルを用いて共有コンテンツファイルを加工処理してユーザ端末4側へ送信することになる。
【0024】
ファイル指定に係る共有コンテンツファイルを受信したユーザ端末4では、データ処理部42がそのファイルをHDD45へセーブさせた後、そのコンテンツ画像を表示部44に表示させ、ユーザは共有コンテンツファイルの内容を確認する(T5)。
そして、表示画像を見ながら入力操作部43によってその画像の加工処理を施すと、データ処理部42がその加工に係る処理情報をサーバ2側へ送信させる(T6)。
【0025】
一方、加工処理情報を受信したサーバ2では、データ管理部22がデータ処理部23を起動させ、HDD25の前記指定に係る共有コンテンツファイルをデータ処理部23へ読み出し、データ処理部23によって加工処理情報を用いた共有コンテンツファイルの加工処理を実行させる(S4)。
その場合、データ処理部23では、受信した加工処理情報に基づいて読み出された共有コンテンツファイルを加工すると共に、その加工処理毎のエフェクトファイルを作成する(S4,S5)。
【0026】
このエフェクトファイルは加工処理内容を記述したファイルであるが、画像の鮮鋭化、ぼかし、増色/減色、エンボス加工、拡大/縮小等の個々の処理とその処理に関するパラメータを1つのエフェクトオブジェクトとして扱い、複数の処理が行われた場合にはその処理数分のエフェクトオブジェクトとその処理順序を記述したものである。
例えば、特許第2965119号公報では「画像処理を個別のオブジェクト(原画像の一部を変更して変更画像を作り出す仮想レンズオブジェクト)としてまとめ、それらの追加,削除,修正を行えるようにして画像処理のフレキシビリティを向上させた画像処理システム」の提案がなされているが、エフェクトオブジェクトとしては前記提案の仮想レンズオブジェクトも適用できる。
従って、エフェクトファイルはユーザ端末4から要求された加工処理プログラムモジュールとしての性質を有し、逆に、共有コンテンツファイルに対してエフェクトファイルを適用することにより加工後の変更された画像ファイルを再生することが可能である。
【0027】
また、データ処理部23は共有コンテンツファイルを加工した後の画像データに係るプレビューを作成し、データ管理部22がそのプレビューデータをユーザ端末4側へ送信させる(S6)。
一方、プレビューデータを受信したユーザ端末4では、それを表示部44に表示させてユーザがその加工後の画像でよいかどうかを確認する(T7)。
そして、ユーザはその加工画像の内容でよければ入力操作部45から保存要求を行うが(T7,T8)、その画像に納得できずに更に加工処理を行う必要があれば入力操作部45から追加の加工処理を行い、所望の加工画像が得られるまでステップT6からステップS6の手順を繰り返して実行する(T7→T6,S4〜S6→T7)。
【0028】
その場合、前記のようにデータ処理部23では加工処理毎のエフェクトファイルを作成しているため、複数の加工処理を施したときにも、そのファイル内のエフェクトオブジェクトの時系列を逆に辿ることによって任意の段階まで戻ることができ、また不要であると思われる個別のエフェクトオブジェクトを選択的に削除することもできる。
また、それらのエフェクトオブジェクトに対する操作過程は前記の繰り返し手順においてプレビューに反映され、ユーザ端末4のユーザはプレビューを見ながら効率良く加工処理を行ってゆくことができる。
【0029】
前記の加工処理において所望の加工画像のプレビューが得られると、ユーザは入力操作部43から保存要求を行い、ユーザ端末4からサーバ2へ保存要求信号が送信される(T8)。
そして、その信号を受信したサーバ2では、データ管理部22によって、データ処理部23が作成した前記エフェクトファイルとその作成に係る日時情報と前記エフェクトファイルから得られる加工情報をHDD25の前記共有コンテンツファイルに対応するアドレス領域に保存・登録させる(S7)。
但し、ここでの「加工情報」とは加工内容を示す要目(例えば、鮮鋭化、ぼかし、増色/減色、サイズ変更等)だけであり、その処理の詳細はエフェクトファイルに記述されている。
また、以下、前記の加工情報と日時情報とを「更新情報」と言うこととする。
尚、この場合は、共有コンテンツファイルに対するユーザ端末4からの加工処理要求が最初の処理であるために、エフェクトファイルと更新情報をそのまま保存・登録させるようにしているが、既に各ユーザ端末3,4,…から共有コンテンツファイルに対する加工処理がなされており、HDD25にエフェクトファイルと更新情報が存在している場合には、それらのファイルを更新する態様で保存・登録がなされる。
【0030】
ところで、サーバ2では、前記の加工処理の過程においてHDD25の共有コンテンツファイルをデータ処理部23に読み出して処理を施しているだけであり、HDD25の共有コンテンツファイルは元のままの格納状態にある。
即ち、サーバ2では元の共有コンテンツファイルはそのままにしてエフェクトファイルと更新情報のみを保存・登録させ、また既に前回の加工処理に係るエフェクトファイルと更新情報が存在する場合にはそれを更新する態様で保存・登録させている。
従って、HDD25の共有コンテンツファイルとエフェクトファイル等の格納領域は加工処理内容によるエフェクトファイルのデータ量の変動があるだけであり、共有コンテンツファイルに対する加工処理がなされる度にデータ量が増大するようなことはない。
【0031】
このようにしてエフェクトファイルと更新情報の保存・登録がなされると、サーバ2ではデータ管理部22がエフェクトファイルの登録通知(既存のエフェクトファイル等が存在した場合には更新通知)を作成してユーザ端末4側へ送信する(S8)。
また、その保存(更新)通知を受信したユーザ端末4では、その通知を得ることで共有コンテンツファイルの更新が正常になされたことを確認する(T9)。
この場合、ユーザ端末4側からみると、見かけ上、共有コンテンツファイルが更新されたことになるが、サーバ2側では、前記のように共有コンテンツファイル自体には加工を施しておらず、エフェクトファイルと更新情報を保存(更新)しているだけである。
【0032】
[実施形態2]
この実施形態では、各ユーザ端末3,4,…の内でユーザ端末3のように監視アプレット36を備えた端末からインターネット1を介してサーバ2が格納している共有コンテンツファイルの更新情報を確認し、更に共有コンテンツファイルの閲覧やエフェクトファイルのみを得て利用する場合について説明する。
以下、その手順を図3の通信シーケンスフローチャートを参照しながら説明する。
先ず、サーバ2の通信制御部21は各ユーザ端末3,4,…との通信の待ち受け状態にあり、またユーザ端末3の通信制御部31も通信可能状態にあって、ユーザ端末3側からの認証要求に対してサーバ2側が認証応答を行うことでリンクを確立させることは、前記の実施形態1においてサーバ2とユーザ端末4による通信手順と同様である(S21,T21,S22,T22,T23)。
従って、この実施形態ではその手順についての説明は省略する。
【0033】
サーバ2とユーザ端末3の間でリンクが確立すると、ユーザ端末3では直ちに監視アプレット36を起動させ、サーバ2側のエフェクトファイルの更新状態を監視する(T24)。
この監視動作は、リンクが確立されている状態でサーバ2に対するアクセスを繰り返して常時監視するようにしてもよいし、また、入力操作部33から予め所望の時刻や定期的な時刻を設定しておいて、その時刻になると監視アプレット36がサーバ2をアクセスして監視するようにしてもよい。
【0034】
その場合の監視シーケンスは次のような手順で実行される。
先ず、サーバ2は各ユーザ端末3,4,…に対して最新の更新情報(エフェクトファイルが作成された日時情報及びエフェクトファイルから得られる加工情報)を公開しており、ユーザ端末3の監視アプレット36は前回の監視時に得られた更新情報を保存し、アクセス時に前回の更新情報と最新の更新情報とを比較して異なっていれば共有コンテンツファイルが更新されたと検知する。
従って、ユーザ端末3ではサーバ2側の共有コンテンツファイルが更新されたか否かを前記の監視時刻に直ちに検知することができる。
即ち、この実施形態では、ユーザ端末3がサーバ2側から更新通知を受けるのではなく、ユーザがリアルタイムに又は所望時刻に更新の有無を検知できる。
【0035】
そして、ユーザ端末3の監視アプレット36は、前記の手順で更新されたことを検知すると、直ちにサーバ2に対して更新情報の要求を行い、その要求を受けたサーバ2では、直ちにHDD25から更新情報を読み出してユーザ端末3側へ送信する(T25,T26,S23)。
更新情報を受信したユーザ端末3では取得した更新情報をHDD35にセーブし、それを表示部34に読み出して表示させることによりユーザの閲覧に供する(T27)。
この場合、実施形態1で説明したように、更新情報には日時情報と共にエフェクトファイルから得られた加工情報が含まれているため、例えば、鮮鋭化やぼかしや増色/減色等の処理内容の要目も表示させることができ、ユーザは共有コンテンツファイルに対して直前になされた加工処理の内容も確認することができる。
【0036】
ユーザ端末3のユーザは、前記の更新情報を閲覧して更新後の共有コンテンツファイルやエフェクトファイルを見たい場合には、入力操作部33からファイル取得要求を行う(T28,T29)。
この場合の要求は、共有コンテンツファイル自体の閲覧要求とエフェクトファイルの取得要求を入力操作部33で選択的に行うことができ、ユーザ端末3のデータ処理部32はその選択に応じた要求信号をサーバ2側へ送信させる。
【0037】
前記の要求信号を受信したサーバ2では、データ管理部22が何れの要求かを判断し、共有コンテンツファイル自体の閲覧要求であった場合には、HDD25から共有コンテンツファイルとエフェクトファイルをデータ処理部23へ転送し、データ処理部23でエフェクトファイルを用いて共有コンテンツファイルに加工処理を施すことにより直前に更新されたコンテンツファイルを再生する(S24,S25,S26)。
一方、エフェクトファイルの取得要求であった場合には、HDD25からエフェクトファイルのみを読み出す(S27)。
そして、データ管理部22は加工処理後のコンテンツファイル又はエフェクトファイルを通信制御部21へ転送し、ユーザ端末3側へ送信させる(S28)。
【0038】
ユーザ端末3では、前記ファイルを受信するとデータ処理部32がそのファイルをHDD35に格納し、コンテンツファイルの場合にはそれを表示部34へ転送して表示させる(T30,T31)。
従って、ユーザは現時点での更新されたコンテンツファイルの画像を見ることができる。
【0039】
一方、エフェクトファイルだけを取得した場合には、元の共有コンテンツファイルが無いために更新されたコンテンツファイルを再生することはできない。
しかし、エフェクトファイルは画像データに対する加工処理プログラムモジュールとしての性質を有しており、共有コンテンツファイルだけでなく、他の画像ファイルに対しても使用できる(T31)。
従って、例えば、ユーザ端末3のHDD35にユーザが作成した画像ファイルをHDD35に用意しておき、その画像ファイルに対して前記のエフェクトファイルを適用して加工処理を行い、エフェクトファイルに記述されている処理方法の面白さ等を独自に楽しむことが可能になる。
即ち、この実施形態によれば、共有コンテンツファイルの更新をエフェクトファイルの保存形式で行っていることにより、共有コンテンツファイルを介したコミュニケーションだけでなく、エフェクトファイルを介したコミュニケーションをも実現する。
【0040】
[実施形態3]
前記の実施形態1及び実施形態2では、各ユーザ端末3,4,…がサーバ2に接続する場合に認証手順(図2のステップS1〜T3,図3のステップS21〜T23)を経ており、サーバ2が特定のユーザ端末3,4,…にのみ共有コンテンツファイルに対するアクセス権を認めているが、共有コンテンツファイルを広く一般に公開する場合もあり得る。
そのような場合には、図4に示すように、サーバ2’に一般公開用ファイルを格納するためのHDD26を別途に設け、特定ユーザのファイルとは別に一般公開用ファイルを管理する。
そして、サーバ2’のデータ管理部22は、HDD24のユーザ管理情報を用いて特定ユーザのユーザ端末3,4,…からのアクセスか一般ユーザのユーザ端末5からのアクセスかを判断し、特定ユーザ用のファイルはHDD25に、一般公開用のファイルはHDD26にそれぞれ別に格納させるようにして独立に管理する。
尚、公開用の共有コンテンツファイルに関するエフェクトファイルの登録(更新)やユーザ端末からの閲覧等については、サーバ2’は一般ユーザのユーザ端末5からのアクセスに対しても特定ユーザのユーザ端末3,4,…の場合と同様の手順で応答する。
【0041】
ところで、一般公開用のファイルの場合には、その性質上、修復不能な加工や特殊なプログラムによる共通コンテンツファイルの消去等の予期しない操作が行われる可能性がある。
そこで、図4に示すように、この実施形態のサーバ2’にはバックアップ用のHDD27を設け、予めそのHDD27に元の共有コンテンツファイルのコピーを格納しておくと共に、一般ユーザのユーザ端末5から加工要求があってHDD26の共有コンテンツファイルの更新を行う際には、その直前のエフェクトファイルと更新情報をHDD27に格納させる。
尚、エフェクトファイルと更新情報をHDD27に格納する際には、既に格納されているエフェクトファイルと更新情報を書き換えてもよいが、この場合にはエフェクトファイルと更新情報の履歴を全て残すようにしてもよい。
後者の場合には、HDD27が記憶するデータ量が増大してゆくことになるが、差分をとって圧縮する方法や一定期間毎に古いデータを消去する方法によってデータ量の増大を抑制できる。
【0042】
[実施形態4]
前記の実施形態2で説明した共有コンテンツファイルの管理方法については、次のような拡張的方法を採用することも可能である。
(1) 実施形態2においては、ユーザ端末3からファイル取得要求がなされた場合に、サーバ2はエフェクトファイルを用いて加工処理した共有コンテンツファイルをユーザ端末3側へ送信するようにしている(図2:T29,S24〜S26,S28)。
しかし、一般には加工処理された共有コンテンツファイルは他のユーザ端末で更新されたものであるため、ユーザ端末3がそのファイルを再生するための十分な機能を備えていない場合もあり得る。
そのような場合には、ユーザ端末3がその再生機能での再生条件を予めサーバ2側へ通知しておき、サーバ2がその条件に適合するように加工処理後の共有コンテンツファイルを更に加工処理するようにすれば、ユーザ端末3側では自己の機能の制約を受けることなく全てのファイルを閲覧することができる。
尚、ユーザ端末3からの再生条件の通知は、サーバ2とユーザ端末3のリンク確立後からファイル送信前までの間に行えばよいが、ファイル取得要求(T29)の際に行うのが合理的である。
(2) 実施形態2では特定の1つの共有コンテンツファイルを監視対象としているが、サーバ2が複数の共有コンテンツファイルを管理している場合には、監視アプレット36によってそれらを一括して監視対象としてもよい。
(3) ユーザ端末3の監視アプレット36は、サーバ2側の共有コンテンツファイルの更新を検知するとサーバ2に対して更新情報の要求を行うが、ユーザ端末3が音声出力機能を有していれば、更新の検知と同時に音声による通知を行わせるようにしてもよい。また、ユーザ端末3がLED等を備えていれば、それを点滅させる等によって更新検知の通知を行わせることもできる。
尚、上記の各実施形態では画像データの共有コンテンツファイルについて説明したが、音楽やプログラム等の多種多様なコンテンツを扱うことが可能である。
【0043】
【発明の効果】
本発明の共有コンテンツファイルの更新管理方法は、以上の構成を有していることにより、次のような効果を奏する。
請求項1の発明は、更新される共有コンテンツファイルをサーバのメモリスペースを圧迫することなく保存することができ、また、ユーザ端末側が監視アプレットで能動的にサーバ側の共有コンテンツファイルの更新状態を監視して、詳細な更新情報を自動的に得ることを可能にする。
これにより、共有コンテンツファイルを介したユーザ端末同士のコミュニケーションをよりリアルタイムに近い円滑な手順で実現できる。
請求項2の発明は、サーバ側において、少ないデータ量で共有コンテンツファイルの更新を管理しながら、閲覧要求に対しては加工後の共有コンテンツファイルを再生して提供することを可能にする。
請求項3の発明は、ユーザ端末側でエフェクトファイルによる加工処理を他のコンテンツファイルに適用して加工処理の面白さを体験でき、エフェクトファイルを用いたコミュニケーションを実現する。
請求項4の発明は、直前に更新された共有コンテンツファイルの状態をバックアップさせることで、修復不能な加工やファイルの消失に対処することを可能にする。特に、共有コンテンツファイルを特定ユーザだけでなく、一般に公開する場合において有効である。
請求項5の発明は、更新された共有コンテンツファイルの属性等によってユーザ端末側で再生不能になるような場合に、サーバ側でユーザ端末に適合した加工処理を行うことにより、ユーザ端末側においてその機能上の制約を受けることなく共有コンテンツファイルを再生できるようにする。
【図面の簡単な説明】
【図1】本発明の実施形態に適用されるサーバとユーザ端末のブロック構成図と、それらがインターネットを介して接続されたネットワークを示す概略図である。
【図2】実施形態1に係る共有コンテンツファイルの加工手順を示す通信シーケンスフローチャートである。
【図3】実施形態2に係る監視アプレットによる共有コンテンツファイルの更新確認及びその閲覧等の手順を示す通信シーケンスフローチャートである。
【図4】実施形態3(共有コンテンツファイルを一般に公開する場合)に適用されるサーバとユーザ端末のブロック構成図と、それらがインターネットを介して接続されたネットワークを示す概略図である。
【符号の説明】
1…インターネット、2,2’…サーバ、3,4,5…ユーザ端末、21,31,41…通信制御部、22…データ管理部、23,32,42…データ処理部、24,25,26,27,35,45…ハードディスク装置(HDD)、33,43…入力操作部、34,44…表示部、36…監視アプレット。
【発明の属する技術分野】
本発明はネットワーク上の共有ファイル更新管理方法に係り、サーバ上に設けた共有コンテンツファイルを各ユーザ端末側から加工処理できるようにしてコミュニケーションの場を提供する場合に、共有コンテンツファイルの更新情報を各ユーザ端末側から確認でき、またサーバ側においても更新される共有コンテンツファイルを少ないデータ量で保存できる方法に関する。
【0002】
【従来の技術】
近年、パーソナルコンピュータに加えて電子メール・ブラウザ機能を備えた携帯電話等の各種端末の広範な普及により、電子メールの送受信、Webページの作成・閲覧、データのアップ・ダウンロード等のインターネットを介したコミュニケーションが多種多様な方式で行われるようになっている。
【0003】
電子メールによる通信では、電話通信のようにリアルタイムな相手の都合や時間を気遣うことなく送信先へ文字データを送信し、ネットワーク上のトラフィック等に問題がない限り、直ちに送信先の端末又はISP(Internet service Provider)のネットワークストレージに電子メールを届けることができる。
一方、送信先では任意の時間に電子メールを読めるため、送信元と送信先の双方が時間を問わずに文字データによるコミュニケーションが行える。
そして、多くの電子メールツールは添付ファイル機能も備えており、画像等のコンテンツファイルを添付して送信できることから、文字データだけでなく各種コンテンツによるコミュニケーションも可能であり、そのための支援システムについては下記の特許文献1〜3等のように各種の提案がなされている。
また、前記電子メール以外のインターネットを介したコミュニケーション方式としてチャットがある。
この方式は、インターネット上に設けた文字記入画面に対して複数の端末から文字が書き込まれて時系列的に追記更新されるものであり、これも文字によるリアルタイムなコミュニケーションの場を提供するものである。
【0004】
しかし、前記の電子メールによる通信は、基本的にはPeer−to−Peerの一方的な連絡手段であると共に、電子メールにファイルを添付して送信すると送信先にはそのファイルがコピーされ、特に、添付ファイルが画像データであるような場合には、送信先の端末のメモリスペースを圧迫してリソースの無駄遣いになることが少なくない。
また、前記のチャットは文字に限定されたコミュニケーションだけであり、リアルタイムにやり取りを行いたい場合には、各端末側でそのためのアプリケーションを立ち上げてログオンした後、チャットウィンドウを継続的に開いておかねばならない。
即ち、電子メールやチャットはインターネット上の最も一般的なコミュニケーションの方式であるが、前記のような問題点を含んでいる。
【0005】
一方、WWW(World Wide Web)では、Webサーバ上のWebページや画像・音声等のコンテンツファイルに複数の端末からアクセスでき、それらコンテンツの内容を見聞きすることができる。
また、Webページの中には、コンテンツファイルの提示だけでなく、任意の又は特定のユーザ端末から書き込みが行える“電子掲示板”を設けておき、文字による相互コミュニケーションの場を提供しているようなWebサイトもある。
そして、そのようなWebサイトを監視するユーザ端末側のアプリケーションソフトとしてWWWC(Webページの更新チェッカ)がある。
このWWWCは、予めユーザによって監視対象とするURL(Uniform Resource Locators)をユーザ端末に登録させておき、指示を与えることにより、又は指定した時刻や定期的な間隔で前記URLに接続してWebページを確認できるようにしたものである。
従って、WWWCを用いると、コンテンツファイルに記述された特定のメタデータやファイルサイズや更新時刻からコンテンツファイルの更新の有無を判断することが可能である。
尚、このようなシステムに関連したものとして、例えば、下記の特許文献4,5等のように各種の提案がなされている。
【0006】
【特許文献1】
特開2001−34547号公報
【特許文献2】
特開2001−211438号公報
【特許文献3】
特開2002−190833号公報
【特許文献4】
特開2002−140323号公報
【特許文献5】
特表2002−523842号公報
【0007】
【発明が解決しようとする課題】
【0008】
ところで、前記のWebサーバ上のWebページも、基本的にはコンテンツの作成者がその内容を多くのユーザに対して一方的に見聞きさせるものであって、そのコンテンツファイルの管理者以外の者にコンテンツファイル自体の変更を認めるものではない。
そして、WWWCのようにWebサーバ上のコンテンツファイルに関する更新チェッカは存在するが、通常はコンテンツファイルの変化を目視的に観察して更新の有無を確認できるに過ぎない。
即ち、コンテンツファイル内に前記の更新通知システムが解読可能なメタデータが記述されているような場合には、それから何等かの更新情報が得られることもあるが、メタデータはコンテンツファイルの作成者が自由に記述する任意情報であって、それを記述していないものも多数ある。
【0009】
一方、Webサーバ上に共有データファイルを置いて各ユーザ端末からそのファイルの閲覧及び変更を行えるようにした場合、ファイルのバージョン管理システム(例えば、CVSやRCS等)を利用すれば、ファイルの閲覧・変更に係る詳細な情報を通知することができる。
具体的には、前記のバージョン管理システムによれば、データファイル内に訂正・修正情報等を記述でき、指定したデータファイルの更新時にその更新通知を電子メールで指定した宛先に通知することが可能であると共に、データファイルの差分を別ファイルに保存しておいて後から各バージョンのデータファイルの差分を比較したり、個々のユーザが変更したデータファイルをマージすることも可能になる。
【0010】
しかし、共有データファイルの更新情報に関しては、前記のバージョン管理システムも電子メールで更新通知をユーザ端末へ送信するだけである。
そして、共有データファイルの更新がなされる度に一方的に送られてくる更新通知に対して、ユーザ端末側は自らが管理できない立場にあり、頻繁に更新がなされるデータファイルのような場合には電子メールの整理等が煩わしくなる。
また、データファイルの差分をとって管理できることは、プログラム言語や文書等のテキストで記述されたファイルについては有効であるが、画像ファイル等のバイナリデータの場合には、更新された変更部分のみを差分として保存できないことが多い。
即ち、画像ファイルの変更は全体に効果をかけたり色を変更したりして加工することが多いため、変更部分のみを差分として保存する方法は馴染まず、また、JPEG等の圧縮フォーマットの画像データは見た目上は画像の一部分に加工を施していてもデータ全体が変更されてしまうことも考えられるために変更のマージが極めて困難である。
更に、画像ファイル自体はフォーマットが決まっているため、ファイル中にメタデータを記述できるフォーマットの画像を用いるか、又は画像データ中にメタ情報を埋め込むための特殊なアプリケーションを利用しない限り、版の相違を画像ファイル内に記述することは難しい。
従って、データファイルが画像ファイル等のバイナリデータの場合には、結局、更新される度にそれ以前のデータと共に更新データを一括して新たに保存することになる。
その場合、例えば、最近のディジタルカメラ等で撮った画像等は一般に数百KB〜数MBのデータ量になり、更新の度に大きなデータ量のファイルができることになるため、サーバ上のメモリスペースを圧迫してゆくことになる。
【0011】
要約すると、Webサーバ上のコンテンツファイルや共有データファイルについて変更がなされた場合に、ユーザ端末側ではサーバ側の更新通知システムやバージョン管理システムによって更新の事実を確認できることになるが、それ以上の情報は得られず、また、画像ファイル等のバイナリデータについては、更新の度にサーバのメモリスペースが圧迫されるために、大容量の記憶装置を設けておかなければならないという問題がある。
【0012】
そこで、本発明は、サーバ上の共有コンテンツファイルを各ユーザ端末側から加工でき、サーバ側では加工後の共有コンテンツファイルを少ないデータ量で保存できると共に、各ユーザ端末側から更新情報を監視して更新後の加工情報や共有コンテンツファイル自体を所望のタイミングで閲覧できる共有コンテンツファイル更新管理方法を提供し、もって、ユーザ端末同士で共有コンテンツファイルを介したよりリアルタイムでフレキシブルなコミュニケーションを可能にすることを目的として創作された。
【0013】
【課題を解決するための手段】
本発明は、ネットワークを介してサーバと複数のユーザ端末とが配置され、前記サーバに対して前記ユーザ端末からアップロードされた共有コンテンツファイル又は前記サーバ側で作成した共有コンテンツファイルを前記サーバに登録せしめ、前記ユーザ端末から前記共有コンテンツファイルを閲覧・加工することが可能なネットワークシステムにおける共有コンテンツファイルの更新管理方法であって、前記サーバに登録されている前記共有コンテンツファイルに対して前記ユーザ端末側から加工要求がなされた場合に、前記サーバは、前記共有コンテンツファイルを加工することなく、前記ユーザ端末による個々の加工処理方法とその加工に必要なパラメータとからなるエフェクトオブジェクト及び前記加工処理の順序情報を記述したエフェクトファイルを作成する手順と、そのエフェクトファイルを少なくとも日時情報とそのエフェクトファイルから得られる加工情報とを含む更新情報と共に登録(但し、先の加工要求に係るエフェクトファイルと更新情報がある場合にはそれらを書き換えて登録)する手順とを実行し、一方、前記ユーザ端末は常時又は予め設定した時刻に前記サーバ側の共有コンテンツファイルの前記更新情報を監視する監視アプレットを備えており、前記ユーザ端末による前記サーバに登録されている前記共有コンテンツファイルの更新情報の確認に際しては、前記監視アプレットによる新規な更新の検知に基づいて、前記ユーザ端末が前記サーバに対して前記更新情報の閲覧要求を送信する手順と、前記サーバが前記閲覧要求に基づいて前記更新情報を前記ユーザ端末へ送信する手順と、
前記ユーザ端末側が前記サーバから受信した前記更新情報を表示手段で表示させる手順とによって行われることを特徴とする共有コンテンツファイルの更新管理方法に係る。
【0014】
本発明によれば、ユーザ端末から共有コンテンツファイルの加工要求があった場合に、サーバは共有コンテンツファイル自体には加工を施さずに、エフェクトファイルと更新情報だけを書き換えながら登録する。
従って、加工がなされる度にその共有コンテンツファイルを保存してゆく場合と比較して、保存データ量は遥かに少なくなり、サーバ側のメモリスペースが圧迫されることはない。
そして、この発明ではユーザ端末の監視アプレットが共有コンテンツファイルの更新情報を監視して更新の事実を検知するようになっており、従来のようにサーバ側から通知を受けるような受身の立場ではなく所望の時点でユーザ端末側から能動的に更新の有無を監視でき、更にその時点での更新情報を自動的に受信できる。
特に、更新情報には日時情報に加えてエフェクトファイルから得られた加工情報が含まれるため、共有コンテンツファイルにどのような加工が施されたかも確認できるという利点がある。
【0015】
また、本発明によれば、前記ユーザ端末による前記サーバに登録されている前記共有コンテンツファイルの閲覧については、前記ユーザ端末が前記サーバに対して前記共有コンテンツファイルの閲覧要求を送信する手順と、前記閲覧要求に基づいて、前記サーバが、前記エフェクトファイルを用いて前記共有コンテンツファイルを加工処理し、その加工処理後の共有コンテンツファイルを前記ユーザ端末側へ送信する手順とを実行させることによって行える。
即ち、少ないデータ量で共有コンテンツファイルの更新を管理しながら、閲覧要求に対しては加工後の共有コンテンツファイルを再生して提供できる。
【0016】
また、前記ユーザ端末が前記サーバに対して共有コンテンツファイルの閲覧要求又はエフェクトファイルのみの閲覧要求を選択的に行えるようにしておき、エフェクトファイルのみの閲覧要求がなされた場合に、前記サーバが前記エフェクトファイルだけを読み出して前記ユーザ端末へ送信するようにすれば、前記ユーザ端末は前記エフェクトファイルのみを得ることができる。
その場合、前記エフェクトファイルは共有コンテンツファイルに対する加工処理の内容を記述したものであるが、前記ユーザ端末側において他のコンテンツファイルに前記エフェクトファイルを作用させることでその加工処理の面白さを体験することができ、単に共有ファイルを介したコミュニケーションだけでなく、エフェクトファイルを用いたコミュニケーションも可能になる。
【0017】
また、前記サーバにおいて、前記共有コンテンツファイルをバックアップ用記憶手段に格納させておき、先の加工要求に係るエフェクトファイルと更新情報を今回の加工要求に係るエフェクトファイルと更新情報に書き換えて登録する場合に、先の加工要求に係るエフェクトファイルと更新情報を前記バックアップ用記憶手段に格納するようにしてもよい。
このバックアップによって、修復不能な加工処理や特殊なプログラムによる共通コンテンツファイルの消去等の予期しない操作が行われた場合にも直前の状態へ戻すことができる。
その場合、バックアップ用記憶手段に格納されるデータは、元の共有コンテンツファイルと直前の加工処理に係るエフェクトファイルと更新情報だけであり、通常の保存・登録用の記憶手段と同様に、バックアップ用記憶手段のメモリスペースが圧迫されることはない。
【0018】
また、前記ユーザ端末が閲覧要求に係る共有コンテンツファイルを受信した際に、前記ユーザ端末がその共有コンテンツファイルを再生するための十分な機能を備えていない場合には、前記ユーザ端末が前記サーバに対して再生可能な条件を通知し、前記サーバが前記加工処理後の共有コンテンツファイルを前記条件に対応させるように更に加工処理を施して前記ユーザ端末へ送信するようにすれば、共有コンテンツファイルの属性等によってそのままでは前記ユーザ端末で再生できないような場合にも、前記サーバ側が適応的に加工処理を行うことでその不都合を解消できる。
【0019】
【発明の実施の形態】
以下、本発明の「共有コンテンツファイルの更新管理方法」の実施形態を、図面を用いて詳細に説明する。
先ず、図1は、インターネット1を介してサーバ2とユーザ端末3,4が配置されており、サーバ2とユーザ端末3,4をブロック構成図として示した概略図である。但し、実際には多数のユーザ端末が接続されることになるが、図1では2つのユーザ端末3,4だけが接続されているネットワーク構成になっている。
この実施形態では、サーバ2側で作成した画像コンテンツファイル又は各ユーザ端末3,4,…で作成されてインターネット1を介してサーバ2側へアップロードされた画像コンテンツファイルを各ユーザ端末3,4,…の共有コンテンツファイルとし、サーバ2側がその共有コンテンツファイルを管理しながら、各ユーザ端末3,4,…に対して前記共有コンテンツファイルの加工・閲覧等を認めるネットワークシステムを例にとって説明する。
【0020】
ここで、サーバ2は、インターネット1との間で通信制御を実行する通信制御部21と、データの入出力やアクセス権等の管理を行うデータ管理部22と、共有コンテンツファイルに対して加工がなされた場合にはその加工に係るエフェクトファイルを作成し、共有コンテンツファイルの閲覧要求があった場合に前記エフェクトファイルを用いて加工後のコンテンツファイルを生成させるデータ処理部23と、アクセス権等に係るユーザ管理情報を格納したハードディスク装置(HDD)24と、共有コンテンツファイルやエフェクトファイル等を格納するHDD25とからなる。
一方、各ユーザ端末3,4は、それぞれ、インターネット1との間で通信制御を実行する通信制御部31,41と、データの処理や入出力等を制御するデータ処理部32,42と、キーボード等からなる操作入力部33,43と、表示部34,44と、HDD35,45を備えており、ユーザ端末3に関しては、更にインターネット1を介して常時又は定期的にサーバ2側の共有コンテンツファイルの更新状態を監視するための監視アプレット36を備えている。
尚、この実施形態ではユーザ端末3だけが監視アプレット36を有しているが、ユーザ端末4や他のユーザ端末が同様の監視アプレット36を備えていてもよい。
【0021】
[実施形態1]
この実施形態では、各ユーザ端末3,4,…からインターネット1を介してサーバ2が格納している共有コンテンツファイルを加工する場合の手順を、図2の通信シーケンスフローチャートを参照しながら説明する。
但し、ここではユーザ端末4から加工がなされる場合を例にとる。
先ず、前記のように、サーバ2のHDD25には各ユーザ端末3,4,…が共有する画像コンテンツファイルが格納されており、サーバ2の通信制御部21は各ユーザ端末3,4,…との通信の待ち受け状態にあり(S1)、ユーザ端末4の通信制御部41も通信可能状態にある。
【0022】
ここで、ユーザ端末4において、入力操作部43でサーバ2に対する認証要求のための操作を行うと、データ処理部42が通信制御部41を制御して認証要求信号をサーバ2側へ送信する(T1)。
サーバ2は、インターネット1を介して通信制御部21で認証要求信号を受信すると、データ管理部22が受信した認証要求信号のユーザ情報とHDD24のユーザ管理情報とを照合し、ユーザ端末4に対してその照合結果に基づいた認証応答を返送する(S2)。
そして、ユーザ端末4では、認証応答が許可応答であればリンクが確立して次の手順として共有コンテンツファイルの指定を行う操作へ移行するが(T2,T4)、認証応答が不許可応答である場合には再び認証要求操作を行って前記の手順を繰り返すことになる(T2,T3)。尚、再認証手順でもサーバ2側から許可応答が得られない場合には、サーバ2とのリンクが不能であり操作が終了する。
【0023】
許可応答を受信したユーザ端末4では、操作入力部43からサーバ2側の共有コンテンツファイルのファイル指定を行い、その指定情報をサーバ2側へ送信する(T4)。
一方、ファイル指定情報を受信したサーバ2は、データ管理部22がHDD25を検索し、指定された共有コンテンツファイルを開いてユーザ端末4側へ送信する(S3)。
尚、ここでは、共有コンテンツファイルが初めて加工される場合を例にとるが、既に各ユーザ端末3,4,…によってその共有コンテンツファイルに加工がなされている場合には、後述のエフェクトファイルを用いて共有コンテンツファイルを加工処理してユーザ端末4側へ送信することになる。
【0024】
ファイル指定に係る共有コンテンツファイルを受信したユーザ端末4では、データ処理部42がそのファイルをHDD45へセーブさせた後、そのコンテンツ画像を表示部44に表示させ、ユーザは共有コンテンツファイルの内容を確認する(T5)。
そして、表示画像を見ながら入力操作部43によってその画像の加工処理を施すと、データ処理部42がその加工に係る処理情報をサーバ2側へ送信させる(T6)。
【0025】
一方、加工処理情報を受信したサーバ2では、データ管理部22がデータ処理部23を起動させ、HDD25の前記指定に係る共有コンテンツファイルをデータ処理部23へ読み出し、データ処理部23によって加工処理情報を用いた共有コンテンツファイルの加工処理を実行させる(S4)。
その場合、データ処理部23では、受信した加工処理情報に基づいて読み出された共有コンテンツファイルを加工すると共に、その加工処理毎のエフェクトファイルを作成する(S4,S5)。
【0026】
このエフェクトファイルは加工処理内容を記述したファイルであるが、画像の鮮鋭化、ぼかし、増色/減色、エンボス加工、拡大/縮小等の個々の処理とその処理に関するパラメータを1つのエフェクトオブジェクトとして扱い、複数の処理が行われた場合にはその処理数分のエフェクトオブジェクトとその処理順序を記述したものである。
例えば、特許第2965119号公報では「画像処理を個別のオブジェクト(原画像の一部を変更して変更画像を作り出す仮想レンズオブジェクト)としてまとめ、それらの追加,削除,修正を行えるようにして画像処理のフレキシビリティを向上させた画像処理システム」の提案がなされているが、エフェクトオブジェクトとしては前記提案の仮想レンズオブジェクトも適用できる。
従って、エフェクトファイルはユーザ端末4から要求された加工処理プログラムモジュールとしての性質を有し、逆に、共有コンテンツファイルに対してエフェクトファイルを適用することにより加工後の変更された画像ファイルを再生することが可能である。
【0027】
また、データ処理部23は共有コンテンツファイルを加工した後の画像データに係るプレビューを作成し、データ管理部22がそのプレビューデータをユーザ端末4側へ送信させる(S6)。
一方、プレビューデータを受信したユーザ端末4では、それを表示部44に表示させてユーザがその加工後の画像でよいかどうかを確認する(T7)。
そして、ユーザはその加工画像の内容でよければ入力操作部45から保存要求を行うが(T7,T8)、その画像に納得できずに更に加工処理を行う必要があれば入力操作部45から追加の加工処理を行い、所望の加工画像が得られるまでステップT6からステップS6の手順を繰り返して実行する(T7→T6,S4〜S6→T7)。
【0028】
その場合、前記のようにデータ処理部23では加工処理毎のエフェクトファイルを作成しているため、複数の加工処理を施したときにも、そのファイル内のエフェクトオブジェクトの時系列を逆に辿ることによって任意の段階まで戻ることができ、また不要であると思われる個別のエフェクトオブジェクトを選択的に削除することもできる。
また、それらのエフェクトオブジェクトに対する操作過程は前記の繰り返し手順においてプレビューに反映され、ユーザ端末4のユーザはプレビューを見ながら効率良く加工処理を行ってゆくことができる。
【0029】
前記の加工処理において所望の加工画像のプレビューが得られると、ユーザは入力操作部43から保存要求を行い、ユーザ端末4からサーバ2へ保存要求信号が送信される(T8)。
そして、その信号を受信したサーバ2では、データ管理部22によって、データ処理部23が作成した前記エフェクトファイルとその作成に係る日時情報と前記エフェクトファイルから得られる加工情報をHDD25の前記共有コンテンツファイルに対応するアドレス領域に保存・登録させる(S7)。
但し、ここでの「加工情報」とは加工内容を示す要目(例えば、鮮鋭化、ぼかし、増色/減色、サイズ変更等)だけであり、その処理の詳細はエフェクトファイルに記述されている。
また、以下、前記の加工情報と日時情報とを「更新情報」と言うこととする。
尚、この場合は、共有コンテンツファイルに対するユーザ端末4からの加工処理要求が最初の処理であるために、エフェクトファイルと更新情報をそのまま保存・登録させるようにしているが、既に各ユーザ端末3,4,…から共有コンテンツファイルに対する加工処理がなされており、HDD25にエフェクトファイルと更新情報が存在している場合には、それらのファイルを更新する態様で保存・登録がなされる。
【0030】
ところで、サーバ2では、前記の加工処理の過程においてHDD25の共有コンテンツファイルをデータ処理部23に読み出して処理を施しているだけであり、HDD25の共有コンテンツファイルは元のままの格納状態にある。
即ち、サーバ2では元の共有コンテンツファイルはそのままにしてエフェクトファイルと更新情報のみを保存・登録させ、また既に前回の加工処理に係るエフェクトファイルと更新情報が存在する場合にはそれを更新する態様で保存・登録させている。
従って、HDD25の共有コンテンツファイルとエフェクトファイル等の格納領域は加工処理内容によるエフェクトファイルのデータ量の変動があるだけであり、共有コンテンツファイルに対する加工処理がなされる度にデータ量が増大するようなことはない。
【0031】
このようにしてエフェクトファイルと更新情報の保存・登録がなされると、サーバ2ではデータ管理部22がエフェクトファイルの登録通知(既存のエフェクトファイル等が存在した場合には更新通知)を作成してユーザ端末4側へ送信する(S8)。
また、その保存(更新)通知を受信したユーザ端末4では、その通知を得ることで共有コンテンツファイルの更新が正常になされたことを確認する(T9)。
この場合、ユーザ端末4側からみると、見かけ上、共有コンテンツファイルが更新されたことになるが、サーバ2側では、前記のように共有コンテンツファイル自体には加工を施しておらず、エフェクトファイルと更新情報を保存(更新)しているだけである。
【0032】
[実施形態2]
この実施形態では、各ユーザ端末3,4,…の内でユーザ端末3のように監視アプレット36を備えた端末からインターネット1を介してサーバ2が格納している共有コンテンツファイルの更新情報を確認し、更に共有コンテンツファイルの閲覧やエフェクトファイルのみを得て利用する場合について説明する。
以下、その手順を図3の通信シーケンスフローチャートを参照しながら説明する。
先ず、サーバ2の通信制御部21は各ユーザ端末3,4,…との通信の待ち受け状態にあり、またユーザ端末3の通信制御部31も通信可能状態にあって、ユーザ端末3側からの認証要求に対してサーバ2側が認証応答を行うことでリンクを確立させることは、前記の実施形態1においてサーバ2とユーザ端末4による通信手順と同様である(S21,T21,S22,T22,T23)。
従って、この実施形態ではその手順についての説明は省略する。
【0033】
サーバ2とユーザ端末3の間でリンクが確立すると、ユーザ端末3では直ちに監視アプレット36を起動させ、サーバ2側のエフェクトファイルの更新状態を監視する(T24)。
この監視動作は、リンクが確立されている状態でサーバ2に対するアクセスを繰り返して常時監視するようにしてもよいし、また、入力操作部33から予め所望の時刻や定期的な時刻を設定しておいて、その時刻になると監視アプレット36がサーバ2をアクセスして監視するようにしてもよい。
【0034】
その場合の監視シーケンスは次のような手順で実行される。
先ず、サーバ2は各ユーザ端末3,4,…に対して最新の更新情報(エフェクトファイルが作成された日時情報及びエフェクトファイルから得られる加工情報)を公開しており、ユーザ端末3の監視アプレット36は前回の監視時に得られた更新情報を保存し、アクセス時に前回の更新情報と最新の更新情報とを比較して異なっていれば共有コンテンツファイルが更新されたと検知する。
従って、ユーザ端末3ではサーバ2側の共有コンテンツファイルが更新されたか否かを前記の監視時刻に直ちに検知することができる。
即ち、この実施形態では、ユーザ端末3がサーバ2側から更新通知を受けるのではなく、ユーザがリアルタイムに又は所望時刻に更新の有無を検知できる。
【0035】
そして、ユーザ端末3の監視アプレット36は、前記の手順で更新されたことを検知すると、直ちにサーバ2に対して更新情報の要求を行い、その要求を受けたサーバ2では、直ちにHDD25から更新情報を読み出してユーザ端末3側へ送信する(T25,T26,S23)。
更新情報を受信したユーザ端末3では取得した更新情報をHDD35にセーブし、それを表示部34に読み出して表示させることによりユーザの閲覧に供する(T27)。
この場合、実施形態1で説明したように、更新情報には日時情報と共にエフェクトファイルから得られた加工情報が含まれているため、例えば、鮮鋭化やぼかしや増色/減色等の処理内容の要目も表示させることができ、ユーザは共有コンテンツファイルに対して直前になされた加工処理の内容も確認することができる。
【0036】
ユーザ端末3のユーザは、前記の更新情報を閲覧して更新後の共有コンテンツファイルやエフェクトファイルを見たい場合には、入力操作部33からファイル取得要求を行う(T28,T29)。
この場合の要求は、共有コンテンツファイル自体の閲覧要求とエフェクトファイルの取得要求を入力操作部33で選択的に行うことができ、ユーザ端末3のデータ処理部32はその選択に応じた要求信号をサーバ2側へ送信させる。
【0037】
前記の要求信号を受信したサーバ2では、データ管理部22が何れの要求かを判断し、共有コンテンツファイル自体の閲覧要求であった場合には、HDD25から共有コンテンツファイルとエフェクトファイルをデータ処理部23へ転送し、データ処理部23でエフェクトファイルを用いて共有コンテンツファイルに加工処理を施すことにより直前に更新されたコンテンツファイルを再生する(S24,S25,S26)。
一方、エフェクトファイルの取得要求であった場合には、HDD25からエフェクトファイルのみを読み出す(S27)。
そして、データ管理部22は加工処理後のコンテンツファイル又はエフェクトファイルを通信制御部21へ転送し、ユーザ端末3側へ送信させる(S28)。
【0038】
ユーザ端末3では、前記ファイルを受信するとデータ処理部32がそのファイルをHDD35に格納し、コンテンツファイルの場合にはそれを表示部34へ転送して表示させる(T30,T31)。
従って、ユーザは現時点での更新されたコンテンツファイルの画像を見ることができる。
【0039】
一方、エフェクトファイルだけを取得した場合には、元の共有コンテンツファイルが無いために更新されたコンテンツファイルを再生することはできない。
しかし、エフェクトファイルは画像データに対する加工処理プログラムモジュールとしての性質を有しており、共有コンテンツファイルだけでなく、他の画像ファイルに対しても使用できる(T31)。
従って、例えば、ユーザ端末3のHDD35にユーザが作成した画像ファイルをHDD35に用意しておき、その画像ファイルに対して前記のエフェクトファイルを適用して加工処理を行い、エフェクトファイルに記述されている処理方法の面白さ等を独自に楽しむことが可能になる。
即ち、この実施形態によれば、共有コンテンツファイルの更新をエフェクトファイルの保存形式で行っていることにより、共有コンテンツファイルを介したコミュニケーションだけでなく、エフェクトファイルを介したコミュニケーションをも実現する。
【0040】
[実施形態3]
前記の実施形態1及び実施形態2では、各ユーザ端末3,4,…がサーバ2に接続する場合に認証手順(図2のステップS1〜T3,図3のステップS21〜T23)を経ており、サーバ2が特定のユーザ端末3,4,…にのみ共有コンテンツファイルに対するアクセス権を認めているが、共有コンテンツファイルを広く一般に公開する場合もあり得る。
そのような場合には、図4に示すように、サーバ2’に一般公開用ファイルを格納するためのHDD26を別途に設け、特定ユーザのファイルとは別に一般公開用ファイルを管理する。
そして、サーバ2’のデータ管理部22は、HDD24のユーザ管理情報を用いて特定ユーザのユーザ端末3,4,…からのアクセスか一般ユーザのユーザ端末5からのアクセスかを判断し、特定ユーザ用のファイルはHDD25に、一般公開用のファイルはHDD26にそれぞれ別に格納させるようにして独立に管理する。
尚、公開用の共有コンテンツファイルに関するエフェクトファイルの登録(更新)やユーザ端末からの閲覧等については、サーバ2’は一般ユーザのユーザ端末5からのアクセスに対しても特定ユーザのユーザ端末3,4,…の場合と同様の手順で応答する。
【0041】
ところで、一般公開用のファイルの場合には、その性質上、修復不能な加工や特殊なプログラムによる共通コンテンツファイルの消去等の予期しない操作が行われる可能性がある。
そこで、図4に示すように、この実施形態のサーバ2’にはバックアップ用のHDD27を設け、予めそのHDD27に元の共有コンテンツファイルのコピーを格納しておくと共に、一般ユーザのユーザ端末5から加工要求があってHDD26の共有コンテンツファイルの更新を行う際には、その直前のエフェクトファイルと更新情報をHDD27に格納させる。
尚、エフェクトファイルと更新情報をHDD27に格納する際には、既に格納されているエフェクトファイルと更新情報を書き換えてもよいが、この場合にはエフェクトファイルと更新情報の履歴を全て残すようにしてもよい。
後者の場合には、HDD27が記憶するデータ量が増大してゆくことになるが、差分をとって圧縮する方法や一定期間毎に古いデータを消去する方法によってデータ量の増大を抑制できる。
【0042】
[実施形態4]
前記の実施形態2で説明した共有コンテンツファイルの管理方法については、次のような拡張的方法を採用することも可能である。
(1) 実施形態2においては、ユーザ端末3からファイル取得要求がなされた場合に、サーバ2はエフェクトファイルを用いて加工処理した共有コンテンツファイルをユーザ端末3側へ送信するようにしている(図2:T29,S24〜S26,S28)。
しかし、一般には加工処理された共有コンテンツファイルは他のユーザ端末で更新されたものであるため、ユーザ端末3がそのファイルを再生するための十分な機能を備えていない場合もあり得る。
そのような場合には、ユーザ端末3がその再生機能での再生条件を予めサーバ2側へ通知しておき、サーバ2がその条件に適合するように加工処理後の共有コンテンツファイルを更に加工処理するようにすれば、ユーザ端末3側では自己の機能の制約を受けることなく全てのファイルを閲覧することができる。
尚、ユーザ端末3からの再生条件の通知は、サーバ2とユーザ端末3のリンク確立後からファイル送信前までの間に行えばよいが、ファイル取得要求(T29)の際に行うのが合理的である。
(2) 実施形態2では特定の1つの共有コンテンツファイルを監視対象としているが、サーバ2が複数の共有コンテンツファイルを管理している場合には、監視アプレット36によってそれらを一括して監視対象としてもよい。
(3) ユーザ端末3の監視アプレット36は、サーバ2側の共有コンテンツファイルの更新を検知するとサーバ2に対して更新情報の要求を行うが、ユーザ端末3が音声出力機能を有していれば、更新の検知と同時に音声による通知を行わせるようにしてもよい。また、ユーザ端末3がLED等を備えていれば、それを点滅させる等によって更新検知の通知を行わせることもできる。
尚、上記の各実施形態では画像データの共有コンテンツファイルについて説明したが、音楽やプログラム等の多種多様なコンテンツを扱うことが可能である。
【0043】
【発明の効果】
本発明の共有コンテンツファイルの更新管理方法は、以上の構成を有していることにより、次のような効果を奏する。
請求項1の発明は、更新される共有コンテンツファイルをサーバのメモリスペースを圧迫することなく保存することができ、また、ユーザ端末側が監視アプレットで能動的にサーバ側の共有コンテンツファイルの更新状態を監視して、詳細な更新情報を自動的に得ることを可能にする。
これにより、共有コンテンツファイルを介したユーザ端末同士のコミュニケーションをよりリアルタイムに近い円滑な手順で実現できる。
請求項2の発明は、サーバ側において、少ないデータ量で共有コンテンツファイルの更新を管理しながら、閲覧要求に対しては加工後の共有コンテンツファイルを再生して提供することを可能にする。
請求項3の発明は、ユーザ端末側でエフェクトファイルによる加工処理を他のコンテンツファイルに適用して加工処理の面白さを体験でき、エフェクトファイルを用いたコミュニケーションを実現する。
請求項4の発明は、直前に更新された共有コンテンツファイルの状態をバックアップさせることで、修復不能な加工やファイルの消失に対処することを可能にする。特に、共有コンテンツファイルを特定ユーザだけでなく、一般に公開する場合において有効である。
請求項5の発明は、更新された共有コンテンツファイルの属性等によってユーザ端末側で再生不能になるような場合に、サーバ側でユーザ端末に適合した加工処理を行うことにより、ユーザ端末側においてその機能上の制約を受けることなく共有コンテンツファイルを再生できるようにする。
【図面の簡単な説明】
【図1】本発明の実施形態に適用されるサーバとユーザ端末のブロック構成図と、それらがインターネットを介して接続されたネットワークを示す概略図である。
【図2】実施形態1に係る共有コンテンツファイルの加工手順を示す通信シーケンスフローチャートである。
【図3】実施形態2に係る監視アプレットによる共有コンテンツファイルの更新確認及びその閲覧等の手順を示す通信シーケンスフローチャートである。
【図4】実施形態3(共有コンテンツファイルを一般に公開する場合)に適用されるサーバとユーザ端末のブロック構成図と、それらがインターネットを介して接続されたネットワークを示す概略図である。
【符号の説明】
1…インターネット、2,2’…サーバ、3,4,5…ユーザ端末、21,31,41…通信制御部、22…データ管理部、23,32,42…データ処理部、24,25,26,27,35,45…ハードディスク装置(HDD)、33,43…入力操作部、34,44…表示部、36…監視アプレット。
Claims (5)
- ネットワークを介してサーバと複数のユーザ端末とが配置され、前記サーバに対して前記ユーザ端末からアップロードされた共有コンテンツファイル又は前記サーバ側で作成した共有コンテンツファイルを前記サーバに登録せしめ、前記ユーザ端末から前記共有コンテンツファイルを閲覧・加工することが可能なネットワークシステムにおける共有コンテンツファイルの更新管理方法であって、
前記サーバに登録されている前記共有コンテンツファイルに対して前記ユーザ端末側から加工要求がなされた場合に、
前記サーバは、前記共有コンテンツファイルを加工することなく、前記ユーザ端末による個々の加工処理方法とその加工に必要なパラメータとからなるエフェクトオブジェクト及び前記加工処理の順序情報を記述したエフェクトファイルを作成する手順と、そのエフェクトファイルを少なくとも日時情報とそのエフェクトファイルから得られる加工情報とを含む更新情報と共に登録(但し、先の加工要求に係るエフェクトファイルと更新情報がある場合にはそれらを書き換えて登録)する手順とを実行し、
一方、前記ユーザ端末は常時又は予め設定した時刻に前記サーバ側の共有コンテンツファイルの前記更新情報を監視する監視アプレットを備えており、
前記ユーザ端末による前記サーバに登録されている前記共有コンテンツファイルの更新情報の確認に際しては、
前記監視アプレットによる新規な更新の検知に基づいて、前記ユーザ端末が前記サーバに対して前記更新情報の閲覧要求を送信する手順と、
前記サーバが前記閲覧要求に基づいて前記更新情報を前記ユーザ端末へ送信する手順と、
前記ユーザ端末側が前記サーバから受信した前記更新情報を表示手段で表示させる手順と
によって行われることを特徴とする共有コンテンツファイルの更新管理方法。 - 前記ユーザ端末による前記サーバに登録されている前記共有コンテンツファイルの閲覧に際しては、
前記ユーザ端末が前記サーバに対して前記共有コンテンツファイルの閲覧要求を送信する手順と、
前記閲覧要求に基づいて、前記サーバが、前記エフェクトファイルを用いて前記共有コンテンツファイルを加工処理し、その加工処理後の共有コンテンツファイルを前記ユーザ端末側へ送信する手順と
によって行われることとした請求項1に記載の共有コンテンツファイルの更新管理方法。 - 前記ユーザ端末が前記サーバに対して共有コンテンツファイルの閲覧要求又はエフェクトファイルのみの閲覧要求を選択的に行うことができ、エフェクトファイルのみの閲覧要求があった場合に、前記サーバは前記エフェクトファイルだけを読み出して前記ユーザ端末へ送信することとした請求項1又は請求項2に記載の共有コンテンツファイルの更新管理方法。
- 前記サーバは前記共有コンテンツファイルをバックアップ用記憶手段に格納させておき、先の加工要求に係るエフェクトファイルと更新情報を今回の加工要求に係るエフェクトファイルと更新情報に書き換えて登録する場合に、先の加工要求に係るエフェクトファイルと更新情報を前記バックアップ用記憶手段に格納することとした請求項1、請求項2又は請求項3に記載の共有コンテンツファイルの更新管理方法。
- 前記ユーザ端末が閲覧要求に係る加工処理後の共有コンテンツファイルを受信した際に、前記ユーザ端末がその共有コンテンツファイルを再生するための十分な機能を備えていない場合には、前記ユーザ端末が前記サーバに対して再生可能な条件を通知し、前記サーバが前記加工処理後の共有コンテンツファイルを前記条件に対応させるように更に加工処理を施して前記ユーザ端末へ送信することとした請求項1、請求項2、請求項3、又は請求項4に記載の共有コンテンツファイルの更新管理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003103358A JP2004310464A (ja) | 2003-04-07 | 2003-04-07 | 共有コンテンツファイルの更新管理方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003103358A JP2004310464A (ja) | 2003-04-07 | 2003-04-07 | 共有コンテンツファイルの更新管理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004310464A true JP2004310464A (ja) | 2004-11-04 |
Family
ID=33466521
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003103358A Pending JP2004310464A (ja) | 2003-04-07 | 2003-04-07 | 共有コンテンツファイルの更新管理方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004310464A (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1973303A1 (en) | 2007-03-23 | 2008-09-24 | Sony Corporation | Music file editing system |
US8176118B2 (en) | 2007-11-07 | 2012-05-08 | Sony Corporation | Server device, client device, information processing system, information processing method, and program |
US8386925B2 (en) | 2007-10-22 | 2013-02-26 | Sony Corporation | Information processing terminal device, information processing device, information processing method, and program |
US8438197B2 (en) | 2007-03-23 | 2013-05-07 | Sony Corporation | System, apparatus, method and program for processing information |
KR20150086573A (ko) * | 2014-01-17 | 2015-07-29 | 에스케이플래닛 주식회사 | 컨텐츠 제공 장치 및 컨텐츠 제공 장치의 컨텐츠 공유 방법 |
-
2003
- 2003-04-07 JP JP2003103358A patent/JP2004310464A/ja active Pending
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8959174B2 (en) | 2007-03-23 | 2015-02-17 | Sony Corporation | System, apparatus, method and program for processing information |
US8112474B2 (en) | 2007-03-23 | 2012-02-07 | Sony Corporation | System, apparatus, and program for distributing incidental content |
US10027730B2 (en) | 2007-03-23 | 2018-07-17 | Sony Corporation | System, apparatus, method and program for processing information |
EP1973303A1 (en) | 2007-03-23 | 2008-09-24 | Sony Corporation | Music file editing system |
US8438197B2 (en) | 2007-03-23 | 2013-05-07 | Sony Corporation | System, apparatus, method and program for processing information |
US9813471B2 (en) | 2007-03-23 | 2017-11-07 | Sony Corporation | System, apparatus, method and program for processing information |
US8386925B2 (en) | 2007-10-22 | 2013-02-26 | Sony Corporation | Information processing terminal device, information processing device, information processing method, and program |
US9213724B2 (en) | 2007-10-22 | 2015-12-15 | Sony Corporation | Information processing terminal device, information processing device, information processing method, and program |
US9319487B2 (en) | 2007-11-07 | 2016-04-19 | Sony Corporation | Server device, client device, information processing system, information processing method, and program |
US8862781B2 (en) | 2007-11-07 | 2014-10-14 | Sony Corporation | Server device, client device, information processing system, information processing method, and program |
US8176118B2 (en) | 2007-11-07 | 2012-05-08 | Sony Corporation | Server device, client device, information processing system, information processing method, and program |
KR20150086573A (ko) * | 2014-01-17 | 2015-07-29 | 에스케이플래닛 주식회사 | 컨텐츠 제공 장치 및 컨텐츠 제공 장치의 컨텐츠 공유 방법 |
KR102227503B1 (ko) * | 2014-01-17 | 2021-03-15 | 에스케이플래닛 주식회사 | 컨텐츠 제공 장치 및 컨텐츠 제공 장치의 컨텐츠 공유 방법 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6186870B2 (ja) | 情報処理装置、プログラム、会議システム及びコンテンツ提供方法 | |
JP4859549B2 (ja) | 管理用シンボルを用いた情報管理方法、及び情報管理サーバ | |
US20140122591A1 (en) | Content sharing with limited cloud storage | |
JP6298197B2 (ja) | 対応するプライマリ・アプリケーションデータから導出される識別子に基づく補足データへのアクセス | |
JP2007172044A (ja) | 画面表示方法及び画面表示装置 | |
JP2012009085A (ja) | コンテンツの同期/追跡のための方法及び装置 | |
CN105302832A (zh) | 文件管理方法及装置 | |
JP2003204581A (ja) | 移動通信端末、ネットワーク装置、移動通信システム、情報送受信方法、情報送受信プログラム | |
JP2007184920A (ja) | 携帯端末機の画像管理装置及び方法 | |
CN109565606A (zh) | 混合源架构中的图像变换 | |
JP2004310464A (ja) | 共有コンテンツファイルの更新管理方法 | |
JP4241200B2 (ja) | データ共有システム及び方法並びにデータ共有用プログラム | |
KR101075023B1 (ko) | 연결문서를 이용한 문서의 히스토리관리 방법 및 이를 이용한 시스템 | |
CN116737302A (zh) | 聊天窗口显示方法、装置及电子设备 | |
JP2009048393A (ja) | 電子機器、およびコンテンツ共有システム | |
JP2005258855A (ja) | 通信履歴監視システム、及び、情報交換方法 | |
JP2006243981A (ja) | 文書管理プログラム、文書管理方法及び文書管理装置 | |
JP2005321922A (ja) | 情報共有システムおよび情報共有用プログラム | |
JP2010191706A (ja) | Webシステムにおける分散処理方法およびwebシステムにおける分散処理システム | |
JP4571400B2 (ja) | 文書ファイル、記録媒体、文書ファイル転送方法および情報処理装置 | |
JP2004102871A (ja) | 共有コンテンツ更新システム及びユーザ端末装置 | |
JP2007128179A (ja) | 情報処理装置及びその制御方法、プログラム及び記憶媒体 | |
JP2009211601A (ja) | ネットワーク配信型文書閲覧システム、文書配信サーバ、文書配信方法および文書配信プログラム | |
JP2010205201A (ja) | ネットワーク端末装置及びプログラム | |
JP6878976B2 (ja) | 情報処理装置、情報処理システム、管理方法及びプログラム |