JP2016504694A - ハイブリッドアプリケーションのためのリソース呼び出し - Google Patents

Abstract

【課題】【解決手段】リソースの呼び出しが提供されており、以下を含む：ページ要求メッセージをサーバに送信すること；ページ要求メッセージに応答してサーバによって送り返されたページデータを受信すること；ページデータを解析して、リソースのアドレスを取得すること；リソースのアドレスを用いてリソース呼び出し要求を生成すること；アプリケーションクライアントのネイティブバージョン情報を取得すること；アプリケーションクライアントのネイティブバージョン情報を用いて、リソース呼び出し要求を修正すること；ならびに、修正されたリソース呼び出し要求に従ってリソースを取得すること。【選択図】図２

Description

他の出願の相互参照
本願は、２０１３年１月２３日出願の中国特許出願第２０１３１００２４４６０．３ 号「Ａ ＲＥＳＯＵＲＣＥ−ＣＡＬＬＩＮＧ ＭＥＴＨＯＤ， ＣＬＩＥＮＴ， ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＨＹＢＲＩＤ−ＡＰＰＬＩＣＡＴＩＯＮ ＣＬＩＥＮＴＳ」の優先権を主張する。当該出願は、すべての目的のために参照により本明細書に組み込まれる。

本願は、インターネット技術の分野に関し、特に、ハイブリッドアプリケーション・クライアントのためのリソース呼び出し方法、クライアント、および、システムに関する。

ハイブリッドアプリケーション・クライアントは、ネイティブアプリケーション・クライアントネイティブアプリケーション・クライアントおよびウェブアプリケーション・クライアントェブアプリケーション・クライアントの両方の利点を有するので、現在では、携帯端末で広く利用されている。ハイブリッドアプリケーション・クライアントは、スマートフォンなどの携帯端末で動作するネイティブアプリケーションに見えるが、サーバによって提供されるウェブページにアクセスする。

図１は、ハイブリッドアプリケーション・クライアントが従来のシステムでユーザにサービスを提供する処理を示すフローチャートである。

工程１０１で、ハイブリッドアプリケーション・クライアントは、所定のユニバーサル・リソースロケータ（ＵＲＬ）を用いて、そのＵＲＬを含むハイパーテキスト・トランスポートプロトコル（ＨＴＴＰ）要求をサーバに送信する。換言すると、ハイブリッドアプリケーション・クライアントは、所定のＵＲＬに対応するページにアクセスする。

工程１０２で、サーバは、ハイパーテキスト・マークアップランゲージ（ＨＴＭＬ）コード（例えば、ＨＴＭＬ５コード）を、ハイブリッドアプリケーション・クライアントに送り返す。

工程１０３で、ハイブリッドアプリケーション・クライアントは、ＨＴＭＬコードを解析して、ＨＴＭＬコードが呼び出そうとしているＪａｖａＳｃｒｉｐｔ（登録商標、以下同じ）ファイルまたはカスケーディングスタイルシート（ＣＳＳ）ファイルを決定する。具体的には、ＨＴＭＬコードは、呼び出しのためのＪａｖａＳｃｒｉｐｔ識別子またはＣＳＳ識別子を含む。その識別子は、呼び出されるＪａｖａＳｃｒｉｐｔまたはＣＳＳを特定するために用いられる。

工程１０４で、ハイブリッドアプリケーション・クライアントは、呼び出されるＪａｖａＳｃｒｉｐｔまたはＣＳＳをサーバから取得する。

工程１０５で、ハイブリッドアプリケーション・クライアントは、取得したＪａｖａＳｃｒｉｐｔまたはＣＳＳを用いて、クライアントにネイティブなアプリケーションプログラミング・インターフェース（ＡＰＩ）を呼び出す。

工程１０６で、ハイブリッドアプリケーション・クライアントは、呼び出したＡＰＩを用いて、自身が位置する携帯端末の適切な機能を起動する。

携帯端末の機能は、単に１つのＪａｖａＳｃｒｉｐｔまたはＣＳＳだけでは有効化できないので、ハイブリッドアプリケーション・クライアントによってネイティブに保存されたＡＰＩが、これらの機能を有効化するために必要である。したがって、ハイブリッドアプリケーション・クライアントは、それが位置する携帯端末の適切な機能を有効化するために、ＨＴＭＬコードに基づいてＪａｖａＳｃｒｉｐｔまたはＣＳＳを取得した後に、取得したＪａｖａＳｃｒｉｐｔまたはＣＳＳを用いてネイティブＡＰＩを呼び出さなければならない。

例えば、ハイブリッドアプリケーション・クライアントは、カメラ機能（対応するリソースを有する）を提供し、すなわち、サーバに保存されたＪａｖａＳｃｒｉｐｔファイルは、ｐｈｏｔｏＶ２．０．ｊｓである。このファイルは、ピクセルサイズ、１クリックで撮ることができる写真の最大数など、オンボードカメラに関連するパラメータを提供する。ハイブリッドアプリケーション・クライアントに保存されたＡＰＩファイルは、ｐｈｏｔｏＶ２．０．ｊａｒである。したがって、ハイブリッドアプリケーション・クライアントは、まず、サーバページにアクセスして、サーバによって送り返されたＨＴＭＬ５コードが呼び出そうとしているＪａｖａＳｃｒｉｐｔファイルがｐｈｏｔｏＶ２．０．ｊｓであると決定し、したがって、サーバからｐｈｏｔｏＶ２．０．ｊｓを取得し、ｐｈｏｔｏＶ２．０．ｊｓを用いて自身のＪａｖａ（登録商標）関数ｐｈｏｔｏＶ２．０．ｊａｒを呼び出して、ハイブリッドアプリケーションが位置する携帯端末のカメラを有効化する。

ハイブリッドアプリケーションによって正常なサービスを提供するには、ハイブリッドアプリケーション・クライアントのバージョンが、サーバのバージョンと同じであるべきである。ハイブリッドアプリケーション・クライアントのバージョンがサーバのバージョンと異なる場合、ハイブリッドアプリケーション・クライアントは、通例、サービスを正常に提供できなくなる。

例えば、ハイブリッドアプリケーション・クライアントは、カメラ写真撮影機能を提供する。ハイブリッドアプリケーション・クライアントのバージョンがＶ１．０であれば、ハイブリッドアプリケーション・クライアントに保存されたＡＰＩは、ｐｈｏｔｏＶ１．０．ｊａｒである（ハイブリッドアプリケーション・クライアントに保存されたＡＰＩのバージョンは、ハイブリッドアプリケーション・クライアント自身のバージョンと同じである）。サーバのバージョンがＶ２．０である場合、サーバに保存されたＪａｖａＳｃｒｉｐｔは、ｐｈｏｔｏＶ２．０．ｊｓである。したがって、サーバによってハイブリッドアプリケーション・クライアントに送り返されたＨＴＭＬ５コードによって呼び出されるＪａｖａＳｃｒｉｐｔは、ｐｈｏｔｏＶ２．０．ｊｓである。ハイブリッドアプリケーション・クライアントがｐｈｏｔｏＶ２．０．ｊｓを取得した後、ｐｈｏｔｏＶ２．０．ｊｓは、同じバージョンＶ２．０のＡＰＩ（すなわち、ｐｈｏｔｏＶ２．０．ｊａｒ）しか呼び出せないので、ハイブリッドアプリケーション・クライアントに保存されているバージョンは、Ｖ１．０のＡＰＩ（すなわち、ｐｈｏｔｏＶ１．０．ｊａｒ）である。結果として、ハイブリッドアプリケーション・クライアントは、ｐｈｏｔｏＶ２．０．ｊｓによって、対応するバージョン（Ｖ２．０）のＡＰＩを取得できないため、カメラ写真撮影機能を正常に提供できない。

すべてのユーザが自分の携帯端末にインストールされたハイブリッドアプリケーション・クライアントをすぐに更新するわけではない。したがって、既存のシステムにおいて、ハイブリッドアプリケーション・クライアントおよびサーバが異なるバージョンを有する場合にハイブリッドアプリケーション・クライアントがサービスを正常に提供できないという先述の問題を解決するために、ハイブリッドアプリケーション・クライアントは、自身の現行バージョンのもとでネイティブにすべてのＡＰＩのＪａｖａＳｃｒｉｐｔまたはＣＳＳ（ＪａｖａＳｃｒｉｐｔおよびＣＳＳは、以下では集合的に「現行リソース」と呼ぶ）を保存できる。ハイブリッドアプリケーション・クライアントは、サーバによって送り返されたＨＴＭＬコードを受信すると、ＨＴＭＬコードによって呼び出される現行リソースのバージョンがハイブリッドアプリケーションのネイティブバージョンと一致しないと判定した場合、ＨＴＭＬコード内の呼び出される現行リソースの識別子を、ネイティブに保存されたバージョンの現行リソースの識別子に置き換え、現行リソースの識別子が置き換えられた後にＨＴＭＬコードを解析し、置き換えられた現行リソースを呼び出して、対応する機能を実現する。

例えば、ハイブリッドアプリケーション・クライアントは、カメラ写真撮影機能を提供する。ハイブリッドアプリケーション・クライアントのバージョンがＶ１．０であるので、ハイブリッドアプリケーション・クライアントに保存されたＡＰＩは、ｐｈｏｔｏＶ１．０．ｊａｒである。さらに、現行リソース（ＪａｖａＳｃｒｉｐｔ）ｐｈｏｔｏＶ１．０．ｊｓは、ｐｈｏｔｏＶ１．０．ｊａｒを呼び出すことができ、ハイブリッドアプリケーション・クライアントに保存される。サーバのバージョンはＶ２．０であり、サーバに保存されたＪａｖａＳｃｒｉｐｔファイルは、ｐｈｏｔｏＶ２．０．ｊｓである。

したがって、サーバによってハイブリッドアプリケーション・クライアントに送り返されたＨＴＭＬコードによって呼び出されるＪａｖａＳｃｒｉｐｔファイルは、ｐｈｏｔｏＶ２．０．ｊｓである。ハイブリッドアプリケーション・クライアントは、ＨＴＭＬコードに含まれるＪａｖａＳｃｒｉｐｔ識別子がｐｈｏｔｏＶ２．０．ｊｓであると判定した場合、ネイティブに保存されたｐｈｏｔｏＶ１．０．ｊｓ識別子（ｐｈｏｔｏＶ２．０．ｊｓに対応するが、バージョンは異なる）をＨＴＭＬコード内のｐｈｏｔｏＶ２．０．ｊｓ識別子の代わりにする。次いで、ＨＴＭＬコードを解析し、置き換えられた識別子（ｐｈｏｔｏＶ１．０．ｊｓの識別子）に基づいて、ネイティブに保存されたｐｈｏｔｏＶ１．０．ｊｓを呼び出す。ハイブリッドアプリケーション・クライアントは、サーバからリソースを取得しない。最後に、ハイブリッドアプリケーション・クライアントは、携帯端末のカメラ機能を有効化するために、ｐｈｏｔｏＶ１．０．ｊｓを用いて、ネイティブに保存されたｐｈｏｔｏＶ１．０．ｊａｒを呼び出す。

しかしながら、既存のスキームでは、ハイブリッドアプリケーション・クライアントは、サーバによって送り返されたＨＴＭＬコード内のｐｈｏｔｏＶ２．０．ｊｓ識別子の代わりに、自身が保存したｐｈｏｔｏＶ１．０．ｊｓの識別子を使う必要がある。これにより、ＨＴＭＬコードの元の構造が変わる。ＨＴＭＬコードがＨＴＭＬ５である場合、この代用は、ＨＴＭＬ５コード自身のアプリケーションキャッシュ機能を無効化するため、後続のウェブページがＨＴＭＬコードに基づいてロードされる時に起こりうるエラーを引き起こす。

以下の詳細な説明と添付の図面において、本発明の様々な実施形態を開示する。

ハイブリッドアプリケーション・クライアントが従来のシステムでユーザにサービスを提供する処理を示すフローチャート。

アプリケーションクライアントがサーバとデータを交換するための処理の一実施形態を示すフローチャート。

２つのアプリケーションクライアントを備えたシステムの一実施形態を示す図。

２つのアプリケーションクライアントを備えたシステムの別の実施形態を示す図。

本願の一実施形態によって提供されるハイブリッドアプリケーション・クライアントを示す構造図。

本願に従ったリソース呼び出しシステムの一実施形態を示すシステム図。

いくつかの実施形態に従って、リソース呼び出しを実行するためにプログラムされたコンピュータシステムを示す機能図。

本発明は、処理、装置、システム、物質の組成、コンピュータ読み取り可能な格納媒体上に具現化されたコンピュータプログラム製品、および／または、プロセッサ（プロセッサに接続されたメモリに格納および／またはそのメモリによって提供される命令を実行するよう構成されたプロセッサ）を含め、様々な形態で実装されうる。本明細書では、これらの実装または本発明が取りうる任意の他の形態を、技術と呼ぶ。一般に、開示された処理の工程の順序は、本発明の範囲内で変更されてもよい。特に言及しない限り、タスクを実行するよう構成されるものとして記載されたプロセッサまたはメモリなどの構成要素は、ある時間にタスクを実行するよう一時的に構成された一般的な構成要素として、または、タスクを実行するよう製造された特定の構成要素として実装されてよい。本明細書では、「プロセッサ」という用語は、１または複数のデバイス、回路、および／または、コンピュータプログラム命令などのデータを処理するよう構成された処理コアを指すものとする。

以下では、本発明の原理を示す図面を参照しつつ、本発明の１または複数の実施形態の詳細な説明を行う。本発明は、かかる実施形態に関連して説明されているが、どの実施形態にも限定されない。本発明の範囲は、特許請求の範囲によってのみ限定されるものであり、多くの代替物、変形物、および、等価物を含む。以下の説明では、本発明の完全な理解を提供するために、多くの具体的な詳細事項が記載されている。これらの詳細事項は、例示を目的としたものであり、本発明は、これらの具体的な詳細事項の一部または全てがなくとも特許請求の範囲に従って実施可能である。簡単のために、本発明に関連する技術分野で周知の技術事項については、本発明が必要以上にわかりにくくならないように、詳細には説明していない。

ハイブリッドアプリケーション・クライアントとは、コンピュータシステム（例えば、スマートフォン、タブレット、ラップトップ、ウェアラブルデバイスなど）上で動作するネイティブアプリケーションであるように見え、機能を提供する過程でサーバによって提供されたウェブページにアクセスする非ブラウザアプリケーションのことである。いくつかの実施形態において、サーバがアプリケーションクライアントに送信するページデータは、呼び出される必要のあるリソースのアドレス（例えば、ＪａｖａＳｃｒｉｐｔファイルまたはＣＳＳドキュメントの位置）を含む。ページデータは解析され、リソース呼び出し要求が生成される。リソース呼び出し要求は、アプリケーションクライアントのネイティブバージョン情報に従って修正される。修正されたリソース呼び出し要求は、リソースを取得するために用いられる。アプリケーションクライアントおよびサーバが、異なるバージョンを有する場合に、この技術は、アプリケーションクライアントがページデータを修正することなしに正常にサービスを提供することを可能にし、したがって、ページデータに基づいて後続のウェブページを正常にロードできることを保証する。

以下では、図面を参照しつつ本願の実施形態の詳細な説明を提供する。

図２は、アプリケーションクライアントがサーバとデータを交換するための処理の一実施形態を示すフローチャートである。処理２００は、ハイブリッドアプリケーション・クライアント（図７の７００など）によって実行される。

工程２０１で、ページ要求メッセージが、サーバに送信される。

クライアントアプリケーションがサーバと通信するには、様々な方法がある。いくつかの実施形態において、ハイブリッドアプリケーション・クライアントは、オペレーティングシステムによって提供されたウェブページレンダリング機能（例えば、Ａｎｄｒｏｉｄ（商標）によって提供されたＷｅｂＶｉｅｗ）を介してシステムと通信する。いくつかの実施形態において、ハイブリッドアプリケーション・クライアントは、ブラウザ関数を実装するライブラリおよび／またはＡＰＩを呼び出すコードを含む。説明のために、これらの異なる実装のウェブブラウザ関数は、集合的にプラグインと呼ぶこととする。クライアントがサービスを提供する時、クライアントのプラグインは、まず、所定のＵＲＬに基づいて、ページ要求メッセージをサーバに送信する。そのメッセージは、ＵＲＬに対応するウェブページをサーバから取得するために用いられる。サーバは、ネットワークサーバである。ページ要求メッセージは、ＨＴＴＰ要求メッセージを含む。

工程２０２で、ページ要求メッセージに応答してサーバによって送り返されたページデータが受信される。

サーバは、ページ要求メッセージを受信した後、ページ要求メッセージに含まれるＵＲＬに対応するウェブページのページデータをクライアントに送り返す。

ページ固有の機能を実現するために、ページデータは、呼び出されるリソースに関する情報を含む。かかる情報の一例は、リソースのアドレスであり、クライアント上のネイティブアドレスとして（例えば、ファイルディレクトリ位置として）表現されうる。リソースは、固有のネイティブ機能（例えば、写真撮影機能および音声対応機能を実装するコード／ライブラリ）を実行するために必要なサポートリソース（フロントエンドリソースとも呼ばれる）を含む。

本願のいくつかの実施形態において、このアドレスは、リソース名およびバージョンプレースホルダを含む。

この例において、サーバによって送り返されるページデータは、ＨＴＭＬコードである。ＨＴＭＬコードに含まれるアドレスは、ソースアドレス（ソースパスとも呼ばれる）であってよい。ＨＴＭＬコードは、ＨＴＭＬ５コードであってよい。

例えば、サーバは、所定のプロトコルに従って、ＨＴＭＬコードを送り返すことができる。返されたＨＴＭＬコードは、以下のようにフォーマットされている：
＜ｈｔｍｌ＞
＜ｂｏｄｙ＞ｓｅｒｖｉｃｅ ｃｏｄｅ＜／ｂｏｄｙ＞
＜ｓｃｒｉｐｔ ｔｙｐｅ＝”ｔｅｘｔ／ｊａｖａｓｃｒｉｐｔ”ｓｒｃ＝”ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ：５００００／ｐｈｏｔｏ＄｛ＶＥＲＳＩＯＮ｝．ｊｓ”＞＜／ｓｃｒｉｐｔ＞
＜／ｈｔｍｌ＞

上述のＨＴＭＬコードは、ソースパス（すなわち、ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ：５００００／ｐｈｏｔｏ＄｛ＶＥＲＳＩＯＮ｝．ｊｓ）を含む。このパスは、上述のＨＴＭＬコードによって呼び出されるリソースを取得するために用いられる（この例では、リソースはＪａｖａＳｃｒｉｐｔファイルである）。ソースパスは、ＵＲＬの形態で構成されており、ここで、「ｌｏｃａｌｈｏｓｔ：５００００」はクライアントのネイティブポート番号を表し、「ｐｈｏｔｏ」はリソース名であり、「＄｛ＶＥＲＳＩＯＮ｝」は、バージョンプレースホルダである。ソースパスのフォーマットは、別の実施形態では異なってもよく、クライアント／サーバアプリケーションの開発者によって定義されうる。

工程２０３で、ページデータは解析され、呼び出される必要のあるリソースのアドレスが取得され、リソース呼び出し要求が生成される。

上記の例を続けると、クライアントが、そのプラグインを介して先述のページデータを受信した後に、ページデータが解析される。解析は、＜ｓｃｒｉｐｔ ｔｙｐｅ＝”ｔｅｘｔ／ｊａｖａｓｃｒｉｐｔ”ｓｒｃ＝”ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ：５００００／ｐｈｏｔｏ＄｛ＶＥＲＳＩＯＮ｝．ｊｓ”＞＜／ｓｃｒｉｐｔ＞を見いだし、これは、上述のＨＴＭＬコードが呼び出すリソースを、上述のアドレス（すなわち、“ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ：５００００／ｐｈｏｔｏ＄｛ＶＥＲＳＩＯＮ｝．ｊｓ”というソースパス）から取得する必要があることを意味する。したがって、クライアントのプラグインは、リソース呼び出し要求を生成し、上記のアドレスに送信する。この要求は、このアドレスから呼び出される必要のあるリソースを取得するために用いられる。このリソース呼び出し要求は、上述のアドレスを含む。このリソース呼び出し要求は、「ＧＥＴ ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ：５００００／ｐｈｏｔｏ＄｛ＶＥＲＳＩＯＮ｝．ｊｓ」などのＨＴＴＰ要求メッセージを含んでもよい。

工程２０４で、ネイティブバージョン情報が取得され、ネイティブバージョン情報は、リソース呼び出し要求を修正する基礎として用いられる。本明細書で用いられているように、ネイティブバージョン情報とは、クライアントデバイス上に現れた時のアプリケーションクライアントのバージョン情報のことである。いくつかの実施形態において、アプリケーションクライアントは、ネイティブバージョン情報を取得するためのＡＰＩまたは関数呼び出しを含む。ネイティブバージョン情報は、構成ファイルまたはレジストリを読み出すことにより、もしくは、任意の他の適切な技術により、取得することができる。

いくつかの実施形態では、組み込みモジュールが、ハイブリッドアプリケーション・クライアントに含まれる。組み込みモジュールは、リソース呼び出し要求を監視および受信するよう構成されたコードを含んでおり、１または複数の処理、ルーチン、関数、ライブラリ、クラス、および／または、その他の適切なプログラミングコードを用いて実装される。上記の例を続けると、クライアントが、上記のアドレスｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ：５００００／ｐｈｏｔｏ＄｛ＶＥＲＳＩＯＮ｝．ｊｓにリソース呼び出し要求を送信する時、上記アドレス内のポート「ｌｏｃａｌｈｏｓｔ：５００００」は、クライアントのネイティブポートを示す。したがって、リソース呼び出し要求は、クライアント自体によって受信される。具体的には、クライアント内の組み込みモジュールが、ポート番号５００００を有するクライアントのネイティブポートを監視し、リソース呼び出し要求を受信する。ポート番号は、事前にサーバと合意したものであってよく、任意の適切な番号でありうる。

いくつかの実施形態において、各アプリケーションクライアントは、初期化時に登録を行う。例えば、初期化後に、アプリケーションクライアントは、アドレス”ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ：５００００”にＨＴＴＰ ＧＥＴ要求を行うことができ、ここで、その要求は、アプリケーションクライアントの名称、クライアントおよびそのリソースのネイティブバージョン情報、ならびに、任意のその他の適切な情報を指定する所定のフィールドを含む。ポートを監視する組み込みモジュールは、登録情報を受信し、後のアプリケーションクライアントの登録情報を記録し、必要に応じて応答する。組み込みモジュールからの応答の成功は、組み込みモジュールがすでに実行中であり、別の組み込みモジュールを起動する必要なしに直接利用できるということを、アプリケーションクライアントに対して示している。

組み込みモジュールは、リソース呼び出し要求を受信した後、リソース呼び出し要求を用いて、どのリソースが呼び出されるのかを学習するために用いる。組み込みモジュールは、さらに、現行ネイティブバージョン情報を用いて、受信したリソース呼び出し要求を修正する。いくつかの実施形態において、組み込みモジュールは、クライアントのネイティブバージョン情報を取得して、リソース呼び出し要求に書き込む。

この例において、リソース呼び出し要求は、呼び出される必要のあるリソースのアドレスを含み、このリソースアドレスは、リソース名およびバージョンプレースホルダを含むので、リソース呼び出し要求は、リソースの名称およびバージョンプレースホルダも含む。リソース呼び出し要求の一例は、「ＨＴＴＰ ＧＥＴ ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ：５００００／ｐｈｏｔｏ＄｛ＶＥＲＳＩＯＮ｝．ｊｓ」である。したがって、クライアントの組み込みモジュールは、リソース呼び出し要求に含まれるバージョンプレースホルダの代わりに、獲得したクライアントのネイティブバージョン情報を用いる。

クライアントの現行バージョンがＶ１．０であると仮定すると、リソース呼び出し要求に含まれるリソースアドレスは、バージョンプレースホルダがＶ１．０で置き換えられた後に以下のようになる：「ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ：５００００／ｐｈｏｔｏＶ１．０．ｊｓ」。したがって、求められるリソース「ｐｈｏｔｏＶ１．０．ｊｓ」が、このアドレスに少なくとも部分的に基づいて取得されうる。

さらに、上述のバージョンプレースホルダは、さらに、呼び出されるリソースを制限リソースとして特定するために用いることができる。制限リソースとは、バージョン制限を伴うリソースのことである。リソース呼び出し要求に含まれるリソースバージョン情報がクライアントのネイティブバージョン情報と異なる場合、リソース呼び出し要求は、リソースが制限リソースであれば、そのリソースを呼び出すことができない。いくつかの実施形態において、アプリケーションクライアントは、デバイス上に保持されたリストに従って、リソースが制限リソースであるか否かを判定する。したがって、いくつかの実施形態において、リソース呼び出し要求の監視は、リソース呼び出し要求がバージョンプレースホルダを含むか否かを評価すること、そして、リソース呼び出し要求がバージョンプレースホルダを含む場合に、バージョンプレースホルダをクライアントのネイティブバージョン情報で置き換えることを含む。

工程２０５で、リソースが、修正されたリソース呼び出し要求に従って取得される。

上記の例を続けると、修正されたリソース呼び出し要求に含まれるリソースアドレスは「ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ：５００００／ｐｈｏｔｏＶ１．０．ｊｓ」であるので、クライアントの組み込みモジュールは、修正されたアドレスを用いて、ｐｈｏｔｏＶ１．０．ｊｓを取得する。修正されたアドレスに従ってリソースを取得する場合、クライアントの組み込みモジュールは、修正されたアドレスに含まれるリソース名（上記の例の「ｐｈｏｔｏ」など）およびクライアントの現行ネイティブバージョン情報（上記の例のＶ１．０など）に基づいて、クライアントからネイティブに適切なリソース（上記の例のｐｈｏｔｏＶ１．０．ｊｓなど）を取得できる。いくつかの実施形態において、組み込みモジュールは、事前設定された位置（「／／ｃｌｉｅｎｔ／ｒｅｓｏｕｒｃｅｓ」など）でリソースを探すよう構成される。したがって、組み込みモジュールは、「／／ｃｌｉｅｎｔ／ｒｅｓｏｕｒｃｅｓ／ｐｈｏｔｏ／Ｖ１．０」というパスでリソースファイルを探す。

いくつかの実施形態において、サーバによってクライアントに送り返されたＨＴＭＬコードに含まれるリソースのアドレスは、呼び出されるリソースの名称およびバージョンプレースホルダに加えて、サーバに格納された様々なリソースの１または複数の格納位置（例えば、＜ｓｃｒｉｐｔ ｔｙｐｅ＝”ｔｅｘｔ／ｊａｖａｓｃｒｉｐｔ”ｓｒｃ＝”ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ：５００００／ｐｈｏｔｏ＄｛ＶＥＲＳＩＯＮ｝．ｊｓ”ｓｅｒｖｅｒｐａｔｈ＝”／／ｓｅｒｖｅｒ／ｒｅｓｏｕｒｃｅｓ”＞＜／ｓｃｒｉｐｔ＞）を含む。クライアントが、対応するリソースをネイティブに保存していないために、リソースがクライアント上で見つからない場合、対応するリソースｐｈｏｔｏＶ１．０．ｊｓは、修正されたアドレスに含まれるサーバ上でリソースを格納するために用いられている格納位置（例えば、「／／ｓｅｒｖｅｒ／ｒｅｓｏｕｒｃｅｓ／ｐｈｏｔｏ／Ｖ１．０」）に従って、サーバから取得される。サーバから取得されたリソースは、他の呼び出し元による将来のアクセスに備えて、クライアントにネイティブに保存される。

クライアントの組み込みモジュールがクライアントまたはサーバのいずれかからリソース「ｐｈｏｔｏＶ１．０．ｊｓ」を取得した後、クライアントは、プラグインがリソース内の関数を呼び出すために、リソースｐｈｏｔｏＶ１．０．ｊｓをプラグインに送信する。

いくつかの実施形態では、制限リソース（すなわち、バージョン制限を持つリソース）が、クライアント側にパッケージされてよく、サーバによって送り返されたページデータは、制限リソースに関するバージョン情報を指定しない。むしろ、バージョンプレースホルダが、ページデータ内に設定される。クライアントはページデータを解析し、組み込みモジュールはリソース呼び出し要求を監視する。バーションプレースホルダを含むリソース呼び出し要求は、リソース呼び出し要求によって呼び出されるリソースが制限リソースであることを示す。組み込みモジュールは、クライアントのネイティブバージョン情報を取得し、リソース呼び出し要求内のバージョンプレースホルダの代わりに、クライアントのネイティブバージョン情報を用いる。

上述の技術を用いることにより、クライアントは、ページデータを受信した後にページデータを修正する必要がない。その代わり、ページデータを解析した後、アプリケーションクライアントは、ページデータに含まれるアドレスに基づいてリソース呼び出し要求を生成し、その要求を送信する。このアドレスはクライアントのネイティブアドレスなので、リソース呼び出し要求は、クライアントの組み込みモジュールによって監視および受信できる。組み込みモジュールは、受信したリソース呼び出し要求に含まれるバージョンプレースホルダを修正する。すなわち、クライアントが修正するものは、ページデータの解析後に受信および送信するリソース呼び出し要求であり、ページデータ自体ではない。クライアントおよびサーバが、異なるバージョンのリソースを有する時に、クライアントは、ページデータを修正する必要なしに、クライアントの現行バージョンに適合するリソースを呼び出すことができる。次いで、クライアントは、サービスを正常に提供し、ページデータは修正されていないので、そのページデータに基づいて、将来、ウェブページが正常にプラグインによってロードされうる。

さらに、既存のシステムにおいて、クライアントは、サーバによって送り返されたＨＴＭＬコードを修正し、その後、クライアント自身のプラグインを用いて修正済みのＨＴＭＬコードをロードする必要がある。結果として、ページがロードされる方法（ページのローディングモードとも呼ばれる）も修正される。さらに、サーバのＵＲＬアドレスでの直接ローディングと対比して、修正されたＨＴＭＬコードは、リソースをロードするための要求の単一性を損なう（例えば、元々のＨＴＭＬコードはサーバに由来し、パス「ｈｔｔｐ：／／ｐｒｏｔｏｃｏｌ」を有するが、修正されたＨＴＭＬコードはクライアント自体に由来し、パス「ｆｉｌｅ：／／ｐｒｏｔｏｃｏｌ」を有する）。ローディングモードにおけるかかる変更は、ＨＴＭＬ５標準アプリケーションキャッシュおよびその他の機能を利用できなくする。しかしながら、処理２００と同様の処理が実行された場合、クライアントがサーバによって送り返されたページデータを修正しないので、ページデータソースの単一性は損なわれない。ページデータがＨＴＭＬコードを含む場合に、クライアントアプリケーションは、ローディングモードに関するＨＴＭＬ５標準の厳格な要件に関係する機能を損なうことがない。

さらに、上述の技術を用いると、サーバは、クライアントの現行バージョンがサーバのバージョンと一致するか否かを知る必要がない。すなわち、クライアントのバージョン情報は、サーバに対してトランスペアレントである。クライアントおよびサーバが異なるバージョンを有する場合でも、クライアントは、上述の処理２００を実行して、リソースを呼び出し、ページ内で機能を実現することができる。

本願の実施形態において、携帯端末は、複数のアプリケーションクライアントをインストールされてよい。上述したような組み込みモジュールが、インストールされた各アプリケーションクライアントに追加されてよい。いくつかの実施形態において、組み込みモジュールは、１または複数の他のアプリケーションクライアントプロセスと通信するプロセスとして実装される。携帯端末への負荷を軽減するために、１つのアプリケーションクライアントが自身の組み込みモジュールを有効化した場合に、この組み込みモジュールは、自身のリソース呼び出し要求を処理するのに加えて、他のアプリケーションクライアントに対するリソース呼び出し要求を処理できる。

いくつかの実施形態では、少なくとも第１のアプリケーションクライアントおよび第２のアプリケーションクライアントが、組み込みモジュールを共有する。以下の説明では、第１のアプリケーションクライアントが、第２のアプリケーションクライアントの前に起動されると仮定する。したがって、第１のアプリケーションクライアントの組み込みモジュールが有効化されている場合、第２のアプリケーションクライアントは、第１のアプリケーションクライアントの有効化された組み込みモジュールを用いてリソースを呼び出すことができる。

上述のように、いくつかの実施形態において、各アプリケーションクライアントは、初期化時に登録情報を指定ポートに送信する。第１のアプリケーションクライアントは、第２のクライアントによって送信された登録情報を受信し、登録情報に含まれる第２のアプリケーションクライアントの現行バージョンを保存する。続いて、第２のアプリケーションクライアントによって送信されたリソース呼び出し要求を受信した後、第１のアプリケーションクライアントは、リソース呼び出し要求内のアドレスに含まれるバージョンプレースホルダを、第２のアプリケーションクライアントの保存済みの現行バージョンに修正し、修正したリソース呼び出し要求に含まれるアドレスを用いて、対応するリソースを取得し、取得したリソースを第２のクライアントに送り返す。

第２のアプリケーションクライアントは、処理２００を用いてサーバとのやり取りを行う時、第２のアプリケーションクライアント自身のプラグインを用いて工程２０１から２０３を実行し、現在の携帯端末が、有効化された組み込みモジュールを備えた別のアプリケーションクライアントを有するか否かを評価してよい。第２のアプリケーションクライアントは、特定の時間内に組み込みモジュールからの応答の受信に成功し、第１のアプリケーションクライアントの組み込みモジュールがすでに有効化されていると判定した場合、第１のクライアント内で有効化された組み込みモジュールを用いて、リソース呼び出しを実行する。第１のクライアントの組み込みモジュールによって受信されたリソース呼び出し要求が、第２のクライアントの識別子を含む場合、第１のクライアントは、このリソース呼び出し要求が第２のクライアントによって送信されたと判定できる。したがって、図３に示すように、第１のクライアントは、適切なリソースを取得した後、第２のクライアントのプラグインにリソースを送り返す。

図３は、２つのアプリケーションクライアントを備えたシステムの一実施形態を示す図である。この例では、第２のアプリケーションクライアントが、登録情報を第１のアプリケーションクライアントに送信する。図３において、第２のアプリケーションクライアントは、第２のアプリケーションクライアントの現行バージョン情報および第２のクライアントの識別子を含む登録情報を第１のアプリケーションクライアントに送信するために、「ハートビート」アプローチを用いる。すなわち、第２のアプリケーションクライアントは、第１のアプリケーションクライアントに登録情報を定期的に送信する。具体的には、第２のアプリケーションクライアントは、以下のメッセージを用いて登録情報を送信する：

ＨＴＴＰ ＧＥＴ ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ：５００００／ｒｅｇｉｓｔｅｒ＿ｔｏｋｅｎ／ａｐｐｎａｍｅ／ｖｅｒｓｉｏｎ

上述の登録情報において、「ａｐｐｎａｍｅ」は第２のアプリケーションクライアントの識別子であり；「ｖｅｒｓｉｏｎ」は第２のアプリケーションクライアントの現行バージョン情報である。

第１のアプリケーションクライアントが登録情報を受信した後、第１のアプリケーションクライアント自身の組み込みモジュールが、登録情報に応答し、第２のアプリケーションクライアントに応答を送り返す。したがって、第２のアプリケーションクライアントは、特定の期間内にアプリケーションの（すなわち、第１のアプリケーションクライアントの）組み込みモジュールから応答を受信したか否かを判定するだけでよい。受信した場合、第２のアプリケーションクライアントは、第１のアプリケーションクライアントの組み込みモジュールが有効化されていると結論づける。第２のアプリケーションクライアントは、第１のアプリケーションクライアントの組み込みモジュールが有効化されていると判定した場合、自身の組み込みモジュールを有効化する必要はなく、第１のアプリケーションクライアントの組み込みモジュールを介してリソース呼び出し工程を実行できる。

図４は、２つのアプリケーションクライアントを備えたシステムの別の実施形態を示す図である。この例では、第１のアプリケーションクライアントの組み込みモジュールが有効化されていない時に、第２のアプリケーションクライアントが、自身の組み込みモジュールを有効化する。具体的には、第２のアプリケーションクライアントは、「ハートビート」モードで登録情報を送信し、特定の期間内に応答を受信しない。したがって、第２のアプリケーションクライアントは、別のアプリケーションクライアントの組み込みモジュールが有効化されていないと判定し、したがって、第２のアプリケーションクライアント自身の組み込みモジュールを有効化して、その欠損を補う。

上述の技術によると、携帯端末において、１つのアプリケーションクライアントのみがそれ自身の組み込みモジュールを有効化すれば、他のアプリケーションクライアントがその組み込みモジュールによるサービスを受けられるようになる。すべてのアプリケーションクライアントの組み込みモジュールを有効化する必要はない。この技術は、携帯端末への負荷を軽減できる。

さらに、本願の実施形態において、サーバにページ要求メッセージを送る送信側は、ハイブリッドアプリケーション・クライアントに加えて、携帯端末自身のブラウザまたはその他のタイプのアプリケーションクライアントを含む。したがって、図２に示した工程２０２で、サーバが、アプリケーションクライアントのネイティブアドレスを含むページデータをアプリケーションクライアントに送り返す前に、アプリケーションクライアントのタイプが、受信されたページ要求メッセージ内の特定のフィールドに従って、特定のタイプとして確認されうる。具体的には、サーバは、受信されたページ要求メッセージ内の「ＵＡｇｅｎｔ」フィールドまたはその他の追加フィールドに基づいて、ページ要求メッセージを送信したアプリケーションクライアントのタイプがハイブリッドアプリケーションであるか否かを評価する（例えば、「ＵＡｇｅｎｔ」が１に設定されている場合、送信側アプリケーションクライアントはハイブリッドアプリケーションである）。ハイブリッドアプリケーションである場合、サーバは、アプリケーションクライアントのネイティブアドレスを含むページデータを送り返す。そうでない場合、通常のページデータを送り返す。

以上は、本願の実施形態によって提供されるハイブリッドアプリケーションのためのリソース呼び出し方法である。本願の実施形態は、図５および図６に示すように、ハイブリッドアプリケーション・クライアントおよびリソース呼び出しシステムも提供する。

図５は、本願の一実施形態によって提供されるハイブリッドアプリケーション・クライアントを示す構造図である。この例において、ハイブリッドアプリケーション５００は、ページ要求メッセージをサーバに、ページ要求メッセージに応答してサーバによって送り返されたページデータを受信し、ページデータを解析し、呼び出す必要のあるリソースのアドレスを取得し、リソース呼び出し要求を生成するよう構成されたプラグイン５０１を備える。

ハイブリッドアプリケーション・クライアント５００は、さらに、監視ユニット５０２１と、解析ユニット５０２２と、リソース評価ユニット５０２３とを備えた組み込みモジュール５０２を備える。監視ユニット５０２１は、プラグインによって生成されたリソース呼び出し要求を監視するよう構成されている。解析ユニット５０２２は、アプリケーションクライアントのネイティブバージョン情報を取得し、アプリケーションクライアントのネイティブバージョン情報を用いて、監視ユニットによって監視されているリソース呼び出し要求を修正するよう構成されている。リソース評価ユニット５０２３は、修正されたリソース呼び出し要求に従ってリソースを取得し、取得したリソースをプラグインに送り返すよう構成されている。

この例において、サーバから受信されたページデータは、ハイパーテキスト・マークアップランゲージ（ＨＴＭＬ）コードを含み、そのＨＴＭＬコードは、呼び出される必要のあるリソースのアドレスを含む。アドレスは、呼び出される必要のあるリソースの名称およびバージョンプレースホルダを含む。バージョンプレースホルダは、リソースを制限リソースとして特定する。解析ユニット５０２２は、監視ユニット５０２１によって監視されているリソース呼び出し要求がバージョンプレースホルダを含むか否かを判定し、リソース呼び出し要求がバージョンプレースホルダを含む場合、アプリケーションクライアントの現行バージョン情報がバージョンプレースホルダの代わりに用いられる。

リソース評価ユニット５０２３は、対応するリソースをネイティブに取得し、修正されたリソース呼び出し要求に含まれるリソース名およびバージョン情報に基づいて、対応するリソースがネイティブに保存されていない時には対応するリソースをサーバから取得し、取得したリソースをネイティブに保存するよう構成されている。

上述のユニットは、１または複数の汎用プロセッサ上で実行されるソフトウェアコンポーネントとして、特定の機能を実行するよう設計されたプログラム可能論理デバイスおよび／または特定用途向け集積回路などのハードウェアとして、もしくは、それらの組み合わせとして実装することができる。いくつかの実施形態において、ユニットは、コンピュータデバイス（パーソナルコンピュータ、サーバ、ネットワーク装置など）に本願の実施形態に記載された方法を実行させるための複数の命令など、不揮発性記憶媒体（光学ディスク、フラッシュ記憶装置、携帯用ハードディスクなど）に格納することができるソフトウェア製品の形態で具現化されてよい。ユニットは、単一のデバイス上に実装されてもよいし、複数のデバイスにわたって分散されてもよい。ユニットの機能は、互いに統合されてもよいし、複数のサブユニットにさらに分割されてもよい。

図６は、本願に従ったリソース呼び出しシステムの一実施形態を示すシステム図である。この例において、システム６００は、サーバ６０１およびクライアントデバイス６０３を備える。クライアントデバイスは、スマートフォン、タブレット、ラップトップ、ウェアラブルデバイスなど、任意の適切なコンピュータシステムであってよい。１または複数のアプリケーションクライアント６０２が、クライアントデバイス上で実行される。サーバおよびクライアントデバイスは、インターネットなどのネットワークを介して通信する。

サーバ６０１は、アプリケーションクライアント６０２によって送信されたページ要求メッセージを受信し、ページ要求メッセージに従ってアプリケーションクライアント６０２にページデータを送り返すよう構成されている。

アプリケーションクライアント６０２は、サーバ６０１によって送り返されたページデータを受信し、呼び出される必要のあるリソースのアドレスを取得し、リソース呼び出し要求を生成するよう構成されている。アプリケーションクライアントは、さらに、アプリケーションクライアント６０２のネイティブバージョン情報を取得し、アプリケーションクライアントのネイティブバージョン情報を用いて、受信したリソース呼び出し要求を修正し、修正したリソース呼び出し要求に従ってリソースを取得するよう構成されている。

図７は、いくつかの実施形態に従って、リソース呼び出しを実行するためにプログラムされたコンピュータシステムを示す機能図である。明らかに、リソース呼び出しを実行するために、他のコンピュータシステムアーキテクチャおよび構成を用いることも可能である。以下に述べるような様々なサブシステムを備えるコンピュータシステム７００は、少なくとも１つのマイクロプロセッササブシステム（プロセッサまたは中央処理装置（ＣＰＵ）とも呼ばれる）７０２を備える。例えば、プロセッサ７０２は、シングルチッププロセッサまたはマルチプロセッサによって実装できる。いくつかの実施形態において、プロセッサ７０２は、コンピュータシステム７００の動作を制御する汎用デジタルプロセッサである。メモリ７１０から読み出された命令を用いて、プロセッサ７０２は、入力データの受信および操作、ならびに、出力デバイス（例えば、ディスプレイ７１８）上でのデータの出力および表示を制御する。いくつかの実施形態において、プロセッサ７０２は、リソース呼び出し関数を含む、および／または、リソース呼び出し関数を提供するために用いられる。

プロセッサ７０２は、メモリ７１０と双方向的に接続されており、メモリ７１０は、第１のプライマリストレージ（通例は、ランダムアクセスメモリ（ＲＡＭ））および第２のプライマリストレージ領域（通例は、読み出し専用メモリ（ＲＯＭ））を含みうる。当業者に周知のように、プライマリストレージは、一般的な記憶領域として、および、スクラッチパッドメモリとして利用可能であり、また、入力データおよび処理済みデータを格納するために利用可能である。プライマリストレージは、さらに、プロセッサ７０２上で実行される処理のための他のデータおよび命令に加えて、データオブジェクトおよびテキストオブジェクトの形態で、プログラミング命令およびデータを格納できる。また、当業者に周知のように、プライマリストレージは、通例、機能（例えば、プログラムされた命令）を実行するためにプロセッサ７０２によって用いられる基本的な動作命令、プログラムコード、データ、および、オブジェクトを備える。例えば、メモリ７１０は、例えば、データアクセスが双方向である必要があるか、単方向である必要があるかに応じて、後述する任意の適切なコンピュータ読み取り可能な記憶媒体を含みうる。例えば、プロセッサ７０２は、頻繁に必要になるデータをキャッシュメモリ（図示せず）に直接的かつ非常に迅速に格納し取り出すことができる。

着脱可能なマスストレージデバイス７１２が、コンピュータシステム７００にさらなるデータ記憶容量を提供しており、プロセッサ７０２に対して双方向（読み出し／書き込み）または単方向（読み出しのみ）に接続されている。例えば、ストレージ７１２は、磁気テープ、フラッシュメモリ、ＰＣカード、携帯型マスストレージデバイス、ホログラフィックストレージデバイス、および、その他のストレージデバイスなどのコンピュータ読み取り可能な媒体も含みうる。固定マスストレージ７２０も、例えば、さらなるデータ記憶容量を提供しうる。マスストレージ７２０の最も一般的な例は、ハードディスクドライブである。マスストレージ７１２、７２０は、一般に、プロセッサ７０２によって通例はあまり利用されないさらなるプログラミング命令、データなどを格納する。マスストレージ７１２および７２０に保持された情報は、必要であれば、仮想メモリとしてのメモリ７１０（例えば、ＲＡＭ）の一部に標準的な方式で組み込まれてよいことが理解される。

プロセッサ７０２がストレージサブシステムにアクセスできるようにすることに加えて、バス７１４は、その他のサブシステムおよびデバイスへのアクセスを可能にするために用いられてもよい。図に示すように、これらは、ディスプレイモニタ／タッチスクリーン７１８、ネットワークインターフェース７１６、キーボード７０４、および、ポインティングデバイス７０６、ならびに、必要に応じて、補助入力／出力デバイスインターフェース、サウンドカード、スピーカ、および、その他のサブシステムを含みうる。例えば、ポインティングデバイス７０６は、マウス、スタイラス、トラックボール、または、タブレットであってよく、グラフィカルユーザインターフェースと相互作用するのに有用である。

ネットワークインターフェース７１６は、図に示すように、ネットワーク接続を用いて、別のコンピュータ、コンピュータネットワーク、または、遠隔通信ネットワークにプロセッサ７０２を接続することを可能にする。例えば、ネットワークインターフェース７１６を通して、プロセッサ７０２は、方法／処理ステップを実行する過程で、別のネットワークから情報（例えば、データオブジェクトまたはプログラム命令）を受信したり、別のネットワークに情報を出力したりすることができる。情報は、しばしば、プロセッサ上で実行される一連の命令として表され、別のネットワークから受信されたり、別のネットワークへ出力されたりしうる。インターフェースカード（または同様のデバイス）と、プロセッサ７０２によって実装（例えば、実行／実施）される適切なソフトウェアとを用いて、コンピュータシステム７００を外部ネットワークに接続し、標準プロトコルに従ってデータを転送することができる。例えば、本明細書に開示された様々な処理の実施形態は、プロセッサ７０２上で実行されてもよいし、処理の一部を共有するリモートプロセッサと共に、ネットワーク（インターネット、イントラネットワーク、または、ローカルエリアネットワークなど）上で実行されてもよい。さらなるマスストレージデバイス（図示せず）が、ネットワークインターフェース７１６を通してプロセッサ７０２に接続されてもよい。

補助Ｉ／Ｏデバイスインターフェース（図示せず）が、コンピュータシステム７００と共に用いられてよい。補助Ｉ／Ｏデバイスインターフェースは、プロセッサ７０２がデータを送信すること、ならびに、より典型的には、他のデバイス（マイクロホン、タッチセンサ方式ディスプレイ、トランスデューサカードリーダ、テープリーダ、音声または手書き認識装置、バイオメトリクスリーダ、カメラ、携帯型マスストレージデバイス、および、他のコンピュータなど）からデータを受信することを可能にする汎用インターフェースおよびカスタマイズされたインターフェースを含みうる。

さらに、本明細書に開示された様々な実施形態は、さらに、様々なコンピュータ実装された動作を実行するためのプログラムコードを備えたコンピュータ読み取り可能な媒体を含むコンピュータストレージ製品に関する。コンピュータ読み取り可能な媒体は、データを格納できる任意のデータストレージデバイスであり、そのデータは、後にコンピュータシステムによって読み出されうる。コンピュータ読み取り可能な媒体の例は、以下の媒体すべてを含むがそれらに限定されない：ハードディスク、フロッピー（登録商標）ディスク、および、磁気テープなどの磁気媒体；ＣＤ−ＲＯＭディスクなどの光学媒体；光学ディスクなどの磁気光学媒体；ならびに、特定用途向け集積回路（ＡＳＩＣ）、プログラム可能論理デバイス（ＰＬＤ）、および、ＲＯＭ／ＲＡＭデバイスなど、特別に構成されたハードウェアデバイス。プログラムコードの例としては、例えば、コンパイラによって生成されるマシンコード、または、インタープリタを用いて実行できる高水準コード（例えば、スクリプト）を含むファイルが挙げられる。

図７に示したコンピュータシステムは、本明細書に開示された様々な実施形態と共に利用するのに適切なコンピュータシステムの一例にすぎない。かかる利用に適した他のコンピュータシステムは、より多いまたは少ないサブシステムを含みうる。さらに、バス７１４は、サブシステムをつなぐよう機能する任意の相互接続スキームの例である。異なる構成のサブシステムを有する他のコンピュータアーキテクチャが利用されてもよい。

本願の実施形態は、リソース呼び出し技術を提供する。この技術によると、クライアントは、サーバによって送信され、呼び出される必要のあるリソースのアドレスを含むページデータを受信する。クライアントは、ページデータを解析し、リソース呼び出し要求を生成する。クライアントは、クライアントのネイティブバージョン情報を用いて、このリソース呼び出し要求を修正し、修正したリソース呼び出し要求に従ってリソースを取得する。上記の技術を用いれば、クライアントおよびサーバが異なるバージョンを有する場合に、ページデータを修正する必要なしに、正常なサービスを提供できる。したがって、後のページを正常にロードすることを保証できる。

当業者は、本願の実施形態が、方法、システム、または、コンピュータソフトウェア製品として提供されうることを理解されたい。したがって、本願は、完全なハードウェア実施形態、完全なソフトウェア実施形態、もしくは、ソフトウェアおよびハードウェアを組み合わせた実施形態を取りうる。さらに、本願は、コンピュータ動作可能なプログラムコードを含む１または複数のコンピュータ動作可能な記憶媒体（磁気ディスク記憶デバイス、ＣＤ−ＲＯＭ、および、光学記憶デバイスを含むがこれらに限定されない）上に実装されたコンピュータプログラム製品の形態を取りうる。

本願は、方法、装置（システム）、および、コンピュータプログラム製品に基づいたフローチャートおよび／またはブロック図を参照して記載されている。フローチャートおよび／またはブロック図内の各フロープロセスおよび／またはブロック図、ならびに、フローチャートおよび／またはブロック図内のフロープロセスおよび／またはブロック図の組み合わせは、コンピュータ命令によって実現されうることに注意されたい。これらのコンピュータ命令は、マシンを生成するために、汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、または、その他のプログラム可能なデータ処理装置のプロセッサに供給されてよく、その結果、コンピュータまたはその他のプログラム可能なデータ処理装置のプロセッサによって命令が実行されることで、フローチャートの１または複数の処理および／またはブロック図の１または複数のブロックに記載された機能を実現するために用いられるデバイスが生成される。

これらのコンピュータプログラム命令は、コンピュータまたはその他のプログラム可能なデータ処理装置を導くことができる専用のコンピュータ読み取り可能な記憶デバイス上に格納されてもよく、その結果、これらのコンピュータ読み取り可能なデバイス上に命令が格納されることで、命令デバイスを備える製品が生成される。これらの命令デバイスは、フローチャートの１または複数の処理および／またはブロック図の１または複数のブロックに記載された機能を実現する。

これらのコンピュータプログラム命令は、コンピュータまたはその他のプログラム可能なデータ処理装置上にロードされてもよく、その結果、一連の動作工程が、コンピュータまたはその他のプログラム可能な装置上で実行され、コンピュータ処理が行われる。このように、コンピュータまたはその他のプログラム可能な装置上で実行された命令は、フローチャートの１または複数の処理および／またはブロック図の１または複数のブロックに記載された機能を実現するための工程を提供する。

上述の実施形態は、理解しやすいようにいくぶん詳しく説明されているが、本発明は、提供された詳細事項に限定されるものではない。本発明を実施する多くの代替方法が存在する。開示された実施形態は、例示であり、限定を意図するものではない。

図５は、本願の一実施形態によって提供されるハイブリッドアプリケーション・クライアントを示す構造図である。この例において、ハイブリッドアプリケーション５００は、ページ要求メッセージをサーバに送信し、ページ要求メッセージに応答してサーバによって送り返されたページデータを受信し、ページデータを解析し、呼び出す必要のあるリソースのアドレスを取得し、リソース呼び出し要求を生成するよう構成されたプラグイン５０１を備える。

上述の実施形態は、理解しやすいようにいくぶん詳しく説明されているが、本発明は、提供された詳細事項に限定されるものではない。本発明を実施する多くの代替方法が存在する。開示された実施形態は、例示であり、限定を意図するものではない。
本発明は、たとえば、以下のような態様で実現することもできる。

適用例１：
リソースを呼び出すための方法であって、
ページ要求メッセージをサーバに送信する工程と、
前記ページ要求メッセージに応答して前記サーバによって送り返されたページデータを受信する工程と、
前記ページデータを解析して、前記リソースのアドレスを取得する工程と、
１または複数のコンピュータプロセッサによって、前記リソースの前記アドレスを用いてリソース呼び出し要求を生成する工程と、
アプリケーションクライアントのネイティブバージョン情報を取得する工程と、
前記アプリケーションクライアントの前記ネイティブバージョン情報を用いて、前記リソース呼び出し要求を修正する工程と、
前記修正されたリソース呼び出し要求に従って前記リソースを取得する工程と、
を備える、方法。

適用例２：
適用例１の方法であって、前記ページデータは、ハイパーテキスト・マークアップランゲージ（ＨＴＭＬ）コードを含み、前記ＨＴＭＬコードは、前記リソースの前記アドレスを含む、方法。

適用例３：
適用例１の方法であって、前記アドレスは、前記リソースの名称およびバージョンプレースホルダを含み、前記バージョンプレースホルダは、前記リソースが制限リソースであることを示す、方法。

適用例４：
適用例１の方法であって、前記アプリケーションクライアントの前記ネイティブバージョン情報を用いて、前記リソース呼び出し要求を修正する工程は、
前記リソース呼び出し要求を監視する工程と、
前記リソース呼び出し要求がバージョンプレースホルダを含むか否かを判定する工程と、
前記リソース呼び出し要求が前記バージョンプレースホルダを含む場合に、前記バージョンプレースホルダを前記アプリケーションクライアントの前記ネイティブバージョン情報で置き換える工程と、
を含む、方法。

適用例５：
適用例１の方法であって、前記修正されたリソース呼び出し要求に従って前記リソースを取得する工程は、前記修正されたリソース呼び出し要求に含まれるリソース名および前記ネイティブバージョン情報を用いて、前記リソースを取得する工程を含む、方法。

適用例６：
適用例１の方法であって、前記修正されたリソース呼び出し要求に従って前記リソースを取得する工程は、
前記アプリケーションクライアントを実行するデバイス上で、ネイティブに前記アプリケーションクライアントから対応するリソースを取得するよう試みる工程と、
前記デバイス上で前記対応するリソースを取得することが成功しなかった場合に、前記対応するリソースを前記サーバから取得して、前記取得したリソースを前記デバイスにネイティブに保存する工程と、
を含む、方法。

適用例７：
適用例１の方法であって、前記アプリケーションクライアントは、第１のアプリケーションクライアントであり、前記方法は、さらに、
第２のアプリケーションクライアントによって送信された登録情報を受信する工程と、
前記登録情報に含まれる前記第２のアプリケーションクライアントの現行バージョン情報を保存する工程と、
前記第２のアプリケーションクライアントによって送信されたリソース呼び出し要求を受信した後に、
前記第２のアプリケーションクライアントによって送信された前記リソース呼び出し要求に含まれるアドレスに含まれるバージョンプレースホルダを、前記第２のアプリケーションクライアントの保存された現行バージョンに修正する工程と、
前記第２のアプリケーションクライアントによって送信された前記修正されたリソース呼び出し要求に含まれる前記アドレスを用いて、対応するリソースを取得する工程と、
前記取得した対応するリソースを前記第２のアプリケーションクライアントに送信する工程と、
を備える、方法。

適用例８：
適用例１の方法であって、前記アドレスは、前記アプリケーションクライアントが動作するクライアントデバイス上で監視されているポートを含む、方法。

適用例９：
リソース呼び出しシステムであって、
１または複数のプロセッサであって、
ページ要求メッセージをサーバに送信し、
前記ページ要求メッセージに応答して前記サーバによって送り返されたページデータを受信し、
前記ページデータを解析して、リソースのアドレスを取得し、
前記リソースの前記アドレスを用いてリソース呼び出し要求を生成し、
アプリケーションクライアントのネイティブバージョン情報を取得し、
前記アプリケーションクライアントの前記ネイティブバージョン情報を用いて、前記リソース呼び出し要求を修正し、
前記修正されたリソース呼び出し要求に従って前記リソースを取得するよう構成された、１または複数のプロセッサと、
前記１または複数のプロセッサに接続され、前記１または複数のプロセッサに命令を提供するよう構成された１または複数のメモリと、
を備える、システム。

適用例１０：
適用例９のシステムであって、前記ページデータは、ハイパーテキスト・マークアップランゲージ（ＨＴＭＬ）コードを含み、前記ＨＴＭＬコードは、前記リソースの前記アドレスを含む、システム。

適用例１１：
適用例９のシステムであって、前記アドレスは、前記リソースの名称およびバージョンプレースホルダを含み、前記バージョンプレースホルダは、前記リソースが制限リソースであることを示す、システム。

適用例１２：
適用例９のシステムであって、前記アプリケーションクライアントの前記ネイティブバージョン情報を用いて、前記リソース呼び出し要求を修正することは、
前記リソース呼び出し要求を監視することと、
前記リソース呼び出し要求がバージョンプレースホルダを含むか否かを判定することと、
前記リソース呼び出し要求が前記バージョンプレースホルダを含む場合に、前記バージョンプレースホルダを前記アプリケーションクライアントの前記ネイティブバージョン情報で置き換えることと、
を含む、システム。

適用例１３：
適用例９のシステムであって、前記修正されたリソース呼び出し要求に従って前記リソースを取得することは、前記修正されたリソース呼び出し要求に含まれるリソース名および前記ネイティブバージョン情報を用いて、前記リソースを取得することを含む、システム。

適用例１４：
適用例９のシステムであって、前記修正されたリソース呼び出し要求に従って前記リソースを取得することは、
前記アプリケーションクライアントを実行するデバイス上で、ネイティブに前記アプリケーションクライアントから対応するリソースを取得するよう試みることと、
前記デバイス上で前記対応するリソースを取得することが成功しなかった場合に、前記対応するリソースを前記サーバから取得して、前記取得したリソースを前記デバイスにネイティブに保存することと、
を含む、システム。

適用例１５：
適用例９のシステムであって、前記アプリケーションクライアントは、第１のアプリケーションクライアントであり、前記１または複数のプロセッサは、さらに、
第２のアプリケーションクライアントによって送信された登録情報を受信し、
前記登録情報に含まれる前記第２のアプリケーションクライアントの現行バージョン情報を保存し、
前記第２のアプリケーションクライアントによって送信されたリソース呼び出し要求を受信した後に、
前記第２のアプリケーションクライアントによって送信された前記リソース呼び出し要求に含まれるアドレスに含まれるバージョンプレースホルダを、前記第２のアプリケーションクライアントの保存された現行バージョンに修正し、
前記第２のアプリケーションクライアントによって送信された前記修正されたリソース呼び出し要求に含まれる前記アドレスを用いて、対応するリソースを取得し、
前記取得した対応するリソースを前記第２のアプリケーションクライアントに送信するよう構成されている、システム。

適用例１６：
適用例９のシステムであって、前記アドレスは、前記アプリケーションクライアントが動作するクライアントデバイス上で監視されているポートを含む、システム。

適用例１７：
リソースを呼び出すためのコンピュータプログラム製品であって、有形のコンピュータ読み取り可能な記憶媒体内に具現化され、
ページ要求メッセージをサーバに送信するためのコンピュータ命令と、
前記ページ要求メッセージに応答して前記サーバによって送り返されたページデータを受信するためのコンピュータ命令と、
前記ページデータを解析して、前記リソースのアドレスを取得するためのコンピュータ命令と、
前記リソースの前記アドレスを用いてリソース呼び出し要求を生成するためのコンピュータ命令と、
アプリケーションクライアントのネイティブバージョン情報を取得するためのコンピュータ命令と、
前記アプリケーションクライアントの前記ネイティブバージョン情報を用いて、前記リソース呼び出し要求を修正するためのコンピュータ命令と、
前記修正されたリソース呼び出し要求に従って前記リソースを取得するためのコンピュータ命令と、
を備える、コンピュータプログラム製品。

Claims (17)

1. リソースを呼び出すための方法であって、
   ページ要求メッセージをサーバに送信する工程と、
   前記ページ要求メッセージに応答して前記サーバによって送り返されたページデータを受信する工程と、
   前記ページデータを解析して、前記リソースのアドレスを取得する工程と、
   １または複数のコンピュータプロセッサによって、前記リソースの前記アドレスを用いてリソース呼び出し要求を生成する工程と、
   アプリケーションクライアントのネイティブバージョン情報を取得する工程と、
   前記アプリケーションクライアントの前記ネイティブバージョン情報を用いて、前記リソース呼び出し要求を修正する工程と、
   前記修正されたリソース呼び出し要求に従って前記リソースを取得する工程と、
   を備える、方法。
2. 請求項１に記載の方法であって、前記ページデータは、ハイパーテキスト・マークアップランゲージ（ＨＴＭＬ）コードを含み、前記ＨＴＭＬコードは、前記リソースの前記アドレスを含む、方法。
3. 請求項１に記載の方法であって、前記アドレスは、前記リソースの名称およびバージョンプレースホルダを含み、前記バージョンプレースホルダは、前記リソースが制限リソースであることを示す、方法。
4. 請求項１に記載の方法であって、前記アプリケーションクライアントの前記ネイティブバージョン情報を用いて、前記リソース呼び出し要求を修正する工程は、
   前記リソース呼び出し要求を監視する工程と、
   前記リソース呼び出し要求がバージョンプレースホルダを含むか否かを判定する工程と、
   前記リソース呼び出し要求が前記バージョンプレースホルダを含む場合に、前記バージョンプレースホルダを前記アプリケーションクライアントの前記ネイティブバージョン情報で置き換える工程と、
   を含む、方法。
5. 請求項１に記載の方法であって、前記修正されたリソース呼び出し要求に従って前記リソースを取得する工程は、前記修正されたリソース呼び出し要求に含まれるリソース名および前記ネイティブバージョン情報を用いて、前記リソースを取得する工程を含む、方法。
6. 請求項１に記載の方法であって、前記修正されたリソース呼び出し要求に従って前記リソースを取得する工程は、
   前記アプリケーションクライアントを実行するデバイス上で、ネイティブに前記アプリケーションクライアントから対応するリソースを取得するよう試みる工程と、
   前記デバイス上で前記対応するリソースを取得することが成功しなかった場合に、前記対応するリソースを前記サーバから取得して、前記取得したリソースを前記デバイスにネイティブに保存する工程と、
   を含む、方法。
7. 請求項１に記載の方法であって、前記アプリケーションクライアントは、第１のアプリケーションクライアントであり、前記方法は、さらに、
   第２のアプリケーションクライアントによって送信された登録情報を受信する工程と、
   前記登録情報に含まれる前記第２のアプリケーションクライアントの現行バージョン情報を保存する工程と、
   前記第２のアプリケーションクライアントによって送信されたリソース呼び出し要求を受信した後に、
   前記第２のアプリケーションクライアントによって送信された前記リソース呼び出し要求に含まれるアドレスに含まれるバージョンプレースホルダを、前記第２のアプリケーションクライアントの保存された現行バージョンに修正する工程と、
   前記第２のアプリケーションクライアントによって送信された前記修正済みのリソース呼び出し要求に含まれる前記アドレスを用いて、対応するリソースを取得する工程と、
   前記取得した対応するリソースを前記第２のアプリケーションクライアントに送信する工程と、
   を備える、方法。
8. 請求項１に記載の方法であって、前記アドレスは、前記アプリケーションクライアントが動作するクライアントデバイス上で監視されているポートを含む、方法。
9. リソース呼び出しシステムであって、
   １または複数のプロセッサであって、
   ページ要求メッセージをサーバに送信し、
   前記ページ要求メッセージに応答して前記サーバによって送り返されたページデータを受信し、
   前記ページデータを解析して、リソースのアドレスを取得し、
   前記リソースの前記アドレスを用いてリソース呼び出し要求を生成し、
   アプリケーションクライアントのネイティブバージョン情報を取得し、
   前記アプリケーションクライアントの前記ネイティブバージョン情報を用いて、前記リソース呼び出し要求を修正し、
   前記修正されたリソース呼び出し要求に従って前記リソースを取得するよう構成された、１または複数のプロセッサと、
   前記１または複数のプロセッサに接続され、前記１または複数のプロセッサに命令を提供するよう構成された１または複数のメモリと、
   を備える、システム。
10. 請求項９に記載のシステムであって、前記ページデータは、ハイパーテキスト・マークアップランゲージ（ＨＴＭＬ）コードを含み、前記ＨＴＭＬコードは、前記リソースの前記アドレスを含む、システム。
11. 請求項９に記載のシステムであって、前記アドレスは、前記リソースの名称およびバージョンプレースホルダを含み、前記バージョンプレースホルダは、前記リソースが制限リソースであることを示す、システム。
12. 請求項９に記載のシステムであって、前記アプリケーションクライアントの前記ネイティブバージョン情報を用いて、前記リソース呼び出し要求を修正することは、
    前記リソース呼び出し要求を監視することと、
    前記リソース呼び出し要求がバージョンプレースホルダを含むか否かを判定することと、
    前記リソース呼び出し要求が前記バージョンプレースホルダを含む場合に、前記バージョンプレースホルダを前記アプリケーションクライアントの前記ネイティブバージョン情報で置き換えることと、
    を含む、システム。
13. 請求項９に記載のシステムであって、前記修正されたリソース呼び出し要求に従って前記リソースを取得することは、前記修正されたリソース呼び出し要求に含まれるリソース名および前記ネイティブバージョン情報を用いて、前記リソースを取得することを含む、システム。
14. 請求項９に記載のシステムであって、前記修正されたリソース呼び出し要求に従って前記リソースを取得することは、
    前記アプリケーションクライアントを実行するデバイス上で、ネイティブに前記アプリケーションクライアントから対応するリソースを取得するよう試みることと、
    前記デバイス上で前記対応するリソースを取得することが成功しなかった場合に、前記対応するリソースを前記サーバから取得して、前記取得したリソースを前記デバイスにネイティブに保存することと、
    を含む、システム。
15. 請求項９に記載のシステムであって、前記アプリケーションクライアントは、第１のアプリケーションクライアントであり、前記１または複数のプロセッサは、さらに、
    第２のアプリケーションクライアントによって送信された登録情報を受信し、
    前記登録情報に含まれる前記第２のアプリケーションクライアントの現行バージョン情報を保存し、
    前記第２のアプリケーションクライアントによって送信されたリソース呼び出し要求を受信した後に、
    前記第２のアプリケーションクライアントによって送信された前記リソース呼び出し要求に含まれるアドレスに含まれるバージョンプレースホルダを、前記第２のアプリケーションクライアントの保存された現行バージョンに修正し、
    前記第２のアプリケーションクライアントによって送信された前記修正済みのリソース呼び出し要求に含まれる前記アドレスを用いて、対応するリソースを取得し、
    前記取得した対応するリソースを前記第２のアプリケーションクライアントに送信するよう構成されている、システム。
16. 請求項９に記載のシステムであって、前記アドレスは、前記アプリケーションクライアントが動作するクライアントデバイス上で監視されているポートを含む、システム。
17. リソースを呼び出すためのコンピュータプログラム製品であって、有形のコンピュータ読み取り可能な記憶媒体内に具現化され、
    ページ要求メッセージをサーバに送信するためのコンピュータ命令と、
    前記ページ要求メッセージに応答して前記サーバによって送り返されたページデータを受信するためのコンピュータ命令と、
    前記ページデータを解析して、前記リソースのアドレスを取得するためのコンピュータ命令と、
    前記リソースの前記アドレスを用いてリソース呼び出し要求を生成するためのコンピュータ命令と、
    アプリケーションクライアントのネイティブバージョン情報を取得するためのコンピュータ命令と、
    前記アプリケーションクライアントの前記ネイティブバージョン情報を用いて、前記リソース呼び出し要求を修正するためのコンピュータ命令と、
    前記修正されたリソース呼び出し要求に従って前記リソースを取得するためのコンピュータ命令と、
    を備える、コンピュータプログラム製品。

Images