(57)【要約】本発明は、データネットワーク及び/又は遠隔通信網を利用して電子決済システムサーバーを介した顧客による商品又はサービスに対する業者への少なくとも最小額の電子決済のための方法に関している。この場合決済過程又は一連の決済ステップに対して、一義的なプロセス識別子が生成され、この識別子が、少なくとも確認問い合わせにおける最初の決済ステップ中に、決済システムサーバーからクライアント端末へ、支払い額情報と共に伝送される。
2005536786.tif 000002
【特許請求の範囲】
【請求項１】
データネットワーク及び/又は遠隔通信網と決済システムサーバーの投入を利用して顧客による商品又はサービスに対する業者へのそれぞれ最少額での一連の支払いステップを実施するための、少なくとも最小額の電子決済のための方法において、
支払い過程または一連の支払いステップに対して一義的なプロセス識別子を生成し、少なくとも最初の支払いステップにおける決済システムサーバーからの確認問い合わせにおいて、支払い金額情報と共に顧客端末へ伝送し、
顧客は顧客端末からの確認メッセージの伝送によってデータネットワーク若しくは遠隔通信ネットワークを介して決済システムサーバーへ預金ないしクレジット金額部分を支払いに対するプロセス識別子との対応付けの中で支払料金の額までトリガし、
決済システムサーバー上で当該決済システムサーバーのもとに記録されそこから電子管理可能な顧客の預金ないしクレジット金額部分と、トリガされるべき支払額との比較を実施し、
決済システムサーバーによる確認メッセージへの応働における、トリガされるべき支払額を上回る預金金額の確定に対する判定の中で、トリガされるべき支払額または当該時点までに支払われるべき金額部分のポスティングがこれによってトリガされ、行われたポスティングに関する第１の実施メッセージが業者端末に送信されるようにしたことを特徴とする方法。
【請求項２】
プロセス識別子が顧客識別子との対応付けにおいて決済システムサーバーによって生成され、業者端末から伝送されたリクエストメッセージに対する応働の中で、予め業者に伝送される請求項１記載の方法。
【請求項３】
プロセス識別子の伝送は、電子的な経路で決済システムサーバーから業者単滅への識別子通知の中で行われる、請求項２記載の方法。
【請求項４】
第２の支払いステップと、関連する一連の支払いステップのうちのさらなるステップがそれぞれ以下のケースにおいて実行される、すなわち、
−プロセス識別子に対する対応付の中で決済システムサーバーへのステップに関する支払い金額の伝送、
−トリガされるべき支払い金額から残される残存支払金額との関係におけるステップに係わる支払金額の検査、
−残余支払金額を下回るステップに係わる支払金額の確定に対する課金と、業者端末へのさらなる実行メッセージの送信のケースにおいて実行される、請求項１から３いずれか１項記載の方法。
【請求項５】
第２の支払いステップ若しくはさらなるステップにおいてトリガされるべき残余支払い金額を上回るステップに係わる支払金額の確定の結果において、決済システムサーバーにより顧客端末へ確認問い合わせがもとの若しくは新たなプロセス識別子と共に送信され、支払金額情報が少なくともステップに係わる支払金額と残余支払金額の間の少なくとも差分をカバーする支払金額と共に送信され、ステップに開変わる支払金額の課金は、顧客端末からの相応の確認メッセージの受信後に初めてトリガされる、請求項４記載の方法。
【請求項６】
確認に対する確認問い合わせにおいて示される支払金額がステップに係わる支払い金額と残余支払金額の間の差分よりも明らかに大きく、それによって当該支払金額に対する確認メッセージに対する応働の中で後続の複数の支払いステップに対する新たな残余支払い金額が、決済システムサーバーのもとでトリガされる、請求項５記載の方法。
【請求項７】
業者端末から決済システムサーバーへの各メッセージは、業者識別子並びに商品若しくはサービス表す識別コンテキストデータレコードを含んでいる、請求項１から６いずれか１項記載の方法。
【請求項８】
前記プロセス識別子は、ＥメールまたはＳＭＳによって業者端末へ伝送される、請求項１から７いずれか１項記載の方法。
【請求項９】
前記プロセス識別子が、顧客にデータネットワークないし遠隔通信ネットワーク外でポイントオブセールにて特に口頭若しくは文字で通知される、請求項１から７いずれか１項記載の方法。
【請求項１０】
決済システムサーバーから顧客端末への確認問い合わせが、Ｅメール、ＷＡＰプッシュ、ＳＭＳによって、若しくは合成音声メッセージとして伝送される、請求項１から９いずれか１項記載の方法。
【請求項１１】
前記決済システムサーバーから顧客端末への確認問い合わせは、業者名と商品またはサービスを表すコンテキストデータレコードを含む、請求項１から１０いずれか１項記載の方法。
【請求項１２】
顧客端末から決済システムサーバーへの確認メッセージは、Ｅメール転送、ＷＡＰ転送、又はＳＭＳ転送によって特に顧客側の付加的な入力なしで送信される、請求項１から１１いずれか１項記載の方法。
【請求項１３】
顧客端末から決済システムサーバーへの確認メッセージは、ボイスＩＤに続く音声メッセージまたはＤＴＭＦによって送信される、請求項１から１１いずれか１項記載の方法。
【請求項１４】
顧客端末から決済システムサーバーへの確認メッセージは、自動的に生成されるかまたは顧客によって入力される顧客識別子を含み、任意付加的に確認コード、特にＰＩＮコード若しくはパスワードを含んでいる、請求項１から１３いずれか１項記載の方法。
【請求項１５】
前記決済システムサーバーは、業者端末への第１実施メッセージの他に第２の実施メッセ維持を顧客端末へ送信する、請求項１から１４いずれか１項記載の方法。
【請求項１６】
決済システムプロバイダの決済システムサーバーと、
データ及び/又遠隔通信ネットワークに接続されこれらを介して決済システムサーバーと接続可能な顧客端末と、
データ及び/又は遠隔通信ネットワーク又はさらなる通信ネットワークに接続されそれらを介して決済システムサーバーと接続可能な業者端末とを有している、請求項１から１５いずれか１項記載の方法を実施するための装置において、
前記決済システムサーバーは、顧客端末への確認問い合わせの生成と送信のための手段と、
顧客端末からの確認メッセージの受信と、少なくともプロセス識別子及びそこからトリガされるべき支払い金額の抽出のための手段と、
顧客に係わる預金金額の記憶と、プロセスに係わるトリガされるべき支払金額の記憶のための記憶手段と、
預金金額を支払金額と比較するための比較手段と、
前記比較手段に接続された、業者端末への実行メッセージの送信と課金のトリガのための制御及び送信手段とを有していることを特徴とする装置。
【請求項１７】
前記顧客端末は、移動無線端末として構成されており、前記データ及び/又は遠隔通信ネットワークは、移動無線ネットワークを有しており、前記決済システムサーバーには、顧客端末との双方向の移動無線通信のための移動無線送受信手段が割当てられている、請求項１６記載の装置。
【請求項１８】
前記決済システムサーバーは、プロセス識別子の生成のための生成手段と、これに接続された、業者端末へのその伝送のための送信手段を有している、請求項１６又は１７記載の装置。
【請求項１９】
前記決済システムサーバーはさらに、記憶されているトリガされるべき支払金額と少なくともステップに係わる支払い金額からの残余支払い金額の計算のための計算手段と、該計算手段に接続された、比較手段に対する入力データとしてトリガされるべき支払金額の置換による残余支払金額の記憶のための記憶手段とを有している、請求項１６から１８いずれか１項記載の装置。
【請求項２０】
前記決済システムサーバーは、及び、業者端末ないしは顧客端末からのメッセージから業者識別子及び/又は顧客識別子を抽出するため及びその若しくはそれらの記憶のための識別及び記憶手段と、
確認問い合わせ、及び/又は実行メッセージ、及び記憶されている業者識別子ないし顧客識別子に基づいた顧客端末ないし業者端末への選択可能なさらなるメッセージ、のアドレッシングのためのアドレッシング手段を有している、請求項１６から１９いずれか１項記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、請求項１の上位概念による商品若しくはサービスの電子決済のための方法並びに該方法を実施するための装置に関している。
【背景技術】
【０００２】
インターネットは、今では不特定多数の一般大衆の通信手段や情報源としての地位を確立し、また購買源としての重要性も益々高めつつある。特にソフトウエア、書籍、旅行などの商取引は、今日では既にインターネットの重要な部分を占めており、また既にその他のグッズやサービスも広範囲に亘って益々インターネットを介した注文や支払いが増え続けている。当初から確立され今日ではさらに拡大傾向にあるこのインターネットにおける相応のサービスの決済は、個別のトランザクションに対してでなくても少なくとも各ビジネスパートナー毎に関連するデータレコードの別々の入力を必要とする。この支払い方式は、ビジネスパートナーに個人情報へのアクセスを許容し、その長期保存も可能にさせている。
【０００３】
その間にもインターネットは、個人領域においてもビジネス上においても、もはやそれ以外の決済過程の処理に対してまで多大な重要性を占めるようになる。
【０００４】
また先進工業国のほぼ全ての銀行は、“エレクトロニックバンキング”として口座取扱いや決済過程の電子処理を提供している。
【０００５】
この電子決算方式には種々異なる状況のもとで様々な要求が課せられる。これらには、インターネットを介した決済方式も、ＳＭＳ、WAP、USSDに基づいた移動型決済方式も含まれる。
【０００６】
特にいわゆる少額決済（マイクロペイメント）に適した方法も必要である。これは既存の決算方式（例えば口座引き落とし）を介したのでは通常のコスト効果をもたらすことのできない少額の決算である（典型的には５ユーロ以下）。その他にもマイクロペイメント過程は、例えばオンラインショップでの“ショッピングバスケット”を充たすようなショッピングなど個々のトランザクション単独ではなくて、複数の小さな個別トランザクションのまとまりから成り立つものが頻繁にある。将来的にはインターネット内の多くのサービスが課金されることが予想され（例えばウエブコンテンツ）、その場合のコストは例えば伝送されるデータ容量に依存するか、あるいはダウンロードするサイトの数に依存する。それ故にコストやチャージは電話の課金システムのように連続的に増えてゆく。コンテンツの課金では、コストは通常は時間に依存するのではなく、ユーザーの行動に依存している。しかしながら時間に依存した課金も基本的には可能である。
【０００７】
電話においてはユーザーは、通常は支払いの許可に関する許諾が自らはできない。これはユーザーが自分の電話でダイヤルを選択すると、それが自動的に電話会社に対して自身の口座からの引き落としを許諾したものとみなされるからである。このようなことは普段は何の問題もない。ユーザーと電話会社との間で信託と相応の課金契約が成り立っているからである。
【０００８】
しかしながらイーコマースの場合ではこのようなことが当てはまらないケースもある。ユーザーがインターネットにおいて自身に興味のあるサービスであっても、ユーザーに対して支払い義務の生じるものがあるからである。このようなケースでは信託の関係は存在していないから、ユーザーはまず最初に支払いの許諾を例えばOKによる確認かあるいはPINコードによる許可を与える。しかしながら連続的な決済では、ユーザーはこのような個別の決済をいちいち行うことは必ずしも望まない。一方では、そのようなことはユーザーにとってめんどうであり、他方では幾つかのサービス、例えばオーディオ/ビデオのストリーミングにおいては、流れているオーディオ/ビデオを決済のたび毎に中断しなければならないので、そのようなことはできるだけ避けたいからである。
【０００９】
技術的な問題は、前述したような点を満足できるように方法を改善してゆくことにあって、具体的には、
−汎用性の問題；例えばウエブ、ＳＭＳ、WAPなど異なるアクセス手法に対して同じ基本原理をかなえること
−連続的な課金のサポートの問題；この場合はユーザーが特定のサービスに直接的に、次の確認/許可の実行を定めることができること
−業者との関係において次の確認/許可の規定について守秘が守られること
−ユーザー毎の支払いが業者に対して匿名でできること
−操作ができるだけ簡単に構築できること
−操作が、あらゆる攻撃に対してセキュリティ上で守られることなどである。
【００１０】
これらの基本的な問題は、例えば欧州特許出願 EP 1 193 658 A1 明細書並びに同一出願人のさらなる別の先行出願明細書（企業内部識別番号２００２０１３７４）でとりあげられている。
【００１１】
最初に述べた明細書では、送金者が送金受取り人に受信ＩＤ（ＲＩＤ）を用いて電子的な金額を匿名で伝送可能なことが記載されている（以下ではわかりやすくするためにこれをセッションＩＤとも称する）。これによって顧客は、ＰＳＰ（Ｐａｙｍｅｎｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）に対してそして業者に対しても匿名を維持できる。以下ではこの方法を図１に基づいて簡単に説明する。
【００１２】
業者はＰＳＰに支払われるべき金額１）を伝送し、一義的なセッションＩＤ（ＳＩＤ）２）の返信を受け取る。ＳＩＤをＰＳＰは顧客に、例えば口頭でＰＯＳ（Ｐｏｉｎｔ  ｏｆ  Ｓａｌｅ）のもとで伝送する３）。顧客はＰＳＰに対して接続を形成し、ＳＩＤ４）を伝送する。これによって顧客は同時にＭＳＩＳＤＮに基づいて識別される。ＰＳＰは所属の支払われるべき金額を返信し５）、顧客はこの金額をＰＩＮ６）でもって確認する。ＳＩＤは業者に支払い確認として通知される。
【００１３】
前述したさらなる先行出願文献では、いわゆる事前承認の方法が開示されており、すなわち顧客は、業者の求めよりも高い（若しくは低い）金額を事前承認できる。それにより後に続く業者からの決済を顧客による永続的でめんどうな確認なしでも行える。顧客自身は、最大金額を予め設定しているので、自分で支払いを非常に融通的に決められる。予め承認した金額に達しない限りは再度顧客が支払いを確認する必要はない。
【００１４】
以下ではこの方法を図２に基づいて簡単に説明する。
【００１５】
業者はＰＳＰを介して顧客に金額＄１を課金する。ＰＳＰは事前承認口座＄が十分であるかどうかを検査する。十分でない場合には、顧客はこの金額をＰＩＮでもって承認する２）、３）。付加的に顧客はより高い金額を承認し＄２，事前承認口座を相応に調整する。金額＄１は、業者に確認される４）。次の支払い要求５）で事前承認口座が十分ならば、この金額は直ちに承認され得る６）。このステップは、事前承認口座がもはや十分ではなくなるまで繰り返され、その時にはユーザーは再度承認を行わなければならない。
【００１６】
前述した方法は、非常に強い、リアルＰＯＳ傾向にあり、例えばショップや自販機、プリペイド口座向けである。この場合、他のシナリオ（例えばウエブ、ＷＡＰ，ＳＭＳ）をサポートするためには基本原理がＳＩＤによって容易に拡張され得る。さらにＳＩＤに基づけば、事前承認も実現され得る。この方法は、サーバーが移動無線で作動されるケースしか考慮しない。２番目に上述した方法では、正確な実現に関しては所定の具現化しか許容されない。
【００１７】
そこで本発明の課題は、より具体的に拡張可能でかつ特に少額決済の求めにぴったり合う電子決済方法を提供することである。さらに本発明の課題は、それにふさわしい装置を提供することである。
【００１８】
前記課題は本発明の観点において、請求項１の特徴部分に記載された本発明による方法並びに請求項１６に記載された本発明による装置によって解決される。
【００１９】
本発明は前述した技術的問題を以下の前提に基づいて解決する。：
−セッションＩＤ（ＳＩＤ）に基づいて顧客が業者（サービスプロバイダ）に対して匿名を維持できるように（但し必須ではない）保証すること
−さらにＳＩＤは、顧客による支払いの承認/許可の必要性なしで顧客に業者に対して連続的な課金の実施を許可できるようにする
−統合された最大決済の限界は、ユーザーによってサービス固有に融通性をもってセットできる
−当該方法は顧客に対する様々なアクセス方法（例えばウエブ、ＷＡＰ，ＳＭＳ，Ｖｏｉｃｅ/ＤＴＭＦ）をサポートする。インターネットではＰＯＳ（Ｐｏｉｎｔ ｏｆ Ｓａｌｅｓ）なども投入できる。業者とＰＳＰの間の接続は点的な形態で標準データ線路を介して構築される。
【００２０】
この方法の有利な実施例では、以下に述べるステップが含まれ、それに対しては図３並びに図４〜図７に表示されている有利な実施例と相応の説明部分によって以下で詳細に説明する。
１）顧客は業者からのサービスを利用する（例えばＷＡＰコンテンツの問い合わせ、ウエブショップ若しくはＰＯＳにおける商品の支払いなど）
１ａ）業者は顧客を識別でき、この顧客に割当てられたＳＩＤを求める。それにより業者はこれをステップ２）において提供できる
２）業者はＰＳＰに対してＳＩＤ（入手可能な場合）、支払うべき額（ＢｅｔｒａｇＸ）、業者ＩＤ、コンテキスト（何が購入されたか）などと共に課金問い合わせを送信する
３）ここにおいて以下の違いが生じる：
−前記２）においてＳＩＤが何も提供されなかった場合、ＰＳＰは一義的なＳＩＤを業者に返信する。引き続きステップ３ａ〜３ｆが続く
−前記２）において（例えば顧客が最初に許可しなければならないなどの理由から）ＳＩＤが提供されたが課金は不可能であった場合には、ＳＩＤ若しくは代替的な新たなＳＩＤが返信される。引き続きステップ３ａ〜３ｆが続けられる
−前記２）において課金の実施を可能にするＳＩＤが伝送された場合、業者に対して課金が承認され、引き続きステップ４が続けられる
３ａ）前記３）において検査がネガティブならば（すなわち課金が不可能）、ＰＳＰは業者にＳＩＤを通知する
３ｂ）業者は顧客にＳＩＤを通知する。ＷＡＰ及びＷＥＰの場合にはこのことはパラメータとして顧客からＰＳＰへの転送において行われる。ＳＭＳの場合には業者は顧客に入手されたＳＩＤと共にＳＭＳを送信する。ＰＯＳには口頭でＳＩＤが通知されてもよい
３ｃ）顧客はＳＩＤをＰＳＰに転送する。ＷＥＢおよびＷＡＰの場合にはこのことは匿名で行われてもよい。つまり顧客はこれについて何も入力しなくてもよい（転送）。ＳＭＳの場合ではＳＭＳが業者からＳＩＤと共にＰＳＰに転送される。Ｖｏｉｃｅ/ＤＴＭＦの場合では顧客はＰＳＰを呼出し、ＳＩＤをＤＴＭＦを介して転送しなければならない
３ｄ）ＰＳＰは顧客に、要求された額（ＢｅｔｒａｇＸ）、業者名並びにコンテキストを通知する（例えばＷＥＢ、ＷＡＰ、ＳＭＳ、Ｖｏｉｃｅ（音声）を介して）
３ｅ）顧客は例えば自身のＭＳＩＳＤＮ、若しくは自身のＩＤの入力を介して識別される。そのうえさらに顧客は要求される金額（ＢｅｔｒａｇＸ）を変更できる（ＢｅｔｒａｇＹ）（例えば後に続く支払いの事前承認に対する引き上げなど）。さらに顧客は支払いを承認/許可できる（例えばＰＩＮ）
３ｆ）顧客プロフィール及び流動性の検査
４）ＰＳＰはここにおいて必要な支払いの検査を実施する
５）ＰＳＰは任意に顧客に支払い（ＢｅｔｒａｇＸ）を確認できる（例えばＳＭＳ毎に）
６）ＰＳＰは業者に対して金額のポスティング（記帳）を承認する
７）業者は商品を顧客に送る。
【００２１】
接続に係わる操作（例えばＷＡＰ、ＷＥＢによる）のもとでは、典型的には接続転送に基づいて、最初に顧客＜−＞業者間から顧客＜−＞ＰＳＰに切り替る。それによって顧客は業者のもとで所望のサービスを支払いの後に再び使用することができ、ＰＳＰからの転送が業者に戻される。この転送は、実施固有のものであり、シーケンスには表れない。
【００２２】
十分な金額の事前承認の後では、課金はステップ２）、３）、４）及び６）からのみ成立し、それ故に非常に効果的に処理され得る。この金額の事前承認は、必ずしも購入に直接関係させなくてもよい。例えば顧客は、ＳＩＤに対して十分な額の金額を事前承認することができる（例えばパーキングメータの支払いなど）。業者は顧客とＳＩＤの間で割当てを記録した場合には、全ての将来的な支払いに対してステップ３ａ〜３ｆを省くことができる。顧客の識別は、例えばＭＳＩＳＤＮ、ＳＭＳ、若しくはログインの際のＩＤに基づいて実施できる。その場合に重要なことは、業者のもとでのユーザー識別がＰＳＰのもとでのユーザー識別に依存しないことである。それにより不都合な依存性は生じず、業者はＰＳＰのもとでの顧客のユーザー識別を知る必要がなくなる。
【００２３】
顧客はいつでも、ＰＳＰのもとでその有効なＳＩＤリストを表示させることができる。ＳＩＤに対してはさらに所属のデータ、例えばまだ使用可能な金額や所属業者を表示させることができる。選択されたＳＩＤ（ＰＳＰの場合）は、例えばＷＥＢ、ＷＡＰ、ＳＭＳを介して消去することも可能である。ＳＩＤの消去の後は業者は顧客の了解なしでは課金を実施できない。課金を再び実施させるためには、全てのシーケンスが実施されなければならない（例えばＳＩＤの要求及び支払いの承認）。
【００２４】
ＰＳＰは、必ずしも実際の口座や顧客のお金、業者を管理する必要はない。例えばＰＳＰは、口座の清算や交換を実施するクリアリングハウスとのインターフェースを有し得る。
【００２５】
本発明は以下の利点を有する：
−本発明の基本原理は、様々なアクセス手法（例えばＷＥＢ、ＷＡＰ、ＳＭＳ）などに対して同一である。このことは融通性の制約なく支払いシステムの実現と業者や顧客に対する当該方法の利用を容易にさせる
−当該方法は、個別の課金も連続的な課金もサポートしている。特に連続的な課金は、とりわけ容量に合わせた課金（ペイパークリック）や時間ベースの課金が行われるコンテンツの課金のケースにおいて重要な意味をなす
−コストのコントロール：顧客はサービス固有の金額を事前承認でき、それによってやっかいな記帳の承認/許可を避けられる
−事前承認された金額のもとでは、課金が非常に迅速に行える。簡単なケースでは、例えば自販機で飲料水を得るために顧客は業者に対してＳＭＳを送るだけでよい
−高い安全性：顧客は業者に対して信用情報や支払いに係わるデータ、例えばＰＩＮデータや口座番号などを与えなくて済む
−顧客は業者に対して匿名が可能である。
【００２６】
本発明のさらなる展望は、従属請求項にも記載されている。なお従属請求項に記載の本発明による方法の有利な実施例は全て本発明の方法の実施に適した装置の実施例（例えばハードウエアもしくはソフトウエアで実現し得る）としても理解し得ることを述べておく。これらの実施例は以下の明細書で図面に基づいて詳細に説明する。この場合、
図１は、公知の電子決済方法のシーケンスを概略的に表したダイヤグラムであり、
図２は、先行出願書類の対象である電子決済方法を概略的に表したダイヤグラムであり、
図３は、本発明の主要な考察を説明するための方法ステップを特徴付けたブロック回路図であり、
図４は、本発明の第１実施形態のブロック回路図であり、
図５は、本発明の第２実施形態のブロック回路図であり、
図６は、本発明の第３実施形態のブロック回路図であり、
図７は、本発明のさらなる実施形態のブロック回路図である。
【実施例】
【００２７】
次に本発明を図面に基づき以下の明細書で詳細に説明する。図１及び図２は、発明の詳細な説明の冒頭でも述べたように従来技術の説明のためのものである。また図３は、前述したように本発明の考察の導入部としてのものである。
【００２８】
図４には、プロバイダへの購入者による課金性のＷＡＰコンテンツの最初の呼出しに対する第１の課金プロセスが示されている。ステップＳ１では、購入者のＷＡＰ準拠の端末（例えば移動無線電話）１１から問い合わせがＧＳＭ遠隔通信ネットワーク１２を介してプロバイダーのサーバー１３に発せられる。販売者はステップＳ２においてトランザクションデータが（これは販売者のＩＤ、ＷＡＰコンテンツに対する計１ユーロの請求書、明細などからなる）データネットワーク１４を介してペイメントサービスプロバイダ（ＰＳＰ）のサーバー１５に伝送される。
【００２９】
ステップＳ３におけるトランザクションデータの検査の後では、購入者に割当てられるセッションＩＤ（ＳＩＤ）は何も求められないので、ここにおいてＰＳＰ（ペイメントサービスプロバイダー）のサーバー１５に対してはステップＳ３．１によって一義的なＳＩＤが生成され、Ｓ３．２によってプロバイダのサーバー１３に伝送され、そこに記憶される。これはステップＳ３．３においてパラメータとしてＷＡＰ転送のＵＲＬにて購入者の移動電話１１へ送信される。この場合ＳＩＤはステップＳ３．４のＷＡＰ転送の枠内で自動的にＰＳＰのサーバー１５へ伝送される。それに続いてステップＳ３．５ではＰＳＰのサーバー１５から販売者のＩＤ、ＷＡＰコンテンツの１ユーロの請求書と明細が購入者の移動電話１１へ伝送される。ステップＳ３．６では、購入者の識別が移動電話の公知のＭＳＩＳＤＮに基づいてＷＡＰ−ＧＷ問い合わせと、ＰＩＮによる計３ユーロの預金金額の承認が行われる。
【００３０】
ＰＳＰのサーバー１５にはステップＳ４において預金金額がＳＩＤに割当てられたトランザクション口座に対応付けられ、並びに請求金額がトランザクション口座に記帳され、ステップＳ５の購入者プロファイルの検査の後でステップＳ６において、１ユーロの請求金額と業者ＩＤを含んだポスティング確認が購入者の移動電話１１に送信される。ステップＳ７においてＷＡＰコンテンツの請求金額とＳＩＤの形態のポスティング確認がＰＳＰサーバー１５からプロバイダのサーバー１３へ伝送された後では、ステップＳ８において購入者移動電話１１へのＷＡＰコンテンツの伝送がトリガされる。
【００３１】
図５には有料ＷＡＰコンテンツに対するポスティングプロセスが図４の例と同じように記載されている。ステップＳ１では、購入者の移動電話２１からさらなる問い合わせがプロバイダのサーバー２３へ発せられる。ステップＳ２では、プロバイダが販売者のＩＤとＷＡＰコンテンツに対する計１ユーロの請求金額と明細並びにＳＩＤからなるトランザクションデータをＰＳＰのサーバー２５に送信する。ステップＳ３からＳ５におけるトランザクションデータ、ないしはＳＩＤ、預金金額、顧客プロファイルのポジティブの検査結果の後では、引き続きステップＳ６においてＰＳＰサーバー２５上でトランザクション口座に対する請求金額のポスティングが行われる。ステップＳ７におけるプロバイダのサーバー２３へのポスティング確認の送信の後では、ステップＳ８において、
購入者の移動電話２１へのＷＡＰコンテンツの伝送のトリガが行われる。
【００３２】
図６には、ＳＭＳに基づいた有料サービスの利用が表されている。ここではステップＳ１において購入者の移動電話１３から移動無線網３２を介してリクエストが販売者のサーバー３３に発せられる。ステップＳ２では、ＭＳＩＳＤＮ/移動無線ナンバーに基づいて購入者に所属するＳＩＤが求められ、ステップＳ３においてその他のトランザクションデータ（販売者ＩＤ、計１ユーロの請求金額、明細）がデータネットワーク３４を介してＰＳＰのサーバー３５に伝送される。ステップＳ４〜ステップＳ６のトランザクションデータ、ＳＩＤ、預金金額、顧客プロファイルのポジティブに経過した検査の後では、ステップＳ７において請求金額のポスティングが行われる。顧客プロファイル内に供託されている指示に基づいて、ステップＳ８ではＰＳＰのサーバー３５から１ユーロの請求金額のポスティングの確認が購入者の移動電話３１へ伝送される。ステップＳ９では、ポスティング確認が販売者のサーバー３３に発信され、そこでステップＳ１０によって販売者は有料ＳＭＳを顧客に伝送する。
【００３３】
図７には、ＳＭＳに基づいたさらなる実施例が示されており、ここではステップＳ１（有料サービスのリクエスト）からステップＳ６（顧客プロファイルの検査）が図５の実施例と同じように経過する。当該実施例のケースでは、顧客プロファイルにおいてポスティングのオーソライズが供託されており、そのためステップＳ７においてＰＳＰサーバー４５からトランザクションデータが購入者の移動電話４１に送信される。ステップＳ８では、ポスティングが請求金額、ＳＩＤ、ＰＩＮのＰＳＰサーバー４５への伝送によってオーソライズされ、その後ステップＳ９において行われる。ステップＳ１０における販売者のサーバー４３へのポスティング確認の伝送の後では、ステップＳ１１において販売者から有料ＳＭＳの顧客への伝送が行われる。
【００３４】
本発明の実施例は、前述してきた例示的な実施形態に限定されるものではなく、それどころか当該商取引の枠内における多くの変形例も可能である。
【図面の簡単な説明】
【００３５】
【図１】公知の電子決済方法のシーケンスを概略的に表したダイヤグラム
【図２】先行出願書類の対象である電子決済方法を概略的に表したダイヤグラム
【図３】本発明の主要な考察を説明するための方法ステップを特徴付けたブロック回路図
【図４】本発明の第１実施形態のブロック回路図
【図５】本発明の第２実施形態のブロック回路図
【図６】本発明の第３実施形態のブロック回路図
【図７】本発明のさらなる実施形態のブロック回路図
【図１】
2005536786.tif 000003
【図２】
2005536786.tif 000004
【図３】
2005536786.tif 000005
【図４】
2005536786.tif 000006
【図５】
2005536786.tif 000007
【図６】
2005536786.tif 000008
【図７】
2005536786.tif 000009
【手続補正書】
【提出日】平成16年5月19日(2004.5.19)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１
【補正方法】変更
【補正の内容】
【請求項１】
データネットワーク及び/又は遠隔通信網と決済システムサーバーの投入を利用して顧客によるそれぞれ最少額での一連の支払いステップが実施される、商品又はサービスの電子決済のための方法において、
支払い過程または一連の支払いステップに対して一義的なプロセス識別子が決済システムサーバーによって生成され、少なくとも最初の支払いステップにおける決済システムサーバーからの確認問い合わせにおいて、支払い金額情報と共に顧客端末へ伝送され、
顧客は顧客端末からの確認メッセージの伝送によってデータネットワーク若しくは遠隔通信ネットワークを介して決済システムサーバーへ預金ないしクレジット金額部分を、支払いに対するプロセス識別子との対応付けの中で支払料金の額までトリガし、
決済システムサーバー上で、当該決済システムサーバーのもとに記録されそこから電子管理可能な顧客の預金ないしクレジット金額部分とトリガされるべき支払額との比較が実施され、
決済システムサーバーによる確認メッセージへの応働における、トリガされるべき支払額を上回る預金金額の確定に対する判定の中で、トリガされるべき支払額または当該時点までに支払われるべき金額部分のポスティングがこれによってトリガされ、行われたポスティングに関する第１の実施メッセージが業者端末に送信されるようにしたことを特徴とする方法。
【国際調査報告】
2005536786.tif 000010
2005536786.tif 000011
2005536786.tif 000012
2005536786.tif 000013