(57)【要約】  本技術の実施形態は、ｗｅｂサービスを代理店端末システムへ統合することに関する。１実施形態における方法は、ネイティブ横断的販売網デスクトップ上でコマンドをモニタリングするステップであって、前記コマンドはネイティブ横断的販売網（ＧＤＳ）デスクトップに対してネイティブメインフレームフォーマットで入力される、ステップ；旅行リクエストがトリガを含んでいる場合、マップベースショッピング予約システムのためのｗｅｂアプリケーションのユーザインターフェースウインドウを、ユーザインターフェース内またはネイティブウインドウ内で起動するステップ；前記ユーザインターフェース内で動作するときのインターフェースのためのローカルＨＴＴＰサーバを前記ユーザインターフェースウインドウに対して提供するステップ；前記ネイティブ横断的販売網（ＧＤＳ）デスクトップ、ＧＤＳｗｅｂサービス、および前記ユーザインターフェースウインドウの間の通信を取りまとめるステップ；を有する。【選択図】図１
2017501490.tif 000002
【特許請求の範囲】
【請求項１】
代理店端末上で実行されるゲートウェイサービスモジュールを用いて、前記代理店端末からのコマンドを受信するステップであって、前記コマンドはネイティブメインフレームフォーマットの旅行パラメータを含み、前記コマンドの少なくとも一部はトリガを含む、ステップ、
前記ゲートウェイサービスモジュールを用いて各前記コマンドを評価するステップ、
を有し、
旅行リクエストが前記トリガを含む場合、前記ゲートウェイサービスモジュールは、
前記変換されたｗｅｂサービスフォーマットリクエストを、横断的販売網のｗｅｂサービスシステムに対して提供し、
前記ｗｅｂサービスシステムから前記リクエストに対する応答を受信し、
前記応答を表示可能フォーマットで前記代理店端末上において提供する
ことを特徴とする方法。
【請求項２】
前記方法はさらに、ｗｅｂアプリケーションまたは前記代理店端末のユーザインターフェースを実行して、前記マップベース応答を表示するステップを有する
ことを特徴とする請求項１記載の方法。
【請求項３】
前記ゲートウェイサービスモジュールは、代理店が任意時点においてメインフレーム端末に対して返信してワークフローを継続できるようにする
ことを特徴とする請求項１記載の方法。
【請求項４】
代理店端末上でゲートウェイサービスモジュールを実行するステップを有し、前記ゲートウェイサービスモジュールは、
ネイティブ横断的販売網デスクトップ上でコマンドをモニタリングし、前記コマンドはネイティブ横断的販売網（ＧＤＳ）デスクトップに対してネイティブメインフレームフォーマットで入力されるものであり、
旅行リクエストがトリガを含んでいる場合、マップベースショッピング予約システムのためのｗｅｂアプリケーションのユーザインターフェースウインドウを、ユーザインターフェース内でまたはネイティブウインドウ内で起動し、
前記ユーザインターフェース内で動作するときのインターフェースのためのローカルＨＴＴＰサーバを前記ユーザインターフェースウインドウに対して提供し、
前記ネイティブ横断的販売網（ＧＤＳ）デスクトップ、ＧＤＳｗｅｂサービス、および前記ユーザインターフェースウインドウの間の通信を取りまとめる
ように構成されていることを特徴とする方法。
【請求項５】
前記ゲートウェイサービスモジュールは、代理店が任意時点においてメインフレーム端末に対して返信してワークフローを継続できるようにする
ことを特徴とする請求項４記載の方法。
【請求項６】
前記ゲートウェイサービスモジュールはさらに、前記旅行リクエストの前記ネイティブメインフレームフォーマットをＧＤＳｗｅｂサービスリクエストへ変換するように構成されている
ことを特徴とする請求項５記載の方法。
【請求項７】
前記方法はさらに、前記ＧＤＳｗｅｂサービスからの応答を前記マップベースユーザインターフェースウインドウ内で表示するステップを有する
ことを特徴とする請求項６記載の方法。
【請求項８】
前記方法はさらに、前記旅行リクエストのサードパーティシステムからの位置ベースオプションを提供するｗｅｂアプリケーションを提供するステップを有し、
前記オプションは、前記マップベース応答内のコンテンツに追加して含まれている
ことを特徴とする請求項７記載の方法。
【請求項９】
予約による前記代理店端末と前記横断的販売網との間の前記旅行リクエストの充足は、前記サードパーティサーバが旅行者の個人情報を受け取らない態様でのみ生じる
ことを特徴とする請求項８記載の方法。
【請求項１０】
プロセッサ、
前記プロセッサが制御するゲートウェイサービスモジュール、
を備え、
前記ゲートウェイサービスモジュールは、
横断的販売網のメインフレームと通信する横断的販売網端末と通信するローカル横断的販売網コネクタ、
前記横断的販売網のｗｅｂサービスと通信する横断的販売網ｗｅｂサービスクライアント、
を備え、
前記ゲートウェイサービスモジュールは、
代理店から前記横断的販売網端末に対するコマンド入力を受信し、前記コマンドは前記横断的販売網のメインフレームのフォーマットで構成されており、前記コマンドの少なくとも一部はトリガを含むものであり、
旅行リクエスト内の前記トリガを検出し、
前記旅行リクエストのフォーマットをｗｅｂサービスフォーマットリクエストへ変換し、
前記横断的販売網ｗｅｂサービスクライアントを介して前記旅行リクエストを前記横断的販売網のｗｅｂサービスへ送信し、
前記ｗｅｂサービスシステムから前記旅行リクエストに対する応答を受信する
ように構成されていることを特徴とするシステム。
【請求項１１】
前記ゲートウェイサービスモジュールはさらに、ローカルサーバと接続するローカルサーバインターフェースを備え、
前記ローカルサーバは、前記旅行リクエストのサードパーティサービスからの位置ベースオプションを提供するｗｅｂアプリケーションを提供し、
前記オプションは、前記応答のコンテンツに追加して含まれる
ことを特徴とする請求項１０記載のシステム。
【請求項１２】
予約による前記代理店端末と前記横断的販売網との間の前記旅行リクエストの充足は、前記サードパーティシステムがクレジットカード業界（ＰＣＩ）要件から守られるように生じる
ことを特徴とする請求項１１記載のシステム。
【請求項１３】
前記横断的販売網ｗｅｂサービスクライアントは、前記応答を表示する
ことを特徴とする請求項１１記載のシステム。
【請求項１４】
前記ローカル横断的販売網コネクタは、ローカルアプリケーションプログラミングインターフェース（ＡＰＩ）を用いて前記横断的販売網端末と接続される
ことを特徴とする請求項１１記載のシステム。
【請求項１５】
前記トリガは、前記メインフレームのフォーマットで記述された前記旅行リクエストに追加されるキーワードを含む
ことを特徴とする請求項１１記載のシステム。
【請求項１６】
前記旅行リクエストは、コマンドのテキスト列である
ことを特徴とする請求項１１記載のシステム。
【請求項１７】
前記横断的販売網は、Ｓａｂｒｅ（登録商標）、Ｔｒａｖｅｌｐｏｒｔ（登録商標）、Ａｍａｄｅｕｓ（登録商標）から選択され、
前記旅行リクエストは、前記選択した横断的販売網のフォーマットのコマンド文字列である
ことを特徴とする請求項１１記載のシステム。
【請求項１８】
前記ゲートウェイサービスモジュールは、前記選択した横断的販売網に基づき前記ネイティブフォーマットの前記旅行リクエストを前記ｗｅｂサービスフォーマットリクエストへパースするネイティブパーサを備える
ことを特徴とする請求項１７記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
＜関連出願に対する相互参照＞
本願は、米国仮出願６１／９１０，８５５号（２０１３年１２月２日出願、発明の名称「ＭＥＴＨＯＤＳ  ＡＮＤ  ＳＹＳＴＥＭＳ  ＦＯＲ  ＬＥＧＡＣＹ  ＣＯＭＰＡＴＩＢＬＥ  ＳＯＦＴＷＡＲＥ」）の優先権を主張する。同出願は、その参照文献を含めて、参照によりその全体が本願に組み込まれる。
【背景技術】
【０００２】
本技術は一般に、旅行予約に関する。より具体的には、代理店デスクトップ上のゲートウェイサービスを組み込むシステムと方法に関するが、これに限らない。ゲートウェイサービスモジュールは、ＧＤＳ（Ｇｌｏｂａｌ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｓｙｓｔｅｍ）ｗｅｂサービス、ＧＤＳメインフレーム端末デスクトップ、およびサードパーティ位置ベース旅行サービスの間の通信を取りまとめる。代理店は、ＧＤＳメインフレーム端末デスクトップ（例えばレガシーインターフェース）を用いて、ネイティブメインフレームリクエストを入力することができる。ゲートウェイサービスモジュールは、これらネイティブメインフレームリクエストを、ＧＤＳｗｅｂサービスによって充足されるクエリへ変換することができる。このように代理店は、慣れ親しんだＧＤＳメインフレーム端末デスクトップを使用して、ＧＤＳｗｅｂサービスから簡易な端末出力ではなくよりロバストな出力を受け取ることができる。これに際して、代理店はＧＤＳｗｅｂサービスの使い方を学習する必要はない。
【発明の概要】
【課題を解決するための手段】
【０００３】
本技術の実施形態は方法を含み、同方法は以下のステップを有する：（ａ）代理店端末上で実行されるゲートウェイサービスモジュールを用いて、前記代理店端末からのコマンドを受信するステップであって、前記コマンドはネイティブメインフレームフォーマットの旅行パラメータを含み、前記コマンドの少なくとも一部はトリガを含む、ステップ；（ｂ）前記ゲートウェイサービスモジュールを用いて各前記コマンドを評価するステップ；旅行リクエストが前記トリガを含む場合、前記ゲートウェイサービスモジュールは：（ｉ）前記変換されたｗｅｂサービスフォーマットリクエストを、横断的販売網のｗｅｂサービスシステムに対して提供し；（ｉｉ）前記ｗｅｂサービスシステムから前記リクエストに対する応答を受信し；（ｉｉｉ）前記応答を表示可能フォーマットで前記代理店端末上において提供する。
【０００４】
本技術の他実施形態は方法を含み、同方法は（ａ）代理店端末上でゲートウェイサービスモジュールを実行するステップを有し、前記ゲートウェイサービスモジュールは：（ｉ）ネイティブ横断的販売網デスクトップ上でコマンドをモニタリングし、前記コマンドはネイティブ横断的販売網（ＧＤＳ）デスクトップに対してネイティブメインフレームフォーマットで入力され；（ｉｉ）旅行リクエストがトリガを含んでいる場合、マップベースショッピング予約システムのためのｗｅｂアプリケーションのユーザインターフェースウインドウを、ユーザインターフェース内でまたはネイティブウインドウ内で起動し；（ｉｉｉ）前記ユーザインターフェースウインドウに対してインターフェースのためのローカルＨＴＴＰサーバを提供し；（ｉｖ）前記ネイティブ横断的販売網（ＧＤＳ）デスクトップ、ＧＤＳｗｅｂサービス、および前記ユーザインターフェースウインドウの間の通信を取りまとめる；ように構成されている。
【０００５】
本技術の別実施形態は、システムを含む。同システムは：（ａ）プロセッサ；（ｂ）前記プロセッサが制御するゲートウェイサービスモジュール；を備える。前記ゲートウェイサービスモジュールは：（ｉ）横断的販売網のメインフレームと通信する横断的販売網端末と通信するローカル横断的販売網コネクタ；（ｉｉ）前記横断的販売網のｗｅｂサービスと通信する横断的販売網ｗｅｂサービスクライアント；を備える。前記ゲートウェイサービスモジュールは：（１）代理店から前記横断的販売網端末に対するコマンド入力を受信し、前記コマンドは前記横断的販売網のメインフレームのフォーマットで構成されており、前記コマンドの少なくとも一部はトリガを含み；（２）旅行リクエスト内の前記トリガを検出し；（３）前記旅行リクエストのフォーマットをｗｅｂサービスフォーマットリクエストへ変換し；（４）前記横断的販売網ｗｅｂサービスクライアントを介して前記旅行リクエストを前記横断的販売網のｗｅｂサービスへ送信し；（５）前記ｗｅｂサービスシステムから前記旅行リクエストに対する応答を受信する；ように構成されている。
【０００６】
本技術の実施形態は、添付する図面によって説明している。図面はスケール合わせしたものではなく、本技術を理解するために必要でない詳細部分や理解を困難にさせる部分は省略されていることを理解されたい。本技術は、以下に説明する特定の実施形態に限定されるものではないことを理解されたい。
【図面の簡単な説明】
【０００７】
【図１】本技術の要素を実施するためのコンピュータアーキテクチャの概略図である。
【０００８】
【図２】本技術にしたがって実行される方法のフローチャートである。
【０００９】
【図３】本技術の原理を用いるホテルショッピングと予約の方法のシグナルフロー図である。
【００１０】
【図４】本技術の原理を用いるホテルショッピングと予約の方法の他例のシグナルフロー図である。
【００１１】
【図５】本技術にしたがって実行される方法のフローチャートである。
【００１２】
【図６】本技術に係る実施形態を実装するため用いられるコンピュータマシンの概略図である。
【発明を実施するための形態】
【００１３】
以下の説明において、本発明をよく理解するために、例えば特定の実施形態、手順、技術などの詳細を説明するが、これは説明目的であって限定のためのものではない。ただし本発明がこれら詳細説明とは異なる他実施形態によっても実施できることは、当業者にとって明らかであろう。
【００１４】
本明細書における“１実施形態”や“実施形態”は、当該実施形態に関して記載している特定の特徴、構造、特性が、少なくとも本発明の１実施形態において含まれていることを意味する。したがって、本明細書の様々な箇所における“１実施形態において”や“実施形態において”や“１実施形態によれば”などのフレーズ（あるいは同様のその他フレーズ）は、必ずしも全て同じ実施形態を指しているわけではない。さらに、特定の特徴、構造、特性は、１以上の実施形態において適当な態様で組み合わせることができる。さらに、本説明の文脈によっては、単数形はその複数形を含み、複数形はその単数形を含む。同様に、ハイフン付き語句（例えば“オン−デマンド”）は、ハイフンなし語句（例えば“オンデマンド”）と相互交換的に用いられる場合もある。大文字語句（例えば“Ｓｏｆｔｗａｒｅ”）は、小文字語句（例えば“ｓｏｆｔｗａｒｅ”）と相互交換的に用いられる場合もある。複数形は、アポストロフィー付きでまたはなしで提示される場合がある（例えばＰＥ’ｓまたはＰＥｓ）。イタリック体語句（例えば“Ｎ＋１”）は、イタリック体でない語句（例えば“Ｎ＋１”）と相互交換的に用いられる場合がある。このような相互交換的使用は、互いに矛盾していると解するべきではない。
【００１５】
また実施形態のなかには、タスクまたはタスクセットを実施する“手段”の観点から記載しているものもある。“手段”は、構造の観点から記載され得ることを理解されたい。例えばプロセッサ、メモリ、カメラなどのＩ／Ｏデバイス、またはこれらの組み合わせである。これに代えて“手段”は、機能や方法ステップを記述したアルゴリズムを含む場合もある。さらに他実施形態においては、“手段”は数式、散文、フローチャート、シグナル図の観点から記載される。
【００１６】
本明細書における用語は、特定の実施形態を説明する目的のみのものであり、本発明を限定することを意図したものではない。本明細書において、単数形“ａ”、“ａｎ”、“ｔｈｅ”は、明示的に除外しない限りは複数形も含むことを意図している。用語“備える”および／または“備えている”は、本明細書において、当該特徴、数値、ステップ、動作、要素、および／または部品が存在することを示しており、その他の特徴、数値、ステップ、動作、要素、部品、および／またはこれらのグループの存在や追加を排除するものではないことを、理解されたい。
【００１７】
用語“連結されている”、“接続されている”、“接続している”、“電気的に接続されている”などは、相互交換的に用いられ、電気的／電子的に接続されている状態を指す。同様に、第１要素が第２要素との間で情報信号（データ情報を含むか、またはデータ／制御情報ではないものを含むかを問わず）を電気的に送信および／または受信する（有線または無線を問わず）場合、その信号のタイプ（アナログかデジタルか）によらず、第１要素は第２要素と“接続”されている。本明細書で説明する図面（部品図を含む）は、説明目的のみのものであり、スケールを正確に記述しているとは限らない。
【００１８】
多くの旅行代理店のショッピング予約システムは、横断的販売網（ＧＤＳ）によって提供されている。主要な３つのＧＤＳは、Ｓａｂｒｅ（登録商標）、Ｔｒａｖｅｌｐｏｒｔ（登録商標）、Ａｍａｄｅｕｓ（登録商標）であり、これらは１９７０年代あるいは１９６０年代のメインフレームシステムに基づいている。
【００１９】
ＧＤＳは、２つのインテグレーション方法を提供している。第１にＧＤＳは、ローカルマシン（例えば代理店端末）上で、ネイティブテキストベースメインフレーム端末に対してデスクトップレベルインテグレーションを提供する。第２にＧＤＳは、フォーマット化されたデータ構造のテキストベースコマンドを全て実行できるｗｅｂサービスのサーバサイドスイートを提供する。従来、代理店は例えばＳａｂｒｅ  Ｒｅｄ、Ｇｏ！Ｒｅｓなどのネイティブデスクトップクライアント上で作業し、ｅｘｐｅｄｉａ．ｃｏｍ、ｈｏｔｅｌｓ．ｃｏｍ、ｋａｙａｋ．ｃｏｍなどのＯＴＡ（Ｏｎｌｉｎｅ  Ｔｒａｖｅｌ  Ａｇｅｎｃｙ）はｗｅｂサービスのみを用いている。
【００２０】
ＧＤＳデスクトップインターフェース（例えばネイティブデスクトップ環境）は、レガシーテキストベースシステムである。多年にわたって、フォーマットは必要に応じて新たなサービスやオプションを導入してきた。その結果、フォーマットは非常に複雑になり、理解しにくい形態となっている。このフォーマットに熟練するための学習曲線は非常に長くなり、専門家であっても適切なフォーマット化のアシストを継続的に必要とする。
【００２１】
旅行代理店が用いるネイティブデスクトップ環境は、ネイティブフォーマットリクエストを構築するための知識とトレーニングを必要とする。すなわちＧＤＳメインフレームは、非常に難解なテキストベース入力を、旅行代理店からの入力として必要とする。例えば“ＨＯＴＹＹＺ／１５ＪＡＮ−２７ＪＡＮ２”は、トロントピアソン空港近傍のホテルを１月１５日から２７日まで要求するリクエストと概ね等価である。クエリの複雑さにより、旅行代理店からネイティブテキストベースメインフレーム端末に対するテキストベースリクエストはより複雑になり、多くのコマンドの知識を必要とする。旅行代理店は、これらコマンドを記憶し熟練するために、時間と努力を要する。
【００２２】
ＧＤＳメインフレームは、ネイティブテキストベースメインフレーム端末に対して、難解なテキストベースフォーマットの応答を提供する。
【００２３】
これに対して、ＧＤＳのｗｅｂサービスはよりロバストな結果を提供するが、これらｗｅｂサービスは、旅行代理店がネイティブテキストベースメインフレーム端末上で用いる難解なネイティブフォーマット入力を処理するようには構成されていない。
【００２４】
ｗｅｂサービスが収集するコンテンツは、サードパーティサービスによるマップベース結果を生成するためのベースとして用いることができる。これについて以下に詳細を説明する。
【００２５】
本技術は、旅行代理店デスクトップ上で動作するゲートウェイを提供する。このゲートウェイは、ｗｅｂサービス機能をネイティブデスクトップ環境へ統合し、現在のマップベースショッピング予約システムへのシームレス移行を可能にする。
【００２６】
１実施形態において、ゲートウェイは、ＧＤＳメインフレームが使用するネイティブテキストベース入力を受信し、そのネイティブテキストベース入力をネイティブフォーマットからＧＤＳｗｅｂサービスにおいて用いるように構造化されたクエリへ変換する。他実施形態において、ネイティブテキストベース入力は、変換されることなくｗｅｂサービスサーバへ転送される。
【００２７】
ゲートウェイにより、旅行代理店はより慣れ親しんだネイティブベース入力を用いることができ、ＧＤＳｗｅｂサービスが提供するマップベースショッピング予約機能を受け取ることができる。したがってゲートウェイは、旅行代理店にとって、最小限のトレーニングと最小限の習慣的影響を必要とするに過ぎない。
【００２８】
その他利点として、本技術とアーキテクチャは、個人情報や支払情報が代理店ネットワークに残らずサードパーティサーバにアクセスしないように設計されている。このようにＰＣＩとＨＩＰＡＡへの準拠が本来的にサポートされている。すなわち、サードパーティサーバはＰＣＩやＨＩＰＰＡの要件に準じる必要はない。個人情報や支払情報に関与しないからである。ＧＤＳシステムと旅行代理店デスクトップのみが、個人情報と支払情報に対してアクセスする主体である。サードパーティサービスプロバイダは、本技術のシステムと方法を用いるであろうと想定される。ＰＣＩとＨＩＰＰＡに準拠することは負担が大きいからである。この規定準拠を除去することにより、システム利用の障壁を減少させることができる。
【００２９】
本技術のこれらおよびその他利点について、図面を参照しつつ以下に説明する。
【００３０】
図１は、本技術のコンピュータアーキテクチャ（以下、アーキテクチャ１００）の概略図である。アーキテクチャ１００は、横断的販売網（ＧＤＳ）１０５、代理店システム１１０、サードパーティサービス１１５を備える。これらコンポーネントは、例えばネットワーク１２０などのパブリックネットワークまたはプライベートネットワークを介して通信可能に接続されている。
【００３１】
ＧＤＳ１０５は、ｗｅｂサービスサーバ１２５とメインフレーム１３０を備える。ＧＤＳは、Ｓａｂｒｅ（登録商標）、Ｔｒａｖｅｌｐｏｒｔ（登録商標）、Ａｍａｄｅｕｓ（登録商標）などの既知のＧＤＳを含む場合もある。各ＧＤＳは、旅行関連リクエストについて固有のネイティブフォーマットを必要とする。旅行サービスリクエストの例は、航空便リクエストやホテルリクエストである。
【００３２】
ネイティブフォーマットリクエストは、ユーザインターフェース１４０において入力される。ユーザインターフェース１４０は、代理店システム１４０上の例えばブラウザその他のユーザインターフェースである。ネイティブフォーマットリクエストは、実施形態によっては端末インターフェース（ネイティブＧＤＳデスクトップ）に対して転送することができる。例えば、ネイティブフォーマットリクエストがトリガを含まない場合である（詳細は後述する）。上述のように、これら固有ネイティブフォーマットリクエストはメインフレーム１３０が読み取り解釈するように構成された、複雑かつ難解なコマンドを含む場合がある。メインフレーム１３０も同様に、ネイティブＧＤＳデスクトップからのリクエストに応答して、テキストベース出力のみを出力する。
【００３３】
これに対して、ｗｅｂサービスサーバ１２５は、航空便やホテルなどの旅行サービスについてのクエリに対して応答を提供し、ｗｅｂサービスサーバ１２５の出力は単純な端末出力よりもロバストである。
【００３４】
ｗｅｂサービスサーバ１２５に対してクエリを発行するために用いるクエリ構造は、メインフレーム１３０に対してクエリを発行するために用いるテキストベース入力とは異なる。したがってｗｅｂサービスサーバ１２５を用いるためには、旅行代理店はｗｅｂサービスサーバ１２５のための全く異なるコマンドセットを学習して用いなければならない。これは、メインフレーム１３０のために用いるネイティブフォーマットリクエストとは反対のものである。
【００３５】
代理店システム１１０は、ネイティブＧＤＳデスクトップ１３５、ユーザインターフェース１４０、ゲートウェイサービスモジュール１４５を備える。
【００３６】
ネイティブＧＤＳデスクトップ１３５は、代理店システム１１０上で動作する端末インターフェースである。ネイティブＧＤＳデスクトップ１３５は、上述のネイティブフォーマットリクエストを受け取る。実施形態においてネイティブＧＤＳデスクトップ１３５は、ローカルアプリケーションプログラミングインターフェース（ＡＰＩ）１８０を用いて、ゲートウェイサービスモジュール１４５と接続されている。
【００３７】
ユーザインターフェース１４０は、サードパーティシステム（例えばサードパーティサービス１１５）を通じた別タイプの旅行情報に対するアクセスを、代理店システム１１０に対して提供する。ＧＤＳは航空便やホテルの予約オプションを提供するが、ＧＤＳ外のその他サービスや商品としては、レンタルカー、エンターテイメント、その他商品やサービスが挙げられる。１例としてサードパーティサービス１１５は、位置ベース旅行サービスシステムを含む。例えばＺｏｏｍａｎｄｇｏ．ｃｏｍ  Ｉｎｃ．が提供するシステムであり、マップベースホテル予約サービスを提供するものである。
【００３８】
本技術は、ｗｅｂサービスサーバ１２５とメインフレーム１３０との間の相互運用性を提供する。これにより旅行代理店は、自身のネイティブＧＤＳデスクトップを用いることができる。ゲートウェイサービスモジュール１４５は、これら機能を提供する。
【００３９】
一般にゲートウェイサービスモジュール１４５は、ネイティブＧＤＳデスクトップ１３５上の通信（例えばリクエスト）をモニタリングし、必要に応じてユーザインターフェース１４０内でまたはネイティブウインドウ内で１以上のウインドウを起動し、ユーザインターフェースに対してユーザインターフェース１４０内で動作するときのインターフェースのためのローカルＨＴＴＰサーバ１５０を提供するように構成されている。
【００４０】
ゲートウェイサービスモジュール１４５は、ＧＤＳデスクトップ１３５、ｗｅｂサービスサーバ１２５、およびユーザインターフェース１４０の間の通信の複雑なシナリオを取りまとめる。
【００４１】
実施形態において、ゲートウェイサービスモジュール１４５は、トリガと呼ばれる単一コマンドコンポーネントを用いて、本技術の方法を実行する。これは、ネイティブＧＤＳデスクトップ１３５が用いるネイティブフォーマットテキスト入力をｗｅｂサービスサーバ１２５が使用可能なフォーマットへ変換して、旅行リクエストを充足するステップを含む。
【００４２】
トリガは、キーワード、シンボル、これらの組み合わせを含む。１例において、ネイティブフォーマットテキスト入力は、上述の“ＨＯＴＹＹＺ／１５ＪＡＮ−２７ＪＡＮ２”を含む。トリガは以下のように含めることができる：“ＨＯＴＹＹＺ／１５ＪＡＮ−２７ＪＡＮ２＊＊ＭＡＰ”。＊＊ＭＡＰがトリガである。１実施形態において、トリガはネイティブフォーマットテキスト入力に追記される。他実施形態において、トリガはコマンドコンポーネントとして用いられる。例えばＭＡＰがネイティブＧＤＳデスクトップ１３５へ入力される場合である。次のネイティブフォーマットテキスト入力は、ｗｅｂサービスサーバ１２５が使用可能なフォーマットへ変換される。
【００４３】
実施形態において、トリガは難解なネイティブフォーマットキーワードを含むことができる。
【００４４】
したがって、トリガと呼ばれる単一コマンドコンポーネントは、ゲートウェイサービスモジュール１４５を起動するために用いられる。スタンドアロンまたはネイティブＧＤＳフォーマットとの組み合わせいずれでもよい。したがってゲートウェイサービスモジュール１４５は、代理店が新フォーマットによって負荷過剰となることなく、通常の代理店ワークフローに対して“フック”するために用いられる。ゲートウェイサービスモジュール１４５は、ネイティブＧＤＳデスクトップ１３５とｗｅｂサービスサーバ１２５との間の相互運用性を提供する。これは旅行代理店にとって透過的なものである。旅行代理店は、ＧＤＳデスクトップ１３５に対してネイティブフォーマットリクエストを送信し、利用可能であればｗｅｂサービスサーバ１２５からおよび／またはサードパーティサービス１１５からロバスト応答が戻される。
【００４５】
実施形態において、ゲートウェイサービスモジュール１４５は、ネイティブフォーマットパーサ１５５を備える。ネイティブフォーマットパーサ１５５は、ネイティブＧＤＳデスクトップ１３５に対して入力されるネイティブフォーマットリクエストを捕捉する。ネイティブフォーマットパーサ１５５は、リクエストを意味のあるコンポーネントへ分解する。ネイティブフォーマットパーサ１５５は、パースしたエレメントをユーザインターフェース１４０に対して引き渡し、表示オプションに対して自動的に組み込む。
【００４６】
実施形態において、ネイティブフォーマットパーサ１５５は、ネイティブフォーマットリクエストを、ｗｅｂサービスサーバ１２５が使用するものとして許容可能なフォーマットへ変換する。他実施形態において、コマンドは変換されず、ｗｅｂサービスサーバ１２５へ直接送信される。
【００４７】
実施形態において、ゲートウェイサービスモジュール１４５は、ＧＤＳｗｅｂサービスクライアント１６０、ローカルＧＤＳ  ＡＰＩコネクタ１６５、ローカルＨＴＴＰ（ｈｙｐｅｒ  ｔｅｘｔ  ｔｒａｎｓｆｅｒ  ｐｒｏｔｏｃｏｌ）サーバ１５０を備える。ゲートウェイサービスモジュール１４５は、代理店システム１１０のメモリ内に格納することができ、代理店システム１１０のプロセッサによって実行される。プロセッサとメモリの例を図６に示す。
【００４８】
本明細書において、用語“モジュール”は、特定用途集積回路（ＡＳＩＣ）、電子回路、１以上のソフトウェアやファームウェアプログラムを実行するプロセッサ（共有、専用、またはグループ）、複合論理回路、および／またはその他適当なコンポーネントなどであってもよい。
【００４９】
ＧＤＳｗｅｂサービスクライアント１６０は、ＧＤＳ１０５のｗｅｂサービスサーバ１２５とのインターフェースである。ネイティブフォーマットパーサ１５５が生成した変換後コマンドは、ＧＤＳｗｅｂサービスクライアント１６０を用いてｗｅｂサービスサーバ１２５に対して提供される。
【００５０】
ローカルＧＤＳ  ＡＰＩコネクタ１６５は、ＧＤＳデスクトップ１３５からネイティブフォーマットリクエストを受け取る。ローカルＨＴＴＰサーバ１５０は、ユーザインターフェース１４０とサードパーティサービス１１５との間の通信接続を提供する。
【００５１】
図２は、本技術の方法の例を示す。同方法は、代理店端末上で実行されるゲートウェイサービスモジュールを用いて代理店端末からコマンドを受け取るステップ２０５を有する。上述のように、各コマンドはネイティブメインフレームフォーマットの旅行パラメータ（個々のコマンドまたはコマンドセグメント）を含む。これらコマンドの１以上はトリガを含み、同トリガによりゲートウェイサービスモジュールは本方法の後続ステップを実行する。旅行代理店は、テキストベース応答に代えてマップベース応答を取得したいとき、トリガを入力することを理解されたい。
【００５２】
１例において、旅行リクエストは、代理店がネイティブＧＤＳデスクトップ１３５に対して入力したコマンド文字列とトリガを含む。トリガが存在する場合、ゲートウェイサービスモジュールはさらに、オプションとして旅行リクエストのフォーマットをｗｅｂサービスフォーマットリクエストへ変換する（ステップ２１０）ことにより、本方法を実行する。
【００５３】
次に本方法は、ゲートウェイサービスモジュールが変換後のｗｅｂサービスフォーマットリクエストを横断的販売網のｗｅｂサービスシステムに対して提供するステップ２１５を含む。
【００５４】
本方法は、ゲートウェイサービスモジュールがｗｅｂサービスシステムからリクエストに対する応答を受け取るステップ２２０を含む。ＧＤＳのｗｅｂサービスシステムがリクエストに対する応答を取得できた場合、本方法はゲートウェイサービスモジュールが代理店端末／システム上で表示可能なフォーマットで応答を提供するステップ２２５を含む。例えばｗｅｂサービス応答は、代理店システムのネイティブウインドウ上でまたはユーザインターフェース１４０上で表示することができる。
【００５５】
これに代えて、ｗｅｂサービスシステムがリクエストを充足できなかった場合、本方法は旅行リクエストをネイティブフォーマットでＧＤＳのメインフレームに対して提供するステップ２３０を含む。本方法は次に、ＧＤＳのメインフレームがテキスト応答を代理店システムに対して返信するステップ２３５を含む。すなわちＧＤＳのメインフレームは、マップベース応答が利用可能でない場合、代理店システム上のＧＤＳ端末に対してテキスト応答を提供する。ステップ２３０と２３５はオプションステップであり、ｗｅｂサービスリクエストが利用可能でないまたは望まれていない場合のみ実行される。
【００５６】
図３は、本技術の原理を用いるホテルショッピングと予約の方法のシグナルフロー図である。このフロー図は、セッション共有（バイナリトークンの生成および使用）できるＳａｂｅｒＧＤＳを用いることに留意されたい。フロー図の最初のセグメントは、ホテルショッピングプロセスとその後の予約プロセスを可能にする初期化プロセスに関するものである。
【００５７】
本実施形態において、旅行リクエストは旅行代理店によりネイティブＧＤＳデスクトップ１３５に対して入力される。これは、“＊＊ＭＡＰ”トリガを含むネイティブフォーマットリクエストを含む。ネイティブフォーマットリクエストの航空便部分は、ＧＤＳメインフレーム１３０に対して提供される。ＧＤＳメインフレーム１３０は、リクエストされた航空便を予約する。ＧＤＳメインフレーム１３０は、複数代理店／ユーザ間のセッション共有するために用いることができるバイナリトークンを戻す。
【００５８】
ネイティブフォーマットリクエストはトリガを含むので、ゲートウェイサービスモジュール１４５は、マップベース検索結果を表示する準備の過程において、ユーザインターフェース１４０を起動させる。
【００５９】
マップは、ユーザインターフェース１４０のため、サードパーティサービス１１５が検索したホテル位置からダウンロードされる。ネイティブフォーマットリクエストは、ネイティブＧＤＳデスクトップ１３５が受け取るとき、様々な方向で提供され得ることを理解されたい。第１に、ネイティブフォーマットリクエストは、ＧＤＳメインフレーム１３０に対して提供される。変換されたネイティブフォーマットリクエストは、ｗｅｂサービスサーバ１２５に対して提供され、変換された応答はサードパーティサービス１１５に対して提供される。サードパーティサービス１１５は、リクエストの位置ベース部分を充足することができる。ｗｅｂサービスサーバ１２５は、リクエストされた旅行プランとしてのロバストで構造化されたホテルの応答を充足する。
【００６０】
ゲートウェイサービスモジュール１４５は、ユーザインターフェース１４０上で表示するための、リクエストされた旅行プランを提供する。
【００６１】
ホテルショッピングプロセスにおいて、旅行セグメントがユーザインターフェース１４０上に表示される。旅行セグメントは、１以上の旅行体験の部分を含む場合がある。例えば旅行者は、１つの場所へ旅行する場合もあるし複数場所へ旅行する場合もある。他例において、旅行者は１つの場所へ旅行するが、その旅程を複数のホテルが必要なように分割する。
【００６２】
いずれのイベントにおいても、ホテルが必要な場所はユーザインターフェースにおいて選択できる。一般にユーザインターフェース１４０は、旅行代理店が旅行セグメントを視認および選択し、所望エリアを選択し、ホテルをブラウズし、空き状況とレートを視認し、その他プロセスを実施できるようにする様々なＧＵＩを、旅行代理店に対して提供する。
【００６３】
本例において、サードパーティサービス１１５は、選択されたエリアからホテル位置情報を取得し、選択されたホテルをＧＵＩ内で旅行代理店に対して提供する。サードパーティサービス１１５は、例えば画像、レビュー、書誌データ、その他ロバスト情報などのようなホテルのコンテキスト情報を提供する。この情報は、ｗｅｂサービスサーバ１２５から収集した空き状況とレートの情報と組み合わせられる。
【００６４】
予約プロセスは、フォームに記入するステップと選択したホテルの予約を確認するステップを含む。この予約プロセスは、クレジットカード番号、社会保障番号、氏名などの取り扱いに注意を要する情報に関与するので、ＧＤＳと代理店システムはＰＣＩとＨＩＰＰＡの要件に準拠しなければならない。サードパーティサービス１１５は、取り扱いに注意を要する情報に対するアクセスを有さず、ＰＣＩとＨＩＰＰＡに準拠する必要はない。
【００６５】
図４は、本技術の原理を用いるホテルショッピングと予約の方法のシグナルフロー図である。このフロー図はＴｒａｖｅｌｐｏｒｔまたはＡｍａｄｅｕｓＧＤＳを用い、これらはいずれもセッション共有しないことに留意されたい。本方法は、ＧＤＳメインフレーム１３０がバイナリトークンを生成しない点を除いて、図３のものと同様である。
【００６６】
図５は、本発明に基づき実行される方法の例のフローチャートである。本方法は、代理店システムによって実行される。代理店システムは、ゲートウェイサービスモジュールを備える。ゲートウェイサービスモジュールは、代理店システム上に格納されている。ゲートウェイサービスモジュールは、代理店システムのプロセッサによって制御される。
【００６７】
１実施形態において、本方法は、代理店端末上でゲートウェイサービスモジュールを実行するステップ５０５を有する。実施形態において、ゲートウェイサービスモジュールはさらに、例えばネイティブ横断的販売網システムデスクトップ上のコマンドをモニタリングするステップ５１０などの本方法のステップを実行する。コマンドは、ネイティブメインフレームフォーマットでネイティブ横断的販売網（ＧＤＳ）デスクトップに対して入力されることを、理解されたい。
【００６８】
次に本方法は、旅行リクエストがトリガを含む場合、マップベースショッピング予約システムのｗｅｂアプリケーションのユーザインターフェースウインドウを、ユーザインターフェース内でまたはネイティブウインドウ内で起動するステップ５１５を含む。
【００６９】
本方法は、ユーザインターフェースウインドウに対してローカルＨＴＴＰサーバを提供するステップ５２０を有する。これは、ユーザインターフェース内で動作するときのインターフェースである。
【００７０】
次に本方法は、ユーザインターフェースウインドウを用いて、ネイティブ横断的販売網（ＧＤＳ）デスクトップとＧＤＳｗｅｂサービスとの間の通信を取りまとめるステップ５２５を有する。これは例えば、ネイティブメインフレームリクエストをｗｅｂサービスフォーマットのリクエストへ変換するステップ、ｗｅｂサービスフォーマットリクエストに対してｗｅｂサービス応答を戻すステップ、さらに実施例によってはｗｅｂサービス応答が存在しないときメインフレーム応答を戻すステップを含む。これら機能はユーザインターフェースウインドウを介して実現され、これにより旅行代理店はメインフレーム応答に代えて（またはこれに加えて）ｗｅｂサービス応答を受け取ることができる。このプロセスにより旅行代理店は、シンプルなテキスト応答ではなく、ロバストで情報量の多い応答を受け取ることができる。さらにサードパーティ位置サービスは、必要に応じて応答を補強することができる。
【００７１】
図６は、コンピュータシステム１の形態のマシン例であり、本明細書の方法のいずれか１以上をマシンに実施させる命令セットが実行される。様々な実施形態において、マシンはスタンドアロンデバイスとして動作し、または他マシンと接続される（例えばネットワーク化される）。ネットワーク配置において、マシンはサーバ−クライアントネットワーク環境におけるサーバマシンまたはクライアントマシンとして動作する。あるいはピアトゥピア（または分散）ネットワーク環境におけるピアマシンとして動作する。マシンは例えば、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、セットトップボックス（ＳＴＢ）、携帯情報端末（ＰＤＡ）、携帯電話、ポータブル音楽プレイヤ（例えばＭｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ  Ａｕｄｉｏ  Ｌａｙｅｒ  ３（ＭＰ３）プレイヤなどのポータブルハードドライブ音楽デバイス）、ｗｅｂアプライアンス、ネットワークルータ、スイッチまたはブリッジ、その他マシンがとるべきアクションを特定する命令セット（シーケンシャルである場合とそうでない場合を含む）を実行することができるマシンである。さらに、単一のマシンのみを示しているが、用語“マシン”は、個別にまたは連携して命令セットを実行して本明細書の方法のうちいずれか１以上を実施するマシンの集合を含む。
【００７２】
コンピュータシステム１の例は、プロセッサまたはマルチプロセッサ５（例えばｃｅｎｔｒａｌ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ（ＣＰＵ）、ｇｒａｐｈｉｃｓ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ（ＧＰＵ）、またはこれら双方）、メインメモリ１０、固定メモリ１５を備え、これらはバス２０を介して相互通信する。コンピュータシステム１はさらに、英数字入力デバイス３０（例えばキーボード）、カーソル制御デバイス（例えばマウス）、音声認識またはバイオ認証ユニット（図示せず）、ドライブユニット３７（ディスクドライブユニットとも呼ばれる）、信号生成デバイス４０（例えばスピーカ）、ネットワークインターフェースデバイス４５を備える。コンピュータシステム１はさらに、データを暗号化するためのデータ暗号化モジュール（図示せず）を備えてもよい。
【００７３】
ディスクドライブユニット３７は、コンピュータまたはマシン読取可能媒体５０を備える。これらには、本明細書の方法または機能のいずれか１以上を実装しまたは利用する１以上の命令セットとデータ構造（例えば命令５５）が格納されている。命令５５は、コンピュータシステム１が実行する間、そのすべてまたは一部がメインメモリ１０内に格納され、および／またはプロセッサ５内に格納される。メインメモリ１０とプロセッサ５は、マシン読取可能媒体を構成する。
【００７４】
命令５５はさらに、既知の送信プロトコル（例えばＨｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ））を利用して、ネットワークインターフェースデバイス４５を介してネットワーク上で送受信することができる。マシン読取可能媒体５０は実施形態において単一媒体として示しているが、用語“コンピュータ読取可能媒体”は、１以上の命令セットを格納する単一媒体または複数媒体（例えば集中または分散データベースおよび／または関連するキャッシュとサーバ）を含む。用語“コンピュータ読取可能媒体”は、マシンが実行して当該マシンに本願の方法を実施させる命令セットを格納し、エンコードし、搬送することができる任意の媒体、あるいはその命令セットが利用しまたは関連付けられたデータ構造を格納し、エンコードし、搬送することができる任意の媒体を含む。したがって、用語“コンピュータ読取可能媒体”は、固体メモリ、光磁気媒体、搬送波信号を含むが、これらに限らない。これら媒体は、ハードディスク、フロッピーディスク、フラッシュメモリカード、デジタルビデオディスク、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、などを含むがこれらに限らない。本明細書の実施形態は、コンピュータ、ハードウェア、ソフトウェアとハードウェアの組み合わせ上にインストールされたソフトウェアを備える動作環境において実装することができる。
【００７５】
インターネットサービスは、インターネットサービスに接続された１以上のコンピュータデバイスに対してインターネットアクセスを提供するように構成されること、およびコンピュータデバイスは１以上のプロセッサ、バス、メモリデバイス、ディスプレイデバイス、入出力デバイスを備えることを、当業者は理解するであろう。さらにインターネットサービスは、１以上のデータベース、リポジトリ、サーバなどと接続できることを、当業者は理解するであろう。これらを利用して、本明細書の実施形態を実装することができる。
【００７６】
特許請求範囲における対応する構造、材料、動作、手段またはステッププラス機能要素は、明示的に記載した他のクレーム要素と組み合わせて機能を実施するための任意の構造、材料、動作を含むことを意図している。本技術は説明目的で提示したが、記載した形態に限定することを意図するものではない。本技術の範囲と要旨から逸脱することなく多くの変更や変形ができることは、当業者にとって明らかである。実施形態は、本技術の原理とその実際的アプリケーションを説明するため、および当業者が本技術を理解して想定される特定用途に適した様々な実施形態と様々な変形をすることができるように、選択して記載した。
【００７７】
本技術の要素は、本技術の実施形態に係る方法、装置（システム）、コンピュータプログラム製品のフローチャートおよび／またはブロック図を参照して説明した。フローチャートおよび／またはブロック図の各ブロック、フローチャートおよび／またはブロック図のブロックの組み合わせは、コンピュータプログラム命令によって実装できることを理解されたい。これらコンピュータプログラム命令は、汎用目的コンピュータ、特定用途コンピュータ、その他プログラム可能データ処理装置のプロセッサに対して提供してマシンを生成し、コンピュータその他プログラム可能データ処理装置が実行することによりフローチャートおよび／またはブロック図のブロックが指定する機能／動作を実装する手段を生成することができる。
【００７８】
コンピュータプログラム命令は、コンピュータ読取可能媒体に格納することができる。コンピュータプログラム命令は、コンピュータ、その他プログラム可能データ処理装置、その他デバイスを特定の態様で機能するように指示することができる。これにより、コンピュータ読取可能媒体に格納された命令は、フローチャートおよび／またはブロック図のブロックが指定する機能／動作を実装する命令を含む製品を生成することができる。
【００７９】
コンピュータプログラム命令は、コンピュータ、その他プログラム可能データ処理装置、その他デバイスへロードして、コンピュータ、その他プログラム可能データ処理装置、その他デバイスが動作ステップを実施し、コンピュータ実装したプロセスを生成することができる。これにより、コンピュータその他プログラム可能装置上で実行される命令が、フローチャートおよび／またはブロック図のブロックが指定する機能／動作を実装するプロセスを提供することができる。
【００８０】
図面のフローチャートとブロック図は、本技術の実施形態に基づき実装できるシステム、方法、コンピュータプログラム製品のアーキテクチャ、機能、動作を示している。この点について、フローチャートまたはブロック図の各ブロックは、モジュール、セグメント、コード部分を表す。これらは、特定の論理機能を実装する１以上の実行可能命令を含む。代替実施例において、ブロックが示す機能は図面が示す順番以外で発生し得る。例えば連続する２つのブロックは、実際には実質的に同時実行され得る。あるいはこれらブロックは逆順で実行され得る。これらは関連する機能に依拠する。ブロック図および／またはフローチャートの各ブロック、およびブロック図および／またはフローチャートのブロックの組み合わせは、特定機能または動作を実施する特定用途ハードウェアベースシステム、または特定用途ハードウェアとコンピュータ命令の組み合わせによって実装できる。
【００８１】
上述のシステムの実施形態や実施例は説明目的のものであり、当業者が理解するようにシステムの範囲内で様々な等化変形が可能である。例えばプロセスやステップは所与の順番で提示されているが、代替実施形態において異なる順番でステップを実施でき、プロセスやステップの一部を除去、移動、追加、分割、組み合わせ、および／または変更して代替物またはサブコンビネーションを提供することができる。これらプロセスまたはステップは、様々な方法で実装することができる。プロセスやステップは連続的に実施するよう示しているが、これらプロセスやステップは並行実施することができ、あるいは異なる時点で実施することができる。
【００８２】
様々な実施形態を説明したが、これらは例示のためのみに提示したものであり、限定のためのものではないことを理解されたい。本明細書は、本発明の範囲を記載した特定の形態に限定することを意図したものではない。むしろ本明細書は、特許請求範囲が定義し当業者が理解する本発明の要旨と範囲内に含まれる代替物、変形物、等価物をカバーすることを意図している。したがって望ましい実施形態の幅と範囲は、上記実施形態によって限定すべきものではない。
【図１】
2017501490.tif 000003
【図２】
2017501490.tif 000004
【図３】
2017501490.tif 000005
【図４】
2017501490.tif 000006
【図５】
2017501490.tif 000007
【図６】
2017501490.tif 000008
【国際調査報告】
2017501490.tif 000009
2017501490.tif 000010
2017501490.tif 000011
2017501490.tif 000012
2017501490.tif 000013