JP2019053514A - 情報処理装置、情報処理方法、情報処理プログラム及び情報処理システム - Google Patents

Abstract

【課題】ファイルデータの取得に関するセキュリティを向上させることを課題とする。
【解決手段】情報処理装置は、取得部と、登録部とを有する。取得部は、ファイルデータのアップロード要求の要求元を示すアップロード要求元情報を取得する。登録部は、ファイルデータのダウンロード可否を判定する際に用いられるファイル記憶部に、取得されたアップロード要求元情報を登録する。これらにより、情報処理装置は、ファイルデータの取得に関するセキュリティを向上させる。
【選択図】図３

Description

本発明は、情報処理装置、情報処理方法、情報処理プログラム及び情報処理システムに関する。

従来、リモートで機器を管理するシステムにおいて、機器情報等のファイルデータをクラウド上の情報処理装置にアップロードし、機器を管理するアプリケーション等から、ファイルデータをダウンロードする技術が知られている。例えば、ファイルデータのアップロード時に生成されたファイルＩＤを指定することで、ファイルデータのダウンロードを実現する技術がある。また、例えば、特許文献１（特開２０１７−１３０７６０号公報）では、ユーザのアカウントに対応付けられた会議資料データの中から、会議のパスコードに一致する会議資料データを検索する技術が開示されている。

しかしながら、上述した従来技術は、ファイルデータの取得に関するセキュリティが脆弱であるという問題がある。具体的には、従来技術は、ファイルＩＤや予め設定されたパスコード等を用いてファイルデータをダウンロードさせているため、ファイルデータへのアクセス権限が実際には存在しない機器であってもダウンロードが可能となる。この結果、従来技術は、ファイルデータの取得に関するセキュリティが脆弱であるという問題がある。

本発明は、上記に鑑みてなされたものであって、ファイルデータの取得に関するセキュリティを向上させることを目的とする。

上述した課題を解決し、目的を達成するため、本発明に係る情報処理装置は、ファイルデータのアップロード要求の要求元を示すアップロード要求元情報を取得する取得部と、ファイルデータのダウンロード可否を判定する際に用いられるファイル記憶部に、取得された前記アップロード要求元情報を登録する登録部とを有する。

本発明によれば、ファイルデータの取得に関するセキュリティを向上させることができるという効果を奏する。

図１は、実施の形態に係る情報処理システムのシステム構成例を示す図である。 図２は、実施の形態に係るクラウドのハードウェア構成例を示す図である。 図３は、実施の形態に係るクラウドの機能構成例を示すブロック図である。 図４は、実施の形態に係るファイル記憶部に記憶される情報例を示す図である。 図５Ａは、実施の形態に係る接続情報記憶部に記憶される情報例を示す図である。 図５Ｂは、実施の形態に係る接続情報記憶部に記憶される情報例を示す図である。 図５Ｃは、実施の形態に係る接続情報記憶部に記憶される情報例を示す図である。 図６Ａは、実施の形態に係るアプリの機能構成例を示すブロック図である。 図６Ｂは、実施の形態に係る仲介装置の機能構成例を示すブロック図である。 図６Ｃは、実施の形態に係る機器の機能構成例を示すブロック図である。 図７は、実施の形態に係る情報処理システムの接続関係例を示す図である。 図８は、図７に示した接続関係におけるファイルデータへのアクセスの仕様の例を示す図である。 図９は、実施の形態に係るアップロードの種類の例を説明する図である。 図１０は、実施の形態に係るアプリからのアップロード処理の流れの例を示すシーケンス図である。 図１１は、実施の形態に係るアプリの証明書の例を示す図である。 図１２は、実施の形態に係る仲介装置からのアップロード処理の流れの例を示すシーケンス図である。 図１３は、実施の形態に係る仲介装置からのアップロード時に送信されるＨＴＴＰヘッダの例を示す図である。 図１４は、実施の形態に係る機器が仲介装置経由で行なうアップロード処理の流れの例を示すシーケンス図である。 図１５は、実施の形態に係る機器からのアップロード時に送信されるＨＴＴＰヘッダの例を示す図である。 図１６は、実施の形態に係るアプリからの要求に応じて仲介装置が行なうアップロード処理の流れの例を示すシーケンス図である。 図１７は、実施の形態に係るコマンド情報の例を示す図である。 図１８は、実施の形態に係るアプリがダウンロード要求装置となる場合のダウンロード処理の流れの例を示すシーケンス図である。 図１９は、実施の形態に係る仲介装置がダウンロード要求装置となる場合のダウンロード処理の流れの例を示すシーケンス図である。 図２０は、実施の形態に係るアップロード時の判定処理の流れの例を示すフローチャートである。 図２１は、実施の形態に係るダウンロード時の判定処理の流れの例を示すフローチャートである。

以下に添付図面を参照して、本発明に係る情報処理装置、情報処理方法、情報処理プログラム及び情報処理システムの実施の形態を説明する。なお、以下の実施の形態により本発明が限定されるものではない。

（実施の形態）
［システム構成］
図１を用いて、実施の形態に係る情報処理システム１のシステム構成を説明する。図１は、実施の形態に係る情報処理システム１のシステム構成例を示す図である。

図１に示すように、情報処理システム１には、クラウド１００と、アプリ２００と、仲介装置３００と、機器４００とが含まれる。アカウントは、ユーザをグルーピングした概念である。なお、情報処理システム１には、複数のアプリ２００や仲介装置３００、機器４００が含まれていても良い。また、クラウド１００は、「情報処理装置」に対応する。また、アプリ２００や仲介装置３００、機器４００は、「要求装置」に対応する。

アプリ２００は、クラウド１００が提供する機器へのアクセス手段を利用して、個別のソリューションを提供する。例えば、アプリ２００は、ログ収集サービス、カウンタ収集サービス、機器メンテナンスサービス等のソリューションを提供する。クラウド１００は、アプリ２００、仲介装置３００、機器４００それぞれの間における情報送受のための接続関係や通信経路等の情報を保持し、アプリ２００と機器４００との双方向の通信を制御する。

仲介装置３００は、ファイアウォールで保護されたＬＡＮ（Local Area Network）内に設置され、クラウド１００からの指示に従い、機器４００にアクセスしたり、機器４００からのアラート通知をクラウド１００に通知したりする。例えば、仲介装置３００は、予め設定されたスケジュール情報に基づいて、機器４００に対して機器情報の取得や死活監視等を行なう。機器４００は、被監視装置であり、メンテナンスやカウンタ検針の対象となる機器である。例えば、機器４００は、ネットワーク機能を有する複写機やプロジェクタ、家電、自動販売機、医療機器、３Ｄプリンタ、電源装置、空調システム、ガスや水道の計量システム、センサ（例えば、撮像装置や集音装置、人感センサ等）等である。

例えば、医療機器としては、眼底検査装置、Ｘ線検査装置、血圧計、体脂肪計、視力計、ペースメーカ等である。医療機器は、自身の識別情報や稼働状況、異常動作の有無、測定結果等を、データ形式又は画像形式等の種々の情報伝達手段を用いて出力する。また、３Ｄプリンタは、造形方式として、材料押出堆積法（ＦＤＭ）、マテリアルジェッティング、バインダージェッティング、粉末焼結積層造形（ＳＬＳ）、光造形法（ＳＬＡ）等がある。３Ｄプリンタは、自身の識別情報や稼働状況、異常動作の有無、装着された消耗品の状態等を、種々の情報伝達手段を用いて出力する。センサは、何らかの産業機械自体、又は、産業機械の周辺に取り付けられ、産業機械の情報を取得できるように構成されていれば良い。例えば、産業機械は、加工機、搬送機、検査機等である。

上述した構成において、クラウド１００は、アプリ２００や仲介装置３００、機器４００からのファイルデータのアップロード要求を受け付ける。アップロード要求には、ファイルデータの他に、ファイルＩＤや、ファイルデータのアップロードを要求した要求元を示すアップロード要求元情報等が含まれる。すなわち、アプリ２００や仲介装置３００、機器４００等は、アップロードの際に自身を識別する識別情報を含むアップロード要求をクラウド１００に対して行なう。

そして、クラウド１００は、アップロード要求に含まれるアップロード要求元情報を取得し、ファイルデータのダウンロード可否を判定する際に用いられるファイル記憶部に、取得されたファイルデータ、ファイルＩＤ、アップロード要求元情報等を登録する。

すなわち、ファイル記憶部には、ファイルデータやファイルＩＤだけではなく、実際にアップロードを要求した装置の情報が含まれる。このため、ファイルのダウンロード要求時には、アップロード要求元情報を確認することで、ファイルデータに対するアクセス権限を確認することができる。これらの結果、クラウド１００は、ファイルデータの取得に関するセキュリティを向上させることができる。

［ハードウェア構成］
次に、図２を用いて、実施の形態に係るクラウド１００のハードウェア構成を説明する。図２は、実施の形態に係るクラウド１００のハードウェア構成例を示す図である。

図２に示すように、クラウド１００は、制御装置１１と、主記憶装置１２と、補助記憶装置１３と、表示装置１４と、入力装置１５と、通信装置１６とを有する。上記各装置は、バスにより相互に接続される。制御装置１１は、ＣＰＵ（Central Processing Unit）やＧＰＵ（Graphics Processing Unit）等であり、主記憶装置１２を作業領域として、主記憶装置１２や補助記憶装置１３等に格納されたプログラムを実行することで、クラウド１００の動作を統括的に制御する。これにより、クラウド１００は、後述する各種機能を実現する。

主記憶装置１２は、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）等である。補助記憶装置１３は、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等である。表示装置１４は、ディスプレイ等である。入力装置１５は、キーボードやマウス等である。通信装置１６は、通信インタフェースであり、アプリ２００と、仲介装置３００（機器４００）との間の通信を制御する。

［機能構成］
次に、図３を用いて、実施の形態に係るクラウド１００の機能構成を説明する。図３は、実施の形態に係るクラウド１００の機能構成例を示すブロック図である。

図３に示すように、クラウド１００は、ファイル記憶部１１１と、接続情報記憶部１１２とを有する。また、クラウド１００は、取得部１２１と、登録部１２２と、暗号化部１２３とを有する。また、クラウド１００は、第１判定部１２４と、第２判定部１２５と、応答部１２６と、復号部１２７とを有する。また、クラウド１００は、コマンド制御部１２８を有する。

ファイル記憶部１１１は、ファイルデータや、ファイルデータに関する各種情報を記憶する。ファイル記憶部１１１に記憶されるファイルデータは、アップロード要求に応じて登録される。また、ファイル記憶部１１１は、ファイルデータのダウンロード可否を判定する際に用いられる。

図４は、実施の形態に係るファイル記憶部１１１に記憶される情報例を示す図である。図４に示すように、ファイル記憶部１１１は、ファイルＩＤと、プロパティと、ファイルデータと、有効期限との情報を記憶する。ファイルＩＤは、ファイルデータを識別する情報である。プロパティは、ファイルデータのアップロード要求の要求元を示す情報（アップロード要求元情報）である。ファイルデータは、アップロードされたファイルデータそのものである。有効期限は、ファイルデータのダウンロードの有効期限を示す情報（有効期限情報）である。

例を挙げると、ファイル記憶部１１１は、ファイルＩＤ「Ｆｉｌ００１」と、プロパティ「ａｐｐｌｉｃａｔｉｏｎＩＤ＝Ａｐｐ００１」と、ファイルデータ「ＸＸＸＸＸＸＸ」と、有効期限「２０１７／９／３」とを対応付けて記憶する。上述したように、プロパティには、アップロード要求元情報が含まれる。例えば、「ａｐｐｌｉｃａｔｉｏｎＩＤ」はアップロード要求元がアプリ２００であることを示す情報であり、「Ａｐｐ００１」は該アプリ２００を識別する情報である。また、「ｇａｔｅｗａｙＩＤ」はアップロード要求元が仲介装置３００であることを示す情報であり、「Ｍｅｄ００１」は該仲介装置３００を識別する情報である。また、「ｄｅｖｉｃｅＩＤ」はアップロード要求元が機器４００であることを示す情報であり、「Ｄｅｖ００２」は該機器４００を識別する情報である。また、「ｃｏｍｍａｎｄＩＤ」はアップロード要求元がアプリ２００から出力された要求であることを示す情報であり、「Ｃｏｍ００３」はコマンドを識別する情報である。

接続情報記憶部１１２は、アップロード要求の要求元間における情報送受のための接続関係を示す接続情報を記憶する。接続情報記憶部１１２に記憶される接続情報は、情報処理システム１が構築されたときに登録される情報であり、実際の運用前に予め保持される。

図５Ａ〜図５Ｃは、実施の形態に係る接続情報記憶部１１２に記憶される情報例を示す図である。図５Ａに示すように、アプリ−仲介装置テーブルには、アプリＩＤと仲介装置ＩＤとの情報が対応付けて記憶される。アプリＩＤは、アプリ２００を識別する情報である。仲介装置ＩＤは、仲介装置３００を識別する情報である。アプリ−仲介装置テーブルに対応付けられている各識別情報は、該当するアプリ２００と仲介装置３００とが情報を送受できることを表している。

図５Ｂに示すように、デバイス情報テーブルには、デバイスＩＤと、仲介装置ＩＤと、デバイス情報との情報が対応付けて記憶される。デバイスＩＤは、機器４００を識別する情報である。デバイス情報は、機器４００に関する情報である。デバイス情報テーブルに対応付けられている各識別情報は、該当する仲介装置３００と機器４００とが情報を送受できることを表している。

図５Ｃに示すように、コマンドテーブルには、コマンドＩＤと、アプリＩＤと、仲介装置ＩＤと、デバイスＩＤとの情報が対応付けて記憶される。コマンドＩＤは、アプリ２００が出力する要求に応じて生成されたコマンドを識別する情報である。コマンドテーブルに対応付けられている各識別情報は、該当するアプリ２００、仲介装置３００、機器４００が情報を送受できることを表している。

取得部１２１は、アップロード要求元情報を取得する。より具体的には、取得部１２１は、ファイルデータのアップロード要求が受け付けられた場合に、アップロード要求に含まれるファイルデータ、ファイルＩＤ、アップロード要求元情報を取得する。ファイルデータのアップロード要求は、通信装置１６によって受信される。また、アップロード要求に有効期限情報が含まれている場合、取得部１２１は、有効期限情報もさらに取得する。

登録部１２２は、ファイル記憶部１１１にアップロード要求元情報を登録する。より具体的には、登録部１２２は、取得部１２１によって取得されたファイルデータ、ファイルＩＤ、アップロード要求元情報を対応付けてファイル記憶部１１１に登録する。また、取得部１２１によって有効期限情報が取得されている場合、登録部１２２は、有効期限情報もさらに対応付けてファイル記憶部１１１に登録する。一方、取得部１２１によって有効期限情報が取得されていない場合、登録部１２２は、所定の有効期限情報をファイル記憶部１１１に登録する。例えば、登録部１２２は、有効期限情報の指定がなければ、現在日から所定日数後を有効期限情報としてファイル記憶部１１１に登録する。また、登録部１２２は、ファイルデータの暗号化を暗号化部１２３に依頼し、暗号化されたファイルデータをファイル記憶部１１１に登録しても良い。

暗号化部１２３は、ファイルデータを暗号化する。より具体的には、暗号化部１２３は、登録部１２２からの依頼に応じて、登録処理対象となっているファイルデータを暗号化し、暗号化したファイルデータを登録部１２２に応答する。以上の機能構成により、ファイルデータのアップロード処理が完了する。以下、ファイルデータのダウンロード処理について説明する。

第１判定部１２４は、ファイルデータのダウンロード要求に応じて、ファイルデータのダウンロード可否を判定する。より具体的には、第１判定部１２４は、ファイルデータのダウンロードを要求してきた装置を示すダウンロード要求装置情報と、ファイル記憶部１１１に記憶されたプロパティ情報（アップロード要求元情報）とが一致するか否かを判定する。ファイルデータのダウンロード要求は、通信装置１６によって受信される。ダウンロード要求には、ダウンロードの対象となるファイルデータのファイルＩＤと、ダウンロード要求装置情報とが含まれる。

詳細には、第１判定部１２４は、ファイル記憶部１１１を参照し、ダウンロード要求に含まれたファイルＩＤに対応するプロパティ情報を取得する。そして、第１判定部１２４は、ダウンロード要求に含まれるダウンロード要求装置情報と、取得したプロパティ情報とが一致するか否かを判定する。第１判定部１２４は、ダウンロード要求装置情報と、プロパティ情報とが一致すれば、ダウンロードの要求者はアップロードの要求元と同一であるから、ファイルデータのダウンロードが可であると判定する。一方、第１判定部１２４は、ダウンロード要求装置情報と、プロパティ情報とが一致しなければ、ダウンロードの要求者はアップロードの要求元とは異なり、ファイルデータへのアクセス権限が存在しないことになるから、ファイルデータのダウンロードが不可であると判定する。なお、該当するファイルＩＤがファイル記憶部１１１に存在しない場合はアクセスエラーとなる。

第２判定部１２５は、第１判定部１２４によってダウンロードが不可であると判定された場合に、さらに、ファイルデータのダウンロード可否を判定する。より具体的には、第２判定部１２５は、第１判定部１２４によってダウンロードが不可であると判定された場合に、接続情報記憶部１１２に記憶された接続情報を参照し、ダウンロード要求装置情報に対応する接続情報に、プロパティ情報（アップロード要求元情報）が含まれるか否かを判定する。

図５Ａ〜図５Ｃに示した何れのテーブルを利用するかについては、プロパティ情報から判断する。すなわち、プロパティ情報が「ａｐｐｌｉｃａｔｉｏｎＩＤ」である場合はアプリ−仲介装置テーブル（図５Ａ）を参照すれば良い。また、プロパティ情報が「ｇａｔｅｗａｙＩＤ」である場合はアプリ−仲介装置テーブル（図５Ａ）を参照すれば良い。また、プロパティ情報が「ｄｅｖｉｃｅＩＤ」である場合はデバイス情報テーブル（図５Ｂ）を参照すれば良い。また、プロパティ情報が「ｃｏｍｍａｎｄＩＤ」である場合はコマンドテーブル（図５Ｃ）を参照すれば良い。

ファイルデータがクラウド１００からダウンロードされる場合は、クラウド１００にダウンロードを要求した装置が要求元になるとは限られない。このため、第２判定部１２５では、ダウンロードを要求した装置の接続情報を確認することで、ファイルデータのアクセス権限を確認している。これらにより、第２判定部１２５は、ダウンロード要求装置情報に対応する接続情報にプロパティ情報が含まれる場合に、ダウンロードの要求者がアップロードの要求元との接続関係を有していることから、アップロードの要求元をトリガとしたダウンロード要求であるものとして、ファイルデータのダウンロードが可であると判定する。一方、第２判定部１２５は、ダウンロードの要求装置情報に対応する接続情報にプロパティ情報が含まれない場合に、ダウンロードの要求者がアップロードの要求元との接続関係を有しておらず、アップロードの要求元をトリガとしたダウンロード要求ではないとして、ファイルデータのダウンロードが不可であると判定する。

応答部１２６は、ダウンロードを要求した装置にファイルデータを応答する。より具体的には、応答部１２６は、第１判定部１２４によってダウンロード要求装置情報と、プロパティ情報とが一致すると判定された場合に、ダウンロードを要求した装置にファイルデータを応答する。また、応答部１２６は、第２判定部１２５によってダウンロード要求装置情報に対応する接続情報に、プロパティ情報が含まれると判定された場合に、ダウンロードを要求した装置にファイルデータを応答する。

また、ファイル記憶部１１１に有効期限情報が登録されている場合、応答部１２６は、有効期限情報をもとにダウンロードが可能である場合に、ダウンロードを要求した装置にファイルデータを応答する。一方、応答部１２６は、有効期限情報をもとにダウンロードが可能でない場合に、アクセスエラーを応答する。また、応答部１２６は、ファイルデータが暗号化されている場合に、復号部１２７にファイルデータの復号を依頼し、復号されたファイルデータを、ダウンロードを要求した装置に応答する。ファイルデータの応答は、通信装置１６によって送信される。

復号部１２７は、ファイルデータを復号する。より具体的には、復号部１２７は、応答部１２６からの依頼に応じて、ファイルデータを復号し、復号したファイルデータを応答部１２６に応答する。

コマンド制御部１２８は、アプリ２００から出力された要求をもとにコマンドを生成したり、コマンドに関する情報を保存したりする。コマンドに関する情報は、コマンドＩＤ、アプリＩＤ、仲介装置ＩＤ、デバイスＩＤ、コマンドの要求内容を示す情報等である。

次に、図６Ａを用いて、実施の形態に係るアプリ２００の機能構成を説明する。図６Ａは、実施の形態に係るアプリ２００の機能構成例を示すブロック図である。

図６Ａに示すように、アプリ２００は、ユーザＩ／Ｆ２０１と、要求発行部２０２と、通知受信部２０３と、アップロード要求部２０４と、ダウンロード要求部２０５とを有する。

ユーザＩ／Ｆ２０１は、監視対象の機器４００や仲介装置３００の状態、情報を一覧や詳細で確認するために、ボタン等を備えた画面の画面表示を制御する。ユーザＩ／Ｆ２０１で制御される画面に対する操作に応じて、機器４００に対して情報取得や制御等の命令が実現する。

要求発行部２０２は、ユーザＩ／Ｆ２０１が制御に従って表示された画面により受け付けられた、仲介装置３００や機器４００宛ての命令をクラウド１００に送信する。通信手段は、例えばＨＴＴＰＳ（Hypertext Transfer Protocol Secure）を想定するが、通信ができればＨＴＴＰＳに限られなくても良い。

通知受信部２０３は、アプリ２００が発行した命令に対する結果や、仲介装置３００や機器４００の自発的なアラート通知等を受信する。

アップロード要求部２０４は、クラウド１００に対してファイルデータのアップロードを要求する。また、アップロード要求部２０４は、アップロード要求時に、アプリ２００を識別するアプリＩＤを含むアップロード要求を行なう。ダウンロード要求部２０５は、クラウド１００に対してファイルデータのダウンロードを要求する。また、ダウンロード要求部２０５は、ダウンロード要求時に、ダウンロードの対象となるファイルデータのファイルＩＤを含むダウンロード要求を行なう。

次に、図６Ｂを用いて、実施の形態に係る仲介装置３００の機能構成を説明する。図６Ｂは、実施の形態に係る仲介装置３００の機能構成例を示すブロック図である。

図６Ｂに示すように、仲介装置３００は、機器接続定義管理部３０１と、タスクスケジューラ３０２と、クラウド通信部３０３と、設置用ユーザＩ／Ｆ３０４と、システム監視部３０５とを有する。また、仲介装置３００は、機器情報管理部３０６と、ログポリシー制御部３０７と、機器異常検知部３０８と、機器通信部３０９と、アップロード要求部３１０と、ダウンロード要求部３１１とを有する。

機器接続定義管理部３０１は、機器４００の追加や削除、検索、機器情報取得、疎通確認を実行するための通信パラメータをデータベース等により管理する。例えば、ＨＴＴＰであれば、リソースＵＲＩ、メソッド、ヘッダ・クエリ・ボディパラメータが存在する。また、ＳＮＭＰであれば、コマンド種別（Ｇｅｔ／ＧｅｔＢｕｌｋ）、バージョン、コミュニティ名、ＯＩＤ（オブジェクト識別子）が存在する。

タスクスケジューラ３０２は、仲介装置３００の内部の時計で事前に設定されたスケジュール情報に基づき、定期動作する。例えば、タスクスケジューラ３０２は、監視対象の機器４００から情報取得し、クラウド１００へ通知したり、機器４００がネットワーク通信可能であるか否かを確認する死活監視を行なったりする。また、タスクスケジューラ３０２は、定期的なログの送信を行なう。

クラウド通信部３０３は、通信制御を行なう。例えば、クラウド通信部３０３は、クラウド１００からのコマンドを受信する。また、クラウド通信部３０３は、機器４００からのアラートをクラウド１００に送信する。通信手段は、ＨＴＴＰＳを想定するが、通信ができればＨＴＴＰＳに限られない。

設置用ユーザＩ／Ｆ３０４は、ＬＡＮから機器４００やクラウド１００と通信するためのネットワーク設定や、クラウド１００と通信開始するためのアクティベーション手続き、接続確認等を行なうための画面を提供する。

システム監視部３０５は、メモリ不足やディスク不足、ディスク書き込みエラー等のシステム異常状態を検知する。

機器情報管理部３０６は、機器４００と通信するための機器識別子、機器種別、機器ＩＰアドレス等をデータベース等により管理する。

ログポリシー制御部３０７は、ログに含まれる文字列から指定したキーワードが存在するか否か、又は、正規表現で値を抽出し、抽出した値が範囲内に収まっているか否か等のポリシーを事前に設定する。

機器異常検知部３０８は、ログポリシー制御部３０７によって設定されたポリシーに従って、異常の兆候を検知する。異常の兆候が検知された場合は、クラウド１００へ通知される。

機器通信部３０９は、アプリ２００からの命令を機器４００に送信する。また、機器通信部３０９は、機器４００からのテキストメッセージやファイル（バイナリ）を受信する。通信プロトコルは、ＨＴＴＰＳやＳＮＭＰ等を想定するが、これらの通信プロトコルに限られない。

アップロード要求部３１０は、クラウド１００に対してファイルデータのアップロードを要求する。また、アップロード要求部３１０は、アップロード要求時に、アップロードの要求までに経由してきた装置全ての識別情報（例えば、デバイスＩＤや自身の仲介装置ＩＤ等）を含むアップロード要求を行なう。ダウンロード要求部３１１は、クラウド１００に対してファイルデータのダウンロードを要求する。また、ダウンロード要求部３１１は、ダウンロード要求時に、ダウンロードの対象となるファイルデータのファイルＩＤを含むダウンロード要求を行なう。

次に、図６Ｃを用いて、実施の形態に係る機器４００の機能構成を説明する。図６Ｃは、実施の形態に係る機器４００の機能構成例を示すブロック図である。

図６Ｃに示すように、機器４００は、ログ生成部４０１と、ログサーバ部４０２と、機器アラート送信部４０３と、アップロード要求部４０４とを有する。

ログ生成部４０１は、機器４００の動作ログを記録し、蓄積する。

ログサーバ部４０２は、仲介装置３００からログの取得要求を受け付けた場合に、機器４００の動作ログ（機器情報）を応答する。

機器アラート送信部４０３は、機器アラートの検知に応じて、仲介装置３００に機器アラートを送信する。

アップロード要求部４０４は、仲介装置３００を介して、クラウド１００に対してファイルデータのアップロードを要求する。機器４００によるアップロード要求は、例えば機器情報の通知を仲介装置３００に行なうことで、実際には仲介装置３００によって実行される。

［接続関係］
次に、図７及び図８を用いて、実施の形態に係る情報処理システム１の接続関係を説明する。図７は、実施の形態に係る情報処理システム１の接続関係例を示す図である。図８は、図７に示した接続関係におけるファイルデータへのアクセスの仕様の例を示す図である。

図７に示すように、３つのアプリ２００と、２つの仲介装置３００と、３つの機器４００（デバイス）とが情報処理システム１に含まれる場合を例に挙げる。また、各アプリ２００による要求に応じて、４つのコマンドが生成される場合を例に挙げる。アプリ２００のそれぞれは、アプリＩＤが「Ａｐｐ００１」、「Ａｐｐ００２」、「Ａｐｐ００３」であるものとする。また、仲介装置３００のそれぞれは、仲介装置ＩＤが「Ｍｅｄ００１」、「Ｍｅｄ００２」であるものとする。また、機器４００のそれぞれは、デバイスＩＤが「Ｄｅｖ００１」、「Ｄｅｖ００２」、「Ｄｅｖ００３」であるものとする。また、コマンドのそれぞれは、コマンドＩＤが「Ｃｏｍ００１」、「Ｃｏｍ００２」、「Ｃｏｍ００３」、「Ｃｏｍ００４」であるものとする。

アプリＩＤが「Ａｐｐ００１」であるアプリ２００は、仲介装置ＩＤが「Ｍｅｄ００１」である仲介装置３００と情報の送受を行なえる。アプリＩＤが「Ａｐｐ００２」であるアプリ２００は、仲介装置ＩＤが「Ｍｅｄ００１」である仲介装置３００と、仲介装置ＩＤが「Ｍｅｄ００２」である仲介装置３００と情報の送受を行なえる。アプリＩＤが「Ａｐｐ００３」であるアプリ２００は、仲介装置ＩＤが「Ｍｅｄ００２」である仲介装置３００と情報の送受を行なえる。

仲介装置ＩＤが「Ｍｅｄ００１」である仲介装置３００は、アプリＩＤが「Ａｐｐ００１」であるアプリ２００と、アプリＩＤが「Ａｐｐ００２」であるアプリ２００と、デバイスＩＤが「Ｄｅｖ００１」である機器４００と情報の送受を行なえる。仲介装置ＩＤが「Ｍｅｄ００２」である仲介装置３００は、アプリＩＤが「Ａｐｐ００２」であるアプリ２００と、アプリＩＤが「Ａｐｐ００３」であるアプリ２００と、デバイスＩＤが「Ｄｅｖ００２」である機器４００と、デバイスＩＤが「Ｄｅｖ００３」である機器４００と情報の送受を行なえる。

デバイスＩＤが「Ｄｅｖ００１」である機器４００は、仲介装置ＩＤが「Ｍｅｄ００１」である仲介装置３００と情報の送受を行なえる。デバイスＩＤが「Ｄｅｖ００２」である機器４００は、仲介装置ＩＤが「Ｍｅｄ００２」である仲介装置３００と情報の送受を行なえる。デバイスＩＤが「Ｄｅｖ００３」である機器４００は、仲介装置ＩＤが「Ｍｅｄ００２」である仲介装置３００と情報の送受を行なえる。

デバイスＩＤが「Ｄｅｖ００１」である機器４００は、アプリＩＤが「Ａｐｐ００１」であるアプリ２００からの要求に応じて生成されたコマンド（コマンドＩＤ「Ｃｏｍ００１」）による命令の対象機器である。また、デバイスＩＤが「Ｄｅｖ００１」である機器４００は、アプリＩＤが「Ａｐｐ００２」であるアプリ２００からの要求に応じて生成されたコマンド（コマンドＩＤ「Ｃｏｍ００２」）による命令の対象機器である。

デバイスＩＤが「Ｄｅｖ００２」である機器４００は、アプリＩＤが「Ａｐｐ００２」であるアプリ２００からの要求に応じて生成されたコマンド（コマンドＩＤ「Ｃｏｍ００３」）による命令の対象機器である。また、デバイスＩＤが「Ｄｅｖ００３」である機器４００は、アプリＩＤが「Ａｐｐ００３」であるアプリ２００からの要求に応じて生成されたコマンド（コマンドＩＤ「Ｃｏｍ００４」）による命令の対象機器である。

図７に示した接続関係において、各装置からアップロード要求が行なわれた場合、アップロードされたファイルデータへのアクセス権限（ダウンロード可否）は、図８に示す通りとなる。例えば、図８に示すように、アプリＩＤが「Ａｐｐ００１」であるアプリ２００がダウンロード要求を行なった場合（ダウンロード要求装置である場合）は、アプリＩＤが「Ａｐｐ００１」であるアプリ２００（自身）と、仲介装置ＩＤが「Ｍｅｄ００１」である仲介装置３００とが、ファイルデータへのアクセス権限を有する。これは、図７に示した接続関係から分かるように、アプリＩＤが「Ａｐｐ００１」であるアプリ２００と、仲介装置ＩＤが「Ｍｅｄ００１」である仲介装置３００とは、情報の送受を行なえる接続関係にあるからである。このような仕様は、図５Ａに示したアプリ−仲介装置テーブルをもとにダウンロード可否が判定されることによって実現する。

また、例えば、図８に示すように、仲介装置ＩＤが「Ｍｅｄ００１」である仲介装置３００がダウンロード要求を行なった場合（ダウンロード要求装置である場合）は、アプリＩＤが「Ａｐｐ００１」であるアプリ２００と、アプリＩＤが「Ａｐｐ００２」であるアプリ２００と、仲介装置ＩＤが「Ｍｅｄ００１」である仲介装置３００（自身）とが、ファイルデータへのアクセス権限を有する。これは、図７に示した接続関係から分かるように、仲介装置ＩＤが「Ｍｅｄ００１」である仲介装置３００と、アプリＩＤが「Ａｐｐ００１」であるアプリ２００とは、情報の送受を行なえる接続関係にあるからである。加えて、仲介装置ＩＤが「Ｍｅｄ００１」である仲介装置３００と、アプリＩＤが「Ａｐｐ００２」であるアプリ２００とは、情報の送受を行なえる接続関係にあるからである。このような仕様は、図５Ａに示したアプリ−仲介装置テーブルをもとにダウンロード可否が判定されることによって実現する。

これらと同様にして、機器４００やコマンドの仕様についても、図５Ｂに示したデバイス情報テーブルや図５Ｃに示したコマンドテーブルをもとにダウンロード可否が判定されることによって実現する。

［アップロード処理］
次に、図９〜図１７を用いて、実施の形態に係るアップロード処理を説明する。

図９は、実施の形態に係るアップロードの種類の例を説明する図である。図９に示すように、ファイルデータのアップロードは、（１）〜（４）の４つが存在する。
（１）アプリ２００からアップロード
（２）仲介装置３００からアップロード
（３）機器４００が仲介装置３００経由でアップロード
（４）アプリ２００からの要求に応じて仲介装置３００がアップロード

以下、各アップロード処理の流れを説明する。

図１０は、実施の形態に係るアプリ２００からのアップロード処理の流れの例を示すシーケンス図である。図１０に示すように、アプリ２００は、ファイルデータのアップロード要求をクラウド１００に送信する（ステップＳ１０１）。ファイルデータのアップロード要求には、ファイルデータ、ファイルデータのファイルＩＤ、アプリ２００のアプリＩＤが含まれる。また、アップロード要求には、有効期限情報等も含まれていても良い。有効期限情報は、アプリ２００のユーザによって指定されれば良い。

クラウド１００は、アプリ２００からのアップロード要求を受け付けると、ファイルデータやファイルＩＤ、アップロード要求元情報であるアプリＩＤ等をファイル記憶部１１１に登録する（ステップＳ１０２）。また、クラウド１００は、アップロード要求に有効期限情報が含まれていれば、有効期限情報も登録する。そして、クラウド１００は、ファイルデータのアップロードが完了した旨を表す結果通知をアプリ２００に送信する（ステップＳ１０３）。

ここで、クラウド１００は、どのアプリ２００からのアップロード要求であるかを判別するために、例えば、アプリ２００がクラウド１００との通信時に利用する証明書の情報を確認しても良い。図１１は、実施の形態に係るアプリ２００の証明書の例を示す図である。図１１に示すように、クラウド１００は、証明書に含まれるＣＮ情報を確認し、どのアプリ２００からのアップロード要求であるかを判別する。クラウド１００は、ＣＮ情報が不明であれば、アップロードを拒否するようにしても良い。

図１２は、実施の形態に係る仲介装置３００からのアップロード処理の流れの例を示すシーケンス図である。図１２に示すように、仲介装置３００は、ファイルデータのアップロード要求をクラウド１００に送信する（ステップＳ２０１）。ファイルデータのアップロード要求には、ファイルデータ、ファイルデータのファイルＩＤ、仲介装置３００の仲介装置ＩＤが含まれる。

クラウド１００は、仲介装置３００からのアップロード要求を受け付けると、ファイルデータやファイルＩＤ、アップロード要求元情報である仲介装置ＩＤ等をファイル記憶部１１１に登録する（ステップＳ２０２）。また、クラウド１００は、アップロード要求に有効期限情報が含まれておらず、有効期限情報を設定することになっていれば、所定日数後を有効期限情報として登録する。

ここで、仲介装置３００は、ファイルデータのアップロード要求の際に、自身の仲介装置ＩＤをＨＴＴＰヘッダ等に追加する。図１３は、実施の形態に係る仲介装置３００からのアップロード時に送信されるＨＴＴＰヘッダの例を示す図である。図１３に示すように、仲介装置３００は、ＨＴＴＰヘッダに自身の仲介装置ＩＤを追加して、ファイルデータのアップロード要求を行なう。これにより、クラウド１００は、ＨＴＴＰヘッダから仲介装置３００の仲介装置ＩＤを取得して、ファイル記憶部１１１に登録することができる。

図１４は、実施の形態に係る機器４００が仲介装置３００経由で行なうアップロード処理の流れの例を示すシーケンス図である。例えば、機器４００が仲介装置３００経由で行なうアップロード処理は、機器情報を含むファイルデータをクラウド１００に保存させる際に生じる。

図１４に示すように、機器４００は、自身の機器情報を仲介装置３００に通知する（ステップＳ３０１）。また、仲介装置３００は、機器情報を含むファイルデータのアップロード要求をクラウド１００に送信する（ステップＳ３０２）。このとき、仲介装置３００は、機器情報を通知してきた機器４００のデバイスＩＤと、自身の仲介装置ＩＤとを含むアップロード要求を送信する。すなわち、ファイルデータのアップロード要求には、ファイルデータ、ファイルデータのファイルＩＤ、仲介装置３００の仲介装置ＩＤ、機器４００のデバイスＩＤが含まれる。

クラウド１００は、仲介装置３００からのアップロード要求を受け付けると、ファイルデータやファイルＩＤ、アップロード要求元情報であるデバイスＩＤ等をファイル記憶部１１１に登録する（ステップＳ３０３）。また、クラウド１００は、アップロード要求に有効期限情報が含まれておらず、有効期限情報を設定することになっていれば、所定日数後を有効期限情報として登録する。

仲介装置３００は、ファイルデータのアップロード要求の際に、自身の仲介装置ＩＤや機器情報を通知してきた機器４００のデバイスＩＤをＨＴＴＰヘッダ等に追加する。図１５は、実施の形態に係る機器４００からのアップロード時に送信されるＨＴＴＰヘッダの例を示す図である。図１５に示すように、仲介装置３００は、ＨＴＴＰヘッダに自身の仲介装置ＩＤと、機器４００のデバイスＩＤとを追加して、ファイルデータのアップロード要求を行なう。これにより、クラウド１００は、ＨＴＴＰヘッダから機器４００のデバイスＩＤを取得して、ファイル記憶部１１１に登録することができる。

図１６は、実施の形態に係るアプリ２００からの要求に応じて仲介装置３００が行なうアップロード処理の流れの例を示すシーケンス図である。例えば、アプリ２００からの要求に応じて仲介装置３００が行なうアップロード処理は、アプリ２００が機器４００の機器情報を取得する要求が行なわれたことをトリガに実現する。

図１６に示すように、アプリ２００は、コマンド生成のトリガとなる機器情報の取得要求をクラウド１００に送信する（ステップＳ４０１）。クラウド１００は、アプリ２００から機器情報の取得要求を受け付けると、要求に対するコマンドを生成し、コマンド情報を保存する（ステップＳ４０２）。例えば、コマンド情報は、コマンドＩＤ、アプリＩＤ、仲介装置ＩＤ、デバイスＩＤ、要求内容の情報を示す要求情報等である。

図１７は、実施の形態に係るコマンド情報の例を示す図である。図１７に示すように、クラウド１００は、機器情報の取得要求に含まれるコマンドＩＤ、アプリＩＤ、仲介装置ＩＤ、デバイスＩＤ、要求情報等の情報を対応付けて保存する。アプリ２００からの機器情報の取得要求は、アプリ２００からの要求をトリガとして、仲介装置３００に、機器４００の機器情報を取得させ、機器情報を含むファイルデータをクラウド１００にアップロードするというものである。このため、機器情報の取得要求には、コマンドＩＤ、アプリＩＤ、仲介装置ＩＤ、デバイスＩＤ、要求情報が含まれることになる。

そして、クラウド１００は、生成したコマンドを仲介装置３００に送信し、コマンドに対応する処理の実行を要求する（ステップＳ４０３）。仲介装置３００は、コマンド要求を受信すると、機器情報の取得を機器４００に要求する（ステップＳ４０４）。これに対し、機器４００は、機器情報を含むファイルデータを応答する（ステップＳ４０５）。仲介装置３００は、機器４００から機器情報を取得すると、取得した機器情報を含むファイルデータをコマンド結果通知としてクラウド１００に送信する（ステップＳ４０６）。かかるコマンド結果通知は、機器情報を含むファイルデータのアップロード要求に相当する。詳細には、仲介装置３００は、自身の仲介装置ＩＤ、コマンドＩＤ、デバイスＩＤ、ファイルデータ、コマンド結果（結果ＯＫ等）を含むコマンド結果通知をクラウド１００に送信する。

クラウド１００は、コマンド結果通知を受信すると、ファイルデータやファイルＩＤ、アップロード要求元情報であるコマンドＩＤ等をファイル記憶部１１１に登録する（ステップＳ４０７）。また、クラウド１００は、有効期限情報についても登録する。そして、クラウド１００は、機器情報の取得結果をアプリ２００に通知する（ステップＳ４０８）。

［ダウンロード処理］
次に、図１８及び図１９を用いて、実施の形態に係るダウンロード処理を説明する。

図１８は、実施の形態に係るアプリ２００がダウンロード要求装置となる場合のダウンロード処理の流れの例を示すシーケンス図である。図１８に示すように、アプリ２００は、取得対象のファイルデータのファイルＩＤを含むファイルデータのダウンロード要求をクラウド１００に送信する（ステップＳ５０１）。クラウド１００は、ダウンロード要求を受け付けると、ファイルデータに対するアクセス権限の確認を行ない、ファイルデータのダウンロード可否を判定する（ステップＳ５０２）。そして、クラウド１００は、ダウンロードが可である場合に、ファイルデータをアプリ２００に応答する（ステップＳ５０３）。

図１９は、実施の形態に係る仲介装置３００がダウンロード要求装置となる場合のダウンロード処理の流れの例を示すシーケンス図である。図１９では、アプリ２００からのファイル転送要求をトリガとして、仲介装置３００がクラウド１００に対し、機器４００に転送するためのファイルデータのダウンロード要求を行なう場合を例に挙げる。

図１９に示すように、アプリ２００は、対象となる機器４００のデバイスＩＤやファイルデータのファイルＩＤを含むファイルデータの転送要求をクラウド１００に送信する（ステップＳ６０１）。クラウド１００は、ファイル転送要求を受け付けると、要求に対するコマンドを生成し、コマンド情報を保存する（ステップＳ６０２）。そして、クラウド１００は、生成したコマンドを仲介装置３００に送信し、コマンドに対応する処理の実行を要求する（ステップＳ６０３）。仲介装置３００は、コマンド要求を受信すると、ファイルデータのダウンロード要求をクラウド１００に送信する（ステップＳ６０４）。

クラウド１００は、ファイルデータのダウンロード要求を受け付けると、ファイルデータに対するアクセス権限を確認し、ファイルデータのダウンロード可否を判定する（ステップＳ６０５）。そして、クラウド１００は、ダウンロードが可である場合に、ファイルデータを仲介装置３００に応答する（ステップＳ６０６）。仲介装置３００は、クラウド１００から応答されたファイルデータを機器４００に転送する（ステップＳ６０７）。そして、仲介装置３００は、ファイル転送を完了したことを示すファイル転送の結果通知をクラウド１００に送信する（ステップＳ６０８）。クラウド１００は、ファイル転送の結果通知をアプリ２００に送信する（ステップＳ６０９）。

［アップロード時の判定処理］
次に、図２０を用いて、実施の形態に係るアップロード時の判定処理を説明する。図２０は、実施の形態に係るアップロード時の判定処理の流れの例を示すフローチャートである。アップロード時の判定処理とは、ファイルデータのアップロード要求を受け付けた際に、クラウド１００が実行する処理を指す。

図２０に示すように、クラウド１００は、ファイルデータのアップロード要求を受け付けると、証明書にアプリＩＤが存在するか否かを判定する（ステップＳ７０１）。このとき、クラウド１００は、証明書にアプリＩＤが存在する場合に（ステップＳ７０１：Ｙｅｓ）、アプリＩＤが実際に存在するＩＤであるかをチェックする処理を実行する（ステップＳ７０２）。ＩＤのチェック処理は、クラウド１００が予め保持する各ＩＤの情報をもとに、ＩＤ自体が存在するか否かを確認すれば良い。

一方、クラウド１００は、証明書にアプリＩＤが存在しない場合に（ステップＳ７０１：Ｎｏ）、要求ヘッダ（例えば、ＨＴＴＰヘッダ）にコマンドＩＤが存在するか否かを判定する（ステップＳ７０３）。このとき、クラウド１００は、コマンドＩＤが存在する場合に（ステップＳ７０３：Ｙｅｓ）、コマンドＩＤが実際に存在するＩＤであるかをチェックする処理を実行する（ステップＳ７０４）。

一方、クラウド１００は、要求ヘッダにコマンドＩＤが存在しない場合に（ステップＳ７０３：Ｎｏ）、要求ヘッダにデバイスＩＤが存在するか否かを判定する（ステップＳ７０５）。このとき、クラウド１００は、デバイスＩＤが存在する場合に（ステップＳ７０５：Ｙｅｓ）、デバイスＩＤが実際に存在するＩＤであるかをチェックする処理を実行する（ステップＳ７０６）。

一方、クラウド１００は、要求ヘッダにデバイスＩＤが存在しない場合に（ステップＳ７０５：Ｎｏ）、要求ヘッダに仲介装置ＩＤが存在するか否かを判定する（ステップＳ７０７）。このとき、クラウド１００は、要求ヘッダに仲介装置ＩＤが存在する場合に（ステップＳ７０７：Ｙｅｓ）、仲介装置ＩＤが実際に存在するＩＤであるかをチェックする処理を実行する（ステップＳ７０８）。一方、クラウド１００は、要求ヘッダに仲介装置ＩＤが存在しない場合に（ステップＳ７０７：Ｎｏ）、アクセスエラーをアップロードの要求装置に返す（ステップＳ７０９）。

［ダウンロード時の判定処理］
次に、図２１を用いて、実施の形態に係るダウンロード時の判定処理を説明する。図２１は、実施の形態に係るダウンロード時の判定処理の流れの例を示すフローチャートである。ダウンロード時の判定処理とは、ファイルデータのダウンロード要求を受け付けた際に、クラウド１００がファイルデータへのアクセス権限を確認する処理を指す。

図２１に示すように、クラウド１００は、アプリ２００からのアクセスであるか否かを判定する（ステップＳ８０１）。このとき、クラウド１００は、アプリ２００からのアクセスでない場合に（ステップＳ８０１：Ｎｏ）、仲介装置３００からのアクセスであるか否かを判定する（ステップＳ８０２）。

クラウド１００は、アプリ２００からのアクセスである場合（ステップＳ８０１：Ｙｅｓ）、仲介装置３００からのアクセスである場合（ステップＳ８０２：Ｙｅｓ）、ファイルＩＤに対応するプロパティ情報をファイル記憶部１１１から取得する（ステップＳ８０３）。ここで、クラウド１００は、取得したプロパティ情報と、ファイルデータのダウンロード要求装置情報とが一致するか否かを判定する（ステップＳ８０４）。このとき、クラウド１００は、プロパティ情報とダウンロード要求装置情報とが一致する場合に（ステップＳ８０４：Ｙｅｓ）、該当するファイルデータを取得する（ステップＳ８０６）。

また、クラウド１００は、プロパティ情報とダウンロード要求装置情報とが一致しない場合に（ステップＳ８０４：Ｎｏ）、ダウンロード要求装置情報に対応する接続情報に、プロパティ情報が含まれるか否かを判定する（ステップＳ８０５）。このとき、クラウド１００は、ダウンロード要求装置情報に対応する接続情報に、プロパティ情報が含まれる場合に（ステップＳ８０５：Ｙｅｓ）、該当するファイルデータを取得する（ステップＳ８０６）。一方、クラウド１００は、仲介装置３００からのアクセスでない場合（ステップＳ８０２：Ｎｏ）、ダウンロード要求装置情報に対応する接続情報に、プロパティ情報が含まれない場合（ステップＳ８０５：Ｎｏ）、アクセスエラーを返す（ステップＳ８０８）。ファイルデータを取得したクラウド１００は、取得したファイルデータをダウンロード要求装置に応答する（ステップＳ８０７）。

上述したように、クラウド１００は、ファイルデータのアップロード時に、ファイルデータのダウンロード可否を判定する際に用いられるアップロードの要求元情報を登録するので、ファイルデータの取得に関するセキュリティを向上させることができる。

また、クラウド１００は、ファイルデータのダウンロードを要求してきた装置の情報がアップロードの要求元情報に一致する場合に、該当するファイルデータを応答するので、ファイルデータの取得に関するセキュリティを向上させることができる。

また、クラウド１００は、ファイルデータのダウンロードを要求してきた装置の情報がアップロードの要求元情報に一致しない場合、ダウンロードを要求してきた装置を含む接続情報に、アップロードの要求元情報が存在するか否かを判定し、存在する場合に該当するファイルデータを応答するので、ファイルデータの取得に関するセキュリティを向上させることができる。

また、上記文書中や図面中等で示した処理手順、制御手順、具体的名称、各種のデータやパラメータ等を含む情報は、特記する場合を除いて任意に変更することができる。また、図示した装置の各構成要素は、機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、装置の分散又は統合の具体的形態は、図示のものに限られず、その全部又は一部を各種の負担や使用状況等に応じて、任意の単位で機能的又は物理的に、分散又は統合することができる。

また、クラウド１００で実行される情報処理プログラムは、一つの様態として、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。また、クラウド１００で実行される情報処理プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、クラウド１００で実行される情報処理プログラムをインターネット等のネットワーク経由で提供又は配布するように構成しても良い。また、情報処理プログラムを、ＲＯＭ等に予め組み込んで提供するように構成しても良い。

クラウド１００で実行される情報処理プログラムは、上述した各部（取得部１２１、登録部１２２）を少なくとも含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ（プロセッサ）が記憶媒体から情報処理プログラムを読み出して実行することにより、上記各部が主記憶装置上にロードされ、取得部１２１、登録部１２２が主記憶装置上に生成されるようになっている。

１ 情報処理システム
１００ クラウド
１１１ ファイル記憶部
１１２ 接続情報記憶部
１２１ 取得部
１２２ 登録部
１２３ 暗号化部
１２４ 第１判定部
１２５ 第２判定部
１２６ 応答部
１２７ 復号部
１２８ コマンド制御部
２００ アプリ
３００ 仲介装置
４００ 機器

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

Claims (8)

1. ファイルデータのアップロード要求の要求元を示すアップロード要求元情報を取得する取得部と、
   ファイルデータのダウンロード可否を判定する際に用いられるファイル記憶部に、取得された前記アップロード要求元情報を登録する登録部と
   を有することを特徴とする情報処理装置。
2. ファイルデータのダウンロードを要求してきた装置を示すダウンロード要求装置情報と、前記ファイル記憶部に記憶された前記アップロード要求元情報とが一致するか否かを判定する第１判定部と、
   前記ダウンロード要求装置情報と、前記アップロード要求元情報とが一致すると判定された場合に、前記装置にファイルデータを応答する応答部とを有することを特徴とする請求項１に記載の情報処理装置。
3. アップロード要求の要求元間における情報送受のための接続関係を示す接続情報を記憶する接続情報記憶部と、
   前記ダウンロード要求装置情報と、前記アップロード要求元情報とが一致しないと判定された場合に、前記ダウンロード要求装置情報に対応する前記接続情報に、前記アップロード要求元情報が含まれるか否かを判定する第２判定部と、をさらに有し、
   前記応答部は、前記ダウンロード要求装置情報に対応する前記接続情報に、前記アップロード要求元情報が含まれると判定された場合に、前記装置にファイルデータを応答することを特徴とする請求項２に記載の情報処理装置。
4. 前記登録部は、ファイルデータのダウンロードの有効期限を示す有効期限情報をさらに登録し、
   前記応答部は、前記有効期限情報をもとにダウンロードが可能である場合に、前記装置にファイルデータを応答することを特徴とする請求項２又は３に記載の情報処理装置。
5. ファイルデータを暗号化する暗号化部と、
   暗号化されたファイルデータを復号する復号部と、をさらに有し、
   前記登録部は、暗号化されたファイルデータを前記ファイル記憶部に登録し、
   前記応答部は、復号化されたファイルデータを前記装置に応答することを特徴とする請求項２〜４の何れか一つに記載の情報処理装置。
6. 情報処理装置で実行される情報処理方法であって、
   ファイルデータのアップロード要求の要求元を示すアップロード要求元情報を取得する取得工程と、
   ファイルデータのダウンロード可否を判定する際に用いられるファイル記憶部に、取得された前記アップロード要求元情報を登録する登録工程と
   を含むことを特徴とする情報処理方法。
7. ファイルデータのアップロード要求の要求元を示すアップロード要求元情報を取得する取得ステップと、
   ファイルデータのダウンロード可否を判定する際に用いられるファイル記憶部に、取得された前記アップロード要求元情報を登録する登録ステップと
   をコンピュータに実行させるための情報処理プログラム。
8. 要求装置と情報処理装置とを有する情報処理システムであって、
   前記要求装置は、
   ファイルデータのアップロードを要求するまでに経由してきた装置全ての識別情報を含むアップロード要求を前記情報処理装置に送信する送信部を有し、
   前記情報処理装置は、
   前記要求装置から前記アップロード要求を受信する受信部と、
   受信された前記アップロード要求に含まれる前記識別情報をもとに、ファイルデータのアップロード要求の要求元を示すアップロード要求元情報を取得する取得部と、
   ファイルデータのダウンロード可否を判定する際に用いられるファイル記憶部に、取得された前記アップロード要求元情報を登録する登録部と
   を有することを特徴とする情報処理システム。

Images