JP2015524586A - ベアラ非依存プロトコルを伴うソケット管理の方法 - Google Patents

Abstract

ベアラ非依存プロトコルゲートウェイパフォーマンス最適化のためのシステム、方法、およびデバイスについて記述される。一態様では、ベアラ非依存プロトコルゲートウェイは、HTTPトランザクション(要求および対応する応答)がいつ完了するかを検出し、TCPソケットが閉じられるのを必ずしも待たずに、トランザクションが完了するとすぐに、次のソケットに切り替えるように構成されたトラフィックアナライザを含むデバイスに設けられる。たとえば、ゲートウェイは、応答が完了していることを検出すると、ソケット待ち行列の中に現在のソケットを移し、次のソケットにサービスし始めることができる。

Description

本出願は、一般に通信デバイスに関し、より詳細には、ベアラ非依存プロトコルゲートウェイパフォーマンス最適化のためのシステム、方法、およびデバイスに関する。

データおよびサービスをスマートカードから提供することができるベアラ非依存プロトコル(BIP)が開発されている。スマートカードは、一般に、通信デバイスに結合され得るデータストレージを含む媒体を指し得る。スマートカードの例には、加入者識別モジュール(SIM)カード、汎用加入者識別モジュール(USIM)カード、汎用集積回路(UICC)カード、取外し可能ユーザ識別モジュール(R-UIM)、CDMA加入者識別モジュール(CSIM)などがある。

データおよびサービスが提供され得る1つの方法は、スマートカードウェブサーバを用いることである。スマートカードは、スマートカードに結合されるデバイスのプロセッサによって、ウェブサーバのインスタンス化および構成をもたらすデータを含むことができる。スマートカードウェブサーバは、表示インターフェースとしてデバイスのウェブブラウザおよび標準ウェブ技術を使用して、エンドユーザに対して、スマートカードを所有し得るオペレータによって定義されるコンテンツを提供するためにベアラ非依存プロトコルを使用するように構成され得る。たとえば、スマートカードは、デバイス(たとえば、スマートフォン、フィーチャーフォン)上で実行されているウェブブラウザを介してアクセスされ得る電子ウォレットアプリケーションを含み得る。このウェブサーバは、ベアラ非依存プロトコルを介してスマートカード上のデータおよびサービスにアクセスするために、パケットベースインターフェース(たとえば、HTTP over TCP/IP)を提供することができる。

2つのプロトコルにブリッジするために、ベアラ非依存プロトコルゲートウェイが含まれ得る。ベアラ非依存プロトコルゲートウェイは、クライアントとの間でパケットベース信号を送受信し、スマートカードとの間でベアラ非依存プロトコル信号を送受信するように構成され得る。

スマートカードと通信するために、有限数のチャネルが提供され得る。たとえば、スマートカードに対して開かれ得る並列のBIPチャネルの数は制限され得る(たとえば、3、8または5)。データ(たとえば、ウェブブラウザ)にアクセスするクライアントは、情報を取得するためにいくつかのソケット接続を開くように構成され得る。したがって、クライアントからのソケットの数は、利用可能なBIPチャネルの数を超え得る。スマートカードとクライアントとの間の通信が管理される方法は、データが送信されるサービスおよび速度のパフォーマンスに影響を与え得る。したがって、ベアラ非依存プロトコルゲートウェイパフォーマンス最適化のためのシステム、方法、およびデバイスが望まれる。

本発明のシステム、方法およびデバイスはそれぞれいくつかの態様を有し、それらのうちの単一の態様が単独で、その望ましい属性を担うわけではない。以下の特許請求の範囲によって表される本発明の範囲を限定することなく、いくつかの特徴がここで簡単に論じられる。この考察を検討した後、具体的には「発明を実施するための形態」と題するセクションを読んだ後、本発明の特徴が、ベアラ非依存プロトコルチャネルの利用の効率を向上させることを含む利点をどのようにもたらすかが理解されよう。

1つの発明的態様では、ソケット管理の方法が提供される。この方法は、少なくとも2つのソケットからパケットベースプロトコルを介して通信されるべきデータをアプリケーションから受信するステップを含む。この方法は、ベアラ非依存プロトコルチャネルを介して少なくとも2つのソケットのうちの1つからデータを送信するステップをさらに含む。この方法は、送信されたデータに少なくとも部分的に基づいてデータ応答を受信するステップも含む。この方法は、受信されたデータ応答に少なくとも部分的に基づいてデータ通信が完了しているかどうかを判断するステップを含む。データ通信が完了していることを判断が示す場合、この方法は、ベアラ非依存プロトコルチャネルを介して少なくとも2つのソケットのうちの別の1つを介してデータを送信するステップを含む。データ通信が未完了であることを判断が示す場合、この方法は、少なくとも2つのソケットのうちの1つを介したデータの送信を続ける。

別の発明的態様では、ソケット接続を管理するための装置が提供される。この装置は、少なくとも2つのソケットからパケットベースプロトコルを介して通信されるべきデータをアプリケーションから受信するように構成されたクライアント回路を含む。この装置は、カード回路を含む。カード回路は、ベアラ非依存プロトコルチャネルを介して少なくとも2つのソケットのうちの1つからデータをスマートカードに送信するように構成される。このカード回路は、送信されたデータに少なくとも部分的に基づいてデータ応答を受信するようにさらに構成される。この装置は、受信されたデータ応答に少なくとも部分的に基づいてデータ通信が完了しているかどうかを判断するように構成されたトラフィックアナライザも含む。クライアント回路は、データ通信が完了していることを判断が示す場合、ベアラ非依存プロトコルチャネルを介して少なくとも2つのソケットのうちの別の1つを介してデータを送信するようにさらに構成される。クライアント回路は、データ通信が未完了であることを判断が示す場合、少なくとも2つのソケットのうちの1つを介したデータの送信を続けるようにも構成される。

さらなる発明的態様では、ソケット接続を管理するための別の装置が提供される。この装置は、少なくとも2つのソケットからパケットベースプロトコルを介して通信するためのデータをアプリケーションから受信するように構成されたクライアントアプリケーション通信のための手段を含む。この装置は、データ通信のための手段を含む。データ通信のための手段は、ベアラ非依存プロトコルチャネルを介して少なくとも2つのソケットのうちの1つからデータを送信するように構成され得る。データ通信のための手段は、送信されたデータに少なくとも部分的に基づいてデータ応答を受信するようにさらに構成され得る。この装置は、受信されたデータ応答に少なくとも部分的に基づいてデータ通信が完了しているかどうかを判断するように構成されたトラフィックを分析するための手段も含む。クライアントアプリケーション通信のための手段は、データ通信が完了していることを判断が示す場合、ベアラ非依存プロトコルチャネルを介して少なくとも2つのソケットのうちの別の1つを介してデータを送信するようにさらに構成され得る。クライアントアプリケーション通信のための手段は、データ通信が未完了であることを判断が示す場合、少なくとも2つのソケットのうちの1つを介したデータの送信を続けるようにも構成され得る。

別の発明的態様では、装置のプロセッサによって実行可能な命令を含むコンピュータ可読記憶媒体が提供される。命令によって、装置は、少なくとも2つのソケットからパケットベースプロトコルを介して通信するためのデータをアプリケーションから受信する。命令によって、装置は、ベアラ非依存プロトコルチャネルを介して少なくとも2つのソケットのうちの1つからデータを送信する。命令によって、装置は、送信されたデータに少なくとも部分的に基づいてデータ応答を受信する。命令によって、装置は、受信されたデータ応答に少なくとも部分的に基づいてデータ通信が完了しているかどうかを判断する。データ通信が完了していることを判断が示す場合、命令によって、装置は、ベアラ非依存プロトコルチャネルを介して少なくとも2つのソケットのうちの別の1つを介してデータを送信する。データ通信が未完了であることを判断が示す場合、命令によって、装置は、少なくとも2つのソケットのうちの1つを介したデータの送信を続ける。

通信デバイスの一例の機能ブロック図である。 スマートカードへの例示的な通信経路の機能ブロック図である。 トラフィックアナライザを含む通信デバイスの一例の機能ブロック図である。 クライアントからスマートカードへの例示的な要求のプロセスフロー図である。 トラフィック分析の一例のプロセスフロー図である。 切替え型ソケット通信セッションの一例のコールフロー図である。 ソケット管理の方法のプロセスフロー図である。 ベアラ非依存プロトコルソケット管理のための例示的な装置の機能ブロック図である。

スマートカードウェブサーバは、一般に、デバイスに結合されるスマートカード上で動作しているウェブサーバを指し得る。スマートカードウェブサーバは、インターフェースとしてデバイスのウェブブラウザおよび標準ウェブ技術を使用して、エンドユーザに対して、スマートカードを所有し得るネットワークオペレータによって定義されるコンテンツを提供するために使用され得る。スマートカードウェブサーバは、たとえばETSI 102 223に記載されているものなど、BIP(ベアラ非依存プロトコル)プロトコルを使用するように構成され得、一方で、ブラウザは、たとえばTCP/IPスタックなど、パケットベースのスタックを使用し得る。スマートカードとクライアントとの間のデータの通信を可能にするために、BIPプロトコルをTCP/IPに、またその逆に変換するように、BIPゲートウェイと呼ばれ得るモジュールが提供され得る。

スマートカード上のリソースが不足する可能性がある。いくつかのカードは、単一のBIPチャネルを開くように構成され得る。一方、TCPソケットは汎用的に使用可能であり、商用のブラウザは、パフォーマンスを向上させるために、同時に多くのソケットを開いて、リソース(たとえば、ウェブページ、画像、カスケーディングスタイルシート、Java(登録商標)scriptなど)を並行してダウンロードする。BIPゲートウェイは、ブラウザから来る要求を順番に並べ、単一のBIPチャネルを介して、それらを順々にスマートカードウェブサーバに送るように構成され得る。多くの商用のHTTPプロトコルスタックは、要求されたコンテンツをダウンロードし終わった後、数秒間、TCP/IP接続を開いておく可能性がある。この構成は、新しいコンテンツが同じサーバから必要とされる場合、同じソケットを再利用するために含まれ得る。再利用は、新しいTCPハンドシェイクのために時間およびネットワークリソースを節約することができる。

しかしながら、この機構は、データ通信が完了した後、ある時間期間の間、BIPチャネルがビジーのままでいるようにし、それによって、その後の送信を遅延させる可能性がある。この遅延によって、パフォーマンス問題(たとえば、各コンテンツ送信間に数秒など)が生じる場合がある。

いくつかの実装形態では、TCPソケットが接続される(たとえば、ステータスがLISTENからESTABLISHEDになる)とき、ソケットがサーバまたはクライアントによって明示的に閉じられるまで、BIPゲートウェイは、BIPチャネルを使用することができる。この時点で、BIPゲートウェイは、BIPチャネルをリリースし(たとえば、ステータスがESTABLISHEDからLISTENになる)、直ちに待ち行列の中の次のソケットのために同じBIPチャネルを使用し始める(たとえば、ステータスがLISTENからESTABLISHEDになる)ことができる。上記で説明したように、閉じた信号の受信の遅延があり得る。

したがって、BIPゲートウェイは、たとえばHTTPトランザクション(要求および対応する応答)などのデータ通信がいつ完了するかを検出し、TCPソケットが閉じられるのを必ずしも待たずに、データ通信が完了するとすぐに、次のソケットに切り替えるように構成されたトラフィックアナライザを含むデバイスに設けられる。たとえば、BIPゲートウェイは、応答が完了していることを検出すると、ソケット待ち行列の中に現在のソケットを移し、次のソケットにサービスし始めることができる。この実装形態は、開いており、使用されていないTCPソケットによって生じる遅延を低減する。

完了したデータ通信を検出する方法は、たとえばコンテンツ長ならびに送信されるバイト数などのHTTPヘッダ情報を分析するステップを含み得る。送信されるバイト数が予想されるコンテンツ長に等しくなると、BIPゲートウェイは、ソケットが閉じるのを待つよりむしろ、この時点で次のソケットに切り替えるように構成され得る。

添付の図面を参照しながら、新規のシステム、装置および方法の種々の態様が、以下にさらに十分に説明される。しかしながら、本教示の開示は、多くの異なる形態で具現化することができ、本開示全体にわたって提示される任意の特定の構造または機能に限定されるものと解釈されるべきではない。むしろ、これらの態様は、本開示が周到で完全になり、本開示の範囲を当業者に十分に伝えるように提供される。本明細書の教示に基づいて、本開示の範囲は、本発明の任意の他の態様とは無関係に実装されるか、本発明の任意の他の態様と組み合わせて実装されるかに関わらず、本明細書で開示する新規のシステム、装置および方法のいかなる態様をも包含するものであることを、当業者は諒解されたい。たとえば、本明細書に記載される任意の数の態様を用いて、装置を実装することができるか、または方法を実施することができる。さらに、本発明の範囲は、本明細書に記載の本発明の様々な態様に加えてまたはそれらの態様以外に、他の構造、機能、もしくは構造および機能を使用して実施されるそのような装置またはそのような方法を包含することが意図される。本明細書で開示するいずれの態様も、請求項の1つまたは複数の要素によって具現化され得ることを理解されたい。

特定の態様について本明細書で説明するが、これらの態様の多くの変形体および置換は本開示の範囲内に入る。好ましい態様のいくつかの利益および利点に言及するが、本開示の範囲は特定の利益、使用、または目的に限定されるものではない。むしろ、本開示の態様は、様々なワイヤレス技術、システム構成、ネットワーク、および送信プロトコルに広く適用可能であるものとし、そのうちのいくつかが例として図および好ましい態様についての以下の説明で示される。詳述される説明および図面は、本開示を限定するものではなく、単に例示するものであり、本開示の範囲は添付の特許請求の範囲およびその均等物によって規定される。

いくつかの実装形態では、アクセス端末は、セルラー電話、コードレス電話、セッション開始プロトコル(「SIP」)電話、ワイヤレスローカルループ(「WLL」)局、携帯情報端末(「PDA」)、ワイヤレス接続機能を有するもしくは有さないハンドヘルドデバイス、またはモデムに接続された何らかの他の適切な処理デバイスを含むことができる。したがって、本明細書において教示される1つまたは複数の態様は、電話(たとえば、セルラー電話またはスマートフォン)、コンピュータ(たとえば、ラップトップ)、ポータブル通信デバイス、ヘッドセット、ポータブルコンピューティングデバイス(たとえば、携帯情報端末)、娯楽デバイス(たとえば、音楽もしくはビデオデバイス、または衛星ラジオ)、ゲームデバイスまたはシステム、全地球測位システムデバイス、あるいはスマートカードを有するベアラ非依存プロトコルを介して通信するように構成される任意の他の適切なデバイスに組み込むことができる。

記述される特徴を含み得るそのようなデバイスは、スマートメータリングのために、またはスマートグリッドネットワークで使用され得る。そのようなデバイスは、センサアプリケーションを提供でき、またはホームオートメーションにおいて使うことができる。デバイスは、代わりに、または追加で、健康管理の場面において、たとえば個人の健康管理のために使うことができる。デバイスは、拡張範囲インターネット接続性(たとえば、ホットスポットとともに使用するため)を可能にするために、またはマシンツーマシン通信を実装するために、監視用に使うこともできる。

図1は、通信デバイスの一例の機能ブロック図を示す。通信デバイス100は、上記で説明したデバイスのうちの1つまたは複数として実装され得る。通信デバイス100は、スマートカード110を含む。スマートカード110は、ポート(図示せず)を介して設けられ得る。スマートカード110は、通信デバイス100に含まれるプロセッサを構成するために使用され得る情報を含むことができる。より詳細には、スマートカード110は、ベアラ非依存プロトコル通信のための構成情報を含むことができる。たとえば、スマートカード110は、スマートカードウェブサーバをインスタンス化するための命令を含むことができる。したがって、スマートカード110は、ベアラ非依存プロトコルチャネル115を介して通信することができる。ベアラ非依存プロトコルチャネル115は、ベアラ非依存プロトコルゲートウェイ120への通信経路を提供することができる。ベアラ非依存プロトコルゲートウェイ120は、ベアラ非依存プロトコルチャネル115を介してスマートカード110との間でベアラ非依存プロトコル通信を送受信するように構成され得る。ベアラ非依存プロトコルゲートウェイ120は、複数のベアラ非依存プロトコルチャネルを管理するように構成され得る。しかしながら、いくつかの実装形態では、ベアラ非依存プロトコルチャネルの数は、制限され得る。たとえば、ベアラ非依存プロトコルゲートウェイ120は、スマートカード110に関して3つのチャネルを維持するように構成され得る。

ベアラ非依存プロトコルゲートウェイ120は、パケットインターフェース125を介してパケットプロトコルスタック130に情報を送信するように構成され得る。図1に示すように、パケットインターフェース125は、TCP/IPパケットベースインターフェースでもよい。したがって、パケットプロトコルスタック130は、図示のように、TCP/IPプロトコルスタックである。

パケットプロトコルスタック130は、スマートカード110へのパケットベース通信経路を提供するように構成され得る。たとえば、パケットベース通信経路135aは、リモートクライアント140aがスマートカード110と通信することができるようにするために確立され得る。リモートクライアント140aは、ネットワーク上にあってよく、通信デバイス100によってアクセスされ得る。たとえば、リモートクライアント140aは、ネットワークオペレータによってホストされるデバイス(たとえば、サーバ)上で実行されるアプリケーションでもよい。リモートクライアント140aは、通信デバイス100に含まれるスマートカード110との間でデータを送受信するように構成され得る。

第2のパケットベース通信経路135は、ローカルアプリケーション140bがスマートカード110と通信することができるようにするために提供され得る。ローカルアプリケーション140bは、通信デバイス100に含まれるプロセッサ上で実行している可能性がある。ローカルアプリケーション140bの例には、ウェブブラウザ、電子ウォレットアプリケーション、カレンダーアプリケーションなどがある。

リモートクライアント140aおよびローカルアプリケーション140bは、クライアントと総称され得る。いくつかの実装形態では、スマートカード110は、クライアントによってアクセスされ得るサービスを提供することができる。たとえば、スマートカード110は、支払いサービスを提供することができる。スマートカード110が通信デバイス100と結合されると、クライアントは、スマートカード110に記憶された情報を送り、かつ/または受信することができる。リモートクライアント140aは、スマートカード110から要求があると、現在の残高情報を提供することができる。ローカルアプリケーション140bは、残高情報を含むインターフェースを表示することができる。

図2は、スマートカードへの例示的な通信経路の機能ブロック図を示す。図2に示すように、スマートカード110は、ベアラ非依存プロトコルゲートウェイ120に結合され得る。ベアラ非依存プロトコルゲートウェイ120とスマートカード110との間の結合は、チャネルと呼ばれ得る。このチャネルは、ベアラ非依存プロトコルに従ってデータを送信するように構成され得る。ベアラ非依存プロトコルゲートウェイ120は、複数のクライアントソケットとの間で情報を送受信するように構成され得る。パケットベース通信システムにおいて、ソケットは、一般に、クライアントとベアラ非依存プロトコルゲートウェイ120との間など、2つのエンティティ間の接続のポイントを指す。図2に示すように、第1のクライアントソケット202、第2のクライアントソケット204、および第3のクライアントソケット206がベアラ非依存プロトコルゲートウェイ120に結合される。追加のクライアントソケット208が含まれ得る。

各クライアントソケットは、データを要求するために使用され得る。たとえば、クライアントがHTMLページをロード中である場合、HTMLページは、たとえばテキスト、画像、ビデオ、オーディオ、および他のタイプのデータなど、様々な要素を含み得る。クライアントは、HTMLページの要素ごとに、ソケットを開き得る。各クライアントソケットは、異なるクライアントアプリケーションに関連付けられ得る。いくつかの実装形態では、1つまたは複数のソケットが同じクライアントアプリケーションに関連付けられ得る。

上記で説明したように、ベアラ非依存プロトコルゲートウェイ120が有する、スマートカード110と通信するためのチャネルは限られ得る。したがって、ソケットは、並行に処理されない場合がある。代わりに、通信デバイス100は、第1のクライアントソケット202の要求を処理し、完了すると、第2のクライアントソケット204の要求にサービスし始めるように構成され得る。

ベアラ非依存プロトコルゲートウェイ120は、クライアントソケットの要求がいつ完了したかを判断するように構成され得る。いくつかの実装形態では、クライアントソケットを介したセッションの完了を示す明示的な信号がクライアント(たとえば、140aまたは140b)によって送信され得る。いくつかの実装形態では、クライアントは、ソケットを介したあり得る将来の通信を予想して、クライアントで要求されたデータが受信された後、クライアントソケットを開いておく可能性がある。そのような実装形態では、ベアラ非依存プロトコルゲートウェイ120は、来ないかもしれない将来の通信を待つ可能性がある。したがって、ベアラ非依存プロトコルゲートウェイ120は、他のクライアントソケットからの要求の処理を遅延させる場合がある。

図3は、トラフィックアナライザを含む通信デバイスの一例の機能ブロック図を示す。図3に示すように、クライアントは、ウェブブラウザ302である。ウェブブラウザ302は、BIPゲートウェイ120に対して1つまたは複数のクライアントソケットを開けることができる。図示のように、3つのクライアントソケット304a、304bおよび304cが開かれている。ウェブブラウザ302は、たとえばクライアントソケット304を介したTCP/IPなど、パケットベースプロトコルを介して通信することができる。

ベアラ非依存プロトコルゲートウェイ120は、トラフィックアナライザ306を含み得る。トラフィックアナライザ306は、ベアラ非依存プロトコルゲートウェイ120に送られた、および/またはそこから送られたパケット通信を受信するように構成され得る。トラフィックアナライザ306は、データの1つまたは複数の特徴を識別し、クライアントソケット304間の切替えを管理するように構成され得る。トラフィックアナライザ306は、以下でさらに詳細に説明される。

トラフィックアナライザ306は、ベアラ非依存プロトコル/パケットコンバータ308に結合され得る。図3に示すように、パケットプロトコルは、TCP/IPである。ベアラ非依存プロトコル/パケットコンバータ308は、クライアントから受信されたパケットデータを構文解析して、スマートカード312に送信するための1つまたは複数のベアラ非依存プロトコル信号を生成するように構成され得る。ベアラ非依存プロトコル/パケットコンバータ308は、スマートカード312から受信されたベアラ非依存プロトコル信号を構文解析して、ウェブブラウザ302など、クライアントに送信するための1つまたは複数のパケットベース信号を生成するように構成され得る。

ベアラ非依存プロトコル/パケットコンバータ308は、ベアラ非依存プロトコルチャネル310に結合され得る。ベアラ非依存プロトコルチャネル310は、スマートカード312に情報を提供し、かつ/またはそこから情報を受信するように構成され得る。

いくつかの別個の構成要素が図3に示されているが、構成要素のうち1つまたは複数は、組み合わされるか、または共通して実装され得ることを当業者は認識するであろう。たとえば、ベアラ非依存プロトコル/パケットコンバータ308を用いて、ベアラ非依存プロトコル/パケットコンバータ308に関して先に説明された機能を実施するだけでなく、トラフィックアナライザ306に関して先に説明された機能を実施することもできる。さらに、図3に示される構成要素の各々は、複数の別個の要素を使用して実装され得る。

図4は、クライアントからスマートカードへの例示的な要求のプロセスフロー図を示す。ブロック405において、クライアントソケットが接続される。ブロック410で、通信デバイスは、データを受信する準備ができている。ブロック415で、データがソケットを介してクライアントから受信される。ブロック420で、より多くのデータが受信されることになるかどうかに関する判断が行われる。ブロック420での判断は、受信されたパケットデータに含まれるヘッダ情報に基づき得る。追加のデータが受信されることになる場合、フローは、上記のようにブロック415に進む。それ以上のデータが予想されない場合、フローはブロック425に進む。

ブロック425で、要求に応答して送信されることになるデータが準備される。たとえば、受信されたデータが画像ファイルを要求する場合、ブロック425で、画像ファイルが探し出され得る。ブロック430で、データがスマートカードから送信される。データは、上記で説明したように、ベアラ非依存プロトコルからパケットベースプロトコルに変換され得る。ブロック435で、トラフィックが分析され得る。トラフィックの分析は、図5に関して以下でさらに詳細に説明される。

より多くのデータが送信されることになることを分析が判断した場合、フローはブロック430に戻る。データ通信が完了したことを分析が判断した場合、プロセスはブロック440に進み、接続されたソケットが切り替えられる。接続されたソケットを切り替えることは、クライアントは開いているが、情報をまだスマートカードに送信し終わっていない1つのソケットを識別することを含み得る。切替えは、ソケットが待ち行列に入れられた順序、ソケットを介して保留中の要求、ソケットを開いているクライアント、通信されることになるデータに関連付けられた他の要因(たとえば、タイプ、量、前に送信されたデータとの関連)、通信に関連付けられたクライアント、またはソケットが開かれた順序に基づき得る。切り替えると、フローは、上記のようにブロック405に進む。

予想よりも多くのデータが送信されたことを分析が判断した場合、トラフィックアナライザは、クライアントソケットを介したデータ通信がいつ完了したかを正確に判断することができない場合がある。したがって、トラフィックアナライザは、使用不能にされ得、それによって、たとえばクライアントによってクライアントソケットが明示的に閉じられるまで、このソケットについての切替えを回避する。ブロック450で、ソケットは、タイムアウトまたはクライアントからのシグナリングなどを介して切断される。閉じると、フローは、上記のようにブロック405に進む。

図4のプロセスフローでわかるように、ソケットの切替えは、トラフィック分析に基づいて、明示的なソケットの切断の前に起こり得る。クライアントがデータ送信を受信した後にソケットを保持することができる実装形態では、ゲートウェイは、トラフィック分析に基づいて、切替えを行い、別のクライアントソケットを処理し始めることができる。

図5は、トラフィック分析の一例のプロセスフロー図を示す。図5に示したトラフィック分析プロセスは、上記のようにトラフィックアナライザ306で実装され得る。ブロック435で、トラフィックが分析され得る。トラフィックアナライザは、クライアントからのパケットデータ、またはスマートカードからの変換されたパケットデータを分析するように構成され得る。決定ブロック505で、より多くのデータが受信されるかどうかに関する判断が行われる。トラフィックアナライザがクライアントからの要求に応答して送信されるデータを分析している一実装形態では、クライアントからソケットを介して追加の情報が受信される場合、プロセスは、アナライザおよびしたがってトラフィックベースの切替えを使用不能にすることができる。クライアントから追加のデータが受信されなかった場合、フローはブロック510に進む。

ブロック510で、実行されることになる分析が識別される。分析は、通信デバイスに関連付けられたメモリに記憶され得る。分析は、クライアント、スマートカード、受信されたデータ、送信されたデータなどに基づいて識別され得る。分析は、分析を実行するためにデータからの値を構文解析するための情報を含むことができる。たとえば、情報は、当該の値を識別するためにパーサによって使用され得るヘッダフィールド名または位置(たとえば、文字位置)を識別することができる。

ブロック515で、構文解析情報は、分析のための値を識別するために適用され得る。たとえば、パーサは、HTTPおよび/またはTCP/IP分析基準を識別することができる。図5に示すように、分析は、ブロック520aのパケットヘッダ、およびパケットコンテンツ520bにおいて実行され得る。構文解析され、分析され得る例示的なヘッダフィールドは、コンテンツ長である。いくつかのパケットベースプロトコル(たとえば、HTTP)におけるコンテンツ長ヘッダフィールドは、送信されることになるデータの量を示し得る。たとえば、送信されるデータが画像ファイルである場合、ヘッダは、バイト単位の画像ファイルのサイズを含み得る。

ブロック525で、より多くのデータが予想されるかどうかに関する判断が行われる。コンテンツ長に基づく分析の例では、送信されるバイト数のカウンタが維持され得る。判断は、コンテンツ長ヘッダフィールドから抽出される値に対して送信されるバイト数を比較することを含み得る。送信される量がコンテンツ長ヘッダフィールドで指定されている値未満である場合、より多くのデータが予想され得る。そのような実装形態では、フローは、ブロック430に進んで、データ送信を続ける。

それ以上のデータが予想されない場合、フローはブロック530に進み、送信が予想されるデータ送信を上回ったかどうかに関する判断が行われる。たとえば、送信されるバイト数がコンテンツ長ヘッダフィールドで指定されている値よりも大きい場合、トラフィックアナライザは、データ通信がいつ完了するかを正確に判断することができない場合がある。したがって、フローは、ブロック445に進む場合があり、上記で説明したように、トラフィックアナライザが使用不能にされる。

より多くのデータが予想されず、データ送信が予想されるデータ送信を上回らない場合、トラフィックアナライザは、データ通信が完了している状況を正常に識別した可能性がある。この場合、フローは、ブロック440に進み、上記で説明したように、接続されたソケットが切り替えられ得る。

図5に示したフローはコンテンツ長ヘッダフィールドに基づいているが、他のヘッダフィールドまたはコンテンツの特徴がトラフィック分析のために使用されてもよい。たとえば、コンテンツヘッダタイプが画像データと識別され、コンテンツがテキストと識別される場合、アナライザは、使用不能にされ得る。いくつかのパケットベースプロトコルは、そのような実装形態では、カスタムのヘッダフィールドを許容することができ、カスタムのヘッダフィールドは、分析のための基礎として識別され得る。たとえば、カスタムのフィールドは、終了シーケンスを含み得る。終了シーケンスは、送信の終了を識別することができる。トラフィックアナライザは、送信の完了を判断するために終了シーケンスの存在を識別するように構成され得る。

図6は、切替え型ソケット通信セッションの一例のコールフロー図を示す。図6に示したコールフロー図は、上記のシステムに含まれ得るエンティティのうちのいくつかを示す。図6に示したエンティティは、スマートカード602、ベアラ非依存プロトコルゲートウェイ604、第1のクライアントソケット606、および第2のクライアントソケット608を含む。

スマートカード602は、ベアラ非依存プロトコルチャネルを開くために、信号605を送信することができる。信号605は、ベアラ非依存プロトコルゲートウェイ604に送信され得る。チャネルは、クライアントからの任意の通信の前に開かれ得る。第1のクライアントソケット606は、接続信号652をベアラ非依存プロトコルゲートウェイ604に送信することができる。ベアラ非依存プロトコルゲートウェイ604は、信号654を介してチャネルを確立し得る。ひとたび確立されると、第1のクライアントソケット606は、送信信号656をベアラ非依存プロトコルゲートウェイに送信することができる。送信信号656は、スマートカード602へのデータの要求であり得る。ベアラ非依存プロトコルゲートウェイ604は、この要求656をベアラ非依存プロトコルに変換し、データ利用可能信号658を送信することができる。応答して、スマートカード602は、受信されたデータ信号660、続いて端末応答信号662を送信することができる。端末応答信号662は、要求されるデータの全部または一部を含むことができる。いくつかの実装形態では、端末応答信号662は、要求されたデータが利用可能であることの肯定応答を含むことができる。ベアラ非依存プロトコルゲートウェイ604を介してクライアントソケット606とスマートカード602との間でデータを交換するために、追加のシグナリング664が実行され得る。シグナリングが実行されると、上記のように、ベアラ非依存プロトコルゲートウェイ604はトラフィックを分析することができる。

第2のクライアントソケット608は、ベアラ非依存プロトコルゲートウェイ604に接続するための信号666を送信することができる。図6に示すように、第1のクライアントソケット606は、第2のクライアントソケット608が信号666を送信するとき、依然としてデータを交換している可能性がある。ベアラ非依存プロトコルゲートウェイ604は、あたかもスマートカード602に対するチャネルが利用可能であるかのように、うまく接続を確立し、データをキャッシュするように構成され得る。ひとたび接続されると、第2のクライアントソケット608は、データ(たとえば要求)をベアラ非依存プロトコルゲートウェイ604に送ることができる。

信号670は、第1のクライアントソケット606によって送信された要求656に応答するさらなるデータを含み得る。ベアラ非依存プロトコルゲートウェイ604は、上記のように送られたデータを分析することができる。たとえば、ベアラ非依存プロトコルゲートウェイ604は、第1のクライアントソケット606とのHTTPトランザクションの終了を検出するために、データ送信をのぞき込むことができる。データは、信号672を介して第1のクライアントソケットに送信され得る。

図6に示すように、信号670および672を介して送られるデータは、第1のクライアントソケット606とのHTTPトランザクションの終了であり得る。信号674および676を介して、ベアラ非依存プロトコルゲートウェイ604は、第1のソケットを閉じること、および新しいソケットを開くことをシミュレーションすることができる。経路を閉じるために明示的な要求が第1のクライアントソケットから受信されていないことに留意されたい。信号678、680、および682は、第2のクライアントソケット608によって信号668で送信され、ベアラ非依存プロトコルゲートウェイ604によってキャッシュされる要求を含み得る。信号678、680、および682は、上記の信号、すなわち、信号658、660、および662と類似する。

第2のクライアントソケット608にサービスすることにこのように切り替えて、シグナリング684を介して第2のクライアントソケット608とスマートカード602との間で追加のデータが交換され得る。したがって、第2のクライアントソケット608は、明示的な閉じた信号686が第1のクライアントソケット606からベアラ非依存プロトコルゲートウェイ604に送信される前に、データをスマートカード602と交換することが可能である。

図7は、ソケット管理の方法のプロセスフロー図を示す。図7で示したプロセスは、図3におけるもの、または図8において下で示されるものなど、上記で説明したデバイスのうちの1つまたは複数の中で実装可能である。ブロック702において、データがアプリケーションから受信される。データは、少なくとも2つのソケットからパケットベースプロトコルを介して通信されることになる。たとえば、いくつかの実装形態では、HTTPを介して少なくとも2つのソケットからスマートカードへの通信が行われ得る。受信されたデータは、たとえば画像または他のファイルリソースについての要求など、情報の要求を含み得る。受信されたデータは、たとえば電子ウォレットを更新するためのトランザクション情報などサブミッションのための情報を含み得る。いくつかの実装形態では、受信されたデータは、応答を必要としない場合がある。いくつかの実装形態では、応答は、肯定応答値を含む信号を含み得る。

ブロック704で、ベアラ非依存プロトコルチャネルを介して少なくとも2つのソケットのうちの1つからデータが送信される。ブロック706において、データ応答が受信される。受信されたデータは、送信されたデータに少なくとも部分的に基づき得る。たとえば、受信されたデータは、画像の要求に応答して送信される画像ファイルでもよい。別の例として、通信がファイルリソースに関連付けられてない一実装形態では、応答は、肯定応答値を含むことができる。

ブロック708で、データ通信が完了しているかどうかに関する判断が行われる。判断は、受信されたデータ応答に少なくとも部分的に基づき得る。ブロック710で、データ通信が完了していることを判断が示す場合、ベアラ非依存プロトコルチャネルを介して少なくとも2つのソケットのうちの別の1つからデータが送信される。ブロック712で、データ通信が未完了であることを判断が示す場合、少なくとも2つのソケットのうちの1つからのデータ送信が続けられる。

図8は、ベアラ非依存プロトコルソケット管理のための例示的な装置の機能ブロック図を示す。ソケット管理装置は、図8に示される簡略化された装置800よりも多くのコンポーネントを有し得ることを、当業者は諒解するだろう。示される装置800は、特許請求の範囲内の実装形態のいくつかの顕著な特徴を説明するのに有用なコンポーネントのみを含む。装置800は、データ入出力回路802、クライアント入出力回路804、および分析回路806を含む。

データ入出力回路802は、ベアラ非依存プロトコルチャネルを介してデータを受信および送信するように構成され得る。データ入出力回路802は、比較器、フィルタ、プロセッサ、信号生成器、およびトランシーバのうちの1つまたは複数を含み得る。いくつかの実装形態では、データ通信のための手段は、データ入出力回路802を含み得る。

クライアント入出力回路804は、パケットベースプロトコルを介してアプリケーションとの間でデータを受信および送信するように構成され得る。クライアント入出力回路804は、プロセッサ、信号生成器、トランシーバ、および復号器のうちの1つまたは複数を含み得る。いくつかの実装形態では、クライアントアプリケーション通信のための手段は、クライアント入出力回路804を含み得る。

分析回路806は、データ入出力回路802とクライアント入出力回路804との間のデータ通信が完了しているかどうかを判断するように構成され得る。分析回路806は、クライアント入出力回路804によって管理されるソケットの切替えをもたらす信号を送信するように構成され得る。分析回路806は、メモリ、プロセッサ、比較器、演算ユニット、および信号生成器のうちの1つまたは複数を含み得る。いくつかの実装形態では、トラフィックを分析するための手段は分析回路806を含み得る。

本明細書で使用される場合、「判断すること」という用語は、多種多様な動作を包含する。たとえば、「判断すること」は、計算すること、算出すること、処理すること、導出すること、調査すること、探索すること(たとえば、テーブル、データベース、または別のデータ構造での探索)、確認することなどを含み得る。また、「判断すること」は、受信すること(たとえば、情報を受信すること)、アクセスすること(たとえば、メモリ内のデータにアクセスすること)などを含む可能性がある。また、「判断すること」は、解決すること、選択すること、選出すること、および確立することなどを含み得る。

本明細書で使用される場合、項目のリスト「のうちの少なくとも1つ」を指す句は、個々のメンバーを含む、それらの項目の任意の組合せを指す。一例として、「a、b、またはcのうちの少なくとも1つ」は、a、b、c、a-b、a-c、b-c、およびa-b-cをカバーするものとする。

上で説明された方法の様々な動作は、様々なハードウェアおよび/もしくはソフトウェア構成要素、回路ならびに/またはモジュールなど、動作を実行することができる任意の適切な手段によって実行することができる。一般に、図に示される任意の動作は、それらの動作を実行することが可能な対応する機能手段によって実行することができる。

本開示に関連して説明された種々の例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタルシグナルプロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ信号(FPGA)もしくは他のプログラマブル論理デバイス(PLD)、個別ゲートもしくはトランジスタロジック、個別ハードウェア構成要素、または本明細書において説明される機能を実施するように設計されたそれらの任意の組合せで実装または実行することができる。汎用プロセッサはマイクロプロセッサとすることができるが、代替形態では、プロセッサは、任意の市販のプロセッサ、コントローラ、マイクロコントローラ、または状態機械とすることができる。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装され得る。

1つまたは複数の態様では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つもしくは複数の命令またはコードとしてコンピュータ可読媒体上に記憶され、あるいはコンピュータ可読媒体を介して送信され得る。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む、コンピュータ記憶媒体と通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセス可能である任意の入手可能な媒体とすることができる。例であって、限定はしないが、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または、命令もしくはデータ構造の形態の所望のプログラムコードを搬送もしくは記憶するために用いることができ、コンピュータによってアクセス可能である、任意の他の媒体を含むことができる。また、当然、あらゆる接続がコンピュータ可読媒体と呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を用いて、ウェブサイト、サーバ、または他のリモートソースから送信される場合には、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。本明細書において用いられるとき、ディスク(disk)およびディスク(disc)は、コンパクトディスク(CD)、レーザーディスク(登録商標)、光ディスク、デジタル多用途ディスク(DVD)、フロッピー(登録商標)ディスク、およびブルーレイディスクを含み、ディスク(disk)は、通常、磁気的にデータを再生し、ディスク(disc)は、レーザーで光学的にデータを再生する。したがって、いくつかの態様において、コンピュータ可読媒体は、非一時的コンピュータ可読媒体(たとえば、有形媒体)を含む場合がある。さらに、いくつかの態様において、コンピュータ可読媒体は、一時的コンピュータ可読媒体(たとえば、信号)を含む場合がある。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべ
きである。

本明細書で開示する方法は、説明した方法を実現するための1つもしくは複数のステップまたは動作を含む。方法のステップおよび/またはアクションは、特許請求の範囲から逸脱することなく、互いと交換され得る。言い換えると、ステップまたは動作の特定の順序が指定されていない限り、特定のステップならびに/または動作の順序および/もしくは使用は、特許請求の範囲から逸脱することなく修正され得る。

説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアにおいて実装される場合には、それらの機能は、コンピュータ可読媒体上に1つまたは複数の命令として記憶することができる。記憶媒体は、コンピュータによってアクセス可能である任意の入手可能な媒体とすることができる。例であって、限定はしないが、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または、命令もしくはデータ構造の形態の所望のプログラムコードを搬送もしくは記憶するために用いることができ、コンピュータによってアクセス可能である、任意の他の媒体を含むことができる。本明細書において用いられるとき、ディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)、およびブルーレイ(登録商標)ディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザーで光学的に再生する。

したがって、いくつかの態様は、本明細書で提示する動作を実行するためのコンピュータプログラム製品を備えてよい。たとえば、そのようなコンピュータプログラム製品は、命令が記憶された(および/または符号化された)コンピュータ可読媒体を備えることができ、それらの命令は、本明細書において説明される動作を実行するために1つまたは複数のプロセッサによって実行可能である。特定の態様の場合、コンピュータプログラム製品はパッケージング材料を含むことができる。

ソフトウェアまたは命令は、伝送媒体上で送信されてもよい。たとえば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を用いて、ウェブサイト、サーバ、または他のリモートソースから送信される場合には、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。

さらに、本明細書で説明された方法および技法を実行するためのモジュールおよび/または他の適切な手段は、適用可能な場合、デバイスおよび/またはスマートカードによってダウンロードされ、かつ/またはその他の方法で取得され得ることを諒解されたい。たとえば、そのようなデバイスは、本明細書において説明された方法を実行するための手段の転送を容易にするために、サーバに結合することができる。あるいは、本明細書で説明した様々な方法は、結合されたデバイスおよび/またはスマートカードが、記憶手段をデバイスに結合したすぐ後に、または提供したすぐ後に、様々な方法を取得することができるように、記憶手段(たとえば、RAM、ROM、コンパクトディスク(CD)またはフロッピー(登録商標)ディスクなどの物理的記憶媒体など)を介して提供され得る。その上、本明細書で説明される方法および技法をデバイスに提供するための任意の他の適切な技法が利用されてもよい。

特許請求の範囲は、上で示された厳密な構成および構成要素に限定されないことを理解されたい。特許請求の範囲から逸脱することなく、上記で説明した方法および装置の構成、動作および詳細において、様々な修正、変更および変形を行うことができる。

上記の内容は本開示の態様に向けられてきたが、本開示の他の態様およびさらなる態様は、本開示の基本的な範囲から逸脱することなく考案することができ、本開示の範囲は、以下の特許請求の範囲によって決定される。

100 通信デバイス
110 スマートカード
115 ベアラ非依存プロトコルチャネル
120 ベアラ非依存プロトコルゲートウェイ
125 パケットインターフェース
130 パケットプロトコルスタック
135a パケットベース通信経路
135 第2のパケットベース通信経路
140a リモートクライアント
140b ローカルアプリケーション
202 第1のクライアントソケット
204 第2のクライアントソケット
206 第3のクライアントソケット
302 ウェブブラウザ
304a クライアントソケット
304b クライアントソケット
304c クライアントソケット
306 トラフィックアナライザ
308 ベアラ非依存プロトコル/パケットコンバータ
310 ベアラ非依存プロトコルチャネル
312 スマートカード
602 スマートカード
604 ベアラ非依存プロトコルゲートウェイ
605 信号
606 第1のクライアントソケット
608 第2のクライアントソケット
652 接続信号
654 信号
656 送信信号
658 データ利用可能信号
660 データ信号
662 端末応答信号
664 追加のシグナリング
666 信号
670 信号
686 閉じた信号
800 装置
802 データ入出力回路
804 クライアント入出力回路
806 分析回路

Claims (22)

1. ソケット管理の方法であって、
   少なくとも2つのソケットからパケットベースプロトコルを介して通信されるべきデータをアプリケーションから受信するステップと、
   ベアラ非依存プロトコルチャネルを介して前記少なくとも2つのソケットのうちの1つからデータを送信するステップと、
   前記送信されたデータに少なくとも部分的に基づいてデータ応答を受信するステップと、
   前記受信されたデータ応答に少なくとも部分的に基づいてデータ通信が完了しているかどうかを判断するステップと、
   データ通信が完了していることを前記判断が示す場合、前記ベアラ非依存プロトコルチャネルを介して前記少なくとも2つのソケットのうちの別の1つを介してデータを送信するステップと、
   データ通信が未完了であることを前記判断が示す場合、前記少なくとも2つのソケットのうちの前記1つを介したデータの送信を続けるステップと
   を含む方法。
2. 前記データ通信が、前記アプリケーションと、加入者識別モジュールカード、汎用加入者識別モジュールカード、汎用集積回路カード、取外し可能なユーザ識別モジュール、CDMA加入者識別モジュールカードのうちの1つまたは複数との間のものである、請求項1に記載の方法。
3. 前記パケットベースプロトコルがHTTPである、請求項1に記載の方法。
4. 前記アプリケーションから受信された前記データがHTTP要求を含む、請求項3に記載の方法。
5. 前記少なくとも2つのソケットがTCP/IPソケットを含む、請求項1に記載の方法。
6. 前記受信されたデータ応答に基づいてパケットベース送信のための信号を生成するステップをさらに含む請求項1に記載の方法。
7. データ通信が完了しているかどうかを判断するステップが、
   前記受信されたデータ応答から値を抽出するステップと、
   前記抽出された値を前記少なくとも2つのソケットのうちの前記1つに関連付けられる値と比較するステップと
   を含む請求項1に記載の方法。
8. 前記値を抽出するステップが、前記受信されたデータ応答のヘッダフィールドに含まれる値を抽出するステップを含む、請求項7に記載の方法。
9. 前記値を抽出するステップが、前記受信されたデータ応答の本体に含まれる値を抽出するステップを含む、請求項7に記載の方法。
10. データ通信が完了しているかどうかを判断するステップが、データ通信が完了していると判断する前に、前記少なくとも2つのソケットのうちの前記1つを介して追加のデータが受信される場合、前記アプリケーションから受信された信号に基づいて、データ通信が完了しているかどうかを判断するステップを含む、請求項1に記載の方法。
11. ソケット接続を管理するための装置であって、
    少なくとも2つのソケットからパケットベースプロトコルを介して通信されるべきデータをアプリケーションから受信するように構成されたクライアント回路と、
    ベアラ非依存プロトコルチャネルを介して前記少なくとも2つのソケットのうちの1つからデータを送信し、
    前記送信されたデータに少なくとも部分的に基づいてデータ応答を受信する
    ように構成されたカード回路と、
    前記受信されたデータ応答に少なくとも部分的に基づいてデータ通信が完了しているかどうかを判断するように構成されたトラフィックアナライザと
    を備え、
    前記クライアント回路が、データ通信が完了していることを前記判断が示す場合、前記ベアラ非依存プロトコルチャネルを介して前記少なくとも2つのソケットのうちの別の1つを介してデータを送信するように構成され、
    前記クライアント回路が、データ通信が未完了であることを前記判断が示す場合、前記少なくとも2つのソケットのうちの前記1つを介したデータの送信を続けるように構成される
    装置。
12. 前記データ通信が、前記アプリケーションと、加入者識別モジュールカード、汎用加入者識別モジュールカード、汎用集積回路カード、取外し可能なユーザ識別モジュール、CDMA加入者識別モジュールカードのうちの1つまたは複数との間のものである、請求項11に記載の装置。
13. 前記パケットベースプロトコルがHTTPである、請求項11に記載の装置。
14. 前記アプリケーションから受信された前記データがHTTP要求を含む、請求項13に記載の装置。
15. 前記少なくとも2つのソケットがTCP/IPソケットを含む、請求項11に記載の装置。
16. 前記カード回路が、受信された前記データに基づいてパケットベース送信のための信号を生成するようにさらに構成される、請求項11に記載の装置。
17. データ通信が完了しているかどうかを判断することが、
    前記受信されたデータ応答から値を抽出することと、
    前記抽出された値を前記少なくとも2つのソケットのうちの前記1つに関連付けられる値と比較することと
    を含む請求項11に記載の装置。
18. 前記値を抽出することが、前記受信されたデータ応答のヘッダフィールドに含まれる値を抽出することを含む、請求項17に記載の装置。
19. 前記値を抽出することが、前記受信されたデータ応答の本体に含まれる値を抽出することを含む、請求項17に記載の装置。
20. データ通信が完了しているかどうかを判断することが、前記トランザクションが完了していると判断する前に、前記少なくとも2つのソケットのうちの前記1つを介して追加のデータが受信される場合、前記アプリケーションから受信された信号に基づいて、前記トランザクションが完了しているかどうかを判断することを含む、請求項11に記載の装置。
21. ソケット接続を管理するための装置であって、
    少なくとも2つのソケットからパケットベースプロトコルを介して通信するためのデータをアプリケーションから受信するように構成されたクライアントアプリケーション通信のための手段と、
    ベアラ非依存プロトコルチャネルを介して前記少なくとも2つのソケットのうちの1つからデータを送信し、
    前記送信されたデータに少なくとも部分的に基づいてデータ応答を受信する
    ように構成されたデータ通信のための手段と、
    前記受信されたデータ応答に少なくとも部分的に基づいてデータ通信が完了しているかどうかを判断するように構成されたトラフィックを分析するための手段と
    を備え、クライアントアプリケーション通信のための前記手段が、データ通信が完了していることを前記判断が示す場合、前記ベアラ非依存プロトコルチャネルを介して前記少なくとも2つのソケットのうちの別の1つを介してデータを送信するようにさらに構成され、
    クライアントアプリケーション通信のための前記手段が、データ通信が未完了であることを前記判断が示す場合、前記少なくとも2つのソケットのうちの前記1つを介したデータの送信を続けるように構成される
    装置。
22. 装置のプロセッサによって実行可能な命令を含むコンピュータ可読記憶媒体であって、前記命令によって、前記装置は、
    少なくとも2つのソケットからパケットベースプロトコルを介して通信するためのデータをアプリケーションから受信し、
    ベアラ非依存プロトコルチャネルを介して前記少なくとも2つのソケットのうちの1つからデータを送信し、
    前記送信されたデータに少なくとも部分的に基づいてデータ応答を受信し、
    前記受信されたデータ応答に少なくとも部分的に基づいてデータ通信が完了しているかどうかを判断し、
    データ通信が完了していることを前記判断が示す場合、前記ベアラ非依存プロトコルチャネルを介して前記少なくとも2つのソケットのうちの別の1つを介してデータを送信し、
    データ通信が未完了であることを前記判断が示す場合、前記少なくとも2つのソケットのうちの前記1つを介したデータの送信を続ける
    コンピュータ可読記憶媒体。

Images