特許 6091545 メッセージ・ストリーム・インテグリティ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6091545

(24)【登録日】2017年2月17日

(45)【発行日】2017年3月8日

(54)【発明の名称】メッセージ・ストリーム・インテグリティ

(51)【国際特許分類】

   G06F 13/00 20060101AFI20170227BHJP

   H04L 29/06 20060101ALI20170227BHJP

【ＦＩ】

   G06F13/00 353A

   H04L13/00 305C

【請求項の数】31

【外国語出願】

【全頁数】44

(21)【出願番号】特願2015-104809(P2015-104809)

(22)【出願日】2015年5月22日

(62)【分割の表示】特願2014-528605(P2014-528605)の分割

【原出願日】2012年8月30日

(65)【公開番号】特開2015-172963(P2015-172963A)

(43)【公開日】2015年10月1日

【審査請求日】2015年5月22日

(31)【優先権主張番号】13/225,047

(32)【優先日】2011年9月2日

(33)【優先権主張国】US

【前置審査】

(73)【特許権者】

【識別番号】502317459

【氏名又は名称】トレーディング テクノロジーズ インターナショナル インコーポレイテッド

(74)【代理人】

【識別番号】100101454

【弁理士】

【氏名又は名称】山田 卓二

(74)【代理人】

【識別番号】100081422

【弁理士】

【氏名又は名称】田中 光雄

(74)【代理人】

【識別番号】100132241

【弁理士】

【氏名又は名称】岡部 博史

(72)【発明者】

【氏名】エリカ・ジョアン・グラント・ブラッドニック

(72)【発明者】

【氏名】レスリー・マイケル・ブロディ

(72)【発明者】

【氏名】スコット・エフ・シンガー

【審査官】 速水 雄太

(56)【参考文献】

【文献】 米国特許第０７１０７２４０（ＵＳ，Ｂ１）

【文献】 特開平０６−２５２８９７（ＪＰ，Ａ）

【文献】 特開２００５−１０９８４９（ＪＰ，Ａ）

【文献】 特開平０８−０３２５３１（ＪＰ，Ａ）

【文献】 特表２００６−５０６９１５（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００６／００５６４０３（ＵＳ，Ａ１）

【文献】 米国特許第０６３８９０１６（ＵＳ，Ｂ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

Ｈ０４Ｌ ２９／０６

(57)【特許請求の範囲】

【請求項1】

コンピュータが、メッセージ・ストリームを通じて送信するべき新しいメッセージを検出するステップ、ここでメッセージ・ストリームとは、関連するメッセージの論理通信チャンネルである、
コンピュータが、新しいメッセージのフェーズ番号を決定するステップ、ここでフェーズ番号は、あるメッセージ・シーケンスに対して同じ値に保持される一方、前記新しいメッセージの前に送信されたメッセージがストップ・メッセージである場合、メッセージ・ストリームを遮断することなく、別の値にセットされる、
コンピュータが、新しいメッセージのシーケンス番号を決定するステップ、ここでシーケンス番号は、前記新しいメッセージの前に送信されたメッセージがストップ・メッセージである場合、リセットされる、
コンピュータが、フェーズ番号とシーケンス番号とを有する新しいメッセージを、メッセージ・ストリームを通じて送信するステップ、
を含む方法。

【請求項2】

送信するべき新しいメッセージを検出するステップは、タイマーの時間切れに基づいて行われる、ここでタイマーは、最後のメッセージが送信された後の第１の時間間隔である、請求項１に記載の方法。

【請求項3】

最後のメッセージは、データ・メッセージである、請求項２に記載の方法。

【請求項4】

最後のメッセージは、ハートビート・メッセージである、請求項２に記載の方法。

【請求項5】

第１の時間間隔は、前回の時間間隔から一定時間増加させた時間間隔である、ここで前回の時間間隔は、最後から２つめのメッセージが送信されたときと最後のメッセージが送信されたときとの間の時間間隔である、請求項４に記載の方法。

【請求項6】

第１の時間間隔は、前回の時間間隔の倍数、前回の時間間隔の指数、素数シーケンス、及びフィボナッチ・シーケンスのうちの１つに基づいて、前回の時間間隔から増加させた時間間隔である、請求項５に記載の方法。

【請求項7】

送信するべき新しいメッセージを検出するステップは、アプリケーションから受信するデータに基づく、請求項１に記載の方法。

【請求項8】

新しいメッセージは、データ・メッセージである、請求項１または７に記載の方法。

【請求項9】

データ・メッセージは、取引可能オブジェクトの注文に関連するデータを含む、請求項８に記載の方法。

【請求項10】

新しいメッセージは、ハートビート・メッセージである、請求項１〜６のいずれか一項に記載の方法。

【請求項11】

ハートビート・メッセージのシーケンス番号は、送信された最後のデータ・メッセージのシーケンス番号と同じである、請求項１０に記載の方法。

【請求項12】

新しいメッセージは、ストップ・メッセージもあることを示すフラグを含む、請求項１〜１１のいずれか一項に記載の方法。

【請求項13】

新しいメッセージは、ストップ・メッセージである、請求項１〜１１のいずれか一項に記載の方法。

【請求項14】

更に、コンピュータが、メッセージ・ストリーム・ステートをクリアするステップを含む、ここでメッセージ・ストリーム・ステートは、ストップ・メッセージが送信された後にクリアされ、又、メッセージ・ストリーム・ステートは、メッセージ・ストリームを特定する情報を含むものであり、関連するメッセージの論理通信チャンネルである、請求項１２または１３に記載の方法。

【請求項15】

メッセージ・ストリームを特定する情報は、フェーズ番号を含む、請求項１４に記載の方法。

【請求項16】

メッセージ・ストリーム・ステートをクリアするステップは、コンピュータのメモリからメッセージ・ストリーム・ステートを割り当て解除することを含む、請求項１４または１５に記載の方法。

【請求項17】

コンピュータに請求項１〜１６のいずれか一項に記載の方法を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。

【請求項18】

コンピュータに請求項１〜１６のいずれか一項に記載の方法を実行させるためのプログラム。

【請求項19】

メッセージ・ストリームを通じて送信するべき新しいメッセージを検出する新しいメッセージ検出器、ここでメッセージ・ストリームとは、関連するメッセージの論理通信チャンネルである、
新しいメッセージのフェーズ番号を決定するフェーズ番号生成器、ここでフェーズ番号は、あるメッセージ・シーケンスに対して同じ値で保持される一方、前記新しいメッセージの前に送信されたメッセージがストップ・メッセージである場合、メッセージ・ストリームを遮断することなく、別の値にセットされる、
新しいメッセージのシーケンス番号を決定するシーケンス番号生成器、ここでシーケンス番号は、前記新しいメッセージの前に送信されたメッセージがストップ・メッセージである場合、リセットされる、
フェーズ番号とシーケンス番号とを有する新しいメッセージを、メッセージ・ストリームを通じて送信するメッセージ送信機、
を含む、システム。

【請求項20】

コンピュータが、メッセージ・ストリームを通じて新しいメッセージを受信するステップ、ここでメッセージ・ストリームとは、関連するメッセージの論理通信チャンネルであり、新しいメッセージは、メッセージ・フェーズ番号とメッセージ・シーケンス番号とを含む一方、フェーズ番号は、あるメッセージ・シーケンスに対して同じ値で保持される一方、前記新しいメッセージの前に送信されたメッセージがストップ・メッセージである場合、メッセージ・ストリームを遮断することなく、別の値にセットされており、且つシーケンス番号は、前記新しいメッセージの前に送信されたメッセージがストップ・メッセージである場合、リセットされている、
コンピュータが、新しいメッセージの予想フェーズ番号を決定するステップ、
コンピュータが、新しいメッセージの予想シーケンス番号を決定するステップ、
コンピュータが、メッセージ・フェーズ番号を予想フェーズ番号と比較するステップ、
コンピュータが、メッセージ・シーケンス番号を予想シーケンス番号と比較するステップ、
コンピュータが、（ａ）メッセージ・フェーズ番号と予想フェーズ番号、（ｂ）メッセージ・シーケンス番号と予想シーケンス番号の少なくとも一方がマッチしないとき、ロスト・メッセージを報知するステップ、
を含む、方法。

【請求項21】

予想フェーズ番号は、前回のメッセージがストップ・メッセージではなかったとき、前回のメッセージのメッセージ・フェーズ番号と同じである、請求項２０に記載の方法。

【請求項22】

予想フェーズ番号は、前回のメッセージがストップ・メッセージであったとき、メッセージ・フェーズ番号と同じである、請求項２０に記載の方法。

【請求項23】

予想シーケンス番号は、前回のメッセージのシーケンス番号に基づく、請求項２０〜２２のいずれか一項に記載の方法。

【請求項24】

予想シーケンス番号は、前回のシーケンス番号を増加することによって決定される、請求項２３に記載の方法。

【請求項25】

予想シーケンス番号は、新しいメッセージがハートビート・メッセージであるとき、前回のデータ・メッセージのシーケンス番号と同じである、請求項２０〜２２のいずれか一項に記載の方法。

【請求項26】

予想シーケンス番号は、新しいメッセージがストップ・メッセージであるとき、前回のデータ・メッセージのシーケンス番号と同じである、請求項２０〜２２のいずれか一項に記載の方法。

【請求項27】

更に、新しいメッセージがデータ・メッセージであるとき、コンピュータが、新しいメッセージ内のデータを処理するステップを含む、請求項２０〜２４及び２６のいずれか一項に記載の方法。

【請求項28】

更に、新しいメッセージがストップ・メッセージであるとき、コンピュータが、メッセージ・ストリーム・ステートをクリアするステップを含む、ここでメッセージ・ストリーム・ステートは、メッセージ・ストリームを特定する情報を含むものであり、関連するメッセージの論理通信チャンネルである、請求項２０〜２７のいずれか一項に記載の方法。

【請求項29】

コンピュータに請求項２０〜２８のいずれか一項に記載の方法を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。

【請求項30】

コンピュータに請求項２０〜２８のいずれか一項に記載の方法を実行させるためのプログラム。

【請求項31】

メッセージ・ストリームを通じて新しいメッセージを受信するメッセージ受信機、ここでメッセージ・ストリームとは、関連するメッセージの論理通信チャンネルであり、新しいメッセージは、メッセージ・フェーズ番号とメッセージ・シーケンス番号とを含む一方、フェーズ番号は、あるメッセージ・シーケンスに対して同じ値で保持される一方、前記新しいメッセージの前に送信されたメッセージがストップ・メッセージである場合、メッセージ・ストリームを遮断することなく、別の値にセットされており、且つシーケンス番号は、前記新しいメッセージの前に送信されたメッセージがストップ・メッセージである場合、リセットされている、
新しいメッセージの予想フェーズ番号を決定する予想フェーズ番号生成器、
新しいメッセージの予想シーケンス番号を決定する予想シーケンス番号生成器、
メッセージ・フェーズ番号を予想フェーズ番号と比較するフェーズ番号比較器、
メッセージ・シーケンス番号を予想シーケンス番号と比較するシーケンス番号比較器、
（ａ）メッセージ・フェーズ番号と予想フェーズ番号、（ｂ）メッセージ・シーケンス番号と予想シーケンス番号の少なくとも一方がマッチしないとき、ロスト・メッセージを報知するロスト・メッセージ報知機、
を含む、システム。

【発明の詳細な説明】

【背景技術】

【0001】

ネットワークを介して送信されるメッセージは、一般的に、１つのデバイスから別のデバイスへ送信され、送り先のデバイスで受信したときに取り出される内容を含んでいる。続いて、様々な処理動作がその内容に基づいて行われる。

【0002】

イベントは、メッセージの内容次第であるため、メッセージ・ストリームのインテグリティを保持することが望ましい。特に、ロスト・メッセージを検出及びメッセージ・ストリーム・データの低減の達成が可能であることは、特に有益である。そのようなロスト・メッセージの検出及びメッセージ・ストリーム・データの低減の１つの応用分野は、特に関連するもので電子取引の分野である。

【0003】

特定の実施形態は、以下の図面を参照して開示されている。

【図面の簡単な説明】

【0004】

【図1】図１は、特定の実施形態に係るコンピュータデバイスのブロック図を示す。

【図2A】図２Ａは、一定間隔手法を用いたハートビートを使用するメッセージ例を示す。

【図2B】図２Ｂは、増大間隔手法を用いたハートビートを使用するメッセージ例を示す。

【図2C】図２Ｃは、図２Ａ―２Ｂに係るメッセージの送信方法の例のフロー図を示す。

【図2D】図２Ｄは、図２Ａ―２Ｂに係るメッセージの受信方法の例のフロー図を示す。

【図3A】図３Ａは、増大間隔手法を用いたハートビートを利用するメッセージの例を示す。

【図3B】図３Ｂは、ストップ・メッセージ手法を利用するメッセージの例を示す。

【図3C】図３Ｃは、ストップ・メッセージを使用するメッセージの例を示す。

【図3D】図３Ｄは、ストップ・メッセージを使用するメッセージの例を示す。

【図3E】図３Ｅは、ストップ・メッセージ及びメッセージ・ストリーム・クリアリングを使用するメッセージの例を示す。

【図3F】図３Ｆは、ストップ・メッセージ、メッセージ・ストリーム・クリアリング、及びフェーズ番号を使用するメッセージの例を示す。

【図3G】図３Ｇは、ストップ・メッセージ、メッセージ・ストリーム・クリアリング、及びフェーズ番号を使用するメッセージの例を示す。

【図3H】図３Ｈは、ストップ・メッセージ、メッセージ・ストリーム・クリアリング、及びフェーズ番号を使用するメッセージの例を示す。

【図4】図４は、特定の実施形態に係るフェーズ番号を使用するメッセージの送信方法の例のフロー図を示す。

【図5】図５は、特定の実施形態に係るフェーズ番号を使用するメッセージの受信方法の例のフロー図を示す。

【図6】図６は、特定の実施形態に係る送信デバイスの例のブロック図を示す。

【図7】図７は、特定の実施形態に係る受信デバイスの例のブロック図を示す。

【図8】図８は、特定の実施形態が採用され得る電子取引システムのブロック図を示す。

【図9】図９は、図８の電子取引システムの例のブロック図を示す。

【発明を実施するための形態】

【0005】

特定の実施形態は、例で示され、提供された図面と共に読むとき、より良く理解されるであろう。なお、実施形態は、添付図面に示す構成及び手段に限定されないことを理解するべきである。

【0006】

メッセージ・ストリームは、関連するメッセージの論理通信チャンネルである。ロスト・メッセージ、特にデータを含むそれらのメッセージの検出は、メッセージ・ストリーム・インテグリティを向上させる。メッセージが失われた場合、様々な動作、例えば、ロスト・メッセージの再送信の要求、メッセージ・ストリームの終了又はリセット、ログファイルにエントリの作成、エラーメッセージの提供、割り込みの生成、ロスト・メッセージについての受信データを処理するアプリケーション又は高レベルプロトコルへの警告、プログラムの実行の中止、メッセージが失われたことを１人以上のユーザへの通知、メッセージ・ストリームの終了と新しいメッセージ・ストリームの確立、ライセンスのリリースと再取得、サーバの再認証、及び／又は完全なデータセットの再ダウンロードなどの動作がとられてもよい。

【0007】

また、ステート情報が、メッセージ・ストリーム及びメッセージ・ストリーム・インテグリティを保持するために記憶される必要がある。ステート情報は、送信デバイス、受信デバイス、及び中間デバイスに記憶されてもよい。このステート情報は、メモリなどの限られたリソースを消費してもよい。これにより、メッセージ・ストリームのために記憶する必要があるステート情報を減らすことが望ましい。

【0008】

ロスト・メッセージを検出するため、いくつかの現在のシステムは、各メッセージにおいて所定の量増大するシーケンス番号又はメッセージ識別器を使用し、受信者が、送信されたメッセージの順番と、どのメッセージが失われたかと、の両方を決定してもよい。なお、メッセージの送信頻度が低い場合、ロスト・メッセージが検出される前に許容できない遅延が生じることがある。

【0009】

いくつかの現在のシステムは、ハートビートを利用し、ロスト・メッセージの検出の可能性を高めている。ハートビート・メッセージは、一定の間隔で送信され、妥当な時間内にロスト・メッセージを検出する。しかしながら、多数のハートビート・メッセージの送信は、限られたネットワーク帯域幅の使用を非効率にし、及び／又はネットワーク上の他のデータ・メッセージの配信のための待ち時間を増やすことがある。

【0010】

開示された実施形態は、ロスト・メッセージを検出し、メッセージ・ストリームのために記憶されたステート情報を減らすことによって、メッセージ・ストリーム・インテグリティを向上させる技術に関する。いくつかの実施形態では、増大間隔手法を用いたハートビートが使用され、ハートビート・メッセージによるネットワーク・トラフィックを低減しつつ、ロスト・メッセージの検出の可能性を高めている。いくつかの実施形態では、ストップ・メッセージ手法が実施され、過度の非データ・ネットワーク・トラフィックを低減しつつ、ロスト・メッセージの検出の可能性を高めている。いくつかの実施形態では、メッセージ・ストリーム・ステート・クリアリング手法が実施され、メッセージ・ストリームのために記憶されたステート情報を減らし、メモリの使用量を減らしている。いくつかの実施形態では、フェーズ番号手法が実施され、ロスト・メッセージの検出の可能性を高めている。

【0011】

以下は、他の構成要素のうち、ハードウェア上で実行されるソフトウェアを含む実施形態を開示しているが、実施形態は単なる例示であり、限定とみなされるべきではないことに留意すべきである。例えば、いずれか又はこれらのすべてのハードウェア及びソフトウェアコンポーネントが、ハードウェアのみに、ソフトウェアのみに、ファームウェアのみに、又はハードウェア、ソフトウェア、及び／又はファームウェアのいくつかの組み合わせで実施されてもよいことが想定される。したがって、開示された実施形態は、他の方法で実施されてもよい。

【0012】

Ｉ．簡単な説明
特定の実施形態は、コンピュータデバイスが、第１のデータ・メッセージを送信するステップ、コンピュータデバイスが、第１のストップ・メッセージを送信するステップ、及びコンピュータデバイスが、第２のデータ・メッセージを送信するステップ、を含む方法を提供する。第１のデータ・メッセージは、所定の初期シーケンス番号の値を有する第１のデータ・メッセージ・シーケンス番号を含む。第１のデータ・メッセージは、第１のデータ・メッセージ・フェーズ番号を含む。第１のストップ・メッセージは、ストップ・メッセージ・フェーズ番号を含む。ストップ・メッセージ・フェーズ番号は、第１のデータ・メッセージ・フェーズ番号と同じである。第２のデータ・メッセージは、第１のストップ・メッセージの後に送信される。第２のデータ・メッセージは、所定の初期シーケンス番号の値を有する第２のデータ・メッセージ・シーケンス番号を含む。第２のデータ・メッセージは、第２のデータ・メッセージ・フェーズ番号を含む。第２のデータ・メッセージ・フェーズ番号は、第１のデータ・メッセージ・フェーズ番号と異なる。いくつかの実施形態では、第１のデータ・メッセージ及び第２のデータ・メッセージは、取引可能オブジェクトの注文に関連するデータを含んでもよい。

【0013】

特定の実施形態は、命令を含む有形のコンピュータ読み取り可能な記録媒体であって、命令は、実行されるとき、コンピュータデバイスに少なくとも第１のデータ・メッセージを送信させ、第１のストップ・メッセージを送信させ、及び第２のデータ・メッセージを送信させる、コンピュータ読み取り可能な記録媒体を提供する。第１のデータ・メッセージは、所定の初期シーケンス番号の値を有する第１のデータ・メッセージ・シーケンス番号を含む。第１のデータ・メッセージは、第１のデータ・メッセージ・フェーズ番号を含む。第１のストップ・メッセージは、ストップ・メッセージ・フェーズ番号を含む。ストップ・メッセージ・フェーズ番号は、第１のデータ・メッセージ・フェーズ番号と同じである。第２のデータ・メッセージは、第１のストップ・メッセージの後に送信される。第２のデータ・メッセージは、所定の初期シーケンス番号の値を有する第２のデータ・メッセージ・シーケンス番号を含む。第２のデータ・メッセージは、第２のデータ・メッセージ・フェーズ番号を含む。第２のデータ・メッセージ・フェーズ番号は、第１のデータ・メッセージ・フェーズ番号と異なる。いくつかの実施形態では、第１のデータ・メッセージ及び第２のデータ・メッセージは、取引可能オブジェクトの注文に関連するデータを含んでもよい。

【0014】

特定の実施形態は、第１のデータ・メッセージを送信する第１のデータ・メッセージ送信機、第１のストップ・メッセージを送信する第１のストップ・メッセージ送信機、及び第２のデータ・メッセージを送信する第２のデータ・メッセージ送信機、を含むシステムを提供する。第１のデータ・メッセージは、所定の初期シーケンス番号の値を有する第１のデータ・メッセージ・シーケンス番号を含む。第１のデータ・メッセージは、第１のデータ・メッセージ・フェーズ番号を含む。第１のストップ・メッセージは、ストップ・メッセージ・フェーズ番号を含む。ストップ・メッセージ・フェーズ番号は、第１のデータ・メッセージ・フェーズ番号と同じである、第２のデータ・メッセージは、第１のストップ・メッセージの後に送信される。第２のデータ・メッセージは、所定の初期シーケンス番号の値を有する第２のデータ・メッセージ・シーケンス番号を含む。第２のデータ・メッセージは、第２のデータ・メッセージ・フェーズ番号を含む。第２のデータ・メッセージ・フェーズ番号は、第１のデータ・メッセージ・フェーズ番号と異なる。いくつかの実施形態では、第１のデータ・メッセージ及び第２のデータ・メッセージは、取引可能オブジェクトの注文に関連するデータを含んでもよい。

【0015】

特定の実施形態は、メッセージにフェーズ番号を提供するフェーズ番号生成器、メッセージにシーケンス番号を提供するシーケンス番号生成器、第１のデータ・メッセージを送信する第１のデータ・メッセージ送信機、第１のストップ・メッセージを送信する第１のストップ・メッセージ送信機、及び第２のデータ・メッセージを送信する第２のデータ・メッセージ送信機、を含むシステムを提供する。第１のデータ・メッセージは、フェーズ番号生成器によって提供される所定の初期シーケンス番号を有する第１のデータ・メッセージ・シーケンス番号を含む。第１のデータ・メッセージは、フェーズ番号生成器によって提供される第１のデータ・メッセージ・フェーズ番号を含む。第１のストップ・メッセージは、フェーズ番号生成器によって提供されるストップ・メッセージ・フェーズ番号を含む。ストップ・メッセージ・フェーズ番号は、第１のデータ・メッセージ・フェーズ番号と同じである。第２のデータ・メッセージは、第１のストップ・メッセージの後に送信される。第２のデータ・メッセージは、シーケンス番号生成器によって提供される所定のシーケンス番号の値を有する第２のデータ・メッセージ・シーケンス番号を含む。第２のデータ・メッセージは、フェーズ番号生成器によって提供される第２のデータ・メッセージ・フェーズ番号を含む。第２のデータ・メッセージ・フェーズ番号は、第１のデータ・メッセージ・フェーズ番号と異なる。いくつかの実施形態では、第１のデータ・メッセージ及び第２のデータ・メッセージは、取引可能オブジェクトの注文に関連するデータを含んでもよい。

【0016】

特定の実施形態は、コンピュータデバイスが、送信されるべき新しいメッセージを検出するステップ、コンピュータデバイスが、新しいメッセージのフェーズ番号を決定するステップ、コンピュータデバイスが、新しいメッセージのシーケンス番号を決定するステップ、及びコンピュータデバイスが、フェーズ番号とシーケンス番号とを有する新しいメッセージを送信するステップ、を含む方法を提供する。

【0017】

特定の実施形態は、命令を含む有形のコンピュータ読み取り可能な記録媒体であって、命令は、実行されるとき、コンピュータデバイスに少なくとも送信されるべき新しいメッセージを検出させ、新しいメッセージのフェーズ番号を決定させ、新しいメッセージのシーケンス番号を決定させ、及びフェーズ番号とシーケンス番号とを有する新しいメッセージを送信させる、コンピュータ読み取り可能な記録媒体を提供する。

【0018】

特定の実施形態は、送信されるべき新しいメッセージを検出する新しいメッセージ検出器、新しいメッセージのフェーズ番号を決定するフェーズ番号生成器、新しいメッセージのシーケンス番号を決定するシーケンス番号生成器、及びフェーズ番号とシーケンス番号とを有する新しいメッセージを送信するメッセージ送信機、を含むシステムを提供する。

【0019】

特定の実施形態は、コンピュータデバイスが、メッセージ・フェーズ番号とメッセージ・シーケンス番号とを含む新しいメッセージを受信するステップ、コンピュータデバイスが、新しいメッセージの予想フェーズ番号を決定するステップ、コンピュータデバイスが、新しいメッセージの予想シーケンス番号を決定するステップ、コンピュータデバイスが、メッセージ・フェーズ番号を予想フェーズ番号と比較するステップ、コンピュータデバイスが、メッセージ・シーケンス番号を予想シーケンス番号と比較するステップ、及びコンピュータデバイスが、（ａ）メッセージ・フェーズ番号と予想フェーズ番号、（ｂ）メッセージ・シーケンス番号と予想シーケンス番号の少なくとも一方がマッチしないとき、ロスト・メッセージを報知するステップ、を含む方法を提供する。

【0020】

特定の実施形態は、命令を含む有形のコンピュータ読み取り可能な記録媒体であって、命令は、実行されるとき、コンピュータデバイスに少なくとも、メッセージ・フェーズ番号とメッセージ・シーケンス番号とを含む新しいメッセージを受信させ、新しいメッセージの予想フェーズ番号を決定させ、新しいメッセージの予想シーケンス番号を決定させ、メッセージ・フェーズ番号を予想フェーズ番号と比較させ、メッセージ・シーケンス番号を予想シーケンス番号と比較させ、及び（ａ）メッセージ・フェーズ番号と予想フェーズ番号、（ｂ）メッセージ・シーケンス番号と予想シーケンス番号の少なくとも一方がマッチしないとき、ロスト・メッセージを報知する、コンピュータ読み取り可能な記録媒体を提供する。

【0021】

特定の実施形態は、メッセージ・フェーズ番号とメッセージ・シーケンス番号とを含む新しいメッセージを受信するメッセージ受信機、新しいメッセージの予想フェーズ番号を決定する予想フェーズ番号生成器、新しいメッセージの予想シーケンス番号を決定する予想シーケンス番号生成器、メッセージ・フェーズ番号を予想フェーズ番号と比較するフェーズ番号比較器、メッセージ・シーケンス番号を予想シーケンス番号と比較するシーケンス番号比較器、及び（ａ）メッセージ・フェーズ番号と予想フェーズ番号、（ｂ）メッセージ・シーケンス番号と予想シーケンス番号の少なくとも一方がマッチしないとき、ロスト・メッセージを報知するロスト・メッセージ報知機、を含むシステムを提供する。

【0022】

特定の実施形態は、コンピュータデバイスが、第１のメッセージを送信するステップ、コンピュータデバイスが、第１のハートビート・メッセージを送信するステップ、コンピュータデバイスが、第２のハートビート・メッセージを送信するステップ、を含む方法を提供する。第１のハートビート・メッセージは、第１のデータ・メッセージが送信された後、第１の時間間隔で送信される。第１の時間間隔は、所定の長さである。第２のハートビート・メッセージは、第１のハートビート・メッセージが送信された後、第２の時間間隔で送信される。第２の時間間隔は、第１の時間間隔より増加させる。

【0023】

特定の実施形態は、命令を含む有形のコンピュータ読み取り可能な記録媒体であって、命令は、実行されるとき、コンピュータデバイスに少なくとも第１のメッセージを送信させ、第１のハートビート・メッセージを送信させ、及び第２のハートビート・メッセージを送信させる、コンピュータ読み取り可能な記録媒体を提供する。第１のハートビート・メッセージは、第１のデータ・メッセージが送信された後、第１の時間間隔で送信される。第１の時間間隔は、所定の長さである。第２のハートビート・メッセージは、第１のハートビート・メッセージが送信された後、第２の時間間隔で送信される。第２の時間間隔は、第１の時間間隔より増加させる。

【0024】

特定の実施形態は、第１のデータ・メッセージを送信する第１のデータ・メッセージ送信機、第１のハートビート・メッセージを送信する第１のハートビート・メッセージ送信機、及び第２のハートビート・メッセージを送信する第２のハートビート・メッセージ送信機、を含むシステムを提供する。第１のハートビート・メッセージは、第１のデータ・メッセージが送信された後、第１の時間間隔で送信される。第１の時間間隔は、所定の長さである。第２のハートビート・メッセージは、第１のハートビート・メッセージが送信された後、第２の時間間隔で送信される。第２の時間間隔は、第１の時間間隔より増加させる。

【0025】

特定の実施形態は、コンピュータデバイスが、第１のデータ・メッセージを送信するステップ、及びコンピュータデバイスが、第１のストップ・メッセージを送信するステップ、を含む方法を提供する。

【0026】

特定の実施形態は、命令を含む有形のコンピュータ読み取り可能な記録媒体であって、命令は、実行されるとき、コンピュータデバイスに少なくとも第１のデータ・メッセージを送信させ、及び第１のストップ・メッセージを送信させる、コンピュータ読み取り可能な記録媒体。

【0027】

特定の実施形態は、第１のデータ・メッセージを送信する第１のデータ・メッセージ送信機、及び第１のストップ・メッセージを送信する第１のストップ・メッセージ送信機、を含むシステムを提供する。

【0028】

特定の実施形態は、コンピュータデバイスが、シーケンス番号とフェーズ番号とを含むメッセージを送信するステップを含む方法を提供する。

【0029】

特定の実施形態は、命令を含む有形のコンピュータ読み取り可能な記録媒体であって、命令は、実行されるとき、コンピュータデバイスに少なくともシーケンス番号とフェーズ番号とを含むメッセージを送信させる、コンピュータ読み取り可能な記録媒体を提供する。

【0030】

特定の実施形態は、シーケンス番号とフェーズ番号とを含むメッセージを送信するメッセージ送信機を含むシステムを提供する。

【0031】

特定の実施形態は、コンピュータデバイスが、シーケンス番号とフェーズ番号とを含むメッセージを受信するステップ、及びコンピュータデバイスが、シーケンス番号とフェーズ番号とに基づき、ロスト・メッセージを報知するステップ、を含む方法を提供する。

【0032】

特定の実施形態は、命令を含む有形のコンピュータ読み取り可能な記録媒体であって、命令は、実行されるとき、コンピュータデバイスに少なくともシーケンス番号とフェーズ番号とを含むメッセージを受信させ、及びシーケンス番号とフェーズ番号とに基づき、ロスト・メッセージを報知させる、コンピュータ読み取り可能な記録媒体を提供する。

【0033】

特定の実施形態は、シーケンス番号とフェーズ番号とを含むメッセージを受信するメッセージ受信機、及びシーケンス番号とフェーズ番号に基づき、ロスト・メッセージを報知するロスト・メッセージ報知機、を含むシステムを提供する。

【0034】

ＩＩ．コンピュータデバイスの例
図１は、開示された実施形態を実施するために使用され得るコンピュータデバイス１００の例のブロック図を示す。１つ以上のコンピュータデバイス１００は、例えば、多くの別のデバイスから送受信されるデータを処理するように構成された端末コンピュータ又はサーバ・コンピュータに実装されてもよい。

【0035】

コンピュータデバイス１００は、プロセッサ１０２、相互接続バス１０４、チップセット１０６、メモリコントローラ１０８、入力／出力（Ｉ／Ｏ）コントローラ１１０、システムメモリ１１２、大容量記憶メモリ１１４、Ｉ／Ｏバス１１６、ネットワークインタフェース１１８、ディスプレイ１２０、入力デバイス１２２、及び出力デバイス１２４を含む。コンピュータデバイス１００は、追加の、異なる、又はより少ない構成要素を含んでもよい。例えば、複数のバス、複数のプロセッサ、複数のメモリデバイス、複数のネットワークインタフェース、複数のディスプレイデバイス、複数の入力デバイス、複数の出力デバイス、又はそれらの任意の組み合わせが、提供されてもよい。別の例として、コンピュータデバイス１００は、ディスプレイデバイス１２０と別の出力デバイス１２４を含まなくてもよい。別の例として、コンピュータデバイス１００は、ディスプレイデバイス１２０を含まなくてもよい。別の例として、コンピュータデバイス１００は、入力デバイス１２２を含まなくてもよい。代わりに、例えば、コンピュータデバイス１００は、ネットワークインタフェース１１８を介して外部の又はリモートの入力デバイスによって制御されてもよい。

【0036】

コンピュータデバイス１００は、相互接続バス１０４と接続されるプロセッサ１０２を含む。相互接続バス１０４は、通信バス、チャンネル、ネットワーク、回路、スイッチ、ファブリック、又はコンピュータデバイス１００の構成要素との間でデータを通信するための他の機構を含んでもよい。相互接続バス１０４は、コンピュータデバイス１００のいくつかの構成要素と通信可能に接続され、データを転送してもよい。例えば、アプリケーションのインストールプロセス中に、プロセッサ１０２によって実行されるべき１つ以上のコンピュータ読み取り可能な命令が、入力デバイス１２２及び／又はネットワークインタフェース１１８から、システムメモリ１１２及び／又は大容量記憶メモリ１１４に転送されてもよい。コンピュータデバイス１００がシステムメモリ１１２及び／又は大容量記憶メモリ１１４に記憶されたアプリケーションを実行しているとき、又は実行の準備をしているとき、プロセッサ１０２は、システムメモリ１１２及び／又は大容量記憶メモリ１１４から、相互接続バス１０４を介して命令を取り出してもよい。

【0037】

プロセッサ１０２は、例えば、プロセッサ、処理ユニット、又はマイクロプロセッサであってもよい。プロセッサ１０２は、例えば、１つ以上の一般的なプロセッサ、デジタル信号プロセッサ、特定用途向け集積回路、フィールド・プログラマブル・ゲート・アレイ、アナログ回路、デジタル回路、プログラムされたプロセッサ、及び／又はそれらの組合せを含んでもよい。プロセッサ１０２は、単一のデバイス又は、ネットワーク若しくは分散処理に関連付けられた１つ以上のデバイスなどのデバイスの組み合わせであってもよい。いくつかの処理戦略では、例えば、マルチ処理、マルチタスク、並行処理、及び／又はリモート処理などが使用されてもよい。処理は、ローカル又はリモートであってもよく、１つのプロセッサから別のプロセッサに移動されてもよい。コンピュータデバイス１００は、マルチプロセッサシステムであってもよく、そして相互接続バス１０４に通信可能に接続される１つ以上の追加のプロセッサを含んでいてもよい。

【0038】

プロセッサ１０２は、１つ以上の有形メディア、例えば、システムメモリ１１２、大容量記憶メモリ１１４などで、及び／又はネットワークインタフェース１１８を介して、エンコードされたロジックを実行するように動作可能であってもよい。本明細書で使用されているように、１つ以上の有形メディアにエンコードされたロジックは、プロセッサ１０２又は別のプロセッサによって実行可能な命令を含んでいる。ロジックは、例えば、ソフトウェア、ハードウェア、集積回路、ファームウェア、及び／又はマイクロコードの一部として記憶されてもよい。ロジックは、外部の通信デバイスから、例えば、インターネットに接続された通信ネットワークを介して受信されてもよい。プロセッサ１０２は、ロジックを実行し、図に示され、若しくは本明細書に記載された機能、動作、又はタスクを行ってもよい。

【0039】

図１のプロセッサ１０２は、メモリコントローラ１０８とＩ／Ｏコントローラ１１０とを含むチップセット１０６に接続されている。チップセットは、通常、Ｉ／Ｏ及びメモリ管理機能、並びに汎用及び／又は特殊用途レジスタ、及びアクセス可能であり、又はチップセット１０６に接続された１つ以上のプロセッサによって使用されるタイマーを提供する。メモリコントローラ１０８は、プロセッサ１０２（又はマルチプロセッサの場合に複数のプロセッサ）をシステムメモリ１１２と大容量記憶メモリ１１４にアクセス可能にする機能を実行する。

【0040】

システムメモリ１１２と大容量記憶メモリ１１４は、例えば、１つ以上の有形メディア、例えば、コンピュータ読み取り可能な記録媒体であってもよい。システムメモリ１１２は、様々なタイプの揮発性及び不揮発性記録媒体を含んでもよく、例えば、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリー・メモリ（ＲＯＭ）、プログラマブル・リード・オンリー・メモリ（ＰＲＯＭ）、電気的プログラマブル・リード・オンリー・メモリ（ＰＲＯＭ）、電気的に消去可能なリード・オンリー・メモリ（ＥＰＲＯＭ）、フラッシュメモリ、いくつかの他の有形データ記憶デバイス、それらのいくつかの組み合わせを含む。大容量記憶メモリ１１４は、様々なタイプの大容量記憶デバイスを含んでもよく、例えば、ハードディスクドライブ、光学メディア、磁気テープ、いくつかの他の有形データ記憶デバイス、又はそれらのいくつかの組み合わせを含む。特定の実施形態では、システムメモリ１１２と大容量記憶メモリ１１４は、非一時的である。

【0041】

システムメモリ１１２と大容量記憶メモリ１１４は、例えば、単一のメモリモジュールであってもよい。システムメモリ１１２と大容量記憶メモリ１１４は、プロセッサ１０２に隣接し、の一部であり、にプログラムされ、にネットワーク接続され、及び／又はから離れており、システムメモリ１１２と大容量記憶メモリ１１４に記憶されたデータは、例えば、プロセッサ１０２によって取り出され、処理されるようになっている。命令が実行され、本明細書で記載されている、若しくは図に示されている動作又は機能のうち１つ以上を行ってもよい。

【0042】

Ｉ／Ｏコントローラ１１０は、機能を実行し、プロセッサ１０２が、Ｉ／Ｏバス１１６を通って、ネットワークインタフェース１１８、ディスプレイ１２０、入力デバイス１２２、及び出力デバイス１２４と通信可能になる。メモリコントローラ１０８とＩ／Ｏコントローラ１１０は、チップセット１０６内に、別のブロックとして図１に示されているが、これらのブロックによって実行される機能は、単一の半導体回路内に統合されてもよく、又は２つ以上の別の集積回路を使用して実現されてもよい。コンピュータデバイス１００の構成要素の１つ以上は、チップ上のシステム（例えば、ＩＰＨＯＮＥ（商標）のチップ上のシステム）として実現されてもよい。

【0043】

ネットワークインタフェース１１８は、一方向又は双方向の通信接続であってもよい。したがって、ネットワークインタフェース１１８は、１つ、２つ、又はそれ以上の通信ネットワーク又はデバイスに通信可能に接続されてもよい。例えば、相互接続バス１０４は、ネットワークインタフェース１１８を介して、サーバと接続されてもよく、１つ、いくつか、すべてのコンピュータデバイス１００の構成要素がアクセス可能であり、又はサーバと通信するようになっている。別の例として、ネットワークインタフェース１１８は、他の通信接続を有する相互接続バス１０４に接続されてもよい。ネットワークインタフェース１１８は、例えば、総合デジタル通信網（ＩＳＤＮ）カード又はデータ通信接続を提供するモデムであってもよい。別の例として、ネットワークインタフェース１１８は、ローカル・エリア・ネットワーク（ＬＡＮ）カードであってもよく、データ通信接続を、例えば、インターネットに接続された互換性のあるＬＡＮに提供する。無線リンクも実装されてもよい。ネットワークインタフェース１１８は、例えば、様々な種類の情報を表すアナログ又はデジタル・データ・ストリームを伝送する電気、電磁気、又は光信号を送受信してもよい。

【0044】

ディスプレイデバイス１２０は、例えば、ビジュアル・アウトプット・デバイス、ブラウン管（ＣＲＴ）ディスプレイ、電子ディスプレイ、電子ペーパー、フラットパネルディスプレイ、発光ダイオード（ＬＥＤ）ディスプレイ、エレクトロルミネッセント・ディスプレイ（ＥＬＤ）、プラズマ・ディスプレイ・パネル（ＰＤＰ）、液晶ディスプレイ（ＬＣＤ）、薄膜トランジスタ・ディスプレイ（ＴＦＴ）、有機発光ダイオード・ディスプレイ（ＯＬＥＤ）、表面伝導型電子放出素子ディスプレイ（ＳＥＤ）、レーザテレビ、カーボンナノチューブ、ナノ液晶ディスプレイ、ヘッドマウント・ディスプレイ、プロジェクタ、３次元ディスプレイ、及び／又は透明ディスプレイデバイスを含んでもよい。

【0045】

ディスプレイデバイス１２０は、画面を表示し、インタラクティブにユーザがデータを入力できるようになっている。

【0046】

入力デバイス１２２は、例えば、キーボード、マウス、マイクロフォン、タッチスクリーン、トラックボール、キーパッド、ジョイスティック、及び／又は入力を提供するための他のデバイスを含んでもよい。入力デバイス１２２は、例えば、プロセッサ１０２にコマンド選択を提供するように使用されてもよい。例えば、入力デバイス１２２は、画面に表示されたカーソルを制御するように使用されるマウスであってもよい。マウスは、例えば、選択と制御をするための１つ以上のボタンを含んでもよい。

【0047】

出力デバイス１２４は、例えば、キーボード、マウス、スピーカー、タッチスクリーン、トラックボール、キーパッド、触覚デバイス又はシステム、ジョイスティック、及び／又は出力を提供するための他のデバイスを含んでもよい。例えば、出力デバイス１２４は、１つ以上の信号、例えば、触覚信号又は音声信号、をユーザに出力するように使用されてもよい。入力デバイス１２２と出力デバイス１２４は、別のブロックとして図１に示されているが、これらのブロックによって実行される機能は、単一のＩ／Ｏデバイスに統合されてもよい。

【0048】

ＩＩＩ．メッセージ・ストリーム・インテグリティ技術
ユーザは、最新かつ正確に送信及び配信されたメッセージを信頼し、情報に基づいて意思決定を行う。メッセージがネットワークを介して送信されたとき、例えば、中間デバイスのメッセージのドロップ、リンク障害、リソース不足（例えば、メモリ又は処理）、又は中間デバイスのクラッシュ又はリセットに起因して、それらが遅延する及び／又は失われる可能性がある。したがって、送信又は受信に失敗したロスト・メッセージを適切に検出することは、メッセージ・ストリームのインテグリティを保持するために望ましい。

【0049】

メッセージが失われたと決定されたとき、様々な動作、例えば、ロスト・メッセージの再送信の要求、メッセージ・ストリームの終了又はリセット、ログファイルにエントリの作成、エラーメッセージの提供、割り込みの生成、ロスト・メッセージについての受信データを処理するアプリケーション又は高レベルプロトコルへの警告、プログラムの実行の中止、メッセージが失われたことを１人以上のユーザへの通知、メッセージ・ストリームの終了と新しいメッセージ・ストリームの確立、ライセンスのリリースと再取得、サーバの再認証、及び／又は完全なデータセットの再ダウンロードなどの動作がとられてもよい。

【0050】

いくつかの現在のシステムは、シーケンス番号又はメッセージ識別器を使用し、ロスト・メッセージの検出を補助してもよい。シーケンス番号又はメッセージ識別器は、各メッセージの所定の量によって変化し（通常、増加する）、受信者は、メッセージの送信された順番、どのメッセージが失われたかどうか、の両方を決定することができる。受信者は、例えば、ネットワークの動作に起因して順番が乱れて受信し得たメッセージをバッファリングしてもよい。メッセージが受信されないとき、欠落しているとみなすことができる。欠落しているメッセージは、例えば、中間デバイスで再び順番付けられることにより、又は再送信に起因して、しばらく経ってから受信されることがある。もし一定期間後に、シーケンス内の欠落しているメッセージが受信されない場合、受信者は、メッセージが失われたと決定することができる。別の例では、後のメッセージを順番が乱れて受信したとき、潜在的に前のメッセージを受信するまで一定時間待つよりむしろ、順序が乱れて後のメッセージを受信したとき、欠落している前のメッセージは、失われたと決定してもよい。

【0051】

いくつかのシステムでは、例えば、データのソースから離れたデバイスで監視されているオブジェクトのデータを変更する場合など、メッセージの送信頻度が低い場合がある。

【0052】

例えば、サーバがアクセス可能かアクセス不可能か、及びサーバとの接続がアクセス可能かアクセス不可能かなどのステート変化に関連するサーバについての情報を送信することがまれにある。別の例として、ニュース・メッセージなどのメッセージを送信することがまれにある。別の例として、起動時及びロスト・メッセージが続いて検出されたときなどに、データのダウンロードを行うことがまれにある。

【0053】

メッセージ・ストリーム・インテグリティは、後の受信したメッセージのシーケンス暗号に基づいてロスト・メッセージを検出することに依存する場合、メッセージの送信がまれであると、ロスト・メッセージが検出される前に許容できない遅延が生じる可能性がある。例えば、データのステートにおける第１の変化に関連するメッセージが送信された場合、失われているが、受信者は、データのステートにおける第２の変化に関連するメッセージが受信されるまでロスト・メッセージを検出しない可能性がある。メッセージの送信頻度が低い場合、第２のメッセージは、第１のメッセージが失われて数時間経ってから受信する可能性がある。別の例として、ステートに第２の変化がない場合、第１のメッセージロスが検出されない可能性がある。したがって、第１のメッセージのロスとロスト・メッセージの検出との間の時間において、受信者は、誤ったデータを使用していることになる。

【0054】

Ａ．一定間隔手法を用いたハートビート
現在のシステムによって使用される１つの手法は、ロスト・メッセージを検出する可能性を高めるものであり、送信されるべき新しいデータがあるか否かに関係なく、いくつかの定義された間隔でメッセージが送信されるものである。この手法を使用するシステムは、例えば、最後のメッセージが送信されてから特定の時間が経過した場合に、ハートビート・メッセージを送信する。ハートビート・メッセージはまた、例えば、アライブ・メッセージ、キープ・アライブ・メッセージ、ステータス・メッセージ、又は同期メッセージと呼ばれてもよい。一定間隔手法を用いたハートビートは、図２Ａのメッセージの例に示されている。

【0055】

図２Ａは、定義された時間間隔が“１”の場合の一定間隔手法を用いたハートビートを利用するメッセージの例を示す。この例では、データ・メッセージは“Ｍ”と表記され、ハートビート・メッセージは“ＨＢ”と表記されている。ここでは、各データ・メッセージのシーケンス番号が１増える。この例では、第１のデータ・メッセージＭ１が時間ｔ＝０のとき、シーケンス番号“０”と共に送信される。定義された時間間隔が“１”であるため、新しいデータがこの時間間隔内で送信されるべきではなく、システムは、時間ｔ＝１のとき、シーケンス番号“０”と共に第１のハートビート・メッセージＨＢ１を送信する。この例では、ハートビート・メッセージは、送信された最後のデータ・メッセージのシーケンス番号を繰り返す。特定の実施形態では、ハートビート・メッセージは、それら自身のシーケンス番号に関連付けられてもよい。

【0056】

時間ｔ＝２のとき、送信されるべき新しいデータがない場合、システムは、送信された最後のデータ・メッセージであるデータ・メッセージＭ１と同じシーケンス番号であるシーケンス番号“０”と共に第２のハートビート・メッセージＨＢ２を送信する。時間ｔ＝３のとき、送信されるべき新しいデータがない場合、システムは、シーケンス番号“０”と共に第３のハートビート・メッセージＨＢ３を送信する。時間ｔ＝４のとき、送信されるべき新しいデータがない場合、システムは、シーケンス番号“０”と共に第４のハートビート・メッセージＨＢ４を送信する。時間ｔ＝５のとき、送信されるべき新しいデータがある。したがって、システムは、第２のデータ・メッセージＭ２を送信し、シーケンス番号を“１”に増やす。時間ｔ＝６のとき、送信されるべき新しいデータがある。システムは、第３のデータ・メッセージＭ３を送信し、シーケンス番号を“２”に増やす。時間ｔ＝７のとき、送信されるべき新しいデータがない場合、システムは、送信された最後のデータ・メッセージであるデータ・メッセージＭ３と同じシーケンス番号である、シーケンス番号“２” と共に第５のハートビート・メッセージＨＢ５を送信する。

【0057】

例えば、“１”などの定義された間隔でハートビート・メッセージを送信することによって、システムは、メッセージのロストとロスト・メッセージの検出との間の時間に上限を設けることができる。受信者が、定義された時間間隔を知っているため、システムは、ロスト・メッセージの検出に上限を設けることができ、メッセージが定義された時間内に受信されない場合に検出することができる。この例では、データ・メッセージＭ３が失われた場合、システムは、次にシーケンス番号“２”と共にハートビート・メッセージＨＢ５を受信する。システムは、受信したハートビート・メッセージのシーケンス番号“２”を最後に受信したメッセージのシーケンス番号、ここではデータ・メッセージＭ２のシーケンス番号“１”と比較する。この例では、ハートビート・メッセージは、前回送信されたデータ・メッセージのシーケンス番号を保持するため、システムは、定義された時間“１”以内にロスト・メッセージを検出する。別の例では、定義された時間間隔よりも長い、例えば、少し、一定の時間長い、又は定義された間隔の２倍などのいくつかの時間レンジ内に受信されない場合、受信者は、ネットワーク遅延の変動を許容するように検出してもよい。

【0058】

しかしながら、上述した定義された時間間隔を有するハートビートシステムでは、例えば、ステート情報の更新がまれであることが多い場合、対応するハートビート・メッセージが多数ある。多数のハートビート・メッセージは、限られたネットワーク帯域幅を非効率に使用し、及び／又はネットワーク上の他のデータ・メッセージの配信の待ち時間を増やす可能性がある。例えば、特定のサーバがアプリケーションを実行し、１５００人のユーザを管理している場合であって、各ユーザに２つのエンドポイントが存在する場合、サーバによって管理されるエンドポイントは、３０００存在する。アクティビティ又は更新されたステート情報がない場合、例えば、３０００のハートビート・メッセージが毎秒必要とされる可能性があり、限られたネットワーク帯域幅を非効率的に使用し、別のサーバシステムから受信される情報のための処理機能へのアクセスを取り除く及び／又は遅延させる。

【0059】

Ｂ．増大間隔手法を用いたハートビート
特定の実施形態は、ハートビート・メッセージ間の間隔を増大させることによって過度の非データ・ネットワーク・トラフィックのこの問題に対処している。例えば、第１のハートビートは、最後のデータ・メッセージが送信された後に、一定の時間送信することができる。後続のハートビート・メッセージは、時間間隔を増大させた後、それから送信されてもよい。例えば、間隔は、一定時間増大し、倍増し、幾何学的に増大し、指数関数的に増大し、又は様々な一定の間隔などの所定の時間だけ増大し、又はフィボナッチ若しくは素数などのシーケンスに基づいて増大してもよい。ロスト・メッセージの検出の効率を向上させるため、間隔は、最大値にキャップされる又は制限されてもよい。間隔を最大値にキャップする又は制限することは、時間間隔が事実上無制限になることを防止し、メッセージのロストとロスト・メッセージの検出との間の時間の上限を維持する。

【0060】

図２Ｂは、時間間隔が２倍の場合の増大間隔手法を用いたハートビートの例を利用するメッセージの例を示す。この例では、データ・メッセージは、“Ｍ”と表記され、ハートビート・メッセージは、“ＨＢ”と表記されている。ここでは、各メッセージのシーケンス番号は、１増加し、ハートビート・メッセージが送信された最後のデータ・メッセージのシーケンス番号を含んでいる。この例では、第１のデータ・メッセージＭ１は、時間ｔ＝０のとき、シーケンス番号“０”と共に送信される。第１の時間間隔は“１”であり、この時間間隔内で新しいデータは送信されない。したがって、システムは、時間ｔ＝１のとき、シーケンス番号“０”と共に第１のハートビート・メッセージＨＢ１を送信する。

【0061】

この例では、時間間隔は２倍であって、それ故、前の時間間隔“１”の２倍の量である、時間ｔ＝３（ｔ＝１（最後のハートビート・メッセージが送信された時間）＋１（前の間隔）＊２（２倍））のときに、次のハートビート・メッセージが送信される。時間ｔ＝３のとき、送信されるべき新しいデータがない場合、システムは、送信された最後のデータ・メッセージであるデータ・メッセージＭ１と同じシーケンス番号である、シーケンス番号“０”と共に第２のハートビート・メッセージＨＢ２を送信する。次のハートビート・メッセージは、前の時間間隔“２”の２倍の量である、時間ｔ＝７（ｔ＝３（最後のハートビート・メッセージが送信された時間）＋２（前の間隔）＊２（２倍））のときに送信される。なお、時間ｔ＝５のとき、新しいデータが送信される。したがって、システムは、第２のデータ・メッセージＭ２を送信し、シーケンス番号を“１”に増やす。時間ｔ＝６のとき、送信されるべき新しいデータがあり、それ故、システムは、第３のデータ・メッセージＭ３を送信し、シーケンス番号を“２”に増やす。次のハービートメッセージは、初期の時間間隔“１”に戻って、時間ｔ＝７のときに送信されるべきである。時間ｔ＝７のとき、送信されるべき新しいデータがない場合、システムは、送信された最後のデータ・メッセージであるデータ・メッセージＭ３と同じシーケンス番号である、シーケンス番号“２” と共に第３のハートビート・メッセージＨＢ３を送信する。

【0062】

上記の図２Ｂに示された増大間隔手法は、一定のハートビート間隔と比較すると、ハートビート・メッセージによりネットワーク・トラフィックを低減している。ここで、上記の図２Ａに示された一定のハートビート間隔は、増大間隔手法の初期の間隔と同じである。図２Ａの例では、４つのハートビート・メッセージが、２つのデータ・メッセージ（Ｍ１とＭ２）間に送信される。この例の場合では、２つのハートビート・メッセージのみが送信される。

【0063】

また、増大間隔手法は、一時的なリンク障害に対するいくつかの許容範囲を提供する、例えば、リンクがダウンし、接続が増大した間隔の期間に復元され、新しいメッセージが送信されない場合、一時的なリンク障害が検出されない。データが失われないので、そのような障害は、ストリーム・インテグリティのために問題となることはないかもしれないが、一定間隔手法は、そのような一時的なリンク障害を検出する可能性が高い。

【0064】

図２Ｃは、上記の増大間隔手法を用いたハートビートに基づいてメッセージを送信する方法２００のフロー図の例を示す。この例では、各データ・メッセージは、異なるシーケンス番号を有している。例えば、各データ・メッセージは、前回のデータ・メッセージのシーケンス番号より１つ大きいシーケンス番号を有していてもよい。この例では、ハートビート・メッセージは、ハートビートの前に送信された最後のデータ・メッセージと同じシーケンス番号を使用する。

【0065】

ブロック２０１で、送信されるべきメッセージのシーケンス番号がリセットされ、ハートビート・メッセージが送信されるべき時間が示された、次のハートビートタイムがセットされる。例えば、シーケンス番号は、“０”又は“−１”にリセットされてもよく、次のハートビートタイムは、データ・メッセージがまだ送信されないので、“無限”にセットされてもよい。

【0066】

ブロック２０２で、新しいデータ・メッセージが送信されるかどうか、又は次のハートビートタイムに達したかどうかを決定する。例えば、送信するための新しいデータ・メッセージがアプリケーションから受信されてもよい。別の例として、ハートビートタイムと関連付けられたタイマーが終了してもよい。

【0067】

新しいメッセージが送信されるべき場合（ブロック２０２で決定されるように）、ブロック２０３で、送信されるべきメッセージのシーケンス番号が増加する。例えば、シーケンス番号が“０”から“１”に、又は“−１”から“０”に１増加してもよい。

【0068】

ブロック２０４で、新しいデータ・メッセージが図２Ｂのデータ・メッセージＭ１などの増加したシーケンス番号と共に送信される。

【0069】

ブロック２０５で、次のハートビートタイムが、新しいデータ・メッセージが送信された時間に初期の間隔を足した時間にセットされる（及び前回設定された次のハートビートタイムがクリアされる）。例えば、新しいデータ・メッセージがｔ＝０のときに送信され、初期のハートビート間隔が“１”であり、それから次のハートビートタイムがｔ＝１にセットされてもよい。次いで制御は、ブロック２０２に戻る。

【0070】

送信するべき新しいデータ・メッセージがなく、次のハートビートタイムに達している場合（ブロック２０２で決定されるように）、ブロック２０６で、ハートビート・メッセージが、図２Ｂのハートビート・メッセージＨＢ２などの、送信された最後のデータ・メッセージのシーケンス番号である、現在のシーケンス番号と共に送信される。

【0071】

ブロック２０７で、この例では、送信された最後のハートビート・メッセージの間隔を２倍にし、それをブロック２０６で送信された直近のハートビート・メッセージの時間に追加することによって、次のハートビートタイムが決定される。例えば、直近の送信されたハートビート・メッセージがハートビート間隔“２”の後、ｔ＝３のときに送信された場合、次のハートビートタイムがｔ＝７（ｔ＝３（送信された直近のハートビート・メッセージ）＋２（前のハートビート間隔）＊２（２倍））にセットされる。次いで制御は、ブロック２０２に戻る。

【0072】

上記の増大間隔手法を用いたハートビートに基づいてメッセージを送信する方法は、シーケンス番号をデータ・メッセージに関連付け、対応するシーケンス番号を、データ・メッセージの後に送信されたハートビート・メッセージに関連付ける。データ及びハートビート・メッセージへのシーケンス番号の関連付けは、データ・メッセージが失ってからその後のメッセージが受信される時間内に、ロスト・メッセージが検出されることを可能にする。

【0073】

図２Ｄは、上記の増大間隔手法を用いたハートビートに基づいてメッセージを受信する方法２１０のフロー図の例を示す。この例では、各データ・メッセージは、異なるシーケンス番号を有している。例えば、各データ・メッセージは、前回のデータ・メッセージのシーケンス番号より１大きいシーケンス番号を有していてもよい。この例では、ハートビート・メッセージは、ハートビートの前に送信された最後のデータ・メッセージと同じシーケンス番号を使用している。

【0074】

ブロック２１１で、受信されるべきメッセージの予想シーケンス番号がリセットされる。例えば、予想シーケンス番号は、“０”又は“−１”にリセットされてもよい。

【0075】

ブロック２１２で、メッセージが受信される。メッセージは、例えば、データ・メッセージ又はハートビート・メッセージであってもよい。メッセージが予想時間間隔内に受信されない場合、ロスト・メッセージが報知されてもよい。予想時間間隔は、例えば、送信されるデータ・メッセージと第１のハートビート・メッセージとの間の初期の時間間隔に基づくものであってもよく、又は予想時間間隔は、２つのハートビート・メッセージ間の間隔に基づくものであってもよい。例えば、初期の時間間隔及び／又は２つのハートビート・メッセージ間の間隔は、一定時間又は２倍増加し、ネットワーク遅延の変動を許容し、予想時間間隔を決定してもよい。

【0076】

ブロック２１３で、受信されたメッセージの予想シーケンス番号が決定される。受信されたメッセージがデータ・メッセージの場合、予想シーケンス番号は、前回受信されたメッセージ（又は前回受信されたメッセージがない場合、リセットされた予想シーケンス番号から）のシーケンス番号を増加することによって決定されてもよい。例えば、シーケンス番号は、“０”から“１”、又は“−１”から“０”に１増加されてもよい。受信されたメッセージがハートビート・メッセージの場合、この例では、予想シーケンス番号は、前回受信されたメッセージと同じシーケンス番号である。

【0077】

ブロック２１４で、受信されたメッセージのシーケンス番号は、ブロック２１３で決定された予想シーケンス番号と比較される。

【0078】

受信されたシーケンス番号が予想シーケンス番号と等しくない場合（ブロック２１４で決定されるように）、ブロック２１５で、ロスト・メッセージが報知されてもよい。特定の実施形態では、ロスト・メッセージは、ロスト・メッセージがデータ・メッセージの場合のみ報知されてもよい。特定の実施形態では、システムは、メッセージが欠落していることを決定し、欠落したメッセージを受信する時間待機してもよい。欠落したメッセージが時間内に受信されない場合、システムは、ロストとして欠落したメッセージを報知する。

【0079】

受信されたメッセージのシーケンス番号が予想シーケンス番号と等しい場合（ブロック２１４で決定されるように）、受信されたメッセージがデータ・メッセージであるかを決定する。受信されたメッセージがデータ・メッセージである場合、ブロック２１７で、データ・メッセージが処理され、制御がブロック２１２に戻る。

【0080】

上記の増大間隔手法を用いたハートビートに基づいてメッセージを受信する方法は、各データ・メッセージのシーケンス番号の増加を予測し、前回送信されたデータ・メッセージのシーケンス番号と同じハートビート・メッセージのシーケンス番号を予測する。データ及びハートビート・メッセージへのシーケンス番号の関連付けは、データ・メッセージのロストから次のメッセージが受信されるまでの時間内に、ロスト・メッセージが検出されることを可能にする。

【0081】

Ｃ．ストップ・メッセージ手法
特定の実施形態は、ストップ・メッセージ手法を利用することによって、過度の非データ・ネットワーク・トラフィックの問題に対処している。ストップ・メッセージ手法では、ストップ・メッセージが送信され、送信機が追加のハートビート・メッセージを提供せずに、受信者の次に受信するメッセージがデータ・メッセージであることを受信者に示している。ストップ・メッセージはまた、例えば、エンド・メッセージ又はハートビート・サスペンション・メッセージと呼ばれてもよい。さらに、ストップ・メッセージは、異なるメッセージの種類であってもよく、又はハートビート・メッセージ又はデータ・メッセージなどの別のメッセージにおけるフラグによって表されてもよい。一例では、ストップ・メッセージは、データ・メッセージにおけるフラグによって表されてもよい。この例では、ストップ・メッセージ手法は、単独で使用されてもよく、又はハートビート・メッセージ手法との組み合わせで使用されてもよい。

【0082】

さらに、使用されるハートビート・メッセージとストップ・メッセージの数は、変更してもよい。例えば、３つのハートビート・メッセージが送信され、ストップ・メッセージが続いてもよい。別の例では、３つのハートビート・メッセージは、ストップ・メッセージ・フラグを有する最後のハートビート・メッセージと共に送信されてもよい。別の例では、送信されるべきハートビート・メッセージの数は、使用されるリンク／トランスポートの待ち時間に基づいてもよい。

【0083】

ストップ・メッセージ手法は、図２Ａ−２Ｄを参照して上記したような同様の方法でロスト・メッセージの検出を増やしている。さらに、ストップ・メッセージ手法は、過度のハートビート・メッセージに起因するネットワーク・トラフィックを更に低減し、図２Ｂを参照して上記した増大間隔手法と同様に一時的なリンク障害に対していくつかの許容範囲を提供する。

【0084】

図３Ａ及び図３Ｂは、送信されるハートビート・メッセージの数を減らした場合のストップ・メッセージ手法の利点を示す。図３Ａは、上記したような増大間隔手法を用いたハートビートの例を利用するメッセージの例を示す。この例では、データ・メッセージは“Ｍ”と表記され、ハートビート・メッセージは“ＨＢ”と表記される。ここでは、ハートビート・メッセージの時間間隔は、２倍されており、ハートビート・メッセージは、送信された最後のデータ・メッセージのシーケンス番号を含む。この例では、第１のデータ・メッセージＭ１が、時間ｔ＝０のときに、シーケンス番号“０”と共に送信される。第１の時間間隔は“１”であり、この時間間隔内に送信されるべき新しいデータはない。したがって、システムは、時間ｔ＝１のとき、シーケンス番号“０”と共に第１のハートビート・メッセージＨＢ１を送信する。時間ｔ＝３（１（前の間隔）＊２（２倍）＝２の間隔後）のとき、送信されるべき新しいデータはなく、システムは、シーケンス番号“０”と共に第２のハートビート・メッセージＨＢ２を送信する。時間ｔ＝７（２（前の間隔）＊２（２倍）＝４の間隔後）のとき、送信されるべき新しいデータがない場合、システムは、シーケンス番号“０”と共に第３のハートビート・メッセージＨＢ３を送信する。時間ｔ＝１１（ハートビート・メッセージが送信される次の時間の前）のとき、送信されるべき新しいデータがある。したがって、システムは、第２のデータ・メッセージＭ２を送信し、シーケンス番号を“１”に増やす。図３Ａの例では、３つのハートビート・メッセージは、第２のデータ・メッセージが送信される前に送信される。これらのハートビート・メッセージは、過剰となる可能性があり、ネットワーク・トラフィックを増大させることになる可能性もある。

【0085】

図３Ｂは、上記したストップ・メッセージ手法の例を利用するメッセージを示す。この例では、ストップ・メッセージは“ＳＭ”と表記され、ハートビート・メッセージは、使用されない。代わりに、初期の間隔“１”の後、ストップ・メッセージが送信され、送信された最後のデータ・メッセージのシーケンス番号を含む。この例では、第１のデータ・メッセージＭ１が、時間ｔ＝０のとき、シーケンス番号“０”と共に送信される。時間ｔ＝１のとき、送信されるべき新しいデータがない場合、ストップ・メッセージＳＭ１がシーケンス番号“０”と共に送信される。このストップ・メッセージは、追加のハートビート・メッセージが送信されず、受信されるべき次のメッセージがデータ・メッセージであることを示している。時間ｔ＝１１のとき、データ・メッセージＭ２がシーケンス番号“１”と共に送信される。図３Ｂに示されるストップ・メッセージ手法は、ハートビート・メッセージの数を減らすことによって、ネットワーク・トラフィックを低減している。図３Ａの例では、３つのハートビート・メッセージが２つのデータ・メッセージの間に送信され、この例の場合、１つのストップ・メッセージのみが送信される。

【0086】

Ｄ．メッセージ・ストリーム・ステートをクリアする手法
特定の実施形態は、送信機及び受信機の両方によって維持されるメッセージ・ストリームについてのステート情報に対処している。メッセージ・ストリーム・ステートは、特定のメッセージ・ストリームに特有の情報である。メッセージ・ストリームは、特定のオブジェクト、項目などに関連するメッセージの論理通信チャンネルである。例えば、監視される各オブジェクトが、そのオブジェクトに関連付けられたメッセージのメッセージ・ストリームに関連付けられてもよい。別の例として、各ユーザは、パーソナル・インボックス・ストリームなどの明確にユーザに向けられたメッセージのメッセージ・ストリームを有していてもよい。送信機のために、例えば、メッセージ・ストリーム・ステートは、最後に送信されたシーケンス番号、最後に送信された時間、再送信のための送信されたデータのコピー、受信者のアドレス又は主題、及びハートビート・メッセージの時間間隔の送信に関連する情報を含んでもよい。

【0087】

受信者のアドレスは、基本的なリンク及び／トランスポートアドレスと異なっていてもよく、例えば、ＩＰネットワーク、プロセス間通信（“ＩＰＣ”）、共有メモリ、及び／又はインフィニバンド（登録商標）などのメッセージ・パッシング・ファブリックを含む。例えば、特定の実施形態は、ＩＰマルチキャストメカニズムのトップに使用され、１人以上の受信者が単一のＩＰマルチキャストグループに参加してもよい。受信者は、メッセージに含まれる対象アドレスに基づいて、それらのために意図されたメッセージを識別する。別の受信者は、異なる対象に興味がある可能性があり、さらにＩＰマルチキャストグループの各メンバーがすべてのマルチキャストメッセージを受信する。特定の主題に興味がない受信者は、それが受信されていなかったかのように、そのメッセージをドロップする。単一のＩＰマルチキャストグループは所定の値であってもよいが、対象アドレスは、メッセージ・ストリーム・ステートの一部である。なぜならば、それは、例えば、監視されるオブジェクトに関連付けられたメッセージ・ストリームに対して特有であるためである。

【0088】

受信機のために、メッセージ・ストリーム・ステートは、例えば、最後に受信されたシーケンス番号、最後に受信した時間、順番が乱れたメッセージのコピー、送信機に関連するアドレス又は主題、ロスト・メッセージを検出するための送信間隔に関連する情報を含んでもよい。例えば、メッセージの順番付けをする中間デバイスもまた各メッセージ・ストリームのメッセージ・ストリーム・ステートを維持してもよい。

【0089】

そのようなメッセージ・ストリーム・ステート情報は、数千のオブジェクト及び／又はユーザとして考えても、メモリ又は強力なサーバのソケット、プロセス、接続、又はポートなどの他のリソースの小さい部分のみを占有するとして退けられる可能性がある。しかしながら、サーバが一度に、数ヶ月、又はそれ以上長く動作すると予想される場合、メッセージ・ストリーム・ステートを維持しなければならないオブジェクト及びユーザの数が無限となり、理論的には、サーバがメモリ又は他のリソースを使い果たす可能性がある。さらに、メッセージの並べ替えがサポートされている場合、各メッセージ・ストリームに対してバッファが必要とされる可能性、又は望まれる可能性がある。メッセージ・ストリームが多数の場合、これは、メモリ使用量のかなりの量を表すことができる。

【0090】

また、受信者の特定のタイプは、より限られたメモリ及び／又はリソースの制約を有していてもよい。例えば、大容量メモリ及び／又はリソースの要件は、モバイルデバイスなどのいくつかのデバイスにおける実用性又は費用効果でなくてもよい。別の例として、特殊なネットワーク・インタフェース・コントローラ（“ＮＩＣ”）・カードがメッセージ処理を実行してもよく、維持することができるストリームの数に影響を与えるリソース制限を有していてもよい。別の例として、ルータ及び／又はブリッジなどのデバイスは、リモートサイト又はネットワークで多数のクライアントに情報を提供することができるアプリケーション・プロトコル・ルータを含み、様々な構成において、受信者又は中間デバイスと見なすことができる。いくつかのデバイスは、例えば、メモリ及び／又はリソースの制約を有する特別な目的のハードウェアデバイスとして実現されてもよい。これにより、頻度の低いメッセージに関連するメッセージ・ストリームのために記憶する必要があるステート情報を低減することが望ましい。

【0091】

特定の実施形態は、上記したストップ・メッセージ手法、メッセージステート情報のクリアリングの組み合わせによってメッセージ・ストリーム・ステート情報を記憶する問題に対処している。伝送制御プロトコル（“ＴＣＰ”）接続又はマルチキャストグループなどの基本的なトランスポート接続は、閉じられる可能性がないかもしれないが、メッセージ・ストリーム・ステートは、クリアされ、破棄され、上書きされ、及び／又はメモリから割り当て解除され、関連付けられたソケットなどのリソースを開放してもよい。送信されるべきメッセージがなく、メッセージ・ストリーム・ステート情報を記憶する必要がないため、メッセージ・ストリーム・ステートのクリアが行われてもよい。したがって、ストップ・メッセージが送信及び／又は受信された後、ステート情報がクリアされてもよい。

【0092】

新しいデータ・メッセージが送信されるとき、新しいメッセージ・ストリームが作成され、所定のシーケンス番号で開始される。例えば、ストップ・メッセージが送信された後、新しいデータ・メッセージが送信される各時間では、新しいデータ・メッセージのシーケンス番号が“０”にリセットされてもよい。データ・メッセージの宛先は、ソース及び／メッセージ自体の内容に由来してもよい。例えば、メッセージの主題は、ユーザ情報に基づいて構成されてもよい。別の例として、宛先は、ユーザ情報、グループメンバーシップ情報、アプリケーション識別子、ユーザネーム、及び／又はアカウントに基づいて構成されてもよい。新しいデータ・メッセージが送信されたため、送信間隔に関連する状態は、所定の初期値にセットされる。これにより、ストリーム状態は、効果的に再作成される。

【0093】

図３Ｃは、上記したメッセージ・ストリーム・ステートをクリアする手法の例を組み合わせたストップ・メッセージ手法の例を利用するメッセージの例を示す。この例では、メッセージ・ストリームにおける各メッセージ（データ・メッセージとストップ・メッセージの両方）のシーケンス番号が“１”増える。データ・メッセージＭ１は、シーケンス番号“０”と共に送信され、データ・メッセージＭ２はシーケンス番号“１”と共に送信され、そしてストップ・メッセージＳＭ１はシーケンス番号“２”と共に送信される。ストップ・メッセージＳＭ１を送信した後、送信機、受信機のうち１つ以上、及び１つ以上の中間デバイスによって、メッセージ・ストリーム・ステートがクリアされる。送信されるべき後続のデータ・メッセージのシーケンス番号はまた、メッセージ・ストリーム・ステートがクリアされたため、所定の値“０”にリセットされる。ストップ・メッセージＳＭ１の送信は、次の受信されるメッセージがデータ・メッセージであるべきであって、データ・メッセージのシーケンス番号が“０”であるべきであることを受信者（又はいくつかの中間デバイス）に示す。この例では、後で、データ・メッセージＭ３がシーケンス番号“０”と共に送信され、データ・メッセージＭ４がシーケンス番号“１”と共に送信され、そしてストップ・メッセージＳＭ２がシーケンス番号“２”と共に送信される。ストップ・メッセージＳＭ１を受信した後、受信者は、シーケンス番号“０”と共にデータ・メッセージを受信することを予測する。例えば、データ・メッセージＭ３が失われた場合、受信者は、代わりにシーケンス番号“１”と共にデータ・メッセージＭ４を受信する。受信者は、受信されたデータ・メッセージＭ４のシーケンス番号が“０”でないことから、データ・メッセージが失われたと決定する。別の例では、データ・メッセージＭ３とＭ４が失われた場合、受信者は、受信したメッセージがシーケンス番号“２”のストップ・メッセージＳＭ２であり、シーケンス番号“０”と“１”のデータ・メッセージＭ３とＭ４ではないことから、両方のデータ・メッセージが失われたと決定する。

【0094】

Ｅ．フェーズ番号手法
上記したように、メッセージ・ストリーム・ステートをクリアする手法を使用するとき、新しいメッセージ・ストリーム・ステートが作成され、所定のシーケンス番号で開始される。例えば、各時間では、ストップ・メッセージが送信された後、新しいデータ・メッセージが送信され、新しいデータ・メッセージのシーケンス番号が“０”にリセットされる。ストップ・メッセージの送信後にメッセージ・ストリーム・ステートをクリアするシステムは、全体のメッセージ・シーケンスが失われたとき、失われたデータ・メッセージを検出することができない。メッセージ・シーケンスは、データ・メッセージのシーケンス及び対応する後続のストップ・メッセージである。そのようなシステムは、間違った順番のシーケンス番号に起因してロスト・メッセージを検出することができるが、全体のシーケンス番号が失われた場合、受信されたメッセージのシーケンス番号は、正しい順序に保持される。新しいメッセージ・シーケンスが“０”などのシーケンス番号で再開するため、受信されたメッセージは、正しい順序に保持される。新しいメッセージ・シーケンスのシーケンス番号がリセットされた場合、全体のメッセージ・シーケンスのロスが検出されない可能性がある。この問題の例は、図３Ｄに示されている。

【0095】

図３Ｄは、全体のメッセージ・シーケンスが検出されずに失われた場合のメッセージの例を示す。この例では、各メッセージのシーケンス番号が１増えて、ストップ・メッセージの送信の際に“０”にリセットされる。したがって、データ・メッセージＭ１は、シーケンス番号“０”と共に送信され、データ・メッセージＭ２は、シーケンス番号“１”と共に送信され、そしてストップ・メッセージＳＭ１は、シーケンス番号“２”と共に送信される。ストップ・メッセージが送信されるため、後続のデータ・メッセージのシーケンス番号が“０”にリセットされる。データ・メッセージＭ３がシーケンス番号“０”と共に送信され、データ・メッセージＭ４がシーケンス番号“１”と共に送信され、そしてストップ・メッセージＳＭ２がシーケンス番号“２”と共に送信される。別のストップ・メッセージが送信された場合、後続のデータ・メッセージのシーケンス番号がリセットされる。データ・メッセージＭ５がシーケンス番号“０”と共に送信され、データ・メッセージＭ６がシーケンス番号“１”と共に送信され、そしてストップ・メッセージＳＭ３がシーケンス番号“２”と共に送信される。

【0096】

この例では、データ・メッセージＭ３、データ・メッセージＭ４、及びストップ・メッセージＳＭ２が失われる。データ・メッセージのシーケンス番号がリセットされ、次いでストップ・メッセージが送信されるため、この例の受信者は、ロスト・メッセージＭ３、Ｍ４、及びＳＭ２を検出することができない。受信者は、ここでは、シーケンス番号“０”と共にデータ・メッセージを受信すると予測し、次いでＳＭ１を受信すると、そのようにするが、メッセージＭ３、Ｍ４及びＳＭ２のロスを検出しない。

【0097】

別の例として、ネットワーク遅延及びメッセージロスの両方に起因して、１つのメッセージ・シーケンスの一部が第２のメッセージ・シーケンスの一部と検出不可能に組み合わされている可能性があり、それ故に、システムは、これらの組み合わされたメッセージのロスを検出することができない場合がある。図３Ｅは、一例を示す。この例では、図３Ｄに示した上記の例と同様に、各メッセージのシーケンス番号が“１”増加し、ストップ・メッセージの送信の際に“０”にリセットされる。図３Ｅの例では、データ・メッセージＭ１がシーケンス番号“０”と共に送信され、データ・メッセージＭ２がシーケンス番号“１”と共に送信され、データ・メッセージＭ３がシーケンス番号“２”と共に送信され、そしてストップ・メッセージＳＭ１がシーケンス番号“３”と共に送信される。シーケンス番号がリセットされ、データ・メッセージＭ４がシーケンス番号“０”と共に送信され、データ・メッセージＭ５がシーケンス番号“１”と共に送信され、データ・メッセージＭ６がシーケンス番号“２”と共に送信され、ストップ・メッセージＳＭ２がシーケンス番号“３”と共に送信される。

【0098】

この例では、メッセージＭ３、ＳＭ１、Ｍ４、及びＭ５が失われる。シーケンス番号“１”と共にデータ・メッセージＭ２を受信した後、受信者は、シーケンス番号“２”と共にデータ・メッセージを受信することを予測する。ストップ・メッセージの送信後にシーケンス番号がリセットされるため、受信者は、シーケンス番号“２”と共にデータ・メッセージを受信するが、メッセージＭ３、ＳＭ１、Ｍ４、及びＭ５のロスを検出しない。メッセージが大きな間隔で送信されるが、中間デバイスでバッファされ及び／又は遅延し、いくつかのメッセージがその後ドロップされる場合、このシナリオが発生する可能性がある。

【0099】

メッセージ・ストリーム・ステートがクリアされ、後続の送信されたデータ・メッセージのシーケンス番号がリセットされ、メッセージ・シーケンスが失われる可能性がある場合のシナリオに対処するため、特定の実施形態は、シーケンス番号に加えて、各メッセージに含まれるフェーズ番号を提供する。フェーズ番号は、全体のメッセージ・シーケンスと同じに保持し、例えば、ストップ・メッセージが送信された後、後続のメッセージ・シーケンスのために別の値にセットされる識別子である。

【0100】

図３Ｆは、フェーズ番号手法に基づくフェーズ番号を有する図３Ｄのメッセージの例を示す。図３Ｆに示す例では、各メッセージ・シーケンスのフェーズ番号は、１増える。それ故、第１のメッセージ・シーケンスがフェーズ番号“０”と共に送信され、第２のメッセージ・シーケンスがフェーズ番号“１”と共に送信され、そして第３のメッセージ・シーケンスがフェーズ番号“２”と共に送信される。この例では、受信者は、１増えたフェーズ番号と共にメッセージ・シーケンスを受信することを予測する。したがって、第１のメッセージ・シーケンスがフェーズ番号“０”と共に受信された後、第３のメッセージ・シーケンスがフェーズ番号“２”と共に受信されたとき、受信者は、フェーズ番号“１”を有するメッセージ・シーケンスが失われたことを決定できる。

【0101】

図３Ｇは、フェーズ番号が含まれた図３Ｅのメッセージの例を示す。図３Ｇでは、各メッセージ・シーケンスのフェーズ番号が１増える。それ故、第１のメッセージ・シーケンスがフェーズ番号“０”と共に送信され、第２のメッセージ・シーケンスがフェーズ番号“１”と共に送信される。この例では、受信者は、１増えたフェーズ番号と共にメッセージ・シーケンスを受信すると予測する。シーケンス番号“１”及びフェーズ番号“０”と共にデータ・メッセージＭ２を受信した後、受信者は、シーケンス番号“２”及びフェーズ番号“０”と共にデータ・メッセージを受信することを予測する。メッセージＭ３、ＳＭ１、Ｍ４、及びＭ５が失われた場合、受信者は、代わりにシーケンス番号“２”及びフェーズ番号“１”と共にデータ・メッセージＭ６を受信する。受信されたデータ・メッセージのフェーズ番号が“０”ではないため、受信者は、ロスト・メッセージのシーケンスを検出することができる。

【0102】

別の例では、同じメッセージ・シーケンスの各メッセージが同じフェーズであるため、フェーズ番号は、クリアされ得るメッセージ・ストリーム・ステートの一部である。メッセージ・ストリーム・ステートをクリアすることの利点は、上記している。新しいメッセージ・シーケンスが開始するとき、次のメッセージ・シーケンスのフェーズの値は、新しいシーケンスが送信機から送信されることを繰り返さない、又は非常にまれに繰り返す方法で変更される送信機で入手可能なグローバル値又は関数から取得される。これは、受信者が次のフェーズ番号を予測することができなくなる。例えば、送信機は、プロトコルに実装可能であって新しいメッセージ・シーケンスが開始するそれぞれの時間に１増える１つの３２ビット符号なし整数値を保持する可能性がある。新しいシーケンスが送信機から送信される時間毎に、受信者にかかわらず、新しいフェーズ番号が選択される。したがって、この例では、送信機が多くの異なる受信者にメッセージ・シーケンスを送信し得るため、受信者は、メッセージ・シーケンスのフェーズ番号を予測することができない。

【0103】

図３Ｈは、受信者がメッセージ・シーケンスのフェーズ番号を予測することができないメッセージの例を示す。図３Ｈは、図３Ｇに示された例と同様であるが、図３Ｈでは、フェーズ番号がランダムに関連付けられている。図３Ｈの例では、第１のメッセージ・シーケンスがフェーズ番号“０”と共に送信され、第２のメッセージ・シーケンスがフェーズ番号“５”と共に送信される。シーケンス番号“１”及びフェーズ番号“０”と共にデータ・メッセージＭ２を受信した後、受信者は、フェーズ番号“０”と共にストップ・メッセージ又はデータ・メッセージを受信することを予測する。メッセージＭ３、ＳＭ１、Ｍ４、及びＭ５が失われた場合、受信者はシーケンス番号“２”及びフェーズ番号“５”と共にデータ・メッセージＭ６を受信する。データ・メッセージＭ６のフェーズ番号“５”とデータ・メッセージＭ２のフェーズ番号“０”とを比較し、受信者は、メッセージのシーケンスが失われたことを決定する。

【0104】

別の例では、受信者がメッセージ・シーケンスのフェーズ番号を予測できない場合、フェーズ番号がメッセージ・ストリームと共にクリアされると、受信者は、全体のメッセージ・シーケンスのロスを検出することができない可能性がある。この例においてロスト・メッセージを検出するため、リンク・ステート問題を検出可能なメカニズムが採用されていてもよい。例えば、複数のメッセージ・ストリームが同じリンク／トランスポートを介して送信される可能性があるため、各リンク／トランスポート・メカニズムに周期的にハートビートを送信し、特有のメッセージ・ストリームから独立した別のメカニズムが、これらのタイプのリンク障害を検出し、その結果アプリケーションがシーケンスを完全に失うことによって生じる問題を防止するように動作してもよい。また、いくつかの状況では、データの性質によって、後のシーケンスの処理中に、メッセージ・シーケンスのロスが受信者に明らかになる可能性がある。

【0105】

図４は、上記したフェーズ番号を使用するメッセージを送信する方法４００のフロー図の例を示す。この例では、フェーズ番号は、シーケンス番号と共に各メッセージと一緒に使用されており、ハートビート・メッセージは使用されず、データ・メッセージが送信されていない初期の間隔の後にストップ・メッセージのみが使用される。特定の実施形態では、ハートビート・メッセージはまた、ストップ・メッセージが送信される前に送信されてもよい。また、上記のメッセージ・ストリーム・ステートをクリアする手法の実施形態も、組み込まれている。

【0106】

ブロック４０１で、新しいメッセージが送信されたかどうかを決定する。新しいメッセージは、例えば、新しいデータ・メッセージ又はストップ・メッセージであってもよい。例えば、送信されるべき新しいデータ・メッセージは、アプリケーションから受信されてもよい。別の例では、初期の間隔と関連付けられたタイマーが終了となり、ストップ・メッセージが送信されるべきことを示してもよい。特定の実施形態では、送信されるべき新しいメッセージがハートビート・メッセージであってもよい。新しいメッセージが送信されるべきではないと決定した場合、その後、制御は、ブロック４０１に戻る。

【0107】

新しいメッセージが送信されるべきである場合（ブロック４０１で決定されるように）、ブロック４０２で、フェーズ番号が決定される。新しいメッセージがメッセージ・シーケンス内の第１のデータ・メッセージである場合、フェーズ番号は、例えば、前回のメッセージ・シーケンスのフェーズ番号を増加する（又はこれが送信された第１のメッセージ・シーケンスの場合、“０”などの所定の値を開始する）、又はグローバル値又は関数から新しいフェーズ番号を取得することによって決定されてもよい。例えば、最後のメッセージ・シーケンスのフェーズ番号が、“０”から“１”まで１増やしてもよい。新しいメッセージがメッセージ・シーケンス内の第１のデータ・メッセージではない場合、フェーズ番号は、送信された最後のメッセージのフェーズ番号であると決定されてもよい。例えば、送信された最後のメッセージのフェーズ番号が“１”である場合、その後、送信されるべき新しいメッセージのフェーズ番号も“１”である。

【0108】

ブロック４０３で、シーケンス番号が決定される。新しいメッセージがデータ・メッセージである場合、シーケンス番号は、前回送信されたデータ・メッセージのシーケンス番号を増加する（又はこれがメッセージ・シーケンス内の第１のデータ・メッセージの場合、“０”などの所定の値で開始する）ことによって決定されてもよい。例えば、シーケンス番号が“０”から“１”に１だけ増やしてもよい。新しいメッセージがストップ・メッセージ（又は、特定の実施形態では、ハートビート・メッセージ）である場合、シーケンス番号がメッセージ・シーケンス内の送信された最後のデータ・メッセージのシーケンス番号であると決定されてもよい。

【0109】

ブロック４０４で、新しいメッセージがデータ・メッセージである場合、制御は、ブロック４０５に進む。新しいメッセージがストップ・メッセージである場合、制御は、ブロック４０６に進む。

【0110】

ブロック４０５で、新しいメッセージ（データ・メッセージ）が送信され、制御は、ブロック４０１に戻る。

【0111】

ハートビート・メッセージを組み込んだ特定の実施形態では、ブロック４０４から、制御がブロックを通過し、新しいハートビート・メッセージを送信し、制御がブロック４０１に戻る前に新しい次のハートビートタイムを決定する。

【0112】

ブロック４０６で、次のメッセージ（データ・メッセージ）が送信される。ブロック４０７で、上述したように、メッセージ・ストリーム・ステートがクリアされ、制御がブロック４０１に戻る。

【0113】

図５は、上記したフェーズ番号手法に基づくメッセージの受信方法５００のフロー図の例を示す。この例では、フェーズ番号がシーケンス番号と共に各メッセージと一緒に使用され、各メッセージ・ストリームは、異なるフェーズ番号を有している。例えば、各メッセージ・ストリームは、前回のメッセージ・ストリームのフェーズ番号より１つ大きいフェーズ番号を有していてもよい。別の例として、各メッセージ・ストリームは、受信者に予測不可能なフェーズ番号を有している可能性がある。また、この例では、各データ・メッセージは、異なるシーケンス番号を有している。例えば、各データ・メッセージは、前回のデータ・メッセージのシーケンス番号よりも１つ大きいシーケンス番号を有していてもよい。この例では、ハートビート・メッセージは使用されず、データ・メッセージが送信されていない初期の間隔の後のストップ・メッセージのみが使用される。特定の実施形態では、ハートビート・メッセージはまた、ストップ・メッセージが送信される前に送信されてもよい。また、上述したメッセージ・ストリーム・ステートをクリアする手法の実施形態もまた、組み込まれている。

【0114】

ブロック５０１で、メッセージが受信される。メッセージは、例えば、データ・メッセージ又はストップ・メッセージであってもよい。メッセージを予想時間間隔内に受信しない場合、ロスト・メッセージが報知されてもよい。例えば、予想時間間隔は、データ・メッセージと第１のハートビート・メッセージ（又はここではストップ・メッセージ）との間の初期の時間間隔に基づいてもよく、又は予想時間間隔は、１つのハートビート・メッセージ間の間隔に基づいてもよい。例えば、初期の時間間隔及び／又は２つのハートビート・メッセージ間の間隔は、一定時間又は２倍増加し、ネットワーク遅延の変動を許容し、予想時間間隔を決定してもよい。

【0115】

ブロック５０２で、受信されたメッセージの予想フェーズ番号を決定する。受信されたメッセージの予想フェーズ番号は、この例では、メッセージ・シーケンス内の前回受信されたメッセージのフェーズ番号と同じである。受信されたメッセージが、メッセージ・シーケンスの第１のメッセージ（前回のメッセージが受信されていないかどうか又は前回のメッセージがストップ・メッセージであるかどうかに基づいて決定されてもよい）である場合、予想フェーズ番号は、フェーズ番号が受信機によって予測可能であるか否かに基づいて決定されてもよい。フェーズ番号が受信機によって予測可能である場合、予想フェーズ番号は、所定の関数に基づいて決定することができる。例えば、予想フェーズ番号は、前回のメッセージ・シーケンスのフェーズ番号を増加する（又はこれが受信された第１のメッセージ・シーケンスである場合、“０”などの所定の値で開始する）ことによって、決定されてもよい。フェーズ番号が、受信機によって予測不可能である場合、メッセージ・シーケンス内の受信された第１のメッセージのフェーズ番号は、予想フェーズ番号として取得され、前回のメッセージ・シーケンスのフェーズ番号と異なることが予想される。

【0116】

ブロック５０３で、受信されたメッセージの予想シーケンス番号が決定される。受信されたメッセージがデータ・メッセージである場合、予想シーケンス番号が前回受信されたメッセージのシーケンス番号（又は前回のメッセージがこのメッセージ・シーケンス内で受信されなかった場合、所定の初期のシーケンス番号から）を増加することによって、決定されてもよい。例えば、シーケンス番号は、“０”から“１”に１増やしてもよい。受信されたメッセージがストップ・メッセージである場合、この例では、予想シーケンス番号は、前回受信されたメッセージのシーケンス番号と同じである。

【0117】

ブロック５０４で、受信されたメッセージのフェーズ番号がブロック５０２で決定された予想フェーズ番号と比較される。

【0118】

受信されたメッセージのフェーズ番号が予想フェーズ番号と等しくない場合（ブロック５０４で決定されたように）、ブロック５０５で、ロスト・メッセージが報知されてもよい。特定の実施形態では、ロスト・メッセージがデータ・メッセージである場合のみ、ロスト・メッセージが報知されてもよい。特定の実施形態では、システムは、メッセージが欠落していると決定し、欠落しているメッセージを受信するための時間待機してもよい。欠落しているメッセージが時間内に受信されない場合、システムは、ロストとして欠落しているメッセージを報知してもよい。

【0119】

受信されたメッセージのフェーズ番号が予想フェーズ番号と等しい場合（ブロック５０４で決定されるように）、ブロック５０６で、受信されたメッセージのシーケンス番号がブロック５０３で決定された予想シーケンス番号と比較される。

【0120】

受信されたメッセージのシーケンス番号が予想シーケンス番号と等しくない場合（ブロック５０６で決定されるように）、ブロック５０５で、ロスト・メッセージが上記したように報知されてもよい。

【0121】

受信されたメッセージのシーケンス番号が予想シーケンス番号と等しい場合（ブロック５０６で決定されるように）、ブロック５０７で、受信されたメッセージがデータ・メッセージである場合、制御はブロック５０８に進む。受信されたメッセージがストップ・メッセージである場合、制御はブロック５０９に進む。

【0122】

受信されたメッセージがデータ・メッセージである場合、ブロック５０８で、データ・メッセージが処理される。例えば、受信されたデータ・メッセージは、アプリケーションに渡されてもよい。その後、制御はブロック５０１に戻る。

【0123】

受信されたメッセージがストップ・メッセージである場合、ブロック５０９で、メッセージ・ストリーム・ステートが上述したようにクリアされ、制御がブロック５０１に戻る。

【0124】

ハートビート・メッセージが組み込まれた特定の実施形態では、ブロック５０７から、制御はブロックに渡り、次の予想ハートビートタイムを更新し、制御が５０１に戻る。

【0125】

ＩＶ．送信デバイス及び受信デバイスの例
図６は、送信デバイス６００の例のブロック図を示す。送信デバイス６００は、上述した手法を別々に及び組み合わせて実装されている。送信デバイス６００は、メッセージ送信機６０１、メッセージ識別器６０２、フェーズ番号生成器６０３、シーケンス番号生成器６０４、及びメッセージ・ストリーム・ステート・クリヤラ６０５を含む。

【0126】

特定の実施形態では、上述した手法のサブセット（及び／又は組み合わせのサブセット）のみが実装されてもよい。例えば、フェーズ番号手法を提供しない送信デバイスは、フェーズ番号生成器６０３を含まなくてもよい。

【0127】

メッセージ送信機６０１がメッセージを送信する。例えば、メッセージ送信機６０１がデータ・メッセージ、ハートビート・メッセージ、及びストップ・メッセージを送信してもよい。利用される特定の手法に応じて、いくつかのメッセージタイプが送信されない場合がある。例えば、ストップ・メッセージのみを用いたフェーズ番号手法を利用する場合、ハートビート・メッセージは、送信されない。別の例として、フェーズ番号手法が増大間隔手法を用いたハートビート及びストップ・メッセージを利用し、それによってデータ・メッセージ、ハートビート・メッセージ、及びストップ・メッセージが送信されてもよい。また、特定の手法が利用されることに応じて、メッセージは、シーケンス番号、又はフェーズ番号とシーケンス番号の両方を含んでもよい。例えば、送信されたメッセージが増大間隔手法を用いたハートビートを利用し、フェーズ番号を含まなくてもよい。別の例として、送信されたメッセージがフェーズ番号手法を利用し、フェーズ番号とシーケンス番号の両方を含んでいてもよい。

【0128】

メッセージ送信機６０１は、データを受信し、アプリケーションからデータ・メッセージを送信してもよい。メッセージ送信機６０１は、次のハートビートタイムを追跡してもよく、ハートビート・メッセージ及び／又はストップ・メッセージが、利用される特定の手法に基づいて、適切な間隔で送信されてもよい。

【0129】

特定の実施形態では、別のメッセージ送信機が利用され、別のメッセージタイプを送信してもよい。

【0130】

メッセージ識別器６０２は、送信されたメッセージのタイプを識別する。例えば、メッセージ識別器６０２は、データ・メッセージ、ハートビート・メッセージ、又はストップ・メッセージとして送信されるメッセージを識別してもよい。

【0131】

フェーズ番号生成器６０３は、送信されるべきメッセージのフェーズ番号を決定し、提供する。フェーズ番号は、メッセージ送信機６０１に提供され、送信されるべきメッセージにはフェーズ番号が含まれる。フェーズ番号は、上述されたように決定されてもよい。送信されるべきメッセージがメッセージ・シーケンス内の第１のメッセージであるとき、例えば、前回のメッセージ・シーケンスのフェーズ番号を増加させる（又はこれ送信された第１のメッセージ・シーケンスである場合、“０”などの所定の値で開始する）、又はグローバル値又は関数から新しいフェーズ番号を取得することによって、フェーズ番号が取得されてもよい。送信されるべきメッセージがメッセージ・シーケンス内の第１のメッセージではない場合、フェーズ番号は、送信された最後のメッセージのフェーズ番号であると決定されてもよい。

【0132】

シーケンス番号生成器６０４は、送信されるべきメッセージのシーケンス番号を決定し、提供する。シーケンス番号は、送信されるべきメッセージのタイプに基づいて決定されてもよい。シーケンス番号は、上述したように決定されてもよい。いくつかの実施形態では、ハートビート・メッセージ及び／又はストップ・メッセージのシーケンス番号は、送信された最後のデータ・メッセージのシーケンス番号と同じである。いくつかの実施形態では、ハートビート・メッセージ及び／又はストップ・メッセージのシーケンス番号は、最後のメッセージがデータ・メッセージであるかハートビート・メッセージであるかで、送信された最後のメッセージのシーケンス番号から増加される。いくつかの実施形態では、新しいメッセージ・シーケンスの第１のメッセージのために、シーケンス番号が所定の値にリセットされる。

【0133】

メッセージ・ストリーム・ステート・クリヤラ６０５は、上述したようにストップ・メッセージが送信された後、メッセージ・ストリームをクリアする。

【0134】

図７は、受信デバイス７００の例のブロック図を示す。受信デバイス７００は、上述した手法を別々に及び組み合わせて実装している。受信デバイス７００は、メッセージ受信機７０１、メッセージ識別器７０２、フェーズ番号比較器７０５、シーケンス番号比較器７０６、ロスト・メッセージ報知機７０７、メッセージ・プロセッサ７０８、及びメッセージ・ストリーム・ステート・クリヤラ７０９を含む。

【0135】

特定の実施形態では、上述した手法のサブセットのみ（及び／又は組み合わせのサブセット）が実装されてもよい。例えば、フェーズ番号手法を提供しない受信デバイスは、予想フェーズ番号生成器７０３及び／又はフェーズ番号比較器７０５を含まなくてもよい。

【0136】

メッセージ受信機７０１は、メッセージを受信する。例えば、メッセージ受信機７０１は、データ・メッセージ、ハートビート・メッセージ、及びストップ・メッセージを受信してもよい。利用される特定の手法に応じて、いくつかのメッセージタイプが受信されなくてもよい。例えば、フェーズ番号手法は、ストップ・メッセージのみを利用し、ハートビート・メッセージを受信しない。別の例として、フェーズ番号手法は、増大間隔手法とストップ・メッセージ手法を用いたハートビートを利用してもよく、そしてデータ・メッセージ、ハートビート・メッセージ、及びストップ・メッセージを受信してもよい。また、利用される特定の手法に応じて、メッセージは、シーケンス番号又は、フェーズ番号とシーケンス番号の両方を含んでもよい。例えば、受信されたメッセージは、増大間隔手法を用いたハートビートを利用し、フェーズ番号を含まなくてもよい。別の例として、受信されたメッセージは、フェーズ番号手法を利用し、フェーズ番号とシーケンス番号の両方を含んでもよい。

【0137】

メッセージ受信機７０１は、次の予想ハートビートタイムを追跡し、予想時間間隔内に受信された場合、ロストとしてハートビート・メッセージ及び／又はストップ・メッセージが検出されてもよい。例えば、予想時間間隔は、データ・メッセージと第１のハートビート・メッセージとの間の初期の時間間隔に基づいてもよく、又は予想時間間隔は、２つのハートビート・メッセージ間の間隔に基づいてもよい。例えば、初期の時間間隔及び／又は２つのハートビート・メッセージ間の間隔は、一定時間又は２倍増加し、ネットワーク遅延の変動を許容し、予想時間間隔を決定してもよい。

【0138】

特定の実施形態では、別のメッセージ受信機が利用され、別のメッセージタイプを受信してもよい。

【0139】

メッセージ識別器７０２は、受信されたメッセージのタイプを識別する。例えば、メッセージ識別器７０２は、受信されたメッセージをデータ・メッセージ、ハートビート・メッセージ、又はストップ・メッセージであることを識別してもよい。

【0140】

予想フェーズ番号生成器７０３は、受信されたメッセージの予想フェーズ番号を決定し、提供する。フェーズ番号は、上述したように決定されてもよい。受信されたメッセージの予想フェーズ番号は、メッセージ・シーケンス内の前回受信されたメッセージのフェーズ番号と同じである、受信されたメッセージがメッセージ・シーケンスの第１のメッセージである（受信されたメッセージがないか、前回のメッセージがストップ・メッセージであるかどうかに基づいて決定され得る）場合、予想フェーズ番号は、受信機によってフェーズ番号が予測可能であるか否かに基づいて決定される。フェーズ番号が、受信機によって予測可能である場合、予想フェーズ番号は、所定の関数に基づいて決定されてもよい。例えば、予想フェーズ番号が、前回のメッセージ・シーケンスのフェーズ番号を増加する（又はこれが受信された第１のメッセージ・シーケンスの場合、“０”などの所定の値で開始する）ことによって決定されてもよい。フェーズ番号が受信機によって予測不可能である場合、メッセージ・シーケンス内の受信された第１のメッセージのフェーズ番号が予想フェーズ番号として取得され、前回のメッセージ・シーケンスのフェーズ番号と異なることが予想される。

【0141】

予想シーケンス番号生成器７０４は、受信されたメッセージの予想シーケンス番号を決定し、提供する。予想シーケンス番号は、受信されたメッセージのタイプに基づいて決定されてもよい。予想シーケンス番号は、上述されたように決定されてもよい。いくつかの実施形態では、ハートビート・メッセージ及び／又はストップ・メッセージの予想シーケンス番号は、受信された最後のデータ・メッセージのシーケンス番号と同じである。いくつかの実施形態では、ハートビート・メッセージ及び／又はストップ・メッセージの予想シーケンス番号は、受信された最後のデータ・メッセージのシーケンス番号から増えている。いくつかの実施形態では、新しいメッセージ・シーケンスの第１のメッセージのために、予想シーケンス番号が所定の値にリセットされる。

【0142】

フェーズ番号比較器７０５は、受信されたメッセージのフェーズ番号が、予想フェーズ番号生成器７０３によって提供された予想フェーズ番号と等しいかどうかを決定する。等しくない場合、ロスト・メッセージ報知機７０７が使用され、ロスト・メッセージが報知される。

【0143】

シーケンス番号比較器７０６は、受信されたメッセージのシーケンス番号が予想シーケンス番号生成器７０４によって提供された予想シーケンス番号と等しいかどうかを決定する。等しくない場合、ロスト・メッセージ報知機７０７が使用され、ロスト・メッセージが報知される。

【0144】

ロスト・メッセージ報知機７０７は、ロスト・メッセージを報知する。特定の実施形態では、ロスト・メッセージがデータ・メッセージである場合のみロスト・メッセージが報知されてもよい。特定の実施形態では、メッセージ受信機７０１は、メッセージが欠落していることを決定し、欠落しているメッセージを受信する時間待機する。欠落しているメッセージが時間内に受信されない場合、メッセージ受信機７０１は、その後、ロスト・メッセージ報知機７０７を使用し、ロストとして欠落しているメッセージを報知する。

【0145】

メッセージ・プロセッサ７０８は、受信されたメッセージを処理する。例えば、受信されたデータ・メッセージは、アプリケーションに渡されてもよい。

【0146】

メッセージ・ストリーム・ステート・クリヤラ７０９は、ストップ・メッセージが受信された後、上述したようにメッセージ・ストリーム・ステートをクリアする。

【0147】

Ｖ．電子商取引システムの例
以上の説明から明らかなように、実施の形態は、データが接続されたデバイスによって送信される、及び、から受信されるネットワーク化された環境に適用される。そのような環境の例は、電子取引システムであり、電子取引所は市場データに関連するメッセージを取引デバイスに送信する。市場データは、例えば、価格データ、市場の深さデータ、最終取引量データ、及び／又は取引可能オブジェクトの市場に関連するいくつかのデータを含む。いくつかの電子取引システムでは、取引デバイスは、取引注文に関連するメッセージを電子取引所に送信する。取引注文を受信する際に、電子取引所は、取引注文を取引所注文ブックに入力し、取引注文の量と１つ以上の反対側の注文の量とをマッチさせるように試みる。特定の実施形態では、各注文は、その注文に関連するメッセージのために、関連付けられたメッセージ・ストリームを有していてもよい。

【0148】

いくつかの電子取引システムでは、メッセージは、まれに送信される可能性がある。メッセージは、例えば、注文などの監視されるオブジェクトに関連付けられてもよい。例えば、注文のステートについての情報は、その注文のステートに変化があるときのみ送信されてもよい。注文のステートの変化は、例えば、フィル、部分的なフィル、注文価格の変化、又はキャンセルされた注文を含んでいてもよい。注文が市場から離れて実行中である場合、そのステートが１時間以上にわたって変化しない可能性がある。いくつかの場合、注文は、トリガされた注文などの、市場内で現在実行されていない注文であってもよく、ステートは数時間又は数日にわたって変化しない場合がある。そのようなトリガされた注文は、例えば、ホールド注文、取り消すまで有効な注文（ｇｏｏｄ ｔｉｌｌ ｃａｎｃｅｌｅｄ ｏｒｄｅｒ）（“ＧＴＣ”）、期間指定注文(ｇｏｏｄ ｔｉｌｌ ｄａｔｅ ｏｒｄｅｒ)（“ＧＴＤ”）、リミット・イフ・タッチド・オーダー（ｌｉｍｉｔ−ｉｆ−ｔｏｕｃｈｅｄ ｏｒｄｅｒ）、マーケット・イフ・タッチド・オーダー（ｍａｒｋｅｔ−ｉｆ−ｔｏｕｃｈｅｄ ｏｒｄｅｒ）、リミット・オン・クローズ・オーダー（ｌｉｍｉｔ−ｏｎ−ｃｌｏｓｅ ｏｒｄｅｒ）、マーケット・オン・クローズ・オーダー（ｍａｒｋｅｔ−ｏｎ−ｃｌｏｓｅ ｏｒｄｅｒ）、リミット・オン・オープン・オーダー（ｌｉｍｉｔ−ｏｎ−ｏｐｅｎ ｏｒｄｅｒ）、及びマーケット・オン・オープン・オーダー（ｍａｒｋｅｔ−ｏｎ−ｏｐｅｎ ｏｒｄｅｒ）を含んでもよい。満たされた注文はまた、市場内では現在実行されていない。

【0149】

別の例として、例えば、サーバがアクセス可能であるかアクセス不可能であるか、及び取引所への接続がアクセス可能であるかアクセス不可能であるかなどのステート変化に関連するサーバについての情報が、まれに送信される場合がある。別の例として、ニュース・メッセージなどの注文に関連しないメッセージが、まれに送信される場合がある。別の例として、ファイル及び初期の注文ブックのダウンロードが、例えば、起動時及びロスト・メッセージが続いて検出されたときに、まれに行われる場合がある。シングルトレーダーは、大量の注文をする必要はないかもしれないが、注文ブックが複数のユーザによって共有されている場合、組み合わせで、大量の注文又は共有された注文ブックに関連するステートの他のタイプが、まれに情報を送信することがある。例えば、リスク管理などの管理者が、トレーダーごとに注文ブックにアクセスする可能性がある。別の例として、特定の会社ですべてのトレーダーは、取引所で、同じアカウントで取引することから、特定の会社ですべてのトレーダーが注文ブックを共有する可能性がある。注文ブックを提供する場合、注文ブックを共有している各受信者は、潜在的に注文ブックに関連したメッセージを受信してもよい。

【0150】

図８は、特定の実施形態で採用され得る電子取引システム８００のブロック図を示す。システム８００は、取引デバイス８１０、ゲートウェイ８２０、及び電子取引所８３０を含む。取引デバイス８１０は、ゲートウェイ８２０と通信する。ゲートウェイ８２０は、取引所８３０と通信する。

【0151】

本明細書で使用するように、語句“通信する”とは、直接通信及び１つ以上の中間構成要素を介しての間接通信を含んでもよい。

【0152】

操作中、取引デバイス８１０は、注文を送信し、取引所８３０で取引可能オブジェクトを買ってもよく、又は売ってもよい。例えば、ユーザは、取引デバイス８１０を利用し、注文を送信してもよい。注文は、ゲートウェイ８２０を通って取引所８３０に送信される。また、市場データは、取引所８３０からゲートウェイ８２０を通って取引デバイス８１０に送信される。ユーザはまた、取引デバイス８１０を利用し、この市場データを監視し、及び／又は決定をベースとし、市場データ上の取引可能オブジェクトの注文を送信してもよい。

【0153】

取引可能オブジェクトは、量及び／又は価格と共に取引できるものである。例えば、株、オプション、債券、先物、通貨、ワラント、ファンドデリバティブ、証券、商品、スワップ、金利商品、インデックスベースの製品、取引されるイベント、グッズ、及びコレクション、及び／又はこれらの組み合わせなどが、取引可能オブジェクトであってもよい。取引可能オブジェクトは、「リアル（ｒｅａｌ）」又は「合成（ｓｙｎｔｈｅｔｉｃ）」であってもよい。リアル取引可能オブジェクトは、取引所によってリストに記載された及び／又は管理された生産物を含む。合成取引可能オブジェクトは、ユーザによって定義された生産物を含む。例えば、合成取引可能オブジェクトは、取引デバイス８１０を利用するトレーダーによって作成されたリアル（又は他の合成）の生産物の組み合わせ、例えば、合成スプレッドなどを含んでもよい。合成取引オブジェクトに対応する及び／又は同様のリアル取引可能オブジェクトがあってもよい。

【0154】

取引デバイス８１０は、例えば、ハンドヘルドデバイス、ラップトップ、デスクトップコンピュータ、シングル又はマルチコアプロセッサを有するワークステーション、複数のプロセッサを有するサーバ、及び／又はコンピュータのクラスタを含んでいてもよい。例えば、単一のデバイスとして論理的に表されているが、取引デバイス８１０は、サーバと通信する取引端末を含んでいてもよく、取引端末とサーバは、一括して取引デバイスであってもよい。取引端末は、取引画面をユーザに提供してもよく、コマンドをサーバに送信し、さらに取引画面を介して、発注などのユーザの入力の処理を行ってもよい。

【0155】

取引デバイス８１０は、一般的に、ユーザによって、所有され、操作され、制御され、プログラムされ、構成され、又は他のものが使用される。本明細書で使用されるように、語句「ユーザ」は、限定されるものではないが、人（例えば、トレーダ）又は電子取引デバイス（例えば、アルゴリズム取引システム）を含んでもよい。１人以上のユーザは、例えば、所有権、操作、制御、プログラミング、構成、又は他の使用に関与してもよい。

【0156】

取引デバイス８１０は、１つ以上の取引アプリケーションを含んでいてもよい。取引アプリケーションは、例えば、取引ウィンドウ及びチャートウィンドウに市場データを配置し、表示することによって市場データを処理してもよい。市場データは、例えば、取引所８３０から受信してもよい。別の例として、市場データは、履歴データを提供する及び／又は実際の世界の取引を実現せずに取引をシミュレートするシミュレーション環境から受信されてもよい。処理は、例えば、ユーザの好みに基づいてもよい。取引アプリケーションが取引デバイス８１０のコンピュータデバイスの１つ以上にわたって分散されてもよい。例えば、取引アプリケーションの特定の構成要素が、取引ワークステーションで実行されてもよく、取引アプリケーションの他の構成要素が、ワークステーションと通信するサーバ上で実行されてもよい。

【0157】

取引デバイス８１０は、例えば、電子取引ワークステーション、ポータブル取引デバイス、“ブラックボックス”又は“グレーボックス”システムなどのアルゴリズム取引システム、組み込み取引システム、及び／又は自動取引ツールを含んでいてもよい。例えば、取引デバイス８１０は、イリノイ州のシカゴのトレーディング・テクノロジーズ・インターナショナル・インコーポレイテッドによって提供される電子取引プラットフォームである、Ｘ＿ＴＲＡＤＥＲ（登録商標）のコピーを実行するコンピュータシステムであってもよい。別の例として、取引デバイス８１０は、トレーディング・テクノロジーズ・インターナショナル・インコーポレイテッドによってまた提供されるＡｕｔｏｓｐｒｅａｄｅｒ（登録商標）及び／又はＡｕｔｏｔｒａｄｅｒ（商標）などの自動取引ツールを実行するコンピュータデバイスであってもよい。

【0158】

別の例として、取引デバイス８１０は、アルゴリズム的に市場データを処理し、アルゴリズムの処理に基づいて注文を手動で配置するためのユーザインタフェースを含み、発注された注文を自動的に操作する取引アプリケーションを含んでいてもよい。アルゴリズム取引アプリケーションは、特定の動作を行う自動処理アルゴリズムを含む取引アプリケーションである。即ち、取引アプリケーションは、例えば、定義された動作を実行する自動化された一連の命令を含む。動作は、特定の方法で市場データを処理すること、発注すること、既存の注文を変更すること、注文を削除すること、発注しないこと、どの取引可能オブジェクトが実行されるかを選択すること、発注又は注文変更の価格を決定すること、発注又は注文の量を決定すること、注文が買いか売りかを決定すること、ある時間動作を遅延させること、を含んでもよい。

【0159】

本明細書で使用されるように、アルゴリズム（取引アルゴリズムとも呼ばれている）は、取引に使用されるアルゴリズムを記述する論理式及びパラメータを含む定義によって特定される。論理式は、パラメータ間の関係を特定し、より多くのパラメータを生成してもよい。パラメータは、例えば、アルゴリズムの論理式への入力を含んでもよい。アルゴリズムの定義は、少なくとも一部では、アルゴリズム取引アプリケーションによって特定されてもよい。例えば、アルゴリズム取引アプリケーションは、ユーザにパラメータを特定させるのみを可能にし、所定の論理式によって使用されてもよい。別の例として、アルゴリズム取引アプリケーションは、ユーザに論理式のうちのいくつか又はすべて及びパラメータのうちのいくつか又はすべてを特定することを可能にしてもよい。論理式がユーザによって特定された取引アルゴリズムは、ユーザ定義の取引アルゴリズムである。

【0160】

取引アプリケーションは、取引デバイス８１０のコンピュータ読み取り可能な記録媒体に記憶されてもよい。特定の実施形態では、取引アプリケーションの１つ以上の構成要素が取引ワークステーションに記憶されてもよく、取引アプリケーションの他の構成要素がワークステーションと通信するサーバ上に記憶されてもよい。特定の実施形態では、取引アプリケーションの１つ以上の構成要素が別のコンピュータ読み取り可能な記録媒体から取引デバイス８１０のコンピュータ読み取り可能な記録媒体へロードされてもよい。例えば、取引アプリケーション（又は取引アプリケーションの更新）は、メーカー、開発者、又は１つ以上のＣＤ若しくはＤＶＤの発行者によって記憶されてもよく、その後アプリケーションを取引デバイス８１０上に、又は取引デバイス８１０が取引アプリケーションを取得するサーバに、アプリケーションをロードする責任のある者に提供される。別の例として、取引デバイス８１０は、例えば、インターネット又は内部ネットワークを介して、サーバから取引アプリケーション（又は取引アプリケーションの更新）を受信してもよい。取引デバイス８１０は、取引デバイス８１０によって要求されたとき（“プル配信”）、及び／又は取引デバイスによって要求されないとき（“プッシュ配信”）、取引アプリケーション又は更新を受信してもよい。

【0161】

取引デバイス８１０は、取引可能オブジェクトの注文を送信するように構成される。注文は、例えば、１つ以上のメッセージ若しくはデータパケットに、又は共有メモリシステムを通して送信される。取引デバイス８１０はまた、例えば、注文のキャンセル、注文の変更、及び／又は取引所への問合せをするように構成されてもよい。別の例として、取引デバイス８１０は、実際の世界の取引を実現しないシミュレーション環境にシミュレートされた取引所に注文を送信するように構成されてもよい。

【0162】

取引デバイス８１０によって送信された注文は、例えば、ユーザの要求又は自動的に送信されてもよい。例えば、トレーダーは、電子取引ワークステーションを利用し、特定の取引可能オブジェクトを発注し、注文価格及び／又は量などの注文のための１つ以上のパラメータを手動で提供する。別の例として、自動化された取引ツールが注文のための１つ以上のパラメータを計算し、注文を自動的に送信してもよい。いくつかの場合では、自動化された取引ツールは、送信されるべき注文を準備し、実際それをユーザからの確認することなしに送信することはない。

【0163】

特定の実施形態では、取引デバイス８１０は、ユーザインタフェースを含む。ユーザインタフェースは、取引アプリケーションのテキストベース及び／又はグラフィカルインタフェースを表す１つ以上のディスプレイデバイスを含んでいてもよい。例えば、ディスプレイデバイスは、コンピュータモニタ、ハンドヘルド・デバイス・ディスプレイ、プロジェクタ、及び／又はテレビを含んでいてもよい。ユーザインタフェースは、例えば、入力を受信するための１つ以上の入力デバイスを含んでもよい。例えば、入力デバイスは、キーボード、トラックボール、２つ又は３つのボタンマウス、及び／又はタッチスクリーンを含んでいてもよい。ユーザインタフェースは、ユーザと対話するための他のデバイスを含んでいてもよい。例えば、情報が音声でスピーカーを介してユーザに提供されてもよく、及び／又はマイクを介して受信されてもよい。

【0164】

特定の実施形態では、取引アプリケーションは、１つ以上の取引画面を含み、ユーザが１つ以上の市場と対話可能にしている。取引画面は、例えば、様々な取引戦略を実施しながら、ユーザが市場情報を取得し、かつ見て、注文エントリーパラメータをセットし、注文を入力及びキャンセルし、及び／又はポジションを監視することを可能にしてもよい。例えば、取引アプリケーションが、取引所８３０から情報（例えば、ビッド価格、ビッド量、アスク価格、アスク量、過去に売った価格及び量、及び／又は他の市場の関連情報など）を受信してもよく、それらのいくつか又はすべてが順番に取引デバイスのユーザインタフェースを用いて表示されてもよい。受信された情報に基づいて、取引画面は、価格レベルのレンジと、取引可能オブジェクトに関する価格レベルの対応するビッド及びアスク量と、を表示してもよい。関連取引情報をユーザに提供するために、取引画面は、内部市場の周囲に価格（と対応するビッド及びアスク量）のレンジを表示してもよい。情報は、連続的に又は定期的に取引アプリケーションに提供され、取引アプリケーションが現在の市場情報と共に取引画面を更新可能にしてもよい。ユーザは、例えば、取引画面を使用し、取引可能オブジェクトの買い及び売り注文を出し、又はそれ以外の場合、表示された情報に基づいて取引可能オブジェクトを取引してもよい。

【0165】

取引画面は、１つ以上の取引ツールを表示してもよい。取引ツールは、電子ツールであり、電子取引を可能にし、補助し、及び／又は容易にする。代表的な取引ツールは、限定されるものではないが、チャート、取引ラダー、注文入力ツール、自動化された取引ツール、自動化されたスプレッドツール、リスク管理ツール、注文パラメータツール、注文入力システム、市場グリッド、フィルウィンドウ、及び市場注文ウィンドウ、それらの組み合わせ、取引、取引の準備、取引の管理、又は市場の分析に使用される他の電子ツールを含んでいてもよい。

【0166】

特定の実施形態では、取引デバイス８１０からの注文は、ゲートウェイ８２０を通って取引所８３０に送信される。取引デバイス８１０は、例えば、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、無線ネットワーク、仮想プライベート・ネットワーク、Ｔ１ライン、Ｔ３回線、統合サービスデジタル網（“ＩＳＤＮ”）線、ポイント・オブ・プレゼンス（ＰＯＰ）、インターネット、及び／又は共有メモリシステムを使用してゲートウェイ８２０と通信することができる。

【0167】

ゲートウェイ８２０は、取引デバイス８１０及び取引所８３０と通信するように構成されている。ゲートウェイ８２０は、取引デバイス８１０と取引所８３０との間の通信を簡単にする。例えば、ゲートウェイ８２０は、取引デバイス８１０から注文を受信し、取引所８３０に注文を送信してもよい。別の例として、ゲートウェイ８２０は、取引所８３０から市場データを受信し、取引デバイス８１０に市場データを送信してもよい。

【0168】

特定の実施形態では、ゲートウェイ８２０は、取引デバイス８１０と取引所８３０との間で通信されたデータの処理を行う。例えば、ゲートウェイ８２０は、取引デバイス８１０から受信された注文を取引所８３０によって理解されるデータフォーマットに処理してもよい。同様に、ゲートウェイ８２０は、取引所８３０から受信された取引所の特有のフォーマットの市場データを、取引デバイスによって理解されるフォーマットに変換してもよい。ゲートウェイ８２０の処理はまた、例えば、取引デバイス８１０からの取引注文を追跡すること、及び取引所８３０から受信されたフィル確認に基づいて注文の状態を更新することを含んでもよい。別の例として、ゲートウェイ８２０は、取引所８３０からの市場データをまとめ、それを取引デバイス８１０に提供してもよい。

【0169】

特定の実施形態では、ゲートウェイ８２０は、取引デバイス８１０と取引所８３０との間で通信されるデータを処理する以外のサービスを提供する。例えば、ゲートウェイ８２０は、リスク処理を提供してもよい。

【0170】

ゲートウェイ８２０は、例えば、ハンドヘルドデバイス、ラップトップ、デスクトップコンピュータ、シングルコア又はマルチコアプロセッサを有するワークステーション、複数のプロセッサを有するサーバ、及び／又はコンピュータのクラスタなどの１つ以上のコンピュータプラットフォームを含んでいてもよい。

【0171】

ゲートウェイ８２０は、１つ以上のゲートウェイアプリケーションを含んでいてもよい。ゲートウェイアプリケーションは、例えば、注文処理及び市場データ処理を扱うことができる。この処理は、例えば、ユーザの好みに基づいてもよい。

【0172】

特定の実施形態では、ゲートウェイ８２０は、例えば、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、仮想プライベート・ネットワーク、Ｔ１ライン、Ｔ３回線、ＩＳＤＮ回線、ポイント・オブ・プレゼンス（ＰＯＰ）、インターネット、及び／又は共有メモリシステムを使用して取引所８３０と通信する。

【0173】

一般的に、取引所８３０は、取引所エンティティによって所有され、操作され、制御され、又は使用され得る。取引所エンティティの例は、ＣＭＥグループ、ロンドン国際金融先物取引所（“ＬＩＦＦＥ”）、インターコンチネンタル取引所（“ＩＣＥ”）、及びユーレックスを含む。取引所８３０は、例えば、取引所によって取引を申し込まれた、取引可能オブジェクトが売買されることを可能にするよう構成された、コンピュータ、サーバ、又は他のコンピュータデバイスなどの電子マッチングシステムを含んでいてもよい。電子マッチングシステムは、別のエンティティを含み、例えば、いくつかが取引可能オブジェクト及び注文を受信してマッチする他のものをリストにしてもよく、及び／又は管理してもよい。取引所８３０は、例えば、電子通信ネットワーク（“ＥＣＮ”）を含んでもよい。

【0174】

取引所は、取引可能オブジェクトを売買するために注文をマッチするよう構成されている。取引可能オブジェクトは、取引所８３０によって取引のためにリストにされてもよい。注文は、例えば、取引デバイス８１０から受信された注文を含んでもよい。注文は、例えば、ゲートウェイ８２０を通って取引デバイス８１０から受信されてもよい。また、注文は、取引所８３０と通信する他のデバイスから受信されてもよい。即ち、典型的に、取引所８３０は、マッチすべき注文も提供する（取引デバイス８１０と同様であり得る）様々な他の取引デバイスと通信する

【0175】

取引所８３０は、市場データを提供するよう構成されてもよい。市場データは、例えば、１つ以上のメッセージ若しくはデータパケットに、又は共有メモリシステムを通って提供されてもよい。市場データは、例えば、取引デバイス８１０に提供されてもよい。市場データは、例えば、取引デバイス８１０にゲートウェイ８２０を通って提供されてもよい。市場データは、例えば、内部市場を示すデータを含んでもよい。市場データは、（内部市場が時間と共に変化するので）特定の時点での最低の売り価格（“ベストアスク”とも呼ばれる）と最高の買い価格（“ベストビッド”とも呼ばれる）である。市場データは、市場の深さを含んでいてもよい。市場の深さは、内部市場で入手可能な量を示しており、また内部市場から離れた他の価格で入手可能な量を示している。したがって、内部市場は、市場の深さの第１のレベルと見なすことができる。内部市場から離れた１つのティックは、例えば、内部市場の第２のレベルと見なしてもよい。特定の実施形態では、市場の深さは、全ての価格レベルに提供されている。特定の実施形態では、市場の深さは、全ての価格レベルより少なく提供されている。例えば、市場の深さは、内部市場の両側の最初の５つの価格レベルのみに提供されてもよい。別の例として、市場の深さは、市場内で入手可能な量である最初の１０個の価格レベルに提供されてもよい。市場データはまた、最終取引価格（ＬＴＰ）、最終取引量（ＬＴＱ）、及び注文フィル情報などの情報を含んでいてもよい。

【0176】

特定の実施形態では、システム８００は、複数の取引デバイス８１０を含んでいる。例えば、上述の取引デバイス８１０と同様の複数の取引デバイスは、ゲートウェイ８２０と通信し、注文を取引所８３０に送信してもよい。

【0177】

特定の実施形態では、システム８００は、複数のゲートウェイ８２０を含んでいる。例えば、上述のゲートウェイ８２０と同様の複数のゲートウェイは、取引デバイス８１０及び取引所８３０と通信してもよい。そのような構成は、例えば、１つのゲートウェイに障害が発生した場合に、冗長性を提供するために使用され得る。

【0178】

特定の実施形態では、システム８００は、複数の取引所８３０を含んでいる。例えば、ゲートウェイ８２０は、上述の取引所８３０と同様の複数の取引所と通信してもよい。そのような構成は、例えば、取引デバイス８１０が、ゲートウェイ８２０を通して複数の取引所で取引可能にすることができる。

【0179】

特定の実施形態では、システム８００は、複数の取引所８３０と複数のゲートウェイ８２０とを含んでいる。例えば、ゲートウェイ８２０と同様の複数のゲートウェイは、上述の取引所８３０と同様の複数の取引所と通信してもよい。各ゲートウェイは、例えば、１つ以上の別の取引所と通信してもよい。そのような構成は、例えば、１つ以上の取引デバイス８１０が複数の取引所で取引可能にすること（及び／又は複数の取引所への接続の冗長性を提供すること）ができる。

【0180】

特定の実施形態では、取引デバイス８１０は、１つ以上のコンピュータデバイス又は処理コンポーネントを含んでいる。言い換えれば、取引デバイス８１０の機能は、複数のコンピュータデバイスによって実行されてもよい。例えば、１つのコンピュータデバイスが、取引所８３０に送信されるべき注文を生成してもよく、一方で別のコンピュータデバイスがユーザにグラフィカル・ユーザ・インタフェースを提供してもよい。特定の実施形態では、ゲートウェイ８２０は、１つ以上のコンピュータデバイス又は処理コンポーネントを含んでいる、言い換えれば、ゲートウェイ８２０の機能は、複数のコンピュータデバイスによって実行されてもよい。特定の実施形態では、取引所８３０は、１つ以上のコンピュータデバイス又は処理コンポーネントを含んでいる。言い換えれば、取引所８３０の機能は、複数のコンピュータデバイスによって実行されてもよい。

【0181】

特定の実施形態では、ゲートウェイ８２０は、取引デバイス８１０の一部である。例えば、ゲートウェイ８２０のコンポーネントは、取引デバイス８１０と同じコンピュータプラットフォームの一部であってもよい。別の例として、ゲートウェイ８２０の機能は、取引デバイス８１０のコンポーネントによって実行されてもよい。特定の実施形態では、ゲートウェイ８２０は存在しない。例えば、取引デバイス８１０が、取引所８３０と通信するために、ゲートウェイ８２０を利用する必要がない場合に、そのような構成にしてもよい。例えば、取引デバイス８１０が、取引所８３０と直接通信するように構成されている場合である。

【0182】

特定の実施形態では、ゲートウェイ８２０は、取引デバイス８１０と同じ側に物理的に配置されている。特定の実施形態では、ゲートウェイ８２０は、取引所８３０と同じ側に物理的に配置されている。特定の実施形態では、取引デバイス８１０は、取引所８３０と同じ側に物理的に配置されている。特定の実施形態では、ゲートウェイ８２０は、取引デバイス８１０と取引所８３０との両方と別の側に物理的に配置されている。

【0183】

特定の実施形態では、システム８００は、ミドルウェア、ファイアーウォール、ハブ、スイッチ、ルータ、取引所特有の通信設備、モデム、セキュリティ管理、及び／又は暗号化／復号化デバイスなどの通信アーキテクチャに固有の他のデバイスを含んでもよい。

【0184】

図９は、図８の電子取引システム８００の実施例９００を示す。システム９００は、取引デバイス８１０ａ−８１０ｅ、ゲートウェイ８２０、取引所８３０、第１のＷＡＮルータ９４０、第２のＷＡＮルータ９５０、及びＷＡＮリンク９６０を含んでいる。取引デバイス８１０ａと８１０ｂは、ゲートウェイ８２０と通信している。ゲートウェイ８２０は、取引所８３０と通信している。取引デバイス８１０ｃ−８１０ｅは、ＷＡＮルータ９４０とＷＡＮルータ９５０とを使用してゲートウェイ８２０と通信する。

【0185】

操作中、取引デバイス８１０ａ−８１０ｅは、注文を送信し、取引所８３０で取引可能オブジェクトを買ってもよく、又は売ってもよい。例えば、ユーザは、取引デバイス８１０ａ−８１０ｅを利用し、注文を送信してもよい。注文は、取引デバイス８１０ａと８１０ｂから、ゲートウェイ８２０を通って、取引所８３０に送信される。注文は、取引デバイス８１０ｃ−８１０ｅから、ＷＡＮルータ９５０と９４０を通って、ゲートウェイ８２０に送信され、ゲートウェイ８２０を通って、取引所８３０に送信される。また、市場データは、取引所８３０からゲートウェイ８２０を通って取引デバイス８１０ａと８１０ｂとＷＡＮルータ９４０とに送信される。市場データは、ＷＡＮルータ９４０からＷＡＮルータ９５０に送信され、その後ＷＡＮルータ９５０から取引デバイス８１０ｃ−８１０ｅに送信される。

【0186】

電子取引システム８００の実施例９００では、例えば、ＷＡＮルータ９４０でメッセージ遅延及び／又はロスが生じる可能性がある。メッセージ遅延及び／又はロスは、例えば、ＷＡＮルータ９４０のメッセージのドロップに起因する、又はＷＡＮルータ９４０、ＷＡＮルータ９５０、及び／又はＷＡＮリンク９６０の障害に起因する可能性がある。例えば、ＷＡＮルータ９４０は、メモリ又は処理容量を使い果たすなどのリソースの制限に起因して、及び／又はＷＡＮリンク９６０経由でメッセージを送信することの遅延によって、メッセージをドロップする可能性がある。別の例として、ＷＡＮルータ９４０及び／又はＷＡＮルータ９５０は、電力損失又はハードウェアの障害に起因して失敗することがある。別の例として、ＷＡＮリンク９６０は、ケーブル切断又はハードウェア障害によって失敗することがある。

【0187】

上述した様々な手法及び実施形態は、電子取引システムに採用され得る。例えば、図８の電子取引システム８００の例は、図２Ｃに関連して記載された例示の方法を実施できる。例示の方法は、図８のゲートウェイ８２０から取引デバイス８１０に送信されるメッセージに、シーケンス番号を関連付ける。例示の方法によってシーケンス番号をデータ及びハートビート・メッセージに関連付けることは、図８の取引デバイス８１０が、データ・メッセージが失われて、次のメッセージが受信されるまでの時間内にロスト・メッセージを検出可能にする。

【0188】

別の例として、図８の電子取引システムの例は、図２Ｄに関連して記載された例示の方法を実施してもよい。図８の取引デバイス８１０は、ゲートウェイ８２０からメッセージを受信する。取引デバイス８１０は、ゲートウェイ８２０から送信されるべきメッセージの予想シーケンス番号を決定する。取引デバイス８１０は、受信されたメッセージのシーケンス番号を予想シーケンス番号と比較し、データ・メッセージが失われたかどうかを決定する。

【0189】

別の例として、図８の電子取引システム８００の例は、図４に関連して記載された例示の方法を実施してもよい。例示の方法は、図８のゲートウェイ８２０によって取引デバイス８１０に送信されるメッセージにシーケンス番号及びフェーズ番号を関連付ける。例示の方法によって、シーケンス番号及びフェーズ番号をメッセージ・シーケンスに関連付けることは、図８の取引デバイス８１０が、ロスト・メッセージ・シーケンスを検出可能にする。さらに、例示の方法は、ゲートウェイ８２０が、メッセージ・シーケンスを完全に送信した後、メッセージ・ストリーム・ステートをクリアすることを可能にする。

【0190】

別の例として、図８の電子取引システム８００の例は、図５に関連して記載された例示の方法を実施してもよい。図８の取引デバイス８１０は、ゲートウェイ８２０からメッセージを受信する。取引デバイス８１０は、ゲートウェイ８２０から受信されたメッセージのフェーズ番号及びシーケンス番号をそれぞれ、予想フェーズ番号及びシーケンス番号と比較し、メッセージが失われたかどうかを決定する。また、例示の方法は、取引デバイス８１０が、メッセージ・シーケンスを完全に受信した後、メッセージ・ストリーム・ステートをクリアすることを可能にする。

【0191】

説明された図のいくつかは、例示のブロック図、システム、及び／又は特定の実施形態のすべて又は一部を実施するために使用され得る方法を示したフロー図が図示されている。構成要素、要素、ブロックのうちの１つ以上、及び／又は例示のブロック図、システムの機能、及び／又はフロー図は、例えば、単独、又は有形のコンピュータ読み取り可能な記録媒体上に記憶された一連のコンピュータ読み取り可能な命令として、ハードウェア、ファームウェア、個別論理の組み合わせ、及び／又はそれらのいくつかの組み合わせを実施してもよい。

【0192】

例示のブロック図、システム、及び／又はフロー図は、例えば、特定用途向け集積回路（ＡＳＩＣ）、プログラム可能論理デバイス（ＰＬＤ）、フィールド・プログラマブル・ロジック・デバイス（ＦＰＬＤ）、離散論理、ハードウェア、及び／又はファームウェアのいくつかの組み合わせを使用して実施することができる。

【0193】

例示のブロック図、システム、及び／又はフロー図は、例えば、１つ以上のプロセッサ、コントローラ、及び／又は他の処理デバイスを使用して実行することができる。例えば、それらの例は、例えば、有形のコンピュータ読み取り可能な記録媒体に記憶されたコンピュータ読み取り可能な命令などのコード化された命令を使用して実行されてもよい。有形のコンピュータ読み取り可能な記録媒体は、様々なタイプの揮発性及び不揮発性記録メディアを含んでもよく、例えば、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリー・メモリ（ＲＯＭ）、プログラマブル・リード・オンリー・メモリ（ＰＲＯＭ）、電気的プログラマブル・リード・オンリー・メモリ（ＰＲＯＭ）、電気的に消去可能なリード・オンリー・メモリ（ＥＰＲＯＭ）、フラッシュメモリ、ハードディスクドライブ、光学メディア、磁気テープ、ファイルサーバ、いくつかの他の有形データ記憶デバイス、又はそれらのいくつかの組み合わせを含んでもよい。有形のコンピュータ読み取り可能な記録媒体は、非一時的である。

【0194】

さらに、例示のブロック図、システム、及び／又はフロー図は、図に関連して上記されており、他の実施形態を採用してもよい。例えば、コンポーネント、要素、ブロック、及び／又は機能の実行の順番は、変更されてもよく、上記したコンポーネント、要素、ブロック、及び／又は機能は、変更、削除、細分化、又は組み合わせてもよい。また、コンポーネント、要素、ブロック、及び／又は機能のいくつか又はすべては、例えば、別の処理スレッド、プロセッサ、デバイス、個別論理、及び／又は回路によって、連続して及び／又は並行して行われてもよい。

【0195】

実施の形態が開示されているが、様々な変更を行ってもよく、同等のものに置換されてもよい。さらに、特定の状況又は材料に適合させるように、多くの修正が行われてもよい。したがって、開示された技術は、開示された特定の実施形態に限定されないが、添付の特許請求の範囲内にすべての実施形態を包含することを意図している。

【図1】

【図2A】

【図2B】

【図2C】

【図2D】

【図3A】

【図3B】

【図3C】

【図3D】

【図3E】

【図3F】

【図3G】

【図3H】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】