JP2019519036A - アプリケーション起動方法及びシステム - Google Patents

Abstract

本願の実施は、アプリケーション（アプリ）起動方法及びシステムを開示する。この方法の実施には、ウェブページを第１のローカルアプリにより開いて、第２のローカルアプリを呼び出すことを試みるステップと；ローカルサーバを第２のローカルアプリにより起動するステップと；ＪＳ参照リクエストを第１のローカルアプリによりローカルサーバへ送信するステップと；ローカルサーバによって返される応答を受信したとき、第１のローカルアプリにより、指定されたダウンロードページへのジャンプを停止するステップと；を含む。本願の実施によれば、開かれたページ（及び第１のローカルアプリも）は、この開かれたページ（及び第１のローカルアプリも）が存在する端末デバイスに、対応するアプリ（第２のローカルアプリ）がインストールされていることを確認できる。

Description

本願はコンピュータソフトウェア技術の分野に関し、特に、アプリケーション起動方法及びシステムに関する。

モバイルデバイス用プラットフォームは、モバイルデバイスのオペレーティングシステムに基づいて開発されたアプリケーション（アプリ）を提供して様々なユーザ指向の機能を実施できる。例えば、Ａｐｐｌｅ（登録商標）のｉＯＳプラットフォームは、ｉＯＳシステムに基づいて開発されたモバイルデバイスアプリを提供し、Ｇｏｏｇｌｅ（登録商標）のＡｎｄｒｏｉｄ（登録商標）プラットフォームは、Ａｎｄｒｏｉｄ（登録商標）システムに基づいて開発されたモバイルデバイスアプリを提供し、そしてＷｉｎｄｏｗｓ（登録商標）モバイルデバイスプラットフォームは、Ｗｉｎｄｏｗｓ（登録商標）システムに基づいて開発されたモバイルデバイスアプリを提供する。

このようなモバイルデバイスプラットフォーム上のアプリは、他のアプリを用いて起動できる。例えば、ＳＭＳアプリによって受信されるＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）のメッセージは、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）アドレスを含む。ユーザがＳＭＳメッセージ内のＵＲＬアドレスをタップすると、モバイルデバイスはウェブページを開くことができる。ウェブページは、モバイルデバイスのデフォルトブラウザを用いて開くことができる。別の例では、モバイルデバイス上のローカルアプリＡ（例えば、チケット購入アプリ）は、ローカルアプリＡに結びつけられたＷｅｂＶｉｅｗコンポーネントを用いて決済取引中に決済ページを開き、更に、ローカルアプリＢ（例えば、支払いアプリ）を決済ページ上で起動できる。

例えば、モバイルデバイスのＳＭＳアプリ内の特定のＳＭＳメッセージは、ＡＬＩＰＡＹのリンクアドレスを含むことができる。ユーザがＳＭＳメッセージ内のリンクアドレスをタップした後、モバイルデバイスは、デフォルトブラウザを用いてリンクアドレスに対応するページを開くことができる。このページでは、ユーザがＡＬＩＰＡＹウォレットアプリで操作を行えるように、スキームＵＲＩ（Ｓｃｈｅｍｅ ＵＲＩ）を用いてローカルアプリＢ（例えばＡＬＩＰＡＹウォレットアプリ）を呼び出す試みを更に行うことができる。スキームＵＲＩは、システムレベルのリソース位置表記法であり、Ａｎｄｒｏｉｄ（登録商標）、ｉＯＳ、及びＷｉｎｄｏｗｓ（登録商標）の各モバイルプラットフォームシステムをサポートする。上記の例では、ＡＬＩＰＡＹウォレットアプリが呼び出された後、ほとんどのモバイルプラットフォームシステムでは、ブラウザアプリによって開かれたページは閉じられることはなく、短時間の後にアプリダウンロードページへジャンプする。このように、ＡＬＩＰＡＹウォレットアプリがモバイルデバイスにインストールされていても、ブラウザがジャンプするページにはプロンプトが表示され、ＡＬＩＰＡＹウォレットアプリをダウンロードするようユーザに指示する。

別の例では、ローカルアプリＡがＷｅｂＶｉｅｗコンポーネントを用いてリンクアドレスに対応するページを開くことができるように、モバイルデバイス上のローカルアプリＡを操作してＴＡＯＢＡＯ上の商品のリンクアドレスを開くことができる。このページでは、ユーザがＴＡＯＢＡＯアプリで操作を実行できるように、スキームＵＲＩを用いてローカルアプリＢ（例えばＴＡＯＢＡＯアプリ）を呼び出す試みを更に行うことができる。同様に、上記の例では、ＴＡＯＢＡＯアプリが呼び出された後、ほとんどのモバイルプラットフォームシステムでは、ローカルアプリＡのＷｅｂＶｉｅｗコンポーネントによって開かれたページは閉じられることはなく、短時間の後、アプリダウンロードページへジャンプする。このように、ＴＡＯＢＡＯアプリがモバイルデバイスにインストールされていても、ＷｅｂＶｉｅｗコンポーネントがジャンプするページにはプロンプトが表示され、ＴＡＯＢＡＯアプリのダウンロードをユーザに指示する。

既存技術では、ウェブページが開かれ、対応するアプリが呼び出された後、開かれたウェブページは、対応するアプリがモバイルデバイスにインストールされていることを知得できないということが見て取れる。よって、モバイルデバイスは、対応するアプリがモバイルデバイスにインストールされているかどうかにかかわらず、アプリダウンロードページへ導かれる。通信プロセスは長くなり、リソースは浪費され、ユーザエクスペリエンスは損なわれる。

本願の実施の目的は、開かれたページが存在する端末デバイスに、対応するアプリがインストールされていることを、開かれたページが確認できるような、アプリケーション（アプリ）起動方法及びシステムを提供することである。

上記の技術的課題を解決するために、本願の実施は以下のように実施される。

アプリケーション起動方法であって：ウェブページを第１のローカルアプリにより開き、第２のローカルアプリを呼び起こすステップと；ローカルサーバを前記第２のローカルアプリにより起動するステップと；ＪＳ（Ｊａｖａ（登録商標） Ｓｃｒｉｐｔ）参照リクエストを前記ローカルサーバへ、前記第１のローカルアプリにより送信するステップと；前記ローカルサーバによって返される応答を受信したとき、前記第１のローカルアプリにより、指定されたダウンロードページへのジャンプを停止するステップと；を含む。

アプリケーション起動システムであって：ウェブページを開き、第２のローカルアプリを呼び出すように構成され、ＪＳ参照リクエストをローカルサーバへ送信するように更に構成され、前記ローカルサーバによって返される応答を受信すると、指定されたダウンロードページへのジャンプを停止するように更に構成された、第１のローカルアプリと；前記ローカルサーバを起動するように構成された前記第２のローカルアプリと；前記第１のローカルアプリによって送信された前記ＪＳ参照リクエストを受信し、前記ＪＳ参照リクエストを受信したときに前記第１のローカルアプリへ前記応答を返すように構成された前記ローカルサーバと；を含む。

本願の実施で提供される技術的解決策から見て取れることは、第２のローカルアプリがローカルサーバを起動した後、たとえ、別のアプリと第２のローカルアプリとが異なるプロセス内に存在しても、ローカルサーバは、別のアプリが送信した要求に応答できるということである。このように、ローカルサーバは、第１のローカルアプリによって送信されたＪＳ参照リクエストを受信すると、応答を返すことができる。ローカルサーバによって返される応答が受信された場合、第１のローカルアプリは、呼び出された第２のローカルアプリがローカルサーバを起動した、と特定できる。言い換えれば、第２のローカルアプリは呼び出されており、第１のローカルアプリは、特定の指示されたダウンロードページへジャンプする必要はない。更に、第１のローカルアプリは、指示されたダウンロードページへのジャンプを停止できる。

本願の実施における又は既存技術における、技術的解決策をより明確に説明するために、本願の実施又は既存技術の説明に必要な添付図面を簡単に以下説明する。明らかに、以下の説明における添付図面は本願の実施例の一部を示すにすぎず、当業者であれば、創造的な努力を要することなく、これらの添付図面から別の図面を得ることができる。

図１は、本願に係るアプリケーション起動方法の実施を示すフローチャートである。

本願の実施は、アプリケーション（アプリ）を起動するための方法及びシステムを提供する。

当業者が本願の技術的解決策をより良く理解するよう、本願の実施における添付図面に関連して、本願の実施における技術的解決策を明確かつ完全に以下説明する。明らかに、記載の実施は本願の実施の全てではなく、その一部に過ぎない。本願の実施に基づき当業者が創造的な努力を要することなく得られる他の全ての実施は、本願の保護範囲に含まれる。

上記の既存技術では、ブラウザによって開かれたウェブページ、又は、ローカルアプリＡ（例えば、前述のブラウザアプリやチケット購入アプリ）のＷｅｂＶｉｅｗコンポーネントを用いて開かれたウェブページは、呼び出されたローカルアプリＢとは、概して異なる。その上、ブラウザ又はローカルアプリＡ及びローカルアプリＢは異なるプロセスに存在する。既存技術では、呼び出しプロセスに対するプロセス間の通信方法はない。したがって、ローカルアプリＡは、ローカルアプリＢが呼び出されたことを知得できず、ローカルアプリＡは依然として、指示されたアプリＢのダウンロードページへジャンプしてしまう。

本願の実施は、アプリ起動方法を提供する。図１は、その実施を実現するフローを示す。図１に示すように、この方法は以下を含む。

Ｓ１１０．第１のローカルアプリがウェブページを開き、第２のローカルアプリを呼び起こす（ウェイクアップする）。

ウェブページのリンクアドレスがタップなどの操作によってトリガされ開かれると、対応するウェブページを、ブラウザアプリに、又はローカルアプリのＷｅｂＶｉｅｗコンポーネントのプロセスにロードすることができる。ブラウザアプリ、又はローカルアプリのＷｅｂＶｉｅｗコンポーネントは、ウェブページのアドレスに含まれるパラメータを統一リソース識別子（ＵＲＩ）に結合できる。ＵＲＩは、スキームＵＲＩ（若しくはＵＲＩスキーム）又はカスタムスキームＵＲＩとも呼ばれる。ＵＲＩは、統一リソース識別子（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）の名前付け構造であり、リソースを記述できる。ここでいうリソースは広範な概念であり、いわゆるＷｅｂリソース、ローカルデバイス上のファイル、又はネットワーク上のビデオなどの可能性がある。ＵＲＩは以下の形式をとることができる。
ｈｔｔｐ：／／ｗｒｉｔｅ．ｂｌｏｇ．ｃｓｄｎ．ｎｅｔ／ｐｏｓｔｅｄｉｔ／７３１３５４３
ｆｉｌｅ：／／／ｃ：／ＷＩＮＤＯＷＳ／ｃｌｏｃｋ．ａｖｉ
Ｇｉｔ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｕｓｅｒ／ｐｒｏｊｅｃｔ−ｎａｍｅ．ｇｉｔ
ｆｔｐ：／／ｕｓｅｒ１：１２３４＠ ａｄｄｒｅｓｓ
ｅｄ２ｋ：／／｜ｆｉｌｅ｜％５ＢＭＡＣ％Ｅ７％８９％８８％Ｅ６％９Ｅ％８１％Ｅ５％９３％８１％Ｅ９％Ａ３％９Ｅ％Ｅ８％ＢＤ％Ａ６９％ＥＦ％ＢＣ％９Ａ％Ｅ６％９Ｃ％８０％Ｅ９％ＡＢ％９８％Ｅ９％８０％９Ａ％Ｅ７％ＢＣ％８９％５Ｄ．％５ＢＭＡＣＧＡＭＥ％５ＤＮｅｅｄ．Ｆｏｒ．Ｓｐｅｅｄ．Ｍｏｓｔ．Ｗａｎｔｅｄ．ｄｍｇ｜４０９６９３３８８８｜２ｃ５５ｆ０ａｄ２ｃｂ７ｆ６ｂ２９６ｄｂ９４０９０ｂ６３ｅ８８ｅ｜ｈ＝ｌｔｃｘｕｖｎｐ２４ｕｆｘ２５ｈ２ｘ７ｕｇｆａｘｆｃｈｊｋｗｘａ｜／

全体として、例えば、ＵＲＩは以下の形式をとる。
ｓｃｈｅｍｅ：／／ｈｏｓｔ：［ｐｏｒｔ］／ｐａｔｈ？ｑｕｅｒｙＫｅｙ＝ｑｕｅｒｙＶａｌｕｅ

ｓｃｈｅｍｅはスキーム名を示すものであって、前述のｈｔｔｐ、ｆｉｌｅ、Ｇｉｔ、及びｅｄ２ｋは全てスキーム名を示し；ｈｏｓｔはホストアドレスを示し；ｐａｔｈはパスを示し；ｑｕｅｒｙＫｅｙ＝ｑｕｅｒｙＶａｌｕｅはクエリキーの値を示し；ｐｏｒｔはポートを示す（オプション）。

例えば、ＳＭＳアプリ内にＳＭＳメッセージがあり、ＳＭＳメッセージのコンテンツには、以下の形式のリンクアドレスが含まれる。
ｈｔｔｐ：／／ｗｗｗ．ａｌｉｐａｙ．ｃｏｍ／ｃｕｓｔｏｍ．ｈｔｍｌ？ｓｃｈｅｍｅＵｒｌ＝ ｚｍＶｅｒｉｆｙ％３ａ％２ｆ％２ｆｓｃｈｅｍｅＡｐｉ％２ｆｓｔａｒｔＡｐｐ％３ｆｂｕｎｄｌｅＩｄ％３ｄ２０００１１８％２６ｖｅｒｓｉｏｎ％３ｄ１．５．１

ｚｍＶｅｒｉｆｙ％３ａ％２ｆ％２ｆｓｃｈｅｍｅＡｐｉ％２ｆｓｔａｒｔＡｐｐ％３ｆｂｕｎｄｌｅＩｄ％３ｄ２０００１１８％２６ｖｅｒｓｉｏｎ％３ｄ１．５．１は、リンク内のパラメータであり、ＵＲＬエンコード後に得られるＵＲＩである（ｚｍＶｅｒｉｆｙ：／／ｓｃｈｅｍｅＡｐｉ／ｓｔａｒＡｐｐ？ｂｕｎｄｌｅＩｄ＝２０００１１８＆ｖｅｒｓｉｏｎ＝１．５．１は、ＵＲＬデコード後に得られる）。ｚｍＶｅｒｉｆｙは、ＺＭＣｅｒｔｉｆｉｃａｔｉｏｎ（セサミクレジット、あるいはゴマ信用）アプリを示す。ＡＬＩＰＡＹウォレットアプリの例は、ａｌｉｐａｙ：／／ｓｃｈｅｍｅＡｐｉ／ｓｔａｒｔＡｐｐ？ｂｕｎｄｌｅＩｄ＝２０００１１８＆ｖｅｒｓｉｏｎ＝１．５．１．である。システムは、命令文を作成してアプリを呼び出すアプリを、ｚｍＶｅｒｉｆｙのスキームを用いて見つけることができる。スキームＡＰＩ（ｓｃｈｅｍｅＡｐｉ）、ｓｔａｒｔアプリ、ｂｕｎｄｌｅＩＤ、ｖｅｒｓｉｏｎなどはすべて任意のパラメータである。スキームＡＰＩは、ｑｑ．ｃｏｍやａｌｉｐａｙ．ｃｏｍなどのドメイン名のドメインと同等である。ｓｔａｒｔアプリ、ｂｕｎｄｌｅＩＤ、ｖｅｒｓｉｏｎ、又はより多くの他の同様のパラメータに対して、第２のアプリは、例えば、特定のウェブページを開いたり、音楽を再生したり、通知を送信したりするなどのサービス要求に基づいてこれらのパラメータを処理できる。

ＳＭＳアプリ内のリンクアドレスがトリガされ開かれた後、デフォルトブラウザのアプリを有効にして（イネーブル化して）リンクアドレスを開くことができる。オープンプロセスにおいて、端末デバイスのブラウザアプリは、リンクアドレス内のＵＲＩをパース（解析）し、ＵＲＩによって識別されるアプリに基づいて、対応するリンクリソースにアクセスすることができる。端末デバイスのブラウザは、ウェブページデータ内のＪＳ（Ｊａｖａ（登録商標） Ｓｃｒｉｐｔ）コードをパースすることにより、ＵＲＩを結合し、これを取得できる。

例えば、ＵＲＩによって識別されるアプリがＡＬＩＰＡＹアプリである場合、システムＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を用いて、対応するＡＬＩＰＡＹアプリを呼び出すことができ、上記のリンクアドレスで記述されたリソースは、ＡＬＩＰＡＹアプリでアクセスすることができる。同様に、ＵＲＩによって識別されるアプリがＴＡＯＢＡＯアプリである場合、システムＡＰＩを用いて、対応するＴＡＯＢＡＯアプリを呼び出すことができ、上記のリンクアドレスによって記述されるリソースをＴＡＯＢＡＯアプリで開くことができる。

前述の実施例では、デフォルトブラウザアプリがＳ１１０における第１のローカルアプリであり、呼び出されるＡＬＩＰＡＹアプリ又はＴＡＯＢＡＯアプリは第２のローカルアプリである。

同様に、第１のローカルアプリは、ＷｅｂＶｉｅｗコンポーネント、例えば特定のショッピングアプリと統合するアプリであり得る。ショッピングアプリはＷｅｂＶｉｅｗと統合し、統合されたＷｅｂＶｉｅｗアプリを用いて特定のリンクを開くことができる。ウェブページ閲覧（ブラウジング）機能を実施できるＷｅｂＶｉｅｗコンポーネントに統合されているので、デフォルトのブラウザアプリを、プロセス中に必ずしも有効にする必要はない。

前述した第１のローカルアプリ及び第２のローカルアプリは、異なるプロセス内に存在するので、互いに、直接、通信することはできない。

Ｓ１２０．第２のローカルアプリがローカルサーバを起動する。

本願のこの実施では、呼び出された後、第２のローカルアプリはローカルサーバを起動できる。ローカルサーバはＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）サーバであり、ＨＴＴＰリクエスト（例えば、ＨＴＴＰ ＧＥＴリクエスト）を受信して、これに応答できる。ソフトウェアプログラムを用いてサーバを設定し、これを起動できる。このような内容は、既存技術で広く適用されており、説明を簡単にするために詳細は述べない。例えば、ローカルサーバのアドレスは１２７．０．０．１：ｐｒｏｔである。１２７．０．０．１は、ローカルサーバを指すループバックアドレスとも呼ばれ、一般に、テストに用いられる。アプリ又はプログラムがループバックアドレスを用いてデータを送信すると、プロトコルソフトウェアは対応する情報を直ちに返すが、これはネットワーク経由では送信されない。

更に、呼び出された後、第２のローカルアプリは、第２のローカルアプリが閲覧（ブラウジング）又は他の操作をユーザに提供するように、前述のリンクアドレスに対応するリソースにアクセスすることができる。

Ｓ１３０．第１のローカルアプリが、ＪＳ参照リクエストをローカルサーバへ送信する。

第１のローカルアプリは、起動されたローカルサーバへＪＳ参照リクエストを送信できる。

本願のこの実施で送信されるＪＳ参照リクエストは、ＪＳＯＮＰ（ＪＳＯＮ ｗｉｔｈ Ｐａｄｄｉｎｇ）技術を用いる。ＪＳＯＮＰは情報フォーマットであり、ウェブページが他のネットワークドメインから情報を取得できるようにするＪＳＯＮ「使用モード」である。更に、ＪＳＯＮＰはオリジン間リソース共有（Ｃｒｏｓｓ−Ｏｒｉｇｉｎ Ｒｅｓｏｕｒｃｅ Ｓｈａｒｉｎｇ、ＣＯＲＳ）を実現できる。一般に、同一オリジンポリシ（Ｓａｍｅ−Ｏｒｉｇｉｎ Ｐｏｌｉｃｙ）に起因して、ｓｅｒｖｅｒ１．ｅｘａｍｐｌｅ．ｃｏｍ内のウェブページは、ｓｅｒｖｅｒ１．ｅｘａｍｐｌｅ．ｃｏｍ外のサーバと通信できない。ただし、ＨＴＭＬ（Ｈｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）の＜ｓｃｒｉｐｔ＞要素は例外である。オープンポリシ（Ｏｐｅｎ ｐｏｌｉｃｙ）、すなわち＜ｓｃｒｉｐｔ＞要素によって、ウェブページは他のオリジンによって動的に生成されたデータ情報を取得できる。そのような使用モードがＪＳＯＮＰである。

本願のこの実施では、第１のローカルアプリによって送信されたＪＳ参照リクエストの例は、次のとおりである。
＜ｓｃｒｉｐｔ＞ｈｔｔｐ：／／１２７．０．０．１：８８８８／ａ．ｊｓ＜／ｓｃｒｉｐｔ＞

＜ｓｃｒｉｐｔ＞＜ｓｃｒｉｐｔ＞は動的に追加されたタグであり、ＪＳ参照リクエストを示す。１２７．０．０．１は、ローカルデバイスのアドレス、つまり起動されたローカルサーバのアドレスである。８８８８はポート番号であり、通常、デフォルト値である。代替として用いられるポート番号は、第２のローカルアプリにより起動されるローカルサーバとの間で、第１のローカルアプリによって事前取決めされた別のポート番号であってもよい。

第１のローカルアプリは、ウェブページに＜ｓｃｒｉｐｔ＞タグを動的に追加することによって生成されたローカルサーバのアドレスを含むＪＳ参照リクエストを、ローカルサーバへ送信できる。

Ｓ１４０．第１のローカルアプリは、ローカルサーバによって返される応答を受信すると、指定のダウンロードページへのジャンプを停止する。

第２のローカルアプリがローカルサーバを起動した後は、別のアプリ及び第２のローカルアプリが異なるプロセス内に存在する場合であっても、ローカルサーバは別のアプリによって送信されたリクエストに応答できる。

このように、ローカルサーバは、第１のローカルアプリによって送信されたＪＳ参照リクエストを受信すると、応答を返すことができる。応答は、あらゆるタイプの応答、又は、サービスに基づく事前取決めによる応答である。後者については、第１のローカルアプリがローカルサーバによって返される応答を受信し、応答が事前取決めによる応答を満たす場合、第１のローカルアプリは、呼び出された第２のローカルアプリがローカルサーバを起動した、と特定できる。言い換えれば、第２のローカルアプリは呼び出されており、第１のローカルアプリは、特定の指定されたダウンロードページへジャンプする必要はない。更に、第１のローカルアプリは、指定されたダウンロードページへのジャンプを停止できる。

第１のローカルアプリは、所定応答時間内に、ローカルサーバによって返される応答を受信する。言い換えれば、第１のローカルアプリは、所定応答時間内にローカルサーバによって返される応答を受信すると、指定のダウンロードページへのジャンプを停止する。

更に、第１のローカルアプリは、第１のローカルアプリが、所定応答時間内に、ローカルサーバによって返される応答を受信しない場合、指定されたダウンロードページへジャンプすることができる。ジャンプ先である指定されたダウンロードページは、ウェブページの論理回路で指定できる。加えて、このような設定は既存技術で実施済みであるので、説明を簡単にするために詳細には述べない。

ポートは、事前取決めによるポート番号群のうちの１つであってもよい。例えば、Ｓ１２０で第２のローカルアプリによって起動されたローカルサーバ上のポートは、ポート群のうちの１つである。ポート群には、８８８８、８８８９、及び８８９０が含まれる。Ｓ１３０で第１のローカルアプリによって送信されるＪＳ参照リクエスト内のポートも、ポート群のうちの１つであってよい。初期状態で、デフォルトポートを８８８８としてもよい。このように、Ｓ１２０で第２のローカルアプリによって起動されるローカルサーバ上のポートは、ポート８８８８であり、Ｓ１３０で第１のローカルアプリによって送信されるＪＳ参照リクエスト内のポートも、ポート８８８８である。したがって、ローカルサーバはＪＳ参照リクエストを受け取ることができる。時に、ポート８８８８は別のアプリによって占有されることがある。この場合、Ｓ１２０でローカルサーバを起動すると、第２のローカルアプリは、そのポート８８８８が占有されており、ポート８８８９に切り替わっていることが判る。その結果、第１のローカルアプリがＳ１３０でポート８８８８を用いてＪＳ参照リクエストを送信すると、ローカルサーバはＪＳ参照リクエストを受信できない。所定時間、例えば２０ｍｓの間に第１のローカルアプリがローカルサーバによって返される応答を受信しない場合、第１のローカルアプリは、所定ポート群内の別のポートへ変更して、ＪＳ参照リクエストを再び送信できる。ＪＳ参照リクエストを再度送信した後、第１のローカルアプリは、ローカルサーバによって返される応答を所定時間内に受信すると、指定されたダウンロードページへのジャンプを停止できる。所定ポート群内のポートを用いて所定応答時間内にローカルサーバによって返される応答を第１のローカルアプリが受信しない場合、第１のローカルアプリは、指定されたダウンロードページへジャンプすることができる。

前述の所定時間は、所定応答時間よりも短くてよい。例えば、所定時間を２０ｍｓとし、所定応答時間を１００ｍｓとする。このような場合、起動されたローカルサーバ上の特定のポートが占有されていても、別のポートを用いることができる。例えば、事前取決めによるポート番号群内の第１のポート番号が占有されている場合、事前取決めによりポート番号群内の第２のポート番号を設定できる。これに対応して、第１のローカルアプリは、第１のポート番号を用いてＪＳ参照リクエストを送信し、更に第１のローカルアプリが第１の所定時間内にローカルサーバによって返される応答を受信しなければ、事前取決めによりポート番号群内の第２のポート番号を用いてＪＳ参照リクエストを送信できる。これに対応して、起動されたサーバと第１のローカルアプリとの間で、事前取決めによりポート番号群内の第３のポート番号及び他のポート番号を更に用いることができるが、説明を簡単にするために詳細は述べない。所定時間は、第１のローカルアプリが可能な限り予め定められたポート番号で多くのポート番号を試行できるように、所定応答時間よりも短くすることができる。したがって、ポート番号を用いてＪＳ参照リクエストを送信した後、第１のローカルアプリは、ローカルサーバによって返される応答を取得すると、第２のローカルアプリが起動されたことを確認できる。その結果、第１のローカルアプリは、指定されたダウンロードページへのジャンプを停止できる。

本願は、アプリ起動システムの実施を更に提供し、このシステムは：ウェブページを開き、第２のローカルアプリを呼び出すように構成され、ＪＳ参照リクエストをローカルサーバへ送信するように更に構成され、ローカルサーバによって返される応答を受信すると、指定されたダウンロードページへのジャンプを停止するように更に構成された第１のローカルアプリと；ローカルサーバを起動するように構成された第２のローカルアプリと；第１のローカルアプリによって送信されるＪＳ参照リクエストを受信し、ＪＳ参照リクエストを受信したときに第１のローカルアプリに応答を返すように構成されたローカルサーバと；を含む。

好ましくは、ウェブページのリンクアドレスがトリガされ開かれると、第１のローカルアプリは対応するウェブページを開く。ここで、第１のローカルアプリは、ブラウザアプリ、又はＷｅｂＶｉｅｗコンポーネントを統合するローカルアプリを含む。

好ましくは、ウェブページのリンクアドレスがトリガされ開かれると、第１のローカルアプリは、ウェブページのアドレスに含まれるパラメータをＵＲＩに結合し、ＵＲＩに対応する第２のローカルアプリを呼び出して、これを開く。

好ましくは、第１のローカルアプリは、ＪＳ参照リクエストをローカルサーバへ送信する。これには、ローカルサーバのアドレスへ＜ｓｃｒｉｐｔ＞タグを動的に追加することによってトリガされ、且つローカルサーバのアドレスを含むＪＳ参照リクエストを、第１のローカルアプリがローカルサーバへ送信することが含まれる。

好ましくは、第１のローカルアプリによって送信されるＪＳ参照リクエストはポート番号を含み、このポート番号はデフォルト値、又は第２のローカルアプリにより起動されるローカルサーバとの間で第１のローカルアプリによって事前取決めされる、ポート番号である。

好ましくは、第２のローカルアプリは、ローカルサーバを起動するプロセスで、ポート番号を、事前取決めにより一群のポート番号のうちの第１のポート番号に設定し；第１のローカルアプリによって送信されたＪＳ参照リクエストは、事前取決めにより一群のポート番号のうちの第１のポート番号を含む。

好ましくは、第２のローカルアプリはローカルサーバを起動し、設定された第１のポート番号が占有されていれば、ポート番号を、事前取決めにより一群のポート番号のうちの第２のポート番号に設定する。第１のローカルアプリは、第１のポート番号を用いてＪＳ参照リクエストを送信し、第１のローカルアプリが所定時間内にローカルサーバによって返される応答を受信しない場合、事前取決めにより一群のポート番号のうちの第２のポート番号を用いてＪＳ参照リクエストを送信する。

好ましくは、第１のローカルアプリは、ローカルサーバによって返される応答を受信したとき、指定されたダウンロードページへのジャンプを停止する。これには、第１のローカルアプリは、所定応答時間内にローカルサーバによって返される応答を受信したとき、指定されたダウンロードページへのジャンプを停止することが含まれる。

好ましくは、第１のローカルアプリは、第１のローカルアプリが、所定応答時間内に、ローカルサーバによって返される応答を受信しない場合、指定されたダウンロードページへジャンプする。

１９９０年代には、技術的な改良がハードウェアの改良（例えば、ダイオード、トランジスタ、スイッチなどの回路構造の改良）であるか、ソフトウェアの改良（方法手順の改良）であるかを明確に区別することができた。しかし、技術の発展に伴い、多くの現在の方法手順における改良は、ハードウェア回路構造の直接的な改良であるとみなすことができる。設計者は、通常、改良された方法手順をハードウェア回路にプログラムして、対応するハードウェア回路構造を得る。したがって、ハードウェア実体モジュールを用いることによって方法手順を改良できる。例えば、プログラマブル論理デバイス（ＰＬＤ）（例えば、フィールドプログラマブルゲートアレイ（ＦＰＧＡ））はそのような集積回路であり、ＰＬＤの論理機能はデバイスプログラミングによりユーザによって決定される。設計者は、チップ製造業者に特定用途向け集積回路チップの設計及び製造を要求することなく、デジタルシステムをＰＬＤに「統合」するためのプログラミングを実行する。加えて、今では、集積回路チップをマニュアルで製造する代わりに、そのようなプログラミングは、主に「論理コンパイラ」ソフトウェアを用いて実装される。論理コンパイラは、プログラムを開発し、書き込むために用いられるソフトコンパイラに類似する。コンパイルのために、元のコードを特定のプログラミング言語で記述する必要がある。言語はハードウェア記述言語（ＨＤＬ）と呼ばれる。高度ブール演算式言語（ＡＢＥＬ）、アルテラハードウェア記述言語（ＡＨＤＬ）、Ｃｏｎｆｌｕｅｎｃｅ（コンフルエンス）、コーネル大学プログラミング言語（ＣＵＰＬ）、ＨＤＣａｌ、Ｊａｖａ（登録商標）ハードウェア記述言語（ＪＨＤＬ）、Ｌａｖａ、Ｌｏｌａ 、ＭｙＨＤＬ、ＰＡＬＡＳＭ、及びＲｕｂｙハードウェア記述言語（ＲＨＤＬ）のような多くのハードウェア記述言語がある。超高速の集積回路ハードウェア記述言語（ＶＨＤＬ）及びＶｅｒｉｌｏｇ２が最も一般的に用いられる。当業者であれば、いくつかの説明されたハードウェア記述言語を用いて方法手順が論理的にプログラムされ、集積回路にプログラムされると、論理方法手順を実装するハードウェア回路を容易に得ることができることも理解すべきである。

コントローラは、適切な方法を用いて実装できる。例えば、コントローラは、マイクロプロセッサ若しくはプロセッサ、論理ゲート、スイッチ、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックコントローラ、又は内蔵マイクロプロセッサによって実行されるコンピュータ読取可能なプログラムコード（ソフトウェア又はファームウェアなど）を格納するコンピュータ読取可能な媒体であってもよい。コントローラの例として、以下のマイクロプロセッサが挙げられるが、これらに限定されない。すなわち、ＡＲＣ ６２５Ｄ、Ａｔｍｅｌ ＡＴ９１ＳＡＭ、Ｍｉｃｒｏｃｈｉｐ ＰＩＣ１８Ｆ２６Ｋ２０、及びＳｉｌｉｃｏｎｅ Ｌａｂｓ Ｃ８０５１Ｆ３２０。メモリコントローラも、メモリの制御ロジックの一部として実装できる。当業者であれば、コンピュータ読取可能なプログラムコードを用いてコントローラを実装することに加えて、秩序的手順で論理プログラミングを実行してコントローラに論理ゲート、スイッチ、特定用途向け集積回路、プログラマブルロジックコントローラ、及び内蔵マイクロコントローラの形態で同じ機能を実行させることができることも理解できよう。したがって、このようなコントローラは、ハードウェアコンポーネントとみなすことができ、コントローラに様々な機能を実装するように構成されるデバイスもハードウェアコンポーネント内の構造とみなせる。或いは、様々な機能を実装するように構成されるデバイスは、この方法を実装するソフトウェアモジュール及びハードウェアコンポーネント内の構造の両方とみなすことさえできる。

前述の実施で示したシステム、デバイス、モジュール、又はユニットは、コンピュータチップ又は実体物を用いて実施することも、特定の機能を持つ製品を用いて実施することもできる。

説明しやすくするために、上記の装置は、機能を様々なユニットに分割して説明されている。当然ながら、本願を実施する場合、各ユニットの機能は、一つ以上のソフトウェア及び／又はハードウェアで実装することができる。

当業者は、本願の実施が方法、システム、又はコンピュータプログラム製品として提供できることを理解するはずである。そのため、本願は、ハードウェアのみの実施、ソフトウェアのみの実施、又は、ソフトウェアとハードウェアとの組み合わせによる実施を用いることができる。さらに、本願は、コンピュータで使用可能なプログラムコードを含んだ１台以上のコンピュータで使用可能な記憶媒体（ディスクメモリ、ＣＤ−ＲＯＭ、光学メモリ等を含むがこれに限定されない）上で実施されるコンピュータプログラム製品を使用できる。

本願は、本願の実施に係る方法、デバイス（システム）、コンピュータプログラム製品のフローチャート及び／又はブロック図を参照して説明されている。コンピュータプログラム命令は、各工程、及び／又はフローチャート内の各ブロック、及び／又はブロック図を実施するために用いることができ、さらに、工程、及び／又はフローチャート内の１つのブロック、及び／又はブロック図、の組み合わせを実施するために用いることができる点が理解されるはずである。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、又はあらゆるその他のプログラムマブルデータ処理デバイスに、マシンを生成するために提供されることができ、これにより、コンピュータ、又は、あらゆるその他のプログラムマブルデータ処理デバイスのプロセッサが、フローチャートの１つ以上の工程において、及び／又は、ブロック図の１つ以上のブロックにおいて、特定の機能を実施するデバイスを生成できるようになる。

これらのコンピュータプログラム命令を、コンピュータ又はあらゆるその他のプログラマブルデータ処理デバイスに特定の方法で機能するように命令することができるコンピュータ読取可能なメモリに記憶して、これらのコンピュータ読取可能なメモリに記憶された命令が、命令装置を含む加工品を作り出すようにすることができる。この命令装置は、フローチャート内の１つ以上の工程における、及び／又はブロック図内の１つ以上のブロックにおける特定の機能を実施する。

これらのコンピュータプログラム命令をコンピュータ又はその他のプログラマブルデータ処理デバイスにロードして、コンピュータ又はその他のプログラムマブルデバイス上で一連の操作及びステップが実行されるようにし、コンピュータで実施される処理を生成することができる。これにより、コンピュータ又はその他のプログラムマブルデバイス上で実行される命令が、フローチャート内の１つ以上のステップ及び／又はブロック図内の１つ以上のブロックにおける特定の機能を実施するデバイスを提供することを可能とする。

典型的な構成では、計算デバイスは１つ以上のプロセッサ（ＣＰＵｓ）、入出力インターフェース、ネットワークインターフェース、及びメモリを含む。

メモリは、揮発性メモリ、ランダムアクセスメモリ（ＲＡＭ）、不揮発性メモリ、及び／又はリードオンリーメモリ（ＲＯＭ）やフラッシュメモリ（フラッシュＲＡＭ）のようなコンピュータ読取可能な他の形式のメモリを含んでよい。メモリはコンピュータ読取可能な媒体の一例である。

コンピュータ読取可能な媒体には、任意の方法又は技術を用いて情報を記憶できる、永続的、非永続的、移動可能な、移動不能な媒体が含まれる。この情報はコンピュータ読取可能な命令、データ構造、プログラムモジュール、又はその他のデータであってよい。コンピュータの記憶媒体の例として、計算デバイスによってアクセスできる情報を記憶するために用いることが可能な、相変化ランダムアクセスメモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、別タイプのランダムアクセスメモリ、リードオンリーメモリ（ＲＯＭ）、電気的に消去可能でプログラム可能なＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリ、又は別のメモリ技術、コンパクトディスクＲＯＭ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、又は別の光学記憶装置、磁気カセットテープ、テープ及びディスク記憶装置、又は別の磁気記憶デバイス、若しくはその他任意の非一時的媒体があるが、それらに限定されない。本願の定義に基づき、コンピュータ読取可能な媒体は、変調されたデータ信号及び搬送波のような一時的な媒体（ｔｒａｎｓｉｔｏｒｙ ｍｅｄｉａ）を含まない。

さらに、用語「含む」、「含有する」、又はこれらのその他任意の応用形は、非限定的な包含を網羅するものであるため、一連の要素を含んだ工程、方法、物品、デバイスはこれらの要素を含むだけでなく、ここで明確に挙げていないその他の要素をも含む、あるいは、このような工程、方法、物品、デバイスに固有の要素をさらに含むことができる点に留意することが重要である。「（一の）〜を含む」との用語を付けて示された要素は、それ以上の制約がなければ、その要素を含んだ工程、方法、物品、デバイス内に別の同一の要素をさらに含むことを排除しない。

当業者は、本願の実施が方法、システム、コンピュータプログラム製品として提供され得ることを理解するはずである。そのため、本願は、ハードウェアのみの実施の形式、ソフトウェアのみの実施の形式、又は、ソフトウェアとハードウェアの組み合わせによる実施の形式を用いることができる。さらに、本願は、コンピュータで用いることができるプログラムコードを含んだ、１つ以上のコンピュータで使用可能な記憶媒体（磁気ディスクストレージ、ＣＤ−ＲＯＭ、光学ディスク等を非限定的に含む）上で実施されるコンピュータプログラム製品の形態を用いることが可能である。

本願は、コンピュータにより実行されるコンピュータ実行可能な命令、例えばプログラムモジュールの一般的文脈において記載することができる。一般に、プログラムモジュールは、特定のタスクを実行する、或いは特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本願は、分散型コンピューティング環境において実践することもできる。これら分散型コンピューティング環境において、タスクは、通信ネットワークを用いることにより接続されるリモート処理デバイスにより実行される。分散型コンピューティング環境において、プログラムモジュールは、格納デバイスを含むローカル及びリモートコンピュータ格納媒体に配置することができる。

本明細書における実施は、逐次的な形式で記載されている。実施における同一又は類似の部分については、その実施を参照されたい。各実施は、他の実施との差異に焦点を当てている。特に、システムの実施は方法の実施に基本的に類似しており、したがって、簡潔に記載される。関連する部分については、方法の実施における関連する説明を参照されたい。

上述のものは本願の一実施の形態に過ぎず、本願を限定するものではない。当業者にとって、本願は様々な修正及び変更を加えることができる。本願の主旨及び原理から逸脱せずに為されるあらゆる修正、均等物による代替、改善は、本願の特許請求の範囲に含まれるものである。

Claims (20)

1. アプリケーション（アプリ）起動方法であって：
   ウェブページを第１のローカルアプリにより開き、第２のローカルアプリを呼び起こすステップと；
   ローカルサーバを前記第２のローカルアプリにより起動するステップと；
   ＪＳ参照リクエストを前記ローカルサーバへ、前記第１のローカルアプリにより送信するステップと；
   前記ローカルサーバによって返される応答を受信したとき、前記第１のローカルアプリにより、指定されたダウンロードページへのジャンプを停止するステップと；を備える、
   アプリケーション起動方法。
2. 前記ウェブページのリンクアドレスがトリガされ開かれると、前記第１のローカルアプリは、前記対応するウェブページを開き、
   前記第１のローカルアプリは、ブラウザアプリ、又はＷｅｂＶｉｅｗコンポーネントを統合するローカルアプリを備える、
   請求項１に記載のアプリケーション起動方法。
3. 前記ウェブページのリンクアドレスがトリガされ開かれると、前記第１のローカルアプリは、前記ウェブページの前記アドレスに含まれるパラメータをＵＲＩに結合し、前記ＵＲＩに対応する前記第２のローカルアプリを呼び出して、これを開く、
   請求項１に記載のアプリケーション起動方法。
4. ＪＳ参照リクエストを前記ローカルサーバへ送信する前記ステップは、ＪＳＯＮＰを介して前記ＪＳリクエストを前記ローカルサーバへ送信するステップを備える、
   請求項１に記載のアプリケーション起動方法。
5. ＪＳ参照リクエストを前記ローカルサーバへ、前記第１のローカルアプリにより送信する前記ステップは：
   前記ウェブページへ＜ｓｃｒｉｐｔ＞タグを動的に追加することによって生成された前記ローカルサーバのアドレスを含むＪＳ参照リクエストを、前記第１のローカルアプリにより前記ローカルサーバへ送信するステップを備える、
   請求項１に記載のアプリケーション起動方法。
6. 前記第１のローカルアプリによって送信される前記ＪＳ参照リクエストはポート番号を含み、前記ポート番号は、デフォルト値、又は前記第２のローカルアプリにより起動されるローカルサーバとの間で前記第１のローカルアプリによって事前取決めされる、ポート番号である、
   請求項５に記載のアプリケーション起動方法。
7. 前記第２のローカルアプリは前記ローカルサーバを起動し、前記ポート番号を、事前取決めによりポート番号群のうちの第１のポート番号に設定し；
   前記第１のローカルアプリによって送信される前記ＪＳ参照リクエストは、前記事前取決めによりポート番号群のうちの前記第１のポート番号を備える、
   請求項６に記載のアプリケーション起動方法。
8. 前記第２のローカルアプリは、前記ローカルサーバを起動し、設定された前記第１のポート番号が占有されている場合、前記ポート番号を、前記事前取決めによりポート番号群のうちの第２のポート番号に設定し；
   前記第１のローカルアプリは、前記第１のポート番号を用いて前記ＪＳ参照リクエストを送信し、前記第１のローカルアプリが前記ローカルサーバによって返される前記応答を所定時間内に受信しない場合、前記事前取決めによりポート番号群のうちの前記第２のポート番号を用いて前記ＪＳ参照リクエストを送信する、
   請求項７に記載のアプリケーション起動方法。
9. 前記ローカルサーバによって返される応答を受信したとき、前記第１のローカルアプリにより、指定されたダウンロードページへのジャンプを停止する前記ステップは：
   前記ローカルサーバによって返される前記応答を所定応答時間内に受信したとき、前記第１のローカルアプリにより、前記指定されたダウンロードページへのジャンプを停止するステップを備える、
   請求項１に記載のアプリケーション起動方法。
10. 前記ローカルサーバによって返される前記応答を前記所定応答時間内に受信しないとき、前記第１のローカルアプリにより、前記指定されたダウンロードページへジャンプするステップを備える、
    請求項９に記載のアプリケーション起動方法。
11. アプリケーション起動システムであって：
    ウェブページを開き、第２のローカルアプリを呼び出すように構成され、ＪＳ参照リクエストをローカルサーバへ送信するように更に構成され、前記ローカルサーバによって返される応答を受信すると、指定されたダウンロードページへのジャンプを停止するように更に構成された、第１のローカルアプリと；
    前記ローカルサーバを起動するように構成された前記第２のローカルアプリと；
    前記第１のローカルアプリによって送信された前記ＪＳ参照リクエストを受信し、前記ＪＳ参照リクエストを受信したときに前記第１のローカルアプリへ前記応答を返すように構成された前記ローカルサーバと；を備える、
    アプリケーション起動システム。
12. 前記ウェブページのリンクアドレスがトリガされ開かれると、前記第１のローカルアプリは、前記対応するウェブページを開き、
    前記第１のローカルアプリは、ブラウザアプリ、又はＷｅｂＶｉｅｗコンポーネントを統合するローカルアプリを備える、
    請求項１１に記載のアプリケーション起動システム。
13. 前記ウェブページのリンクアドレスがトリガされ開かれると、前記第１のローカルアプリは、前記ウェブページの前記アドレスに含まれるパラメータをＵＲＩに結合し、前記ＵＲＩに対応する前記第２のローカルアプリを呼び出して、これを開く、
    請求項１１に記載のアプリケーション起動システム。
14. 前記ＪＳ参照リクエストを前記ローカルサーバへ送信することは：ＪＳＯＮＰを介して前記ＪＳリクエストを前記ローカルサーバへ送信することを備える、
    請求項１１に記載のアプリケーション起動システム。
15. 前記第１のローカルアプリが前記ＪＳ参照リクエストを前記ローカルサーバへ送信することは：
    前記ローカルサーバのアドレスへ＜ｓｃｒｉｐｔ＞タグを動的に追加することによって生成された前記ローカルサーバのアドレスを含むＪＳ参照リクエストを、前記第１のローカルアプリが前記ローカルサーバへ送信することを備える、
    請求項１１に記載のアプリケーション起動システム。
16. 前記第１のローカルアプリによって送信される前記ＪＳ参照リクエストはポート番号を含み、前記ポート番号は、デフォルト値、又は前記第２のローカルアプリにより起動されるローカルサーバとの間で前記第１のローカルアプリによって事前取決めされる、ポート番号である、
    請求項１５に記載のアプリケーション起動システム。
17. 前記第２のローカルアプリは、前記ローカルサーバを起動するプロセスにおいて、前記ポート番号を、事前取決めによりポート番号群のうちの第１のポート番号に設定し；
    前記第１のローカルアプリによって送信される前記ＪＳ参照リクエストは、前記事前取決めによるポート番号群のうちの前記第１のポート番号を備える、
    請求項１６に記載のアプリケーション起動システム。
18. 前記第２のローカルアプリは、前記ローカルサーバを起動し設定された前記第１のポート番号が占有されている場合、前記ポート番号を、前記事前取決めによりポート番号群のうちの第２のポート番号に設定し；
    前記第１のローカルアプリは、前記第１のポート番号を用いて前記ＪＳ参照リクエストを送信し、前記第１のローカルアプリが前記ローカルサーバによって返される前記応答を所定時間内に受信しない場合、前記事前取決めによりポート番号群のうちの前記第２のポート番号を用いて前記ＪＳ参照リクエストを送信する、
    請求項１７に記載のアプリケーション起動システム。
19. 前記ローカルサーバによって返される前記応答を受信したとき、前記第１のローカルアプリが前記指定されたダウンロードページへのジャンプを停止することは：
    前記ローカルサーバによって返される前記応答を所定応答時間内に受信したとき、前記第１のローカルアプリが前記指定されたダウンロードページへのジャンプを停止することを備える、
    請求項１１に記載のアプリケーション起動システム。
20. 前記第１のローカルアプリが、前記ローカルサーバによって返される前記応答を前記所定応答時間内に受信しないとき、前記第１のローカルアプリは、前記指定されたダウンロードページへジャンプする、
    請求項１９に記載のアプリケーション起動システム。

Images