JP5937893B2 - 情報流通システム、情報処理装置及び方法 - Google Patents

Description

この発明は、複数の情報処理装置間でサービス対象データを流通させる情報流通システムとこのシステムで使用される情報処理装置及び方法に関する。

Ｗｅｂサービスを構築する方法の一つに、Ｗｅｂブラウザ上で動作するプログラミング言語を用いる方法やフレームワークを用いる方法がある（例えば、非特許文献１を参照。）。この非特許文献１に記載された方法によれば、開発言語によりさまざまなサービスを提供することが可能となる。また、フレームワークにおいても、Ｗｅｂサービスに特化したものとしてStrutsやVelocityといったものが存在しており、使用する言語や用途に応じて使い分けられている（例えば、非特許文献２を参照。）。

また、利用者がＷｅｂブラウザ上で簡単な操作を行うだけで、Ｗｅｂ上のプログラムコンポーネントから処理結果を取得し、Ｗｅｂブラウザ上に処理結果を表示するといった、プログラムコンポーネントに関する技術も提案されている（例えば、特許文献１を参照。）。
しかし、この特許文献１に記載された技術には以下のような課題がある。すなわち、トラストサークル上で提供するＷｅｂサービスを開発するとき、データにアクセスするためにはどこのシステムに格納されているデータベースに問い合わせればよいのか、データベースのどのカラムにデータを格納すればよいかといった情報を把握しておかなければならない。このため、データベースの知識が乏しいプログラマにとっては開発が難しい。さらに、データの更新や削除を行なうためにはロック機能により排他制御を実現しなければいけないが、データベースのプログラミングに慣れていない人が開発すると、ロックをかけ忘れや解除忘れなどでトランザクション処理の不整合が生じ、サービスの提供に支障が出るおそれがある。

それに加え、他のシステムに格納されているデータにアクセスする、あるいは他のシステムで用いているデータベースにデータを格納する場合、トラストサークルでのデータのやり取りの手続きに従う必要がある。この手続きは、例えばＳＡＭＬ（Security Assertion Markup Language）により認証されたユーザが、ＩＤ−ＷＳＦ（Identity Web Service Framework）を用いてユーザの属性情報を交換して要求するデータにアクセスできるかどうかを判断し、アクセス可能であれば要求するデータに関する情報をＩＤ−ＷＳＦにより問い合わせ、検索結果をＩＤ−ＷＳＦを使ってユーザに提示する、というものである。

ＳＡＭＬやＩＤ−ＷＳＦといったＩＤ連携に関する標準化技術は、２００９年６月にＩＤ管理に関する団体「カンターラ・イニシアティブ」が設立されて普及活動を行なっている（例えば、非特許文献３を参照。）。しかし、Ｗｅｂサービス開発者に広く普及しているとは言えないため、概念を理解するのが難しく、開発できる人材も少ない。
なお、ＳＡＭＬとは、インターネット経由でセキュリティ情報を交換するためのＸＭＬベースのフレームワーク、ＩＤ−ＷＳＦとは、Liberty Alliance Projectによって策定された、異なるサイト間でユーザの意思に基づき属性情報を安全に流通するための仕様である。

さらに、医療分野では個人情報へのアクセスについて監査ログを出力することが定められている（例えば、非特許文献４を参照）。

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

株式会社カール、"製品情報：Curlとは"、インターネット＜URL: http://www.curlap.com/products/curl.html＞ 日経ＢＰ社、"Part1 ソフトウエアのフレームワークとはなにか"、インターネット＜URL: http://itpro.nikkeibp.co.jp/article/lecture/20070205/260697/＞ カンターラ・イニシアティブ、インターネット＜URL: http://www.kantarainitiative.org/＞ JAHIS（ジェイヒス）、"ヘルスケア分野における監査証跡のメッセージ標準規約"、インターネット＜URL: http://www.jahis.jp/jahis_hyojyun/seiteizumi_hyojyun/09-003/＞

以上のように、データベースを使ったシステムを開発するという点では、非特許文献１や非特許文献２に記載された技術を使うことで開発効率を上げることが可能である。しかし、トラストサークルで使うことは考慮されていないため、要件を十分満たしているとは言えない。

例えば医療分野では、複数の医療機関がネットワークを介して連携し、医療サービスを市民に提供するサービスシステムが普及しつつある。この種のシステムでは、個々の病院がそれぞれサーバを運用し、これらのサーバ間で医療情報をやり取りする。例えば、中核病院により検査した結果であるレントゲン写真やカルテ等の医療情報を格納したサーバに対し、診療所等のかかりつけ医が自身の端末からアクセスして閲覧する。しかし、特許文献１に記載された技術では、シナリオが決められているため、利用者はシナリオに沿った操作しかできず自由に操作をすることができない。

このように、特に医療分野においては、さまざまな医療機器で作成された検査結果と連携させてサービスを提供することも多く、事前にシナリオを想定することが困難である。また、新たに追加されたサービスに対応したシナリオを作成する手間もかかるため、容易にサービスを提供することができない。また、上記レントゲン写真やカルテ等の医療情報は個人情報であるため、取り扱いを慎重にしなければならない。

そこで、医療情報を安全にやり取りする手法として、上記したＳＡＭＬおよびＩＤ−ＷＳＦといった標準規格を採用することが検討されている。しかし、上述したようにＳＡＭＬおよびＩＤ−ＷＳＦの仕様や開発に関する知識は世の中に広く普及しているとは言えないため、サービス開発には困難を伴う。

さらに、医療分野では、先に述べたように個人情報へのアクセスについて監査ログを出力することが定められている。このため、どのデータにアクセスしたときに出力しなければいけないかを考慮してプログラム開発をしなければならず、この点もサービス参入の障害の１つになっている。

すなわち、従来提案されている医療情報流通システムでは、当該システムを開発するためには、データベースの知識を有し、ユーザのＩＤ連携に必要なＳＡＭＬやＩＤ−ＷＳＦの仕様を理解し、かつ医療分野における個人情報へのアクセス時に出力すべきログを把握し、その上でプログラミングを行うことができる人材を用意しなければならず、システム開発の大きな妨げとなっている。

この発明は上記事情に着目してなされたもので、その目的とするところは、情報の操作や定義を行うために使用されるデータベース言語の知識を備えていなくても容易にシステムを構築できるようにした情報流通システムとこのシステムで使用される情報処理装置及び方法を提供することにある。

上記目的を達成するためにこの発明の一観点は、クライアント端末に接続されサービスの要求側となる第１の情報処理装置と、サービスの提供側となる第２の情報処理装置と、これら第１及び第２の情報処理装置間をネットワークを介して連携させる第３の情報処理装置とを具備する情報流通システムにおいて、上記第１及び第２の情報処理装置に、システムが保有するテーブルデータの各々についてシステム内における格納場所を示す情報を少なくとも定義したテーブル設定ファイルを記憶する手段を設け、さらに判定手段と、リモートデータアクセス手段と、ローカルデータアクセス手段を備えている。
このうち判定手段では、上記クライアント端末から上記テーブルデータに対するアクセス要求が送られた場合に、アクセス先となるテーブルデータの格納場所が自己の情報処理装置内であるか他の情報処理装置であるかを、上記記憶されたテーブル設定ファイルに基づいて判定する。リモートデータアクセス手段では、上記アクセス先となるテーブルデータの格納場所が他の情報処理装置であると判定された場合、及び他の情報処理装置からアクセスに必要な情報が送られてきた場合に、実行対象の機能ごとに予め設定された第１のアプリケーションインタフェースの下で動作して、上記情報処理装置間でデータの授受を行う。ローカルデータアクセス手段では、上記アクセス先となるテーブルデータの格納場所が自己の情報処理装置内であると判定された場合、及び自己の情報処理装置のリモートデータアクセス手段からアクセス要求を受け取った場合に、上記リモートデータアクセス手段が使用する第１のアプリケーションインタフェースと共通の第２のアプリケーションインタフェースの下で動作して、自己の情報処理装置内に格納されている該当するテーブルデータに対しアクセスする。

したがって、テーブル設定ファイルで定義されている個々のテーブルデータの格納場所に関する情報をもとに呼び出す手段及びアプリケーションを特定することができ、データベースに格納されているテーブルの情報をテーブル設定ファイルに記載することで、データの操作や定義を行なうデータベース言語の知識がなくても容易にシステムを構築することが可能となる。また、Ｗｅｂ画面作成からデータ取得まで、画面情報定義ファイルやテーブル設定ファイルに必要な項目を記述するといった一貫した手法によりサービスを実現することができる。

また、この発明の一観点は以下のような態様を備えることも特徴とする。
第１の態様は、上記第１、第２及び第３の情報処理装置のリモートデータアクセス手段が情報処理装置間でデータ転送を行う際に、ＩＤ−ＷＳＦ（Identity Web Service Framework）を用いるものである。
このようにすると、ＩＤ−ＷＳＦを使用することで、情報処理装置間のデータ転送を安全にやり取りすることが可能となる。

第２の態様は、テーブルデータの各々について当該テーブルデータが個人情報を含むか否かを表す情報をテーブル設定ファイルにさらに記憶し、上記第１及び第２の情報処理装置は、当該アクセス先となったテーブルデータが個人情報を含むか否かを上記テーブル設定ファイルに基づいて判定し、個人情報を含むと判定された場合に上記ローカルデータアクセス手段又はリモートデータアクセス手段からアクセス結果を表す情報を受け取った時点で監査ログを生成するようにしたものである。
このようにすると、アクセス日時やアクセスした人の情報を監査ログとして簡単かつ確実に出力することが可能となる。すなわち、システムを構築する際に、監査に必要な情報を意識することなく監査ログを生成する仕組みを提供することが可能となる。

すなわちこの発明の一観点によれば、情報の操作や定義を行うために使用されるデータベース言語の知識を備えていなくても容易にシステムを構築できるようにした情報流通システムとこのシステムで使用される情報処理装置及びそのアクセス制御方法を提供することができる。

この発明の一実施形態に係る情報流通システムの機能構成を示すブロック図。 図１に示したシステムの各サーバが備えるＷｅｂアクセス受付部の機能構成とファイルの一例を示す図。 Ｗｅｂ画面コンポーネント基本構成と、紹介元病院の医療従事者用サービス画面の一例を示す図。 図１に示したシステムの紹介元病院サーバと連携サーバとの間における患者ＩＤ連携処理手順の前半部分を示すフローチャート。 図１に示したシステムの紹介元病院サーバと連携サーバとの間の患者ＩＤ連携処理手順の後半部分を示すフローチャート。 紹介先病院の医療従事者用サービス画面の一例を示す図。 図１に示したシステムの紹介先病院サーバ、連携サーバおよび紹介元病院サーバ間における患者ＩＤ連携処理手順の前半部分を示すフローチャート。 図１に示したシステムの紹介先病院サーバ、連携サーバおよび紹介元病院サーバ間における患者ＩＤ連携処理手順の後半分を示すフローチャート。 紹介元病院サーバのユーザ情報格納部に格納される情報の一例を示す図。 連携サーバのユーザ情報格納部に格納される情報の一例を示す図。 紹介先病院サーバのユーザ情報格納部に格納される情報の一例を示す図。

以下、図面を参照してこの発明に係わる実施形態を説明する。
［一実施形態］
（構成）
図１は、この発明の一実施形態に係る情報流通システムの機能構成を示すブロック図である。
一実施形態に係る情報流通システムは、クライアント端末４が接続される複数の要求側サーバ１と、サービスを提供する複数の提供側サーバ２と、連携サーバ３とを具備し、これらのサーバ１，２，３はネットワーク５を介して相互に通信可能となっている。なお、図１では図示の煩雑化を避けるため、要求側サーバ１及び提供側サーバ２はいずれも１台のみを図示している。

一実施形態に係る情報流通システムは、トラストサークルでＩＤ連携されている。ＩＤ連携は、ＳＡＭＬ（Security Assertion Markup Language）の機能を用いて実現する。ＳＡＭＬによるＩＤ連携は、ユーザ情報を扱う１つのアイデンティティプロバイダ（ＩｄＰ: Identity Provider）と、複数のサービスプロバイダ（ＳＰ: Service Provider）との間のトラストサークルに基づいて行われる。本実施形態では、ＩｄＰとして連携サーバ３を、ＳＰとして要求側及び提供側の各サーバ１，２を適用する場合を例示している。ＩＤ連携を実現するためには仮名（かめい）を使用する。仮名を使う理由は、実ユーザのＩＤが漏れるのを防ぐためと、名寄せによる個人情報の情報が漏れるのを防ぐためである。

クライアント端末４は、例えば医師や患者等のユーザが使用するパーソナル・コンピュータからなり、Ｗｅｂブラウザ４０を有している。ユーザは、このＷｅｂブラウザ４０を使って要求側サーバ１及び提供側サーバ２にアクセスする。
次に、要求側サーバ１、提供側サーバ２及び連携サーバ３の構成を説明する。なお、要求側サーバ１と提供側サーバ２は同一構成なので、ここでは要求側サーバ１について説明し、提供側サーバ２についての説明は省略する。

要求側サーバ１は、例えば病院のポータルサーバ或いは患者が利用する医療ポータルサーバからなり、クライアント端末４からのアクセス要求を受け付けると、このアクセス要求に対応するサービスを自サーバが処理できる場合には自サーバ１内で実行し、処理できない場合には該当する提供側サーバ２に上記要求を転送して対応するサービスを実行させる。

この機能を実現するために要求側サーバ１は、処理部としてＷｅｂアクセス受付部１１と、アクセス制御判定部１２と、ローカルデータアクセス部１３と、リモートデータアクセス部１４を備え、さらにデータ格納部としてユーザ情報格納部１５と、アプリケーションデータ格納部１６を備えている。

ユーザ情報格納部１５には、ユーザの個人情報が格納されている。この個人情報は、アクセス要求を送信したユーザについて、アクセス制御判定部１２が当該アクセスの可否を判定するために用いられる。アプリケーションデータ格納部１６には、自サーバ１上で実行されるアプリケーションが用いるアクセス制御ファイル、設定ファイル及び個別データが格納されている。

Ｗｅｂアクセス受付部１１は、図示しないファイル格納部からＵＲＬマッピング情報設定ファイル４２及び画面情報定義ファイル４３を読み込み、これらの設定ファイルのデータを用いてクライアント端末４のＷｅｂブラウザ４０からアクセス要求（ＨＴＴＰリクエスト）を受け付けて、その要求内容を解析する機能を有する。

またＷｅｂアクセス受付部１１は、図示しないファイル格納部からテーブル設定ファイル４１を読み込み、このテーブル設定ファイル４１に記述された設定情報に基づいて、操作対象のテーブルが要求側サーバ１に存在するか提供側サーバ２に存在するかを判定する。そして、この判定結果に基づき、要求側サーバ１に存在すると判定された場合にはローカルデータアクセス部１３を動作させ、一方提供側サーバ２に存在すると判定された場合にはリモートデータアクセス部１４を動作させる機能を有する。

アクセス制御判定部１２は、上記ユーザ情報格納部１５に格納されたユーザ情報に基づいて、データに対するユーザのアクセスの可否を判断する。ローカルデータアクセス部１３は、要求側サーバ（自サーバ）１のデータベースが保有するテーブルに対するアクセス処理を実行する。具体的には、データベース言語を用いずに、テーブルの作成、削除、クリア、ファイルのアップロード及びダウンロードと、データ検索、削除、取得、登録、更新の各処理を実行する。これらの機能を実現するためのアプリケーションインタフェースが規定されているので、具体的な値を入力パラメータとして外部から指定することで上記処理を実行する。

例えば、テーブルに格納されているデータを削除する場合は、テーブル名を指定して、テーブル設定ファイル４１に記載されているカラム名を読み込み、必要なデータをローカルデータアクセス部１３のデータ削除アプリケーションインタフェースに渡すことにより、ローカルデータアクセス部１３のデータ削除アプリケーションがテーブルから該当箇所のデータの削除を実行し、成功または失敗したという内容の結果を出力する。

リモートデータアクセス部１４は、提供側サーバ（他のサーバ）２のデータベースに格納されているテーブルに対するアクセス処理を実行するもので、先に述べたローカルデータアクセス部１３が備える各機能のうち、テーブル操作およびファイル操作を除いた機能を備える。具体的には、リモートデータ検索、削除、取得、登録、更新の各機能に加え、他サーバとのやり取りのための機能として、リモートデータアクセス要求・応答機能を有する。さらにリモートデータアクセス部１４は、他のサーバと通信をするときに、必ずＩＤ−ＷＳＦを使うように設定している。そして、そのためにローカルデータアクセス部１３と同様に、これらの機能を実現するためのアプリケーションインタフェースが規定されている。

これにより、テーブル設定ファイル４１に書かれているテーブルの格納場所を把握できれば、ローカルデータアクセスかリモートデータアクセスのどちらのアプリケーションを呼び出すかを気にしなくてよい。リモートデータアクセス部１４に格納されているアプリケーションは、すべてＩＤ−ＷＳＦを用いて他のサーバにアクセスするようになっているので、ＩＤ−ＷＳＦを意識する必要がない。

また、リモートデータアクセス部１４を使って他のサーバ２，３のリモートデータアクセス部２４，３４を呼び出した場合、他のサーバ２，３内ではローカルデータアクセス部２３，３３が呼び出されて動作する。このため、呼び出す操作や形式が統一されている。したがって、ローカルデータアクセス部１３と同じやり方を用いて、具体的な値を入力パラメータとして外部から指定させることで、上記機能を実現できるようになっている。

図２は、上記Ｗｅｂアクセス受付部１１のより詳しい構成を示した機能ブロック図である。Ｗｅｂアクセス受付部１１は、ＵＲＬ解析部１１１と、Ｗｅｂアクセス処理部１１２と、通信データ作成部１１３を有する。
ＵＲＬ解析部１１１は、クライアント端末４からＨＴＴＰリクエストを受け取った場合に、アクセス先となるＵＲＬを解析する。そして、解析結果に基づいて、ＵＲＬマッピング情報設定ファイル４２からデータ操作に必要となる設定情報を読込む。具体的には、図２に示すようにデータ操作に必要となる処理名、画面表示名、ＵＲＬのアクション名、処理クラス名を読込む。

Ｗｅｂアクセス処理部１１２は、上記解析されたＵＲＬに対しアクセスする際に、テーブル設定ファイル４１及び画面情報定義ファイル４３に記述されたデータに基づいて、操作メニュー画面や検索画面等、ＵＲＬに該当する画面表示データを生成する。画面情報定義ファイル４３には、Ｗｅｂ画面コンポーネント基本構成に該当する項目の具体的な内容が記述されている。

図３（ａ）はＷｅｂ画面コンポーネント基本構成を示すもので、ページを構成する本体部５１にヘッダ部５２とフッタ部５３を付加したものからなる。ヘッダ部５２には、メインタイトルや左上図、右上図が記述される。本体部５１は、概要説明部５１１と、テーブル表示部５１２と、ボタン表示部５１３と、リンク表示部５１４とから構成される。概要説明部５１１には、表示する画面を説明するための文章が記述される。テーブル表示部５１２には、テーブル設定ファイル４１と一致したデータを表示した結果が反映される。ボタン表示部５１３には、表示画面において操作が必要な場合に、その操作ボタンを表示する。リンク表示部５１４には、自サーバへのリンク情報を表示する。フッタ部５３には、左、中央、右にそれぞれ文字が記述される。著作権表示はこのエリアに記述される。

通信データ作成部１１３は２つの機能を持つ。その一つは、Ｗｅｂアクセス処理部１１２で取得したデータを操作するために必要となる情報を受け取り、ローカルデータアクセス部１３またはリモートデータアクセス部１４に問い合わせをするためのデータに変換する機能である。他の１つは、ローカルデータアクセス部１３及びリモートデータアクセス部１４による処理結果をＷｅｂアクセス処理部１１２から受け取り、この受け取った処理結果をＷｅｂ画面として表示するための形式に変換する機能である。

テーブル設定ファイル４１は、アクセス対象となるテーブルを定義するもので、定義対象となるテーブルには例えば以下のテーブルが挙げられる。
(1) ユーザデータ；ユーザＩＤと、ユーザの属性とを関連付けて管理するデータであり、要求側サーバ１、提供側サーバ２及び連携サーバ３のそれぞれで管理される。なお、ユーザの属性とは、氏名、生年月日、性別、住所などである。
(2) 認証データ；ユーザＩＤと、ログイン、パスワードとを関連付けて管理するデータであり、要求側サーバ１、提供側サーバ２及び連携サーバ３のそれぞれで管理される。
(3) 組織データ；組織ＩＤと組織の名称を関連付けて管理するデータであり、連携サーバ３のみで管理される。
(4) サーバユーザＩＤ−仮名マッピングデータ；サーバ単位で保有するユーザＩＤと仮名を関連付けて管理するデータであり、要求側サーバ１、提供側サーバ２、連携サーバ３のそれぞれで管理される。
(5) アクセス制御リスト；ユーザデータ、組織データ、資格データ、アクセス制御リストへのアクセス権限を保持するデータであり、要求側サーバ１、提供側サーバ２、連携サーバ３のそれぞれで管理される。
(6) サービスプロバイダＩＤ−組織マッピングデータ；サービスプロバイダを識別するＩＤと組織ＩＤを関連付けるデータであり、連携サーバ３のみで管理される。
(7) 紹介済み患者データ；医療機関が他医療機関に紹介した患者の情報を管理するデータであり、要求側サーバ１及び提供側サーバ２で管理される。
(8) 一時ユーザ指定子データ；仮名と、仮名を暗号化したデータと、暗号化を依頼したサーバのプロバイダＩＤを関連付けるデータであり、連携サーバ３のみで管理される。

以上述べた各テーブルは、テーブル設定ファイル４１において、例えば図２に示したようにテーブルの表示名、テーブル名、格納場所、サービスタイプ、検索条件等の複数の項目により定義される。また、非NULL値、主キーやインデックスの設定など、データベースの基本的な機能もこのテーブルで設定される。さらに、上記各テーブルのうち、ユーザデータ、認証データ、サーバユーザＩＤ−仮名マッピングデータ、紹介済み患者データ及び一時ユーザ指定子データは、個人情報が格納されたテーブルである。この個人情報を含む各テーブルにアクセスした場合には、必ず監査ログを出力する必要があるため、テーブル設定ファイル４１には個人情報であることを示す情報も設定される。
このように、要求側サーバ１、提供側サーバ２及び連携サーバ３が管理するテーブルの定義情報を、共通のテーブル設定ファイルで管理することによって、今後データテーブルが増えた場合でも、臨機応変に対応することが可能となる。

連携サーバ３は、上記要求側サーバ１と提供側サーバ２との間を連携させるためのもので、上記要求側サーバ１と同様に、処理部としてＷｅｂアクセス受付部３１と、アクセス制御判定部３２と、ローカルデータアクセス部３３と、リモートデータアクセス部３４を備え、さらにデータ格納部としてユーザ情報格納部３５及びアプリケーションデータ格納部３６に加えて、システム情報格納部３７と、マスタ情報格納部３８を備えている。

このうちシステム情報格納部３７には、情報流通システムを構成する各サーバが有するシステム情報や使用する認証方式を表す情報が格納されている。マスタ情報格納部３８には、情報流通システムに対し利用登録した全てのユーザについて、そのユーザＩＤに関連付けて当該ユーザが所属する組織や資格を表す属性情報がマスタ情報として格納される。登録済のユーザが新たに資格を取得した場合には、上記マスタ情報が更新される。

ユーザ情報格納部３４には、上記マスタ情報格納部３８に格納されたマスタ情報のうちユーザの属性情報が格納され、さらにユーザが利用できるサービスのリストが格納される。アプリケーションデータ格納部３６には、自サーバ上で実行されるアプリケーションが用いるアクセス制御ファイル、設定ファイル及び個別データが格納される。

連携サーバ３は、要求側サーバ１又は提供側サーバ２から、ユーザが利用可能なサービスについての問い合わせを受信すると、上記ユーザ情報格納部３５に格納されたサービスリストを検索して、当該ユーザが要求するサービスを利用可能か否かを判断し、その結果を要求元の要求側サーバ１又は提供側サーバ２へ回答する。

なお、以上述べた要求側サーバ１、提供側サーバ２及び連携サーバ３による基本的な機能とその動作については、特開２０１０−８６０８０号公報「分散情報連携システムおよび分散情報連携方法」に詳しく記載されている。

（動作）
次に、以上のように構成された情報流通システムの動作を説明する。ここでは、病院サーバ間で患者を紹介する場合を例にとって説明を行う。なお、（１）だけで見ると、紹介元病院サーバは要求側サーバとなるが、（１）、（２）を通して同じ符号を用いるため、ここでの記述は提供側サーバとしている。

（１）紹介元病院の医療従事者が患者のＩＤ連携を実施する場合
患者の情報は、治療を受けている紹介元病院サーバとなる提供側サーバ２のユーザ情報格納部２５にのみ、ユーザＩＤとユーザ属性とを関連付けた状態で格納されている。ユーザの属性としては、氏名、生年月日、住所、性別などがあるが、これに限定されるものではない。

このような状態で、紹介元病院の医療従事者が患者のＩＤ連携を実施しようとすると、紹介元病院サーバとなる提供側サーバ２と、連携サーバ３との間では、以下のような処理が実行される。図４及び図５はその処理手順と処理内容を示すフローチャートである。なお、ＩＤ連携の実施結果にはＮＧの場合もあり得るが、図４及び図５では説明の簡単のためすべての処理が成功した場合のみを示している。

先ず、紹介元病院サーバである提供側サーバ２では、その起動時において、Ｗｅｂアクセス受付部２１がその処理に必要な各種設定ファイルを図示しないファイル格納部から作業メモリ上に読込む。このとき、読込まれるファイルの中にはテーブル設定ファイル４１が含まれる。なお、連携サーバ３においても、その起動時において、テーブル設定ファイル４１を含む各種ファイルがＷｅｂアクセス受付部３１の作業メモリ上に読込まれる。

クライアント端末４において、紹介元病院の医療従事者がサービスを提供するＵＲＬにアクセスするための操作を行うと、クライアント端末４から提供側サーバ（紹介元病院サーバ）２へＨＴＴＰリクエストが送信される。これに対し紹介元病院サーバ２は、Ｗｅｂアクセス受付部２１により画面情報定義ファイル４３に基づいて操作メニュー画面や検索画面など、ＵＲＬに該当する表示画面を生成し、この生成された表示画面データをクライアント端末４へ返送する。この結果、クライアント端末４には紹介元病院の医療従事者向けのサービス画面が表示される。

図３（ｂ）はこのとき表示されるサービス画面の一例を示すもので、図３（ａ）に示したＷｅｂ画面コンポーネントに基づいて生成されたものである。同図に示すように、ヘッダ部５２にはメインタイトルの「紹介元病院の患者ＩＤ連携」が表示される。本体部５１の概要説明部５１１には、「患者を紹介する病院が…」という内容が記載されている。テーブル表示部５１２には、患者テーブルに格納されているデータを操作するためのリンク先情報が、プログラムによって生成され表示される。ボタン表示部５１３には、何も表示されない。リンク表示部５１４には、メインメニューに戻るためのリンク情報と、サービスを終了するためのログアウトのリンク情報が表示されている。フッタ部５３には、このサービスを提供する会社の著作権情報が表示されている。なお、図３（ｂ）はあくまでも一例であり、これに限定されるものではない。

この状態で、医療従事者が「データ検索」をクリックし、連携したい患者の情報、例えば氏名を入力して検索実行ボタンを操作したとする。そうすると、Ｗｅｂアクセス受付部２１は、先ず上記連携対象の患者情報（ユーザデータ）が自サーバ内に格納されているか或いは他のサーバに格納されているかを、先に読込んでおいたテーブル設定ファイル４１をもとに判定する。この判定の結果、いま患者情報が紹介元病院サーバ２に格納されていたとする。そうするとＷｅｂアクセス受付部２１は、受信した患者の氏名を検索キーとしてローカルデータアクセス部２３に対しユーザデータ中に該当する患者の情報が含まれているか否かを問い合わせる。この問い合わせに対しローカルデータアクセス部２３は、ユーザ情報格納部２５から該当する患者情報を検索し、この検索された情報をＷｅｂアクセス受付部２１に返却する。Ｗｅｂアクセス受付部２１は、この返却された患者情報の表示データをクライアント端末４へ転送し表示させる。

次に医療従事者は、上記患者の情報のＩＤ連携を行なうために、クライアント端末４において「データ新規登録」をクリックしたのち、登録対象の患者（すでにユーザデータを取得済み）を連携サーバ３に登録するために必要な情報、例えばログインＩＤとパスワードを入力する。この入力されたログインＩＤとパスワードは、クライアント端末４から紹介元病院サーバ２へ送られる。

紹介元病院サーバ２は、上記ログインＩＤとパスワードを受信すると、Ｗｅｂアクセス受付部１１が自分のプロバイダＩＤと自サーバ１における上記患者のユーザＩＤをリモートデータアクセス部２４に渡す。リモートデータアクセス部２４は、上記プロバイダＩＤ及び患者のユーザＩＤを含む仮名登録要求を、ＩＤ−ＷＳＦを使用して連携サーバ３のリモートデータアクセス部３４へ送信する。

連携サーバ３のリモートデータアクセス部３４は、上記要求を受信すると仮名の登録をローカルデータアクセス部３３に依頼する。ローカルデータアクセス部３３は、上記受け取った情報の中に仮名が含まれているか否かを判定し、含まれていなければ上記依頼された患者の情報は連携サーバ３に登録されていないと判断し、新規にサーバユーザＩＤを作成する。そして、この作成したサーバユーザＩＤと、それに対応する仮名と、プロバイダＩＤとを紐付けるために、サーバユーザＩＤ−仮名マッピングデータに登録する。そして、登録した結果をリモートデータアクセス部３４に返却する。リモートデータアクセス部３４は、上記登録結果を表す情報をＩＤ−ＷＳＦを経由して紹介元病院サーバ２のリモートデータアクセス部２４に返送する。リモートデータアクセス部２４は、上記受信結果をＷｅｂアクセス受付部２１に返却する。

紹介元病院サーバ２は、上記登録結果をＷｅｂアクセス受付部２１で受信すると、連携サーバ３のプロバイダＩＤ及び登録する患者のサーバユーザＩＤを上記受信された登録結果に含まれる仮名と関連付けるために、Ｗｅｂアクセス受付部２１からローカルデータアクセス部２３へ登録依頼を渡す。ローカルデータアクセス部２３は、受け取った情報をサーバユーザＩＤ−仮名マッピングデータに登録し、登録結果をＷｅｂアクセス受付部２１に返却する。

そうして連携サーバ３及び紹介元病院サーバ２の両方に患者の仮名が登録されると、紹介元病院サーバ２は続いて連携サーバ３に対し該当する患者の情報を登録するための処理を以下のように実行する。すなわち、先ずＷｅｂアクセス受付部２１は、ユーザデータ登録に必要な情報をリモートデータアクセス部２４に渡す。リモートデータアクセス部２４は、ユーザデータ登録に必要な情報をＩＤ−ＷＳＦを経由して連携サーバ３のリモートデータアクセス部３４に送る。

連携サーバ３のリモートデータアクセス部３４は、ユーザデータ登録の処理をローカルデータアクセス部３３に依頼し、ローカルデータアクセス部３３はユーザデータおよび認証データを登録して、結果をリモートデータアクセス部３４に返す。リモートデータアクセス部３４は、ＩＤ−ＷＳＦを経由して登録結果を表す情報を紹介元病院サーバ２のリモートデータアクセス部２４に返送する。

紹介元病院サーバ２のリモートデータアクセス部２４は、上記登録結果を表す情報をＷｅｂアクセス受付部２１に返す。Ｗｅｂアクセス受付部２１は、登録結果がＯＫであれば、紹介先病院サーバ１に紹介対象の患者を登録するために必要となる仮名を渡すための処理を以下のように実行する。

すなわち、仮名を渡すために一時ユーザ指定子を発行する。なお、一時ユーザ指定子を渡す方法については、特開２０１１−１０７７７９号公報、「情報アクセス制御システムおよび方法」に詳しく記載されている。例えば、医療従事者が一時ユーザ指定子をダウンロードして患者に手渡しする。あるいは紹介先病院の医療従事者が患者のＩＤ連携を行なうときに紹介元病院サーバから取得する、という様々な方法が考えられる。この実施形態では後者の例を用いてＩＤの連携方法を示す。

紹介元病院サーバ２は、上記発行した一時ユーザ指定子をリモートデータアクセス部２４に渡す。リモートデータアクセス部２４は、上記一時ユーザ指定子の発行要求をＩＤ−ＷＳＦを使用して連携サーバ３のリモートデータアクセス部３４へ送信する。連携サーバ３のリモートデータアクセス部３４は、上記発行要求を受信すると一時ユーザ指定子の発行をローカルデータアクセス部３３に依頼する。ローカルデータアクセス部３３は、上記依頼を受けて一時ユーザ指定子を発行し、この発行した結果をリモートデータアクセス部３４に返却する。リモートデータアクセス部３４は、上記発行結果を表す情報をＩＤ−ＷＳＦを経由して紹介元病院サーバ２のリモートデータアクセス部２４に返送する。リモートデータアクセス部２４は、上記受信結果をＷｅｂアクセス受付部２１に返却する。

紹介元病院サーバ２は、上記発行結果をＷｅｂアクセス受付部２１で受信すると、Ｗｅｂアクセス受付部２１からローカルデータアクセス部２３へ一時ユーザ指定子の登録依頼を渡す。ローカルデータアクセス部２３は、受け取った一時ユーザ指定子を紹介済患者データと関連付けて登録する。そして、登録結果を表す情報をＷｅｂアクセス受付部２１に返却する。この登録結果を表す情報は、Ｗｅｂアクセス受付部２１から要求元のクライアント端末４に送られ、同端末４の表示部に表示される。

一時ユーザ指定子は、仮名を暗号化したものであるから、紹介先病院の医療従事者に安全に渡すことができるし、暗号化された一時ユーザ指定子を復号するために使用する秘密鍵が流出して一時ユーザ指定子が第三者に復号されても、システム上で使用されている実ＩＤ、例えばユーザＩＤやログインＩＤを第三者に知られるリスクを回避できる。

（２）紹介先病院の医療従事者が患者のＩＤ連携を実施する場合
紹介先病院の医療従事者が患者のＩＤ連携を実施しようとすると、紹介先病院サーバとなる要求側サーバ１と連携サーバ３との間、及び紹介元病院サーバとなる提供側サーバ２と連携サーバ３との間において、以下のような処理が実行される。図７及び図８はその処理手順と処理内容を示すフローチャートである。なお、ＩＤ連携の実施結果にはＮＧの場合もあり得るが、図７及び図８では説明の簡単のためすべての処理が成功した場合のみを示している。

先ず、紹介先病院サーバとなる要求側サーバ１では、その起動時において、Ｗｅｂアクセス受付部１１がその処理に必要な各種設定ファイルを図示しないファイル格納部から作業メモリ上に読込む。このとき、読込まれるファイルの中にはテーブル設定ファイル４１が含まれる。なお、連携サーバ３においても、また紹介元病院サーバとなる提供側サーバ２においても、それぞれ起動時においてテーブル設定ファイル４１を含む各種ファイルがＷｅｂアクセス受付部３１，２１の作業メモリ上に読込まれる。

クライアント端末４において、紹介先病院の医療従事者がサービスを提供するＵＲＬにアクセスするための操作を行うと、クライアント端末４から要求側サーバ（紹介先病院サーバ）１へＨＴＴＰリクエストが送信される。これに対し紹介先病院サーバ１は、Ｗｅｂアクセス受付部１１により画面情報定義ファイル４３に基づいて操作メニュー画面や検索画面など、ＵＲＬに該当する表示画面を生成し、この生成された表示画面データをクライアント端末４へ返送する。この結果、クライアント端末４には紹介先病院の医療従事者向けのサービス画面が表示される。

図６はこのとき表示されるサービス画面の一例を示すもので、図３（ａ）に示したＷｅｂ画面コンポーネントに基づいて生成されたものである。同図に示すように、ヘッダ部５２にはメインタイトルの「紹介先病院の患者ＩＤ連携」が表示される。本体部５１の概要説明部５１１には、「患者を紹介される病院が…」という内容が記載されている。テーブル表示部５１２には、患者テーブルに格納されているデータを操作するためのリンク先情報が、プログラムによって生成され表示される。ボタン表示部５１３には、何も表示されない。リンク表示部５１４には、メインメニューに戻るためのリンク情報と、サービスを終了するためのログアウトのリンク情報が表示されている。フッタ部５３には、このサービスを提供する会社の著作権情報が表示されている。なお、図６はあくまでも一例であり、これに限定されるものではない。

この状態で、医療従事者が「データ検索」をクリックし、連携したい患者の情報、例えば氏名を入力して検索実行ボタンを操作したとする。そうすると、紹介先病院サーバ１のＷｅｂアクセス受付部１１は、先ず上記連携対象の患者情報（ユーザデータ）が自サーバ内に格納されているか或いは他のサーバに格納されているかを、先に読込んでおいたテーブル設定ファイル４１をもとに判定する。いま、患者の情報は紹介先病院サーバ１に既に登録済みであるとすると、Ｗｅｂアクセス受付部１１は上記受信した患者の氏名を検索キーとしてローカルデータアクセス部１３に対しユーザデータ中に該当する患者の情報が含まれているか否かを問い合わせる。この問い合わせに対しローカルデータアクセス部１３は、ユーザ情報格納部１５から該当する患者情報を検索し、この検索された情報をＷｅｂアクセス受付部１１に返却する。Ｗｅｂアクセス受付部１１は、この返却された患者情報の表示データをクライアント端末４へ転送し表示させる。

次に医療従事者が、ＩＤ連携可能な病院を検索するために、図６に示したサービス画面において「ＩＤ連携できる病院一覧検索」をクリックしたとする。そうすると、Ｗｅｂアクセス受付部１１は、リモートデータアクセス部１４に対し連携サーバ３に登録されている病院（組織データ）の検索を依頼する。リモートデータアクセス部１４は、医療従事者の認証データといった必要なデータをＩＤ−ＷＳＦ経由で、連携サーバ３のリモートデータアクセス部３４に転送し、組織データの検索を依頼する。

連携サーバ３のリモートデータアクセス部３４は、上記組織データの検索依頼を受信すると、ローカルデータアクセス部３３に組織データの検索処理を依頼する。ローカルデータアクセス部３３は、マスタ情報格納部３８から組織データを検索して、連携可能な組織データをリモートデータアクセス部３４に返却する。リモートデータアクセス部３４は、連携可能な組織データをＩＤ−ＷＳＦを経由して、要求元の紹介先病院サーバ１のリモートデータアクセス部１４に返送する。紹介先病院サーバ１のリモートデータアクセス部１４は、返送された連携可能な組織データをＷｅｂアクセス受付部１１に渡し、Ｗｅｂアクセス受付部１１は当該データをクライアント端末４へ転送して表示させる。

この状態で医療従事者が、該当する患者がかかっていた病院である紹介元病院を選択すると、紹介先病院サーバ１のＷｅｂアクセス受付部１１は、紹介元病院のプロバイダＩＤの検索をリモートデータアクセス部１４に依頼する。リモートデータアクセス部１４は、紹介元病院の組織データをＩＤ−ＷＳＦを経由して連携サーバ３のリモートデータアクセス部３４へ送信し、プロバイダＩＤの検索を依頼する。

上記プロバイダＩＤの検索依頼をすると、連携サーバ３のリモートデータアクセス部３４は、ローカルデータアクセス部３３にプロバイダＩＤの検索を依頼する。ローカルデータアクセス部３３はプロバイダＩＤ−組織マッピングデータを検索し、該当するプロバイダＩＤをリモートデータアクセス部３４に返却する。リモートデータアクセス部３４は、該当するプロバイダＩＤをＩＤ−ＷＳＦを経由して紹介先病院サーバ１のリモートデータアクセス部１４に返送する。紹介先病院サーバ１のリモートデータアクセス部１４は、上記返送すされた紹介元病院サーバのプロバイダＩＤをＷｅｂアクセス受付部１１に返却する。

紹介先病院サーバ１のＷｅｂデータアクセス部１１は、続いて紹介先病院サーバのプロバイダＩＤを取得し、この取得した紹介先病院サーバのプロバイダＩＤをリモートデータアクセス部１４に渡して、紹介先病院サーバの組織データの検索を依頼する。この検索依頼を受けてリモートデータアクセス部１４は、紹介先病院サーバのプロバイダＩＤをＩＤ−ＷＳＦを経由して連携サーバ３のリモートデータアクセス部３４に送信する。

連携サーバ３のリモートデータアクセス部３４は、ローカルデータアクセス部３３に対し紹介先病院サーバの組織データの検索を依頼する。ローカルデータアクセス部３３は、この依頼に応じて紹介先病院サーバのプロバイダＩＤをもとに組織データを検索し、この検索した結果をリモートデータアクセス部３４に返却する。リモートデータアクセス部３４は、上記検索された紹介先病院サーバの組織データをＩＤ−ＷＳＦを経由して依頼元の紹介先病院サーバ１のリモートデータアクセス部１４に返送する。リモートデータアクセス部１４は、この返送された紹介先病院サーバの組織データをＷｅｂアクセス受付部１１に返却する。

次に紹介先病院サーバ１のＷｅｂアクセス受付部１１は、ＩＤ連携に必要となる仮名を取得するために、紹介元病院サーバ２に登録されている一時ユーザ指定子の取得をリモートデータアクセス部１４に依頼する。リモートデータアクセス部１４は、患者の情報、紹介元病院サーバ２のプロバイダＩＤ、紹介先病院サーバ１の組織データなど、一時ユーザ指定子を取得するために必要となるデータをＩＤ−ＷＳＦを経由して連携サーバ３のリモートデータアクセス部３４に送信する。

連携サーバ３部のリモートデータアクセス部３４は、探す先が紹介元病院サーバ１になっているので、受け取ったデータを図８に示すようにＩＤ−ＷＳＦを経由して紹介元病院サーバ２のリモートデータアクセス部２４へ転送する。紹介元病院サーバ２のリモートデータアクセス部２４は、上記受信したデータをローカルデータアクセス部２３に渡し、一時ユーザ指定子の取得を依頼する。この依頼を受けるとローカルデータアクセス部２３は、患者の一時ユーザ指定子を取得し、その結果をリモートデータアクセス部２４に返却する。リモートデータアクセス部２４は、上記取得された一時ユーザ指定子をＩＤ−ＷＳＦを経由して連携サーバ３のリモートデータアクセス部に返送する。連携サーバ３のリモートデータアクセス部３４は、上記返送された患者の一時ユーザ指定子をＩＤ−ＷＳＦを経由して紹介先病院サーバ１のリモートデータアクセス部１４に返送し、リモートデータアクセス部１４はＷｅｂアクセス受付部１１に返却する。

次に、紹介先病院サーバ１のＷｅｂアクセス受付部１１は、一時ユーザ指定子の解決処理をリモートデータアクセス部１４に依頼する。リモートデータアクセス部１４は、一時ユーザ指定子の解決に必要なデータの取得要求をＩＤ−ＷＳＦを経由して連携サーバ３のリモートデータアクセス部３４に送信する。

連携サーバ３のリモートデータアクセス部３４は、患者の一時ユーザ指定子を解決するためにローカルデータアクセス部３３に処理を渡す。ローカルデータアクセス部３３は、一時ユーザ指定子を解決し、その結果得られた仮名をリモートデータアクセス部３４に返却する。リモートデータアクセス部３４は、仮名をＩＤ−ＷＳＦを経由して紹介先病院サーバ１のリモートデータアクセス部１４に返送する。

紹介先病院サーバ１のリモートデータアクセス部１４は、上記返送された仮名をＷｅｂアクセス受付部１１に返却する。Ｗｅｂアクセス受付部１１は、紹介元病院と紹介先病院との間の患者のＩＤを関連付けるため、リモートデータアクセス部１４に対し連携サーバ３への患者の仮名登録の依頼を出す。リモートデータアクセス部１４は、患者の情報と取得した仮名をＩＤ−ＷＳＦを経由して連携サーバ３のリモートデータアクセス部３４に渡す。

連携サーバ３のリモートデータアクセス部３４は、受け取ったデータをローカルデータアクセス部３３に渡し、サーバユーザＩＤ−仮名マッピングデータへの登録を依頼する。ローカルデータアクセス部３３は、上記依頼を受けて登録処理を行い、登録が完了した結果を示す情報をリモートデータアクセス部３４に返す。リモートデータアクセス部３４は、登録結果をＩＤ−ＷＳＦを経由して紹介先病院サーバ１のリモートデータアクセス部１４に返送する。紹介先病院サーバ１のリモートデータアクセス部１４は、上記登録結果を示す情報をＷｅｂアクセス受付部１１に返却し、Ｗｅｂアクセス受付部１１は当該患者のＩＤ連携が完了したことを表す情報をクライアント端末４へ返送する。

以上のＩＤ連携手順を実行することで、紹介元病院サーバ２及び紹介先病院サーバ１のユーザ情報格納部２５，１５には、ＩＤ連携された患者の情報がそれぞれ格納される。図９は、紹介元病院サーバ２のユーザ情報格納部２５に格納されたサーバユーザＩＤ−仮名マッピングデータ、ユーザデータ及び紹介済み患者データの一例を示す。また図１０は、連携サーバ３のユーザ情報格納部３５に格納されたサーバユーザＩＤ−仮名マッピングデータ、ユーザデータ及び認証データの一例を示す。最後に図１１は、紹介先病院サーバ１のユーザ情報格納部１５に格納されたサーバユーザＩＤ−仮名マッピングデータ及びユーザデータの一例を示すものである。

図９乃至図１１に示した各データを利用することで、以下のような情報流通処理が可能となる。すなわち、紹介先病院サーバ１のユーザＩＤ“b19284”を持つ患者が紹介元病院サーバ２の情報を取得するためには、紹介先病院サーバ１においてユーザＩＤ“b19284”が仮名“SJE2”であることに基づき、連携サーバ３に“SJE2”に関係するユーザデータを問い合わせる。連携サーバ３では、仮名“SJE2”が紹介先病院のユーザであり、かつ連携サーバ３におけるユーザＩＤ“MD006”であることを知る。また、ユーザＩＤ“MD006”は、紹介元病院のユーザであり、仮名“AAD6”を持つことを知る。紹介元病院の仮名“AAD6”が誰であるかを問い合わせると、紹介元病院サーバ２ではユーザＩＤ“A00006”となり、紹介先病院サーバ１と紹介元病院サーバ２との間で患者が一致することが分かるので、紹介元病院サーバ２の患者情報を紹介先病院サーバ１に提供することが可能となる。

（作用効果）
以上詳述したように一実施形態に係る情報流通システムでは、要求側サーバ１の機能として、テーブル設定ファイル４１により個々のテーブルに関する定義情報を管理することで、自サーバ１内でテーブルをアクセスするときにはローカルデータアクセス部１３を、他サーバとの間でデータのやり取りをするときには通信にＩＤ−ＷＳＦを用いたリモートデータアクセス部１４をそれぞれ選択してデータアクセスを行うようにし、かつローカルデータアクセス部１３とリモートデータアクセス部１４で提供するアプリケーションインタフェースを共通化するようにしている。

したがって、テーブル設定ファイル４１で管理されている個々のテーブルの格納場所に関する情報により、呼び出すアプリケーションを特定することができ、データベースに格納されているテーブルの情報をテーブル設定ファイル４１に記載することで、データの操作や定義を行なうデータベース言語の知識がなくても容易にシステムを構築することが可能となる。また、Ｗｅｂ画面作成からデータ取得まで、画面情報定義ファイル４３やテーブル設定ファイル４１に必要な項目を記述するといった一貫した手法によりサービスを実現することができる。

さらに、テーブル設定ファイル４１において、個人情報を含むテーブルに「個人情報」である旨のフラグを立てることにより、アクセス日時やアクセスした人の情報を監査ログとして簡単かつ確実に出力することが可能となる。すなわち、システムを構築する際に、監査に必要な情報を意識することなく監査ログを生成する仕組みを提供することが可能となる。

なお、この発明は上記実施形態に限定されるものではない。例えば、前記実施形態では病院サーバ間で患者の情報を流通させるシステムを例に説明したが、企業等において従業員の勤務データや評価データ等の個人情報を流通させるシステムや、決裁文書や会議データ等を部署間又は事業所間で流通させるシステムにも適用可能である。

要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。

１…要求側サーバ、２…提供側サーバ、３…連携サーバ、４…クライアント端末、５…ネットワーク、１１，２１，３１…Ｗｅｂアクセス受付部、１２，２２，３２…アクセス制御判定部、１３，２３，３３…ローカルデータアクセス部、１４，２４，３４…リモートデータアクセス部、１５，２５，３５…ユーザ情報格納部、１６，２６，３６…アプリケーションデータ格納部、３７…システム情報格納部、３８…マスタ情報格納部、４０…Ｗｅｂブラウザ、４１…テーブル設定ファイル、４２…ＵＲＬマッピング情報設定ファイル、４３…画面情報定義ファイル、５１…Ｗｅｂ画面コンポーネントの本体部、５２…ヘッダ部、５３…フッタ部、１１１…ＵＲＬ解析部、１１２…Ｗｅｂアクセス処理部、１１３…通信データ作成部、５１１…概要説明部、５１２…テーブル表示部、５１３…ボタン表示部、５１４…リンク表示部。

Claims (7)

1. クライアント端末に接続されサービスの要求側となる第１の情報処理装置と、サービスの提供側となる第２の情報処理装置と、これら第１及び第２の情報処理装置間をネットワークを介して連携させる第３の情報処理装置とを具備する情報流通システムにおいて、前記第１、第２及び第３の情報処理装置は、
   システムが保有するテーブルデータの各々についてシステム内における格納場所を示す情報を少なくとも定義したテーブル設定ファイルを記憶する手段と、
   前記クライアント端末からテーブルデータに対するアクセス要求が送られた場合に、アクセス先となるテーブルデータの格納場所が自己の情報処理装置内であるか他の情報処理装置であるかを、前記記憶されたテーブル設定ファイルに基づいて判定する判定手段と、
   前記クライアント端末の入力に基づいて実行されるデータ処理の機能ごとに予め設定され、当該データ処理を実行するために必要なパラメータが入力される第１のアプリケーションインタフェースを有し、前記アクセス先となるテーブルデータの格納場所が他の情報処理装置であると判定された場合、及び他の情報処理装置からアクセスに必要な情報が送られてきた場合に動作して、前記第１のアプリケーションインタフェースの制御の下、前記情報処理装置間でデータの授受を行うリモートデータアクセス手段と、
   前記リモートデータアクセス手段が有する前記第１のアプリケーションインタフェースと共通のデータ処理の機能ごとに予め設定され、当該データ処理を実行するために必要なパラメータが入力される第２のアプリケーションインタフェースを有し、前記アクセス先となるテーブルデータの格納場所が自己の情報処理装置内であると判定された場合、及び自己の情報処理装置のリモートデータアクセス手段からアクセス要求を受け取った場合に動作して、前記第２のアプリケーションインタフェースの制御の下、自己の情報処理装置内に格納されている該当するテーブルデータに対しアクセスし、前記クライアント端末からの入力パラメータに基づいて特定されたデータについて前記第２のアプリケーションインタフェースに設定されたデータ処理機能を実行するローカルデータアクセス手段と
   を備えたことを特徴とする情報流通システム。
2. 前記第１、第２及び第３の情報処理装置のリモートデータアクセス手段は、情報処理装置間でデータ転送を行う際にＩＤ−ＷＳＦ（Identity Web Service Framework）を用いることを特徴とする請求項１記載の情報流通システム。
3. 前記テーブル設定ファイルを記憶する手段は、テーブルデータの各々について当該テーブルデータが個人情報を含むか否かを表す情報をさらに記憶し、
   前記第１及び第２の情報処理装置は、
   前記ローカルデータアクセス手段又はリモートデータアクセス手段からアクセス結果を表す情報を受け取った場合に、当該アクセス先となったテーブルデータが個人情報を含むか否かを前記テーブル設定ファイルに基づいて判定し、個人情報を含むと判定された場合に監査ログを生成する手段を
   さらに備えることを特徴とする請求項１記載の情報流通システム。
4. クライアント端末に接続されサービスの要求側となる第１の情報処理装置と、サービスの提供側となる第２の情報処理装置との間を、連携用の第３の情報処理装置を介して連携させる情報流通システムで使用される前記第１、第２及び第３の情報処理装置であって、
   システムが保有するテーブルデータの各々についてシステム内における格納場所を示す情報を少なくとも定義したテーブル設定ファイルを記憶する手段と、
   前記クライアント端末から前記テーブルデータに対するアクセス要求が送られた場合に、アクセス先となるテーブルデータの格納場所が自己の情報処理装置内であるか他の情報処理装置であるかを、前記記憶されたテーブル設定ファイルに基づいて判定する判定手段と、
   前記クライアント端末の入力に基づいて実行されるデータ処理の機能ごとに予め設定され、当該データ処理を実行するために必要なパラメータが入力される第１のアプリケーションインタフェースを有し、前記アクセス先となるテーブルデータの格納場所が他の情報処理装置であると判定された場合、及び他の情報処理装置からアクセスに必要な情報が送られてきた場合に動作して、前記第１のアプリケーションインタフェースの制御の下、前記情報処理装置間でデータの授受を行うリモートデータアクセス手段と、
   前記リモートデータアクセス手段が有する前記第１のアプリケーションインタフェースと共通のデータ処理の機能ごとに予め設定され、当該データ処理を実行するために必要なパラメータが入力される第２のアプリケーションインタフェースを有し、前記アクセス先となるテーブルデータの格納場所が自己の情報処理装置内であると判定された場合、及び自己の情報処理装置のリモートデータアクセス手段からアクセス要求を受け取った場合に動作して、前記第２のアプリケーションインタフェースの制御の下、自己の情報処理装置内に格納されている該当するテーブルデータに対しアクセスし、前記クライアント端末からの入力パラメータに基づいて特定されたデータについて前記第２のアプリケーションインタフェースに設定されたデータ処理機能を実行するローカルデータアクセス手段と
   を具備することを特徴とする情報処理装置。
5. 前記第１、第２及び第３の情報処理装置のリモートデータアクセス手段は、情報処理装置間でデータ転送を行う際にＩＤ−ＷＳＦ（Identity Web Service Framework）を用いることを特徴とする請求項４記載の情報処理装置。
6. 前記テーブル設定ファイルを記憶する手段は、テーブルデータの各々について当該テーブルデータが個人情報を含むか否かを表す情報をさらに記憶し、
   前記ローカルデータアクセス手段又はリモートデータアクセス手段からアクセス結果を表す情報を受け取った場合に、当該アクセス先となったテーブルデータが個人情報を含むか否かを前記テーブル設定ファイルに基づいて判定し、個人情報を含むと判定された場合に監査ログを生成する手段を
   さらに具備することを特徴とする請求項４記載の情報処理装置。
7. クライアント端末に接続されサービスの要求側となる第１の情報処理装置と、サービスの提供側となる第２の情報処理装置との間を、連携用の第３の情報処理装置を介して連携させる情報流通システムで使用される前記第１及び第２の情報処理装置による情報処理方法であって、
   システムが保有するテーブルデータの各々についてシステム内における格納場所を示す情報を少なくとも定義したテーブル設定ファイルを記憶する過程と、
   前記クライアント端末から前記テーブルデータに対するアクセス要求が送られた場合に、アクセス先となるテーブルデータの格納場所が自己の情報処理装置内であるか他の情報処理装置であるかを、前記記憶されたテーブル設定ファイルに基づいて判定する過程と、
   前記アクセス先となるテーブルデータの格納場所が他の情報処理装置であると判定された場合、及び他の情報処理装置からアクセスに必要な情報が送られてきた場合に、前記クライアント端末の入力に基づいて実行されるデータ処理の機能ごとに予め設定され、当該データ処理を実行するために必要なパラメータが入力される第１のアプリケーションインタフェースの下で動作して、前記情報処理装置間でデータの授受を行うリモートデータアクセス処理過程と、
   前記アクセス先となるテーブルデータの格納場所が自己の情報処理装置内であると判定された場合、及び自己の情報処理装置のリモートデータアクセス処理によりアクセス要求を受け取った場合に、前記第１のアプリケーションインタフェースと共通のデータ処理の機能ごとに予め設定され、当該データ処理を実行するために必要なパラメータが入力される第２のアプリケーションインタフェースの下で動作して、自己の情報処理装置内に格納されている該当するテーブルデータに対しアクセスし、前記クライアント端末からの入力パラメータに基づいて特定されたデータについて前記第２のアプリケーションインタフェースに設定されたデータ処理機能を実行するローカルデータアクセス処理過程と
   を具備することを特徴とする情報処理方法。

Images