JP2015228218A - コンテンツアクセス方法およびシステム - Google Patents

Abstract

【課題】1組のアプリケーション及び拡張されたレコードデータ構造を含むコンテンツ管理システムにおいて、コンテンツにアクセスする方法を提供する。【解決手段】拡張されたデータ構造は、標準的な種類の標準的なデータ要素を含む標準的なレコードデータ構造及び予め定義された標準的な種類とは異なる種類を有する非標準的なデータ要素を含む非標準的なレコードデータ構造を含む。拡張されたレコードデータ構造の1組の関連するデータ要素にアクセスするアプリケーションからの要求に応答する、1組の関連するデータ要素の中の各データ要素に関して、フィルタリング規則にしたがって、拡張されたレコードデータ構造のデータ要素に関連するデータコンテナの属性をフィルタリングするステップ805と、一意の抜粋の種類を割り振られ、データコンテナの1組の属性を含む抜粋のコンテナを生成するステップ806と、を含む。【選択図】図２０

Description

本発明は、概して、データ管理に関し、特に、コンテンツ管理システムにおいてコンテンツにアクセスするための方法、システム、およびコンピュータプログラム製品に関する。

コンテンツ管理システムは、専用の通信ネットワークを通じてシステムに接続された1つまたは複数のクライアント(例えば、末端の消費者)に特定のコンテンツへのアクセスを提供する可能性がある。

それぞれの産業の分野に非常に多くのコンテンツ流通プロバイダが現れたので、それぞれの消費者が一意のコンテンツ管理システムを通じて複数のコンテンツプロバイダにアクセスすることができる必要性が存在する。

例えば、旅行産業においては、旅行管理システム(travel management system)が、1組の旅行プロバイダシステム(コンテンツプロバイダ)から得られたコンテンツを複数の旅行代理店システム(コンテンツの消費者)に流通させるために使用され得る。旅行産業は過去数十年間に大きく成長しており、同じ時に、旅行産業によって提供されるサービスは大きく変わり、その結果、今や、多種多様なサービスが異種のコンテンツを要する末端の消費者に提供されている。さらに、現在、旅行産業は、旅行プロバイダから末端の消費者まで多数の参加者(player)を、それらの参加者の間で管理されるべき大量のデータとともに含む。旅行プロバイダと末端のユーザとの間に、グローバル流通システム(GDS)などの旅行仲介者が、旅行代理店がこれまでの旅行プロバイダ(航空会社プロバイダ)から情報を得るか、または末端の消費者とこれまでの旅行プロバイダとの間の取引を行うことを可能にする旅行管理システムを提供する。

純粋な航空輸送の流通に主眼を置いていた旅行代理店のビジネスモデルは、発展しており、今では、参加者は非航空関連コンテンツのおかげでより高い販売利益を生み出している。したがって、新しい種類の旅行プロバイダからの非常に重要なさまざまなサービスが、到着地で提案される。

そのような代替的な流通チャネルの魅力によって、旅行代理店は、通常のGDSコンテンツ(例えば、フライトまたは鉄道コンテンツ)の他にますます多くの非GDSコンテンツ(例えば、ホテル、レンタカーなど)を流通させる傾向がある。

しかし、通常の旅行管理システムは、非GDSコンテンツに関連する情報を旅行代理店に直接提供する適切な手段を提供しない。

図1に示されるように、概して、旅行管理システム1は、GDSコンテンツプロバイダ40から直接受信されたGDSコンテンツに関連するレコードを記憶するための「乗客名記録(Passenger Name Record)」データ構造900として知られるレコードデータ構造を含む。各レコード(PNR)は、レコードロケータによってデータベースDB内で特定される。そのとき、PNRレコードロケータは、GDSコンテンツにアクセスし、そのGDSコンテンツを旅行代理店または末端の消費者のシステム(60)などのクライアントデバイスに流通させるために使用され得る。

PNR 900データ構造は、所与の乗客または一緒に旅行する乗客のグループに関連する旅行データに関連してレコードロケータを保有する(レコードロケータは、確認番号、予約番号、確認コード、予約参照(booking reference)などとしても知られる)。例えば、乗客または乗客のグループに関して予約が行われるとき、PNRが、データ構造900で生成され、このPNRは、予約内容(例えば、到着時間、出発時間などのフライトデータなど)に対応するレコードロケータおよびデータを含む。

現在、旅行管理システムは、標準化の制約のため、非GDS旅行プロバイダ50から非GDSコンテンツを直接受信することができない。

さらに言えば、旅行管理システムが標準的な旅行プロバイダ(40)とやりとりする方法は、「ATA/IATA予約航空会社間メッセージ手順-乗客(ATA/IATA Reservations Interline Message Procedures - Passenger)」(AIRIMP)によって定義されたIATA(国際航空運送協会)によって定義された規則にしたがう。特に、標準的な旅行プロバイダ40と旅行コンテンツ管理エンジン30との間でやりとりされるメッセージは、IATA標準によって定義されたメッセージ交換フォーマットTTY(テレタイプ(Teletype)フォーマット)を満たさなければならず、通常のPNR 900は、そのようなTTYフォーマットで受信されたコンテンツのみを扱うように構成される。

いかなる業界標準も、PNR 900のレイアウトおよびコンテンツに関してそのように定義されていない。しかし、各旅行管理システム(例えばコンピュータ予約システム(Computer Reservation System)CRS)は、AIRIMPの制限および特にPNRデータをAIRIMPメッセージに簡単にマッピングする必要を考慮に入れる、PNRのレイアウトおよびコンテンツに関する独自仕様の標準を定義する。したがって、異なる旅行管理システムによって保有されるPNR 900のデータコンテンツおよびフォーマットについて多くの類似性が存在する。特に、各PNRデータ構造900は、レコードロケータに関連する旅行データがIATAによって標準化されたGDSコンテンツに対応するいくつかの予め定義された種類(フライトデータ、鉄道データなど)を満たさなければならないようなものである。

したがって、GDSコンテンツ(例えば、フライト、鉄道データ)のみが、IATAメッセージ交換標準に関連する制約を満たす静的なフォーマットでPNRデータ構造900に保有され得る。よって、非GDSコンテンツ(車のレンタル、ジェットスキーなど)に関するレコードを生成することは不可能である。

米国特許出願第2012259667号は、PNR 900に非GDSコンテンツを意見(remark)、その他(miscellaneous)、または架空セグメント(ghost segment)の形態で記憶するための解決策を提供する。しかし、そのような解決策は、旅行管理システムが、非標準的な旅行プロバイダから直接受信された非GDSコンテンツを構造化された方法でその他のGDS要素の中でPNR 900の前の動的にシームレスに記憶することを可能にしない。

したがって、通常の旅行管理システム1は、航空会社プロバイダなどのGDS旅行プロバイダからのコンテンツのみを扱う。通常の旅行管理システムは、非常に多くのアプリケーションを用いる旅行コンテンツ管理エンジン30を含み、各アプリケーションは、特定の旅行サービス(例えば、予約、ショッピング、価格決定など)に関連する。所与の旅行代理店Ai(70)からの要求に応じて、旅行コンテンツ管理エンジン30は、GDS旅行プロバイダ40からコンテンツを取得し、PNR 900のレコードを生成し、そのように生成されたPNRレコードの表現を旅行代理店Aiに返すことのみを行うことができる。

各旅行代理店は、非GDSコンテンツにアクセスする必要がある場合、1組の非GDSコンテンツプロバイダ50に直接接続されなければならず、一方、旅行管理システム1はGDSコンテンツプロバイダ40にのみ直接接続される。一方、各旅行代理店は、非GDS旅行コンテンツ(タクシー、エンターテインメントのチケットなど)を得るために特定の1組の旅行プロバイダ50に直接接続される。したがって、旅行コンテンツ管理エンジン30は、標準的な旅行プロバイダ40からの標準的な旅行コンテンツ(GDSコンテンツ)のみを扱いながら、n個の旅行サービスプラットフォーム(各旅行代理店A1からAnにつき1つのプラットフォーム2.1、2.2、...2.i、2.n)を公開する。

したがって、所与の旅行代理店Aiが非標準的な旅行プロバイダ50からの特定のコンテンツ(例えば、博物館のチケット発行)を望む場合、そのようなコンテンツは、旅行代理店Aiによって独自に実装(self-implement)されなければならない。そのような独自の実装は、旅行代理店にとって特にコストがかかり、複雑である。

さらに、通常の手法では、旅行管理システム100は、PNRコンテンツをローカルフォーマット(元のPNRコンテンツフォーマット)で記憶する。しかし、旅行管理システムは、PNRからのデータをPNRデータに関する独自のフォーマット(目標のPNRコンテンツフォーマット)を有するその他の外部システム(旅行プロバイダ、旅行代理店)とやりとりすることを要求される可能性がある。したがって、目標のシステムに応じて、目標のPNRコンテンツフォーマットへの旅行管理システムのPNRレコードに関連するPNRコンテンツの変換が、実行され得る。そのような変換は、現在、コストのかかる静的な手法でのハードコーディングおよび再コンパイルをともなう。同様に、旅行管理システム100内のPNRコンテンツを使用するアプリケーションフロー(application flow)において、PNRコンテンツを受信するアプリケーションフロー(一続きにされたアプリケーション)のそれぞれの内部アプリケーションは、PNRコンテンツを操作するためにそのPNRコンテンツをアプリケーションのフォーマットで変換することを要求される。したがって、一続きの各アプリケーションは、PNRコンテンツを読むまたは書くことができるようにそのPNRコンテンツを復号、検証、および符号化することを要求され、そのことは、手作業でコーディングされたコンポーネントを必要とし、コストがかかる。

さらに、通常の管理システムにおいて、PNRは、標準的な種類のコンテンツのみを操作するように現在構成されている非常に多くのアプリケーションによって使用され得る。したがって、新しいコンテンツの種類を操作することができるためには、現在、コストのかかる、コンテンツ管理システムのすべてのアプリケーションを再コーディングすることが必要とされる。

米国特許出願第2012259667号

したがって、コンテンツを動的にシームレスにやりとりするための改善されたコンテンツ管理システム、方法、およびコンピュータプログラム製品の必要性が存在する。

これらのおよびその他の問題に対処するために、添付の独立請求項1で定義されるコンテンツ管理方法と、添付の請求項14で定義されるコンテンツ管理システムとが提供される。好ましい実施形態が、従属請求項で定義される。

したがって、本発明のさまざまな実施形態による方法およびシステムは、新しい種類のコンテンツが拡張されたレコードデータ構造に追加される度にすべての内部アプリケーションを再コーディングする必要なしに、任意のアプリケーションが任意の種類のコンテンツに動的にアクセスすることを可能にする。

図面および詳細な説明を吟味すると、本発明のさらなる利点が当業者に明らかになるであろう。すべてのさらなる利点は本明細書に組み込まれることが意図される。

本明細書に組み込まれ、その一部をなす添付の図面は、本発明のさまざまな実施形態を示し、上で与えられた本発明の概説および以下で与えられる実施形態の詳細な説明と一緒に、本発明の実施形態を説明する働きをする。

従来技術による通常のコンテンツ管理システムの模式図である。 ネットワークを介して接続する複数のコンピューティングシステムを含む特定の実施形態によるコンテンツ管理システムの模式図である。 コンテンツ管理システムを含む例示的な動作環境の模式図である。 図2および図3の例示的なコンピューティングシステムの概略図である。 拡張されたレコードデータ構造に新しいコンテンツを追加するために実行され得るプロセスを示す流れ図である。 特定の実施形態によるコンテンツ管理システムで実行される内部アプリケーションの構造の模式図である。 ビジネスモデルオブジェクト(Business Model Object)型の技術的オブジェクト(technical object)に基づく内部アプリケーションの動作を示す概略図である。 内部アプリケーションの間の例示的なインタラクションを示すコンテンツ管理システムの模式図である。 1組のキー値によって定義される例示的な非標準的なデータコンテナの概略図である。 例示的なシリアル化フォーマットの概略図である。 種類の情報が非標準的なデータコンテナに含まれる図9の例示的な非標準的なデータコンテナの概略図である。 図11の非標準的なデータコンテナに関連する例示的な構造記述ファイルの概略図である。 アプリケーションによるコンテンツアクセスのために実行され得るプロセスの流れ図である。 例示的なコンテンツ交換ユニットの模式図である。 クライアントデバイスにコンテンツを送信するために実行され得るプロセスの流れ図である。 C型の標準的なデータコンテナのXSLT変換の概略図である。 図16の標準的なデータコンテナと同じC型の非標準的なデータコンテナのXSLT変換の概略図である。 1組の属性を含むD型の標準的なデータコンテナのXSLT変換の概略図である。 図18の標準的なデータコンテナの属性と同一のいくつかの属性を有するE型の非標準的なデータコンテナのXSLT変換の概略図である。 データ要素を再編成するために実行され得るプロセスの流れ図である。 特定の実施形態による拡張されたレコードデータ構造の模式図である。

本発明の実施形態による方法、システム、およびコンピュータプログラム製品は、コンテンツプロバイダから受信された任意の種類の(標準的および非標準的な)コンテンツの動的な管理を可能にし、コンテンツの種類が何であってもそのようなコンテンツに関連するレコードの集中的な記憶を可能にし得る。コンテンツ管理システム100は、クライアントの要求の受信を可能にするクライアント/サーバアーキテクチャに基づく可能性がある。

図2を参照すると、いくつかのユーザクライアント7が一意のプラットフォームを通じて1組のコンテンツプロバイダシステム4、5によって提供される任意の種類のコンテンツに直接アクセスし得るコンテンツ管理システム100が提供される。コンテンツ管理システム100によって扱われるコンテンツは、予め定義された標準化されたメッセージ交換フォーマットなどの第1の種類のメッセージ交換フォーマット14にしたがってコンテンツ管理システム100と通信する標準的なコンテンツプロバイダシステム4から、または第2の種類のメッセージ交換フォーマット15にしたがってコンテンツ管理システム100と通信する非標準的なコンテンツプロバイダシステム5から受信され得る。

コンテンツ管理システム100は、通信ネットワーク13に接続される可能性があり、通信ネットワーク13は、インターネット、ローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、セルラ音声/データネットワーク、1つもしくは複数の高速バス接続、および/またはその他のそのような種類の通信ネットワークを含む可能性がある。

コンテンツ管理システム100は、1つまたは複数の特定のサービス分野(例えば、旅行の分野)に専用である可能性がある。1つまたは複数のクライアントデバイス7は、ユーザが旅行管理システム100とのサービス要求セッションを初期化し、サービス要求に応答して旅行管理システム100からコンテンツを受信し得るように通信ネットワーク13にそれぞれ接続される可能性がある。

本発明の実施形態は、1つまたは複数のネットワーク化されたコンピュータまたはサーバを含むコンピューティングシステムによって実施され得る。コンピューティングシステムは、コンテンツ管理のための処理およびデータベース機能を提供し得る。

それぞれのクライアントデバイス7は、パーソナルコンピューティングデバイス、タブレットコンピュータ、シンクライアント端末、スマートフォン、および/またはその他のそのようなコンピューティングデバイスである可能性がある。それぞれのクライアントデバイス7は、ウェブブラウザおよび/またはカスタムアプリケーションソフトウェア(例えば、クライアントシステム)をホストする可能性があり、クライアントユーザインターフェースを含む可能性がある。

それぞれのコンテンツプロバイダシステム4または5は、通信ネットワーク13に接続され得る。それぞれのコンテンツプロバイダシステム4または5は、1つもしくは複数のウェブサイトをホストし、および/または1つもしくは複数のウェブサイトをホストするホスティングサービスを有する可能性がある。

クライアントデバイス7のうちの1つを操作するユーザ(すなわち、旅行者)は、(例えば、ウェブサービスに接続することによってアクセスされる)アプリケーションに関連するサービス要求セッション中にクライアントデバイス7を用いてコンテンツ管理システム100とインターフェースを取り得る。コンテンツ管理システム100は、クライアントデバイス7から受信されたサービス要求を処理するためのコンテンツ管理エンジン3を含む。

コンテンツ管理エンジン3は、IATA標準にしたがう標準化されたTTYメッセージ交換フォーマット(第1のメッセージ交換フォーマット14)を用いて標準的な旅行プロバイダ4とメッセージをやりとりし得る。

さらに、コンテンツ管理エンジン3は、データ交換ユニット11(この説明においては「コンテンツアクセスユニット」とも呼ばれる)を通じて非標準的なプロバイダ5とメッセージをやりとりし得る。データ交換ユニット11は、例えば、旅行代理店エンティティ(例えば、旅行代理店のオペレータまたは旅行代理店システム)に関連するユーザクライアント7からの検索、予約、価格決定、発行、取り消し要求に応答して、拡張可能マークアップ言語などのデータ記述言語によって定義されたメッセージ(第2のメッセージ交換フォーマット15)を用いて非標準的なコンテンツプロバイダと通信し得る。

ユーザは、(例えば、ウェブサービスの形式で)コンテンツ管理システム100で実行されるアプリケーションによってクライアントデバイス7で生成されたユーザグラフィカルインターフェースを通じてクライアントデバイス7において情報を入力することによりコンテンツ管理システム100にサービス要求を送り得る。ユーザから受け取られた情報は、(例えば、送る動作を実行することによって)ユーザがコンテンツ管理システム100にサービス要求を送るまで蓄積される可能性がある。

ユーザの要求に応答して、コンテンツ管理エンジン3は、メッセージ交換フォーマット14および/または15にしたがってコンテンツプロバイダシステム4および/または5からのコンテンツを要求し、取得し、取得されたコンテンツに関連するレコードを拡張されたレコードデータ構造9で記憶し得る。拡張されたレコードデータ構造9は、コンテキスト(context)に記憶され、保存要求に応じてまたは周期的に1つまたは複数のデータベース8に保存され得る。代替的に、特定の実施形態においては、拡張されたレコードデータ構造9が、1つまたは複数のデータベース8に直接記憶される可能性がある。

拡張されたレコードデータ構造9は、標準的なデータに関連してレコードを記憶するための標準的なレコードデータ構造90と、非標準的なデータに関連してレコードを記憶するための非標準的なレコードデータ構造91とを含む。

レコードは、関連するデータ要素に関連してレコード識別子(「レコードロケータ」とも呼ばれる)を含む。レコード識別子は、番号などの任意の種類および任意のフォーマットである可能性がある。

標準的なレコードデータ構造90は、予め定義された1組の属性の中の1つまたは複数の属性を有する予め定義された種類のコンテンツ(「標準的な」コンテンツと呼ばれる)に関するレコードを記憶するようにのみ適合されるので静的である。本明細書において使用されるとき、用語「標準的な」は、標準的なレコードデータ構造90によってサポートされるフォーマットおよび/または種類に対応する予め定義されたフォーマットおよび/または種類を有する標準的なコンテンツを指す。

受信されたコンテンツが標準的なデータ要素のみを含む場合、関連するデータ要素を含む受信されたコンテンツに関して、標準的なレコードデータ構造90にレコードが追加され得る。レコードは、データ要素に関連してレコード識別子を含む。

代替的に、受信されたコンテンツが非標準的なデータ要素のみを含む場合、関連するデータ要素を含む受信されたコンテンツに関して、非標準的なレコードデータ構造91にレコードが追加され得る。レコードは、非標準的なデータ要素を含む少なくとも1つの非標準的なデータコンテナに関連してレコード識別子を含む。

さらに、受信されたコンテンツが非標準的なデータ要素および標準的なレコードデータ構造90を含む場合、関連するデータ要素を含む受信されたコンテンツに関して、標準的なレコードデータ構造90および非標準的なレコードデータ構造91にレコードが追加され得る。標準的なレコードデータ構造90および非標準的なレコードデータ構造91内の受信されたコンテンツに関する追加された2つのレコードは、両方とも、同じレコード識別子(以降、「共通レコード識別子」と呼ばれる)を割り振られる可能性がある。共通レコード識別子は、標準的なレコードデータ構造90内の1つもしくは複数の標準的なデータ要素(標準的なコンテンツ)および/または非標準的なレコードデータ構造91内の(非標準的なデータ要素を含む)1つもしくは複数の非標準的なデータコンテナの間で共有される。

両方のレコードデータ構造90および91で同じレコード識別子を用いて関連する標準的なおよび非標準的なデータ要素を特定することによって、コンテンツ管理システム100は、2つのレコードデータ構造が一意のレコードデータ構造を形成するかのようにそれらの2つのレコードデータ構造を透過的に管理し得る。

コンテンツ管理エンジン3は、異なるサービスに関連するいくつかのアプリケーションを保有する可能性がある。コンテンツ管理エンジン3は、コンテンツプロバイダシステムからのコンテンツの取得とそのような受信されたコンテンツに関連するレコードの拡張されたデータ構造9への記憶とをトリガし得るクライアントデバイス7から受信されたサービス要求に応じて1つまたは複数のアプリケーションを実行することができる。コンテンツ管理エンジンは、レコードデータ構造9に記録されたコンテンツを用いるユーザクライアントに、コンテンツの種類が何であれ、拡張されたレコードデータ構造9に記憶されたレコードに基づいてサービス要求に対する応答を返すようにさらに構成され得る。クライアントに応答を返すために、コンテンツ管理エンジン3は、拡張されたレコードデータ構造9から取得されたレコードに含まれるコンテンツの種類が何であれ、クライアントデバイス7でコンテンツの一定の表現を生成するためにデータ交換ユニット11を使用し得る。したがって、コンテンツ管理エンジン3は、ユーザクライアント7にサービスを提供するアプリケーションアグリゲータ(application aggregator)として働く。

本発明の好ましい実施形態において、コンテンツ管理システム100は、旅行管理システムである可能性がある。旅行管理システム100は、例えば、GDS(「グローバル流通システム」の頭字語)で実施される旅行コンテンツの集中的な管理を可能にするために仲介者(例えば、旅行の分野においてはグローバル流通システム(GDS))によって実装され得る。

図3は、GDS 1で実装されるそのような管理システム100の例示的な動作環境10を示す。そのような実施形態において、標準的なコンテンツは、標準的な旅行プロバイダシステム4によって提供される(フライト、鉄道コンテンツなどの)IATAの制約に準拠するGDSコンテンツを指し、一方、非標準的なコンテンツは、非標準的な旅行プロバイダシステム5によって提供されるか、またはGDSの外部で予約されるIATAの制約を満たさない任意の種類の非GDSコンテンツ(例えば、車のレンタル)である可能性がある。標準的なレコードデータ構造90は、標準的なコンテンツを記憶するように構成される標準的なPNRデータ構造(以降、「標準的なPNR」と呼ばれ、PNRは乗客名記録の頭字語である)である可能性があり、一方、非標準的なレコードデータ構造91(以降、「非標準的なPNR」とも呼ばれる)は、データマッピングおよびコンパイルメカニズムをハードコーディングすることによって非標準的なコンテンツの種類および属性を予め定義する必要なしに任意の種類の非標準的なコンテンツを動的に記録するように構成される。概して、標準的なPNR 90は、予め定義されたデータ構造(種類、属性、系統(family))を用いる複数の輸送会社、ならびに/またはホテルおよびレンタカーの予約などの旅行を含むその他の旅行サービスからのセグメント(segment)を含む旅程に関するデータの完全な組を含む。

拡張されたレコードデータ構造9は、それぞれのコンテンツレコードがレコードに関連するコンテンツの種類が何であれコンテンツ管理エンジン3によってシームレスに操作され得る拡張された旅行レコード(以降、「ETR」とも呼ばれる)を形成する。

クライアントデバイス7は、それぞれのクライアントインターフェース2を通じてサービスを要求する複数の旅行代理店システム70に関連付けられ得る。より広く、旅行管理システム100は、(例えば、拡張された旅行レコード9に記憶されるコンテンツをやりとりするために)それぞれのユーザインターフェース2を通じた旅行者のデバイス6またはそれどころか旅行プロバイダシステム4もしくは5などの、クライアント/サーバの手法によって異なる種類の要求を送る異なる種類のクライアントデバイスによってやはりアクセスされ得る。

標準的な旅行プロバイダシステム4は、複数の輸送会社のシステムまたは旅行者のシステムを含む可能性がある。非標準的な旅行商品プロバイダシステム5は、自動車レンタルシステム、博物館予約システムなどを含む可能性がある。実装されるとき、輸送会社のシステムは、GDS 1を可能にするそれぞれの航空会社のためのコンピュータ予約システム(CRS)および/または課金システムを含む可能性がある。旅行代理店システム70は、非標準的な旅行プロバイダ5によって提供される旅行チケットおよび/または追加的なサービスを予約し、支払いをするように構成され得る。また、一部の標準的な旅行プロバイダシステム4は、検証輸送会社(validating carrier)が運行輸送会社(operating carrier)によって提供される座席のチケットを販売することを可能にするために、直接かまたはGDS 1を通じてかのどちらかで互いにインタラクションし得る。そのとき、運行輸送会社は、提供されたサービスに関して検証輸送会社に請求を行い得る。

GDS 1は、旅行代理店、検証輸送会社、またはその他の間接的な販売業者がGDS 1を介して1つまたは複数の輸送会社システム4で利用可能なセグメントを探し、予約を行い、追加的なサービス(例えば、車のレンタル、博物館のチケットなど)を探し、予約することを可能にすることによって、旅行プロバイダ4および5と旅行代理店システム70との間の通信を容易にするように構成され得る。

各旅行代理店システム70は、公的にアクセスされ得るウェブサイトを提供するウェブサーバを含み得る。このウェブサイトは、旅行の要求に合致する旅行商品を探す能力などの旅行を計画する特徴へのアクセスを提供するように構成され得る。この目的で、旅行代理店システム70は、GDS 1、旅行プロバイダ4および5、ならびに旅行代理店システム70によってホストされる1つまたは複数のデータベースのデータに旅行者がアクセスすることができるように提供し得る。本発明の代替的な実施形態においては、旅行代理店システム70は、旅行サービスプロバイダまたは旅行代理店にアクセスを制限する独自仕様のシステムである可能性があり、その場合、アクセスは、非公開のウェブサイトまたはその他のアプリケーションを通じて提供される可能性がある。

旅行者または旅行代理店は、旅行代理店システム70を用いて、特定の旅行アプリケーション(例えば、旅行計画アプリケーション)を使用して旅行者から受け取られた旅行の要求を満足する旅行の提案を生成するおよび/または探すことができる。

旅行者のデバイス6は、パブリックまたはプライベートネットワーク13(例えば、インターネット)を通じて旅行管理システム100に直接接続され得る。旅行者のデバイス6は、ネットワーク13を介して旅行管理システム100と通信するように構成された任意の好適なコンピューティングシステムである可能性がある。例えば、旅行者のデバイス6は、旅行者がネットワーク20を介して旅行サービスを探し、予約することを可能にするデスクトップ、ラップトップ、もしくはタブレットコンピュータ、スマートフォン、または任意のその他のコンピューティングデバイスを含み得る。本発明の一実施形態において、旅行者のデバイス6は、ウェブサービスアプリケーションに応じて旅行の要求を送るために旅行管理システム100のコンテンツ管理エンジン3によってホストされるウェブサービスアプリケーションと通信するウェブブラウザアプリケーションを含み得る。

代替的に、旅行者のデバイス6は、旅行代理店システム70によってホストされるウェブサービスアプリケーションと通信するウェブブラウザアプリケーションを含み得る。さらに、ウェブサービスアプリケーションは、旅行サービスアプリケーションに応じて旅行の要求を送るために旅行管理システム100と通信し得る。

旅行の要求は、例えば、GDS 1または別のGDSを通じて提供される旅行に関連して、利用可能な旅行のセグメントに関連するデータを取得し、旅行の要求を満たす旅行の提案を生成し、および/または非標準的なプロバイダ5によって提供される非標準的なコンテンツに対応する付加的なサービス(例えば、車のレンタル、ジェットスキーの予約、博物館のチケットの予約など)を予約するために送られる可能性がある。

ここで図4を参照すると、動作環境10のGDS 1、旅行管理システム100、旅行プロバイダシステム4および5、旅行代理店システム70、旅行者のデバイス6が、コンピュータ30などのコンピュータと集合的に呼ばれる1つまたは複数のコンピューティングデバイスまたはシステムで実装され得る。コンピュータ30は、プロセッサ32、メモリ34、大容量記憶メモリデバイス36、入力/出力(I/O)インターフェース38、およびヒューマンマシンインターフェース(HMI)40を含み得る。また、コンピュータ30は、ネットワーク22および/またはI/Oインターフェース38を介して1つまたは複数の外部リソース42に動作可能なように結合され得る。外部リソースは、コンピュータ30によって使用され得るサーバ、データベース、大容量記憶デバイス、周辺デバイス、クラウドに基づくネットワークサービス、または任意のその他の好適なコンピューティングリソースを含み得るがこれらに限定されない。

プロセッサ32は、メモリ34に記憶される動作命令に基づいて(アナログまたはデジタル)信号を操作するマイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、マイクロコンピュータ、中央演算処理装置、フィールドプログラマブルゲートアレイ、プログラマブルロジックデバイス、状態機械、論理回路、アナログ回路、デジタル回路、または任意のその他のデバイスから選択される1つまたは複数のデバイスを含み得る。メモリ34は、読み出し専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、揮発性メモリ、不揮発性メモリ、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリ(DRAM)、フラッシュメモリ、キャッシュメモリ、または情報を記憶することができる任意のその他のデバイスを含むがこれらに限定されない単一のメモリデバイスまたは複数のメモリデバイスを含み得る。大容量記憶メモリデバイス36は、ハードドライブ、光学式ドライブ、テープドライブ、不揮発性ソリッドステートデバイス、または情報を記憶することができる任意のその他のデバイスなどのデータ記憶デバイスを含み得る。データベース44は、大容量記憶メモリデバイス36に存在する可能性があり、本明細書において説明されるさまざまなシステムおよびモジュールによって使用されるデータを収集し、組織化するために使用され得る。

プロセッサ32は、メモリ34に存在するオペレーティングシステム46の制御の下で動作し得る。オペレーティングシステム46は、メモリ34に存在するアプリケーション48などの1つまたは複数のコンピュータソフトウェアアプリケーションとして具現化されるコンピュータプログラムコードがプロセッサ32によって実行される命令を有するようにコンピューティングリソースを管理し得る。代替的な実施形態においては、プロセッサ32がアプリケーション48を直接実行する可能性があり、その場合、オペレーティングシステム46は省かれ得る。1つまたは複数のデータ構造50もメモリ34に存在する可能性があり、データを記憶または操作するためにプロセッサ32、オペレーティングシステム46、および/またはアプリケーション48によって使用され得る。

I/Oインターフェース38は、ネットワーク22および/または外部リソース42などのその他のデバイスおよびシステムにプロセッサ32を動作可能なように結合するマシンインターフェースを提供し得る。それによって、アプリケーション48は、I/Oインターフェース38を介して通信することによってネットワーク22および/または外部リソース42と協力して働いて、本発明の実施形態を構成するさまざまな特徴、機能、アプリケーション、プロセス、および/またはモジュールを提供し得る。また、アプリケーション48は、1つもしくは複数の外部リソース42によって実行されるプログラムコードを有するか、またはそうでなければコンピュータ30の外部のその他のシステムもしくはネットワーク構成要素によって提供される機能および/もしくは信号に頼る可能性がある。さらに言えば、ほとんど際限のないハードウェアおよびソフトウェア構成が可能であることを考慮すると、当業者は、本発明の実施形態が、コンピュータ30の外部に置かれるか、複数のコンピュータもしくはその他の外部リソース42に分散されるか、またはクラウドコンピューティングサービスなどのネットワーク22を介したサービスとして提供されるコンピューティングリソース(ハードウェアおよびソフトウェア)によって提供されるアプリケーションを含み得ることを理解するであろう。

HMI 40は、コンピュータ30のユーザがコンピュータ30と直接インタラクションすることを可能にする知られている方法でコンピュータ30のプロセッサ32に動作可能なように結合され得る。HMI 40は、映像および/もしくは英数字ディスプレイ、タッチスクリーン、スピーカ、ならびにユーザに情報を提供することができる任意のその他の好適な音声および視覚的インジケータを含み得る。HMI 40は、ユーザからコマンドまたは入力を受け付け、入力された入力をプロセッサ32に送信することができる英数字キーボード、ポインティングデバイス、キーパッド、押しボタン、制御つまみ、マイクロホンなどの入力デバイスおよび制御装置も含み得る。

以下の説明は、例示のみを目的として図3のコンテンツ管理システム100を参照してなされる。

それぞれの旅行代理店システム70を通じて旅行管理システム100に接続された異なる旅行代理店は、したがって、(標準的な航空会社のコンテンツ、タクシー、エンターテインメントのチケットなど)コンテンツの種類が何であれ、1組の旅行プロバイダシステム(4、5)によって提供される任意の種類のコンテンツに一意のプラットフォームを通じて直接アクセスすることができる。よって、旅行管理システム100は、標準的なPNRデータ構造90に準拠する標準的なコンテンツのみでなく、任意の新しい種類のコンテンツ(すなわち、タクシーのコース、劇場のチケット、コンサート、おいしい食べ物など)も記憶する可能性を、旅行代理店が電話またはインターネットを介してなどによってGDSシステムの外部のそのような非標準的なコンテンツを予約する必要をなくしながら提供する。

非標準的なPNR 91を標準的なPNR 90の後ろに付け加えることによって、旅行管理システムは、無制限の数の旅行サービスを旅行代理店システム70に動的にシームレスに提供することができる。

したがって、2つの要素がある拡張された旅行レコード9は、ETR 9に保有されるレコードが標準的なPNR 90および非標準的なPNR 91が一意のレコードデータ構造を形成するかのようにアクセスされ、管理される可能性がありつつ、任意の旅行プロバイダシステム4または5によって供給されるコンテンツ(そのコンテンツは、例えば、GDSの外部で予約される商品に対応する可能性がある)の構造化された表現を形成する。

標準的なPNR 90内の標準的なデータ要素(例えば、商品)は、IATA標準に準拠するようにGDS 1によって実装された標準的なレイアウトおよびフォーマットにしたがって任意または必須と認定される可能性がある1組の属性に関連付けられる。

拡張された旅行レコード9に保有されるデータは、複数の系統に分類される可能性があり、各系統は、例えば、表1に示される5つの系統などのいくつかのデータ要素の種類を含む。ETR 9は、任意の数の新しいデータ要素の種類および系統をサポートするように適合される。

コンテンツ管理エンジン3は、ETR 9の異種のコンテンツを管理するように構成され、それは、以下を含み得る。
- 例えば、旅行代理店システム70からの要求に応じて、コンテンツの種類が何であれ、任意の旅行プロバイダシステム4または5からの新しいデータ要素を拡張された旅行レコード9に追加すること
- (例えば、博物館の2回の入場の事前予約に対応する「博物館」商品の開始日を変更することによって)拡張された旅行レコード9内のデータ要素を修正すること
- (例えば、ユーザがそのユーザのニューヨークへの旅行から商品「博物館」を削除すると決めた場合に、拡張された旅行レコードからこの商品の予約を削除することによって)拡張された旅行レコード9からデータ要素を削除すること
- (例えば、特定の旅行レコードの「博物館」商品のすべての構造化された属性を取得することによって)拡張された旅行レコード9からデータ要素を取得すること。

したがって、拡張された旅行レコード(9)は、非標準的なコンテンツと標準的なコンテンツとの両方をそれらが一意のレコードデータ構造(PNR)の一部であるかのように記憶し得る。コンテンツ管理エンジン3は、拡張された旅行レコード9に保有される異種のコンテンツをユーザクライアントに対して透過的に管理する。拡張された旅行レコード9は、さらに柔軟であり、新しいコンテンツに関連する属性が何であれ任意の種類の新しいコンテンツ(タクシー、地下鉄、バス、博物館のチケット発行など)に適合される。

標準的なPNR 90は、IATA標準にしたがって組織化される。所与の1組のデータ要素が所与のサービスに関連するアプリケーションフロー(例えば、予約管理フロー)で第1のメッセージ交換フォーマット14によるメッセージを通じて標準的な旅行プロバイダシステム4からコンテンツ管理エンジン3に送信されるとき、以下のステップが、コンテンツ管理エンジン3によって実行され得る。
i. 標準的な旅行プロバイダシステム4によって送信された到着するメッセージからコンテンツ管理エンジン3によってデータが抽出され得る
ii. 標準的なPNR 90にレコードが追加される可能性があり、レコードは、コンテンツ管理エンジン3によって抽出されたデータ(コンテンツデータ)に対応するデータ要素に関連してレコード識別子を含む。

したがって、得られたデータは、アプリケーションフローの次のアプリケーションに送信されることになる別のメッセージを構築するために使用され得る。

アプリケーションフローが1組の一続きにされた内部アプリケーションを含むとき、ステップi.が、アプリケーションフローの所与の内部アプリケーションによって実行され得る一方、ステップii.は、フローの別のアプリケーションによってトリガされ得る。

標準的なPNR 90に追加されるデータは、制限された数の予め定義された属性のみを持つことができ、1つまたは複数の予め定義された種類およびフォーマット(標準化された属性)を満たさなければならない。

非標準的なPNR 91は、標準の規則および従来からの制約(IATAのコンテンツの定義、TTYメッセージ、IATAメッセージ)に準拠しない。しかし、非標準的なコンテンツは、拡張された旅行レコード9の一部であり、コンテンツ管理エンジン3によって実行されるアプリケーションによってシームレスに透過的にアクセスされ得る。

したがって、拡張された旅行レコード9は、任意の種類の標準的なコンテンツ(例えば、フライト、ホテル、車、クルージング、保険、フェリーなどのGDSコンテンツ)および非標準的なコンテンツ(バス/タクシー/レストラン/他など)を構造化された方法で、普遍的なフォーマットで記憶し得る。

任意の種類のコンテンツを動的に管理するために、コンテンツ管理エンジン3は、非標準的なコンテンツプロバイダシステム5から旅行管理システム100に送信された非標準的なデータ要素を含む受信されたコンテンツに応じて非標準的なデータコンテナを生成するように構成される。非標準的なデータコンテナは、非標準的なデータコンテナの自己シリアル化特性によって、データ要素を受信するコンテンツ管理システムの内部アプリケーションのフォーマットに動的に適合し得る。受信する内部アプリケーションが1組の一続きにされたアプリケーション(内部アプリケーション)を含むアプリケーションフローのアプリケーションであるとき、非標準的なデータコンテナは、非標準的なデータコンテナの自己シリアル化特性を用いて、その非標準的なデータコンテナが送信されるそれぞれの内部アプリケーションのフォーマットに動的に適合し得る。

より詳細には、旅行管理システム100が、非標準的なコンテンツの種類を提供する新しい旅行プロバイダ5に接続するとき、非標準的なコンテンツプロバイダシステム5から受信された非標準的なデータ要素が、非標準的なコンテンツの種類に割り振られたそのような非標準的なデータコンテナに記憶される。そして、レコードが、(例えば、アプリケーションフローの)内部アプリケーションによって非標準的なレコードデータ構造91に追加され得る。レコードは、レコード識別子と、非標準的なコンテンツの種類を有する非標準的なデータコンテナとを含み得る。非標準的なデータコンテナは、属性のリストを含む可能性があり、各属性は、キーおよび値によって表される。各属性は、それ自体が、(下位属性などに関してと同様に)キーおよび値によってそれぞれ表される下位属性のリストを含む可能性がある。それぞれの属性のキーは、名前および種類に関連付けられる。非標準的なデータコンテナは、その非標準的なデータコンテナが表す構造またはその非標準的なデータコンテナが含むデータが何であれその非標準的なデータコンテナ自体を自己実装(self-implement)するように構成され、つまり、非標準的なデータコンテナの一部である任意の属性の任意の値の読み取りのみのアクセスまたは読み取り/書き込みアクセス(すなわち、ゲットまたはセット)に関して、非標準的なデータコンテナは、ハードコーディングによってゲッタ/セッタ(getter/setter)メソッドを実装する必要なしに、キーの名前にもキーの種類にも依存せずに、メソッドを介してそのようなアクセスを可能にする。

したがって、非標準的なデータコンテナは、コンテンツの種類が何であれ、非標準的なPNR 91で新しいレコードを生成するために使用され得る。そのようなレコードは、任意の種類のコンテンツ管理動作のため、例えば、旅行アプリケーションを実行するか、クライアントデバイス7に対するサービス要求の結果の表示を生成するか、または外部デバイス(例えば、旅行プロバイダシステムもしくは旅行デバイス)にコンテンツを送信するためにコンテンツ管理エンジン3によって透過的にアクセスされ得る。

ここで図5を参照すると、1つまたは複数の旅行プロバイダシステムから受信されたコンテンツに応じて拡張された旅行レコード9で新しいレコードを生成するためのプロセスを示す流れ図が示されている。

ブロック501において、コンテンツ管理エンジン3が、例えば、旅行代理店システムなどのクライアントデバイス7からのサービス要求に応じてメッセージ交換フォーマット14および/または15によって1つまたは複数の旅行プロバイダ4、5からコンテンツを受信し得る。

コンテンツは、複数の関連するデータ要素、例えば、逐次的に受信されるフライト商品(標準的なデータ要素)およびタクシー商品(非標準的なコンテンツ)などの同じ旅行に関連するデータ要素を含み得る。共通のコンテンツに関連するデータ要素は、逐次的にまたは並列的に受信され得る。データ要素は、それらのデータ要素が同じ共通のコンテンツの一部であると特定するための情報を含み得る。

データ要素は、標準的なデータ要素(例えば、フライト商品)および/または非標準的なデータ要素(例えば、タクシー商品)を含み得る。

標準的なデータ要素(例えば、GDSコンテンツ)は、TTYなどの第1のメッセージ交換フォーマット14にしたがって受信され得る。

非標準的なデータ要素は、第2のメッセージ交換フォーマット15にしたがってXMLなどのマークアップ記述言語により定義されたメッセージの形態でデータ交換ユニット11によって受信され得る。以下の説明は、旅行管理システム100と外部システムとの間のデータの相互のやりとりのためのXMLメッセージ(XML文書またはファイルとも呼ばれる)を参照してなされる。データ交換メッセージは、メッセージの構造ならびにメッセージに含まれるデータの種類およびフォーマットを記述する構造記述ファイルを含み得る。例えば、XML型のデータ交換メッセージに関しては、XML XSDスキーマが、XMLメッセージの属性の構造の表現を与える構造記述ファイルとして使用され得る。

ブロック502において、共通のコンテンツに関して受信された各データ要素に関し、コンテンツ管理エンジン3が、データ要素を抽出し得る。コンテンツの抽出は、コンテンツ管理エンジン3の内部アプリケーションによって実行され得る。

データ要素が標準的なコンテンツ(例えば、フライト商品)に対応する場合、ブロック503において、コンテンツ管理エンジン3が、データ要素の種類(例えば、フライト型)を有する標準的なデータコンテナ(以降、「標準的なコンテナ」とも呼ばれる)を用いて標準的なコンテンツ(例えば、フライト商品)に関して標準的なPNR(90)でレコードRを生成する。標準的なデータコンテナは、予め定義された種類のデータ要素(標準的なデータ要素)のために構成された静的なコンテナである可能性がある。ブロック505において、レコードRは、レコード識別子Iを割り振られる可能性があり、標準的なデータコンテナに関連付けられる可能性がある。レコードは、一時的なコンテキストおよび/または少なくとも1つのデータベース8に保存され得る。

データ要素が非標準的なコンテンツ(例えば、タクシー商品)に対応する場合、ブロック505において、コンテンツ管理エンジン3が、非標準的なデータコンテナ(以降、「非標準的なコンテナ」とも呼ばれる)を用いて非標準的なコンテンツ(例えば、タクシー商品)に関して非標準的なPNR(91)でレコードRを生成する。ステップ505は、アプリケーションフローの1つの内部アプリケーションによってトリガされ得る。ETRでのレコードの生成をトリガする内部アプリケーションは、データ交換ユニット11から非標準的なデータ要素を受信する内部アプリケーションとは異なる可能性がある。例えば、第1の内部アプリケーションA1が、アプリケーションA1のフォーマットF1で非標準的なデータ要素を受信する可能性があり、非標準的なデータ要素が、その非標準的なデータ要素がアプリケーションAnのフォーマットFnで内部アプリケーションAnに到着するまで一続きのその他の内部アプリケーションに送信される可能性があり、最後に、アプリケーションAnが、非標準的なレコードデータ構造91(フォーマットFnを有する非標準的なデータコンテナ)でのレコードの生成をトリガする。非標準的なデータコンテナは、データ要素の種類(例えば、タクシー型)に割り振られ得る。

非標準的なデータコンテナは、任意の種類のデータ要素(非標準的なデータ要素)を含むように適合される。ブロック506において、レコードRは、同じレコード識別子Iを割り振られる可能性があり、非標準的なデータコンテナに関連付けられる可能性がある。レコードは、一時的なコンテキストおよび/または少なくとも1つのデータベースに記憶され得る。

一実施形態においては、ブロック506で生成された非標準的なデータコンテナが、ブロック507において、さらにタグを割り振られ得る。そのようなタグは、例えば、クライアントデバイス7に送信されるべきでないデータ要素を特定するために、レコードRにアクセスするときにコンテンツ管理エンジン3によって使用され得る。

したがって、一意のレコード識別子Iが、共通のコンテンツに対応するすべての標準的なデータ要素および非標準的なデータ要素(関連するデータ要素)に関して標準的なPNR 90および非標準的なPNR 91で生成され得る。よって、この共通レコード識別子は、異種のデータ要素が一意のレコードデータ構造に保有されるかのように異種のデータ要素に対応するレコードを操作するために共有され得る。例えば、レコード識別子Iは、データの種類が何であれ、非標準的なデータ要素をアプリケーションが読み取る/書き込むことを可能にするためにコンテンツ管理エンジン3によって使用され得る。

簡略化された例において、拡張された旅行レコード9は、例えば、共通レコード識別子ID1を割り振られたいくつかのレコードを含む可能性があり、そのようなレコード識別子ID1は、以下のデータ要素に共通に関連付けられる。
- 1型の標準的なデータ要素D1
- 2型の標準的なデータ要素D2
- 3型の標準的なデータ要素D3
- タグ付けされた4型の非標準的なデータ要素D4
- 5型の非標準的なデータ要素D5
- タグ付けされた6型の非標準的なデータ要素D6

データ要素D1、D2、D3に関するレコードは、レコード識別子ID1に関連して標準的なレコードデータ構造90に保有される。

データ要素D4、D5、D6に関するレコードは、レコード識別子ID1に関連して非標準的なレコードデータ構造91に(非標準的なデータコンテナに)保有される。

標準的なデータ要素を含むために使用される標準的なデータコンテナは、IATA標準にしたがって予め定義された種類および1組の属性を有するデータ要素を含むように特に適合される。したがって、標準的なデータコンテナは、標準化されたデータフォーマットおよびデータの種類にのみ適合される。

非標準的なデータコンテナは、非標準的なデータ要素の種類、属性、およびフォーマットが何であれ生成され得る。各属性は、それ自体、いくつかの下位属性を含み得る。

したがって、コンテンツ管理エンジン3は、コンテンツの種類が何であれ、非標準的なデータコンテナを用いて、拡張された旅行レコード(9)で新しい種類のコンテンツを動的に生成する。

非標準的なデータコンテナは、標準的なコンテナとは異なり所与の要素に関するコードにハードコーディングされない多様性のあるデータコンテナである可能性がある。対照的に、非標準的なデータコンテナが取らなければならない形態は、動的に定義され得る。

非標準的なデータコンテナは、自己シリアル化/逆シリアル化特性をやはり持ち得る。

特定の実施形態において、非標準的なデータコンテナは、拡張された旅行レコード9に新しいコンテンツを組み込むことを容易にする、その非標準的なデータコンテナを操作する内部アプリケーションのビジネスオブジェクトモデル(Business Object Model)21によって表される技術的オブジェクトである可能性がある。

図6は、非標準的なデータコンテナがビジネスオブジェクトモデル21である本発明の特定の実施形態によるコンテンツ管理エンジン3の内部アプリケーションの構造を概略的に示す。内部アプリケーションは、スタンドアロンアプリケーションであるか、または(関連するアプリケーションを形成する)一続きのアプリケーションの中のアプリケーションである可能性がある。

内部アプリケーションは、以下を含む。
- 構造化されたインターフェース2
- ビジネスオブジェクトモデル21
- ビジネスレイヤ22

構造化されたインターフェース2は、アプリケーションが互いに通信する方法を表す。構造化されたインターフェースは、アプリケーションによって処理されることになる機能データを運び得る。それらの機能データは、検証動作を実行し、動作するためにビジネスレイヤ22によって使用されるビジネスオブジェクトモデル21にマッピングされ得る。検証動作は、文法的な検査に加えてデータに対してビジネスレイヤ22によって実行される機能的な検査に対応する。データ要素は、検証の後、構造化された方法で、拡張されたレコードデータ構造9に挿入され得る。

結果として、拡張されたPNR9のデータ構造の修正は、アプリケーションのビジネスオブジェクトモデル21の修正およびそのアプリケーションの構造化されたインターフェースの修正をともなう可能性がある。さらに、データ構造の修正の恩恵を受けるために、あり得るその他の関連するアプリケーションは、それらのアプリケーションのビジネスオブジェクトモデル21、それらのアプリケーションの構造化されたインターフェース2をやはり適合させ、その他のモジュールのインターフェースに新しいバージョンのデータモデルを組み込む必要がある可能性がある。

本発明のさまざまな実施形態は、非標準的なデータコンテナモデルを使用することによってそのような修正に関連するコストを抑えることを可能にする。

コンテンツ管理エンジン3で実行される旅行サービスアプリケーションは、図7の図にしたがって動作し得る。BOM 21は、アプリケーションによって使用される内部データモデルを表すために使用されるビジネスオブジェクトモデル21を表す。

サービス210は、アプリケーションによってターゲットにされ得るクライアントデバイス7、非標準的な旅行プロバイダ5、または旅行者のデバイス6から旅行管理システム100によって受信される(XMLまたはEdifactメッセージなどの)任意の構造化されたメッセージを表す。

コンテキストサーバ211は、その他のアプリケーションとの非同期のインタラクションの間にアプリケーションによって使用されるデータのコンテキストの記憶(「コンテキスト」とも呼ばれる)を表す。

コンテキストからのデータは、要求に応じて、周期的に、または特定の条件に応じてデータベース8に保存され得る。

図8は、特定の実施形態によるコンテキスト管理エンジン3の一続きにされたアプリケーションA1からAnの間のインタラクションを示す。旅行管理システム100が分散型アーキテクチャで動作させられるとき、プロセスを担う一続きにされた内部アプリケーションA1からAnは、互いを呼び出す可能性があり、このことは、図7のアーキテクチャのいくつかのアプリケーションサーバ30(バックエンドサーバとも呼ばれる)へのいくつかの複製をもたらす可能性があり、各アプリケーションサーバ30は、それぞれの一続きにされたアプリケーションAiに関連付けられる。プロセスの一続きの各ステップで、通常の手法では、アプリケーションA1のための第1のバックエンドサーバ30からアプリケーションAnのための最後のサーバ30に運ばれるデータは、プロセスの途中でサーバ30からサーバ30へわたっていく前に異なる方法で変換、符号化、および復号される。各バックエンドサーバ30は、さらに、データ要素にアクセスする前に、到着するデータ要素を復号し、そのバックエンドサーバ30の専用のプロセスのためにデータを検証する。そして、データは、一続きの次のアプリケーションA_i+1に送信されるために符号化される。さらに、ビジネスオブジェクトモデル21が、構造化されたインターフェース2への情報の充填または構造化されたインターフェース2からの情報の取得のプロセスに関与させられる可能性があり、データの書き込み/読み取りのために使用される可能性がある。通常の手法において、構造化されたインターフェース2および集中的なレコードリポジトリへの/からのデータの書き込み/読み取りは、手作業でコーディングされたコンポーネントを必要とする。したがって、データモデルへの単一の変更が、コストがかかる可能性がある。さらに、概して、アプリケーションが操作しているデータ要素は、操作されるデータが業界の制約に適合した好適なフォーマットであることを保証すること(検証)を各アプリケーションが要求され得るように多くの機能的な制約を有する。

結果として、通常の手法では、データ要素がそのような一続きにされたアプリケーションで修正される必要がある度に、各プロセスが新しいデータを次のプロセスに送信しなければならず、したがって、その新しいデータを復号し、検証し、符号化しなければならなくなるので、プロセスのすべてのステップが影響を受ける可能性がある。さらに、新しいコンテンツが既存のアプリケーションに追加されることになるとき、各プロセスは、さらに、新しいコンテンツを次のプロセスに送信しなければならず、一続きの各プロセスは、新しい要素を復号し、検証し、符号化しなければならない。

特定の実施形態による本発明は、BOM型の非標準的なデータコンテナの自己シリアル化(self-serialization)特性を用いることによって状況を改善する。

特に、非標準的なデータコンテナが、非標準的なコンテンツプロバイダ5からのデータ要素D1、D2、およびD3の受信に応じて、一続きの第1のアプリケーションA1によって生成され得る。そのような非標準的なコンテンツは、PNR 90の標準的な構造に準拠するデータの種類および属性を含まないので、標準的なPNR 90にそのまま記憶され得ない。非標準的なコンテンツは、さまざまな形態をとり、さまざまな種類および属性に関連付けられる可能性がある。

第1のアプリケーションA1は、例えば、第1の内部アプリケーションA1のフォーマットF1(例えばProtocol Buffers)でそれぞれの非標準的なデータ要素D_kのための非標準的なコンテナを生成し得る。それから、第1のアプリケーションA1は、非標準的なコンテナの自己シリアル化/逆シリアル化特性を使用してメッセージM1を用いて一続きの次のアプリケーションに非標準的なコンテナを渡す。メッセージM1は、自己シリアル化/逆シリアル化情報を運ぶブロッブ(blob)である可能性がある。そして、第2のアプリケーションA2は、内部アプリケーションA2のフォーマットF2で非標準的なデータコンテナを抽出し得る。同様に、第2のアプリケーションは、アプリケーションAnがETR 9でレコードの生成をトリガするまで、自己シリアル化/逆シリアル化情報を運ぶメッセージM2、M3などを用いて一続きのその他のアプリケーションに非標準的なコンテナを送信し得る。

したがって、非標準的なデータコンテナを用いることによって、一続きの内部アプリケーションでETR 9に新しいデータ構造を追加するか、データ構造を更新するか、またはデータ要素を送信するためにいかなるコードの変更も必要とされない。さらに、既存のデータ構造を修正する必要がない。非標準的なデータコンテナによって含まれるデータは、そのデータを抽出し、あるフォーマットから別のフォーマットに変換する必要なしに利用できるようにされ得る。したがって、中間の/手作業でコーディングされたレイヤが、削減され得る。

図9の例に示されるように、非標準的なデータコンテナ50は、アプリケーションによって操作され得るビジネスオブジェクトモデルを記述する1組のキー値によって定義される可能性がある。各キー(KEY)51は、BOMの属性を定義し、関連する値52(図9においては「DATA」とも呼ばれる)を含む。例えば、キー「city」によって定義される非標準的なデータコンテナは、値「Paris」に関連付けられる。データコンテナは、複雑な構造を含み、任意の種類のデータに関連付けられ得る。例えば、データコンテナの1つまたは複数のキーが、所与のデータコンテナを1組の関連するデータコンテナに関連付ける参照53(図9においては「REF」と呼ばれる)にさらに関連付けられる可能性がある。例えば、キー/値の対「phone/+335551213」によって指定されるデータコンテナは、次のデータコンテナ、すなわち、「mobile/+336123456」および「home/+335551213」への参照(「REF」)を含む。

非標準的なデータコンテナ50は、非標準的なデータコンテナに含まれるデータ要素のいずれかに関する書き込みモードでのアクセスを、そのようなアクセスを可能にするアクセサ(accessor)を作る必要なしにコンテンツ管理エンジン3に許す。これは、柔軟性およびスケーラビリティを保証する。

さらに、非標準的なデータコンテナに含まれるデータ要素へのアクセスは、Xpathなどの好適な問い合わせ言語による問い合わせを用いることによってアプリケーションの処理の任意の時点でコンテンツ管理エンジン3により実行され得る。

非標準的なデータコンテナは、プログラム的に後方および前方互換性がある可能性がある。プログラミングの観点から見ると、非標準的なデータコンテナに関連する新しいバージョンのデータ要素の構造を使用するためにいかなるコードの変更も必要とされない。

非標準的なデータコンテナは、シリアル化/逆シリアル化をサポートするように構成される。特に、シリアル化は、拡張可能なフォーマットでデータコンテナを符号化するために非標準的なコンテンツの1つまたは複数の属性の生成および修正時に実行される可能性があり、逆シリアル化は、アプリケーションが非標準的なコンテンツの少なくとも1つの属性を読み取る必要がある度に実行される可能性がある。

特に、非標準的なデータコンテナのキーおよび値は、非標準的なデータコンテナを表す技術的オブジェクト(例えば、BOM)の状態を、記憶され、データコンテナをそのデータコンテナの元の状態に復元するために逆シリアル化メカニズムによって再構築され得るフォーマット(例えば、バイナリ表現)に変換することによって任意の時点でシリアル化され得る。したがって、非標準的なデータコンテナは、データコンテナに含まれるデータが何であれ、任意の目標のフォーマットに変換され得る。シリアル化および逆シリアル化メカニズムは、ハードコーディングを必要としない。シリアル化情報は、データコンテナに関連するライブラリに組み込まれ得る。したがって、そのようなBOMの使用は、特定のコーディングを必要とせずに、非標準的なデータコンテナのキーによって定義される任意の種類の構造のためにサポートされ得るシリアル化メカニズムをネイティブで提供する。特定の例示的な実施形態において、シリアル化/逆シリアル化メカニズムによって非標準的なデータコンテナの状態を変換するために使用される非標準的なデータコンテナの表現のフォーマットは、例えば、図10に示されるように、XML、ASCII、JSON、バイナリフォーマットに基づく可能性がある。

非標準的なデータコンテナの値の検証が、非標準的なデータコンテナオブジェクトによって表されるデータ要素の生成および修正時にのみ必要とされる可能性がある。したがって、キーに関連するデータ要素を再検証するためのいかなる読み取りプロセスも必要とされない。

非標準的なデータコンテナを使用することにより、コンテンツの種類に関連する情報(例えば、航空、タクシー、スポーツショー、駐車、都市交通など)が、非標準的なデータコンテナ自体に持ち込まれ得る。非標準的なデータコンテナの種類は、非標準的なデータコンテナにキーとして直接記憶され得る。

一部の実施形態において、所与の非標準的なデータコンテナの生成または修正における検証メカニズムは、通常の手法のようなC++型ではなく、非標準的なデータ要素にキーとして記憶される機能型(functional type)に基づく可能性がある。

特定の実施形態においては、非標準的なデータコンテナのそれぞれの種類が、データ要素の属性の構造(属性のレイアウト、属性の依存関係、および属性のフォーマットなど)を記述する構造記述ファイル(例えば、XSD)に関連付けられる可能性がある。

構造記述ファイル(例えば、XSD)は、技術的オブジェクト(例えば、XMLオブジェクト)として表される非標準的なデータコンテナの属性と要素との間の相互関係をさらに表す。非標準的なデータコンテナに関連するXSDスキーマ内で、非標準的なデータコンテナの異なるキー/値と、その非標準的なデータコンテナに適用される補足的制約とが、1組のXMLタグを使用して記述され得る。構造記述ファイルは、非標準的なデータコンテナの生成および修正で使用され得る。加えて、補足的制約が、構造記述ファイル(例えば、XSD)を用いて非標準的なデータコンテナに適用され得る。

それぞれの非標準的なデータコンテナに関連する構造記述ファイルは、非標準的なデータコンテナの生成または修正で非標準的なデータコンテナの属性を検証するために使用され得る。検証メカニズムは、非標準的なデータコンテナによって表される非標準的なデータ要素がコンテンツが配置されることになるデータ要素の記述を遵守するかどうかを検証することを含み得る。特定の実施形態において、検証メカニズムは、非標準的なデータコンテナに記憶されるデータが目標のフォーマットに合致するかどうかを非標準的なデータコンテナに関連する構造記述ファイルを用いることによって検証するように実装され得る。

旅行管理システム100は、非標準的なデータコンテナに関連する構造記述ファイルに対応して非標準的なデータコンテナのデータの種類を記憶するためのテーブルを保有し得る。テーブルは、プロセスの実行時に更新され得る。

コンテンツ管理エンジン3は、新しい属性などの非標準的なデータコンテナ構造を記述する構造記述ファイル(例えば、XSD)を更新することによって新しいデータを非標準的なデータコンテナに追加するように構成され得る。

非標準的なデータコンテナを定義する構造記述ファイル(例えば、XSD)は、変更をハードコーディングし、コードを再コンパイルする必要なしに修正され得る。したがって、非標準的なデータコンテナの修正は、動的であり、実行時に更新される。

図11は、例示的な非標準的なデータコンテナのそれぞれの種類、すなわち、電話型(PhoneType)、住所型(AddressType)、GPS型(GPSType)を示す図9のそれらの例示的な非標準的なデータコンテナの概略図である。情報の種類は、非標準的なデータコンテナに属性として記憶され得る。そのような情報は、非標準的なデータコンテナに関連する構造記述ファイルを取得するために使用され得る。

図12は、異なる種類(「PhoneType」、「AddressType」、「GPSType」)を有する図11の例示的な非標準的なデータコンテナに関するXSD記述ファイルを示す。

特定の実施形態によれば、コンテンツ管理エンジン3は、さらに、クライアントデバイス7に返されるコンテンツの種類、およびコンテンツ管理エンジン3によって保有されるアプリケーションが何であれ、旅行管理システム100によってクライアントデバイス7に公開される一意のプラットフォームで1組の内部サービスインターフェース2を生成し得る。

拡張された旅行レコード9は、非常に多くのアプリケーションによって使用される可能性がある。例えば、コンテンツ管理エンジン3は、コンテンツの種類が何であれ、標準的な旅行プロバイダシステム4から受信された外部コンテンツ(例えば、航空商品)および任意のその他の旅行プロバイダシステム5から受信された外部コンテンツ(例えば、非航空商品)に基づいてクライアントデバイス7に異なる種類の旅行サービスを届けるための1組のアプリケーション(例えば、旅行アプリケーション)を含み得る。そのようなサービスは、例えば、ショッピング、予約、価格決定、保険、払い戻しサービスを含み得る。

そのようなサービスアプリケーションは、ハードコーディングによってETR 9に追加されたN種類のデータに各アプリケーションを適合させる必要なしに、クライアントデバイス7を通じた旅行管理システム100に接続されたシステム(例えば、旅行代理店システム70)からのサービス要求に応答して実行され得る。

結果は、XMLメッセージなどの所与のフォーマットの応答メッセージを用いてデータ交換ユニット11を通じて返され得る。したがって、旅行管理システム(100)によって生成される内部サービスインターフェース2は、XML型である可能性がある。

任意の数の新しい種類の非標準的なデータコンテナをサポートするために各アプリケーションを再コーディングし、再コンパイルする必要をなくすために、一意の種類(汎用要素型)を有する汎用的な要素が使用され得る。汎用的な要素は、任意の種類の非標準的なデータコンテナを含むように構成されたメガデータコンテナ(mega data container)である。汎用的な要素は、制限されない数N個の非標準的なデータの種類を含み得るが、すべてのサービスアプリケーションによって一意の種類(以降、「汎用要素型」と呼ばれる)のコンテナと見なされ得る。

したがって、各アプリケーションは、データコンテナに含まれるデータ要素の種類とは独立にシームレスに非標準的なコンテナを操作することができるように汎用的な要素をインスタンス化し得る。したがって、各アプリケーションは、新しいデータの種類と同じ数の非標準的なデータコンテナをインスタンス化する必要はない。

結果として、非標準的なPNR 91への新しいコンテンツの種類の追加は、(例えば、ハードコーディングによって)後方互換性を保証するために、コンテンツ管理エンジン3によって扱われるアプリケーションに影響を与えることがないか、またはコンテンツ管理エンジン3によって扱われるアプリケーションに対する適合を必要としない。

図13は、所与のレコード識別子Iを有するETR 9のレコードへのアプリケーションによるアクセスを示す流れ図である。例えば、レコード識別子Iは、以下を含み得る。
- T1型の標準的なデータ要素SD1
- T2型の標準的なデータ要素SD2
- 非標準的なデータコンテナに含まれるT3型の非標準的なデータ要素NSD3
- 非標準的なデータコンテナに含まれるT4型の非標準的なデータ要素NSD4

ブロック600において、レコード識別子Iに関連するレコードが、ETR 9から取得される。レコードは、それぞれの種類T1、T2、T3、T4を有する標準的なデータ要素(SD1、SD2)および非標準的なデータ要素NSD3、NSD4(非標準的なデータコンテナ)に関連付けられる可能性がある。

そして、各データ要素SD1、SD2、NSD3、およびNSD4は、別々に処理される。

特に、例えば、NSD3などの各データ要素に関して、データ要素が非標準的なデータ要素である場合(ブロック601)、T3型の非標準的なデータ要素は、ブロック602において、T3型の非標準的なデータ要素を含む一意の汎用要素型の汎用的な要素に変換される。メガデータコンテナとしての汎用的な要素は、それ自体、特定の種類を有する非標準的なデータコンテナを含み得る。汎用的な要素は、BOMなどの技術的オブジェクトとして実装される可能性があり、非標準的なデータコンテナと同じテクノロジーに基づく可能性がある。

データ要素が、例えば、SD1などの標準的なデータ要素である場合(ブロック603)、T1型の標準的なデータ要素は、ブロック604において、同じT1型の非標準的なデータコンテナに変換され得る。

ブロック602において、そのように取得された非標準的なデータ要素は、それから、標準的なデータ要素NSD1に対応するT1型の非標準的なデータ要素を含む一意の汎用要素型の汎用的な要素に変換される。

汎用的な要素は、アプリケーションが標準的なデータ要素および非標準的なデータ要素をそれらのデータ要素の種類が何であれシームレスに操作することを可能にする非標準的なデータ要素の一時的な状態を形成する。したがって、アプリケーションは、非標準的なコンテンツの種類をはっきりと知ることなく、ETR 9のデータ要素を、それらのデータ要素が一意の種類を有するかのように操作することができる。

ブロック605において、サービス要求を生じるクライアントデバイス7のインターフェースに1つまたは複数のデータ要素が送信されることをアプリケーションの実行が必要とする場合、アプリケーションが、汎用的な要素の中身を調べて(introspect)、データ要素の種類にアクセスし得る。

本発明の特定の実施形態において、非標準的なデータ要素は、それぞれのタグに関連付けられる可能性がある。そのような実施形態においては、ブロック601で、それぞれのタグに関連付けられた非標準的なデータ要素のみがアプリケーションによって選択され、汎用的な要素に変換され得る。

したがって、汎用的な要素は、非標準的なデータ要素の種類を抜粋し、つまり、新しい種類のコンテンツがアプリケーションによって扱われる必要がある(新しいコンテンツがETR 9に追加される)度に新しい要素の種類を定義する代わりに、各アプリケーションは、したがって、任意の新しいコンテンツの種類および属性をサポートすることができる一意の汎用的な要素をインスタンス化し得る。

再び図3に目を向けると、旅行管理システム100は、任意の種類のコンテンツ(標準的および非標準的なコンテンツ)を旅行代理店システム70、非標準的な旅行プロバイダシステム5などの任意の外部クライアントデバイスとやりとりするか、または内部インターフェース2を通じて同じGDS内の任意のその他のバックエンドサーバとやりとりするように適合され得る。

通常の手法では、旅行管理システム100は、目標のクライアントデバイスのインターフェースによってサポートされる標準的なフォーマットへのハードコーディングの変換を実装することによって、標準的なPNRからのデータを、PNRコンテンツのフォーマットに関する独自の標準(目標のPNRコンテンツフォーマット)を有するその他の目標のクライアントデバイス(例えば、旅行プロバイダシステム、旅行代理店システム)とやりとりすることができる。これは、旅行管理システム100における符号化メカニズムおよび目標のデバイスにおける復号/検証メカニズムを必要とする。さらに言えば、各旅行管理システムは、PNRコンテンツのフォーマットに関する独自の標準(元のPNRコンテンツフォーマット)を有する可能性があり、したがって、目標のデバイスのインターフェースは、そのようなフォーマットのみをサポートする。そのような変換(符号化/復号/検証)は、現在、コストのかかる静的な手法でのハードコーディングおよび再コンパイルをともなう。

データ交換ユニット11は、任意の種類のコンテンツをやりとりするために第2のデータ交換フォーマット15にしたがって外部クライアントデバイスからのデータ交換メッセージの受信または送信を可能にする。好ましい実施形態において、第2のデータ交換フォーマット15は、XMLなどのマークアップ記述言語である。非標準的なデータ要素に対応するそれぞれのデータ交換メッセージは、XMLメッセージに関するXSDなどのデータ要素の属性(属性のレイアウトおよびフォーマット)を定義する構造記述ファイルと、属性の値に対応する1組の値とを含む。

図14は、特定の実施形態によるデータ交換ユニット11の構造をより詳細に示す。

データ交換ユニット11は、非標準的な旅行プロバイダ5、旅行代理店システム、または別の非GDSシステムなどの外部クライアントデバイスとデータ要素をやりとりするために使用され得る。特に、データ交換ユニット11は、
- クライアントデバイスから非標準的なデータ要素を受信するか、または
- ETR 9からのデータ要素をクライアントデバイスに送信する
ために使用され得る。

データ交換ユニット11は、XSDなどの構造記述ファイルを元の構造記述ファイルXSD1を目標の構造記述ファイルXSD2に変換するためのXSLTエンジンなどの構造変換エンジン111と、XMLなどの記述言語によって定義されたメッセージの形態でデータを送信するためのデータ交換メッセージジェネレータ112とを含み得る。XSLTエンジンは、受信モードで元の構造記述ファイルXSD1を変換するための変換規則を定義する予め定義されたローカルマッピング規則113(例えば、XSLTスタイルシート)、または送信モードで元の構造記述ファイルXSD1を変換するための変換規則を定義する予め定義されたクライアントマッピング規則117(例えば、XSLTスタイルシート)を使用し得る。

旅行管理システム100は、異なるコンテンツの種類に関連し、旅行管理システム100によってローカルで適用されることになる構造記述ファイルに対応する1つまたは複数の予め定義されたローカル構造記述ファイル115を保有するかまたは実行時に動的にロードし得る。

受信モードで、データ交換ユニット11は、外部クライアントデバイス7によって定義された元の構造記述ファイルXSD1に準拠する外部クライアントデバイス7から到着するデータ交換メッセージXML1を受信し得る。到着するメッセージXML1は、所与の種類Tiの非標準的なデータ要素を含む。

非標準的なデータ要素を含むそのような到着するデータ交換メッセージXML1が旅行管理システム100によって受信される度に、変換エンジン111は、データ交換メッセージXML1に含まれるデータ要素の種類に関連するローカルマッピング規則113を用いて、到着するメッセージの構造記述ファイルXSD1を目標の構造記述ファイルXSD2に変換し得る。それから、目標の構造記述ファイルXSD2は、1組のローカル構造記述ファイル115に追加される。

さらに、データ交換ユニット11は、元の構造記述ファイルXSD1を目標の構造記述ファイルXSD2に変換する前に、到着するメッセージXML1に検証メカニズムを適用して構造記述ファイルXSD1の属性に関連するいくつかの条件(例えば、必須の属性の存在)を検証し得る。

そして、Ti型の非標準的なデータコンテナが、データ交換メッセージXML1のフィールドを非標準的なデータコンテナのプリミティブ(primitive)にマッピングすることによって生成され得る。次いで、非標準的なデータコンテナは、図5に関連して説明されたように、Ti型に関する115に記憶された目標の構造記述ファイル(XSD2)に関連してETR 9に追加される。ETR 9の新しいコンテンツの任意の更新または追加は、実行時に行われ得る。

したがって、データ交換ユニット11の使用は、いかなるコードの変更も必要とせずに、コンテンツプロバイダシステム4、5から受信された任意の到着するデータ交換メッセージを、追加/修正されることになる要素を表すいくつかの非標準的なデータコンテナオブジェクトに動的に変換することを可能にする。

送信モード(破線)で、旅行管理システム100は、ETRからの任意のデータ要素をデータ交換ユニットを通じて外部クライアントデバイス7の目標のインターフェースに送信し得る。

送信モードで、データ交換ユニット11は、(非標準的なデータコンテナに既に変換されたTi型の非標準的なデータ要素または標準的なデータ要素を含む)非標準的なデータコンテナを入力として受信する。

Ti型の非標準的なデータコンテナは、XSDファイル(115)などの、非標準的なデータコンテナの属性(キー)、属性のレイアウト、および属性のフォーマットの記述を含む構造記述ファイル(元の構造記述ファイルと呼ばれる)に関連付けられる。非標準的なデータコンテナは、属性の値に対応するキー値にやはり関連付けられる。

旅行管理システム100によって送信されることになるデータ要素がETR 9からの所与の種類Tiの非標準的なデータコンテナを含む場合、変換エンジン111は、非標準的なデータ要素の種類に関連するクライアントマッピング規則117を使用することによって、ローカル構造記述ファイル115の非標準的なデータコンテナに関連する構造記述ファイルXSD3を目標の構造記述ファイルXSD4に変換し得る。クライアントマッピング規則117は、例えば、目標のクライアントデバイス7のグラフィカルユーザインターフェース(GUI)への表示のための、目標のクライアントデバイス7のインターフェースのフォーマットへの変換規則を定義する。

クライアントデバイス7に送信されることになるデータ要素がTi型の標準的なデータ要素(例えば、GDS要素)である場合、標準的なデータ要素は、データコンテナコンバータ12を用いて同じ種類の非標準的なデータコンテナに既に変換されている可能性がある。それから、標準的なデータ要素は、目標のクライアントデバイス7への送信のために非標準的なデータコンテナの形式でデータ変換ユニット11に送信され得る。

図15は、特定の実施形態による、クライアントデバイス7の目標のインターフェース(グラフィカルユーザインターフェースGUI)にTi型のデータ要素を送信するための流れ図を示す。

データ要素が標準的なデータ要素である場合(ブロック700)、Ti型の標準的なデータ要素は、(図13のブロック604と同様に)ブロック701において、同じTi型の非標準的なデータコンテナに変換され得る。そして、標準的なデータ要素は、構造記述ファイルXSD1およびキー値Viに関連するTi型の非標準的なデータコンテナの形態でブロック703において処理される。

データ要素が構造記述ファイルXSD1およびキー値Viに関連するTi型の非標準的なデータコンテナの形態の非標準的なデータ要素である場合(ブロック700)、ブロック703において、Ti型の非標準的なデータ要素が直接処理される。

ブロック703において、非標準的なデータコンテナに関連する元の構造記述ファイルXSD1が、取得される。

ブロック704において、元の構造記述ファイルXSD1が、マッピングエンジン110(例えば、XSLTエンジン)を使用してマッピング規則113(例えば、XSLTスタイルシート)を用いて元の構造記述ファイルXSD1を解析し、解析されたフィールドを目標の構造記述ファイルXSD2に変換して目標の構造記述ファイルXSD2に変換される。マッピング規則113は、クライアントデバイス7の目標のインターフェースのフォーマットにしたがって定義される。

ブロック705において、クライアントデバイスに送信されることになるデータ要素を含むXMLメッセージが、非標準的なデータコンテナに関連する値Viを追加することによって生成される。

ブロック706において、XMLメッセージが、ネットワーク13を通じてクライアントデバイス7の目標のインターフェースに送信される。目標のインターフェースは、XMLメッセージの応答に応答して動的で透過的に適合され得る。

さらに、外部クライアントデバイス7は、データの種類および目標のインターフェースのフォーマットが何であれ、データに復号および複雑な検証メカニズムを適用する必要なしにXMLメッセージに含まれるデータ要素を抽出し、そのデータ要素をその外部クライアントデバイス7独自の標準にしたがって記憶し得る。

構造記述ファイル(XSD)に関連し、任意のフォーマット15(例えば、XML)で非標準的なデータコンテナ自体をデータ交換メッセージとしてシリアル化する能力を有する非標準的なデータコンテナを使用することによって、したがって、新しい種類のインターフェース2が構築され得る。

一実施形態において、データ交換ユニット11は、できる限り少ない手作業でコーディングされたソフトウェアで、コンテンツの種類が何であれ(標準的、非標準的、混合のコンテンツ)クライアントデバイス7(例えば、旅行代理店システム)のインターフェースへの要求の結果の一貫した表現を動的に生成するためにコンテンツ管理エンジン3によって使用され得る。

サービスアプリケーションは、インターフェース2でデータを記憶するために同種のデータ構造を直接使用することができる。これは、インターフェースレイヤとBOMレイヤとの間でさらに別のフォーマットのデータ構造をやりとりする必要をなくす。さらに、これは、拡張された旅行レコードに記憶されたデータと、一意のプラットフォームを通じてクライアントデバイス7(例えば、旅行代理店システム)に公開されたサービスインターフェースのデータ表現との間のオーバーヘッドを削減することを可能にする。

特に、図13の方法は、コンテンツの種類が何であれ(標準的なコンテンツまたは非標準的なコンテンツ)表現が同種であることを保証しながら、クライアントデバイス7(例えば旅行代理店システム70)からのサービス要求に応答して結果の表現を生成し、クライアントデバイスのインターフェースでサービスに関連するユーザグラフィカルインターフェース上のそのような表現の表示を生成するために適用され得る。

非標準的なコンテンツおよび/または標準的なコンテンツに関連するレコード識別子が拡張されたレコードデータ構造9に追加されるとき、サービスアプリケーションは、新しい種類が何であれ、レコードの表現を動的に同種で生成するように適合される。

サービス要求に対応するコンテンツ管理エンジン3のアプリケーションは、汎用的な要素を用いて図12のアクセス方法にしたがってETRから得られた結果に対応するレコードにアクセスし得る。

クライアントデバイス7に返されることになるコンテンツの種類が何であれ一意の汎用的な要素に基づく非標準的なデータコンテナ(50)へのアクセスの実装は、各アプリケーションが非標準的なコンテンツプロバイダシステム5からの任意の種類のコンテンツをサポートすることを可能にする。したがって、コンテンツ管理エンジン3のアプリケーションは、コンテンツの種類とは独立している。

結果を旅行代理店システム70のインターフェースに返すために、アプリケーションは、汎用的な要素の中身を調べて非標準的なデータコンテナにアクセスし得る(図6のブロック605)。そのようにアクセスされる非標準的なデータコンテナは、図14の方法にしたがって返され得る。

したがって、コンテンツ管理エンジン3は、操作されなければならない商品の種類(例えば、従来のGDS航空商品(フライト)/GDS自動車レンタル/非GDSタクシー/非GDSレストラン...)とは独立に一意の応答を表すサービス(例えば、旅行サービス)毎の1組のインターフェースを含む一意のプラットフォームをすべてのクライアントデバイス7に提供するように適合される。

アプリケーションへの新しいコンテンツの統合を容易にするために、アプリケーションに関連する内部サービスインターフェース2は、それぞれのコンテンツの系統に関する1組の共通属性を有する可能性がある。これは、既存のコンテンツの系統の新しい要素が系統のために利用可能なすべての表示機能から恩恵を受けることを可能にする。

特に、非標準的なデータコンテナ(50)の基礎を成すデータ構造が、特定の要素のカテゴリ内の共通フォーマットを共有し得る。例えば、航空会社のセグメント型のデータ要素を表すために使用されるフォーマット記述ファイルXSDiは、そのデータ要素が旅行管理システム(100)を通じて予約されたか、または別の外部予約システムを介して予約されたかに関わらず同じであり得る。そのデータ要素は、別のカテゴリ(例えば、郵送カテゴリ)からの要素と1組の共通のデータを共有する可能性もある。

特に、変換エンジン111は、所与のレコード識別子I1に関して、非標準的なデータ要素と標準的なデータ要素との両方に関連するETR 9で、非標準的なデータ要素および標準的なデータ要素が同じ一般的な種類(例えば、「ホテル」)である場合、非標準的なデータ要素に関連する構造記述ファイルXSD1および標準的なデータ要素に関連する構造記述ファイルXSD2を目標のインターフェースに準拠する共通の種類の同じ構造記述ファイルにマッピングすることによって、外部クライアントデバイス7(例えば、旅行代理店システム)の目標のインターフェースで両方のデータ要素のために同じ表現が生成され得るように定義され得る。

例えば、図16に示されるように、C型の標準的なデータ要素が、まず、同じC型に関連する非標準的なコンテナに変換され(図15のブロック701)、それから、表現(XSD2)が、変換エンジン111と、クライアントデバイスでC型に関して定義されたマッピング規則117(スタイルシート)とを用いてC型に関してクライアントデバイスに生成される。図17の例に示されるように、同じ表現(XSD2)が、種類C型の非標準的なコンテナのために使用される。

また、変換規則117は、任意のデータ要素の同じ種類の属性が、コンテンツの種類が何であれ(非標準的または標準的)、(目標の記述ファイルの)属性を含む同じ下位表現にマッピングされるように定義され得る。

図18に示される例においては、(元の構造記述ファイルXSD1で定義された)1組の属性A1、A2、A3、A4を含むD型の標準的なコンテナが、まず、同じD型に関連する非標準的なコンテナに変換され(図15のブロック701)、それから、表現XSD2(目標の構造記述ファイル)が、変換エンジン111を用いてD型に関してクライアントデバイスに生成され、表現XSD2は、元の属性{A1, A2, A3, A4}に対応する表現属性{E1, E2, E3, E4}を含む。図19の例に示されるように、同じ表現{E2, E3}が、元の構造記述ファイルXSDの同様の属性に関する同じマッピング規則117を適用することによって、1組の属性{C1, A2, A3, C4}を含む別のC型の非標準的なコンテナの属性A2、A3に関して生成され得る。したがって、マッピングエンジン11は、それぞれ属性A2およびA3に関する同じ表現E2およびE3を有する表現XSD3={F1, E2, E3, F4, F5}を生成する。

したがって、コンテンツ管理エンジン3は、操作されなければならないコンテンツの種類(例えば、GDSフライト商品、GDS自動車レンタル、非GDSタクシー、非GDSレストランなど)とは独立に一意の応答が生成され得るアプリケーション毎の1組のインターフェースを含む一意のプラットフォームを(例えば、旅行代理店システムに関連する)すべてのクライアントデバイス7に提供する。

したがって、サービスアプリケーションは、インターフェースでデータを記憶するために異種のデータ構造を直接使用することができる。これは、インターフェースレイヤとBOMレイヤとの間でさらに別のフォーマットのデータ構造をやりとりする必要をなくす。さらに、これは、拡張された旅行レコード9に記憶されたデータと、一意のプラットフォームを通じてクライアントデバイス7(例えば、旅行代理店システム)に公開されたサービスインターフェース2のデータ表現との間のオーバーヘッドを削減することを可能にする。

したがって、データ交換ユニット11は、できる限り少ない手作業でコーディングされたソフトウェアで、コンテンツの種類が何であれ(標準的、非標準的、混合のコンテンツ)、結果の一貫した表現を動的に生成することを可能にする。

特に、結果をクライアントデバイス7に返すために使用されるデータ交換メッセージは、内部構造に近いフォーマット(例えば、XML)を有し、このフォーマットは、汎用的な要素で要素自体を定義するために使用された構造記述ファイル(例えば、XSD)から継承される。

したがって、コンテンツ管理システム100は、操作されなければならない商品の種類(例えば、従来のGDS航空商品(フライト)/GDS自動車レンタル/非GDSタクシー/非GDSレストラン...)とは独立に一意の応答を表す旅行サービス毎の1組のインターフェースを提供する。

図20は、特定の実施形態によるコンテンツ再編成方法の流れ図を示す。ETR 9の共通レコード識別子に関連するコンテンツは、同じ旅行に関連する1組のデータ要素を含む。ETR 9の特定のレコード識別子を必要とするアプリケーションに応じて、アプリケーションは、所与のレコードロケータに関連する異なるデータ要素が、アプリケーションによってアクセスされるときに予め定義された再編成基準(例えば、再配列基準)にしたがって編成される(例えば、順序付けられる)ことを必要とする可能性がある。

コンテンツ再編成方法は、時間順、ランク付け基準など、アプリケーションによって予め定義された再編成基準にしたがってデータ要素を再編成するために実装され得る。再編成方法は、標準的なデータ要素および非標準的なデータ要素を抜粋の要素に基づく抜粋のランク付けモデルへと合併し得る。抜粋の要素は、再編成基準にしたがってデータ要素を並べ替えるために使用され得る。したがって、アプリケーションは、目標のインターフェースの制約にしたがって順序付けられた合併されたデータ要素を返すことができる。これは、例えば、PNRセグメントおよび拡張された要素(非標準的なコンテンツ)が同じビュー(view)で合併され得る集約された旅程文書をもたらし得る。

特に、各データ要素に関して、データ要素が非標準的なデータ要素である場合(ブロック801)、Ti型の非標準的なデータ要素は、ブロック802において、Ti型の非標準的なデータ要素の属性のサブセットを含む一意の種類の抜粋の要素に変換される。非標準的なデータコンテナの属性は、例えば再編成基準に基づいて生成されたフィルタリング規則にしたがってフィルタリングされる(例えば、時間順に、フィルタリング基準は日付属性を選択する)。抜粋の要素は、BOMなどの技術的オブジェクトとして実装される可能性があり、非標準的なデータコンテナおよび/または汎用的な要素と同じテクノロジーに基づく可能性がある。汎用的な要素と抜粋の要素とは、両方とも、データ要素の種類の抜粋を可能にすることに留意されたい。

データ要素がTi型の標準的なデータ要素である場合(ブロック803)、そのデータ要素は、(図13のステップ604と同様に)ブロック804において、同じTi型の非標準的なデータコンテナに変換され得る。

ブロック805において、そのように取得された非標準的なデータ要素の属性が、フィルタリング基準にしたがってフィルタリングされる。

ブロック806において、ステップ804で取得された非標準的なデータ要素が、Ti型の標準的なデータ要素に対応するTi型の非標準的なデータ要素のフィルタリングされた1組の属性を含む抜粋の要素に変換される。

汎用的な要素と同様に、得られた抜粋の要素は、データコンテナの種類を抜粋することを可能にする非標準的なデータ要素の一時的な状態を形成する。さらに、その抜粋の要素は、抜粋のモデルの中身を調べることによって、データ要素の種類が何であれ、アプリケーションによるフィルタリングされたデータ要素の属性のグローバルな操作を可能にし、特に、それらのフィルタリングされたデータ要素の属性を再編成基準にしたがって編成する。

旅行の分野においては、標準的なPNR 90が、複数のシステム間で共有される記憶領域に記憶され得る。標準的なPNR 90に保有される標準的なデータ要素は、異なる種類である可能性があり、各要素は、独自のシリアル化フォーマットを有する可能性がある。標準的なデータ要素は、データ要素が関連する(例えば、同じ乗客または旅程に共通である)場合、同じレコード識別子を共有し得る。

同様に、非標準的なPNR 91のデータ要素は、データ要素が関連する場合、非標準的なPNR 91または標準的なPNRの別のデータ要素と同じレコード識別子を共有し得る。非標準的なPNR 91は、標準的なPNRと同じ記憶領域に記憶され得る。代替的に、標準的なPNR 90および非標準的なPNR 91は、異なる記憶領域に記憶され得る。2つの領域は、共通のデータの同期を可能にするためにグローバルな管理メカニズムによって管理される可能性がある。グローバルな管理メカニズムは、拡張された旅行レコード9全体を操作する必要がある問い合わせの度に、非標準的なPNR 91に専用の記憶領域を標準的なPNR 90に専用のその他の記憶領域にリンクするように実装され得る。

たとえETR 9が2つのレコードデータ構造90および91に分けられるとしても、ETR 9は、関連するデータ要素を特定する共通レコード識別子、補足的コンテナデータ、および/またはレコードデータ構造情報に基づいてグローバルに管理され得る。

補足的データコンテナデータは、各データコンテナに関する制御情報(例えば、作成日時、最終修正日時など)を含み得る。通常の手法では、そのような情報は、レコード識別子0に関連してそれぞれの標準的なデータコンテナに直接記憶され、標準的なPNRを管理するために(例えば、標準的なPNRを周期的に除去するために)アクセスされ得る。しかし、そのような手法は、2つのレコードデータ構造90および91の最適化された管理を可能にしない。

図21は、特定の実施形態よるETR 9の構造を表す。示されるように、2つのレコードデータ構造90および91のグローバルな管理を最適化するために、一部の実施形態においては、拡張された旅行レコード9は、データコンテナの作成日時、データコンテナの最終修正日時などの、ETR 9で生成された各データコンテナに関連する補足的コンテナデータを管理するための補足的データ構造92(「集中管理データ構造」または「集中管理領域」とも呼ばれる)をさらに含み得る。補足的データ構造92に保有される情報が、両方の領域を同期して管理するために使用され得る。補足的データ構造92の各エントリは、ETR 9で生成されたデータコンテナとして同じレコード識別子を共有し得る。さらに、補足的データ構造92の各レコードは、(同じレコード識別子を有する)ETR 9に保有されるデータコンテナに関連する1組の補足的コンテナデータに関連付けられ得る。補足的データ構造92は、標準的なレコードデータ構造90および非標準的なレコードデータ構造91に含まれるデータコンテナ情報で満たされ得る。

一部の実施形態において、補足的データ構造92の各エントリは、拡張されたレコードデータ構造(9)で同じレコード識別子を共有するデータコンテナに関連する1組の補足的属性を含み得る。各エントリは、同じレコード識別子を共有するETR 9のレコードに関連する1組の補足的コンテナデータを記憶するための補足的データコンテナを含み得る。1組の補足的コンテナデータは、レコードの除去の前の日付などの、同じレコード識別子を共有するETR 9のレコードに関連する制御情報を表す制御属性を含み得る。

一部の実施形態においては、所与のレコードデータ構造90または91のすべてのレコードに関連するデータコンテナ情報が、このレコードデータ構造(90または91)の専用のレコード(「コンテナ情報レコード」とも呼ばれる)に保有され、特定のレコード識別子(例えば、レコード識別子0)を割り振られる可能性がある。標準的なレコードデータ構造90のコンテナ情報レコードおよび/または非標準的なレコードデータ構造91のコンテナ情報レコードは、異なる時間間隔で、例えば、周期的に、または問い合わせに応じて、または代替的にETR 9が1つもしくは複数のデータベース8に保存される度に補足的データ構造92にコピーされ得る。

さらに、補足的データ構造92は、データベースに標準的なレコードデータ構造90および非標準的なレコードデータ構造91の最新のバージョンを特定するバージョン情報などの、標準的なレコードデータ構造および/または非標準的なレコードデータ構造に関連するレコードデータ構造情報を保有し得る。

旅行管理システム100は、補足的データ構造92に含まれるデータ(補足的コンテナデータ情報および/または標準的なレコードデータ構造情報90および/または非標準的なレコードデータ構造情報91)に基づいてETR 9を管理するためのETR制御ユニット18を含み得る。

一実施形態において、ETR制御ユニット18は、共通レコード識別子、補足的データ構造92に保有される補足的コンテナデータ、および/またはレコードデータ構造情報を用いて、標準的なPNR 90および非標準的なPNR 91からレコードを共通のデータに関して同期して周期的に除去するように構成された除去モジュール180を含み得る。

特定の実施形態において、ETR制御ユニット18は、補足的データ構造92に保有されるデータに基づいて標準的なPNR 90および非標準的なPNR 91の同じレコード識別子への同時アクセスを扱うためのアクセスマネージャ181を含み得る。そのような実施形態において、補足的データ構造は、データベース8に標準的なレコードデータ構造90および非標準的なレコードデータ構造91の最新のバージョンを特定するバージョン情報をさらに保有し得る。例えば、ETR 9がコンテキストからデータベースに保存される度に、バージョン情報が、補足的データ構造92で更新される。アクセスマネージャ181は、補足的データ構造92に保有されたバージョン情報に基づいてETR 9へのアクセスを管理するように構成され得る。

本明細書において説明された本発明の実施形態のいずれかを具現化するプログラムコードは、さまざまな異なる形態のプログラム製品として個々にまたはまとめて配布され得る。特に、プログラムコードは、コンピュータ可読記憶媒体および通信媒体を含み得るコンピュータ可読媒体を用いて配布され得る。本質的に非一時的であるコンピュータ可読記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報の記憶のための任意の方法またはテクノロジーで実装された揮発性および不揮発性の取り外し可能なおよび取り外し不可能な有形の媒体を含み得る。コンピュータ可読記憶媒体は、RAM、ROM、消去可能プログラマブル読み出し専用メモリ(EPROM)、電気的消去可能プログラマブル読み出し専用メモリ(EEPROM)、フラッシュメモリ、もしくはその他のソリッドステートメモリテクノロジー、ポータブルコンパクトディスク読み出し専用メモリ(CD-ROM)、もしくはその他の光学式記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、もしくはその他の磁気式記憶デバイス、または所望の情報を記憶するために使用可能であり、コンピュータによって読み取り可能である任意のその他の媒体をさらに含み得る。通信媒体は、コンピュータ可読命令、データ構造、またはその他のプログラムモジュールを具現化し得る。限定ではなく例として、通信媒体は、有線ネットワークまたは直接有線接続などの有線媒体、ならびに音響、RF、赤外線、およびその他の無線媒体などの無線媒体を含み得る。上記の媒体のうちの任意のものの組み合せも、コンピュータ可読媒体の範囲に含まれる可能性がある。

本明細書において説明された方法は、本明細書において規定された機能/動作を実施するための命令を実行するプロセッサを有する機械を製造するために任意の種類のコンピュータのプロセッサに供給されたコンピュータプログラム命令によって実施され得る。これらのコンピュータプログラム命令は、特定の方法で機能するようにコンピュータに指示し得るコンピュータ可読媒体に記憶される可能性もある。その目的で、コンピュータプログラム命令は、一連の動作のステップの実行を引き起こし、それによって、実行された命令が本明細書において規定された機能/動作を実施するためのプロセスを提供するようにコンピュータで実施されるプロセスを生成するためにコンピュータにロードされ得る。

本発明の実施形態がさまざまな例の説明によって示され、これらの実施形態はかなり詳細に説明されたが、添付の特許請求の範囲をそのような詳細に制限するかまたはいずれかの方法で限定することは出願人の意図するところではない。さらなる利点および修正は、当業者に容易に明らかになる。したがって、本発明のより広い態様の本発明は、特定の詳細、代表的な方法、および示され、説明された例示的な例に限定されない。特に、抜粋の要素がコンテンツを再編成することに関して説明されたが、抜粋の要素は、異なる種類の動作のためにコンテンツにアクセスするために内部アプリケーションによってより広く使用され得る。データコンテナの属性をフィルタリングするために適用されるフィルタリング規則は、意図される動作に応じて変わり得る。

1 旅行管理システム、GDS
2 インターフェース
3 コンテンツ管理エンジン
4 標準的なコンテンツプロバイダシステム、標準的な旅行プロバイダシステム
5 非標準的なコンテンツプロバイダシステム、非標準的な旅行プロバイダシステム
6 旅行者のデバイス
7 ユーザクライアント、クライアントデバイス
8 データベース
9 拡張されたレコードデータ構造、拡張された旅行レコード
10 動作環境
11 メッセージ交換ユニット、マッピングエンジン
12 データコンテナコンバータ
13 通信ネットワーク
14 第1のメッセージ交換フォーマット
15 第2のメッセージ交換フォーマット
18 ETR制御ユニット
20 ネットワーク
21 ビジネスオブジェクトモデル
22 ネットワーク、ビジネスオブジェクトモデル
30 旅行コンテンツ管理エンジン、コンピュータ、アプリケーションサーバ
32 プロセッサ
34 メモリ
36 大容量記憶メモリデバイス
38 入力/出力(I/O)インターフェース
40 GDSコンテンツプロバイダ、標準的な旅行プロバイダ、ヒューマンマシンインターフェース
42 外部リソース
44 データベース
46 オペレーティングシステム
48 アプリケーション
50 非GDS旅行プロバイダ、データ構造、非標準的なデータコンテナ
51 キー
52 値
53 参照
60 末端の消費者のシステム
70 旅行代理店、旅行代理店システム
90 標準的なレコードデータ構造
91 非標準的なレコードデータ構造
92 補足的データ構造
100 旅行管理システム、コンテンツ管理システム
111 構造変換エンジン
112 データ交換メッセージジェネレータ
113 ローカルマッピング規則
115 ローカル構造記述ファイル
117 クライアントマッピング規則
180 除去モジュール
181 アクセスマネージャ
900 乗客名記録(PNR)データ構造

Claims (13)

1組のアプリケーションおよび拡張されたレコードデータ構造を含むコンテンツ管理システム(100)においてコンテンツにアクセスする方法であって、前記拡張されたデータ構造は、標準的なデータコンテナの形態で予め定義された標準的な種類の標準的なデータ要素を含むレコードを記憶するための標準的なレコードデータ構造(90)および非標準的なデータコンテナの形態で前記予め定義された標準的な種類とは異なる種類を有する非標準的なデータ要素を含むレコードを記憶するための非標準的なレコードデータ構造(91)を含み、前記方法は、アクセス基準にしたがって前記拡張されたレコードデータ構造の1組の関連するデータ要素にアクセスするアプリケーションからの要求に応答して、
a. 前記1組の関連するデータ要素の中の各データ要素に関して、フィルタリング規則にしたがって前記拡張されたレコードデータ構造(9)のデータ要素に関連するデータコンテナの属性をフィルタリングするステップと、
b. 一意の抜粋の種類を割り振られ、前記データコンテナの前記1組のフィルタリングされた属性を含む抜粋のコンテナを生成するステップと、を含む、方法。

それぞれの非標準的なデータコンテナは、前記非標準的なデータコンテナの属性の構造を記述する構造記述ファイルに関連付けられ、ステップa.は、予め定義されたマッピングスキームにしたがって前記非標準的なデータコンテナに関連する構造記述ファイルを目標の構造記述ファイルに変換することをさらに含み、前記フィルタリング規則は、前記目標の構造記述ファイルに適用される請求項1に記載の方法。

ステップa.は、それぞれの標準的なデータ要素に関して、前記拡張されたレコードデータ構造(9)のデータ要素に関連する非標準的なデータコンテナを構造記述ファイルに関連する非標準的なデータコンテナに予め変換することを含む請求項1または2に記載の方法。

前記抜粋のコンテナは、ビジネスオブジェクトモデルである請求項1から3のいずれか一項に記載の方法。

前記アクセス基準は、順序付け基準である請求項1から4のいずれか一項に記載の方法。

c. 前記順序付け基準にしたがって抜粋の要素を順序付けるステップと、
d. 前記順序付けられた抜粋の要素を前記アプリケーションに返すステップと、をさらに含む請求項5に記載の方法。

前記順序付け基準は、時間属性に関連する時間順を含み、予め定義されたフィルタリング規則は、前記時間属性に対応する請求項5または6に記載の方法。

予め定義された順序は、属性の種類に関連するアルファベット順であり、予め定義されたフィルタリング規則は、前記種類の属性に対応する請求項5または6に記載の方法。

前記非標準的なデータコンテナは、その種類を定義する属性を含み、前記構造記述ファイルは、前記種類に関連して記憶される請求項2から8のいずれか一項に記載の方法。

前記構造記述ファイルは、XSDスキーマであり、前記予め定義されたマッピングスキームは、XSLTスタイルシートである請求項2から8のいずれか一項に記載の方法。

前記拡張されたレコードデータ構造(9)の各レコードは、レコード識別子を含み、前記拡張されたレコードデータ構造のレコードは、共通レコード識別子を共有する関連するデータ要素に対応し、前記アプリケーションは、前記共通レコード識別子を用いて前記1組の関連するデータ要素を特定する請求項1から10のいずれか一項に記載の方法。

前記非標準的なデータ要素は、それ自身を任意のアプリケーションのフォーマットにシリアル化することが可能なビジネスオブジェクトモデルである請求項1から11のいずれか一項に記載の方法。

1組のアプリケーションおよび拡張されたレコードデータ構造を含むコンテンツ管理システム(100)においてコンテンツにアクセスするシステムであって、前記拡張されたデータ構造は、標準的なデータコンテナの形態で予め定義された標準的な種類の標準的なデータ要素を含むレコードを記憶するための標準的なレコードデータ構造(90)および非標準的なデータコンテナの形態で前記標準的な予め定義された種類とは異なる種類を有する非標準的なデータ要素を含むレコードを記憶するための非標準的なレコードデータ構造(91)を含み、前記システムは、
- 予め定義されたフィルタリング規則にしたがって前記1組の関連するデータ要素の中の各データ要素に関連するデータコンテナの属性をフィルタリングし、
- 一意の抜粋の種類を割り振られ、前記データコンテナの前記1組のフィルタリングされた属性を含む抜粋のコンテナを生成する
ように構成される、システム。

Images