(57)【要約】【課題】外部装置に記憶されている文書に関する処理を外部サーバに実行させるために内部装置が持っている情報だけでなく外部ネットワーク上の装置が持っている情報が必要な場合でも、その処理が実現できるようにする。【解決手段】処理装置１１０は、外部アプリサーバ４００が提供する外部アプリを利用する旨の要求をユーザの閲覧端末１０４から受け取る。その要求は組織内管理システム１５０を経由して外部アプリＧＷＳ３２０に渡される。外部アプリＧＷＳ３２０は、外部アプリサーバ４００が処理のために必要とする情報を、組織内ネットワーク上の処理装置１１０や組織内管理システム１５０と、外部ネットワーク上の管理システム２００及び外部アプリサーバ４００から取得し、外部アプリサーバ４００に渡す。【選択図】図３
2020160503.tif 000002
【特許請求の範囲】
【請求項１】
内部ネットワークに接続された１以上の内部装置であって、前記内部ネットワークはファイアウォールを介して外部ネットワークに接続されている、内部装置と、
前記内部ネットワーク及び前記外部ネットワークと通信可能な仲介装置と、
を含み、
前記内部装置は、
１以上の文書と、それら１以上の文書の各々のメタデータと、を記憶する記憶手段と、
前記記憶手段に記憶されている前記文書に関して、ユーザから、前記外部ネットワーク上の外部サーバによる処理の要求を受け付け、受け付けた前記要求を前記仲介装置に向けて送信する要求受付手段と、
を含み、
前記仲介装置は、
前記要求を受信し、前記要求を実行するために前記外部サーバが必要とする複数のデータ項目のうち、少なくとも１つのデータ項目は前記外部ネットワークから取得し、別の少なくとも１つのデータ項目は前記要求を送信した前記内部装置から前記内部ネットワーク経由で取得し、取得した前記複数のデータ項目を含む要求データを前記外部サーバに送信する要求送信手段、
を含む、情報処理システム。
【請求項２】
前記外部ネットワークに接続された外部装置を更に含み、
前記内部装置は、前記文書に対する閲覧権限の付与先である付与先ユーザの指定を受け付け、指定された付与先ユーザを示す権限ユーザ情報を、前記記憶手段内の前記文書の前記メタデータに組み込むと共に、前記メタデータを前記外部装置に登録し、前記記憶手段に記憶された前記文書を、前記付与先ユーザが復号できるよう暗号化した状態で前記付与先ユーザの閲覧端末に提供し、
前記外部装置は、前記内部装置から登録された前記メタデータを記憶し、
前記閲覧端末は、ユーザから当該閲覧端末内にある前記文書の閲覧が要求された場合に、前記内部装置又は前記外部装置のうちのアクセス可能な装置に記憶されている、前記文書の前記メタデータに含まれる前記権限ユーザ情報に、当該ユーザが前記付与先ユーザとして含まれているかどうかを調べ、含まれていれば前記文書を復号して表示し、含まれていなければ、前記文書の表示を禁止し、
前記複数のデータ項目には、前記処理の対象である前記文書の文書識別情報が含まれ、
前記仲介装置は、
前記要求データを受け取った前記外部サーバから、前記文書識別情報を含む文書要求を受け取った場合、前記文書識別情報に対応する前記文書を記憶する前記内部装置に対して、当該文書を前記外部サーバに提供する旨の提供指示を送信し、前記提供指示に応じて前記内部装置から提供される、暗号化した状態の前記文書を前記外部サーバに送信する処理を行うサーバ要求処理手段と、
を更に含み、
前記内部装置は、
受信した前記提供指示の対象である前記文書を、前記外部サーバが復号できるが前記仲介装置は復号できないよう暗号化した状態で、前記仲介装置に提供するデータ提供手段と、
を含む、請求項１に記載の情報処理システム。
【請求項３】
前記複数のデータ項目には、前記処理の対象である前記メタデータ又はその一部を特定するメタデータ特定情報が含まれ、
前記仲介装置の前記サーバ要求処理手段は、前記要求データを受け取った前記外部サーバから、前記メタデータ特定情報を含むメタデータ要求を受け取った場合、前記メタデータ特定情報に対応する前記メタデータ又はその一部を前記外部装置又は前記内部装置から取得し、取得した前記メタデータ又はその一部を前記外部サーバが復号可能な暗号化メタデータに変換して前記外部サーバに送信する、請求項２に記載の情報処理システム。
【請求項４】
前記複数のデータ項目のうちの１つは、前記仲介装置のアドレス情報であって前記外部ネットワーク向けのアドレス情報である、請求項１〜３のいずれか１項に記載の情報処理システム。
【請求項５】
前記仲介装置は、
前記外部サーバから送られてきた前記処理の結果を示す処理結果データを受信し、受信した前記処理結果データを、前記処理に対応する前記要求を送信した前記内部装置に前記内部ネットワーク経由で送信する処理結果送信手段、
を更に含む請求項１〜４のいずれか１項に記載の情報処理システム。
【請求項６】
前記文書の前記メタデータには複数の要素が含まれ、
前記複数のデータ項目には、前記文書の文書識別情報と、当該文書の前記メタデータに含まれる前記複数の要素のうち、前記処理の結果である処理結果データを書き込むべき要素を示す要素識別情報が含まれ、
前記仲介装置は、前記外部サーバから前記文書識別情報、前記要素識別情報及び前記要求データに対応する処理結果データを受け取った場合に、当該処理結果データを、前記内部装置の前記記憶手段に記憶される前記文書識別情報に対応する前記文書の前記メタデータの要素群のうち、前記要素識別情報に対応する要素に対して書き込まれるように制御する、ことを特徴とする請求項１〜５のいずれか１項に記載の情報処理システム。
【請求項７】
前記仲介装置は、ユーザからの前記要求を受け取った場合に、前記内部ネットワーク上の所定の装置から、前記ユーザが前記仲介装置の利用権限を持つか否かを示す情報を取得し、取得した情報から前記ユーザが前記利用権限を持たないことが分かった場合、前記ユーザからの前記要求を拒否する制御を行う、ことを特徴とする請求項１〜６のいずれか１項に記載の情報処理システム。
【請求項８】
前記仲介装置は、前記外部サーバが一時的に生成する宛先データであって、前記要求データの宛先を示す宛先データを、前記外部ネットワーク経由で前記外部サーバから取得し、
前記要求送信手段は、前記宛先データを前記複数のデータ項目の１つとして含む前記要求データを前記外部サーバに送信する、
ことを特徴とする請求項１〜７のいずれか１項に記載の情報処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システムに関する。
【背景技術】
【０００２】
出願人は、管理装置（又は管理システム）と複数の処理装置とからなる２層構造を含むドキュメント管理システムを提案している（特許文献１〜４参照）。処理装置は、主として、本システムに登録されるドキュメントを暗号化等により保護する処理と、この処理により得られた保護済みドキュメントを送信先のユーザに配信する処理とを担う。管理装置は、処理装置群を管理すると共に、それら処理装置が生成した保護済みドキュメントのメタデータを保管し、保管したメタデータの提供を行う。ユーザは、それぞれ自分のホームとする処理装置に登録される、例えば、処理装置は、企業の部署等の単位ごとに設置され、その単位に属するユーザはその単位に設置された処理装置に登録される。
【０００３】
ユーザがシステムに登録したドキュメントの保護済みドキュメントは、そのユーザがホームとする処理装置に保存される。そして、そのユーザが指定した送信先のユーザであって、その処理装置自身、又は、その処理装置に対して安全であるものとして登録された他の処理装置、を介してそのドキュメントの配信を要求したユーザの端末に送信される。保護済みドキュメントは、それが登録された処理装置と、送信先に指定されたユーザの端末には保存されるが、管理装置や他の処理装置、他の端末には保存されない。
【０００４】
また、保護済みドキュメントのメタデータには、その保護済みドキュメントに対する閲覧権限等の権限を持つユーザの情報が保持される。この権限の情報は、その保護済みドキュメントをシステムに登録したユーザ（登録者）等の権限を有する者が処理装置を介してシステムに登録したり、変更したりする。端末は、その端末を操作しているユーザから、その端末内の保護済みドキュメントの閲覧指示を受けた場合、その保護済みドキュメントの識別情報に対応する最新のメタデータを近傍の処理装置を介して取得し、そのユーザが現在その保護済みドキュメントの閲覧権限を持つのかを、その最新のメタデータに基づき判定する。閲覧権限を持つと判定した場合は、端末はその保護済みドキュメントをメタデータ中の鍵情報を用いて復号して表示し、そうでない場合は閲覧不可の旨をユーザに通知する。
【０００５】
以上に説明したように、このシステムは、保護済みドキュメントが、これを登録したユーザのホームの処理装置と、そのユーザが指定した送信先の各ユーザの端末と、にしか保持されないという仕組みにより、保護済みドキュメントが第三者の手に渡りにくくしている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１８−１５６４０９号公報
【特許文献２】特開２０１８−１５６４１０号公報
【特許文献３】特開２０１８−１５６４１１号公報
【特許文献４】特開２０１８−１５６３８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ファイアウォール外の外部ネットワーク上にある外部サーバが、ファイアウォール内の内部ネットワーク上にある内部装置に記憶されている文書に関する処理を実行するサービスがある。そのような処理には、文書に関して内部装置が持っている情報だけでなく、外部ネットワーク上の装置にある情報が必要になる場合がある。
【０００８】
本発明は、内部装置に記憶されている文書に関する処理を外部サーバに実行させるために内部装置が持っている情報だけでなく外部ネットワーク上の装置が持っている情報が必要な場合でも、その処理が実現できる仕組みを提供する。
【課題を解決するための手段】
【０００９】
請求項１に係る発明は、内部ネットワークに接続された１以上の内部装置であって、前記内部ネットワークはファイアウォールを介して外部ネットワークに接続されている、内部装置と、前記内部ネットワーク及び前記外部ネットワークと通信可能な仲介装置と、を含み、前記内部装置は、１以上の文書と、それら１以上の文書の各々のメタデータと、を記憶する記憶手段と、前記記憶手段に記憶されている前記文書に関して、ユーザから、前記外部ネットワーク上の外部サーバによる処理の要求を受け付け、受け付けた前記要求を前記仲介装置に向けて送信する要求受付手段と、を含み、前記仲介装置は、前記要求を受信し、前記要求を実行するために前記外部サーバが必要とする複数のデータ項目のうち、少なくとも１つのデータ項目は前記外部ネットワークから取得し、別の少なくとも１つのデータ項目は前記要求を送信した前記内部装置から前記内部ネットワーク経由で取得し、取得した前記複数のデータ項目を含む要求データを前記外部サーバに送信する要求送信手段、を含む、情報処理システムである。
【００１０】
請求項２に係る発明は、前記外部ネットワークに接続された外部装置を更に含み、前記内部装置は、前記文書に対する閲覧権限の付与先である付与先ユーザの指定を受け付け、指定された付与先ユーザを示す権限ユーザ情報を、前記記憶手段内の前記文書の前記メタデータに組み込むと共に、前記メタデータを前記外部装置に登録し、前記記憶手段に記憶された前記文書を、前記付与先ユーザが復号できるよう暗号化した状態で前記付与先ユーザの閲覧端末に提供し、前記外部装置は、前記内部装置から登録された前記メタデータを記憶し、前記閲覧端末は、ユーザから当該閲覧端末内にある前記文書の閲覧が要求された場合に、前記内部装置又は前記外部装置のうちのアクセス可能な装置に記憶されている、前記文書の前記メタデータに含まれる前記権限ユーザ情報に、当該ユーザが前記付与先ユーザとして含まれているかどうかを調べ、含まれていれば前記文書を復号して表示し、含まれていなければ、前記文書の表示を禁止し、前記複数のデータ項目には、前記処理の対象である前記文書の文書識別情報が含まれ、前記仲介装置は、前記要求データを受け取った前記外部サーバから、前記文書識別情報を含む文書要求を受け取った場合、前記文書識別情報に対応する前記文書を記憶する前記内部装置に対して、当該文書を前記外部サーバに提供する旨の提供指示を送信し、前記提供指示に応じて前記内部装置から提供される、暗号化した状態の前記文書を前記外部サーバに送信する処理を行うサーバ要求処理手段と、を更に含み、前記内部装置は、受信した前記提供指示の対象である前記文書を、前記外部サーバが復号できるが前記仲介装置は復号できないよう暗号化した状態で、前記仲介装置に提供するデータ提供手段と、を含む、請求項１に記載の情報処理システムである。
【００１１】
請求項３に係る発明は、前記複数のデータ項目には、前記処理の対象である前記メタデータ又はその一部を特定するメタデータ特定情報が含まれ、前記仲介装置の前記サーバ要求処理手段は、前記要求データを受け取った前記外部サーバから、前記メタデータ特定情報を含むメタデータ要求を受け取った場合、前記メタデータ特定情報に対応する前記メタデータ又はその一部を前記外部装置又は前記内部装置から取得し、取得した前記メタデータ又はその一部を前記外部サーバが復号可能な暗号化メタデータに変換して前記外部サーバに送信する、請求項２に記載の情報処理システムである。
【００１２】
請求項４に係る発明は、前記複数のデータ項目のうちの１つは、前記仲介装置のアドレス情報であって前記外部ネットワーク向けのアドレス情報である、請求項１〜３のいずれか１項に記載の情報処理システムである。
【００１３】
請求項５に係る発明は、前記仲介装置は、前記外部サーバから送られてきた前記処理の結果を示す処理結果データを受信し、受信した前記処理結果データを、前記処理に対応する前記要求を送信した前記内部装置に前記内部ネットワーク経由で送信する処理結果送信手段、を更に含む請求項１〜４のいずれか１項に記載の情報処理システムである。
【００１４】
請求項６に係る発明は、前記文書の前記メタデータには複数の要素が含まれ、前記複数のデータ項目には、前記文書の文書識別情報と、当該文書の前記メタデータに含まれる前記複数の要素のうち、前記処理の結果である処理結果データを書き込むべき要素を示す要素識別情報が含まれ、前記仲介装置は、前記外部サーバから前記文書識別情報、前記要素識別情報及び前記要求データに対応する処理結果データを受け取った場合に、当該処理結果データを、前記内部装置の前記記憶手段に記憶される前記文書識別情報に対応する前記文書の前記メタデータの要素群のうち、前記要素識別情報に対応する要素に対して書き込まれるように制御する、ことを特徴とする請求項１〜５のいずれか１項に記載の情報処理システムである。
【００１５】
請求項７に係る発明は、前記仲介装置は、ユーザからの前記要求を受け取った場合に、前記内部ネットワーク上の所定の装置から、前記ユーザが前記仲介装置の利用権限を持つか否かを示す情報を取得し、取得した情報から前記ユーザが前記利用権限を持たないことが分かった場合、前記ユーザからの前記要求を拒否する制御を行う、ことを特徴とする請求項１〜６のいずれか１項に記載の情報処理システムである。
【００１６】
請求項８に係る発明は、前記仲介装置は、前記外部サーバが一時的に生成する宛先データであって、前記要求データの宛先を示す宛先データを、前記外部ネットワーク経由で前記外部サーバから取得し、前記要求送信手段は、前記宛先データを前記複数のデータ項目の１つとして含む前記要求データを前記外部サーバに送信する、ことを特徴とする請求項１〜７のいずれか１項に記載の情報処理システムである。
【発明の効果】
【００１７】
請求項１に係る発明によれば、外部装置に記憶されている文書に関する処理を外部サーバに実行させるために内部装置が持っている情報だけでなく外部ネットワーク上の装置が持っている情報が必要な場合でも、その処理が実現できる。
【００１８】
請求項２に係る発明によれば、内部装置が持つ文書の内容が、その内部装置と、その文書に対する処理を実行する外部サーバ以外の装置には開示されないようにすることができる。
【００１９】
請求項３に係る発明によれば、外部装置も記憶しているメタデータについては、内部装置がそれを暗号化する手間を省くことができる。
【００２０】
請求項４に係る発明によれば、外部サーバに対して、外部サーバの処理結果データを仲介装置に返す際の宛先を知らせることができる。
【００２１】
請求項５に係る発明によれば、外部サーバの処理結果データを内部装置に伝達することができる。
【００２２】
請求項６に係る発明によれば、外部サーバの処理結果データがメタデータ中の予め定められた要素に書き込まれるようにすることができる。
【００２３】
請求項７に係る発明によれば、仲介装置の利用権限がないユーザが仲介装置を介して外部サーバを利用することを防止することができる。
【００２４】
請求項８に係る発明によれば、仲介装置が外部サーバの固定的なアドレスに対して要求データを送信する場合と比べて、セキュリティを向上させることができる。
【図面の簡単な説明】
【００２５】
【図１】実施形態の仕組みが適用されるドキュメント管理システムの例を示す図である。
【図２】組織内管理システムを設けたシステム構成の例を示す図である。
【図３】実施形態のドキュメント管理システムの構成を例示する図である。
【図４】処理装置の内部構成を例示する図である。
【図５】外部アプリＧＷＳの内部構成を例示する図である。
【図６】組織内管理システムが管理している外部アプリの管理情報を例示する図である。
【図７】実施形態のシステムにおける外部アプリの利用の流れを例示する図である。
【発明を実施するための形態】
【００２６】
＜実施形態の制御の適用先となるシステムの例示＞
図１及び図２に、本実施形態の方式が適用されるドキュメント管理システムの概略構成を例示する。図１及び図２に示すシステムは、特許文献１〜４に例示したものと同様のものであり、ここでは概略の説明を行う。これらのシステムの詳細については、特許文献１〜４を参照されたい。
【００２７】
図１及び図２に例示するドキュメント管理システムは、電子的なドキュメント（以下、文書とも呼ぶ）をセキュアに利用できる環境を提供し、ドキュメントの情報が漏洩するリスクを下げることを目指す。ここで、ドキュメントは、１つの単位（例えば１つのファイル）として流通可能なコンテントデータであり、データの種類は特に限定されない。例えば、ドキュメントの概念には、テキストデータ、ワードプロセッサソフトで作成された文書データ、表計算ソフトで作成されたスプレッドシートデータ、ＣＡＤ（Computer Aided Design）データ、画像データ、動画データ、音声データ、マルチメディアデータ、ウェブブラウザで表示されたページデータ、その他ＰＣ上で作成・編集・閲覧されプリントアウト対象となる様なデータなどが含まれる。
【００２８】
図１のドキュメント管理システムは、複数のローカルシステム１００とそれらローカルシステムに関する管理（特に後述する処理システムの管理）を行う管理システム２００とを含む。管理システム２００は、インターネット等の広域ネットワーク１０を介して各ローカルシステム１００と通信可能である。
【００２９】
ローカルシステム１００は、ローカルネットワーク１０８に接続された１以上の作成端末１０２、１以上の閲覧端末１０４、及び処理装置１１０を含む。ローカルネットワーク１０８は、企業等の組織内に設けられたプライベートネットワーク（例えばＬＡＮとして構成）であり、ファイアウォール等により広域ネットワーク１０から保護されている。処理装置１１０は、基本的に、ローカルシステム１００内に１つ設置される。組織内のプライベートネットワークが大規模なものである場合、プライベートネットワークを構成する個々のネットワークセグメントをそれぞれローカルシステム１００とし、それら個々のローカルシステム１００内に１つずつ処理装置１１０を設置してもよい。
【００３０】
作成端末１０２は、ドキュメントを作成するために用いられる端末であり、例えばデスクトップ型又はノート型のパーソナルコンピュータ、ワークステーション、タブレット端末、スマートフォン、複合機、スキャナ、ファクシミリ装置、デジタルカメラ等がその例である。作成端末１０２には、ドキュメントの作成、編集等のためのアプリケーションがインストールされている。また、作成端末１０２には、作成したドキュメントの配信をドキュメント管理システムに依頼するためのソフトウエアがインストールされている。このソフトウエアの形態としては、後述する処理装置１１０と情報をやりとりするデバイスドライバとして実装、又はＷｅｂアプリによる実装、などが考えられる。
【００３１】
処理装置１１０は、作成端末１０２が作成したドキュメントを、ドキュメント管理システムが提供するセキュアな環境で用いる形態である保護済みドキュメント（以下では「ｅＤｏｃファイル」とも呼ぶ）へと変換するという保護処理を実行する。保護処理は、元のドキュメントをｅＤｏｃへとエンコードする処理ともいえ、この意味では処理装置１１０は一種のエンコーダである。この保護処理では、ドキュメントを、例えば、本実施形態のシステムのために設計された専用フォーマットのデータに変換すると共に、そのドキュメントの配信先に指定されたユーザにのみ復号可能な形で暗号化する。フォーマット変換と暗号化はどちらを先に行ってもよい。
【００３２】
また処理装置１１０は、保護済みドキュメントのメタデータを作成し、作成したメタデータを、内蔵するデータベースにその保護済みドキュメントと対応付けて保存すると共に、上位システムである管理システム２００にそのメタデータを登録する。メタデータは、当該保護済みドキュメントの書誌事項、配信先の情報、アクセス権限情報、各配信先が保護済みドキュメントの暗号化を解除するのに用いる鍵情報等を含む。書誌事項には、例えばそのドキュメントのＤＩＤ、そのドキュメントを本システムに登録したユーザ（すなわち配信者）のユーザＩＤ、登録の日時（すなわちエンコード日時）等の項目が含まれる。メタデータが含む項目の中には、このサービスで提供される機能に応じて、対応するデバイスやユーザからデータ付与や更新が行われる場合もある。また例えば、それら項目のうちの一部を、ドキュメント管理システムに対するドキュメントの登録指示を行ったユーザが指定し、別の一部は処理装置１１０が作成する。また、メタデータのうちの一部の項目の値を管理システム２００や閲覧端末１０４が設定することもあり得る。また、処理装置１１０は、生成した保護済みドキュメント（ｅＤｏｃファイル）を、ユーザの指定した配信先の閲覧端末１０４に送信する。
【００３３】
保護済みドキュメントすなわちｅＤｏｃファイルは、元のドキュメントを専用フォーマットに変換し暗号化したものであり、ｅＤｏｃの本体とも呼ぶ。保護済みドキュメントは、文書の一例である。ｅＤｏｃファイルを閲覧可能とするには、対応するメタデータが必要となる。ｅＤｏｃファイルとメタデータとが揃って、閲覧可能な完全な保護済みドキュメントを構成する。このように、ｅＤｏｃファイルとこれに対応するメタデータとの組を、以下では「ｅＤｏｃ」と呼ぶ。
【００３４】
各ユーザには、それぞれ自分にとっての既定の処理装置１１０が決められている。既定の処理装置１１０は、典型的には、ユーザが所属する部署に設置された処理装置１１０である。典型的な利用シーンでは、ユーザは、自分の部署内の他のユーザと共有するドキュメントをその処理装置１１０に登録し、それら他のユーザに配信する。ユーザの既定の処理装置１１０は、そのユーザのユーザＩＤと対応付けてユーザＩＤサーバ２１０に登録されている。ユーザが、既定の処理装置１１０以外の処理装置１１０に対してドキュメントの登録を依頼した場合、依頼を受けた処理装置１１０は、そのドキュメントを保護済みドキュメントに変換し、メタデータを生成してそのメタデータを管理システム２００に登録すると共に、その保護済みドキュメントとメタデータとをそのユーザの既定の処理装置１１０に転送する。既定の処理装置１１０は、転送された保護済みドキュメントとメタデータを、内蔵するデータベースに保存する。一方、転送元の処理装置１１０は、既定の処理装置１１０に転送した保護済みドキュメント及びメタデータを、自身の記憶装置から削除する。これにより、ユーザが登録した保護済みドキュメントは、そのユーザの既定の処理装置１１０にのみ保存されることとなる。
【００３５】
閲覧端末１０４は、保護済みドキュメント（ｅＤｏｃファイル）の閲覧に用いられる端末である。ここで言う「閲覧」は、保護済みドキュメントをそのドキュメントが表す情報内容に応じた態様で利用することを意味する。例えば、保護済みドキュメントがワープロデータや図面等の文書を情報内容として持つ場合、閲覧は、閲覧端末１０４が表示したその文書をユーザが読む又は見ることである。また保護済みドキュメントが表す情報内容が音声である場合、閲覧とは、閲覧端末１０４が再生したその音声をユーザが聞くことである。閲覧端末１０４は、例えば、デスクトップ型又はノート型のパーソナルコンピュータ、ワークステーション、タブレット端末、スマートフォン等の汎用のコンピュータに、保護済みドキュメントを閲覧するためのビューワアプリケーションをインストールして構成される。また、電子書籍端末のような閲覧専用の端末に、ビューワアプリケーションと同等の機能を持たせたものを閲覧端末１０４として用いてもよい。ビューワアプリケーションは、暗号化されている保護済みドキュメントをメタデータの情報を用いて復号する機能や、保護済みドキュメントの専用フォーマットで表されるデータを可読な状態のデータへとデコードする機能を有する。なお、ドキュメント管理システムに対応するビューワアプリケーションを持たないコンピュータは、専用フォーマットのデータを可読なデータへとデコードすることはできない。
【００３６】
また、一例として、ドキュメント管理システムを利用するユーザを認証するためのツールとして、ユーザが携帯する認証デバイス１３０を用いる。認証デバイス１３０は、ＩＣカードのように、当該デバイスを携帯するユーザに固有の識別情報を内蔵し、外部装置からの要求に応じてユーザ認証のためのデータ処理を実行するデバイスである。認証デバイス１３０は、そのような個人認証用のＩＣカードと同等の機能を内蔵したスマートフォンのような携帯端末であってもよい。閲覧端末１０４や作成端末１０２は、ＮＦＣ（Near Field Communication）等の無線通信プロトコルを用いて認証デバイス１３０と通信する機能を備える。閲覧端末１０４や作成端末１０２は、認証デバイス１３０との間で所定のプロトコルに沿ってユーザ認証のための情報をやりとりし、その認証デバイス１３０を携帯するユーザを認証する。あるいは、実際のユーザ認証は処理装置１１０や管理システム２００等、ドキュメント管理システムのサーバ側が実行し、閲覧端末１０４や作成端末１０２は、サーバ側と認証デバイス１３０との間のデータ転送の仲介を行う方式であってもよい。また、閲覧端末１０４や作成端末１０２が認証デバイス１３０の機能を内蔵していてもよい。
【００３７】
管理システム２００は、各ローカルシステム１００内の処理装置１１０を管理する。また管理システム２００は、それら各処理装置１１０が生成した保護済みドキュメントのメタデータを管理し、要求に応じてメタデータを閲覧端末１０４に提供する。管理システム２００は、１台のコンピュータ、又は相互に通信可能な複数のコンピュータにより構成され、ユーザＩＤサーバ２１０、ＤＩＤサーバ２２０、メタデータサーバ２３０、処理装置管理サーバ２４０の機能を有する。
【００３８】
ユーザＩＤサーバ２１０は、ドキュメント管理システムを利用する各ユーザの情報を管理するサーバである。ドキュメント管理システムを利用するユーザには、２つの階層がある。１つは、ドキュメント管理システムの利用のための契約を本システムの運営者と結んだ契約者であり、もう１つはその契約の下で実際にシステムを利用してドキュメントの登録や閲覧を行う一般ユーザである。例えば、会社が契約者であり、その会社のローカルネットワーク１０８に処理装置１１０が設置され、その会社の社員が一般ユーザとして、その処理装置１１０を介してドキュメント管理システムを利用するケースが多いと想定される。ユーザＩＤサーバ２１０は、契約者と一般ユーザのそれぞれについての情報を保持し、管理する。
【００３９】
ＤＩＤサーバ２２０は、保護済みドキュメントの識別情報（ＩＤ）であるＤＩＤ（ドキュメントＩＤ）を管理する。実際に保護済みドキュメントにＤＩＤを付与するのはその保護済みドキュメントを作成した処理装置１１０であるが、ＤＩＤサーバ２２０は処理装置１１０に対してＤＩＤの発行権限と発行枠（発行数）を付与し、その発行権限と発行枠の中で処理装置１１０が実際に発行したＤＩＤの報告を受けて記録する。これにより、ＤＩＤサーバ２２０は、不正なＤＩＤの発生を抑止し、不正なＤＩＤを持つドキュメントを検知可能とする。
【００４０】
メタデータサーバ２３０は、処理装置１１０が生成した保護済みドキュメント（ｅＤｏｃファイル）のメタデータを保持し、管理する。メタデータサーバ２３０は、ユーザから閲覧端末１０４を介して保護済みドキュメントのメタデータを要求された場合、そのユーザが正当な者であれば、メタデータをその閲覧端末１０４に提供する。なお、メタデータを要求するユーザ（閲覧者）がメタデータサーバ２３０にとって「正当な者」であるとは、そのユーザと、そのユーザがその要求を発する際に用いた閲覧端末１０４との組合せが、そのｅＤｏｃファイルのＤＩＤ（これはその要求に含まれる）に対応づけてメタデータサーバ２３０が保持しているメタデータ中の配信先情報に示される配信先ユーザ及び配信先の閲覧端末１０４の組合せに該当する場合のことである。
【００４１】
処理装置管理サーバ２４０は、各処理装置１１０のステータス（状態）を管理するサーバである。
【００４２】
図１のシステムにおける処理の流れを概説する。
【００４３】
ユーザは、ドキュメントをドキュメント管理システムに登録したい（すなわち配信したい）場合、作成端末１０２に対して認証デバイス１３０等を用いてログインし、ドキュメント登録を指示する。ユーザは、作成端末１０２に保持されているドキュメントからドキュメント管理システムに登録するものを選んでその登録を指示する。
【００４４】
すると、作成端末１０２は、選ばれたドキュメントに対する属性データのうちそのユーザが指定すべき項目（例えばドキュメントの配信先）の入力を受け付ける。ここで、配信先として、ユーザと閲覧端末１０４の組合せの指定を受け付けるようにしてもよい。この場合、ユーザと、そのユーザがドキュメントの閲覧に用いる閲覧端末１０４との組合せが、配信先として指定された組合せと一致する場合に、ユーザはそのドキュメントを閲覧可能となる。
【００４５】
作成端末１０２は、ユーザが入力した配信先等の属性項目と、作成端末１０２自身が生成した他の属性項目（例えば登録者の情報、作成日時等）と合わせた属性データを、そのドキュメントのデータと共に処理装置１１０に送信する。
【００４６】
処理装置１１０は、作成端末１０２から受信した登録対象のドキュメントに対して保護処理を施すことで保護済みドキュメント（ｅＤｏｃファイル）を生成する。この生成では、受信したドキュメントをドキュメント管理システムの専用フォーマットへとエンコードし、エンコードしたデータを、生成した暗号鍵を用いて暗号化することで、ｅＤｏｃファイルを生成する。エンコードと暗号化の順序は逆でもよい。また処理装置１１０は、そのｅＤｏｃに対して一意なＤＩＤを付与する。生成されたＤＩＤは、ｅＤｏｃファイル内に（例えばそのファイルのプロパティの一項目として）組み込まれる。
【００４７】
また処理装置１１０は、生成したｅＤｏｃファイルに対応するメタデータを生成する。このメタデータには、作成端末１０２からそのドキュメントと共に受け取った属性データと、処理装置１１０自身が生成した属性項目（例えば、ＤＩＤ、処理装置自身のＩＤ、エンコード日時、暗号鍵情報）の値とが含まれる。メタデータに含まれる暗号鍵情報は、ｅＤｏｃファイルの暗号化を解除するための鍵を示す情報である。暗号化に共通鍵方式を用いた場合、暗号鍵情報はその共通鍵を示す情報である。ただし、共通鍵そのものを平文でメタデータに含めると、盗聴や傍受により悪用される懸念があるので、その共通鍵を配信先ユーザの公開鍵で暗号化したものを暗号鍵情報としてメタデータに組み込む。
【００４８】
また、処理装置１１０は、生成したｅＤｏｃファイルとメタデータを、内蔵するデータベースに保存する。
【００４９】
処理装置１１０は、生成したメタデータを管理システム２００に送信して登録する。管理システム２００（メタデータサーバ２３０）は、受信したメタデータを保存する。なお、詳細は後述するが、本実施形態特有の制御として、処理装置１１０は、生成したメタデータの全項目の実体データを管理システム２００に送るのではなく、そのうちの所定の（すなわち予め定めた）一部の項目群のみの実体データを管理システム２００に送る。
【００５０】
処理装置１１０は、生成したｅＤｏｃファイルを、配信先に指定された閲覧端末１０４に配信する。この配信は、ローカルシステム１００内のローカルネットワーク１０８を介して行われる。
【００５１】
閲覧端末１０４が受信したｅＤｏｃファイルは、暗号化等により保護されているのでそのままでは閲覧が不可能である。ユーザは、閲覧端末１０４でそのｅＤｏｃファイルを閲覧したい場合、閲覧端末１０４にログインした上で、閲覧端末１０４の画面上でそのｅＤｏｃの閲覧を指示する。この指示を受けた閲覧端末１０４は、アクセス可能な処理装置１１０、又は管理システム２００、にアクセスしてそのｅＤｏｃのメタデータを要求する。この要求には、そのｅＤｏｃのＤＩＤが含まれる。
【００５２】
この要求を受けた処理装置１１０は、そのＤＩＤに対応するメタデータの最新版を管理システム２００から取得し、その閲覧端末１０４に送信する。なお、管理システム２００（特にメタデータサーバ２３０）がその要求を受ける構成の場合には、管理システム２００がそのＤＩＤに対応するメタデータの最新版をその閲覧端末１０４に送信する。処理装置１１０に対するユーザの操作によりメタデータに変更（例えばアクセス権限情報の変更）が加えられた場合、その変更は管理システム２００に伝達され、管理システム２００は自身が持つそのメタデータに対してその変更を反映させる。これにより、管理システム２００は、常に、保護済みドキュメントのメタデータの最新版を有する。
【００５３】
ここで、保護済みドキュメントの閲覧指示を受けた閲覧端末１０４にとってすぐに必要なのは、メタデータのうちの配信先情報とアクセス権限情報なので、処理装置１１０又は管理システムは、その要求に応じて閲覧端末１０４に対して、アクセス権限情報のみを送信してもよい。なお、配信先情報は、例えば、その保護済みドキュメントの配信先として指定されたユーザＩＤのリストを含む。また、配信先情報は、ユーザＩＤと端末ＩＤのペアのリストを含む場合もある。またアクセス権限情報は、例えば、その保護済みドキュメントの配信先情報に含まれる各ユーザＩＤに対応付けてそのユーザが持つ権限（例えば、閲覧のみ可能、又は閲覧と編集が可能等）の内容を示す情報を含む。すなわち、アクセス権限情報は、ｅＤｏｃに対する閲覧権限等のアクセス権限の付与先である付与先ユーザの情報を含んでいる。アクセス権限情報は、権限ユーザ情報の一例である。閲覧端末１０４は、ユーザからｅＤｏｃの閲覧を要求された場合、そのｅＤｏｃの最新のメタデータを処理装置１１０に要求し、これによって得たメタデータ中のアクセス権限情報を調べる。最新のメタデータから、そのユーザがそのｅＤｏｃについて閲覧権限等のアクセス権限を持っていることが分かれば、閲覧端末１０４はそのｅＤｏｃの内容を表示する。そのユーザがそのｅＤｏｃについてアクセス権限を持っていないことが分かれば、閲覧端末１０４はそのｅＤｏｃの内容の表示を拒否する。
【００５４】
閲覧端末１０４は、要求したメタデータを受信すると、そのメタデータに含まれる配信先情報に、当該閲覧端末１０４と現在この閲覧端末１０４を利用しているユーザとの組合せが含まれるかどうかを判定する。含まれていない場合、そのユーザはその閲覧端末１０４でそのｅＤｏｃを閲覧する権限がないので、閲覧端末１０４はｅＤｏｃファイルを開かず、閲覧権限がない旨を示すエラーメッセージを表示する。含まれる場合は、そのユーザはその閲覧端末１０４でそのｅＤｏｃファイルを閲覧する権限を持つ。この場合閲覧端末１０４は、そのｅＤｏｃファイルをそのメタデータに含まれる鍵情報を用いて復号し、そのｅＤｏｃファイルの復号結果の情報内容に応じた態様で出力する。
【００５５】
メタデータが最初の管理システム２００に登録された後、そのメタデータに含まれる配信先情報やアクセス権限情報が配信者、又は配信先の変更権限が与えられた者（例えばデータの編集権限を保有する者）により変更されることがある。処理装置１１０は、配信者から、その配信者が登録したｅＤｏｃファイルに対する各ユーザのアクセス権の内容を規定するアクセス権限情報の入力や変更を受け付ける機能を持つ。ｅＤｏｃが作成・登録された時点で配信先に指定されたユーザであっても、その後の変更により配信先から外された場合には、閲覧端末１０４は、管理システム２００から取得した最新のメタデータに含まれる配信先情報によりそのことを検知し、ｅＤｏｃファイルの表示を行わない。
【００５６】
図１は、処理装置１１０群と管理システム２００の２階層の階層構造を持つシステムであったが、新たな管理システムの階層を挿入することで、３階層以上のシステムとすることもできる。図２に３階層のシステムを例示する。
【００５７】
図２に示す例では、企業等の組織のプライベートネットワークである組織内ネットワーク内にローカルシステム１００が複数存在する。組織内ネットワークや、ローカルシステム１００のローカルネットワーク１０８は、内部ネットワークの一例である。
【００５８】
組織内ネットワークには、組織内管理システム１５０が設けられている。組織内管理システム１５０は、ドキュメント管理システムのうち当該組織内の処理やそれに必要な情報を管理する。すなわち、管理システム２００は、ドキュメント管理システムのサービスプロバイダが運用し、ドキュメント管理システムを利用する複数の組織についての情報や処理を管理するのに対し、組織内管理システム１５０はそれら情報や処理のうち当該組織に関する部分を、管理システム２００の管理下で管理する。
【００５９】
組織内ネットワークは、ファイアウォール３００を介して、外部ネットワークの一例であるインターネット上にある管理システム２００に接続されている。例えば、組織内ネットワークは、管理システム２００とエクストラネットを構成している。組織内ネットワークは、ファイアウォール３００を介してインターネットに接続されている。
【００６０】
組織内管理システム１５０は、ローカルユーザＩＤサーバ１５２、ローカルＤＩＤサーバ１５４、及びローカルメタデータサーバ１５６を有する。
【００６１】
ローカルユーザＩＤサーバ１５２は、当該組織のメンバのうちドキュメント管理システムにユーザ登録されているユーザの情報を管理する。ローカルユーザＩＤサーバ１５２が保持する個々のユーザの情報は、ユーザＩＤサーバ２１０が保持する一般ユーザの情報と同様である。処理装置１１０に対して、その処理装置１１０を取得し利用するユーザ（すなわちその処理装置１１０を「既定の処理装置」とするユーザ）が登録されると、処理装置１１０は登録されたユーザの情報を組織内のローカルユーザＩＤサーバ１５２に送る。ローカルユーザＩＤサーバ１５２は、受け取ったユーザの情報を保存すると共に、ファイアウォール３００経由で、インターネット上にある中央の管理システム２００のユーザＩＤサーバ２１０に送る。ユーザＩＤサーバ２１０は、受け取ったユーザの情報を保管する。また、処理装置１１０に登録されたユーザの情報に変更が生じた場合、管理者等が処理装置１１０に対してそのユーザの情報の変更を行う。処理装置１１０は、このユーザ情報の変更内容の情報（例えばユーザＩＤと、変更された情報項目の項目名と、その項目の変更後の値とを含む）をローカルユーザＩＤサーバ１５２に送信し、ローカルユーザＩＤサーバ１５２は、受信した変更に内容に応じて自身が保管している当該ユーザの情報を変更する。また、ローカルユーザＩＤサーバ１５２は、受け取った変更内容の情報を中央のユーザＩＤサーバ２１０に送り、ユーザＩＤサーバ２１０は送られてきた情報に応じて、自分が保持するそのユーザの情報を変更する。
【００６２】
ローカルＤＩＤサーバ１５４は、当該組織の組織内ネットワークに属する各ローカルシステム１００内の処理装置１１０が発行したＤＩＤを受け取り、保管する。ローカルＤＩＤサーバ１５４が保持する情報は、ＤＩＤサーバ２２０が保持する情報と同様である。またローカルＤＩＤサーバ１５４は、処理装置１１０から受け取ったＤＩＤの情報を中央のＤＩＤサーバ２２０に送り、ＤＩＤサーバ２２０はその情報を保管する。また、ローカルＤＩＤサーバ１５４は、中央のＤＩＤサーバ２２０からＤＩＤの発行権限及び発行枠を付与され、その発行枠の範囲内で、その発行権限に基づいて管理下の各処理装置１１０に対してＤＩＤの発行権限及び発行枠を付与する。
【００６３】
ローカルメタデータサーバ１５６は、当該組織の組織内ネットワークに属する各ローカルシステム１００内の処理装置１１０が生成したｅＤｏｃのメタデータを受け取り、保管する。ローカルメタデータサーバ１５６が保持する情報は、メタデータサーバ２３０が保持する情報と同様である。またローカルメタデータサーバ１５６は、処理装置１１０から受け取ったメタデータを中央のメタデータサーバ２３０に送り、メタデータサーバ２３０はそのメタデータを保管する。
【００６４】
＜実施形態＞
ドキュメント管理システムに登録された保護済みドキュメントに対して、このシステムの外部にあるサーバが提供するアプリケーションを適用するための仕組みを以下に説明する。
【００６５】
図３は、この実施形態のドキュメント管理システムの構成を例示する図である。図３に例示したシステムは、図２に例示した組織内管理システム１５０の階層を含んだシステムをベースとするものであるが、これは一例にすぎない。もっと階層が多いシステムや、逆に図１に例示したローカルシステム１００と管理システム２００の２階層のみからなるシステムにも、本実施形態の手法は適用可能である。
【００６６】
図３のシステムでは、インターネット等の外部ネットワーク上にある管理システム２００は、外部ネットワークを介して外部アプリサーバ４００とセキュアに接続されている。外部アプリサーバ４００は、ドキュメント管理システム内の保護済みドキュメントやそのメタデータに対して何らかのアプリケーション（すなわち情報処理）を実行するサービスを提供する。外部アプリサーバ４００は、外部サーバの一例である。図では外部アプリサーバ４００を１つのみ示したが、様々なアプリケーションを提供する複数の外部アプリサーバ４００があってもよい。なお、以下では、外部アプリサーバ４００が提供するアプリケーションのことを外部アプリと呼ぶ。
【００６７】
あくまで例示にすぎないが、外部アプリとしては、ｅＤｏｃの文書内容を特定の言語に翻訳するアプリケーション、ｅＤｏｃの文書内容の要約を生成するアプリケーション、ｅＤｏｃのメタデータに対する解析を行うアプリケーション、等がある。
【００６８】
図３のシステムは、外部アプリＧＷＳ（ゲートウエイサーバ）３２０を有している。外部アプリＧＷＳ（以下単にＧＷＳともいう）３２０は、ローカルシステム１００内のユーザと、外部アプリサーバ４００との間での、外部アプリの利用要求及びその外部アプリの処理対象となるデータと、外部アプリの処理結果データ等と、のやりとりを、安全かつ自動的に仲介するゲートウェイである。
【００６９】
外部アプリＧＷＳ３２０は、内部ネットワークである組織内ネットワーク上の装置と、インターネット等の外部ネットワーク上の装置と、の両方と通信可能となるよう設定されている。図３の例では、外部アプリＧＷＳ３２０は、組織内ネットワークを外部ネットワークと隔てるファイアウォール３００内の装置として設けられている。しかし、これは一例に過ぎない。外部アプリＧＷＳ３２０は、組織内ネットワーク及び外部ネットワークの両方と通信可能であればよく、その設置場所はファイアウォール３００の内部に限らない。
【００７０】
以下、図３のシステムにおいて、実施形態の制御に関連する要素について詳しく説明する。
【００７１】
＜処理装置＞
図４に、処理装置１１０の詳細な構成を例示する。処理装置１１０は、内部装置の一例である。図示のように、処理装置１１０は、管理情報記憶部１１２、ユーザＤＢ１１４、ドキュメントＤＢ１１６、要求受付部１１７及びデータ提供部１１９を含む。
【００７２】
管理情報記憶部１１２には、管理情報１１２ａが記憶される。管理情報１１２ａには、上位装置アドレス情報、セキュリティ証明書、暗号鍵、エンコードソフト名、エンコードソフトバージョン、暗号化ソフト名、暗号化ソフトバージョン等の項目が含まれる。上位装置アドレス情報は、処理装置１１０を管理する上位装置のそれぞれの通信アドレス（例えばＩＰアドレス、ＵＲＬ等）の情報である。管理システム２００やその中の各サーバ２１０〜２４０、又は組織内管理システム１５０やその中の各サーバ１５２〜１５６が上位装置の例である。セキュリティ証明書は、処理装置１１０がネットワーク上の他の装置と公開鍵基盤準拠のセキュアな通信を行う際に用いるデジタル証明書である。処理装置１１０は、よく通信する相手である各上位装置のセキュリティ証明書を保持している。また作成端末１０２や閲覧端末１０４を使用する各ユーザのセキュリティ証明を保持してもよい。暗号鍵は、処理装置１１０がネットワーク上の他の装置と通信を行う際の暗号化や復号、処理装置１１０によるデジタル署名（又はそれに類する証明情報の生成）等の目的に用いる、当該処理装置１１０の暗号鍵であり、例えば公開鍵基盤においてその処理装置１１０に対して付与された秘密鍵と公開鍵のペアである。エンコードソフト及び暗号化ソフトは、それぞれ、この処理装置１１０にインストールされているエンコード（専用フォーマットへの変換）及び暗号化のためのソフトウエアである。
【００７３】
ユーザＤＢ１１４には、この処理装置１１０に登録されている各ユーザ（言い換えればこの処理装置１１０を「既定の処理装置」とするユーザ）のユーザ情報１１４ａが記憶されている。個々の登録ユーザのユーザ情報１１４ａには、ユーザＩＤ、パスワード、ユーザＩＤキー情報、公開鍵情報、既定の閲覧端末リスト等の項目が含まれる。ユーザＩＤキー情報は、そのユーザの認証デバイス１３０が用いるそのユーザの認証情報である。既定の閲覧端末リストは、そのユーザが主として使用する１以上の閲覧端末のＩＤのリストである。
【００７４】
ドキュメントＤＢ１１６には、処理装置１１０が生成したｅＤｏｃファイルと、そのｅＤｏｃファイルに対応するメタデータとが保存される。ｅＤｏｃファイルとメタデータとはＤＩＤの情報を含んでいるので、対応付けが可能である。またドキュメントＤＢ１１６には、ｅＤｏｃにエンコードする前の元のデータ（作成端末１０２から受け取ったもの）を、そのｅＤｏｃのＤＩＤに対応付けて登録してもよい。ドキュメントＤＢ１１６は、内部装置の一例である処理装置１１０が備える記憶手段の一例である。
【００７５】
要求受付部１１７は、要求受付手段の一例であり、ユーザから外部アプリを利用する旨の要求（以下、アプリ利用要求、又は利用要求と呼ぶ）を受け付けると共に、受け付けたアプリ利用要求を上位装置、すなわち図３の例では組織内管理システム１５０に転送する処理を行う。転送されたアプリ利用要求は、組織内管理システム１５０及び外部アプリＧＷＳ３２０を介して、外部アプリサーバ４００に送られる。また要求受付部１１７は、そのアプリ利用要求に対する外部アプリの処理結果を受け取り、その処理結果を要求元のユーザに提供したり、ドキュメントＤＢ１１６内のメタデータにその処理結果を反映させたりする。
【００７６】
データ提供部１１９は、ユーザが要求した外部アプリが必要とするｅＤｏｃファイル又はメタデータ又はその両方を、外部アプリに提供するための処理を実行する。データ提供部１１９は、データ提供手段の一例である。
【００７７】
＜外部アプリＧＷＳ＞
次に、図５を参照して、外部アプリＧＷＳ３２０の機能構成を例示する。外部アプリＧＷＳ３２０は、仲介装置の一例である。外部アプリＧＷＳ３２０は、要求転送部３２２、サーバ要求処理部３２４、及び処理結果転送部３２６を有する。
【００７８】
要求転送部３２２は、組織内管理システム１５０を介して受け取ったユーザからのアプリ利用要求を、その外部アプリを実行する外部アプリサーバ４００に転送する。要求転送部３２２は要求送信手段の一例であり、アプリ利用要求は要求データの一例である。
【００７９】
ここで、外部アプリが適切に実行されるようにするためには、外部アプリが必要とするデータ項目群をその利用要求に含める必要がある。外部アプリの実行に必要なデータ項目群は、組織内ネットワーク内にある場合もあれば、外部ネットワーク上にある場合もある。このため、要求転送部３２２は、組織内管理システム１５０を介して受け取ったユーザの利用要求の中に、外部アプリの実行に必要なデータ項目が含まれていない場合、そのデータ項目を組織内ネットワーク内、又は外部ネットワーク上の装置から取得する。このように、要求転送部３２２は、外部アプリに転送するアプリ利用要求に含めるべきデータ項目を、組織内ネットワーク上の装置（例えば処理装置１１０）と、外部ネットワーク上の装置（例えば外部アプリサーバ４００や管理システム２００）から取得する機能を有する。そして、取得したデータ項目を含んだアプリ利用要求を、外部アプリサーバ４００に送信する。
【００８０】
外部アプリサーバ４００は、外部アプリＧＷＳ３２０からアプリ利用要求を受け取ると、そのアプリ要求に応じた外部アプリの実行のために必要なデータを取得するために、外部アプリＧＷＳ３２０に対して、データ要求を送る。
【００８１】
サーバ要求処理部３２４は、外部アプリサーバ４００からそのデータ要求を受け取り、そのデータ要求が示すデータを組織内ネットワーク内の装置（例えば処理装置１１０）から取得する。また、サーバ要求処理部３２４は、取得したデータを外部アプリサーバ４００に送信する。
【００８２】
処理結果転送部３２６は、アプリ利用要求に対する外部アプリサーバ４００の処理結果のデータ（処理結果データと呼ぶ）を受け取り、その処理結果データを、ユーザからそのアプリ利用要求を受け付けた処理装置１１０に転送する。このとき処理結果転送部３２６は、処理結果データを処理装置１１０に対して直接転送してもよいし、アプリ利用要求が転送されてきた経路とは逆の経路に沿って転送してもよい。後者の場合、処理結果転送部３２６は、処理結果データを、組織内管理システム１５０に転送する。処理結果転送部３２６は、処理結果送信手段の一例である。
【００８３】
ここで、外部アプリサーバ４００に転送するアプリ利用要求に含まれる複数のデータ項目について説明する。この実施形態では、外部アプリサーバ４００に転送するアプリ利用要求は、以下のデータ項目（ａ）〜（ｅ）を含んでいる必要がある。
【００８４】
（ａ）要求受付アドレス情報
要求受付アドレス情報は、外部アプリサーバ４００が、当該アプリ利用要求を受け付けるために特別に用意した受付用アドレス（例えばＵＲＬ）を示す情報である。
【００８５】
本実施形態では、外部アプリＧＷＳ３２０は、外部アプリサーバ４００にアプリ利用要求を送る場合、その外部アプリサーバ４００の既知の固定的な窓口アドレスにアクセスし、外部アプリサーバ４００とハンドシェイク処理を実行する。このハンドシェイク処理において、外部アプリサーバ４００はそのアプリ利用要求に固有の受付用アドレスを生成し、その受付用アドレスを外部アプリＧＷＳ３２０に提供する。外部アプリＧＷＳ３２０はその受付アドレスに対してアプリ利用要求を送る。その受付用アドレスを示す情報が要求受付アドレス情報である。なお、外部アプリサーバ４００は、アプリ利用要求の処理を終了すると、そのアプリ利用要求に対応する受付用アドレス（すなわち要求受付アドレス情報）を無効化する。これにより、その受付用アドレスが第三者に利用されるといったセキュリティ上のリスクが少なくなる。要求受付アドレス情報は、外部アプリサーバ４００が一時的に生成する宛先データの一例である。
【００８６】
（ｂ）外部アプリＧＷＳ３２０の外部ネットワーク向けのアドレス情報
このアドレス情報は、外部ネットワーク上の装置が外部アプリＧＷＳ３２０にアクセスする際に用いるアドレスを示す情報である。このアドレス情報は、例えばＵＲＬの形式で表される。
【００８７】
外部アプリサーバ４００は、外部アプリＧＷＳ３２０から受け取ったアプリ利用要求に対する処理結果データを外部アプリＧＷＳ３２０に応答する際、そのアドレス情報が示すアドレス宛に送る。また、外部アプリサーバ４００は、アプリ利用要求の処理のために必要なデータを外部アプリＧＷＳ３２０に要求する際にも、そのアドレス情報が示すアドレスにその要求を送ってもよい。
【００８８】
このアドレス情報は、固定的なものであってもよい。また、上述した要求受付アドレス情報と同様、外部アプリＧＷＳ３２０が、このアドレス情報として、そのアプリ利用要求のための専用のアドレス情報を生成してもよい。
【００８９】
（ｃ）外部アプリＧＷＳ３２０へのアクセス権情報
このアクセス権情報は、アプリ利用要求を発したユーザが、外部アプリＧＷＳ３２０を利用できるか否かを示す情報である。このアクセス権情報は、外部アプリＧＷＳ３２０がユーザからのアプリ利用要求を受け付けるか否かの判定に用いる。また、このアクセス権情報をアプリ利用要求に含めて外部アプリサーバ４００に送ることで、第三者が外部アプリＧＷＳ３２０になりすますことを困難にする。
【００９０】
（ｄ）アプリＩＤ及びアクセスキー
アプリＩＤは、アプリ利用要求の対象である外部アプリの識別情報である。アクセスキーは、その外部アプリのどの機能をどのレベルまで利用可能か示す情報である。例えば、組織内ネットワークを有する組織に対して外部アプリの提供者が外部アプリの利用のためのライセンスを発行するが、そのライセンスにアクセスキーが含まれる。外部アプリサーバ４００は、アプリ利用要求に含まれるアプリＩＤ及びアクセスキーにより、どの外部アプリを実行するかを認識すると共に、そのアプリ利用要求が要求する機能を提供してよいか（すなわちユーザがその機能を利用可能か）を判断する。
【００９１】
（ｅ）要求情報
要求情報は、アプリ利用要求の本体となる情報であり、アプリ利用要求の内容を表す１以上の項目からなる。要求情報には、例えばＤＩＤ、ユーザＩＤ、メタデータＩＤ、アプリ機能ＩＤ等のうちの１以上の項目が含まれる。ＤＩＤは、アプリ利用要求に係る外部アプリの処理対象となるｅＤｏｃのＩＤである。ユーザＩＤは、アプリ利用要求を行ったユーザのＩＤである。メタデータＩＤは、アプリ利用要求に係る外部アプリの処理対象となるメタデータ項目の識別情報であり、メタデータ特定情報の一例である。メタデータ項目は、メタデータを構成する項目（例えばＤＩＤ、ユーザＩＤ、アクセス権限情報、鍵情報等）のことである。特定のｅＤｏｃの特定のメタデータ項目は、そのｅＤｏｃのＤＩＤと、そのメタデータ項目のメタデータＩＤとの組合せで特定される。メタデータ項目の中には、外部アプリの処理結果を格納するための項目もある。また、この要求情報には、外部アプリの利用を処理装置１１０に要求した際にユーザが用いている端末（例えば閲覧端末１０４）の端末ＩＤを含めてもよい。個々のメタデータ項目は、メタデータを構成する要素の一例であり、メタデータＩＤは、メタデータの要素を一意に識別する要素識別情報の一例である。
【００９２】
アプリ機能ＩＤは、そのアプリ利用要求にてユーザが利用したいと要求した外部アプリの機能の識別情報である。アプリ機能ＩＤは、例えば、外部アプリの識別情報（すなわちアプリＩＤ）と、その外部アプリが有する１以上の機能のうちユーザが利用を要求した機能の識別情報と、の組合せで表現される。
【００９３】
例えば、本実施形態のドキュメント管理システムに対して、外部アプリを提供する提供者は、管理システム２００の運営者からその外部アプリについての審査を受ける。そして、その審査に合格すると、運営者からその外部アプリについてのアプリＩＤの付与を受ける。またこのとき、その外部アプリが提供する１以上の機能のそれぞれについてＩＤが付与される。また、その外部アプリの各機能について、その機能による処理の結果の書き込み先となるメタデータ項目のＩＤも付与される。
【００９４】
以上に例示した（ａ）〜（ｅ）のデータ項目群のうち、（ａ）のデータ項目は、外部アプリＧＷＳ３２０が、アプリ利用要求を外部アプリサーバ４００に送る際に、外部アプリサーバ４００から取得する。すなわち、（ａ）は、外部アプリＧＷＳ３２０が外部ネットワーク上から取得するデータ項目の一例である。（ｂ）のデータ項目は、外部アプリＧＷＳ３２０自身が知っているか、生成する。（ｃ）のデータ項目は、ユーザの属性情報の１つであり、例えば組織内管理システム１５０内のローカルユーザＩＤサーバ１５２で管理されている。また、処理装置１１０は、利用したい外部アプリをユーザに選択させるので、（ｄ）のうちアプリＩＤは処理装置１１０が把握可能である。また、アクセスキーは、組織内管理システム１５０が、アプリＩＤに対応付けて管理している。（ｅ）のうちＤＩＤ、ユーザＩＤ、アプリ機能ＩＤの各項目は、処理装置１１０がユーザから外部アプリの利用要求を受け付けたときに特定される。また、メタデータＩＤについては、特定されたアプリ機能ＩＤに応じて決まる（例えば組織内管理システム１５０において）。
【００９５】
次に図６を参照して、組織内管理システム１５０が保持している外部アプリの管理情報の一例を説明する。
【００９６】
図６に例示する外部アプリの管理情報は、アプリＩＤ、外部アプリサーバの窓口アドレス情報、アクセスキー、契約種別情報、有効期限、課金条件情報を含む。この管理情報は、外部アプリサーバ４００群が提供する外部アプリごとに作成され、管理される。アプリＩＤは、当該外部アプリの識別情報である。外部アプリサーバの窓口アドレス情報は、当該外部アプリを実行する外部アプリサーバ４００の固定的な窓口のアドレス（例えばＵＲＬ）である。前述の通り、外部アプリＧＷＳ３２０は、外部アプリサーバ４００のこの固定的な窓口のアドレスにアクセスし、アプリ利用要求の送信先とする要求受付アドレス情報を得る。外部アプリＧＷＳ３２０は、ユーザが発した利用要求に含まれるアプリＩＤに対応する外部アプリサーバ４００の窓口アドレスの情報を、組織内管理システム１５０から取得する。アクセスキーは、当該外部アプリに関して当該組織内管理システム１５０を用いている組織が取得しているアクセスキーである。アクセスキーの内容については前述した。契約種別情報は、当該組織と当該外部アプリの提供者の契約の種別を示す情報である。有効期限は、アクセスキーの有効期限である。課金条件情報は、当該外部アプリについて課金のその組織内での計上の仕方（例えばユーザに対する課金とするのか、ユーザの属する部署の課金とするのか等）を規定する情報である。
【００９７】
図６に例示した管理情報のうち、アプリＩＤと、外部アプリサーバの窓口アドレス情報とは、組織に固有の情報ではないので、中央の管理システム２００にて管理してもよい。
【００９８】
次に、図７を参照して、外部アプリの利用の流れを説明する。
【００９９】
（１）処理装置１１０は、ユーザからの要求に応じて、外部アプリの実行指示を入力可能なＵＩ画面をそのユーザの閲覧端末１０４に、ネットワーク経由で提供する。このＵＩ画面は、例えば、処理装置１１０のドキュメントＤＢ１１６内にある、そのユーザがアクセス権を持つｅＤｏｃの一覧画面であってもよい。
【０１００】
（２）ユーザは、そのＵＩ画面上で外部アプリの利用を要求するための操作を行う。例えば、ＵＩ画面上でユーザがｅＤｏｃを１つ選択すると、例えば、そのｅＤｏｃに対して実行可能な処理のメニューが表示される。このメニューには、外部アプリ群が提供する各機能を表すメニュー項目も含まれる。例えば、ある外部アプリサーバ４００が提供する各国語翻訳サービスという外部アプリが、中国語への翻訳機能、アラビア語への翻訳機能といった複数の機能を提供する場合、その機能毎にメニュー項目が設けられる。外部アプリの機能を表すメニュー項目には、その機能を一意に特定する外部アプリ機能ＩＤが対応付けられている。この外部アプリ機能ＩＤは、例えば、その外部アプリのアプリＩＤと、その外部アプリ内での当該機能のＩＤ（例えばその外部アプリが提供する各機能に割り当てられた通し番号）と、の組合せで表現される。なお、１つの機能のみを提供する外部アプリもあり、その場合、その機能の外部アプリ機能ＩＤは、その外部アプリのアプリＩＤと同じであってもよい。
【０１０１】
以上に説明したように、１つの例では、ユーザは、ＵＩ画面上で、ｅＤｏｃを選択し、そのｅＤｏｃに適用したい外部アプリの機能を選択する。これにより、ユーザの外部アプリ利用のための指示の内容が処理装置１１０に伝わる。
【０１０２】
（３）処理装置１１０は、ユーザから入力された指示の内容に従ってアプリ利用要求を生成し、自装置の上位の組織内管理システム１５０に対してそのアプリ利用要求を渡す。このアプリ利用要求には、そのユーザのユーザＩＤ、ユーザが選択した外部アプリの機能を特定する外部アプリ機能ＩＤ、その機能の適用対象であるｅＤｏｃのＤＩＤ、という各データ項目が含まれる。また、このアプリ利用要求には、その処理装置１１０のＩＤが含まれていてもよい。
【０１０３】
（４）組織内管理システム１５０は、処理装置１１０から受け取ったアプリ利用要求に対して、その要求に含めるべきデータ項目のうち自分が保持しているデータ項目を追加する。例えば、組織内管理システム１５０は、アプリ利用要求に含まれるアプリ機能ＩＤから、そのアプリ機能ＩＤに対応するアプリＩＤを求め、そのアプリＩＤに対応するアクセスキーをアプリ利用要求に追加する。なお、アプリ機能ＩＤ内にアプリＩＤが含まれている場合には、この追加は不要である。また、組織内管理システム１５０は、保持している各アプリＩＤについてのアクセスキーのうち、そのアプリＩＤに対応するものをアプリ利用要求に追加する。また組織内管理システム１５０は、アプリ機能ＩＤごとに、そのアプリ機能ＩＤが示す外部アプリの機能を実行したときの処理結果の格納先とするメタデータ項目のＩＤ（すなわちメタデータＩＤ）を保持している。組織内管理システム１５０は、アプリ利用要求に含まれるアプリ機能ＩＤに対応するメタデータＩＤを求め、そのメタデータＩＤをアプリ利用要求に追加する。また、組織内管理システム１５０は、アプリ利用要求に含まれるユーザＩＤから、そのユーザＩＤに対応するアプリＧＷＳへのアクセス権情報を求め、そのアクセス権情報をアプリ利用要求に追加する。そして、組織内管理システム１５０は、このようにして必要なデータ項目を追加したアプリ利用要求を外部アプリＧＷＳ３２０に送信する。
【０１０４】
（５）組織内管理システム１５０からアプリ利用要求を受け取った外部アプリＧＷＳ３２０は、その利用要求に含まれる外部アプリＧＷＳ３２０へのアクセス権情報に基づき、そのアプリ利用要求を受け付けるか拒否するかを判定する。拒否すると判定した場合は、外部アプリＧＷＳ３２０は、組織内管理システム１５０及び処理装置１１０を介して、または直接、そのユーザの閲覧端末１０４に対して、権限がないため要求を受け付けられない旨のエラーメッセージを送る。
【０１０５】
一方、アプリ利用要求を受け付けると判定した場合、外部アプリＧＷＳ３２０は、そのアプリ利用要求に含まれるアプリＩＤに対応する外部アプリを提供する外部アプリサーバ４００の固定的な窓口アドレスの情報を管理システム２００から取得する。この例では、外部アプリサーバ４００の固定的な窓口アドレスの情報は管理システム２００で管理されているとする。この場合、例えば何らかの事情で外部アプリサーバ４００の窓口アドレスが変更された場合、その変更は中央の管理システム２００が管理する情報に反映しておくだけでよい。
【０１０６】
（６）外部アプリＧＷＳ３２０は、取得した窓口アドレスに対してアクセスし、その外部アプリサーバ４００とハンドシェイクを行う。これにより、外部アプリサーバ４００から、今回のアプリ利用要求の送り先の一時的なアドレスを示す、要求受付アドレス情報を受け取る。
【０１０７】
（７）外部アプリＧＷＳ３２０は、組織内管理システム１５０から受け取ったアプリ利用要求に対して、要求受付アドレス情報と、自身の外部ネットワーク向けのアドレス情報とを追加する。そして、追加後のアプリ利用要求を外部アプリサーバ４００に送信する。このとき送信されるアプリ利用要求のデータは、外部アプリＧＷＳ３２０と外部アプリサーバ４００との間の伝送路の暗号化により保護される。以上の処理により、アプリ利用要求は、要求受付アドレス情報が示すアドレスへと送信される。
【０１０８】
（８）外部アプリサーバ４００は、外部アプリＧＷＳ３２０から受け取ったアプリ利用要求に従って外部アプリを実行する。この外部アプリの実行の詳細は、後で説明する。
【０１０９】
（９）外部アプリサーバ４００は、外部アプリの実行により得られた処理結果データを、アプリ利用要求に含まれる、外部アプリＧＷＳ３２０の外部ネットワーク向けのアドレスに送信する。この処理結果データには、アプリ利用要求に含まれるユーザＩＤの情報、又はそのユーザが使っている端末の端末ＩＤ又はその両方が付随する。
【０１１０】
（１０）外部アプリＧＷＳ３２０は、処理結果データに付随するユーザＩＤ又は端末ＩＤを用いて、アプリ利用要求の発行元のユーザの閲覧端末１０４を特定し、組織内ネットワークを経由して、その閲覧端末１０４にその処理結果データを送信する。閲覧端末１０４は、受信した処理結果データを画面表示する。
【０１１１】
（１１）また外部アプリサーバ４００は、外部アプリＧＷＳ３２０に対して、外部アプリ利用についてのログを記録する処理（ログ処理と呼ぶ）のためのデータを送信する。このデータには、処理結果データと、その外部アプリが適用されたｅＤｏｃのＤＩＤと、その処理結果データを格納するメタデータ項目を特定するメタデータＩＤとが含まれる。
【０１１２】
（１２）外部アプリＧＷＳ３２０は、そのログ処理用のデータを組織内管理システム１５０に渡す。
【０１１３】
組織内管理システム１５０は、受け取ったログ処理用のデータを、ローカルメタデータサーバ１５６に反映する。すなわち、組織内管理システム１５０は、そのログ処理用のデータが含むログの情報を、外部アプリの処理の対象となったｅＤｏｃのメタデータ中のログ情報に追加する。このログには、例えば外部アプリの実行日時、外部アプリサーバ４００のＩＤ、実行した外部アプリの識別名、指示したユーザのＩＤ等の項目が含まれる。
【０１１４】
また組織内管理システム１５０が外部アプリＧＷＳ３２０から受け取ったログ処理用のデータには、処理結果データと、ＤＩＤと、メタデータＩＤが含まれる。組織内管理システム１５０は、その処理結果データを、ローカルメタデータサーバ１５６内のそのＤＩＤに対応するメタデータ中の、そのメタデータＩＤに対応するメタデータ項目に書き込む・
【０１１５】
（１３）組織内管理システム１５０は、ユーザからアプリ利用要求を受け付けた処理装置１１０とメタデータの同期処理を行う。これにより、上記ステップ（１２）で更新されたメタデータの更新内容（すなわちログ及び処理結果データの追加）がその処理装置１１０内のドキュメントＤＢ１１６にも反映される。
【０１１６】
次に、上記ステップ（８）における外部アプリサーバ４００の処理について更に詳しく説明する。
【０１１７】
外部アプリサーバ４００は、外部アプリＧＷＳ３２０から受け取ったアプリ利用要求に含まれるアプリ機能ＩＤから、実行すべき外部アプリの機能を特定する。また外部アプリサーバ４００は、特定した外部アプリの機能を実行するのに、対象となるｅＤｏｃ又はメタデータが必要な場合には、そのｅＤｏｃ又はメタデータを取得する。
【０１１８】
例えば、その機能がｅＤｏｃの内容に対する処理（例えば翻訳）である場合、外部アプリサーバ４００は、外部アプリＧＷＳ３２０に対して文書要求を送る。この文書要求には、そのアプリ利用要求に含まれるＤＩＤが含まれる。ＤＩＤは、文書を一意に識別する文書識別情報の一例である。またこの文書要求には、外部アプリサーバ４００の公開鍵が含まれていてもよい。この文書要求を受けた外部アプリＧＷＳ３２０は、そのＤＩＤに対応するｅＤｏｃを記憶している処理装置１１０（この例ではユーザからアプリ利用要求を受け付けた処理装置１１０）に、そのｅＤｏｃの提供指示を送る。この提供指示を受けた処理装置１１０は、そのｅＤｏｃ（これは暗号化された状態である）と、そのｅＤｏｃを復号するための鍵を外部アプリサーバ４００の公開鍵で暗号化したデータ（このデータを鍵データと呼ぶ）と、を互いに対応付けて、外部アプリＧＷＳ３２０に送信する。外部アプリＧＷＳ３２０は、処理装置１１０から受け取ったｅＤｏｃと鍵データとを外部アプリサーバ４００に送信する。外部アプリサーバ４００は、外部アプリＧＷＳ３２０からｅＤｏｃと鍵データを受信する。外部アプリサーバ４００は、その鍵データを自身の秘密鍵で復号することにより、ｅＤｏｃを復号するための復号鍵を得る。外部アプリサーバ４００はその復号鍵を用いてｅＤｏｃを復号することにより、そのｅＤｏｃの内容を表す平文データを得る。そして、外部アプリサーバ４００は、その平文データに対して、要求された外部アプリの機能に係る処理を実行する。外部アプリサーバ４００は、その処理の結果得られた処理結果データを外部アプリＧＷＳ３２０に応答した後、その平文データを削除する。
【０１１９】
以上の処理の流れにおいて、外部アプリＧＷＳ３２０は、処理装置１１０からｅＤｏｃと鍵データを受け取るが、その鍵データを復号できないため、結局そのｅＤｏｃの内容は外部アプリＧＷＳ３２０には知り得ない。したがって、ｅＤｏｃの内容は、そのｅＤｏｃの登録を受け付けた処理装置１１０と、そのｅＤｏｃにアクセス権を持つユーザと、そのｅＤｏｃの処理を行う外部アプリサーバ４００にしか公開されない。
【０１２０】
アプリ要求データ中のアプリ機能ＩＤが示す機能がｅＤｏｃのメタデータ項目に対する処理である場合、外部アプリサーバ４００は、外部アプリＧＷＳ３２０に対して要求を送る。この要求には、そのアプリ利用要求に含まれるＤＩＤと、そのメタデータ項目を示すメタデータＩＤとが含まれる。この要求はメタデータ要求の一例である。この要求を受け取った外部アプリＧＷＳ３２０は、そのＤＩＤが示すｅＤｏｃを記憶している処理装置１１０に対して、そのＤＩＤ及びメタデータＩＤを含む要求を送る。処理装置１１０は、その要求に含まれるＤＩＤ及びメタデータＩＤの組合せにより特定されるメタデータ項目の値を外部アプリＧＷＳ３２０に返す。外部アプリＧＷＳ３２０は、処理装置１１０から受け取ったメタデータ項目の値を外部アプリサーバ４００に送信する。この送信の際、外部アプリＧＷＳ３２０は、そのメタデータ項目の値を暗号化し、その暗号化で得られたデータを外部アプリサーバ４００に送信する。このデータは、暗号化メタデータの一例である。外部アプリサーバ４００は、受け取ったデータを復号してメタデータ項目の値を求め、その値を用いて、要求された外部アプリの機能に係る処理を実行する。
【０１２１】
以上に例示した作成端末１０２、閲覧端末１０４、処理装置１１０、ローカルユーザＩＤサーバ１５２、ローカルＤＩＤサーバ１５４、ローカルメタデータサーバ１５６、ユーザＩＤサーバ２１０、ＤＩＤサーバ２２０、メタデータサーバ２３０、処理装置管理サーバ２４０、外部アプリＧＷＳ３２０等の各装置は、コンピュータに上述のそれら各装置の機能を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）及びリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、フラッシュメモリやＳＳＤ（ソリッドステートドライブ）、ＨＤＤ（ハードディスクドライブ）や等の固定記憶装置を制御するコントローラ、各種Ｉ／Ｏ（入出力）インタフェース、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバス等を介して接続された回路構成を有する。それら各機能の処理内容が記述されたプログラムがネットワーク等の経由でフラッシュメモリ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。
【符号の説明】
【０１２２】
１００  ローカルシステム、１０２  作成端末、１０４  閲覧端末、１０８  ローカルネットワーク、１１０  処理装置、１１２  管理情報記憶部、１１４  ユーザＤＢ、１１６  ドキュメントＤＢ、１１７  要求受付部、１１９  データ提供部、１３０  認証デバイス、１５０  組織内管理システム、１５２  ローカルユーザＩＤサーバ、１５４  ローカルＤＩＤサーバ、１５６  ローカルメタデータサーバ、２００  管理システム、２１０  ユーザＩＤサーバ、２２０  ＤＩＤサーバ、２３０  メタデータサーバ、２４０  処理装置管理サーバ、３００  ファイアウォール、３２０  外部アプリＧＷＳ（ゲートウエイサーバ）、３２２  要求転送部、３２４  サーバ要求処理部、３２６  処理結果転送部、４００  外部アプリサーバ。
【図１】
2020160503.tif 000003
【図２】
2020160503.tif 000004
【図３】
2020160503.tif 000005
【図４】
2020160503.tif 000006
【図５】
2020160503.tif 000007
【図６】
2020160503.tif 000008
【図７】
2020160503.tif 000009