JP2009524892A - 検索可能旅行データの集約システムの方法、システムおよび装置 - Google Patents

Abstract

このシステムは、チャーターデータオブジェクトを能動的に入手し、または受動的に受け取るように構成することができる。データオブジェクトには、使用可能なチャーター機器（たとえば飛行機）、可用性位置、および／または時間情報などの情報を含めることができる。このシステムは、さまざまなデータソースからのさまざまなオブジェクトフォーマットのいずれかを処理するように構成することができる。このシステムは、チャーターフライトデータインジケータおよび対応するフライト特性を抽出して、チャーターフライトデータレコードを作成し、投入し、これらのデータレコードは、チャーターデータ管理システムコンポーネントの基礎として働く。このシステムは、最良一致または代替の提案される結果と共にチャーターフライトデータレコードを識別する検索機能性を実施する。標準化された形または標準化されていない形の情報で公表され／配布されるチャーターフライトレコードは、複数のソースから発する。このシステムは、クライアントから使用可能フライト要求を受け入れ、ユーザに自動的に警告する（すなわち、販売代理人を介して間接的にまたは見込み客もしくは顧客に直接に）。

Description

本発明は、全般的にはチャーターデータ集約および管理を容易にする装置、方法、およびシステムに関し、より具体的には、チャーターデータ要素を受け取り／入手し、その要素を処理し、処理されたチャーターデータのシステムユーザ検索を容易にする装置、方法、およびシステムに関する。

従来、チャーターエアラインフライトオペレータ（ｃｈａｒｔｅｒ ａｉｒｌｉｎｅ ｆｌｉｇｈｔ ｏｐｅｒａｔｏｒ）などのチャーター旅行プロバイダは、機器可用性および料金の情報を公表し、配布してきた。このタイプの情報は、さまざまな標準化されたフォーマットまたは標準化されていないフォーマットで公表され、かつ／または配布される。さまざまなタイプの可用性データを集約し、そのデータを処理し、簡単に管理されるフォーマットで提示する方法、システム、および装置を提供することへのかなりの必要がある。さらに、処理されたデータを扱う便利で効果的なインターフェースをシステムユーザに与える必要がある。

本発明は、全般的にはチャーターデータ集約および管理を容易にする装置、方法、およびシステムを提供し、より具体的には、チャーターデータ要素を受け取り／入手し、その要素を処理し、処理されたチャーターデータのシステムユーザ検索を容易にする装置、方法、およびシステムを提供することを目的とする。

この開示では、旅行集約システムに関連する装置、方法、およびシステムの実施態様を詳細に述べる。一実施態様で、このシステムは、旅行可用性情報を集約すると同時に、システムユーザからの旅行検索要求を処理するように構成される。このシステムは、両方のエンティティすなわち旅行データを配布する一連の旅行プロバイダおよび旅行可用性要求をサブミットするシステムユーザからの処理されたデータを調整するように構成された媒介物として構成される。

このシステムは、ある種のデータオブジェクトを能動的に入手し、または受動的に受け取るように構成することができる。これらのデータオブジェクトは、チャーターフライト可用性など、サービスに関する可用性情報を含むように構成することができる。データオブジェクトには、使用可能な機器（たとえば飛行機）、可用性位置、および／または時間情報などの情報を含めることができる。このシステムは、システムに登録されたチャーターデータソースまたは登録されていないソースのいずれかからの構造化された／構造化されていないデータオブジェクトを処理するように構成することができる。

チャーターフライトシステム構成では、このシステムは、データオブジェクトからチャーターフライトデータ特性を抽出し、そのデータを使用して、チャーターフライトデータレコードを作成し、投入する。これらのデータレコードは、チャーターデータ集約管理システムコンポーネントの下にある基礎として働く。データ管理コンポーネントの一態様は、片道航程として構成できる使用可能なチャーターフライトを検索エンジンが見つけるのを容易にすることを含む。往復旅行または出発地と目的地との間に１つまたは複数の着陸を有する飛行は、一連の片道航程として表すことができる。

このシステムは、最初の一致または代替結果を提供するチャーターフライトデータレコードを識別するために検索エンジン機能性を実施するように構成することができる（代替使用可能フライト、要求されたチャーターフライト判断基準に最もよく一致する使用可能なチャーターフライト）。標準化された形または標準化されていない形で公表され／配布されるチャーターフライトレコードは、複数のソースから発する。このシステムは、標準化されていないデータ抽出の自動化されたデータ抽出ツールにおける信頼度を示すために、ソース信頼度／正確度スコアをも投入される。このシステムは、クライアント（または、このシステムがユーザのコミュニティ用のサービスとして実施される場合には、参加者／コミュニティメンバ）から使用可能フライト要求を受け入れ、格納し、ユーザに自動的に警告する（すなわち、販売代理人を介して間接的にまたは見込み客もしくは顧客に直接に）。このシステムは、アプリケーションプログラミングインターフェースを介して、検索結果を開始し、スケジュールを追加し、連絡先を取り出し、このシステムの他のファシリティと通信するために、既存ソフトウェアアプリケーションに簡単に統合することができる。

添付図面は、本開示によるさまざまな非限定的な例の発明的態様を示す。

図面内の各符号の先頭の数は、その符号が導入され、かつ／または詳細に示される図面を示す。したがって、符号１０１は、図１で最初に導入される。符号２０１は、図２で導入されるなどである。

優先権
本願は、米国特許法第１１９（ｅ）条の下で、２００６年１月２５日に出願した米国特許仮出願第６０／７６２，２８１号、名称「Ｍｅｔｈｏｄ，Ｓｙｓｔｅｍ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ａｇｇｒｅｇａｔｉｏｎ Ｓｙｓｔｅｍ ｆｏｒ Ｓｅａｒｃｈａｂｌｅ Ｔｒａｖｅｌ Ｄａｔａ」の優先権を主張するものである。

このシステムは、旅行プロバイダなどのさまざまなソースからの可用性および料金情報を含むチャーターデータオブジェクトを受け取り／入手し、処理することを容易にする。例示のみのために、次の図面で、本発明をエアラインの文脈で、より具体的にはチャーターフライトデータ集約および処理システムとして述べる。しかし、本明細書で説明するシステム、方法、および装置を、さまざまな旅行プロバイダおよび顧客に関連する任意の個数の異なるタイプのデータの集約および処理を容易にするために適合させることができることを理解されたい。さらに、このシステムの多くの態様を、エアラインチャーターフライトの文脈で述べるが、このシステムを、本明細書で述べるチャーターフライトデータ実施態様を超えるさまざまなシステムユーザの必要に合わせて構成できることを理解されたい。たとえば、このシステムを、追加のタイプの旅行、貨物輸送／出荷、不動産、および異なるタイプのデータの管理を容易にする任意の個数の他の実施態様を容易にするように構成することができる。

図１に、チャーターデータ集約および処理システムすなわち旅行集約システム（「ＴＡＳ」）として実施されたシステム構成を示す。図１は、１次ＴＡＳユーザインターフェース１００を含むＴＡＳならびに基礎になるＴＡＳシステムデータベースを示す。以下でより詳細に述べるように、システムユーザ１２０は、ＴＡＳを使用して、チャーターフライト判断基準を詳細に示すユーザ定義の検索要求に関する使用可能なチャーターフライト（「一航程」）を見つけることができる。ＴＡＳシステムは、実施態様に依存するさまざまなソース１３０から発するものとすることができる使用可能チャーターフライトレコードをＴＡＳシステムデータベースから検索する。

このシステムの旅行情報データベースは、電子メールリストサーバまたはスキャンされた広告から抽出されたデータなど、構造化されていない（標準化されていない）ソースからデータを受け取る。システムユーザ１２０は、個人でまたはシステム管理者１４０の助けを得てＴＡＳインターフェースをナビゲートすることができる。システム管理者は、さまざまなチャーターデータソースを処理して、チャーターデータオブジェクトの受け取り／入手を調整することもできる。さらに、システム管理者は、ＴＡＳデータオブジェクト処理モジュールに関連するデータ抽出ルールを調整する責任をも負う。

システム１００は、システムユーザ１２０から使用可能フライト要求を受け入れ、格納し、いくつかの実施形態では、特定の検索要求に関して最初の一致よりよい一致を提供する追加フライトレコードに関してユーザに自動的に警告するように構成され得る。システム１００は、アプリケーションプログラミングインターフェース（ＡＰＩ）を介して、検索結果を開始し、スケジュールを追加し、連絡先を取り出し、このシステムの他のファシリティと通信するために、既存ソフトウェアアプリケーションに簡単に統合することができる。

図１に示されているように、旅行集約システム（「ＴＡＳ」）１００は、旅行情報データベースを構築するために、標準化されたチャーター（「一航程」）可用性情報を配布するリソースを含む、広範囲のリソースからデータを受け取るように構成することができる。標準化されたデータソース１３０は、ある範囲の文書フォーマットでデータを生成し、外部システムからＴＡＳへ送信することができる。これには、ＸＭＬフォーマットのデータ、リモートアクセス可能なデータベース、明確にフォーマットされたウェブサイト、および／または電子メールを含めることができる。

有利なことに、ＴＡＳは、その範囲の文書フォーマットの集約を容易にするチャーターオブジェクトフォーマットの広範囲のライブラリを含む。ＴＡＳの追加コンポーネントは、潜在的顧客から発する使用可能フライトに関する要求を受け取り、処理するように構成される。これらの要求は、チャーターデータソースから公表することができる。潜在的顧客を、カスタマリレーションシップシステム、ウェブサイト、および他のデータ入力アプリケーションによって旅行集約システムに参照することもできる。

さらに、チャーターデータオブジェクト（たとえば、使用可能フライトデータおよび／または要求されたフライトデータ）を、構造化されていないディジタル文書（たとえば、電子メール）で供給することもできる。ＴＡＳは、意味論的／コンテキスト的に分析されるこれらの文書のテキストを処理するように構成され、あるアルゴリズムが、チャーターデータレコードを（使用可能なフライトまたは要求されたフライトから）抽出する。このシステムを、情報の理解のレベルに基づいてこれらのレコードに信頼の度合を割り当てるように構成することができる。システム管理者は、データレコードを処理し、ＴＡＳシステムデータベース１１０に投入するのに使用されるチャーターフライトデータレコードを投入するための多数の抽出ルールに基づくシステムアルゴリズムを開発するために、ＴＡＳを扱う。

このシステムを、情報を構造化し、ＴＡＳデータベースに投入するために、構造化されていないテキストディジタル文書（通常は電子メール）からチャーターフライト情報を解析し、抽出するシステムデータ抽出モジュールと共に構成することができる。抽出モジュールは、旅行可用性データのある種の特徴／特性を「認識する」ように構成されて供給されるシリーズルールに基づく。抽出される情報の量および質は、特定のソースに関する信頼の度合メトリックの基礎を提供する。抽出されたデータが疑わしい場合には、オリジナルの抽出文書を、以下の検索判断基準に従ってエンドユーザに表示することができ、その結果、データは、処理中に誤って特徴を表されず／無視されなくなる。その代わりに、疑わしい文書をシステムから追い出すことができる。

このシステムを、チャーターデータオブジェクトからさまざまな情報を抽出するように構成することができる。たとえば、ＴＡＳを、構成されたチャーターデータオブジェクトを処理するように構成することができる。というのは、単一のディジタル文書が、単一のフライトまたは複数のフライトに関する情報を含む可能性があり、情報が異なるソース（パブリッシャ）によって公表されるからである。一部のソースは、周知であり、頻繁に公表される。他のソースは、より低い頻度で公表され、いつでも、新しいソースが追加される可能性がある。オブジェクトは、チャーター会社；会社、名前、住所、電話番号、ウェブサイト、および連絡先の電子メール；飛行機のタイプ、名前、モデルなど；出発日、日付の可用性範囲；出発地の空港ベース（都市の名前、空港の名前、空港コード）；および／または目的地（都市、地域、国、空港名またはコード）などの情報を含むことができる。

図２に、ＴＡＳデータ集約および管理の諸態様を示す高水準流れ図を示す。このシステムの実施態様によれば、この処理は、ステップ２００で、ＴＡＳがチャーターデータオブジェクト（構造化された／構造化されていないフライト可用性情報）を受け取るか入手する時に開始される。ＴＡＳは、ステップ２１０で、一連のチャーターデータ識別および抽出ルールを取り出し、ステップ２２０で、チャーターフライトデータ特性を抽出する。チャーターデータオブジェクトのソースならびに抽出されたデータ特性の品質に基づいて、ＴＡＳは、データ信頼度メトリック２３０を導出する。信頼度メトリックは、抽出されたデータが評判のよいプロバイダからの可用性情報に対応し、あるいは、フライトデータ特性がシステム管理者によって確認済みである可能性があることの保証をシステムユーザに提供する。フライトデータ特性および信頼度メトリックは、その後、ステップ２４０で、チャーターフライトデータレコードを投入するのに使用される。チャーターフライトデータレコードは、その後、使用可能フライトデータをＴＡＳデータベースに投入するのに使用される。

ＴＡＳデータベースが投入された後に、システムユーザは、ステップ２５０でフライトデータ検索要求をサブミットすることができる。フライトデータ検索要求は、３つの１次フライトパラメータすなわち、要求されたフライト機器、時間、および位置に基づくものとすることができる。ＴＡＳは、ステップ２６０で、検索パラメータを抽出し、使用可能チャーターフライトデータベースの検索を行う。ＴＡＳを、ステップ２７０で、検索要求に対応する最良一致を含む最初の検索結果ならびにシステムユーザに代替の提案される結果を提供するＴＡＳ生成の代替検索結果を作成するように構成することができる。実施態様に応じて、システムを、検索結果に対して動的更新を行うように構成することができる。動的更新では、システムユーザは、最良一致の予約をとるために供託金を積むことができる。しかし、所定の予約期間の間に、システムは、周期的に検索を再実行することができる。このタイプの実施態様では、ステップ２９０で、よりよい一致が後続検索の１つで識別される場合にシステムユーザに通知するようにＴＡＳを構成することができる。いくつかの実施態様で、システムユーザに、ペナルティなしで動的検索結果にアップグレードする機会を与えることができる。

上述したように、このシステムは、文書内のある種のインジケータを探してデータを処理することを試みる。たとえば、チャーターフライト情報は、通常、単一のフライトまたは複数のフライトに関する情報（「インジケータ」）を含むディジタル文書としてフォーマットされる。一般に、この情報は、さまざまなソース（パブリッシャ）によって配布され／公表される。一部のソースは、周知であり、頻繁に公表される。他のソースは、より低い頻度で公表され、いつでも、新しいソースが追加される可能性がある。インジケータのいくつかの例は、チャーターフライトオペレータの名前；会社、名前、住所、電話番号、ウェブサイト、および連絡先の電子メール；特定の飛行機のタイプ、名前、モデルなど；出発日、日付の可用性範囲；出発地の空港ベース（都市の名前、空港の名前、空港コード）；および／または目的地（都市、地域、国、空港名またはコード）を含む。これらのインジケータは、単に、チャーターフライト産業内で供給される例である。本発明を、他の産業に関連するインジケータならびに全世界の都市、地域、国、州／県などに関連する位置情報を識別するように構成でき適用できることを理解されたい。

図３に、ＴＡＳの一実施態様によるチャーターデータ集約プロセス３００の諸態様を示す。このプロセスは、ＴＡＳがチャーターフライトデータオブジェクトを受け取る／入手する時に開始される。実施態様に基づいて、このプロセスは、データオブジェクトの受動的受け取り３１５またはデータオブジェクトの能動検索３１０を含むことができる。ＴＡＳがデータオブジェクトを有したならば、ステップ３２０で、データオブジェクトを処理するためにチャーターデータ特性抽出ルールを取り出す。抽出ルールは、システム管理者によって確立され、ある種のチャーターデータ特性に焦点を合わせるために反復的に洗練することができる。図３では、ＴＡＳ抽出プロセスは、ステップ３２５で最初のフライトインジケータを識別する。以下でより詳細に述べるように、ＴＡＳは、ＴＡＳシステムデータベースに格納され、またはＴＡＳシステム管理者によって確立された複数のフライトインジケータのいずれに関する抽出をも調整することができる。フライトに関する情報は、通常、あるタイプの文書（ＡＳＣＩＩ、ＨＴＭＬ、電子メール、または印刷された可用性レコードのファックス）として受け取られる。当初に、ＴＡＳは、次の情報データベースと共に構成され、最初のフライトインジケータを相関させるための鍵（すなわち、オブジェクトが実現可能なフライトデータを含むことを示すデータオブジェクトへの最初のフック）としていずれか１つまたは複数を単独でまたは組み合わせて実施することができる。

−空港、その都市、および空港コードのデータベース
−チャーター航空機会社、名前、およびモデルのデータベース
−すべての地域情報の緯度および経度
−データフォーマットおよび日付関連キーワードのデータベース
−関連するインジケータまたはキーワードおよび類義語の辞書

最初のフライトインジケータを識別したならば、インジケータに関連する追加のフライト特性を抽出する。さらに、ステップ３３０で、追加のフライトインジケータおよびすべての対応するフライト特性を抽出するようにＴＡＳを構成することができる。ステップ３３５で、ＴＡＳが、オブジェクト信頼度インジケータを作成する。図３では、３つの可能な信頼度インジケータすなわち、データオブジェクトの基礎になるソースがＴＡＳに登録されたチャーターソースであることを示す信頼度インジケータ、ソースが登録されたソースではないが、データが実現可能であることを示すのに十分なフライトデータが抽出されていることを示す信頼度インジケータ、およびソースが登録されたソースではなく、データが実現可能なデータフォーマットではないことを示す信頼度インジケータを作成することができる。データオブジェクトが、この最後のタイプのインジケータに相関する場合に、しばしば、そのデータオブジェクトは、システム管理者がＴＡＳをオーバーライドしない限り、無効として拒否される。ＴＡＳの文脈では、空港ルート（片道航程）検出は、ユーザがフライトルートを検索するので、集約に使用される最も重要な情報である。分析中に検出された可能なフライトオブジェクトの信頼度が非常に低いか、相補的情報（日付、連絡先など）が明確に検出されない時であっても、これらのありそうもないフライトルートを除去せずに格納するようにＴＡＳを構成することができる。ユーザがフライトルートを検索する時に、多数のありそうもないルートが、照会によって除去され、結果は、通常は信頼度ランキングによって表示される。

ＴＡＳは、信頼度インジケータを決定するためにさまざまなルールを実施することができる。たとえば、いくつかの基本的なルールは、次の番号付きの要素を含むことができる。

１．単一フライトの内容
−日付は今日または将来にしなければならない。いくつかのキーワード（すなわち、ｔｏｍｏｒｒｏｗ（明日））も、日付として検出しなければならない
−フライトレコードの各可能なデータフィールドが、フォーマッティングルール、キーワード近接ルール、ならびにキーワードの出現の順序および出現回数を使用して検索され、識別される。

２．文書内の１つまたは複数のフライトの存在の検出
−３つ以上の空港コードまたは空港名がある場合には、おそらく複数のフライトが文書内にある
−フライトは、対すなわち出発地および目的地で現れる
−空港の対が検出される時には、その対は、産業界の慣習に従う可能性がある。そうである場合には、検出されたフライトのスコアリングを高める
−フライトは、いくつかの期待されるフィールドを有効にされる
−フライトのリスト内のフライトの個々のレコードは、
・フライトフィールドとして識別される単語の近接に基づくルールと
・可能なフライトレコードフィールドオカレンスの出現の回数と
を介して識別される。

３．内容のランキング
−複数の内容ルールが、検出された産業キーワード、各注文へのキーワード対近接（文字および改行に依存する）、産業固有キーワード、産業対非産業固有使用法に基づくキーワードの一般的命名および信頼度に関するパターンマッチングに基づいて内容をランキングする
−内容は、ユーザによってシステムに供給される情報に基づいてランキングされる
−内容は、専門家ユーザから供給される正確さフィードバックにも基づいてランキングされる
−ランキングは、類似する分析された内容に関する過去の結果にも依存する
−フライトレコードの新しさは、その価値を高める。

４．他のルール
−新しい文書のフォーマットが、同一のソースから以前に受け取られた文書のフォーマットと一致する場合に、情報の正確における信頼の度合は、以前の信頼の度合と一致する。以前の信頼の度合が１００％であった場合には、抽出の正確は、１００％でなければならない。
−既知のフォーマットのライブラリが、フォーマットについて構築され、ほとんどのフライトレコードフィールドを、あるフォーマットの複数の出現における変動から識別することができる。異なるフォーマットの間の差も、ユーザ／開発者によって、ディジタル文書内の関係するデータフライトレコードフィールドを識別することによって判定することができる。
−テンプレートを、人間によって生成されたのではない、既知の検出可能なソースから発するメッセージについて定義することもできる。これらのメッセージについて、フライト情報を、１００％信頼度で抽出することができ、フォーマットに対する変更は、検出テンプレートを将来の変更に適合させるために警告を生成することができる。

５．内容の拒絶。フライトを含まないいくつかの無効な文書がシステムにサブミットされる場合に、それらの文書を、除去するか、システムの正しさに影響せずに脇に置くことができる。
−フライトコードなど、いくつかのキーワードは、関係する情報のランキングにおいてより高い価値を有する。
−日付など、いくつかのキーワードは、他の単語（フライトコード）と共に存在するのでない場合に、より低い価値を有する可能性がある
−各キーワードカテゴリは、文書を拒絶しなければならないかどうかを判定するためのスコアリングを確立するためにレーティングされ、ランキングされる
−文書内に少数の基本的な構成要素だけがあり、フライトコードがない場合には、その文書は、おそらくは関係する文書ではなく、無視されなければならない
−同一の種類のルールを、関連に関して領域をレーティングするために文書の諸領域に適用することができる。いくつかのランキングされたテキスト領域を、他のランキングされたテキストセグメントおよび他のルールと組み合わせて、文書のランキングを補足することができる。たとえば、フライト日付または都市は、多数のフライトをリストする文書内で１回だけ指定することができる。

このアルゴリズムは、人間が書いたメッセージ内で多数のフライトを検出することができ、これらのほとんどは無効である。しかし、これらは、スコアが０である場合にフィルタアウトされる。さらに、このアルゴリズムは、実際には無効である可能なフライトを検出する。しかし、これらは、次の手段によってフィルタアウトされる。

−ユーザは、特定のフライト、たとえば２つの空港の間のルートを検索するので、他のルートは表示されない。したがって、人間が選ばないはずのすべての異常なルートは、通常、無効に検出されたルートに対応する。このシステムのテストおよび使用は、これが、無効に検出されたルートのほとんどをフィルタアウトし、その結果、表示されたままになるルートが、有効であるかおそらく有効であることを示した。

−検索エンジンは、最も関連する一致を提示し、これらをスコアリングによってソートする。したがって、有効なフライトが、最初に提示される。

−ある照会について、いくつかの可能なフライトが表示される場合に、解析されたメッセージのうちでフライト情報に対応する部分が、検索結果内に表示され、その結果、ユーザは、フライトが有効であるかどうかをビジュアルにすばやく識別できるようになる。

ルールを、ユーザ介入から調整し、豊かにすることができる。ユーザは、ルールおよび分析に優先順位を与える産業コンテキスト固有エキスパートシステムの追加を介して追加の内容を供給することができる。このユーザは、多数の使用可能な文書からシステムをトレーニングする開発者または産業専門家とすることができる。特定のシステムユーザの必要に応じて、このシステムを、次を行うように構成することができる。

１．すべてのフィールドが照合されたかどうかを検証する
２．照合されていないフィールドの正しい情報を示すことによってシステムをトレーニングする
３．不正に照合されたフィールドを識別する、たとえば、フライト到着または出発に関する都市が、連絡先情報の都市と誤解される可能性がある
４．好ましい会社およびより好ましくない会社のリスト
５．ユーザによって絶対に使用されないかめったに必要とされない空港にフラグを立てる
６．好ましい連絡先およびより好ましくない連絡先のリスト
検出されたフライトに割り当てられた信頼度スコアリングに基づいて、ユーザ定義しきい値が、実現可能、おそらくは実現可能、および／または無効なフライトを識別するのを助ける。

データ信頼度チェックの一部として、ＴＡＳがあるレコードを実現不能として識別することをもたらす可能性がある複数の追加の情況がある。旅行日付が、現在または将来の旅行でなければならないことに留意されたい。また、ＴＡＳを、チャーターオブジェクトの日付と連繋するキーワード（すなわち、ｔｏｍｏｒｒｏｗ）を認識するように構成することができ、これを、データオブジェクト処理中に実際の日付を用いてフライト情報を補足するためのインジケータとして使用することもできる。フライトレコードの各可能なデータフィールドは、フォーマッティングルール、キーワード近接ルール、ならびにキーワードの出現の順序および出現回数を使用して検索され、識別される。このプロセスを、下で図４〜５Ｅに関してより詳細に説明する。

また、３つ以上の空港コードまたは空港名がある場合には、複数のフライトが文書内にある可能性がある。一般に、フライトは、出発地フライトおよび目的地フライトに対応する対で述べられる。複数のフライトデータ抽出が、実現可能チャーターオブジェクトとして資格を与えるためのシステムしきい値を確立する、ある期待されるデータ修飾子／識別子（フィールド）を有する場合もある。より具体的に言うと、フライトのリスト内のフライトの個々のレコードは、ａ．）フライトレコードとして識別された単語の近接に基づくルールおよびｂ．）可能なフライトレコードフィールドオカレンスの出現回数を介して識別される。データは、信頼度ルール、ＴＡＳに供給される情報、または管理者１４０（図１Ａから）から供給される正確さフィードバックに基づいてステップ１８０でランキング（検証）される。ＴＡＳは、類似する分析された内容を含むヒストリカル結果ならびにフライトデータがどれほど最近のものであるかに基づいてランキング／検証を行うこともできる。

追加の正確度ルールは、文書フォーマットを分析することを含む。新しい文書のフォーマットが、同一の（検証された）ソースから以前に受け取られた文書のフォーマットと一致する場合に、情報の正確における信頼の度合は、以前の信頼の度合と一致する。以前の信頼の度合が１００％であった場合には、抽出されたデータも、１００％でなければならない。既知のフォーマットのライブラリを、フォーマットについて作成し、維持することができ、ほとんどのフライトレコードフィールドを、ＴＡＳシステムデータベース内に格納されたフォーマットの変形形態として識別することができる。

変形形態を、ディジタル文書内の関係するデータフライトレコードフィールドを識別することによってユーザ／開発者を相関させることによって識別することもできる。さらに、信頼度メトリックを判定する際に、異なるパラメータに異なる重みを割り当てることができる。空港コードなど、いくつかのキーワードフライトインジケータは、関係する情報のランキングにおいてより高い価値を有する。日付などのいくつかのキーワードは、他の単語（空港コード）と共に存在するのでない場合に、より低い価値を有する可能性がある。各キーワードカテゴリは、文書を拒絶しなければならないかどうかを判定するためのスコアリングを確立するためにレーティングされ、ランキングされる。文書内に少数の基本的な構成要素だけがあり、フライトコードがない場合には、その文書は、おそらくは関係する文書ではなく、無視されなければならない。

同一の種類のルールを、関連に関して領域をレーティングするために文書の諸領域に適用することができる。たとえば、抽出されたヘッダ情報に、抽出された本体情報より大きい重みを与えることができる。また、いくつかのランキングされたテキスト領域を、他のランキングされたテキストセグメントおよび他のルールと組み合わせて、文書のランキングを補足することができる。たとえば、フライト日付または都市は、多数のフライトをリストする文書内で１回だけ指定することができる。システム管理者１４０は、抽出ルールを補足／強化／変更し、または作成／削除することができる。その代わりに、いくつかの実施形態で、ユーザは、ルールおよび分析に優先順位を与えるエキスパートシステムに追加の内容を供給することができる。いくつかの実施態様で、管理者は、多数の使用可能な文書からシステムをトレーニングする開発者または産業専門家とすることができる。いくつかの可能な管理者ルールは、ある／すべてのデータフィールドが照合されたかどうか、または好ましい（または除外される）会社および／または連絡先をリストすることを含む。

図４に、フライト可用性情報を含むチャーターデータオブジェクトの例を示し、図５Ａ〜５Ｅに、例のチャーターデータオブジェクトに対するさまざまな処理ステップの諸態様を示す。図４では、チャーターデータオブジェクト４００が、電子メールフォーマットを有して示されている。上述したように、ＴＡＳは、受動的チャーターオブジェクト検索、たとえば、フライト可用性情報を受け取るために電子メールリストサーバにサブスクライブすることを実施することができる。図４では、チャーターデータオブジェクトが、可用性電子メールオブジェクト４００として構成される。電子メール４００オブジェクトを、ヘッダ情報４１０および本体情報４２０に分割することができる。実施態様に応じて、オブジェクトの１つの部分から抽出されたデータフライトデータに、電子メールオブジェクトの別の部分から抽出されたデータと異なって価値を与えることができる。

また、図４に、電子メールチャーターオブジェクトの処理の概要の諸態様を示す。ＴＡＳは、ステップ４３０で、チャーターオブジェクトを新しい電子メールとして識別し、ステップ４４０で、電子メールフォーマットについてチェックする。ステップ４４０は、ＴＡＳ信頼度メトリック導出プロセスの重要な部分である。図４に示されているように、ＴＡＳは、データオブジェクトが単純なテキストフォーマットまたはＨＴＭＬメッセージ４４３、表形式のＨＴＭＬフォーマット４４６、あるいは登録されたソースからの既知のフォーマットとして識別可能のどれであるかを調べるためにチェックする。ＴＡＳが、登録されたソースからのものとしてオブジェクトを認識する場合（４４９）に、ＴＡＳは、オブジェクトからフライト識別子およびフライト特性を抽出するのに使用できる解析ルールの格納されたセットを選択することができる。たとえば、ＴＡＳは、登録されたソースＡ、Ｂ、およびＣからのデータオブジェクトと共に使用するために対応するテンプレートＡ（４５３）、Ｂ（４５６）、およびＣ（４５９）を有することができる。これらのテンプレートは、オブジェクトが以下で説明する実現可能なフライトデータを含むかどうかを判定する際に処理される生データを作成するのに使用される。

図５Ａは、どのテンプレート４５３〜４５９もデータオブジェクトと一致せず、メッセージが単純なテキストまたはＨＴＭＬメッセージであると判定された時の最初の処理ステップの諸態様を示す。表形式のＨＴＭＬまたは他の文書フォーマット（たとえば、ワード文書、ｐｄｆなど）は、説明されたものに類似するが、さまざまなファイルフォーマットおよび／またはディジタル文書内のテキストのレイアウトを考慮に入れるための差を伴う原理を使用して分析することができる。ＴＡＳは、処理のために電子メールから生テキストを抽出するが、分析のために２つの異なるテキスト部分すなわちヘッダ５１０からのテキストおよび本体５２０からのテキストを維持する。生テキストを抽出したならば、ＴＡＳは、図５Ｂに示された、可能なフライト識別子を抽出するためのテキストの解析に進む。テキスト解析／分析プロセス５２５は、解析のために生テキストをオリジナルのオブジェクト部分に分割することから始まる（たとえば、ヘッダテキストはヘッダセクション５１０内に留まり、本体テキストは本体セクション５２０内に留まる）。この区分は、後に、信頼度メトリックを判定する際に助けるために分析において使用することができる。解析ツールは、どのキーワードが、ステップ５３５で実行される分析においてフライト識別子として働くかを識別する。この議論において、空港コード５４４は、パーサが探しているキーワードフライトインジケータとして指定されている。しかし、データオブジェクトのソース／タイプおよび／またはシステムユーザの特定の必要に応じて、キーワードフライトインジケータを、日付情報（５４２）として指定できることを理解されたい。チャーターデータオブジェクト内に現れる可能性がある機器情報（５４０）または複数の他のパラメータを、フライト識別子として使用することができる。これらの他のキーワード（５４０、５４２）を、ルート検出プロセス（５３５）をさらに助けるために、ステップ５３０の直後に検出し、空港コードと並列に処理することもできる。したがって、ステップ５３５、５４０、５４２、５４４（５４５、５５０を含む分岐）のすべてを、並列に行うことができ、これらは、５５５につながる。キーワードフライトインジケータに基づいて、ＴＡＳは、次いで、ステップ５４５で、可能なルートリスティングを生成し、フライト特性を抽出する。

いくつかの実施態様で、ＴＡＳは、フライト特性をフライトインジケータと照合する際の相関要因として単語近接を使用する。リスティングを生成したならば、ステップ５５０で、各可能なルートを、チャーターデータソース／データオブジェクトに関連するスコアリングテンプレートに従ってスコアリングする。実現可能なルートを識別したならば、ステップ５５５で、フライト日付情報および追加のフライト特性を、キーワード近接またはコンテキストに基づいてインジケータに関連付ける。

図５Ｃに、キーワード識別子が、チャーターデータオブジェクトの２つの部分に関して生テキスト内でどのように解析されるかの例を示す。図５Ｃでは、キーワード識別子が、空港コードとして知られる３文字または４文字の単語である（世界中のすべての空港に一意の空港コードが関連付けられ、たとえば、米国ニューヨーク市のラガーディア空港は、ＬＧＡに対応する）。したがって、３文字または４文字のすべての単語が、対象部分５６０内で識別され、チャーターオブジェクトの本体部分５６５が、識別される。図示されているように、「Ｎｅｅｄ」、「ＴＥＢ」、および「ＴＮＣＭ」は、３文字または４文字の単語として資格を与えられる。次に、これらの単語をＴＡＳシステムデータベース内に保持される空港コードデータベースエントリと比較することができる。

図５Ｄに、チャーターオブジェクトが実現可能なチャーターフライトルート情報を含むかどうかを判定するために行われる空港コードペアリングおよびスコアリングプロセスの諸態様を示す。たとえば、前のステップからのヒットのそれぞれ（たとえば、「ＴＥＢ」または「ＴＮＣＭ」）が、別のヒットと照合され、コンテキスト的に分析されて、提案されるルートの相対スコアが判定される。たとえば、図５Ｄでは、「ＴＥＢ」および「ＴＮＣＭ」が、識別され、対象対５７０としてさらなる分析のために対にされる。この分析は、ある種の制約が満足される場合に正味スコアにポイントを加算することに基づく。

たとえば、空港コード対はメッセージ対象部分の中にあるので、提案されるルートのスコアは、２０ポイントだけ増やされる。対の左の単語および右の単語のそれぞれが、大文字になっているので、ルートスコアは、４ポイントだけ増やされる。さらに、対の両方の単語が、大文字であり、同一行にあるので、スコアは、追加の２０ポイントだけ増やされる。一般に、特性が実際のフライトルートを示せば示すほど、対のスコアが増やされる。たとえば、対がダッシュによって区切られ、両方の単語が同一行にあり、対を区切る他の文字がないので、スコアは、１００ポイントだけ増やされる。この特徴は、航空機に関する用語標準の文脈で実現可能ルートを非常によく示す。

図５Ｅに、スコアリングルーチンの諸態様を示し、ここで、図５Ｅで識別される各提案される対のスコアが比較されている。ＴＡＳは、すべての可能な対およびそれに対応するスコアのリスティング５７５を作成する。対が、レコードの対象部分と本体部分との両方に現れる場合に、対スコアが合併される。組み合わされたスコア５８０が、対が実現可能なフライトデータとして資格を与えられるかどうかを判定するのに使用される。実施態様およびＴＡＳによって実施されるスコアリングルールに応じて、対が実現可能なフライトデータとして資格を与えられるための有効カットオフである実現可能性しきい値５８５がある。図５Ｅに示されているように、カットオフ未満のフライトは、非常にありそうもないルート５９０と指定される。このプロセスは、システムがしきい値未満の提案されるルートを除去した状態で自動化することができ、あるいは、すべてのルートがスコアリングされた後に、実現可能なルートの指定を、システム管理者によってビジュアルに達成することができる。

さらに、いくつかの実施形態で、このシステムは、空港間の距離が短すぎる場合に提案される対を除外する追加のフィルタを実施することができる。代替案では、空港が離れすぎているか、軍事空港であるか、要求された／使用可能なフライト機器に関連しない場合に、スコアを下げるか除去することができる。日付検出は、パターンマッチング、パターンの優先順位付け、または提案されるルートに対する相対的なテキスト位置によって達成することができる。

図６は、本発明の実施形態によるフライト要求処理の諸態様を示す高水準流れ図である。この処理は、ステップ６１０で、システムユーザがこのシステムにアクセスし、チャーターデータ検索要求を作成する時に開始される。一実施態様で、システムユーザは、検索要求を作成するために、このシステムにログオンし、ビジュアル／テキスト検索要求インターフェースを利用することができる（図１０Ａおよび１０Ｂに示し、以下でより詳細に述べるように）。代替案では、システムユーザは、チャーターデータ検索要求を作成し、サービスプロバイダに転送することができ、このサービスプロバイダは、ステップ６１０で可用性をチェックするためにＴＡＳシステムにこの要求を転送することができる。

検索要求を受け取ったならば、このシステムは、ステップ６２０で、検索要求を処理して、要求を使用可能なフライトレコードと照合する際に使用される検索キーワードを抽出することができる。実施態様に応じて、このシステムは、検索要求フライト機器特性、フライト出発位置／目的位置特性、フライト出発／目的時刻特性を使用して、可用性フライトレコードの検索をキーイングすることができる。ＴＡＳは、最良一致ならびに最良一致に対するランキングされた代替案を識別する検索結果リスティングを作成する。代替案は、代替機器パラメータ６３２、代替位置パラメータ６３４、代替時刻パラメータ６３６、または代替機器再配置パラメータ６３８に従ってランキングすることができる。機器再配置パラメータ６３８は、検索要求パラメータを満足できる近くの機器を再配置することに伴う追加コストを示す。

ステップ２１０でＴＡＳにログオンした後に、システムユーザは、検索エンジン１１０と相互作用して、検索要求を生成し、サブミットする。ステップ２２０で、ＴＡＳは、検索要求を受け取る。このシステムは、ステップ２３０で、システム照会を生成し、実行して、最初の一致があるかどうかを判定する。本発明のいくつかの実施形態で、このシステムは、ステップ２４０で、最初の照会に基づいて導出される代替旅行配置をも作成し、システムユーザに提示する。ステップ２５０で、このシステムは、検索結果を生成し、システムユーザに表示する。

特定のシステムユーザの必要に基づいて、ＴＡＳのいくつかの実施態様を、ユーザ定義および／またはシステム定義の検索項目あるいは代替結果を提案するためのユーザ定義および／またはシステム定義のルールに基づく検索要求の処理など、ある種の機能を伴って構成することができる。たとえば、ユーザの必要ならびに／あるいは要求された出発時刻の精度および要求された地域または空港に応じて、このシステムを、ある個数の可能な計算を判定するように構成することができる。
−検索要求について、使用可能な飛行機が、識別され、要求の日付および／または時刻に関して空の航程と照合される。
−カバレッジをチェックする
・空港の緯度および経度を使用してフライトの長さおよびフライト時間を推定する
・カバレッジ最小値とフライト時間を比較する
−要求に一致するためにある飛行機の位置を変更できるかどうかを調べるために飛行機のリアルタイム位置をチェックする
・テールナンバー（ｔａｉｌ ｎｕｍｂｅｒ）を使用して、このシステムは、ベース空港をリンクし、最も近い空港へのフライトの距離および時間を計算する。
・通過の区域を検証する
・位置変更時間が地点Ａと地点Ｂとの間のフライト時間の５０％未満であるかどうかを計算する
−可能な新しいフライト出発に関する追加の一致を見つけるために、このシステムは、将来の片道フライトの目的地を調べる。
−このシステムは、往復フライト要求を２つの片道フライトと照合する。代替案では、このシステムは、２つの片道フライトを往復旅行に関する要求と照合することができる。

このシステムを、次の特徴をサポートするように構成することもできる。
−販売代理人が、受け取られ、可能な可用性と照合された要求について見つかった新しい一致について警告を受け取り、その結果、顧客に関する最良一致をさらに判断でき、フライトを使用可能にする会社から見積を得られるようにすることができる。
−検索結果を
・データの鮮度によってソートする
・最良の位置から最悪の位置へ（最も近い一致）表示する
・範囲（距離）または時間（１時間単位）によってフィルタリングする
・地域によってフィルタリングする
・マッピングエンジンを使用してビジュアルに表示する
ことができる。
検索エンジン結果の２つの可能な実施態様が、図１０Ａおよび１０Ｂ（下で詳細に述べる）に含まれ、説明される。さらに、このシステムを、会社のリストを含むＴＡＳデータベース内のアカウント情報のレコードを維持し、会社をリストすることと次を含むそれらの会社の詳細を見ることを可能にするように構成することができる。
・その会社が有する飛行機のタイプ
・その会社がどこに基づくか
・通常の価格
・この会社から使用可能なフライト
・その会社に関する過去のアクティビティおよび満足
さらに、ＴＡＳの柔軟なアプリケーションプログラムインターフェース（ＡＰＩ）モジュールは、他のソフトウェアアプリケーションとの完全な統合を可能にする。たとえば、ＣＲＭシステムは、販売の機会を受け取り、このシステムに要求を送ることができ、このシステムは、可能なフライト可用性の結果を返す。このＡＰＩのいくつかの特徴は、次を含む。
−航空機会社データを取り出し、挿入し、変更する能力
−見込みのあるフライト要求を取り出し、挿入し、変更する能力
−会社、連絡先、フライト要求、および使用可能なフライトルートを外部ＣＲＭシステムと同期化する能力
−特定のフライト要求またはフライト可用性に関する検索を開始し、検索結果を取り出す能力
−構造化されていないフライト情報を解析し、理解するためにこのシステムにアクセスする能力、ルールの優先順位を微調整し、検索テンプレートおよび取り出しテンプレートを追加し、使用されるキーワードを追加し、変更するなどのために構成できるそれ自体のＡＰＩを有する。

ビジュアルインジケータは、レコードが、このシステムが確かには識別できない構造化されていない情報から発する時に、各表示されるレコードの信頼度のレベルを示す。これらの特徴の諸態様は、図１０Ａおよび１０Ｂに関してより詳細に述べる。

図７および８Ａ〜８Ｅに、ＴＡＳの実施形態による検索要求を処理するもう１つの方法の諸態様を示し、ここで、チャーターデータ検索要求が、このシステムによって受け取られる。図７は、ヘッダ７１０および本体７２０を伴う電子メールとして構成されたチャーターデータ検索要求を示す。この電子メール検索要求プロセスは、図４〜５Ｅに示されたチャーターデータオブジェクト処理に関して上で述べたものに類似する。電子メールが、ステップ７３０でＴＡＳによって受け取られ、その後、７４０で、電子メールフォーマットをチェックする。フォーマットに応じて、ＴＡＳは、データ抽出ルールの異なるセットを適用することができる。たとえば、電子メールは、単純なテキストまたはＨＴＭＬメッセージ７４３、表形式のＨＴＭＬフォーマット７４６、または登録されたデータソースからの既知のフォーマットとして構成される可能性がある。検索要求が、登録されたソースからのものである場合に、ＴＡＳは、対応するソース固有解析テンプレート（テンプレートＡ ７５３、テンプレートＢ ７５６、またはテンプレートＸ ７５９）を適用できる場合がある。

図８Ａに、電子メールフォーマットが識別された後の最初のステップを示し、ここで、ＴＡＳは、処理のために電子メールから生テキストを抽出するが、分析のために２つの別個のテキスト部分すなわちヘッダ８１０からのテキストおよび本体８２０からのテキストを維持する。生テキストを抽出したならば、ＴＡＳは、図８Ｂに示された、可能なフライト識別子を抽出するためのテキストのフォーマッティングおよび解析に進む。テキスト解析／分析プロセス８２５は、生テキストを解析のためにオリジナルのオブジェクト部分に分割することから始まる（たとえば、ヘッダテキストはヘッダセクション８１０内に留まり、本体テキストは本体セクション８２０内に留まる）。この区分は、後に、信頼度メトリックを判定する際に助けるために分析において使用することができる。

解析ツールは、どのキーワードが、ステップ８３５で実行される分析においてフライト識別子として働くかを識別する。この議論において、空港コード８４４は、パーサが潜在的検索結果と照合するのに使用するキーワードフライトインジケータとして指定されている。しかし、データオブジェクトのソース／タイプおよび／またはシステムユーザの特定の必要に応じて、キーワードフライトインジケータを、日付情報（８４２）、機器情報（８４０）、またはチャーターデータオブジェクト内に現れる可能性がある複数の他のパラメータとして指定できることを理解されたい。キーワードフライトインジケータに基づいて、ＴＡＳは、ステップ８４５で、可能な照合されたルートリスティングを生成し、フライト特性を抽出する。いくつかの実施態様で、ＴＡＳは、フライト特性をフライトインジケータと照合する際の相関要因として単語近接を使用する。

リスティングを生成したならば、ステップ８５０で、各可能なルートを、チャーターデータソース／データオブジェクトに関連するスコアリングテンプレートに従ってスコアリングする。実現可能なルートを識別したならば、ステップ８５５で、フライト日付情報および追加のフライト特性を、キーワード近接に基づいてインジケータに関連付ける。

図８Ｃに、キーワード識別子が、チャーターデータ検索要求の２つの部分に関して生テキスト内でどのように解析されるかの例を示す。図８Ｃでは、キーワード識別子が、空港コードとして知られる３文字または４文字の単語である（すべての空港に一意の空港コードが関連付けられ、たとえば、米国ニューヨーク市のラガーディア空港は、「ＬＧＡ」と指定される）。したがって、チャーターオブジェクトの対象部分５６０および本体部分５６５内の３文字または４文字のすべての単語が、可能な空港コードとして識別される。図８Ｃに示されているように、生テキスト「Ｎｅｅｄ」、「ＴＥＢ」、および「ＴＮＣＭ」は、３文字または４文字の単語として資格を与えられる。次に、これらの単語をＴＡＳシステムデータベース内に格納された空港コードデータベースエントリと比較することができる。

図８Ｄに、チャーターオブジェクトが実現可能なチャーターフライトルート情報を含むかどうかを判定するために行われる空港コードペアリングおよびスコアリングプロセスの諸態様を示す。たとえば、前のステップからのヒットのそれぞれ（たとえば、「ＴＥＢ」または「ＴＮＣＭ」）が、別のヒットと照合され、コンテキスト的に分析されて、提案されるルートの相対スコアが判定される。たとえば、図８Ｄでは、「ＴＥＢ」および「ＴＮＣＭ」が、潜在的な一致として識別され、対象対８７０としてさらなる分析のために対にされる。このスコアリング分析は、ある種の制約が満足される場合に正味スコアにポイントを加算することに基づく。

たとえば、空港コード対はメッセージ対象部分の中にあるので、提案されるルートのスコアは、２０ポイントだけ増やされる。対の左の単語および右の単語のそれぞれが、独立に大文字フォーマットになっているので、ルートスコアは、４ポイントだけ増やされる。さらに、対の両方の単語が、大文字であり、同一行にあるので、スコアは、追加の２０ポイントだけ増やされる。一般に、特性が実際のフライトルートを示せば示すほど、対のスコアが増やされる。たとえば、対がダッシュによって区切られ、両方の単語が同一行にあり、対を区切る他の文字がないので、スコアは、１００ポイントだけ増やされる。この特徴は、実現可能ルートを非常によく示す。

しかし、これらの図面は空港コードスコアリングセットを対象とするが、機器、出発位置／目的位置、出発／目的時刻、および／または他のフライトインジケータに関連する他のキーワードに基づいて生テキストを分析し、スコアリングすることを対象とするスコアリングルールを実施するようにＴＡＳを構成できることを理解されたい。

図８Ｅに、スコアリングルーチンの諸態様を示し、ここで、図８Ｅで識別される各提案される対のスコアが比較されている。ＴＡＳは、すべての可能な対および各対に対応するスコアのリスティング８７５を作成する。対が、レコードの対象部分と本体部分との両方に現れる場合に、対スコアが合併される。そのような対について、組み合わされたスコア８８０が、インジケータの対が実現可能なフライトデータとして資格を与えられるかどうかを判定するのに使用される。実施態様およびＴＡＳによって実施されるスコアリングルールに応じて、対が実現可能なフライトデータとして資格を与えられるための有効カットオフである実現可能性しきい値８８５がある。図８Ｅに示されているように、しきい値未満にリストされたフライトは、非常にありそうもないルート８９０と指定される。このプロセスは、システムがしきい値未満の提案されるルートを除去することによって自動化することができる。代替案では、すべてのルートがスコアリングされた後に、実現可能なルートの指定を、システム管理者によってビジュアルに達成することができる。さらに、ビジュアル判定の一部として、システム管理者に、実現可能性判定で助けるために、基礎になるチャーターデータ検索要求へのアクセスを与えることができる。

さらに、いくつかの実施形態で、ＴＡＳシステムは、空港間の距離が短すぎる場合に提案される対を除外する追加のフィルタを実施することができる。代替案では、空港が離れすぎているか、軍事空港であるか、要求された／使用可能なフライト要件に関連しない場合に、スコアを下げるか除去することができる。データ検出は、パターンマッチング、パターンの優先順位付け、または提案されるルートに対する相対的なテキスト位置によって達成することができる。

図９は、動的検索結果更新の諸態様を示す流れ図である。検索要求パラメータを抽出したならば、このシステムは、ＴＡＳデータベースに格納されたチャーターフライトデータレコードの検索を行う。このシステムは、システムによって判定された近い使用可能フライトデータレコードに基づいて最良一致を生成する。本発明の実施態様では、このシステムは、最良一致パラメータを格納し、よりよい一致がユーザ指定の時間期間について見つかるかどうかを判定するために検索要求を再試行する。図９では、ＴＡＳは、ステップ９００で、最初の検索結果の一部として動的検索要求インジケータを受け取る。次に、ＴＡＳは、ステップ９１０で、周期的更新の頻度すなわち、使用可能なレコードの検索をどれほど頻繁に実行するかを確立する。これらのパラメータの両方が、一般に、検索要求の一部として含まれる（代替案では、これらを、システムユーザ登録プロセス中に、登録されたシステムユーザについて確立することができる）。このシステムは、検索要求をシステムユーザのアカウント情報に関連付け、検索要求／結果情報をシステムデータベースに格納する。また、ＴＡＳは、ステップ９２０で、最初の検索からの最良一致のコピーを格納する。次に、ステップ９３０で、最良一致および最初の検索要求の特定のパラメータを、更新された検索結果と比較する。最良一致が見つかる場合には、ＴＡＳは、ステップ９４０で、最良一致に関連する項目についてシステムユーザに通知する。

特定の実施態様に応じて、新しい検索結果を、システムユーザによる後刻の再検討のためにシステムデータベースに（ステップ９４０で）単純に格納することができる。代替案では、システムユーザ（または管理者）が、周期的検索更新から「最良の結果」だけを格納するための比較ルールのセットを確立することができる。たとえば、検索要求は、出発都市および目的都市、旅行日数を定義することができるが、ユーザが判定する長さの時間の間の周期的検索からの「最良の価格」の結果を保存するように最適化することができる。次に、ユーザは、周期的更新ストレージモジュールにアクセスして、以前の「最良の」検索結果パラメータではなく新しいパラメータを変更する／受け入れることを望むかどうかを調べることができる。代替案では、格納された「最良の」結果を更新し、ステップ９４０と同様に、更新された検索結果についてユーザに通知するためにユーザ警告を生成し、送信するようにシステムを構成することができる。

図１０Ａに、ＴＡＳに関連するユーザインターフェース１０００を示す。図１０Ａでは、システムユーザの検索結果が、ユーザへの表示のためにテキストフォーマットで提示される。両方の実施形態で、検索要求フォーム１０１０は、対話型フォームである。より具体的に言うと、システムユーザは、このフォームと対話して、「Ｄｅｐａｒｔｕｒｅｓ（出発地）」ボックス４２０の下のテキストボックスに、出発都市／時刻を手動で入力することができる。代替案では、実際のテキスト「Ｓｅａｒｃｈ Ｄｅｐａｒｔｕｒｅｓ（出発地検索）」を、可能な出発都市／時刻のリスティングへのウェブリンクとして構成することができる。システムユーザは、めいめいの出発都市を単純にクリックし、このフォームは、対応する出発地情報を用いて検索要求テキストボックスを更新する。「Ｓｅａｒｃｈ Ｄｅｓｔｉｎａｔｉｏｎｓ／Ｔｉｍｅｓ（目的地／時刻検索）」要素１０３０を、類似する形で構成することができる。検索判断基準には、輸送を必要とする人数に基づく飛行機タイプ要求または機器要求を含むさまざまな他の検索パラメータをも含めることができる。

システムユーザが検索判断基準を定義した後に、ユーザは、ｓｕｂｍｉｔ ｒｅｑｕｅｓｔ（要求サブミット）ボタンをクリックする。次に、このシステムは、検索結果を生成し、テキストベースのリスティング１０４５内に表示する。たとえば、図１０Ａは、ニューヨークからロサンゼルスへのフライトを探す検索要求からの３つの検索結果すなわち、１．ニューヨーク（ＬＧＡ）からシカゴ（ＯＲＤ）へおよびその後にロサンゼルス（ＬＡＸ）へ、２．ニューヨーク（ＬＧＡ）からアトランタ（ＡＴＬ）へ、およびその後にヒューストン（ＩＡＨ）、最後にロサンゼルス（ＬＡＸ）へ、ならびに３．ニューヨーク（ＪＦＫ）からロサンゼルス（ＬＡＸ）へのフライトを示す。３つすべての検索結果を、ユーザがめいめいのリンクをクリックした時に特定のフライト情報に関する追加の詳細を含むウェブページへのリンクとして構成することができる。また、このディスプレイインターフェースに、システムユーザが基礎になるソースを見ることを可能にするリンク１０４６（たとえば、フライト情報がそこから抽出されたフライトデータレコードまたはチャーターデータオブジェクト）を含めることができる。また、このインターフェースを、以前の顧客再検討および／または航空会社の機器説明、名簿、ベース位置など、航空会社情報１０４８へのアクセスを提供するように構成することができる。

図１０Ａに示された実施態様とは対照的に、図１０Ｂは、検索結果のグラフィカルな最初の表現を生成する。たとえば、グラフィカル検索結果１０６０を、米国の地図の上で生成するか、別の旅行区域のためにカスタマイズすることができる。図１０Ｂに示されているように、最初の出発都市は、特定の形状（たとえば円）として示され、最終的な目的地は、異なる形状（たとえば、三角形）１０７５として示される。さらに、旅行の各航程を、クリック可能なイメージとして構成することができる（すなわち、ユーザがニューヨークとシカゴとの間の矢印をクリックする場合に、旅行のその航程に関連するフライト／航空会社データを表示することができる）。代替案では、ユーザは、単純に矢印に「マウスオーバー」して、対応するフライト／航空会社情報を有するテキストボックスを表示することができる。このディスプレイに、要素を全般的に説明する凡例１０７５を含めることができ、あるいは、いくつかの実施形態で、凡例１０７５を、特定の検索結果に関する特定の要素を示すようにカスタマイズすることができる（たとえば、特定の検索結果、ＬＧＡ−＞ＯＲＤ−＞ＬＡＸ）。また、「最良一致」を、ＴＡＳが提案する代替のデータフライトレコードとは異なる特定の色で表示することができる。ＴＡＳの一実施態様では、テキストユーザインターフェースおよびビジュアルユーザインターフェースの諸態様を組み合わせて、ハイブリッド検索結果ディスプレイインターフェースを達成することができる。

このシステムは、特定のユーザ用にカスタマイズ可能であり、追加の／代替の検索フィールドを含むことができる。検索インターフェースを、次のフィルタリングフィールドを伴って構成して、片道フライトの代替検索結果を探すことができる：出発位置／目的位置および出発時間／目的時間を、ユーザがフィールド１０７０、１０８０と対話することによって変更することができる。ＴＡＳを、「最良一致」に加えて、提案される「代替」検索結果を提供するように構成することができる。これらの代替案は、最も早い可能な出発および／または最も遅い可能な到着、機器の異なるカテゴリ（軽ジェット機、中ジェット機、大型ジェット機、定期旅客機など）、飛行機の複数のカテゴリを同時に検索できる、海里単位での最も近い使用可能な飛行機のユーザ定義の半径（または時間単位の旅行時間で入手可能）を含むことができる。このシステムを、空の旅程のみまたは到着しつつあるか出発しつつある飛行機をチェックし、フライト要求、使用可能フライト、またはその両方をチェックするように構成することができる。システムユーザは、日単位および時間単位のフライトレコード鮮度パラメータ（最近のアクティビティに対する相対的な）を指定することができる。いくつかの実施形態で、検索結果は、ユーザが検索パラメータを変更する時にリアルタイムで更新される。ユーザは、データの新しさを含むさまざまなパラメータに従って結果をソートすることもできる。

図１０Ｂに示された実施態様に加えて、表示された検索結果を、２点の間の１航程線、方向、ソースのタイプ、どこから来るか、ベースへのリンクを伴うリアルタイムの飛行機の位置を示すビジュアルマップを使用して表示することができる。システムユーザは、日付、飛行機タイプ、位置変更時刻によるシステムフライトデータレコードフィルタリング機能を用いて点Ａから点Ｂへの旅行を要求することができる。各到着および出発は、飛行機の方向を示すアイコンを使用して示される。到着点および出発点をクリックして、アイコンによって表される空港の詳細、見込みのあるフライト要求のリスト、およびクリックされた空港に到着するフライトおよびその空港から出発するフライトのリストを含むフライトの詳細のポップアップウィンドウを示すことができる。各フライトは、出発地および目的地の日付および時刻、連絡先の電話番号および電子メール、飛行機モデル、ルートで使用される空港、ならびにフライトのデータのソースを示す。ハイパーリンクを使用して、空港の詳細または各フライトの詳細を調べることができる。見込みのあるフライト要求を表す矢印を、ある色の破線または実線を使用して表示することができる。

このシステムを、最良一致／代替フライト検索結果としての選択のために使用可能なフライトを識別するために次のフィルタリングフィールドを含む検索インターフェースと共に構成することができる。

ａ．出発地空港、目的地空港
ｂ．最も早い可能な出発および最も遅い可能な到着の日付および時刻
ｃ．飛行機のカテゴリ（軽ジェット機、中ジェット機、大型ジェット機、定期旅客機など）飛行機の複数のカテゴリを同時に検索することができる。
ｄ．海里単位の最も近い使用可能な飛行機の半径。時間単位でも入手可能である。
ｅ．空の航程のみまたは到着しつつあるか出発しつつある飛行機をチェックする
ｆ．フライト要求、使用可能フライト、またはその両方をチェックする
ｇ．日単位および時間単位の内容の鮮度

一実施態様で、検索結果を、ユーザが検索パラメータを変更する時にリアルタイムで更新することができる。ユーザは、情報の新しさを含む多数の異なるパラメータから結果をソートすることもできる。表示される検索結果を、２点の間の１航程線と、方向と、ソースのタイプと、どこから来るかと、ベースへのリンクを伴うリアルタイムの飛行機の位置と、日付、飛行機タイプ、位置変更時刻によるフィルタリング機能を用いる点Ａから点Ｂへの要求旅行とを示すビジュアルマップを使用して表示することができる。各到着および出発は、飛行機の方向を示すアイコンを使用して示される。到着点および出発点をクリックして、アイコンによって表される空港の詳細、見込みのあるフライト要求のリスト、およびクリックされた空港に到着するフライトおよびその空港から出発するフライトのリストを含むフライトの詳細のポップアップウィンドウを示すことができる。各フライトは、出発地および目的地の日付および時刻、連絡先の電話番号および電子メール、飛行機モデル、ルートで使用される空港、ならびにフライトのデータのソースを示す。ハイパーリンクを使用して、空港の詳細または各フライトの詳細を調べることができる。また、見込みのあるフライト要求を表す矢印を、破線を使用して表示することができる。

ビジュアル検索結果実施形態では、使用可能な片道フライトを、以前に定義されたパラメータを使用してソートできる詳細な結果グリッドを使用してリストすることができる。ビジュアルインジケータを含めて、各フライトデータレコードの信頼度のレベル、フライトデータレコードに関連する航空会社情報、および／または抽出されたフライトデータレコードの基礎になるチャーターデータオブジェクトを表示することもできる。ビジュアルインジケータは、レコードが、このシステムが確かには識別できない構造化されていない情報から発する時に、各表示されるレコードの信頼度のレベルを示す。他の実施形態では、ビジュアルディスプレイに、異なるタイプの機器に使用されるディファピクトグラム（ｄｉｆｆｅｒ ｐｉｃｔｏｇｒａｍ）を含めることができる。もう１つのグリッドを、見込みのあるフライト要求の検索結果を表示するために含めることができる。ユーザインターフェースおよびＴＡＳシステムを、他のタイプのフライトすなわち、往復旅行、複数航程などの検索に適合させることもできる。さらに、ＴＡＳは、ルートを同一の最初の出発地および最終的な目的地について構成できる場合に、一航程要求について複数の航程を提案することもできる（ニューヨークからロサンゼルスへの複数の一航程旅行について図１０Ｂに示されているように）。

旅行集約システム（ＴＡＳ）コントローラ
上記で説明した旅行集約システムを、旅行集約システム（ＴＡＳ）コントローラ１１０１によって実施することができる。本開示の図１１に、ブロック図でＴＡＳコントローラ１１０１の発明的態様を示す。この実施形態では、ＴＡＳコントローラ１１０１は、チャーターデータオブジェクトを入手し／受け取り、処理し、チャーターデータレコードを作成し、チャーターデータレコード管理および検索機能性を容易にするように働くことができる。

コンピュータは、プロセッサを使用して情報を処理し、そのようなプロセッサを、しばしば、中央処理装置（ＣＰＵ）と称する。一般的な形のプロセッサを、マイクロプロセッサと称する。通常はコンピュータ上のＣＰＵによって実行されるソフトウェアであるコンピュータオペレーティングシステムは、ユーザがコンピュータ情報テクノロジおよびリソースにアクセスし、操作することを可能にし、容易にする。情報テクノロジシステムで使用される一般的なリソースは、それを介してデータをコンピュータに渡し、コンピュータから渡すことができる入力機構および出力機構、それにデータを保存できるメモリストレージ、およびそれによって情報を処理できるプロセッサを含む。しばしば、情報テクノロジシステムは、一般に、データベースソフトウェアを介して容易にされる、後の取り出し、分析、および操作のためにデータを収集するのに使用される。情報テクノロジシステムは、ユーザがさまざまなシステムコンポーネントにアクセスし、操作することを可能にするインターフェースを提供する。

一実施形態で、ＴＡＳコントローラ１１０１は、ユーザ入力デバイス１１１１からの１つまたは複数のユーザ、周辺デバイス１１１２、暗号プロセッサデバイス１１２８、および／または通信ネットワーク１１１３などであるがこれらに限定はされないエンティティに接続され、かつ／または通信することができる。

ネットワークは、一般に、グラフトポロジでのクライアント、サーバ、および仲介ノードの相互接続および相互運用を含むと考えられる。用語「サーバ」は、本開示全体を通じて使用される時に、一般に、通信ネットワークを介してリモートユーザの要求を処理し、応答するコンピュータ、他のデバイス、ソフトウェア、またはこれらの組合せを指すことに留意されたい。サーバは、その情報を、要求する「クライアント」に供給する。用語「クライアント」は、本明細書で使用される時に、一般に、通信ネットワークを介して要求を処理し、行い、サーバから応答を入手し、処理することのできるコンピュータ、他のデバイス、ソフトウェア、またはこれらの組合せを指す。容易にし、情報および要求を処理し、かつ／またはソースユーザから宛先ユーザへの情報の通過を促進するコンピュータ、他のデバイス、ソフトウェア、またはこれらの組合せを、一般に、「ノード」と称する。ネットワークは、一般に、ソース点から宛先への情報の転送を容易にすると考えられる。特にソースから宛先への情報の通過を促進する仕事を割り当てられたノードを、一般に、「ルータ」と呼ぶ。ローカルエリアネットワーク（ＬＡＮ）、ピコネットワーク、広域ネットワーク（ＷＡＮ）、無線ネットワーク（ＷＬＡＮ）など、多数の形のネットワークがある。たとえば、インターネットは、これによってリモートクライアントおよびサーバが互いにアクセスし、相互運用できる、複数のネットワークの相互接続として一般に受け入れられている。

ＴＡＳコントローラ１１０１は、メモリ１１２９に接続されたコンピュータシステム化１１０２などのコンポーネントを含むことができるがこれらに限定はされないコンピュータシステムに基づくものとすることができる。

コンピュータシステム化
コンピュータシステム化１１０２は、クロック１１３０、中央処理装置（ＣＰＵ）１１０３、読み取り専用メモリ（ＲＯＭ）１１０６、ランダムアクセスメモリ（ＲＡＭ）１１０５、および／またはインターフェースバス１１０７を含むことができ、必ずではないが最も頻繁に、すべてがシステムバス１１０４を介して相互接続され、かつ／または通信している。オプションで、コンピュータシステム化を、内部電源１１８６に接続することができる。オプションで、暗号プロセッサ１１２６を、システムバスに接続することができる。システムクロックは、通常、水晶発振器を含み、ベース信号を提供する。クロックは、通常、システムバスおよびさまざまなクロックマルチプライヤに結合され、このクロックマルチプライヤは、コンピュータシステム化に相互接続された他のコンポーネントのためにベース動作周波数を高めるか下げる。クロックおよびコンピュータシステム化内のさまざまなコンポーネントは、システム全体を通じて情報を実施する信号を駆動する。コンピュータシステム化全体を通じて情報を実施する信号のそのような送出および受け取りを、一般に、通信と称することができる。これらの通信信号を、さらに、送出し、受け取ることができ、通信ネットワーク、入力デバイス、他のコンピュータシステム化、周辺デバイス、および／または類似物への現在のコンピュータシステム化を超えたリターン信号通信および応答信号通信の原因とすることができる。もちろん、上記のコンポーネントのいずれをも、互いに直接に接続し、ＣＰＵに接続し、かつ／またはさまざまなコンピュータシステムによって例示されるように、使用される多数の変形形態で編成することができる。

ＣＰＵは、ユーザおよび／またはシステムの生成する要求を実行するプログラムモジュールを実行するのに適当な少なくとも１つの高速データプロセッサを含む。ＣＰＵは、ＡＭＤ社のＡｔｈｌｏｎ、Ｄｕｒｏｎ、および／またはＯｐｔｅｒｏｎ、ＩＢＭ社および／またはＭｏｔｏｒｏｌａ社のＰｏｗｅｒＰＣ、Ｉｎｔｅｌ社のＣｅｌｅｒｏｎ、Ｉｔａｎｉｕｍ、Ｐｅｎｔｉｕｍ（登録商標）、Ｘｅｏｎ、および／またはＸＳｃａｌｅ、ならびに／あるいは類似するプロセッサ（１つまたは複数）などのマイクロプロセッサとすることができる。ＣＰＵは、従来のデータ処理技法に従ってストアドプログラムコードを実行するために導電導管を通過する信号を介してメモリと相互作用する。そのような信号通過は、ＴＡＳコントローラ内およびこれを超えるさまざまなインターフェースを介する通信を容易にする。処理要件が、より多くの量の速度を規定する場合に、並列アーキテクチャ、メインフレームアーキテクチャ、および／またはスーパーコンピュータアーキテクチャを、同様に使用することができる。代替案では、展開要件がより高いポータビリティを規定する場合に、より小さい携帯情報端末（ＰＤＡ）を使用することができる。

電源
電源１１８６は、アルカリ、リチウム水素、リチウムイオン、ニッケルカドミウム、太陽電池、および／または類似物などの動力電池など、小型電子回路基板デバイスに電力を与える任意の標準フォームを有するものとすることができる。他のタイプの交流電源または直流電源を使用することもできる。太陽電池の場合に、一実施形態で、ケースは、太陽電池がそれを介して光子エネルギを取り込むことができる開口部を提供する。動力電池１１８６は、ＴＡＳの相互接続された後続コンポーネントのうちの少なくとも１つに接続され、これによって、すべての後続コンポーネントに電流を供給する。一例で、電源１１８６は、システムバスコンポーネント１１０４に接続される。代替実施形態で、外部電源１１８６が、Ｉ／Ｏ １１０８インターフェースにまたがる接続を介して提供される。たとえば、ＵＳＢおよび／またはＩＥＥＥ １３９４接続は、その接続にまたがってデータと電力との両方を搬送し、したがって、適切な電力の源である。

インターフェースアダプタ
インターフェースバス（１つまたは複数）１１０７は、必ずではないが通常は入出力インターフェース（Ｉ／Ｏ）１１０８、ストレージインターフェース１１０９、ネットワークインターフェース１１１０、および／または類似物などであるがこれらに限定はされないアダプタカードの形の複数のインターフェースアダプタを受け入れ、接続し、かつ／または通信する。オプションで、暗号プロセッサインターフェース１１２７を、同様にインターフェースバスに接続することができる。インターフェースバスは、お互いとのならびにコンピュータシステム化の他のコンポーネントとのインターフェースアダプタの通信をもたらす。インターフェースアダプタは、互換インターフェースバス用に適合される。インターフェースアダプタは、従来、スロットアーキテクチャを介してインターフェースバスに接続される。Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）、Ｃａｒｄ Ｂｕｓ、（Ｅｘｔｅｎｄｅｄ）Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（（Ｅ）ＩＳＡ）、マイクロチャネルアーキテクチャ（ＭＣＡ）、ＮｕＢｕｓ、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（Ｅｘｔｅｎｄｅｄ）（ＰＣＩ（Ｘ））、ＰＣＩ Ｅｘｐｒｅｓｓ、Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ Ｍｅｍｏｒｙ Ｃａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ａｓｓｏｃｉａｔｉｏｎ（ＰＣＭＣＩＡ）、および／または類似物などであるがこれらに限定はされない従来のスロットアーキテクチャを使用することができる。

ストレージインターフェース１１０９は、ストレージデバイス１１１４、リムーバブルディスクデバイス、および／または類似物などであるがこれらに限定はされない複数のストレージデバイスを受け入れ、通信し、かつ／または接続することができる。ストレージインターフェースは、（Ｕｌｔｒａ）（Ｓｅｒｉａｌ）Ａｄｖａｎｃｅｄ Ｔｅｃｈｎｏｌｏｇｙ Ａｔｔａｃｈｍｅｎｔ（Ｐａｃｋｅｔ Ｉｎｔｅｒｆａｃｅ）（（Ｕｌｔｒａ）（Ｓｅｒｉａｌ）ＡＴＡ（ＰＩ））、（Ｅｎｈａｎｃｅｄ）Ｉｎｔｅｇｒａｔｅｄ Ｄｒｉｖｅ Ｅｌｅｃｔｒｏｎｉｃｓ（（Ｅ）ＩＤＥ）、Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ（ＩＥＥＥ） １３９４、ｆｉｂｅｒ ｃｈａｎｎｅｌ、Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅ（ＳＣＳＩ）、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ（ＵＳＢ）および／または類似物などであるがこれらに限定はされない接続プロトコルを使用することができる。

ネットワークインターフェース１１１０は、通信ネットワーク１１１３を受け入れ、通信し、かつ／または接続することができる。通信ネットワーク１１１３を介して、ＴＡＳコントローラは、ユーザ１１３３によってリモートクライアント（たとえば、ウェブブラウザを有するコンピュータ）を介してアクセス可能である。ネットワークインターフェースは、直接接続、イーサネット（登録商標）（シック、シン、より対線１０／１００／１０００ Ｂａｓｅ Ｔ、および／または類似物）、トークンリング、ＩＥＥＥ ８０２．１１ａ−ｘなどの無線接続、および／または類似物などであるがこれらに限定はされない接続プロトコルを使用することができる。通信ネットワークは、直接接続、インターネット、ローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、Ｏｐｅｒａｔｉｎｇ Ｍｉｓｓｉｏｎｓ ａｓ Ｎｏｄｅｓ ｏｎ ｔｈｅ Ｉｎｔｅｒｎｅｔ（ＯＭＮＩ）、保護されたカスタム接続、広域ネットワーク（ＷＡＮ）、無線ネットワーク（たとえば、Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＷＡＰ）、Ｉ−モード、および／または類似物などであるがこれらに限定はされないプロトコルを使用する）、および／または類似物のいずれかおよび／またはその組合せとすることができる。ネットワークインターフェースは、入出力インターフェースの特殊化された形と見なすことができる。さらに、複数のネットワークインターフェース１１１０を使用して、さまざまな通信ネットワークタイプ１１１３と係合することができる。たとえば、複数のネットワークインターフェースを使用して、ブロードキャストネットワーク、マルチキャストネットワーク、および／またはユニキャストネットワークを介する通信を可能にすることができる。

入出力インターフェース（Ｉ／Ｏ）１１０８は、ユーザ入力デバイス１１１１、周辺デバイス１１１２、暗号プロセッサデバイス１１２８、および／または類似物を受け入れ、通信し、かつ／または接続することができる。Ｉ／Ｏは、Ａｐｐｌｅ Ｄｅｓｋｔｏｐ Ｂｕｓ（ＡＤＢ）；Ａｐｐｌｅ Ｄｅｓｋｔｏｐ Ｃｏｎｎｅｃｔｏｒ（ＡＤＣ）；オーディオ：アナログ、ディジタル、モノラル、ＲＣＡ、ステレオ、および／または類似物；ＩＥＥＥ １３９４ａ−ｂ；赤外線；ジョイスティック；キーボード；ｍｉｄｉ；光；ＰＣ ＡＴ；ＰＳ／２；パラレル；ラジオ；シリアル；ＵＳＢ；ビデオインターフェース：ＢＮＣ、同軸、コンポジット、ディジタル、Ｄｉｇｉｔａｌ Ｖｉｓｕａｌ Ｉｎｔｅｒｆａｃｅ（ＤＶＩ）、ＲＣＡ、ＲＦアンテナ、Ｓ−Ｖｉｄｅｏ、ＶＧＡ、および／または類似物；無線；および／または類似物などであるがこれらに限定はされない接続プロトコルを使用することができる。一般的な出力デバイスは、ビデオインターフェースから信号を受け入れるテレビジョンセットである。また、ビデオインターフェースから信号を受け入れるインターフェース（たとえば、ＤＶＩ回路およびケーブル）を有する陰極線管（ＣＲＴ）ベースまたは液晶ディスプレイ（ＬＣＤ）ベースのモニタを通常は含むビデオディスプレイを使用することができる。ビデオインターフェースは、コンピュータシステム化によって生成された情報を合成し、ビデオメモリフレーム内の合成された情報に基づいてビデオ信号を生成する。通常、ビデオインターフェースは、ビデオディスプレイインターフェースを受け入れるビデオ接続インターフェース（たとえば、ＲＣＡコンポジットビデオケーブルを受け入れるＲＣＡコンポジットビデオコネクタ；ＤＶＩディスプレイケーブルを受け入れるＤＶＩコネクタなど）を介して、合成されたビデオ情報を提供する。

ユーザ入力デバイス１１１１は、カードリーダー、ドングル、指紋リーダー、グローブ、グラフィックスタブレット、ジョイスティック、キーボード、マウス、リモートコントロール、網膜リーダー、トラックボール、トラックパッド、および／または類似物とすることができる。

周辺デバイス１１１２は、ネットワークインターフェース、ストレージインターフェース、および／または類似物などのＩ／Ｏおよび／または類似物の他のファシリティに接続され、かつ／または通信することができる。周辺デバイスは、オーディオデバイス、カメラ、ドングル（たとえば、ディジタル署名を用いてセキュアトランザクションを保証するコピープロテクション用および／または類似物）、外部プロセッサ（追加機能性用）、ゴーグル、マイクロホン、モニタ、ネットワークインターフェース、プリンタ、スキャナ、ストレージデバイス、ビデオデバイス、ビデオソース、バイザ、および／または類似物とすることができる。

ユーザ入力デバイスおよび周辺デバイスを使用することができるが、ＴＡＳコントローラを、組込みデバイス、専用デバイス、および／またはモニタレス（すなわち、ヘッドレス）デバイスとして実施でき、ここで、アクセスが、ネットワークインターフェース接続を介して提供されることに留意されたい。

マイクロコントローラ、プロセッサ１１２６、インターフェース１１２７、および／またはデバイス１１２８などであるがこれらに限定はされない暗号ユニットが、ＴＡＳコントローラに接続され、かつ／またはＴＡＳコントローラと通信することができる。一般にＭｏｔｏｒｏｌａ Ｉｎｃ．社によって製造されるＭＣ６８ＨＣ１６マイクロコントローラを、暗号ユニット用におよび／または暗号ユニット内で使用することができる。同等のマイクロコントローラおよび／またはプロセッサを使用することもできる。ＭＣ６８ＨＣ１６マイクロコントローラは、１６ＭＨｚ構成で１６ビットｍｕｌｔｉｐｌｙ−ａｎｄ−ａｃｃｕｍｕｌａｔｅ命令を利用し、５１２ビットＲＳＡ秘密鍵動作を実行するのに１秒未満を必要とする。暗号ユニットは、対話するエージェントからの通信の認証ならびに匿名トランザクションを可能にすることをサポートする。暗号ユニットを、ＣＰＵの一部として構成することもできる。他の市販の特殊化された暗号プロセッサは、ＶＬＳＩ Ｔｅｃｈｎｏｌｏｇｙ社の３３ＭＨｚ ６８６８またはＳｅｍａｐｈｏｒｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ社の７４０ＭＨｚ Ｒｏａｄｒｕｎｎｅｒを含む。

メモリ
一般に、プロセッサが情報の格納および／または取り出しをもたらすことを可能にするすべての機構および／または実施形態は、メモリ１１２９と見なされる。しかし、メモリは、代替可能なテクノロジおよびリソースであり、したがって、任意の個数のメモリ実施形態を、互いの代わりにまたは互いと連繋して使用することができる。ＴＡＳコントローラおよび／またはコンピュータシステム化が、さまざまな形のメモリ１１２９を使用できることを理解されたい。たとえば、オンチップＣＰＵメモリ（たとえば、レジスタ）、ＲＡＭ、ＲＯＭ、および任意の他のストレージデバイスの機能性が、紙パンチテープまたは紙パンチカード機構によって提供されるコンピュータシステム化を構成することができ、もちろん、そのような実施形態は、極端に低速の動作をもたらすはずである。通常の構成では、メモリ１１２９は、ＲＯＭ ０６、ＲＡＭ ０５、およびストレージデバイス１１１４を含む。ストレージデバイス１１１４は、任意の従来のコンピュータシステムストレージとすることができる。ストレージデバイスは、ドラム、（固定および／またはリムーバブル）磁気ディスクドライブ、光磁気ドライブ、光ドライブ（すなわち、ＣＤ ＲＯＭ／ＲＡＭ／Ｒｅｃｏｒｄａｂｌｅ（Ｒ）、ＲｅＷｒｉｔａｂｌｅ（ＲＷ）、ＤＶＤ Ｒ／ＲＷなど）、および／または類似物の他のデバイスを含むことができる。したがって、コンピュータシステム化は、一般に、メモリを必要とし、メモリを利用する。

モジュールコレクション
メモリ１１２９は、オペレーティングシステムモジュール（１つまたは複数）１１１５（オペレーティングシステム）、情報サーバモジュール（１つまたは複数）１１１６（情報サーバ）、ユーザインターフェースモジュール（１つまたは複数）１１１７（ユーザインターフェース）、ウェブブラウザモジュール（１つまたは複数）１１１８（ウェブブラウザ）、データベース（１つまたは複数）１１１９、暗号サーバモジュール（１つまたは複数）１１２０（暗号サーバ）、ＴＡＳモジュール（１つまたは複数）１１３５、および／または類似物（すなわち、集合的にモジュールコレクション）などであるがこれらに限定はされないプログラムモジュールおよび／またはデータベースモジュールならびに／あるいはデータのコレクションを含むことができる。これらのモジュールを、ストレージデバイスおよび／またはインターフェースバスを介してアクセス可能なストレージデバイスに格納し、それからアクセスすることができる。モジュールコレクション内のソフトウェアモジュールなど、非従来のソフトウェアモジュールは、通常、ローカルストレージデバイス１１１４に格納されるが、周辺デバイス、ＲＡＭ、通信ネットワークを介するリモートストレージファシリティ、ＲＯＭ、さまざまな形のメモリ、および／または類似物などのメモリにロードし、かつ／または格納することもできる。

オペレーティングシステム
オペレーティングシステムモジュール１１１５は、ＴＡＳコントローラの動作を容易にする実行可能プログラムコードである。通常、オペレーティングシステムは、Ｉ／Ｏ、ネットワークインターフェース、周辺デバイス、ストレージデバイス、および／または類似物のアクセスを容易にする。オペレーティングシステムは、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ ＯＳ Ｘ（Ｓｅｒｖｅｒ）、ＡＴ＆Ｔ Ｐｌａｎ ９、Ｂｅ ＯＳ、Ｌｉｎｕｘ、Ｕｎｉｘ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標） Ｓｅｒｖｅｒ ２０００／２００３、および／または類似するオペレーティングシステムなど、非常にフォールトトレラント、スケーラブル、かつセキュアなシステムとすることができる。しかし、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ ＯＳ、Ｍｉｃｒｏｓｏｆｔ ＤＯＳ、Ｐａｌｍ ＯＳ、Ｗｉｎｄｏｗｓ（登録商標）２０００／３．１／９５／９８／ＣＥ／Ｍｉｌｌｅｎｉｕｍ／ＮＴ／ＸＰ／Ｖｉｓｔａ、および／または類似物など、より制限されたおよび／またはより非セキュアなオペレーティングシステムを使用することもできる。オペレーティングシステムは、それ自体および／または類似物を含むモジュールコレクション内の他のモジュールへおよび／またはこれらと通信することができる。最も頻繁に、オペレーティングシステムは、他のプログラムモジュール、ユーザインターフェース、および／または類似物と通信する。たとえば、オペレーティングシステムは、プログラムモジュール、システム、ユーザ、および／またはデータ通信、要求、および／または応答を含み、通信し、生成し、入手し、かつ／または提供することができる。オペレーティングシステムは、ＣＰＵによって実行されたならば、通信ネットワーク、データ、Ｉ／Ｏ、周辺デバイス、プログラムモジュール、メモリ、ユーザ入力デバイス、および／または類似物との相互作用を可能にすることができる。オペレーティングシステムは、ＴＡＳコントローラが通信ネットワーク１１１３を介して他のエンティティと通信することを可能にする通信プロトコルを提供することができる。マルチキャスト、ＴＣＰ／ＩＰ、ＵＤＰ、ユニキャスト、および／または類似物などであるがこれらに限定はされないさまざまな通信プロトコルを、航空会社輸送機構としてのＴＡＳコントローラによって相互作用に使用することができる。

情報サーバ
情報サーバモジュール１１１６は、ＣＰＵによって実行されるストアドプログラムコードである。情報サーバは、Ａｐａｃｈｅ Ｓｏｆｔｗａｒｅ Ｆｏｕｎｄａｔｉｏｎ社のＡｐａｃｈｅ、Ｍｉｃｒｏｓｏｆｔ社のＩｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｅｒ、および／または類似物などであるがこれらに限定はされない従来のインターネット情報サーバとすることができる。情報サーバは、Ａｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅ（ＡＳＰ）、ＡｃｔｉｖｅＸ、（ＡＮＳＩ）（Ｏｂｊｅｃｔｉｖｅ−）Ｃ（＋＋）、Ｃ＃、Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ（ＣＧＩ）スクリプト、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、Ｐｒａｃｔｉｃａｌ Ｅｘｔｒａｃｔｉｏｎ Ｒｅｐｏｒｔ Ｌａｎｇｕａｇｅ（ＰＥＲＬ）、Ｐｙｔｈｏｎ、ＷｅｂＯｂｊｅｃｔｓ、および／または類似物などのファシリティを介するプログラムモジュールの実行を可能にすることができる。情報サーバは、ファイル転送プロトコル（ＦＴＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、セキュアハイパーテキスト転送プロトコル（ＨＴＴＰＳ）、セキュアソケットレイヤ（ＳＳＬ）、および／または類似物などであるがこれらに限定はされないセキュア通信プロトコルをサポートすることができる。情報サーバは、ウェブページの形で結果をウェブブラウザに供給し、他のプログラムモジュールとの相互作用を介するウェブページの操作された生成を可能にする。ＨＴＴＰ要求のドメインネームシステム（ＤＮＳ）解決部分が特定の情報サーバに解決された後に、情報サーバは、ＨＴＴＰ要求の残りに基づいて、ＴＡＳコントローラ上の指定された位置の情報に関する要求を解決する。たとえば、ｈｔｔｐ：／／１２３．１２４．１２５．１２６／ｍｙＩｎｆｏｒｍａｔｉｏｎ．ｈｔｍｌなどの要求は、ＤＮＳサーバによってそのＩＰアドレスにある情報サーバに解決される要求のＩＰ部分「１２３．１２４．１２５．１２６」を有することができ、その情報サーバは、さらに、この要求の「／ｍｙＩｎｆｏｒｍａｔｉｏｎ．ｈｔｍｌ」部分についてｈｔｔｐ要求を解析し、これを情報「ｍｙＩｎｆｏｒｍａｔｉｏｎ．ｈｔｍｌ」を含むメモリ内の位置に解決することができる。さらに、たとえばポート７２１を介するＦＴＰ通信および／または類似物など、他の情報サービングプロトコルを、さまざまなポートにまたがって使用することができる。情報サーバは、それ自体および／または類似物のファシリティを含むモジュールコレクション内の他のモジュールへおよび／またはこれらと通信することができる。最も頻繁に、情報サーバは、ＴＡＳデータベース１１１９、オペレーティングシステム、他のプログラムモジュール、ユーザインターフェース、ウェブブラウザ、および／または類似物と通信する。

ＴＡＳデータベースへのアクセスは、下に列挙されたスクリプト言語（たとえば、ＣＧＩ）を介しておよび下に列挙されたアプリケーション間通信チャネル（たとえば、ＣＯＲＢＡ、ＷｅｂＯｂｊｅｃｔｓなど）を介してなど、複数のデータベースブリッジ機構を介して達成することができる。ウェブブラウザを介するデータ要求は、ブリッジ機構を介して、ＴＡＳによって要求される適当な文法に解析される。一実施形態で、情報サーバは、ウェブブラウザによってアクセス可能なウェブフォームを提供する。ウェブフォーム内で供給されるフィールドに行われる入力は、特定のフィールドに入力されたものとしてタグを付けられ、そのようなものして解析される。次に、入力された項目が、フィールドタグと一緒に渡され、このフィールドタグは、パーサに、適当なテーブルおよび／またはフィールドに向けられた照会を生成するように指示するように働く。一実施形態で、パーサは、タグ付けされたテキスト入力に基づいて、正しいｊｏｉｎ／ｓｅｌｅｃｔコマンドを有する検索文字列をインスタンス化することによって、標準ＳＱＬの照会を生成することができ、結果のコマンドは、ブリッジ機構を介してＴＡＳに照会として供給される。照会から照会結果を生成した時に、それらの結果は、ブリッジ機構を介して渡され、ブリッジ機構による新しい結果のウェブページのフォーマッティングおよび生成のために解析することができる。そのような新しい結果のウェブページは、その後、情報サーバに供給され、この情報サーバは、このウェブページを要求元のウェブブラウザに供給することができる。

また、情報サーバは、プログラムモジュール、システム、ユーザ、および／またはデータ通信、要求、および／または応答を含み、通信し、生成し、入手し、かつ／または提供することができる。

ユーザインターフェース
コンピュータインターフェースの機能は、いくつかの点で、自動車の運転インターフェースに似ている。ハンドル、ギアシフト、およびスピードメータなどの自動車運転インターフェース要素は、自動車のリソース、機能性、および状況へのアクセス、操作、および表示を容易にする。チェックボックス、カーソル、メニュー、スクローラ、およびウィンドウ（集合的に一般にウィジェットと称する）などのコンピュータ対話インターフェース要素は、同様に、データおよびコンピュータハードウェアおよびオペレーティングシステムリソース、機能性および状況のアクセス、操作、および表示を容易にする。操作インターフェースを、一般にユーザインターフェースと称する。Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ Ｏｐｅｒａｔｉｎｇ ＳｙｓｔｅｍのＡｑｕａ、Ｍｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓ（登録商標）ＸＰ、またはＵｎｉｘ（登録商標）のＸ−Ｗｉｎｄｏｗｓ（登録商標）などのグラフィカルユーザインターフェース（ＧＵＩ）は、情報にアクセスし、情報をグラフィカルにユーザに表示するベースラインおよび手段を提供する。

ユーザインターフェースモジュール１１１７は、ＣＰＵによって実行されるストアドプログラムコードである。ユーザインターフェースは、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ ＯＳ、たとえばＡｑｕａ、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）（ＮＴ／ＸＰ）、Ｕｎｉｘ（登録商標）Ｘ Ｗｉｎｄｏｗｓ（登録商標）（ＫＤＥ、Ｇｎｏｍｅ、および／または類似物）、ｍｙｔｈＴＶ、および／または類似物などのオペレーティングシステムおよび／またはオペレーティング環境によって、これらを用いて、および／またはこれらの上に提供される従来のグラフィカルユーザインターフェースとすることができる。ユーザインターフェースは、テキストファシリティおよび／またはグラフィカルファシリティを介するプログラムモジュールおよび／またはシステムファシリティの表示、実行、対話、操作、および／または動作を可能にすることができる。ユーザインターフェースは、ユーザがそれを介してコンピュータシステムに影響し、対話し、かつ／または操作することができるファシリティを提供する。ユーザインターフェースは、それ自体および／または類似物のファシリティを含むモジュールコレクション内の他のモジュールへおよび／またはこれと通信することができる。最も頻繁に、ユーザインターフェースは、オペレーティングシステム、他のプログラムモジュール、および／または類似物と通信する。ユーザインターフェースは、プログラムモジュール、システム、ユーザ、および／またはデータ通信、要求、および／または応答を含み、通信し、生成し、入手し、かつ／または提供することができる。

ウェブブラウザ
ウェブブラウザモジュール１１１８は、ＣＰＵによって実行されるストアドプログラムコードである。ウェブブラウザは、Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ ＥｘｐｌｏｒｅｒまたはＮｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒなどの従来のハイパーテキスト表示アプリケーションとすることができる。セキュアウェブブラウジングは、ＨＴＴＰＳ、ＳＳＬ、および／または類似物による１２８ビット（以上）の暗号化と共に供給することができる。一部のウェブブラウザは、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、ＡｃｔｉｖｅＸ、および／または類似物などのファシリティを介するプログラムモジュールの実行を可能にする。ウェブブラウザおよび類似する情報アクセスツールを、ＰＤＡ、セル電話機、および／または他のモバイルデバイスに一体化することができる。ウェブブラウザは、それ自体および／または類似物のファシリティを含むモジュールコレクション内の他のモジュールへおよび／またはこれと通信することができる。最も頻繁に、ウェブブラウザは、情報サーバ、オペレーティングシステム、一体化されたプログラムモジュール（たとえば、プラグイン）、および／または類似物と通信し、たとえば、プログラムモジュール、システム、ユーザ、および／またはデータ通信、要求、および／または応答を含み、通信し、生成し、入手し、かつ／または提供することができる。もちろん、ウェブブラウザおよび情報サーバの代わりに、両方の類似する機能を実行するために、組み合わされたアプリケーションを開発することができる。組み合わされたアプリケーションは、ＴＡＳ対応ノードからユーザ、ユーザエージェント、および／または類似物への情報の入手および提供に、類似して影響するはずである。組み合わされたアプリケーションは、標準ウェブブラウザを使用するシステム上では無意味である可能性がある。

暗号サーバ
暗号サーバモジュール１１２０は、ＣＰＵ１１０３、暗号プロセッサ１１２６、暗号プロセッサインターフェース１１２７、暗号プロセッサデバイス１１２８、および／または類似物によって実行されるストアドプログラムコードである。暗号プロセッサインターフェースは、暗号モジュールによる暗号化要求および／または暗号化解除要求の遠征を可能にすることができるが、暗号モジュールを、その代わりに、従来のＣＰＵ上で動作することができる。暗号モジュールは、供給されるデータの暗号化および／または暗号化解除を可能にする。暗号モジュールは、対称と非対称との両方の（たとえば、Ｐｒｅｔｔｙ Ｇｏｏｄ Ｐｒｏｔｅｃｔｉｏｎ（ＰＧＰ））暗号化および／または暗号化解除を可能にする。暗号モジュールは、ディジタル証明書（たとえば、Ｘ．５０９認証フレームワーク）、ディジタル署名、二重署名、エンベローピング、パスワードアクセス保護、公開鍵管理、および／または類似物などであるがこれらに限定はされない暗号技法を使用することができる。暗号モジュールは、チェックサム、Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ（ＤＥＳ）、楕円曲線暗号化（ＥＣＣ）、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ａｌｇｏｒｉｔｈｍ（ＩＤＥＡ）、Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ ５（ＭＤ５、一方向ハッシュ関数である）、パスワード、Ｒｉｖｅｓｔ Ｃｉｐｈｅｒ（ＲＣ５）、Ｒｉｊｎｄａｅｌ、ＲＳＡ（１９９７年にＲｏｎ Ｒｉｖｅｓｔ、Ａｄｉ Ｓｈａｍｉｒ、およびＬｅｏｎａｒｄ Ａｄｌｅｍａｎによって開発されたアルゴリズムを使用するインターネット暗号化および認証システムである）、Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ（ＳＨＡ）、セキュアソケットレイヤ（ＳＳＬ）、セキュアハイパーテキスト転送プロトコル（ＨＴＴＰＳ）、および／または類似物などであるがこれらに限定はされない多数の（暗号化および／または暗号化解除）セキュリティプロトコルを容易にする。そのような暗号化セキュリティプロトコルを使用することによって、ＴＡＳコントローラは、すべての着信通信および／または発信通信を暗号化することができ、より広い通信ネットワークを用いる仮想プライベートネットワーク（ＶＰＮ）内のノードとして働くことができる。暗号モジュールは、「セキュリティ認証」のプロセスを容易にし、これによって、リソースへのアクセスが、セキュリティプロトコルによって禁止され、暗号モジュールは、保護されたリソースへの許可されたアクセスをもたらす。さらに、暗号モジュールは、たとえばおよびＭＤ５ハッシュを使用してディジタルオーディオファイルの一意署名を入手することによって、内容の一意識別子を提供することができる。暗号モジュールは、それ自体および／または類似物のファシリティを含むモジュールコレクション内の他のモジュールへおよび／またはこれと通信することができる。暗号モジュールは、それが望まれる場合にＴＡＳモジュールがセキュアトランザクションにかかわることを可能にするために、通信ネットワークにまたがる情報のセキュア伝送を可能にする暗号化方式をサポートする。暗号モジュールは、ＴＡＳ上のリソースのセキュアアクセスを容易にし、リモートシステム上の保護されたリソースのアクセスを容易にする、すなわち、保護されたリソースのクライアントおよび／またはサーバとして働くことができる。最も頻繁に、暗号モジュールは、情報サーバ、オペレーティングシステム、他のプログラムモジュール、および／または類似物と通信する。暗号モジュールは、プログラムモジュール、システム、ユーザ、および／またはデータ通信、要求、および／または応答を含み、通信し、生成し、入手し、かつ／または提供することができる。

ＴＡＳデータベース
ＴＡＳデータベースモジュール１１１９は、データベースおよびその格納されたデータ内で実施することができる。データベースは、ＣＰＵによって実行されるストアドプログラムコードであり、ストアドプログラムコード部分は、格納されたデータを処理するようにＣＰＵを構成する。データベースは、ＯｒａｃｌｅまたはＳｙｂａｓｅなど、従来の、フォールトトレラント、リレーショナル、スケーラブル、セキュアデータベースとすることができる。リレーショナルデータベースは、フラットファイルの拡張である。リレーショナルデータベースは、一連の関係付けられたテーブルからなる。テーブルは、キーフィールドを介して相互接続される。キーフィールドの使用は、キーフィールドに対するインデクシングによるテーブルの組合せを可能にする、すなわち、キーフィールドは、さまざまなテーブルからの情報を組み合わせるための次元ピボット点として働く。関係は、一般に、主キーを照合することによってテーブル間で維持されるリンクを識別する。主キーは、リレーショナルデータベース内のテーブルの行を一意に識別するフィールドを表す。より正確には、主キーは、１対多関係の「１」側でテーブルの行を一意に識別する。

代替案では、ＴＡＳデータベースを、配列、ハッシュ、（リンク）リスト、構造体、構造化されたテキストファイル（たとえば、ＸＭＬ）、テーブル、および／または類似物などのさまざまな標準的なデータ構造を使用して実施することができる。そのようなデータ構造を、メモリおよび／または（構造化された）ファイルに格納することができる。もう１つの代替案では、Ｆｒｏｎｔｉｅｒ、ＯｂｊｅｃｔＳｔｏｒｅ、Ｐｏｅｔ、Ｚｏｐｅ、および／または類似物などのオブジェクト指向データベースを使用することができる。オブジェクトデータベースは、共通の属性によって一緒にグループ化されかつ／またはリンクされる複数のオブジェクトコレクションを含むことができ、オブジェクトコレクションは、ある共通の属性によって他のオブジェクトコレクションに関係付けることができる。オブジェクト指向データベースは、オブジェクトが単なるデータではなく、所与のオブジェクト内にカプセル化された他のタイプの機能性を有することができることを除いて、リレーショナルデータベースに似て実行する。ＴＡＳデータベースがデータ構造として実施される場合に、ＴＡＳデータベース１１１９の使用を、ＴＡＳモジュール１１３５などの別のモジュールに一体化することができる。また、データベースを、データ構造、オブジェクト、および関係構造の混合物として実施することができる。データベースを、標準的なデータ処理技法を介して、無数の変形形態で合併し、かつ／または分散させることができる。データベースの諸部分、たとえばテーブルを、エクスポートし、かつ／またはインポートし、したがって分散させ、かつ／または統合することができる。

一実施形態で、データベースモジュール１１１９は、複数のテーブル１１１９ａ〜ｃを含む。チャーターデータオブジェクトソーステーブル１１１９ａは、ソースＩＤ、好ましいフォーマッティング情報、対応する解析ルール、および／または航空会社情報、および／または類似物などであるがこれらに限定はされないフィールドを含む。チャーターデータ抽出ツールセットテーブル１１１９ｂは、解析優先順位、チャーターインジケータ情報、チャーター特性情報、スコアリングルールセット、および／または類似物などであるがこれらに限定はされないフィールドを含む。動的検索更新テーブル１１１９ｃは、最良一致検索結果、更新頻度データ、最初の検索要求パラメータ、代替検索結果パラメータおよび／または類似物などであるがこれらに限定はされないフィールドを含む。

一実施形態で、ＴＡＳデータベースは、他のデータベースシステムと相互作用することができる。たとえば、分散データベースシステムを使用すると、ＴＡＳモジュールによる照会およびデータアクセスは、ＴＡＳおよびＴＡＳデータベースの組合せを単一のデータベースエンティティとして扱うことができる。

一実施形態で、ユーザプログラムは、さまざまなユーザインターフェースプリミティブを含むことができ、このユーザインターフェースプリミティブは、ＴＡＳを更新するように働くことができる。また、さまざまなアカウントが、環境とＴＡＳがサービスする必要がある可能性があるクライアントのタイプとに応じて、カスタムデータベーステーブルを必要とする場合がある。任意の一意のフィールドを、終始、キーフィールドとして指定できることに留意されたい。代替実施形態では、これらのテーブルは、それ自体のデータベースおよびそれらのめいめいのデータベースコントローラ（すなわち、上記のテーブルのそれぞれのための個々のデータベースコントローラ）に分散されている。データ処理技法を使用すると、複数のコンピュータシステム化および／またはストレージデバイスにまたがってデータベースをさらに分散させることができる。同様に、分散されたデータベースコントローラの構成は、さまざまなデータベースモジュール１１１９ａ〜ｃを合併し、かつ／または分散させることによって変更することができる。ＴＡＳを、データベースコントローラを介してさまざまなセッティング、入力、およびパラメータを追跡するように構成することができる。

ＴＡＳデータベースは、それ自体および／または類似物のファシリティを含むモジュールコレクション内の他のモジュールへおよび／またはこれと通信することができる。最も頻繁に、ＴＡＳデータベースは、ＴＡＳモジュール、他のプログラムモジュール、および／または類似物と通信する。データベースは、他のノードおよびデータに関する情報を含み、保存し、提供することができる。

ＴＡＳ制御モジュール
ＴＡＳモジュール１１３５は、ＣＰＵによって実行されるストアドプログラムコードである。ＴＡＳ制御モジュールは、さまざまな通信ネットワークにまたがる情報、サービス、トランザクション、および／または類似物のアクセス、入手、および提供に影響する。

ＴＡＳモジュールは、ノードの間での情報のアクセスを可能にし、（ＡＮＳＩ）（Ｏｂｊｅｃｔｉｖｅ−）Ｃ（＋＋）、Ａｐａｃｈｅモジュール、バイナリ実行可能ファイル、データベースアダプタ、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、マッピングツール、手続き指向およびオブジェクト指向開発ツール、ＰＥＲＬ、Ｐｙｔｈｏｎ、シェルスクリプト、ＳＱＬコマンド、ウェブアプリケーションサーバエクステンション、ＷｅｂＯｂｊｅｃｔｓ、および／または類似物などであるがこれらに限定はされない標準開発ツールを使用することによって開発することができる。一実施形態で、ＴＡＳサーバは、暗号サーバを使用して通信を暗号化し、暗号化解除する。ＴＡＳモジュールは、それ自体および／または類似物のファシリティを含むモジュールコレクション内の他のモジュールへおよび／またはこれと通信することができる。最も頻繁に、ＴＡＳモジュールは、ＴＡＳデータベース、オペレーティングシステム、他のプログラムモジュール、および／または類似物と通信する。ＴＡＳは、プログラムモジュール、システム、ユーザ、および／またはデータ通信、要求、および／または応答を含み、通信し、生成し、入手し、かつ／または提供することができる。

分散ＴＡＳ
ＴＡＳノードコントローラコンポーネントのいずれかの構造および／または動作を、開発および／または展開を容易にするために任意の個数の形で組み合わせ、合併し、かつ／または分散させることができる。同様に、モジュールコレクションを、展開および／または開発を容易にするために任意の個数の形で組み合わせることができる。これを達成するために、コンポーネントを、共通のコードベース内にまたは統合された形でオンデマンドでコンポーネントを動的にロードできるファシリティ内に統合することができる。

モジュールコレクションを、標準的なデータ処理技法および／または開発技法を介して無数の変形形態で合併し、かつ／または分散させることができる。プログラムモジュールコレクション内のプログラムモジュールのうちの任意の１つの複数のインスタンスを、単一ノード上でおよび／または多数のノードにまたがってインスタンス化して、負荷平衡化技法および／またはデータ処理技法を介して性能を改善することができる。さらに、単一のインスタンスを、複数のコントローラおよび／またはストレージデバイス、たとえばデータベースにまたがって分散させることもできる。協調して働くすべてのプログラミングモジュールインスタンスおよびコントローラは、標準データ処理通信技法を介してそれを行うことができる。

ＴＡＳコントローラの構成は、システム展開のコンテキストに依存する。予算、容量、位置、および／または基礎になるハードウェアリソースの使用などであるがこれらに限定はされない要因が、展開の要件および構成に影響する可能性がある。構成がより合併されたおよび／または統合されたプログラムモジュールをもたらし、より分散された一連のプログラムモジュールをもたらし、かつ／または合併された構成と分散された構成との間のある組合せをもたらすかどうかにかかわりなく、データを、通信し、入手し、かつ／または提供することができる。プログラムモジュールコレクションから共通コードベースに合併されたモジュールのインスタンスは、データを通信し、入手し、かつ／または提供することができる。これは、データ参照（たとえば、ポインタ）、内部メッセージング、オブジェクトインスタンス変数通信、共有メモリ空間、変数渡し、および／または類似物などであるがこれらに限定はされないアプリケーション間データ処理通信技法を介して達成することができる。

モジュールコレクションコンポーネントが、離散的であり、別々であり、かつ／または互いの外部である場合に、他のモジュールコンポーネントとのおよび／または他のモジュールコンポーネントへのデータの通信、入手、および／または提供は、アプリケーションプログラムインターフェース（ＡＰＩ）情報渡し、（分散）Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ（（Ｄ）ＣＯＭ）、（分散）Ｏｂｊｅｃｔ Ｌｉｎｋｉｎｇ ａｎｄ Ｅｍｂｅｄｄｉｎｇ（（Ｄ）ＯＬＥ）、および／または類似物）、Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＣＯＲＢＡ）、プロセスパイプ、共有ファイル、および／または類似物などであるがこれらに限定はされないアプリケーション間データ処理通信技法を介して達成することができる。アプリケーション間通信のために離散モジュールコンポーネント間でまたはアプリケーション内通信のために単一モジュールのメモリ空間内で渡されるメッセージは、文法の作成および解析を介して容易にすることができる。文法は、ｌｅｘ、ｙａｃｃ、ＸＭＬ、および／または類似物などの標準開発ツールを使用することによって開発することができ、これらのツールは、文法生成および解析機能性を可能にし、この文法生成および解析機能性は、モジュール内およびモジュール間の通信メッセージの基礎を形成することができる。やはり、構成は、システム展開のコンテキストに依存する。

この開示の全体（カバーページ、名称、見出し、技術分野、背景技術、課題を解決するための手段、図面の簡単な説明、発明を実施するための最良の形態、特許請求の範囲、要約、図面、および他）は、請求される発明を実践できるさまざまな実施形態を例によって示すものである。この開示の利益および特徴は、実施形態の代表的サンプルのみのものであり、網羅的および／または排他的ではない。これらは、理解を助け、請求される原理を教示するためにのみ提示される。これらが、すべての請求される発明の代表ではないことを理解されたい。したがって、この開示のある種の態様は、本明細書では述べられていない。代替実施形態が、本発明の特定の部分について提示されていない可能性があること、または、さらなる説明されていない代替実施形態が、ある部分について使用可能である可能性があることは、これらの代替実施形態の棄権と解釈されてはならない。これらの説明されていない実施形態の多くが、本発明の同一の原理を組み込み、他の実施形態が、同等であることを了解されたい。したがって、本開示の範囲および／または趣旨から逸脱せずに、他の実施形態を利用でき、機能的、論理的、組織的、構造的、および／またはトポロジ的変更を行うことができることを理解されたい。したがって、すべての例および／または実施形態は、この開示全体を通じて非限定的と考えられる。また、本明細書で述べられていない実施形態に対する本明細書で述べられた実施形態に関する推断は、スペースと繰返しを減らすためにそうなっていることを除いて行ってはならない。たとえば、図面および／または本明細書全体に記載のすべてのプログラムモジュール（モジュールコレクション）、他のコンポーネント、および／またはすべての現在の特徴セットの任意の組合せの論理構造および／またはトポロジ的構造は、固定された動作順序および／または配置に限定されるのではなく、すべての開示された順序は、例示的であり、すべての同等物が、順序にかかわりなく、本開示によって企図されている。さらに、そのような特徴が、順次実行に限定されるのではなく、非同期に、並行に、並列に、同時に、同期式に、および／または類似物で実行できる任意の個数のスレッド、プロセス、サービス、サーバ、および／または類似物が、本開示によって企図されていることを理解されたい。したがって、これらの特徴の一部は、これらが単一の実施形態で同時に存在し得ないという点で、相互に矛盾する場合がある。同様に、いくつかの特徴は、本発明の一態様に適用可能であり、他の態様には適用不能である。さらに、本開示は、現在は請求されていない他の発明を含む。出願人は、これらの現在は請求されていない発明を請求し、追加の特許出願、継続出願、部分継続出願、分割出願、および／または類似物を出願する権利を含めて、そのような発明のすべての権利を留保する。したがって、本開示の利益、実施形態、例、機能的、特徴、論理的、組織的、構造的、トポロジ的、および／または他の態様を、特許請求の範囲によって定義される本開示に対する限定または特許請求の範囲の同等物に対する限定と考えてはならない。

このシステムの一実施態様による、システムコンポーネントおよびこのシステムと相互作用するエンティティの一部の諸態様を示す高水準コンポーネント図である。 このシステムの一実施態様による、チャーターデータ集約および管理プロセスの諸態様を示す高水準流れ図である。 このシステムのエアラインチャーターフライト実施態様でのチャーターデータ集約処理の諸態様を示す流れ図である。 このシステムによって受け取られるチャーターデータオブジェクトの例を示す図である。 このシステムの一実施態様によるチャーターデータオブジェクト処理プロセスの一態様を示す図である。 このシステムの一実施態様によるチャーターデータオブジェクト処理プロセスの一態様を示す図である。 このシステムの一実施態様によるチャーターデータオブジェクト処理プロセスの一態様を示す図である。 このシステムの一実施態様によるチャーターデータオブジェクト処理プロセスの一態様を示す図である。 このシステムの一実施態様によるチャーターデータオブジェクト処理プロセスの一態様を示す図である。 このシステムのチャーターフライトデータ実施態様のチャーターデータ検索要求管理の諸態様を示す流れ図である。 このシステムのエアラインチャーターフライト実施態様でこのシステムによって受け取られるチャーターデータ検索要求の例を示す図である。 このシステムの一実施態様によるチャーターデータ検索要求処理の一態様を示す図である。 このシステムの一実施態様によるチャーターデータ検索要求処理の一態様を示す図である。 このシステムの一実施態様によるチャーターデータ検索要求処理の一態様を示す図である。 このシステムの一実施態様によるチャーターデータ検索要求処理の一態様を示す図である。 このシステムの一実施態様によるチャーターデータ検索要求処理の一態様を示す図である。 このシステムの一実施態様による検索要求更新処理の諸態様を示す流れ図である。 このシステムの一実施態様によるテキスト検索結果データインターフェースの諸態様を示す図である。 このシステムの一実施態様によるビジュアル検索結果データインターフェースの諸態様を示す図である。 このシステムの一実施態様に関連するコンピュータシステム化の諸態様を示す図である。

Claims (42)

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. 前記プロセッサは、
    前記チャーターデータインジケータを出発時間データまたは目的時間データに相関させる
    プログラム命令をも実行することを特徴とする請求項２２に記載のシステム。
32. 前記プロセッサは、
    前記チャーターデータインジケータを航空会社機器データに相関させる
    プログラム命令をも実行することを特徴とする請求項２２に記載のシステム。
33. 処理されたチャーターデータを管理するシステムであって、
    プロセッサと通信し、プログラム命令を含むメモリと、
    前記プロセッサおよびメモリと通信する入力および出力と
    を含み、前記プロセッサは、前記メモリに含まれるプログラム命令を実行し、前記プログラム命令は、
    チャーターデータ検索要求を受け取ることと、
    前記チャーターデータ検索要求内のチャーターインジケータを識別することと、
    チャーター位置、時間、および機器要求情報を導出するために、前記チャーターデータ検索要求を処理することと、
    前記処理された要求情報を、最初の検索結果としてフライトデータレコードからの使用可能チャーターデータと相関させることと、
    前記検索要求に対する最良一致結果および前記最良一致に対する代替案を表示することと
    を含むことを特徴とするシステム。
34. 前記プロセッサは、
    動的周期的検索結果更新インジケータを受け取るプログラム命令と、
    最良一致結果パラメータおよび検索要求パラメータを格納するプログラム命令と、
    前記処理された要求情報を、２次検索結果としてフライトデータレコードからの使用可能チャーターデータとその後に周期的に再相関させるプログラム命令と、
    前記最初の検索結果を前記２次検索結果と比較するプログラム命令と、
    システムユーザは前記２次検索結果は前記最初の検索結果より近い一致として判定されることを通知するプログラム命令と
    をも実行することを特徴とする請求項３３に記載のシステム。
35. 前記チャーターデータ検索要求は、ビジュアルベースのチャーターデータ検索要求として構成されることを特徴とする請求項３３に記載のシステム。
36. 前記チャーターデータ検索要求は、テキストベースのチャーターデータ検索要求として構成されることを特徴とする請求項３３に記載のシステム。
37. 前記テキストベースのチャーターデータ検索要求は、構造化されていない要求文書であることを特徴とする請求項３６に記載のシステム。
38. 前記構造化されていない要求文書は、電子メールとして構成されることを特徴とする請求項３７に記載のシステム。
39. 前記相関プロセスは、使用可能な機器に基づいて前記識別された最良一致に関する代替案を識別することを含むことを特徴とする請求項３３に記載のシステム。
40. 前記相関プロセスは、使用可能な目的時間または出発時間に基づいて前記識別された最良一致に関する代替案を識別することを含むことを特徴とする請求項３３に記載のシステム。
41. 前記相関プロセスは、使用可能な目的位置または出発位置に基づいて前記識別された最良一致に関する代替案を識別することを含むことを特徴とする請求項３３に記載のシステム。
42. 前記相関プロセスは、改善された一致結果を作成するために再配置できる機器に基づいて前記識別された最良一致に関する代替案を識別することを含むことを特徴とする請求項３３に記載のシステム。

Images