JP6579898B2

JP6579898B2 - 情報処理システム、情報処理装置の制御方法、およびプログラム

Info

Publication number: JP6579898B2
Application number: JP2015201408A
Authority: JP
Inventors: 内田　貴之; 貴之内田
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2015-10-09
Filing date: 2015-10-09
Publication date: 2019-09-25
Anticipated expiration: 2035-10-09
Also published as: JP2017073081A

Description

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

クラウドサーバ上で業務データの管理や各種処理を行う情報処理システムの形態が普及し始めている。このようなシステムでは、ファイルアップロードに関して次のような方法が考えられる。ユーザは、クライアントコンピュータのブラウザからインターネットを介してクラウドサーバのＷｅｂページにアクセスする。ユーザは、クライアントコンピュータに保存されているファイルを選択し、Ｗｅｂページから当該ファイルのアップロードリスエストを行う。クラウドサーバは、アップロードリクエストを受付けると、ファイルをアップロードするためのＵＲＬを生成し、クライアントコンピュータに返却する。クライアントコンピュータは、返却されたＵＲＬに対してファイルをアップロードする。ファイルのアップロードが完了した後、クライアントコンピュータは、クラウドサーバにアップロードが完了したことを通知する。

特許文献１は、サーバが受信したファイルメタデータ群にハッシュ関数を適用することに基づいて、実行可能ファイルを識別するためのハッシュ識別子を算出するサーバを開示している。

特表２０１４−５３１０９１号公報

上述したようなシステムでは、クライアントコンピュータのブラウザは、ファイルをアップロードして登録を完了するために、次の２回のＨＴＴＰリクエスト（リクエスト）をサーバに送信する。すなわち、ファイルをアップロードするためのリクエスト、およびアップロードが完了したことを通知するリクエストである。

サーバに対してリクエストを複数回送信する場合、それらリクエストが一連の処理であることを識別するためにＨＴＴＰセッションを使用することが考えられる。負荷分散装置を介してサーバが複数台接続されている場合であっても、リクエスト情報をサーバのＨＴＴＰセッションに保持し、一連のリクエストを同一のサーバに振り分けることができる。サーバは、受付けたリクエストとセッションに保持した情報とを比較し、リクエストの妥当性を検証する。

しかしながら、ＨＴＴＰセッションを使用する方法は、サーバが現在の状態を保持する（ステートフル）ため、そのサーバがダウンした場合にサービスを継続することができない。ＨＴＴＰセッションを複数のサーバでレプリケーション（複製）する方法もあるが、本質的には状態を保持するサーバに依存している。

また、同一のファイルに対して複数のユーザが同時に更新を試行した場合に、データの不整合が発生することがある。これを防ぐため、一人のユーザが更新処理を開始した時点でサーバ上のデータベースをロックし、更新処理が完了した時点でロックを解除することが行われている。しかしながら、データベースをロックする手法は、処理を複雑にしてしまう。また、サーバ台数を増やしてスケールアウトを行う場合に、データベースのロックがボトルネックになってしまう。

本発明は、サーバに現在の処理状態を保持させることなく、簡易な方法で不整合を抑制しつつファイルをアップロードすることを可能にする情報処理システムの提供を目的とする。

本発明の一実施形態の情報処理システムは、アップロード対象のファイルの属性情報を含むアップロードリクエストをアップロード要求元から受付ける第１の受付手段と、前記アップロードリクエストに含まれるファイルの属性情報に基づき第１の署名情報を生成する第１の生成手段と、前記アップロード要求元に対して、アップロード先ＵＲＬと前記第１の署名情報とを送信する送信手段と、前記アップロード要求元が前記アップロード先ＵＲＬを用いて前記ファイルのアップロードを実行した後に、前記ファイルの属性情報と前記第１の署名情報とを含むアップロード完了通知を前記アップロード要求元から受付ける第２の受付手段と、前記アップロード完了通知に含まれるファイルの属性情報に基づき第２の署名情報を生成する第２の生成手段と、前記生成された第２の署名情報と、前記アップロード完了通知に含まれる前記第１の署名情報とが一致するか否かを判定する第１の判定手段と、前記第１の判定手段で前記第１の署名情報と前記第２の署名情報とが一致したと判定した場合に、前記ファイルの属性情報を登録する登録手段と、前記第１の判定手段で前記第１の署名情報と前記第２の署名情報とが一致しないと判定した場合に、エラーを通知する通知手段と、を備える。

本発明の情報処理システムによれば、サーバに現在の処理状態を保持させることなく、簡易な方法で不整合を抑制しつつファイルをアップロードすることを可能にする。

本発明の一実施形態に係る情報処理システムの構成を示す図である。情報処理装置のハードウェア構成を示す図である。情報処理システムのソフトウェア構成を示す図である。ファイル属性情報のデータテーブルの一例を示す図である。文書管理サーバがリクエストを受付けた際の処理を示す図である。アップロードの完了通知を受付けた際の処理を示す図である。

以下、本発明を実施するための形態について図面などを参照して説明する。
（第１実施形態）
図１は、本実施形態に係る情報処理システムの構成を示すブロック図である。
本実施形態に係る情報処理システムは、クライアント装置１０１と、文書管理サーバ１０２と、ストレージサーバ１０３と、データベースサーバ１０４とを含み、各構成要素は、インターネットを介してネットワーク１００により通信可能に接続されている。クライアント装置１０１は、文書管理サーバ１０２およびストレージサーバ１０３に対してリクエストを発行する。

文書管理サーバ１０２は、クライアント装置１０１からのリクエストに応じて、ファイル属性の表示や、ファイルの登録、更新または削除等を行う。また、文書管理サーバ１０２は、クライアント装置１０１からストレージサーバ１０３にアクセス可能なＵＲＬを生成する。文書管理サーバ１０２は、負荷分散装置を介して複数台接続されていることを想定している。ストレージサーバ１０３は、ファイルの保存と管理を行い、クライアント装置１０１や文書管理サーバ１０２からのファイルアップロード／ダウンロードのリクエストを受付ける。データベースサーバ１０４は、ストレージサーバ１０３に保存されたファイルの各種属性に関する情報を保持する。

なお、本実施形態では、文書管理サーバ１０２〜データベースサーバ１０４の各サーバは、複数台のサーバで冗長化されたクラウドサービスとしてそれぞれ異なるドメインにインターネット上に公開される。ただし、これに限定することなく、例えば、それぞれ１台の構成であってもよい。

ネットワーク１００は、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれかであってよい。また、これらの組み合わせにより実現される、いわゆる通信ネットワークであってよい。また、ネットワーク１００は、データの送受信が可能であればよく、各サーバ間および各サーバとクライアント装置間の通信手段が異なっていてもよい。

図２は、クライアント装置１０１、文書管理サーバ１０２、ストレージサーバ１０３、データベースサーバ１０４のいずれかとして利用可能な情報処理装置のハードウェア構成を示すブロック図である。
ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）２０１は、内部バスで接続される各デバイス（ＲＯＭ、ＲＡＭなど）を直接または間接的に制御し、本実施形態に係る処理を実現するためのプログラムを実行する。ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）２０２は、ＢＩＯＳを格納している。

ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）２０３は、ＣＰＵ２０１のワーク領域として利用され、本実施形態に係る処理を実現するためのソフトウェアモジュールをロードするための一時記憶として利用される直接記憶装置である。ＨＤＤ２０４は、基本ソフトウェアであるＯＳやソフトウェアモジュールが記憶されているＨＤＤ（ハードディスクドライブ）、またはＳＳＤ（ソリッドステートドライブ）などの間接記憶装置である。入力装置２０５は、不図示のキーボードやポインティングデバイスなどの入力手段である。出力装置２０６は、ディスプレイなどの出力手段である。Ｉ／Ｆ２０７は、ネットワーク１００に接続するためのインターフェースである。

各装置（サーバ）の起動後、ＣＰＵ２０１によりＢＩＯＳが実行され、ＯＳがＨＤＤ２０４からＲＡＭ２０３に実行可能にロードされる。そして、ＣＰＵ２０１は、ＯＳの動作に従って後述する各種ソフトウェアモジュールをＨＤＤ２０４からＲＡＭ２０３に、随時、実行可能にロードする。各種ソフトウェアモジュールは、上記各構成部品の協調により、ＣＰＵ２０１によって実行されて動作する。また、Ｉ／Ｆ２０７は、ネットワーク１００に接続されており、ＯＳの動作に従ってＣＰＵ２０１により制御され、上述した通信手段による通信を実現している。

図３は、本実施形態に係る情報処理システムのソフトウェア構成を示す図である。
なお各ソフトウェアモジュールは、図２で示したＨＤＤ２０４に記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。クライアント装置１０１は、ユーザインタフェースアプリケーションとしてＷｅｂブラウザ３０１を備えている。

文書管理サーバ１０２は、Ｗｅｂサーバ３０２と、文書管理部３０３と、一時ＵＲＬ生成部３０４とを備える。クライアント装置１０１は、Ｗｅｂブラウザ３０１を介してＷｅｂサーバ３０２にアクセスすることができる。文書管理サーバのＷｅｂサーバ３０２は、Ｗｅｂアプリケーションの機能を有し、Ｗｅｂブラウザ３０１からのＨＴＴＰリクエスト（リクエスト）に対してユーザインタフェース情報を返答する。

Ｗｅｂブラウザ３０１は、Ｗｅｂサーバ３０２から得られたユーザインタフェース情報をレンダリングし表示する。表示されたユーザインタフェース情報には、例えば、後述するストレージサーバ１０３が管理するファイルの一覧や、後述するデータベースサーバ１０４が管理する各ファイルの属性を表示するためのインターフェース等が含まれている。また、例えば、後述するファイルアップロードの成功時に遷移するＷｅｂページ等も含まれている。

文書管理部３０３は、クライアント装置１０１がストレージサーバ１０３にアップロードしたファイルの管理や、データベースサーバ１０４に対してファイル属性の登録や更新を行う。また、後述するように、文書管理部３０３は、クライアント装置から指定されたファイルの属性情報と、データベースサーバから取得したファイルのバージョン情報とに基づいて、署名情報を生成する機能も有する。

一時ＵＲＬ生成部３０４は、Ｗｅｂサーバ３０２が受付けたファイルアップロードリクエストやファイルダウンロードリクエストに応じて、ストレージサーバ１０３にアクセス可能な一時ＵＲＬの発行を行う。一時ＵＲＬとは、所定の期間（例えば１時間）のみ有効で且つ該所定の期間が過ぎるとアクセス不可となる一時的なＵＲＬのことである。一時ＵＲＬには、ファイルの保存先となるストレージサーバ１０３のアドレスに関する情報、ならびに、該所定の期間に基づいてアクセス制御するための制御情報（引数）などが含まれる。

ストレージサーバ１０３は、Ｗｅｂサーバ３０５と、アクセス制御部３０６と、ストレージ管理部３０７と、ストレージ３０８とを備える。Ｗｅｂサーバ３０５は、Ｗｅｂアプリケーションの機能を有し、クライアント装置１０１は、Ｗｅｂブラウザ３０１を介してＷｅｂサーバ３０５にアクセスすることができる。アクセス制御部３０６は、Ｗｅｂブラウザ３０１から指定された一時ＵＲＬに含まれる制御情報に基づいて、Ｗｅｂブラウザ３０１からのリクエストを実行許可するか否かを判定する。

アクセス制御部３０６が実行許可したリクエストは、ストレージ管理部３０７へ渡され、実行拒否と判定したリクエストは、エラーにする。ストレージ管理部３０７は、ファイル情報を管理し、アップロード／ダウンロードリクエストされたファイルの入出力を行う。ストレージ３０８は、ストレージサーバ１０３がＷｅｂブラウザ３０１から受信したファイルを格納する。また、ストレージ３０８が該ファイルの格納に成功した場合、Ｗｅｂサーバ３０５は、Ｗｅｂブラウザ３０１にファイルが格納されたことを通知する。この通知を受けると、Ｗｅｂブラウザ３０１は、文書管理サーバ１０２に対してアップロード完了の通知を送信する。

データベースサーバ１０４は、Ｗｅｂサーバ３０９と、アクセス制御部３１０と、ストレージ３１１とを備える。ストレージ３１１には、文書管理サーバ１０２で管理しているファイルに関する属性などの情報が格納されており、キーバリュー形式で属性情報を管理する。Ｗｅｂサーバ３０９は、文書管理サーバ１０２の文書管理部３０３からのリクエストに対してユーザインタフェース情報を返答する。ユーザインタフェース情報には、例えば、指定されたキーに対するバリュー情報の返却や、バリュー情報の検索結果のインターフェース等が含まれている。

図４は、文書管理サーバ１０２がデータベースサーバ１０４に保存するファイル属性情報４００のデータテーブルの一例を示す図である。

ファイル属性情報４００は、ファイル登録時に文書管理部３０３がレコードを生成し、データベースサーバ１０４に保存される。また、ユーザは、ファイルに対して固有の属性（例えば、フレンドリー名やタグ、コメント）を付与することが可能である。ユーザは、クラウドサーバコンピュータのＷｅｂページの画面で、各種属性を指定してファイルを検索することができる。

ファイルＩＤ４０１は、ファイルを一意に識別するＩＤ（識別情報）である。本実施形態では、ユーザがアップロードするファイルのファイル名をファイルＩＤとしているが、これに限定することなく、例えば、文書管理サーバ１０２が独自のファイルＩＤを発行してもよい。フレンドリー名４０２およびタグ４０３は、ユーザがＷｅｂブラウザ３０１からファイルの管理や検索を容易にするためユーザが任意に指定可能な属性である。

ファイルバージョン４０４は、ファイルのバージョン情報を表す属性であり、ファイルを更新するたびに文書管理サーバ１０２がファイルバージョン４０４の値を更新する。ファイルＵＲＬ４０５は、ファイルが保存された場所を示すアドレスであり、ストレージサーバ１０３のＵＲＬから構成される。ファイルＵＲＬ４０５は、文書管理サーバ１０２がファイルアップロードリクエスト受信時に、ストレージサーバ１０３でファイルを一意に特定できるように、ユニークな文字列で構成されるＵＲＬパスおよびファイルＩＤ４０１等を含めて生成される。

次に、本実施形態における情報処理システムのファイルアップロードに係る処理について、図５及び６を用いて説明する。
図５は、文書管理サーバ１０２がファイルの登録またはファイル属性の更新に関するリクエストを受付けた際の処理を示すフローチャートである。なお、ユーザは、不図示のログイン画面にて文書管理サーバ１０２にログイン済みであり、クライアント装置１０１のＷｅｂブラウザ３０１には文書管理サーバ１０２のＷｅｂサーバ３０２から返答されたファイル登録／更新画面が表示されているものとする。図５の処理は、ユーザによりクライアント装置１０１のＷｅｂブラウザ３０１に表示された不図示のファイル登録／更新画面で登録または更新操作が行われることにより開始される。

文書管理サーバ１０２は、リクエストを受信すると、ステップＳ５０１において、当該リクエストがファイルのアップロードリクエストであるか、ファイル属性の更新リクエストであるかを判定する。ステップＳ５０１でファイルのアップロードリクエストであると判定した場合、処理は、ステップＳ５０２に進む。なお、アップロードリクエストには、アップロード対象のファイルに関するファイル属性（例えば、ファイル名や、フレンドリー名、タグ、コメントなどの属性情報）が含まれる。また、アップロードリクエストには、次の２種類がある。１つは、データベースサーバに既に保存されているバージョンのファイルを新たなバージョンのファイルで更新（または追加）する際のアップロードリクエストである。また他の１つは、最初のバージョンのファイルとしてアップロードする際のアップロードリクエストである。

ステップＳ５０２において、文書管理サーバ１０２は、文書管理部３０３を介して、リクエストされた（アップロード要求された）ファイルのファイルバージョン４０４の情報を取得する。具体的には、文書管理サーバ１０２は、文書管理部３０３を介して、リクエストされたファイルのファイルＩＤをキーに指定し、データベースサーバ１０４から当該指定されたファイルのファイルバージョン４０４の情報を取得する。

次に、ステップＳ５０３において、文書管理サーバ１０２は、受信したアップロードリクエストのパラメータに含まれるファイル属性と、ステップＳ５０２で取得したファイルバージョン４０４とに基づいて、署名情報（第１の署名情報）を生成する。署名情報とは、次の情報を連結した文字列をＭＤ５等でハッシュ化した文字列のことである。連結する文字列は、ファイルＩＤ（「ｉｄ＝＜ファイルＩＤ＞」）、フレンドリー名（「ｎａｍｅ＝＜リクエストで指定されたフレンドリー名＞」）、タグ（「ｔａｇ＝＜リクエストで指定されたタグ文字列＞」）、ファイルバージョン（「ｖ＝＜前記取得したファイルバージョン＞」）である。

なお、文書管理サーバ１０２が受信したリクエストが、ファイルの新規登録のリクエスト（最初のバージョンのファイルのアップロードリクエスト）である場合、Ｓ５０２で取得されるファイルバージョンは空文字列とする。ただし、これに限定することなく、空文字列以外としてもよい。また、文字列をハッシュ化する際にソルト文字列を追加してもよい。例えば、ユーザＩＤをソルト文字列として使用してもよい。

ステップＳ５０４において、文書管理サーバ１０２の一時ＵＲＬ生成部３０４は、ファイルをストレージサーバにアップロードするための一時ＵＲＬ（アップロード先ＵＲＬ）を生成する。その後、ステップＳ５０５において、文書管理サーバ１０２は、Ｓ５０３で生成した署名情報と、Ｓ５０４で生成した一時ＵＲＬとを、アップロード要求元であるＷｅｂブラウザ３０１に返却する。

クライアント装置のＷｅｂブラウザ３０１は、当該返却された署名情報を保持しておく。さらに、クライアント装置のＷｅｂブラウザ３０１は、当該返却された一時ＵＲＬに基づき、ＪａｖａＳｃｒｉｐｔ（登録商標）等を用いてストレージサーバ１０３にファイルをアップロードする。ストレージサーバ１０３は、当該アップロードされたファイルをストレージ３０８に格納すると、Ｗｅｂブラウザ３０１にファイルを格納したことを通知する。

Ｗｅｂブラウザ３０１は、このファイル格納通知を受けると、文書管理サーバ１０２に対してアップロード完了通知を送信する。このアップロード完了通知には、Ｗｅｂブラウザ３０１で保持しておいた署名情報と、アップロード対象のファイルに関するファイル属性（アップロードリクエストに含まれていたファイル属性情報と同じもの）とが含まれる。

一方、ステップＳ５０１で、ファイル属性の更新に関するリクエストを受信したと判定した場合、処理は、ステップＳ５０６に進む。ステップＳ５０６において、文書管理サーバ１０２は、文書管理部３０３を介して、リクエストされたファイルのファイルＩＤをキーに指定し、リクエストで指定されたファイルの属性情報をデータベースサーバ１０４に保存する。なお、このときファイルバージョン４０４は更新しない。以上の処理により、文書管理サーバ１０２は、ファイル登録またはファイル属性更新のリクエストを受付けた際の処理を実行する。

図６は、文書管理サーバ１０２がクライアント装置からファイルアップロードの完了通知を受付けた際の処理を示すフローチャートである。
図６の処理は、クライアント装置１０１が、ストレージサーバにファイルをアップロードした後、文書管理サーバ１０２に対してアップロード完了通知を送信することを契機として開始される。上述したように、アップロード完了通知には、Ｓ５０５で返却されてＷｅｂブラウザで保持しておいた署名情報と、アップロード対象のファイルに関するファイル属性の情報とが含まれる。

文書管理サーバ１０２は、アップロード完了通知を受信すると、ステップＳ６０１において、当該アップロード完了通知に含まれるパラメータの中に署名情報を表すパラメータ”ｓｉｇｎ”が含まれているか否かを判定する。ステップＳ６０１でパラメータ”ｓｉｇｎ”を含む（すなわち、アップロード完了通知に署名情報が含まれている）と判定した場合、処理は、ステップＳ６０２に進む。ステップＳ６０２において、文書管理サーバ１０２は、リクエスト（アップロード完了を通知された）されたファイルのファイルバージョン４０４を取得する。具体的には、文書管理サーバ１０２の文書管理部３０３を介して、リクエストされたファイルのファイルＩＤをキーに指定し、データベースサーバ１０４から当該ファイルのファイルバージョン４０４を取得する。

次に、ステップＳ６０３において、文書管理サーバ１０２は、アップロード完了通知に含まれるファイル属性の情報と、ステップＳ６０２で取得したファイルバージョン４０４とに基づいて、署名情報（第２の署名情報）を生成する。ステップＳ６０３での署名情報の生成に用いるアルゴリズムは、図５のステップＳ５０３の処理と同様のアルゴリズムを用いる。

ステップＳ６０４において、文書管理サーバ１０２は、アップロード完了通知に含まれていたパラメータ”ｓｉｇｎ”の値（第１の署名情報）と、ステップＳ６０３で生成した署名情報（第２の署名情報）とを比較する。ステップＳ６０５において、パラメータ”ｓｉｇｎ”の値とステップＳ６０３で生成した署名情報とが一致すると判定した場合、処理はステップＳ６０６に進む。

ステップＳ６０６において、文書管理サーバ１０２は、文書管理部３０３を介して、リクエストされたファイルのファイルＩＤをキーに指定し、次の情報をデータベースサーバ１０４に保存要求する。すなわち、アップロード完了通知で指定されたファイル属性およびステップＳ６０２で取得したファイルバージョン４０４の値を変更（更新）した値をデータベースサーバ１０４に保存要求する。

このとき、文書管理サーバ１０２は、次の条件を指定して、データベースサーバ１０４に保存を要求する。この指定される条件とは、データベースサーバ１０４上のファイルバージョン４０４の値（現在のバージョン）が、ステップＳ６０２で取得したファイルバージョン４０４の値と一致していることである。そして、データベースサーバ１０４では、当該保存要求で指定された条件を満たしていると判断した場合に、当該指定されたファイル属性の情報の保存、およびバージョン値の変更とを実際に実行する。

ステップＳ６０７において、文書管理サーバ１０２の文書管理部３０３は、保存要求が成功したか否かを判定する。ステップＳ６０７で保存要求が成功したと判定した場合、処理はステップＳ６０８に進む。ステップＳ６０８において、文書管理サーバ１０２のＷｅｂサーバ３０２は、ファイル登録または更新が成功したことをＷｅｂブラウザ３０１にレスポンスとして返す。

一方、ステップＳ６０７で保存要求が成功しなかった場合、処理はステップＳ６０９に進む。例えば、データベースサーバ１０４上のファイルバージョン４０４の値がステップＳ６０２で取得した値と一致しなかったためにファイル属性の保存が実行されず、データベースサーバ１０４からエラーが返されると、保存要求が成功しなかったと判断される。このとき、文書管理サーバ１０２のＷｅｂサーバ３０２は、Ｓ６０９において、ファイルが別のユーザによって登録または更新されたことをＷｅｂブラウザ３０１にエラーレスポンスとして返す。

一方、ステップＳ６０５で、アップロード完了通知に含まれていたパラメータ”ｓｉｇｎ”の値（第１の署名情報）とステップＳ６０３で生成した第２の署名情報とが一致しないと判定された場合、処理はステップＳ６０９に進む。この場合、ステップＳ６０９において、文書管理サーバ１０２のＷｅｂサーバ３０２は、不正なリクエストであることをＷｅｂブラウザ３０１にエラーレスポンスとして返す。また、ステップＳ６０１でアップロード完了通知にパラメータ”ｓｉｇｎ”が含まれていないと判定した場合も、処理はステップＳ６０９に進む。この場合も、ステップＳ６０９において、文書管理サーバ１０２のＷｅｂサーバ３０２は、不正なリクエストであることをＷｅｂブラウザ３０１にエラーレスポンスとして返す。

以上の処理により、文書管理サーバ１０２は、ファイルアップロードの完了通知を受付けた際の処理を実行する。なお、本実施形態では、ステップＳ６０１において、送信されたアップロード完了通知に含まれるパラメータの中に署名情報が含まれないと判定した場合にエラーを返すようにしているが、これに限定するものではない。例えば、送信されたアップロード完了通知のパラメータに署名情報が含まれない場合には、属性更新のリクエストとみなして処理を実行してもよい。

以上のように、本実施形態によれば、文書管理サーバは、アップロードリクエストを受信した際に指定されたファイル属性情報とデータベースサーバに保存されているバージョン情報とに基づいて第１の署名情報を生成する。そして、ファイル保存に用いる一時ＵＲＬとともに該第１の署名情報をクライアント装置に返却する。クライアント装置は、当該返却された一時ＵＲＬを用いてファイルをアップロードした後、該第１の署名情報とファイル属性情報とを含むアップロード完了通知を文書管理サーバに送信する。

文書管理サーバは、アップロード完了通知に含まれるファイル属性情報とデータベースサーバに保存されているバージョン情報とに基づいて第２の署名情報を生成する。そして、当該生成した第２の署名情報とアップロード完了通知に含まれる第１の署名情報とを比較することで、正しいリクエストかどうか（不整合が発生しないかどうか）を判定することができる。

したがって、サーバに現在の処理状態を保持させることなく、簡易な方法で不整合を抑制しつつファイルをアップロードすることを可能にする。例えば、負荷分散装置を介してサーバが複数台接続されている場合に、いずれのサーバにおいてもクライアントコンピュータのリクエストの妥当性を簡易な方法で検証することが可能となる。

このため、サーバの状態に依存せず、一部のサーバがダウンした場合であってもサービスを継続することができる。また、複数のユーザが同時に同一ファイルをアップロードした場合であっても、データベースのロック等の複雑な仕組みを用いずに不整合を抑制できる。このため、サーバの台数を増やしてスケールアウトを実現した場合も、データベースがボトルネックの原因となることを減らすことが可能となる。

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

以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。

１０２文書管理サーバ
３０２Ｗｅｂサーバ
３０３文書管理部

Claims

アップロード対象のファイルの属性情報を含むアップロードリクエストをアップロード要求元から受付ける第１の受付手段と、
前記アップロードリクエストに含まれるファイルの属性情報に基づき第１の署名情報を生成する第１の生成手段と、
前記アップロード要求元に対して、アップロード先ＵＲＬと前記第１の署名情報とを送信する送信手段と、
前記アップロード要求元が前記アップロード先ＵＲＬを用いて前記ファイルのアップロードを実行した後に、前記ファイルの属性情報と前記第１の署名情報とを含むアップロード完了通知を前記アップロード要求元から受付ける第２の受付手段と、
前記アップロード完了通知に含まれるファイルの属性情報に基づき第２の署名情報を生成する第２の生成手段と、
前記生成された第２の署名情報と、前記アップロード完了通知に含まれる前記第１の署名情報とが一致するか否かを判定する第１の判定手段と、
前記第１の判定手段で前記第１の署名情報と前記第２の署名情報とが一致したと判定した場合に、前記ファイルの属性情報を登録する登録手段と、
前記第１の判定手段で前記第１の署名情報と前記第２の署名情報とが一致しないと判定した場合に、エラーを通知する通知手段と、
を備える、ことを特徴とする情報処理システム。
前記登録手段は、前記第１の署名情報と前記第２の署名情報とが一致したと判定した場合に、前記ファイルのバージョン情報を更新して前記ファイルの属性情報をデータベースに登録することを特徴とする請求項１に記載の情報処理システム。
前記第１の生成手段は、前記アップロードリクエストに含まれるファイルの属性情報と、データベースから取得されるバージョン情報とに基づいて、前記第１の署名情報を生成し、
前記第２の生成手段は、前記アップロード完了通知に含まれるファイルの属性情報と、前記データベースから取得されるバージョン情報とに基づいて、前記第２の署名情報を生成する、ことを特徴とする請求項１または２に記載の情報処理システム。
前記ファイルの属性情報は、ユーザが当該ファイルに対して固有に付与する情報を含む、ことを特徴とする請求項１ないし３のいずれか１項に記載の情報処理システム。
前記第１の生成手段は、前記アップロードリクエストに含まれるファイルの属性情報に基づく文字列をハッシュ化することにより、前記第１の署名情報を生成し、
前記第２の生成手段は、前記アップロード完了通知に含まれるファイルの属性情報に基づく文字列をハッシュ化することにより、前記第２の署名情報を生成する、ことを特徴とする請求項１に記載の情報処理システム。
アップロード対象のファイルの属性情報を含むアップロードリクエストをアップロード要求元から受付ける第１の受付工程と、
前記アップロードリクエストに含まれるファイルの属性情報に基づき第１の署名情報を生成する第１の生成工程と、
前記アップロード要求元に対して、アップロード先ＵＲＬと前記第１の署名情報とを送信する送信工程と、
前記アップロード要求元が前記アップロード先ＵＲＬを用いて前記ファイルのアップロードを実行した後に、前記ファイルの属性情報と前記第１の署名情報とを含むアップロード完了通知を前記アップロード要求元から受付ける第２の受付工程と、
前記アップロード完了通知に含まれるファイルの属性情報に基づき第２の署名情報を生成する第２の生成工程と、
前記生成された第２の署名情報と、前記アップロード完了通知に含まれる前記第１の署名情報とが一致するか否かを判定する第１の判定工程と、
前記第１の判定工程で前記第１の署名情報と前記第２の署名情報とが一致したと判定した場合に、前記ファイルの属性情報を登録する登録工程と、
を有する、ことを特徴とする情報処理装置の制御方法。
請求項１乃至５のいずれか１項に記載の情報処理システムが備える各手段としてコンピュータを機能させるためのプログラム。