(57)【要約】【課題】受信した複数の処理要求に応じたより適切な優先処理制御を行う。【解決手段】複数のリソースを管理する通信装置は、外部装置からリソースに対する操作要求を受け付ける受付手段と、受付手段により受け付けた第１の操作要求に基づいてリソースを処理している間に、受付手段により第２の操作要求を受け付けた場合、第１の操作要求と第２の操作要求の優先度に基づいて、リソースに対する処理を決定する決定手段と、を有する。【選択図】図３
2020010118.tif 000002
【特許請求の範囲】
【請求項１】
複数のリソースを管理する通信装置であって、
外部装置からリソースに対する操作要求を受け付ける受付手段と、
前記受付手段により受け付けた第１の操作要求に基づいて前記リソースを処理している間に、前記受付手段により第２の操作要求を受け付けた場合、前記第１の操作要求と前記第２の操作要求の優先度に基づいて、前記リソースに対する処理を決定する決定手段と、
を有することを特徴とする通信装置。
【請求項２】
前記第１の操作要求と前記第２の操作要求の優先度を示す情報を管理する管理手段を更に有し、
前記決定手段は、前記管理手段によって管理される情報に基づいて前記リソースに対する処理を決定する
ことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記第１の操作要求が対象とするリソースと前記第２の操作要求が対象とするリソースとの間に関連性があるか否かを判定する判定手段を更に有し、
前記決定手段は、更に前記判定手段により前記第１の操作要求が対象とするリソースと前記第２の操作要求が対象とするリソースとの間に関連性があると判定された場合に、前記管理手段により管理された前記情報に基づいて処理を決定する
ことを特徴とする請求項２に記載の通信装置。
【請求項４】
前記判定手段は、前記第１の操作要求が対象とするリソースに対応するデータが前記第２の操作要求が対象とするリソースに対応するデータに基づいて生成される場合、又は、前記第２の操作要求が対象とするリソースに対応するデータが前記第１の操作要求が対象とするリソースに対応するデータに基づいて生成される場合に、前記第１の操作要求が対象とするリソースと前記第２の操作要求が対象とするリソースとの間に関連性があると判定する
ことを特徴とする請求項３に記載の通信装置。
【請求項５】
前記管理手段によって管理される情報は、
前記第１の操作要求及び前記第２の操作要求それぞれに対する処理の実行有無、
前記第１の操作要求に対する処理と前記第２の操作要求に対する処理との処理順序
の少なくとも一方を含む
ことを特徴とする請求項２に記載の通信装置。
【請求項６】
前記優先度は、前記受付手段が前記第１の操作要求及び前記第２の操作要求それぞれを受け付けた際に取得した認証情報に基づいて決定される
ことを特徴とする請求項１乃至５の何れか１項に記載の通信装置。
【請求項７】
前記第１の操作要求及び前記第２の操作要求は、それぞれ、対象とするリソースを示す情報と該リソースに対する処理内容の情報とを含む
ことを特徴とする請求項１乃至６の何れか１項に記載の通信装置。
【請求項８】
前記処理内容の情報は、ＨＴＴＰにより規定されたメソッドにより示される
ことを特徴とする請求項７に記載の通信装置。
【請求項９】
前記決定手段により前記第１の操作要求及び前記第２の操作要求それぞれに対して決定された処理内容を表示する表示手段を更に有する
ことを特徴とする請求項１乃至８の何れか１項に記載の通信装置。
【請求項１０】
複数のリソースを管理する通信装置の制御方法であって、
外部装置からリソースに対する操作要求を受け付ける受付工程と、
前記受付工程で受け付けた第１の操作要求に基づいて前記リソースを処理している間に、前記受付工程で第２の操作要求を受け付けた場合、前記第１の操作要求と前記第２の操作要求の優先度に基づいて、前記リソースに対する処理を決定する決定工程と、
を含むことを特徴とする制御方法。
【請求項１１】
コンピュータを、請求項１乃至９の何れか１項に記載の通信装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、要求に基づくデータの処理技術に関するものである。
【背景技術】
【０００２】
近年、無線通信を利用して撮像装置内に記憶された画像データを外部装置へ転送する技術が実用化されている。外部装置に応じて再生可能な画像データのフォーマットは異なり得るため、撮像装置は、転送先の外部装置で再生可能なフォーマットに画像データを変換した上で転送を行う。一般にフォーマット変換などのデータ変換処理には時間を要する。そのため、画像データのサイズが大きい場合、転送要求を行った通信装置は要求したデータを受信開始するまでに長い時間待機することになる。
【０００３】
また、特許文献１では、画像データに対する撮影状況情報を生成し当該画像データに関連付けて記録することにより、外部装置による検索性を高める技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１５−１０４０７８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、カメラなどの電子機器においては、予め全てのコンテンツをトランスコードして記憶しておくことは内部メモリの制限から困難である。そのため、外部装置からの要求を受信してからトランスコードを行うことによりメモリの消費量を抑えている。
【０００６】
しかしながら、複数の機器（ブラウザや対向機）から同時に処理要求を受信した場合、データ処理の制約から、処理を同時に実行できない場合がある。例えば、フォーマット変換処理実行時には、当該フォーマット変換に関連しているデータを削除／上書き処理することができない。その結果、処理要求を行った外部装置に対して適切な処理結果を提供出来ない、あるいは、処理結果の提供が大きく遅延してしまうといった状況が生じる。
【０００７】
本発明は、このような問題に鑑みてなされたものであり、受信した複数の処理要求に応じたより適切な優先処理制御を可能とする技術を提供することを目的としている。
【課題を解決するための手段】
【０００８】
上述の問題点を解決するため、本発明に係る通信装置は以下の構成を備える。すなわち、複数のリソースを管理する通信装置は、
外部装置からリソースに対する操作要求を受け付ける受付手段と、
前記受付手段により受け付けた第１の操作要求に基づいて前記リソースを処理している間に、前記受付手段により第２の操作要求を受け付けた場合、前記第１の操作要求と前記第２の操作要求の優先度に基づいて、前記リソースに対する処理を決定する決定手段と、
を有する。
【発明の効果】
【０００９】
本発明によれば、受信した複数の処理要求に応じたより適切な優先処理制御を可能とする技術を提供することができる。
【図面の簡単な説明】
【００１０】
【図１】第１実施形態に係る通信システムの全体構成を示す図である。
【図２】通信装置の内部構成を示す図である。
【図３】通信装置の動作を示すフローチャートである。
【図４】受信した２つのリクエストに対応する処理方法を規定するテーブルを示す図である。
【図５】設定内容４０１に示すリクエストを受け付ける状態を例示的に示す図である。
【図６】設定内容４０２に示すリクエストを受け付ける状態を例示的に示す図である。
【図７】設定内容４０４に示すリクエストを受け付ける状態を例示的に示す図である。
【図８】リソース間の関連を説明する図である。
【図９】設定内容４０５に示すリクエストを受け付ける状態を例示的に示す図である。
【発明を実施するための形態】
【００１１】
以下に、図面を参照して、この発明の実施の形態の一例を詳しく説明する。なお、以下の実施の形態はあくまで例示であり、本発明の範囲を限定する趣旨のものではない。
【００１２】
（第１実施形態）
本発明に係る通信装置の第１実施形態として、画像データを外部装置に提供する通信装置を例に挙げて以下に説明する。
【００１３】
＜装置構成＞
図１は、第１実施形態に係る通信システム１００の全体構成を示す図である。通信システム１００は、通信装置１０１、外部装置１０２を有する。通信装置１０１、外部装置１０２は、有線または無線で互いに通信可能に接続されている。通信装置１０１と外部装置１０２とは、例えば静止画や動画等のコンテンツデータやイベント通知コマンドを送受信する。以下の説明では、通信装置１０１と外部装置１０２は、ＨＴＴＰ（Hypertext Transfer Protocol）において規定される通信プロトコルを利用してデータ送信を行う。即ち、外部装置１０２は通信装置１０１に操作要求を示すＨＴＴＰリクエストを送信し、通信装置１０１は受信したＨＴＴＰリクエストに応じて外部装置１０２にＨＴＴＰレスポンスを送信する。
【００１４】
通信装置１０１及び外部装置１０２の具体例としては、デジタルカメラ、ネットワークカメラ、プリンタ、複合機、テレビ、プロジェクタ、携帯電話、スマートフォン、ＰＣ、及びサーバ装置などがある。ここでは通信装置１０１及び外部装置１０２をそれぞれ１つの装置として記載しているが、これに限らず、複数の装置の複合やクラウドサービスであってもよい。
【００１５】
通信装置１０１と外部装置１０２との間の通信は、例えばＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）、又はそれらの組み合わせにより接続される。ＬＡＮとしては、Ｅｔｈｅｒｎｅｔ（登録商標）に則った有線ＬＡＮや、ＩＥＥＥ８０２．１１シリーズに則った無線ＬＡＮなどが用いられる。ＷＡＮとしては、例えばインターネットなどが用いられる。また、Ｂｌｕｅｔｏｏｔｈ（登録商標）やＺｉｇｂｅｅ（登録商標）など他の通信方式に基づいて接続してもよい。
【００１６】
図２は、通信装置１０１の内部構成を示す図である。通信装置１０１は、バス２００、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、ＴＣＰ／ＩＰ処理部２０４、ＨＴＴＰ処理部２０５、キャンセル部２０６、認証処理部２０７を有する。また、トランスコード部２０８、リソース管理部２０９、操作受付部２１０、データ管理部２１１、通信部２１２、表示部２１３、リクエスト判定部２１４、優先度生成部２１５を有する。
【００１７】
バス２００は、通信装置１０１の各部を繋いで情報を伝達する。ＣＰＵ２０１は、ＲＯＭ２０２やＲＡＭ２０３に格納されているコンピュータプログラムやデータを用いて通信装置１０１の全体を制御する。ＲＯＭ２０２は、変更を必要としないプログラムやパラメータを格納する。ＲＡＭ２０３は、通信部２１２を介して外部から供給されるデータを一時記憶する。
【００１８】
ＴＣＰ／ＩＰ処理部２０４は、ＴＣＰ／ＩＰなどのネットワークスタックの処理を行う。ＨＴＴＰ処理部２０５は、ＨＴＴＰの処理を行う。ここでは、ＵＲＬ（uniform resource locator）とＨＴＴＰの各メソッド（ＧＥＴ、ＰＯＳＴ、ＰＵＴ、ＤＥＬＥＴＥなどの処理内容）に応じた、ＨＴＴＰヘッダの処理とＨＴＴＰボディの処理を行う。キャンセル部２０６は、ＨＴＴＰおよびＴＣＰのキャンセル処理を行う。
【００１９】
例えば、キャンセル部２０６は、ＨＴＴＰ処理を途中でやめる。この時、キャンセル部２０６は、ＨＴＴＰ処理部２０５を介して、レスポンスコードを外部装置１０２に送信するように指示する。さらに、キャンセル部２０６は、ＴＣＰコネクションを切断する。ここではＨＴＴＰおよびＴＣＰのキャンセル処理を行ったが、これに限らず、利用するプロトコルのキャンセル処理を行う。また、ＨＴＴＰのキャンセルを行わずにＴＣＰのコネクションのキャンセルを実行してもよい。
【００２０】
認証処理部２０７は、ＨＴＴＰによる認証処理を行う。例えば、証明書による認証、ダイジェスト認証、ベーシック認証、ＯＡｕｔｈ２．０やＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔなどによるトークン認証を行う。
【００２１】
トランスコード部２０８は、通信装置１０１に保存されている画像や映像ストリームのコンテンツに対する要求があった時、画像フォーマット変換処理（トランスコード）を行う。トランスコード部２０８は、受信したリクエストに応じた画像や映像ストリームを生成する。例えば、ＲＡＷ画像からＪＰＧ画像やＰＮＧ画像を生成する。
【００２２】
リソース管理部２０９は、データ管理部２１１で管理されるコンテンツとＵＲＬを関連付けて管理する。また、リソース管理部２０９は、ＵＲＬ間の関連付けも同時に管理する。例えば、ＲＡＷ画像とＪＰＧ画像、ＰＮＧ画像、メタデータへの関連付けなどである。動画の場合においても同様に、他のフォーマットやメタデータへの関連付けを管理する。ここでは、画像データで説明したが、これに限らず、音声データや他の種類のデータであってもよい。
【００２３】
操作受付部２１０は、外部装置１０２からの、リソース（コンテンツ等）に対する処理を受け付ける。処理としては、取得（ＧＥＴ）、削除（ＤＥＬＥＴＥ）、置き換え（ＰＵＴ）、登録（ＰＯＳＴ）などが含まれる。ここでは、ＲＥＳＴ（REpresentational State Transfer）の原則に則って構築されたＲＥＳＴｆｕｌ  ＡＰＩを用いて複数の外部機器から同時に／並行して処理を受け付け可能であることを想定する。ただし、ＳＯＡＰや他の方式を用いてもよい。
【００２４】
データ管理部２１１は、静止画や動画といったコンテンツ、メタデータ、コンテンツのリストなどを保持する。なお、他の装置やクラウドサービスから管理データを取得する構成としてもよい。
【００２５】
通信部２１２は、外部装置１０２など他の装置と通信を行う。例えば、通信装置１０１が他の装置と有線で接続される場合には、ＬＡＮケーブル等が通信部２１２に接続される。なお無線通信する機能を有する場合、通信部２１２はアンテナを備える。
【００２６】
表示部２１３は、コンテンツデータや通信状態の表示を行う。ディスプレイを用いて表示してもよいし、ＵＩがない場合にはＬＥＤ点滅や音声による通知を行ってもよい。
【００２７】
リクエスト判定部２１４は、第一のＨＴＴＰリクエストと第二のＨＴＴＰリクエストの優先度、リソース、メソッドなどから、処理方法を決定する。優先度生成部２１５は、受信したＨＴＴＰリクエストと認証情報から、処理順位を決めるための優先度決定を行う。
【００２８】
＜リソース構成＞
図８は、リソース間の関連を説明する図である。ここではリソースとして、ＲＡＷ画像８０１、ＪＰＧ画像８０２、ＰＮＧ画像８０３、メタデータ８０４を含む状況を例示的に示している。なお、リソース間の関連はリソース管理部２０９により管理される。
【００２９】
ＲＡＷ画像８０１（ｘｘｘ．ｒａｗ）は、カメラの撮像部により生成される画像データである。ＪＰＧ画像８０２（ｘｘｘ．ｊｐｇ）及びＰＮＧ画像８０３（ｘｘｘ．ｐｎｇ）は、ＲＡＷ画像８０１をトランスコードすることにより生成される画像データである。要求に応じてリアルタイムにトランスコーディングを行ってもよいし、予めトランスコードしたものをキャッシュとして用意してもよい。更に、ＲＡＷ画像８０１のメタデータとして、メタデータ８０４（ｘｘｘ．ｍｅｔａｄａｔａ）がある。
【００３０】
ここでは説明を簡単にするためにＲＡＷ画像８０１に対してメタデータを関連付ける形式を示しているが、これに限らず、トランスコード後の各画像データに対してメタデータを関連づけてもよい。また、フォルダとファイルのリソースを関連付けてもよい。例えば、ＲＥＳＴ  ＡＰＩの場合、第一のＡＰＩのリソースと第二のＡＰＩのリソースの関連付けがあると示してもよい。さらに、コンテンツはファイル形式だけでなく、ストリーミング形式であってもよい。リアルタイムストリーミングの形式を複数サポートしている環境において、リアルタイムトランスコーディングを行って配信するなどのユースケースに適用してもよい。
【００３１】
＜装置の動作＞
図３は、通信装置１０１の動作を示すフローチャートである。ここでは、通信装置１０１は、外部装置１０２からのＨＴＴＰリクエストを受信して処理する形態、特に、ＲＥＳＴのアーキテクチャに基づくＨＴＴＰリクエストを受信して処理する形態について説明する。なお、図４に示すテーブルはＲＯＭ２０２又はＲＡＭ２０３に予め記憶されており、リクエスト判定部２１４は、当該テーブルを参照可能に構成されている。
【００３２】
Ｓ３０１では、ＨＴＴＰ処理部２０５は、ＴＣＰ／ＩＰ処理部２０４を介して、ＨＴＴＰサーバとして待ち受けを開始する。例えば、ユーザまたはアプリケーションの指示を受け付けたことをトリガに開始される。Ｓ３０２では、ＨＴＴＰ処理部２０５は、外部装置１０２からＨＴＴＰによるリクエストを受信する。Ｓ３０３では、リソース管理部２０９は、リクエストに含まれるＵＲＬとメソッドから、関連するリソースの有無を確認する。リソースありと判断するとＳ３０４に進み、リソースなしと判断するとＳ３１１に進む。
【００３３】
Ｓ３０４では、リソース管理部２０９は、リソースの関連情報（図８）を取得する。Ｓ３０５では、リソース管理部２０９は、Ｓ３０２で受信したリクエストに含まれるリソースに関連性がある別のリクエストを処理中であるか否かを確認する。ここで、リソース管理部２０９は、リソースの関連情報を参照して関連性の有無を確認する。たとえば、ＲＡＷ画像８０１（ｘｘｘ．ｒａｗ）を対象としたリクエストを既に受信している状態で、ＪＰＧ画像８０２（ｘｘｘ．ｊｐｇ）を対象としたリクエストをＳ３０２で受信した場合に、関連性があると判断する。関連性があるリクエストを処理中であると判断するとＳ３０６に進み、処理中でないと判断するとＳ３１１に進む。すなわち、Ｓ３０２で受信したリクエストが１つ目のリクエストである場合や、関連性がないリクエストを処理中の場合にはＳ３１１に進むことになる。
【００３４】
Ｓ３０６では、認証処理部２０７は、各リクエストの認証情報を確認する。Ｓ３０７では、優先度生成部２１５は、リソース名、パス、認証情報、操作内容などから、各リクエストの優先度の情報を生成する。
【００３５】
Ｓ３０８では、リクエスト判定部２１４は、図４に示すテーブルを元に各リクエストに対する処理を決定する。なお、図４に示すテーブルは一例であって、これに限るものではない。図４中の第二のリクエストとは、Ｓ３０２で受信したリクエストを示しており、第一のリクエストとは、Ｓ３０２で第二のリクエストを受信した際に既に受信されており処理中のリクエストである。各リクエストにおけるパラメータとして優先度、リソース、メソッド以外のパラメータ（たとえば、時間情報、ベースＵＲＬ、ＩＰｖ４、ＩＰｖ６など）を用いてもよい。
【００３６】
Ｓ３０９では、トランスコード部２０８は、リクエストに含まれるリソースについてトランスコードが必要か否かを判断する。例えば、リクエストにｘｘｘ．ｊｐｇのＧＥＴ（取得要求）が含まれているが、ｘｘｘ．ｊｐｇが存在しない場合は、トランスコードが必要であると判断する。その場合、トランスコード部２０８は、元画像に指定されている画像（ｘｘｘ．ｒａｗ）から、トランスコード後の画像（ｘｘｘ．ｊｐｇ）を生成する。
【００３７】
なお、すでにトランスコード後の画像（ｘｘｘ．ｊｐｇ）がある場合には、トランスコード部２０８の処理をスキップしてもよい。トランスコードするかしないかの判断はパスやファイル名、キャッシュの有無から決定することができる。また、トランスコードの機能がハードウェアで実装されている場合、同時に実行可能な数に制限があり、ここでは、同時に１つのトランスコードを実行可能である場合を想定している。ただし、同時実行可能数は２以上であり得、その場合は制約条件が変わることになる。
【００３８】
Ｓ３１０では、ＨＴＴＰ処理部２０５は、トランスコードした画像などを含むレスポンスを送信する。レスポンスはＨＴＴＰ形式のレスポンスであり、ステータスコード、パラメータ、画像、サムネイル、ストリーミングデータ、メタデータなどを含む。ＸＭＬやＪＳＯＮ形式のデータを含んでもよい。レスポンスを送信後、図３のフローを終了する。
【００３９】
Ｓ３１１では、リクエスト判定部２１４は、ＨＴＴＰリクエストのリクエスト処理を行う。リクエスト判定部２１４は、データ管理部２１１を用いて、どのリソースにアクセスがあったのかのアクセス状況を取得する。たとえば、ＰＮＧ画像８０３（ｘｘｘ．ｐｎｇ）にアクセスがあった場合、関連するフラグまたはカウンターを設定することで、アクセス状況を把握できる。データ管理部２１１におけるデータはＲＤＢのデータで保持してもよいし、グラフ形式のデータで保持してもよい。
【００４０】
Ｓ３１２では、トランスコード部２０８は、リクエストに含まれるリソースについてトランスコードが必要か否かを判断し、必要に応じてトランスコードを行う。当該処理は、Ｓ３０９と同様の処理であるため詳細な説明は省略する。Ｓ３１３では、ＨＴＴＰ処理部２０５は、トランスコードした画像などを含むレスポンスを送信する。当該処理は、Ｓ３１０と同様の処理であるため詳細な説明は省略する。
【００４１】
なお、上述の説明では、関連したリソースへのリクエストがある（Ｓ３０５でＹｅｓ）と判断した後に、認証情報の確認や優先度の決定を行うよう説明した。しかし、リクエストを受信した段階で認証情報の確認や優先度の決定を行うよう構成してもよい。
【００４２】
図４は、受信した２つのリクエストに対応する処理方法を規定するテーブルを示す図である。テーブルには１以上の設定内容が含まれている。各設定内容は、既に受信したリクエスト、図４中の第一のリクエストと、後続して受信したリクエスト、図４中の第二のリクエストとの組み合わせに対応する処理方法（処理方針）を規定している。特に、各リクエストは「優先度，リソース，メソッド」により特徴づけられている。
【００４３】
例えば、設定内容４０１は、第一のリクエストが「優先度１，ｘｘｘ．ｒａｗ，ＧＥＴ」であり、第二のリクエストが「優先度１，ｘｘｘ．ｐｎｇ，ＤＥＬＥＴＥまたはＰＵＴ」である場合の処理方法を規定している。なお「優先度１」は優先度が通常よりも高いことを意味している。
【００４４】
通信装置１０１は、第一のリクエストを受け付けた後に第二のリクエストを受け付けた場合、図８に示す関連リソース情報へアクセスし、第一のリクエストが指定するリソースと第二のリクエストが指定するリソースとの間に関係性があるかを確認する。関係性がある場合、通信装置１０１は、各リクエストの優先度を決定した後、図４に示すテーブルを参照する。受け付けた第一のリクエストと第二のリクエストとの組み合わせが設定内容４０１で規定する組み合わせに対応する場合、第二のリクエストに対して「第一のリクエストの完了を待ってから実行する」という処理方法を決定する。
【００４５】
設定内容４０２〜４０７については、第一のリクエストと第二のリクエストおよび処理方法の内容が異なるだけであるため、説明を省略する。このように、処理方法（処理方針）は、第一のリクエスト及び第二のリクエストそれぞれに対する処理の実行有無、第一のリクエストに対する処理と第二のリクエストに対する処理との処理順序、の少なくとも一方を含む。また、第一のリクエスト及び第二のリクエストそれぞれに対する優先度の組み合わせに対して個別に処理方法が規定される。なお、ここでは２つのリクエストを受け付けた場合について説明しているが、より多くのリクエストを受け付けた場合にも適用可能である。また、図４に示すテーブルの内容は、適宜ユーザによって変更可能であったり、新規追加や削除が可能であってもよい。
【００４６】
以上のように、通信装置１０１は、第一のリクエストと第二のリクエストの組み合わせから、処理方法を決定することができる。リソース内容や優先度が増えた場合には図４で示す組み合わせを増やすことで対応できる。また、図４のマトリクスをソフトウェアとして実装することで第一のリクエストの処理中に受信した第二のリクエストを自動的に処理することが可能になる。
【００４７】
＜具体的な動作例＞
以下では、いくつかの設定内容に対応する具体的な動作について説明する。具体的には、図４に示す設定内容４０１、４０２、４０４、４０５に対応する動作について説明する。
【００４８】
・設定内容４０１に示す２つのリクエストを受け付けた場合の動作
図５は、設定内容４０１に示すリクエストを受け付ける状態を例示的に示す図である。ここでは、通信装置１０１が、外部装置１０２ａから第一のリクエストを受信し、外部装置１０２ｂから第二のリクエストを受信することを想定する。
【００４９】
Ｍ５０１では、通信装置１０１は、外部装置１０２ａから第一のリクエストを受信する。第一のリクエストはｘｘｘ．ｒａｗの取得であり、通信装置１０１は、トランスコードを行うことはない。Ｍ５０２では、通信装置１０１は、外部装置１０２ｂから、第二のリクエストを受信する。ここで、通信装置１０１は、第一のリクエストの処理中（第一のリクエストに対する処理を決定する前）に第二のリクエストを受信する。第二のリクエストはｘｘｘ．ｐｎｇの削除である。
【００５０】
通信装置１０１は、第一のリクエストの処理中であるため、第二のリクエストが指定するリソースと第一のリクエストが指定するリソースの関係性を確認する。図８に示されるように、ｘｘｘ．ｒａｗとｘｘｘ．ｐｎｇとは関係性のあるリソースであるため、通信装置１０１は、認証情報等に基づいて各リクエストの優先度を決定する。ここでは、第一のリクエストと第二のリクエストとの両方が「優先度１」である。
【００５１】
そのため、第一のリクエストは「優先度１，ｘｘｘ．ｒａｗ，ＧＥＴ」であり、第二のリクエストは「優先度１，ｘｘｘ．ｐｎｇ，ＤＥＬＥＴＥ」であるため、図４の設定内容４０１に対応することになる。そのため、通信装置１０１は、「第一のリクエストの完了を待ってから、第二のリクエストを実行する」と決定する。
【００５２】
そのため、Ｍ５０３では、通信装置１０１は、ＨＴＴＰの暫定応答（１００  Ｃｏｎｔｉｎｕｅ）を外部装置１０２ｂに送信し、Ｍ５０４では、通信装置１０１は、ｘｘｘ．ｒａｗを含むレスポンスを外部装置１０２ａに送信する。外部装置１０２ａへのレスポンスの送信を完了した後、通信装置１０１は、ｘｘｘ．ｐｎｇを削除する。そして、Ｍ５０５では、通信装置１０１は、ｘｘｘ．ｐｎｇを削除したことを含むレスポンスを外部装置１０２ｂに送信する。
【００５３】
・設定内容４０２に示す２つのリクエストを受け付けた場合の動作
図６は、設定内容４０２に示すリクエストを受け付ける状態を例示的に示す図である。ここでは、通信装置１０１が、外部装置１０２ａから第一のリクエストを受信し、外部装置１０２ｂから第二のリクエストを受信することを想定する。
【００５４】
Ｍ６０１では、通信装置１０１は、外部装置１０２ａから第一のリクエストを受信する。第一のリクエストはｘｘｘ．ｒａｗの取得であり、通信装置１０１は、トランスコードを行うことはない。Ｍ６０２では、通信装置１０１は、外部装置１０２ｂから、第二のリクエストを受信する。ここで、通信装置１０１は、第一のリクエストの処理中に第二のリクエストを受信する。第二のリクエストはｘｘｘ．ｒａｗの削除である。
【００５５】
通信装置１０１は、第一のリクエストの処理中であるため、第二のリクエストが指定するリソースと第一のリクエストが指定するリソースの関係性を確認する。ここでは、同一のリソース（ｘｘｘ．ｒａｗ）であるため、通信装置１０１は、認証情報等に基づいて各リクエストの優先度を決定する。ここでは、第一のリクエストは「優先度１」であり第二のリクエストは「優先度２」である。なお「優先度２」は優先度が通常である（「優先度１」より低い）ことを意味している。
【００５６】
そのため、第一のリクエストは「優先度１，ｘｘｘ．ｒａｗ，ＧＥＴ」であり、第二のリクエストは「優先度２，ｘｘｘ．ｒａｗ，ＤＥＬＥＴＥ」であるため、図４の設定内容４０２に対応することになる。そのため、通信装置１０１は、「第二のリクエストを拒否する」と決定する。
【００５７】
そのため、Ｍ６０３では、通信装置１０１は、処理を実行できない旨を示すレスポンスを外部装置１０２ｂに送信し、Ｍ６０４では、通信装置１０１は、ｘｘｘ．ｒａｗを含むレスポンスを外部装置１０２ａに送信する。
【００５８】
・設定内容４０４に示す２つのリクエストを受け付けた場合の動作
図７は、設定内容４０４に示すリクエストを受け付ける状態を例示的に示す図である。ここでは、通信装置１０１が、外部装置１０２ａから第一のリクエストを受信し、外部装置１０２ｂから第二のリクエストを受信することを想定する。
【００５９】
Ｍ７０１では、通信装置１０１は、外部装置１０２ａから第一のリクエストを受信する。第一のリクエストはｘｘｘ．ｐｎｇの取得であり、通信装置１０１は、トランスコードが必要と判断する。Ｍ７０２では、通信装置１０１は、外部装置１０２ｂから、第二のリクエストを受信する。ここで、通信装置１０１は、第一のリクエストの処理中に第二のリクエストを受信する。第二のリクエストはｘｘｘ．ｒａｗの削除である。
【００６０】
通信装置１０１は、第一のリクエストの処理中であるため、第二のリクエストが指定するリソースと第一のリクエストが指定するリソースの関係性を確認する。図８に示されるように、ｘｘｘ．ｐｎｇとｘｘｘ．ｒａｗとは関係性のあるリソースであるため、通信装置１０１は、認証情報等に基づいて各リクエストの優先度を決定する。ここでは、第一のリクエストは「優先度２」であり第二のリクエストは「優先度１」である。
【００６１】
そのため、第一のリクエストは「優先度２，ｘｘｘ．ｐｎｇ，ＧＥＴ」であり、第二のリクエストは「優先度１，ｘｘｘ．ｒａｗ，ＤＥＬＥＴＥ」であるため、図４の設定内容４０４に対応することになる。そのため、通信装置１０１は、「第一のリクエストをキャンセルし、第二のリクエストを実行する」と決定する。これは、ｘｘｘ．ｐｎｇはｘｘｘ．ｒａｗからトランスコードにより生成されるため、元データであるｘｘｘ．ｒａｗが削除された後は継続することができないためである。
【００６２】
そのため、Ｍ７０３では、通信装置１０１は、ＨＴＴＰの暫定応答を外部装置１０２ｂに送信する。また、通信装置１０１は、第一のリクエストをキャンセルし、Ｍ７０４では、通信装置１０１は、キャンセルした旨を示すステータスコードを含むレスポンスを外部装置１０２ａに送信する。その後、通信装置１０１は、ｘｘｘ．ｒａｗを削除し、関連するデータ（トランスコード後のキャッシュやリソースデータ（ｘｘｘ．ｊｐｇ，ｘｘｘ．ｐｎｇ，ｘｘｘ．ｍｅｔａｄａｔａ））を削除する。そして、Ｍ７０５では、通信装置１０１は、ｘｘｘ．ｒａｗ及び関連するデータを削除したことを含むレスポンスを外部装置１０２ｂに通知する。
【００６３】
なお、設定内容４０４では、第一のリクエストをキャンセルする処理にしたが、ユースケースによっては、第一のリクエストを実行後、第二のリクエストを実行するような構成としてもよい。例えば、第一のリクエスト及び第二のリクエストを同一の外部装置１０２から受け付けた場合、シーケンシャルに処理を行ってもよい。このように、処理方法は、図４に示される内容に限定されるものではなく、様々な定義が可能である。
【００６４】
・設定内容４０５に示す２つのリクエストを受け付けた場合の動作
図９は、設定内容４０５に示すリクエストを受け付ける状態を例示的に示す図である。ここでは、通信装置１０１が、外部装置１０２ａから第一のリクエストを受信し、外部装置１０２ｂから第二のリクエストを受信することを想定する。
【００６５】
Ｍ９０１では、通信装置１０１は、外部装置１０２ａから第一のリクエストを受信する。第一のリクエストはｘｘｘ．ｐｎｇの取得であり、通信装置１０１は、トランスコードが必要と判断する。Ｍ９０２では、通信装置１０１は、外部装置１０２ｂから、第二のリクエストを受信する。ここで、通信装置１０１は、第一のリクエストの処理中に第二のリクエストを受信する。第二のリクエストはｘｘｘ．ｊｐｇの取得であり、通信装置１０１は、トランスコードが必要と判断する。
【００６６】
通信装置１０１は、第一のリクエストの処理中であるため、第二のリクエストが指定するリソースと第一のリクエストが指定するリソースの関係性を確認する。図８に示されるように、ｘｘｘ．ｐｎｇとｘｘｘ．ｊｐｇとは関係性のあるリソースであるため、通信装置１０１は、認証情報等に基づいて各リクエストの優先度を決定する。ここでは、第一のリクエストは「優先度２」であり第二のリクエストは「優先度１」である。
【００６７】
そのため、第一のリクエストは「優先度２，ｘｘｘ．ｐｎｇ，ＧＥＴ」であり、第二のリクエストは「優先度１，ｘｘｘ．ｊｐｇ，ＧＥＴ」であるため、図４の設定内容４０５に対応することになる。そのため、通信装置１０１は、「第一のリクエストを保留して、第二のリクエストを実行する」と決定する。これは、ｘｘｘ．ｐｎｇ及びｘｘｘ．ｊｐｇは両方ともにｘｘｘ．ｒａｗからトランスコードにより生成されるが、トランスコードの同時実行可能数は１であるためであり、両方のトランスコードを同時には実行できないためである。
【００６８】
そのため、通信装置１０１は、トランスコードによりｘｘｘ．ｊｐｇを生成し、Ｍ９０３では、通信装置１０１は、ｘｘｘ．ｊｐｇを含むレスポンスを外部装置１０２ｂに送信する。外部装置１０２ｂへのレスポンスの送信を完了した後、通信装置１０１は、トランスコードによりｘｘｘ．ｐｎｇを生成し、Ｍ９０４では、通信装置１０１は、ｘｘｘ．ｐｎｇを含むレスポンスを外部装置１０２ａに送信する。
【００６９】
以上説明したとおり第１実施形態によれば、複数の処理要求（リクエスト）を受信した場合に、当該複数の処理要求の状況に応じた適応的な処理を行うことが可能となる。特に、複数の処理要求それぞれの内容（リソース、メソッドなど）の組み合わせに対して予め処理方法を規定しておくことにより、所望の処理結果を得ることが可能となる。また、各処理要求を受け付けた際の認証情報に基づいて優先度を決定することにより、更に細かい処理方法の制御が可能となる。
【００７０】
なお、通信装置１０１は、外部装置１０２からリクエストを受信した時、ステータスや操作内容を画面に表示してもよい。例えば、液晶ディスプレイに画面表示してもよいし、ＬＥＤやビープ音などを利用してもよい。これにより、ユーザは通信装置１０１が外部装置１０２からリクエストを受けていることを認識することができる。例えば、通信装置１０１の処理が限定される（例えば録画や削除など）ようなケースの場合に、ユーザがなぜ利用できないのか（削除されているのかなど）を知ることができる。
【００７１】
また、上述の説明においては、認証情報により各リクエストの優先度を決定したが、ユーザ・パスワードに基づき優先度を決定してもよい。例えば、通常ユーザのリクエストに比較しアドミニストレータのリクエストの優先度を高くしてもよい。また、上述の図５〜７、９を参照した説明においては、通信装置１０１が、外部装置１０２ａから第一のリクエストを受信し、外部装置１０２ｂから第二のリクエストを受信するとした。ただし、第一のリクエスト及び第二のリクエストを同一の外部装置から受信する形態に適用することも可能である。
【００７２】
更に、上述の第１実施形態では静止画のデータに関して説明を行ったが、動画のストリーミングに適用することも可能である。つまり、リソースの関連情報としてストリーミングのリソースを記載することで同様の制御が可能である。
【００７３】
（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００７４】
２００  バス；  ２０１  ＣＰＵ；  ２０２  ＲＯＭ；  ２０３  ＲＡＭ；  ２０４  ＴＣＰ／ＩＰ処理部；  ２０５  ＨＴＴＰ処理部；  ２０６  キャンセル部；  ２０７  認証処理部；  ２０８  トランスコード部；  ２０９  リソース管理部；  ２１０  操作受付部；  ２１１  データ管理部；  ２１２  通信部；  ２１３  表示部；  ２１４  リクエスト判定部；  ２１５  優先度生成部
【図１】
2020010118.tif 000003
【図２】
2020010118.tif 000004
【図３】
2020010118.tif 000005
【図４】
2020010118.tif 000006
【図５】
2020010118.tif 000007
【図６】
2020010118.tif 000008
【図７】
2020010118.tif 000009
【図８】
2020010118.tif 000010
【図９】
2020010118.tif 000011