JP7261754B2 - 電子データ仲介サーバ - Google Patents

Description

本発明は、電子データ仲介サーバに関する。

電気会社が発行する電気料金請求書やガス会社が発行するガス料金請求書や銀行が発行するローン利用明細などの帳票について、従来、発行企業がそのような帳票を紙に印刷して郵送でユーザに届けていた。

通信インフラが整備され、企業のＩＴ投資も十分に進み、一人一台スマートフォンを持つことが当たり前となってきた我が国の現在の状況においては、上記のような紙ベースの帳票の交付の短所が目立つようになってきている。すなわち、紙ベースでは印刷コストや郵送費などのコストが嵩み、また大量の紙資源を用いることから環境に優しくなく、さらには誤配送や紛失等のリスクの懸念もある。

そこで、例えば非特許文献１に記載されるような帳票の電子交付の仕組みが提案されている。

「ＭｙＰｏｓｔ」、日本郵便株式会社、ＵＲＬ：https://www.post.japanpost.jp/service/mypost/、２０１９年１２月１６日検索

しかしながら、非特許文献１に記載されるような電子交付サービスの普及は思ったほど進んでいない。本発明者等は上記のような電子交付サービスの普及が進まない原因として以下の課題があると認識する。
（１）ＩＤ連携の正確性、即時性に欠ける
非特許文献１に記載のシステムでは、システムＩＤとサービス提供企業が保有するユーザＩＤとの対応付けが「住所、氏名、生年月日」だけであるため、住所表示のブレを自動で吸収できず、手作業が介在する。このため、対応付けの正確性と即時性、汎用性に課題がある。
（２）サービス事業者による本人確認の不確実性
サービス事業者において、本人確認が不十分な場合が多く、システム側で本人確認をしっかり行っていても、対応付けの実効性に少なからぬ不確実性が残る。
（３）キラーコンテンツの不在
サービスが閲覧のみであり、他サービスとの連携といったキラーコンテンツが存在しないため、利用者が少ない。

本発明はこうした課題に鑑みてなされたものであり、その目的は、上記の課題の少なくともひとつを解決することで電子データを仲介するサービスの普及を促進することができる技術の提供にある。

本発明のある態様は、電子データ仲介サーバに関する。この電子データ仲介サーバは、電子データ仲介サービスを提供する電子データ仲介サーバであって、金融機関を介した支払いに用いられる所定のフォーマットを有する番号と、当該番号に関連付けられた電子データと、を、電子データを発行する側の発行ユーザから、ネットワークを介して取得する手段と、取得された番号に対応する、電子データを受け取る側の受け取りユーザを、前記金融機関を介して特定する手段と、取得された番号に関連付けられた電子データを、特定された受け取りユーザにネットワークを介して提供する手段と、を備え、前記特定する手段は、前記取得された番号に対応する受け取りユーザを特定するように金融機関に問い合わせる手段と、前記金融機関によって特定された、前記取得された番号に対応する受け取りユーザを受け取る手段と、を含み、前記金融機関は、前記所定のフォーマットを有する番号と、前記受け取りユーザとを対応付けて保持しており、前記金融機関を介した支払いは口座振替であり、前記所定のフォーマットを有する番号は、数字４桁の金融機関コードと、数字３桁の店番号と、数字１桁の預金種別と、数字７桁の口座番号と、を含む。

なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。

本発明によれば、電子データを仲介するサービスの普及を促進することができる。

実施の形態に係る電子交付システムの模式図である。 図２（ａ）～（ｃ）は、決済情報保持部の一例を示すデータ構造図である。 図３（ａ）、（ｂ）は、ユーザ情報保持部の一例を示すデータ構造図である。 図４（ａ）、（ｂ）は、事業者端末から電子交付サーバに送信されるアップロードデータのデータフォーマットを示すデータ構造図である。 図１の電子交付サーバのハードウエア構成図である。 図１の電子交付サーバの機能および構成を示すブロック図である。 図６の帳票データ保持部の一例を示すデータ構造図である。 図６のログイン情報保持部の一例を示すデータ構造図である。 図１の電子交付システムにおける処理の流れを示すチャートである。 ユーザ端末のディスプレイに表示されるログイン画面の代表画面図である。 ユーザ端末のディスプレイに表示されるトップ画面の代表画面図である。 ユーザ端末のディスプレイに表示される帳票一覧画面の代表画面図である。 ユーザ端末のディスプレイに表示される帳票詳細画面の代表画面図である。

以下、各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。また、各図面において説明上重要ではない部材の一部は省略して表示する。

図１は、実施の形態に係る電子交付システム２の模式図である。電子交付システム２は、様々な事業体が発行する様々な帳票を一括して電子交付する電子交付サービスを提供する。従来の各事業体がユーザに紙で帳票を交付する形態では、印刷のコストがかさみ、環境への配慮も不十分であり、様々なリスクの懸念もあった。本実施の形態に係る電子交付システム２で実現される電子交付サービスでは帳票が電子交付されるので、事業体による帳票印刷が不要になり、紙資源の消費が抑えられ、紛失や誤配送のリスクも無くなるので、従来システムの課題が解決される。

帳票は、金銭や物品、役務（サービス）の取引や出入りを記録した、帳簿や伝票などの定型的な書類の総称である。帳票は、証跡となる記録を残したり、情報を人に伝達したりする役割がある。例えば、帳票は、金銭取引を記録する請求書や振込伝票などの書類、物品などモノを配送するための流通を記録する配送伝票、成績表や健康診断の結果通知書などのサービス情報を伝達する書類、組織における人の動きを伝達する出張申請や出退勤などの書類、を含む。

電子交付システム２は、複数の事業者端末１０、１２、１４と、複数の金融機関サーバ２２、２４と、ユーザ端末３０と、電子交付サーバ１００と、を備える。事業者端末は電子交付サービスを利用する、インフラ企業（電気会社やガス会社など）や金融機関（銀行など）などの事業者の端末である。図１の例では第１事業者の第１事業者端末１０と、第２事業者の第２事業者端末１２と、第３事業者の第３事業者端末１４と、が設けられている。以下、複数の事業者端末を事業者端末と総称する場合がある。金融機関サーバは電子交付サービスに参加する銀行や証券会社などの金融機関の端末である。図１の例では第１金融機関の第１金融機関サーバ２２と、第２金融機関の第２金融機関サーバ２４と、が設けられている。以下、複数の金融機関サーバを金融機関サーバと総称する場合がある。ユーザ端末３０は電子交付サービスを利用する法人または個人であるユーザの端末である。図１ではひとつのユーザ端末３０を示しているが、ユーザ端末の数に制限はない。同様に、事業者端末や金融機関サーバの数にも制限はない。電子交付システム２に含まれる各端末、各サーバはインターネットなどのネットワーク（不図示）を介して互いに通信可能に接続される。

事業者およびユーザはいずれも電子交付サービスのユーザであるが、帳票の発行および受け取りの観点では、事業者は帳票（のデータ）を発行する側の発行ユーザであり、ユーザは帳票を受け取る側の受け取りユーザである。以下、単にユーザと称する場合は帳票を受け取る側の受け取りユーザを指す。

電子交付サーバ１００は、口座情報またはクレジットカード情報を活用したＩＤ連携により、事業者からユーザへの帳票の電子交付を仲介する。電子交付サーバ１００は、金融機関が有するユーザの口座情報やクレジットカード情報を用いることによって、各事業者から送られてくる帳票データをユーザごとに名寄せし、保持部に格納する。電子交付サーバ１００はユーザから要求があると、格納している情報から要求元のユーザに対して発行された帳票を抽出して該ユーザに提供する。なお、帳票データは、事業者がユーザに発行する帳票の電子交付に係る電子データであり、例えばｐｄｆ形式のデータやテキスト形式のデータであってもよい。帳票データは帳票を電子化した任意の形式のデータであってもよい。

より詳細には以下の通りである。
一般に、事業者はサービス提供にあたり、口座振替やクレジットカード払いなど、ユーザから何らかの決済情報（口座情報やクレジットカード情報）を入手して利用料の決済を行っていることが多い。その際には、ユーザから銀行届出印を押印した口座振替依頼書等の提出を受けており、印鑑が符合すれば厳格な本人確認が行われていると解される。

金融機関または金融機関から委任された第三者は、自社内または電子交付サーバ１００内に、ユーザが自社に保有する口座情報等と該ユーザの電子交付サイトＩＤとを対応付けて保有している。電子交付サイトＩＤは、電子交付サービスにおいてユーザを一意に特定する。電子交付サーバ１００は、事業者が保有する口座情報やクレジットカード情報を金融機関が保有する電子交付サイトＩＤに変換することで、事業者が帳票を発行したユーザを一意に、かつ迅速に認識することが可能となる。

本実施の形態に係る電子交付サービスによってもたらされる価値は、不特定多数のサービス事業者とユーザとを、電子的に、相互に、迅速かつ確実に（本人確認を含む）接続する点にある。付随するメリットとして、銀行などの金融機関や事業者が電子交付サイト上でさまざまなサービスを提供することにより、ユーザによるサイトの閲覧率が高くなることがある。

ユーザが法人の場合、電子交付サイトＩＤとして法人番号を利用してもよく、その場合は、さらに複数の金融機関の電子交付サイトＩＤを統合する効果が加わり、社会的効率性は大きく上昇する。本実施の形態では、電子交付サイトＩＤは法人番号のように参加する複数の金融機関に亘って共通のＩＤとする。別の実施の形態では、金融機関ごとに独自のＩＤがユーザに割り当てられ、電子交付サイトにおいて金融機関独自のＩＤが電子交付サイトＩＤに変換されてもよい。

各事業者端末は、ユーザから当該事業者への金融機関を介した支払いに用いられる所定のフォーマットを有する番号を含む決済情報を保持する決済情報保持部を有する。図１の例では、第１事業者端末１０は、ユーザから第１事業者への口座振替による支払いに係る情報を保持する第１決済情報保持部１０ａを有する。第２事業者端末１２は、ユーザから第２事業者への口座振替による支払いに係る情報を保持する第２決済情報保持部１２ａを有する。第３事業者端末１４は、ユーザから第３事業者へのクレジットカード払いに係る情報を保持する第３決済情報保持部１４ａを有する。

各金融機関サーバは、所定のフォーマットを有する番号と、電子交付サイトＩＤと、を対応付けて保持するユーザ情報保持部を有する。図１の例では、第１金融機関サーバ２２は、ユーザが第１金融機関に有する口座の口座番号などの口座情報と、当該ユーザの電子交付サイトＩＤと、を対応付けて保持する第１ユーザ情報保持部２２ａを有する。第２金融機関サーバ２４は、第２金融機関がイシュアまたはアクワイアラとなっているクレジットカードサービスにおけるユーザのクレジットカード情報と、当該ユーザの電子交付サイトＩＤと、を対応付けて保持する第２ユーザ情報保持部２４ａを有する。

図２（ａ）～（ｃ）は、決済情報保持部の一例を示すデータ構造図である。図２（ａ）は第１事業者端末１０が備えている第１決済情報保持部１０ａの一例を示す。第１決済情報保持部１０ａは、ユーザを第１事業者の顧客として第１事業者において特定する顧客番号と、当該ユーザと取り交わした口座振替契約により取得した口座情報と、を対応付けて保持する。口座情報は、全国銀行協会が定めるフォーマットを有する複数の番号と、カナ氏名と、を含む。具体的には、口座情報は、数字４桁の金融機関コードと、数字３桁の店番号と、数字１桁の預金種別と、数字７桁の口座番号と、カナ氏名と、を含む。金融機関コード、店番号、預金種別、口座番号については、全国銀行協会が金融機関に発出した通達で定める定義によるものとする。
本実施の形態に係る電子交付サービスにおいて、カナ氏名はチェックデジットとして機能する。

図２（ｂ）は第２事業者端末１２が備えている第２決済情報保持部１２ａの一例を示す。第２決済情報保持部１２ａは、図２（ａ）に示される第１決済情報保持部１０ａと同様のデータ構造を有する。

図２（ｃ）は第３事業者端末１４が備えている第３決済情報保持部１４ａの一例を示す。第２決済情報保持部１４ａは、ユーザを第３事業者の顧客として第３事業者において特定する顧客番号と、当該ユーザと取り交わしたクレジットカード払いの契約により取得したクレジットカード情報と、を対応付けて保持する。クレジットカード情報は、ＩＳＯ／ＩＥＣ ７８１２により制定されるフォーマットを有するクレジットカード番号と、クレジットカードの有効期限と、を含む。

図３（ａ）、（ｂ）は、ユーザ情報保持部の一例を示すデータ構造図である。図３（ａ）は第１金融機関サーバ２２が備えている第１ユーザ情報保持部２２ａの一例を示す。第１ユーザ情報保持部２２ａは、ユーザが第１金融機関に有する銀行口座の金融機関コードと、当該銀行口座の店番号と、当該銀行口座の預金種別と、当該銀行口座の口座番号と、当該銀行口座のカナ氏名と、当該銀行口座の所有者であるユーザの電子交付サイトＩＤと、を対応付けて保持する。

図３（ｂ）は第２金融機関サーバ２４が備えている第２ユーザ情報保持部２４ａの一例を示す。第２ユーザ情報保持部２４ａは、第２金融機関がイシュアまたはアクワイアラとなっているクレジットカードサービスにおけるユーザのクレジットカードのクレジットカード番号と、当該クレジットカードの有効期限と、当該クレジットカードの名義と、当該クレジットカードの所有者であるユーザの電子交付サイトＩＤと、を対応付けて保持する。

図４（ａ）、（ｂ）は、事業者端末から電子交付サーバ１００に送信されるアップロードデータのデータフォーマットを示すデータ構造図である。図４（ａ）は口座振替に係る口座情報を帳票データに付与して送信する場合のデータフォーマットを示す。このアップロードデータは、帳票の発行対象のユーザの口座情報４０２と、帳票データ４０４と、を含む。アップロードデータは、銀行等に電子的に口座振替を依頼するためのデータとは異なることに注意されたい。帳票の発行対象のユーザの口座情報４０２は、事業者端末が帳票データを発行する際、帳票の発行対象のユーザの顧客番号に対応する口座情報を自己の決済情報保持部から読み出すことにより設定される。口座情報４０２は、金融機関コードと、店番号と、預金種別と、口座番号と、カナ氏名と、を含む。

図４（ｂ）はクレジットカード払いに係るクレジットカード情報を帳票データに付与して送信する場合のデータフォーマットを示す。このアップロードデータは、帳票の発行対象のユーザのクレジットカード情報４０６と、帳票データ４０８と、を含む。帳票の発行対象のユーザのクレジットカード情報４０６は、事業者端末が帳票データを発行する際、帳票の発行対象のユーザの顧客番号に対応するクレジットカード情報を自己の決済情報保持部から読み出すことにより設定される。クレジットカード情報４０６は、クレジットカード番号と、有効期限と、を含む。

図５は、実施の形態に係る電子交付サーバ１００のハードウエア構成図である。図１に示される他の端末やサーバは図５に示されるハードウエア構成と同様のハードウエア構成を有していてもよい。電子交付サーバ１００は、メモリ１０４と、プロセッサ１０６と、通信インタフェース１０８と、ディスプレイ１０２と、入力インタフェース１１０と、を含む。これらの要素はそれぞれバス１１２に接続され、バス１１２を介して互いに通信する。

メモリ１０４は、データやプログラムを記憶するための記憶領域である。データやプログラムは、メモリ１０４に恒久的に記憶されてもよいし、一時的に記憶されてもよい。プロセッサ１０６は、メモリ１０４に記憶されているプログラムを実行することにより、電子交付サーバ１００における各種機能を実現する。通信インタフェース１０８は、電子交付サーバ１００の外部との間でデータの送受信を行うためのインタフェースである。例えば、通信インタフェース１０８は事業者端末、ユーザ端末、金融機関サーバと通信するためのインタフェースを含む。ディスプレイ１０２は、各種情報を表示するためのデバイスであり、例えば、液晶ディスプレイや有機ＥＬ（Ｅｌｅｃｔｒｏｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイなどである。入力インタフェース１１０は、ユーザからの入力を受け付けるためのデバイスである。入力インタフェース１１０は、例えば、ディスプレイ１０２上に設けられたタッチパネルや、各種入力キー等を含む。

図６は、図１の電子交付サーバ１００の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。

電子交付サーバ１００は、帳票データ取得部１５０と、ＩＤ特定部１５２と、帳票データ格納部１５４と、ログイン管理部１５６と、提供要求受付部１５８と、帳票データ提供部１６０と、帳票データ保持部１６２と、ログイン情報保持部１６４と、を備える。

図７は、図６の帳票データ保持部１６２の一例を示すデータ構造図である。帳票データ保持部１６２は、口座情報またはクレジットカード情報に関連付けられた帳票データを、ユーザに対応付けて保持する。具体的には、帳票データ保持部１６２は、ユーザの電子交付サイトＩＤと、当該ユーザに発行された帳票データと、を対応付けて保持する。

図８は、図６のログイン情報保持部１６４の一例を示すデータ構造図である。ログイン情報保持部１６４は、電子交付サービスにおけるユーザのユーザ名と、当該ユーザの電子交付サイトＩＤと、当該ユーザのパスワードと、を対応付けて保持する。

図６に戻り、帳票データ取得部１５０は、事業者端末からネットワークを介してアップロードデータを取得する。事業者は周期的にまたは任意のタイミングでユーザに帳票を発行する。その際、事業者端末は帳票の発行先のユーザ（＝顧客番号）に対応する口座情報またはクレジットカード情報を決済情報保持部から取得して帳票データに付与することによってアップロードデータを生成する。帳票データ取得部１５０は複数の事業者端末１０、１２、１４のそれぞれからアップロードデータを取得する。

ＩＤ特定部１５２は、帳票データ取得部１５０によって取得された口座情報またはクレジットカード情報に対応する、帳票データを受け取る側のユーザを特定する。ＩＤ特定部１５２は、ＩＤ問い合わせ部１６６と、応答受取部１６８と、を含む。ＩＤ問い合わせ部１６６は、取得された口座情報またはクレジットカード情報に対応する電子交付サイトＩＤを金融機関に問い合わせる。ＩＤ問い合わせ部１６６は、口座情報またはクレジットカード情報を含む問い合わせ情報を生成し、ネットワークを介して金融機関サーバに送信する。

応答受取部１６８は、ＩＤ問い合わせ部１６６による問い合わせに対する問い合わせ結果を金融機関サーバからネットワークを介して受け取る。問い合わせ結果は、問い合わせ情報に含まれる口座情報またはクレジットカード情報に対応するユーザの電子交付サイトＩＤを含む。

なお、本実施の形態では金融機関サーバがユーザ情報保持部を有し、電子交付サーバ１００が金融機関サーバに問い合わせを行う場合を説明するが、これに限られない。他の実施の形態では、電子交付サーバがユーザ情報保持部を有してもよい。この場合、ＩＤ特定部は、帳票データ取得部によって取得された口座情報またはクレジットカード情報に対応する電子交付サイトＩＤを、自己が有するユーザ情報保持部から取得してもよい。

帳票データ格納部１５４は、帳票データ取得部１５０によって取得された帳票データを、ＩＤ特定部１５２によって特定されたユーザに対応付けて帳票データ保持部１６２に格納する。

ログイン管理部１５６は、ユーザ端末３０とネットワークを介して通信することで、ユーザによる電子交付サービスへのログインを管理する。ログイン管理部１５６は、ユーザ端末３０から受信するユーザのクレデンシャルをログイン情報保持部１６４に登録されている情報と照合し、ログインの成否を決定する。

提供要求受付部１５８は、ログイン済みのユーザ（のユーザ端末３０）から帳票データの閲覧要求を受け付ける。

帳票データ提供部１６０は、ユーザのユーザ端末３０にネットワークを介して帳票データを提供する。帳票データ提供部１６０は、提供要求受付部１５８が閲覧要求を受け付けると、要求元のユーザに対応する帳票データを帳票データ保持部１６２から読み出して当該要求元のユーザのユーザ端末３０に提供する。

以上の構成による電子交付システム２の動作を説明する。
図９は、図１の電子交付システム２における処理の流れを示すチャートである。図９では例として以下の前提があるものとする。（１）ユーザが第１事業者に第１金融機関の口座を通じて口座振替により料金を支払う契約がある。（２）第１事業者がユーザに帳票を発行する。（３）ユーザがその帳票の電子交付を受ける。

第１事業者端末１０は、ユーザに発行する帳票の帳票データと、当該ユーザの顧客番号に対応する口座情報と、を含むアップロードデータを生成する（Ｓ９０２）。第１事業者端末１０は、生成されたアップロードデータを電子交付サーバ１００に、ネットワークを介して送信する（Ｓ９０４）。電子交付サーバ１００は、受信したアップロードデータから口座情報を抽出し、抽出した口座情報を含む問い合わせ情報を生成する（Ｓ９０６）。電子交付サーバ１００は、生成された問い合わせ情報を第１金融機関サーバ２２に送信することで、問い合わせを行う（Ｓ９０８）。第１金融機関サーバ２２は、第１ユーザ情報保持部２２ａを参照し、問い合わせ情報に含まれる口座情報に対応する電子交付サイトＩＤを特定する（Ｓ９１０）。第１金融機関サーバ２２は、特定された電子交付サイトＩＤを電子交付サーバ１００に返信する（Ｓ９１２）。電子交付サーバ１００は、受信した電子交付サイトＩＤに対応付けて、ステップＳ９０６で受信したアップロードデータに含まれる帳票データを帳票データ保持部１６２に格納する（Ｓ９１４）。

ユーザは、自己に発行されている帳票を閲覧するために、ユーザ端末３０から電子交付サーバ１００（のウェブサイト）にアクセスし、ログイン認証を行う（Ｓ９１６）。ログインが成功すると、ユーザはユーザ端末３０から帳票閲覧要求を電子交付サーバ１００に送信する（Ｓ９１８）。電子交付サーバ１００は、帳票閲覧要求を受けると、ログインしたユーザの電子交付サイトＩＤに対応付けて帳票データ保持部１６２に保持されている帳票データを読み出す（Ｓ９２０）。電子交付サーバ１００は、読み出された帳票データをユーザ端末３０に提供する（Ｓ９２２）。

図１の電子交付システム２における処理の流れを、図２、図３、図７、図８に基づきより具体的に説明する。これらの図において、「イワテ タロウ」、「iwatetarou001」は同一人物「岩手 太郎」を指す。

第１事業者は電力会社である。ユーザ「岩手 太郎」はこの電力会社に第１金融機関である銀行（金融機関コード「００００」）の口座を通じて口座振替により料金を支払う口座振替契約を結んでいる。この電力会社は、顧客番号「００１Ａ」で特定される「岩手 太郎」に電気料金請求書を発行する。第１事業者端末１０は、金融機関コード「００００」、店番号「０００」、預金種別「１」、口座番号「０１２３４５６」、カナ氏名「イワテ タロウ」を電気料金請求書のｐｄｆファイルに添付した第１アップロードデータを生成し、電子交付サーバ１００に送信する。

電子交付サーバ１００は、第１アップロードデータから口座情報、すなわち金融機関コード「００００」、店番号「０００」、預金種別「１」、口座番号「０１２３４５６」、カナ氏名「イワテ タロウ」を抽出し、第１金融機関サーバ２２にこの口座情報に対応する電子交付サイトＩＤを問い合わせる。なお、問い合わせ先の金融機関は、抽出された金融機関コードから決定されてもよい。

第１金融機関サーバ２２は第１ユーザ情報保持部２２ａに保持されている金融機関コード「００００」、店番号「０００」、預金種別「１」、口座番号「０１２３４５６」のエントリを特定し、特定されたエントリのカナ氏名「イワテ タロウ」と、問い合わせ情報に含まれるカナ氏名「イワテ タロウ」と、を照合する。それらが一致すれば、第１金融機関サーバ２２は特定されたエントリの電子交付サイトＩＤ「iwatetarou001」を電子交付サーバ１００に返信する。

電子交付サーバ１００は、返信されてきた電子交付サイトＩＤ「iwatetarou001」と、第１アップロードデータに含まれる電気料金請求書のｐｄｆファイルと、を対応付けて帳票データ保持部１６２に登録する。

第２事業者は通信会社である。ユーザ「岩手 太郎」はこの通信会社に銀行（金融機関コード「００００」）の口座を通じて口座振替により料金を支払う口座振替契約を結んでいる。この通信会社は、顧客番号「２５９Ｂ」で特定される「岩手 太郎」に通信料金請求書を発行する。第２事業者端末１２は、金融機関コード「００００」、店番号「０００」、預金種別「１」、口座番号「０１２３４５６」、カナ氏名「イワテ タロウ」を通信料金請求書のｐｄｆファイルに添付した第２アップロードデータを生成し、電子交付サーバ１００に送信する。

電子交付サーバ１００は、第２アップロードデータから口座情報、すなわち金融機関コード「００００」、店番号「０００」、預金種別「１」、口座番号「０１２３４５６」、カナ氏名「イワテ タロウ」を抽出し、第１金融機関サーバ２２にこの口座情報に対応する電子交付サイトＩＤを問い合わせる。第１金融機関サーバ２２は第１ユーザ情報保持部２２ａに保持されている金融機関コード「００００」、店番号「０００」、預金種別「１」、口座番号「０１２３４５６」のエントリを特定し、特定されたエントリのカナ氏名「イワテ タロウ」と、問い合わせ情報に含まれるカナ氏名「イワテ タロウ」と、を照合する。それらが一致すれば、第１金融機関サーバ２２は特定されたエントリの電子交付サイトＩＤ「iwatetarou001」を電子交付サーバ１００に返信する。

電子交付サーバ１００は、返信されてきた電子交付サイトＩＤ「iwatetarou001」と、第２アップロードデータに含まれる通信料金請求書のｐｄｆファイルと、を対応付けて帳票データ保持部１６２に登録する。

第３事業者は水道会社である。「岩手 太郎」はこの水道会社に第２金融機関が発行するクレジットカードにより料金を支払う契約を結んでいる。この水道会社は、顧客番号「２３４Ｃ」で特定される「岩手 太郎」に水道料金請求書を発行する。第３事業者端末１４は、クレジットカード番号「００００－００００－００００－００００」、有効期限「０４／２２」を水道料金請求書のｐｄｆファイルに添付した第３アップロードデータを生成し、電子交付サーバ１００に送信する。なお、問い合わせ先の金融機関は、抽出されたクレジットカード番号から決定されてもよい。

電子交付サーバ１００は、第３アップロードデータからクレジットカード情報、すなわちクレジットカード番号「００００－００００－００００－００００」、有効期限「０４／２２」を抽出し、第２金融機関サーバ２４にこのクレジットカード情報に対応する電子交付サイトＩＤを問い合わせる。第２金融機関サーバ２４は第２ユーザ情報保持部２４ａに保持されているクレジットカード番号「００００－００００－００００－００００」、有効期限「０４／２２」のエントリを特定し、特定されたエントリの電子交付サイトＩＤ「iwatetarou001」を電子交付サーバ１００に返信する。

電子交付サーバ１００は、返信されてきた電子交付サイトＩＤ「iwatetarou001」と、第３アップロードデータに含まれる水道料金請求書のｐｄｆファイルと、を対応付けて帳票データ保持部１６２に登録する。

ユーザ「岩手 太郎」がユーザ端末３０を介して電子交付サービスにログインし、帳票閲覧要求を送信すると、電子交付サーバ１００は「岩手 太郎」の電子交付サイトＩＤ「iwatetarou001」に対応付けて帳票データ保持部１６２に保持されている帳票データ「電気料金請求書.pdf、通信料金請求書.pdf、水道料金請求書.pdf」を読み出す。電子交付サーバ１００は、「岩手 太郎」が使用しているユーザ端末３０に、読み出された三つの帳票データを送信する。これにより、「岩手 太郎」は自分宛の電気料金請求書、通信料金請求書、水道料金請求書を一度のダウンロード作業で取得し、閲覧することができる。

図１０は、ユーザ端末３０のディスプレイに表示されるログイン画面５０２の代表画面図である。ユーザは、ユーザ端末３０のウェブブラウザまたはユーザ端末３０にインストールされたアプリケーションプログラムを介して、電子交付サーバ１００によって提供される電子交付サイトにアクセスする。ログイン画面５０２はこのアクセスの最初にディスプレイに表示される画面である。ユーザはログイン画面５０２のＩＤ入力領域５０４に自己の電子交付サイトＩＤを入力し、ログイン画面５０２のＰＷ入力領域５０６にパスワードを入力し、ログインボタン５０８を押し下げる。すると、ユーザ端末３０は入力された電子交付サイトＩＤおよびパスワードをクレデンシャルとして電子交付サーバ１００に送信する。電子交付サーバ１００のログイン管理部１５６は受信したクレデンシャルとログイン情報保持部１６４に保持される情報とを照合することでログイン認証を行う。ログイン認証に成功すると、ユーザ端末３０のディスプレイにトップ画面５１０が表示される。

図１１は、ユーザ端末３０のディスプレイに表示されるトップ画面５１０の代表画面図である。トップ画面５１０は、３つのメニュー、すなわち帳票閲覧メニュー５１２、電子契約メニュー５１４、サービス申込メニュー５１６、を有する。ユーザが帳票閲覧メニュー５１２の参照ボタン５１８を押し下げると、ユーザ端末３０は帳票閲覧要求を電子交付サーバ１００に送信する。電子交付サーバ１００は、帳票閲覧要求を受信すると、ユーザに対して発行され電子交付サーバ１００に蓄積されている帳票データをユーザ端末３０に送信する。

図１２は、ユーザ端末３０のディスプレイに表示される帳票一覧画面５２０の代表画面図である。帳票一覧画面５２０は、帳票閲覧要求の送信に応じて電子交付サーバ１００から受信した、または受信可能な帳票データの概要を一覧形式で表示する。帳票一覧画面５２０は、ユーザ名表示領域５２２と、帳票の概要を一覧で表示する帳票概要表示領域５２４と、を有する。帳票概要表示領域５２４は、帳票データごとに、発行日と、発行者と、種別と、帳票名と、備考と、を表示する。併せて帳票概要表示領域５２４は、各帳票データの閲覧を可能とするリンク５２６と、各帳票データのダウンロードを可能とするリンク５２８と、を表示する。

図１３は、ユーザ端末３０のディスプレイに表示される帳票詳細画面５３０の代表画面図である。ユーザが帳票一覧画面５２０において帳票データの閲覧を可能とするリンク５２６を押し下げると、該リンク５２６に対応する帳票詳細画面５３０がディスプレイに表示される。帳票詳細画面５３０は、帳票データの内容を表示する。

上述の実施の形態において、保持部の例は、ハードディスクや半導体メモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶する半導体メモリなどにより実現できることは本明細書に触れた当業者には理解される。

本実施の形態に係る電子交付システム２によると、電子交付サーバ１００において、口座情報またはクレジットカード情報を電子交付サイトＩＤに変換することにより、異なる事業者から同じユーザに発行された帳票を当該同じユーザの電子交付サイトＩＤに対応付けることができる。さらに、この変換は口座情報やクレジットカード情報、すなわち口座番号やクレジットカード番号などの所定のフォーマットに従う番号の突合により行われる。したがって、表記揺れが生じうる住所や氏名の突合によりそのような変換を行う場合と比較して、より容易かつ正確なマッチングが可能となる。

また、本実施の形態に係る電子交付システム２ではカナ氏名をチェックデジットとして用いることで、マッチングの確実性をさらに向上できる。

また、本実施の形態に係る電子交付システム２では、帳票の発行に際し、事業者は帳票の発行先のユーザの本人確認を都度行う必要はなく、電子交付サーバ１００が金融機関と連携することによりそのような本人確認が行われる。したがって、事業者が帳票を発行する際の手間を削減できる。

特に、口座振替について、口座振替契約は、銀行と企業、ユーザの三者間で締結され、ユーザから銀行への支払委託と解される。口座振替は企業、ユーザに広く受け入れられており、個人、法人を問わず多くのユーザに利用されている。ユーザを多数保有する事業者は、口座振替契約によりユーザの口座情報を保有しているケースが多い。

本実施の形態に係る電子交付システム２では、ユーザの口座情報を保有している事業者が、ユーザの電子交付サイトＩＤを知らなくても、銀行を経由することで、電子交付などのサービスを提供することができる。具体的には、地域のガス会社や燃料店は、口座情報と請求書の電子データをセットで電子交付サーバ１００にアップロードするだけで、即座に請求書の電子交付が可能となる。これにより、独自に電子交付サイトを設けることが難しい地域企業のペーパーレス化、効率化に資する。また同時に、認証情報を活用した、新たな銀行の収益機会創出にもつながる。

以上、実施の形態に係る電子交付システム２の構成と動作について説明した。この実施の形態は例示であり、各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解される。

実施の形態では、帳票の電子交付を実現するシステムを例として説明したが、これに限られず、本実施の形態に係る技術的思想は、電子データ仲介サービスを提供する電子データ仲介サーバに広く適用可能である。例えば、図１１にも示した電子契約や各種サービスへの申し込みにも、本実施の形態に係る技術的思想を適用できる。

電子契約の場合、契約の一方の当事者が契約書の電子データに他方の当事者の口座情報またはクレジットカード情報を添付して電子データ仲介サーバにアップロードする。電子データ仲介サーバは、添付された口座情報またはクレジットカード情報を他方の当事者のＩＤに変換する。電子データ仲介サーバは、該ＩＤに基づき他方の当事者に契約書の電子データを提供する。他方の当事者は、当該契約書に電子署名を行うことで契約を発効させる。この場合、電子データ仲介サーバは、他方の当事者による電子署名を確認することで、リアルタイムに契約の発効を認識することができる。また、契約では当事者間の本人確認が重要でありかつ手間がかかるものであるところ、この電子データ仲介サービスを利用すると、一方の当事者は自己が他方の当事者の本人確認をしなくても、電子データ仲介サーバにより自動的に本人確認が完了することとなる。また、この本人確認は金融機関が提供する情報に基づく信頼性の高いものである。したがって、契約における本人確認の信憑性を維持しつつその手間を削減することができる。

なお、電子契約が金銭消費貸借契約である場合には、電子データ仲介サーバは、他方の当事者により電子署名がなされたことを確認し、そのタイミングで金融機関サーバに通知し、当該契約に基づく口座間の金銭の移動を発生させてもよい。この場合、金銭移動の即時性を高めることができる。

実施の形態では、事業者が発行する帳票をユーザに提供する場合を説明したが、これに限られず、データを逆向きに届けることも可能である。すなわち、例えば図１１の「サービス申込」にも示される通り、ユーザが事業者提供のサービスに申し込む場面を考える。ユーザは電子交付サイトに自己の電子交付サイトＩＤでログインし、サービス申込書の電子データをアップロードする。電子交付サーバ１００は、ユーザの電子交付サイトＩＤを口座情報またはクレジットカード情報に変換する。電子交付サーバ１００は、変換の結果得られた口座情報またはクレジットカード情報をサービス申込書の電子データに添付して事業者端末に送信する。事業者端末は、受信した口座情報またはクレジットカード情報を顧客番号に変換する。事業者端末は、変換の結果得られた顧客番号と、受信したサービス申込書の電子データと、を対応付けて登録する。これにより、ユーザは個々の事業者に個別にサービス申し込みをしなくても電子交付サイトで一括して各種サービスに申し込むことができるので、ユーザ利便性が向上する。

実施の形態では帳票の例として電気、通信、水道に係る帳票を用いたが、これに限られない。例えば、事業者がガス会社の場合は帳票の例はガス料金請求書であり、事業者が学校・幼稚園の場合は帳票の例は保護者宛通知文書（お便り等）であり、事業者が介護施設の場合は帳票の例は介護計画通知であり、事業者がマンション管理組合の場合は帳票の例は管理会計報告や修繕計画通知である。

１０ 第１事業者端末、 ２２ 第１金融機関サーバ、 ３０ ユーザ端末、 １００ 電子交付サーバ。

Claims (8)

1. 電子データ仲介サービスを提供する電子データ仲介サーバであって、
   金融機関を介した支払いに用いられる所定のフォーマットを有する番号と、当該番号に関連付けられた電子データと、を、電子データを発行する側の発行ユーザから、ネットワークを介して取得する手段と、
   取得された番号に対応する、電子データを受け取る側の受け取りユーザを、前記金融機関を介して特定する手段と、
   取得された番号に関連付けられた電子データを、特定された受け取りユーザにネットワークを介して提供する手段と、を備え、
   前記特定する手段は、
   前記取得された番号に対応する受け取りユーザを特定するように金融機関に問い合わせる手段と、
   前記金融機関によって特定された、前記取得された番号に対応する受け取りユーザを受け取る手段と、を含み、
   前記金融機関は、前記所定のフォーマットを有する番号と、前記受け取りユーザとを対応付けて保持しており、
   前記金融機関を介した支払いは口座振替であり、
   前記所定のフォーマットを有する番号は、数字４桁の金融機関コードと、数字３桁の店番号と、数字１桁の預金種別と、数字７桁の口座番号と、を含む、
   電子データ仲介サーバ。
2. 前記取得する手段は、所定のフォーマットを有する番号に併せてカナ氏名を取得し、
   前記特定する手段は、取得された番号およびカナ氏名に対応する受け取りユーザを、前記金融機関を介して特定する請求項１に記載の電子データ仲介サーバ。
3. 金融機関を介した支払いはクレジットカードによる支払いであり、
   所定のフォーマットを有する番号は、クレジットカード番号を含む請求項１に記載の電子データ仲介サーバ。
4. 前記金融機関に問い合わせた結果として、前記所定のフォーマットを有する番号と、前記電子データ仲介サービスにおいて受け取りユーザを特定する受け取りユーザＩＤと、を対応付けて保持するユーザ情報保持手段をさらに備え、
   前記特定する手段は、取得された番号に対応する受け取りユーザＩＤを前記ユーザ情報保持手段から取得する請求項１から３のいずれか一項に記載の電子データ仲介サーバ。
5. 取得された番号に関連付けられた電子データを、特定された受け取りユーザに対応付けてデータ保持手段に格納する手段をさらに備え、
   前記提供する手段は、受け取りユーザから要求があると、当該受け取りユーザに対応する電子データを前記データ保持手段から読み出して当該受け取りユーザに提供する請求項１から４のいずれか一項に記載の電子データ仲介サーバ。
6. 電子データは、発行ユーザが受け取りユーザに発行する帳票の電子交付に係るデータである請求項１から５のいずれか一項に記載の電子データ仲介サーバ。
7. 受け取りユーザは、法人番号で特定される法人である請求項１から６のいずれか一項に記載の電子データ仲介サーバ。
8. コンピュータを、請求項１から請求項７のいずれか一項に記載の電子データ仲介サーバの各手段として機能させるためのコンピュータプログラム。

Images