特許第6576932号(P6576932)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ビーストライプ・エルエルシーの特許一覧 ▶ アーロン・エフ・ラブレイスの特許一覧 ▶ シアラン・エス・トンプソンの特許一覧 ▶ スティーブン・エム・マルコウィッツの特許一覧

特許6576932信頼できない検索エンジンから信頼できる検索エンジンへ検索要求をリダイレクトする方法
<>
  • 特許6576932-信頼できない検索エンジンから信頼できる検索エンジンへ検索要求をリダイレクトする方法 図000002
  • 特許6576932-信頼できない検索エンジンから信頼できる検索エンジンへ検索要求をリダイレクトする方法 図000003
  • 特許6576932-信頼できない検索エンジンから信頼できる検索エンジンへ検索要求をリダイレクトする方法 図000004
  • 特許6576932-信頼できない検索エンジンから信頼できる検索エンジンへ検索要求をリダイレクトする方法 図000005
  • 特許6576932-信頼できない検索エンジンから信頼できる検索エンジンへ検索要求をリダイレクトする方法 図000006
  • 特許6576932-信頼できない検索エンジンから信頼できる検索エンジンへ検索要求をリダイレクトする方法 図000007
  • 特許6576932-信頼できない検索エンジンから信頼できる検索エンジンへ検索要求をリダイレクトする方法 図000008
  • 特許6576932-信頼できない検索エンジンから信頼できる検索エンジンへ検索要求をリダイレクトする方法 図000009
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6576932
(24)【登録日】2019年8月30日
(45)【発行日】2019年9月18日
(54)【発明の名称】信頼できない検索エンジンから信頼できる検索エンジンへ検索要求をリダイレクトする方法
(51)【国際特許分類】
   G06F 16/955 20190101AFI20190909BHJP
   G06F 21/62 20130101ALI20190909BHJP
【FI】
   G06F16/955
   G06F21/62 345
【請求項の数】8
【全頁数】9
(21)【出願番号】特願2016-543036(P2016-543036)
(86)(22)【出願日】2015年5月29日
(65)【公表番号】特表2017-521735(P2017-521735A)
(43)【公表日】2017年8月3日
(86)【国際出願番号】US2015033384
(87)【国際公開番号】WO2015184392
(87)【国際公開日】20151203
【審査請求日】2018年5月23日
(31)【優先権主張番号】14/725,593
(32)【優先日】2015年5月29日
(33)【優先権主張国】US
(31)【優先権主張番号】62/005,739
(32)【優先日】2014年5月30日
(33)【優先権主張国】US
(73)【特許権者】
【識別番号】317006926
【氏名又は名称】ビーストライプ・エルエルシー
(73)【特許権者】
【識別番号】516186418
【氏名又は名称】アーロン・エフ・ラブレイス
(73)【特許権者】
【識別番号】516186429
【氏名又は名称】シアラン・エス・トンプソン
(73)【特許権者】
【識別番号】516186430
【氏名又は名称】スティーブン・エム・マルコウィッツ
(74)【代理人】
【識別番号】100139778
【弁理士】
【氏名又は名称】栗原 潔
(72)【発明者】
【氏名】アーロン・エフ・ラブレイス
(72)【発明者】
【氏名】シアラン・エス・トンプソン
(72)【発明者】
【氏名】スティーブン・エム・マルコウィッツ
【審査官】 齊藤 貴孝
(56)【参考文献】
【文献】 米国特許出願公開第2013/0054782(US,A1)
【文献】 特開2012−094071(JP,A)
【文献】 米国特許出願公開第2007/0043712(US,A1)
【文献】 米国特許出願公開第2011/0145435(US,A1)
【文献】 米国特許出願公開第2009/0164472(US,A1)
【文献】 特開2013−235465(JP,A)
【文献】 特開2012−118713(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 16/00−16/958
G06F 21/62
(57)【特許請求の範囲】
【請求項1】
コンピューターにより実行される、検索クエリーを信頼できない検索エンジンから信頼できる検索エンジンにリダイレクトする方法であって、
(A)少なくともひとつの信頼できるURLパターンと複数の信頼できないURLパターンを取得するステップと、
(B)求める検索エンジンの検索クエリーに対応する検索クエリーURLを取得するステップと、
(C)前記求める検索エンジンを前記複数の信頼できないURLパターンから発見するために、前記検索クエリーURLを前記複数の信頼できないURLパターンと比較するステップと、
(D)前記求める検索エンジンが前記複数の信頼できないURLパターン内に発見されない場合には、前記求める検索エンジンに前記検索クエリーURLの検索結果を生成するステップと、
(E)前記求める検索エンジンが前記複数の信頼できないURLパターン内に発見された場合には、前記検索クエリーを前記少なくともひとつの信頼できるURLパターンにしたがって信頼できる検索エンジンにリダイレクトするステップとを含む方法。
【請求項2】
請求項1に記載の方法であって、
さらに、更新サーバーに関する情報を取得するステップと、
前記更新サーバーに対して信頼できないパターンの更新を定期的に問い合わせるステップと、
前記更新サーバーから前記信頼できないパターンの更新を取得するステップと、
前記信頼できないパターンを前記複数の信頼できないURLパターンに取り込むステップとを含む方法。
【請求項3】
請求項1に記載の方法であって、
さらに、更新サーバーに関する情報を取得するステップと、
前記更新サーバーに信頼できるパターンの更新を定期的に問い合わせるステップと、
前記更新サーバーから前記信頼できるパターンの更新を取得するステップと、
前記信頼できるパターンの更新を前記少なくともひとつの信頼できるURLパターンに取り入れるステップとを含む方法。
【請求項4】
請求項1に記載の方法であって、
前記求める検索エンジンは複数の信頼できないURLパターン内に発見されず、
前記検索クエリーを前記求める検索エンジンに受け渡すことを許可するステップと、
前記求める検索エンジンによって生成された前記検索結果を受信するステップと、
前記検索結果をユーザー・コンピューティング・デバイス上に表示するステップとを含む方法。
【請求項5】
請求項1に記載の方法であって、
前記検索クエリーを前記検索クエリーURLから抽出するステップと、
前記検索クエリーを信頼できる検索エンジンに受け渡すステップと、
前記信頼できる 検索エンジンから信頼できる検索結果を受信するステップと、
前記検索結果をユーザー・コンピューティング・デバイスに表示するステップとを含む方法。
【請求項6】
請求項1に記載の方法であって、
前記ステップ(A)から前記ステップ(E)までがユーザー・コンピューティング・デバイスによって実行される方法。
【請求項7】
請求項1に記載の方法であって、
仲介サーバーが前記ステップ(A)から前記ステップ(E)までを実行し、ステップ(E)で生成された検索結果ユーザー・コンピューティング・デバイスに送信る方法。
【請求項8】
請求項1に記載の方法であって、
さらに、
前記検索クエリーURLに対応した暗号化されたHTTPリクエストを受信するステップと、
前記前記複数の信頼できないURLパターンのそれぞれと比較するために、前記検索クエリーURLを復号するステップとを含む方法。
【発明の詳細な説明】
【技術分野】
【0001】
本願発明は、一般には、ユーザー・コンピューターによって行なわれ、何らかの外部サーバーに送信されて処理されるインターネット検索クエリーに関する。より具体的には、本願発明は検索クエリーを信頼できない検索エンジンから信頼できる検索エンジンにリダイレクトする方法に関する。本願発明は、外部に送信されるHTTP (Hypertext Transfer Protocol)リクエストを監視し、URL (Uniform Resource Locator)を使用してそのHTTPリクエストが安全ではないと判断された検索エンジンなどのウェブサイトに向けられたものであるかどうかを判定するよう設計されている。もしHTTPリクエストが安全ではない検索エンジン等のウェブサイトに向けられたものである場合には、外部に向かうトラフィックは、本願発明内のプロトコルにおいて安全であると判断された検索エンジンにリダイレクトされる。
【背景技術】
【0002】
インターネットのユーザーは、各ユーザーの活動に関する情報を収集し、保存するウェブサイトを頻繁に訪問する。ウェブサイトが情報を収集し、保存する典型的理由は様々であるが、ユーザーの体験の調整、レポーティング、地理的分析、収益の最適化などが含まれる。ユーザー情報はターゲット広告に利用され、他の企業との間で売却、取引、共有されることがよくある。検索エンジンによって収集されたユーザー情報の集合は収益増に活用できる可能性があるため、企業にとってきわめて価値が高い。検索エンジンから得られたユーザーに関する情報は、インターネット上の他の場所で得られた情報よりも価値が高い。これは、検索エンジンを使用する際には、ユーザーが特定トピックに関する自身の嗜好を示す検索クエリーを入力することが必要だからである。このようなトピックはきわめて個人的であり、そのようなトピックを他人が評価した場合、名声や社会的地位が危うくなることもあり得る。結果的に、多くのインターネット・ユーザーは、ログされた情報を誰かが見るかもしれないということを好まず、情報のログと保存に不安を感じている。
【0003】
インターネット・ユーザーに関する情報の中で最も機密性が高いもののひとつが、ウェブ検索の活動と履歴である。インターネット・ユーザーが検索エンジンを使用してインターネットを検索するとき、そのクエリーは多くの場合IP(Internet Protocol)などの個人を特定できる可能性がある情報と共にログされる。長期的に見れば、検索エンジン企業が、ユーザーのウェブ検索の履歴から個人の問題、病気、願望などの、きわめて機密性が高い情報を明確に理解できるようになる可能性がある。これが、検索エンジンが過去の検索履歴を保存していることに対して多くのインターネット・ユーザーがきわめて不安に感じる主な理由である。また、検索履歴を使用して他のウェブサイトにターゲット広告を表示したり、他者に検索履歴を販売したりする可能性についても不安がある。特に他人が一時的にコンピューターを借りている場合等において、ターゲット広告が他のウェブサイトに表示されることは、ユーザーを当惑させる可能性がある。
【0004】
検索クエリーの履歴情報をログし、保管することで知られる検索エンジンからユーザーを保護するソフトウェアの必要性があることは明らかである。そのようなソフトウェアにより、インターネット上の個人のプライバシー保護が強化され、個人識別情報などの他のデータ要素の保護に貢献できる。検索エンジン使用パターンと検索クエリー履歴の収集と保存からユーザーを保護することが本願発明の目的である。本願発明は、ユーザーのコンピューター上にインストールされ、外部に送信されるHTTPリクエストを常時監視するソフトウェアを提供することでこの目的を達成する。HTTPリクエストは、ユーザー情報をログし、保管することで知られている検索エンジンに向けられたものであるかどうかを判定するよう分析される。HTTPリクエストがこれらの検索エンジンに向けられたものであると判定された場合には、ソフトウェアは自動的にHTTPリクエストをユーザーの検索履歴を保存しない検索エンジンにリダイレクトすることで対応する。ユーザーのプライバシーを損なう検索エンジンなどのURLは、外部サーバーに維持され、最新に保たれ、ソフトウェア・アプリケーション自身に取り込まれる。こうすることで、ソフトウェアは適切にユーザーのHTTPリクエストを判定し、ユーザーのプライバシーを損なわない同等のURLにリダイレクトすることができる。
【図面の簡単な説明】
【0005】
図1】本願発明の全体的プロセスを示すフローチャートである。
図2】本願発明の第一の実施例のワークフロー図である。
図3】本願発明の第二の実施例のワークフロー図である。
図4】複数の信頼できないURLパターンを更新するステップを記述したフローチャートである。
図5】少なくともひとつの信頼できるURLパターンを更新するステップを記述したフローチャートである。
図6】望む検索エンジンに検索結果を生成する許可を与えるステップを記述したフローチャートである。
図7】信頼できる検索エンジンに検索をリダイレクトするステップを記述したフローチャートである。
図8】暗号化されたHTTPリクエストを復号するステップを記述したフローチャートである。
【発明の詳細な説明】
【0006】
すべての図面の記載は、本願発明の特定の実装を記述するためのものであり、本願発明の範囲を限定することを意図したものではない。
【0007】
図1から図3に示される本願発明は、非一過性のコンピューター可読媒体に保存されたコンピューターで実行可能な命令を実行することで、信頼できない検索エンジンから信頼できる検索エンジンへ検索クエリーをリダイレクトする方法である。多くの検索エンジンは、ユーザーのウェブサイトの発見を容易にするが、同時にユーザーが入力した検索クエリーに関する情報も保存する。この情報は、実質的に特定ユーザーのプロファイル構築のために検索エンジンの運営企業により活用され得る。検索エンジンは、検索がどのIP(Internet Protocol)アドレスからのものであるかを知っているため特にこれが言える。多くのインターネット・ユーザーにとって、これはきわめて憂慮すべきプライバシー侵害となる。本願発明はこのプライバシー侵害への対応策として機能する。本願発明は、個人情報を収集する検索エンジンへのアクセスを試みているかを検出し、元々の検索エンジンが信頼できないと判断された場合には、ユーザーの検索を信頼できる検索エンジンにリダイレクトするシステムと方法を提供することに関連する。
【0008】
本願発明のシステムは、検索エンジン上で検索を開始するために、デスクトップ・コンピューター、ラップトップ、タブレット、または、スマートフォンなどのユーザー・コンピューティング・デバイスに依存する。また、ユーザー・コンピューティング・デバイスは、ユーザーの検索の監視とリダイレクトも行なう。本願発明の別の実施例では、ユーザー・コンピューティング・デバイスにより起動されたユーザーの検索の監視とリダイレクトのために、仲介サーバーが提供される。仲介サーバーは、インターネットを介してユーザー・コンピューティング・デバイスと接続され、HTTP(Hypertext Transfer Protocol)リクエストを捕獲し、そのHTTPリクエスト信頼できない検索エンジンをアクセスしようとしているかを判断するよう構成されたサーバーである。加えて、仲介サーバーは、暗号化されたHTTP (HTTPS)リクエストと共に使用してもよい。また、少なくともひとつの信頼できるURL(Uniform Resource Locator)パターンと複数の信頼できないURLパターンも提供される(ステップA)。複数の信頼できないURLパターンは、ユーザーのプライバシーにとって安全ではないと判断される検索エンジンを定義するパターンを保管したリストである。少なくともひとつの信頼できるURLパターンは、安全でない検索を信頼できる検索エンジンにリダイレクトするために使用される。少なくともひとつの信頼できるURLパターンと複数の信頼できないURLパターンは、ユーザー・コンピューティング・デバイスに手作業、または、プログラムによって保管されることができ、XML(Extensible Markup Language)、JSON(JavaScript Object Notation)、または、他のコンピューター可読な形式を取る。複数の信頼できないURLパターンも少なくともひとつの信頼できる URLパターンも、URLの一部または全体を含むことができ、ワイルドカードを含んでいてもよい。ワイルドカードにより、追加の文字列やパターンをひとつのパターンに対応付けることが可能になり、検索クエリー URL が信頼できない検索エンジン由来であるかを判定する上での各パターンの融通性が増す。本願発明のある実施例では、少なくともひとつの信頼できるURLパターンと複数の信頼できないURLパターンを更新するために更新サーバーが提供される。これは、追加の信頼できない検索エンジンが発見された場合において有用である。
【0009】
図1において、本願発明の方法は、コンピューターで実行可能な命令にしたがうソフトウェア・アプリケーションであり、ユーザーが実行した検索を監視し、安全ではないと判断された検索をリダイレクトするために使用される。ユーザーが求める検索エンジンをアクセスし、検索を開始すると、ソフトウェア・アプリケーションは求める検索エンジンの検索クエリーURLを取得する。ここで、検索クエリーURLは検索クエリーに対応する(ステップB)。求める検索エンジンとは、単に、ユーザーが検索を完了しようと考えている検索エンジンのことを指す。求める検索エンジンは安全なことも安全でないこともある。求める検索エンジンが信頼できるかどうかを判断するために、検索クエリーURLが複数の信頼できないURLパターンのそれぞれと複数の信頼できないURLパターン内に求める検索エンジンを発見するために比較される(ステップC)。求める検索エンジンが複数の信頼できないURLパターンの中に発見されなかった場合には、求める検索エンジンはリクエストを処理し、検索クエリー URLの検索結果を生成する(ステップD)。求める検索エンジンが複数の信頼できないURLパターンの中に発見された場合には、ソフトウェア・アプリケーションは検索クエリーを信頼できるURLパターンにしたがって、信頼できる検索エンジンにリダイレクトする(ステップE)。信頼できる検索エンジンとは、少なくともひとつの信頼できるURLパターンと一致し、安全であることが知られている検索エンジンのことである。本願発明の多様な実施例でひとつ以上の信頼できる検索エンジンが使用されてよい。このプロセスにより、信頼できるサイトによってのみ検索が許可され、信頼できないサイトに試みられた検索がリダイレクトされることで、ユーザーの個人情報のプライバシーが保護される。
【0010】
前述のとおり、本願発明の一部の実施例では、複数の 信頼できないURLパターンを定期的に更新するために更新サーバーを使用してよい。図2から図4に示すように、本願発明のシステムに更新サーバーが組み込まれている場合には、ソフトウェア・アプリケーションが定期的に更新サーバーに対して信頼できないパターンの更新を問い合わせる。信頼できないパターンの更新は、新しいまたは編集されたパターン、URL、リンク、構成ファイル、アイコン、などの多様な情報のタイプであってよい。更新が利用可能であるときは、ソフトウェア・アプリケーションは、更新サーバーから信頼できないパターンの更新を取得する。次に、信頼できないパターンの更新は、複数のURLパターンに取り込まれる。このプロセスは、必要な場合に新しい信頼できない検索エンジンが識別できるように行なわれる。加えて、このプロセスにより、ソフトウェア・アプリケーションは、信頼できない検索エンジンをより効率的に継続的に認識できるようになる。
【0011】
図2図3、および、図5において、複数の信頼できないURLパターンと同様に、少なくともひとつの 信頼できるURLパターンに変更を加えるために.更新サーバーが使用されてもよい。このためには、ソフトウェア・アプリケーションが定期的に更新サーバーに信頼できるパターンの更新を問い合わせる。信頼できるパターンの更新は、新しいまたは編集されたパターン、URL、リンク、構成ファイル、アイコンなどの多様なタイプの情報であってよい。更新が利用可能であるときは、ソフトウェア・アプリケーションは、信頼できるパターンの更新を更新サーバーから取得する。次に、信頼できるパターンの更新が少なくともひとつの信頼できるURLパターンに取り込まれる。このプロセスは、検索が信頼できない検索エンジンから正確にリダイレクトされるように行なわれる。加えて、少なくともひとつの信頼できるURLパターンは複数の信頼できる検索エンジンが使用できるように更新されてもよい。
【0012】
図6において、ソフトウェア・アプリケーションが検索クエリーURLを複数の信頼できないURLと比較した後、求める検索エンジンが複数のURLパターン内に発見されなかったときには、ユーザーの検索は求める検索エンジン自由に処理を進めることが許可される。このために、ソフトウェア・アプリケーションは、検索クエリーを求める検索エンジンに受け渡すことを許可する。求める検索エンジンが検索の結果を生成した後、ソフトウェア・アプリケーションは求める検索エンジンによって生成された検索結果を受信する。次に、検索結果がユーザー・コンピューティング・デバイスに表示される。
【0013】
図7に示すように、求める検索エンジンが複数の信頼できないURLパターン内に発見された場合には、ソフトウェア・アプリケーションは、検索を信頼できる検索エンジンにリダイレクトすることで先に進む。そのために、ソフトウェア・アプリケーションは、検索クエリーURLから検索クエリーを抽出する。次に、検索クエリーは信頼できる検索エンジンに渡される。次に、ソフトウェア・アプリケーションは、信頼できる検索エンジンから信頼できる検索結果を取得し、検索結果をユーザー・コンピューティング・デバイスに表示する。ユーザーの検索は求める検索エンジンとの通信の前にリダイレクトされているため、ユーザーの個人情報は求める検索エンジンによってはアクセスされない。その代わりに、検索は、個人情報を収集しない信頼できる検索エンジンにリダイレクトされる。
【0014】
本願発明のシステムと方法には2つの主要な実施例がある。本願発明の第一の実施例では、ステップAからステップEがユーザー・コンピューティング・デバイスによってのみ実行される。この実施例では、ソフトウェア・アプリケーションは、ユーザー・コンピューティング・デバイス上にのみ存在する。この実施例は、デスクトップ・コンピューター、ラップトップ、および、他の同様の比較的高性能のデバイス向けで使用される可能性が高い。この実施例では、ソフトウェア・アプリケーションは、ウェブ・ブラウザー・プラグイン、ブラウザー拡張機能、スタンドアローンのウェブ・ブラウザー、または、ブラウザー以外のソフトウェアなどのインターネット接続機能を備えた同様のアプリケーションの形態を取り得る。本願発明の第二の実施例では、ソフトウェア・アプリケーションは、仲介サーバーがステップAからステップEを実行する形態で使用されるが、ユーザー・コンピューティング・デバイスと仲介サーバーがシームレスに通信できるようにするために、何らかの形態のソフトウェアやネットワーク接続の構成情報が必要とされる可能性が高い。この実施形態では、ステップEで生成された検索結果は、ユーザー・コンピューティング・デバイスに送られる。この実施例はスマートフォン、タブレット、および、他の比較的処理能力が低い低消費電力のインターネット接続コンピューティング・デバイス向けで使用されることを意図している。ユーザー・コンピューティング・デバイスにある構成情報のソフトウェアは、仲介サーバーがユーザー・コンピューティング・デバイスから送られた暗号化された情報を解釈するために使用されてもよい。 ゆえに、ステップAは、検索クエリーURLに関連した暗号化されたHTTP (HTTPS)リクエストを受信することも含む。これは図8に示されている。次に、ソフトウェア・アプリケーションは、検索クエリーURLと複数の信頼できないURLパターンのそれぞれと比較するために、HTTPSリクエストを復号することができる。
【0015】
本願発明は、望ましい実施例との関連により説明されてきたが、ここでクレームされた発明の精神と範囲を逸脱することなく、他の多くの変更や変形が可であることを理解されたい。
図1
図2
図3
図4
図5
図6
図7
図8