JP4391766B2

JP4391766B2 - Browser session mobility system for multi-platform applications

Info

Publication number: JP4391766B2
Application number: JP2003157235A
Authority: JP
Inventors: ソンユ; フアチューハオ; イスラムナイーム; マサジカタギリ; ローゼンダン; ショウジクラカケ
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2002-05-31
Filing date: 2003-06-02
Publication date: 2009-12-24
Anticipated expiration: 2023-06-02
Also published as: JP2004062873A

Description

【０００１】
【発明の属する技術分野】
本発明は、概してネットワーク上の装置間における通信に関し、特に、ブラウザを用いて確立される１以上の独立したアクティブセッションのブラウザ状態を保存し、同一もしくは異なるブラウザおよび／またはプラットフォームを用いて、保存されたセッションを後で読み出して再開する方法およびシステムに関する。
【０００２】
【従来の技術】
今日、インターネットは、情報にアクセスするためばかりでなく商品やサービスを購入するために一般的に利用されている。通常、インターネットにアクセスするにはブラウザが必要である。ブラウザはインターネットを介してウェブサイトにアクセスするために利用される。このウェブサイトを介して、ユーザは情報を取得したり、商品やサービスを購入することができる。通常、ブラウザとウェブサイトとの対話はセッション指向型である。一般的に、ウェブサイトは、ブラウザに対してセッションの確立およびセッションＩＤを最初に要求する。ウェブサイトは、セッションＩＤを用いて、当該ウェブサイト内の種々のページを移動するブラウザを追跡し、識別する。
【０００３】
ブラウザは、アクティブウェブセッション中、ステートレスであるＨＴＴＰプロトコルに従ってウェブサイトと対話する際に使用されるランタイム状態を蓄積する。ブラウザのランタイム状態は、クッキー、ドキュメントオブジェクト、およびスクリプトオブジェクトとして蓄積される。ブラウザがウェブサイトへのアクセスをしばらく中断した場合や、ユーザが明示的にログアウトした場合に、アクティブウェブセッションが終了する。アクティブウェブセッションが終了すると、ブラウザ状態のいくつかは復元不能になる。
【０００４】
【発明が解決しようとする課題】
このセッション指向型モデルでは、アクティブセッションを確立したブラウザを一時的にシャットダウンする場合、ユーザは同一のアクティブセッションを継続することができない。さらに、ユーザが、ある装置上のブラウザから別の装置上の同一または別のブラウザに切り替えたい場合も、同一のアクティブセッションを継続することができない。例えば、据置型装置（デスクトップＰＣ等）上でアクティブセッションを確立しているユーザが、当該据置型装置とモバイル装置（無線アクセス機能付きポケットＰＣ等）を取り替える場合、ユーザは当該据置型装置のアクティブセッションを終了して、モバイル装置で新しいアクティブセッションを確立し直さなければならない。同様に、無線通信費用を抑えるために、他の作業をする間一時的に無線接続を中断しようとする場合、モバイル装置でアクティブセッションを確立しているユーザは当該セッションを保存することができない。
【０００５】
ブラウザを使用してウェブページにアクセスするための方法として、後でアクセスするウェブページのＵＲＬ（Uniform Resource Locator）を保存するブックマークの利用が広く知られている。例えば、マイクロソフト（登録商標）インターネットエクスプローラ（登録商標）の「お気に入り」等のブックマークの概念によれば、効率的で迅速なウェブページへのアクセスが可能になる。しかし、このようなブックマークを用いても、静的なウェブページへの再アクセスが可能になるだけである。例えば、商品の選択条件、購買情報、その他特定のアクティブウェブセッションに関する情報等のセッション特有の情報は保存されないので、再び作成する必要がある。
【０００６】
また、アクティブセッションに関する情報を保存する方法として、クッキーの利用が広く知られている。通常、クッキーはブラウザ側の記憶メカニズムであり、ブラウザを操作するユーザに関するセッション内またはセッション間の情報を保存するために用いられる。一般的に、クッキーはブラウザがアクセスしているウェブサイトにより設定され、次回アクセスする際に当該ウェブサイトに送信される情報である。クッキーはブラウザが動作している装置に送信され、保存される。ブラウザはウェブサイトにアクセスする際、以前に保存された当該ウェブサイトに対応するクッキーを利用する。しかしながら、このようなクッキーは単一の装置に関連付けられて保存されるため、他の装置上で動作するブラウザでは利用することができない。
【０００７】
さらに、いくつかのウェブサイトが提供する、ブラウザのユーザを識別してアクティブセッション中に蓄積された購買情報を保存できる方法が広く知られている。この情報は、後のセッションで読み出せるようにサーバ側のデータベースに保存される。この技術は、各ウェブサイトに対して相当のユーザ追跡能力を要求するばかりでなく、ユーザに対しても商品またはサービスの購入を決断する前にサインインプロセスを完了しなければならないという負担を負わせる。さらに、このようなウェブサイトに保存される購買情報には、例えばブラウザが以前に表示したページ、セッション中にカスタマイズされた値、および／またはブラウザナビゲーションとそれに伴うウェブサイトのカスタマイズに関する情報等、アクティブセッションに関する情報は含まれない。従って、ウェブサイトとの新しいアクティブセッションを確立する場合、以前のアクティブセッション中にカスタマイズした設定の多くは再び作成されなければならない。
【０００８】
【課題を解決するための手段】
本発明は、ブラウザセッションモビリティ（ＢＳＭ）システムに関する。ＢＳＭシステムは、アクティブセッションの取り込み、保存、および再インスタンス化をサポートする。アクティブセッションは、アプリケーションサーバおよび、一プラットフォームである通信装置上で動作するブラウザ間で確立される。アクティブセッションは、マルチプラットフォームネットワークアプリケーションのプラットフォーム依存（platform specific）バージョンを有するアプリケーションサーバによってサポートされる。アクティブセッションが確立されると、プラットフォーム依存ランタイム状態が生成される。プラットフォーム依存ランタイム状態はスナップショットとして取り込まれ、プラットフォーム非依存（platform independent）ランタイム状態に選択的に変換されて、ＢＳＭシステムのリポジトリサーバに保存される。ランタイム状態が取り込まれて変換される際には、アクティブセッションのブラウザ側ランタイム状態とサーバ側ランタイム状態とが取り込まれて選択的に変換される。または、ブラウザ側ランタイム状態のみの取り込み、選択的な変換、および保存が行われてもよい。
【０００９】
ＢＳＭシステムは、プラットフォーム非依存ランタイム状態を用いて、マルチプラットフォームネットワークアプリケーションの、異なるプラットフォーム間におけるモビリティをサポートする。プラットフォーム非依存ランタイム状態は記憶装置から読み出されると、任意のプラットフォームに依存するランタイム状態に変換される。従って、アクティブセッションの第１のプラットフォームに依存するランタイム状態は、ネットワークアプリケーションの第１のプラットフォームに依存するバージョンから取り込まれ、プラットフォーム非依存ランタイム状態に選択的に変換される。プラットフォーム非依存ランタイム状態は一旦保存され、後で読み出されると第２のプラットフォームに依存するランタイム状態に選択的に変換される。第２のプラットフォームに依存するランタイム状態は、ネットワークアプリケーションの第２のプラットフォームに依存するバージョンを用いてアクティブセッションとして再インスタンス化される。
【００１０】
ＢＳＭシステムにおいて、プラットフォーム依存ランタイム状態およびプラットフォーム非依存ランタイム状態はスナップショットと表現される。プラットフォーム依存（ＰＳ）スナップショットは、ブラウザ側およびサーバ側ランタイム状態のうち少なくともいずれか一方のプラットフォーム依存ランタイム状態を指す。プラットフォーム非依存（ＰＩ）スナップショットは、プラットフォーム非依存ランタイム状態を指す。スナップショットは、それぞれアクティブセッションの状態データおよびセッションデータを含む。ＰＩスナップショットおよびＰＳスナップショット間の変換は、マッピングに基づいて行われる。マッピングによれば、異なるプラットフォームに依存するネットワークアプリケーション間で異なる、プラットフォーム依存ランタイム状態の部分を選択的に変換できる。
【００１１】
ＢＳＭシステムによれば、従来のように、ブラウザ側ランタイム状態とブラウザが動作する装置とを関連付けるのではなく、ランタイム状態のスナップショットをユーザがアクセス可能な場所に保存することにより、ブラウザ側ランタイム状態とユーザとを関連付けることができる。さらに、ＢＳＭシステムでは、アクティブセッションと特定のプラットフォームとが関連付けられることがない。これは、サーバ側およびブラウザ側ランタイム状態の両方を含むランタイム状態を取り込んでプラットフォーム非依存ランタイム状態に選択的に変換することにより可能になる。または、プラットフォーム非依存ランタイム状態はブラウザ側ランタイム状態のみを含んでもよい。プラットフォーム非依存ランタイム状態は、プラットフォーム依存ランタイム状態に選択的に変換されることにより任意のプラットフォーム上で再インスタンス化される。
【００１２】
ＢＳＭシステムの特徴は、ＰＳスナップショットおよびＰＩスナップショット間の変換に関する。例えば、ブラウザ側ランタイム状態がＰＳスナップショットに取り込まれると、ＰＳスナップショットのブラウザ側ランタイム状態を成す状態データおよび／またはセッションデータは、ＰＩスナップショットに選択的に変換される。この変換は、マッピング記述ファイルを用いて選択的に行われる。マッピング記述ファイルによれば、ＰＳスナップショットの状態データおよび／またはセッションデータのうちプラットフォームに依存する部分が特定され、特定された状態データおよびセッションデータが、プラットフォームに依存しない状態データおよびセッションデータに変換される。
【００１３】
ＢＳＭシステムの別の特徴は、ＰＩスナップショットの生成に関する。ＰＩスナップショットは、アクティブセッションのプラットフォーム非依存ランタイム状態を指し、サーバ側ランタイム状態とブラウザ側ランタイム状態とが結合されている。サーバ側ランタイム状態がＰＩスナップショットに選択的に変換され、ブラウザ側ランタイム状態も選択的に変換されて、ＰＩスナップショットのサーバ側ランタイム状態と結合される。または、ブラウザ側ランタイム状態のみが取り込まれて、ＰＩスナップショットに選択的に変換される。
【００１４】
ＢＳＭシステムのさらに別の特徴は、異なるスナップショットのランタイム状態間におけるマッピングの設定である。マッピングは選択的に設定され、スナップショットに取り込まれる状態データおよびセッションデータの大部分または一部分が変換されたり、全く変換されなかったりする。マッピングにより指定される変換の量は、プラットフォームが異なる状態およびセッションデータ間の互換性に比例する。スナップショットの状態データおよびセッションデータが異なるプラットフォーム間で互換性をもつ場合には、マッピングによって全く変換が指定されない。一方、スナップショットの状態データおよびセッションデータの一部が互換性を持たない場合は、マッピングによって適当な変換が指定される。
【００１５】
ＢＳＭシステムのさらに別の特徴は、アクティブセッションのランタイム状態を表すスナップショットの異なる状態データおよびセッションデータ間のマッピングに関する。異なるプラットフォーム間のマッピングは、マッピング記述ファイルに記述されている。特定のプラットフォームに対して用いられるマッピング記述ファイルは、マスターマッピングファイルを用いて選択される。プラットフォームが特定されると、マスターマッピングファイルを用いて対応するマッピング記述ファイルが特定される。そして、マッピング記述ファイルを用いて、スナップショットに含まれる状態データおよびセッションデータが選択的に変換される。
【００１６】
本発明のさらなる目的および効果は、以下の説明と本発明の好適な実施形態を明示する添付の図面とを参照することにより明らかになる。
【００１７】
【発明の実施の形態】
本発明には、ブラウザを操作するユーザが１以上のアクティブセッションのブラウザ状態を保存することを可能にするブラウザ状態リポジトリ（ＢＳＲ）サービスが含まれる。ＢＳＲサービスによれば、ユーザは、任意のブラウザおよび／または装置を使用して保存されたブラウザ状態のいずれかを選択的に読み出し、当該ブラウザ状態に対応する同一のアクティブセッションを再開できる。ブラウザの現状態は、アクティブセッション中に保存された時点と同じ状態に復元される。従って、ＢＳＲサービスによれば、ユーザはアクティブセッションのブラウザ状態を消失して、新しい装置上の新しいブラウザ状態で再びやり直すことなく、アクティブセッション中に新しい装置またはブラウザに切り替えることができる。さらに、ＢＳＲサービスによれば、任意の装置またはブラウザ上で任意のアクティブセッションを保存して後で再開することができるだけでなく、ユーザは複数のアクティブセッションのブラウザ状態を同時に管理することができる。
【００１８】
図１は、ネットワーク１２を介して動作するＢＳＲサービス１０の一実施形態を示すブロック図である。ＢＳＲサービス１０は、第１の装置１４および第２の装置１６として示される少なくとも１の装置を有する。さらに、ＢＳＲサービスは、少なくとも１のリポジトリサーバ１８を有する。図１に示すように、第１および第２の装置１４、１６およびリポジトリサーバ１８はネットワーク１２を介して通信接続されている。別の態様において、ＢＳＲサービス１０は、任意の数の装置、リポジトリサーバ、および／またはネットワーク対応装置を有してよい。本明細書中において、「結合」、「接続」、または「相互接続」という用語は、電気的な結合、光学的な結合、無線による結合、および／またはシステム、装置、および／またはコンポーネント間にインターフェイスを提供するその他の結合を意味する。
【００１９】
ネットワーク１２は、例えばインターネット、公的および／または私的イントラネット、エクストラネット、および／またはデータおよびコマンド転送を可能にするその他のネットワーク構成である。ネットワーク１２内で行われる通信で用いられる通信媒体は、有線通信システムおよび／または無線通信システムである。通信媒体は、例えば、通信チャンネル、電波、マイクロ波、有線通信、光ファイバー通信、またはデータ、音声、および／または動画像情報を送信可能なその他の通信媒体である。
【００２０】
第１および第２の装置１４、１６は、ネットワーク１２を介した通信接続が可能な任意のタイプのコンピュータ装置または同様のハードウェアである。さらに、第１および第２の装置１４、１６は、ユーザインターフェイス（ＵＩ）、メモリ、マイクロプロセッサ、および／またはその他のハードウェアと関連するオペレーティングシステム／アプリケーションを有する。第１および第２の装置１４、１６は、例えば携帯電話、携帯情報端末（ＰＤＡ）、ポケットパソコン（ＰＣ）、または無線通信が可能なその他の装置であってもよい。さらに、第１および第２の装置１４、１６は、例えばネットワーク端末、パソコン、サーバ、またはネットワーク１２を介して有線通信が可能なその他の装置であってもよい。別の態様において、第１および第２の装置１４、１６は有線および無線通信機能の両方を有してもよい。
【００２１】
図１に示すように、第１の装置１４上では第１のブラウザ２０が動作する。同様に、第２の装置１６上では第２のブラウザ２２が動作する。第１および第２のブラウザ２０、２２は、ネットワーク１２上の別の装置からダウンロードしたページ特定して表示できる第１および第２の装置１４、１６上で動作する、任意のフォームのアプリケーションである。本実施形態において、第１および第２のブラウザ２０、２２は、例えばマイクロソフト（登録商標）インターネットエクスプローラ（登録商標）、および／またはネットスケープナビゲータ（登録商標）等のウェブブラウザである。別の態様において、第１および第２のブラウザ２０、２２は、ネットワーク１２を介してダウンロードした任意の形式のページを特定して表示する機能を有する、任意の形式の同種同士または異種同士のブラウザでもよい。第１および第２のブラウザ２０、２２は、テキストおよびグラフィックの表示に加えて、動画像、音声、マルチメディアおよび／またはその他情報の表示をサポートしてもよい。ＢＳＲサービス１０の動作も、第１および第２のブラウザ２０、２２によってサポートされることが望ましい。第１および第２のブラウザ２０、２２は第１および第２の装置１４、１６上で起動、操作され、リポジトリサーバ１８と連携して動作する。
【００２２】
リポジトリサーバ１８は、少なくとも１のサーバ等の、ネットワーク１２を介して要求を受信し応答を送信できる任意の形式のコンピュータ装置である。本実施形態において、リポジトリサーバ１８はＢＳＲサービス１０のインフラストラクチャ内で動作し、第１および第２の装置１４、１６から要求を受信し応答を送信する通信機能を有する。ある態様において、リポジトリサーバ１８はハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバであってもよい。この態様において、第１および第２の装置１４、１６は、ＨＴＴＰおよび／または高信頼ハイパーテキスト転送プロトコル（ＨＴＴＰＳ）を用いてリポジトリサーバ１８と通信を行うようにしてもよい。別の態様において、ファイル転送プロトコル（ＦＴＰ）、ネットニューズ転送プロトコル（ＮＮＴＰ）、簡易メール転送プロトコル（ＳＭＴＰ）、リモートメッセージインターフェイス（ＲＭＩ：Remote Message Interface）、コルバ（ＣＯＲＢＡ：Common Object Request Broker Architecture）、コンポーネントオブジェクトモデル（ＣＯＭ：Component Object Model）、公的および私的専用プロトコル等のプロトコルを用いてもよい。
【００２３】
ＢＳＲサービス１０の動作中、ユーザは、第１の装置１４上で動作する第１のブラウザ２０を使用してアクティブセッションを確立する。「アクティブセッション」という用語は、ネットワーク１２上の別の装置との任意の形式の対話を意味する。この対話では、別の装置から提供される情報が第１のブラウザ２０を操作するユーザに対して表示、通信、伝達される。典型的なアクティブセッションとして、第１のブラウザ２０を使用してウェブページおよび関連する資料の場所を特定した後、その情報をダウンロードして表示するウェブセッションがある。
【００２４】
アクティブセッションを確立してカスタマイズした後、ユーザは、ＢＳＲサービス１０を利用してアクティブセッションのブラウザの現状態を取り込んで（ｃａｐｔｕｒｅ）保存することができる。本明細書中において、アクティブセッションの「カスタマイズ」または「カスタム化」という用語は、第１のブラウザ２０を使用した対話によりブラウザ状態に蓄積されるアクティブセッションの変更を意味する。さらに、「ブラウザの現状態」または「ブラウザ状態」という用語は、ユーザがブラウザを使用して生成したアクティブセッションのカスタマイズされた状態を意味する。第１のブラウザ２０を使用して確立されるアクティブセッションのブラウザの現状態とそれに関連する属性は格納可能な形式で取り込まれる。取り込まれたアクティブセッションのブラウザの現状態は、「スナップショット」または「ブラウザスナップショット」と呼ばれる。
【００２５】
アクティブセッションのブラウザの現状態は、ブラウザキャッシュおよびブラウザ履歴により構成される。ブラウザキャッシュおよびブラウザ履歴には、ドキュメントオブジェクトおよびスクリプトオブジェクトの現状態に加えて、例えば第１のブラウザ２０が最後に表示したページが含まれる。従って、取り込まれたアクティブセッションのブラウザの現状態に含まれるページは動的でも静的であってもよい。さらに、ブラウザキャッシュおよびブラウザ履歴は、以前におよび／または最後に表示されたページ上で変更あるいは入力された値、ブラウザ履歴、クッキー、および／またはユーザによってカスタマイズ可能なアクティブセッションのブラウザの現状態に関連するその他のパラメータを含んでもよい。ユーザは、リポジトリサーバ１８を使用してネットワーク１２内にアクティブセッションのブラウザの現状態を安全に保存できる。
【００２６】
ＢＳＲサービス１０によれば、ユーザは、保存されたアクティブセッションのブラウザの現状態を後で安全に読み出すことができる。ユーザは、リポジトリサーバ１８および任意の装置上の任意のブラウザを使用して、保存されたブラウザの現状態を取り出すことができる。例えば、ユーザは、第１の装置１４上で第１のブラウザ２０、第２の装置１６上で第２のブラウザ２２、またはその他任意の装置とそれに付随するブラウザを用いてもよい。保存されたブラウザの現状態が読み出されると、アクティブセッションのブラウザ状態は復元され、同一のアクティブセッションをスナップショットが取り込まれた時点から再開できる。
【００２７】
例えば、ユーザが、オフィスのデスクトップＰＣ上で第１のブラウザ２０を操作して厚地の窓用カーテンを購入する場合を想定する。ここで、このユーザは、アクティブセッション中に別々のページ上で所望の色、図柄、および形等の選択をした後、帰宅して窓枠を測定しなければならないものとする。同様に、同一のユーザが後で航空券を購入する目的で、別のアクティブセッション中に第１のブラウザ２０を使用して別々のページ上で複数のフライトスケジュールを組むものとする。
【００２８】
ユーザは、ＢＳＲサービス１０を利用して、第１のブラウザ２０をシャットダウンする前にこれらカスタマイズされたアクティブセッションの各ブラウザの現状態を取り込む。そして、ユーザは帰宅し、窓枠を測定し、旅行の計画を仕上げ、例えばポケットＰＣ等の第２の装置１６上で第２のブラウザ２２を起動させる。ユーザは、以前に保存されたブラウザスナップショットを読み出して復元した後、アクティブセッション中にカスタマイズされたページを閲覧し、厚地の窓用カーテンの選択を完了する。さらに、ユーザは以前にカスタマイズされたページを閲覧し、以前にカスタマイズされたアクティブセッション中に組んだフライトスケジュールの１つを選択する。
【００２９】
ある態様において、ＢＳＲサービス１０はインターネットのインフラストラクチャとそれに付随するプロトコルを用いて実施可能である。この態様では、ＢＳＲサービス１０の導入にあたり、既存のウェブサイト、装置とそれに付随するブラウザにほとんど変更を加える必要がない。別の態様において、ＢＳＲサービス１０はその他任意のインフラストラクチャとそれに付随するプロトコルを用いて実施してもよい。
【００３０】
図２は、ＢＳＲサービス１０の一実施形態を示すより詳細なブロック図である。ＢＳＲサービス１０は、図１を参照して説明した実施形態と同様に、第１のブラウザ２０を搭載した第１の装置１４、第２のブラウザ２２を搭載した第２の装置１６、およびネットワーク１２を介して図２に示すように通信するリポジトリサーバ１８を有する。図２は、リポジトリサーバ１８、第１および第２の装置１４、１６各々とネットワーク１２を介して通信する少なくとも１のサイト３０を例示している。さらに、図２は、本実施形態のＢＳＲサービス１０のインフラストラクチャの一部分として、第１および第２の装置１４、１６上で動作するＢＳＲ装置モジュール３４、およびリポジトリサーバ１８上で動作するＢＳＲリポジトリモジュール３６を例示している。別の態様において、任意の数のセキュアサイトおよび／または非セキュアサイトを含むようにしてもよい。さらに、ＢＳＲサービス１０の一部分として同図に例示するモジュールの数は図２に示す数より少なくしてもよいし、多くしてもよい。
【００３１】
一方、サイト３０は、ブラウザを介した情報に対するアクセスを提供可能な、ネットワーク１２を介して通信する任意のメカニズムである。サイト３０は、不正アクセスの可能性を最小限にするためのいずれの形式のセキュリティも有しない非セキュアサイトであってもよいし、反対にセキュアサイトであってもよい。従って、第１および第２のブラウザ２０、２２は、セキュリティのレベルに応じて高信頼性（secure）または非高信頼性通信を用いてサイト３０を閲覧する。第１および第２のブラウザ２０、２２は、サイト３０が非セキュアサイトの場合、ＨＴＴＰメッセージを用いて通信し、サイト３０がセキュアサイトの場合、ＨＴＴＰＳメッセージを用いて通信する。別の態様において、サイト３０は、セキュアサイトの部分および非セキュアサイトの部分を含んでもよい。この態様において、通信は、閲覧するサイトの部分に応じて高信頼性通信と非高信頼性通信の間でシフトするようにしてもよい。
【００３２】
ＢＳＲ装置モジュール３４は、第１および第２の装置１４、１６の少なくともいずれか１つで起動される任意のアプリケーションである。ＢＳＲ装置モジュール３４は、第１および第２のブラウザ２０、２２の機能を向上させるか、もしくは連携して動作することでＢＳＲサービス１０をサポートする。本実施形態において、ＢＳＲ装置モジュール３４は、ダウンロード可能なブラウザプラグインであり、第１および第２のブラウザ２０、２２に適用可能である。一般的に、ブラウザプラグインは、アプリケーションに機能またはサービスを付加する周知の形式のアプリケーションである。別の態様において、ＢＳＲ装置モジュール３４は、第１および第２の装置１４、１６内で、第１および第２のブラウザ２０、２２の機能を向上させる独立型のモジュールであってもよい。
【００３３】
図３は、ＢＳＲ装置モジュール３４の一実施形態を示すブロック図である。本実施形態において、ＢＳＲ装置モジュール３４は、インターフェイスコンポーネント４０、セキュリティコンポーネント４２、取り込みコンポーネント４４、および復元コンポーネント４６を有する。別の態様において、ＢＳＲ装置モジュール３４は、例えばスナップショット保存機能、ユーザ認証機能、またはＢＳＲサービス１０に係るその他の機能等の付加的な機能を有してもよい。
【００３４】
インターフェイスコンポーネント４０は、第１および第２の装置１４、１６のユーザにＢＳＲサービス１０とのインターフェイスを提供する。ユーザは、このインターフェイスを使用して、ＢＳＲサービス１０の機能に加えてＢＳＲ装置モジュール３４により提供される付加的な機能の動作を命令できる。さらに、インターフェイスコンポーネント４０は、ユーザインターフェイスを特定の装置のハードウエアに適合させる変換機能を提供する。例えば、ある装置においてユーザインターフェイスはタッチスクリーンであってもよいし、別の装置においてユーザインターフェイスはボタンであってもよいし、さらに別の装置においてユーザインターフェイスは音声や動画による対話であってもよい。つまり、インターフェイスコンポーネント４０は装置のハードウエアを認識して、ユーザインターフェイスをハードウエアに適合させる。
【００３５】
セキュリティコンポーネント４２は、ＢＳＲサービス１０のセキュリティを保証する。すなわち、セキュリティコンポーネント４２は高信頼性通信を選択的に行い、ＢＳＲサービス１０の不正使用を防止する。ユーザは、取り込みコンポーネント４４を用いることにより、アクティブセッションのブラウザスナップショットを取り込んで保存することができる。同様に、ユーザは、復元コンポーネント４６を用いることにより、取り込まれたブラウザスナップショットの読み出しを命令できる。ＢＳＲ装置モジュール３４の各コンポーネントの機能については以下で詳細に説明する。
【００３６】
図４および５は、ユーザインターフェイスバー５０を例としてインターフェイスの実施形態を例示している。ユーザインターフェイスバー５０は、インターフェイスコンポーネント４０（図３参照）を用いて起動および管理される。ある態様において、ユーザインターフェイスバー５０は、第１および第２の装置１４、１６（図２参照）のグラフィカルユーザインターフェイス（ＧＵＩ）を実装したブラウザウィンドウ内に表示されてもよい。別の態様において、ユーザインターフェイスバー５０は、別のウィンドウ内、または別のページとして表示されてもよい。さらに別の態様において、ユーザインターフェイスバー５０の選択可能な機能（以下で説明する）は、ハードボタン、個別アイコン、音声認識、および／またはユーザがＢＳＲサービス１０（図２参照）の機能に対して命令可能なその他のメカニズムを用いて表示してもよい。
【００３７】
インターフェイスコンポーネント４０が起動されると、本実施形態のユーザインターフェイスバー５０はHypertext Markup Language（ＨＴＭＬ）のページを表示する。本実施形態において、このページはＢＳＲリポジトリモジュール３６（図２参照）が動作するリポジトリサーバ１８（図２参照）から提供される。従って、インターフェイスコンポーネント４０を実行するために、第１および第２のブラウザ２０、２２の構成に加えるべき変更あるいは追加は比較的少ない。
【００３８】
別の態様において、このページは、例えばeXtensible Markup Language（ＸＭＬ）、Wireless Markup Language（ＷＭＬ）、Compact Hypertext Markup Language（ｃＨＴＭＬ）および／またはその他の言語で記述されたページであってもよい。さらに、このページは、インターフェイスコンポーネント４０と連携して動作する、ネットワーク１２内のその他の装置から提供されてもよい。さらに別の態様において、ユーザインターフェイスバー５０は、インターフェイスコンポーネント４０によって単独で生成され、管理されてもよい。上記いずれの態様においても、インターフェイスコンポーネント４０は、ユーザインターフェイスバー５０を介して入力されたコマンドに応じて、コマンドおよび情報を解読し、ネットワーク１２（図２参照）を介して送信する。
【００３９】
図４は、ユーザＩＤ欄５２、パスワード欄５４、サインオンボタン５６、リセットボタン５８、および認証装置ＩＤ欄６０を備えるログイン画面時のユーザインターフェイスバー５０を示している。別の態様において、ユーザインターフェイスバー５０のログイン画面は、ユーザを識別するためのその他の機能を備えてもよい。ユーザは、ログイン画面によりログイン情報を入力することが可能になる。ログイン情報は、ユーザが認証されてアクセスを許可されることなしにＢＳＲサービス１０（図２参照）にアクセスすることを防止するために用いられる。
【００４０】
図２、３および４に示すように、本実施形態において、認証およびアクセス許可はＢＳＲリポジトリモジュール３６により行われる。この実施形態において、ユーザＩＤ欄５２に入力されたユーザ名とパスワード欄５４に入力されたパスワードはネットワーク１２を介してＢＳＲリポジトリモジュール３６に送信され、認証およびアクセス許可を受ける。セキュリティコンポーネント４２は、Secure Sockets Layer（ＳＳＬ）接続等の高信頼性接続をＢＳＲリポジトリモジュール３６との間で確立し、認証およびアクセス許可処理を開始する。セキュリティコンポーネント４２により高信頼性接続が開始される際には、ユーザ名およびパスワード情報を、例えばＨＴＴＰＳメッセージにすることによりこれらの情報の安全性が保証される。本実施形態のログイン画面は、ＢＳＲリポジトリモジュール３６が動作するリポジトリサーバ１８から提供されることが好ましい。さらに、高信頼性接続は、第１および第２のブラウザ２０、２２を使用して確立される。
【００４１】
セキュリティコンポーネント４２はインターフェイスコンポーネント４０と連携してログイン画面の機能を管理してもよい。例えば、セキュリティコンポーネント４２は、サインオンボタン５６が選択された時に認証およびアクセス許可処理を開始してもよい。さらに、ネットワーク１２を介してＢＳＲ装置モジュール３４からＢＳＲリポジトリモジュール３６へ送信される後続のメッセージについても、セキュリティコンポーネント４２により安全性を保証してもよい。別の態様において、ログイン情報は、個人情報記憶装置（個人情報カード等）、生体情報スキャナ（声紋、指紋、網膜スキャナ等）および／またはユーザを識別するためのその他のメカニズムからのデータとして外部からセキュリティコンポーネント４２に供給してもよい。さらに別の態様において、セキュリティコンポーネント４２はログイン画面を生成し、ＢＳＲサービス１０の機能へのアクセスをユーザに許可してもよい。さらに別の態様において、セキュリティコンポーネント４２は、ユーザインターフェイスバー５０が長時間休止状態にある場合に、タイムアウトパスワード等のローカルセキュリティを設定してもよい。
【００４２】
認証装置ＩＤ欄６０により、ユーザ認証のためにログイン情報が送信される、ネットワーク１２内の少なくとも１の装置が特定される。この装置は、ユーザが作成したアカウントの情報とセキュリティコンポーネント４２を介して送信されるログイン情報とを照合可能なネットワーク接続された装置である。本実施形態において、ユーザはＢＳＲリポジトリモジュール３６を用いてアカウントを作成する。従って、本実施形態の認証装置ＩＤ欄６０には、ＢＳＲリポジトリモジュール３６が動作するリポジトリサーバ１８の識別子が入力される。この識別子は、インターネットプロトコル（ＩＰ）アドレス、ＵＲＬ（Uniform Resource Locator）、ＵＲＩ（Uniform Resource Identifier）、ＵＵＩＤ（Universal Unique Identifier）、またはその他の形式の識別子である。
【００４３】
図５に示すように、ユーザインターフェイスバー５０は、ＢＳＲサービス１０とユーザとを媒介するためのユーザ画面を表示する。本実施形態のユーザインターフェイスバー５０は、認証装置ＩＤ欄６０、ユーザＩＤ欄６２、スナップショットボタン６４、セッション名欄６６、セッションパスワード欄６８、復元ボタン７０、セッション選択欄７２、サインオフボタン７４、およびＢＳＲリポジトリモジュール欄７６を備える。別の態様において、ユーザインターフェイスバー５０は追加機能やＢＳＲサービス１０の動作に関する情報を備えてもよい。
【００４４】
図２、３および５に示すように、ユーザから提供されたログイン情報が認証されアクセスが許可されると、本実施形態のユーザ画面がユーザインターフェイスバー５０に表示される。従って、ユーザＩＤ欄６２には、ログインに成功した正当なユーザの識別子が入力される。この識別子は、例えばユーザ名、番号、またはアクセスを許可されたユーザを示すその他の識別子である。
【００４５】
ユーザは、スナップショットボタン６４を選択することにより、ＢＳＲ装置モジュール３４の取り込みコンポーネント４４を起動できる。上述したように、取り込みコンポーネント４４を起動することによりスナップショットを取り込むことができる、すなわちアクティブセッションのブラウザの現状態を取り込むことができる。取り込みコンポーネント４４は、スナップショットの取り込みが開始されるとアクティブセッションのブラウザ状態に関する複数のセッションパラメータを取り込む。ある態様において、このセッションパラメータには、ブラウザに表示中のページを構成する少なくとも１のドキュメントオブジェクトモデル（ＤＯＭ）、現在のページを構成する少なくとも１のスクリプトオブジェクト、現在のセッションのブラウザ履歴、ブラウザキャッシュ、およびクッキーが含まれる。別の態様において、取り込みコンポーネント４４は、アクティブセッションのブラウザの現状態を構成するその他の形式のセッションパラメータを取り込んでもよい。
【００４６】
従来から周知なように、ＤＯＭは、ＨＴＭＬおよびＸＭＬ文書用の１組のアプリケーションプログラムインターフェイス（ＡＰＩ）である。一般的に、ＤＯＭは文書の論理構造を定義し、ブラウザに表示される文書へのアクセスおよび操作のための標準のインターフェイスを提供する。ＤＯＭにより定義されたインターフェイスを用いて、文書構造とそれに含まれる要素の構築および変更に加えて、文書構造内の移動が行われる。
【００４７】
例えば、マイクロソフト（登録商標）インターネットエクスプローラ（登録商標）を使用してＨＴＭＬページを解析すると、ＤＯＭ構造が作成される。ＤＯＭ構造は、ブラウザに表示されたＨＴＭＬページの構造を表す。ＤＯＭ構造の各ノードはドキュメント情報を表す。ドキュメント情報には、ＨＴＭＬページのＨＴＭＬ要素、ＸＭＬ要素、属性、および／またはテキストが含まれる。例えば、＜a href＝http://www.docomolabs-usa.com＞DoCoMo＜/a＞というＨＴＭＬの場合、"a"要素のノード、"
href"属性のノード、およびテキスト内容の２つのノードの合計４つのノードで表さ
れる。
【００４８】
従来から周知なように、各ＤＯＭ構造の各ノードには、ブラウザにおける表示方法および動作を定義する１組の属性が含まれている。ＢＳＲ装置モジュール３４は、コンテンツおよびノードの属性を含むこのようなＤＯＭ構造をスナップショット内に取り込むよう指示される。別の態様において、Compact ＨＴＭＬ（ｃＨＴＭＬ）、Wireless Application Protocol（ＷＡＰ）、Wireless Markup Language（ＷＭＬ）、および／またはその他のプロトコルや言語を解析する機能を備えたブラウザを使用してＢＳＲ装置モジュール３４により取り込み可能な構造を作成してもよい。
【００４９】
例えば、マイクロソフト（登録商標）インターネットエクスプローラ（登録商標）にページをダウンロードして、ＢＳＲサービス１０によりアクティブセッションのブラウザの現状態を保存する場合を想定する。ユーザがスナップショットボタン６４を選択すると、取り込みコンポーネント４４は、ブラウザに表示されているページの最上位フレーム内の全ドキュメントオブジェクトをたどる。取り込みコンポーネント４４は最上位フレーム内の各ノードとその属性を取り込む。さらに、取り込みコンポーネント４４は下位フレームに進み、ＤＯＭ構造のノードとその属性を取り込む。
【００５０】
取り込みコンポーネント４４により取り込まれる別のセッションパラメータとして、スクリプトオブジェクトがある。VB ScriptやJavaScript等のスクリプトオブジェクトは、ブラウザにダウンロードされるページに含まれる。取り込みコンポーネント４４はこのようなスクリプトオブジェクトをブラウザスナップショットの一部として取り込むようにしてもよい。スクリプトオブジェクトはＤＯＭドキュメントとともに取り込まれてもよい。従って、取り込みコンポーネント４４は、ページを構成するＤＯＭおよびスクリプトオブジェクトの両方を同時に取り込む。また、取り込みコンポーネント４４はスクリプトオブジェクトのみを取り込むようにしてもよい。
【００５１】
例えば、マイクロソフト（登録商標）インターネットエクスプローラ（登録商標）を使用する場合、スクリプト変数は、IDispatchオブジェクトと表されるスクリプトタグで定義される。IDispatchオブジェクトは、実行時、マイクロソフト（登録商標）インターネットエクスプローラ（登録商標）が備えるスクリプトエンジンを用いてアクセスされる。ある態様において、マイクロソフト（登録商標）インターネットエクスプローラ（登録商標）を使用してスナップショットを取り込む場合、スクリプト変数に対応するIDispatchオブジェクトはシリアル化されて取り込まれるが、対応するスクリプト機能は取り込まれない。従来から周知なように、マイクロソフト（登録商標）インターネットエクスプローラ（登録商標）のスクリプト機能は一定である。別の態様において、スクリプト機能とスクリプト変数の両方が取り込みコンポーネント４４により取り込まれてもよい。
【００５２】
取り込みコンポーネント４４により取り込まれるさらに別のセッションパラメータとして、クッキーがある。一般的に、クッキーは、ユーザ固有の情報を含む周知の装置識別子である。従来から周知なように、クッキーは、ダウンロードされるページとともにブラウザに提供される。取り込みコンポーネント４４は、取り込みプロセスにおいて、クッキーをnameおよびvalue要素の対として解釈して保存する。、クッキーは取り込まれると、取り込みコンポーネント４４により取り込まれるその他の情報に付加される。マイクロソフト（登録商標）インターネットエクスプローラ（登録商標）が使用される場合、クッキーは上述した各スナップショットのＤＯＭ構造に付加される。
【００５３】
取り込みコンポーネント４４により取り込まれるさらに別のセッションパラメータとして、アクティブセッションのブラウザ履歴がある。ブラウザ履歴は、ブラウザが以前に表示したページの集合である。従って、取り込みコンポーネント４４はブラウザ履歴に登録されたページを取り込み、取り込まれたその他の情報に付加する。マイクロソフト（登録商標）インターネットエクスプローラ（登録商標）が使用される態様において、ブラウザは、ＵＲＬ履歴を検索および設定するためにIURHistoryStgインターフェイスを備える。この態様では、ブラウザ履歴を取り込む際に、ＵＲＬ履歴を列挙し、列挙されたＵＲＬを取得し、取得したＵＲＬをＤＯＭ構造およびクッキーに付加する。
【００５４】
ユーザは、取り込みコンポーネント４４を用いて、取り込まれたアクティブセッションのブラウザの現状態に対してセッション名とセッションパスワードを設定してもよい。ユーザは、図４に示されるセッション名欄６６に固有のセッション名を入力する。あるいは、ユーザは、以前に取り込んだブラウザ状態のセッション名を選択してもよい。セッション名が設定されない場合、ウェブサイトのホスト名等をデフォルトセッション名として、取り込んだアクティブセッションのブラウザ状態を識別してもよい。
【００５５】
ユーザは、図４に示されるセッションパスワード欄６８に入力されるセッションパスワードを用いてブラウザスナップショットを保護してもよい。このセッションパスワードにより、取り込んだブラウザスナップショットへの不正アクセスを防止できる。別の態様において、セッションパスワードの入力方法には、音声パスワードやブラウザスナップショットへの不正アクセスを防止するその他のメカニズムが含まれる。
【００５６】
ブラウザスナップショットは取り込まれると、取り込みを指示したユーザと関連付けられる。つまり、スナップショットは、ブラウザ状態を取り込んだブラウザおよび／または装置ではなく、ユーザと関連付けられる。スナップショットは、ユーザと関連付けられる際、ユーザのアカウント情報、ユーザ名、またはアクティブセッションをカスタマイズしてブラウザスナップショットを取り込んだユーザを一意に識別するその他のメカニズムと関連付けられる。各ユーザと関連付けられたブラウザスナップショットはネットワーク１２内の安全な場所に保存される。
【００５７】
本実施形態において、ブラウザスナップショットはＢＳＲリポジトリモジュール３６により保存される。本実施形態において、セキュリティコンポーネント４２は、ＢＳＲ装置モジュール３４とＢＳＲリポジトリモジュール３６間の高信頼性接続を確立し、取り込んだアクティブセッションのブラウザ状態をネットワーク１２を介して送信する。別の態様において、取り込んだアクティブセッションのブラウザ状態がネットワーク１２内の他の場所に保存される場合、セキュリティコンポーネント４２は、ネットワークに接続されたその他の装置と高信頼性接続を確立し、ブラウザスナップショットを安全に送信する。
【００５８】
ある態様において、セッション名およびセッションパスワードの入力後、ブラウザスナップショットを自動的に保存するようにしてもよい。別の態様において、ユーザは、別のコマンドでおよび／または保存場所を選択してブラウザスナップショットの保存を開始してもよい。ユーザがアクティブセッションのブラウザ状態を取り込んだ後も当該アクティブセッションのカスタマイズを続けた場合、取り込みコンポーネント４４は、取り込んだアクティブセッションのブラウザスナップショットとの不一致の可能性を警告してもよい。
【００５９】
上述したように、ＢＳＲ装置モジュール３４は復元コンポーネント４６を有する。ユーザはユーザインターフェイスバー５０を用いて、取り込んだブラウザスナップショットの読み出しを指示する。読み出しは、復元ボタン７０とセッション選択欄７２とを用いて開始される。ユーザは、正常に認証されアクセスを許可されると、以前に取り込まれユーザに関連付けられたブラウザスナップショットを選択する。ブラウザスナップショットを選択する際には、プルダウンメニューリスト、索引、データベース、セッション名の手動入力、または以前に取り込まれユーザに関連付けられたブラウザスナップショットのリストを識別するためのその他の検索メカニズムが用いられる。検索メカニズムおよび／またはリストは、ＢＳＲリポジトリモジュール３６、セキュリティコンポーネント４２、および／またはブラウザスナップショットの保存場所に関連付けられたその他の装置により提供される。
【００６０】
以前に保存されたアクティブセッションのブラウザ状態が選択されると、復元ボタン７０を選択することにより読み出しが開始される。アクティブセッションのブラウザ状態がＢＳＲリポジトリモジュール３６に保存される態様において、保存されたブラウザスナップショットは、ログインする際にユーザを認証しアクセスを許可するために予め確立された高信頼性接続を介してダウンロードされる。この態様において、高信頼性接続がすでに切断されている場合、セキュリティコンポーネント４２は高信頼性接続の確立を再び開始する。ブラウザスナップショットがネットワーク１２内の他の場所に保存される別の態様において、セキュリティコンポーネント４２は高信頼性接続を確立し、スナップショットを安全に読み出せるようにする。
【００６１】
選択されたブラウザスナップショットに対してセッションパスワードが設定されている場合は、セッションパスワードをセッションパスワード欄６８に入力する。セッションパスワードは、ＢＳＲリポジトリモジュール３６、セキュリティコンポーネント４２、またはブラウザスナップショットの保存場所に関連付けられたその他の装置により認証される。従って、ユーザは正常に認証されアクセスを許可されても、セッションパスワードがなければ保存されたブラウザスナップショットを読み出すことができない。
【００６２】
復元コンポーネント４６は、ブラウザスナップショットを受信すると当該ブラウザスナップショットを復元する。ブラウザスナップショットを復元する際、ブラウザスナップショットはアクティブセッションのブラウザ状態に変換される。アクティブセッションは、復元後、スナップショットが取り込まれた時点と同じ状態でブラウザに表示される。ある態様では、上述のように取り込まれたＤＯＭおよびスクリプトオブジェクトの復元の結果、アクティブセッションのブラウザ状態が表示される。さらに、ページ中に入力された値、ブラウザ履歴、ブラウザキャッシュ、クッキー、および／またはアクティブセッション中にカスタマイズされたその他の情報も復元される。
【００６３】
ある態様では、ブラウザスナップショットを復元する際にサイト３０（図２参照）からコンテンツを再ダウンロードする。サイト３０からブラウザにコンテンツがダウンロードされると、ＢＳＲ装置モジュール３４の復元コンポーネント４６はブラウザスナップショットを利用してコンテンツをカスタマイズし、以前に取り込んだアクティブセッションのブラウザ状態を復元する。ある態様では、以前に取り込んだＤＯＭ構造を復元する際に、ダウンロードしたコンテンツのＤＯＭ構造が利用される。この態様において、復元コンポーネント４６は、以前に取り込んだＤＯＭ構造に従って、ダウンロードしたコンテンツの各ＤＯＭノードの値および属性を復元する。ＤＯＭ構造が復元されると、復元コンポーネント４６は、クッキー、スクリプトオブジェクトの変数、およびブラウザ履歴の復元を開始する。
【００６４】
図２、３および５に示すように、セキュリティコンポーネント４２はサインオフボタン７４を備える。セキュリティコンポーネント４２はログオフ処理を開始する、すなわちサインオフボタン７４が選択されるとＢＳＲサービス１０へのアクセスを終了する。セキュリティコンポーネント４２は、サインオフボタン７４が選択されるとＢＳＲ装置モジュール３４とブラウザとの接続を切断する。さらに、セキュリティコンポーネント４２はインターフェイスコンポーネント４０に指示してユーザインターフェイスバー５０を閉じる。
【００６５】
ＢＳＲリポジトリモジュール欄７６には、ＢＳＲリポジトリモジュール３６が動作する装置の場所が入力される。場所を示す識別子としては、ＩＰアドレス、物理的な場所名、またはその他任意の形式の識別子がある。従って、複数のＢＳＲリポジトリモジュール３６が利用可能な場合には、ＢＳＲリポジトリモジュール欄７６により所望の場所が選択できる。
【００６６】
図２に示すように、ＢＳＲリポジトリモジュール３６は、ネットワーク１２を介してＢＳＲ装置モジュール３４と通信可能な装置上で動作し、且つＢＳＲサービス１０の動作をサポートする任意のアプリケーションである。本実施形態において、ＢＳＲリポジトリモジュール３６はリポジトリサーバ１８上で動作する。別の態様において、ＢＳＲリポジトリモジュール３６は、ネットワークに接続された任意の装置上で動作してもよい。本実施形態において、ＢＳＲリポジトリモジュール３６と連携して動作するリポジトリサーバ１８は、ＢＳＲサービス１０をサポートする商用のサーバサービス提供者でもよいし、私的に設定、管理されるＢＳＲサービス１０用のサーバサービスの提供装置でもよい。
【００６７】
図６は、ＢＳＲリポジトリモジュール３６の一実施形態を示すブロック図である。ＢＳＲリポジトリモジュール３６は、ログインセキュリティコンポーネント８０、ページサーバコンポーネント８２、スナップショット保存コンポーネント８４、通信セキュリティコンポーネント８６、およびタイミングコンポーネント８８を備える。別の態様において、ＢＳＲリポジトリモジュール３６の機能を果たすコンポーネント数の多寡は問わない。さらに別の態様において、ＢＳＲリポジトリモジュール３６はコード変換機能を備えてもよい。このコード変換機能により、ＨＴＭＬからｃＨＴＭＬへの変換、ｃＨＴＭＬからＨＴＭＬへの変換、および／またはその他の言語変換が可能になる。また、コード変換機能により、ＨＴＴＰおよびワイヤレスアプリケーションプロトコル（ＷＡＰ）間の変換等のプロトコル変換が可能になる。さらに、コード変換機能により、ＨＴＴＰのＨＴＭＬおよびＷＡＰのワイヤレスマークアップ言語（ＷＭＬ）間の変換等のように言語とプロトコルの両方を変換してもよい。
【００６８】
ログインセキュリティコンポーネント８０は、図４を参照して説明したユーザインターフェイスバー５０のログイン画面を介してログイン情報を提供したユーザを認証し、アクセスを許可する。ログインセキュリティコンポーネント８０は、アカウントの情報とユーザインターフェイスバー５０を介して提供されたログイン情報とを照合する。ユーザは、ＢＳＲリポジトリモジュール３６にアカウントを作成して保存する。ログインセキュリティコンポーネント８０は、ログイン情報を受信すると保存されたアカウント情報にアクセスしてユーザの認証を行う。正常に認証されると、ユーザはログインしてＢＳＲリポジトリモジュール３６へのアクセスを許可される。
【００６９】
ページサーバコンポーネント８２により、ＢＳＲリポジトリモジュール３６は、図４および５を参照して説明したユーザインターフェイスバー５０にドキュメントを提供する標準のサーバとして機能することが可能になる。ページサーバコンポーネント８２は、ドキュメントに加えて、ログイン情報で識別されるユーザに関するその他の情報を提供する。例えば、保存されたブラウザスナップショットのリストが上述したセッション選択欄７２に提供される。保存されたブラウザスナップショットのリストには、ＢＳＲリポジトリモジュール３６を用いて保存されたスナップショットが記載されている。別の態様において、ページサーバコンポーネント８２は、インターフェイスコンポーネント４０（図３参照）やネットワーク１２（図２参照）内のその他の装置等により生成および表示されたページ上の情報を提供してもよい。
【００７０】
スナップショット保存コンポーネント８４は、図３および５を参照して説明したようにＢＳＲ装置モジュール３４により取り込まれたブラウザスナップショットを保存する。スナップショット保存コンポーネント８４は、取り込みコンポーネント４４（図３参照）により送信されたブラウザスナップショットを受信し、保存する。スナップショット保存コンポーネント８４は、ＢＳＲリポジトリモジュール３６が動作する装置に関連付けられた保存メカニズムにブラウザスナップショットの保存を指示する。
【００７１】
代表的な保存メカニズムとしては、ハードディスク、光ディスク、またはその他のデータ記憶媒体と連携して動作する関係データベースがある。別の態様において、スナップショット保存コンポーネント８４は、ネットワーク１２（図２参照）内の任意の装置が備える保存メカニズムにブラウザスナップショットの保存を指示してもよい。
【００７２】
上述したように、保存された各ブラウザスナップショットは、アクティブセッションのブラウザ状態を取り込んで保存したユーザに対応付けられる。従って、スナップショットはユーザの識別情報ごとに保存される。さらに、保存されたスナップショットにアクセスするには、ブラウザ状態を取り込んで保存したユーザの認証およびアクセス許可が必要となる。
【００７３】
ユーザが認証されアクセスを許可されると、保存されたブラウザスナップショットは、所望のスナップショットの識別子に基づいてスナップショット保存コンポーネント８４によりアクセスされる。図５を参照して説明したように、保存されたブラウザスナップショットは、ユーザインターフェイスバー５０のセッション選択欄７２を用いて特定され、読み出される。選択されたブラウザスナップショットは保存メカニズムから読み出されてユーザのブラウザに送信されると、上述したように復元されて表示される。スナップショット保存コンポーネント８４は、選択されたブラウザスナップショットに設定されたパスワードを認証する。
【００７４】
図２および６に示すように、通信セキュリティコンポーネント８６によりＢＳＲ装置モジュール３４との高信頼性接続が可能になる。高信頼性接続では、上述したプロトコルのいずれを用いてもよい。高信頼性接続には、例えばログイン情報の送信、取り込んだアクティブセッションのブラウザ状態の送信、またはＢＳＲ装置モジュール３４とＢＳＲリポジトリモジュール３６間で行われるその他の通信が含まれる。さらに、通信セキュリティコンポーネント８６を用いれば、ＢＳＲサービス１０に関するその他の機密情報の通信も保護することができる。
【００７５】
タイミングコンポーネント８８は、ブラウザスナップショットとして保存された、サイト３０（図２参照）とのアクティブセッションを管理する。従来から周知なように、サイト３０はアクティブセッションに対してタイムアウトポリシーを設定することがある。従って、長時間保存されたブラウザスナップショットは保存場所から読み出されてもアクティブセッションに復元されない場合がある。
【００７６】
ある態様において、タイミングコンポーネント８８はサイト３０に定期的にアクセスして（例えば、ピン（Ping））、ブラウザ状態が取り込まれ保存されたアクティブセッションをアクティブ状態に保つ。この通信には、サイト３０に対して単にピンを使用する方法の他に、タイムアウト時間をリセットするために必要なその他の通信が含まれる。タイミングコンポーネント８８は、各ブラウザスナップショットが保存された時刻に基づいて、対応するサイト３０のタイムアウト時間をリセットするための通信を行う。
【００７７】
別の態様において、タイミングコンポーネント８８は、ブラウザスナップショットが保存された各サイト３０のタイムアウト時間を調べる。そして、ユーザは、アクティブセッションのタイムアウト時間が経過する前にブラウザスナップショットを読み出すようタイミングコンポーネント８８により通知される。さらに、タイミングコンポーネント８８は、タイムアウト時間が経過した（または経過しそうな）場合に、タイムアウト時間が経過した（または経過しそうな）ブラウザスナップショットをユーザに通知してもよい。さらに別の態様において、サイト３０のタイムアウトポリシーを拡充してブラウザスナップショットが保存されたアクティブセッションに対応させてもよい。さらに別の態様において、アクティブセッションのブラウザ状態が取り込まれ保存された旨の通知をタイミングコンポーネント８８から受けることにより、サイト３０は当該アクティブセッションに対するタイムアウトポリシーの適用を停止してもよい。
【００７８】
図７は、図１、２、３、４、および６に示されるＢＳＲサービス１０の動作を示すフローチャートである。この動作例を説明するにあたり、ユーザは、ＢＳＲサービス１０にアクセスするため、予めアカウントを作成しているものとする。さらに、ユーザは、まだアクティブセッションのブラウザスナップショットを取り込み、保存していないものとする。
【００７９】
まず、ブロック１０２において第１のブラウザ２０が第１の装置１４上で起動される。ブロック１０４において、第１の装置１４および第１のブラウザ２０と関連付けられたＢＳＲ装置モジュール３４が起動される。ブロック１０６において、ユーザはユーザ名とパスワードをユーザインターフェイスバー５０のログイン画面に入力する。ブロック１０８において、ＢＳＲ装置モジュール３４はリポジトリサーバ１８との高信頼性接続の確立を開始する。ブロック１１０において、ログイン情報が高信頼性接続を介してリポジトリサーバ１８に送信される。ブロック１１２において、リポジトリサーバ１８のＢＳＲリポジトリモジュール３６はログイン情報に基づいてユーザを認証し、アクセス許可メッセージをＢＳＲ装置モジュール３４に送信する。ブロック１１４において、ログイン画面に代わりユーザ画面がユーザインターフェイスバー５０に表示される。ブロック１１６において、ユーザはネットワーク１２を介してリクエストを送信し、第１のブラウザ２０を使用してサイトの特定および閲覧を開始する。
【００８０】
ブロック１１８において、第１のブラウザ２０はサイト３０にリクエストを送信してアクティブセッションをカスタマイズする。カスタマイズ後、ブロック１２０において、ユーザはアクティブセッションのブラウザの現状態の保存を開始する。ブロック１２２において、ユーザインターフェイスバー５０のスナップショットボタン６４を選択して、アクティブセッションのブラウザの現状態の取り込みを開始する。アクティブセッションのブラウザ状態をブラウザスナップショットとして取り込んだ後、ブロック１２４において、当該スナップショット用のセッション名とパスワードを設定する。ブロック１２６において、ユーザはブラウザスナップショットと関連付けられる。
【００８１】
図８のブロック１２８において、ＢＳＲ装置モジュール３４は、第１の装置１４とリポジトリサーバ１８との高信頼性接続の確立を開始する。接続が確立されると、ブロック１３０において、ブラウザスナップショットがこの高信頼性接続を介してリポジトリサーバ１８に送信される。ブロック１３２において、ブラウザスナップショットは解読され、ＢＳＲリポジトリモジュール３６により対応するユーザと関連付けられて保存される。ブロック１３４において、ユーザはユーザインターフェイスバー５０のサインオフボタン７４を選択してサイト３０の閲覧を終了し、第１のブラウザ２０とＢＳＲリポジトリモジュール３６との接続を切断する。ブロック１３６において、ＢＳＲリポジトリモジュール３６は第１の装置１４とリポジトリサーバ１８との高信頼性接続を切断する。ブロック１３８において、ユーザは第１のブラウザ２０を終了する。
【００８２】
図９は、同一のユーザが第２の装置１６上で第２のブラウザ２２を起動させた場合におけるＢＳＲサービス１０の動作を示すフローチャートである。この動作例を説明するにあたり、ユーザは第１の装置１４上で動作する第１のブラウザ２０を使用してブラウザスナップショットをすでに保存しているものとする。図示しないが、上述したブロック１０２からブロック１１４（図７参照）までの動作が、第１の装置１４および第１のブラウザ２０に代えて第２の装置１６および第２のブラウザ２２を使用して再び行われる。
【００８３】
図９のブロック２０２において、ログイン済みのユーザに関連付けられて保存されたブラウザスナップショットを含むリストが高信頼性接続を介してダウンロードされ、ユーザインターフェイスバー５０に提示される。ブロック２０４において、ユーザは保存されたブラウザスナップショットを読み出すか否かを決定する。ユーザが、保存されたブラウザスナップショットを読み出さない場合、ブロック２０６において、ユーザは第２のブラウザ２２を使用してネットワーク１２上のサイト３０を特定する。ブロック２０８において、ユーザはネットワーク１２を介してリクエストを送信し、サイト３０の閲覧を開始する。
【００８４】
ブロック２０４において、ユーザが、保存されたブラウザスナップショットの読み出しを決定した場合、ブロック２１０において、保存されたブラウザスナップショットをセッション名欄６６で選択し、当該ブラウザスナップショットに対して設定されたパスワードをセッションパスワード欄６８に入力する。ブロック２１２において、ユーザインターフェイスバー５０の復元ボタン７０が選択され、復元処理が開始される。パスワードが認証されると、ブロック２１４において、選択されたブラウザスナップショットがリポジトリサーバ１８から第２の装置１６に高信頼性接続を介してダウンロードされる。
【００８５】
ブロック２１６において、ＢＳＲ装置モジュール３４は保存されたブラウザスナップショットを復元し、第２のブラウザ２２を使用してアクティブセッションを再開する。ブロック２０８において、第２のブラウザ２２は、ネットワーク１２を介してリクエストを送信し、アクティブセッションが復元されたサイト３０の閲覧を開始する。
【００８６】
アクティブセッションのブラウザ状態をカスタマイズして保存する第２のブラウザ２２の動作は、図７および８を参照して説明した動作と同様である。別の態様において、ユーザは異なる装置および異なるブラウザを任意に使用してサイトを閲覧し、さらにアクティブセッションを任意にカスタマイズしてブラウザ状態を保存してもよい。さらに、ユーザは異なる装置および異なるブラウザを任意に使用して、保存されたブラウザの現状態を復元し、アクティブセッションを継続してもよい。
【００８７】
上述したＢＳＲサービス１０の実施形態によれば、ユーザは、セッションを終了して別の装置でセッションのカスタマイズを最初からやり直すことなく、アクティブセッション中に装置を切り替えることができる。さらに、ユーザは、任意の装置でいつでもどんなアクティブセッションでも保存して継続できるので、複数のカスタマイズされたアクティブセッションを同時に管理できる。ＢＳＲサービス１０を利用してアクティブセッションを保存する際には、単にアクティブセッションのブラウザ状態をスナップショットとして保存するだけでよい。スナップショットは安全に保存され、後で安全に読み出されて、ユーザによりカスタマイズされたアクティブセッションに復元される。また、ユーザは、任意のブラウザおよび／または装置を使用してブラウザスナップショットを保存し読み出すことができる。従って、ＢＳＲサービス１０によれば、ブラウザスナップショットはブラウザまたは装置と関連付けられるのではなく、ＢＳＲサービス１０のユーザと関連付けられる。
【００８８】
別の態様において、ＢＳＲサービスは、ブラウザセッションモビリティ（ＢＳＭ）システムに拡張される。ＢＳＭシステムは、マルチプラットフォームネットワークアプリケーションのアクティブセッションのランタイム状態の、異なるプラットフォーム間におけるモビリティをサポートする。従来から周知のように、セッションは、ウェブアプリケーション等のネットワークアプリケーションを使用するユーザのインスタンスである。プラットフォームとは、ポケットパーソナルコンピュータ、携帯電話、デスクトップコンピュータ等のソフトウェアおよび／またはハードウェア環境が異なる装置の種類である。上述したように、ＢＳＲサービスによれば、ブラウザ状態は特定の装置と関連付けられるのではなくユーザと関連付けられるため、ユーザは、アクティブセッションの複数のブラウザスナップショットを保存し、復元することができる。ＢＳＭシステムでは、この関連付けがさらに拡張され、マルチプラットフォームネットワークアプリケーションが動作する異なるプラットフォーム間におけるシームレスな移動が可能になる。
【００８９】
ＢＳＭシステムは、異なるプラットフォーム間におけるランタイム状態のモビリティをサポートする。プラットフォームが異なると、ディスプレイ、ネットワーキング、ユーザインターフェイス等に関連する制限および能力が異なる。ＢＳＭシステムによれば、ＢＳＲサービスのようにブラウザ状態を取り込むだけではなく、アクティブセッションのサーバ状態も取り込むことができる。アクティブセッションのブラウザ状態およびサーバ状態中に生成される状態データおよびセッションデータは総称してランタイム状態と呼ばれる。ＢＳＭシステムにおいて、「状態」または「ランタイム状態」という用語はユーザおよびネットワークアプリケーション間において蓄積される対話を指す。ランタイム状態には、フォームデータ、スクリプト変数、クッキー等のブラウザ状態とブラウザ状態をサポートするサーバ状態が含まれる。サーバ状態は、プラットフォームに依存するＪＳＰ（Java Server Pages）やＣＧＩ（Computer Generated Image）の状態のようにプラットフォーム毎に異なる。
【００９０】
ＢＳＭシステムによれば、マルチプラットフォームネットワークアプリケーションのプラットフォーム依存バージョンを用いて生成されたプラットフォーム依存ランタイム状態を、マルチプラットフォームネットワークアプリケーションの別のプラットフォームに依存するバージョンにおいて別のプラットフォームに依存するランタイム状態に変換することができる。従って、ＢＳＭシステムでは、ランタイム状態と特定のプラットフォームとを関連付けないことにより、ある特定のプラットフォーム上で実行されるマルチプラットフォームネットワークアプリケーションのランタイム状態が別のプラットフォームに転送される。
【００９１】
上述したＢＳＲサービスのスナップショットという概念は修正および拡張され、ＢＳＭシステムでは、プラットフォーム非依存ランタイム状態データが含まれる。従って、ＢＳＭシステムによれば、スナップショットは任意のプラットフォーム上でアクティブセッションに復元される。ＢＳＭシステムは、マルチプラットフォームネットワークアプリケーションの任意のプラットフォームに依存するバージョンのタスク、ランタイム状態、およびデータ構造に対して動作する。ＢＳＭシステムによれば、任意のマルチプラットフォームネットワークアプリケーションの構造において、アクティブセッションのスナップショットを取り込み、プラットフォーム毎に変換し、復元させることができる。
【００９２】
図１０は、上述したネットワーク１２を介して動作するＢＳＭシステム３００を示すブロック図である。同図に示すように、ＢＳＭシステム３００は、アプリケーションサーバ３０２、第１および第２の装置３０４、３０６として示される通信装置、およびリポジトリサーバ３０８をそれぞれ少なくとも１ずつ備える。別の態様において、ＢＳＭシステム３００は、任意の数のアプリケーションサーバ、通信装置、リポジトリサーバ、およびその他のネットワーク対応装置を備えてもよい。
【００９３】
アプリケーションサーバ３０２は、第１および第２の装置３０４、３０６等の、ネットワーク１２上の装置に対してアプリケーションを提供可能な任意のネットワーク対応装置である。アプリケーションサーバ３０２は、プロセッサ、メモリ、マルチプラットフォームウェブアプリケーション等の少なくとも１のマルチプラットフォームネットワークアプリケーション、サーバ状態モジュール３１２、およびプラットフォームアダプタモジュール３１４を備える。アプリケーションサーバ３０２は、オペレーティングシステムおよびプログラムもメモリに備え、通常のネットワークサーバコンピュータと同程度の能力を有する。ネットワークを介してネットワークアプリケーションを提供する周知のメカニズムでは、ＨＴＴＰ要求等の要求によりアプリケーションサーバ３０２とのアクティブセッションが開始される。
【００９４】
この要求は、第１および第２の装置３０４、３０６等の対象プラットフォームからネットワーク１２を介してアプリケーションサーバ３０２に送信される。アプリケーションサーバ３０２は、プラットフォームの種類（例えば、デスクトップパーソナルコンピュータ、ラップトップコンピュータ、携帯情報端末（ＰＤＡ）、携帯電話等）と対象プラットフォームのために起動されるマルチプラットフォームネットワークアプリケーションの当該プラットフォームに依存するバージョンを特定する。次に、アプリケーションサーバ３０２は、サーバ状態モジュール３１２を用いてサーバ状態を生成する。このサーバ状態は、対象プラットフォームに対応するプラットフォーム依存ネットワークアプリケーションとともに動作する。プラットフォーム依存ネットワークアプリケーションとは、対象プラットフォームのブラウザとのアクティブセッションの確立および維持可能な、マルチプラットフォームネットワークアプリケーションのプラットフォーム依存バージョンである。
【００９５】
図１１、１２、および１３は、プラットフォームの異なるブラウザ表示例を示す図である。各プラットフォームは、ネットワークアプリケーションの各プラットフォームに依存するバージョンとともに動作するサーバ状態によりサポートされる、各プラットフォームに依存するバージョンは、バージョンが異なるマルチプラットフォームネットワークアプリケーション（この例では、ブックストアアプリケーション）である。図１１、１２、および１３に示される各表示例は、各プラットフォームの表示画面のサイズ、ユーザインターフェイス装置、およびネットワーク接続のタイプ等の能力に最適化された各プラットフォームに依存するブックストアアプリケーションの表示である。別の態様において、マルチプラットフォームネットワークアプリケーションは任意の数のプラットフォームに対応してよい。
【００９６】
図１１に示される第１のブラウザ表示例３２４は、ブックストアアプリケーションの第１のプラットフォームに依存するバージョンにより生成される。第１のプラットフォームに依存するバージョンは、デスクトップまたはラップトップコンピュータ等の表示画面が比較的大きくネットワーク接続が比較的安定したプラットフォームによるアクティブセッションに用いられる。表示画面が比較的大きいため、このプラットフォームは、書籍目録タスク３２６、ショッピングカートタスク３２８、およびチェックアウトタスク３３０を一画面中に表示できる。ネットワーク１２への高速接続と多様なユーザインターフェイス装置により、アクティブセッション中の操作にはスクロール、マウスクリック、キーボードによるデータ入力等が用いられる。
【００９７】
図１２に示される第２のブラウザ表示例３３４は、ポケットＰＣまたはＰＤＡ等のネットワーク１２への接続が比較的高速で表示画面が小さいプラットフォームを対象としている。第２のブラウザ表示例３３４を伴うアクティブセッションは、上記のプラットフォームに対応する、ブックストアアプリケーションの第２のプラットフォームに依存するバージョンによりサポートされる。第２のプラットフォームに依存するバージョンでは、小さい表示画面上においても見易くするために、書籍目録タスク３２６、ショッピングカートタスク３２８、およびチェックアウトタスク３３０がブラウザの別々のページに配置される。ＨＴＴＰ要求等の個々のページに対する要求により、ブラウザ状態と、ネットワークアプリケーションの第２のプラットフォームに依存するバージョンとともに動作するサーバ状態とが同期化される。
【００９８】
ブラウザのユーザインターフェイス装置は、利用可能なユーザインターフェイス装置が異なるため、ネットワークアプリケーションの各プラットフォーム依存バージョン間で非常に異なる。例えば、第１のブラウザ表示例３２４では、ユーザインターフェイス装置により、全てのタスク３２６、３２８、および３３０が表示される。第２のブラウザ表示例３３４では、表示画面が小さいためにタスク３２６、３２８、および３３０の一部のみが表示され、その結果としてスクロールバーが表示される。異なるプラットフォーム間におけるユーザインターフェイス装置の変更のその他の例として、テキストフィールドボックスからプルダウンメニューへの変更や、マウス操作からタッチスクリーン操作への変更がある。
【００９９】
図１３に示される第３のブラウザ表示例３４０は、ネットワーク接続が悪いポケットＰＣ等の、表示画面が比較的小さくネットワーク１２への接続が比較的低速な装置を対象としている。第３のブラウザ表示例３４０を含むブラウザ状態は、第３のプラットフォームに依存するバージョンとともに動作するサーバ状態によりサポートされる。第３のブラウザ表示例３４０では、書籍目録タスク３２６（図示せず）、ショッピングカートタスク３２８、およびチェックアウトタスク３３０（図示せず）が、スクロールバーを備える別々のページに配置される。第３のプラットフォームに依存するバージョンは、対象装置とのアクティブセッションを見易くするために、ブラウザ中に代わりのユーザインターフェイス装置を提供する。
【０１００】
例えば、第３のブラウザ表示例３４０のショッピングカートタスク３２８では、別のタイトルが、第１および第２のブラウザ表示のショッピングカートタスク３２８のように一覧表示されるのではなく、プルダウンメニューにより表示される。さらに、アクティブセッション中の操作は、対象装置上のクライアントサイドスクリプトによって行われてもよい。例えば、「数量」および「価格」は、プルダウンメニュー３４４で選択されたタイトルに基づいて読み出される。従って、ブラウザ状態より生成されてネットワークを介してサーバ状態に送信されるＨＴＴＰ要求等の要求が減少するため、ネットワークトラフィックが最小限に抑えられる。
【０１０１】
表示方法および機能が非常に異なるため、各表示では、異なるタスクモデルが暗黙的に用いられている。サーバ状態とともに動作するネットワークアプリケーションのプラットフォーム依存バージョンに基づいてデータが表示され、フォームデータを含む変数がサーバ側ランタイム状態に送信される回数および方法は、プラットフォーム毎に異なる。従って、マルチプラットフォームネットワークアプリケーションの異なるプラットフォームに依存するバージョン間において、サーバ側ランタイム状態データは非常に異なる。
【０１０２】
図１０に示されるプラットフォームアダプタモジュール３１４は、サーバ状態モジュール３１２と連携して動作する。プラットフォームアダプタモジュール３１４は、アクティブセッションのサーバ側ランタイム状態のプラットフォーム依存（ＰＳ）スナップショットを取り込む能力を有する。アクティブセッションのサーバ側ＰＳスナップショットは、アクティブセッション中にブラウザおよびアプリケーションサーバ３０２間で進行中の対話に関連するプラットフォーム依存ランタイム状態データを含む。プラットフォームアダプタモジュール３１４によってサーバ側ＰＳスナップショットに取り込まれるプラットフォーム依存ランタイム状態データの量、種類、および詳細については、マルチプラットフォームネットワークアプリケーションの開発者により指定される。サーバ側ＰＳスナップショットに取り込まれるプラットフォーム依存ランタイム状態は、別のデータベースへのリンク、アクティブセッションに関連するキャッシュデータ、オープンファイル、入力／出力、ＪＳＰまたはＣＧＩ変数等を含んでもよい。サーバ側ＰＳスナップショットは、プラットフォームアダプタモジュール３１４により、第１および第２の装置３０４、３０６、および／またはリポジトリサーバ３０８にネットワーク１２を介して送信される。
【０１０３】
また、プラットフォームアダプタモジュール３１４は、サーバ側ＰＳスナップショットをサーバ側プラットフォーム非依存ランタイム状態に変換する能力を有する。この変換はマッピングを用いて行われ、サーバ側プラットフォーム依存ランタイム状態データからサーバ側プラットフォーム非依存ランタイム状態データに選択的に変換される。同様に、プラットフォームアダプタモジュール３１４は、プラットフォーム非依存ランタイム状態データをプラットフォーム依存ランタイム状態に変換する。
【０１０４】
プラットフォームアダプタモジュール３１４は、マッピング記述ファイルを用いてマッピングする。マッピング記述ファイルには、アプリケーション開発者により、サーバ側ＰＳスナップショットに含まれるサーバ側プラットフォーム依存ランタイム状態およびサーバ側プラットフォーム非依存ランタイム状態間の変換について記述される。
【０１０５】
サーバ側プラットフォーム非依存ランタイム状態は、プラットフォーム非依存（ＰＩ）スナップショットに含まれる。プラットフォームアダプタモジュール３１４は、ＰＩスナップショットとマッピング記述ファイルを、リポジトリサーバ３０８、および／または第１および第２の装置３０４、３０６等のその他の装置にネットワーク１２を介して送信する。上述の実施形態と同様に、ネットワーク１２を介する通信は暗号化される。
【０１０６】
第１および第２の装置３０４、３０６は、それぞれＢＳＭモジュール３１６を備える。図１に示される第１および第２の装置１４、１６と同様に、ＢＳＭモジュール３１６は、第１および第２の装置３０４、３０６において、それぞれ第１および第２のブラウザ３１８、３２０と連携して動作する。ＢＳＭモジュール３１６は、第１および第２の装置３０４、３０６上で動作するブラウザプラグインや独立型のモジュール等である。
【０１０７】
図１４は、ＢＳＭモジュール３１６の一実施形態を示すブロック図である。ＢＳＭモジュール３１６は、上述したインターフェイスコンポーネント４０、セキュリティコンポーネント４２、取り込みコンポーネント４４、および復元コンポーネント４６に加えて、変換モジュール３５０および状態ハンドラモジュール３５２を備える。上述したように、取り込みコンポーネント４４によって取り込まれるブラウザ側プラットフォーム依存（ＰＳ）スナップショットは、アクティブセッションのブラウザ側プラットフォーム依存ランタイム状態を含む。別の態様において、ＢＳＭモジュール３１６は、任意の数のモジュールまたはコンポーネントを備えてよい。
【０１０８】
変換モジュール３５０は、取り込みコンポーネント４４と連携して動作し、ネットワークアプリケーションのプラットフォーム依存バージョンのブラウザ側ランタイム状態（ブラウザ側ＰＳスナップショット）を選択的に変換する。プラットフォームアダプタモジュール３１４と同様に、ブラウザ側ＰＳスナップショットは、マッピング記述ファイルを用いて、ブラウザ側プラットフォーム非依存ランタイム状態に変換される。具体的には、ブラウザ側ＰＳスナップショットに含まれるブラウザ側プラットフォーム依存ランタイム状態データが、プラットフォーム非依存ランタイム状態データに選択的に変換される。また、変換モジュール３５０は、復元コンポーネント４６と連携して動作し、ブラウザ側プラットフォーム非依存ランタイム状態を、ブラウザ側プラットフォーム依存ランタイム状態データを含むブラウザ側ＰＳスナップショットに選択的に変換する。
【０１０９】
変換モジュール３５０は、マッピング記述ファイルを用いて状態データを選択的に変換する。プラットフォームアダプタモジュール３１４と同様に、マッピング記述ファイルには、アプリケーション開発者により、ブラウザ側ＰＳスナップショットに含まれるブラウザ側プラットフォーム依存ランタイム状態データおよびブラウザ側プラットフォーム非依存ランタイム状態データ間の選択的な変換について記述される。
【０１１０】
ブラウザ側ＰＳスナップショットが変換されると、状態ハンドラモジュール３５２は、ブラウザ側プラットフォーム非依存ランタイム状態を変換モジュール３５０から受信する。また、状態ハンドラモジュール３５２は、サーバ側プラットフォーム非依存ランタイム状態を含むＰＩスナップショットをプラットフォームアダプタモジュール３１４から受信する。サーバ側プラットフォーム非依存ランタイム状態は、ＰＩスナップショット内において、ブラウザ側プラットフォーム非依存ランタイム状態と結合される。アクティブセッションのプラットフォーム非依存ランタイム状態を含むＰＩスナップショットは、リポジトリサーバ３０８に送信される。
【０１１１】
また、状態ハンドラモジュール３５２は、プラットフォームアダプタモジュール３１４からサーバ側ＰＳスナップショットを受信する。サーバ側ＰＳスナップショットは、マッピング記述ファイルを用いて変換モジュール３５０により変換される。この変換により、サーバ側プラットフォーム依存ランタイム状態がサーバ側プラットフォーム非依存ランタイム状態に変換される。サーバ側プラットフォーム非依存ランタイム状態は、状態ハンドラモジュール３５２により、ブラウザ側プラットフォーム非依存ランタイム状態と結合される。
【０１１２】
さらに別の態様において、状態ハンドラモジュール３５２は、サーバ側プラットフォーム依存ランタイム状態を含むサーバ側ＰＳスナップショットを受信する。状態ハンドラモジュール３５２は、サーバ側ＰＳスナップショットと、ブラウザ側プラットフォーム依存ランタイム状態を含むブラウザ側ＰＳスナップショットとを結合する。サーバ側およびブラウザ側ＰＳスナップショットは結合されてプラットフォーム依存ランタイム状態スナップショットとなる。プラットフォーム依存ランタイム状態スナップショットは、状態ハンドラモジュール３５２により、ネットワーク１２を介してリポジトリサーバ３０８に送信される。
【０１１３】
以前に保存されたＰＩスナップショットが記憶装置から読み出されると、状態ハンドラモジュール３５２はＰＩスナップショットを受信して、ＰＩスナップショットからブラウザ側プラットフォーム非依存ランタイム状態を抽出する。ブラウザ側プラットフォーム非依存ランタイム状態は変換モジュール３５０に提供され、変換モジュール３５０はブラウザ側プラットフォーム非依存ランタイム状態をブラウザ側ＰＳスナップショットに変換する。変換後、ブラウザ側プラットフォーム依存ランタイム状態は、アクティブセッションとしてインスタンス化される。
【０１１４】
図１０に示すように、リポジトリサーバ３０８はＢＳＭリポジトリモジュール３２２を備える。図１および６に示されるリポジトリサーバ１８と同様に、リポジトリサーバ３０８は、ネットワーク１２を介して、第１および第２の装置３０４、３０６、およびアプリケーションサーバ３０２と連携して動作する。また、リポジトリサーバ３０８は、第１および第２の装置３０４、３０６とのみ通信を行ってもよい。
【０１１５】
図１５は、ＢＳＭリポジトリモジュール３２２の一実施形態を示すブロック図である。ＢＳＭリポジトリモジュール３２２は、図６に示される上述のログインセキュリティコンポーネント８０、ページサーバコンポーネント８２、スナップショット保存コンポーネント８４、および通信セキュリティコンポーネント８６に加えて、状態ハンドラモジュール３５４を備える。状態ハンドラモジュール３５４は、第１および第２の装置３０４、３０６、および／またはアプリケーションサーバ３０２のいずれかからブラウザ側ＰＳスナップショットとサーバ側ＰＳスナップショットを受信し、変換、結合してＰＩスナップショットを生成する。別の態様において、ＢＳＭリポジトリモジュール３２２は任意の数のモジュールを備えてよい。
【０１１６】
また、状態ハンドラモジュール３５４は、ブラウザ側プラットフォーム依存ランタイム状態とサーバ側プラットフォーム依存ランタイム状態とを含むプラットフォーム依存ランタイム状態スナップショットを受信して、ＰＩスナップショットに変換する。別の態様において、ＰＩスナップショットが、アプリケーションサーバ３０２のプラットフォームアダプタモジュール３１４または状態ハンドラモジュール３５２によって生成される場合、リポジトリサーバ３０８は状態ハンドラモジュール３５４を備えていなくてもよい。この場合、ＰＩスナップショットはリポジトリサーバ３０８に送信され、スナップショット保存コンポーネント８４によって保存される。
【０１１７】
尚、ＢＳＭリポジトリモジュール３２２は、図６に示されるタイミングコンポーネント８８を備えていない。ＢＳＭシステム３００では、アクティブセッションのブラウザ側およびサーバ側ランタイム状態の両方がスナップショットに取り込まれるため、タイミングコンポーネント８８が不要となる。従って、アプリケーションサーバ３０２とのアクティブセッションを維持するための時間管理が不要となる。
【０１１８】
ユーザは、第１の装置３０４等の通信装置を用いてマルチプラットフォームネットワークアプリケーションの起動を要求し、アクティブセッションを開始する。第１の装置３０４上で動作する第１のブラウザ３１８とのアクティブセッションを確立、維持するために、マルチプラットフォームネットワークアプリケーションのプラットフォーム依存バージョンがサーバ状態とともに用いられる。アクティブセッション中、第１の装置３０４のユーザは、ＢＳＭシステム３００を利用してアクティブセッションの取り込みを開始する。
【０１１９】
アクティブセッションのプラットフォーム依存ランタイム状態は、ＰＳスナップショットとして取り込まれる。具体的には、第１の装置３０４上で動作する第１のブラウザ３１８のブラウザ現状態と、アプリケーションサーバ３０２のサーバ現状態が取り込まれる。ブラウザ現状態を含むＰＳスナップショットとサーバ現状態を含むＰＳスナップショットは結合され、アクティブセッションのプラットフォーム非依存ランタイム状態を含むＰＩスナップショットに変換される。ＰＩスナップショットはリポジトリサーバ３０８に保存される。
【０１２０】
ＰＩスナップショットは、第２の装置３０６等の対象装置を用いて後で読み出される。ＰＩスナップショットは、第２の装置３０６のハードウェアおよび／またはソフトウェア能力（プラットフォーム）に基づいてＰＳスナップショットに変換される。サーバ側ＰＳスナップショットには、サーバ側プラットフォーム依存ランタイム状態データが含まれ、ブラウザ側ＰＳスナップショットには、ブラウザ側プラットフォーム依存ランタイム状態データが含まれる。プラットフォーム依存ランタイム状態はアクティブセッションとしてインスタンス化され、以前に確立されたアクティブセッションが再開される。アクティブセッションの再開には、アプリケーションサーバ３０２と第２の装置３０６上で動作する第２のブラウザ３２０が用いられる。従って、アクティブセッションは、あらゆるプラットフォーム上で復元可能である。
【０１２１】
ＢＳＭシステム３００では、プラットフォーム依存ランタイム状態の相違に対して変換をもって対応する。この変換は、プラットフォーム依存ランタイム状態およびプラットフォーム非依存ランタイム状態間の選択的なマッピングに基づいて行われる。ＢＳＭシステム３００では、このマッピングを通じてプラットフォーム依存ランタイム状態間の相違を調整する。ＢＳＭシステム３００によれば、あるプラットフォームに依存する表示から別のプラットフォームに依存する表示への構成要素のマッピングが容易になるため、異なるプラットフォーム間のシームレスな変換が可能になる。
【０１２２】
ＢＳＭシステム３００において、ページレイアウト、ユーザインターフェイス装置、状態メンテナンス等の相違、およびその他のプラットフォームに依存する相違は、変換によって対処される。ページレイアウトは、アクティブセッション中のページにおいてどのようにタスクが細分化または統合されるかを示す。タスクは、ユーザによって命令される、検索、購入、選択等のアクティブセッション中のさまざまな機能を指す。ユーザインターフェイス装置は、キーパッド、キーボード、タッチスクリーン、マウス等のランタイム状態データの入力やアクティブセッション中の操作の際にユーザによって操作される装置を指す。状態メンテナンスは、データベース入力、クッキー、スクリプト変数、隠しフォームフィールド等の状態をプラットフォーム依存アプリケーションがページ間でどのように維持するかを示す。状態メンテナンスは、ブラウザ状態およびサーバ状態間でどのように状態が同期化されるかも示す。
【０１２３】
ＰＳスナップショットをマッピングする際には、ページおよびデータが選択的にマッピングされる。ページは、各ページがプラットフォーム非依存タスクに対応しているものとみなしてマッピングされる。上述したように、データには、フォーム制御、クッキー、ＪＳＰ変数、スクリプト変数等が含まれる。あるマッピング方法例では、ＰＳスナップショットのデータをマッピングする際に、固有のプラットフォーム非依存名称がデータに選択的に割り当てられる。プラットフォーム依存データは、マッピング記述ファイルを用いて、割り当てられた固有のプラットフォーム非依存名称にマッピングされ、プラットフォーム依存データからプラットフォーム非依存データに変換される。同様に、プラットフォーム非依存データを特定のプラットフォームのＰＳスナップショットに変換する場合には、当該特定のプラットフォームに対応するマッピング記述ファイルを用いて、固有のプラットフォーム非依存名称からＰＳスナップショットのプラットフォーム依存データに変換される。
【０１２４】
マッピング機構の一実施例として、ＨＴＭＬの注と２つの単純なＸＭＬドキュメントを用いるタイプがある。このマッピング機構を説明するために、ＢＳＭモジュール３１６によるＰＩスナップショットの保存および復元動作の一例を取り上げる。ＢＳＭモジュール３１６は、マルチプラットフォームＩＤに基づいてアプリケーションをマルチプラットフォームアプリケーションと特定する。マルチプラットフォームＩＤの一例としては、＜link rel＝"bsm-map" href＝"my-platform.xml"＞等の各
ＨＴＭＬページのヘッダの１行がある。この場合、リンク要素はＨＴＭＬ標準の一部であり、２つのドキュメント間の関係を指定するために用いられる。この場合の関係は、ブラウザを用いて現在閲覧されているページにはマッピングが適用され、マッピング記述ファイル（この場合、"my-platform.xml"）にマッピングが記述されてい
ることを指定している。
【０１２５】
マッピング記述ファイルは、保存および復元プロセスにおいて、プラットフォーム依存およびプラットフォーム非依存ランタイム状態間の変換を行う際の指示書としてＢＳＭモジュール３１６に用いられる。このタイプのマッピング記述ファイルのＤＴＤ（Document Type Definition）では次の構造が指定される。
・map要素は、後述するマスターマッピングファイルのＵＲＬと１以上のpage要素を含む。
・page要素は、ページのＵＲＬからネットワークアプリケーションの変則的かつ概念的な１以上のタスクへのマッピングを行う。タスクは０以上のcontrol要素を含む。
・control要素は、プラットフォーム依存ユーザインターフェイス装置名から固有のプラットフォーム非依存名称へのマッピングを行い、０以上のvalue要素を含む。
・value要素（セッションデータおよび／または状態データ）は、ユーザインターフェイス装置等のプラットフォーム依存値からプラットフォーム非依存値へのマッピングを行う。
【０１２６】
マッピング記述ファイルは、アプリケーション開発者によって、ネットワークアプリケーションの各プラットフォーム依存バージョン用に選択的に記述される。例えば、マッピング記述ファイルは、第１のプラットフォームに依存するバージョンのあるpage要素（タスク）中のcontrol要素に含まれる値（データ）の範囲から、第２のプラットフォームに依存するバージョンの別のpage要素（タスク）中の別のcontrol要素に含まれる値（データ）の範囲へ明示的にマッピングされるように記述される。マッピング記述ファイルにより、アプリケーション開発者には、異なるプラットフォームに依存するアプリケーション間において名称および値の範囲が異なるcontrol要素のみに対して選択的にマッピングするという柔軟性が与えられる。異なるプラットフォームに依存するアプリケーション間において名称および値の範囲が同じ場合には、例えば、固有のプラットフォーム非依存名称へのマッピングが指定される必要がない。別々のプラットフォーム依存バージョン間において名称および値の範囲が全て同じ場合、アプリケーション開発者は、マッピング記述ファイルにおいてpage要素（タスク）のマッピングのみ指定すればよい。
【０１２７】
以下の例では、３つのページがタスクにマッピングされ、control要素（この例では、＜select＞または＜input type＝"radio"＞要素グループを想定）が固有のプラットフォーム非依存名称および値の範囲にマッピングされている。
＜map master＝"master.xml"＞
＜page url＝"http://localhost/foo.html" task＝"foo"＞
＜control from＝"ab" to＝"alphabravo"＞
＜value from＝"a" to＝"alpha"＞
＜value from＝"b" to＝"bravo"＞
＜value from＝"c" to＝"charlie"＞
＜/control＞
＜/page＞
＜page url＝"http://localhost/bar.html" task＝"bar"/＞
＜page url＝"http://localhost/baz.html" task＝"baz"/＞
＜/map＞
【０１２８】
ＢＳＭシステム３００では、各マルチプラットフォームネットワークアプリケーションに対してアプリケーション開発者によって作成されるマスターマッピングファイルが用いられる。マスターマッピングファイルには、プラットフォームとマッピング記述ファイルとの対応関係が記述されている。ＢＳＭシステム３００では、ＰＩスナップショットを復元する際にマスターマッピングファイルが用いられる。マスターマッピングファイルによって、ＰＩスナップショットからブラウザ側ＰＳスナップショットおよびサーバ側ＰＳスナップショットへの変換またはその逆の変換の際に用いられるマッピング記述ファイルが特定される。同様に、ＰＳスナップショットによって、プラットフォーム依存バージョンの表示の際にロードされるページが特定される。
【０１２９】
一般的に、マルチプラットフォームネットワークアプリケーションは、起動要求に基づいて表示を選択する。起動要求は、例えばＨＴＴＰ要求で送信されるuser-agentストリングである。同様に、ＢＳＭシステム３００では、移動させたランタイム状態に対応する表示が選択される。表示は、アクティブセッション中の条件、デフォルト表示、またはその他のランタイム状態に関連するパラメータに基づいて選択される。ある態様では、マルチプラットフォームネットワークアプリケーションが表示を選択する際に用いられる方法と同様の方法がＢＳＭシステム３００において用いられる。以下は、ＤＴＤの一例である。
・master要素は１以上のmap要素を含む。
・map要素は、user-agentストリングに対応する正規表現と、user-agentストリングと関連付けられたマッピング記述ファイルに対応するＵＲＬとを含む。複数の正規表現がuser-agentストリングに対応する場合には、マッピング記述ファイルの最初の正規表現が用いられる。
【０１３０】
以下は、マスターマッピングファイルの一例である。
＜master＞
＜map useragent＝"windows" url＝"pc-map.xml"/＞
＜map useragent＝"pocket" url＝"ppc-map.xml"/＞
＜map useragent＝"*" url＝"default-map.xml"/＞
＜/master＞
【０１３１】
このマスターマッピングファイルでは、"windows"を含む全てのuser-agentストリングがpc-map.xml記述ファイルと、"pocket"を含むuser-agentストリングがppc-map.xml記述ファイルと、そしてその他のuser-agentストリングがdefault-map.xml記述ファイルと関連付けられている。
【０１３２】
上述のマッピングおよび変換は、ＢＳＭモジュール３１６、プラットフォームアダプタモジュール３１４、および／またはＢＳＭリポジトリモジュール３２２において行われる。ある態様において、マッピングはＸＭＬ等のコードを用いて行われる。図１６は、上述のブックストアアプリケーションのサーバ側ＰＳスナップショットからＰＩスナップショットへマッピングする、アプリケーション記述およびマッピング記述ファイルの一例である。
【０１３３】
上記の例がマッピングの完全な実施例ではなく、ＢＳＭシステム３００におけるマッピングの一実施例であることは当業者にとって明らかである。一般的に、アプリケーション記述およびマッピング記述ファイルでは、セッションデータおよび状態データがname属性とtype属性の対で記述される。
【０１３４】
ＢＳＭシステム３００では、有限状態機械（Finite State Model：ＦＳＭ）の概念に基づいてプラットフォーム依存表示がモデル化される。ＢＳＭシステム３００では、ＦＳＭの概念を用いてマルチプラットフォームネットワークアプリケーションのプラットフォーム依存バージョンのプラットフォーム依存表示の構造が表される。ＦＳＭモデルとともに上述のマッピングを用いて、異なるプラットフォーム間を移動させるランタイム状態を選択的に変換する。
【０１３５】
ＢＳＭシステム３００において、ＦＳＭモデルは、ある頂点から次の頂点を結ぶ各辺が頂点の順序対となる有向グラフである。マルチプラットフォームネットワークアプリケーションのプラットフォーム依存バージョンの各プラットフォーム依存表示の構造は、有向グラフを用いてモデル化される。
【０１３６】
ＦＳＭモデルの有向グラフは、状態を示す頂点と状態間の遷移を示す辺からなる。ここで、ＦＳＭモデルにおける状態は、プラットフォーム依存表示のタスクを指す。ＦＳＭモデルにおける状態間の遷移は、アクティブセッションのプラットフォーム依存表示中の移動を指す。移動には、ブラウザにおけるフォームの送信やリンク先に飛ぶ等の、アクティブセッション中のユーザの操作が含まれる。アクティブセッションのランタイム状態を保存および復元するためには、ＦＳＭモデルにおける遷移が明示的にモデル化されなくてもよい。その代わりに、ネットワークアプリケーションのプラットフォーム依存バージョンの論理に暗示されていると推定される。
【０１３７】
データフィールドは、ＦＳＭモデルにおける各状態と関連付けられる。データフィールドは、プラットフォーム依存表示においてユーザに提示されるフォーム制御に相当する。さらに、アクティブセッションのプラットフォーム依存表示の状態データおよびセッションデータがデータフィールドに含まれる。状態データは、ブラウザ状態および／またはサーバ状態のタスクデータを表すセッション固有のデータである。「ショッピングカート」の内容やクッキー等のセッションデータは、アクティブセッション中、状態間で不変である。
【０１３８】
ＦＳＭモデルを用いることによって、ネットワークアプリケーションのプラットフォーム依存バージョンの各アクティブセッションに関連付けられた表示の全ての構造が表される。アクティブセッションのブラウザ側およびサーバ側プラットフォーム依存ランタイム状態もまた、ＦＳＭモデルを用いて表されるプラットフォーム依存表示に含まれる。
【０１３９】
例えば、プラットフォーム依存表示例である図１１、１２、および１３では、それぞれ異なるＦＳＭモデルが用いられてマルチプラットフォームネットワークアプリケーションのプラットフォーム依存表示の構造が表されている。ＦＳＭモデルにおける状態は、アクティブセッション中のブラウザに表示される、特定のプラットフォームを特に対象とするページを表す。例えば、図１２に示される第２の表示例には３つの状態３２６、３２８、および３３０が表示されている。ＦＳＭモデルにおけるデータフィールドには、アクティブセッション中にユーザによってブラウザに生成される状態データおよびセッションデータ（例えば、ブラウザ側ランタイム状態）が含まれる。例えば、送信されなかった、名前等のチェックアウト情報は、プラットフォーム依存表示の状態データとしてブラウザ側ランタイム状態に含まれる。
【０１４０】
同様に、サーバ側のプラットフォーム依存表示もＦＳＭモデルを用いて表される。サーバ側のＦＳＭモデルにおけるデータフィールドも状態データおよびセッションデータ（例えば、サーバ側ランタイム状態）を表す。例えば、ユーザが要求する書籍目録がアクセスされるデータベースは状態データの一部である。
【０１４１】
マッピング記述ファイルを用いたマッピングによれば、各プラットフォーム依存ＦＳＭモデルで表されるプラットフォーム依存ランタイム状態およびデータフィールドを、プラットフォーム非依存ランタイム状態およびプラットフォーム依存ランタイム状態間で選択的に変換することが可能になる。マッピングによれば、ランタイム状態と、ユーザが操作している装置とが関連付けられることがない。さらに、マッピングによって、マルチプラットフォームネットワークアプリケーションの異なるプラットフォームに依存するバージョン間における、ユーザインターフェイス装置およびページレイアウトの相違がモデル化される。例えば、データフィールドは、マルチプラットフォームネットワークアプリケーションのプラットフォーム依存バージョンに基づいて、アクティブセッション中の各タスクにおいてユーザに選択的に提示される操作手段を表す。操作手段は、各プラットフォーム依存ネットワークアプリケーションの論理に基づいて提示されてもよい。
【０１４２】
ＢＳＭシステム３００では、ネットワークアプリケーションのプラットフォーム依存バージョンのどの状態（例えば、表示）でユーザがＰＩスナップショットを保存したかが特定される。従って、ユーザがＰＩスナップショットを保存した時点の状態のＩＤがネットワークアプリケーションのプラットフォーム依存バージョン間でランタイム状態とともに転送される。ＰＩスナップショットが読み出されて復元される際には、ＰＩスナップショットが保存された時と同じ状態（ランタイム状態を含む）にアクティブセションが復元される。
【０１４３】
ユーザがＰＩスナップショットを保存した時点の状態は、次の比較的容易な２段階プロセスで特定される。まず、表示構造を表すＦＳＭモデルにおける状態を調べて、表示ページ中の一部入力されたデータフィールドを特定する。一部入力されたデータフィールドが存在しない、または複数存在する場合には、アプリケーション開発者によって指定されたデフォルト状態が、ユーザがＰＩスナップショットを保存した時点の状態として特定される。
【０１４４】
ＰＩスナップショットの復元時も、ユーザがＰＩスナップショットを保存した時点の状態が同様に特定される。第１のプラットフォームに依存する表示のＦＳＭモデルにおける状態のうちデータフィールドの一部のみにデータが入力されている状態が存在する場合には、その状態が、ユーザがＰＩスナップショットを保存した時点の状態として特定される。アクティブセッションが再インスタンス化される際には、特定された状態に対応する、第２のプラットフォームに依存する表示の状態が特定されて、その状態に関連付けられた表示が行われる。一部入力されたデータフィールドが存在しない、または複数存在する場合には、デフォルトマッピングを用いて状態が特定される。
【０１４５】
図１７は、図１０に示されるＢＳＭシステム３００の動作例を示すフローチャートである。ここでは、アクティブセッションを表すＰＩスナップショットが保存される。まず、ブロック４０２において、ユーザは第１の装置３０４上で第１のブラウザ３１８を起動する。ブロック４０４において、ユーザは、第１の装置３０４を用いてリポジトリサーバ３０８にログオンする。ブロック４０６において、ユーザは、第１の装置３０４を用いてアクティブセッション開始要求をアプリケーションサーバ３０２に送信する。
【０１４６】
ブロック４０８において、アプリケーションサーバ３０２は、第１の装置３０４のプラットフォームの種類を特定する。ブロック４１０において、アプリケーションサーバ３０２は、第１の装置３０４のプラットフォームに対応する、マルチプラットフォームネットワークアプリケーションのプラットフォーム依存バージョンを起動する。ブロック４１２において、第１の装置３０４の第１のブラウザ３１８は画面を表示する。ブロック４１４において、ユーザがアクティブセッション中に操作を行うと、ブラウザ状態およびサーバ状態の変更が行われる。ブロック４１６において、ユーザは、第１の装置３０４を用いてアクティブセッションのスナップショット取り込みを開始する。
【０１４７】
ブロック４１８において、第１の装置３０４のＢＳＭモジュール３１６は、ネットワーク１２を介してプラットフォームアダプタモジュール３１４に保存要求を送信する。この保存要求はＵＲＬ等のリソースロケータであり、第１の装置３０４のプラットフォームを特定するための少なくとも１の暗号化された変数が添付されている。ブロック４２０において、プラットフォームアダプタモジュール３１４は、アクティブセッションのサーバ側ランタイム状態（状態データおよびセッションデータ）をサーバ側ＰＳスナップショットとして取り込む。ブロック４２２では、マスターマッピングファイルを用いて、保存要求で特定されるプラットフォームに対応するマッピング記述ファイルを特定する。ブロック４２４では、特定されたマッピング記述ファイルを用いて、サーバ側ＰＳスナップショットがＰＩスナップショットに変換される。
【０１４８】
図１８のブロック４２６において、プラットフォームアダプタモジュール３１４は、保存要求に対する応答として第１の装置３０４に対してＰＩスナップショットを送信する。ブロック４２８では、保存要求に対する応答として、特定されたマッピング記述ファイルがさらに第１の装置３０４に送信される。ブロック４３０において、ＢＳＭモジュール３１６は、サーバ側プラットフォーム非依存ランタイム状態を含むＰＩスナップショットを受信する。ブロック４３２において、ＢＳＭモジュール３１６は、ブラウザ側ＰＳスナップショットとしてブラウザ側プラットフォーム依存ランタイム状態を取り込む。ブロック４３４において、ＢＳＭモジュール３１６は、マッピング記述ファイルを用いてブラウザ側ＰＳスナップショットをブラウザ側プラットフォーム非依存ランタイム状態に選択的に変換する。ブロック４３６において、ブラウザ側プラットフォーム非依存ランタイム状態は、アプリケーションサーバ３０２から受信したＰＩスナップショットのサーバ側プラットフォーム非依存ランタイム状態と結合される。ブロック４３８において、アクティブセッションのプラットフォーム非依存ランタイム状態を含むＰＩスナップショットは、シリアル化されてリポジトリサーバ３０８に送信される。ブロック４４０において、リポジトリサーバ３０８はＰＩスナップショットを保存する。
【０１４９】
別の態様において、ブラウザ側ランタイム状態とサーバ側ランタイム状態は、アプリケーションサーバ３０２または第１の装置３０４のいずれにおいて変換されてもよい。さらに別の態様において、リポジトリサーバ３０８は、アプリケーションサーバ３０２および第１の装置３０４からネットワーク１２を介して送信されるＰＳスナップショットをマッピング記述ファイルを用いて選択的に変換してもよい。さらに別の態様において、第１の装置３０４が、アプリケーションサーバ３０２から送信されるサーバ側ＰＳスナップショットとブラウザ側ＰＳスナップショットをリポジトリサーバ３０８に送信し、リポジトリサーバ３０８がＰＳスナップショットをＰＩスナップショットに変換してもよい。以上より明らかなように、ＢＳＭシステム３００内の任意の場所で、マッピング記述ファイルを用いたＰＩスナップショットへの変換が可能である。
【０１５０】
図１９は、図１０に示されるＢＳＭシステム３００の動作例を示すフローチャートである。ここでは、図１７および１８に示されるように第１の装置３０４を用いて保存されたＰＩスナップショットが、アクティブセッションに復元される。まず、ブロック５０２において、第２の装置３０６等の通信装置上でブラウザを起動する。ここでは説明のため、第２の装置３０６のプラットフォームが第１の装置３０４のものとは異なると想定する。ブロック５０４において、ユーザは第２の装置３０６を用いてリポジトリサーバ３０８にログオンする。ブロック５０６において、ユーザは、以前に保存されたアクティブセッションのＰＩスナップショットの復元を決定し、ネットワーク１２を介してリポジトリサーバ３０８に復元要求を送信する。ブロック５０８において、リポジトリサーバ３０８は、復元要求の応答として、保存されたＰＩスナップショットをネットワーク１２を介して第２の装置３０６に送信する。
【０１５１】
ブロック５１０において、第２の装置３０６のプラットフォームのＩＤがセッション再開要求に含まれる。このセッション再開要求には、第２の装置３０６上で表示される表示状態を特定するための少なくとも１の暗号化された変数と、ＵＲＬ等のリソースロケータが含まれる。ブロック５１２において、第２の装置３０６は、セッション再開要求により、保存されたＰＩスナップショットをアプリケーションサーバ３０２に送信する。ブロック５１４において、プラットフォームアダプタモジュール３１４はマスターマッピングファイルにアクセスして、第２の装置３０６のプラットフォームに対応するマッピング記述ファイルを特定する。ブロック５１６において、プラットフォームアダプタモジュール３１４は、特定されたマッピング記述ファイルを用いて、ＰＩスナップショットに含まれるサーバ側ランタイム状態をサーバ側ＰＳスナップショットに変換する。ブロック５１８において、プラットフォームアダプタモジュール３１４はサーバ側ＰＳスナップショットに含まれるサーバ側ランタイム状態を再インスタンス化する。ブロック５２０において、プラットフォームアダプタモジュール３１４は、セッション再開要求に対する応答として、セッション再開要求で特定される表示状態に対応する、復元されたアクティブセッションのページを送信する。
【０１５２】
ブロック５２２において、プラットフォームアダプタモジュール３１４は、セッション再開要求に対する応答として、特定されたマッピング記述ファイルも第２の装置３０６に送信する。ブロック５２４において、第２の装置３０６のＢＳＭモジュール３１６は、マッピング記述ファイルを用いてＰＩスナップショットをブラウザ側ＰＳスナップショットに変換する。ブロック５２６において、第２の装置３０６の第２のブラウザ３２０は、アプリケーションサーバ３０２がら送信されたページを表示する。ブロック５２８において、ＢＳＭモジュール３１６はブラウザ側ランタイム状態を再インスタンス化することで、表示ページ中のフォームにデータが入力され、スクリプト変数、クッキー等が再び初期化される。ブラウザ側ＰＳスナップショットが完全に復元されると、ブロック５３０において、ユーザは第２の装置３０６の第２のブラウザ３２０を用いて、スナップショットが取り込まれた時点からアクティブセッションを再開する。別の態様において、ＢＳＭシステム３００の他の装置が、マッピング記述ファイルを用いてＰＩスナップショットをＰＳスナップショットに変換してもよい。
【０１５３】
別の態様において、ＢＳＭシステム３００は、上述したＢＳＲサービス１０と同様に、ブラウザ側ランタイム状態のみをスナップショットとして取り込んでもよい。しかしながら、ＢＳＭシステム３００は、ブラウザ側ＰＳスナップショットおよびＰＩスナップショット間のランタイム状態の変換をマッピングする能力をさらに備える。従って、ＢＳＭシステム３００によれば、マルチプラットフォームネットワークアプリケーションの各プラットフォーム依存バージョン間で異なるページレイアウト、ユーザインターフェイス装置、およびアプリケーション状態がシームレスに変換される。ＢＳＭシステム３００が提供する柔軟性のある枠組みでは、アプリケーション開発者が、異なるプラットフォーム上で動作するブラウザ間におけるブラウザ側ランタイム状態のマッピングを選択的に指定できる。
【０１５４】
この場合、サーバ側で維持されるアプリケーション状態の取り込み、変換、および保存は行われない。従って、サーバがアクティブセッションを終了すると、ＢＳＭシステム３００を利用して保存されたＰＩスナップショットは無効になる。保存されたアクティブセッションの無効を回避するために、リポジトリサーバ３０８は図６に示されるタイミングコンポーネント８８も備える。図６を参照して説明したように、タイミングコンポーネント８８は、一旦ＰＩスナップショットが保存されるとアクティブセッションの管理を開始する。または、一旦ＰＩスナップショットが保存されると、アクティブセッションのタイムアウトまでの時間延長やタイムアウトの停止が行われる。
【０１５５】
サーバ側ランタイム状態が取り込まれないため、ＢＳＭシステム３００の提供者がアプリケーションサーバ３０２の提供者でない場合に、アプリケーションサーバ３０２内部の情報が漏れるのを回避できる。具体的には、アプリケーションサーバ３０２が、全ての一般プログラミング言語およびサーバ環境に適応するように、ＣＧＩスクリプトの任意変数等の変数を変更できる構成とされる必要がなくなる。さらに、アプリケーションサーバ３０２内部の情報が外部に漏れることに伴い予想されるセキュリティリスクが回避できる。さらに、ブラウザ側ランタイム状態のみマッピングが行われる場合には、アプリケーション開発者による努力をそれほど必要とせずに、マルチプラットフォームネットワークアプリケーションのローミングが可能になる。
【０１５６】
第１および第２の装置３０４、３０６が備えるコンポーネントによる上述の処理を実行するプログラムを、アプリケーションプログラムとして第１および第２の装置３０４、３０６にインストールしてもよい。さらには、このようなプログラムを記録したＣＤ−ＲＯＭ等の様々な記録媒体をユーザに提供するようにしてもよいし、インターネット等の通信回線を介してユーザに提供するようにしてもよい。
【０１５７】
【発明の効果】
上述したＢＳＭシステム３００によれば、任意のプラットフォームおよび任意のブラウザ上におけるアクティブセッションの取り込み、保存、および復元が可能になる。マルチプラットフォームネットワークアプリケーションのプラットフォーム依存バージョンのランタイム状態は取り込まれると、プラットフォーム非依存ランタイム状態に変換されて保存される。同様に、プラットフォーム非依存ランタイム状態は読み出されると、異なるプラットフォームに依存するランタイム状態に変換されて、マルチプラットフォームネットワークアプリケーションの、異なるプラットフォームに依存するバージョンに対応するプラットフォーム上で使用される。従って、ランタイム状態とプラットフォームとが関連付けられることがない。さらに、ランタイム状態には、アクティブセッションのサーバ側およびブラウザ側ランタイム状態の両方が含まれるため、アクティブセッションは無期限に保存され、アクティブセッションの状態データおよびセッションデータが完全な状態で復元される。また、ブラウザ側ランタイム状態のみが保存される場合でも、ランタイム状態と特定のプラットフォームとが関連付けられることはない。
【０１５８】
以上、本発明を具体的な実施形態を参照して説明してきたが、請求の範囲に記載された本発明の意図および範囲から逸脱することなくこれらの実施形態に対して種々の変更が可能であることは明白である。従って、本明細書および図面は例示的なものであり、限定的なものではない。
【図面の簡単な説明】
【図１】ＢＳＲサービスを示すブロック図である。
【図２】図１に示されるＢＳＲサービスを示す詳細なブロック図である。
【図３】図２に示されるＢＳＲ装置モジュールを示す詳細なブロック図である。
【図４】図３に示されるＢＳＲ装置モジュールにより起動されるユーザインターフェイスバーの一例を示す図である。
【図５】図３に示されるＢＳＲ装置モジュールにより起動されるユーザインターフェイスバーの別の例を示す図である。
【図６】図２に示されるＢＳＲリポジトリモジュールを示す詳細なブロック図である。
【図７】ＢＳＲサービスの一動作例を示すフローチャートである。
【図８】図７に示されるＢＳＲサービスの一動作例の続きを示すフローチャートである。
【図９】ＢＳＲサービスの動作例を示すフローチャートである。
【図１０】ブラウザセッションモビリティ（ＢＳＭ）システムを示すブロック図である。
【図１１】図１０に示されるＢＳＭシステム内のブラウザ／プラットフォーム上の表示例である。
【図１２】図１０に示されるＢＳＭシステム内のブラウザ／プラットフォーム上の第２の表示例である。
【図１３】図１０に示されるＢＳＭシステム内のブラウザ／プラットフォーム上の第３の表示例である。
【図１４】ＢＳＭモジュールを示す詳細なブロック図である。
【図１５】ＢＳＭリポジトリモジュールを示す詳細なブロック図である。
【図１６】アプリケーション記述およびマッピング記述ファイルの一例を示す図である。
【図１７】図１０に示されるＢＳＭシステムによる、アクティブセッションの取り込み、変換、および保存動作の一例を示すフローチャートである。
【図１８】図１７に示されるＢＳＭシステムの動作例の続きを示すフローチャートである。
【図１９】図１０に示されるＢＳＭシステムによる、異なるプラットフォーム上でアクティブセッションを復元する動作の一例を示すフローチャートである。
【符号の説明】
１０…ブラウザ状態リポジトリ（ＢＳＲ）サービス、１２…ネットワーク、１４、３０４…第１の装置、１６、３０６…第２の装置、１８、３０８…リポジトリサーバ、２０、３１８…第１のブラウザ、２２、３２０…第２のブラウザ、３０…サイト、３４…ＢＳＲ装置モジュール、３６…ＢＳＲリポジトリモジュール、４０…インターフェイスコンポーネント、４２…セキュリティコンポーネント、４４…取り込みコンポーネント、４６…復元コンポーネント、５２…ユーザＩＤ欄、５４…パスワード欄、５６…サインオンボタン、５８…リセットボタン、６０…認証装置ＩＤ欄、６２…ユーザＩＤ欄、６４…スナップショットボタン、６６…セッション名欄、６８…セッションパスワード欄、７０…復元ボタン、７２…セッション選択欄、７４…サインオフボタン、７６…ＢＳＲリポジトリモジュール欄、８０…ログインセキュリティコンポーネント、８２…ページサーバコンポーネント、８４…スナップショット保存コンポーネント、８６…通信セキュリティコンポーネント、８８…タイミングコンポーネント、３００…ＢＳＭシステム、３０２…アプリケーションサーバ、３１２…サーバ状態モジュール、３１４…プラットフォームアダプタモジュール、３１６…ＢＳＭモジュール、３２２…ＢＳＭリポジトリモジュール、３２４…第１のブラウザ表示例、３２６…書籍目録タスク、３２８…ショッピングカートタスク、３３０…チェックアウトタスク、３３４…第２のブラウザ表示例、３４０…第３のブラウザ表示例、３４４…プルダウンメニュー、３５０…変換モジュール、３５２、３５４…状態ハンドラモジュール。[0001]
BACKGROUND OF THE INVENTION
The present invention relates generally to communication between devices on a network, and in particular, saves the browser state of one or more independent active sessions established using a browser and saves using the same or different browsers and / or platforms. The present invention relates to a method and system for later retrieving and resuming a created session.
[0002]
[Prior art]
Today, the Internet is commonly used not only to access information but also to purchase goods and services. Usually, a browser is required to access the Internet. Browsers are used to access websites via the Internet. Through this website, the user can acquire information and purchase goods and services. Usually, the interaction between the browser and the website is session-oriented. In general, a website first requests a browser to establish a session and a session ID. The website uses the session ID to track and identify browsers that navigate various pages within the website.
[0003]
The browser accumulates the runtime state used when interacting with the website according to the HTTP protocol, which is stateless, during an active web session. Browser runtime state is stored as cookies, document objects, and script objects. The active web session ends when the browser interrupts access to the website for some time or when the user explicitly logs out. When the active web session ends, some of the browser state becomes unrecoverable.
[0004]
[Problems to be solved by the invention]
In this session-oriented model, when a browser that has established an active session is temporarily shut down, the user cannot continue the same active session. Furthermore, even if the user wants to switch from a browser on one device to the same or another browser on another device, the same active session cannot be continued. For example, when a user who has established an active session on a stationary device (desktop PC or the like) replaces the stationary device with a mobile device (such as a pocket PC with a wireless access function), the user is active on the stationary device. The session must be terminated and a new active session must be reestablished on the mobile device. Similarly, if an attempt is made to temporarily interrupt a wireless connection while performing other work to reduce wireless communication costs, a user who has established an active session with the mobile device cannot save the session.
[0005]
As a method for accessing a web page using a browser, use of a bookmark that stores a URL (Uniform Resource Locator) of a web page to be accessed later is widely known. For example, according to the concept of bookmarks such as “favorites” of Microsoft® Internet Explorer®, it is possible to access web pages efficiently and quickly. However, using such bookmarks only allows re-access to static web pages. For example, session-specific information such as product selection conditions, purchase information, and other information related to a specific active web session is not stored and must be created again.
[0006]
Also, the use of cookies is widely known as a method for storing information about active sessions. Cookies are typically browser-side storage mechanisms and are used to store information within or between sessions regarding the user operating the browser. Generally, a cookie is information set by a website accessed by a browser and transmitted to the website when accessed next time. Cookies are sent and stored on the device where the browser is running. When a browser accesses a website, the browser uses a cookie corresponding to the website stored previously. However, since such a cookie is stored in association with a single device, it cannot be used by a browser operating on another device.
[0007]
In addition, there are widely known methods provided by some websites that can identify browser users and store purchase information accumulated during an active session. This information is stored in a database on the server side so that it can be read out in a later session. This technique not only requires significant user tracking capabilities for each website, but also burdens the user to complete the sign-in process before making a decision to purchase goods or services. Make it. Further, purchase information stored on such websites may include active information such as pages previously displayed by the browser, customized values during the session, and / or information regarding browser navigation and associated website customization, for example. Does not contain information about the session. Thus, when establishing a new active session with a website, many of the settings customized during the previous active session must be recreated.
[0008]
[Means for Solving the Problems]
The present invention relates to a browser session mobility (BSM) system. The BSM system supports active session capture, storage, and re-instancing. An active session is established between an application server and a browser operating on a communication device that is a platform. Active sessions are supported by application servers that have a platform specific version of a multi-platform network application. When an active session is established, a platform dependent runtime state is generated. The platform dependent runtime state is captured as a snapshot, selectively converted to a platform independent runtime state, and stored in the repository server of the BSM system. When the runtime state is captured and converted, the browser-side runtime state and the server-side runtime state of the active session are captured and selectively converted. Alternatively, only browser-side runtime state may be captured, selectively converted, and saved.
[0009]
The BSM system uses a platform independent runtime state to support mobility between different platforms of multi-platform network applications. When the platform independent runtime state is read from the storage device, it is converted to an arbitrary platform dependent runtime state. Accordingly, the first platform dependent runtime state of the active session is taken from the first platform dependent version of the network application and selectively converted to a platform independent runtime state. The platform-independent runtime state is saved once and later selectively converted to a runtime state that depends on the second platform. The runtime state that depends on the second platform is re-instantiated as an active session with the second platform-dependent version of the network application.
[0010]
In the BSM system, the platform dependent runtime state and the platform independent runtime state are expressed as snapshots. A platform dependent (PS) snapshot refers to a platform dependent runtime state of at least one of a browser side and a server side runtime state. A platform independent (PI) snapshot refers to a platform independent runtime state. Each snapshot includes state data and session data of the active session. Conversion between the PI snapshot and the PS snapshot is performed based on the mapping. The mapping can selectively convert portions of the platform-dependent runtime state that differ between network applications that depend on different platforms.
[0011]
According to the BSM system, rather than associating the browser-side runtime state with the device on which the browser operates, the browser-side runtime state is saved by storing a snapshot of the runtime state in a location accessible to the user. Can be associated with a user. Furthermore, in a BSM system, an active session is not associated with a specific platform. This is made possible by capturing runtime states that include both server-side and browser-side runtime states and selectively converting them to platform-independent runtime states. Alternatively, the platform independent runtime state may include only the browser side runtime state. The platform independent runtime state is re-instantiated on any platform by being selectively converted to a platform dependent runtime state.
[0012]
A feature of the BSM system relates to the conversion between PS snapshots and PI snapshots. For example, when the browser-side runtime state is captured in the PS snapshot, the state data and / or session data forming the browser-side runtime state of the PS snapshot is selectively converted into a PI snapshot. This conversion is selectively performed using a mapping description file. According to the mapping description file, the state data and / or session data of the PS snapshot are identified as platform-dependent parts, and the identified state data and session data are converted into platform-independent state data and session data. Is done.
[0013]
Another feature of the BSM system relates to the generation of PI snapshots. The PI snapshot points to the platform independent runtime state of the active session, and the server side runtime state and the browser side runtime state are combined. The server-side runtime state is selectively converted to a PI snapshot, and the browser-side runtime state is also selectively converted and combined with the server-side runtime state of the PI snapshot. Alternatively, only the browser-side runtime state is captured and selectively converted to a PI snapshot.
[0014]
Yet another feature of the BSM system is the setting of mappings between different snapshot runtime states. The mapping is selectively set so that most or part of the state data and session data captured in the snapshot is converted or not converted at all. The amount of conversion specified by the mapping is proportional to the compatibility between different platform and session data. If the snapshot state data and session data are compatible across different platforms, no mapping is specified by the mapping. On the other hand, if the snapshot state data and part of the session data are not compatible, an appropriate conversion is specified by mapping.
[0015]
Yet another feature of the BSM system relates to the mapping between different state data and session data in the snapshot representing the runtime state of the active session. Mapping between different platforms is described in the mapping description file. The mapping description file used for a particular platform is selected using the master mapping file. When the platform is specified, a corresponding mapping description file is specified using the master mapping file. Then, the state data and session data included in the snapshot are selectively converted using the mapping description file.
[0016]
Further objects and advantages of the present invention will become apparent by reference to the following description and accompanying drawings that set forth preferred embodiments of the invention.
[0017]
DETAILED DESCRIPTION OF THE INVENTION
The present invention includes a browser state repository (BSR) service that allows a user operating a browser to save the browser state of one or more active sessions. According to the BSR service, the user can selectively read out any saved browser state using any browser and / or device and resume the same active session corresponding to the browser state. The browser's current state is restored to the same state it was saved during the active session. Thus, the BSR service allows the user to switch to a new device or browser during an active session without losing the browser state of the active session and restarting with a new browser state on the new device. In addition, the BSR service not only allows saving any active session on any device or browser and resuming it later, but also allows the user to manage the browser state of multiple active sessions simultaneously.
[0018]
FIG. 1 is a block diagram illustrating one embodiment of a BSR service 10 that operates over a network 12. The BSR service 10 has at least one device shown as a first device 14 and a second device 16. Further, the BSR service has at least one repository server 18. As shown in FIG. 1, the first and second devices 14 and 16 and the repository server 18 are communicatively connected via a network 12. In another aspect, the BSR service 10 may have any number of devices, repository servers, and / or network enabled devices. As used herein, the term “coupled”, “connected”, or “interconnect” refers to electrical coupling, optical coupling, wireless coupling, and / or between systems, devices, and / or components. Means any other connection that provides an interface.
[0019]
Network 12 is, for example, the Internet, public and / or private intranets, extranets, and / or other network configurations that allow data and command transfer. A communication medium used for communication performed in the network 12 is a wired communication system and / or a wireless communication system. The communication medium is, for example, a communication channel, radio wave, microwave, wired communication, optical fiber communication, or other communication medium capable of transmitting data, voice, and / or moving image information.
[0020]
The first and second devices 14, 16 are any type of computer device or similar hardware capable of communication connection via the network 12. In addition, the first and second devices 14, 16 have operating systems / applications associated with a user interface (UI), memory, a microprocessor, and / or other hardware. The first and second devices 14 and 16 may be, for example, a mobile phone, a personal digital assistant (PDA), a pocket personal computer (PC), or other devices capable of wireless communication. Further, the first and second devices 14 and 16 may be, for example, a network terminal, a personal computer, a server, or other devices capable of wired communication via the network 12. In another aspect, the first and second devices 14, 16 may have both wired and wireless communication capabilities.
[0021]
As shown in FIG. 1, the first browser 20 operates on the first device 14. Similarly, the second browser 22 operates on the second device 16. The first and second browsers 20 and 22 are arbitrary forms of applications that operate on the first and second devices 14 and 16 that can identify and display a page downloaded from another device on the network 12. . In the present embodiment, the first and second browsers 20 and 22 are web browsers such as Microsoft (registered trademark) Internet Explorer (registered trademark) and / or Netscape Navigator (registered trademark). In another aspect, the first and second browsers 20 and 22 have the function of specifying and displaying a page of an arbitrary format downloaded via the network 12, and the same type or different types of browsers of any format But you can. The first and second browsers 20, 22 may support the display of moving images, audio, multimedia and / or other information in addition to displaying text and graphics. The operation of the BSR service 10 is also preferably supported by the first and second browsers 20 and 22. The first and second browsers 20 and 22 are activated and operated on the first and second devices 14 and 16 and operate in cooperation with the repository server 18.
[0022]
The repository server 18 is any type of computer device that can receive requests and send responses over the network 12, such as at least one server. In this embodiment, the repository server 18 operates within the infrastructure of the BSR service 10 and has a communication function of receiving a request from the first and second devices 14 and 16 and transmitting a response. In one aspect, repository server 18 may be a hypertext transfer protocol (HTTP) server. In this aspect, the first and second devices 14, 16 may communicate with the repository server 18 using HTTP and / or reliable hypertext transfer protocol (HTTPS). In another aspect, File Transfer Protocol (FTP), Net News Transfer Protocol (NNTP), Simple Mail Transfer Protocol (SMTP), Remote Message Interface (RMI), Colba (CORBA: Common Object Request Broker Architecture), Protocols such as Component Object Model (COM), public and private protocols may be used.
[0023]
During operation of the BSR service 10, the user establishes an active session using the first browser 20 running on the first device 14. The term “active session” means any form of interaction with another device on the network 12. In this dialogue, information provided from another device is displayed, communicated, and transmitted to the user who operates the first browser 20. A typical active session is a web session that uses the first browser 20 to locate a web page and associated material, and then downloads and displays that information.
[0024]
After establishing and customizing the active session, the user can capture and save the current state of the browser of the active session using the BSR service 10. In the present specification, the term “customization” or “customization” of an active session means a change of the active session accumulated in the browser state by an interaction using the first browser 20. In addition, the terms “current browser state” or “browser state” refer to a customized state of an active session generated by a user using a browser. The browser's current state and associated attributes of the active session established using the first browser 20 are captured in a storable form. The browser's current state of the captured active session is called “snapshot” or “browser snapshot”.
[0025]
The current state of the browser of the active session is configured by the browser cache and browser history. The browser cache and browser history include, for example, the last page displayed by the first browser 20 in addition to the current state of the document object and the script object. Accordingly, the pages included in the current state of the captured active session browser may be dynamic or static. In addition, the browser cache and browser history are the current state of the browser for active sessions that can be customized by the user, customizable by the user, values that have been changed or entered on previously and / or last displayed pages. Other related parameters may also be included. The user can securely store the current state of the browser of the active session in the network 12 using the repository server 18.
[0026]
According to the BSR service 10, the user can safely retrieve the current state of the saved active session browser later. The user can retrieve the stored current state of the browser using the repository server 18 and any browser on any device. For example, the user may use the first browser 20 on the first device 14, the second browser 22 on the second device 16, or any other device and associated browser. When the current state of the saved browser is read, the browser state of the active session is restored, and the same active session can be resumed from the time when the snapshot was captured.
[0027]
For example, it is assumed that a user purchases a thick window curtain by operating the first browser 20 on an office desktop PC. Here, it is assumed that the user has to select a desired color, design, shape, and the like on different pages during an active session, and then go home and measure the window frame. Similarly, suppose that the same user uses the first browser 20 during different active sessions to schedule multiple flight schedules on separate pages for the purpose of later purchasing air tickets.
[0028]
The user uses the BSR service 10 to capture the current state of each browser in these customized active sessions before shutting down the first browser 20. Then, the user returns home, measures the window frame, finishes the travel plan, and activates the second browser 22 on the second device 16 such as a pocket PC. The user reads and restores the previously saved browser snapshot, then browses the customized page during the active session and completes the selection of the thick window curtain. In addition, the user browses a previously customized page and selects one of the flight schedules established during the previously customized active session.
[0029]
In one aspect, the BSR service 10 can be implemented using the Internet infrastructure and associated protocols. In this aspect, when the BSR service 10 is introduced, there is almost no need to make changes to existing websites, devices and browsers associated therewith. In another aspect, the BSR service 10 may be implemented using any other infrastructure and associated protocols.
[0030]
FIG. 2 is a more detailed block diagram illustrating one embodiment of the BSR service 10. As in the embodiment described with reference to FIG. 1, the BSR service 10 includes the first device 14 having the first browser 20, the second device 16 having the second browser 22, and the network 12. As shown in FIG. 2, the repository server 18 is communicated. FIG. 2 illustrates at least one site 30 in communication with the repository server 18, each of the first and second devices 14, 16 via the network 12. Further, FIG. 2 shows that as part of the infrastructure of the BSR service 10 of this embodiment, the BSR device module 34 operating on the first and second devices 14, 16 and the BSR repository module operating on the repository server 18. 36 is illustrated. In another aspect, any number of secure sites and / or non-secure sites may be included. Furthermore, the number of modules illustrated in the figure as a part of the BSR service 10 may be smaller or larger than the number shown in FIG.
[0031]
On the other hand, the site 30 is an arbitrary mechanism for communicating via the network 12 that can provide access to information via a browser. Site 30 may be a non-secure site that does not have any form of security to minimize the possibility of unauthorized access, and may be a secure site. Accordingly, the first and second browsers 20 and 22 browse the site 30 using secure or non-reliable communication depending on the level of security. The first and second browsers 20 and 22 communicate using an HTTP message when the site 30 is a non-secure site, and communicate using an HTTPS message when the site 30 is a secure site. In another aspect, the site 30 may include a secure site portion and a non-secure site portion. In this aspect, communication may be shifted between high-reliability communication and non-high-reliability communication depending on the portion of the site being viewed.
[0032]
The BSR device module 34 is an arbitrary application that is activated on at least one of the first and second devices 14 and 16. The BSR device module 34 supports the BSR service 10 by improving the functions of the first and second browsers 20 and 22 or operating in cooperation with each other. In the present embodiment, the BSR device module 34 is a downloadable browser plug-in and can be applied to the first and second browsers 20 and 22. In general, a browser plug-in is a known type of application that adds a function or service to an application. In another aspect, the BSR device module 34 may be a stand-alone module that improves the functionality of the first and second browsers 20, 22 within the first and second devices 14, 16.
[0033]
FIG. 3 is a block diagram illustrating one embodiment of the BSR device module 34. In this embodiment, the BSR device module 34 has an interface component 40, a security component 42, a capture component 44, and a restoration component 46. In another aspect, the BSR device module 34 may have additional functions such as a snapshot storage function, a user authentication function, or other functions related to the BSR service 10.
[0034]
The interface component 40 provides an interface with the BSR service 10 to users of the first and second devices 14, 16. Using this interface, the user can command the operation of additional functions provided by the BSR device module 34 in addition to the functions of the BSR service 10. In addition, the interface component 40 provides a conversion function that adapts the user interface to the hardware of a particular device. For example, the user interface may be a touch screen in one device, the user interface may be a button in another device, or the user interface may be a voice or video interaction in another device. . That is, the interface component 40 recognizes the hardware of the device and adapts the user interface to the hardware.
[0035]
The security component 42 ensures the security of the BSR service 10. That is, the security component 42 selectively performs high-reliability communication and prevents unauthorized use of the BSR service 10. The user can capture and save a browser snapshot of the active session by using the capture component 44. Similarly, the user can command the retrieved browser snapshot to be read by using the restore component 46. The function of each component of the BSR device module 34 will be described in detail below.
[0036]
4 and 5 illustrate an embodiment of the interface, taking user interface bar 50 as an example. The user interface bar 50 is activated and managed using the interface component 40 (see FIG. 3). In certain aspects, the user interface bar 50 may be displayed in a browser window that implements the graphical user interface (GUI) of the first and second devices 14, 16 (see FIG. 2). In another aspect, the user interface bar 50 may be displayed in a separate window or as a separate page. In yet another aspect, selectable functions (described below) of the user interface bar 50 are for hard buttons, individual icons, voice recognition, and / or functions of the BSR service 10 (see FIG. 2) by the user. Other mechanisms that can be commanded may be used for display.
[0037]
When the interface component 40 is activated, the user interface bar 50 according to the present embodiment displays a Hypertext Markup Language (HTML) page. In the present embodiment, this page is provided from the repository server 18 (see FIG. 2) on which the BSR repository module 36 (see FIG. 2) operates. Thus, there are relatively few changes or additions to be made to the configuration of the first and second browsers 20, 22 to execute the interface component 40.
[0038]
In another aspect, the page may be a page written in eXtensible Markup Language (XML), Wireless Markup Language (WML), Compact Hypertext Markup Language (cHTML), and / or other languages, for example. Further, this page may be provided from other devices in the network 12 that operate in conjunction with the interface component 40. In yet another aspect, the user interface bar 50 may be generated and managed solely by the interface component 40. In any of the above aspects, the interface component 40 decodes the command and information according to the command input via the user interface bar 50, and transmits the command and information via the network 12 (see FIG. 2).
[0039]
FIG. 4 shows the user interface bar 50 at the time of a login screen including a user ID field 52, a password field 54, a sign-on button 56, a reset button 58, and an authentication device ID field 60. In another aspect, the login screen of the user interface bar 50 may include other functions for identifying the user. The user can input login information on the login screen. The login information is used to prevent the user from accessing the BSR service 10 (see FIG. 2) without being authenticated and allowed access.
[0040]
As shown in FIGS. 2, 3 and 4, in this embodiment, authentication and access authorization are performed by the BSR repository module 36. In this embodiment, the user name entered in the user ID field 52 and the password entered in the password field 54 are transmitted to the BSR repository module 36 via the network 12 to receive authentication and access permission. The security component 42 establishes a reliable connection, such as a Secure Sockets Layer (SSL) connection, with the BSR repository module 36 and initiates authentication and access authorization processing. When a high-reliability connection is started by the security component 42, the user name and password information are set to, for example, an HTTPS message to ensure the security of these information. The login screen of this embodiment is preferably provided from the repository server 18 on which the BSR repository module 36 operates. In addition, a reliable connection is established using the first and second browsers 20,22.
[0041]
The security component 42 may manage the function of the login screen in cooperation with the interface component 40. For example, the security component 42 may initiate authentication and access permission processing when the sign-on button 56 is selected. Further, the security component 42 may ensure the safety of subsequent messages transmitted from the BSR device module 34 to the BSR repository module 36 via the network 12. In another aspect, the login information is externally as data from a personal information storage device (such as a personal information card), a biometric scanner (such as a voiceprint, fingerprint, retinal scanner, etc.) and / or other mechanisms for identifying the user. The security component 42 may be supplied. In yet another aspect, the security component 42 may generate a login screen and allow the user access to the functions of the BSR service 10. In yet another aspect, the security component 42 may set local security, such as a timeout password, when the user interface bar 50 has been dormant for a long time.
[0042]
The authentication device ID column 60 identifies at least one device in the network 12 to which login information is transmitted for user authentication. This device is a network-connected device capable of collating the account information created by the user with the login information transmitted via the security component 42. In this embodiment, the user creates an account using the BSR repository module 36. Therefore, the identifier of the repository server 18 on which the BSR repository module 36 operates is input to the authentication device ID column 60 of the present embodiment. This identifier is an Internet Protocol (IP) address, a URL (Uniform Resource Locator), a URI (Uniform Resource Identifier), a UUID (Universal Unique Identifier), or some other type of identifier.
[0043]
As shown in FIG. 5, the user interface bar 50 displays a user screen for mediating the BSR service 10 and the user. The user interface bar 50 of this embodiment includes an authentication device ID field 60, a user ID field 62, a snapshot button 64, a session name field 66, a session password field 68, a restore button 70, a session selection field 72, a sign-off button 74, And a BSR repository module field 76. In another aspect, the user interface bar 50 may include information regarding additional functions and operation of the BSR service 10.
[0044]
As shown in FIGS. 2, 3 and 5, when the login information provided by the user is authenticated and access is permitted, the user screen of this embodiment is displayed on the user interface bar 50. Accordingly, the identifier of a legitimate user who has successfully logged in is entered in the user ID column 62. This identifier is, for example, a user name, number, or other identifier that indicates a user who is permitted access.
[0045]
The user can activate the capture component 44 of the BSR device module 34 by selecting the snapshot button 64. As described above, the snapshot can be captured by activating the capture component 44, that is, the current state of the browser of the active session can be captured. The capture component 44 captures a plurality of session parameters regarding the browser state of the active session when the capture of the snapshot is started. In one aspect, the session parameters include at least one document object model (DOM) that constitutes the page being displayed in the browser, at least one script object that constitutes the current page, browser history of the current session, browser cache , And cookies. In another aspect, capture component 44 may capture other types of session parameters that make up the current state of the browser of the active session.
[0046]
As is well known in the art, DOM is a set of application program interfaces (APIs) for HTML and XML documents. In general, DOM defines the logical structure of a document and provides a standard interface for accessing and manipulating documents displayed in a browser. Using the interface defined by DOM, movement within the document structure is performed in addition to construction and modification of the document structure and the elements contained therein.
[0047]
For example, when an HTML page is analyzed using Microsoft® Internet Explorer®, a DOM structure is created. The DOM structure represents the structure of the HTML page displayed on the browser. Each node in the DOM structure represents document information. The document information includes HTML elements, XML elements, attributes, and / or text of HTML pages. For example, in the HTML <a href=http://www.docomolabs-usa.com> DoCoMo </a>, the node of the “a” element, “
Expressed by a total of four nodes, one with a href attribute and two with text content
It is.
[0048]
As is well known in the art, each node of each DOM structure includes a set of attributes that define the display method and operation in the browser. The BSR device module 34 is instructed to incorporate such a DOM structure including content and node attributes into the snapshot. In another aspect, the BSR device module 34 uses a browser with the ability to analyze Compact HTML (cHTML), Wireless Application Protocol (WAP), Wireless Markup Language (WML), and / or other protocols and languages. An importable structure may be created.
[0049]
For example, it is assumed that a page is downloaded to Microsoft® Internet Explorer® and the current state of the active session browser is saved by the BSR service 10. When the user selects the snapshot button 64, the capture component 44 follows all document objects in the top frame of the page displayed in the browser. The capture component 44 captures each node in the top frame and its attributes. Further, the capture component 44 proceeds to the lower frame, and captures the DOM structure node and its attribute.
[0050]
Another session parameter captured by the capture component 44 is a script object. Script objects such as VB Script and JavaScript are included in pages downloaded to the browser. The capture component 44 may capture such a script object as part of a browser snapshot. The script object may be imported together with the DOM document. Accordingly, the capture component 44 captures both the DOM and script objects constituting the page at the same time. Further, the capture component 44 may capture only the script object.
[0051]
For example, when using Microsoft (registered trademark) Internet Explorer (registered trademark), a script variable is defined by a script tag represented as an IDispatch object. The IDispatch object is accessed using a script engine provided in Microsoft® Internet Explorer® during execution. In one aspect, when capturing a snapshot using Microsoft® Internet Explorer®, the IDispatch object corresponding to the script variable is captured serially, but the corresponding script function is not captured. As is well known, the script function of Microsoft (registered trademark) Internet Explorer (registered trademark) is constant. In another aspect, both script functions and script variables may be captured by the capture component 44.
[0052]
Yet another session parameter captured by the capture component 44 is a cookie. In general, a cookie is a well-known device identifier that contains user-specific information. As is well known in the art, cookies are provided to the browser along with the page to be downloaded. The capture component 44 interprets and stores cookies as name and value element pairs during the capture process. Once captured, the cookie is appended to other information captured by the capture component 44. When Microsoft (R) Internet Explorer (R) is used, cookies are added to the DOM structure of each snapshot described above.
[0053]
Yet another session parameter captured by the capture component 44 is the browser history of the active session. The browser history is a set of pages previously displayed by the browser. Accordingly, the capture component 44 captures the page registered in the browser history and adds it to the captured other information. In the embodiment where Microsoft® Internet Explorer® is used, the browser includes an IURHistoryStg interface for searching and setting URL history. In this aspect, when the browser history is captured, the URL history is enumerated, the enumerated URL is acquired, and the acquired URL is added to the DOM structure and the cookie.
[0054]
The user may use the capture component 44 to set a session name and session password for the current state of the captured active session browser. The user inputs a unique session name in the session name column 66 shown in FIG. Alternatively, the user may select a browser state session name that was previously captured. When the session name is not set, the browser state of the captured active session may be identified using the website host name or the like as the default session name.
[0055]
The user may protect the browser snapshot using the session password entered in the session password field 68 shown in FIG. This session password prevents unauthorized access to the captured browser snapshot. In another aspect, the session password entry method includes voice passwords and other mechanisms that prevent unauthorized access to browser snapshots.
[0056]
When the browser snapshot is captured, the browser snapshot is associated with the user who instructs the capture. That is, the snapshot is associated with the user, not the browser and / or device that captured the browser state. When the snapshot is associated with the user, it is associated with the user's account information, username, or other mechanism that customizes the active session to uniquely identify the user that captured the browser snapshot. Browser snapshots associated with each user are stored in a secure location within the network 12.
[0057]
In this embodiment, the browser snapshot is saved by the BSR repository module 36. In this embodiment, the security component 42 establishes a reliable connection between the BSR device module 34 and the BSR repository module 36 and transmits the browser state of the captured active session over the network 12. In another aspect, when the browser state of the captured active session is stored elsewhere in the network 12, the security component 42 establishes a trusted connection with other devices connected to the network, and the browser snaps. Send shots securely.
[0058]
In one aspect, the browser snapshot may be automatically saved after entering the session name and session password. In another aspect, the user may initiate saving the browser snapshot with another command and / or selecting a save location. If the user continues to customize the active session after capturing the browser state of the active session, the capture component 44 may warn of a possible discrepancy with the browser snapshot of the captured active session.
[0059]
As described above, the BSR device module 34 has a restoration component 46. The user uses the user interface bar 50 to instruct reading of the captured browser snapshot. Reading is started using the restore button 70 and the session selection field 72. If the user is successfully authenticated and allowed access, the user selects a browser snapshot that was previously captured and associated with the user. When selecting browser snapshots, pull-down menu lists, indexes, databases, manual entry of session names, or other search mechanisms to identify a list of browser snapshots previously captured and associated with the user are used. It is done. The search mechanism and / or list is provided by the BSR repository module 36, the security component 42, and / or other devices associated with the storage location of the browser snapshot.
[0060]
When the browser state of the previously saved active session is selected, reading is initiated by selecting the restore button 70. In the manner in which the browser state of the active session is stored in the BSR repository module 36, the stored browser snapshot is transmitted via a trusted connection previously established to authenticate the user and allow access when logging in. Downloaded. In this aspect, if the trusted connection has already been broken, the security component 42 will again initiate establishment of the trusted connection. In another aspect where the browser snapshot is stored elsewhere in the network 12, the security component 42 establishes a trusted connection so that the snapshot can be safely read.
[0061]
If a session password is set for the selected browser snapshot, the session password is entered in the session password field 68. The session password is authenticated by the BSR repository module 36, security component 42, or other device associated with the storage location of the browser snapshot. Therefore, even if the user is successfully authenticated and allowed access, the saved browser snapshot cannot be read without the session password.
[0062]
When the restoration component 46 receives the browser snapshot, the restoration component 46 restores the browser snapshot. When restoring a browser snapshot, the browser snapshot is converted to the browser state of the active session. The active session is displayed in the browser in the same state as when the snapshot was taken after restoration. In one aspect, the browser state of the active session is displayed as a result of the restoration of the DOM and script objects captured as described above. In addition, values entered in the page, browser history, browser cache, cookies, and / or other information customized during the active session are also restored.
[0063]
In one aspect, the content is re-downloaded from the site 30 (see FIG. 2) when restoring the browser snapshot. When content is downloaded from the site 30 to the browser, the restore component 46 of the BSR device module 34 uses the browser snapshot to customize the content and restore the browser state of the previously captured active session. In one aspect, the DOM structure of the downloaded content is utilized when restoring a previously captured DOM structure. In this aspect, the restore component 46 restores the values and attributes of each DOM node of the downloaded content according to the previously captured DOM structure. When the DOM structure is restored, the restore component 46 begins restoring cookies, script object variables, and browser history.
[0064]
As shown in FIGS. 2, 3 and 5, the security component 42 includes a sign-off button 74. The security component 42 starts the logoff process, that is, when the signoff button 74 is selected, the access to the BSR service 10 is terminated. When the sign-off button 74 is selected, the security component 42 disconnects the connection between the BSR device module 34 and the browser. Further, the security component 42 instructs the interface component 40 to close the user interface bar 50.
[0065]
In the BSR repository module column 76, the location of the apparatus on which the BSR repository module 36 operates is input. The identifier indicating the location includes an IP address, a physical location name, or any other type of identifier. Therefore, when a plurality of BSR repository modules 36 are available, a desired location can be selected by the BSR repository module column 76.
[0066]
As shown in FIG. 2, the BSR repository module 36 is any application that runs on a device that can communicate with the BSR device module 34 via the network 12 and supports the operation of the BSR service 10. In the present embodiment, the BSR repository module 36 operates on the repository server 18. In another aspect, the BSR repository module 36 may operate on any device connected to the network. In this embodiment, the repository server 18 that operates in cooperation with the BSR repository module 36 may be a commercial server service provider that supports the BSR service 10, or a server for the BSR service 10 that is privately set and managed. A service providing apparatus may be used.
[0067]
FIG. 6 is a block diagram illustrating one embodiment of the BSR repository module 36. The BSR repository module 36 includes a login security component 80, a page server component 82, a snapshot storage component 84, a communication security component 86, and a timing component 88. In another aspect, the number of components that perform the function of the BSR repository module 36 is not limited. In yet another aspect, the BSR repository module 36 may include a code conversion function. This code conversion function allows conversion from HTML to cHTML, cHTML to HTML, and / or other language conversions. The code conversion function enables protocol conversion such as conversion between HTTP and wireless application protocol (WAP). Furthermore, both the language and the protocol may be converted by the code conversion function, such as conversion between HTTP HTML and WAP Wireless Markup Language (WML).
[0068]
The login security component 80 authenticates the user who provided the login information via the login screen of the user interface bar 50 described with reference to FIG. 4 and permits access. The login security component 80 collates the account information with the login information provided via the user interface bar 50. The user creates and saves an account in the BSR repository module 36. When receiving the login information, the login security component 80 accesses the stored account information and authenticates the user. If successfully authenticated, the user is logged in and allowed to access the BSR repository module 36.
[0069]
The page server component 82 allows the BSR repository module 36 to function as a standard server that provides documents to the user interface bar 50 described with reference to FIGS. In addition to the document, the page server component 82 provides other information about the user identified by the login information. For example, a list of saved browser snapshots is provided in the session selection field 72 described above. The list of saved browser snapshots includes snapshots saved using the BSR repository module 36. In another aspect, the page server component 82 may provide information on the page generated and displayed by the interface component 40 (see FIG. 3), other devices in the network 12 (see FIG. 2), and the like.
[0070]
The snapshot storage component 84 stores browser snapshots captured by the BSR device module 34 as described with reference to FIGS. The snapshot storage component 84 receives and stores the browser snapshot sent by the capture component 44 (see FIG. 3). The snapshot storage component 84 directs the storage of the browser snapshot to the storage mechanism associated with the device on which the BSR repository module 36 operates.
[0071]
A typical storage mechanism is a relational database that operates in conjunction with a hard disk, optical disk, or other data storage medium. In another aspect, the snapshot storage component 84 may direct the storage of browser snapshots to a storage mechanism provided by any device in the network 12 (see FIG. 2).
[0072]
As described above, each saved browser snapshot is associated with the user who captured and saved the browser state of the active session. Therefore, the snapshot is stored for each user identification information. Furthermore, accessing the stored snapshot requires authentication and access permission for the user who captured and stored the browser state.
[0073]
Once the user is authenticated and granted access, the stored browser snapshot is accessed by the snapshot storage component 84 based on the desired snapshot identifier. As described with reference to FIG. 5, the stored browser snapshot is specified and read using the session selection field 72 of the user interface bar 50. When the selected browser snapshot is read from the save mechanism and sent to the user's browser, it is restored and displayed as described above. The snapshot storage component 84 authenticates the password set for the selected browser snapshot.
[0074]
As shown in FIGS. 2 and 6, the communication security component 86 enables a reliable connection with the BSR device module 34. For the reliable connection, any of the above-described protocols may be used. Reliable connections include, for example, transmission of login information, transmission of browser status of captured active sessions, or other communications performed between the BSR device module 34 and the BSR repository module 36. Furthermore, the communication security component 86 can be used to protect communication of other confidential information related to the BSR service 10.
[0075]
Timing component 88 manages active sessions with site 30 (see FIG. 2), stored as browser snapshots. As is well known in the art, the site 30 may set a timeout policy for an active session. Accordingly, browser snapshots stored for a long time may not be restored to the active session even when read from the storage location.
[0076]
In an aspect, the timing component 88 periodically accesses the site 30 (eg, Ping) to keep the active session in which the browser state is captured and stored active. This communication includes other communication necessary for resetting the timeout period in addition to a method of simply using a pin for the site 30. The timing component 88 performs communication for resetting the timeout time of the corresponding site 30 based on the time when each browser snapshot is saved.
[0077]
In another aspect, the timing component 88 examines the timeout period for each site 30 where the browser snapshot is stored. The user is then notified by the timing component 88 to read the browser snapshot before the active session timeout period elapses. Further, the timing component 88 may notify the user of a browser snapshot whose timeout time has passed (or is about to pass) if the timeout time has passed (or is about to pass). In yet another aspect, the site 30 timeout policy may be expanded to accommodate active sessions in which browser snapshots are stored. In yet another aspect, the site 30 may stop applying the timeout policy for the active session by receiving notification from the timing component 88 that the browser state of the active session has been captured and saved.
[0078]
FIG. 7 is a flowchart showing the operation of the BSR service 10 shown in FIGS. In explaining this operation example, it is assumed that the user has created an account in advance in order to access the BSR service 10. Further, assume that the user has not yet captured and saved a browser snapshot of the active session.
[0079]
First, in block 102, the first browser 20 is activated on the first device 14. At block 104, the BSR device module 34 associated with the first device 14 and the first browser 20 is activated. In block 106, the user enters a username and password into the login screen of the user interface bar 50. At block 108, the BSR device module 34 initiates establishment of a reliable connection with the repository server 18. At block 110, login information is sent to the repository server 18 via a trusted connection. At block 112, the BSR repository module 36 of the repository server 18 authenticates the user based on the login information and sends an access permission message to the BSR device module 34. In block 114, the user screen is displayed on the user interface bar 50 instead of the login screen. At block 116, the user sends a request over the network 12 and initiates site identification and browsing using the first browser 20.
[0080]
In block 118, the first browser 20 sends a request to the site 30 to customize the active session. After customization, at block 120, the user begins saving the current state of the active session browser. At block 122, the snapshot button 64 of the user interface bar 50 is selected to begin capturing the current state of the active session browser. After capturing the browser state of the active session as a browser snapshot, at block 124 a session name and password for the snapshot are set. At block 126, the user is associated with a browser snapshot.
[0081]
In block 128 of FIG. 8, the BSR device module 34 initiates establishment of a reliable connection between the first device 14 and the repository server 18. Once the connection is established, at block 130 a browser snapshot is sent to the repository server 18 over this trusted connection. At block 132, the browser snapshot is decrypted and stored in association with the corresponding user by the BSR repository module 36. In block 134, the user selects the sign-off button 74 on the user interface bar 50 to finish browsing the site 30 and disconnects the first browser 20 and the BSR repository module 36. At block 136, the BSR repository module 36 disconnects the trusted connection between the first device 14 and the repository server 18. In block 138, the user exits the first browser 20.
[0082]
FIG. 9 is a flowchart showing the operation of the BSR service 10 when the same user activates the second browser 22 on the second device 16. In describing this example operation, it is assumed that the user has already saved a browser snapshot using the first browser 20 running on the first device 14. Although not shown, the operations from the block 102 to the block 114 (see FIG. 7) described above are performed using the second device 16 and the second browser 22 instead of the first device 14 and the first browser 20. Done again.
[0083]
In block 202 of FIG. 9, a list containing browser snapshots saved associated with the logged-in user is downloaded over the trusted connection and presented to the user interface bar 50. At block 204, the user determines whether to retrieve the saved browser snapshot. If the user does not retrieve the saved browser snapshot, at block 206, the user uses the second browser 22 to identify the site 30 on the network 12. In block 208, the user sends a request over the network 12 to begin browsing the site 30.
[0084]
If the user decides to read the saved browser snapshot at block 204, the saved browser snapshot is selected in the session name field 66 at block 210 and the password set for the browser snapshot is selected. Is entered in the session password field 68. At block 212, the restore button 70 on the user interface bar 50 is selected and the restoration process is initiated. Once the password is authenticated, at block 214, the selected browser snapshot is downloaded from the repository server 18 to the second device 16 via a trusted connection.
[0085]
At block 216, the BSR device module 34 restores the saved browser snapshot and resumes the active session using the second browser 22. At block 208, the second browser 22 sends a request over the network 12 and begins browsing the site 30 where the active session has been restored.
[0086]
The operation of the second browser 22 for customizing and saving the browser state of the active session is the same as the operation described with reference to FIGS. In another aspect, the user may browse the site optionally using different devices and different browsers, and optionally customize the active session to save the browser state. Further, the user may optionally use a different device and a different browser to restore the current state of the saved browser and continue the active session.
[0087]
According to the embodiment of the BSR service 10 described above, a user can switch a device during an active session without terminating the session and re-customizing the session from the beginning with another device. In addition, the user can save and continue any active session at any time on any device, so that multiple customized active sessions can be managed simultaneously. When saving an active session using the BSR service 10, it is only necessary to save the browser state of the active session as a snapshot. The snapshot is securely saved and later safely retrieved and restored to the active session customized by the user. The user can also save and retrieve browser snapshots using any browser and / or device. Thus, according to the BSR service 10, the browser snapshot is not associated with a browser or device, but with a user of the BSR service 10.
[0088]
In another aspect, the BSR service is extended to a browser session mobility (BSM) system. The BSM system supports mobility between different platforms in the runtime state of an active session of a multi-platform network application. As is well known in the art, a session is an instance of a user who uses a network application such as a web application. A platform is a type of device having a different software and / or hardware environment, such as a pocket personal computer, a mobile phone, and a desktop computer. As described above, according to the BSR service, the browser state is associated with the user rather than with a specific device, so the user can save and restore multiple browser snapshots of the active session. In BSM systems, this association is further extended to allow seamless movement between different platforms on which multi-platform network applications run.
[0089]
BSM systems support runtime state mobility between different platforms. Different platforms have different limitations and capabilities related to displays, networking, user interfaces, etc. According to the BSM system, it is possible to capture not only the browser state as in the BSR service but also the server state of the active session. State data and session data generated during the browser state and server state of the active session are collectively referred to as runtime state. In a BSM system, the term “state” or “runtime state” refers to a stored interaction between a user and a network application. The runtime state includes a browser state such as form data, script variables, and cookies, and a server state that supports the browser state. The server status differs from platform to platform, such as JSP (Java Server Pages) and CGI (Computer Generated Image) status depending on the platform.
[0090]
According to the BSM system, a platform dependent runtime state generated using a platform dependent version of a multiplatform network application is converted to another platform dependent runtime state in another platform dependent version of the multiplatform network application. be able to. Thus, in a BSM system, by not associating a runtime state with a particular platform, the runtime state of a multi-platform network application running on one particular platform is transferred to another platform.
[0091]
The concept of BSR service snapshot described above has been modified and extended, and in the BSM system, platform independent runtime state data is included. Thus, according to the BSM system, the snapshot is restored to the active session on any platform. The BSM system operates on any platform-dependent version of tasks, runtime states, and data structures of a multi-platform network application. According to the BSM system, in a structure of an arbitrary multi-platform network application, a snapshot of an active session can be captured, converted for each platform, and restored.
[0092]
FIG. 10 is a block diagram showing a BSM system 300 operating via the network 12 described above. As shown in the figure, the BSM system 300 includes at least one application server 302, a communication device shown as first and second devices 304 and 306, and a repository server 308. In another aspect, the BSM system 300 may comprise any number of application servers, communication devices, repository servers, and other network enabled devices.
[0093]
The application server 302 is any network compatible device that can provide applications to devices on the network 12, such as first and second devices 304, 306. Application server 302 includes at least one multi-platform network application such as a processor, memory, multi-platform web application, server state module 312, and platform adapter module 314. The application server 302 also has an operating system and programs in its memory, and has the same capability as a normal network server computer. In a known mechanism for providing a network application via a network, an active session with the application server 302 is started by a request such as an HTTP request.
[0094]
This request is transmitted from the target platform such as the first and second devices 304 and 306 to the application server 302 via the network 12. Application server 302 is a platform-dependent version of a multi-platform network application launched for a platform type (eg, desktop personal computer, laptop computer, personal digital assistant (PDA), mobile phone, etc.) and target platform Is identified. Next, the application server 302 generates a server state using the server state module 312. This server state operates with a platform dependent network application corresponding to the target platform. A platform-dependent network application is a platform-dependent version of a multi-platform network application that can establish and maintain an active session with a browser on the target platform.
[0095]
11, 12, and 13 are diagrams showing examples of browser displays with different platforms. Each platform is supported by a server state that operates with each platform-dependent version of the network application. Each platform-dependent version is a multi-platform network application (in this example, a bookstore application) with a different version. Each display example shown in FIGS. 11, 12, and 13 is a display of a book store application dependent on each platform optimized for capabilities such as the display screen size, user interface device, and network connection type of each platform. It is. In another aspect, the multi-platform network application may correspond to any number of platforms.
[0096]
The first browser display example 324 shown in FIG. 11 is generated by a first platform dependent version of the bookstore application. The version depending on the first platform is used for an active session by a platform having a relatively large display screen such as a desktop or laptop computer and a relatively stable network connection. Because the display screen is relatively large, the platform can display a book catalog task 326, a shopping cart task 328, and a checkout task 330 in one screen. Due to the high-speed connection to the network 12 and various user interface devices, scrolling, mouse clicks, keyboard data input, etc. are used for operations during active sessions.
[0097]
The second browser display example 334 shown in FIG. 12 is intended for a platform with a relatively fast connection to the network 12 such as a pocket PC or PDA and a small display screen. The active session with the second browser display example 334 is supported by a second platform dependent version of the bookstore application corresponding to the platform described above. In versions that depend on the second platform, a book catalog task 326, a shopping cart task 328, and a checkout task 330 are placed on separate pages of the browser for ease of viewing on a small display screen. Requests for individual pages, such as HTTP requests, synchronize the browser state with the server state operating with the second platform dependent version of the network application.
[0098]
Browser user interface devices vary greatly between each platform dependent version of a network application due to the different user interface devices available. For example, in the first browser display example 324, all tasks 326, 328, and 330 are displayed by the user interface device. In the second browser display example 334, since the display screen is small, only a part of the tasks 326, 328, and 330 is displayed, and as a result, a scroll bar is displayed. Other examples of user interface device changes between different platforms include a change from a text field box to a pull-down menu and a change from mouse operation to touch screen operation.
[0099]
A third browser display example 340 shown in FIG. 13 is intended for a device having a relatively small display screen and a relatively slow connection to the network 12, such as a pocket PC having a poor network connection. The browser state including the third browser display example 340 is supported by the server state operating with a third platform dependent version. In the third browser display example 340, a book catalog task 326 (not shown), a shopping cart task 328, and a checkout task 330 (not shown) are placed on separate pages with scroll bars. The third platform dependent version provides an alternative user interface device in the browser to make it easier to see the active session with the target device.
[0100]
For example, in the shopping cart task 328 of the third browser display example 340, another title is not displayed in a list as in the shopping cart task 328 of the first and second browser displays, but is displayed by a pull-down menu. The Furthermore, operations during an active session may be performed by a client-side script on the target device. For example, “quantity” and “price” are read based on the title selected in the pull-down menu 344. Accordingly, since requests such as HTTP requests generated from the browser state and transmitted to the server state via the network are reduced, network traffic can be minimized.
[0101]
Because the display methods and functions are very different, different task models are implicitly used for each display. The number and manner in which data is displayed based on a platform-dependent version of a network application that works with the server state, and variables containing form data are sent to the server-side runtime state varies from platform to platform. Thus, server-side runtime state data is very different between different platform dependent versions of a multi-platform network application.
[0102]
The platform adapter module 314 shown in FIG. 10 operates in conjunction with the server state module 312. The platform adapter module 314 has the ability to capture a platform dependent (PS) snapshot of the server side runtime state of the active session. A server-side PS snapshot of an active session includes platform dependent runtime state data related to ongoing interactions between the browser and application server 302 during the active session. The amount, type, and details of platform-dependent runtime state data that is captured by the platform adapter module 314 into the server-side PS snapshot is specified by the developer of the multi-platform network application. The platform dependent runtime state captured in the server-side PS snapshot may include a link to another database, cache data associated with the active session, open files, input / output, JSP or CGI variables, etc. The server-side PS snapshot is sent over the network 12 by the platform adapter module 314 to the first and second devices 304, 306 and / or the repository server 308.
[0103]
The platform adapter module 314 also has the ability to convert server-side PS snapshots to server-side platform-independent runtime states. This conversion is performed using a mapping and selectively converted from server-side platform dependent runtime state data to server-side platform independent runtime state data. Similarly, the platform adapter module 314 converts platform-independent runtime state data into platform-dependent runtime state.
[0104]
The platform adapter module 314 performs mapping using the mapping description file. In the mapping description file, the application developer describes the conversion between the server-side platform-dependent runtime state and the server-side platform-independent runtime state included in the server-side PS snapshot.
[0105]
The server-side platform independent runtime state is included in the platform independent (PI) snapshot. The platform adapter module 314 sends the PI snapshot and mapping description file to the repository server 308 and / or other devices such as the first and second devices 304, 306 over the network 12. Similar to the embodiment described above, communications over the network 12 are encrypted.
[0106]
Each of the first and second devices 304 and 306 includes a BSM module 316. Similar to the first and second devices 14 and 16 shown in FIG. 1, the BSM module 316 cooperates with the first and second browsers 318 and 320 in the first and second devices 304 and 306, respectively. Works. The BSM module 316 is a browser plug-in operating on the first and second devices 304 and 306, an independent module, or the like.
[0107]
FIG. 14 is a block diagram illustrating one embodiment of a BSM module 316. The BSM module 316 includes a conversion module 350 and a status handler module 352 in addition to the interface component 40, security component 42, capture component 44, and restoration component 46 described above. As described above, the browser side platform dependent (PS) snapshot captured by the capture component 44 includes the browser side platform dependent runtime state of the active session. In another aspect, the BSM module 316 may comprise any number of modules or components.
[0108]
The conversion module 350 operates in conjunction with the capture component 44 to selectively convert the browser-side runtime state (browser-side PS snapshot) of the platform-dependent version of the network application. Similar to the platform adapter module 314, the browser-side PS snapshot is converted to a browser-side platform-independent runtime state using the mapping description file. Specifically, browser-side platform-dependent runtime state data included in the browser-side PS snapshot is selectively converted into platform-independent runtime state data. The conversion module 350 also operates in conjunction with the restore component 46 to selectively convert the browser side platform independent runtime state into a browser side PS snapshot that includes browser side platform dependent runtime state data.
[0109]
The conversion module 350 selectively converts the state data using the mapping description file. Similar to the platform adapter module 314, the mapping description file contains information about selective conversion between browser-side platform-dependent runtime state data and browser-side platform-independent runtime state data included in the browser-side PS snapshot by the application developer. Described.
[0110]
When the browser side PS snapshot is converted, the state handler module 352 receives the browser side platform independent runtime state from the conversion module 350. In addition, the state handler module 352 receives a PI snapshot including a server-side platform-independent runtime state from the platform adapter module 314. The server side platform independent runtime state is combined with the browser side platform independent runtime state in the PI snapshot. A PI snapshot containing the platform independent runtime state of the active session is sent to the repository server 308.
[0111]
Further, the state handler module 352 receives the server-side PS snapshot from the platform adapter module 314. The server-side PS snapshot is converted by the conversion module 350 using the mapping description file. This conversion converts the server side platform dependent runtime state into a server side platform independent runtime state. The server side platform independent runtime state is combined with the browser side platform independent runtime state by the state handler module 352.
[0112]
In yet another aspect, the state handler module 352 receives a server-side PS snapshot that includes a server-side platform dependent runtime state. The state handler module 352 combines the server-side PS snapshot and the browser-side PS snapshot that includes the browser-side platform dependent runtime state. The server side and browser side PS snapshots are combined into a platform dependent runtime state snapshot. The platform dependent runtime state snapshot is sent to the repository server 308 via the network 12 by the state handler module 352.
[0113]
When a previously saved PI snapshot is read from storage, the state handler module 352 receives the PI snapshot and extracts the browser-side platform independent runtime state from the PI snapshot. The browser side platform independent runtime state is provided to the conversion module 350, which converts the browser side platform independent runtime state into a browser side PS snapshot. After conversion, the browser side platform dependent runtime state is instantiated as an active session.
[0114]
As shown in FIG. 10, the repository server 308 includes a BSM repository module 322. Similar to the repository server 18 shown in FIGS. 1 and 6, the repository server 308 operates in cooperation with the first and second devices 304 and 306 and the application server 302 via the network 12. Further, the repository server 308 may communicate only with the first and second devices 304 and 306.
[0115]
FIG. 15 is a block diagram illustrating one embodiment of a BSM repository module 322. The BSM repository module 322 includes a state handler module 354 in addition to the above-described login security component 80, page server component 82, snapshot storage component 84, and communication security component 86 shown in FIG. The state handler module 354 receives browser-side PS snapshots and server-side PS snapshots from either the first and second devices 304, 306 and / or the application server 302, translates and combines them into a PI snapshot. Is generated. In another aspect, the BSM repository module 322 may comprise any number of modules.
[0116]
In addition, the state handler module 354 receives a platform-dependent runtime state snapshot including the browser-side platform-dependent runtime state and the server-side platform-dependent runtime state and converts it into a PI snapshot. In another aspect, repository server 308 may not include state handler module 354 if the PI snapshot is generated by platform adapter module 314 or state handler module 352 of application server 302. In this case, the PI snapshot is sent to the repository server 308 and stored by the snapshot storage component 84.
[0117]
Note that the BSM repository module 322 does not include the timing component 88 shown in FIG. In the BSM system 300, both the browser side and server side runtime state of the active session are captured in the snapshot, eliminating the need for the timing component 88. Therefore, time management for maintaining an active session with the application server 302 becomes unnecessary.
[0118]
A user requests activation of a multi-platform network application using a communication device such as the first device 304 and starts an active session. A platform dependent version of the multi-platform network application is used with the server state to establish and maintain an active session with a first browser 318 running on the first device 304. During an active session, the user of the first device 304 uses the BSM system 300 to start capturing an active session.
[0119]
The platform dependent runtime state of the active session is captured as a PS snapshot. Specifically, the browser current state of the first browser 318 operating on the first device 304 and the server current state of the application server 302 are captured. The PS snapshot containing the browser current state and the PS snapshot containing the server current state are combined and converted to a PI snapshot containing the platform independent runtime state of the active session. The PI snapshot is stored in the repository server 308.
[0120]
The PI snapshot is read later using a target device such as the second device 306. The PI snapshot is converted into a PS snapshot based on the hardware and / or software capabilities (platform) of the second device 306. The server-side PS snapshot includes server-side platform-dependent runtime state data, and the browser-side PS snapshot includes browser-side platform-dependent runtime state data. The platform dependent runtime state is instantiated as an active session and the previously established active session is resumed. To resume the active session, the application server 302 and the second browser 320 operating on the second device 306 are used. Thus, active sessions can be restored on any platform.
[0121]
The BSM system 300 responds with differences to platform-dependent runtime state differences. This conversion is based on a selective mapping between platform-dependent and platform-independent runtime states. The BSM system 300 coordinates differences between platform dependent runtime states through this mapping. The BSM system 300 facilitates mapping of components from one platform-dependent display to another platform-dependent display, thus enabling seamless conversion between different platforms.
[0122]
In the BSM system 300, differences in page layout, user interface devices, state maintenance, etc., and other platform dependent differences are addressed by conversion. The page layout shows how tasks are subdivided or integrated on pages during an active session. Tasks refer to various functions during an active session, such as search, purchase, selection, etc., which are commanded by the user. The user interface device refers to a device operated by a user when inputting runtime state data such as a keypad, a keyboard, a touch screen, and a mouse or performing an operation during an active session. State maintenance indicates how the platform dependent application maintains the state of database entries, cookies, script variables, hidden form fields, etc. between pages. State maintenance also shows how state is synchronized between browser state and server state.
[0123]
When mapping PS snapshots, pages and data are selectively mapped. Pages are mapped assuming that each page corresponds to a platform independent task. As described above, the data includes form control, cookies, JSP variables, script variables, and the like. In one example mapping method, a unique platform independent name is selectively assigned to the data when mapping PS snapshot data. The platform-dependent data is mapped to the assigned unique platform-independent name using the mapping description file, and converted from the platform-dependent data to the platform-independent data. Similarly, when converting platform-independent data into a PS snapshot of a specific platform, the mapping description file corresponding to the specific platform is used to convert the platform-dependent data of the PS snapshot from a unique platform-independent name. Is converted to
[0124]
One example of a mapping mechanism is a type that uses HTML notes and two simple XML documents. To illustrate this mapping mechanism, an example of PI snapshot save and restore operations by the BSM module 316 is taken. The BSM module 316 identifies the application as a multiplatform application based on the multiplatform ID. Examples of multi-platform IDs include <link rel = "bsm-map" href = "my-platform.xml">
There is one line of the header of the HTML page. In this case, the link element is part of the HTML standard and is used to specify the relationship between two documents. In this case, the mapping is applied to the page currently being viewed using the browser, and the mapping is described in the mapping description file (in this case, "my-platform.xml").
Is specified.
[0125]
The mapping description file is used by the BSM module 316 as instructions for converting between platform dependent and platform independent runtime states in the save and restore process. The DTD (Document Type Definition) of this type of mapping description file specifies the following structure.
The map element includes a URL of a master mapping file to be described later and one or more page elements.
The page element maps from the URL of the page to one or more irregular and conceptual tasks of the network application. A task contains zero or more control elements.
The control element performs mapping from a platform-dependent user interface device name to a unique platform-independent name and includes zero or more value elements.
The value element (session data and / or state data) performs mapping from platform-dependent values such as user interface devices to platform-independent values.
[0126]
The mapping description file is selectively written by the application developer for each platform dependent version of the network application. For example, the mapping description file includes another page element of a version dependent on the second platform from a range of values (data) included in a control element in a page element (task) having a version dependent on the first platform. It is described so as to be explicitly mapped to the range of values (data) included in another control element in (task). The mapping description file gives the application developer the flexibility to selectively map only to control elements that have different name and value ranges between applications that depend on different platforms. If the name and value ranges are the same between applications that depend on different platforms, for example, mapping to a unique platform-independent name need not be specified. When the name and value ranges are all the same between different platform-dependent versions, the application developer need only specify the mapping of the page element (task) in the mapping description file.
[0127]
In the following example, three pages are mapped to a task, and the control element (in this example, assumes a <select> or <input type = "radio"> element group) with a unique platform-independent name and value range It is mapped.
<Map master = “master.xml”>
<Page url = "http: //localhost/foo.html" task = "foo">
<Control from = "ab" to = "alphabravo">
<Value from = “a” to = “alpha”>
<Value from = "b" to = "bravo">
<Value from = "c" to = "charlie">
</ Control>
</ Page>
<Page url = "http: //localhost/bar.html" task = "bar"/>
<Page url = "http: //localhost/baz.html" task = "baz"/>
</ Map>
[0128]
The BSM system 300 uses a master mapping file created by an application developer for each multi-platform network application. The master mapping file describes the correspondence between the platform and the mapping description file. In the BSM system 300, a master mapping file is used when restoring a PI snapshot. The master mapping file specifies the mapping description file used in the conversion from the PI snapshot to the browser-side PS snapshot and the server-side PS snapshot or vice versa. Similarly, the PS snapshot identifies the page that is loaded when displaying the platform dependent version.
[0129]
In general, a multi-platform network application selects a display based on an activation request. The activation request is, for example, a user-agent string transmitted with an HTTP request. Similarly, in the BSM system 300, a display corresponding to the moved runtime state is selected. The display is selected based on parameters associated with conditions during the active session, default display, or other runtime state. In an aspect, a method similar to that used when a multi-platform network application selects a display is used in the BSM system 300. The following is an example of DTD.
-The master element contains one or more map elements.
The map element includes a regular expression corresponding to the user-agent string and a URL corresponding to the mapping description file associated with the user-agent string. If multiple regular expressions correspond to the user-agent string, the first regular expression in the mapping description file is used.
[0130]
The following is an example of a master mapping file.
<Master>
<Map useragent = "windows" url = "pc-map.xml"/>
<Map useragent = "pocket" url = "ppc-map.xml"/>
<Map useragent = "*" url = "default-map.xml"/>
</ Master>
[0131]
In this master mapping file, all user-agent strings containing "windows" are pc-map.xml description files, user-agent strings containing "pocket" are ppc-map.xml description files, and other user The -agent string is associated with the default-map.xml description file.
[0132]
The mapping and conversion described above is performed in the BSM module 316, the platform adapter module 314, and / or the BSM repository module 322. In some embodiments, the mapping is performed using a code such as XML. FIG. 16 is an example of an application description and a mapping description file for mapping from the server-side PS snapshot to the PI snapshot of the bookstore application described above.
[0133]
It will be apparent to those skilled in the art that the above example is not a complete example of mapping, but an example of mapping in the BSM system 300. Generally, in the application description and mapping description file, session data and state data are described as a pair of name attribute and type attribute.
[0134]
In the BSM system 300, the platform-dependent display is modeled based on the concept of finite state machine (FSM). In the BSM system 300, the structure of the platform dependent display of the platform dependent version of the multi-platform network application is represented using the concept of FSM. The above mapping is used with the FSM model to selectively translate runtime states that move between different platforms.
[0135]
In the BSM system 300, the FSM model is a directed graph in which each side connecting one vertex to the next vertex is an ordered pair of vertices. The structure of each platform-dependent representation of the platform-dependent version of a multi-platform network application is modeled using a directed graph.
[0136]
The directed graph of the FSM model includes vertices indicating states and edges indicating transitions between the states. Here, the state in the FSM model indicates a task of platform dependent display. Transitions between states in the FSM model refer to movement during platform-dependent display of active sessions. The movement includes a user operation during an active session such as sending a form in a browser or jumping to a link destination. In order to save and restore the active session runtime state, transitions in the FSM model may not be explicitly modeled. Instead, it is presumed to be implied by the logic of the platform dependent version of the network application.
[0137]
A data field is associated with each state in the FSM model. The data field corresponds to the form control presented to the user in the platform dependent display. In addition, status data and session data of the platform dependent display of the active session are included in the data field. The state data is session-specific data representing the task data of the browser state and / or the server state. The contents of the “shopping cart” and session data such as cookies remain unchanged between states during an active session.
[0138]
By using the FSM model, the entire structure of the display associated with each active session of the platform dependent version of the network application is represented. The browser-side and server-side platform-dependent runtime states of the active session are also included in the platform-dependent display represented using the FSM model.
[0139]
For example, in FIGS. 11, 12, and 13, which are platform-dependent display examples, different FSM models are used to represent the platform-dependent display structure of a multi-platform network application. The state in the FSM model represents a page specifically targeted to a particular platform that is displayed in a browser during an active session. For example, in the second display example shown in FIG. 12, three states 326, 328, and 330 are displayed. Data fields in the FSM model include state data and session data (eg, browser-side runtime state) generated by the user during an active session. For example, check-out information such as a name that has not been transmitted is included in the browser-side runtime state as state data of platform-dependent display.
[0140]
Similarly, the server-side platform-dependent display is also expressed using the FSM model. Data fields in the server-side FSM model also represent state data and session data (eg, server-side runtime state). For example, the database to which the book catalog requested by the user is accessed is part of the state data.
[0141]
Mapping using a mapping description file allows the platform-dependent runtime states and data fields represented by each platform-dependent FSM model to be selectively converted between platform-independent and platform-dependent runtime states. Become. According to the mapping, the runtime state is not associated with the device operated by the user. Further, the mapping models user interface device and page layout differences between different platform dependent versions of a multi-platform network application. For example, the data field represents an operating means that is selectively presented to the user at each task during an active session based on a platform-dependent version of the multi-platform network application. The operating means may be presented based on the logic of each platform dependent network application.
[0142]
The BSM system 300 specifies in which state (eg, display) of the platform dependent version of the network application the user saved the PI snapshot. Thus, the state ID at the time the user saved the PI snapshot is transferred along with the runtime state between the platform dependent versions of the network application. When the PI snapshot is read and restored, the active session is restored to the same state (including the runtime state) when the PI snapshot is saved.
[0143]
The state at the time the user saved the PI snapshot is identified by the following relatively easy two-step process. First, the state in the FSM model representing the display structure is examined, and a partially input data field in the display page is specified. When some or some input data fields do not exist, or a plurality of data fields exist, the default state specified by the application developer is specified as the state at the time when the user saved the PI snapshot.
[0144]
When the PI snapshot is restored, the state at the time when the user saved the PI snapshot is similarly specified. If there is a state in which data is entered in only a part of the data field among the states in the display-dependent FSM model depending on the first platform, the state is the state at the time when the user saved the PI snapshot. Identified as a state. When the active session is re-instantiated, the display state depending on the second platform corresponding to the specified state is specified, and the display associated with the state is performed. If there are no or some data fields that have been partially entered, the default mapping is used to identify the state.
[0145]
FIG. 17 is a flowchart showing an operation example of the BSM system 300 shown in FIG. Here, a PI snapshot representing the active session is stored. First, at block 402, the user launches the first browser 318 on the first device 304. At block 404, the user logs on to the repository server 308 using the first device 304. At block 406, the user sends an active session start request to the application server 302 using the first device 304.
[0146]
In block 408, the application server 302 identifies the platform type of the first device 304. At block 410, the application server 302 launches a platform-dependent version of the multi-platform network application that corresponds to the platform of the first device 304. At block 412, the first browser 318 of the first device 304 displays a screen. At block 414, browser state and server state changes are made when a user performs an operation during an active session. At block 416, the user initiates a snapshot capture of the active session using the first device 304.
[0147]
At block 418, the BSM module 316 of the first device 304 sends a save request to the platform adapter module 314 via the network 12. This save request is a resource locator such as a URL, and is attached with at least one encrypted variable for specifying the platform of the first device 304. At block 420, the platform adapter module 314 captures the server-side runtime state (state data and session data) of the active session as a server-side PS snapshot. In block 422, the mapping description file corresponding to the platform specified in the save request is specified using the master mapping file. At block 424, the server-side PS snapshot is converted to a PI snapshot using the identified mapping description file.
[0148]
In block 426 of FIG. 18, the platform adapter module 314 sends a PI snapshot to the first device 304 in response to the save request. At block 428, the identified mapping description file is further transmitted to the first device 304 in response to the save request. At block 430, the BSM module 316 receives a PI snapshot that includes a server-side platform independent runtime state. At block 432, the BSM module 316 captures the browser side platform dependent runtime state as a browser side PS snapshot. At block 434, the BSM module 316 selectively converts the browser side PS snapshot into a browser side platform independent runtime state using the mapping description file. At block 436, the browser side platform independent runtime state is combined with the server side platform independent runtime state of the PI snapshot received from the application server 302. At block 438, the PI snapshot including the platform independent runtime state of the active session is serialized and sent to the repository server 308. At block 440, the repository server 308 stores the PI snapshot.
[0149]
In another aspect, the browser-side runtime state and the server-side runtime state may be converted at either the application server 302 or the first device 304. In yet another aspect, the repository server 308 may selectively convert PS snapshots transmitted from the application server 302 and the first device 304 over the network 12 using a mapping description file. In yet another aspect, the first device 304 sends the server-side PS snapshot and browser-side PS snapshot sent from the application server 302 to the repository server 308, and the repository server 308 sends the PS snapshot to the PI snapshot. May be converted to As is clear from the above, conversion to a PI snapshot using a mapping description file is possible at an arbitrary location in the BSM system 300.
[0150]
FIG. 19 is a flowchart showing an operation example of the BSM system 300 shown in FIG. Here, the PI snapshot saved using the first device 304 as shown in FIGS. 17 and 18 is restored to the active session. First, in block 502, a browser is activated on a communication device such as the second device 306. Here, for the sake of explanation, it is assumed that the platform of the second device 306 is different from that of the first device 304. At block 504, the user logs on to the repository server 308 using the second device 306. At block 506, the user decides to restore the previously saved active session PI snapshot and sends a restore request over the network 12 to the repository server 308. At block 508, the repository server 308 sends the saved PI snapshot to the second device 306 over the network 12 in response to the restore request.
[0151]
At block 510, the platform ID of the second device 306 is included in the session resume request. This session resumption request includes at least one encrypted variable for specifying a display state displayed on the second device 306 and a resource locator such as a URL. In block 512, the second device 306 sends the saved PI snapshot to the application server 302 in response to a session resume request. At block 514, the platform adapter module 314 accesses the master mapping file to identify the mapping description file corresponding to the platform of the second device 306. At block 516, the platform adapter module 314 converts the server-side runtime state contained in the PI snapshot into a server-side PS snapshot using the identified mapping description file. At block 518, the platform adapter module 314 re-instantiates the server-side runtime state included in the server-side PS snapshot. In block 520, the platform adapter module 314 sends a page of the restored active session corresponding to the display state identified in the session resume request in response to the session resume request.
[0152]
At block 522, the platform adapter module 314 also sends the identified mapping description file to the second device 306 in response to the session resume request. At block 524, the BSM module 316 of the second device 306 converts the PI snapshot into a browser-side PS snapshot using the mapping description file. In block 526, the second browser 320 of the second device 306 displays the page sent by the application server 302. At block 528, the BSM module 316 reinstantiates the browser-side runtime state so that data is entered into the form in the display page and script variables, cookies, etc. are reinitialized. Once the browser-side PS snapshot is fully restored, at block 530, the user uses the second browser 320 of the second device 306 to resume the active session from the time the snapshot was captured. In another aspect, other devices in the BSM system 300 may convert a PI snapshot to a PS snapshot using a mapping description file.
[0153]
In another aspect, the BSM system 300 may capture only the browser-side runtime state as a snapshot, similar to the BSR service 10 described above. However, the BSM system 300 further comprises the ability to map runtime state conversions between browser-side PS snapshots and PI snapshots. Thus, the BSM system 300 seamlessly translates different page layouts, user interface devices, and application states between platform-dependent versions of multi-platform network applications. The flexible framework provided by the BSM system 300 allows an application developer to selectively specify the mapping of browser-side runtime states between browsers running on different platforms.
[0154]
In this case, the application state maintained on the server side is not captured, converted, and stored. Therefore, when the server ends the active session, the PI snapshot stored using the BSM system 300 becomes invalid. To avoid invalidation of stored active sessions, repository server 308 also includes a timing component 88 shown in FIG. As described with reference to FIG. 6, the timing component 88 begins managing active sessions once the PI snapshot is saved. Alternatively, once the PI snapshot is saved, the time until the active session times out is extended or the timeout is stopped.
[0155]
Since the server-side runtime state is not captured, it is possible to avoid leakage of information inside the application server 302 when the provider of the BSM system 300 is not the provider of the application server 302. Specifically, the application server 302 need not be configured to be able to change variables such as arbitrary variables of the CGI script so as to adapt to all general programming languages and server environments. Furthermore, it is possible to avoid a security risk that is expected when information inside the application server 302 leaks outside. In addition, if only the browser-side runtime state is mapped, the multi-platform network application can be roamed without requiring much effort by the application developer.
[0156]
A program for executing the above-described processing by the components included in the first and second devices 304 and 306 may be installed in the first and second devices 304 and 306 as an application program. Further, various recording media such as a CD-ROM in which such a program is recorded may be provided to the user, or may be provided to the user via a communication line such as the Internet.
[0157]
【The invention's effect】
According to the above-described BSM system 300, it is possible to capture, save, and restore active sessions on any platform and any browser. When the runtime state of the platform dependent version of the multi-platform network application is captured, it is converted into a platform independent runtime state and saved. Similarly, when the platform independent runtime state is read, it is converted to a different platform dependent runtime state and used on the platform corresponding to the different platform dependent version of the multi-platform network application. Therefore, the runtime state and the platform are not associated with each other. Furthermore, since the runtime state includes both the server-side and browser-side runtime state of the active session, the active session is saved indefinitely, and the active session state data and session data are restored to a complete state. Even if only the browser-side runtime state is saved, the runtime state is not associated with a particular platform.
[0158]
While the invention has been described with reference to specific embodiments, various modifications can be made to these embodiments without departing from the spirit and scope of the invention as set forth in the claims. It is clear that there is. Accordingly, the specification and drawings are illustrative and not restrictive.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a BSR service.
FIG. 2 is a detailed block diagram illustrating the BSR service shown in FIG.
FIG. 3 is a detailed block diagram showing the BSR device module shown in FIG. 2;
FIG. 4 is a diagram showing an example of a user interface bar activated by the BSR device module shown in FIG. 3;
FIG. 5 is a view showing another example of a user interface bar activated by the BSR device module shown in FIG. 3;
6 is a detailed block diagram illustrating the BSR repository module shown in FIG.
FIG. 7 is a flowchart showing an operation example of a BSR service.
FIG. 8 is a flowchart showing a continuation of an operation example of the BSR service shown in FIG. 7;
FIG. 9 is a flowchart illustrating an operation example of a BSR service.
FIG. 10 is a block diagram illustrating a browser session mobility (BSM) system.
11 is a display example on a browser / platform in the BSM system shown in FIG.
12 is a second display example on the browser / platform in the BSM system shown in FIG.
13 is a third display example on the browser / platform in the BSM system shown in FIG.
FIG. 14 is a detailed block diagram showing a BSM module.
FIG. 15 is a detailed block diagram illustrating a BSM repository module.
FIG. 16 is a diagram illustrating an example of an application description and a mapping description file.
FIG. 17 is a flowchart showing an example of an active session capture, conversion, and storage operation by the BSM system shown in FIG. 10;
FIG. 18 is a flowchart showing a continuation of the operation example of the BSM system shown in FIG.
FIG. 19 is a flowchart showing an example of an operation for restoring an active session on a different platform according to the BSM system shown in FIG. 10;
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 10 ... Browser state repository (BSR) service, 12 ... Network, 304, 1st apparatus, 16, 306 ... 2nd apparatus, 18, 308 ... Repository server, 20, 318 ... 1st browser, 22, 320 ... second browser, 30 ... site, 34 ... BSR device module, 36 ... BSR repository module, 40 ... interface component, 42 ... security component, 44 ... import component, 46 ... restore component, 52 ... user ID field, 54 ... Password field, 56 ... Sign-on button, 58 ... Reset button, 60 ... Authentication device ID field, 62 ... User ID field, 64 ... Snapshot button, 66 ... Session name field, 68 ... Session password field, 70 ... Restore button 72 ... Session selection field 74 ... Sign-off button, 76 ... BSR repository module field, 80 ... Login security component, 82 ... Page server component, 84 ... Snapshot storage component, 86 ... Communication security component, 88 ... Timing component, 300 ... BSM system, 302 ... Application server, 312 ... Server status module, 314 ... Platform adapter module, 316 ... BSM module, 322 ... BSM repository module, 324 ... First browser display example, 326 ... Book catalog task, 328 ... Shopping cart task, 330 ... Check Out task, 334 ... second browser display example, 340 ... third browser display example, 344 ... pull-down menu, 350 ... conversion module Le, 352, 354 ... state handler module.

Claims

A first session establishing step in which a first communication device establishes a session with an application server;
A first storing step in which the first communication device stores browser state information during the session;
A transmitting step in which the first communication device transmits status information of the browser to a repository server;
A second storage step in which the repository server stores state information of the browser;
A receiving step in which a second communication device receives status information of the browser from the repository server;
A second session establishing step in which the second communication device establishes a session with the application server using the browser state information;
A communication method comprising:
The first storing step includes
The first communication device storing browser state information depending on the platform of the first communication device;
The first communication device comprising: converting browser status information dependent on the platform of the first communication device into platform status information independent of the platform;
The second session establishment step includes:
The second communication device converts the browser state information independent of the platform into browser state information dependent on the platform of the second communication device;
The second communication device, the communication method you; and a step of establishing a session with the application server using the state information of the browser that is dependent on the second communication device platform.

A first session establishing step in which a first communication device establishes a session with an application server;
A first storing step in which the first communication device stores browser state information during the session;
A transmitting step in which the first communication device transmits status information of the browser to a repository server;
A second storage step in which the repository server stores state information of the browser;
A receiving step in which a second communication device receives status information of the browser from the repository server;
A second session establishing step in which the second communication device establishes a session with the application server using the browser state information;
A communication method comprising:
The browser status information saved in the first saving step is browser status information depending on the platform of the first communication device,
The second storing step includes
The repository server converting the browser state information dependent on the platform of the first communication device into platform independent browser state information;
The repository server stores browser-independent browser state information; and
The receiving step includes
The second communication device, to said repository server, and sending a message requesting status information of the browser,
The repository server converting the platform-independent browser state information into the browser state information depending on the platform of the second communication device;
The second communication device, communication method you; and a step of receiving status information of the browser platform dependent of the second communication device from the repository server.

A first session establishing step in which a first communication device establishes a session with an application server;
A first storing step in which the first communication device stores browser state information during the session;
A transmitting step in which the first communication device transmits status information of the browser to a repository server;
A second storage step in which the repository server stores state information of the browser;
A receiving step in which a second communication device receives status information of the browser from the repository server;
A second session establishing step in which the second communication device establishes a session with the application server using the browser state information;
A communication method comprising:
The application server storing state information of the application server during the session, the state information depending on the platform of the first communication device;
The application server further comprising: transmitting status information of the application server depending on the platform of the first communication device to the first communication device;
The first storing step includes
The first communication device storing browser state information depending on the platform of the first communication device;
The first communication device comprising: converting browser status information dependent on the platform of the first communication device into platform status information independent of the platform;
The transmitting step includes
The first communication device converting the status information of the application server depending on the platform of the first communication device into the status information of the application server independent of the platform;
The first communication device includes transmitting the platform-independent application server status information to the repository server together with the platform-independent browser status information;
In the receiving step, the second communication device receives state information of the browser independent of the platform and state information of the application server independent of the platform from the repository server,
The second session establishment step includes:
The second communication device converts the browser state information independent of the platform into browser state information dependent on the platform of the second communication device;
The second communication device converts the status information of the application server independent of the platform into the status information of the application server dependent on the platform of the second communication device;
The second communication device transmitting status information of an application server depending on a platform of the second communication device to the application server;
The second communication device uses the state information of the application server that depends on the platform of the second communication device using the state information of the browser that depends on the platform of the second communication device. communication how to, comprising the steps of establishing a session.

A first session establishing step in which a first communication device establishes a session with an application server;
A first storing step in which the first communication device stores browser state information during the session;
A transmitting step in which the first communication device transmits status information of the browser to a repository server;
A second storage step in which the repository server stores state information of the browser;
A receiving step in which a second communication device receives status information of the browser from the repository server;
A second session establishing step in which the second communication device establishes a session with the application server using the browser state information;
A communication method comprising:
The application server storing state information of the application server during the session, the state information depending on the platform of the first communication device;
The application server converting the status information of the application server dependent on the platform of the first communication device into the status information of the application server independent of the platform;
The application server further comprising: transmitting status information of the application server independent of the platform to the first communication device;
The first storing step includes
The first communication device storing browser state information depending on the platform of the first communication device;
Converting browser state information depending on the platform of the first communication device into browser state information independent of the platform, and
In the transmission step, the first communication device transmits the platform-independent application server status information together with the platform-independent browser status information to the repository server,
In the receiving step, the second communication device receives the status information of the browser independent of the platform and the status information of the application server independent of the platform from the repository server,
The second session establishment step includes:
The second communication device converts the browser state information independent of the platform into browser state information dependent on the platform of the second communication device;
The second communication device transmitting status information of the application server independent of the platform to the application server;
The application server converting state information of the application server independent of the platform into state information of the application server depending on the platform of the second communication device;
The second communication device uses the state information of the application server that depends on the platform of the second communication device using the state information of the browser that depends on the platform of the second communication device. communication how to, comprising the steps of establishing a session.

A first session establishing step in which a first communication device establishes a session with an application server;
A first storing step in which the first communication device stores browser state information during the session;
A transmitting step in which the first communication device transmits status information of the browser to a repository server;
A second storage step in which the repository server stores state information of the browser;
A receiving step in which a second communication device receives status information of the browser from the repository server;
A second session establishing step in which the second communication device establishes a session with the application server using the browser state information;
A communication method comprising:
The application server storing state information of the application server during the session, the state information depending on the platform of the first communication device;
The application server further comprising: transmitting status information of the application server depending on the platform of the first communication device to the first communication device;
The browser status information saved in the first saving step is browser status information depending on the platform of the first communication device,
In the transmission step, the first communication device sends the status information of the application server depending on the platform of the first communication device to the repository server together with the status information of the browser depending on the platform of the first communication device. Send
The second storing step includes
The repository server converting the browser state information dependent on the platform of the first communication device into platform independent browser state information;
The repository server converting the application server state information dependent on the platform of the first communication device into platform independent application server state information;
The repository server stores the platform-independent browser state information and the platform-independent application server state information; and
The receiving step includes
A step wherein the second communication device, to said repository server, which sends a message requesting the status information and application server state information of the browser,
The repository server converting the platform-independent browser state information into the browser state information depending on the platform of the second communication device;
The repository server converting the platform-independent application server status information into the application server status information dependent on the second communication device platform; and
A second communication device receiving, from the repository server, browser status information dependent on the second communication device platform and application server status information dependent on the second communication device platform; Have
The second session establishment step includes:
The second communication device transmitting status information of an application server depending on a platform of the second communication device to the application server;
The second communication device uses the state information of the application server that depends on the platform of the second communication device using the state information of the browser that depends on the platform of the second communication device. communication how to, comprising the steps of establishing a session.

Status information of the browser, the document object model, script object, browser history, The communication method according to any one of claims 1 to 5, characterized in that it comprises at least one of the browser cache and cookies.

6. The communication method according to claim 3, wherein the status information of the application server includes at least one of a JSP variable and a CGI variable.

A communication system having a first communication device, an application server, a repository server, and a second communication device,
The first communication device establishes a session with the application server;
The first communication device stores browser state information during the session, and stores browser state information depending on the platform of the first communication device ;
The first communication device converts browser status information dependent on the platform of the first communication device into browser status information independent of the platform,
The first communication device sends browser status information independent of the platform to the repository server;
The repository server stores browser state information independent of the platform ;
The second communication device receives the status information of the browser that is independent of the platform from the repository server,
The second communication device converts browser state information independent of the platform into browser state information dependent on the platform of the second communication device,
The second communication device establishes a session with the application server using browser state information depending on a platform of the second communication device .

A communication system having a first communication device, an application server, a repository server, and a second communication device,
The first communication device establishes a session with the application server;
The first communication device stores browser state information during the session, and stores browser state information depending on the platform of the first communication device;
The first communication device sends browser state information depending on the platform of the first communication device to the repository server,
The repository server converts browser state information depending on the platform of the first communication device into browser state information independent of the platform,
The repository server stores browser state information independent of the platform;
The second communication device transmits a message requesting browser status information to the repository server,
The repository server converts browser status information independent of the platform into browser status information dependent on the platform of the second communication device,
The second communication device receives browser state information depending on the platform of the second communication device from the repository server;
The second communication device establishes a session with the application server using browser state information depending on the platform of the second communication device.
A communication system characterized by the above.

First session establishing means for establishing a session with an application server;
Storage means for storing browser state information during the session, the browser state information depending on its own platform ;
First conversion means for converting browser state information dependent on the platform of the device into browser state information independent of the platform;
Transmitting means for transmitting the platform-independent browser status information to the repository server;
Receiving means for receiving state information of the browser independent of the platform from the repository server;
Second conversion means for converting the browser state information independent of the platform into browser state information dependent on the platform of the device;
And a second session establishing means for establishing a session with the application server using browser state information depending on the platform of the device.

First receiving means for receiving status information of the browser of the communication device from the first communication device;
Storage means for storing the browser status information;
Transmitting means for transmitting the browser status information to a second communication device;
A repository server having
The browser status information received by the receiving means is browser status information depending on the platform of the first communication device;
A first conversion means for converting browser state information dependent on the platform of the first communication device into browser state information independent of the platform;
The storage means stores browser state information independent of the platform;
From the second communication device, a second receiving means for receiving a message requesting status information of the browser,
The status information of the browser that does not depend on the platform, the second second conversion means and further comprising: the to Brighter Pojitorisaba the converting the browser state information platform dependent communication device.

On the computer,
A first session establishment step for establishing a session with an application server;
A saving step for saving browser state information during the session, the browser state information depending on its own platform ;
A first conversion step of converting browser state information dependent on the platform of the device into browser state information independent of the platform;
A sending step of sending browser state information independent of the platform to a repository server;
Receiving the platform-independent browser status information from the repository server;
A second conversion step of converting the browser state information independent of the platform into browser state information dependent on the own platform;
And a second session establishment step of establishing a session with the application server using browser state information depending on the platform of the device .

A computer-readable recording medium that records the program according to claim 12 .