(57)【要約】本発明は携帯電話通信システムにおいて金融取引を遂行する方法とシステムに係るものである。多様化している金融取引を取引の発注者と代金受領者との間で可能とするため第１の取引メッセージを取引サーバーへ送って処理する。この処理に応じて第２，第３の取引メッセージが発生する。第２取引メッセージは第１携帯電話加入者に関して取引を遂行するに必要な情報を含み、そして第３取引メッセージは取引の受領者に関して取引を遂行するに必要な情報を含む。この第２取引メッセージを第１携帯電話ネットワークのビリング・センターに送って第１の携帯電話ネットワークの加入者に関する取引を清算し、そして第３の取引メッセージを取引を受けるシステムに送って受領者に関しての取引を清算する。
2005502141.tif 000002
【特許請求の範囲】
【請求項１】
第１の携帯電話ネットワークの加入者から取引の受領者への取引を遂行する方法において、
第１の取引メッセージを取引サーバーへ送る段階、
この第１の取引メッセージを処理する段階、
この処理に応答して、第１の携帯電話ネットワークの加入者に関する取引遂行に必要な情報を含む第２の取引メッセージを、そして取引の受領者に関する取引遂行に必要な情報を含む第３の取引メッセージを発生する段階、
前記の第１の携帯電話ネットワークの加入者に関して取引を清算するため前記の第２の取引メッセージを第１の携帯電話ネットワークのビリング・センターに送る段階、そして
前記の受領者に関して取引を清算するため取引を受けるシステムへ前記の第３の取引メッセージを送る段階
を備えることを特徴とする方法。
【請求項２】
前記の第１の携帯電話ネットワークの加入者を特定認識する認識子を含む問合せを携帯電話ネットワークの加入者データーベースへ送る段階、
このデーターベースからの応答を受ける段階、
その応答に基づいて取引を継続すべきか否かを決定する段階
を更に備える請求項１に記載の方法。
【請求項３】
取引を監視する段階、
この監視に応じて、前記の第１の携帯電話ネットワークの加入者へ取引の結果を示す告知を送る段階
を更に備える請求項１に記載の方法。
【請求項４】
データーベース内の取引の受領者に関しての情報を蓄積する段階、そして
その蓄積情報を利用して、前記の処理する段階における前記の第３の取引メッセージのため受領者の認識子部分を発生する段階
を更に備える請求項１に記載の方法。
【請求項５】
前記の受領者は第２の携帯電話ネットワークの加入者であり、そして前記の第３の取引メッセージを携帯電話ネットワークのビリング・センターに送る請求項１に記載の方法。
【請求項６】
第１の取引メッセージがデーターベースに蓄積されている請求項１に記載の方法。
【請求項７】
前記の取引が、第１の携帯電話ネットワークの加入者が第２のネットワーク加入者に金を貸すことである請求項５に記載の方法。
【請求項８】
前記の取引が、第１の携帯電話ネットワークの加入者がプリペイド電話アカウントを再請求することである請求項１に記載の方法。
【請求項９】
前記の取引が、第１の携帯電話ネットワークの加入者が振り替えをすることである請求項１に記載の方法。
【請求項１０】
前記の第１の取引メッセージが短いメッセージである請求項１に記載の方法。
【請求項１１】
第１の携帯電話ネットワークの加入者から取引の受領者への取引を遂行するシステムにおいて、
第１の取引メッセージを取引サーバーにおいて受け取る第１の受信手段、
この第１の取引メッセージを処理する処理手段、
この処理手段に応答し、第１の携帯電話ネットワークの加入者に関する取引遂行に必要な情報を含む第２の取引メッセージを発生する第１のメッセージ発生手段、
取引の受領者に関する取引遂行に必要な情報を含む第３の取引メッセージを発生する第２のメッセージ発生手段、
前記の第１の携帯電話ネットワークの加入者に関して取引を清算するため前記の第２の取引メッセージを携帯電話ネットワークのビリング・センターに送る第１の送信手段、そして
前記の受領者に関して取引を清算するため取引を受けるシステムへ前記の第３の取引メッセージを送る第２の送信手段
を備えることを特徴とするシステム。
【請求項１２】
前記の第１の受信手段に応答して、前記の第１の携帯電話ネットワークの加入者を特定認識する認識子を含む問合せを携帯電話ネットワークの加入者データーベースへ送る第３の送信手段、
前記の第３の受信手段に応答して、前記のデーターベースからの応答を受ける第２の受信手段、そして
この第２の受信手段に応答して、取引を継続すべきか否かを決定する選択手段
を更に備える請求項１１に記載のシステム。
【請求項１３】
取引を監視する監視手段、
この監視手段に応答して、前記の第１の携帯電話ネットワークの加入者へ取引の結果を示す告知を送る第３送信手段
を更に備える請求項１１に記載のシステム。
【請求項１４】
取引の受領者についての情報を蓄積する蓄積手段、
この蓄積手段に応答して、前記の情報を検索する検索手段、
この検索手段と前記の処理手段に応答して、前記の蓄積された情報を利用して、前記の第３の取引メッセージのため受領者の認識子を発生する発生手段
を更に備える請求項１１に記載のシステム。
【請求項１５】
前記の受領者が第２の携帯電話ネットワーク加入者であり、そして前記の第２の送信手段が前記の第３の取引メッセージを第２の携帯電話ネットワークビリング・センターへ送るようになっている請求項１１に記載のシステム。
【請求項１６】
前記の取引が、第１の携帯電話ネットワークの加入者が第２のネットワーク加入者に金を貸すことである請求項１５に記載のシステム。
【請求項１７】
前記の取引が、第１の携帯電話ネットワークの加入者がプリペイド電話アカウントを再請求することである請求項１１に記載のシステム。
【請求項１８】
前記の取引が、第１の携帯電話ネットワークの加入者が振り替えをすることである請求項１１に記載のシステム。
【請求項１９】
前記の第１の受信手段が受けた前記の第１の取引メッセージが短いメッセージである請求項１１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はモバイル通信システムにおいて金融取引を行う方法とシステムに係るものである。
【背景技術】
【０００２】
携帯電話を使用して取引する必要性が、携帯電話が広がってくるにつれ最近では一層緊急のこととなった。普通の電話の機能も携帯電話の方に向かって発達している。
【０００３】
市場で携帯電話で支払うことによる解決策が幾つかある。典型的な例は０７００連続番号を有する自動販売機である。この自動販売機を使用する加入者は０７００番号にかけて自動販売機を作動させる、すなわちその加入者にフレッシュ・ドリンクを販売させる。携帯電話で支払いを受け付ける機械の他の日常的な例としては自動車の洗浄機もしくは駐車オートメートがある。これらの機械では取引を受ける人は支払いシステムに登録されている。ある解決策ではユーザーの携帯電話の送受話器をプログラムをし直さなければならないが、別の解決策ではサービスに対し支払うのに既定の番号に文書メッセージを送ればよいことになっている。
【０００４】
更に他の解決策では、短いメッセージを送る必要がある。この方面の既知の方法は特許文献１，２に説明されている。これら２つの文献はプリペイド・ネットワーク・アカウントに代金請求し、そして再請求するタスクを取り扱っている。
【０００５】
【特許文献１】
ＷＯ  ００/１８１０６
【特許文献２】
ＷＯ  ００/３３２６４
【０００６】
特許文献１では個々にコード化したクーポンの形でコール・タイムを購入する。自分のアカウントに再請求する加入者はサービス番号に短いメッセージを送る。サーバーはそのメッセージを分析し、そして送り手の携帯電話認識番号（ＭＳＩＳＤＮ）に含まれている加入者のアイデンティティに基づいてアカウントに再請求する。
【０００７】
特許文献２ではプリペイド・システムの形のアカウントに請求もしくは再請求する。ユーザーは組織化されていない追加サービスデーターメッセージを送る。このメッセージは請求もしくは再請求しようとする額、ユーザーの秘密コード、そして任意事項として、第２のＩＤを含んでいる。この第２のＩＤによりその額を第２のユーザーのプリペイドアカウントへ再請求できる。
【０００８】
上述の自動販売機の例が示すように、加入者が取引の受領者もしくは受取人を自由に選択することはできない。他の例では取引はクーポンで行わなければならないか、もしくはプリペイド環境（プリペイド・アカウントを持つ加入者だけを含んでいる）にオペレーションは限定されている。システムの融通が非常に効くというのではないので顧客の満足は少なく、そして事後支払い、ポスト・ペイドの加入者を取りこむことはできない。
【０００９】
オペレーターは大抵は電話請求書の形で、サービスを利用するユーザーに請求書をだすのが普通である。ユーザーはサービス番号へ短いメッセージを送ることにより例えばコーラー・グループ（ｃａｌｌｅｒ  ｇｒｏｕｐ）アイコンもしくはリンギング・トーンへ加入でき、そのメッセージは所望のアイコンもしくはリンギング・トーンを指示している。受取人ＭＳＩＳＤＮを挿入することにより他の加入者へアイコンもしくはリンギング・トーンをオーダーすることもできる。オーダーを出した加入者は支払いを請求され、そして受取人へは余分のチャージは課せられないのが通常である。これらの例では代金請求はノーマルＧＳＭチャージングすなわちロゴもしくはリンギングトーンの送付に基づいている。代金請求チケットを生じるプロセスを開始するサービスを形成しているこのロゴもしくはリンギングトーンは、代金請求明細記録もしくは別個の請求項目のどちらかの形でＧＳＭ請求データーベースに入れられる。
【００１０】
上の例では利用できるサービスの選択によりユーザーは制限される。ユーザーは普通の通貨や他の同様の手段を使って取引をすることはできない。
【００１１】
普通のＧＳＭシステムにおいて融通性のある取引ができるようにすることは、もしも同じオペレータの他のユーザーと、異なるオペレータのユーザーと、そして様々に異なるシステムを採用している他の取引相手と多くの種類の異なる取引をしたいと思うポスト・ペイド（後払い）加入者を普通のＧＳＭシステムが含むのであれば、そのことは明らかに大きな挑戦である。ＰＬＭＮオペレータのインフラストラクチャ（構造基盤）を使うのではそのことは技術的に不可能とされてきたのが事実である。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明の目的は上記の問題に挑戦することであって、これを達成する方法、システム、そして取引サーバーは請求項１と１１にそれぞれ記載されている。
【課題を解決するための手段】
【００１３】
本発明は既存の携帯電話のネットワークのインフラを使って新しいサービスを提供する方法とシステムに係るものである。本発明の目的は、一つのオペレータの加入者間で、２つのオペレーターの加入者間でそしてＰＬＭＮオペレータの加入者と外部のパ−ティもしくは相手方との間での多様化した経済取引を可能とすることである。
【００１４】
安全取引の利点を保証できる。信頼できる加入者認証を使って、または許容取引に対する閾値設定により安全は得られる。
【００１５】
別の利点としては、加入者が金融取引をコントロールでき、その金融取引は加入者のアカウントで行われる。これはサービスの可能／不能の異種部分によって達成され、そしてその受取人により異なり、もしくは取引の種類により異なる会計限界もしくは金額限界の設定によって達成される。取引は２つのフォーマット、すなわち、携帯電話から出た取引と携帯電話で終端する取引とに分類される。単一のＰＬＭネットワーク内での取引、もしくは２つの比較できるＰＬＭネットワークのユーザー間での取引が両方のフォーマットにあり、それらのフォーマットは発注者と受取人で異なっている。
【００１６】
取引をしたいと思う人によってどの取引でも開始される。これはＰＬＭネットワークへメッセージを送ることによりなされ、そのメッセージは取引の受取人と取引の大きさを示している。
【００１７】
各金融取引は少なくとも一つのＰＬＭＮ加入者のアカウントに関係している。取引の大きさは２部数字であると言うのは、請求された取引額は、もし当事者のオペレーターがその取引に対して手数料を請求すると、受け取られる取引額と異なるからである。単一の取引について言えば、その請求された取引額は送り側（発注者）のアカウントへ請求される総額である。受け取られる取引額は受取人のアカウントへ再請求される総額である。ここで言う再請求（recharge）とは、アカウントにある額の金を置くことを言う。ＰＬＭＮ加入者のアカウントの請求もしくは再請求は、ＰＬＭＮネットワークの関連の代価請求センターもしくはビリング・センターへ請求明細記録（ＣＤＲ）を送ることによりなされる。
【００１８】
別の携帯電話のユーザーであるということのほかに、例えば銀行口座もしくは信用度の大きいクレジットカード・アカウントを有する個人または組織が相手であることもある。
【発明を実施するための最良の形態】
【００１９】
ＰＬＭＮ代金請求において、通常オペレーターは代金請求のベースとして使えるすべてのイベントについてのデータを収集する。これらは請求イベントとして知られている。通常この動作態様ではコールについての情報だけを収集する。この代価請求においてどれだけ多くの加入者が請求されているかは未だ計算されていない。
【００２０】
図１は従来のＰＬＭネットワークを示しており、この例ではＧＳＭネットワークである。通常はコール、短いメッセージもしくは何か他のＰＬＭサービスを携帯電話端末（ＭＴ）１０１からベース・トランシーバ・ステーション（ＢＴＳ）１０２とベース・ステーション・コントローラ（ＢＳＣ）１０３とを介してモバイル・スイッチング・センター（ＭＳＣ）１０４へ送る。ＭＳＣは受取人へのコール、もしくはショート・メッセージ・センター（ＳＭＳＣ）１０５へのメッセージの発信源を辿る。ショート・メッセージ・センターは受取人へのメッセージを蓄え、そして配送する。ＰＬＭネットワークにおいては加入者は異なるネットワークを徘徊することがある。その場合にはホーム・ロケーション・レジスター（ＨＩＲ）１０８は加入者の現在のＭＳＣの情報である。更に詳しく言えば、ネットワークはビジター・ロケーション・レジスター（ＶＬＲ）を有し、それらは通常それぞれのＭＳＣへ直接接続されている。ＶＬＲはネットワークのエレメントであって、予約サービスについての、そして多分加入者認証を遂行する何らかの手段についての情報を含んでいる。通常この後のことは、加入者のホーム・ネットワーク・認証センターもしくはＨＬＲからのテスト・キーと署名をＶＬＲが要求するというような仕方で行われる。そのとき、ＶＬＲはキーを加入者端末へ送り、そして端末はそのキーに対して署名を送り返す。もしもその署名がＨＬＲから回収された署名と一致すれば、その加入者は正当加入者である。
【００２１】
そのネットワークがパケット・スイッチド・ネットワークであると、サーキット・スイッチド・トラヒックを扱うエレメントはそれらのパケット・オリエンテッドのカウンター・パートに置換えるのが通常である。この種類のネットワークにおいて、オペレーションの原理は上述のものと余り異なってはいない。例えば、ＧＰＲＳアーキテクチャにおいてパケットデータ・エレメントは一般にサポーティングＧＰＲＳサポート・ノード（ＳＧＳＮ）とゲートウエイＧＰＲＳサポート・ノード（ＧＧＳＮ）であり、前者はＭＳＣのパケット関連のタスクを行い、後者は外部ネットワークに向いているゲートウエイとして働く。
【００２２】
図１を参照する。代価請求データの作成を引き受けるネットワーク要素はＭＳＣ１０４、ＨＬＲ１０８、そしてそのネットワークに存在する別のアプリケーション・サーバー１０６である。アプリケーション・サーバーの例は例えば、ＷＯ９９／５７６６２にあり、そこではネットワークにおけるアプリケーション・プログラムがあり、このプログラムは各アプリケーションプログラムを使うコストを請求単位で決めている。このアプリケーション・プログラムは各アプリケーションプログラムと取引サーバーとの間のインターフエースを持っている。このアプリケーションは請求単位でコスト情報を送っている。
【００２３】
他方、代価請求（ビリング）は加入者のための値段調査と請求書発行を含んでいる。ＭＳＣ１０４から受けた代価請求情報もしくは支払細目データをつくる他のネットワーク・エレメントからデータ通信リンクを介して受けた代価請求情報に基づいてコール毎のコストをビリング・センター（ＢＣ）１０９で計算する。
【００２４】
大抵のＰＬＭＮネットワークがアクセス・ネットワークであるので、２人のユーザー（それらの間で通信もしくは取引が行われようとしている）が異なるネットワーク（図１のＰＬＭＮ１とＰＬＭＮ２）の加入者であることがある。一方のネットワークから別のネットワークへのコールにより生じるコストを彼らが定期的に比較し、そしてそれらのアカウントを清算することに大抵のオペレータが同意している。オペレータ間の請求書送付（ビリング）はアカウンティング１３０と呼ばれる。通常、このアカウンテイングはエンド・ユーザーに透明であって、そして２つのオペレータのビリング・センター１０９，１１９の間での概要情報のやり取りにより行われる。
【００２５】
本発明の概略のネットワーク・アーキテクチャを図２に示す。本発明の方法とシステムにおいて、第１ＰＬＭＮ加入者（ＭＴ）２０１は第２ＰＬＭＮ加入者（ＭＴ）２１１との金融取引を簡単にできる。これだけに限定するのではなく、第１の加入者もＰＬＭＮの加入者ではない他の者（どこかの金融取引システム２２２の依頼人もしくは外部の取引システム）との金融取引もできる。以下に２つの好ましい実施例を図２，３，４を参照して説明する。
【００２６】
第１の実施例においてＭＳＩＳＤＮ１を持つ第１の加入者は、少なくともサービス・コードと取引の代価受取人と取引の大きさとをを含む図３Ａの形の短いメッセージ４０１を送る。例としてのメッセージ（図３Ｂ）は、「ＰＡＹ  ＰＡＳＳＷＤ  ＭＩＩＳＤＮ２  １００∈」であって、宛先はネットワーク番号１７０００である。このメッセージはＭＳＣ２０４へＢＴＳ２０２とＢＳＣ２０３とを介して通常の仕方で、送られ、ＭＳＣ２０４はＳＭＳ４０２をＳＭＳＣ２０５へ送る。ＳＭＳＣはこのメッセージ４０３を、メッセージ４０３の中の第２宛先部の目的地宛先１７０００に基づいてアプリケーション・サーバー２０６へ送る。このアプリケーション・サーバーはメッセージ内のサービズ・コードＰＡＹを特定認識し、そしてＭＳＩＳＤＮ１、ＭＳＩＳＤＮ２、１００∈、ＰＡＳＳＷＤの４つのパラメータを持つ支払プログラム・ブロックへコントロール４０４を送る。明白にするということで、支払プログラム・ブロックは別個の支払アプリケーション・サーバー２０７にあるとする。
【００２７】
支払サーバーとは区別されるアプリケーション・サーバーが選択されていて、このようにして加入者は多くのサービス番号を覚えなくともよいが、正常なオントロオジー（ｏｎｔｏｌｏｇｙ）に一致するサービス指令を利用できる。アプリケーション・サ−バーはサービス指令の少なくとも部分、サービスのユーザー・インターフエースに対し一種のヒエラルキーを形成しているサービス・インターフエース言語、すなわち、サービスのフロント・エンドを解釈する。アプリケーション・サーバーはそのメッセージからパラメーターを抜き出し、そして正しいアプリケーションへそれらを通過させる。
【００２８】
別個のサーバーを選択する別の理由はそのアプリケーション・サーバーの負荷が、多分幾つかのネットワークへリクエストを送らなければならないサービスのため増加していると言うことである。アプリケーション・サーバーは多くの他のサービスと関係させられており、それら他のサービスに対してはそれらサービスの遂行に有害な遅れを回避するのに充分なリゾースをとっておかなければならない。
【００２９】
ＭＳＩＳＤＮ１が金融取引の発注者２０１であると言うことが支払いプログラム・ブロックにおいて先ず認められた。ここで次のことを仮定する。すなわち、第１加入者のホーム・オペレーターが詐欺を防止する既知の方法を使用しており、それによりＭＳＩＳＤＮ１を持つ加入者は取引を望んでいる真正の相手方であると確信できる。例えば、ＧＳＭシステムにおいて認証トリプレットを使ってＳＩＭカードがオリジナルであることを確かめる。来るべきＵＭＴＳシステムでは認証ベクトル（これは安全の向上を保証している）を使用する。加入者からの個人認識番号（ＰＩＮ）コードを要求する方法は加入者認証としてこの方面の技術で知られている。盗まれた携帯電話の場合の、もしくは正当加入者の携帯電話を権限のないユーザーが使用している場合の安全向上を保証するため、オリジナルの取引リクエスト・メッセージ４０１にパス・ワードを付けることができる。
【００３０】
ＭＳＩＳＤＮ１を使用している加入者が金融取引を遂行するのに足る相手であることを判定できないときがある。こう言う場合とは例えば、第１加入者がマイナーである、限定クレデイットのプリペイド加入者である、もしくは、その雇用者が電話料金を支払っている会社員であるというときである。換言すれば、その人達のためサービスをすることが許されない加入者が多くあると言うことである。新しいサービスをさせる（サービスの活性化）のに必要なステップを以下に詳細に述べる。
【００３１】
トラブルを回避するため新しいタイプの支払請求記録を持つ新しいサービス・クラスを第１オペレータのためＨＬＲへ加える。表１にＨＬＲに既に存在する支払請求記録の幾つかのタイプを示す。
【００３２】
表１：支払請求記録のタイプの例
携帯電話発端もしくは携帯電話終了コール
徘徊加入者へのコール
転送コール
補完サービス、補完サービスの利用、活性化ロケーション更新
ＨＬＲ質問
携帯電話発端もしくは終了のショート・メッセージ
ＰＳＴＮ発端もしくは終了コール
ＰＢＸ発端もしくは終了コール
未組織補完サービスデータ
インテリジェント・ネットワーク・データ
【００３３】
支払請求記録は電話サービス（表２）もしくは補完サービス（表３）に一致する。電話サービスは、端末から端末へのデータの流れを定めるサービスである。ネットワーク内で送られた情報は特定フォーマットを有し、そしてネットワークは適正にそれを解釈する。
【００３４】
表２：電話サービス
Ｔ１１＝電話通信
ＴＤ１＝アルテメイト（Ａｌｔｅｍａｔｅ）ライン・サービス
Ｔ２１＝ショート・メッセージＭＴ／ＰＰ
Ｔ２２＝ショート・メッセージＭＯ／ＰＰ
Ｔ６１＝ファクシミリ  グループとオルター（ａｌｔｅｒ）スピーチ
Ｔ６２＝自動ファクシミリ  グループ  ３
【００３５】
電話サービスに加えてＰＬＭＮは通常幾つかの補完サービス（表３）を有する。それらは基本サービスに新しい実用機能を加える。補完サービスのあるものはオプションである。
【００３６】
表３：  補完サービス
支払請求告知
コールホールド
コーリング・ラインＩＤ呈示
コーリング・ラインＩＤ限定
コール転送
プライベート・ナンバーリング・インデクッス
宛先変更インデックス
マルチ・パーティ・サービス
インテリジェント・ネットワーク・カテゴリ・キー
サービス  セット  インデックス
支払請求クラス
支払請求エリア
ホット・ビリング
コール限定サービス（…）
コール転送サービス（…）
コール完成サービス（…）
【００３７】
ＨＬＲネットワーク  エレメント２０８は、電話サービスとして、そして補完サービスとしての両方で、加入者に利用できるサービスについての情報を有する。ＨＬＲは（表３で…をつけた）サービス毎に特定の記録を有するが、（表３で…のついていない）回収記録内には少なくともフイールドを有しているのが好ましい。
【００３８】
ＰＬＭＮにおいて支払補完サービスを提供するためこのタイプの補完サービスはＨＬＲにおいて定義されていなければならない。どのようにしてサービスを実行できるか、そして制限できるか幾つかオプションがあるが、第１の必要なステップは特定の加入者に対してオペレーションをしてもいいのか、いけないのかをチェックすることである。ＨＬＲ２０８において、新しい支払補完サービスはＭＯＢＩＬＥ  ＯＲＩＧＩＮＡＴＥＤモード（携帯電話発端モード）もしくはＭＯＢＩＬＥ  ＴＥＲＭＩＮＡＴＥＤモード（携帯電話終了モード）で活性化される。当然ＭＯＢＩＬＥ  ＯＲＩＧＩＮＡＴＥＤモードはＭＯＢＩＬＥ  ＴＥＲＭＩＮＡＴＥＤ金融取引を許している。もしＭＯＢＩＬＥ  ＯＲＩＧＩＮＡＴＥＤ支払いが携帯電話発端支払へ文字通り限定されているならば、勿論新しいタイプ（これは両方向での取引を許すこととなろう）を決めることができる。
【００３９】
ＨＬＲ２０８が既存の支払補完サービスについての情報を含むや否や支払アプリケーションサーバー２０７はHLRへリクエスト“ＭＯ  ＰＡＹ  ＡＬＬＯＷＥＤ”（「携帯電話発端・支払い可」）４０５を送る。または、訪問されたＶＬＲ（これはＭＳＣへ接続されている）は通常ＨＬＲからサービス・データーを回収し、それ故そのリクエストをＶＬＲへ送れる。しかし、この例ではＨＬＲがその支払サービスとの関連で調べられなければならない。支払サービスが加入者と加入者のホームオペレ−ターとの間での同意に基づいているからである。勿論、オペレーター同士の間でサービス条件を決めることはできるが、この例ではホーム・オペレーターはユーザーが引き起こした不良負債のリスクを負うことになり、取引を許すべきか、否かを決定するのはいつも他ならぬホーム・オペレーターである。ＭＳＩＳＤＮ１に基づいてＨＬＲにコンタクトでき、またはその代わりとして、第１加入者のＩＭＳＩからできる。普通は、ＳＭＳＣ２０５もしくは、支払アプリケ−ション・サーバー２０７はＩＭＳＩを知らないが、ＭＳＩＳＤＮとＩＭＳＩとの間の関係を知っているので、これはその方法を実現する別のやり方である。
【００４０】
金融取引の大きさを決めているリクエストにおける別のパラメータ、もしくは取引の支払受取人、もしくは他の関連情報、例えば共通の金融システムにおける支払いと請求書とを関連付けるのに使用できる支払いの参照番号を支払アプリケーション・サーバー２０７がつける。
【００４１】
リクエストされた支払サービスを許すかどうかをＨＬＲが決める。もしあるパラメーターを供給されると、ＨＬＲはそれらをある既定の基準と比較する。もしもその分析の結果でサービスを許すことになると、ＨＬＲは了解４０６を支払アプリケーションサーバー２０７に送る。もしその反対の結果であると、不承知となって、支払アプリケーション・サーバーは取引処理を停止する。
【００４２】
その場合、支払アプリケーション・サーバーは受信加入者のＨＬＲ１８に、ＭＳＩＳＤＮ２を持つ受信加入者２１１が“ＭＯＢＩＬＥ  ＴＥＲＭＩＮＡＴＥＤ  ＴＲＡＮＳＡＣＴＩＯＮ”  （携帯電話終了取引）補完サービスを活かしてもらっているかどうかを尋ねる。ＨＬＲインクァイアリ（ｅｎｑｕｉｒｙ）４０７はメッセージ“ＭＴ  ＰＡＹ  ＡＬＬＯＷＥＤ”（携帯電話終端・支払い可）の形となる。肯定の結果の場合には了承４０８が送られる。否定の場合には返事は不承知となり、上に述べた不承知と同じ結果となる。
【００４３】
両方の了解があると、支払サーバーは利用している補完サービスに関連のメッセージを発生する。換言すれば、それは第１のMSC２０４への第１メッセージ４１０を発し、第１加入者のアカウントは請求さるべきであることを告げ、そして第２メッセージ４２０は第２ＭＳＣ２１４へ第２加入者のアカウントは再請求さるべきであることを告げる。
【００４４】
それから、第１ＭＳＣ２０４は支払請求細目記録４１１を発生し、そしてそれをＰＬＭネットワーク１のビリング・センター（ＢＣ）２０９へ送る。第２のＭＳＣ２１４は支払請求細目記録４２１を発生し、そしてそれをＰＬＭネットワーク２のビリング・センター（ＢＣ）２１９へ送る。
【００４５】
第１ＭＳＣ４１３と第２ＭＳＣ４２２とからの了承を受けた後、支払アプリケーション・サーバーは取引が完了したと結論する。それからそれは取引の発注者（ＭＴ）２０１へ、そして取引の受領者（ＭＴ）２１１へ、もしくは両者へ告知を送達する。この告知は短いメッセージ４３０，４４０の形であって、それは先ず、関連のＭＳＣを介して関連のＳＭＳＣ２０５と２１５への路（４３，４４１，４４２）をつけ、その関連のＳＭＳＣ２０５と２１５とは告知メッセージ４３２，４４３の蓄積と配送の手配をする。告知メッセージの伝達完了後ＳＭＳＣ２０５と２１５は告知メッセージの配送の成功を伝える承認を送る。
【００４６】
図５は支払アプリケーションのデーターベースのサンプル記録を示す。受領人ＲＥＣＩＰＩＥＮＴのＩＤがハンドルに置かれ、そのハンドルはショート・カットとして働いて取引の発注者はオリジナルのリクエスト４０１にすべての情報を入れる必要はなくなる。もしもそのシステムが他の金融取引システムに接続されていると、アカウントのタイプのインジケーターもある。アカウントのタイプは例えば、携帯電話加入者アカウント、プリペイド・アカウント、銀行口座もしくはクレジット・カンパニーのアカウントである。
【００４７】
支払アプリケーション・データーベースに何かの取引制限があることもある。それらの制限は単一の取引に対する単一の受領者に対して、もしくは累積取引に対する単一の受領者に対して設定でき、そしてある期間にわたっての取引の累積大きさを計算する特別の基準があることもある。便宜のため受領者の本当の名前がデーターベースへ加える。
【００４８】
もしも第２加入者が第１加入者に金のため接触すると、その金融取引は第２加入者へある金額を第１加入者が貸したことである。第２加入者は金融システムを介してリクエストを送ることができ、その金融システムはリクエストのためのログを有している。第１加入者は、取引システムへ取引メッセージを送ることにより取引を確認する必要はある。そのシステムは更に、取引種類、その金額の明細、取引日付、そして同意した利子を記述している表を備えている。
【００４９】
データーベースの内容を加入者がコントロールする最も簡単な方法はＷＷＷインターフエースを介してである。加入者は標準ブラウザを使用してその内容を編集できる。しかしながら、ＷＭＬインターフエースでデーターベースにアクセスできるのであれば、ＷＡＰブラウザを使って編集することができることに注目すべきであり、もしくはデータベースに標準質問言語インターフエースを装備してある既定のフォーマットの形の平文の短いメッセージのような何か他の手段により編集できるようにしてもよい。
【００５０】
ユーザーはデーターベースへユーザーの秘密のパスワードを呈示できる。先ずそのサービスを活性化して、システムは仮のランダムなパスワードを発生でき、そしてそれをユーザーへ送れるが、最も便利なのはユーザーが自分のため適当なパスワードを選択することである。データーベース内のパスワード・ファイルはシャドウ・パスワード・ファイルということがあり、それはＵＮＩＸ（登録商標）で解読できる。
【００５１】
又は、取引リクエストがオペレーション遂行に必要な情報を含んでいるならば、又はＳＭＳＣが上に述べた支払細目データーベースへアクセスできるならば、ＳＭＳＣはそれ自体で支払ＣＤＲを発生できる。
【００５２】
もし加入者が異なるネットワーク内で徘徊していると、その訪問先のＶＬＲもしくはＨＬＲによってもＣＤＲは発生されることができる。このことの不可欠な前提は、ＳＭＳＣ可能化ＣＤＲ生成の場合と同様に、オペレーターがあらかじめその処置に同意していることである。
【００５３】
もしも支払アプリケーションが携帯電話商業アプリケーションも受け入れるならば、支払アプリケーションは第１加入者から受けた情報に少なくとも部分的に基づいて所望のフォーマットの形でメッセージをつくり、そのメッセージはＳＭＳメッセージであるのが好ましく、そしてそれを加入者に送って、加入者がそれの秘密のパス・ワードを加えるようにするか、もしくは少なくとも確認リクエストを加入者に送るかする。秘密コード、個人認識番号を送ることによりもしくはそのメッセージに加入者のディジタル署名をすることによって加入者はその取引を確認できる。その署名はユーザーのパブリック・キーで確証でき、そのパブリック・キーには支払アプリケーションがアクセスできる。又は、その署名は認証センターによってチェックされることができ、この認証センターは例えば、少なくともＵＭＴＳネットワークにおいて利用できる。
【００５４】
一つのオプションは携帯電話端末に上記のデーター・ベースを含むクライエント・ソフトウエアを装備させることであり、そうして支払アプリケーションへ正確なフォーマットでメッセージを送れる。
【００５５】
支払アプリケーション・サーバーは他の外部経済アカウント・システムへのＴＣＰ／ＩＰ接続であるのが好ましい。サーバーはアプリケション・サーバー２０６へのＴＣＰ／ＩＰ接続も持てる。携帯電話端末から支払アプリケーション・サーバーへの路はＨＴＴＰもしくはＷＡＰのような標準のアプリケーション・インターフエース・プロトコルを利用できる。
【００５６】
ＭＯＢＩＬＥ  ＯＲＩＧＩＮＡＴＥＤ（携帯電話発端）支払請求チケットは明確な支払請求チケットである必要はなく、その場合発注側の電話料金を増すだけとなろう。しかし、システムを反転させて支払サービスが借りる／貸すサービスとなるようにできる。このようにすると、受領者が支払請求を受ける金融取引を発注側が受けるようになる。実際に、このことは同じ解決法を使って実施できるが、受領者はその取引を確認する必要があり、それは上述の同じ確認メッセージ・システム、パスワードもしくはＰＩＮアルゴリズムを使ってできる。
【００５７】
そのアーキテクチャはインテリジェント・ネットワーク・ビルディング・ユニットを使ってもつくることができ、その場合異なるオペレータ・ネットワーク間の相互間作動は新しいＣＡＭＥＬスタンダードに対応する解決法を使用して得られる。従って、ＭＳＣとサービス・コントロール・ポイント（ＳＣＰ）とにおいてインテリジェント・ネットワーク・アプリケーション（ＩＮＡＰ）インターフエースがある。ＩＮアーキテクチャがコール関係サービスによく適応しているので、上述の無接続解決法とポイント・ツー・ポイントのメッセージを利用する、例えば短いメッセージもしくはデーター・パケットを利用することが好ましい。
【００５８】
上に説明した例はＧＳＭシステムに関したものである。しかしながら、本発明の方法とシステムとはＧＳＭもしくはＵＭＴＳにおいて利用できるばかりでなく、同様のネットワーク要素を有する通信システムにおいても利用できる。
【００５９】
本発明の性質のため、最終結果は選択された技術によるばかりでなく、多くの技術を利用して本発明を実施できる。それ故、本発明は本文の記載に限定されるものではなく、請求項に記載の技術思想において解釈さるべきである。
【図面の簡単な説明】
【００６０】
【図１】２つのＰＬＭネットワークを有する従来のＰＬＭシステムを示す。
【図２】加入者と第２者との間の取引を可能とする簡単化したＰＬＭネットワークのアーキテクチャを示す。
【図３】取引を開始するユーザー発注指令の（あり得るものとしての）メッセージフォーマットを示す。
【図４】機能している取引サービスの信号略図を示す。
【図５】支払いデータベースにある記録の例である。
【図１】
2005502141.tif 000003
【図２】
2005502141.tif 000004
【図３Ａ】
2005502141.tif 000005
【図４】
2005502141.tif 000006
【図５】
2005502141.tif 000007
【国際公開パンフレット】
2005502141.tif 000008
2005502141.tif 000009
2005502141.tif 000010
2005502141.tif 000011
2005502141.tif 000012
2005502141.tif 000013
2005502141.tif 000014
2005502141.tif 000015
2005502141.tif 000016
2005502141.tif 000017
2005502141.tif 000018
2005502141.tif 000019
2005502141.tif 000020
2005502141.tif 000021
2005502141.tif 000022
2005502141.tif 000023
2005502141.tif 000024
2005502141.tif 000025
2005502141.tif 000026
2005502141.tif 000027
2005502141.tif 000028
2005502141.tif 000029
【国際調査報告】
2005502141.tif 000030
2005502141.tif 000031