JP4679056B2 - モバイル通信システムにおいて金融取引を行う方法とシステム - Google Patents

Description

本発明はモバイル通信システムにおいて金融取引を行う方法とシステムに係るものである。

携帯電話を使用して取引する必要性が、携帯電話が広がってくるにつれ最近では一層緊急のこととなった。普通の電話の機能も携帯電話の方に向かって発達している。

市場で携帯電話で支払うことによる解決策が幾つかある。典型的な例は０７００連続番号を有する自動販売機である。この自動販売機を使用する加入者は０７００番号にかけて自動販売機を作動させる、すなわちその加入者にフレッシュ・ドリンクを販売させる。携帯電話で支払いを受け付ける機械の他の日常的な例としては自動車の洗浄機もしくは駐車オートメートがある。これらの機械では取引を受ける人は支払いシステムに登録されている。ある解決策ではユーザーの携帯電話の送受話器をプログラムをし直さなければならないが、別の解決策ではサービスに対し支払うのに既定の番号に文書メッセージを送ればよいことになっている。

更に他の解決策では、短いメッセージを送る必要がある。この方面の既知の方法は特許文献１，２に説明されている。これら２つの文献はプリペイド・ネットワーク・アカウントに代金請求し、そして再請求するタスクを取り扱っている。

ＷＯ ００/１８１０６ ＷＯ ００/３３２６４

特許文献１では個々にコード化したクーポンの形でコール・タイムを購入する。自分のアカウントに再請求する加入者はサービス番号に短いメッセージを送る。サーバーはそのメッセージを分析し、そして送り手の携帯電話認識番号（ＭＳＩＳＤＮ）に含まれている加入者のアイデンティティに基づいてアカウントに再請求する。

特許文献２ではプリペイド・システムの形のアカウントに請求もしくは再請求する。ユーザーは組織化されていない追加サービスデーターメッセージを送る。このメッセージは請求もしくは再請求しようとする額、ユーザーの秘密コード、そして任意事項として、第２のＩＤを含んでいる。この第２のＩＤによりその額を第２のユーザーのプリペイドアカウントへ再請求できる。

上述の自動販売機の例が示すように、加入者が取引の受領者もしくは受取人を自由に選択することはできない。他の例では取引はクーポンで行わなければならないか、もしくはプリペイド環境（プリペイド・アカウントを持つ加入者だけを含んでいる）にオペレーションは限定されている。システムの融通が非常に効くというのではないので顧客の満足は少なく、そして事後支払い、ポスト・ペイドの加入者を取りこむことはできない。

オペレーターは大抵は電話請求書の形で、サービスを利用するユーザーに請求書をだすのが普通である。ユーザーはサービス番号へ短いメッセージを送ることにより例えばコーラー・グループ（ｃａｌｌｅｒ ｇｒｏｕｐ）アイコンもしくはリンギング・トーンへ加入でき、そのメッセージは所望のアイコンもしくはリンギング・トーンを指示している。受取人ＭＳＩＳＤＮを挿入することにより他の加入者へアイコンもしくはリンギング・トーンをオーダーすることもできる。オーダーを出した加入者は支払いを請求され、そして受取人へは余分のチャージは課せられないのが通常である。これらの例では代金請求はノーマルＧＳＭチャージングすなわちロゴもしくはリンギングトーンの送付に基づいている。代金請求チケットを生じるプロセスを開始するサービスを形成しているこのロゴもしくはリンギングトーンは、代金請求明細記録もしくは別個の請求項目のどちらかの形でＧＳＭ請求データーベースに入れられる。

上の例では利用できるサービスの選択によりユーザーは制限される。ユーザーは普通の通貨や他の同様の手段を使って取引をすることはできない。

普通のＧＳＭシステムにおいて融通性のある取引ができるようにすることは、もしも同じオペレータの他のユーザーと、異なるオペレータのユーザーと、そして様々に異なるシステムを採用している他の取引相手と多くの種類の異なる取引をしたいと思うポスト・ペイド（後払い）加入者を普通のＧＳＭシステムが含むのであれば、そのことは明らかに大きな挑戦である。ＰＬＭＮオペレータのインフラストラクチャ（構造基盤）を使うのではそのことは技術的に不可能とされてきたのが事実である。

本発明の目的は上記の問題に挑戦することであって、これを達成する方法、システム、そして取引サーバーは請求項１と１１にそれぞれ記載されている。

本発明は既存の携帯電話のネットワークのインフラを使って新しいサービスを提供する方法とシステムに係るものである。本発明の目的は、一つのオペレータの加入者間で、２つのオペレーターの加入者間でそしてＰＬＭＮオペレータの加入者と外部のパ−ティもしくは相手方との間での多様化した経済取引を可能とすることである。

安全取引の利点を保証できる。信頼できる加入者認証を使って、または許容取引に対する閾値設定により安全は得られる。

別の利点としては、加入者が金融取引をコントロールでき、その金融取引は加入者のアカウントで行われる。これはサービスの可能／不能の異種部分によって達成され、そしてその受取人により異なり、もしくは取引の種類により異なる会計限界もしくは金額限界の設定によって達成される。取引は２つのフォーマット、すなわち、携帯電話から出た取引と携帯電話で終端する取引とに分類される。単一のＰＬＭネットワーク内での取引、もしくは２つの比較できるＰＬＭネットワークのユーザー間での取引が両方のフォーマットにあり、それらのフォーマットは発注者と受取人で異なっている。

取引をしたいと思う人によってどの取引でも開始される。これはＰＬＭネットワークへメッセージを送ることによりなされ、そのメッセージは取引の受取人と取引の大きさを示している。

各金融取引は少なくとも一つのＰＬＭＮ加入者のアカウントに関係している。取引の大きさは２部数字であると言うのは、請求された取引額は、もし当事者のオペレーターがその取引に対して手数料を請求すると、受け取られる取引額と異なるからである。単一の取引について言えば、その請求された取引額は送り側（発注者）のアカウントへ請求される総額である。受け取られる取引額は受取人のアカウントへ再請求される総額である。ここで言う再請求（recharge）とは、アカウントにある額の金を置くことを言う。ＰＬＭＮ加入者のアカウントの請求もしくは再請求は、ＰＬＭＮネットワークの関連の代価請求センターもしくはビリング・センターへ請求明細記録（ＣＤＲ）を送ることによりなされる。

別の携帯電話のユーザーであるということのほかに、例えば銀行口座もしくは信用度の大きいクレジットカード・アカウントを有する個人または組織が相手であることもある。

ＰＬＭＮ代金請求において、通常オペレーターは代金請求のベースとして使えるすべてのイベントについてのデータを収集する。これらは請求イベントとして知られている。通常この動作態様ではコールについての情報だけを収集する。この代価請求においてどれだけ多くの加入者が請求されているかは未だ計算されていない。

図１は従来のＰＬＭネットワークを示しており、この例ではＧＳＭネットワークである。通常はコール、短いメッセージもしくは何か他のＰＬＭサービスを携帯電話端末（ＭＴ）１０１からベース・トランシーバ・ステーション（ＢＴＳ）１０２とベース・ステーション・コントローラ（ＢＳＣ）１０３とを介してモバイル・スイッチング・センター（ＭＳＣ）１０４へ送る。ＭＳＣは受取人へのコール、もしくはショート・メッセージ・センター（ＳＭＳＣ）１０５へのメッセージの発信源を辿る。ショート・メッセージ・センターは受取人へのメッセージを蓄え、そして配送する。ＰＬＭネットワークにおいては加入者は異なるネットワークを徘徊することがある。その場合にはホーム・ロケーション・レジスター（ＨＩＲ）１０８は加入者の現在のＭＳＣの情報である。更に詳しく言えば、ネットワークはビジター・ロケーション・レジスター（ＶＬＲ）を有し、それらは通常それぞれのＭＳＣへ直接接続されている。ＶＬＲはネットワークのエレメントであって、予約サービスについての、そして多分加入者認証を遂行する何らかの手段についての情報を含んでいる。通常この後のことは、加入者のホーム・ネットワーク・認証センターもしくはＨＬＲからのテスト・キーと署名をＶＬＲが要求するというような仕方で行われる。そのとき、ＶＬＲはキーを加入者端末へ送り、そして端末はそのキーに対して署名を送り返す。もしもその署名がＨＬＲから回収された署名と一致すれば、その加入者は正当加入者である。

そのネットワークがパケット・スイッチド・ネットワークであると、サーキット・スイッチド・トラヒックを扱うエレメントはそれらのパケット・オリエンテッドのカウンター・パートに置換えるのが通常である。この種類のネットワークにおいて、オペレーションの原理は上述のものと余り異なってはいない。例えば、ＧＰＲＳアーキテクチャにおいてパケットデータ・エレメントは一般にサポーティングＧＰＲＳサポート・ノード（ＳＧＳＮ）とゲートウエイＧＰＲＳサポート・ノード（ＧＧＳＮ）であり、前者はＭＳＣのパケット関連のタスクを行い、後者は外部ネットワークに向いているゲートウエイとして働く。

図１を参照する。代価請求データの作成を引き受けるネットワーク要素はＭＳＣ１０４、ＨＬＲ１０８、そしてそのネットワークに存在する別のアプリケーション・サーバー１０６である。アプリケーション・サーバーの例は例えば、ＷＯ９９／５７６６２にあり、そこではネットワークにおけるアプリケーション・プログラムがあり、このプログラムは各アプリケーションプログラムを使うコストを請求単位で決めている。このアプリケーション・プログラムは各アプリケーションプログラムと取引サーバーとの間のインターフエースを持っている。このアプリケーションは請求単位でコスト情報を送っている。

他方、代価請求（ビリング）は加入者のための値段調査と請求書発行を含んでいる。ＭＳＣ１０４から受けた代価請求情報もしくは支払細目データをつくる他のネットワーク・エレメントからデータ通信リンクを介して受けた代価請求情報に基づいてコール毎のコストをビリング・センター（ＢＣ）１０９で計算する。

大抵のＰＬＭＮネットワークがアクセス・ネットワークであるので、２人のユーザー（それらの間で通信もしくは取引が行われようとしている）が異なるネットワーク（図１のＰＬＭＮ１とＰＬＭＮ２）の加入者であることがある。一方のネットワークから別のネットワークへのコールにより生じるコストを彼らが定期的に比較し、そしてそれらのアカウントを清算することに大抵のオペレータが同意している。オペレータ間の請求書送付（ビリング）はアカウンティング１３０と呼ばれる。通常、このアカウンテイングはエンド・ユーザーに透明であって、そして２つのオペレータのビリング・センター１０９，１１９の間での概要情報のやり取りにより行われる。

本発明の概略のネットワーク・アーキテクチャを図２に示す。本発明の方法とシステムにおいて、第１ＰＬＭＮ加入者（ＭＴ）２０１は第２ＰＬＭＮ加入者（ＭＴ）２１１との金融取引を簡単にできる。これだけに限定するのではなく、第１の加入者もＰＬＭＮの加入者ではない他の者（どこかの金融取引システム２２２の依頼人もしくは外部の取引システム）との金融取引もできる。以下に２つの好ましい実施例を図２，３，４を参照して説明する。

第１の実施例においてＭＳＩＳＤＮ１を持つ第１の加入者は、少なくともサービス・コードと取引の代価受取人と取引の大きさとをを含む図３Ａの形の短いメッセージ４０１を送る。例としてのメッセージ（図３Ｂ）は、「ＰＡＹ ＰＡＳＳＷＤ ＭＩＩＳＤＮ２ １００∈」であって、宛先はネットワーク番号１７０００である。このメッセージはＭＳＣ２０４へＢＴＳ２０２とＢＳＣ２０３とを介して通常の仕方で、送られ、ＭＳＣ２０４はＳＭＳ４０２をＳＭＳＣ２０５へ送る。ＳＭＳＣはこのメッセージ４０３を、メッセージ４０３の中の第２宛先部の目的地宛先１７０００に基づいてアプリケーション・サーバー２０６へ送る。このアプリケーション・サーバーはメッセージ内のサービズ・コードＰＡＹを特定認識し、そしてＭＳＩＳＤＮ１、ＭＳＩＳＤＮ２、１００∈、ＰＡＳＳＷＤの４つのパラメータを持つ支払プログラム・ブロックへコントロール４０４を送る。明白にするということで、支払プログラム・ブロックは別個の支払アプリケーション・サーバー２０７にあるとする。

支払サーバーとは区別されるアプリケーション・サーバーが選択されていて、このようにして加入者は多くのサービス番号を覚えなくともよいが、正常なオントロオジー（ｏｎｔｏｌｏｇｙ）に一致するサービス指令を利用できる。アプリケーション・サ−バーはサービス指令の少なくとも部分、サービスのユーザー・インターフエースに対し一種のヒエラルキーを形成しているサービス・インターフエース言語、すなわち、サービスのフロント・エンドを解釈する。アプリケーション・サーバーはそのメッセージからパラメーターを抜き出し、そして正しいアプリケーションへそれらを通過させる。

別個のサーバーを選択する別の理由はそのアプリケーション・サーバーの負荷が、多分幾つかのネットワークへリクエストを送らなければならないサービスのため増加していると言うことである。アプリケーション・サーバーは多くの他のサービスと関係させられており、それら他のサービスに対してはそれらサービスの遂行に有害な遅れを回避するのに充分なリゾースをとっておかなければならない。

ＭＳＩＳＤＮ１が金融取引の発注者２０１であると言うことが支払いプログラム・ブロックにおいて先ず認められた。ここで次のことを仮定する。すなわち、第１加入者のホーム・オペレーターが詐欺を防止する既知の方法を使用しており、それによりＭＳＩＳＤＮ１を持つ加入者は取引を望んでいる真正の相手方であると確信できる。例えば、ＧＳＭシステムにおいて認証トリプレットを使ってＳＩＭカードがオリジナルであることを確かめる。来るべきＵＭＴＳシステムでは認証ベクトル（これは安全の向上を保証している）を使用する。加入者からの個人認識番号（ＰＩＮ）コードを要求する方法は加入者認証としてこの方面の技術で知られている。盗まれた携帯電話の場合の、もしくは正当加入者の携帯電話を権限のないユーザーが使用している場合の安全向上を保証するため、オリジナルの取引リクエスト・メッセージ４０１にパス・ワードを付けることができる。

ＭＳＩＳＤＮ１を使用している加入者が金融取引を遂行するのに足る相手であることを判定できないときがある。こう言う場合とは例えば、第１加入者がマイナーである、限定クレデイットのプリペイド加入者である、もしくは、その雇用者が電話料金を支払っている会社員であるというときである。換言すれば、その人達のためサービスをすることが許されない加入者が多くあると言うことである。新しいサービスをさせる（サービスの活性化）のに必要なステップを以下に詳細に述べる。

トラブルを回避するため新しいタイプの支払請求記録を持つ新しいサービス・クラスを第１オペレータのためＨＬＲへ加える。表１にＨＬＲに既に存在する支払請求記録の幾つかのタイプを示す。

表１：支払請求記録のタイプの例
携帯電話発端もしくは携帯電話終了コール
徘徊加入者へのコール
転送コール
補完サービス、補完サービスの利用、活性化ロケーション更新
ＨＬＲ質問
携帯電話発端もしくは終了のショート・メッセージ
ＰＳＴＮ発端もしくは終了コール
ＰＢＸ発端もしくは終了コール
未組織補完サービスデータ
インテリジェント・ネットワーク・データ

支払請求記録は電話サービス（表２）もしくは補完サービス（表３）に一致する。電話サービスは、端末から端末へのデータの流れを定めるサービスである。ネットワーク内で送られた情報は特定フォーマットを有し、そしてネットワークは適正にそれを解釈する。

表２：電話サービス
Ｔ１１＝電話通信
ＴＤ１＝アルテメイト（Ａｌｔｅｍａｔｅ）ライン・サービス
Ｔ２１＝ショート・メッセージＭＴ／ＰＰ
Ｔ２２＝ショート・メッセージＭＯ／ＰＰ
Ｔ６１＝ファクシミリ グループとオルター（ａｌｔｅｒ）スピーチ
Ｔ６２＝自動ファクシミリ グループ ３

電話サービスに加えてＰＬＭＮは通常幾つかの補完サービス（表３）を有する。それらは基本サービスに新しい実用機能を加える。補完サービスのあるものはオプションである。

表３： 補完サービス
支払請求告知
コールホールド
コーリング・ラインＩＤ呈示
コーリング・ラインＩＤ限定
コール転送
プライベート・ナンバーリング・インデクッス
宛先変更インデックス
マルチ・パーティ・サービス
インテリジェント・ネットワーク・カテゴリ・キー
サービス セット インデックス
支払請求クラス
支払請求エリア
ホット・ビリング
コール限定サービス（…）
コール転送サービス（…）
コール完成サービス（…）

ＨＬＲネットワーク エレメント２０８は、電話サービスとして、そして補完サービスとしての両方で、加入者に利用できるサービスについての情報を有する。ＨＬＲは（表３で…をつけた）サービス毎に特定の記録を有するが、（表３で…のついていない）回収記録内には少なくともフイールドを有しているのが好ましい。

ＰＬＭＮにおいて支払補完サービスを提供するためこのタイプの補完サービスはＨＬＲにおいて定義されていなければならない。どのようにしてサービスを実行できるか、そして制限できるか幾つかオプションがあるが、第１の必要なステップは特定の加入者に対してオペレーションをしてもいいのか、いけないのかをチェックすることである。ＨＬＲ２０８において、新しい支払補完サービスはＭＯＢＩＬＥ ＯＲＩＧＩＮＡＴＥＤモード（携帯電話発端モード）もしくはＭＯＢＩＬＥ ＴＥＲＭＩＮＡＴＥＤモード（携帯電話終了モード）で活性化される。当然ＭＯＢＩＬＥ ＯＲＩＧＩＮＡＴＥＤモードはＭＯＢＩＬＥ ＴＥＲＭＩＮＡＴＥＤ金融取引を許している。もしＭＯＢＩＬＥ ＯＲＩＧＩＮＡＴＥＤ支払いが携帯電話発端支払へ文字通り限定されているならば、勿論新しいタイプ（これは両方向での取引を許すこととなろう）を決めることができる。

ＨＬＲ２０８が既存の支払補完サービスについての情報を含むや否や支払アプリケーションサーバー２０７はHLRへリクエスト“ＭＯ ＰＡＹ ＡＬＬＯＷＥＤ”（「携帯電話発端・支払い可」）４０５を送る。または、訪問されたＶＬＲ（これはＭＳＣへ接続されている）は通常ＨＬＲからサービス・データーを回収し、それ故そのリクエストをＶＬＲへ送れる。しかし、この例ではＨＬＲがその支払サービスとの関連で調べられなければならない。支払サービスが加入者と加入者のホームオペレ−ターとの間での同意に基づいているからである。勿論、オペレーター同士の間でサービス条件を決めることはできるが、この例ではホーム・オペレーターはユーザーが引き起こした不良負債のリスクを負うことになり、取引を許すべきか、否かを決定するのはいつも他ならぬホーム・オペレーターである。ＭＳＩＳＤＮ１に基づいてＨＬＲにコンタクトでき、またはその代わりとして、第１加入者のＩＭＳＩからできる。普通は、ＳＭＳＣ２０５もしくは、支払アプリケ−ション・サーバー２０７はＩＭＳＩを知らないが、ＭＳＩＳＤＮとＩＭＳＩとの間の関係を知っているので、これはその方法を実現する別のやり方である。

金融取引の大きさを決めているリクエストにおける別のパラメータ、もしくは取引の支払受取人、もしくは他の関連情報、例えば共通の金融システムにおける支払いと請求書とを関連付けるのに使用できる支払いの参照番号を支払アプリケーション・サーバー２０７がつける。

リクエストされた支払サービスを許すかどうかをＨＬＲが決める。もしあるパラメーターを供給されると、ＨＬＲはそれらをある既定の基準と比較する。もしもその分析の結果でサービスを許すことになると、ＨＬＲは了解４０６を支払アプリケーションサーバー２０７に送る。もしその反対の結果であると、不承知となって、支払アプリケーション・サーバーは取引処理を停止する。

その場合、支払アプリケーション・サーバーは受信加入者のＨＬＲ１８に、ＭＳＩＳＤＮ２を持つ受信加入者２１１が“ＭＯＢＩＬＥ ＴＥＲＭＩＮＡＴＥＤ ＴＲＡＮＳＡＣＴＩＯＮ” （携帯電話終了取引）補完サービスを活かしてもらっているかどうかを尋ねる。ＨＬＲインクァイアリ（ｅｎｑｕｉｒｙ）４０７はメッセージ“ＭＴ ＰＡＹ ＡＬＬＯＷＥＤ”（携帯電話終端・支払い可）の形となる。肯定の結果の場合には了承４０８が送られる。否定の場合には返事は不承知となり、上に述べた不承知と同じ結果となる。

両方の了解があると、支払サーバーは利用している補完サービスに関連のメッセージを発生する。換言すれば、それは第１のMSC２０４への第１メッセージ４１０を発し、第１加入者のアカウントは請求さるべきであることを告げ、そして第２メッセージ４２０は第２ＭＳＣ２１４へ第２加入者のアカウントは再請求さるべきであることを告げる。

それから、第１ＭＳＣ２０４は支払請求細目記録４１１を発生し、そしてそれをＰＬＭネットワーク１のビリング・センター（ＢＣ）２０９へ送る。第２のＭＳＣ２１４は支払請求細目記録４２１を発生し、そしてそれをＰＬＭネットワーク２のビリング・センター（ＢＣ）２１９へ送る。

第１ＭＳＣ４１３と第２ＭＳＣ４２２とからの了承を受けた後、支払アプリケーション・サーバーは取引が完了したと結論する。それからそれは取引の発注者（ＭＴ）２０１へ、そして取引の受領者（ＭＴ）２１１へ、もしくは両者へ告知を送達する。この告知は短いメッセージ４３０，４４０の形であって、それは先ず、関連のＭＳＣを介して関連のＳＭＳＣ２０５と２１５への路（４３，４４１，４４２）をつけ、その関連のＳＭＳＣ２０５と２１５とは告知メッセージ４３２，４４３の蓄積と配送の手配をする。告知メッセージの伝達完了後ＳＭＳＣ２０５と２１５は告知メッセージの配送の成功を伝える承認を送る。

図５は支払アプリケーションのデーターベースのサンプル記録を示す。受領人ＲＥＣＩＰＩＥＮＴのＩＤがハンドルに置かれ、そのハンドルはショート・カットとして働いて取引の発注者はオリジナルのリクエスト４０１にすべての情報を入れる必要はなくなる。もしもそのシステムが他の金融取引システムに接続されていると、アカウントのタイプのインジケーターもある。アカウントのタイプは例えば、携帯電話加入者アカウント、プリペイド・アカウント、銀行口座もしくはクレジット・カンパニーのアカウントである。

支払アプリケーション・データーベースに何かの取引制限があることもある。それらの制限は単一の取引に対する単一の受領者に対して、もしくは累積取引に対する単一の受領者に対して設定でき、そしてある期間にわたっての取引の累積大きさを計算する特別の基準があることもある。便宜のため受領者の本当の名前がデーターベースへ加える。

もしも第２加入者が第１加入者に金のため接触すると、その金融取引は第２加入者へある金額を第１加入者が貸したことである。第２加入者は金融システムを介してリクエストを送ることができ、その金融システムはリクエストのためのログを有している。第１加入者は、取引システムへ取引メッセージを送ることにより取引を確認する必要はある。そのシステムは更に、取引種類、その金額の明細、取引日付、そして同意した利子を記述している表を備えている。

データーベースの内容を加入者がコントロールする最も簡単な方法はＷＷＷインターフエースを介してである。加入者は標準ブラウザを使用してその内容を編集できる。しかしながら、ＷＭＬインターフエースでデーターベースにアクセスできるのであれば、ＷＡＰブラウザを使って編集することができることに注目すべきであり、もしくはデータベースに標準質問言語インターフエースを装備してある既定のフォーマットの形の平文の短いメッセージのような何か他の手段により編集できるようにしてもよい。

ユーザーはデーターベースへユーザーの秘密のパスワードを呈示できる。先ずそのサービスを活性化して、システムは仮のランダムなパスワードを発生でき、そしてそれをユーザーへ送れるが、最も便利なのはユーザーが自分のため適当なパスワードを選択することである。データーベース内のパスワード・ファイルはシャドウ・パスワード・ファイルということがあり、それはＵＮＩＸ（登録商標）で解読できる。

又は、取引リクエストがオペレーション遂行に必要な情報を含んでいるならば、又はＳＭＳＣが上に述べた支払細目データーベースへアクセスできるならば、ＳＭＳＣはそれ自体で支払ＣＤＲを発生できる。

もし加入者が異なるネットワーク内で徘徊していると、その訪問先のＶＬＲもしくはＨＬＲによってもＣＤＲは発生されることができる。このことの不可欠な前提は、ＳＭＳＣ可能化ＣＤＲ生成の場合と同様に、オペレーターがあらかじめその処置に同意していることである。

もしも支払アプリケーションが携帯電話商業アプリケーションも受け入れるならば、支払アプリケーションは第１加入者から受けた情報に少なくとも部分的に基づいて所望のフォーマットの形でメッセージをつくり、そのメッセージはＳＭＳメッセージであるのが好ましく、そしてそれを加入者に送って、加入者がそれの秘密のパス・ワードを加えるようにするか、もしくは少なくとも確認リクエストを加入者に送るかする。秘密コード、個人認識番号を送ることによりもしくはそのメッセージに加入者のディジタル署名をすることによって加入者はその取引を確認できる。その署名はユーザーのパブリック・キーで確証でき、そのパブリック・キーには支払アプリケーションがアクセスできる。又は、その署名は認証センターによってチェックされることができ、この認証センターは例えば、少なくともＵＭＴＳネットワークにおいて利用できる。

一つのオプションは携帯電話端末に上記のデーター・ベースを含むクライエント・ソフトウエアを装備させることであり、そうして支払アプリケーションへ正確なフォーマットでメッセージを送れる。

支払アプリケーション・サーバーは他の外部経済アカウント・システムへのＴＣＰ／ＩＰ接続であるのが好ましい。サーバーはアプリケション・サーバー２０６へのＴＣＰ／ＩＰ接続も持てる。携帯電話端末から支払アプリケーション・サーバーへの路はＨＴＴＰもしくはＷＡＰのような標準のアプリケーション・インターフエース・プロトコルを利用できる。

ＭＯＢＩＬＥ ＯＲＩＧＩＮＡＴＥＤ（携帯電話発端）支払請求チケットは明確な支払請求チケットである必要はなく、その場合発注側の電話料金を増すだけとなろう。しかし、システムを反転させて支払サービスが借りる／貸すサービスとなるようにできる。このようにすると、受領者が支払請求を受ける金融取引を発注側が受けるようになる。実際に、このことは同じ解決法を使って実施できるが、受領者はその取引を確認する必要があり、それは上述の同じ確認メッセージ・システム、パスワードもしくはＰＩＮアルゴリズムを使ってできる。

そのアーキテクチャはインテリジェント・ネットワーク・ビルディング・ユニットを使ってもつくることができ、その場合異なるオペレータ・ネットワーク間の相互間作動は新しいＣＡＭＥＬスタンダードに対応する解決法を使用して得られる。従って、ＭＳＣとサービス・コントロール・ポイント（ＳＣＰ）とにおいてインテリジェント・ネットワーク・アプリケーション（ＩＮＡＰ）インターフエースがある。ＩＮアーキテクチャがコール関係サービスによく適応しているので、上述の無接続解決法とポイント・ツー・ポイントのメッセージを利用する、例えば短いメッセージもしくはデーター・パケットを利用することが好ましい。

上に説明した例はＧＳＭシステムに関したものである。しかしながら、本発明の方法とシステムとはＧＳＭもしくはＵＭＴＳにおいて利用できるばかりでなく、同様のネットワーク要素を有する通信システムにおいても利用できる。

本発明の性質のため、最終結果は選択された技術によるばかりでなく、多くの技術を利用して本発明を実施できる。それ故、本発明は本文の記載に限定されるものではなく、請求項に記載の技術思想において解釈さるべきである。

２つのＰＬＭネットワークを有する従来のＰＬＭシステムを示す。 加入者と第２者との間の取引を可能とする簡単化したＰＬＭネットワークのアーキテクチャを示す。 取引を開始するユーザー発注指令の（あり得るものとしての）メッセージフォーマットを示す。 機能している取引サービスの信号略図を示す。 支払いデータベースにある記録の例である。

Claims (15)

1. 第１の携帯電話ネットワーク端末（２０１）から第２の携帯電話ネットワーク端末（２１１）への取引を実行する方法において、
   前記第１の携帯電話ネットワーク端末から第１の取引メッセージを取引サーバー（２０７）へ送る段階と、
   前記取引サーバーが、前記第１の取引メッセージを受信する段階と、
   前記取引サーバーが、前記受信した第１の取引メッセージに基づいて、取引を継続すべきか否かを決定する段階と、
   取引を継続すべきとの前記決定に応答して、前記取引サーバーが、前記第１の携帯電話ネットワーク端末に関する取引実行に必要な情報を含む第２の取引メッセージ及び前記第２の携帯電話ネットワーク端末に関する取引実行に必要な情報を含む第３の取引メッセージを生成する段階と、
   前記取引サーバーが、前記第２の取引メッセージを前記第１の携帯電話ネットワーク端末に関連付けられた第１のモバイル・スイッチング・センターへ送信する段階と、
   前記取引サーバーが、前記第３の取引メッセージを前記第２の携帯電話ネットワーク端末に関連付けられた第２のモバイル・スイッチング・センターへ送信する段階と、
   前記第２の取引メッセージの受信に応答して、前記第１のモバイル・スイッチング・センターが、前記第１の携帯電話ネットワーク端末に関して取引を清算するために、第１の課金メッセージを生成して、第１の携帯電話ネットワークのビリング・センターに送信し、前記取引サーバーに確認メッセージ送信する段階と、
   前記第３の取引メッセージの受信に応答して、前記第２のモバイル・スイッチング・センターが、前記第２の携帯電話ネットワーク端末に関して取引を清算するために、第２の課金メッセージを生成して、第２の携帯電話ネットワークビリング・センターへ送信し、前記取引サーバーに確認メッセージを送信する段階と、
   前記取引サーバーが、両モバイル・スイッチング・センターからの前記確認メッセージの受信に基づいて、両携帯電話ネットワーク端末間で取引が清算されたことを確認する段階と、
   を備えることを特徴とする方法。
2. 前記取引サーバーが、前記受信した第１の取引メッセージに基づいて、前記第１の携帯電話ネットワーク端末を識別する識別子を含む問合せメッセージ（４０５）を携帯電話ネットワークの加入者データーベースへ送信する段階と、
   前記取引サーバーが、前記データーベースからの応答（４０６）を受信する段階と、
   前記取引サーバーが、前記応答に基づいて取引を継続すべきか否かを決定する段階と、を更に備える請求項１に記載の方法。
3. 前記取引サーバーは、取引を監視する段階と、
   前記取引サーバーは、前記監視に応じて、前記第１の携帯電話ネットワーク端末へ取引の結果を示す通知メッセージを送信する段階と、
   を更に備える請求項１に記載の方法。
4. データーベースに取引の受領者に関しての情報を蓄積する段階と、
   前記蓄積情報を利用して、前記第３の取引メッセージのための前記第２の携帯電話ネットワーク端末の識別子部分を生成する段階と、
   を更に備える請求項１に記載の方法。
5. 前記第１の取引メッセージがデーターベースに蓄積されている請求項１に記載の方法。
6. 前記第１の取引メッセージがショートメッセージである請求項１に記載の方法。
7. 支払補完サービスがアクチベートされる第１及び第２の携帯電話ネットワーク端末のそれぞれのために携帯電話ネットワーク加入者データーベースから肯定応答メッセージを前記取引サーバーが受信することに応答して前記第２（４１０）及び第３（４２０）の取引メッセージは生成される請求項１に記載の方法。
8. 第１の携帯電話ネットワーク端末（２０１）から第２の携帯電話ネットワーク端末（２１１）への取引を実行するシステムにおいて、
   第１の取引メッセージ（４０４）を取引サーバー（２０７）において受け取る第１のメッセージ受信手段と、
   前記受信された第１の取引メッセージに基づいて、取引を継続すべきか否かを決定する選択手段と、
   取引を継続すべきであるとする前記決定に応答し、第１の携帯電話ネットワーク端末に関する取引実行に必要な情報を含む第２の取引メッセージを発生する第１のメッセージ発生手段と、
   取引を継続すべきであるとする前記決定に応答して、前記第２の携帯電話ネットワーク端末に関する取引実行に必要な情報を含む第３の取引メッセージを発生する第２のメッセージ発生手段と、
   前記第１の携帯電話ネットワーク端末に関連する第１のモバイル・スイッチング・センターへ前記取引サーバーから前記第２の取引メッセージを送信する第１の取引メッセージ送信手段を含む第１のメッセージ送信手段と、
   前記第２の携帯電話ネットワーク端末に関連する第２のモバイル・スイッチング・センターへ前記取引サーバーから前記第３の取引メッセージを送信する第２の取引メッセージ送信手段を含む前記第２のメッセージ送信手段を備え、
   前記システムは更に、
   前記第１の携帯電話ネットワーク端末に関連する取引を清算するための第１の課金メッセージ（４１１）を前記第１のモバイル・スイッチング・センターにおいて生成する第１の課金生成手段と、
   前記第２の携帯電話ネットワーク端末に関連する取引を清算するための第２の課金メッセージ（４２１）を前記第２のモバイル・スイッチング・センターにおいて生成する第２の課金生成手段と、
   第１の携帯電話ネットワークビリング・センターへ前記第１のモバイル・スイッチング・センターから前記第１の課金メッセージを送信する第１の課金送信手段と、
   第２の携帯電話ネットワークビリング・センターへ前記第２のモバイル・スイッチング・センターから前記第１の課金メッセージを送信する第２の課金送信手段と、
   前記取引サーバーへ前記第１のモバイル・スイッチング・センターから確認メッセージ（４１３）を送信する第１の確認手段と、
   前記取引サーバーへ前記第２のモバイル・スイッチング・センターから確認メッセージ（４２３）を送信する第２の確認手段と、
   両モバイル・スイッチング・センターから前記取引サーバーが確認メッセージを受信することに基づいて、両携帯電話ネットワーク端末の間で取引が清算されたことを確認する第３の確認手段と、を備えることを特徴とするシステム。
9. 前記受信された第１の取引メッセージに基づいて、前記第１の携帯電話ネットワーク端末を識別する識別子を含む問合せメッセージを携帯電話ネットワークの加入者データーベースへ送信する第３のメッセージ送信手段と、
   前記の第３の受信手段に応答して、前記のデーターベースからの応答メッセージを受信する第２のメッセージ受信手段と、
   前記受信された応答メッセージに基づいて、取引を継続すべきか否かを決定する選択手段と、
   を更に備える請求項８に記載のシステム。
10. 取引を監視する監視手段と、
    前記監視手段に応答して、前記の第１の携帯電話ネットワーク端末へ取引の結果を示す通知メッセージを送る第３のメッセージ送信手段と
    を更に備える請求項８に記載のシステム。
11. 取引の受領者についての情報を蓄積する蓄積手段と、
    前記蓄積手段に応答して、前記の情報を検索する検索手段と、
    前記検索手段と前記の処理手段に応答して、前記の蓄積された情報を利用して、前記の第３の取引メッセージのために前記第２の携帯電話ネットワーク端末の識別子を生成する生成手段と、
    を更に備える請求項８に記載のシステム。
12. 前記の第１の受信手段が受けた前記の第１の取引メッセージがショートメッセージである請求項８に記載のシステム。
13. 前記取引サーバー（２０７）は更に、前記取引が完了したことを示す、前記第１の携帯電話ネットワーク端末（２０１）及び／または前記第２の携帯電話ネットワーク端末（２１１）へ送信する通知メッセージ（４３２、４４３）を生じさせる通知送信手段を備える請求項８に記載のシステム。
14. 支払補完サービスがアクチベートされた前記第１及び第２の携帯電話ネットワーク端末のそれぞれのために携帯電話加入者データーベースから肯定応答メッセージを要求するための肯定応答処理手段を更に備え、
    前記第１及び第２の取引メッセージ生成手段は、前記肯定応答処理手段に応答して前記第１及び第２の取引メッセージを生成する請求項８に記載のシステム。
15. 第１の携帯電話ネットワーク端末（２０１）から第２の携帯電話ネットワーク端末（２１１）への取引を実行するための取引サーバー（２０７）であって、
    第１の取引メッセージ（４０４）を受信する第１の受信手段と、
    前記第１の携帯電話ネットワーク端末に関連する前記取引を実行するために要求される情報を含む第２の取引メッセージを生成する第２の取引メッセージ生成手段と、
    前記第２の携帯電話ネットワーク端末に関連する前記取引を実行するために要求される情報を含む第３の取引メッセージを生成する第３の取引メッセージ生成手段と、
    前記第２の取引メッセージを前記取引サーバーから前記第１の携帯電話ネットワーク端末に関連付けられる第１のモバイル・スイッチング・センターへ送信する第１の取引メッセージ送信手段を含む第１のメッセージ送信手段であって、前記第１の携帯電話ネットワーク端末に関連して前記取引を清算するために、第１の課金メッセージは前記第１のモバイル・スイッチング・センターにおいて生成される、第１のメッセージ送信手段と、
    前記第３の取引メッセージを前記取引サーバーから前記第２の携帯電話ネットワーク端末に関連付けられる第２のモバイル・スイッチング・センターへ送信する第２の取引メッセージ送信手段を含む第２のメッセージ送信手段であって、前記第２の携帯電話ネットワーク端末に関連して前記取引を清算するために、第２の課金メッセージは前記第２のモバイル・スイッチング・センターにおいて生成される、第２のメッセージ送信手段と、
    確認メッセージ（４１３）を前記第１のモバイル・スイッチング・センターから受信する第１の確認受信手段と、
    確認メッセージ（４２３）を前記第２のモバイル・スイッチング・センターから受信する第２の確認受信手段と、
    前記取引サーバーが両モバイル・スイッチング・センターから確認メッセージを受信することに基づいて、両携帯電話ネットワーク端末間で取引が清算されたことを確認する第３の確認手段と、
    を備える取引サーバー。

Images