【事件の表示】
　特願２００９−５２６９４１「利用者ベースのバイアスを使用した検索結果の取得又は提供方法および装置」拒絶査定不服審判事件〔平成２０年　３月　６日国際公開、ＷＯ２００８／０２８１５０、平成２２年　１月２８日国内公表、特表２０１０−５０３０８１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯 
　本願は、平成１９年８月３１日（パリ条約による優先権主張外国庁受理２００６年８月３１日、アメリカ合衆国）を国際出願日とする出願であって、平成２３年８月１１日付けで拒絶理由の通知がなされ、同年１１月２２日付けで手続補正書の提出がなされ、平成２４年３月１５日付けで拒絶査定がなされ、これに対して同年７月２３日付けで拒絶査定不服審判の請求がなされるとともに手続補正書の提出がなされ、当審において、平成２５年１月２４日付けで前置報告書を利用した審尋がなされ、同年４月３０日付けで回答書の提出がなされたが、同年７月３日付けで平成２４年７月２３日付け手続補正に対して補正の却下の決定がなされるとともに最後の拒絶理由が通知され、平成２６年１月８日付けで手続補正書の提出がなされたものである。
　
　
　　　　　
２．本願発明 
　本願の請求項１に係る発明は、平成２６年１月８日付け手続補正書によって補正された特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである（以下「本願発明」という）。
　　　　  
「通信システム中の１つ以上のコンポーネントによって検索結果を提供する方法であって、
　ユーザによって提起されたクエリを受信することと、
　前記クエリに基づいて検索を実行することと、
　検索結果を取得することと、
　フレンド・データベースからフレンド・バイアス・データを検索することにより前記ユーザに関連付けられたフレンド・バイアスを決定することと、なお、前記フレンド・データベースは前記ユーザに関連付けられたアクセス端末に記憶されたコンタクト・リストを備える、
　検索された前記フレンド・バイアス・データに基づいて、前記検索結果にバイアスを適用することと、
　前記バイアスが適用された検索結果を記憶することと、
　を具備する方法。」
　　　　
　
　　　　 　　　
３．引用文献 
　平成２５年７月３日付けの拒絶理由通知で引用した国際公開第２００６／０５０２７８号（以下、「引用文献」という）には、下記の事項が記載されている。
　　
Ａ 「 [0063] Fig. 7 is a flow diagram of a process 700 that may be implemented in query processing module 162 (Fig. 2) for incorporating a user's previously stored judgment data into a response to a current query from that user. At step 702, the query is received. At step 704, a list of hits corresponding to the query is obtained, e.g., from page index 170 (Fig. 2). At step 706, query processing module 162 ranks the hits, e.g., using conventional algorithms.
 [0064] At step 708, query processing module 162 determines whether the user identifier for this user is known (e.g., whether the user has logged in). If not, query processing module 162 may send the results page to the user without personalization at step 710, enabling users to perform searches and obtain results without logging in or being registered in any way with search server 160. If the user is known at step 708, then the results page is customized for that user, based on information in personalization database 166.
 [0065] More specifically, at step 712, query processing module 162 provides the user identifier to personalization database 166 and obtains judgment records authored by that user. At step 714, the URLs of the retrieved judgment records are compared to URLs of the hits to detect any hits that match URLs for which the user has previously entered judgments. For judgments where Host flag is set to true, a match (referred to herein as a partial match) is detected if the hostname portion of the hit URL (e.g., http://www.domain.tld/) matches the host name portion of the URL stored in the judgment record. Otherwise, an exact match between the judgment URL and the hit URL is required. For each match, it is determined at step 716 whether the judgment is favorable (positive), e.g., by reference to the Score field of the judgment record. If so, then the hit is added to the favored results (My Results) list.
 [0066] At step 720, after comparisons between hits and judgments are completed, the results list is optionally reranked using the judgment information. For example, a base score can be generated for each hit (whether it matches a judgment or not) using a conventional ranking algorithm. For hits that matched a judgment, a bonus can be determined from the judgment's Score value. The bonus is advantageously defined such that favorably rated sites tend to move up in the rankings while unfavorably rated sites tend to move down. For instance, if low scores are better, the bonus for a favorable rating may be defined as a negative number and the bonus for an unfavorable rating as a positive number. In some embodiments, partial URL matches may be given a smaller bonus than exact URL matches. Unrated sites would receive no bonus. This bonus can be added (algebraically) to the base score to determine a final score for each hit, and reranking can be based on the final score.
 [0067] In some embodiments, reranking at step 720 may also include dropping hits that match unfavorably rated sites from the list of hits to be displayed. In such embodiments, the search results page sent to the user may include an indication of the number of hits that were dropped due to unfavorable ratings and/or a Show all hits button (or other control) that allows the user to see the search results displayed with the unfavorably rated hits included. Another variation allows the user to click on a link to see just the unfavorably rated hits.
 [0068] At step 722, the My Results list is ranked, hi one embodiment, this ranking may be done, e.g., using the same final score described above. In another embodiment, hits in the My Results list may be sorted by user rating; hits with the same rating may be further sorted according to the base score described above. The results page, in this case including the personalized My Results section, is sent to the user at step 710. 」 
　
（当審訳「[００６３]　 図７は、ユーザの以前に記憶された判断データをそのユーザからの現在質問に対する応答に合体するために質問応答モジュール１６２（図２）において実施できるプロセス７００を示すフローチャートである。ステップ７０２において、質問が受け取られる。ステップ７０４において、その質問に対応するヒットのリストが、例えば、ページインデックス１７０（図２）から得られる。ステップ７０６において、質問応答モジュール１６２は、例えば、従来のアルゴリズムを使用して、ヒットをランク付けする。
［００６４］　ステップ７０８において、質問応答モジュール１６２は、このユーザのユーザ識別子が既知であるかどうか（例えば、ユーザがログインしたかどうか）決定する。もしそうでなければ、質問応答モジュール１６２は、ステップ７１０において、個人化を伴わずにユーザへ結果ページを送信し、ユーザが、ログインしたり又はサーチサーバー１６０に何らかの仕方で登録されたりせずに、サーチを遂行して結果を得ることができるようにする。ステップ７０８においてユーザが既知である場合には、結果ページが、個人化データベース１６６の情報に基づいて、そのユーザに対してカスタマイズされる。
［００６５］　より詳細には、ステップ７１２において、質問応答モジュール１６２は、ユーザ識別子を個人化データベース１６６に供給し、そのユーザにより創作された判断レコードを得る。ステップ７１４において、検索された判断レコードのＵＲＬがヒットのＵＲＬと比較され、ユーザが以前に判断を入力したところのＵＲＬに一致するヒットを検出する。「ホストフラグ」が真にセットされた判断については、ヒットＵＲＬ（例えば、ｈｔｔｐ：／／ｗｗｗ．ｄｏｍａｉｎ．ｔｌｄ／）のホスト名部分が、判断レコードに記憶されたＵＲＬのホスト名部分に一致する場合に、一致（ここでは、「部分一致」と称される）が検出される。さもなければ、判断ＵＲＬとヒットＵＲＬとの間の「厳密」な一致が要求される。各一致に対して、ステップ７１６において、例えば、判断レコードの「スコア」フィールドを参照することにより、判断が好評（肯定的）であるかどうか決定される。もしそうであれば、好評結果（“My Results”）リストにヒットが追加される。
［００６６］　ステップ７２０において、ヒットと判断との間の比較が完了した後に、判断情報を使用して、結果リストが任意に再ランク付けされる。例えば、従来のランク付けアルゴリズムを使用して、各ヒットに対して（それが判断に一致するかどうかに関わらず）ベーススコアを発生することができる。判断に一致するヒットについては、判断のスコア値から「ボーナス」を決定することができる。このボーナスは、好評に格付けされたサイトがランクをアップ方向に移動する傾向となり、一方、不評に格付けされたサイトがダウン方向に移動する傾向となるように好都合に定義される。例えば、低いスコアの方が良い場合には、好評な格付けに対するボーナスは、負の数として定義することができ、不評な格付けに対するボーナスは、正の数として定義することができる。ある実施形態では、部分的ＵＲＬ一致には、厳密なＵＲＬ一致より小さなボーナスしか与えられない。格付けされないサイトは、ボーナスを受けない。このボーナスは、各ヒットに対する最終的なスコアを決定するようにベーススコアに加算（代数的に）することができ、この最終的なスコアに基づいて再ランク付けを行うことができる。
［００６７］　又、ある実施形態では、ステップ７２０における再ランク付けは、不評に格付けされたサイトに一致するヒットを、表示されるべきヒットのリストからドロップすることを含んでもよい。このような実施形態では、ユーザに送信されるサーチ結果ページは、不評な格付けのためにドロップされたヒットの数の指示、及び／又は不評に格付けされて含まれたヒットと共に表示されるサーチ結果をユーザが見るのを許す“Show all hits(全てのヒットを示す)”ボタン（又は他のコントロール）を含むことができる。別の変形例では、ユーザが、不評に格付けされたヒットだけを見るためのリンクをクリックすることが許される。
［００６８］　ステップ７２２において、“My Results”リストがランク付けされる。一実施形態では、このランク付けは、例えば、上述した同じ最終的スコアを使用して行うことができる。別の実施形態では、“My Results”リストにおけるヒットをユーザの格付けにより分類することができ、同じ格付けをもつヒットは、上述したベーススコアに基づいて更に分類することができる。この場合には、個人化された“My Results”区分を含む結果ページが、ステップ７１０において、ユーザへ送信される。」）
　　
Ｂ 「 [0073] In addition, if the user has a trust network defined, scores from members of the trust network may be used to modify the rankings and/or to generate listings of favored results. Aspects of the present invention related to trust networks are described below. 」
　
（当審訳「[００７３]  更に、ユーザが、定義された信頼ネットワークを有する場合に、その信頼ネットワークのメンバーからのスコアを使用して、ランクを変更し、及び／又は好評結果のリストを発生することができる。信頼ネットワークに関連した本発明の態様を以下に説明する。」）
　
Ｃ 「 [0096] Fig. 10 illustrates a trust network interface page 1000 according to one embodiment of the present invention. Page 1000 provides various mechanisms for the user to view and modify a list of trusted users (which serves, in this instance, as a community). The current trusted list is shown in a table 1002 that lists the user ID, trust weight, and a description for each member. The Description field, which may be blank, can be populated by the user with any information desired, such as the member's real name, nickname, relationship, etc. Table 1002 may be implemented to support sorting by any of its fields and may include other information about each member (e.g., a timestamp indicating when the member was added). Some embodiments may also provide an Active flag for each member, allowing the user to temporarily disregard that member's judgments without removing the member from the list. Information for populating table 1002 can be stored, e.g., in appropriate records in personalization database 166. 」
　
（当審訳「[００９６]　 図１０は、本発明の一実施形態による信頼ネットワークインターフェイスページ１０００を示す。このページ１０００は、ユーザが、信頼性のあるユーザのリスト（この例では、コミュニティとして働く）を見て変更するための種々のメカニズムを与える。現在の「信頼リスト」は、各メンバーに対するユーザＩＤ、信頼性重み及び記述をリストしたテーブル１００２に示されている。ブランクでもよい記述フィールドは、ユーザにより、メンバーの本名、ニックネーム、関係等の必要な情報でポピュレートすることができる。テーブル１００２は、そのフィールドのいずれかにより分類をサポートするように実施され、そして各メンバーに関する他の情報（例えば、いつメンバーが追加されたかを示すタイムスタンプ）を含んでもよい。又、ある実施形態は、各メンバーに対してアクティブなフラグも与え、ユーザが、リストからメンバーを除去せずにそのメンバーの判断を一時的に無視するのを許す。テーブル１００２をポピュレートするための情報を、例えば、個人化データベース１６６において適切なレコードに記憶することができる。」）
　　
Ｄ 「 [0104] Those skilled in the art will appreciate that a trust network can be generated from a variety of data sources, not limited to EVI friends lists. For example, e-mail address books maintained by various users may provide identifiers for users they regularly communicate with. In another embodiment, membership of two users in the same Yahoo! group (or any other voluntary association of users) may be used to establish a bidirectional relationship between the users. In addition, various web-based social networking services have developed protocols that allow users to define associations or relationships between themselves and others, with extended networks being built up from the user-defined associations; such protocols may be adapted for defining trust networks for practicing the present invention. In yet another embodiment, user demographics can be used to define relationships among users (e.g., users with the same ZIP code or users belonging to a particular age group). In still another embodiment, relationships between users can be defined by analyzing the judgment data entered by various users. For example, two (or more) users who tend to rate pages or sites similarly may be included in a community. 」
　
（当審訳「[０１０４] 当業者であれば、信頼ネットワークは、種々のデータソースから発生することができ、ＩＭ友人リストに限定されないことが明らかであろう。例えば、種々のユーザにより維持されるｅメールアドレスブックは、それらが定期的に通信するユーザの識別子を与えることができる。別の実施形態では、同じＹａｈｏｏ！グループ（又はユーザの他の随意の共同体）における２人のユーザのメンバーシップを使用して、ユーザ間の両方向関係を確立することができる。更に、種々のウェブベースの「ソーシャルネットワーキング」サービスは、ユーザがそれら自身とその他の者との間に共同体又は関係を定義するのを許すプロトコルを開発し、ユーザ定義された共同体から拡張ネットワークが構築され、このようなプロトコルは、本発明を実施するための信頼ネットワークを定義するように適応される。更に別の実施形態では、ユーザの人口統計情報を使用して、ユーザ（例えば、同じＺＩＰコードをもつユーザ又は特定年齢グループに属するユーザ）間の関係を定義することができる。更に別の実施形態では、種々のユーザにより入力される判断データを分析することによりユーザ間の関係を定義することができる。例えば、ページ又はサイトを同様に格付けする傾向のある２人（以上の）ユーザをコミュニティに含ませてもよい。」
　
Ｅ 「 
B. Trust Networks in Query Response　
[0108]According to another embodiment of the present invention, query response module 162 accesses trust data, e.g., from personalization database 166, in order to customize a query response for a particular user. Fig. 12 is a flow diagram of a portion of a process 1200 for incorporating judgments of users in a searching user's trust network into query results for the searching user. In one embodiment, process 1200 is performed during process 700 (Fig. 7), e.g., after generation of the My Results list at steps 716 and 718.
[0109] At step 1202, it is determined whether the user has an active trust list (or trust network). In one embodiment, a trust list is automatically created for each user from whatever data is available about that user's associations. In other embodiments, the user manually defines a trust list. In either case, the user can elect to inactivate use of results from the trust network (e.g., using an option provided via My Ratings page 900 described above). If the user does not have an active trust network, process 1200 exits, proceeding to step 720 of Fig. 7. In this case, only the user's own judgments would affect the search results page.
[0110] If, at step 1202, it is determined that the user has an active trust network, then at step 1204, a list of trusted users and their trust weights is obtained. This may include all of the trust network or some subset thereof (e.g., up to a maximum degree of separation from the user). At step 1206, judgment records created by any of the trusted users are retrieved from personalization database 166. At step 1208, matches between search hits and URLs of judgment records from trusted users are detected; this step is generally similar to step 714 of process 700. At step 1210, an aggregate rating for each matched hit is computed. The aggregate rating may be, e.g., a weighted average of the rating given by each trusted user who rated the site, with weights proportional to the trust weight of each trust network member..」
　
（当審訳「
Ｂ．質問応答における信頼ネットワーク
［０１０８］本発明の別の実施形態によれば、質問応答モジュール１６２は、特定ユーザに対する質問応答をカスタマイズするために、例えば、個人化データベース１６６からの信頼性データにアクセスする。図１２は、サーチユーザの信頼ネットワークにおけるユーザの判断をサーチユーザのための質問結果に合体するプロセス１２００の一部分を示すフローチャートである。一実施形態において、プロセス１２００は、プロセス７００（図７）の間に、例えば、ステップ７１６及び７１８において“My Results”リストが作成された後に遂行される。
［０１０９］ステップ１２０２では、ユーザがアクティブな信頼リスト（又は信頼ネットワーク）を有するかどうか決定される。一実施形態において、各ユーザに対して、そのユーザの共同体に関してどんなデータが入手できるかということから、信頼リストが自動的に生成される。他の実施形態では、ユーザは、信頼リストを手動で定義する。いずれの場合でも、ユーザは、信頼ネットワークからの結果のインアクティブな使用を選択することができる（例えば、上述した“My Ratings”ページ９００を経て与えられる選択肢を使用して）。ユーザがアクティブな信頼ネットワークをもたない場合には、プロセス１２００を退出し、図７のステップ７２０へ進む。この場合には、ユーザ自身の判断がサーチ結果ページに影響するだけである。
［０１１０］ステップ１２０２において、ユーザがアクティブな信頼ネットワークを有すると決定された場合には、次いで、ステップ１２０４において、信頼性のあるユーザ及びそれらの信頼性重みが得られる。これは、信頼ネットワーク又はその何らかのサブセットの全部を含んでもよい（例えば、ユーザから最大分離度まで）。ステップ１２０６において、信頼性のあるユーザのいずれかにより生成された判断レコードが個人化データベース１６６から検索される。ステップ１２０８において、信頼性あるユーザからの判断レコードのＵＲＬとサーチヒットとの間の一致が検出され、このステップは、プロセス７００のステップ７１４と一般的に同様である。ステップ１２１０では、各一致ヒットに対する総計格付けが計算される。この総計格付けは、例えば、サイトを格付けした各信頼性のあるユーザにより与えられた格付けの重み付け平均でよく、その重みは、各信頼ネットワークメンバーの信頼性重みに比例する。」）
　
Ｆ　図２には、クライアント１２０とサーチサーバー１６０がインタ−ネット１４０を介して接続され、サーチサーバー１６０は質問応答モジュール１６２を備え、該サーチサーバー１６０は個人化データベース１６６及びページインデックス１７０に接続され、クライアント１２０からサーチサーバ−１６０へ質問が送信される構成が記載されている。
　
　
　ここで、上記引用文献の記載事項について検討する。
（あ）サーチシステムの構成としては、上記Ｆから図２に、クライアント１２０がインターネットを介してサーチサーバ−１６０に接続され、クライアント１２０から送信された質問をサーチサーバー１６０において受信する構成が記載されている。
　
（い）サーチサーバー１６０におけるサーチ処理については、上記Ａにサーチサーバー１６０内の質問応答モジュール１６２が実施する処理として、ユーザからの質問を受け付け、ページインデックス１７０から該質問に対応するヒットのリストを得てからヒットのランク付けを行い、個人化データベースから質問したユーザの判断レコードを取得し、取得した判断レコードに基づいてヒットの再ランク付けを行い、その結果をユーザに送信することが記載されている。
　
（う）ヒットのランク付けの変更については、上記（い）に記載したユーザの判断レコードだけではなく、信頼ネットワークのメンバーのスコアを使用できることが上記Ｂに記載されている。
　
（え）信頼ネットワークのメンバーのスコアを使用する処理については、信頼性のあるユーザにより生成された判断レコードを個人化データベース１６６から検索して利用することが上記Ｅに記載されている。
　
（お）上記（い）乃至（え）の記載から、引用文献には、「個人化データベースから信頼性のあるユーザの判断レコードを取得し、取得した信頼性のあるユーザの判断レコードに基づいてヒットの再ランク付け」を行うことが記載されているといえる。
　
　　
　よって、上記（あ）乃至（お）及び関連図面の記載から、引用文献には、実質的に下記の発明（以下、「引用発明」という）が記載されている。
　　
　「サーチサーバーによってサーチした結果をインターネットを介してクライアントへ送信する方法であって、
　ユーザからの質問を受け付け、
　ページインデックスから前記質問に対応するヒットのリストを得て、
　前記ヒットのランク付けを行い、
　個人化データベースから信頼性のあるユーザの判断レコードを取得し、
　前記取得した信頼性のあるユーザの判断レコードに基づいて前記ヒットの再ランク付けを行い、結果をユーザに送信する方法。」
　　　　
　　　
　　　　　　　　　　  
４．対比 
（１）本願発明と引用発明との対応関係について
（ア）本願発明の「コンポーネント」は、通信システム中のものであり、かつ、検索結果を提供するものであるところ、引用発明の「サーチサーバー」も、インターネットを介してクライアントと接続され、かつ、サーチした結果をクライアントへ提供するものであるから、引用発明の「サーチサーバー」は、本願発明の「通信システム中の１つ以上のコンポーネント」に相当する。
　よって、引用発明の「サーチサーバーによってサーチした結果をインターネットを介してクライアントへ送信する方法」は、本願発明の「通信システム中の１つ以上のコンポーネントによって検索結果を提供する方法」に相当している。
　
（イ）引用発明の「サーチ」、「質問」は、本願発明の「検索」、「クエリ」に相当しているので、引用発明の「ユーザからの質問を受け付け」は、本願発明の「ユーザによって提起されたクエリを受信すること」に相当する。
　
（ウ）引用発明では、質問に基づいてページインデックスを検索することでヒットのリストが得られるものであるから、引用発明の「ページインデックスから前記質問に対応するヒットのリストを得て」は、本願発明の「前記クエリに基づいて検索を実行することと、検索結果を取得することと」に相当している。
　
（エ）本願発明の「フレンド・バイアス・データ」は、「検索結果にバイアスを適用する」ために利用され、「フレンド・データベース」から検索されるものであるのに対し、引用発明の「信頼性のあるユーザの判断レコード」は、「ヒットの再ランク付け」に利用され、「個人化データベース」から取得されるものであるから、引用発明の「信頼性のあるユーザの判断レコード」、「ヒットの再ランク付け」、「個人化データベース」は、それぞれ本願発明の「フレンド・バイアス・データ」、「検索結果にバイアスを適用する」、「フレンド・データベース」に対応したものである。
　そこで、本願発明の「バイアスを適用する」について検討し、次に、本願発明の「フレンド・バイアス・データ」について検討する。
　
（オ）本願発明の「バイアスを適用する」について
　本願発明の「バイアスを適用する」については、本願特許請求の範囲の請求項４に「検索結果を順位付けすること」と特定されていることから、引用発明の「ヒットの再ランク付け」は、本願発明の「バイアスを適用する」に相当している。
　
（カ）本願発明の「フレンド・バイアス・データ」について
　本願明細書の段落【００２５】には、フレンド・リストから抽出された情報を利用して検索結果にバイアスを適用することが記載され、段落【００２２】には、フレンド・リストが１つ以上の基準に基づく所定の係わりを有する１つ以上の主体、例えば、所属団体、仲間等であることが記載され、段落【００８９】乃至【００９４】には、フレンド・バイアス・データによる処理の具体例として、フレンド・データベースから得たマイクのフレンドであるチャドのバイアスを処理して、チャドがカブズディナーのチョコレートミルクシェーキを好み、ディナーに９８回訪れたことを判定している。これらのことから、本願発明の「フレンド・バイアス・データ」には、検索を行うユーザの所属団体や仲間の見解や行動に関するデータが含まれ得ると解される。
　これに対して、引用発明の「信頼性のあるユーザの判断レコード」について検討すると、引用文献の上記Ｄには、信頼ネットワークがインスタントメッセージ（ＩＭ）の友人リストやｅメールアドレスブック等から発生できることが記載されており、上記Ｅには判断レコードとして上記Ａと同様の好評とされたＵＲＬが例示されている。これらのことから、引用発明の「信頼性のあるユーザの判断レコード」には、検索を行うユーザの友人のＵＲＬに対する評価に関するデータが含まれている。
　よって、引用発明の「信頼性のあるユーザの判断レコード」は、本願発明の「フレンド・バイアス・データ」に相当している。
　
（キ）上記（エ）乃至（カ）から、引用発明の「信頼性のあるユーザの判断レコード」、「ヒットの再ランク付け」、「個人化データベース」は、それぞれ本願発明の「フレンド・バイアス・データ」、「検索結果にバイアスを適用する」、「フレンド・データベース」に相当している。
　
（ク）引用文献の上記Ａには、判断レコードが「スコア」フィールドを有し、該スコアフィールドのスコア値を用いてヒットの再ランク付けを行うことが記載され、上記スコアフィールドのスコア値を用いることは本願発明のフレンド・バイアスを決定することに相当していると認められる。
　よって、上記（キ）の対応関係も踏まえれば、引用発明も、「フレンド・データベースからフレンド・バイアス・データを検索することによりユーザに関連付けられたフレンド・バイアスを決定することと、検索された前記フレンド・バイアス・データに基づいて、検索結果にバイアスを適用する」処理を行っているといえる。
　　
　　　
（２）本願発明と引用発明の一致点について
　上記の対応関係から、本願発明と引用発明は、
　
「通信システム中の１つ以上のコンポーネントによって検索結果を提供する方法であって、
　ユーザによって提起されたクエリを受信することと、
　前記クエリに基づいて検索を実行することと、
　検索結果を取得することと、
　フレンド・データベースからフレンド・バイアス・データを検索することにより前記ユーザに関連付けられたフレンド・バイアスを決定することと、
　検索された前記フレンド・バイアス・データに基づいて、前記検索結果にバイアスを適用することと、
　を具備する方法。」
　　
の点で一致している。
　
　　　　　
（３）本願発明と引用発明の相違点について
　本願発明と引用発明とは、下記の点で相違する。
　
（相違点１）
　フレンド・データベースについて、本願発明は「前記フレンド・データベースは前記ユーザに関連付けられたアクセス端末に記憶されたコンタクト・リストを備える」としているのに対し、引用発明はそのようなリストを備えるものであるか定かではない点。
　　
（相違点２）
　本願発明は「前記バイアスが適用された検索結果を記憶する」としているのに対し、引用発明はそのような処理を行っているか定かではない点。
　　
　　
　　
５．当審の判断 
（１）相違点１について
　引用発明では、個人化データベースから信頼性のあるユーザの判断レコードを取得することが行われるが、そのためには、検索を行っているユーザ毎に誰を「信頼性のあるユーザ」にするかを設定して参照できるようにしておかなければならない。
　この点について、引用文献の上記Ｃには、信頼性のあるユーザをリストにしたテーブルを個人化データベースに記憶することが記載され、
上記Ｄには、該リストの生成元として、
種々のユーザにより維持されるｅメールアドレスブック
　そして、クライアントに備えられたｅメールアプリケーションにおいて、ｅメールアドレスブックをクライアントで管理記憶する構成は、引用文献を示すまでもなく周知技術である。
　してみると、引用文献の上記Ｄの記載に接した当業者であれば、個人化データベースに記憶する「信頼性のあるユーザ」のリストを生成するために、クライアントで管理記憶されたｅメールアドレスブックに登録されたユーザの情報を利用することは、格別に困難無くなし得る程度のものである。
　よって、引用文献に記載された事項及び周知技術に基づき引用発明を相違点１に係る構成とすることは、当業者が容易に想到し得たものである。
　
　
（２）相違点２について
　引用文献には、質問応答モジュール１６２において、再ランク付けを行った結果を記憶することは記載されていない。しかしながら、インターネットを介してクライアントへ処理結果を送信する場合にサーバーにおいて処理結果を記憶することは、情報処理の分野では引用文献を示すまでもなく周知技術にすぎない。
　よって、引用発明において、再ランク付けした結果をユーザへ送信する前にサーチサーバー内で該結果を記憶させることは、格別なこととは認められない。
　
　
（３）本願発明の作用効果について　　　
　平成２６年１月８日付け意見書において、審判請求人は、「３．特許法第２９条第２項による拒絶について」欄において、引用刊行物１に記載された「ｅメールアドレスブック」は、「あるオンラインｅメールプロバイダ（例えば、Ｙａｈｏｏ！）に関連付けられたネットワーク上のアドレスブックであり、ユーザに関連付けられたアクセス端末に記憶されたコンタクト・リストではありません。」と主張している。
　しかしながら、引用文献（上記「引用刊行物１」）の上記Ｄには、
「当業者であれば、信頼ネットワークは、種々のデータソースから発生することができ、ＩＭ友人リストに限定されないことが明らかであろう。例えば、種々のユーザにより維持されるｅメールアドレスブックは、それらが定期的に通信するユーザの識別子を与えることができる。別の実施形態では、同じＹａｈｏｏ！グループ（又はユーザの他の随意の共同体）における２人のユーザのメンバーシップを使用して、ユーザ間の両方向関係を確立することができる。」
と記載されていることから、引用文献に記載された「ｅメールアドレスブック」が必ずしも請求人が主張するようなネットワーク上のアドレスブックに限定されるものとは言えない。
　また、仮にそのような事が言えたとしても、上記「５．当審の判断（１）相違点１について」において述べたとおり、引用文献にはリストの生成元のデータとしてｅメールアドレスブックが利用できることが記載され、かつ、ｅメールアドレスブックをクライアントで管理記憶する構成は周知技術であることを踏まえれば、クライアントに管理記憶されたｅメールアドレスブックのデータから「信頼性のあるユーザ」のリストを生成して個人化データベースに記憶させることは、当業者が格別に困難無くなし得る程度のものであるから、上記請求人の主張を採用することはできない。
　そして、本願発明の作用効果も、引用発明、引用文献に記載された事項及び周知技術から当業者が予測できる範囲のものである。　　　　
　　
　
　　　
６．むすび 
　以上のとおり、本願発明は、引用発明、引用文献に記載された事項及び周知技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。 
　よって、結論のとおり審決する。