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

Description

本発明は、複数の通信装置の間でリクエストとレスポンスの送受信を行うシステムに関する。

ネットワーク上でのサービス提供形態の一つとして、サーバがクライアントから送信された要求を受け付け、要求に応じた処理を実行するものがある。サーバとクライアントとの間での通信には、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）の技術が利用されることがある。例えば、クライアントはサーバにＨＴＴＰリクエストを送信することで処理の要求を行い、サーバは要求に応じた処理を実行した後にＨＴＴＰレスポンスを送信することでクライアントに処理の完了を通知する。

ＨＴＴＰリクエストにより要求される処理の内容によっては、サーバによるリクエストの受信からレスポンスの送信までの時間が長くなることがある。特許文献１には、サーバが長い時間を要する処理を実行している間にクライアントから当該処理の結果を要求するリクエストを受信した場合に、当該処理が完了する前に、一時的にリクエストに応じられない旨のレスポンスを送信することが開示されている。

特開２０１３－２１０８０３号公報

サーバによるリクエストの受信からレスポンスの送信までの時間が長くなる場合、クライアントは、サーバが処理を実行中なのかリクエストがサーバに正しく受信されていないのかを判断できないままレスポンスを長時間待ち続けることになりうる。そのため、サーバがリクエストを正しく受信できていなかった場合には、クライアントが無駄に待機し続けることにより、システムにおける処理の遅延が大きくなる虞がある。また、リクエストがサーバに受信されていないと判断してクライアントがリクエストを再送した際に、実際にはサーバが処理を実行中である場合、リクエストに応じた処理をサーバが繰り返し実行してしまうことによりサーバの処理負荷が大きくなる。

一方、特許文献１に記載の技術では、クライアントはサーバに処理の結果を要求するリクエストを送信することで、サーバにおいてその処理が実行中であるか否かを確認することができる。しかしながら、サーバにおいて処理が完了したことを早く判断するためには、クライアントは、当該処理の完了を示すレスポンスを受信するまでリクエストを何度も送り直すことになりうる。そのため、クライアントの処理負荷が大きくなる虞がある。

本発明は、クライアントの処理負荷の増大を抑制しつつ、クライアントが送信したリクエストがサーバにより受信されたことと、当該リクエストに関する処理がサーバにより完了されたことを、クライアントが早く判断できるようにすることを目的とする。

上記の課題を解決するため、本発明に係る通信装置は、例えば以下の構成を有する。すなわち、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に従う通信を行う通信装置であって、前記通信装置に対して処理を要求するためのＨＴＴＰリクエストであって、要求される処理を識別するための識別情報を含むＨＴＴＰリクエストを、他の通信装置から受信する受信手段と、前記受信手段により前記ＨＴＴＰリクエストが受信されてから、前記ＨＴＴＰリクエストにより要求される処理の完了を示す第１のレスポンスを送信するまでの間に、第２のレスポンスを前記他の通信装置へ送信するかを、前記ＨＴＴＰリクエストに含まれる前記識別情報に応じて決定する決定手段と、前記決定手段による決定に応じて、前記第１のレスポンス及び前記第２のレスポンスを前記他の通信装置へ送信する送信手段とを有し、前記送信手段がデータをサーバ装置へ送信する処理を実行している最中に前記データの送信を要求するための前記ＨＴＴＰリクエストを受信した場合、前記送信手段は前記第２のレスポンスを送信し、前記サーバ装置への前記データの送信が完了した後に、前記データの格納先ＵＲＬを含む前記第１のレスポンスを送信する。

本発明によれば、クライアントの処理負荷の増大を抑制しつつ、クライアントが送信したリクエストがサーバにより受信されたことと、当該リクエストに関する処理がサーバにより完了されたことを、クライアントが早く判断できるようになる。

通信システム１０の構成例を示す図である。 サーバ装置１１０の機能構成例を示す図である。 クライアント装置１２０の機能構成例を示す図である。 サーバ装置１１０の動作について説明するためのフローチャートである。 情報保持部２１６が保持する情報の一例を示す図である。 クライアント装置１２０の動作について説明するためのフローチャートである。 サーバ装置１１０とクライアント装置１２０との間の通信に関するシーケンスの一例を示す図である。 サーバ装置１１０とクライアント装置１２０との間の通信に関するシーケンスの一例を示す図である。 サーバ装置１１０とクライアント装置１２０との間の通信に関するシーケンスの一例を示す図である。 通信システム２０の構成例を示す図である。 サーバ装置１１０の動作について説明するためのフローチャートである。 情報保持部２１６が保持する情報の一例を示す図である。 通信システム２０における通信に関するシーケンスの一例を示す図である。 サーバ装置１１０のハードウェア構成例について説明するための図である。

［システム構成］
以下、本発明の実施形態について、図面を参照して説明する。図１は、本実施形態に係る通信システム１０の構成を示す図である。本実施形態の通信システム１０においては、サーバ装置１１０とクライアント装置１２０とがネットワーク１００を介して有線または無線で接続され、相互に通信を行って、例えば静止画や動画等のコンテンツデータや各種操作指示のコマンドなどを送受信する。なお、図１に示す通信システム１０においては１台のサーバ装置１１０と１台のクライアント装置１２０とが接続されているが、接続形態はこれに限らない。例えば、１台のサーバ装置１１０と複数のクライアント装置１２０とが接続されていてもよいし、複数のサーバ装置１１０と１台のクライアント装置１２０とが接続されていてもよい。また、複数のサーバ装置１１０と複数のクライアント装置１２０とが接続されていてもよい。

ネットワーク１００はサーバ装置１１０とクライアント装置１２０が接続するネットワークである。本実施形態におけるネットワーク１００は、例えばインターネット、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、又はそれらの組み合わせにより実現される。なお、サーバ装置１１０とクライアント装置１２０は、ネットワーク１００を介さずに、直接接続されても良い。直接接続は例えば無線アドホックネットワークなどを用いて実現される。

サーバ装置１１０はＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）におけるサーバとして動作する。すなわちサーバ装置１１０は、クライアント装置１２０からＨＴＴＰリクエストを受信し、受信したリクエストに応じてクライアント装置１２０にＨＴＴＰレスポンスを送信する。クライアント装置１２０はＨＴＴＰにおけるクライアントとして動作する。すなわちクライアント装置１２０は、サーバ装置１１０へＨＴＴＰリクエストを送信し、サーバ装置から送信されたＨＴＴＰレスポンスを受信する。サーバ装置１１０及びクライアント装置１２０は具体的には、デジタルカメラ、ネットワークカメラ、プリンタ、複合機、テレビ、プロジェクタ、携帯電話、スマートフォン、及びＰＣなどである。例えば、クライアント装置１２０としてのスマートフォンが、サーバ装置１１０としてのネットワークカメラに、パン／チルトの制御や動画の撮影などの処理をＨＴＴＰリクエストにより要求する。サーバ装置１１０としてのネットワークカメラはＨＴＴＰリクエストを受信すると、要求に応じた処理を実行し、処理の完了を示すＨＴＴＰレスポンスをクライアント装置１２０としてのスマートフォンに送信する。このＨＴＴＰレスポンスを受信することで、スマートフォンは処理の完了を知ることができ、例えば処理結果に応じた次の処理の要求を行うことができる。ただし、サーバ装置１１０及びクライアント装置１２０の形態はこれらに限定されない。

ここで、サーバ装置１１０により実行される処理が長い時間を要する場合、クライアント装置１２０はリクエストを送信してからレスポンスを受信するまで長時間待機することになる。このようにレスポンスが長時間受信できない場合にクライアント装置１２０は、サーバ装置１１０が処理を実行中であるのかリクエストが正しくサーバ装置１１０に届いていないのかを判断できない。そこでクライアント装置１２０は、リクエストがサーバ装置１１０に正しく届いたか否かを確認するための問い合わせを新たにサーバ装置１１０に送信することで、リクエストの受信状況を確認することができる。しかしながらこの方法では、クライアント装置１２０が余分に通信を行うことになり、クライアント装置１２０の処理負荷やネットワーク１００の負荷が大きくなりうる。特に問い合わせの送信のためにユーザ操作が必要である場合には、ユーザの手間も増加する可能性がある。

そこで本実施形態において、サーバ装置１１０は、ＨＴＴＰリクエストを受信してから、そのＨＴＴＰリクエストにより要求される処理の完了を示すレスポンスを送信するまでの間に、暫定レスポンスをクライアント装置１２０へ送信する。これにより、サーバ装置１１０におけるリクエストの受信状況をクライアント装置１２０が容易に判断できるようになる。リクエストがサーバ装置１１０により受信され処理が実行中であるということを判断できれば、クライアント装置１２０は、新たに問い合わせを送信することなく処理の完了を示すレスポンスを待機し、効率的な通信が実現できる。また、リクエストがサーバ装置１１０により受信されていないということを判断できれば、クライアント装置１２０は、新たに問い合わせを送信することなくＨＴＴＰリクエストを再送し、サーバ装置１１０が処理を開始するまでの遅延を低減できる。

［装置構成］
図１４は、サーバ装置１１０のハードウェア構成を示すブロック図である。なお、クライアント装置１２０も、サーバ装置１１０と同様の構成である。サーバ装置１１０は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、補助記憶装置２０４、表示部２０５、操作部２０６、通信部２０７、及びバス２０８を有する。

ＣＰＵ２０１は、ＲＯＭ２０２やＲＡＭ２０３に格納されているコンピュータプログラムやデータを用いてサーバ装置１１０の全体を制御する。ＲＯＭ２０２は、変更を必要としないプログラムやパラメータを格納する。ＲＡＭ２０３は、補助記憶装置２０４から供給されるプログラムやデータ、及び通信部２０７を介して外部から供給されるデータなどを一時記憶する。補助記憶装置２０４は、例えばハードディスクドライブ等で構成され、静止画や動画などのコンテンツデータを記憶する。

表示部２０５は、例えば液晶ディスプレイやＬＥＤ等で構成され、ユーザがサーバ装置１１０を操作するためのＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）やエラー情報などを表示する。操作部２０６は、例えばキーボードやマウス、タッチパネル等で構成され、ユーザによる操作を受けて各種の指示をＣＰＵ２０１に入力する。通信部２０７は、クライアント装置１２０などの外部の装置と通信を行う。サーバ装置１１０が外部の装置と有線で接続される場合には、例えばＬＡＮケーブル等が通信部２０７に接続される。また、サーバ装置１１０が外部の装置と無線通信する機能を有する場合、通信部２０７はアンテナ等を備える。バス２０８は、中継装置１０１の各部を繋いで情報を伝達する。

なお、本実施形態ではＣＰＵ２０１がプログラムを実行することで通信部２０７を介したサーバ装置１１０と外部の装置との通信を制御するが、サーバ装置１１０と外部の装置との通信の少なくとも一部を通信部２０７がハードウェア処理により制御してもよい。また、本実施形態では表示部２０５と操作部２０６はサーバ装置１１０の内部に存在するが、表示部２０５及び操作部２０６の少なくとも一方がサーバ装置１１０の外部に別の装置として存在していてもよい。この場合、ＣＰＵ２０１が、表示部２０５を制御する表示制御部、及び操作部２０６を制御する操作制御部として動作する。また、サーバ装置１１０は図２に示す構成要素以外の構成要素を有していてもよい。例えば、サーバ装置１１０がネットワークカメラである場合、サーバ装置１１０はレンズや撮像センサにより構成される不図示の撮像部を有していてもよい。

図２は、サーバ装置１１０の機能構成を示す図である。図２に示すサーバ装置１１０の各機能部は、サーバ装置１１０のＣＰＵ２０１がＲＯＭ２０２やＲＡＭ２０３に格納されているプログラムを実行し、補助記憶装置２０４や通信部２０７などを制御することで実現される。リクエスト受信部２１１は、クライアント装置１２０から送信されるリクエストを受信する。リクエスト判定部２１２は、リクエスト受信部２１１により受信されたリクエストに、情報保持部２１６が保持する所定の識別情報が含まれているかを判定する。識別情報の詳細については図５等を用いて後述する。処理部２１３は、リクエスト受信部２１１により受信されたリクエストにより要求される処理など、サーバ装置１１０が有する機能に応じた各種の処理を実行する。暫定レスポンス送信部２１４は、リクエスト受信部２１１により受信されたリクエストに応じて、暫定レスポンスを送信する。完了レスポンス送信部２１５は、リクエスト受信部２１１により受信されたリクエストに応じた処理の完了を示す完了レスポンスを送信する。情報保持部２１６は、所定の識別情報を予め取得し保持する。

図３は、クライアント装置１２０の機能構成を示す図である。図３に示すクライアント装置１２０の各機能部は、クライアント装置１２０のＣＰＵ２０１がＲＯＭ２０２やＲＡＭ２０３に格納されているプログラムを実行し、補助記憶装置２０４や通信部２０７などを制御することで実現される。リクエスト送信部３２１は、サーバ装置１１０へＨＴＴＰリクエストを送信する。レスポンス受信部３２２は、リクエスト送信部３２１により送信されたリクエストに応じてサーバ装置１１０から送信されるレスポンスを受信する。レスポンス判定部３２３は、レスポンス受信部３２２により受信されたレスポンスが暫定レスポンスか否かを判定する。

［動作フロー］
次に、サーバ装置１１０及びクライアント装置１２０の動作フローについて説明する。図４は、クライアント装置１２０とのＨＴＴＰ通信における、サーバ装置１１０の動作を説明するためのフローチャートである。図４に示す処理は、サーバ装置１１０のＣＰＵ２０１がＲＯＭ２０２に格納されたプログラムをＲＡＭ２０３に展開して実行することで実現される。ただし、以下で説明する処理の少なくとも一部が、ＣＰＵ２０１とは異なる専用のハードウェアにより実現されてもよい。図４に示す処理は、サーバ装置１１０とクライアント装置１２０との間でＨＴＴＰコネクションなどの接続が確立されたタイミングで開始され、サーバ装置１１０がクライアント装置１２０からＨＴＴＰリクエストを受信するたびに実行される。ただし図４の処理の開始タイミングはこれに限定されない。

Ｓ４１１においてリクエスト受信部２１１は、クライアント装置１２０から、サーバ装置１１０に対して処理を要求するためのＨＴＴＰリクエストを受信する。ここで受信されるＨＴＴＰリクエストには、要求される処理を識別するための識別情報が含まれる。Ｓ４１２においてリクエスト判定部２１２は、Ｓ４１１において受信されたＨＴＴＰリクエストを解析し、ＨＴＴＰリクエストに含まれる識別情報と情報保持部２１６が保持している所定の識別情報とが合致するかを判定する。具体的には、ＨＴＴＰリクエストが所定のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）とメソッドを示す情報を含んでいれば、識別情報は合致すると判定され（Ｓ４１２でＹＥＳ）、Ｓ４１４へ進む。Ｓ４１４へ進む場合は、以下で説明するように、サーバ装置１１０からクライアント装置１２０へ暫定レスポンスが送信されるフローとなる。一方、ＨＴＴＰリクエストが所定のＵＲＬとメソッドを示す情報を含んでいなければ、識別情報は合致しないと判定され（Ｓ４１２でＮＯ）、Ｓ４１３へ進む。Ｓ４１３へ進む場合は、以下で説明するように、サーバ装置１１０からクライアント装置１２０へ暫定レスポンスが送信されないフローとなる。所定の識別情報の詳細については図５を用いて後述する。

本実施形態において、所定のＵＲＬとメソッドを示す情報を含むＨＴＴＰリクエストは、長い時間を要する処理を要求するためのリクエストである。長い時間を要する処理とは例えば、サーバ装置１１０が有する撮影部による静止画の連続撮影処理、動画の撮影処理、撮影された画像の変換処理、及び撮影部による撮影の方向（パン及びチルト）又はズーム率を変更する処理などである。

サーバ装置１１０は、長い時間を要する処理を要求するための識別情報を含むＨＴＴＰリクエストを受信した場合には、以降の処理において暫定レスポンスをクライアント装置１２０へ送信することで、リクエストの受信をクライアント装置１２０に通知する。一方、サーバ装置１１０が短い時間で完了可能な処理を要求するための識別情報を含むＨＴＴＰリクエストを受信した場合には、処理の完了を示すレスポンスをクライアント装置１２０が長時間待ち続けることにならない。そのため、サーバ装置１１０は暫定レスポンスを送信しない。このように、サーバ装置１１０は、暫定レスポンスをクライアント装置１２０へ送信するか否かを、受信したＨＴＴＰリクエストに含まれる識別情報に応じて決定する。これにより、サーバ装置１１０が受信したすべてのＨＴＴＰリクエストに応じて暫定レスポンスを送信する場合と比較して、サーバ装置１１０の処理負荷やネットワーク１００における通信データ量を低減することができる。

なお、サーバ装置１１０が暫定レスポンスを送信するか否かを決定するための基準は、受信したＨＴＴＰリクエストに含まれる識別情報と情報保持部２１６が保持する識別情報とが合致するか否かに限らない。例えばサーバ装置１１０は、識別情報が合致しない場合であっても、サーバ装置１１０が他の処理を実行中であるなどの理由により完了レスポンスが遅れることが見込まれる場合には、暫定レスポンスを送信すると決定してもよい。また例えば、識別情報が合致する場合であっても、要求された処理をすでに実行済みであるなどの理由により完了レスポンスを直ちに送信できる場合には、暫定レスポンスを送信しないと決定してもよい。

Ｓ４１３において処理部２１３は、クライアント装置１２０から受信したリクエストにより要求される処理を実施する。Ｓ４１８において完了レスポンス送信部２１５は、要求された処理の完了を示すＨＴＴＰレスポンスをクライアント装置１２０へ送信する。なお、リクエストにより要求される処理がレスポンスを送信する処理のみである場合には、Ｓ４１３のステップは省略されＳ４１８においてレスポンスが送信される。Ｓ４１８の処理が実行されると、図４の処理を終了する。このように、サーバ装置１１０は、暫定レスポンスをクライアント装置１２０へ送信しないと決定した場合には、暫定レスポンスを送信することなく完了レスポンスをクライアント装置１２０へ送信する。そのため、暫定レスポンスの送信に係るサーバ装置１１０の処理負荷を削減しつつ、クライアント装置１２０はＨＴＴＰリクエストがサーバ装置１１０により処理されたことを完了レスポンスの受信により知ることができる。

Ｓ４１４において暫定レスポンス送信部２１４は、Ｓ４１１におけるＨＴＴＰリクエストの受信に応じた暫定レスポンスをクライアント装置１２０へ送信する。暫定レスポンスは例えば、ステータスコードが１００ ＣｏｎｔｉｎｕｅであるＨＴＴＰレスポンスである。ただし、暫定レスポンスの内容はこれに限らない。Ｓ４１５において処理部２１３は、クライアント装置１２０から受信したリクエストにより要求される処理を開始する。なお、Ｓ４１４とＳ４１５の順番は逆転していてもよい。

Ｓ４１６において完了レスポンス送信部２１５は、Ｓ４１５で開始した処理の完了まで待機する。なお、ＨＴＴＰリクエストにより要求された処理が完了する前に、サーバ装置１１０とクライアント装置１２０との間における通信セッションがアライブではないと判定された場合、処理部２１３は実行中の処理を中断してもよい。通信セッションがアライブではないと判断される場合とは、例えばＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）のコネクションが切断された場合などである。また、要求された処理が完了する前に、クライアント装置１２０がサーバ装置１１０へ、送信済みのリクエストを取り消す要求を送信した場合にも、処理部２１３は実行中の処理を中断してもよい。

Ｓ４１７にて完了レスポンス送信部２１５は、クライアント装置１２０から受信したリクエストに応じた処理の完了を示す完了レスポンスをクライアント装置１２０へ送信する。完了レスポンスは、例えば、ステータスコードが２００ ＯＫであるＨＴＴＰレスポンスである。なお、完了レスポンスには、処理の完了を示す情報に加えて、処理結果を示す情報などが含まれていてもよい。また、完了レスポンスの内容はこれに限らず、例えばリクエストの内容やサーバ装置１１０の状態、及び処理結果などに応じて異なるステータスコードを含むレスポンスが完了レスポンスとして送信されてもよい。また、サーバ装置１１０が要求された処理を途中で中断した場合には、例えば４０６ Ｎｏｔ Ａｃｃｅｐｔａｂｌｅや４０８ Ｒｅｑｕｅｓｔ Ｔｉｍｅｏｕｔなどのステータスコードを含むエラーレスポンスが完了レスポンスの代わりに送信される。以上により、図４の処理が終了する。

ここで、Ｓ４１２における判定処理に関連する、情報保持部２１６が保持する所定の識別情報について、図５を用いて説明する。本実施形態において、クライアント装置１２０から送信されるＨＴＴＰリクエストには、そのＨＴＴＰリクエストのメソッドを示す情報と、そのＨＴＴＰリクエストにより要求される処理の内容を特定するためのＵＲＬとが含まれる。情報保持部２１６は、ＨＴＴＰリクエストに含まれ得るＵＲＬとメソッドを示す情報のうち、所定のＵＲＬとＨＴＴＰリクエストのメソッドを示す情報の組を、所定の識別情報として保持する。ただしこれに限らず、識別情報はＵＲＬ又はメソッドの何れか一方のみで表されていてもよいし、ＵＲＬの代わりにＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）などが用いられてもよい。また識別情報はこの他の形式の情報であってもよく、ＨＴＴＰリクエストにより要求される処理の種別や内容を識別するための情報であればよい。

エントリ５０１の識別情報は、ｈｔｔｐ：／／ｘｘｘ／ｔａｋｅＰｉｃというＵＲＬと、ＰＯＳＴのメソッドを示す情報で表現される。すなわち、Ｓ４１２において解析されるＨＴＴＰリクエストが、ＰＯＳＴメソッドのリクエストであり、且つｈｔｔｐ：／／ｘｘｘ／ｔａｋｅＰｉｃというＵＲＬを含むリクエストである場合には、Ｓ４１２の判定はＹＥＳとなる。なお、エントリ５０１の識別情報は、写真の連続撮影を意味する。また、ＨＴＴＰリクエストに含まれるＵＲＬには、末尾にクエリ情報が記載されていてもよい。例えば、クライアント装置１２０から送信されるＨＴＴＰリクエストが、サーバ装置１１０による５枚の写真の連続撮影を要求するリクエストである場合、ＨＴＴＰリクエストにはｈｔｔｐ：／／ｘｘｘ／ｔａｋｅＰｉｃ？ｎｕｍ＝５というＵＲＬが含まれる。この場合も、ＨＴＴＰリクエストはエントリ５０１の識別情報と合致する情報を含むものと判定される。

エントリ５０２の識別情報は、サーバ装置１１０が有する撮像部の光学ズームを要求するためのリクエストに対応する。例えば、２００％の光学ズームを要求するためのＨＴＴＰリクエストには、ｈｔｔｐ：／／ｘｘｘ／ｚｏｏｍ？ｒａｔｅ＝２００というＵＲＬと、ＰＯＳＴメソッドを示す情報が含まれる。エントリ５０３は、サーバ装置１１０による動画の録画を要求するためのリクエストに対応する。例えば、１０秒間の動画録画を要求するためのＨＴＴＰリクエストには、ｈｔｔｐ：／／ｘｘｘ／ｒｅｃ？ｔｉｍｅ＝１０というＵＲＬと、ＰＯＳＴメソッドを示す情報が含まれる。

本実施形態において、情報保持部２１６が保持する所定の識別情報は、所定の時間長より長い時間を要する処理に対応する識別情報である。具体的には、サーバ装置１１０は、所定の時間長を指定するユーザによる操作やクライアント装置からの指示を受け付け、サーバ装置１１０が実行可能な処理のうち指定された時間長より長い時間を要する処理に対応する識別情報を情報保持部２１６に保持する。ただし、情報保持部２１６が保持する所定の識別情報の決定方法はこれに限らない。例えば、ユーザ操作やクライアント装置からの指示により処理の内容や識別情報そのものが指定され、サーバ装置１１０は指定に応じた識別情報を情報保持部２１６に保持してもよい。また、サーバ装置１１０が自装置の動作モードや実行中の処理の内容に基づいて、情報保持部２１６に保持する情報を自動で決定及び更新してもよい。図５に示す所定の識別情報の例は何れもメソッドがＰＯＳＴとなっているが、これに限らず、ＰＵＴやＮＯＴＩＦＹなどのメソッドに対応する識別情報が情報保持部２１６に保持されていてもよい。

次に、クライアント装置１２０の動作フローについて、図６を用いて説明する。図６に示す処理は、クライアント装置１２０のＣＰＵ２０１がＲＯＭ２０２に格納されたプログラムをＲＡＭ２０３に展開して実行することで実現される。ただし、以下で説明する処理の少なくとも一部が、ＣＰＵ２０１とは異なる専用のハードウェアにより実現されてもよい。図６に示す処理は、サーバ装置１１０とクライアント装置１２０との間でＨＴＴＰコネクションなどの接続が確立されたタイミングで開始され、クライアント装置１２０からサーバ装置１１０へＨＴＴＰリクエストを送信すべきイベントが発生する度に実行される。ただし図６の処理の開始タイミングはこれに限定されない。

Ｓ６２１においてリクエスト送信部３２１は、サーバ装置１１０へＨＴＴＰリクエストを送信する。Ｓ６２２においてレスポンス受信部３２２は、サーバ装置１１０からのレスポンスを受信する。なお、レスポンスを受信したクライアント装置１２０は、クライアント装置１２０を操作するユーザに対し、サーバ装置１１０からレスポンスを受信したこと、即ちＨＴＴＰリクエストがサーバ装置１１０により受信されたことを、表示や音により通知してもよい。Ｓ６２３においてレスポンス判定部３２３は、Ｓ６２２において受信したレスポンスが暫定レスポンスであるかを判定する。例えば、受信したレスポンスのステータスコードが１００ Ｃｏｎｔｉｎｕｅであれば、Ｓ６２３の判定はＹＥＳとなり、Ｓ６２４へ進む。一方、受信したレスポンスのステータスコードが１００ Ｃｏｎｔｉｎｕｅでなければ、図６の処理を終了する。

Ｓ６２４においてレスポンス受信部３２２は、サーバ装置１１０から完了レスポンスを受信するまで待機する。Ｓ６２５においてレスポンス受信部３２２は、サーバ装置１１０から送信された完了レスポンスを受信する。なお、サーバ装置１１０から完了レスポンスの代わりにエラーレスポンスが送信された場合には、Ｓ６２５においてレスポンス受信部３２２はエラーレスポンスを受信する。以上により図６処理が終了する。

［通信シーケンス］
図７は、通信システム１０において実行される通信シーケンスの例を示す。サーバ装置１１０及びクライアント装置１２０が、図４及び図６を用いて上述した動作を実行することで、図７に示す通信シーケンスが実現される。Ｓ７０１において、クライアント装置１２０のリクエスト送信部３２１がＨＴＴＰリクエストを送信し、サーバ装置１１０のリクエスト受信部２１１はそのＨＴＴＰリクエストを受信する。ここで送信されるＨＴＴＰリクエストには、図５に示すような情報保持部２１６により保持される所定の識別情報が含まれる。

Ｓ７０２において、サーバ装置１１０のリクエスト判定部２１２はリクエストに所定の識別情報が含まれていると判定し、暫定レスポンス送信部２１４は受信したリクエストに対する暫定レスポンスを送信する。クライアント装置１２０のレスポンス受信部３２２は送信されたレスポンスを受信し、レスポンス判定部３２３はそのレスポンスが暫定レスポンスであると判定する。

Ｓ７０３において、サーバ装置１１０の処理部２１３はリクエストにより要求された処理を完了する。Ｓ７０４において、サーバ装置１１０の完了レスポンス送信部２１５は完了レスポンスを送信し、クライアント装置１２０のレスポンス受信部３２２はそのレスポンスを受信する。なお、サーバ装置１１０はＨＴＴＰリクエストにより要求される処理が完了した後に完了レスポンスを送信してもよいし、完了レスポンスの送信自体が要求される処理の一部又は全部であってもよい。また、サーバ装置１１０は要求された処理が正常に完了できると判断した場合に、その処理の完了前に完了レスポンスを送信してもよい。また、Ｓ７０２における暫定レスポンスの送信回数は１回でなくてもよく、例えばサーバ装置１１０は、Ｓ７０１におけるＨＴＴＰリクエストの受信からＳ７０４における完了レスポンスの送信までの間、一定期間ごとに暫定レスポンスを送信してもよい。

このように、クライアント装置１２０は、Ｓ７０２において暫定レスポンスを受信することで、Ｓ７０１において送信したＨＴＴＰリクエストがサーバ装置１１０により受信されたことを判断することができる。そのためクライアント装置１２０は、リクエストが正しく受信されたかを確認するための余分な通信などを行うことなく、サーバ装置１１０からのレスポンスを待機する。そしてクライアント装置１２０は、Ｓ７０４において完了レスポンスを受信することで、Ｓ７０１において送信したＨＴＴＰリクエストにより要求される処理がサーバ装置１１０により完了されたことを判断することができる。

なお、Ｓ７０２において送信される暫定レスポンスは例えばステータスコードが１００ ＣｏｎｔｉｎｕｅのＨＴＴＰレスポンスであり、Ｓ７０４において送信される完了レスポンスは例えばステータスコードが２００ ＯＫのＨＴＴＰレスポンスである。ただし、暫定レスポンスと完了レスポンスの内容はこれに限定されない。例えば、サーバ装置１１０は、ステータスコードが１００から１９９のうち何れかであるＨＴＴＰレスポンスを暫定レスポンスとして送信し、ステータスコードが２００から５９９のうち何れかであるＨＴＴＰレスポンスを完了レスポンスとして送信してもよい。ここで、１００から１９９のステータスコードは、リクエストが受け付けられて処理が継続されることを示す。一方、２００から５９９のステータスコードは、リクエストの処理が完了されたこと、リクエストの処理の完了のために追加的な処理が必要なこと、又はリクエストの内容又はリクエストの処理にエラーがあることを示す。

また例えば、サーバ装置１１０は、暫定レスポンスとしてＨＴＴＰレスポンスの一部分を送信し、完了レスポンスとしてそのＨＴＴＰレスポンスの残りの部分を送信してもよい。具体的には、サーバ装置１１０は、ステータスコードが２００ ＯＫのＨＴＴＰレスポンスのステータスライン及びヘッダを暫定レスポンスとして送信し、完了レスポンスとしてそのＨＴＴＰレスポンスのボディを送信してもよい。なお、暫定レスポンスは、ＨＴＴＰレスポンスのボディの一部を含んでいてもよいし、ステータスラインのみを含んでいてもよい。

このような方法によっても、暫定レスポンスと完了レスポンスとがそれぞれ別のＨＴＴＰレスポンスとして送信される場合と同様の効果が得られる。すなわち、クライアント装置１２０は、ＨＴＴＰレスポンスのステータスライン及びヘッダを受信することで、ＨＴＴＰリクエストがサーバ装置１１０により受信されたことを判断できる。また、クライアント装置１２０は、ＨＴＴＰレスポンスのボディを受信することで、ＨＴＴＰリクエストにより要求される処理がサーバ装置１１０により完了されたことを判断できる。またこの方法によれば、暫定レスポンスと完了レスポンスとがそれぞれ独立したＨＴＴＰレスポンスとして送信される場合と比較して、通信システム１０内のデータ通信量を削減することができる。

また、図８は、暫定レスポンスとしてサーバ装置１１０からクライアント装置１２０へストリーム予約の要求が送信され、完了レスポンスとして予約されたストリームを用いたプッシュレスポンスが送信される場合の通信シーケンスの例を示す。図７を用いて説明したシーケンスにおける処理と同様の処理については、同じ符号を付している。

ＨＴＴＰに基づく通信規格であるＨＴＴＰ／２においては、サーバから送信可能なデータとしてＰＵＳＨ＿ＰＲＯＭＩＳＥフレームが規定されている。サーバはクライアントにＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを送信することで、論理的な接続であるストリームの予約を要求する。そしてサーバは、クライアントからの新たなリクエストを待つことなく、予約されたストリームを用いて任意のタイミングでクライアントにデータをプッシュすることができる。これにより、サーバからクライアントへのプッシュ型のデータ送信であるサーバープッシュが実現される。

ＨＴＴＰ／２において規定されるこのような機能を用いることで、本実施形態における暫定レスポンスと完了レスポンスを実現することができる。図８に示す通信シーケンスのＳ８０２において、サーバ装置１１０は、Ｓ７０１におけるクライアント装置１２０からのＨＴＴＰリクエストの受信に応じてＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを含む暫定レスポンスを送信する。ここで送信されるＰＵＳＨ＿ＰＲＯＭＩＳＥフレームには、予約するストリームの番号が記載されている。そしてサーバ装置１１０は、Ｓ７０３においてリクエストに応じた処理が完了したことに応じて、Ｓ８０４においてクライアント装置１２０へプッシュレスポンスを送信する。ここで送信されるプッシュレスポンスは、Ｓ８０２におけるＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを含む暫定レスポンスにより予約されたストリームを用いて送信されるレスポンスであり、リクエストに応じた処理の完了を示す。なお、プッシュレスポンスには、リクエストに応じた処理の結果に関するデータが含まれていてもよい。

このように、暫定レスポンスとしてサーバ装置１１０からクライアント装置１２０へストリーム予約の要求が送信され、完了レスポンスとしてプッシュレスポンスが送信される場合にも、図７に示す通信シーケンスを実行する場合と同様の効果が得られる。すなわち、クライアント装置１２０は、ストリーム予約の要求を受信することで、リクエストがサーバ装置１１０により受信されたことを判断できる。また、クライアント装置１２０は、プッシュレスポンスを受信することで、ＨＴＴＰリクエストにより要求される処理がサーバ装置１１０により完了されたことを判断できる。またこの方法によれば、サーバ装置１１０はより柔軟なタイミングで完了レスポンスを送信することができる。

図９は、ＨＴＴＰ／２におけるサーバープッシュを用いる通信シーケンスの別の例を示す。図７を用いて説明したシーケンスにおける処理と同様の処理については、同じ符号を付している。サーバ装置１１０は、Ｓ７０１におけるＨＴＴＰリクエストの受信に応じて、Ｓ９０２においてステータスコードが１００ ＣｏｎｔｉｎｕｅのＨＴＴＰレスポンスを暫定レスポンスとして送信する。その後Ｓ９０３において、サーバ装置１１０は、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームをクライアント装置１２０へ送信することでストリームを予約する。そしてサーバ装置１１０は、予約されたストリームを用いてＳ９０４においてプッシュレスポンスをクライアント装置１２０へ送信することで、Ｓ７０３における処理の完了をクライアント装置１２０に通知する。

このような通信シーケンスにおいても、図７に示す通信シーケンスを実行する場合と同様の効果が得られる。すなわち、クライアント装置１２０は、ステータスコードが１００ ＣｏｎｔｉｎｕｅのＨＴＴＰレスポンスを受信することで、ＨＴＴＰリクエストがサーバ装置１１０により受信されたことを判断できる。また、クライアント装置１２０は、プッシュレスポンスを受信することで、ＨＴＴＰリクエストにより要求される処理がサーバ装置１１０により完了されたことを判断できる。

また、図８や図９においてはプッシュレスポンスを完了レスポンスとして送信する場合の例を示しているが、ＨＴＴＰ／２におけるサーバープッシュを用いる場合において、サーバ装置１１０はプッシュレスポンスとは別に完了レスポンスを送信してもよい。具体的には、サーバ装置１１０は、暫定レスポンスとしてＰＵＳＨ＿ＰＲＯＭＩＳＥフレームをクライアント装置１２０へ送信し、予約されたストリームを用いたプッシュレスポンスを送信し、さらにその後に完了レスポンスを送信してもよい。ここで送信される完了レスポンスは、例えばステータスコードが２００ ＯＫのＨＴＴＰレスポンスなどである。

以上説明したように、本実施形態に係るサーバ装置１１０は、クライアント装置１２０との間でＨＴＴＰに従う通信を行う。具体的には、サーバ装置１１０は、サーバ装置１１０に対して処理を要求するためのＨＴＴＰリクエストであって、要求される処理を識別するための識別情報を含むＨＴＴＰリクエストを、クライアント装置１２０から受信する。またサーバ装置１１０は、ＨＴＴＰリクエストが受信されてから、当該ＨＴＴＰリクエストにより要求される処理の完了を示す第１のレスポンスを送信するまでの間に、第２のレスポンスをクライアント装置１２０へ送信するかを決定する。当該決定は、ＨＴＴＰリクエストに含まれる識別情報に応じて行われる。そしてサーバ装置１１０は、当該決定に応じて、第１のレスポンス及び第２のレスポンスをクライアント装置１２０へ送信する。

このような構成によれば、クライアント装置１２０がサーバ装置１１０にリクエストを送信してから、サーバ装置１１０により当該リクエストが受信されたことをクライアント装置１２０が判断可能となるまでの時間を、短くすることができる。そのため、サーバ装置１１０がリクエストを正しく受信できていない場合にクライアント装置１２０がレスポンスを待ち続けるようなことが抑制でき、遅延が低減された効率的な通信が実現できる。また、サーバ装置１１０によりレスポンスが受信されたか否かを問い合わせるためのリクエストをクライアント装置１２０が別途送信する場合と比較して、クライアント装置の処理負荷を低減することができる。

また、図７から図９を用いて説明したように、本実施形態におけるサーバ装置１１０は、ＨＴＴＰ（ＨＴＴＰ／２を含む）において規定される形式のメッセージを従来とは異なる方法で用いることにより、暫定レスポンスと完了レスポンスを実現する。これによりサーバ装置１１０は、リクエストとレスポンスが１対１に対応するのが通常であるＨＴＴＰの通信方式に則りながらも、単一のリクエストに対して２種類のレスポンスを送信することができる。またサーバ装置１１０は、クライアント装置１２０が標準的でない特別なコマンドを理解する機能を有していなくても、ＨＴＴＰに従う通信に対応していれば、リクエストの受信や処理の完了をクライアントに通知することができる。

［変形例］
なお、上記の説明においては、サーバ装置１１０がクライアント装置１２０から受信したＨＴＴＰリクエストにより要求される処理を完了した際に完了レスポンスを送信する場合を中心に説明した。ただしこれに限らず、サーバ装置１１０は、クライアント装置１２０から受信したＨＴＴＰリクエストに関係する処理であって、そのＨＴＴＰリクエストにより要求される処理とは別の処理が完了した際に、完了レスポンスを送信してもよい。以下ではこの場合の例について具体的に説明する。

図１０は、通信システム１０の変形例である通信システム２０の構成を示す。通信システム２０においては、図１に示した通信システム１０の構成に加えて、ネットワーク１００にストレージ装置１３０が接続されている。ストレージ装置１３０は、画像や音声などのコンテンツを記憶可能な装置であり、ネットワーク１００を介してサーバ装置１１０及びクライアント装置１２０と通信可能である。

図１１は、通信システム２０におけるサーバ装置１１０の動作を説明するためのフローチャートである。図１１に示す処理は、サーバ装置１１０のＣＰＵ２０１がＲＯＭ２０２に格納されたプログラムをＲＡＭ２０３に展開して実行することで実現される。ただし、以下で説明する処理の少なくとも一部が、ＣＰＵ２０１とは異なる専用のハードウェアにより実現されてもよい。図１１に示す処理は、サーバ装置１１０とクライアント装置１２０との間でＨＴＴＰコネクションなどの接続が確立され、且つサーバ装置１１０の処理部２１３が所定の処理を開始したタイミングで実行される。以下では所定の処理がサーバ装置１１０からストレージ装置１３０への動画データの送信処理である場合を中心に説明するが、所定の処理の内容はこれに限らない。また、図１１の処理の開始タイミングもこれに限定されない。以下では、図４を用いて説明した処理フローとの差異を中心に説明する。

Ｓ１１１０において、情報保持部２１６は、処理部２１３により実行中の所定の処理の対象となっているコンテンツへのアクセスが必要な別の処理を要求するためのＨＴＴＰリクエストに対応する識別情報を新たに格納する。例えば、実行中の所定の処理がストレージ装置１３０への動画データの送信処理である場合に、その動画データをクライアント装置１２０へ送信する処理に対応する識別情報や、その動画データを削除する処理に対応する識別情報が新たに格納される。ここで格納される識別情報の具体例については、図１２を用いて後述する。

なお、処理部２１３により実行される所定の処理は、動画データの送信に限らず、動画以外のメディアデータや、アプリケーションを動かすためのアプリケーションデータ、又は装置の動作履歴を示すログデータなどのコンテンツを送信する処理であってもよい。また、所定の処理はコンテンツの送信処理に限らず、コンテンツのエンコード、デコード又は編集などの、コンテンツを変換する処理であってもよい。また、所定の処理は、動画データを生成するための動画撮影など、コンテンツを生成する処理であってもよい。

Ｓ４１１及びＳ４１２においては、図４を用いて上述した処理と同様に、サーバ装置１１０は、クライアント装置１２０からＨＴＴＰリクエストを受信し、そのリクエストが情報保持部２１６により保持されている識別情報と合致する情報を含むかを判定する。Ｓ４１２の判定結果がＹＥＳとなる場合はＳ４１４に進む。Ｓ４１４に進む場合とは、例えば、ＨＴＴＰリクエストにより要求されるコンテンツと処理部２１３がストレージ装置１３０へ送信中であるコンテンツとが同一である場合などである。一方、Ｓ４１２の判定結果がＮＯとなる場合はＳ１１１３に進む。Ｓ１１１３に進んだ場合、完了レスポンス送信部２１５はリクエストに応じたレスポンスをクライアント装置１２０へ送信し、図１１の処理を終了する。

Ｓ４１４において、暫定レスポンス送信部２１４は、Ｓ４１１におけるＨＴＴＰリクエストの受信に応じた暫定レスポンスをクライアント装置１２０へ送信する。この暫定レスポンスには、処理部２１３が所定の処理を実行中であることを示す情報が含まれていてもよい。Ｓ１１１５において完了レスポンス送信部２１５は、処理部２１３により実行中の所定の処理が完了するまで待機する。Ｓ１１１６において完了レスポンス送信部２１５は、クライアント装置１２０へ完了レスポンスを送信する。この完了レスポンスには、処理部２１３による所定の処理の完了を示す情報が含まれていてもよい。また、完了レスポンスには、コンテンツの送信先であるストレージ装置１３０の情報など、所定の処理の結果を示す情報が含まれていてもよい。処理部２１３による所定の処理が途中で中断した場合においては、完了レスポンスの代わりにエラーレスポンスが送信されてもよい。

なお、Ｓ１１１０において情報保持部２１６は、処理部２１３により実行中の所定の処理が所定の時間長より長い時間を要する処理である場合にのみ、識別情報を新たに格納してもよい。具体的には、処理部２１３により送信中である動画データが所定の時間長より長い場合や、所定のデータサイズより大きい場合に、情報保持部２１６は当該動画データの取得や削除を要求する処理に対応する識別情報を新たに格納してもよい。そうでない場合には、当該動画データの取得や削除を要求する処理に対応する識別情報を新たに格納しなくてもよい。

図１２は、Ｓ１１１０において情報保持部２１６が新たに格納する識別情報の一例を示す。ここでは、処理部２１３により実行中の処理が動画データ１．ｍｐｇをストレージ装置１３０へ送信する処理であるものとする。エントリ１２０１の識別情報は、動画データ１．ｍｐｇの送信要求に対応するＵＲＬとメソッドの組である。エントリ１２０２の識別情報は、サーバ装置１１０が有する動画データの削除要求に対応するＵＲＬとメソッドの組である。例えば動画データ１．ｍｐｇの削除を要求するためのＨＴＴＰリクエストには、ｈｔｔｐ：／／ｘｘｘ／ｄｅｌ？ｎｏ＝１というＵＲＬと、ＰＯＳＴメソッドを示す情報が含まれる。なお、Ｓ１１１０において新たに格納される識別情報はこれらの例に限定されず、処理部２１３により実行中の処理の対象となっているコンテンツへのアクセスが必要なリクエストに対応する識別情報であればよい。

図１３は、通信システム２０において実行される通信シーケンスの例を示す。サーバ装置１１０及びクライアント装置１２０が、図１１及び図６を用いて上述した動作を実行することで、図１３に示す通信シーケンスが実現される。Ｓ１３００において、サーバ装置１１０の処理部２１３は、ストレージ装置１３０への動画データの送信を開始する。Ｓ７０１において、クライアント装置１２０のリクエスト送信部３２１は、サーバ装置１１０からストレージ装置１３０へ送信中の動画データを要求するためのＨＴＴＰリクエストを送信し、サーバ装置１１０はそのＨＴＴＰリクエストを受信する。Ｓ１３０２において、サーバ装置１１０の暫定レスポンス送信部２１４は、Ｓ７０１におけるＨＴＴＰリクエストに応じた暫定レスポンスをクライアント装置１２０へ送信する。送信される暫定レスポンスは、例えばステータスコードが１００ ＣｏｎｔｉｎｕｅのＨＴＴＰレスポンスであってもよいし、上述したＰＵＳＨ＿ＰＲＯＭＩＳＥフレームやＨＴＴＰレスポンスのヘッダであってもよい。

Ｓ１３０３において、サーバ装置１１０の処理部２１３は、Ｓ１３００において開始した動画データの送信処理を完了する。送信処理の完了の後、Ｓ１３０４において、サーバ装置１１０の完了レスポンス送信部２１５は、Ｓ７０１におけるＨＴＴＰリクエストに応じた完了レスポンスをクライアント装置１２０へ送信する。完了レスポンスは、ステータスコードが２００ ＯＫのＨＴＴＰレスポンスであってもよいし、上述したプッシュメッセージやＨＴＴＰレスポンスのボディであってもよい。また、サーバ装置１１０は、Ｓ７０１におけるＨＴＴＰリクエストにより要求された動画データを完了レスポンスとしてクライアント装置１２０へ送信してもよい。

また、Ｓ１３０４において送信される完了レスポンスは、処理部２１３による動画データの送信先であるストレージ装置１３０へのアクセスを促すステータスコード３０８ Ｐｅｒｍａｎｅｎｔ Ｒｅｄｉｒｅｃｔを含むＨＴＴＰレスポンスであってもよい。ステータスコードが３０８ Ｐｅｒｍａｎｅｎｔ Ｒｅｄｉｒｅｃｔの場合、完了レスポンスは、ストレージ装置１３０内の動画データの所在を示すＵＲＬを含んでいてもよい。そして、完了レスポンスを受信したクライアント装置１２０は、ストレージ装置１３０に動画データを要求するためのリクエストを送信し、動画データを取得してもよい。

このように、クライアント装置１２０へのコンテンツの送信をサーバ装置１１０でなくストレージ装置１３０が実行することで、サーバ装置１１０の処理負荷を低減することができる。サーバ装置１１０がデジタルカメラでありストレージ装置１３０が高速なネットワークに接続されたＰＣである場合など、サーバ装置１１０よりもストレージ装置１３０の通信性能が高い場合には、クライアント装置１２０への動画データの送信時間も低減できる。

以上のように、サーバ装置１１０は、サーバ装置１１０装置に対してコンテンツを要求するためのＨＴＴＰリクエストをクライアント装置１２０から受信する。そしてサーバ装置１１０は、受信されたＨＴＴＰリクエストにより要求されるコンテンツに対してサーバ装置１１０が所定の処理を実行中である場合に当該ＨＴＴＰリクエストに応じた第１のレスポンスをクライアント装置１２０へ送信する。さらにサーバ装置１１０は、当該所定の処理が完了した後に当該ＨＴＴＰリクエストに応じた第２のレスポンスをクライアント装置１２０へ送信する。

これにより、クライアント装置１２０から送信されたリクエストに対するレスポンスがサーバ装置１１０により実行中の別の処理のために遅くなってしまう場合に、クライアント装置１２０はサーバ装置１１０によるリクエストの受信状況を早く判断できる。

なお、本実施形態ではサーバ装置１１０とクライアント装置１２０とがＨＴＴＰに従う通信を行う場合について説明したが、通信の方式はこれに限らない。例えば、ＣｏＡＰ（Ｃｏｎｓｔｒａｉｎｅｄ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）などのＨＴＴＰのセマンティクスを用いるプロトコルに従う通信を行う場合にも本実施形態を適用できる。

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

１０ 通信システム
１００ ネットワーク
１１０ サーバ装置
１２０ クライアント装置

Claims (13)

1. ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に従う通信を行う通信装置であって、
   前記通信装置に対して処理を要求するためのＨＴＴＰリクエストであって、要求される処理を識別するための識別情報を含むＨＴＴＰリクエストを、他の通信装置から受信する受信手段と、
   前記受信手段により前記ＨＴＴＰリクエストが受信されてから、前記ＨＴＴＰリクエストにより要求される処理の完了を示す第１のレスポンスを送信するまでの間に、第２のレスポンスを前記他の通信装置へ送信するかを、前記ＨＴＴＰリクエストに含まれる前記識別情報に応じて決定する決定手段と、
   前記決定手段による決定に応じて、前記第１のレスポンス及び前記第２のレスポンスを前記他の通信装置へ送信する送信手段と、
   を有し、
   前記送信手段がデータをサーバ装置へ送信する処理を実行している最中に前記データの送信を要求するための前記ＨＴＴＰリクエストを受信した場合、前記送信手段は前記第２のレスポンスを送信し、前記サーバ装置への前記データの送信が完了した後に、前記データの格納先ＵＲＬを含む前記第１のレスポンスを送信することを特徴とする通信装置。
2. 前記送信手段は、前記第２のレスポンスを前記他の通信装置へ送信しないと前記決定手段により決定された場合に、前記第２のレスポンスを送信することなく前記第１のレスポンスを前記他の通信装置へ送信することを特徴とする請求項１に記載の通信装置。
3. 前記送信手段は、前記ＨＴＴＰリクエストにより要求される処理が完了した後に前記第１のレスポンスを送信することを特徴とする請求項１又は２に記載の通信装置。
4. 前記受信手段により受信されるＨＴＴＰリクエストに含まれる識別情報は、当該ＨＴＴＰリクエストのメソッドを示す情報と当該ＨＴＴＰリクエストにより要求される処理の内容を特定するためのＵＲＬとを含むことを特徴とする請求項１乃至３の何れか１項に記載の通信装置。
5. 予め取得された識別情報を保持する保持手段を有し、
   前記決定手段は、前記受信手段により受信されたＨＴＴＰリクエストに含まれる識別情報が前記保持手段により保持されている識別情報と合致する場合に、前記第２のレスポンスを前記他の通信装置へ送信すると決定することを特徴とする請求項１乃至４の何れか１項に記載の通信装置。
6. 前記決定手段は、前記受信手段により受信されたＨＴＴＰリクエストに含まれる識別情報が、ユーザ又は第２の通信装置により指定される所定の時間長より長い時間を要する処理に対応する識別情報である場合に、前記第２のレスポンスを前記他の通信装置へ送信すると決定することを特徴とする請求項１乃至５の何れか１項に記載の通信装置。
7. 前記決定手段は、前記受信手段により受信されたＨＴＴＰリクエストに含まれる識別情報が、撮影手段による撮影の方向又はズーム率を変更する処理に対応する識別情報である場合に、前記第２のレスポンスを前記他の通信装置へ送信すると決定することを特徴とする請求項１乃至５の何れか１項に記載の通信装置。
8. 前記決定手段は、前記受信手段により受信されたＨＴＴＰリクエストに含まれる識別情報が、撮影手段による静止画の連続撮影処理、前記撮影手段による動画の撮影処理、及び前記撮影手段により撮影された画像の変換処理の何れかに対応する識別情報である場合に、前記第２のレスポンスを前記他の通信装置へ送信すると決定することを特徴とする請求項１乃至５の何れか１項に記載の通信装置。
9. 前記送信手段により送信される前記第１のレスポンスは、２００から５９９のうち何れかのステータスコードを含み、
   前記送信手段により送信される前記第２のレスポンスは、１００から１９９のうち何れかのステータスコードを含むことを特徴とする請求項１乃至８の何れか１項に記載の通信装置。
10. 前記送信手段により送信される前記第２のレスポンスは、ＨＴＴＰ／２において規定されるＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを含み、
    前記送信手段は、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを含む前記第２のレスポンスにより予約されたストリームを用いて前記第１のレスポンスを送信することを特徴とする請求項１乃至８の何れか１項に記載の通信装置。
11. 前記送信手段により送信される前記第２のレスポンスは、ＨＴＴＰレスポンスのヘッダを含み、
    前記送信手段により送信される前記第１のレスポンスは、ＨＴＴＰレスポンスのボディであることを特徴とする請求項１乃至８の何れか１項に記載の通信装置。
12. ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に従う通信を行う通信装置により実行される通信方法であって、
    前記通信装置に対して処理を要求するためのＨＴＴＰリクエストであって、要求される処理を識別するための識別情報を含むＨＴＴＰリクエストを、他の通信装置から受信する受信工程と、
    前記受信工程において前記ＨＴＴＰリクエストが受信されてから、前記ＨＴＴＰリクエストにより要求される処理の完了を示す第１のレスポンスを送信するまでの間に、第２のレスポンスを前記他の通信装置へ送信するかを、前記ＨＴＴＰリクエストに含まれる前記識別情報に応じて決定する決定工程と、
    前記決定工程における決定に応じて、前記第１のレスポンス及び前記第２のレスポンスを前記他の通信装置へ送信する送信工程と、を有し、
    前記送信工程においてデータをサーバ装置へ送信する処理を実行している最中に前記データの送信を要求するための前記ＨＴＴＰリクエストを受信した場合、前記第２のレスポンスを送信し、前記サーバ装置への前記データの送信が完了した後に、前記データの格納先ＵＲＬを含む前記第１のレスポンスを送信することを特徴とする通信方法。
13. コンピュータを、請求項１乃至１１のいずれか１項に記載の通信装置の各手段として機能させるためのプログラム。

Images