JP2018132931A - 承認システム、承認方法および承認プログラム - Google Patents

Abstract

【課題】承認情報の開示に伴う内部情報の漏洩リスクを低減させる。【解決手段】ストレージ装置１１は、１以上のユーザが属するグループに属していない他のユーザから参照可能なストレージ装置１２と同じ情報を記憶し、ストレージ装置１２との間で相互に情報の書き込みを反映させる。処理装置１３は、グループに対して取引の承認を依頼する依頼情報１４がストレージ装置１１に書き込まれたことが検出された場合に、グループに属するユーザのうちの承認担当者１５を識別するユーザ識別子であって取引に応じて異なるユーザ識別子１６を依頼情報１４と対応付けてストレージ装置１１に書き込ませる。処理装置１３は、承認担当者１５による承認が完了したことが検出された場合に、ユーザ識別子１６を含んでおり承認担当者１５の承認完了を示す承認ステータス情報１７を依頼情報１４と対応付けてストレージ装置１１に書き込ませる。【選択図】図１

Description

本発明は承認システム、承認方法および承認プログラムに関する。

現在、集中管理型のデータベースシステムに代えて、ネットワーク上に分散した複数のストレージ装置に同一の情報を重複して記憶しておく分散データベースシステムが利用されることがある。このような分散データベースシステムは、複数のストレージ装置が適宜同期して情報の同一性を維持する。このような分散データベースシステムは、集中管理型のデータベースシステムよりも耐故障性を向上させることが容易となる。これら複数のストレージ装置は、異なる組織によって保有されることもある。

分散して管理される情報の改竄防止や改竄検出を可能とし情報の信頼性を向上させる仕組みが、分散ストレージシステムに実装されることがある。例えば、いわゆるブロックチェーン（分散台帳）が分散ストレージシステムに実装されることがある。

ブロックチェーンでは、発生したトランザクションに関する情報が新たなブロックに格納され、既存のブロック列の末尾に新たなブロックが追加されていく。また、ブロックは全ての分散環境で共有される。ブロックチェーンにおける複数のブロックは、各ブロックの内容に応じたハッシュ値を介して連結している。あるブロックに含まれる情報または当該ブロックから参照される情報を改竄すると後続のブロックが有するハッシュ値に不整合が生じ、改竄を隠蔽するには後続の全てのブロックを再計算することになる。よって、ブロックチェーンによれば改竄検出が可能となり、改竄の隠蔽が困難となる。これにより、集中管理型のデータベースシステムを構築しなくても、複数の組織が信頼性の高い情報を共有することが可能となる。

なお、顧客から依頼された取引を受け付けて承認する過程の不正を防止する電話取引支援システムが提案されている。提案の電話取引支援システムは、受付担当者が入力した取引内容をデータベースに登録する。また、電話取引支援システムは、複数の承認端末の中から当該取引内容を承認する承認端末をランダムに選択し、選択した承認端末の識別情報を当該取引内容と対応付けてデータベースに登録する。

また、稟議決裁用の電子文書を複数の担当者に回覧する電子文書回覧システムが提案されている。提案の電子文書回覧システムは、所定の決裁ルールに基づいて回覧経路を決定する。電子文書回覧システムは、回覧経路に沿った回覧中に不在の担当者が存在する場合、不在の担当者をスキップして電子文書を回覧させ、回覧経路に沿った回覧が完了した後に当該スキップした担当者に対して電子文書を送信する。

また、預金口座からの不正な出金を防止する出入金システムが提案されている。提案の出入金システムは、出金を承認する承認者が複数設定されている場合、複数の承認者の中からランダムに１人の承認者を選択し、選択した承認者に出金を承認するか否かの問い合わせを送信する。出入金システムは、問い合わせから所定時間以内に回答を受信しない場合、ランダムに他の１人の承認者を選択し、選択した承認者に問い合わせを送信する。

特開２００３−３２３５５０号公報 特開２００４−２５２５０６号公報 特開２０１０−１４０４５６号公報

組織間で情報を共有する分散データベースシステムを利用して、取引を承認する承認ワークフローを管理することが考えられる。例えば、ある組織（依頼元組織）から他の組織（依頼先組織）に取引の承認を依頼し、依頼先組織が内部で承認手続を完了すると依頼先組織から依頼元組織に承認完了を通知するという承認ワークフローの進行状況を、分散データベースシステムに記録して共有することが考えられる。

このような承認ワークフローの管理を行う場合、依頼先組織は、組織内部の承認ワークフローも分散データベースシステム上に開示したい場合がある。例えば、依頼先組織は、組織内の承認手続が著しく遅延しないための業務体制を構築していることを表現するために、依頼に対する今後の承認手続の予定を組織外に対して開示したいことがある。また、例えば、依頼先組織は、組織内の承認手続が着実に進行していることを表現するため、組織内の承認ワークフローの進行状況を組織外に対して開示したいことがある。

組織内の承認ワークフローを開示するにあたっては、情報の信頼性を確保することや承認ワークフローの進行をシステム上で表現することなどの目的のため、依頼を処理する予定の承認担当者の識別子を分散データベースシステムに記録することがある。しかし、組織内のユーザに対して１対１に対応付けた固定のユーザ識別子をそのまま分散データベースシステムに記録してしまうと、多数の取引の承認情報を分析することで組織の内部情報が推測されてしまうというリスクがある。例えば、組織内に存在する承認担当者の人数、取引の種類と承認担当者の間の関係、人事異動による承認担当者の変更など、本来は秘匿しておきたい組織構造に関する内部情報が漏洩するリスクがある。

１つの側面では、本発明は、承認情報の開示に伴う内部情報の漏洩リスクを低減させる承認システム、承認方法および承認プログラムを提供することを目的とする。

１つの態様では、ストレージ装置と処理装置とを有する承認システムが提供される。ストレージ装置は、１以上のユーザが属するグループに属していない他のユーザから参照可能な他のストレージ装置と同じ情報を記憶し、他のストレージ装置との間で相互に情報の書き込みを反映させる。処理装置は、グループに対して取引の承認を依頼する依頼情報がストレージ装置に書き込まれたことが検出された場合に、グループに属する１以上のユーザのうちの承認担当者を識別するユーザ識別子であって取引に応じて異なるユーザ識別子を依頼情報と対応付けてストレージ装置に書き込ませ、承認担当者による承認が完了したことが検出された場合に、ユーザ識別子を含んでおり承認担当者の承認完了を示す承認ステータス情報を依頼情報と対応付けてストレージ装置に書き込ませる。

また、１つの態様では、情報処理システムが実行する承認方法が提供される。また、１つの態様では、コンピュータに実行させる承認プログラムが提供される。

１つの側面では、承認情報の開示に伴う内部情報の漏洩リスクを低減できる。

第１の実施の形態の承認システムの例を示す図である。 第２の実施の形態の承認システムの例を示す図である。 ブロックチェーンの例を示す図である。 キーバリューストアの例を示す図である。 識別子テーブルの例を示す図である。 ローカルのキーバリューストアの例を示す図である。 サーバのハードウェア例を示すブロック図である。 第２の実施の形態のサーバの機能例を示すブロック図である。 承認フロー管理の手順例を示すフローチャートである。 承認フロー管理の手順例を示すフローチャート（続き）である。 ブロックチェーン処理の手順例を示すフローチャートである。 第３の実施の形態の承認システムの例を示す図である。 第３の実施の形態のサーバの機能例を示すブロック図である。 設定情報テーブルの例を示す図である。 承認フロー管理の他の手順例を示すフローチャートである。 承認フロー管理の他の手順例を示すフローチャート（続き）である。

以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
第１の実施の形態を説明する。

図１は、第１の実施の形態の承認システムの例を示す図である。
第１の実施の形態の承認システム１０は、取引承認手続を管理する情報処理システムである。承認システム１０は、ストレージ装置１１および処理装置１３を含む。ストレージ装置１１および処理装置１３は、１以上のユーザが属する所定のグループ（依頼先グループ）によって使用されている。依頼先グループは、例えば、企業などの組織である。ストレージ装置１１および処理装置１３は、依頼先グループによって所有されていてもよい。ストレージ装置１１は、ネットワークを介してストレージ装置１２と通信することができる。ストレージ装置１２は、依頼先グループに属していない他のユーザから参照可能なストレージ装置である。ストレージ装置１２は、１以上の他のユーザが属する他のグループ（依頼元グループ）によって使用されていてもよく、依頼元グループによって所有されていてもよい。依頼元グループは、例えば、企業などの組織である。

ストレージ装置１１は、記憶装置を有するサーバ装置である。記憶装置は、例えば、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性の記憶装置である。ストレージ装置１１は、ＣＰＵ（Central Processing Unit）などのプロセッサとＲＡＭ（Random Access Memory）などのメモリとを有するサーバコンピュータでもよい。ストレージ装置１１は、ストレージ装置１２と同じ情報を記憶し、ストレージ装置１２との間で相互に情報の書き込みを反映させる。すなわち、ストレージ装置１１は、ネットワークを介してストレージ装置１２と同期している。ストレージ装置１１に新たな情報が書き込まれると当該情報がストレージ装置１２に複製され、逆にストレージ装置１２に新たな情報が書き込まれると当該情報がストレージ装置１１に複製されることになる。

処理装置１３は、ストレージ装置１１を利用してグループに属さない他のユーザと情報のやり取りを行うサーバ装置またはクライアント装置である。処理装置１３は、ＣＰＵなどのプロセッサとＲＡＭなどのメモリとを有するサーバコンピュータまたはクライアントコンピュータでもよい。その場合、例えば、処理装置１３のメモリは後述する処理を記載した承認プログラムを記憶し、処理装置１３のプロセッサは承認プログラムを実行する。なお、ストレージ装置１１や処理装置１３は、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などの特定用途の電子回路を有していてもよい。また、複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。

処理装置１３は、グループに対して取引の承認を依頼することを示す依頼情報１４がストレージ装置１１に書き込まれたことを検出する。依頼情報１４は、例えば、ストレージ装置１２に書き込まれてストレージ装置１１に複製されたものである。すると、処理装置１３は、グループに属するユーザの中から取引を承認する予定の承認担当者１５を選択し、承認担当者１５を識別するユーザ識別子１６を依頼情報１４と対応付けてストレージ装置１１に書き込む。ここで書き込まれるユーザ識別子１６は、グループ内の今後の承認手続の予定を示す承認ワークフロー情報として解釈することもできる。ストレージ装置１１に書き込まれたユーザ識別子１６は、ストレージ装置１２に複製される。よって、グループに属さない他のユーザから、依頼情報１４に対するグループ内の今後の承認手続の予定を確認することができる。

ここで、ストレージ装置１１に書き込まれるユーザ識別子１６は、承認担当者１５と１対１に対応する固定ユーザ識別子ではなく、承認依頼に応じて異なる一時的ないし仮想的と言えるユーザ識別子である。例えば、処理装置１３は、依頼情報１４を検出すると承認担当者１５にユーザ識別子１６を新規に割り当て、依頼情報１４と関連付けられる情報については承認担当者１５を表すためにユーザ識別子１６を使用する。よって、別の依頼情報に対して同じ承認担当者１５が選択された場合であっても、その際にストレージ装置１１に書き込まれるユーザ識別子はユーザ識別子１６と異なる可能性がある。

このとき、処理装置１３は、ユーザ識別子１６をランダムに選択してもよい。その場合、処理装置１３は、依頼情報１４を識別する取引識別子および承認担当者１５の組に対して、ユーザ識別子１６を割り当てたことを示す対応情報を保持しておいてもよい。対応情報を参照することで、グループ内ではユーザ識別子１６が示す実際の承認担当者１５を特定でき、グループ内からストレージ装置１１の情報を活用することができる。対応情報は、グループ内のユーザが使用する内部ストレージ装置（例えば、グループによって所有される内部ストレージ装置）に保存されてもよい。また、処理装置１３は、依頼情報１４を識別する取引識別子を用いてユーザ識別子１６を生成してもよい。すなわち、ユーザ識別子１６が依頼情報１４に依存して変化するようにしてもよい。例えば、処理装置１３は、取引識別子を用いて暗号鍵を生成し、承認担当者１５の固定ユーザ識別子を当該暗号鍵で暗号化してユーザ識別子１６を生成する。この場合、ユーザ識別子１６と依頼情報１４の取引識別子から承認担当者１５の固定ユーザ識別子を復元できる。

また、処理装置１３は、承認担当者１５による承認が完了したことを検出する。例えば、処理装置１３は、承認担当者１５が使用する端末装置から承認完了のメッセージを受信する。すると、処理装置１３は、ユーザ識別子１６を含んでおり承認担当者１５の承認完了を示す承認ステータス情報１７を生成する。すなわち、承認担当者１５の承認が完了したことが、ユーザ識別子１６を用いて表現される。承認ステータス情報１７は、承認担当者１５の固定ユーザ識別子を含まなくてよい。承認ステータス情報１７に含まれるユーザ識別子１６は、先にストレージ装置１１に書き込まれたものと同じである。例えば、処理装置１３は、保存しておいた対応情報を参照して、取引を承認した承認担当者１５に割り当てたユーザ識別子１６を特定し、承認ステータス情報１７を生成する。

処理装置１３は、生成した承認ステータス情報１７を依頼情報１４と対応付けてストレージ装置１１に書き込む。ここで書き込まれる承認ステータス情報１７は、グループ内の承認ワークフローの進行状況として解釈することができる。ストレージ装置１１に書き込まれた承認ステータス情報１７は、ストレージ装置１２に複製される。よって、グループに属さない他のユーザから、依頼情報１４に対する承認手続が進行したことを確認することができる。

ただし、ユーザ識別子１６は、依頼情報１４に関連付けられた情報の中でのみ承認担当者の同一性を表したものであり、他の依頼情報に関連付けられた情報との間では承認担当者の同一性を表していない。よって、グループに属さない他のユーザからは、取引承認依頼毎の承認体制や承認ワークフローの進行状況を確認することができるものの、複数の取引承認依頼と承認担当者との関係は把握されない。すなわち、承認担当者１５がどの程度の数の取引を承認したかや、承認担当者１５がどの様な種類の取引を承認したかなどは、開示されるユーザ識別子が取引によって変わるため特定されない。このため、グループ内に存在する承認担当者の人数、取引の種類と承認担当者の間の関係、人事異動による承認担当者の変更など、グループ構造に関する内部情報が漏洩するリスクを低減できる。

［第２の実施の形態］
次に、第２の実施の形態を説明する。
図２は、第２の実施の形態の承認システムの例を示す図である。

第２の実施の形態の承認システムは、複数の組織に跨がって行われる取引の承認状況を管理する情報処理システムである。この承認システムは、例えば、投資機関や証券会社などの取引参加者の間で行われる株式取引の決済状況を管理するために用いることができる。この承認システムは、承認手続のワークフロー（以下では「承認フロー」と言うことがある）の進行状況を示す承認情報を、耐改竄性や耐故障性を向上させるため、複数の組織が共有するブロックチェーン（分散台帳）を利用して管理する。

第２の実施の形態の承認システムは、端末装置５１〜５４、承認管理サーバ１００，１００ａ、ブロックチェーンサーバ２００，２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅおよびローカルブロックチェーンサーバ３００を含む。

端末装置５１〜５３、承認管理サーバ１００、ブロックチェーンサーバ２００およびローカルブロックチェーンサーバ３００は、組織３１（組織Ｄ）が保持しており、組織３１のローカルネットワークであるネットワーク４２に接続されている。ネットワーク４２は、広域ネットワークであるネットワーク４１に接続されている。端末装置５４、承認管理サーバ１００ａおよびブロックチェーンサーバ２００ａは、組織３２（組織Ａ）が保持しており、組織３２のローカルネットワークであるネットワーク４３に接続されている。ネットワーク４３はネットワーク４１に接続されている。

ブロックチェーンサーバ２００ｂは、組織Ｂが保持している。ブロックチェーンサーバ２００ｃは、組織Ｃが保持している。ブロックチェーンサーバ２００ｄは、組織Ｅが保持している。ブロックチェーンサーバ２００ｅは、組織Ｆが保持している。ブロックチェーンサーバ２００ｂ，２００ｃ，２００ｄ，２００ｅは、ネットワーク４１を介して他のブロックチェーンサーバと通信することができる。

端末装置５１〜５３は、組織３１に属するユーザが使用するクライアントコンピュータである。端末装置５１〜５３のユーザは、ある取引を承認する担当者に指定されることがある。担当者に指定されたユーザは、何れかの端末装置を操作することで、当該端末装置から承認管理サーバ１００にアクセスして承認フローを実行させることができる。

組織３１が他の組織から取引の承認を依頼された場合、組織３１の内部では組織３１が独自に決めた承認ルールに従って承認フローが実行される。承認ルールは、特定のユーザが不在であることによって承認フローが遅延しないように、複数の担当者を指定して当該複数の担当者の一部（例えば、１人）が承認すればよいことを規定している場合がある。また、承認ルールは、権限の異なる２以上の担当者（例えば、一次担当者とその上司）の全てが承認することを要求している場合がある。第２の実施の形態では主に、１つの取引につき３人の担当者を指定し、当該３人の担当者のうち何れか１人が承認すれば組織３１として承認したことになる承認ルール（１ｏｆ３ルール）を想定する。

端末装置５４は、組織３２に属するユーザが使用するクライアントコンピュータである。端末装置５４は、端末装置５１〜５３と同様の機能を有する。第２の実施の形態では主に、組織３２（組織Ａ）が組織３１（組織Ｄ）に対して取引の承認を依頼することを想定する。端末装置５４のユーザは、端末装置５４を操作することで、端末装置５４から承認管理サーバ１００ａにアクセスして承認依頼を発行させることができる。

承認管理サーバ１００は、承認依頼の発行や承認フローの実行を管理するサーバコンピュータである。承認管理サーバ１００は、端末装置５１〜５３からの要求に応じて、他の組織への承認依頼の情報を生成する。承認管理サーバ１００は、生成した承認依頼の情報をブロックチェーンサーバ２００に送信し、承認依頼をブロックチェーンに反映させる。

また、承認管理サーバ１００は、ブロックチェーンサーバ２００が保持するブロックチェーンを監視し、組織３１に対する承認依頼を検出する。すると、承認管理サーバ１００は、組織３１の内部における承認フローを決定する。承認管理サーバ１００は、承認フローの情報（承認予定の担当者を示す情報など）をブロックチェーンサーバ２００に送信し、その承認フローをブロックチェーンに反映させる。その後、承認管理サーバ１００は、端末装置５１〜５３を用いた承認操作に応じて、承認ステータスの情報（組織３１が承認を完了したか否かや内部の承認フローがどの段階まで進行したかなどを示す情報）を更新する。承認管理サーバ１００は、更新した承認ステータスの情報をブロックチェーンサーバ２００に送信し、最新の承認ステータスをブロックチェーンに反映させる。

このとき、承認管理サーバ１００は、他の組織に対して公開しない情報を保存するためにローカルブロックチェーンサーバ３００を利用することがある。同様に、承認管理サーバ１００ａは、承認依頼の発行や承認フローの実行を管理するサーバコンピュータである。承認管理サーバ１００ａは、端末装置５４からの要求に応じてブロックチェーンサーバ２００ａと通信し、承認依頼をブロックチェーンに反映させる。また、承認管理サーバ１００ａは、他の組織からの承認依頼に応じて組織３２の内部における承認フローを決定し、ブロックチェーンサーバ２００ａと通信して承認フローや最新の承認ステータスをブロックチェーンに反映させる。なお、組織Ｂ，Ｃ，Ｅ，Ｆが、承認管理サーバ１００，１００ａと同様の承認管理サーバ（図示せず）を有していてもよい。

ブロックチェーンサーバ２００は、ブロックチェーンを管理するサーバコンピュータである。ブロックチェーンサーバ２００は、実体的データを保存するデータベースであるキーバリューストア（ＫＶＳ）と、キーバリューストアの更新の履歴を示すブロックチェーンとを保存する。ブロックチェーンは、キーバリューストアに保存されたデータが正当であり改竄されていないことを保証するために用いられる。キーバリューストアは、キーとバリューを対応付けて記憶する。第２の実施の形態では、キーとして取引を識別する案件ＩＤを使用し、バリューとして当該取引に関する承認情報を保持する。

ブロックチェーンサーバ２００には、キーバリューストアの参照や更新を行う１以上の関数が組み込まれている。ブロックチェーンサーバ２００は、承認管理サーバ１００からの要求に応じて関数を実行する。関数の実行によりキーバリューストアが更新されると、ブロックチェーンサーバ２００は、更新履歴を示すトランザクション情報を生成する。ブロックチェーンサーバ２００は、生成したトランザクション情報を自身で保持すると共に、他の全てのブロックチェーンサーバ（ブロックチェーンサーバ２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅ）に対してブロードキャストする。

また、ブロックチェーンサーバ２００は、他のブロックチェーンサーバからトランザクション情報を受信すると、受信したトランザクション情報に従って関数を再実行してキーバリューストアを更新する。これにより、そのトランザクション情報の送信元で行われた更新が、ブロックチェーンサーバ２００のキーバリューストアに反映される。また、ブロックチェーンサーバ２００は、一定時間毎に当該一定時間内に発生したトランザクション情報を含むブロックを生成し、生成したブロックをブロックチェーンの末尾に追加する。一定時間内に発生したトランザクション情報には、ブロックチェーンサーバ２００が生成したものと他のブロックチェーンサーバから受信したものとが含まれる。

同様に、ブロックチェーンサーバ２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅは、ブロックチェーンを管理するサーバコンピュータである。ブロックチェーンサーバ２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅは、ブロックチェーンサーバ２００と同じキーバリューストアおよびブロックチェーンを保持する。すなわち、ブロックチェーンサーバ２００，２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅの間では、キーバリューストアおよびブロックチェーンが複製されて同期されている。これにより、組織Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆは共通の承認情報を閲覧でき、取引の透明性や客観性を確保できる。また、承認情報が冗長化されて保存されており、耐故障性が向上する。

ローカルブロックチェーンサーバ３００は、組織３１の内部で使用され組織３１の外部には開示されないブロックチェーンを管理するサーバコンピュータである。ローカルブロックチェーンサーバ３００は、キーバリューストアとブロックチェーンとを保存する。ブロックチェーンサーバ２００，２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅと同様、ローカルブロックチェーンサーバ３００には、キーバリューストアの参照や更新を行う１以上の関数が組み込まれている。ローカルブロックチェーンサーバ３００は、承認管理サーバ１００からの要求に応じて関数を実行する。関数の実行によりキーバリューストアが更新されると、ローカルブロックチェーンサーバ３００は、更新履歴を示すトランザクション情報を生成する。

ローカルブロックチェーンサーバ３００は、一定時間毎に当該一定時間内に発生したトランザクション情報を含むブロックを生成し、生成したブロックをブロックチェーンの末尾に追加する。ローカルブロックチェーンサーバ３００のキーバリューストアやブロックチェーンは、ブロックチェーンサーバ２００，２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅのキーバリューストアやブロックチェーンとは同期していない。なお、組織３１は複数のローカルブロックチェーンサーバを有してもよい。その場合、ブロックチェーンサーバ２００，２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅと同様、それら複数のローカルブロックチェーンサーバの間でキーバリューストアやブロックチェーンが同期される。

図３は、ブロックチェーンの例を示す図である。
ブロックチェーンサーバ２００，２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅに保存されるブロックチェーンは、例えば、ブロック６１〜６３を含む。ブロック６１はブロック６２の一定時間前に生成されたブロックであり、ブロック６３はブロック６２の一定時間後に生成されたブロックである。ブロック６２は、前ブロックハッシュ値７１およびトランザクション情報７２，７３，７４を含む。他のブロックも、ブロック６２と同様に、前ブロックハッシュ値およびトランザクション情報を含む。

前ブロックハッシュ値７１は、直前のブロックであるブロック６１全体から所定のハッシュ関数を用いて算出されるハッシュ値である。同様に、ブロック６３は、直前のブロックであるブロック６２全体から算出される前ブロックハッシュ値を含んでいる。このように、複数のブロックが前ブロックハッシュ値を通じて連結している。

ここで、仮にブロック６１の内容が変化したとすると、ブロック６２に含まれるべき前ブロックハッシュ値７１が変化する。すると、連鎖的にブロック６３に含まれるべき前ブロックハッシュ値も変化する。このように、ブロックチェーンの中の１つのブロックの内容が事後的に変化すると、それ以降の全てのブロックの前ブロックハッシュ値を再計算しなければ、ブロック間で前ブロックハッシュ値が整合しなくなる。よって、ブロックチェーンの中の特定のブロックを改竄してその改竄を隠蔽するには膨大な計算を要することになり、ブロックの改竄が実質的に困難になる。このため、ブロックチェーンに含まれる前ブロックハッシュ値が正しいことを検証することで、改竄がないことを保証できる。

トランザクション情報７２は、案件ＩＤ７２ａ、関数ＩＤ７２ｂ、関数パラメータ７２ｃおよびＫＶＳハッシュ値７２ｄを含む。案件ＩＤ７２ａは、取引を識別する識別子であり、キーバリューストアのキーとして用いられる。トランザクション情報７２は、キーバリューストアの中の案件ＩＤ７２ａに対応する承認情報が更新されたことを示す。関数ＩＤ７２ｂは、承認情報の更新の際に呼び出された関数の識別子である。関数パラメータ７２ｃは、承認情報の更新の際に関数に対して渡された引数の値である。ＫＶＳハッシュ値７２ｄは、関数が実行された直後（キーバリューストアが更新された直後）におけるキーバリューストア全体から所定のハッシュ関数を用いて算出されるハッシュ値である。

トランザクション情報７２を生成したブロックチェーンサーバ以外の他のブロックチェーンサーバは、関数ＩＤ７２ｂによって特定される関数に対して関数パラメータ７２ｃを与えて実行することで、キーバリューストアを同期させることができる。このとき、他のブロックチェーンサーバは、更新後のキーバリューストアのハッシュ値とＫＶＳハッシュ値７２ｄとが一致していることを確認することで、更新が正しいことを保証できる。

トランザクション情報７３，７４も、トランザクション情報７２と同様に、案件ＩＤ、関数ＩＤ、関数パラメータおよびＫＶＳハッシュ値を含む。ブロック６２に含まれるトランザクション情報７２〜７４は、ブロック６１が生成された後、ブロック６２が生成されるまでの間に何れかのブロックチェーンサーバによって生成されたトランザクション情報である。各ブロックに含まれるトランザクション情報の件数は可変である。

図４は、キーバリューストアの例を示す図である。
キーバリューストア２２２は、ブロックチェーンサーバ２００に保存されている。キーバリューストア２２２は、案件ＩＤをキーとして含み、承認情報をバリューとして含む。ある取引についての承認情報には、当該取引に関与する複数の組織によってレコードが挿入されることがある。承認情報に挿入されるレコードには、組織間の承認手続に関するレコードだけでなく、組織内の承認手続に関するレコードも含まれる。組織間の承認手続に関するレコードは、ある組織が承認依頼を発行したことや、ある組織が承認を完了したことなどを示す。組織内の承認手続に関するレコードは、ある担当者の承認が未完了であることや、ある担当者の承認が完了したことなどを示す。

一例として、承認情報はレコード８１〜８４を含む。レコード８１は、案件ＩＤ＝１００１の取引について、組織３２（組織Ａ）から組織３１（組織Ｄ）に承認依頼を発行したことを示す。レコード８１は組織３２によって書き込まれる。

レコード８２は、案件ＩＤ＝１００１の取引を組織３１が承認するための組織３１内の承認フローを示す。レコード８２は、承認予定の担当者として、担当者アドレスＸＸＸＸ３２，ＸＸＸＸ０５，ＸＸＸＸ８４が付与された３人のユーザが選択されたことを示している。この３人の担当者の何れか１人が承認すれば、組織３１として案件ＩＤ＝１００１の取引を承認したことになる。このような組織３１の承認ルールがレコード８２に記載されてもよい。レコード８２は、レコード８１の後に組織３１によって書き込まれる。

レコード８３は、案件ＩＤ＝１００１の取引について組織３１内の承認ステータス、すなわち、レコード８２が示す承認フローの進行状況が更新されたことを示す。レコード８３は、レコード８２が示す３人の担当者のうち、担当者アドレスＸＸＸＸ３２が付与された担当者が案件ＩＤ＝１００１の取引を承認したことを示している。レコード８３は、レコード８２の後に組織３１によって書き込まれる。

レコード８４は、案件ＩＤ＝１００１の取引について組織３１の対外的な承認ステータスが更新されたこと、すなわち、レコード８１の承認依頼に対する組織３１から組織３２への回答を示す。組織３１では３人の担当者のうちの何れか１人が承認すればよいため、レコード８３が書き込まれた時点で案件ＩＤ＝１００１の取引は組織３１として承認されたことになる。レコード８４は、組織３１の承認が完了したことを示している。レコード８４は、レコード８３の後に組織３１によって書き込まれる。

レコード８１〜８４それぞれがキーバリューストア２２２に書き込まれる毎に、トランザクション情報が生成される。これらのトランザクション情報がブロックチェーンに挿入されることで、レコード８１〜８４が後から改竄されたとしても改竄が行われたことを検出することができ、改竄を隠蔽することが難しくなる。よって、承認が完了したことや承認が未完了であることについて信頼性の高い情報が提供される。

また、上記のように、承認情報には組織間の通信に関するレコードに加えて、組織内部の承認フローや承認ステータスを示すレコードも含まれる。各組織は、ブロックチェーンを利用して内部の承認フローや承認ステータスを他の組織に開示することで、承認が不当に遅延していないことや十分な遅延対策を行っていることを表明することができる。例えば、組織内部で承認フローが進行していることや、承認予定の担当者が複数指定されており一部の担当者が不在でも承認が遅延しない体制を確立していることを、他の組織に確認してもらうことができる。これにより、組織間の承認手続の透明性が確保される。また、承認手続が大きく遅延した場合にその原因を特定することが容易となる。よって、内部の承認フローや承認ステータスを開示することは、各組織にとって利点がある。

ここで、ブロックチェーンを利用して承認フローや承認ステータスを開示するにあたり、情報の信頼性や管理の利便性などのため、担当者を識別する担当者アドレスを開示することが好ましい。しかし、組織内のユーザに対して１対１に対応付けたユーザＩＤを担当者アドレスとして組織外に開示してしまうと、様々な取引の担当者アドレスを比較分析することで、組織構造に関する内部情報が漏洩してしまうおそれがある。例えば、組織内に存在する担当者の人数、取引の種類と承認を行う担当者の関係、承認フローに関与する上司と部下の間の指揮系統、担当者の人事異動などの内部情報が漏洩するおそれがある。

そこで、第２の実施の形態の承認システムは、組織外に開示する承認情報から組織構造に関する内部情報が漏洩するリスクを低減させる。このため、承認システムは、ユーザと開示される担当者アドレスとが１対１に対応しないようにし、ユーザに割り当てられる担当者アドレスが取引によって変わるようにする。

組織構造の分析を困難にするためには、ユーザと開示される担当者アドレスとが多対多の関係になればよい。すなわち、あるユーザが２つの取引の担当者として指定された場合に、一方の取引について当該ユーザに割り当てられる担当者アドレスと他方の取引について当該ユーザに割り当てられる担当者アドレスとが異なる可能性がある。また、あるユーザが１つの取引の担当者として指定され、別のユーザが別の取引の担当者として指定された場合に、この２つの取引について同じ担当者アドレスが使用される可能性がある。

図５は、識別子テーブルの例を示す図である。
第２の実施の形態では、承認管理サーバ１００は取引毎にランダムに担当者アドレスを選択する。承認管理サーバ１００は、識別子テーブル１２２を有する。識別子テーブル１２２は、キーバリューストアに書き込む担当者アドレスとして使用可能な識別子の集合を記憶する。例えば、識別子テーブル１２２は、ＸＸＸＸ０５，ＸＸＸＸ２１，ＸＸＸＸ２９，ＸＸＸＸ３２，ＸＸＸＸ４６，ＸＸＸＸ４９，ＸＸＸＸ８４，ＸＸＸＸ９３，…などの識別子を記憶する。承認管理サーバ１００は、識別子テーブル１２２に記憶された識別子の中から、選択した担当者毎にランダムに担当者アドレスとして使用する識別子を選択する。ただし、承認管理サーバ１００は、１つの取引についての承認フローの中では、複数の担当者の間で担当者アドレスが重複しないようにする。

例えば、承認管理サーバ１００は、案件ＩＤ＝１００１に対してユーザＡ、ユーザＢおよびユーザＣの３人を担当者として選択する。そして、承認管理サーバ１００は、識別子テーブル１２２の中から、ユーザＡに対してＸＸＸＸ３２を選択し、ユーザＢに対してＸＸＸＸ０５を選択し、ユーザＣに対してＸＸＸＸ８４を選択する。承認管理サーバ１００は、これら選択した識別子を担当者アドレスとして組織外に開示する。

このように、担当者アドレスとして使用する識別子をランダムに選択することで、ブロックチェーンで管理される承認情報を通じて内部情報が漏洩するリスクを低減できる。一方、ブロックチェーンで管理される承認情報には実際の担当者を特定するための情報が不足している。そのため、承認管理サーバ１００は、このままでは組織３１の内部の承認フローを管理するためにブロックチェーンを活用することが制限され、ブロックチェーンの利便性が低下する。そこで、承認管理サーバ１００は、ローカルブロックチェーンサーバ３００に、担当者と担当者アドレスの対応関係を案件ＩＤ毎に記録しておく。

ブロックチェーンサーバ２００に記憶された承認情報とローカルブロックチェーンサーバ３００に記憶された対応情報とを連携させることで、承認管理サーバ１００は、承認情報からユーザ固有の識別子を除去しつつ内部の承認フローを管理することができる。

図６は、ローカルのキーバリューストアの例を示す図である。
キーバリューストア３２２は、ローカルブロックチェーンサーバ３００に保存されている。キーバリューストア３２２は、案件ＩＤをキーとして含み、ユーザと担当者アドレスとして使用する識別子との対応関係を示す対応情報をバリューとして含む。対応情報は、組織３１の内部で使用するユーザ固有のユーザＩＤに対して、取引毎に一時的に選択されて組織３１の外部に開示される識別子を対応付けている。

前述のように、例えば、案件ＩＤ＝１００１に対してユーザＡ、ユーザＢおよびユーザＣが担当者として選択される。すると、キーバリューストア３２２には、ユーザＡに対してＸＸＸＸ３２を割り当て、ユーザＢに対してＸＸＸＸ０５を割り当て、ユーザＣに対してＸＸＸＸ８４を割り当てたことを示す対応情報が記録される。また、例えば、案件ＩＤ＝１００２に対してユーザＡ、ユーザＤおよびユーザＥが担当者として選択される。すると、キーバリューストア３２２には、ユーザＡに対してＸＸＸＸ４６を割り当て、ユーザＤに対してＸＸＸＸ３９を割り当て、ユーザＥに対してＸＸＸＸ４９を割り当てたことを示す対応情報が記録される。また、例えば、案件ＩＤ＝１００３に対してユーザＢ、ユーザＣおよびユーザＥが担当者として選択される。すると、キーバリューストア３２２には、ユーザＢに対してＸＸＸＸ２１を割り当て、ユーザＣに対してＸＸＸＸ９３を割り当て、ユーザＥに対してＸＸＸＸ２９を割り当てたことを示す対応情報が記録される。

このように、案件ＩＤ＝１００１についてはユーザＡにＸＸＸＸ３２が割り当てられる一方、案件ＩＤ＝１００２についてはユーザＡにＸＸＸＸ４６が割り当てられることがある。また、案件ＩＤ＝１００１についてはユーザＢにＸＸＸＸ０５が割り当てられる一方、案件ＩＤ＝１００３についてはユーザＢにＸＸＸＸ２１が割り当てられることがある。また、案件ＩＤ＝１００１についてはユーザＣにＸＸＸＸ８４が割り当てられる一方、案件ＩＤ＝１００３についてはユーザＣにＸＸＸＸ９３に割り当てられることがある。よって、担当者アドレスから担当者の同一性を判断することが困難となる。

次に、承認システムに含まれる各装置の構成について説明する。
図７は、サーバのハードウェア例を示すブロック図である。
承認管理サーバ１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６および通信インタフェース１０７を有する。上記ユニットはバスに接続される。端末装置５１〜５４、承認管理サーバ１００ａ、ブロックチェーンサーバ２００，２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅおよびローカルブロックチェーンサーバ３００も、承認管理サーバ１００と同様のハードウェアを用いて実装することができる。

ＣＰＵ１０１は、プログラムの命令を実行する演算回路を含むプロセッサである。ＣＰＵ１０１は、ＨＤＤ１０３に記憶されたプログラムやデータの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。なお、ＣＰＵ１０１は複数のプロセッサコアを備えてもよく、承認管理サーバ１００は複数のプロセッサを備えてもよく、以下の処理を複数のプロセッサまたはプロセッサコアを用いて並列に実行してもよい。また、複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。

ＲＡＭ１０２は、ＣＰＵ１０１が実行するプログラムやＣＰＵ１０１が演算に用いるデータを一時的に記憶する揮発性の半導体メモリである。なお、承認管理サーバ１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。

ＨＤＤ１０３は、ＯＳ（Operating System）やミドルウェアやアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。プログラムには承認プログラムが含まれる。なお、承認管理サーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。

画像信号処理部１０４は、ＣＰＵ１０１からの命令に従って、承認管理サーバ１００に接続されたディスプレイ１１１に画像を出力する。ディスプレイ１１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、プラズマディスプレイ、有機ＥＬ（ＯＥＬ：Organic Electro-Luminescence）ディスプレイなど、任意の種類のディスプレイを用いることができる。

入力信号処理部１０５は、承認管理サーバ１００に接続された入力デバイス１１２から入力信号を取得し、ＣＰＵ１０１に出力する。入力デバイス１１２としては、マウスやタッチパネルやタッチパッドやトラックボールなどのポインティングデバイス、キーボード、リモートコントローラ、ボタンスイッチなどを用いることができる。また、承認管理サーバ１００に複数の種類の入力デバイスが接続されていてもよい。

媒体リーダ１０６は、記録媒体１１３に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体１１３として、例えば、磁気ディスク、光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）、半導体メモリなどを使用できる。磁気ディスクには、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤが含まれる。光ディスクには、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）が含まれる。

媒体リーダ１０６は、例えば、記録媒体１１３から読み取ったプログラムやデータを、ＲＡＭ１０２やＨＤＤ１０３などの他の記録媒体にコピーする。読み取られたプログラムは、例えば、ＣＰＵ１０１によって実行される。なお、記録媒体１１３は可搬型記録媒体であってもよく、プログラムやデータの配布に用いられることがある。また、記録媒体１１３やＨＤＤ１０３を、コンピュータ読み取り可能な記録媒体と言うことがある。

通信インタフェース１０７は、ネットワーク４２に接続され、ネットワーク４２を介して他のノードと通信を行うインタフェースである。通信インタフェース１０７は、例えば、スイッチなどの通信装置とケーブルで接続される有線通信インタフェースである。ただし、基地局と無線リンクで接続される無線通信インタフェースでもよい。

図８は、第２の実施の形態のサーバの機能例を示すブロック図である。
承認管理サーバ１００は、識別子記憶部１２１、承認依頼発行部１３１、承認フロー生成部１３２および承認フロー実行部１３３を有する。識別子記憶部１２１は、例えば、ＲＡＭ１０２またはＨＤＤ１０３に確保した記憶領域を用いて実装される。承認依頼発行部１３１、承認フロー生成部１３２および承認フロー実行部１３３は、例えば、ＣＰＵ１０１が実行するプログラムモジュールを用いて実装される。

識別子記憶部１２１は、識別子テーブル１２２を記憶する。
承認依頼発行部１３１は、組織３１が他の組織に対して取引の承認を依頼する場合に、端末装置５１〜５３の何れかの端末装置から承認依頼の情報を受け付ける。受け付ける承認依頼の情報には、承認対象の取引を識別する案件ＩＤや依頼先の組織の識別情報が含まれる。すると、承認依頼発行部１３１は、案件ＩＤや依頼先の組織などを指定して、ブロックチェーンサーバ２００に組み込まれた関数を呼び出し、ブロックチェーンを通じて承認依頼を他の組織に対して開示させる。

承認フロー生成部１３２は、ブロックチェーンサーバ２００が保持するブロックチェーンを監視し、組織３１に対する承認依頼を検出する。すると、承認フロー生成部１３２は、承認依頼で指定された取引を承認する組織３１内の担当者および承認ルールを決定し、承認フローを生成する。担当者の数は予め決まっており、２人以上であることが好ましい。担当者は、取引の種類に関係なく固定でもよいし、取引の種類に応じて異なってもよいし、担当者の候補の中からランダムに選択されてもよい。承認フロー生成部１３２は、例えば、担当者の候補のユーザＩＤを保持している。承認ルールは、組織３１として承認完了となる条件であり、例えば、１ｏｆ３ルールなどである。承認ルールは、取引の種類に関係なく固定でもよいし、取引の種類に応じて異なってもよい。承認フロー生成部１３２は、例えば、予め組織３１が決定した承認ルールの情報を保持している。

ここで、承認フロー生成部１３２は、ある承認依頼に対して担当者を決定すると、その担当者それぞれに、識別子記憶部１２１に記憶された識別子テーブル１２２からランダムに識別子を選択して担当者アドレスとして割り当てる。承認フロー生成部１３２は、一時的に割り当てた担当者アドレスと担当者固有のユーザＩＤとを対応付けた対応情報を生成する。承認フロー生成部１３２は、案件ＩＤや対応情報を指定して、ローカルブロックチェーンサーバ３００に組み込まれた関数を呼び出し、対応情報を組織３１の外部に開示しない秘密情報として保持させる。また、承認フロー生成部１３２は、案件ＩＤや担当者アドレスを指定して、ブロックチェーンサーバ２００に組み込まれた関数を呼び出し、ブロックチェーンを通じて承認フローを他の組織に対して開示させる。開示される承認フローの情報には、担当者固有のユーザＩＤは含まれない。

承認フロー実行部１３３は、組織３１の内部において承認フローを実行する。承認フロー生成部１３２で決定された担当者が端末装置５１〜５３の何れかの端末装置を用いて承認管理サーバ１００にログインすると、取引に関する情報や承認を促すメッセージを当該端末装置に送信する。承認フロー実行部１３３は、当該端末装置から承認完了のメッセージを受け付けると、ローカルブロックチェーンサーバ３００に組み込まれた関数を呼び出して、取引の案件ＩＤと承認を行った担当者とに対応する担当者アドレスを取得する。承認フロー実行部１３３は、取得した担当者アドレスを含み担当者固有のユーザＩＤを含まないように、当該担当者の承認が完了したことを示す承認ステータスの情報を生成する。

承認フロー実行部１３３は、案件ＩＤや承認ステータスの情報を指定して、ブロックチェーンサーバ２００に組み込まれた関数を呼び出し、ブロックチェーンを通じて途中段階の承認ステータスを他の組織に対して開示させる。また、承認フロー実行部１３３は、当該担当者の承認によって所定の承認ルールが満たされたか判断する。承認ルールが１ｏｆ３ルールである場合、１人の担当者の承認によって承認ルールが満たされたことになる。承認ルールが満たされた場合、承認フロー実行部１３３は、組織３１の承認が完了したことを示す承認ステータスの情報を生成する。承認フロー実行部１３３は、案件ＩＤや承認ステータスの情報を指定して、ブロックチェーンサーバ２００に組み込まれた関数を呼び出し、ブロックチェーンを通じて承認完了を示す承認ステータスを他の組織に対して開示させる。

ブロックチェーンサーバ２００は、関数記憶部２２１、キーバリューストア２２２、ブロックチェーン記憶部２２３、関数実行部２３１、ブロック生成部２３２および同期部２３３を有する。関数記憶部２２１、キーバリューストア２２２およびブロックチェーン記憶部２２３は、例えば、ブロックチェーンサーバ２００が有するＲＡＭまたはＨＤＤに確保した記憶領域を用いて実装される。関数実行部２３１、ブロック生成部２３２および同期部２３３は、例えば、ＣＰＵが実行するプログラムモジュールを用いて実装される。

関数記憶部２２１は、ブロックチェーンサーバ２００に組み込まれた複数の関数の情報を記憶する。例えば、関数記憶部２２１は、関数を実装したプログラムを記憶する。
キーバリューストア２２２は、キーとバリューとを対応付けて記憶するデータベースである。キーとして案件ＩＤが記憶され、バリューとして承認情報が記憶される。

ブロックチェーン記憶部２２３は、図３のような複数のブロックを連結したブロックチェーンを記憶する。一定時間毎にブロックチェーンの末尾にブロックが追加されていく。キーバリューストア２２２に記憶された承認情報の正当性を検証できるように、ブロックチェーンに一旦追加されたブロックは原則として更新も削除もされない。ただし、明らかに古くなり不要になったブロックを、ブロックチェーンの先頭から削除してもよい。

関数実行部２３１は、承認管理サーバ１００からの要求に応じて、関数記憶部２２１に記憶された情報が示す複数の関数のうち指定された関数を実行する。関数の実行によってキーバリューストア２２２から情報が検索されて承認管理サーバ１００に送信されることがある。また、関数の実行によってキーバリューストア２２２が更新されることがある。例えば、関数実行部２３１は、承認管理サーバ１００からの要求に応じて、承認管理サーバ１００から指定された案件ＩＤに対応する承認情報に、承認依頼の情報、承認フローの情報、承認ステータスの情報などを挿入する。

キーバリューストア２２２を更新した場合、関数実行部２３１は、ブロックチェーンに挿入すべきトランザクション情報を生成する。トランザクション情報には、案件ＩＤ、実行した関数を識別する関数ＩＤ、関数に渡した引数を示す関数パラメータ、および、更新後のキーバリューストア２２２から算出されるＫＶＳハッシュ値が含まれる。関数実行部２３１は、生成したトランザクション情報をブロック生成部２３２に出力する。また、関数実行部２３１は、他のブロックチェーンサーバ（ブロックチェーンサーバ２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅ）とのブロックチェーンの同期のため、生成したトランザクション情報を同期部２３３に出力する。

また、関数実行部２３１は、他のブロックチェーンサーバが生成したトランザクション情報を同期部２３３から取得する。すると、関数実行部２３１は、取得したトランザクション情報に含まれる関数ＩＤおよび関数パラメータを用いて関数を再実行する。これにより、トランザクション情報の送信元のブロックチェーンサーバと同様にキーバリューストア２２２が更新される。このとき、関数実行部２３１は、更新後のキーバリューストア２２２から算出されるＫＶＳハッシュ値とトランザクション情報に含まれるＫＶＳハッシュ値とを比較して、関数が正しく再実行されたか確認してもよい。

ブロック生成部２３２は、ブロックチェーンサーバ２００で生成されたトランザクション情報を関数実行部２３１から取得する。また、ブロック生成部２３２は、他のブロックチェーンサーバで生成されたトランザクション情報を同期部２３３から取得する。ブロック生成部２３２は、一定時間毎に、直近の一定時間に取得したトランザクション情報を含むブロックを生成し、ブロックチェーン記憶部２２３に記憶されたブロックチェーンの末尾に追加する。このとき、ブロック生成部２３２は、直前のブロックから前ブロックハッシュ値を算出し、生成したブロックに挿入しておく。

同期部２３３は、ブロックチェーンサーバ２００のブロックチェーンと他のブロックチェーンサーバのブロックチェーンとを同期させる。同期部２３３は、ブロックチェーンサーバ２００で生成されたトランザクション情報を関数実行部２３１から取得すると、取得したトランザクション情報を他のブロックチェーンサーバに送信する。他のブロックチェーンサーバそれぞれのアドレスは、同期部２３３が予め知っている。また、同期部２３３は、他のブロックチェーンサーバからトランザクション情報を受信すると、受信したトランザクション情報を関数実行部２３１とブロック生成部２３２に出力する。

ローカルブロックチェーンサーバ３００は、関数記憶部３２１、キーバリューストア３２２、ブロックチェーン記憶部３２３、関数実行部３３１およびブロック生成部３３２を有する。関数記憶部３２１、キーバリューストア３２２およびブロックチェーン記憶部３２３は、例えば、ローカルブロックチェーンサーバ３００が有するＲＡＭまたはＨＤＤに確保した記憶領域を用いて実装される。関数実行部３３１およびブロック生成部３３２は、例えば、ＣＰＵが実行するプログラムモジュールを用いて実装される。

関数記憶部３２１は、ブロックチェーンサーバ２００の関数記憶部２２１と同様に、ローカルブロックチェーンサーバ３００に組み込まれた複数の関数の情報を記憶する。
キーバリューストア３２２は、ブロックチェーンサーバ２００のキーバリューストア２２２と同様に、キーとバリューとを対応付けて記憶するデータベースである。キーとして案件ＩＤが記憶され、バリューとして対応情報が記憶される。

ブロックチェーン記憶部３２３は、ブロックチェーンサーバ２００のブロックチェーン記憶部２２３と同様に、複数のブロックを連結したブロックチェーンを記憶する。一定時間毎にブロックチェーンの末尾にブロックが追加されていく。

関数実行部３３１は、承認管理サーバ１００からの要求に応じて、関数記憶部３２１に記憶された情報が示す複数の関数のうち指定された関数を実行する。関数の実行によってキーバリューストア３２２から情報が検索されて承認管理サーバ１００に送信されることがある。また、関数の実行によってキーバリューストア３２２が更新されることがある。例えば、関数実行部３３１は、承認管理サーバ１００からの要求に応じて、承認管理サーバ１００から指定された案件ＩＤに対応付けて担当者と識別子との対応関係を示す対応情報を記憶させる。キーバリューストア３２２を更新した場合、関数実行部３３１は、ブロックチェーンに挿入すべきトランザクション情報を生成する。関数実行部３３１は、生成したトランザクション情報をブロック生成部３３２に出力する。

ブロック生成部３３２は、トランザクション情報を関数実行部３３１から取得する。ブロック生成部３３２は、一定時間毎に、直近の一定時間に取得したトランザクション情報を含むブロックを生成し、ブロックチェーン記憶部３２３に記憶されたブロックチェーンの末尾に追加する。このとき、ブロック生成部３３２は、直前のブロックから前ブロックハッシュ値を算出し、生成したブロックに挿入しておく。

なお、第２の実施の形態では、取引毎の担当者と識別子との対応関係をローカルブロックチェーンを利用して記録しておくこととしたが、ローカルファイルや関係データベースなど他の種類の記憶方法を利用して記録しておいてもよい。

次に、承認システムの処理手順について説明する。
図９は、承認フロー管理の手順例を示すフローチャートである。
承認管理サーバ１００は、承認依頼毎に以下の処理を実行する。

（Ｓ１０）承認フロー生成部１３２は、ブロックチェーンサーバ２００にアクセスし、ブロックチェーンの末尾に新たなブロックが追加されたことを検出する。
（Ｓ１１）承認フロー生成部１３２は、ブロックチェーンサーバ２００にアクセスし、追加されたブロックに含まれるトランザクション情報が示す承認情報（更新された承認情報）を参照し、組織３１に対する新たな承認依頼が記録されているか判断する。組織３１に対する新たな承認依頼がある場合はステップＳ１２に処理が進み、組織３１に対する新たな承認依頼がない場合はステップＳ１０に処理が進む。

（Ｓ１２）承認フロー生成部１３２は、承認依頼があった取引を組織３１が承認するための承認ルールと担当者を決定する。承認ルールは、例えば、３人の担当者のうち何れか１人が承認すれば組織３１として承認したことになる１ｏｆ３ルールである。担当者は、予め用意された担当者の候補の中から承認ルールが要求する人数だけ選択される。担当者はランダムに選択されてもよいし、所定の規則に従って選択されてもよい。

（Ｓ１３）承認フロー生成部１３２は、識別子記憶部１２１に記憶された識別子テーブル１２２の中から、ステップＳ１２で決定した担当者の数だけ互いに異なる識別子をランダムに選択する。例えば、承認ルールが１ｏｆ３ルールである場合、承認フロー生成部１３２は、識別子テーブル１２２の中から３つの異なる識別子を選択する。承認フロー生成部１３２は、選択した識別子を担当者に割り当てる。

（Ｓ１４）承認フロー生成部１３２は、担当者固有のユーザＩＤとステップＳ１３で割り当てた取引依存の識別子との対応関係を示す対応情報を生成する。承認フロー生成部１３２は、取引の案件ＩＤと対応情報をローカルブロックチェーンサーバ３００に送信し、案件ＩＤと対応付けて対応情報をブロックチェーンを利用して記録させる。

（Ｓ１５）承認フロー生成部１３２は、ステップＳ１３で選択した識別子を担当者アドレスとして含み、担当者固有のユーザＩＤは含まない承認フロー情報を生成する。承認フロー生成部１３２は、取引の案件ＩＤと承認フロー情報をブロックチェーンサーバ２００に送信し、案件ＩＤに対応する承認情報の中に承認フロー情報を記録させる。

図１０は、承認フロー管理の手順例を示すフローチャート（続き）である。
（Ｓ１６）承認フロー実行部１３３は、担当者のログインを検出する。
（Ｓ１７）承認フロー実行部１３３は、ログインした担当者が未処理である承認フローが存在するか判断する。未処理の承認フローがある場合はステップＳ１８に処理が進み、未処理の承認フローがない場合はステップＳ１６に処理が進む。

（Ｓ１８）承認フロー実行部１３３は、未処理の承認フローについての取引情報を取得する。例えば、承認フロー実行部１３３は、ブロックチェーンサーバ２００にアクセスして取引の案件ＩＤに対応付けられた情報を取得する。承認フロー実行部１３３は、ステップＳ１６の担当者が使用する端末装置に取引情報を送信する。また、承認フロー実行部１３３は、取引の承認を促すメッセージを当該端末装置に送信する。

（Ｓ１９）承認フロー実行部１３３は、ステップＳ１６の担当者による承認操作を検出したか判断する。例えば、承認フロー実行部１３３は、ステップＳ１８の端末装置から承認完了のメッセージを受信したか判断する。承認操作を検出した場合はステップＳ２０に処理が進み、承認操作を検出しなかった場合はステップＳ１６に処理が進む。

（Ｓ２０）承認フロー実行部１３３は、担当者が承認した取引の案件ＩＤに対応する対応情報をローカルブロックチェーンサーバ３００から取得し、当該担当者に対して割り当てられた取引依存の識別子を対応情報から抽出する。

（Ｓ２１）承認フロー実行部１３３は、ステップＳ２０で取得した識別子を担当者アドレスとして用いて、ステップＳ１６の担当者の承認が完了したことを示す承認ステータス情報を生成する。この承認ステータス情報には、担当者固有のユーザＩＤは含まれない。承認フロー実行部１３３は、案件ＩＤと承認ステータス情報をブロックチェーンサーバ２００に送信し、案件ＩＤに対応する承認情報の中に承認ステータス情報を記録させる。

（Ｓ２２）承認フロー実行部１３３は、ステップＳ１６の担当者が取引を承認したことによって、当該取引について組織３１の承認ルールが満たされたか判断する。承認ルールが承認人数に関するルールである場合、承認フロー実行部１３３は、承認した担当者の数が承認ルールの要求する閾値に達したか判断する。例えば、承認ルールが１ｏｆ３ルールである場合、ステップＳ１６の担当者の承認が完了したことによって自動的に承認ルールが満たされたことになる。承認ルールが２ｏｆ３ルールである場合、当該取引について２人の担当者の承認が完了したか判断される。承認ルールが満たされた場合はステップＳ２３に処理が進み、承認ルールが満たされていない場合はステップＳ１６に処理が進む。

（Ｓ２３）承認フロー実行部１３３は、組織３１の承認が完了したことを示す承認ステータス情報を生成する。ステップＳ２１の承認ステータス情報は、個別の担当者の承認完了を示しており、組織３１内の承認フローの途中経過を示している。これに対し、ここで生成する承認ステータス情報は、承認依頼に対する組織３１の正式な回答を示している。承認フロー実行部１３３は、案件ＩＤと承認ステータス情報をブロックチェーンサーバ２００に送信し、案件ＩＤに対応する承認情報の中に承認ステータス情報を記録させる。

図１１は、ブロックチェーン処理の手順例を示すフローチャートである。
ブロックチェーンサーバ２００は、一定時間毎に以下の処理を実行する。
（Ｓ３０）関数実行部２３１は、承認管理サーバ１００から関数呼び出しを受け付けたか判断する。関数呼び出しを受け付けた場合はステップＳ３１に処理が進み、関数呼び出しを受け付けていない場合はステップＳ３５に処理が進む。

（Ｓ３１）関数実行部２３１は、ステップＳ３０で呼び出された関数がキーバリューストア２２２を更新する関数であるか判断する。キーバリューストア２２２を更新する関数である場合はステップＳ３２に処理が進み、キーバリューストア２２２を更新しない関数である場合はステップＳ３５に処理が進む。なお、キーバリューストアを更新しない関数が呼び出された場合、関数実行部２３１は、通常の手順に従って呼び出された関数を実行してキーバリューストア２２２の検索などを行う。

（Ｓ３２）関数実行部２３１は、キーバリューストア２２２を更新する前に、関数呼び出しを示すトランザクション情報を生成する。このとき、関数実行部２３１は、関数呼び出しにおいて指定された案件ＩＤ、呼び出された関数を識別する関数ＩＤおよび指定された関数パラメータを、トランザクション情報に挿入する。

（Ｓ３３）関数実行部２３１は、呼び出された関数を実行してキーバリューストア２２２を更新する。例えば、関数実行部２３１は、指定された関数のプログラムを関数記憶部２２１から読み出して実行する。関数呼び出しでは、案件ＩＤや記録する情報などを引数として受け付ける。例えば、関数実行部２３１は、案件ＩＤに対応付けてキーバリューストア２２２に記憶されている承認情報に、引数として取得した承認依頼情報、承認フロー情報または承認ステータス情報を挿入する。

（Ｓ３４）関数実行部２３１は、ステップＳ３３の関数実行直後のキーバリューストア２２２全体のハッシュ値を算出し、トランザクション情報に挿入する。ただし、トランザクション情報に挿入するハッシュ値を、関数実行直前のキーバリューストア２２２全体のハッシュ値とすることも考えられる。その場合、上記ステップＳ３２の時点で、キーバリューストア２２２全体のハッシュ値をトランザクション情報に挿入できる。

同期部２３３は、生成されたトランザクション情報を、組織３１の外部にある他のブロックチェーンサーバ（ブロックチェーンサーバ２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅ）に対してブロードキャストする。

（Ｓ３５）関数実行部２３１は、組織３１の外部にある他のブロックチェーンサーバからトランザクション情報を受信したか判断する。組織３１の外部からトランザクション情報を受信した場合はステップＳ３６に処理が進み、外部からトランザクション情報を受信していない場合はステップＳ３７に処理が進む。

（Ｓ３６）関数実行部２３１は、外部から受信したトランザクション情報に従って関数を実行してキーバリューストア２２２を更新する。例えば、関数実行部２３１は、トランザクション情報に含まれる関数ＩＤに対応するプログラムを関数記憶部２２１から読み出し、トランザクション情報に含まれる関数パラメータを与えて実行する。

（Ｓ３７）ブロック生成部２３２は、直前のブロックを生成してから所定時間が経過したか判断する。所定時間が経過した場合はステップＳ３８に処理が進み、所定時間が経過していない場合はステップＳ３０に処理が進む。

（Ｓ３８）ブロック生成部２３２は、直前のブロック以降に発生したトランザクション情報を収集する。収集するトランザクション情報には、ステップＳ３３で組織３１の内部で生成されたトランザクション情報と、ステップＳ３５で組織３１の外部から受信されたトランザクション情報とが含まれる。ブロック生成部２３２は、直前のブロックのハッシュ値を算出し、算出したハッシュ値と収集したトランザクション情報とを含むブロックを生成する。そして、ブロック生成部２３２は、生成したブロックをブロックチェーン記憶部２２３に記憶されたブロックチェーンの末尾に追加する。

第２の実施の形態の承認システムによれば、組織内の承認フローや現在の承認ステータスが、ブロックチェーンを利用して信頼性の高い情報として組織外に開示される。よって、各組織は、組織内の承認手続が着実に進行していることや承認手続が大きく遅延しないための対策を十分行っていることを他の組織に対して主張することが可能となる。また、組織間の承認手続が大きく遅延した場合にその原因を特定することが容易となる。また、開示される承認情報には、担当者アドレスとして取引毎にランダムに割り当てられる識別子が使用され、担当者固有のユーザＩＤは使用されない。よって、開示された承認情報から組織構造、業務処理体制、人事異動などの内部情報が漏洩する可能性を低減できる。

［第３の実施の形態］
次に、第３の実施の形態を説明する。第２の実施の形態と異なる事項を中心に説明し、第２の実施の形態と同様の事項については説明を省略することがある。

第３の実施の形態では、担当者アドレスの生成方法が第２の実施の形態と異なる。
図１２は、第３の実施の形態の承認システムの例を示す図である。
第３の実施の形態の承認システムは、第２の実施の形態と同様、端末装置５１〜５４、承認管理サーバ１００ａおよびブロックチェーンサーバ２００，２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅを含む。また、第３の実施の形態の承認システムは、承認管理サーバ４００および暗号処理サーバ５００を含む。承認管理サーバ４００および暗号処理サーバ５００は、組織３１が保持しており、組織３１のローカルネットワークであるネットワーク４２に接続されている。承認管理サーバ４００は、第２の実施の形態の承認管理サーバ１００に代えて設置される。第２の実施の形態と異なり、組織３１はローカルブロックチェーンサーバ３００を有さなくてもよい。

承認管理サーバ４００は、承認依頼の発行や承認フローの実行を管理するサーバコンピュータである。承認管理サーバ４００は、端末装置５１〜５３からの要求に応じて他の組織への承認依頼の情報を生成し、ブロックチェーンサーバ２００に送信する。また、承認管理サーバ４００は、組織３１に対する承認依頼に応じて組織３１の内部における承認フローを決定し、承認フロー情報をブロックチェーンサーバ２００に送信する。また、承認管理サーバ４００は、端末装置５１〜５３を用いた担当者の承認操作に応じて承認ステータス情報を生成し、ブロックチェーンサーバ２００に送信する。

このとき、承認管理サーバ４００は、第２の実施の形態の承認管理サーバ１００とは異なり、担当者アドレスを秘匿化しなくてよい。すなわち、承認管理サーバ４００は、担当者と１対１に対応付けられたユーザＩＤを担当者アドレスとして使用してよい。

暗号処理サーバ５００は、ブロックチェーンサーバ２００と承認管理サーバ４００との間で通信を中継するサーバコンピュータである。例えば、暗号処理サーバ５００は、アプリケーションレベルで通信を中継するゲートウェイ装置である。

暗号処理サーバ５００は、承認管理サーバ４００からブロックチェーンサーバ２００に送信される情報のうち所定の項目の情報を暗号化する。具体的には、暗号処理サーバ５００は、案件ＩＤに依存する暗号鍵を用いて担当者アドレスを暗号化する。これにより、担当者アドレスが自動的に秘匿化されて他の組織に開示される。また、暗号処理サーバ５００は、ブロックチェーンサーバ２００から承認管理サーバ４００に送信される情報のうち所定の項目の情報を復号する。具体的には、暗号処理サーバ５００は、案件ＩＤに依存する復号鍵を用いて、暗号化されている担当者アドレスを復号する。これにより、承認管理サーバ４００は担当者アドレスが秘匿化されていない情報を取得できる。

図１３は、第３の実施の形態のサーバの機能例を示すブロック図である。
承認管理サーバ４００は、承認依頼発行部４３１、承認フロー生成部４３２および承認フロー実行部４３３を有する。承認依頼発行部４３１、承認フロー生成部４３２および承認フロー実行部４３３は、例えば、ＣＰＵが実行するプログラムモジュールを用いて実装される。承認依頼発行部４３１、承認フロー生成部４３２および承認フロー実行部４３３は、第２の実施の形態の承認管理サーバ１００の承認依頼発行部１３１、承認フロー生成部１３２および承認フロー実行部１３３に対応する。

承認依頼発行部４３１は、組織３１が他の組織に対して取引の承認を依頼する場合に、依頼先の組織などを指定した承認依頼情報を生成し、暗号処理サーバ５００を介してブロックチェーンサーバ２００に承認依頼情報を送信する。

承認フロー生成部４３２は、ブロックチェーンサーバ２００が保持するブロックチェーンを暗号処理サーバ５００を介して監視し、組織３１に対する承認依頼を検出する。すると、承認フロー生成部４３２は、組織３１内の担当者および承認ルールを決定し、担当者アドレスを含む承認フロー情報を生成する。このとき、承認フロー生成部４３２は、承認フロー情報に含まれる担当者アドレスを秘匿化しなくてよく、担当者アドレスとして担当者固有のユーザＩＤを用いてよい。承認フロー生成部４３２は、暗号処理サーバ５００を介してブロックチェーンサーバ２００に承認フロー情報を送信する。

承認フロー実行部４３３は、組織３１の内部において承認フローを実行する。承認フロー生成部４３２で選択された何れかの担当者が取引を承認すると、承認フロー実行部４３３は、承認が完了した担当者の担当者アドレスを含む承認ステータス情報を生成する。このとき、承認フロー実行部４３３は、承認ステータス情報に含まれる担当者アドレスを秘匿化しなくてよく、担当者アドレスとして担当者固有のユーザＩＤを用いてよい。承認フロー実行部４３３は、暗号処理サーバ５００を介してブロックチェーンサーバ２００に当該承認ステータス情報を送信する。また、当該担当者の承認によって承認ルールが満たされた場合、承認フロー実行部４３３は、組織３１の承認が完了したことを示す承認ステータス情報を生成する。承認フロー実行部４３３は、暗号処理サーバ５００を介してブロックチェーンサーバ２００に当該承認ステータス情報を送信する。

暗号処理サーバ５００は、設定情報記憶部５２１、基本鍵記憶部５２２、暗号化部５３１および復号部５３２を有する。設定情報記憶部５２１および基本鍵記憶部５２２は、例えば、ＲＡＭまたはＨＤＤに確保した記憶領域を用いて実装される。暗号化部５３１および復号部５３２は、例えば、プログラムモジュールを用いて実装される。

設定情報記憶部５２１は、暗号処理サーバ５００が実行する暗号処理に関する設定情報を記憶する。設定情報には、転送する情報の中の暗号化する項目、暗号化の方法、転送する情報の中の復号する項目、復号の方法などが記載される。

基本鍵記憶部５２２は、暗号化に使用する暗号鍵および復号に使用する復号鍵を生成するための基本鍵を記憶する。例えば、暗号鍵および復号鍵は、それぞれ基本鍵に案件ＩＤを連結することで生成される。この場合、基本鍵は暗号鍵および復号鍵それぞれの一部分を構成することになる。暗号処理方式が共通鍵暗号方式である場合、暗号鍵と復号鍵は同一である。この場合、暗号鍵および復号鍵は同一の基本鍵から生成すればよい。一方、暗号処理方式が公開鍵暗号方式である場合、暗号鍵と復号鍵は異なる。この場合、暗号鍵および復号鍵は異なる基本鍵から生成することになる。

暗号化部５３１は、設定情報記憶部５２１に記憶された設定情報に従って特定の項目の平文を暗号化する。特に、暗号化部５３１は、承認管理サーバ４００からブロックチェーンサーバ２００に送信される承認フロー情報や承認ステータス情報を検出し、検出した情報に含まれる担当者アドレスを抽出する。暗号化部５３１は、基本鍵記憶部５２２に記憶された基本鍵と検出した情報に付加された案件ＩＤとを連結して暗号鍵を生成し、抽出した担当者アドレスを暗号化する。暗号化部５３１は、担当者アドレスが暗号化された承認フロー情報や承認ステータス情報をブロックチェーンサーバ２００に転送する。暗号鍵に案件ＩＤが含まれるため、暗号化された担当者アドレスは案件ＩＤに依存する。すなわち、元の担当者アドレスが同じでも取引によって暗号化後の担当者アドレスは変わる。

復号部５３２は、設定情報記憶部５２１に記憶された設定情報に従って特定の項目の暗号文を復号する。特に、復号部５３２は、ブロックチェーンサーバ２００から承認管理サーバ４００に送信される承認フロー情報や承認ステータス情報を検出し、検出した情報に含まれる担当者アドレスを抽出する。復号部５３２は、基本鍵記憶部５２２に記憶された基本鍵と検出した情報に付加された案件ＩＤとを連結して復号鍵を生成し、抽出した担当者アドレスを復号する。復号部５３２は、担当者アドレスが復号された承認フロー情報や承認ステータス情報を承認管理サーバ４００に転送する。

図１４は、設定情報テーブルの例を示す図である。
設定情報テーブル５２３は、設定情報記憶部５２１に記憶されている。設定情報テーブル５２３は、アクセス種別、対象項目、処理種別およびキー付加値を含む。

アクセス種別は、ブロックチェーンサーバ２００と承認管理サーバ４００の間の通信の種類である。アクセス種別には、承認管理サーバ４００がブロックチェーンサーバ２００に承認情報を登録する「承認情報登録」と、承認管理サーバ４００がブロックチェーンサーバ２００から承認情報を読み出す「承認情報参照」がある。対象項目は、暗号処理の対象とする情報項目である。対象項目としては「担当者アドレス」が想定される。処理種別は、暗号処理の種類であり、「暗号化」または「復号」である。キー付加値は、暗号処理に使用する鍵（暗号鍵または復号鍵）を生成するために基本鍵に付加する値である。暗号化された担当者アドレスが取引に依存する（取引によって自動的に担当者アドレスが変わる）ように、キー付加値としては「案件ＩＤ」が想定される。

図１５は、承認フロー管理の他の手順例を示すフローチャートである。
（Ｓ４０）承認フロー生成部４３２は、ブロックチェーンサーバ２００にアクセスし、ブロックチェーンの末尾に新たなブロックが追加されたことを検出する。

（Ｓ４１）承認フロー生成部４３２は、ブロックチェーンサーバ２００にアクセスし、追加されたブロックに含まれるトランザクション情報が示す承認情報（更新された承認情報）を参照し、組織３１に対する新たな承認依頼が記録されているか判断する。組織３１に対する新たな承認依頼がある場合はステップＳ４２に処理が進み、組織３１に対する新たな承認依頼がない場合はステップＳ４０に処理が進む。

（Ｓ４２）承認フロー生成部４３２は、承認依頼があった取引を組織３１が承認するための承認ルールと担当者を決定する。承認フロー生成部４３２は、決定した担当者に対応するユーザＩＤを担当者アドレスとして含む承認フロー情報を生成する。担当者アドレスとして使用するユーザＩＤは、担当者固有のユーザＩＤでよい。承認フロー生成部４３２は、取引の案件ＩＤと承認フロー情報を暗号処理サーバ５００に送信する。

（Ｓ４３）暗号化部５３１は、設定情報記憶部５２１に記憶された設定情報テーブル５２３に従い、承認管理サーバ４００から受信した承認フロー情報に含まれる担当者アドレスが暗号化対象であると判定する。すると、暗号化部５３１は、基本鍵記憶部５２２に記憶された基本鍵と承認フロー情報に付加された案件ＩＤとを連結して暗号鍵を生成する。例えば、暗号化部５３１は、基本鍵の後ろに案件ＩＤを連結する。暗号化部５３１は、生成した暗号鍵を用いて担当者アドレスを暗号化する。

（Ｓ４４）暗号化部５３１は、承認フロー情報に担当者アドレスとして含まれる平文を暗号文に置換し、担当者アドレスが暗号化された承認フロー情報をブロックチェーンサーバ２００に転送する。これにより、ブロックチェーンサーバ２００によって、案件ＩＤに対応する承認情報の中に承認フロー情報が記録される。

図１６は、承認フロー管理の他の手順例を示すフローチャート（続き）である。
（Ｓ４５）承認フロー実行部４３３は、担当者のログインを検出する。
（Ｓ４６）承認フロー実行部４３３は、ログインした担当者が未処理である承認フローが存在するか判断する。未処理の承認フローがある場合はステップＳ４７に処理が進み、未処理の承認フローがない場合はステップＳ４５に処理が進む。

（Ｓ４７）承認フロー実行部４３３は、未処理の承認フローについての取引情報を取得する。例えば、承認フロー実行部４３３は、ブロックチェーンサーバ２００にアクセスして取引の案件ＩＤに対応付けられた情報を取得する。承認フロー実行部４３３は、ステップＳ４５の担当者が使用する端末装置に取引情報を送信する。また、承認フロー実行部４３３は、取引の承認を促すメッセージを当該端末装置に送信する。

上記において、ブロックチェーンサーバ２００から取得する情報に担当者アドレスが含まれる場合、復号部５３２により、暗号化された担当者アドレスが復号される。すなわち、復号部５３２は、設定情報記憶部５２１に記憶された設定情報テーブル５２３に従い、ブロックチェーンサーバ２００から受信した承認情報に含まれる担当者アドレスが復号対象であると判定する。すると、復号部５３２は、基本鍵記憶部５２２に記憶された基本鍵と承認情報に付加された案件ＩＤとを連結して復号鍵を生成する。例えば、復号部５３２は、基本鍵の後ろに案件ＩＤを連結する。復号部５３２は、生成した復号鍵を用いて担当者アドレスを復号し、担当者アドレスが復号された承認情報を転送する。

（Ｓ４８）承認フロー実行部４３３は、ステップＳ４５の担当者による承認操作を検出したか判断する。承認操作を検出した場合はステップＳ４９に処理が進み、承認操作を検出しなかった場合はステップＳ４５に処理が進む。

（Ｓ４９）承認フロー実行部４３３は、承認が完了した担当者に対応するユーザＩＤを担当者アドレスとして含む承認ステータス情報を生成する。担当者アドレスとして使用するユーザＩＤは、担当者固有のユーザＩＤでよい。承認フロー実行部４３３は、取引の案件ＩＤと承認ステータス情報を暗号処理サーバ５００に送信する。

暗号化部５３１は、設定情報記憶部５２１に記憶された設定情報テーブル５２３に従い、承認管理サーバ４００から受信した承認ステータス情報に含まれる担当者アドレスが暗号化対象であると判定する。すると、暗号化部５３１は、基本鍵記憶部５２２に記憶された基本鍵と承認ステータス情報に付加された案件ＩＤとを連結して暗号鍵を生成する。暗号化部５３１は、生成した暗号鍵を用いて担当者アドレスを暗号化する。

（Ｓ５０）暗号化部５３１は、承認ステータス情報に担当者アドレスとして含まれる平文を暗号文に置換し、担当者アドレスが暗号化された承認ステータス情報をブロックチェーンサーバ２００に転送する。これにより、ブロックチェーンサーバ２００によって、案件ＩＤに対応する承認情報の中に承認ステータス情報が記録される。

（Ｓ５１）承認フロー実行部４３３は、ステップＳ４５の担当者の承認によって組織３１の承認ルールが満たされたか判断する。承認ルールが満たされた場合はステップＳ５２に処理が進み、承認ルールが満たされていない場合はステップＳ４５に処理が進む。

（Ｓ５２）承認フロー実行部４３３は、組織３１の承認が完了したことを示す承認ステータス情報を生成する。承認フロー実行部４３３は、案件ＩＤと承認ステータス情報を暗号処理サーバ５００に送信する。暗号化部５３１は、設定情報記憶部５２１に記憶された設定情報テーブル５２３に従い、承認管理サーバ４００から受信した承認ステータス情報に暗号化対象が含まれていないと判定し、受信した承認ステータス情報をブロックチェーンサーバ２００に転送する。これにより、ブロックチェーンサーバ２００によって、案件ＩＤに対応する承認情報の中に当該承認ステータス情報が記録される。

第３の実施の形態の承認システムによれば、第２の実施の形態と同様の効果が得られる。更に、第３の実施の形態では、暗号処理サーバ５００によって自動的に担当者アドレスが秘匿化される。よって、承認管理サーバ４００に秘匿化機能を組み込まなくてよく、承認フローを管理する既存サーバを利用することが容易となる。

１０ 承認システム
１１，１２ ストレージ装置
１３ 処理装置
１４ 依頼情報
１５ 承認担当者
１６ ユーザ識別子
１７ 承認ステータス情報

Claims (6)

1. １以上のユーザが属するグループに属していない他のユーザから参照可能な他のストレージ装置と同じ情報を記憶し、前記他のストレージ装置との間で相互に情報の書き込みを反映させるストレージ装置と、
   前記グループに対して取引の承認を依頼する依頼情報が前記ストレージ装置に書き込まれたことが検出された場合に、前記グループに属する前記１以上のユーザのうちの承認担当者を識別するユーザ識別子であって前記取引に応じて異なるユーザ識別子を前記依頼情報と対応付けて前記ストレージ装置に書き込ませ、前記承認担当者による承認が完了したことが検出された場合に、前記ユーザ識別子を含んでおり前記承認担当者の承認完了を示す承認ステータス情報を前記依頼情報と対応付けて前記ストレージ装置に書き込ませる処理装置と、
   を有する承認システム。
2. 前記依頼情報は前記取引を識別する取引識別子を含み、
   前記処理装置は、前記依頼情報の書き込みが検出された場合に、前記承認担当者に前記ユーザ識別子を割り当て、前記グループに属する前記１以上のユーザによって使用される内部ストレージ装置に前記取引識別子と前記ユーザ識別子とを対応付けて書き込ませ、
   前記処理装置は、前記承認担当者の承認完了が検出された場合に、承認された前記取引の前記取引識別子に対応する前記ユーザ識別子を前記内部ストレージ装置から取得し、取得した前記ユーザ識別子を用いて前記承認ステータス情報を生成する、
   請求項１記載の承認システム。
3. 前記依頼情報は前記取引を識別する取引識別子を含み、
   前記処理装置は、前記取引識別子を用いて前記ユーザ識別子を生成する、
   請求項１記載の承認システム。
4. 前記承認担当者には前記取引に依存しない固定ユーザ識別子が割り当てられ、
   前記依頼情報は前記取引を識別する取引識別子を含み、
   前記処理装置は、前記依頼情報の書き込みが検出された場合に、前記取引識別子を用いて暗号鍵を生成し、前記暗号鍵を用いて前記承認担当者に割り当てられた前記固定ユーザ識別子を暗号化することで前記ユーザ識別子を生成する、
   請求項１記載の承認システム。
5. 情報処理システムが実行する承認方法であって、
   １以上のユーザが属するグループに属していない他のユーザから参照可能な他のストレージ装置と同じ情報を記憶し、前記他のストレージ装置との間で相互に情報の書き込みを反映させるストレージ装置に、前記グループに対して取引の承認を依頼する依頼情報が書き込まれたことを検出し、
   前記グループに属する前記１以上のユーザのうちの承認担当者を識別するユーザ識別子であって前記取引に応じて異なるユーザ識別子を前記依頼情報と対応付けて前記ストレージ装置に書き込み、
   前記承認担当者による承認が完了したことを検出し、
   前記ユーザ識別子を含んでおり前記承認担当者の承認完了を示す承認ステータス情報を前記依頼情報と対応付けて前記ストレージ装置に書き込む、
   承認方法。
6. コンピュータに、
   １以上のユーザが属するグループに属していない他のユーザから参照可能な他のストレージ装置と同じ情報を記憶し、前記他のストレージ装置との間で相互に情報の書き込みを反映させるストレージ装置に、前記グループに対して取引の承認を依頼する依頼情報が書き込まれたことが検出された場合に、前記グループに属する前記１以上のユーザのうちの承認担当者を識別するユーザ識別子であって前記取引に応じて異なるユーザ識別子を前記依頼情報と対応付けて前記ストレージ装置に書き込ませ、
   前記承認担当者による承認が完了したことが検出された場合に、前記ユーザ識別子を含んでおり前記承認担当者の承認完了を示す承認ステータス情報を前記依頼情報と対応付けて前記ストレージ装置に書き込ませる、
   処理を実行させる承認プログラム。

Images