(57)【特許請求の範囲】
【請求項１】
ページオペレーション処理方法であって、
端末デバイスにより、アクセスされることになるリソースに対応するユニフォーム・リソース・ロケータ（URL）を取得するステップと、
前記端末デバイスにより、格納されているドメイン名が、前記URLに対応するドメイン名を含んでいるかどうかを検出するステップと、
前記格納されているドメイン名が、前記URLに対応する前記ドメイン名を含んでいる場合、前記端末デバイスにより、ブラウザの代わりに、前記URLの前記ドメイン名に対応するアプリケーション・クライアントをトリガーして、前記URLに対応するアプリケーション・クライアント・ページを取得して表示するステップと
を含み、
前記端末デバイスにより、ブラウザの代わりに、前記URLの前記ドメイン名に対応するアプリケーション・クライアントをトリガーして、前記URLに対応するアプリケーション・クライアント・ページを取得して表示する前記ステップよりも前に、
前記端末デバイスにより、前記URLの前記ドメイン名に対応する前記アプリケーション・クライアントがインストールされているかどうかを決定するステップと、
前記URLの前記ドメイン名に対応する前記アプリケーション・クライアントがインストールされていない場合、前記端末デバイスにより、前記アプリケーション・クライアントをインストールし、前記アプリケーション・クライアントに対応する少なくとも1つのドメイン名、ならびに前記アプリケーション・クライアントの識別子および／またはアイコンを格納するステップと
をさらに含み、
前記端末デバイスにより、前記アプリケーション・クライアントをインストールする前記ステップよりも前に、
前記端末デバイスにより、前記ドメイン名に対応する前記アプリケーション・クライアントが存在するかどうかをサーバがフィードバックするよう、前記URLに対応する前記ドメイン名を前記サーバへ送信するステップをさらに含み、
前記端末デバイスにより、前記アプリケーション・クライアントをインストールする前記ステップが、
前記ドメイン名に対応する前記アプリケーション・クライアントが存在する場合、前記端末デバイスにより、前記ドメイン名に対応する前記アプリケーション・クライアントをインストールするステップを含む、方法。
【請求項２】
前記端末デバイスにより、格納されているドメイン名が、前記URLに対応するドメイン名を含んでいるかどうかを検出する前記ステップが、
前記端末デバイスにより、データベースに格納されているドメイン名情報に従って前記URL内の文字を1つずつ比較し、前記URLから第2レベルドメイン名を抽出して、前記URLの前記ドメイン名を入手するか、または前記URL内のデリミタに従って前記URLから第2レベルドメイン名を抽出して、前記URLの前記ドメイン名を入手するステップと、
前記端末デバイスにより、前記端末デバイスが前記ドメイン名を格納しているかどうかを決定するステップと
を含み、
前記ドメイン名が、少なくとも前記第2レベルドメイン名を含む、請求項1に記載の方法。
【請求項３】
前記端末デバイスにより、前記URLの前記ドメイン名に対応する前記アプリケーション・クライアントがインストールされているかどうかを決定する前記ステップが、
前記端末デバイスにより、前記URLに対応する前記ドメイン名と、ローカルに格納されているアプリケーション・クライアント・リストとの間におけるマッチングを実行し、前記マッチングが成功である場合には、前記アプリケーション・クライアントが前記端末デバイス上にインストールされていると決定し、前記マッチングが不成功である場合には、前記アプリケーション・クライアントが前記端末デバイス上にインストールされていないと決定するステップを含む、請求項1に記載の方法。
【請求項４】
端末デバイスにより、アクセスされることになるリソースに対応するURLを取得する前記ステップが、
前記端末デバイスにより、前記アクセスされることになるリソースに対応し、かつユーザによって入力される前記URLを取得するステップ、または
前記端末デバイスにより、2次元コードをスキャンすることによって、前記アクセスされることになるリソースに対応する前記URLを取得するステップ、または
前記端末デバイスにより、近距離無線通信を使用することによって、前記アクセスされることになるリソースに対応する前記URLを別のデバイスから取得するステップ
を含む、請求項1から3のいずれか一項に記載の方法。
【請求項５】
端末であって、
前記端末上にインストールされているアプリケーション・クライアントに対応するドメイン名を格納するように構成されたメモリと、
アクセスされることになるリソースに対応するユニフォーム・リソース・ロケータ（URL）を取得し、格納されているドメイン名が、前記URLに対応するドメイン名を含んでいるかどうかを検出し、前記格納されているドメイン名が、前記URLに対応する前記ドメイン名を含んでいることが検出された場合に、ブラウザの代わりに、前記URLの前記ドメイン名に対応するアプリケーション・クライアントをトリガーして、前記URLに対応するアプリケーション・クライアント・ページを取得して表示するように構成されたプロセッサと
を含み、
前記プロセッサが、
前記URLの前記ドメイン名に対応する前記アプリケーション・クライアントがインストールされているかどうかを決定し、前記URLの前記ドメイン名に対応する前記アプリケーション・クライアントがインストールされていない場合に、前記アプリケーション・クライアントをインストールし、前記アプリケーション・クライアントに対応する少なくとも1つのドメイン名、ならびに前記アプリケーション・クライアントの識別子および／またはアイコンを格納するようにさらに構成され、
前記プロセッサが、
前記ドメイン名に対応する前記アプリケーション・クライアントが存在するかどうかをサーバがフィードバックするよう、前記URLに対応する前記ドメイン名を前記サーバへ送信するようにさらに構成され、
前記アプリケーション・クライアントをインストールすることが、
前記ドメイン名に対応する前記アプリケーション・クライアントが存在する場合に、前記ドメイン名に対応する前記アプリケーション・クライアントをインストールすることを含む、端末。
【請求項６】
格納されているドメイン名が、前記URLに対応するドメイン名を含んでいるかどうかを検出することが、
データベースに格納されているドメイン名に従って前記URL内の文字を1つずつ比較し、前記URLから第2レベルドメイン名を抽出して、前記URLの前記ドメイン名を入手するか、または前記URL内のデリミタに従って前記URLから第2レベルドメイン名を抽出して、前記URLの前記ドメイン名を入手することと、
前記端末が前記ドメイン名を格納しているかどうかを決定することと
を含み、
前記ドメイン名が、少なくとも前記第2レベルドメイン名を含む、請求項5に記載の端末。
【請求項７】
前記URLの前記ドメイン名に対応する前記アプリケーション・クライアントがインストールされているかどうかを決定することが、
前記URLに対応する前記ドメイン名と、ローカルに格納されているアプリケーション・クライアント・リストとの間におけるマッチングを実行し、前記マッチングが成功である場合には、前記アプリケーション・クライアントが前記端末上にインストールされていると決定し、前記マッチングが不成功である場合には、前記アプリケーション・クライアントが前記端末上にインストールされていないと決定することを含む、請求項5に記載の端末。
【請求項８】
前記アクセスされることになるリソースに対応し、かつユーザによって入力される前記URLを受信して、前記URLを前記プロセッサへ送信するように構成された入力デバイス、または
近距離無線通信を使用することによって、前記アクセスされることになるリソースに対応する前記URLを受信して、前記URLを前記プロセッサへ送信するように構成された近距離無線通信受信機
をさらに含む、請求項5から7のいずれか一項に記載の端末。
【請求項９】
2次元コードイメージを取得して、前記2次元コードイメージを前記プロセッサへ送信するように構成されたイメージ取得デバイスをさらに含み、
前記プロセッサが、前記2次元コードイメージを解析して、前記アクセスされることになるリソースに対応する前記URLを入手するようにさらに構成される、請求項5から8のいずれか一項に記載の端末。
【請求項１０】
請求項1から4のいずれか一項に記載の方法をコンピュータに実行させるプログラムを格納したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、通信テクノロジーに関し、詳細には、ページオペレーション処理方法および装置、ならびに端末に関する。
【背景技術】
【０００２】
端末デバイス上のさまざまなアプリケーションの継続的な開発に伴って、人々は、端末デバイスを使用することによってインスタントメッセージ通信、インターネット上でのサーフィン、およびショッピングなどの機能オペレーションを実行することに徐々に慣れてきている。
【０００３】
従来技術においては、ユーザが端末デバイス上でウェブページ・リンクをクリックすると、端末デバイスは、ユーザによってクリックされたコンテンツがユニフォーム・リソース・ロケータ（Uniform Resource Locator、略してURL）であるということを認識することができ、次いで端末デバイスは、端末デバイス上にインストールされているすべてのブラウザを含むウィンドウをユーザに提示することができる。ユーザは、端末デバイスによって提示されたウィンドウにおいて1つのブラウザを選択して、ウェブページ・リンクにアクセスすることができる。
【０００４】
しかしながら、ブラウザを使用してウェブページ・リンクにアクセスすることは、大量のネットワークトラフィックの消費に容易につながる。加えて、端末デバイスのスクリーンは一般的なコンピュータのスクリーンよりも小さいので、ブラウザを使用することによってページが表示される場合の表示されるコンテンツのサイズは相対的に小さい。結果として、ユーザオペレーションおよびブラウジングにとって不便である。
【発明の概要】
【課題を解決するための手段】
【０００５】
本発明の実施態様は、従来技術における問題、すなわち、ブラウザを使用することによって端末デバイス上でウェブページ・リンクがアクセスされる場合に大量のネットワークトラフィックが消費されるということ、ならびにブラウザを使用することによってページが表示される場合の表示されるコンテンツのサイズが相対的に小さいので、ユーザオペレーションおよびブラウジングにとって不便であるということを解決するために、ページオペレーション処理方法および装置、ならびに端末を提供する。それにより、ユーザ体験が改善される。
【０００６】
第1の態様によれば、本発明の一実施態様は、
端末デバイスにより、アクセスされることになるリソースに対応するユニフォーム・リソース・ロケータ（URL）を取得するステップと、
端末デバイスにより、格納されているドメイン名が、URLに対応するドメイン名を含んでいるかどうかを検出するステップと、
格納されているドメイン名が、URLに対応するドメイン名を含んでいる場合、端末デバイスにより、URLのドメイン名に対応するアプリケーション・クライアントをトリガーして、URLに対応するアプリケーション・クライアント・ページを取得して表示するステップとを含むページオペレーション処理方法を提供する。
【０００７】
第1の態様に関連して、第1の態様の第1の可能な実施様式においては、端末デバイスにより、アクセスされることになるリソースに対応するURLを取得するステップは、
端末デバイスにより、アクセスされることになるリソースに対応し、かつユーザによって入力されるURLを取得するステップ、または
端末デバイスにより、2次元コードをスキャンすることによって、アクセスされることになるリソースに対応するURLを取得するステップ、または
端末デバイスにより、近距離無線通信を使用することによって、アクセスされることになるリソースに対応するURLを別のデバイスから取得するステップを含む。
【０００８】
第1の態様に関連して、第1の態様の第2の可能な実施様式においては、端末デバイスにより、格納されているドメイン名が、URLに対応するドメイン名を含んでいるかどうかを検出するステップは、
端末デバイスにより、データベースに格納されているドメイン名情報に従ってURL内の文字を1つずつ比較し、URLから第2レベルドメイン名を抽出して、URLのドメイン名を入手するか、またはURL内のデリミタに従ってURLから第2レベルドメイン名を抽出して、URLのドメイン名を入手するステップと、
端末デバイスにより、端末デバイスがドメイン名を格納しているかどうかを決定するステップとを含み、
ここで、ドメイン名は、少なくとも第2レベルドメイン名を含む。
【０００９】
第1の態様に関連して、第1の態様の第3の可能な実施様式においては、端末デバイスにより、URLのドメイン名に対応するアプリケーション・クライアントをトリガーして、URLに対応するアプリケーション・クライアント・ページを取得して表示するステップは、
端末デバイスにより、アプリケーション・クライアントを始動して、URLをアプリケーション・クライアントへ送信し、それによって、アプリケーション・クライアントが、URLに対応するアプリケーション・クライアント・ページを取得したいという要求をネットワークサーバへ送信し、アプリケーション・クライアント・ページを表示する、ステップ、または
端末デバイスにより、アクセスされることになるリソースを開くために使用可能なオプションのうちの1つとしてアプリケーション・クライアントの識別子および／またはアイコンをユーザに提示し、アプリケーション・クライアントの識別子および／またはアイコンをユーザが選択した後に、アプリケーション・クライアントを始動して、URLをアプリケーション・クライアントへ送信し、それによって、アプリケーション・クライアントが、URLに対応するアプリケーション・クライアント・ページを取得したいという要求をネットワークサーバへ送信し、アプリケーション・クライアント・ページを表示する、ステップを含む。
【００１０】
第1の態様、または第1の態様の第1の可能な実施様式から第1の態様の第3の可能な実施様式のいずれか1つに関連して、第1の態様の第4の可能な実施様式においては、端末デバイスにより、URLのドメイン名に対応するアプリケーション・クライアントをトリガーして、URLに対応するアプリケーション・クライアント・ページを取得して表示するステップよりも前に、この方法は、
端末デバイスにより、URLのドメイン名に対応するアプリケーション・クライアントがインストールされているかどうかを決定するステップと、
URLのドメイン名に対応するアプリケーション・クライアントがインストールされていない場合、端末デバイスにより、アプリケーション・クライアントをインストールし、アプリケーション・クライアントに対応する少なくとも1つのドメイン名、ならびにアプリケーション・クライアントの識別子および／またはアイコンを格納するステップとをさらに含む。
【００１１】
第1の態様の第4の可能な実施様式に関連して、第1の態様の第5の可能な実施様式においては、端末デバイスにより、URLのドメイン名に対応するアプリケーション・クライアントがインストールされているかどうかを決定するステップは、
端末デバイスにより、URLに対応するドメイン名と、ローカルに格納されているアプリケーション・クライアント・リストとの間におけるマッチングを実行し、マッチングが成功である場合には、アプリケーション・クライアントが端末デバイス上にインストールされていると決定し、マッチングが不成功である場合には、アプリケーション・クライアントが端末デバイス上にインストールされていないと決定するステップを含む。
【００１２】
第1の態様の第5の可能な実施様式に関連して、第1の態様の第6の可能な実施様式においては、端末デバイスにより、アプリケーション・クライアントをインストールするステップよりも前に、この方法は、
端末デバイスにより、URLに対応するドメイン名をサーバへ送信し、それによって、サーバが、ドメイン名に対応するアプリケーション・クライアントが存在するかどうかをフィードバックする、ステップをさらに含み、
端末デバイスにより、アプリケーション・クライアントをインストールするステップは特に、
ドメイン名に対応するアプリケーション・クライアントが存在する場合、端末デバイスにより、アプリケーション・クライアントをインストールするステップを含む。
【００１３】
第2の態様によれば、本発明の一実施態様は、
アクセスされることになるリソースに対応するユニフォーム・リソース・ロケータ（URL）を取得するように構成された取得モジュールと、
格納されているドメイン名が、URLに対応するドメイン名を含んでいるかどうかを検出するように構成された検出モジュールと、
格納されているドメイン名が、URLに対応するドメイン名を含んでいることを検出モジュールが検出した場合に、URLのドメイン名に対応するアプリケーション・クライアントをトリガーして、URLに対応するアプリケーション・クライアント・ページを取得して表示するように構成された処理モジュールとを含むページオペレーション処理装置を提供する。
【００１４】
第2の態様に関連して、第2の態様の第1の可能な実施様式においては、取得モジュールは特に、
アクセスされることになるリソースに対応し、かつユーザによって入力されるURLを取得すること、または
2次元コードをスキャンすることによって、アクセスされることになるリソースに対応するURLを取得すること、または
近距離無線通信を使用することによって、アクセスされることになるリソースに対応するURLを別のデバイスから取得することを行うように構成される。
【００１５】
第2の態様に関連して、第2の態様の第2の可能な実施様式においては、検出モジュールは特に、
データベースに格納されているドメイン名情報に従ってURL内の文字を1つずつ比較し、URLから第2レベルドメイン名を抽出して、URLのドメイン名を入手するか、またはURL内のデリミタに従ってURLから第2レベルドメイン名を抽出して、URLのドメイン名を入手し、検出モジュールがドメイン名を格納しているかどうかを決定するように構成され、
ここで、ドメイン名は、少なくとも第2レベルドメイン名を含む。
【００１６】
第2の態様に関連して、第2の態様の第3の可能な実施様式においては、URLのドメイン名に対応するアプリケーション・クライアントをトリガーして、URLに対応するアプリケーション・クライアント・ページを取得して表示することは、
アプリケーション・クライアントを始動して、URLをアプリケーション・クライアントへ送信し、それによって、アプリケーション・クライアントが、URLに対応するアプリケーション・クライアント・ページを取得したいという要求をネットワークサーバへ送信し、アプリケーション・クライアント・ページを表示する、ことを含み、または
第1の送信モジュールが特に、アクセスされることになるリソースを開くために使用可能なオプションのうちの1つとしてアプリケーション・クライアントの識別子および／またはアイコンをユーザに提示し、アプリケーション・クライアントの識別子および／またはアイコンをユーザが選択した後に、アプリケーション・クライアントを始動して、URLをアプリケーション・クライアントへ送信し、それによって、アプリケーション・クライアントが、URLに対応するアプリケーション・クライアント・ページを取得したいという要求をネットワークサーバへ送信し、アプリケーション・クライアント・ページを表示する、ように構成される。
【００１７】
第2の態様、または第2の態様の第1の可能な実施様式から第3の態様の第3の可能な実施様式のいずれか1つに関連して、第3の態様の第4の可能な実施様式においては、この装置は、
URLのドメイン名に対応するアプリケーション・クライアントがインストールされているかどうかを決定するように構成された決定モジュールをさらに含み、
処理モジュールは、アプリケーション・クライアントがインストールされていない場合に、アプリケーション・クライアントをインストールし、アプリケーション・クライアントに対応する少なくとも1つのドメイン名、ならびにアプリケーション・クライアントの識別子および／またはアイコンを格納するようにさらに構成される。
【００１８】
第2の態様の第4の可能な実施様式に関連して、第2の態様の第5の可能な実施様式においては、決定モジュールは特に、URLに対応するドメイン名と、ローカルに格納されているアプリケーション・クライアント・リストとの間におけるマッチングを実行し、マッチングが成功である場合には、アプリケーション・クライアントがインストールされていると決定し、マッチングが不成功である場合には、アプリケーション・クライアントがインストールされていないと決定するように構成される。
【００１９】
第2の態様の第5の可能な実施様式に関連して、第2の態様の第6の可能な実施様式においては、処理モジュールは、
URLに対応するドメイン名をサーバへ送信し、それによって、サーバが、ドメイン名に対応するアプリケーション・クライアントが存在するかどうかをフィードバックする、ように構成され、端末デバイスにより、アプリケーション・クライアントをインストールすることは特に、ドメイン名に対応するアプリケーション・クライアントが存在する場合に、アプリケーション・クライアントをインストールすることを含む。
【００２０】
第3の態様によれば、本発明の一実施態様は、端末を提供し、この端末は、
この端末上にインストールされているアプリケーション・クライアントに対応するドメイン名を格納するように構成されたメモリと、
アクセスされることになるリソースに対応するユニフォーム・リソース・ロケータ（URL）を取得し、格納されているドメイン名が、URLに対応するドメイン名を含んでいるかどうかを検出し、格納されているドメイン名が、URLに対応するドメイン名を含んでいることが検出された場合に、URLのドメイン名に対応するアプリケーション・クライアントをトリガーして、URLに対応するアプリケーション・クライアント・ページを取得して表示するように構成されたプロセッサとを含む。
【００２１】
第3の態様に関連して、第3の態様の第1の可能な実施様式においては、この端末は、
アクセスされることになるリソースに対応し、かつユーザによって入力されるURLを受信して、URLをプロセッサへ送信するように構成された入力デバイス、または
近距離無線通信を使用することによって、アクセスされることになるリソースに対応するURLを受信して、URLをプロセッサへ送信するように構成された近距離無線通信受信機をさらに含む。
【００２２】
第3の態様、または第3の態様の第1の可能な実施様式に関連して、第3の態様の第2の可能な実施様式においては、この端末は、
2次元コードイメージを取得して、2次元コードイメージをプロセッサへ送信するように構成されたイメージ取得デバイスをさらに含み、
プロセッサは、2次元コードイメージを解析して、リソースに対応するURLにアクセスするようにさらに構成される。
【００２３】
第3の態様に関連して、第3の態様の第3の可能な実施様式においては、格納されているドメイン名が、URLに対応するドメイン名を含んでいるかどうかを検出することは特に、
データベースに格納されているドメイン名情報に従ってURL内の文字を1つずつ比較し、URLから第2レベルドメイン名を抽出して、URLのドメイン名を入手するか、またはURL内のデリミタに従ってURLから第2レベルドメイン名を抽出して、URLのドメイン名を入手することと、
端末がドメイン名を格納しているかどうかを決定することとを含み、
ここで、ドメイン名は、少なくとも第2レベルドメイン名を含む。
【００２４】
第3の態様に関連して、第3の態様の第4の可能な実施様式においては、URLのドメイン名に対応するアプリケーション・クライアントをトリガーして、URLに対応するアプリケーション・クライアント・ページを取得して表示することは、
アプリケーション・クライアントを始動して、URLをアプリケーション・クライアントへ送信し、それによって、アプリケーション・クライアントが、URLに対応するアプリケーション・クライアント・ページを取得したいという要求をネットワークサーバへ送信し、アプリケーション・クライアント・ページを表示する、こと、または
アクセスされることになるリソースを開くために使用可能なオプションのうちの1つとしてアプリケーション・クライアントの識別子および／またはアイコンをユーザに提示し、アプリケーション・クライアントの識別子および／またはアイコンをユーザが選択した後に、アプリケーション・クライアントを始動して、URLをアプリケーション・クライアントへ送信し、それによって、アプリケーション・クライアントが、URLに対応するアプリケーション・クライアント・ページを取得したいという要求をネットワークサーバへ送信し、アプリケーション・クライアント・ページを表示する、ことを含む。
【００２５】
第3の態様、または第3の態様の第1の可能な実施様式から第3の態様の第4の可能な実施様式のいずれか1つに関連して、第3の態様の第5の可能な実施様式においては、プロセッサは、URLのドメイン名に対応するアプリケーション・クライアントがインストールされているかどうかを決定し、URLのドメイン名に対応するアプリケーション・クライアントがインストールされていない場合に、アプリケーション・クライアントをインストールし、アプリケーション・クライアントに対応する少なくとも1つのドメイン名、ならびにアプリケーション・クライアントの識別子および／またはアイコンを格納するようにさらに構成される。
【００２６】
第3の態様の第5の可能な実施様式に関連して、第3の態様の第6の可能な実施様式においては、URLのドメイン名に対応するアプリケーション・クライアントがインストールされているかどうかを決定することは、URLに対応するドメイン名と、ローカルに格納されているアプリケーション・クライアント・リストとの間におけるマッチングを実行し、マッチングが成功である場合には、アプリケーション・クライアントが端末デバイス上にインストールされていると決定し、マッチングが不成功である場合には、アプリケーション・クライアントが端末デバイス上にインストールされていないと決定することを含む。
【００２７】
第3の態様の第6の可能な実施様式に関連して、第3の態様の第7の可能な実施様式においては、
プロセッサは、URLに対応するドメイン名をサーバへ送信し、それによって、サーバが、ドメイン名に対応するアプリケーション・クライアントが存在するかどうかをフィードバックする、ようにさらに構成され、端末デバイスにより、アプリケーション・クライアントをインストールすることは特に、ドメイン名に対応するアプリケーション・クライアントが存在する場合に、アプリケーション・クライアントをインストールすることを含む。
【００２８】
本発明の実施態様は、ページオペレーション処理方法および装置、ならびに端末を提供する。この方法によれば、ウェブページ・リンクなど、アクセスされることになるリソースが、アプリケーション・クライアントを使用することによって開かれ、アプリケーション・クライアント・ページが、端末デバイス側で表示され、これによってネットワークトラフィックの消費が減り、ユーザオペレーションおよびページブラウジングが容易になり、それによってユーザ体験が改善される。
【００２９】
本発明の実施形態における技術的なソリューションをより明確に説明するために、以降では、それらの実施形態を説明する上で必要とされる添付の図面を簡単に紹介する。当然ながら、以降の説明における添付の図面は、本発明のいくつかの実施形態を示しているにすぎず、当技術分野における通常の知識を有する技術者であれば、創造的な労力を伴わずに、これらの添付の図面からその他の図面を導き出すことができる。
【図面の簡単な説明】
【００３０】
【図１】本発明によるページオペレーション処理方法の第1の実施形態の概略フローチャートである。
【図２】本発明によるページオペレーション処理方法の第2の実施形態の概略フローチャートである。
【図３】本発明によるページオペレーション処理方法の第3の実施形態の概略フローチャートである。
【図４】本発明によるページオペレーション処理方法の第4の実施形態のシグナリング図である。
【図５】本発明によるページオペレーション処理方法の第5の実施形態のシグナリング図である。
【図６】本発明によるページオペレーション処理方法の第6の実施形態のシグナリング図である。
【図７】本発明によるページオペレーション処理装置の第1の実施形態の概略構造図である。
【図８】本発明によるページオペレーション処理装置の第2の実施形態の概略構造図である。
【図９】本発明による端末の第1の実施形態の概略構造図である。
【発明を実施するための形態】
【００３１】
以降では、本発明の実施形態における添付の図面を参照しながら本発明の実施形態における技術的なソリューションを明確かつ十分に説明する。当然ながら、説明されている実施形態は、本発明の実施形態のうちのすべてではなく、一部にすぎない。当技術分野における通常の知識を有する技術者によって本発明の実施形態に基づいて創造的な取り組みを伴わずに得られるその他のすべての実施形態は、本発明の保護範囲内に収まるものとする。
【００３２】
第1の実施形態
図1は、本発明によるページオペレーション処理方法の第1の実施形態の概略フローチャートである。本発明のこの実施形態は、ページオペレーション処理方法を提供する。この方法は、ページオペレーション処理方法を実行する任意のページオペレーション処理装置によって実行することができ、その装置は、ソフトウェアおよび／またはハードウェアを使用することによって実施することができる。この実施形態においては、ページオペレーション処理装置を端末デバイス内に統合することができる。図1において示されているように、この実施形態による方法は、下記のステップを含む。
【００３３】
ステップ101．端末デバイスが、アクセスされることになるリソースに対応するURLを取得する。
【００３４】
具体的には、アクセスされることになるリソースは、複数の形態であることが可能であり、たとえば、ウェブページ・リンクであることが可能であり、イメージ・リンクおよびE-mail・リンクであることも可能である。現在、ユーザは、多くの様式でウェブページを共有することができ、たとえば、ユーザは、QQ、WeChat、およびMicrosoftサービスネットワーク（Microsoft Service Network、略してMSN）などのインスタント通信ソフトウェアを使用することによってウェブページを共有することができ、ユーザは、ショート・メッセージ・サービスおよびマルチメディア・メッセージ・サービスなどのメッセージング様式で、またはSina、Renren、およびウェブログ（Web log、略してBlog）などのソーシャルプラットフォームを使用することによってウェブページを共有することができ、ユーザは、2次元コードをスキャンすることによって、たとえば、モバイル電話を使用することにより2次元コードをスキャンすることによって、または近距離無線通信（Near Field Communication、略してNFC）様式で、たとえば、モバイル電話どうしの間における接触で、ウェブページ・リンクをさらに取得することができる。
【００３５】
ウェブページ・リンクを受信するユーザは、そのウェブページ・リンクをクリックすることによってウェブページへのアクセスを実施することができ、すなわち、ユーザが端末デバイス上でウェブページ・リンクをクリックしたときに、端末デバイスは、そのウェブページ・リンクに対応するURLを取得する。2次元コードをスキャンすること、またはNFC様式を使用することによってウェブページ・リンクが取得された後には、端末デバイスは、そのウェブページ・リンクに対応するURLを自動的に取得する。このシナリオにおいては、端末デバイスがウェブページ・リンクを取得した後に、ユーザは、そのウェブページ・リンクをクリックすることなくウェブページへのアクセスを実施することができる。
【００３６】
ステップ102．格納されているドメイン名が、URLに対応するドメイン名を含んでいるかどうかを端末デバイスが検出する。
【００３７】
具体的には、従来技術においては、端末デバイスのオペレーティングシステム、たとえば、アンドロイド（Android）システム、またはアップル社によって開発されたオペレーティングシステム（iOS）は、依然としてURLのドメイン名を認識することができない。したがって、そのシステムの既存のメカニズムが、本発明のこの実施形態において拡張される。たとえば、AndroidシステムのIntentメカニズムが拡張され、それによってAndroidシステムは、URLのドメイン名を認識することができる。たとえば、TaobaoのウェブサイトのURLに関して、システム拡張の後では、そのURLに含まれているtaobao.comというドメイン名を認識することができる。
【００３８】
URLを取得した後に、端末デバイスは、そのURLのドメイン名を分析し、分析結果に従って、そのURLのドメイン名に対応するアプリケーション（Application、略してAPP）クライアントが端末デバイス上にインストールされているかどうかを決定する、すなわち、そのURLのドメイン名が、端末デバイス上に格納されているドメイン名に含まれているかどうかを決定する。さらに、その決定の結果に従って、その後の処理が実行される。そのURLのドメイン名が、端末デバイス上に格納されているドメイン名に含まれている場合には、ステップ103が実行され、そのURLのドメイン名が、端末デバイス上に格納されているドメイン名に含まれていない場合には、従来技術に従って、端末デバイス上にインストールされているブラウザを使用することによって、そのURLがアクセスされ、またはアプリケーション・クライアントをインストールする必要があるかどうかをユーザに対してプロンプト表示する。これは、この実施形態において特に限定されるものではない。
【００３９】
ステップ103．格納されているドメイン名が、URLに対応するドメイン名を含んでいる場合には、端末デバイスが、URLのドメイン名に対応するアプリケーション・クライアントをトリガーして、URLに対応するアプリケーション・クライアント・ページを取得して表示する。
【００４０】
具体的には、ユーザは、アクセスされることになるリソースに対応するURLを取得し、そのURLに対応するアプリケーション・クライアントが、ユーザによって使用されている端末デバイス上にインストールされる。2つの条件が満たされている場合には、端末デバイスは、そのURLを、端末デバイス内にインストールされているアプリケーション・クライアントへ送り、アプリケーション・クライアントは、ネットワークサーバと対話および通信して、そのURLのドメイン名に対応するアプリケーション・クライアント・ページを取得し、端末デバイスは、そのアプリケーション・クライアント・ページをユーザに表示する。アプリケーション・クライアント・ページは、端末デバイスのスクリーンにマッチするページである。従来技術においてブラウザを使用することによって開かれたページと比較して、アプリケーション・クライアント・ページは、より少ないコンテンツを含む。たとえば、フォントおよびイメージなど、表示される情報のサイズは、相対的に大きい。
【００４１】
本発明のこの実施形態によれば、端末デバイスが、アクセスされることになるリソースに対応するURLのドメイン名を分析し、そのURLのドメイン名に対応するアプリケーション・クライアントをトリガーして、そのURLに対応するアプリケーション・クライアント・ページを取得してユーザに表示し、これによって、ネットワークトラフィックの消費が減る。加えて、アプリケーション・クライアント・ページは、端末デバイスのスクリーンにマッチし、これによって、ユーザのキーに基づく誤操作が減り、ユーザのページブラウジングが容易になり、それによってユーザ体験が改善される。
【００４２】
上記に基づいて、ステップ101は特に、端末デバイスにより、アクセスされることになるリソースに対応していてユーザによって入力されるURLを取得するステップ、または端末デバイスにより、2次元コードをスキャンすることによって、アクセスされることになるリソースに対応するURLを取得するステップ、または端末デバイスにより、近距離無線通信を使用することによって、アクセスされることになるリソースに対応するURLを別のデバイスから取得するステップを含むことができる。すなわち、アクセスされることになるリソースは、ユーザによって、たとえば、ユーザがウェブページ・リンクをクリックすること、またはウェブサイトを手動で入力することによって入力することができ、アクセスされることになるリソースに対応するURLは、2次元コードをスキャンすることによって、または端末デバイスどうしが互いに接触するという様式で取得することもできる。本発明のこの実施形態は、本発明の適用シナリオを増やすために、それらには限定されない。
【００４３】
上記に基づいて、ステップ102は特に、端末デバイスにより、データベースに格納されているドメイン名情報に従ってURL内の文字を1つずつ比較し、URLから第2レベルドメイン名を抽出して、URLのドメイン名を入手するステップ、または端末デバイスにより、URL内のデリミタに従ってURLから第2レベルドメイン名を抽出して、URLのドメイン名を入手するステップと、端末デバイスにより、端末デバイスがそのドメイン名を格納しているかどうかを決定するステップとを含むことができる。そのドメイン名は、少なくとも第2レベルドメイン名を含む。
【００４４】
ウェブページ・ドメイン名は一般に、ドメイン名を命名するためのルールに従って命名される。すなわち、ドメイン名は、トップ・レベル・ドメイン名および第2レベルドメイン名を含むさまざまなレベルへと分類することができる。トップ・レベル・ドメイン名は、カントリーコードおよび国際ドメイン名を含む。カントリーコードに関しては、たとえば、中国のドメイン名は.cnであり、日本のドメイン名は.jpであり、国際ドメイン名に関しては、たとえば、営利企業のドメイン名は.comであり、非営利組織のドメイン名は.orgである。第2レベルドメイン名とは、トップ・レベル・ドメイン名の下のドメイン名を指す。第2レベルドメイン名は、国際トップ・レベル・ドメイン名の下にある場合には、ibm、yahoo、およびmicrosoftなど、ドメイン名登録者のウェブ名を指し、国別トップ・レベル・ドメイン名の下にある場合には、com、edu、gov、およびnetなど、登録されている企業のタイプを表すシンボルを指す。
【００４５】
ドメイン名を命名するためのルールに従って、プログラムをコンパイルすることによってドメイン名を抽出することができる。たとえば、取得されたURLに関して、そのURLのトップ・レベル・ドメイン名を最初に抽出することができ、次いで第2レベルドメイン名が抽出され、最後にトップ・レベル・ドメイン名および第2レベルドメイン名を組み合わせて、そのURLのドメイン名を入手する。トップ・レベル・ドメイン名および第2レベルドメイン名を抽出するための方法は、限定されていない。その方法は、URL内のある文字から始めて、その後の各文字が、データベースに格納されているトップ・レベル・ドメイン名に従って1つずつ比較されて、URLのトップ・レベル・ドメイン名が入手され、次いでトップ・レベル・ドメイン名の最初の文字の左側から始めて、その前の各文字が、データベースに格納されている第2レベルドメイン名に従って1つずつ比較されて、URLの第2レベルドメイン名が入手される、といった具合に最終的にURLのドメイン名が入手されるという方法であることが可能である。あるいは、URLが直接、特別な文字（一般に「.」である）に従っていくつかの部分へと区分され、トップ・レベル・ドメイン名および第2レベルドメイン名が抽出される、といった方法であることも可能である。別の例に関しては、www.google.com.cn/XXXXXXについて、cnおよびcomというトップ・レベル・ドメイン名が、「.」による区分に従ってシーケンスにおいて抽出され、次いでgoogleが抽出され、したがってここではgoogle.com.cnが、抽出されるドメイン名であるということが検出される。
【００４６】
本発明の任意の実施形態において記載されているドメイン名は、アプリケーションに対応する少なくとも第2レベルドメイン名を含むということに留意されたい。たとえば、Taobaoのドメイン名は、少なくとも第2レベルドメイン名taobaoを含む。もちろん、taobao.comなどのトップ・レベル・ドメイン名がさらに含まれることも可能であるが、これも、本発明の実施形態においては限定されない。
【００４７】
上記に基づいて、ステップ103は特に、端末デバイスにより、アプリケーション・クライアントを始動して、URLをアプリケーション・クライアントへ送信し、それによってアプリケーション・クライアントが、そのURLに対応するアプリケーション・クライアント・ページを取得したいという要求をネットワークサーバへ送信し、アプリケーション・クライアント・ページを表示するステップ、または端末デバイスにより、アクセスされることになるリソースを開くために使用することができるオプションのうちの1つとしてアプリケーション・クライアントの識別子および／またはアイコンをユーザに提示し、アプリケーション・クライアントの識別子および／またはアイコンをユーザが選択した後に、アプリケーション・クライアントを始動して、URLをアプリケーション・クライアントへ送信し、それによってアプリケーション・クライアントが、そのURLに対応するアプリケーション・クライアント・ページを取得したいという要求をネットワークサーバへ送信し、アプリケーション・クライアント・ページを表示するステップを含むことができる。この実施形態においては、どの様式が端末デバイスによって使用されるかは、端末デバイスのオペレーティングシステムによって使用されているメカニズムに依存する。
【００４８】
上記に基づいて、ステップ103よりも前に、この方法は、端末デバイスにより、URLのドメイン名に対応するアプリケーション・クライアントがインストールされているかどうかを決定するステップと、URLのドメイン名に対応するアプリケーション・クライアントがインストールされていない場合には、端末デバイスにより、アプリケーション・クライアントをインストールし、アプリケーション・クライアントに対応する少なくとも1つのドメイン名、ならびにアプリケーション・クライアントの識別子および／またはアイコンを格納するステップとをさらに含む。端末デバイスにより、URLのドメイン名に対応するアプリケーション・クライアントがインストールされているかどうかを決定するステップは、端末デバイスにより、URLに対応するドメイン名と、ローカルに格納されているアプリケーション・クライアント・リストとの間におけるマッチングを実行するステップと、マッチングが成功である場合には、アプリケーション・クライアントが端末デバイス上にインストールされているということを決定するステップと、マッチングが不成功である場合には、アプリケーション・クライアントが端末デバイス上にインストールされていないということを決定するステップとを含む。この実施形態においては、アクセスされることになるURLに対応するアプリケーション・クライアントが端末デバイス上にインストールされているかどうかが最初に決定され、次いで、アプリケーション・クライアントがインストールされていない場合にはプロンプトメッセージが与えられ、それによってユーザは、インストレーションを実行するかどうかを独立して選択し、それによってユーザ体験が高まる。
【００４９】
さらに、端末デバイスにより、アプリケーション・クライアントをインストールするステップよりも前に、この方法は、端末デバイスにより、URLに対応するドメイン名をサーバへ送信し、それによってサーバが、ドメイン名に対応するアプリケーション・クライアントが存在するかどうかをフィードバックするステップをさらに含むことができ、端末デバイスにより、アプリケーション・クライアントをインストールするステップは特に、端末デバイスにより、ドメイン名に対応するアプリケーション・クライアントが存在する場合には、そのアプリケーション・クライアントをインストールするステップと、端末デバイスにより、そのアプリケーション・クライアントが存在しない場合には、ブラウザを使用することによってURLにアクセスするステップとを含む。
【００５０】
解析によって取得されたURLのドメイン名に従って、ドメイン名に対応するウェブサイトがアプリケーション・クライアントを有しているかどうかを端末デバイスが分析する上で利用可能ないくつかの主要な方法がある。
【００５１】
方法1：端末デバイスが、取得されたドメイン名と、ローカルに格納されているアプリケーション・クライアント・リストとの間におけるマッチングを実行し、そのアプリケーション・クライアント・リストは、電子市場（アンドロイド、アップルなど）によって提供され、共通のドメイン名と、それらの共通のドメイン名に対応するアプリケーション・クライアントに関する情報とを記録している。
【００５２】
URLのドメイン名に対応するアプリケーション・クライアントを端末デバイスがアプリケーション・クライアント・リストにおいて見つけ出した場合には、端末デバイスは、インストレーションを実行するためのプロンプト表示をユーザに対して行い、URLのドメイン名に対応するアプリケーション・クライアントを端末デバイスが見つけ出すことができない場合には、URLのドメイン名に対応するアプリケーション・クライアントが存在しないとみなされ、端末デバイスは、既存の方法に従って、すなわちブラウザを使用することによってURLに直接アクセスする。
【００５３】
方法2：クエリーメカニズムが端末デバイスと電子市場との間に加えられ、それによって端末デバイスおよび電子市場は、互いに通信することができる。端末デバイスは、ドメイン名を電子市場へ送信し、電子市場は、そのドメイン名に対応するアプリケーション・クライアントが存在するかどうかをフィードバックする。アプリケーション・クライアントが存在する場合には、端末デバイスは、インストレーションを実行するためのプロンプト表示をユーザに対して行い、アプリケーション・クライアントが存在しない場合には、端末デバイスは、既存の方法に従って、すなわちブラウザを使用することによってURLに直接アクセスする。
【００５４】
方法3：学習機能が端末デバイスに加えられる。ドメイン名に対応するアプリケーション・クライアントが端末デバイス上にインストールされていた場合には、オペレーティングシステムは、そのアプリケーション・クライアントに関する情報を保持する、すなわち、そのアプリケーション・クライアントに関する情報は、そのアプリケーション・クライアントがアンインストールされる際に破棄されない。
【００５５】
ドメイン名に対応するアプリケーション・クライアントがインストールされていたということを端末デバイスが検出した場合には、端末デバイスは、そのアプリケーション・クライアントに関する以前に保持されていた情報を呼び出し、インストレーションを実行するためのプロンプト表示をユーザに対して行い、そのアプリケーション・クライアントが以前にインストールされていなかった場合には、方法1または方法2に従って処理が実行される。
【００５６】
第2の実施形態
図2は、本発明によるページオペレーション処理方法の第2の実施形態の概略フローチャートである。この実施形態は、本発明において提供されるページオペレーション処理方法をアプリケーション・クライアントの観点から説明する。図2において示されているように、この実施形態による方法は、下記のステップを含む。
【００５７】
ステップ201．アプリケーション・クライアントが、オペレーティングシステムによって送信されたURLを受信する。
【００５８】
具体的には、端末デバイス上のアプリケーション・クライアントおよびオペレーティングシステムが、互いに対話する。端末デバイスが、アクセスされることになるリソースに対応するURLを取得した後に、端末デバイスのオペレーティングシステムは、そのURLのドメイン名を認識し、そのドメイン名に対応するアプリケーション・クライアントをトリガーする。すなわち、アプリケーション・クライアントは、オペレーティングシステムによって送信されたURLを受信する。
【００５９】
1つのアプリケーションが複数のドメイン名に対応していることが可能であるということに留意されたい。たとえば、TaobaoのウェブサイトのURLに関しては、そのURLに含まれているドメイン名は、taobao.comである。taobao.comは、1つのTaobaoアプリケーションに対応しているが、そのTaobaoアプリケーションに対応するドメイン名は、taobao.comに限定されず、taobao.com.cn、taobao.com.ukなどであることも可能である。端末デバイスは、TaobaoのウェブサイトのURLを取得し、端末デバイスのオペレーティングシステムは、taobao.comなど、TaobaoのウェブサイトのURLのドメイン名が、そのアプリケーションに対応している複数のドメイン名のうちの1つであり、あらかじめ端末デバイス上に格納されているということを認識する。次いでオペレーティングシステムは、そのTaobaoアプリケーションをトリガーし、そのTaobaoアプリケーションは、オペレーティングシステムによって送信されたTaobaoのウェブサイトのURLを受信する。
【００６０】
ステップ202．アプリケーション・クライアントが、URLに含まれているコンテンツ識別子を取得する。
【００６１】
具体的には、アプリケーション・クライアントは、そのURLを受信した後に、そのアプリケーション・クライアントのモードおよびコンテンツ識別子に従ってアクセス要求を生成する。たとえば、アプリケーション・クライアントのモードは、ネイティブおよびウェブの組み合わせられたモード（Native＋Web）であることが可能であり、たとえば、アプリケーション・クライアントは、Java（登録商標）テクノロジーを使用することによって開発されているが、アプリケーション・クライアントとネットワークサーバとの間における通信は、Webモードで行われる。アプリケーション・クライアントのモードは、ネイティブ（Native）モードであることも可能であり、たとえば、アプリケーション・クライアントは、Javaを使用することによって開発されているが、アプリケーション・クライアントとネットワークサーバとの間における通信も、Java命令を使用することによって行うことができる。アプリケーション・クライアントのモードが、組み合わせられたモードである場合には、コンテンツ識別子はURLそのものであり、アプリケーション・クライアントのモードがネイティブモードである場合には、コンテンツ識別子は、URL内のキー情報およびフィルタ条件であり、これは、この実施形態においては限定されない。
【００６２】
ステップ203．アプリケーション・クライアントが、コンテンツ識別子を含むアクセス要求をネットワークサーバへ送信する。
【００６３】
具体的には、アプリケーション・クライアントのモードが、組み合わせられたモードである場合には、アクセス要求はURLそのものであり、アプリケーション・クライアントは、URLをネットワークサーバへ送信し、アプリケーション・クライアントのモードがネイティブモードである場合には、アクセス要求は、URL内のキー情報およびフィルタ条件にマッチするアプリケーション要求であり、このケースにおいては、アプリケーション・クライアントは、ステップ202において取得されるURL内のキー情報およびフィルタ条件に関してマッピング処理を実行して、そのキー情報およびフィルタ条件にマッチするアプリケーション要求を生成し、そのアプリケーション要求を、ハイパーテキスト転送プロトコルGet（Hyper Text Transfer Protocol Get、略してHTTP GET）様式でJava命令を使用してネットワークサーバへ送信して、そのキー情報およびフィルタ条件に対応するアプリケーション・クライアント・ページを取得することを要求する。URL内のキー情報とは、アイデンティティー（Identity、略してID）情報など、URL内にあって、そのURLによって指し示されているページを一意に表す情報を指し、フィルタ条件とは、ユーザコメントおよび製品詳細など、IDに関連しているサブページを指す。
【００６４】
ステップ204．アプリケーション・クライアントが、ネットワークサーバによって返されてアクセス要求に対応しているアプリケーション・クライアント・ページを受信して表示する。
【００６５】
具体的には、アプリケーション・クライアント・ページは、従来技術においてブラウザを使用することによって開かれたページとは異なり、端末デバイスのスクリーンにマッチするページである。ブラウザを使用することによって開かれたページと比較して、アプリケーション・クライアント・ページは、より少ないイメージおよびより少ない情報を含み、それによって、ユーザにとってのネットワークトラフィックの消費が減る。
【００６６】
この実施形態においては、端末デバイスが、アプリケーション・クライアントを使用することによって、取得されることになるリソースに対応するURLにアクセスし、そのURLに対応するアプリケーション・クライアント・ページをユーザに表示し、これによって、ネットワークトラフィックの消費が減る。加えて、アプリケーション・クライアント・ページは、端末デバイスのスクリーンにマッチし、これによって、ユーザのキーに基づく誤操作が減り、ユーザのページブラウジングが容易になり、それによってユーザ体験が改善される。
【００６７】
上記に基づいて、アプリケーション・クライアントがネイティブ・アプリケーション・モードを使用している場合には、アプリケーション・クライアントによって、URLに含まれているコンテンツ識別子を取得するステップは、アプリケーション・クライアントによって、URLを分析して、そのURL内のキー情報およびフィルタ条件を取得するステップを含むことができる。
【００６８】
さらに、アプリケーション・クライアントによって、コンテンツ識別子を含むアクセス要求をネットワークサーバへ送信するステップは、アプリケーション・クライアントによって、URL内のキー情報およびフィルタ条件にマッチするアプリケーション要求をネットワークサーバへ送信するステップを含む。
【００６９】
アプリケーション・クライアントによって、URLに含まれているコンテンツ識別子を取得するステップ、およびアプリケーション・クライアントによって、コンテンツ識別子を含むアクセス要求をネットワークサーバへ送信するステップという2つのステップにおいて、アプリケーション・クライアントが、組み合わせられたアプリケーションモードを使用している場合には、URLを分析する必要はなく、アプリケーション要求を生成する必要もなく、その代わりに、URLはネットワークサーバへ直接送信される。なぜなら、このモードにおいては、アプリケーション・クライアントとネットワークサーバとの間における通信はWeb様式で行われるからである。
【００７０】
第3の実施形態
図3は、本発明によるページオペレーション処理方法の第3の実施形態の概略フローチャートである。この実施形態は、本発明において提供されるページオペレーション処理方法をネットワークサーバの観点から説明する。図3において示されているように、この実施形態による方法は、下記のステップを含む。
【００７１】
ステップ301．ネットワークサーバが、コンテンツ識別子を含んでいてアプリケーション・クライアントによって送信されるアクセス要求を受信し、そのコンテンツ識別子は、アプリケーション・クライアントによってURLから取得される。
【００７２】
具体的には、アクセス要求はURLそのものであることが可能であり、このケースにおいては、コンテンツ識別子もURLそのものであり、アクセス要求は、URL内のキー情報およびフィルタ条件にマッチするアプリケーション要求であることも可能であり、このケースにおいては、コンテンツ識別子は、URL内のキー情報およびフィルタ条件である。アプリケーション要求は一般に、アプリケーションキー（App Key）、サービスデータ、タイムスタンプなどを含み、App Keyは、アプリケーション・プログラミング・インターフェース（Application Programming Interface、略してAPI）が呼び出される場合のアプリケーション・クライアントの一意の識別子であり、App Keyは、アプリケーション・クライアントを識別するためにネットワークサーバによって使用される。
【００７３】
ステップ302．ネットワークサーバが、アクセス要求に従って、そのアクセス要求に対応するアプリケーション・クライアント・ページを決定する。
【００７４】
具体的には、アプリケーション・クライアントによって送信されたアクセス要求を受信した後に、ネットワークサーバは、アクセス要求に対応するアプリケーション・クライアント・ページをアプリケーション・クライアントへ送信し、それによりアプリケーション・クライアント・ページは、アプリケーション・クライアントを使用することによって表示される。
【００７５】
アプリケーション・クライアント・ページは、従来技術においてブラウザを使用することによって開かれたページとは異なり、端末デバイスのスクリーンにマッチするページである。ブラウザを使用することによって開かれたページと比較して、アプリケーション・クライアント・ページは、より少ないイメージおよびより少ない情報を含み、それによって、ユーザにとってのネットワークトラフィックの消費が減る。
【００７６】
ステップ303．ネットワークサーバが、アプリケーション・クライアント・ページをアプリケーション・クライアントへ送信する。
【００７７】
本発明のこの実施形態においては、端末デバイスが、ネットワークサーバおよびアプリケーション・クライアントを使用することによって、アクセスされることになるリソースに対応するURLにアクセスし、これによって、ネットワークトラフィックの消費が減る。加えて、アプリケーション・クライアント・ページが、端末デバイスのスクリーンにマッチし、これによって、ユーザのキーに基づく誤操作が減り、ユーザのページブラウジングが容易になり、それによってユーザ体験が改善される。
【００７８】
あるシナリオにおいては、アプリケーション・クライアントは、組み合わせられたアプリケーションモードを使用することができ、ネットワークサーバにより、アクセス要求に従って、そのアクセス要求に対応するアプリケーション・クライアント・ページを決定するステップは、下記の2つの条件を含む。
1．URLが、アプリケーション・クライアント・ページに対応するURLである場合には、ネットワークサーバは、そのURLに従って、アクセス要求に対応するアプリケーション・クライアント・ページを決定する。
2．ネットワークサーバは、そのURLに関してマッピング処理を実行し、そのURLによって指し示されているページに対応するアプリケーション・クライアント・ページを決定する。
【００７９】
別のシナリオにおいては、アプリケーション・クライアントは、ネイティブ・アプリケーション・モードを使用し、ネットワークサーバにより、コンテンツ識別子を含んでいてアプリケーション・クライアントによって送信されるアクセス要求を受信するステップは、ネットワークサーバにより、アプリケーション・クライアントによって送信されたアプリケーション要求を受信するステップを含み、そのアプリケーション要求は、URL内のキー情報およびフィルタ条件にマッチする。さらに、ネットワークサーバにより、アクセス要求に従って、そのアクセス要求に対応するアプリケーション・クライアント・ページを決定するステップは、ネットワークサーバにより、アプリケーション要求に対応するページを、アプリケーション・クライアントがインストールされている端末デバイスへ表示用として返すステップを含む。
【００８０】
以降では、ページオペレーション処理方法の技術的なソリューションについて、いくつかの特定の実施形態を使用することによって詳細に説明する。
【００８１】
第4の実施形態
図4において示されているように、本発明のこの実施形態において提供されるページオペレーション処理方法は、ユーザ、（アプリケーション・クライアントがインストールされている）端末デバイス、およびネットワークサーバの間において対話をシグナリングすることによって実施される。この実施形態においては、アプリケーション・クライアントは、端末デバイス内に統合され、端末デバイスは、スマートフォン、タブレットコンピュータなどであることが可能である。この実施形態および以降の実施形態は、例としてスマートフォンを使用することによって説明されており、アプリケーション・クライアントがスマートフォン上にインストールされていてユーザがウェブページ・リンクをクリックすることによってURLを取得するというシナリオにおける特定の実施様式である。もちろん、この実施形態および以降の実施形態はスマートフォンに限定されないということを当業者なら理解することができる。この実施形態における具体的なステップは、下記のとおりである。
【００８２】
ステップ401．ユーザがウェブページ・リンクをクリックするというオペレーション命令を受け取る。
【００８３】
ステップ402．URLを取得し、そのURLのドメイン名を解析する。
【００８４】
具体的には、スマートフォンのオペレーティングシステムが、ウェブページ・リンクに対応するURLを取得すること、そのURLのドメイン名を解析すること、およびそのドメイン名に対応するアプリケーション・クライアントがスマートフォン上にインストールされているかどうかを検出することが可能である。
【００８５】
そのオペレーティングシステムは、従来技術でURLのドメイン名を認識することができず、すなわち、URLが与えられた場合に、そのURLに含まれているドメイン名を従来技術でそのURLから抽出することができない。したがって、スマートフォンのオペレーティングシステムの既存のメカニズムを拡張する必要があり、それによってスマートフォンのオペレーティングシステムは、URLのドメイン名を認識することができる。
【００８６】
たとえば、TaobaoのウェブサイトのURL・リンクに関して、オペレーティングシステムのメカニズムが拡張された後に、スマートフォンのオペレーティングシステムは、そのURL・リンクがtaobao.comというドメイン名を含んでいるということを認識することができる。
【００８７】
スマートフォン上にアプリケーション・クライアントがインストールされているときに、アプリケーション・クライアントは、スマートフォンのオペレーティングシステムにページ処理機能を登録する。アプリケーション・クライアントのインストレーションファイルは、そのアプリケーションによってアクセスすることができるドメイン名を保持する。アプリケーション・クライアントがインストールされているときに、オペレーティングシステムは、そのアプリケーション・クライアントによってアクセスすることができるドメイン名を含むファイルを入手する。すなわち、アプリケーション・クライアントがインストールされているときに、アプリケーション・クライアントは、ドメイン名情報を含む登録ファイルをオペレーティングシステムへ送信して、ページ処理機能の登録を完了する。スマートフォンは、アプリケーション・クライアントに対応する少なくとも1つのドメイン名と、アプリケーション・クライアントの識別子とを格納し、それによってスマートフォンは、アプリケーション・クライアントが、アクセス・アドレス・ロケータ（URL）のドメイン名に対応するアプリケーション・クライアント・ページを開くことができるということを知る。ページ処理機能は、アプリケーション・クライアントが、そのアプリケーション・クライアントに対応するドメイン名を含むURLにアクセスすることができるということを示す。たとえば、Taobaoアプリケーションは、Androidシステムにおいてインストールされているときに、taobao.comというドメイン名を含むURLにアクセスする機能をAndroidシステムに登録する。
【００８８】
ステップ403．アクセス様式をプロンプト表示する。
【００８９】
具体的には、スマートフォンのオペレーティングシステムは、表示されるウィンドウにアプリケーション・クライアントの識別子を加えること、およびその識別子を、ウェブページ・リンクにアクセスすることができるオプションのうちの1つとしてユーザに提示することが可能である。
【００９０】
ステップ404．ユーザがアプリケーション・クライアントを始動することを選択しているというオペレーション命令を受け取る。
【００９１】
スマートフォンのオペレーティングシステムは、ユーザがアプリケーション・クライアントを始動することを選択しているというオペレーション命令を受け取る。
【００９２】
ステップ403およびステップ404は、任意選択のステップであり、ステップ405を直接実行することも可能である。
【００９３】
ステップ405．アプリケーション・クライアントを始動する。
【００９４】
具体的には、スマートフォンのオペレーティングシステムは、URLをアプリケーション・クライアントへ送信することができ、アプリケーション・クライアントは、スマートフォンのオペレーティングシステムによって送信されたURLを受信する。
【００９５】
スマートフォンのオペレーティングシステムは、下記の2つの様式でアプリケーション・クライアントをトリガーすることができる。
【００９６】
様式1：ステップ402が実行された後に、ステップ403およびステップ404が順に実行される。
【００９７】
様式2：ステップ402が実行された後に、ステップ405が直接実行される。
【００９８】
前述の2つの様式のうちのどちらの様式が使用されるかは、オペレーティングシステムによって使用されているメカニズムに依存する。たとえば、Androidシステムにおいては、
（1）Androidの明示的なインテントメカニズム（Explicit Intent）が使用されている場合には、Androidシステムは、ユーザがウェブページ・リンクをクリックしたときに、対応するアプリケーション・クライアントを直接開く。
（2）Androidの暗黙的なインテントメカニズム（Implicit Intent）が使用されている場合には、Androidシステムは、ユーザがウェブページ・リンクをクリックしたときに、選択用のウィンドウをユーザに表示する。
【００９９】
具体的には、Intentメカニズムは、実行されることになる1つのオペレーションを抽象的に記述するデータ構造であり、プログラム実行プロセスにおいて2つの異なるコンポーネントを接続する機能を提供する。アプリケーションプログラムが、Intentメカニズムを使用することによって、あるタイプの要求情報をAndroidシステムへ送信し、Androidシステムは、その要求情報の内容に従って、その要求メッセージを処理することができるコンポーネントを選択する。たとえば、電話をかけるために、Android電話が使用される。ダイヤルキーが押されると、コールボタン（CALL_BUTTON）行為を有するIntentオブジェクトが、Androidシステムへ送信される。Androidシステムは、要求情報に従って、およびアプリケーションが登録されているAndroidMnifest.xmlファイルから、その要求情報を処理することができる電話番号ダイヤリングプログラムを見つけ出す。電話番号が入力されて再びダイヤルキーが押されると、ダイヤリングプログラムは、アクションコール（ACTION_CALL）と電話番号データとを含むIntent要求をAndroidシステムへ送信し、Androidシステムは、処理のために適切なアプリケーションプログラムを見つけ出す。
【０１００】
コンポーネント名を明確に指定するIntentが、明示的なIntentであり、Androidシステムは、そのコンポーネント名によって指定されているターゲットコンポーネントを直接始動して、要求を処理する。
【０１０１】
ターゲットコンポーネントを明確に指定しないIntentは、暗黙的なIntentと呼ばれている。暗黙的なIntentは、明確なターゲットを有しておらず、したがってAndroidシステムは、アプリケーションが、要求を処理するために適切なターゲットコンポーネントを見つけ出すのを補助しなければならない。このタイプのIntentメッセージのための解析メカニズムを選択するための特定の方法は、AndroidManifest.xmlファイルに登録されていて、Intentメッセージを処理することができるそれぞれのコンポーネントを定義するために使用されるすべてのIntentFilterフィルタを取り出し、それらのフィルタをそのIntentメッセージの内容と比較することである。ある暗黙的なIntent要求の内容が、あるコンポーネントにおけるIntentFilterフィルタのフィルタリングルールにマッチしている場合には、Androidシステムは、そのコンポーネントを、その暗黙的なIntentメッセージを処理するためのターゲットコンポーネントとして選択する。
【０１０２】
この実施形態においては、アプリケーション・クライアントは、Native＋Webモードを使用するアプリケーション・クライアントである。このモードにおいては、たとえば、アプリケーション・クライアントは、Javaテクノロジーを使用することによって開発されているが、アプリケーション・クライアントとネットワークサーバとの間における通信は、Webモードで行われる。
【０１０３】
ステップ406．アプリケーション・クライアントが、コンテンツ識別子を含むアクセス要求をネットワークサーバへ送信する。
【０１０４】
アプリケーション・クライアントは、ネットワークサーバと通信し、コンテンツ識別子、すなわちURLを含むアクセス要求をネットワークサーバへ送信する。
【０１０５】
ステップ407．ネットワークサーバが、アクセス要求を分析する。
【０１０６】
ネットワークサーバは、アプリケーション・クライアントによって送信されたURLを受信した後に、そのURLを下記のように分析する。
（1）そのURLが、アプリケーション・クライアントに対応するURLである場合には、ネットワークサーバは直接、そのURLに対応するアプリケーション・クライアント・ページをアプリケーション・クライアントに返す。
（2）そのURLが、アプリケーション・クライアントに対応するURLではない場合、たとえば、そのURLが、パーソナルコンピュータ（Personal Computer、略してPC）に対応するURL、またはモバイル電話ブラウザに対応するURLである場合には、ネットワークサーバは、そのURLに関してマッピング処理を実行し、そのURLによって指し示されているページに対応するアプリケーション・クライアント・ページをアプリケーション・クライアントに返す。
【０１０７】
本発明の任意の実施形態においては、同じドメイン名に関して、PC上に表示されるページと、モバイル電話ブラウザ上に表示されるページと、アプリケーション・クライアント上に表示されるページとは異なるということに留意されたい。ネットワークサーバは、同じURLのページどうしの1つのセットまたは2つのセットを格納することができるが、これは、本明細書においては限定されない。たとえば、ネットワークサーバがページどうしの1つのセットを格納しているが、一般にスタイルシートと呼ばれているカスケーディング・スタイル・シート（Cascading Style Sheet、略してCSS）どうしの2つのセットがある場合には、ネットワークサーバは、ユーザ端末のタイプに従って自動的な決定を実行することができ、ネットワークサーバがページどうしの2つのセットを格納していて、一方のセットが、PCに対応するページに関するものであり、他方のセットが、モバイル電話ブラウザに対応するページに関するものである場合には、ネットワークサーバ・エンドは、URLの送信者に従ってURLに関してマッピングを実行し、送信者のタイプに従って、送信者にマッチするページを送信者に返す。
【０１０８】
ステップ408．ネットワークサーバが、アプリケーション・クライアント・ページをアプリケーション・クライアントへ送信する。
【０１０９】
ステップ409．アプリケーション・クライアントが、アプリケーション・クライアント・ページをユーザに表示する。
【０１１０】
本発明のこの実施形態においては、ユーザがウェブページ・リンクをクリックした後に、そのウェブページ・リンクが、アプリケーション・クライアント、モバイル電話、およびネットワークサーバの間において対話をシグナリングすることによって分析され、そのウェブページ・リンクに対応するアプリケーション・クライアント・ページが、アプリケーション・クライアントを使用することによってアクセスされ、これによって、ネットワークトラフィックの消費およびユーザのキーに基づく誤操作が減り、それによって、ユーザのページブラウジングがさらに容易になり、ユーザ体験が改善される。
【０１１１】
第5の実施形態
図5において示されているように、本発明のこの実施形態において提供されるページオペレーション処理方法は、ユーザ、アプリケーション・クライアント、端末デバイス、およびネットワークサーバの間において対話をシグナリングすることによって実施され、例として、スマートフォンである端末デバイスが使用されている。この実施形態は、アプリケーション・クライアントがスマートフォン上にインストールされているというシナリオにおける別の特定の実施様式である。具体的なステップは、下記のとおりである。
【０１１２】
ステップ501からステップ505は、第4の実施形態におけるステップ401からステップ405と同じであり、詳細についてここで再び説明することはしない。
【０１１３】
ステップ506．アプリケーション・クライアントが、端末デバイスによって送信されたURLを受信し、アプリケーション要求を生成する。
【０１１４】
具体的には、この実施形態においては、アプリケーション・クライアントは、ネイティブ・アプリケーション・モードを使用するアプリケーション・クライアント、すなわち、Nativeモードにあるアプリケーション・クライアントである。このモードが示しているのは、アプリケーション・クライアントは、Javaテクノロジーを使用することによって開発されているが、アプリケーション・クライアントとネットワークサーバとの間における通信はJava命令を使用するということである。たとえば、アプリケーション・クライアントとネットワークサーバとの間における通信は、ハイパーテキスト転送プロトコル（Hypertext Transfer Protocol、略してHTTP）のGET様式を使用することによって行うことができ、すなわち、その通信はHTTP GET様式で行われ、HTTP GETは一般に、リソース情報の取得／クエリーを行うために使用される。
【０１１５】
この実施形態においては、アプリケーション・クライアントは、受信されたURLを分析し、そのURLからキー情報およびフィルタ条件を抽出し、そのキー情報およびフィルタ条件に従って、そのキー情報およびフィルタ条件に対応するアプリケーション要求を生成する。キー情報とは、ID情報など、URL内にあって、そのURLによって指し示されているページを一意に表す情報を指し、フィルタ条件とは、ユーザコメントおよび製品詳細など、IDに関連しているサブページ情報を指す。フィルタ条件およびキー情報はともに、アプリケーション・クライアント・ページに含まれているコンテンツを決定し、そのコンテンツは、テキストおよびイメージなどの情報を含むことができる。
【０１１６】
ステップ507．アプリケーション・クライアントが、アプリケーション要求をネットワークサーバへ送信する。
【０１１７】
具体的には、この実施形態においては、アプリケーション要求とは、ステップ506において生成されてURL内のキー情報およびフィルタ条件にマッチするアプリケーション要求を指す。アプリケーション・クライアントは、ステップ506において取得されるURL内のキー情報およびフィルタ条件に従ってマッピング処理を実行し、そのキー情報およびフィルタ条件にマッチするアプリケーション要求を生成する。そのアプリケーション要求は、Java命令であり、すなわち、アプリケーション・クライアントおよびネットワークサーバは、HTTP GET様式でJava命令を使用することによって直接通信する。
【０１１８】
アプリケーション・クライアントは、アプリケーション要求をHTTP GET様式でネットワークサーバへ送信して、URL内のキー情報およびフィルタ条件に対応するアプリケーション・クライアント・ページを取得することを要求する。
【０１１９】
ステップ508．ネットワークサーバが、アプリケーション・クライアント・ページをアプリケーション・クライアントへ送信する。
【０１２０】
本発明のこの実施形態と第4の実施形態との間における違いは、この実施形態においては、ネットワークサーバがアプリケーション要求に関して分析およびマッピングを実行する必要がなく、アプリケーション要求によって指定されたアプリケーション・クライアント・ページをアプリケーション・クライアントに直接返すという点にあるということに留意されたい。これは、第4の実施形態におけるステップ408においては、アプリケーション・クライアントがWeb様式でネットワークサーバと通信し、URLが送信され、PC、モバイル電話ブラウザ、およびアプリケーション・クライアントに対応する同じページの各URLが異なり、分析する必要があるからである。たとえば、コンピュータにおいてChromeブラウザによってアクセスされたショップのURLが、http://shop68404486.taobao.com/?spm=0.0.0.0.4BGcaMであり、モバイル電話上でUCブラウザによってアクセスされたショップのURLが、http://shop.m.taobao.com/shop/shop_index.htm?shop_id=68404486&sid=96cdb91451601574であり、モバイル電話上でTaobaoアプリケーションによってアクセスされたショップのURLが、http://shop.m.taobao.com/shop/shop_index.htm?user_id=374476867である。別々のURLは別々の様式に対応しているということを知ることができる。この実施形態においては、アプリケーション要求が、HTTP GET様式でJava命令を使用することによってネットワークサーバとの通信を行うために使用され、それ以上そのアプリケーション要求に関して分析およびマッピングを実行する必要はない。
【０１２１】
ステップ509．アプリケーション・クライアントが、アプリケーション・クライアント・ページを受信し、そのアプリケーション・クライアント・ページをユーザに表示する。
【０１２２】
本発明のこの実施形態においては、ユーザがウェブページ・リンクをクリックした後に、そのウェブページ・リンクが、スマートフォンのオペレーティングシステム、スマートフォン上にインストールされているアプリケーション・クライアント、およびネットワークサーバの間において対話をシグナリングすることによって分析され、そのウェブページ・リンクに対応するアプリケーション・クライアント・ページが、アプリケーション・クライアントを使用することによってアクセスされ、これによって、ネットワークトラフィックの消費およびユーザのキーに基づく誤操作が減り、それによって、ユーザのページブラウジングがさらに容易になり、ユーザ体験が改善される。
【０１２３】
第6の実施形態
前述の実施形態に基づいて、この実施形態は、アプリケーション・クライアントが端末デバイス上にインストールされていないという条件を考慮に入れており、それは、第4の実施形態に基づいて説明されている。図6において示されているように、
【０１２４】
ステップ601は、ステップ401と同じである。
【０１２５】
ステップ602．スマートフォンのオペレーティングシステムが、ウェブページ・リンクに対応するURLを取得し、解析によってそのURLのドメイン名を取得し、そのドメイン名に対応するアプリケーション・クライアントがスマートフォン上にインストールされているかどうかを検出する。
【０１２６】
そのドメイン名に対応するアプリケーション・クライアントがスマートフォン上にインストールされていない場合には、スマートフォンは、そのURLが、対応するアプリケーション・クライアントを有しているかどうかを分析する。
【０１２７】
具体的には、下記の様式で分析が実行される。
【０１２８】
様式1：スマートフォンが、取得されたドメイン名と、ローカルに格納されているアプリケーション・クライアント・リストとの間におけるマッチングを実行する。そのアプリケーション・クライアント・リストは、サーバ（特に電子市場のサーバであることが可能である）によって提供され、共通のドメイン名と、それらの共通のドメイン名に対応するアプリケーション・クライアントに関する情報とを記録している。
【０１２９】
URLのドメイン名に対応するアプリケーション・クライアントをスマートフォンがアプリケーション・クライアント・リストにおいて見つけ出した場合には、ステップ603が実行され、URLのドメイン名に対応するアプリケーション・クライアントを見つけ出すことができない場合には、URLのドメイン名に対応するアプリケーション・クライアントが存在しないとみなされ、スマートフォンは、既存の方法に従って、すなわちブラウザを使用することによってURLに直接アクセスする。
【０１３０】
様式2：クエリーメカニズムがスマートフォンと電子市場との間に加えられ、それによってスマートフォンおよび電子市場は、互いに通信することができる。スマートフォンは、ドメイン名を電子市場へ送信し、電子市場は、そのドメイン名に対応するアプリケーション・クライアントが存在するかどうかをフィードバックする。アプリケーション・クライアントが存在する場合には、ステップ603が実行され、アプリケーション・クライアントが存在しない場合には、スマートフォンは、既存の方法に従って、すなわちブラウザを使用することによってURLに直接アクセスする。
【０１３１】
様式3：学習機能がスマートフォンに加えられる。ドメイン名に対応するアプリケーション・クライアントがスマートフォン上にインストールされていた場合には、オペレーティングシステムは、そのアプリケーション・クライアントに関する情報を保持する、すなわち、そのアプリケーション・クライアントに関する情報は、そのアプリケーション・クライアントがアンインストールされる際に破棄されない。
【０１３２】
ドメイン名に対応するアプリケーション・クライアントがインストールされていたということをスマートフォンが検出した場合には、スマートフォンは、そのアプリケーション・クライアントに関する以前に保持されていた情報を呼び出し、ステップ603が実行され、そのアプリケーション・クライアントが以前にインストールされていなかった場合には、様式1または様式2における方法に従って処理が実行される。
【０１３３】
任意選択で、前述の方法は、下記のステップをさらに含むことができる。
【０１３４】
ステップ603．スマートフォンのオペレーティングシステムが、アプリケーション・クライアントをインストールするかどうかをユーザにプロンプト表示する。
【０１３５】
具体的には、アプリケーション・クライアントをインストールすることをユーザが選択した場合には、スマートフォンは、ネットワークサーバと通信し、そのアプリケーション・クライアントのインストレーションプログラムをネットワークサーバからダウンロードし、ダウンロードが完了した後にスマートフォン上でインストレーションを実行し、そのアプリケーション・クライアントに対応する少なくとも1つのドメイン名と、そのアプリケーション・クライアントの識別子および／またはアイコンとを格納する。インストレーションが完了した後に、オペレーティングシステムは、URLにアクセスするためにアプリケーション・クライアントを直接呼び出す。その後のオペレーションステップに関しては、第4の実施形態におけるステップ403からステップ409および第5の実施形態におけるステップ503からステップ509への参照を行い、詳細についてここで再び説明することはしない。
【０１３６】
加えて、アプリケーション・クライアントをインストールするかどうかを端末デバイスがユーザにプロンプト表示した場合に、「今後はインストレーションに関するプロンプト表示を行わない」などのオプションを設定することができる。アプリケーション・クライアントをインストールしないことをユーザが選択した場合には、従来技術における方法に従ってオペレーションが実行され、スマートフォン上でブラウザを使用することによってウェブページ・リンクがアクセスされる。ユーザが、アプリケーション・クライアントをインストールしないことを選択したが、「今後はインストレーションに関するプロンプト表示を行わない」などのオプションを選択しなかった場合には、そのウェブサイトドメイン名を含むURLをユーザが次回クリックしてアクセスしたときに、スマートフォンは、アプリケーション・クライアントをインストールするかどうかを尋ねるオプションを引き続きユーザにプロンプト表示する。ユーザが、アプリケーション・クライアントをインストールしないことを選択し、「今後はインストレーションに関するプロンプト表示を行わない」などのオプションを選択した場合には、スマートフォンは、従来技術における方法に従ってブラウザを使用することによってURLにアクセスし、そのウェブサイトドメイン名を含むURLをユーザが次回クリックしてアクセスしたときに、デフォルトでブラウザを使用することによってURLにアクセスし、アプリケーション・クライアントをインストールするかどうかをそれ以上ユーザにプロンプト表示しない。
【０１３７】
本発明のこの実施形態においては、ウェブページ・リンクに対応するアプリケーション・クライアントがスマートフォン上にインストールされていない場合には、ユーザは、アプリケーション・クライアントをインストールするかどうかを独立して選択し、それによってユーザは、ウェブページ・リンクにアクセスするためにブラウザを使用するか、またはアプリケーション・クライアントを使用するかを独立してさらに決定することができ、これによって、ユーザの選択肢がさらに多く提供される。
【０１３８】
第7の実施形態
この実施形態と前述の実施形態との間における違いは、URLに対応するページをアプリケーション・クライアントが開くことができないという条件をこの実施形態が考慮に入れているという点にある。アプリケーション・クライアントによって送信されたURLまたはアプリケーション要求をネットワークサーバが受信した後に、対応するアプリケーション・クライアント・ページをネットワークサーバ上で見つけ出すことができない場合に実行される処理方法は特に、下記を含むことができる。
【０１３９】
あるアプリケーションシナリオにおいては、アプリケーション・クライアントがNative＋Webモードを使用する、すなわち、本発明の第4の実施形態における対応するアプリケーション・クライアントである。このアプリケーションシナリオにおいては、この実施形態と第4の実施形態との間における違いは、下記のとおりである。
【０１４０】
ネットワークサーバが、アプリケーション・クライアントによって送信されたURLを受信し、そのURLを分析した後に、ネットワークサーバは、そのURLに対応するアプリケーション・クライアント・ページがネットワークサーバ上に存在しないが、ネットワークサーバが、PCに対応するURLのページ、またはブラウザに対応するURLのページを格納しているということに気づく。このケースにおいては、ネットワークサーバは、そのURLに対応するアプリケーション・クライアント・ページを見つけ出すことができないという応答をクライアントに返す。
【０１４１】
そのURLに対応するアプリケーション・クライアント・ページを見つけ出すことができないという、ネットワークサーバによって返された応答を受信した後に、アプリケーション・クライアントは、デフォルトのブラウザを使用することによってそのURLにアクセスするようスマートフォンにプロンプト表示する。さらにスマートフォンは、デフォルトのブラウザを呼び出すことによってそのURLにアクセスする。
【０１４２】
ネットワークサーバが、URLを分析した後に、そのURLに対応するアプリケーション・クライアント・ページがネットワークサーバ上に存在しないということ、ならびにPCに対応するURLのページおよびブラウザに対応するURLのページがネットワークサーバ上に存在しないということ、すなわち、そのURLに対応するページがまったく存在しないということに気づいた場合には、ネットワークサーバは、エラー応答をアプリケーション・クライアントに返し、アプリケーション・クライアントは、ページが存在しないということをユーザに示す。
【０１４３】
別のアプリケーションシナリオにおいては、アプリケーション・クライアントがNativeモードを使用する、すなわち、本発明の第5の実施形態における対応するアプリケーション・クライアントである。このケースにおいては、この実施形態と前述の実施形態との間における違いは、下記のとおりである。
【０１４４】
ネットワークサーバは、アプリケーション・クライアントによって送信されたアプリケーション要求を受信した後に、そのアプリケーション要求に対応するアプリケーション・クライアント・ページをネットワークサーバ上で見つけ出すことができず、したがってエラー応答をアプリケーション・クライアントに返す。アプリケーション・クライアントは、ネットワークサーバによって返されたエラー応答を受信した後に、デフォルトのブラウザを使用することによってURLにアクセスするようスマートフォンにプロンプト表示する。
【０１４５】
この実施形態においては、ユーザがウェブページ・リンクをクリックした後の処理状況をユーザに通知するために、そのウェブページ・リンクに対応するページがネットワークサーバ側に格納されていないという情報が返され、それによってユーザは、別の様式でウェブページ・リンクにアクセスすることができ、それによってリンク処理効率が改善され、ユーザ体験が高まる。
【０１４６】
第8の実施形態
図7は、本発明によるページオペレーション処理装置の第1の実施形態の概略構造図である。本発明のこの実施形態におけるページオペレーション処理装置は、端末内に統合することができる。図7において示されているように、この実施形態におけるページオペレーション装置は、取得モジュール701、検出モジュール702、および処理モジュール703を含む。
【０１４７】
取得モジュール701は、アクセスされることになるリソースに対応するURLを取得するように構成されており、検出モジュール702は、格納されているドメイン名が、そのURLに対応するドメイン名を含んでいるかどうかを検出するように構成されており、処理モジュール703は、格納されているドメイン名が、そのURLに対応するドメイン名を含んでいるということを検出モジュール702が検出した場合に、そのURLのドメイン名に対応するアプリケーション・クライアントをトリガーして、そのURLに対応するアプリケーション・クライアント・ページを取得して表示するように構成されている。
【０１４８】
この実施形態におけるページオペレーション処理装置は、前述のページオペレーション処理方法の実施形態のうちの任意の実施形態における技術的なソリューションを実行するために使用することができる。この実施形態における実施原理および技術的効果は、方法実施形態における実施原理および技術的効果と同様であり、詳細についてここで再び説明することはしない。
【０１４９】
さらに、取得モジュール701は特に、アクセスされることになるリソースに対応していてユーザによって入力されるURLを取得することができ、または取得モジュール701は特に、2次元コードをスキャンすることによって、アクセスされることになるリソースに対応するURLを取得し、または取得モジュール701は特に、近距離無線通信を使用することによって、アクセスされることになるリソースに対応するURLを別のデバイスから取得する。
【０１５０】
上記に基づいて、検出モジュール702は特に、データベースに格納されているドメイン名情報に従ってURL内の文字を1つずつ比較し、URLから第2レベルドメイン名を抽出して、URLのドメイン名を入手するか、またはURL内のデリミタに従ってURLから第2レベルドメイン名を抽出して、URLのドメイン名を入手し、検出モジュール702がそのドメイン名を格納しているかどうかを決定する。
【０１５１】
さらに、URLのドメイン名に対応するアプリケーション・クライアントをトリガーして、そのURLに対応するアプリケーション・クライアント・ページを取得して表示するステップは、アプリケーション・クライアントを始動して、URLをアプリケーション・クライアントへ送信し、それによってアプリケーション・クライアントが、そのURLに対応するアプリケーション・クライアント・ページを取得したいという要求をネットワークサーバへ送信し、アプリケーション・クライアント・ページを表示するステップを含み、または処理モジュール703は特に、アクセスされることになるリソースを開くために使用することができるオプションのうちの1つとしてアプリケーション・クライアントの識別子および／またはアイコンをユーザに提示し、アプリケーション・クライアントの識別子および／またはアイコンをユーザが選択した後に、アプリケーション・クライアントを始動して、URLをアプリケーション・クライアントへ送信し、それによってアプリケーション・クライアントが、そのURLに対応するアプリケーション・クライアント・ページを取得したいという要求をネットワークサーバへ送信し、アプリケーション・クライアント・ページを表示するように構成されている。
【０１５２】
さらに、図7に基づいて、図8において示されているように、この装置は、決定モジュール801をさらに含むことができる。決定モジュール801は、URLのドメイン名に対応するアプリケーション・クライアントがインストールされているかどうかを決定するように構成されており、処理モジュール703はさらに、アプリケーション・クライアントがインストールされていない場合には、アプリケーション・クライアントをインストールし、アプリケーション・クライアントに対応する少なくとも1つのドメイン名、ならびにアプリケーション・クライアントの識別子および／またはアイコンを格納するように構成されている。
【０１５３】
さらに、決定モジュール801は特に、URLに対応するドメイン名と、ローカルに格納されているアプリケーション・クライアント・リストとの間におけるマッチングを実行し、マッチングが成功である場合には、アプリケーション・クライアントがインストールされているということを決定し、マッチングが不成功である場合には、アプリケーション・クライアントがインストールされていないということを決定するように構成されている。
【０１５４】
さらに、処理モジュール703はさらに、URLに対応するドメイン名をサーバへ送信し、それによってサーバが、ドメイン名に対応するアプリケーション・クライアントが存在するかどうかをフィードバックするように構成されることが可能であり、端末デバイスにより、アプリケーション・クライアントをインストールするステップは特に、ドメイン名に対応するアプリケーション・クライアントが存在する場合には、そのアプリケーション・クライアントをインストールするステップを含む。
【０１５５】
第9の実施形態
図9は、本発明による端末の第1の実施形態の概略構造図である。図9において示されているように、この端末は、メモリ91およびプロセッサ92を含む。
【０１５６】
メモリ91は、端末上にインストールされているアプリケーション・クライアントに対応するドメイン名を格納するように構成されている。プロセッサ92は、アクセスされることになるリソースに対応するURLを取得し、メモリ91に格納されているドメイン名が、そのURLに対応するドメイン名を含んでいるかどうかを検出し、格納されているドメイン名が、そのURLに対応するドメイン名を含んでいるということが検出された場合には、そのURLのドメイン名に対応するアプリケーション・クライアントをトリガーして、そのURLに対応するアプリケーション・クライアント・ページを取得して表示するように構成されている。
【０１５７】
この端末は、前述の方法実施形態を実行することができ、この実施形態における実施原理は、前述の方法実施形態における実施原理と同様であり、詳細についてここで再び説明することはしない。
【０１５８】
この実施形態においては、端末が、アプリケーション・クライアントを使用することによって、ウェブページ・リンクなど、アクセスされることになるリソースを開き、端末デバイス側でアプリケーション・クライアント・ページを表示する。アプリケーション・クライアント・ページは、ブラウザを使用することによって一般的に開かれたページとは異なり、イメージおよびテキストなど、アプリケーション・クライアント・ページに含まれている情報の量は、ブラウザを使用することによって開かれたページに含まれている情報の量よりも少なく、それによってネットワークトラフィックの消費が減り、ユーザオペレーションおよびページブラウジングが容易になり、アプリケーション・クライアント・ページ上のフォントは、ブラウザを使用することによって開かれたページ上のフォントよりも大きく、それによって誤操作が減り、ユーザ体験が改善される。
【０１５９】
図9において示されている実施形態に基づいて、この端末は、入力デバイス93、および近距離無線通信受信機94、およびイメージ取得デバイス95の任意の組合せをさらに含むことができる。入力デバイス93は、アクセスされることになるリソースに対応していてユーザによって入力されるURLを受信して、そのURLをプロセッサ92へ送信するように構成されている。近距離無線通信受信機94は、近距離無線通信を使用することによって、アクセスされることになるリソースに対応するURLを受信して、そのURLをプロセッサ92へ送信するように構成されている。イメージ取得デバイス95は、2次元コードイメージを取得して、その2次元コードイメージをプロセッサ92へ送信するように構成されており、このケースにおいては、プロセッサ92は、その2次元コードイメージを解析して、アクセスされることになるリソースに対応するURLを入手するようにさらに構成されている。本明細書における入力デバイス93は、命令を端末に入力するために使用することができるキーボード、タッチスクリーン、姿勢認識デバイス、またはその他の任意のデバイスであることが可能である。近距離無線通信は、無線周波数識別（RFID）、Bluetooth（登録商標）、およびZigBeeなどの短距離通信標準を含む。イメージ取得デバイス95は、カメラまたはスキャナなど、イメージを取得するために使用されるデバイスであることが可能である。
【０１６０】
格納されているドメイン名が、そのURLに対応するドメイン名を含んでいるかどうかを検出するステップは特に、データベースに格納されているドメイン名情報に従ってURL内の文字を1つずつ比較し、URLから第2レベルドメイン名を抽出して、URLのドメイン名を入手するステップ、またはURL内のデリミタに従ってURLから第2レベルドメイン名を抽出して、ULRのドメイン名を入手するステップと、端末がそのドメイン名を格納しているかどうかを決定するステップとを含むことができ、そのドメイン名は、少なくとも第2レベルドメイン名を含む。
【０１６１】
さらに、URLのドメイン名に対応するアプリケーション・クライアントをトリガーして、そのURLに対応するアプリケーション・クライアント・ページを取得して表示するステップは、アプリケーション・クライアントを始動して、URLをアプリケーション・クライアントへ送信し、それによってアプリケーション・クライアントが、そのURLに対応するアプリケーション・クライアント・ページを取得したいという要求をネットワークサーバへ送信し、アプリケーション・クライアント・ページを表示するステップ、またはアクセスされることになるリソースを開くために使用することができるオプションのうちの1つとしてアプリケーション・クライアントの識別子および／またはアイコンをユーザに提示し、アプリケーション・クライアントの識別子および／またはアイコンをユーザが選択した後に、アプリケーション・クライアントを始動して、URLをアプリケーション・クライアントへ送信し、それによってアプリケーション・クライアントが、そのURLに対応するアプリケーション・クライアント・ページを取得したいという要求をネットワークサーバへ送信し、アプリケーション・クライアント・ページを表示するステップを含む。
【０１６２】
任意選択で、プロセッサ92は、URLのドメイン名に対応するアプリケーション・クライアントがインストールされているかどうかを決定し、URLのドメイン名に対応するアプリケーション・クライアントがインストールされていない場合には、アプリケーション・クライアントをインストールし、アプリケーション・クライアントに対応する少なくとも1つのドメイン名、ならびにアプリケーション・クライアントの識別子および／またはアイコンを格納するようにさらに構成されることが可能である。
【０１６３】
さらに、URLのドメイン名に対応するアプリケーション・クライアントがインストールされているかどうかを決定するステップは、URLに対応するドメイン名と、ローカルに格納されているアプリケーション・クライアント・リストとの間におけるマッチングを実行するステップと、マッチングが成功である場合には、アプリケーション・クライアントが端末デバイス上にインストールされているということを決定するステップと、マッチングが不成功である場合には、アプリケーション・クライアントが端末デバイス上にインストールされていないということを決定するステップとを含む。
【０１６４】
さらに、プロセッサ92はさらに、URLに対応するドメイン名をサーバへ送信し、それによってサーバが、アプリケーション・クライアントに対応するアプリケーション・クライアントが存在するかどうかをフィードバックするように構成されており、端末デバイスにより、アプリケーション・クライアントをインストールするステップは特に、ドメイン名に対応するアプリケーション・クライアントが存在する場合には、そのアプリケーション・クライアントをインストールするステップを含む。
【０１６５】
本出願において提供されているいくつかの実施形態においては、開示されているデバイスおよび方法をその他の様式で実施することも可能であるということを理解されたい。たとえば、説明されているデバイス実施形態は、例示的なものにすぎない。たとえば、ユニットまたはモジュールの区分は、論理的な機能区分にすぎず、実際の実施においてはその他の区分であってもよい。たとえば、複数のユニットまたはモジュールを別のシステムへと組み合わせることまたは統合することが可能であり、またはいくつかの機能を無視することまたは実行しないことも可能である。加えて、表示されているまたは論じられている相互の結合または直接の結合または通信接続は、いくつかのインターフェースを通じて実施されることが可能である。デバイスまたはモジュールどうしの間における間接的な結合または通信接続は、電子的な形態、機械的な形態、またはその他の形態で実施されることが可能である。
【０１６６】
別々の部分として説明されているモジュールどうしは、物理的に別々であることも、または物理的に別々ではないことも可能であり、モジュールとして表示されている部分は、物理的なモジュールであることも、または物理的なモジュールではないことも可能であり、1つの位置に配置されることも可能であり、または複数のネットワークユニット上に分散されることも可能である。モジュールのうちのいくつかまたはすべては、実施形態のソリューションの目的を達成するために実際のニーズに従って選択されることが可能である。
【０１６７】
方法実施形態のステップのうちのすべてまたはいくつかは、関連するハードウェアに命令するプログラムによって実施することができるということを当技術分野における通常の知識を有する技術者なら理解することができる。そのプログラムは、コンピュータ可読ストレージメディア内に格納することができる。そのプログラムが作動したときに、方法実施形態のステップが実行される。前述のストレージメディアは、プログラムコードを格納することができる任意のメディア、たとえば、ROM、RAM、磁気ディスク、または光ディスクを含む。
【０１６８】
最後に、前述の実施形態は、本発明の技術的なソリューションを説明することを意図しているにすぎず、本発明を限定することを意図したものではないということに留意されたい。本発明について、前述の実施形態を参照しながら詳細に説明したが、当技術分野における通常の知識を有する技術者であれば、本発明の実施形態の技術的なソリューションの範囲から逸脱することなく、前述の実施形態において説明されている技術的なソリューションに対する修正形態を作成すること、またはそれらの技術的な特徴のいくつかまたはすべてに対する均等な代替形態を作成することが可能であるということを理解できよう。
【符号の説明】
【０１６９】
701  取得モジュール
702  検出モジュール
703  処理モジュール
801  決定モジュール
91  メモリ
92  プロセッサ
93  入力デバイス
94  近距離無線通信受信機
95  イメージ取得デバイス
【図１】
0006414855.tif 000002
【図２】
0006414855.tif 000003
【図３】
0006414855.tif 000004
【図４】
0006414855.tif 000005
【図５】
0006414855.tif 000006
【図６】
0006414855.tif 000007
【図７】
0006414855.tif 000008
【図８】
0006414855.tif 000009
【図９】
0006414855.tif 000010