(57)【特許請求の範囲】
【請求項１】
インターネット使用可能ユーザ・デバイスのウェブブラウザを介してアクセス可能なリッチ・インターネット・アプリケーションに関連したバックグラウンド・プロセスを管理するアプリケーション実行サーバであって、
前記リッチ・インターネット・アプリケーションからのバックグラウンド・プロセスに対する要求を受信することに応答して、バックグラウンド・プロセスを生成するバックグラウンド・プロセス・マネージャを備え、
前記バックグラウンド・プロセスは、関連する前記リッチ・インターネット・アプリケーションと関連したトリガ・イベントを認識し、前記ウェブブラウザ及び前記リッチ・インターネット・アプリケーションの少なくとも一方が動作しているか否かに関わらず、前記リッチ・インターネット・アプリケーションを起動させることを特徴とするアプリケーション実行サーバ。
【請求項２】
前記バックグラウンド・プロセス・マネージャは、
前記要求に従って実行可能なコードを取得し、該コードを実行することによって、前記バックグラウンド・プロセスを生成することを特徴とする請求項１に記載のアプリケーション実行サーバ。
【請求項３】
前記コードは、前記アプリケーション実行サーバ及び前記インターネット使用可能ユーザ・デバイスが通信可能な外部のサーバから取得されることを特徴とする請求項２に記載のアプリケーション実行サーバ。
【請求項４】
前記バックグラウンド・プロセス・マネージャは、前記受信した要求からＵＲＬを抽出することによって前記外部のサーバを特定することを特徴とする請求項３に記載のアプリケーション実行サーバ。
【請求項５】
前記バックグラウンド・プロセス・マネージャは、前記バックグラウンド・プロセスと前記リッチ・インターネット・アプリケーションとの間でインタラクションを可能とすることを特徴とする請求項１乃至４の何れか１項に記載のアプリケーション実行サーバ。
【請求項６】
前記バックグラウンド・プロセス・マネージャは、サーバ・ネットワーク機能をさらに備え、
前記サーバ・ネットワーク機能は、持続的な通信チャネルをサポートすることによって、バックグラウンド・プロセスと関連するリッチ・インターネット・アプリケーションとの間の通信を可能とすることを特徴とする請求項１乃至５の何れか１項に記載のアプリケーション実行サーバ。
【請求項７】
前記アプリケーション実行サーバは、前記インターネット使用可能ユーザ・デバイスの統合部分として構成されることを特徴とする請求項１乃至６の何れか１項に記載のアプリケーション実行サーバ。
【請求項８】
前記アプリケーション実行サーバは、前記インターネット使用可能ユーザ・デバイスと通信を確立する独立型のネットワーク・エンティティとして構成されることを特徴とする請求項１乃至６の何れか１項に記載のアプリケーション実行サーバ。
【請求項９】
ウェブブラウザを介してアクセス可能なリッチ・インターネット・アプリケーションと、アップリケーション実行サーバに常駐する関連バックグラウンド・プロセスとの間の通信を可能とするインターネット使用可能ユーザ・デバイスであって、
持続的リッチ・インターネット・アプリケーション・マネージャと、
ユーザ・インタフェースとを備え、
前記持続的リッチ・インターネット・アプリケーション・マネージャは、
前記アプリケーション実行サーバで生成されるべき前記バックグラウンド・プロセスと、前記ユーザ・インタフェース上で設定されるべき、ソフトウェア要素である関連する持続的アーチファクトとを要求し、さらに、前記ウェブブラウザ及び前記リッチ・インターネット・アプリケーションの少なくとも一方が動作しているか否かに関わらず、前記バックグラウンド・プロセスと前記関連する持続的アーチファクトと間の通信をサポートすることを特徴とするインターネット使用可能ユーザ・デバイス。
【請求項１０】
前記持続的リッチ・インターネット・アプリケーション・マネージャは、前記リッチ・インターネット・アプリケーション、又は、前記ウェブブラウザからの前記バックグラウンド・プロセスを開始する要求を受信することを特徴とする請求項９に記載のインターネット使用可能ユーザ・デバイス。
【請求項１１】
前記持続的リッチ・インターネット・アプリケーション・マネージャは、さらに、クライアント・ネットワーク機能を備え、
前記クライアント・ネットワーク機能は、前記持続的リッチ・インターネット・アプリケーション・マネージャと、前記アプリケーション実行サーバとの間の持続的な通信チャネルをサポートすることによって、前記リッチ・インターネット・アプリケーションと、前記バックグラウンド・プロセスとの間の持続的な通信を可能とすることを特徴とする請求項９又は１０に記載のインターネット使用可能ユーザ・デバイス。
【請求項１２】
前記持続的リッチ・インターネット・アプリケーション・マネージャは、前記リッチ・インターネット・アプリケーションに関連する指示に従って１つ以上の機能を実行し、
前記指示は、前記持続的な通信チャネルを介して前記バックグラウンド・プロセスから前記持続的リッチ・インターネット・アプリケーション・マネージャへ提供されることを特徴とする請求項１１に記載のインターネット使用可能ユーザ・デバイス。
【請求項１３】
前記クライアント・ネットワーク機能は、リモート・プロシージャ・コール・メカニズム、又は、レプレゼンタティブ・ステート・トランスファ・メカニズムを適用することによって、持続的な通信を可能とすることを特徴とする請求項１２に記載のインターネット使用可能ユーザ・デバイス。
【請求項１４】
前記持続的リッチ・インターネット・アプリケーション・マネージャは、前記指示に従って実行可能なコードを取得し、該コードを実行することを特徴とする請求項１２又は１３に記載のインターネット使用可能ユーザ・デバイス。
【請求項１５】
前記持続的リッチ・インターネット・アプリケーション・マネージャは、さらに、前記バックグラウンド・プロセスから提供された指示に従って、前記インターネット使用可能ユーザ・デバイスの少なくとも１つのデバイス・インタフェースと情報をやり取りすることを特徴とする請求項９乃至１４の何れか１項に記載のインターネット使用可能ユーザ・デバイス。
【請求項１６】
前記インターネット使用可能ユーザ・デバイスは、固定ユーザ・デバイス、又は、無線ユーザ・デバイスの何れかであることを特徴とする請求項９乃至１５の何れか１項に記載のインターネット使用可能ユーザ・デバイス。
【請求項１７】
インターネット使用可能ユーザ・デバイス上で実行されるリッチ・インターネット・アプリケーションに関連したバックグラウンド・プロセスを管理するための、アプリケーション実行サーバにおいて実行される方法であって、
前記インターネット使用可能ユーザ・デバイスで実行される、前記リッチ・インターネット・アプリケーションからのバックグラウンド・プロセスに対する要求を受信するステップと、
前記要求に従って指示を実行することによって前記バックグラウンド・プロセスを生成するステップと、を含み、
前記バックグラウンド・プロセスは、関連する前記リッチ・インターネット・アプリケーションと関連したトリガ・イベントを認識し、前記インターネット使用可能ユーザ・デバイスのウェブブラウザ及び前記リッチ・インターネット・アプリケーションの少なくとも一方が動作しているか否かに関わらず、前記リッチ・インターネット・アプリケーションを起動させることを特徴とする方法。
【請求項１８】
前記リッチ・インターネット・アプリケーションに関連する通知を要求する、前記バックグラウンド・プロセスからの通知要求であって、前記イベントによってトリガとされる前記通知要求を受信するステップと、
前記インターネット使用可能ユーザ・デバイスへの前記通知要求を送信して、該インターネット使用可能ユーザ・デバイスで前記イベントの通知を可能とするステップと
をさらに含むことを特徴とする請求項１７に記載の方法。
【請求項１９】
インターネット使用可能ユーザ・デバイスのウェブブラウザを介してアクセス可能なリッチ・インターネット・アプリケーションと、アップリケーション実行サーバに常駐する関連バックグラウンド・プロセスとの間の通信を可能とする方法であって、
前記インターネット使用可能ユーザ・デバイスは、持続的リッチ・インターネット・アプリケーション・マネージャと、ユーザ・インタフェースとを備え、
前記インターネット使用可能ユーザ・デバイスで実行される前記方法は、
前記リッチ・インターネット・アプリケーションから、バックグラウンド・プロセスを生成するための要求を受信するステップと、
前記ユーザ・インタフェース上で、ソフトウェア要素である関連する持続的アーチファクトを設定するステップと、
前記要求に従って、前記アプリケーション実行サーバでのバックグラウンド・プロセスの作成を要求するステップと、
前記ウェブブラウザ及び前記リッチ・インターネット・アプリケーションの少なくとも一方が動作しているか否かに関わらず、前記バックグラウンド・プロセスからの通知を受信することに応じて、前記バックグラウンド・プロセスと前記関連する持続的アーチファクトと間の通信を管理するステップと
を含むことを特徴とする方法。
【請求項２０】
前記アプリケーション実行サーバからの通知を含むメッセージを受信するステップと、
前記リッチ・インターネット・アプリケーションに通知するステップと、
前記通知が前記関連する持続的アーチファクトを介して承認されれば、予め定義された指示に従って、前記持続的リッチ・インターネット・アプリケーション・マネージャと前記リッチ・インターネット・アプリケーションとの間の通信をサポートするステップと
をさらに含むことを特徴とする請求項１９に記載の方法。
【請求項２１】
前記バックグラウンド・プロセスと前記インターネット使用可能ユーザ・デバイスのデバイス・インタフェースとの間で通知されるバックグラウンド・プロセス通信メッセージを処理するステップをさらに含むことを特徴とする請求項１９又は２０に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、持続的リッチ・インターネット・アプリケーションを管理し、サポートする方法と、バックグラウンド・プロセスがそのようなアプリケーションへのアクセスを獲得できるために適する装置とに関するものである。
【背景技術】
【０００２】
今日、多くのアプリケーションは、大体において、純粋にウェブ型であり、それ故、ウェブブラウザおよびインターネット・アクセス機能を提供された任意のユーザ・デバイスからアクセス可能である。この形式のアプリケーションは、典型的には、リッチ・インターネット・アプリケーション（ＲＩＡ）と呼称され、従来のネイティブ・アプリケーションから期待できることに比較すると、そのユーザに幾つかの重要な利益を提供する。
【０００３】
ＲＩＡが、局部的にインストールされる代わりに、それが開始される時は何時もウェブ・サーバからロードされるので、ＲＩＡを使用するユーザは、もはやアプリケーションをインストールすること、またはソフトウェアを手作業で更新し続けることを気にする必要がない。開発者の観点からは、ＲＩＡは、一般的には、開発および運用する面倒は、対応するネイティブ・アプリケーションより少ないので、ＲＩＡに関連する開発コストは劇的に削減可能である。更に、それらにより、会社は重要なユーザ集団をすばやく獲得可能となるので、ＲＩＡは事業展望から重要である。
【０００４】
また、ネイティブ・アプリケーションからＲＩＡへの開発は、“アーチファクトとしてのソフトウェア”から“サービスとしてのソフトウェアへ移行するパラダイム・シフトと見ることができる。このパラダイム・シフトのため、インターネットはグローバルに分布するオペレーティング・システムになろうとしている。ネイティブ・アプリケーションをユーザ・デバイスに局部的に動作させる代わりに、ＲＩＡプロセスを完全に分散させ、そこでは幾つかのアプリケーションがユーザ・デバイスで動作しており、一方、代わりに、その他のアプリケーションはネットワークで動作していてもよい。多くの異なる形式のユーザ・デバイスから、ユーザはサービスをアクセスしてもよく、移動ユーザ・デバイスは、ネットワークへの多くの可能なエントリ・ポイントの内の一つにすぎなくなる。
【０００５】
移動ユーザ・デバイス産業は、オープン・ユーザ・デバイス、即ち、従来のデスクトップ・コンピュータと高い共通性を持つユーザ・デバイスへのパラダイム・シフトを経験しつつあり、それにより、ユーザに新しいアプリケーション・バージョンをインストール可能となり、ユーザの個人的な好みにより、ユーザのユーザ・デバイス全てをカストマイズ可能となる。また、近い将来には、殆どのユーザ・デバイスには、デスクトップ級のウェブブラウザ、即ち、あたかも伝統的なデスクトップ・コンピュータを使用しているように、ユーザはウェブを閲覧し、殆ど同じユーザ経験を得ることが可能となるウェブブラウザが提供されるであろう。もっともあり得る結果は、恐らく、多くのユーザが削減した開発コストに到達する可能性があるので、そのようなユーザ・デバイスで動作するＲＩＡは、多くの開発者にとっても更により魅力的になるであろう、ということである。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
明らかなことであるが、ウェブブラウザは、ウェブの発展のために必須の要素である。ウェブブラウザ技術における最近の開発は、典型的にはジャバスクリプト・インタプリタおよびジャバスクリプト・フレームワークと呼称するが、これによりアプリケーションがはるかに早く、または十分に機能的なインターネット接続がなくても、動作可能になる。しかしながら、今日利用可能なウェブブラウザは、アプリケーションに幾つかの制約を課すので、本格的なランタイム環境を構成するとは考えることができない。例えば、一旦ウェブブラウザまたはタブ／ウィンドウが閉じられたなら、ＲＩＡはもう一つのアプリケーションのバックグラウンドで動作することを継続できない。
【０００７】
今日利用可能なウェブブラウザが持つもう一つの問題点は、それらはデスクトップ上で完全には統合されない、ということであり、これは、例えばメール・サービスのような、ＲＩＡを定義する特定のウェブ・サービスに関連するアイコンをデスクトップに置くことが可能であるとしても、単にＲＩＡがウェブブラウザにオープンになっている場合にのみ動作しているという理由のため、新しいメールを受信する場合、このサービスはユーザに通知することはできない、ということ意味する。
【０００８】
本発明の目的は、上記に概説した問題点を取り扱うことである、具体的には、アプリケーション実行サーバに常駐するバックグラウンド・プロセスと、インターネット使用可能ユーザ・デバイスに常駐するリッチ・インターネット・アプリケーションとの間で、通信を開始し、再開することを可能にするメカニズムを提供することが、本発明の目的である。
【課題を解決するための手段】
【０００９】
一つの側面によれば、リッチ・インターネット・アプリケーションと関連し、インターネット使用可能ユーザ・デバイスで実行可能なバックグラウンド・プロセスを管理するアプリケーション実行サーバが提供される。アプリケーション実行サーバには、リッチ・インターネット・アプリケーションからのそのような要求を受信することに応答して、バックグラウンド・プロセスを生成するバックグラウンド・プロセス・マネージャを備える。関連のリッチ・インターネット・アプリケーションと関連するトリガ・イベントを認識するよう、そして、ウェブブラウザおよびリッチ・インターネット・アプリケーションの少なくとも一方がオープンまたはクローズ状態であるかどうか、即ち、それらが動作しているか否かに関係なく、リッチ・インターネット・アプリケーションを起動するよう、バックグラウンド・プロセス・マネージャに常駐するバックグラウンド・プロセスを適合させる。それによって、トリガ・イベントがリッチ・インターネット・アプリケーションと通信するために要望を提起する場合は何時でも、関連のバックグラウンド・プロセスからリッチ・インターネット・アプリケーションをアクセスしてもよい。
【００１０】
受信した要求に基づき、従って、そのようなコードを実行することに基づき、例えばサーバから、実行可能なコードを獲得することにより、典型的には、バックグラウンド・プロセスを生成するようバックグラウンド・プロセス・マネージャを適合させる。例えば、受信した要求から要求されたサーバ位置を表わすＵＲＬを抽出することにより、例えば第三パーティのサーバのようなサーバを認識するよう、バックグラウンド・プロセス・マネージャを適合させてもよい。
【００１１】
典型的には、バックグラウンド・プロセスと関連のリッチ・インターネット・アプリケーションとの間の相互作用を可能にするバックグラウンド・プロセス・マネージャに、持続的通信チャネルをサポートすることにより、バックグラウンド・プロセスと関連のリッチ・インターネット・アプリケーションとの間の通信を可能にする専用サーバ・ネットワーク機能を提供してもよい。
【００１２】
インターネット使用可能ユーザ・デバイスの統合部分として、または、インターネット使用可能ユーザ・デバイスにアクセス可能な独立型ネットワーク・エンティティとして、提案のアプリケーション実行サーバを構成してもよい。例えばもしアプリケーションへのアクセスが要求される場合、ネットワークへのアクセスが全く可能でない場合でも、前者の選択肢は望ましいが、一方、バッテリ消費電力が重要な課題である状況では後者の選択肢の方を選ぶべき可能性がある。
【００１３】
もう一つの側面によれば、リッチ・インターネット・アプリケーションとアプリケーション実行サーバに常駐する関連のバックグラウンド・プロセスとの間の通信を可能にするのに適当なインターネット使用可能ユーザ・デバイスが提供される。そのようなインターネット使用可能ユーザ・デバイスには、持続的リッチ・インターネット・アプリケーション・マネージャと呼称してもよい機能的エンティティとユーザ・インタフェースとを備える。バックグラウンド・プロセスがアプリケーション実行サーバで生成されるため、そして、関連の持続的アーチファクトがユーザ・インタフェースに設定されるため、要求をするよう、持続的リッチ・インターネット・アプリケーション・マネージャを適合させる。また、ウェブブラウザおよび／またはリッチ・インターネット・アプリケーションが動作しているか否かに関係なく、動作中のバックグラウンド・プロセスと関連の持続的アーチファクトとの間の通信をサポートするよう、持続的リッチ・インターネット・アプリケーション・マネージャを適合させる。
【００１４】
典型的には、リッチ・インターネット・アプリケーションおよびウェブブラウザの少なくとも一方から、バックグラウンド・プロセスを開始する要求を受信するよう、持続的リッチ・インターネット・アプリケーション・マネージャを適合させる。
【００１５】
更に、持続的リッチ・インターネット・アプリケーション・マネージャには、持続的リッチ・インターネット・アプリケーション・マネージャとアプリケーション実行サーバとの間に持続的通信チャネルを提供することにより、リッチ・インターネット・アプリケーションと関連のバックグラウンド・プロセスとの間で持続的通信を可能とする専用クライアント・ネットワーク・機能が提供さる可能性がある。そのような持続的通信チャネルは、例えばリモート・プロシージャ・コール・メカニズムまたはレプレゼンタティブ・ステート・トランスファ・メカニズムに基づいていてもよい。
【００１６】
持続的リッチ・インターネット・アプリケーション・マネージャには、典型的には、リッチ・インターネット・アプリケーションに関連する指示により、一つ以上の機能を実行する論理を備える。そのような指示は、持続的通信チャネルを介して、関連のバックグラウンド・プロセスから持続的リッチ・インターネット・アプリケーション・マネージャに提供される可能性があり、特定のバックグラウンド・プロセスに関連する実行可能なコードを如何に獲得するかについての指示を備えている可能性がある。
【００１７】
バックグラウンド・プロセスおよび関連のリッチ・インターネット・アプリケーションと相互に作用することに加え、持続的リッチ・インターネット・アプリケーション・マネージャはまた、バックグラウンド・プロセスから提供される指示により、インターネット使用可能ユーザ・デバイスの一つ以上のデバイス・インタフェースと相互に作用する可能性がある。デバイス・インタフェースを介して、持続的リッチ・インターネット・アプリケーション・マネージャおよびバックグラウンド・プロセスは、インターネット使用可能ユーザ・デバイスの一つ以上の内部機能にアクセスする可能性がある。
提案のインターネット使用可能ユーザ・デバイスは、例えばＰＣのような固定ユーザ・デバイス、または、例えばラップトップ、ＰＤＡまたは移動電話機のような無線ユーザ・デバイスであってもよい。更にもう一つの側面によれば、インターネット使用可能ユーザ・デバイスで実行されるリッチ・インターネット・アプリケーションと関連するバックグラウンド・プロセスを管理する方法がまた提供される。この方法によれば、インターネット使用可能ユーザ・デバイスで動作するリッチ・インターネット・アプリケーションから受信した、バックグラウンド・プロセスのための要求に基づいて、指示を実行することによりバックグラウンド・プロセスが生成される。関連のリッチ・インターネット・アプリケーションと関連するトリガ・イベントを認識するように、そして、ウェブブラウザおよび／またはリッチ・インターネット・アプリケーションが動作しているか否かに関係なく、リッチ・インターネット・アプリケーションを起動するよう、バックグラウンド・プロセスを適合させる。
【００１８】
本方法には、バックグラウンド・アプリケーションから通知要求を受信することと、リッチ・インターネット・アプリケーションに関連する通知を要求することと、本要求は本イベントによりトリガされるものであり、インターネット使用可能ユーザ・デバイスに本通知要求を送信することと、それによってインターネット使用可能ユーザ・デバイスで本イベントの通知を可能にすることという、更なるステップを備える。
【００１９】
更なる側面によれば、インターネット使用可能ユーザ・デバイスからアクセス可能なリッチ・インターネット・アプリケーションと、アプリケーション実行サーバに常駐するサーバに常駐する関連のバックグラウンド・プロセスとの間の通信を可能とする方法が提供される。リッチ・インターネット・アプリケーションからバックグラウンド・プロセスを生成する要求を受信する場合、持続的リッチ・インターネット・アプリケーション・マネージャとユーザ・インタフェースとを備えるインターネット使用可能ユーザ・デバイスに適用する本方法を開始する。そのような要求を受信することに応答して、関連のパーセプティブル・アーチファクトがユーザ・インタフェースに設定され、本要求により、アプリケーション実行サーバは、バックグラウンド・プロセスを生成するよう要求される。一旦バックグラウンド・プロセスが生成されると、ウェブブラウザおよび／またはリッチ・インターネット・アプリケーションが動作しているか否かに関係なく、バックグラウンド・プロセスからの通知を受信することに応答して、インターネット使用可能ユーザ・デバイスは、バックグラウンド・プロセスとパーセプティブル・アーチファクトとの間の通信を管理する。
【００２０】
述べた本方法には、アプリケーション実行サーバからの通知を備えるメッセージを受信することと、リッチ・インターネット・アプリケーションに通知することと、もしパーセプティブル・アーチファクトを介して前記通知を承認する場合、事前に定めた指示により、持続的リッチ・インターネット・アプリケーション・マネージャとリッチ・インターネット・アプリケーションとの間の通信をサポートすることという、更なるステップを備えてもよい。更にもう一つの方法のステップによれば、インターネット使用可能ユーザ・デバイスは、バックグラウンド・プロセスとインターネット使用可能ユーザ・デバイスのデバイス・インタフェースとの間で通信するメッセージを処理してもよく、それによってバックグラウンド・プロセスがデバイス・インタフェース、従ってまた、デバイス・インタフェースに実装したセンサまたは機能にアクセス可能となる。
【００２１】
本発明の更なる特徴およびその恩恵については、以下に示す詳細な説明から理解できる。
【００２２】
ここで、本発明について、典型的な実施形態により、そして以下における添付の図面を参照して、更に詳細に説明する
【図面の簡単な説明】
【００２３】
【図１】一つの典型的な実施形態による、持続的リッチ・インターネット・アプリケーションを使用するよう適合している、アプリケーション実行サーバとインターネット使用可能ユーザ・デバイスとを備えるブロック図である。
【図２Ａ】バックグラウンド・プロセスおよび関連の持続的リッチ・インターネット・アプリケーションの簡略図である。
【図２Ｂ】持続的リッチ・インターネット・アプリケーションの簡略図である。
【図３】一つの典型的な実施形態による、図１のブロック図の更に詳細な図である。
【図４】簡略化したシグナル伝達方式であり、一つの典型的な実施形態による、バックグラウンド・プロセスの生成と、それ故、持続的リッチ・インターネット・アプリケーションの設定との手順を示す。
【図５】簡略化したシグナル伝達方式であり、一つの典型的な実施形態による、バックグラウンド・プロセスと持続的リッチ・インターネット・アプリケーションとを終端する手順を示す。
【図６Ａ】簡略化したシグナル伝達方式であり、一つの典型的な実施形態による、バックグラウンド・プロセスと関連するイベントのユーザに通知する手順を示す。
【図６Ｂ】簡略化したシグナル伝達方式であり、一つの典型的な実施形態による、持続的リッチ・インターネット・アプリケーションとバックグラウンド・プロセスとの間の相互作用を可能にする手順を示す。
【図６Ｃ】簡略化したシグナル伝達方式であり、もう一つの典型的な実施形態による、持続的リッチ・インターネット・アプリケーションとバックグラウンド・プロセスとの間の相互作用を可能にするもう一つの手順を示す。
【図７Ａ】簡略化したフローチャートであり、インターネット使用可能ユーザ・デバイスで実行される予定の一つの典型的な実施形態による、持続的リッチ・インターネット・アプリケーションを設定するための方法のステップを示す。
【図７Ｂ】簡略化したフローチャートであり、インターネット使用可能ユーザ・デバイスで実行される予定の一つの典型的な実施形態による、通知を処理するための方法のステップを示す。
【図７Ｃ】簡略化したフローチャートであり、インターネット使用可能ユーザ・デバイスで実行される予定の一つの典型的な実施形態による、バックグラウンド・プロセスを終端するための方法のステップを示す。
【図８Ａ】簡略化したフローチャートであり、アプリケーション実行サーバで実行される予定の一つの典型的な実施形態による、バックグラウンド・プロセスを生成するための方法のステップを示す。
【図８Ｂ】簡略化したフローチャートであり、アプリケーション実行サーバで実行される予定の一つの典型的な実施形態による、バックグラウンド・プロセスからの通知を処理するための方法のステップを示す。
【図８Ｃ】簡略化したフローチャートであり、アプリケーション実行サーバで実行される予定の一つの典型的な実施形態による、バックグラウンド・プロセス終端するための方法のステップを示す。
【発明を実施するための形態】
【００２４】
特許請求した本発明の背後にある一般的な着想は、ウェブ・アプリケーションを閲覧するユーザに対してユーザ経験を高めることであり、もっと具体的には、関連の主なウェブブラウザ・プロセス、即ち、各ＲＩＡが動作しているか否かに関係なく、本プロセスがＲＩＡを起動する可能性のあるようなＲＩＡのバックグラウンドで、しかしそれから分離して、専用バックグラウンド・プロセスが動作可能なようにすることにより、インターネット使用可能ユーザ・デバイスで動作しているＲＩＡを使用するユーザのために、ユーザ経験を高めることである。この意味する所は、関連のＲＩＡが終端された、即ち、ＲＩＡのウェブブラウザ・タブが除去された、および／または完全なウェブブラウザが閉じられたとしても、開始したバックグラウンド・プロセスは、それ自身がまた積極的に終端されるまで、動作し続けるであろうし、その一方で、イベントについて警告を受けた後、ユーザが閉じたＲＩＡを再び起動することを選択する可能性があるというように、トリガ・イベントのユーザに警告できる、ということである。
【００２５】
本文脈では、インターネット使用可能ユーザ・デバイスで動作可能な、任意の種類の動的ウェブ型アプリケーションを開示するようなその最も広い意味において、ＲＩＡを解釈すべきである。
【００２６】
実行可能なアプリケーションという文脈において十分確立されているように、プロセスとはコンピュータ・プログラムと呼称でき、一つ以上の実行可能なオブジェクトを構成する可能性のある、少なくとも一つのコアに存在し、オブジェクトの各々は一つ以上のスレッド構成し、各スレッドは、幾つかのコンピュータ・プログラムを同時に動作させる能力を持つ従来のコンピュータ・システム機能を備えるエンティティにより、連続的に実行されている。マルチコア・システムの場合には、異なるスレッドは並列に実行される可能性がある。
【００２７】
本文脈では、バックグラウンド・プロセスは、主なウェブブラウザ・プロセスを介してＲＩＡから開始されるプロセスと呼称されるべきでありが、ひとたび開始すると、ウェブブラウザの外の個別のランタイム環境で、主なプロセスとは独立に動作する可能性があり、一方、開発者の観点からは、依然として、ウェブブラウザ内部で動作している論理的プロセスとして把握されている。本文脈では、そのようなバックグラウンド・プロセスをアプリケーション・スコープとも呼称する可能性がある。
【００２８】
バックグラウンド・プロセスは、関連のＲＩＡと関連する活動を積極的に監視でき、ＲＩＡと、また選択的には、例えばデバイス・インタフェースを介してインターネット使用可能ユーザ・デバイスのその他の機能的エンティティと通信できるであろう。
【００２９】
バックグラウンド・プロセスは、多くの理由で、関連のＲＩＡを起動するよう構成された可能性がある。一つの理由は、ある変更またはイベントで更新されることを望むユーザが、それらが起こる可能性のある場合はいつでも、そのようなタスクを完了するよう要求した、ということである可能性がある。ＲＩＡを起動するもう一つの理由は、例えばユーザを共同ウェブ・サービスに勧誘する呼制御またはサービス勧誘に、または、着信電話ＲＩＡまたは着信インスタント・メッセージングＲＩＡに応答することに、関連する可能性がある。特許請求の本発明によれば、そのようなバックグラウンド・プロセスは、ウェブブラウザおよび／または関連のＲＩＡがクローズであるか、またはオープンを保つかに関係なく、動作を維持することができる。
【００３０】
上記で説明した概念を典型的に示すため、ここで、二つの典型的使用の場合を以下に提示する。
【００３１】
第一の使用の場合では、ユーザのビルがユーザ・デバイスからウェブを閲覧し、最終的には興味があると分かったウェブ・アプリケーション（ＲＩＡ）を選択する。本アプリケーションは、リアルタイムでユーザ・デバイスに最新のＮＨＬ結果を表示するスポーツ・ウェブ・ページである。本ウェブ・アプリケーションは、選択可能なボタンの共同で、適当な対話をユーザに単に促すことにより、ユーザ・デバイスのダッシュボードに特定の形式のアイコンを追加する選択肢をビルに提供する。ビルは、本アプリケーションの提供した拡張を好み、対話で提供された“はい”ボタンを起動し、強化されたウェブ・アプリケーションと、強化された本アプリケーションに関連し、ダッシュボードに現われる新しいアイコンとのインストールを開始する。次に、ビルは本ウェブ・アプリケーションを閉じて、インターネットを閲覧することを続ける。しばらくして、小さな星印がダッシュボードの上部の左の角に提示されるというように、最近導入したアイコンは外観を変更する。ビルはアイコンの変更に気付き、強化したウェブ・アプリケーションに関連する何かが起こったということを興奮して明確に理解し、迷うことなくアイコンをクリックし、結果として閉じたウェブ・アプリケーションが本ウェブブラウザで再び起動される。ここでビルは、彼のひいきのチームが得点し、今やリードしているということをダッシュボードで見ることができる。
【００３２】
もう一つの典型的な使用の場合によれば、これは、代わりにボイス・オーバ・インターネット・プロトコル（ＶｏＩＰ）アプリケーションと呼称され、ウェブを閲覧しているユーザであるピータが、彼が興味を持てると分かったウェブＶｏＩＰアプリケーションで結局は終了する。ピータは、自分のユーザ・デバイスのディスプレイに現われているボタンを起動し、このようにして選択したアプリケーションを持続的にする。従来の固定電話の形式のアイコンがディスプレイに現われる。ディスプレイに現われる対話を介して、ひとたび、彼が、例えばユーザネームとパスワードのような彼の信用情報を完全に入力したなら、ピータはウェブブラウザを閉じ、インターネットの探索を続ける。また、彼のユーザネームが、説明した本ＶｏＩＰサービスに対して正当であるということに彼の親友が気付かされることを、彼は確認する。後で、ピータは、如何にディスプレイの電話アイコンが色を変更しており、鳴音がユーザ・デバイスのスピーカから発生するかに気付く。応答で、ピータは電話アイコンを起動し、ＶｏＩＰアプリケーションがウェブブラウザで開始する。ピータは、彼の友人ビルが彼を呼び出しているということに気付き、応答で、ウェブ・アプリケーションに現われる“回答”ボタンを起動し、ここで彼の友人に会話することを開始できる。
【００３３】
バックグラウンド・プロセスは、それを最初に生成したインターネット使用可能ユーザ・デバイスからそれを積極的の終端するまで、またはそれを特定した一つまたは複数のタスクが完全に完了してしまうまで、通常は管理され、動作していることが維持されるであろう。或いは、バックグラウンド・プロセスは、もしそれが疑わしいか有害なコードを発見した場合、バックグラウンド・プロセス・マネージャによって終端される可能性がある。
【００３４】
ＲＩＡは、提案のメカニズムに従って動作するよう設定された、関連のバックグラウンド・プロセスと一緒に、持続的リッチ・インターネット・アプリケーション（ＰＲＩＡ）と呼称することができる、新しい持続的アプリケーション概念を構成する。各ＰＲＩＡは、二つのエンティティ、即ち、インターネット使用可能ユーザ・デバイスに位置する、レプレゼンテーション・エンティティ、およびＰＲＩＡと関連する特定のタスクを実行している、バックグラウンド・プロセス・エンティティから構成されるであろう。この形式のレプレゼンテーション・エンティティは、パーセプティブル・アーチファクト（ＰＡ）を適用することにより実装できる。このようにして、典型的には視覚的または音感覚的経験を介して、ユーザが警告を受けることができるＰＡ概念は、バックグラウンド・プロセスと関連のＲＩＡとの間のリンクを構成し、これによりバックグラウンド・プロセスはＲＩＡを起動できるようになる。ＰＡは、例えばサイズ、色、および／または形状を変更することにより、その外観を変更できるというように、典型的には構成された可能性のある動的レプレゼンテーション・エンティティである。
【００３５】
各バックグラウンド・プロセスは、インターネット使用可能ユーザ・デバイスのユーザ・インタフェース（ＵＩ）を介してアクセス可能であるＰＡと関連するであろう。ＰＡ概念により、ユーザは作動中のバックグラウンド・プロセスに対する制御を容易に維持し、必要な時は何時でもバックグラウンド・プロセスを終端することが可能になり、同様に、バックグラウンド・プロセスは、例えば関連のＰＡを変更することにより、ユーザと相互に作用し、インターネット使用可能ユーザ・デバイスのプロセスと相互に作用できるようになる。言い換えれば、特定のＲＩＡと関連し、通知を受けたイベントを継続することをユーザが望むか否かを決定することはユーザ次第であるというように、今やＰＲＩＡを構成している、トリガ動作中のインターネット使用可能ユーザ・デバイスのユーザに、バックグラウンド・プロセスが通知または警告するためのツールとして、ＰＡを見なすことができる。
【００３６】
ひとたび、ユーザが警告されたなら、ユーザはＰＡを動作させることにより先に進むことを選択する可能性があり、それによって、それぞれのバックグラウンド・プロセスの対応する指示により、持続的リッチ・インターネット・アプリケーション・マネージャに開始したプロセスを継続するよう指示する。
【００３７】
ここで、上記で説明した、強化されたバックグラウンド・プロセス概念を提供するのに適する典型的システム・アーキテクチャについて、図１を参照して更に詳細に説明する。
【００３８】
理解すべきことであるが、この明細書の図は単に典型的な実施形態を説明するものであり、定められた機能ユニットは論理ユニットとして呼称されるべきであり、本文脈で関連するが、提案のメカニズムの理解に必要ではないその他のユニットは簡潔さの理由で省略されてしまう可能性がある。例えば、図１で説明したインターネット使用可能ユーザ・デバイスはまた、通常、ユーザ・デバイスがインターネットおよび外部のネットワーク・サービスと通信可能となるのに必要な、従来の通信手段を備える。
【００３９】
特許請求の本発明は、インターネット使用可能ユーザ・デバイスに存在し、ＰＲＩＡの開始と終端を管理するよう、同様にＰＲＩＡと関連する通信ステップを処理するよう構成した機能的エンティティに基本的に基づく。今後はＰＲＩＡマネージャと呼称するが、このエンティティは、一つ以上のバックグラウンド・プロセスを管理するよう適合する、もう一つの一般的なエンティティと相互に作用する。
【００４０】
各々のＰＲＩＡに対して、個別のバックグラウンド・プロセスがアプリケーション実行サーバで起動され、管理される。そのような目的のため、今後はバックグラウンド・プロセス・マネージャと呼称するが、機能的エンティティがアプリケーション実行サーバに提供される。ＰＲＩＡから新しいバックグラウンド・プロセスの要求を受信することに応答して、関連のＲＩＡのために事前に構成された、例えばフラッシュ、ジャバスクリプト、ジャバ、フラッシュまたはＨＴＭＬのような、ある実行可能なコードを獲得するよう、バックグラウンド・プロセス・マネージャを構成する。正しいバックグラウンド・プロセスを生成することができるため、そのような要求には、典型的には、適当なコードを検索すべき場所を示す、即ちコードをダウンロードすることができる場所からの、例えばＵＲＬのような指示を備える。
【００４１】
図１は、インターネット使用可能ユーザ・デバイス１００の略図であり、インターネット上のＲＩＡ、即ち、ウェブブラウザ１０２を提供されたユーザ・デバイスにアクセスするよう構成されている。ウェブブラウザ１０２により、ユーザは従来の方法でＲＩＡにアクセスし、閲覧できる。また、図１のインターネット使用可能ユーザ・デバイスにはＵＩ１０１を備えるが、これは、例えばデスクトップまたはダッシュボード、オーディオ型ＵＩまたは、選択された形式のＰＡを適用可能とする任意のその他の形式のＵＩのような、図形的ＵＩである可能性がある。
【００４２】
本ＵＩは、典型的には、ＰＡがアイコンまたはウィジェットである、ビジュアルＵＩとして構成される可能性があっても、ＵＩまたはＰＡはどちらもそのような解決策に限定されない。ＵＩは、例えば、オーディオ型ＵＩである可能性があり、音声を経由してユーザに警告し、本ユーザでさえ、音声を使用するＰＡと相互に作用することにより、そのような警告またはトリガに応答できる可能性がある。
【００４３】
或いは、ＰＡは、ビジュアルおよび音声効果の組合せで中継する可能性がある。
【００４４】
ユーザは通知を介してバックグラウンド・プロセスから警告を受けることができ、ＰＲＩＡをインストールする場合にインターネット使用可能ユーザ・デバイス１００のＵＩ１０１に現われる関連のＰＡ（ＰＡ−１−ＰＡｎ）を介して、ＰＲＩＡへのアクセスと応答を獲得できる。典型的なシナリオでは、もし図形的ＵＩを適用するなら、ＵＩ１０１はまた、従来のアイコン(アイコン１−アイコンｍ)、例えばネイティブ・アプリケーションに関連するアイコンを表示するであろう。
【００４５】
インターネット使用可能ユーザ・デバイス１００の統合部分として、または、通信ネットワークのどこかに位置する独立型エンティティとして、アプリケーション実行サーバ１５０を構成してもよい。もし、通信ネットワークへのアクセスが可能でないか、または幾つかの理由で望ましくない場合でもＰＲＩＡが動作すべきであるなら、インターネット使用可能ユーザ・デバイスの一部であるアプリケーション実行サーバは望ましい選択である可能性があり、一方、通信ネットワーク・ノードに実装されるアプリケーション実行サーバは、多くのその他の状況において、しかし、具体的にはインターネット使用可能ユーザ・デバイスでのバッテリ消費電力が重要な課題であるような状況では、好ましい代替案である可能性がある。
【００４６】
典型的には、特定のタスクのため事前に定めていたＰＡを生成する選択肢をユーザに提供することにより、ＲＩＡの一つ以上から、一つ以上のＰＲＩＡを起動する可能性がある。それらの動的特性およびそれらの従来のアイコンからの区別のため、アイコンとして実装されたＰＡは、ライブ・アイコンとも呼称される可能性がある。
【００４７】
例えばＰＡ１をバックグラウンド・プロセス１に写像するというように、各々のＰＡ（ＰＡ１−ＰＡｎ）を、アプリケーション実行サーバ１５０に常駐するそれぞれのバックグラウンド・プロセス（バックグラウンド・プロセス１−バックグラウンド・プロセスｎ）に写像するであろう。
【００４８】
ＰＡを介して、ユーザは、関連のバックグラウンド・プロセスを容易に生成し、制御しそして終端できるであろう。ユーザに指示した対話に応答して、ユーザはバックグラウンド・プロセスを生成する可能性がある。典型的には、ユーザがあるＰＲＩＡを起動したいかどうかをユーザに尋ねるそれぞれのＰＲＩＡにより、そのような対話を開始するであろう。例えばジャバスクリプトＡＰＩのようなウェブ・アプリケーションＡＰＩを使用して、ＲＩＡ１０３から直接的にか、または、今日では、全ての従来のウェブブラウザで利用可能な機能であるブックマークを追加する場合に適用されるメカニズムに類似である、ウェブブラウザ１０２が提供する専用の機能を介してか、そのどちらかでそのような対話を実行する可能性がある。或いは、ＲＩＡの処理コードに実装した幾つかのトリガに応答して、バックグラウンド・プロセスを自動的に生成する可能性がある。
【００４９】
ここで、図２Ａを参照して、バックグラウンド・プロセスがウェブブラウザ１０２を介して如何に生成される可能性があるかを説明する典型的なシナリオについて、以下に詳細に説明する。
【００５０】
ＲＩＡを閲覧するユーザによるＰＡ１の起動は、ＰＲＩＡ、すなわちＰＲＩＡ１を起動するが、これは、インターネット使用可能ユーザ・デバイス１００のＵＩ１０１でＰＡ１を起動することに加えて、アプリケーション実行サーバ１５０でバックグラウンド・プロセス１を生成する、ということを意味する。図２Ａによれば、これは、例えば“ライブ・アイコンを追加するか？”というような質問がＵＩ１０１のディスプレイに現れる場合、ユーザが“はい”を選択することを選ぶことにより実現される可能性がある。
【００５１】
また、インターネット使用可能ユーザ・デバイスとバックグラウンド・プロセスとの間の相互作用については、図２Ｂにより説明することができ、バックグラウンド・プロセスを動作するよう構成したコードは、例えば計算のようなタスクを実行し、バックグラウンド・プロセスとインターネット使用可能ユーザ・デバイスの関連のＲＩＡとの間の通信を可能にする可能性がある。バックグラウンド・プロセスを構成するそのようなコードには、バックグラウンド・プロセス１とインターネット使用可能ユーザ・デバイス１００の関連のＰＡとの間の通信を可能にする、即ち本例において、パーセプティブル・アーチファクト・オブジェクト２１０が表わすＵＩ１０１に警告を提供するためのコードと、ここではユーザ・インタフェース・オブジェクト２１１が表わすＵＩ１０１を介して、バックグラウンド・プロセス１と関連のＲＩＡとの間の通信を可能にするコードとの両方を備える。
【００５２】
また、図２Ｂには、選択的デバイス・インタフェース・オブジェクト２１２を備え、これは、バックグラウンド・プロセスとインターネット使用可能ユーザ・デバイス１００のデバイス・インタフェース２１３との間の相互作用を可能にするよう構成される。そのようなオブジェクトは、関連のＲＩＡを含まなければならないか、または含む必要がないタスクを実行するよう構成される可能性があり、そして、例えば、インターネット使用可能ユーザ・デバイス１００のバッテリ状態、無線サービス圏、または位置をチェックするようなタスクを含む可能性がある。
【００５３】
開発者の観点からは、バックグラウンド・プロセスで動作するコードはユーザ・デバイスで局部的に動作しているように見え、一方、本コードは、実際には、通信ネットワークの遠隔位置で動作している可能性がある。
【００５４】
図１を参照して上記で説明した、典型的アプリケーション・サーバとインターネット使用可能ユーザ・デバイスのアーキテクチャについて、図３を参照して、ここで更に詳細に説明する。簡潔さの理由で、図１の幾つかの機能は図３においては省略された。
【００５５】
ＰＲＩＡマネージャ１０４は、ＵＩ１０１にＰＡを生成することに対して、そしてアプリケーション実行サーバ１５０からバックグラウンド・プロセスに要求することに責任がある。また、インターネット使用可能ユーザ・デバイス１００と、バックグラウンド・プロセス（バックグラウンド・プロセス１−ｎ）とそれらのそれぞれの、関連するＰＡ（ＰＡ１−ｎ）とに間の信頼できる通信を可能にするのに使用される予定の、アプリケーション実行サーバ１５０との間の通信チャネル１０８を生成し、維持するよう、ＰＲＩＡマネージャ１０４を構成する。この目的のために、リモート・プロシージャ・コール（ＲＰＣ）通信またはレプレゼンテーショナル・ステート・トランスファ（ＲＥＳＴ）メカニズムをサポートする通信チャネルを使用する可能性がある。
【００５６】
バックグラウンド・プロセスと、関連するＲＩＡとの間の次の相互作用を獲得できるというように、そのようなメッセージを処理するよう適合させた、ＰＲＩＡマネージャ１０４にメッセージを生成し、送信することにより、ＰＲＩＡマネージャ１０４に警告するよう、バックグラウンド・プロセスを適合させる。
【００５７】
既に上記に述べたように、アプリケーション実行サーバ１５０は、ＰＲＩＡマネージャ１０６と相互に作用することを可能にする機能を必要とする。図１によれば、バックグラウンド・プロセス・マネージャ１５１と呼称される専用の機能的エンティティとして、そのような機能を実装する可能性がある。
【００５８】
ＰＲＩＡマネージャ１０４からの要求でバックグラウンド・プロセスを生成するよう、同様に既に生成したバックグラウンド・プロセスを管理するよう、そしてバックグラウンド・プロセスがインターネット使用可能ユーザ・デバイス１００と通信可能なようになるよう、バックグラウンド・プロセス・マネージャ１５１を適合させる。
【００５９】
バックグラウンド・プロセス・マネージャ１５１は、アプリケーション実行サーバ１５０で各々の動作するバックグラウンド・プロセス（バックグラウンド・プロセス１−ｎ）のライフ・サイクル管理に対して責任がある。これは、着信要求に耳を傾けるよう、確立した通信チャネル１０８を介してＰＲＩＡマネージャ１０４から到着する可能性のある新しいバックグラウンド・プロセスを生成するよう、例えば第三パーティ・サーバのようなコード・ソースからの関連のコードを獲得することにより、そのような要求に応答するよう、そしてダウンロードしたコードを実行することにより新しいバックグラウンド・プロセスを生成するよう、それを適合させる、ということを意味する。或いは、幾つかのまたは全ての関連のコードは、アプリケーション実行サーバ１５０の記憶手段に既に記憶されている可能性がある。
【００６０】
また、アプリケーション実行サーバ１５０には、コード・インタプリータ１５２、またはバックグラウンド・プロセス・マネージャ１５１に接続され、実行可能なコードを解釈するよう構成された、任意の対応する機能を備える。
【００６１】
一つの代わりの実施形態によれば、ジャバスクリプトを実行可能なコードとして適用する場合には、例えば、両方ともそれぞれのジャバスクリプト・インタプリータを含むＷｅｂＫｉｔまたはＭｏｚｉｌｌａ  Ｇｅｃｋｏのような、完全なレンダリング・エンジン（図示せず）がアプリケーション実行サーバ１５０に組み込まれる可能性がある。更にもう一つの代わりの実施形態によれば、例えばＭｏｚｉｌｌａ  Ｒｈｉｎｏのような独立型コード・インタプリータ（図示せず）をアプリケーション実行サーバ１５０に組み込む可能性がある。
【００６２】
インターネット使用可能ユーザ・デバイス１００のＰＲＩＡマネージャ１０４およびアプリケーション実行サーバ１５０のバックグラウンド・プロセス・マネージャ１５１を両方とも多くの各種の方法で、実装される可能性がある。また、図３のＰＲＩＡマネージャ１０４には、クライアント・ネットワーク機能３００に接続されるＰＡ／ＲＩＡ機能３０１と、ウェブブラウザ３０２および／またはウェブブラウザ通信機能３０３として実装され、ウェブブラウザ１０を介してＲＩＡ１０３との相互作用を可能とする機能とを備える。
【００６３】
ＰＡ／ＲＩＡ機能３０１は上記で説明したＰＡ機能を実装するよう適合した論理機能であり、即ち、ＰＡ／ＲＩＡ機能３０１は適合したＰＡと関連の警告機能をサポートする。
【００６４】
一つの典型的な実施形態によれば、デスクトップの図形的に適用可能なアイコンをサポートするよう、ＰＡ／ＲＩＡ機能３０１を構成する可能性がある。ユーザが、そのようなＰＡ／ＲＩＡ機能を介してバックグラウンド・プロセスからのイベントについて通知された場合、ユーザはアイコンをクリックする可能性があり、それによって、関連のＲＩＡを開始して、例えば、標準のプラットフォーム・アイコンＡＰＩ、または任意のその他の対応する標準的技術で、応答してもよい。或いは、ユーザは本通知および提供されたＰＲＩＡ特性を無視してもよい。通知メカニズムは、例えばＤバッス・インタフェースによりサポートされる可能性のある、例えばＵｂｕｎｔｕ  Ｌｉｎｕｘ（登録商標）デスクトップ・アイコンを、実装することにより、適用される可能性がある。
【００６５】
もう一つの典型的な実施形態によれば、代わりに、例えば、インターネット使用可能ユーザ・デバイスのスピーカを介して音声を鳴らすことにより、ユーザにイベントを通知するというように、オーディオ型ユーザ・インタフェースを介して相互作用をサポートするよう、ＰＡ／ＲＩＡ機能３０１を構成してもよい。そのようなシナリオでは、ユーザは、例えば図形的アイコンを起動して、または既知の音声処理技術を介して音声コマンドを使用することにより、そのような通知に応答してもよい。
【００６６】
更にまた、インターネット使用可能ユーザ・デバイスのデバイス・インタフェースを介して、バックグラウンド・プロセスとインターネット使用可能ユーザ・デバイスの機能との間の相互作用をサポートするよう、ＰＡ／ＲＩＡ機能３０１を構成してもよい。
【００６７】
例えば、標準のＸＭＬ  ＨＴＴＰ要求オブジェクトとして提供された要求を処理するよう適合する可能性のある、ウェブ・サーバ３０２を介するか、共有メモリ、パイプまたはソケットに依存するプロセス間通信プロトコルを使用して、ＰＲＩＡマネージャ１０６と通信するよう適合させた、例えばネットスケープ・プラグイン・アプリケーション・プログラミング・インタフェース（ＮＰＡＰＩ）またはＷｅｂＫｉｔプラグインのようなウェブブラウザ・プラグインとして構成される可能性のある、ウェブブラウザ通信機能３０３を介するか、そのどちらかを介して、ウェブブラウザ１０２から新しいＰＲＩＡの要求を受信するよう、ＰＡ／ＲＩＡ機能３０１を適合させる。
【００６８】
一つの実施形態によれば、バックグラウンド・プロセスを要求するメッセージへのＵＲＬの挿入をサポートするよう、そして、アプリケーション実行サーバ１５０との通信を管理するよう適合したクライアント・ネットワーク機能３００を介して、対応するサーバ・ネットワーク機能にそのようなメッセージを提供するよう、ＰＡ／ＲＩＡ機能３０１を適合させてもよい。
【００６９】
もし通信チャネルがバックグラウンド・プロセス・マネージャ１５１とＰＲＩＡマネージャ１０４との間に前から全く設定されていないなら、これらの二つの機能の間に通信チャネルを提供するよう、クライアント・ネットワーク機能３００を適合させる。
【００７０】
また、バックグラウンド・プロセスから受信した通知を処理するよう、ＰＡ／ＲＩＡ機能３０１を適合させる。もしウェブブラウザ１０２および／または関連のＲＩＡが閉じた、非動作状態にある場合のみ、要求された通知を処理するよう、ＰＡ／ＲＩＡ機能３００を構成してもよい。ウェブブラウザ１０２とのユーザの接続が終端した場合、またはあるＲＩＡにウェブブラウザをもはや接続しない場合を認識するよう構成したＰＡ／ＲＩＡ機能３０１は、そのような特性を獲得する可能性がある。この目的に、例えばＤバス・メカニズムを使用してもよい。もしＰＡ／ＲＩＡ機能が、ウェブブラウザ１０２および関連のＲＩＡのどちらも現在閉じていると認識するなら、それぞれのＰＲＩＡのための指示に従い、本処理を開始するよう、代わりにそれを構成してもよい。
【００７１】
もし通知を処理する予定であれば、通知された動作を承認して、関連のＰＡを起動することにより、ユーザは本通知に応答することを決定する可能性があり、それによって、ＰＲＩＡの特定のコードに従い、そのような承認を認識し、追加の動作を実行するよう、ＰＡ／ＲＩＡ機能３０１を適合させる。
【００７２】
例えば拡張マークアップ言語（ＸＭＬ）−ＰＲＣ、ジャバスクリプト・オブジェクト表記法（ＪＳＯＮ）−ＰＲＣまたはレプレゼンテーショナル・ステート・トランスファ（ＲＥＳＴ）メカニズムのようなリモート・プロシージャ・コール（ＲＰＣ）メカニズムにより、例えば、説明した通信機能を実現してもよい。
【００７３】
通知の承認のための待ち時間を制限するため、ＰＲＩＡマネージャ１０４にはまた、事前に定めた時間制限が満了した場合に承認を全く受信していなかったなら、通知が開始した処理を終端するというように、適合した従来のタイマを備えてもよい。その結果、バックグラウンド・プロセス・マネージャ１５１もまた、対応するタイマ機能を備えてもよい。
【００７４】
既に上記で述べたように、通信チャネルを介して通信をサポートするため、バックグラウンド・プロセス・マネージャ１５１には、対応するクライアント・ネットワーク機能３００と相互に作用するよう適合した、サーバ・ネットワーク機能３１０を備えてもよい。
【００７５】
もし適用可能なら、バックグラウンド・プロセスに対する要求からＵＲＬを抽出するよう、サーバ・ネットワーク機能３１０を適合させてもよく、それによって、関連のバックグラウンド・プロセスに必要な関係のある実行可能なコードを簡単な方法で獲得可能となる。
【００７６】
各々の動作しているバックグラウンド・プロセスの新しい情報のために、対応するサーバ・ネットワーク機能３１０をポーリングするクライアント・ネットワーク機能３００を持つことは通常実現可能ではなく、クライアント・ネットワーク機能３００をホストするインターネット使用可能ユーザ・デバイスにおいて、バックグラウンド・プロセスは過剰なバッテリ消費電力に導く可能性があるので、二つの機能の間には、サーバ起動のプッシュ型通信チャネルを選ぶ。従って、もしアプリケーション実行サーバ１５０をネットワークに位置させるなら、例えばＳＭＳ、Ｃｏｍｅｔ、ＢＯＳＨ、ウェブ・ソケット、またはサーバ・セント・イベントのような既知の技術的解決策に基づくメカニズムを、この目的に適用してもよい。もし、代わりに、インターネット使用可能ユーザ・デバイス１００の一部としてアプリケーション実行サーバ１５０を構成したなら、代わりに、従来のＴＣＰソケットまたは任意のその他の形式の適当なプロセス間通信プロトコルをこの目的に使用してもよい。
【００７７】
各々のバックグラウンド・プロセスに対する個別の接続の管理と、それ故、例えばインターネット使用可能ユーザ・デバイス上の複数のＰＡの起動による、過剰なエネルギ消費の必要性とを避けるため、一つの通信チャネルがインターネット使用可能ユーザ・デバイスとアプリケーション実行サーバとの間の通信を維持するのに適当であろう。少なくとも、アプリケーション実行サーバで動作する任意のバックグラウンド・プロセスがある限り、典型的には、そのようなチャネルを維持するであろう。従って、ＰＲＩＡマネージャは、アプリケーション実行サーバ毎に一つの通信チャネルのみを必要とするが、多数の通信チャネルを異なるアプリケーション実行サーバにオープンにして置くことができる。
【００７８】
また、図３のバックグラウンド・プロセス・マネージャ１５１には、サーバ・ネットワーク機能３１０とコード・インタプリータ１５２とに接続した、バックグラウンド・プロセス機能３１１を備える。バックグラウンド・プロセス機能３１１は、事前に定めた指示により、新しいバックグラウンド・プロセスを生成して終端するように、そして、もし必要なら、例えば外部のコード・ソースから、および／またはアプリケーション実行サーバ上に存在する可能性のあるメモリ（図示せず）から、バックグラウンド・プロセスの生成のために必要なコードを獲得するように適合した論理を典型的にはホストする。
【００７９】
以下に、前に説明したバックグラウンド・プロセス概念に基づく多くの典型的なシナリオについて、図４−６Ｃそれぞれを参照して、ここで更に詳しく以下に説明する。
【００８０】
図４は、インターネット使用可能ユーザ・デバイス１００が、バックグラウンド・プロセス、従ってＰＲＩＡを起動または生成するため、アプリケーション実行サーバ１５０と如何に相互に作用する可能性があるかを示す、一般的なシグナル伝達図である。
【００８１】
第一のステップ４：１で、ウェブブラウザ１０２を介してＲＩＡ１０３を閲覧するユーザは、ＲＩＡ１０３を介してＰＲＩＡマネージャ１０４と相互に作用するか、ウェブブラウザ１０２を介して直接か、そのどちらかで、インターネット使用可能ユーザ・デバイス１００のＵＩ１０１に、例えばライブ・アイコンのようなＰＡを追加することを選択する。ＰＲＩＡマネージャ１０４は、次のステップ４：２で示すように、事前に定めた指示に従い、関連のＲＩＡを識別し、本ＰＡを設定する。
【００８２】
ＰＡを設定することに平行して、ＰＲＩＡマネージャ１０４はまた、アプリケーション実行サーバ１５０のバックグラウンド・プロセス・マネージャ１５１にメッセージを生成し、送信するが、本メッセージには、もう一つのステップ４：３で示すように、新しいバックグラウンド・プロセスを設定する要求を備える。本例では、インターネット使用可能ユーザ・デバイス１００とアプリケーション実行サーバ１５０との間にチャネルを既に設定していると仮定している。もしこれがその場合でない可能性があるなら、この段階でＰＲＩＡマネージャがそのような通信チャネルを設定しなければならないであろう。
【００８３】
本要求に従い、バックグラウンド・プロセス・マネージャ１５１は、バックグラウンド・プロセス３１２を生成することによって本要求に応答する。典型的には、事前に定めた機能を実行することにより、即ち、バックグラウンド・プロセス・マネージャ１５１において、選ばれたＰＲＩＡのために特定して構成した事前に定めたコードを動作させることによりこれを達成する。バックグラウンド・プロセス・マネージャ１５１が関連のＰＲＩＡを識別し、それ故、関連のバックグラウンド・プロセスを生成できるようにするため、ＰＲＩＡマネージャ１０４は、ステップ４：３で配信するメッセージに、ＵＲＬ、またはＰＲＩＡ関連のコードをホストするソースを識別可能とする任意のその他の情報を追加した可能性がある。
【００８４】
次のステップ４：４で示すように、本メッセージからＵＲＬ、または任意のその他の対応する情報を抽出し、この情報を使用して、第三パーティ・サーバ４０１、または関連のコードをダウンロードする可能性のある任意のその他のソースから関連のバックグラウンド・プロセスを獲得する。或いは、関連のコードが既に、アプリケーション実行サーバ１５０に存在する可能性がある。バックグラウンド・プロセス・マネージャ１５１は、新しいバックグラウンド・プロセスにＰＲＩＡ関連のコードを投入し、これからは、本プロセスが最初に開始したＲＩＡのバックグラウンドでＰＲＩＡ関連のコードを実行するであろう。
【００８５】
ここで、ＰＡは、関連のバックグラウンド・プロセスと一緒にＰＲＩＡを構成するが、ＰＲＩＡは通常は、ウェブブラウザ１０２および／または本ＰＡを最初に生成したＲＩＡ１０３が、動作中／オープンであるかないかに関係なく、例えば、関連のバックグラウンド・プロセスにおける一つ以上のイベントの完了により、または誤りのある、または疑わしいコードの検出により、ＰＡを操作するユーザがそれをクローズするまで、動作中のままであろう。
【００８６】
図５は、ＲＩＡ１０３に関するバックグラウンド・プロセス３１２を積極的に除去するための、可能性のあるシナリオを示す。
【００８７】
第一のステップ５：１では、バックグラウンド・プロセス３１２を除去するよう決定したユーザは、第一に、インターネット使用可能ユーザ・デバイス１００のＵＩ１０１から関連のＰＡを除去するための選択肢を選ぶ。次に、もう一つのステップ５：２で示すように、ＵＩ１０１からＰＲＩＡマネージャ１０４にＰＡの要求された除去の通知を送信する。ＰＲＩＡマネージャ１０４は、次のステップ５：３に示すように、ＰＡを除去することによりそのような通知に応答する。
【００８８】
また、ＰＲＩＡマネージャ１０４は、もう一つのステップ５：４で示すように、バックグラウンド・プロセス３１２を除去するよう、バックグラウンド・プロセス・マネージャ１５１に要求するメッセージを送信する。応答では、バックグラウンド・プロセス・マネージャ１５１は、最終のステップ５：５で示すように、バックグラウンド・プロセス３１２を除去する。
【００８９】
更にもう一つのシグナル伝達図、すなわち図６Ａは、バックグラウンド・プロセスでトリガされたイベントについてユーザに通知する目的のため、提案したＰＲＩＡ可能メカニズムを如何に適用する可能性があるかを示しており、それによって、ユーザが本通知で開始したプロセスが開始することを承認するか、または無視するかを決定する可能性があるというように、あるイベントが発生したということにユーザが気付くことを可能にする。通知するバックグラウンド・プロセスおよび／またはインターネット使用可能ユーザ・デバイス１００のウェブブラウザと関連するＲＩＡが閉じられる場合、典型的には、提案した通知プロセスのみが要求される。関連のＲＩＡが再び開始した後は、ＲＩＡと関連のバックグラウンド・プロセスとの間、またはＲＩＡとＰＲＩＡマネージャ１０４との間のどちらかの間で継続する通信に対して、多くの代替的選択肢が可能であろう。
【００９０】
第一のステップ６：１では、特定のイベントの発生のため、バックグラウンド・プロセス３１２の処理が、関連のＲＩＡの通知を要求するポイントに到達した、即ち、ＲＩＡ通知トリガが起動された。一つの典型的なシナリオによれば、新しいデータの発生がバックグラウンド・プロセス３１２でＲＩＡ通知をトリガする可能性のあるような新しいデータのために、特定の第三パーティ・サーバ（図示せず）を獲得するよう、バックグラウンド・プロセス３１２を構成してもよい。通知トリガを認識することに応じて、バックグラウンド・プロセス３１２は、次のステップ６：２で示すように、バックグラウンド・プロセス・マネージャ１５１に通知を起動するよう要求し、ウェブブラウザおよび／または関連のＲＩＡが閉じられているということに気付いているＰＲＩＡマネージャ１０４は、次のステップ６：３において関連のＰＲＩＡマネージャ１０４に本通知を送信する。
【００９１】
通知を受信すると、ＰＲＩＡマネージャ１０４は通知手順を実行し、その結果、もう一つのステップ６：４で示すように、ＵＩ１０１を介して、それぞれのＰＡを変更する。一旦ＰＲＩＡマネージャ１０４が通知手順を実行したなら、もう一つのステップ６：５で示すように、説明したＰＲＩＡプロセスは、典型的には、ＰＲＩＡマネージャがユーザ承認を認識するまで開始しないであろう。そのような承認は、典型的には、変更したＰＡ上のユーザ・クリック動作によって実行される可能性がある。もしＲＰＣを適用するなら、ＰＡオブジェクトはバックグラウンド・プロセスで動作している可能性があり、このオブジェクトでの変更により、通知がトリガされ、ＰＲＩＡマネージャ１０４に送られるということになる。次に、ＰＲＩＡマネージャ１０４で、通知の内容を解釈し、その結果、ＰＡを変更するであろう。
【００９２】
また、ＲＰＣメカニズムに頼るもう一つの代わりの実施形態によれば、ＰＲＩＡマネージャ１０４では、バックグラウンド・プロセスのために全く事前にＰＡを定めなかった。代わりに、要求したＰＡ変更をＰＲＩＡマネージャから要求することができるというように起動される、事前に定めた対応する機能を備えるＰＲＩＡマネージャ１０４に、所定のＲＰＣコールを送信する。
【００９３】
ＲＥＳＴメカニズムを適用するなら適用可能である可能性のある、さらにもう一つの実施形態によれば、各ＰＡは、ＲＥＳＴリソースとして関連のバックグラウンド・プロセスからアクセス可能である。
【００９４】
ひとたびユーザが、それぞれのＲＩＡを再び開始することを継続するよう自分の承認を与えたなら、例えばそれぞれのＲＩＡを更新するための手順、ユーザがＰＲＩＡマネージャと相互に作用することを可能にするための手順、および／またはユーザがバックグラウンド・プロセスを開始する可能性にある通知と相互に作用することを可能にするための手順のような各種の形式の手順を開始する可能性がある。
【００９５】
一つの実施形態により、図６Ａを参照して上記で説明したもののような、成功した通知に続く可能性のある一連のステップを示す一つの典型的なシナリオについて、ここで、図６Ｂのシグナル伝達図を参照して以下に説明する。
【００９６】
図６Ｂのシグナル伝達図によれば、ステップ６：６および／または６：７で示すように、承認は、ウェブブラウザ１０２および／またはＲＩＡ１０３をＰＲＩＡマネージャ１０４が開始するという結果をもたらす。一旦、ウェブブラウザ１０２およびＲＩＡ１０３が動作すると、閲覧しているユーザは、バックグラウンド・プロセス３１２と相互に作用をすることにより、開始したＰＲＩＡプロセスを継続してもよい。図６Ｂによると、次のステップ６：８で示すように、相互作用がＲＩＡ／ウェブブラウザ１０３，１０２と関連のバックグラウンド・プロセス３１２との間で始まる。そのような相互作用は、もう一つのステップ６０９で示すように、バックグラウンド・プロセス３１２に新しいデータを検索するようＰＲＩＡマネージャ１０４に指示するという結果をもたらし、これにより、ＰＲＩＡマネージャ１０４は、次のステップ６：１０で示すように、サーバ４０１から新しいデータを検索し、その後で、ステップ６：１１で示すように、ＲＩＡ１０３を更新する可能性がある。次に、本相互作用は、もう一つのステップ６：１２で示すように、それぞれのＰＲＩＡ関連の指示により、継続してもよい。
【００９７】
また、既に上記に述べたように、インターネット使用可能ユーザ・デバイスのデバイス・インタフェースと相互に作用するよう、バックグラウンド・プロセスを構成してもよい。もしそのような通信を適用する予定なら、バックグラウンド・プロセスは、関連のＰＲＩＡと関係するまたは関係しない、一つ以上のタスクを実行してもよい。
【００９８】
ここで、図６Ｃのシグナル伝達図を参照して以下に説明するもう一つの代わりの実施形態によれば、ステップ６；６’および６：７’で示すように、ウェブブラウザ１０２およびＲＩＡ１０３の両方がオープン／動作状態であるが、残りのプロセスでは、バックグラウンド・プロセスは積極的には全くかかわる予定がない。代わりに、ＰＲＩＡマネージャ１０４は、再びウェブブラウザのＲＩＡ  ＵＲＬをオープンにし、それによって、ＲＩＡから開始した手順を開始可能とする。入力する処理ステップには、例えば、ＰＲＩＡマネージャ１０４の管理の下でインターネット使用可能ユーザ・デバイス１００に対して外部のサーバ４０１からデータを再ロードすることを含む可能性がある。再ロードしたデータには、例えば、関連のＰＲＩＡのために特定した、事前に定めた指示の集合を含む可能性がある。次に、ＲＩＡ１０３は、関連のバックグラウンド・プロセスと関係なく、獲得したデータを使用する可能性がある。次のステップ６：８’および６：９’でそのような手順を示す。
【００９９】
バックグラウンド・プロセスを生成し、管理し、終端するため、同様に通知と次の指示を管理するため、上記で説明したもののようなエンティティを使用する方法について、ここで、図７Ａ−図８Ｃをそれぞれ参照し、多くのフローチャートを参照して、以下に説明する。
【０１００】
図７Ａは、ＰＲＩＡマネージャが実行する、アプリケーション実行サーバでの新しいバックグラウンド・プロセスを開始する、または生成する方法、またはインターネット使用可能ユーザ・デバイスの対応する機能的エンティティに言及する。
【０１０１】
第一のステップ７００で、インターネット使用可能ユーザ・デバイスから、ＰＡを生成する要求を受信する。次のステップ７０１で示すように、要求の内容により、ユーザ・デバイスのＵＩにＰＡを設定することにより、そのような要求に応答する。次のステップ７０２で、関連のアプリケーション実行サーバに利用可能な任意のチャネルがあるかどうかを決定する。もしこれがその場合でないなら、次のステップ７０３においてそのような通信を確立する。次に、本要求の内容により、関連のバックグラウンド・プロセスを設定する要求を準備し、次に、次のステップ７０４によりアプリケーション実行サーバに本要求を送る。
【０１０２】
図７Ｂは、インターネット使用可能ユーザ・デバイスで通知プロセスを管理することにより、動作しているバックグラウンド・プロセスとインターネット使用可能ユーザ・デバイスとの間の通信を可能とするため、インターネット使用可能ユーザ・デバイスで実行する予定の典型的な方法のステップに言及する。
【０１０３】
第一のステップ７０５で、バックグラウンド・プロセスから通知を要求するメッセージを受信し、次のステップ７０６で、インターネット使用可能ユーザ・デバイスのＰＲＩＡマネージャは、関連のＰＡを介して通知を実行する。次に、ステップ７０７で示すように、ＰＲＩＡマネージャは、開始した相互作用プロセスを継続するための承認、即ち、本通知に対する応答を待ち、一旦承認さると、バックグラウンド・プロセスは本承認について通知を受け、次のステップ７０８で示すように、典型的には、一つ以上のメッセージで提供されるバックグラウンド・プロセスから指示を受信することにより、そして、その結果、そのような指示を実行することにより、本通知により開始したプロセスが開始する可能性がある。もしウェブブラウザおよび通知を受けたＲＩＡが動作状態であれば、ステップ７０７は無視される可能性があり、それ故、プロセスを開始した要求のイベントを直ちに開始するよう、ＰＲＩＡマネージャはバックグラウンド・プロセスに知らせる可能性がある。
【０１０４】
図７Ｃは、インターネット使用可能ユーザ・デバイスからバックグラウンド・プロセスを終端する予定である場合のインターネット使用可能ユーザ・デバイスで実行する予定の一連の方法のステップについて説明する、もう一つの典型的な手順に言及する。第一のステップ７０９で、次のステップ７１０およびもう一つの次のステップ７１１で示すように、ＰＡを除去することにより、典型的には、インターネット使用可能ユーザ・デバイスのＰＲＩＡマネージャが、応答する予定のＲＩＡから、ＰＡを除去する要求を受信し、このことは、関連するバックグラウンド・プロセスを終端するため、アプリケーション実行サーバを構成するということを示す。
【０１０５】
図８Ａ−図８Ｃは、バックグラウンド・プロセスをそれぞれ生成し、終端しまたは管理する予定の場合、アプリケーション実行サーバで実行する予定の、対応する方法のステップを示す。
【０１０６】
一つの実施形態により、新しいバックグラウンド・プロセスに対する要求を管理するステップを例示する図８Ａで、ステップ８００で示すように、最初にインターネット使用可能ユーザ・デバイスから提供されるメッセージで、新しいバックグラウンド・プロセスに対する要求を受信する。
【０１０７】
次のステップ８０１で、本メッセージの内容により、関連のバックグラウンド・プロセス・コードを獲得する。ひとたび、本関連のコードを獲得した場合、もう一つのステップ８０２に示すように、本要求により、それぞれのバックグラウンド・プロセスを起動できるというように、関連のコードを実行することにより、アプリケーション実行サーバは事前に定めた指示を実行する。
【０１０８】
図８Ｂは、一つの実施形態により、バックグラウンド・プロセスと、アプリケーション実行サーバが実行する予定のＲＩＡとの間の通信を可能とする方法のステップのもう一つの集合を示す。
【０１０９】
第一のステップ８０３で、アプリケーション実行サーバは、バックグラウンド・プロセスから通知に対するトリガを受信する。次のステップ８０４で、アプリケーション実行サーバは、通知に対する要求を備えるメッセージを準備し、ＲＩＡに接続するインターネット使用可能ユーザ・デバイスに本メッセージを送信する。次に、バックグラウンド・プロセスは、バックグラウンド・プロセスの指示により、それぞれのＲＩＡと開始した通信プロセスを継続するため、バックグラウンド・プロセスへの表示として考慮される予定の通知の承認を待つ。これは、ステップ８０５と参照されるループで示される。
【０１１０】
ひとたびアプリケーション実行サーバが承認を受信したなら、ステップ８０６で示すように、プロセスは開始してもよく、または、もっと言えば、バックグラウンド・プロセスのそれぞれの指示に依存して、終端してもよい。
【０１１１】
図８Ｃは、バックグラウンド・プロセスの要求された終端を実行するため、アプリケーション実行サーバで実行される可能性のある、典型的な方法のステップのもう一つの集合を示す、もう一つのシグナル伝達方式である。
【０１１２】
本例によれば、ステップ８０７で示すように、アプリケーション実行サーバでバックグラウンド・プロセス終端要求を最初に認識することにより、動作しているバックグラウンド・プロセスを終端する可能性がる。インターネット使用可能ユーザ・デバイスが認識した欠陥のある、または疑わしいコードに応答して、または、例えば、ひとたび要求されたプロセスを完了したなら、バックグラウンド・プロセスからトリガを受信することにより、対応するＰＡを介してユーザが入れたユーザ相互作用に応答して、ＲＩＡに接続したインターネット使用可能ユーザ・デバイスから、そのような要求を受信する可能性がある。ステップ８０８で示すように、アプリケーション実行サーバは、バックグラウンド・プロセスを終端することにより、そのような要求に応答する。
【０１１３】
この明細書を通して、“アプリケーション実行サーバ”、“バックグラウンド・プロセス・マネージャ”、“ＰＲＩＡマネージャ”、“サーバ・ネットワーク機能”および“クライアント・ネットワーク機能”のような、論理デバイス、エンティティまたはノードを表現するために使用する用語は、多くの代わりの方法で表現される可能性のある典型的表現としてのみ解釈されるべきである。
【０１１４】
加えて、説明した装置および方法のステップについて、特定の典型的な実施形態を参照して説明したが、本説明は、一般的には、説明した本発明の概念を示すことにのみ意図しており、添付の特許請求範囲が定めたものの範囲を制限するものとして受け取られるべきではない。
【０１１５】
＜略語＞
Ｄ−ＢＵＳ        デスクトップ・バス
ＨＴＭＬ          ハイパーテキスト・マークアップ言語
ＨＴＴＰ          ハイパーテキスト転送プロトコル
ＪＳＯＮ          ジャバスクリプト・オブジェクト表現法
ＮＰＡＰＩ        ネットスケープ・プラグイン・アプリケーション・プログラミング・
インタフェース
ＰＡ              パーセプティブル・アーチファクト
ＰＲＴＡ          持続的リッチ・インターネット・アプリケーション
ＲＥＳＴ          レプレゼンテーショナル・ステート・トランスファ
ＲＩＡ            リッチ・インターネット・アプリケーション
ＲＰＣ            リモート・プロシージャ・コール
ＳＭＳ            ショート・メッセージ・サービス
ＵＲＬ            ユニフォーム・リソース・ロケータ
ＸＭＬ            拡張マークアップ言語
【図１】
0005535324.tif 000002
【図２Ａ】
0005535324.tif 000003
【図２Ｂ】
0005535324.tif 000004
【図３】
0005535324.tif 000005
【図４】
0005535324.tif 000006
【図５】
0005535324.tif 000007
【図６Ａ】
0005535324.tif 000008
【図６Ｂ】
0005535324.tif 000009
【図６Ｃ】
0005535324.tif 000010
【図７Ａ】
0005535324.tif 000011
【図７Ｂ】
0005535324.tif 000012
【図７Ｃ】
0005535324.tif 000013
【図８Ａ】
0005535324.tif 000014
【図８Ｂ】
0005535324.tif 000015
【図８Ｃ】
0005535324.tif 000016