データ伝送方法及び端末
【課題】本発明によれば、端末においてより速くＷｅｂデータを伝送する効果を達成する。
【解決手段】本発明はデータ伝送方法及び端末を開示し、当該方法は、通信プロセッサがアプリケーションプロセッサからの接続確立リクエストを受信するステップと、通信プロセッサがアプリケーションプロセッサに接続確立成功を指示するための応答を送信し、そして応答に応じてアプリケーションプロセッサの多重モジュールに多重チャネルを割り当てることを指示するステップと、通信プロセッサの多重モジュールが多重チャネルを割り当てるステップと、通信プロセッサが多重チャネルを介してアプリケーションプロセッサとデータ伝送を行うステップとを含む。
【解決手段】本発明はデータ伝送方法及び端末を開示し、当該方法は、通信プロセッサがアプリケーションプロセッサからの接続確立リクエストを受信するステップと、通信プロセッサがアプリケーションプロセッサに接続確立成功を指示するための応答を送信し、そして応答に応じてアプリケーションプロセッサの多重モジュールに多重チャネルを割り当てることを指示するステップと、通信プロセッサの多重モジュールが多重チャネルを割り当てるステップと、通信プロセッサが多重チャネルを介してアプリケーションプロセッサとデータ伝送を行うステップとを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信分野に関し、具体的には、データ伝送方法及び端末に関する。
【背景技術】
【０００２】
グローバルモバイル通信システム連合（Ｇｌｏｂａｌ Ｓｙｓｔｅｍｓ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ａｓｓｏｃｉａｔｉｏｎ：ＧＳＭＡ）が発展型近距離通信技術（ｅｎｈａｎｃｅｄ Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ，ｅＮＦＣ）をサポートするキャリー電話に対する要求に応じて、携帯電話においてスマートカードウェブサーバー（Ｓｍａｒｔ Ｃａｒｄ Ｗｅｂ Ｓｅｒｖｅｒ：ＳＣＷＳ）機能を実現する必要がある。
【０００３】
スマートフォンの枠組みは一般的に１つのアプリケーションプロセッサ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｃｅｓｓｏｒ：ＡＰ）、及び１つ又は複数の通信プロセッサ（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｐｒｏｃｅｓｓｏｒ：ＣＰ）を含む。ＡＰはブラウザ、伝送制御プロトコル／インターネットプロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：ＴＣＰ／ＩＰ）のプロトコルスタック、ワイファイ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ：ＷｉＦｉ）、ブルートゥース等を含む携帯電話のアプリケーションプログラム等を処理することに用い、１つ又は複数のＣＰは無線周波数信号処理、通信プロトコルスタック処理、及び汎用集積回路カード（Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ：ＵＩＣＣ）インターフェースとの情報対話処理等を含む通信インターネット無線インターフェースに関する業務を担う。このようなモードにおいて、ブラウザ、ｊａｖａプログラム及びその他のアプリケーションプログラムとＵＩＣＣインターフェースとはそれぞれ異なるプロセッサにあり、機能の実現は２つのプロセッサ間のチャネルを通す必要があり、各機能の実現は単一のプロセッサ端末より複雑である。
【０００４】
現在、関連技術において、複数のプロセッサ移動端末でＳＣＷＳの実現スキームを開示した。図１は関連技術に係るＡＴコマンドを介してＵＩＣＣ内蔵ＷＥＢサーバー端末にアクセスするアーキテクチャであり、図１に示すように、ネットワークブラウザがＴＣＰ／ＩＰプロトコルを介して代理サービスモジュールにリクエストを送信し、ＡＴモジュールが当該リクエストをＡＴコマンドを介してＣＰに送信し、そしてベアラー非依存プロトコル（Ｂｅａｒｅｒ Ｉｎｄｅｐｅｎｄｅｎｔ Ｐｒｏｔｏｃｏｌ：ＢＩＰ）ゲートウェイを介してＵＩＣＣに送信し、これによって、ＡＰとＣＰとの間のシグナリングとデータともＡＴコマンドを用いて伝送することである。ＡＴコマンドメカニズムはデータ端末装置（Ｄａｔａ Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ：ＤＴＥと略称、即ちアプリケーションプロセッサ）とデータ通信装置（Ｄａｔａ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｅｑｕｉｐｍｅｎｔ：ＤＣＥ）との間に応用され、ＡＴコマンドとＡＴ応答とのペアでの実現メカニズムを用いる必要があるが、ネットワークブラウザとＷＥＢサーバーとの間のデータ伝送が必ずしもそれぞれに対応するものではなく、且つ複数のリクエスト応答データが並行伝送される可能性があり、そして、ＡＴコマンドが実現される場合に一般的には、単一のコマンドのサイズに対して所定の制限があり、ビッグデータが複数のコマンドに分割されて伝送され、並行伝送リクエストがシリアルになって処理される必要がある。データ伝送量がより大きいため、ＡＴコマンド伝送の速度がより遅いことであって、これによって、ユーザーがＵＩＣＣにおけるウェブを閲覧する時に表示がより遅い。
【０００５】
関連技術においてＡＴコマンドでＳＣＷＳを実現してウェブを閲覧する時に表示がより遅い問題に対して、現時点、まだ有効的な解決策が提出されてない。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
関連技術においてＡＴコマンドでＳＣＷＳを実現してウェブを閲覧する時に表示がより遅い問題に対して本発明を提出し、このため、本発明の主な目的は、上記問題を解決するために、改良されたデータ伝送スキームを提出した。
【課題を解決するための手段】
【０００７】
上記目的を実現するために、本発明の１つの側面に応じて、データ伝送方法が提出された。
【０００８】
本発明に係るデータ伝送方法は、通信プロセッサがアプリケーションプロセッサからの接続確立リクエストを受信するステップと、通信プロセッサがアプリケーションプロセッサへ接続確立成功を指示するための応答を送信し、かつ応答に応じてアプリケーションプロセッサの多重モジュールが多重チャネルを割り当てることを指示するステップと、通信プロセッサの多重モジュールが多重チャネルを割り当てるステップと、通信プロセッサが多重チャネルを介してアプリケーションプロセッサとデータ伝送を行うステップとを含む。
【０００９】
好ましくは、応答に応じてアプリケーションプロセッサの多重モジュールが多重チャネルを割り当てることを指示するステップは、アプリケーションプロセッサが応答を受信した後、アプリケーションプロセッサの多重モジュールが多重チャネルを割り当てることを含む。
【００１０】
好ましくは、通信プロセッサが接続確立リクエストを受信した後、上記方法は、さらに、通信プロセッサが接続確立リクエストに応じて汎用集積回路カードＵＩＣＣに接続確立を指示することに用いる通知メッセージを送信することを含み、通信プロセッサがＵＩＣＣからのオープンチャネルリクエストを受信し、通信プロセッサがＵＩＣＣとの間のチャネルをオープンする。
【００１１】
好ましくは、通信プロセッサが多重チャネルを介してアプリケーションプロセッサとデータ伝送を行うステップは、通信プロセッサが多重チャネルを介してアプリケーションプロセッサからの所定フォーマットのデータを受信し、そしてデータをベアラー非依存プロトコルＢＩＰフォーマットのデータに変換するステップと、通信プロセッサがＢＩＰフォーマットのデータをチャネルを介してＵＩＣＣに送信するステップとを含む。
【００１２】
好ましくは、通信プロセッサが多重チャネルを介してアプリケーションプロセッサとデータ伝送を行うステップは、通信プロセッサがチャネルを介してＵＩＣＣからのＢＩＰフォーマットのデータを受信し、そしてＢＩＰフォーマットのデータを所定フォーマットのデータに変換するステップと、通信プロセッサが所定フォーマットのデータをアプリケーションプロセッサに送信するステップとを含む。
【００１３】
好ましくは、通信プロセッサが多重チャネルを介してアプリケーションプロセッサとデータ伝送を行うステップが終了した後、上記方法は、通信プロセッサがＵＩＣＣからのクローズチャネルリクエストを受信してチャネルをクローズするステップと、通信プロセッサが多重チャネルをクローズし、そして、アプリケーションプロセッサがコマンドに応じて多重チャネルをクローズするように、アプリケーションプロセッサに接続が既にクローズしたコマンドを送信するステップとを更に含む。
【００１４】
上記目的を達成するように、本発明のもう１つの側面に応じて、端末が提供された。
【００１５】
本発明の端末によれば、アプリケーションプロセッサ及び通信プロセッサを含み、アプリケーションプロセッサは代理サービスモジュール及び第１の多重モジュールを含み、通信処理モジュールはＢＩＰゲートウェイ及び第２の多重モジュールを含み、ＢＩＰゲートウェイが代理サービスモジュールからの接続確立リクエストを受信することに用いられ、ＢＩＰゲートウェイが代理サービスモジュールに接続確立成功を指示するための応答を送信し、そして多重チャネルを割り当てることを第１の多重モジュールに通知することに更に用いられ、代理サービスモジュールが応答を受信し、そして多重チャネルを割り当てることを第２の多重モジュールに通知することに用いられ、ＢＩＰゲートウェイが多重チャネルを介して代理サービスモジュールとデータ伝送を行うことに更に用いられる。
【００１６】
好ましくは、ＢＩＰゲートウェイはＵＩＣＣに確立接続を指示することに用いる通知メッセージを送信し、そしてＵＩＣＣからのオープンチャネルリクエストを受信した後、ＵＩＣＣとの間のチャネルをオープンすることに更に用いられる。
【００１７】
好ましくは、ＢＩＰゲートウェイは代理サービスモジュールからの所定フォーマットのデータをＢＩＰフォーマットのデータに変換し、そしてＢＩＰフォーマットのデータをチャネルを介してＵＩＣＣに送信することに更に用いられ、ＢＩＰゲートウェイはＵＩＣＣからのＢＩＰフォーマットのデータを所定フォーマットのデータに変換し、そして変換後の所定フォーマットのデータを多重チャネルを介して代理サービスモジュールに送信することに更に用いられる。
【００１８】
好ましくは、ＢＩＰゲートウェイはＵＩＣＣからのクローズチャネルリクエストを受信し、そしてチャネルをクローズすることに更に用いられ、ＢＩＰゲートウェイは多重チャネルをクローズすることを第２の多重モジュールに通知し、そして代理サービスモジュールに接続が既にクローズしたコマンドを送信することに更に用いられ、代理サービスモジュールは接続が既にクローズしたコマンドを受信した後、多重チャネルをクローズすることを第１の多重モジュールに通知することに更に用いられる。
【発明の効果】
【００１９】
本発明によれば、端末にＭＵＸ（ｍｕｌｔｉｐｌｅｘｅｒ）モジュールを追加し、そしてＭＵＸモジュールを介してデータを伝送することで、ＡＴコマンドでＳＣＷＳを実現してウェブを閲覧する時に表示がより遅い問題を解決し、さらに、端末においてＷｅｂデータをより速く伝送する効果を達成する。
【図面の簡単な説明】
【００２０】
【図１】関連技術に係るＡＴコマンドを介してＵＩＣＣ内蔵ＷＥＢサーバー端末にアクセスするアーキテクチャである。
【図２】本発明の実施例に係るデータ伝送方法のフローチャートである。
【図３】本発明の実施例に係る端末のシステムアーキテクチャである。
【図４】本発明の実施例に係るＭＵＸモジュールを介してアプリケーションプロセッサと通信プロセッサとを接続してＵＩＣＣ Ｗｅｂサーバーの端末にアクセスするアーキテクチャである。
【図５】本発明の実施例に係るＵＩＣＣ内蔵ＷＥＢサーバーにアクセスするフローチャートである。
【図６】本発明の実施例に係る端末のアーキテクチャである。
【発明を実施するための形態】
【００２１】
関連技術においてＡＴコマンドでＳＣＷＳを実現してウェブを閲覧する時に表示がより遅い問題に対して、本発明の実施例において、改良されたデータ伝送スキームが提出された。当該スキームの処理原則は、通信プロセッサがＡＴコマンドを介してアプリケーションプロセッサからの接続確立リクエストを受信し、通信プロセッサがアプリケーションプロセッサに接続確立成功を指示するためのＡＴ応答を送信し、そしてＡＴ応答に応じてアプリケーションプロセッサのＭＵＸモジュールがＭＵＸチャネルを割り当てることを指示し、通信プロセッサのＭＵＸモジュールがＭＵＸチャネルを割り当て、通信プロセッサがＭＵＸチャネルを介してアプリケーションプロセッサとデータ伝送を行う。
【００２２】
なお、矛盾しない場合に、本発明における実施例及び実施例における特徴が相互に組合わせられる。以下、図面を参照しながら、実施例とともに本発明を詳しく説明する。
【００２３】
以下の実施例において、図面のフローチャートに示したステップは、例えばコンピュータで実行可能なコマンド群のコンピュータシステムで実行してよい、且つ、フローチャートにロジック順序を示したが、ある場合に、これに異なる順序で示される又は説明されるステップを実行してもよい。
【００２４】
本発明の実施例に応じて、データ伝送方法が提出された。図２は本発明の実施例に係るデータ伝送方法のフローチャートである。図２に示すように、当該方法は、以下のようなステップＳ２０２〜ステップＳ２０８を含む。
【００２５】
ステップＳ２０２において、通信プロセッサがアプリケーションプロセッサからの接続確立リクエストを受信する。
【００２６】
ステップＳ２０４において、通信プロセッサがアプリケーションプロセッサに接続確立成功を指示するためのＡＴ応答を送信し、そしてＡＴ応答に応じてアプリケーションプロセッサのＭＵＸモジュールがＭＵＸチャネルを割り当てることを指示し、即ち、アプリケーションプロセッサがＡＴ応答を受信した後、アプリケーションプロセッサのＭＵＸモジュールがＭＵＸチャネルを割り当てる。
【００２７】
ステップＳ２０６において、通信プロセッサのＭＵＸモジュールがＭＵＸチャネルを割り当てる。
【００２８】
ステップＳ２０８において、通信プロセッサがＭＵＸチャネルを介してアプリケーションプロセッサとデータ伝送を行う。
【００２９】
ステップＳ２０２の後、通信プロセッサが接続確立リクエストに応じてＵＩＣＣに通知メッセージを送信し、ＵＩＣＣが通知メッセージを受信した後、通信プロセッサにオープンチャネルリクエストを送信し、そして、通信プロセッサがＵＩＣＣとの間のチャネルをオープンする。
【００３０】
通信プロセッサはアプリケーションプロセッサとＵＩＣＣとの間にデータ変換を行う必要がある。通信プロセッサがＭＵＸチャネルを介してアプリケーションプロセッサからの所定フォーマットのデータを受信し、そしてデータをＢＩＰフォーマットのデータに変換することと、通信プロセッサがＢＩＰフォーマットのデータをＵＩＣＣとの間のチャネルを介してＵＩＣＣに送信することと、及び、通信プロセッサがＵＩＣＣとの間のチャネルを介してＵＩＣＣからのＢＩＰフォーマットのデータを受信し、そしてＢＩＰフォーマットのデータを所定フォーマットのデータに変換することと、通信プロセッサが所定フォーマットのデータをアプリケーションプロセッサに送信することとを含む。
【００３１】
データ伝送が完了した後、既に確立した接続をクローズする必要があり、当該プロセスは、以下のようなステップを含む。
【００３２】
ステップＡにおいて、通信プロセッサがＵＩＣＣからのクローズチャネルリクエストを受信し、そしてチャネルをクローズする。
【００３３】
ステップＢにおいて、通信プロセッサがＭＵＸチャネルをクローズし、そしてアプリケーションプロセッサがＡＴコマンドに応じてＭＵＸチャネルをクローズするように、アプリケーションプロセッサに接続が既にクローズしたＡＴコマンドを送信する。
【００３４】
ステップＣにおいて、アプリケーションプロセッサがＡＴコマンドを受信した後、ＭＵＸチャネルをクローズする。
【００３５】
以下、実例に合わせて本発明の実施例の実現過程を詳しく説明する。
【００３６】
図３は本発明の実施例に係る端末のシステムアーキテクチャである。図３に示すように、当該移動端末はアプリケーションプロセッサ、１つ又は複数の通信プロセッサ、ＵＩＣＣ及びプロセッサ間のチャネルを含み、その中、アプリケーションプロセッサは、ネットワークブラウザ、ＴＣＰ／ＩＰプロトコルスタック、代理サービスモジュール、プロセッサ間通信モジュール（ＡＴコマンドモジュール及び／又は多重ＭＵＸモジュールでよい）を含み、それぞれの通信プロセッサは、ＴＣＰ／ＩＰプロトコルスタック（当該モジュールが選択可能）、ＢＩＰゲートウェイとＢＩＰモジュール、及びプロセッサ間通信モジュール（ＡＴコマンドモジュール及び／又はＭＵＸモジュールでよい）を含む。
【００３７】
なお、プロセッサ間の物理チャネルは複数の種類があってもよい。以下の実例はシリアルポートを例とするが、シリアルポートに限らない。
【００３８】
実例１
図４は本発明の実施例に係るＭＵＸモジュールを介してアプリケーションプロセッサと通信プロセッサとを接続してＵＩＣＣ Ｗｅｂサーバーの端末にアクセスするアーキテクチャである。図４に示すように、当該端末はデータを伝送する場合にＭＵＸモジュールを用いた。当該実例において、アプリケーションプロセッサと１つの通信プロセッサとの接続を例として説明する。アプリケーションプロセッサは、ネットワークブラウザ、ＴＣＰ／ＩＰプロトコルスタック、代理サービスモジュール（代理サーバーに位置する）、ＡＴコマンドモジュール、多重モジュールを含み、通信プロセッサは、ＡＴコマンドモジュール、ＭＵＸモジュール、ＢＩＰゲートウェイ及びＢＩＰモジュールを含み、ＢＩＰゲートウェイがＢＩＰモジュールの機能を含んでよい。
【００３９】
図５は本発明の実施例に係るＵＩＣＣ内蔵ＷＥＢサーバーにアクセスするフローチャートである。以下、図４に示す構造の上で、図５のプロセスを詳しく説明する。図５に示すように、当該プロセスは２つの部分に分けれてよい、即ち、第１の部分はＡＴコマンドを介してＡＰとＣＰとの間の伝送チャネルを確立／閉鎖することであり、具体的に、以下のステップ１、ステップ４に対応する。第２の部分はＭＵＸチャネルを介してＡＰとＣＰとの間にデータ伝送を行うことであり、具体的に、以下のステップ２、ステップ３対応する。図５を参照しながら、ステップ１〜ステップ４を詳しく説明する。
【００４０】
ステップ１、ネットワークブラウザとＵＩＣＣとが接続を確立する。当該ステップは具体的に以下のステップＳ５０１〜ステップＳ５０５を含み、当該ステップを詳しく説明する。
【００４１】
ステップＳ５０１、ユーザーがネットワークブラウザでｈｔｔｐ：／／１２７．０．０．１：ｐｏｒｔ（その中、ｐｏｒｔがＵＩＣＣのあるサービスのインターフェースに対応し、デフォルトインターフェース８０を用いる場合、インターフェース番号を入力しなくてもよい、ｈｔｔｐ：／／１２７．０．０．１を直接入力する）を入力し、ユーザーがブラウザに予めに設定した、ｈｔｔｐ：／／１２７．０．０．１：ｐｏｒｔに指向するブックマークを用いて上記アドレスを手動入力することを取り替えてもよく、また、ＵＩＣＣカードＳＴＫ（ＳＩＭ Ｔｏｏｌ Ｋｉｔ）メニューにおける呼ぶブラウザにアクセスすることを介してＳＣＷＳのメニューにアクセスして、以上のステップを完了してもよい。そして、ネットワークブラウザはＴＣＰ／ＩＰプロトコルスタックを介してＴＣＰ／ＩＰプロトコルで伝送する接続リクエストを送信する。
【００４２】
ステップＳ５０２、代理サービスモジュールが接続リクエストを受信してブラウザとの接続を確立する。同時に、代理サービスモジュールが接続リクエストをＡＴコマンドで伝送する接続リクエストに変換し、％ＷＥＢＯＰＣＨ ＝ ｐｏｒｔをＣＰに送信し、接続確立をリクエストする。
【００４３】
ステップＳ５０３、ＢＩＰゲートウェイがＡＴコマンドで伝送した接続リクエストをＢＩＰプロトコルで伝送する接続リクエストに変換し、ＣＰ側のＢＩＰモジュールがＵＩＣＣとの間の接続を確立することをリクエストする。ＢＩＰゲートウェイがローカル接続エンベロープメッセージ（Ｅｎｖｅｌｏｐｅ（ｌｏｃａｌ ｃｏｎｎｅｃｔｉｎｇ））を介してＵＩＣＣに接続イベントがあることを通知する。
【００４４】
ステップＳ５０４、ＵＩＣＣが通知を受信した後、ＢＩＰゲートウェイにオープンチャネルリクエスト（Ｆｅｔｃｈ：ｏｐｅｎ ｃｈａｎｎｅｌ）を送信する。
【００４５】
ステップＳ５０５、ＢＩＰゲートウェイがオープンチャネルリクエストを受信した後、ＵＩＣＣにチャネル識別子（ｃｈａｎｎｅｌ ＩＤ）をキャリーする接続成功メッセージ（Ｔｅｒｍｉｎａｌ ｒｅｓｐｏｎｓｅ）を返す。そしてＭＵＸチャネルを割り当てるコマンドをＣＰ側のＭＵＸモジュールに送信する。同時に、代理サービスモジュールに接続確立成功ＡＴ応答（ＯＫ）を返す。代理サービスモジュールがＭＵＸチャネルを割り当てるコマンドをＡＰ側のＭＵＸモジュールに送信する。ＡＰとＣＰとの間にデータ伝送するためのＭＵＸチャネルを確立することが完了する。
【００４６】
ステップ２、ネットワークブラウザがリクエストデータをＵＩＣＣに送信する。当該ステップは具体的に以下のステップＳ５０６〜ステップＳ５１０を含み、以下、当該ステップを詳しく説明する。
【００４７】
ステップＳ５０６、ネットワークブラウザがＴＣＰ／ＩＰプロトコルで伝送するアクセスデータを代理サービスモジュールに送信する。
【００４８】
ステップＳ５０７、代理サービスモジュールがＴＣＰ／ＩＰプロトコルで伝送するアクセスデータをＰｏｒｔ＋ｄａｔａのフォーマットに変換し、ＭＵＸチャネルを介してＣＰ側のＢＩＰゲートウェイに送信する。ＢＩＰゲートウェイがアクセスデータをＢＩＰプロトコルがサポートするフォーマットに変換し、そしてＵＩＣＣに送信を準備する。
【００４９】
ステップＳ５０８、ＢＩＰゲートウェイが、チャネルデータが使用可能なエンベロープメッセージ（Ｅｎｖｅｌｏｐｅ（ｃｈａｎｎｅｌ ｄａｔａ ａｖａｉｌａｂｌｅ））を送信してＵＩＣＣにアクセスデータの送信があることを通知する。
【００５０】
ステップＳ５０９、ＵＩＣＣがデータ受信リクエスト（Ｆｅｔｃｈ：ｒｅｃｅｉｖｅ ｄａｔａ）を返してアクセスデータの受信を要求する。
【００５１】
ステップＳ５１０、ＢＩＰゲートウェイが端末応答（Ｔｅｒｍｉｎａｌ ｒｅｓｐｏｎｓｅ（ｄａｔａ））を介してＵＩＣＣにアクセスデータを送信する。
【００５２】
ステップ３、ＵＩＣＣが応答データをネットワークブラウザに送信する。当該ステップは具体的に以下のステップＳ５１１〜ステップＳ５１３を含み、以下、当該ステップを詳しく説明する。
【００５３】
ステップＳ５１１、ＵＩＣＣがＢＩＰプロトコルで伝送する応答データをＢＩＰゲートウェイに送信し、即ち、ＵＩＣＣがデータ送信リクエスト（Ｆｅｔｃｈ：ｓｅｎｄ ｄａｔａ）を介してＢＩＰゲートウェイに応答データを送信する。
【００５４】
ステップＳ５１２、ＢＩＰゲートウェイが応答データを受信した後、端末応答（Ｔｅｒｍｉｎａｌ ｒｅｓｐｏｎｓｅ）を介して既に応答データを受信したことをＵＩＣＣに通知し、そしてＰｏｒｔ＋ｄａｔａのフォーマットでＭＵＸチャネルを介して応答データをＡＰ側代理サービスモジュールに伝送する。
【００５５】
ステップＳ５１３、代理サービスモジュールが応答データを受信した後、ＡＴコマンドで伝送する応答データをＴＣＰ／ＩＰプロトコルで伝送する応答データに変換し、そしてＴＣＰ／ＩＰプロトコルスタックでネットワークブラウザに返し、ブラウザがハイパーテキスト伝送プロトコル（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：ＨＴＴＰ）データパケットを解析した後、ブラウザに表示する。
【００５６】
ＵＩＣＣにおいてすべてのデータが送信されているまで、以上のステップ２、ステップ３は数回に繰り返す可能性がある。
【００５７】
ステップ４、接続をクローズする。当該ステップは具体的に以下のステップＳ５１４〜ステップＳ５１７を含み、以下、当該ステップを詳しく説明する。
【００５８】
ステップＳ５１４、ＵＩＣＣからＢＩＰゲートウェイへクローズチャネルリクエストを送信し、そしてチャネル識別子（Ｆｅｔｃｈ：ｃｌｏｓｅ ｃｈａｎｎｅｌ（ｃｈａｎｎｅｌ ＩＤ））をキャリーし、チャネルをクローズすることをリクエストする。
【００５９】
ステップＳ５１５、ＢＩＰゲートウェイが接続をクローズした後、ＵＩＣＣへ端末応答（Ｔｅｒｍｉｎａｌ ｒｅｓｐｏｎｓｅ（ｃｈａｎｎｅｌ ｓｔａｔｕｓ：ｌｉｎｋ ｎｏｔ ｅｓｔａｂｌｉｓｈｅｄ））を送信することを介してチャネルをクローズすることを確認し、そしてＣＰ側ＭＵＸモジュールにＭＵＸチャネルをクローズするコマンドを送信し、同時に、代理サービスモジュールにＡＴコマンド、ＡＴ＋ＷＥＢＣＩＳ＝＜ｐｏｒｔ＞を送信して、今回の接続が既にクローズしたことをＡＰに通知する。
【００６０】
ステップＳ５１６、代理サービスモジュールがＴＣＰ／ＩＰプロトコルスタックを介してクローズ接続メッセージをネットワークブラウザに返し、そしてＡＰ側ＭＵＸモジュールにクローズＭＵＸチャネルコマンドを送信し、ＭＵＸチャネルのクローズを完了する。
【００６１】
ステップＳ５１７、ブラウザがクローズ応答を送信する。
【００６２】
上記実施例によれば、ＭＵＸチャネルを介してＡＰとＣＰとの間にデータ伝送を行い、伝送速度がもっと速く、もっと安定になり、同時に、複数のリクエストのデータを同時に伝送することもサポートできる。
【００６３】
本発明の実施例によれば、端末が提供された、アプリケーションプロセッサ６２及び通信プロセッサ６４を含み、図６は本発明の実施例に係る端末のアーキテクチャであり、図６に示すように、アプリケーションプロセッサ６２は代理サービスモジュール６２２及び第１のＭＵＸモジュール６２４を含み、通信プロセッサ６４はＢＩＰゲートウェイ６４２及び第２のＭＵＸモジュール６４４を含む。以下、それぞれのモジュールの機能を詳しく説明する。
【００６４】
ＢＩＰゲートウェイ６４２は代理サービスモジュール６２２からの接続確立リクエストを受信し、ＢＩＰゲートウェイ６４２は代理サービスモジュール６２２に接続確立成功を指示するための応答を送信し、そして第１のＭＵＸモジュール６２４にＭＵＸチャネルを割り当てることを通知することに更に用いられ、代理サービスモジュール６２２は応答を受信し、そして第２のＭＵＸモジュール６４４にＭＵＸチャネルを割り当てることを通知することに更に用いられ、ＢＩＰゲートウェイ６４２はＭＵＸチャネルを介して代理サービスモジュール６２２とデータ伝送を行うことに更に用いられる。
【００６５】
ＢＩＰゲートウェイ６４２はＵＩＣＣに確立接続を指示することに用いる通知メッセージを送信し、そしてＵＩＣＣからのオープンチャネルリクエストを受信した後、ＵＩＣＣとの間のチャネルをオープンすることに更に用いられる。
【００６６】
ＢＩＰゲートウェイ６４２は代理サービスモジュール６２２からの所定フォーマットのデータをＢＩＰフォーマットのデータに変換し、そしてＢＩＰフォーマットのデータをチャネルを介してＵＩＣＣに送信することに更に用いられ、ＢＩＰゲートウェイ６４２はＵＩＣＣからのＢＩＰフォーマットのデータを所定フォーマットのデータに変換し、そして変換後の所定フォーマットのデータをＭＵＸチャネルを介して代理サービスモジュール６２２に送信することに更に用いられる。
【００６７】
ＢＩＰゲートウェイ６４２はＵＩＣＣからのクローズチャネルリクエストを受信し、チャネルをクローズし、そして第２のＭＵＸモジュール６４４にＭＵＸチャネルをクローズすることを通知し、代理サービスモジュール６２２に接続が既にクローズしたコマンドを送信することに更に用いられ、代理サービスモジュール６２２は接続が既にクローズしたコマンドを受信した後、第１のＭＵＸモジュール６２４にＭＵＸチャネルをクローズすることを通知することに更に用いられる。
【００６８】
以上の記載によれば、本発明は以下のような技術的な効果を達成することが分かった。
【００６９】
速度が速い、ＷＥＢサービスのビッグデータ量伝送に適応する。ＡＴコマンドメカニズムはデータ端末装置とデータ通信装置との間に設計され、ＡＴコマンドとＡＴ応答とのペアでの実現メカニズムを用い、しかし、ブラウザとＷＥＢサーバーとの間のデータ伝送が必ずしもそれぞれに対応するものではなく、且つＡＴコマンドが実現される場合に一般的には、単一のコマンドのサイズに対して所定の制限があり、ビッグデータが複数のコマンドに分割されて伝送される必要がある。多重モジュールがデータ伝送することはデータストリームのモードで伝送するため、データのサイズ及びフォーマットの制限がなく、それぞれのＭＵＸのチャネルが相互に単独であり、様々なメモリエリアとフロー制御があり、様々なチャネルで同時に伝送することをサポートする。これによって、ＭＵＸチャネルを介してデータ伝送を行うことは、伝送速度を大きく向上させられ、データ伝送の信頼性を増加し、そして同時にパラレルリクエストのデータ伝送が完了できる。
【００７０】
明らかに、本分野の当業者が了解すべきなのは、上記本発明の各モジュール又は各ステップが汎用の計算装置で実現できて、それらが単一の計算装置に集中してもいい、或いは複数の計算する装置で組み立てるネットワークに配布されてもいい、選択的に、それらが、計算装置で実行可能のプログラムコードで実現できて、だから、それらを記憶装置に記憶され計算装置で実行してもいい、或いは、それらをそれぞれ各集積回路モジュールを作成してもいい、それらの中に複数のモジュール又はステップを単一の集積回路モジュールを作成して実現してもいい。そうしたら、本発明がいかなる特定されたハードウェアとソフトウェアの組み合わせに制限されない。
【００７１】
以上は、本発明の最適的な実施例に過ぎなく、本発明を制限せず、本分野の当業者に対して、本発明が各種類の変更と変化がある。本発明の主旨精神と原則以内に、いかなる改修、同等入れ替わり、改良等が、本発明の保護範囲以内に含まれるべきである。
【技術分野】
【０００１】
本発明は、通信分野に関し、具体的には、データ伝送方法及び端末に関する。
【背景技術】
【０００２】
グローバルモバイル通信システム連合（Ｇｌｏｂａｌ Ｓｙｓｔｅｍｓ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ａｓｓｏｃｉａｔｉｏｎ：ＧＳＭＡ）が発展型近距離通信技術（ｅｎｈａｎｃｅｄ Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ，ｅＮＦＣ）をサポートするキャリー電話に対する要求に応じて、携帯電話においてスマートカードウェブサーバー（Ｓｍａｒｔ Ｃａｒｄ Ｗｅｂ Ｓｅｒｖｅｒ：ＳＣＷＳ）機能を実現する必要がある。
【０００３】
スマートフォンの枠組みは一般的に１つのアプリケーションプロセッサ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｃｅｓｓｏｒ：ＡＰ）、及び１つ又は複数の通信プロセッサ（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｐｒｏｃｅｓｓｏｒ：ＣＰ）を含む。ＡＰはブラウザ、伝送制御プロトコル／インターネットプロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：ＴＣＰ／ＩＰ）のプロトコルスタック、ワイファイ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ：ＷｉＦｉ）、ブルートゥース等を含む携帯電話のアプリケーションプログラム等を処理することに用い、１つ又は複数のＣＰは無線周波数信号処理、通信プロトコルスタック処理、及び汎用集積回路カード（Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ：ＵＩＣＣ）インターフェースとの情報対話処理等を含む通信インターネット無線インターフェースに関する業務を担う。このようなモードにおいて、ブラウザ、ｊａｖａプログラム及びその他のアプリケーションプログラムとＵＩＣＣインターフェースとはそれぞれ異なるプロセッサにあり、機能の実現は２つのプロセッサ間のチャネルを通す必要があり、各機能の実現は単一のプロセッサ端末より複雑である。
【０００４】
現在、関連技術において、複数のプロセッサ移動端末でＳＣＷＳの実現スキームを開示した。図１は関連技術に係るＡＴコマンドを介してＵＩＣＣ内蔵ＷＥＢサーバー端末にアクセスするアーキテクチャであり、図１に示すように、ネットワークブラウザがＴＣＰ／ＩＰプロトコルを介して代理サービスモジュールにリクエストを送信し、ＡＴモジュールが当該リクエストをＡＴコマンドを介してＣＰに送信し、そしてベアラー非依存プロトコル（Ｂｅａｒｅｒ Ｉｎｄｅｐｅｎｄｅｎｔ Ｐｒｏｔｏｃｏｌ：ＢＩＰ）ゲートウェイを介してＵＩＣＣに送信し、これによって、ＡＰとＣＰとの間のシグナリングとデータともＡＴコマンドを用いて伝送することである。ＡＴコマンドメカニズムはデータ端末装置（Ｄａｔａ Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ：ＤＴＥと略称、即ちアプリケーションプロセッサ）とデータ通信装置（Ｄａｔａ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｅｑｕｉｐｍｅｎｔ：ＤＣＥ）との間に応用され、ＡＴコマンドとＡＴ応答とのペアでの実現メカニズムを用いる必要があるが、ネットワークブラウザとＷＥＢサーバーとの間のデータ伝送が必ずしもそれぞれに対応するものではなく、且つ複数のリクエスト応答データが並行伝送される可能性があり、そして、ＡＴコマンドが実現される場合に一般的には、単一のコマンドのサイズに対して所定の制限があり、ビッグデータが複数のコマンドに分割されて伝送され、並行伝送リクエストがシリアルになって処理される必要がある。データ伝送量がより大きいため、ＡＴコマンド伝送の速度がより遅いことであって、これによって、ユーザーがＵＩＣＣにおけるウェブを閲覧する時に表示がより遅い。
【０００５】
関連技術においてＡＴコマンドでＳＣＷＳを実現してウェブを閲覧する時に表示がより遅い問題に対して、現時点、まだ有効的な解決策が提出されてない。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
関連技術においてＡＴコマンドでＳＣＷＳを実現してウェブを閲覧する時に表示がより遅い問題に対して本発明を提出し、このため、本発明の主な目的は、上記問題を解決するために、改良されたデータ伝送スキームを提出した。
【課題を解決するための手段】
【０００７】
上記目的を実現するために、本発明の１つの側面に応じて、データ伝送方法が提出された。
【０００８】
本発明に係るデータ伝送方法は、通信プロセッサがアプリケーションプロセッサからの接続確立リクエストを受信するステップと、通信プロセッサがアプリケーションプロセッサへ接続確立成功を指示するための応答を送信し、かつ応答に応じてアプリケーションプロセッサの多重モジュールが多重チャネルを割り当てることを指示するステップと、通信プロセッサの多重モジュールが多重チャネルを割り当てるステップと、通信プロセッサが多重チャネルを介してアプリケーションプロセッサとデータ伝送を行うステップとを含む。
【０００９】
好ましくは、応答に応じてアプリケーションプロセッサの多重モジュールが多重チャネルを割り当てることを指示するステップは、アプリケーションプロセッサが応答を受信した後、アプリケーションプロセッサの多重モジュールが多重チャネルを割り当てることを含む。
【００１０】
好ましくは、通信プロセッサが接続確立リクエストを受信した後、上記方法は、さらに、通信プロセッサが接続確立リクエストに応じて汎用集積回路カードＵＩＣＣに接続確立を指示することに用いる通知メッセージを送信することを含み、通信プロセッサがＵＩＣＣからのオープンチャネルリクエストを受信し、通信プロセッサがＵＩＣＣとの間のチャネルをオープンする。
【００１１】
好ましくは、通信プロセッサが多重チャネルを介してアプリケーションプロセッサとデータ伝送を行うステップは、通信プロセッサが多重チャネルを介してアプリケーションプロセッサからの所定フォーマットのデータを受信し、そしてデータをベアラー非依存プロトコルＢＩＰフォーマットのデータに変換するステップと、通信プロセッサがＢＩＰフォーマットのデータをチャネルを介してＵＩＣＣに送信するステップとを含む。
【００１２】
好ましくは、通信プロセッサが多重チャネルを介してアプリケーションプロセッサとデータ伝送を行うステップは、通信プロセッサがチャネルを介してＵＩＣＣからのＢＩＰフォーマットのデータを受信し、そしてＢＩＰフォーマットのデータを所定フォーマットのデータに変換するステップと、通信プロセッサが所定フォーマットのデータをアプリケーションプロセッサに送信するステップとを含む。
【００１３】
好ましくは、通信プロセッサが多重チャネルを介してアプリケーションプロセッサとデータ伝送を行うステップが終了した後、上記方法は、通信プロセッサがＵＩＣＣからのクローズチャネルリクエストを受信してチャネルをクローズするステップと、通信プロセッサが多重チャネルをクローズし、そして、アプリケーションプロセッサがコマンドに応じて多重チャネルをクローズするように、アプリケーションプロセッサに接続が既にクローズしたコマンドを送信するステップとを更に含む。
【００１４】
上記目的を達成するように、本発明のもう１つの側面に応じて、端末が提供された。
【００１５】
本発明の端末によれば、アプリケーションプロセッサ及び通信プロセッサを含み、アプリケーションプロセッサは代理サービスモジュール及び第１の多重モジュールを含み、通信処理モジュールはＢＩＰゲートウェイ及び第２の多重モジュールを含み、ＢＩＰゲートウェイが代理サービスモジュールからの接続確立リクエストを受信することに用いられ、ＢＩＰゲートウェイが代理サービスモジュールに接続確立成功を指示するための応答を送信し、そして多重チャネルを割り当てることを第１の多重モジュールに通知することに更に用いられ、代理サービスモジュールが応答を受信し、そして多重チャネルを割り当てることを第２の多重モジュールに通知することに用いられ、ＢＩＰゲートウェイが多重チャネルを介して代理サービスモジュールとデータ伝送を行うことに更に用いられる。
【００１６】
好ましくは、ＢＩＰゲートウェイはＵＩＣＣに確立接続を指示することに用いる通知メッセージを送信し、そしてＵＩＣＣからのオープンチャネルリクエストを受信した後、ＵＩＣＣとの間のチャネルをオープンすることに更に用いられる。
【００１７】
好ましくは、ＢＩＰゲートウェイは代理サービスモジュールからの所定フォーマットのデータをＢＩＰフォーマットのデータに変換し、そしてＢＩＰフォーマットのデータをチャネルを介してＵＩＣＣに送信することに更に用いられ、ＢＩＰゲートウェイはＵＩＣＣからのＢＩＰフォーマットのデータを所定フォーマットのデータに変換し、そして変換後の所定フォーマットのデータを多重チャネルを介して代理サービスモジュールに送信することに更に用いられる。
【００１８】
好ましくは、ＢＩＰゲートウェイはＵＩＣＣからのクローズチャネルリクエストを受信し、そしてチャネルをクローズすることに更に用いられ、ＢＩＰゲートウェイは多重チャネルをクローズすることを第２の多重モジュールに通知し、そして代理サービスモジュールに接続が既にクローズしたコマンドを送信することに更に用いられ、代理サービスモジュールは接続が既にクローズしたコマンドを受信した後、多重チャネルをクローズすることを第１の多重モジュールに通知することに更に用いられる。
【発明の効果】
【００１９】
本発明によれば、端末にＭＵＸ（ｍｕｌｔｉｐｌｅｘｅｒ）モジュールを追加し、そしてＭＵＸモジュールを介してデータを伝送することで、ＡＴコマンドでＳＣＷＳを実現してウェブを閲覧する時に表示がより遅い問題を解決し、さらに、端末においてＷｅｂデータをより速く伝送する効果を達成する。
【図面の簡単な説明】
【００２０】
【図１】関連技術に係るＡＴコマンドを介してＵＩＣＣ内蔵ＷＥＢサーバー端末にアクセスするアーキテクチャである。
【図２】本発明の実施例に係るデータ伝送方法のフローチャートである。
【図３】本発明の実施例に係る端末のシステムアーキテクチャである。
【図４】本発明の実施例に係るＭＵＸモジュールを介してアプリケーションプロセッサと通信プロセッサとを接続してＵＩＣＣ Ｗｅｂサーバーの端末にアクセスするアーキテクチャである。
【図５】本発明の実施例に係るＵＩＣＣ内蔵ＷＥＢサーバーにアクセスするフローチャートである。
【図６】本発明の実施例に係る端末のアーキテクチャである。
【発明を実施するための形態】
【００２１】
関連技術においてＡＴコマンドでＳＣＷＳを実現してウェブを閲覧する時に表示がより遅い問題に対して、本発明の実施例において、改良されたデータ伝送スキームが提出された。当該スキームの処理原則は、通信プロセッサがＡＴコマンドを介してアプリケーションプロセッサからの接続確立リクエストを受信し、通信プロセッサがアプリケーションプロセッサに接続確立成功を指示するためのＡＴ応答を送信し、そしてＡＴ応答に応じてアプリケーションプロセッサのＭＵＸモジュールがＭＵＸチャネルを割り当てることを指示し、通信プロセッサのＭＵＸモジュールがＭＵＸチャネルを割り当て、通信プロセッサがＭＵＸチャネルを介してアプリケーションプロセッサとデータ伝送を行う。
【００２２】
なお、矛盾しない場合に、本発明における実施例及び実施例における特徴が相互に組合わせられる。以下、図面を参照しながら、実施例とともに本発明を詳しく説明する。
【００２３】
以下の実施例において、図面のフローチャートに示したステップは、例えばコンピュータで実行可能なコマンド群のコンピュータシステムで実行してよい、且つ、フローチャートにロジック順序を示したが、ある場合に、これに異なる順序で示される又は説明されるステップを実行してもよい。
【００２４】
本発明の実施例に応じて、データ伝送方法が提出された。図２は本発明の実施例に係るデータ伝送方法のフローチャートである。図２に示すように、当該方法は、以下のようなステップＳ２０２〜ステップＳ２０８を含む。
【００２５】
ステップＳ２０２において、通信プロセッサがアプリケーションプロセッサからの接続確立リクエストを受信する。
【００２６】
ステップＳ２０４において、通信プロセッサがアプリケーションプロセッサに接続確立成功を指示するためのＡＴ応答を送信し、そしてＡＴ応答に応じてアプリケーションプロセッサのＭＵＸモジュールがＭＵＸチャネルを割り当てることを指示し、即ち、アプリケーションプロセッサがＡＴ応答を受信した後、アプリケーションプロセッサのＭＵＸモジュールがＭＵＸチャネルを割り当てる。
【００２７】
ステップＳ２０６において、通信プロセッサのＭＵＸモジュールがＭＵＸチャネルを割り当てる。
【００２８】
ステップＳ２０８において、通信プロセッサがＭＵＸチャネルを介してアプリケーションプロセッサとデータ伝送を行う。
【００２９】
ステップＳ２０２の後、通信プロセッサが接続確立リクエストに応じてＵＩＣＣに通知メッセージを送信し、ＵＩＣＣが通知メッセージを受信した後、通信プロセッサにオープンチャネルリクエストを送信し、そして、通信プロセッサがＵＩＣＣとの間のチャネルをオープンする。
【００３０】
通信プロセッサはアプリケーションプロセッサとＵＩＣＣとの間にデータ変換を行う必要がある。通信プロセッサがＭＵＸチャネルを介してアプリケーションプロセッサからの所定フォーマットのデータを受信し、そしてデータをＢＩＰフォーマットのデータに変換することと、通信プロセッサがＢＩＰフォーマットのデータをＵＩＣＣとの間のチャネルを介してＵＩＣＣに送信することと、及び、通信プロセッサがＵＩＣＣとの間のチャネルを介してＵＩＣＣからのＢＩＰフォーマットのデータを受信し、そしてＢＩＰフォーマットのデータを所定フォーマットのデータに変換することと、通信プロセッサが所定フォーマットのデータをアプリケーションプロセッサに送信することとを含む。
【００３１】
データ伝送が完了した後、既に確立した接続をクローズする必要があり、当該プロセスは、以下のようなステップを含む。
【００３２】
ステップＡにおいて、通信プロセッサがＵＩＣＣからのクローズチャネルリクエストを受信し、そしてチャネルをクローズする。
【００３３】
ステップＢにおいて、通信プロセッサがＭＵＸチャネルをクローズし、そしてアプリケーションプロセッサがＡＴコマンドに応じてＭＵＸチャネルをクローズするように、アプリケーションプロセッサに接続が既にクローズしたＡＴコマンドを送信する。
【００３４】
ステップＣにおいて、アプリケーションプロセッサがＡＴコマンドを受信した後、ＭＵＸチャネルをクローズする。
【００３５】
以下、実例に合わせて本発明の実施例の実現過程を詳しく説明する。
【００３６】
図３は本発明の実施例に係る端末のシステムアーキテクチャである。図３に示すように、当該移動端末はアプリケーションプロセッサ、１つ又は複数の通信プロセッサ、ＵＩＣＣ及びプロセッサ間のチャネルを含み、その中、アプリケーションプロセッサは、ネットワークブラウザ、ＴＣＰ／ＩＰプロトコルスタック、代理サービスモジュール、プロセッサ間通信モジュール（ＡＴコマンドモジュール及び／又は多重ＭＵＸモジュールでよい）を含み、それぞれの通信プロセッサは、ＴＣＰ／ＩＰプロトコルスタック（当該モジュールが選択可能）、ＢＩＰゲートウェイとＢＩＰモジュール、及びプロセッサ間通信モジュール（ＡＴコマンドモジュール及び／又はＭＵＸモジュールでよい）を含む。
【００３７】
なお、プロセッサ間の物理チャネルは複数の種類があってもよい。以下の実例はシリアルポートを例とするが、シリアルポートに限らない。
【００３８】
実例１
図４は本発明の実施例に係るＭＵＸモジュールを介してアプリケーションプロセッサと通信プロセッサとを接続してＵＩＣＣ Ｗｅｂサーバーの端末にアクセスするアーキテクチャである。図４に示すように、当該端末はデータを伝送する場合にＭＵＸモジュールを用いた。当該実例において、アプリケーションプロセッサと１つの通信プロセッサとの接続を例として説明する。アプリケーションプロセッサは、ネットワークブラウザ、ＴＣＰ／ＩＰプロトコルスタック、代理サービスモジュール（代理サーバーに位置する）、ＡＴコマンドモジュール、多重モジュールを含み、通信プロセッサは、ＡＴコマンドモジュール、ＭＵＸモジュール、ＢＩＰゲートウェイ及びＢＩＰモジュールを含み、ＢＩＰゲートウェイがＢＩＰモジュールの機能を含んでよい。
【００３９】
図５は本発明の実施例に係るＵＩＣＣ内蔵ＷＥＢサーバーにアクセスするフローチャートである。以下、図４に示す構造の上で、図５のプロセスを詳しく説明する。図５に示すように、当該プロセスは２つの部分に分けれてよい、即ち、第１の部分はＡＴコマンドを介してＡＰとＣＰとの間の伝送チャネルを確立／閉鎖することであり、具体的に、以下のステップ１、ステップ４に対応する。第２の部分はＭＵＸチャネルを介してＡＰとＣＰとの間にデータ伝送を行うことであり、具体的に、以下のステップ２、ステップ３対応する。図５を参照しながら、ステップ１〜ステップ４を詳しく説明する。
【００４０】
ステップ１、ネットワークブラウザとＵＩＣＣとが接続を確立する。当該ステップは具体的に以下のステップＳ５０１〜ステップＳ５０５を含み、当該ステップを詳しく説明する。
【００４１】
ステップＳ５０１、ユーザーがネットワークブラウザでｈｔｔｐ：／／１２７．０．０．１：ｐｏｒｔ（その中、ｐｏｒｔがＵＩＣＣのあるサービスのインターフェースに対応し、デフォルトインターフェース８０を用いる場合、インターフェース番号を入力しなくてもよい、ｈｔｔｐ：／／１２７．０．０．１を直接入力する）を入力し、ユーザーがブラウザに予めに設定した、ｈｔｔｐ：／／１２７．０．０．１：ｐｏｒｔに指向するブックマークを用いて上記アドレスを手動入力することを取り替えてもよく、また、ＵＩＣＣカードＳＴＫ（ＳＩＭ Ｔｏｏｌ Ｋｉｔ）メニューにおける呼ぶブラウザにアクセスすることを介してＳＣＷＳのメニューにアクセスして、以上のステップを完了してもよい。そして、ネットワークブラウザはＴＣＰ／ＩＰプロトコルスタックを介してＴＣＰ／ＩＰプロトコルで伝送する接続リクエストを送信する。
【００４２】
ステップＳ５０２、代理サービスモジュールが接続リクエストを受信してブラウザとの接続を確立する。同時に、代理サービスモジュールが接続リクエストをＡＴコマンドで伝送する接続リクエストに変換し、％ＷＥＢＯＰＣＨ ＝ ｐｏｒｔをＣＰに送信し、接続確立をリクエストする。
【００４３】
ステップＳ５０３、ＢＩＰゲートウェイがＡＴコマンドで伝送した接続リクエストをＢＩＰプロトコルで伝送する接続リクエストに変換し、ＣＰ側のＢＩＰモジュールがＵＩＣＣとの間の接続を確立することをリクエストする。ＢＩＰゲートウェイがローカル接続エンベロープメッセージ（Ｅｎｖｅｌｏｐｅ（ｌｏｃａｌ ｃｏｎｎｅｃｔｉｎｇ））を介してＵＩＣＣに接続イベントがあることを通知する。
【００４４】
ステップＳ５０４、ＵＩＣＣが通知を受信した後、ＢＩＰゲートウェイにオープンチャネルリクエスト（Ｆｅｔｃｈ：ｏｐｅｎ ｃｈａｎｎｅｌ）を送信する。
【００４５】
ステップＳ５０５、ＢＩＰゲートウェイがオープンチャネルリクエストを受信した後、ＵＩＣＣにチャネル識別子（ｃｈａｎｎｅｌ ＩＤ）をキャリーする接続成功メッセージ（Ｔｅｒｍｉｎａｌ ｒｅｓｐｏｎｓｅ）を返す。そしてＭＵＸチャネルを割り当てるコマンドをＣＰ側のＭＵＸモジュールに送信する。同時に、代理サービスモジュールに接続確立成功ＡＴ応答（ＯＫ）を返す。代理サービスモジュールがＭＵＸチャネルを割り当てるコマンドをＡＰ側のＭＵＸモジュールに送信する。ＡＰとＣＰとの間にデータ伝送するためのＭＵＸチャネルを確立することが完了する。
【００４６】
ステップ２、ネットワークブラウザがリクエストデータをＵＩＣＣに送信する。当該ステップは具体的に以下のステップＳ５０６〜ステップＳ５１０を含み、以下、当該ステップを詳しく説明する。
【００４７】
ステップＳ５０６、ネットワークブラウザがＴＣＰ／ＩＰプロトコルで伝送するアクセスデータを代理サービスモジュールに送信する。
【００４８】
ステップＳ５０７、代理サービスモジュールがＴＣＰ／ＩＰプロトコルで伝送するアクセスデータをＰｏｒｔ＋ｄａｔａのフォーマットに変換し、ＭＵＸチャネルを介してＣＰ側のＢＩＰゲートウェイに送信する。ＢＩＰゲートウェイがアクセスデータをＢＩＰプロトコルがサポートするフォーマットに変換し、そしてＵＩＣＣに送信を準備する。
【００４９】
ステップＳ５０８、ＢＩＰゲートウェイが、チャネルデータが使用可能なエンベロープメッセージ（Ｅｎｖｅｌｏｐｅ（ｃｈａｎｎｅｌ ｄａｔａ ａｖａｉｌａｂｌｅ））を送信してＵＩＣＣにアクセスデータの送信があることを通知する。
【００５０】
ステップＳ５０９、ＵＩＣＣがデータ受信リクエスト（Ｆｅｔｃｈ：ｒｅｃｅｉｖｅ ｄａｔａ）を返してアクセスデータの受信を要求する。
【００５１】
ステップＳ５１０、ＢＩＰゲートウェイが端末応答（Ｔｅｒｍｉｎａｌ ｒｅｓｐｏｎｓｅ（ｄａｔａ））を介してＵＩＣＣにアクセスデータを送信する。
【００５２】
ステップ３、ＵＩＣＣが応答データをネットワークブラウザに送信する。当該ステップは具体的に以下のステップＳ５１１〜ステップＳ５１３を含み、以下、当該ステップを詳しく説明する。
【００５３】
ステップＳ５１１、ＵＩＣＣがＢＩＰプロトコルで伝送する応答データをＢＩＰゲートウェイに送信し、即ち、ＵＩＣＣがデータ送信リクエスト（Ｆｅｔｃｈ：ｓｅｎｄ ｄａｔａ）を介してＢＩＰゲートウェイに応答データを送信する。
【００５４】
ステップＳ５１２、ＢＩＰゲートウェイが応答データを受信した後、端末応答（Ｔｅｒｍｉｎａｌ ｒｅｓｐｏｎｓｅ）を介して既に応答データを受信したことをＵＩＣＣに通知し、そしてＰｏｒｔ＋ｄａｔａのフォーマットでＭＵＸチャネルを介して応答データをＡＰ側代理サービスモジュールに伝送する。
【００５５】
ステップＳ５１３、代理サービスモジュールが応答データを受信した後、ＡＴコマンドで伝送する応答データをＴＣＰ／ＩＰプロトコルで伝送する応答データに変換し、そしてＴＣＰ／ＩＰプロトコルスタックでネットワークブラウザに返し、ブラウザがハイパーテキスト伝送プロトコル（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：ＨＴＴＰ）データパケットを解析した後、ブラウザに表示する。
【００５６】
ＵＩＣＣにおいてすべてのデータが送信されているまで、以上のステップ２、ステップ３は数回に繰り返す可能性がある。
【００５７】
ステップ４、接続をクローズする。当該ステップは具体的に以下のステップＳ５１４〜ステップＳ５１７を含み、以下、当該ステップを詳しく説明する。
【００５８】
ステップＳ５１４、ＵＩＣＣからＢＩＰゲートウェイへクローズチャネルリクエストを送信し、そしてチャネル識別子（Ｆｅｔｃｈ：ｃｌｏｓｅ ｃｈａｎｎｅｌ（ｃｈａｎｎｅｌ ＩＤ））をキャリーし、チャネルをクローズすることをリクエストする。
【００５９】
ステップＳ５１５、ＢＩＰゲートウェイが接続をクローズした後、ＵＩＣＣへ端末応答（Ｔｅｒｍｉｎａｌ ｒｅｓｐｏｎｓｅ（ｃｈａｎｎｅｌ ｓｔａｔｕｓ：ｌｉｎｋ ｎｏｔ ｅｓｔａｂｌｉｓｈｅｄ））を送信することを介してチャネルをクローズすることを確認し、そしてＣＰ側ＭＵＸモジュールにＭＵＸチャネルをクローズするコマンドを送信し、同時に、代理サービスモジュールにＡＴコマンド、ＡＴ＋ＷＥＢＣＩＳ＝＜ｐｏｒｔ＞を送信して、今回の接続が既にクローズしたことをＡＰに通知する。
【００６０】
ステップＳ５１６、代理サービスモジュールがＴＣＰ／ＩＰプロトコルスタックを介してクローズ接続メッセージをネットワークブラウザに返し、そしてＡＰ側ＭＵＸモジュールにクローズＭＵＸチャネルコマンドを送信し、ＭＵＸチャネルのクローズを完了する。
【００６１】
ステップＳ５１７、ブラウザがクローズ応答を送信する。
【００６２】
上記実施例によれば、ＭＵＸチャネルを介してＡＰとＣＰとの間にデータ伝送を行い、伝送速度がもっと速く、もっと安定になり、同時に、複数のリクエストのデータを同時に伝送することもサポートできる。
【００６３】
本発明の実施例によれば、端末が提供された、アプリケーションプロセッサ６２及び通信プロセッサ６４を含み、図６は本発明の実施例に係る端末のアーキテクチャであり、図６に示すように、アプリケーションプロセッサ６２は代理サービスモジュール６２２及び第１のＭＵＸモジュール６２４を含み、通信プロセッサ６４はＢＩＰゲートウェイ６４２及び第２のＭＵＸモジュール６４４を含む。以下、それぞれのモジュールの機能を詳しく説明する。
【００６４】
ＢＩＰゲートウェイ６４２は代理サービスモジュール６２２からの接続確立リクエストを受信し、ＢＩＰゲートウェイ６４２は代理サービスモジュール６２２に接続確立成功を指示するための応答を送信し、そして第１のＭＵＸモジュール６２４にＭＵＸチャネルを割り当てることを通知することに更に用いられ、代理サービスモジュール６２２は応答を受信し、そして第２のＭＵＸモジュール６４４にＭＵＸチャネルを割り当てることを通知することに更に用いられ、ＢＩＰゲートウェイ６４２はＭＵＸチャネルを介して代理サービスモジュール６２２とデータ伝送を行うことに更に用いられる。
【００６５】
ＢＩＰゲートウェイ６４２はＵＩＣＣに確立接続を指示することに用いる通知メッセージを送信し、そしてＵＩＣＣからのオープンチャネルリクエストを受信した後、ＵＩＣＣとの間のチャネルをオープンすることに更に用いられる。
【００６６】
ＢＩＰゲートウェイ６４２は代理サービスモジュール６２２からの所定フォーマットのデータをＢＩＰフォーマットのデータに変換し、そしてＢＩＰフォーマットのデータをチャネルを介してＵＩＣＣに送信することに更に用いられ、ＢＩＰゲートウェイ６４２はＵＩＣＣからのＢＩＰフォーマットのデータを所定フォーマットのデータに変換し、そして変換後の所定フォーマットのデータをＭＵＸチャネルを介して代理サービスモジュール６２２に送信することに更に用いられる。
【００６７】
ＢＩＰゲートウェイ６４２はＵＩＣＣからのクローズチャネルリクエストを受信し、チャネルをクローズし、そして第２のＭＵＸモジュール６４４にＭＵＸチャネルをクローズすることを通知し、代理サービスモジュール６２２に接続が既にクローズしたコマンドを送信することに更に用いられ、代理サービスモジュール６２２は接続が既にクローズしたコマンドを受信した後、第１のＭＵＸモジュール６２４にＭＵＸチャネルをクローズすることを通知することに更に用いられる。
【００６８】
以上の記載によれば、本発明は以下のような技術的な効果を達成することが分かった。
【００６９】
速度が速い、ＷＥＢサービスのビッグデータ量伝送に適応する。ＡＴコマンドメカニズムはデータ端末装置とデータ通信装置との間に設計され、ＡＴコマンドとＡＴ応答とのペアでの実現メカニズムを用い、しかし、ブラウザとＷＥＢサーバーとの間のデータ伝送が必ずしもそれぞれに対応するものではなく、且つＡＴコマンドが実現される場合に一般的には、単一のコマンドのサイズに対して所定の制限があり、ビッグデータが複数のコマンドに分割されて伝送される必要がある。多重モジュールがデータ伝送することはデータストリームのモードで伝送するため、データのサイズ及びフォーマットの制限がなく、それぞれのＭＵＸのチャネルが相互に単独であり、様々なメモリエリアとフロー制御があり、様々なチャネルで同時に伝送することをサポートする。これによって、ＭＵＸチャネルを介してデータ伝送を行うことは、伝送速度を大きく向上させられ、データ伝送の信頼性を増加し、そして同時にパラレルリクエストのデータ伝送が完了できる。
【００７０】
明らかに、本分野の当業者が了解すべきなのは、上記本発明の各モジュール又は各ステップが汎用の計算装置で実現できて、それらが単一の計算装置に集中してもいい、或いは複数の計算する装置で組み立てるネットワークに配布されてもいい、選択的に、それらが、計算装置で実行可能のプログラムコードで実現できて、だから、それらを記憶装置に記憶され計算装置で実行してもいい、或いは、それらをそれぞれ各集積回路モジュールを作成してもいい、それらの中に複数のモジュール又はステップを単一の集積回路モジュールを作成して実現してもいい。そうしたら、本発明がいかなる特定されたハードウェアとソフトウェアの組み合わせに制限されない。
【００７１】
以上は、本発明の最適的な実施例に過ぎなく、本発明を制限せず、本分野の当業者に対して、本発明が各種類の変更と変化がある。本発明の主旨精神と原則以内に、いかなる改修、同等入れ替わり、改良等が、本発明の保護範囲以内に含まれるべきである。
【特許請求の範囲】
【請求項１】
通信プロセッサ及びアプリケーションプロセッサを含む端末に用いるデータ伝送方法であって、
通信プロセッサがアプリケーションプロセッサからの接続確立リクエストを受信するステップと、
前記通信プロセッサが前記アプリケーションプロセッサに接続確立成功を指示するための応答を送信し、且つ前記応答に応じて前記アプリケーションプロセッサが多重チャネルを割り当てることを指示するステップと、
前記通信プロセッサが前記多重チャネルを割り当てるステップと、
前記通信プロセッサが前記多重チャネルを介して前記アプリケーションプロセッサとデータ伝送を行うステップとを含むことを特徴とするデータ伝送方法。
【請求項２】
前記応答に応じて前記アプリケーションプロセッサが多重チャネルを割り当てることを指示するステップは、
前記アプリケーションプロセッサが前記応答を受信した後、前記多重チャネルを割り当てることを指示することを特徴とする
請求項１に記載の方法。
【請求項３】
前記通信プロセッサが前記接続確立リクエストを受信した後、前記方法は、
前記通信プロセッサが前記接続確立リクエストに応じて汎用集積回路カードＵＩＣＣに接続確立を指示することに用いる通知メッセージを送信するステップと、
前記通信プロセッサが前記ＵＩＣＣからのオープンチャネルリクエストを受信した後、前記通信プロセッサと前記ＵＩＣＣとの間のチャネルをオープンするステップとを更に含むことを特徴とする
請求項２に記載の方法。
【請求項４】
前記通信プロセッサが前記多重チャネルを介して前記アプリケーションプロセッサとデータ伝送を行うステップは、
前記通信プロセッサが前記多重チャネルを介して前記アプリケーションプロセッサからの所定フォーマットのデータを受信し、そして前記データをベアラー非依存プロトコルＢＩＰフォーマットのデータに変換するステップと、
前記通信プロセッサが前記ＢＩＰフォーマットのデータを前記通信プロセッサと前記ＵＩＣＣとの間のチャネルを介してＵＩＣＣに送信するステップとを含むことを特徴とする
請求項３に記載の方法。
【請求項５】
前記通信プロセッサが前記多重チャネルを介して前記アプリケーションプロセッサとデータ伝送を行うステップは、
前記通信プロセッサが前記通信プロセッサと前記ＵＩＣＣとの間のチャネルを介して前記ＵＩＣＣからのＢＩＰフォーマットのデータを受信した後、前記ＢＩＰフォーマットのデータを前記所定フォーマットのデータに変換するステップと、
前記通信プロセッサが前記所定フォーマットのデータを前記アプリケーションプロセッサに送信するステップとを含むことを特徴とする
請求項３に記載の方法。
【請求項６】
前記通信プロセッサが前記多重チャネルを介して前記アプリケーションプロセッサとデータ伝送を完了した後、前記方法は、
前記通信プロセッサがＵＩＣＣからのクローズチャネルリクエストを受信し、前記通信プロセッサと前記ＵＩＣＣとの間のチャネルをクローズするステップと、
前記通信プロセッサが前記多重チャネルをクローズし、そして前記アプリケーションプロセッサに接続が既にクローズしたコマンドを送信するステップとを更に含むことを特徴とする
請求項１〜５のいずれか１項に記載の方法。
【請求項７】
アプリケーションプロセッサと通信プロセッサとを含む端末であって、
前記アプリケーションプロセッサは、代理サービスモジュール及び第１の多重モジュールを含み、前記通信処理モジュールは、ＢＩＰゲートウェイ及び第２の多重モジュールを含み、
前記ＢＩＰゲートウェイは、前記代理サービスモジュールからの接続確立リクエストを受信することに用いられ、
前記ＢＩＰゲートウェイは、前記代理サービスモジュールに接続確立成功を指示するための応答を送信し、そして多重チャネルを割り当てることを前記第１の多重モジュールに通知することに更に用いられ、
前記代理サービスモジュールは、前記応答を受信し、そして前記多重チャネルを割り当てることを前記第２の多重モジュールに通知することに用いられ、
前記ＢＩＰゲートウェイは、前記多重チャネルを介して前記代理サービスモジュールとデータ伝送を行うことに更に用いられることを特徴とする端末。
【請求項８】
前記ＢＩＰゲートウェイは、ＵＩＣＣに確立接続を指示することに用いる通知メッセージを送信し、そして前記ＵＩＣＣからのオープンチャネルリクエストを受信した後、ＵＩＣＣとの間のチャネルをオープンすることに更に用いられることを特徴とする
請求項７に記載の端末。
【請求項９】
前記ＢＩＰゲートウェイは、前記代理サービスモジュールからの所定フォーマットのデータをＢＩＰフォーマットのデータに変換し、そして前記ＢＩＰフォーマットのデータを前記通信プロセッサと前記ＵＩＣＣとの間のチャネルを介してＵＩＣＣに送信することに更に用いられ、
前記ＢＩＰゲートウェイは、前記ＵＩＣＣからのＢＩＰフォーマットのデータを前記所定フォーマットのデータに変換し、そして変換後の前記所定フォーマットのデータを前記多重チャネルを介して前記代理サービスモジュールに送信することに更に用いられることを特徴とする
請求項８に記載の端末。
【請求項１０】
前記ＢＩＰゲートウェイは、ＵＩＣＣからのクローズチャネルリクエストを受信し、そして前記通信プロセッサと前記ＵＩＣＣとの間のチャネルをクローズすることに更に用いられ、
前記ＢＩＰゲートウェイは、前記多重チャネルをクローズすることを前記第２の多重モジュールに通知し、そして前記代理サービスモジュールに接続が既にクローズしたコマンドを送信することに更に用いられ、
前記代理サービスモジュールは、前記接続が既にクローズしたコマンドを受信した後、前記多重チャネルをクローズすることを前記第１の多重モジュールに通知することに更に用いられることを特徴とする
請求項７〜９のいずれか１項に記載の端末。
【請求項１】
通信プロセッサ及びアプリケーションプロセッサを含む端末に用いるデータ伝送方法であって、
通信プロセッサがアプリケーションプロセッサからの接続確立リクエストを受信するステップと、
前記通信プロセッサが前記アプリケーションプロセッサに接続確立成功を指示するための応答を送信し、且つ前記応答に応じて前記アプリケーションプロセッサが多重チャネルを割り当てることを指示するステップと、
前記通信プロセッサが前記多重チャネルを割り当てるステップと、
前記通信プロセッサが前記多重チャネルを介して前記アプリケーションプロセッサとデータ伝送を行うステップとを含むことを特徴とするデータ伝送方法。
【請求項２】
前記応答に応じて前記アプリケーションプロセッサが多重チャネルを割り当てることを指示するステップは、
前記アプリケーションプロセッサが前記応答を受信した後、前記多重チャネルを割り当てることを指示することを特徴とする
請求項１に記載の方法。
【請求項３】
前記通信プロセッサが前記接続確立リクエストを受信した後、前記方法は、
前記通信プロセッサが前記接続確立リクエストに応じて汎用集積回路カードＵＩＣＣに接続確立を指示することに用いる通知メッセージを送信するステップと、
前記通信プロセッサが前記ＵＩＣＣからのオープンチャネルリクエストを受信した後、前記通信プロセッサと前記ＵＩＣＣとの間のチャネルをオープンするステップとを更に含むことを特徴とする
請求項２に記載の方法。
【請求項４】
前記通信プロセッサが前記多重チャネルを介して前記アプリケーションプロセッサとデータ伝送を行うステップは、
前記通信プロセッサが前記多重チャネルを介して前記アプリケーションプロセッサからの所定フォーマットのデータを受信し、そして前記データをベアラー非依存プロトコルＢＩＰフォーマットのデータに変換するステップと、
前記通信プロセッサが前記ＢＩＰフォーマットのデータを前記通信プロセッサと前記ＵＩＣＣとの間のチャネルを介してＵＩＣＣに送信するステップとを含むことを特徴とする
請求項３に記載の方法。
【請求項５】
前記通信プロセッサが前記多重チャネルを介して前記アプリケーションプロセッサとデータ伝送を行うステップは、
前記通信プロセッサが前記通信プロセッサと前記ＵＩＣＣとの間のチャネルを介して前記ＵＩＣＣからのＢＩＰフォーマットのデータを受信した後、前記ＢＩＰフォーマットのデータを前記所定フォーマットのデータに変換するステップと、
前記通信プロセッサが前記所定フォーマットのデータを前記アプリケーションプロセッサに送信するステップとを含むことを特徴とする
請求項３に記載の方法。
【請求項６】
前記通信プロセッサが前記多重チャネルを介して前記アプリケーションプロセッサとデータ伝送を完了した後、前記方法は、
前記通信プロセッサがＵＩＣＣからのクローズチャネルリクエストを受信し、前記通信プロセッサと前記ＵＩＣＣとの間のチャネルをクローズするステップと、
前記通信プロセッサが前記多重チャネルをクローズし、そして前記アプリケーションプロセッサに接続が既にクローズしたコマンドを送信するステップとを更に含むことを特徴とする
請求項１〜５のいずれか１項に記載の方法。
【請求項７】
アプリケーションプロセッサと通信プロセッサとを含む端末であって、
前記アプリケーションプロセッサは、代理サービスモジュール及び第１の多重モジュールを含み、前記通信処理モジュールは、ＢＩＰゲートウェイ及び第２の多重モジュールを含み、
前記ＢＩＰゲートウェイは、前記代理サービスモジュールからの接続確立リクエストを受信することに用いられ、
前記ＢＩＰゲートウェイは、前記代理サービスモジュールに接続確立成功を指示するための応答を送信し、そして多重チャネルを割り当てることを前記第１の多重モジュールに通知することに更に用いられ、
前記代理サービスモジュールは、前記応答を受信し、そして前記多重チャネルを割り当てることを前記第２の多重モジュールに通知することに用いられ、
前記ＢＩＰゲートウェイは、前記多重チャネルを介して前記代理サービスモジュールとデータ伝送を行うことに更に用いられることを特徴とする端末。
【請求項８】
前記ＢＩＰゲートウェイは、ＵＩＣＣに確立接続を指示することに用いる通知メッセージを送信し、そして前記ＵＩＣＣからのオープンチャネルリクエストを受信した後、ＵＩＣＣとの間のチャネルをオープンすることに更に用いられることを特徴とする
請求項７に記載の端末。
【請求項９】
前記ＢＩＰゲートウェイは、前記代理サービスモジュールからの所定フォーマットのデータをＢＩＰフォーマットのデータに変換し、そして前記ＢＩＰフォーマットのデータを前記通信プロセッサと前記ＵＩＣＣとの間のチャネルを介してＵＩＣＣに送信することに更に用いられ、
前記ＢＩＰゲートウェイは、前記ＵＩＣＣからのＢＩＰフォーマットのデータを前記所定フォーマットのデータに変換し、そして変換後の前記所定フォーマットのデータを前記多重チャネルを介して前記代理サービスモジュールに送信することに更に用いられることを特徴とする
請求項８に記載の端末。
【請求項１０】
前記ＢＩＰゲートウェイは、ＵＩＣＣからのクローズチャネルリクエストを受信し、そして前記通信プロセッサと前記ＵＩＣＣとの間のチャネルをクローズすることに更に用いられ、
前記ＢＩＰゲートウェイは、前記多重チャネルをクローズすることを前記第２の多重モジュールに通知し、そして前記代理サービスモジュールに接続が既にクローズしたコマンドを送信することに更に用いられ、
前記代理サービスモジュールは、前記接続が既にクローズしたコマンドを受信した後、前記多重チャネルをクローズすることを前記第１の多重モジュールに通知することに更に用いられることを特徴とする
請求項７〜９のいずれか１項に記載の端末。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公表番号】特表２０１２−５３１８４６（Ｐ２０１２−５３１８４６Ａ）
【公表日】平成２４年１２月１０日（２０１２．１２．１０）
【国際特許分類】
【出願番号】特願２０１２−５１７９９９（Ｐ２０１２−５１７９９９）
【出願日】平成２１年１１月２７日（２００９．１１．２７）
【国際出願番号】ＰＣＴ／ＣＮ２００９／０７５１８０
【国際公開番号】ＷＯ２０１０／１４５１２２
【国際公開日】平成２２年１２月２３日（２０１０．１２．２３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（５１００２０３５４）中▲興▼通▲訊▼股▲ふぇん▼有限公司 (21)
【氏名又は名称原語表記】ＺＴＥ ＣＯＲＰＯＲＡＴＩＯＮ
【住所又は居所原語表記】ＺＴＥ Ｐｌａｚａ Ｋｅｊｉ Ｒｏａｄ Ｓｏｕｔｈ，Ｈｉ−Ｔｅｃｈ Ｉｎｄｕｓｔｒｉａｌ Ｐａｒｋ，Ｎａｎｓｈａｎ Ｄｉｓｔｒｉｃｔ Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ ５１８０５７ Ｃｈｉｎａ
【Ｆターム（参考）】
【公表日】平成２４年１２月１０日（２０１２．１２．１０）
【国際特許分類】
【出願日】平成２１年１１月２７日（２００９．１１．２７）
【国際出願番号】ＰＣＴ／ＣＮ２００９／０７５１８０
【国際公開番号】ＷＯ２０１０／１４５１２２
【国際公開日】平成２２年１２月２３日（２０１０．１２．２３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（５１００２０３５４）中▲興▼通▲訊▼股▲ふぇん▼有限公司 (21)
【氏名又は名称原語表記】ＺＴＥ ＣＯＲＰＯＲＡＴＩＯＮ
【住所又は居所原語表記】ＺＴＥ Ｐｌａｚａ Ｋｅｊｉ Ｒｏａｄ Ｓｏｕｔｈ，Ｈｉ−Ｔｅｃｈ Ｉｎｄｕｓｔｒｉａｌ Ｐａｒｋ，Ｎａｎｓｈａｎ Ｄｉｓｔｒｉｃｔ Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ ５１８０５７ Ｃｈｉｎａ
【Ｆターム（参考）】
[ Back to top ]