JP3827688B2 - 移動通信端末機のインターネットサービス同期化方法 - Google Patents

Description

本発明は、移動通信端末機のインターネットサービス同期化方法に係るもので、詳しくは、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）とＷＡＰ（Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ブラウザー間の同期化方法に関するものである。

一般に、移動通信システムにおいては、ネットスケープ・ナビゲーターやマイクロソフト・インターネット・エクスプローラのようなインターネットブラウザー機能を移動端末機に具現するためにＷＡＰを用い、該ＷＡＰは、携帯電話、ポケベル及びＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）のような無線端末機のための応用構造及びプロトコルを定義し、特に、ＧＳＭ（Ｇｌｏｂａｌ Ｓｔａｎｄａｒｄ ｆｏｒ Ｍｏｂｉｌｅｓ）、ＴＤＭＡ（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）及びＣＤＭＡ（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）のような無線網とインターネットを連動させる。

且つ、このようなＷＡＰを基盤としたインターネットサービスシステムは、ＷＡＰブラウザーを装着してコンテンツを支援するＷＡＰディバイスと、無線コンテンツを提供するＣＰ（Ｃｏｎｔｅｎｔｓ Ｐｒｏｖｉｄｅｒ）サーバーと、前記ＷＡＰディバイスと無線インターネット間を接続するためのＷＡＰゲートウェイと、を包含して構成される。

また、前記ＷＡＰディバイスは、携帯電話及びＰＤＡのような移動通信端末機であって、その内部にＷＡＰブラウザーが装着され、該ＷＡＰブラウザーを利用して、ＶＯＤ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）、ＭＭＳ（Ｍｕｌｔｉｍｅｄｉａ Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅ）及びＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のようなサービスを受信する。

且つ、図５に示したように、前記ＷＡＰブラウザーは、ソケットインターフェースを通して、インターネットサービスをユーザに提供し、ＴＣＰ／ＩＰを通して網との連結を設定し、該網との連結によりデータ送受信を行う。ここで、ソケットは、クライアントプログラム（例えば、ＷＡＰブラウザー）とサーバープログラム間の通信方法であって、“接続の端点”として定義される。このようなソケットは、ソケットＡＰＩと呼ばれる一連のプログラミングの要請や関数呼出し（Ｆｕｎｃｔｉｏｎ ｃａｌｌ）により作られる。

以下、このようなＷＡＰ基盤のインターネットサービスシステムにおける、ＷＡＰブラウザーとＴＣＰ／ＩＰ間の同期化過程に対して説明する。

まず、データ送信サービスを行う場合、ＷＡＰブラウザーは、ＴＣＰ／ＩＰにデータ送信を要求し、そのＷＡＰブラウザーの要求によって、ＴＣＰ／ＩＰは、自分のバッファの状態をチェックする。次いで、ＴＣＰ／ＩＰは、そのチェックの結果、前記バッファに可用空間がないと直ちに失敗値をリターンし、可用空間があると直ちに成功値をリターンする。その後、ＷＡＰブラウザーは、ＴＣＰ／ＩＰから失敗値が伝送されるとデータ送信サービスを中断し、成功値が伝送されると以後のデータ送信過程を行う。

一方、データ受信サービスを行う場合、ＷＡＰブラウザーは、ＴＣＰ／ＩＰにデータ受信を要求し、そのＷＡＰブラウザーの要求によって、ＴＣＰ／ＩＰは、自分の受信バッファをチェックし、前記受信バッファ内に受信データがないとＷＡＰブラウザーに失敗値をリターンし、受信データがあると成功値をリターンする。その後、ＷＡＰブラウザーは、ＴＣＰ／ＩＰから失敗値が伝送されるとデータ送信サービスを中断し、成功値が伝送されると以後のデータ受信過程を行う。

また、ＷＡＰブラウザーがＴＣＰ／ＩＰに外部クライアントとの連結要請に対する許可を要請した場合、ＴＣＰ／ＩＰは、該当の要求時点に受信された連結要請信号があるかを確認し、受信された連結要請信号がないと直ちに失敗値をリターンし、ＷＡＰブラウザーは、サービスを中断する。

このように、ＷＡＰ基盤のインターネットサービスシステムにおける、ＷＡＰブラウザーとＴＣＰ／ＩＰ間の同期化過程は、ＷＡＰブラウザーの要請に対するＴＣＰ／ＩＰの応答により行われる。

ところが、このような従来の同期化過程において、ＷＡＰブラウザーは、“データ送信サービス”、“データ受信サービス”及び“連結要請信号”に対する応答信号として失敗値が受信されると、サービスの遂行を中断してそれ以上ＴＣＰ／ＩＰから信号を受信しないため、ＴＣＰ／ＩＰが直ちにＷＡＰブラウザーの要請を収容することができる状態に転換されても、その転換されたＴＣＰ／ＩＰの状態を分かることができない。

このような従来のインターネットサービス同期化方法においては、ＷＡＰブラウザーは、“データ送信サービス”、“データ受信サービス”及び“外部クライアントとの連結”を行い得るようになっても、前記ＴＣＰ／ＩＰの状態が分からないため、ＷＡＰブラウザーとＴＣＰ／ＩＰ間の同期化を行うことができないし、よって、インターネットサービスを円滑に行い得ないという不都合な点があった。

また、サービス同期化の頻繁な失敗により、インターネットサービスシステムの性能及び効率が低下するという不都合な点があった。

本発明は、このような従来の課題に鑑みてなされたもので、ＷＡＰブラウザーとＴＣＰ／ＩＰ間の同期化の失敗回数を減らし得るインターネットサービス同期化方法を提供することを目的とする。

このような目的を達成するため、本発明に係るインターネットサービス同期化方法においては、移動通信端末機のＴＣＰ／ＩＰであって、アプリケーションからユーザの要求を受信する過程と、前記ユーザの要求を処理することができるかを判断する過程と、前記ユーザの要求を処理することができないとき、アプリケーションを待機させる過程と、前記ユーザの要求を処理し得るようになったとき、アプリケーションにユーザの要求を再伝送するようにして処理する過程と、を順次行うことを特徴とする。

また、前記ユーザの要求は、データ送信要求であることを特徴とする。

且つ、前記ユーザの要求は、データ受信要求であることを特徴とする。

且つ、前記ユーザの要求は、外部クライアントの連結要請に対する許可要求であることを特徴とする。

そして、本発明に係るインターネットサービス同期化方法においては、移動通信端末機のアプリケーションであって、ＴＣＰ／ＩＰにユーザの要求を伝送する過程と、ＴＣＰ／ＩＰがユーザの要求を処理することができない状態であることを知らせたとき、ＴＣＰ／ＩＰの再伝送の要求があるまで待機する過程と、ＴＣＰ／ＩＰの再伝送の要求が受信されたとき、前記ユーザの要求を再伝送する過程と、を順次行うことを特徴とする。

本発明のインターネットサービス同期化方法は、移動通信端末機のＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）であって、アプリケーションからユーザの要求を受信する過程と、前記ユーザの要求を処理することができるかを判断する過程と、前記ユーザの要求を処理することができないとき、アプリケーションを待機させる過程と、前記ユーザの要求を処理し得るようになったとき、アプリケーションにユーザの要求を再伝送するようにして処理する過程と、を順次行うことを特徴とし、それにより上記目的が達成される。

前記ユーザの要求は、データ送信要求であることを特徴としてもよい。

前記判断過程は、ＴＣＰ／ＩＰのバッファに余裕格納空間があるかを確認することであることを特徴としてもよい。

前記ユーザの要求は、データ受信要求であることを特徴としてもよい。

前記判断過程は、ＴＣＰ／ＩＰに受信されたデータがあるかを確認することであることを特徴としてもよい。

前記ユーザの要求は、外部クライアントの連結要請（ｃｏｎｎｅｃｔｉｏｎ ｒｅｑｕｅｓｔ）に対する許可要求であることを特徴としてもよい。

前記判断過程は、ＴＣＰ／ＩＰに受信された連結要請信号があるかを確認することであることを特徴としてもよい。

本発明のインターネットサービス同期化方法は、移動通信端末機のアプリケーションであって、ＴＣＰ／ＩＰにユーザの要求を伝送する過程と、ＴＣＰ／ＩＰがユーザの要求を処理することができない状態であることを知らせたとき、ＴＣＰ／ＩＰの再伝送の要求があるまで待機する過程と、ＴＣＰ／ＩＰの再伝送の要求が受信されたとき、前記ユーザの要求を再伝送する過程と、を順次行うことを特徴とし、それにより上記目的が達成される。

前記ユーザの要求は、データ送信要求であることを特徴としてもよい。

前記ＴＣＰ／ＩＰのユーザの要求を処理することができない状態は、ＴＣＰ／ＩＰのバッファに余裕格納空間がない状態であることを特徴としてもよい。

前記ユーザの要求は、データ受信要求であることを特徴としてもよい。

前記ＴＣＰ／ＩＰのユーザの要求を処理することができない状態は、ＴＣＰ／ＩＰに受信されたデータがない状態であることを特徴としてもよい。

前記ユーザの要求は、外部クライアントの連結要請に対する許可要求であることを特徴としてもよい。

前記ＴＣＰ／ＩＰのユーザの要求を処理することができない状態は、ＴＣＰ／ＩＰに受信された連結要請信号がない状態であることを特徴としてもよい。

本発明に係る移動通信端末機のインターネットサービス同期化方法においては、ＴＣＰ／ＩＰとアプリケーション間のサービス同期化過程を改善することで、サービス同期化の頻繁な失敗により、インターネットサービスシステムの性能及び効率が低下する従来の同期化過程の問題点を解決し得るという効果がある。

以下、本発明の実施の形態に対し、図面に基づいて説明する。

本発明の主眼点は、ＴＣＰ／ＩＰがＷＡＰブラウザーから要求されたサービスを行うことができない状態のとき、“失敗値”の代わりに“待機メッセージ”をリターンするようにすることで、ＷＡＰブラウザーが直ちにサービスを終了しないようにすることにある。

以下、ＷＡＰブラウザーとＴＣＰ／ＩＰ間に行われる一般の同期化過程に対し、図１に基づいて説明する。

任意のサービス（サービス−Ｘ）の遂行を要求するユーザの命令が伝達されると、ＷＡＰブラウザー（以下、アプリケーションという）は、ＴＣＰ／ＩＰに前記サービス−Ｘを要求し（Ｓ１０）、ＴＣＰ／ＩＰは、前記サービス−Ｘを行うため、自分の状態をチェックする。次いで、ＴＣＰ／ＩＰは、そのチェックの結果、前記サービス−Ｘを行うことができないと判定されると、“待機メッセージ（ＷＯＵＬＤＢＬＯＣＫ）”をリターンする（Ｓ１１）。その後、サービス−Ｘの遂行が可能になると、アプリケーションに“通知イベントメッセージ”を伝送する（Ｓ１２）。

一方、“待機メッセージ”を受信したアプリケーションは、他の作業を行いながらＴＣＰ／ＩＰの“通知イベントメッセージ”が受信されるまで待機する。その後、ＴＣＰ／ＩＰから“通知イベントメッセージ”が受信されると、アプリケーションは前記サービス−Ｘ要求過程（Ｓ１０）を繰り返して行う（Ｓ１３）。

本発明に係るアプリケーションとＴＣＰ／ＩＰ間の同期化過程、特に、“データ送信サービス同期化過程”、“データ受信サービス同期化過程”及び“外部クライアントの連結要請に対する許可を行うための同期化過程”に対して説明する。

まず、データ送信サービスを行うための同期化過程に対し、図２に基づいて説明する。

データ送信サービスを行うため、アプリケーションがＳｅｎｄ（）関数を呼び出して“データ送信サービス要求信号”をソケットＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）に伝達すると、ソケットＡＰＩは、Ｓｏｃｋｅｔ＿Ｓｅｎｄ（）関数を呼び出してＴＣＰ／ＩＰにデータ送信を要求する（Ｓ２０）。

次いで、アプリケーションの要求によって、ＴＣＰ／ＩＰは、自分のバッファの状態をチェックして可用空間があるかを確認し、可用空間があるとデータ送信を行い、可用空間がないと“待機メッセージ”をリターンする（Ｓ２１）。

その後、“待機メッセージ”を受信したアプリケーションは、他の作業を行いながらＴＣＰ／ＩＰの“通知イベントメッセージ”が受信されるまで待機する。次いで、ＴＣＰ／ＩＰから“通知イベントメッセージ”が受信されると（Ｓ２２）、アプリケーションは、Ｓｅｎｄ（）関数を再び呼び出して前記データ送信サービス要求過程（Ｓ２０）を繰り返して行う（Ｓ２３）。

以下、データ受信サービスを行うための同期化過程に対し、図３に基づいて説明する。

データ受信サービスを行うため、アプリケーションがＲｅｃｅｉｖｅ（）関数を呼び出して“データ受信サービス要求信号”をソケットＡＰＩに伝達すると、ソケットＡＰＩは、Ｓｏｃｋｅｔ＿Ｒｅｃｅｉｖｅ（）関数を呼び出してＴＣＰ／ＩＰにデータ受信を要求する（Ｓ３０）。

次いで、アプリケーションの要求によって、ＴＣＰ／ＩＰは、自分の受信バッファをチェックして受信データがあるかを確認し、受信データがあるとデータ受信を行い、受信データがないと“待機メッセージ”をリターンする（Ｓ３１）。

その後、“待機メッセージ”を受信したアプリケーションは、他の作業を行いながらＴＣＰ／ＩＰの“通知イベントメッセージ”が受信されるまで待機する。次いで、ＴＣＰ／ＩＰから“通知イベントメッセージ”が受信されると（Ｓ３２）、アプリケーションは、Ｒｅｃｅｉｖｅ（）関数を再び呼び出して前記データ受信サービス要求過程（Ｓ３０）を繰り返して行う（Ｓ３３）。

以下、外部クライアントの連結要請に対する許可を行うための同期化過程に対し、図４に基づいて説明する。

外部クライアントの連結要請に対する許可を行うため、アプリケーションがＡｃｃｅｐｔ（）関数を呼び出して“連結要請許可要求信号”をソケットＡＰＩに伝達すると、ソケットＡＰＩはＳｏｃｋｅｔ＿Ａｃｃｅｐｔ（）関数を呼び出してＴＣＰ／ＩＰに外部クライアントの連結要請に対する許可を要求する（Ｓ４０）。

次いで、アプリケーションの要求によって、ＴＣＰ／ＩＰは、該当の要求時点に受信された連結要請信号があるかを確認し、連結要請信号があると連結要請に対する許可を行い、受信された連結要請信号がないと“待機メッセージ”をリターンする（Ｓ４１）。

その後、“待機メッセージ”を受信したアプリケーションは、他の作業を行いながらＴＣＰ／ＩＰの“通知イベントメッセージ”が受信されるまで待機する。次いで、ＴＣＰ／ＩＰから“通知イベントメッセージ”が受信されると（Ｓ４２）、アプリケーションは、Ａｃｃｅｐｔ（）関数を再び呼び出して前記連結要請許可要求過程（Ｓ４０）を繰り返して行う（Ｓ４３）。

以上のように、本発明の好ましい実施形態を用いて本発明を例示してきたが、本発明は、この実施形態に限定して解釈されるべきものではない。本発明は、特許請求の範囲によってのみその範囲が解釈されるべきであることが理解される。当業者は、本発明の具体的な好ましい実施形態の記載から、本発明の記載および技術常識に基づいて等価な範囲を実施することができることが理解される。本明細書において引用した特許、特許出願および文献は、その内容自体が具体的に本明細書に記載されているのと同様にその内容が本明細書に対する参考として援用されるべきであることが理解される。

本発明に係るインターネットサービス同期化過程の信号流れ図である。 本発明に係る、データ送信を行うための同期化過程の信号流れ図である。 本発明に係る、データ受信を行うための同期化過程の信号流れ図である。 本発明に係る、外部クライアントの連結要請に対する許可を行うための同期化過程の信号流れ図である。 ＷＡＰの一般のプロトコルスタックを示した構成図である。

Claims (14)

1. 移動通信端末機のＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）であって、
   アプリケーションからユーザの要求を受信する過程と、
   前記ユーザの要求を処理することができるかを判断する過程と、
   前記ユーザの要求を処理することができないとき、アプリケーションを待機させる過程と、
   前記ユーザの要求を処理し得るようになったとき、アプリケーションにユーザの要求を再伝送するようにして処理する過程と、
   を順次行うことを特徴とするインターネットサービス同期化方法。
2. 前記ユーザの要求は、
   データ送信要求であることを特徴とする請求項１記載のインターネットサービス同期化方法。
3. 前記判断過程は、
   ＴＣＰ／ＩＰのバッファに余裕格納空間があるかを確認することであることを特徴とする請求項２記載のインターネットサービス同期化方法。
4. 前記ユーザの要求は、
   データ受信要求であることを特徴とする請求項１記載のインターネットサービス同期化方法。
5. 前記判断過程は、
   ＴＣＰ／ＩＰに受信されたデータがあるかを確認することであることを特徴とする請求項４記載のインターネットサービス同期化方法。
6. 前記ユーザの要求は、
   外部クライアントの連結要請（ｃｏｎｎｅｃｔｉｏｎ ｒｅｑｕｅｓｔ）に対する許可要求であることを特徴とする請求項１記載のインターネットサービス同期化方法。
7. 前記判断過程は、
   ＴＣＰ／ＩＰに受信された連結要請信号があるかを確認することであることを特徴とする請求項６記載のインターネットサービス同期化方法。
8. 移動通信端末機のアプリケーションであって、
   ＴＣＰ／ＩＰにユーザの要求を伝送する過程と、
   ＴＣＰ／ＩＰがユーザの要求を処理することができない状態であることを知らせたとき、ＴＣＰ／ＩＰの再伝送の要求があるまで待機する過程と、
   ＴＣＰ／ＩＰの再伝送の要求が受信されたとき、前記ユーザの要求を再伝送する過程と、
   を順次行うことを特徴とするインターネットサービス同期化方法。
9. 前記ユーザの要求は、
   データ送信要求であることを特徴とする請求項８記載のインターネットサービス同期化方法。
10. 前記ＴＣＰ／ＩＰのユーザの要求を処理することができない状態は、
    ＴＣＰ／ＩＰのバッファに余裕格納空間がない状態であることを特徴とする請求項９記載のインターネットサービス同期化方法。
11. 前記ユーザの要求は、
    データ受信要求であることを特徴とする請求項８記載のインターネットサービス同期化方法。
12. 前記ＴＣＰ／ＩＰのユーザの要求を処理することができない状態は、
    ＴＣＰ／ＩＰに受信されたデータがない状態であることを特徴とする請求項１１記載のインターネットサービス同期化方法。
13. 前記ユーザの要求は、
    外部クライアントの連結要請に対する許可要求であることを特徴とする請求項８記載のインターネットサービス同期化方法。
14. 前記ＴＣＰ／ＩＰのユーザの要求を処理することができない状態は、
    ＴＣＰ／ＩＰに受信された連結要請信号がない状態であることを特徴とする請求項１３記載のインターネットサービス同期化方法。

Images