WO2018203437A1 - 通信システム、並びに、通信装置及びその制御方法及びプログラム - Google Patents

Abstract

本発明は、プル転送型の通信プロトコルにおいて、サーバ側にてユーザの望むタイミングで情報の転送を中断させることを可能にする。このため、クライアントは、コンテンツ要求を前記サーバに送信する第１の要求部とを有し、サーバは第１の要求部により要求されたコンテンツを前記クライアントに送信する第１の応答部とを有する。また、クライアントは、更に、サーバに対して、所定の状態になった場合に応答するように要求する第２の要求部を有し、サーバは、更に、第２の要求部による前記要求を受信した場合、前記所定の状態にならない場合に応答を保留し、前記所定の状態になった場合に前記応答として前記クライアントに送信する第２の応答部を有する。

Description

通信システム、並びに、通信装置及びその制御方法及びプログラム

　本発明は通信システム、並びに、通信装置及びその制御方法及びプログラムに関するものである。

　デジタルカメラなどの画像処理装置（もしくは撮像装置）の通信機能の進歩に伴い、例えばデジタルカメラとＰＣ、携帯電話などが通信を行い、コンテンツを送受信することができるようになっている。そして現在では、ＨＴＴＰのようなサーバ・クライアントのシステムを用いて、カメラがサーバ側となってリモート撮影を実現することも可能である。サーバ・クライアントシステムのようなシステムにおいては、サーバから自発的にクライアントに何らかの通知を行うことについては一定の制限があることが多い。

　この点については、まずクライアントからリクエストを送信し、サーバがその応答の保留状態を維持することにより、必要なタイミングでサーバが自発的にクライアントに通知を行うことが考えられる。その手法として、予め状態通知用のリクエストを送信して、サーバのステータスが変化したタイミングでレスポンスを返すといった方法がある（特許文献１）。

特開２０１３－２１５２６号公報

　しかし特許文献１の方法では、サーバのステータス通知のみが想定されている。サーバ・クライアントシステムの応用範囲によっては、ステータス以外の通知を行いたい場合もある。

　この課題を解決するため、例えば本発明の通信システムは以下の構成を備える。すなわち、
　クライアント及び当該クライアントから要求に応じた情報を送信するサーバとを含む通信システムであって、
　前記クライアントは、
　　　　コンテンツ要求を前記サーバに送信する第１の要求手段と、
　を有し、
　前記サーバは、
　　　　前記第１の要求手段により要求されたコンテンツを前記クライアントに送信する第１の応答手段とを有し、
　前記クライアントは、更に、
　　　　前記サーバに対して、所定の状態になった場合に応答するように要求する第２の要求手段を有し、
　前記サーバは、更に、
　　　　前記第２の要求手段による前記要求を受信した場合、前記所定の状態にならない場合に応答を保留し、前記所定の状態になった場合に前記応答として前記クライアントに送信する第２の応答手段を有することを特徴とする。

　本発明によれば、サーバ側にてユーザの望むタイミングで情報の転送を中断させることが可能になる。

　本発明のその他の特徴及び利点は、添付図面を参照とした以下の説明により明らかになるであろう。なお、添付図面においては、同じ若しくは同様の構成には、同じ参照番号を付す。

　添付図面は明細書に含まれ、その一部を構成し、本発明の実施の形態を示し、その記述と共に本発明の原理を説明するために用いられる。
実施形態におけるデジタルカメラのブロック構成図。 実施形態におけるデジタルカメラの正面図。 実施形態におけるデジタルカメラの背面図。 実施形態におけるスマートデバイスの構成を示すブロック構成図。 実施形態におけるデジタルカメラが用意したＡＰＩの一覧を示す図。 実施形態におけるデジタルカメラが用意したＡＰＩの一覧を示す図。 第１の実施形態におけるデジタルカメラとスマートデバイス間の通信シーケンスの一例を示す図。 実施形態におけるデジタルカメラのユーザインターフェースの画面を示す図。 実施形態におけるデジタルカメラのユーザインターフェースの画面を示す図。 実施形態におけるデジタルカメラのユーザインターフェースの画面を示す図。 第１の実施形態におけるデジタルカメラの処理手順を示すフローチャート。 第１の実施形態におけるデジタルカメラの処理手順を示すフローチャート。 第１の実施形態におけるスマートデバイスの処理手順を示すフローチャート。 第２の実施形態におけるデジタルカメラとスマートデバイス間の通信シーケンスの一例を示す図。 第２の実施形態におけるデジタルカメラとスマートデバイス間の通信シーケンスの一例を示す図。 第２の実施形態におけるデジタルカメラの処理手順を示すフローチャート。 第２の実施形態におけるデジタルカメラの処理手順を示すフローチャート。 第２の実施形態におけるスマートデバイスの処理手順を示すフローチャート。 第２の実施形態におけるスマートデバイスの処理手順を示すフローチャート。 第３の実施形態におけるデジタルカメラとスマートデバイス間の通信シーケンスの一例を示す図。 第３の実施形態におけるデジタルカメラとスマートデバイス間の通信シーケンスの一例を示す図。 第３の実施形態におけるデジタルカメラの処理手順を示すフローチャート。 第３の実施形態におけるデジタルカメラの処理手順を示すフローチャート。 第３の実施形態におけるスマートデバイスの処理手順を示すフローチャート。 第３の実施形態におけるスマートデバイスの処理手順を示すフローチャート。

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

　［第１の実施形態］
　＜デジタルカメラ１００の構成＞
　図１Ａは、本実施形態が適用する通信システムのメンバであるデジタルカメラ１００の構成例を示すブロック図である。なお、ここでは通信装置の一例として画像データを記録媒体に記録可能なデジタルカメラについて述べるが、通信装置はこれに限られない。例えば通信装置は携帯型のメディアプレーヤや、いわゆるタブレットデバイス、パーソナルコンピュータ、種々の設備に接続または組み込まれた情報処理装置などであってもよい。また、取り扱うデータも画像データに限定されず、音声データ、文書データなどであってもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　＜デジタルカメラを外部装置から制御するＡＰＩの構成について＞
　図３Ａ，３Ｂは、外部機器からデジタルカメラ１００（サーバ）を制御するためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を示す図である。このＡＰＩは、実施形態のデジタルカメラ１００を先に説明したＡＰモードとして機能させた場合である。

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

　このＡＰＩは、予め不揮発メモリ１０３に保存されている。制御部１０１は、通信部１１１を介して外部機器（実施形態でのスマートデバイス２００）との通信が確立すると、ＡＰＩを実行するためのプログラムを作業用メモリ１０４に展開し、外部装置からＡＰＩがリクエストされるのを待つ。制御部１０１が外部機器からＡＰＩがリクエストされたことを検知すると、ＡＰＩの種類に応じて処理を実行し、その結果をレスポンスとして外部機器に返却する。なお、ＡＰＩはデジタルカメラ１００が規定した通信プロトコル上で実行され、外部機器は規定された通信プロトコルを用いてデジタルカメラ１００と通信を行い、ＡＰＩをリクエストする。また、本実施形態では、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）上で本ＡＰＩが実行されることを想定して説明する。すなわち、デジタルカメラ１０１がＨＴＴＰサーバとして機能し、スマートデバイス２００がＨＴＴＰクライアントとして機能する。なお、通信プロトコルは、ＨＴＴＰに限るものではなく、他のプロトコルであっても構わない。また、ＨＴＴＰプロトコル自体は広く利用されているものであるので、ここでの説明は割愛する。ＨＴＴＰにおけるＡＰＩの実行方法については、外部機器がＨＴＴＰリクエストボディにＡＰＩ名と必要な引数をテキストで記述しＧＥＴメソッドもしくはＰＯＳＴメソッドを用いてデジタルカメラ１００に送信すると、ＨＴＴＰレスポンスボディにその結果を付加して外部機器に返却することで実現される。

　図３Ａ，３ＢのＡＰＩリスト３００は、前述した仕組みで動作する、実施形態のデジタルカメラ１００が提供するＡＰＩセットを表にしたものである。以下、各ＡＰＩを説明する。

　ＡＰＩ３０１は、デジタルカメラ１００の製品情報を取得するためのＡＰＩである。デジタルカメラ１００は、ＡＰＩ名の「ＲｅｑｕｅｓｔＰｒｏｄｕｃｔＩｎｆｏ」のリクエストを引数なしで受信した場合、不揮発性メモリ１０３に格納された、デジタルカメラ１００の製品名、製造者名、ファームウェアバージョン、シリアルナンバーをレスポンスとして構成する。そしてデジタルカメラ１００は、その構成した情報を要求元の外部機器に送信する。なお、製品名とは、デジタルカメラ１００の製品名称である。製造者名とはデジタルカメラ１００のメーカー名称である。ファームウェアバージョンとは、不揮発メモリ１０３に保存されたデジタルカメラ１００を制御するためのプログラムのバージョン番号である。シリアルナンバーとは、デジタルカメラ１００の個体識別が可能な一意の番号である。

　ＡＰＩ３０２は、デジタルカメラ１００の保存領域の情報を取得するＡＰＩである。デジタルカメラ１００は、ＡＰＩ名の「ＲｅｑｕｅｓｔＭｅｍｏｒｙＩｎｆｏ」のリクエストを引数なしで受信した場合、デジタルカメラ１００の保存領域ＩＤ、保存可能容量、空き容量、保存済みのコンテンツファイル数をレスポンスとして構成する。そして、デジタルカメラ１００は、その構成したレスポンスを要求元の外部機器に送信する。なお、保存領域ＩＤとは、デジタルカメラ１００で生成されるコンテンツファイルが保存可能な領域にそれぞれ割り振られたＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）である。例えば、デジタルカメラ１００の記録媒体１１０に割り振られる。保存可能容量とは、コンテンツファイルが保存できる保存領域の保存可能上限サイズである。空き容量とは、保存領域のうち、コンテンツファイルが保存されていない領域のサイズである。保存済みのコンテンツ数とは、保存領域に保存されているコンテンツファイルの総数のことである。

　ＡＰＩ３０３は、デジタルカメラ１００の保存領域に保存されているコンテンツＩＤとコンテンツファイルの基本情報を取得するＡＰＩである。デジタルカメラ１００は、ＡＰＩ名の「ＲｅｑｕｅｓｔＣｏｎｔｅｅｎｔＩｎｆｏ」のリクエストと共に、引数として、ＡＰＩ３０２で取得した保存領域ＩＤ、コンテンツフォーマットの種類、取得要求数を受信した場合、デジタルカメラ１００の保存領域に保存されているコンテンツファイルのコンテンツＩＤ、ファイル名、ファイルサイズ、ファイル生成日時を取得し、要求元の外部機器に送信する。なお、コンテンツＩＤとは、コンテンツファイルを個々に識別するために割り振られたＩＤである。また、本実施形態における本ＡＰＩは、作業用メモリ１０４のサイズによっては一度に取得できるコンテンツファイルの情報に上限値が設定されている。よって、記録媒体１１０などに保存されているコンテンツファイルの数が本ＡＰＩの上限値を超える場合には、繰り返しＡＰＩをリクエストする必要がある。

　ＡＰＩ３０４は、デジタルカメラ１００の保存領域に保存されているコンテンツファイルを取得するＡＰＩである。デジタルカメラ１００は、ＡＰＩ名の「ＲｅｑｕｅｓｔＣｏｎｅｎｔ」のリクエストと共に、引数としてコンテンツＩＤとコンテンツサイズを受信すると、該当するコンテンツファイルを要求元の外部機器に送信する。なお、コンテンツサイズでは、コンテンツファイルをオリジナルのサイズで取得するのか、もしくは縮小したサイズで取得するのかを選択することができる。デジタルカメラ１００は指定されたサイズに従ったコンテンツファイルを生成し外部装置へレスポンスとして送信することになる。本実施形態では、例えば静止画ファイルをオリジナルのサイズで取得するのか、サムネイルサイズで取得するのかが指定できる。従って、サイズとしては、数値ではなく、オリジナル、サムネイルを識別する文字列も利用できる。

　ＡＰＩ３０５は、デジタルカメラ１００の状態のうち、変更された情報を取得するＡＰＩである。デジタルカメラ１００は、ＡＰＩ名の「ＲｅｑｕｅｓｔＣａｍｅｒａＥｖｅｎｔ」のリクエストを引数なしで受信した場合、ＡＰＩ８０１で取得可能な情報の一部もしくはすべてを取得する。なお、デジタルカメラ１００は、このＡＰＩ３０５のリクエストに対してすぐさまレスポンスを返却しない。デジタルカメラ１００の一部の状態が変化するまで待ち、変化したことを検知すると、変化した情報のみをレスポンスとして返却する。例えば、本実施形態では、バッテリー情報を取得するためのＡＰＩである。

　ＡＰＩ３０６は、デジタルカメラ１００が要求元の外部機器に対して送信するコンテンツファイルのＩＤを取得するＡＰＩである。デジタルカメラ１００は、ＡＰＩ名の「ＲｅｑｕｅｓｔＣｏｎｔｅｎｔＬｉｓｔ」のリクエストを引数なしで受信した場合、該当するコンテンツファイルの一覧を要求元の外部機器に送信する。なお、デジタルカメラ１００は、このＡＰＩ３０６のリクエストに対してすぐさまレスポンスを返却しない。デジタルカメラ１００の保存領域に保存されているコンテンツファイルの中から、要求元の外部機器に送信する画像がユーザによって選択された時にレスポンスとして返却する。

　ＡＰＩ３０７は、デジタルカメラ１００が要求元の外部機器に対するコンテンツファイルの送信を中断するＡＰＩである。デジタルカメラ１００は、ＡＰＩ名の「ＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔ」のリクエストを引数なしで受信した場合、ＡＰＩ３０４の「ＲｅｑｕｅｓｔＣｏｎｅｎｔ」によって行っているデジタルカメラ１００から要求元の外部機器に送信しているコンテンツファイルの送信を中断する。なお、中断するのは現在転送しているコンテンツファイルだけではなく、要求元の外部機器がその後に送信を予定しているコンテンツファイルも含めて中断する。なお、デジタルカメラ１００は、このＡＰＩ３０７を受信するまでは、表示部１０６にコンテンツファイル転送キャンセルを指示するＵＩの表示を行わない。また、デジタルカメラ１００は、このＡＰＩ３０７のリクエストに対してすぐさまレスポンスを返却しない。デジタルカメラ１００においてユーザがキャンセル指示操作が行われたことを検出した時にレスポンスとして外部装置に返却する。

　ＡＰＩ３０８は、デジタルカメラ１００が要求元の外部機器に対するコンテンツファイルの送信を中断する、もしくは変更された情報を取得するＡＰＩである。デジタルカメラ１００は、ＡＰＩ名の「ＣａｎｃｅｌＥｖｅｎｔＡｎｄＣａｎｃｅｌ」のリクエストを引数なしで受信した場合、前述のＡＰＩ３０５もしくはＡＰＩ３０７の処理を実施する。本ＡＰＩはＡＰＩ３０５とＡＰＩ３０７の共用ＡＰＩであり、どちらの用途に使用しても良い。

　以上、実施形態におけるＡＰＩを説明した。上記は、主要なＡＰＩの一例であり、上記以外の様々なデジタルカメラ１００の制御方法のＡＰＩを提供しても構わない。また、デジタルカメラ１００は、上記ＡＰＩリクエストに対する応答を送信するとき、要求されたリクエストを特定すると共に、その返値（もしあれば）を要求元に送信するものとする。応答形式は、『Ｒｅｓｐｏｎｓｅ（ＡＰＩリクエスト名、返値）』とする。例えば、デジタルカメラ１００が、外部装置から、ＲｅｑｕｅｓｔＰｒｏｄｕｃｔＩｎｆｏのリクエストを受信し、それに対して応答する場合は、『Ｒｅｓｐｏｎｓｅ（ＲｅｑｕｅｓｔＰｒｏｄｕｃｔＩｎｆｏ，返値）』として、要求元に応答する。なお、どのＡＰＩに対する応答であるかを、要求元に通知できれば良いので、上記例で発明が限定されるものではない。

　これから説明する全ての実施形態では、スマートデバイス２００とデジタルカメラ１００とがネットワーク（実施形態では無線ＬＡＮ）を介して画像処理システムを構成する。なお、デジタルカメラ１００の制御部１０１は、操作部１０５から簡易ＡＰモード（初期状態ではＨＴＴＰプロトコルを利用するファイルサーバモード）に移行済みであるものとする。また、全ての実施形態におけるコンテンツファイルは、画像ファイルを例に説明する。また、実施形態の説明では、例えば、『スマートデバイス２００がデジタルカメラ１００に対し、ＡＰＩ３０１の「ＲｅｑｕｅｓｔＰｒｏｄｕｃｔＩｎｆｏ」を送信する』ことを、簡易にするため、『スマートデバイス２００がＲｅｑｕｅｓｔＰｒｏｄｕｃｔＩｎｆｏ３０１をデジタルカメラにリクエストする』と表現する。

　＜デジタルカメラからスマートデバイスへの画像転送を中断するシーケンス＞
　以下、前述の画像処理システムにおいて、デジタルカメラ１００からスマートデバイス２００に対するコンテンツファイルの画像転送を、デジタルカメラ１００の任意のタイミングで中断する手順を図４～図７を用いて説明する。

　図４はスマートデバイス２００とデジタルカメラ１００の通信シーケンスの例を示している。具体的には、スマートデバイス２００がデジタルカメラ１００から受信するコンテンツファイルの一覧を取得し、その後そのコンテンツファイル一覧を元に、スマートデバイス２００からデジタルカメラ１００に画像の送信要求を行い、デジタルカメラ１００がコンテンツファイルをスマートデバイス２００に送信するまでの処理である。図５Ａ～５Ｃは、デジタルカメラ１００上で動作するプログラムが表示部１０６に表示するユーザインターフェイス（ＵＩ）を示す図である。

　Ｓ４０１において、デジタルカメラ１００とスマートデバイス２００は無線ローカルエリアネットワーク（ＬＡＮ）接続を確立する。ここでは、デジタルカメラ１００が、ユーザの操作によって、簡易ＡＰを起動してコネクションを確立する場合の処理を説明する。

　デジタルカメラ１００の制御部１０１は、無線ＬＡＮ接続するために必要なＳＳＩＤ（Ｓｅｒｖｉｃｅ　Ｓｅｔ　Ｉｄｅｎｔｉｆｉｅｒ）と暗号化キーを生成した後、ＳＳＩＤと暗号化キーを用いて簡易ＡＰを起動し無線ＬＡＮネットワークを生成する。このとき、デジタルカメラ１００は、表示部１０６に、ＳＳＩＤ、暗号キー等のデジタルカメラ１００が提供している簡易ＡＰに接続するための情報を表示する。なお、ＳＳＩＤとは、ＩＥＥＥ８０２．１１シリーズの無線ＬＡＮにおけるアクセスポイントの識別子であり、混信を避けるために付けられる名前である。暗号化キーとは、ＳＳＩＤに不正アクセスされないよう無線ＬＡＮの暗号化を行うためのキーである。なお、ここで表示するＳＳＩＤ、暗号キー等がユーザが適宜編集可能であり、変更編集が無い限り前回用いた情報を表示する。次に、制御部１０１は、ＤＨＣＰ（Ｄｙｎａｍｉｃ　Ｈｏｓｔ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）サーバを起動し、簡易ＡＰが生成するネットワークに参加した機器に対してＩＰアドレスが割り振れるよう準備する。

　一方、スマートデバイス２００の制御部２０１は、ユーザ操作によって無線ＬＡＮネットワークに接続する処理を開始すると、周囲のＡＰをサーチする処理を行い、その結果、得られたＳＳＩＤの一覧を表示部２０６に表示される。ユーザは、操作部２０５を操作して、表示部２０６に表示されたＳＳＩＤ一覧中の、デジタルカメラ１００の表示部１０６に表示された簡易ＡＰのＳＳＩＤと一致するものを選択する。そして、ユーザは、デジタルカメラ１００の表示部１０６に表示された暗号化キーと同じキー（文字列）を、操作部２０５から入力する。この結果、スマートデバイス２００の制御部２０１は、デジタルカメラ１００が生成した簡易ＡＰのネットワークへの参加を開始する。なお、スマートデバイス２００は、過去に接続した経験のあるＳＳＩＤと暗号化キーを記憶しておき、ユーザが選択したＳＳＩＤが、記憶された中にある場合には、対応して記憶された暗号化キーを、暗号キー入力欄にデフォルトとして表示するようにし、ユーザがＯＫボタンを押下（もしくはタッチ）するだけで良いようにしても構わない。上記の結果、デジタルカメラ１００からスマートデバイス２００にＩＰアドレスが割り振られ、無線ＬＡＮへの接続が完了する。なお、ここではデジタルカメラ１００はＤＨＣＰサーバも兼ねる例を説明したが、ルータが構築するローカルネットワークにデジタルカメラ１００とスマートデバイス２００がそれぞれ接続する形態も考えられる。

　Ｓ４０２において、スマートデバイス２００がディスカバリ処理を行う。そして、デジタルカメラ１００とスマートデバイス２００が互いの存在や提供するサービスを認識する。また、スマートデバイス２００は、無線ＬＡＮを介してデジタルカメラ１００が提供するＡＰＩを使用して通信するための準備を行う。なお、ディスカバリで用いられるプロトコルは、例えば、ＳＳＤＰ（Ｓｉｎｇｌｅ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌ）やＭａｌｔｉｃａｓｔ ＤＮＳなどがある。またＳＳＤＰやＭａｌｔｉｃａｓｔ ＤＮＳについては公知のプロトコルであるため説明は割愛する。

　ディスカバリ処理の一例を説明すると、デジタルカメラ１００の制御部１０１は、自らが生成したネットワークに対してアドバタイズ通知を送信し、自身の存在をスマートデバイス２００に通知する。スマートデバイス２００の制御部２０１は、デジタルカメラ１００からのアドバタイズ通知を受信すると、デジタルカメラ１００の機器情報が記載されたデバイスディスクリプションをデジタルカメラ１００から取得し、ＡＰＩサービスを提供しているか否かを判定する。制御部２０１は、デジタルカメラ１００がＡＰＩサービスを提供していると判断した場合、不揮発メモリ２０３よりＡＰＩを使用してデジタルカメラ１００から画像ファイルを取得するためのプログラムを作業用メモリ２０４に展開し、実行する。

　Ｓ４０３において、制御部２０１は、通信部２１１を介してＲｅｑｕｅｓｔＰｒｏｄｕｃｔＩｎｆｏ３０１をデジタルカメラ１００にリクエストする。Ｓ４０４にて、制御部１０１が通信部１１１を介して、このリクエストを受信したことを検知すると、製品名、製造者名、ファームウェアバージョン、シリアルナンバーを不揮発メモリ１０３より取得し、レスポンス用データセットに成形する。そして、制御部１０１は形成したデータセットを、通信部１１１を介してスマートデバイス２００に送信する。

　Ｓ４０５において、制御部２０１は、通信部２１１を介してＲｅｑｕｅｓｔＭｅｍｏｒｙＩｎｆｏ３０２をデジタルカメラ１００にリクエストする。Ｓ４０６において、制御部１０１は、通信部１１１を介してこのリクエストを受信したことを検知すると、保存領域ＩＤ、保存可能容量、空き容量、保存済みコンテンツ数を作業用メモリ１０４や記録媒体１１０より取得してレスポンス用データセットに成形する。そして、制御部１０１は形成したデータセットを、通信部１１１を介してスマートデバイス２００に送信する。

　Ｓ４０７において、制御部２０１は、通信部２１１を介してＲｅｑｕｅｓｔＣｏｎｔｅｎｔＬｉｓｔ３０６をデジタルカメラ１００にリクエストする。デジタルカメラ１００の制御部１０１が、通信部１１１を介して、このリクエストを受信したことを検知すると、Ｓ４０８においてデジタルカメラ１００の表示部１０６に、図５Ａのように記憶媒体１１０に記録されている画像のサムネイル一覧を選択可能に表示する。そして、制御部１００は、ユーザによる選択を行わせ、スマートデバイス２００への転送対象の画像を決定していく。

　Ｓ４０９において、ユーザが、デジタルカメラ１００の表示部１０６において、転送画像を選択ボタン５０２で選択し、ＯＫボタン５０３をタッチすると、制御部１０１は、図５Ｂの転送中の画面を表示部１０６に表示する。このとき制御部１０１は、選択した画像ＩＤ一覧を作業用メモリ１０４に保存する。その後、Ｓ４１０において、制御部１０１は、ユーザが選択した送信用の画像ＩＤ一覧を作業用メモリ１０４より取得して、レスポンス用データセットに成形する。そして、制御部１０１は形成したデータセットを、通信部１１１を介してスマートデバイス２００に送信する。

　この結果、スマートデバイス２００の制御部２０１は、ユーザが選択した画像を特定する情報を取得できることになる。

　Ｓ４１１において、制御部２０１は、通信部２１１を介してＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔ３０７をデジタルカメラ１００にリクエストする。デジタルカメラ側から転送の中断操作を可能にするためである。デジタルカメラ１００の制御部１０１が通信部１１１を介して、このリクエストを受信したことを検知すると、デジタルカメラ１００の表示部１０６に、図５Ｃに示すように、キャンセルボタン５０４を追加表示する。制御部２０１は、このリクエストに対するレスポンスは直ぐに返さず、保留状態とする。このリクエストを意図的に保留状態にしておくことで、デジタルカメラ１００は任意のタイミングでスマートデバイス２００にデータを送信することが可能となる。本実施形態では、ユーザ操作によりキャンセルボタン５０４が押下されたタイミングでレスポンスを返すことになる。このように、サーバ側が任意のタイミングでクライアントにデータを送信することをサーバプッシュと呼び、意図的なレスポンスの保留状態を作ってサーバプッシュを実現する技術をロングポーリングと呼ぶ。

　Ｓ４１２において、制御部２０１は、通信部２１１を介してＲｅｑｕｅｓｔＣｏｎｔｅｎｔ３０４をデジタルカメラ１００にリクエストする。Ｓ４１３において、制御部１０１は、通信部１１１を介してこのリクエストを受信したことを検知すると、指定されたコンテンツＩＤに対応するコンテンツファイル（ユーザが選択した画像のファイル）を作業用メモリ１０４や記録媒体１１０より取得してレスポンス用データセットに成形する。そして、制御部１０１は形成したデータセットを、通信部１１１を介してスマートデバイス２００に送信する。

　その後、Ｓ４１４、Ｓ４１５以降、Ｓ４１２、Ｓ４１３と同じ処理が繰り返される。つまり、通常は、ユーザが選択した全画像のデジタルカメラ１００からスマートデバイスに向けて転送が完了するまで繰り返される。この間、ユーザが、何らかの理由で転送をキャンセルする場合を説明する。

　今、画像転送中のＳ４１６において、ユーザは、操作部１０５への操作によって、図５Ｃのキャンセルボタン５０４を押下したとする。この場合、Ｓ４１７において、制御部１０１は、通信部１１１を介してスマートデバイス２００に対し、Ｓ４１１に対するレスポンスデータを送信する。

　Ｓ４１８において、制御部２０１はユーザ指示によってプログラムの終了指示を検知すると、Ｓ４１９において、デジタルカメラ１００との通信を終了する。つまり、制御部２０１は、この終了指示を検知した場合、ユーザが当初選択した全画像の受信が完了していなくても、通信を終了する。

　Ｓ４２０において、デジタルカメラ１００とスマートデバイス２００の通信の切断処理が完了する。

　以上が、スマートデバイス２００がデジタルカメラ１００と接続して、コンテンツファイルを取得する際に、デジタルカメラ１００からコンテンツファイル取得の中断を行う方法の一例である。

　＜デジタルカメラ１００の処理内容＞
　デジタルカメラ１００の処理の流れについて説明する。図６Ａ，６Ｂは、デジタルカメラ１００のＡＰＩサービスの処理の流れを示したフローチャートである。

　Ｓ６０１において、制御部１０１は、デジタルカメラ１００とスマートデバイス２００は無線ローカルエリアネットワーク（ＬＡＮ）接続を確立する。本処理はＳ４０１で説明したデジタルカメラ１００の処理と同様であるため説明は割愛する。

　Ｓ６０２において、制御部１０１は、ディスカバリを行い、デジタルカメラ１００とスマートデバイス２００が互いの存在や提供するサービスを認識し、無線ＬＡＮを介してデジタルカメラ１００が提供するＡＰＩを使用して通信するための準備を行う。本処理は、Ｓ４０２で説明したデジタルカメラ１００の処理と同様であるため説明は割愛する。

　Ｓ６０３において、制御部１０１は、通信部１１１を介してＡＰＩのＲｅｑｕｅｓｔＣｏｎｔｅｎｔＬｉｓｔリクエストを受信したか否かを検知する。もし、検知した場合はＳ６０４に進む。そうでない場合は処理を繰り返す。

　Ｓ６０４において、制御部１０１は、図５Ａの画像情報一覧を表すＵＩの表示、及び、ユーザによる画像の選択操作を受け付ける。そして、選択終了（図５ＡのＯＫボタン操作）があった場合に、制御部１０１は、通信部１１１を介して、選択画像を特定するためのＩＤを含む情報リスト（or画像リスト）を生成し、その情報リストをＡＰＩのＲｅｑｕｅｓｔＣｏｎｔｅｎｔＬｉｓｔレスポンスとして送信する。

　Ｓ６０５において、制御部１０１は、表示部１０６に図５Ｂの転送の進捗状況を示すＵＩを表示する。

　Ｓ６０６にて、制御部１０１は、ＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストを受信しているか否かを判定するためのフラグＦＬＡＧを初期化（非受信を示す値）する。なお、このフラグＦＬＡＧは、作業用メモリ１０４の所定のアドレスに確保されるものとする。

　Ｓ６０７において、制御部１０１は、通信部１１１を介してＡＰＩのＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストを受信したか否かを検知する。もし、受信していた場合はＳ６０８に進む。そうでない場合はＳ６０９に処理を進める。

　Ｓ６０８にて、制御部１０１は、通信部１１１を介してＡＰＩのＲｅｑｕｅｓｔＣｏｎｔｅｎｔレスポンスを送信する。このレスポンスは、ＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストに記述されたＩＤが示す画像データの送信である。このレスポンス処理を終えると、制御部１０１は、処理をＳ６０７に戻す。

　一方、Ｓ６０９に処理が進んだ場合、制御部１０１は、通信部１１１を介してＡＰＩのＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストを受信したか否かを判定する。このリクエストを受信した場合、制御部１０１は処理をＳ６１０に進める。否の場合、制御部１０１は、処理をＳ６１２に進める。

　Ｓ６１０にて、制御部１０１は、ＡＰＩのＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストを受信したので、フラグＦＬＡＧに“１”をセットする。そして、Ｓ６１１にて、制御部１０１は、表示部１０６に図５Ｃのキャンセルボタン５０４を表示する。この後、制御部１０１は処理をＳ６０７に戻す。

　Ｓ６１２において、制御部１０１は、フラグＦＬＡＧが“１”であるか否かを判定する。換言すれば、ＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストを受信しているか否かを判定するとも言えるし、キャンセルボタン５０４をＵＩに表示済みであるか否かを判定すると言い換えることもできる。フラグＦＬＡＧが“１”である場合、制御部１０１は処理をＳ６１３に進める。また、フラグＦＬＡＧが“０”である場合、制御部１０１は処理をＳ６０７に戻す。

　Ｓ６１３にて、制御部１０１は、ユーザが操作部１０５を操作して、キャンセルボタン５０４を押下したか否かを判定する。キャンセルボタン５０４が押下されていた場合、制御部１０１は処理をＳ６１４に進め、押下されていない場合にはＳ６０７に処理を戻す。

　Ｓ６１４において、制御部１０１は、通信部１１１を介してＡＰＩのＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔレスポンスを送信する。つまり、制御部１０１は、ユーザより画像転送のキャンセルが操作されたことをスマートデバイス２００に通知する。その後、制御部１０１は、スマートデバイス２００から接続終了の指示を受けて、本処理を終了させる。

　＜スマートデバイス２００の処理内容＞
　次に、コンテンツ一覧表示やリモート撮影してコンテンツファイルを取得する際に、デジタルカメラ１００の状態情報を取得する際のスマートデバイス２００の処理の流れについて説明する。

　図７は、スマートデバイス２００にて実行されるアプリケーションの処理の流れを示したフローチャートである。

　Ｓ７０１において、制御部２０１は、デジタルカメラ１００とスマートデバイス２００は無線ローカルエリアネットワーク（ＬＡＮ）接続を確立する。本処理はＳ４０１で説明したスマートデバイス２００の処理と同様であるため説明は割愛する。

　Ｓ７０２において、制御部２０１は、ディスカバリを行い、デジタルカメラ１００とスマートデバイス２００が互いの存在や提供するサービスを認識し、無線ＬＡＮを介してデジタルカメラ１００が提供するＡＰＩを使用して通信するための準備を行う。本処理は、Ｓ４０２で説明したスマートデバイス２００の処理と同様であるため説明は割愛する。

　Ｓ７０３において、制御部２０１は、ＲｅｑｕｅｓｔＰｒｏｄｕｃｔＩｎｆｏをデジタルカメラ１００に送信する。本処理は、Ｓ４０３で説明した処理と同様であるため説明は割愛する。

　Ｓ７０４において、制御部２０１は、ＲｅｑｕｅｓｔＭｅｍｏｒｙＩｎｆｏをデジタルカメラ１００に送信する。本処理は、Ｓ４０５で説明した処理と同様であるため説明は割愛する。

　Ｓ７０５において、制御部２０１は、ＲｅｑｕｅｓｔＣｏｎｔｅｎｔＬｉｓｔをデジタルカメラ１００に送信する。本処理は、Ｓ４０７で説明した処理と同様であるため説明は割愛する。

　Ｓ７０６において、制御部２０１は、通信部２１１を介してＲｅｑｕｅｓｔＣｏｎｔｅｎｔＬｉｓｔレスポンス（転送対象の画像ＩＤが記述された情報リスト）を受信したか否かを判定する。もし、そのレスポンスを受信した場合、制御部２０１は処理をＳ７０７に進め、そうでない場合はそのレスポンスを受信するまで待つ。

　Ｓ７０７において、制御部２０１は、通信部２１１を介してＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔをデジタルカメラ１００に送信する。本処理は、Ｓ４１１で説明した処理と同様であるため説明は割愛する。

　Ｓ７０８において、制御部２０１は、ＲｅｑｕｅｓｔＣｏｎｔｅｎｔをデジタルカメラ１００に送信する。つまり、制御部２０１は、ユーザが選択した画像の１つの送信要求をデジタルカメラ１００に要求する。この処理はＳ４１２で説明した処理でもある。

　Ｓ７０９において、制御部２０１は、通信部２１１を介してＡＰＩのＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔレスポンスを受信したか否かを判定する。もし、ＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔレスポンスを受信した場合は、制御部２０１は画像受信処理を中断し、デジタルカメラ１００に接続終了の指示を送信して処理を終了させる。ＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔレスポンスが未受信であると判定した場合、制御部２０１は処理をＳ７１０に進める。

　Ｓ７１０において、制御部２０１は、通信部２１１を介してＡＰＩのＲｅｑｕｅｓｔＣｏｎｔｅｎｔレスポンス（画像データ）を受信したか否かを判定する。ＲｅｑｕｅｓｔＣｏｎｔｅｎｔレスポンスを受信した場合、Ｓ７１１にて、制御部２０１は、全ての画像の受信を終えたか否かを判断する。否の場合には次の画像を取得するため、制御部２０１は、次の画像をデジタルカメラ１００から受信するために、Ｓ７０８に処理を戻す。一方、着目している画像データの受信が完了していない場合には、ユーザからのキャンセル処理が行われたどうかを判断するために、処理をＳ７０９に戻す。

　以上説明したように本実施形態によれば、ユーザがデジタルカメラに記憶保持されている撮像画像をスマートデバイスに転送する場合に、デジタルカメラ側の操作部を介して転送の中断を行うことができるようになる。

　上記の第１の実施形態では、画像転送している間にその転送をデジタルカメラ１００の操作でキャンセルした例を説明した。画像の転送キャンセル用に使用したＡＰＩのＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔと同じ使い方で、デジタルカメラ１００のステータス通知用に使用することも出来る。

　そこで、第２の実施形態では、画像転送のキャンセルには専用のＡＰＩのＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔを使用し、デジタルカメラのステータス通知には別のＡＰＩのＲｅｑｕｅｓｔＣａｍｅｒａＥｖｅｎｔを使用した例を説明する。

　第３の実施形態では、画像転送のキャンセルと、デジタルカメラのステータス通知の共用として使用するＡＰＩのＲｅｑｕｅｓｔＥＶｅｎｔＡｎｄＣａｎｃｅｌを用いた例を説明する。

　［第２の実施形態］
　＜画像転送用のＡＰＩと、カメラのステータス通知用のＡＰＩをそれぞれ別で使用する場合のシーケンス＞
　図８Ａ，８Ｂは、第２の実施形態における、スマートデバイス２００とデジタルカメラ１００との画像転送キャンセルを行わなかった場合の通信シーケンスを含めた例を示している。具体的には、画像転送のキャンセルには専用のＡＰＩ３０７を使用し、デジタルカメラ１００のステータス通知には別のＡＰＩ３０５を使用した例である。

　Ｓ８０１、Ｓ８０２は第１の実施形態で説明した図４のＳ４０１、Ｓ４０２と同様の処理なので説明を省略する。

　Ｓ８０３において、制御部２０１は、通信部２１１を介してＲｅｑｕｅｓｔＣａｍｅｒａＥｖｅｎｔ３０５をデジタルカメラ１００にリクエストする。デジタルカメラ１００の制御部１０１は、通信部１１１を介してこのリクエストを受信したとしても、直ぐにレスポンスは返さない。また、制御部１０１は、このリクエストを受信すると、カメラ１００のステータスが変化（状態変化）を監視を開始し、その変化があった場合にはじめて、このＲｅｑｕｅｓｔＣａｍｅｒａＥｖｅｎｔ３０５のレスポンスを返す。本第２の実施形態ではバッテリーの状態を通知した時の例を説明している。もちろん、ステータスとしてバッテリーの状態だけでは無く、カメラの内部状態であれば他のパラメータであっても構わないに対する。

　Ｓ８０４～Ｓ８１８までの処理は、第１の実施形態で説明した図４のＳ４１４、Ｓ４１５と同様の処理なので説明を省略する。

　Ｓ８１９において、バッテリー状態が変化している。Ｓ８２０において、制御部１０１が、デジタルカメラ１００のバッテリー状態が変化したことを検知すると、Ｓ８０３のＲｅｑｕｅｓｔＣａｍｅｒａＥｖｅｎｔ３０５に対して、バッテリー情報をレスポンス用データセットに成形して、通信部１１１を介してスマートデバイス２００に送信する。

　Ｓ８２１において、制御部２０１は、通信部２１１を介してＲｅｑｕｅｓｔＣａｍｅｒａＥｖｅｎｔ３０５をデジタルカメラ１００にリクエストする。Ｓ８２１を行うことによって、再度デジタルカメラ１００のステータス通知をスマートデバイス２００に対して行えることを可能にしている。

　Ｓ８２２において、制御部１０１は、通信部１１１を介してＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔ３０７のレスポンスをデジタルカメラ１００に送信する。これはＳ８１３から始まった画像転送がキャンセルされなかったため、正常に画像転送処理が終わった場合は、必ずＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔ３０７に対してレスポンスを返してリソースの消費を防いでいる。

　Ｓ８２３～Ｓ８３７は第１の実施形態で説明した図４のＳ４０１～Ｓ４２０と同様の処理なので説明を省略する。

　＜デジタルカメラ１００の処理内容＞
　デジタルカメラ１００の処理の流れについて説明する。図９Ａ、９Ｂは、デジタルカメラ１００のＡＰＩサービスの処理の流れを示したフローチャートである。以下、同図に従って説明する。

　Ｓ９０１、Ｓ９０２は第１の実施形態で説明した図６ＡのＳ６０１、Ｓ６０２と同様の処理なので説明を省略する。

　Ｓ９０３にて、制御部１０１は、作業用メモリ１０４に予め確保したフラグＦＬＡＧ＿Ｅ、ＦＬＡＧ＿Ｃをゼロクリアする。フラグＦＬＡＧ＿Ｅは、ＲｅｑｕｅｓｔＣａｍｅｒａＥｖｅｎｔリクエストを受信しているか否かを判定するため、フラグＦＬＡＧ＿Ｃは、ＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストを受信しているか否かを判定するためのフラグである。Ｓ９０３の処理は、いずれのリクエストも未受信であるものとするためである。

　Ｓ９０４にて、制御部１０１は、通信部１１１を介して、スマートデバイス２００から何らかのリクエストを受信したか否かを判定する。リクエストの受信があった場合、制御部は続くＳ９０５乃至Ｓ９０８にて、受信したリクエストの種類を判定し、それぞれに応じた処理を行う。一方、リクエストを受信していないと判定した場合、制御部１０１はＳ９２１に処理を進める。

　受信したのがＲｅｑｕｅｓｔＣｏｎｔｅｎｔＬｉｓｔリクエストである場合、制御部１０１はＳ９０５からＳ９０９に処理を進める。そして、Ｓ９０９にて、制御部１０１は、ＲｅｑｕｅｓｔＣｏｎｔｅｎｔＬｉｓｔレスポンスを送信する。この送信は、第１の実施形態におけるＳ６０４と同じである。そして、制御部１０１は、Ｓ９１０にて、画像転送画面の表示を開始する。この処理も第１の実施形態におけるＳ６０５と同じである。この後、制御部１０１は処理をＳ９０４に戻す。

　受信したのがＲｅｑｕｅｓｔＣａｍｅｒａＥｖｅｎｔリクエストである場合、制御部１０１はＳ９０６からＳ９１１に処理を進める。このＳ９１１にて、制御部１０１は、ＲｅｑｕｅｓｔＣａｍｅｒａＥｖｅｎｔリクエストの受信があったことを示すため、フラグＦＬＡＧ＿Ｅに“１”をセットする。そして、制御部１０１は処理をＳ９０４に戻す。

　受信したのがＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストである場合、制御部１０１はＳ９０７からＳ９１２に処理を進める。このＳ９１２にて、制御部１０１は、ＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストの受信があったことを示すため、フラグＦＬＡＧ＿Ｃに“１”をセットする。そして、制御部１０１は、Ｓ９１３にて、表示画面にキャンセルボタン５０４を表示する。この後、制御部１０１は処理をＳ９０４に戻す。

　なお、実施形態では、ＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストの受信する以前に転送画面が既に表示されているものとしているが、ＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストを受信した後に、ＲｅｑｕｅｓｔＣｏｎｔｅｎｔＬｉｓｔリクを受信した場合には、制御部１０１は、Ｓ９１０にて、キャンセルボタン５０４を有する転送画面を表示することになる。

　受信したのがＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストである場合、制御部１０１はＳ９０８からＳ９１４に処理を進める。このＳ９１４にて、制御部１０１は、ＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストのレスポンスを送信する。この送信処理は、第１の実施形態におけるＳ６０８と同じである。この後、制御部１０１は処理をＳ９０４に戻す。

　また、受信したリクエストが上記以外の場合には、制御部１０１はＳ９０８からＳ９１５に進み、受信したリクエストに対応する処理を行う。そして、制御部１０１は、処理をＳ９０４に戻す。

　さて、Ｓ９０４にて、制御部１０１がリクエストの受信が無いと判断した場合にはＳ９２１に処理を進める。このＳ９２１にて、制御部１０１は、フラグＦＬＡＧ＿Ｅが“１”であるか否か、換言すれば、ＲｅｑｕｅｓｔＣａｍｅｒａＥｖｅｎｔリクエストを受信済みであるか否かを判定する。ＦＬＡＧ＝０（非受信）である場合、制御部１０１は、Ｓ９２２、Ｓ９２３の処理をスキップし、Ｓ９２４に処理を進める。また、フラグＦＬＡＧ＿Ｅが“１”である場合（受信済み）、制御部１０１は、Ｓ９２２にて、デジタルカメラ１００のバッテリー状態等の変化があったか否かを判定する。変化がない場合には、制御部１０１は処理をＳ９２４に進める。また、変化があれば、Ｓ９２３にて、制御部１０１は、変化内容を記述した応答メッセージを作成し、ＲｅｑｕｅｓｔＣａｍｅｒａＥｖｅｎｔリクエストに対する応答として送信する。そして、制御部１０１は処理をＳ９２４に進める。

　Ｓ９２４にて、制御部１０１は、フラグＦＬＡＧ＿Ｃが“１”であるか否か、換言すれば、ＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストを受信済みか否かを判定する。ＦＬＡＧ＿Ｃ＝０（非受信）である場合、制御部１０１は処理をＳ９０４に戻す。ＦＬＡＧ＿Ｃ＝１である場合（受信済み）、制御部１０１はＳ９２５に処理を進める。このＳ９２５にて、制御部１０１は、キャンセルボタン５０４が押下されたか否かを判定する。非押下の場合、制御部１０１は処理をＳ９０４に戻す。また、制御部１０１は、キャンセルボタン５０４が押下されたと判定した場合、処理をＳ９２６に進める。このＳ９２６にて、制御部１０１は、ＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストに対する応答メッセージを生成し、送信する。このＳ９２６の処理は、第１の実施形態における、Ｓ６１４と同じである。

　＜スマートデバイス２００の処理内容＞
　次に、スマートデバイス２００の処理の流れを図１０Ａ，１０Ｂのフローチャートに従って説明する。

　Ｓ１００１～Ｓ１００４は第１の実施形態で説明した図７のＳ７０１～Ｓ７０４と同様の処理なので、その説明は省略する。

　Ｓ１００５においては、制御部２０１は、ＲｅｑｕｅｓｔＣａｍｅｒａＥｖｅｎｔ３０５リクエストをデジタルカメラ１００に送信する。Ｓ１００６～Ｓ１０１０は第１の実施形態で説明した図７のＳ７０１～Ｓ７０９と同様の処理なので説明を省略する。

　Ｓ１０１１において、制御部２０１は、通信部２１１を介してＡＰＩのＲｅｑｕｅｓｔＣａｍｅｒａＥｖｅｎｔレスポンスを受信したか否かを判定する。もし、そのレスポンスを受信した場合は、制御部２０１は画像受信処理を中断し、デジタルカメラ１００に接続終了の指示を送信して処理を終了させる。ＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔレスポンスが未受信であると判定した場合、制御部２０１は処理をＳ１０１１に進める。

　Ｓ１０１１にて、制御部２０１は、ＲｅｑｕｅｓｔＣａｍｅｒａＥｖｅｎｔ３０５に対するレスポンスを受信したか否かを判定する。否の場合、制御部２０１は処理をＳ１０１３に進める。また、ＲｅｑｕｅｓｔＣａｍｅｒａＥｖｅｎｔ３０５に対するレスポンスを受信した場合、制御部２０１は、Ｓ１０１２にて、デジタルカメラのステータスに応じた処理を行うと共に、以降でもスタータスに変化があった場合に通知を受信するため、再度ＲｅｑｕｅｓｔＣａｍｅｒａＥｖｅｎｔ３０５リクエストをデジタルカメラ１００に送信する。

　Ｓ１０１３は第１の実施形態で説明した図７のＳ７１０と同様の処理なので説明を省略する。

　Ｓ１０１４において、制御部２０１は、Ｓ１００７で受信したＲｅｑｕｅｓｔＣｏｎｔｅｎｔＬｉｓｔの全ての画像を受信したかどうかを判定する。否の場合には、制御部２０１は次の画像の受信するために処理をＳ１００９に戻す。一方、全画像の受信が完了していれば、制御部２０１は本処理を終えるため、通信を終える。

　［第３の実施形態］
　＜画像転送用のＡＰＩと、カメラのステータス通知用のＡＰＩをそれぞれ別で使用する場合のシーケンス＞
　図１１Ａ，１１Ｂは、第３の実施形態における、スマートデバイス２００とデジタルカメラ１００との画像転送キャンセルを行わなかった場合の通信シーケンスを含めた例を示している。具体的には、画像転送のキャンセルと、デジタルカメラ１００のステータス通知を共用したＡＰＩ、ＲｅｑｕｅｓｔＥｖｅｎｔＡｎｄＣａｎｃｅｌ３０８を使用した時の例である。

　Ｓ１１０１、Ｓ１１０２は第１の実施形態で説明した図４のＳ４０１、Ｓ４０２と同様の処理なので説明を省略する。

　Ｓ１１０３は、制御部２０１は、通信部２１１を介してＲｅｑｕｅｓｔＣａｍｅｒａＥｖｅｎｔＡｎｄＣａｎｃｅｌ３０８をデジタルカメラ１００にリクエストする。デジタルカメラ１００の制御部１０１が通信部１１１を介して、このリクエストを受信したことを検知しても、直ぐにレスポンスは返さない。この後行う画像転送のキャンセル処理、もしくはカメラのステータスが変化した時にレスポンスを返す。

　Ｓ１１０４～Ｓ１１１７は第２の実施形態で説明した図８Ａ、８ＢのＳ８０４～Ｓ８１１、Ｓ８１３～８１８と同様の処理なので説明を省略する。

　Ｓ１１１８において、バッテリー状態が変化しとする。この場合、Ｓ１１１９において、制御部１０１が、デジタルカメラ１００のバッテリー状態が変化したことを検知し、Ｓ１１０３のＲｅｑｕｅｓｔＥｖｅｎｔＡｎｄＣａｎｃｅｌ３０８に対して、バッテリー情報をレスポンス用データセットに成形して、通信部１１１を介してスマートデバイス２００に送信する。

　Ｓ１１２０において、制御部２０１は、このレスポンスを再度受信できるようにするため、通信部２１１を介してＲｅｑｕｅｓｔＥｖｅｎｔＡｎｄＣａｎｃｅｌ３０８をデジタルカメラ１００にリクエストする。Ｓ１１２０を行うことによって、再度デジタルカメラ１００のステータス通知をスマートデバイス２００に対して行えること、また画像転送のキャンセルを可能にしている。

　Ｓ１１２１～Ｓ１１２８は第２の実施形態で説明した図８Ａ，８ＢのＳ８２３～Ｓ８２６、Ｓ８２８～８３１と同様の処理なので説明を省略する。

　Ｓ１１２９において、制御部１０１が、デジタルカメラ１００のバッテリー状態が変化したことを検知すると、Ｓ１１２０のＲｅｑｕｅｓｔＥｖｅｎｔＡｎｄＣａｎｃｅｌ３０８に対して、バッテリー情報をレスポンス用データセットに成形して、通信部１１１を介してスマートデバイス２００に送信する。

　Ｓ１１３２～Ｓ１１３５は第２の実施形態で説明した図８Ａ，８ＢのＳ８３４～Ｓ８３７と同様の処理なので説明を省略する。

　＜デジタルカメラ１００の処理内容＞
　デジタルカメラ１００の処理の流れについて説明する。図１２Ａ、１２Ｂは、デジタルカメラ１００のＡＰＩサービスの処理の流れを示したフローチャートである。以下、同図に従って説明する。

　Ｓ１２０１、Ｓ１２０２は第１の実施形態で説明した図６ＡのＳ６０１、Ｓ６０２と同様の処理なので説明を省略する。

　Ｓ１２０３にて、制御部１０１は、作業用メモリ１０４に予め確保したフラグＦＬＡＧをゼロクリアする。このフラグＦＬＡＧは、ＲｅｑｕｅｓｔＥｖｅｎｔＡｎｄＣａｎｃｅｌリクエストを受信しているか否かを判定するためのものである。Ｓ１２０３の処理は、ＲｅｑｕｅｓｔＥｖｅｎｔＡｎｄＣａｎｃｅｌリクエストを未受信とするためである。

　Ｓ１２０４にて、制御部１０１は、通信部１１１を介して、スマートデバイス２００から何らかのリクエストを受信したか否かを判定する。リクエストの受信があった場合、制御部は続くＳ１２０５、Ｓ１２０６，Ｓ１２０８にて、受信したリクエストの種類を判定し、それぞれに応じた処理を行う。一方、リクエストを受信していないと判定した場合、制御部１０１はＳ１２２１に処理を進める。

　受信したのがＲｅｑｕｅｓｔＣｏｎｔｅｎｔＬｉｓｔリクエストである場合、制御部１０１はＳ１２０５からＳ１２０９に処理を進める。そして、Ｓ１２０９にて、制御部１０１は、ＲｅｑｕｅｓｔＣｏｎｔｅｎｔＬｉｓｔレスポンスを送信する。この送信は、第１の実施形態におけるＳ６０４と同じである。そして、制御部１０１は、Ｓ１２１０にて、画像転送画面の表示を開始する。この処理も第１の実施形態におけるＳ６０５と同じである。この後、制御部１０１は処理をＳ１２０４に戻す。

　受信したのがＲｅｑｕｅｓｔＥｖｅｎｔＡｎｄＣａｎｃｅｌリクエストである場合、制御部１０１はＳ１２０６からＳＳ１２１１に処理を進める。このＳ１２１１にて、制御部１０１は、ＲｅｑｕｅｓｔＥｖｅｎｔＡｎｄＣａｎｃｅｌリクエストの受信があったことを示すため、フラグＦＬＡＧに“１”をセットする。そして、制御部１０１は処理をＳ１２１２にて、画像転送画面を表示したか否かを判定する。画像転送画面が非表示である場合、制御部１０１は、処理をＳ１２０４に戻す。また、画像転送画面を表示している場合には、制御部１０１はＳ１２１３にて、キャンセルボタン５０４を表示する。この後、制御部１０１は処理をＳ１２０４に戻す。

　なお、実施形態では、ＲｅｑｕｅｓｔＥｖｅｎｔＡｎｄＣａｎｃｅｌクエストの受信した後に、ＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストを受信した場合には、フラグを“１”にすると共に、制御部１０１は、キャンセルボタン５０４を有する転送画面を表示することになる。

　受信したのがＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストである場合、制御部１０１はＳ１２０８からＳ１２１４に処理を進める。このＳ１２１４にて、制御部１０１は、ＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストのレスポンスを送信する。この送信処理は、第１の実施形態におけるＳ６０８と同じである。この後、制御部１０１は処理をＳ１２０４に戻す。

　また、受信したリクエストが上記以外の場合には、制御部１０１はＳ１２０８からＳ１２１５に進み、受信したリクエストに対応する処理を行う。そして、制御部１０１は、処理をＳ１２０４に戻す。

　さて、Ｓ１２０４にて、制御部１０１がリクエストの受信が無いと判断した場合にはＳ１２２１に処理を進める。このＳ１２２１にて、制御部１０１は、フラグＦＬＡＧが“１”であるか否か、換言すれば、ＲｅｑｕｅｓｔＥｖｅｎｔＡｎｄＣａｎｃｅｌリクエストを受信済みであるか否かを判定する。ＦＬＡＧ＝０（非受信）である場合、制御部１０１は、処理をＳ１２０４に戻す。

　また、フラグＦＬＡＧが“１”である場合（受信済み）、制御部１０１は、Ｓ１２２２にて、デジタルカメラ１００のバッテリー状態等の変化があったか否かを判定する。変化がない場合には、制御部１０１は処理をＳ１２２４に進める。また、変化があれば、Ｓ１２２３にて、制御部１０１は、変化内容を記述した応答メッセージを作成し、ＲｅｑｕｅｓｔＥｖｅｎｔＡｎｄＣａｎｃｅｌリクエストに対する応答として送信する。そして、制御部１０１は処理をＳ１２０４に戻す。

　また、Ｓ１２２４にて、制御部１０１は、キャンセルボタン５０４が押下されたか否かを判定する。非押下の場合、制御部１０１は処理をＳ１２０４に戻す。また、制御部１０１は、キャンセルボタン５０４が押下されたと判定した場合、処理をＳ１２２５に進める。このＳ１２２５にて、制御部１０１は、キャンセルボタン５０４が押下されたことを示すメッセージを作成し、ＣａｎｃｅｌＲｅｑｕｅｓｔＣｏｎｔｅｎｔリクエストに対する応答として送信する。そして、制御部１０１は、処理をＳ１２０４に戻す。

　＜スマートデバイス２００の処理内容＞
　次に、スマートデバイス２００の処理の流れを図１３Ａ，１３Ｂのフローチャートに従って説明する。

　Ｓ１３０１～Ｓ１３０４は第１の実施形態で説明した図７のＳ７０１～Ｓ７０４と同様の処理なので、その説明は省略する。

　Ｓ１３０５においては、制御部２０１は、ＲｅｑｕｅｓｔＥｖｅｎｔＡｎｄＣａｎｃｅｌ３０８のリクエストをデジタルカメラ１００に送信する。Ｓ１３０６～Ｓ１３０８は第１の実施形態で説明した図７のＳ７０１～Ｓ７０９と同様の処理なので説明を省略する。

　Ｓ１３０９において、制御部２０１は、通信部２１１を介してＡＰＩのＲｅｑｕｅｓｔＥｖｅｎｔＡｎｄＣａｎｃｅｌリクエストのレスポンスを受信したか否かを判定する。ＲｅｑｕｅｓｔＥｖｅｎｔＡｎｄＣａｎｃｅｌリクエストのレスポンスを受信した場合、制御部２０１は処理をＳ１３１０に処理を進め、否の場合には処理をＳ１３１３に進める。

　Ｓ１３１０にて、制御部２０１は受信したＲｅｑｕｅｓｔＥｖｅｎｔＡｎｄＣａｎｃｅｌリクエストのレスポンスを解析し、デジタルカメラのステータスの変更を通知するものであるか、画像転送のキャンセルが指示されたことを示すものであるかを判定する。そして、画像転送のキャンセルが指示されたことを示している場合、制御部２０１は本通信処理を終了する。

　一方、ステータス変更を示す場合、制御部２０１は、Ｓ１３１１にて、デジタルカメラ１００のステータスに応じた処理を行うと共に、以降でもスタータスに変化があった場合に通知を受信するため、再度ＲｅｑｕｅｓｔＥｖｅｎｔＡｎｄＣａｎｃｅｌ３０８のリクエストをデジタルカメラ１００に送信する。そして、制御部２０１は、処理をＳ１３１３に進める。

　Ｓ１３１３は第１の実施形態で説明した図７のＳ７１０と同様の処理なので説明を省略する。

　Ｓ１３１４において、制御部２０１は、Ｓ１３０７で受信したＲｅｑｕｅｓｔＣｏｎｔｅｎｔＬｉｓｔの全ての画像を受信したかどうかを判定する。否の場合には、制御部２０１は次の画像の受信するために処理をＳ１３０８に戻す。一方、全画像の受信が完了していれば、制御部２０１は本処理を終えるため、通信を終える。

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

　本発明は上記実施の形態に制限されるものではなく、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、本発明の範囲を公にするために、以下の請求項を添付する。

　本願は、２０１７年５月２日提出の日本国特許出願特願２０１７－０９１９４３を基礎として優先権を主張するものであり、その記載内容の全てを、ここに援用する。

Claims (14)

1. 　クライアント及び当該クライアントから要求に応じた情報を送信するサーバとを含む通信システムであって、
   　前記クライアントは、
   　　　　コンテンツ要求を前記サーバに送信する第１の要求手段と、
   　を有し、
   　前記サーバは、
   　　　　前記第１の要求手段により要求されたコンテンツを前記クライアントに送信する第１の応答手段とを有し、
   　前記クライアントは、更に、
   　　　　前記サーバに対して、所定の状態になった場合に応答するように要求する第２の要求手段を有し、
   　前記サーバは、更に、
   　　　　前記第２の要求手段による前記要求を受信した場合、前記所定の状態にならない場合に応答を保留し、前記所定の状態になった場合に前記応答として前記クライアントに送信する第２の応答手段を有する、
   　ことを特徴とする通信システム。
2. 　前記クライアントは、
   　　　　転送対象の情報リストの要求を前記第１の要求手段として送信することで、前記情報リストを取得する第１の取得手段と、
   　　　　該第１の取得手段で得られた前記情報リストに示された各情報を前記サーバに要求することで、それぞれの情報を取得する第２の取得手段と、
   　　　　前記第２の要求手段に対する応答を受信した場合に、情報の受信に係る処理を終了する終了手段とを有する
   　ことを特徴とする請求項１に記載の通信システム。
3. 　前記サーバは、
   　　　前記情報リストの要求を受信した場合、前記転送対象をユーザが選択可能に一覧表示する第１の表示手段と、
   　　　前記一覧表示された情報の中から、ユーザが選択した情報を特定する情報を記述したリストを生成する生成手段とを含み、
   　前記第１の応答手段は、前記生成手段で生成した前記リストを前記情報リストとして応答する
   　ことを特徴とする請求項２に記載の通信システム。
4. 　前記サーバは、撮像手段と、当該撮像手段で撮像して得た画像を記憶する記憶手段とを有する撮像装置であって、
   　前記クライアントは、前記サーバから前記画像を受信するための携帯端末であり、
   　前記サーバ及び前記クライアントは、それぞれが無線通信手段を介して通信する
   　ことを特徴とする請求項１乃至３のいずれか１項に記載の通信システム。
5. 　前記第２の応答手段は、前記第２の要求手段による要求を受信した場合、情報の転送を中断するＵＩを表示する第２の表示手段を含み、前記ＵＩが操作された場合、前記所定の状態になったとして応答する
   　ことを特徴とする請求項１乃至４のいずれか１項に記載の通信システム。
6. 　前記第２の応答手段は、
   　　　前記第２の要求手段による要求を受信した場合、情報の転送を中断するＵＩを表示する第２の表示手段と、
   　　　予め設定された状態変化があるか否かを監視する監視手段とを含み、
   　　　前記ＵＩが操作された場合には当該操作が行われたこと表す応答、前記状態変化があった場合には状態変化があったこと表す応答を前記クライアントに応答し、
   　前記終了手段は、
   　　前記ＵＩの操作が行われたことを示す応答を受信した場合に、前記情報の受信に係る処理を終了し、前記ＵＩの操作の以外の状態変化を示す応答を受信した場合には前記第２の要求手段による再度の要求を行う
   　ことを特徴とする請求項２に記載の通信システム。
7. 　通信装置であって、
   　クライアントからコンテンツ要求を受信する第１の受信手段と、
   　前記第１の受信手段により前記コンテンツ要求を受信したことに応じて、前記コンテンツ要求に対応するコンテンツを前記クライアントに送信する第１の送信手段と、
   　前記クライアントから所定の要求を受信する第２の受信手段と、
   　前記第２の受信手段により、前記所定の要求を受信した場合、前記第１の送信手段によるコンテンツの送信処理を中断するためのＵＩを表示する表示手段と、
   　該表示手段で表示された前記ＵＩが操作された場合、前記所定の要求に対する所定の応答を前記クライアントに送信する第２の送信手段を有し、
   　前記第２の送信手段による応答の送信により、前記第１の送信手段によるコンテンツの送信処理は中断されることを特徴とする通信装置。
8. 　通信装置の制御方法であって、
   　クライアントからコンテンツ要求を受信する第１の受信工程と、
   　前記第１の受信工程により前記コンテンツ要求を受信したことに応じて、前記コンテンツ要求に対応するコンテンツを前記クライアントに送信する第１の送信工程と、
   　前記クライアントから所定の要求を受信する第２の受信工程と、
   　前記第２の受信工程により、前記所定の要求を受信した場合、前記第１の送信工程によるコンテンツの送信処理を中断するためのＵＩを表示する表示工程と、
   　該表示工程で表示された前記ＵＩが操作された場合、前記所定の要求に対する所定の応答を前記クライアントに送信する第２の送信工程を有し、
   　前記第２の送信工程による応答の送信により、前記第１の送信工程によるコンテンツの送信処理は中断されることを特徴とする通信装置の制御方法。
9. 　前記通信装置のプロセッサが読み込み実行することで、前記プロセッサに、請求項８に記載の方法の各工程を実行させるためのプログラム。
   
10. 　クライアント装置と通信するサーバ装置であって、
    　クライアント装置から所定の処理を実行するための第１の要求を受信する第１の受信手段と、
    　前記第１の受信手段により第１の要求を受信したことに応じて、前記所定の処理を開始する第１の処理手段と、
    　前記クライアント装置から、前記第１の処理手段による前記所定の処理を中断するための第２の要求を受信する第２の受信手段と、
    　前記第１及び第２の要求への応答の送信を制御する制御手段を有し、
    　前記制御手段は、前記第１の要求に応じて前記第１の処理手段が前記所定の処理を行う間は、前記第２のリクエストに対する応答を保留し、前記第１の処理手段が前記所定の処理を中断する場合は、前記保留されていた前記第２のリクエストに対する応答を送信する
    　ことを特徴とするサーバ装置。
11. 　前記第２の受信手段が前記第２の要求を受信したことに応じて、前記第１の処理手段による前記所定の処理を中断する指示を受け付けるための表示を行う表示手段と、を有する
    　ことを特徴とする請求項１０に記載のサーバ装置。
12. 　前記第１の処理手段は、前記表示手段により前記所定の処理を中断する指示を受け付けたことに応じて、前記所定の処理を中断する
    　ことを特徴とする請求項１１に記載のサーバ装置。
13. 　前記所定の処理は、前記第１の要求に応じて前記サーバ装置が有するコンテンツを前記クライアント装置に送信する処理である
    　ことを特徴とする請求項１０乃至１２の何れか１項に記載のサーバ装置。
14. 　前記第２の受信手段は、前記第１の受信手段が前記第１の要求を受信する前に、前記第２の要求を受信する
    ことを特徴とする請求項１０乃至１３の何れか１項に記載のサーバ装置。

Images