JP6603311B2 - ブラウザによりローカルサービスアセンブリを呼び出すための方法、デバイス及びシステム - Google Patents

Description

本出願は、通信技術の分野に関し、特に、ブラウザによりローカルサービスコンポーネントを呼び出すための方法、装置及びシステムに関する。

ＮＰＡＰＩ（Ｎｅｔｓｃａｐｅプラグインアプリケーションプログラミングインターフェース）などのブラウザプラグインは、ブラウザにおいて外部アプリケーションを実行するための汎用インターフェースである。外部アプリケーションの実行はまた、ローカルサービスコンポーネントの呼び出しと呼ばれることもある。ローカルサービスコンポーネントの呼び出しは、デジタル証明書をインストールすること、デジタル証明書を削除すること、デジタル証明書を検証すること、ネットワークカードのｍａｃアドレスなど、ローカルマシンの環境情報を獲得すること等を含んでよい。ＮＰＡＰＩに加えて、同様の機能を有する現在共通のブラウザプラグインはさらに、ＢＨＯ（Ｂｒｏｗｓｅｒ Ｈｅｌｐｅｒ Ｏｂｊｅｃｔ）、Ｎａｔｉｖｅ Ｍｅｓｓａｇｉｎｇ、ＪＳ‐Ｃｔｙｐｅｓ等を含む。

しかしながら、これらのブラウザプラグインには、特に以下の、いくつかの問題がある。

デスクトップ端末のほぼ全てのグラフィカルインターフェースブラウザ（ＩＥを除く）は、ＮＰＡＰＩをサポートするが、ＮＰＡＰＩプラグインの不適切な書き込みはブラウザの故障を引き起こすことがあり、または、ＮＰＡＰＩが設計されたときにセキュリティ上の配慮がなされていないので、システムに対するマルウェア攻撃につながることさえある。さらに、ＮＰＡＰＩプラグインはモバイルデバイスをサポートせず、現在のところ削除の危機に瀕している。現在、最新のブラウザ（ｃｈｒｏｍｅやＦｉｒｅｆｏｘ等）の大半はＮＰＡＰＩをサポートせず、ブラウザプラグインは、ローカル情報を獲得するため、または、ウェブサイトのデジタル証明書を検証するために使用できない。Ｍｉｃｒｏｓｏｆｔにより提唱されるＢＨＯは、サードパーティのプログラマーにとって対話型インターフェースを開くためのブラウザの業界標準であり、ブラウザのフィールドにおける対話型インターフェースは、単純なコードにより入力され得る。さらに、いくつかの、ＩＥブラウザを個人用に設定するツールが、今ではＢＨＯを使用して実行されている。しかしながら、ＢＨＯはＩＥブラウザしかサポートせず、アプリケーションが制限される。さらに、Ｇｏｏｇｌｅは、当初のＮＰＡＰＩに置き換わるように、その新たなｃｈｒｏｍｅブラウザに新たなＮａｔｉｖｅ Ｍｅｓｓａｇｉｎｇインターフェースを追加している。しかしながら、Ｎａｔｉｖｅ Ｍｅｓｓａｇｉｎｇは、現在のところｃｈｒｏｍｅブラウザしかサポートせず、拡張がブラウザにインストールされる必要がある。同様に、ＪＳ‐ＣｔｙｐｅｓはＦｉｒｅｆｏｘブラウザしかサポートせず、同様に、拡張がブラウザにインストールされる必要がある。

それゆえ、ＮＰＡＰＩが削除されなければならないが、他のブラウザプラグインが汎用でない状況で、顕著な汎用性及び良好なセキュリティを有し、且つ、大多数の主流ブラウザによりローカルサービスコンポーネントの呼び出しを実行することができる解決策が、現在、緊急に必要である。

本出願の実施形態の目的は、大多数の主流ブラウザが、セキュリティを考慮しつつローカルサービスコンポーネントを確実に呼び出すことができるように、ブラウザによりローカルサービスコンポーネントの呼び出しを実行するための方法、装置及びシステムを提供することである。

上記の目的を達成するため、１つの態様において、本出願の実施形態は、ブラウザによりローカルサービスコンポーネントの呼び出しを実行するための方法を提供し、当該方法は、
クライアント端末が、ブラウザ端末により開始されるクロスドメイン通信プロトコルに基づく接続要求を受信することと、
クライアント端末が、接続要求の妥当性検証を行うことと、
接続要求が妥当性検証をパスする場合、ブラウザ端末にローカルサービスコンポーネントを呼び出すことを可能にするように、クライアント端末が、クロスドメイン通信プロトコルに基づいてブラウザ端末との通信接続を確立すること
を含む。

別の態様において、本出願の実施形態はさらに、ブラウザによりローカルサービスコンポーネントの呼び出しを実行するための装置を提供する。当該装置はクライアント端末であり、
ブラウザにより開始されるクロスドメイン通信プロトコルに基づく接続のための要求を受信するように構成される接続要求受信モジュールと、
接続要求の妥当性検証を行うように構成される妥当性検証モジュールと、
接続要求が妥当性検証をパスする場合、ブラウザ端末に、ローカルサービスコンポーネントを呼び出すことを可能にするように、クロスドメイン通信プロトコルに基づいてブラウザ端末との通信接続を確立するように構成される接続制御モジュールと
を含む。

さらに別の態様において、本出願の実施形態はさらに、ブラウザによりローカルサービスコンポーネントの呼び出しを実行するためのシステムを提供し、当該システムは、
クライアント端末に対し、クロスドメイン通信プロトコルに基づく接続要求を開始するように構成されるブラウザ端末と、
接続要求の妥当性検証を行い、接続要求が妥当性検証をパスする場合、ブラウザ端末がローカルサービスコンポーネントを呼び出すことができるように、クロスドメイン通信プロトコルに基づいてブラウザ端末との通信接続を確立するように構成されるクライアント端末と
を含む。

本出願の実施形態において、クライアント端末は、クロスドメイン通信プロトコルをサポートし、大多数の既存の主流ブラウザはまた、クロスドメイン通信プロトコルをサポートし、クライアント端末は、既存の主流ブラウザとの通信チャンネルを確立することができる。このように、ＮＰＡＰＩが現在のところ削除されなければならないが、他のブラウザプラグインが汎用でない状況で、大多数の主流ブラウザに、ローカルサービスコンポーネントを呼び出すことを可能にする通信解決策が提供される。さらに、本出願の実施形態において、ブラウザとの通信接続を確立するよりも前に、クライアント端末が、ブラウザの接続要求の妥当性検証を行う。ローカルサービスコンポーネントを呼び出すための通信接続は、要求が妥当性検証をパスする場合にのみ確立され得る。それゆえ、本出願の実施形態はまた、悪質なウェブサイトがクライアント端末を利用するのを防ぐ機能を有し、これにより、ローカルサービスコンポーネントを呼び出すための、ブラウザのための通信のセキュリティが改善される。

本明細書において説明される添付の図面は、本出願の実施形態のさらなる理解を提供するのに使用され、本出願の一部を構成し、本出願の実施形態を限定するものと解釈すべきでない。添付の図面では、以下を表す。

本出願の実施形態に従った、ブラウザによりローカルサービスコンポーネントの呼び出しを実行するための例示的な方法の流れ図である。 本出願の実施形態に従った、ブラウザによりローカルサービスコンポーネントの呼び出しを実行するための例示的な装置の論理構造図である。 本出願の実施形態に従った、ブラウザによりローカルサービスコンポーネントの呼び出しを実行するための例示的なシステムの論理構造図である。

より理解しやすい方法で、本出願の実施形態の目的、技術的解決策及び利点を得るために、本出願の実施形態が、実施形態及び添付の図面を参照してより詳細に本明細書において説明される。本出願の実施形態の説明的な実施例及び対応する説明は、本出願の実施形態を説明するのに使用されるものであり、本出願の実施形態を限定するものと解釈すべきでない。

本出願の実施形態の実施態様の詳細が、添付の図面を参照してより詳細に本明細書において説明される。

図１を参照すると、本出願の実施形態に従った、ブラウザによりローカルサービスコンポーネントの呼び出しを実行するための方法は、以下の動作を含む。

Ｓ１０１で、クライアント端末は、ブラウザ端末により開始されるクロスドメイン通信プロトコルに基づく接続要求を受信する。ブラウザ端末がローカルサービスコンポーネントを呼び出す必要がある場合、ブラウザ端末は、クライアント端末に対し、ＷｅｂＳｏｃｋｅｔプロトコルに基づく接続要求を開始し、クライアント端末はこれに応じて当該要求を受信する。ＷｅｂＳｏｃｋｅｔプロトコルは、全二重通信のネットワーク技術である。ＷｅｂＳｏｃｋｅｔプロトコルにおいて、通信当事者は、通信当事者間で通信チャンネルを迅速に形成するためにハンドシェイク動作のみを必要とし、相互のデータ伝送が、通信当事者間で直接行われてもよい。現在の主流ブラウザ（Ｃｈｒｏｍｅ１６＋、ＩＥ１０＋、Ｆｉｒｅｆｏｘ１１＋、Ｓａｆａｒｉ６．０＋、Ｏｐｅｒａ１２．１０＋、３６０Ｓｅｃｕｒｉｔｙブラウザ、３６０Ｃｈｒｏｍｅ、Ｔａｏｂａｏ（商標）ブラウザ、Ｓｏｇｏｕブラウザ、ＵＣブラウザ、Ｃｈｅｅｔａｈブラウザ、及びＭａｘｔｈｏｎブラウザなど）全てが、ＷｅｂＳｏｃｋｅｔプロトコルをサポートする。

大多数の主流ブラウザに、ローカルサービスコンポーネントを呼び出すことを可能にするように、クロスドメイン通信プロトコルが、本出願の実施形態において、クライアント端末とブラウザとの間で使用される必要があることに留意すべきである。クロスドメインは、クロッシングシステムセキュリティドメインを指す。ＷｅｂＳｏｃｋｅｔプロトコルが、本出願の実施形態において好ましい。しかしながら、本出願の実施形態はまた、代案として他のクロスドメイン通信プロトコル（ＪＳＯＮＰプロトコル及びＣＯＲＳプロトコル等）を使用してもよい。しかしながら、ＪＳＯＮＰプロトコルは、送信されるデータパケットのサイズに限界があり、送信されるデータの長さがこの限界を超える場合、残りのデータは切り捨てられることがある。ＣＯＲＳプロトコルが使用される場合、特別なフィールドが、クライアント端末によりサーバへ返信される応答ヘッダに追加される必要がある。クライアント端末は、しかしながら、プロアクティブにサーバへメッセージを送信できず、サーバは、サーバへ送信すべきデータがあるかどうかについて、クライアント端末に絶え間なく問い合わせる必要がある。ＷｅｂＳｏｃｋｅｔプロトコルは、上記の２つのプロトコルの制限を有さず、通信当事者のための双方向通信チャンネルを迅速に確立できる。さらに、ＷｅｂＳｏｃｋｅｔプロトコルのこのタイプの通信アプローチが使用される場合、クライアント端末が故障しても、クライアント端末がバックエンドで再起動して、関連するサービスを再開し得るので、ウェブサイトはこれに気付くことができない。それゆえ、ウェブサイトのエクスペリエンスが改善される。

Ｓ１０２で、クライアント端末は接続要求の妥当性検証を行う。妥当性検証が正常終了する場合、Ｓ１０３が行われる。そうでない場合、クライアント端末は、悪質なウェブサイトがクライアント端末を利用するのを防ぐように、ブラウザ端末との接続を切断する。この動作において、妥当性検証の目的は、悪質なウェブサイトがクライアント端末を利用するのを防ぐことである。この方法で、悪質なウェブサイトは、クライアント端末を使用してローカルマシンの情報を取得できず、これにより、通信のセキュリティが改善される。この動作において、妥当性検証は好ましくは、接続要求を開始するブラウザ端末に対応するウェブサイトが、ウェブサイトホワイトリストに含まれるウェブサイトであるかどうかを判定することにより、検証を行う。これは、関係のあるごく少数のウェブサイトが一般にローカルサービスコンポーネントを呼び出す必要があるからである。それゆえ、ウェブサイトホワイトリストを使用した検証は、クライアント端末の妥当性検証の処理速度を加速させ得る。明らかに、妥当性検証はまた、この動作において、トークン検証などの他のアプローチを使用してもよい。トークン検証は、非対称暗号化アルゴリズムを使用した暗号化を指し、合法のウェブサイトのみがそのようなトークンを生成できる。クライアント端末は、トークンに対して成される修正を識別でき、それゆえ接続を拒否できる。

Ｓ１０３で、接続要求が妥当性検証をパスすることに応答して、ブラウザ端末がローカルサービスコンポーネントを呼び出すことができるように、クライアント端末は、ＷｅｂＳｏｃｋｅｔプロトコルに基づいてブラウザ端末との通信接続を確立する。通信接続が確立された後、ブラウザ端末がローカルサービスコンポーネントを呼び出すためのプロセスは、実質的に以下を含んでよい。
１）ブラウザ端末がクライアント端末へコマンドを送信。
２）クライアント端末がコマンドをパースし、対応するローカルサービスコンポーネントへコマンドを送る。
３）ローカルサービスコンポーネントがコマンドを処理し、クライアント端末へ処理結果を返信。
４）クライアント端末がブラウザ端末へ処理結果を転送。

本出願の実施形態において、ブラウザ端末により開始されるＷｅｂＳｏｃｋｅｔプロトコルに基づく接続要求を受信する際、クライアント端末は、設定されたポートバインディング優先順位に従って、バインディングのためのポートリストからポートを選択する。さらに、ポートバインディング優先順位は、ブラウザ端末のポート選択優先順位と一致する。例えば、ポートリストは、４つの選択可能なポート、すなわち、Ａ、Ｂ、Ｃ及びＤを含み、クライアント端末のポートバインディング優先順位は、Ａ＞Ｂ＞Ｃ＞Ｄである。同様に、ブラウザ端末のポート選択優先順位もまた、Ａ＞Ｂ＞Ｃ＞Ｄである。この方法で、最も好ましいポートＡが別のソフトウェアによって占有される場合、クライアント端末及びブラウザ端末は双方がポートＢをまず選択するように試みてもよく、これにより、接続を確立する成功率を改善し、接続を確立するための時間を短縮するのが促される。

さらに、本出願の実施形態において、クライアント端末が故障する場合、クライアント端末は、その故障レポートを、故障レポートに従ってクライアント端末の対応する改善及びアップグレードを後に行うため、サーバへ送信する。故障レポートは、エラーコード、エラー位置、及び現在の状態等の情報を含んでよい。クライアント端末は、オペレーティングシステムのアプリケーションプログラミングインターフェース（ＡＰＩ）を介してオペレーティングシステムに組み込まれた障害診断プログラムを呼び出すことにより、故障レポートを取得してもよい。

本出願の実施形態において、クライアント端末側でウェブサイトホワイトリストをアップデートするための実施態様は、以下のアプローチ、すなわち、
クライアント端末が、ウェブサイトホワイトリストのアップデートが存在するかどうかについて周期的にサーバに問い合わせ、肯定の場合に、アップデートを獲得するための要求を送信すること、を使用して達成されてもよい。

本出願の実施形態において、クライアント端末がＷｅｂＳｏｃｋｅｔプロトコルをサポートし、大多数の既存の主流ブラウザもまた、ＷｅｂＳｏｃｋｅｔプロトコルをサポートするので、クライアント端末は、既存の主流ブラウザとの通信チャンネルを確立することができる。このように、ＮＰＡＰＩが現在のところ削除されなければならないが、他のブラウザプラグインが汎用でない状況で、大部分の主流ブラウザに、ローカルサービスコンポーネントを呼び出すことを可能にする通信方法が提供される。さらに、本出願の実施形態において、ブラウザとの通信接続を確立するよりも前に、クライアント端末はブラウザの接続要求の妥当性検証を行い、要求が妥当性検証をパスする場合にのみ、それとの通信接続が確立される。それゆえ、本出願の実施形態はまた、悪質なウェブサイトがクライアント端末を利用するのを防ぐ機能を有し、これにより、ブラウザによるローカルサービスコンポーネントの呼び出しと関連した通信のセキュリティが改善される。

図２を参照すると、本出願の実施形態に従った、ブラウザによりローカルサービスコンポーネントの呼び出しを実行するための装置は、クライアント端末である。ブラウザによりローカルサービスコンポーネントの呼び出しを実行する前述の方法と一致して、クライアント端末は、接続要求受信モジュール２１、妥当性検証モジュール２２、及び接続制御モジュール２３を含む。

接続要求受信モジュール２１は、ブラウザ端末により開始されるクロスドメイン通信プロトコルに基づく接続要求を受信するように構成される。ブラウザ端末がローカルサービスコンポーネントを呼び出す必要がある場合、ブラウザ端末は、クライアント端末に対し、ＷｅｂＳｏｃｋｅｔプロトコルに基づく接続要求を開始し、接続要求受信モジュール２１はこれに応じて当該要求を受信する。ＷｅｂＳｏｃｋｅｔプロトコルは、ブラウザとサーバとの間の全二重通信のネットワーク技術である。ＷｅｂＳｏｃｋｅｔプロトコルにおいて、通信当事者は、通信当事者間で通信チャンネルを迅速に形成するためにハンドシェイク動作のみを必要とし、相互のデータ伝送が、通信当事者間で直接行われてもよい。現在の主流ブラウザ（Ｃｈｒｏｍｅ１６＋、ＩＥ１０＋、Ｆｉｒｅｆｏｘ１１＋、Ｓａｆａｒｉ６．０＋、Ｏｐｅｒａ１２．１０＋、３６０Ｓｅｃｕｒｉｔｙブラウザ、３６０Ｃｈｒｏｍｅ、Ｔａｏｂａｏ（商標）ブラウザ、Ｓｏｇｏｕブラウザ、ＵＣブラウザ、Ｃｈｅｅｔａｈブラウザ、及びＭａｘｔｈｏｎブラウザなど）全てが、ＷｅｂＳｏｃｋｅｔプロトコルをサポートする。

大多数の主流ブラウザに、ローカルサービスコンポーネントを呼び出すことを可能にするように、クロスドメイン通信プロトコルが、本出願の実施形態において、クライアント端末とブラウザとの間で使用される必要があることに留意すべきである。クロスドメインは、クロッシングシステムセキュリティドメインを指す。ＷｅｂＳｏｃｋｅｔプロトコルが、本出願の実施形態において好ましい。しかしながら、本出願の実施形態はまた、代案として他のクロスドメイン通信プロトコル（ＪＳＯＮＰプロトコル及びＣＯＲＳプロトコル等）を使用してもよい。しかしながら、ＪＳＯＮＰプロトコルは、送信されるデータパケットのサイズに限界があり、送信されるデータの長さがこの限界を超える場合、残りのデータは切り捨てられることがある。ＣＯＲＳプロトコルが使用される場合、特別なフィールドが、クライアント端末によりサーバへ返信される応答ヘッダに追加される必要がある。クライアント端末は、しかしながら、プロアクティブにサーバへメッセージを送信できず、サーバは、サーバへ送信すべきデータがあるかどうかについて、クライアント端末に絶え間なく問い合わせる必要がある。ＷｅｂＳｏｃｋｅｔプロトコルは、上記の２つのプロトコルの制限を有さず、通信当事者のための双方向通信チャンネルを迅速に確立できる。さらに、ＷｅｂＳｏｃｋｅｔプロトコルのこのタイプの通信アプローチが使用される場合、クライアント端末が故障しても、クライアント端末がバックエンドで再起動して、関連するサービスを再開し得るので、ウェブサイトはこれに気付くことができない。それゆえ、ウェブサイトのエクスペリエンスが改善される。

妥当性検証モジュール２２は、接続要求の妥当性検証を行うように構成される。妥当性検証の目的は、悪質なウェブサイトがクライアント端末を利用するのを防ぐことであり、これにより、通信のセキュリティが改善される。妥当性検証モジュール２２において、妥当性検証は好ましくは、接続要求を開始するブラウザ端末に対応するウェブサイトが、ウェブサイトホワイトリストに含まれるウェブサイトであるかどうかを判定することにより、検証を行う。これは、一般に２０〜３０の、関係のあるごく少数のウェブサイトが、ローカルサービスコンポーネントを呼び出す必要があるからである。それゆえ、ウェブサイトホワイトリストを使用した検証は、クライアント端末の妥当性検証の処理速度を加速させ得る。明らかに、妥当性検証はまた、この動作において、トークン検証などの他のアプローチを使用してもよい。トークン検証は、非対称暗号化アルゴリズムを使用した暗号化を指し、合法のウェブサイトのみがそのようなトークンを生成できる。クライアント端末は、トークンに対して成される修正を識別でき、それゆえ接続を拒否できる。

接続制御モジュール２３は、接続要求が妥当性検証をパスすることに応答して、ブラウザ端末がローカルサービスコンポーネントを呼び出すことができるように、ＷｅｂＳｏｃｋｅｔプロトコルに基づいてブラウザ端末との通信接続を確立するように構成される。そうでない場合、悪質なウェブサイトがクライアント端末を利用するのを防ぐようにブラウザ端末との接続が切断される。通信接続が確立された後、ブラウザ端末がローカルサービスコンポーネントを呼び出すプロセスは、実質的に以下を含んでよい。
１）ブラウザ端末がクライアント端末へコマンドを送信。
２）クライアント端末がコマンドをパースし、対応するローカルサービスコンポーネントへコマンドを送る。
３）ローカルサービスコンポーネントがコマンドを処理し、クライアント端末へ処理結果を返信。
４）クライアント端末がブラウザ端末へ処理結果を転送。

本出願の実施形態において、クライアント端末はさらに、
接続要求受信モジュール２１が、ブラウザ端末により開始されるクロスドメイン通信プロトコルに基づく接続要求を受信する場合、設定されたポートバインディング優先順位に従って、バインディングのためのポートリストからポートを選択するように構成されるポートバインディングモジュール２４を含んでよく、当該ポートバインディング優先順位はブラウザ端末のポート選択優先順位と一致する。例えば、ポートリストは、４つの選択可能なポート、すなわち、Ａ、Ｂ、Ｃ及びＤを含み、クライアント端末のポートバインディング優先順位は、Ａ＞Ｂ＞Ｃ＞Ｄである。同様に、ブラウザ端末のポート選択優先順位もまた、Ａ＞Ｂ＞Ｃ＞Ｄである。この方法で、最も好ましいポートＡが別のソフトウェアによって占有される場合、ポートバインディングモジュール２４及びブラウザ端末は双方がポートＢをまず選択するように試みてもよく、これにより、接続を確立する成功率を改善し、接続を確立するための時間を短縮するのが促される。

本出願の実施形態において、クライアント端末はさらに、
クライアント端末が故障したことを判定する際、クライアント端末の故障レポートを、当該故障レポートに従ってクライアント端末の対応する改善及びアップグレードを後に行うため、サーバへ送信するように構成される、故障レポート処理モジュール２５を含んでよい。故障レポートは、エラーコード、エラー位置、及び現在の状態等の情報を含んでよい。故障レポート処理モジュール２５は、オペレーティングシステムのアプリケーションプログラミングインターフェースを介してオペレーティングシステムに組み込まれた障害診断プログラムを呼び出すことにより、故障レポートを取得してもよい。

さらに、本出願の実施形態において、クライアント端末はさらに、
サーバに周期的に問い合わせることにより、クライアント端末のウェブサイトホワイトリストをアップデートするように構成されるアップデートモジュール２６を含んでよい。

本出願の実施形態において、クライアント端末がＷｅｂＳｏｃｋｅｔプロトコルをサポートし、大多数の既存の主流ブラウザもまた、ＷｅｂＳｏｃｋｅｔプロトコルをサポートするので、クライアント端末は、既存の主流ブラウザとの通信チャンネルを確立することができる。このように、ＮＰＡＰＩが現在のところ削除されなければならないが、他のブラウザプラグインが汎用でない状況で、大部分の主流ブラウザに、ローカルサービスコンポーネントを呼び出すことを可能にする通信方法が提供される。さらに、本出願の実施形態において、ブラウザとの通信接続を確立するよりも前に、クライアント端末はブラウザの接続要求の妥当性検証を行い、要求が妥当性検証をパスする場合にのみ、それとの通信接続が確立される。それゆえ、本出願の実施形態はまた、悪質なウェブサイトがクライアント端末を利用するのを防ぐ機能を有し、これにより、ブラウザによるローカルサービスコンポーネントの呼び出しと関連した通信のセキュリティが改善される。

図３を参照すると、本出願の実施形態に従った、ブラウザによりローカルサービスコンポーネントの呼び出しを実行するためのシステムは、ブラウザ端末３１及びクライアント端末３２を含む。

ブラウザ端末３１は、クライアント端末３２に対し、クロスドメイン通信プロトコルに基づく接続要求を開始するように構成される。

クライアント端末３２は、ブラウザ端末３１により送信される接続要求の妥当性検証を行い、接続要求が妥当性検証をパスする場合、ブラウザ端末がローカルサービスコンポーネントを呼び出すことができるように、ＷｅｂＳｏｃｋｅｔプロトコルに基づいてクライアント端末３２とブラウザ端末３１との間の通信接続を確立するように構成される。クライアント端末３２の詳細は、前述の本出願の実施形態を参照することにより取得でき、本明細書において繰返し説明されない。

本出願の実施形態において、システムはさらに、
クライアント端末３１により送信される故障レポートを受信及び記憶するように構成されるサーバ３３を含む。

本出願の実施形態において、クライアント端末がＷｅｂＳｏｃｋｅｔプロトコルをサポートし、大多数の既存の主流ブラウザもまた、ＷｅｂＳｏｃｋｅｔプロトコルをサポートするので、通信チャンネルが、クライアント端末と既存の主流ブラウザとの間で確立され得る。このように、ＮＰＡＰＩが現在のところ削除されなければならないが、他のブラウザプラグインが汎用でない状況で、大部分の主流ブラウザに、ローカルサービスコンポーネントを呼び出すことを可能にすることが達成される。さらに、本出願の実施形態において、ブラウザとの通信接続を確立するよりも前に、クライアント端末はブラウザの接続要求の妥当性検証を行い、要求が妥当性検証をパスする場合のみ、それとの通信接続が確立される。それゆえ、本出願の実施形態はまた、悪質なウェブサイトがクライアント端末を利用するのを防ぐ機能を有し、これにより、通信のセキュリティが改善される。

当業者はさらに、本出願の実施形態において列挙される、各説明的な論理ブロック、ユニット及び動作が、ハードウェア、ソフトウェアまたはそれらの組合せにより実行されてもよいことを理解し得る。実施態様がハードウェアまたはソフトウェアを使用して行われるかどうかは、特定のアプリケーション及びシステム全体の設計要求によって決まる。当業者は、各特定のアプリケーションのための機能（複数可）を実行するように様々な方法を使用してもよいが、このような実施態様が、本出願の実施形態の保護の範囲外にあるものと解釈すべきでない。

本出願の実施形態において説明された各説明的な論理ブロックまたはユニットの機能（複数可）は、汎用プロセッサ、デジタル信号プロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイもしくは別のプログラム可能な論理デバイス、ディスクリートのゲートもしくはトラジスタ論理、ディスクリートのハードウェアコンポーネント、またはそれらの任意の組合せを介して、実行または動作されてもよい。汎用プロセッサは、マイクロプロセッサであってもよく、随意に、汎用プロセッサはまた、任意の従来のプロセッサ、コントローラ、マイクロコントローラまたは状態機械であってもよい。プロセッサはまた、デジタル信号プロセッサ及びマイクロプロセッサ、マルチマイクロプロセッサ、デジタル信号プロセッサコアと関連した１つまたは複数のマイクロプロセッサ、または任意の他の同様の構成など、コンピューティングデバイスの組合せを利用して実行されてもよい。

本出願の実施形態において説明される方法またはアルゴリズムの動作は、ハードウェア、プロセッサ（複数可）により実行されるソフトウェアモジュール（複数可）、またはそれらの組合せに直接組み込まれてもよい。ソフトウェアモジュール（複数可）は、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ‐ＲＯＭ、または、本分野における任意の他の形態の記憶媒体に記憶されてもよい。実例として、記憶媒体は、プロセッサに結合されてもよく、これにより、プロセッサは、記憶媒体から情報を読み取ることができ、また、記憶媒体に情報を記憶及び書込むことができる。随意に、記憶媒体はプロセッサに組み込まれてもよい。プロセッサ及び記憶媒体はＡＳＩＣに配置されてもよく、こうしたＡＳＩＣはユーザ端末に配置されてもよい。随意に、プロセッサ及び記憶媒体はまた、ユーザ端末の様々なコンポーネントに配置されてもよい。

１つまたは複数の例示的な設計において、本出願の実施形態において説明された前述の機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せにおいて実行されてもよい。ソフトウェアにおいて実行される場合、これらの機能は、コンピュータ可読媒体に記憶されてもよく、または、１つまたは複数の命令またはコードの形でコンピュータ可読媒体に伝達されてもよい。コンピュータ可読媒体は、コンピュータ記憶媒体、及び、１つの場所から別の場所へのコンピュータプログラムの転送を促進する通信媒体を含む。記憶媒体は、任意の汎用または専用のコンピュータにアクセス可能な、任意の使用可能な媒体であってもよい。例えば、コンピュータ可読媒体は、これに限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ‐ＲＯＭもしくは他の光学ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または、命令もしくはデータ構造において、または、汎用もしくは専用コンピュータまたは汎用もしくは専用プロセッサにより読み取り可能な他の形において、プログラムコードを携帯及び記憶するのに使用され得る任意の他の媒体を含んでよい。さらに、任意の接続は、コンピュータ可読媒体として適切に規定されてもよい。例えば、ソフトウェアがウェブサイト、サーバまたは別の遠隔リソースから、同軸ケーブル、光ケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）を経由して、または、赤外線、無線、及びマイクロ波等の無線方式を介して伝達される場合、これはやはり、規定されたコンピュータ可読媒体として含まれる。ディスク（ｄｉｓｋ）及びディスク（ｄｉｓｃ）は、コンパクトディスク（ｄｉｓｃ）、レーザディスク（ｄｉｓｋ）、光ディスク（ｄｉｓｋ）、ＤＶＤ、フロッピーディスク（ｄｉｓｃ）、及び、ブルーレイ光ディスク（ｄｉｓｋ）を含む。ディスク（ｄｉｓｃ）は一般に磁気的にデータを複製し、ディスク（ｄｉｓｋ）は一般にレーザを使用して光学的にデータを複製する。上記の組合せがまた、コンピュータ可読媒体として含まれてもよい。

上記で説明された例示的な実施形態は、さらに詳細に、本出願の実施形態の目的、技術的解決策及び有用な効果を説明する。上記の説明が、本出願の実施形態の例示的な実施形態に過ぎず、本出願の実施形態の保護の範囲を制限することを意図するものでないことを理解すべきである。本出願の実施形態の精神及び原則から逸脱することなく成される任意の修正、等価の置換、改良等は、本出願の実施形態の保護の範囲内にあるものである。

Claims (19)

1. ブラウザによるローカルサービスコンポーネントの呼び出しの実行方法であって、前記方法が、
   クライアント端末が、ブラウザ端末により開始されるクロスドメイン通信プロトコルに基づく接続要求を受信することと、
   前記クライアント端末が、前記接続要求を受信する際に、設定されたポートバインディング優先順位に従って、バインディングのためのポートリストからポートを選択することと、
   前記クライアント端末が、前記接続要求の妥当性検証を行うことと、
   前記接続要求が前記妥当性検証をパスする場合、前記ブラウザ端末がローカルサービスコンポーネントを呼び出すことができるように、前記クライアント端末が、前記クロスドメイン通信プロトコルに基づいて前記ブラウザ端末との通信接続を確立すること
   を含む、前記方法。
2. 前記ポートバインディング優先順位が、前記ブラウザ端末のポート選択優先順位と一致する、請求項１に記載の方法。
3. 前記クライアント端末が、前記クライアント端末が故障したとき、その故障レポートをサーバへ送信する、請求項１に記載の方法。
4. 前記故障レポートが、エラーコード、エラー位置、及び現在の状態を含む、請求項３に記載の方法。
5. 前記クロスドメイン通信プロトコルが、ＷｅｂＳｏｃｋｅｔプロトコル、ＪＳＯＮＰプロトコル、またはＣＯＲＳプロトコルを含む、請求項１に記載の方法。
6. 前記妥当性検証が、前記接続要求を開始する前記ブラウザ端末に対応するウェブサイトが、ウェブサイトホワイトリストに含まれるウェブサイトであるかどうかを、前記クライアント端末により判定することを含む、請求項１に記載の方法。
7. 前記クライアント端末が、サーバに周期的に問い合わせることにより、前記ウェブサイトホワイトリストをアップデートする、請求項６に記載の方法。
8. 前記クライアント端末が、オペレーティングシステムのアプリケーションプログラミングインターフェースを介して前記オペレーティングシステムに組み込まれた障害診断プログラムを呼び出すことにより、前記故障レポートを取得する、請求項３に記載の方法。
9. 前記通信接続が確立された後、前記ブラウザにより前記ローカルサービスコンポーネントを呼び出すプロセスが、
   １）前記クライアント端末が、前記ブラウザ端末により送信されるコマンドを受信すること、
   ２）前記クライアント端末が前記コマンドをパースし、対応するローカルサービスコンポーネントへ前記コマンドを送ること、
   ３）前記クライアント端末が、前記コマンドを処理した後に、前記ローカルサービスコンポーネントにより返信される処理結果を受信すること、
   ４）前記クライアント端末が前記ブラウザ端末へ前記処理結果を転送すること
   を含む、請求項１に記載の方法。
10. ブラウザによりローカルサービスコンポーネントの呼び出しを実行するための装置であって、前記装置がクライアント端末であり、
    ブラウザ端末により開始されるクロスドメイン通信プロトコルに基づく接続要求を受信するように構成される接続要求受信モジュールと、
    前記接続要求受信モジュールが前記接続要求を受信する場合、設定されたポートバインディング優先順位に従って、バインディングのためのポートリストからポートを選択するように構成されるポートバインディングモジュールと、
    前記接続要求の妥当性検証を行うように構成される妥当性検証モジュールと、
    前記接続要求が前記妥当性検証をパスする場合、前記ブラウザ端末に、ローカルサービスコンポーネントを呼び出すことを可能にするように、前記クロスドメイン通信プロトコルに基づいて前記ブラウザ端末との通信接続を確立するように構成される接続制御モジュールと
    を含む、前記装置。
11. 前記ポートバインディング優先順位が、前記ブラウザ端末のポート選択優先順位と一致する、請求項１０に記載の装置。
12. 前記クライアント端末が
    故障したことを判定する際に、前記クライアント端末の故障レポートをサーバへ送信するように構成される故障レポート処理モジュール
    をさらに含む、請求項１０に記載の装置。
13. 前記故障レポートが、エラーコード、エラー位置、及び現在の状態を含む、請求項１２に記載の装置。
14. 前記クロスドメイン通信プロトコルが、ＷｅｂＳｏｃｋｅｔプロトコル、ＪＳＯＮＰプロトコル、またはＣＯＲＳプロトコルを含む、請求項１０に記載の装置。
15. 前記妥当性検証が、
    前記接続要求を開始する前記ブラウザ端末に対応するウェブサイトが、ウェブサイトホワイトリストに含まれるウェブサイトであるかどうかを、前記妥当性検証モジュールにより判定すること
    を含む、請求項１０に記載の装置。
16. 前記クライアント端末が、
    サーバに周期的に問い合わせることにより、前記ウェブサイトホワイトリストをアップデートするように構成されるアップデートモジュール
    をさらに含む、請求項１５に記載の装置。
17. 前記故障レポート処理モジュールが、オペレーティングシステムのアプリケーションプログラミングインターフェースを介して前記オペレーティングシステムに組み込まれた障害診断プログラムを呼び出すことにより、前記故障レポートを獲得する、請求項１２に記載の装置。
18. ブラウザによりローカルサービスコンポーネントの呼び出しを実行するためのシステムであって、
    クライアント端末に対し、クロスドメイン通信プロトコルに基づく接続要求を開始するように構成されるブラウザ端末と、
    前記接続要求を受信する際に、設定されたポートバインディング優先順位に従って、バインディングのためのポートリストからポートを選択し、前記接続要求の妥当性検証を行い、前記接続要求が前記妥当性検証をパスする場合、前記ブラウザ端末に、ローカルサービスコンポーネントを呼び出すことを可能にするように、前記クロスドメイン通信プロトコルに基づいて前記ブラウザ端末との通信接続を確立するように構成される前記クライアント端末と
    を含む、前記システム。
19. 前記クライアント端末により送信される故障レポートを受信及び記憶するように構成されるサーバ
    をさらに含む、請求項１８に記載のシステム。

Images