【事件の表示】
　特願２００３−１０９９００「口座振替契約方法、システム及びプログラム」拒絶査定不服審判事件〔平成１６年１１月１１日出願公開、特開２００４−３１８３６４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
Ｉ．手続の経緯
　本願は，平成１５年４月１５日の出願であって，平成１６年３月１６日付けで拒絶理由が通知され，これに対し，同年５月２８日付けで意見書が提出されたものの，平成１７年１月２４日付けで拒絶査定がされ，同年２月２２日に拒絶査定に対する審判請求がされたものであり，当審において，平成２０年５月２０日付けで拒絶理由が通知され，これに対し，同年７月２３日付けで意見書及び手続補正書が提出されたものである。
　
II．本願特許請求の範囲等の記載
１．平成２０年７月２３日付け手続補正について
　平成２０年７月２３日付けで提出された手続補正書による手続補正（以下，「本件補正」という。）は，特許請求の範囲を以下のように補正するとともに，対応する発明の詳細な説明における記載を補正するものである。
　
【請求項１】
　利用者端末との間で情報伝送するためのＩＢウェブサイトを構築管理しかつ銀行ホストとの間で情報伝送するＩＢサーバにより口座振替契約手続きを行う口座振替契約方法において，前記ＩＢサーバが，
　前記利用者端末が口座振替契約申込み情報を入力及び送信した収納企業ウェブサイトから前記ＩＢウェブサイトへと接続を移行する際に該口座振替契約申込み情報及び口座振替契約に係る収納企業情報を引き継ぐステップと，
　予め記憶された収納企業情報と前記引き継いだ口座振替契約に係る収納企業情報とを照合することにより収納企業認証処理を行うステップと，
　予め記憶された利用者の口座情報及び認証情報と，前記引き継いだ口座振替契約申込み情報に含まれる口座情報及び第１認証情報，並びに利用者端末からさらに入力されて送信される第２認証情報とを照合することにより利用者認証処理を行うステップと，
　前記口座振替契約申込み情報及び前記口座振替契約に係る収納企業情報から抽出した情報に基づいて本登録用データを作成するステップと，
　前記作成された本登録用データを本登録処理のために前記銀行ホストへ送信しさらに該銀行ホストから該本登録処理の可否の結果データを受信するステップと，
　前記本登録の可否の結果データの受信に応じて契約結果ファイルを作成するステップと，
　前記契約結果ファイルの内容を前記収納企業ウェブサイトを構築管理する収納企業ホストへ送信するステップとを有することを特徴とする
口座振替契約方法。
【請求項２】（略）
【請求項３】（略）
【請求項４】
　利用者端末との間で情報伝送するためのＩＢウェブサイトを構築管理しかつ銀行ホストとの間で情報伝送するＩＢサーバにより口座振替契約手続きを行う口座振替契約システムにおいて，前記ＩＢサーバが，
　前記利用者端末が口座振替契約申込み情報を入力及び送信した収納企業ウェブサイトから前記ＩＢウェブサイトへと接続を移行する際に該口座振替契約申込み情報及び口座振替契約に係る収納企業情報を引き継ぐ手段と，
　予め記憶された収納企業情報と前記引き継いだ口座振替契約に係る収納企業情報とを照合することにより収納企業認証処理を行う手段と，
　予め記憶された利用者の口座情報及び認証情報と，前記引き継いだ口座振替契約申込み情報に含まれる口座情報及び第１認証情報，並びに利用者端末からさらに入力されて送信される第２認証情報とを照合することにより利用者認証処理を行う手段と，
　前記口座振替契約申込み情報及び前記口座振替契約に係る収納企業情報から抽出した情報に基づいて本登録用データを作成する手段と，
　前記作成された本登録用データを本登録処理のために前記銀行ホストへ送信しさらに該銀行ホストから該本登録処理の可否の結果データを受信する手段と，
　前記本登録の可否の結果データの受信に応じて契約結果ファイルを作成する手段と，
　前記契約結果ファイルの内容を前記収納企業ウェブサイトを構築管理する収納企業ホストへ送信する手段とを有することを特徴とする
口座振替契約システム。
【請求項５】（略）
【請求項６】（略）
【請求項７】
　口座振替契約手続きを行うべく，利用者端末との間で情報伝送するためのＩＢウェブサイトを構築管理しかつ銀行ホストとの間で情報伝送するＩＢサーバに対し，
　前記利用者端末が口座振替契約申込み情報を入力及び送信した収納企業ウェブサイトから前記ＩＢウェブサイトへと接続を移行する際に該口座振替契約申込み情報及び口座振替契約に係る収納企業情報を引き継ぐ機能と，
　予め記憶された収納企業情報と前記引き継いだ口座振替契約に係る収納企業情報とを照合することにより収納企業認証処理を行う機能と，
　予め記憶された利用者の口座情報及び認証情報と，前記引き継いだ口座振替契約申込み情報に含まれる口座情報及び第１認証情報，並びに利用者端末からさらに入力されて送信される第２認証情報とを照合することにより利用者認証処理を行う機能と，
　前記口座振替契約申込み情報及び前記口座振替契約に係る収納企業情報から抽出した情報に基づいて本登録用データを作成する機能と，
　前記作成された本登録用データを本登録処理のために前記銀行ホストへ送信しさらに該銀行ホストから該本登録処理の可否の結果データを受信する機能と，
　前記本登録の可否の結果データの受信に応じて契約結果ファイルを作成する機能と，
　前記契約結果ファイルの内容を前記収納企業ウェブサイトを構築管理する収納企業ホストへ送信する機能とを実現させることを特徴とする
口座振替契約プログラム。
【請求項８】（略）
【請求項９】（略）
　
２．本件補正前の特許請求の範囲の記載について
　当審における平成２０年５月２０日付け拒絶理由が通知された本件補正前の特許請求の範囲の記載は，出願当初明細書等に記載された，以下のとおりのものである。
　
　　【請求項１】
　利用者端末との間で情報伝送するためのＩＢウェブサイトを構築管理しかつ銀行ホストとの間で情報伝送するＩＢサーバにより口座振替契約手続きを行う口座振替契約方法において，前記ＩＢサーバが，
　前記利用者端末が口座振替契約申込み情報を入力及び送信した収納企業ウェブサイトから前記ＩＢウェブサイトへと接続を移行する際に該口座振替契約申込み情報及び口座振替契約に係る収納企業情報を引き継ぐステップと，
　予め記憶された収納企業情報と前記引き継いだ口座振替契約に係る収納企業情報とを照合することにより収納企業認証処理を行うステップと，
　予め記憶された利用者の口座情報及び認証情報と，前記引き継いだ口座振替申込み情報に含まれる口座情報及び認証情報とを照合することにより利用者認証処理を行うステップと，
　前記口座振替契約申込み情報及び前記口座振替契約に係る収納企業情報から抽出した情報に基づいて本登録用データを作成するステップと，
　前記作成された本登録用データを本登録処理のために前記銀行ホストへ送信しさらに該銀行ホストから該本登録処理の可否の結果データを受信するステップと，
　前記本登録の可否の結果データの受信に応じて契約結果ファイルを作成するステップと，
　前記契約結果ファイルの内容を前記収納企業ウェブサイトを構築管理する収納企業ホストへ送信するステップとを有することを特徴とする
　口座振替契約方法。
【請求項２】〜【請求項９】（略）
　
III．当審において通知した拒絶理由
　当審において平成２０年５月２０日付けで通知した拒絶理由は，理由１，２からなり，その概要はそれぞれ以下のとおりである。
　
１．理由１の概要
「この出願は，特許請求の範囲の記載が下記の点で，特許法第３６条第６項第１号又は第２号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　　記
　
Ａ．請求項１における「予め記憶された利用者の口座情報及び認証情報と，前記引き継いだ口座振替申込み情報に含まれる口座情報及び認証情報とを照合することにより利用者認証処理を行うステップ」について
（１）上記「口座振替申込み情報」と当該請求項に記載された「口座振替契約申込み情報」との関係が，明りょうでない。
（２）上記「認証情報」と明細書【００４４】段落に記載された「口座暗証番号１０２ｇ，ログインＩＤ１０２ｈ，ログインパスワード１０２ｉ等の認証情報」との関係が，明りょうでない。
（３）上記「口座振替申込み情報」が「口座振替契約申込み情報」であり，且つ，上記「認証情報」が，明細書【００４４】段落に記載された「口座暗証番号１０２ｇ，ログインＩＤ１０２ｈ，ログインパスワード１０２ｉ等の認証情報」である場合，【００４４】段落には，「利用者は，図４（Ｂ）の画面上でさらに口座暗証番号１０２ｇ，ログインＩＤ１０２ｈ，ログインパスワード１０２ｉ等の認証情報を入力し，確認ボタン１０８をクリック等することによりウェブサーバ４０へ送信する。」と記載されていることからみて，上記「口座暗証番号１０２ｇ，ログインＩＤ１０２ｈ，ログインパスワード１０２ｉ等の認証情報」は，利用者端末で入力されたものであって，収納企業ウェブサイトから引き継いだ口座振込契約申込み情報に含まれる情報とは認められない。そうしてみると，上記「前記引き継いだ・・・に含まれる口座情報及び認証情報とを照合することにより利用者認証処理を行う」は，発明の詳細な説明に記載したものとは認められない。
　
Ｂ．上記Ａと同様に，請求項４における「予め記憶された利用者の口座情報及び認証情報と，前記引き継いだ口座振替申込み情報に含まれる口座情報及び認証情報とを照合することにより利用者認証処理を行う手段」，請求項７における「予め記憶された利用者の口座情報及び認証情報と，前記引き継いだ口座振替申込み情報に含まれる口座情報及び認証情報とを照合することにより利用者認証処理を行う機能」について，当該記載は明りょうでなく，発明の詳細な説明に記載したものとは認められない。
　
Ｃ．（略）
Ｄ．（略）
Ｅ．（略）
　
　よって，請求項１−９（請求項４，７を引用する請求項も含む）に係る発明は明確でなく，また，請求項１−９（請求項１，４，７を引用する請求項も含む）に係る発明は，発明の詳細な説明に記載したものでない。」
　
２．理由２の概要
「本願の請求項１−９に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　　　　　　　　　　　　　　　　　記
　引用例１．特開２００２−１５７４２６号公報
　引用例２．特開２００２−３６６７６６号公報
　引用例３．特開２００１−１３４６７９号公報　」
　
IV．当審の判断
１．理由１についての判断
（１）理由１のＡについて
　理由１のＡで指摘した点に関して，請求項１のＩＢサーバが実行する「予め記憶された利用者の口座情報及び認証情報と，前記引き継いだ口座振替契約申込み情報に含まれる口座情報及び第１認証情報，並びに利用者端末からさらに入力されて送信される第２認証情報とを照合することにより利用者認証処理を行うステップ」について，以下に検討する。
　
（ａ）請求項１の記載について
　ＩＢサーバが実行する上記「利用者認証処理を行うステップ」で照合する情報について，請求項１に記載された特定事項を検討する。
　本件補正により，補正前の「引き継いだ口座振替申込み情報に含まれる口座情報及び認証情報」における「認証情報」が，「第１認証情報，並びに利用者端末からさらに入力されて送信される第２認証情報」と補正されている。
　この補正事項について，意見書の「(2-3)補正の根拠」における主張を参酌すると，上記「第１認証情報」は，【００３８】段落に記載される「利用者の氏名，住所，収納企業から利用者に対し予め付与された顧客番号等」を特定し，上記「第２認証情報」は，【００４４】段落に記載される「口座暗証番号１０２ｇ，ログインＩＤ１０２ｈ，ログインパスワード１０２ｉ等」を特定するものである。このことから，上記「第１認証情報」は，引き継いだ口座振替契約申込み情報に含まれた情報であり，上記「第２認証情報」は，引き継いだ口座振替契約申込み情報に含まれた情報以外の，利用者端末からさらに入力された情報と認められる。
　そうしてみると，ＩＢサーバが実行する上記「利用者認証処理を行うステップ」において，「予め記憶された利用者の口座情報及び認証情報」と照合する情報は，「引き継いだ口座振替契約申込み情報に含まれる口座情報」及び「引き継いだ口座振替契約申込み情報に含まれる第１認証情報」並びに「利用者端末からさらに入力されて送信される第２認証情報」であると認められる。
　
（ｂ）発明の詳細な説明の記載について
　ＩＢサーバが実行する上記「利用者認証処理を行うステップ」に関する，発明の詳細な説明の記載を検討する。
　まず，発明の詳細な説明の【００４７】段落の記載を参酌すると，ＩＢサーバの利用者認証処理部が行う利用者認証処理（Ｓ６）は，「利用者が当該銀行に有している口座の実在確認」と，「ログイン要求してきた利用者が当該口座の名義人本人であることの認証」とを行う処理であり，具体的には，利用者認証処理部は，ＩＢサーバの備えるＤＢサーバ内に記憶されている顧客データファイルから当該利用者の口座情報及び認証情報を取得し，この顧客データファイルの口座情報及び認証情報の内容と，ステップＳ４で利用者端末から送信されてきた口座情報及び認証情報の内容とを照合して，口座の実在確認及び利用者認証を行うものである。
　ここで，上記「ステップＳ４で利用者端末から送信されてきた口座情報及び認証情報」に関して，【００４１】〜【００４４】段落，【図４】（Ａ），（Ｂ）の記載を参酌すると，【図４】（Ｂ）に図示されるように，ＩＢウェブサイトの画面には，収納企業ウェブサイトから引き継がれた「口座振替契約申込み情報」の中から，「氏名」，「科目」，「口座番号」，「顧客情報」が表示され，引き継がれた情報が表示された画面上で，利用者が「暗証番号」，「ログインＩＤ」，「ログインパスワード」の認証情報をさらに入力し，確認ボタンをクリック等することにより，これらの情報が，利用者端末からＩＢサーバの備えるウェブサーバへ送信され，ウェブサーバは，送信されてきた情報を一時的に記憶するものである。ここで【００３８】段落の記載も参酌すると，ＩＢウェブサイトの画面に表示される上記「科目」及び「口座番号」は「口座情報」に該当し，上記「氏名」及び「顧客情報」は「第１認証情報」に該当するものである。このことから，「引き継いだ口座振替契約申込み情報に含まれる口座情報（「科目」及び「口座番号」）」，「引き継いだ口座振替契約申込み情報に含まれる第１認証情報（「氏名」及び「顧客情報」）」，「利用者端末からさらに入力されて送信される第２認証情報（「暗証番号」，「ログインＩＤ」，「ログインパスワード」）」が，ステップＳ４で利用者端末からＩＢサーバの備えるウェブサーバに送信され，当該ウェブサーバは，上記「口座情報」及び「第１認証情報」並びに「第２認証情報」を一時的に記憶しているものと認められる。
　しかしながら，【００４７】段落を参酌しても，「利用者が当該銀行に有している口座の実在確認」と，「ログイン要求してきた利用者が当該口座の名義人本人であることの認証」とを行うために，「顧客データファイルの口座情報及び認証情報の内容」と，「ステップＳ４で利用者端末から送信されてきた口座情報及び認証情報の内容」とを照合すると記載されているものの，照合する情報について，「口座情報」及び「認証情報」に含まれるいずれの情報を照合するのか具体的に説明する記載はないため，「第１認証情報」並びに「第２認証情報」は，ステップＳ４で利用者端末から送信されてきた認証情報であるものの，「第１認証情報」並びに「第２認証情報」が照合する情報として使用されていることが記載されていると認めることはできない。
　また，【００４７】段落やその他の記載を参酌すると，上記顧客データファイルのマスタファイルは，銀行ホストの顧客マスタに保管されたものであり，口座作成時に取得した利用者（名義人）の口座情報が記憶されていると記載されており，銀行ホストの顧客マスタであることからみて，当該口座情報には口座番号が含まれること，口座番号に対応して口座暗証番号などの認証情報も記憶されているものと認められるものの，口座番号や口座暗証番号以外に，「口座情報」及び「認証情報」として，どのような情報が記憶されているのか具体的に説明されていないため，顧客データファイル側から見ても，「利用者が当該銀行に有している口座の実在確認」と，「ログイン要求してきた利用者が当該口座の名義人本人であることの認証」とを行うために，「第１認証情報」並びに「第２認証情報」が照合する情報として使用されていることが記載されていると認めることはできない。
　このように，発明の詳細な説明には，「利用者が当該銀行に有している口座の実在確認」と，「ログイン要求してきた利用者が当該口座の名義人本人であることの認証」とを行うために，ＩＢサーバのＤＢサーバ内に記憶されている利用者の口座情報及び認証情報と，利用者端末から送信されてきた口座情報及び認証情報とを照合することは記載されているものの，「第１認証情報」並びに「第２認証情報」が，照合する情報として使用されていることが記載されていると認めることはできない。
　よって，ＩＢサーバが実行する上記「利用者認証処理を行うステップ」において，「予め記憶された利用者の口座情報及び認証情報」と照合する情報が，「引き継いだ口座振替契約申込み情報に含まれる口座情報」及び「引き継いだ口座振替契約申込み情報に含まれる第１認証情報」並びに「利用者端末からさらに入力されて送信される第２認証情報」であることは，発明の詳細な説明に記載された事項であるとは認められない。
　
（ｃ）発明の詳細な説明の記載から自明な事項について
　利用者端末から送信されてきた認証情報である「第１認証情報」並びに「第２認証情報」の両情報を照合する情報として使用することが，発明の詳細な説明の記載から自明な事項であるかどうかについて以下に検討する。
　「第１認証情報」は，【００３８】段落に記載されように「利用者の氏名，住所，収納企業から利用者に対し予め付与された顧客番号等」であり，利用者の本人確認（認証）のための情報であると説明されているものの，この認証情報は，【００３９】段落に記載されるように，収納企業ホストが利用者の認証を行うための情報であり，収納企業ホスト内の請求マスタに記憶された情報と照合し，一致していると判断した場合に本人であると認証するものであり，各収納企業ホスト内の「請求マスタ」に記憶された情報が，銀行ホストに記憶されているとは認められないため，「第１認証情報」により，ＩＢサーバにおける「ログイン要求してきた利用者が当該口座の名義人本人であることの認証」を行うことはできない。
　これに対して，「第２認証情報」は，【００４４】段落に記載されるように「口座暗証番号，ログインＩＤ，ログインパスワード等」であり，通常，「口座暗証番号」は，口座名義人本人のみが知る情報として，「口座番号」に対応させて銀行ホストの顧客マスタに保管される情報であるから，顧客データファイルの「口座情報」及び「認証情報」と，「口座番号」を含む「引き継いだ口座振替契約申込み情報に含まれる口座情報」及び「口座暗証番号」を含む「第２認証情報」とを照合することにより，「口座の実在確認」及び「ログイン要求してきた利用者が当該口座の名義人本人であることの認証」を行う処理が同時に実現可能である。
　そうしてみると，「口座の実在確認」と，「ログイン要求してきた利用者が当該口座の名義人本人であることの認証」とを行う利用者認証処理は，「予め記憶された利用者の口座情報及び認証情報」と，「引き継いだ口座振替契約申込み情報に含まれる口座情報」及び「利用者端末からさらに入力されて送信される第２認証情報」とを照合することで実現可能であり，これに加えて，「引き継いだ口座振替契約申込み情報に含まれる第１認証情報」との照合を行うようにすることは，照合する情報を不必要に冗長化することに他ならず，通常のシステム設計の観点からみても，当業者にとって，発明の詳細な説明の記載から自明な事項であるとは認められない。
　
（ｄ）まとめ
　以上，発明の詳細な説明の記載を総合的に判断すると，ＩＢサーバが実行する上記利用者認証処理を行うステップは，「予め記憶された利用者の口座情報及び認証情報」と，「引き継いだ口座振替契約申込み情報に含まれる口座情報」及び「利用者端末からさらに入力されて送信される第２認証情報」とを照合するものであり，「第２認証情報」に加えて「引き継いだ口座振替契約申込み情報に含まれる第１認証情報」も照合する情報とすることは，発明の詳細な説明に記載されたものとは認められず，また，発明の詳細な説明の記載から自明な事項とも認められない。
　したがって，請求項１の「予め記憶された利用者の口座情報及び認証情報と，前記引き継いだ口座振替契約申込み情報に含まれる口座情報及び第１認証情報，並びに利用者端末からさらに入力されて送信される第２認証情報とを照合することにより利用者認証処理を行うステップ」は，発明の詳細な説明に記載されたものではない。
　
（２）理由１のＢについて
　上記Ａと同様に，請求項４における「予め記憶された利用者の口座情報及び認証情報と，前記引き継いだ口座振替契約申込み情報に含まれる口座情報及び第１認証情報，並びに利用者端末からさらに入力されて送信される第２認証情報とを照合することにより利用者認証処理を行う手段」，請求項７における「予め記憶された利用者の口座情報及び認証情報と，前記引き継いだ口座振替契約申込み情報に含まれる口座情報及び第１認証情報，並びに利用者端末からさらに入力されて送信される第２認証情報とを照合することにより利用者認証処理を行う機能」は，発明の詳細な説明に記載されたものではない。
　
（３）まとめ
　よって，請求項１−９（請求項１，４，７を引用する請求項も含む）に係る発明は，発明の詳細な説明に記載したものでないから，この出願の特許請求の範囲の記載は，特許法第３６条第６項第１号に規定する要件を満たしていない。
　
２．理由２について
（１）本願発明
　本願の請求項１に係る発明は，本件補正により補正された，特許請求の範囲の請求項１に記載された，上記のとおりのものである。
　
（２）引用例
（引用例１）特開２００２−１５７４２６号公報（平成１４年５月３１日出願公開）には，図面と共に，以下の事項が記載されている。
（Ａ）【００１４】〜【００１９】段落
「【００１４】
【発明の実施の形態】本発明の実施形態として，ネットワーク完結型の口座振替スキームを例に説明する。図１は，このスキームを実現する口座振替システムの全体構成図であり，銀行，多数の顧客，少なくとも一つのサービス提供者の間で相互に情報伝達可能なネットワーク環境が整備されていることを前提としている。以下の説明では，現在，最もポピュラーなネットワークであるインターネットを用いたシステムを例示している。しかしながら，本発明は，これに限定されるものではなく，各種の有線・無線ネットワークを用いて，同様のスキームを実現するシステムに広く適用可能である。
【００１５】銀行は，インターネット上の所定のＷｅｂサイト（銀行サイト）において，インターネットバンキング（ＩＢ）を開設している。顧客は，このインターネットバンキングを利用して，オンラインで入出金や振込等を行うことができる他，後述する口座振替に関する手続を行うこともできる。一方，サービス提供者は，(1)サービス加入者である顧客に対して所定のサービスを提供し，(2)所定のＷｅｂサイト（サービス提供者サイト）においてホームページを開設し，かつ，(3)口座振替の委任を受けている者である。これらの条件(1)〜(3)を満足し得る業種としては，例えば，五大公共，税金，学費（各種私立学校，保育園・幼稚園），保険，カード・信販，会費，返済金等が挙げられ，このような業種を営む者が，本明細書でいう「サービス提供者」となり得る。顧客は，サービス提供者サイトからサービス契約の申込みを行うことができる（オンライン・サインアップ）。本実施形態の特徴の一つは，サービス提供者とのサービス契約と，それに伴う口座振替に関する銀行手続との同時処理を実現する点にある。
【００１６】銀行システム１は，サーバ２，記憶装置３，通信装置４等を主体に構成されており，顧客端末１０との間およびサービス提供者システム２０との間で，ネットワークを介した情報伝達が可能である。サーバ２は，図１に示したように単一のサーバであっても，Ｗｅｂサーバや管理サーバ等を含む複数のサーバがＬＡＮによって結ばれた形態であってもよい。同様に，記憶装置３も単一または複数のいずれであってもよい。記憶装置３には，インターネットバンキングを運営するのに必要な各種データベースが格納されているが，本実施形態との関係では，申込受付データベース５，テレホンバンキング契約データベース６が重要となる。申込受付データベース５は，個々の顧客から受けた口座振替の申込みを一元的に管理するためのデータベースであり，受付案件毎に個別の受付番号が付されたレコード群で構成されている。個々のレコードには，口座振替の申込みに際して，顧客が入力した顧客情報（振替口座を特定するための情報を含む）が記述されている。また，テレホンバンキング契約データベース６は，テレホンバンキング（ＴＢ）契約者の情報を一元的に管理するためのデータベースであり，例えば，契約者毎に個別の番号が付されたレコード群で構成されている。個々のレコードには，契約者情報（テレホンバンキングの契約番号，パスワード，確認番号等を含む）が記述されている。
【００１７】顧客端末１０は，銀行システム１との間およびサービス提供者システム２０との間で，ネットワークを介した情報伝達が可能であり，送受信されたデータは，ブラウザによって閲覧可能な状態で表示される。一例として，顧客端末１０は，コンピュータ１１，キーボードやマウス等の入力装置１２，ＣＲＴやＬＣＤ等の表示装置１３，通信装置１４等を主体に構成されている。ただし，顧客端末１０は，インターネットに接続可能で，情報を入力・確認し得るものであればどのような形態でもよく，例えば，デジタルＴＶの送受信装置や通信機能を有する家庭用ゲーム機等であってもよい。顧客は，自己の顧客端末１０を操作して，銀行やサービス提供者が運営するＷｅｂサイトにアクセスし，サービス契約の申込み，口座振替の依頼等を行う。
【００１８】サービス提供者システム２０は，サーバ２１，記憶装置２２，通信装置２３等を主体に構成されており，銀行システム１との間および顧客端末１０との間で，ネットワークを介した情報伝達が可能である。サーバ２１および記憶装置２２は，単一または複数のいずれの形態であってもよい。また，サービス提供者と集金代行者が別主体である場合，それぞれのシステムはネットワークを介して情報伝達可能であることが多いので，それらをまとめてサービス提供者システム２０と捉えることができる。記憶装置２２中には，サービス提供者が業務を遂行する上で，あるいは，サイト運営に必要な各種データベースが格納されているが，本実施形態との関係では，申込受付データベース２４が重要となる。申込受付データベース２４は，個々の顧客から受けたサービス契約の申込みを一元的に管理するためのデータベースであり，受付案件毎に仮採番された固有番号付のレコード群で構成されている。個々のレコードには，サービス契約の申込者の顧客情報（振替口座を特定するための情報を含む）が記述されている。
【００１９】顧客が口座振替の手続を行うケースとして，下記の２つのルートがある。
［ルートＡ］  サービス提供者に新規契約の申込みを行うに際し，顧客がサービス提供者を介して口座振替を申込むルートである。この場合，顧客がサービス提供者との契約申込みを行った直後に，データ引継ぎを伴う画面遷移を行うことによって，銀行に対して口座振替の手続を行う。
［ルートＢ］  サービス提供者との間に既に契約があり口座振替の変更を行う場合，顧客が銀行に対して口座振替を直接申込むルートである。この場合，口座振替の申込みを受けた銀行は，サービス提供者に対して，口座振替の変更があった旨を通知する。」
　
（Ｂ）【００２０】〜【００３６】段落
「【００２０】（第１の実施形態）図２は，本実施形態に係る口座振替手順の説明図である。以下，Ａルートにおいて顧客が行う手続の流れに従い，ネットワーク上の情報伝達とシステムの内部処理とについて詳述する。なお，ステップ１〜５およびステップ１５はサービス提供者システム２０と関連した手順，ステップ６〜１４は，銀行システム１と関連した手順であり，一連の手順（ステップ１〜１５）はリアルタイム処理で実行される。
【００２１】（ステップ１）サービス提供者サイトへのアクセス
まず，顧客は，入力装置１２を操作して，ブラウザよりサービス提供者（収納業者）側のサーバ２１（Ｗｅｂサーバ）を指定するアドレス（ＵＲＬ）を入力・送信する。これを受けて，サービス提供者側のサーバ２１は，ＨＴＭＬで記述された初期画面データを顧客端末１０側に送信する。顧客端末１０がこの画面データを受信すると，新規契約の申込みに関する入力フォームへのリンクが張られた初期画面（ポータル画面）が表示装置１３に表示される。
【００２２】（ステップ２）新規契約の申込み入力
顧客は，入力フォーム画面に移行した後に，このフォームにおいて要求される顧客情報を順次入力していく。ここで入力すべき顧客情報には，申込者の氏名，住所，電話番号等の他に，口座振替手続を銀行に対して行う際に必要となる「振替口座特定情報」（銀行の支店番号，科目，口座番号，口座名義人といった振替口座を特定するための情報）も含まれる。なお，本実施形態では，銀行が口座振替における本人認証と出金を行う事前承認とを得ることが可能なテレホンバンキング契約者を口座振替申込みの主体的要件としているが，本人認証と出金を行う事前承認とを得ることが可能なものであれば他の方法でもよく，例えば，本人認証のためのキャッシュカードやＩＣカード等を用いてもよい。顧客は要求された全情報を入力した後，所定の操作を行うことにより，これらの情報セットを含むデータがサービス提供者システム２０側に送信される。
【００２３】顧客端末１０からデータを受信したサービス提供者システム２０は，契約申込者の顧客情報に基づいて，新規契約の申込みに関する受付処理を行う。ただし，契約が未だ成立していない状態なので，サーバ２１は，固有番号を仮採番した上で，顧客情報が記述された新規レコードを申込受付データベース２４に追加する。そして，受付内容の確認を顧客に促すために，確認画面データを顧客端末１０側に送信する。
【００２４】（ステップ３）新規契約に関する申込み内容の確認
顧客端末１０がサービス提供者システム２０側からデータを受信すると，申込まれた内容（顧客情報や支払方法）と固有番号とが表示装置１３に表示される。それとともに，この確認画面において，銀行の口座振替を行うか否かの確認（換言すれば，テレホンバンキング契約者か）と，銀行へのデータ引継ぎを行ってよいか否かの確認とを顧客に促す。顧客は，表示された内容を確認し，それに同意する場合には，「同意する」ボタンをクリックする。このアクションによって，顧客端末１０からサービス提供者システム２０側に顧客が同意した旨通知される。
【００２５】（ステップ４）引継画面によるデータ引継ぎの確認
通知を受けたサービス提供者システム２０は，顧客の誤認防止および顧客情報の保護の観点より，引継画面データを顧客端末１０側に送信する。このデータを受信した顧客端末１０は，銀行サイトへリンクする旨の引継画面を別ウインドウで表示する（ステップ３で表示された確認画面が非アクティブになる）。そして，新規契約の申込みに際して入力された顧客情報の一部が銀行に引継がれることを顧客に明示する。引継画面上に表示された「確認」ボタンのクリックアクションが行われた場合，銀行システム１へのデータ引継ぎが開始される（ステップ５）。
【００２６】銀行システム１に引継がれるデータ内容は，銀行とサービス提供者との取決めによって規定されているが，最低限，上述した振替口座特定情報を含んでいる必要がある。この情報が銀行側に通知されないと，銀行が振替を行うための口座を特定できないからである（オンラインでの口座振替の申込み受付ができなくなる）。図３は，引継データ内容の一例を示す図である。銀行側に引継ぐデータとしては，管理情報１〜５と顧客情報６〜１１とに大別される。管理情報のうち，「２．ルート区分」は，サービス提供者を介した口座振替（ルートＡ），銀行に直接申込まれた口座振替（ルートＢ）のいずれかであるかを区別する情報である。「３．保険／非保険区分」は，保険とそれ以外とを区別するため必要な情報である。両者を区別する理由については，後述する第２の実施形態において述べる。「４．サービス提供者コード」は，サービス提供者を特定するためのコードである。一方，顧客情報としては，契約者氏名，住所，電話番号の他に，振替口座特定情報である支店番号，（普通口座の）口座番号，名義人がある。なお，本実施形態では，振替可能な口座が普通口座に限定されているという理由で，引継データ中に「科目」（普通，当座等）という項目を設けていない。
【００２７】銀行システム１に引継がれるデータ（顧客情報）は，顧客端末１０を経由して転送される。換言すれば，顧客端末１０は，サービス提供者システム２０とのデータ送受信プロセスにおいて内部に記憶された引継データを読出し，それを銀行システム１に転送する。このような転送形態を採用すると，他のシステムとの整合性を意識せずに銀行システム１と顧客端末１０との間における独自のセキュリティも可能となる。例えば，銀行システム１と顧客端末１０との間に，セキュリティプロトコルの一態様であるＳＳＬ（Secure Sockets Layer）128biを確保することができる。これにより，引継データを銀行システム１に転送する際における情報の盗聴，改ざん，なりすましといった第三者からの攻撃に対抗でき，顧客情報の保護を図ることができる。ここで，ＳＳＬは，ＴＣＰと上位アプリケーションとの中間に位置するプロトコルであり，公開鍵暗号方式を利用して通信相手を認証する機能や，共通鍵暗号方式を利用してデータを暗号化する機能を有する。
【００２８】なお，サービス提供者側のサーバ２１がＳＳＬを具備している場合は，サービス提供者側のサーバ２１から銀行システム１側に直接データを送信してデータを引継ぐことも可能である。
【００２９】（ステップ６）Ｗｅｂ自動支払の説明および口座振替の申込み入力
引継データを受信した銀行システム１は，外部より指示されたサービス提供者に対応する受付画面データを顧客端末１０側に送信する。顧客端末１０がこのデータを受信すると，例えば，図４に示すような口座振替説明画面（サービス提供者毎にカスタマイズされた画面）において，データを引継いだサービス提供者を表示するとともに，Ｗｅｂ自動支払の説明文が表示される。そして，顧客が所定のアクションを行うと，口座振替の規定画面が表示される（ステップ７）。表示された規定内容に同意する場合，顧客は「同意する」ボタンをクリックする。このアクションにより，顧客端末１０から銀行システム１０側に顧客が同意した旨通知される。これにより，図５に示すような口座振替の入力フォームが表示される。この入力フォームには引継データが反映されており，いくつかの入力項目には既に情報が確定データとして記述されている。顧客は，ブランクの入力項目，すなわち，顧客自身で補記すべき項目に情報を入力していく。そして，顧客による「ＯＫ」ボタンのクリックにより，これらの情報セットを含むデータが銀行システム１側に送信される。
【００３０】（ステップ８）入力内容の確認
データを受信した銀行システム１は，入力内容確認データを顧客端末１０側に送信する。これによって，図６に示すような口座振替に関する入力内容確認画面が表示装置１３に表示される。顧客は，この画面に表示された顧客情報を改めて確認するとともに，下欄において要求されている本人認証のための情報（テレホンバンキングの契約番号，パスワードおよび確認番号）を入力した上で，「ＯＫ」ボタンをクリックする。これにより，入力された本人認証情報を含むデータが銀行システム１側に送信される。なお，上述した本人認証のための情報は，認証として用いるために再度入力を要求しているが，データ引継ぎにより入力済項目としてもよい。
【００３１】顧客端末１０からデータを受信した銀行システム１は，口座振替の申込みに関する受付処理を行う（ステップ９）。すなわち，サーバ２は，引継データに含まれる固有番号とともに，本人認証情報を含む顧客情報が記述された新規レコードを申込受付データベース５に追加する。そして，サーバ２は，ステップ８において顧客が入力した本人認証情報と，既取引の顧客データとに基づいて，本人認証を行う（ステップ１０）。なお，このステップ１０では，本人認証の他に，出金口座の届出確認（口座確認）もそのステップにおいて行われる（これらを総称して「０次審査」と呼ぶ）。既取引の顧客データとしてテレホンバンキング契約データベース６を利用する場合，まず，テレホンバンキング契約データベース６を検索して，その顧客に関するレコードを抽出する。つぎに，抽出されたレコードに記述されたテレホンバンキングの契約番号，パスワード，確認番号と，ステップ８において顧客が入力した本人認証情報とを比較する。その結果，本人認証が得られなかった場合（両情報が一致しない場合），ステップ１１の否定判定を経てステップ１２に進み，本人認証ができなかった旨の画面を表示装置１３に表示させる。これに対して，本人認証が得られた場合（両情報が一致する場合），ステップ１１の肯定判定を経てステップ１３に進み，銀行側における口座振替の申込受付が終了したことを示す画面を表示させる。
【００３２】（ステップ１４，１５）引継確認および今後の段取りの確認
銀行システム１は，顧客の誤認防止および顧客情報の保護の観点より，サービス提供者サイトへ戻る旨を記述した引継画面を表示装置１３に表示させる。引継画面上に表示された「確認」ボタンのクリックアクションが行われた場合，顧客が引継ぎに同意したものと判断する。この場合，所定の情報とともに口座振替の申込受付が完了した旨を示す引継データを，上述したセキュリティプロトコルを用いて顧客端末１０に送信する。そして，顧客端末１０よりこの引継データを受信したサービス提供者システム２０は，今後の段取りに関する説明文が記述された画面を表示装置１３に表示させる。
【００３３】なお，顧客が銀行に対して口座振替を直接申込む場合（ルートＢ），入力装置１２を操作して，ブラウザより銀行側のサーバ２（Ｗｅｂサーバ）を指定するアドレス（ＵＲＬ）を入力・送信する。これを受けて，銀行側のサーバ２は，初期画面を表示装置１３に表示させる（ステップ５’）。顧客は，この初期画面よりリンクが張られた口座振替説明画面（図４参照）に移行する（ステップ６）。なお，上述したように口座振替説明画面はサービス提供者毎にカスタマイズされているため，顧客はどのサービス提供者に関する口座振替の申込みか指示する必要がある。つまり，サービス提供者の特定は，銀行システム１外のシステムである顧客端末１０の操作より行われる。それ以降の手順は，上述したルートＡとほぼ同様であるが，引継確認および今後の段取の確認（ステップ１４，１５）の際に，口座振替の変更があった旨と顧客情報を含む引継データとがサービス提供者システム２０に送信されることとなる。
【００３４】このように，本実施形態に係るネット完結型口座振替スキームによれば，インターネットを用いて顧客主導で口座振替手続を行う際に，サービス提供者サイトで入力した顧客情報を銀行側に引継いでいる。これにより，オンラインによるサービス契約の申込みと同時に口座振替手続を行うことができるので，その登録までに要する時間を短縮することができる。また，データの引継ぎは，その旨の確認を顧客に促して顧客の同意を得ることを条件に行われるため，現在どのサイトにアクセスしているかに関する顧客の誤認を防止でき，顧客情報保護の要請にも合致している。
【００３５】また，サービス提供者と銀行との間でデータが引継がれ，両者の間で必要な電子データを提供し合っている。そのため，顧客にとっては，サービス提供者側と銀行側とに対して同じデータを重複して入力する必要がなくなるので，それに要する負担が軽減される。一方，銀行およびサービス提供者にとっては，所有する顧客情報を一致させることができるとともに，事務手続の省力化を推進できる。特に，サービス提供者にとっては，従来，銀行での口座振替申込処理完了後に契約事務手続を開始していたが，本スキームでは，契約申込みと口座振替の申込みとの同時伝送が可能になるため，契約処理を著しく迅速化できる。なお，銀行は，テレホンバンキング等の既取引の顧客データを用いて，口座振替申込みの受付時に本人認証を行うため，その登録処理の一層の迅速化を図ることができる。
【００３６】また，銀行との取引でのみ必要となる情報（テレホンバンキングの契約番号，パスワード，または確認番号等）を，サービス提供者側に渡す必要がないので，セキュリティを確保することができる（情報の漏洩防止）。さらに，顧客と銀行との間では，セキュリティプロトコルが確保されているため，データの引継時における第三者からの攻撃に対抗することができ，高度なセキュリティレベルを確保することができる。」
　
（Ｃ）【００４３】〜【００４６】段落
「【００４３】（第３の実施形態）図８は，銀行における口座振替手続の概略的なフローチャートである。ステップ３１の口座振替Ｗｅｂ取込みは，上述したように，オンラインによる口座振替の申込受付時にリアルタイム処理で行われる本人認証である。続くステップ３２の一次審査は，口座振替の申込時に入力された情報の適切性を個別チェックするステージである。そして，ステップ３３の二次審査は，口座が直前に解約されていないかといった口座の実在性をチェックするステージである。そして，以上の審査を経て，ステップ３４において審査結果が通知される。通常，一次審査および二次審査には相応の時間を要するため，口座振替登録が完了するまでには数日を要する。
【００４４】そこで，図９に示すように，銀行は，インターネット上において電子掲示板を開設し，この掲示板を顧客およびサービス提供者が閲覧することにより，個々の案件に関する現在の審査状況を把握可能にする。口座振替に関する進捗状況の確認ツールである電子掲示板を活用することにより，処理状況の即時通知が可能となる。また，収納業者への事前通知や通知確認が不要となる。一方，サービス提供者にとっては，処理状況に応じた迅速な対応（例えば，口座振替の準備開始等）が可能となるため，サービス契約事務の開始を促進できる。また，本掲示板を用いてサービス提供者の収納委託先を選択可能とすることにより，顧客による口座振替申込みとサービス提供者の収納委託先決定との作業フローを切り分けることができるため，後決め先指定が可能となり，選択の自由度が増す。
【００４５】銀行システム１は，電子掲示板用データベース７を有しており，このデータベース７が更新されると，その内容が電子掲示板に随時反映される（ネットワーク上に公開される）。電子掲示板用データベース７は，口座振替処理に関する個々の案件の進捗状況を一元的に管理するためのデータベースであり，案件毎の固有番号（固有番号については上述）が付されたレコード群で構成されている。個々のレコードには，上述した「保険／非保険区分」を始めとして，「Ｗｅｂ受付日時」，「一次結果」，「不備コード」，「登録結果」および収納委託先を後決めの場合に限り入力される「収納業者コード」等が記述されている。
【００４６】図１０は，電子掲示板の表示例を示す図である。サービス提供者毎に別個の画面を表示するようにし，サービス提供者毎に個別に発行したアクセスパスワードの入力によって，自己の案件に関する進捗状況の一覧を参照することができる。なお，サービス提供者毎にアクセスログをとるようにしてもよい。このアクセスログを確認することによって，サービス提供者への通知確認が可能となる。」
　
　これらの記載からみて引用例１には，以下の発明（以下，「引用例１記載の発明」という。）が開示されていると認められる。
「顧客端末との間で情報伝送するためのインターネットバンキング（ＩＢ）を開設している銀行サイトを構築管理する銀行システムのサーバにより口座振替申込み手続を行う口座振替申込み手続方法において，前記銀行システムのサーバが，
　前記顧客端末が口座振替の申込みのための顧客情報を入力及び送信したサービス提供者サイトから前記インターネットバンキング（ＩＢ）を開設している銀行サイトへと接続を移行する際に該口座振替の申込みのための顧客情報及びサービス提供者（収納業者）コードを含む管理情報を引き継ぐステップと，
　予め記憶された顧客（契約者）の口座情報及び本人認証情報（契約番号，パスワードおよび確認番号）と，前記引き継いだ口座振替申込みのための顧客情報に含まれる口座情報及び本人認証情報（契約番号，パスワードおよび確認番号）とを照合することにより本人認証処理を行うステップと
を有する口座振替申込み手続方法」
　
（引用例２）特開２００２−３６６７６６号公報（平成１４年１２月２０日出願公開）には，図面と共に，以下の事項が記載されている。
（Ｄ）【００１９】〜【００８０】段落
「【００１９】
【発明の実施の形態】〔第１実施形態〕本発明の第１実施形態に係る資金処理システムは，このサービスである請求連動サービスを受ける利用者と販売者とを顧客データベースに登録しておき，この顧客データベースに登録されている販売者から，登録されている利用者についての決済要求を受け付けた場合には，この決済要求に基づいて利用者の口座から引落処理を行い，この引落処理が正常に行えたかどうかを示す結果通知を販売者に送信することにより，販売者がリアルタイムに決済処理を行えるようにしたものである。より詳しくを以下に説明する。
【００２０】まず，図１に基づいて，本実施形態に係る資金処理システムの構成を説明する。この図１は，販売者と利用者と金融機関とを，ネットワークを介して相互に接続した資金処理システムの構成を示す図である。
【００２１】本実施形態においては，例えば，販売者は，損害保険を販売する損害保険会社であり，利用者は，その損害保険会社の販売代理店である。利用者である販売代理店は，最終的な消費者に損害保険を販売し，これを販売者である損害保険会社に通知する。このような処理は，日常業務として頻繁に行われるものである。
【００２２】この資金処理システムの前提として，利用者と，販売者と，金融機関との三者間で，請求連動サービスに関する口座振替契約を締結しておく。すなわち，販売者からの決済要求に対しては，その都度利用者の承諾を得ることなく，その決済要求に示されている金額を利用者の引落口座から引き落として販売者の入金口座に入金してもよいという契約を締結しておく。この契約を締結しておくことにより，金融機関としては，販売者からの決済要求に基づいてリアルタイムに決済処理をすることが可能になる。
【００２３】図１に示すように，販売者は，販売者サーバコンピュータ１０を備えており，この販売者サーバコンピュータ１０は，インターネット等の公衆ネットワークであるネットワーク２０に接続している。すなわち，ネットワーク２０には，不特定多数の者がアクセスできる。この販売者に対する利用者は，１又は複数存在しており，各利用者は，利用者端末３０を備えている。利用者端末３０も，ネットワーク２０に接続している。このため，利用者は，利用者端末３０を操作することにより，ネットワーク２０を介して，販売者サーバコンピュータ１０にアクセスすることが可能である。
【００２４】金融機関は，決済サーバコンピュータ４０と勘定系ホストコンピュータ４２とを備えている。決済サーバコンピュータ４０は，ネットワーク２０に接続しているが，勘定系ホストコンピュータ４２はネットワーク２０に接続していない。これは，勘定系ホストコンピュータ４２は，実際の資金管理をするコンピュータであり，そのセキュリティーを確保する必要があるためである。また，勘定系ホストコンピュータ４２に対して，ネットワーク２０へ接続する機能を付加するのは，システム改造に多大なコストを要するため，汎用的なネットワークインターフェースを有する決済サーバコンピュータ４０を用いてネットワーク２０に接続して，この決済サーバコンピュータ４０を勘定系ホストコンピュータ４２に接続した方が，システム改造コストの低減が図れるためである。したがって，本実施形態においては，決済サーバコンピュータ４０と勘定系ホストコンピュータ４２とは，金融機関内の専用回線２２で接続されている。
【００２５】本実施形態においては，決済サーバコンピュータ４０と勘定系ホストコンピュータ４２は，異なる金融機関に設けられている。すなわち，決済サーバコンピュータ４０は，クレジットカード会社に設けられており，勘定系ホストコンピュータ４２は，銀行に設けられている。但し，これら決済サーバコンピュータ４０と勘定系ホストコンピュータ４２とは，１つの金融機関，例えば銀行内に，設けられてもよい。
【００２６】決済サーバコンピュータ４０は，顧客データベース４４を備えている。この顧客データベース４４は，この請求連動サービスに関する口座振替契約を締結した販売者と利用者に関する情報を保持している。この顧客データベース４４は，例えば，これらの情報をハードディスクに格納することにより，構成されている。
【００２７】次に，この図１に基づいて，本実施形態に係る資金処理システムの全体的処理の概要を説明する。例えば，利用者が損害保険会社の販売代理店である場合，販売代理店は，利用者端末３０から販売者サーバコンピュータ１０にアクセスして，最終的な消費者が加入した保険の内容を示す保険契約情報と，その保険内容に対して損害保険会社が受け取るべき保険料金に相当する決済指示を入力する。これら保険契約情報と決済指示とは，ネットワーク２０を介して，損害保険会社の販売者サーバコンピュータ１０で受信される。
【００２８】この決済指示を受け取った損害保険会社の販売者サーバコンピュータ１０は，決済指示に示されている金額についての決済要求を生成し，ネットワーク２０を介して，金融機関の決済サーバコンピュータ４０に送信する。決済サーバコンピュータ４０では，受信した決済要求が顧客データベース４４に登録されている利用者と販売者のものであるかどうかを確認する。この決済要求が，登録されている利用者と販売者のものである場合には，その決済要求を勘定系ホストコンピュータ４２に送信する。
【００２９】勘定系ホストコンピュータ４２では，この決済要求に基づいて，引落口座からこの決済要求が示す金額を引き落とし，入金口座に入金する処理を行う。そして，引落処理が正常に行えたかどうかを示す結果通知を，決済サーバコンピュータ４０に送信する。決済サーバコンピュータ４０は，この結果通知を，ネットワーク２０を介して，損害保険会社の販売者サーバコンピュータ１０に送信する。これら一連の処理は，販売者サーバコンピュータ１０，決済サーバコンピュータ４０，及び，勘定系ホストコンピュータ４２において，リアルタイムで実行される。ここでリアルタイムとは，バッチ処理ではないという意味であり，決済要求や結果通知等のデータを受信してから，その処理が実行されるまでの間に，ある程度の時間間隔が存在してもよいことを意味している。特に本実施形態においては，決済要求や結果通知等のデータを受信した場合には，これを各コンピュータが許容できる範囲で即時に処理することとしている。これにより，販売者である損害保険会社は，決済結果をリアルタイムで入手できるようになる。
【００３０】次に，本実施形態に係る資金処理システムの処理内容を詳細に説明する。まず，図２に基づいて，販売者サーバコンピュータ１０で行われる販売者サーバ決済要求送信処理について説明する。
【００３１】図２に示すように，販売者サーバコンピュータ１０は，利用者端末３０からのログイン要求があった場合には，その利用者に利用者の認証を求め，利用者が入力した認証と，販売者サーバコンピュータ１０に予め登録されている認証とが一致するかどうかを判断する（ステップＳ１０）。本実施形態においては，この認証に，利用者ＩＤとパスワードとを用いる。つまり，入力された利用者ＩＤとパスワードとが，販売者サーバコンピュータ１０に予め登録されている利用者ＩＤとパスワードと，一致するかどうかを判断する。
【００３２】両者が一致しなかった場合（ステップＳ１０：Ｎｏ）には，ログインを認めず，このステップＳ１０の処理を繰り返す。一方，両者が一致した場合（ステップＳ１０：Ｙｅｓ）には，ログインを認めた上で，商品の購入画面や，その購入した商品についての資金の決済の約定などを，利用者端末３０に表示する（ステップＳ１１）。販売者が損害保険会社である場合には，例えば，保険契約情報やその保険料金を表示し，利用者に必要な項目を選択させたり，入力させたりする。
【００３３】次に，販売者サーバコンピュータ１０は，利用者が商品を購入した場合には，利用者端末３０に決済画面を表示して，利用者に決済指示を入力させ，これを受信する（ステップＳ１２）。本実施形態においては，利用者は，利用者端末３０から決済金額を入力し，これを販売者サーバコンピュータ１０が受信する。但し，この際，利用者が引落口座を特定する情報も合わせて入力し，これを販売者サーバコンピュータ１０が受信するようにしてもよい。
【００３４】次に，販売者サーバコンピュータ１０は，受信した決済指示に基づいて，決済要求を生成する（ステップＳ１３）。図３は，本実施形態に係る決済要求のデータフォーマットを示す図である。この図３に示すように，決済要求は，データ項目として，トランザクションＩＤ  Ｔ１０と，販売者コードＴ１１と，店番Ｔ１２と，科目Ｔ１３と，口座番号Ｔ１４と，店番Ｔ１５と，科目Ｔ１６と，口座番号Ｔ１７と，金額Ｔ１８とを備えている。
【００３５】トランザクションＩＤ  Ｔ１０は，決済要求を生成する毎に割り当てられるユニークな識別情報である。販売者コードＴ１１は，金融機関が各販売者毎に割り付けるユニークな識別情報である。店番Ｔ１２と科目Ｔ１３と口座番号Ｔ１４とにより，入金口座が特定される。つまり，引き落とされた資金が入金される販売者の口座が特定される。但し，この入金口座を特定するための情報は，顧客データベース４４に各販売者毎に登録されているので，省略することも可能である。店番Ｔ１５と科目Ｔ１６と口座番号Ｔ１７とにより，引落口座が特定される。つまり，入金処理をするための資金が引き落とされる利用者の口座が特定される。金額Ｔ１８により，引落処理及び入金処理を行う金額が特定される。
【００３６】利用者端末３０から受信した決済指示には，代金としての金額に関する情報が含まれているので，この金額に基づいて，決済要求の金額Ｔ１８が生成される。これ以外の項目は，販売者サーバコンピュータ１０に予め登録されているので，販売者サーバコンピュータ１０が生成して付加する。
【００３７】次に，図２に示すように，販売者サーバコンピュータ１０は，この生成した決済要求を，ネットワーク２０を介して，決済サーバコンピュータ４０に送信する（ステップＳ１４）。そして，上述したステップＳ１０の処理に戻る。
【００３８】次に，図４に基づいて，決済サーバコンピュータ４０で行われる決済サーバ決済要求送信処理を説明する。
【００３９】まず，決済サーバコンピュータ４０は，販売者サーバコンピュータ１０から，決済要求を受信したかどうかを判断する（ステップＳ２０）。決済要求を受信していない場合（ステップＳ２０：Ｎｏ）には，このステップＳ２０の処理を繰り返して待機する。
【００４０】一方，決済要求を受信した場合（ステップＳ２０：Ｙｅｓ）には，その決済要求が，顧客データベース４４に登録されている販売者から送信されたものであるかどうかを判断する（ステップＳ２１）。
【００４１】図５は，本実施形態に係る顧客データベース４４の構成を示す図である。この図５に示すように，顧客データベース４４は，項目として，販売者コードＴ２０と，販売者名Ｔ２１と，店番Ｔ２２と，科目Ｔ２３と，口座番号Ｔ２４と，利用者ＩＤ  Ｔ２５と，利用者名Ｔ２６と，店番Ｔ２７と，科目Ｔ２８と，口座番号Ｔ２９とを備えている。
【００４２】販売者コードＴ２０は，各販売者毎に割り当てるユニークな識別情報であり，図３に示した決済要求の販売者コードＴ１１に対応する。販売者名Ｔ２１は，その販売者の名称を示している。店番Ｔ２２と科目Ｔ２３と口座番号Ｔ２４とにより，販売者の入金口座が特定されるが，これらは図３に示した決済要求の店番Ｔ１２と科目Ｔ１３と口座番号Ｔ１４とに，それぞれ，対応している。
【００４３】利用者ＩＤ  Ｔ２５は，利用者毎に且つ引落口座毎に割り当てられたユニークな識別情報である。利用者名Ｔ２６は，利用者の氏名や名称であり，引落口座の名義に対応している。店番Ｔ２７と科目Ｔ２８と口座番号Ｔ２９とにより，引落口座が特定されるが，これらは図３に示した決済要求の店番Ｔ１５と科目Ｔ１６と口座番号Ｔ１７とに，それぞれ，対応している。
【００４４】この顧客データベース４４は，利用者と販売者と金融機関との三者との間で，請求連動サービスに関する口座振替契約が締結された時点で，金融機関側で入力するデータである。図５からも分かるように，本実施形態においては，引落口座毎に１つのレコードが形成される。このため，１人の利用者に対して，つまり，同じ利用者ＩＤに対して，複数のレコードが形成される場合もある。
【００４５】上述した図４のステップＳ２１においては，受信した決済要求に含まれている販売者コードＴ１１が，顧客データベース４４の販売者コードＴ２０に登録されているかどうかを判断する。販売者コードＴ１１が顧客データベース４４に登録されている場合（ステップＳ２１：Ｙｅｓ）には，決済サーバコンピュータ４０は，受信した決済要求に含まれている引落口座が，その販売者に対する利用者の引落口座として，顧客データベース４４に登録されているかどうかを判断する（ステップＳ２２）。具体的には，図３に示す決済要求の店番Ｔ１５と科目Ｔ１６と口座番号Ｔ１７とにより特定される引落口座が，図５に示す顧客データベース４４において，その販売者に対応する利用者の店番Ｔ２７と科目Ｔ２８と口座番号Ｔ２９とにより特定される引落口座として，登録されているかどうかを判断する。
【００４６】決済要求に含まれる引落口座が，その販売者に対応する引落口座として登録されている場合（ステップＳ２２：Ｙｅｓ）には，決済サーバコンピュータ４０は，その決済要求を勘定系ホストコンピュータ４２に送信する（ステップＳ２３）。この決済要求のデータフォーマットは，図３に示す構造と同様である。そして，上述したステップＳ２０の処理に戻る。
【００４７】一方，上述したステップＳ２１で，決済要求に含まれている販売者コードＴ１１が，顧客データベース４４に登録されていないと判断した場合（ステップＳ２１：Ｎｏ），又は，上述したステップＳ２２で，決済要求に含まれている引落口座が，その販売者に対応する利用者の引落口座として登録されていないと判断した場合（ステップＳ２２：Ｎｏ）には，この請求連動サービスに未登録である旨の結果通知を，販売者サーバコンピュータ１０に送信する（ステップＳ２４）。そして，上述したステップＳ２０の処理に戻る。
【００４８】次に，図６に基づいて，勘定系ホストコンピュータ４２で行われる勘定系ホスト処理について説明する。
【００４９】まず，勘定系ホストコンピュータ４２は，決済サーバコンピュータ４０から，決済要求を受信したかどうかを判断する（ステップＳ３０）。決済要求を受信していない場合（ステップＳ３０：Ｎｏ）には，このステップＳ３０の処理を繰り返して待機する。
【００５０】決済要求を受信した場合（ステップＳ３０：Ｙｅｓ）には，決済要求に含まれている引落口座から，指定された金額を引き落とすための処理を行い，この引き落としができたかどうかを判断する（ステップＳ３１）。具体的には，図３に示す決済要求の店番Ｔ１５と科目Ｔ１６と口座番号Ｔ１７とで特定される引落口座から，金額Ｔ１８で特定される金額を引き落とす処理を行う。この際，例えば，引落口座の残高が，金額Ｔ１８よりも少ないと，引き落としはできないこととなる。また，引落口座が解約されてしまっているような場合にも，引き落としはできないこととなる。
【００５１】引落口座から金額Ｔ１８の引き落としができた場合（ステップＳ３１：Ｙｅｓ）には，その引き落とした金額Ｔ１８を，入金口座に入金する（ステップＳ３２）。具体的には，図３に示す決済要求の店番Ｔ１２と科目Ｔ１３と口座番号Ｔ１４とで特定される入金口座に，金額Ｔ１８で特定される金額を入金する。本実施形態においては，この入金口座への実際の入金は，金融機関の翌営業日に行われるようになっているが，リアルタイムで行うようにしてもよい。
【００５２】次に，勘定系ホストコンピュータ４２は，決済サーバコンピュータ４０に，正常に引落処理ができた旨の結果通知を送信する（ステップＳ３３）。この結果通知は，リアルタイムに送信する。図７は，本実施形態に係る結果通知のデータフォーマットを示す図である。この図７に示すように，本実施形態に係る結果通知は，トランザクションＩＤ  Ｔ４０と，処理結果Ｔ４１と，エラー情報Ｔ４２とを備えている。トランザクションＩＤ  Ｔ４０は，勘定系ホストコンピュータ４２が受信した決済要求に含まれているトランザクションＩＤ  Ｔ１０に対応する項目であり，受信した決済要求と同じトランザクションＩＤが格納される。処理結果Ｔ４１は，引落処理が正常に行えたかどうかを示す情報である。エラー情報Ｔ４２は，引落処理が正常に行えなかった場合における，そのエラー原因を示す情報である。図６のステップＳ３３では，引落処理が正常に行えたので，処理結果Ｔ４１には，正常に引落処理が行われた旨の情報が格納されている。この結果通知を送信した後，勘定系ホストコンピュータ４２は，上述したステップＳ３０の処理に戻る。
【００５３】一方，上述したステップＳ３１において，引落口座からの引落処理ができなかった場合（ステップＳ３１：Ｎｏ）には，勘定系ホストコンピュータ４２は，決済サーバコンピュータ４０に，引落処理ができなかった旨の結果通知を送信する（ステップＳ３４）。つまり，図７に示す結果通知において，処理結果Ｔ４１には，正常に引落処理ができなかったことを示す情報が格納され，エラー情報Ｔ４２には，そのエラー原因を示す情報が格納された処理結果を，決済サーバコンピュータ４０に送信する。そして，上述したステップＳ３０の処理に戻る。
【００５４】次に，図８に基づいて，本実施形態に係る決済サーバコンピュータ４０で行われる決済サーバ結果通知送信処理について説明する。
【００５５】図８に示すように，決済サーバコンピュータ４０は，まず，勘定系ホストコンピュータ４２から，結果通知を受信したかどうかを判断する（ステップＳ４０）。この結果通知は，上述した図６のステップＳ３３
及びステップＳ３４で，送信されたものである。結果通知を受信していない場合（ステップＳ４０：Ｎｏ）には，このステップＳ４０の処理を繰り返して待機する。
【００５６】一方，結果通知を受信した場合（ステップＳ４０：Ｙｅｓ）には，その結果通知を，販売者サーバコンピュータ１０にネットワーク２０を介して送信する（ステップＳ４１）。そして，上述したステップＳ４０の処理に戻る。
【００５７】次に，図９に基づいて，販売者サーバコンピュータ１０で行われる販売者サーバ結果通知受信処理について説明する。
【００５８】図９に示すように，まず，販売者サーバコンピュータ１０は，決済サーバコンピュータ４０から結果通知を受信したかどうかを判断する（ステップＳ５０）。結果通知を受信していない場合（ステップＳ５０：Ｎｏ）には，このステップＳ５０の処理を繰り返して待機する。一方，結果通知を受信した場合（ステップＳ５０：Ｙｅｓ）には，販売者サーバコンピュータ１０は，この結果通知の内容をその一覧リストに追加して出力するとともに，その結果通知が，引落処理が正常に行われたことを示しているかどうかを判断する（ステップＳ５１）。具体的には，図７に示す結果通知の処理結果Ｔ４１が，引落処理を正常に行ったことを示しているかどうかを判断する。
【００５９】決済処理が正常に行われたことを，通知結果が示している場合（ステップＳ５１：Ｙｅｓ）には，上述したステップＳ５０の処理に戻る。これにより，販売者にとっては，利用者に販売した商品の代金に関する決済処理は完結したことになる。
【００６０】一方，決済処理が正常に行われなかったことを，通知結果が示している場合（ステップＳ５１：Ｎｏ）には，再度，金融機関に振替処理を依頼すべく，図２に示す販売者サーバ決済要求送信処理のステップＳ１３からを再度実行させる。但し，このステップＳ１３からを再度実行させるタイミングは，一定期間経過後である。例えば，１日経過後，３日経過後などである。なぜなら，残高不足で引落口座から必要な資金の引落ができなかった場合には，利用者はまだ引落口座に代金を入金していないのであるから，利用者が引落口座に代金を入金した頃を見計らって再度実行するのが望ましいからである。そして，販売者サーバコンピュータ１０は，上述したステップＳ５０の処理に戻る。
【００６１】なお，ステップＳ５１及びステップＳ５２の処理は，必ずしも必要なものではなく，省略することも可能である。この場合，販売者サーバコンピュータ１０の管理者は，決済サーバコンピュータ４０から受信した結果通知を一覧リストの形式で出力し，人間の手作業で引落処理が正常に行われなかった利用者に対してのみ，再度，決済要求を販売者サーバコンピュータ１０に入力して再度の振替処理を試みるようにしてもよい。
【００６２】以上のように，本実施形態に係る資金処理システムによれば，決済サーバコンピュータ４０は，販売者サーバコンピュータ１０から決済要求を受信した時点で，勘定系ホストコンピュータ４２に決済の処理を要求するようにしたので，販売者にとっては，利用者のアクションに依存しない形で資金を確保することができる。このため，商品販売代金を効率的に精算できるようになる。しかも，販売者は，販売者サーバコンピュータ１０が出力した結果通知により，商品を販売した後すぐに決済結果をリアルタイムで金融機関から取得することができる。このため，販売管理の効率化を図ることができる。
【００６３】また，引落口座の残高不足等の理由により，引落口座から入金口座への資金の振り替えができなかった場合でも，販売者が主導権を持って再度の決済要求を送信できる。このため，未回収代金の効率的な精算を実現することができる。
【００６４】一方，利用者にとっても，ネットデビットのＩＤとパスワードを入力する手間が省けるので，簡単に購入代金の精算をすることができる。
【００６５】さらに，販売者サーバコンピュータ１０と決済サーバコンピュータ４０との間の通信は，既存のネットデビットのインターフェースを利用することができるので，販売者は安全な決済情報の受け渡しを安価に実現することができる。
【００６６】〔第２実施形態〕本発明の第２実施形態は，上述した第１実施形態に係る資金処理システムにおいて，顧客データベース４４の構造を変形したものである。
【００６７】図１０は，本実施形態に係る販売者テーブルＴＢＬ１０の構成を示す図であり，図１１は，利用者テーブルＴＢＬ２０の構成を示す図である。すなわち，本実施形態においては，顧客データベース４４を，各販売者毎に１つのレコードを形成した販売者テーブルＴＢＬ１０と，各利用者毎に１つのレコードを形成した利用者テーブルＴＢＬ２０とに分けて構成している。販売者テーブルＴＢＬ１０と利用者テーブルＴＢＬ２０との関連づけは，販売者コードＴ２０を用いて行う。
【００６８】本実施形態における資金処理システムでは，上述した図４の決済サーバ決済要求送信処理のステップＳ２１において，販売者が顧客データベース４４に登録されているかどうかを，販売者テーブルＴＢＬ１０に基づいて判断することになる。また，ステップＳ２２において，利用者の引落口座が，決済要求を送信した販売者に対する引落口座として，顧客データベース４４に登録されているかどうかを，利用者テーブルＴＢＬ２０に基づいて判断することになる。
【００６９】それ以外の点は，本実施形態に係る資金処理システムは，上述した第１実施形態と同様の処理となり，同様の効果を得ることができる。
【００７０】〔第３実施形態〕本発明の第３実施形態は，上述した第１実施形態及び第２実施形態に係る資金処理システムにおいて，販売者サーバコンピュータ１０と決済サーバコンピュータ４０との間も，専用回線で接続するようにしたものである。
【００７１】図１２は，本実施形態に係る資金処理システムの構成を示すブロック図であり，上述した図１に対応している。この図１２に示すように，本実施形態においては，決済サーバコンピュータ４０と勘定系ホストコンピュータ４２との間と同様に，販売者サーバコンピュータ１０と決済サーバコンピュータ４０との間も，特定の者しかアクセスできない専用回線２４で接続されている。本実施形態においては，これら販売者サーバコンピュータ１０と決済サーバコンピュータ４０との間の通信は，既存のクレジット決済等のインターフェースを利用している。これにより，販売者は新たな通信回線に加入することなく，販売者サーバコンピュータ１０と決済サーバコンピュータ４０との間の通信を，不特定多数の者がアクセスできるネットワーク２０を介さずに，行うことができるようになる。その結果，この資金処理システムのセキュリティをより向上させることができる。
【００７２】これ以外の点については，本実施形態に係る資金処理システムは，上述した第１実施形態又は第２実施形態と同様の処理となり，同様の効果を得ることができる。
【００７３】なお，本発明は上記実施形態に限定されず種々に変形可能である。例えば，上述した実施形態においては，販売者が損害保険会社であり，利用者が販売代理店である場合を例に説明したが，販売者及び利用者はこの組み合わせに限るものではない。販売者がフランチャイザーであり，利用者がフランチャイジーであるようなフランチャイズシステムに対して，本発明を適用し，商品代金の精算をすることもできる。さらには，公共料金や税金等の精算や，保険会社，証券会社の預かり金口座への資金入金手段にも適用することができる。
【００７４】また，販売者が扱う商品は，保険商品などの無形の商品でなく，物品等の有形の商品であってもよい。また，利用者と販売者との間の決済は，必ずしも継続的に行われるものでなくてもよい。つまり，ある１の者と他の１の者との間で発生する資金の決済に対して，本発明は適用することができる。
【００７５】さらに，上述した実施形態においては，決済サーバコンピュータ４０は，図３に示す決済要求の引落口座に基づいて，その決済要求が顧客データベース４４に登録されている利用者に関するものであるかどうかを判断したが，利用者ＩＤに基づいて判断するようにしてもよい。この場合，１つの利用者ＩＤに対して１つの引落口座が割り当てられるようにしておく必要があるが，決済要求から引落口座を特定する情報を省くことができる。
【００７６】また，上述した実施形態においては，決済サーバコンピュータ４０と勘定系ホストコンピュータ４２とを別々のコンピュータシステムで構成したが，これらをまとめて１つのコンピュータシステムで構成してもよい。この場合，専用回線２２は不要になる。
【００７７】また，上述の実施形態で説明した各処理については，これら各処理を実行するためのプログラムをフロッピーディスク，ＣＤ−ＲＯＭ（Compact Disc-Read Only Memory），ＲＯＭ，メモリカード等の記録媒体に記録して，記録媒体の形で頒布することが可能である。この場合，このプログラムが記録された記録媒体を販売者サーバコンピュータ１０や決済サーバコンピュータ４０，勘定系ホストコンピュータ４２に読み込ませ，実行させることにより，上述した実施形態を実現することができる。
【００７８】また，販売者サーバコンピュータ１０や決済サーバコンピュータ４０，勘定系ホストコンピュータ４２は，オペレーティングシステムや別のアプリケーションプログラム等の他のプログラムを備える場合がある。この場合，これらコンピュータの備える他のプログラムを活用し，記録媒体にはこれらのコンピュータが備えるプログラムの中から，上述した実施形態と同等の処理を実現するプログラムを呼び出すような命令を記録するようにしてもよい。
【００７９】さらに，このようなプログラムは，記録媒体の形ではなく，ネットワークを通じて搬送波として頒布することも可能である。ネットワーク上を搬送波の形で伝送されたプログラムは，販売者サーバコンピュータ１０や決済サーバコンピュータ４０，勘定系ホストコンピュータ４２に取り込まれて，このプログラムを実行することにより上述した実施形態を実現することができる。
【００８０】また，記録媒体にプログラムを記録する際や，ネットワーク上を搬送波として伝送される際に，プログラムの暗号化や圧縮化がなされている場合がある。この場合には，これら記録媒体や搬送波からプログラムを読み込んだこれらのコンピュータは，そのプログラムの復号化や伸張化を行った上で，実行する必要がある。」
　
（引用例３）特開２００１−１３４６７９号公報（平成１３年５月１８日出願公開）には，図面と共に，以下の事項が記載されている。
（Ｅ）【０００９】〜【００２３】段落
「【０００９】
【発明の実施の形態】以下，本発明に係わる口座振替契約システムの実施の形態を図面を参照して説明する。
【００１０】本実施形態の口座振替契約システムのシステム構成図を図１に示す。
【００１１】本システムは，チャネル１と，銀行ホスト３と，企業ホスト５を備える。銀行ホスト３と企業ホスト５とは例えば公衆回線４を介して接続されている。
【００１２】チャネル１は，銀行が顧客からの口座振替契約の申込を受付けるための通信手段であり，例えば，電話７，店頭端末９，およびインターネットワーク等のネットワーク１３を介して銀行ホスト３と通信可能な通信端末１１を含む。
【００１３】銀行ホスト３は，口座振替契約の申込に関する情報を，顧客からの電話７，店頭に設置された店頭端末９，あるいはネットワーク１３を介して通信端末１１，から受付けるコンピュータである。
【００１４】銀行ホスト３は，顧客からの口座振替契約の申込に関する情報に基づいて，口座実在チェック，本人確認チェック，口座振替契約の対象企業のチェック等を行ない，口座振替契約意志確認情報データとして記憶するとともに，口座振替契約受付けデータを作成し，対象企業のホスト５に伝送する。企業ホスト５は，口座振替契約受付けデータに基づいて顧客の実在を確認し，契約可否を判定する。企業は契約可と判断したデータを口座振替契約依頼データとして銀行ホスト３に伝送する。銀行ホスト３は企業ホスト５から伝送された口座振替契約依頼データと，記憶されている口座振替契約意志確認情報データとを照合し，合致したデータを対象に口座振替契約処理を行う。
【００１５】以下，図２乃至図１１を参照して，口座振替契約の処理について詳述する。
【００１６】図２および図３は，顧客が銀行に口座振替契約を電話で申し込む場合の処理を示すフローチャートである。
【００１７】図２において，顧客は電話により口座振替契約を銀行に申し込む。この際，顧客は銀行取引き情報を電話で銀行に伝える（Ｓ１）。この銀行取引き情報は，口座振替契約を行う，店番，科目，口座番号を含む。銀行ホスト３は口座振替契約を行う「店番」「科目」「口座番号」を図４に示す顧客マスタ２１と突合し，口座の実在チェックを行う（Ｓ３）。顧客マスタは，図４に示すように「店番」「科目」「口座番号」「キャッシュカード暗証番号」「口座振替契約可能フラッグ」等の情報から構成される。口座が実在しない場合には，その旨のエラーメッセージを顧客に電話で伝える。口座が実在する場合には，顧客はキャッシュカードの暗証番号を電話で銀行に伝える（Ｓ５）。銀行ホスト３は，顧客から入力されたキャッシュカードの暗証番号を図４に示す顧客マスタ２１と照合し，本人確認を行う（Ｓ７）。暗証番号チェックの結果不一致であれば，その旨のエラーメッセージを顧客に電話で伝える。暗証番号チェックの結果一致が取れれば，次に，銀行は顧客から口座振替企業に関する情報を入力する（Ｓ９）。銀行ホスト３は，入力された口座振替企業を口座振替契約の企業として受付けてよいか否かを図５に示す口座振替企業マスタ２３を参照してチェックする（Ｓ１１）。口座振替企業マスタ２３は，図５に示すように「委託者コード」「委託者名」「受付けチャネル別契約可否フラッグ」「入金口座情報」「手数料徴求情報」等から構成される。
【００１８】次に，銀行ホスト３は，口座振替企業が必要とする情報（例えば契約者Ｎｏ，契約名義人等）を企業に代理して顧客から聞き取る（他のチャネルの場合には，顧客に入力させる）（Ｓ１３）。この際，銀行ホスト３は企業別必要情報マスタ２４を参照して企業毎に必要な情報をチェックする。銀行ホスト３は，聞き取ったもしくは入力させた口座振替企業が必要とする情報を図６に示す口座振替契約意志確認情報データ２５として蓄える（Ｓ１５）。口座振替契約意志確認情報データ２５は，図６に示すように「店番」「科目」「口座番号」「意志確認受付け日付」「契約名義人」等から構成される。次に，銀行ホスト３は，蓄えられた口座振替契約意志確認情報データ２５を，受付時間を条件として（例えば，受付日単位（０時から翌日の０時まで）抽出し，図８および図９に示す口座振替契約受付けデータ２７を作成し，ＥＢ(Electronic Banking)システムに蓄積する（Ｓ１７）。口座振替契約受付けデータ２７は図８および９に示すように，ヘッダ部が「申込受付日」「入金口座情報」等から構成され，データ部が「データ区分」「口座振替契約依頼口座情報」「契約者No」「受付けチャネル情報」「結果コード」等から構成される。なお，口座振替契約依頼データ，口座振替契約結果データについても，口座契約受付けデータと同様のデータ構成である。
【００１９】一方，企業ホスト５は，銀行のＥＢシステムから口座振替契約受付データを取り込み，口座契約受付けファイル２９に蓄積する（Ｓ１９）。企業ホスト５は，図９に示す口座振替契約受付けデータ中の契約名義人（預金者名），契約者Ｎｏを図１１に示す請求マスタ３１と照合し，当該顧客の実在を確認し，契約可否を判定する（Ｓ２１）。請求マスタ３１は図１１に示すように，「契約者Ｎｏ」「契約名義人」「口座振替情報」等から構成される。次に，企業ホスト５は契約可と判断されたデータを，図８および図１０に示す口座振替契約依頼データの形式に変換し，このデータを銀行のＥＢシステムに伝送する（Ｓ２３）。
【００２０】銀行ホスト３は，企業ホスト５から伝送された口座振替契約依頼データ３３と口座振替契約意志確認情報データ２５を照合し，合致したデータを対象に口座振替契約処理を行う（Ｓ２５）。具体的には，口座振替契約依頼データ３３を基に図７に示すような口座振替契約マスタ２７を更新する。銀行ホスト３は図１０に示すような口座振替依頼データ３３の結果コードフィールドに，契約ができたか否かの情報を書き込み，口座振替契約結果データ３５としてＥＢシステムに蓄積する。
【００２１】企業ホスト５はＥＢシステムから口座振替契約結果データ３５を取り込み，結果コードを判定して，図１１に示すような企業ホスト５の請求マスタ３１に口座振替契約情報を追加・更新する。
【００２２】なお，この発明は上記実施の形態に限定されるものではない。例えば，上記実施の形態では，顧客からの電話による口座振替契約の申込を銀行のコールセンタが受付けた場合の処理を示したが，顧客が自己の端末からインターネットを介して，あるいは顧客が銀行の店頭に出向き，店頭端末から口座振替契約をそれぞれ申し込む場合にも同様の処理により口座振替契約を自動的に行うことができる。
【００２３】
【発明の効果】この発明によれば，銀行が直接利用者から口座振替契約に必要な利用者の口座情報や企業が必要とする情報を電話，インターネットもしくは店頭端末を介して収集し，口座振替契約のために必要な情報を電子化し，この電子化されたデータを用いて口座振替契約を自動的に処理する公正としたので，完全なペーパレス化による事務の効率化を図れるとともに，銀行，企業，契約者のコストダウンが図れる。さらに，口座振替契約に必要な日数を短縮することができる。また，受付け時に口座の実在をチェックすることにより，口座情報の正確性が向上し，エラーを削減することができる。また，本人確認は，電話，インターネット，店頭端末等の各受付けチャネルで実施されるので，従来技術において起こり得る銀行取引印の相違によるエラーを撲滅することができる。」
　
（３）対比
　請求項１に係る発明と引用例１記載の発明を対比すると，引用例１記載の発明の「顧客端末」，「インターネットバンキング（ＩＢ）を開設している銀行サイト」，「口座振替申込み手続」，「口座振替の申込みのための顧客情報」，「サービス提供者サイト」，「顧客（契約者）」は，それぞれ請求項１に係る発明の「利用者端末」，「ＩＢウェブサイト」，「口座振替契約手続」，「口座振替契約申込み情報」，「収納企業ウェブサイト」，「利用者」に対応する。
　また，上記摘記事項（Ｂ）に記載されるように，引用例１記載の「サービス提供者（収納業者）コードを含む管理情報」は，サービス提供者に新規契約の申込みを行うに際し、顧客がサービス提供者を介して口座振替を申込む場合に，銀行システムに引き継がれる「サービス提供者を特定するためのコードである」から，「口座振替に係る」ものであるといえ，一方，請求項１に係る発明の「口座振替契約に係る収納企業情報」は，明細書の【００４２】，【００４６】段落の記載を参照すると，「口座振替契約に係る収納企業情報は、例えば、企業名称、サービス名称、若しくはこれらをコード化したもの等である」ことから，引用例１記載の発明の「サービス提供者コードを含む管理情報」は，請求項１に係る発明の「口座振替契約に係る収納企業情報」に対応する。
　さらに，引用例１記載の発明の「銀行システムのサーバ」と請求項１に係る発明の「ＩＢサーバ」は，「ＩＢ用のＷｅｂサーバ」で共通している。
　これらのことから，
　引用例１記載の発明の「顧客端末との間で情報伝送するためのインターネットバンキング（ＩＢ）を開設している銀行サイトを構築管理する銀行システムにより口座振替申込み手続を行う」と，請求項１に係る発明の「利用者端末との間で情報伝送するためのＩＢウェブサイトを構築管理しかつ銀行ホストとの間で情報伝送するＩＢサーバにより口座振替契約手続きを行う」は，「利用者端末との間で情報伝送するためのＩＢウェブサイトを構築管理するＩＢ用のＷｅｂサーバにより口座振替契約手続きを行う」で共通し，
　引用例１記載の発明の「前記顧客端末が口座振替の申込みのための顧客情報を入力及び送信したサービス提供者サイトから前記インターネットバンキング（ＩＢ）を開設している銀行サイトへと接続を移行する際に該口座振替の申込みのための顧客情報及び口座振替に係るサービス提供者（収納業者）コードを含む管理情報を引き継ぐステップ」は，請求項１に係る発明の「前記利用者端末が口座振替契約申込み情報を入力及び送信した収納企業ウェブサイトから前記ＩＢウェブサイトへと接続を移行する際に該口座振替契約申込み情報及び口座振替契約に係る収納企業情報を引き継ぐステップ」に対応し，
　引用例１記載の発明の「予め記憶された顧客（契約者）の口座情報及び本人認証情報（契約番号，パスワードおよび確認番号）と，前記引き継いだ口座振替申込みのための顧客情報に含まれる口座情報及び本人認証情報（契約番号，パスワードおよび確認番号）とを照合することにより本人認証処理を行うステップ」と，請求項１に係る発明の「予め記憶された利用者の口座情報及び認証情報と，前記引き継いだ口座振替契約申込み情報に含まれる口座情報及び第１認証情報，並びに利用者端末からさらに入力されて送信される第２認証情報とを照合することにより利用者認証処理を行うステップ」は，「予め記憶された利用者の口座情報及び認証情報と，前記引き継いだ口座振替申込み情報に含まれる口座情報及び認証情報とを照合することにより利用者認証処理を行うステップ」に対応しているものと認められる。
　そして，引用例１記載の発明の「口座振替申込み手続方法」は，請求項１に係る発明の「口座振替契約方法」と，以下の相違点で相違するものの，「口座振替契約方法」で共通していると認められる。
　してみれば，請求項１に係る発明と引用例１記載の発明は，
　「利用者端末との間で情報伝送するためのＩＢウェブサイトを構築管理するＩＢ用のＷｅｂサーバにより口座振替契約手続きを行う口座振替契約方法において，前記ＩＢ用のＷｅｂサーバが，
　前記利用者端末が口座振替契約申込み情報を入力及び送信した収納企業ウェブサイトから前記ＩＢウェブサイトへと接続を移行する際に該口座振替契約申込み情報及び口座振替契約に係る収納企業情報を引き継ぐステップと，
　予め記憶された利用者の口座情報及び認証情報と，前記引き継いだ口座振替申込み情報に含まれる口座情報及び認証情報とを照合することにより利用者認証処理を行うステップと，
を有する口座振替契約方法」
である点で一致し，以下の点で相違するものと認められる。
　
（相違点１）
　「ＩＢ用のＷｅｂサーバ」が，請求項１に係る発明では，「銀行ホストとの間で情報伝送する」ものであるのに対して，引用例１記載の発明では，「銀行ホストとの間で情報伝送する」ものではない点。
　
（相違点２）
　請求項１に係る発明の「ＩＢ用のＷｅｂサーバ」が「予め記憶された収納企業情報と前記引き継いだ口座振替契約に係る収納企業情報とを照合することにより収納企業認証処理を行うステップ」を有する口座振替契約方法を実行するのに対して，引用例１記載の発明の「ＩＢ用のＷｅｂサーバ」がこのような収納企業認証処理を行うステップを有する口座振替契約方法を実行しない点。
　
（相違点３）
　請求項１に係る発明の「ＩＢ用のＷｅｂサーバ」が「前記口座振替契約申込み情報及び前記口座振替契約に係る収納企業情報から抽出した情報に基づいて本登録用データを作成するステップ」と，「前記作成された本登録用データを本登録処理のために前記銀行ホストへ送信しさらに該銀行ホストから該本登録処理の可否の結果データを受信するステップ」と，「前記本登録の可否の結果データの受信に応じて契約結果ファイルを作成するステップ」と，「前記契約結果ファイルの内容を前記収納企業ウェブサイトを構築管理する収納企業ホストへ送信するステップ」とを有する口座振替契約方法を実行するのに対して，引用例１記載の発明の「ＩＢ用のＷｅｂサーバ」がこのような一連のステップを有する口座振替契約方法を実行しない点。
　
（相違点４）
　請求項１に係る発明の「認証情報」が，「引き継いだ口座振替契約申込み情報に含まれる第１認証情報」，並びに「利用者端末からさらに入力されて送信される第２認証情報」であるのに対して，引用例１記載の発明の「認証情報」が，「本人認証情報（契約番号，パスワードおよび確認番号）」である点。
　
（４）相違点についての当審の判断
　上記相違点について検討すると，
（相違点１についての判断）
　引用例２の摘記事項（Ｄ）の【００２４】段落には，「金融機関は，決済サーバコンピュータ４０と勘定系ホストコンピュータ４２とを備えている。・・・汎用的なネットワークインターフェースを有する決済サーバコンピュータ４０を用いてネットワーク２０に接続して，この決済サーバコンピュータ４０を勘定系ホストコンピュータ４２に接続・・・したがって，本実施形態においては，決済サーバコンピュータ４０と勘定系ホストコンピュータ４２とは，金融機関内の専用回線２２で接続されている。」との記載があり，更に，【００７６】段落には，「また，上述した実施形態においては，決済サーバコンピュータ４０と勘定系ホストコンピュータ４２とを別々のコンピュータシステムで構成したが，これらをまとめて１つのコンピュータシステムで構成してもよい。この場合，専用回線２２は不要になる。」との記載があり，また，上記引用例１の摘記事項（Ａ）の【００１６】段落には，「・・・サーバ２は，図１に示したように単一のサーバであっても，Ｗｅｂサーバや管理サーバ等を含む複数のサーバがＬＡＮによって結ばれた形態であってもよい。・・・」との記載があることから，上記引用例２に記載されるような，汎用的なネットワークインターフェースを有するサーバコンピュータと勘定系ホストコンピュータとを金融機関内の専用回線で接続して，情報伝達するようにした金融機関のコンピュータシステムの構成を，引用例１記載の発明に採用して，引用例１記載の発明の「ＩＢ用のＷｅｂサーバ」を「銀行ホストとの間で情報伝送する」ようにすることは，当業者が容易に成し得たものと認められる。
　したがって，上記相違点１に係る請求項１に係る発明の構成は，引用例１記載の発明及び引用例１，２に記載された事項に基づいて，当業者が容易に想到し得たものと認められる。
　
（相違点２についての判断）
　引用例３の摘記事項（Ｅ）の【００１４】段落には，「銀行ホスト３は，顧客からの口座振替契約の申込に関する情報に基づいて，口座実在チェック，本人確認チェック，口座振替契約の対象企業のチェック等を行ない，口座振替契約意志確認情報データとして記憶するとともに，口座振替契約受付けデータを作成し，対象企業のホスト５に伝送する。」との記載があり，【００１７】段落には，「・・・銀行ホスト３は，入力された口座振替企業を口座振替契約の企業として受付けてよいか否かを図５に示す口座振替企業マスタ２３を参照してチェックする（Ｓ１１）。口座振替企業マスタ２３は，図５に示すように「委託者コード」「委託者名」「受付けチャネル別契約可否フラッグ」「入金口座情報」「手数料徴求情報」等から構成される。」との記載があり，このような口座振替契約の対象企業のチェックする処理を引用例１記載の発明に採用して，「ＩＢ用のＷｅｂサーバ」が「予め記憶された収納企業情報と前記引き継いだ口座振替契約に係る収納企業情報とを照合することにより収納企業認証処理を行うステップ」を有する口座振替契約方法を実行するようにすることは，当業者が容易に成し得たものと認められる。
　したがって，上記相違点２に係る請求項１に係る発明の構成は，引用例１記載の発明及び引用例３に記載された事項に基づいて，当業者が容易に想到し得たものと認められる。
　
（相違点３についての判断）
　引用例３の摘記事項（Ｅ）の【００１８】〜【００２０】段落には，「・・・銀行ホスト３は，・・・図８および図９に示す口座振替契約受付けデータ２７を作成し，ＥＢ(Electronic Banking)システムに蓄積する（Ｓ１７）。口座振替契約受付けデータ２７は図８および９に示すように，ヘッダ部が「申込受付日」「入金口座情報」等から構成され，データ部が「データ区分」「口座振替契約依頼口座情報」「契約者No」「受付けチャネル情報」「結果コード」等から構成される。・・・銀行ホスト３は，企業ホスト５から伝送された口座振替契約依頼データ３３と口座振替契約意志確認情報データ２５を照合し，合致したデータを対象に口座振替契約処理を行う（Ｓ２５）。具体的には，口座振替契約依頼データ３３を基に図７に示すような口座振替契約マスタ２７を更新する。銀行ホスト３は図１０に示すような口座振替依頼データ３３の結果コードフィールドに，契約ができたか否かの情報を書き込み，口座振替契約結果データ３５としてＥＢシステムに蓄積する。」との記載があり，【００２１】段落には，「企業ホスト５はＥＢシステムから口座振替契約結果データ３５を取り込み，結果コードを判定して，図１１に示すような企業ホスト５の請求マスタ３１に口座振替契約情報を追加・更新する。」との記載があり，システム構成に適合させて，上記銀行ホストが実行する口座振替契約に関する処理を，銀行ホストに接続されるサーバで実行するようにすることは，通常行われる設計変更の範囲内であり，格別の困難性は認められない。また，「口座振替契約依頼データ」を基に「口座振替契約マスタ」を更新するに際して，「口座振替契約依頼データ」に基づいて，「口座振替契約マスタ」に準じた形式及びデータ構造とする更新用データを作成し，当該更新用データで「口座振替契約マスタ」を更新することは，マスタファイルの更新処理として周知技術である。
　してみれば，上記銀行ホストが実行する口座振替契約に関する処理を適用して，引用例１記載の発明の「ＩＢ用のＷｅｂサーバ」が，「前記口座振替契約申込み情報及び前記口座振替契約に係る収納企業情報から抽出した情報に基づいて本登録用データを作成するステップ」と，「前記作成された本登録用データを本登録処理のために前記銀行ホストへ送信しさらに該銀行ホストから該本登録処理の可否の結果データを受信するステップ」と，「前記本登録の可否の結果データの受信に応じて契約結果ファイルを作成するステップ」と，「前記契約結果ファイルの内容を前記収納企業ウェブサイトを構築管理する収納企業ホストへ送信するステップ」とを有する口座振替契約方法を実行するようにすることは，当業者が容易に成し得たものと認められる。
　したがって，上記相違点３に係る請求項１に係る発明の構成は，引用例１記載の発明及び引用例３に記載された事項に基づいて，当業者が容易に想到し得たものと認められる。
　
（相違点４についての判断）
　引用例１の摘記事項（Ｂ）の【００２９】〜【００３１】段落に記載された内容からみて，図６に示される口座振替に関する入力内容確認画面は，その上欄に，引継データにより情報が反映された入力項目を含む口座振替の入力フォーム（図５）で入力された顧客情報（顧客の氏名，住所など）が表示されており，顧客端末の表示装置に表示された入力内容確認画面上で，下欄に本人認証のための情報（テレホンバンキングの契約番号，パスワードおよび確認番号）を入力し，上記顧客情報及び本人認証情報が銀行システムのサーバに送信され，当該情報と既取引の顧客データとをサーバで照合を行うことにより，本人認証と口座確認を行っているものと認められる。
　このことからみて，引用例１記載の発明において，本人認証と口座確認を行うために「予め記憶された利用者の口座情報及び認証情報」と照合する情報を，「引き継いだ口座振替契約申込み情報に含まれる第１認証情報」並びに「利用者端末からさらに入力されて送信される第２認証情報」とすることに，格別の困難性は認められない。
　したがって，上記相違点４に係る請求項１に係る発明の構成は，引用例１記載の発明及び引用例１に記載された事項に基づいて，当業者が容易に想到し得たものと認められる。
　
　そして，請求項１に係る発明の作用効果も，引用例１−３から当業者が予測できる範囲のものである。
　
　よって，請求項１に係る発明は，引用例１記載の発明及び引用例１−３の記載事項に基づいて，当業者が容易に発明をすることができたものと認められる。
　
（５）意見書のおける審判請求人の主張について
　審判請求人は，平成２０年７月２３日付け意見書の「(3-2)「理由２」に指摘される請求項１について」において，以下の主張をしている。
　(1) 拒絶理由通知書に記載の「引用例１記載の発明と請求項１に係る発明とが一致する点」に対する主張
　審判請求人は，「本発明の請求項１は、「口座振替契約に係る収納企業情報を引き継ぐステップ」が記載されているのに対し、引用例１は、「サービス提供者を特定するためのコード」としての「サービス提供者コード」のみが記載されているため、この点で、引用例１と異なるものである。」と主張している。
　しかしながら，上記摘記事項（Ｂ）に記載されるように，引用例１記載の「サービス提供者（収納業者）コードを含む管理情報」は，サービス提供者に新規契約の申込みを行うに際し、顧客がサービス提供者を介して口座振替を申込む場合に，銀行システムに引き継がれる「サービス提供者を特定するためのコードである」から，「口座振替に係る」ものであるといえ，一方，請求項１に係る発明の「口座振替契約に係る収納企業情報」は，本願明細書の【００４２】，【００４６】段落の記載を参照すると，「口座振替契約に係る収納企業情報は、例えば、企業名称、サービス名称、若しくはこれらをコード化したもの等である」ことから，引用例１記載の発明の「サービス提供者コードを含む管理情報」は，請求項１に係る発明の「口座振替契約に係る収納企業情報」に対応するものである。
　よって，審判請求人の上記主張は失当である。
　
　(2) 拒絶理由通知書の「（相違点２についての判断）」に対する主張
　審判請求人は，「引用例１には、「収納企業認証処理」が記載されず、引用例３には、「企業ウェブサイトから企業情報を引き継ぐ」処理が記載されず、従って、引用例１と３にはいずれにも前述の「収納企業認証処理」と「企業ウェブサイトから収納企業情報を引き継ぐ」処理との組み合わせは記載されておらず、又、示唆されてもいないため、この組み合わせがないことにより、正確で、迅速な「収納企業認証処理」は期待できない。」と主張している。
　しかしながら，請求項１に係る発明の「収納企業認証処理」は，本願明細書の【００４６】段落の記載を参酌すると，「ＤＢサーバ内に記憶されている収納企業データファイルの情報内容と、利用者端末から送信されてきた口座振替契約に係る収納企業情報の内容とを照合し、収納企業の認証処理を行う」ものであり，引用例３の摘記事項（Ｅ）の【００１７】段落には，「・・・銀行ホスト３は，入力された口座振替企業を口座振替契約の企業として受付けてよいか否かを図５に示す口座振替企業マスタ２３を参照してチェックする（Ｓ１１）。・・・」と記載されており，また，前述のとおり，引用例１には，「企業システムから銀行システムに口座振替に係る収納企業情報を引き継ぐ」処理が記載されており，これらの技術を組み合わせることに格別の阻害要因もないことから，引用例１の引き継いだ「口座情報に係る収納企業情報」により，口座振替企業マスタ２３を参照してチェックして，収納企業認証処理を実現することは当業者が容易に想到し得たものである。
　よって，審判請求人の上記主張は，当を得たものではない。
　
　(3) 拒絶理由通知書の「（相違点３についての判断）」に対する主張
　審判請求人は，「本発明の請求項１に於いて、「本登録用データ」は、「銀行ホストヘ送信」し、「登録処理」を行うためのデータであるが、引用例３に於いては、「口座振替契約依頼データ33を基に・・・口座振替契約マスタ27を更新する」と記載されていることから、本発明の請求項１の「本登録用データ」に相当するものは、引用例３に於いて企業ホストで作成される「口座振替契約依頼データ」である。然しながら、引用例３に於いて、「口座振替契約依頼データ」は、企業ホストによって作成（変換）されるものであり、銀行ホスト等では作成されていない。従って、「IB用のWebサーバ」が、「本登録用データを作成する」とは言えず、示唆してもいないものである。」と主張している。
　しかしながら，マスタファイルを更新する際に，マスタファイルに準じた形式及びデータ構造とする更新用データを作成し，当該更新用データでマスタファイルを更新することは，マスタファイルの更新処理として周知技術であり，マスタファイルに直接データを書き込んで更新する更新処理よりも一般的であり，上記周知技術を適用して，「口座振替契約依頼データ」を基に「口座振替契約マスタ」を更新するに際して，「口座振替契約依頼データ」に基づいて，請求項１の「本登録データ」に対応する「口座振替契約マスタに準じた形式及びデータ構造とする更新用データ」を作成し，当該更新用データで「口座振替契約マスタ」を更新することは，格別のことではない。
　よって，審判請求人の上記主張は，請求項１に係る発明の「本登録用データ」と，引用例３に記載された「口座振替契約依頼データ」とを対応付けた点で失当であり，この対応付けに基づくその余の主張は，当を得たものではない。
　
　また，審判請求人は，「引用例３に於いて、「銀行ホスト3は図10に示すような口座振替依頼データ33の結果コードフイールドに、契約ができたか否かの情報を書き込み」と記載されているが、この記載のみでは、送受信は行なわれていないことから、本発明の請求項１に記載される「銀行ホストから該本登録処理の可否の結果データを受信する」ことと共通しない。」と主張している。
　しかしながら，上記審判請求人が指摘する記載箇所に続いて，「・・・口座振替契約結果データ３５としてＥＢシステムに蓄積する。企業ホスト５はＥＢシステムから口座振替契約結果データ３５を取り込み、結果コードを判定して、図１１に示すような企業ホスト５の請求マスタ３１に口座振替契約情報を追加・更新する。」と記載されており，図３のフローチャートも合わせ見れば，企業ホストは銀行ホストから口座振替契約（本登録処理）の可否の結果データを受信しているものと認められる。
　よって，審判請求人の上記主張は，引用例３の記載を正解しないものである。
　
（６）まとめ
　以上のとおり，請求項１に係る発明は，引用例１記載の発明及び引用例１−３の記載事項に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることはできない。
　
VI．むすび
　したがって，この出願は，特許法第３６条第４項に規定する要件を満たしていないから，拒絶されるべきものである。
　また，請求項１に係る発明は，引用例１記載の発明及び引用例１−３の記載事項に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により特許を受けることはできないから，他の請求項を検討するまでもなく，この出願は拒絶されるべきものである。
　よって，結論のとおり審決する。