JP4724721B2 - マルチアプリケーション・プロトコルにおいて、サービスプラットフォームがユーザー端末情報を獲得することを保証する方法 - Google Patents

Description

本発明は無線通信網におけるユーザー端末情報を獲得する方法に関する。本発明は特に、マルチアプリケーション・プロトコルにおいて、サービスプラットフォームがユーザー端末情報を獲得することを保証する方法に関し、通信技術の分野に属する。

移動ネットワークは、データサービスのフロー情報だけしか獲得することができない。一方で、例えば、ダウンロードに成功した数、メッセージの送信に成功した数等といったデータサービスのユーザー使用情報は、サービスプラットフォームだけからしか獲得することができない。従って、データサービス・プラットフォームに基づいた費用計算を行うためには、サービスプラットフォームがユーザー携帯番号を獲得する方法を考えなければならない。
従来、通常の場合は、移動網内に一つのプロキシサーバーを追加し、図１に示したように、端末とネットワークが接続され、ネットワークから端末にIPアドレスを与える時、プロキシサーバーにおいて、IPアドレスとユーザー携帯番号間の対応関係を構築する。端末からアプリケーション層のサービス要求を送信する時、まず、当該要求をプロキシサーバーに転送し、プロキシサーバーは、IPアドレスとユーザー携帯番号間の対応関係に従って、対応する携帯番号をアプリケーション・プロトコルのデータパケットの中に挿入してから、対応するサービスプラットフォームに転送する。これによって、サービスプラットフォームがユーザー携帯番号を獲得することを保証して、データサービスの費用を計算する。
データサービスのアプリケーション・プロトコルが多いので、プロキシサーバーが多種のアプリケーション・プロトコルを支持（サポート）できる場合に限り、ユーザー携帯番号を異なるアプリケーション・プロトコルのデータパケットの中に挿入することができる。新しいプロトコルが現れた場合、プロキシサーバーをアップグレードする必要があり、コストが高くなり、アップグレードが複雑で、工程周期が長いので、さらに改良しなければならない。

本発明が解決しようとする技術課題は、マルチアプリケーション・プロトコルにおいて、サービスプラットフォームがユーザー端末情報を獲得することを保証する方法を提供することにある。当該方法は、クライアントから通常のサービスを要求する前に、プロキシサーバーに汎用アプリケーション・プロトコル要求を送信する工程を追加することにより、プロキシサーバーがアップグレードされなくても、サービスプラットフォームがユーザー携帯番号を獲得することを保証することができ、新しいアプリケーション・プロトコルが現れる度にデバイスのアップグレードが頻繁に必要となるという問題点を避けることができる。

本発明において解決しようとする技術問題は、下記の技術手段により解決される。
マルチアプリケーション・プロトコルにおいて、サービスプラットフォームがユーザー端末情報を獲得することを保証する方法であって、ユーザー端末或いはユーザーのカード内に、クライアントサービス接続のためのソフトウェアが内装されて、上記クライアントサービス接続のためのソフトウェアは、サービス接続のためのユーザー・インターフェースを有して、移動端末が行う移動サービスの接続を検査及びコントロールすることができ、前記方法は、ユーザーが、移動端末でサービス要求を作成する段階と、移動端末から、移動ネットワークに、接続要求を送信する段階と、移動ネットワークが、接続要求を受信し、ユーザーにIPアドレスを与え、IPアドレスとユーザー携帯番号間の対応関係を構築する段階と、移動ネットワークが、IPアドレスとユーザー携帯番号間の対応関係を、プロキシサーバーに送信する段階と、プロキシサーバーが、IPアドレスとユーザー携帯番号間の対応関係を受信した後、移動ネットワークに応答情報を送信する段階と、移動ネットワークが、プロキシサーバーからの応答情報を受信してから、移動端末への接続に成功したとの応答情報を送信し、且つユーザーに与えたIPアドレスを移動端末に送信する段階と、移動端末が、移動ネットワークに汎用アプリケーション・プロトコル要求を送信する段階と、移動ネットワークが、受信された汎用アプリケーション・プロトコル要求をプロキシサーバーに転送する段階と、プロキシサーバーが、汎用アプリケーション・プロトコル要求を受信してから、IPアドレスと携帯番号間の対応関係、且つ対応する携帯番号を汎用アプリケーション・プロトコル要求のデータパケットの中に挿入する段階と、プロキシサーバーが、対応する携帯番号を含む汎用アプリケーション・プロトコル要求のデータパケットをサービスプラットフォームに転送する段階と、サービスプラットフォームが、汎用アプリケーション・プロトコル要求のパケットを受信してから、プロキシサーバーに応答情報を送信する段階と、プロキシサーバーが、移動ネットワークに応答情報を転送する段階と、移動ネットワークが、移動端末に応答情報を転送する段階と、移動端末が、応答情報を受信してから、接続が成功したかどうかを判断し、成功しなかった場合、ステップ7に戻り、成功した場合、次のステップを行う段階と、該段階で接続に成功した場合に、移動端末が、移動ネットワークにサービス要求を送信する送信段階と、移動ネットワークが、前記移動端末から前記送信段階により送信されたサービス要求を受信してから、該受信したサービス要求をサービスプラットフォームに転送する段階を備えることを特徴とする方法が提供される。
本発明において、クライアントから通常のサービスを要求する前に、プロキシサーバーに汎用アプリケーション・プロトコル要求を送信する工程を追加することにより、プロキシサーバーがアップグレードされなくても、サービスプラットフォームがユーザー携帯番号を獲得することを保証することができ、新しいアプリケーション・プロトコルが現れる度にデバイスのアップグレード及び改造が頻繁に必要となるという問題点を避けることができる。新しいアプリケーション・プロトコルが現れた時、プロキシサーバーをアップグレードすることなく、サービスプラットフォームにユーザー携帯番号を獲得させて費用を計算することにより、通信事業者の費用計算能力を向上し、費用計算コストを低減し、アプリケーション・プロトコルのアップグレードに対する適応性を高め、ネットワークの改造コストを低減し、端末管理の融通性を向上し、サービスのレベルを高め、ユーザーに受け容れられやすくすることが可能となる。

以下、図面及び実施例を併せて参照することにより、本発明に係る技術手段について更に説明する。
図２に示したように、本発明に係るシステムには、移動端末、無線基地局及び通信事業者ネットワークが含まれる。その中で、通信事業者ネットワークには、移動ネットワークデバイス、プロキシサーバー及びサービスプラットフォームが含まれ、移動ネットワークデバイスには、移動ゲートウェー等が含まれる。無線基地局は、ケーブルにより移動ネットワークデバイスと接続し、移動ネットワークデバイスは、ケーブルによりプロキシサーバー及びサービスプラットフォームと接続する。無線基地局は、移動端末に対して情報を無線送受信し、ケーブルにより、移動端末の情報を移動ネットワークデバイスに送信し、移動ネットワークデバイスは、ケーブルにより移動端末の情報をプロキシサーバー及びサービスプラットフォームに送信する。それと同時に、無線基地局は、プロキシサーバー及びサービスプラットフォームから移動ネットワークデバイスを通じて転送されてきた移動端末に対する応答情報を受信する。移動端末或いはユーザーのカード内に、クライアントサービス接続のためのソフトウェアが内装されており、クライアントサービス接続のためのソフトウェアは、サービス接続のためのユーザー・インターフェースを有して、移動端末が行う移動サービスの接続を判断及びコントロールすることができる。

本発明において、移動端末とサービスプラットフォームが、例えばSIPプロトコル、RTPプロトコル等の対応するサービス・アプリケーション・プロトコルを支持するほかに、例えばHTTPプロトコルといった汎用アプリケーション・プロトコルも支持しなければならない。しかし、プロキシサーバーは、例えばHTTPプロトコルといった汎用アプリケーション・プロトコルだけを支持すればいい。これにより、新しいサービスが増加することに従って、新しいサービスのアプリケーション・プロトコルを新たに支持させる必要がなく、新しいサービスのアプリケーション・プロトコルが現れることによるプロキシサーバーの頻繁なアップグレードを避けることができる。

本発明において、ユーザー端末或いはユーザーのカード内に、クライアントサービス接続のためのソフトウェアが内装される。クライアントサービス接続のためのソフトウェアは、サービス接続のためのユーザー・インターフェースを有し、移動端末が行う移動サービスの接続を判断及びコントロールすることができる。クライアントのプログラムは、サービス要求を送信する前に、プロキシサーバーに汎用アプリケーション・プロトコル要求を送信し、プロキシサーバーは、携帯番号を汎用アプリケーション・プロトコルのデータパケットの中に挿入してから、サービスプラットフォームに転送する。本発明において、クライアントから通常のサービスを要求する前に、プロキシサーバーに汎用アプリケーション・プロトコル要求を送信する工程を追加することにより、プロキシサーバーがアップグレードされなくても、サービスプラットフォームがユーザー携帯番号を獲得することを保証することができ、新しいアプリケーション・プロトコルが現れる度にデバイスのアップグレード及び改造が頻繁に必要となるという問題点を避けることができる。説明すべきことは、クライアントから通常のサービスを要求する前に、追加されたプロキシサーバーに汎用アプリケーション・プロトコル要求を送信することは、クライアントから自動的に行われるから、ユーザーの干渉を必要とせず、ユーザーに対して、過程及び手続きの不便を何ら招くことがない。

図３において、本発明に係る実施例の作業フローチャートを示した。マルチアプリケーション・プロトコルにおいて、サービスプラットフォームがユーザー端末情報を獲得することを保証する方法であって、下記のステップを含む。
ステップ1：ユーザーは、移動端末でサービス要求を作成する。
ステップ2：移動端末から、移動ネットワークに、接続要求を送信する。
ステップ3：移動ネットワークは、接続要求を受信してから、ユーザーにIPアドレスを与え、IPアドレスとユーザー携帯番号間の対応関係を構築する。
ステップ4：移動ネットワークは、IPアドレスとユーザー携帯番号間の対応関係を、プロキシサーバーに送信する。
ステップ5：プロキシサーバーは、IPアドレスとユーザー携帯番号間の対応関係を受信した後、移動ネットワークに応答情報を送信する。
ステップ6：移動ネットワークは、プロキシサーバーからの応答情報を受信してから、移動端末への接続に成功したとの応答情報を送信し、且つユーザーに与えたIPアドレスを移動端末に送信する。
ステップ7：移動端末は、移動ネットワークに汎用アプリケーション・プロトコル要求を送信し、それと同時に時間測定が開始される。もし、設定した待ち時間Ｔ内で、移動端末が、移動ネットワークから返送したサービスプラットフォームがユーザー携帯番号を成功裏に獲得したという応答を受信しなかった場合、移動端末は、既に汎用アプリケーション・プロトコル要求を送信した回数ｍと設定した最大送信回数Ｎを比べ、もし、ｍがＮより小さい場合、ステップ7を繰り返し、ｍがＮと等しい場合、接続失敗という情報をスクリーンに表示して、ユーザーに通知する。待ち時間Ｔは、移動端末により設定され、最大送信回数Ｎは、２回以上であり、移動端末により設定される。
ステップ8：移動ネットワークは、受信された汎用アプリケーション・プロトコル要求をプロキシサーバーに転送する。
ステップ9：プロキシサーバーは、汎用アプリケーション・プロトコル要求を受信してから、IPアドレスとユーザー携帯番号間の対応関係、且つ対応する携帯番号を汎用アプリケーション・プロトコル要求のデータパケットに挿入する。
ステップ10：プロキシサーバーは、対応する携帯番号を連れている汎用アプリケーション・プロトコル要求のデータパケットをサービスプラットフォームに転送する。
ステップ11：サービスプラットフォームは、汎用アプリケーション・プロトコル要求のデータパケットを受信してから、プロキシサーバーに応答情報を送信する。
ステップ12：プロキシサーバーは、移動ネットワークに応答情報を転送する。
ステップ13：移動ネットワークは、移動端末に応答情報を転送する。
ステップ14：移動端末は、応答を受信してから、接続が成功したかどうかを判断し、接続が成功した場合、次のステップを行う。接続が成功しなかった場合、既に汎用アプリケーション・プロトコル要求を送信した回数ｍと設定した最大送信回数Ｎを比べ、もし、ｍがＮより小さい場合、ステップ7を繰り返し、ｍがＮと等しい場合、接続失敗という情報をスクリーンに表示して、ユーザーに通知する。待ち時間Ｔは、移動端末により設定され、最大送信回数Ｎは、２回以上であり、移動端末により設定される。
ステップ15：移動端末は、移動ネットワークにサービス要求を送信する。
ステップ16：移動ネットワークは、サービス要求を受信してから、これをサービスプラットフォームに転送する。

例えば、あるユーザーから、移動チャットというサービス要求が送信された場合、当該サービスは、SIPプロトコルを採用するが、プロキシサーバーは、HTTPプロトコルのみを支持し、HTTPプロトコルしか解析できない。

移動チャットのクライアント・プログラムは、ユーザーから送信したサービス要求を受信した後、直ちに、端末により移動ネットワークに接続要求を送信する。移動ゲートウェーは、上記要求を受信した後、ユーザーにIPアドレスを与え、且つIPアドレスとユーザー携帯番号間の対応関係を構築し、且つ当該対応関係をプロキシサーバーに送信する。これにより、プロキシサーバーは、IPアドレスとユーザー携帯番号間の対応関係を獲得してから、移動ゲートウェーに応答を送信する。移動ゲートウェーは、応答を受信して、与えたIPアドレスを端末に返送する。

端末は、応答を受信した後、自動的にHTTP要求を送信し、プロキシサーバーは、要求を受信した後、HTTPプロトコルを解析し、当該IPアドレスに対応するユーザー携帯番号をHTTPプロトコル先頭のフィールドに挿入してから、当該HTTP要求を移動チャットのサービスプラットフォームに転送する。HTTPプロトコルは、汎用アプリケーション・プロトコルに属するので、サービスプラットフォームは、HTTPの先頭を解析することができ、ユーザー携帯番号を読み込むことができる。それにより、サービスプラットフォームは、ユーザー携帯番号に基づいてユーザーが使用したサービスに対する費用を計算することができる。

サービスプラットフォームは、上記操作を完成した後に、端末に応答を与える。端末は、応答を受信した後、接続が成功したかどうか判断し、成功しなかった場合、HTTP要求を新たに送信して、成功した応答が受信されて初めて、クライアント・プログラムはチャットサービスを開始し、SIPプロトコル要求を送信する。

最後に説明すべきことは、上記実施例は本発明に係る技術を説明するだけのものであり、限定するものではない。上記具体的な実施形態を挙げて、本発明を説明したが、当業者であれば、当該技術分野における技術常識及び本明細書の記載に基づき、本発明の技術形態に対して各種態様の変更或いは交替を行うことができ、またこれらが本発明の技術形態の要旨及び範囲を逸脱するものではなく、本発明の技術的範囲に属することは明白である。

従来技術に係る作業フローチャートである。 本発明に係るシステムの構造を示す図である。 本発明に係る実施例の作業フローチャートである。

Claims (7)

1. マルチアプリケーション・プロトコルにおいて、サービスプラットフォームがユーザー端末情報を獲得することを保証する方法であって、
   ユーザー端末或いはユーザーのカード内に、クライアントサービス接続のためのソフトウェアが内装され、前記クライアントサービス接続のためのソフトウェアは、サービス接続のためのユーザー・インターフェースを有して、移動端末が行う移動サービスの接続を検査及びコントロールすることができ、
   前記方法は、
   ステップ1：ユーザーが、移動端末でサービス要求を作成する段階と、
   ステップ2：移動端末から、移動ネットワークに、接続要求を送信する段階と、
   ステップ3：移動ネットワークが、接続要求を受信し、ユーザーにIPアドレスを与え、IPアドレスとユーザー携帯番号間の対応関係を構築する段階と、
   ステップ4：移動ネットワークが、IPアドレスとユーザー携帯番号間の対応関係を、プロキシサーバーに送信する段階と、
   ステップ5：プロキシサーバーが、IPアドレスとユーザー携帯番号間の対応関係を受信した後、移動ネットワークに応答情報を送信する段階と、
   ステップ6：移動ネットワークが、プロキシサーバーからの応答情報を受信してから、移動端末への接続に成功したとの応答情報を送信し、且つユーザーに与えたIPアドレスを移動端末に送信する段階と、
   ステップ7：移動端末が、移動ネットワークに汎用アプリケーション・プロトコル要求を送信する段階と、
   ステップ8：移動ネットワークが、受信された汎用アプリケーション・プロトコル要求をプロキシサーバーに転送する段階と、
   ステップ9：プロキシサーバーが、汎用アプリケーション・プロトコル要求を受信してから、IPアドレスと携帯番号間の対応関係、且つ対応する携帯番号を汎用アプリケーション・プロトコル要求のデータパケットの中に挿入する段階と、
   ステップ10：プロキシサーバーが、対応する携帯番号を含む汎用アプリケーション・プロトコル要求のデータパケットをサービスプラットフォームに転送する段階と、
   ステップ11：サービスプラットフォームが、汎用アプリケーション・プロトコル要求のパケットを受信してから、プロキシサーバーに応答情報を送信する段階と、
   ステップ12：プロキシサーバーが、移動ネットワークに応答情報を転送する段階と、
   ステップ13：移動ネットワークが、移動端末に応答情報を転送する段階と、
   ステップ14：移動端末が、応答情報を受信してから、接続に成功したかどうかを判断し、成功しなかった場合、ステップ7に戻り、成功した場合、次のステップを行う段階と、
   ステップ15：ステップ14で接続に成功した場合に、移動端末が、移動ネットワークにサービス要求を送信する送信段階と、
   ステップ16：移動ネットワークが、前記移動端末から前記送信段階により送信されたサービス要求を受信してから、該受信したサービス要求をサービスプラットフォームに転送する段階を備えることを特徴とする、マルチアプリケーション・プロトコルにおいてサービスプラットフォームがユーザー端末情報を獲得することを保証する方法。
2. 具体的に上記ステップ7において、移動端末が、移動ネットワークに汎用アプリケーション・プロトコル要求を送信すると同時に時間測定が開始され、もし、所定の待ち時間Ｔ内に、移動端末が、移動ネットワークから返送されたサービスプラットフォームがユーザー携帯番号を成功裏に獲得したという応答を受信しなかった場合、移動端末が既に汎用アプリケーション・プロトコル要求を送信した回数ｍと所定の最大送信回数Ｎを比べ、もし、ｍがＮより小さいとき、ステップ7を繰り返し、ｍがＮと等しいとき、接続失敗という情報をスクリーンに表示して、ユーザーに通知することを特徴とする請求項１に記載のマルチアプリケーション・プロトコルにおいてサービスプラットフォームがユーザー端末情報を獲得することを保証する方法。
3. 前記待ち時間Ｔは、移動端末により設定されることを特徴とする請求項２に記載のマルチアプリケーション・プロトコルにおいてサービスプラットフォームがユーザー端末情報を獲得することを保証する方法。
4. 前記最大送信回数Ｎは、２回以上で、移動端末により設定されることを特徴とする請求項２に記載のマルチアプリケーション・プロトコルにおいてサービスプラットフォームがユーザー端末情報を獲得することを保証する方法。
5. 具体的に前記ステップ14において、移動端末は、応答を受信してから、接続に成功したかどうか判断し、成功した場合、次のステップを行い、成功しなかった場合、移動端末は、既に汎用アプリケーション・プロトコル要求を送信した回数ｍと所定の最大送信回数Ｎを比べ、もし、ｍがＮより小さいとき、ステップ7に戻り、ｍがＮと等しいとき、接続失敗という情報をスクリーンに表示して、ユーザーに通知することを特徴とする請求項１乃至４の何れかに記載のマルチアプリケーション・プロトコルにおいてサービスプラットフォームがユーザー端末情報を獲得することを保証する方法。
6. 前記待ち時間Ｔは、移動端末により設定されることを特徴とする請求項５に記載のマルチアプリケーション・プロトコルにおいてサービスプラットフォームがユーザー端末情報を獲得することを保証する方法。
7. 前記最大送信回数Ｎは、２回以上で、移動端末により設定されることを特徴とする請求項５に記載のマルチアプリケーション・プロトコルにおいてサービスプラットフォームがユーザー端末情報を獲得することを保証する方法。

Images