(57)【要約】      （修正有）【課題】サーバ装置に複数のクライアント装置がアクセス可能な状況において、サーバ装置に対する不正なアクセスを防ぐ。【解決手段】通信装置は、通信装置に処理を要求するためのリクエストを受信し、リクエストに対応する処理を実行する。通信装置は、受信した第１のリクエストに対応する処理が実行されることに応じて、第１のリクエストに対する識別情報を含む第１のレスポンスを第１のリクエストの送信元に送信し、第１のレスポンスを送信した後に受信した第２のリクエストが第１のリクエストに関連するリクエストであり、かつ、第２のリクエストに付与された識別情報が第１のリクエストに対する識別情報である場合に、２のリクエストに対応する処理を実行する。【選択図】図４
2020046875.tif 000002
【特許請求の範囲】
【請求項１】
通信装置であって、
前記通信装置に処理を要求するためのリクエストを受信する受信手段と、
前記受信手段により受信されたリクエストに対応する処理を実行する実行手段と、
前記実行手段により、前記受信手段により受信された第１のリクエストに対応する処理が実行されることに応じて、前記第１のリクエストに対する識別情報を含む第１のレスポンスを前記第１のリクエストの送信元に送信する送信手段と、
前記送信手段により前記第１のレスポンスが送信された後に、前記受信手段により受信された前記第１のリクエストと異なる第２のリクエストに、識別情報が付与されているかを判定する第１の判定手段と、
前記第１の判定手段により、前記第２のリクエストに前記識別情報が付与されていると判定された場合に、前記第２のリクエストが前記第１のリクエストに関連するリクエストであり、かつ、前記識別情報が前記第１のリクエストに対する識別情報であるかを判定する第２の判定手段と、を有し、
前記第２の判定手段により、前記第２のリクエストが前記第１のリクエストに関連するリクエストであり、かつ、前記識別情報が前記第１のリクエストに対する識別情報であると判定された場合に、前記実行手段は、前記第２のリクエストに対応する処理を実行することを特徴とする通信装置。
【請求項２】
前記第２の判定手段により、前記第２のリクエストが前記第１のリクエストに関連するリクエストではないと判定された場合、または、前記識別情報が前記第１のリクエストに対する識別情報ではないと判定された場合に、前記実行手段は前記第２のリクエストに対応する処理を実行しないことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記第１の判定手段により、前記第２のリクエストに前記識別情報が付与されていないと判定された場合に、前記第２のリクエストが前記第１のリクエストに関連するリクエストかを判定する第３の判定手段を更に有し、
前記第３の判定手段により、前記第２のリクエストが前記第１のリクエストに関連するリクエストであると判定された場合に、前記実行手段は前記第２のリクエストに対応する処理を実行しないことを特徴とする請求項１または２に記載の通信装置。
【請求項４】
前記第３の判定手段により、前記第２のリクエストが前記第１のリクエストに関連するリクエストであると判定された場合、または、前記第２の判定手段により、前記第２のリクエストが前記第１のリクエストに関連するリクエストではないと判定された場合、または、前記識別情報が前記第１のリクエストに対する識別情報ではないと判定された場合に、前記第２のリクエストの送信元を不正な送信元として登録する登録手段を更に有することを特徴とする請求項３に記載の通信装置。
【請求項５】
前記送信手段は、前記実行手段により前記第１のリクエストに対応する処理の実行が完了した後に、前記第１のリクエストの送信元に対して、前記第１のリクエストに対応する処理の完了を示す第２のレスポンスを送信することを特徴とする請求項１から４のいずれか１項に記載の通信装置。
【請求項６】
前記第２の判定手段により、前記第２のリクエストが前記第１のリクエストに関連するリクエストであり、かつ、前記識別情報が前記第１のリクエストに対する識別情報であると判定された場合に、前記送信手段は、前記実行手段により前記第２のリクエストに対応する処理の実行が完了した後に、前記第２のリクエストの送信元に対して、前記第２のリクエストに対応する処理の完了を示す第２のレスポンスを送信することを特徴とする請求項１から４のいずれか１項に記載の通信装置。
【請求項７】
前記第１のレスポンスは、１００から１９９までのステータスコードを含むＨＴＴＰレスポンスであり、前記第２のレスポンスは、２００から５９９までのステータスコードを含むＨＴＴＰレスポンスであることを特徴とする請求項５または６に記載の通信装置。
【請求項８】
前記第１のレスポンスは、所定のステータスコードのＨＴＴＰレスポンスのＨＴＴＰヘッダ部分であり、前記第２のレスポンスは、前記ＨＴＴＰレスポンスのＨＴＴＰボディ部分であることを特徴とする請求項５または６に記載の通信装置。
【請求項９】
前記第１のリクエストの送信元と前記第２のリクエストの送信元は同じであることを特徴とする請求項１から８のいずれか１項に記載の通信装置。
【請求項１０】
前記第１のリクエストの送信元と前記第２のリクエストの送信元は異なることを特徴とする請求項１から８のいずれか１項に記載の通信装置。
【請求項１１】
前記第２の判定手段は、前記第２のリクエストが、前記第１のリクエストに対応する処理のキャンセル、前記第１のリクエストに対応する処理の中断、前記第１のリクエストに対応する処理のやり直し、前記第１のリクエストに対応する処理の延長のいずれかである場合に、前記第２のリクエストは前記第１のリクエストに関連するリクエストであると判定することを特徴とする請求項１から１０のいずれか１項に記載の通信装置。
【請求項１２】
受信手段および送信手段を有する通信装置の制御方法であって、
前記受信手段により受信された第１のリクエストに対応する処理を実行する第１の実行工程と、
前記第１の実行工程により、前記受信手段により受信された第１のリクエストに対応する処理が実行されることに応じて、前記送信手段に、前記第１のリクエストに対する識別情報を含む第１のレスポンスを前記第１のリクエストの送信元に送信させる制御工程と、
前記送信手段により前記第１のレスポンスが送信された後に、前記受信手段により受信された前記第１のリクエストと異なる第２のリクエストに、識別情報が付与されているかを判定する第１の判定工程と、
前記第１の判定工程において、前記第２のリクエストに前記識別情報が付与されていると判定された場合に、前記第２のリクエストが前記第１のリクエストに関連するリクエストであり、かつ、前記識別情報が前記第１のリクエストに対する識別情報であるかを判定する第２の判定工程と、
前記第２の判定工程において、前記第２のリクエストが前記第１のリクエストに関連するリクエストであり、かつ、前記識別情報が前記第１のリクエストに対する識別情報であると判定された場合に、前記第２のリクエストに対応する処理を実行する第２の実行工程と、
を含むことを特徴とする通信装置の制御方法。
【請求項１３】
コンピュータを、請求項１から１１のいずれか１項に記載の通信装置として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、通信方法、およびプログラムに関する。
【背景技術】
【０００２】
ウェブシステムでは、ＨＴＴＰ（Hypertext Transfer Protocol）による通信がしばしば利用されている。ＨＴＴＰを利用したクライアント装置とサーバ装置との間の通信では、処理効率を上げるために様々な手法が提案されている。特許文献１には、クライアント装置が時間のかかる処理をサーバ装置へ要求し、更に、処理完了後を前提としたアクセスを当該処理実行中のサーバ装置に対して行った場合、サーバ装置は当該アクセスに応じられない旨の応答を返す技術が記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１３−２１０８０３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１においては、時間のかかる処理を実行中に、クライアント装置がサーバ装置に対して当該処理の中断を要求することで、サーバ装置は当該処理を中断することができる。しかしながら、サーバ装置に複数のクライアントがアクセスできる状況では、処理を依頼したクライアント装置とは異なるクライアント装置が、サーバ装置に対して処理の中断を行ってしまう可能性がある。これは、サーバ装置に対する不正なアクセスであり、サーバ装置に対して処理を依頼したクライアントが意図せずに処理が中断されてしまうことになる。
【０００５】
本発明は、上記課題に鑑みてなされたものであり、複数の装置からの処理のリクエストを受信可能な状況において、不正なアクセスを防ぐことを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するための一手段として、本発明の通信装置は以下の構成を有する。すなわち、通信装置であって、前記通信装置に処理を要求するためのリクエストを受信する受信手段と、前記受信手段により受信されたリクエストに対応する処理を実行する実行手段と、前記実行手段により、前記受信手段により受信された第１のリクエストに対応する処理が実行されることに応じて、前記第１のリクエストに対する識別情報を含む第１のレスポンスを前記第１のリクエストの送信元に送信する送信手段と、前記送信手段により前記第１のレスポンスが送信された後に、前記受信手段により受信された前記第１のリクエストと異なる第２のリクエストに、識別情報が付与されているかを判定する第１の判定手段と、前記第１の判定手段により、前記第２のリクエストに前記識別情報が付与されていると判定された場合に、前記第２のリクエストが前記第１のリクエストに関連するリクエストであり、かつ、前記識別情報が前記第１のリクエストに対する識別情報であるかを判定する第２の判定手段と、を有し、前記第２の判定手段により、前記第２のリクエストが前記第１のリクエストに関連するリクエストであり、かつ、前記識別情報が前記第１のリクエストに対する識別情報であると判定された場合に、前記実行手段は、前記第２のリクエストに対応する処理を実行する。
【発明の効果】
【０００７】
複数の装置からの処理のリクエストを受信可能な状況において、不正なアクセスを防ぐことが可能となる。
【図面の簡単な説明】
【０００８】
【図１】いくつかの実施形態におけるシステムの構成例を示す図。
【図２】サーバ装置１１０の構成例を示す図。
【図３】クライアント装置１２０の構成例を示す図。
【図４】サーバ装置１１０の処理例を示すフローチャート。
【図５】サーバ装置１１０の記憶部２１９に登録されるＵＲＬとメソッドと識別子の組の状態を示す図。
【図６】クライアント装置１２０、１２１、１２２の処理例を示すフローチャート。
【図７】クライアント装置１２０の表示部３２４の画面例を示す図。
【図８】クライアント装置１２０の表示部３２４の画面例を示す図。
【図９】実施形態１におけるシステムの処理の流れの例を示すシーケンス図。
【図１０】実施形態１におけるシステムの処理の流れの別の例を示すシーケンス図。
【図１１】実施形態２におけるシステムの処理の流れの例を示すシーケンス図。
【図１２】変形例１におけるサーバ装置１１０の表示部２１８の画面例を示す図。
【図１３】サーバ装置１１０の記憶部２１９に登録されるリクエスト送信元のＩＰアドレスの状態を示す図。
【発明を実施するための形態】
【０００９】
以下、添付の図面を参照して、本発明をその実施形態の一例に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
【００１０】
［実施形態１］
（システム構成）
図１に、本実施形態におけるシステム構成図を示す。ネットワーク１００は、サーバ装置１１０、クライアント装置１２０、１２１、１２２が接続するネットワークである。ネットワーク１００は、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）、または、それらの複合等であり得る。なお、サーバ装置１１０とクライアント装置１２０は、ネットワーク１００を介さずに、直接接続しても良い。直接接続は、例えば、無線アドホックネットワークを用いて実現できる。これは、サーバ装置１１０と、クライアント装置１２１、１２２との間の接続に関しても同様である。
【００１１】
ネットワーク１０１は、クライアント装置１２０、１２１が接続するネットワークである。本実施形態では、ネットワーク１０１は、Ｂｌｕｅｔｏｏｔｈ（登録商標）  Ｌｏｗ  Ｅｎｅｒｇｙ（ＢＬＥ）とする。しかし、これに限定するものではなく、ネットワーク１０１は、ＬＡＮ等の有線ネットワークでもよいし、Ｗｉ−Ｆｉ等の無線ネットワークでもよいし、それらの複合等でもよい。
【００１２】
クライアント装置１２０は、ネットワーク１００を介して、サーバ装置１１０へ、所定のプロトコルとしてＨＴＴＰ（Hypertext Transfer Protocol）を用いたリクエストを送信し、サーバ装置１１０はこれを受信することができる。当該リクエストは、サーバ装置１１０へ処理を要求するためのリクエストである。サーバ装置１１０は、クライアント装置１２０から受信したリクエストを解析し、処理結果などに基づきクライアント装置１２０へレスポンスを送信する。これはクライアント装置１２１、１２２に関しても同様である。また、クライアント装置１２０、１２１は、ネットワーク１０１を介して、情報の送信を行うことができる。ユーザ１３０、１３１、１３２は、それぞれ、クライアント装置１２０、１２１、１２２を操作する。
【００１３】
（サーバ装置の構成）
次に、サーバ装置１１０の構成について説明する。図２は、サーバ装置１１０のハードウェア構成の一例を示す図である。各構成要素は、バス２１０を介して接続される。リクエスト受信部２１１は、クライアント装置１２０、１２１、１２２から送信されるリクエストを受信する。リクエスト判定部２１２は、リクエスト受信部２１１により受信されたリクエストが、処理実行部２１３により実行されている処理に対応するリクエストに関連するかを判定する。具体的には、リクエスト判定部２１２は、リクエスト受信部２１１により受信されたリクエストが、リクエスト管理部２１６により記憶部２１９に登録されているＵＲＬ（Uniform Resource Locator）とメソッドの組に関連するリクエストかを判定する。また、リクエスト判定部２１２は、リクエスト受信部２１１により受信されたリクエストが、処理実行部２１３により実行されている処理に対応するリクエストに関連し、正規のクライアント装置から送信されているかを判定する。具体的には、リクエスト判定部２１２は、リクエスト受信部２１１により受信された、識別子付きのリクエストが、リクエスト管理部２１６により記憶部２１９に登録されているＵＲＬとメソッドの組に対するリクエストで、かつ、付与されている識別子が該組に対して登録された識別子と一致するかを判定する。
【００１４】
処理実行部２１３は、リクエスト受信部２１１により受信されたリクエストに対応する処理を実行する。暫定レスポンス送信部２１４は、リクエスト受信部２１１により受信されたリクエストに応じて、暫定レスポンスを送信する。暫定レスポンスは、処理実行部２１３により対象の処理の実行が完了する前に、リクエストの送信元に対して送信される、暫定的な応答を示すレスポンスである。完了レスポンス送信部２１５は、リクエスト受信部２１１により受信されたリクエストに応じて、完了レスポンスを送信する。完了レスポンスは、処理実行部２１３により対象の処理の実行が完了した場合に、リクエストの送信元に対して送信される、処理の完了を示すレスポンスである。
【００１５】
リクエスト管理部２１６は、処理実行部２１３により実行されている処理に関する情報として、当該処理に対応するＵＲＬとメソッドと識別子の組を、記憶部２１９において登録・管理する。ＵＲＬとメソッドと識別子については後述する。なお、この識別子は、１つのリクエスト（ＵＲＬとメソッド）を識別する識別情報であれば、どのような形式であってもよい。
【００１６】
撮像部２１７は、被写体の光学像を撮像する撮影機能を有する。表示部２１８は、各種表示を行う。表示部２１８は、ＬＣＤ（Liquid Crystal Display）やＬＥＤ（Light Emitting Diode）のように視覚で認知可能な情報を出力することができる。また、表示部２１８は、ユーザから操作入力を受け付けて操作に対応する処理を行うことができるユーザインタフェースとしての機能も有する。記憶部２１９は、ＲＯＭ、ＲＡＭの両方、もしくは、いずれか一方により構成され、後述する各種動作を行うためのプログラムや、通信のための通信パラメータ等の各種情報を記憶する。なお、記憶部２１９として、ＲＯＭ、ＲＡＭ等のメモリの他に、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＤＶＤなどの記憶媒体を用いてもよい。
【００１７】
なお、図２に示すリクエスト判定部２１２、処理実行部２１３、およびリクエスト管理部２１６は、ソフトウェアにより構成されてもよい。ソフトウェアとして構成される場合には、各機能を実現するためのコンピュータプログラムが記憶部２１９に記憶され、サーバ装置１１０が備える１つ以上のＣＰＵ２２０が当該プログラムを実行することによって該機能が実現され得る。一方、ハードウェアにより実現される場合、例えば、所定のコンパイラを用いることで、各機能モジュールの機能を実現するためのプログラムからＦＰＧＡ上に自動的に専用回路を生成すればよい。ＦＰＧＡとは、Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙの略である。また、ＦＰＧＡと同様にしてＧａｔｅ  Ａｒｒａｙ回路を形成し、ハードウェアとして実現するようにしてもよい。また、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）により実現するようにしてもよい。リクエスト受信部２１１、暫定レスポンス送信部２１４、および完了レスポンス送信部２１５は、個別のモジュールではなく、１つ以上の統合した通信モジュール（通信回路）として構成されてもよい。
【００１８】
（クライアント装置の構成）
続いて、クライアント装置１２０の構成について説明する。図３は、クライアント装置１２０のハードウェア構成の一例を示す図である。なお、クライアント装置１２１、１２２の構成は、クライアント装置１２０の構成と同様である。各構成要素は、バス３２０を介して接続される。
【００１９】
リクエスト送信部３２１は、サーバ装置１１０に処理を実行させるためのリクエストを送信する。レスポンス受信部３２２は、リクエスト送信部３２１により送信したリクエストに対応してサーバ装置１１０から送信されるレスポンスを受信する。レスポンス判定部３２３は、レスポンス受信部３２２により受信されたレスポンスが、暫定レスポンスか否かを判定する。また、受信されたレスポンスが暫定レスポンスである場合、レスポンス判定部３２３は更に、当該暫定レスポンスに識別子が付与されているか否かを判定する。
【００２０】
表示部３２４は、各種表示を行う。表示部３２４は、ＬＣＤやＬＥＤのように視覚で認知可能な情報の出力を行うことができる。また、表示部３２４は、ユーザから操作入力を受け付けて操作に対応する処理を行うことができるユーザインタフェースとしての機能も有する。ＢＬＥ通信部３２５は、ＢＬＥによる通信を行う上で必要となる基本的な機能（アンテナと変復調回路、メディアアクセス制御等）を有する。記憶部３２６は、ＲＯＭ、ＲＡＭの両方、もしくは、いずれか一方により構成され、後述する各種動作を行うためのプログラムや、通信のための通信パラメータ等の各種情報を記憶する。記憶部３２６は、記憶部２１９と同様に、フレキシブルディスク等で構成され得る。
【００２１】
なお、図３に示すレスポンス判定部３２３は、ソフトウェアにより構成されてもよい。ソフトウェアとして構成される場合には、各機能を実現するためのコンピュータプログラムが記憶部３２６に記憶され、クライアント装置１２０が備える１つ以上のＣＰＵ３２７が当該プログラムを実行することによって該機能が実現され得る。一方、ハードウェアにより実現される場合、例えば、所定のコンパイラを用いることで、各機能モジュールの機能を実現するためのプログラムからＦＰＧＡ上に自動的に専用回路を生成すればよい。ＦＰＧＡとは、Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙの略である。また、ＦＰＧＡと同様にしてＧａｔｅ  Ａｒｒａｙ回路を形成し、ハードウェアとして実現するようにしてもよい。また、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）により実現するようにしてもよい。リクエスト送信部３２１とレスポンス受信部３２２は、別々のモジュールではなく、統合した通信モジュール（通信回路）として構成されてもよい。
【００２２】
（サーバ装置とクライアント装置の処理の流れ）
図４は、サーバ装置１１０の処理例を示すフローチャートである。概略的には、図４は、ＨＴＴＰ通信において、サーバ装置１１０がクライアント装置１２０、１２１、１２２のいずれかからリクエストを受信し、完了レスポンスを送信する処理のフローチャートを示す。図４に示すフローチャートは、サーバ装置１１０の１つ以上のＣＰＵ２２０が記憶部２１９に記憶されている制御プログラムを実行し、情報の演算および加工並びに各ハードウェアの制御を実行することにより実現され得る。
【００２３】
Ｓ４０１にて、リクエスト受信部２１１は、クライアント装置１２０、１２１、１２２のいずれかからリクエストを受信する。なお、リクエスト受信部２１１により受信されたリクエストに対して、完了レスポンス送信部２１５が完了レスポンスを送信する（Ｓ４１０）前に、リクエスト受信部２１１が次のリクエストを受けた場合、図４のフローの動作は、並列に行われ得る。
【００２４】
Ｓ４０２にて、リクエスト判定部２１２は、Ｓ４０１で受信されたリクエストを解析し、リクエストに識別子が付与されているかを判定する。識別子については、Ｓ４０４の処理において後述する。リクエストに識別子が付与されていない場合（Ｓ４０２でＮＯ）、処理はＳ４０３へ進む。Ｓ４０３にて、リクエスト判定部２１２は、Ｓ４０１で受信されたリクエストが、記憶部２１９に登録されているＵＲＬとメソッドの組（実行されている処理に対応するリクエスト）に関連するリクエストか判定する。登録されているＵＲＬとメソッドの組に関連するリクエストとは、例えば、実行されている処理に対する、キャンセル／中断処理、処理のやり直し、処理の延長などがある。これらのリクエストに対するＵＲＬとメソッドは、あらかじめリクエスト判定部２１２で決められており、対応付けられている。例えば、本実施形態では、録画リクエストは、ＵＲＬがｈｔｔｐ：／／ｘｘｘ／ｒｅｃであり、メソッドはＰＯＳＴであある。また、録画キャンセルリクエストは、ＵＲＬがｈｔｔｐ：／／ｘｘｘ／ｒｅｃ？ｃａｎｃｅｌ＝１であり、メソッドがＰＯＳＴである。この場合、Ｓ４０１で、ＵＲＬがｈｔｔｐ：／／ｘｘｘ／ｒｅｃ？ｃａｎｃｅｌ＝１であり、メソッドがＰＯＳＴであるリクエストを受信したとする。このとき、リクエスト判定部２１２は、Ｓ４０１で受信したリクエストは、録画リクエストに関連するリクエストと判定する。ここで、リクエスト管理部２１６により記憶部２１９に録画リクエストのＵＲＬとメソッドが登録されていた場合、Ｓ４０３の判定でＹＥＳとなり、登録されていなければＳ４０３でＮＯとなる。
【００２５】
Ｓ４０３でＮＯの場合、Ｓ４０４にて暫定レスポンス送信部２１４は、識別子を付与した暫定レスポンスを、リクエストの送信元のクライアント装置へ送信する。識別子は、暫定レスポンス送信部２１４により任意に決定され得る、１つのリクエスト（ＵＲＬとメソッド）を特定するための識別情報である。暫定レスポンスに識別子を付与することで、識別子を送信するために新しい通信シーケンスを使用しなくて済むという効果がある。
【００２６】
本実施形態では、識別子を表す変数にｉｄ、識別子の値にランダムな値を利用する。識別子の値は、これに限るものではなく、変数を用いない決められた桁数のランダムな値でもよいし、クライアント装置のＩＰアドレスやＭＡＣアドレスの値、それらを基に生成した値でもよい。例えば、Ｓ４０４で暫定レスポンス送信部２１４は、暫定レスポンスに、識別子として“ｉｄ＝ａｂｃｄ”を付与する。先の処理であるＳ４０２では、リクエスト判定部２１２は、リクエストの引数に、識別子を表す変数であるｉｄが付いているか解析する。ｉｄが付いていればＳ４０２でＹＥＳとなり、付いていなければＳ４０２でＮＯとなる。
【００２７】
なお、本実施形態では、暫定レスポンスは、ステータスコード１００  Ｃｏｎｔｉｎｕｅを含むＨＴＴＰレスポンスとする。しかし、これに限らず、暫定レスポンスは、例えば、ステータスコード１０１  Ｓｗｉｔｃｈｉｎｇ  Ｐｒｏｔｏｃｏｌｓや１０２  Ｐｒｏｃｅｓｓｉｎｇ等の他のステータスコードを含むＨＴＴＰレスポンスや、他の形式のレスポンスであってもよい。
【００２８】
Ｓ４０５にて、処理実行部２１３は、Ｓ４０１で受信されたリクエストに対応する処理を実行する。このとき、リクエスト管理部２１６は、受信したリクエストのＵＲＬとメソッド、および、Ｓ４０４で暫定レスポンスに付与した識別子を組として、記憶部２１９に登録する。なお、本実施形態では、リクエスト管理部２１６は、ＵＲＬを登録する際、受信したリクエストのＵＲＬからクエリを除いたものを登録する。
【００２９】
ここで、図５を参照して、リクエスト管理部２１６により記憶部２１９に登録される、ＵＲＬとメソッドと識別子の組の一例を説明する。図５は、記憶部２１９に登録される、ＵＲＬとメソッドと識別子の組の状態を示す。図５の状態５０１は、リクエスト管理部２１６により何も登録されていない状態を示し、状態５０２は、リクエスト管理部２１６により図示するようなＵＲＬとメソッドと識別子の組が登録されている状態を示す。
【００３０】
図５を用いて、Ｓ４０１〜Ｓ４０５の処理の具体例を説明する。Ｓ４０１の処理の前に、リクエスト管理部２１６がＵＲＬとメソッドと識別子を、記憶部２１９に登録していない状態（状態５０１）であったとする。このとき、Ｓ４０１にて、リクエスト受信部２１１は、クライアント装置１２０から３０秒の所定時間録画要求のリクエストであるｈｔｔｐ：／／ｘｘｘ／ｒｅｃ？ｔｉｍｅ＝３０のＵＲＬとＰＯＳＴのメソッドを受信したとする。受信されたリクエストには識別子が付与されておらず（Ｓ４０２でＮＯ）、記憶部２１９は状態５０１である（Ｓ４０３でＮＯ）ことから、処理はＳ４０４へ進む。Ｓ４０４にて、暫定レスポンス送信部２１４は、ｉｄ＝ａｂｃｄの識別子を付与した暫定レスポンスをクライアント装置１２０へ送信する。その後、Ｓ４０５にて、処理実行部２１３が、受信されたリクエストに対応する処理を実行し、リクエスト管理部２１６は、受信されたリクエストのＵＲＬとメソッドと識別子の組を記憶部２１９に登録する。このとき、記憶部２１９の状態は、状態５０１から状態５０２になる。なお、Ｓ４０１で受信されたリクエストに対応する処理が、レスポンスを送信することだけを指す場合、Ｓ４０５の処理は省略され得る。
【００３１】
Ｓ４０５の処理の後、完了レスポンス送信部２１５は、Ｓ４０５の処理が完了するまで待機する（Ｓ４０６）。なお、Ｓ４０５の処理が完了する前に、ＴＣＰ（Transmission Control Protocol）通信セッションが切断された場合、処理実行部２１３は、実行中のＳ４０５の処理をキャンセルしてもよい。Ｓ４０５の処理の完了後、Ｓ４１０にて完了レスポンス送信部２１５は、Ｓ４０１で受信されたリクエストの送信元のクライアント装置へ完了レスポンスを送信し、処理を終了する。このとき、リクエスト管理部２１６は、Ｓ４０５で登録したＵＲＬとメソッドと識別子の組を、記憶部２１９から削除する。これにより、記憶部２１９の状態は、状態５０２から状態５０１となる。なお、本実施形態では、Ｓ４０５の処理が完了した場合のＳ４１０での完了レスポンスは、ステータスコード２００  ＯＫを含むＨＴＴＰレスポンスとする。しかし、これに限らず、完了レスポンスは、他の形式のレスポンスであってもよい。なお、後述するＳ４０９の処理がされていた場合等は、完了レスポンスは、ステータスコード４０６  Ｎｏｔ  Ａｃｃｅｐｔａｂｌｅや４０８  Ｒｅｑｕｅｓｔ  Ｔｉｍｅｏｕｔ等の他のステータスコードを含むＨＴＴＰレスポンスとなり得る。また、ステータスコード２００  ＯＫには、リクエスト結果のデータを付随させてもよい。
【００３２】
Ｓ４０３でＹＥＳの場合、Ｓ４１０にて完了レスポンス送信部２１５は、Ｓ４０１で受信されたリクエストの送信元のクライアント装置へ完了レスポンスを送信し、処理を終了する。本実施形態では、Ｓ４０３でＹＥＳの場合の完了レスポンスは、ステータスコード５００  Ｉｎｔｅｒｎａｌ  Ｓｅｒｖｅｒ  Ｅｒｒｏｒを含むＨＴＴＰレスポンスとする。しかし、これに限らず、完了レスポンスは、ステータスコード４０６  Ｎｏｔ  Ａｃｃｅｐｔａｂｌｅや４０８  Ｒｅｑｕｅｓｔ  Ｔｉｍｅｏｕｔ等の他のステータスコードを含むＨＴＴＰレスポンスであってもよい。
【００３３】
Ｓ４０２でＹＥＳの場合、Ｓ４０７にてリクエスト判定部２１２は、Ｓ４０１で受信されリクエストが、記憶部２１９に登録されているＵＲＬとメソッドの組（実行されている処理に対応するリクエスト）に関連するリクエストか判定する。更に、リクエスト判定部２１２は、受信されたリクエストに付与されている識別子が、その組に対して登録された識別子と一致するか判定する。例えば、識別子付きの録画キャンセルリクエストをＳ４０１で受信する。当該リクエストにおいて、ＵＲＬはｈｔｔｐ：／／ｘｘｘ／ｒｅｃ？ｃａｎｃｅｌ＝１？ｉｄ＝ａｂｃｄであり、メソッドはＰＯＳＴであるとする。このとき、リクエスト判定部２１２は、受信されたリクエストが録画リクエストに関連するリクエストであると判定する。ここで、記憶部２１９の状態が状態５０２であれば、識別子が録画リクエストの識別子と一致しているため、Ｓ４０７の判定でＹＥＳとなる。一方、記憶部２１９が状態５０１であれば、Ｓ４０７の判定でＮＯとなる。
【００３４】
Ｓ４０７でＮＯの場合、Ｓ４１０にて完了レスポンス送信部２１５は、Ｓ４０１で受信されたリクエストの送信元のクライアント装置に完了レスポンスを送信し、処理を終了する。本実施形態では、Ｓ４０７でＮＯの場合の完了レスポンスは、ステータスコード５００  Ｉｎｔｅｒｎａｌ  Ｓｅｒｖｅｒ  Ｅｒｒｏｒを含むＨＴＴＰレスポンスとする。Ｓ４０７でＹＥＳの場合、Ｓ４０８にて暫定レスポンス送信部２１４は、Ｓ４０１で受信されたリクエストの送信元のクライアント装置へ暫定レスポンスを送信する。ここで、暫定レスポンス送信部２１４は、Ｓ４０１で受信されたリクエストに付与されている識別子と同一の識別子を付与した暫定レスポンスを送信する。
【００３５】
Ｓ４０８の後、Ｓ４０９にて、処理実行部２１３は、Ｓ４０１で受信されたリクエストに対応する処理を実行する。なお、Ｓ４０１で受信されたリクエストに対応する処理が、レスポンスを送信することだけを指す場合、Ｓ４０９の処理は省略される。Ｓ４０９の後、Ｓ４１０にてＳ４０６の後にＳ４０９で行うものと同様の処理を行う。
【００３６】
なお、本実施形態では、クエリ部分はＵＲＬに含まれているが、これに限らず、例えば、ＨＴＴＰリクエストのボディに含まれていても良い。このように、本実施形態は、特定の形式／構成の、ＵＲＬ、クエリ、メソッド、ＨＴＴＰリクエストのボディに限定されるものではない。また、本実施形態ではメソッドとしてＰＯＳＴを用いたが、これに限らず、ＰＵＴやＮＯＴＩＦＹのような拡張したメソッドを用いてもよい。
【００３７】
図６は、クライアント装置１２０、１２１、１２２の処理例を示すフローチャートである。概略的には、図６は、ＨＴＴＰ通信において、クライアント装置１２０、１２１、１２２がサーバ装置１１０へリクエストを送信し、そのリクエストに対するレスポンスを受信する処理のフローチャートである。図６に示すフローチャートは、クライアント装置１２０、１２１、１２２の１つ以上のＣＰＵ３２７が記憶部３２６に記憶されている制御プログラムを実行し、情報の演算および加工並びに各ハードウェアの制御を実行することにより実現され得る。なお、クライアント装置１２０、１２１、１２２がリクエストを送信した後、完了レスポンスを受信する前に、次のリクエストを送信した場合、図６のフローの動作は、並列に行われる。
【００３８】
Ｓ６０１にて、リクエスト送信部３２１は、サーバ装置１１０へリクエストを送信する。Ｓ６０２にて、レスポンス受信部３２２は、サーバ装置１１０からのレスポンスを受信する。Ｓ６０３にて、レスポンス判定部３２３は、受信したレスポンスが暫定レスポンスかを判定する。この処理は、ステータスコードを確認することにより行われ得る。受信したレスポンスが暫定レスポンスであれば（Ｓ６０３でＹＥＳ）、処理はＳ６０４へ進み、暫定レスポンスでなければ（Ｓ６０３でＮＯ）、処理は終了する。なお、本実施形態において、暫定レスポンスは、ステータスコード１００  Ｃｏｎｔｉｎｕｅを含むＨＴＴＰレスポンスとする。しかし、これに限定するものではなく、例えばステータスコード１０１  Ｓｗｉｔｃｈｉｎｇ  Ｐｒｏｔｏｃｏｌｓや１０２  Ｐｒｏｃｅｓｓｉｎｇ等の他のステータスコードを含むＨＴＴＰレスポンスであってもよい。
【００３９】
受信されたレスポンスが暫定レスポンスでの場合（Ｓ６０３でＹＥＳ）、Ｓ６０４にて、レスポンス受信部３２２は、サーバ装置１１０から暫定レスポンス以外のレスポンス（本実施形態では完了レスポンス）を受信するまで待機する。Ｓ６０５にて、レスポンス受信部３２２は、暫定レスポンス以外のレスポンスを受信し、処理を終了する。
【００４０】
（クライアント装置の表示部の画面例）
次に、図７と図８を参照して、サーバ装置１１０と通信するクライアント装置１２０の表示部３２４の画面例を示す。なお、図７と図８はクライアント装置１２０を例に説明するが、クライアント装置１２１、１２２に対しても同様の説明を適用できる。図７は、レスポンス受信待ちでない状態の表示部３２４の画面例である。レスポンス受信待ちでない状態とは、クライアント装置１２０が、図６におけるＳ６０４で待機していない状態を指す。
【００４１】
領域７０１は、映像を表示するための領域、例えば、撮像部２１７により撮影された映像／画像を映す領域である。領域７０２は、各種リクエストを送信するための１つ以上の操作ボタンを含む領域である。ユーザ１３０は、領域７０２における所望の処理に対応する操作ボタンを操作することにより、サーバにリクエストを送信できる。なお、領域７０２における各操作ボタンが押された（選択された）ときに送信されるリクエストのＵＲＬとメソッドの組は、あらかじめ決定されているものとする。例えば、録画ボタン７０３が押された場合、ＵＲＬがｈｔｔｐ：／／ｘｘｘ／ｒｅｃで、メソッドがＰＯＳＴのリクエストが送信されるものとする。また、領域７０２における各操作ボタンでは、各種リクエストに対する引数も指定できるものとする。例えば、録画ボタン７０３が押された後、何秒間録画するかを選択できるポップアップが表示部３２４に表示され、ユーザ１３０が録画に対する秒数を選択／設定してもよい。ユーザ１３０が、録画に対する秒数として３０秒を選択した場合、送信されるリクエストのＵＲＬはｈｔｔｐ：／／ｘｘｘ／ｒｅｃ？ｔｉｍｅ＝３０となる。また、ユーザ１３０は、領域７０２におけるいずれかの操作ボタンを押した後、サーバ装置１１０から完了レスポンスを受信するまでの間、同じリクエストに対する操作ボタンを押す（選択する）ことができないようにしてもよい。例えば、ユーザ１３０が録画ボタン７０３を押した場合、サーバ装置１１０から完了レスポンスを受信するまでの間、ユーザ１３０は、録画ボタン７０３は押すことができない、または押しても対応するリクエストは送信されない。これにより、同じクライアント装置がサーバ装置１１０に同じリクエストを複数回送信することを防ぐ効果がある。
【００４２】
図８は、レスポンス受信待ちでの状態の表示部３２４の画面例である。レスポンス受信待ちの状態とは、クライアント装置１２０、１２１、１２２が、図６におけるＳ６０４で待機中の状態を指す。また、図８は、録画リクエストのレスポンス受信待ちの状態における表示部３２４の画面例を示す。図７と同様の領域は図７と同じ参照番号を付し、説明を省略する。
【００４３】
領域８０１は、領域７０２におけるいずれかの操作ボタンへの操作により送信されたリクエストであって、完了レスポンスの受信待ちをしているリクエストの状態を示す領域である。例えば、録画ボタン７０３を押したことに応答して、領域８０１では「録画のレスポンス受信待ち」が表示される。領域８０２は、領域８０１で完了レスポンスを受信待ちしているリクエストの処理に関連する操作ボタンを含む領域である。ユーザ１３０は、領域８０２におけるいずれかの操作ボタンを操作することにより、サーバ装置１１０で処理中である処理に関連する処理のリクエストを送信できる。ここで送信するリクエストには、例えば、実行されている処理に対する、キャンセル処理、処理のやり直し、処理の延長などがある。なお、領域７０２における各操作ボタンが押されたときに送信されるリクエストのＵＲＬとＰＯＳＴの組は、あらかじめ決定されているものとする。更に、このとき送信されるリクエストのＵＲＬには、完了レスポンスの受信待ちをしているリクエストに対する暫定レスポンスに付与された識別子が自動的に追加される。例えば、録画リクエストに対して、ｉｄ＝ａｂｃｄの識別子が付与された暫定レスポンスをレスポンス受信部３２２が受信していた場合を考える。このとき、領域８０２におけるキャンセルボタン８０４が押された場合、ＵＲＬがｈｔｔｐ：／／ｘｘｘ／ｒｅｃ？ｃａｎｃｅｌ＝１？ｉｄ＝ａｂｃｄであり、メソッドがＰＯＳＴのリクエストを送信する。これにより、ユーザ１３０が識別子の存在を意識することなく、クライアント装置１２０は、識別子を付与したリクエストを送信できる効果がある。
【００４４】
領域８０３は、領域８０１で完了レスポンスを受信待ちしているリクエストに関する情報として、識別子の情報をネットワーク１０１で接続している他のクライアントに送信する操作ボタンを含む領域である。領域８０３における操作ボタンの操作に関する処理については、実施形態２において後述する。
【００４５】
（実施形態１におけるシステムの処理の流れ）
図９は、本実施形態におけるシステムの処理の流れの例を示すシーケンス図である。概略的には、ＨＴＴＰ通信において、クライアント装置１２０がサーバ装置１１０に録画リクエストを送信し、サーバ装置１１０が識別子を含む暫定的なレスポンスを送信する。その後、クライアント装置１２０がサーバ装置１１０のリクエストの要求処理完了前に録画キャンセルリクエストを送信し、サーバ装置１１０の録画リクエストの要求処理をキャンセルする。また、本シーケンス図における記憶部２１９の初期状態は、状態５０１であるし、クライアント装置１２０の表示部３２４は図７に示す状態であるとする。
【００４６】
Ｓ９０１にて、ユーザ１３０は、録画のリクエスト要求操作を行う。当該操作は、例えば、ユーザが図７に示した領域７０２における録画ボタン７０３を、ユーザ１３０が押すことによりなされる。ユーザ１３０により録画のリクエスト要求操作が行われたことに応答して、Ｓ９０２にて、クライアント装置１２０のリクエスト送信部３２１は、サーバ装置１１０に対して録画リクエストを送信する（Ｓ６０１）。このとき送信されるリクエストは、ＵＲＬがｈｔｔｐ：／／ｘｘｘ／ｒｅｃであり、メソッドがＰＯＳＴであるとする。サーバ装置１１０のリクエスト受信部２１１は、録画リクエストを受信する（Ｓ４０１）。
【００４７】
Ｓ９０３にて、サーバ装置１１０のリクエスト判定部２１２は、受信した録画リクエストに識別子がついているかを判定する（Ｓ４０２）。判定の結果、識別子がついていないため、リクエスト判定部２１２は、受信した録画リクエストが、記憶部２１９に登録されているＵＲＬとメソッドの組に関連するリクエストか判定をする（Ｓ４０３）。Ｓ４０３の判定の結果、記憶部２１９に受信した録画リクエストのＵＲＬとメソッドが登録されていないため、サーバ装置１１０の暫定レスポンス送信部２１４は、受信した録画リクエストに対して、ステータスコードが１００  Ｃｏｎｔｉｎｕｅで識別子がｉｄ＝ａｂｃｄの暫定レスポンスを送信する（Ｓ４０４）。その後、処理実行部２１３は、受信した録画リクエストに対応する処理である録画処理を実行する（Ｓ４０５）。このとき、リクエスト管理部２１６は、記憶部２１９に、受信した録画リクエストのＵＲＬとメソッドと識別子の組を登録する。登録後の記憶部２１９の状態は状態５０２（図５）となる。クライアント装置１２０のレスポンス受信部３２２は、録画リクエストに対する暫定レスポンスを受信する（Ｓ６０２）。続いて、クライアント装置１２０のレスポンス判定部３２３は、録画リクエストに対する暫定レスポンスのステータスコードが１００  Ｃｏｕｎｔｉｎｕｅであることを判定し、暫定レスポンス以外のレスポンスを受信するまで待機する（Ｓ６０４）。このとき、クライアント装置１２０の表示部３２４は、例えば図８の状態になる。
【００４８】
Ｓ９０４にて、ユーザ１３０は、クライアント装置１２０に録画キャンセルリクエスト要求操作を行う。当該操作は、例えば図８に示した領域８０２におけるキャンセルボタン８０４を押すことによりなされる。ユーザ１３０により録画キャンセルリクエスト要求操作が行われたことに応答して、Ｓ９０５にて、クライアント装置１２０のリクエスト送信部３２１は、識別子を付与した録画キャンセルリクエストをサーバ装置１１０に送信する（Ｓ６０１）。このとき送信されるリクエストは、ＵＲＬがｈｔｔｐ：／／ｘｘｘ／ｒｅｃ？ｃａｎｃｅｌ＝１＆ｉｄ＝ａｂｃｄであり、メソッドがＰＯＳＴである。サーバ装置１１０のリクエスト受信部２１１は、識別子の付与された録画キャンセルリクエストを受信する（Ｓ４０１）。その後、サーバ装置１１０のリクエスト判定部２１２は、受信した録画キャンセルリクエストに識別子が付与されているか判定する（Ｓ４０２）。Ｓ４０２の判定の結果、識別子が付与されているため、リクエスト判定部２１２は、記憶部２１９に登録されているＵＲＬとメソッドの組に関連するリクエストで、識別子はその組に対して登録されたものと一致するか判定する（Ｓ４０７）。
【００４９】
Ｓ４０７の判定の結果、リクエスト判定部２１２は、受信した録画キャンセルリクエストは、記憶部２１９に登録されているＵＲＬとメソッドの組に関連するリクエストで、識別子はその組に対して登録されたものと一致すると判定する。この判定を受けて、暫定レスポンス送信部２１４は、録画キャンセルリクエストに対する暫定レスポンスである、ステータスコード１００  Ｃｏｕｎｔｉｎｕｅを含むレスポンスをクライアント装置１２０へ送信する（Ｓ４０８）。その後、処理実行部２１３は、受信した録画キャンセルリクエストに対応する処理である、録画キャンセル処理を実行する（Ｓ４０９）。ここで、録画キャンセルリクエストに対する暫定レスポンスを受信したクライアント装置１２０は、図８の領域８０２における録画リクエストに対するキャンセルボタン８０４を押せなく（受け付けなく）する、またはキャンセルボタン８０４を押してもエラーが表示部３２４に表示されるようにしてもよい。これにより、クライアント装置１２０を操作するユーザ１３０が複数回同じリクエストを送信してしまうのを防ぐことができる。
【００５０】
Ｓ９０７にて、Ｓ４０９の処理完了後、完了レスポンス送信部２１５は、録画キャンセルリクエストの完了レスポンスである、ステータスコード２００  ＯＫを含むレスポンスを送信する。クライアント装置１２０のレスポンス受信部３２２はそのレスポンスを受信する（Ｓ６０２）。レスポンス判定部３２３は、録画キャンセルレスポンスのステータスコードが２００であることを判定する（Ｓ６０３）。Ｓ６０３で判定の結果、レスポンス受信部３２２はステータスコードが２００  ＯＫだと判断したため処理を終了する。
【００５１】
録画キャンセルリクエストの処理により録画リクエストの処理がキャンセルされたため、Ｓ９０８にて、サーバ装置１１０の完了レスポンス送信部２１５は、録画リクエストの送信元のクライアント装置１２０に対して完了レスポンスを送信する（Ｓ４１０）。このとき、リクエスト管理部２１６は、Ｓ４０５で記憶部２１９に登録された内容を削除する。これにより、記憶部２１９は状態５０１（図５）となる。なお、サーバ装置１１０の完了レスポンス送信部２１５は、完了レスポンスとして、ステータスコードが５００  ＩｎｔｅｒｎａｌＳｅｒｖｅｒＥｒｒｏｒのレスポンスを送信する。クライアント装置のレスポンス受信部３２２はそのレスポンスを受信する（Ｓ６０５）。その後、クライアント装置１２０の表示部３２４は、例えば図８から図７の状態になる。なお、Ｓ９０７とＳ９０８の順番は入れ替わることもあるが、Ｓ９０７とＳ９０８の処理内容に変更はない。
【００５２】
図１０は、本実施形態におけるシステムの処理の流れの別の例を示すシーケンス図である。概略的には、ＨＴＴＰ通信において、クライアント装置１２０がサーバ装置１１０に録画リクエストを送信し、サーバ装置１１０が識別子を含む暫定的なレスポンスを送信する。その後、サーバ装置１１０が完了レスポンスをクライアント装置１２０に送信する前に、クライアント装置１２２がサーバ装置１１０に録画キャンセルリクエストを送信する。なお、クライアント装置１２２は、クライアント装置１２０とネットワーク１０１で繋がっておらず、ユーザ１３０から見るとユーザ１３２は予期しないユーザであり、クライアント装置１２２は予期しないクライアント装置であるとする。図１０の説明として、図９で説明したシーケンスとの差異を記載する。
【００５３】
Ｓ１００１にて、ユーザ１３２は、クライアント装置１２２に録画キャンセルリクエスト要求操作を行う。当該操作は、例えば、ユーザが図８に示した領域８０２におけるキャンセルボタン８０４を押すことによりなされる。ユーザ１３２により録画キャンセルリクエスト要求操作が行われたことに応答して、Ｓ１００２にて、クライアント装置１２２のリクエスト送信部３２１は、録画キャンセルリクエストをサーバ装置１１０に送信する（Ｓ６０１）。このとき送信されるリクエストは、ＵＲＬがｈｔｔｐ：／／ｘｘｘ／ｒｅｃ？ｃａｎｃｅｌ＝１であり、メソッドがＰＯＳＴである。すなわち、クライアント装置１２２は、例えばユーザ１３２による入力により、録画キャンセルリクエストのＵＲＬとメソッドをあらかじめ知っており、それらを利用して録画キャンセルリクエストを送信する。
【００５４】
サーバ装置１１０のリクエスト受信部２１１は、クライアント装置１２２から録画キャンセルリクエストを受信する（Ｓ４０１）。その後、サーバ装置１１０のリクエスト判定部２１２は、受信した録画キャンセルリクエストに識別子が付与されているか判定する（Ｓ４０２）。Ｓ４０２の判定の結果、識別子が付与されていないため、リクエスト判定部２１２は、記憶部２１９に登録されているＵＲＬとメソッドの組に関連するリクエストかを判定する（Ｓ４０３）。Ｓ４０３の判定の結果、リクエスト判定部２１２は、受信した録画キャンセルリクエストは、記憶部２１９に登録されているＵＲＬとメソッドの組に関連するリクエストと判定する。この判定を受けて、Ｓ１００３にて、完了レスポンス送信部２１５は、ステータスコードが５００  Ｉｎｔｅｒｎａｌ  Ｓｅｒｖｅｒ  Ｅｒｒｏｒを含む完了レスポンスをクライアント装置１２２に対して送信する（Ｓ４１０）。サーバ装置の処理実行部２１３が録画処理終了後、Ｓ１００４にて、完了レスポンス送信部２１５は、Ｓ９０２で受信したリクエストに対してクライアント装置１２０へ完了レスポンスを送信し、処理を終了する（Ｓ４１０）。
【００５５】
このように、本実施形態によれば、サーバ装置１１０は、記憶部２１９に登録されているＵＲＬとメソッドの組に対する識別子の付いていないリクエストの処理を行わないまま、完了レスポンスを送信できる。これにより、予期しないクライアント装置が、所定の処理のリクエストをキャンセルするためのリクエストのＵＲＬとメソッドを知っている場合においても、当該所定の処理のリクエストがキャンセルされることを防ぐ効果がある。これは、キャンセルに限ったことではなく、処理のやり直しや、処理の延長など、サーバが処理中の処理に対するリクエストに対しても有効である。なお、Ｓ４０５の処理の前提として、受信したリクエストには識別子は付与されていないことから、予期しないクライアント装置でも、Ｓ４０３でＮＯの判定になるリクエスト処理をサーバ装置１１０で実行させることができる。
【００５６】
［実施形態２］
実施形態２として、実施形態１と異なる点について説明する。まず、図８に示した、クライアント装置１２０のレスポンス受信待ち状態での表示部３２４の画面上の、領域８０３における操作ボタンについて説明する。ユーザ１３０は、領域８０３における操作ボタンを操作することにより、領域８０１で完了レスポンスを受信待ちしているリクエストに関する情報として、識別子の情報を、ネットワーク１０１で接続している他のクライアントに送信できる。例えば、ユーザ１３０が領域８０３における識別子送信ボタンを８０５押すと、クライアント装置１２０の表示部３２４にクライアント装置１２０がネットワーク１０１で接続しているクライアント装置のリストが表示される。本実施形態では、そのリストにクライアント装置１２１が表示される。その後、ユーザ１３０が表示部３２４から識別子送信を行うクライアント装置を選択するとネットワーク１０１を介して、選択したクライアント装置に識別子が送信される。ここで送信される識別子は、暫定レスポンスに付与されたリクエストに対する識別子だけなく、何のリクエストに対する識別子送信かを表す情報も送信され得る。例えば、領域７０２における操作ボタンが押されたときに送信されるＵＲＬとメソッドの組の情報や、領域７０２における操作ボタンに設定したｉｄ情報などがある。
【００５７】
（実施形態２におけるシステムの処理の流れ）
図１１は、本実施形態におけるシステムの処理の流れの例を示すシーケンス図である。概略的には、ＨＴＴＰ通信において、クライアント装置１２０がサーバ装置１１０に録画リクエストを送信し、サーバ装置１１０が識別子を含む暫定的なレスポンスを送信する。その後、クライアント装置１２０が識別子情報をクライアント装置１２１に送信する。次に、サーバ装置１１０が完了レスポンスをクライアント装置１２０に送信する前に、クライアント装置１２１がサーバ装置１１０にキャンセルリクエストを送信する。ここでは、実施形態１において説明した図９との差異を記載する。なお、クライアント装置１２０の表示部３２４は図７に示す状態であるとする。図１１の説明として、図９で説明したシーケンスとの差異を記載する。
【００５８】
Ｓ１１０１にて、ユーザ１３０は、クライアント装置１２０に識別子の送信の要求操作を行う。当該操作は、例えば、ユーザが図８に示した領域８０３における識別子送信ボタン８０５を押すことによりなされる。このとき、ユーザ１３０は、識別子送信先のクライアント装置も選択できるものとする。ここで選択できるクライアント装置は、ネットワーク１０１で繋がっている装置である。
【００５９】
Ｓ１１０２にて、クライアント装置１２０のＢＬＥ通信部３２５は、Ｓ９０３で受信した識別子情報をＢＬＥでクライアント装置１２１へ送信する。この識別子情報には、Ｓ９０３の暫定レスポンスに付与された識別子だけでなく、領域７０２のどの操作ボタンに対する識別子か、についての情報も含まれている。例えば、当該情報は、ＵＲＬとメソッドの組でもよいし、操作ボタンのＩＤであり得る。ここでは、ＢＬＥ通信部３２５は、ＵＲＬがｈｔｔｐ：／／ｘｘｘ／ｒｅｃ、メソッドがＰＯＳＴ、ｉｄ＝ａｂｃｄの情報を識別子情報として送信する。クライアント装置１２１のＢＬＥ通信部３２５は、識別子情報を受信する。このとき、クライアント装置１２１は、識別子情報の内容から、サーバ装置１１０が録画処理中ということを判断する。これにより、クライアント装置１２１は、録画リクエストに対する暫定レスポンス以外のレスポンスの受信待ち状態になる。つまり、クライアント装置１２１の表示部３２４は図７から図８の状態になる。
【００６０】
Ｓ１１０３にて、ユーザ１３１は、クライアント装置１２１に録画キャンセルリクエストの要求操作を行う。当該操作は、例えば、ユーザが図８の領域８０２におけるキャンセルボタン８０４を押すことによりなされる。ユーザ１３１により録画キャンセルリクエスト要求操作が行われたことに応答して、Ｓ１１０４にて、クライアント装置１２１のリクエスト送信部３２１は、識別子を付与した録画キャンセルリクエストを送信する（Ｓ６０１）。本実施形態では、このとき送信するリクエストは、ＵＲＬがｈｔｔｐ：／／ｘｘｘ／ｒｅｃ？ｃａｎｃｅｌ＝１＆ｉｄ＝ａｂｃｄであり、メソッドがＰＯＳＴである。サーバ装置１１０のリクエスト受信部２１１は、識別子が付与された録画キャンセルリクエストを受信する（Ｓ４０１）。その後、サーバ装置１１０のリクエスト判定部２１２は、録画キャンセルリクエストに識別子がついているか判定する（Ｓ４０２）。Ｓ４０２の判定の結果、識別子がついているため、リクエスト判定部２１２は、記憶部２１９に登録されているＵＲＬとメソッドの組に関連するリクエストで、識別子はその組に登録されたものと一致するか判定する（Ｓ４０７）。
【００６１】
Ｓ４０７の判定の結果、リクエスト判定部２１２は、受信した録画キャンセルリクエストは、記憶部２１９に登録されているＵＲＬとメソッドの組に関連するリクエストで、識別子はその組に対して登録されたものと一致すると判定する。この判定を受けて、Ｓ１１０５にて、暫定レスポンス送信部２１４は、録画キャンセルリクエストに対して、暫定レスポンスである、ステータスコード１００  Ｃｏｕｎｔｉｎｕを含むレスポンスを送信する（Ｓ４０８）。その後、処理実行部２１３は、受信した録画キャンセリクエストに対応する処理である、録画キャンセル処理を実行する（Ｓ４０９）。
【００６２】
Ｓ１１０６にて、Ｓ４０９の処理完了後、サーバ装置１１０の完了レスポンス送信部２１５は、録画キャンセルリクエストの完了レスポンスである、ステータスコード２００  ＯＫを含むレスポンスを送信する。クライアント装置１２１のレスポンス受信部３２２は、録画キャンセルリクエストに対する完了レスポンスを受信する（Ｓ６０２）。クライアント装置１２１のレスポンス判定部３２３は、完了レスポンスのステータスコードが２００であることを判定する（Ｓ６０３）。Ｓ６０３で判定の結果、クライアント装置１２１のレスポンス受信部３２２はステータスコードが２００  ＯＫだと判断したため処理を終了する。その後、クライアント装置１２１の表示部３２４は、図８から図７の状態になる。
【００６３】
クライアント装置１２０のレスポンス受信部３２２は、はＳ９０８で完了レスポンスを受信後、Ｓ１１０７にて、クライアント装置１２０のＢＬＥ通信部３２５は、完了レスポンス受信通知をクライアント装置１２１へ送信する。クライアント装置１２１のレスポンス受信部３２２は、完了レスポンス受信通知を受信後、録画リクエストに対する暫定レスポンス以外のレスポンスの受信待ち状態になっている場合、待ち状態を終了する。つまり、クライアント装置１２１の表示部３２４は図８から図７の状態になる。なお、Ｓ１１０６とＳ９０８の順番は入れ替わることもあるが、Ｓ１１０６とＳ９０８の処理内容に変更はない。
【００６４】
本実施形態によれば、リクエストを要求したユーザが認める他のユーザが、サーバのリクエスト処理をキャンセルする処理を可能にする効果がある。これは、キャンセルに限ったことではなく、処理の中断、処理のやり直し、処理の延長など、サーバが処理中の処理に対するリクエストに対しても有効である。
【００６５】
以上が本発明の実施形態の例であるが、本発明は、明細書および図面に示す実施形態の範囲に限定されることなく、その要旨を変更しない範囲内で変形して実施できるものである。以下、いくつかの変形例について説明する。
【００６６】
［変形例１］
上記実施形態において、リクエスト判定部２１２が、Ｓ４０３でＹＥＳまたはＳ４０７でＮＯと判定した場合に、サーバ装置１１０は、リクエストの送信元を、不正ユーザとして登録しても良い。本変形例を図１２と図１３を参照して説明する。図１２は、本変形例におけるサーバ装置１１０の表示部２１８の画面例を示す図である。図１２では、例えば、記憶部２１９の状態が状態５０２である場合に、Ｓ４０１で受信されたリクエストが、ＵＲＬがｈｔｔｐ：／／ｘｘｘ／ｒｅｃ？ｃａｎｃｅｌ＝１で、メソッドがＰＯＳＴの場合に表示される画面例である。リクエスト情報１２０１は、受信されたリクエストに関する情報であり、本例では、リクエストのＵＲＬ、メソッド、クエリ、リクエスト送信元のＩＰアドレスを含む。なお、リクエスト情報は、これに限るものではない。リクエスト情報１２０１が表示された状態で、サーバ装置１１０のユーザが不正ユーザ登録ボタン１２０２におけるＹＥＳを押すと、リクエスト管理部２１６は、リクエスト情報１２０１に含まれるリクエスト送信元のＩＰアドレスを、不正ユーザとして記憶部２１９に記憶して管理する。
【００６７】
ここで、図１３を参照して、リクエスト管理部２１６により記憶部２１９に登録される、リクエスト送信元のＩＰアドレスの一例を説明する。図１３は、記憶部２１９に登録される、リクエスト送信元のＩＰアドレスの状態を示す。状態１３０１は、初期状態、すなわち、記憶部２１９にリクエスト送信元のＩＰアドレスが登録されていない状態を示す。また、状態１３０２は、記憶部２１９にリクエスト送信元のＩＰアドレスが登録されている状態を示す。記憶部２１９の状態が１３０１の場合に、不正ユーザ登録ボタン１２０２のＹＥＳが押されると、記憶部２１９の状態は状態１３０２となる。その後、Ｓ４０１でリクエスト受信部がリクエストを受信した際に、リクエスト送信元のＩＰアドレスが記憶部２１９に登録されているかを判定し、登録されている場合、完了レスポンス送信部２１５が完了レスポンスを送信する。ここでの完了レスポンスは、ステータスコード４０６  Ｎｏｔ  Ａｃｃｅｐｔａｂｌｅや４０８を含むＨＴＴＰレスポンスとなり得る。これにより、不正なアクセスをしようとしているユーザのリクエストを拒否することができる。
【００６８】
［変形例２］
上記実施形態において、サーバ装置１１０の利用可能な残りセッション数に応じて、Ｓ４０４で、暫定レスポンス送信部２１４は、識別子を付与せずに暫定レスポンスを送信してもよい。上記の実施形態では、クライアント装置１２０、１２１、１２２は、サーバ装置１１０から識別子無しの暫定レスポンスを受信した場合、表示部３２４は例えば図８の状態となる。本変形例において、ここまでの動作は同じであるが、ユーザは、領域８０２におけるいずれかのボタンを押せなくなる、または、押してもエラーが表示され得る。これにより、サーバ装置１１０の残りセッション数がなく、記憶部２１９に登録されているＵＲＬとメソッドの組に関連するリクエストを受信できない場合において、クライアント側からの当該リクエスト送信を防ぐことができる。この場合、サーバ装置１１０のセッション数が空き次第、Ｓ４０４で、暫定レスポンス送信部２１４は、識別子を付与した暫定レスポンスを送信するようにしてもよい。
【００６９】
［変形例３］
上記実施形態において、では、処理実行部２１３が、リクエストに対応する処理を短時間で終了できる場合、暫定レスポンス送信部２１４が暫定レスポンスを送信直後に、完了レスポンス送信部２１５が完了レスポンスを送信することになる。この場合、サーバ装置１１０は、暫定レスポンスの送信から完了レスポンス送信までの間に何等かのリクエストを受信できる可能性は低くなるため、暫定レスポンス送信部２１４は、暫定レスポンスを送信しなくてもよい。すなわち、処理実行部２１３が、リクエストに対応する処理が短時間で終了できると判断した場合、暫定レスポンス送信部２１４は、暫定レスポンスを送信しなくてもよい。これにより、暫定レスポンスの送信を回避し、通信回数を削減できる。
【００７０】
［変形例４］
上記実施形態において、録画キャンセルリクエストのＵＲＬをｈｔｔｐ：／／ｘｘｘ／ｒｅｃ？ｃａｎｃｅｌ＝１をとした。しかし、これに限るものではなく、録画キャンセルリクエストのＵＲＬをｈｔｔｐ：／／ｘｘｘ／ｃａｎｃｅｌ？ｒｅｃのように、クエリ部分にキャンセルする処理の内容を示すようにしてもよい。これは、キャンセルに限ったことではなく、処理の中断、処理のやり直し、処理の延長など、サーバが処理中の処理に対するリクエストに対しても同様である。
【００７１】
［変形例５］
上記実施形態において、暫定レスポンスとして、ステータスコードが１００  ＣｏｎｔｉｎｕｅのＨＴＴＰレスポンスを、完了レスポンスとして、ステータスコードが２００  ＯＫや５００  ＩｎｔｅｒｎｅｌＳｅｒｖｅｒＥｒｒｏｒ等のレスポンスを使用した。すなわち、暫定レスポンスとして、１００から１９９までのステータスコードを含むＨＴＴＰレスポンスを、完了レスポンスとして、２００から５９９までのステータスコードを含むＨＴＴＰレスポンスを使用した。しかし、これらに限るものではなく、例えば、サーバ装置１１０が使用する暫定レスポンスとして、ステータスコードが２００  ＯＫのＨＴＴＰヘッダ部分を、完了レスポンスとして、ステータスコードが２００  ＯＫのＨＴＴＰボディ部分を使用してもよい。また、サーバ装置１１０が使用する暫定レスポンスとして、ステータスコードが２００  ＯＫのレスポンスを、完了レスポンスとして、ＨＴＴＰ／２  サーバプッシュのレスポンスを使用してもよい。他にも、サーバ装置１１０が使用する暫定レスポンスとして、ＨＴＴＰ／２  サーバプッシュのレスポンスを、完了レスポンスとしてステータスコードが２００  ＯＫのレスポンスを使用してもよい。
【００７２】
［変形例６］
上記実施形態では、ＨＴＴＰ通信を利用することを前提としているが、他の通信方式に、上記実施形態を適用することも可能である・
【００７３】
［その他の実施形態］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００７４】
１００、１０１：  ネットワーク；１１０  サーバ装置；１２０、１２１、１２２：  クライアント装置；１３０、１３１、１３２：ユーザ
【図１】
2020046875.tif 000003
【図２】
2020046875.tif 000004
【図３】
2020046875.tif 000005
【図４】
2020046875.tif 000006
【図５】
2020046875.tif 000007
【図６】
2020046875.tif 000008
【図７】
2020046875.tif 000009
【図８】
2020046875.tif 000010
【図９】
2020046875.tif 000011
【図１０】
2020046875.tif 000012
【図１１】
2020046875.tif 000013
【図１２】
2020046875.tif 000014
【図１３】
2020046875.tif 000015