拒絶査定不服の審決｜不服2020-15990 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

ポートフォリオを新規に作成して保存		追加
既存のポートフォリオに追加保存		追加

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服 2項進歩性取り消して特許、登録 G06F
管理番号	1377033
審判番号	不服2020-15990
総通号数	262
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2021-10-29
種別	拒絶査定不服の審決
審判請求日	2020-11-19
確定日	2021-09-06
事件の表示	特願2018-567072「文脈情報を提供するためのシステムおよび方法」拒絶査定不服審判事件〔平成29年12月28日国際公開、WO2017/222585、令和 1年 8月15日国内公表、特表2019-522852、請求項の数(20)〕について、次のとおり審決する。
結論	原査定を取り消す。本願の発明は、特許すべきものとする。
理由	第1 手続の経緯本願は,2016年(平成28年)12月2日(パリ条約による優先権主張外国庁受理2016年6月22日,米国)を国際出願日とする出願であって,平成31年2月13日付けで手続補正がされ,令和2年1月30日付けで拒絶理由が通知され,令和2年5月7日付けで手続補正がされ,令和2年7月9日付けで拒絶査定(原査定)がされ,これに対し,令和2年11月19日に拒絶査定不服審判の請求がされると同時に手続補正がされ,令和3年5月31日付けで上申書が提出され,令和3年6月7日付けで拒絶理由(以下,「当審拒絶理由」という。)が通知され,令和3年6月23日付けで手続補正がされたものである。第2 本願発明本願請求項1-20に係る発明(以下,それぞれ「本願発明1」-「本願発明20」という。)は,令和3年6月23日付けの手続補正で補正された特許請求の範囲の請求項1-20に記載された事項により特定される発明であり,本願発明1は以下のとおりの発明である。「【請求項1】データ処理装置において実施される方法であって,前記方法が, ユーザデバイスから,前記ユーザデバイス上のアプリケーション環境内に表示されるアクティブリソースに関連する文脈情報に対する,クエリに依存しない要求を受信するステップであって, 前記クエリに依存しない要求は, ユーザによって入力されたクエリパラメータを含まない要求であり,かつ前記アクティブリソースのスクリーンショットと,前記ユーザデバイスのディスプレイ上に現在レンダリングされているコンテンツを定義した文書オブジェクトモデルとを含む,ステップと, 前記クエリに依存しない要求に応答して,前記スクリーンショットおよび前記文書オブジェクトモデルから,前記アクティブリソースによって記述されたコンテンツを決定するステップと, 前記クエリに依存しない要求に応答して,前記アクティブリソースによって記述された前記コンテンツに関連する複数のリソースを識別するステップと, 前記複数のリソースの各リソースについて,1人または複数のユーザによる前記リソースの関与を反映するユーザ関与の対応する尺度を決定するステップと, 前記複数のリソースに対するユーザ関与の前記尺度に基づいて,前記複数のリソースのうちの1つまたは複数を選択するステップと, 前記ユーザデバイスに,前記アクティブリソースと共に表示するためのユーザインターフェース要素を提供するステップであって,前記ユーザインターフェース要素が,選択時に前記ユーザデバイスに前記それぞれのリソースを要求させる前記選択された複数のリソースの各々に対するナビゲーションリンクを含む,ステップとを含む方法。」なお,本願発明2-20の概要は以下のとおりである。本願発明2-7,18は,本願発明1を減縮した発明である。本願発明8,15は,それぞれ本願発明1に対応するシステム及び非一時的コンピュータ可読記憶媒体の発明であり,本願発明1とカテゴリ表現が異なるだけの発明である。本願発明9-14,19は,本願発明8を減縮した発明である。本願発明16-17,20は,本願発明15を減縮した発明である。第3 引用文献,引用発明等 1.引用文献1について原査定の拒絶の理由に引用された引用文献1(特表2013-534673号公報)には,図面とともに次の事項が記載されている。「【0012】 1.0.全体的概要ユーザがアクセスしたコンテンツに、ビデオ、画像、定義、地図、検索結果、関連リンクなどの文脈的に関連する又は関連性のあるコンテンツの動的に決定されたスニペットを補足することによってユーザのブラウジング体験を高めるための方法、技術及び機構を開示する。以下では「補足コンテンツ」又は「補足」と呼ぶこれらの「スニペット」は、興味を引くエンティティを識別するだけでなく、これらのエンティティに基づく検索結果から取得される、これらのエンティティに関する興味を引く情報も含む。従って、ある実施形態では、これらの補足により、検索エンジンにクエリを送信することなどの不便と思われるステップをユーザが行う必要なく、またコンテンツプロバイダに代わって編集プログラミングを行う必要なくユーザを検索体験に従事させる。【0013】補足コンテンツは、ユーザがアクセスしたコンテンツの分析に少なくとも部分的に基づいて生成される。ある実施形態によれば、各補足は、この分析に少なくとも部分的に基づいて選択された1又はそれ以上のエンティティに関する情報を含む。各エンティティは、分析したコンテンツ内に現れる又はこれに関連する単語、用語又は語句である。1又はそれ以上のエンティティに関する情報は、1又はそれ以上の検索エンジン及び/又はデータベース内で1又はそれ以上のエンティティを検索することにより生成される。補足は、ユーザを対象とした広告などの、分析したコンテンツとは無関係のその他の情報を追加として含むこともできる。」「【0018】ある実施形態では、ユーザがコンテンツの記事を要求したことに応答して、ユーザの要求に応答してサーバ側又はクライアント側の命令が実行された結果として、コンテンツの特定の記事に関して動的に補足が生成される。ある実施形態では、検索プロバイダが、コンテンツ開発者、コンテンツホスター、コンテンツ表示アプリケーション、及び/又は背景アプリケーションがコンテンツの記事を提出し、これと引き換えに、このコンテンツに関する生成された補足を受け取ることができるようにする補足生成サービスを提供する。例えば、ウェブページをブラウザに戻す前にブラウザによってウェブページが要求された場合、ウェブホストプロバイダは、このプロバイダがホストするウェブページを、補足生成サービスを通じて自動的に供給することができる。これにより、ウェブホストプロバイダは、補足コンテンツのための関連情報を手動で識別する必要なく、このプロバイダがホストするあらゆるページに、文脈に依存する捕捉コンテンツを自動的に挿入できるようになる。別の例として、ユーザにブラウザツールバーを提供し、このツールバー内の制御の選択時に、ユーザが現在見ているウェブページを補足生成サービスに送信するようにすることができる。これと引き換えに、このツールバーは、ユーザに表示するための補足コンテンツを受け取る。」「【0024】図1B及び図1Cは、記事110の補足120の代わりに提示できる代替の補足例160及び180である。図1Bには、一次エンティティ131、関連エンティティ133、134、及び一次エンティティ135といった異なるエンティティの組を含む補足160を示している。補足160では、ユーザの個人化、関連性を計算するために使用するデータの時間感度、及び金銭的要因を含む様々な理由で、一次エンティティ132の代わりに一次エンティティ135が選択されたと考えられる。【0025】図1Bの区分163は、図1の区分143とは異なる小区分の組171?174を含む。小区分171?174は、画像のリポジトリ、写真のリポジトリ、ニュース記事のリポジトリ、及び一般的な検索クエリのリポジトリに照らした検索結果にそれぞれ対応する。小区分171は複数の画像を含み、小区分172はインラインビデオを含む。小区分173及び174は、各々が異なる検索結果に対応する複数のリンクを含む。小区分171?173の各々は、これらのそれぞれのリポジトリからさらなる検索結果を取得するためのリンク165を含む。」「【0052】 4.2.クライアント主導の補足図4は、ユーザに補足したコンテンツの記事を提供するための方法例を示すフロー図400である。フロー図400は、補足コンテンツを提供する処理の第2の例を示すものにすぎない。さらに他の処理は、同じ又は異なる順序で構成された、より多くの、より少ない、又は異なるステップを含むことができる。【0053】ステップ410において、クライアント210などの、コンテンツを表示するクライアントが、コンテンツサーバ220などのコンテンツサーバにコンテンツの記事に対する要求を送信する。例えば、ユーザがウェブブラウザを操作してウェブサーバにウェブページを要求することができる。【0054】ステップ420において、この要求に応答して、コンテンツサーバが記事を検索する。例えば、コンテンツサーバは、1又はそれ以上のデータベース又は記憶装置から記事を検索することができる。【0055】ステップ430において、コンテンツサーバは、記事を検索すると、少なくともこの記事を含む構造化文書を生成する。例えば、コンテンツサーバは、ヘッダ、フッタ、サイドバー、及び/又はその他のナビゲーション又は装飾項目とともにウェブページ内に記事のコンテンツを埋め込むことができる。或いは、好適な構造化文書内に前もって記事を記憶しておいて、このステップを不要にしてもよい。【0056】ステップ440において、コンテンツサーバは、記事を含む構造化文書をクライアントに送信することによってステップ420の要求に応答する。【0057】ステップ450において、クライアントは、ステップ370で受け取った構造化文書に基づいて記事のコンテンツを表示する。例えば、構造化文書がウェブページである場合、クライアントは、このウェブページを解析し、マークアップ及びその他の命令に基づいて少なくとも記事をレンダリングし、クライアントを操作しているユーザに表示することができる。【0058】ステップ460において、補足アプリケーション(クライアントアプリケーション、又はクライアントに関連して動作する別のアプリケーションのいずれか)が、補足サーバ230などの補足サーバに、記事に対する補足の要求を送信する。例えば、補足サーバは、このような要求を受け取るためのアプリケーションプログラムインターフェイス(API)を公開することができる。このAPIに従って、補足アプリケーションは、この要求とともに、記事のコンテンツ、及び/又はファイルの経路、データベース記録の識別子、又は記事を検索できる場所を示すユニフォームリソースロケータなどの記事への参照を含む、補足を要求する記事を示すデータを含めることができる。【0059】ステップ470において、ステップ340に関連して及び本開示全体を通じて説明するように、補足サーバは、記事に基づいて補足を生成する。【0060】ステップ480において、補足サーバは、この補足を補足アプリケーションに戻す。ある実施形態では、HTML及び/又はスクリプト命令としてフォーマットされた補足が戻される。【0061】ステップ490において、補足アプリケーションは、記事に関連して補足を表示する。以降、ステップ490は、いつでもステップ450とともに行うことができる。」「【0064】 4.3.補足の生成図5は、コンテンツの記事に関する補足コンテンツを生成するための技術例を示すフロー図500である。フロー図500のステップを、例えば補足サーバにより実施して、図4のステップ470又は図3のステップ340に従って補足を生成することができる。フロー図500は、補足コンテンツを生成する処理の一例を示すものにすぎない。他の処理は、同じ又は異なる順序で構成された、より多くの、より少ない、又は異なるステップを含むことができる。【0065】ステップ510において、補足サーバ230などのサーバが、記事のコンテンツ又はメタデータから複数の構成エンティティを抽出する。複数の構成エンティティの各構成エンティティは、コンテンツ又はメタデータ内に現れる異なるエンティティである。様々な技術を使用して、コンテンツからエンティティを抽出することができる。ある実施形態では、記事内の各ユニークワードが構成エンティティと考えられる。ある実施形態では、コンテンツの構文及び/又は意味分析を使用して構成エンティティを識別し、統計的に重要な単語又は語句を識別することができる。ある実施形態では、記事内の全ての固有名詞が構成エンティティとして識別される。ある実施形態では、事前に定めた関心のあるエンティティの辞書内の単語又は単語の組み合わせを検索することにより構成エンティティが識別される。その他の変形形態は、さらなる分析及び上述した実施形態の組み合わせに依拠することができる。【0066】ステップ520において、サーバが、複数の構成エンティティから一次エンティティの組を選択する。これを行うために、サーバは、各エンティティを1又はそれ以上のランク付け処理にかけることができる。この処理により、各構成エンティティのスコア及び/又は構成エンティティのランクリストが作成される。このランクは、限定ではないが、記事内の各エンティティの位置、コンテンツ内にエンティティが現れる頻度、エンティティが現れる文の言語構造、及び例えば、人物名、組織名又は場所名などの、エンティティが属するものとして分類されるエンティティタイプを含むいくつかの因子に基づくことができる。ある実施形態では、このランクが、記事のコンテンツからエンティティを除外することによってコンテンツの主なトピック又は題材が失われるという点で、エンティティの「アバウトネス」の尺度、すなわちそのエンティティが全体として記事にどれほど関連しているかについての尺度を少なくとも部分的に示す。これに加えて又はこれの代わりに、このランクは、ユーザ又はユーザグループに対するエンティティの関連性、又は最新ニューストピックに対するエンティティの関連性などの、各エンティティの他の側面を定量化するように機能することができる。ある実施形態では、所定数の最も高くランクされた一次エンティティのみが選択される。ある実施形態では、閾値スコアよりも高くスコア付けされた一次エンティティのみが選択される。【0067】ステップ530において、サーバは、記事に基づいて関連エンティティの組を識別する。例えば、サーバは、一次エンティティの組の各エンティティに関する関連エンティティを、関連エンティティの1又はそれ以上のデータベース内で検索することができる。別の例として、サーバは、関連エンティティ識別要素250などの1又はそれ以上の関連エンティティ識別要素に、記事全体、構成エンティティの組、又は一次エンティティの組を供給することができる。 (中略) 【0069】ステップ540において、サーバは、1又はそれ以上の一次エンティティの組及び1又はそれ以上の関連エンティティの組をプールして、記事の補足コンテンツに含める候補である候補エンティティの組を形成する。【0070】ステップ550において、サーバは、候補エンティティの組の各エンティティにランクを付けて、各候補エンティティのスコア及び/又は候補エンティティのランクリストを作成する。この場合も、サーバは、様々なランク付け処理に依拠することができる。ある実施形態では、サーバが、クリック率に関して最適化するためのランク付け、大きな記事の組にわたるエンティティのカバー範囲を最適化するためのランク付け、或いは広告又は検索結果からの収益を最適化するためのランク付けを含む、異なる目的のための異なるランク付け処理を利用することができる。このランク付け処理は、限定ではないが、エンティティに関連する検索の収益、一次エンティティの「アバウトネス」スコア、それぞれの一次エンティティに対するその関連エンティティの関連性ランク、特定のユーザ又はユーザグループに対する関連性、以前にサーバが提供した補足内で各エンティティの検索結果が提示及び/又はクリックされた頻度、及び検索ログ、ブラウジング履歴、及び最新ニュース又はソーシャルメディア記事内における各エンティティの出現頻度によって示される各エンティティの人気の時間依存尺度を含む様々な因子に基づくことができる。なお、これらの因子の一部は、構成エンティティ又は関連エンティティ候補にランク付けする役割を果たすこともできる。【0071】ステップ560において、サーバは、ステップ550のランク付けに少なくとも基づいて候補エンティティの組をフィルタ処理し、最終的なエンティティの組を生成する。ある実施形態では、所定数の最も高くランクされた候補エンティティのみが、最終的なエンティティの組に選択される。ある実施形態では、閾値スコアよりも高くスコア付けされた一次エンティティのみが選択される。 (中略) 【0074】ステップ570において、サーバは、最終的なエンティティの組の各特定のエンティティに関し、この特定のエンティティを検索語として使用して、1又はそれ以上の検索リポジトリに照らした1又はそれ以上のクエリを実行する。例えば、サーバは、最終的なエンティティの組の各エンティティを、ビデオのリポジトリ、ウェブページのリポジトリ、及びWikiｐediaデータベース内で検索することができる。このステップに従ってサーバが検索を行えるその他の考えられるリポジトリとしては、限定ではないが、ビデオ、画像、ウェブページ、オーディオファイル、ニュース記事、ソーシャルメディア、ブログエントリ、ムービーメタデータ、イベントカレンダー、株価情報、地図、スポーツの点数、出荷追跡データ、辞書エントリ、参照エントリなどのリポジトリが挙げられる。」「【0108】ある実施形態では、補足サーバが、クエリプランニング要素及び1又はそれ以上の検索要素の両方を参考にして、検索結果が、又は少なくとも(単複の)上位の検索結果が関連性閾値を満たさないエンティティをフィルタ除去する。あらゆる好適な関連性ランク付けアルゴリズムを使用して、関連性尺度を生成することができる。ある実施形態では、各検索結果タイプが、関連性及び/又は異なる関連性閾値を決定するための異なるアルゴリズムを有することができる。例えば、ニュースコーパス内におけるエンティティの検索では、エンティティに対する各ニュース記事の関連性のカスタマイズした尺度に基づいて検索結果内でニュース記事にランク付けできるのに対し、標準的なウェブリポジトリ内におけるエンティティの検索では、エンティティとの関連性のより一般的な尺度によって検索結果内でウェブ文書にランク付けすることができる。いずれの場合にも、クエリプランニング要素及び/又は検索要素は、関連性尺度を補足サーバに渡し、さらにこの補足サーバが、エンティティに関する関連性尺度が最低限の関連性スコアを個別に又は全体的に満たすことを確実にする。」「図1B 」「図4 」「図5 」したがって,上記引用文献1(特に下線部の記載)には次の発明(以下,「引用発明」という。)が記載されていると認められる。「ユーザがアクセスしたコンテンツに,検索結果,関連リンクなどの文脈的に関連性のあるコンテンツの動的に決定されたスニペットを補足することによってユーザのブラウジング体験を高めるための方法であって,(段落0012) 「補足コンテンツ」又は「補足」と呼ぶこれらの「スニペット」は,エンティティに基づく検索結果から取得されるものであり,(段落0012) これらの補足により,検索エンジンにクエリを送信することなどの不便と思われるステップをユーザが行う必要なくユーザを検索体験に従事させることができ,(段落0012) 補足コンテンツは,ユーザがアクセスしたコンテンツの分析に基づいて生成されるものであり,(段落0013) 各補足は,この分析に基づいて選択されたエンティティに関する情報を含み,各エンティティは,分析したコンテンツ内に現れる単語であり,エンティティに関する情報は,検索エンジン内でエンティティを検索することにより生成されるものであり,(段落0013) ユーザにブラウザツールバーを提供し,このツールバー内の制御の選択時に,ユーザが現在見ているウェブページを補足生成サービスに送信するようにすることができ,これと引き換えに,このツールバーは,ユーザに表示するための補足コンテンツを受け取ることができ,(段落0018) 補足160の区分163は,小区分の組171?174を含み,小区分173及び174は,各々が異なる検索結果に対応する複数のリンクを含むものであり,(段落0024?0025,図1B) ユーザに補足したコンテンツの記事を提供するための方法例では,(段落0052,図4) ステップ410において,クライアント210などの,コンテンツを表示するクライアントが,コンテンツサーバ220などのコンテンツサーバにコンテンツの記事に対する要求を送信し,例えば,ユーザがウェブブラウザを操作してウェブサーバにウェブページを要求することができ,(段落0053,図4) ステップ420において,この要求に応答して,コンテンツサーバが記事を検索し,(段落0054,図4) ステップ430において,コンテンツサーバは,記事を含む構造化文書を生成し,(段落0055,図4) ステップ440において,コンテンツサーバは,記事を含む構造化文書をクライアントに送信し,(段落0056,図4) ステップ450において,クライアントは,受け取った構造化文書に基づいて記事のコンテンツを表示し,例えば,構造化文書がウェブページである場合,クライアントは,このウェブページを解析し,マークアップ及びその他の命令に基づいて少なくとも記事をレンダリングし,クライアントを操作しているユーザに表示することができ,(段落0057,図4) ステップ460において,補足アプリケーション(クライアントアプリケーション)が,補足サーバ230などの補足サーバに,記事に対する補足の要求を送信し,(段落0058,図4) ステップ470において,補足サーバは,記事に基づいて補足を生成し,(段落0059,図4) ステップ480において,補足サーバは,この補足を補足アプリケーションに戻し,HTML及び/又はスクリプト命令としてフォーマットされた補足が戻され,(段落0060,図4) ステップ490において,補足アプリケーションは,記事に関連して補足を表示し,(段落0061,図4) フロー図500のステップを補足サーバにより実施して,前記ステップ470に従って補足を生成する処理では,(段落0064,図5) ステップ510において,記事のコンテンツ又はメタデータから複数の構成エンティティを抽出し,(段落0065,図5) ステップ520において,複数の構成エンティティから一次エンティティの組を選択し,(段落0066,図5) ステップ530において,記事に基づいて関連エンティティの組を識別し,(段落0067,図5) ステップ540において,一次エンティティの組及び関連エンティティの組をプールして,記事の補足コンテンツに含める候補である候補エンティティの組を形成し,(段落0069,図5) ステップ550において,候補エンティティの組の各エンティティにランクを付け,(段落0070,図5) ステップ560において,ステップ550のランク付けに少なくとも基づいて候補エンティティの組をフィルタ処理し,最終的なエンティティの組を生成し,((段落0071,図5) ステップ570において,最終的なエンティティの組の各特定のエンティティに関し,この特定のエンティティを検索語として使用して,検索リポジトリに照らしたクエリを実行するものであり,(段落0074,図5) 補足サーバは,検索結果が関連性閾値を満たさないエンティティをフィルタ除去するために,好適な関連性ランク付けアルゴリズムを使用して,関連性尺度を生成することができ,例えば,ニュースコーパス内におけるエンティティの検索では,エンティティに対する各ニュース記事の関連性のカスタマイズした尺度に基づいて検索結果内でニュース記事にランク付けでき,また,標準的なウェブリポジトリ内におけるエンティティの検索では,エンティティとの関連性のより一般的な尺度によって検索結果内でウェブ文書にランク付けすることができる,(段落0108) 方法。」第4 対比・判断 1.本願発明1について (1)対比本願発明1と引用発明とを対比すると,次のことがいえる。ア(ア)引用発明の「クライアント」は本願発明1の「ユーザデバイス」に相当し,引用発明の前記「クライアント」で動作する「ウェブブラウザ」は本願発明1の「前記ユーザデバイス上のアプリケーション」に相当する。また,引用発明の「ユーザがアクセスしたコンテンツ」又は「ユーザが現在見ているウェブページ(記事)」は,ウェブブラウザ“環境内”において,“現在表示されている”“アクティブ”な“リソース”であるから,本願発明1の「前記ユーザデバイス上のアプリケーション環境内に表示されるアクティブリソース」に相当する。 (イ)上記(ア)の検討を踏まえると,引用発明の「ユーザがアクセスしたコンテンツ」に「文脈的に関連性のあるコンテンツ」の「スニペット(補足コンテンツ,補足)」は,本願発明1の「アクティブリソースに関連する文脈情報」に相当する。 (ウ)引用発明は,「補足アプリケーション(クライアントアプリケーション)が,補足サーバ230などの補足サーバに,記事に対する補足の要求を送信し」ているところ,これを「補足サーバ」の側からみれば,「補足サーバ」は,「クライアント」(本願発明1の「ユーザデバイス」に相当する。)から,「記事(本願発明1の「アクティブリソース」に相当する。)に対する補足の要求」を“受信”しているといえる。そして,当該「要求」は,「検索エンジンにクエリを送信することなどの不便と思われるステップをユーザが行う必要」がないものであるから,本願発明1の「クエリに依存しない要求」に相当する。 (エ)上記(ア)-(ウ)の検討から,引用発明と本願発明1とは,「ユーザデバイスから,前記ユーザデバイス上のアプリケーション環境内に表示されるアクティブリソースに関連する文脈情報に対する,クエリに依存しない要求を受信するステップ」を含む点で一致する。イ(ア)引用発明の「記事に対する補足の要求」(本願発明1の「クエリに依存しない要求」に相当する。)は,「検索エンジンにクエリを送信することなどの不便と思われるステップをユーザが行う必要」がないものであるから,本願発明1の「ユーザによって入力されたクエリパラメータを含まない要求」に相当する。 (イ)引用発明は,「記事に対する補足の要求」をする際に,「ユーザが現在見ているウェブページを補足生成サービスに送信する」ものであるところ,引用発明の「ユーザが現在見ているウェブページ」は本願発明1の「前記ユーザデバイスのディスプレイ上に現在レンダリングされているコンテンツ」に相当する。 (ウ)上記(ア),(イ)の検討から,引用発明と本願発明1とは, 「前記クエリに依存しない要求は, ユーザによって入力されたクエリパラメータを含まない要求であり,かつ前記ユーザデバイスのディスプレイ上に現在レンダリングされているコンテンツを含む」点で共通している。ウ(ア)引用発明は,「補足を生成する処理」である「ステップ510」において,「記事のコンテンツ又はメタデータから複数の構成エンティティ(単語)を抽出し」ている。一方,本願発明1の「前記アクティブリソースによって記述されたコンテンツを決定するステップ」とは,本願明細書の段落0051の「【0051】プロセス300は、クエリに依存しない要求に応答して、アクティブリソースによって記述されたコンテンツを決定するステップを含む(320)。たとえば、リソース識別エンジン220は、要求内のスクリーンショットから「サンフランシスコ」というテキストを抽出するか、または、表示されたリソースの少なくとも一部を表す文書オブジェクトモデルから「サンフランシスコ」というテキストを抽出してもよい。」(下線は当審で付した。) との記載を参酌すると,実施例では,「テキストを抽出する処理」であると認められる。そうすると,引用発明の「記事のコンテンツ又はメタデータから複数の構成エンティティ(単語)を抽出」することは,本願発明1の「前記アクティブリソースによって記述されたコンテンツ(テキスト)を決定する」ことに相当する。 (イ)したがって,引用発明と本願発明1とは,“前記クエリに依存しない要求に応答して,前記アクティブリソースによって記述されたコンテンツを決定するステップ”を含む点で共通する。エ(ア)引用発明は,「記事のコンテンツ又はメタデータ」から抽出される「複数の構成エンティティ(単語)」に基づいて,「最終的なエンティティの組を生成し」,「最終的なエンティティの組の各特定のエンティティに関し,この特定のエンティティを検索語として使用して,検索リポジトリに照らしたクエリを実行するものであ」る。そうすると,引用発明の「特定のエンティティを検索語として使用して,検索リポジトリに照らしたクエリを実行」して得られる“複数の”「検索結果」は,本願発明1の「前記アクティブリソースによって記述された前記コンテンツに関連する複数のリソース」に相当する。また,引用発明において,“複数の”「検索結果」を得るために,「特定のエンティティを検索語として使用して,検索リポジトリに照らしたクエリを実行」することは,本願発明1の「前記アクティブリソースによって記述された前記コンテンツに関連する複数のリソースを識別する」ことに相当する。 (イ)したがって,引用発明と本願発明1とは,「前記クエリに依存しない要求に応答して,前記アクティブリソースによって記述された前記コンテンツに関連する複数のリソースを識別するステップ」を含む点で一致する。オ上記エ(ア)の検討から,引用発明の“複数の”「検索結果」が本願発明1の「前記アクティブリソースによって記述された前記コンテンツに関連する複数のリソース」に相当する。そして,引用発明の補足サーバは,「検索結果が関連性閾値を満たさないエンティティをフィルタ除去するために,好適な関連性ランク付けアルゴリズムを使用して,関連性尺度を生成することができ」るものであるから,引用発明の「関連性尺度を生成すること」と本願発明1の「前記複数のリソースの各リソースについて,1人または複数のユーザによる前記リソースの関与を反映するユーザ関与の対応する尺度を決定する」こととは,“尺度を決定”することである点で共通する。また,引用発明の「エンティティに対する各ニュース記事の関連性のカスタマイズした尺度に基づいて検索結果内でニュース記事にランク付け」することは,ランク付けの結果に基づいて上位にランク付けしたニュース記事を“選択する”ことにほかならないから,本願発明1の「前記複数のリソースに対するユーザ関与の前記尺度に基づいて,前記複数のリソースのうちの1つまたは複数を選択する」こととは,“前記尺度に基づいて,前記複数のリソースのうちの1つまたは複数を選択する”ことである点で共通する。したがって,引用発明と本願発明1とは,“尺度を決定するステップ”と,“前記尺度に基づいて,前記複数のリソースのうちの1つまたは複数を選択するステップ”とを含む点で共通する。カ(ア)引用発明の「補足160の区分163」は,「小区分の組171?174を含み,小区分173及び174は,各々が異なる検索結果に対応する複数のリンクを含むものであ」るところ,上記エ(ア)の検討から,引用発明の“複数の”「検索結果」が本願発明1の「前記アクティブリソースによって記述された前記コンテンツに関連する複数のリソース」に相当するものであるから,引用発明の「各々が異なる検索結果に対応する複数のリンク」は,本願発明1の「選択時に前記ユーザデバイスに前記それぞれのリソースを要求させる前記選択された複数のリソースの各々に対するナビゲーションリンク」に相当する。また,引用発明の「補足160」は,クライアントにおいて「ユーザがアクセスしたコンテンツ」とともに「表示」されるものであるから,当該「補足160」に含まれ,「複数のリンクを含む」「小区分173及び174」は,本願発明1の「前記ユーザデバイスに,前記アクティブリソースと共に表示するためのユーザインターフェース要素」であって,「選択時に前記ユーザデバイスに前記それぞれのリソースを要求させる前記選択された複数のリソースの各々に対するナビゲーションリンクを含む」「ユーザインターフェース要素」に相当する。 (イ)引用発明において,「補足サーバは,この補足を補足アプリケーションに戻し」ているところ,この処理が,本願発明1の「前記ユーザデバイスに」,「ユーザインターフェース要素を提供するステップ」に相当する。 (ウ)上記(ア),(イ)の検討から,引用発明と本願発明1とは,「前記ユーザデバイスに,前記アクティブリソースと共に表示するためのユーザインターフェース要素を提供するステップであって,前記ユーザインターフェース要素が,選択時に前記ユーザデバイスに前記それぞれのリソースを要求させる前記選択された複数のリソースの各々に対するナビゲーションリンクを含む,ステップ」を含む点で一致する。キ引用発明の「補足サーバ」は,「記事に基づいて補足を生成」する処理を実行するコンピュータであって,上記ア-カに記載したように,本願発明1の各ステップに対応するデータ処理を実行する装置であるから,本願発明1の「データ処理装置」に相当する。したがって,引用発明と本願発明1とは,「データ処理装置において実施される方法」である点で共通する。したがって,本願発明1と引用発明との間には,次の一致点,相違点があるといえる。 (一致点) 「データ処理装置において実施される方法であって,前記方法が, ユーザデバイスから,前記ユーザデバイス上のアプリケーション環境内に表示されるアクティブリソースに関連する文脈情報に対する,クエリに依存しない要求を受信するステップであって, 前記クエリに依存しない要求は, ユーザによって入力されたクエリパラメータを含まない要求であり,かつ前記ユーザデバイスのディスプレイ上に現在レンダリングされているコンテンツを含む,ステップと, 前記クエリに依存しない要求に応答して,前記アクティブリソースによって記述されたコンテンツを決定するステップと, 前記クエリに依存しない要求に応答して,前記アクティブリソースによって記述された前記コンテンツに関連する複数のリソースを識別するステップと, 尺度を決定するステップと, 前記尺度に基づいて,前記複数のリソースのうちの1つまたは複数を選択するステップと, 前記ユーザデバイスに,前記アクティブリソースと共に表示するためのユーザインターフェース要素を提供するステップであって,前記ユーザインターフェース要素が,選択時に前記ユーザデバイスに前記それぞれのリソースを要求させる前記選択された複数のリソースの各々に対するナビゲーションリンクを含む,ステップとを含む方法。」 (相違点) (相違点1)本願発明1は,「クエリに依存しない要求」が「前記アクティブリソースのスクリーンショット」と,「前記ユーザデバイスのディスプレイ上に現在レンダリングされているコンテンツを定義した文書オブジェクトモデル」とを含むのに対して,引用発明はそのような構成となっていない点。 (相違点2)本願発明1は「前記スクリーンショットおよび前記文書オブジェクトモデルから」,前記アクティブリソースによって記述されたコンテンツを決定するのに対し,引用発明はそのような構成となっていない点。 (相違点3)本願発明1は,「前記複数のリソースの各リソースについて,1人または複数のユーザによる前記リソースの関与を反映するユーザ関与の対応する尺度」を決定し,「前記複数のリソースに対するユーザ関与の前記尺度」に基づいて,前記複数のリソースのうちの1つまたは複数を選択するのに対して,引用発明は,「尺度を決定」し,当該「尺度」に基づいてリソースを選択しているものの,引用発明の「尺度」は,本願発明1で特定されているような「尺度」ではない点。 (2)相違点についての判断事案に鑑み,上記相違点1及び相違点2について検討する。相違点1,2に係る発明の構成である,「アクティブリソースのスクリーンショットをクエリに依存しない要求に含ませてサーバに送信し,サーバにおいて,スクリーンショットから,アクティブリソースによって記述されたコンテンツ(テキスト)を決定する構成」(以下,「構成A」という。)は,引用文献1には,記載も示唆もされておらず,また,当該構成Aが,本願優先日前に当該技術分野における周知技術であったとも認められない。したがって,上記相違点3について判断するまでもなく,本願発明1は,当業者であっても引用発明に基づいて容易に発明できたものであるとはいえない。 2.本願発明2-7,18について本願発明2-7,18は,本願発明1を減縮した発明であり,本願発明1の「構成A」と同一の構成を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明に基づいて容易に発明できたものとはいえない。 3.本願発明8,15について本願発明8,15は,それぞれ本願発明1に対応するシステムの発明,及び非一時的コンピュータ可読記憶媒体の発明であり,本願発明1の「構成A」と同様の構成を備えるものであるから,本願発明1と同様の理由により,当業者であっても,引用発明に基づいて容易に発明できたものとはいえない。 4.本願発明9-14,19について本願発明9-14,19は,本願発明8を減縮した発明であり,本願発明1の「構成A」と同様の構成を備えるものであるから,本願発明1と同様の理由により,当業者であっても,引用発明に基づいて容易に発明できたものとはいえない。 5.本願発明16-17,20について本願発明16-17,20は,本願発明15を減縮した発明であり,本願発明1の「構成A」と同様の構成を備えるものであるから,本願発明1と同様の理由により,当業者であっても,引用発明に基づいて容易に発明できたものとはいえない。第5 原査定の概要及び原査定についての判断原査定は,請求項1-20について上記引用文献1に基づいて,当業者が容易に発明できたものであるから,特許法第29条第2項の規定により特許を受けることができないというものである。しかしながら,令和3年6月23日付け手続補正により補正された請求項1,8,15は,それぞれ上記「構成A」に対応する構成を有するものとなっており,上記のとおり,本願発明1-20は,上記引用文献1に記載された発明に基づいて,当業者が容易に発明できたものではない。したがって,原査定を維持することはできない。第6 当審拒絶理由について＜特許法第36条第6項第2号について＞当審では,請求項1の「前記クエリに依存しない要求に応答して,前記スクリーンショットまたは前記文書オブジェクトモデルから,前記アクティブリソースによって記述されたコンテンツを決定するステップ」との記載では,「クエリに依存しない要求に応答して」,「スクリーンショット」から,「アクティブリソースによって記述されたコンテンツを決定する」のか否かが不明確であるとの拒絶の理由を通知しているが,令和3年6月23日付けの補正において,「前記クエリに依存しない要求に応答して,前記スクリーンショットおよび前記文書オブジェクトモデルから,前記アクティブリソースによって記述されたコンテンツを決定するステップ」と補正された結果,この拒絶の理由は解消した。第7 むすび以上のとおり,本願発明1-20は,当業者が引用発明に基づいて容易に発明をすることができたものではない。したがって,原査定の理由によっては,本願を拒絶することはできない。また,他に本願を拒絶すべき理由を発見しない。よって,結論のとおり審決する。
審決日	2021-08-20
出願番号	特願2018-567072(P2018-567072)
審決分類	P 1 8・ 121- WY (G06F)
最終処分	成立
前審関与審査官	西村直史、▲はま▼中信行
特許庁審判長	篠原功一
特許庁審判官	須田勝巳山崎慎一
発明の名称	文脈情報を提供するためのシステムおよび方法
代理人	実広信哉
代理人	村山靖彦
代理人	阿部達彦

プライバシーポリシーセキュリティーポリシー運営会社概要サービスに関しての問い合わせ