JP2000276554A - 要求受付システム、要求受付方法及びｏｃｒ帳票 - Google Patents

Abstract

(57)【要約】 【課題】 より迅速で正確な処理を行う要求受付システ
ム、要求受付方法及びＯＣＲ帳票を提供する。また、シ
ステムのセキュリティを確保する文書要求システムを提
供する。 【解決手段】 支社１５内には、要求用ファクシミリ１
０Ａ〜１０Ｃが設置される。 本社１７には、各ファク
シミリ１０Ａ〜１０Ｃからの要求をファクシミリ網１１
を介して受信して各種処理を行う受付端末２０と、受付
端末２０が処理した結果を集計する集計端末３０と、プ
リンタ４０と、受付内容の確認用のファクシミリ５０と
が設置される。２２はＯＣＲ認識部であり、モデム２１
が受信したＯＣＲ帳票に記入内容を、特定の文字として
認識する。２３は演算部であり、ＯＣＲ認識部２２が認
識した結果に基づき、要求内容を把握し、各種処理を行
う。ユーザＤＢ２４，基準書ＤＢ２５，受付内容ＤＢ３
１は、各々所定のデータを格納する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はＯＣＲ機能を用いた
要求受付システムに関する。

【０００２】

【従来の技術】会社等においては、本社の所轄部署が社
内に配布される各種文書（例えば、システムドキュメン
ト、マニュアル等）を一括管理しており、支社は、本社
に対して、希望する文書をファクシミリ等を用いて随時
要求している。その場合、支社の要求者は、専用のＯＣ
Ｒ帳票上に要求者名及び要求内容等を所定の方法に従っ
て記入し、そのＯＣＲ帳票を本社にファクシミリ送信す
る。本社に設置されたＯＣＲ装置は、ファクシミリ受信
したＯＣＲ帳票上の文字を認識し、その認識結果を出力
する。本社の要求受付担当者は、出力された認識結果の
内容を参照して、受付の可否（例えば、要求者の記入ミ
スやＯＣＲ装置の認識ミスの有無、また、要求者が社員
であるか否か、要求された文書は要求者に配布してもよ
いものか否か等）について判定する。そして、受付担当
者は、その判定結果を支社に通知すると共に、その判定
結果に応じた処理を行う。

【０００３】

【発明が解決しようとする課題】従来のシステムにおい
ては、要求者側は、文書の要求手続に際し、上記のＯＣ
Ｒ帳票を事前に用意しておかなければならないという煩
雑さがある。また、このＯＣＲ帳票は、ＯＣＲ認識の精
度を高める観点から、文字記入位置の目安が文字記載欄
内に極薄線により示されており、利用者がＯＣＲ帳票を
作成しようとしても、上記のような極薄線は通常のワー
ドプロセッサー等を用いても一般に作成できないという
問題がある。また、受付担当者は、受付の可否を目視や
手作業で判断しているため、その判断処理に時間がかか
るという問題がある。その結果、受付担当者から要求者
に対する受付可否通知も遅延する。

【０００４】さらに、要求者が社員（すなわち正当な要
求権利を持つ者）であるか否かの判断は、受信したＯＣ
Ｒ帳票に記入された要求者名（又は要求者識別符号）の
みに基づいて行われている。従って、不正な第三者（例
えば社外の人間等）が自らのファクシミリを用い、社員
の名前をかたって要求して社内文書を入手する可能性も
あり、システムの悪用を防止するというセキュリティ面
においても問題がある。

【０００５】本発明は、上述した事情に鑑みてなされた
ものであり、より簡便で正確な処理を行う要求受付シス
テム、要求受付方法及びＯＣＲ帳票を提供することを第
一の目的とする。また、本発明は、自動的に要求者の正
当性を判定することにより、システムのセキュリティを
確保する要求受付システム、要求受付方法及びＯＣＲ帳
票を提供することを第二の目的とする。

【０００６】

【課題を解決するための手段】上述した課題を解決する
ため、請求項１に記載の発明は、要求書送信装置と、送
信された要求書を受信し、前記要求書の受信イメージを
ＯＣＲ認識し、ＯＣＲ認識した結果を出力する要求書受
信装置と、前記要求書送信装置と前記要求書受信装置と
を中継する中継網とから成る要求受付システムにおい
て、前記要求書が受付可能となるための受付条件を記憶
する受付条件記憶手段と、前記ＯＣＲ認識の結果と前記
受付条件とを用いて、前記要求書の受付の可否を判定す
る受付可否判定手段とを具備することを特徴とする要求
受付システムを提供するものである。

【０００７】上述した課題を解決するため、請求項２に
記載の発明は、請求項１記載の要求受付システムにおい
て、前記受付の可否判定の結果を前記要求送信装置に通
知する結果通知手段を具備することを特徴とする要求受
付システムを提供するものである。

【０００８】上述した課題を解決するため、請求項３に
記載の発明は、請求項１記載の要求受付システムにおい
て、前記要求受付システムの利用が可能と認められた要
求者の識別符号と、前記要求者が使用すべき前記要求書
送信装置の通信のために用いられる通信識別符号とを対
にして記憶する識別符号記憶手段と、前記中継網から、
前記要求書を送信した前記要求書送信装置の通信識別符
号を取得する識別符号取得手段とを具備し、前記受付可
否判定手段は、ＯＣＲ認識された前記要求者の識別符号
と前記識別符号記憶手段が記憶する前記要求者識別符号
とが一致し、かつ、前記中継網から取得した前記要求書
送信装置の前記通信識別符号と前記識別符号記憶手段が
記憶する前記要求書送信装置の通信識別符号とが一致す
るか否かにより、受付の可否を判定することを特徴とす
る要求受付システムを提供するものである。

【０００９】上述した課題を解決するため、請求項４に
記載の発明は、請求項１記載の要求受付システムにおい
て、前記要求の対象物の識別符号である対象物識別符号
は、所定の関係を有する複数の数字により構成されてお
り、ＯＣＲ認識された前記対象物識別符号を構成する数
字が前記所定の関係を有するか否かを判定する関係判定
手段を具備し、前記受付条件記憶手段は、受付可能な前
記対象物識別符号を記憶し、前記受付可否判定手段は、
ＯＣＲ認識された対象物識別符号と同一の符号が前記受
付記憶手段により記憶されているか否かにより、受付可
否を判定し、前記結果通知手段は、前記受付可否判定手
段により受付不可と判定され、かつ、前記関係判定手段
により前記所定の関係があると判定された場合、前記要
求送信装置に、前記要求書を記入した者の記入ミスの旨
の通知を送信する要求受付システムを提供するものであ
る。

【００１０】上述した課題を解決するため、請求項５に
記載の発明は、要求書送信装置から送信された要求書を
受信し、前記要求書の受信イメージをＯＣＲ認識し、Ｏ
ＣＲ認識した結果を出力する要求受付方法において、前
記要求書が受付可能となるための受付条件と、前記ＯＣ
Ｒ認識の結果とを用いて、前記要求書の受付の可否を判
定する過程を具備することを特徴とする要求受付方法で
ある。

【００１１】上述した課題を解決するため、請求項６に
記載の発明は、請求項５記載の要求受付方法において、
前記受付の可否判定の結果を前記要求送信装置に送信す
る過程を具備することを特徴とする要求受付方法であ
る。

【００１２】上述した課題を解決するため、請求項７に
記載の発明は、請求項５記載の要求受付方法において、
ＯＣＲ認識された前記対象物識別符号を構成する数字が
前記所定の関係を有するか否かを判定する過程を具備
し、前記受付の可否を判定する過程は、ＯＣＲ認識され
た対象物識別符号が予め記憶されているか否かにより、
受付可否を判定し、前記結果を通知する過程は、前記受
付可否を判定する過程により受付不可と判定され、か
つ、前記関係を判定する過程により前記所定の関係があ
ると判定された場合、前記要求送信装置に、前記要求書
を記入した者の記入ミスの旨の通知を送信する請求項６
記載の要求受付方法である。

【００１３】上述した課題を解決するため、請求項８に
記載の発明は、請求項５記載の要求受付方法において、
要求者の識別符号と、前記要求者が使用すべき前記要求
書送信装置の通信のために用いられる通信識別符号とを
対にして記憶する過程と、前記中継網から、前記要求書
を送信した前記要求書送信装置の通信識別符号を取得す
る過程とを具備し、前記受付可否を判定する過程は、Ｏ
ＣＲ認識された前記要求者の識別符号と前記識別符号記
憶手段が記憶する前記要求者識別符号とが一致し、か
つ、前記中継網から取得した前記要求書送信装置の前記
通信識別符号と前記識別符号記憶手段が記憶する前記要
求書送信装置の通信識別符号とが一致するか否かによ
り、受付可否を判定することを特徴とする要求受付方法
である。

【００１４】上述した課題を解決するため、請求項９に
記載の発明は、請求項５６記載の要求受付方法に使用さ
れるＯＣＲ帳票であって、ＯＣＲ認識の対象となる所定
の位置に記載された記入枠と、ＯＣＲ認識の対象外とな
る位置に記載され、前記記入枠に記入する文字の位置を
示す記入位置目安とを具備し、そのため、文書作成装置
で作成可能なＯＣＲ帳票である。

【００１５】

【発明の実施の形態】[１．構成]図１に本発明の実施形
態である要求受付システムの機能構成を示す。なお、こ
のシステムで要求の対象物として「文書」を例に挙げて
説明するが、以下、「文書」を「基準書」と呼ぶものと
する。同図によると、支社１５内の各ユーザ１６Ａ〜１
６Ｃには、要求用ファクシミリ１０Ａ〜１０Ｃが設置さ
れる。これらのファクシミリ１０Ａ〜１０Ｃは、各種要
求を示すＯＣＲ帳票を本社１７へ送信したり、また、本
社１７から受付可否通知等の各種通知を受信したりす
る。

【００１６】本社１７には、各ファクシミリ１０Ａ〜１
０Ｃから送信されたＯＣＲ帳票の内容をファクシミリ網
１１を介して受信し、その内容に応じて各種処理を行う
受付端末２０が設置される。また、受付端末２０が受け
付けた内容を記憶・集計する集計端末３０と、集計端末
３０が集計した結果を出力するプリンタ４０と、本社１
７の受付担当者が支社１５からの要求内容を確認するた
めの確認用ファクシミリ５０とが設置される。この確認
用ファクシミリ５０は、本社１７の要求受付担当者が、
要求された内容を確認するためのものである。

【００１７】以下に、この基準書要求システムを構成す
る受付端末２０の各構成要素を説明する。２１はファク
シミリモデムであり、要求用ファクシミリ１０Ａ〜１０
Ｃが読み込んだＯＣＲ帳票の内容をファクシミリ網１１
を介して受信したり、また、要求用ファクシミリ１０Ａ
〜１０Ｃへ各種通知を送信したりする。２２はＯＣＲ認
識部であり、モデム２１が受信したＯＣＲ帳票の受信イ
メージを、文字として認識する。

【００１８】２３は演算部であり、ＯＣＲ認識部２２が
認識した結果に基づき、要求内容を判断し、各種処理を
行う。例えば、ＯＣＲ認識部の認識結果に従い、以下に
述べるデータベース２４及び２５を検索したり、所定の
データを登録したり、削除したりする。また、認識結果
と各ＤＢとの登録内容を参照して、様々な判定を行う。
また、各ファクシミリ１０Ａ〜１０Ｃに各種通知を送信
するようモデム２１に指示する。

【００１９】２４はユーザＤＢであり、各ユーザ１６Ａ
〜１６Ｃに関する属性情報を格納する。ここで、「ユー
ザ」とは、要求者の一単位となりうるものを指し、例え
ば、社内の各部署（営業部、総務部等）であってもよい
し、各関連会社であってもよいし、各社員であってもよ
い。本実施例では各部署を各ユーザとして説明する。

【００２０】このユーザＤＢ２４のファイル構成を、図
２を参照しながら説明する。同図によると、ユーザＤＢ
２４には、各ユーザ１６Ａ〜１６Ｃについての、このシ
ステムにおいて使用すべきファクシミリ番号、組織コー
ド、電話番号、組織名（会社名）、郵便番号、住所、ビ
ル名、担当者名（ユーザ名）、登録年月日（ユーザ属性
情報をこのユーザＤＢ２４に格納した年月日）等が格納
される。

【００２１】各ユーザ１６Ａ〜１６Ｃは基準書の要求を
行う場合、このユーザＤＢ２４に各ユーザについて登録
されているファクシミリを使用することが義務づけられ
る。もし、各ユーザ１６Ａ〜１６Ｃが登録されているフ
ァクシミリ以外のファクシミリを使用して要求を行った
場合、受付端末２０は、該要求の送信元のファクシミリ
に対してエラー通知を送信し、以後、処理は進行しない
ようになっている。

【００２２】２５は基準書属性ＤＢであり、本社１７が
管理する、全ての基準書の各々に関する属性情報を格納
する。基準書属性ＤＢのファイル構成を、図３を参照し
ながら説明する。同図によると、基準書属性ＤＢ２５に
は、各基準書についての、基準書番号、基準書名、版
数、倉庫位置、原紙枚数、販売価格、制定年月日、制定
組織、制定組織連絡番号、配布管理番号等が格納されて
いる。

【００２３】基準書番号とは、この基準書要求受付シス
テムを導入する会社内における、各基準書の識別番号で
ある。倉庫位置とは、各基準書を保管している倉庫の位
置を示す番号であり、基準書配布担当者は、この倉庫位
置を基に基準書配布の作業を行う。制定年月日とは、本
社１７が各ユーザ１６Ａ〜１６Ｃからの要求を受け付け
ることが可能となる年月日である、制定組織連絡番号と
は、各基準書を作成した組織（会社）の連絡番号（電話
番号）である。配布管理番号とは、各ユーザからの受付
が可能か否かを示す識別番号である。これは、基準書は
本社１７の管理下にあるが、各ユーザ１６Ａ〜１６Ｃへ
の配布ができる場合とできない場合があり、配布可の基
準書の配布管理番号には「１」が登録され、配布不可の
基準書の配布管理番号には「０」が登録される。要求受
付の際には、演算部２３は、基準書属性ＤＢ２５を検索
して配布管理番号を確認し、配布可の基準書に関する要
求のみを正常に受け付ける。

【００２４】集計端末３０は受付端末２０が各ユーザ１
６Ａ〜１６Ｃから受け付けた内容を取得し、受付内容Ｄ
Ｂ３１に格納する。また、集計端末３０は、受内容ＤＢ
３１を検索し、所定の期間内に受け付けた受付内容を集
計結果として抽出する。その集計結果はプリンタ４０に
送信され、出力される。

【００２５】この受付内容ＤＢ３１のファイル構成を、
図４を参照しながら説明する。同図によると、受付内容
ＤＢ２７には、受付番号、ファクシミリ番号、電話番
号、基準書番号、受付部数等が格納されている。

【００２６】受付番号とは、受付端末２０が要求を受け
付ける度に付される識別番号であり、例えば、受付端末
２０が受け付けた日時を示す数字により構成される。フ
ァクシミリ番号とは、要求を送信した要求用ファクシミ
リのファクシミリ番号である。モデム２１は要求の受信
の際にファクシミリ網１１から各ファクシミリ１０Ａ〜
１０Ｃのファクシミリ番号を取得するため、その取得し
たファクシミリ番号が、この受付内容ＤＢ３１に格納さ
れる。また、この要求受付システムは、一度のファクシ
ミリ送信で６種類の基準書の要求が可能であり、その基
準書の種類ごとに各々の基準書番号と部数とが格納され
る。

【００２７】次に、各基準書に付される基準書番号の構
成について図５を参照しながら説明する。同図による
と、基準書番号は７つの数字により構成されている。該
基準書番号の１桁目から６桁目までの数字群は、基準書
の各々に対して一意に付されたものである。そして、該
基準書番号の末尾（７桁目）の数字は、１〜６桁目の各
数字の総和の数の１の位の数字となっている。例えば、
図４においては、１〜６桁目の各数字の総和が「２１」
であり、その「２１」の１の位の数字は「１」が基準書
番号の末尾の数字となっている。この末尾の数字は、演
算部２３によるパリティチェックの為に用いられる。

【００２８】以下、パリティチェックについて詳述す
る。演算部２３によるパリティチェックとは、ＯＣＲ認
識部２２が認識した基準書番号において、１〜６桁目の
各数字の総和を計算し、その総和の一の位の数字とＯＣ
Ｒ認識された基準書番号の末尾数字とを比較して、その
両者の数字が一致しているか否か（一致していればＯＫ
一致していなければＮＧ）を判定することである。

【００２９】一方、演算部２３は基準書が要求された場
合、ＯＣＲ認識された基準書番号のを検索キーとして、
基準書属性ＤＢ２５を検索する。

【００３０】パリティチェックの結果と基準書属性ＤＢ
２５の検索結果とを用いると、以下のように判断するこ
とが可能である。「基準書識別番号有り」で「パリティ
チェックＯＫ」の場合、ＯＣＲ認識された基準書番号は
正しく認識されていると判断できる。また、「基準書識
別番号有り」で「パリティチェックＮＧ」の場合という
のはあり得ない。

【００３１】「基準書識別番号無し」で「パリティチェ
ックＮＧ」の場合（例えば、格納されている基準書番号
が「１２３４５６１」でＯＣＲ認識された基準書番号が
「１２３４５６２」のような場合）、要求者の記入ミス
又はＯＣＲ認識部２２の誤認識のいずれかが原因と考え
られる。しかし、そのどちらが真の原因かは判断できな
い。

【００３２】「基準書識別番号無し」で「パリティチェ
ックＯＫ」の場合（例えば、格納されている基準書番号
が「１２３４５６１」でＯＣＲ認識された基準書番号が
「１２３４５７２」のような場合）、ＯＣＲ認識部２２
の誤認識により「基準書識別番号無し」という結果にな
った可能性はきわめて低い。なぜなら、要求者が正しく
記入している基準書番号が誤認識され、その誤認識の結
果、基準書番号がパリティチェックをＯＫとなる可能性
は低いからである。

【００３３】例えば、要求者が「１２３４５６１」と正
しい基準書番号を記入しているのに、ＯＣＲ認識部２２
が「１２３４５７２」という誤認識をする場合を想定す
る。このような場合、ＯＣＲ認識部２２は、まず６桁目
の「６」という数字を「７」と誤認識すると、７桁目の
「１」を必ず「２」と誤認識しなければならない。この
ように、ＯＣＲ認識部２２が、７桁の基準書番号の各数
字の内の２つの数字を、結果としてパリティチェックＯ
Ｋとなるように誤認識する可能性はきわめて低いと考え
てよい。従って、要求者の記入ミスが「基準書番号無
し」の原因とほぼ断定できるので、その記入ミスのみを
解決すればよく、以後の処理が迅速に処理される。

【００３４】このシステムに用いられるＯＣＲ帳票は、
図６，図７，図８に示すように３種類ある。図６に、こ
のシステムにユーザ登録又は削除する場合に用いるＯＣ
Ｒ帳票を示す。各ユーザ１０Ａ〜１０Ｃは、基準書の要
求を行う際、事前にこのシステムにユーザ登録すること
が義務づけられる。帳票右上隅の４つの同数字群は各Ｏ
ＣＲ帳票の種別を表す数字である（以下帳票種別コード
と呼ぶ）。このユーザ登録又は削除の帳票については
「０」の帳票種別コードが付されており、そのコードを
４つ連ねた「００００」が予めＯＣＲ帳票に印刷されて
いる。

【００３５】ＯＣＲ認識部２２が帳票種別コードをＯＣ
Ｒ認識することにより、何の要求がされているかが判断
される。その際、ＯＣＲ認識部２２は、４つ連なった帳
票種別コードのうちを１つでも認識できれば、その認識
された帳票種別コードに従い、演算部２３は帳票の種別
を判断する。このようにすれば、帳票種別の認識不能と
いう事態が起こる可能性は低くなり、システムの信頼性
は向上する。これは図７及び図８においても同様であ
る。

【００３６】ユーザ登録／削除票において、要求者は、
まず、ユーザの登録又は削除のどちらの処理を行いたい
のかを「レ」印で指定し、以下、登録又は削除の対象と
なるユーザの、所定の組織コード、組織名（会社名）、
電話番号、ファクシミリ番号、基準書の送付先の郵便番
号、住所、ビル名、担当名（ユーザ名）、及び、ＯＣＲ
帳票の記入者名を記入する。

【００３７】図７に、本社１７に基準書を要求する場合
に用いるＯＣＲ帳票を示す。基準書要求のＯＣＲ帳票に
は「２」の帳票種別コードが付されており、「２２２
２」が予め印刷されている。記入者は、要求を行うユー
ザの組織コード、組織名、電話番号及び、要求する基準
書の基準書番号及び基準書名及び部数を記入する。これ
らの組織コード、組織名及び電話番号は全て事前のユー
ザ登録により登録したものを用いる。

【００３８】なお、このシステムのメイン処理となる基
準書要求の受付処理に際しては、組織コード及び電話番
号によりユーザが特定され、また、基準書番号により基
準書が特定されるため、記入者が組織コード、電話番号
及び基準書番号を正確に記入する（特に各文字を一定間
隔で記入する）ことが重要である。そのため、これらの
記載項目の記載欄の枠外には記入文字の間隔の目安とな
るつめ６０がある。記入者は、この各つめ６０を目安に
して、各文字が等間隔となるように、隣り合うつめとつ
めの間に記入する。そのように記入することにより、Ｏ
ＣＲ認識部２２の認識精度が向上する。なお、このつめ
は他の記載欄に設けられてもよい。

【００３９】また、このＯＣＲ帳票は、要求者等がワー
ドプロセッサ等の文書作成装置を用いて作成することが
可能である。なぜなら、各記載項目欄（組織コード、組
織名・・・等の記載欄）の位置及び寸法及び記載項目は
予めシステム設計者により規定されており、要求者等は
それらの規定に従い作成すればよいからである。さら
に、従来のように、文字記載欄内に極薄線による文字記
入目安が有るのではなく、文字記載欄外に濃線によるつ
め６０を作成すればよいからである。従って、要求者等
は専用のＯＣＲ帳票がない場合でも、自らで作成するこ
とができる。これは図６及び図８においても同様であ
る。

【００４０】図８に、本社１７に各種問い合わせを行う
場合に用いるＯＣＲ帳票を示す。問い合わせ用帳票には
「７」の帳票種別コードが付されており、「７７７７」
が予め印刷されている。要求者は、組織名、氏名、ファ
クシミリ番号、電話番号及び問い合わせ内容を記入す
る。問い合わせ内容は、例えば、希望する基準書が本社
１７で管理されているか否か等の問いあわせである。

【００４１】[２．動作]次に当該システムを使用した動
作例を図９を参照しながら説明する。ステップＳＰ１１
では、例えばユーザ１６Ａは、要求用ファクシミリ１０
Ａを用いて、要求する内容を記入したＯＣＲ帳票を本社
１７宛にファクシミリ送信する。ステップＳＰ１２で
は、受付端末２０のモデム２１は、ファクシミリ網１１
を介して該ＯＣＲ帳票を受信する。ステップＳＰ１３で
は、受付端末２０のＯＣＲ認識部２２は、受信されたＯ
ＣＲ帳票の内容を文字として認識する処理を行う。

【００４２】ステップＳＰ１４では、演算部２３は、ス
テップＳＰ１３のＯＣＲ認識処理の結果を取得し、ＯＣ
Ｒ帳票上の全ての文字が認識できたか否かの判定を行
う。この判定の結果、認識できていない文字があれば、
ステップＳＰ１５に進み、演算部２３は、モデム２１及
びファクシミリ網１１を介して、要求用ファクシミリ１
０Ａ及び確認用ファクシミリ５０に、認識できない文字
がある旨のエラー通知を送信する。エラー通知を受け取
ったユーザ１６Ａ及び本社１７の受付担当者は、文字の
確認、修正等の所定の作業を行う。ステップＳＰ１４の
判定の結果、全ての文字が認識できたと判定されると、
認識されたＯＣＲ帳票の帳票種別コードに応じて、ユー
ザ登録／削除処理、基準書要求処理、問い合わせ処理の
いずれかの処理に進む。

【００４３】ユーザ登録／削除処理の動作を、図１０を
参照しながら説明する。ステップＳＰ２１では、演算部
２３は、ＯＣＲ認識部２２による認識結果に基づき、要
求されている処理がユーザ登録か削除かを判定する。そ
の判定の結果、要求されている処理がユーザ登録であれ
ば、ステップＳＰ２２に進み、演算部２３は、組織コー
ド及び電話番号及びファクシミリ番号を検索キーとし
て、ユーザＤＢ２４を検索し、登録が要求されているユ
ーザが既に登録されているか否かを判定する。

【００４４】ステップＳＰ２２の判定の結果、該ユーザ
が既に登録されていれば、ステップＳＰ２３に進み、演
算部２３は、要求用ファクシミリ１６Ａに二重登録不可
の旨のエラー通知を送信する。ステップＳＰ２２の判定
の結果、該ユーザが登録されていなければ、ステップＳ
Ｐ２４に進み、演算部２３は、ＯＣＲ認識された内容を
ユーザ属性情報としてユーザＤＢ２４に格納する。

【００４５】格納処理が完了すると、ステップＳＰ２５
では、演算部２３は、要求用ファクシミリ１６Ａにユー
ザ登録完了の旨の結果通知を送信する。この結果通知
は、例えば、図１１に示すような通知である。ユーザ１
６Ａは、この結果通知により、ユーザ登録が正常に処理
されたことを確認することができる。

【００４６】一方、ステップＳＰ２１の判定の結果が、
ユーザの削除である場合は、ステップＳＰ２６に進み、
演算部２３は、組織コード及び電話番号及びファクシミ
リ番号を検索キーとしてユーザＤＢ２４を検索し、削除
が要求されているユーザの属性情報がユーザＤＢ２４に
格納されているか否かを判定する。

【００４７】その判定の結果、該当するユーザがなけれ
ば、ステップＳＰ２９に進み、演算部２３は、要求用フ
ァクシミリ１６Ａに、該当するユーザは登録されていな
い旨のエラー通知を送信する。また、ステップＳＰ２６
の判定の結果、該当するユーザの属性情報があれば、ス
テップＳＰ２７に進み、演算部２３は、ユーザＤＢ２４
に格納される該ユーザの属性情報を削除する。そして、
ステップＳＰ２８では、演算部２３は、要求用ファクシ
ミリ１６Ａにユーザ削除完了の旨の結果通知を送信す
る。この結果通知は、図１１に示す結果通知の「登録」
を「削除」に置き換えたような通知である。

【００４８】次に、基準書要求処理の動作を、図１２を
参照しながら説明する。ステップＳＰ３１では、演算部
２３は、ファクシミリ網１１から取得した要求用ファク
シミリ１６Ａのファクシミリ番号を検索キーにして、ユ
ーザＤＢ２４を検索する。ステップＳＰ３２では、検索
の結果、要求送信元のファクシミリ番号がユーザＤＢに
登録されているかいないかを判定する。

【００４９】その判定の結果、登録されていなければ、
ステップＳＰ３３に進み、演算部２３は、要求用ファク
シミリ１６Ａ及び確認証ファクシミリ５０にエラー通知
を送信する。このエラー通知は、例えば、図１３に示す
ような通知である。基準書を要求した者及び本社１７の
受付担当者は、この結果通知により、要求が受け付けら
れなかった理由を確認することができる。また、その判
定の結果、登録されていれば、ステップＳＰ３４に進
み、演算部２３は、登録されているファクシミリ番号に
ついての組織コード及び電話番号と、ＯＣＲ認識された
組織コード及び電話番号とを比較して、一致しているか
否かを判定する。つまり、一致していれば、正当なユー
ザであるし、一致していなければ正当なユーザではない
と判定する。

【００５０】ステップＳＰ３４の判定の結果、正当ユー
ザではない場合は、ステップＳＰ３３に進み、演算部２
３は、要求用ファクシミリ１６Ａ及び確認用ファクシミ
リにユーザ未登録の旨のエラー通知を送信する。

【００５１】また、ステップＳＰ３１の判定の結果、正
当な要求であると判定されると、ステップＳＰ３５に進
み、演算部２３は、ＯＣＲ認識された基準書番号を検索
キーにして基準書属性ＤＢ２５を検索する。

【００５２】ステップＳＰ３６では、演算部２３は、ス
テップＳＰ３１の検索の結果、該当する基準書があるか
ないかを判定する。

【００５３】その判定の結果、該当する基準書がなけれ
ば、ステップＳＰ３７に進み、演算部２３は、ＯＣＲ認
識された基準書番号についてパリティチェックを行う。
すなわち、演算部２３は、該基準書番号の１桁目から６
桁目の数字の総和を計算し、その総和の一の位の数字と
ＯＣＲ認識された該基準書番号の末尾の数字とを比較す
る。そして、上記の２つの数字が一致していれば、パリ
ティチェックＯＫと判定してステップＳＰ３８に進み、
一致していなければ、パリティチェックＮＧと判定して
ステップＳＰ３９に進む。

【００５４】ステップＳＰ３８では、上述したように記
入者の記入ミスがあると考えられるので、演算部２３は
その旨のエラー通知を要求用ファクシミリ１６Ａに送信
する。このエラー通知は、例えば、図１４に示すような
通知であり、記入者は、記入ミスを修正して再度ファク
シミリ送信する。

【００５５】また、ステップＳＰ３９では、演算部２３
は、要求されている基準書番号が無い旨のエラー通知を
要求用ファクシミリ１６Ａ及び確認用ファクシミリ５０
に送信する。確認用ファクシミリ５０に送信されるエラ
ー通知は、例えば図１５に示すような通知である。

【００５６】また、ステップＳＰ３６の判定の結果、要
求されている基準書が格納されていれば、ステップＳＰ
４０では、演算部２３は、該基準書の属性情報のうち、
配布管理番号を参照し、要求された基準書が配布可能か
否かを判定する。つまり、配布管理番号が「１」であれ
ば配布可能と判断し、「０」であれば配布不可と判断す
る。

【００５７】その判定の結果、要求された基準書が配布
不可であれば、ステップＳＰ３３に進み、演算部２３
は、要求用ファクシミリ１６Ａ及び確認用ファクシミリ
５０に、要求された基準書は配布不可の旨のエラー通知
を送信する。また、その判定の結果、要求されている基
準書が配布可であれば、ステップＳＰ４１に進む。

【００５８】ステップＳＰ４１では、演算部２３は、Ｏ
ＣＲ認識された結果に基づき、要求されている各基準書
の部数の総合計を計算する。そして、その計算された総
合計とＯＣＲ認識された総合計とが一致しているか否か
を判定する。その判定の結果、一致していなければ、ス
テップＳＰ３３に進み、演算部２３は、要求用ファクシ
ミリ１６Ａ及び確認用ファクシミリ５０に、和が一致し
ていない旨のエラー通知を送信する。確認用ファクシミ
リ５０に送信されるエラー通知は、例えば、図１６に示
すような通知である。また、その判定の結果、一致して
いれば、ステップＳＰ４２に進む。

【００５９】ステップＳＰ４２では、演算部２３は、集
計端末３０に、受付内容ＤＢ３１を検索するよう指示す
る。この受付内容ＤＢ３１の検索においては、一定期間
の範囲を予め定めておく。例えば、１週間という期間を
定めておいて、集計端末３０は過去１週間以内の受付内
容を検索する。これは、要求者等の過誤による二重要求
を防ぐためである。

【００６０】ステップＳＰ４３では、検索の結果、今回
要求された内容と同一の内容のものがあるかないかを判
定する。その判定の結果、同一要求があれば、ステップ
ＳＰ３３に進み、演算部２３は、要求用ファクシミリ１
６Ａ及び確認用ファクシミリ５０に、二重要求の旨のエ
ラー通知を送信する。要求用ファクシミリ１６Ａに送信
されるエラー通知は、例えば、図１７のような通知であ
る。また、その判定の結果、同一要求がなければ、ステ
ップＳＰ４４に進む。

【００６１】ステップ４４では、ＯＣＲ認識された受付
内容が受付内容ＤＢ３１に格納される。ステップ４５で
は、演算部２３は、要求用ファクシミリ１６Ａ及び確認
用ファクシミリ５０に、受付が完了した旨の結果通知を
送信する。要求用ファクシミリ１６Ａに送信される結果
通知は、例えば、図１８に示すような通知である。

【００６２】次に、問い合わせ処理の流れを、図１９を
参照しながら説明する。ステップＳＰ６１では、演算部
２３は、ＯＣＲ認識の結果を確認用ファクシミリ５０に
送信する。ステップＳＰ６２では、演算部２３は、問い
合わせ票を受け取った旨の通知を要求用ファクシミリ１
６Ａに送信する。 [３．変形例] [３−１．第一変形例]上述の実施形態では、基準書（つ
まり文書）の要求に関するシステムであったが、文書に
限らず、社内備品や、その会社が取り扱う商品等の他の
対象物であってもよい。 [３−２．第二変形例]上述の実施形態では、パリティチ
ェックは基準書番号（すなわち要求の対象物の識別符
号）についてのみ行われているが、基準書番号だけでは
なく、各ユーザの与えられるユーザ識別符号等について
も行われるようにしてもよい。

【００６３】

【発明の効果】上述したように本発明によれば、より迅
速で正確な処理を行う要求受付システム、要求受付方法
及びＯＣＲ帳票を提供することが可能である。また、本
発明によれば、システムのセキュリティを確保する要求
受付システム、要求受付方法及びＯＣＲ帳票を提供する
ことが可能である。

【図面の簡単な説明】

【図１】本発明の実施形態である要求受付システムの機
能構成を示す図である。

【図２】同実施形態におけるユーザＤＢのファイル構成
を示す図である。

【図３】同実施形態における基準書ＤＢのファイル構成
を示す図である。

【図４】同実施形態における要求内容ＤＢのファイル構
成を示す図である。

【図５】同実施形態における基準書番号の構成を示す図
である

【図６】同実施形態におけるユーザ登録票を示す図であ
る。

【図７】同実施形態における基準書要求票を示す図であ
る。

【図８】同実施形態における問い合わせ票を示す図であ
る。

【図９】同実施形態における処理の動作を示すフローチ
ャート図である。

【図１０】同実施形態におけるユーザ登録／削除の処理
動作を示すフローチャート図である。

【図１１】同実施形態における結果通知を示す図であ
る。

【図１２】同実施形態における基準書要求の処理動作を
示すフローチャート図である。

【図１３】同実施形態におけるエラー通知を示す図であ
る。

【図１４】同実施形態におけるエラー通知を示す図であ
る。

【図１５】同実施形態におけるエラー通知を示す図であ
る。

【図１６】同実施形態におけるエラー通知を示す図であ
る。

【図１７】同実施形態におけるエラー通知を示す図であ
る。

【図１８】同実施形態における結果通知を示す図であ
る。

【図１９】同実施形態における問い合わせ処理の動作を
示すフローチャート図である。

【符号の説明】

１０・・・要求用ファクシミリ、１１・・・ファクシミ
リ網、１５・・・支社 １６・・・ユーザ（部署）、１７・・・本社、２０・・
・受付端末 ２１・・・ファクシミリモデム、２２・・・ＯＣＲ認識
部、２３・・・演算部 ２４・・・ユーザデータベース、２５・・・基準書属性
データベース ３０・・・集計端末、３１・・・受付内容データベー
ス、４０・・・プリンタ ５０・・・確認用ファクシミリ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 河内 亨 東京都港区港南一丁目９番１号 エヌ・テ ィ・ティ・コミュニケーションウェア株式 会社内 (72)発明者 下田 嘉己 東京都港区港南一丁目９番１号 エヌ・テ ィ・ティ・コミュニケーションウェア株式 会社内 (72)発明者 青木 一美 東京都港区港南一丁目９番１号 エヌ・テ ィ・ティ・コミュニケーションウェア株式 会社内 Ｆターム(参考） 5B064 AA01 AA08 5C062 AA02 AA17 AC43 AF01 AF12 5C075 BB05 CF02 FF90

Claims (9)

【特許請求の範囲】
1. 【請求項１】 要求書送信装置と、送信された要求書を
   受信し、前記要求書の受信イメージをＯＣＲ認識し、Ｏ
   ＣＲ認識した結果を出力する要求書受信装置と、前記要
   求書送信装置と前記要求書受信装置とを中継する中継網
   とから成る要求受付システムにおいて、 前記要求書が受付可能となるための受付条件を記憶する
   受付条件記憶手段と、 前記ＯＣＲ認識の結果と前記受付条件とを用いて、前記
   要求書の受付の可否を判定する受付可否判定手段と、 を具備することを特徴とする要求受付システム。
2. 【請求項２】 請求項１記載の要求受付システムにおい
   て、 前記受付の可否判定の結果を前記要求送信装置に通知す
   る結果通知手段を具備することを特徴とする要求受付シ
   ステム。
3. 【請求項３】 請求項１記載の要求受付システムにおい
   て、 前記要求受付システムの利用が可能と認められた要求者
   の識別符号と、前記要求者が使用すべき前記要求書送信
   装置の通信のために用いられる通信識別符号とを対にし
   て記憶する識別符号記憶手段と、 前記要求書を送信した前記要求書送信装置の通信識別符
   号を、前記中継網から取得する識別符号取得手段とを具
   備し、 前記受付可否判定手段は、ＯＣＲ認識された前記要求者
   の識別符号と前記識別符号記憶手段が記憶する前記要求
   者識別符号とが一致し、かつ、前記中継網から取得した
   前記要求書送信装置の前記通信識別符号と前記識別符号
   記憶手段が記憶する前記要求書送信装置の前記通信識別
   符号とが一致するか否かにより、受付の可否を判定する
   ことを特徴とする要求受付システム。
4. 【請求項４】 請求項１記載の要求受付システムにおい
   て、 前記要求の対象物の識別符号である対象物識別符号は、
   所定の関係を有する複数の数字により構成されており、 ＯＣＲ認識された前記対象物識別符号を構成する数字が
   前記所定の関係を有するか否かを判定する関係判定手段
   を具備し、 前記受付条件記憶手段は、受付可能な前記対象物識別符
   号を記憶し、 前記受付可否判定手段は、ＯＣＲ認識された対象物識別
   符号と同一の符号が前記受付記憶手段により記憶されて
   いるか否かにより、受付可否を判定し、 前記結果通知手段は、前記受付可否判定手段により受付
   不可と判定され、かつ、前記関係判定手段により前記所
   定の関係があると判定された場合、前記要求送信装置
   に、前記要求書を記入した者の記入ミスの旨の通知を送
   信する請求項１記載の要求受付システム。
5. 【請求項５】 要求書送信装置から送信された要求書を
   受信し、前記要求書の受信イメージをＯＣＲ認識し、Ｏ
   ＣＲ認識した結果を出力する要求受付方法において、 前記要求書が受付可能となるための受付条件と、前記Ｏ
   ＣＲ認識の結果とを用いて、前記要求書の受付の可否を
   判定する過程を具備することを特徴とする要求受付方
   法。
6. 【請求項６】 請求項５記載の要求受付方法において、 前記受付の可否判定の結果を前記要求送信装置に送信す
   る過程を具備することを特徴とする要求受付方法。
7. 【請求項７】 請求項５記載の要求受付方法において、 ＯＣＲ認識された前記対象物識別符号を構成する数字が
   前記所定の関係を有するか否かを判定する過程を具備
   し、 前記受付の可否を判定する過程は、ＯＣＲ認識された対
   象物識別符号が予め記憶されているか否かにより、受付
   可否を判定し、 前記結果を通知する過程は、前記受付可否を判定する過
   程により受付不可と判定され、かつ、前記関係を判定す
   る過程により前記所定の関係があると判定された場合、
   前記要求送信装置に、前記要求書を記入した者の記入ミ
   スの旨の通知を送信する要求受付方法。
8. 【請求項８】 請求項５記載の要求受付方法において、 要求者の識別符号と、前記要求者が使用すべき前記要求
   書送信装置の通信のために用いられる通信識別符号とを
   対にして記憶する過程と、 前記中継網から、前記要求書を送信した前記要求書送信
   装置の通信識別符号を取得する過程とを具備し、 前記受付可否を判定する過程は、ＯＣＲ認識された前記
   要求者の識別符号と前記識別符号記憶手段が記憶する前
   記要求者識別符号とが一致し、かつ、前記中継網から取
   得した前記要求書送信装置の前記通信識別符号と前記識
   別符号記憶手段が記憶する前記要求書送信装置の通信識
   別符号とが一致するか否かにより、受付可否を判定する
   ことを特徴とする要求受付方法。
9. 【請求項９】 請求項５記載の要求受付方法に使用され
   るＯＣＲ帳票であって、 ＯＣＲ認識の対象となる所定の位置に記載された記入枠
   と、 ＯＣＲ認識の対象外となる位置に記載され、前記記入枠
   に記入する文字の位置を示す記入位置目安とを具備し、
   それにより、文書作成装置で作成可能なＯＣＲ帳票。