JP2002117368A

JP2002117368A - データ送受信方法及びフォーム提供システム

Info

Publication number: JP2002117368A
Application number: JP2000307663A
Authority: JP
Inventors: Shiro Sonehara; 士郎曽根原; Takayuki Kubota; 隆幸久保田; Eiichi Kawaguchi; 栄一川口; Tetsuo Yasunaga; 哲郎安永
Original assignee: Kokuyo Co Ltd
Current assignee: Kokuyo Co Ltd
Priority date: 2000-10-06
Filing date: 2000-10-06
Publication date: 2002-04-19

Abstract

(57)【要約】【課題】多種大量なデータ項目を判りやすく管理する
こと。【解決手段】フォームデータベースに登録されたフォ
ームを送信用に特定するフォーム特定工程Ｓ１と、特定
されたフォームを前記スタイルデータに従って表示する
フォーム表示工程Ｓ２と、特定されたフォームの各フィ
ールドのうち当該フィールド名と関連した項目のデータ
を前記項目別データベース１３から抽出すると共に当該
抽出されたデータを当該フィールドに格納するフィール
ドデータ抽出工程Ｓ３とを備えている。さらに、フィー
ルドにデータが格納されると、当該フォームの各フィー
ルドデータを一群の情報として当該フォームの送り先へ
アクセスを許可するアクセス許可工程Ｓ５を備えた。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データ送受信方法
に係り、特に、個人情報や、商取引に関連する情報や、
各種の申請及び申込に関する情報など種々の情報を送受
信するための方法に関する。また、本発明は、このデー
タの送受信を行うためのフォーム提供システムや、フォ
ームの証明を行う認証局等に関する。

【０００２】

【従来の技術】従来より、会社や教育機関などの組織で
は、組織内での情報の共有や事務処理の効率を向上さ
せ、そのコストを低減するために、情報システムを構築
している。情報システムは、各種の電子化されたデータ
を用いて、組織内の人員に関するデータ管理や、売上や
支払等の管理や、スケジュールの管理等を行う。一方、
異なる組織間では、例えば、受発注などの商取引につい
て、情報を伝票用紙ではなく電子データにて行うＥＤＩ
（Electronic Data Interchange)が用いられている。

【０００３】そして、近年の情報関連技術（ＩＴ，Info
rmation Technology）の発展と浸透に伴い、ＴＣＰ／Ｉ
Ｐを用いた通信により異なる組織間・個人間のデータ転
送が容易となったことから、ＨＴＭＬ等のマークアップ
・ランゲージを用いて記述されたページを送受信するこ
とで情報の伝達を行うことができるようになった。この
インターネットを介したページの公開では、例えば、行
政機関等がそのホームページにて各種申請に必要な帳票
を電子的に提供している。申請者は、この電子的な申請
書データを行政機関によって管理されるサーバからダウ
ンロードし、印刷した上、所定の記入を行い、各種の申
請を行うことができる。

【０００４】さらに、データベースから必要な項目を読
み出してマークアップ・ランゲージで記述するページを
自動生成する手法や、ユーザの端末に表示したページ上
の各種の実行ボタンの操作に応じてユーザの端末にて入
力したデータをデータベースに登録する手法を用いて、
各種の申請や、宿泊施設への予約や、購入の申込等を電
子的に行うことも実現している。そして、各種の申請に
必要な帳票をデータベースに登録しておき、帳票の作成
から電子的又は印刷した用紙による帳票の提出までの操
作を支援するシステムも提案されている（特開２０００
-６７１３８号）。

【０００５】また、コンピュータによる可読性を高め、
データベースや既存の情報システムとの親和性を有しつ
つ、より多様なデータ交換を行う規格として、ＸＭＬ
（eXtensible Markup Language）やその周辺技術（例え
ば、ＸＳＬ，eXtensible StyleLanguage、ＸＳＬＴ，XS
L Transformation等）が提案されている。このＸＭＬに
従って作成される電子データでは、その電子データを共
有するコミュニティがタグの用途等を定義するスキーマ
言語（例えば、XML SchemaやＤＴＤ，DocumentType Def
initionなど）を自由に取り決めることができるため、
行政機関に提出する全ての申請や、企業や教育機関等の
組織間での情報の授受や、組織と個人顧客間の商取引に
関する情報や、教育機関や企業等の組織内の文書をその
項目レベルで再利用しやすい状態で定義することができ
る。すなわち、スキーマを共有することで、電子データ
のボキャブラリを異なる組織間で共有することができ
る。その項目に記述された内容は、コンピュータで可読
な状態となり、すると、項目名を特定した検索や、既存
のシステムへのデータ登録などが容易となる。

【０００６】

【発明が解決しようとする課題】上記各従来例では、個
人的、社会的、組織的な活動の種々の局面において多種
類の個人的又は組織内部の保護されるべきデータの電子
的な送受信に際して、各項目のデータの取扱が不明確と
なりやすい、という不都合があった。すなわち、ＸＭＬ
等の技術により送受信データを情報システムへ取り込む
ことが容易となると、データの送信者側の意図を超えて
データの受信者側でその内容を利用される可能性が高ま
ってしまう。また、多様な種類の情報を大量に電子的に
送受信すると、その電子データ全てを体系的に管理する
ことが困難となり、この多種類、大量という点からも、
データ項目毎に明確にデータを管理することが困難とな
る。

【０００７】また、データの受信側でも、従来申請用紙
や伝票等の帳票（用紙）に基づいて業務負担や処理内容
が定められていた場合に、受信したデータがそのまま組
織内の情報システムに登録されると、その閲覧や認証結
果の反映等をワークフローを再検討しなければならず、
従って、各種の申請等のデータを電子的に受信すること
によって直ちに業務を効率化することができず、慎重な
処理を要求される業務では、各種の申請等の電子化が難
しくなってしまう。すなわち、従来より利用されている
伝票や申請用紙による情報の伝達を電子化することが難
しい、という不都合があった。

【０００８】

【発明の目的】本発明は、係る従来例の有する不都合を
改善し、特に、多種大量なデータ項目のデータを判りや
すく管理することのでき、また、情報の受信側にとって
も利用しやすいデータ送信方法を提供することを、その
目的とする。本発明はまた、データの送受信に有用なフ
ォームを提供することを、その目的とする。

【０００９】

【課題を解決するための手段】本発明の複数の発明者
は、複雑な電子データの送受信での混乱を生じさせない
ためには、または、より利用者によって理解しやすい状
態で電子データの送受信及び管理を行うには、従来より
用いていた市販されている又組織内での帳票用紙のレイ
アウト（スタイル）を活用すべきである、という着想を
得た。例えば、入学願書は入学希望先の教育機関への入
学希望の表明であり、そこに記述する内容は当該教育機
関によって秘密が保持されることを期待できる。また、
行政機関によって発行された住民票は、住民票取得時で
のその住民の正確な現住所を示す。社内の物品購入に必
要な承認請求用紙や、稟議書等は一定の目的のために作
成された文書であり、その用紙はどのように閲覧され、
処理が行われるかが定まっている。このように、帳票に
は、作成者と一又は複数の宛先と使用目的とがあり、各
データ項目は、この使用目的に従って記述される。本発
明では、電子的な帳票（フォーム）を単位としてデータ
項目へのアクセス権や用途を特定する。これにより、個
人的、社会的、さらに組織内で用いる多種多様なデータ
項目を送信者及び受信者にとって理解しやすい形でデー
タを送受信することができる。

【００１０】本発明では、予め定められた項目のデータ
をそれぞれ保持する複数のフィールド及びこれら各フィ
ールドの表示用の配置関係を指定するスタイルデータを
有する一又は複数のフォームを登録したフォームデータ
ベースと、前記フォームのフィールド名と関連した各項
目のデータを登録した一又は複数の項目別データベース
とを使用して情報を送り先へ送信するデータ送信方法で
あって、フォームデータベースに登録されたフォームを
送信用に特定するフォーム特定工程と、このフォーム特
定工程にて特定されたフォームを前記スタイルデータに
従って表示するフォーム表示工程と、前記フォーム特定
工程にて特定されたフォームの各フィールドのうち当該
フィールド名と関連した項目のデータを前記項目別デー
タベースから抽出すると共に当該抽出されたデータを当
該フィールドに格納するフィールドデータ抽出工程と、
各フィールドにデータが格納された後に当該フォームの
各フィールドデータを一群の情報として当該フォームの
送り先へアクセスを許可するアクセス許可工程とを備え
た、という構成を採っている。これにより前述した目的
を達成しようとするものである。

【００１１】フォームは、市販の又は組織で特別に印刷
等した帳票のレイアウトを有する電子的なデータであ
る。このフォームは、帳票の項目に対応した複数のフィ
ールドと、各フィールドの表示用の配置関係を指定する
スタイルデータを有する。このフォームは、フォームデ
ータベースに登録されている。また、フィールドに対応
する項目で識別可能な項目別データベースは、フォーム
の作成者のローカルな端末か、または所定のデータセン
ター等に登録されている。本発明では、データの送信者
は、まず、フォームを特定する。フォームが登録される
と、このフォームはスタイルデータに従ったレイアウト
で表示される。ユーザはこのフォームを確認し、項目別
データベースから当該フィールドに対応したデータを抽
出し、フィールドにデータを格納する。項目別データベ
ースに登録されていないデータがある場合には、データ
の送信者が入力する。そして、データの送信者は、この
フォームを単位としてデータの受信者に対して当該アク
セスを許可する。例えば、項目別データベースがデータ
センタ等に格納されている場合には、電子的なデータの
転送は行わずに、当該フォームのフィールドに対応する
データ項目へのアクセスを許可する。項目別データベー
スが送信者のローカルなコンピュータに登録されている
場合には、そのコンピュータへのアクセスをデータ受信
者に許可しても良い。また、フィールドにデータを格納
した状態で当該フォームを送信するようにしても良い。
このように、データの送信者は、個別のデータ項目を送
信者に送信するのではなく、フォームを単位として送信
する。これにより、送信者は、送信するデータ項目の意
味内容や意図を一定の文脈で理解することができ、各デ
ータ項目の管理を行いやすい。また、データの利用者
（受信者）も、フォームを単位として電子データにアク
セスすると、送信の場合と同様の効果を奏する。

【００１２】好ましい実施形態では、現実の帳票用紙の
利点を電子データの送受信に適用するために、フォーム
又はフィールドを単位として各種の認証を行う認証局を
用いる。そして、好ましい実施形態では、データの送受
信及び入出力にフォームを用いながら一定のワークフロ
ーを実現するための仕組みとして、フォーム又はフィー
ルド別に予め定められた処理を記述し、さらに複数のフ
ォームを関連付ける。例えば、出金伝票フォームを完成
させることで、現金出納帳フォームを呼び出す。また、
履歴書フォームを受信したときに面接者選定フォームを
呼び出し、面接者選定フォームが完成したときに採用通
知フォーム及び不採用通知フォームを呼び出す。このよ
うにフォームを関連させることで、業務の自然な推移に
従った分散処理を実現することができる。

【００１３】

【発明の実施の形態】以下、本発明の実施の形態を図面
を参照して説明する。図１は、本発明の第１実施形態に
よるデータ送信処理の構成例を示すフローチャートであ
る。本実施形態では、予め定められた項目のデータをそ
れぞれ保持する複数のフィールド及びこれら各フィール
ドの表示用の配置関係を指定するスタイルデータを有す
る一又は複数のフォームを登録したフォームデータベー
ス１２と、前記フォームのフィールド名と関連した各項
目のデータを登録した一又は複数の項目別データベース
１３とを使用して情報を送り先へ送信する。フォーム
は、ＸＭＬ関連技術や、ＨＴＭＬなどのマークアップラ
ンゲージにて記述すると良い。また、ＰＤＦや他の一般
的なワードプロセッシングソフトウエアでの文書形式で
作成しても良い。

【００１４】図１に示す例では、まず、フォームデータ
ベースに登録されたフォームを送信用に特定する（フォ
ーム特定工程Ｓ１）。続いて、このフォーム特定工程Ｓ
１にて特定されたフォームを前記スタイルデータに従っ
て表示する（フォーム表示工程Ｓ２）。さらに、フォー
ム特定工程Ｓ１にて特定されたフォームの各フィールド
のうち当該フィールド名と関連した項目のデータを前記
項目別データベース１３から抽出すると共に当該抽出さ
れたデータを当該フィールドに格納する（フィールドデ
ータ抽出工程Ｓ３）。このフィールドデータ抽出工程に
前後して、項目別データベースにデータが登録されてい
ない項目に関連するフィールドについてデータの入力を
促すと共に入力されるデータを当該フィールドに格納す
るフィールドデータ入力工程Ｓ４を備えるようにしても
良い。そして、フィールドにデータが格納されると、当
該フォームの各フィールドデータを一群の情報として当
該フォームの送り先へアクセスを許可する（アクセス許
可工程Ｓ５）。このフォーム全体に対して一括してアク
セス権を設定することで、項目別データベースに格納さ
れたデータのうち今回のデータ送信の意図に応じた項目
のみについてアクセスを許可することができ、また、フ
ォームを単位にデータの内容を確認することができるた
め、各データ項目の意味内容を送信者及び受信者が理解
し易い。

【００１５】項目別データベースは、送信者が使用する
ローカルなコンピュータのファイルシステムにて管理さ
れていても良いし、また、ネットワークを介して接続さ
れたデータセンタや、組織内のデータベースであっても
よい。データベースというときには、ＸＭＬ等のタグが
付された小規模なテキスト・ファイルから、ＳＱＬ文等
で外部と更新する大規模なデータ・ベースまでを含む。
また、「端末」というときには、主にフォームの送信者
又は受信者によって利用されるコンピュータを意図する
が、携帯電話等の携帯端末や、またサーバー機能を有す
るコンピュータを意味する場合もある。

【００１６】図１に示すフォーム特定工程では、送信者
が、データ送信に使用するフォームを特定する。所定の
申請や意思表示を行う際にその申請等に応じたフォーム
を選択するようにしても良いし、また、一定のデータ又
はフォームを受信した結果として自動的にフォームを特
定するようにしても良い。図１に示す例では、データ送
信に使用するために特定されたフォームを、フィールド
にデータを格納していない状態で、データの送信者によ
って管理されるディスプレイに表示する。データの送信
者がコンピュータを使用する場合には、コンピュータに
接続されたディスプレイであり、携帯端末を使用する場
合には、その携帯端末のディスプレイである。

【００１７】本実施形態では、フォームのスタイル（レ
イアウト）を送信者に表示する（ステップＳ２）。送信
者がそのフォーム又はそのフォームの元となる市販又は
組織内の帳票に慣れている場合には、どのようなデータ
項目がそのフォームに含まれるかを理解し易い。また、
不慣れなレイアウトのフォームであっても、送信者は、
そのフォームの名称やレイアウトからそのフォームが意
図するデータの利用態様を理解しやすい。

【００１８】図１に示す例では、ディスプレイ等に表示
したフォームに含まれる各フィールドにデータを格納す
る。項目別のデータベース（例えば、組織内のデータベ
ースや個人的にフロッピー（登録商標）ディスク等に格
納した個人情報ファイル）を有する場合には、そのフィ
ールドに対応する項目のデータを当該項目別データベー
スから読み出す。履歴書フォームにおける志望動機の欄
（フィールド）など、フォームの送信毎に個別に記述す
る必要が有る部分については、当該フィールドに新たに
入力する。ここでは、「フィールドデータの入力」に
は、項目別データベースに格納されていた旧情報を新情
報へ更新する更新処理を含む。例えば、履歴書フォーム
に記述する現住所が変化している場合には、新しい現住
所を当該現住所フィールドに入力する。

【００１９】フォームの各フィールドにデータを登録す
ると、このフォーム及びフォームのフィールドに入力さ
れたデータに対するアクセス権を送り先に許可する。項
目別データベースがデータセンタや送信者のローカルサ
ーバに格納されている場合には、受信者へ当該フォーム
に含まれるデータ項目へのアクセス権を付与するように
しても良いし、また、当該フォームを受信者のみが読み
とれるように暗号化して受信者に送信するようにしても
良い。受信者のみが読みとれるようにデータを送信する
には、例えば、受信者の公開鍵で暗号化すると良い。

【００２０】図２は、本実施形態でのデータの受信をフ
ォームを単位として行う処理例を示すフローチャートで
ある。まず、フォームデータベース１２に登録されたフ
ォームを送信用に特定する（フォーム特定工程Ｓ１
１）。続いて、各フィールドにデータが格納された後に
当該フォームの各フィールドデータを一群の情報として
前記受信者のアクセス権を判定する（アクセス権判定工
程Ｓ１２）。そして、フォーム特定工程Ｓ１２にて特定
されたフォームの各フィールドのうち当該フィールド名
と関連した項目のデータを前記項目別データベースから
抽出すると共に当該抽出されたデータを当該フィールド
に格納する（フィールドデータ抽出工程Ｓ１３）。

【００２１】アクセス権の判定Ｓ１２では、受信するデ
ータが図１に示すデータ送信方法にて送信されたデータ
であれば、送信者がフォーム全体に対してフォームの受
信者にアクセス権を与えているため、フォームの種別に
基づいてアクセス権の判定が可能である。また、組織内
のデータベース（項目別データベース１３）から必要な
データ項目を受信するには、本実施例では、ユーザとフ
ォームの関係に基づいて当該データベースの項目へのア
クセス権を定める。例えば、採用結果及び新人の紹介を
行うための新人紹介フォームに付いては組織内全員がア
クセスできるが、応募者が提出した履歴書フォームには
面接担当者及び採用責任者のみがアクセスできる。

【００２２】採用された新人の現住所が新人紹介フォー
ムに紹介されている場合には、組織内全員が新人の現住
所データにアクセスすることができる。しかし、同一の
現住所データであっても、採用された新人（応募者）が
提出した履歴書フォームの現住所データへのアクセスは
面接担当者等のみに制限される。どの主体にどのデータ
項目の閲覧を許可し、また禁止するかは、データの種類
が多種大量となるとその管理が煩雑となってしまうが、
図２に示す例では、フォームを単位として個々の主体
（データ受信者）のアクセス権を判定するため、現状の
データ秘匿状況を素直にシステム化することができる。
特に、データベースの構築及び運用に関する知識を要さ
ずに、フォームを単位として各主体又はグループのアク
セス権を設定することで、不適切な情報漏洩を有効に防
止することができる。すなわち、データ項目に対するア
クセス権ではなく、データ項目を読み出すことができる
フォームに対するアクセス権を設定することで、多種多
量なデータの管理を個々の業務担当者の経験を生かしつ
つシステム構築を行うことが可能となる。

【００２３】アクセス権は、読出の可否のみならず、書
込の可否を含めるようにしても良い。例えば、一旦提出
した履歴書フォームの現住所の訂正は、書類の性質から
して応募者本人にのみ許可される。従って、履歴書フォ
ーム（履歴書フォーム中の採用担当者記入欄等を除く）
の更新は応募者のみに許可される。一方、新人紹介フォ
ームの場合には、人事部の担当者が更新を行うことがで
きるが、新人本人は更新ができないといった運用が可能
となる。

【００２４】図１及び図２に示すように、フォームを単
位として各データ項目を一体的なデータとして扱い、そ
のフォーム全体でアクセス権を設定することで、現実の
業務内容に沿った形でデータの送受信（提供及び閲覧）
を行うことができる。

【００２５】図３は、第１実施形態でのフォーム提供シ
ステムの構成例を示すブロック図である。図３に示す例
では、予め定められた項目のデータをそれぞれ保持する
複数のフィールド及びこれら各フィールドの表示用の配
置関係を指定するスタイルデータを有する複数のフォー
ムを登録したフォームデータベース１２と、ネットワー
クを介して接続された端末に前記フォームデータベース
に登録されたフォームデータを提供するフォーム提供サ
ーバ１０とを備えている。そして、フォームデータベー
スが、主となるフォームが選択された時に当該主フォー
ムに関連する関連フォームを特定するためのフォーム関
連データを備えている。

【００２６】現在使用されている帳票用紙は、帳票と帳
票に一定の関係がある。例えば、出金伝票や入金伝票を
使用して現金出納帳が記帳される。出勤簿の記述内容に
基づいて給与支払明細書が作成される。また、例えば、
市販の履歴書には「宛先」フィールドが存在しない。履
歴書は、宛先を明記した封筒に封入されて完成する。封
筒も一つのフォーム（帳票）と考えると、履歴書フォー
ムと封筒フォームとは関係していて、両方同時に作成し
なければ、データの送り先を特定できない。また、請求
書や手紙（便せん）は、その紙の状態で保管されるので
はなく、各種のファイリング用品を用いて保管されてい
る。

【００２７】図３に示す例では、フォームの提供に関し
て、各フォームの関係を示すフォーム関連データを使用
する。フォーム関連データは、フォームの内側に不可視
又は可視の状態で埋め込むようにしても良いし、フォー
ムとは別に格納するようにしても良い。フォームとフォ
ームの関係としては、同時に作成すべき添付関係（履歴
書フォームと封筒）と、一つのフォームの送受信が完了
した後に作成が必要となるフォームを指定するワークフ
ロー関係と、多数のフォームを保管するフォームである
保管関係などがある。

【００２８】添付関係は、なんらかの申告や報告を行う
場合に併せて必要となるフォームを特定するようにして
も良いし、また、履歴書フォームを作成者記載欄フォー
ムと採用者記載欄フォームとに論理的に分割するなど、
アクセス権の単位となるフォーム群で別々のフォームと
し、両者を添付関係とするようにしても良い。添付関係
の場合には、フォーム提供システムは、１つのフォーム
が特定されたときに他のフォームを併せて提供する。

【００２９】ワークフロー関係（ワークフロー特定デー
タ）では、フォーム作成者によってフォームが転送され
た後に当該フォームの受信者にて使用するフォームを特
定する。すなわち、送信者によって作成されたフォーム
を受信者が受信した際に受信者側で必要となるフォーム
を特定する。例えば、履歴書フォームを受信した受信者
が別の種類のフォームの送信者の立場でフォーム提供サ
ーバ１０にアクセスした場合に、受信した履歴書フォー
ムとワークフロー関係にあるフォームの一覧を探索す
る。履歴書フォームには、受信側として、面接記録フォ
ームや、採用通知フォームや、不採用通知フォームが用
意されているとする。すなわち、履歴書フォームと採用
通知フォームはワークフロー関係として定義されている
とする。すると、履歴書の受信者は採用通知フォームを
フォーム提供サーバ１０からダウンロードすることがで
きる。履歴書の受信者は、採用通知フォームと添付関係
にある封筒フォームを読み出し、ディスプレイに表示す
る。封筒フォームの送り先フィールドや、採用通知の宛
先フィールドは、既に受信した履歴書フォームを項目別
データベースとして、この履歴書フォームのフィールド
に格納された履歴書作成者の現住所フィールドや個人氏
名フィールドのデータを採用通知フォームの対応するフ
ィールドにコピーする。

【００３０】また、電子的な領収書である領収書フォー
ムを販売店のＷｅｂサイトからネットワーク８を介して
アクセス可能な状態となったとする。領収書フォームと
ワークフロー関係にあるフォームとして、出金伝票フォ
ームや、物品購入管理フォームや、出張報告書フォーム
とがあるとする。領収書フォーム内に不可視のデータと
してワークフロー関係にあるフォーム名を埋め込む例で
は、領収書フォームに対して操作をすることでフォーム
ＤＢ１２に格納された出張報告書フォームを特定するこ
とができる。領収書フォームのフィールドから領収金額
データを読み取り、出張報告書フォームの出張費フィー
ルドに格納する。また、出張報告書フォームと領収書フ
ォームとが添付関係にあると定義されている場合には、
出張報告書フォームに受信した領収書フォームを添付し
て、出張報告の受信者へ当該出張報告書フォームを送信
する。出張報告書フォームの受信側にてさらにワークフ
ロー関係にあるフォームが定義されていれば、出張報告
書フォームの受信者は必要な業務をフォーム提供サーバ
１０から提供されるフォームを利用して処理する。

【００３１】保管関係は、帳票用紙をフラットファイル
などのファイリング用品で綴じるように、多数の電子的
なフォームを１つの保管されたフォームとする関係であ
る。例えば、フラットファイルフォームは、履歴書フォ
ームと保管関係にあるとする。履歴書フォームをフラッ
トファイルフォームと関連付けることで、履歴書フォー
ムを単位とするアクセス権を、フラットファイルフォー
ムを単位とするアクセス権に変更することができる。ま
た、個々の履歴書フォームを人事部から採用部門の部門
長に送信するのではなく、人事部側で受信した履歴書フ
ォームをフラットファイルフォームに保管したうえ、こ
のフラットファイルフォームを送信するようにしても良
い。

【００３２】ワークフロー関係及び保管関係としては、
例えば品質管理のための文書の保管を厳格に行う場合に
各文書をフォームとしておくことで文書の厳格な管理を
比較的少ない作業量で行うことができる。

【００３３】このように、単純にフォームのみを提供す
るのではなく、フォームとフォームの関係を定義するこ
とで、フォーム自体に内在しているルールに従ってフォ
ームの作成及びデータの送受信をより簡明な状態で行う
ことができる。このワークフロー関係や、添付関係や、
保管関係を整備するすることで、フォーム提供サーバ１
０は、インターネットで接続された多数の組織及び個人
にとって、文書管理システムとして機能する。本実施形
態によるフォームによるデータの送受信と、フォーム間
の関係の定義とにより、ＨＴＭＬによるページが世界中
のコンピュータと相互リンクしたように、フォームを単
位とした送受信データが相互に関連しあう。これは、自
らが作成するのではない書類については、入力作業を不
要とする可能性を示唆する。また、フォームに書式等を
埋め込むことで、書類の送受信に際して形式的なチェッ
クを不要とする可能性をもたらす。ＨＴＭＬによるペー
ジはサーバの管理者から不特定多数へのメッセージであ
るが、フォームによるデータの送受信は特定者から特定
者へのメッセージである。そして、特定者と特定者間の
メッセージが一定のアクセス権管理を保ちながら相互に
関連することによって、多種類大量のデータを各個人が
比較的容易に管理できるシステム環境を構築することが
できる。

【００３４】また、添付関係では、一方を内容フォーム
（例えば、履歴書フォーム）とし、他方を通信フォーム
（例えば、封筒フォーム）としても良い。内容フォーム
は、フォーム受信者へ向けてフォーム作成者によって各
フィールド毎に記述される内容データを保持する。通信
フォームは、この内容フォームの関連フォームとして当
該内容フォームを前記フォーム作成者の端末から前記フ
ォーム受信者の端末へ転送するための転送用データを保
持する。図３に示す例では、フォーム提供サーバ１０
が、前記内容フォームが要求された場合には当該内容フ
ォームと当該内容フォームに関連する通信フォームとを
当該内容フォームを要求した端末に送信するフォーム送
信部１０Ａを備えると良い。通信フォームは、フォーム
の作成者からフォームの受信者へ当該内容フォームを送
信するための機能を埋め込むと良い。また、通信フォー
ムを、内容フォームへのアクセス権の設定用データとし
ても良い。

【００３５】また、図３に示す例では、フォーム提供サ
ーバが、提供するフォームを他のフォームと識別するた
めの不可視のデータを当該フォームに埋め込む不可視デ
ータ埋め込み部１０Ｂを備えている。不可視データ埋め
込み部１０Ｂによって埋め込まれる不可視データは、例
えば添付、ワークフロー、保管等のフォーム関連データ
である。また、不可視データを、フォームの各フィール
ドのデータ型や記載形式を特定するための記述（フォー
ムロジック）や、各フィールド毎に当該フィールドに入
力されるデータの種別に応じて、当該フォームを表示す
る端末１にて実行されるスクリプト（フィールドアクシ
ョン（商標））としても良い。フィールド毎に定義され
るスクリプトは、例えば、入力の支援や、関連情報の取
得や、他のフィールドに格納される値との関係に基づい
て何らかの値を計算する計算式や、他のデータへのリン
クを制御する。不可視データとして、各フィールド毎の
スクリプトではなく、フォーム全体を駆動するためのフ
ォーム用のスクリプト（フォームアクション（商標））
を採用しても良い。これらのスクリプトの場合には、ス
クリプト自体を表示用のフォームのスタイルとしては送
信者や受信者に対して不可視とするのであって、これら
のスクリプトに従って各種の操作ボタンやリンク表示等
を行うようにしても良い。

【００３６】上述したように第１実施形態によると、ま
ず、フォームを単位としてアクセス権の設定を行い、こ
れに応じてデータの送受信を行うため、送受信者にとっ
て理解しやすい状態で多種多量なデータ項目を送受信す
ることができ、また、大規模な一又は複数のデータベー
スへのアクセス権を各業務担当者の業務を素直に反映さ
せたシステムの構築が可能となる。また、フォーム関連
データを用いる例では、多種類のフォームの関係を定め
ておくことで、申請や、報告や、判断のための情報の閲
覧や、承認などの複数の主体間でデータの送受信を伴い
ながら実行すべき作業をフォームを用いてスムーズに行
うことができる。さらに、各フォームの受信者側で次に
必要となるフォームの定義（ワークフロー関係等）を行
うことで、例えばインターネット等に接続された端末を
操作可能な個人や組織のメンバー間での作業及び業務を
定型的なものとしてシステム化することができる。すな
わち、伝票の作成や添付書類の一覧の確認等の本来の主
たる業務ではない間接的なコストとなる作業に要する時
間を短縮することができる。しかも、各担当者がフォー
ムに対して有する注意力と同様の注意力で各データ項目
へのアクセス権を管理しつつ、このデータの送受信を要
する作業負担の低減を実現することができる。

【００３７】＜第２実施形態：フォームの認証＞次
に、データ項目を一括して送受信するためのフォームの
認証について説明する。図４は、第２実施形態によるフ
ォーム認証局（フォームを認証するための認証サーバ）
の構成例を示すブロック図である。フォームは、図示し
ないフォームＤＢ１２や、フォームを送信するフォーム
送信端末１Ａに格納されている。フォームは、予め定め
られた項目のデータをそれぞれ保持する複数のフィール
ド及びこれら各フィールドの表示用の配置関係を指定す
るスタイルデータを有する。このフォームのフィールド
に対応する項目のデータを格納し、このフォームをフォ
ーム受信端末１Ｂに送信することで、フォーム送信端末
１Ａの使用者は、フォーム受信端末の使用者へ一群のデ
ータを送信する。ここで、「フォームの送信」には、第
１実施形態にて説明した「フォームの各フィールドデー
タへのアクセス権の許可」を含む。フォームに格納され
たデータへのアクセス権をフォームの受信者に許可する
ことで、実際にデータを送信するのと同様の効果を得る
ことができる。

【００３８】図４に示す例では、フォーム認証局は、フ
ォーム送信端末１Ａからフォーム受信端末１Ｂへ送信さ
れるフォームを対象として種々の証明書の発行を行う。
このフォーム認証局は、フォームを当該フォームの宛先
となるフォーム受信端末１Ｂに送信するフォーム送信端
末１Ａとネットワーク８を介して接続された通信制御部
１４と、前記フォーム送信端末１Ａを使用するフォーム
発行者の情報を記憶したフォーム発行者データベース１
８と、前記フォーム送信端末１Ａにて送信予定のフォー
ムの属性を前記フォーム発行者ＤＢ１８に登録された情
報に基づいて前記通信制御部１４を介して認証する認証
部１６とを備える。通信制御部１４を介した認証（証明
書の発行等）は、フォームの送信前の認証でも良いし、
フォーム作成完了後の認証でも良い。また、フォーム認
証局がフォームを受信して証明書を当該フォームに添付
するようにしても良いし、フォーム送信端末１Ａ等のフ
ァイルシステムにて管理されるフォームの証明データを
通信制御部１４を介してフォーム送信端末１Ａに送信す
るようにしても良い。

【００３９】フォーム、フォームのフィールド又はフォ
ームの送信者に関する証明書の発行としては、フォーム
の発行者が本人であることの証明や、そのフォームの原
本性（偽造されていないことや改ざんされていないこ
と）の証明などである。一般に、データの証明を行うに
は、秘密鍵による暗号技術や、公開鍵及び秘密鍵（個人
鍵）による暗号技術や、一方向関数（ハッシュ関数）を
用いたデジタル署名技術を利用する。図４に示すフォー
ム認証局による証明で重要なのは、フォームの送信時で
の内容の正当性の証明であり、長期間に渡る秘密保持で
なないため、フォームを送信する時点での認証技術を用
い、受信側ではユーザＩＤ（ログインＩＤ）とパスワー
ドによるアクセス権の設定による管理としてもよい。

【００４０】ハッシュ関数は、文字列に適用する計算式
であり、元の文字列をハッシュ関数に通すことで、特定
の長さの文字列（メッセージ・ダイジェスト）を得るこ
とができる。ハッシュ関数を用いると元の文字列から唯
一のメッセージ・ダイジェストが生成されるが、メッセ
ージ・ダイジェストから元の文字列を復元することはで
きない。この計算の一方向性から、ハッシュ関数は一方
向性関数とも呼ばれる。また、元の文字列が変化する
と、メッセージ・ダイジェストの内容も変化する。この
ため、フォームの送信前にメッセージ・ダイジェストを
生成しておき、当該フォームの受信後にメッセージ・ダ
イジェストを生成し、両者を比較することでフォームの
内容が改ざんされていないことを認証することができ
る。もちろん、メッセージ・ダイジェスト自体が改ざん
されてしまうと、元の文字列の改ざんの有無を判定する
ことはできない。このため、送信元で生成したメッセー
ジ・ダイジェストを暗号化して受信側に送信する。

【００４１】公開鍵暗号方式は、送信者や受信者や認証
局のそれぞれが秘密に保持する秘密鍵と、この秘密鍵に
対応する公開鍵とをペアで用いる暗号技術である。ある
主体の秘密鍵で暗号化した情報は、その主体の公開鍵で
復号化することができる。ある主体の公開鍵で暗号化し
た情報は、その主体の秘密鍵でなければ復号化すること
ができない。公開鍵の所有者を認証できれば、その情報
は公開鍵の所有者によって暗号化されたことを証明する
ことができる。

【００４２】送信者は、フォームのメッセージ・ダイジ
ェストを生成し、さらに、そのメッセージ・ダイジェス
トを送信者の秘密鍵で暗号化する。受信者は、フォーム
と共にこの暗号化されたメッセージ・ダイジェストを受
信する。このメッセージ・ダイジェストを送信者の公開
鍵で複合することで、公開鍵の所有者によって暗号化さ
れたことを認証することができる。そして、受信したフ
ォームから受信者側で算出したメッセージ・ダイジェス
トと、復号化したメッセージ・ダイジェストとを比較す
ることで、フォームの内容が改ざんされていないことを
認証できる（デジタル署名）。送信者が、フォームの内
容を受信者にのみ開示し、他の者には秘密とする場合に
は、受信者の公開鍵でフォーム全体を暗号化する。する
と、受信者の秘密鍵以外ではそのフォームを復号化する
ことができない。

【００４３】他人の氏名での履歴書の作成や、企業名を
偽証して領収書を発行するなどの他人へのなりすましへ
の対策としては、認証局による証明書の発行が用いられ
る。メールアドレスと個人氏名と公開鍵の関係や、サー
バのＩＰアドレスと法人名称と公開鍵の関係などは、種
々のグレードでの証明書を認証局が発行する。この証明
書には認証局のデジタル署名（認証局の秘密鍵で暗号化
された証明書のメッセージ・ダイジェスト）が付され
る。

【００４４】本実施形態での認証局の機能は、サーバの
ドメイン名と法人名称の関係の証明等のみならず、認証
局に蓄積されたフォーム発行者に関連するデータを参照
して、フォームの内容についての証明書の発行も行う。
さらに、信頼できるフォーム発行主体によってデジタル
署名付きで発行されたフォームは、他のフォームのフィ
ールド内容の証明書であると考える。例えば自治体によ
って住民票フォームが発行されるのであれば、個人氏名
と現住所の関係について住民票フォームを証明書として
使用することができる。教育機関から学生に成績証明書
フォームや在学証明書フォームが発行されるのであれ
ば、この在学証明書フォームは例えば履歴書フォームの
学歴フィールドの証明書として使用することができる。
このように他のフォームのフィールドの内容を証明可能
なフォームの発行主体を、ここではフォーム認証局と呼
ぶ。成績証明書フォームが正当であることは、そのフォ
ームの送信端末の端末ＩＤ（例えば、ＩＰアドレス）と
教育機関名の関係の証明書によって認証できる。

【００４５】一般的に、パスポートの申請や運転免許証
の取得に住民票などの添付が要求される。これは、申請
書のフィールドの内容が正当であることを、自治体が発
行する住民票の記載に基づいて証明している。同様に、
各種のフォームが電子的に提供されるようになると、そ
のフォームの送信端末は認証局として機能する。

【００４６】図４に示す例では、認証部１６は、各種の
機能を備えている。例えば、認証部１６は、前記フォー
ムに当該フォームの発行者が本人であることの証明デー
タを付加する本人証明制御機能２０を備えている。本人
の証明は、例えばサーバからフォームを送信するのであ
れば、そのサーバのドメイン名やＩＰアドレスと発行者
名の関係の証明書を発行すれば良い。一方、フォームに
メールアドレスや連絡先電話番号を記載してダイアルア
ップ接続する端末から送信するのであれば、そのメール
アドレスや電話番号と個人氏名の関係の証明を行えば良
い。本人であることの証明は、フォーム発行主体へのな
りすましによるフォームの偽造を防止する。

【００４７】また、認証部１６が、前記フォームに当該
フォームが原本であることの証明データを付加する原本
証明制御機能２２を備えると良い。例えば、領収書や請
求書等を電子的なフォームにて発行する場合には、領収
書の発行主体名と、領収書の受取主体名（領収書フォー
ムの受信者又はその所属先名称）と、発行主体によって
発行される領収書に付される連続番号とによってその領
収書フォームが原本であることを証明することができ
る。さらに、発行日時や発行主体での売上伝票番号等を
付するようにしても良い。

【００４８】図４に示す例では、フォーム発行者ＤＢに
当該発行者によって発行された領収書の連続番号（領収
書発行番号）を格納しておき、この発行毎に増加する連
続番号が一致していることの証明書を発行するようにし
ても良い。例えば、フォーム提供サーバ１０がフォーム
発行者ＤＢを参照して次に発行する領収書の連続番号を
取得する。このフォーム送信端末ではこの領収書フォー
ムにデジタル署名を行うと共に、図４に示すフォーム認
証局にフォーム発行者の名称とその連続番号の関係の証
明を要求する。フォーム認証局では連続番号とフォーム
発行者名の関係の証明書をフォーム発行者ＤＢを参照し
て発行し、認証局に秘密鍵でデジタル署名する。これに
より、受信側にてその領収書フォームが改ざんされてい
ないことを認証することができる。

【００４９】また、図４に示す例では、認証部１６が、
前記フォームに当該フォームが原本の複写物であること
の証明データを付加する複写証明制御機能２４を備えて
いる。この複写証明制御機能２４は、複数箇所に同一フ
ォームがコピーされた場合に、その両者が同一であるこ
とを証明する機能であり、複写（バックカーボン）式の
給与支払明細書や送り状等のフォームと同様の機能を果
たすものである。例えば、そのフォームのメッセージ・
ダイジェストを認証局の秘密鍵で暗号化することで、そ
のフォームが複写された場合であっても両者に改変がな
されていないことを証明することができる。この場合、
フォームの送信者から一旦認証局にて受信し、認証部１
６にてメッセージダイジェストを算出すると共に暗号化
する。この認証局の秘密鍵で暗号化したメッセージ・ダ
イジェストを複写の証明書とする。

【００５０】さらに、図４に示す例では、認証部１６
が、前記フォームに当該フォームに含まれる全てのフィ
ールドの内容の証明及び証明者名を付加するフォーム別
証明制御機能２６を備えている。このフォーム全体を単
位とした証明は、原本証明や複写証明に適している。ま
た、住民票フォームの送信端末による履歴書フォームの
現住所の証明や、本人証明などは、フィールド別の証明
となる。この場合、認証部１６が、前記フォームに当該
フォームの特定のフィールドの内容の証明及び証明者名
を付加するフィールド別証明制御機能２８を備える。

【００５１】図５は図４に示す構成でのフォーム認証処
理の一例を示すフローチャートである。まず、フォーム
認証局は、フォームの発行要求を受信する（ステップＳ
３１）。続いて、フォームの発行要求を行ったフォーム
発行者及び発行するフォームの種別を特定する（ステッ
プＳ３２）。フォーム発行者とフォーム種別とが特定さ
れると、その発行者でのフォームに関する属性情報を特
定することができる。フォーム認証局はフォーム発行者
ＤＢから当該フォームに関する発行者データを特定する
（ステップＳ３３）。発行者データは、発行者の個人氏
名又は組織名称や、フォームの発行番号などである。続
いて、フォーム発行者の個人氏名又は組織名称の証明書
を発行する（ステップＳ３４）。図５に示す例では、フ
ォームの発行番号として発行毎に異なる番号である連続
番号を当該フォームに付与する（ステップＳ３５）。そ
して、この連続番号や他のキーとなるデータを等を用い
てフォームが原本であることの証明書を発行する（ステ
ップＳ３６）。フォーム発行者は、各証明書を添付した
フォームを発行し、フォーム受信者へ送信又はアクセス
許可する（ステップＳ３７）。フォームが発行されたこ
ととの一連のトランザクションとして、フォーム認証局
側では、フォームの連続番号等のフォーム発行者データ
を更新する（ステップＳ３８）。

【００５２】図４に示す構成や、図５に示す処理はフォ
ーム認証用プログラムをサーバ等の端末で実行すること
で実現できる。このフォーム認証用プログラムは、フォ
ーム認証システムを動作させる指令として、フォーム送
信端末を使用するフォーム発行者に関するデータを読み
出すフォーム発行者データ読出指令（ステップＳ３３に
対応）と、このフォーム発行者データ読出指令に応じて
読み出されるフォーム発行者データに基づいて前記フォ
ーム送信端末にて送信予定のフォームの属性を認証させ
る認証指令（ステップＳ３４，Ｓ３６に対応）とを備え
る。認証指令は、具体的には、図４に示す各機能を実現
するための指令を備えると良い。また、連続番号の証明
など証明対象が証明の都度変化する場合には、フォーム
認証用プログラムが、前記認証指令に応じてフォームの
認証をした後に当該認証結果を前記フォーム発行者デー
タに登録させるフォーム発行者データ更新指令（ステッ
プＳ３８に対応）を備えると良い。その他、図４及び図
５に示す機能又は工程をサーバにて実現するには、フォ
ーム認証用プログラムが、その機能や工程等に対応した
指令を備えれば良い。

【００５３】ここで、サーバ等を「動作させる指令」と
いうときには、各指令のみで演算装置（コンピュータ）
を動作させる指令と、サーバ等のコンピュータに予め格
納されているオペレーティングシステムやデータベース
システムなどの他のプログラムに依存して当該コンピュ
ータを動作させる指令とのいずれかまたは双方を含む。
例えば、図５に示す例では、フォーム発行者データ読出
指令を、サーバ１０に予め格納されたデータベースサー
バ用プログラムによるデータベース検索機能に依存し
て、当該検索機能にフォーム発行者データを識別するた
めのフォーム発行者ＩＤ及びフォームＩＤとを引き渡す
指令としても良い。このように、フォーム発行者データ
読出指令を記憶する記憶媒体であって、当該プログラム
をユーザへ搬送する用途の記憶媒体には、例えば「デー
タベースサーバに検索のキーとなるデータを引き渡す指
令」のみが格納される場合がある。これは、動作させよ
うとするコンピュータのオペレーティングシステムやサ
ーバ用プログラム等との関係で定る。

【００５４】フォーム認証用プログラムファイルは、可
搬性のある記憶媒体に格納されて当該コンピュータに供
給される。この記憶媒体は、ＣＤ-ＲＯＭやフロッピー
ディスクなどデータを不揮発的に記憶しておくものであ
れば、どのようなものでもよい。また、他のホスト装置
から通信回線を経由して補助記憶装置にプログラムを供
給することもできる。

【００５５】上述したように第２実施形態によると、発
行するフォームに関して改ざんや偽造を防止するための
証明書を発行するため、現実の帳票に与えられる署名や
捺印と同様の機能を電子的に実現することができる。フ
ォームの送信者及び受信者双方から信頼可能な第三者が
フォームの証明書を発行することで、多種類・大量な電
子データを受信する場合であってもそのフォームに証明
書を発行した認証局を確認するだけでそのフォームの正
当性を信頼することができる。

【００５６】＜第３実施形態：スクリプティング＞次
に、本発明の第３実施形態を説明する。第３実施形態で
は、電子化されたフォームの利便性をより高めるため
に、フォームとプログラム（スクリプト）とを関連させ
る。図６に示す実施形態では、フォーム提供システム９
と、このフォーム提供システム９から提供されるフォー
ムを実行するフォーム実行装置３０とを備えている。

【００５７】フォーム提供システム９は、予め定められ
た項目のデータをそれぞれ保持する複数のフィールド及
びこれら各フィールドの表示用の配置関係を指定するス
タイルデータを有する複数のフォームを登録したフォー
ムデータベース１２と、ネットワークを介して接続され
た端末に前記フォームデータベースに登録されたフォー
ムデータを提供するフォーム提供サーバ１０とを備えて
いる。そして、フォームデータベースに登録された各フ
ォームは、当該フォームの各フィールド毎に当該フィー
ルドに対して与えられるイベントに応じた動作を記述し
たフィールドスクリプト５を備えている。フィールドス
クリプトは、フォームのフィールド毎に定義され、この
フィールドに格納されるデータの入力支援や、関連情報
の検索などを行うためのプログラムである。

【００５８】また、フォームデータベース１２に登録さ
れた各フォームが、当該フォームに対して与えられるイ
ベントに応じた動作を記述したフォームスクリプトを備
えたるようにしても良い。このフォームスクリプトは、
フォーム全体に対する処理内容や、フォームと関連する
他のフォームのコールなどを行う。

【００５９】図６に示す例では、フォームをフォーム提
供システムから受信し、フォームのフィールドにデータ
を格納して所定の送付先に送信するフォーム実行装置
（フォーム送信端末）３は、フォーム提供システム９か
ら送信されるフォームを受信するフォーム受信部３１
と、このフォーム受信部３１にて受信したフォームに与
えられるイベントを検出するイベント検出部３２と、こ
のイベント検出部３２によって検出されたイベントと当
該イベントの対象となるフィールドとに応じて前記フィ
ールドスクリプトにて予め定義された動作を実行するフ
ィールドスクリプト実行部３６と、フォーム全体に対し
て実行可能な操作（例えば、操作用のタグやボタン）を
前記フォームスクリプトに基づいて当該フォームと関連
させて表示すると共に当該表示への操作に応じて当該フ
ォームスクリプトを実行するフォームスクリプト実行部
３４とを備えている。

【００６０】フィールドスクリプトは、フォームの中に
あるフィールド（項目）に対する処理の定義であり、一
般的にはイベントが検出されたときにそのスクリプトに
よる処理を実行する。スクリプトにより実行する内容
を、ここではフィールドアクション（商標）と呼ぶ。イ
ベントの種類としては、「クリック」や、「作成指令の
受信」や、「タブの操作」や、「関連するフィールドス
クリプトによる起動」などである。

【００６１】フィールドアクションの種類としては、入
力されるデータに関連したデータ検索及び表示の制御
や、他のフィールドや別のファイルに登録されたデータ
に基づいて当該フィールドの値を計算するための計算式
や、認証のチェックなどである。また、入力されるデー
タのデータ型や表現形式のチェックを行うようにしても
良い。データの検索では、例えば住所が入力された場合
に所定の情報提供サーバから当該住所に応じた地図の検
索を行う。計算式では、２カ所の住所からその２カ所間
の移動に必要な時間を算出するために所定の情報提供サ
ーバを駆動する。また、表計算ソフトウエアでのセルの
参照による計算式のように、他のフィールドに入力され
た値に基づいてフィールドの値を算出するための計算式
でも良い。

【００６２】フォームスクリプトは、そのフォームに記
録されている情報のハンドリング等の定義をいい、イベ
ント毎に実行される。イベントの種類としては、フォー
ムのテンプレート（フィールドにデータが登録されてい
ないフォーム）の受信や、フィールドにデータが登録さ
れたフォームの受信や、受信したフォームの認証結果
や、受信してからの経過時間などである。フォームスク
リプトによるフォームアクションは、主に、フォームと
フォームの関連づけや、フォームとデータベースとの関
連づけなどに用いると良い。

【００６３】フォームスクリプト及びフィールドスクリ
プトは、当該フォームにアクセスするユーザ別に異なる
動作を行うように分岐を定義しても良い。例えば、関連
フォームの一覧を行うフォームスクリプトでは、作成者
である応募者がフォームにアクセスする場合には「職務
経歴書」や「封筒」等のフォームとの関連を表示し、一
方、受信者である募集者側ではその募集組織内の情報シ
ステムへのデータの登録手順を実行するようにしても良
い。

【００６４】また、フォームをＸＭＬ等のデータ駆動型
の記述を用いる場合には、人に送信するフォームのみな
らず、コンピュータや周辺機器やＯＡ機器に送信するフ
ォームを用いても良い。例えば、チェックシートなどを
当該機器に送信し、機器内部のチェック機能を用いてチ
ェックを行い、自動返信するようにしても良い。すなわ
ち、従来保守担当者が使用していた帳票をフォームと
し、各項目別に機器の確認用のフィールドスクリプトを
定義する。そして、ネットワークに接続された機器に保
守用のフォームを送信し、機器側でフィールドに値を格
納した後、保守担当者へ送り返す。また、ファームウエ
アのアップグレードなどは、「修理依頼書」フォームに
ファームウエア・ファイルを添付することで自動的に行
うようにしても良い。このようなフォームを用いた機器
の保守システムの開発では、現在使用している帳票をフ
ォーム化し、続いて各フィールド毎にスクリプトを定義
する手順で開発することができるため、保守用のチェッ
クシート等を用いた経験をそのまま保守システムに活用
し易くなる。

【００６５】図７は給与支払明細書フォームを例として
フォームスクリプト及びフィールドスクリプトの具体例
を説明する説明図である。給与支払明細フォームは、出
願人によって広く市販されている帳票であり、その品番
はシン-１１３である。「読込」、「計算」、「封入」
はフォームスクリプト及びフィールドスクリプトによる
操作用のタブ１１Ｂである。宛先フィールド１３Ａや、
労働日数フィールド１３Ｂ等のフィールドの内容は、勤
務表ＤＢや勤務表フォームから読み込むことができる。
差引支給額フィールド１３Ｃについては、支給額と控除
額とからフィールドスクリプトを用いて算出することが
できる。事業所名等については、フォーム認証局による
本人の証明書を取得するようにしても良い。この証明書
の取得に必要なフォーム認証局との通信手順に関して
も、フィールドスクリプトとして定義することができ
る。

【００６６】図７に示す例では、給与支払明細フォーム
１１Ａを封筒フォーム１１Ｃに封入して送信する。封筒
は、便せんや帳票の内容を封筒の受取人が開封するまで
秘匿する役割を果たす。この現実の封筒の役割に着目し
て、給与支払明細フォームの暗号化を封筒への封入とい
うユーザ・インタフェースで実現する。封筒の鍵マーク
１３Ｆは内容物を暗号化したことを表す。また、この鍵
フィールドを操作することで暗号処理に必要なフィール
ドスクリプトを呼び出す。また、在中フィールド１３Ｉ
には、封入したフォームの名称が示される。この封筒に
封入したフォームは、封筒フォームと共に宛先１３Ｈに
送信される。給与支払明細フォームのフォームスクリプ
トとして他のフォームの連動が定義されている場合、例
えば、現金振込票フォームや出金伝票フォームがワーク
フロー関連データとして定義されている場合には、給与
支払明細フォームの作成又は送信に伴って、出金伝票フ
ォーム等の特定処理に移行する。

【００６７】上述したように本実施形態によると、フィ
ールドスクリプト及びフォームスクリプトとを用いるこ
とで、不可視のデータをフォームに埋め込み、また、本
来データ送受信用のユーザインタフェースであるフォー
ムに計算式等を埋め込むことができ、さらに、フォーム
間の関連などをフォームスクリプトを用いて定義し、ま
た証明書の要求等をフィールドスクリプトを用いて自動
化することができる。これらにより、電子帳票でーるフ
ォームの利便性がより一層向上する。

【００６８】＜第１実施例＞次に、履歴書フォームを例
とする第１実施例を説明する。従来より、就職活動に際
しては、応募者の経歴や志望動機等の情報を応募者から
募集企業へ伝達するのに履歴書が用いられている。履歴
書は、応募の第一段階で郵送したり、また、面談時に採
用担当者へ手渡す等して応募者から募集企業へ送付され
ている。募集希望側では、応募者が多数の場合、大量の
履歴書の整理及び管理を行い、多数の採用関係者へ閲覧
している。本実施例では、上述した各実施形態の手法を
用いてこの履歴書及び履歴書周辺の帳票（例えば、職務
経歴書等）を電子化し、応募者から募集主体へ履歴書フ
ォーム等をネットワークを介して送信する。

【００６９】図８は、本実施例での履歴書フォーム提供
システムの構成例を示すブロック図である。履歴書フォ
ームは、応募者端末１Ｃから募集者端末１Ｄにネットワ
ーク８を介して送信される。この履歴書フォームは、ま
ず、履歴書フォーム提供システムから応募者端末１Ｃに
提供される。図８に示す例では、履歴書フォーム提供シ
ステムは、履歴書の各項目に対応したフィールドと、当
該項目の配置を履歴書の帳票用紙と同様とするためのス
タイルデータとを有する履歴書フォームを記憶した履歴
書フォーム記憶部４０と、ネットワーク８を介して端末
と接続され当該端末からの要求に応じて前記履歴書フォ
ーム記憶部４０に格納された履歴書フォームを当該端末
に送信する履歴書フォーム送信部４２と、この履歴書フ
ォーム送信部４２から送信され前記端末にて編集された
履歴書フォームの記載内容の一部の正当性を認証する一
又は複数の認証局４６，４８，５０とを備えている。

【００７０】また、履歴書フォーム記憶部４０が、前記
履歴書フォームの各フィールド毎に当該履歴書フォーム
へデータを登録する履歴書作成者の端末又は当該作成さ
れた履歴書フォームを受信する履歴書使用者の端末にて
生じるイベントに応じて実行されるフォームスクリプト
を記憶すると良い。このフォームスクリプトは、例え
ば、履歴書使用者（募集側）によって予め定められた種
類のデータ入力を促すスクリプトである。この場合、履
歴書フォーム記憶部４０は、募集者毎にフィールドやス
クリプトが設計された履歴書フォームを記憶する。そし
て、履歴書フォーム送信部４２は、応募者端末１Ｃから
の操作に応じて募集者別の履歴書フォームを当該応募者
端末１Ｃに送信する。また、履歴書フォームの送信に関
しても、図７に示す給与支払明細と同様に、封筒フォー
ムを用いて応募者から募集者へ送信するようにしても良
い。

【００７１】図８に示す例では、応募者端末１Ｃは、複
数の認証局とネットワークを介して接続されている。認
証局としては、氏名と使用コンピュータＩＤ又はメール
アドレスとの関係を証明することで送信者が本人である
ことを証明する本人認証局４６や、経歴の一部を証明す
る経歴認証局４８や、氏名と現住所の関係を証明する現
住所認証局５０などがある。本人認証局４６は、当該応
募者にメールアドレス又はログインＩＤを提供した主体
や、認証サービスを行う主体によって管理できる。経歴
認証局４８は、例えば、応募者が新卒である場合、現在
在籍している学校がその応募者の経歴の一部を証明する
ことができる。また、中途採用の場合には、退職した勤
務先から退職証明を得ることで、応募者の経歴の一部を
証明することができる。現住所認証局は、例えば、住民
票を発行する自治体などによって管理される。これらの
場合、履歴書フォームの一部のフィールドの内容を各認
証局が個別に証明する。

【００７２】また、履歴書フォーム提供サーバは、フォ
ームのスキーマを定義したフォームのテンプレートを提
供者のサーバから応募者端末に提供するようにしても良
いし、また、例えば大学固有の履歴書フォームを用いる
場合には、大学によって管理されるサーバから提供する
ようにしても良い。大学固有の履歴書フォームの場合に
は、そのフォーム内に大学によるデジタル署名を付加す
ると良い。また、募集者が特定の質問項目等を用意し、
また募集者社内の情報システムとの関連を予め定義した
履歴書フォームの使用を応募者に要望する例では、履歴
書フォームは募集者向けにカスタマイズされ、募集者に
よって応募者へ提供される。

【００７３】図９は、履歴書フォームのスタイル例を示
す説明図である。図９では、履歴書の片面側のみを開示
している。個人名前フィールド１０２に漢字で氏名を記
載する場合には、名前の入力からふりがなを自動生成で
きる。この場合、個人名前フィールド１０２又はふりが
なフィールド１０１にこのふりがなの自動生成及び登録
の手順をフィールドスクリプトとして記載する。同様の
入力支援としては、郵便番号フィールドに郵便番号が入
力されると、この郵便番号によって特定できる住所を自
動生成する。また、生年月日が入力された場合に、小中
学校の入学及び卒業年度を算出するフィールドスクリプ
トを用意しても良い。算出した年度は、経歴の年フィー
ルド１０４や月フィールド１０５に格納する。写真貼付
フィールド１０８には、イメージファイルへのリンクを
格納する。また、電話フィールドに、可視的又は不可視
的に携帯電話番号や電子メールアドレス等を格納するよ
うにしても良い。

【００７４】通勤時間の記述についても、例えば交通機
関の経路探索サービスを行っている情報提供サーバにア
クセスし、現住所近傍の駅から勤務先近傍の駅までの通
勤時間を取得するようにしても良い。この通勤時間を情
報提供サービスから取得する例では、通勤時間フィール
ドの記載内容を当該情報提供者が証明していることとな
る。

【００７５】資格や免許については、文字での記述は多
数の応募者が統一した形式で記載するとは限らないた
め、募集者側で利用しやすくするために、資格や免許の
一覧を表示し、チェックボックスへのチェックで免許等
を特定するようにしても良い。また、運転免許証等の発
行主体から当該免許の内容の証明を得るようにしても良
い。本人希望欄などにつていては、募集企業側が特に知
りたい内容を予めフォームに提供するようにしても良
い。

【００７６】図１０は、履歴書フォームの構造を示す説
明図である。図１０（Ａ）は一つのフィールドでのツリ
ー構造を示す図で、図１０（Ｂ）はこのツリー構造をＸ
ＭＬのタグとして表現した例を示す図で、図１０（Ｃ）
はフィールドスクリプトの例である。ここでは、フィー
ルドの構成をＸＭＬを用いて定義している。各タグにつ
いては、フォーム提供サーバにて管理するスキーマを参
照することでその属性や役割をシステム的に取得するこ
とができる。好ましくは、例えば「個人氏名」を示すタ
グは各種のフォームで統一すると良い。統一されたフィ
ールド定義を複数のフォームで利用することで、フォー
ム間のデータ転送や、データベースに対するデータ項目
の読出及び更新が容易となる。また、履歴書フォームの
「個人氏名」フィールドは、封筒フォームでの「送信
者」フィールドとなる。このようなフォーム間のタグの
関係や、また、ＤＢでの項目名との関係などは、ＸＳＬ
Ｔに定義しておくことでフォーム間又はフォームとデー
タベース間でデータ項目のマッチングを行うことができ
る。

【００７７】図１１は、応募者が募集者へ履歴書を送信
する処理の一例を示すフローチャートである。図１１に
示すように、応募者は、まず、図８に示す履歴書フォー
ム記憶部４０から図９に示すような履歴書フォームを受
信する（ステップＳ４１）。この履歴書フォームは、一
時的に応募者端末１Ｃに蓄積される。続いて、応募者
は、応募者端末１Ｃを用いて、履歴書フォームの応募者
スクリプトによる入力支援に従って各フィールドにデー
タを格納する（ステップＳ４２）。続いて、図８に示す
本人認証局４６に対して応募者の氏名と電子メール等と
の関係の証明書を要求し、受信する（ステップＳ４
３）。同様に、経歴認証局４６から学歴等の証明書を受
信し（ステップＳ４４）、現住所認証局５０から氏名と
現住所の関係についての証明書を受信する（ステップＳ
４５）。続いて、応募者は、応募者端末１Ｃでのグラフ
ィカル・ユーザ・インタフェースを用いて履歴書フォー
ムを封筒フォームに封入する操作を行う。すると、封筒
フォームのフォームスクリプトが起動し、この履歴書フ
ォームを暗号化する（ステップＳ４７）。このとき、募
集者の公開鍵で暗号化すると、募集者以外によってこの
封筒が開封されることを防止することができる。続い
て、封筒フォームのフォームスクリプトに従って当該履
歴書フォームを添付した封筒フォームを募集者へ送信す
る（ステップＳ４８）

【００７８】＜第２実施例＞次に、財務会計などに使用
する伝票類の発行を例として本発明の第２実施例を説明
する。図１２は本実施例の構成例を示すブロック図であ
る。図１２に示すように、電子帳票発行システム６０
は、各種伝票等の帳票の項目に応じたフィールドと当該
帳票のレイアウトを指定するスタイルデータとを有する
一又は複数のフォームを記憶したフォームＤＢ６４と、
ネットワークを介して接続された端末からフォームを要
求された場合に当該端末からの要求に応じて当該フォー
ム又は当該フォームのフィールドの属性情報を編集する
フォーム属性編集部６２と、このフォーム属性編集部に
よって属性が編集されたフォームを当該端末に送信する
フォーム送信部６０とを備えている。このようなフォー
ムによる電子帳票としては、出金伝票フォームや、入金
伝票フォームや、振替伝票フォームや、勤務表フォーム
などが該当する。出金伝票フォームは、例えば購買担当
者によって発行され、会計管理部門に送信される。

【００７９】フォーム属性編集部６２は、フォームの属
性を編集する。フォームの属性としては、例えば、フォ
ームの発行日時や、フォームに付される連続番号の番号
や、フォームの発行者の個人氏名や部門の名称や、これ
らの証明書の添付や、発行するフォームとワークフロー
関係にあるフォーム名などである。電子帳票発行システ
ム６０側でこれらのフォームの属性情報を付すること
で、そのフォームの記述内容に関する客観性を向上させ
ることができる。フォームの属性情報は、フォームのフ
ィールドの一部でも良いし、また、フィールドスクリプ
ト等の不可視の埋め込みデータでも良い。フォーム属性
編集部６２は、例えば、フォーム送信部による帳票の送
信履歴に基づいて当該帳票に連続番号を付する連番付与
機能６２Ａを備える。

【００８０】図１２に示す例では、電子帳票発行システ
ム６０は、フォーム属性編集部６２によって編集された
フォームの原本性を認証する認証部６８を備える。この
認証部によって市販の伝票を使用するのと同様のイメー
ジで記帳作業等を行いつつ、偽造や改ざんの可能性を排
した状態で電子的に帳簿類を保存することができる。

【００８１】次に、領収書を代行発行する領収書フォー
ム発行システムについて説明する。従来より、商品やサ
ービスの対価として現金の授受があったときに、現金を
領収した側がその領収書の証明として現金の支払をした
側に発行する。ＰＯＳシステムが浸透したことで、領収
書の役割をレシートで代替することもあるが、組織の購
買、会計制度や、購入金額によっては、宛先を明記した
領収書を必要とすることもある。また、Ｗｅｂサイトを
用いた商品やサービスの提供などでは、カード決済や代
金引換配送が多く、市販されているような領収書帳票で
の領収書の発行はなされていないことが多い。

【００８２】大型の販売店では、宛先を手書きした領収
書の発行のために専門のカウンターと人員と設け、顧客
からＰＯＳシステムでのレシートを受け取り、手書きの
領収書を発行している。また、病院等では、診療を受け
た人々に宛先を明記した領収書の発行を行うための事務
担当者が存在せず、レシートをそのまま使用して欲しい
旨の説明が繰り返されていることもある。

【００８３】本実施例では、上述した実施形態に開示し
た手法を用いて、領収書の発行を行う。具体的には、領
収書フォームを用いて手書きの領収書と同様の効果を実
現する。図１３に示す例では、領収書フォーム発行シス
テムは、領収書の項目に応じたフィールドと当該領収書
のレイアウトを指定するスタイルデータとを有する領収
書フォームを記憶した領収書フォーム記憶部７４と、ネ
ットワーク８を介して接続された販売者端末から領収書
フォームの発行を要求された場合に当該販売者端末から
取得する領収金額データ及び領収書受取人を前記フィー
ルドに格納する領収書フォーム属性編集部７２と、この
領収書フォーム属性編集部７２によって編集された領収
書フォームを前記領収書受取人の端末へ送信する領収書
フォーム送信部７８とを備えている。

【００８４】領収書の発行者（商品の販売店やサービス
の提供者）は、売上に対する対価を領収したことについ
て、領収書フォームを発行する。領収書記憶部７４は、
市販の領収書と同様のスタイルの領収書フォームや、領
収書発行者の名称等を付した名入れの領収書フォーム
や、領収書発行者の事務管理に必要な項目等を付加した
特別のスタイル（レイアウト）の領収書フォームを記憶
する。領収書フォーム属性編集部７２は、領収書フォー
ムの発行主体のＩＤ等に応じて、使用する領収書フォー
ムを特定する。

【００８５】領収書フォーム属性編集部７２は、領収書
発行主体から領収金額データと領収書受領人に関するデ
ータとを受信し、これらのデータを領収書フォームの所
定のフィールドに格納する。売上管理システムやＰＯＳ
システムなどを構築している領収書発行主体は、この売
上管理システムに売上金額を登録する際に領収金額を領
収書フォーム発行システムに送信すると良い。また、顧
客に顧客ＩＤを付し、顧客情報を管理している販売店
や、電子カルテシステムを構築している病院であれば、
この顧客情報のうち個人氏名又は名称や、但し書きに記
載する商品名又はサービス名等の領収書発行に必要なデ
ータを領収書システム側に送信することができる。ま
た、領収書フォーム発行システムから受信する領収書フ
ォームに個別に入力するようにしても良い。

【００８６】領収書フォーム属性編集部７２は、前記販
売者端末との送受信の履歴に基づいて当該販売者名義で
発行する領収書フォームに連続番号を付する連番付与機
能７２Ａを備えると良い。この連続番号を領収書に付す
ることにより、偽造や不正使用の可能性を減少させ、ま
た、領収書フォームの発行者と受領者間にて複写式の領
収書を有しているのと同様の効果を得ることができる。

【００８７】領収書フォームの送受信には、種々の態様
がある。例えば、領収書受信者が販売店から付与された
顧客ＩＤを有しているとする。領収書発行者がＷｅｂサ
ーバを有する場合には、この顧客ＩＤ向けのページに領
収書フォームを登録しておき、この領収書フォームへの
アクセス権を当該顧客ＩＤを有する領収書受領者（デー
タの受信者）のみに許可しても良い。また、領収書受領
者が、領収書発行者と領収書フォーム発行システムとの
双方からユーザＩＤを取得しているとする。この場合、
領収書フォーム発行システムでの各ユーザ別のページ
（または領域）に複数の販売店から発行された領収書フ
ォームを登録しておくようにしても良い。すると、領収
書受領者は、例えば一週間に購入した商品又はサービス
に簡単にアクセスすることができる。また、Ｗｅｂサイ
トを用いた通信販売などでは、領収書フォームを電子メ
ールに添付して送信するようにしても良い。また、領収
書発行システムを用いて領収書を印刷し、郵送するよう
にしても良い。この場合、表面が領収書で、裏面が郵便
ハガキとなる領収書用紙（例えば、出願人製造のウケ-
７９Ｎなど）を用いることができる。

【００８８】また、領収書フォーム発行システム７０
は、領収書フォーム属性編集部７４によって編集された
領収書フォームの原本性を認証する領収書フォーム認証
部７６を備えると良い。領収書の原本性の証明は、発行
者と、領収金額と、その取引を特定するための情報とに
デジタル署名を行えば良い。まず、領収書発行者の名称
と領収書発行要求を行ったコンピュータの関係を証明す
る。領収金額や領収書受領者の情報は領収書発行者が正
当性を保証すべきであるため、領収書フォーム発行シス
テムにてその内容の証明を行う必要性は低い。一方、例
えば領収書の発行年月日が正当であることの証明の一助
として、一定周期で領収書フォーム発行サイトにて各領
収書に付する領収書フォーム番号を変更し、その領収書
フォーム番号と当該領収書フォームの提供時期との関係
を証明可能な状態としても良い。この証明書番号は、領
収書フォーム認証部の秘密鍵でデジタル署名すると良
い。なお、この領収書フォームは、電子帳票保存法によ
って電子的な保存が可能な対象となると考えられる。

【００８９】図１４は、領収書フォーム提供サーバを使
用して領収書フォームを領収書受領者に発行する領収書
発行処理の一例を示すフローチャートである。まず、領
収書発行者は、前記領収書フォーム提供サーバに領収書
フォームを要求する（領収書フォーム要求工程Ｓ５
１）。続いて、領収書フォーム提供サーバは、前記領収
書発行者によって使用される端末へ領収書フォームを提
供する（領収書フォーム提供工程Ｓ５２）。続いて、領
収書発行者は、受信した領収書フォームの領収金額フィ
ールドに領収金額を登録する（領収金額登録工程Ｓ５
３）。そして、領収書発行者が領収書受領者名を登録す
る（領収書受領者名登録工程Ｓ５４）。このとき、但し
書きや領収書発行側の売上伝票フォーム番号等を記述す
るようにしても良い。

【００９０】さらに、当該領収金額及び領収書受領者名
を登録した領収書フォームに連続番号となる領収書発行
番号を登録する（連続番号付与工程Ｓ５５）。続いて、
この領収書発行番号が付与された領収書フォームの原本
性を証明するための処理を行う（証明処理工程Ｓ５
６）。さらに、この証明処理工程にて原本性が証明され
る状態で当該領収書フォームを前記領収書受領者によっ
て使用される端末へ送信する（領収書フォーム送信工程
Ｓ５７）。

【００９１】図１５は領収書フォームの一例を示す説明
図である。図１５（Ａ）に示す例では、カーボンによる
複写ではなく、領収書発行側控え領域１１０と、領収書
領域１１２とで同一の項目を別途記述する様式となって
いる。複写性の証明については、領収書受領側と領収書
発行側とでその表示スタイルが異なる。また、図１５
（Ａ）に示す実際の帳票用紙では、詳細な印刷を行うこ
とで用紙自体の偽造を防止している。この機能を電子的
な領収フォームで実現するには、イメージ部分１１４
に、著作権の表示等に利用される識別番号の埋め込みを
行うと良い。すると、その画像の偽造を防止することが
できる。符号１１６で示す部分は、連続番号フィールド
である。図１５（Ｂ）に示すレイアウトは、比較的少額
の取引にて用いられる領収書で、連続番号を付さない。
このような領収書フォームでは、単純に宛名と領収金額
と但し書きとを記述すれば良い。

【００９２】

【発明の効果】本発明は以上のように構成され機能する
ので、これによると、請求項１記載の発明では、アクセ
ス許可工程にて、フィールドにデータが格納された後に
当該フォームの各フィールドデータを一群の情報として
当該フォームの送り先へアクセスを許可することで、帳
票に手書きして情報を伝達するのと同様な手順及び思考
でデータの送信を行うことができ、多種多様なデータ項
目を個別に管理する必要がなくなり、また、フォームに
含まれるフィールドの内容を一体的なデータとして扱う
と、秘匿が必要なデータを格納した組織内の又は個人的
なデータベースを万人にとって理解しやすく且つ操作ミ
スを生じさせにくい状態で利用することができ、データ
ベースへのアクセス権の付与をデータの送信と同様と考
えると、フォームを単位としたアクセス権の変更を行う
ことで、情報の送り元から送り先へフォームの目的に沿
った一群のデータを提供することができ、これにより、
意思の表明や情報の提供者側にとって判りやすく、ま
た、情報の受信側にとっても利用しやすい状態でデータ
を送信することができる、という従来にない優れたデー
タ送信方法を提供することができる。

【図面の簡単な説明】

【図１】本発明の第１実施形態によるデータ送信方法の
構成例を示すフローチャートである。

【図２】本発明の第１実施形態によるデータ受信方法の
構成例を示すフローチャートである。

【図３】本発明の第１実施形態によるフォーム提供シス
テムの構成例を示すブロック図である。

【図４】本発明の第２実施形態による認証局の構成例を
示すブロック図である。

【図５】図４に示した構成での認証処理の一例を示すフ
ローチャートである。

【図６】本発明の第３実施形態によるフォーム実行装置
等の構成例を示すブロック図である。

【図７】第３実施形態でのフォームスクリプト及びフィ
ールドスクリプトの一例を示す説明図である。

【図８】本発明の第１実施例による履歴書フォーム提供
システムの構成例を示すブロック図である。

【図９】図８に示す第１実施例で使用する履歴書フォー
ム及びフィールドスクリプトの一例を示す説明図であ
る。

【図１０】図８に示す第１実施例で使用する履歴書フォ
ームのデータ例を示す説明図であり、図１０（Ａ）は履
歴書フォームのフィールド構造例を示す図で、図１０
（Ｂ）はこのフィールド構造をＸＭＬのタグとして定義
した例を示す図で、図１０（Ｃ）はフィールドスクリプ
トの記述例を示す図である。

【図１１】図８に示す第１実施例で使用する履歴書送信
処理の一例を示すフローチャートである。

【図１２】本発明の第２実施例での電子帳票発行システ
ムの構成例を示すブロック図である。

【図１３】本発明の第２実施例での履歴書発行システム
の構成例を示すブロック図である。

【図１４】図１３に示す履歴書発行システムを用いた履
歴書発行処理の一例を示すフローチャートである。

【図１５】図１５（Ａ）及び（Ｂ）は図１３に示す領収
書発行システムで用いる領収書のスタイルの一例を示す
図である。

【符号の説明】

１端末８ネットワーク（例えば、インターネット）１０フォーム提供サーバ１２フォームデータベース（フォームＤＢ）１４通信制御部１６認証部１８フォーム発行者ＤＢ

フロントページの続き (72)発明者川口栄一大阪市東成区大今里南６丁目１番１号コクヨ株式会社内 (72)発明者安永哲郎大阪市東成区大今里南６丁目１番１号コクヨ株式会社内

Claims

【特許請求の範囲】

【請求項１】予め定められた項目のデータをそれぞれ
保持する複数のフィールド及びこれら各フィールドの表
示用の配置関係を指定するスタイルデータを有する一又
は複数のフォームを登録したフォームデータベースと、
前記フォームのフィールド名と関連した各項目のデータ
を登録した一又は複数の項目別データベースとを使用し
て情報を送り先へ送信するデータ送信方法であって、前記フォームデータベースに登録されたフォームを送信
用に特定するフォーム特定工程と、このフォーム特定工
程にて特定されたフォームを前記スタイルデータに従っ
て表示するフォーム表示工程と、前記フォーム特定工程
にて特定されたフォームの各フィールドのうち当該フィ
ールド名と関連した項目のデータを前記項目別データベ
ースから抽出すると共に当該抽出されたデータを当該フ
ィールドに格納するフィールドデータ抽出工程と、各フ
ィールドにデータが格納された後に当該フォームの各フ
ィールドデータを一群の情報として当該フォームの送り
先へアクセスを許可するアクセス許可工程とを備えたこ
とを特徴とするデータ送信方法。
【請求項２】前記フィールドデータ抽出工程と前後し
て、前記項目別データベースにデータが登録されていな
い項目に関連するフィールドについてデータの入力を促
すと共に入力されるデータを当該フィールドに格納する
フィールドデータ入力工程を備えたことを特徴とする請
求項１記載のデータ送信方法。
【請求項３】予め定められた項目のデータをそれぞれ
保持する複数のフィールド及びこれら各フィールドの表
示用の配置関係を指定するスタイルデータを有する一又
は複数のフォームを登録したフォームデータベースと、
前記フォームのフィールド名と関連した各項目のデータ
を登録した一又は複数の項目別データベースとを使用し
て情報を送り元から受信するデータ受信方法であって、前記フォームデータベースに登録されたフォームを送信
用に特定するフォーム特定工程と、各フィールドにデー
タが格納された後に当該フォームの各フィールドデータ
を一群の情報として前記受信者のアクセス権を判定する
アクセス権判定工程と、前記フォーム特定工程にて特定
されたフォームの各フィールドのうち当該フィールド名
と関連した項目のデータを前記項目別データベースから
抽出すると共に当該抽出されたデータを当該フィールド
に格納するフィールドデータ抽出工程とを備えたことを
特徴とするデータ受信方法。
【請求項４】予め定められた項目のデータをそれぞれ
保持する複数のフィールド及びこれら各フィールドの表
示用の配置関係を指定するスタイルデータを有する複数
のフォームを登録したフォームデータベースと、ネット
ワークを介して接続された端末に前記フォームデータベ
ースに登録されたフォームデータを提供するフォーム提
供サーバとを備え、前記フォームデータベースが、主となるフォームが選択
された時に当該主フォームに関連する関連フォームを特
定するためのフォーム関連データを備えたことを特徴と
するフォーム提供システム。
【請求項５】前記フォームデータベースが、フォーム
作成者によってフォーム受信者へ向けて各フィールド毎
に記述される内容データを保持する内容フォームと、こ
の内容フォームの関連フォームとして当該内容フォーム
を前記フォーム作成者の端末から前記フォーム受信者の
端末へ転送するための転送用データを保持する通信フォ
ームとを備え、前記フォーム提供サーバが、前記内容フォームが要求さ
れた場合には当該内容フォームと当該内容フォームに関
連する通信フォームとを当該内容フォームを要求した端
末に送信するフォーム送信部を備えたことを特徴とする
請求項４記載のフォーム提供システム。
【請求項６】前記フォーム関連データが、前記フォー
ムを受信するフォーム作成者によってフォームが転送さ
れた後に当該フォームの受信者にて使用するフォームを
特定するワークフロー特定データであることを特徴とす
る請求項４記載のフォーム提供システム。
【請求項７】前記フォーム提供サーバが、提供するフ
ォームを他のフォームと識別するための不可視のデータ
を当該フォームに埋め込む不可視データ埋め込み部を備
えたことを特徴とする請求項５，６又は７記載のフォー
ム提供システム。
【請求項８】予め定められた項目のデータをそれぞれ
保持する複数のフィールド及びこれら各フィールドの表
示用の配置関係を指定するスタイルデータを有するフォ
ームを当該フォームの宛先となるフォーム受信端末に送
信するフォーム送信端末とネットワークを介して接続さ
れた通信制御部と、前記フォーム送信端末を使用するフ
ォーム発行者の情報を記憶したフォーム発行者データベ
ースと、前記フォーム送信端末にて送信予定のフォーム
の属性を前記フォーム発行者データベースに登録された
情報に基づいて前記通信制御部を介して認証する認証部
とを備えたことを特徴とするフォーム認証局。
【請求項９】前記認証部が、前記フォームに当該フォ
ームの発行者が本人であることの証明データを付加する
本人証明制御機能を備えたことを特徴とする請求項８記
載のフォーム認証局。
【請求項１０】前記認証部が、前記フォームに当該フ
ォームが原本であることの証明データを付加する原本証
明制御機能を備えたことを特徴とする請求項８記載のフ
ォーム認証局。
【請求項１１】前記認証部が、前記フォームに当該フ
ォームが原本の複写物であることの証明データを付加す
る複写証明制御機能を備えたことを特徴とする請求項８
記載のフォーム認証局
【請求項１２】前記認証部が、前記フォームに当該フ
ォームに含まれる全てのフィールドの内容の証明及び証
明者名を付加するフォーム別証明制御機能を備えたこと
を特徴とする請求項８記載のフォーム認証局。
【請求項１３】前記認証部が、前記フォームに当該フ
ォームの特定のフィールドの内容の証明及び証明者名を
付加するフィールド別証明制御機能を備えたことを特徴
とする請求項８記載のフォーム認証局。
【請求項１４】予め定められた項目のデータをそれぞ
れ保持する複数のフィールド及びこれら各フィールドの
表示用の配置関係を指定するスタイルデータを有するフ
ォームを当該フォームの宛先となるフォーム受信端末に
送信するフォーム送信端末とネットワークを介して接続
されたフォーム認証システムを使用して当該フォームを
認証するためのフォーム認証用プログラムであって、記
録媒体に格納され、当該フォーム認証用プログラムは前記フォーム認証シス
テムを動作させる指令として、前記フォーム送信端末を使用するフォーム発行者に関す
るデータを読み出すフォーム発行者データ読出指令と、
このフォーム発行者データ読出指令に応じて読み出され
るフォーム発行者データに基づいて前記フォーム送信端
末にて送信予定のフォームの属性を認証させる認証指令
とを備えたことを特徴とするフォーム認証用プログラ
ム。
【請求項１５】前記フォーム認証用プログラムが、前
記認証指令に応じてフォームの認証をした後に当該認証
結果を前記フォーム発行者データに登録させるフォーム
発行者データ更新指令を備えたことを特徴とする請求項
１４記載のフォーム認証用プログラム。
【請求項１６】予め定められた項目のデータをそれぞ
れ保持する複数のフィールド及びこれら各フィールドの
表示用の配置関係を指定するスタイルデータを有する複
数のフォームを登録したフォームデータベースと、ネッ
トワークを介して接続された端末に前記フォームデータ
ベースに登録されたフォームデータを提供するフォーム
提供サーバとを備え、前記フォームデータベースに登録された各フォームが、
当該フォームの各フィールド毎に当該フィールドに対し
て与えられるイベントに応じた動作を記述したフィール
ドスクリプトを備えたことを特徴とするフォーム提供シ
ステム。
【請求項１７】前記フォームデータベースに登録され
た各フォームが、当該フォームに対して与えられるイベ
ントに応じた動作を記述したフォームスクリプトを備え
たことを特徴とする請求項１６記載のフォーム提供シス
テム。
【請求項１８】予め定められた項目のデータをそれぞ
れ保持する複数のフィールドと、これら各フィールドの
表示用の配置関係を指定するスタイルデータと、各フィ
ールドに対して与えられるイベントに応じた動作を記述
したフィールドスクリプトとを備えたフォームを受信す
るフォーム受信部と、このフォーム受信部にて受信した
フォームに与えられるイベントを検出するイベント検出
部と、このイベント検出部によって検出されたイベント
と当該イベントの対象となるフィールドとに応じて前記
フィールドスクリプトにて予め定義された動作を実行す
るフィールドスクリプト実行部とを備えたことを特徴と
するフォーム実行装置。
【請求項１９】前記フォームが、当該フォームに対し
て与えられるイベントに応じた動作を記述したフォーム
スクリプトを備え、前記フォーム全体に対して実行可能な操作を前記フォー
ムスクリプトに基づいて当該フォームと関連させて表示
すると共に当該表示への操作に応じて当該フォームスク
リプトを実行するフォームスクリプト実行部を備えたこ
とを特徴とする請求項１８記載のフォーム実行装置。
【請求項２０】履歴書の各項目に対応したフィールド
と、当該項目の配置を履歴書の帳票用紙と同様とするた
めのスタイルデータとを有する履歴書フォームを記憶し
た履歴書フォーム記憶部と、ネットワークを介して端末
と接続され当該端末からの要求に応じて前記履歴書フォ
ーム記憶部に格納された履歴書フォームを当該端末に送
信する履歴書フォーム送信部とを備えると共に、この履歴書フォーム送信部から送信され前記端末にて編
集された履歴書フォームの記載内容の一部の正当性を認
証する一又は複数の認証局とを備えたことを特徴とする
履歴書フォーム提供システム。
【請求項２１】前記履歴書フォーム記憶部が、前記履
歴書フォームの各フィールド毎に当該履歴書フォームへ
データを登録する履歴書作成者の端末又は当該作成され
た履歴書フォームを受信する履歴書使用者の端末にて生
じるイベントに応じて実行されるフォームスクリプトを
記憶したことを特徴とする請求項２０記載の履歴書フォ
ーム提供システム。
【請求項２２】前記フォームスクリプトが、前記履歴
書使用者によって予め定められた種類のデータ入力を促
すスクリプトであることを特徴とする請求項２０記載の
履歴書フォーム提供システム。
【請求項２３】前記認証局は、前記履歴書作成者の氏
名が本人であることを証明する本人証明制御機能を備え
たことを特徴とする請求項２０又は２１記載の履歴書フ
ォーム提供システム。
【請求項２４】前記履歴書フォーム記憶部が、当該履
歴書の送り先フィールドと、封筒の形態を表示するため
のスタイルデータとを有する封筒フォームを記憶し、前記履歴書フォーム送信部は、前記履歴書作成者の端末
から履歴書フォームの送信が要求されたときには当該履
歴書フォームと前記封筒フォームとを関連させて送信す
ることを特徴とする請求項２０記載の履歴書フォーム提
供システム。
【請求項２５】各種伝票等の帳票の項目に応じたフィ
ールドと当該帳票のレイアウトを指定するスタイルデー
タとを有する一又は複数のフォームを記憶したフォーム
ＤＢと、ネットワークを介して接続された端末からフォ
ームを要求された場合に当該端末からの要求に応じて当
該フォーム又は当該フォームのフィールドの属性情報を
編集するフォーム属性編集部と、このフォーム属性編集
部によって属性が編集されたフォームを当該端末に送信
するフォーム送信部とを備えたことを特徴とする電子帳
票発行システム。
【請求項２６】前記フォーム属性編集部によって編集
されたフォームの原本性を認証する認証部を備えたこと
を特徴とする請求項２５記載の電子帳票発行システム。
【請求項２７】前記フォーム属性編集部が、前記フォ
ーム送信部による帳票の送信履歴に基づいて当該帳票に
連続番号を付する連番付与機能を備えたことを特徴とす
る請求項２５又は２６記載の電子帳票発行システム。
【請求項２８】領収書の項目に応じたフィールドと当
該領収書のレイアウトを指定するスタイルデータとを有
する領収書フォームを記憶した領収書フォーム記憶部
と、ネットワークを介して接続された販売者端末から領
収書フォームの発行を要求された場合に当該販売者端末
から取得する領収金額データ及び領収書受取人を前記フ
ィールドに格納する領収書フォーム属性編集部と、この
領収書フォーム属性編集部によって編集された領収書フ
ォームを前記領収書受取人の端末へ送信する領収書フォ
ーム送信部とを備えたことを特徴とする領収書フォーム
発行システム。
【請求項２９】前記領収書フォーム属性編集部によっ
て編集された領収書フォームの原本性を認証する領収書
フォーム認証部を備えたことを特徴とする請求項２８記
載の領収書フォーム発行システム。
【請求項３０】前記領収書フォーム属性編集部が、前
記販売者端末との送受信の履歴に基づいて当該販売者名
義で発行する領収書フォームに連続番号を付する連番付
与機能を備えたことを特徴とする請求項２８又は２９記
載の領収書フォーム発行システム。
【請求項３１】領収書の項目に応じたフィールドと当
該領収書のレイアウトを指定するスタイルデータとを有
する領収書フォームを提供する領収書フォーム提供サー
バを使用して領収書フォームを領収書受領者に発行する
領収書発行方法であって、領収書発行者が前記領収書フォーム提供サーバに領収書
フォームを要求する領収書フォーム要求工程と、前記領収書フォーム提供サーバが前記領収書発行者によ
って使用される端末へ領収書フォームを提供する領収書
フォーム提供工程と、前記領収書発行者が当該領収書フォームの領収金額フィ
ールドに領収金額を登録する領収金額登録工程と、前記領収書発行者が領収書受領者名を登録する領収書受
領者名登録工程と、当該領収金額及び領収書受領者名を登録した領収書フォ
ームに連続番号となる領収書発行番号を登録する連続番
号付与工程と、この領収書発行番号が付与された領収書フォームの原本
性を証明するための処理を行う証明処理工程と、この証明処理工程にて原本性が証明される状態で当該領
収書フォームを前記領収書受領者によって使用される端
末へ送信する領収書フォーム送信工程とを備えたことを
特徴とする領収書フォーム発行システム。