JP2006343906A

JP2006343906A - 電子申請における交渉システム

Info

Publication number: JP2006343906A
Application number: JP2005167673A
Authority: JP
Inventors: Hitoshi Mizutani; 仁水谷; Kazumi Yoshida; 一省吉田; Hiroaki Nakai; 博章中井; Naoko Taniguchi; 尚子谷口
Original assignee: Hitachi Software Engineering Co Ltd; Hitachi Ltd
Current assignee: Hitachi Software Engineering Co Ltd; Hitachi Ltd
Priority date: 2005-06-08
Filing date: 2005-06-08
Publication date: 2006-12-21

Abstract

【課題】
電子文書を介して、対等な権限をもった複数の承認者が改竄を防止しながら交渉を行ない、署名を行なうための従来のシステムでは、複数の承認者が記載できる項目に対して、文書作成者以外の承認者が内容を承諾できない場合、文書の改竄を防止するために、文書が作成者に返却される。
【解決手段】
複数人に対等性を与えるため、複数人が記述権限をもっている共通項目は、署名の状態として本ロック、仮ロックの状態をもたせ、文書の更新権限を制御する。また、仮ロックの状態により、文書に不足している著名を確認できる。また、変更履歴を確認できるようにするため、内容を変更した際の記載内容を履歴として残す。
【選択図】図１

Description

本発明は電子文書を介して、対等な権限をもった複数の承認者が、改竄を防止しながら交渉を行ない、署名を行なうためのシステムに関するものである。

従来の技術では、複数人が記載できる項目に対して、文書作成者以外の承認者が内容を承諾できない場合、文書の改竄を防止するために、文書が作成者に返却されるようになっていた。本発明に関し、特開２００３−１６８０２４があるが、これは合意において特定の人のみで合意に達することができるものとなっている。

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

本発明は、文書作成者とそれ以外の承認者に対等な権限をもたせ、複数の承認者が文書に署名を行なうシステムを提供することを主な目的とする。その際、承認者が合意しない改竄を防ぐことを前提とする。また、本システムは文書内容の変更履歴を確認できることも特徴である。

複数の承認者に対等性を与えるため、複数の承認者が記述権限をもっている共通項目は、署名の状態として本ロック、仮ロックの状態をもつ。仮ロックの状態が残っている文書は合意がとれていないものである。全員の署名が揃った時点で契約書が合意され、本ロックされるものである。仮ロックの状態では、承認者のうち署名が有効でない者のみが文書を更新できるものであり、署名が有効である者は文書を参照することしかできない。また、仮ロックの状態においては、どの承認者の署名が不足しているかを判断できることも特徴である。本ロックの状態では、すべての承認者は文書を更新することはできず、参照することしかできないものである。

また、変更履歴を確認できるようにするため、内容を変更した際の記載内容を履歴として残すものである。

本発明により、複数人が対等な関係で文書の合意に持っていける利点がある。

また、文書内容に変更が発生した場合は、変更箇所の確認のみで対応できる利点がある。さらに、履歴を管理しているため、前回の記述内容との差分をとりながら文書の確認を行なえる利点がある。

以下、図面を参照して、本発明の実施の形態に係る電子申請における交渉システムにおいて、クライアントコンピュータが文書を編集し、サーバコンピュータにて文書の状態をチェックし、ロックの制御を行なう方法について説明する。

図１は、本発明の実施の形態に係る電子申請における交渉システムにおけるシステム構成を示す図である。本システムはサーバコンピュータ１１０、クライアントコンピュータ１２０、文書１３０から構成される。サーバコンピュータ１１０は、文書格納部１１１、文書送信部１１２、要求受信部１１３、文書受信部１１４、文書管理テーブル更新部１１５、文書管理テーブル１１６、文書テンプレート格納部１１７を具備する。クライアントコンピュータ１２０は、文書受信部１２１、文書編集部１２２、ログイン部１２３、文書送信部１２４、要求送信部１２５、署名部１２６を具備する。

図２は、本発明の実施の形態に係る文書１３０の形式を示す図である。この図では、２人が署名を行なう文書１３０の形式を例として示している。図２（a）は、ユーザが取り扱う文書の表示イメージを示している。ここで、項Ａは第一人者のみの承認が必要な記入欄の集まり、項目Ｂは第二人者のみの承認が必要な記入欄の集まり、項目Ｃは第一人者と第二人者の両方の承認が必要な記入欄の集まりを表わしている。

図２（ｂ）は図２（a）を物理的な表として格納する形式を表わしている。文書は「項目IＤ」、「項目名」、「承認者」、「内容」、「署名値」を保有している。「項目名」は、図２（a）のそれぞれの項目に対応し、最初から格納されている領域である。「内容」は、図２（a）のそれぞれの項目に記述された内容が格納される。

図２（c）は、処理中の文書１３０の状態を表わしている。「文書IＤ」の項目には、サーバコンピュータ１１０によって割り振られた、システムに固有な文書のIＤが格納される。「承認者」は、文書１３０を編集することができる承認者名を格納するリストである。すべての項目に対して同じリストが格納されている。「署名値」は承認者の数だけのリスト形式となっており、各承認者の署名値が格納される。（署名値は公知技術。参考URL: http://www.ipa.go.jp/security/pki/pki.pｄf 「２００２年３月１８日更新」）署名値が不要な領域には、”不要”という文字列が格納されており、この値により項目に対して不要な承認者を表わしている。各項目の「署名値」に、「内容」に対してすべて正しい値が格納されれば、文書は完了状態となる。

図２（ｄ）は、完了状態となった文書を表わしている。図２（c）では項目Ｃの１番目の署名値に「内容」とは異なるものが格納されているのに対し、図２（ｄ）は、すべての署名値の値が正しい値である。このことにより、文書が完了状態であることが判断できるものである。

図３は、サーバコンピュータ１１０の具備する文書管理テーブル１１６の形式を示す図である。図３（a）に示すように、文書管理テーブル１１６は「文書IＤ_S」、「文書_S」、「署名済み者_S」、「コメント_S」を保有している。「文書IＤ_S」は文書１３０の「文書IＤ」と同等なものであり、文書を特定するキーとなっている。「文書_S」は、文書１３０を格納する場所である。クライアントコンピュータ１２０から送付される文書が格納される。「署名済み者_S」は、文書１３０の署名が行なわれた承認者名を格納するリストである。「コメント_S」は、文書１３０がどのような状態となっているかを記述する場所である。「署名済み者_S」と「コメント_S」は、クライアントコンピュータ１２０から文書１３０が送付される度にサーバコンピュータ１１０によって更新される。

次に、図３（ｂ）と図３（c）を用いて、本ロックと仮ロックの状態について説明する。まず、図３（ｂ）は、処理中の文書管理テーブル１１６を表わす図である。「署名済み者_S」を参照すると、リストの２項目には値が格納されているが、１項目は空のデータとなっている。これは、第一人者である”鈴木”の署名がなされていない事を表わし、全ての承認者の署名がなされていないため、仮ロックの状態となっている。仮ロックの状態では、本システムの処理によって、承認者のうち署名がなされていない者によって文書を更新することができるものである。「コメント_S」では、”鈴木”の署名が失われ、”佐藤”の署名が加えられたことを表現している。

次に、図３（c）は文書の成立した際の文書管理テーブル１１６を表わす図である。「署名済み者_S」を参照すると、全ての項目に承認者の値が格納されている。これは、全ての承認者の署名が完了したことを表わし、本ロックの状態となっている。本ロックの状態では、本システムの処理によって、文書を更新することができなくなるものである。「コメント_S」では、既に文書が成立していることを表現している。

図４は、サーバコンピュータ１１０の具備する文書テンプレート格納部１１７の形式を示す図である。サーバコンピュータ１１０は、文書テンプレート格納部１１７に文書１３０の初期フォーマットとしてのテンプレートをあらかじめ持っている。図４に示すように、文書テンプレート格納部１１７は「文書テンプレートIＤ」、「説明」、「文書テンプレート」を保有している。「文書テンプレートIＤ」に対して、その概要を「説明」に記述し、文書１３０の初期フォーマットであるテンプレート自体は「文書テンプレート」に格納されている。

次に、本発明の実施の形態に係る電子申請および交渉システムについて、図５〜図１０のフローチャートを参照して説明する。

まず、図５を用いて、サーバコンピュータ１１０より文書１３０を受信し、文書を編集後、サーバコンピュータ１１０に文書１３０を送信するクライアントコンピュータ１２０の処理を説明する。クライアントコンピュータ１２０は、ログイン者の情報を認識し、ログインを行なう（５０１）。その後、新規文書を取得するか、既存文書を取得するかを選択する（５０２）。新規文書を取得する場合は、文書テンプレート格納部１１７より文書１３０を要求する（５０３）。この処理は図６の説明として後述する。既存文書を取得する場合は、「文書IＤ」を指定し、対象の文書１３０を要求する（５０４）。この処理は図７の説明として後述する。それぞれの要求によって文書を受信する（５０５）と、次に文書１３０の編集を行なう（５０６）。この処理は図８の説明として後述する。最後にサーバに文書１３０を送信する（５０７）。

次に、図６を用いて、新規文書の要求（５０３）が行なわれた際のクライアントコンピュータ１２０とサーバコンピュータ１１０の処理を説明する。クライアントコンピュータ１２０は「文書テンプレートIＤ」を指定し、サーバコンピュータ１１０に新規文書の受信要求を行なう（６０１）。要求を受けたサーバコンピュータ１１０は、文書テンプレート格納部１１７より指定されたIＤの文書１３０を取得し（６０２）、文書１３０の「署名値」リスト数をカウントし、その数をクライアントコンピュータ１２０に送信する（６０３）。クライアントコンピュータ１２０はその数を承認者数として受信し（６０４）、承認者数分の承認者を決定後、サーバコンピュータ１１０に送信する（６０５）。

承認者を受け取ったサーバコンピュータ１１０は、文書管理テーブル１１６を参照しながら新規のIＤを取得し（６０６）、取得したIＤを「文書IＤ_S」に格納（６０７）、「署名済み者_S」に指名者分の空のリストを格納（６０８）する。その後、文書１３０の「文書IＤ」に新規IＤを格納（６０９）後、「承認者」にサーバコンピュータ１１０より受け取った承認者を格納（６１０）後、文書１３０を文書管理テーブル１１６の「文書_S」に格納（６１１）し、クライアントへ文書１３０を送信する（６１２）。クライアントコンピュータ１２０は文書を受信し、新規文書要求５０３の処理を終了する。

次に、図７を用いて、既存文書の要求（５０４）が行なわれた際のサーバコンピュータ１１０の処理を説明する。サーバコンピュータ１１０は、既存文書の要求のあったクライアントコンピュータ１２０のログイン情報を読み込み（７０１）、クライアントコンピュータ１２０から「文書IＤ」指定で要求のあった文書１３０を取得する（７０２）。文書管理テーブル１１６においてクライアントコンピュータ１２０から指定のあった「文書IＤ」に対応する「署名済み者_S」を、ログイン情報によるログイン者と比較する（７０３）。ログイン者が「署名済み者_S」に含まれない場合にはクライアントコンピュータ１２０に文書１３０を送信し（７０５）、処理を終了する。含まれる場合には、文書１３０の全ての項目をReaｄ Only とし（７０４）、クライアントコンピュータ１２０に文書１３０を送信し（７０５）、処理を終了する。全ての項目をReaｄ Only とする（７０４）ことで、既に署名済みの者がさらに上書きをすることを防ぐものである。

次に、図８を用いて、文書編集（５０６）のクライアントコンピュータ１２０の処理を説明する。文書１３０の「内容」を更新すると（８０１）、ログイン者が「承認者」の何番目に相当するかを取得する（８０２）。ここで、ログイン者は「承認者」のＸ番目だとすると、ログイン者の情報により「内容」を署名値に変換し、「署名値（Ｘ）」にその値を格納し（８０３）、処理を終了する。

次に、図９を用いて、クライアントコンピュータ１２０より文書１３０を受信した後に、サーバコンピュータ１１０にて行なう処理を説明する。
サーバコンピュータ１１０は、文書１３０の送信元であるクライアントコンピュータ１２０のログイン情報を読み込み（９０１）、クライアントコンピュータ１２０から送信された文書１３０を読み込む（９０２）。文書管理テーブル１１６においてクライアントコンピュータ１２０から指定のあった「文書IＤ」に対応する「署名済み者_S」を、ログイン情報によるログイン者と比較し（９０３）、ログイン者が「署名済み者_S」に含まれる場合には、処理を終了する。そうでない場合は、文書管理テーブル１１６を更新する（９０４）。この更新処理は図１０の処理として後述する。文書管理テーブル１１６を更新した（９０４）後、「署名済み者_S」リストに空データが存在するかどうかを判定する（９０５）。空データが存在する場合は、そのまま文書１３０を「文書_S」に格納（９０８）後、処理を終了する。空データが存在しない場合は、文書１３０の全ての項目をReaｄ Only とし（９０６）、「コメント_S」を”成立”と更新してから、文書１３０を「文書_S」に格納（９０８）後、処理を終了する。

次に、図１０を用いて、サーバコンピュータ１１０にて文書管理テーブル１１６を更新する処理を説明する。この時点で、文書１３０はクライアントコンピュータ１２０によって更新された最新のものであるのに対し、「署名済み者_S」は１つ前の文書１３０における署名済み者の状態を表わしている。文書管理テーブル１１６の「コメント_S」の内容を削除する（１００１）。

そして、それぞれの承認者の署名値状態を順番に見ていくため、変数 i を用いて処理を行なう。まず i = １とし（１００２）、「署名済み者_S（i）」と「承認者（i）」を比較する（１００３）。ここで、両者が同じ値でなければ、文書１３０が以前に「承認者（i）」によって署名されていない状態であることがわかる。それに対し、文書１３０の項目A、Ｂ、Cにおいて、全ての「内容」に対して「署名値（i）」に正しい値が入っているかを検知し（１００４）、最新の文書１３０における「承認者（i）」の署名状態を知ることができる。全て正しい値である場合は、「承認者（i）」の署名が加えられたことになるため、「コメント_S」に” 「承認者（i）」の署名追加”と追記し（１００５）、「署名済み者_S（i）」を「承認者（i）」で更新する（１００６）。

また、「署名済み者_S（i）」と「承認者（i）」を比較し（１００３）、両者が同じ値の場合は、文書１３０が以前に「承認者（i）」によって署名されている状態であることがわかる。この場合も、文書１３０の項目A、Ｂ、Cにおいて、全ての「内容」に対して「署名値（i）」に正しい値が入っているかを検知し（１００７）、全てが正しい値ではない場合は、「承認者（i）」の署名が削除されたことになるため、「コメント_S」に” 「承認者（i）」の署名削除”と追記し（１００８）、「署名済み者_S（i）」から「承認者（i）」を削除する（１００９）。以上の処理が終わったら、i=i+１とし（１０１０）、「承認者（i）」が存在しなくなるまで１００３から同じ処理を繰り返す（１０１１）。この処理により、「署名済み者_S」と「コメント_S」は最新の情報に更新され、処理を終了する。

上記例では２者間での処理を記述したが、３者以上にすることも可能である。

また、文書には履歴を持たすことが可能なため、文書１３０に履歴を持たせ、図５の５０６処理の直前に前状態との差分チェックを行ない、文書１３０中のどこに変更が加えたかを表示するような処理を入れ込むこともできる。このような機能により、２者が対等性を保ちながら、文書を合意に持っていくことができる。

システム構成図である。文書形式である。文書管理テーブルの形式である。文書テンプレート格納部の形式である。クライアント処理のフローチャート図である。新規文書送受信のフローチャート図である。既存文書送信のフローチャート図である。文書編集のフローチャート図である。サーバ処理のフローチャート図である。文書管理テーブル更新のフローチャート図である。

符号の説明

１１０サーバコンピュータ
１１１サーバコンピュータの文書格納部
１１２サーバコンピュータの文書送信部
１１３サーバコンピュータの要求受信部
１１４サーバコンピュータの文書受信部
１１５サーバコンピュータの文書管理テーブル更新部
１１６文書管理テーブル
１１７文書テンプレート格納部
１２０クライアントコンピュータ
１２１クライアントコンピュータの文書受信部
１２２クライアントコンピュータの文書編集部
１２３クライアントコンピュータのログイン部
１２４クライアントコンピュータの文書送信部
１２５クライアントコンピュータの要求送信部
１２５クライアントコンピュータの署名部
１３０文書

Claims

電子文書を介して、対等な権限をもった複数の承認者が改竄を防止しながら交渉を行ない、署名を行なうためのシステムは、
契約書を表示し、承認者の署名を受け付ける複数のクライアントと、
承認者のうち署名が有効でない者のみが前記契約書を更新でき、署名が有効である者は文書を参照することしかできない仮ロック状態を設定する手段と、全員の署名が揃った時点で契約書が合意された時に本ロック状態の設定する手段とを含むサーバとを有することを特徴とする交渉システム。
請求項１記載の交渉システムにおいて、前記契約書の内容を変更した際の記載内容を履歴として保持することを特徴とする交渉システム。