サーバおよび画像処理システム
【課題】 申請者に負担が少ない方法で、本人確認書類から光学的に読み取った画像で本人確認を行う。
【解決手段】サーバは、受信部、文字認識部、判定部、通知部を有する。前記受信部は所定の契約に関する手続きの種別毎に異なる受信用の電子メールアドレスを持ち、手続きの種別毎の前記アドレスに電子メールを受信する。前記文字認識部は受信された電子メールに添付されている書類の画像に対して文字認識処理を行うことで文字列を得る。前記判定部は前記文字認識部により得られた文字列と、前記サーバに予め登録された本人確認書類毎の文字列候補とを比較し、前記画像の本人確認書類としての種別を判定し、この本人確認書類の種別と前記サーバに予め登録された契約に関する情報とから前記画像が本人確認書類の画像として適切か否かを判定する。前記通知部は前記画像の判定結果を前記携帯端末へ通知する。
【解決手段】サーバは、受信部、文字認識部、判定部、通知部を有する。前記受信部は所定の契約に関する手続きの種別毎に異なる受信用の電子メールアドレスを持ち、手続きの種別毎の前記アドレスに電子メールを受信する。前記文字認識部は受信された電子メールに添付されている書類の画像に対して文字認識処理を行うことで文字列を得る。前記判定部は前記文字認識部により得られた文字列と、前記サーバに予め登録された本人確認書類毎の文字列候補とを比較し、前記画像の本人確認書類としての種別を判定し、この本人確認書類の種別と前記サーバに予め登録された契約に関する情報とから前記画像が本人確認書類の画像として適切か否かを判定する。前記通知部は前記画像の判定結果を前記携帯端末へ通知する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、サーバおよび画像処理システムに関する。
【背景技術】
【０００２】
保険会社、銀行などの金融機関における新規取り扱いまたは契約変更などを行う窓口では、犯罪による収益の移転防止に関する法律（犯罪収益移転防止法）への対応として顧客に対する確実な本人確認が必要となっている。
【０００３】
例えば保険会社の窓口で契約者（申請者）が契約変更などの手続きをする際には、運転免許証、各種健康保険証・年金手帳、パスポート（旅券）、外国人登録証明書などの公的証明書（本人確認書類）を申請者が窓口担当者へ手渡し、窓口担当者が申請者と本人確認書類とを見比べて本人確認をしている。
【０００４】
具体的には、申請者から提示された本人確認書類をコピーしたものを窓口担当者が目視し申請者の容姿と見比べることで本人確認が行われてきた。
【０００５】
最近では、モバイルバンキングの口座を開設するにあたり、携帯電話機で人を介さずに行う手続きも始められている。この手続きを行うために、携帯電話機のカメラ機能を利用し免許証や健康保険証などの公的証明書（本人確認書類）を撮影し、その画像を申請用のＷｅｂサイトへ送信するアプリケーションソフトウェア（公的証明書撮影アプリケーション）が実用化されつつある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００６−１８６５６４号
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従来、公的証明書撮影アプリケーションは、ソフトウェアを契約者が所持する携帯電話機へダウンロードする必要があるため、ソフトウェアのダウンロードに要するパケット通信料・時間などのコストを伴う。これは当該アプリケーションを一度程度しか使わない申請者（契約者）にとっては負担が大きいという問題があった。
【０００８】
本発明が解決しようとする課題は、申請者に負担が少ない方法で、本人確認書類から光学的に読み取った画像で本人確認を行うことができるサーバおよび画像処理システムを提供することにある。
【課題を解決するための手段】
【０００９】
実施形態のサーバは、携帯端末とネットワークを介して接続されたサーバであり、受信部、文字認識部、判定部、通知部を有する。前記受信部は所定の契約に関する手続きの種別毎に異なる受信用の電子メールアドレスを持ち、手続きの種別毎の前記アドレスに電子メールを受信する。前記文字認識部は受信された電子メールに添付されている書類の画像に対して文字認識処理を行うことで文字列を得る。前記判定部は前記文字認識部により得られた文字列と、前記サーバに予め登録された本人確認書類毎の文字列候補とを比較し、前記画像の本人確認書類としての種別を判定し、この本人確認書類の種別と前記サーバに予め登録された契約に関する情報とから前記画像が本人確認書類の画像として適切か否かを判定する。前記通知部は前記画像の判定結果を前記携帯端末へ通知する。
【図面の簡単な説明】
【００１０】
【図１】第１実施形態の画像処理システムの概要構成を示す図である。
【図２】携帯端末の構成を示す図である。
【図３】サーバの構成を示す図である。
【図４】第１実施形態の動作を示すフローチャートである。
【図５】携帯端末の本人確認書類送付画面（申請画面）を示す図である。
【図６】携帯端末の送信メール作成画面を示す図である。
【図７】携帯端末の添付データ選択メニュー画面を示す図である。
【図８】カメラ機能による本人確認書類撮影画面を示す図である。
【図９】電子メールアドレスと本人確認書類の画像とが紐付けされてメモリに記憶された様子を示す図である。
【図１０】電子メールアドレスと本人確認書類の画像が手続き別にマスタＤＢに保存される様子を示す図である。
【図１１】不適合の際に電子メールに挿入される定型メッセージの一例を示す図である。
【図１２】第２実施形態の構成を示す図である。
【図１３】ＱＲコード認識画面を示す図である。
【図１４】第２実施形態の動作を示すフローチャートである。
【図１５】第３実施形態の動作を示すフローチャートである。
【図１６】第３実施形態における携帯端末の添付データ選択メニュー画面を示す図である。
【図１７】第４実施形態の動作を示すフローチャートである。
【発明を実施するための形態】
【００１１】
以下、図面を参照して、実施形態を詳細に説明する。
（第１実施形態）
図１は第１実施形態の画像処理装置の構成を示す図である。
図１に示すように、この第１実施形態の画像処理システムは、携帯端末１とサーバ３とを無線基地局２ａおよびインターネットなどのネットワーク２を介して接続して構成されている。携帯端末１は、例えばカメラ付き携帯電話機などであり、保険の契約者などが携行している。サーバ３は、例えば保険会社または保険契約の審査会社などに配置されている。
【００１２】
図２に示すように、携帯端末１は、表示部９、メモリ１０、キー操作部１１、画像取得部１２、電子メール部１３、暗号化部１４、Ｗｅｂアクセス部１５、制御部１７などを有している。
【００１３】
表示部９は、例えば液晶ディスプレイなどであり、画像取得部１２により取得される本人確認書類の画像を表示可能である。メモリ１０は、各部が行う処理の作業領域として利用される。メモリ１０には、画像取得部１２により取得された画像が記憶される。キー操作部１１は、例えばテンキー、矢印キー、決定キーなどの操作ボタン（スイッチ）であり、表示部９に表示された申請画面にある複数の手続きの中からユーザが選択（指定）した手続きを受け付ける。
【００１４】
画像取得部１２は、例えばＣＣＤカメラなどであり、被写体としての本人確認書類を撮像し、その書類の画像を取得する。ＣＣＤカメラの性能（解像度）としては、例えば２００万画素（６５ｄｐｉ）以上あることが好ましい。画像取得部１２による書類撮影の際にキー操作部１１の決定キーは撮像ボタンとして機能する。撮像ボタンの押下によりそのとき画像取得部１２により撮影された画像が取得される。
【００１５】
暗号化部１４は、送信メール作成画面にて作成された、送信メールを暗号化する。電子メール部１３は、暗号化部１４により暗号化された電子メールを送信先のサーバ３へ送信する。
【００１６】
Ｗｅｂアクセス部１５は、サーバ３に対してネットワーク２を通じてアクセスし、サーバ３から受信されたユーザ認証のための画面にてユーザにより入力されたユーザ情報（ユーザＩＤ、パスワードなど）を送り、サーバ３で認証された場合、サーバ３から受信されたメニューページから各種画面（本人確認書類申請用の画面（図５参照）、電子メール作成用の画面である送信メール作成画面（図６参照）など）の要求を行い、受信された画面にて次の操作を行う。
【００１７】
すなわち、Ｗｅｂアクセス部１５は、予め設定されたサーバ３のＷｅｂサイトにアクセスし、ユーザ認証後、サーバ３から受信された申請画面（図５参照）を表示部９に表示し、申請画面で本人確認書類を送る手続きが指定された場合、手続きの種別に応じて送付先の電子メールアドレスが宛先欄に入力された送信メール作成画面（図６参照）をサーバ３から受信し表示部９に表示し、送信メール作成画面における画像添付操作により画像取得部１２により取得された画像を当該電子メールに添付して送信する。制御部１７は、上記各部を統括制御する。
【００１８】
図３に示すように、サーバ３は、メール受信部３１、復号部３２、メモリ３３、文字認識辞書記憶部３４、文字認識部３５、本人確認書類記憶部３６、比較・判定部３７、申込検索・特定部３８、Ｗｅｂサーバ部３９、マスタデータベース４３（以下「マスタＤＢ４３」と称す）などを有するコンピュータであり、ハードウェアとして、上記メモリ３３の他、ハードディスクドライブなどの不揮発性記憶装置、ＣＰＵなどの制御装置などを備えている。
【００１９】
メール受信部３１は、携帯端末１からネットワーク２を通じて送られてきた、暗号化された電子メールを受信する。メール受信部３１には申請手続きの種別毎（項目毎）の電子メールアドレス（以下「受信アドレス」と称す）が複数設定されており、電子メールが各受信アドレスに受信されることで、その電子メールの申請手続きが特定できる。すなわちメール受信部３１は、手続きの種別毎に異なる受信用の電子メールアドレスを持ち、ネットワーク２を通じてアドレス毎（手続きの種別毎）に電子メールを受信する。
【００２０】
復号部３２は、メール受信部３１により受信された、暗号化された電子メールを復号し、電子メールとその添付画像とを対応させてメモリ３３に記憶する。すなわちメモリ３３には、受信された電子メールの内容とその添付画像の画像データが記憶される。
【００２１】
文字認識辞書記憶部３４には、画像から文字を認識するための一般的な辞書が記憶されている。
【００２２】
文字認識部３５は、メール受信部３１により受信された電子メールに添付されている書類の画像に対して予め文字認識辞書記憶部３４に設定された文字認識辞書を用いて文字認識処理を行うことで文字列を得る。
【００２３】
具体的には、文字認識部３５は、メモリ３３の書類画像を読み出して文字認識、つまり書類画像から文字毎の画像を切り出し、切り出した個々の文字の画像と文字認識辞書記憶部３４の辞書のテキストとのペアを生成する。
【００２４】
さらに文字認識部３５は、認識結果の１文字ずつ連続するテキストの行を文節また単語の単位に区切った文字または文字列を生成する。すなわち文字認識部３５は、メール受信部３１により受信された画像に対して予め文字認識辞書記憶部３４に記憶された文字認識辞書を用いて文字認識処理を行い、文字または文字列を得る。
【００２５】
本人確認書類辞書記憶部３６には、申請内容（契約内容確認・変更など）によって必要な本人確認書類の種別（書類識別情報）毎にキーワードが記憶されている。例えば契約内容確認・変更などという申請では、「運転免許証」という本人確認書類が必要である。
【００２６】
この本人確認書類を特定するための運転免許証キーワード（書類特有の文字列候補）として、例えば「免許証」、「本籍」、「住所」、「氏名」、「交付」、「有効」、「番号」、「日生」などのキーワード（文字列候補）が記憶されている。このように本人確認書類辞書記憶部３６は、本人確認書類の種別毎に書類特有の文字列候補を記憶する記憶部として機能する。
【００２７】
申込検索・特定部３８は、文字認識結果（氏名、住所など）をキーワードにしてマスタＤＢ４３を検索し、契約者の申込情報を特定する。すなわち申込検索・特定部３８は、画像から文字認識された氏名、住所、生年月日などをキーにしてマスタＤＢ４３を検索し、当該電子メールの送付者（契約者）の申込情報を特定する。申込検索・特定部３８は、文字認識部３５により得られた文字列が含まれる契約に関する情報（申込情報）を検索する検索部として機能する。
【００２８】
文字認識結果の氏名、住所、生年月日とマスタＤＢ４３に予め登録されている氏名、住所、生年月日の情報と一致する申込情報が見つかった場合、申込検索・特定部３８は、比較・判定部３７へ申込情報を送る。
【００２９】
比較・判定部３７は、申込検索・特定部３８から受け取った申込情報と本人確認書類の種別の判定結果とを総合して、受信された画像が本人確認書類の画像か否かを判定する。
【００３０】
比較・判定部３７は、文字認識部３５により文字認識されて文字認識結果として得られた文字列と、本人確認書類辞書記憶部３６の書類毎のキーワードとを比較し、画像から得られた文字列全体に対するキーワードの一致／不一致の割合である一致度を求める。すなわち比較・判定部３７は、文字認識部３５により文字認識処理の結果得られた文字列と本人確認書類辞書記憶部３６の書類毎のキーワードとを比較し、一致度が高い書類（書類識別情報）を特定する。
【００３１】
なお、ここでは予め設定した閾値（例えば８０％など）を、一致度が超えた場合に一致度が高いものとし、そのキーワードを持つ本人確認書類（書類識別情報）の種別を特定する。画像の書類が免許証か健康保険証かなどである。
【００３２】
すなわち、比較・判定部３７は、文字認識部により得られた文字列と、本人確認書類辞書記憶部３６の本人確認書類毎の文字列候補とを比較し、画像の本人確認書類としての種別を判定し、この本人確認書類の種別と申込検索・特定部３８により検索された契約に関する情報とから画像が本人確認書類の画像として適切か否かを判定する判定部として機能する。
【００３３】
返信メール処理部４１は、比較・判定部３７による本人確認書類の画像（書類画像）の判定結果を、ネットワーク２を通じて電子メール送信元の携帯端末１へ送り通知する通知部として機能する。復号部３２は、メール受信部３１により受信された電子メール（または添付画像）を復号する。
【００３４】
マスタＤＢ４３は、サーバ３の大容量記憶装置、例えばハードディスクドライブなどに設けられるデータベースである。マスタＤＢ４３には、例えば保険の手続きに関する情報（例えば例えば保険契約者の氏名、住所、生年月日、申込内容、申込日などの保険契約者の申込情報が記憶されている。申込情報を案件情報とも言う。
【００３５】
また、マスタＤＢ４３には、例えば"契約内容変更"という手続きの項目に対してサーバ３の受信アドレスとして、例えば＊＊@xxxx.co.jpなどが対応して記憶され、"契約内容確認"という手続きの項目に対してサーバ３の受信アドレスとして、例えば＊＊＊@xxxx.co.jpが対応して記憶された手続き−電子メールアドレス対応テーブルが設けられている。つまりサーバ３は手続き毎の受信アドレスを有しており、電子メールが受信された受信アドレスによって、手続きの内容を判定できる。
【００３６】
この他、マスタＤＢ４３には、保険の手続きに関する申請のための情報として「契約内容確認・変更」、「保険料振替口座変更」、「保険控除証明書再発行」、「改姓・名、契約者変更、受取人変更」、「入院給付金請求」、「死亡保険金請求」などの項目が記憶されている。
【００３７】
このうち、申請が例えば「契約内容変更」であれば、手続き名称として「契約内容変更」と、この契約内容変更に関して必要な書類の情報（「運転免許証」、「健康保険証」…など）が記憶されている。
【００３８】
マスタＤＢ４３には、所定の契約（保険契約）に関する情報（契約者の申込情報）とこの情報に関する手続きを行う上で必要な本人確認書類の種別（契約変更手続きには免許証または健康保険証が必要など）が記憶されている。
【００３９】
返信メール処理部４１は、本人確認書類の画像の判定結果に応じた定型メッセージをメモリ３３から読み出し、定型メッセージを電子メールの本文に挿入した返信用の電子メールを作成し、画像送付元の携帯端末１へ通知する。すなわち返信メール処理部４１は、比較・判定部３７により判定された本人確認書類判定結果を携帯端末１へ電子メールで通知する。
【００４０】
メモリ３３には、書類画像の判定結果に応じた定型メッセージが記憶されている。例えば判定結果が本人確認書類の画像として「適切」の場合、本人確認書類の画像を正常に受理した旨の通知情報として、例えば「お送りいただきました本人確認書類の画像は正常に受理されました。」などの定型メッセージがメモリ３３に記憶されている。
【００４１】
また「画像が不明」であり判定結果が本人確認書類の画像として「不適切」の場合、読み取り不可の通知情報として、図１１に示すように、「［重要］本人確認書類の再撮影・ご送付のお願い。先ほどご送付頂きました写真は受理できませんでした。理由：文字列が読み取れませんでした。お願い：お手数ですが再撮影・ご送付をお願いいたします。」などの定型メッセージがメモリ３３に記憶されている。
【００４２】
Ｗｅｂサーバ部３９は、携帯端末１からのＷｅｂアクセスの要求によりユーザ認証を行い、認証されたユーザの携帯端末１に対して、要求された各種画面（本人確認書類の申請用の画面（図５参照）、電子メール作成用の画面である送信メール作成画面（図６参照）など）を送る。
【００４３】
次に、図４乃至図８を参照してこの第１実施形態の画像処理システムの動作を説明する。
この第１実施形態の場合、利用者が携帯端末１のキーを操作して、サーバ３のＷｅｂサーバ部３９によりネットワーク２上に公開されている携帯サイト、例えば保険のポータルサイトなどにアクセスし、ログインボタンなどを選択操作すると、ログイン認証用の画面が表示される。
【００４４】
このログイン認証用の画面には、ユーザＩＤとパスワードの入力欄があり、ユーザが入力欄に、ユーザＩＤとパスワードを入力し、ＯＫボタンなどを押下すると、Ｗｅｂサーバ部３９では、入力欄に入力された情報（ユーザＩＤとパスワード）と予め登録されているユーザ情報とを比較し、一致した場合、認証ＯＫとし、契約者だけのメニューページを携帯端末１へ送る。これにより、携帯端末１の表示部９には、申請画面である本人確認書類送付画面５１（図５参照）が表示される。
【００４５】
図５に示すように、本人確認書類送付画面５１には、本人確認書類送付画面５１には、「同意しました。」というメッセージと、その左側に配置されたチェックボックス５２と、申請ボタン５３ａ〜５３ｃなどと、申請のやり方（手順）を示すメッセージ５４とが設けられている。
【００４６】
申請ボタン５３ａ〜５３ｃは、保険契約に関する手続きが項目別に複数、例えば保険申込み、契約内容変更、契約者貸付などが用意されている。各申請ボタン５３ａ〜５３ｃには、その申請毎に異なるサーバ３側の電子メールアドレス（以下「受信アドレス」と称す）のリンクが張られている。
【００４７】
ユーザが、例えば契約内容変更を行うため、契約内容変更の手続きの項目の申請ボタン５３ｂを選択操作し、「同意しました。」のメッセージの左側に位置するチェックボックス５２にチェックを入れると（図４のステップＳ１０１）、Ｗｅｂサーバ部３９は、選択操作された申請ボタン５３ｂの受信アドレスのリンクから、契約内容変更手続き用として設定されているサーバ３の受信アドレス（＊＊＠ｘｘｘｘ．ｃｏ．ｊｐ）への送信メール作成画面５５（図６参照）を携帯端末１の表示部９に表示させる（ステップＳ１０２）。
【００４８】
図６に示すように、送信メール作成画面５５には、宛先欄５６、件名欄５７、添付欄５８、本文欄５９が設けられている。宛先欄５６には、予めサーバ３の契約変更手続き用の受信アドレス５６が予め入力されている。
【００４９】
この送信メール作成画面５５にて、ユーザがファイルを添付するためのボタン６０を押下すると、添付データ選択メニュー画面６１（図７参照）が表示部９に表示される。
【００５０】
図７に示すように、添付データ選択メニュー画面６１には、添付データ選択メニューが設けられている。添付データ選択メニューとして、例えばデータフォルダ、ムービー撮影、フォト撮影、ボイス録音、プロフィール、アドレス帳、タスクリスト…などの項目が設けられている。
【００５１】
この添付データ選択メニュー画面６１において、ユーザがキー操作部１１の矢印ボタンなどで「フォト撮影」６２の項目を選択し（ステップＳ１０３）、「選択」ボタン６３を押下すると、撮影画面６４（図８参照）が表示部９に表示される。
【００５２】
図８に示すように、この撮影画面６４には、画像取得部１２により取得される本人確認書類（被写体）の画像（被写体を免許証とした場合、免許証の画像６５）が映し出される。免許証の他、本人確認書類としては、例えば健康保険証などであってもよい。
【００５３】
撮影では、携帯端末１または免許証のいずれかを動かして、免許証の画像が極力大きくかつ免許証全体が撮影範囲に収まるようにしてキー操作部１１の撮影ボタンを押し、本人確認書類の画像を撮影する（ステップＳ１０４）。
【００５４】
本人確認書類の画像が撮影されると、本人確認書類の画像ファイルが当該電子メールに添付された状態の送信メール作成画面５５が表示部９に表示される。
【００５５】
この送信メール作成画面５５にて、件名や本文が無い状態で、ユーザが携帯端末１の画面のメニューから「送信」の操作を行うことで、送信メールが、暗号化された後、既に宛先欄に入力されているサーバ３の受信アドレス５６へ送信される（ステップＳ１０５）。
【００５６】
一方、サーバ３では、暗号化された電子メールが受信されると、その電子メールを復号し、図９に示すように、電子メールアドレスとこの電子メールに添付されてきた本人確認書類画像とを紐付けしてメモリ３３に保存する（ステップＳ１０６）。
【００５７】
次に、文字認識部３５が、当該本人確認書類画像をメモリ３３から読み出して文字認識（ＯＣＲ）処理し（ステップＳ１０７）、文字認識結果として文字列を得る。
【００５８】
続いて、比較・判定部３７は、本人確認書類辞書記憶部３６を参照して当該画像がこの手続きの証拠として適切か不適切かを判定する（ステップＳ１０８）。
【００５９】
すなわち、この比較・判定部３７では、当該画像の鮮明度や当該画像が本人確認書類として有効か否かを判定する。
【００６０】
詳細には、比較・判定部３７は、本人確認書類辞書記憶部３６から読み出し、文字認識部３５により得られた文字認識結果の文字列とを比較して、文字列候補と文字列との一致／不一致の度合い、つまり互いの文字列の一致度を判定する。
【００６１】
文字列の一致度が予め設定された閾値よりも高い場合、当該画像を有効（適切、合格など）と判定し、文字列の一致度が閾値よりも低い場合、当該画像を無効（不適切、不合格など）と判定する。なお閾値は例えば８０％などに設定されているものとする。この閾値は一例であり、他の値であってもよい。
【００６２】
当該画像の鮮明度については、当該画像の階調変化率を求め、求めた画像の階調変化率が予め設定された閾値を超えたか否かによりピントの合否を判定し、このピントの合否判定結果と画像の有効性判定結果とを合わせて判定してもよい。２つの判定結果を合わせるとは、例えば論理積をとる、または論理和をとるなどの方法が考えられる。
【００６３】
本人確認書類の有効性判定の結果として、当該画像が証拠として適切（合格）である場合（ステップＳ１０８の「適切」）、図１及び図１０に示すように、手続きの種別毎に、申請者の電子メールアドレスと当該画像（受信された本人確認書類の画像）とを、既にマスタＤＢ４３に登録されている契約者の申込情報に対応させて、マスタＤＢ４３に保存する（ステップＳ１０９）。
【００６４】
これと共に、返信メール処理部４１は、比較・判定部３７の有効性判定結果が有効であれば、画像を受理した旨の定型メッセージを電子メールに挿入し、申請元の携帯端末１へ返信する（ステップＳ１１０）。
【００６５】
一方、比較・判定部３７の有効性判定結果が有効でない、つまり不合格（画像を受理不可）の場合、当該画像と手続きの種別毎に受信した電子メールの電子メールアドレスとをメモリ３３に一時保存した後（ステップＳ１１１）、メモリ３３に一時保存した電子メールアドレスを宛先欄に設定し、図１１に示すように、不合格理由の定型メッセージ（本人確認書類の画像の再取得要請コメント）を書き込んだ電子メールを申請元の携帯端末１へ返信する（ステップＳ１１２）。
【００６６】
このようにこの第１実施形態によれば、本人確認書類の画像の確認手続きに必要なアプリケーションを、携帯端末１からサーバ３へのＷｅｂアクセスで提供されるＷｅｂアプリケーションで実現し、携帯端末１のカメラ機能を利用して本人確認書類を撮影および送付する。つまりネットワークからダウンロードするアプリケーションソフトウェアを用いることなく、本人確認書類の画像を手続き先へ送り、確認結果を受け取ることができる。
【００６７】
これにより、ソフトウェアを契約者の携帯端末１にダウンロードする必要がないため、ソフトウェアのダウンロードに要するパケット通信料・時間などのコストを少なくし、当該アプリケーションを一度程度しか使わない契約者の負担を軽減することができる。
【００６８】
より具体的には、携帯サイトへの入力内容と電子メールで送られてきた画像の文字認識結果とから当該手続きを導き出し、画像が本人確認書類の画像として適切か否かを判定し、適切であれば、その旨を申請元の携帯端末１へ通知し、不適切であれば、再送要求を通知するので、申請者に負担が少ない方法で、本人確認書類から携帯端末１で光学的に読み取った画像で本人確認を行うことができる。
またこの第１実施形態によれば、受信された電子メールに応じた手続きの種別または電子メールに添付されていた画像データから取得した文字情報を基に既入力情報である申込情報を探索して、案件を特定して紐付け保存することにより手続きの確実性を担保することができる。
【００６９】
さらに、本実施形態では、画像における階調変化率を確認することにより被写体全体のピントの合否を確認することで、文字列だけでなく、絵や写真の部分についても見易さ（見読性）を確認できる。
また、本実施形態では、画像が受理不可である旨のメッセージを入れた電子メールを申請者の携帯端末１へ返信することで、画像受理不可の理由についても場合分けして通知するので、撮影者のユーザビリティを高くするこができる。
【００７０】
（第２実施形態）
次に、図１２及び図１３を参照して第２実施形態を説明する。図１２は第２実施形態の画像処理システムの携帯端末の構成を示す図、図１３は第２実施形態の動作を示すフローチャートである。なお第１実施形態と同様の構成には同一の符号を付しその説明は省略する。
【００７１】
図１２に示すように、この第２実施形態の場合、携帯端末１は、ＱＲコード認識部１８を備える。ＱＲコード認識部１８はユーザがこれから電子メールを送る手続きの受信アドレスのリンクを含むＱＲコードを読み取り、コードの内容を認識する。
【００７２】
すなわちＱＲコード認識部１８は、画像取得部１２により画像が取得される手続きに対応する電子メールアドレスのリンクをＱＲコードから得る。ＱＲコードは保険手続きのパンフレッドやＰＣ用Ｗｅｂサイトなどに、予め手続き別に複数表示されているものとする。つまりＱＲコードは手続きの種別毎に予め保険手続きのパンフレッドに印刷、またはＰＣ用Ｗｅｂサイトなどに表示されている。
【００７３】
この第２実施形態の場合、ＱＲコード認識部１８は、携帯端末１の表示部９に、図１３に示すようなＱＲコード認識画面７１を表示する。
【００７４】
このＱＲコード認識画面７１には、認識範囲を示す枠線７２が設けられており、パンプレットに印刷された手続きを示すＱＲコード７３が枠線７２内に入るように画像取得部１２のカメラ機能にて撮像することで、ＱＲコード認識部１８は、ＱＲコード７３を認識し、手続きに対応する受信アドレスのリンクを取得する（図１４のステップＳ２０１）。ステップＳ１０２以降の処理は、第１実施形態と同様である。
【００７５】
このようにこの第２実施形態によれば、ＱＲコード認識部１８を設けて、手続きに対応する受信アドレスのリンクをＱＲコード７３から取得することで、第１実施形態の効果に加え、手続きの指定（入力）を容易にかつ確実に行うことができる。
【００７６】
すなわち、受信アドレスのリンクをＱＲコード７３から取得することで、ユーザが受信アドレスをキー入力したときに発生しやすい入力ミスやキー入力の手間などを軽減することができる。
【００７７】
換言すると、手続き先の電子メールアドレスを携帯端末１に入力する手段として、ＱＲコードを採用したことで、紙面やＰＣ用Ｗｅｂサイトとの連携でキー入力を極力少なくした手続きを行うことができる。
【００７８】
（第３実施形態）
次に、図１５、図１６を参照して第３実施形態を説明する。図１５は第３実施形態の動作を示すフローチャート、図１６は携帯端末１の添付データ選択メニュー画面を示す図である。なおこの第３実施形態の構成は第２実施形態と同様である。
【００７９】
この第３実施形態の場合、保険の申し込みや契約内容変更などの手続を行うＰＣ用Ｗｅｂサイトや保険契約のパンフレットなどに本人確認書類の画像の撮影方法を明示しておき、利用者はその内容に従って携帯端末１の画像取得部１２のカメラ機能で本人確認書類を撮影し、携帯端末１のメモリ１０に予め保存しておく（ステップＳ３０１）。
【００８０】
また、第２実施形態と同様にＰＣ用Ｗｅｂサイトや保険契約のパンフレットに設けられた本人確認書類の画像送付先であるサーバ３の受信アドレスのリンクを示す暗号情報としてのＱＲコード（コード情報）を手続きの種別毎に複数表示しておき、ユーザは携帯端末１を操作して、所望の手続きのＱＲコードを携帯端末１のカメラ機能にて読み取り、ＱＲコード認識部１８がコードの内容を認識し、受信アドレスのリンクを取得する（ステップＳ３０２）。暗号情報はＱＲコード以外に、例えばバーコードなどであってもよい。
【００８１】
ＱＲコード認識部１８は、ＱＲコードの内容である受信アドレスのリンクを取得すると、手続き用の受信アドレスへの送信メール作成画面５５（図６参照）を表示部９に表示させる。
【００８２】
この送信メール作成画面５５にて、件名や本文が入力されていない空メールの状態で、ユーザが「添付」を選択するボタン６０を押下すると、添付データ選択メニュー画面６１（図１６参照）が表示部９に表示される（ステップＳ３０３）。
【００８３】
図１６に示すように、この添付データ選択メニュー画面６１において、撮影済みの画像（保存画像）が保存されている「データフォルダ」６６を選択し、「全データ表示」という機能で開いた画面の中から、予め撮影しておいた本人確認書類の画像を選択し（ステップＳ３０４）、キー操作部１１の「確定」ボタンを押下すると、当該電子メールが暗号化され、既に宛先として入力されているサーバ３の受信アドレスへ送信される（ステップＳ３０５）。ステップＳ１０６以降のサーバ３側での処理は第１実施形態と同様である。
【００８４】
この第３実施形態によれば、携帯端末１で予め撮影しておいた本人確認書類の画像を読み出して電子メールに添付し送信するので、ＷＥＢアクセス時の作業時間を短縮することができる。
【００８５】
（第４実施形態）
次に、図１７を参照して第４実施形態を説明する。図１７は第４実施形態の動作を示すフローチャートである。なおこの第４実施形態の構成は第１実施形態と同様である。
【００８６】
この第４実施形態の場合、携帯端末１に表示された申請のための本人確認書類送付画面５１（図５参照）から、所望の手続きの申請ボタン５３ａ〜５３ｃのいずれかが押下されステップＳ４０１）、送信メール作成画面（図６参照）を表示するための要求があった場合、サーバ３のＷｅｂサーバ部３９は、手続きの種別毎に所定の発行ルールでワンタイムメールアドレスを作成および発行し、そのワンタイムメールアドレスを宛先欄に挿入した送信メール作成画面（図６参照）を携帯端末１の表示部９に表示させる。ステップＳ１０２以降の処理は第１実施形態と同様である。
【００８７】
この第４実施形態によれば、携帯端末１からアクセスするＷｅｂサイト（携帯サイト）でワンタイム・メールアドレスを発行することで、件名や本文無しでかつ画像添付漏れで電子メールが送信されてきた場合であっても、携帯端末１から申請された手続きをサーバ３の側で特定することができる。
また、データ送信にはワンタイムメールアドレスを使用することにより空メールであっても案件を特定でき、同時に悪意ある第三者による犯罪利用を防止することができる。
【００８８】
なお、上記各実施形態において携帯端末１から電子メールで本人確認書類の画像をサーバ３へ送信する際、携帯端末１が、例えば携帯電話機などでは、通信料金（パケット代）がユーザの負担になる。
【００８９】
そこで、ユーザに対してパケット代を補填するため、フリーダイヤルのように受け手がパケット代を払うメールアドレスの仕組みを用いる。具体的には、キャリヤ間のサービス連携により特定メールアドレスへのパケット送信料を受け手側に請求する仕組みを採用するか、もしくは例えば当該手続きが保険金請求であった場合、パケット代相当分を保険金等の支払い時に合算して入金する仕組みとすることが好ましい。
【００９０】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【００９１】
上記実施形態では、携帯端末１としての一例に、カメラ付き携帯電話機を例示したが、この他、例えばインターネット接続機能とカメラ機能を搭載したＰＤＡ、タブレット端末および電子ブック端末などであってもよい。
【００９２】
上記実施形態では、画像ファイル名の一部に、書類の種別を識別するための識別情報を含ませたが、この他、例えば画像自体に電子透かしとして識別情報を埋め込んでもよい。この場合、書類の識別情報を隠蔽できるため、書類画像の不正利用などを抑止することができる効果がある。
【００９３】
また、上記実施形態に示した各構成要素を、コンピュータのハードディスク装置などのストレージにインストールしたプログラムで実現してもよく、また上記プログラムを、コンピュータ読取可能な電子媒体：electronic mediaに記憶しておき、プログラムを電子媒体からコンピュータに読み取らせることで本発明の機能をコンピュータが実現するようにしてもよい。電子媒体としては、例えばＣＤ−ＲＯＭ等の記録媒体やフラッシュメモリ、リムーバブルメディア：Removable media等が含まれる。さらに、ネットワークを介して接続した異なるコンピュータに構成要素を分散して記憶し、各構成要素を機能させたコンピュータ間で通信することで実現してもよい。
【符号の説明】
【００９４】
１…携帯端末、２…ネットワーク、２ａ…無線基地局、３…サーバ、９…表示部、１０…メモリ、１１…キー操作部、１２…画像取得部、１３…電子メール部、１４…暗号化部、１５…Ｗｅｂアクセス部、１７…制御部、１８…ＱＲコード認識部、３１…メール受信部、３２…復号部、３３…メモリ、３４…文字認識辞書記憶部、３５…文字認識部、３６…本人確認書類辞書記憶部、３７…比較・判定部、３８…申込検索・特定部、３９…Ｗｅｂサーバ部、４１…返信メール処理部、４３…マスタデータベース（マスタＤＢ）。
【技術分野】
【０００１】
本発明の実施形態は、サーバおよび画像処理システムに関する。
【背景技術】
【０００２】
保険会社、銀行などの金融機関における新規取り扱いまたは契約変更などを行う窓口では、犯罪による収益の移転防止に関する法律（犯罪収益移転防止法）への対応として顧客に対する確実な本人確認が必要となっている。
【０００３】
例えば保険会社の窓口で契約者（申請者）が契約変更などの手続きをする際には、運転免許証、各種健康保険証・年金手帳、パスポート（旅券）、外国人登録証明書などの公的証明書（本人確認書類）を申請者が窓口担当者へ手渡し、窓口担当者が申請者と本人確認書類とを見比べて本人確認をしている。
【０００４】
具体的には、申請者から提示された本人確認書類をコピーしたものを窓口担当者が目視し申請者の容姿と見比べることで本人確認が行われてきた。
【０００５】
最近では、モバイルバンキングの口座を開設するにあたり、携帯電話機で人を介さずに行う手続きも始められている。この手続きを行うために、携帯電話機のカメラ機能を利用し免許証や健康保険証などの公的証明書（本人確認書類）を撮影し、その画像を申請用のＷｅｂサイトへ送信するアプリケーションソフトウェア（公的証明書撮影アプリケーション）が実用化されつつある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００６−１８６５６４号
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従来、公的証明書撮影アプリケーションは、ソフトウェアを契約者が所持する携帯電話機へダウンロードする必要があるため、ソフトウェアのダウンロードに要するパケット通信料・時間などのコストを伴う。これは当該アプリケーションを一度程度しか使わない申請者（契約者）にとっては負担が大きいという問題があった。
【０００８】
本発明が解決しようとする課題は、申請者に負担が少ない方法で、本人確認書類から光学的に読み取った画像で本人確認を行うことができるサーバおよび画像処理システムを提供することにある。
【課題を解決するための手段】
【０００９】
実施形態のサーバは、携帯端末とネットワークを介して接続されたサーバであり、受信部、文字認識部、判定部、通知部を有する。前記受信部は所定の契約に関する手続きの種別毎に異なる受信用の電子メールアドレスを持ち、手続きの種別毎の前記アドレスに電子メールを受信する。前記文字認識部は受信された電子メールに添付されている書類の画像に対して文字認識処理を行うことで文字列を得る。前記判定部は前記文字認識部により得られた文字列と、前記サーバに予め登録された本人確認書類毎の文字列候補とを比較し、前記画像の本人確認書類としての種別を判定し、この本人確認書類の種別と前記サーバに予め登録された契約に関する情報とから前記画像が本人確認書類の画像として適切か否かを判定する。前記通知部は前記画像の判定結果を前記携帯端末へ通知する。
【図面の簡単な説明】
【００１０】
【図１】第１実施形態の画像処理システムの概要構成を示す図である。
【図２】携帯端末の構成を示す図である。
【図３】サーバの構成を示す図である。
【図４】第１実施形態の動作を示すフローチャートである。
【図５】携帯端末の本人確認書類送付画面（申請画面）を示す図である。
【図６】携帯端末の送信メール作成画面を示す図である。
【図７】携帯端末の添付データ選択メニュー画面を示す図である。
【図８】カメラ機能による本人確認書類撮影画面を示す図である。
【図９】電子メールアドレスと本人確認書類の画像とが紐付けされてメモリに記憶された様子を示す図である。
【図１０】電子メールアドレスと本人確認書類の画像が手続き別にマスタＤＢに保存される様子を示す図である。
【図１１】不適合の際に電子メールに挿入される定型メッセージの一例を示す図である。
【図１２】第２実施形態の構成を示す図である。
【図１３】ＱＲコード認識画面を示す図である。
【図１４】第２実施形態の動作を示すフローチャートである。
【図１５】第３実施形態の動作を示すフローチャートである。
【図１６】第３実施形態における携帯端末の添付データ選択メニュー画面を示す図である。
【図１７】第４実施形態の動作を示すフローチャートである。
【発明を実施するための形態】
【００１１】
以下、図面を参照して、実施形態を詳細に説明する。
（第１実施形態）
図１は第１実施形態の画像処理装置の構成を示す図である。
図１に示すように、この第１実施形態の画像処理システムは、携帯端末１とサーバ３とを無線基地局２ａおよびインターネットなどのネットワーク２を介して接続して構成されている。携帯端末１は、例えばカメラ付き携帯電話機などであり、保険の契約者などが携行している。サーバ３は、例えば保険会社または保険契約の審査会社などに配置されている。
【００１２】
図２に示すように、携帯端末１は、表示部９、メモリ１０、キー操作部１１、画像取得部１２、電子メール部１３、暗号化部１４、Ｗｅｂアクセス部１５、制御部１７などを有している。
【００１３】
表示部９は、例えば液晶ディスプレイなどであり、画像取得部１２により取得される本人確認書類の画像を表示可能である。メモリ１０は、各部が行う処理の作業領域として利用される。メモリ１０には、画像取得部１２により取得された画像が記憶される。キー操作部１１は、例えばテンキー、矢印キー、決定キーなどの操作ボタン（スイッチ）であり、表示部９に表示された申請画面にある複数の手続きの中からユーザが選択（指定）した手続きを受け付ける。
【００１４】
画像取得部１２は、例えばＣＣＤカメラなどであり、被写体としての本人確認書類を撮像し、その書類の画像を取得する。ＣＣＤカメラの性能（解像度）としては、例えば２００万画素（６５ｄｐｉ）以上あることが好ましい。画像取得部１２による書類撮影の際にキー操作部１１の決定キーは撮像ボタンとして機能する。撮像ボタンの押下によりそのとき画像取得部１２により撮影された画像が取得される。
【００１５】
暗号化部１４は、送信メール作成画面にて作成された、送信メールを暗号化する。電子メール部１３は、暗号化部１４により暗号化された電子メールを送信先のサーバ３へ送信する。
【００１６】
Ｗｅｂアクセス部１５は、サーバ３に対してネットワーク２を通じてアクセスし、サーバ３から受信されたユーザ認証のための画面にてユーザにより入力されたユーザ情報（ユーザＩＤ、パスワードなど）を送り、サーバ３で認証された場合、サーバ３から受信されたメニューページから各種画面（本人確認書類申請用の画面（図５参照）、電子メール作成用の画面である送信メール作成画面（図６参照）など）の要求を行い、受信された画面にて次の操作を行う。
【００１７】
すなわち、Ｗｅｂアクセス部１５は、予め設定されたサーバ３のＷｅｂサイトにアクセスし、ユーザ認証後、サーバ３から受信された申請画面（図５参照）を表示部９に表示し、申請画面で本人確認書類を送る手続きが指定された場合、手続きの種別に応じて送付先の電子メールアドレスが宛先欄に入力された送信メール作成画面（図６参照）をサーバ３から受信し表示部９に表示し、送信メール作成画面における画像添付操作により画像取得部１２により取得された画像を当該電子メールに添付して送信する。制御部１７は、上記各部を統括制御する。
【００１８】
図３に示すように、サーバ３は、メール受信部３１、復号部３２、メモリ３３、文字認識辞書記憶部３４、文字認識部３５、本人確認書類記憶部３６、比較・判定部３７、申込検索・特定部３８、Ｗｅｂサーバ部３９、マスタデータベース４３（以下「マスタＤＢ４３」と称す）などを有するコンピュータであり、ハードウェアとして、上記メモリ３３の他、ハードディスクドライブなどの不揮発性記憶装置、ＣＰＵなどの制御装置などを備えている。
【００１９】
メール受信部３１は、携帯端末１からネットワーク２を通じて送られてきた、暗号化された電子メールを受信する。メール受信部３１には申請手続きの種別毎（項目毎）の電子メールアドレス（以下「受信アドレス」と称す）が複数設定されており、電子メールが各受信アドレスに受信されることで、その電子メールの申請手続きが特定できる。すなわちメール受信部３１は、手続きの種別毎に異なる受信用の電子メールアドレスを持ち、ネットワーク２を通じてアドレス毎（手続きの種別毎）に電子メールを受信する。
【００２０】
復号部３２は、メール受信部３１により受信された、暗号化された電子メールを復号し、電子メールとその添付画像とを対応させてメモリ３３に記憶する。すなわちメモリ３３には、受信された電子メールの内容とその添付画像の画像データが記憶される。
【００２１】
文字認識辞書記憶部３４には、画像から文字を認識するための一般的な辞書が記憶されている。
【００２２】
文字認識部３５は、メール受信部３１により受信された電子メールに添付されている書類の画像に対して予め文字認識辞書記憶部３４に設定された文字認識辞書を用いて文字認識処理を行うことで文字列を得る。
【００２３】
具体的には、文字認識部３５は、メモリ３３の書類画像を読み出して文字認識、つまり書類画像から文字毎の画像を切り出し、切り出した個々の文字の画像と文字認識辞書記憶部３４の辞書のテキストとのペアを生成する。
【００２４】
さらに文字認識部３５は、認識結果の１文字ずつ連続するテキストの行を文節また単語の単位に区切った文字または文字列を生成する。すなわち文字認識部３５は、メール受信部３１により受信された画像に対して予め文字認識辞書記憶部３４に記憶された文字認識辞書を用いて文字認識処理を行い、文字または文字列を得る。
【００２５】
本人確認書類辞書記憶部３６には、申請内容（契約内容確認・変更など）によって必要な本人確認書類の種別（書類識別情報）毎にキーワードが記憶されている。例えば契約内容確認・変更などという申請では、「運転免許証」という本人確認書類が必要である。
【００２６】
この本人確認書類を特定するための運転免許証キーワード（書類特有の文字列候補）として、例えば「免許証」、「本籍」、「住所」、「氏名」、「交付」、「有効」、「番号」、「日生」などのキーワード（文字列候補）が記憶されている。このように本人確認書類辞書記憶部３６は、本人確認書類の種別毎に書類特有の文字列候補を記憶する記憶部として機能する。
【００２７】
申込検索・特定部３８は、文字認識結果（氏名、住所など）をキーワードにしてマスタＤＢ４３を検索し、契約者の申込情報を特定する。すなわち申込検索・特定部３８は、画像から文字認識された氏名、住所、生年月日などをキーにしてマスタＤＢ４３を検索し、当該電子メールの送付者（契約者）の申込情報を特定する。申込検索・特定部３８は、文字認識部３５により得られた文字列が含まれる契約に関する情報（申込情報）を検索する検索部として機能する。
【００２８】
文字認識結果の氏名、住所、生年月日とマスタＤＢ４３に予め登録されている氏名、住所、生年月日の情報と一致する申込情報が見つかった場合、申込検索・特定部３８は、比較・判定部３７へ申込情報を送る。
【００２９】
比較・判定部３７は、申込検索・特定部３８から受け取った申込情報と本人確認書類の種別の判定結果とを総合して、受信された画像が本人確認書類の画像か否かを判定する。
【００３０】
比較・判定部３７は、文字認識部３５により文字認識されて文字認識結果として得られた文字列と、本人確認書類辞書記憶部３６の書類毎のキーワードとを比較し、画像から得られた文字列全体に対するキーワードの一致／不一致の割合である一致度を求める。すなわち比較・判定部３７は、文字認識部３５により文字認識処理の結果得られた文字列と本人確認書類辞書記憶部３６の書類毎のキーワードとを比較し、一致度が高い書類（書類識別情報）を特定する。
【００３１】
なお、ここでは予め設定した閾値（例えば８０％など）を、一致度が超えた場合に一致度が高いものとし、そのキーワードを持つ本人確認書類（書類識別情報）の種別を特定する。画像の書類が免許証か健康保険証かなどである。
【００３２】
すなわち、比較・判定部３７は、文字認識部により得られた文字列と、本人確認書類辞書記憶部３６の本人確認書類毎の文字列候補とを比較し、画像の本人確認書類としての種別を判定し、この本人確認書類の種別と申込検索・特定部３８により検索された契約に関する情報とから画像が本人確認書類の画像として適切か否かを判定する判定部として機能する。
【００３３】
返信メール処理部４１は、比較・判定部３７による本人確認書類の画像（書類画像）の判定結果を、ネットワーク２を通じて電子メール送信元の携帯端末１へ送り通知する通知部として機能する。復号部３２は、メール受信部３１により受信された電子メール（または添付画像）を復号する。
【００３４】
マスタＤＢ４３は、サーバ３の大容量記憶装置、例えばハードディスクドライブなどに設けられるデータベースである。マスタＤＢ４３には、例えば保険の手続きに関する情報（例えば例えば保険契約者の氏名、住所、生年月日、申込内容、申込日などの保険契約者の申込情報が記憶されている。申込情報を案件情報とも言う。
【００３５】
また、マスタＤＢ４３には、例えば"契約内容変更"という手続きの項目に対してサーバ３の受信アドレスとして、例えば＊＊@xxxx.co.jpなどが対応して記憶され、"契約内容確認"という手続きの項目に対してサーバ３の受信アドレスとして、例えば＊＊＊@xxxx.co.jpが対応して記憶された手続き−電子メールアドレス対応テーブルが設けられている。つまりサーバ３は手続き毎の受信アドレスを有しており、電子メールが受信された受信アドレスによって、手続きの内容を判定できる。
【００３６】
この他、マスタＤＢ４３には、保険の手続きに関する申請のための情報として「契約内容確認・変更」、「保険料振替口座変更」、「保険控除証明書再発行」、「改姓・名、契約者変更、受取人変更」、「入院給付金請求」、「死亡保険金請求」などの項目が記憶されている。
【００３７】
このうち、申請が例えば「契約内容変更」であれば、手続き名称として「契約内容変更」と、この契約内容変更に関して必要な書類の情報（「運転免許証」、「健康保険証」…など）が記憶されている。
【００３８】
マスタＤＢ４３には、所定の契約（保険契約）に関する情報（契約者の申込情報）とこの情報に関する手続きを行う上で必要な本人確認書類の種別（契約変更手続きには免許証または健康保険証が必要など）が記憶されている。
【００３９】
返信メール処理部４１は、本人確認書類の画像の判定結果に応じた定型メッセージをメモリ３３から読み出し、定型メッセージを電子メールの本文に挿入した返信用の電子メールを作成し、画像送付元の携帯端末１へ通知する。すなわち返信メール処理部４１は、比較・判定部３７により判定された本人確認書類判定結果を携帯端末１へ電子メールで通知する。
【００４０】
メモリ３３には、書類画像の判定結果に応じた定型メッセージが記憶されている。例えば判定結果が本人確認書類の画像として「適切」の場合、本人確認書類の画像を正常に受理した旨の通知情報として、例えば「お送りいただきました本人確認書類の画像は正常に受理されました。」などの定型メッセージがメモリ３３に記憶されている。
【００４１】
また「画像が不明」であり判定結果が本人確認書類の画像として「不適切」の場合、読み取り不可の通知情報として、図１１に示すように、「［重要］本人確認書類の再撮影・ご送付のお願い。先ほどご送付頂きました写真は受理できませんでした。理由：文字列が読み取れませんでした。お願い：お手数ですが再撮影・ご送付をお願いいたします。」などの定型メッセージがメモリ３３に記憶されている。
【００４２】
Ｗｅｂサーバ部３９は、携帯端末１からのＷｅｂアクセスの要求によりユーザ認証を行い、認証されたユーザの携帯端末１に対して、要求された各種画面（本人確認書類の申請用の画面（図５参照）、電子メール作成用の画面である送信メール作成画面（図６参照）など）を送る。
【００４３】
次に、図４乃至図８を参照してこの第１実施形態の画像処理システムの動作を説明する。
この第１実施形態の場合、利用者が携帯端末１のキーを操作して、サーバ３のＷｅｂサーバ部３９によりネットワーク２上に公開されている携帯サイト、例えば保険のポータルサイトなどにアクセスし、ログインボタンなどを選択操作すると、ログイン認証用の画面が表示される。
【００４４】
このログイン認証用の画面には、ユーザＩＤとパスワードの入力欄があり、ユーザが入力欄に、ユーザＩＤとパスワードを入力し、ＯＫボタンなどを押下すると、Ｗｅｂサーバ部３９では、入力欄に入力された情報（ユーザＩＤとパスワード）と予め登録されているユーザ情報とを比較し、一致した場合、認証ＯＫとし、契約者だけのメニューページを携帯端末１へ送る。これにより、携帯端末１の表示部９には、申請画面である本人確認書類送付画面５１（図５参照）が表示される。
【００４５】
図５に示すように、本人確認書類送付画面５１には、本人確認書類送付画面５１には、「同意しました。」というメッセージと、その左側に配置されたチェックボックス５２と、申請ボタン５３ａ〜５３ｃなどと、申請のやり方（手順）を示すメッセージ５４とが設けられている。
【００４６】
申請ボタン５３ａ〜５３ｃは、保険契約に関する手続きが項目別に複数、例えば保険申込み、契約内容変更、契約者貸付などが用意されている。各申請ボタン５３ａ〜５３ｃには、その申請毎に異なるサーバ３側の電子メールアドレス（以下「受信アドレス」と称す）のリンクが張られている。
【００４７】
ユーザが、例えば契約内容変更を行うため、契約内容変更の手続きの項目の申請ボタン５３ｂを選択操作し、「同意しました。」のメッセージの左側に位置するチェックボックス５２にチェックを入れると（図４のステップＳ１０１）、Ｗｅｂサーバ部３９は、選択操作された申請ボタン５３ｂの受信アドレスのリンクから、契約内容変更手続き用として設定されているサーバ３の受信アドレス（＊＊＠ｘｘｘｘ．ｃｏ．ｊｐ）への送信メール作成画面５５（図６参照）を携帯端末１の表示部９に表示させる（ステップＳ１０２）。
【００４８】
図６に示すように、送信メール作成画面５５には、宛先欄５６、件名欄５７、添付欄５８、本文欄５９が設けられている。宛先欄５６には、予めサーバ３の契約変更手続き用の受信アドレス５６が予め入力されている。
【００４９】
この送信メール作成画面５５にて、ユーザがファイルを添付するためのボタン６０を押下すると、添付データ選択メニュー画面６１（図７参照）が表示部９に表示される。
【００５０】
図７に示すように、添付データ選択メニュー画面６１には、添付データ選択メニューが設けられている。添付データ選択メニューとして、例えばデータフォルダ、ムービー撮影、フォト撮影、ボイス録音、プロフィール、アドレス帳、タスクリスト…などの項目が設けられている。
【００５１】
この添付データ選択メニュー画面６１において、ユーザがキー操作部１１の矢印ボタンなどで「フォト撮影」６２の項目を選択し（ステップＳ１０３）、「選択」ボタン６３を押下すると、撮影画面６４（図８参照）が表示部９に表示される。
【００５２】
図８に示すように、この撮影画面６４には、画像取得部１２により取得される本人確認書類（被写体）の画像（被写体を免許証とした場合、免許証の画像６５）が映し出される。免許証の他、本人確認書類としては、例えば健康保険証などであってもよい。
【００５３】
撮影では、携帯端末１または免許証のいずれかを動かして、免許証の画像が極力大きくかつ免許証全体が撮影範囲に収まるようにしてキー操作部１１の撮影ボタンを押し、本人確認書類の画像を撮影する（ステップＳ１０４）。
【００５４】
本人確認書類の画像が撮影されると、本人確認書類の画像ファイルが当該電子メールに添付された状態の送信メール作成画面５５が表示部９に表示される。
【００５５】
この送信メール作成画面５５にて、件名や本文が無い状態で、ユーザが携帯端末１の画面のメニューから「送信」の操作を行うことで、送信メールが、暗号化された後、既に宛先欄に入力されているサーバ３の受信アドレス５６へ送信される（ステップＳ１０５）。
【００５６】
一方、サーバ３では、暗号化された電子メールが受信されると、その電子メールを復号し、図９に示すように、電子メールアドレスとこの電子メールに添付されてきた本人確認書類画像とを紐付けしてメモリ３３に保存する（ステップＳ１０６）。
【００５７】
次に、文字認識部３５が、当該本人確認書類画像をメモリ３３から読み出して文字認識（ＯＣＲ）処理し（ステップＳ１０７）、文字認識結果として文字列を得る。
【００５８】
続いて、比較・判定部３７は、本人確認書類辞書記憶部３６を参照して当該画像がこの手続きの証拠として適切か不適切かを判定する（ステップＳ１０８）。
【００５９】
すなわち、この比較・判定部３７では、当該画像の鮮明度や当該画像が本人確認書類として有効か否かを判定する。
【００６０】
詳細には、比較・判定部３７は、本人確認書類辞書記憶部３６から読み出し、文字認識部３５により得られた文字認識結果の文字列とを比較して、文字列候補と文字列との一致／不一致の度合い、つまり互いの文字列の一致度を判定する。
【００６１】
文字列の一致度が予め設定された閾値よりも高い場合、当該画像を有効（適切、合格など）と判定し、文字列の一致度が閾値よりも低い場合、当該画像を無効（不適切、不合格など）と判定する。なお閾値は例えば８０％などに設定されているものとする。この閾値は一例であり、他の値であってもよい。
【００６２】
当該画像の鮮明度については、当該画像の階調変化率を求め、求めた画像の階調変化率が予め設定された閾値を超えたか否かによりピントの合否を判定し、このピントの合否判定結果と画像の有効性判定結果とを合わせて判定してもよい。２つの判定結果を合わせるとは、例えば論理積をとる、または論理和をとるなどの方法が考えられる。
【００６３】
本人確認書類の有効性判定の結果として、当該画像が証拠として適切（合格）である場合（ステップＳ１０８の「適切」）、図１及び図１０に示すように、手続きの種別毎に、申請者の電子メールアドレスと当該画像（受信された本人確認書類の画像）とを、既にマスタＤＢ４３に登録されている契約者の申込情報に対応させて、マスタＤＢ４３に保存する（ステップＳ１０９）。
【００６４】
これと共に、返信メール処理部４１は、比較・判定部３７の有効性判定結果が有効であれば、画像を受理した旨の定型メッセージを電子メールに挿入し、申請元の携帯端末１へ返信する（ステップＳ１１０）。
【００６５】
一方、比較・判定部３７の有効性判定結果が有効でない、つまり不合格（画像を受理不可）の場合、当該画像と手続きの種別毎に受信した電子メールの電子メールアドレスとをメモリ３３に一時保存した後（ステップＳ１１１）、メモリ３３に一時保存した電子メールアドレスを宛先欄に設定し、図１１に示すように、不合格理由の定型メッセージ（本人確認書類の画像の再取得要請コメント）を書き込んだ電子メールを申請元の携帯端末１へ返信する（ステップＳ１１２）。
【００６６】
このようにこの第１実施形態によれば、本人確認書類の画像の確認手続きに必要なアプリケーションを、携帯端末１からサーバ３へのＷｅｂアクセスで提供されるＷｅｂアプリケーションで実現し、携帯端末１のカメラ機能を利用して本人確認書類を撮影および送付する。つまりネットワークからダウンロードするアプリケーションソフトウェアを用いることなく、本人確認書類の画像を手続き先へ送り、確認結果を受け取ることができる。
【００６７】
これにより、ソフトウェアを契約者の携帯端末１にダウンロードする必要がないため、ソフトウェアのダウンロードに要するパケット通信料・時間などのコストを少なくし、当該アプリケーションを一度程度しか使わない契約者の負担を軽減することができる。
【００６８】
より具体的には、携帯サイトへの入力内容と電子メールで送られてきた画像の文字認識結果とから当該手続きを導き出し、画像が本人確認書類の画像として適切か否かを判定し、適切であれば、その旨を申請元の携帯端末１へ通知し、不適切であれば、再送要求を通知するので、申請者に負担が少ない方法で、本人確認書類から携帯端末１で光学的に読み取った画像で本人確認を行うことができる。
またこの第１実施形態によれば、受信された電子メールに応じた手続きの種別または電子メールに添付されていた画像データから取得した文字情報を基に既入力情報である申込情報を探索して、案件を特定して紐付け保存することにより手続きの確実性を担保することができる。
【００６９】
さらに、本実施形態では、画像における階調変化率を確認することにより被写体全体のピントの合否を確認することで、文字列だけでなく、絵や写真の部分についても見易さ（見読性）を確認できる。
また、本実施形態では、画像が受理不可である旨のメッセージを入れた電子メールを申請者の携帯端末１へ返信することで、画像受理不可の理由についても場合分けして通知するので、撮影者のユーザビリティを高くするこができる。
【００７０】
（第２実施形態）
次に、図１２及び図１３を参照して第２実施形態を説明する。図１２は第２実施形態の画像処理システムの携帯端末の構成を示す図、図１３は第２実施形態の動作を示すフローチャートである。なお第１実施形態と同様の構成には同一の符号を付しその説明は省略する。
【００７１】
図１２に示すように、この第２実施形態の場合、携帯端末１は、ＱＲコード認識部１８を備える。ＱＲコード認識部１８はユーザがこれから電子メールを送る手続きの受信アドレスのリンクを含むＱＲコードを読み取り、コードの内容を認識する。
【００７２】
すなわちＱＲコード認識部１８は、画像取得部１２により画像が取得される手続きに対応する電子メールアドレスのリンクをＱＲコードから得る。ＱＲコードは保険手続きのパンフレッドやＰＣ用Ｗｅｂサイトなどに、予め手続き別に複数表示されているものとする。つまりＱＲコードは手続きの種別毎に予め保険手続きのパンフレッドに印刷、またはＰＣ用Ｗｅｂサイトなどに表示されている。
【００７３】
この第２実施形態の場合、ＱＲコード認識部１８は、携帯端末１の表示部９に、図１３に示すようなＱＲコード認識画面７１を表示する。
【００７４】
このＱＲコード認識画面７１には、認識範囲を示す枠線７２が設けられており、パンプレットに印刷された手続きを示すＱＲコード７３が枠線７２内に入るように画像取得部１２のカメラ機能にて撮像することで、ＱＲコード認識部１８は、ＱＲコード７３を認識し、手続きに対応する受信アドレスのリンクを取得する（図１４のステップＳ２０１）。ステップＳ１０２以降の処理は、第１実施形態と同様である。
【００７５】
このようにこの第２実施形態によれば、ＱＲコード認識部１８を設けて、手続きに対応する受信アドレスのリンクをＱＲコード７３から取得することで、第１実施形態の効果に加え、手続きの指定（入力）を容易にかつ確実に行うことができる。
【００７６】
すなわち、受信アドレスのリンクをＱＲコード７３から取得することで、ユーザが受信アドレスをキー入力したときに発生しやすい入力ミスやキー入力の手間などを軽減することができる。
【００７７】
換言すると、手続き先の電子メールアドレスを携帯端末１に入力する手段として、ＱＲコードを採用したことで、紙面やＰＣ用Ｗｅｂサイトとの連携でキー入力を極力少なくした手続きを行うことができる。
【００７８】
（第３実施形態）
次に、図１５、図１６を参照して第３実施形態を説明する。図１５は第３実施形態の動作を示すフローチャート、図１６は携帯端末１の添付データ選択メニュー画面を示す図である。なおこの第３実施形態の構成は第２実施形態と同様である。
【００７９】
この第３実施形態の場合、保険の申し込みや契約内容変更などの手続を行うＰＣ用Ｗｅｂサイトや保険契約のパンフレットなどに本人確認書類の画像の撮影方法を明示しておき、利用者はその内容に従って携帯端末１の画像取得部１２のカメラ機能で本人確認書類を撮影し、携帯端末１のメモリ１０に予め保存しておく（ステップＳ３０１）。
【００８０】
また、第２実施形態と同様にＰＣ用Ｗｅｂサイトや保険契約のパンフレットに設けられた本人確認書類の画像送付先であるサーバ３の受信アドレスのリンクを示す暗号情報としてのＱＲコード（コード情報）を手続きの種別毎に複数表示しておき、ユーザは携帯端末１を操作して、所望の手続きのＱＲコードを携帯端末１のカメラ機能にて読み取り、ＱＲコード認識部１８がコードの内容を認識し、受信アドレスのリンクを取得する（ステップＳ３０２）。暗号情報はＱＲコード以外に、例えばバーコードなどであってもよい。
【００８１】
ＱＲコード認識部１８は、ＱＲコードの内容である受信アドレスのリンクを取得すると、手続き用の受信アドレスへの送信メール作成画面５５（図６参照）を表示部９に表示させる。
【００８２】
この送信メール作成画面５５にて、件名や本文が入力されていない空メールの状態で、ユーザが「添付」を選択するボタン６０を押下すると、添付データ選択メニュー画面６１（図１６参照）が表示部９に表示される（ステップＳ３０３）。
【００８３】
図１６に示すように、この添付データ選択メニュー画面６１において、撮影済みの画像（保存画像）が保存されている「データフォルダ」６６を選択し、「全データ表示」という機能で開いた画面の中から、予め撮影しておいた本人確認書類の画像を選択し（ステップＳ３０４）、キー操作部１１の「確定」ボタンを押下すると、当該電子メールが暗号化され、既に宛先として入力されているサーバ３の受信アドレスへ送信される（ステップＳ３０５）。ステップＳ１０６以降のサーバ３側での処理は第１実施形態と同様である。
【００８４】
この第３実施形態によれば、携帯端末１で予め撮影しておいた本人確認書類の画像を読み出して電子メールに添付し送信するので、ＷＥＢアクセス時の作業時間を短縮することができる。
【００８５】
（第４実施形態）
次に、図１７を参照して第４実施形態を説明する。図１７は第４実施形態の動作を示すフローチャートである。なおこの第４実施形態の構成は第１実施形態と同様である。
【００８６】
この第４実施形態の場合、携帯端末１に表示された申請のための本人確認書類送付画面５１（図５参照）から、所望の手続きの申請ボタン５３ａ〜５３ｃのいずれかが押下されステップＳ４０１）、送信メール作成画面（図６参照）を表示するための要求があった場合、サーバ３のＷｅｂサーバ部３９は、手続きの種別毎に所定の発行ルールでワンタイムメールアドレスを作成および発行し、そのワンタイムメールアドレスを宛先欄に挿入した送信メール作成画面（図６参照）を携帯端末１の表示部９に表示させる。ステップＳ１０２以降の処理は第１実施形態と同様である。
【００８７】
この第４実施形態によれば、携帯端末１からアクセスするＷｅｂサイト（携帯サイト）でワンタイム・メールアドレスを発行することで、件名や本文無しでかつ画像添付漏れで電子メールが送信されてきた場合であっても、携帯端末１から申請された手続きをサーバ３の側で特定することができる。
また、データ送信にはワンタイムメールアドレスを使用することにより空メールであっても案件を特定でき、同時に悪意ある第三者による犯罪利用を防止することができる。
【００８８】
なお、上記各実施形態において携帯端末１から電子メールで本人確認書類の画像をサーバ３へ送信する際、携帯端末１が、例えば携帯電話機などでは、通信料金（パケット代）がユーザの負担になる。
【００８９】
そこで、ユーザに対してパケット代を補填するため、フリーダイヤルのように受け手がパケット代を払うメールアドレスの仕組みを用いる。具体的には、キャリヤ間のサービス連携により特定メールアドレスへのパケット送信料を受け手側に請求する仕組みを採用するか、もしくは例えば当該手続きが保険金請求であった場合、パケット代相当分を保険金等の支払い時に合算して入金する仕組みとすることが好ましい。
【００９０】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【００９１】
上記実施形態では、携帯端末１としての一例に、カメラ付き携帯電話機を例示したが、この他、例えばインターネット接続機能とカメラ機能を搭載したＰＤＡ、タブレット端末および電子ブック端末などであってもよい。
【００９２】
上記実施形態では、画像ファイル名の一部に、書類の種別を識別するための識別情報を含ませたが、この他、例えば画像自体に電子透かしとして識別情報を埋め込んでもよい。この場合、書類の識別情報を隠蔽できるため、書類画像の不正利用などを抑止することができる効果がある。
【００９３】
また、上記実施形態に示した各構成要素を、コンピュータのハードディスク装置などのストレージにインストールしたプログラムで実現してもよく、また上記プログラムを、コンピュータ読取可能な電子媒体：electronic mediaに記憶しておき、プログラムを電子媒体からコンピュータに読み取らせることで本発明の機能をコンピュータが実現するようにしてもよい。電子媒体としては、例えばＣＤ−ＲＯＭ等の記録媒体やフラッシュメモリ、リムーバブルメディア：Removable media等が含まれる。さらに、ネットワークを介して接続した異なるコンピュータに構成要素を分散して記憶し、各構成要素を機能させたコンピュータ間で通信することで実現してもよい。
【符号の説明】
【００９４】
１…携帯端末、２…ネットワーク、２ａ…無線基地局、３…サーバ、９…表示部、１０…メモリ、１１…キー操作部、１２…画像取得部、１３…電子メール部、１４…暗号化部、１５…Ｗｅｂアクセス部、１７…制御部、１８…ＱＲコード認識部、３１…メール受信部、３２…復号部、３３…メモリ、３４…文字認識辞書記憶部、３５…文字認識部、３６…本人確認書類辞書記憶部、３７…比較・判定部、３８…申込検索・特定部、３９…Ｗｅｂサーバ部、４１…返信メール処理部、４３…マスタデータベース（マスタＤＢ）。
【特許請求の範囲】
【請求項１】
携帯端末にネットワークを介して接続されたサーバにおいて、
所定の契約に関する手続きの種別毎に異なる受信用の電子メールアドレスを持ち、前記手続きの種別毎の前記アドレスに電子メールを受信する受信部と、
前記携帯端末から受信された電子メールに添付されている書類の画像に対して文字認識処理を行うことで文字列を得る前記文字認識部と、
前記文字認識部により得られた文字列と、前記サーバに予め登録された本人確認書類毎の文字列候補とを比較し、前記画像の本人確認書類としての種別を判定し、この本人確認書類の種別と前記サーバに予め登録された契約に関する情報とから前記画像が本人確認書類の画像として適切か否かを判定する判定部と、
前記画像の判定結果を前記携帯端末へ通知する前記通知部と
を有するサーバ。
【請求項２】
送付先のアドレスとしてワンタイムアドレスを発行する請求項１記載のサーバ。
【請求項３】
前記判定部は、
前記画像の階調変化率を求め、求めた前記画像の階調変化率が予め設定された閾値を超えたか否かによりピントの合否を判定し、このピントの合否判定結果を前記本人確認書類判定結果の一つに含める請求項１または２記載のサーバ。
【請求項４】
携帯端末とサーバとをネットワークを介して接続した画像処理システムにおいて、
前記携帯端末は、
本人確認書類の画像を取得する画像取得部と、
前記画像取得部により取得される前記本人確認書類の画像を表示可能な表示部と、
予め設定された前記サーバのＷｅｂサイトにアクセスし、ユーザ認証後、前記サーバから受信された申請画面を前記表示部に表示し、前記申請画面で前記本人確認書類を送る手続きが指定された場合、手続きの種別に応じて送付先のアドレスが宛先欄に入力された送信メール作成画面を前記サーバから受信し前記表示部に表示し、前記送信メール作成画面における画像添付操作により前記画像取得部により取得された画像を電子メールに添付して送信するＷｅｂアクセス部とを有し、
前記サーバは、
所定の契約に関する情報とこの情報に関する手続きを行う上で必要な本人確認書類の種別が記憶されたデータベースと、
前記携帯端末からのＷｅｂアクセスの要求によりユーザ認証を行い、認証されたユーザの前記携帯端末に対して、要求された画面を送るＷｅｂサーバ部と、
前記手続きの種別毎に異なる受信用の電子メールアドレスを持ち、前記ネットワークを通じて前記アドレス毎に電子メールを受信する受信部と、
前記手続きに必要な本人確認書類の種別毎に書類特有の文字列候補を記憶する記憶部と、
前記受信部により受信された電子メールに添付されている書類の画像に対して予め設定された文字認識辞書を用いて文字認識処理を行うことで文字列を得る文字認識部と、
前記文字認識部により得られた文字列が含まれる契約に関する情報を検索する検索部と、
前記文字認識部により得られた文字列と、前記記憶部の本人確認書類毎の文字列候補とを比較し、前記画像の本人確認書類としての種別を判定し、この本人確認書類の種別と前記検索部により検索された契約に関する情報とから前記画像が本人確認書類の画像として適切か否かを判定する判定部と、
前記判定部により判定された前記本人確認書類としての画像の判定結果を電子メール送信元の前記携帯端末へ電子メールで通知する通知部と
を有する画像処理システム。
【請求項５】
前記携帯端末は、
前記本人確認書類の画像の送付先の電子メールアドレスまたはそのリンクをＱＲコードから得るＱＲコード認識部を有する請求項４記載の画像処理システム。
【請求項６】
前記サーバは、
送付先のアドレスとしてワンタイムアドレスを発行する請求項４記載の画像処理システム。
【請求項７】
前記判定部は、
前記画像の階調変化率を求め、求めた前記画像の階調変化率が予め設定された閾値を超えたか否かによりピントの合否を判定し、このピントの合否判定結果を前記本人確認書類判定結果の一つに含める請求項４乃至６いずれか１記載の画像処理システム。
【請求項８】
前記携帯端末は、前記サーバへの前記電子メールを暗号化する暗号部を有する請求項４乃至７いずれか１記載の画像処理システム。
【請求項９】
前記送信メール作成画面における画像添付操作により前記携帯端末に予め保存しておいた本人確認書類の画像を添付する請求項４乃至８いずれか１記載の画像処理システム。
【請求項１】
携帯端末にネットワークを介して接続されたサーバにおいて、
所定の契約に関する手続きの種別毎に異なる受信用の電子メールアドレスを持ち、前記手続きの種別毎の前記アドレスに電子メールを受信する受信部と、
前記携帯端末から受信された電子メールに添付されている書類の画像に対して文字認識処理を行うことで文字列を得る前記文字認識部と、
前記文字認識部により得られた文字列と、前記サーバに予め登録された本人確認書類毎の文字列候補とを比較し、前記画像の本人確認書類としての種別を判定し、この本人確認書類の種別と前記サーバに予め登録された契約に関する情報とから前記画像が本人確認書類の画像として適切か否かを判定する判定部と、
前記画像の判定結果を前記携帯端末へ通知する前記通知部と
を有するサーバ。
【請求項２】
送付先のアドレスとしてワンタイムアドレスを発行する請求項１記載のサーバ。
【請求項３】
前記判定部は、
前記画像の階調変化率を求め、求めた前記画像の階調変化率が予め設定された閾値を超えたか否かによりピントの合否を判定し、このピントの合否判定結果を前記本人確認書類判定結果の一つに含める請求項１または２記載のサーバ。
【請求項４】
携帯端末とサーバとをネットワークを介して接続した画像処理システムにおいて、
前記携帯端末は、
本人確認書類の画像を取得する画像取得部と、
前記画像取得部により取得される前記本人確認書類の画像を表示可能な表示部と、
予め設定された前記サーバのＷｅｂサイトにアクセスし、ユーザ認証後、前記サーバから受信された申請画面を前記表示部に表示し、前記申請画面で前記本人確認書類を送る手続きが指定された場合、手続きの種別に応じて送付先のアドレスが宛先欄に入力された送信メール作成画面を前記サーバから受信し前記表示部に表示し、前記送信メール作成画面における画像添付操作により前記画像取得部により取得された画像を電子メールに添付して送信するＷｅｂアクセス部とを有し、
前記サーバは、
所定の契約に関する情報とこの情報に関する手続きを行う上で必要な本人確認書類の種別が記憶されたデータベースと、
前記携帯端末からのＷｅｂアクセスの要求によりユーザ認証を行い、認証されたユーザの前記携帯端末に対して、要求された画面を送るＷｅｂサーバ部と、
前記手続きの種別毎に異なる受信用の電子メールアドレスを持ち、前記ネットワークを通じて前記アドレス毎に電子メールを受信する受信部と、
前記手続きに必要な本人確認書類の種別毎に書類特有の文字列候補を記憶する記憶部と、
前記受信部により受信された電子メールに添付されている書類の画像に対して予め設定された文字認識辞書を用いて文字認識処理を行うことで文字列を得る文字認識部と、
前記文字認識部により得られた文字列が含まれる契約に関する情報を検索する検索部と、
前記文字認識部により得られた文字列と、前記記憶部の本人確認書類毎の文字列候補とを比較し、前記画像の本人確認書類としての種別を判定し、この本人確認書類の種別と前記検索部により検索された契約に関する情報とから前記画像が本人確認書類の画像として適切か否かを判定する判定部と、
前記判定部により判定された前記本人確認書類としての画像の判定結果を電子メール送信元の前記携帯端末へ電子メールで通知する通知部と
を有する画像処理システム。
【請求項５】
前記携帯端末は、
前記本人確認書類の画像の送付先の電子メールアドレスまたはそのリンクをＱＲコードから得るＱＲコード認識部を有する請求項４記載の画像処理システム。
【請求項６】
前記サーバは、
送付先のアドレスとしてワンタイムアドレスを発行する請求項４記載の画像処理システム。
【請求項７】
前記判定部は、
前記画像の階調変化率を求め、求めた前記画像の階調変化率が予め設定された閾値を超えたか否かによりピントの合否を判定し、このピントの合否判定結果を前記本人確認書類判定結果の一つに含める請求項４乃至６いずれか１記載の画像処理システム。
【請求項８】
前記携帯端末は、前記サーバへの前記電子メールを暗号化する暗号部を有する請求項４乃至７いずれか１記載の画像処理システム。
【請求項９】
前記送信メール作成画面における画像添付操作により前記携帯端末に予め保存しておいた本人確認書類の画像を添付する請求項４乃至８いずれか１記載の画像処理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２０１２−９８８２３（Ｐ２０１２−９８８２３Ａ）
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【出願番号】特願２０１０−２４４４７９（Ｐ２０１０−２４４４７９）
【出願日】平成２２年１０月２９日（２０１０．１０．２９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＱＲコード
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【出願日】平成２２年１０月２９日（２０１０．１０．２９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＱＲコード
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
[ Back to top ]