JP6545000B2 - アップロード管理システム、アップロード管理システムの制御方法、及びプログラム - Google Patents

Description

本発明は、認証されたクライアントからのデータアップロードを管理するためのアップロード管理システムに関する。

近年、スマートフォンなどのクライアントから、インターネット上のネットワークストレージにデータをアップロードするような事例が増えてきている。この場合、スマートフォンなどを紛失したりして、悪意のある第三者に利用されてしまった場合、大量のデータがネットワークストレージにアップロードされてしまう可能性があり。その場合、多額のネットワークストレージの利用料をユーザが請求されてしまう可能性がある。また、ユーザの保存領域がいっぱいになり、ユーザが真にアップロードしたいデータのアップロードができなくなってしまう可能性もある。さらに、ユーザの保存領域が他のユーザに公開する設定となっている場合などでは、機密情報の漏洩の原因となってしまう可能性もある。

一般的に、こういった事例を防ぐための方策としては、ユーザがアップロードしているコンテンツのファイルサイズ等をチェックし、しきい値以上のものはアップロードさせないなどの対応が考えられる。

特許文献１においては、ネットワークに接続するノード間で通信されるコンテンツの総データ量が所定のデータ量を超えた場合に、アップロードの抑止を行う。このようにすることで、前述したような悪意のある第三者による大量のデータのアップロードをすることができなくなる。

特開２００９−１７７７８３号公報

特許文献１において示されるような、アップロード時のコンテンツデータのサイズ監視によるアップロードの抑止を行うためには、コンテンツのアップロードリクエストを受信するストレージシステムが、コンテンツサイズの監視などの処理を行う必要がある。

しかし、サードパーティなどが提供するストレージシステムなどを利用する場合、ストレージシステム自体に対して新たな処理を加えることはできない。このような場合、特許文献１に示すような技術はそのまま適用できず、コンテンツサイズによるアップロード抑止ができないという問題が存在する。

また、コンテンツサイズ監視用のサーバを新規に設置し、このサーバが、クライアントからのコンテンツアップロードを受信し、サイズなどをチェックしたのちに、ストレージシステムにデータ保存するといったシステムも考えられる。
しかし、この場合、コンテンツサイズ監視用のサーバは、大量のリクエストや、大容量のデータを一度受け付ける必要があるため、パフォーマンスに考慮が必要となり、システム全体として最適ではないといえる。

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、ストレージシステムに変更を加えることなく、また、負荷を大きくしてパフォーマンスを劣化させることなく、コンテンツのサイズや数に応じたアップロード抑止を行うことが可能な負荷の小さなアップロード管理システムを構築可能な仕組みを提供することである。

本発明は、クライアントからストレージシステムへのデータアップロードを管理するアップロード管理システムであって、前記データアップロードを行うクライアントからの要求に応じて、該クライアントにより既にアップロードされたデータに関する情報を、前記ストレージシステムから取得する取得手段と、前記取得手段により取得された情報に基づいて、該クライアントが所定の条件に違反しているか否かを判定する判定手段と、前記判定手段により前記条件に違反していないと判定された場合には該クライアントに対して前記データアップロードを行うための認証情報の返却を行い、一方、前記条件に違反していると判定された場合には前記認証情報の返却を行わず、さらに該クライアントの情報が一度、所定の通知先に通知されている場合には、前記通知を行わない制御手段と、を有することを特徴とする。

本発明によれば、ストレージシステムに変更を加えることなく、また、負荷を大きくしてパフォーマンスを劣化させることなく、コンテンツのサイズや数に応じたアップロード抑止を行うことが可能となる。

本実施例のシステム構成図 本実施例のシステムに適用可能な情報処理装置のハードウェア構成図 本実施例のシステムの機能ブロック図 実施例１におけるコンテンツアップロード処理のフローチャート アクセストークン取得処理のフローチャート アクセストークン検証処理のフローチャート 実施例２におけるコンテンツアップロード処理のフローチャート 実施例３におけるコンテンツアップロード処理のフローチャート 実施例５におけるコンテンツ監視処理のフローチャート

以下、本発明を実施するための形態について図面を用いて説明する。

図１は、本発明の一実施例を示すシステムの構成を例示する図である。
図１に示すように、本実施例のシステムでは、クライアント１０１、認証システム１０３、アップロード管理システム１０４、ストレージシステム１０５が、インターネット１０２を介して接続されている。

クライアント１０１は、ストレージシステム１０５等に接続可能な情報処理装置であれば、パーソナルコンピュータ（ＰＣ）や、タブレット型端末、スマートフォン、またその他デバイス（例えば、複写機、複合機等の画像形成装置）でも構わない。

認証システム１０３、アップロード管理システム１０４、ストレージシステム１０５は、それぞれＷｅｂサービスが動作するＷｅｂサーバ１０６、１０８、１１０を備える。それぞれのＷｅｂサーバでは、ＨＴＴＰや、ＳＯＡＰなどのプロトコルに準じたＷｅｂサービスがホストされる。

データベースシステム１０７は、認証サービスにて用いられるデータ、例えばユーザＩＤやパスワード等を管理する。データ保存システム１１０は、クライアントからアップロードされたコンテンツそのものや、コンテンツのメタデータ（例えば、コンテンツサイズや、コンテンツパス等）を管理する。

図１においては、認証システム１０３、アップロード管理システム１０４が、別のシステムとして記載されているが、１つのシステムとして統合してもよい。また、その場合、Ｗｅｂサーバ１０６，１０８、およびデータベースシステム１０７を、同一のサーバ上で動作させても構わない。

図２は、クライアント１０１、Ｗｅｂサーバ１０６、１０８、１０９、データベースシステム１０７、および、データ保存システム１１０のハードウェア構成を例示する図である。Ｗｅｂサーバ１０６、１０８、１０９、データベースシステム１０７、および、データ保存システム１１０は、一般的な情報処理装置（いわゆるＰＣ）のハードウェアで構成することができる。

図２において、ＣＰＵ２０１は、ＲＯＭ２０３内のプログラム用ＲＯＭに記憶されたプログラムや、ハードディスク２１０からＲＡＭ２０２にロードされたＯＳ（オペレーティングシステム）やアプリケーション等のプログラムを実行する。すなわち、ＣＰＵ２０１が、読み取り可能な記憶媒体に格納された該プログラムを実行することにより、後述する各フローチャートの処理を実行する各処理部として機能する。

ＲＡＭ２０２は、ＣＰＵ２０１のメインメモリであり、ワークエリア等として機能する。ＲＯＭ２０３のプログラムＲＯＭには、ＣＰＵ２０１が実行するプログラムが格納されている。ＲＯＭ２０３のデータＲＯＭには、各種データが格納されている。

キーボードコントローラ２０４は、キーボード２０８や図示しないポインティングデバイス（マウス、タッチパッド、タッチパネル、トラックボールなど）からの操作入力を制御する。ディスプレイコントローラ２０５は、ディスプレイ２０９の表示を制御する。ディスクコントローラ２０６は、各種データを記憶するハードディスク（ＨＤ）や、ソリッドステートドライブ（ＳＳＤ）、フレキシブルディスク（ＦＤ）等の外部メモリ２１０へのデータアクセスを制御する。ネットワークコントローラ（ＮＣ）２０７は、ネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。外部メモリ２１０には、ＣＰＵ２０１が実行可能なＯＳやアプリケーション等のプログラム、各種データが格納されている。

図３は、本実施例のシステムの各機能構成を例示するブロック図である。
まず、クライアント１０１についての説明を行う。
クライアント１０１は、ファイルのアップロード処理を行うためのものであり、入力受付部３０１、画面表示部３０２、認証処理部３０３、コンテンツ保存情報取得部３０４、ストレージ操作部３０５等の機能部を有する。これらの機能部は、クライアント１０１のＣＰＵ２０１が外部メモリ２１０に格納されたプログラムをＲＡＭ２０２にロードして実行することにより実現されるものである。

入力受付部３０１は、アップロードするコンテンツの選択や、認証情報の入力等、クライアント１０１の利用者からの入力を受け付ける。画面表示部３０２は、入力された認証情報や、コンテンツの選択結果などを、クライアント１０１の利用者に対して視覚的な情報を表示する。

認証処理部３０３は、認証システム１０３と通信して、アップロード管理システム１０４にアクセスするための認証情報を取得する。
コンテンツ保存情報取得部３０４は、アップロード管理システム１０４と通信して、ストレージシステム１０５にアクセスするための認証情報や、コンテンツのアップロードパス（例えばＵＲＬ等）等、種々の情報を取得する。
ストレージ操作部３０５は、コンテンツ保存情報取得部３０４が取得したコンテンツのアップロードパスや、認証処理部３０３が取得した認証情報を用いて、ストレージシステム１０５に対してアクセスし、コンテンツをアップロードする。

次に、認証システム１０３についての説明を行う。
認証システム１０３は、クライアント登録受付部３２１、アクセストークン発行部３２２、アクセストークン検証部３２３、クライアント管理テーブル３２４、アクセストークン管理テーブル３２５等の機能部を有する。これらの機能部は、認証システム１０３を構成する各情報処理装置のＣＰＵ２０１が外部メモリ２１０に格納されたプログラムをＲＡＭ２０２にロードして実行することにより実現されるものである。

クライアント登録受付部３２１は、クライアント１０１の認証処理部３０３からのクライアント情報（例えば、クライアント名など）を受け取り、後述する表１に示すクライアント管理テーブル３２４に保存する。この時、クライアント登録受付部３２１は、クライアント１０１の認証を行う。認証方法としては、Ｂａｓｉｃ認証、ＤｉｇｅＳ７認証や、クライアント証明書などを用いた認証など複数考えられるが、そのいずれでも構わない。また、クライアント登録受付部３２１は、クライアント１０１の認証に成功した場合には、クライアントＩＤ、およびクライアントパスワードを発行し、クライアント１０１の認証処理部３０３に送信する。このクライアントＩＤ、およびクライアントパスワードは、後述する表１に示すように、クライアント管理テーブル３２４にて、クライアントの情報などと紐づけられて管理される。

アクセストークン発行部３２２は、クライアント１０１の認証処理部３０３から送信されたクライアントＩＤ、およびクライアントパスワードを、クライアント管理テーブル３２４のそれらを用いて検証する。アクセストークン発行部３２２は、検証の結果、正しい組み合わせであることが確認できたら、アクセストークンを発行し、クライアント１０１の認証処理部３０３に送信する。このアクセストークンは、コンテンツ保存情報取得部３０４がアップロード管理システム１０４にアクセスするときの認証情報となる。発行されたアクセストークンの値や、その有効期限などは、後述する表２に示すアクセストークン管理テーブル３２５に保存される。

アクセストークン検証部３２３は、アップロード管理システム１０４がクライアント１０１から受け取ったアクセストークンの妥当性を検証するためのリクエストを受け付ける。アクセストークン検証部３２３は、アクセストークン管理テーブル３２５に保存された情報を照会し、アクセストークンの妥当性（有効期限や、その値の正しさ等）を検証する。アクセストークン検証部３２３は、アクセストークンの検証に成功した場合には、アクセストークンに紐づくクライアントの情報を、アップロード管理システム１０４に返却する。

以下、クライアント管理テーブル３２４の説明を、表１を用いて行う。
表１に示すように、クライアント管理テーブル３２４は、クライアント名（Ａ１）、クライアントＩＤ（Ａ２）、クライアントパスワード（Ａ３）の３項目を有する。

クライアント名（Ａ１）は、クライアント１０１によって指定されるクライアントを表す名称である。なお、ここではクライアント名を用いたが、クライアントを識別可能な識別子であれば、他の識別子であってもよい。本項目は、後述するコンテンツ保存情報発行部３４１にて利用される。
クライアントＩＤ（Ａ２）、およびクライアントパスワード（Ａ３）は、クライアント登録受付部３２１によって、クライアント１０１毎に発行されるＩＤ、およびパスワードである。なお、クライアント１０１のコンテンツ保存情報取得部３０４は、このクライアントＩＤ（Ａ２）、およびクライアントパスワード（Ａ３）を用いて、アクセストークン発行部３２２にアクセスする。

以下、アクセストークン管理テーブル３２５について、表２を用いて説明する。
表２に示すように、アクセストークン管理テーブル３２５は、クライアントＩＤ（Ｂ１）、アクセストークン（Ｂ２）、有効期限（Ｂ３）の３項目を有する。

クライアントＩＤ（Ｂ１）には、クライアント１０１がクライアント登録受付部３２１から発行されたクライアントＩＤが設定される。
アクセストークン（Ｂ２）は、アクセストークン発行部３２２が発行したアクセストークンが設定される。
有効期限（Ｂ３）には、そのアクセストークンが有効となる期限が設定される。

次に、アップロード管理システム１０４について説明する。
アップロード管理システム１０４は、クライアント１０１からストレージシステム１０５へのデータアップロードを管理するものであり、実施例１では、コンテンツ保存情報発行部３４１、クライアント情報取得部３４２、違反クライアント検出部３４３等の機能部を有する。これらの機能部は、アップロード管理システム１０４を構成する各情報処理装置のＣＰＵ２０１が外部メモリ２１０に格納されたプログラムをＲＡＭ２０２にロードして実行することにより実現されるものである。なお、アラート通知部３４４については実施例２で必須の構成、違反クライアント管理部３４５については実施例３で必須の構成、コンテンツ監視部３４６については実施例５で必須の構成であり、これらは実施例１では必須の構成ではないため、説明は実施例２以降で行う。

コンテンツ保存情報発行部３４１は、クライアント１０１のコンテンツ保存情報取得部３０４からのリクエストを受け付ける。この時、リクエストには、アクセストークン発行部３２２によって発行されたアクセストークンが含まれる。コンテンツ保存情報発行部３４１は、リクエスト受信日、および後述するクライアント情報取得部３４２を介して取得するクライアント情報に含まれるクライアント名を用いて、クライアント１０１からアップロードされるコンテンツの保存先を決定する。具体的には、クライアント名が「ＣｌｉｅｎｔＡ」、日付が「２０１５年５月５日」とした場合、保存先のパスに、「＊／ＣｌｉｅｎｔＡ／２０１５０５０５／＊」というように、クライアント名と受け付けた日付が入るように決定する。なお、「＊」には、どういった階層が設定されていてもよい。また、コンテンツ保存情報発行部３４１は、クライアント１０１がストレージシステム１０５にアクセスするための認証情報も併せて発行し、保存先のパス、および認証情報を、クライアント１０１に返却する。

クライアント情報取得部３４２は、コンテンツ保存情報発行部３４１から渡されたアクセストークンを、認証システム１０３のアクセストークン検証部３２３に渡し、正しいアクセストークンであることが確認された場合に返却されるクライアント情報を受け取る。

違反クライアント検出部３４３は、リクエスト元のクライアント名、およびリクエスト受信日から定まるコンテンツの保存先に、所定の条件を満たすコンテンツが保存されていないかをチェックする。この条件は、例えば「しきい値を超えるサイズのコンテンツがすでにアップロードされている」、および「しきい値を超える数のコンテンツがすでにアップロードされている」の２つとし、これらのしきい値は、静的に定められているものとする。違反クライアント検出部３４３は、これらの条件を満たす場合には、セキュリティ的な違反が発生しているものと判断し、クライアント１０１に対してエラーレスポンスを返却する。

最後に、ストレージシステム１０５について説明する。
ストレージシステム１０５は、コンテンツ受信部３６１、コンテンツメタデータ管理部３６２、コンテンツ保存部３６３等の機能部を有する。これらの機能部は、ストレージシステム１０５を構成する各情報処理装置のＣＰＵ２０１が外部メモリ２１０に格納されたプログラムをＲＡＭ２０２にロードして実行することにより実現されるものである。

コンテンツ受信部３６１は、クライアント１のストレージ操作部３０５からのリクエストを受信し、コンテンツをコンテンツ保存部３６３に保存し、コンテンツのメタデータ（例えば、ファイルサイズや階層等）を、コンテンツメタデータ管理部３６２に保存する機能を持つ。

コンテンツメタデータ管理部３６２は、コンテンツのメタデータを管理し、前述したアップロード管理システム１０４の違反クライアント検出部３４３からの、メタデータ取得リクエストに対して応答する機能を持つ。メタデータには、後述する表３に示すような情報が含まれている。なお、表３に示す情報や保持形式は一例であり、他の情報が保存されていたり、他の形式で保存されていたりしてもかまわない。

以下、表３を用いてメタデータとして保存されている内容、および、前述した違反クライアント検出部３４３のより具体的な動作について説明する。
なお、Ｎｏ列に関しては説明のために付与しただけであり、実際のメタデータには必要ない。Ｎｏ１の項目は、階層「＊／ＣｌｉｅｎｔＡ／２０１５０５０４／＊」に「ｄａｔａ１．ｄａｔ」というコンテンツが保存されており、そのサイズが３ＭＢｙｔｅであることを表している。

ここで、前述した違反クライアント検出部３４３の具体的な動作について説明する。
コンテンツ保存情報発行部３４１が、クライアント名「ＣｌｉｅｎｔＡ」からのリクエストを「２０１５年５月５日」に受信した場合、違反クライアント検出部３４３は、コンテンツメタデータ管理部３６２に対して、引数として「ＣｌｉｅｎｔＡ」、および「２０１５０５０５」の情報を渡す。コンテンツメタデータ管理部３６２は、階層２（Ｃ２）が「ＣｌｉｅｎｔＡ」、階層３（Ｃ３）が「２０１５０５０５」となる項目数と、そのサイズのリストを違反クライアント検出部３４３に返却する。この場合、項目数は「１」、サイズのリストは「３Ｍｂｙｔｅ」となる。違反クライアント検出部３４３は、それらの数量がしきい値を超えているか否かを判断する。例えば、コンテンツ数のしきい値を「２０」、コンテンツサイズのしきい値を「５Ｍｂｙｔｅ」とすると、この場合、コンテンツ数、およびサイズ共にしきい値を超えていないと判断される。

一方、コンテンツ保存情報発行部３４１が、クライアント名「ＣｌｉｅｎｔＢ」からのリクエストを「２０１５年５月５日」に受信した場合、違反クライアント検出部３４３に、返却される項目数が「２１」となる。このため、コンテンツ数のしきい値「２０」を超えていることになり、クライアント１０１にはエラーレスポンスが返却される。

また、コンテンツ保存情報発行部３４１が、クライアント名「ＣｌｉｅｎｔＣ」からのリクエストを「２０１５年５月５日」に受信した場合、違反クライアント検出部３４３に、返却されるサイズのリストは「１００ＭＢｙｔｅ」となる。このため、コンテンツサイズのしきい値「５Ｍｂｙｔｅ」を超えることになり、クライアント１０１にはエラーレスポンスが返却される。

コンテンツ保存部３６３は、クライアント１０１からアップロードされたコンテンツを保存する保存システムである。この保存システムは、ファイルシステムやデータベースシステムなど、コンテンツを保存できるシステムであれば、何でも構わない。

以下、図４、図５、図６を用いて、クライアント１０１からのコンテンツアップロード処理について説明する。
図４は、実施例１におけるクライアント１０１からのコンテンツをアップロードする場合の一連の処理を例示するフローチャートである。なお、図４及び後述する図５〜図９中のクライアント１の処理は、クライアント１０１のＣＰＵ２０１が外部メモリ２１０に格納されたプログラムをＲＡＭ２０２にロードして実行することにより実現される。また、同図中、認証システム１０３の処理は、認証システム１０３を構成する各情報処理装置のＣＰＵ２０１が外部メモリ２１０に格納されたプログラムをＲＡＭ２０２にロードして実行することにより実現される。また、同図中、アップロード管理システム１０４の処理は、アップロード管理システム１０４を構成する各情報処理装置のＣＰＵ２０１が外部メモリ２１０に格納されたプログラムをＲＡＭ２０２にロードして実行することにより実現される。

Ｓ４０１において、認証処理部３０３は、図５に示すフローチャートに従ってアクセストークンの取得を行う。この処理の詳細は図５の説明にて行う。なお、この処理において、認証処理部３０３は、アクセストークンを取得する。

Ｓ４０２において、コンテンツ保存情報取得部３０４は、コンテンツ保存情報発行部３４１に対して、コンテンツ保存情報取得リクエストを、アップロード管理システム１０４に対して発行する。この時、上記Ｓ４０１で取得したアクセストークンを引数に指定する。

Ｓ４０３において、アップロード管理システム１０４のコンテンツ保存情報発行部３４１は、コンテンツ保存情報取得リクエストを受信する。
Ｓ４０４において、クライアント情報取得部３４２は、図６に示すフローチャートに従ってアクセストークンの検証処理を行う。この処理の詳細は図６の説明にて行う。なお、この処理において、クライアント情報取得部３４２は、アップロード管理システム１０４のアクセストークン検証部３２３から返却されるレスポンスを受信する。

Ｓ４０５において、クライアント情報取得部３４２は、アクセストークン検証部３２３から返却されたレスポンスがエラーレスポンスか否かを判定する。そして、エラーレスポンスであると判定した場合（Ｓ４０５でＹｅｓの場合）、Ｓ４０６に遷移する。
Ｓ４０６において、コンテンツ保存情報発行部３４１は、クライアント１のコンテンツ保存情報取得部３０４にエラーレスポンスを返却する。この時、エラーレスポンスには、アクセストークンの検証で失敗したことを表す情報を含める。

一方、エラーレスポンスでないと判定した場合（Ｓ４０５でＮｏの場合）、Ｓ４０７に遷移する。
Ｓ４０７において、コンテンツ保存情報発行部３４１は、アクセストークン検証部３２３から返却されたクライアント名、および、コンテンツ保存情報発行部３４１がリクエストを受信した日付を用いて、コンテンツの保存階層を決定する。そして、Ｓ４０８に遷移する。

Ｓ４０８において、違反クライアント検出部３４３は、上記Ｓ４０７で定めた保存階層に存在するコンテンツ数、およびコンテンツサイズのリストの取得リクエストを、ストレージシステム１０５に対して発行する。
Ｓ４０９において、ストレージシステム１０５のコンテンツメタデータ管理部３６２は、上記Ｓ４０８のリクエストを受信し、指定された階層上に存在するコンテンツ数、およびコンテンツサイズのリストを、アップロード管理システム１０４に返却する。

Ｓ４１０において、アップロード管理システム１０４の違反クライアント検出部３４３は、ストレージシステム１０５から返却されたコンテンツ数が、コンテンツ数のしきい値以上か否かを判断する。そして、上記コンテンツ数が、コンテンツ数のしきい値以上であると判断した場合（Ｓ４１０でＹｅｓの場合）、Ｓ４１３に遷移する。

一方、上記コンテンツ数が、コンテンツ数のしきい値未満であると判断した場合（Ｓ４１０でＮｏの場合）、Ｓ４１１に遷移する。

Ｓ４１１において、違反クライアント検出部３４３は、返却されたコンテンツサイズのリストの中に、コンテンツサイズのしきい値以上となるサイズのコンテンツが存在するか否かを判断する。そして、コンテンツサイズのしきい値以上のサイズとなるコンテンツが存在しないと判断した場合（Ｓ４１１でＮｏの場合）、Ｓ４１２に遷移する。
Ｓ４１２では、コンテンツ保存情報発行部３４１は、コンテンツ保存パスを作成する。また、コンテンツ保存情報発行部３４１は、ストレージシステムにクライアント１がアクセスするための認証情報も作成し、それらの情報を、クライアント１０１に返却する。

一方、コンテンツサイズのしきい値以上のサイズとなるコンテンツが存在すると判断した場合（Ｓ４１１でＹｅｓの場合）、Ｓ４１３に遷移する。
Ｓ４１３において、コンテンツ保存情報発行部３４１は、エラーレスポンスをクライアント１０１に返却する。この時、エラーレスポンスには、しきい値チェックで違反した旨を表す情報を含める。

Ｓ４１４において、クライアント１０１のコンテンツ保存情報取得部３０４は、返却されたレスポンスをチェックし、レスポンスにアクセストークンに失敗したことを表す情報が含まれているか否かを判定する。そして、レスポンスにアクセストークンに失敗したことを表す情報が含まれていると判定した場合（Ｓ４１４でＹｅｓの場合）、Ｓ４０１に遷移し、再度アクセストークンの取得を行う。

一方、レスポンスにアクセストークンに失敗したことを表す情報が含まれていないと判定した場合（Ｓ４１４でＮｏの場合）、Ｓ４１５に遷移する。
Ｓ４１５において、コンテンツ保存情報取得部３０４は、レスポンスにしきい値チェックで違反したことを表す情報が含まれているか否かを判定する。
そして、レスポンスにしきい値チェックで違反したことを表す情報が含まれていると判定した場合（Ｓ４１５でＹｅｓの場合）、本フローチャートの処理を終了させる。この際、ユーザに、その旨を通知してもよい。

一方、レスポンスにしきい値チェックで違反したことを表す情報が含まれていないと判定した場合（Ｓ４１５でＮｏの場合）、Ｓ４１６に遷移する。
Ｓ４１６において、ストレージ操作部３０５は、上記レスポンスに含まれる、アップロード管理システム１０４のコンテンツ保存情報発行部３４１が発行したコンテンツパス、および認証情報を用いて、ストレージシステム１０５に、コンテンツをアップロードする。

Ｓ４１７において、ストレージシステム１０５のコンテンツ受信部３６１は、ストレージ操作部３０５からアップロードされたコンテンツを受信する。
Ｓ４１８において、コンテンツ受信部３６１は、上記Ｓ４１７で受信したコンテンツをコンテンツ保存部３６３に保存し、併せて該コンテンツのサイズ等のメタデータをコンテンツメタデータ管理部３６２に保存する。そして、コンテンツ受信部３６１は、保存結果を、クライアント１０１のストレージ操作部３０５に返却する。

Ｓ４１９において、クライアント１０１のストレージ操作部３０５は、ストレージシステム１０５のコンテンツ受信部３６１からのレスポンスを受信する。そして、本フローチャートの処理を終了させる。この際、コンテンツのアップロードが成功した旨をユーザに通知してもよい。

次に、図５を用いて、図４のＳ４０１のアクセストークン取得処理について説明する。
図５は、アクセストークン取得処理の一例を示すフローチャートである。
Ｓ５０１において、認証処理部３０３は、予めクライアント１０１の外部メモリ２１０等で保持しているユーザＩＤ、パスワードを用いて、クライアント情報の登録リクエストを、認証システム１０３に発行する。この時クライアント情報には、クライアント１０１を一意に特定可能なクライアント名を含める。

Ｓ５０２において、認証システム１０３のクライアント登録受付部３２１は、クライアント登録リクエストを受信する。
Ｓ５０３において、クライアント登録受付部３２１は、クライアント１０１の認証処理部３０３から送信されてきたユーザＩＤ，パスワードが正しいものか否かを判定する。そして、判定の結果、これらが正しい場合には、クライアント登録受付部３２１は、クライアント情報、クライアントＩＤ、およびクライアントパスワードを発行し、クライアント管理テーブル３２４に登録する。併せて、クライアント登録受付部３２１は、クライアントＩＤ、およびクライアントパスワードを、クライアント１０１の認証処理部３０３に返却する。

Ｓ５０４において、クライアント１０１の認証処理部３０３は、認証システム１０３から返却されたクライアントＩＤ、およびクライアントパスワードを指定して、アクセストークン取得リクエストを、認証システム１０３に発行する。

Ｓ５０５において、認証システム１０３のアクセストークン発行部３２２は、アクセストークン取得リクエストを受信する。
Ｓ５０６において、アクセストークン発行部３２２は、アクセストークン取得リクエストとして受け取ったクライアントＩＤ、およびクライアントパスワードが、クライアント管理テーブル３２４に存在するか否かを判定する。

そして、上記クライアントＩＤおよびクライアントパスワードがクライアント管理テーブル３２４に存在しないと判定した場合（Ｓ５０６でＮｏの場合）、Ｓ５０７に遷移する。
Ｓ５０７において、アクセストークン発行部３２２は、クライアント１０１の認証処理部３０３に、クライアントＩＤ、およびクライアントパスワードの組が存在しない旨の情報を埋め込んだエラーレスポンスを返却する。

一方、上記クライアントＩＤおよびクライアントパスワードがクライアント管理テーブル３２４に存在すると判定した場合（Ｓ５０６でＹｅｓの場合）、Ｓ５０８に遷移する。
Ｓ５０８において、アクセストークン発行部３２２は、アクセストークンを発行し、アクセストークン管理テーブル３２５にクライアント名と紐づけて保存する。そして、アクセストークン発行部３２２は、該発行したアクセストークンを、クライアント１０１の認証処理部３０３に返却する。

Ｓ５０９において、クライアント１０１の認証処理部３０３は、認証システム１０３からのレスポンスをチェックし、受信したレスポンスが、クライアントＩＤおよびクライアントパスワードが存在しないことを表すエラーレスポンスか否かを判定する。
そして、エラーレスポンスであると判定した場合（Ｓ５０９でＹｅｓの場合）、Ｓ５０１に遷移する。なお、基本的にクライアントパスワードが存在しないことはないが、何らかの原因によりクライアントパスワードが削除される可能性もあるため、本分岐が存在する。

一方、エラーレスポンスでないと判定した場合（Ｓ５０９でＮｏの場合）、認証処理部３０３は、本フローチャートの処理を終了させる。

最後に、図６を用いて、図４のＳ４０４のアクセストークン検証処理について説明する。
図６は、アクセストークン検証処理の一例を示すフローチャートである。

Ｓ６０１において、アップロード管理システム１０４のクライアント情報取得部３４２は、認証システム１０３に対して、アクセストークンの検証リクエストを発行する。
Ｓ６０２において、認証システム１０３のアクセストークン検証部３２３は、アクセストークン検証リクエストを受信する。

Ｓ６０３において、アクセストークン検証部３２３は、アクセストークン管理テーブル３２５に、上記Ｓ６０２で受け付けたアクセストークンが存在するか否かを判定する。そして、該アクセストークンが存在すると判定した場合（Ｓ６０３でＹｅｓの場合）、Ｓ６０４に遷移する。

Ｓ６０４において、アクセストークン検証部３２３は、上記Ｓ６０２で受け付けたアクセストークンの有効期限を、アクセストークン管理テーブル３２５のそれと比較し、現在時刻が有効期限内か否かを判定する。そして、該アクセストークンが有効期限を超えている（有効期限切れ）と判定した場合（Ｓ６０４でＹｅｓの場合）、Ｓ６０５に遷移する。
また、上記Ｓ６０３において、該アクセストークンが存在しないと判定した場合（Ｓ６０３でＮｏの場合）にも、Ｓ６０５に遷移する。

Ｓ６０５では、アクセストークン検証部３２３は、エラーレスポンスを、アップロード管理システムに返却する。

一方、該アクセストークンが有効期限を超えていない（有効期限切れでない）と判定した場合（Ｓ６０４でＮｏの場合）、Ｓ６０６に遷移する。
Ｓ６０６では、アクセストークン検証部３２３は、アクセストークン管理テーブル３２５から取得したクライアントＩＤを用いてクライアント管理テーブル３２４から取得したクライアント名を、アップロード管理システム１０４のクライアント情報取得部３４２に返却する。
Ｓ６０７では、アップロード管理システム１０４のクライアント情報取得部３４２は、認証システム１０３から返却されたレスポンスを受信する。

以上示したような実施例１のアップロード管理システムを実現することにより、ストレージシステムにおいてサイズ監視などの機能を追加することなく、また、アップロード管理システム１０４の負荷を大きくしてパフォーマンスを劣化させることなく、コンテンツのサイズや数に応じたアップロード抑止を行うことが可能となる。

本発明に係る実施例２について説明する。以下、実施例２の構成に関しては実施例１と異なる点についてのみ説明する。

実施例１において述べたシステムの場合、クライアント１０１に対して、エラーレスポンスが返却されるのみであるため、セキュリティリスクが発生したことを、システム管理者などが気づくことができない。
そこで、本実施例２においては、違反クライアント検出部３４３が、しきい値を超えていることを検出した場合に、システム管理者などへ通知する構成とする。以下、詳細に説明する。

本実施例２を実現するにあたって、アップロード管理システム１０４に、アラート通知部３４４を追加する。
アラート通知部３４４は、違反クライアント検出部３４３がサイズの閾値もしくは数のしきい値を超えていることを検出した場合に、予め登録されているシステム管理者へのメールなどの通知処理を行う。ここで、アラート通知部３４４が行う処理は、メール送信による通知である必要はなく、例えば、管理システムへの通知でも構わない。

次に、図７を用いて、アラート通知部３４４の処理も含めた、アップロード管理システム１０４の処理フローについて説明する。
図７は、実施例２におけるクライアント１０１からのコンテンツをアップロードする場合の一連の処理を例示するフローチャートである。なお、図７の処理は、図４の処理にＳ７０１が追加されたものであり、図４と同一のステップには同一のステップ番号を付してある。以下、Ｓ７０１の説明のみ行い、他のステップの説明は省略する。

実施例２のアップロード管理システム１０４のアラート通知部３４４は、Ｓ４１１において、コンテンツサイズのしきい値以上のサイズとなるコンテンツが存在すると判断した場合（Ｓ４１１でＹｅｓの場合）、Ｓ７０１に遷移する。
Ｓ７０１において、アラート通知部３４４は、予めシステム管理者の通知先として登録されているメールアドレスへメール通知を行う。この通知には、クライアント１０１からストレージシステム１０５へアップロードされようとしたコンテンツがサイズ又は数のしきい値を超えるというセキュリティ的に異常な状態が発生したことを示す情報が含まれる。
そして、Ｓ７０１の通知の後、Ｓ４１３に遷移する。

以上、実施例２に記載のシステムを実現することにより、アップロードシステムへアップロードされているコンテンツのサイズ又は数がしきい値を超えるというセキュリティ的に異常な状態が発生していることを、システム管理者に通知することが可能となる。よって、システム管理者は、アップロードシステムへアップロードされているコンテンツのサイズ又は数がしきい値を超えるというセキュリティ的に異常な状態が発生したことを、容易に認識することが可能となる。

本発明に係る実施例３について説明する。以下、実施例３の構成に関しては実施例１、２と異なる点についてのみ説明する。

実施例２において述べたシステムの場合、あるクライアントのしきい値チェックで、一度でも、しきい値を超えると、そのクライアントからのアクセスがある度に、システム管理者への通知が行われる。そのため、運用者や、管理システムの負荷が高くなる可能性がある。
そこで、本実施例３においては、システム管理者への通知が一度でも行われたクライアントに対しては、２回目以降のシステム管理者への通知を防ぐ構成とする。以下、詳細に説明する。

本実施例３を実現するにあたって、アップロード管理システム１０４に違反クライアント管理部３４５を追加する。
違反クライアント検出部３４３は、違反クライアント検出部３４３がサイズの閾値もしくは数のしきい値を超えているクライアントを検出した場合に、違反クライアント管理部３４５に対して、すでに該クライアントに関してシステム管理者への通知を行ったかを問い合わせる。違反クライアント管理部３４５は、該クライアントのクライアント名をファイル名（すでに上記の通知が行われたクライアントに対応する情報）に含むファイルが自サーバ内に存在するか否かを検索する。そして、該ファイルが存在しない場合には、違反クライアント検出部３４３に対して、システム管理者への通知は行う旨の応答をする。一方、該ファイルが存在する場合には、システム管理者への通知は行わずクライアント１０１へのエラーレスポンスだけ返すように応答する。

なお、本実施例３では、すでにシステム管理者に通知が行われたクライアントに対応する情報としてクライアント名を用い、クライアント名の出力先としてファイルシステムを選択した。しかし、クライアント名の出力先としてデータベースシステム等を選択し、該クライアント名をキーとする情報が該データベースシステムに保存されているか否かに応じて通知の有無を切り替える構成でも構わない。また、すでにシステム管理者に通知が行われたクライアントに対応する情報としてクライアント名に限定されるものではなく、クライアントを特定可能な情報であれば他の情報であってもよい。

次に、図８を用いて、違反クライアント管理部３４５の処理も含めた、アップロード管理システム１０４の処理フローについて説明する。
図８は、実施例３におけるクライアント１０１からのコンテンツをアップロードする場合の一連の処理を例示するフローチャートである。なお、図８の処理は、図７の処理にＳ８０１及びＳ８０２が追加されたものであり、図７と同一のステップには同一のステップ番号を付してある。以下、Ｓ８０１、Ｓ８０２の説明のみ行い、他のステップの説明は省略する。

実施例３のアップロード管理システム１０４のアラート通知部３４４は、Ｓ４１１において、コンテンツサイズのしきい値以上のサイズとなるコンテンツが存在すると判断した場合（Ｓ４１１でＹｅｓの場合）、Ｓ８０１に遷移する。
Ｓ８０１において、違反クライアント管理部３４５は、Ｓ４０３で受信したコンテンツ保存情報取得リクエストを送信したクライアントのクライアント名をファイル名に含むファイル（クライアント名をキーとする情報）が、アップロード管理システム１０４を構成する情報処理装置の外部メモリ２１０内に存在するか否かを判定する。そして、ファイル名にクライアント名を含むファイルが存在しないと判定した場合（Ｓ８０１でＮｏの場合）、Ｓ８０２に遷移する。
Ｓ８０２では、違反クライアント管理部３４５は、クライアント名をファイル名としてファイルを作成し、Ｓ７０１に遷移する。
一方、ファイル名にクライアント名を含むファイルが存在すると判定した場合（Ｓ８０１でＹｅｓの場合）、Ｓ４１３に遷移する。

以上、実施例３に記載のシステムを実現することにより、一度、システム管理者への通知などを行ったクライアントに関しては、２回目以降の通知を行うことがなくなり、システム管理者の負荷削減が可能となる。

本発明に係る実施例４について説明する。以下、実施例４の構成に関しては実施例１〜３と異なる点についてのみ説明する。

実施例３に記載のシステムにおいて、システム管理者への通知を行ったことを表す情報（クライアント名をキーとする情報）の出力先としてファイルシステムを例に挙げた。即ち、クライアント名をファイル名に含むファイルを保存する構成を説明した。しかし、同じクライアントから、同時にアクセスが行われた場合、ファイルの同時書き込みなどが行われるため、処理が煩雑になる。そこで、上記クライアント名をファイル名に含むファイルのファイル名を「クライアント名_〔ランダムな文字列〕」とする。ランダムな文字列は、違反クライアント管理部３４５が出力の度に変化する値であってファイル名として使用可能な値であればどのような値であってもよい。このようにすることで、同じクライアントから、同時にアクセスが行われても同一のファイルに書き込むことがなくなるため、煩雑な処理を防ぐことが可能となる。

本発明に係る実施例５について説明する。以下、実施例５の構成に関しては実施例１と異なる点についてのみ説明する。

実施例１〜３において述べたシステムの場合、しきい値を超える大容量のデータをアップロードした後に、同一のクライアントから２度目のアップロードリクエストがない場合（即ち、一度きりのアクセスだった場合）、システム管理者などは、大量のデータがアップロードされたことに気づくことができない。

そこで、本実施例５においては、ストレージシステム１０５にアップロード済みのコンテンツを検出して、クライアントごとに、アップロード済みのコンテンツのサイズや、アップロード済みのコンテンツ数を算出する。算出した値がしきい値を超える場合には、システム管理者などへの通知を行う構成とする。

本実施例５を実現するにあたって、アップロード管理システム１０４に、コンテンツ監視部３４６を追加する。
コンテンツ監視部３４６は、コンテンツメタデータ管理部３６２に対して定期的に問い合わせを行い、全クライアントからアップロードされたファイル数と、ファイルサイズをチェックする。アップロードされたファイル数やファイルサイズがしきい値を超えているクライアントが存在する場合には、実施例３と同じように、そのクライアント名がファイル名に含まれるファイルを出力する。実施例５の違反クライアント検出部３４３は、図８のＳ８０１において、違反クライアント管理部３４５が出力するファイル、およびコンテンツ監視部３４６が出力するファイルの双方をチェックするようにする。

次に、図９を用いて、コンテンツ監視部３４６の処理について説明する。
図９は、コンテンツ監視部３４６の処理を例示するフローチャートである。

Ｓ９０１において、アップロード管理システム１０４のコンテンツ監視部３４６は、ストレージシステム１０５のコンテンツメタデータ管理部３６２に対して、全クライアントのファイル数、およびファイルサイズのリストの取得リクエストを発行する。

Ｓ９０２において、ストレージシステム１０５のコンテンツメタデータ管理部３６２は、前記リストの取得リクエストを受信すると、全クライアントがアップロードしたコンテンツの数、および各ファイルのサイズのリストを、クライアントごとにまとめて求め、アップロード管理システム１０４に返却する。この時、求める対象のコンテンツは、表３に示した階層３（Ｃ３）の値が、処理日となる項目のみとする。しかし、午前零時を跨いで処理日が変化する場合もあるため、階層３（Ｃ３）の値が、処理日及びその前日を含む期間となる項目のみとする。これは、図５のＳ４０８においてコンテンツ数およびコンテンツサイズのリストを取得する場合も同様である。

Ｓ９０３では、アップロード管理システム１０４のコンテンツ監視部３４６は、ストレージシステム１０５から返却されるリストを受信すると、該リストを用いて、クライアント毎にコンテンツ数が、コンテンツ数のしきい値以上か否かを判定する。

そして、コンテンツ数が、コンテンツ数のしきい値以上のクライアントが存在すると判定した場合（Ｓ９０３でＹｅｓの場合）、コンテンツ監視部３４６は、コンテンツ数のしきい値を超えたクライアントのリストを求め、Ｓ９０５に遷移する。

一方、コンテンツ数が、コンテンツ数のしきい値以上のクライアントが存在しないと判定した場合（Ｓ９０３でＮｏの場合）、コンテンツ監視部３４６は、Ｓ９０４に遷移する。

Ｓ９０４では、コンテンツ監視部３４６は、クライアント毎に、コンテンツサイズが、コンテンツサイズのしきい値以上か否かを判定する。
そして、コンテンツサイズが、コンテンツサイズのしきい値以上のクライアントが存在しないと判定した場合（Ｓ９０４でＮｏの場合）、コンテンツ監視部３４６は、Ｓ９０８に遷移する。

一方、コンテンツサイズが、コンテンツサイズのしきい値以上のクライアントが存在すると判定した場合（Ｓ９０４でＹｅｓの場合）、コンテンツ監視部３４６は、コンテンツサイズのしきい値を超えたクライアントのリストを求め、Ｓ９０５に遷移する。

Ｓ９０５では、コンテンツ監視部３４６は、上記Ｓ９０３もしくはＳ９０４で求められたリスト内のクライアント名を含むファイルが全て存在する（クライアント名をキーとする情報が全て存在する）か否かを判断する。そして、リスト内のクライアント名を含むファイルが全て存在すると判断した場合（Ｓ９０５でＹｅｓの場合）、コンテンツ監視部３４６は、Ｓ９０８に遷移する。

一方、リスト内のクライアント名を含むファイルで存在しないものが１つでもあると判断した場合（Ｓ９０５でＮｏの場合）、コンテンツ監視部３４６は、Ｓ９０６に遷移する。

Ｓ９０６では、コンテンツ監視部３４６は、上記Ｓ９０３もしくはＳ９０４で求められた各クライアント名のうち、まだクライアント名を含むファイルに出力されていないクライアント名をシステム管理者に通知する。
Ｓ９０７では、コンテンツ監視部３４６は、上記Ｓ９０６で通知対象となったクライアント名を含むファイルを出力し（クライアント名をキーとする情報を出力し）、Ｓ９０８に遷移する。

Ｓ９０８では、コンテンツ監視部３４６は、一定時間停止し、Ｓ９０１に遷移する。この時に停止する時間については、予め静的に定められているものとするが、管理者等により変更可能である。

以上、実施例５に記載のシステムを実現することにより、１度しかコンテンツ保存情報取得リクエストを送っていないクライアントであっても、しきい値を超えるようなコンテンツがアップロードされている場合には、システム管理者への通知が可能となる。

以上示したように、本発明の各実施例では、コンテンツをネットワークストレージへアップロードする前に、クライアントからのネットワークストレージへの保存パスや、認証情報を作成するための要求を受け付け、そのクライアントを一意に識別する値とリクエスト受信日から、保存パスを求め、該求められた保存パス上のコンテンツ数や、コンテンツのサイズをチェックし、これらの値が予め定めたコンテンツ数やコンテンツサイズのしきい値超えている場合には、ネットワークストレージへの保存パス、および認証情報は発行しない構成とする。

このように、本実施例のアップロード管理システムは、アップロードするファイルを中継等してチェックするような負荷の大きい構成ではないため、大きな負荷がかかることもない。このため、ストレージシステムに対して変更を加えることなく、また、負荷を大きくしてパフォーマンスを劣化させることなく、アップロードコンテンツの監視、およびその抑止を行うことが可能な負荷の小さなアップロード管理システムを構築することができる。

したがって、クライアントが悪意のある第三者に利用されてしまう等の場合に、大量のコンテンツがストレージシステムにアップロードされてしまうことを抑えることができる。よって、例えば、ネットワークストレージの利用代金として多額の請求がなされる危険性を抑えることができる。また、ユーザに割り当てられた保存領域がいっぱいになってしまい、真にユーザが望むデータの保存ができない等の事態の発生を抑えることができる。また、ユーザの保存領域が他のユーザに公開する設定となっている場合などでも、情報漏洩等の危険性を抑えることができる。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。

（その他の実施例）
本発明は、上述の実施例の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

１０１ クライアント
１０３ 認証システム
１０４ アップロード管理システム
１０５ ストレージシステム

Claims (12)

1. クライアントからストレージシステムへのデータアップロードを管理するアップロード管理システムであって、
   前記データアップロードを行うクライアントからの要求に応じて、該クライアントにより既にアップロードされたデータに関する情報を、前記ストレージシステムから取得する取得手段と、
   前記取得手段により取得された情報に基づいて、該クライアントが所定の条件に違反しているか否かを判定する判定手段と、
   前記判定手段により前記条件に違反していないと判定された場合には該クライアントに対して前記データアップロードを行うための認証情報の返却を行い、一方、前記条件に違反していると判定された場合には前記認証情報の返却を行わず、さらに該クライアントの情報が一度、所定の通知先に通知されている場合には、前記通知を行わない制御手段と、
   を有することを特徴とするアップロード管理システム。
2. 前記条件に違反している場合とは、該クライアントから所定の期間にアップロードされたデータの特定の数量が所定のしきい値を超える場合であることを特徴とする請求項１に記載のアップロード管理システム。
3. 前記データの特定の数量は、データの数、データのサイズの少なくともいずれかを含むことを特徴とする請求項２に記載のアップロード管理システム。
4. 前記所定の期間は、前記クライアントから前記要求があった日であることを特徴とする請求項２又は３に記載のアップロード管理システム。
5. 前記判定手段により前記条件に違反していると判定された場合に、該違反していると判定されたクライアントの情報を、前記所定の通知先に通知する第１通知手段を有することを特徴とする請求項１乃至４のいずれか１項に記載のアップロード管理システム。
6. 前記判定手段により前記条件に違反していると判定された場合に、該違反していると判定されたクライアントに対応する情報を保存システムに保存する保存手段を有し、
   前記第１通知手段は、前記保存システムに前記条件に違反していると判定されたクライアントに対応する情報が保存されている場合には、前記通知を行わないことを特徴とする請求項５に記載のアップロード管理システム。
7. 前記クライアントに対応する情報は、該クライアントを識別可能な識別子をファイル名に含むファイルであることを特徴とする請求項６に記載のアップロード管理システム。
8. 前記クライアントに対応する情報は、該クライアントを識別可能な識別子および前記保存の度に変化する値をファイル名に含むファイルであることを特徴とする請求項７に記載のアップロード管理システム。
9. 定期的に前記条件に違反しているクライアントの存在を監視する監視手段と、
   前記監視手段により前記条件に違反しているクライアントが特定された場合には、該条件に違反しているクライアントの情報を、所定の通知先に通知する第２通知手段と、を有することを特徴とする請求項５乃至８のいずれか１項に記載のアップロード管理システム。
10. 前記監視手段は、定期的に、全てのクライアントにより前記ストレージシステムへ既にアップロードされたデータに関する情報を、前記ストレージシステムから取得し、該取得した情報に基づいて、各クライアントが前記所定の条件に違反しているか否かを判定することにより、前記条件に違反しているクライアントが特定することを特徴とする請求項９に記載のアップロード管理システム。
11. クライアントからストレージシステムへのデータアップロードを管理するアップロード管理システムの制御方法であって、
    前記データアップロードを行うクライアントからの要求に応じて、該クライアントにより既にアップロードされたデータに関する情報を、前記ストレージシステムから取得する取得ステップと、
    前記取得ステップで取得された情報に基づいて、該クライアントが所定の条件に違反しているか否かを判定する判定ステップと、
    前記判定ステップで前記条件に違反していないと判定された場合には該クライアントに対して前記データアップロードを行うための認証情報の返却を行い、一方、前記条件に違反していると判定された場合には前記認証情報の返却を行わず、さらに該クライアントの情報が一度、所定の通知先に通知されている場合には、前記通知を行わない制御を行うステップと、
    を有することを特徴とするアップロード管理システムの制御方法。
12. コンピュータを、請求項１乃至１０のいずれか１項に記載の手段として機能させるためのプログラム。

Images