(57)【要約】【課題】  文書の任意の要素を暗号化できるという利便性を備えながら、その暗号化された文書に対するスキーマ検証が適切に行えるようなスキーマ文書処理装置を提供することを目的とする。【解決手段】  スキーマ文書処理装置２１は、文書中で暗号化する箇所を指定する入出力部２１１と、暗号化前の文書がスキーマ検証で合格できる第１のスキーマ文書に応じて、前記指定箇所が暗号化された文書が、スキーマ検証で合格できる第２のスキーマ文書を生成するスキーマ文書処理部２０１とを備える。スキーマ文書処理部２０１は、指定箇所を復号化可能な相手には第１のスキーマ文書が取得でき、復号化不能な相手には第２のスキーマ文書が取得できるように送信するメッセージを設定する。【選択図】          図１
2006279349.tif 000002
【特許請求の範囲】
【請求項１】
文書中で暗号化する箇所を指定する指定手段と、
暗号化前の文書がスキーマ検証で合格できる第１のスキーマ文書に応じて、前記指定箇所が暗号化された文書がスキーマ検証で合格できる第２のスキーマ文書を生成する生成手段と、
前記指定箇所を復号化可能な相手には前記第１のスキーマ文書が取得でき、前記指定箇所を復号化不能な相手には前記第２のスキーマ文書が取得できるように送信するメッセージを設定する設定手段と
を含むことを特徴とするスキーマ文書処理装置。
【請求項２】
前記生成手段は、異なった暗号鍵ごとに前記第２のスキーマ文書を生成することを特徴とする請求項１に記載のスキーマ文書処理装置。
【請求項３】
前記設定手段は、文書中の箇所を暗号化したときと同じ暗号を前記第１のスキーマ文書の実体あるいは参照に対してかけることを特徴とする請求項１に記載のスキーマ文書処理装置。
【請求項４】
前記第１のスキーマ文書および前記第２のスキーマ文書の少なくとも一方を用いてスキーマ検証を行う検証手段をさらに備えることを特徴とする請求項１に記載のスキーマ文書処理装置。
【請求項５】
前記スキーマ検証の結果、妥当な文書について所定の処理を行う処理手段をさらに備えることを特徴とする請求項４に記載のスキーマ文書処理装置。
【請求項６】
文書中で暗号化する箇所を指定するステップと、
暗号化前の文書がスキーマ検証で合格できる第１のスキーマ文書に応じて、前記指定箇所が暗号化された文書が、スキーマ検証で合格できる第２のスキーマ文書を生成するステップと、
前記指定箇所を復号化可能な相手には前記第１のスキーマ文書が取得でき、前記指定箇所を復号化不能な相手には前記第２のスキーマ文書が取得できるように送信するメッセージを設定するステップと、
を含むことを特徴とするスキーマ文書処理方法。
【請求項７】
異なった暗号鍵ごとに前記第２のスキーマ文書を生成するステップをさらに含むことを特徴とする請求項６に記載のスキーマ文書処理方法。
【請求項８】
文書中の箇所を暗号化したときと同じ暗号を前記第１のスキーマ文書の実体あるいは参照に対してかけるステップをさらに含むことを特徴とする請求項６に記載のスキーマ文書処理方法。
【請求項９】
前記第１のスキーマ文書および前記第２のスキーマ文書の少なくとも一方を用いてスキーマ検証を行うステップをさらに含むことを特徴とする請求項６に記載のスキーマ文書処理方法。
【請求項１０】
前記スキーマ検証の結果、妥当な文書について所定の処理を行うステップをさらに含むことを特徴とする請求項９に記載のスキーマ文書処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＸＭＬやＳＧＭＬといった構造化文書において、文書が取りうる構造と内容とを文法的に規定するスキーマ文書処理装置およびスキーマ文書処理方法に関する。
【背景技術】
【０００２】
近年、複数のネットワーク装置で実行される異なるサービスを、人手を介さずに連携させて一連の処理を実現するという、ウェブサービスが発展しつつある。ウェブサービスにおいては、複数のサービスの間でＸＭＬ文書が送受信されることで情報伝達が行われ、一連の処理が進められる。ウェブサービスを支える技術の一つが、スキーマ処理の技術である。ＸＭＬやＳＧＭＬといった構造化文書の技術領域において、スキーマとは文書が取りうる構造と内容とを文法的に規定したものである。スキーマを記述するための言語をスキーマ言語と呼び、ＸＭＬに対するスキーマ言語としてＤＴＤ(Document Type Definition; 文書型定義)、Ｗ３Ｃ ＸＭＬ Ｓｃｈｅｍａ、ＲＥＬＡＸ ＮＧといったものがある。スキーマ言語を用いた特定の記述のことをスキーマ文書と呼ぶ。
【０００３】
ウェブサービスでは人手を介さずにサービスが実行されるので、マシン処理可能なように、サービスの入出力データの形式と意味とが明確に規定される必要がある。もしその規定に則ったデータが受け渡しされなければ、サービスが誤った結果を返すだけでなく、サービスそのものがダウンする可能性もある。サービスの入力あるいは出力として許される文書をスキーマ文書によって規定し、サービス間で受け渡しされる文書がスキーマを満たしているかを検証した後にサービスを利用することで、上述の問題を回避できる。なおＸＭＬの技術領域では、あるＸＭＬ文書Ｄ１がＸＭＬ規格のタグ付けルールに従っているとき「文書Ｄ１は整形式(well-formed)である」といい、あるＸＭＬ文書Ｄ２があるスキーマ文書Ｓが規定する要素名や要素の階層関係や内容の型などをすべて満たすとき「文書Ｄ２は妥当(ｖａｌｉｄ)である」とよぶ。言うまでもないが、文書が妥当なためには整形式である必要がある。
【０００４】
ウェブサービスを支える別の技術として、暗号化／復号化処理の技術がある。ＸＭＬ文書を対象とする暗号の国際標準として、ＸＭＬ暗号(ＸＭＬ Ｅｎｃｒｙｐｔｉｏｎ)がある。ＸＭＬ暗号を用いると、文書中の任意の要素から下位構造を暗号化することができる。ウェブサービスでは、同じ文書が複数のサービスで受け渡しされて処理される、あるいは、文書の一部がコピーされて複数のサービスで利用されるということがよく起こる。このとき、セキュリティ上の要求から、文書の一部を特定のサービスにだけ利用可能とし、他のサービスから秘匿したい場合がある。
【０００５】
例えば、クレジットカード内容を含む注文書を、発注者と本屋とクレジットカード会社と宅配業者との間で情報を追記しながら受け渡して一連の処理を進めることを考える。このとき、クレジットカード内容の部分はクレジットカード会社だけが処理できるようにし、本屋と宅配業者にはクレジット決済されたことだけが伝わることがセキュリティ上望ましい。ＸＭＬ暗号を用いると、発注者がクレジットカード内容を記述した要素を、クレジットカード会社が公開する暗号鍵で暗号化できる。このとき、クレジットカード会社だけが暗号化された要素を復号化して利用でき、本屋と宅配業者にはクレジットカード内容を知られずに済むようになる。
【０００６】
図７および図８は、スキーマ文書の一例を示す図である。図９は、図７および図８で示すスキーマ文書が示す規定を満たすＸＭＬ文書の例を示す図である。図１０は、図９に示すＸＭＬ文書の一部を暗号化した文書の例を示す図である。例えば図９に示すＸＭＬ文書において、クレジットカード内容を示すcreditCardInfo要素から下位の構造（すなわち、開始タグ<bo:creditCardInfo>から終了タグ</bo:creditCardInfo>まで）を暗号化することを考える。ＸＭＬ暗号を用いて暗号化すると、図１０に示すように、この部分がEncryptData要素から下位の構造に置換される。ここで、文書要素が暗号化されることをスキーマ文書で想定していなかった場合、暗号化された文書はスキーマ検証によって妥当ではないと判定されてしまう。例えば、図９のＸＭＬ文書を規定するスキーマ文書がＷ３Ｃ ＸＭＬ Ｓｃｈｅｍａを用いて図７および図８のように記述されているとする。すなわち、図９の（Ｃ）のxsi:schemaLocation属性で指定されているスキーマ文書bo.xsdが図７および図８で示されるものであるとする。このとき、図１０のＸＭＬ文書は図７のスキーマ文書の規定を満たさないので妥当ではないと判定されてしまう。
【０００７】
妥当でない文書はサービスの入力や出力として不適切なので、ウェブサービスでの一連の処理が正常に終了しなくなる。これに対して、例えば特許文献１に開示される技術では、スキーマ文書の規定を変化させる箇所と内容とを事前に取り決め、この取り決めを記述した変化規則を各サービスが共有し、妥当性検証時にスキーマ文書の規定を満たさない文書要素が出現した際には、前記変化規則を適用して変化させた規定で改めて妥当性検証を行う、というものがある。
【０００８】
【特許文献１】特開２００４−３４２０２０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、従来技術では、任意の文書要素を暗号化したい場合に、次のような課題がある。まず一般の検証処理では、スキーマ文書の規定を満たさないと検証が失敗するので、スキーマ文書で暗号化が許容されていない文書要素を暗号化すると、その要素を含む文書の検証は失敗する。これを避けるには、様々なサービス提供者による暗号化の要求を勘案して、スキーマ文書作成者があらかじめ文書要素が置換されうることをスキーマ文書中に記述しなければならない。
【００１０】
例えば図９において、発注者はcreditCardInfo要素以下を暗号化したいかもしれないし、cardNumberInfo要素とvalidThru要素とを個別に暗号化したいかもしれないし、payerInfo要素以下をまとめて暗号化したいかもしれない。このような様々な暗号化の可能性を考慮すると、スキーマ記述が複雑化になる。スキーマ記述が複雑化すると、その記述に工数が大きくかかるだけでなく、記述エラーの発生の可能性が増え、以後の拡張や保守が難しくなる。特許文献１に開示される変化規則においても、上記の課題はあてはまる。
【００１１】
まず、変化規則が記述されていなければ検証は失敗するので、任意箇所を暗号化することはできない。また、サービス提供者による暗号化の要求を勘案して変化規則を作成すると、変化規則が増大・複雑化する。さらに、変化規則は各サービスで共有される必要があるので、変化規則に対する変更や追加が生じた場合に一貫性を保つための保守が難しくなる。
【００１２】
また別の課題として、スキーマ記述にある要素が暗号化された要素で置換されうることをスキーマ文書中に記述する、あるいは、前記変化規則として記述した場合、暗号化された要素にどのような情報が記載されているかを、本来情報を復号できないサービスが知りうることになってしまう。例えば、暗号化された情報がクレジットカード情報であることが知られてしまえば、悪意のある攻撃者によって不正な解読の対象にさらされる危険性がある。このように、スキーマ記述や前記変化規則が広く知られてしまうことは、暗号化の主旨から見て好ましくない。
【００１３】
そこで、本発明は、上記問題点に鑑みてなされたもので、文書の任意の要素を暗号化できるという利便性を備えながら、その暗号化された文書に対するスキーマ検証が適切に行えるようなスキーマ文書処理装置およびスキーマ文書処理方法を提供することを目的とする。
【課題を解決するための手段】
【００１４】
上記課題を解決するために、本発明は、文書中で暗号化する箇所を指定する指定手段と、暗号化前の文書がスキーマ検証で合格できる第１のスキーマ文書に応じて、前記指定箇所が暗号化された文書がスキーマ検証で合格できる第２のスキーマ文書を生成する生成手段と、前記指定箇所を復号化可能な相手には前記第１のスキーマ文書が取得でき、前記指定箇所を復号化不能な相手には前記第２のスキーマ文書が取得できるように送信するメッセージを設定する設定手段とを含むことを特徴とするスキーマ文書処理装置である。本発明によれば、文書の任意の要素を暗号化できるという利便性を備えながら、その暗号化された文書に対するスキーマ検証を適切に行うことができる。
【００１５】
前記生成手段は、異なった暗号鍵ごとに前記第２のスキーマ文書を生成することを特徴とする。前記設定手段は、文書中の箇所を暗号化したときと同じ暗号を前記第１のスキーマ文書の実体あるいは参照に対してかけることを特徴とする。これにより、相手に応じたスキーマ文書の取得を実現できる。本発明のスキーマ文書処理装置は、前記第１のスキーマ文書および前記第２のスキーマ文書の少なくとも一方を用いてスキーマ検証を行う検証手段をさらに備える。本発明のスキーマ文書処理装置は、前記スキーマ検証の結果、妥当な文書について所定の処理を行う処理手段をさらに備える。
【００１６】
本発明は、文書中で暗号化する箇所を指定するステップと、暗号化前の文書がスキーマ検証で合格できる第１のスキーマ文書に応じて、前記指定箇所が暗号化された文書が、スキーマ検証で合格できる第２のスキーマ文書を生成するステップと、前記指定箇所を復号化可能な相手には前記第１のスキーマ文書が取得でき、前記指定箇所を復号化不能な相手には前記第２のスキーマ文書が取得できるように送信するメッセージを設定するステップとを含むスキーマ文書処理方法である。本発明によれば、文書の任意の要素を暗号化できるという利便性を備えながら、その暗号化された文書に対するスキーマ検証を適切に行うことができる。
【００１７】
本発明のスキーマ文書処理方法は、異なった暗号鍵ごとに前記第２のスキーマ文書を生成するステップをさらに含む。
【００１８】
本発明のスキーマ文書処理方法は、文書中の箇所を暗号化したときと同じ暗号を前記第１のスキーマ文書の実体あるいは参照に対してかけるステップをさらに含むことを特徴とする。これにより、相手に応じたスキーマ文書の取得を実現できる。本発明のスキーマ文書処理方法は、前記第１のスキーマ文書および前記第２のスキーマ文書の少なくとも一方を用いてスキーマ検証を行うステップをさらに含む。本発明のスキーマ文書処理方法は、前記スキーマ検証の結果、妥当な文書について所定の処理を行うステップをさらに含む。
【発明の効果】
【００１９】
本発明によれば、文書の任意の要素を暗号化できるという利便性を備えながら、その暗号化された文書に対するスキーマ検証が適切に行えるようなスキーマ文書処理装置およびスキーマ文書処理方法を提供することができる。
【発明を実施するための最良の形態】
【００２０】
以下、本発明を実施するための最良の形態について実施例を用いて説明する。
【実施例１】
【００２１】
図１は、本発明の第１実施例に係わるシステム構成を示す図である。図１に示すように、システム１は、サービス装置２１〜２ｎを備える。これらはネットワーク３を介して接続されている。サービス装置２１は、スキーマ文書処理部２０１、メッセージ受信部２０２、メッセージ送信部２０３、メッセージ記憶部２０４、文書記憶部２０５、スキーマ文書記憶部２０６、スキーマ検証部２０７、暗号化部２０８、復号化部２０９、サービス処理部２１０および入出力部２１１を備える。
【００２２】
各サービス装置２１〜２ｎはパブリックネットワーク３を介してメッセージを送受信して一連の処理を実行する。ここでサービスには、たとえばホテル予約、航空機予約、レンタカー予約などが含まれる。送受信されるメッセージはＳＯＡＰエンベロープ形式（すなわちＸＭＬ文書形式）であり、ＳＯＡＰエンベロープのボディにサービス処理部２１０の入出力となるＸＭＬ文書が含まれる。サービスを実際に処理するサービス処理部２１０にＸＭＬ文書を渡す前に、スキーマ検証部２０７による検証が行われ、妥当な文書だけがサービス処理部２１０によって処理される。スキーマ言語は、本実施例ではＷ３Ｃ ＸＭＬ Ｓｃｈｅｍａを用いる。本実施例では、特定のサービス装置だけが内容を復号化できる一つの暗号鍵を用いて、文書中の任意の要素（複数可）を暗号化する。入出力部２１１は、文書中で暗号化する箇所を指定するものである。暗号鍵は暗号化部２０８に保有されている。
【００２３】
スキーマ文書処理部２０１は、暗号化前の文書がスキーマ検証で合格できる第１のスキーマ文書に応じて、指定箇所が暗号化された文書がスキーマ検証で合格できる第２のスキーマ文書を生成し、指定箇所を復号化可能な相手には第１のスキーマ文書が取得でき、指定箇所を復号化不能な相手には第２のスキーマ文書が取得できるように送信するメッセージを設定するものである。このとき、スキーマ文書処理部２０１は、文書中の箇所を暗号化したときと同じ暗号を第１のスキーマ文書の実体あるいは参照に対してかける。ここでスキーマ文書の実態とは、スキーマ文書自体のことである。スキーマ検証部２０７は、第１のスキーマ文書又は第２のスキーマ文書を用いてスキーマ検証を行うものである。サービス処理部２１０は、スキーマ検証の結果、妥当な文書について所定の処理を行う。
【００２４】
図２は、ＳＯＡＰエンベロープ３１を他のサービス装置２２〜２ｎに送信する前にスキーマ文書処理部２０１が実行する処理を模式的に示した図である。また、図５は図２で説明した処理に関わる、スキーマ文書処理部２０１の処理フローを示す図である。
【００２５】
ステップＳ１１で、スキーマ文書処理部２０１は、ＸＭＬ文書Ｄ中の暗号化する要素の指示を受け取る。参照符号３２は暗号化する要素を示す。ステップＳ１２で、スキーマ文書処理部２０１は、暗号化する要素３２について、その定義がある箇所をスキーマ文書Ｓから検出する。ステップＳ１３で、スキーマ文書処理部２０１は、暗号化する要素３２と同じ種類の要素がＸＭＬ文書Ｄの他の部分に存在し、同じ種類の要素はすべて暗号化の対象であると判断した場合（ステップＳ１４）、ステップＳ１６に進む。ステップＳ１３で、暗号化する要素３２と同じ種類の要素がＸＭＬ文書Ｄ中の他の部分に存在しない場合は、ステップＳ１６に進む。
【００２６】
ステップＳ１６で、元のスキーマ文書Ｓで暗号化する要素の定義が記述されている箇所を、暗号化後の要素を定義したスキーマ記述と置換したスキーマ文書Ｓ’を生成する。図９と図１０の例で言えば、この処理におけるスキーマ文書Ｓは、図７および図８に示すものとなり、新たに生成されるスキーマ文書Ｓ’は、図７（Ａ）から図８ (Ｂ)の部分をＸＭＬ暗号標準に規定される<EncryptedData>要素以下のスキーマ記述に置換したものになる。
【００２７】
暗号化する要素と同じ種類の要素が文書中の他の部分に存在し、かつ、同じ種類のものが暗号化されない場合は、新たに生成されるスキーマ文書Ｓ’に暗号化前の要素と暗号化後の要素の両方の定義が含まれる必要がある。したがって、同じ種類のものが存在する暗号化する要素については、元のスキーマ文書Ｓで暗号化する要素の定義が記述されている箇所を、暗号化前の要素と暗号化後の要素のいずれかを選択できるスキーマ記述に書き換え、それ以外の箇所は暗号化後の要素を定義したスキーマ記述に置換したスキーマ文書Ｓ’を生成する（ステップＳ１５）。要素のいずれかを選択できるスキーマ記述の一例として図９と図１０を用いて説明すると、スキーマ文書Ｓ’は、図７ (Ａ)の直前に<xsd:choice>に続いて<EncryptedData>要素以下のスキーマ記述が挿入され、図８（Ｂ）の直後に</xsd:choice>が挿入されたものになる。なお、前記のスキーマ記述の変更は、スキーマ記述を実際に上書きしても良いし、インポートしても良い。
【００２８】
ステップＳ１７で、スキーマ文書処理部２０１は、要素を暗号化部２０８に暗号化させる。ステップＳ１８で、スキーマ文書処理部２０１は、図２の「スキーマ付替とエンベローピング」において、ＸＭＬ文書Ｄから参照されるスキーマ文書をＳからＳ’に置換する。ステップＳ１９で、スキーマ文書処理部２０１は、ＸＭＬ文書ＤをＳＯＡＰボディ３３に、Ｓへのスキーマ参照をＳＯＡＰヘッダ３４に持つＳＯＡＰエンベローブ３１を生成する。このため、元のスキーマ文書Ｓは、ＸＭＬ文書Ｄを含むＳＯＡＰエンベロープ３１のＳＯＡＰヘッダ３４中の要素から参照される。
【００２９】
ステップＳ２０で、スキーマ文書処理部２０１は、前記要素の暗号化と同じ暗号鍵を用いてＳＯＡＰヘッダ３４のスキーマ参照を暗号化部２０８に暗号化させる。すなわち、ヘッダ要素は、文書の要素の暗号化と同じ暗号鍵を使って暗号化される。このため、文書の要素を復号化できるサービス装置は、このヘッダ要素も復号化できるので元のスキーマ文書Ｓを入手することができる。なお本実施例では、スキーマ参照にはxsi:schemaLocation属性をＳＯＡＰヘッダでも用いる。ステップＳ２１で、ＳＯＡＰエンベロープ３１をメッセージ送信部２０３を使ってパブリックネットワーク３へ送信する。
【００３０】
図３は、ＳＯＡＰエンベロープ３１をパブリックネットワーク３を介して他のサービス装置から受信した後に、暗号化部分を復号可能な場合にスキーマ文書処理部２０１が実行する処理を模式的に示した図である。図４は、ＳＯＡＰエンベロープ３１をパブリックネットワーク３を介して他のサービス装置から受信した後に、暗号化部分を復号できない場合にスキーマ文書処理部２０１が実行する処理を模式的に示した図である。
【００３１】
また、図６は図３および図４で説明した処理に関わる、スキーマ文書処理部２０１の処理フローを示す図である。ステップＳ３１で、スキーマ文書処理部２０１は、受信したＳＯＡＰエンベローブ３１のヘッダ３４の復号化を復号化部２０９で試みる。ステップＳ３２で、スキーマ文書処理部２０１は、ヘッダ３４が復号できない場合、ステップＳ３３に進む。ステップＳ３４で、スキーマ文書処理部２０１は、復号化部分にスキーマ参照を含まない場合、ステップＳ３３に進む。
この場合はスキーマ文書Ｓを入手できないので、文書Ｄが参照するスキーマ文書Ｓ’が以後のスキーマ検証で用いられる。すなわち、ステップＳ３３で、スキーマ文書処理部２０１は、受信したＳＯＡＰエンベローブ３１からボディ３３にあるＸＭＬ文書Ｄを取り出し、文書記憶部２０５に記憶させ、ステップＳ３８に進む。
【００３２】
ヘッダ３４が復号でき、かつ復号化部分にスキーマ参照を含む場合、ヘッダ３４のスキーマ参照３５からスキーマ文書Ｓを入手できる。ステップＳ３５で、スキーマ文書処理部２０１は、以後のスキーマ検証でスキーマ文書Ｓが利用されるように、受信したＳＯＡＰエンベローブ３１のボディ３３にある文書Ｄのスキーマ参照を、スキーマ文書Ｓへの参照に付け替える。ステップＳ３６で、スキーマ文書処理部２０１は、受信したＳＯＡＰエンベローブ３１からボディ３３にある文書Ｄを取り出し、文書記憶部２０５に記憶させる。ステップＳ３７で、スキーマ文書処理部２０１は、前記文書中の暗号化された要素を復号化する。ステップＳ３８で、スキーマ文書処理部２０１は、スキーマ検証部２０７にスキーマの妥当性を検証させる。ステップＳ３９で、妥当であれば、ステップＳ４０で、サービス処理部２１０に検証された文書を渡し、サービスを実行させる。
【００３３】
以上、本発明の実施形態について説明した。ここまでの説明では既に標準化されたＸＭＬ関連技術に基づいて説明したが、
１）文書が木構造形式に構造化され、
２）その木構造形式に対するスキーマ言語が存在し、
３）木構造の部分木に対する暗号化方式が存在し、
４）文書にメタデータが付与可能であり、
５）前記メタデータを前記暗号化方式で暗号化できる
場合には、本発明が適用できることは明らかである。
【実施例２】
【００３４】
次に、本発明の第２実施例について説明する。第１実施例では、特定のサービス装置が復号化できる一つの暗号鍵を用いていた。これを、複数の暗号鍵を用意し、個々の暗号鍵と文書の暗号箇所とを対応付けて暗号化するようにし、暗号鍵ごとに生成したスキーマ文書を用いて検証するようにしてもよい。暗号鍵と暗号箇所を使い分けることで、一つの文書の中で、複数のサービス装置に対して内容を知ることができる箇所をコントロールするようにでき、その暗号化に応じたスキーマ文書で各サービス装置が検証できるようになる。上述した本の発注の例で説明すれば、クレジットカード内容の暗号化に加え、発注された内容を暗号化してクレジットカード会社には具体的な本の名前などが知られないようにすることができる。なお、サービス装置の構成は実施例１と同様であるため図１を用いて説明する。
【００３５】
図１１は、異なるサービス向けに、文書の複数箇所に異なった暗号鍵による暗号化が行われる場合のＳＯＡＰエンベロープ１３１とＸＭＬ文書Ｄの模式図を示す図である。スキーマ文書処理部２０１での処理については、暗号鍵ごとに新たなスキーマ文書を生成する。そして、元のスキーマ文書への参照をＳＯＡＰヘッダ３４に記載するのではなく、復号化可能な要素に応じた複数のスキーマ文書をＳＯＡＰヘッダ３４に暗号化して記載する。
【００３６】
図１１の斜線のハッチ部分４１と格子のハッチ部分４２とが異なる暗号鍵で暗号化された部分である。スキーマ文書Ｓ１は、格子部分の暗号化要素を含み、斜線部分が復号化された文書を許容するものである。スキーマ文書Ｓ２は、斜線部分の暗号化要素を含み、格子部分が復号化された文書を許容するものである。スキーマ文書Ｓ３は、斜線部分と格子部分の暗号化要素を含む文書を許容するものである。
【００３７】
次に、スキーマ検証部２０１の処理については、一つの暗号鍵に対応して復号化できるスキーマ参照と文書要素ごとに検証を行う。そして、すべての検証で妥当な場合にのみ、サービス処理部２１０に文書を渡してサービスを実行させる。ここで渡す文書は、このサービス装置で復号化可能な文書要素をすべて復号化したものである。なお、復号化できる部分がない場合の処理は、前記実施例１と同様である。
【００３８】
図１１の例で説明すると、あるサービス装置が斜線部分と格子部分の両方を復号化可能な場合は、斜線部分を復号化したときの検証と格子部分を復号化したときの検証とをそれぞれ行う。そして、いずれの検証でも妥当である場合には、斜線部分と格子部分を復号化した文書をサービス処理部２１０に渡す。
【００３９】
なお、上記各実施例において、スキーマ文書への参照を用いたが、これをスキーマ文書を実体として文書とエンベロープに含めるように構成しても良い。また、前記の実施形態では元のスキーマ文書への参照をエンベロープのヘッダに記載した。これを、文書の暗号化部分にスキーマ文書への参照を含める形にし、復号化後にスキーマ文書への参照が含まれていれば文書中の他の部分のスキーマ参照を削除するようにしてもよい。
【００４０】
また、前記の実施例では複数のサービス装置がネットワークを介して分散処理を行う形を取った。これを、共有の文書記憶装置が存在し、これに各サービス装置がアクセスする形態を取っても良い。この場合は、共有文書記憶装置への書き込み前に、図２の１から４の処理が行われて、５の「送信」の代わりに書き込みが行われる。そして、共有文書記憶装置から読み出し時に、図３乃至図４の１の「受信」の代わりに読み出しが行われ、それ以降の処理が順次行われる。また、前記の実施例では暗号化部がサービス装置に応じた暗号鍵を保有していたが、これを暗号鍵を適宜配布するように構成しても良い。配布方式は、公開鍵方式やアクセスコントロールチケットを用いる方式といったネットワークを用いた方式でも良いし、鍵が記録されたメディアの郵送といった物理的な方式でも良い。
【００４１】
本発明では、文書の任意の要素が暗号化される際に、暗号化された要素を含む文書が妥当となるスキーマ文書を生成する。そして、暗号化された要素を含む文書から前記スキーマ文書が入手可能にするとともに、暗号化された要素を復号可能であるサービスに対して復号化された要素を含む文書が妥当となるスキーマ文書を入手可能とした。従って、文書を暗号化する側は元のスキーマにとらわれることなく、文書の任意の要素に暗号をかけることができる。そして、暗号化された文書を受け取った側は、復号化できる要素に応じたスキーマ文書を用いて、受け取った文書を検証することができるようになる。
【００４２】
なお、本発明によるスキーマ文書処理方法は、例えば、ＣＰＵ（Central Processing Unit）、ＲＯＭ(Read Only Memory)、ＲＡＭ(Random Access Memory)等を用いて実現され、プログラムをハードディスク装置や、ＣＤ−ＲＯＭ、ＤＶＤまたはフレキシブルディスクなどの可搬型記憶媒体等からインストールし、または通信回路からダウンロードし、ＣＰＵがこのプログラムを実行することで、各ステップが実現される。
【００４３】
以上本発明の好ましい実施例について詳述したが、本発明は係る特定の実施例に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形、変更が可能である。
【図面の簡単な説明】
【００４４】
【図１】本発明の実施例に係わるシステム構成を示す図である。
【図２】ある文書Ｄをパブリックネットワークを介して送信する前に、スキーマ文書処理部が行う処理を説明する図である。
【図３】ある文書Ｄを含むエンベロープをパブリックネットワークを介して受信した後に、暗号化部分を復号可能な場合にスキーマ文書処理部が行う処理を説明する図である。
【図４】ある文書Ｄを含むエンベロープをパブリックネットワークを介して受信した後に、暗号化部分を復号できない場合にスキーマ文書処理部が行う処理を説明する図である。
【図５】図２で説明した処理に関わる、スキーマ文書処理部の処理フローを示す図である。
【図６】図３および図４で説明した処理に関わる、スキーマ文書処理部の処理フローを示す図である。
【図７】スキーマ文書の一例の前半部分を示す図である。
【図８】スキーマ文書の一例の後半部分を示す図である。
【図９】図７および図８で示すスキーマ文書が示す規定を満たすＸＭＬ文書の例を示す図である。
【図１０】図９に示すＸＭＬ文書の一部を暗号化した文書の例を示す図である。
【図１１】異なるサービス向けに、文書の複数箇所に異なった暗号鍵による暗号化が行われる場合を説明する図である。
【符号の説明】
【００４５】
１  システム
２１〜２ｎ  サービス装置
３  ネットワーク
２０１  スキーマ文書処理部
２０２  メッセージ受信部
２０３  メッセージ送信部
２０４  メッセージ記憶部
２０５  文書記憶部
２０６  スキーマ文書記憶部
２０７  スキーマ検証部
２０８  暗号化部
２０９  復号化部
２１０  サービス処理部
２１１  入出力部
【図１】
2006279349.tif 000003
【図２】
2006279349.tif 000004
【図３】
2006279349.tif 000005
【図４】
2006279349.tif 000006
【図５】
2006279349.tif 000007
【図６】
2006279349.tif 000008
【図７】
2006279349.tif 000009
【図８】
2006279349.tif 000010
【図９】
2006279349.tif 000011
【図１０】
2006279349.tif 000012
【図１１】
2006279349.tif 000013