JP6824949B2 - 通信装置、制御方法およびプログラム - Google Patents

Description

本発明は外部装置と通信できる通信装置に関する。

近年、デジタルカメラや携帯電話等の通信装置の通信機能の進歩に伴い、通信装置同士でコンテンツを送受信することが行われている。

特許文献１では、ＨＴＴＰのようなサーバ・クライアントのシステムを用いて、デジタルカメラがサーバ側となってリモート撮影を実現することが開示されている。

特開２０１３−０７３５０６号公報

ＨＴＴＰのサーバ・クライアントのシステムを用いたリモートコントロール機能をユーザに提供する場合、リモートコントロールされるデジタルカメラがサーバとなり、リモートコントロールする側がクライアントとなる。そして、クライアントとなる装置にデジタルカメラをコントロールするプログラムを実装することで、リモートコントロールを実現する。この場合、デジタルカメラをリモートコントロールするためのＵＲＬと実行可能なＨＴＴＰメソッドの組み合わせを通信ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）として公開することで、クライアントのプログラムの実装負荷を低減することが考えられる。対向機であるクライアントには、公開されたＡＰＩの仕様に基づいて、リモートコントロールを実現するプログラムを実装する。この実装負荷をより軽減するために、チャンク送信を利用したＡＰＩを用意することが考えられる。しかし、チャンク送信はＨＴＴＰレスポンスヘッダを返した後にＨＴＴＰレスポンスボディを繰り返し送信する送信方法である。そのため、ＨＴＴＰレスポンスボディの送信の途中において、送信すべきデータを用意できない場合、デジタルカメラはＨＴＴＰレスポンスヘッダを用いてエラーを通知することができない。一方、エラーを通知するために、ＨＴＴＰレスポンスボディにエラーの情報を含めると、対向機においてそのエラーの情報を解析するための処理が必要となり、対向アプリケーションの開発の実装負荷が増大してしまう。

そこで、本発明は、通信装置を制御するための対向アプリケーションを開発する際の実装負荷をより低減することを目的とする。

本発明に係る通信装置の一つは、ライブビュー画像を生成する生成手段と、通信手段と、制御手段とを有する通信装置であって、前記制御手段が前記通信手段を介して外部装置から第一のリクエストを受信した場合、前記制御手段は、前記生成手段で生成されたライブビュー画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを繰り返し行い、前記生成手段でライブビュー画像の生成が行われている場合に、ライブビュー画像の生成が阻害される処理が行われた場合、前記制御手段は、前記生成手段で生成されなかったライブビュー画像の代わりに所定の画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを行い、前記制御手段が前記通信手段を介して前記外部装置から前記第一のリクエストを受信した場合にライブビュー画像から生成されたレスポンスは、チャンク送信（Ｃｈｕｎｋｅｄ Ｔｒａｎｓｆｅｒ）によって前記外部装置に送信される。

本発明によれば、通信装置を制御するための対向アプリケーションを開発する際の実装負荷をより低減することができる。

第１の実施形態におけるデジタルカメラのブロック構成、正面、背面を示す図である。 第１の実施形態におけるスマートデバイスの構成を示すブロック図である。 第１の実施形態におけるシステム構成を示すブロック図である。 第１の実施形態における通信ＡＰＩの基本構成を示す図である。 第１の実施形態におけるデジタルカメラのスルー画を取得するＡＰＩを説明する図。 第１の実施形態におけるスルー画を１フレームずつ取得するＡＰＩを実行した場合のシーケンス図の一例である。 第１の実施形態におけるデジタルカメラのスルー画をチャンク送信によって取得するＡＰＩを実行した場合のシーケンス図の一例である。 第１の実施形態におけるデジタルカメラ１００の動作の一例を示すフローチャートである。 第１の実施形態におけるスマートデバイス２００の動作の一例を示すフローチャートである。 （ａ）第１の実施形態におけるスルー画を１フレームずつ取得するライブビュー中のスマートデバイス２００のＵＩ図の一例である。（ｂ）第１の実施形態におけるスルー画を１フレームずつ取得するライブビュー中にデジタルカメラ１００にエラーが発生した場合のスマートデバイス２００のＵＩ図の一例である。 （ａ）第１の実施形態を利用するチャンク送信におけるライブビュー中のスマートデバイス２００のＵＩ図の一例である。（ｂ）第１の実施形態を利用するチャンク送信におけるライブビュー中にデジタルカメラ１００にエラーが発生した場合のスマートデバイス２００のＵＩ図の一例である。（ｃ）第１の実施形態を利用しないチャンク送信におけるライブビュー中にデジタルカメラ１００にエラーが発生した場合のスマートデバイス２００のＵＩ図の一例である。 第１の実施形態におけるスルー画を１フレームずつ取得する場合におけるデジタルカメラ１００の動作の一例を示すフローチャートである。 第１の実施形態におけるスルー画を１フレームずつ取得する場合におけるスマートデバイスのフローチャートの一例である。 第１の実施形態を利用しないチャンク送信におけるデジタルカメラ１００の動作の一例の示すフローチャートである。 第１の実施形態を利用しないチャンク送信におけるスマートデバイス２００の動作の一例の示すフローチャートである。 第１の実施形態を利用するチャンク送信におけるデジタルカメラ１００の動作の一例の示すフローチャートである。 第１の実施形態を利用するチャンク送信におけるスマートデバイス２００の動作の一例の示すフローチャートである。

以下、添付図面に従って本発明の実施形態を詳細に説明する。なお、以下に説明する実施形態は、本発明の実現手段としての一例であり、本発明が適用される装置の構成や各種条件によって適宜修正又は変更されてもよい。また、各実施形態を適宜組み合せることも可能である。

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

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

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

不揮発性メモリ１０３は、電気的に消去・記録可能な不揮発性のメモリであり、制御部１０１で実行される後述のプログラム等が格納される。作業用メモリ１０４は、撮像部１０２で撮像された画像データを一時的に保持するバッファメモリや、表示部１０６の画像表示用メモリ、制御部１０１の作業領域等として使用される。

操作部１０５は、ユーザがデジタルカメラ１００に対する指示をユーザから受け付けるために用いられる。操作部１０５は例えば、ユーザがデジタルカメラ１００の電源のＯＮ／ＯＦＦを指示するための電源ボタンや、撮影を指示するためのレリーズスイッチ、画像データの再生を指示するための再生ボタンを含む。さらに、後述の通信部１１１を介して外部機器との通信を開始するための専用の接続ボタンなどの操作部材を含む。また、後述する表示部１０６に形成されるタッチパネルも操作部１０５に含まれる。なお、レリーズスイッチは、押下状態を２段階で検出するためにＳＷ１およびＳＷ２を有する。レリーズスイッチが、いわゆる半押し状態となることにより、ＳＷ１がＯＮとなる。これにより、ＡＦ（オートフォーカス）処理、ＡＥ（自動露出）処理、ＡＷＢ（オートホワイトバランス）処理、ＥＦ（フラッシュプリ発光）処理等の撮影準備を行うための指示を受け付ける。また、レリーズスイッチが、いわゆる全押し状態となることにより、ＳＷ２がＯＮとなる。これにより、撮影を行うための指示を受け付ける。

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

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

通信部１１１は、外部装置と接続するためのインターフェイスである。本実施形態のデジタルカメラ１００は、通信部１１１を介して、外部装置とデータのやりとりを行うことができる。例えば、撮像部１０２で生成した画像データを、通信部１１１を介して外部装置に送信することができる。なお、本実施形態では、通信部１１１は外部装置とＩＥＥＥ８０２．１１の規格に従った、いわゆる無線ＬＡＮで通信するためのインターフェイスを含む。制御部１０１は、通信部１１１を制御することで外部装置との無線通信を実現する。なお、通信方式は無線ＬＡＮに限定されるものではなく、例えば赤外線通信方式、Ｂｌｕｅｔｏｏｔｈ（登録商標）通信方式、ＷｉｒｅｌｅｓｓＵＳＢ等の無線通信方式などを含むことができる。さらには、ＵＳＢケーブルやＨＤＭＩ（登録商標）、ＩＥＥＥ１３９４、Ｅｔｈｅｒｎｅｔなど、有線接続を採用してもよい。

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

本実施形態において、後述するスマートデバイス２００とは、通信部より通信を開始して接続される。また、本実施形態におけるデジタルカメラ１００の通信部１１１は、インフラストラクチャモードにおけるアクセスポイントとして動作するＡＰモードと、インフラストラクチャモードにおけるクライアントとして動作するＣＬモードとを有している。そして、通信部１１１をＣＬモードで動作させることにより、本実施形態におけるデジタルカメラ１００は、インフラストラクチャモードにおけるＣＬ機器として動作することが可能である。デジタルカメラ１００がＣＬ機器として動作する場合、周辺のＡＰ機器に接続することで、ＡＰ機器が形成するネットワークに参加することが可能である。また、通信部１１１をＡＰモードで動作させることにより、本実施形態におけるデジタルカメラ１００は、ＡＰの一種ではあるが、より機能が限定された簡易的なＡＰ（以下、簡易ＡＰ）として動作することも可能である。デジタルカメラ１００が簡易ＡＰとして動作すると、デジタルカメラ１００は自身でネットワークを形成する。デジタルカメラ１００の周辺の装置は、デジタルカメラ１００をＡＰ機器と認識し、デジタルカメラ１００が形成したネットワークに参加することが可能となる。上記のようにデジタルカメラ１００を動作させるためのプログラムは不揮発性メモリ１０３に保持されているものであり、ＡＰモード、ＣＬモードを、ユーザが操作部１０５を操作して選択することになる。

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

次に、デジタルカメラ１００の外観について説明する。図１（ｂ）、図１（ｃ）はデジタルカメラ１００の外観正面、背面の一例を示す図である。レリーズスイッチ１０５ａや再生ボタン１０５ｂ、方向キー１０５ｃ、タッチパネル１０５ｄは、前述の操作部１０５に含まれる操作部材である。また、表示部１０６には、撮像部１０２による撮像の結果得られた画像が表示される。以上、実施形態におけるデジタルカメラ１００の構成を説明した。

＜スマートデバイス２００の内部構成＞
図２は、本実施形態のデジタルカメラ１００と通信する情報処理装置の一例であるスマートデバイス２００の構成例を示すブロック図である。なお、スマートデバイスとはスマートフォンやタブレットデバイス等の携帯端末を意味する。また、ここでは情報処理装置の一例としてスマートデバイスについて述べるが、情報処理装置はこれに限られない。例えば情報処理装置は、無線機能付きのデジタルカメラやプリンタ、テレビ、あるいはパーソナルコンピュータなどであってもよい。

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

撮像部２０２は、撮像部２０２に含まれるレンズで結像された被写体光を電気信号に変換し、ノイズ低減処理などを行い、デジタルデータを画像データとして出力する。撮像した画像データはバッファメモリに蓄えられた後、制御部２０１にて所定の演算や符号化処理が施され、記録媒体２１０にファイルとして記録される。

不揮発性メモリ２０３は、電気的に消去・記録可能な不揮発性のメモリである。不揮発性メモリ２０３には、制御部２０１が実行する基本的なソフトウェアであるＯＳ（オペレーティングシステム）や、このＯＳと協働して応用的な機能を実現するアプリケーションが記録されている。また、本実施形態では、不揮発性メモリ２０３には、デジタルカメラ１００と通信するためのアプリケーション（以下アプリ）が格納されている。

作業用メモリ２０４は、表示部２０６の画像表示用メモリや、制御部２０１の作業領域等として使用される。操作部２０５は、スマートデバイス２００に対する指示をユーザから受け付けるために用いられる。操作部２０５は例えば、ユーザがスマートデバイス２００の電源のＯＮ／ＯＦＦを指示するための電源ボタンや、表示部２０６に形成されるタッチパネルなどの操作部材を含む。表示部２０６は、画像データの表示、対話的な操作のための文字表示などを行う。なお、表示部２０６は必ずしもスマートデバイス２００が備える必要はない。スマートデバイス２００は表示部２０６と接続することができ、表示部２０６の表示を制御する表示制御機能を少なくとも有していればよい。なお、操作部２０５及び表示部２０６で、スマートデバイス２００のユーザインターフェースを構成することになる。

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

通信部２１１は、外部装置と接続するためのインターフェイスである。本実施形態のスマートデバイス２００は、通信部２１１を介して、デジタルカメラ１００とデータのやりとりを行うことができる。本実施形態では、通信部２１１はアンテナであり、制御部１０１は、アンテナを介して、デジタルカメラ１００と接続することができる。なお、デジタルカメラ１００との接続では、直接接続してもよいしアクセスポイントを介して接続してもよい。データを通信するためのプロトコルとしては、例えばＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）である。その他、無線ＬＡＮを通じたＰＴＰ／ＩＰ（Ｐｉｃｔｕｒｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を用いることもできる。なお、デジタルカメラ１００との通信はこれに限られるものではない。例えば、通信部２１１は、赤外線通信モジュール、Ｂｌｕｅｔｏｏｔｈ（登録商標）通信モジュール、ＷｉｒｅｌｅｓｓＵＳＢ等の無線通信モジュールを含むことができる。さらには、ＵＳＢケーブルやＨＤＭＩ、ＩＥＥＥ１３９４、Ｅｔｈｅｒｎｅｔなど、有線接続を採用してもよい。

近距離無線通信部２１２は、他機との非接触近距離通信を実現するための通信ユニットである。近距離無線通信部２１２は、無線通信のためのアンテナと無線信号を処理するための変復調回路や通信コントローラから構成される。近距離無線通信部２１２は、変調した無線信号をアンテナから出力し、またアンテナで受信した無線信号を復調することにより非接触近距離通信を実現する。ここでは、ＩＳＯ／ＩＥＣ １８０９２の規格（いわゆるＮＦＣ）に従った非接触通信を実現する。近距離無線通信部２１２は、他のデバイスからデータ読み出し要求を受けると、不揮発性メモリ２０３に格納されているデータに基づき、応答データを出力する。

公衆網通信部２１３は、公衆無線通信を行う際に用いられるインターフェイスである。スマートデバイス２００は、公衆網通信部２１３を介して、他の機器と通話することができる。この際、制御部２０１はマイク２１４およびスピーカ２１５を介して音声信号の入力と出力を行うことで、通話を実現する。本実施形態では、公衆網通信部２１３はアンテナであり、制御部１０１は、アンテナを介して、公衆網に接続することができる。なお、通信部２１１および公衆網通信部２１３は、一つのアンテナで兼用することも可能である。以上、実施形態におけるスマートデバイス２００を説明した。

＜システム構成＞
図３は、スマートデバイス２００がネットワークを通じてデジタルカメラ１００の通信ＡＰＩを利用し、デジタルカメラ１００を制御するためのシステム構成を示す図である。

通信ＡＰＩを利用しデジタルカメラ１００を制御するためのシステム構成は３種類ある。

最初に、通信３０１に示すように、デジタルカメラ１００とスマートデバイス２００Ａがピア・ツー・ピアで接続する構成である。この時デジタルカメラ１００はＷｉ−ＦｉアクセスポイントとなってＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）を構築する。スマートデバイス２００ＡはＷｉ−Ｆｉクライアントとなりデジタルカメラ１００が構築したＬＡＮにジョインする。なお、本実施例においては通信３０１がＷｉ−Ｆｉで接続されている例をあげたが、Ｅｔｈｅｒｎｅｔなどのような有線接続であってもよい。

次に、ネットワークルータ３０２、通信３０３、３０４に示すように、デジタルカメラ１００とスマートデバイス２００Ａが、ネットワークルータ３０２を経由して接続する構成である。この時ネットワークルータがＷｉ−ＦｉアクセスポイントとなってＬＡＮを構築する。デジタルカメラ１００とスマートデバイス２００ＡはＷｉ−Ｆｉクライアントとなり、ネットワークルータ３０２が構築したＬＡＮにジョインする。なお本実施例においては、通信３０３、３０４がＷｉ−Ｆｉで接続されている例をあげたが、Ｅｔｈｅｒｎｅｔなどのような有線接続であってもよい。

最後に、ネットワークルータ３０２、通信３０３、公衆回線３０５に示すように、スマートデバイス２００Ｂが公衆回線３０５を経由してデジタルカメラ１００と接続する構成である。前述の２つのシステム構成では、同一ＬＡＮ内での接続の構成となる。一方、この構成では、スマートデバイス２００Ｂは例えばＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）を使用することで、インターネットを通じ、ＬＡＮの外側の離れた場所からデジタルカメラ１００と通信することが可能である。なお、ＶＰＮは公知の技術であるため、ここでは説明を割愛する。

以上の３種類のシステム構成において、スマートデバイス２００はデジタルカメラ１００の通信ＡＰＩを利用できる。

＜デジタルカメラ１００が公開する通信ＡＰＩの基本構成＞
図４、図５は、スマートデバイス２００などの外部機器からデジタルカメラ１００を制御するための通信ＡＰＩの構成を示す図である。

デジタルカメラ１００は、スマートデバイス２００などの外部機器からデジタルカメラ１００を制御するための通信ＡＰＩを公開している。このＡＰＩを用いて要求を受け付けることで、本実施形態のデジタルカメラ１００は、不揮発性メモリ１０３に記録されたデバイス情報や、記録媒体１１０などに保存されたコンテンツファイルを、通信部１１１を介して外部機器へ送信する。コンテンツファイルとは、デジタルカメラ１００が生成して記録媒体１１０や不揮発性メモリ１０３に保存する画像ファイルのことであり、本実施形態では、撮像した静止画ファイルや動画ファイルのことを指す。

この通信ＡＰＩに対応するプログラムは、予め不揮発性メモリ１０３に保存されている。制御部１０１は、通信部１１１を介して外部機器との通信が確立すると、通信ＡＰＩに対応するプログラムを作業用メモリ１０４に展開し、外部装置からの通信ＡＰＩを用いたリクエストを待つ。制御部１０１が外部機器から通信ＡＰＩを用いたリクエストを検知すると、通信ＡＰＩの種類に応じた処理を実行し、その結果をレスポンスとして外部機器に返却する。なお、通信ＡＰＩに対応するプログラムはデジタルカメラ１００が規定した通信プロトコル上で実行され、外部機器は規定された通信プロトコルを用いてデジタルカメラ１００と通信を行い、通信ＡＰＩを用いてリクエストする。本実施形態では、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）上で本通信ＡＰＩに対応するプログラムが実行される。すなわち、デジタルカメラ１００はＨＴＴＰサーバとして機能する。すなわち、本実施形態では、通信ＡＰＩをＷｅｂＡＰＩとして実装する場合を例に挙げて説明する。

なお、通信プロトコルは、ＨＴＴＰに限るものではなく、他のプロトコルであっても構わない。また、ＨＴＴＰプロトコル自体は広く利用されているものであるので、ここでの説明は割愛する。

ＨＴＴＰにおける通信ＡＰＩに対応するプログラムの実行方法については、以下の手順で実現される。

まず、外部機器が通信ＡＰＩとして公開されるＵＲＬに対して、ＨＴＴＰリクエストボディにアクセス先の通信ＡＰＩの仕様に応じた必要な指示情報をテキストデータで記述する。そして、ＨＴＴＰメソッドであるＧＥＴ（取得）、ＰＯＳＴ（生成）、ＰＵＴ（更新）、ＤＥＬＥＴＥ（削除）の４メソッドのいずれかを用いてデジタルカメラ１００に送信する。

これを受けたデジタルカメラ１００はＵＲＬとＨＴＴＰメソッドとＨＴＴＰリクエストボディの指示情報の内容に基づいて処理を行い、その結果をＨＴＴＰレスポンスヘッダと共にＨＴＴＰレスポンスボディに付加して、外部機器に返却する。以上の手順で実現される。なお、ＨＴＴＰレスポンスヘッダはＨＴＴＰステータスコードを含むとする。

また、通信ＡＰＩにおいて、ＨＴＴＰリクエストボディとＨＴＴＰレスポンスボディに記述するデータは、データ記述言語の１つであるＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）によって表現される。各通信ＡＰＩには、それぞれの機能に応じたＪＳＯＮ構文の仕様が規定されており、デジタルカメラ１００やスマートデバイス２００は、それに則ってリクエストの指示やレスポンスの解析を行う。

なお、本実施例ではＪＳＯＮを用いているが、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）であってもよいし、独自フォーマットで定義されたテキストデータやバイナリデータを用いてもよい。

次に、通信ＡＰＩの構成を詳細に説明する。

以下の説明では、説明を簡単にするために、インターフェイスそのものだけでなく、通信ＡＰＩに対応するサービスやそれを実現するプログラムも、単にＡＰＩや通信ＡＰＩとも記載する。すなわち、ＡＰＩに対応するサービスを実現するプログラムを実行することをＡＰＩを実行する、などと記載し、ＡＰＩを介して対応するサービスの実行をリクエストすることをＡＰＩをリクエストする、などと記載する。

図４は、通信ＡＰＩの基本構成を説明する図である。

まず、本実施形態における通信ＡＰＩで使用するＨＴＴＰメソッドについて説明する。本実施形態における通信ＡＰＩで使用するＨＴＴＰメソッドは、ＧＥＴ４０１、ＰＯＳＴ４０２、ＰＵＴ４０３、ＤＥＬＥＴＥ４０４の４種類のみである。ＨＴＴＰの規格としては他のメソッドも存在するが、取得、生成、更新、削除といった、ほとんど全てのコンピュータソフトウェアが持つ永続的な４つの基本機能に限定している。なお、本通信ＡＰＩにおける４メソッドのそれぞれの意味は以下の通りである。

ＧＥＴ４０１は、コンテンツ（画像ファイル）の取得、カメラの情報や状態の取得、設定項目の能力値や設定値を取得する場合に使用する。

ＰＯＳＴ４０２は、外部装置からデジタルカメラ１００に対してコンテンツファイルなどデータの保存、撮影の実行やズーム操作など、カメラの機能を実行する場合に使用する。

ＰＵＴ４０３は、デジタルカメラ１００のメニュー設定や撮影パラメータ設定など、設定値を変更する場合に使用する。

ＤＥＬＥＴＥ４０４は、コンテンツの削除や、設定値を初期化する場合に使用する。

上記４メソッドに絞ることで、複雑なＨＴＴＰメソッドの制御を必要としない。そのため、デジタルカメラ１００を制御するためのスマートデバイス２００の制御プログラムを作成するプログラマは、最低限かつ頻繁に活用するＨＴＴＰメソッドを使用するだけでプログラムを作成することができる。

次に、本実施形態における通信ＡＰＩのトップＵＲＬについて説明する。トップＵＲＬとは、クライアントがデジタルカメラ１００をコントロールする際に、最初にアクセスするＵＲＬとして規定されるＵＲＬである。コントローラは必ずこのトップＵＲＬにアクセスしてから、カメラのリモートコントロールのための他のＡＰＩを利用する必要がある。

図４のＵＲＬ４０５は通信ＡＰＩのトップＵＲＬである。トップＵＲＬのホスト名、ドメイン名は、デジタルカメラ１００に割り当てられたＩＰアドレスとポート番号で構成される。それに続き、通信ＡＰＩを示すディレクトリ、さらに通信ＡＰＩのバージョンを示すディレクトリがその後に続く構成になっている。例えば、デジタルカメラ１００に割り振られたＩＰアドレスが１９２．１６８．１．１であり、ポート番号が８０８０であった場合のトップＵＲＬは、
ｈｔｔｐ：／／１９２．１６８．１．１：８０８０／ａｐｉ／ｖｅｒ１
となる。

ＨＴＴＰクライアントであるスマートデバイス２００が、ＨＴＴＰサーバであるデジタルカメラ１００が公開する通信ＡＰＩのトップＵＲＬをＧＥＴ４０１でリクエストすると、デジタルカメラ１００はＡＰＩ４０６に示すレスポンスボディ（ＪＳＯＮ）を返す。ここには、デジタルカメラ１００が対応している通信ＡＰＩの一覧が記述されている。なお特徴的なのは、各ＵＲＬに対して、どのＨＴＴＰメソッドが対応しているかがわかるＪＳＯＮ構文になっている点である。トップＵＲＬにアクセスすることで、スマートデバイス２００は、デジタルカメラ１００が対応している通信ＡＰＩの種類を知ることができる。

次に、ＡＰＩ表４０７は通信ＡＰＩのカテゴリを示す表である。本実施形態における通信ＡＰＩは、機能の種類によってＵＲＬを複数のカテゴリに分類していることを示している。なお、表におけるＡＰＩカテゴリのＵＲＬ表記は、トップＵＲＬを省略した表記になっている。実際には、ＡＰＩカテゴリ４０８は、
ｈｔｔｐ：／／１９２．１６８．１．１：８０８０／ａｐｉ／ｖｅｒ１／ｄｅｖｉｃｅｉｎｆｏｒｍａｔｉｏｎ
となる。

次に、通信ＡＰＩの機能のカテゴライズについて説明する。まず、ＡＰＩカテゴリ４０８は、デジタルカメラ１００の固定情報を取得するカテゴリである。次に、ＡＰＩカテゴリ４０９は、デジタルカメラ１００の状態情報を取得するカテゴリである。次に、ＡＰＩカテゴリ４１０は、デジタルカメラ１００のメニュー設定の取得や変更、メニュー機能を実行するカテゴリである。次に、ＡＰＩカテゴリ４１１は、デジタルカメラ１００の撮影機能を実行するカテゴリである。次に、ＡＰＩカテゴリ４１２は、デジタルカメラ１００の撮影パラメータの設定を取得、変更するカテゴリである。次に、ＡＰＩカテゴリ４１３は、デジタルカメラ１００が出力するスルー画を取得するカテゴリである。次に、ＡＰＩカテゴリ４１４は、デジタルカメラ１００が発行するイベント情報を取得するカテゴリである。次に、ＡＰＩカテゴリ４１５は、デジタルカメラ１００に装着されたメディアに保存されたコンテンツを取得するカテゴリである。

以上のように通信ＡＰＩがＵＲＬでカテゴライズされることにより、デジタルカメラ１００を制御するためのスマートデバイス２００の制御プログラムを作成するプログラマは、実行したい通信ＡＰＩがどのＵＲＬにあるのかが一目瞭然になるのが特徴である。

なお、個々の通信ＡＰＩは、上記のＡＰＩカテゴリ以下のディレクトリにＵＲＬが規定されている。

以上が、ＡＰＩの基本的な構成の説明である。

続いて、本実施形態における特徴となるデジタルカメラ１００のスルー画を取得するＡＰＩについて説明する。

＜デジタルカメラ１００のスルー画を取得するＡＰＩ＞
図５のＡＰＩ表５００は、デジタルカメラ１００のスルー画（リモート用ライブビュー画像）を取得するＡＰＩ群を示した表であり、図４のＡＰＩカテゴリ４１３に属するＡＰＩを示す。

ＡＰＩ５０１は、デジタルカメラ１００のスルー画の生成の開始と終了を指示するＡＰＩである。リクエストボディにスルー画のサイズとデジタルカメラ１００の表示部１０６にスルー画を表示するか否かの指示を記述して本ＡＰＩをＰＯＳＴ４０２で実行すると、デジタルカメラ１００は指示された内容に従ってスルー画の生成を開始および停止する。

ＡＰＩ５０２は、デジタルカメラ１００のスルー画を１フレーム取得するＡＰＩである。本ＡＰＩをＧＥＴ４０１で実行すると、ＡＰＩ５０１で設定したスルー画を１フレーム取得できる。

ＡＰＩ５０３は、デジタルカメラ１００のスルー画をチャンク送信で取得するＡＰＩである。チャンク送信（Ｃｈｕｎｋｅｄ Ｔｒａｎｓｆｅｒ）とは、ＨＴＴＰ１．１（ＲＦＣ２６１６）で定義されているデータ転送メカニズムの１つである。チャンク送信は、事前にレスポンスのデータ全体のサイズが不明であっても、データの塊（ブロック）ごとにサイズを記してレスポンスを返していく送信方法である。ＡＰＩ５０３はＡＰＩ５０２と比べて、データ容量の合計がわからない場合やデータを連続して取得する場合等に効果的である。詳細なメカニズムについては公知の技術であるためここでの説明は割愛する。本ＡＰＩをＧＥＴ４０１で実行すると、ＡＰＩ表５００に示すように、スルー画のサイズ情報、スルー画の実データの順でスルー画が送信され続ける。本実施形態では、スルー画は１フレームずつスマートデバイス２００に送信されているとする。また、本ＡＰＩをＤＥＬＥＴＥ４０４で実行すると、ＡＰＩ表５００の最後の行に示すように、デジタルカメラ１００はスルー画のサイズ情報が０と送信し、スルー画のチャンク送信を停止する。

ここで、デジタルカメラ１００に何らかのエラーが発生し、スルー画を生成できない場合について説明する。対向機がデジタルカメラ１００に対してＡＰＩ５０２を実行した場合、デジタルカメラ１００はリクエストに対するレスポンスとしてスルー画を１フレーム送信する。そのため、ライブビュー中に、例えばデジタルカメラ１００に何らかのエラーが発生している場合、デジタルカメラ１００はＨＴＴＰレスポンスヘッダにそのエラーであることを示す情報を格納することで、対向機にエラーが発生していることを通知できる。さらに、ＨＴＴＰレスポンスヘッダにエラーであることを示すためのコードがＨＴＴＰの規格に定義されている。また、ＨＴＴＰレスポンスヘッダはＨＴＴＰ通信では必ず参照する。これによりスマートデバイス２００はＨＴＴＰレスポンスヘッダを参照することで、デジタルカメラ１００のエラーが発生したか否かを特別なアルゴリズムを必要することなく判定できる。

これに対して、対向機がデジタルカメラ１００に対してＡＰＩ５０３を実行した場合、デジタルカメラ１００はリクエストに対するレスポンスとして、ＨＴＴＰレスポンスヘッダを送信後にＨＴＴＰレスポンスボディとしてスルー画を連続して送信し続ける。チャンク送信方式ではスルー画を送信している途中に、デジタルカメラ１００はＨＴＴＰレスポンスヘッダを送信することはできない。そのため、ライブビュー中に、デジタルカメラ１００に何らかのエラーが発生した場合でも、デジタルカメラ１００はＨＴＴＰレスポンスヘッダではそのエラーの内容を通知することはできない。また、一つの解決方法として、ＨＴＴＰレスポンスボディまたはスルー画のデータ構造にエラーの内容を含めるためのデータ領域を作成し、対向機がそのデータ領域を解析するという方法がある。しかしながら、この方法だと対向機はＨＴＴＰレスポンスボディまたはスルー画を解析する必要がある。そのため対向機でＨＴＴＰレスポンスボディ（スルー画）を解析する方法は、対向アプリケーションを開発する際の実装負荷を増加させる。

本実施形態では、チャンク送信方式でも、対向機であるスマートデバイス２００がＨＴＴＰレスポンスボディまたはスルー画を解析することなく、デジタルカメラ１００はスルー画を生成できないことを対向機のユーザに通知する。このために、本実施形態におけるチャンク送信ではデジタルカメラ１００はスルー画を生成できない場合、ダミー画像を送信する。

＜本実施形態におけるスルー画を１フレームずつ取得する方法の説明＞
まず、チャンク送信に対してスルー画を１フレームずつ取得する方法について説明する。図６Ａは、図５に示す通信ＡＰＩ５０２を実行した際の処理の流れを示すシーケンス図の一例である。図７Ａ（ａ）〜（ｂ）はライブビュー中のスマートデバイス２００のＵＩ画面の一例を示した図である。

図６ＡのステップＳ６０１Ａ、Ｓ６０２Ａは、ＡＰＩ５０１を実行した際のシーケンスである。図６ＡのステップＳ６０３Ａ、Ｓ６０４Ａ、Ｓ６０５Ａ、Ｓ６０６Ａ、Ｓ６０７ＡはＡＰＩ５０２を実行した際のシーケンスである。

ステップＳ６０１Ａにて、スマートデバイス２００の制御部２０１は、プログラム処理により作業用メモリ２０４に記録されたスルー画の生成を開始するための値を取得する。そして制御部２０１は、スルー画の生成を開始するための値をリクエスト用ＪＳＯＮ構文に基づいたデータセットに成形してＨＴＴＰリクエストボディに記述し、通信部２１１を介してデジタルカメラ１００にＡＰＩ５０１をＰＯＳＴ４０２でリクエストする。なお本ステップにおいて、制御部２０１はＡＰＩ５０１の仕様に則り、スルー画のサイズ情報、およびデジタルカメラ１００の表示部１０６にスルー画を表示するか否かを指示している。デジタルカメラ１００の制御部１０１が通信部１１１を介して、このリクエストを受信したことを検知すると、リクエストボディに記述されたＪＳＯＮ構文を解析する。そして、制御部１０１はスマートデバイス２００によってリクエストされたスルー画のサイズおよびデジタルカメラ１００の表示部１０６にスルー画を表示するか否かの指示に従って、スルー画の生成処理を開始する。制御部１０１は生成されたスルー画を、逐次一時的に作業用メモリ１０４に記録する。

ステップＳ６０２Ａにて、デジタルカメラ１００の制御部１０１は、レスポンスの値をＪＳＯＮ構文に基づいたデータセットに成形してＨＴＴＰレスポンスボディに記述し、レスポンスとして通信部１１１を介してスマートデバイス２００に送信する。

ステップＳ６０３Ａにて、スマートデバイス２００の制御部２０１は、通信部２１１を介してデジタルカメラ１００にＡＰＩ５０２をＧＥＴ４０１でリクエストする。

ステップＳ６０４Ａにて、デジタルカメラ１００の制御部１０１が通信部１１１を介して、このリクエストを受信したことを検知すると、作業用メモリ１０４より逐次一時的に記録されるスルー画を取得し、レスポンス用データセットに成形する。そして、制御部１０１は成形したデータセットをＨＴＴＰレスポンスボディに記述し、通信部１１１を介してスマートデバイス２００に送信する。

なお、スマートデバイス２００より繰り返しＡＰＩ５０２が実行され、スマートデバイス２００上でのライブビュー表示を実現する。例えば、図７Ａ（ａ）の画面７０１Ａに示すように、ライブビュー表示はスマートデバイス２００の表示部２０６に表示される。

ここで、デジタルカメラ１００の制御部１０１がスルー画を生成できない場合（スルー画生成不可区間６９０）について説明する。たとえば、表示部１０６に撮影パラメータの設定を変更するためのメニューを表示している場合、および作業用メモリ１０４にスルー画を保持できる容量がない場合、デジタルカメラ１００の制御部１０１はスルー画を生成しない。他にも、たとえば、記録媒体１１０に保存している画像の現像処理などをおこなっている場合、およびその他スルー画の生成を阻害する処理が実行されている場合も、デジタルカメラ１００の制御部１０１はスルー画を生成できない。

ステップＳ６０５Ａにて、スマートデバイス２００の制御部２０１は、通信部２１１を介してデジタルカメラ１００にＡＰＩ５０２をＧＥＴ４０１でリクエストする。

ステップＳ６０６Ａにて、デジタルカメラ１００の制御部１０１が通信部１１１を介してこのリクエストを受信したことを検知すると、スルー画を生成できないことを記述したエラーメッセージを含むレスポンス用データセットを成形する。そして、制御部１０１は成形したデータセットをレスポンスボディに記述し、通信部１１１を介してスマートデバイス２００に送信する。スマートデバイス２００の制御部２０１はエラーメッセージを受信した場合、ＨＴＴＰレスポンスヘッダを参照することで、デジタルカメラ１００にエラーが発生していることを判定する。そして制御部２０１は、必要に応じて、ＨＴＴＰレスポンスボディを参照し、エラーの内容等を取得する。このとき、スマートデバイス２００の制御部２０１は図７Ａ（ｂ）に示すように、メッセージ７０４Ａを表示部２０６に表示する。本実施形態において、制御部２０１は図７Ａ（ｂ）の画面７０３Ａに示すように、スルー画生成不可区間６９０より前に取得したスルー画を表示する。このスルー画はスマートデバイス２００の作業用メモリ２０４に保持されている。本実施形態ではスマートデバイス２００は上記のようにエラーメッセージとスルー画の表示を行ったが、これに限る必要はない。例えば、スマートデバイス２００はメッセージ７０４Ａを画面７０３Ａに重畳して表示することで、エラー発生をユーザに報知してもよい。

以上、スルー画を１フレームずつ取得する方法について説明した。

＜本実施形態におけるチャンク送信の説明＞
図６Ｂは、図５に示す通信ＡＰＩ５０３を実行した際の処理の流れを示すシーケンス図の一例である。図７Ｂ（ａ）〜（ｃ）はライブビュー中のスマートデバイス２００のＵＩ画面の一例を示した図である。

図６ＢのステップＳ６０１Ｂ、Ｓ６０２Ｂは、ＡＰＩ５０１を実行した際のシーケンスである。図６ＢのステップＳ６０３Ｂ、Ｓ６０４Ｂ、Ｓ６０５Ｂ、Ｓ６０６Ｂ、Ｓ６０７ＢはＡＰＩ５０３を実行した際のシーケンスである。

ステップＳ６０１Ｂにて、スマートデバイス２００の制御部２０１は、プログラム処理により作業用メモリ２０４に記録されたスルー画の生成を開始するための値を取得する。そして制御部２０１は、スルー画の生成を開始するための値をリクエスト用ＪＳＯＮ構文に基づいたデータセットに成形してＨＴＴＰリクエストボディに記述し、通信部２１１を介してデジタルカメラ１００にＡＰＩ５０１をＰＯＳＴ４０２でリクエストする。なお本ステップにおいて、制御部２０１はＡＰＩ５０１の仕様に則り、スルー画のサイズ情報、およびデジタルカメラ１００の表示部１０６にスルー画を表示するか否かを指示している。デジタルカメラ１００の制御部１０１が通信部１１１を介して、このリクエストを受信したことを検知すると、リクエストボディに記述されたＪＳＯＮ構文を解析する。そして、制御部１０１はスマートデバイス２００によってリクエストされたスルー画のサイズおよびデジタルカメラ１００の表示部１０６にスルー画を表示するか否かの指示に従って、スルー画の生成処理を開始する。制御部１０１は生成されたスルー画を、逐次一時的に作業用メモリ１０４に記録する。

ステップＳ６０２Ｂにて、デジタルカメラ１００の制御部１０１は、レスポンスの値をＪＳＯＮ構文に基づいたデータセットに成形してＨＴＴＰレスポンスボディに記述し、レスポンスとして通信部１１１を介してスマートデバイス２００に送信する。

ステップＳ６０３Ｂにて、スマートデバイス２００の制御部２０１は、通信部２１１を介してデジタルカメラ１００にＡＰＩ５０３をＧＥＴ４０１でリクエストする。

ステップＳ６０４Ｂにて、デジタルカメラ１００の制御部１０１は通信部１１１を介して、このリクエストを受信したことを検知した場合、作業用メモリ１０４からスルー画を読み込む。制御部１０１は取得したスルー画を、レスポンス用データセットに成形する。そして、制御部１０１は成形したデータセットをＨＴＴＰレスポンスボディに記述し、通信部１１１を介してスマートデバイス２００に送信する。スマートデバイス２００の制御部２０１は受信したスルー画を図７Ｂ（ａ）の画面７０１Ｂに示すように表示部２０６にライブビュー表示する。デジタルカメラ１００の制御部１０１は作業用メモリ１０４に逐次一時的に記録したスルー画を順次スマートデバイス２００に送信する。

ここで、デジタルカメラ１００の制御部１０１がスルー画を生成できない場合（スルー画生成不可区間６９０）について説明する。例えば、表示部１０６に撮影パラメータの設定を変更するためのメニューを表示している場合、および作業用メモリ１０４にスルー画を保持できる容量がない場合、デジタルカメラ１００の制御部１０１はスルー画を生成できない。他にも、たとえば、記録媒体１１０に保存している画像の現像処理などを実行している場合、およびその他スルー画の生成を阻害する処理が実行している場合も、デジタルカメラ１００の制御部１０１はスルー画を生成できない。なお、ここでデジタルカメラ１００は表示部１０６に撮影パラメータの設定を変更するためのメニューを表示している場合は表示部１０６にメニューが表示されている。作業用メモリ１０４にスルー画を保持できる容量がない場合や記録媒体１１０に保存している画像の現像処理などを実行している場合等では、デジタルカメラ１００は表示部１０６に、スルー画を生成できない旨の警告を表示する。

また、前述したように、ＡＰＩ５０３を実行した場合、デジタルカメラ１００はＨＴＴＰレスポンスヘッダを利用してエラーの内容をスマートデバイス２００に送信することはできない。そこで、本実施形態ではデジタルカメラ１００はエラーの内容を通知するためのダミー画像をスマートデバイス２００に送信する。

ステップＳ６０５Ｂにて、デジタルカメラ１００の制御部１０１はダミー画像を生成して、レスポンス用データセットに成形する。そして、制御部１０１は成形したデータセットをＨＴＴＰレスポンスボディに記述し、通信部１１１を介して、スマートデバイス２００に送信する。例えば、デジタルカメラ１００はダミー画像として、図７Ｂ（ｂ）の画面７０２Ｂに示すようなエラーメッセージを記載した画像を生成する。これにより、スルー画生成不可区間６９０より前と同様に、デジタルカメラ１００は送信した画像をスマートデバイス２００の表示部２０６に表示させることでユーザにエラーの内容を通知できる。ここで、スマートデバイス２００は受信したスルー画を解析していない。本実施形態では、ダミー画像がエラーメッセージを記載した画像としたがこれに限る必要はない。たとえば、ダミー画像として、単に黒く塗りつぶされただけの画像でもよい。また、本実施形態においてデジタルカメラ１００の制御部１０１はダミー画像を、スルー画と同じ解像度および同じアスペクト比にして生成する。これにより、スマートデバイス２００の制御部２０１は、ダミー画像を受信しても画角調整等の処理を追加することなく、スムーズに表示を切り替えることができる。これにより、スマートデバイス２００の制御部２０１は、スルー画生成不可区間６９０においても、デジタルカメラ１００から受信したデータセットを解析することや画像の画角調整等の特別な処理を行う必要がない。

ステップＳ６０６Ｂにて、スマートデバイス２００の制御部２０１は、ライブビューを終了するために通信部２１１を介してデジタルカメラ１００にＡＰＩ５０３をＤＥＬＥＴＥ４０４でリクエストする。

ステップＳ６０７Ｂにて、デジタルカメラ１００の制御部１０１は通信部１１１を介して、このリクエストを受信したことを検知すると、スルー画のサイズ情報を０としてレスポンス用データセットを成形する。そして、制御部１０１は成形したデータセットをレスポンスボディに記述し、通信部１１１を介してスマートデバイス２００に送信する。このデータセットを受信したスマートデバイス２００はライブビュー表示を終了する。これによってデジタルカメラ１００およびスマートデバイス２００間のチャンク送信処理が終了する。

以上、本実施形態におけるチャンク送信について説明した。

次に、本実施形態におけるデジタルカメラ１００の動作の一例およびスマートデバイス２００の動作の一例について説明する。

図６Ｃは本実施形態におけるデジタルカメラ１００の動作の一例を示すフローチャートである。デジタルカメラ１００の制御部１０１は通信部１１１を介して、スマートデバイス２００からＧＥＴ４０１でリクエストされたことを検知したことをトリガに本処理を開始する。

ステップＳ６０１Ｃにて、制御部１０１は受信したリクエストのＡＰＩの種類について判定する。ＡＰＩ５０２によってリクエストされたと判定した場合、スルー画を１フレーム送信するため制御部１０１はステップＳ６０６Ｃに遷移する。この場合は、図６ＡのステップＳ６０３Ａに対応する。ＡＰＩ５０３によってリクエストされたと判定した場合、チャンク送信によってスルー画を送信するため、制御部１０１はステップＳ６０２Ｃに遷移する。この場合は、図６ＢのステップＳ６０３Ｂに対応する。

ステップＳ６０２Ｃにて、制御部１０１はスルー画を作業用メモリ１０４から読みこみ、スルー画からレスポンス用データを作成し、作業用メモリ１０４に記録する。

ステップＳ６０３Ｃにて、制御部１０１は通信部１１１を介して、スマートデバイス２００に作成したレスポンスデータを送信する。本ステップは、図６ＢのステップＳ６０４Ｂに対応する。

ステップＳ６０４Ｃにて、制御部１０１は通信部１１１を介して、スマートデバイス２００からチャンク送信を終了する指示を受信したか否かを判定する。スマートデバイス２００からチャンク送信を終了する指示を受信した場合、制御部１０１はステップＳ６０５Ｃに遷移する。スマートデバイス２００からチャンク送信を終了する指示を受信していない場合、制御部１０１はステップＳ６０２Ｃに戻り、チャンク送信を継続する。

ステップＳ６０５Ｃにて、制御部１０１は通信部１１１を介してスマートデバイス２００へチャンク送信を終了するためのレスポンス用データを送信する。

ステップＳ６０６Ｃにて、制御部１０１はスルー画を作業用メモリ１０４から読みこみ、スルー画からレスポンス用データを作成し、作業用メモリ１０４に記録する。

ステップＳ６０７Ｃにて、制御部１０１は通信部１１１を介して、スマートデバイス２００に作成したレスポンスデータを送信する。本ステップは、エラーが発生していない場合、図６ＡのステップＳ６０４Ａに対応する。

以上、本実施形態におけるデジタルカメラ１００の動作の一例について説明した。

次にスマートデバイス２００の動作の一例について説明する。図６Ｄは本実施形態におけるスマートデバイス２００の動作の一例を示すフローチャートである。スマートデバイス２００の制御部２０１は通信部２１１を介してデジタルカメラ１００にＧＥＴ４０１でリクエストした場合、本処理を開始する。

ステップＳ６０１Ｄにて、制御部２０１は送信したリクエストのＡＰＩの種類について判定する。ＡＰＩ５０２によってリクエストした場合、スルー画を１フレーム取得するため、制御部２０１はステップＳ６０７Ｄに遷移する。この場合は、図６ＡのステップＳ６０３Ａに対応する。ＡＰＩ５０３によってリクエストした場合、チャンク送信によってスルー画を取得するため、制御部２０１はステップＳ６０２Ｄに遷移する。この場合は、図６ＢのステップＳ６０３Ｂに対応する。

ステップＳ６０２Ｄにて、制御部２０１はレスポンス用データを受信したか否かを判定する。レスポンス用データを受信した場合、制御部２０１はステップＳ６０３Ｄに遷移する。レスポンス用データを受信していない場合、制御部２０１は本処理を繰り返す。本ステップは図６ＢのステップＳ６０４Ｄに対応する。

ステップＳ６０３Ｄにて、制御部２０１は受信したスルー画を表示部２０６に表示する。

ステップＳ６０４Ｄにて、制御部２０１はチャンク送信を終了するか否かを判定する。例えば制御部２０１はユーザから操作部２０５（タッチパネル等）を介してライブビューを終了する指示を受け付けた場合チャンク送信を終了すると判定する。チャンク送信を終了する場合、制御部２０１はステップＳ６０５Ｄに遷移する。チャンク送信を終了しない場合、制御部２０１はステップＳ６０３Ｄに戻りチャンク送信を継続する。

ステップＳ６０５Ｄにて、制御部２０１は通信部２１１を介してチャンク送信を終了するための指示をデジタルカメラ１００へ送信する。

ステップＳ６０６Ｄにて、制御部２０１は通信部２１１を介してチャンク送信を終了するためのレスポンス用データを受信したか否かを判定する。チャンク送信を終了するためのレスポンス用データを受信した場合、制御部２０１は処理を終了する。チャンク送信を終了するためのレスポンス用データを受信していない場合、制御部２０１は本ステップの処理を繰り返す。

ステップＳ６０７Ｄにて、スルー画を取得するため制御部２０１はレスポンス用データを受信したか否かを判定する。レスポンス用データを受信した場合、制御部２０１はステップＳ６０３Ｄに遷移する。レスポンス用データを受信していない場合、制御部２０１は本処理を繰り返す。本ステップは図６ＢのステップＳ６０４Ｄに対応する。

ステップＳ６０８Ｄにて、制御部２０１は受信したスルー画を表示部２０６に表示し、処理を終了する。

以上、スマートデバイス２００の動作の一例について説明した。なお、本実施形態におけるＡＰＩ５０２によるライブビュー表示の場合、スマートデバイス２００はスルー画を１フレーム取得した後自動的に再度ＡＰＩ５０２をＧＥＴ４０１でリクエストし、スルー画を１フレーム取得する処理を繰り返す。

以下、本実施形態におけるチャンク送信について、対向機のアプリケーションの実装負荷の低減の効果について説明する。

＜実施形態による対向機のアプリケーションの実装負荷の低減の効果＞
ここでは従来の方法と本実施形態におけるチャンク送信とを比較することで、対向機のアプリケーションの実装負荷の低減の効果について説明する。まず従来のスルー画を１フレームずつ取得する方法および従来の本実施形態を利用しないチャンク送信についてその課題を説明し、その後本実施形態におけるチャンク送信についてその効果を説明する。

まず、本実施形態におけるスルー画を１フレームずつ取得する方法におけるデジタルカメラ１００の動作の一例およびスマートデバイス２００の動作の一例を説明する。図８Ａは本実施形態におけるスルー画を１フレームずつ取得する場合におけるデジタルカメラ１００の動作の一例を示すフローチャートである。デジタルカメラ１００の制御部１０１は通信部１１１を介して、スマートデバイス２００からＡＰＩ５０２をＧＥＴ４０１でリクエストされたことを検知したことをトリガに本処理を開始する。このトリガは図６ＡのステップＳ６０３ＡおよびステップＳ６０５Ａに対応する。

ステップＳ８０１にて、制御部１０１はスルー画を生成できるか否かを判定する。スルー画を生成できない場合、制御部１０１はステップＳ８０２に遷移する。スルー画が生成できる場合、制御部１０１はステップＳ８０３に遷移する。

ステップＳ８０２にて、制御部１０１はスルー画を生成できない原因であるエラーの内容を検知する。

ステップＳ８０３にて、制御部１０１は、エラーが発生したことを通知するためのデータをＨＴＴＰレスポンスヘッダに記述してレスポンス用データを作成し、作業用メモリ１０４に記録する。ここで制御部１０１は、さらにエラーの具体的な内容をＨＴＴＰレスポンスボディに記述してレスポンス用データを作成してもよい。

ステップＳ８０４にて、制御部１０１はスルー画を作業用メモリ１０４から読みこみ、スルー画からレスポンス用データを作成し、作業用メモリ１０４に記録する。

ステップＳ８０５にて、制御部１０１は通信部１１１を介して、スマートデバイス２００に作成したレスポンスデータを送信する。本ステップは、エラーが発生していない場合、図６ＡのステップＳ６０３Ａに対応する。本ステップは、エラーが発生している場合、図６ＡのステップＳ６０６Ａに対応する。

以上、本実施形態におけるスルー画を１フレームずつ取得する場合におけるデジタルカメラ１００の動作の一例について説明した。

図８Ｂは本実施形態におけるスルー画を１フレームずつ取得する場合におけるスマートデバイス２００のフローチャートの一例である。スマートデバイス２００の制御部２０１は通信部２１１を介してデジタルカメラ１００にＡＰＩ５０２をＧＥＴ４０１でリクエストし、そのレスポンスとしてデジタルカメラ１００からスルー画を受信した場合、本処理を開始する。このトリガは図６ＡのステップＳ６０４ＡおよびステップＳ６０６Ａに対応する。

ステップＳ８５１にて、制御部２０１は受信したレスポンス用データを解析し、エラーが発生したことを通知するためのデータが含まれているか否かを判定する。例えば制御部２０１はレスポンス用データのＨＴＴＰレスポンスヘッダにエラーが発生したことを通知するためのデータが含まれているか否かを判定する。レスポンス用データにエラーが発生したことを通知するためのデータが含まれていると判定した場合、制御部２０１はステップＳ８５２に遷移する。レスポンス用データにエラーが発生したことを通知するためのデータが含まれていないと判定した場合、制御部２０１はステップＳ８５３に遷移する。

ステップＳ８５２にて、制御部２０１はステップＳ８５１において解析したエラーの内容を表示部２０６に表示する。例えば図７Ｂ（ｃ）に示すように、制御部２０１は画面７０３Ｂに、スルー画生成不可区間６９０より前に受信したスルー画を表示する。このスルー画はスマートデバイス２００の作業用メモリ２０４に保持されている。制御部２０１は画面７０３Ｂの下にエラーメッセージ７０４Ｂを表示する。他にも、例えば制御部２０１はエラーメッセージ７０４Ｂを画面７０２Ｂに重畳して表示することで、エラー発生をユーザに報知してもよい。このスルー画はスマートデバイス２００の作業用メモリ２０４に保持されている。なお受信したレスポンス用データのＨＴＴＰレスポンスボディにエラーの詳細な内容が含まれていた場合、制御部２０１はその内容を表示部２０６に表示してもよい。

ステップＳ８５３にて、解析の結果、受信したレスポンス用データにエラーが発生したことを通知するためのデータは含まれていないため、制御部２０１は受信したレスポンス用データに含まれるスルー画を表示する。

以上、本実施形態におけるスルー画を１フレームずつ取得する場合におけるスマートデバイス２００の動作の一例について説明した。このような場合、アプリケーションの実装において、デジタルカメラ１００が送信したデータを毎回解析するアルゴリズムをスマートデバイス２００は必要とする。

次に本実施形態を利用しない従来のチャンク送信におけるデジタルカメラ１００の動作の一例およびスマートデバイス２００の動作の一例を説明する。図９Ａは本実施形態を利用しない従来のチャンク送信におけるデジタルカメラ１００の動作の一例を示すフローチャートである。デジタルカメラ１００の制御部１０１は通信部１１１を介して、スマートデバイス２００からＡＰＩ５０３をＧＥＴ４０１でリクエストされたことを検知したことをトリガに本処理を開始する。このトリガは図６ＢのステップＳ６０３Ｂに対応する。

ステップＳ９０１にて、制御部１０１はスルー画を生成できるか否かを判定する。スルー画を生成できない場合、制御部１０１はステップＳ９０２に遷移する。スルー画が生成できる場合、制御部１０１はステップＳ９０３に遷移する。

ステップＳ９０２にて、制御部１０１はスルー画を生成できない原因であるエラーの内容を検知する。

ステップＳ９０３にて、制御部１０１は、エラーが発生したことを通知するためのデータをＨＴＴＰレスポンスボディに記述してレスポンス用データを作成し、作業用メモリ１０４に記録する。

ステップＳ９０４にて、制御部１０１はスルー画を作業用メモリ１０４から読みこみ、スルー画からレスポンス用データを作成し、作業用メモリ１０４に記録する。

ステップＳ９０５にて、制御部１０１は通信部１１１を介して、スマートデバイス２００へ作成したレスポンス用データを送信する。

ステップＳ９０６にて、制御部１０１は通信部１１１を介して、スマートデバイス２００からチャンク送信を終了する指示を受信したか否かを判定する。スマートデバイス２００からチャンク送信を終了する指示を受信した場合、制御部１０１はステップＳ９０７に遷移する。スマートデバイス２００からチャンク送信を終了する指示を受信していない場合、制御部１０１はステップＳ９０１に戻り、本処理を繰り返す。

ステップＳ９０７にて、制御部１０１は通信部１１１を介してスマートデバイス２００へチャンク送信を終了するためのレスポンス用データを送信する。

以上、本実施形態を利用しない場合のデジタルカメラ１００の動作の一例について説明した。

図９Ｂは本実施形態を利用しない従来のチャンク送信におけるスマートデバイス２００のフローチャートの一例である。スマートデバイス２００の制御部２０１は通信部２１１を介してデジタルカメラ１００にＡＰＩ５０３をＧＥＴ４０１でリクエストした場合、本処理を開始する。このトリガは図６ＢのステップＳ６０３Ｂに対応する。

ステップＳ９５０にて、制御部２０１はレスポンス用データを受信したか否かを判定する。レスポンス用データを受信した場合、制御部２０１はステップＳ９５１に遷移する。レスポンス用データを受信していない場合、制御部２０１はステップＳ９５０を繰り返す。ただし、所定の時間以上レスポンス用データを受信していない場合、制御部２０１はデジタルカメラ１００に何らかのエラーが発生したとして、表示部２０６にエラーを表示して処理を終了する。

ステップＳ９５１にて、制御部２０１は受信したレスポンス用データを解析し、エラーが発生したことを通知するためのデータが含まれているか否かを判定する。レスポンス用データにエラーが発生したことを通知するためのデータが含まれていると判定した場合、制御部２０１はステップＳ９５２に遷移する。レスポンス用データにエラーが発生したことを通知するためのデータが含まれていないと判定した場合、制御部２０１はステップＳ９５３に遷移する。

ステップＳ９５２にて、制御部２０１はステップＳ９５１において解析したエラーの内容を表示部２０６に表示する。例えば図７Ｂ（ｃ）に示すように、制御部２０１は画面７０３Ｂに、スルー画生成不可区間６９０より前に受信したスルー画を表示する。このスルー画はスマートデバイス２００の作業用メモリ２０４に保持されている。制御部２０１は画面７０３Ｂの下にエラーメッセージ７０４Ｂを表示する。他にも、例えば制御部２０１はエラーメッセージ７０４Ｂを画面７０２Ｂに重畳して表示することで、エラー発生をユーザに報知してもよい。このスルー画はスマートデバイス２００の作業用メモリ２０４に保持されている。

ステップＳ９５３にて、解析の結果、受信したレスポンス用データにエラーが発生したことを通知するためのデータは含まれていないため、制御部２０１は受信したレスポンス用データに含まれるスルー画を表示する。

ステップＳ９５４にて、制御部２０１はチャンク送信を終了するか否かを判定する。例えば制御部０１はユーザから操作部２０５（タッチパネル等）を介してライブビューを終了する指示を受け付けた場合チャンク送信を終了すると判定する。チャンク送信を終了する場合、制御部２０１はステップＳ９５５に遷移する。チャンク送信を終了しない場合、制御部２０１はステップＳ９０１に戻りチャンク送信を継続する。

ステップＳ９５５にて、制御部２０１は通信部２１１を介してチャンク送信を終了するための指示をデジタルカメラ１００へ送信する。

ステップＳ９５６にて、制御部２０１は通信部２１１を介してチャンク送信を終了するためのレスポンス用データを受信したか否かを判定する。チャンク送信を終了するためのレスポンス用データを受信した場合、制御部２０１は処理を終了する。チャンク送信を終了するためのレスポンス用データを受信していない場合、制御部２０１は本ステップの処理を繰り返す。

以上、本実施形態を利用しないチャンク送信におけるスマートデバイス２００の動作の一例について説明した。このような従来のチャンク送信では、アプリケーションの実装において、デジタルカメラ１００が送信したレスポンス用データを解析するアルゴリズムをスマートデバイス２００は必要とする。

最後に、従来のチャンク送信例に対して本実施形態を利用したチャンク送信におけるデジタルカメラ１００およびスマートデバイス２００の動作の一例について説明する。図１０Ａは本実施形態におけるデジタルカメラ１００の動作の一例を示すフローチャートである。デジタルカメラ１００の制御部１０１は通信部１１１を介して、スマートデバイス２００からＡＰＩ５０３をＧＥＴ４０１でリクエストされたことを検知したことをトリガに、本処理を開始する。このトリガは図６ＢのステップＳ６０３Ｂに対応する。

ステップＳ１００１にて、制御部１０１はスルー画を生成できるか否かを判定する。スルー画を生成できない場合、制御部１０１はステップＳ１００２に遷移する。スルー画を生成できる場合、制御部１０１はステップＳ１００３に遷移する。本ステップは図９ＡのステップＳ９０１と同様である。

ステップＳ１００２にて、制御部１０１はスルー画を生成できない原因であるエラーの内容を検知する。本ステップは図９ＡのステップＳ９０２と同様である。

ステップＳ１００３にて、制御部１０１は送信するデータとして、ダミー画像を生成して、作業用メモリ１０４に保存する。ここで制御部１０１はステップＳ１００２にて検知したエラーの内容を示すメッセージをダミー画像に含める。このメッセージはユーザが視覚可能なメッセージになるようにダミー画像に含まれる。なお、このダミー画像の生成するための処理はスルー画を読み込む処理よりも負荷の大きい処理ではない。また、ダミー画像の生成するための処理はあらかじめ用意されているエラーを通知するための画像を読み込む処理でもよい。この場合、エラーを通知するための画像は不揮発性メモリ１０３に記録されている。

ステップＳ１００４にて、スルー画を生成できるため、制御部１０１はスルー画を読みだして、レスポンスデータを生成し、作業用メモリ１０４に保存する。

ステップＳ１００５にて、制御部１０１は通信部１１１を介して、スマートデバイス２００に作業用メモリ１０４に保持しているレスポンスデータを送信して処理を終了する。

ステップＳ１００６にて、制御部１０１は通信部１１１を介して、スマートデバイス２００からチャンク送信を終了する指示を受信したか否かを判定する。スマートデバイス２００からチャンク送信を終了する指示を受信した場合、制御部１０１はステップＳ１００７に遷移する。スマートデバイス２００からチャンク送信を終了する指示を受信していない場合、制御部１０１はステップＳ１００１に戻り、本処理を繰り返す。

ステップＳ１００７にて、制御部１０１は通信部１１１を介してスマートデバイス２００へチャンク送信を終了するためのレスポンス用データを送信する。

以上、本実施形態を利用した場合のデジタルカメラ１００の動作の一例について説明した。

本実施形態におけるスマートデバイス２００の処理の流れについて図１０Ｂを用いて説明する。スマートデバイス２００の制御部２０１が通信部２１１を介してデジタルカメラ１００に、ＡＰＩ５０３をＧＥＴ４０１でリクエストし、そのレスポンスとしてスルー画を受信した場合、本フローチャートは開始される。このトリガは図６ＢのステップＳ６０４Ｂに対応する。

ステップＳ１０５０にて、制御部２０１はレスポンス用データを受信したか否かを判定する。レスポンス用データを受信した場合、制御部２０１はステップＳ１０５１に遷移する。レスポンス用データを受信していない場合、制御部２０１はステップＳ１０５０を繰り返す。ただし、所定の時間以上レスポンス用データを受信していない場合、制御部２０１はデジタルカメラ１００に何らかのエラーが発生したとして、表示部２０６にエラーを表示して処理を終了する。

ステップＳ１０５１にて、制御部２０１は受信したスルー画を表示部２０６に表示する。本ステップは図６ＢのステップＳ６０４Ｂに対応する。

ステップＳ１０５２にて、制御部２０１はチャンク送信を終了するか否かを判定する。例えば制御部２０１はユーザからライブビューを終了する指示を受け付けた場合チャンク送信を終了すると判定する。チャンク送信を終了する場合、制御部２０１はステップＳ１０５３に遷移する。チャンク送信を終了しない場合、制御部２０１はステップＳ１０５１に戻りチャンク送信を継続する。

ステップＳ１０５３にて、制御部２０１は通信部２１１を介してチャンク送信を終了するための指示をデジタルカメラ１００へ送信する。

ステップＳ１０５４にて、制御部２０１は通信部２１１を介してチャンク送信を終了するためのレスポンス用データを受信したか否かを判定する。チャンク送信を終了するためのレスポンス用データを受信した場合、制御部２０１は処理を終了する。チャンク送信を終了するためのレスポンス用データを受信していない場合、制御部２０１は本ステップの処理を繰り返す。

以上、本実施形態を利用した場合のスマートデバイス２００の動作の一例について説明した。

このように、従来のスルー画を１フレームずつ取得する方法および従来の本実施形態を利用しないチャンク送信では、対向機であるスマートデバイス２００は受信したレスポンス用データにエラーが含まれているか否かを解析する処理を必要とした。一方、本実施形態のチャンク送信によってスルー画を取得するＡＰＩにおいて、デジタルカメラ１００はスルー画を生成できない場合、代わりにダミー画像を送信する。スマートデバイス２００は受信したダミー画像をエラーが含まれているか否かを解析せず表示する。そのため本実施形態におけるチャンク送信では、アプリケーションの実装において、デジタルカメラ１００が送信したデータを解析するアルゴリズムをスマートデバイス２００は必要としない。これにより通信ＡＰＩを用いたアプリケーションの実装負荷を低減することができる。特にこの方法は、スマートデバイス２００側のアプリケーションの実装負荷を軽減することができる。さらにデジタルカメラ１００はダミー画像をエラーの内容を視覚的に表示する画像とすることで、スマートデバイス２００の処理を減らすことができる。

［その他の実施形態］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

Claims (16)

1. ライブビュー画像を生成する生成手段と、
   通信手段と、
   制御手段と
   を有する通信装置であって、
   前記制御手段が前記通信手段を介して外部装置から第一のリクエストを受信した場合、前記制御手段は、前記生成手段で生成されたライブビュー画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを繰り返し行い、
   前記生成手段でライブビュー画像の生成が行われている場合に、ライブビュー画像の生成が阻害される処理が行われた場合、前記制御手段は、前記生成手段で生成されなかったライブビュー画像の代わりに所定の画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを行い、
   前記制御手段が前記通信手段を介して前記外部装置から前記第一のリクエストを受信した場合にライブビュー画像から生成されたレスポンスは、チャンク送信（Ｃｈｕｎｋｅｄ Ｔｒａｎｓｆｅｒ）によって前記外部装置に送信される
   ことを特徴とする通信装置。
2. ライブビュー画像を生成する生成手段と、
   通信手段と、
   制御手段と
   を有する通信装置であって、
   前記生成手段でライブビュー画像が生成された場合に、前記制御手段が前記通信手段を介して外部装置から第二のリクエストを受信した場合、前記制御手段は、前記生成手段で生成されたライブビュー画像からレスポンスを生成する処理と、生成されたレスポンスを前記第二のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを行い、
   前記生成手段でライブビュー画像が生成されなかった場合に、前記制御手段が前記通信手段を介して前記外部装置から前記第二のリクエストを受信した場合、前記制御手段は、エラーの発生を通知するための情報を含むレスポンスを生成する処理と、生成されたレスポンスを前記第二のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを行い、
   前記制御手段が前記通信手段を介して前記外部装置から第一のリクエストを受信した場合、前記制御手段は、前記生成手段で生成されたライブビュー画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを繰り返し行い、
   前記生成手段でライブビュー画像の生成が行われている場合に、ライブビュー画像の生成が阻害される処理が行われた場合、前記制御手段は、前記生成手段で生成されなかったライブビュー画像の代わりに所定の画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを行う
   ことを特徴とする通信装置。
3. ライブビュー画像を生成する生成手段と、
   通信手段と、
   制御手段と
   を有する通信装置であって、
   前記制御手段が前記通信手段を介して外部装置から第一のリクエストを受信した場合、前記制御手段は、前記生成手段で生成されたライブビュー画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを繰り返し行い、
   前記生成手段でライブビュー画像の生成が行われている場合に、ライブビュー画像の生成が阻害される処理が行われた場合、前記制御手段は、前記生成手段で生成されなかったライブビュー画像の代わりに所定の画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを行い、
   前記生成手段で生成されたライブビュー画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とが繰り返し行われている場合に、ライブビュー画像の送信を終了する場合、前記制御手段は、ライブビュー画像の送信を終了するためのレスポンスを前記第一のリクエストに対応するレスポンスとして前記外部装置に送信する処理を行う
   ことを特徴とする通信装置。
4. 前記所定の画像は、前記生成手段でライブビュー画像が生成されなかった原因を通知するための情報を含むことを特徴とする請求項１から３のいずれか１項に記載の通信装置。
5. 前記所定の画像が記録されたメモリをさらに有することを特徴とする請求項１から４のいずれか１項に記載の通信装置。
6. 前記通信装置はサーバとして動作し、前記外部装置はクライアントとして動作することを特徴とする請求項１から５のいずれか１項に記載の通信装置。
7. 前記所定の画像の解像度またはアスペクト比は、前記生成手段で生成されたライブビュー画像の解像度またはアスペクト比と同じであることを特徴とする請求項１から６のいずれか１項に記載の通信装置。
8. 前記通信手段で用いられる通信プロトコルは、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）であることを特徴とする請求項１から７のいずれか１項に記載の通信装置。
9. ライブビュー画像の生成は、撮影パラメータの設定が変更される場合、記録媒体に保存されている画像の現像処理が行われている場合、ライブビュー画像を保持できる容量がメモリにない場合のいずれかにおいて阻害されることを特徴とする請求項１から８のいずれか１項に記載の通信装置。
10. 前記生成手段で生成されたライブビュー画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とが繰り返し行われている場合に、ライブビュー画像の送信を終了することを要求するリクエストを受信した場合、前記制御手段は、ライブビュー画像の送信を終了することを特徴とする請求項１から９のいずれか１項に記載の通信装置。
11. ライブビュー画像を生成する生成手段と、通信手段とを有する通信装置の制御方法であって、
    第一のリクエストを前記通信手段を介して外部装置から受信するステップと、
    前記通信手段を介して外部装置から第一のリクエストを受信した場合は、前記生成手段で生成されたライブビュー画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを繰り返し行うステップと、
    前記生成手段でライブビュー画像の生成が行われている場合に、ライブビュー画像の生成が阻害される処理が行われた場合は、前記生成手段で生成されなかったライブビュー画像の代わりに所定の画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを行うステップと
    を有し、
    前記通信手段を介して前記外部装置から前記第一のリクエストを受信した場合にライブビュー画像から生成されたレスポンスは、チャンク送信（Ｃｈｕｎｋｅｄ Ｔｒａｎｓｆｅｒ）によって前記外部装置に送信されることを特徴とする制御方法。
12. ライブビュー画像を生成する生成手段と、通信手段とを有する通信装置のコンピュータに、
    第一のリクエストを前記通信手段を介して外部装置から受信するステップと、
    前記通信手段を介して外部装置から第一のリクエストを受信した場合は、前記生成手段で生成されたライブビュー画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを繰り返し行うステップと、
    前記生成手段でライブビュー画像の生成が行われている場合に、ライブビュー画像の生成が阻害される処理が行われた場合は、前記生成手段で生成されなかったライブビュー画像の代わりに所定の画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを行うステップと
    を実行させるためのプログラムであって、
    前記通信手段を介して前記外部装置から前記第一のリクエストを受信した場合にライブビュー画像から生成されたレスポンスは、チャンク送信（Ｃｈｕｎｋｅｄ Ｔｒａｎｓｆｅｒ）によって前記外部装置に送信されることを特徴とするプログラム。
13. ライブビュー画像を生成する生成手段と、通信手段とを有する通信装置の制御方法であって、
    前記生成手段でライブビュー画像が生成された場合に、前記通信手段を介して外部装置から第二のリクエストを受信した場合、前記生成手段で生成されたライブビュー画像からレスポンスを生成する処理と、生成されたレスポンスを前記第二のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを行うステップと、
    前記生成手段でライブビュー画像が生成されなかった場合に、前記通信手段を介して前記外部装置から前記第二のリクエストを受信した場合、エラーの発生を通知するための情報を含むレスポンスを生成する処理と、生成されたレスポンスを前記第二のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを行うステップと、
    前記通信手段を介して前記外部装置から第一のリクエストを受信した場合、前記生成手段で生成されたライブビュー画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを繰り返し行うステップと、
    前記生成手段でライブビュー画像の生成が行われている場合に、ライブビュー画像の生成が阻害される処理が行われた場合、前記生成手段で生成されなかったライブビュー画像の代わりに所定の画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを行うステップと
    を有することを特徴とする制御方法。
14. ライブビュー画像を生成する生成手段と、通信手段とを有する通信装置のコンピュータに、
    前記生成手段でライブビュー画像が生成された場合に、前記通信手段を介して外部装置から第二のリクエストを受信した場合、前記生成手段で生成されたライブビュー画像からレスポンスを生成する処理と、生成されたレスポンスを前記第二のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを行うステップと、
    前記生成手段でライブビュー画像が生成されなかった場合に、前記通信手段を介して前記外部装置から前記第二のリクエストを受信した場合、エラーの発生を通知するための情報を含むレスポンスを生成する処理と、生成されたレスポンスを前記第二のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを行うステップと、
    前記通信手段を介して前記外部装置から第一のリクエストを受信した場合、前記生成手段で生成されたライブビュー画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを繰り返し行うステップと、
    前記生成手段でライブビュー画像の生成が行われている場合に、ライブビュー画像の生成が阻害される処理が行われた場合、前記生成手段で生成されなかったライブビュー画像の代わりに所定の画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを行うステップと
    を実行させるためのプログラム。
15. ライブビュー画像を生成する生成手段と、通信手段とを有する通信装置の制御方法であって、
    前記通信手段を介して外部装置から第一のリクエストを受信した場合、前記生成手段で生成されたライブビュー画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを繰り返し行うステップと、
    前記生成手段でライブビュー画像の生成が行われている場合に、ライブビュー画像の生成が阻害される処理が行われた場合、前記生成手段で生成されなかったライブビュー画像の代わりに所定の画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを行うステップと、
    前記生成手段で生成されたライブビュー画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とが繰り返し行われている場合に、ライブビュー画像の送信を終了する場合、ライブビュー画像の送信を終了するためのレスポンスを前記第一のリクエストに対応するレスポンスとして前記外部装置に送信する処理を行うステップと
    を有することを特徴とする制御方法。
16. ライブビュー画像を生成する生成手段と、通信手段とを有する通信装置のコンピュータに、
    前記通信手段を介して外部装置から第一のリクエストを受信した場合、前記生成手段で生成されたライブビュー画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを繰り返し行うステップと、
    前記生成手段でライブビュー画像の生成が行われている場合に、ライブビュー画像の生成が阻害される処理が行われた場合、前記生成手段で生成されなかったライブビュー画像の代わりに所定の画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とを行うステップと、
    前記生成手段で生成されたライブビュー画像からレスポンスを生成する処理と、生成されたレスポンスを前記第一のリクエストに対応するレスポンスとして前記通信手段を介して前記外部装置に送信する処理とが繰り返し行われている場合に、ライブビュー画像の送信を終了する場合、ライブビュー画像の送信を終了するためのレスポンスを前記第一のリクエストに対応するレスポンスとして前記外部装置に送信する処理を行うステップと
    を実行させるためのプログラム。

Images