(57)【要約】【課題】異なる属性情報流通方式を採用したWebアプリケーション間で簡便かつセキュリティを担保した属性情報の流通を実現できるようにする。【解決手段】ゲートウエイ１に翻訳テーブル１１、翻訳処理部１２及び変換処理部１３を設ける。先ず属性情報流通方式の変換方向を表す情報を取得して、翻訳テーブル１１内の方式マスタテーブルからリンク情報fidを取得する。次に、この取得されたfidで定義された構文分割テーブルを参照して上記受信されたリクエストを構文分割し、この分割された各文からパラメータ変換用コードを抽出する。続いてこのパラメータ変換用コードをもとにパラメータ翻訳テーブルから翻訳情報を取得し、かつこの翻訳情報をもとに異なる情報流通方式として対応のないパラメータを判定する。そして、変換後の属性情報流通方式に必要なパラメータを該当箇所に埋め込むと共に、パラメータの補完及び除外を行なう。【選択図】図１
2014016960.tif 000002
【特許請求の範囲】
【請求項１】
第１の情報流通方式を採用したアプリケーションを有する第１の装置と、前記第１の情報流通方式と異なる第２の情報流通方式を採用したアプリケーションを有する第２の装置との間で、属性情報の流通を中継する中継装置であって、
前記第１の情報流通方式で使用される第１のパラメータと前記第２の情報流通方式で使用される第２のパラメータとを、対応するもの同士で相互に関連付けて記憶するパラメータ翻訳テーブルと、
前記第１の装置から第１の情報通信方式によるリクエスト又はレスポンスを受信した場合に、当該リクエスト又はレスポンスに含まれる第１のパラメータに対応する第２のパラメータを前記パラメータ翻訳テーブルから検索するパラメータ検索手段と、
前記パラメータ検索手段による検索結果をもとに、前記第２の情報流通方式において必要なパラメータと不要なパラメータを判定する整合性判定手段と、
前記受信されたリクエスト又はレスポンスに含まれる第１のパラメータを、前記パラメータ翻訳テーブルから検索された第２のパラメータに変換する変換処理手段と、
前記第２の情報流通方式において必要と判定されたパラメータを、前記受信されたリクエスト又はレスポンスに対し補完する補完処理手段と、
前記第２の情報流通方式において不要と判定されたパラメータを、前記受信されたリクエスト又はレスポンスから除外する除外処理手段と、
前記変換、補完及び除外の少なくとも一つの処理が行われた後の、前記第２の情報流通方式に対応するリクエスト又はレスポンスを、前記第２の装置に向け送信する送信手段と
を具備することを特徴とする中継装置。
【請求項２】
前記第１及び第２の情報流通方式がそれぞれ複数の情報流通方式を含む場合に、前記第１の装置から送信されるリクエスト又はレスポンスについて、どの情報流通方式のリクエスト又はレスポンスからどの情報流通方式のリクエスト又はレスポンスに変換するのかを表す変換方向情報を取得する変換方向取得処理手段を、さらに具備し、
前記パラメータ検索手段は、前記第１の装置からリクエスト又はレスポンスを受信した場合に、前記変換方向取得処理手段により取得された変換方向情報に基づいて前記パラメータ翻訳テーブルから変換対象となるパラメータ群を選択し、この選択されたパラメータ群の中から前記受信されたリクエスト又はレスポンスに含まれる第１のパラメータに対応する第２のパラメータを検索することを特徴とする請求項１記載の中継装置。
【請求項３】
前記変換方向ごとに、第１の情報流通方式によるリクエスト又はレスポンスの構文を分割するための分割ルールが記憶された構文分割テーブルを、さらに具備し、
前記パラメータ検索手段は、
前記第１の装置からリクエスト又はレスポンスを受信した場合に、前記変換方向情報をもとに前記構文分割テーブルから分割ルールを選択し、当該選択された分割ルールに従い、前記受信されたリクエスト又はレスポンスを複数の構文に分割する構文分割手段と、
前記分割された構文ごとに前記第１のパラメータを抽出し、当該抽出された第１のパラメータに対応する第２のパラメータを、前記パラメータ翻訳テーブルから読み出す読出手段と
を備えることを特徴とする請求項２記載の中継装置。
【請求項４】
第１の情報流通方式を採用したアプリケーションを有する第１の装置と、前記第１の情報流通方式と異なる第２の情報流通方式を採用したアプリケーションを有する第２の装置との間で、属性情報の流通を中継する中継方法であって、
前記第１の情報流通方式で使用される第１のパラメータと前記第２の情報流通方式で使用される第２のパラメータとを、データタイプ別に対応するもの同士で相互に関連付けてパラメータ翻訳テーブルに記憶する過程と、
前記第１の装置から第１の情報流通方式によるリクエスト又はレスポンスを受信した場合に、当該リクエスト又はレスポンスに含まれる第１のパラメータに対応する第２のパラメータを前記パラメータ翻訳テーブルから検索する過程と、
前記第２のパラメータを検索する過程による検索結果をもとに、前記第２の情報流通方式において必要なパラメータと不要なパラメータを判定する過程と、
前記受信されたリクエスト又はレスポンスに含まれる第１のパラメータを、前記パラメータ翻訳テーブルから検索された第２のパラメータに変換する過程と、
前記第２の情報流通方式において必要と判定されたパラメータを、前記受信されたリクエスト又はレスポンスに対し補完する過程と、
前記第２の情報流通方式において不要と判定されたパラメータを、前記受信されたリクエスト又はレスポンスから除外する過程と、
前記変換、補完及び除外の少なくとも一つの処理が行なわれた後の、前記第２の情報流通方式に対応するリクエスト又はレスポンスを、前記第２の装置に向け送信する過程と
を具備することを特徴とする中継方法。
【請求項５】
前記第１及び第２の情報流通方式がそれぞれ複数の情報流通方式を含む場合に、前記第１の装置から送信されるリクエスト又はレスポンスについて、どの情報流通方式のリクエスト又はレスポンスからどの情報流通方式のリクエスト又はレスポンスに変換するのかを表す変換方向情報を取得する過程を、さらに具備し、
前記パラメータを検索する過程は、前記第１の装置からリクエスト又はレスポンスを受信した場合に、前記取得された変換方向情報に基づいて前記パラメータ翻訳テーブルから変換対象となるパラメータ群を選択し、この選択されたパラメータ群の中から前記受信されたリクエスト又はレスポンスに含まれる第１のパラメータに対応する第２のパラメータを検索することを特徴とする請求項４記載の中継方法。
【請求項６】
前記変換方向ごとに、第１の情報流通方式によるリクエスト又はレスポンスの構文を分割するための分割ルールを構文分割テーブルに記憶させる過程を、さらに具備し、
前記パラメータを検索する過程は、
前記第１の装置からリクエスト又はレスポンスを受信した場合に、前記変換方向情報をもとに前記構文分割テーブルから分割ルールを選択し、当該選択された分割ルールに従い、前記受信されたリクエスト又はレスポンスを複数の構文に分割する過程と、
前記分割された構文ごとに前記第１のパラメータを抽出し、当該抽出された第１のパラメータに対応する第２のパラメータを、前記パラメータ翻訳テーブルから読み出す過程と
を備えることを特徴とする請求項５記載の中継方法。
【請求項７】
請求項１乃至３のいずれかに記載の中継装置が具備する手段による処理を、当該中継装置が備えるコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、異なる属性情報流通方式を採用するWebアプリケーション間でユーザ属性情報を流通させる属性情報流通システムで使用される中継装置、方法及びプログラムに関する。
【背景技術】
【０００２】
複数のWebアプリケーション間でユーザの属性情報を交換する方式として、ID-WSF方式とOpen ID AX方式が知られている。これらの方式は、セキュリティを優先するか、ユーザビリティを優先するかなど、属性情報の取扱い方法によってどちらを採用するかが決められることが多い。
【０００３】
一般的に、ID-WSF方式は、複数のWeb上のアプリケーション間でユーザの属性情報を安全に交換する方法をとる場合に多く採用され、医療情報の流通などで活用されている（以後非特許文献１と称する）。一方、Open ID AX方式は複数のWeb上のアプリケーション間において、ユーザを１つのＩＤで共通化し、簡易に多様なサービスと結びつける方法をとる場合に多く採用され、ヘルスケア情報とショッピングをうまく連携できるように、ヘルスケアサイトとＥＣ（Electronic Commerce）サイトにおけるアカウント情報の共通化などで活用されている（以後非特許文献２と称する）。
【０００４】
この様に属性情報の取扱方法によってどちらの方式を採用するか決められている現状ではあるが、今後より利便性の高いサービスを提供するために、流通する属性情報のライフサイクルの各段階において属性情報の取扱方法を変えていくといった手段を取ることが求められている。
【０００５】
例えば、病院などの医療機関で生成・管理された医療情報が、法令に定める一定の期間を満たした場合に、医療機関の管理義務はなくなり削除されることがある。その際、医療機関での管理責任が無くなった医療情報を患者に渡し、ヘルスケアサイト等と併せて健康意識の向上に役立てるというビジネスモデルが提案されている。また、今後のＩＴ技術の革新により、セキュリティの観点を情報流通のレイヤではなく、ＮＷや認証などのレイヤで制御することが主流になる可能性もある。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】Liberty ID-WSF 2.0 Marketing Requirements Document Version: 1.0、インターネット＜URL: http://www.projectliberty.org/liberty/strategic_initiatives/requirements/?f=liberty/strategic_initiatives/requirements＞
【非特許文献２】Open ID Attribute Exchange 1.0-最終版、インターネット＜URL: http://openid-foundation-japan.github.com/openid-attribute-exchange.html#store_request＞
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、異なる属性情報流通方式を採用したWebアプリケーション間で属性情報の流通を実現するには、この異なるWebアプリケーション間で流通するリクエスト・レスポンスを翻訳する仕組みが必要となる。単一方式の中でバージョン差異がある場合に限れば、改編部分を定義して、リクエスト・レスポンスを翻訳・変換することで互換性を担保する方法は提案されている。しかし、異なる属性情報流通方式を採用しているWebアプリケーションで連携する仕組みが求められている現在においては、上記を考慮した提案は見られない。
【０００８】
現段階において、異なる属性情報流通方式を採用しているWebアプリケーション間を連携させる方法としては、以下の方法が提案されている。  
第１の方法は、データベースの様な情報を蓄積している記憶領域を直接参照し、もう一方のデータベースに反映させていくという方法である。この方法は手間がかかる分だけ、間違いが起こる可能性を増やす。また、一般の利用者にその動作を求めるのは現実的でない。
【０００９】
第２の方法は、異なるWebアプリケーションが管理する情報蓄積領域に格納可能な形式で情報を外部に出力し、その情報を改めて入力するという方法である。この方法は、データベースの閲覧と反映の手間を改善することができるが、情報連携システムでセキュリティを向上させても、一旦外部に出力されるため情報のライフサイクルを追跡できず、結果として情報漏洩のリスクを高めてしまう。
【００１０】
すなわち、異なる属性情報流通方式間におけるWebアプリケーションの連携では、より簡便かつセキュリティを担保した方法を取る必要があり、システム内で閉じた異なる属性情報流通方式間のリクエスト・レスポンスを連携させることが切望されている。具体的には、単一方式間のバージョン変更対応の様な特定の領域のみの翻訳・変換ではなく、必須・オプションなどの情報の取扱いの違い等を含めた翻訳・変換処理技術の確立が望まれている。また、属性情報流通方式として、独自方式を採用するWebアプリケーションも適宜連携を取れるような、独自方式とOpen ID AX方式或いはID-WSF方式との間のリクエスト・レスポンスの翻訳・変換処理技術を実現することも望まれている。
【００１１】
この発明は上記事情に着目してなされたもので、その目的とするところは、異なる属性情報流通方式を採用したWebアプリケーション間で簡便かつセキュリティを担保した属性情報の流通を実現できるようにした属性情報流通システムの中継装置、方法及びプログラムを提供することにある。
【課題を解決するための手段】
【００１２】
上記目的を達成するためにこの発明の１つの観点は、第１の情報流通方式を採用したアプリケーションを有する第１の装置と、上記第１の情報流通方式と異なる第２の情報流通方式を採用したアプリケーションを有する第２の装置との間で、属性情報の流通を中継する中継装置にあって、上記第１の情報流通方式で使用される第１のパラメータと上記第２の情報流通方式で使用される第２のパラメータとを、対応するもの同士で相互に関連付けて記憶するパラメータ翻訳テーブルを備える。そして、第１の装置から第１の情報流通方式によるリクエスト又はレスポンスを受信した場合に、当該リクエスト又はレスポンスに含まれる第１のパラメータに対応する第２のパラメータを上記パラメータ翻訳テーブルから検索し、上記受信されたリクエスト又はレスポンスに含まれる第１のパラメータを、上記検索された第２のパラメータに変換する。また、上記パラメータの検索結果をもとに、上記第２の情報流通方式において必要なパラメータと不要なパラメータを判定し、必要と判定されたパラメータを上記受信されたリクエスト又はレスポンスに対し補完すると共に、不要と判定されたパラメータを上記受信されたリクエスト又はレスポンスから除外し、この変換、補完及び除外の少なくとも一つの処理が行われた後の第２の情報流通方式に対応するリクエスト又はレスポンスを、上記第２の装置に向け送信するようにしたものである。
【００１３】
具体的には、上記第１及び第２の情報流通方式がそれぞれ複数の情報流通方式を含む場合に、上記第１の装置から送信されるリクエスト又はレスポンスについて、どの情報流通方式のリクエスト又はレスポンスからどの情報流通方式のリクエスト又はレスポンスに変換するのかを表す変換方向情報を取得する。そして、上記第１の装置からリクエスト又はレスポンスを受信した場合に、上記取得された変換方向情報に基づいて上記パラメータ翻訳テーブルから変換対象となるパラメータ群を選択し、この選択されたパラメータ群の中から上記受信されたリクエスト又はレスポンスに含まれる第１のパラメータに対応する第２のパラメータを検索する。  
したがって、第１及び第２の情報流通方式がそれぞれ複数の情報流通方式を含む場合でも、使用される情報流通方式に応じたパラメータ変換を行なうことができる。
【００１４】
また、上記第１の情報流通方式によるリクエスト又はレスポンスの構文を分割するための分割ルールが記憶された構文分割テーブルをさらに備え、上記パラメータを検索する際に、第１の装置から第１の情報流通方式によるリクエスト又はレスポンスを受信した場合に、当該リクエスト又はレスポンスを上記構文分割テーブルに記憶された分割ルールに従い複数の文に分割し、この分割された文ごとに上記第１のパラメータを抽出する。そして、この文ごとに抽出された第１のパラメータに対応する第２のパラメータを上記パラメータ翻訳テーブルから読み出すようにしている。  
したがって、ゲートウエイ等の既存の中継装置を利用して、ここでリクエスト・レスポンスの翻訳・変換処理をさらに行なうことで、異なる属性情報流通方式を採用したWebアプリケーション間で属性情報の流通に必要なリクエスト・レスポンスの連携が可能になる。これにより、それぞれの属性情報流通方式が持つメリットを状況に応じて使い分けることが可能になる。
【発明の効果】
【００１５】
すなわちこの発明の１つの観点によれば、異なる属性情報流通方式を採用したWebアプリケーション間で簡便かつセキュリティを担保した属性情報の流通を実現することができる属性情報流通システムの中継装置、方法及びプログラムを提供することができる。
【図面の簡単な説明】
【００１６】
【図１】この発明の一実施形態に係る属性情報流通システムの全体構成と、このシステムが中継装置として備えるゲートウエイの機能構成を示すブロック図。
【図２】図１に示したシステムにおけるOpen ID AX方式の属性情報リクエストをID-WSF方式のリクエストに変換する処理の手順と内容を示す図。
【図３】図１に示したシステムにおけるID-WSF方式の属性情報レスポンスをOpen ID AX方式のレスポンスに変換する処理の手順と内容を示す図。
【図４】図１に示した中継機器の翻訳テーブルに設けられる方式マスタテーブルの一例を示す図。
【図５】図１に示した中継機器の翻訳テーブルに設けられる構文分割テーブルの一例を示す図。
【図６】図１に示した中継機器の翻訳テーブルに設けられるパラメータ翻訳テーブルの一例を示す図。
【図７】図１に示したシステムにおいて、Open ID AX方式を採用したWebアプリケーション同士で属性情報を流通させるときの動作を説明するための図。
【図８】図１に示したシステムにおいてOpen ID AX方式を採用したWebアプリケーションとID-WSF方式を採用したWebアプリケーションとの間で属性情報を流通させるときの動作を説明するための図。
【図９】図８に示した動作のうち中継機器における動作を説明するための図。
【発明を実施するための形態】
【００１７】
以下、図面を参照してこの発明に係わる実施形態を説明する。  
［一実施形態］
（構成）
この発明の一実施形態に係る属性情報流通システムの全体構成と、このシステムが中継装置として備えるゲートウエイの機能構成を示すブロック図である。  
本実施形態のシステムは、データ要求（ＲＰ; Relying Party）サーバ２と、データ提供（ＯＰ; OpenID Provider）サーバ３と、データ格納場所提供（ＤＳ; Discovery Service）サーバ４と、データ共有（ＷＳＣ／ＷＳＰ; Web Service Consumer／Web Service Provider）サーバ５と、データ共有（独自ＡＰＩ; Application）サーバ６を備え、これらのサーバ２〜６間で中継装置としてのゲートウエイ１を介してデータ転送を行うように構成されている。なお、上記各サーバ２〜６の代わりに、同等の機能を備えるパーソナル・コンピュータを使用することも可能である。
【００１８】
データ要求（ＲＰ）サーバ２は、OpenID AX方式を採用したWebアプリケーションを使用するもので、一般ユーザの要求操作に応じて属性情報の提供を要求するデータ要求を生成し、このデータ要求をOpenID AX方式によりデータ提供（ＯＰ）サーバ２へ送信する機能を有する。
【００１９】
データ提供（ＯＰ）サーバ３も、OpenID AX方式を採用したWebアプリケーションを使用し、上記OpenID AX方式によるデータ要求を受信した場合に、要求先が自サーバであれば該当するデータを検索してその検索結果をデータ応答としてOpenID AX方式により要求元のデータ要求（ＲＰ）サーバ２へ応答する機能を備える。
【００２０】
またデータ提供（ＯＰ）サーバ３は、要求先が他の属性情報流通方式を採用したＷｅｂアプリケーションサーバを使用するサーバであれば、上記データ要求をOpenID AX方式によりゲートウエイ１へ転送すると共に、当該要求に対しゲートウエイ１からOpenID AX方式により返送されたデータ応答を、OpenID AX方式により要求元のデータ要求（ＲＰ）サーバ２へ返送する機能を有する。
【００２１】
データ格納場所提供（ＤＳ）サーバ４は、ID-WSF方式を採用したWebアプリケーションを使用するもので、ID-WSF方式によるデータ要求に対し該当する属性情報の存在場所を表すデータを提供する機能を有する。
【００２２】
データ共有（ＷＳＣ／ＷＳＰ）サーバ５は、ID-WSF方式を採用したWebアプリケーションを使用し、ID-WSF方式によるＷＳＣとしての機能と、ID-WSF方式によるＷＳＰとしての機能をそれぞれ実行する。
【００２３】
データ共有（独自ＡＰＩ）サーバ６は、独自のWebアプリケーションを使用するもので、一般ユーザの操作に応じて生成されたデータ要求を独自API方式によりゲートウエイ１に送信すると共に、ゲートウエイ１から独自API方式により返送されたデータ応答を受信する機能を有する。
【００２４】
ところで、ゲートウエイ１はこの発明の一実施形態を実現するための機能として、OpenID AX方式により上記データ要求（ＲＰ; Relying Party）及びデータ提供（ＯＰ; OpenID Provider）を実行する機能と、ID-WSF方式により上記データ共有（ＷＳＣ／ＷＳＰ; Web Service Consumer／Web Service Provider）を実行する機能に加え、異なる属性情報流通方式を採用したWebアプリケーション間で属性情報流通のためのリクエスト・レスポンスを連携させる機能を有している。
この異なる属性情報流通方式間で属性情報流通リクエスト・レスポンスを連携させる機能は、翻訳テーブル１１と、翻訳処理部１２と、変換処理部１３とにより実現される。このうち、翻訳処理部１２及び変換処理部１３の機能は、図示しないプログラムメモリに格納されたアプリケーション・プログラムを中央処理ユニット（ＣＰＵ）に実行させることにより実現される。
【００２５】
翻訳テーブル１１は、方式マスタテーブルと、構文分割テーブルと、パラメータ翻訳テーブルとを備える。方式マスタテーブルには、翻訳処理部１２および変換処理部１３が属性情報流通方式の種類を特定してリクエスト・レスポンスに対する翻訳・変換処理を行うための、属性情報流通方式とその識別情報fidとを関連付けた情報が記憶されている。図４はその一例を示す図であり、fid＝１に関連付けてID-WSF方式を表す情報が、またfid＝２に関連付けてOpenID AX方式が表す情報がそれぞれ記憶されている。
【００２６】
構文分割テーブルには、翻訳処理部１２および変換処理部１３がリクエスト・レスポンスの構文切り分け処理を実施する際に、情報流通方式ごとにどう切り分け処理を行えばよいかを示す分割方法（分割ルール）が記載されている。図５はその一例を示すもので、図４の方式マスタテーブルにfid＝２として定義されたOpenID AX方式の場合の構文分割ルールを例示している。同図において、“definition”はOpenID AX方式の用途として定義された文字列を表し、また“format”はリクエストの構文中に記述される上記用途ごとの文字列を表している。さらに“data_type”は、翻訳・変換処理においての取扱い方針を記載したもので、[def]は属性情報流通方針の定義に関わる値、[data]は属性情報流通対象の値、[data_variation]は属性情報流通対象の値の取扱いに関する値、[input]は対象となる属性情報の範囲などを指定する条件値をそれぞれ示している。
【００２７】
パラメータ翻訳テーブルには、翻訳処理部１２および変換処理部１３が構文分割処理後に抽出されたパラメータをどのような名義に変換するのかを示す情報が記憶されている。図６はその一例を示すもので、リクエストをOpenID AX方式からID-WSF方式に翻訳・変換する場合において、“data_type”ごとに変換前のリクエストフォーム（“request_from”）と、変換後のリクエストフォーム（“request_to”）と、リクエストの成形処理内容を表す“action”とを関連付けたものである。
【００２８】
“action”としては、[loop]、[delete]及び[keep]が定義されている。[loop]は、主に属性情報流通対象に関する取扱いに用いるもので、「要求する属性情報毎に、属性情報流通リクエスト文を複数整形する」といった、翻訳結果を変換する際にリクエストを複数回繰り返しの整形する処理である。[delete]は、“data_type”によらず、変換前のリクエスト文に含まれていたパラメータを変換後に除外するように整形する処理である。[keep]は、主に属性情報流通対象の件数や範囲を制限する様な条件に用いるもので、パラメータに付随している値をパラメータ名の翻訳後もそのまま引き継ぐようにリクエスト文を整形する処理である。
【００２９】
翻訳処理部１２は、変換方向取得処理部と、構文分割処理部と、パラメータ検索処理部と、整合性判定処理部を有している。変換方向取得処理部は、変換前のリクエストが、どの属性情報流通方式からどの属性情報流通方式への変更を要求するものであるか、つまり方式の変換方向を判定する。
【００３０】
構文分割処理部は、変換前のリクエスト又はレスポンスを上記構文分割テーブルに記載された構文分割ルールに従い複数の文に切り分ける。パラメータ検索処理部は、上記構文分割処理部により切り分けられた文からパラメータを抽出し、この抽出したパラメータに対応する変換後のパラメータをパラメータ翻訳テーブルから読み込む。
【００３１】
整合性判定処理部は、異なる情報流通方式間で対応のとれないパラメータの有無を判定し、変換後の属性情報流通方式の仕様として補完するパラメータと、除外するパラメータがないかどうかを確認する。補完するパラメータが存在する場合には、対象とするパラメータを定義している箇所を出力する。除外するパラメータが存在する場合も、同様にパラメータを定義している箇所を出力する。整合性を確認した後、整合がとれている場合にはそのまま変換可能である旨を変換処理部１３に渡し、不整合がある場合には補完するパラメータ情報、或いは除外するパラメータ情報を併せて変換処理部１３に渡す。
【００３２】
変換処理部１３は、パラメータ変換処理部と、補完処理部と、除外処理部を有している。パラメータ変換処理部は、上記翻訳処理部１２からその処理結果を受取り、上記パラメータ検索処理部によって翻訳テーブル１１から読み込まれたパラメータを、変換前のパラメータに代えてリクエスト文又はレスポンス文中に埋め込む。
【００３３】
補完処理部は、上記整合性判定処理部によって変換後の情報流通方式に必要であると判断されたパラメータを補完する。除外処理部は、上記整合性判定処理部によって変換後の情報流通方式に不要であると判断されたパラメータをリクエスト文に記載せず、当該リクエストに対するレスポンスの変換処理のために記憶領域に一時保存する。
【００３４】
（動作）
次に、以上のように構成されたシステムの動作を、ゲートウエイ１の動作を中心に説明する。  
（１）OpenID AX方式を採用したWebアプリケーション間で属性情報を流通させる場合
ここでは、例えばデータ要求（ＲＰ）サーバ２からデータ提供（ＯＰ）サーバ３へ属性情報流通リクエストを送信し、この属性情報流通リクエストに応答してデータ提供（ＯＰ）サーバ３が要求元のデータ要求（ＲＰ）サーバ２へレスポンスを返送する場合について述べる。
【００３５】
図７は、データ要求（ＲＰ）サーバ２からデータ提供（ＯＰ）サーバ３へ送信される属性情報流通リクエストと、このリクエストに応答してデータ提供（ＯＰ）サーバ３が要求元のデータ要求（ＲＰ）サーバ２へ返送される属性情報に対する操作結果を表すレスポンスの一例を示すものである。
【００３６】
この例では、データ要求（ＲＰ）サーバ２が、「氏名」と「カルテ情報」を必須とし、「レセプト情報」をオプションとして属性情報の操作を要求するリクエスト文を生成し、このリクエストをデータ提供（ＯＰ）サーバ３へ送信している。これに対しデータ提供（ＯＰ）サーバ３は、上記リクエストの内容に応じて、該当する「氏名」と「カルテ情報」、及び「レセプト情報」をデータベースから読み出し、この読み出された情報をレスポンスとしてデータ要求（ＲＰ）サーバ２へ返送している。
【００３７】
すなわち、データ要求（ＲＰ）サーバ２とデータ提供（ＯＰ）サーバ３との間では、OpenID AX方式のみを使用した、つまりOpenID AX方式で閉じられた属性情報の流通処理が行なわれることになり、したがって情報流通方式間のリクエスト・レスポンスの変換は行なわれない。
【００３８】
（２）OpenID AX方式を採用したWebアプリケーションと、ID-WSF方式を採用したWebアプリケーションとの間で、属性情報流通のためのリクエスト・レスポンスを連携させる場合
（２−１）OpenID AX方式からID-WSF方式へのリクエストの変換
ここでは、一般ユーザがデータ要求（ＲＰ）サーバ２において、データ共有（ＷＳＣ・ＷＳＰ）サーバ５が管理している属性情報を操作（作成、参照、修正又は削除）する場合を例にとって説明を行なう。
【００３９】
データ要求（ＲＰ）サーバ２から送信されたOpenID AX方式による属性情報流通リクエストは、データ提供（ＯＰ）サーバ３を経由してゲートウエイ１に転送される。ゲートウエイ１は、上記OpenID AX方式による属性情報流通リクエストをＯＰ（OpenID Provider）として受信すると、図２に示すように先ず翻訳処理部１２が翻訳テーブル１１を参照して以下のように翻訳処理を実行する。
【００４０】
すなわち、先ず変換方向取得処理部により、どの属性情報流通方式によるリクエストをどの属性情報流通方式によるリクエストに変換するのかを表す情報を取得する。このとき取得する情報は、一般ユーザがデータ要求（ＲＰ）サーバ２からリクエストを出したタイミングで取得してもよいし、また変換が必要になったタイミングでゲートウエイ１からデータ要求（ＲＰ）サーバ２に対し問い合わせ取得するようにしてもよい。この問い合わせにより取得するアプリケーションは、ゲートウエイ１に予めインストールしておく。
【００４１】
上記属性情報流通方式の変換方向を表す情報を取得できると、続いてこの取得された変換方向を表す情報をもとに、翻訳テーブル１１内の方式マスタテーブル（図４）を参照して、以後の翻訳・変換処理で使用するリンク情報fidを取得する。そして、方式マスタテーブルをもとに、上記受信されたリクエストを、“request from fid=2 to fid=1”といった形式で翻訳処理部１２の内部にコードとして保存し、構文分割処理部に渡す。なお、保存先は、ゲートウエイ１内の作業メモリ上でも、また設定ファイルに書き出すようにしても構わない。
【００４２】
上記リクエストの形式を表すコードを受取ると、構文分割処理部は“fid=2”で定義された構文分割テーブル（図５）を参照し、この構文分割テーブルに記憶された分割ルールに従い、上記受信されたリクエストを構文に従い分割する。この構文分割の結果、リクエストは“data_type”及び“format”にそれぞれ記載されたパラメータ変換用コードに分割され保存されたのち、パラメータ検索処理部に渡される。この場合も、保存先はゲートウエイ１内の作業メモリ上でも、また設定ファイルに書き出すようにしてもよい。
【００４３】
次に、上記パラメータ変換用コードを受取ったパラメータ検索処理部は、“request from fid=2 to fid=1”に関連付けられたパラメータ翻訳テーブルを参照し、翻訳情報を取得する。例えば、図６に示したパラメータ翻訳テーブルでは、OpenID AX方式のパラメータ変換用コード“medical record”に関連付けて、“medical record_A”が記憶されているので、この“medical record_A”を翻訳情報として読み出す。そして、この取得された翻訳情報は、“request_from”と“request_to”の対応が記載された整合性確認用コードとして保存された後、整合性判定処理部に渡される。この場合も、保存先はゲートウエイ１内の作業メモリ、設定ファイル上の何れでもよい。
【００４４】
続いて、上記整合性確認用コードを受け取った整合性判定処理部は、異なる情報流通方式として対応のないパラメータを判定し、変換後の属性情報流通方式の仕様として補完するパラメータと除外するパラメータの有無について確認する。この確認の結果、補完するパラメータが存在する場合には、対象とするパラメータを定義している箇所を抽出する。除外するパラメータが存在する場合にも、同様にパラメータを定義している箇所を抽出する。この整合性を確認した後、整合がとれている場合にはそのまま変換可能である旨を変換処理部１３に渡し、不整合がある場合には補完するパラメータ情報或いは除外するパラメータ情報を併せて変換処理部１３に渡す。
【００４５】
上記整合性判定処理部の確認結果を受け取ると変換処理部１３は、“request_from”と“request_to”の対応関係が記載された整合性確認用コードの通りに、パラメータを該当箇所に埋め込んでリクエスト文を整形する。例えば、上記したようにパラメータ変換コード“medical record”に対して、翻訳情報として“medical record_A”が取得された場合には、図９に示すように“medical record”に代えて、“medical record_A”が埋め込まれる。
【００４６】
また、それと共に補完するパラメータ情報を併せて受取った場合には、補完処理部によってそのコードに記載された情報を補完する機能に対し問い合わせを実施し、この問い合わせにより得られた結果をもとにリクエスト文を整形する。一般に、属性情報の流通は認証と併せて利用されることが多い。このため、属性情報の流通の条件として例えばユーザを指定する必要がある場合、既に認証済みであれば認証結果からパラメータを取得する。未認証であれば、認証処理を実施するように要求を出し、認証結果からパラメータを取得する。
【００４７】
さらに、除外するパラメータも併せて受取った場合には、除外処理部により、そのコードに記載された内容をリクエスト文には記載せず、当該リクエストに対するレスポンスの変換処理のために記憶領域に一時保存する。この場合も、保存先はゲートウエイ１内の作業メモリ又は設定ファイル上の何れでもよい。
【００４８】
かくして、OpenID AX方式による属性情報流通リクエストは、ゲートウエイ１においてID-WSF方式による属性情報流通リクエストに翻訳・変換される。そして、この変換後のID-WSF方式による属性情報流通リクエストは、ゲートウエイ１からデータ格納場所提供（ＤＳ）サーバ４、或いはデータ共有（ＷＳＣ・ＷＳＰ）サーバ５へ転送される。図８はデータ格納場所提供（ＤＳ）サーバ４へ属性情報流通リクエストを転送した場合の例を、また図９はデータ共有（ＷＳＣ・ＷＳＰ）サーバ５へ属性情報流通リクエストを転送した場合の例を示している。
【００４９】
（２−２）ID-WSF方式からOpenID AX方式へのレスポンスの変換
データ共有（ＷＳＣ／ＷＳＰ）サーバ５からID-WSF方式によりレスポンスが返送されると、ゲートウエイ１では以下のようにレスポンスをOpenID AX方式へ翻訳・変換する処理が行なわれる。図３はその処理手順を示し、また図８及び図９は具体例を示している。
【００５０】
すなわち、ゲートウエイ１は、図９に記載したようなID-WSF方式によるレスポンスを受信すると、先に述べたリクエストの場合と同様に、翻訳処理部１２及び変換処理部１３によって逆変換処理を行う。
【００５１】
レスポンスの翻訳・変換処理がリクエストの場合のそれと大きく異なる点は、
(1) リクエスト文の変換時に補完したパラメータを除外パラメータとして取扱い、レスポンス変換時のパラメータとして整形しないこと。  
(2) リクエスト文の翻訳・変換時に除外し、ゲートウエイ１内の作業メモリ等に一時保存しておいたパラメータを当該メモリ等から読み出し、レスポンス変換時のパラメータとして整形すること。
の２点である。  
例えば、図９に示すようにデータ共有（ＷＳＣ・ＷＳＰ）サーバ５から返送されたレスポンスに含まれる＜SOAP-ENV:Body ID=“idwsf” id=“2222”＞はOpenID AX方式にあっては不要なパラメータであるため、除外される。
【００５２】
このレスポンスの逆変換処理によって、レスポンスはID-WSF方式からOpenID AX方式に対応する形式に整形され、図８又は図９に示すようにデータ提供（ＯＰ）サーバ３を経由してデータ要求（ＲＰ）サーバ２に転送される。かくして、一般ユーザは、情報流通方式を意識することなく、ID-WSF方式を採用したデータ共有（ＷＳＣ・ＷＳＰ）サーバ５に存在する属性情報に対する操作結果を確認することができる。
【００５３】
なお、以上の説明では、データ要求（ＲＰ）サーバ２のWebアプリケーションを使用して、データ共有（ＷＳＣ・ＷＳＰ）サーバ５で管理されている情報を操作する場合を例にとって説明した。しかしそれに限らず、
(1) データ要求（ＲＰ）サーバ２のWebアプリケーションを使用して、データ共有（独自ＡＰＩ）サーバ６で管理されている情報を操作する場合。  
(2) データ共有（ＷＳＣ・ＷＳＰ）サーバのWebアプリケーションを使用して、データ提供（ＯＰ）サーバ３で管理されている情報を操作する場合。  
(3) データ共有（ＷＳＣ・ＷＳＰ）サーバ５のWebアプリケーションを使用して、データ共有（独自ＡＰＩ）サーバ６で管理されている情報を操作する場合。  
(4) データ共有（独自ＡＰＩ）サーバ６のWebアプリケーションを使用して、データ提供（ＯＰ）サーバ３で管理されている情報を操作する場合。  
(5) データ共有（独自ＡＰＩ）サーバ６のWebアプリケーションを使用して、データ共有（ＷＳＣ・ＷＳＰ）サーバ５で管理されている情報を操作する場合。
にも、この発明による中継方法は同様に適用できる。
【００５４】
これら(1) 〜(5) の場合と、先に述べたデータ要求（ＲＰ）サーバ２のWebアプリケーションを使用してデータ共有（ＷＳＣ・ＷＳＰ）サーバ５で管理されている情報を操作する場合との差分は、構文分割テーブル及びパラメータ翻訳テーブルに記憶されているデータの内容である。
【００５５】
上記(1) 〜(5) のうち、独自の情報流通方式（独自API）を採用したデータ共有サーバ６と、ID-WSF 方式又はOpenID AX 方式を採用したデータ提供サーバ２との間で情報流通のためのリクエスト・レスポンスの連携を行う場合、つまり上記(2) 又は(3) の場合、新たに異なる属性情報流通方式のWebアプリケーションと連携をとろうとする個別のパーソナル・コンピュータ又はサーバを管理するユーザは、自己のWebアプリケーションの構文分割テーブルをゲートウエイ１に事前に提供する。そして、連携予定の属性情報流通方式との間のパラメータ翻訳テーブルを作成し、ゲートウエイ１の管理ユーザと合意をとって新たに定義する。
【００５６】
例えば、図４に示した方式マスタテーブルに記載されたOriginal API_2という属性情報流通方式を採用する個別のパーソナル・コンピュータ又はサーバの管理ユーザは、新たに、“fid=4”として定義し、Original API_2の構造分割テーブルを作成し、連携予定分のパラメータ翻訳テーブルを定義すればよい。ここでは、例えばOpenID AX及びID-WSFとの間で連携をとるものとすると、“request from fid=4 to fid=1”，“request from fid=4 to fid=2”，“response from fid=2 to fid=4”，“response from fid=2 to fid=4”を定義する。
【００５７】
以上詳述したようにこの発明の一実施形態では、ゲートウエイ１に翻訳テーブル１１、翻訳処理部１２及び変換処理部１３を設け、これらにより異なる属性情報流通方式を採用したWebアプリケーション間で属性情報流通のためのリクエスト・レスポンスを連携させるようにしている。具体的には、先ず属性情報流通方式の変換方向を表す情報を取得して、この情報をもとに翻訳テーブル１１内の方式マスタテーブルからリンク情報fidを取得する。次に、この取得されたfidで定義された構文分割テーブルを参照して、その分割ルールに従い上記受信されたリクエストを構文分割して、この分割された各文からパラメータ変換用コードを抽出する。続いて、このパラメータ変換用コードをキーとしてパラメータ翻訳テーブルから翻訳情報を取得すると共に、この翻訳情報をもとに異なる情報流通方式として対応のないパラメータを判定して、変換後の属性情報流通方式の仕様として補完するパラメータと除外するパラメータの有無について確認する。そして、変換後の属性情報流通方式に必要なパラメータを該当箇所に埋め込んでリクエスト文を整形すると共に、上記パラメータの補完及び除外処理を行なう。
【００５８】
したがって、異なる属性情報流通方式を採用したWebアプリケーション間で属性情報の流通に必要なリクエスト・レスポンスの連携が可能になる。これにより、それぞれの属性情報流通方式が持つメリットを状況に応じて使い分けることが可能になる。
【００５９】
例えば、個人の医療情報等は、一般にセキュリティの高い属性流通方式を用いているWebアプリーション配下のパーソナル・コンピュータ又はサーバで管理される。しかし、医療情報の生成から数年が経過し、医療情報を生成した組織（病院など）側で当該情報を削除しようとした場合には、現在では医療情報を残す方法としては記録メディアに記録させる等の方法を採るしかないが、この発明の実施形態によれば異なる属性情報流通方式間での医療情報の流通が可能になる。  
【００６０】
すなわち、削除される予定の医療情報を、セキュリティは多少劣るものの健康改善を目的としたWebアプリケーションが豊富な属性情報流通方式のWebアプリケーションに医療情報をコピーして、これを一般の市民が健康管理目的で広く活用するといった新たな用途に利用できる。
【００６１】
［他の実施形態］
なお、この発明は前記実施形態に限定されるものではない。例えば、前記実施形態では、OpenID AX方式を採用したＷｅｂアプリケーションとID-WSF方式を採用したＷｅｂアプリケーションとの間でリクエスト・レスポンスの翻訳・変換処理を行う場合を例にとって説明した。しかしそれに限らず、図４に例示したOriginal API_1やOriginal API_2等のその他の属性情報流通方式との間で属性情報流通リクエスト／レスポンスの翻訳・変換処理を行う場合にも、この発明を同様に適用可能である。
【００６２】
さらに、前記実施形態では属性情報として利用者の氏名や電子カルテ等の医療情報を流通させる場合を例にとって説明したが、医療情報以外に会議情報や従業員の労務情報等を流通させるようにしてもよい。その他、中継機器の種類や構成、翻訳、変換、補完及び削除等の各処理手順と処理内容等についても、この発明の要旨を逸脱しない範囲で種々変形して実施可能である。
【００６３】
要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【００６４】
１…ゲートウエイ、２…データ要求（ＲＰ）サーバ、３…データ提供（ＯＰ）サーバ、４…データ格納場所提供（ＤＳ）サーバ、５…データ共有（ＷＳＣ／ＷＳＰ）サーバ、６…データ共有（独自ＡＰＩ）サーバ、１１…翻訳テーブル、１２…翻訳処理部、１３…変換処理部。
【図１】
2014016960.tif 000003
【図２】
2014016960.tif 000004
【図３】
2014016960.tif 000005
【図４】
2014016960.tif 000006
【図５】
2014016960.tif 000007
【図６】
2014016960.tif 000008
【図７】
2014016960.tif 000009
【図８】
2014016960.tif 000010
【図９】
2014016960.tif 000011