• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06Q
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) G06Q
管理番号 1194320
審判番号 不服2005-3072  
総通号数 113 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2009-05-29 
種別 拒絶査定不服の審決 
審判請求日 2005-02-22 
確定日 2009-03-11 
事件の表示 特願2003-109900「口座振替契約方法、システム及びプログラム」拒絶査定不服審判事件〔平成16年11月11日出願公開、特開2004-318364〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 I.手続の経緯
本願は,平成15年4月15日の出願であって,平成16年3月16日付けで拒絶理由が通知され,これに対し,同年5月28日付けで意見書が提出されたものの,平成17年1月24日付けで拒絶査定がされ,同年2月22日に拒絶査定に対する審判請求がされたものであり,当審において,平成20年5月20日付けで拒絶理由が通知され,これに対し,同年7月23日付けで意見書及び手続補正書が提出されたものである。

II.本願特許請求の範囲等の記載
1.平成20年7月23日付け手続補正について
平成20年7月23日付けで提出された手続補正書による手続補正(以下,「本件補正」という。)は,特許請求の範囲を以下のように補正するとともに,対応する発明の詳細な説明における記載を補正するものである。

【請求項1】
利用者端末との間で情報伝送するためのIBウェブサイトを構築管理しかつ銀行ホストとの間で情報伝送するIBサーバにより口座振替契約手続きを行う口座振替契約方法において,前記IBサーバが,
前記利用者端末が口座振替契約申込み情報を入力及び送信した収納企業ウェブサイトから前記IBウェブサイトへと接続を移行する際に該口座振替契約申込み情報及び口座振替契約に係る収納企業情報を引き継ぐステップと,
予め記憶された収納企業情報と前記引き継いだ口座振替契約に係る収納企業情報とを照合することにより収納企業認証処理を行うステップと,
予め記憶された利用者の口座情報及び認証情報と,前記引き継いだ口座振替契約申込み情報に含まれる口座情報及び第1認証情報,並びに利用者端末からさらに入力されて送信される第2認証情報とを照合することにより利用者認証処理を行うステップと,
前記口座振替契約申込み情報及び前記口座振替契約に係る収納企業情報から抽出した情報に基づいて本登録用データを作成するステップと,
前記作成された本登録用データを本登録処理のために前記銀行ホストへ送信しさらに該銀行ホストから該本登録処理の可否の結果データを受信するステップと,
前記本登録の可否の結果データの受信に応じて契約結果ファイルを作成するステップと,
前記契約結果ファイルの内容を前記収納企業ウェブサイトを構築管理する収納企業ホストへ送信するステップとを有することを特徴とする
口座振替契約方法。
【請求項2】(略)
【請求項3】(略)
【請求項4】
利用者端末との間で情報伝送するためのIBウェブサイトを構築管理しかつ銀行ホストとの間で情報伝送するIBサーバにより口座振替契約手続きを行う口座振替契約システムにおいて,前記IBサーバが,
前記利用者端末が口座振替契約申込み情報を入力及び送信した収納企業ウェブサイトから前記IBウェブサイトへと接続を移行する際に該口座振替契約申込み情報及び口座振替契約に係る収納企業情報を引き継ぐ手段と,
予め記憶された収納企業情報と前記引き継いだ口座振替契約に係る収納企業情報とを照合することにより収納企業認証処理を行う手段と,
予め記憶された利用者の口座情報及び認証情報と,前記引き継いだ口座振替契約申込み情報に含まれる口座情報及び第1認証情報,並びに利用者端末からさらに入力されて送信される第2認証情報とを照合することにより利用者認証処理を行う手段と,
前記口座振替契約申込み情報及び前記口座振替契約に係る収納企業情報から抽出した情報に基づいて本登録用データを作成する手段と,
前記作成された本登録用データを本登録処理のために前記銀行ホストへ送信しさらに該銀行ホストから該本登録処理の可否の結果データを受信する手段と,
前記本登録の可否の結果データの受信に応じて契約結果ファイルを作成する手段と,
前記契約結果ファイルの内容を前記収納企業ウェブサイトを構築管理する収納企業ホストへ送信する手段とを有することを特徴とする
口座振替契約システム。
【請求項5】(略)
【請求項6】(略)
【請求項7】
口座振替契約手続きを行うべく,利用者端末との間で情報伝送するためのIBウェブサイトを構築管理しかつ銀行ホストとの間で情報伝送するIBサーバに対し,
前記利用者端末が口座振替契約申込み情報を入力及び送信した収納企業ウェブサイトから前記IBウェブサイトへと接続を移行する際に該口座振替契約申込み情報及び口座振替契約に係る収納企業情報を引き継ぐ機能と,
予め記憶された収納企業情報と前記引き継いだ口座振替契約に係る収納企業情報とを照合することにより収納企業認証処理を行う機能と,
予め記憶された利用者の口座情報及び認証情報と,前記引き継いだ口座振替契約申込み情報に含まれる口座情報及び第1認証情報,並びに利用者端末からさらに入力されて送信される第2認証情報とを照合することにより利用者認証処理を行う機能と,
前記口座振替契約申込み情報及び前記口座振替契約に係る収納企業情報から抽出した情報に基づいて本登録用データを作成する機能と,
前記作成された本登録用データを本登録処理のために前記銀行ホストへ送信しさらに該銀行ホストから該本登録処理の可否の結果データを受信する機能と,
前記本登録の可否の結果データの受信に応じて契約結果ファイルを作成する機能と,
前記契約結果ファイルの内容を前記収納企業ウェブサイトを構築管理する収納企業ホストへ送信する機能とを実現させることを特徴とする
口座振替契約プログラム。
【請求項8】(略)
【請求項9】(略)

2.本件補正前の特許請求の範囲の記載について
当審における平成20年5月20日付け拒絶理由が通知された本件補正前の特許請求の範囲の記載は,出願当初明細書等に記載された,以下のとおりのものである。

【請求項1】
利用者端末との間で情報伝送するためのIBウェブサイトを構築管理しかつ銀行ホストとの間で情報伝送するIBサーバにより口座振替契約手続きを行う口座振替契約方法において,前記IBサーバが,
前記利用者端末が口座振替契約申込み情報を入力及び送信した収納企業ウェブサイトから前記IBウェブサイトへと接続を移行する際に該口座振替契約申込み情報及び口座振替契約に係る収納企業情報を引き継ぐステップと,
予め記憶された収納企業情報と前記引き継いだ口座振替契約に係る収納企業情報とを照合することにより収納企業認証処理を行うステップと,
予め記憶された利用者の口座情報及び認証情報と,前記引き継いだ口座振替申込み情報に含まれる口座情報及び認証情報とを照合することにより利用者認証処理を行うステップと,
前記口座振替契約申込み情報及び前記口座振替契約に係る収納企業情報から抽出した情報に基づいて本登録用データを作成するステップと,
前記作成された本登録用データを本登録処理のために前記銀行ホストへ送信しさらに該銀行ホストから該本登録処理の可否の結果データを受信するステップと,
前記本登録の可否の結果データの受信に応じて契約結果ファイルを作成するステップと,
前記契約結果ファイルの内容を前記収納企業ウェブサイトを構築管理する収納企業ホストへ送信するステップとを有することを特徴とする
口座振替契約方法。
【請求項2】?【請求項9】(略)

III.当審において通知した拒絶理由
当審において平成20年5月20日付けで通知した拒絶理由は,理由1,2からなり,その概要はそれぞれ以下のとおりである。

1.理由1の概要
「この出願は,特許請求の範囲の記載が下記の点で,特許法第36条第6項第1号又は第2号に規定する要件を満たしていない。

記

A.請求項1における「予め記憶された利用者の口座情報及び認証情報と,前記引き継いだ口座振替申込み情報に含まれる口座情報及び認証情報とを照合することにより利用者認証処理を行うステップ」について
(1)上記「口座振替申込み情報」と当該請求項に記載された「口座振替契約申込み情報」との関係が,明りょうでない。
(2)上記「認証情報」と明細書【0044】段落に記載された「口座暗証番号102g,ログインID102h,ログインパスワード102i等の認証情報」との関係が,明りょうでない。
(3)上記「口座振替申込み情報」が「口座振替契約申込み情報」であり,且つ,上記「認証情報」が,明細書【0044】段落に記載された「口座暗証番号102g,ログインID102h,ログインパスワード102i等の認証情報」である場合,【0044】段落には,「利用者は,図4(B)の画面上でさらに口座暗証番号102g,ログインID102h,ログインパスワード102i等の認証情報を入力し,確認ボタン108をクリック等することによりウェブサーバ40へ送信する。」と記載されていることからみて,上記「口座暗証番号102g,ログインID102h,ログインパスワード102i等の認証情報」は,利用者端末で入力されたものであって,収納企業ウェブサイトから引き継いだ口座振込契約申込み情報に含まれる情報とは認められない。そうしてみると,上記「前記引き継いだ・・・に含まれる口座情報及び認証情報とを照合することにより利用者認証処理を行う」は,発明の詳細な説明に記載したものとは認められない。

B.上記Aと同様に,請求項4における「予め記憶された利用者の口座情報及び認証情報と,前記引き継いだ口座振替申込み情報に含まれる口座情報及び認証情報とを照合することにより利用者認証処理を行う手段」,請求項7における「予め記憶された利用者の口座情報及び認証情報と,前記引き継いだ口座振替申込み情報に含まれる口座情報及び認証情報とを照合することにより利用者認証処理を行う機能」について,当該記載は明りょうでなく,発明の詳細な説明に記載したものとは認められない。

C.(略)
D.(略)
E.(略)

よって,請求項1-9(請求項4,7を引用する請求項も含む)に係る発明は明確でなく,また,請求項1-9(請求項1,4,7を引用する請求項も含む)に係る発明は,発明の詳細な説明に記載したものでない。」

2.理由2の概要
「本願の請求項1-9に係る発明は,その出願前に日本国内又は外国において,頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。
記
引用例1.特開2002-157426号公報
引用例2.特開2002-366766号公報
引用例3.特開2001-134679号公報 」

IV.当審の判断
1.理由1についての判断
(1)理由1のAについて
理由1のAで指摘した点に関して,請求項1のIBサーバが実行する「予め記憶された利用者の口座情報及び認証情報と,前記引き継いだ口座振替契約申込み情報に含まれる口座情報及び第1認証情報,並びに利用者端末からさらに入力されて送信される第2認証情報とを照合することにより利用者認証処理を行うステップ」について,以下に検討する。

(a)請求項1の記載について
IBサーバが実行する上記「利用者認証処理を行うステップ」で照合する情報について,請求項1に記載された特定事項を検討する。
本件補正により,補正前の「引き継いだ口座振替申込み情報に含まれる口座情報及び認証情報」における「認証情報」が,「第1認証情報,並びに利用者端末からさらに入力されて送信される第2認証情報」と補正されている。
この補正事項について,意見書の「(2-3)補正の根拠」における主張を参酌すると,上記「第1認証情報」は,【0038】段落に記載される「利用者の氏名,住所,収納企業から利用者に対し予め付与された顧客番号等」を特定し,上記「第2認証情報」は,【0044】段落に記載される「口座暗証番号102g,ログインID102h,ログインパスワード102i等」を特定するものである。このことから,上記「第1認証情報」は,引き継いだ口座振替契約申込み情報に含まれた情報であり,上記「第2認証情報」は,引き継いだ口座振替契約申込み情報に含まれた情報以外の,利用者端末からさらに入力された情報と認められる。
そうしてみると,IBサーバが実行する上記「利用者認証処理を行うステップ」において,「予め記憶された利用者の口座情報及び認証情報」と照合する情報は,「引き継いだ口座振替契約申込み情報に含まれる口座情報」及び「引き継いだ口座振替契約申込み情報に含まれる第1認証情報」並びに「利用者端末からさらに入力されて送信される第2認証情報」であると認められる。

(b)発明の詳細な説明の記載について
IBサーバが実行する上記「利用者認証処理を行うステップ」に関する,発明の詳細な説明の記載を検討する。
まず,発明の詳細な説明の【0047】段落の記載を参酌すると,IBサーバの利用者認証処理部が行う利用者認証処理(S6)は,「利用者が当該銀行に有している口座の実在確認」と,「ログイン要求してきた利用者が当該口座の名義人本人であることの認証」とを行う処理であり,具体的には,利用者認証処理部は,IBサーバの備えるDBサーバ内に記憶されている顧客データファイルから当該利用者の口座情報及び認証情報を取得し,この顧客データファイルの口座情報及び認証情報の内容と,ステップS4で利用者端末から送信されてきた口座情報及び認証情報の内容とを照合して,口座の実在確認及び利用者認証を行うものである。
ここで,上記「ステップS4で利用者端末から送信されてきた口座情報及び認証情報」に関して,【0041】?【0044】段落,【図4】(A),(B)の記載を参酌すると,【図4】(B)に図示されるように,IBウェブサイトの画面には,収納企業ウェブサイトから引き継がれた「口座振替契約申込み情報」の中から,「氏名」,「科目」,「口座番号」,「顧客情報」が表示され,引き継がれた情報が表示された画面上で,利用者が「暗証番号」,「ログインID」,「ログインパスワード」の認証情報をさらに入力し,確認ボタンをクリック等することにより,これらの情報が,利用者端末からIBサーバの備えるウェブサーバへ送信され,ウェブサーバは,送信されてきた情報を一時的に記憶するものである。ここで【0038】段落の記載も参酌すると,IBウェブサイトの画面に表示される上記「科目」及び「口座番号」は「口座情報」に該当し,上記「氏名」及び「顧客情報」は「第1認証情報」に該当するものである。このことから,「引き継いだ口座振替契約申込み情報に含まれる口座情報(「科目」及び「口座番号」)」,「引き継いだ口座振替契約申込み情報に含まれる第1認証情報(「氏名」及び「顧客情報」)」,「利用者端末からさらに入力されて送信される第2認証情報(「暗証番号」,「ログインID」,「ログインパスワード」)」が,ステップS4で利用者端末からIBサーバの備えるウェブサーバに送信され,当該ウェブサーバは,上記「口座情報」及び「第1認証情報」並びに「第2認証情報」を一時的に記憶しているものと認められる。
しかしながら,【0047】段落を参酌しても,「利用者が当該銀行に有している口座の実在確認」と,「ログイン要求してきた利用者が当該口座の名義人本人であることの認証」とを行うために,「顧客データファイルの口座情報及び認証情報の内容」と,「ステップS4で利用者端末から送信されてきた口座情報及び認証情報の内容」とを照合すると記載されているものの,照合する情報について,「口座情報」及び「認証情報」に含まれるいずれの情報を照合するのか具体的に説明する記載はないため,「第1認証情報」並びに「第2認証情報」は,ステップS4で利用者端末から送信されてきた認証情報であるものの,「第1認証情報」並びに「第2認証情報」が照合する情報として使用されていることが記載されていると認めることはできない。
また,【0047】段落やその他の記載を参酌すると,上記顧客データファイルのマスタファイルは,銀行ホストの顧客マスタに保管されたものであり,口座作成時に取得した利用者(名義人)の口座情報が記憶されていると記載されており,銀行ホストの顧客マスタであることからみて,当該口座情報には口座番号が含まれること,口座番号に対応して口座暗証番号などの認証情報も記憶されているものと認められるものの,口座番号や口座暗証番号以外に,「口座情報」及び「認証情報」として,どのような情報が記憶されているのか具体的に説明されていないため,顧客データファイル側から見ても,「利用者が当該銀行に有している口座の実在確認」と,「ログイン要求してきた利用者が当該口座の名義人本人であることの認証」とを行うために,「第1認証情報」並びに「第2認証情報」が照合する情報として使用されていることが記載されていると認めることはできない。
このように,発明の詳細な説明には,「利用者が当該銀行に有している口座の実在確認」と,「ログイン要求してきた利用者が当該口座の名義人本人であることの認証」とを行うために,IBサーバのDBサーバ内に記憶されている利用者の口座情報及び認証情報と,利用者端末から送信されてきた口座情報及び認証情報とを照合することは記載されているものの,「第1認証情報」並びに「第2認証情報」が,照合する情報として使用されていることが記載されていると認めることはできない。
よって,IBサーバが実行する上記「利用者認証処理を行うステップ」において,「予め記憶された利用者の口座情報及び認証情報」と照合する情報が,「引き継いだ口座振替契約申込み情報に含まれる口座情報」及び「引き継いだ口座振替契約申込み情報に含まれる第1認証情報」並びに「利用者端末からさらに入力されて送信される第2認証情報」であることは,発明の詳細な説明に記載された事項であるとは認められない。

(c)発明の詳細な説明の記載から自明な事項について
利用者端末から送信されてきた認証情報である「第1認証情報」並びに「第2認証情報」の両情報を照合する情報として使用することが,発明の詳細な説明の記載から自明な事項であるかどうかについて以下に検討する。
「第1認証情報」は,【0038】段落に記載されように「利用者の氏名,住所,収納企業から利用者に対し予め付与された顧客番号等」であり,利用者の本人確認(認証)のための情報であると説明されているものの,この認証情報は,【0039】段落に記載されるように,収納企業ホストが利用者の認証を行うための情報であり,収納企業ホスト内の請求マスタに記憶された情報と照合し,一致していると判断した場合に本人であると認証するものであり,各収納企業ホスト内の「請求マスタ」に記憶された情報が,銀行ホストに記憶されているとは認められないため,「第1認証情報」により,IBサーバにおける「ログイン要求してきた利用者が当該口座の名義人本人であることの認証」を行うことはできない。
これに対して,「第2認証情報」は,【0044】段落に記載されるように「口座暗証番号,ログインID,ログインパスワード等」であり,通常,「口座暗証番号」は,口座名義人本人のみが知る情報として,「口座番号」に対応させて銀行ホストの顧客マスタに保管される情報であるから,顧客データファイルの「口座情報」及び「認証情報」と,「口座番号」を含む「引き継いだ口座振替契約申込み情報に含まれる口座情報」及び「口座暗証番号」を含む「第2認証情報」とを照合することにより,「口座の実在確認」及び「ログイン要求してきた利用者が当該口座の名義人本人であることの認証」を行う処理が同時に実現可能である。
そうしてみると,「口座の実在確認」と,「ログイン要求してきた利用者が当該口座の名義人本人であることの認証」とを行う利用者認証処理は,「予め記憶された利用者の口座情報及び認証情報」と,「引き継いだ口座振替契約申込み情報に含まれる口座情報」及び「利用者端末からさらに入力されて送信される第2認証情報」とを照合することで実現可能であり,これに加えて,「引き継いだ口座振替契約申込み情報に含まれる第1認証情報」との照合を行うようにすることは,照合する情報を不必要に冗長化することに他ならず,通常のシステム設計の観点からみても,当業者にとって,発明の詳細な説明の記載から自明な事項であるとは認められない。

(d)まとめ
以上,発明の詳細な説明の記載を総合的に判断すると,IBサーバが実行する上記利用者認証処理を行うステップは,「予め記憶された利用者の口座情報及び認証情報」と,「引き継いだ口座振替契約申込み情報に含まれる口座情報」及び「利用者端末からさらに入力されて送信される第2認証情報」とを照合するものであり,「第2認証情報」に加えて「引き継いだ口座振替契約申込み情報に含まれる第1認証情報」も照合する情報とすることは,発明の詳細な説明に記載されたものとは認められず,また,発明の詳細な説明の記載から自明な事項とも認められない。
したがって,請求項1の「予め記憶された利用者の口座情報及び認証情報と,前記引き継いだ口座振替契約申込み情報に含まれる口座情報及び第1認証情報,並びに利用者端末からさらに入力されて送信される第2認証情報とを照合することにより利用者認証処理を行うステップ」は,発明の詳細な説明に記載されたものではない。

(2)理由1のBについて
上記Aと同様に,請求項4における「予め記憶された利用者の口座情報及び認証情報と,前記引き継いだ口座振替契約申込み情報に含まれる口座情報及び第1認証情報,並びに利用者端末からさらに入力されて送信される第2認証情報とを照合することにより利用者認証処理を行う手段」,請求項7における「予め記憶された利用者の口座情報及び認証情報と,前記引き継いだ口座振替契約申込み情報に含まれる口座情報及び第1認証情報,並びに利用者端末からさらに入力されて送信される第2認証情報とを照合することにより利用者認証処理を行う機能」は,発明の詳細な説明に記載されたものではない。

(3)まとめ
よって,請求項1-9(請求項1,4,7を引用する請求項も含む)に係る発明は,発明の詳細な説明に記載したものでないから,この出願の特許請求の範囲の記載は,特許法第36条第6項第1号に規定する要件を満たしていない。

2.理由2について
(1)本願発明
本願の請求項1に係る発明は,本件補正により補正された,特許請求の範囲の請求項1に記載された,上記のとおりのものである。

(2)引用例
(引用例1)特開2002-157426号公報(平成14年5月31日出願公開)には,図面と共に,以下の事項が記載されている。
(A)【0014】?【0019】段落
「【0014】
【発明の実施の形態】本発明の実施形態として,ネットワーク完結型の口座振替スキームを例に説明する。図1は,このスキームを実現する口座振替システムの全体構成図であり,銀行,多数の顧客,少なくとも一つのサービス提供者の間で相互に情報伝達可能なネットワーク環境が整備されていることを前提としている。以下の説明では,現在,最もポピュラーなネットワークであるインターネットを用いたシステムを例示している。しかしながら,本発明は,これに限定されるものではなく,各種の有線・無線ネットワークを用いて,同様のスキームを実現するシステムに広く適用可能である。
【0015】銀行は,インターネット上の所定のWebサイト(銀行サイト)において,インターネットバンキング(IB)を開設している。顧客は,このインターネットバンキングを利用して,オンラインで入出金や振込等を行うことができる他,後述する口座振替に関する手続を行うこともできる。一方,サービス提供者は,(1)サービス加入者である顧客に対して所定のサービスを提供し,(2)所定のWebサイト(サービス提供者サイト)においてホームページを開設し,かつ,(3)口座振替の委任を受けている者である。これらの条件(1)?(3)を満足し得る業種としては,例えば,五大公共,税金,学費(各種私立学校,保育園・幼稚園),保険,カード・信販,会費,返済金等が挙げられ,このような業種を営む者が,本明細書でいう「サービス提供者」となり得る。顧客は,サービス提供者サイトからサービス契約の申込みを行うことができる(オンライン・サインアップ)。本実施形態の特徴の一つは,サービス提供者とのサービス契約と,それに伴う口座振替に関する銀行手続との同時処理を実現する点にある。
【0016】銀行システム1は,サーバ2,記憶装置3,通信装置4等を主体に構成されており,顧客端末10との間およびサービス提供者システム20との間で,ネットワークを介した情報伝達が可能である。サーバ2は,図1に示したように単一のサーバであっても,Webサーバや管理サーバ等を含む複数のサーバがLANによって結ばれた形態であってもよい。同様に,記憶装置3も単一または複数のいずれであってもよい。記憶装置3には,インターネットバンキングを運営するのに必要な各種データベースが格納されているが,本実施形態との関係では,申込受付データベース5,テレホンバンキング契約データベース6が重要となる。申込受付データベース5は,個々の顧客から受けた口座振替の申込みを一元的に管理するためのデータベースであり,受付案件毎に個別の受付番号が付されたレコード群で構成されている。個々のレコードには,口座振替の申込みに際して,顧客が入力した顧客情報(振替口座を特定するための情報を含む)が記述されている。また,テレホンバンキング契約データベース6は,テレホンバンキング(TB)契約者の情報を一元的に管理するためのデータベースであり,例えば,契約者毎に個別の番号が付されたレコード群で構成されている。個々のレコードには,契約者情報(テレホンバンキングの契約番号,パスワード,確認番号等を含む)が記述されている。
【0017】顧客端末10は,銀行システム1との間およびサービス提供者システム20との間で,ネットワークを介した情報伝達が可能であり,送受信されたデータは,ブラウザによって閲覧可能な状態で表示される。一例として,顧客端末10は,コンピュータ11,キーボードやマウス等の入力装置12,CRTやLCD等の表示装置13,通信装置14等を主体に構成されている。ただし,顧客端末10は,インターネットに接続可能で,情報を入力・確認し得るものであればどのような形態でもよく,例えば,デジタルTVの送受信装置や通信機能を有する家庭用ゲーム機等であってもよい。顧客は,自己の顧客端末10を操作して,銀行やサービス提供者が運営するWebサイトにアクセスし,サービス契約の申込み,口座振替の依頼等を行う。
【0018】サービス提供者システム20は,サーバ21,記憶装置22,通信装置23等を主体に構成されており,銀行システム1との間および顧客端末10との間で,ネットワークを介した情報伝達が可能である。サーバ21および記憶装置22は,単一または複数のいずれの形態であってもよい。また,サービス提供者と集金代行者が別主体である場合,それぞれのシステムはネットワークを介して情報伝達可能であることが多いので,それらをまとめてサービス提供者システム20と捉えることができる。記憶装置22中には,サービス提供者が業務を遂行する上で,あるいは,サイト運営に必要な各種データベースが格納されているが,本実施形態との関係では,申込受付データベース24が重要となる。申込受付データベース24は,個々の顧客から受けたサービス契約の申込みを一元的に管理するためのデータベースであり,受付案件毎に仮採番された固有番号付のレコード群で構成されている。個々のレコードには,サービス契約の申込者の顧客情報(振替口座を特定するための情報を含む)が記述されている。
【0019】顧客が口座振替の手続を行うケースとして,下記の2つのルートがある。
[ルートA] サービス提供者に新規契約の申込みを行うに際し,顧客がサービス提供者を介して口座振替を申込むルートである。この場合,顧客がサービス提供者との契約申込みを行った直後に,データ引継ぎを伴う画面遷移を行うことによって,銀行に対して口座振替の手続を行う。
[ルートB] サービス提供者との間に既に契約があり口座振替の変更を行う場合,顧客が銀行に対して口座振替を直接申込むルートである。この場合,口座振替の申込みを受けた銀行は,サービス提供者に対して,口座振替の変更があった旨を通知する。」

(B)【0020】?【0036】段落
「【0020】(第1の実施形態)図2は,本実施形態に係る口座振替手順の説明図である。以下,Aルートにおいて顧客が行う手続の流れに従い,ネットワーク上の情報伝達とシステムの内部処理とについて詳述する。なお,ステップ1?5およびステップ15はサービス提供者システム20と関連した手順,ステップ6?14は,銀行システム1と関連した手順であり,一連の手順(ステップ1?15)はリアルタイム処理で実行される。
【0021】(ステップ1)サービス提供者サイトへのアクセス
まず,顧客は,入力装置12を操作して,ブラウザよりサービス提供者(収納業者)側のサーバ21(Webサーバ)を指定するアドレス(URL)を入力・送信する。これを受けて,サービス提供者側のサーバ21は,HTMLで記述された初期画面データを顧客端末10側に送信する。顧客端末10がこの画面データを受信すると,新規契約の申込みに関する入力フォームへのリンクが張られた初期画面(ポータル画面)が表示装置13に表示される。
【0022】(ステップ2)新規契約の申込み入力
顧客は,入力フォーム画面に移行した後に,このフォームにおいて要求される顧客情報を順次入力していく。ここで入力すべき顧客情報には,申込者の氏名,住所,電話番号等の他に,口座振替手続を銀行に対して行う際に必要となる「振替口座特定情報」(銀行の支店番号,科目,口座番号,口座名義人といった振替口座を特定するための情報)も含まれる。なお,本実施形態では,銀行が口座振替における本人認証と出金を行う事前承認とを得ることが可能なテレホンバンキング契約者を口座振替申込みの主体的要件としているが,本人認証と出金を行う事前承認とを得ることが可能なものであれば他の方法でもよく,例えば,本人認証のためのキャッシュカードやICカード等を用いてもよい。顧客は要求された全情報を入力した後,所定の操作を行うことにより,これらの情報セットを含むデータがサービス提供者システム20側に送信される。
【0023】顧客端末10からデータを受信したサービス提供者システム20は,契約申込者の顧客情報に基づいて,新規契約の申込みに関する受付処理を行う。ただし,契約が未だ成立していない状態なので,サーバ21は,固有番号を仮採番した上で,顧客情報が記述された新規レコードを申込受付データベース24に追加する。そして,受付内容の確認を顧客に促すために,確認画面データを顧客端末10側に送信する。
【0024】(ステップ3)新規契約に関する申込み内容の確認
顧客端末10がサービス提供者システム20側からデータを受信すると,申込まれた内容(顧客情報や支払方法)と固有番号とが表示装置13に表示される。それとともに,この確認画面において,銀行の口座振替を行うか否かの確認(換言すれば,テレホンバンキング契約者か)と,銀行へのデータ引継ぎを行ってよいか否かの確認とを顧客に促す。顧客は,表示された内容を確認し,それに同意する場合には,「同意する」ボタンをクリックする。このアクションによって,顧客端末10からサービス提供者システム20側に顧客が同意した旨通知される。
【0025】(ステップ4)引継画面によるデータ引継ぎの確認
通知を受けたサービス提供者システム20は,顧客の誤認防止および顧客情報の保護の観点より,引継画面データを顧客端末10側に送信する。このデータを受信した顧客端末10は,銀行サイトへリンクする旨の引継画面を別ウインドウで表示する(ステップ3で表示された確認画面が非アクティブになる)。そして,新規契約の申込みに際して入力された顧客情報の一部が銀行に引継がれることを顧客に明示する。引継画面上に表示された「確認」ボタンのクリックアクションが行われた場合,銀行システム1へのデータ引継ぎが開始される(ステップ5)。
【0026】銀行システム1に引継がれるデータ内容は,銀行とサービス提供者との取決めによって規定されているが,最低限,上述した振替口座特定情報を含んでいる必要がある。この情報が銀行側に通知されないと,銀行が振替を行うための口座を特定できないからである(オンラインでの口座振替の申込み受付ができなくなる)。図3は,引継データ内容の一例を示す図である。銀行側に引継ぐデータとしては,管理情報1?5と顧客情報6?11とに大別される。管理情報のうち,「2.ルート区分」は,サービス提供者を介した口座振替(ルートA),銀行に直接申込まれた口座振替(ルートB)のいずれかであるかを区別する情報である。「3.保険/非保険区分」は,保険とそれ以外とを区別するため必要な情報である。両者を区別する理由については,後述する第2の実施形態において述べる。「4.サービス提供者コード」は,サービス提供者を特定するためのコードである。一方,顧客情報としては,契約者氏名,住所,電話番号の他に,振替口座特定情報である支店番号,(普通口座の)口座番号,名義人がある。なお,本実施形態では,振替可能な口座が普通口座に限定されているという理由で,引継データ中に「科目」(普通,当座等)という項目を設けていない。
【0027】銀行システム1に引継がれるデータ(顧客情報)は,顧客端末10を経由して転送される。換言すれば,顧客端末10は,サービス提供者システム20とのデータ送受信プロセスにおいて内部に記憶された引継データを読出し,それを銀行システム1に転送する。このような転送形態を採用すると,他のシステムとの整合性を意識せずに銀行システム1と顧客端末10との間における独自のセキュリティも可能となる。例えば,銀行システム1と顧客端末10との間に,セキュリティプロトコルの一態様であるSSL(Secure Sockets Layer)128biを確保することができる。これにより,引継データを銀行システム1に転送する際における情報の盗聴,改ざん,なりすましといった第三者からの攻撃に対抗でき,顧客情報の保護を図ることができる。ここで,SSLは,TCPと上位アプリケーションとの中間に位置するプロトコルであり,公開鍵暗号方式を利用して通信相手を認証する機能や,共通鍵暗号方式を利用してデータを暗号化する機能を有する。
【0028】なお,サービス提供者側のサーバ21がSSLを具備している場合は,サービス提供者側のサーバ21から銀行システム1側に直接データを送信してデータを引継ぐことも可能である。
【0029】(ステップ6)Web自動支払の説明および口座振替の申込み入力
引継データを受信した銀行システム1は,外部より指示されたサービス提供者に対応する受付画面データを顧客端末10側に送信する。顧客端末10がこのデータを受信すると,例えば,図4に示すような口座振替説明画面(サービス提供者毎にカスタマイズされた画面)において,データを引継いだサービス提供者を表示するとともに,Web自動支払の説明文が表示される。そして,顧客が所定のアクションを行うと,口座振替の規定画面が表示される(ステップ7)。表示された規定内容に同意する場合,顧客は「同意する」ボタンをクリックする。このアクションにより,顧客端末10から銀行システム10側に顧客が同意した旨通知される。これにより,図5に示すような口座振替の入力フォームが表示される。この入力フォームには引継データが反映されており,いくつかの入力項目には既に情報が確定データとして記述されている。顧客は,ブランクの入力項目,すなわち,顧客自身で補記すべき項目に情報を入力していく。そして,顧客による「OK」ボタンのクリックにより,これらの情報セットを含むデータが銀行システム1側に送信される。
【0030】(ステップ8)入力内容の確認
データを受信した銀行システム1は,入力内容確認データを顧客端末10側に送信する。これによって,図6に示すような口座振替に関する入力内容確認画面が表示装置13に表示される。顧客は,この画面に表示された顧客情報を改めて確認するとともに,下欄において要求されている本人認証のための情報(テレホンバンキングの契約番号,パスワードおよび確認番号)を入力した上で,「OK」ボタンをクリックする。これにより,入力された本人認証情報を含むデータが銀行システム1側に送信される。なお,上述した本人認証のための情報は,認証として用いるために再度入力を要求しているが,データ引継ぎにより入力済項目としてもよい。
【0031】顧客端末10からデータを受信した銀行システム1は,口座振替の申込みに関する受付処理を行う(ステップ9)。すなわち,サーバ2は,引継データに含まれる固有番号とともに,本人認証情報を含む顧客情報が記述された新規レコードを申込受付データベース5に追加する。そして,サーバ2は,ステップ8において顧客が入力した本人認証情報と,既取引の顧客データとに基づいて,本人認証を行う(ステップ10)。なお,このステップ10では,本人認証の他に,出金口座の届出確認(口座確認)もそのステップにおいて行われる(これらを総称して「0次審査」と呼ぶ)。既取引の顧客データとしてテレホンバンキング契約データベース6を利用する場合,まず,テレホンバンキング契約データベース6を検索して,その顧客に関するレコードを抽出する。つぎに,抽出されたレコードに記述されたテレホンバンキングの契約番号,パスワード,確認番号と,ステップ8において顧客が入力した本人認証情報とを比較する。その結果,本人認証が得られなかった場合(両情報が一致しない場合),ステップ11の否定判定を経てステップ12に進み,本人認証ができなかった旨の画面を表示装置13に表示させる。これに対して,本人認証が得られた場合(両情報が一致する場合),ステップ11の肯定判定を経てステップ13に進み,銀行側における口座振替の申込受付が終了したことを示す画面を表示させる。
【0032】(ステップ14,15)引継確認および今後の段取りの確認
銀行システム1は,顧客の誤認防止および顧客情報の保護の観点より,サービス提供者サイトへ戻る旨を記述した引継画面を表示装置13に表示させる。引継画面上に表示された「確認」ボタンのクリックアクションが行われた場合,顧客が引継ぎに同意したものと判断する。この場合,所定の情報とともに口座振替の申込受付が完了した旨を示す引継データを,上述したセキュリティプロトコルを用いて顧客端末10に送信する。そして,顧客端末10よりこの引継データを受信したサービス提供者システム20は,今後の段取りに関する説明文が記述された画面を表示装置13に表示させる。
【0033】なお,顧客が銀行に対して口座振替を直接申込む場合(ルートB),入力装置12を操作して,ブラウザより銀行側のサーバ2(Webサーバ)を指定するアドレス(URL)を入力・送信する。これを受けて,銀行側のサーバ2は,初期画面を表示装置13に表示させる(ステップ5’)。顧客は,この初期画面よりリンクが張られた口座振替説明画面(図4参照)に移行する(ステップ6)。なお,上述したように口座振替説明画面はサービス提供者毎にカスタマイズされているため,顧客はどのサービス提供者に関する口座振替の申込みか指示する必要がある。つまり,サービス提供者の特定は,銀行システム1外のシステムである顧客端末10の操作より行われる。それ以降の手順は,上述したルートAとほぼ同様であるが,引継確認および今後の段取の確認(ステップ14,15)の際に,口座振替の変更があった旨と顧客情報を含む引継データとがサービス提供者システム20に送信されることとなる。
【0034】このように,本実施形態に係るネット完結型口座振替スキームによれば,インターネットを用いて顧客主導で口座振替手続を行う際に,サービス提供者サイトで入力した顧客情報を銀行側に引継いでいる。これにより,オンラインによるサービス契約の申込みと同時に口座振替手続を行うことができるので,その登録までに要する時間を短縮することができる。また,データの引継ぎは,その旨の確認を顧客に促して顧客の同意を得ることを条件に行われるため,現在どのサイトにアクセスしているかに関する顧客の誤認を防止でき,顧客情報保護の要請にも合致している。
【0035】また,サービス提供者と銀行との間でデータが引継がれ,両者の間で必要な電子データを提供し合っている。そのため,顧客にとっては,サービス提供者側と銀行側とに対して同じデータを重複して入力する必要がなくなるので,それに要する負担が軽減される。一方,銀行およびサービス提供者にとっては,所有する顧客情報を一致させることができるとともに,事務手続の省力化を推進できる。特に,サービス提供者にとっては,従来,銀行での口座振替申込処理完了後に契約事務手続を開始していたが,本スキームでは,契約申込みと口座振替の申込みとの同時伝送が可能になるため,契約処理を著しく迅速化できる。なお,銀行は,テレホンバンキング等の既取引の顧客データを用いて,口座振替申込みの受付時に本人認証を行うため,その登録処理の一層の迅速化を図ることができる。
【0036】また,銀行との取引でのみ必要となる情報(テレホンバンキングの契約番号,パスワード,または確認番号等)を,サービス提供者側に渡す必要がないので,セキュリティを確保することができる(情報の漏洩防止)。さらに,顧客と銀行との間では,セキュリティプロトコルが確保されているため,データの引継時における第三者からの攻撃に対抗することができ,高度なセキュリティレベルを確保することができる。」

(C)【0043】?【0046】段落
「【0043】(第3の実施形態)図8は,銀行における口座振替手続の概略的なフローチャートである。ステップ31の口座振替Web取込みは,上述したように,オンラインによる口座振替の申込受付時にリアルタイム処理で行われる本人認証である。続くステップ32の一次審査は,口座振替の申込時に入力された情報の適切性を個別チェックするステージである。そして,ステップ33の二次審査は,口座が直前に解約されていないかといった口座の実在性をチェックするステージである。そして,以上の審査を経て,ステップ34において審査結果が通知される。通常,一次審査および二次審査には相応の時間を要するため,口座振替登録が完了するまでには数日を要する。
【0044】そこで,図9に示すように,銀行は,インターネット上において電子掲示板を開設し,この掲示板を顧客およびサービス提供者が閲覧することにより,個々の案件に関する現在の審査状況を把握可能にする。口座振替に関する進捗状況の確認ツールである電子掲示板を活用することにより,処理状況の即時通知が可能となる。また,収納業者への事前通知や通知確認が不要となる。一方,サービス提供者にとっては,処理状況に応じた迅速な対応(例えば,口座振替の準備開始等)が可能となるため,サービス契約事務の開始を促進できる。また,本掲示板を用いてサービス提供者の収納委託先を選択可能とすることにより,顧客による口座振替申込みとサービス提供者の収納委託先決定との作業フローを切り分けることができるため,後決め先指定が可能となり,選択の自由度が増す。
【0045】銀行システム1は,電子掲示板用データベース7を有しており,このデータベース7が更新されると,その内容が電子掲示板に随時反映される(ネットワーク上に公開される)。電子掲示板用データベース7は,口座振替処理に関する個々の案件の進捗状況を一元的に管理するためのデータベースであり,案件毎の固有番号(固有番号については上述)が付されたレコード群で構成されている。個々のレコードには,上述した「保険/非保険区分」を始めとして,「Web受付日時」,「一次結果」,「不備コード」,「登録結果」および収納委託先を後決めの場合に限り入力される「収納業者コード」等が記述されている。
【0046】図10は,電子掲示板の表示例を示す図である。サービス提供者毎に別個の画面を表示するようにし,サービス提供者毎に個別に発行したアクセスパスワードの入力によって,自己の案件に関する進捗状況の一覧を参照することができる。なお,サービス提供者毎にアクセスログをとるようにしてもよい。このアクセスログを確認することによって,サービス提供者への通知確認が可能となる。」

これらの記載からみて引用例1には,以下の発明(以下,「引用例1記載の発明」という。)が開示されていると認められる。
「顧客端末との間で情報伝送するためのインターネットバンキング(IB)を開設している銀行サイトを構築管理する銀行システムのサーバにより口座振替申込み手続を行う口座振替申込み手続方法において,前記銀行システムのサーバが,
前記顧客端末が口座振替の申込みのための顧客情報を入力及び送信したサービス提供者サイトから前記インターネットバンキング(IB)を開設している銀行サイトへと接続を移行する際に該口座振替の申込みのための顧客情報及びサービス提供者(収納業者)コードを含む管理情報を引き継ぐステップと,
予め記憶された顧客(契約者)の口座情報及び本人認証情報(契約番号,パスワードおよび確認番号)と,前記引き継いだ口座振替申込みのための顧客情報に含まれる口座情報及び本人認証情報(契約番号,パスワードおよび確認番号)とを照合することにより本人認証処理を行うステップと
を有する口座振替申込み手続方法」

(引用例2)特開2002-366766号公報(平成14年12月20日出願公開)には,図面と共に,以下の事項が記載されている。
(D)【0019】?【0080】段落
「【0019】
【発明の実施の形態】〔第1実施形態〕本発明の第1実施形態に係る資金処理システムは,このサービスである請求連動サービスを受ける利用者と販売者とを顧客データベースに登録しておき,この顧客データベースに登録されている販売者から,登録されている利用者についての決済要求を受け付けた場合には,この決済要求に基づいて利用者の口座から引落処理を行い,この引落処理が正常に行えたかどうかを示す結果通知を販売者に送信することにより,販売者がリアルタイムに決済処理を行えるようにしたものである。より詳しくを以下に説明する。
【0020】まず,図1に基づいて,本実施形態に係る資金処理システムの構成を説明する。この図1は,販売者と利用者と金融機関とを,ネットワークを介して相互に接続した資金処理システムの構成を示す図である。
【0021】本実施形態においては,例えば,販売者は,損害保険を販売する損害保険会社であり,利用者は,その損害保険会社の販売代理店である。利用者である販売代理店は,最終的な消費者に損害保険を販売し,これを販売者である損害保険会社に通知する。このような処理は,日常業務として頻繁に行われるものである。
【0022】この資金処理システムの前提として,利用者と,販売者と,金融機関との三者間で,請求連動サービスに関する口座振替契約を締結しておく。すなわち,販売者からの決済要求に対しては,その都度利用者の承諾を得ることなく,その決済要求に示されている金額を利用者の引落口座から引き落として販売者の入金口座に入金してもよいという契約を締結しておく。この契約を締結しておくことにより,金融機関としては,販売者からの決済要求に基づいてリアルタイムに決済処理をすることが可能になる。
【0023】図1に示すように,販売者は,販売者サーバコンピュータ10を備えており,この販売者サーバコンピュータ10は,インターネット等の公衆ネットワークであるネットワーク20に接続している。すなわち,ネットワーク20には,不特定多数の者がアクセスできる。この販売者に対する利用者は,1又は複数存在しており,各利用者は,利用者端末30を備えている。利用者端末30も,ネットワーク20に接続している。このため,利用者は,利用者端末30を操作することにより,ネットワーク20を介して,販売者サーバコンピュータ10にアクセスすることが可能である。
【0024】金融機関は,決済サーバコンピュータ40と勘定系ホストコンピュータ42とを備えている。決済サーバコンピュータ40は,ネットワーク20に接続しているが,勘定系ホストコンピュータ42はネットワーク20に接続していない。これは,勘定系ホストコンピュータ42は,実際の資金管理をするコンピュータであり,そのセキュリティーを確保する必要があるためである。また,勘定系ホストコンピュータ42に対して,ネットワーク20へ接続する機能を付加するのは,システム改造に多大なコストを要するため,汎用的なネットワークインターフェースを有する決済サーバコンピュータ40を用いてネットワーク20に接続して,この決済サーバコンピュータ40を勘定系ホストコンピュータ42に接続した方が,システム改造コストの低減が図れるためである。したがって,本実施形態においては,決済サーバコンピュータ40と勘定系ホストコンピュータ42とは,金融機関内の専用回線22で接続されている。
【0025】本実施形態においては,決済サーバコンピュータ40と勘定系ホストコンピュータ42は,異なる金融機関に設けられている。すなわち,決済サーバコンピュータ40は,クレジットカード会社に設けられており,勘定系ホストコンピュータ42は,銀行に設けられている。但し,これら決済サーバコンピュータ40と勘定系ホストコンピュータ42とは,1つの金融機関,例えば銀行内に,設けられてもよい。
【0026】決済サーバコンピュータ40は,顧客データベース44を備えている。この顧客データベース44は,この請求連動サービスに関する口座振替契約を締結した販売者と利用者に関する情報を保持している。この顧客データベース44は,例えば,これらの情報をハードディスクに格納することにより,構成されている。
【0027】次に,この図1に基づいて,本実施形態に係る資金処理システムの全体的処理の概要を説明する。例えば,利用者が損害保険会社の販売代理店である場合,販売代理店は,利用者端末30から販売者サーバコンピュータ10にアクセスして,最終的な消費者が加入した保険の内容を示す保険契約情報と,その保険内容に対して損害保険会社が受け取るべき保険料金に相当する決済指示を入力する。これら保険契約情報と決済指示とは,ネットワーク20を介して,損害保険会社の販売者サーバコンピュータ10で受信される。
【0028】この決済指示を受け取った損害保険会社の販売者サーバコンピュータ10は,決済指示に示されている金額についての決済要求を生成し,ネットワーク20を介して,金融機関の決済サーバコンピュータ40に送信する。決済サーバコンピュータ40では,受信した決済要求が顧客データベース44に登録されている利用者と販売者のものであるかどうかを確認する。この決済要求が,登録されている利用者と販売者のものである場合には,その決済要求を勘定系ホストコンピュータ42に送信する。
【0029】勘定系ホストコンピュータ42では,この決済要求に基づいて,引落口座からこの決済要求が示す金額を引き落とし,入金口座に入金する処理を行う。そして,引落処理が正常に行えたかどうかを示す結果通知を,決済サーバコンピュータ40に送信する。決済サーバコンピュータ40は,この結果通知を,ネットワーク20を介して,損害保険会社の販売者サーバコンピュータ10に送信する。これら一連の処理は,販売者サーバコンピュータ10,決済サーバコンピュータ40,及び,勘定系ホストコンピュータ42において,リアルタイムで実行される。ここでリアルタイムとは,バッチ処理ではないという意味であり,決済要求や結果通知等のデータを受信してから,その処理が実行されるまでの間に,ある程度の時間間隔が存在してもよいことを意味している。特に本実施形態においては,決済要求や結果通知等のデータを受信した場合には,これを各コンピュータが許容できる範囲で即時に処理することとしている。これにより,販売者である損害保険会社は,決済結果をリアルタイムで入手できるようになる。
【0030】次に,本実施形態に係る資金処理システムの処理内容を詳細に説明する。まず,図2に基づいて,販売者サーバコンピュータ10で行われる販売者サーバ決済要求送信処理について説明する。
【0031】図2に示すように,販売者サーバコンピュータ10は,利用者端末30からのログイン要求があった場合には,その利用者に利用者の認証を求め,利用者が入力した認証と,販売者サーバコンピュータ10に予め登録されている認証とが一致するかどうかを判断する(ステップS10)。本実施形態においては,この認証に,利用者IDとパスワードとを用いる。つまり,入力された利用者IDとパスワードとが,販売者サーバコンピュータ10に予め登録されている利用者IDとパスワードと,一致するかどうかを判断する。
【0032】両者が一致しなかった場合(ステップS10:Nｏ)には,ログインを認めず,このステップS10の処理を繰り返す。一方,両者が一致した場合(ステップS10:Yeｓ)には,ログインを認めた上で,商品の購入画面や,その購入した商品についての資金の決済の約定などを,利用者端末30に表示する(ステップS11)。販売者が損害保険会社である場合には,例えば,保険契約情報やその保険料金を表示し,利用者に必要な項目を選択させたり,入力させたりする。
【0033】次に,販売者サーバコンピュータ10は,利用者が商品を購入した場合には,利用者端末30に決済画面を表示して,利用者に決済指示を入力させ,これを受信する(ステップS12)。本実施形態においては,利用者は,利用者端末30から決済金額を入力し,これを販売者サーバコンピュータ10が受信する。但し,この際,利用者が引落口座を特定する情報も合わせて入力し,これを販売者サーバコンピュータ10が受信するようにしてもよい。
【0034】次に,販売者サーバコンピュータ10は,受信した決済指示に基づいて,決済要求を生成する(ステップS13)。図3は,本実施形態に係る決済要求のデータフォーマットを示す図である。この図3に示すように,決済要求は,データ項目として,トランザクションID T10と,販売者コードT11と,店番T12と,科目T13と,口座番号T14と,店番T15と,科目T16と,口座番号T17と,金額T18とを備えている。
【0035】トランザクションID T10は,決済要求を生成する毎に割り当てられるユニークな識別情報である。販売者コードT11は,金融機関が各販売者毎に割り付けるユニークな識別情報である。店番T12と科目T13と口座番号T14とにより,入金口座が特定される。つまり,引き落とされた資金が入金される販売者の口座が特定される。但し,この入金口座を特定するための情報は,顧客データベース44に各販売者毎に登録されているので,省略することも可能である。店番T15と科目T16と口座番号T17とにより,引落口座が特定される。つまり,入金処理をするための資金が引き落とされる利用者の口座が特定される。金額T18により,引落処理及び入金処理を行う金額が特定される。
【0036】利用者端末30から受信した決済指示には,代金としての金額に関する情報が含まれているので,この金額に基づいて,決済要求の金額T18が生成される。これ以外の項目は,販売者サーバコンピュータ10に予め登録されているので,販売者サーバコンピュータ10が生成して付加する。
【0037】次に,図2に示すように,販売者サーバコンピュータ10は,この生成した決済要求を,ネットワーク20を介して,決済サーバコンピュータ40に送信する(ステップS14)。そして,上述したステップS10の処理に戻る。
【0038】次に,図4に基づいて,決済サーバコンピュータ40で行われる決済サーバ決済要求送信処理を説明する。
【0039】まず,決済サーバコンピュータ40は,販売者サーバコンピュータ10から,決済要求を受信したかどうかを判断する(ステップS20)。決済要求を受信していない場合(ステップS20:Nｏ)には,このステップS20の処理を繰り返して待機する。
【0040】一方,決済要求を受信した場合(ステップS20:Yeｓ)には,その決済要求が,顧客データベース44に登録されている販売者から送信されたものであるかどうかを判断する(ステップS21)。
【0041】図5は,本実施形態に係る顧客データベース44の構成を示す図である。この図5に示すように,顧客データベース44は,項目として,販売者コードT20と,販売者名T21と,店番T22と,科目T23と,口座番号T24と,利用者ID T25と,利用者名T26と,店番T27と,科目T28と,口座番号T29とを備えている。
【0042】販売者コードT20は,各販売者毎に割り当てるユニークな識別情報であり,図3に示した決済要求の販売者コードT11に対応する。販売者名T21は,その販売者の名称を示している。店番T22と科目T23と口座番号T24とにより,販売者の入金口座が特定されるが,これらは図3に示した決済要求の店番T12と科目T13と口座番号T14とに,それぞれ,対応している。
【0043】利用者ID T25は,利用者毎に且つ引落口座毎に割り当てられたユニークな識別情報である。利用者名T26は,利用者の氏名や名称であり,引落口座の名義に対応している。店番T27と科目T28と口座番号T29とにより,引落口座が特定されるが,これらは図3に示した決済要求の店番T15と科目T16と口座番号T17とに,それぞれ,対応している。
【0044】この顧客データベース44は,利用者と販売者と金融機関との三者との間で,請求連動サービスに関する口座振替契約が締結された時点で,金融機関側で入力するデータである。図5からも分かるように,本実施形態においては,引落口座毎に1つのレコードが形成される。このため,1人の利用者に対して,つまり,同じ利用者IDに対して,複数のレコードが形成される場合もある。
【0045】上述した図4のステップS21においては,受信した決済要求に含まれている販売者コードT11が,顧客データベース44の販売者コードT20に登録されているかどうかを判断する。販売者コードT11が顧客データベース44に登録されている場合(ステップS21:Yeｓ)には,決済サーバコンピュータ40は,受信した決済要求に含まれている引落口座が,その販売者に対する利用者の引落口座として,顧客データベース44に登録されているかどうかを判断する(ステップS22)。具体的には,図3に示す決済要求の店番T15と科目T16と口座番号T17とにより特定される引落口座が,図5に示す顧客データベース44において,その販売者に対応する利用者の店番T27と科目T28と口座番号T29とにより特定される引落口座として,登録されているかどうかを判断する。
【0046】決済要求に含まれる引落口座が,その販売者に対応する引落口座として登録されている場合(ステップS22:Yeｓ)には,決済サーバコンピュータ40は,その決済要求を勘定系ホストコンピュータ42に送信する(ステップS23)。この決済要求のデータフォーマットは,図3に示す構造と同様である。そして,上述したステップS20の処理に戻る。
【0047】一方,上述したステップS21で,決済要求に含まれている販売者コードT11が,顧客データベース44に登録されていないと判断した場合(ステップS21:Nｏ),又は,上述したステップS22で,決済要求に含まれている引落口座が,その販売者に対応する利用者の引落口座として登録されていないと判断した場合(ステップS22:Nｏ)には,この請求連動サービスに未登録である旨の結果通知を,販売者サーバコンピュータ10に送信する(ステップS24)。そして,上述したステップS20の処理に戻る。
【0048】次に,図6に基づいて,勘定系ホストコンピュータ42で行われる勘定系ホスト処理について説明する。
【0049】まず,勘定系ホストコンピュータ42は,決済サーバコンピュータ40から,決済要求を受信したかどうかを判断する(ステップS30)。決済要求を受信していない場合(ステップS30:Nｏ)には,このステップS30の処理を繰り返して待機する。
【0050】決済要求を受信した場合(ステップS30:Yeｓ)には,決済要求に含まれている引落口座から,指定された金額を引き落とすための処理を行い,この引き落としができたかどうかを判断する(ステップS31)。具体的には,図3に示す決済要求の店番T15と科目T16と口座番号T17とで特定される引落口座から,金額T18で特定される金額を引き落とす処理を行う。この際,例えば,引落口座の残高が,金額T18よりも少ないと,引き落としはできないこととなる。また,引落口座が解約されてしまっているような場合にも,引き落としはできないこととなる。
【0051】引落口座から金額T18の引き落としができた場合(ステップS31:Yeｓ)には,その引き落とした金額T18を,入金口座に入金する(ステップS32)。具体的には,図3に示す決済要求の店番T12と科目T13と口座番号T14とで特定される入金口座に,金額T18で特定される金額を入金する。本実施形態においては,この入金口座への実際の入金は,金融機関の翌営業日に行われるようになっているが,リアルタイムで行うようにしてもよい。
【0052】次に,勘定系ホストコンピュータ42は,決済サーバコンピュータ40に,正常に引落処理ができた旨の結果通知を送信する(ステップS33)。この結果通知は,リアルタイムに送信する。図7は,本実施形態に係る結果通知のデータフォーマットを示す図である。この図7に示すように,本実施形態に係る結果通知は,トランザクションID T40と,処理結果T41と,エラー情報T42とを備えている。トランザクションID T40は,勘定系ホストコンピュータ42が受信した決済要求に含まれているトランザクションID T10に対応する項目であり,受信した決済要求と同じトランザクションIDが格納される。処理結果T41は,引落処理が正常に行えたかどうかを示す情報である。エラー情報T42は,引落処理が正常に行えなかった場合における,そのエラー原因を示す情報である。図6のステップS33では,引落処理が正常に行えたので,処理結果T41には,正常に引落処理が行われた旨の情報が格納されている。この結果通知を送信した後,勘定系ホストコンピュータ42は,上述したステップS30の処理に戻る。
【0053】一方,上述したステップS31において,引落口座からの引落処理ができなかった場合(ステップS31:Nｏ)には,勘定系ホストコンピュータ42は,決済サーバコンピュータ40に,引落処理ができなかった旨の結果通知を送信する(ステップS34)。つまり,図7に示す結果通知において,処理結果T41には,正常に引落処理ができなかったことを示す情報が格納され,エラー情報T42には,そのエラー原因を示す情報が格納された処理結果を,決済サーバコンピュータ40に送信する。そして,上述したステップS30の処理に戻る。
【0054】次に,図8に基づいて,本実施形態に係る決済サーバコンピュータ40で行われる決済サーバ結果通知送信処理について説明する。
【0055】図8に示すように,決済サーバコンピュータ40は,まず,勘定系ホストコンピュータ42から,結果通知を受信したかどうかを判断する(ステップS40)。この結果通知は,上述した図6のステップS33
及びステップS34で,送信されたものである。結果通知を受信していない場合(ステップS40:Nｏ)には,このステップS40の処理を繰り返して待機する。
【0056】一方,結果通知を受信した場合(ステップS40:Yeｓ)には,その結果通知を,販売者サーバコンピュータ10にネットワーク20を介して送信する(ステップS41)。そして,上述したステップS40の処理に戻る。
【0057】次に,図9に基づいて,販売者サーバコンピュータ10で行われる販売者サーバ結果通知受信処理について説明する。
【0058】図9に示すように,まず,販売者サーバコンピュータ10は,決済サーバコンピュータ40から結果通知を受信したかどうかを判断する(ステップS50)。結果通知を受信していない場合(ステップS50:Nｏ)には,このステップS50の処理を繰り返して待機する。一方,結果通知を受信した場合(ステップS50:Yeｓ)には,販売者サーバコンピュータ10は,この結果通知の内容をその一覧リストに追加して出力するとともに,その結果通知が,引落処理が正常に行われたことを示しているかどうかを判断する(ステップS51)。具体的には,図7に示す結果通知の処理結果T41が,引落処理を正常に行ったことを示しているかどうかを判断する。
【0059】決済処理が正常に行われたことを,通知結果が示している場合(ステップS51:Yeｓ)には,上述したステップS50の処理に戻る。これにより,販売者にとっては,利用者に販売した商品の代金に関する決済処理は完結したことになる。
【0060】一方,決済処理が正常に行われなかったことを,通知結果が示している場合(ステップS51:Nｏ)には,再度,金融機関に振替処理を依頼すべく,図2に示す販売者サーバ決済要求送信処理のステップS13からを再度実行させる。但し,このステップS13からを再度実行させるタイミングは,一定期間経過後である。例えば,1日経過後,3日経過後などである。なぜなら,残高不足で引落口座から必要な資金の引落ができなかった場合には,利用者はまだ引落口座に代金を入金していないのであるから,利用者が引落口座に代金を入金した頃を見計らって再度実行するのが望ましいからである。そして,販売者サーバコンピュータ10は,上述したステップS50の処理に戻る。
【0061】なお,ステップS51及びステップS52の処理は,必ずしも必要なものではなく,省略することも可能である。この場合,販売者サーバコンピュータ10の管理者は,決済サーバコンピュータ40から受信した結果通知を一覧リストの形式で出力し,人間の手作業で引落処理が正常に行われなかった利用者に対してのみ,再度,決済要求を販売者サーバコンピュータ10に入力して再度の振替処理を試みるようにしてもよい。
【0062】以上のように,本実施形態に係る資金処理システムによれば,決済サーバコンピュータ40は,販売者サーバコンピュータ10から決済要求を受信した時点で,勘定系ホストコンピュータ42に決済の処理を要求するようにしたので,販売者にとっては,利用者のアクションに依存しない形で資金を確保することができる。このため,商品販売代金を効率的に精算できるようになる。しかも,販売者は,販売者サーバコンピュータ10が出力した結果通知により,商品を販売した後すぐに決済結果をリアルタイムで金融機関から取得することができる。このため,販売管理の効率化を図ることができる。
【0063】また,引落口座の残高不足等の理由により,引落口座から入金口座への資金の振り替えができなかった場合でも,販売者が主導権を持って再度の決済要求を送信できる。このため,未回収代金の効率的な精算を実現することができる。
【0064】一方,利用者にとっても,ネットデビットのIDとパスワードを入力する手間が省けるので,簡単に購入代金の精算をすることができる。
【0065】さらに,販売者サーバコンピュータ10と決済サーバコンピュータ40との間の通信は,既存のネットデビットのインターフェースを利用することができるので,販売者は安全な決済情報の受け渡しを安価に実現することができる。
【0066】〔第2実施形態〕本発明の第2実施形態は,上述した第1実施形態に係る資金処理システムにおいて,顧客データベース44の構造を変形したものである。
【0067】図10は,本実施形態に係る販売者テーブルTBL10の構成を示す図であり,図11は,利用者テーブルTBL20の構成を示す図である。すなわち,本実施形態においては,顧客データベース44を,各販売者毎に1つのレコードを形成した販売者テーブルTBL10と,各利用者毎に1つのレコードを形成した利用者テーブルTBL20とに分けて構成している。販売者テーブルTBL10と利用者テーブルTBL20との関連づけは,販売者コードT20を用いて行う。
【0068】本実施形態における資金処理システムでは,上述した図4の決済サーバ決済要求送信処理のステップS21において,販売者が顧客データベース44に登録されているかどうかを,販売者テーブルTBL10に基づいて判断することになる。また,ステップS22において,利用者の引落口座が,決済要求を送信した販売者に対する引落口座として,顧客データベース44に登録されているかどうかを,利用者テーブルTBL20に基づいて判断することになる。
【0069】それ以外の点は,本実施形態に係る資金処理システムは,上述した第1実施形態と同様の処理となり,同様の効果を得ることができる。
【0070】〔第3実施形態〕本発明の第3実施形態は,上述した第1実施形態及び第2実施形態に係る資金処理システムにおいて,販売者サーバコンピュータ10と決済サーバコンピュータ40との間も,専用回線で接続するようにしたものである。
【0071】図12は,本実施形態に係る資金処理システムの構成を示すブロック図であり,上述した図1に対応している。この図12に示すように,本実施形態においては,決済サーバコンピュータ40と勘定系ホストコンピュータ42との間と同様に,販売者サーバコンピュータ10と決済サーバコンピュータ40との間も,特定の者しかアクセスできない専用回線24で接続されている。本実施形態においては,これら販売者サーバコンピュータ10と決済サーバコンピュータ40との間の通信は,既存のクレジット決済等のインターフェースを利用している。これにより,販売者は新たな通信回線に加入することなく,販売者サーバコンピュータ10と決済サーバコンピュータ40との間の通信を,不特定多数の者がアクセスできるネットワーク20を介さずに,行うことができるようになる。その結果,この資金処理システムのセキュリティをより向上させることができる。
【0072】これ以外の点については,本実施形態に係る資金処理システムは,上述した第1実施形態又は第2実施形態と同様の処理となり,同様の効果を得ることができる。
【0073】なお,本発明は上記実施形態に限定されず種々に変形可能である。例えば,上述した実施形態においては,販売者が損害保険会社であり,利用者が販売代理店である場合を例に説明したが,販売者及び利用者はこの組み合わせに限るものではない。販売者がフランチャイザーであり,利用者がフランチャイジーであるようなフランチャイズシステムに対して,本発明を適用し,商品代金の精算をすることもできる。さらには,公共料金や税金等の精算や,保険会社,証券会社の預かり金口座への資金入金手段にも適用することができる。
【0074】また,販売者が扱う商品は,保険商品などの無形の商品でなく,物品等の有形の商品であってもよい。また,利用者と販売者との間の決済は,必ずしも継続的に行われるものでなくてもよい。つまり,ある1の者と他の1の者との間で発生する資金の決済に対して,本発明は適用することができる。
【0075】さらに,上述した実施形態においては,決済サーバコンピュータ40は,図3に示す決済要求の引落口座に基づいて,その決済要求が顧客データベース44に登録されている利用者に関するものであるかどうかを判断したが,利用者IDに基づいて判断するようにしてもよい。この場合,1つの利用者IDに対して1つの引落口座が割り当てられるようにしておく必要があるが,決済要求から引落口座を特定する情報を省くことができる。
【0076】また,上述した実施形態においては,決済サーバコンピュータ40と勘定系ホストコンピュータ42とを別々のコンピュータシステムで構成したが,これらをまとめて1つのコンピュータシステムで構成してもよい。この場合,専用回線22は不要になる。
【0077】また,上述の実施形態で説明した各処理については,これら各処理を実行するためのプログラムをフロッピーディスク,CD-ROM(Compact Disc-Read Only Memory),ROM,メモリカード等の記録媒体に記録して,記録媒体の形で頒布することが可能である。この場合,このプログラムが記録された記録媒体を販売者サーバコンピュータ10や決済サーバコンピュータ40,勘定系ホストコンピュータ42に読み込ませ,実行させることにより,上述した実施形態を実現することができる。
【0078】また,販売者サーバコンピュータ10や決済サーバコンピュータ40,勘定系ホストコンピュータ42は,オペレーティングシステムや別のアプリケーションプログラム等の他のプログラムを備える場合がある。この場合,これらコンピュータの備える他のプログラムを活用し,記録媒体にはこれらのコンピュータが備えるプログラムの中から,上述した実施形態と同等の処理を実現するプログラムを呼び出すような命令を記録するようにしてもよい。
【0079】さらに,このようなプログラムは,記録媒体の形ではなく,ネットワークを通じて搬送波として頒布することも可能である。ネットワーク上を搬送波の形で伝送されたプログラムは,販売者サーバコンピュータ10や決済サーバコンピュータ40,勘定系ホストコンピュータ42に取り込まれて,このプログラムを実行することにより上述した実施形態を実現することができる。
【0080】また,記録媒体にプログラムを記録する際や,ネットワーク上を搬送波として伝送される際に,プログラムの暗号化や圧縮化がなされている場合がある。この場合には,これら記録媒体や搬送波からプログラムを読み込んだこれらのコンピュータは,そのプログラムの復号化や伸張化を行った上で,実行する必要がある。」

(引用例3)特開2001-134679号公報(平成13年5月18日出願公開)には,図面と共に,以下の事項が記載されている。
(E)【0009】?【0023】段落
「【0009】
【発明の実施の形態】以下,本発明に係わる口座振替契約システムの実施の形態を図面を参照して説明する。
【0010】本実施形態の口座振替契約システムのシステム構成図を図1に示す。
【0011】本システムは,チャネル1と,銀行ホスト3と,企業ホスト5を備える。銀行ホスト3と企業ホスト5とは例えば公衆回線4を介して接続されている。
【0012】チャネル1は,銀行が顧客からの口座振替契約の申込を受付けるための通信手段であり,例えば,電話7,店頭端末9,およびインターネットワーク等のネットワーク13を介して銀行ホスト3と通信可能な通信端末11を含む。
【0013】銀行ホスト3は,口座振替契約の申込に関する情報を,顧客からの電話7,店頭に設置された店頭端末9,あるいはネットワーク13を介して通信端末11,から受付けるコンピュータである。
【0014】銀行ホスト3は,顧客からの口座振替契約の申込に関する情報に基づいて,口座実在チェック,本人確認チェック,口座振替契約の対象企業のチェック等を行ない,口座振替契約意志確認情報データとして記憶するとともに,口座振替契約受付けデータを作成し,対象企業のホスト5に伝送する。企業ホスト5は,口座振替契約受付けデータに基づいて顧客の実在を確認し,契約可否を判定する。企業は契約可と判断したデータを口座振替契約依頼データとして銀行ホスト3に伝送する。銀行ホスト3は企業ホスト5から伝送された口座振替契約依頼データと,記憶されている口座振替契約意志確認情報データとを照合し,合致したデータを対象に口座振替契約処理を行う。
【0015】以下,図2乃至図11を参照して,口座振替契約の処理について詳述する。
【0016】図2および図3は,顧客が銀行に口座振替契約を電話で申し込む場合の処理を示すフローチャートである。
【0017】図2において,顧客は電話により口座振替契約を銀行に申し込む。この際,顧客は銀行取引き情報を電話で銀行に伝える(S1)。この銀行取引き情報は,口座振替契約を行う,店番,科目,口座番号を含む。銀行ホスト3は口座振替契約を行う「店番」「科目」「口座番号」を図4に示す顧客マスタ21と突合し,口座の実在チェックを行う(S3)。顧客マスタは,図4に示すように「店番」「科目」「口座番号」「キャッシュカード暗証番号」「口座振替契約可能フラッグ」等の情報から構成される。口座が実在しない場合には,その旨のエラーメッセージを顧客に電話で伝える。口座が実在する場合には,顧客はキャッシュカードの暗証番号を電話で銀行に伝える(S5)。銀行ホスト3は,顧客から入力されたキャッシュカードの暗証番号を図4に示す顧客マスタ21と照合し,本人確認を行う(S7)。暗証番号チェックの結果不一致であれば,その旨のエラーメッセージを顧客に電話で伝える。暗証番号チェックの結果一致が取れれば,次に,銀行は顧客から口座振替企業に関する情報を入力する(S9)。銀行ホスト3は,入力された口座振替企業を口座振替契約の企業として受付けてよいか否かを図5に示す口座振替企業マスタ23を参照してチェックする(S11)。口座振替企業マスタ23は,図5に示すように「委託者コード」「委託者名」「受付けチャネル別契約可否フラッグ」「入金口座情報」「手数料徴求情報」等から構成される。
【0018】次に,銀行ホスト3は,口座振替企業が必要とする情報(例えば契約者Nｏ,契約名義人等)を企業に代理して顧客から聞き取る(他のチャネルの場合には,顧客に入力させる)(S13)。この際,銀行ホスト3は企業別必要情報マスタ24を参照して企業毎に必要な情報をチェックする。銀行ホスト3は,聞き取ったもしくは入力させた口座振替企業が必要とする情報を図6に示す口座振替契約意志確認情報データ25として蓄える(S15)。口座振替契約意志確認情報データ25は,図6に示すように「店番」「科目」「口座番号」「意志確認受付け日付」「契約名義人」等から構成される。次に,銀行ホスト3は,蓄えられた口座振替契約意志確認情報データ25を,受付時間を条件として(例えば,受付日単位(0時から翌日の0時まで)抽出し,図8および図9に示す口座振替契約受付けデータ27を作成し,EB(Electronic Banking)システムに蓄積する(S17)。口座振替契約受付けデータ27は図8および9に示すように,ヘッダ部が「申込受付日」「入金口座情報」等から構成され,データ部が「データ区分」「口座振替契約依頼口座情報」「契約者No」「受付けチャネル情報」「結果コード」等から構成される。なお,口座振替契約依頼データ,口座振替契約結果データについても,口座契約受付けデータと同様のデータ構成である。
【0019】一方,企業ホスト5は,銀行のEBシステムから口座振替契約受付データを取り込み,口座契約受付けファイル29に蓄積する(S19)。企業ホスト5は,図9に示す口座振替契約受付けデータ中の契約名義人(預金者名),契約者Nｏを図11に示す請求マスタ31と照合し,当該顧客の実在を確認し,契約可否を判定する(S21)。請求マスタ31は図11に示すように,「契約者Nｏ」「契約名義人」「口座振替情報」等から構成される。次に,企業ホスト5は契約可と判断されたデータを,図8および図10に示す口座振替契約依頼データの形式に変換し,このデータを銀行のEBシステムに伝送する(S23)。
【0020】銀行ホスト3は,企業ホスト5から伝送された口座振替契約依頼データ33と口座振替契約意志確認情報データ25を照合し,合致したデータを対象に口座振替契約処理を行う(S25)。具体的には,口座振替契約依頼データ33を基に図7に示すような口座振替契約マスタ27を更新する。銀行ホスト3は図10に示すような口座振替依頼データ33の結果コードフィールドに,契約ができたか否かの情報を書き込み,口座振替契約結果データ35としてEBシステムに蓄積する。
【0021】企業ホスト5はEBシステムから口座振替契約結果データ35を取り込み,結果コードを判定して,図11に示すような企業ホスト5の請求マスタ31に口座振替契約情報を追加・更新する。
【0022】なお,この発明は上記実施の形態に限定されるものではない。例えば,上記実施の形態では,顧客からの電話による口座振替契約の申込を銀行のコールセンタが受付けた場合の処理を示したが,顧客が自己の端末からインターネットを介して,あるいは顧客が銀行の店頭に出向き,店頭端末から口座振替契約をそれぞれ申し込む場合にも同様の処理により口座振替契約を自動的に行うことができる。
【0023】
【発明の効果】この発明によれば,銀行が直接利用者から口座振替契約に必要な利用者の口座情報や企業が必要とする情報を電話,インターネットもしくは店頭端末を介して収集し,口座振替契約のために必要な情報を電子化し,この電子化されたデータを用いて口座振替契約を自動的に処理する公正としたので,完全なペーパレス化による事務の効率化を図れるとともに,銀行,企業,契約者のコストダウンが図れる。さらに,口座振替契約に必要な日数を短縮することができる。また,受付け時に口座の実在をチェックすることにより,口座情報の正確性が向上し,エラーを削減することができる。また,本人確認は,電話,インターネット,店頭端末等の各受付けチャネルで実施されるので,従来技術において起こり得る銀行取引印の相違によるエラーを撲滅することができる。」

(3)対比
請求項1に係る発明と引用例1記載の発明を対比すると,引用例1記載の発明の「顧客端末」,「インターネットバンキング(IB)を開設している銀行サイト」,「口座振替申込み手続」,「口座振替の申込みのための顧客情報」,「サービス提供者サイト」,「顧客(契約者)」は,それぞれ請求項1に係る発明の「利用者端末」,「IBウェブサイト」,「口座振替契約手続」,「口座振替契約申込み情報」,「収納企業ウェブサイト」,「利用者」に対応する。
また,上記摘記事項(B)に記載されるように,引用例1記載の「サービス提供者(収納業者)コードを含む管理情報」は,サービス提供者に新規契約の申込みを行うに際し、顧客がサービス提供者を介して口座振替を申込む場合に,銀行システムに引き継がれる「サービス提供者を特定するためのコードである」から,「口座振替に係る」ものであるといえ,一方,請求項1に係る発明の「口座振替契約に係る収納企業情報」は,明細書の【0042】,【0046】段落の記載を参照すると,「口座振替契約に係る収納企業情報は、例えば、企業名称、サービス名称、若しくはこれらをコード化したもの等である」ことから,引用例1記載の発明の「サービス提供者コードを含む管理情報」は,請求項1に係る発明の「口座振替契約に係る収納企業情報」に対応する。
さらに,引用例1記載の発明の「銀行システムのサーバ」と請求項1に係る発明の「IBサーバ」は,「IB用のWebサーバ」で共通している。
これらのことから,
引用例1記載の発明の「顧客端末との間で情報伝送するためのインターネットバンキング(IB)を開設している銀行サイトを構築管理する銀行システムにより口座振替申込み手続を行う」と,請求項1に係る発明の「利用者端末との間で情報伝送するためのIBウェブサイトを構築管理しかつ銀行ホストとの間で情報伝送するIBサーバにより口座振替契約手続きを行う」は,「利用者端末との間で情報伝送するためのIBウェブサイトを構築管理するIB用のWebサーバにより口座振替契約手続きを行う」で共通し,
引用例1記載の発明の「前記顧客端末が口座振替の申込みのための顧客情報を入力及び送信したサービス提供者サイトから前記インターネットバンキング(IB)を開設している銀行サイトへと接続を移行する際に該口座振替の申込みのための顧客情報及び口座振替に係るサービス提供者(収納業者)コードを含む管理情報を引き継ぐステップ」は,請求項1に係る発明の「前記利用者端末が口座振替契約申込み情報を入力及び送信した収納企業ウェブサイトから前記IBウェブサイトへと接続を移行する際に該口座振替契約申込み情報及び口座振替契約に係る収納企業情報を引き継ぐステップ」に対応し,
引用例1記載の発明の「予め記憶された顧客(契約者)の口座情報及び本人認証情報(契約番号,パスワードおよび確認番号)と,前記引き継いだ口座振替申込みのための顧客情報に含まれる口座情報及び本人認証情報(契約番号,パスワードおよび確認番号)とを照合することにより本人認証処理を行うステップ」と,請求項1に係る発明の「予め記憶された利用者の口座情報及び認証情報と,前記引き継いだ口座振替契約申込み情報に含まれる口座情報及び第1認証情報,並びに利用者端末からさらに入力されて送信される第2認証情報とを照合することにより利用者認証処理を行うステップ」は,「予め記憶された利用者の口座情報及び認証情報と,前記引き継いだ口座振替申込み情報に含まれる口座情報及び認証情報とを照合することにより利用者認証処理を行うステップ」に対応しているものと認められる。
そして,引用例1記載の発明の「口座振替申込み手続方法」は,請求項1に係る発明の「口座振替契約方法」と,以下の相違点で相違するものの,「口座振替契約方法」で共通していると認められる。
してみれば,請求項1に係る発明と引用例1記載の発明は,
「利用者端末との間で情報伝送するためのIBウェブサイトを構築管理するIB用のWebサーバにより口座振替契約手続きを行う口座振替契約方法において,前記IB用のWebサーバが,
前記利用者端末が口座振替契約申込み情報を入力及び送信した収納企業ウェブサイトから前記IBウェブサイトへと接続を移行する際に該口座振替契約申込み情報及び口座振替契約に係る収納企業情報を引き継ぐステップと,
予め記憶された利用者の口座情報及び認証情報と,前記引き継いだ口座振替申込み情報に含まれる口座情報及び認証情報とを照合することにより利用者認証処理を行うステップと,
を有する口座振替契約方法」
である点で一致し,以下の点で相違するものと認められる。

(相違点1)
「IB用のWebサーバ」が,請求項1に係る発明では,「銀行ホストとの間で情報伝送する」ものであるのに対して,引用例1記載の発明では,「銀行ホストとの間で情報伝送する」ものではない点。

(相違点2)
請求項1に係る発明の「IB用のWebサーバ」が「予め記憶された収納企業情報と前記引き継いだ口座振替契約に係る収納企業情報とを照合することにより収納企業認証処理を行うステップ」を有する口座振替契約方法を実行するのに対して,引用例1記載の発明の「IB用のWebサーバ」がこのような収納企業認証処理を行うステップを有する口座振替契約方法を実行しない点。

(相違点3)
請求項1に係る発明の「IB用のWebサーバ」が「前記口座振替契約申込み情報及び前記口座振替契約に係る収納企業情報から抽出した情報に基づいて本登録用データを作成するステップ」と,「前記作成された本登録用データを本登録処理のために前記銀行ホストへ送信しさらに該銀行ホストから該本登録処理の可否の結果データを受信するステップ」と,「前記本登録の可否の結果データの受信に応じて契約結果ファイルを作成するステップ」と,「前記契約結果ファイルの内容を前記収納企業ウェブサイトを構築管理する収納企業ホストへ送信するステップ」とを有する口座振替契約方法を実行するのに対して,引用例1記載の発明の「IB用のWebサーバ」がこのような一連のステップを有する口座振替契約方法を実行しない点。

(相違点4)
請求項1に係る発明の「認証情報」が,「引き継いだ口座振替契約申込み情報に含まれる第1認証情報」,並びに「利用者端末からさらに入力されて送信される第2認証情報」であるのに対して,引用例1記載の発明の「認証情報」が,「本人認証情報(契約番号,パスワードおよび確認番号)」である点。

(4)相違点についての当審の判断
上記相違点について検討すると,
(相違点1についての判断)
引用例2の摘記事項(D)の【0024】段落には,「金融機関は,決済サーバコンピュータ40と勘定系ホストコンピュータ42とを備えている。・・・汎用的なネットワークインターフェースを有する決済サーバコンピュータ40を用いてネットワーク20に接続して,この決済サーバコンピュータ40を勘定系ホストコンピュータ42に接続・・・したがって,本実施形態においては,決済サーバコンピュータ40と勘定系ホストコンピュータ42とは,金融機関内の専用回線22で接続されている。」との記載があり,更に,【0076】段落には,「また,上述した実施形態においては,決済サーバコンピュータ40と勘定系ホストコンピュータ42とを別々のコンピュータシステムで構成したが,これらをまとめて1つのコンピュータシステムで構成してもよい。この場合,専用回線22は不要になる。」との記載があり,また,上記引用例1の摘記事項(A)の【0016】段落には,「・・・サーバ2は,図1に示したように単一のサーバであっても,Webサーバや管理サーバ等を含む複数のサーバがLANによって結ばれた形態であってもよい。・・・」との記載があることから,上記引用例2に記載されるような,汎用的なネットワークインターフェースを有するサーバコンピュータと勘定系ホストコンピュータとを金融機関内の専用回線で接続して,情報伝達するようにした金融機関のコンピュータシステムの構成を,引用例1記載の発明に採用して,引用例1記載の発明の「IB用のWebサーバ」を「銀行ホストとの間で情報伝送する」ようにすることは,当業者が容易に成し得たものと認められる。
したがって,上記相違点1に係る請求項1に係る発明の構成は,引用例1記載の発明及び引用例1,2に記載された事項に基づいて,当業者が容易に想到し得たものと認められる。

(相違点2についての判断)
引用例3の摘記事項(E)の【0014】段落には,「銀行ホスト3は,顧客からの口座振替契約の申込に関する情報に基づいて,口座実在チェック,本人確認チェック,口座振替契約の対象企業のチェック等を行ない,口座振替契約意志確認情報データとして記憶するとともに,口座振替契約受付けデータを作成し,対象企業のホスト5に伝送する。」との記載があり,【0017】段落には,「・・・銀行ホスト3は,入力された口座振替企業を口座振替契約の企業として受付けてよいか否かを図5に示す口座振替企業マスタ23を参照してチェックする(S11)。口座振替企業マスタ23は,図5に示すように「委託者コード」「委託者名」「受付けチャネル別契約可否フラッグ」「入金口座情報」「手数料徴求情報」等から構成される。」との記載があり,このような口座振替契約の対象企業のチェックする処理を引用例1記載の発明に採用して,「IB用のWebサーバ」が「予め記憶された収納企業情報と前記引き継いだ口座振替契約に係る収納企業情報とを照合することにより収納企業認証処理を行うステップ」を有する口座振替契約方法を実行するようにすることは,当業者が容易に成し得たものと認められる。
したがって,上記相違点2に係る請求項1に係る発明の構成は,引用例1記載の発明及び引用例3に記載された事項に基づいて,当業者が容易に想到し得たものと認められる。

(相違点3についての判断)
引用例3の摘記事項(E)の【0018】?【0020】段落には,「・・・銀行ホスト3は,・・・図8および図9に示す口座振替契約受付けデータ27を作成し,EB(Electronic Banking)システムに蓄積する(S17)。口座振替契約受付けデータ27は図8および9に示すように,ヘッダ部が「申込受付日」「入金口座情報」等から構成され,データ部が「データ区分」「口座振替契約依頼口座情報」「契約者No」「受付けチャネル情報」「結果コード」等から構成される。・・・銀行ホスト3は,企業ホスト5から伝送された口座振替契約依頼データ33と口座振替契約意志確認情報データ25を照合し,合致したデータを対象に口座振替契約処理を行う(S25)。具体的には,口座振替契約依頼データ33を基に図7に示すような口座振替契約マスタ27を更新する。銀行ホスト3は図10に示すような口座振替依頼データ33の結果コードフィールドに,契約ができたか否かの情報を書き込み,口座振替契約結果データ35としてEBシステムに蓄積する。」との記載があり,【0021】段落には,「企業ホスト5はEBシステムから口座振替契約結果データ35を取り込み,結果コードを判定して,図11に示すような企業ホスト5の請求マスタ31に口座振替契約情報を追加・更新する。」との記載があり,システム構成に適合させて,上記銀行ホストが実行する口座振替契約に関する処理を,銀行ホストに接続されるサーバで実行するようにすることは,通常行われる設計変更の範囲内であり,格別の困難性は認められない。また,「口座振替契約依頼データ」を基に「口座振替契約マスタ」を更新するに際して,「口座振替契約依頼データ」に基づいて,「口座振替契約マスタ」に準じた形式及びデータ構造とする更新用データを作成し,当該更新用データで「口座振替契約マスタ」を更新することは,マスタファイルの更新処理として周知技術である。
してみれば,上記銀行ホストが実行する口座振替契約に関する処理を適用して,引用例1記載の発明の「IB用のWebサーバ」が,「前記口座振替契約申込み情報及び前記口座振替契約に係る収納企業情報から抽出した情報に基づいて本登録用データを作成するステップ」と,「前記作成された本登録用データを本登録処理のために前記銀行ホストへ送信しさらに該銀行ホストから該本登録処理の可否の結果データを受信するステップ」と,「前記本登録の可否の結果データの受信に応じて契約結果ファイルを作成するステップ」と,「前記契約結果ファイルの内容を前記収納企業ウェブサイトを構築管理する収納企業ホストへ送信するステップ」とを有する口座振替契約方法を実行するようにすることは,当業者が容易に成し得たものと認められる。
したがって,上記相違点3に係る請求項1に係る発明の構成は,引用例1記載の発明及び引用例3に記載された事項に基づいて,当業者が容易に想到し得たものと認められる。

(相違点4についての判断)
引用例1の摘記事項(B)の【0029】?【0031】段落に記載された内容からみて,図6に示される口座振替に関する入力内容確認画面は,その上欄に,引継データにより情報が反映された入力項目を含む口座振替の入力フォーム(図5)で入力された顧客情報(顧客の氏名,住所など)が表示されており,顧客端末の表示装置に表示された入力内容確認画面上で,下欄に本人認証のための情報(テレホンバンキングの契約番号,パスワードおよび確認番号)を入力し,上記顧客情報及び本人認証情報が銀行システムのサーバに送信され,当該情報と既取引の顧客データとをサーバで照合を行うことにより,本人認証と口座確認を行っているものと認められる。
このことからみて,引用例1記載の発明において,本人認証と口座確認を行うために「予め記憶された利用者の口座情報及び認証情報」と照合する情報を,「引き継いだ口座振替契約申込み情報に含まれる第1認証情報」並びに「利用者端末からさらに入力されて送信される第2認証情報」とすることに,格別の困難性は認められない。
したがって,上記相違点4に係る請求項1に係る発明の構成は,引用例1記載の発明及び引用例1に記載された事項に基づいて,当業者が容易に想到し得たものと認められる。

そして,請求項1に係る発明の作用効果も,引用例1-3から当業者が予測できる範囲のものである。

よって,請求項1に係る発明は,引用例1記載の発明及び引用例1-3の記載事項に基づいて,当業者が容易に発明をすることができたものと認められる。

(5)意見書のおける審判請求人の主張について
審判請求人は,平成20年7月23日付け意見書の「(3-2)「理由2」に指摘される請求項1について」において,以下の主張をしている。
(1) 拒絶理由通知書に記載の「引用例1記載の発明と請求項1に係る発明とが一致する点」に対する主張
審判請求人は,「本発明の請求項1は、「口座振替契約に係る収納企業情報を引き継ぐステップ」が記載されているのに対し、引用例1は、「サービス提供者を特定するためのコード」としての「サービス提供者コード」のみが記載されているため、この点で、引用例1と異なるものである。」と主張している。
しかしながら,上記摘記事項(B)に記載されるように,引用例1記載の「サービス提供者(収納業者)コードを含む管理情報」は,サービス提供者に新規契約の申込みを行うに際し、顧客がサービス提供者を介して口座振替を申込む場合に,銀行システムに引き継がれる「サービス提供者を特定するためのコードである」から,「口座振替に係る」ものであるといえ,一方,請求項1に係る発明の「口座振替契約に係る収納企業情報」は,本願明細書の【0042】,【0046】段落の記載を参照すると,「口座振替契約に係る収納企業情報は、例えば、企業名称、サービス名称、若しくはこれらをコード化したもの等である」ことから,引用例1記載の発明の「サービス提供者コードを含む管理情報」は,請求項1に係る発明の「口座振替契約に係る収納企業情報」に対応するものである。
よって,審判請求人の上記主張は失当である。

(2) 拒絶理由通知書の「(相違点2についての判断)」に対する主張
審判請求人は,「引用例1には、「収納企業認証処理」が記載されず、引用例3には、「企業ウェブサイトから企業情報を引き継ぐ」処理が記載されず、従って、引用例1と3にはいずれにも前述の「収納企業認証処理」と「企業ウェブサイトから収納企業情報を引き継ぐ」処理との組み合わせは記載されておらず、又、示唆されてもいないため、この組み合わせがないことにより、正確で、迅速な「収納企業認証処理」は期待できない。」と主張している。
しかしながら,請求項1に係る発明の「収納企業認証処理」は,本願明細書の【0046】段落の記載を参酌すると,「DBサーバ内に記憶されている収納企業データファイルの情報内容と、利用者端末から送信されてきた口座振替契約に係る収納企業情報の内容とを照合し、収納企業の認証処理を行う」ものであり,引用例3の摘記事項(E)の【0017】段落には,「・・・銀行ホスト3は,入力された口座振替企業を口座振替契約の企業として受付けてよいか否かを図5に示す口座振替企業マスタ23を参照してチェックする(S11)。・・・」と記載されており,また,前述のとおり,引用例1には,「企業システムから銀行システムに口座振替に係る収納企業情報を引き継ぐ」処理が記載されており,これらの技術を組み合わせることに格別の阻害要因もないことから,引用例1の引き継いだ「口座情報に係る収納企業情報」により,口座振替企業マスタ23を参照してチェックして,収納企業認証処理を実現することは当業者が容易に想到し得たものである。
よって,審判請求人の上記主張は,当を得たものではない。

(3) 拒絶理由通知書の「(相違点3についての判断)」に対する主張
審判請求人は,「本発明の請求項1に於いて、「本登録用データ」は、「銀行ホストヘ送信」し、「登録処理」を行うためのデータであるが、引用例3に於いては、「口座振替契約依頼データ33を基に・・・口座振替契約マスタ27を更新する」と記載されていることから、本発明の請求項1の「本登録用データ」に相当するものは、引用例3に於いて企業ホストで作成される「口座振替契約依頼データ」である。然しながら、引用例3に於いて、「口座振替契約依頼データ」は、企業ホストによって作成(変換)されるものであり、銀行ホスト等では作成されていない。従って、「IB用のWebサーバ」が、「本登録用データを作成する」とは言えず、示唆してもいないものである。」と主張している。
しかしながら,マスタファイルを更新する際に,マスタファイルに準じた形式及びデータ構造とする更新用データを作成し,当該更新用データでマスタファイルを更新することは,マスタファイルの更新処理として周知技術であり,マスタファイルに直接データを書き込んで更新する更新処理よりも一般的であり,上記周知技術を適用して,「口座振替契約依頼データ」を基に「口座振替契約マスタ」を更新するに際して,「口座振替契約依頼データ」に基づいて,請求項1の「本登録データ」に対応する「口座振替契約マスタに準じた形式及びデータ構造とする更新用データ」を作成し,当該更新用データで「口座振替契約マスタ」を更新することは,格別のことではない。
よって,審判請求人の上記主張は,請求項1に係る発明の「本登録用データ」と,引用例3に記載された「口座振替契約依頼データ」とを対応付けた点で失当であり,この対応付けに基づくその余の主張は,当を得たものではない。

また,審判請求人は,「引用例3に於いて、「銀行ホスト3は図10に示すような口座振替依頼データ33の結果コードフイールドに、契約ができたか否かの情報を書き込み」と記載されているが、この記載のみでは、送受信は行なわれていないことから、本発明の請求項1に記載される「銀行ホストから該本登録処理の可否の結果データを受信する」ことと共通しない。」と主張している。
しかしながら,上記審判請求人が指摘する記載箇所に続いて,「・・・口座振替契約結果データ35としてEBシステムに蓄積する。企業ホスト5はEBシステムから口座振替契約結果データ35を取り込み、結果コードを判定して、図11に示すような企業ホスト5の請求マスタ31に口座振替契約情報を追加・更新する。」と記載されており,図3のフローチャートも合わせ見れば,企業ホストは銀行ホストから口座振替契約(本登録処理)の可否の結果データを受信しているものと認められる。
よって,審判請求人の上記主張は,引用例3の記載を正解しないものである。

(6)まとめ
以上のとおり,請求項1に係る発明は,引用例1記載の発明及び引用例1-3の記載事項に基づいて,当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることはできない。

VI.むすび
したがって,この出願は,特許法第36条第4項に規定する要件を満たしていないから,拒絶されるべきものである。
また,請求項1に係る発明は,引用例1記載の発明及び引用例1-3の記載事項に基づいて,当業者が容易に発明をすることができたものであり,特許法第29条第2項の規定により特許を受けることはできないから,他の請求項を検討するまでもなく,この出願は拒絶されるべきものである。
よって,結論のとおり審決する。
 
審理終結日 2008-12-12 
結審通知日 2009-01-06 
審決日 2009-01-19 
出願番号 特願2003-109900(P2003-109900)
審決分類 P 1 8・ 537- WZ (G06Q)
P 1 8・ 121- WZ (G06Q)
最終処分 不成立  
前審関与審査官 丹治 彰、石川 正二  
特許庁審判長 赤穂 隆雄
特許庁審判官 ▲吉▼田 耕一
山本 穂積
発明の名称 口座振替契約方法、システム及びプログラム  
代理人 小島 高城郎  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ