(57)【要約】【課題】検証者（受信者）が電子署名ファイルが存在していることだけを認知していて、正当な電子署名ファイルを受信・検証しようとしたとき、検証者側からこの正当な電子署名ファイルを入手する手段がない。【解決手段】電子署名ファイル保管手段６６は、電子文書を特定する文書ＩＤと対応付けられた電子文書に、電子署名付き電子文書を、電子署名ファイルとして保管し、電子署名ファイル要求手段５７は、文書ＩＤを含む電子署名ファイル要求情報に電子署名付き電子署名ファイル要求情報を上記第１のコンピュータに送信し、署名検証手段４７は第２のコンピュータから受信した、電子署名付き電子署名ファイル要求情報の電子署名を検証し、電子署名ファイル提供手段６５は電子署名付き電子署名ファイル要求情報が正当であることを確認した後、文書ＩＤに基づき、該当する電子署名ファイルを上記第２のコンピュータに送信するものである。【選択図】        図９
2004289720.tif 000002
【特許請求の範囲】
【請求項１】
電子文書を特定する文書ＩＤと対応付けられた電子文書に、第１の署名者の電子署名を生成した、電子署名付き電子文書を、電子署名ファイルとして保管する電子署名ファイル保管手段
を備えた第１のコンピュータ、
上記文書ＩＤを含む電子署名ファイル要求情報に第２の署名者の電子署名を生成した、電子署名付き電子署名ファイル要求情報を上記第１のコンピュータに送信する電子署名ファイル要求手段
を備えた第２のコンピュータを有し、
さらに、上記第１のコンピュータは、
上記第２のコンピュータから受信した、上記電子署名付き電子署名ファイル要求情報の電子署名を検証する署名検証手段と、
上記電子署名付き電子署名ファイル要求情報が正当であることを確認した後、上記文書ＩＤに基づき、該当する電子署名ファイルを上記第２のコンピュータに送信する電子署名ファイル提供手段と
を備えたことを特徴とする電子署名システム。
【請求項２】
電子データを特定するデータＩＤを含む電子データに、第１の署名者の電子署名を生成した、１以上の電子署名付き電子データを、電子データ保管ファイルに順次保管する電子データ保管手段
を備えた第１のコンピュータ、
上記データＩＤを含む電子データ要求情報に第２の署名者の電子署名を生成した、電子署名付き電子データ要求情報を上記第１のコンピュータに送信する電子データ要求手段
を備えた第２のコンピュータを有し、
さらに、上記第１のコンピュータは、
上記第２のコンピュータから受信した、上記電子署名付き電子データ要求情報の電子署名を検証する署名検証手段と、
上記電子署名付き電子データ要求情報が正当であることを確認した後、上記電子データ保管ファイルを検索し、該当する電子データを上記第２のコンピュータに送信する電子データ提供手段と
を備えたことを特徴とする電子署名システム。
【請求項３】
上記第１のコンピュータは、さらに、第１のコンピュータを示す電子署名を生成する第１の署名手段を有し、
上記電子データ提供手段は、該当する電子データを上記第２のコンピュータに送信するとき、上記電子データが正当であることを示す上記第１のコンピュータの電子署名を、上記第１の署名手段に対して要求し、上記電子署名付き電子データに第１のコンピュータのさらなる電子署名を生成した、電子データを上記第２のコンピュータに送信することを特徴とする請求項２に記載の電子署名システム。
【請求項４】
上記電子データ保管ファイルは、電子データ毎に提供済みであるかどうかを示すフラグを有し、
上記電子データ提供手段は、上記電子データ要求情報に基づき、該当する電子データを提供したときは、該電子データの上記フラグを「提供済み」とし、このフラグが「提供済み」であるときは、該電子データを上記第２のコンピュータに送信しないことを特徴とする請求項２又は３に記載の電子署名システム。
【請求項５】
上記電子データ保管ファイルは、電子データ毎に提供回数を示すカウンタを有し、
上記電子データ提供手段は、上記電子データ要求情報に基づき、該当する電子データを提供したときは、該電子データの上記カウンタを提供回数分、加算することを特徴とする請求項２又は３に記載の電子署名システム。
【請求項６】
上記第２のコンピュータは、さらに、第２の署名者の電子署名を生成する第２の署名手段と、
上記第２の署名手段に対して、上記第１のコンピュータから受信した電子データに第２の署名者の電子署名を要求し、第２の署名者の電子署名付き電子データを電子データ保管ファイルに保管する第２の電子データ保管手段を有することを特徴とする請求項２〜５のいずれかに記載の電子署名システム。
【請求項７】
上記電子署名ファイル要求情報に生成された、上記第２の署名者の電子署名は、上記第１の署名者の電子署名と同一であることを特徴とする請求項１〜６のいずれかに記載の電子署名システム。
【請求項８】
上記電子署名ファイル要求情報に生成された、上記第２の署名者の電子署名は、上記第１の署名者の電子署名と異なることを特徴とする請求項１〜６のいずれかに記載の電子署名システム。
【請求項９】
第１のコンピュータから電子署名付き電子データ要求情報を受け付け、この第１のコンピュータに該当の電子データを送信する電子署名システムであって、
電子データを特定するデータＩＤを含む電子データに、第１の署名者の電子署名を生成した、１以上の上記電子署名付き電子データを、電子データ保管ファイルに順次保管する電子データ保管手段、
上記第１のコンピュータから受信した、電子署名付き電子データ要求情報の電子署名を検証する署名検証手段と、
上記電子署名付き電子データ要求情報が正当であることを確認した後、上記電子データ保管ファイルを検索し、該当する電子データを上記第１のコンピュータに送信する電子データ提供手段と
を備えたことを特徴とする電子署名システム。
【請求項１０】
電子データを特定するデータＩＤを含む電子データを保管する第１のコンピュータに、特定の電子データの送信を要求し、この第１のコンピュータから該当の電子データを受信する電子署名システムであって、
上記データＩＤを含む電子データ要求情報に第１の署名者の電子署名を生成した、電子署名付き電子データ要求情報を上記第１のコンピュータに送信する電子データ要求手段
を備えたことを特徴とする電子署名システム。
【請求項１１】
処方データを特定する患者ＩＤを含む処方データに、医師及び患者の電子署名を生成した、電子署名付き処方データを、処方データベースに保管する処方データ保管手段
を備えた病院サーバコンピュータ、
上記患者ＩＤを含む処方データ要求情報に薬剤師及び患者の電子署名を生成した、電子署名付き処方データ要求情報を上記病院サーバコンピュータに送信する処方データ要求手段
を備えた調剤薬局端末を有し、
さらに、上記病院サーバコンピュータは、
上記調剤薬局端末から受信した、上記電子署名付き処方データ要求情報の電子署名を検証する署名検証手段と、
上記電子署名付き処方データ要求情報が正当であることを確認した後、上記処方データベースを検索し、該当する処方データを上記調剤薬局端末に送信する処方データ提供手段と
を備えたことを特徴とする電子署名システム。
【請求項１２】
上記病院サーバコンピュータは、さらに、病院サーバコンピュータを示す電子署名を生成する第１の署名手段を有し、
上記処方データ提供手段は、該当する処方データを上記調剤薬局端末に送信するとき該当する電子データの正当性を示す病院サーバコンピュータの電子署名を第１の署名手段に要求し、病院サーバコンピュータのさらなる電子署名付きの処方データを上記調剤薬局端末に送信することを特徴とする請求項１１に記載の電子署名システム。
【請求項１３】
上記処方データベースは、処方データ毎に提供済みであるかどうかを示すフラグを有し、
上記処方データ提供手段は、上記処方データ要求情報に基づき、該当する処方データを提供したときは、該処方データの上記フラグを「提供済み」とし、このフラグが「提供済み」であるときは、該処方データを上記第２のコンピュータに送信しないことを特徴とする請求項１１又は１２に記載の電子署名システム。
【請求項１４】
上記調剤薬局端末は、さらに、薬剤師の電子署名を生成する第２の署名手段と、
上記第２の署名手段に対して、受信した処方データに基づく調剤記録への薬剤師の電子署名を要求し、薬剤師の電子署名付き調剤記録データを調剤データベースに記録する調剤記録手段を有することを特徴とする請求項１１〜１３のいずれかに記載の電子署名システム。
【請求項１５】
調剤薬局端末から電子署名付き処方データ要求情報を受け付け、この調剤薬局端末に該当の処方データを送信する電子署名システムであって、
処方データを特定する患者ＩＤを含む処方データに、医師及び患者の電子署名を生成した、電子署名付き処方データを、処方データベースに保管する処方データ保管手段、
上記調剤薬局端末から受信した、電子署名付き処方データ要求情報の電子署名を検証する署名検証手段と、
上記電子署名付き処方データ要求情報が正当であることを確認した後、上記処方データベースを検索し、該当する処方データを上記調剤薬局端末に送信する電子データ提供手段と
を備えたことを特徴とする電子署名システム。
【請求項１６】
病院サーバコンピュータに、患者に処方された処方データの送信を要求し、この病院サーバコンピュータから該当の処方データを受信する電子署名システムであって、
上記患者を特定する患者ＩＤを含む処方データ要求情報に薬剤師及び患者の電子署名を生成した、電子署名付き処方データ要求情報を上記病院サーバコンピュータに送信する処方データ要求手段
を備えたことを特徴とする電子署名システム。
【請求項１７】
第１のコンピュータから電子署名付き電子データ要求情報を受け付け、この第１のコンピュータに該当の電子データを送信する電子署名方法をコンピュータに実行させるためのプログラムであって、
電子データを特定するデータＩＤを含む電子データに、第１の署名者の電子署名を生成した、１以上の上記電子署名付き電子データを、電子データ保管ファイルに順次保管する電子データ保管ステップと、
上記第１のコンピュータから受信した、電子署名付き電子データ要求情報の電子署名を検証する署名検証ステップと、
上記電子署名付き電子データ要求情報が正当であることを確認した後、上記電子データ保管ファイルを検索し、該当する電子データを上記第１のコンピュータに送信する電子データ提供ステップと
をコンピュータに実行させるプログラム。
【請求項１８】
電子データを特定するデータＩＤを含む電子データを保管する第１のコンピュータに、特定の電子データの送信を要求し、この第１のコンピュータから該当の電子データを受信する電子署名方法をコンピュータに実行させるためのプログラムであって、
上記データＩＤを含む電子データ要求情報に第２の署名者の電子署名を生成した、電子署名付き電子データ要求情報を上記第１のコンピュータに送信する電子データ要求ステップと
をコンピュータに実行させるプログラム。
【請求項１９】
調剤薬局端末から電子署名付き処方データ要求情報を受け付け、この調剤薬局端末に該当の処方データを送信する電子署名方法を、コンピュータに実行させるためのプログラムであって、
処方データを特定する患者ＩＤを含む処方データに、医師及び患者の電子署名を生成した、電子署名付き処方データを受付ける処方データ受付ステップと、
上記電子署名付き処方データを処方データベースに保管する処方データ保管ステップと、
上記調剤薬局端末から受信した、上記電子署名付き処方データ要求情報の電子署名を検証する署名検証ステップと、
上記電子署名付き処方データ要求情報が正当であることを確認した後、上記処方データベースを検索し、該当する処方データを上記調剤薬局端末に送信する電子データ提供ステップと
をコンピュータに実行させるプログラム。
【請求項２０】
病院サーバコンピュータに患者に処方された処方データの送信を要求し、この病院コンピュータから該当の処方データを受信する電子署名方法を、コンピュータに実行させるためのプログラムであって、
上記患者を特定する患者ＩＤを含む処方データ要求情報に、薬剤師及び患者の電子署名を生成した、電子署名付き処方データ要求情報を受付ける処方データ要求情報受付ステップと、
上記病院サーバコンピュータに上記電子署名付き処方データ要求情報を送信する処方データ要求ステップと、
上記病院サーバコンピュータから患者ＩＤを含む処方データを受信する処方データ受信ステップと
を実行させるためのプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、電子署名システムにかかり、特に特定の署名者が署名した電子文書を、正当な要求に対して提供する電子署名システム及びそれをコンピュータに実行させるプログラムに関するものである。
【０００２】
【従来の技術】
電子署名とは、所定のハッシュ関数及び秘密鍵を用いて所定の電子文書データファイル（以下、電子文書）を暗号化し、得られた署名情報（署名データ）を該当の電子文書に付加することである。デジタル署名と呼ばれることもある。電子署名により、電子文書の正当性が保証され、改竄の有無を確認することができる。また電子署名ファイル（電子文書に署名情報を付加したファイル）の検証には、所定のハッシュ関数及び当該秘密鍵と対になる公開鍵が用いられる。
【０００３】
電子署名ファイルを作成・送信する人を署名者、この電子署名ファイルを受信・検証する人を検証者としたとき、通常、電子署名ファイルは、１又は複数の特定の署名者・検証者間で受け渡される。署名者は検証者に対して電子署名ファイルを送信し、検証者は、電子署名ファイルを受信して初めて電子署名ファイルの存在を認識し、所定のハッシュ関数及び当該秘密鍵と対となる公開鍵を用いて検証する。
【０００４】
一方、特開２００１−２３６３９５号公報には、病院で診察を受けた患者が処方データを薬局に持参しなくても調剤を受けることができる処方データペーパレスシステムが開示されている。このシステムでは、処方データを電子文書として、扱っている。
【０００５】
【特許文献１】
特開２００１−２３６３９５号公報
【０００６】
【発明が解決しようとする課題】
現在の電子署名システムは、署名者から検証者へ電子署名ファイルを送信し、検証者は、電子署名ファイルを受信して初めてその電子署名ファイルの存在を認識し、検証する構成となっている。つまり、検証者（受信者）が電子署名ファイルが存在していることだけを認知していて、正当な電子署名ファイルを受信・検証しようとしたとき、検証者側からこの正当な電子署名ファイルを入手する手段がない。
【０００７】
また、特開２００１−２３６３９５号公報に開示された技術では、患者の処方データと認証用データとを病院のＷｅｂサーバにある処方および認証データベースに登録し、患者の磁気カードから読み取ったデータと、処方および認証データベースとを照合し、承認が確立すると、調剤薬局がこの処方データをダウンロードして患者に調剤する。
【０００８】
だがこのような構成では、処方データと認証用データとをＷｅｂサーバに登録しているため、例えば一度処方データを登録した医師が意図的に処方データを細工することも可能であり、また第３者の改竄を防止することもできない。さらに、処方データをダウンロードした調剤薬局でも改竄を防止することができず、また改竄があったときは誰がどの時点で改竄されたのかを検知することができない。
【０００９】
また処方データを電子文書としたとき、処方された患者が検証者（受信者）となり、患者は病院を受診して薬が調剤されたことを認識しているので、患者側から電子文書を要求し、正当な処方データを入手できるように構成することが望ましい。
【００１０】
本発明は、かかる問題点を解決するためになされたものであり、例えば処方データのように、検証者（受信者）が電子文書が存在していることを認識し、正当な電子文書を要求したとき、該当する電子文書を提供する電子署名システム及びそれをコンピュータに実行させるプログラムを得ることを目的としている。
【００１１】
【課題を解決するための手段】
本発明に係る電子署名システムは、電子文書を特定する文書ＩＤと対応付けられた電子文書に、第１の署名者の電子署名を生成した、電子署名付き電子文書を、電子署名ファイルとして保管する電子署名ファイル保管手段を備えた第１のコンピュータ、上記文書ＩＤを含む電子署名ファイル要求情報に第２の署名者の電子署名を生成した、電子署名付き電子署名ファイル要求情報を上記第１のコンピュータに送信する電子署名ファイル要求手段を備えた第２のコンピュータを有し、さらに、上記第１のコンピュータは、上記第２のコンピュータから受信した、上記電子署名付き電子署名ファイル要求情報の電子署名を検証する署名検証手段と、上記電子署名付き電子署名ファイル要求情報が正当であることを確認した後、上記文書ＩＤに基づき、該当する電子署名ファイルを上記第２のコンピュータに送信する電子署名ファイル提供手段とを備えたものである。
【００１２】
また、電子データを特定するデータＩＤを含む電子データに、第１の署名者の電子署名を生成した、１以上の電子署名付き電子データを、電子データ保管ファイルに順次保管する電子データ保管手段を備えた第１のコンピュータ、上記データＩＤを含む電子データ要求情報に第２の署名者の電子署名を生成した、電子署名付き電子データ要求情報を上記第１のコンピュータに送信する電子データ要求手段を備えた第２のコンピュータを有し、さらに、上記第１のコンピュータは、上記第２のコンピュータから受信した、上記電子署名付き電子データ要求情報の電子署名を検証する署名検証手段と、上記電子署名付き電子データ要求情報が正当であることを確認した後、上記電子データ保管ファイルを検索し、該当する電子データを上記第２のコンピュータに送信する電子データ提供手段とを備えたことを特徴とするものである。
【００１３】
また、上記第１のコンピュータは、さらに、第１のコンピュータを示す電子署名を生成する第１の署名手段を有し、上記電子データ提供手段は、該当する電子データを上記第２のコンピュータに送信するとき、上記電子データが正当であることを示す上記第１のコンピュータの電子署名を、上記第１の署名手段に対して要求し、上記電子署名付き電子データに第１のコンピュータのさらなる電子署名を生成した、電子データを上記第２のコンピュータに送信することを特徴とするものである。
【００１４】
また、上記電子データ保管ファイルは、電子データ毎に提供済みであるかどうかを示すフラグを有し、上記電子データ提供手段は、上記電子データ要求情報に基づき、該当する電子データを提供したときは、該電子データの上記フラグを「提供済み」とし、このフラグが「提供済み」であるときは、該電子データを上記第２のコンピュータに送信しないことを特徴とするものである。
【００１５】
また、上記電子データ保管ファイルは、電子データ毎に提供回数を示すカウンタを有し、上記電子データ提供手段は、上記電子データ要求情報に基づき、該当する電子データを提供したときは、該電子データの上記カウンタを提供回数分、加算することを特徴とするものである。
【００１６】
また、上記第２のコンピュータは、さらに、第２の署名者の電子署名を生成する第２の署名手段と、上記第２の署名手段に対して、上記第１のコンピュータから受信した電子データに第２の署名者の電子署名を要求し、第２の署名者の電子署名付き電子データを電子データ保管ファイルに保管する第２の電子データ保管手段を有することを特徴とするものである。
【００１７】
また、上記電子署名ファイル要求情報に生成された、上記第２の署名者の電子署名は、上記第１の署名者の電子署名と同一であることを特徴とするものである。
【００１８】
また、上記電子署名ファイル要求情報に生成された、上記第２の署名者の電子署名は、上記第１の署名者の電子署名と異なることを特徴とするものである。
【００１９】
本発明に係る電子署名システムは、第１のコンピュータから電子署名付き電子データ要求情報を受け付け、この第１のコンピュータに該当の電子データを送信する電子署名システムであって、電子データを特定するデータＩＤを含む電子データに、第１の署名者の電子署名を生成した、１以上の上記電子署名付き電子データを、電子データ保管ファイルに順次保管する電子データ保管手段、上記第１のコンピュータから受信した、電子署名付き電子データ要求情報の電子署名を検証する署名検証手段と、上記電子署名付き電子データ要求情報が正当であることを確認した後、上記電子データ保管ファイルを検索し、該当する電子データを上記第１のコンピュータに送信する電子データ提供手段とを備えたものである。
【００２０】
本発明に係る電子署名システムは、電子データを特定するデータＩＤを含む電子データを保管する第１のコンピュータに、特定の電子データの送信を要求し、この第１のコンピュータから該当の電子データを受信する電子署名システムであって、上記データＩＤを含む電子データ要求情報に第１の署名者の電子署名を生成した、電子署名付き電子データ要求情報を上記第１のコンピュータに送信する電子データ要求手段を備えたことを特徴とするものである。
【００２１】
本発明に係る電子署名システムは、処方データを特定する患者ＩＤを含む処方データに、医師及び患者の電子署名を生成した、電子署名付き処方データを、処方データベースに保管する処方データ保管手段を備えた病院サーバコンピュータ、上記患者ＩＤを含む処方データ要求情報に薬剤師及び患者の電子署名を生成した、電子署名付き処方データ要求情報を上記病院サーバコンピュータに送信する処方データ要求手段を備えた調剤薬局端末を有し、さらに、上記病院サーバコンピュータは、上記調剤薬局端末から受信した、上記電子署名付き処方データ要求情報の電子署名を検証する署名検証手段と、上記電子署名付き処方データ要求情報が正当であることを確認した後、上記処方データベースを検索し、該当する処方データを上記調剤薬局端末に送信する処方データ提供手段とを備えたことを特徴とするものである。
【００２２】
また、上記病院サーバコンピュータは、さらに、病院サーバコンピュータを示す電子署名を生成する第１の署名手段を有し、上記処方データ提供手段は、該当する処方データを上記調剤薬局端末に送信するとき該当する電子データの正当性を示す病院サーバコンピュータの電子署名を第１の署名手段に要求し、病院サーバコンピュータのさらなる電子署名付きの処方データを上記調剤薬局端末に送信することを特徴とするものである。
【００２３】
また、上記処方データベースは、処方データ毎に提供済みであるかどうかを示すフラグを有し、上記処方データ提供手段は、上記処方データ要求情報に基づき、該当する処方データを提供したときは、該処方データの上記フラグを「提供済み」とし、このフラグが「提供済み」であるときは、該処方データを上記第２のコンピュータに送信しないことを特徴とするものである。
【００２４】
また、上記調剤薬局端末は、さらに、薬剤師の電子署名を生成する第２の署名手段と、上記第２の署名手段に対して、受信した処方データに基づく調剤記録への薬剤師の電子署名を要求し、薬剤師の電子署名付き調剤記録データを調剤データベースに記録する調剤記録手段を有することを特徴とするものである。
【００２５】
本発明に係る電子署名システムは、調剤薬局端末から電子署名付き処方データ要求情報を受け付け、この調剤薬局端末に該当の処方データを送信する電子署名システムであって、処方データを特定する患者ＩＤを含む処方データに、医師及び患者の電子署名を生成した、電子署名付き処方データを、処方データベースに保管する処方データ保管手段、上記調剤薬局端末から受信した、電子署名付き処方データ要求情報の電子署名を検証する署名検証手段と、上記電子署名付き処方データ要求情報が正当であることを確認した後、上記処方データベースを検索し、該当する処方データを上記調剤薬局端末に送信する電子データ提供手段とを備えたものである。
【００２６】
本発明に係る電子署名システムは、病院サーバコンピュータに、患者に処方された処方データの送信を要求し、この病院サーバコンピュータから該当の処方データを受信する電子署名システムであって、上記患者を特定する患者ＩＤを含む処方データ要求情報に薬剤師及び患者の電子署名を生成した、電子署名付き処方データ要求情報を上記病院サーバコンピュータに送信する処方データ要求手段を備えたことを特徴とするものである。
【００２７】
本発明に係るコンピュータに、電子署名方法を実行させるためのプログラムは、第１のコンピュータから電子署名付き電子データ要求情報を受け付け、この第１のコンピュータに該当の電子データを送信する電子署名方法をコンピュータに実行させるためのプログラムであって、電子データを特定するデータＩＤを含む電子データに、第１の署名者の電子署名を生成した、１以上の上記電子署名付き電子データを、電子データ保管ファイルに順次保管する電子データ保管ステップと、上記第１のコンピュータから受信した、電子署名付き電子データ要求情報の電子署名を検証する署名検証ステップと、上記電子署名付き電子データ要求情報が正当であることを確認した後、上記電子データ保管ファイルを検索し、該当する電子データを上記第１のコンピュータに送信する電子データ提供ステップとを備えたものである。
【００２８】
本発明に係るコンピュータに、電子署名方法を実行させるためのプログラムは、電子データを特定するデータＩＤを含む電子データを保管する第１のコンピュータに、特定の電子データの送信を要求し、この第１のコンピュータから該当の電子データを受信する電子署名方法をコンピュータに実行させるためのプログラムであって、上記データＩＤを含む電子データ要求情報に第２の署名者の電子署名を生成した、電子署名付き電子データ要求情報を上記第１のコンピュータに送信する電子データ要求ステップとを備えたものである。
【００２９】
本発明に係るコンピュータに、電子署名方法を実行させるためのプログラムは、調剤薬局端末から電子署名付き処方データ要求情報を受け付け、この調剤薬局端末に該当の処方データを送信する電子署名方法を、コンピュータに実行させるためのプログラムであって、処方データを特定する患者ＩＤを含む処方データに、医師及び患者の電子署名を生成した、電子署名付き処方データを受付ける処方データ受付ステップと、上記電子署名付き処方データを処方データベースに保管する処方データ保管ステップと、上記調剤薬局端末から受信した、上記電子署名付き処方データ要求情報の電子署名を検証する署名検証ステップと、上記電子署名付き処方データ要求情報が正当であることを確認した後、上記処方データベースを検索し、該当する処方データを上記調剤薬局端末に送信する電子データ提供ステップとを備えたものである。
【００３０】
本発明に係るコンピュータに、電子署名方法を実行させるためのプログラムは、病院サーバコンピュータに患者に処方された処方データの送信を要求し、この病院コンピュータから該当の処方データを受信する電子署名方法を、コンピュータに実行させるためのプログラムであって、上記患者を特定する患者ＩＤを含む処方データ要求情報に、薬剤師及び患者の電子署名を生成した、電子署名付き処方データ要求情報を受付ける処方データ要求情報受付ステップと、上記病院サーバコンピュータに上記電子署名付き処方データ要求情報を送信する処方データ要求ステップと、上記病院サーバコンピュータから患者ＩＤを含む処方データを受信する処方データ受信ステップとを備えたものである。
【００３１】
【発明の実施の形態】
実施の形態１．
本実施の形態は、公開鍵暗号方式  （Ｐｕｂｌｉｃ  Ｋｅｙ  Ｃｒｙｐｔｏｇｒａｐｈｙ）に基づき、秘密鍵（署名鍵）で電子文書（電子データ）に電子署名をし、秘密鍵と対となる公開鍵（検証鍵）で、電子文書を検証する電子署名システムであるとする。公開鍵証明書（Ｐｕｂｌｉｃ  Ｋｅｙ  Ｃｅｒｔｉｆｉｃａｔｅ、以下証明書）は、認証局（Ｃｅｒｔｉｆｉｃａｔｉｏｎ  Ａｕｔｈｏｒｉｔｙ  （ＣＡ））で発行され、有効性検証局で証明書の有効性を確認する。証明書には、公開鍵とその所有者を証明する情報が登録されている。
【００３２】
本実施の形態は、病院と調剤薬局とで、処方データの要求・提供に関する電子署名システムを実現したものである。処方データが電子文書となり、病院を受診した患者は処方データが存在していることを認識していて、調剤薬局に赴き、正当な処方データに基づく、調剤を要求する。
【００３３】
図１は、本実施の形態のシステム構成図を示したものである。図１に示すように、病院には、病院サーバ（病院サーバコンピュータ）１、受付端末２、医師端末３があり、受付端末２と医師端末３にはそれぞれＩＣカードリードライタ（以下、ＩＣカードＲ／Ｗ）４が附属されている。また、調剤薬局には調剤薬局端末５があり、やはりＩＣカードＲ／Ｗ４が附属されている。ＩＣカードＲ／Ｗ４は、診察券等のＩＣカードから秘密鍵を読みこんだり、診察券に必要な情報を書きこんだりする。図１では簡略化のため、１つの病院と、１つの調剤薬局で構成するように記載しているが、病院、調剤薬局とも、複数で構成することが可能である。病院サーバ１と調剤薬局端末５とは、インターネット等のネットワークを介して接続されるため、１つの病院サーバ１に対して、複数台の調剤薬局端末５よりアクセスすることが可能である。
【００３４】
６は認証局であり、７は有効性認証局である。また８は、病院サーバ１にあるサブＣＡ（Ｓｕｂｏｒｄｉｎａｔｅ  ＣＡ、下位ＣＡ）であり、階層型ＣＡである認証局６の下位に置かれている。サブＣＡ８は、ＣＡ６が発行した証明書を有し、受付端末２及び医師端末３からの証明書発行要求に対して、公開鍵を証明する証明書を発行する機能を持つ。９は、証明書申請手段であり、患者の秘密鍵と公開鍵のペアを作成し、サブＣＡ８に、患者の公開鍵を証明する証明書の発行を要求し、発行された証明書を、患者の秘密鍵、公開鍵とともに端末に送信する。また、証明書申請手段９は、医師用の秘密鍵と公開鍵のペアも作成し、医師用の公開鍵を証明する証明書の発行をサブＣＡ８に要求する。
【００３５】
さらに、１０は患者情報作成手段、１１は患者データベース、１２は調剤薬局端末５と情報の送受信を行う、病院Ｗｅｂアプリケーションである。１３は通信を行う通信手段、１４は処方データベースに病院サーバ１を示す電子署名を生成する署名手段（第１の署名手段）、１５は、調剤薬局端末５から受信した、電子署名付き処方データ要求情報の電子署名を検証する署名検証手段である。
【００３６】
さらに１６は処方データ提供手段、１７は処方データ保管手段、１８は処方データベースである。処方データ提供手段１６は、署名検証手段１５が電子署名付き処方データ要求情報の正当性を確認した後、処方データベース１８を検索し、該当する処方データを調剤薬局端末５に送信する。また処方データ保管手段１７は、患者ＩＤを含む処方データに、医師及び患者の電子署名を生成した、電子署名付き処方データを処方データベース１８に保管する。上述した１３〜１７は、病院Ｗｅｂアプリケーション１２に含まれている。
【００３７】
また受付端末２には、次の１８〜２０がある。１８は患者毎の、秘密鍵、公開鍵及び証明書の発行を病院サーバ１に要求する証明書要求手段、１９はＩＣカードＲ／Ｗと連動して、ＩＣカードへの読書きを行うＩＣカード読書手段、２０は入力装置（図示せず）からの入力を受け付ける入力受付手段である。初診時、ＩＣカードに患者毎の患者の秘密鍵、証明書、病院の証明書を記憶し、患者毎の診察券とする。病院の証明書には、病院を証明する情報として、病院ＩＤ（ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ））が登録されている。
【００３８】
また医師端末３には、次の２１〜２４がある。２１は病院サーバ１との通信を行う通信手段、２２は医師及び患者の署名をする署名手段、２３は入力装置（図示せず）からの入力を受け付ける入力受付手段、２４はＩＣカードＲ／Ｗと連動して、ＩＣカードへの読書きを行うＩＣカード読取手段である。
【００３９】
調剤薬局端末５には、次の２５〜３２がある。２５は病院サーバとの通信を行う通信手段、２６は処方データの署名を検証する署名検証手段、２７は患者ＩＤを含む処方データ要求情報を病院サーバ１に送信する処方データ要求手段、２８は薬剤師及び患者の署名をする署名手段、２９は受信した処方データに基づく調剤記録を記録する調剤記録手段、３０は調剤記録手段２９が調剤記録を記録する調剤データベースである。また３１は受信した処方データを表示装置（図示せず）に表示する表示手段、３１はＩＣカードＲ／Ｗと連動して、ＩＣカードへの読書きを行うＩＣカード読取手段である。
【００４０】
次に患者が病院で受付をしてから調剤薬局で薬を手に入れるまでの、患者、受付事務担当、医師、薬剤師の動作を簡単に説明する。患者は病院での診察を希望すると、まず受付に赴き、受付事務担当の指示に従い、受付端末２にて、病院が必要とする患者情報を入力する。患者は必要事項を紙に記載して、受付事務担当が入力しても良い。また２度目以降の受診のときは、受診科目に関係することを回答すればよい。その後患者は、病院固有の診察券を受付で渡され、その診察券を持って医師の診察室に赴き、診察を受診する。診察券には患者の秘密鍵、証明書、病院の証明書が記憶されている。
【００４１】
患者は医師の診察を受け、医師は薬を処方するために処方データを作成する。医師は、その処方データにＩＣカードを用いて医師の署名をし、患者は処方内容を納得した上で、診察券を用いて患者の署名をし、医師・患者の署名付き処方データは、病院サーバ１に処方データとして保管される。その後患者は、本システムが稼動している任意の調剤薬局に出向き、診察券を調剤薬局の薬剤師に見せ、薬の調剤を所望する。患者は診察券をＩＣカードＲ／Ｗに読み込ませ、それにより患者ＩＤ、さらに病院の証明書から病院ＩＤ情報を取得することができ、調剤薬局の署名と患者の署名をした、電子署名付き処方データ要求情報を病院サーバ１に送信する。病院サーバ１では電子署名付き処方データ要求情報の正当性を確認し、検証が正しければ該当の処方データに病院の署名をして、調剤薬局宛に送信する。調剤薬局端末は、処方データを受信し、処方データの正当性を確認した後、それを薬剤師に通知し、薬剤師は提供された処方データに基づき、薬を調剤する。患者はこの一連の作業で、薬を入手することができる。また、処方データに基づいた調剤記録に、薬剤師及び患者が署名をして、調剤記録データベースに保管する。
【００４２】
次に、データベースの構造を説明する。図２は、患者情報データベース１１の構成を示した図であり、図２に示すように、患者情報データベース１１には一意の患者ＩＤ、患者名、受付にて診察を希望した診察科、既往症、アレルギー歴、住所、電話番号などが患者毎に登録される。患者毎の情報は、最初に受付にて診察券を発行したときに、新規に作成され、２回目以降の受診時には追加の情報が更新される。
【００４３】
図３は、処方データベース１８の構成を示した図である。図３に示すように、処方データベース１８には受診した患者毎の、１又は複数の薬の名称、調剤量、調剤個数などが蓄積されている。医師が作成した処方データに、医師及び患者の署名がされるため、明示していないがそれぞれの処方データには、医師及び患者の署名データが附属している。
【００４４】
図４は、調剤データベース３０の構成を示した図である。図４に示すように、薬剤師は受信した処方データに基づき薬を調剤すると、その調剤記録を調剤データベース３０に、記憶する。調剤データベース３０の１つ１つの調剤データには調剤ＩＤ、病院ＩＤ、処方ＩＤ、患者ＩＤ、調剤に関する記録等が蓄積される。
【００４５】
次に図２及び図５を用いて、受付端末２にて診察券を発行する処理の流れを説明する。図５は本実施の形態における診察券を発行する処理を示した、フローチャートである。受付端末２で入力受付手段２０が入力装置（図示せず）から患者情報を受けつけると（ステップＳ１）、証明書要求手段２がこの患者情報を病院サーバ１に送信し、患者の証明書発行を要求する（ステップＳ２）。病院サーバ１の患者情報作成手段１０は、受信した患者情報を患者データベース１１に保存し、患者に対応する患者ＩＤを取得する（ステップＳ３）。患者データベース１１は、図２に示したとおりである。
【００４６】
その後、証明書申請手段９が受信した患者情報に基づき、患者の公開鍵と秘密鍵のペアを作成し、サブＣＡ８に対して、公開鍵を証明する証明書の発行を要求する（ステップＳ４）。サブＣＡ８では、証明書申請手段９からの申請内容に対して、署名を施し、患者の証明書を発行する。またサブＣＡ８は、診察券に記憶するために、証明書申請手段９に対して、病院の証明書も発行する（ステップＳ５）。次に、証明書申請手段９は患者の患者ＩＤ、秘密鍵、証明書及び病院の証明書を受付端末２に送信する（ステップＳ６）。証明書には、前述したように、患者の公開鍵と、患者を証明する情報が登録されている。受付端末２の証明書要求手段１８は、患者の患者ＩＤ、秘密鍵、証明書及び病院の証明書を受信し（ステップＳ７）、ＩＣカード読書手段１９は証明書要求手段１８が受信した、患者の患者ＩＤ、秘密鍵、証明書及び病院の証明書を診察券（ＩＣカード）に書き込む（ステップＳ８）。また上述したように、病院の証明書には、病院ＩＤ（ＵＲＬ）が含まれている。これで、患者毎の診察券が発行される。
【００４７】
次に図３及び図６を用いて、医師端末３にて処方データを作成する処理の流れを説明する。図６は、処方データ作成処理の流れを示したフローチャートである。患者の診察を行った医師は、入力装置（図示せず）を用いて、処方データを入力する。医師端末３の入力受付手段２３は、受け付けたデータにより、処方データを作成し（ステップＳ１１）、表示装置（図示せず）に、その作成した処方データを表示する。このとき、医師は患者に処方データを説明し、患者の合意を得ることが考えられる。
【００４８】
その後、処方データに医師の署名をするために、署名手段２２は表示装置（図示せず）に、「ＩＣカードＲ／Ｗ４に、医師の秘密鍵を記憶しているＩＣカードを挿入する」旨を促すメッセージを表示する。それにより、医師が所定のＩＣカードをＩＣカードＲ／Ｗ４に挿入するため、ＩＣカードから医師の秘密鍵を読み込み、処方データに医師の署名をする（ステップＳ１２）。その後、処方データに患者の署名をするために、署名手段２２は表示装置（図示せず）に、「ＩＣカードＲ／Ｗ４に、患者の診察券を挿入する」旨を促すメッセージを表示する。ＩＣカード読書手段２４は、診察券から患者の秘密鍵を読み込み、処方データに患者の署名をする（ステップＳ１３）。通信手段２１は、医師及び患者の署名付き処方データを病院サーバ１に送信し（ステップＳ１４）、病院サーバ１の通信手段１３がその処方データを受信する。処方データ保管手段１７は、通信手段１３から渡された処方データを処方データベース１８に保存する（ステップＳ１５）。処方データベース１８の構成は、図３に示したとおりであり、明示していないが、処方データ毎に、医師及び患者の署名データが附属されている。
【００４９】
次に、病院を受診した患者が病院の診察券を持参して任意を調剤薬局に出向き、薬を所望する処理の流れについて、図３及び図７を用いて説明する。図７は、処方データ要求処理の流れを示したフローチャートである。調剤薬局端末５のＩＣカード読書手段３２は、ＩＣカードＲ／Ｗ４に挿入された患者の診察券を読み込み、患者ＩＤを取得し、さらに病院の証明書から病院ＩＤ（ＵＲＬ）の情報を取得する（ステップＳ２１）。処方データ要求手段２７は、読みこんだ患者ＩＤ及び病院ＩＤから処方データ要求情報を生成し、処方データ要求情報に薬剤師の署名をするために、署名手段２８は表示装置（図示せず）に、「ＩＣカードＲ／Ｗ４に、薬剤師の秘密鍵を記憶しているＩＣカードを挿入する」旨を促すメッセージを表示する。ＩＣカード読書手段３２は、ＩＣカードから薬剤師の秘密鍵を読み込み、署名手段２８は読みこんだ秘密鍵で、薬剤師の署名をする（ステップＳ２２）。次に、処方データ要求情報に患者の署名をするために、署名手段２８は表示装置（図示せず）に、「ＩＣカードＲ／Ｗ４に、診察券を挿入する」旨を促すメッセージを表示する。ＩＣカード読書手段３２は、診察券から患者の秘密鍵を読み込み、署名手段２８は読みこんだ秘密鍵で、患者の署名をする（ステップＳ２３）。
【００５０】
通信手段２５は、病院ＩＤであるＵＲＬに、処方データ要求情報を送信し（ステップＳ２４）、病院サーバ１の署名検証手段１５は、処方データ要求情報に関して署名の検証と、証明書の有効性検証とをし（ステップＳ２５）、検証の結果、「検証ＯＫ」であれば、ステップＳ２６の処理に移る。ステップＳ２５の検証の結果、「検証ＮＧ」であれば、病院サーバ１の署名検証手段１５は、調剤薬局端末に、検証の結果、「検証ＮＧ」であり、処方データを提供できない旨を通知する（ステップＳ３０）。
【００５１】
ステップＳ２５で処方データ要求情報の正当性が確認された後、処方データ提供手段１６は、患者ＩＤに対する処方データを取り出し（ステップＳ２６）、署名手段１４は取り出した処方データに、病院を特定する秘密鍵を用いて、署名し、通信手段１３を用いて、病院の署名付き処方データを調剤薬局端末５に送信する（ステップＳ２７）。調剤薬局端末５の署名検証手段２６は、処方データの署名を検証し、有効性検証局７に対して、病院、患者、医師の証明書の有効性検証とをし（ステップＳ２８）、検証の結果、「検証ＯＫ」であれば、ステップＳ２９の処理に移る。ステップＳ２８の検証の結果、「検証ＮＧ」であれば、署名検証手段２６は、表示装置（図示せず）、検証の結果、「検証ＮＧ」であり、処方データにより調剤できない旨を通知する（ステップＳ３１）。
【００５２】
ステップＳ２８で処方データ要求情報の正当性が確認された後、表示手段３１は検証された処方データに基づき、表示装置（図示せず）に処方データを表示する（ステップＳ２９）。その表示された処方データにより、薬剤師は患者の薬を調剤する。このように、図７に示した処理の流れで、患者は、自分に処方された処方データが存在していることを認知し、調剤薬局に出向いたとき、正当な処方データにて調剤された薬を手に入れることができる。
【００５３】
ステップＳ２５及びステップＳ２８に示した、署名検証手段１５の署名の検証と、証明書の有効性検証について、追記すると、署名検証手段１５は、署名による改竄検証と、有効性認証局７に問合せることによる証明書の有効性検証の機能を有する。処方データまたは処方データ要求情報には、署名情報が附属している。署名情報としては、次の（１）、（２）が含まれている。
（１）署名者を証明する証明書（公開鍵を含む）
（２）所定のハッシュ関数を用いて元のデータを変換した、ダイジェストと呼ばれる固定長のビット列を秘密鍵で暗号化したデータ
【００５４】
改竄検証は、元のデータを（２）で用いたハッシュ関数で、ダイジェストを作成し、（２）のデータを公開鍵を用いて復号したダイジェストとを比較し、同一であるかどうかを検証する。また、証明書の有効性検証は、署名情報に含まれる証明書を、有効性検証局７に送付し、証明書の正当性を確認する。有効性検証局７で検証していることを具体的に示すと、次の（１）〜（３）である。
（１）検証を要求した証明書が信頼する認証局から発行されていること。
（２）証明書の有効期間が期限が切れていないこと。
（３）証明書が失効されていないこと。
（１）を検証することにより、証明書の信頼性を検証することができる。また例えば、秘密鍵を紛失してしまったときは、その秘密鍵の悪用を防ぐために証明書を失効させるが、有効期限と失効していないことを確認することにより、秘密鍵が現在有効であることを確認することができる。
【００５５】
本実施の形態では、秘密鍵と公開鍵のペアを生成し、電子署名をするのは、医師・患者・薬剤師としている。また、処方データ要求データが正当であることを確認した後、処方データを調剤薬局端末５に送信するときは、病院の電子署名をすることとしている。電子署名は、人（自然人）が行うのが一般的であり、通常の処理は、医師・患者・薬剤師が自分の秘密鍵を用いて、自らの意思による電子署名を受けつけるように構成している。この電子署名により、病院サーバ１に保管されていた処方データが正当であることを確認でき、これにより、処方データを登録した医師が意図的に処方データを細工したときや第３者による改竄があったときは、判別することができる。
【００５６】
一方、図７に示したステップＳ２７では、署名手段１４は取り出した処方データに、病院を特定する秘密鍵を用いて、署名している。署名手段１４が病院を特定する秘密鍵で署名をするように構成することにより、病院サーバ１から調剤薬局端末５への送信時の改竄を検証することができる。また、ステップＳ２８で、調剤薬局端末５の署名検証手段２６が処方データを検証することで、調剤薬局でも改竄があったかどうかを、確認することができる。
【００５７】
また、病院サーバ１と調剤薬局端末５とのネットワークの安全性が別の方法により確保されているとき、例えば病院サーバ１と調剤薬局端末５とが専用線で接続されているときは、ステップＳ２７で実施した、病院の秘密鍵での署名を、省略することができる。
【００５８】
次に、薬剤師が調剤をした記録を作成する処理の流れについて、図４及び図８を用いて説明する。図８は、調剤記録を作成する処理の流れを示したフローチャートである。図４に示した調剤情報データベース３０に、薬剤師が調剤する度に、調剤記録を蓄積していくが、調剤記録は例えば表示装置（図示せず）に表示される「入力画面」に必要事項を入力することで、作成される。調剤記録手段２９が調剤記録を作成し、その調剤記録に薬剤師の署名をするために、署名手段２８は表示装置（図示せず）に、「ＩＣカードＲ／Ｗ４に、薬剤師の秘密鍵を記憶しているＩＣカードを挿入する」旨を促すメッセージを表示する。ＩＣカード読書手段３２は、ＩＣカードから薬剤師の秘密鍵を読み込み、署名手段２８は読みこんだ秘密鍵で、薬剤師の署名をする（ステップＳ３１）。次に、調剤記録に患者の署名をするために、署名手段２８は表示装置（図示せず）に、「ＩＣカードＲ／Ｗ４に、診察券を挿入する」旨を促すメッセージを表示する。ＩＣカード読書手段３２は、診察券から患者の秘密鍵を読み込み、署名手段２８は読みこんだ秘密鍵で、患者の署名をする（ステップＳ３２）。調剤記録手段２９は、薬剤師及び患者の電子署名付き調剤記録を調剤データベース３０に保存する（ステップＳ３３）。以上で、調剤記録を作成する処理を終了する。
【００５９】
以上説明したように、本実施の形態では、患者は、自分に処方された処方データが存在していることを認知し、調剤薬局に出向いたとき、正当な処方データにて調剤された薬を手に入れることができる。また、処方データに医師及び患者の電子署名をし、処方データ要求情報に薬剤師及び患者の電子署名をして、その都度、改竄検証と、証明書の有効性検証を実施しているので、不正データにより薬を処方されたり、不正な第３者に処方データが漏洩することがない。さらに、調剤記録は調剤薬局端末５に薬剤師及び患者の電子署名付きで保存しておくので、調剤に不正があったときは、処方データと調剤記録とを照合することができる。
【００６０】
実施の形態２．
本実施の形態は、第１のコンピュータに保管した電子署名付き電子データを第２のコンピュータから要求するシステムである。実施の形態１は、病院と調剤薬局とで、処方データの要求・提供に関する電子署名システムを実現したものであるが、本実施の形態の電子データは処方データに限らず、第１のコンピュータに保管して、第２のコンピュータから要求する電子データであれば、よい。本実施の形態では、電子データは、自治体で発行される公的書類であるとし、一例として「印鑑証明書」で説明する。また第１のコンピュータを自治体サーバとし、第２のコンピュータを自治体サーバに接続可能な端末であるとする。また、電子データに署名をする第１の署名者を、自治体の窓口担当者、電子データ要求情報に署名する第２の署名者を、印鑑所有者とする。
【００６１】
図９は、本実施の形態のシステム構成図を示したものである。図９において、実施の形態１で示した図１と同一の構成については、同一符号を付している。図９に示すように、自治体には、自治体サーバ４１、自治体端末４２があり、自治体端末４２にはＩＣカードＲ／Ｗ４が附属されている。また、端末４３には、やはりＩＣカードＲ／Ｗ４が附属されている。自治体サーバ１と、端末４３とは、ネットワークを介して接続されている。
【００６２】
本実施の形態においても、本人の秘密鍵と証明書は、ＩＣカードに保存されているとし、ＩＣカードＲ／Ｗ４は、ＩＣカードから秘密鍵を読みこんだり、必要な情報を書きこんだりする。また端末４３は、パソコン、携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｃｅ）などが考えられる。図９では簡略化のため、１つの自治体と、１つの端末で構成するように記載しているが、自治体サーバ１と、端末４３は、ネットワークで接続されるので、複数台で構成することが可能である。
【００６３】
６〜９は、実施の形態１で説明したとおりである。４４は端末４３と情報の送受信を行う、自治体Ｗｅｂアプリケーションである。４５は通信を行う通信手段、４６は「印鑑証明書」に自治体サーバ４１を示す電子署名を生成する署名手段（第１の署名手段）、４７は、端末４３から受信した、電子署名付き「印鑑証明書」要求情報の電子署名を検証する署名検証手段である。
【００６４】
さらに４８は電子データ提供手段、４９は電子データ保管手段、５０は電子データ保管ファイルである。電子データ提供手段４８は、署名検証手段４７が電子署名付き「印鑑証明書」要求情報の正当性を確認した後、電子データ保管ファイル５０を検索し、該当する「印鑑証明書」を端末４３に送信する。また電子データ保管手段４９は、「印鑑証明書」を特定するデータＩＤを含む「印鑑証明書」に、自治体の窓口担当者の電子署名を生成した、電子署名付き「印鑑証明書」を電子データ保管ファイル５０に保管する。上述した４５〜４９は、自治体Ｗｅｂアプリケーション４４に含まれている。
【００６５】
また自治体端末４２には、次の５０〜５４がある。５０は印鑑所有者の、秘密鍵、公開鍵及び証明書の発行を自治体サーバ４１に要求する証明書要求手段、５１はＩＣカードＲ／Ｗと連動して、ＩＣカードへの読書きを行うＩＣカード読書手段、５２は入力装置（図示せず）からの入力を受け付ける入力受付手段である。印鑑登録時に、ＩＣカードに印鑑所有者毎の秘密鍵・証明書・病院の証明書を記憶する。５３は自治体サーバ４１との通信を行う通信手段、５４は窓口担当者の署名をする署名手段である。
【００６６】
端末４３には、次の５５〜６０がある。５５は自治体サーバ４１との通信を行う通信手段、５６は「印鑑証明書」の署名を検証する署名検証手段、５７はデータＩＤを含む電子データ要求情報を自治体サーバ４１に送信する電子データ要求手段、５８は印鑑所有者の署名をする署名手段、５９は受信した「印鑑証明書」を表示装置（図示せず）に表示する表示手段、６０はＩＣカードＲ／Ｗと連動して、ＩＣカードへの読書きを行うＩＣカード読取手段である。
【００６７】
次に印鑑所有者が印鑑登録のために、自治体の窓口に出向き、印鑑登録を受けてから、自宅等で「印鑑証明書」を手に入れるまでの、窓口担当者及び印鑑所有者の動作を簡単に説明する。印鑑所有者は、印鑑の登録を希望すると、まず自治体の窓口に赴き、窓口担当者の指示に従い、自治体端末４２にて、印鑑登録に必要とする情報を入力する。印鑑所有者は必要事項を紙に記載して、窓口担当者が入力しても良い。その後、印鑑所有者は、印鑑を特定するデータＩＤ、所有者の秘密鍵、証明書、及び自治体サーバの証明書が記憶されたＩＣカードを受け取る。自治体サーバの証明書には、自治体ＩＤ（ＵＲＬ）が登録されている。自治体サーバ４１では、印鑑登録データに、窓口担当者の署名をし、窓口担当者の署名付き印鑑登録データは、電子データ保管ファイル５０に保管される。
【００６８】
その後印鑑所有者は、「印鑑証明書」が必要となったとき、任意の端末４３から「印鑑証明書」を所望する。印鑑所有者は、ＩＣカードをＩＣカードＲ／Ｗに読みこませ、データＩＤと自治体ＵＲＬ情報を取得し、印鑑所有者の署名をした、電子署名付き電子データ要求手段を自治体サーバ４１に送信する。自治体サーバ４１では電子署名付き電子データ要求手段の正当性を確認し、検証が正しければ該当の「印鑑証明書」に自治体の署名をして、端末４３に送信する。印鑑所有者は、「印鑑証明書」を受信し、正当性を確認した後、目的に応じて「印鑑証明書」を使用する。
【００６９】
次に、データベースの構造を説明する。図１０は、電子データ保管ファイル５０の構成を示した図であり、図１０に示すように、電子データ保管ファイル５０には一意のデータＩＤ、所有者ＩＤ、印鑑情報、所有者情報、提供回数（「印鑑証明書」の提供回数）などが印鑑毎に登録される。提供回数は、正当な電子データ要求情報に基づき、「印鑑証明書」を発行する度に、更新される。
【００７０】
次に図１０及び図１１を用いて、自治体端末４２にて印鑑登録をする処理の流れを説明する。図１１は本実施の形態における印鑑登録処理を示した、フローチャートである。自治体端末４２で入力受付手段５２が入力装置（図示せず）から印鑑情報を受けつけると（ステップＳ４１）、証明書要求手段５０がこの印鑑情報を自治体サーバ４１に送信し、印鑑所有者の証明書発行を要求する（ステップＳ４２）。自治体サーバ４１の電子データ保管手段４９は、受信した印鑑情報を電子データ保管ファイル５０に保存し、登録した印鑑に対応するデータＩＤ及び所有者ＩＤを取得する（ステップＳ４３）。この印鑑情報とは、印鑑所有者に関する情報や印鑑の印影など、図２に示した電子データ保管ファイルに保存されるものである。
【００７１】
その後、証明書申請手段９が受信した印鑑情報に基づき、印鑑所有者の公開鍵と秘密鍵のペアを作成し、サブＣＡ８に対して、公開鍵を証明する証明書の発行を要求する（ステップＳ４４）。サブＣＡ８では、証明書申請手段９からの申請内容に対して、署名を施し、印鑑所有者の証明書を発行する。またサブＣＡ８は、ＩＣカードに記憶するために、証明書申請手段９に対して、自治体の証明書も発行する（ステップＳ４５）。
【００７２】
次に、証明書申請手段９は印鑑所有者の所有者ＩＤ、秘密鍵、証明書及び自治体の証明書を自治体端末４２に送信する（ステップＳ４６）。証明書には、前述したように、印鑑所有者の公開鍵と、印鑑所有者を証明する情報が登録されている。自治体端末４２の証明書要求手段５０は、印鑑所有者の所有者ＩＤ、秘密鍵、証明書及び自治体の証明書を受信し（ステップＳ４７）、ＩＣカード読書手段５１は証明書要求手段５０が受信した、印鑑所有者の所有者ＩＤ、秘密鍵、証明書及び自治体の証明書をＩＣカードに書き込む（ステップＳ４８）。これで、印鑑所有者毎のＩＣカードが発行される。
【００７３】
次に、図１２を用いて印鑑所有者が任意のときに、「印鑑証明書」を要求する処理について、説明する。図１２は、「印鑑証明書」要求処理の流れを示したフローチャートである。端末４３のＩＣカード読書手段６０は、ＩＣカードＲ／Ｗ４に挿入されたＩＣカードを読み込み、データＩＤと自治体ＩＤ（ＵＲＬ）の情報を取得する（ステップＳ５１）。電子データ要求手段５７は、読みこんだデータＩＤ及び自治体ＩＤから電子データ要求情報を生成し（ステップＳ５２）、電子データ要求情報に印鑑所有者の署名をするために、署名手段５８は表示装置（図示せず）に、「ＩＣカードＲ／Ｗ４に、印鑑所有者の秘密鍵を記憶しているＩＣカードを挿入する」旨を促すメッセージを表示する。ＩＣカード読書手段６０は、ＩＣカードから印鑑所有者の秘密鍵を読み込み、署名手段５８は読みこんだ秘密鍵で、印鑑所有者の署名をする（ステップＳ５３）。
【００７４】
通信手段５５は、自治体ＩＤであるＵＲＬに、電子データ要求情報を送信し（ステップＳ５４）、自治体サーバ４１の署名検証手段４７は、処方データ要求情報に関して署名の検証と、証明書の有効性検証とをし（ステップＳ５５）、検証の結果、「検証ＯＫ」であれば、ステップＳ５６の処理に移る。ステップＳ５５の検証の結果、「検証ＮＧ」であれば、自治体サーバ４１の署名検証手段４７は、端末４３に、検証の結果、「検証ＮＧ」であり、電子データ（「印鑑証明書」）を提供できない旨を通知する（ステップＳ６０）。
【００７５】
ステップＳ５５で電子データ要求情報の正当性が確認された後、電子データ提供手段４８は、データＩＤに対する印鑑情報を取り出し（ステップＳ５６）、署名手段４６は取り出した印鑑情報に、自治体を特定する秘密鍵を用いて、署名し、通信手段４５を用いて、自治体の署名付き「印鑑証明書」を端末４３に送信する（ステップＳ５７）。端末４３の署名検証手段５６は、「印鑑証明書」の署名を検証し、有効性検証局７に対して、自治体の証明書の有効性検証とをし（ステップＳ５８）、検証の結果、「検証ＯＫ」であれば、ステップＳ５９の処理に移る。ステップＳ５８の検証の結果、「検証ＮＧ」であれば、署名検証手段５６は、表示装置（図示せず）、検証の結果、「検証ＮＧ」であり、印鑑証明書を入手できなかった旨を通知する（ステップＳ６１）。
【００７６】
ステップＳ５８で印鑑証明書の正当性が確認された後、表示手段５９は検証された「印鑑証明書」を、表示装置（図示せず）に表示する（ステップＳ５９）。表示された「印鑑証明書」は、必要に応じて、印刷または記憶装置（図示せず）に記憶することができる。ステップＳ５５及びステップＳ５８に示した、署名検証手段４７の処理については、実施の形態１で上述したとおりである。
【００７７】
また本実施の形態においても、図１２に示したステップＳ５７の処理で、署名手段４６は取り出した印鑑情報に、自治体を特定する秘密鍵を用いて、署名している。これは、自治体サーバ４１に保管されていた印鑑情報が正当であることを確認し、その正当性を示す電子署名である。「印鑑証明書」は、印鑑情報に、自治体の署名を付したもので構成される。ステップＳ２７で、署名手段４６が自治体を特定する秘密鍵で署名をするように構成することにより、保管時の改竄がないことを証明することができる。また、ステップＳ５８で、端末４３の署名検証手段５６が「印鑑証明書」の電子署名を検証することで、端末４３でも改竄があったかどうかを、確認することができる。
【００７８】
本実施の形態では、電子データに署名をする第１の署名者を、自治体の窓口担当者、電子データ要求情報に署名する第２の署名者を、印鑑所有者としたが、第１の署名者・第２の署名者とも、印鑑所有者とすることもできる。つまり、第１の署名者と、第２の署名者は、同一とすることも、異なるようにすることもできる。さらに、第１の署名者を、自治体の窓口担当及び印鑑所有者とし、第２の署名者を、印鑑所有者と構成することができる。印鑑所有者の代理人が「印鑑証明書」を要求するときは、電子データ要求情報に、印鑑所有者及び代理人の電子署名を付すように、構成することもできる。
【００７９】
また自治体サーバ４１は、市町村単位に設置することも可能であるし、県単位や西日本・東日本などの分類で設置することも可能である。また複数の自治体サーバ４１に接続可能な構成にするときは、印鑑所有者に発行するＩＣカードに、複数の自治体の証明書を登録しておけばよい。
【００８０】
さらにＩＣカードには、ＩＣカード所有者の秘密鍵、証明書及び自治体の証明書が登録されているので、ＩＣカードを「印鑑証明書」だけでなく、各種公的書類の発行要求に用いることができる。
【００８１】
実施の形態３．
本実施の形態は、第１のコンピュータに保管した電子署名付き電子文書を第２のコンピュータから要求するシステムである。例えば、会社のコンピュータで作成した電子署名付き電子文書を、自宅または客先などのコンピュータで取り出す処理などが考えられる。本実施の形態では、一例として第１のコンピュータを会社サーバ６１、第２のコンピュータを自宅端末６３としている。実施の形態２では、電子データとして公的書類の一例として「印鑑証明書」で説明したが、本実施の形態は実施の形態２の電子データを電子文書に置き換えた構成である。。
【００８２】
図１３は、本実施の形態のシステム構成図を示したものである。図１３において、実施の形態１で示した図１または実施の形態２で示した図９と同一の構成については、同一符号を付している。６１は会社サーバ、６２は会社サーバ６１に接続された自席端末、６３は自宅端末、６４は会社ＷＥｂアプリケーションである。また、６５は電子署名ファイル提供手段、６６は電子署名ファイル保管手段、６７は電子署名ファイル、６９は電子署名ファイル要求手段である。電子署名ファイル６７は、会社サーバ６１に複数蓄積されている。
【００８３】
本実施の形態においても、本人の秘密鍵と証明書は、ＩＣカードに保存されているとし、ＩＣカードＲ／Ｗ４は、ＩＣカードから秘密鍵を読みこんだり、必要な情報を書きこんだりする。また自宅端末６３は、パソコン、携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｃｅ）などである。
【００８４】
次に電子ファイルの所有者が会社で電子署名ファイルを作成し、自宅で電子署名ファイルを手に入れるまでの、動作を説明する。電子ファイルの所有者は、電子ファイルを作成し、自分の秘密鍵で電子署名を付す。秘密鍵の読み込み方は、上述したとおりである。またこのとき、電子署名ファイルの文書ＩＤを会社サーバ６１から入手する。
【００８５】
その後電子ファイルの所有者は、電子署名ファイルが必要となったとき、自宅端末６３から電子署名ファイルを所望する。所有者は、予め知りうる文書ＩＤと会社サーバＵＲＬ情報に、自分の署名をした、電子署名付き電子文書要求手段を会社サーバ６１に送信する。会社サーバ６１では電子署名付き電子文書要求手段の正当性を確認し、検証が正しければ該当の電子文書に会社の署名をして、自宅端末６３に送信する。電子ファイルの所有者は、蓄積手段６８を用いて、送信された電子文書を蓄積する。
【００８６】
以上説明したように、本実施の形態によれば、第１のコンピュータに蓄積した電子文書を、安全に第２のコンピュータから入手することができる。
【００８７】
【発明の効果】
本発明は、以上説明したような構成を有するので、以下の効果を奏する。
【００８８】
検証者（受信者）が電子文書が存在していることを認知し、正当な電子文書を要求したとき、該当する電子文書を提供することができる。
【図面の簡単な説明】
【図１】実施の形態１における電子署名システムの構成を示した図である。
【図２】患者情報データベース１１の構成を示した図である。
【図３】処方データベース１８の構成を示した図である。
【図４】調剤データベース３０の構成を示した図である。
【図５】実施の形態１において、受付端末２にして診察券を発行する処理の流れを示したフローチャートである。
【図６】実施の形態１において、処方データ作成処理の流れを示したフローチャートである。
【図７】実施の形態１において、処方データ要求処理の流れを示したフローチャートである。
【図８】実施の形態１において、調剤記録を作成する処理の流れを示したフローチャートである。
【図９】実施の形態２における電子署名システムの構成を示した図である。
【図１０】電子データ保管ファイル５０の構成を示した図である。
【図１１】実施の形態２において、印鑑登録処理の流れを示したフローチャートである。
【図１２】実施の形態２において、「印鑑証明書」要求処理の流れを示したフローチャートである。
【図１３】実施の形態３における電子署名システムの構成を示した図である。
【符号の説明】
１，４１，６１  第１のコンピュータ（病院サーバ、自治体サーバ、会社サーバ）、５，４３，６３  第２のコンピュータ（調剤薬局端末、端末、自宅端末）、１５，４７  署名検証手段、１６  処方データ提供手段、１７  処方データ保管手段、２７  処方データ要求手段、４８  電子データ提供手段、４９  電子データ保管手段、５７  電子データ要求手段、６５  電子署名ファイル提供手段、６６  電子署名ファイル保管手段、６９  電子署名ファイル要求手段。
【図１】
2004289720.tif 000003
【図２】
2004289720.tif 000004
【図３】
2004289720.tif 000005
【図４】
2004289720.tif 000006
【図５】
2004289720.tif 000007
【図６】
2004289720.tif 000008
【図７】
2004289720.tif 000009
【図８】
2004289720.tif 000010
【図９】
2004289720.tif 000011
【図１０】
2004289720.tif 000012
【図１１】
2004289720.tif 000013
【図１２】
2004289720.tif 000014
【図１３】
2004289720.tif 000015