JP7218164B2 - 通信装置およびその制御方法 - Google Patents

Description

本発明は、通信装置が保持するコンテンツに関する情報を他の機器に通信する技術に関する。

近年、パーソナルコンピュータ、デジタルカメラ、ゲーム機、タブレット端末、携帯電話機など、多くの電子機器に通信機能が搭載され、電子機器間でデータ送受信が実現されている。例えば、特許文献１には、データ転送プロトコルのコマンドを用いて、データ転送装置であるコンピュータが転送先であるデジタルカメラにコンテンツデータを送信することが開示されている。

また、特許文献２には、コンテンツデータの管理装置として機能するデジタルカメラが、管理するコンテンツに新たにコンテンツが追加されてディレクトリを作成した場合、ディレクトリの構成に変更があったことを他の電子機器に通知することが開示されている。

特開２００８－２５０８２０号公報 特開２０１１－０４９９８１号公報

コンテンツデータを保持する電子機器（送信機器）において、データの追加、削除などにより保持するコンテンツデータに変化が生じ、その変化を他の電子機器（受信機器）に通知する場合、次の手順で通知することが考えられている。

まず、送信機器がコンテンツデータの変化情報を生成して保持する。次に、送信機器が受信機器からコンテンツデータの変化情報の取得要求を受信する。そして、送信機器が取得要求に応じて受信機器にコンテンツデータの変化情報を送信する。

しかし、この手順では、送信機器が保持するコンテンツデータにおいて変化が多く生じた場合、送信機器は大量の変化情報を保持しなければならない。また、受信機器から変化情報の取得要求を受信するまで、送信機器はその大量の変化情報を保持し続ける必要があり、送信機器の処理能力によっては全ての変化情報を保持できない可能性がある。

また、送信機器が保持するコンテンツデータに変化が多い場合、送信機器から受信機器に送信される変化情報のデータ量も多くなる。その結果、変化情報の送信に要する通信時間が長くなり、通信プロトコルによっては通信タイムアウトとなって、全ての変化情報を送信できない可能性もある。

ここで、特許文献２のように、コンテンツデータが追加されて新たにディレクトリが生成された場合、そのコンテンツデータが属するディレクトリを通知することで、個々のコンテンツデータの変化情報を通知するよりも、少ないデータ量で通知することが考えられる。しかし、この場合、受信機器は、送信機器で変化が生じたコンテンツデータの詳細を得ることができないという問題がある。

そこで、本発明は、送信機器が保持するコンテンツデータに変化があった場合、その変化を示す変化情報を、コンテンツデータのファイル単位で作成して受信機器に通信するモードとコンテンツデータが属するディレクトリ単位で作成して受信機器に通信するモードの何れかに従って生成するように、状況に応じて制御することによって、コンテンツデータの変化の内容を効率的に通知することを可能にするものである。

通信装置は、外部装置と通信する通信装置であって、前記通信装置が保持するコンテンツに変化が生じると変化の内容に相当する変化情報を生成する生成手段と、変化の生じたコンテンツのファイル単位で前記変化情報を生成する第１モードと、変化の生じたコンテンツが属するディレクトリ単位で前記変化情報を生成する第２モードとの何れかのモードに従って動作するように前記生成手段を制御する制御手段と、前記変化情報を前記外部装置からの要求に応じて送信する通信手段と、を備え、変化の内容がコンテンツの追加の場合は前記第１モードで動作し、変化の内容がコンテンツの削除の場合は前記第２モードで動作するように前記生成手段を制御する、ことを特徴とする。

本発明によれば、電子機器が保持するコンテンツデータに変化があった場合、コンテンツデータの変化の内容を他の電子機器に効率的に通知することができる。

本発明の実施形態におけるデジタルカメラの構成を示すブロック図である。 本発明の実施形態におけるスマートフォンの構成を示すブロック図である。 本発明の実施形態における送信機器が使用するＡＰＩの例を示す図である。 本発明の実施形態における送信機器内のコンテンツ管理構成の例を示す図である。 本発明の実施形態における送信機器内のコンテンツ変化情報の保持手順の例を示す図である。 本発明の実施形態における送信機器の動作を説明するためのフローチャートである。 本発明の実施形態における受信機器の動作を説明するためのフローチャートである。

以下に、本発明の実施形態について、添付の図面を用いて詳細に説明する。

なお、以下に説明する実施形態は、本発明の実現手段としての一例であり、本発明が適用される装置の構成や各種条件によって適宜修正又は変更されてもよい。

図１は、本実施形態の通信装置の一例であるデジタルカメラ１００の構成例を示すブロック図である。ここでは、通信装置の一例としてデジタルカメラについて述べるが、通信装置はこれに限られない。例えば、通信装置は、携帯型のメディアプレーヤや、いわゆるタブレットデバイス、パーソナルコンピュータなどの情報処理装置であってもよい。

制御部１０１は、入力された信号や、後述のプログラムに従ってデジタルカメラ１００の各部を制御する。なお、制御部１０１が装置全体を制御する代わりに、複数のハードウェアが処理を分担することで、装置全体を制御してもよい。

撮像部１０２は、例えば、光学レンズユニットと絞り・ズーム・フォーカスなど制御する光学系と、光学レンズユニットを経て導入された光（映像）を電気的な映像信号に変換するための撮像素子などで構成される。撮像素子としては、一般的には、ＣＭＯＳ（Ｃｏｍｐｌｅｍｅｎｔａｒｙ Ｍｅｔａｌ Ｏｘｉｄｅ Ｓｅｍｉｃｏｎｄｕｃｔｏｒ）や、ＣＣＤ（Ｃｈａｒｇｅ Ｃｏｕｐｌｅｄ Ｄｅｖｉｃｅ）が利用される。撮像部１０２は、制御部１０１に制御されることにより、撮像部１０２に含まれるレンズで結像された被写体光を、撮像素子により電気信号に変換し、ノイズ低減処理などを行いデジタルデータを画像データとして出力する。本実施形態のデジタルカメラ１００では、画像データは、ＤＣＦ（Ｄｅｓｉｇｎ Ｒｕｌｅ ｆｏｒ Ｃａｍｅｒａ Ｆｉｌｅ ｓｙｓｔｅｍ）の規格に従って、記録媒体１１０に記録される。

不揮発性メモリ１０３は、電気的に消去・記録可能な不揮発性のメモリであり、制御部１０１で実行される後述のプログラム等が格納される。

作業用メモリ１０４は、撮像部１０２で撮像された画像データを一時的に保持するバッファメモリや、表示部１０６の画像表示用メモリ、制御部１０１の作業領域等として使用される。

操作部１０５は、ユーザがデジタルカメラ１００に対する指示をユーザから受け付けるために用いられる。操作部１０５は例えば、ユーザがデジタルカメラ１００の電源のＯＮ／ＯＦＦを指示するための電源ボタンや、撮影を指示するためのレリーズスイッチ、画像データの再生を指示するための再生ボタンを含む。さらに、後述の接続部１１１を介して外部機器との通信を開始するための専用の接続ボタンなどの操作部材を含む。また、後述する表示部１０６に形成されるタッチパネルも操作部１０５に含まれる。

なお、レリーズスイッチは、ＳＷ１およびＳＷ２を有する。レリーズスイッチが、いわゆる半押し状態となることにより、ＳＷ１がＯＮとなる。これにより、ＡＦ（オートフォーカス）処理、ＡＥ（自動露出）処理、ＡＷＢ（オートホワイトバランス）処理、ＥＦ（フラッシュプリ発光）処理等の撮影準備を行うための指示を受け付ける。また、レリーズスイッチが、いわゆる全押し状態となることにより、ＳＷ２がＯＮとなる。これにより、撮影を行うための指示を受け付ける。

表示部１０６は、撮影の際のビューファインダー画像の表示、撮影した画像データの表示、対話的な操作のための文字表示などを行う。なお、表示部１０６は必ずしもデジタルカメラ１００が内蔵する必要はない。デジタルカメラ１００は内部又は外部の表示部１０６と接続することができ、表示部１０６の表示を制御する表示制御機能を少なくとも有していればよい。

記録媒体１１０は、撮像部１０２から出力された画像データを記録することができる。記録媒体１１０は、デジタルカメラ１００に着脱可能なよう構成してもよいし、デジタルカメラ１００に内蔵されていてもよい。すなわち、デジタルカメラ１００は少なくとも記録媒体１１０にアクセスする手段を有していればよい。

接続部１１１は、外部装置と接続するためのインターフェースである。本実施形態のデジタルカメラ１００は、接続部１１１を介して、外部装置とデータのやりとりを行うことができる。例えば、撮像部１０２で生成した画像データを、接続部１１１を介して外部装置に送信することができる。なお、本実施形態では、接続部１１１は外部装置とＩＥＥＥ８０２．１１の規格に従った、いわゆる無線ＬＡＮで通信するためのインターフェースを含む。制御部１０１は、接続部１１１を制御することで外部装置との無線通信を実現する。なお、通信方式は無線ＬＡＮに限定されるものではなく、例えば赤外通信方式も含む。接続部１１１は第１の無線通信手段の一例である。

近距離無線通信部１１２は、例えば無線通信のためのアンテナと無線信号を処理するため変復調回路や通信コントローラから構成される。近距離無線通信部１１２は、変調した無線信号をアンテナから出力し、またアンテナで受信した無線信号を復調することによりＩＥＥＥ８０２．１５の規格（いわゆるＢｌｕｅｔｏｏｔｈ（登録商標））に従った近距離無線通信を実現する。

本実施形態においてＢｌｕｅｔｏｏｔｈ（登録商標）通信は、低消費電力であるＢｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙのバージョン４．０を採用する。このＢｌｕｅｔｏｏｔｈ（登録商標）通信は、無線ＬＡＮ通信と比べて通信可能な範囲が狭い（つまり、通信可能な距離が短い）。また、Ｂｌｕｅｔｏｏｔｈ（登録商標）通信は、無線ＬＡＮ通信と比べて通信速度が遅い。その一方で、Ｂｌｕｅｔｏｏｔｈ（登録商標）通信は、無線ＬＡＮ通信と比べて消費電力が少ない。

本実施形態のデジタルカメラ１００は、近距離無線通信部１１２を介して、外部装置とデータのやりとりを行うことができる。例えば外部装置から撮影の命令を受信した場合は撮像部１０２を制御し、撮影動作を行い、無線ＬＡＮ通信によるデータの授受を行うための命令を受信した場合は接続部１１１を制御し、無線ＬＡＮ通信を開始する。

近接無線通信部１１３は、例えば無線通信のためのアンテナと無線信号を処理するため変復調回路や通信コントローラから構成される。近接無線通信部１１３は、変調した無線信号をアンテナから出力し、またアンテナで受信した無線信号を復調することでＩＳＯ／ＩＥＣ １８０９２の規格（いわゆるＮＦＣ：Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）に従った非接触近接通信を実現する。本実施形態の近接無線通信部１１３は、デジタルカメラ１００の側部に配される。

外部装置とは、互いの近接無線通信部を近接させることにより通信を開始して接続される。なお、近接無線通信部を用いて接続させる場合、必ずしも近接無線通信部同士を接触させる必要はない。近接無線通信部は一定の距離だけ離れていても通信することができるため、互いの機器を接続するためには、近接無線通信可能な範囲まで近づければよい。以下の説明では、この近接無線通信可能な範囲まで近づけることを、近接させる、とも記載する。

また、互いの近接無線通信部が近接無線通信不可能な範囲にあれば、通信は開始されない。また、互いの近接無線通信部が近接無線通信可能な範囲にあって、デジタルカメラ１００同士が通信接続されている際に、互いの近接無線通信部１１３が近接無線通信不可能な範囲に離れてしまった場合は、通信接続が解除される。なお、近接無線通信部１１３が実現する非接触近接通信はＮＦＣに限られるものではなく、他の無線通信を採用してもよい。例えば、近接無線通信部１１３が実現する非接触近接通信として、ＩＳＯ／ＩＥＣ １４４４３の規格に従った非接触近接通信を採用してもよい。

本実施形態では、接続部１１１により実現される通信の通信速度は、後述の近接無線通信部１１３により実現される通信の通信速度よりも速い。また、接続部１１１により実現される通信は、近接無線通信部１１３による通信よりも、通信可能な範囲が広い。その代わり、近接無線通信部１１３による通信では、通信可能な範囲の狭さにより通信相手を限定することができるため、接続部１１１により実現される通信で必要な暗号鍵の交換等の処理を必要としない。すなわち、接続部１１１を用いるよりも手軽に通信することができる。

なお、本実施形態におけるデジタルカメラ１００の接続部１１１は、インフラストラクチャモードにおけるアクセスポイントとして動作するＡＰモードと、インフラストラクチャモードにおけるクライアントとして動作するＣＬモードとを有している。そして、接続部１１１をＣＬモードで動作させることにより、本実施形態におけるデジタルカメラ１００は、インフラストラクチャモードにおけるＣＬ機器として動作することが可能である。

デジタルカメラ１００がＣＬ機器として動作する場合、周辺のＡＰ機器に接続することで、ＡＰ機器が形成するネットワークに参加することが可能である。また、接続部１１１をＡＰモードで動作させることにより、本実施形態におけるデジタルカメラ１００は、ＡＰの一種ではあるが、より機能が限定された簡易的なＡＰ（以下、簡易ＡＰ）として動作することも可能である。

デジタルカメラ１００が簡易ＡＰとして動作すると、デジタルカメラ１００は自身でネットワークを形成する。デジタルカメラ１００の周辺の装置は、デジタルカメラ１００をＡＰ機器と認識し、デジタルカメラ１００が形成したネットワークに参加することが可能となる。上記のようにデジタルカメラ１００を動作させるためのプログラムは不揮発性メモリ１０３に保持されているものとする。

なお、本実施形態におけるデジタルカメラ１００はＡＰの一種であるものの、ＣＬ機器から受信したデータをインターネットプロバイダなどに転送するゲートウェイ機能は有していない簡易ＡＰである。したがって、自機が形成したネットワークに参加している他の装置からデータを受信しても、それをインターネットなどのネットワークに転送することはできない。

図２は、本実施形態の通信装置の一例であるスマートフォン２００の構成例を示すブロック図である。ここでは、通信装置の一例としてスマートフォンについて述べるが、通信装置はこれに限られない。例えば、通信装置は携帯型のメディアプレーヤや、いわゆるタブレットデバイス、パーソナルコンピュータなどの情報処理装置であってもよい。

制御部２０１から近接無線通信部２１３の各構成に関しては、デジタルカメラ１００の制御部１０１から近接無線通信部１１３と同等であるため説明は省略する。

公衆網通信部２１４は、公衆無線通信を行う際に用いられるインターフェースである。スマートフォン２００は、公衆網通信部２１４を介して、他の機器と通話することができる。この際、制御部２０１はマイク２１５およびスピーカ２１６を介して音声信号の入力と出力を行うことで、通話を実現する。本実施形態では、公衆網通信部２１４はアンテナであり、制御部２０１は、アンテナを介して、公衆網に接続することができる。なお、通信部２１１および公衆網通信部２１４は、一つのアンテナで兼用することも可能である
図３は、外部装置からデジタルカメラ１００を制御するためのアプリケーションプログラミングインターフェース（ＡＰＩ）を示す図である。本実施形態では、デジタルカメラ１００を、スマートフォン２００などの外部装置から制御するためのＡＰＩが公開されていることを前提としている。外部装置の設計者は、公開されたＡＰＩを用いてデジタルカメラ１００に要求を送信するように外部装置のアプリケーションを実装することで、ＡＰＩを用いてデジタルカメラ１００を制御し、デジタルカメラ１００のデバイス情報やデジタルカメラ１００が保持するコンテンツデータを取得することが可能となる。

デジタルカメラ１００の不揮発性メモリ１０３にはＡＰＩがプログラムとして予め保存されており、通信部１１１を介して外部装置との通信が確立すると、制御部１０１はＡＰＩを作業用メモリ１０４に展開し、外部装置からＡＰＩがリクエストされるのを待つ。制御部１０１は外部装置からＡＰＩがリクエストされたことを検知すると、リクエストされたＡＰＩに応じてデジタルカメラ１００の各部を制御して処理を実行し、その結果をレスポンスとして外部装置に返送する。

なお、ＡＰＩはデジタルカメラ１００が規定した通信プロトコル上で実行され、外部装置は規定された通信プロトコルを用いてデジタルカメラ１００と通信を行ってＡＰＩをリクエストする。なお、本実施形態では、通信プロトコルとしてＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を用いることを想定して説明するが、他の通信プロトコルを用いて実施することもできる。なお、ＨＴＴＰは公知の通信プロトコルであるため、その詳細についての説明は割愛する。

ＨＴＴＰを用いたＡＰＩのリクエストは、ＨＴＴＰリクエストボディにＡＰＩ名と必要な引数がテキストで記述され、これにＧＥＴメソッドやＤＥＬＥＴＥメソッド、ＰＯＳＴメソッド等のＨＴＴＰメソッドを組み合わせることで実現される。また、ＡＰＩに対するレスポンスは、それぞれのＡＰＩに対して規定されており、図３に示すようにＨＴＴＰレスポンスボディに情報を付加して実現される。本実施形態では、デジタルカメラ１００が、スマートフォン２００から送信されたＡＰＩに従って動作し、レスポンスをスマートフォン２００に返送する。

図３に示すＡＰＩリスト３００は、デジタルカメラ１００を制御するために提供（公開）されたＡＰＩの内容を示している。図３では、便宜上６種類のＡＰＩを示しているが、ＡＰＩの種類の数は６つに限定されない。また、図３に示すＡＰＩリスト３００は、デジタルカメラ１００とスマートフォン２００がＨＴＴＰ通信する場合を想定した例であるが、他の通信プロトコルでも同様に実現することができる。

ＡＰＩ３０１（ｈｔｔｐ：／／ｘｘｘ／ｄｅｖｉｃｅｉｎｆｏ）は、デジタルカメラ１００の製品情報を外部装置が取得できるようにするためのＡＰＩである。このＡＰＩ３０１をＧＥＴメソッドでデジタルカメラ１００にリクエストすることにより、デジタルカメラ１００の製品名やファームウェアバージョン、ＭＡＣアドレス、シリアルナンバー等の製品情報をレスポンスとして取得できる。なお、製品名とはデジタルカメラ１００の製品名、ファームウェアバージョンとは不揮発性メモリ１０３に保存されたデジタルカメラ１００を制御するためのプログラムのバージョン番号である。シリアルナンバーとは、デジタルカメラ１００の個体識別を可能とする一意の番号である。

ＡＰＩ３０２（ｈｔｔｐ：／／ｘｘｘ／ｃｏｎｔｅｎｔｓ／ｓｄ）は、デジタルカメラ１００の記録媒体１１０に保存されているコンテンツを操作するためのＡＰＩのひとつで、ＳＤカードの直下（以下、ＳＤ直下）に保存されているコンテンツの一覧を取得できるＡＰＩである。ここでコンテンツとは、静止画ファイルや動画ファイルなどのファイル、あるいはこれらのファイルが属するディレクトリなどが含まれる。このＡＰＩ３０２をＧＥＴメソッドでデジタルカメラ１００にリクエストすることにより、デジタルカメラ１００はＳＤ直下に保存されているコンテンツからそれぞれのコンテンツ情報を取得するためのＡＰＩ（ＵＲＬ）を含むレスポンスを生成し、まとめて返送する。

ＡＰＩ３０３（ｈｔｔｐ：／／ｘｘｘ／ｃｏｎｔｅｎｔｓ／ｓｄ／１００ｘｘｘｘｘ）は、デジタルカメラ１００の記録媒体１１０に保存されているコンテンツを操作するためのＡＰＩのひとつで、ＳＤ直下のディレクトリ「１００ｘｘｘｘｘ」を操作できるＡＰＩである。このＡＰＩをＧＥＴメソッドでデジタルカメラ１００にリクエストすることにより、デジタルカメラ１００は「１００ｘｘｘｘｘ」直下に保存されているコンテンツからそれぞれのコンテンツ情報を操作するためのＡＰＩ（ＵＲＬ）を含むレスポンスを生成し、まとめて返送する。また、このＡＰＩ３０３をＤＥＬＥＴＥメソッドでリクエストすることにより、デジタルカメラ１００は「１００ｘｘｘｘｘ」および「１００ｘｘｘｘｘ」に含まれるコンテンツをすべて削除する。コンテンツの削除に成功した場合は、「２００ ＯＫ」をレスポンスとして返却する。

ＡＰＩ３０４（ｈｔｔｐ：／／ｘｘｘ／ｃｏｎｔｅｎｔｓ／ｓｄ／１００ｘｘｘｘｘ／ＩＭＧ＿０００１．ＪＰＧ）は、デジタルカメラ１００の記録媒体１１０に保存されているコンテンツを操作するためのＡＰＩのひとつで、ＳＤ直下のフォルダ「１００ｘｘｘｘｘ」に保存されている「ＩＭＧ＿０００１．ＪＰＧ」のファイルデータを操作できるＡＰＩである。ＧＥＴメソッドでリクエストした場合、デジタルカメラ１００は記録媒体１１０に保存されている「ＩＭＧ＿０００１．ＪＰＧ」のファイルデータを取り出し、外部機器にレスポンスとして返送する。ＤＥＬＥＴＥメソッドでリクエストした場合、デジタルカメラ１００は「ＩＭＧ＿０００１．ＪＰＧ」のファイルデータを削除し、「２００ ＯＫ」をレスポンスとして返却する。

ＡＰＩ３０５（ｈｔｔｐ：／／ｘｘｘ／ｅｖｅｎｔ／ｍｏｎｉｔｏｒｉｎｇ）は、デジタルカメラ１００の記録媒体１１０に保存されているコンテンツの追加や削除等の変化情報を取得するためのＡＰＩである。後述するＡＰＩ３０６とはレスポンスの方式が異なり、ＡＰＩ３０５はＣｈｕｎｋ送信と呼ばれる方式を採用している。Ｃｈｕｎｋ送信はＨＴＴＰ／１．１で定義されている方式である。この方式の特徴を簡単に説明すると、ヘッダーにはデータのサイズを指定する記述（Ｃｏｎｔｅｎｔ－Ｌｅｎｇｔｈ）は入れず、エンコード方式をＣｈｕｎｋと指定する記述（Ｔｒａｎｓｆｅｒ－Ｅｎｃｏｄｉｎｇ：ｃｈｕｎｋｅｄ）を入れる。メッセージボディには、Ｃｈｕｎｋごとに、データサイズ、改行、実データ、改行、を繰り返し記述する。そしてＣｈｕｎｋデータの最後は「０」のみからなる行と空行で示す、というものである。Ｃｈｕｎｋ方式によると、複数のデータを１度に送信できるため、リクエストの回数は１度だけで済む。

デジタルカメラ１００は、デジタルカメラが保持するコンテンツに変化（追加や削除など）が生じると、その変化に応じて変化情報を生成し、作業用メモリ１０４に保持する。デジタルカメラ１００は、外部機器からＡＰＩ３０５のＧＥＴメソッドによりコンテンツの変化情報の取得要求を受けた場合、保持している変化情報を参照して、変化のあったコンテンツを操作するためのＡＰＩ（ＵＲＬ）を生成し、レスポンスとして返送する。そして、コンテンツの変化情報をレスポンスとして返送すると、デジタルカメラ１００は作業用メモリ１０４で保持していたコンテンツの変化情報を削除する。なお、以下の説明において、コンテンツの変化として、追加と削除を主に用いて説明するが、これ以外の編集などによる変化であってもよい。

ＡＰＩ３０５でリクエストされた場合は、ＣＨＵＮＫ方式による返送を行うため、ＤＥＬＥＴＥメソッドで取得の停止要求を受けるまで、デジタルカメラ１００はレスポンスを繰り返し返送する。このとき、作業用メモリ１０４に保持しているコンテンツの変化情報が無い場合は、空のデータをレスポンスとして送る。

ＡＰＩ３０６（ｈｔｔｐ：／／ｘｘｘ／ｅｖｅｎｔ／ｐｏｌｌｉｎｇ）は、デジタルカメラ１００の記録媒体１１０に保存されているコンテンツの追加や削除等の変化情報を取得するためのＡＰＩである。上述したＡＰＩ３０５とはレスポンスの方式が異なり、ＡＰＩ３０６はリクエストのあったタイミングで作業用メモリ１０４に保持しているコンテンツの変化情報のすべてを、ひとつのレスポンスで返却する。また、作業用メモリ１０４に保持しているコンテンツの変化情報が無い場合は、デジタルカメラ１００は外部機器にすぐにレスポンスを返送しない。外部機器からのリクエストを保持したまま、コンテンツの変化を検知するまで待ち、コンテンツの変化を検知してから変化情報をレスポンスとして返送する。これは、Ｌｏｎｇ Ｐｏｌｌｉｎｇと呼ばれるＨＴＴＰの手法の一種である。

ＡＰＩ３０５またはＡＰＩ３０６により、デジタルカメラ１００のコンテンツの変化情報を得た外部機器は、外部機器内で保持しているデジタルカメラ１００のコンテンツ情報を更新することで、デジタルカメラ１００で保持しているコンテンツの状態と同期することが可能となる。

デジタルカメラ１００内のコンテンツ変化ついて説明する。

図４はデジタルカメラ１００の記録媒体１１０が保持しているコンテンツを階層構造で示している。まず、図４（ａ）におけるデジタルカメラ１００に保存されているコンテンツの状態について説明する。コンテンツ４０１はデジタルカメラ１００の記録媒体１１０に該当する。コンテンツ４０２はＳＤカードに該当する。記録媒体１１０はＳＤカード等の外部ストレージであってデジタルカメラ１００に着脱可能であり、ＳＤカードが挿入されてＳＤカードの制御が可能となった状態を、図４（ａ）に示すようにコンテンツ４０１とコンテンツ４０２を線で繋いで表現する。

さらに、ＳＤカードの直下にディレクトリ「１００ＸＸＸＸＸ」があることをコンテンツ４０３で表現し、ディレクトリ「１００ＸＸＸＸＸ」のなかに、ファイル「ＩＭＧ＿０００１．ＪＰＧ」から「ＩＭＧ＿０９９９．ＪＰＧ」があることをコンテンツ４０４で表現している。

図４（ａ）の状態からディレクトリ「１００ＸＸＸＸＸ」内にファイル「ＩＭＧ＿１０００．ＪＰＧ」が追加されると図４（ｂ）の状態になる。コンテンツ４０５がファイル「ＩＭＧ＿１０００．ＪＰＧ」に該当する。

同様に図４（ｃ）は、ディレクトリ「１００ＸＸＸＸＸ」内にファイル「ＩＭＧ＿１００１．ＪＰＧ」が追加される場合に、ＳＤカード内にディレクトリ「１０１ＸＸＸＸＸ」が追加され、ディレクトリ「１０１ＸＸＸＸＸ」内にファイル「ＩＭＧ＿０００１．ＪＰＧ」が追加された状態を示している。

デジタルカメラ１００の制御部１０１は、このようにデジタルカメラ１００が保持するコンテンツに生じた変化を検知し、後述するようなコンテンツの変化情報として保持する。

次に、デジタルカメラ１００内のコンテンツ変化情報の保持ついて説明する。

図５はデジタルカメラ１００がコンテンツの変化情報を保持している様子を示した図である。

図５（ａ）はコンテンツ変化が１回発生したときのコンテンツ変化情報を表している。コンテンツ変化情報には、追加や削除などの変化内容を示す情報（図５の例では「Ｅｖｅｎｔ」）や、変化のあったコンテンツの保存場所を示す情報（図５の例では、「Ｓｔｏｒａｇｅ」，「Ｄｉｒｅｃｔｏｒｙ」）、コンテンツのファイル名（図５の例では「Ｆｉｌｅ」）などが含まれる。

コンテンツ変化情報５０１は、ストレージ「ＳＤ」のディレクトリ「１００ＸＸＸＸＸ」に、ファイル名「ＩＭＧ＿０００１．ＪＰＧ」が追加「ＡｄｄｅｄＣｏｎｔｅｎｔｓ」されたことを示している。コンテンツ変化があるたびに同様のコンテンツ変化情報が追加されて保持される。例えば、ＳＤカードが空の状態から図４（ａ）の状態までコンテンツが変化した場合、コンテンツ変化情報は図５（ｂ）のような状態になる。なお、変化が削除の場合は、「Ｅｖｅｎｔ」として「ＤｅｌｌｅｔｅｄＣｏｎｔｅｎｔｓ」が示され、削除前に保存されていた保存場所を示す情報を含むように構成することができる。

図５のそれぞれのコンテンツ変化情報の左に添えられている数字は、保持されているコンテンツ変化情報の数を示しており、図５（ｂ）は９９９個のコンテンツ変化情報を保持していることを示している。コンテンツの変化量が多いほど、保持しなければいけないコンテンツの変化情報量が増えていく。コンテンツの変化情報はデジタルカメラ１００の作業用メモリ１０４で保持されるが、作業用メモリ１０４の容量は有限であり、コンテンツ変化量が一定量を超えると、コンテンツ変化情報を保持しきれなくなる。その対策として、本実施形態で実施するコンテンツの変化情報を圧縮する方法について説明する。

次に、コンテンツの変化情報の圧縮方法ついて説明する。

同一のディレクトリ内のコンテンツ変化が多い場合、そのディレクトリに変化があったとして、ディレクトリの変化情報を１つ追加し、コンテンツごとの変化情報を削除することで、保持しなければいけない変化情報の数を減らすことができる。つまり、変化が生じたそれぞれのコンテンツの変化情報をディレクトリ単位で纏めて圧縮することで変化情報の数を減らしている。

一例として、図５（ｂ）の状態を圧縮する場合について説明する。図５（ｂ）は、ストレージ「ＳＤ」のディレクトリ「１００ＸＸＸＸＸ」に、ファイルが追加「ＡｄｄｅｄＣｏｎｔｅｎｔｓ」されたことを示すコンテンツ変化情報が９９９個保持されている。これらの変化情報は、変化内容（Ｅｖｅｎｔ）と保存場所（Ｓｔｏｒａｇｅ、Ｄｉｒｅｃｔｏｒｙ）が共通であり、ファイル名（Ｆｉｌｅ）を共通の文字列に置き換えてしまえば、すべて同一の変化情報となる。これら同一の情報をひとつに纏めると、図５（ｃ）のような状態となる。こうすることで、保持されている変化情報の数はディレクトリ単位の１個となり、圧縮前に比べて９９８個の情報削減が可能となる。

この状態からさらにコンテンツ変化があった場合について説明する。例えば、図４（ａ）から図４（ｂ）のように変化した場合、ディレクトリ「１００ＸＸＸＸＸ」にファイル「ＩＭＧ＿１０００．ＪＰＧ」が追加されたことを示す変化情報は、すでに保持されている変化情報５０３に内包される。よって、保持される変化情報は図５（ｃ）のままとなる。さらに、図４（ｂ）から図４（ｃ）のようにコンテンツが変化した場合、追加されたファイル「ＩＭＧ＿１００１．ＪＰＧ」はすでに保持されているディレクトリ「１００ＸＸＸＸＸ」の変化情報に内包され、追加されたディレクトリ「１０１ＸＸＸＸＸ」とファイル「ＩＭＧ＿０００１．ＪＰＧ」は、新たな変化情報５０４として保持される。その結果、保持される変化情報は図５（ｄ）の状態となる。

コンテンツ変化情報の圧縮を行う条件ついて説明する。

上述したようにコンテンツ変化情報を圧縮することにより、保持するコンテンツ変化情報のデータ量は減らすことができる。しかし、複数のファイル単位の変化情報がディレクトリ単位の変化情報に纏められて情報が丸め込まれてしまうため、コンテンツ変化情報を受信する受信機側で詳細な変化情報を得ることができなくなってしまう。そこで、変化情報を送信する送信機器側の状態に応じ、圧縮を行う条件を適切なものにする必要がある。圧縮を行う条件として以下が挙げられる。

１つ目の条件は、保持する変化情報の数が一定量を超えたら情報を圧縮するケースである。上述したとおり、コンテンツ変化情報を保持する作業用メモリ１０４は有限であり、保持できるデータ量には限りがある。そこで、保持する変化情報の数に上限を設け、上限を越えたタイミングで圧縮を行う。コンテンツ変化が少量の場合は、詳細な変化情報を通知することができる。すなわち、変化が生じたコンテンツの数が所定数未満の場合と所定数以上の場合とで制御を異ならせる。

２つ目の条件は、コンテンツの変化内容に応じて圧縮するか否かを決定するケースである。具体的には、変化内容が削除の場合に変化情報を圧縮する。

デジタルカメラにおいて、一度の操作で変化するコンテンツの数は追加よりも削除のほうが多い。コンテンツの追加は主に撮影である。一度の撮影操作で増えるコンテンツはせいぜい数個である。それに対し削除は、複数枚指定して削除、フォルダごと削除、ＳＤカード内の全削除など、一度の操作で変化するコンテンツの数が多い。そこで、削除によるコンテンツ変化を検出した場合には、コンテンツのファイル単位で変化情報を保持するのではなく、あらかじめディレクトリ単位もしくはストレージ単位で保持することで、効率的に情報を保持することができる。

また、受信機側も追加に比べ削除に関しては、コンテンツの変化に関して詳細な情報が必要ないこともある。例えば、受信機側が保持しているコンテンツ情報を更新する際、変化情報にある削除されたコンテンツを逐次的に検索し該当する情報を更新していくよりも、削除があったディレクトリに保存されているファイル情報を取得しなおして一括で更新したほうが処理が早い。その場合は、受信機側は、変化のあったディレクトリの情報を取得するだけで十分である。

３つ目の条件は、撮影モードが連写だったら情報を圧縮するケースである。

デジタルカメラには写真を１枚ずつ撮影する単写モードと、複数枚連続して撮影する連写モードがある。連写モードでは一度に大量のコンテンツが追加されることが予想されるため、連写モードに設定されている場合は、連写で取得されるコンテンツをディレクトリ単位に纏めて保持してあげることで、効率的に情報を保持することができる。

４つ目の条件は、ＡＰＩのレスポンスのデータ形式に応じて圧縮するか否かを決定するケースである。具体的には、レスポンスのデータ形式がＣＨＵＮＫ形式だったら情報を圧縮しない。

上述したとおり、ＣＨＵＮＫ形式は一度のリクエストでデータを送り続けることができる。そのため、コンテンツ変化情報も複数回にわたって受信機側に送り続けることができ、送信の度に保持する変化情報を削除するので、保持しなければいけない変化情報の数は少量ですむ。ＡＰＩ３０５などＣＨＵＮＫ形式でリクエストを受けた場合は、ファイル単位で情報を保持することで、詳細な変化情報を受信機側に通知することができる。また、ＡＰＩ３０６のようなＬｏｎｇ Ｐｏｌｌｉｎｇと呼ばれる形式（ＰＯＬＬＩＮＧ形式）でレスポンスが要求された場合は、変化情報を大量に送る場合があるので、ディレクトリ単位に変化情報を圧縮して送信する。

以上、コンテンツの変化情報をディレクトリ単位に圧縮するかどうかを決定する条件として４つの条件を例示したが、これ以外の条件に従ってもよい。また、上記４つの条件のいずれかのみを使用してもよいし、複数の条件を組み合わせて使用してもよい。

図６は本実施形態におけるデジタルカメラ１００の処理を取り出して示したフローチャートである。

図６（ａ）はコンテンツの変化を検知して、コンテンツの変化情報を保持するまでの処理、図６（ｂ）は受信機器からのコンテンツの変化情報の取得要求を受けてからレスポンスを返すまでの処理を示している。

図６（ａ）のＳ６０１ａにおいて、制御部１０１は、コンテンツの追加や削除等のコンテンツの変化を検知をする。検知をした場合、Ｓ６０２ａにおいてコンテンツの変化情報を生成する。コンテンツの変化情報の生成に必要な情報は、記録媒体１１０や作業用メモリ１０４から収集する。

Ｓ６０３ａにおいて、上述したコンテンツの変化情報の圧縮の条件に基づき、コンテンツの変化情報の圧縮が必要か否かの判定する。コンテンツの変化情報の圧縮が必要と判断された場合、Ｓ６０４ａにおいてコンテンツの変化情報の圧縮を行う。

最後に、Ｓ６０５ａにおいて、コンテンツの変化情報を保持し、Ｓ６０１ａに戻り、処理繰り返す。

図６（ｂ）のＳ６０１ｂにおいて、制御部１０１は、通信部１１１を通じてスマートフォン２００からコンテンツ変化情報の取得要求を受信する。取得要求は、上述したＡＰＩ３０５のＧＥＴメソッド、またはＡＰＩ３０６のＧＥＴメソッドが該当する。取得要求を受信した場合、Ｓ６０２ｂへ進む。

Ｓ６０２ｂにおいて、スマートフォン２００からの取得要求に対するレスポンスのデータ形式がＣｈｕｎｋ形式であるか否かを判定する。ＡＰＩ３０６で要求されている場合には、Ｃｈｕｎｋ形式での応答とならないため、Ｓ６０３ｂへ進む。ＡＰＩ３０５で要求されている場合は、Ｃｈｕｎｋ形式での応答となるため、Ｓ６０７ｂへ進む。

Ｓ６０３ｂにおいて、制御部１０１は保持しているコンテンツ変化情報の有無を確認する。保持している変化情報がある場合はＳ６０４ｂへ進む。保持している変化情報がない場合は、Ｓ６０６ｂへ進む。

Ｓ６０４ｂにおいて、制御部１０１は保持している変化情報をレスポンスのデータ形式に変換する。図３のｒｅｓｐｏｎｓｅ列の例だと、変化したコンテンツを制御できるＡＰＩ（ＵＲＬ）を生成し、変化内容（Ｅｖｅｎｔ）ごとにまとめたＪＳＯＮ形式のデータを生成する。

Ｓ６０５ｂにおいて、制御部１０１は通信部１１１を通じてスマートフォン２００へレスポンスデータを送信する。送信が完了すると、Ｓ６０１ｂへ戻り、はじめから処理を繰り返す。

Ｓ６０６ｂにおいて、スマートフォン２００からコンテンツの変化情報の停止要求を検知した場合、Ｓ６０１ｂへ戻り、はじめから処理を繰り返す。停止要求を検知しない場合、Ｓ６０３ｂへ戻り、コンテンツ変化情報が保持されるまで処理を繰り返す。ここで停止要求はＡＰＩ３０６のＤＥＬＥＴＥメソッドがこれに該当する。

Ｓ６０７ｂにおいて、Ｓ６０３ｂと同様に保持しているコンテンツ変化情報の有無を確認する。保持している変化情報がある場合はＳ６０８ｂへ進む。保持している変化情報がない場合は、Ｓ６０９ｂへ進む。Ｃｈｕｎｋ形式での応答の場合、コンテンツの変化が無くてもレスポンスを送信する。

Ｓ６０８ｂにおいて、Ｓ６０４ｂと同様に、制御部１０１は保持している変化情報をレスポンス用のＪＳＯＮデータ形式に変換する。

Ｓ６０９ｂにおいて、制御部１０１はレスポンス用データを生成する。このとき、コンテンツの変化が無いため、空のＪＳＯＮデータを生成する。

Ｓ６１０ｂにおいて、制御部１０１は、通信部１１１を通じてスマートフォン２００に対し、生成したレスポンスデータを送信する。送信が完了するとＳ６１１ｂへ進む。

Ｓ６１１ｂにおいて、スマートフォン２００からコンテンツの変化情報の停止要求を検知した場合、Ｓ６０１ｂへ戻り、はじめから処理を繰り返す。停止要求を検知しない場合、Ｓ６０７ｂへ戻り、レスポンスデータの生成と送信処理を繰り返す。ここで停止要求はＡＰＩ３０５のＤＥＬＥＴＥメソッドがこれに該当する。

なお、上記フローでは、コンテンツの変化情報をＪＳＯＮ形式に変換してレスポンスを送信しているがこれに限らない。変化情報が示す変化の内容を受信機に実質的に通知することが可能であれば、他の形式でもよい。

図７は、本実施形態におけるスマートフォン２００の処理を取り出して示したフローチャートである。

以下の動作は、制御部２０１がスマートフォン２００にインストールされている、デジタルカメラ１００との連係動作するためのアプリケーション（通信アプリ）を実行することにより実現される。

Ｓ７０１において、制御部２０１は、デジタルカメラ１００に送信したコンテンツの変化情報の取得を要求するＡＰＩに対するレスポンスを受信する。変化情報を受信するとＳ７０２へ進む。ここで制御部２０１は、取得したレスポンスデータをコンテンツの変化情報に変換する。レスポンスデータのヘッダ情報から取得したデータ形式がＣｈｕｎｋ形式か否かが判断できるため、制御部２０１は適当な変換方法を選択することができる。上述したように、レスポンスの形式に応じて変換方法を適応的に設定してもよい。

Ｓ７０２において、得られたコンテンツ変化情報を解析する。コンテンツの変化内容は追加なのか削除なのか、また変化情報はディレクトリ単位なのかファイル単位なのか等、スマートフォン２００で保持しているコンテンツ情報を更新するために必要な情報を読み取る。ここで、得られた変化情報に詳細な情報がない場合、Ｓ７０４において、詳細な変化情報の要求と取得を行う。例えば、コンテンツの追加情報がディレクトリ単位で纏められて情報が丸め込まれていた場合、スマートフォン２００は追加されたコンテンツのファイル単位の情報が別途必要となる。そこで、スマートフォン２００は得られた変化情報から該当のディレクトリを制御するためのＡＰＩ（ＵＲＬ）を取得し、このＡＰＩ（ＵＲＬ）を実行することで、ディレクトリ内のファイル情報を得ることができる。例えば、図３のＡＰＩ３０２やＡＰＩ３０３がこれに該当する。

Ｓ７０５において、コンテンツの取得が必要か否かを判断する。コンテンツの取得が必要な場合、Ｓ７０６へ進む。コンテンツの取得が必要な場合の例としては、例えば、スマートフォン２００上のアプリでデジタルカメラ１００内のコンテンツ一覧画面を生成する場合などが挙げられる。コンテンツを表示するためには、コンテンツのファイルデータの取得が必要となるからである。

Ｓ７０６において、制御部２０１は、デジタルカメラ１００に対して、コンテンツのファイルデータの要求および取得を行う。ファイルデータは、変化情報やＡＰＩ３０２に含まれる、ファイルを制御するためのＡＰＩ（ＵＲＬ）を実行することで取得ができる。ＡＰＩ３０４がこれに該当する。

最後に、Ｓ７０７において、取得した変化情報やファイルデータを用いて、保持しているコンテンツ情報を更新する。更新が完了したら、Ｓ７０１に戻り処理を繰り返す。これらの処理を繰り返すことにより、スマートフォン２００で保持しているコンテンツ情報をデジタルカメラで保持しているコンテンツ情報を同期することができる。

なお、本実施形態では、図３に示すＡＰＩ３０１～３０６をＡＰＩサービスとして提供されていることを前提に説明したが、ＡＰＩサービスで提供するＡＰＩの種類はこれらに限定されない。例えば、「リモート撮影をする」および「カメラの設定をする」等の連係動作を実現するためのＡＰＩが提供されてもよい。新たなＡＰＩの追加はデジタルカメラ１００で実行するＡＰＩプログラムを追加してインストールすることにより実現可能である。

以上説明したように、本実施形態によれば、コンテンツデータを有する電子機器が、コンテンツデータの変化情報のデータ量を状況に応じて圧縮し、外部装置に提供するようにした。そのため、できる限り通信やデータ保持に負荷を与えることなく、詳細なコンテンツの変化情報を外部装置へ通知することが可能となる。

以上、本発明をその好適な実施形態に基づいて詳述してきたが、本発明はこれら特定の実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の様々な形態も本発明に含まれる。また、上述の実施形態においては、送信対象を画像として説明したが、これに限る必要はない。たとえば、音声ファイルや文書ファイルなど、クライアント機器とサーバ機器の間でやりとりできるファイルであれば何でもよい。

また、上述の実施形態の機能を実現するソフトウェアのプログラムを、記録媒体から直接、或いは有線／無線通信を用いてプログラムを実行可能なコンピュータを有するシステム又は装置に供給し、そのプログラムを実行する場合も本発明に含む。従って、本発明の機能処理をコンピュータで実現するために、該コンピュータに供給、インストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明の機能処理を実現するためのコンピュータプログラム自体も本発明に含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。プログラムを供給するための記録媒体としては、例えば、ハードディスク、磁気テープ等の磁気記録媒体、光／光磁気記憶媒体、不揮発性の半導体メモリでもよい。また、プログラムの供給方法としては、コンピュータネットワーク上のサーバに本発明を形成するコンピュータプログラムを記憶し、接続のあったクライアントコンピュータがコンピュータプログラムをダウンロードしてプログラムするような方法も考えられる。

Claims (11)

1. 外部装置と通信する通信装置であって、
   前記通信装置が保持するコンテンツに変化が生じると変化の内容に相当する変化情報を生成する生成手段と、
   変化の生じたコンテンツのファイル単位で前記変化情報を生成する第１モードと、変化の生じたコンテンツが属するディレクトリ単位で前記変化情報を生成する第２モードとの何れかのモードに従って動作するように前記生成手段を制御する制御手段と、
   前記変化情報を前記外部装置からの要求に応じて送信する通信手段と、を備え、
   前記制御手段は、変化の内容がコンテンツの追加の場合は前記第１モードで動作し、変化の内容がコンテンツの削除の場合は前記第２モードで動作するように前記生成手段を制御する、ことを特徴とする通信装置。
2. 通信装置が有するコンテンツの変化を検知する検知手段を有し、
   前記生成手段は、前記検知手段によって検知されたコンテンツの変化に基づいて、前記変化情報を生成することを特徴とする請求項１に記載の通信装置。
3. 前記生成手段は、前記第２モードで動作する場合、変化が生じた複数のコンテンツについてファイル単位で変化情報をそれぞれ生成し、生成した変化情報をディレクトリ単位で纏めることで前記外部装置に送信される変化情報を生成する、ことを特徴とする請求項１または２に記載の通信装置。
4. 前記第２モードで生成された変化情報は、前記第１モードで生成された変化情報よりも通信のデータ量を小さいことを特徴とする請求項１から３の何れか１項に記載の通信装置。
5. 前記変化情報を前記外部装置に送信することで前記外部装置が保持するコンテンツの情報の更新を可能にすることを特徴とする請求項１から４の何れか１項に記載の通信装置。
6. 前記制御手段は、
   変化が生じたコンテンツの数が所定数未満の場合は前記第１モードで動作し、
   変化が生じたコンテンツの数が所定数以上の場合は前記第２モードで動作するように前記生成手段を制御する、ことを特徴とする請求項１から５の何れか１項に記載の通信装置。
7. 撮像手段を備え、
   前記制御手段は、
   前記撮像手段の単写の撮影で得られたコンテンツが追加されることによって前記通信装置が有するコンテンツに変化が生じた場合は前記第１モードで動作し、
   前記撮像手段の連写の撮影で得られたコンテンツが追加されることによって前記通信装置が有するコンテンツに変化が生じた場合は前記第２モードで動作するように前記生成手段を制御する、ことを特徴とする請求項１から５の何れか１項に記載の通信装置。
8. 前記制御手段は、
   前記外部装置からの要求が前記変化情報を複数回にわたって送信するように求める場合は前記第１モードで動作し、
   前記外部装置からの要求が前記変化情報を１回で送信するように求める場合は前記第２モードで動作するように前記生成手段を制御する、ことを特徴とする請求項１から５の何れか１項に記載の通信装置。
9. 前記通信手段はＨＴＴＰを用いて前記外部装置と通信可能であり、
   前記外部装置からの要求がＣＨＵＮＫ形式による送信を示す場合は前記第１モードで動作し、
   前記外部装置からの要求がＰＯＬＬＩＮＧ形式による送信を示す場合は前記第２モードで動作するように前記生成手段を制御する、ことを特徴とする請求項１から５の何れか１項に記載の通信装置。
10. 外部装置と通信する通信装置の制御方法であって、
    前記通信装置が保持するコンテンツに変化が生じると変化の内容に相当する変化情報を、変化の生じたコンテンツのファイル単位で前記変化情報を生成する第１モードと、変化の生じたコンテンツが属するディレクトリ単位で前記変化情報を生成する第２モードのいずれかのモードに従って生成する工程と、
    生成された前記変化情報を前記外部装置からの要求に応じて送信する工程と、を備え、
    変化の内容がコンテンツの追加の場合は前記第１モードで動作し、変化の内容がコンテンツの削除の場合は前記第２モードで動作するように前記生成手段を制御する、ことを特徴とする、ことを特徴とする通信装置の制御方法。
11. 外部装置と通信する通信装置のコンピュータに、
    前記通信装置が保持するコンテンツに変化が生じると変化の内容に相当する変化情報を、変化の生じたコンテンツのファイル単位で前記変化情報を生成する第１モードと、変化の生じたコンテンツが属するディレクトリ単位で前記変化情報を生成する第２モードのいずれかのモードに従って生成する工程と、
    生成された前記変化情報を前記外部装置からの要求に応じて送信する工程と、
    変化の内容がコンテンツの追加の場合は前記第１モードで動作し、変化の内容がコンテンツの削除の場合は前記第２モードで動作するように前記生成手段を制御する工程と
    を実行させるためのプログラム。

Images