【事件の表示】
　特願２００２−　２９０１９「リソース解決の適応インデクシングおよびリソース・ルックアップのための顧客セルフ・サービス・サブシステム」拒絶査定不服審判事件〔平成１４年１２月１３日出願公開、特開２００２−３５８３２４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　
１．手続の経緯
　この出願（以下、「本願」という。）は、平成１４年２月６日（優先権主張平成１３年２月７日、米国）に出願したものであって、平成１６年９月３日付けで拒絶理由が通知され、これに対して同年１２月７日付けで手続補正がなされたが、平成１７年３月１０日付けで拒絶査定がなされ、これに対して同年４月１４日に拒絶査定不服審判が請求され、同年４月１８日に手続補正がなされたものである。
　
　
２．本願発明
　本願の請求項１〜２５に係る発明は、平成１７年４月１８日付け手続補正で補正された特許請求の範囲の請求項１〜２５に記載されたとおりのものであると認める。
　そして、請求項１に係る発明は、以下のとおりである。
「【請求項１】
　ユーザの照会に応答してリソースの検索および選択を実行する顧客セルフ・サービス・システムであって、
　前記ユーザの照会に関連するリソースを有するリソース・ライブラリと、
　前記ユーザの照会に適応するリソースを要求するために必要な情報であるユーザ照会を受け付けるインターフェースと、
　前記ユーザ照会と前記ユーザ照会に関連したユーザ・コンテキストとを前記ユーザから受信することで生成される対話を含むユーザ・コンテキスト・ベクトルを生成する手段と、
　前記リソース・ライブラリと以前の照会、この照会に対する応答、および、対話、に関するデータを格納するユーザ対話レコードとに基づいて、前記ユーザ照会と前記ユーザ・コンテキスト・ベクトルとを前記リソース・ライブラリに格納されるリソースのサブセットにマッピングし、前記リソースのサブセットを含む応答セットを生成し、前記マッピングする機能を更新するリソース・インデクシング手段と、を含む、顧客セルフ・サービス・システム。」
　
　
３．原査定の理由
　原査定の拒絶の理由の概要は、次のとおりである。
「１．この出願は、明細書及び図面の記載が下記の点で、特許法第３６条第４項及び第６項第２号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　　記
　
＜請求項１〜２５＞
　請求項１〜２５の記載について、全般的に記載内容が不明確であるが、特に以下の用語、文の技術的意味が不明であり、特許請求の係る発明について明確に把握することができない。
（１）「ユーザ・コンテキスト」　
　一般に、ユーザ・コンテキストというとユーザの現在の状態を意味する概念的な用語であり、ユーザ・コンテキストが具体的にどのようなデータにより構成されているか特定されておらず不明確である。
（２）「現行ユーザ照会」
　技術的意味が不明である。
（３）「各ユーザ照会および関連するコンテキスト・ベクトルを前記リソース・ライブラリからのリソースのサブセットにマッピングし、前記ユーザの照会に最も関係するリソースの前記サブセットを含む応答セットを生成する」
　とあるが、技術的意味が不明である。
　
（４）以下の記載が技術的に意味が不明である。
　「ユーザ照会と検索可能リソースとの間のマッピングのためのリソース・インデクシング機能」、「より狭い検索を促進するリソース・パラメータ」、「限定性」、「検索結果の価値」、「照会領域」、「「静的、ヒストリカル・コンテキスト、一時コンテキスト、組織コンテキスト、コミュニティ・コンテキスト、および環境コンテキストの１つまたは複数を含む生コンテキスト情報」」
　
（５）「ユーザ対話レコードのデータベース」とあるが、
　何が、どのように記憶されているのか不明確である。
　
　なお、この出願は、出願内容が著しく不明確であるから、請求項１〜２５に係る発明については、新規性、進歩性等の特許要件についての審査を行っていない」
　
　　
４．当審の判断
　原査定の備考欄では、主に「ユーザ・コンテキスト・ベクトル」の構成、及び、「照会にもっとも関係するリソースのサブセットを含む応答セットを生成する」構成について言及している。これに対して、審判請求人は、平成１７年４月１８日付けの手続補正書で補正された「請求の理由」（以下、「審判請求の理由」という。）の「（３−３）拒絶理由について」の『（３−３−１）「ユーザから与えられた「ユーザ照会」と「ユーザコンテキスト」等のパラメータから、どのようにユーザ・コンテキスト・ベクトルを生成しているのかが特定されていない」について』と『（３−３−２）「「照会にもっとも関係するリソースのサブセットを含む応答セットを生成する」ための構成が特定されていない」について』で意見を述べている。
　これらは、いずれも拒絶理由の１．（３）に関するものと解されるから、これから検討する。
　
（１）拒絶理由の１．（３）について
　拒絶理由の１．（３）で技術的意味が不明であるとして摘記している「各ユーザ照会および関連するコンテキスト・ベクトルを前記リソース・ライブラリからのリソースのサブセットにマッピングし、前記ユーザの照会に最も関係するリソースの前記サブセットを含む応答セットを生成する」との記載は、拒絶理由が通知されたこの出願の願書に最初に添付された明細書における請求項１の「リソース・インデクシング機構」に関する記載である。そして、「リソース・インデクシング機構」は、現在の（以下、省略する。）請求項１における「リソース・インデクシング手段」に対応すると解されるから、上記摘記箇所の記載は、請求項１における「リソース・インデクシング手段」についての、「前記リソース・ライブラリと以前の照会、この照会に対する応答、および、対話、に関するデータを格納するユーザ対話レコードとに基づいて、前記ユーザ照会と前記ユーザ・コンテキスト・ベクトルとを前記リソース・ライブラリに格納されるリソースのサブセットにマッピングし、前記リソースのサブセットを含む応答セットを生成し」との記載に対応するといえる。
　そこで、請求項１の上記記載について検討する。
　
　請求項１の上記記載は、「前記リソース・ライブラリ」と「以前の照会、この照会に対する応答、および、対話、に関するデータを格納するユーザ対話レコード」とに基づいて「ユーザ照会」と「ユーザ・コンテキスト・ベクトル」とを、「リソースのサブセット」に「マッピング」し、「前記リソースのサブセットを含む応答セットを生成」することであると解される。
　以下、各要素について検討する。
　　
（あ）「リソース・ライブラリ」について
　請求項１における「前記リソース・ライブラリ」とは、先行する記載の「前記ユーザの照会に関連するリソースを有するリソース・ライブラリ」を指していると解される。
　
（い）「ユーザ対話レコード」について
　請求項１における「以前の照会、この照会に対する応答、および、対話、に関するデータを格納するユーザ対話レコード」との記載からは、「ユーザ対話レコード」が格納するものは、「以前の照会」、「この照会に対する応答」、「対話」に「関するデータ」であると解される。また、「この照会に対する応答」の「この照会」とは、「以前の照会」を指していると解される。
　しかし「関するデータ」というあいまいな表現がされているため、「ユーザ対話レコード」が格納する具体的データを特定することができない。「ユーザ対話レコード」の内容が明確に把握されないと、「ユーザ対話レコード」に基づいて行われる「マッピング」を明確に把握することができない。
　そこで、発明の詳細な説明の記載を参酌する。
　発明の詳細な説明には、「ユーザ対話レコード」に「格納する」「データ」について、以下の記載がある。
　
（段落００１６）
「【００１６】
　オフライン処理で、適応インデクシング機能が、現在のユーザの、彼らのコンテキストでの検索結果の価値を高めるために適用され、この適応インデクシング機能は、リソースへのユーザ照会のマッピングに関する関連および限定性を増やすことによって、リソース・インデクシング機能を強化する。適応インデクシング処理は、ユーザ対話レコードのデータベースの中からのユーザ対話データとリソース・ライブラリからのリソースとを受け取る教師付き学習アルゴリズムを実施し、ユーザ対話レコードで提供される、システムとのユーザ対話およびユーザ・フィードバックのヒストリに基づいてリソース・インデクシング機能を適応させる。この形で、教師付き学習アルゴリズムが、ユーザ対話フィードバックに適用される評価メトリックによって測定されるリソース・インデクシング機能の性能を最適化する。前のユーザ対話からのフィードバックによって、特定の取出しの成功または失敗に関するデータが供給される（１つの可能な評価メトリックによれば、特定の取出しが成功とみなされるのは、ユーザが、表示されるリソースのリストからその特定のリソースを選択する場合である）。適応インデクシング・アルゴリズムは、成功の取出しの数を最大にするためにインデクシング機能を最適化する。」
　
　段落００１６の記載によれば、「ユーザ対話レコード」で「提供される」ものは「システムとのユーザ対話及びユーザ・フィードバックのヒストリ」であるといえるから、「システムとのユーザ対話及びユーザ・フィードバックのヒストリ」が「ユーザ対話レコード」に格納されていると解される。
　また、「前のユーザ対話からのフィードバックによって、特定の取出しの成功または失敗に関するデータが供給される（１つの可能な評価メトリックによれば、特定の取出しが成功とみなされるのは、ユーザが、表示されるリソースのリストからその特定のリソースを選択する場合である）」との記載から、「システムとのユーザ対話及びユーザ・フィードバックのヒストリ」には、「表示されるリソースのリストからのリソース選択」に関するヒストリが含まれるものと解される。
　
（段落００２２）
「．．．このコンポーネントには、．．．４）ユーザの以前の照会、応答、およびシステム１０との対話が保管されるヒストリカルなユーザ対話レコード・データベース１５などのデータベースが含まれる。最初の３つのデータベースは、システム起動の前に作成され、ユーザ対話レコード・データベース１５は、システムの最初のユーザ／使用と共に作成されるが、４つのデータベースのすべてが、下で説明するシステム動作を介して保守され、強化されることを理解されたい。」
　
　段落００２２の記載によれば、「ユーザ対話レコード・データベース１５」には、「ユーザの以前の照会、応答、およびシステム１０との対話」が保管されるといえる。
　
（段落００３０）
「【００３０】
　第２動作では、適応インデクシング・アルゴリズム２８５が、連続処理または反復処理としての実行のために実施される。このサブプロセスでは、ユーザ対話レコード１９が、適応インデクシング・アルゴリズム２８５がリソース・ライブラリ４２からの関連するリソースの選択についてリソース・インデクシング機能２７に学習させる（継続的に改善する）ためのトレーニング・セットとして働く。具体的に言うと、ユーザ対話レコード１９に、すべてのタイプの生のコンテキスト情報と、それが静的、ヒストリカル、または一時的、組織的コンテキストまたはコミュニティ・コンテキスト、環境コンテキスト、またはユーザに関連し、ユーザの対話状態および、たとえば教育、不動産、旅行などの照会領域に依存する他のコンテキストのどれであるかと、ユーザ照会と、システムの応答と、ユーザ・フィードバックとを含む、システムのユーザとの前の対話のトレースが含まれる。（フィードバックは、たとえば、表示されたリソースのリストに対してユーザが選択または拒絶したリソースの指定とすることができる）。適応インデクシング・アルゴリズム２８５は、ユーザ対話レコード１９内のフィードバックによって測定されるリソース・インデクシング機能２７の性能を最適化する。たとえば、１つの可能な評価メトリックによれば、性能の尺度の１つが、所与の照会／コンテキスト対に対してユーザが最終的に選択したリソースのカバレッジである。この場合には、インデクシング機能は、それが提案する結果セットに、しばしば、ユーザによって選択されるリソースのすべてが含まれる場合に、高い性能を有する。」
　
　段落００３０の記載によれば、「ユーザ対話レコード」には、「すべてのタイプの生のコンテキスト情報」、「それが静的、ヒストリカル、または一時的、組織的コンテキストまたはコミュニティ・コンテキスト、環境コンテキスト、またはユーザに関連し、ユーザの対話状態および、たとえば教育、不動産、旅行などの照会領域に依存する他のコンテキストのどれであるか」、「ユーザ照会と、システムの応答と、ユーザ・フィードバックとを含む、システムのユーザとの前の対話のトレース」が含まれ、「フィードバックは、たとえば、表示されたリソースのリストに対してユーザが選択または拒絶したリソースの指定とすることができる」ことが記載されているといえる。
　
（段落００３９）
「【００３９】
　ユーザが、特に結果表示ワークスペース３３および詳細指定ワークスペース２３を介して、このシステムを扱う時に、そのユーザの対話が、取り込まれ、ユーザ対話レコード・データベース１５に保管される。したがって、ユーザ照会、コンテキスト・ベクトル、および応答データ・セットのほかに、このシステムは、ユーザ・コンテキストに対する調整挙動、結果表示操作挙動、結果表示挙動、および結果選択挙動５１を保存する。」
　
　段落００３９の記載によれば、ユーザが結果表示ワークスペース３３および詳細指定ワークスペースを介して、このシステムを扱うときの対話が、ユーザ対話レコード・データベース１５に取り込まれ、保管されるといえる。
　段落００３９の記載における「ユーザ・コンテキストに対する調整挙動、結果表示操作挙動、結果表示挙動、および結果選択挙動５１」は、「このシステムを扱うときの対話」であると解されるから、要するに、「ユーザ・コンテキストに対する調整挙動、結果表示操作挙動、結果表示挙動、および結果選択挙動５１」がユーザ対話レコードに含まれるものと解される。
　
（段落００４８〜００４９）
「【００４８】
　属性値：属性値選択のリストが、コンテキスト属性ごとに事前に定義される。
【００４９】
　システムは、データ・ルックアップに基づくか、以前のユーザの入力または挙動から感知されたまたはヒストリ的に導出された、デフォルト値を、各属性にセットする。システムまたはユーザのいずれかが、明示的なプリファレンスまたは観察された挙動に基づいて、当初にセットされた値を変更することができる。この値は、リソース・ルックアップに使用されるコンテキスト・ベクトルに追加され、ユーザ対話レコード・データベース１５に保存され、したがって、各個人がシステムを使用するたびに各個人についてデフォルト値をセットするのに使用することができる。」
　
　段落００４９における「この値」は、「属性値」を指すと解される。
　したがって、段落００４８，００４９の記載によれば、コンテキスト属性毎に事前に定義される属性値について、当初にセットされた値、及び、当初にセットされた値を変更したものが、ユーザ対話レコード・データベースに保存されるといえる。
　
　以上のことから、請求項１における「ユーザ対話レコード」とは、これら発明の詳細な説明に記載されたような各種の情報（データ）を格納するレコードであると解される。
　
（う）「ユーザ照会」について
　「リソース・インデクシング手段」において「マッピング」される、「ユーザ照会」がどのようなものであるのか、請求項１には、「ユーザの照会に適応するリソースを要求するために必要な情報である」という記載の他に具体的な記載はない。
　そして、「ユーザ照会」とは、ユーザからの照会という一般的・抽象的な概念であると解されるところ、請求項の記載からは、「ユーザ照会」がどのような情報であるのか特定できない。
　「ユーザ照会」の具体的内容が明確でないと請求項１に係る発明における「ユーザ照会」に対する処理である「マッピング」がどのような処理であるのか明確に把握することができないため、発明の詳細な説明の記載を参酌する。
　「ユーザ照会」の具体的構成に関する記載として、発明の詳細な説明には以下の記載がある。
　
（段落００２３）
「．．．これらの前処理ステップの後に、インターフェース１２が、ユーザの端末または、ウェブベース通信リンクを介してリソース検索が行われる場合にはウェブブラウザに、ユーザのために表示される。コンテキスト選択ワークスペース１３には、当初は、最適と判定されたユーザ・コンテキスト・アイコンの小さい組が表示され、現在のユーザ検索セッションに最適と思われるアイコンのユーザによる選択を取り込み、ユーザの実際の照会を取り込む。ほとんどの場合に、この最小限の入力が、検索を開始するのに十分である。というのは、システムが、すでに、ユーザの側での追加入力を必要とせずにシステムをユーザ検索に前進させるための関係する属性、デフォルト値、およびパラメータを判定しているからである。しかし、ユーザが、デフォルトを再検討することを望むか、あるコンテキストまたはリソース変数の微調整を望む場合には、検索を開始する前にインターフェース２２のアイコン詳細指定ワークスペース表示に進む選択肢がある。」
　
　段落００２３の記載によれば、「インターフェース１２」が表示され、コンテキスト選択ワークスペース１３に「ユーザ・コンテキスト・アイコンの小さい組」が表示され、「現在のユーザ検索セッションに最適と思われるアイコンのユーザによる選択を取り込み、ユーザの実際の照会を取り込む。」とある。
　該記載における、「アイコンのユーザによる選択」は「ユーザ・コンテキスト・アイコン」の選択であることは明らかである。
　しかし、「現在のユーザ検索セッションに最適と思われるアイコンのユーザによる選択を取り込み、ユーザの実際の照会を取り込む。」との記載は、「アイコンのユーザによる選択」を取り込むことと、「ユーザの実際の照会」を取り込むことの相互関係が明確でない。すなわち、「アイコンの選択」と「ユーザの実際の照会」とが、同じものを指しているのか、別のものを指しているのか、段落００２３の記載だけでは、「取り込む」ものについて、「アイコンの選択」と「ユーザの実際の照会」の関係は明確ではない。
　
（段落００５５）
「【００５５】
　最初のログオンで、図２に示されているように、このシステムは、まず、図２のインターフェース１２を介してユーザが使用可能であるユーザ・コンテキストの組を提示する。システムは、他のコンテキストに対して１つのコンテキストを提案するが、ユーザは、自分の現在の情況に最も適するコンテキストを選択することができる。各セッションで、ユーザは、使用するユーザ・コンテキストを１つだけ選択するが、経時的に、各ユーザは、２つの異なるユーザ・コンテキストが異なる状況での自分の必要に役立つことを発見する可能性がある。このコンテキスト選択ワークスペース１３で、具体的に言うと、ユーザが、たとえばウェブ・ブラウザ表示インターフェースを介する、またはたとえば音声認識ソフトウェアの助けを借りて音声を介する、テキストを含む１つまたは複数の方法を介して、照会を入力する。しかし、照会入力が、これらのタイプの方法に制限されないことを理解されたい。．．．」
　
　段落００５５の記載において「照会」は「ユーザ」が入力するものであり、本願明細書中に他の「照会」があるようには記載されていないから、段落００５５及びその他で入力される「照会」と、請求項１における「ユーザー照会」とは同じものを指していると解される。（以後は特に区別しない。）
　そして、段落００５５の記載によれば、照会は「ウェブ・ブラウザ表示インターフェースを介する、またはたとえば音声認識ソフトウェアの助けを借りて音声を介する、テキストを含む１つまたは複数の方法を介して」入力されることが記載されている。「テキストを含む１つまたは複数の方法を介して、照会を入力する」との記載は、「テキスト」が「１つまたは複数の方法」に含まれると解されるから、「照会を入力する方法」の一つとして「テキスト」を入力することが含まれるといえる。
　したがって、「照会」には、少なくとも「ウェブブラウザ表示インターフェース」又は「音声認識ソフトウェア」を介して入力される「テキスト」が含まれていると解される。
　なお、ウェブブラウザを用いて「テキスト」を入力することは、例えばＨＴＭＬにおけるテキスト入力のためのフォームのように周知の方法である。
　また、音声認識ソフトウェアを用いて「テキスト」を入力することは、同じく周知の方法である。
　
（段落００５６）
「【００５６】
　図４に、照会の一部としてユーザ・コンテキストを表現できるようにするコンテキスト選択ワークスペース１３を含むインターフェース１２を詳細に示す。図４からわかるように、コンテキスト選択ワークスペース１３には、ユーザ・コンテキストを選択するためにユーザに提示される一連の１つまたは複数の選択可能なユーザ・コンテキスト・アイコン１３２と、たとえばテキストまたは音声入力を介する、検索単語のユーザ入力を可能にする照会入力フィールド１３１とが含まれる。（後略）」
　
　段落００５６の記載によれば、「照会入力フィールド１３１」に「検索単語」を「テキストまたは音声入力」を介して「ユーザ入力」するといえる。
　「ユーザ入力」とは、ユーザによる入力であると解され、「照会入力フィールド」とは、「照会」を入力するフィールドであると解されるから「照会入力フィールド」に「ユーザ入力」されるものは、「ユーザ照会」であるといえる。
　
（段落００５８〜００５９）
「【００５８】
．．．ユーザは、適当な応答セットを見つけるために必要なだけ何度でもこの画面に戻ることができる。．．．したがって、詳細指定ワークスペース２３によって、ユーザは、１）照会を修正すること（たとえばテキスト入力または音声を介して）と、．．．」
「【００５９】
　図５に、ユーザが照会入力フィールド１３１および（単一の）選択されたユーザ・コンテキスト・アイコン１３２に関連するすべてのパラメータを定義または変更できるようにするインターフェース２２の諸態様を詳細に示す。図５に示されているように、インターフェース２２は、下記のセクションに分割される：前のインターフェース画面（図４）で入力され、編集のために使用可能である照会入力フィールド１３１を表示するセクションと；．．．」
　
　段落００５８及び００５９の記載によれば、「照会入力フィールド１３１」は、編集（修正）可能なフィールドであるといえる。
　
　ここで、「照会入力フィールド１３１」に対応する図４の記号１３１をみると、四角の枠線とその上に「ENTER QUERY HERE:」との記載がある。該「ENTER QUERY HERE:」は、記号１３１の枠線を指していると解され、QUERYは、照会という意味を有することから、「照会入力フィールド１３１」は、図４で示される枠線１３１に照会をユーザが入力するものであるといえる。
　そして、コンピューターの画面インターフェースで、テキストを入力するフィールドを四角の枠線で表示し、そこに任意の文字列の入力・編集をすることはこの出願の出願前において通常行われていることであるから、段落００５６，００５８，００５９及び図４の記載から、本願の実施例において「照会」は、（選択肢から選択するようなものではなく）任意の文字列や文を照会として入力するように構成されるものと解される。
　
（段落００６７〜００７０）
「【００６７】
　教育の領域に関して、ユーザが学習者であり、図３に、教育領域に適用される本発明の実施形態に含まれるアイコン・インターフェース（図２）を介するシステムとの例の対話を示す。図２の３つのアイコン・ワークスペースによって、学習者が、図３の教育（たとえば環境）の列６０に示された例のデータ要素などの例のデータ要素を指定し、次のように結果を表示することができる：第１処理ステップで、学習者が、コンテキスト選択ワークスペース（図４のインターフェース１２）を使用して、「家庭でLotus　 Notesを学習する」として照会６１を指定する。学習者は、コンテキスト・アイコン６２の使用可能な組の中から、たとえばユーザ・コンテキスト「遠隔地のスタッフ」を選択することができる（アイコンの名前が図３で強調表示されている）。．．．」
「【００６８】
　教育領域に関して、ユーザが、「学習者」であるが、図２の３つのアイコン・ワークスペースが、下記のように、学習者が図３の教育（たとえば主題）列７０に示された例のデータ要素などの例のデータ要素を指定でき、結果を表示できるようにする処理を提供する：第１処理ステップで、学習者が、コンテキスト選択ワークスペース（図４のインターフェース１２）を使用して、たとえば「６月までにLinux開発者になる」として照会７１を指定する。学習者は、使用可能なコンテキスト・アイコン７２の中からユーザ・コンテキスト「通勤する技術者」を選択する。．．．」
「【００６９】
　不動産領域に関して、ユーザが不動産交渉者（借り手／買い手）であり、図３に、不動産領域に適用される本発明の実施形態に含まれるアイコン・インターフェース（図２）を介するシステムとの例の対話を示す。図２の３つのアイコン・ワークスペースによって、不動産の借り手または買い手が、次のように、図３の不動産の列８０に示された例のデータ要素などの例のデータ要素を指定でき、結果を見られるようになる：第１処理ステップで、借り手または買い手が、コンテキスト指定ワークスペースを使用して、「８月までに新しい職場の近くで住宅を見つける」として照会８１を指定する。借り手または買い手は、使用可能なコンテキスト・アイコン８２の中から、ユーザ・コンテキスト「引っ越し専門業者」を選択する。．．．」
「【００７０】
　旅行領域に関して、ユーザが旅行者であり、図３に、旅行領域に適用される本発明の実施形態に含まれるアイコン・インターフェース（図２）を介する顧客セルフ・サービス・システムとの例の対話を示す。図２の３つのアイコン・ワークスペースによって、旅行者が、次のように、図３の旅行の列９０に示された例のデータ要素などのデータ要素を指定でき、結果を見られるようになる：第１処理ステップで、旅行者が、コンテキスト選択ワークスペースを使用して、たとえば「バーモントへの６月中の旅行を計画する」などの照会９１を指定する。旅行者は、たとえば、使用可能なユーザ・コンテキスト・アイコン１３２の中から、ユーザ・コンテキスト・アイコン「母子」を選択することができる（アイコンの名前９２が、図３で強調表示されている）。．．．」
　
　段落００６７〜００７０の「照会」についての記載によれば、各種ユーザーが「照会」として、それぞれの「第１処理ステップ」で、「家庭でLotus　 Notesを学習する」、「６月までにLinux開発者になる」、「８月までに新しい職場の近くで住宅を見つける」、「バーモントへの６月中の旅行を計画する」という照会を指定することが記載されている。
　これらの「照会」は、図３における「ユーザ照会」の行に示されるから、これらの「照会」は「ユーザ照会」として入力されていることは明らかである。
　また、段落００６７〜００７０には、それとは別に、ユーザ・コンテキスト・アイコン（コンテキスト・アイコン）を選択する旨の記載があり、図４を参照すると、ユーザーコンテキストのアイコン１３２が示されていること、段落００６７〜００７０で「ユーザ・コンテキスト・アイコン」として選択される、「遠隔地のスタッフ」、「通勤する技術者」、「引っ越し専門業者」、「母子」が、いずれも図３における「ユーザ・コンテキスト」の行に含まれる要素であることから、「ユーザ・コンテキスト・アイコン」として表示され、選択されるものは、図３における「ユーザ・コンテキスト」であると解される。
　
　これらの段落００６７〜００７０の記載と、段落００５５，００５６，００５８，００５９の「照会入力フィールド１３１」についての記載から、上記記載の「第１処理ステップ」で入力されるそれぞれの照会６１，７１，８１，９１は、（アイコンの選択ではなく）テキストまたは音声を介して「照会入力フィールド１３１」に入力されると解するほかない。
　そして、検索の分野において、テキストを入力するフィールドに任意の文や単語を検索キーとして入力することは、通常行われることであるから、入力される「照会」は、図３の「ユーザ照会」の行で示されるような文として入力されると解される。
　また、テキスト入力フィールドに対する入力は、通常、ユーザーが自由に（任意の）文章や単語を入力するものであるところ、本願実施例においても、「ユーザ照会」が予め定義され保存されている旨の記載はないため、ユーザが自由に入力するものと解される。
　なお、段落００５５には「しかし、照会入力が、これらのタイプの方法に制限されないことを理解されたい。」と記載されているものの、他の方法については具体的な記載はない。
　
　以上のことから、請求項１における「ユーザ照会」は、予め定義されたものではない（任意の）文として入力されるテキストデータを少なくとも含むといえる。
　
　なお、審判請求人は、審判請求の理由の『（３−３−１）「ユーザから与えられた「ユーザ照会」と「ユーザコンテキスト」等のパラメータから、どのようにユーザ・コンテキスト・ベクトルを生成しているのかが特定されていない」について』において、「ユーザ照会」に関し以下のように述べている。
「本願発明では、まず、ユーザは、ユーザ照会を受け付けるインターフェースを通じて、ユーザ照会を入力します。ユーザ照会を入力する例として、インターフェース上に提示されるユーザ・コンテキスト・アイコンのうち、照会したいアイコンをユーザが選択する場合が挙げられます。また、例えば、照会入力フィールドから検索単語を、ユーザ自身が入力する場合が挙げられます（[００５６]〜[００５７]、図４）。
　次に、ユーザは、ユーザ照会に関連したユーザ・コンテキストを入力します。ユーザ・コンテキストを入力する例として、ユーザ・コンテキストに関連する属性を変更することが挙げられます。また、包含／排他のような値リソース・パラメータを変更することが挙げられます。さらに、チェックボックスまたは数値入力もしくはその両方を使用することで、判断基準の重みづけなど、リソース選択判断基準を変更することによって応答のサブセットをカスタマイズすることが挙げられます。また、リソース判断基準の最大／最小許容可能範囲を指定することが挙げられます。（[００５８]、図５）。
　以上の２つの入力、すなわち、ユーザ照会の入力と、ユーザ・コンテキストの入力と、を行うことにより、ユーザ・コンテキスト・ベクトルが生成されます。
　ここで、より具体的な例として、学習者が教育の領域に関する内容を照会したい場合について説明します。まず、学習者は、インターフェース上に提示されるユーザ・コンテキスト・アイコンのうち、アイコン「家庭でLotus　Notesを学習する」を入力します。その後、学習者は、インターフェースを介して、ユーザ・コンテキスト「遠隔地のスタッフ」と、コンテキスト属性「接続性」と、属性値「ＤＳＬ」と、コスト、時間、品質、リスクなどの順序付け、重み付け、その最小値および最大値と、を入力します。これらにより、ユーザ・コンテキスト・ベクトルが生成されます（[００６７]、図５）。このユーザ・コンテキスト・ベクトルが生成されるのは、学習者が教育の領域に関する内容を照会したい場合に限られず、例えば、不動産交渉者が不動産の領域に関する内容を照会したい場合や、旅行者が旅行の領域を照会したい場合など、他の場合にも応用できます（[００６９]、[００７０]）。」
　しかし、この主張は「ユーザ照会」に「ユーザ・コンテキスト」の入力が包含されるように記載されている点、および、「家庭でLotus　Notesを学習する」という「ユーザ照会」の入力が「ユーザ・コンテキスト・アイコン」の選択で行われるように記載されている点で、明細書の記載と矛盾しており、発明の詳細な説明の記載に基づく主張とはいえないから、採用できない。
　
（え）「ユーザ・コンテキスト・ベクトル」及び「ユーザ・コンテキスト・ベクトルを生成する手段」について
　請求項１には、「リソース・インデクシング手段」での記載の他に「ユーザ・コンテキスト・ベクトル」に関連する記載として「前記ユーザ照会と前記ユーザ照会に関連したユーザ・コンテキストとを前記ユーザから受信することで生成される対話を含むユーザ・コンテキスト・ベクトルを生成する手段」との先行する記載がある。
　したがって、「ユーザ・コンテキスト・ベクトル」は、該「生成する手段」によって生成されるものであると解される。
　また、「ユーザ・コンテキスト・ベクトル」は、「前記ユーザ照会と前記ユーザ照会に関連したユーザ・コンテキストとを前記ユーザから受信することで生成される対話」を含むものと解される。
　しかし、「前記ユーザ照会と前記ユーザ照会に関連したユーザ・コンテキストとを前記ユーザから受信することで生成される対話」との記載は、どのような「対話」がどうやって生成され、どのように「ベクトル」に含まれるのか、明確でない。特に、「受信することで生成される対話」の「受信すること」と「生成される」との関係が明確でない。
　一方、「ユーザ・コンテキスト・ベクトル」という語について、「ユーザ・コンテキスト」とあるから、「ユーザ・コンテキスト」に関するなんらかの情報であると解釈可能であり、同様に、「ベクトル」とあるから、なんらかのベクトル（ベクトル量）であると解釈可能であるものの、いずれの語も検索分野において種々の意味で用いられており、特定の概念を表す技術用語とはいえないので、それらを連結した「ユーザ・コンテキスト・ベクトル」が用語としてそれ自体明確であるとはいえない。
　してみれば、請求項１の上記「生成する手段」についての記載が明確でないため、「ユーザ・コンテキスト・ベクトル」がどのような情報をどのように「含む」のかは、明確に把握できない。また、「ユーザ・コンテキスト・ベクトル」が、何から、どのような情報の処理・加工によって生成されるのかは、上記請求項１の「生成する手段」についての記載からは明確に把握できない。
　「ユーザ・コンテキスト・ベクトル」の具体的内容が明確でないと請求項１に係る発明における「ユーザ・コンテキスト・ベクトル」を「マッピング」する処理がどのような処理であるのかを明確に把握することができない。そのため、「ユーザ・コンテキスト・ベクトル」について発明の詳細な説明の記載を参酌する。
　「ユーザ・コンテキスト・ベクトル」について、発明の詳細な説明には以下の記載がある。
　
（段落００２３）
「【００２３】
　まず、ユーザがシステムにサイン・オンする前で、ユーザが初めてインターフェース１２を見る前に、システム１０は、１）空の「ユーザ・コンテキスト・ベクトル」２５を作成し、このコンテキスト・ベクトルに、システムに統合された外部ユーザ・データ１１からまたはシステム感知／ディスカバリから、最小限の情報を取り込むステップと、２）コンテキスト分類論理を使用して、コンテキスト属性マスタ・データベース１４、属性値機能データベース１６、およびユーザ対話レコード・データベース１５に対して最小限のユーザ・コンテキスト・ベクトル２５を処理して、この特定のユーザを、コンテキスト定義のシステムの事前定義の長いリストからの少数のユーザ・コンテキスト定義の１つに分類できる「提案」をもたらすステップとを含む複数の前処理ステップを実行する。．．．」
　
　段落００２３の記載によれば、ユーザがシステムにサイン・オンする前に、空の「ユーザー・コンテキスト・ベクトル」を作成すること、また、「システムに統合された外部ユーザ・データ１１」から、又は、「システム感知／ディスカバリ」から「この（空の）コンテキスト・ベクトル（ユーザー・コンテキスト・ベクトル）に最小限の情報を取り込む」こと、が記載されていると解される。
　しかし、「最小限の情報」とは何であるのか、発明の詳細な説明にはなんら記載されていない。
　また、取り込む情報源の一つである、「外部ユーザ・データ１１」について発明の詳細な説明にはの具体的記載はない。したがって、「外部ユーザ・データ１１」からの「最小限の情報」が何であるのかは、明確でない。
　同じく取り込む情報源の一つである、「システム感知／ディスカバリ」は、発明の詳細な説明には他に記載がない。段落００２８の「コンテキスト・クラスタ・ディスカバリ」のことであると仮定しても、具体的にディスカバリの結果（出力）がどのようなもので、そのうちの何が「最小限の情報」なのかは、なんら記載されていない。
　したがって、段落００２３の記載からは、「ユーザ・コンテキスト・ベクトル」が、どのような情報であるのかは、明確に把握することができない。
　また、段落００２３の「ユーザ・コンテキスト・ベクトル」についての記載と、請求項１における「前記ユーザ照会と前記ユーザ照会に関連したユーザ・コンテキストとを前記ユーザから受信することで生成される対話を含む」との関係は明確でない。
　
（段落００２４）
「【００２４】
　選択された画面ナビゲーション・パスに無関係に、ユーザが照会を開始する時に、システム１０は、詳細なユーザ・コンテキスト・ベクトル２５と共にユーザ照会をパッケージ化して、この時点でのユーザの必要についてわかっていることを要約する。検索を開始した後に、照会およびコンテキスト・ベクトルが、３つの別個のサブプロセスすなわち、１）ユーザ・コンテキスト分類サブプロセス２４、２）本発明によるリソース解決の適応インデクシングおよびリソース・ルックアップ・サブプロセス２８、および３）応答セット順序付けおよび注釈サブプロセス３４を介して順次処理される。」
　
　段落００２４の第１文の記載は、「詳細なユーザ・コンテキスト・ベクトル２５と共にユーザ照会をパッケージ化して、この時点でのユーザの必要についてわかっていることを要約する」とあり、「パッケージ化し」と「要約する」との相互関係が明確でないが、「パッケージ化し」と「要約する」のいずれについても、その具体的な情報処理の内容はなんら記載されていない。したがって、「ユーザ・コンテキスト・ベクトル」がどのような情報であるのか、また、どのような情報の処理加工がされるものであるのかは明確ではない。
　段落００２４の第２文は、３つのサブプロセスで順次処理されるということを明示しているものであり、「ユーザ・コンテキスト・ベクトル」に対する具体的な処理の内容はなんら記載されていない。
　したがって、段落００２４の記載からは、「ユーザ・コンテキスト・ベクトル」が、どのような情報であるのか、また、どのようにして「生成」されるものであるかは、特定することができない。
　
（段落００２５）
「【００２５】
　具体的に言うと、ユーザ・コンテキスト分類サブプロセス２４は、入力として、ユーザ照会、生のユーザ・コンテキスト・ベクトル２５、および外部ユーザ・データ１１を受け取り、これらをこのユーザ／ユーザ・グループのユーザ対話レコード１９と、コンテキスト属性マスタ・データベース１４および属性値機能データベース１６からのデータに対して処理する。システムは、この指定されたユーザの対話状態を分類し、後続処理で使用するためのコンテキスト・パラメータの完全な組を用いてコンテキスト・ベクトル２５’に注釈を付ける。ユーザ・コンテキスト分類サブプロセス２４は、特に、導出されるコンテキストを予測する試みとして、帰納学習アルゴリズムを適用する。さらに、ユーザ・コンテキスト分類サブプロセス２４は、より強化された機能を用いて属性値機能データベース１６を更新する。」
　
　段落００２５は、段落００２４で挙げられた３つのサブプロセスの一つである、「ユーザ・コンテキスト分類サブプロセス２４」についての記載である。
　段落００２５の第１文は、「ユーザ・コンテキスト分類サブプロセス２４」について、「入力として、ユーザ照会、生のユーザ・コンテキスト・ベクトル２５、および外部ユーザ・データ１１を受け取り」という処理の入力の特定、「これらを〜に対して処理する」という、処理の対象の特定がなされているが、「処理する」との記載が具体的にどのような内容の処理をするのかは記載されていない。
　段落００２５の第２文は、「この指定されたユーザの対話状態を分類」すること、及び、「後続処理で使用するためのコンテキスト・パラメータの完全な組を用いてコンテキスト・ベクトル２５’に注釈を付ける」ことを該サブプロセスが行うことが記載されていると解されるが、この２つの処理の相互関係は特定されていない点、「コンテキストベクトル２５’に注釈をつける」という処理が、具体的にどのような情報の処理加工によって行われ、どのような処理の結果が得られるのかなんら特定されていない点、及び、「コンテキスト・パラメータの完全な組」という用語は、明細書中この文でのみ用いられており、「コンテキスト・パラメータ」及び「完全な組」とは何であるのか、なんら特定されていない点で、この第２文は全体としてその内容が明確でない。
　段落００２５の第３文「ユーザ・コンテキスト分類サブプロセス２４は、特に、導出されるコンテキストを予測する試みとして、帰納学習アルゴリズムを適用する。」との記載は、「ユーザ・コンテキスト分類サブプロセス２４」で用いられるアルゴリズムが「帰納学習アルゴリズム」であることを特定していると解される。
　しかし、「特に、導出されるコンテキストを予測する試みとして」との記載は、「特に」、「試み」との記載が何を意味するのか、また、「導出される」と「予測する」という２つの動作が記載されているが、「予測」の結果が「導出されるコンテキスト」であるのか、あるいは、「導出されるコンテキスト」を導出することとは別に「導出されるコンテキスト」を「予測する」ことを行うのか、記載の内容が明確でない。
　また、「帰納学習アルゴリズムを適用する」との記載について、アルゴリズムを挙げるだけでは列挙された一連の情報に対しどのような情報の処理・加工を行い、どのような結果が得られるのか特定できないから、この記載をもって、具体的な情報の処理加工が特定されているとはいえない。
　
　以上のとおり、段落００２５の記載は、「ユーザー・コンテキスト・ベクトル」についての具体的な構成ないし「ユーザ・コンテキスト・ベクトル」に対する具体的な情報の処理・加工を特定できるように記載されていないから、段落００２５の記載からは「ユーザ・コンテキスト・ベクトル」が、どのような情報であるのか把握することができない。
　
　なお、段落００２５における「導出されるコンテキスト」とは、「ユーザ・コンテキスト」を指すと解されるが、該「ユーザ・コンテキスト」についての、拒絶理由の１．（１）「一般に、ユーザ・コンテキストというとユーザの現在の状態を意味する概念的な用語であり、ユーザ・コンテキストが具体的にどのようなデータにより構成されているか特定されておらず不明確である。」に対する応答である、平成１６年１２月７日付け意見書では、「ユーザ・コンテキスト」について、以下のように主張している。
「（４−１）
　（１）「ユーザ・コンテキスト」について
　ユーザ・コンテキストは、予め定義した検索項目のデータで構成されています。このユーザ・コンテキストは、人間のグループの検索挙動／必要に関係するコンテキスト属性の事前定義の組を表しています（[００４４]）。すなわち、ユーザ・コンテキストは、予め、人の検索の仕方などに基づいてグループ化した項目のことであります。この項目は、複数の属性（コンテキスト属性）を有します。そして、具体的には、図３に示す、６２、７２、８２、９２などの内容であります。」
　この意見書における主張は、「ユーザ・コンテキスト」が、予め定義された項目であると主張するものであるから、段落００２５の「帰納学習アルゴリズム」によって「導出される」、あるいは、「予測」される構成とは対応しない。
　また、審判請求の理由の（３−３−１）では、「ユーザ・コンテキスト」について、以下のように主張している。
「次に、ユーザは、ユーザ照会に関連したユーザ・コンテキストを入力します。ユーザ・コンテキストを入力する例として、ユーザ・コンテキストに関連する属性を変更することが挙げられます。また、包含／排他のような値リソース・パラメータを変更することが挙げられます。さらに、チェックボックスまたは数値入力もしくはその両方を使用することで、判断基準の重みづけなど、リソース選択判断基準を変更することによって応答のサブセットをカスタマイズすることが挙げられます。また、リソース判断基準の最大／最小許容可能範囲を指定することが挙げられます。（[００５８]、図５）。」
　この審判請求の理由での主張は、「ユーザ・コンテキスト」は入力されるものであるというものであるから、段落００２５の「帰納学習アルゴリズム」によって「導出される」、あるいは、「予測」される構成とは対応しない。
　以上のとおり、これらの意見書、及び、審判請求の理由における主張は、明細書の段落００２５の「導出」あるいは「予測」される、「コンテキスト」に関する記載と対応しておらず、これらの主張をもって段落００２５の「コンテキスト」の内容が明確であるとはいえない。
　
（段落００２７）
「【００２７】
　リソース解決の適応インデクシングおよびリソース・ルックアップ・サブプロセス２８は、入力として、ユーザ照会およびコンテキスト・ベクトル２５’を受け取り、リソース・ライブラリ４２、このユーザ／ユーザ・グループに関するユーザ対話レコード１９、およびリソース・インデクシング機能２７に対してこれらを処理する。．．．」
　
　段落００２７は、「リソース解決の適応インデクシングおよびリソース・ルックアップ・サブプロセス２８」についての記載であり、該プロセスが入力として「ユーザ照会およびコンテキスト・ベクトル２５’」を受け取るといえる。
　しかし、該サブプロセスにおける「ユーザ・コンテキスト・ベクトル」の「処理」についての記載は明確でなく、また、「ユーザ・コンテキスト・ベクトル」がどのような情報を有するのかは記載されていない。
　
（段落００３４）
「【００３４】
　第３動作では、リソース・ルックアップ・サブプロセス２８８が、ユーザが照会を開始するか洗練する時に、必ず対話式に実行される。この際に、ユーザ照会と、ユーザ・コンテキスト分類サブプロセス２４で展開されるコンテキスト・ベクトル２５’の両方が、インスタンス化されたリソース・インデクシング機能２７に対してリソース・ルックアップ・サブプロセス２８８によって処理される。リソース・マップを使用して、リソース・ライブラリ４２からユーザの照会に関連するリソースのサブセットを選択し、リソース応答セット３５を作成する。具体的に言うと、リソース・ルックアップ・サブプロセス２８８は、すべてのリソースにスコアを付け、応答セットを生成することによってリソースのサブセットを計算する機能を実施する。各応答は、関連する異なる属性（コストなど）を有する。入力のコンテキスト・ベクトル２５’は、たとえばコスト、専門レベルなどについてどの属性が関連するかと、その値を示す。入力のユーザ照会項目が、さらに、リソース・ルックアップ・サブプロセス２８８によって出力されるリソース応答セット３５のリソースと突き合わされる。コンテキスト・ベクトルに基づく突合せだけでは不十分なので、選択されたリソースは、コストおよび専門レベルの観点から正しい。」
　
　段落００３４は、段落００２８において「リソース・ルックアップ・サブプロセス２８」に含まれるとされる３つの非同期動作のうちの一つである、第３動作についての記載である。
　段落００３４の第２文「この際に、ユーザ照会と、ユーザ・コンテキスト分類サブプロセス２４で展開されるコンテキスト・ベクトル２５’の両方が、インスタンス化されたリソース・インデクシング機能２７に対してリソース・ルックアップ・サブプロセス２８８によって処理される。」は、「インスタンス化されたリソース・インデクシング機能２７に対して」との記載が明確ではないが、少なくとも、「ユーザ照会と、ユーザ・コンテキスト分類サブプロセス２４で展開されるコンテキスト・ベクトル２５’の両方」が、「リソース・ルックアップ・サブプロセス２８８によって処理される。」ものであると解されるから、「ユーザ・コンテキスト分類サブプロセス２４で展開されるユーザ・コンテキスト・ベクトル２５’」は、リソース・ルックアップ・サブプロセスの第３動作の入力であるといえる。
　また、段落００３４の第６文には、「入力のコンテキスト・ベクトル２５’は、たとえばコスト、専門レベルなどについてどの属性が関連するかと、その値を示す。」との記載がある。この第６文の記載における「属性」について、段落００３４の第５文に「各応答は、関連する異なる属性（コストなど）を有する。」との記載があることから、「コスト」が「属性」の例として挙げられていると解される。
　そこで、第６文に戻ると、「たとえばコスト、専門レベルなどについてどの属性が関連するか」との記載は、「どの属性が関連するか」の「属性」の例示として「たとえばコスト、専門レベルなど」が挙げられていると解される。しかし、「どの属性が関連するか」ということについて、「その値を示す」ということの「値」（スカラー量と解釈可能である。）が、「ベクトル」とどう関係するのか（どのようにベクトルとして表現されるのか）、また、「関連する」とあるが、何に関連するのか、いずれも明確でない。
　また、段落００３４で「ユーザ・コンテキスト分類サブプロセス２４で展開されるコンテキスト・ベクトル２５’」との記載がされており、「コンテキスト・ベクトル」について、サブプロセス２４で「展開される」という情報の処理・加工を受けていると解されるから、「ユーザ照会およびユーザ・コンテキスト・ベクトル２５」と「ユーザ照会およびユーザ・コンテキスト・ベクトル２５’」とでは「ユーザ・コンテキスト・ベクトル」が異なる（内容あるいはデータ構造が変わっている）と解される。しかし、どのように「展開される」のかなんら具体的な記載がないことから、「ユーザ・コンテキスト分類サブプロセス２４で展開されるコンテキスト・ベクトル２５’」がどのようなものであるのか、記載の内容が明確でない。
　
　したがって、段落００３４の記載からは、「ユーザ・コンテキスト・ベクトル」が、どのような情報であるのかは、特定することができない。
　
（段落００３７）
「【００３７】
　図１に戻って、応答セット順序付けおよび注釈サブプロセス３４は、入力として、ユーザ・コンテキスト・ベクトルとリソース応答セット３５を受け取り、注釈スコアリング・メトリック４６および特定のユーザ／グループに関するユーザ対話レコード１９からのデータに対してこれを処理する。．．．」
　
　段落００３７の記載は、「応答セット順序付けおよび注釈サブプロセス３４」の入力として「ユーザ・コンテキスト・ベクトルとリソース応答セット３５」を受け取ることが記載されているのみであり、段落００３７の記載からは、「ユーザ・コンテキスト・ベクトル」が、どのような情報であるのかは、特定することができない。
　
（段落００４８〜００４９）
「【００４８】
　属性値：属性値選択のリストが、コンテキスト属性ごとに事前に定義される。
【００４９】
　システムは、データ・ルックアップに基づくか、以前のユーザの入力または挙動から感知されたまたはヒストリ的に導出された、デフォルト値を、各属性にセットする。システムまたはユーザのいずれかが、明示的なプリファレンスまたは観察された挙動に基づいて、当初にセットされた値を変更することができる。この値は、リソース・ルックアップに使用されるコンテキスト・ベクトルに追加され、ユーザ対話レコード・データベース１５に保存され、したがって、各個人がシステムを使用するたびに各個人についてデフォルト値をセットするのに使用することができる。」
　
　段落００４９における「この値」は、「属性値」を指すと解される。
　また、「リソース・ルックアップに使用されるコンテキスト・ベクトル」とは、「ユーザ・コンテキスト・ベクトル」であると解される。
　したがって、段落００４８，００４９の記載によれば、コンテキスト属性毎に事前に定義される属性値について、当初にセットされた値、及び、当初にセットされた値を変更したものが、「ユーザ・コンテキスト・ベクトル」に追加されるといえる。
　しかし、「属性値」が、どのような情報であるのか、また、事前にセットされた値や変更したものが、どのように「ユーザ・コンテキスト・ベクトル」に追加されるのかは記載されていない。
　
（段落００７１）
「【００７１】
　図１に戻って、顧客セルフ・サービス・システムによって、ユーザ・コンテキストおよびシステムとの前の対話の組合せから導出されるｎ次元のコンテキスト・ベクトル２５’が実施されて、特定のコンテキストが特定のリソースにマッピングされる。．．．」
　
　段落００７１の記載は、「．．．コンテキストベクトル２５’が実施されて」との記載の意味が明確でないが、「コンテキスト・ベクトル２５’」は、「ｎ次元（のベクトル）」であり、「ユーザ・コンテキストおよびシステムとの前の対話の組合せから導出される」ものであると解される。
　しかし、「ｎ次元」のｎはどのような値であるのかなんら記載がなく、また、「コンテキストベクトル２５’」がどうやって「導出される」のか、処理の具体的内容についても記載されていない。
　
（図面の図１）
　図１には、「ユーザ・コンテキスト・ベクトル」に関する記載として、以下の３カ所の記載がある。
（ａ）「第１アイコン・インターフェース：コンテキスト選択ワークスペース１２（１２は図中の対応する符号、以下同様）」及び「第２アイコン・インターフェース：詳細指定ワークスペース２２」のそれぞれから「サブプロセス：ユーザ・コンテキスト分類２４」へ向かう２本の矢印に「ユーザ照会およびユーザ・コンテキスト・ベクトル２５」と記載されている。
（ｂ）「サブプロセス：ユーザ・コンテキスト分類２４」から「サブプロセス：リソース解決の適応インデクシングおよびリソース・ルックアップ２８」へ向かう矢印に「ユーザ照会およびユーザ・コンテキスト・ベクトル２５’」と記載されている。
（ｃ）「サブプロセス：リソース解決の適応インデクシングおよびリソース・ルックアップ２８」から「サブプロセス：応答セット順序付けおよび注釈３４」へ向かう矢印に「ユーザ・コンテキスト・ベクトルおよびリソース応答セット３５」と記載されている。
　
　符号２５，２５’，３５は、それぞれ「ユーザ・コンテキスト・ベクトル」と他のデータに対して付されていると解されるから、上記（ａ）、（ｂ）、（ｃ）における「ユーザ・コンテキスト・ベクトル」が同じものか異なるものかは図１の記載からは特定できない。
　また、「ユーザ・コンテキスト・ベクトル」の生成に関し、矢印の記載からは、少なくとも、「第１アイコン・インターフェース」および「第２アイコン・インターフェース」が、それぞれ「ユーザ・コンテキスト・ベクトル」を生成していると解される。
　
　これらの発明の詳細な説明及び図面の記載から、「ユーザ・コンテキスト・ベクトル」について、発明の詳細な説明及び図面には以下のことが記載されているといえる。
（１）ユーザがシステムにサイン・オンする前に、空の「ユーザー・コンテキスト・ベクトル」を作製すること、また、「システムに統合された外部ユーザ・データ１１」、又は、「システム感知／ディスカバリ」から「この（空の）コンテキスト・ベクトル（ユーザー・コンテキスト・ベクトル）に最小限の情報を取り込む」こと
（２）少なくとも「第１アイコン・インターフェース」および「第２アイコン・インターフェース」で「ユーザ・コンテキスト・ベクトル２５」として生成され、サブプロセス２４で「展開」され、「ユーザ・コンテキスト・ベクトル２５’」になること
（３）コンテキスト・ベクトル２５’は、たとえばコスト、専門レベルなどについてどの属性が関連するかと、その値を示すこと
（４）コンテキスト属性毎に事前に定義される属性値について、当初にセットされた値、及び、当初にセットされた値を変更したものが、「ユーザ・コンテキスト・ベクトル」に追加されること
（５）コンテキスト・ベクトル２５’は「ｎ次元（のベクトル）」であり、「ユーザ・コンテキストおよびシステムとの前の対話の組合せから導出される」こと
　
　しかし、これらの発明の詳細な説明及び図面からは、「ユーザ・コンテキスト・ベクトル」がどのような情報（データ）により構成され、どのような具体的な情報の処理加工が行われるのか、当業者が理解し実施できる程度に記載されているとはいえない。
　
　してみると、請求項１における「前記ユーザ照会と前記ユーザ照会に関連したユーザ・コンテキストとを前記ユーザから受信することで生成される対話を含むユーザ・コンテキスト・ベクトル」について、発明の詳細な説明には、当業者が請求項１に係る発明を理解し実施できる程度に明確かつ十分に記載されているとはいえない。
　
　また、どのようにして「ユーザ・コンテキスト・ベクトル」を生成するのか、発明の詳細な説明の記載は明確ではないから、請求項１における「ユーザ・コンテキスト・ベクトルを生成する手段」について、発明の詳細な説明には、当業者が請求項１に係る発明を理解し実施できる程度に明確かつ十分に記載されているとはいえない。
　
　以上のとおり、請求項１における「ユーザ・コンテキスト・ベクトル」、及び、「ユーザ・コンテキスト・ベクトルを生成する手段」は、それ自体明確ではなく、また、「ユーザ・コンテキスト・ベクトル」、及び、「ユーザ・コンテキスト・ベクトルを生成する手段」についての発明の詳細な説明が明確かつ十分ではないため、発明の詳細な説明の記載を参酌しても、明確に把握できるとはいえない。
　
（お）「リソースのサブセット」について
　「リソースのサブセット」とは、「リソース」の部分集合であると解される。検索の結果として部分集合を生成することは一般的に行われていることである。
　しかし、以下の（か）で述べるように本願の請求項１に係る発明における「マッピング」がどのような情報処理であるのか明確でないため、「リソースのサブセットにマッピング」したものである請求項１における「リソースのサブセット」がどのようなものであるのかは、明確に把握できない。
　
（か）「マッピング」について
　「マッピング」についての請求項１における記載は、「前記リソース・ライブラリと以前の照会、この照会に対する応答、および、対話、に関するデータを格納するユーザ対話レコードとに基づいて、前記ユーザ照会と前記ユーザ・コンテキスト・ベクトルとを前記リソース・ライブラリに格納されるリソースのサブセットにマッピングし．．」という記載があるものの、処理に用いられるデータが特定されているのみで、「マッピング」がいかなる処理であるか請求項には記載されていない。
　一方、情報処理において「マッピング」という用語は、要素間の対応付けを特にテーブル・表（マップ）を用いて行うことや、要素を平面座標上や空間座標上へ配置（対応付け）することを指すのに用いられている広汎な概念を示す用語である。
　そして、本願の請求項１の記載における「マッピング」についての記載は、上記のとおり、処理に用いられるデータが特定されているのみであり、また、各データについての記載は上記のとおり明確ではないので、データが特定されることで処理が特定されるともいえないため、「マッピングし」との処理が具体的にどのような情報処理を行うものであるのか把握することができない。そのため、発明の詳細な説明を参酌する。
　発明の詳細な説明には、「マッピング」に関する記載として、以下の記載がある。
　
（段落００２２）
「【００２２】
　図１に戻ると、好ましい実施形態による顧客セルフ・サービス・リソース検索選択システムであるシステム１０の概念的な制御フローが示されている。３部分の直観的なグラフィカル・ユーザ・インターフェース（ＧＵＩ）を介して、ユーザが、照会を入力でき、ユーザのリソースの必要に従ってシステムの応答を操作できるようになる。その背後には、これから説明するように、最小限のユーザの労力で特定のユーザ・コンテキストを導出、仮定、感知、および推論するように協力するサブシステム・コンポーネントの組がある。このコンポーネントには、１）システムに既知のすべての属性の定義と、事前定義のユーザ・コンテキストに対するそれらの関係とが保管されるコンテキスト属性マスタ・データベース１４と、２）特定のインスタンス（コンテキスト・デフォルト、ユーザのグループ）の属性への値の割当に関連する定義および論理が保管される属性値機能データベース１６と、３）特定のコンテキスト・セットへの特定のリソースのマッピングのための定義および論理が格納されるリソース・インデクシング機能データベース１８と、４）ユーザの以前の照会、応答、およびシステム１０との対話が保管されるヒストリカルなユーザ対話レコード・データベース１５などのデータベースが含まれる。最初の３つのデータベースは、システム起動の前に作成され、ユーザ対話レコード・データベース１５は、システムの最初のユーザ／使用と共に作成されるが、４つのデータベースのすべてが、下で説明するシステム動作を介して保守され、強化されることを理解されたい。」
　
　段落００２２における「３）特定のコンテキスト・セットへの特定のリソースのマッピングのための定義および論理が格納されるリソース・インデクシング機能データベース１８」との記載からは、「リソース・インデクシング機能データベース１８」は、「特定のコンテキスト・セットへの特定のリソースのマッピングのための定義および論理が格納される」ものであることが記載されているといえる。
　一方、該段落００２２の記載は、「リソースのマッピング」が「特定のリソース」の「特定のコンテキスト・セット」へのマッピングであるように記載されており、請求項１における「ユーザ照会」と「ユーザコンテキストベクトル」とを「リソースのサブセット」にマッピングすることとの対応関係が明確でない。
　
（段落００２７）
「【００２７】
　リソース解決の適応インデクシングおよびリソース・ルックアップ・サブプロセス２８は、入力として、ユーザ照会およびコンテキスト・ベクトル２５’を受け取り、リソース・ライブラリ４２、このユーザ／ユーザ・グループに関するユーザ対話レコード１９、およびリソース・インデクシング機能２７に対してこれらを処理する。このサブプロセスは、特に、特定のコンテキストを特定のリソースにマッピングして、ユーザが明示的にシステムをトレーニングすることを必要とせずに、所与のユーザの彼の現在のコンテキストでの検索結果の関連を高める。リソース解決の適応インデクシングおよびリソース・ルックアップ・サブプロセス２８の主要な出力は、新たに識別されたリソース応答セット３５であり、このリソース応答セット３５が、応答セット順序付けおよび注釈サブプロセス３４に入力される。リソース解決の適応インデクシングおよびリソース・ルックアップ・サブプロセス２８は、さらに、さらに強化された機能２７’を用いるリソース・インデクシング機能データベース１８への更新を含む副出力を生成する。したがって、機械学習は、ユーザがシステムを明示的にトレーニングする必要なしに、リソース・インデクシング機能の常に改良されるセットを展開するのに使用される。用語「リソース・インデクシング機能」が、ユーザ照会と検索可能リソースの間のマッピングを示すことを理解されたい。本発明において、用語ルールおよび機能は、交換可能に使用される。両方が、ラベル付き入力値の組を与えられて、ラベル付き出力値の組を計算する形でインタープリタによって実行することができるデータ構造を指す。算術ルールの例が、「華氏←摂氏×５／９＋３２」である。ルール言語には、ニューラル・ネット、意思決定木、関数型言語、多項式関数が含まれるが、これに制限はされない。具体的に言うと、「リソース・インデクシング機能」に、各検索を絞りこむのを助ける包含および排他のリソース・パラメータおよび値を含めることができる。」
　
　段落００２７には、「マッピング」に関し、「このサブプロセスは、特に、特定のコンテキストを特定のリソースにマッピングして、．．．」との記載、及び、『用語「リソース・インデクシング機能」が、ユーザ照会と検索可能リソースの間のマッピングを示すことを理解されたい。』との記載がある。
　「このサブプロセスは、特に、特定のコンテキストを特定のリソースにマッピングして、．．．」との記載に関し、「このサブプロセス」とは、「リソース解決の適応インデクシングおよびリソース・ルックアップ・サブプロセス２８」であると解されるから、該記載からは「リソース解決の適応インデクシングおよびリソース・ルックアップ・サブプロセス２８」が、「特定のコンテキスト」を「特定のリソース」に「マッピング」するものであるといえる。
　しかし、該記載は、具体的な「マッピング」の処理内容を明らかにするものではなく、また、請求項１における「ユーザ照会」と「ユーザ・コンテキスト・ベクトル」とを「リソースのサブセット」にマッピングする構成との対応関係が明確ではない。
　また、段落００２７における『用語「リソース・インデクシング機能」が、ユーザ照会と検索可能リソースの間のマッピングを示すことを理解されたい。』との記載は、「マッピング」が名詞として記載されていると解され、請求項１の「．．．リソースのサブセットにマッピングし」という処理（動詞）との対応関係が明確でない。また、該記載は、「ユーザ照会」と「リソース」間の「マッピング」であると解され、請求項１における「ユーザ照会」と「ユーザ・コンテキスト・ベクトル」とを「リソースのサブセット」にマッピングする構成との対応関係が明確ではない。
　段落００２７の記載のうち、『用語「「リソース・インデクシング機能」が〜』以降の各文は、日本語として明確でなく、また、文相互の関係（つながり）が明確でないため、全体として意味が不明である。
　
（段落００３４）
「【００３４】
　第３動作では、リソース・ルックアップ・サブプロセス２８８が、ユーザが照会を開始するか洗練する時に、必ず対話式に実行される。この際に、ユーザ照会と、ユーザ・コンテキスト分類サブプロセス２４で展開されるコンテキスト・ベクトル２５’の両方が、インスタンス化されたリソース・インデクシング機能２７に対してリソース・ルックアップ・サブプロセス２８８によって処理される。リソース・マップを使用して、リソース・ライブラリ４２からユーザの照会に関連するリソースのサブセットを選択し、リソース応答セット３５を作成する。具体的に言うと、リソース・ルックアップ・サブプロセス２８８は、すべてのリソースにスコアを付け、応答セットを生成することによってリソースのサブセットを計算する機能を実施する。各応答は、関連する異なる属性（コストなど）を有する。入力のコンテキスト・ベクトル２５’は、たとえばコスト、専門レベルなどについてどの属性が関連するかと、その値を示す。入力のユーザ照会項目が、さらに、リソース・ルックアップ・サブプロセス２８８によって出力されるリソース応答セット３５のリソースと突き合わされる。コンテキスト・ベクトルに基づく突合せだけでは不十分なので、選択されたリソースは、コストおよび専門レベルの観点から正しい。」
　
　段落００３４には、「リソース・ライブラリ４２からユーザの照会に関連するリソースのサブセットを選択」とあるから、「ユーザ照会」と「リソースのサブセット」との「マッピング」になんらかの関係があると解される。
　しかし、段落００３４には、「リソース・マップを使用して、リソース・ライブラリ４２からユーザの照会に関連するリソースのサブセットを選択し、リソース応答セット３５を作成する。」と記載されているが、「リソース・マップ」なる用語は、発明の詳細な説明の他の箇所に用いられておらず、「リソース・マップ」がどのようなものであるのか、また、「リソース・マップ」を使用して「リソースのサブセットを選択」することがどのような処理であるのか、明確に把握することができない。
　また、段落００３４の続く部分の、「具体的に言うと、リソース・ルックアップ・サブプロセス２８８は、すべてのリソースにスコアを付け、応答セットを生成することによってリソースのサブセットを計算する機能を実施する。」との記載は、明確ではないが、「リソースのサブセットを計算する機能」の一部あるいは全部が、「すべてのリソースにスコアを付け、応答セットを生成すること」によってもたらされるとすると、「すべてのリソースにスコアを付け、応答セットを生成すること」が、どのような情報をどのように用いてスコアを付け、応答セットを生成するのか、いずれも明確に記載されていない。
　また、請求項１の記載では、「応答セット」が「リソースのサブセット」を含むように記載されているが、段落００３４の記載は、リソースのサブセットを計算する機能の一部として「応答セットを生成すること」を行うように記載されており、「応答セット」と「リソースのサブセット」の包含関係が異なると解されるため、請求項１と段落００３４の記載との対応関係が明確ではない。
　また、段落００３４における「入力のユーザ照会項目が、さらに、リソース・ルックアップ・サブプロセス２８８によって出力されるリソース応答セット３５のリソースと突き合わされる。」との記載は、「ユーザ照会」と「リソース」とが「突き合わされる」という処理であると解されるが、「ユーザ照会」と「リソース」との間でどのような情報処理が行われるのか把握できず、また、「リソース応答セット」と突き合わされることから「リソース応答セット」が生成された後の処理と考えられ、段落００３４の先行する記載「リソース・マップを使用して、リソース・ライブラリ４２からユーザの照会に関連するリソースのサブセットを選択し、リソース応答セット３５を作成する。」との関係、及び、請求項１の「．．．リソースのサブセットにマッピングし、前記リソースのサブセットを含む応答セットを生成し、」という処理との対応関係がいずれも明確ではない。
　
（段落００７１）
「【００７１】
　図１に戻って、顧客セルフ・サービス・システムによって、ユーザ・コンテキストおよびシステムとの前の対話の組合せから導出されるｎ次元のコンテキスト・ベクトル２５’が実施されて、特定のコンテキストが特定のリソースにマッピングされる。これによって、ユーザがシステムを明示的にトレーニングすることを必要とせずに、所与のユーザの現在のコンテキストでそのユーザに関する検索結果の関連が高まる。推論および結論は、個々のユーザの好ましいリソース特性と、ユーザの共通の組のリソース特性の両方に関して行われる。これらは、本発明を使用する後続の検索のために各特定のユーザに提示されるアイコン・インターフェースを修正し、同一の検索に応答してインターフェースを介するユーザへの提示のために選択される結果を修正するために、サブプロセスへの入力として使用される。経時的に、このシステムは、個々の必要を満たす能力が改善され、ユーザのグループに好ましい回答を提案する能力へ進化する。」
　
　段落００７１の記載は「ｎ次元のコンテキスト・ベクトル２５’が実施されて」との記載の「実施されて」との記載が何を意味するのか明確でないため、全体として記載の内容が明確ではない。
　また、「特定のコンテキスト」が「特定のリソース」に「マッピングされる」ものであると解されるから、請求項１における「ユーザ照会とユーザコンテキストベクトル」を「リソースのサブセット」にマッピングすることとの対応関係が明確でない。
　
　これらの段落００２２，００２７，００３４，００７１のいずれにも、「ユーザ照会」と「ユーザ・コンテキスト・ベクトル」とを一括して「マッピング」する構成は記載されていないから、請求項１における「前記ユーザ照会と前記ユーザ・コンテキスト・ベクトルとを前記リソース・ライブラリに格納されるリソースのサブセットにマッピング」するとの記載に直接に対応する構成は、発明の詳細な説明に記載された構成を抽象化（上位概念化）したものと解される。
　そして、上記「マッピング」に関する発明の詳細な説明の記載のうち、段落００２２，００２７，００７１には、「特定のコンテキスト」を「特定のリソース」にマッピングすることが記載されているといえる。しかし、「ユーザ対話レコード」に基づいて「ユーザ・コンテキスト・ベクトル」を「リソースのサブセット」にマッピングすることについては、具体的にどのような情報処理を行うのか、いずれにも記載されていない。
　また、「ユーザ照会」を「リソースのサブセット」にマッピングすることについては、段落００３４に関連すると思われる「リソース・マップを使用して、リソース・ライブラリ４２からユーザの照会に関連するリソースのサブセットを選択し、」との記載があるものの、それ以上の具体的記載はない。そのため、「リソース・マップ」と「マッピング」することの関係は明らかではなく、また、「リソースのサブセットを選択」することと「リソースのサブセットにマッピング」することの関係も明らかではない。したがって、「ユーザ対話レコード」に基づいて「ユーザ照会」を「リソースのサブセット」にマッピングすることについては、具体的にどのような情報処理を行うのか、記載されているとはいえない。
　
　してみれば、請求項１における「マッピング」することについて、「ユーザ・コンテキスト・ベクトル」、及び、「ユーザ照会」のそれぞれを「リソースのサブセット」に「マッピング」する構成が、発明の詳細な説明には、当業者が請求項１に係る発明を理解し実施できる程度に明確かつ十分に記載されているとはいえない。
　
　以上のとおり、請求項１における「前記リソース・ライブラリと以前の照会、この照会に対する応答、および、対話、に関するデータを格納するユーザ対話レコードとに基づいて、前記ユーザ照会と前記ユーザ・コンテキスト・ベクトルとを前記リソース・ライブラリに格納されるリソースのサブセットにマッピング」との記載における「マッピング」について、請求項の記載は明確ではなく、また、発明の詳細な説明の記載が明確かつ十分ではないため、発明の詳細な説明を参酌しても、明確に把握できるとはいえない。
　
（き）「応答セット」について
　請求項１における「応答セット」は、「リソースのサブセットを含む」とあるから、ユーザの照会に対する応答として生成される、そのような応答セットであると解される。
　しかし、上記のとおり「リソースのサブセットにマッピング」する構成は、請求項の記載が明確でなく、また、発明の詳細な説明及び図面の記載を参酌しても明確に把握することができないから、結果として、「応答セット」がどのような情報であるのか、明確に把握できるとはいえない。
　
（く）まとめ
　本願の請求項１における「ユーザ・コンテキスト・ベクトル」、及び、「ユーザ・コンテキスト・ベクトルを生成する手段」は、上記（え）で検討したように、それ自体明確ではなく、また、「ユーザ・コンテキスト・ベクトル」、及び、「ユーザ・コンテキスト・ベクトルを生成する手段」についての発明の詳細な説明が十分ではないため、発明の詳細な説明の記載を参酌しても、明確であるとはいえない。
　また、本願の請求項１における「マッピング」は、上記（あ）〜（お）の検討を踏まえると、
「リソース・ライブラリ」と「ユーザ対話レコード」に基づいて、
文として入力されたテキストデータの「ユーザ照会」と、
「ユーザ・コンテキストおよびシステムとの前の対話の組合せから導出され」、「コンテキスト属性毎に事前に定義される属性値について、当初にセットされた値、及び、当初にセットされた値を変更したものが追加される」「ｎ次元（のベクトル）」である「たとえばコスト、専門レベルなどについてどの属性が関連するかと、その値を示す」「ユーザ・コンテキスト・ベクトル」とを、
「リソース」の部分集合である「サブセット」に、
「マッピング」することであると解される。
　一方、上記（か）で述べたように、発明の詳細な説明には、「ユーザ照会」と「ユーザ・コンテキスト・ベクトル」とをマッピングする処理について、「ユーザ照会とユーザ・コンテキスト・ベクトル」とを（一括して）マッピングする構成は記載されておらず、個別に処理を行う構成については記載があるものの、いずれについてもどのように「ユーザ照会」と「ユーザ・コンテキスト・ベクトル」とを「ユーザ対話レコード」に基づいて「マッピング」するのか、具体的な情報処理が記載されているとはいえない。
　
　したがって、原査定の拒絶理由１．（３）に関し、請求項１における、「リソース・インデクシング手段」についての、「前記リソース・ライブラリと以前の照会、この照会に対する応答、および、対話、に関するデータを格納するユーザ対話レコードとに基づいて、前記ユーザ照会と前記ユーザ・コンテキスト・ベクトルとを前記リソース・ライブラリに格納されるリソースのサブセットにマッピングし、前記リソースのサブセットを含む応答セットを生成し」との記載は、それ自体明確であるとはいえず、発明の詳細な説明の記載を参酌したとしても明確に把握することができないから、請求項１の記載は、特許を受けようとする発明が明確であるとはいえない。（特許法第３６条第６項第２号）
　また、請求項１に係る発明について、当業者がその実施をすることができる程度に発明の詳細な説明が明確かつ十分に記載されているとはいえない。（特許法第３６条第４項）
　　
（２）拒絶理由の１．（１）について
　本願の請求項１における「ユーザ・コンテキスト」という語は、上記（１）（え）で引用した、意見書及び審判請求の理由での主張にある、「予め定義した検索項目のデータ」であって、「ユーザ」が「入力する」もの、及び、段落００２５に記載された、「帰納学習アルゴリズム」によって「導出される」、あるいは、「予測」される「コンテキスト」を指すと解される。
　そして、「ユーザ・コンテキスト」自体は発明の詳細な説明の記載を参酌することでその内容が把握できるものの、「ユーザ・コンテキスト・ベクトル」及び「ユーザ・コンテキスト・ベクトルを生成する手段」については、上記（１）（え）で述べたように発明の詳細な説明の記載を参酌しても明確ではない。
　
　
５．むすび
　上記のとおり、本願の請求項１に係る発明は、特許法第３６条第４項及び第６項に規定する要件を満たしていない。
　したがって、他の請求項について検討するまでもなく、この出願は拒絶すべきものである。
　よって、結論のとおり審決する。
　
　
（付記：審尋回答書における補正案について）
　審判請求人は、審尋に対する平成２０年１月１１日付けの回答書の「３．本願発明について（３−１）本願発明の補正について」にて、特許請求の範囲の補正案を記載しているので、以下に検討する。
　該補正案における請求項１は、下記のとおりである。
「［請求項１］ 
 　ユーザの照会に応答してリソースの検索および選択を実行する顧客セルフ・サービス・システムであって、 
 　前記ユーザの照会に関連するリソースを有するリソース・ライブラリと、 
 　前記ユーザの照会に適応するリソースを要求するために必要な情報であるユーザ照会を受け付けるインターフェースと、 
 　前記ユーザ照会と前記ユーザ照会に関連するとともに検索に関係するコンテキスト属性の組みを表すユーザ・コンテキストとを前記ユーザから受信して少なくとも前記検索に関する属性を表すユーザ・コンテキスト・ベクトルを生成する手段と、 
 　前記ユーザによって選択されたリソースを含むユーザ対話レコードを格納するユーザ対話レコード・データベースと、 
 　前記ユーザ対話レコード・データベースからユーザ対話レコードを受けるとともに、前記リソース・ライブラリからリソースを受け、前記ユーザ照会および前記ユーザ・コンテキスト・ベクトルに応じて前記ユーザ照会と前記リソースとのマッピングを行って、前記ユーザ対話レコードと前記ユーザによって選択されたリソースとに応じて前記ユーザ照会に関係する前記リソースのサブセットを含む応答セットを生成するリソース・インデクシング手段とを有する顧客セルフ・サービス・システム。 」
　
　上記補正案の請求項１における「ユーザ・コンテキスト・ベクトル」、「ユーザ・コンテキスト・ベクトルを生成する手段」、及び、「マッピング」について、現在の請求項１と同様に、その具体的な情報処理を当業者が理解し実施できる程度に、発明の詳細な説明が明確かつ記載されているとはいえない。
　また、補正案の請求項１の、「マッピング」を行う構成は、「ユーザ対話レコードに基づいて」マッピングを行う構成、及び、リソースの「サブセットに」マッピングする構成が削除されているため、請求項に記載された「リソース・インデクシング手段」の内容が現在の請求項１に比べてさらに不明確になっている。