JP4988307B2

JP4988307B2 - コンテキスト・ベースのナビゲーション

Info

Publication number: JP4988307B2
Application number: JP2006298853A
Authority: JP
Inventors: ロバート・ハリス; ウィリアム・レスリー・イエイツ; ケヴィン・リチャード・ラッセル
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2005-11-26
Filing date: 2006-11-02
Publication date: 2012-08-01
Anticipated expiration: 2026-11-02
Also published as: JP2007149080A; CN1972285A; GB0524166D0; US20070124445A1; TW200805972A

Description

本発明は、インターネット・ブラウジングの分野に関し、特にクライアント・サーバ環境でのコンテキスト依存ＵＲＩの生成に関する。

ブラウザ・アプリケーションは、クライアント・デバイスのところで表示するために、ウェブサーバ上に位置するウェブページを検索するために使用される。従来技術のウェブブラウザは、ユーザ・セッション中にページ・ナビゲーションを助ける機能を含む。このタイプの機能の一例としては、前に表示したウェブページを再表示するための機能がある。

「前に表示したウェブページの再表示」機能は、ブラウザのツール・バー上に位置する「進む」および「戻る」ボタンにより制御される。これらのボタンは、多くの場合、ブラウザの表示エリア上の固定位置の戻りおよび進みポインティング矢印として表示される。ブラウザがあるページにアクセスすると、そのページは通常ローカル・キャッシュに格納される。「進む」ボタンまたは「戻る」ボタンにより前に表示したウェブページにアクセスするために、「進む」または「戻る」ボタンは、ローカル・キャッシュにアクセスし、該当するウェブページを検索する。それ故、前に表示したページのブラウザのキャッシュにより、ユーザはその現在のブラウジング・セッション中にすでに表示したページにナビゲートすることができる。

ユーザ入力および出力のためにブラウザにより実行するインターネット・アプリケーションは、業界ではステートレス・プロトコルと呼ばれるＨＴＴＰプロトコルを通してアクセスされる。しかし、従来技術のインターネット・アプリケーションの場合には、ブラウザは、アプリケーションがユーザのセッションに関する情報を維持するために、各要求と一緒に「状態」情報を送信しなければならない。そのため、ユーザに関連情報を提供しなければならない。しかし、実行中のアプリケーションは、ユーザ・インタラクションの継続中有効であるいかなる整合動作状態にも依存することはできない。このことは、多くの場合、ブラウザのキャッシュ内に格納しているページが無効になることを意味する。何故なら、そのページは古い情報を含んでいるからである。あるページを再表示しようとすると、ナビゲーション・エラー応答となる。このようなナビゲーション・エラーは、ページが再表示されないことから不正確なまたは無効な情報の表示まで様々である。

既存の従来技術の解決方法は、「キオスク・モード」でブラウザを使用することによりこの問題を解決しようとする。キオスク・モードは、ブラウザのインタフェースからナビゲーション・ボタンを除去することにより、ナビゲーション・エラーの問題を無視するステップを含む。ナビゲーション・ボタンを除去すると、ユーザに対して多数の使用勝手の問題が起こる。すなわち、ミスを修正するために「進む」および「戻る」ボタンを使用することができなくなる。

従来技術のナビゲーション・ボタンが役に立つ機能を提供できないもう１つの例は、ユーザが多数の一連のページ内にある特定のページをブラウジングしている場合である。順次チェーンの例は、検索エンジン結果ページに見られる。可能性のある結果の数が多いので、結果はいくつかのページに分割される。各ページは、多くの場合、少なくとも表示する次のページおよび前のページへのリンクを含む。これらは、通常、下記の形でブラウザに表示される。
＜前へ＞＜１＞＜２＞＜３＞＜４＞＜５＞＜６＞＜次へ＞

チェーン内で次のページまたは前のページへリンクするこの方法は、ブラウザの「戻る」および「進む」ボタンとは全く異なっている。ブラウジング・セッションの開始時にチェーン内の最初のページのところにいて、「次」ページにナビゲートしようとしているユーザは、「進む」ボタンを使用しようとするかもしれない。しかし、ブラウザ・キャッシュの動作により、この機能を使用することができない（何故なら、「次」ページは表示されたことがなく、そのため「次」ページがキャッシュ内に含まれていないからである）。それ故、ユーザは現在のページ上に表示されているリンクを使用しなければならない。同様に、ユーザが、チェーン内のｎ番目のページに直接ナビゲートするためにリンクを使用し、次に、チェーン内の前のページにアクセスしようとすると、戻りブラウザ制御はこの機能を提供しない。例えば、１、２、９ページを表示した後で、従来技術の「戻る」ボタンを使用すると、実際には８ページ目を見たいのに２ページ目が再表示される。

明らかに、これらのアプローチは、通常のユーザにとって満足のいくものではない。身体に障害のあるユーザの場合にはこの状況は論外である。視覚障害のあるユーザは、ブラウザに表示されているウェブページをチェックするためにスクリーン・リーダを使用しなければならず、そのため一組のウェブページを通してナビゲートする何らかの一様ではっきりした方法が必要になる。

この問題を解決しようとするもう１つの従来技術の例は、「進む」および「戻る」ボタンに属性を取り付ける、すなわち付加するために、特殊ＨＴＭＬ構造を使用する場合である。これらの属性は、ＨＴＭＬ構造にハード・コード化され、模擬の「進む」および「戻る」ボタンを実現し得るが、それらは機能において非常に静的なものである。それは、ユーザがＨＴＭＬ構造に含まれていないページにナビゲートすると、「進む」または「戻る」ボタンが機能しなくなるからである。これを補償する唯一の方法は、もう１つのユニフォーム・リソース・ロケータ（ＵＲＩ）属性を追加するために、ＨＴＭＬ構造を手動で編集するというものである。

マルチメディア・アプリケーションを使用すると、この問題はさらに複雑になり、ＨＴＭＬ構造をページに埋め込むことができなくなる。それ故、従来技術の進みおよび戻りナビゲーション・ボタンを使用するナビゲーションの方法を改善する必要がある。

第１の態様によれば、本発明は、ブラウザ・アプリケーションに送信するために、進みナビゲーション・ボタンに関連付けるためのユニフォーム・リソース・ロケータを生成するためのインターセプタ構成要素を含む。インターセプタ構成要素は、受信したデータ・パケットがインバウンド要求であるのかどうかを判定するためのインバウンド／アウトバウンド・コントローラと、判定したインバウンド要求の一意の識別子およびユニフォーム・リソース・ロケータを識別し、一意の識別子およびユニフォーム・リソース・ロケータを格納するための構文解析構成要素とを含み、インバウンド／アウトバウンド・コントローラが、インバウンド要求に対するアウトバウンド応答を受信し、アウトバウンド応答内で一意の識別子を識別し、一意の識別子に関連するユニフォーム・リソース・ロケータの位置を発見し、インバウンド／アウトバウンド・コントローラが、進みナビゲーション動作中にナビゲートすることができるユニフォーム・リソース・ロケータの位置を知るための第２のルックアップを行い、位置を発見したユニフォーム・リソース・ロケータをアウトバウンド応答内に挿入し、応答を要求元クライアント・デバイスに送信する。

都合の良いことに、本発明は、ブラウザ環境で「進む」および「戻る」ボタンによりナビゲートすることができるＵＲＩの識別を提供する。リソースに対する要求がウェブサーバに送信される度に、インターセプタは、ＨＴＴＰデータ・パケットのＨＴＴＰヘッダ内に挿入するために、ＨＴＴＰ構造に内蔵される一対のＵＲＩを識別する。それ故、マルチメディア内に実行可能コードを埋め込むことができないマルチメディア環境で、進みおよび戻りナビゲーション・ボタンに取り付けるためのＵＲＩを識別することができる。

好ましくは、本発明は、さらに、戻りナビゲーション動作中にナビゲートすることができるユニフォーム・リソース・ロケータの位置を発見し、位置を発見したユニフォーム・リソース・ロケータをアウトバウンド応答内に挿入するためのインバウンド／アウトバウンド・コントローラを備えるインターセプタ構成要素を備える。

好ましくは、本発明は、アウトバウンド応答が要求元デバイス上で動作しているブラウザにより受信され、ブラウザ・アプリケーションが進みＵＲＩを各「進む」ボタンに取り付けるインターセプタ構成要素を備える。

好ましくは、本発明は、アウトバウンド応答が要求元デバイス上で動作しているブラウザにより受信され、ブラウザ・アプリケーションが各「戻る」ボタンに戻りＵＲＩを取り付けるインターセプタ構成要素を備える。

好ましくは、本発明は、一意の識別子がＩＰアドレスまたは状態トークンであるインターセプタ構成要素を備える。

好ましくは、本発明は、さらに、インバウンド要求で識別したＵＲＩからナビゲートすることができる少なくとも１つのＵＲＩを詳細に示すワークフロー・マップを含むインターセプタ構成要素を含む。

好ましくは、本発明は、さらに、アウトバウンド応答のＵＲＩをワークフロー・マップのノード内で識別したＵＲＩと一致させるために、ワークフロー・マップを構文解析するための状態管理構成要素を含むインターセプタ構成要素を提供する。

好ましくは、本発明は、状態管理構成要素が、一致を識別した場合に、アウトバウンド応答で識別したＵＲＩからナビゲートすることができるＵＲＩの位置を発見するために、複数の方向にワークフロー・マップを横切るインターセプタ構成要素を備える。

好ましくは、本発明は、ＵＲＩペアの各ＵＲＩが、アウトバウンド応答のＨＴＴＰヘッダ内に挿入するために、ＨＴＴＰ構造にパッケージされるインターセプタ構成要素を備える。

好ましくは、本発明は、各ＨＴＴＰ構造が、進みナビゲーション動作および戻りナビゲーション動作を識別するインターセプタ構成要素を提供する。

好ましくは、本発明は、ワークフロー・マップが、さらに、ＵＲＩ内で識別したサーバの動作作業負荷容量に関連するデータを含んでいるインターセプタ構成要素を供給することが好ましい。

好ましくは、本発明は、インバウンド／アウトバウンド構成要素が、サーバの動作作業負荷容量に応じてロード・バランシング動作を行うインターセプタ構成要素を提供する。

第２の態様によれば、本発明は、データ処理環境で動作しているサーバにリソースを要求し、すでに説明したように、アウトバウンド応答を受信することができるブラウザ・アプリケーションを提供する。

第３の態様によれば、本発明は、受信したデータ・パケットがインバウンド要求であるかどうかを判定するステップと、判定したインバウンド要求の一意の識別子とユニフォーム・リソース・ロケータを識別し、一意の識別子およびユニフォーム・リソース・ロケータを格納するステップと、インバウンド要求へのアウトバウンド応答を受信し、アウトバウンド応答内で一意の識別子を識別し、一意の識別子に関連するユニフォーム・リソース・ロケータの位置を発見するステップと、進みナビゲーション動作中にナビゲートすることができるユニフォーム・リソース・ロケータの位置を発見するために第２のルックアップを行い、位置を発見したユニフォーム・リソース・ロケータをアウトバウンド応答内に挿入し、応答を要求元クライアント・デバイスに送信するステップとを含む、ブラウザ・アプリケーションへ送信するための進みナビゲーション・ボタンに関連付けるためのユニフォーム・リソース・ロケータを生成するための方法を提供する。

第４の態様によれば、本発明は、コンピュータ・プログラムを提供する。

添付の図面を参照しながら本発明の実施形態について以下に詳細に説明するが、これは単に例示としてのものに過ぎない。

図１は、分散型コンピューティング・アーキテクチャである。複数のクライアント・デバイス１０５、１１０がインターネットのようなネットワーク１５０に接続している。クライアント・デバイス１０５、１１０は、パーソナル・コンピュータ、携帯電話、ゲーム・マシン等のような異なるコンピューティング・デバイスを含むことができる。クライアント・デバイス１０５、１１０は、例えば、ウェブサービス、音楽サービス、およびビデオ・オン・デマンド・サービスを含むマルチメディア・アプリケーションのようなリソースへのアクセスを要求する。通常、クライアント・デバイス１０５、１１０は、例えば、ＨＴＴＰおよびＴＣＰ／ＩＰのようなＯＳＩプロトコル・スタック内のプロトコルによりネットワーク１５０と相互に作用する。ネットワーク１５０は、例えば、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、大都市ネットワークおよび無線ネットワークのような任意のネットワーク・タイプを含むことができる。

各クライアント・デバイス１０５、１１０は、ユーザがリソースに対する要求を指定することができるようにするためのソフトウェアを含む。例えば、ソフトウェアは、従来のウェブブラウザ１１５、１２０またはメディア・プレーヤもしくは携帯電話等で動作する特殊ウェブブラウザを含むことができる。

要求したリソースにアクセスするために、クライアント・デバイス１０５、１１０は、ウェブブラウザ１１５、１２０を介してサービス・プロバイダにリソースに対する要求を送信する。サービス・プロバイダは、要求の位置を発見し、要求者が加入しているためにリソースに対する要求を許容できる場合には、要求者に要求したリソースを返送する。サービス・プロバイダは、ウェブサーバ１３０およびゲートウェイ１６０等のネットワークを管理する。

クライアント・コンピュータ１０５、１１０は、特定のタイプのデータ処理装置に限定されることはなく、従来のデスクトップもしくはラップトップ・パーソナル・コンピュータ、携帯情報端末（ＰＤＡ）、またはブラウザ・アプリケーションを実行することができる他の特殊データ処理装置であってもよい。クライアント・コンピュータ１０５、１１０は、無線または有線接続を介してデータ処理システムのネットワークに接続することができる。同様に、サーバ１２５は、ウェブサーバ１３０、ディレクトリ・サーバまたは類似のサーバ・プログラム、および複数のウェブページを格納するためのデータ記憶装置１３５を稼働することができる任意のデータ処理装置であってもよい。以下に詳細に説明する実施形態のソフトウェア実施要素は、どのような特定のオペレーティング・システムまたはプログラミング言語にも限定されない。

図２を参照すると、ウェブサーバ１３０は、例えば、メディア・ファイルのようなリソースに対するクライアント・デバイス１０５、１１０からの要求を処理するための複数の構成要素を含む。

ウェブサーバ１３０は、クライアント・デバイス１０５、１１０から要求を受信し、要求されたメディア・ファイルおよび他のリソースの形での応答を要求元クライアント・デバイス１０５、１１０へ送信するための通信構成要素２００、メディア・ファイルを格納するためのデータ記憶装置１３５、およびデータ記憶装置１３５内の要求されたメディア・ファイルの位置を発見するために、クライアントの要求を構文解析するためのルックアップ構成要素２０５を含む。これら各構成要素については以下に順次説明する。

通信構成要素２００は、要求元クライアント・デバイス１０５、１１０からのリソースに対する要求を受信し、ＨＴＴＰプロトコル、およびＴＣＰ／ＩＰプロトコルを含むＯＳＩスタックの他のネットワーク・プロトコルにより動作することができる。

リソースに対する要求は、要求されているリソースおよびその位置を識別するユニフォーム・リソース・ロケータ（ＵＲＩ）を含む。通信構成要素２００は、リソースに対する要求をルックアップ構成要素２０５に送る。要求されたリソースのデータ記憶装置内の位置を識別する経路名を識別するために、ＵＲＩに対してルックアップが行われる。ルックアップ構成要素２０５は、要求を識別した位置に送り、データ記憶装置１３５からメディア・ファイルを取り出す。要求されたリソースは、ネットワーク１５０を介して要求元クライアント・デバイス１０５、１１０と通信するために、ルックアップ構成要素２０５により通信構成要素２００に送信される。

図３は、周知の従来技術のブラウザ１１５、１２０の主要構成要素の詳細図である。これらの構成要素は、表示ウィンドウと、ウェブページ３２５のブラウジングに関する様々なアクションを行うためにユーザが選択することができる複数のボタンを含むアクション・バー３０５とを備えるユーザ・インタフェース３００を含む。アクション・バー３０５は、例えば、前に表示したウェブページ３２５をブラウジングするための「進む」ボタン３１０および「戻る」ボタン３１５を含む。ＵＲＩは、ブラウザ・ウィンドウ１１５、１２０のアクション・バー３０５上に位置するアドレス・バー内にタイプされる。

ブラウザ１１５、１２０は、ウェブサーバ１３０上の特定のポートへのＴＣＰ接続を確立することにより、リソースに対する要求を開始する。ウェブサーバ１３０は、特定のポート上で聴取（ｌｉｓｔｅｎ）し、要求の種々の態様を記述している情報ヘッダ・ストリングを有するＭＩＭＥメッセージが後に続く「Ｇｅｔ／ＨＴＴＰ／１．１」の形であってもよいブラウザ要求を待つ。要求を受信した場合には、ウェブサーバ１３０は、「２００ＯＫ」のような応答ストリング、およびそれ自身のメッセージを返送する。応答ストリングの本体は、要求されたリソースである。例１は、クライアント・デバイス１０５、１１０とウェブサーバ１３０の間の通常のＨＴＴＰ要求／応答会話である。

例１
クライアントの要求
GET/index.html HTTP/1.1
ホスト：www.mymusic.com

サーバの応答
ＨＴＴＰ／１．１２００ＯＫ
日付；２００５年１１月２２日火曜日１４：１９ＧＭＴ
サーバ：Ａｐａｃｈｅ／１．３．２５
最終更新日時：２００５年７月２日土曜日１２：０１ＧＭＴ
コンテンツ−長さ５２４
接続：アクティブ
コンテンツ・タイプ：ｍｐｓ，ｗａｖ，ｗｍｖ；ｃｈａｒｓｅｔＵＴＦ−１６

ウェブサーバ１３０は、ページ・レンダラ構成要素３２０によるレンダリングのためにブラウザ１１５、１２０に要求を返送する。

次に、「進む」ボタンおよび「戻る」ボタンが、前に表示したウェブページを通してナビゲートするためにユーザにより使用される。ユーザがブラウジング・セッションをスタートしたばかりの場合には、「進む」ボタン３１０および「戻る」ボタン３１５は、ユーザが他のウェブページ３２５を訪問するまでグレイのままであり、前に表示したウェブページ３２５のナビゲーション機能を提供するために、ＵＲＩを「進む」ボタンおよび「戻る」ボタンに取り付けることができるのは、他のウェブページ３２５を訪問したときだけである。それは、前に、ユーザが要求されたリソースを訪問したことがなく、そのためブラウザ・キャッシュ内に格納されなかったためである。

図４を参照すると、ナビゲーション機能を強化するために、本発明は、リソースに対する要求のＨＴＴＰヘッダおよび要求への応答をインターセプトして、クライアントとサーバの間の要求／応答相互作用のコンテキストを判定するためのインターセプタ構成要素４００を提供する。そのため、「進む」ボタン３１０および「戻る」３１５ボタンの属性に取り付けるために、コンテキスト依存ＵＲＩがブラウザ・アプリケーションにより受信されるＨＴＴＰヘッダに取り付けられる。

好ましい実施形態によれば、本発明は、好ましくは、サービス・プロバイダのローカル・ネットワーク１５０上に位置していて、ウェブサーバ１３０およびクライアント・デバイス１０５、１１０の間で要求を送受信することができるゲートウェイ１６０上にあるインターセプタ構成要素４００を提供する。インターセプタ構成要素４００は、クライアント・デバイス１０５、１１０から要求を受信し、ウェブサーバ１３０から応答を受信するための通信構成要素４０５と、ＩＰパーサ構成要素４１５、ＵＲＩパーサ構成要素４２５、およびＵＲＩ挿入装置構成要素４３０に対してインタフェースとしての働きをするインバウンド／アウトバウンド・コントローラ４１０と、ワークフロー・マップ４３５を含む状態管理コントローラ４２０とを備える。これらの各構成要素については以下に順次説明する。

この実施形態の通信構成要素４０５は、ゲートウェイ１６０上にあるので、ゲートウェイを介して、指定ウェブサーバ１３０宛のインバウンド・データ・パケット、または要求元クライアント・デバイス１０５、１１０宛のアウトバウンド・データ・パケットを受信する。

インバウンド・シナリオの場合には、クライアント１０５、１１０は、ブラウザのアドレス・バー内にＵＲＩをタイプすることによりリソースを要求する。ブラウザ１１５、１２０は、ＵＲＩを構文解析し、要求をＨＴＴＰデータ・パケットにパッケージする。ウェブサーバ１３０への途中、要求は、例えば、サービス・プロバイダにより管理されているゲートウェイ１６０を通して送られる。ゲートウェイ１６０は、応答のＨＴＴＰヘッダ内に挿入すべき一対のＵＲＩを決定するために、インターセプタ構成要素４００に要求を送信する。ブラウザ１１５、１２０は、応答を受信した場合、ＨＴＴＰヘッダを構文解析し、ＵＲＩを識別し、ＵＲＩをその「進む」ボタンおよび「戻る」ボタンにそれぞれ取り付ける。

通信構成要素４０５は、要求を受信すると、データ・パケットがインバウンド要求なのかまたはアウトバウンド応答なのかを判定するために、インバウンド／アウトバウンド・コントローラ４１０に要求を送信する。インバウンド／アウトバウンド・コントローラ４１０は、データ・パケットがインバウンド要求なのかアウトバウンド応答なのかを識別するＧＥＴおよびＰＯＳＴのようなＨＴＴＰ構造を識別する、データ・パケットのＨＴＴＰヘッダを構文解析する。ＨＴＴＰヘッダ内にＧＥＴおよびＰＯＳＴを含んでいれば、データ・パケットはインバウンド要求であり、含んでいなければ、データ・パケットはアウトバウンド応答である。

インバウンド／アウトバウンド・コントローラ４１０は、データ・パケットがインバウンド要求であるのか、アウトバウンド応答であるのか判定する際に、ＴＣＰ／ＩＰヘッダおよびＨＴＴＰヘッダからＩＰアドレスおよびＵＲＩを抽出するために、ＩＰ抽出装置構成要素４１５およびＵＲＩパーサ構成要素４２５とインタフェースする。当業者であれば周知のように、ＴＣＰ／ＩＰヘッダがＨＴＴＰヘッダをカプセル化していることに留意することは重要である。ネットワーク上で動作している他のデバイスとのオープン接続の生成に関連するのはＴＣＰ／ＩＰプロトコルである。

例えば、インバウンド要求のＨＴＴＰヘッダは、下記のものであってもよい。

インバウンド要求
ＴＣＰ／ＩＰヘッダ
ＩＰアドレス：１２９．５４．１６．２００
ＨＴＴＰヘッダ
GET/index.html HTTP/1.1
ホスト：www.mymusic/lastestgroovysong/song1

ＩＰパーサ構成要素４１５およびＵＲＩパーサ構成要素４３０は、ＨＴＴＰヘッダからwww.mymusic/lastestgroovysong/song1をコピーし、ＴＣＰ／ＩＰヘッダから１２９．５４．１６．２００をコピーする。

ＩＰアドレスおよびＵＲＩのコピーは、状態管理構成要素４２０内にキー・ペアとして格納される。キー・ペアを格納すると、インターセプトしたデータ・パケットが、ゲートウェイを通して通信構成要素４０５から受信ウェブサーバ１３０に送信される。受信ウェブサーバ１３０は、例えば、ｓｏｎｇｌのような要求されたリソースを見つけ、ｓｏｎｇｌを要求元クライアント・デバイス１０５、１１０に返送する。例２がアウトバウンド応答の一例を示す。

例２
アウトバウンド応答
ＴＣＰ／ＩＰヘッダ
ＩＰアドレス：１２９．５４．１６．２００

ＨＴＴＰヘッダ
ＨＴＴＰ／１．１２００ＯＫ
日付；２００５年１１月２２日火曜日１４：１９ＧＭＴ
サーバ：Ａｐａｃｈｅ／１．３．２５
最終更新日時：２００５年７月２日土曜日１２：０１ＧＭＴ
コンテンツ−長さ５２４
接続：アクティブ
コンテンツ・タイプ：ｍｐｓ，ｗａｖ，ｗｍｖ；ｃｈａｒｓｅｔＵＴＦ−１６
本体：ｓｏｎｇ１

アウトバウンド応答が、要求元クライアント・デバイス１０５、１１０に返送された場合、アウトバウンド応答はゲートウェイ１６０により受信される。

通信構成要素４０５は、アウトバウンド応答を受信し、インバウンド／アウトバウンド・コントローラ４１０に送る。インバウンド／アウトバウンド・コントローラ４１０は、アウトバウンド応答を構文解析し、受信したデータ・パケットがアウトバウンド応答なのかインバウンド要求なのかを識別する。ここでは、インバウンドおよびアウトバウンドの要求／応答を使用して本発明を説明しているが、これは説明を分かり易くするためで、実際には、ゲートウェイは、ＨＴＴＰデータ・パケットを特定のポート番号のところで受信し、受信したＨＴＴＰストリームがアウトバウンド応答なのか、インバウンド要求なのかは知らない。それ故、インバウンド／アウトバウンド・コントローラ４１０は、それがどのタイプのＨＴＴＰデータ・パケットなのかを識別するために分析ステップを実行する。

インバウンド／アウトバウンド・コントローラ４１０は、ＩＰパーサ４１５に対して機能呼出しを行い、ＩＰパーサ４１５にＩＰアドレスをコピーするように要求する。ＩＰアドレスを使用することにより、インバウンド／アウトバウンド・コントローラ４１０は、ＩＰアドレスに関連するＵＲＩを識別するためのルックアップを状態管理構成要素４２０に要求する。それ故、このルックアップは、クライアントが要求したＵＲＩを表す。

状態管理構成要素４２０は、インバウンド／アウトバウンド・コントローラ４１０から要求を受信する。状態管理構成要素４２０は、ブラウザ１１５、１２０内の「進む」ボタンおよび「戻る」ボタンに取り付けるために、ＨＴＴＰヘッダ内に挿入するＵＲＩの識別を行う。状態管理構成要素４２０は、アウトバウンド応答の抽出したＩＰアドレスにより、データ記憶装置１３５内でルックアップを行うためにインバウンド／アウトバウンド・コントローラ４１０から通信を受信する。状態管理構成要素４２０は、ＩＰアドレスに関連するＵＲＩを返送する。

状態管理構成要素４２０は、識別したＵＲＩにより、ブラウザ環境内での「進む」ボタン３１０により前方にナビゲートするためのＵＲＩ、および「戻る」３１５ボタンにより後方にナビゲートするためのＵＲＩの位置を発見するために、ワークフロー・マップ４３５内でルックアップを行う。

例えば、図５を参照すると、状態管理構成要素４２０は下記のようなＵＲＩを識別する。
www.mymusic/lastestgroovysong/song1

それ故、状態管理構成要素４２０は、ブラウザ内の「進む」ボタン３１０および「戻る」３１５ボタンにより、前後にナビゲートすることができるＵＲＩをワークフロー・マップ４３５内でルックアップを行うためにＵＲＩを使用する。例えば、／ｓｏｎｇｌ５０５から後方にナビゲートすることができるＵＲＩは、／ｈｏｍｅ５００であり、／ｓｏｎｇｌから前方にナビゲートすることができるＵＲＩは、／ｓｏｎｇ２５１０、／ｓｏｎｇ３５１５、または／ｓｏｎｇ４５２０である。

前方にナビゲートするためのＵＲＩ、および後方にナビゲートするためのＵＲＩの位置を発見する場合に、一対のＵＲＩがＵＲＩ挿入装置構成要素４３０によりＨＴＴＰヘッダ内に挿入される。ＵＲＩ挿入装置構成要素４３０が使用するＨＴＴＰ構造は下記のものであってもよい。
Intelligent_button_forward_action:www.mymusic/lastestgroovysong/song2
Intelligent_button_back_action:www.mymusic/lastestgroovysong/home

ＵＲＩ挿入装置構成要素４３０は、これら各構造を下記のようにＨＴＴＰヘッダ内に挿入する。
アウトバウンド応答
ＴＣＰ／ＩＰヘッダ
ＩＰアドレス：１２９．５４．１６．２００
ＨＴＴＰヘッダ
ＨＴＴＰ／１．１２００ＯＫ
日付；２００５年１１月２２日火曜日１４：１９ＧＭＴ
サーバ：Ａｐａｃｈｅ／１．３．２５
最終更新日時：２００５年７月２日土曜日１２：０１ＧＭＴ
コンテンツ − 長さ５２４
接続：能動
コンテンツ・タイプ：ｍｐｓ、ｗａｖ、ｗｍｖ；ｃｈａｒｓｅｔＵＴＦ−１６
本体：ｓｏｎｇ１
Intelligent_button_forward_action:www.mymusic/lastestgroovysong/song2
Intelligent_button_back_action:www.mymusic/lastestgroovysong/home

ＵＲＩ挿入装置構成要素４３０は、要求元クライアント・デバイス１０５、１１０に送信するために、通信構成要素４０５にＨＴＴＰヘッダを送信する。クライアント・デバイス１０５、１１０は、通常の方法でデータ・パケットの一部としてＨＴＴＰヘッダを受信し、ブラウザは、ページ・レンダリング構成要素３２０を介してＨＴＴＰヘッダを処理し、ＵＲＩをその「進む」ボタン３１０および「戻る」ボタン３１５にそれぞれ取り付ける。

他の実施形態の場合には、ＩＰパーサ構成要素４１５の代わりに状態トークン・コントローラ６００が使用される。このことは、ゲートウェイ１６０がリソースに対する多数の要求を受信する場合には妥当であるかもしれないが、ゲートウェイ１６０はＴＣＰ／ＩＰヘッダ内に要求元クライアント・デバイスのＩＰアドレスを含む要求を転送するのではなく、ＩＰアドレスをそれ自身のＩＰアドレスで置き換える。

例えば、クライアント・デバイスＡは、ｓｏｎｇ１に対する要求を送信し、１９２．２３．４６．１００のＩＰアドレスを有し、クライアント・デバイスＢは、ｓｏｎｇ１に対する要求を送信し、２０４．４６．７８．２００のＩＰアドレスを有する。ゲートウェイ１６０は、これら２つの要求を受信するが、ＴＣＰ／ＩＰヘッダ内のクライアントのＩＰアドレスを含む要求を転送するのではなく、各ＩＰアドレスをそれ自身のＩＰアドレスで置換する。それ故、応答がゲートウェイ１６０に戻ってきたとき、ゲートウェイ１６０はそれ自身のＩＰアドレスを見るだけであり、クライアントの各ＩＰアドレスは見えない。

それ故、受信した各要求に対して、状態トークン・コントローラ６００は、例えば、１６進の数値のような一意の識別子を生成し、この一意の識別子をＨＴＴＰヘッダに付加する。次に、要求は、図４のところで説明したように、通常の方法で処理されるが、この例の場合、状態トークンは、要求元クライアント・デバイスのＵＲＩの位置を発見するために、データ記憶装置内でルックアップを行うために使用される。

他の実施形態の場合には、ワークフロー・マップ４３５は、各ウェブサーバ１３０の負荷容量に関する追加情報を含むことができ、インバウンド／アウトバウンド・コントローラ４１０は、ロード・バランシング動作を行い、リソースに対する要求を、要求をよりよく処理することができるウェブサーバ１３０に送信することができる。サーバ１３０の動作負荷情報は、例えば、既知のネットワーク管理システムとインタフェースすることによりある時間にわたって更新することができる。

図７は本発明の動作ステップを示す。ステップ７００において、インターセプタ構成要素４００は、通信構成要素４０５を介してリソースに対する要求を受信する。通信構成要素４０５は、この要求をインバウンド／アウトバウンド・コントローラ４１０に送り、ここでコントローラ４１０は、ステップ７０５において、ＩＰアドレスおよびＵＲＩのコピーを取るために、ＩＰパーサ構成要素４１５およびＵＲＩパーサ構成要素４２５とインタフェースする。コピーは、状態管理構成要素４２０に送られ、データ記憶装置内にキー・ペアとして格納される。ステップ７１０において、要求は通常の方法でウェブサーバ１３０に転送される。

ステップ７１５において、通信構成要素４０５は、アウトバウンド応答を受信する。この応答はインバウンド／アウトバウンド・コントローラ４１０に送信され、インバウンド／アウトバウンド・コントローラ４１０は、ＩＰアドレスをコピーするためにＩＰパーサ構成要素とインタフェースする。このＩＰアドレスは、ステップ７２０においてＩＰアドレスに関連するＵＲＩの位置を発見するために、データ記憶装置のルックアップとして使用される。

状態管理構成要素４２０は、ＵＲＩを取り出し、ステップ７２５において、進みおよび戻りナビゲーション動作によりナビゲートすることができるリソースの位置を発見するためにワークフロー・マップ４３５内でルックアップを行う。

ステップ７３０において、一対のＵＲＩがＨＴＴＰ構造にパッケージされ、ステップ７３５において、応答が要求元クライアント・デバイスに送信される。

クライアント・デバイスのところで、ブラウザは、受信した応答を構文解析し、「進む」ボタンおよび「戻る」ボタンの構造を識別し、適切なＵＲＩを適切な「進む」ボタンおよび「戻る」ボタンに取り付ける。

図８を参照すると、シーケンス図は、リソースへの要求を満足させる、要求元クライアント・デバイス１０５、１１０、インターセプタ構成要素４００およびウェブサーバ１３０間の相互作用ステップを示す。

一例として、クライアント・デバイス１０５は、ブラウザ１１５、１２０を介して、イベント８００のところでｗｗｗ．ｍｙｍｕｓｉｃ．ｃｏｍからの歌を要求する。ゲートウェイ１６０は、例えば、ポート番号８０を介して要求を受信する。ゲートウェイ１６０は、ウェブサーバ１３０に要求を送信する前に、インターセプタ構成要素４００およびそのサブ構成要素を介して要求を送る。通信構成要素４０５は、要求を受信し、それをインバウンド／アウトバウンド・コントローラ４１０に送信し、このコントローラは、イベント８０５において、ＴＣＰ／ＩＰヘッダ内に含まれているＩＰアドレスを識別し、データ記憶装置内にコピーを格納するために、ＩＰパーサ４１５または状態トークン構成要素６００とインタフェースし、ＵＲＩを識別し、コピーをのＩＰアドレスと共にデータ記憶装置内に格納するために（例えば、ＩＰアドレス：１０２．４６．７３．２００、ＵＲＩ：ｗｗｗ．ｍｙｍｕｓｉｃ．ｃｏｍ）ＵＲＩパーサとインタフェースし、またはＨＴＴＰヘッダに取り付けるための一意の識別子（例えば、１６進数値）を生成するために、状態トークン構成要素６００とインタフェースする。

要求は、要求を満足させることができるウェブサーバ１３０に転送される。ウェブサーバ１３０は、イベント８１０において、要求を受信し、ＵＲＩにより、この場合は歌１である、現在要求されているリソースがどれであるかを識別し、歌１を要求元クライアント１０５、１１０に返送する。この場合も、要求はゲートウェイ１６０を通して送られ、インターセプタ構成要素４００によりインターセプトされる。インターセプタ構成要素４００は、インバウンド／アウトバウンド・コントローラ４１０により要求がインバウンド要求であるのか、アウトバウンド応答であるのかを識別する。この例の場合、要求はアウトバウンド応答であり、ＴＣＰ／ＩＰヘッダ内でＩＰアドレスが識別され、関連するＵＲＩの位置を発見するためにデータ記憶装置内でルックアップとして使用される。ＵＲＩの位置を発見した場合には、ＵＲＩは前後にナビゲートすることができる関連ＵＲＩを識別するために使用される。イベント８１５において、一対のＵＲＩがＨＴＴＰ構造に収容され、ＨＴＴＰヘッダに追加される。イベント８２０において、応答が要求元クライアント１０５、１１０に送信され、ブラウザ１１５、１２０は、ＨＴＴＰヘッダを読み出し、ＨＴＴＰ構造の存在を識別し、ＵＲＩを「進む」ボタンおよび「戻る」ボタンにそれぞれ取り付ける。

本発明の好ましい実施形態を実施することができる異機種計算環境のブロック図である。当業者であれば周知のウェブサーバの構成要素を示すブロック図である。本発明の好ましい実施形態を実施することができるウェブブラウザの構成要素を示すブロック図である。本発明の好ましい実施形態によるインターセプタ構成要素の構成要素を示すブロック図である。当業者であれば周知の階層的ウェブサイトのブロック図である。本発明の好ましい実施形態によるインターセプタ構成要素のもう１つの例を示すブロック図である。本発明の好ましい実施形態によるインターセプタ構成要素の動作ステップの詳細を示すフローチャートである。インターセプタ構成要素と他のデータ処理構成要素との相互作用のシーケンスを示すシーケンス図である。

Claims

ブラウザ・アプリケーションに送信するために進みナビゲーション・ボタンに関連付けるためのユニフォーム・リソース・ロケータを生成するためのインターセプタ構成要素であって、
受信したデータ・パケットがインバウンド要求であるのかどうかを判定するためのインバウンド／アウトバウンド・コントローラと、
判定したインバウンド要求の一意の識別子およびユニフォーム・リソース・ロケータを識別し、前記一意の識別子および前記ユニフォーム・リソース・ロケータを格納するための構文解析構成要素と、
前記インバウンド要求で識別されたＵＲＩからナビゲートすることができる少なくとも１つのＵＲIを示すワークフロー・マップを備え、
前記インバウンド／アウトバウンド・コントローラが、前記インバウンド要求に対するアウトバウンド応答を受信し、前記アウトバウンド応答内で一意の識別子を識別し、前記一意の識別子に関連するユニフォーム・リソース・ロケータを発見し、
前記インバウンド／アウトバウンド・コントローラが、進みナビゲーション動作の際にナビゲートすることができるユニフォーム・リソース・ロケータを知るための第２のルックアップを前記ワークフロー・マップ内で行い、前記発見したユニフォーム・リソース・ロケータを前記アウトバウンド応答内に挿入し、前記応答を要求元クライアント・デバイスに送信し、
前記ワークフロー・マップが、前記ＵＲＩ内で識別したサーバの動作作業負荷容量に関するデータを含む、インターセプタ構成要素。
ブラウザ・アプリケーションに送信するために進みナビゲーション・ボタンに関連付けるためのユニフォーム・リソース・ロケータを生成するための方法であって、コンピュータに下記ステップを実行させる方法において、該ステップが、
受信したデータ・パケットがインバウンド要求であるのかどうかを判定するステップと、
判定したインバウンド要求の一意の識別子およびユニフォーム・リソース・ロケータを識別し、前記一意の識別子および前記ユニフォーム・リソース・ロケータを格納するステップと、
前記インバウンド要求に対するアウトバウンド応答を受信し、前記アウトバウンド応答内で前記一意の識別子を識別し、前記一意の識別子に関連するユニフォーム・リソース・ロケータを発見するステップと、
進みナビゲーション動作中にナビゲートすることができるユニフォーム・リソース・ロケータを知るための第２のルックアップを、前記インバウンド要求で識別されたＵＲＩからナビゲートすることができる少なくとも１つのＵＲIを示すワークフロー・マップ内で行い、前記発見したユニフォーム・リソース・ロケータを前記アウトバウンド応答内に挿入し、前記応答を要求元クライアント・デバイスに送信するステップとを含み、
前記ワークフロー・マップが、前記ＵＲＩ内で識別したサーバの動作作業負荷容量に関するデータを含む、方法。
コンピュータの内部メモリ内に直接ロードすることができるコンピュータ・プログラムであって、請求項２に記載のステップをコンピュータに実行させるためのコンピュータ・プログラム。