JP2011505606A - 表形式データストリームプロトコルの行におけるヌル列の圧縮 - Google Patents

Abstract

ヌル列を有する行の効率的な伝送を可能にすることにより、表形式データストリーム（ＴＤＳ）プロトコルを向上させるシステムおよび方法。識別コンポーネントは、送信される列を受信側（例えばクライアント）に示すために、行の先頭の位置に置くことができるビットマップを利用する。従って、ヌルでない列とヌルである列の区別することによって、ヌルでない列の送信が追随して、伝送資源を効果的に利用することができる。

Description

本発明は、クライアントとサーバシステムとの間の要求および応答の転送のために利用されるメッセージ指向のアプリケーションレベルプロトコルである、表形式データストリーム（Ｔａｂｕｌａｒ Ｄａｔａ Ｓｔｒｅａｍ：ＴＤＳ）プロトコルに関する。

コンピュータ技術（例えば、マイクロプロセッサ速度、記憶容量、データ転送帯域幅、ソフトウェア機能性など）における進歩は、様々な産業において増大するコンピュータの利用に一般に寄与している。その結果、コンピュータシステムの構成は劇的に変化している。あらゆるユーザが自分の業務を持ち込むような、単一の大型コンピュータによる大型コンピュータセンターの概念は、時代遅れである。同様に、ＤＢＭＳ（Ｄａｔａ Ｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ：データベース管理システム）は、集中型メインフレーム環境から、非集中または分散環境にずいぶん前に推移している。例えば、１つ以上のＰＣ「クライアント」システムは、ネットワークを介して、１つ以上のサーバベースのデータベースシステム（構造化照会言語−ＳＱＬデータベースサーバ）に接続することができる。コンピュータネットワークの既知の例は、コンピュータが地理的に相互に接近している（例えば同じ建物における）ＬＡＮ（Ｌｏｃａｌ−Ａｒｅａ Ｎｅｔｗｏｒｋ）や、コンピュータが遠く離れており電話回線または電波によって接続されるＷＡＮ（Ｗｉｄｅ−Ａｒｅａ Ｎｅｔｗｏｒｋ）を含む。

多くの場合、ネットワークは、ネットワーク上のコンピュータを「クライアント」または「サーバ」として分類するように、「クライアント／サーバ」ネットワークとして構成される。サーバは、ストレージ（例えばディスクドライブ）、プリンタ、モデムまたは同種のものなどのような共有資源の管理専用の有力なコンピュータまたはプロセスである。サーバは、サーバタスクを除いて事実上他のタスクを実行しないという意味で、多くの場合専用である。例えば、データベースサーバは、様々なクライアントからのデータベース照会（ｑｕｅｒｙ）を処理するようにデータベース情報を管理する。クライアントサーバのアーキテクチャのクライアント部分は、典型的には、動作を実行するためにサーバに依存するＰＣまたはワークステーションを含む。典型的には、クライアントは、特定のデータベース情報を返すような、いくつかの動作を実行するためにサーバに依存する「クライアントアプリケーション」を稼働する。当該ネットワークを通して、様々な要求・応答プロトコルは、所定の一連のルールに従って情報を移送する。

そのような要求・応答プロトコルの１つは、クライアントとサーバシステムとの間の要求および応答の転送のために利用されるメッセージ指向のアプリケーションレベルプロトコルである、表形式データストリーム（Ｔａｂｕｌａｒ Ｄａｔａ Ｓｔｒｅａｍ：ＴＤＳ）プロトコルである。ＴＤＳは、文字列型（ｃｈａｒ）、可変長文字列型（ｖｃｈａｒ）、バイナリ型（ｂｌｏｂ）、日付時間型、タイムスタンプ型、ベンダ固有データ型および同種のものなどのような、従来のＳＱＬデータ型のためのネイティブサポートを含むことができる。ＴＤＳを利用するシステムにおいて、サーバ（例えばデータベース）と永続的な接続を確立することは、クライアント（例えばユーザまたはアプリケーションプログラム）にとって典型的である。適切にサポートされたトランスポート／セッションレベルプロトコルを介して接続の成功したハンドシェークおよび確立に際して、完了応答がサーバからクライアントに伝わった後、完了メッセージがクライアントからサーバに転送される。

本発明の目的とするところは、サーバからクライアントへの照会結果（ｑｕｅｒｙ ｒｅｓｕｌｔ）の伝送の間のビット数を削減するために、ヌル列を指定する識別コンポーネントを介して、行の効率的な伝送を可能にすることによりＴＤＳプロトコルを向上させることにある。

下記では、本明細書のいくつかの態様の基本的な理解を提供するために、本明細書の簡易化された発明の概要を提示する。この発明の概要は、本明細書の他方面にわたる概要ではない。本明細書の主要または重要な構成要素を識別しないし、本明細書の範囲を規定するものでもない。その唯一の目的は、後で提示する「発明を実施するための形態」への前置きとして、簡易化された形態で本明細書のいくつかの概念を提示することにある。

本発明は、サーバからクライアントへの照会結果（ｑｕｅｒｙ ｒｅｓｕｌｔ）の伝送の間のビット数を削減するために、ヌル列を指定する識別コンポーネントを介して、行の効率的な伝送を可能にすることによりＴＤＳプロトコルを向上させるものである。当該識別コンポーネントは、送信される列を受信側（例えば、クライアント）に示すために、行の先頭の位置に置くことができるビットマップを利用する。従って、ヌルでない列とヌルである列を区別し、続いてヌルでない列を送信することによって、伝送資源を効果的に利用することができる。

関連する態様において、識別コンポーネントは、列がヌルであるか否かを示すために、各列のビットを含むヘッダ部分を利用することができる。当該ヘッダ部分は、サーバから最初に送信することができ、データの行が続く伝送される列の数を示すことができる。そのため、前もって送信される行を最初に検査することによって、関連するビットマップが計算される。このビットマップはヌル列を識別し、従って、当該ヌル列を伝送しないことによって、スペースを節約することができ、効率を改善できる。

さらなる方法によれば、要求を、最初にサーバに送信することができる。次に、サーバは、結果セットを実現し、かつデータの列などのようなデータのレイアウトを指定する要求（例えば、表と表の間の結合、関連する動作、および同種のもの）を処理する。典型的には、サーバからクライアントに送信される結果は、その中に列および行をいくつでも含むことができる。当該結果セットは異なるアイテム間の結合の結果であり、表に格納することができる。次に、表と関連する行は、表と関連する行毎に（ｏｎ ａ ｒｏｗ−ｂｙ−ｒｏｗ ｂａｓｉｓ）ビットマップを計算するために最初に検査することができる。次に、結果セットのためのメタデータ（どのような列が来るかを指定する）が、クライアントに最初に送信され、続いて結果セットと関係するデータの行が送信される。

さらに、情報は、列に関して実際の列およびメタデータを示す応答として、最初にネットワーク層に伝送することができる。従って、結果セットの伝送の前に、クライアントには、転送される列の数（例えば、行の中の列の数）が通知される。従って、当該メタデータを最初に送信することにより、クライアントは、受信される列の数について認識するようになる。関連する態様において、ヌルを許可する列が所定の閾値を超える場合、本発明によるヌルの圧縮が利用される。

前述及び関連する目的を達成するために、本発明は、以下に説明する特徴を含む。以下の説明および添付の図面は、本発明のある例示の態様を詳細に説明する。しかしながら、これらの態様は、本発明の原理が利用され得る様々な方法のうちのごくわずかのもののみを示すものである。図面と共に検討すれば、本発明の他の態様、利点、新規の特徴は、以下の本発明の詳細な説明から明らかになるであろう。

本発明の一態様による照会（ｑｕｅｒｙ）に対する結果セットの効率的な伝送を可能にする例示的な表形式データストリーム（Ｔａｂｕｌａｒ Ｄａｔａ Ｓｔｒｅａｍ：ＴＤＳ）プロトコルを示す図である。 本発明のＴＤＳプロトコルの一部として識別コンポーネントを示す図である。 本明細書の一態様によるビット圧縮の例を示す図である。 本発明の一態様による圧縮した方式において照会結果を送信する方法を示す図である。 ヌル圧縮トークンでデータを伝送する方法を示す図である。 クライアントサーバがデータを効率的に伝送することを可能にする識別コンポーネントの一部として例示的なバッファヘッダ配列を示す図である。 本発明の一態様による識別コンポーネントに関連する人工知能（ＡＩ）コンポーネントを示す図である。 本発明の一態様による拡張ＴＤＳプロトコルを実装する例示的なシステムを示す図である。 本発明の様々な態様を実施するための例示的な環境を示す図である。 本発明の一態様による、ヌルでない転送列のために利用することができるサンプルコンピューティング環境の概略ブロック図である。

本発明の様々な態様を、添付の図面を参照して説明する。同様の参照番号は同様のまたは対応する構成要素を全体にわたって示す。しかしながら、参照番号に関連する図面および詳細な説明が、開示された特定の形態に本発明を限定するようには意図されないことは理解されるべきである。むしろ、本発明の趣旨および範囲内の変更、等価物および代替手段をすべて包含することを意図している。

図１は、本発明の一態様による拡張ＴＤＳ（Ｔａｂｕｌａｒ Ｄａｔａ Ｓｔｒｅａｍ）プロトコル１２０を利用するシステム１００のブロック図である。サーバ１４０による照会結果の伝送の前に、クライアント１３０には、転送される列の数（例えば、行の中の列の数）が通知される。従って、そのようなメタデータを最初に送信することにより、クライアント１３０は、受信する列の数を認識するようになる。さらに、ヌルでない列とヌルである列を識別し、続いてヌルでない列を送信することにより、伝送資源を効果的に利用することができる。拡張ＴＤＳプロトコル１２０は、識別コンポーネント１３５を介して、ヌル列を有する行のそのような効率的な伝送を可能にする。識別コンポーネント１３５は、ヌル列を指定して、サーバ１４０からクライアント１３０に照会結果を伝送する間のビット数を削減する。本明細書では、サーバからクライアントへの通信という文脈において主にヌル圧縮について説明するが、クライアントからサーバなどの逆の通信も、本発明の範囲内にあることは十分に理解されよう。

システム１００は、複合モデルに基づいたデータベース構造とすることができるデータストレージシステム１１０に関連する。アイテム、サブアイテム、プロパティおよび関連は、複合型のインスタンスとして、データストレージシステム内の情報の表示を可能にするように定義される。例えば、データストレージシステム１１０は、リッチオブジェクト（ｒｉｃｈ ｏｂｊｅｃｔ）、永続オブジェクト（ｐｅｒｓｉｓｔｅｄ ｏｂｊｅｃｔ）およびオブジェクト間のリンクを作成し管理するための一連の基本構成要素を利用することができる。アイテムは、データストレージシステム１１０内で一貫性の最も小さなユニットとして定義することができ、独立して保護され、連続化され（ｓｅｒｉａｌｉｚｅｄ）、同期化され、コピーされ、バックアップ／リストアされることができる。当該アイテムは、型のインスタンスを含むことができ、データストレージシステム１１０内のすべてのアイテムは、アイテムの単一のグローバルな範囲（ｅｘｔｅｎｔ）に格納することができる。さらに、データストレージシステム１１０は、少なくとも１つのアイテムおよび／またはコンテナ構造に基づくことができ、アイテムとしてファイル内に埋め込むリッチメタデータを明らかにする（ｅｘｐｏｓｅ）ストレージプラットフォームとして作用することができる。データストレージシステム１１０は、上述した機能をサポートするデータベース（図示せず）を含むことができ、任意の適切な特性および／または属性を実装することができる。さらに、データストレージシステム１１０は、コンテナ階層構造を利用することができる。コンテナとは、少なくとも１つの他のアイテムを含むことができるアイテムである。このような包含概念（Ｃｏｎｔａｉｎｍｅｎｔ Ｃｏｎｃｅｐｔ）は、関連するクラスの内部のコンテナＩＤプロパティを介して実施することができ、記憶装置（ｓｔｏｒｅ）は、物理的かつ組織的で管理しやすいユニットの形態であるコンテナでもありえる。さらに、当該記憶装置は、階層構造内にコンテナのツリーのためのルートコンテナを表現する。図１に示すように、拡張ＴＤＳ１２０は、識別コンポーネント１３５を利用し、ヌルでない列とヌルである列を区別し、続いて、ヌルでない列を送信する。従って、伝送資源を効果的に利用することができる。

図２は、本発明の一態様によるＴＤＳプロトコル２２２の一部として特定の識別コンポーネント２２０を図示している。識別コンポーネント２２０は、送信される列を受信側（例えば、クライアント２２１）に示すために、行２０４、２０６および２０８（１からｎ、ここでｎは整数である）の先頭に位置に置くことができるビットマップを利用する。識別コンポーネント２２０は、ヌルビット圧縮トークン（Ｎｕｌｌ Ｂｉｔ Ｃｏｍｐｒｅｓｓｉｏｎ ｔｏｋｅｎ）（ＮＢＣＲｏｗ）を利用することができる。当該ヌルビットマップ圧縮は、各列がヌルであるかまたはヌルでないかを指定するために単一ビットを用いることにより、さらに行２０４、２０６、２０８からヌル列値をすべて取り除くことにより実施される。行２０４、２０６、２０８からヌル列値（ヌルインスタンス当たり８バイトまでありうる）を取り除くことは、本発明の一態様による圧縮をもたらす。当該ヌルビットマップは、以下に詳細に記述されるような列メタデータ（例えば、ＣＯＬＭＥＴＡＤＡＴＡのＴＤＳトークン）内に定義された各列の１ビットを含む。列メタデータとは、列に関連するメタデータである。例えば、ヌルビットマップにおいて、１のビット値は、列がヌルであるため行の中に存在していないことを示す。同様に、典型的には、０のビット値は、列がヌルではなく、従って行２０４、２０６、２０８の中に存在することを示すことができる。さらに、当該ヌルビットマップは、典型的には、８ビットの最も近い倍数に丸めることができ、ヌルビットマップの最終バイトにおいてヌルビットマップの端部に残りの予約ビット１〜７が存在することができる。例えば、ＴＤＳプロトコル２２２は、次のものを実装することができる。

トークンストリームコメント（Token Stream Comment）
トークン値は、０ｘＤ２／２１０である。

トークンストリーム特定ルール（Token Stream Specific Rules）
ＴｏｋｅｎＴｙｐｅ：＝ＢＹＴＥ；
ＮｕｌｌＢｉｔｍａｐＢｉｔＣｏｕｎｔ：＝結果セット内の列の数；
ＮｕｌｌＢｉｔｍａｐＢｙｔｅＣｏｕｎｔ：＝（ＮｕｌｌＢｉｔｍａｐＢｉｔＣｏｕｎｔ＋７）／８；
ＮｕｌｌＢｉｔｍａｐ：＝ＮｕｌｌＢｉｔｍａｐＢｙｔｅＣｏｕｎｔ×ＢＹＴＥ；
ＣｏｌｕｍｎＤａｔａ：＝単一の非ヌル列値のためのデータのバイト；
ＡｌｌＣｏｌｕｍｎＤａｔａ：＝｛ＣｏｌｕｍｎＤａｔａ｝；
ＮＢＣＲＯＷ：＝ＴｏｋｅｎＴｙｐｅ、ＮｕｌｌＢｉｔｍａｐ、ＡｌｌＣｏｌｕｍｎＤａｔａ

ヌル圧縮した行および通常の行は、同一の結果セットにおいて混合することができる。ＣｏｌｕｍｎＤａｔａは、データの各非ヌル列のために一度繰り返すことができる。バイトの節約がない場合、例えば、結果セットにヌル値を許可するカラムがない場合または結果セット内の特定の行にヌル値がない場合は、サーバ２２３はＮＢＣＲＯＷトークンを送信しないようにすることができる。さらに、ＮＢＣＲＯＷトークンおよびＲＯＷトークンは、同一の結果セットにおいて混合することができる。

例えば、特定の列がヌルであるか否かを判断する場合、列がＣＯＬＭＥＴＡＤＡＴＡトークンのＣｏｌｕｍｎＤａｔａセクション内に現われるときに、０から６５５３４までのゼロベース方式のインデックスを用いて、左から右に配列されたすべての列を検討する。そのため、ヌルビットマップは、以下のバイトおよびビットレイアウトにおけるゼロビットを用いて、列がヌルであることを示す。

従って、第１のバイトは、ゼロ番目の列を示すバイト内の最下位（あるいは右端の）ビット、および７番目の列を示すバイト内の最上位（あるいは左端の）ビットと共に、列０〜７についてのフラグを含むであろう。列インデックス８は、最下位ビットとして第２のバイトなどにあるであろう。一般に、ヌルビットマップのビットが設定される場合、列はヌルであり、行の中で列のヌルトークン値は続くことができない。ヌルビットマップのビットがクリアである場合、列はヌルではなく、行の中で列の値は続く。

図３は、本発明の一態様による識別コンポーネント３２０の特定の態様を例示している。識別コンポーネント３２０は、配列３１０内でヌルが使用するスペースを低減して、より圧縮した配列３３０（例えば、データ型に依存するヌルインスタンス当たり１〜８バイト）を作成することができる。配列３１０は、行においてヌル列インスタンス当たり８バイトまでを用いることができる。例えば、１０００ヌルｖａｒｃｈａｒ（最大）列を有する結果セットは、当該ヌルを表現するために１行当たり８０００バイトを用いることができる。識別コンポーネント３２０は、ＴＤＳ行配列３３０において圧縮される実質的に多数のヌルを有する結果セットにより、全体的性能およびネットワーク帯域幅を改善することができる。

さらに、本発明のＴＤＳ行フォーマット３３０において、ヌルビットマップ圧縮ヌル値は、行の内部で典型的には送信されない。より正確に言えば、ＮＢＣＲｏｗへの次のビットを識別するトークン３１５は、例えば、（１列当たり１ビットを用いて）どの列がヌルであるか、および／またはどの列がヌルでないかを示すために、行の先頭で利用することができる。さらに、非ヌル列値は、ＲＯＷトークンにおけるのと同一の方式において送信することができる。

図４は、本発明の一態様による、効率的な伝送のためのデータ圧縮の関連する方法４００を図示している。例示的な方法が様々なイベントおよび／または動作の一連のブロック表現として本明細書に図示され、記述されるが、本発明は当該ブロックの図示する順序に限定されない。例えば、本発明によるいくつかの動作またはイベントが、本明細書に図示された順序とは別に、他の動作またはイベントと異なる順序および／または同時に発生してもよい。さらに、すべての図示するブロック（イベントまたは動作）は、本発明による方法を実施するように要求されるとは必ずしも限らない。さらに、本発明による典型的な方法および他の方法が、本明細書に図示し、記述した方法と共同することはもちろん、図示や記述がされていない他のシステムおよび装置と共同して実施されてもよいことは十分に理解されるであろう。４１０において、クライアントは、例えば、ネットワーク上のログオンデータストリームの送信を介して、サーバとの接続を開始する（例えば、ハンドシェークの開始）。クライアントからサーバへの当該通信は、複数のコマンドを含むことができ、サーバからの応答は、複数の結果セットを戻すことができる。開始された当該通信において、セッション要素、プレゼンテーション要素および応用サービス要素は、４２０においてＴＤＳにより供給される。次に４３０において、サーバは、クライアントによる接続要求に肯定応答することができる。

続いて４４０において、照会に関連した結果セットは、ヌル圧縮形式において送信することができる。ヌルビットマップ圧縮は、各列がヌルであるかヌルでないかを指定するために、単一ビットを用いることにより、および行からヌル列値をすべて取り除くことにより実施することができる。行からヌル列値（１つのヌルインスタンス当たり８バイトまでありうる）を取り除くことは、本発明の一態様による圧縮を提供する。

図５は、本発明の一態様による、ヌル列により行を効率的に伝送するためにＴＤＳを向上させる特定の方法５００を図示している。初めに５１０において、どの列が到着するか、およびどれがヌル値を含むことができるかを明らかにする結果セットのためのメタデータを指定することができる。例えば、メタデータは、どの列がヌルを許可するかを示すことができる。その後、当該情報は、列に関して実際の列およびメタデータを示す応答として、ネットワーク層に伝送することができる。従って、伝送結果を設定する前に、クライアントには、５２０において、転送される列の数（例えば行の中の列の数）が通知される。５３０において、ヌル列の数が所定の閾値を超えているか判定がなされる。超えていなければ、本方法は動作５３５に進み、データはヌル圧縮なしで伝送することができる。超えていれば、本方法５００は動作５４０に進み、ヌルでない列とヌルである列を区別し、続けてヌルでない列を送信することにより、伝送資源を効果的に利用することができる。

図６は、サーバからクライアントへの照会結果の伝送の間にビット数を削減するために、ヌル列を指定する識別コンポーネント６１０の一部として、例示的なバッファヘッダ配列６００を図示している。クライアントからサーバへのコールは、サーバに１つ以上のパラメータを送信することができ、所定のヘッダ部分は、値パラメータ、列、データ型、行、バイナリフォーマットおよび関連するバッファの型を定義することができる。

典型的には、バッファ６００は同時に書き込まれたか、または読み取られたユニットであり、「パケット」としてモデル化することができ、メッセージは、１つ以上のバッファから成ることができる。バッファは、メッセージを含むバッファデータ６０４が続くことができるバッファヘッダ６０２を含むことができる。さらに、各新規のメッセージは、新規のバッファにおいてスタートすることができる。

一般に、クライアントとサーバの両方は、データで満ちたバッファを読み取ることを試みて、さらに多くの（あるいはさらに少ない）データがどのように通信内に存在するかを観察するためにヘッダを抽出（ｐｉｃｋ ｏｕｔ）することができる。下層にあるネットワークインタフェースが、読み取りにおいて指定されたバイトがすべて読み取られるまでブロックすることを要求する場合、クライアントはヘッダを読み取り、どのくらいさらに多く読み取るべきかを決定することができる。例えば、ログイン時において、クライアントは、より小さな「パケット」へ大きなメッセージを分割するために利用されるサイズを識別することができる、要求される「パケット」サイズを指定することができる。さらに、表全体を通過するための、クライアントとサーバとの間を通過するメッセージは、典型的には、「トークンストリーム」または「トークンレスストリーム」のいずれかである２つの型のうちの１つを含むことができる。トークンストリームは、１つ以上の「トークン」から成り、その各々にいくつかのトークン固有データが伴う。「トークン」は、トークンに続くデータを記述するために利用される単一のバイト識別子（例えば、トークンデータ型、トークンデータ長などを含む）を表現する。その中のデータのより詳細な記述を要求することができるメッセージがトークンストリームとして送信される一方、トークンレスストリームは、典型的には、シンプルなメッセージに対して用いられる。

バッファヘッダは、列がヌルであるか否かを示すために、各列のビットを含むヘッダ部分に関連づけることができる。当該ヘッダ部分は、サーバから最初に送信することができ、データの行が続く、伝送される列の数を示すことができる。そのため、前もって、送信される行を最初に検査することにより、ヌルのビットマップを伝送しないことでスペースを節約することができる。関連するビットマップは、行について計算される。

１つの特定の例において、従来のシステムは、次のように１６の整数のヌルを許可する値（交互の非ヌルおよびヌル）の行を送信することができる。
Ｄｌ ０４ ００ ００ ００ ０１ ００ ０４ ００ ００ ００ ０１ ００ ０４ ００ ００ ００ ０１ ００ ０４ ００ ００ ００ ０１ ００ ０４ ００ ００ ００ ０１ ００ ０４ ００ ００ ００ ０１ ００ ０４ ００ ００ ００ ０１ ００ ０４ ００ ００ ００ ０１ ００
ここで、００値は、整数値に対するヌルトークンを示すことができ、「０４ ００ ００ ００ ０１」は、１の単一の整数値を示す（０４は長さインジケータであり、「００ ００ ００ ０１」は値である）。

本発明の実施によって、ヌル行圧縮により、当該行は次のように送信することができる。
Ｄ２ ＡＡ ＡＡ ０４ ００ ００ ００ ０１ ０４ ００ ００ ００ ０１ ０４ ００ ００ ００ ０１ ０４ ００ ００ ００ ０１ ０４ ００ ００ ００ ０１ ０４ ００ ００ ００ ０１ ０４ ００ ００ ００ ０１ ０４ ００ ００ ００ ０１ ［００４１］
ここで、「ＡＡ ＡＡ」は、ビットマップの型においてビット−＞１０１０１０１０ １０１０１０１０を表わす。１６のヌル整数トークンを有する行は、「Ｄ２ ＦＦ ＦＦ」のように送信することができることに注意されたい。

図７は、本発明の一態様による、行毎にヌル列のビットマップを、いつ、どこで、どのように計算するかの推測および／または判定を容易にするために利用することができる人工知能（ＡＩ）コンポーネント７３０を図示している。本明細書で用いられるように、用語「推測（ｉｎｆｅｒｅｎｃｅ）」は、イベントおよび／またはデータを介して取り込まれるような１連の観察からシステム、環境および／またはユーザについて状態を推論する、または推測するプロセスを一般に表す。推測は、特定の文脈または動作を識別するために利用することができ、もしくは、例えば、状態に関する確率分布を生成することができる。推測は、確率論的な、すなわち、データとイベントの考察に基づいた対象の状態に関する確率分布の計算が可能である。推測は、１連のイベントおよび／またはデータからより高いレベルのイベントを構成するために利用される技術を引用することもできる。当該推測は、観察された１連のイベントおよび／または保存された１連のイベントデータから、イベントが時間的に近接して相互に関連するか否か、及び、イベントとデータが１つまたはいくつかのイベントおよびデータソースから生ずるか否かという、新規のイベントまたは動作の構造をもたらす。

ＡＩコンポーネント７３０は、本明細書で説明する発明の様々な態様を容易にすることに関連して、上述したような様々な適切なＡＩベースの機構のいずれかを利用することができる。例えば、効率的にデータを送信することについて、ヌルビット圧縮トークンがどのようにして作成されるべきかを明示的にまたは暗黙に学習するプロセスは、自動分類システムおよびプロセスを介して容易にできる。分類は、ユーザが自動的に実行されることを望む動作を予知または推測するための確率論および／または統計に基づいた解析（例えば、解析ユーティリティおよびコストを計算に入れて）を利用することができる。例えば、ＳＶＭ（Ｓｕｐｐｏｒｔ Ｖｅｃｔｏｒ Ｍａｃｈｉｎｅ：サポートベクターマシン）分類器を利用することができる。ベイジアン・ネットワーク、デシジョンツリー、および異なるパターンの独立性を与える確率論の分類モデルを含む、他の分類アプローチを利用することができる。本明細書で用いられる分類は、プライオリティのモデルを展開するために利用される統計的回帰（ｓｔａｔｉｓｔｉｃａｌ ｒｅｇｒｅｓｓｉｏｎ）も包括する。

本明細書から容易に理解されるように、本発明は、分類器が１つの質問に返すために答える所定の基準に従って自動的に判定するために使用されるように、暗黙に訓練される（例えば、ユーザ動作を観察することを介して、外部の情報を得る）と同様に、明示的に訓練される（例えば、一般的な訓練データを介して）分類器を利用することができる。例えば、十分に理解されるＳＶＭに関して、ＳＶＭは、分類器コンストラクタおよび特徴選択モジュール内の学習または訓練のフェーズを介して構成される。分類器は、入力がクラス、すなわち、ｆ（ｘ）＝ｃｏｎｆｄｅｎｃｅ（ｃｌａｓｓ）に属するという信頼度（ｃｏｎｆｉｄｅｎｃｅ）に対して、入力属性ベクトル、ｘ＝（ｘ１，ｘ２，ｘ３，ｘ４，ｘｎ）をマップする関数である。

図８は、サーバ８５０からクライアント８２０に照会結果を伝送する間にビット数を削減するために、ヌル列を指定することを可能にする拡張ＴＤＳプロトコル８３３を実施するシステムを図示している。クライアント８２０上で稼働するものは、クライアントプロセス、例えば、ウェブブラウザ８１０である。同様に、サーバ８５０上で稼働するものは、対応するサーバプロセス、例えば、ウェブサーバ８６０である。さらに、ウェブブラウザ８１０内に組み込まれるものは、スクリプトまたはアプリケーション８３０が可能であり、クライアントコンピュータ８２０のランタイム環境８４０内で稼働し、本発明の様々な態様に従って、フォーマットされたデータパッケットをパッケージおよびアンパッケージするプロキシ８１５が存在可能である。サーバ８５０と通信するものは、データベース（図示せず）へのアクセスを管理するデータベース管理システム（ＤＢＭＳ）８８０である。ＤＢＭＳ８８０およびデータベース（図示せず）は、サーバ自体の中に配置することができ、またはリモートデータベースサーバ（図示せず）に遠隔で配置することができる。ウェブサーバ８６０上で稼働するものは、ＤＢＭＳ８８０へのアクセスを提供するデータベースインタフェースＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎｓ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）８７０である。クライアントコンピュータ８２０およびサーバコンピュータ８５０は、ネットワーク８９０を介して互いに通信することができる。クライアントプロセス、例えば、ウェブブラウザ８１０がデータベースにデータを要求する場合、スクリプトまたはアプリケーション８３０は、サーバコンピュータ８５０へネットワーク（例えば、インターネット）８９０を介して送信される照会（それはサーバプロセス、例えば、ウェブサーバ８６０によって解釈される）を発行する。上述したように、サーバ８５０へのクライアントの要求は、複数のコマンドを含むことができ、サーバ８５０からの応答は、複数の結果セットを返すことができる。当該通信において、セッション、プレゼンテーションおよびアプリケーションサービス要素は、ＴＤＳによって提供される。ＴＤＳは、典型的には特定のトランスポートプロバイダを必要としないため、複数のトランスポートプロトコルおよびネットワーク８９０を介して実施することができる。

当該拡張ＴＤＳプロトコル８３３は、サーバからクライアントに照会結果を伝送する間にビット数を削減するために、ヌル列を指定する識別コンポーネントを利用することができる。識別コンポーネントは、送信される列を受信側（例えば、クライアント）に示すために、行の先頭の位置に置くことができるビットマップを利用する。従って、ヌルでない列とヌルである列の区別し、続いて、ヌルでない列の送信をすることにより、伝送資源を効果的に利用することができる。

返されるクライアントコマンドに対する応答は、自己記述的でレコード指向（ｏｒｉｅｎｔｅｄ）でありえる（例えば、データストリームは、返される行の名称、型およびオプションを記述することができる）。クライアント側８２０において、データは、ログインレコード、すなわち、サーバ側８５０が受け取ることができる言語である構造化照会言語（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ：ＳＱＬ）コマンド、その関連するバイナリデータ（例えば、一括コピーコマンドのためのデータ）が後続するＳＱＬコマンド、または注意信号である。接続が望まれる場合、クライアント８２０は、サーバにログインデータストリームを送信することができる。たとえクライアント８２０がサーバ８５０に対して２つ以上の接続をすることができたとしも、各接続パスは、別々に同一の方式において確立することができる。

サーバ８５０がクライアント８２０からログインレコードを受信すると、接続要求を受理するか、または拒否するかのいずれかがクライアントに通知される。同様に、ＳＱＬコマンドまたはＳＱＬコマンドのバッチを送信するために、ＳＱＬコマンド（例えば、ユニコードフォーマットによって表現される）を、バッファのデータセクションにコピーし、ＳＱＬサーバ側８２０に対して送信することができる。ＳＱＬバッチは、２つ以上バッファにまたがってもよい。さらに、様々なＯＤＢＣ（Ｏｐｅｎ Ｄａｔａ Ｂａｓｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ：オープン・データベース・コネクティビティ）ルーチンは、クライアントメッセージバッファにＳＱＬコマンドを配置することができ、もしくはサーバにメッセージバッファを送信することができる。

さらに、バイナリデータを有するＳＱＬコマンドのために、一括挿入（ｉｎｓｅｒｔ ｂｕｌｋ）オペレーションは、バイナリデータが後続するＳＱＬコマンド（例えば、ユニコードフォーマットにおける）の場合を表現することができる。最初に、一括挿入コマンドは、通常の方法でサーバ８５０に送信することができ、肯定応答をサーバ８５０から受信すると、クライアント８２０は、フォーマットされたバイナリデータをサーバ８５０に送信することができる。このような機能は、本発明の１つの例示的な態様に従って、ＯＤＢＣに含まれたルーチンによって提供することができる。さらに、クライアント８２０は、サーバ８５０に対して、最初に一括挿入ＳＱＬステートメントを送信することができる。当該一括挿入ＳＱＬステートメントには、未加工のデータを記述するＣＯＬＭＥＴＡＤＡＴＡトークンが続き、さらにバイナリデータの複数の行が続く。例えば、データは、ストレージエンジン行フォーマットではフォーマットされず、ＣＯＬＭＥＴＡＤＡＴＡトークンによって記述されたフォーマットでフォーマットされる。ストリームは、データがサーバ８５０へ送信されるというよりは、むしろサーバ８５０から選ばれていた場合と同じである。

「例示的である（ｅｘｅｍｐｌａｒｙ）」という用語は、具体例、事例または例証として取り扱うことを意味するために、本明細書で用いられる。「例示的である」と本明細書に記述されたいかなる態様または設計は、他の態様または設計に対して好適または有利であるように、必ずしも解釈することができない。同様に、具体例は、もっぱら明瞭さと理解の目的のために本明細書で提供され、任意の方式において本発明またはその部分を限定することが目的ではない。無数の付加的または代替の具体例を提示することができたかもしれないが、簡潔さの目的のために省略されたことは十分に理解されよう。

本出願において用いられるように、用語「コンポーネント」、「システム」、「エンジン」は、コンピュータ関連エンティティ（ハードウェア、ハードウェアとソフトウェアの組み合わせ、ソフトウェア、または実行中のソフトウェアのいずれか）を表すように意図している。例えば、コンポーネントは、プロセッサ上で稼働するプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータでありえるが、限定的ではない。例として、サーバ上で稼働するアプリケーションとサーバはいずれも、コンポーネントでありえる。１つ以上のコンポーネントは、プロセスおよび／または実行スレッド内に存在することができ、コンポーネントは、１台のコンピュータに配置することができ、および／または、２台以上のコンピュータ間で分散することができる。

さらに、本発明のすべてまたは一部は、開示された発明を実施するコンピュータを制御するソフトウェア、ファームウェア、ハードウェアまたはその任意の組み合わせを形成するために標準規格プログラミングおよび／またはエンジニアリング技術を用いて、システム、方法、装置、または製品として実施することができる。例えば、コンピュータ可読媒体は、磁気ストレージデバイス（例えば、ハードディスク、フロッピー（登録商標）ディスク、磁気ストリップ…）、光ディスク（例えば、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｋ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ…）、スマートカード、およびフラッシュメモリデバイス（例えば、カード、スティック、キードライブ…）を含むことができるが、限定的ではない。さらに、電子メールを送受信するために、またはインターネットもしくはローカルエリアネットワーク（ＬＡＮ）などのような、ネットワークにアクセスするために用いられるようなコンピュータ可読電子データを伝えるために、搬送波を利用することができることは、十分に理解されよう。もちろん、当業者は、本発明の内容の範囲または趣旨から逸脱せずに、多くの変更をこの構成に対してできることは認識するであろう。

開示された発明の主題の様々な態様のための文脈を呈するために、以下の説明並びに図９および図１０は、開示された発明の主題の様々な態様が実施できる好適な環境の簡潔な概要を提供する。本発明の主題が、１台のコンピュータおよび／または複数のコンピュータ上で稼働するコンピュータプログラムのコンピュータ実行可能命令の一般的な文脈において上述されているが、当業者は、本発明が他のプログラムモジュールと組み合わせて実施されてもよいことを認識するだろう。一般に、プログラムモジュールは、特定のタスクを実行し、および／または特定の抽象データ型を実施するルーチン、プログラム、コンポーネント、データ構造などを含む。さらに、当業者は、パーソナルコンピュータ、携帯型のコンピューティングデバイス（例えば、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、電話、腕時計…）、マイクロプロセッサベースもしくはプログラム可能な民生用または産業用電子機器だけでなく、シングルプロセッサまたはマルチプロセッサコンピュータシステム、ミニコンピューティングデバイス、メインフレームコンピュータなどを含む他のコンピュータシステム構成によって、本発明の方法を実践することができることを十分に理解するだろう。図示する態様も、通信ネットワークを介してリンクされるリモート処理デバイスによってタスクが実行される分散コンピューティング環境内で実践されてもよい。しかしながら、本発明の全部ではないがいくつかの態様は、スタンドアロンのコンピュータ上で実践することができる。分散コンピューティング環境において、プログラムモジュールは、ローカルとリモートのメモリストレージデバイスの両方に配置してもよい。

図９に関連して、コンピュータ９１２を含む本発明の様々な態様を実行する例示的な環境９１０を記述する。コンピュータ９１２は、処理装置９１４、システムメモリ９１６、およびシステムバス９１８を含む。システムバス９１８は、処理装置９１４に、限定はしないがシステムメモリ９１６を含むシステムコンポーネントを結合する。処理装置９１４は、様々な利用可能なプロセッサのいずれかでよい。デュアルマイクロプロセッサおよび他の多重プロセッサアーキテクチャも、処理装置９１４として利用することができる。

システムバス９１８は、いくつかのタイプのバス構造のいずれかとすることができる。そのバス構造は、限定はしないが、１１ビットのバス、ＩＳＡ（Ｉｎｄｕｓｔｒｉａｌ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＭＳＡ（Ｍｉｃｒｏ−Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＥＩＳＡ（Ｅｘｔｅｎｄｅｄ ＩＳＡ）、ＩＤＥ（Ｉｎｔｅｌｌｉｇｅｎｔ Ｄｒｉｖｅ Ｅｌｅｃｔｒｏｎｉｃｓ）、ＶＬＢ（ＶＥＳＡ Ｌｏｃａｌ Ｂｕｓ）、 ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）、ＡＧＰ（Ａｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）、ＰＣＭＣＩＡ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ Ｍｅｍｏｒｙ Ｃａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ａｓｓｏｃｉａｔｉｏｎ ｂｕｓ）、およびＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅ）を含む利用可能なバス構成の任意の種類を用いたメモリバスまたはメモリコントローラ、周辺バスまたは外部バス、および／またはローカルバスを含む。

システムメモリ９１６は、揮発性メモリ９２０および不揮発性メモリ９２２を含む。起動中などにコンピュータ９１２内のエレメント間で情報を転送するための基本ルーチンを含む基本入出力システム（ＢＩＯＳ）は、不揮発性メモリ９２２内に格納される。限定ではなく例として、不揮発性メモリ９２２は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、ＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ＲＯＭ）、またはフラッシュメモリを含むことができる。揮発性メモリ９２０は、外部キャッシュメモリとして作用するＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を含む。限定ではなく例として、ＲＡＭは、ＳＲＡＭ（Ｓｙｎｃｈｒｏｎｏｕｓ ＲＡＭ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ ＲＡＭ）、ＳＤＲＡＭ（Ｓｙｎｃｈｒｏｎｏｕｓ ＤＲＡＭ）、ＤＤＲ ＳＤＲＡＭ（Ｄｏｕｂｌｅ Ｄａｔａ Ｒａｔｅ ＳＤＲＡＭ）、ＥＳＤＲＡＭ（Ｅｎｈａｎｃｅｄ ＳＤＲＡＭ）、ＳＬＤＲＡＭ（Ｓｙｎｃｈｌｉｎｋ ＤＲＡＭ）、およびＤＲＲＡＭ（Ｄｉｒｅｃｔ Ｒａｍｂｕｓ ＲＡＭ）などのような多くの形態において利用可能である。

コンピュータ９１２は、リムーバブル／非リムーバブル、揮発性／不揮発性のコンピュータストレージ媒体も含む。図９は、ディスクストレージ９２４を図示しており、当該ディスクストレージ９２４は、磁気ディスクドライブ、フロッピーディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−６０ドライブ、フラッシュメモリカード、またはメモリースティックのようなデバイスを含むが、限定するものではない。さらに、ディスクストレージ９２４は、別々に、または、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ ＲＯＭ）デバイス、ＣＤ−Ｒ（ＣＤ Ｒｅｃｏｒｄａｂｌｅ）ドライブ、ＣＤ−ＲＷ（ＣＤ Ｒｅｗｒｉｔａｂｌｅ）ドライブ、またはＤＶＤ−ＲＯＭ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ ＲＯＭ）ドライブなどの光ディスクドライブを含む他のストレージ媒体と組み合わせて、ストレージ媒体を含むことができるが、これらに限定されない。システムバス９１８へのディスクストレージデバイス９２４の接続を容易にするために、リムーバブルまたは非リムーバブルなインタフェースは、典型的にはインタフェース９２６などが用いられる。

図９が、ユーザと、好適な操作環境９１０内に記述される基本的なコンピュータ資源との間の媒介として作用するソフトウェアを記述していることは、十分に理解されるだろう。当該ソフトウェアは、オペレーティングシステム９２８を含む。ディスクストレージ９２４上に格納することができるオペレーティングシステム９２８は、コンピュータシステム９１２のリソースを制御し、割り当てるように動作する。システムアプリケーション９３０は、システムメモリ９１６内またはディスクストレージ９２４上のいずれかに格納されたプログラムモジュール９３２およびプログラムデータ９３４を介して、オペレーティングシステム９２８によりリソースの管理を活用する。様々なオペレーティングシステムまたはオペレーティングシステムの組み合わせで、本明細書に記述された様々なコンポーネントを実施することができることは、十分に理解されよう。

ユーザは、入力デバイス９３６を介してコンピュータ９１２へコマンドまたは情報を入力する。入力デバイス９３６は、マウスなどのポインティングデバイス、トラックボール、スタイラス、タッチパッド、キーボード、マイクロホン、ジョイスティック、ゲームパッド、衛星放送アンテナ、スキャナ、テレビジョンチューナカード、ディジタルカメラ、デジタルビデオカメラ、ウェブカメラなどを含むが、これらには限定されない。これらおよび他の入力デバイスは、インタフェースポート９３８を介してシステムバス９１８を通じて処理装置９１４に接続する。インタフェースポート９３８は、例えば、シリアルポート、パラレルポート、ゲームポート、およびＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）を含む。出力デバイス９４０は、入力デバイス９３６と同一タイプのポートのいくつかを用いる。したがって、例えば、ＵＳＢポートは、コンピュータ９１２に入力を提供し、コンピュータ９１２から出力デバイス９４０へ情報を出力するために用いられてもよい。出力アダプタ９４２は、専用のアダプタを要求する他の出力デバイス９４０のうちの、モニタ、スピーカ、およびプリンタと同様ないくつかの出力デバイス９４０があることを示すために提供されている。出力アダプタ９４２は、限定ではなく例として、出力デバイス９４０とシステムバス９１８との間の接続手段を提供するビデオカードおよびサウンドカードを含む。他のデバイスおよび／またはデバイスのシステムが、リモートコンピュータ９４４などの入出力機能の双方を提供することには注目されたい。

コンピュータ９１２は、リモートコンピュータ９４４ような、１つ以上のリモートコンピュータへの論理的接続を用いて、ネットワーク化された環境内で作動することができる。リモートコンピュータ９４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの機器、ピアデバイスまたは他の共通ネットワークノードおよびその他同種のものとすることができ、典型的にはコンピュータ９１２に関連して記述した多くのまたはすべての構成要素を含む。簡潔さの目的のために、メモリストレージデバイス９４６のみがリモートコンピュータ９４４で図示されている。リモートコンピュータ９４４は、ネットワークインタフェース９４８を介してコンピュータ９１２に論理的に接続され、通信接続９５０を介して物理的に接続される。ネットワークインタフェース９４８は、ＬＡＮ（Ｌｏｃａｌ−Ａｒｅａ Ｎｅｔｗｏｒｋ）およびＷＡＮ（Ｗｉｄｅ−Ａｒｅａ Ｎｅｔｗｏｒｋ）などの通信ネットワークを包含する。ＬＡＮ技術は、ＦＤＤＩ（Ｆｉｂｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ：ファイバ分配データインタフェース）、ＣＤＤＩ（Ｃｏｐｐｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ：銅分散データインタフェース）、イーサネット／ＩＥＥＥ ８０２．３、トークンリング／ＩＥＥＥ ８０２．５などを含む。ＷＡＮ技術は、２地点間接続リンク、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）およびその変形物のような回線交換ネットワーク、パケット交換ネットワーク、およびＤＳＬ（Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）を含むが、限定するものではない。

通信接続９５０は、バス９１８にネットワークインタフェース９４８を接続するために利用されるハードウェア／ソフトウェアを表す。通信接続９５０は、コンピュータ９１２の内部に例示の明瞭さのために示されているが、コンピュータ９１２外部でも可能である。ネットワークインタフェース９４８への接続に対して必要なハードウェア／ソフトウェアは、例示的な目的で、通常の電話回線モデム、ケーブルモデムおよびＤＳＬモデム、ＩＳＤＮアダプタ、およびイーサネットカードを含むモデムなどの、内部技術、外部技術を含む。

図１０は、本発明の拡張型ＴＤＳの実施のために利用できるサンプルコンピューティング環境１０００の概略ブロック図である。システム１０００は、１つ以上のクライアント１０１０を含む。クライアント１０１０は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）とすることができる。システム１０００は、さらに１つ以上のサーバ１０３０を含む。サーバ１０３０も、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）とすることができる。例えば、サーバ１０３０は、本明細書に記述されるコンポーネントの利用により変換を実行するためにスレッドを収容することができる。クライアント１０１０とサーバ１０３０との間の可能な１つの通信は、２つ以上のコンピュータプロセス間で伝送されるのに適応したデータパケットの形態をしていてもよい。システム１０００は、クライアント１０１０とサーバ１０３０との間の通信を容易にするために利用できる通信フレームワーク１０５０を含む。クライアント１０１０は、クライアント１０１０に対してローカルな情報を格納するために利用することができる１つ以上のクライアントデータ記憶装置１０６０に動作可能に接続される。同様に、サーバ１０３０は、サーバ１０３０に対してローカルな情報を格納するために利用することができる１つ以上のサーバデータ記憶装置１０４０に動作可能に接続される。

以上に記述されたものは、様々な例示的な態様を含む。これらの態様を記述するためにコンポーネントまたは方法の考えられるすべての組み合わせを記述することは不可能であり、当業者は、さらに多くの組み合わせや置換が可能であるということを認識されるであろう。従って、本明細書に記述された態様は、添付の特許請求の範囲に係る発明の趣旨および範囲内にある、変更、修正および変形物をすべて包含することを意図している。

さらに、用語「含む（ｉｎｃｌｕｄｅｓ）」が「発明を実施するための形態」または「請求項」のいずれかにおいて用いられる範囲について、当該用語は、請求項において移行語（ｔｒａｎｓｉｔｉｏｎａｌ ｗｏｒｄ）として利用される場合に「備える（ｃｏｍｐｒｉｓｉｎｇ）」が解釈されるように、用語「備える（ｃｏｍｐｒｉｓｉｎｇ）」と同様の形で包括的であることを意図する。

Claims (20)

1. コンピュータによって実施されるシステムであって、
   クライアント（１３０、２２１、８２０）とサーバ（１４０、２２３、８５０）との間の要求応答を転送する表形式データストリーム（ＴＤＳ）プロトコル（１２０、２２２、８３３）と、
   前記ＴＤＳ（１２０、２２２、８３３）の一部としての識別コンポーネント（１３５、２２０、３２０、６１０）であって、行（２０４、２０６、２０８）に関連するヌル列を指定して、前記サーバ（１４０、２２３、８５０）から前記クライアント（１３０、２２１、８２０）への照会結果の伝送の間にビット数を削減する前記識別コンポーネント（１３５、２２０、３２０、６１０）と
   を含むコンピュータ実行可能コンポーネントを備えることを特徴とするシステム。
2. 前記ＴＤＳプロトコルは、列のためのビットを含み、前記列がヌルであるか否かを示すヘッダ部分をさらに備えることを特徴とする請求項１に記載のシステム。
3. 前記ＴＤＳプロトコルは、表形式に形成されたデータの転送のためのパケットとしてモデル化されたバッファをさらに備えることを特徴とする請求項２に記載のシステム。
4. 前記ヘッダ部分は、前記サーバから送信される列の数を示すことを特徴とする請求項２に記載のシステム。
5. 前記行は、所定の閾値を超える断続的なヌル値を許可するカラムを有することを特徴とする請求項４に記載のシステム。
6. リレーショナルデータベースに関連したデータベース管理システムをさらに備えることを特徴とする請求項４に記載のシステム。
7. 前記クライアントは、ウェブブラウザをさらに備えることを特徴とする請求項４に記載のシステム。
8. 前記ビットは、行毎に計算可能であることを特徴とする請求項２に記載のシステム。
9. オープン・データベース・コネクティビティ（ＯＤＢＣ）ルーチンをさらに備え、前記クライアントのメッセージバッファにＳＱＬコマンドを配置することを特徴とする請求項７に記載のシステム。
10. 前記ＳＱＬコマンドは、ユニコードフォーマットであることを特徴とする請求項７に記載のシステム。
11. ＴＤＳプロトコル（１２０、２２２、８３３）を介してクライアント（１３０、２２１、８２０）からサーバ（１４０、２２３、８５０）にデータを転送するステップと、
    照会結果に関連する行（２０４、２０６、２０８）に対してヌル列を指定するためにビットマップを計算するステップと
    を含むコンピュータ実行可能な動作を含むことを特徴とするコンピュータ実施方法。
12. 行毎に、転送されるデータを検査するステップをさらに含むことを特徴とする請求項１１に記載の方法。
13. 行の先頭に前記ビットマップを配置するステップをさらに含むことを特徴とする請求項１２に記載の方法。
14. ヘッダ部分により行または列またはデータ型またはそれらの組み合わせを定義するステップをさらに含むことを特徴とする請求項１１に記載の方法。
15. 単一のバイト識別子の形態においてトークンを利用するステップをさらに含むことを特徴とする請求項１１に記載の方法。
16. 列を順序づけて記述するステップをさらに含むことを特徴とする請求項１５に記載の方法。
17. 他の列とヌルである列を区別するステップをさらに含むことを特徴とする請求項１６に記載の方法。
18. 分類器を介してヌル列を推測するステップをさらに含むことを特徴とする請求項１１に記載の方法。
19. ヌル列を伝送しないことにより伝送の間にスペースを節約するステップをさらに含むことを特徴とする請求項１１に記載の方法。
20. コンピュータによって実施されるシステムであって、
    クライアント（１３０、２２１、８２０）とサーバ（１４０、２２３、８５０）との間でデータを交換する手段（１２０、２２２、８３３）と、
    交換されたデータ内のヌル列を識別する手段（１３５、２２０、３２０、６１０）と
    を備えることを特徴とするシステム。

Images