図面 (/)

技術 データ管理システム

出願人 富士ゼロックス株式会社
発明者 神谷成樹伊與田哲男山下明男
出願日 2019年3月22日 (1年9ヶ月経過) 出願番号 2019-054007
公開日 2020年9月24日 (3ヶ月経過) 公開番号 2020-154902
状態 特許登録済
技術分野 検索装置
主要キーワード 差入れ 最下階層 契約識別情報 ビューワアプリケーション わかりやすさ 本アプリ 秘密事項 管理対象データ
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2020年9月24日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (13)

課題

階層構造になっている管理システムにおいて、管理対象データ実体最上位の装置が全て管理する場合と比較して、管理対象データがユーザの意図しない装置に提供されないシステムを提供する。

解決手段

管理システムは、管理対象データであるメタデータを生成する最下層の複数の処理装置と、それら処理装置が生成したメタデータの一部を記憶する少なくとも1階層の上位の管理装置(例えばメタデータサーバ)と、を含む階層構造を有する。管理装置は、メタデータのうち、自装置内に実体データを記憶していない項目については、階層構造状でその管理装置の下位にある管理装置又は処理装置に記憶されている、その項目の実体データを特定するリンク情報を記憶している。管理装置は、要求されたメタデータの項目の実体データを持っていない場合、リンク情報を用いてその実体データをユーザに提供する。

概要

背景

出願人は、管理装置(又は管理システム)と複数の処理装置とからなる2層構造を含むドキュメント管理システムを提案している(特許文献1〜4参照)。処理装置は、主として、本システムに登録されるドキュメントを暗号化等により保護する処理と、この処理により得られた保護済みドキュメントを送信先のユーザに配信する処理とを担う。管理装置は、処理装置群を管理すると共に、それら処理装置が生成した保護済みドキュメントのメタデータ保管し、保管したメタデータの提供を行う。ユーザは、それぞれ自分のホームとする処理装置に登録される、例えば、処理装置は、企業の部署等の単位ごとに設置され、その単位に属するユーザはその単位に設置された処理装置に登録される。

ユーザがシステムに登録したドキュメントの保護済みドキュメントは、そのユーザがホームとする処理装置に保存される。そして、そのユーザが指定した送信先のユーザであって、その処理装置自身、又は、その処理装置に対して安全であるものとして登録された他の処理装置、を介してそのドキュメントの配信を要求したユーザの端末に送信される。保護済みドキュメントは、それが登録された処理装置と、送信先に指定されたユーザの端末には保存されるが、管理装置や他の処理装置、他の端末には保存されない。

また、保護済みドキュメントのメタデータには、その保護済みドキュメントに対する閲覧権限等の権限を持つユーザの情報が保持される、この権限の情報は、その保護済みドキュメントをシステムに登録したユーザ(登録者)等の権限を有する者が処理装置を介してシステムに登録したり、変更したりする。端末は、その端末を操作しているユーザから、その端末内の保護済みドキュメントの閲覧指示を受けた場合、その保護済みドキュメントの識別情報に対応する最新のメタデータを近傍の処理装置を介して取得し、そのユーザが現在その保護済みドキュメントの閲覧権限を持つのかを、その最新のメタデータに基づき判定する。閲覧権限を持つと判定した場合は、端末はその保護済みドキュメントをメタデータ中鍵情報を用いて復号して表示し、そうでない場合は閲覧不可の旨をユーザに通知する。

以上に説明したように、このシステムは、保護済みドキュメントが、これを登録したユーザのホームの処理装置と、そのユーザが指定した送信先の各ユーザの端末と、にしか保持されないという仕組みにより、保護済みドキュメントが第三者の手に渡りにくくしている。

概要

階層構造になっている管理システムにおいて、管理対象データ実体最上位の装置が全て管理する場合と比較して、管理対象データがユーザの意しない装置に提供されないシステムを提供する。管理システムは、管理対象データであるメタデータを生成する最下層の複数の処理装置と、それら処理装置が生成したメタデータの一部を記憶する少なくとも1階層の上位の管理装置(例えばメタデータサーバ)と、を含む階層構造を有する。管理装置は、メタデータのうち、自装置内に実体データを記憶していない項目については、階層構造状でその管理装置の下位にある管理装置又は処理装置に記憶されている、その項目の実体データを特定するリンク情報を記憶している。管理装置は、要求されたメタデータの項目の実体データを持っていない場合、リンク情報を用いてその実体データをユーザに提供する。

目的

例えば、最上位の管理装置が管理対象データの実体を全て管理しようと下位の管理装置(例えば第2の管理装置)が管理する一部の管理対象データの実体を上位の管理装置に提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

階層構造をなす複数の装置を含み、前記複数の装置のうち前記階層構造上の最下階層以外の階層に位置する装置は、複数の項目からなる管理対象データのうち当該装置の記憶対象の項目の実体データを記憶する記憶手段と、当該装置に対応する前記階層構造上の下位の装置に記憶されている、前記管理対象データの実体データうち当該装置の前記記憶対象の項目以外の項目群の実体データを特定するリンク情報を取得する取得手段と、を含むデータ管理システム

請求項2

前記複数の装置のうち前記階層構造の最下階層及び最上階層を除く各階層に位置する装置は、前記下位の装置から前記記憶対象の項目の実体データを受信する受信手段と、受信した前記記憶対象の項目の実体データのうちの所定の項目の実体データを、当該装置に対応する前記階層構造上の上位の装置に送信する手段と、前記受信手段が受信した前記記憶対象の項目の実体データを、前記リンク情報と対応付けて前記記憶手段に格納する制御を行う格納制御手段と、を更に含む請求項1に記載のデータ管理システム。

請求項3

前記格納制御手段は、前記受信手段が前記記憶対象の項目の実体データの受信の際に得た前記下位の装置の情報から前記リンク情報を生成し、生成したリンク情報と、前記受信手段が受信した前記記憶対象の項目の実体データと、を前記記憶手段に格納する、ことを特徴とする請求項2に記載のデータ管理システム。

請求項4

前記階層構造上の前記最下階層に位置する装置は、当該装置が実行した処理に基づいて前記管理対象データを生成する手段と、生成した前記管理対象データのうちの所定の項目の実体データを、当該装置に対応する前記階層構造上の上位の装置に送信する手段と、を更に含む請求項1〜3のいずれか1項に記載のデータ管理システム。

請求項5

前記複数の装置の各々は、前記管理対象データについての検索要求を受信する手段と、前記検索要求を満たす前記管理対象データを検索するための制御を行う検索制御手段であって、当該装置に対応する前記階層構造上の下位又は上位のうちの少なくとも一方の装置に対して前記検索要求を転送する機能を持つ検索制御手段と、を更に含む請求項1〜4のいずれか1項に記載のデータ管理システム。

請求項6

同一の管理対象データの一部又は全部の項目の実体データを前記記憶手段に記憶している前記階層構造上の各階層の前記装置は、当該管理対象データの識別情報を前記記憶手段に記憶しており、前記検索制御手段は、前記検索要求が特定の識別情報を持つ前記管理対象データを求めるものである場合において、当該識別情報が前記記憶手段に記憶されていない場合には、当該装置に対応する前記階層構造上の上位の装置に前記検索要求を転送し、当該識別情報が前記記憶手段に記憶されている場合には、当該装置に対応する前記階層構造上の上位の装置には前記検索要求を転送しない、請求項5に記載のデータ管理システム。

請求項7

前記検索制御手段は、前記検索要求が求める前記識別情報を持つ前記管理対象データが前記記憶手段に記憶されている場合において、当該識別情報を持つ管理対象データのうち前記検索要求が求める項目の実体データが前記記憶手段に記憶されていない場合、前記記憶手段に記憶されている当該管理対象データに対応する前記リンク情報が示す前記階層構造上の下位の装置に前記検索要求を転送する、ことを特徴とする請求項6に記載のデータ管理システム。

請求項8

前記検索制御手段は、前記検索要求が求める前記識別情報を持つ前記管理対象データが前記記憶手段に記憶されている場合において、当該識別情報を持つ管理対象データのうち前記検索要求が求める項目が前記記憶手段に記憶されていない場合、前記記憶手段に記憶されている当該管理対象データに対応する前記リンク情報が示す前記階層構造上の下位の装置から、前記検索要求が求める前記項目の実体データを取得する、ことを特徴とする請求項6に記載のデータ管理システム。

技術分野

0001

本発明は、データ管理システムに関する。

背景技術

0002

出願人は、管理装置(又は管理システム)と複数の処理装置とからなる2層構造を含むドキュメント管理システムを提案している(特許文献1〜4参照)。処理装置は、主として、本システムに登録されるドキュメントを暗号化等により保護する処理と、この処理により得られた保護済みドキュメントを送信先のユーザに配信する処理とを担う。管理装置は、処理装置群を管理すると共に、それら処理装置が生成した保護済みドキュメントのメタデータ保管し、保管したメタデータの提供を行う。ユーザは、それぞれ自分のホームとする処理装置に登録される、例えば、処理装置は、企業の部署等の単位ごとに設置され、その単位に属するユーザはその単位に設置された処理装置に登録される。

0003

ユーザがシステムに登録したドキュメントの保護済みドキュメントは、そのユーザがホームとする処理装置に保存される。そして、そのユーザが指定した送信先のユーザであって、その処理装置自身、又は、その処理装置に対して安全であるものとして登録された他の処理装置、を介してそのドキュメントの配信を要求したユーザの端末に送信される。保護済みドキュメントは、それが登録された処理装置と、送信先に指定されたユーザの端末には保存されるが、管理装置や他の処理装置、他の端末には保存されない。

0004

また、保護済みドキュメントのメタデータには、その保護済みドキュメントに対する閲覧権限等の権限を持つユーザの情報が保持される、この権限の情報は、その保護済みドキュメントをシステムに登録したユーザ(登録者)等の権限を有する者が処理装置を介してシステムに登録したり、変更したりする。端末は、その端末を操作しているユーザから、その端末内の保護済みドキュメントの閲覧指示を受けた場合、その保護済みドキュメントの識別情報に対応する最新のメタデータを近傍の処理装置を介して取得し、そのユーザが現在その保護済みドキュメントの閲覧権限を持つのかを、その最新のメタデータに基づき判定する。閲覧権限を持つと判定した場合は、端末はその保護済みドキュメントをメタデータ中鍵情報を用いて復号して表示し、そうでない場合は閲覧不可の旨をユーザに通知する。

0005

以上に説明したように、このシステムは、保護済みドキュメントが、これを登録したユーザのホームの処理装置と、そのユーザが指定した送信先の各ユーザの端末と、にしか保持されないという仕組みにより、保護済みドキュメントが第三者の手に渡りにくくしている。

先行技術

0006

特開2018−156409号公報
特開2018−156410号公報
特開2018−156411号公報
特開2018−156383号公報

発明が解決しようとする課題

0007

第1の管理装置に管理されている第2の管理装置が存在するような階層構造になっている管理システムにおいて、管理の対象となるデータ(以下、管理対象データと呼ぶ)の実体最上位の管理装置(例えば第1の管理装置)が全て管理しようとするとセキュリティ上問題になることがあった。例えば、最上位の管理装置が管理対象データの実体を全て管理しようと下位の管理装置(例えば第2の管理装置)が管理する一部の管理対象データの実体を上位の管理装置に提供する際、下位の管理装置と上位の管理装置を運営する主体(例えば企業)が異なる場合や、下位の管理装置に管理される管理対象データやこれに対応付けられたデータが下位の管理装置の外になるべく出したくないデータである場合等がその一例である。

0008

本発明は、階層構造になっている管理システムにおいて、管理対象データの実体を最上位の装置が全て管理する場合と比較して、管理対象データがユーザの意図しない装置に提供されないシステムを提供することを目的とする。

課題を解決するための手段

0009

請求項1に係る発明は、階層構造をなす複数の装置を含み、前記複数の装置のうち前記階層構造上の最下階層以外の階層に位置する装置は、複数の項目からなる管理対象データのうち当該装置の記憶対象の項目の実体データを記憶する記憶手段と、当該装置に対応する前記階層構造上の下位の装置に記憶されている、前記管理対象データの実体データうち当該装置の前記記憶対象の項目以外の項目群の実体データを特定するリンク情報を取得する取得手段と、を含むデータ管理システムである。

0010

請求項2に係る発明は、前記複数の装置のうち前記階層構造の最下階層及び最上階層を除く各階層に位置する装置は、前記下位の装置から前記記憶対象の項目の実体データを受信する受信手段と、受信した前記記憶対象の項目の実体データのうちの所定の項目の実体データを、当該装置に対応する前記階層構造上の上位の装置に送信する手段と、前記受信手段が受信した前記記憶対象の項目の実体データを、前記リンク情報と対応付けて前記記憶手段に格納する制御を行う格納制御手段と、を更に含む請求項1に記載のデータ管理システムである。

0011

請求項3に係る発明は、前記格納制御手段は、前記受信手段が前記記憶対象の項目の実体データの受信の際に得た前記下位の装置の情報から前記リンク情報を生成し、生成したリンク情報と、前記受信手段が受信した前記記憶対象の項目の実体データと、を前記記憶手段に格納する、ことを特徴とする請求項2に記載のデータ管理システムである。

0012

請求項4に係る発明は、前記階層構造上の前記最下階層に位置する装置は、当該装置が実行した処理に基づいて前記管理対象データを生成する手段と、生成した前記管理対象データのうちの所定の項目の実体データを、当該装置に対応する前記階層構造上の上位の装置に送信する手段と、を更に含む請求項1〜3のいずれか1項に記載のデータ管理システムである。

0013

請求項5に係る発明は、前記複数の装置の各々は、前記管理対象データについての検索要求を受信する手段と、前記検索要求を満たす前記管理対象データを検索するための制御を行う検索制御手段であって、当該装置に対応する前記階層構造上の下位又は上位のうちの少なくとも一方の装置に対して前記検索要求を転送する機能を持つ検索制御手段と、を更に含む請求項1〜4のいずれか1項に記載のデータ管理システムである。

0014

請求項6に係る発明は、同一の管理対象データの一部又は全部の項目の実体データを前記記憶手段に記憶している前記階層構造上の各階層の前記装置は、当該管理対象データの識別情報を前記記憶手段に記憶しており、前記検索制御手段は、前記検索要求が特定の識別情報を持つ前記管理対象データを求めるものである場合において、当該識別情報が前記記憶手段に記憶されていない場合には、当該装置に対応する前記階層構造上の上位の装置に前記検索要求を転送し、当該識別情報が前記記憶手段に記憶されている場合には、当該装置に対応する前記階層構造上の上位の装置には前記検索要求を転送しない、請求項5に記載のデータ管理システムである。

0015

請求項7に係る発明は、前記検索制御手段は、前記検索要求が求める前記識別情報を持つ前記管理対象データが前記記憶手段に記憶されている場合において、当該識別情報を持つ管理対象データのうち前記検索要求が求める項目の実体データが前記記憶手段に記憶されていない場合、前記記憶手段に記憶されている当該管理対象データに対応する前記リンク情報が示す前記階層構造上の下位の装置に前記検索要求を転送する、ことを特徴とする請求項6に記載のデータ管理システムである。

0016

請求項8に係る発明は、前記検索制御手段は、前記検索要求が求める前記識別情報を持つ前記管理対象データが前記記憶手段に記憶されている場合において、当該識別情報を持つ管理対象データのうち前記検索要求が求める項目が前記記憶手段に記憶されていない場合、前記記憶手段に記憶されている当該管理対象データに対応する前記リンク情報が示す前記階層構造上の下位の装置から、前記検索要求が求める前記項目の実体データを取得する、ことを特徴とする請求項6に記載のデータ管理システムである。

発明の効果

0017

請求項1に係る発明によれば、階層構造になっている管理システムにおいて、管理対象データの実体を最上位の装置が全て管理する場合と比較して、管理対象データがユーザの意図しない装置に提供されないシステムを提供することができる。

0018

請求項2又は4に係る発明によれば、請求項1に係るシステムのために、階層構造の上位になるほど実体データを記憶している項目が少なくなるようにすることができる。

0019

請求項3に係る発明によれば、下位の装置からリンク情報が送られてこない場合でも,リンク情報を記憶することができる。

0020

請求項5に係る発明によれば、検索要求が求めるメタデータが自装置にない場合に,システム内の他の装置にてその検索要求が処理されるようにすることができる。

0021

請求項6に係る発明によれば、ある識別情報を持つメタデータを検索する検索要求に対して、自装置にそのメタデータがない場合に、そのメタデータを記憶している可能性がある上位の装置にその検索要求を処理させることができる。

0022

請求項7に係る発明によれば、検索要求が求めるメタデータ中の項目の実体データを自装置が記憶していない場合に、その実体データを記憶している可能性がある下位の装置にその検索要求を処理させることができる。

0023

請求項8に係る発明によれば、検索要求が求めるメタデータ中の項目の実体データを自装置が記憶していない場合に、その実体データを記憶している可能性がある下位の装置からその実体データを取得し、検索要求の要求元に提供することができる。

図面の簡単な説明

0024

ドキュメント管理システムの構成の例を示す図である。
組織内管理システムを設けたシステム構成の例を示す図である。
メタデータの項目を例示する図である。
ドキュメント管理システムに含まれる処理装置及びMDS(メタデータサーバ)の階層構造を例示する図である。
階層が上位になるにつれ、メタデータのうち処理装置及びMDSが実体データを記憶する項目を少なくしていくことを説明する図である。
あるレベルのMDSが記憶しているメタデータの項目内容を示す図である。
図6の例より下位のレベルのMDSが記憶しているメタデータの項目内容を示す図である。
ドキュメントの登録を指示されたときに処理装置が実行する処理手順の例を示す図である。
下位装置からメタデータがアップロードされたときにMDSが実行する処理手順の例を示す図である。
ユーザの端末から検索要求を受け取ったときに処理装置が実行する処理手順の例を示す図である。
他の装置から検索要求を受け取ったときにMDSが実行する処理手順の例を示す図である。
他の装置から検索要求を受け取ったときにMDSが実行する処理手順の別の例を示す図である。

実施例

0025

<実施形態の制御の適用先となるシステムの例示>
図1及び図2に、本実施形態の制御が適用されるドキュメント管理システムの概略構成を例示する。図1及び図2に示すシステムは、特許文献1〜4に例示したものと同様のものであり、ここでは概略の説明を行う。これらのシステムの詳細については、特許文献1〜4を参照されたい。

0026

図1及び図2に例示するドキュメント管理システムは、電子的なドキュメントをセキュアに利用できる環境を提供し、ドキュメントの情報が漏洩するリスク下げることを目指す。ここで、ドキュメントは、1つの単位(例えば1つのファイル)として流通可能なコンテントデータであり、データの種類は特に限定されない。例えば、ドキュメントの概念には、テキストデータ、ワードプロセッサソフトで作成された文書データ表計算ソフトで作成されたスプレッドシートデータCAD(Computer Aided Design)データ、画像データ、動画データ、音声データ、マルチメディアデータ、ウェブブラウザで表示されたページデータ、その他PC上で作成・編集・閲覧されプリントアウト対象となる様なデータなどが含まれる。

0027

図1のドキュメント管理システムは、複数のローカルシステム100とそれらローカルシステムに関する管理(特に後述する処理システムの管理)を行う管理システム200とを含む。管理システム200は、インターネット等の広域ネットワーク10を介して各ローカルシステム100と通信可能である。

0028

ローカルシステム100は、ローカルネットワーク108に接続された1以上の作成端末102、1以上の閲覧端末104、及び処理装置110を含む。ローカルネットワーク108は、企業等の組織内に設けられたプライベートネットワーク(例えばLANとして構成)であり、ファイアウォール等により広域ネットワーク10から保護されている。処理装置110は、基本的に、ローカルシステム100内に1つ設置される。組織内のプライベートネットワークが大規模なものである場合、プライベートネットワークを構成する個々のネットワークセグメントをそれぞれローカルシステム100とし、それら個々のローカルシステム100内に1つずつ処理装置110を設置してもよい。

0029

作成端末102は、ドキュメントを作成するために用いられる端末であり、例えばデスクトップ型又はノート型パーソナルコンピュータワークステーションタブレット端末スマートフォン複合機スキャナファクシミリ装置デジタルカメラ等がその例である。作成端末102には、ドキュメントの作成、編集等のためのアプリケーションインストールされている。また、作成端末102には、作成したドキュメントの配信をドキュメント管理システムに依頼するためのソフトウエアがインストールされている。このソフトウエアの形態としては、後述する処理装置110と情報をやりとりするデバイスドライバとして実装、又はWebアプリによる実装、などが考えられる。

0030

処理装置110は、作成端末102が作成したドキュメントを、ドキュメント管理システムが提供するセキュアな環境で用いる形態である保護済みドキュメント(以下では「eDocファイル」とも呼ぶ)へと変換するという保護処理を実行する。保護処理は、元のドキュメントをeDocへとエンコードする処理ともいえ、この意味では処理装置110は一種エンコーダである。この保護処理では、ドキュメントを、例えば、本実施形態のシステムのために設計された専用フォーマットのデータに変換すると共に、そのドキュメントの配信先に指定されたユーザにのみ復号可能な形で暗号化する。フォーマット変換と暗号化はどちらを先に行ってもよい。

0031

また処理装置110は、保護済みドキュメントのメタデータを作成し、作成したメタデータを、内蔵するデータベースにその保護済みドキュメントと対応付けて保存すると共に、上位システムである管理システム200にそのメタデータを登録する。メタデータは、当該保護済みドキュメントの書誌事項、配信先の情報、アクセス権限情報、各配信先が保護済みドキュメントの暗号化を解除するのに用いる鍵情報等を含む。書誌事項には、例えばそのドキュメントのDID、そのドキュメントを本システムに登録したユーザ(すなわち配信者)のユーザID、登録の日時(すなわちエンコード日時)等の項目が含まれる。メタデータが含む項目の中には、このサービスで提供される機能に応じて、対応するデバイスやユーザからデータ付与や更新が行われる場合もある。また例えば、それら項目のうちの一部を、ドキュメント管理システムに対するドキュメントの登録指示を行ったユーザが指定し、別の一部は処理装置110が作成する。また、メタデータのうちの一部の項目の値を管理システム200や閲覧端末104が設定することもあり得る。また、処理装置110は、生成した保護済みドキュメント(eDocファイル)を、ユーザの指定した配信先の閲覧端末104に送信する。

0032

メタデータは、本実施形態の管理の対象である管理対象データの一例である。

0033

保護済みドキュメントすなわちeDocファイルは、元のドキュメントを専用フォーマットに変換し暗号化したものであり、eDocの本体とも呼ぶ。eDocファイルを閲覧可能とするには、対応するメタデータが必要となる。eDocファイルとメタデータとが揃って、閲覧可能な完全な保護済みドキュメントを構成する。このように、eDocファイルとこれに対応するメタデータとの組を、以下では「eDoc」と呼ぶ。

0034

各ユーザには、それぞれ自分にとっての既定の処理装置110が決められている。既定の処理装置110は、典型的には、ユーザが所属する部署に設置された処理装置110である。典型的な利用シーンでは、ユーザは、自分の部署内の他のユーザと共有するドキュメントをその処理装置110に登録し、それら他のユーザに配信する。ユーザの既定の処理装置110は、そのユーザのユーザIDと対応付けてユーザIDサーバ210に登録されている。ユーザが、既定の処理装置110以外の処理装置110に対してドキュメントの登録を依頼した場合、依頼を受けた処理装置110は、そのドキュメントを保護済みドキュメントに変換し、メタデータを生成してそのメタデータを管理システム200に登録すると共に、その保護済みドキュメントとメタデータとをそのユーザの既定の処理装置110に転送する。既定の処理装置110は、転送された保護済みドキュメントとメタデータを、内蔵するデータベースに保存する。一方、転送元の処理装置110は、既定の処理装置110に転送した保護済みドキュメント及びメタデータを、自身の記憶装置から削除する。これにより、ユーザが登録した保護済みドキュメントは、そのユーザの既定の処理装置110にのみ保存されることとなる。

0035

閲覧端末104は、保護済みドキュメント(eDocファイル)の閲覧に用いられる端末である。ここで言う「閲覧」は、保護済みドキュメントをそのドキュメントが表す情報内容に応じた態様で利用することを意味する。例えば、保護済みドキュメントがワープロデータや図面等の文書を情報内容として持つ場合、閲覧は、閲覧端末104が表示したその文書をユーザが読む又は見ることである。また保護済みドキュメントが表す情報内容が音声である場合、閲覧とは、閲覧端末104が再生したその音声をユーザが聞くことである。閲覧端末104は、例えば、デスクトップ型又はノート型のパーソナルコンピュータ、ワークステーション、タブレット端末、スマートフォン等の汎用コンピュータに、保護済みドキュメントを閲覧するためのビューワアプリケーションをインストールして構成される。また、電子書籍端末のような閲覧専用の端末に、ビューワアプリケーションと同等の機能を持たせたものを閲覧端末104として用いてもよい。ビューワアプリケーションは、暗号化されている保護済みドキュメントをメタデータの情報を用いて復号する機能や、保護済みドキュメントの専用フォーマットで表されるデータを可読な状態のデータへとデコードする機能を有する。なお、ドキュメント管理システムに対応するビューワアプリケーションを持たないコンピュータは、専用フォーマットのデータを可読なデータへとデコードすることはできない。

0036

また、一例として、ドキュメント管理システムを利用するユーザを認証するためのツールとして、ユーザが携帯する認証デバイス130を用いる。認証デバイス130は、ICカードのように、当該デバイスを携帯するユーザに固有の識別情報を内蔵し、外部装置からの要求に応じてユーザ認証のためのデータ処理を実行するデバイスである。認証デバイス130は、そのような個人認証用のICカードと同等の機能を内蔵したスマートフォンのような携帯端末であってもよい。閲覧端末104や作成端末102は、NFC(Near Field Communication)等の無線通信プロトコルを用いて認証デバイス130と通信する機能を備える。閲覧端末104や作成端末102は、認証デバイス130との間で所定のプロトコルに沿ってユーザ認証のための情報をやりとりし、その認証デバイス130を携帯するユーザを認証する。あるいは、実際のユーザ認証は処理装置110や管理システム200等、ドキュメント管理システムのサーバ側が実行し、閲覧端末104や作成端末102は、サーバ側と認証デバイス130との間のデータ転送仲介を行う方式であってもよい。また、閲覧端末104や作成端末102が認証デバイス130の機能を内蔵していてもよい。

0037

管理システム200は、各ローカルシステム100内の処理装置110を管理する。また管理システム200は、それら各処理装置110が生成した保護済みドキュメントのメタデータを管理し、要求に応じてメタデータを閲覧端末104に提供する。管理システム200は、1台のコンピュータ、又は相互に通信可能な複数のコンピュータにより構成され、ユーザIDサーバ210、DIDサーバ220、メタデータサーバ230、処理装置管理サーバ240の機能を有する。

0038

ユーザIDサーバ210は、ドキュメント管理システムを利用する各ユーザの情報を管理するサーバである。ドキュメント管理システムを利用するユーザには、2つの階層がある。1つは、ドキュメント管理システムの利用のための契約を本システムの運営者と結んだ契約者であり、もう1つはその契約の下で実際にシステムを利用してドキュメントの登録や閲覧を行う一般ユーザである。例えば、会社が契約者であり、その会社のローカルネットワーク108に処理装置110が設置され、その会社の社員が一般ユーザとして、その処理装置110を介してドキュメント管理システムを利用するケースが多いと想定される。ユーザIDサーバ210は、契約者と一般ユーザのそれぞれについての情報を保持し、管理する。

0039

DIDサーバ220は、保護済みドキュメントの識別情報(ID)であるDID(ドキュメントID)を管理する。実際に保護済みドキュメントにDIDを付与するのはその保護済みドキュメントを作成した処理装置110であるが、DIDサーバ220は処理装置110に対してDIDの発行権限と発行枠(発行数)を付与し、その発行権限と発行枠の中で処理装置110が実際に発行したDIDの報告を受けて記録する。これにより、DIDサーバ220は、不正なDIDの発生を抑止し、不正なDIDを持つドキュメントを検知可能とする。

0040

メタデータサーバ230は、処理装置110が生成した保護済みドキュメント(eDocファイル)のメタデータを保持し、管理する。メタデータサーバ230は、ユーザから閲覧端末104を介して保護済みドキュメントのメタデータを要求された場合、そのユーザが正当な者であれば、メタデータをその閲覧端末104に提供する。なお、メタデータを要求するユーザ(閲覧者)がメタデータサーバ230にとって「正当な者」であるとは、そのユーザと、そのユーザがその要求を発する際に用いた閲覧端末104との組合せが、そのeDocファイルのDID(これはその要求に含まれる)に対応づけてメタデータサーバ230が保持しているメタデータ中の配信先情報に示される配信先ユーザ及び配信先の閲覧端末104の組合せに該当する場合のことである。

0041

処理装置管理サーバ240は、各処理装置110のステータス(状態)を管理するサーバである。

0042

図1のシステムにおける処理の流れを概説する。

0043

ユーザは、ドキュメントをドキュメント管理システムに登録したい(すなわち配信したい)場合、作成端末102に対して認証デバイス130等を用いてログインし、ドキュメント登録を指示する。ユーザは、作成端末102に保持されているドキュメントからドキュメント管理システムに登録するものを選んでその登録を指示する。

0044

すると、作成端末102は、選ばれたドキュメントに対する属性データのうちそのユーザが指定すべき項目(例えばドキュメントの配信先)の入力を受け付ける。ここで、配信先として、ユーザと閲覧端末104の組合せの指定を受け付けるようにしてもよい。この場合、ユーザと、そのユーザがドキュメントの閲覧に用いる閲覧端末104との組合せが、配信先として指定された組合せと一致する場合に、ユーザはそのドキュメントを閲覧可能となる。

0045

作成端末102は、ユーザが入力した配信先等の属性項目と、作成端末102自身が生成した他の属性項目(例えば登録者の情報、作成日時等)と合わせた属性データを、そのドキュメントのデータと共に処理装置110に送信する。

0046

処理装置110は、作成端末102から受信した登録対象のドキュメントに対して保護処理を施すことで保護済みドキュメント(eDocファイル)を生成する。この生成では、受信したドキュメントをドキュメント管理システムの専用フォーマットへとエンコードし、エンコードしたデータを、生成した暗号鍵を用いて暗号化することで、eDocファイルを生成する。エンコードと暗号化の順序は逆でもよい。また処理装置110は、そのeDocに対して一意なDIDを付与する。生成されたDIDは、eDocファイル内に(例えばそのファイルのプロパティの一項目として)組み込まれる。

0047

また処理装置110は、生成したeDocファイルに対応するメタデータを生成する。このメタデータには、作成端末102からそのドキュメントと共に受け取った属性データと、処理装置110自身が生成した属性項目(例えば、DID、処理装置自身のID、エンコード日時、暗号鍵情報)の値とが含まれる。メタデータに含まれる暗号鍵情報は、eDocファイルの暗号化を解除するための鍵を示す情報である。暗号化に共通鍵方式を用いた場合、暗号鍵情報はその共通鍵を示す情報である。ただし、共通鍵そのものを平文でメタデータに含めると、盗聴傍受により悪用される懸念があるので、その共通鍵を配信先ユーザの公開鍵で暗号化したものを暗号鍵情報としてメタデータに組み込む。

0048

また、処理装置110は、生成したeDocファイルとメタデータを、内蔵するデータベースに保存する。

0049

処理装置110は、生成したメタデータを管理システム200に送信して登録する。管理システム200(メタデータサーバ230)は、受信したメタデータを保存する。なお、詳細は後述するが、本実施形態特有の制御として、処理装置110は、生成したメタデータの全項目の実体データを管理システム200に送るのではなく、そのうちの所定の(すなわち予め定めた)一部の項目群のみの実体データを管理システム200に送る。

0050

処理装置110は、生成したeDocファイルを、配信先に指定された閲覧端末104に配信する。この配信は、ローカルシステム100内のローカルネットワーク108を介して行われる。

0051

閲覧端末104が受信したeDocファイルは、暗号化等により保護されているのでそのままでは閲覧が不可能である。ユーザは、閲覧端末104でそのeDocファイルを閲覧したい場合、閲覧端末104にログインした上で、閲覧端末104の画面上でそのeDocの閲覧を指示する。この指示を受けた閲覧端末104は、アクセス可能な処理装置110、又は管理システム200、にアクセスしてそのeDocのメタデータを要求する。この要求には、そのeDocのDIDが含まれる。

0052

この要求を受けた処理装置110は、そのDIDに対応するメタデータの最新版を管理システム200から取得し、その閲覧端末104に送信する。なお、管理システム200(特にメタデータサーバ230)がその要求を受ける構成の場合には、管理システム200がそのDIDに対応するメタデータの最新版をその閲覧端末104に送信する。なお、処理装置110に対するユーザの操作によりメタデータに変更(例えばアクセス権限情報の変更)が加えられた場合、その変更は管理システム200に伝達され、管理システム200は自身が持つそのメタデータに対してその変更を反映させる。これにより、管理システム200は、常に、保護済みドキュメントのメタデータの最新版を有する。

0053

ここで、保護済みドキュメントの閲覧指示を受けた閲覧端末104にとってすぐに必要なのは、メタデータのうちの配信先情報とアクセス権限情報なので、処理装置110又は管理システムは、その要求に応じて閲覧端末104に対して、アクセス権限情報のみを送信してもよい。なお、配信先情報は、例えば、その保護済みドキュメントの配信先として指定されたユーザIDのリストを含む。また、配信先情報は、ユーザIDと端末IDのペアのリストを含む場合もある。またアクセス権限情報は、例えば、その保護済みドキュメントの配信先情報に含まれる各ユーザIDに対応付けてそのユーザが持つ権限(例えば、閲覧のみ可能、又は閲覧と編集が可能等)の内容を示す情報を含む。

0054

閲覧端末104は、要求したメタデータを受信すると、そのメタデータに含まれる配信先情報に、当該閲覧端末104と現在この閲覧端末104を利用しているユーザとの組合せが含まれるかどうかを判定する。含まれていない場合、そのユーザはその閲覧端末104でそのeDocを閲覧する権限がないので、閲覧端末104はeDocファイルを開かず、閲覧権限がない旨を示すエラーメッセージを表示する。含まれる場合は、そのユーザはその閲覧端末104でそのeDocファイルを閲覧する権限を持つ。この場合閲覧端末104は、そのeDocファイルをそのメタデータに含まれる鍵情報を用いて復号し、そのeDocファイルの復号結果の情報内容に応じた態様で出力する。

0055

メタデータが最初の管理システム200に登録された後、そのメタデータに含まれる配信先情報やアクセス権限情報が配信者、又は配信先の変更権限が与えられた者(例えばデータの編集権限を保有する者)により変更されることがある。eDocが作成・登録された時点で配信先に指定されたユーザであっても、その後の変更により配信先から外された場合には、閲覧端末104は、管理システム200から取得した最新のメタデータに含まれる配信先情報によりそのことを検知し、eDocファイルの表示を行わない。

0056

図1は、処理装置110群と管理システム200の2階層の階層構造を持つシステムであったが、新たな管理システムの階層を挿入することで、3階層以上のシステムとすることもできる。図2に3階層のシステムを例示する。

0057

図2に示す例では、企業等の組織のプライベートネットワークである組織内ネットワーク内にローカルシステム100が複数存在する。そして、組織内ネットワークには、組織内管理システム150が設けられている。組織内管理システム150は、ドキュメント管理システムのうち当該組織内の処理やそれに必要な情報を管理する。すなわち、管理システム200は、ドキュメント管理システムのサービスプロバイダ運用し、ドキュメント管理システムを利用する複数の組織についての情報や処理を管理するのに対し、組織内管理システム150はそれら情報や処理のうち当該組織に関する部分を、管理システム200の管理下で管理する。

0058

組織内管理システム150は、ローカルユーザIDサーバ152、ローカルDIDサーバ154、及びローカルメタデータサーバ156を有する。

0059

ローカルユーザIDサーバ152は、当該組織のメンバのうちドキュメント管理システムにユーザ登録されているユーザの情報を管理する。ローカルユーザIDサーバ152が保持する個々のユーザの情報は、ユーザIDサーバ210が保持する一般ユーザの情報と同様である。処理装置110に対して、その処理装置110を取得し利用するユーザ(すなわちその処理装置110を「既定の処理装置」とするユーザ)が登録されると、処理装置110は登録されたユーザの情報を組織内のローカルユーザIDサーバ152に送る。ローカルユーザIDサーバ152は、受け取ったユーザの情報を保存すると共に、広域ネットワーク300経由で中央の管理システム200のユーザIDサーバ210に送る。ユーザIDサーバ210は、受け取ったユーザの情報を保管する。また、処理装置110に登録されたユーザの情報に変更が生じた場合、管理者等が処理装置110に対してそのユーザの情報の変更を行う。処理装置110は、このユーザ情報変更内容の情報(例えばユーザIDと、変更された情報項目の項目名と、その項目の変更後の値とを含む)をローカルユーザIDサーバ152に送信し、ローカルユーザIDサーバ152は、受信した変更に内容に応じて自身が保管している当該ユーザの情報を変更する。また、ローカルユーザIDサーバ152は、受け取った変更内容の情報を中央のユーザIDサーバ210に送り、ユーザIDサーバ210は送られてきた情報に応じて、自分が保持するそのユーザの情報を変更する。

0060

ローカルDIDサーバ154は、当該組織の組織内ネットワークに属する各ローカルシステム100内の処理装置110が発行したDIDを受け取り、保管する。ローカルDIDサーバ154が保持する情報は、DIDサーバ220が保持する情報と同様である。またローカルDIDサーバ154は、処理装置110から受け取ったDIDの情報を中央のDIDサーバ220に送り、DIDサーバ220はその情報を保管する。また、ローカルDIDサーバ154は、中央のDIDサーバ220からDIDの発行権限及び発行枠を付与され、その発行枠の範囲内で、その発行権限に基づいて管理下の各処理装置110に対してDIDの発行権限及び発行枠を付与する。

0061

ローカルメタデータサーバ156は、当該組織の組織内ネットワークに属する各ローカルシステム100内の処理装置110が生成したeDocのメタデータを受け取り、保管する。ローカルメタデータサーバ156が保持する情報は、メタデータサーバ230が保持する情報と同様である。またローカルメタデータサーバ156は、処理装置110から受け取ったメタデータを中央のメタデータサーバ230に送り、メタデータサーバ230はそのメタデータを保管する。

0062

以上に例示した図1及び図2のシステムにおいて、処理装置110がeDocと共に生成したメタデータの全部の項目の値が上位の装置、すなわち組織内管理システム150や管理システム200に登録されると、不都合な場合がある。例えば、処理装置110が設置されている部署における部署内限定の極秘情報が、eDocのメタデータ内に含まれる場合、その部署は、その極秘情報を上位の組織内管理システム150や管理システム200に開示することを望まない。同様に、組織の秘密事項がメタデータに含まれる場合、その組織は、その秘密事項を組織外にある管理システム200に開示することは望まない。

0063

そこで、本実施形態では、メタデータの項目のうち下位の装置(例えば処理装置110)が秘密にしたい項目が上位の装置(例えば管理システム200)に登録されないように制御する。

0064

このドキュメント管理システム、特にそのうちのメタデータを管理する機構が、データ管理システムの一例である。

0065

この制御について説明する前に、本実施形態におけるメタデータの項目構成の例を、図3を参照して説明する。

0066

図3に例示するメタデータに含まれる項目群は、書誌情報、基本アプリ関連情報アクセスログ情報拡張情報、という4つの種別に大別される。個々のeDocのメタデータには、これら4つの種別の項目群が含まれ得る。

0067

書誌情報は、当該メタデータに対応するeDocについての書誌を示す情報である。書誌情報には、当該メタデータに対応するeDocのDID、契約識別情報、ドキュメント名、配信者ID、エンコード日時、処理装置、等の項目が含まれる。契約識別情報は、そのeDocを生成した処理装置110が所属する組織が、中央の管理システム200の運営者と結んでいる、本実施形態のシステムの利用のための契約を識別する識別情報である。またドキュメント名はそのeDocのファイル名である。配信者IDは、そのeDocを処理装置110に対して登録したユーザのユーザIDである。エンコード日時は、そのユーザからの登録指示に応じてeDocが作成(すなわちエンコード)された日時であり、処理装置IDは、そのeDocを作成した処理装置110の識別情報である。

0068

基本アプリ関連情報は、eDocに対して本実施形態のシステムが提供するサービス(基本アプリと呼ぶ)が用いる情報である。基本アプリ(ここで「アプリ」は、アプリケーションの略)には、eDocの配信、配信されたeDocに対するユーザのアクセス管理(例えば閲覧等の可否の管理)等がある。基本アプリ関連情報には、例えばアクセス権限情報、配信先情報、暗号化情報キーワード情報オフライン有効期間などの項目が含まれる。アクセス権限情報、配信先情報については既に説明した。暗号化情報は、暗号化されているeDocを復号するための鍵を示す情報である。eDocは、所定形式にエンコードしたドキュメントをある鍵で暗号化したものであるが、暗号化情報は、配信先ユーザのそれぞれについて、暗号化に用いたその鍵をその配信先ユーザの公開鍵で暗号化した鍵情報を含む。キーワード情報は、本実施形態のシステムが提供する簡易的な検索サービスに用いられる、当該eDocの検索用キーワード(すなわち検索インデックス)群を含む。なお、ここでいう「簡易的な検索サービス」は、後述する外部アプリの1つが提供する高度な検索サービスとの比較のための用語である。オフライン有効期間は、閲覧端末104が既に取得済みのメタデータ中のアクセス権限情報及び配信先情報が有効である期間の長さである。閲覧端末104が処理装置110、組織内管理システム150又は管理システム200等からそのメタデータを取得した時点から、オフライン有効期間の長さの期間内では、閲覧端末104は、その取得済みのメタデータ内のアクセス権限情報及び配信先情報を用いて、そのメタデータに対応するeDocに対するユーザのアクセスを制御する。一方、取得済みのメタデータ内のオフライン有効期間が過ぎた時点でユーザからそのeDocに対する閲覧等のアクセスが要求された場合には、閲覧端末104は、最寄りの処理装置110、組織内管理システム150又は管理システム200からそのメタデータの最新版の情報を取得する。そして、これに応じて取得した最新版の情報に従って、その要求に係るアクセスを許可するか否かを制御する。

0069

アクセスログ情報は、当該メタデータに対応するeDocへのユーザからのアクセスについてのログ情報である。アクセスログ情報には、例えばユーザからeDocへのアクセスがあるごとに、アクセス日時、アクセス種別(例えば閲覧、編集等)、そのユーザのユーザID(すなわち項目「アクセス者」)等の項目が互いに対応付けて追加される。

0070

拡張情報は、メタデータの項目のうち外部アプリが用いる項目群のことである。本実施形態のシステムの運営者以外の者が、運営者の許可を受けて、そのシステムを介してユーザ側に提供するサービスが外部アプリである。拡張情報には、外部アプリが実行する処理の材料となる情報を含む項目、又は外部アプリの処理結果を保持する項目、が含まれ得る。図3には、前者の例として、高度な検索サービスを提供するいくつかの外部アプリが検索のために用いる高度検索用インデックス分野別翻訳サービスを提供する外部アプリがその翻訳のために利用する分野別翻訳用処理データ、を例示している。また、後者の例として、ある外部アプリAの処理結果を保持する項目を示している。

0071

次に、図4を参照して、本実施形態のシステムの階層構造の例を説明する。図4は、特にメタデータの管理の観点から、メタデータサーバ(図ではMDSと表記)の階層構造を示している。しかし、MDSと同じ階層には、そのMDSと共に管理を担う、ユーザIDサーバ、DIDサーバ等が存在する。

0072

図4に例示する階層構造は、図1及び図2に例示したシステムよりも多い、レベル0〜4の5つの階層を有する。

0073

最上位の階層であるレベル0は、本実施形態のシステムの運営者が管理する中央MDS230aの階層である。中央MDS230aは、全世界で唯一のMDSであり、全世界にある全ての処理装置110が生成したメタデータ群を記憶する。ただし、中央MDS230aが記憶するのは、それらメタデータの全項目ではなく、それら項目うち、中央MDS230aに記憶することが許された項目のみである。中央MDS230aは、このシステムにおける最上階層の装置に該当する。

0074

上から2番目の階層であるレベル1は、国や地域等の管理単位ごとに設けられたMDS230bが属する階層である。MDS230bは、その管理単位に属する各組織内の処理装置110が生成したメタデータ群を記憶する。ただし、MDS230bが記憶するのは、それらメタデータの全項目ではなく、それらの項目うち、MDS230bに記憶することが許された項目のみである。

0075

上から3番目の階層であるレベル2は、国や地域等の管理単位内に存在する組織(例えば企業)に設置されたローカルMDS156aの階層である。ローカルMDS156aは、当該組織内の最上位のMDSであり、その組織全体のメタデータを管理する。すなわち、ローカルMDS156aは、その組織内の処理装置110が生成したメタデータ群を記憶する。ただし、ローカルMDS156aが記憶するのは、それらメタデータの全項目ではなく、それら項目うち、ローカルMDS156aに記憶することが許された項目のみである。

0076

上から4番目の階層であるレベル3は、組織内での2番目の階層であり、例えばその組織内の管理単位ごとに設けられたローカルMDS156bを含む。組織内の管理単位には、例えばその組織が有する拠点、例えば本社、支社営業所工場、研究所等、がある。

0077

図4の例は、組織が大規模であるため、組織内管理システムの階層を2階層にしている。管理単位のローカルMDS156bは、当該管理単位全体のメタデータを管理する。すなわち、ローカルMDS156bは、その管理単位(例えば組織内の1拠点)内の処理装置110が生成したメタデータ群を記憶する。ただし、ローカルMDS156bが記憶するのは、それらメタデータの全項目ではなく、それら項目うち、ローカルMDS156bに記憶することが許された項目のみである。

0078

なお、本実施形態のシステムの運営者の委託を受けてサービスを提供するサービスプロバイダ(又はサービスの販売会社)があり、そのサービスプロバイダが例えば中小企業等の顧客組織にサービスを提供する場合が考えられる。この場合、サービスプロバイダと顧客組織とからなる集合を1つの組織と捉えることができる。この例では、個々の顧客組織にレベル3のローカルMDS156bが設けられ、サービスプロバイダにそれらローカルMDS156bを統括するレベル2のローカルMDS156aが設けられる。

0079

最下層であるレベル4は、メタデータを生成し、保存する処理装置110が属する階層である。処理装置110は、基本的には、自身が生成したメタデータの全項目を記憶する。ただし、メタデータの項目のうち所定の項目群については処理装置110内に記憶しないように設定することも可能である。処理装置110は、このシステムにおける最下階層の装置に該当する。

0080

各階層の装置は、それぞれ、階層構造における自装置の直接の上位の装置のアドレス情報を記憶している。例えば、処理装置110は、階層構造において自分の上位の装置である、レベル3のローカルMDS156b(又はこれを含むレベル3の組織内管理システム)のアドレス情報を有する。また例えばローカルMDS156bは、階層構造において自分の上位である、レベル2のローカルMDS156b(又はこれを含むレベル2の組織内管理システム)のアドレス情報を有する。各階層の装置は、その上位の装置のアドレス情報を用いて、メタデータを上位の装置にアップロードする場合等、上位の装置と通信する場合に、そのアドレス情報を用いる。

0081

次に、図4の各レベルの装置がそれぞれメタデータの項目群のうちのいずれの項目の実体データを記憶するかという記憶構成の例を、図5を参照して説明する。

0082

記憶構成の基本的な考え方は、階層すなわちレベルが高くなるほど、その階層の装置が実体データを記憶する項目を少なくするというものである。図5の例は、図3に示したメタデータの項目群の種別のうち、種別IDの番号が大きいものほど、ユーザ側(すなわち組織やその組織内の拠点、部署)にとって秘密度合いが高い場合の例である。

0083

ここで、メタデータの項目の「実体データ」とは、そのメタデータのうちのその項目の実体的な値である。これに対して、後述するリンク情報は、当該項目の実体データを指し示す情報である。

0084

最下層であるレベル4の処理装置110は、メタデータ及びそのメタデータに対応するeDoc本体を生成し記憶する装置なので、基本的にメタデータの全項目を記憶する。図5の例では、レベル4の処理装置110は、書誌情報、基本アプリ関連情報、アクセスログ情報、拡張情報の4つの種別に属する全ての項目を記憶する。なお、図5では、各レベルの装置が記憶するメタデータ項目の種別を太字で示した。

0085

また図5の例では、レベル3のローカルMDS156bは、書誌情報、基本アプリ関連情報、アクセスログ情報に属する項目群は記憶するが、拡張情報に属する項目群は記憶しない。この例は、拡張情報に属する項目群が、処理装置110の設置された部署の外には秘密である場合のものである。

0086

また図5の例では、レベル2のローカルMDS156aは、書誌情報、基本アプリ関連情報に属する項目群は記憶するが、アクセスログ情報及び拡張情報に属する項目群は記憶しない。この例は、アクセスログ情報に属する項目群が、ローカルMDS156aの設置された拠点の外には秘密である場合のものである。

0087

そして、組織の外にあるレベル1のMDS230b及びレベル0の中央MDS230aは、書誌情報の一部の項目群は記憶するが、書誌情報の残りの部分、基本アプリ関連情報、アクセスログ情報及び拡張情報に属する項目群は記憶しない。この例は、書誌情報のうちの一部の項目と、基本アプリ関連情報に属する項目群が、組織の外には秘密である場合のものである。

0088

以上に説明した図5の例では、主としてメタデータ項目の種別を単位として、上位の階層のMDSほど、記憶するメタデータ項目の種別が少なくなった。しかし、種別を単位とするのは一例に過ぎない。各階層のMDSがどの項目を記憶するかは、項目単位で規定可能である。例えば、レベル0及び1に属する中央MDS230a及びMDS230bは、基本的には基本アプリ関連情報の種別に属する項目は記憶しないが、そのうちアクセス権情報及び配信先情報という2つの項目は記憶する、等のいった項目単位での制御が可能である。

0089

図5に例示したように、階層が上がるにつれて、装置が実体データを記憶しているメタデータの項目が少なくなっていく記憶構成のことを、メタデータのエスカレーションと呼ぶ。

0090

次に、図6及び図7を参照して、いくつかのレベル(すなわち階層)のMDSが記憶するメタデータのデータ内容を説明する。

0091

図6は、レベル1のMDS230bが記憶するメタデータのデータ内容を説明するための図である。図において、「項目ID」は、1つのeDocのメタデータに含まれる各項目のID(すなわち識別情報)である。図示例では、わかりやすさ優先して、各項目の名称を項目IDの欄に示している。「種別」は、それら各項目が属する種別を示す。そして「項目内容」は、MDS230bが記憶している当該項目のデータ内容である。

0092

図6の例では、MDS230bは、書誌情報の種別に属する項目「DID」及び「契約識別情報」と、基本アプリ関連情報の種別に属する項目「アクセス権限情報」及び「暗号化情報」とについては、当該項目についての実体データを記憶している。例えば、MDS230bは、DIDについては実際のDIDの値を、契約識別情報については実際の契約識別情報の値を記憶している。項目内容に実体データが記憶されている項目は、当該MDSにとっての記憶対象の項目である。

0093

これに対し、書誌情報のうちDIDと契約識別情報を除く残りの項目については、MDS230bは、項目内容として、当該項目の実体データの代わりにリンク情報を記憶している。項目のリンク情報は、包括的に言えば、当該項目の実体データを特定する情報である。この例では、項目のリンク情報は、階層構造において当該MDSの直下に位置する下位装置(すなわちMDS又は処理装置)に記憶されている、当該項目の項目内容を指し示す情報である。ここで、ツリー状に構成されたMDS及び処理装置の階層構造において、あるMDSの「下位装置」とは、その階層構造におけるそのMDSの子ノードに該当する装置のことである。例えばMDS230bが持つあるメタデータ内のある項目の項目内容であるリンク情報は、MDS230bの子であるレベル2のローカルMDS156a群のうち、そのメタデータを持つMDS230b内の、そのメタデータのその項目の項目内容を指し示す。リンク情報が指し示す下位装置の項目内容は、当該項目の実体データである場合もあれば、更なるリンク情報である場合もある。後者の場合も、リンク情報の指し示す先のリンク情報、更にこれが指し示すリンク情報と、連鎖的にリンク情報をたどることで、最終的に当該項目の実体データを取得することができる。この意味で、図示例のリンク情報も、当該項目の実体データを特定する情報である。

0094

例えば、リンク情報は、下位装置のネットワーク上での位置を示す情報と、その下位装置内に記憶されたそのメタデータ内の当該項目を識別する情報とを含むものである。ここで、メタデータ内の当該項目を識別する情報は、そのメタデータの識別情報と、その項目の識別情報との組合せであってもよい。メタデータの識別情報には、例えばそのメタデータに対応するeDocのDIDを用いる。また、項目の識別情報は、例えばDID、契約識別情報、ドキュメント名、ユーザID等といった個々の項目を一意に識別する情報である。この例では、メタデータの識別情報と項目の識別情報との組合せにより、特定のメタデータ内の特定の項目が識別される。

0095

具体的な例では、リンク情報はURI(Uniform Resource Identifier)又はURL(Uniform Resource Locator)等の形式記述される。あるMDS230bの下位装置であるローカルMDS156aのホスト名が例えば「eduser.sample.com」である場合において、MDS230b内にある、DIDが「xxxx」であるeDocのメタデータ内の項目「yyyy」の項目内容であるリンク情報は、例えば「data://eduser.sample.com/intApr?DID=xxx&AprID=yyyy」となる。

0096

なお、リンク情報の記述形式はURIやURLに限らない。例えば上に例示したURLと同内容をSQLクエリとして記述した場合、「SELECT `DID`,`did` FROM `metadata3` WHERE `AprID`,`xxx`」となり、MDS230bはそのリンク情報を参照し、下位装置に対してそのクエリを送ることで、そのメタデータの項目の項目内容を取得する。

0097

リンク情報は、項目単位のものであってもよいし、複数の項目からなるグループ単位のものであってもよい。図6の例では、書誌情報に属するドキュメント名から処理装置IDまでの4項目からなるグループについて、下位装置内のそのグループを指し示すリンク情報が記述されている。

0098

図7に示す例は、レベル2のローカルMDS156aが記憶するメタデータのデータ内容を説明するための図である。レベル1のMDS230aが記憶するメタデータ(図6参照)と比較すると、ローカルMDS156aが記憶するメタデータは、書誌情報内のドキュメント名から処理装置IDまでの4つの項目について実体データを含んでいる点が異なる。なお、アクセスログ情報の項目内容はリンク情報となっているが、このリンク情報は、下位装置であるレベル3のローカルMDS156b内の、当該メタデータ内のアクセスログ情報の項目内容を指し示す。

0099

さて、本実施形態のシステムでは、図5に例示したような階層間の記憶構成を実現するために、処理装置110、ローカルMDS156,156a,156b、及びMDS230b等の各装置は、メタデータが含む項目のうち、それぞれ上位の装置(すなわちツリー状の階層構造における当該処理装置110の親のノードに該当する装置)にアップロード(すなわち送信)すべき項目を示すメタデータ管理情報を有している。すなわち、メタデータ管理情報にて、アップロードすべき項目として示されていない項目は、上位の装置に対して実体データを秘密にすべき項目である。各装置は、記憶しているメタデータのうち、メタデータ管理情報に示される項目の実体データを、当該装置の上位の装置にアップロードする。

0100

次に、図8を参照して、ユーザの作成端末102からドキュメントの登録要求を受けたときの処理装置110が実行する処理手順の例を説明する。

0101

この手順では、処理装置110は、まずそのドキュメントのeDoc化処理を実行する(S10)。すなわち、例えば、そのドキュメントを本システムの専用フォーマットへとエンコードし、エンコード結果を暗号化することで、eDocファイルを生成する。また処理装置110は、そのeDocのメタデータを生成し、そのメタデータのうち実体データを取得可能な項目については、その実体データをその項目の値として記憶する(S12)。次に処理装置110は、自装置が有するメタデータ管理情報を参照することで、先ほど作成して記憶したメタデータの各項目のうち、実体データを、階層構造において当該処理装置110の上位のローカルMDS156bにアップロードすべき項目を特定する(S14)。そして、作成したメタデータのうち、特定した項目の実体データを、そのメタデータの識別情報及びその項目の識別情報と対応付けて、そのローカルMDS156bにアップロードする(S16)。

0102

なお、作成したメタデータ内の項目のうち、アップロードがなされなかった項目の実体データは、本実施形態のシステム全体において、その処理装置110のみが記憶していることとなる。

0103

次に図9を参照して、下位装置からメタデータのアップロードを受けた装置の処理手順の例を説明する。この処理手順を実行する装置は、階層構造のうち、最下位(すなわち処理装置110)と最上位(すなわち中央MDS230a)を除いた残りの装置、すなわちローカルMDS156a,156b及びMDS230aである。

0104

この手順では、装置は、下位装置から登録対象のメタデータのアップロードを受け付け、そのメタデータに含まれる各項目の実体データを取得する(S20)。次に、装置は、アップロードされたメタデータを、内蔵するデータベースに登録する(S22)。S22では、装置は、アップロードされたメタデータのためのエントリをデータベース内に作成し、そのエントリの各項目に対し、アップロードされたメタデータに含まれる当該項目の実体データを登録する(S24)。

0105

また装置は、下位装置から実体データがアップロードされなかった項目についてのリンク情報を生成し、そのリンク情報を当該メタデータの当該項目の項目内容として、データベースに登録する(S26)。アップロードのための通信により、下位装置のホスト名がわかり、またメタデータを識別するDIDはアップロードされるデータに含まれている。これらの情報と、実体データがアップロードされなかった項目の情報から、リンク情報が生成可能である。

0106

次に装置は、自装置が有するメタデータ管理情報を参照することで、下位装置からアップロードされたメタデータの各項目のうち、階層構造において当該装置の上位の装置に実体データをアップロードすべき項目を特定する(S26)。そして、特定した項目の実体データを、そのメタデータの識別情報及びその項目の識別情報と対応付けて、その上位装置にアップロードする(S28)。

0107

階層構造を構成する処理装置110、ローカルMDS156a及び156b、MDS230aが、それぞれ図8又は図9に示す処理を行うことで、図5に例示したメタデータのエスカレーションが実現される。

0108

図9の手順では、下位装置からメタデータの各項目の実体データのアップロードを受けたMDSが、実体データがアップロードされなかった項目についてのリンク情報を作成した。別の例として、下位装置が、上位のMDSに実体データをアップロードしない項目又は項目のグループについてのリンク情報を生成し、生成したリンク情報を、実体データと共に上位のMDSにアップロードしてもよい。この場合、MDSは、下位装置からアップロードされた各項目の実体データ及びリンク情報を、内蔵するデータベースに記憶すればよい。

0109

次に、本実施形態のシステムにおけるメタデータの検索処理について説明する。

0110

処理装置110は、ユーザの端末(例えば閲覧端末104)からメタデータの検索要求を受け付ける。検索要求には、検索条件が含まれる。検索条件は、ユーザが欲するメタデータが満たすべき条件である。1つの例では、検索条件は、ユーザが欲するメタデータに含まれる各項目が満たすべき条件の論理式として表現される。例えば、ユーザが特定のeDocのメタデータを欲している場合には、検索条件は、そのeDocのDIDの値をメタデータの項目「DID」の値として含む、というものとなる。また、検索要求には、検索条件に付随して、検索結果として得たい1以上の項目を指定する検索項目情報が含まれていてもよい。ユーザは、検索結果としてメタデータ全体を得たい場合もあれば、メタデータ中の特定の1以上の項目のみを得たい場合もある。例えば、ユーザが得たい項目(すなわち検索対象の項目)の項目IDのリストが、検索項目情報となる。

0111

処理装置110は、ユーザの端末から検索要求を受けた場合、その検索要求を、レベル3の階層にある、自分の上位の装置であるローカルMDS156bに転送する機能を有する。例えば、処理装置110が、ユーザから指定差入れた検索要求に示されるDIDを含むメタデータを記憶していない場合、そのメタデータは他の処理装置110で作成されたeDocのメタデータなので、上位に検索要求を転送するのである。

0112

下位の処理装置110から検索要求の転送を受けたローカルMDS156bは、その検索要求中の検索条件を満たすメタデータが、自分の内蔵するデータベース内にあるかどうかを調べ、もしなければ、その検索要求を自装置の上位のローカルMDS156aに転送する。

0113

また、ローカルMDS156bは、その検索要求中の検索条件を満たすメタデータが、自分の内蔵するデータベース内にある場合には、そのメタデータを、転送元の処理装置110経由で、又は直接、検索要求を出したユーザの端末に提供する。前者の場合、ローカルMDS156bは、その処理装置110に対してそのメタデータを応答し、これを受け取ったその処理装置110が、そのメタデータを要求元の端末に送信する。後者の場合、検索要求には、要求元であるユーザの端末のアドレス情報が含まれており、ローカルMDS156bはそのアドレス情報を用いてその端末に対してそのメタデータを送信する。

0114

ここで、その検索要求中の検索条件を満たすメタデータが、ローカルMDS156bのデータベース内にある場合でも、そのメタデータの一部の項目の実体データがない場合がある。その場合、そのデータベースには、その項目の項目内容として実体データの代わりにリンク情報が含まれる。ローカルMDS156bはそのリンク情報を用いて、その項目の実体データが、検索要求を出したユーザの端末に提供されるようにするための制御を行う。

0115

この制御では、ローカルMDS156bは、そのリンク情報を用いて、例えば、そのリンク情報が指し示す(すなわちそのリンク情報のリンク先)データに対する要求を発する。この要求は、そのリンク情報が示す下位の処理装置110に送られる。この下位の処理装置110は、そのリンク情報が示す項目の実体データを持っており、その実体データをローカルMDS156bに返す。ローカルMDS156bは、返された実体データを、検索要求の転送元の処理装置110(すなわちユーザから検索要求を受け付けた装置)経由で、あるいは直接、検索要求元のユーザの端末に提供する。

0116

またその制御の別の例では、ローカルMDS156bは、そのリンク情報が示す下位の処理装置110に対して、その検索要求を転送する。転送された検索要求を受け取ったその下位の処理装置110は、その検索要求の検索条件を満たす管理データの、検索項目情報が示す各項目の実体データを、直接、又は転送元のローカルMDS156を経由して、検索要求元のユーザの端末に提供する。

0117

また、レベル3のローカルMDS156から検索要求の転送を受けた、レベル2にある上位のローカルMDS156aは、その検索要求中の検索条件を満たすメタデータが、自分の内蔵するデータベース内にあるかどうかを調べ、もしなければ、その検索要求をレベル2の階層にある自装置の上位のMDS230bに転送する。また、検索条件を満たすメタデータが、自分の内蔵するデータベース内にある場合、検索項目情報が示すユーザの欲する項目の実体データがそのデータベース内にあるならば、その項目の実体データを、直接、又は転送元のローカルMDS156bを経由して、検索要求元のユーザの端末に提供する。後者は、言い換えれば、検索要求が転送された経路を逆にたどって、メタデータをユーザの端末に転送することである。また、ローカルMDS156aは、転送された検索要求中の検索条件を満たすメタデータが、自分の内蔵するデータベース内にある場合でも、検索項目情報が示すユーザの欲する項目の実体データがそのデータベース内にない場合には、その項目に対応するリンク情報を用いて、その項目の実体データが、検索要求を出したユーザの端末に提供されるようにするための制御を行う。この制御は、レベル3のローカルMDS156bの場合と同様でよい。

0118

このように、各レベルのMDSは、検索要求を上位又は下位の装置に転送することで、検索要求が求める検索結果を得る。

0119

以下に、検索のための処理装置110、ローカルMDS156a及び156b、MDS230a及び200bが実行する手順の例を説明する。以下では、検索条件としてDIDが指定されている場合を例に取る。

0120

例えば、ユーザが閲覧端末104に対して、閲覧端末104内に記憶されたあるeDocの閲覧を要求したり、そのeDocについてのメタデータの同期を指示したりした場合、閲覧端末104は、アクセス可能な処理装置110に対して、そのメタデータの最新版を要求する。この要求は、そのeDocを特定する情報としてDIDを含む。従って、この要求は、検索条件としてDIDが指定されている検索要求の一例である。

0121

図10は、その検索要求を受け取った処理装置110が実行する処理手順の一例を示す。この手順では、検索要求を受け取った処理装置110は、検索要求中の検索条件が示すDIDの値を読み取り、その値を項目「DID」の項目内容として持つメタデータを、内蔵するデータベースから検索する。そして、その検索条件を満たすメタデータがデータベース内から検索できたかどうかを判定する(S30)。検索できた場合、処理装置110は、その検索できたメタデータを、要求元の閲覧端末104に応答する(S32)。処理装置110のデータベースには、基本的に、メタデータ内の全ての項目の実体データが記憶されているので、処理装置110に対してメタデータの全項目の実体データを提供可能である。

0122

S30の判定結果がNoである場合、処理装置110は、その検索要求の検索条件であるDIDを持つメタデータを記憶していない。そのメタデータは、他の処理装置110が生成したeDocのメタデータである。この場合、処理装置110は、階層構造における上位のローカルMDS156bに対して、その検索要求を転送する(S34)。

0123

またこの例では、処理装置110から転送された検索要求を受け取ったローカルMDS156bは、図11に示す処理手順を実行する。レベル2のローカルMDS156a、レベル1のMDS230b、及びレベル0のMDS230aも同様の処理手順を実行する。以下、以下の図11の処理手順を説明する。以下の説明では、ローカルMDS156b、ローカルMDS156a、MDS230b、及びMDS230aを、「MDS」と総称する。

0124

図11の手順では、下位の装置から転送された検索要求を受け取ったMDSは、その検索要求中の検索条件が示すDIDの値を読み取り、その値を項目「DID」の項目内容として持つメタデータを、内蔵するデータベースから検索する。そして、その検索条件を満たすメタデータがデータベース内から検索できたかどうかを判定する(S40)。検索できた場合、MDSは、データベース内のそのメタデータが、検索要求中の検索項目情報が示す検索対象のすべての項目の実体データを含んでいるかどうかを判定する(S42)。S42の判定結果がYesの場合、MDSは、検索したそのメタデータのうちの検索対象の項目の実体データを要求元の閲覧端末104に応答する(S44)。この応答は、MDSが直接行ってもよいし、検索要求の転送の経路を逆にたどって行ってもよい。

0125

S42の判定結果がNoの場合、検索対象の項目のうちそのMDSが実体データを持っていない項目については、MDSはリンク情報を持っている。MDSは、そのリンク情報が示す下位装置に対して、その検索要求を、転送する(S46)。

0126

S40の判定結果がNoの場合は、MDSは、上位の装置に対してその検索要求を転送する(S48)。

0127

S46で当該MDSから検索要求の転送を受けた装置が処理装置110である場合、その処理装置110は、その検索要求の対象であるメタデータのすべての項目の実体データを持っているはずである。したがって、その処理装置110は、そのメタデータのうちの検索対象の項目の実体データを、直接に、又は検索要求の転送の経路を逆にたどって、要求元の閲覧端末104に応答する。

0128

S46で当該MDSから検索要求の転送を受けた装置が別のMDSである場合、当該別のMDSは、図11の処理を実行する。ただし、この場合、当該別のMDSは、検索要求の対象であるメタデータのすべての項目の実体データを持っているはずなので、S40及びS48の処理は不要である。

0129

S48で当該MDSから検索要求の転送を受けた装置が別のMDSである場合、当該別のMDSは、図11の処理を実行する。

0130

転送された検索要求を受け取ったMDSが実行する処理手順の別の例を、図12を参照して説明する。図12の手順において、図11の手順と同様のステップには,同一符号を付した。

0131

図12の手順では、MDSは、S42の判定結果がNoの場合、検索対象の項目のうちMDS自身(以下では「注目するMDS」と呼ぶ)が持っていない項目の実体データを、下位装置から取得する(S50)。すなわち、この場合、注目するMDSは、そのMDS自身が持っていない項目についてのリンク情報を持っているので、そのリンク情報を用いて、下位装置に対して、それら項目についての実体データを要求する。この要求を受けた下位装置は、その項目の実体データを持っていれば、その実体データを要求元の上位のMDSに応答し、持っていなければ、その下位装置が有するリンク情報を用いて、更なる下位装置に対してその項目の実体データを要求する。このようにリンク情報を用いて下位の装置へと要求を伝播していくことで、最終的にその項目の実体データにたどり着き、その実体データがその伝搬の経路の逆の経路で、注目するMDSへともたらされる。このようにして注目するMDSは、検索要求が求めているメタデータの項目の実体データを入手する。そして、このMDSは、それらの項目の実体データを、直接、又はS40で取得した検索要求が転送されてきた経路を逆にたどって、要求元のユーザの閲覧端末104に応答する(S44)。

0132

以上に説明したように、ドキュメント管理システムは、複数の処理装置110と各レベルのMDSという階層構造をなす複数の装置から構成される。

0133

ここで、処理装置110及びMDSは、それぞれ各eDocのメタデータを記憶するデータベースを有する。このデータベースは記憶手段の一例である。また、またMDSは、自身が内蔵するそのデータベースから、検索等に必要なメタデータ内のリンク情報を取得する機能を有しており、この機能が取得手段の一例である。また、MDSは、階層構造上の下位装置(すなわち処理装置110又は下位のMDS)から送信されてくるメタデータの項目群の実体データを受信する機能を有しており、この機能が受信手段の一例である。また、処理装置110及びMDSは、メタデータの項目群のうち、上位の装置に実体データを送信すべき項目を規定する情報を保持しており、下位の装置から受信したメタデータのうち、その情報に規定される項目の実体データを上位の装置に送信する。この送信の機能が、送信する手段の一例である。

0134

また、MDSは、下位装置から受信したメタデータの項目群の実体データと、実体データを受信しなかった項目についてのリンク情報とを、メタデータの識別情報(すなわちDID)と対応付けてデータベースに格納する機能を有する。この機能が、格納制御手段の一例である。この機能は、下位装置から受信したメタデータの情報から、リンク情報を生成する機能を含んでいてもよい。

0135

またMDSは、ユーザの端末又は他の装置(すなわち処理装置110又は他のMDS)から検索要求を受信する機能を有しており、この機能が、検索要求を受信する手段の一例である。またMDSは、図11及び図12に示したS46、S48及びS50等に例示するように、他の装置から受信した検索要求を上位又は下位の装置に転送する機能を有しており、この機能は検索制御手段の一例である。

0136

以上、本発明の実施形態について説明したが、以上に例示した実施形態はあくまで例示的なものにすぎない。

0137

以上の実施形態では、MDSが持つメタデータ内の項目(又は項目のグループ)のリンク情報(例えば図6参照)は、当該MDSの下位装置における当該項目(又は項目のグループ)の項目内容を指すものであり、その項目内容はリンク情報である場合もあった。これに対して、別の例として、MDSが持つメタデータのリンク情報は、項目ごと又はグループごとではなく、メタデータ全体を単位とするものであってもよい。この場合のリンク情報は、当該メタデータを記憶しているその下位装置を特定する情報(例えばアドレス情報)と、そのメタデータの識別情報として機能するDIDとを含む。

0138

また更に別の例として、MDSが持つメタデータの項目又はグループについてリンク情報は、そのメタデータの下位装置(すなわちツリー状の階層構造における子の装置)内の情報を指す代わりに、階層構造におけるそのMDSの子孫装置群のいずれかに記憶されているその項目又はグループの実体データを指すものであってもよい。例えば、MDSが持つあるメタデータのリンク情報は、そのMDSの子孫である、そのメタデータの全ての項目の実体データを持っている処理装置110内のメタデータ(又はそのメタデータ内の個々の項目の実体データ)を指すものであってもよい。

0139

また、上記実施形態では、各レベルのMDSがリンク情報を記憶していたが、リンク情報は、本実施形態のシステムの外部の装置に記憶されていてもよい。外部の装置は、メタデータの識別情報として機能するDIDに対応付けて、そのメタデータの実体データを特定するリンク情報を記憶している。このリンク情報は、例えば、いずれかの処理装置110内にあるそのメタデータを特定する情報(例えばURL)であってもよい。あるいは、外部の装置は、DIDに対応付けて、メタデータの項目ごとに、その項目の実体データを特定するリンク情報を記憶していてもよい。各レベルのMDS又は処理装置110は、検索要求の検索条件に示されるDIDに対応するメタデータを記憶していない場合は、その外部の装置からそのDIDに対応するリンク情報を取得する。すなわち、MDSは、外部の装置からリンク情報を取得する取得手段を有する。そして、そのリンク情報を用いてそのDIDに対応するメタデータの実体データを取得し、取得した実体データを、直接、又はその検索要求の転送の経路を逆向きに経由して、要求元のユーザの閲覧端末104に提供する。

0140

以上に例示した作成端末102、閲覧端末104、処理装置110,110S及び110R、ローカルユーザIDサーバ152、ローカルDIDサーバ154、ローカルメタデータサーバ156、156a及び156b、ユーザIDサーバ210、DIDサーバ220、メタデータサーバ230、230a、230b、処理装置管理サーバ240等の各装置は、コンピュータに上述のそれら各装置の機能を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、CPU等のマイクロプロセッサランダムアクセスメモリ(RAM)及びリードオンリメモリ(ROM)等のメモリ一次記憶)、フラッシュメモリSSD(ソリッドステートドライブ)、HDDハードディスクドライブ)や等の固定記憶装置を制御するコントローラ、各種I/O(入出力インタフェースローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバス等を介して接続された回路構成を有する。それら各機能の処理内容が記述されたプログラムがネットワーク等の経由でフラッシュメモリ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがRAMに読み出されCPU等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。

0141

100ローカルシステム、102作成端末、104閲覧端末、108ローカルネットワーク、110処理装置、130認証デバイス、150組織内管理システム、152ローカルユーザIDサーバ、154ローカルDIDサーバ、156,156a,156bローカルメタデータサーバ、200 管理システム、210 ユーザIDサーバ、220 DIDサーバ、230,230a,230bメタデータサーバ(MDS)、240 処理装置管理サーバ、300広域ネットワーク。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ