(57)【要約】【課題】ユーザの意見を基にしてカテゴリーを管理するとともに料理レシピを最適なカテゴリーに自動分類し、ユーザの観点に近いカテゴリーを構築することで、ユーザに利便性の高い料理レシピ提示システムを提供する。  【解決手段】意味内容分析手段５は、入力された意見のテキストデータを分解して意味内容を分析し、意味内容の表現の強さを数値化する。レシピ属性管理手段６は、料理レシピに対するユーザの意見に基づいて属性を付与、または削除を行い料理レシピの属性を管理する。レシピ分類・カテゴリー管理手段７は、各料理レシピを既存のカテゴリーの中で最も近いものに分類する。新規カテゴリーの作成と既存カテゴリーの削除を行い、カテゴリーを管理する。検索手段８は、入力されたキーワードから条件に一致するレシピを選択する。これらの機能を用いて最適なカテゴリーに自動分類する。【選択図】        図１
2005284406.tif 000002
【特許請求の範囲】
【請求項１】
料理レシピに対するユーザの意見を入力データとして取り込み、この入力データから意味内容を分析し、意味内容の表現の強さを数値化する意味内容分析手段と、
前記数値化されたデータに基づいて料理レシピに対して感想に関する属性を付与または削除するレシピ属性管理手段と、
前記属性データに基づいて料理レシピを既存のカテゴリーに分類し、又はカテゴリーを生成、削除するレシピ分類・カテゴリー管理手段とを備えたことを特徴とする料理レシピ提示システム。
【請求項２】
前記料理レシピの既存のカテゴリーへの分類は、料理レシピに付与された属性と、この属性に関する既存カテゴリー毎の平均値との関係により類似度を判断して行うことを特徴とする請求項１記載の料理レシピ提示システム。
【請求項３】
前記カテゴリーの生成は、カテゴリー内の料理レシピ数が所定の値以上になった場合か、又はカテゴリーの属性の平均値が所定の値以上になった場合に、当該カテゴリーを分割して新しいカテゴリーを生成することを特徴とする請求項１〜請求項２記載の料理レシピ提示システム。
【請求項４】
前記カテゴリーの削除は、カテゴリー内の料理レシピ数が所定の値以下になった場合か、又はカテゴリーの属性の平均値が所定の値以下になった場合に、当該カテゴリーを削除することを特徴とする請求項１〜請求項３記載の料理レシピ提示システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、料理レシピをユーザの意見をもとに最適なカテゴリーに分類してユーザに提示し、ユーザにとって利便性の良い料理レシピ情報を提供する料理レシピ提示システムに関する。
【背景技術】
【０００２】
キッチンでユーザが調理を行う場合、ユーザが望む料理の料理レシピを表示装置に提示したり、料理方法を音声出力するシステム等がある。インターネットを介して様々なホームページから料理レシピを閲覧したり、入手したりすることができる。
【０００３】
また、料理レシピ情報を専門に提供しているサイトもあり、ユーザが端末から検索条件を入力して料理レシピ情報が蓄積されたデータベースを検索することを行い、ユーザが望む料理レシピ情報を取り出すようにしている。
【０００４】
さらに、ユーザが望む料理レシピ情報を取り出しやすくするために、ユーザから被調理物を実際に加熱調理したときの加熱調理装置の操作内容の情報や加熱動作情報を記述した定型原稿をホストコンピュータにアップロードし、ホストコンピュータでその情報を国別料理、主食、副食、加熱熱源、装置の機種別などのカテゴリーに分類し、データベース化して保管するシステムが提案されている。  
【０００５】
【特許文献１】特開平９−２１８８７５号公報
【特許文献２】特開２００３−７６７０５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかし、上記従来の技術では、料理レシピサイトにおいてレシピが追加され増えていくと、最初に提供されたカテゴリーだけを使っていると１つのカテゴリー内に含められるレシピ数が多すぎてユーザが望むレシピを探し出すのに時間がかかる。１つのカテゴリー内の料理レシピの数が増えると、１つのカテゴリー内に多くの要素が存在してしまうので、カテゴリーの特徴が薄れ、どのカテゴリーを探せば欲しい料理レシピを見つけられるのかが判断しにくくなる。
【０００７】
逆に、カテゴリーが細分化されすぎた場合には個々のカテゴリーの特徴は明確になってくるので、カテゴリー内の料理レシピは探しやすいが目的のカテゴリー自身を探すのに時間がかかったり、ユーザ自身が考えているのとは大きくかけ離れた観点から思いもよらないカテゴリーに欲しい料理レシピが分類されている場合がある。
【０００８】
また、個々のユーザ自身の好みでカテゴリー名称を登録できるものがあるが（例えば、ブラウザの「お気に入り」など）、放置しておくと１つのカテゴリー内の情報量が増えて探しにくくなり、他方、頻繁に分類するのは煩雑である。
【０００９】
現在では、ＢＢＳという形でユーザ同士が質問や回答を行い、情報を交換する手段があるが、過去データの検索や、インターネット上のマナーなどにも問題が多く、集積された情報が十分に活用されていない。
【００１０】
本発明は、上述した課題を解決するために創案されたものであり、ユーザの意見を基にしてカテゴリーを管理するとともに料理レシピを最適なカテゴリーに自動分類し、ユーザの観点に近いカテゴリーを構築することで、ユーザに利便性の高い料理レシピ提示システムを提供することを目的としている。
【課題を解決するための手段】
【００１１】
上記目的を達成するために、請求項１記載の発明は、料理レシピに対するユーザの意見を入力データとして取り込み、この入力データから意味内容を分析し、意味内容の表現の強さを数値化する意味内容分析手段と、前記数値化されたデータに基づいて料理レシピに対して感想に関する属性を付与または削除するレシピ属性管理手段と、前記属性データに基づいて料理レシピを既存のカテゴリーに分類し、又はカテゴリーを生成、削除するレシピ分類・カテゴリー管理手段とを備えたことを特徴とする料理レシピ提示システムである。
【００１２】
また、請求項２記載の発明は、前記料理レシピの既存のカテゴリーへの分類は、料理レシピに付与された属性と、この属性に関する既存カテゴリー毎の平均値との関係により類似度を判断して行うことを特徴とする請求項１記載の料理レシピ提示システムである。
【００１３】
また、請求項３記載の発明は、前記カテゴリーの生成は、カテゴリー内の料理レシピ数が所定の値以上になった場合か、又はカテゴリーの属性の平均値が所定の値以上になった場合に、当該カテゴリーを分割して新しいカテゴリーを生成することを特徴とする請求項１〜請求項２記載の料理レシピ提示システムである。
【００１４】
また、請求項４記載の発明は、前記カテゴリーの削除は、カテゴリー内の料理レシピ数が所定の値以下になった場合か、又はカテゴリーの属性の平均値が所定の値以下になった場合に、当該カテゴリーを削除することを特徴とする請求項１〜請求項３記載の料理レシピ提示システムである。
【発明の効果】
【００１５】
本発明によれば、ユーザの意見を基にしてカテゴリーを管理するとともに料理レシピを最適なカテゴリーに自動分類し、レシピの分類を適宜修正することでユーザの観点に近いカテゴリーを構築することができる。
【００１６】
また、ユーザの意見を継続的に収集して分類を見直すことで、ユーザにとってわかりやすく、精度の高い分類を行うことができる。さらに、ユーザの意見を再度ユーザに提供することで蓄積された情報を積極的に活用することができる。
【発明を実施するための最良の形態】
【００１７】
以下、図面を参照して本発明の一実施形態を説明する。図１は本発明による料理レシピ提示システムの基本構成例を示す図である。
【００１８】
ユーザ１が使用する入出力端末２は、サーバ４とインターネット、通信回線、ＬＡＮなどのネットワーク３で接続されており、入出力端末２とサーバ４とはネットワーク３を介してデータを送受信することができるようになっている。
【００１９】
サーバ４は、意味内容分析手段５、レシピ属性管理手段６、レシピ分類・カテゴリー管理手段７、検索手段８、メモリ部９、テキストＤＢ（データベース）１０、テキスト分析結果ＤＢ１１、テキスト内容分析ＤＢ１２、テキスト内容数値化ＤＢ１３、レシピ属性値ＤＢ１４、カテゴリー情報ＤＢ１５、ユーザ情報ＤＢ１６、レシピＤＢ１７とから構成されている。
【００２０】
意味内容分析手段５は、入力された意見のテキストデータを分解して意味内容を分析し、意味内容の表現の強さを数値化する。レシピ属性管理手段６は、料理レシピに対するユーザの意見に基づいて属性を付与、または削除を行い料理レシピの属性を管理する。
【００２１】
レシピ分類・カテゴリー管理手段７は、各料理レシピを既存のカテゴリーの中で最も近いものに分類する。新規カテゴリーの作成と既存カテゴリーの削除を行い、カテゴリーを管理する。検索手段８は、入力されたキーワードから条件に一致するレシピを選択する。
【００２２】
テキストＤＢ１０は、例えば、図３のようなデータベース構造となっており、ユーザ１が入出力端末２から入力した料理レシピに対する意見の原文が保存されている。意見の原文にはテキストＩＤが付与されて、その意見内容（テキスト内容）とともにデータベースに格納される。
【００２３】
テキスト内容分析ＤＢ１２は、例えば、図４のようなデータベース構造となっており、ユーザの意見から内容を分析するための分析用データが保存されている。テキスト属性欄には、料理レシピの属性を決める要素が並んでおり、各属性の要素と同義語と見なせる単語が属性候補ワード欄に記載されている。したがって、ユーザの意見の中に例えば、「しょっぱい」という単語が見つかれば、「塩辛い」という属性と同義であると解釈される。
【００２４】
テキスト内容数値化ＤＢ１３は、例えば、図６のようなデータベース構造となっており、テキスト属性の度合いを数値であらわそうとするものである。例えば、テキスト内容分析ＤＢ１２を用いて、テキスト属性として「辛い」という属性が見つかった場合、その「辛い」という単語にかかる形容詞などを抽出して辛さの度合いを数値化するためのものであり、非常にという単語が存在すれば、４点が付与される。
【００２５】
テキスト分析結果ＤＢ１１は、例えば、図５のようなデータベース構造となっており、ユーザの意見としてのテキストデータをテキスト内容分析ＤＢ１２、テキスト内容数値化ＤＢ１を用いて分析された結果が格納される。
【００２６】
レシピ属性値ＤＢ１４は、例えば、図７のようなデータベース構造となっており、各料理レシピに寄せられている意見をすべてテキスト分析して数値化し、各属性候補ごとに合計点数を算出している。
【００２７】
カテゴリー情報ＤＢ１５は、例えば、図９のようなデータベース構造となっており、カテゴリー毎に料理レシピが整理されているデータ構造（上側の図）と、料理レシピ毎に属性が整理されているデータ構造（下側の図）の両方を有している。
【００２８】
ユーザ情報ＤＢ１６は、例えば、図１１のようなデータベース構造となっており、ユーザごとにユーザＩＤが割り当てられ、地域、家族の人数、どの料理レシピを参照したかやどの意見をコメントしたのか等の履歴が記載された履歴ファイルなどが保存される。
【００２９】
レシピＤＢ１７は、例えば、図１０のようなデータベース構造となっており、レシピを表示する料理レシピを表示するために必要なすべての情報、材料データ、作り方データ、出来上がった料理の写真などが格納される。
【００３０】
メモリ部９は、不揮発性のメモリ等で構成されており、電源を切ってもメモリに蓄えられたデータは消滅しないようになっている。メモリ部９には、図８に示すように、料理レシピに対して意見を述べたユーザとその意見内容のテキストと意見が述べられた料理レシピとを関連付けるデータが保存される。
【００３１】
次に、図１のシステムにおける動作について説明する。図１２は基本的な処理手順を示し、ユーザから料理レシピに対して意見が寄せられた場合の処理の流れを示す。
【００３２】
まず、ユーザ１が入出力端末２から意見を入力すると、新規テキストとしてテキストＩＤが付されテキストＤＢ１０に追加される（Ｓ１）。メモリ部９にはテキストＩＤ、レシピＩＤ、ユーザＩＤが関連付けられて保存される。次にテキスト分析処理（Ｓ２）が行われる。このテキスト分析処理内容の手順を示すのが図１３であり、図１３に示すテキスト分析処理は意味内容分析手段５で実行される。まず、入力されたテキストのデータクリーニング（Ｓ１１）を行い、ユーザの表記方法をあらかじめ決められた表記方法に統一する。
【００３３】
次に、意味を区切る文字や文字列などに基づいてテキストの文書分解を行い、文に分解する（Ｓ１１）。さらに、形態素解析などを用いて文を単語に分解する。ここでテキストの内容を特定するために、テキストには「感想」と「提案」の２つの属性を与える。「感想」には料理レシピに対する感想（甘かった、辛かった、量が多かった、秋には良さそうな料理だ等）を、「提案」には材料や調理法の代替案、改善、工夫などの内容を含める。
【００３４】
「提案」にはさらに内容から「材料」や「調理方法」「味付け」などの属性を付け加えておく。「感想」の属性に該当するものがあるかどうかを調べるために、上記分解された単語をテキスト内容分析ＤＢ１２を用いてテキストの内容を特定する（Ｓ１１）。
【００３５】
テキストの属性に「感想」に関するものがあるかどうか判断し（Ｓ１２）、「感想」に関するものがない場合は、テキスト分析結果ＤＢ１１に分析結果を記録して終了する。
【００３６】
一方、「感想」に関するものがある場合には、この属性をテキスト内容数値化ＤＢ１３を用いてその意味内容の度合いを数値化する（Ｓ１３）。図６のデータを用いると、例えば、「非常に辛かった」は辛さ＝４、「そこそこ甘かった」は甘さ＝２となる。数値化した結果とテキスト属性をテキストＩＤとともにテキスト分析結果ＤＢ１１に記録し（Ｓ１４）、テキスト分析処理を終了する。
【００３７】
テキスト分析処理が終了するとレシピ属性更新処理（Ｓ３）に移る。レシピ属性更新処理内容の流れを示すのが図１４であり、図１４に示すテキスト分析処理はレシピ属性管理手段６で実行される。まず、上記テキスト分析処理で「感想」に関する属性が抽出された場合に、メモリ部９を用いてそのテキストに対応する特定の料理レシピＲに付与されているテキストを過去の分を含めてすべて集め、テキスト分析結果ＤＢ１１のテキスト分析結果の件数をカウントする。この合計件数があらかじめ定めた閾値Ｎ以上かどうか判断し（Ｓ２１）、Ｒに対してテキスト合計件数がＮ以上の場合には、各属性候補（甘い・辛い・温かい・ヘルシー等の料理の属性）毎に、テキスト分析結果ＤＢ１１のテキスト分析結果を用い、数値化されたデータを合計してレシピ属性候補値ａを計算する（Ｓ２２）。この値は、レシピ属性値ＤＢ１４に保存される。
【００３８】
したがって、一度レシピ属性値ＤＢ１４に記録された属性に関しては、次に同じ属性を持つテキストが入力された場合、このレシピ属性値ＤＢ１４に保存されている数値に次の属性数値を加算すれば、合計値が求まる。
【００３９】
ａがあらかじめ定められた上限値以上であるかどうか判断し（Ｓ２３）、上限値以上であればａをＲの属性に追加する（Ｓ２４）。一方、ａが上限値未満であれば、さらにａがあらかじめ定められた下限値以下かどうか判断し（Ｓ２５）、ａが下限値以下ならばａをＲの属性から削除する（Ｓ２６）。
【００４０】
他方、ａが下限値を超えているならば、削除の処理を行わずにＳ２７の処理に移行する。Ｓ２７では、全ての属性候補に対して判定が終了しているかどうかを判断し、すべての判定が終了していない場合はＳ２３からのステップに戻り、終了している場合には属性情報に変化があった場合（属性追加、属性削除）にカテゴリー情報ＤＢ１５のレシピ属性情報を更新する（Ｓ２８）。
【００４１】
例えば、閾値Ｎを６０とし、料理レシピＲに意見を入力したテキスト件数が１００件あったとすると、レシピＲは属性の追加又は削除の対象となる。これら１００件のテキストの分析結果を図５のテキストＩＤより抽出する。  抽出されたデータを確認して、例えば、「辛い」という属性を有するテキストが上記１００件中、７０件存在し、「温かい」という属性を有するテキストが４０件存在したとすると、「辛い」という属性が属性情報として追加または削除され得る候補となる。
【００４２】
次に、各属性について、図５のテキスト分析結果の数値（辛い：−２、甘い：３  など）を１００件分加算する。この合計値をＳ２３〜Ｓ２７までの判定処理にかけてカテゴリー情報ＤＢ１５の属性情報を追加したり、削除したりする。
【００４３】
次に、レシピ属性の更新があったどうかを判別し（Ｓ４）、更新がない場合には処理を終了する。更新があった場合には、レシピの分類処理（Ｓ５）へ移行する。
【００４４】
図１５は、レシピの分類処理のフローを示すものであり、レシピ分類・カテゴリー管理手段７により実行される。レシピの属性更新内容により処理が分かれ（Ｓ３１）、レシピＲに属性ａを追加の場合は（Ｓ３２）、属性ａのカテゴリーCiに対してCiでのａの平均値とＲのａの距離が閾値以下かどうか判定し（Ｓ３３），閾値以下ならばＲをCiに分類し（Ｓ３４）、カテゴリー情報ＤＢ１５のカテゴリー情報を更新する（Ｓ３９）。閾値以下でない場合は終了する。
【００４５】
上記Ｓ３３の分類ルールを詳しく説明すると、あるカテゴリーCiにおいて、Ciの属性Aiに対してCi内の全てのレシピの平均値Acを求める。あるレシピRに対して、Rの属性AとAcの距離Ad＝|A−Ac|を考える。現在存在する全てのカテゴリーに対してAdを求め、RはAd(Ci)が閾値以下となる全てのCiに属すると考える。
【００４６】
例えば、「甘い」カテゴリーにレシピが10個分類されていたとする。それぞれのレシピの「甘い」の値がa＝｛3,2,5,3,4,2,4,2,3,3|i=1,2,…,10｝とすると、Ac＝(a1,…,a10)/10=3.1である。レシピRの「甘い」の値aが3 の場合Ad＝0.1であり、a＝−4の場合Ad＝7.1である。他のカテゴリーとの距離が「塩辛い」＝3.5、「温かい」＝4.7、「辛い」＝8.1、「ヘルシー」＝2.2で閾値が3だったとすると、Ad＝0.1ならばRは「甘い」と「ヘルシー」に分類され、Ad＝7.1の場合には「ヘルシー」に分類される。
【００４７】
一方、レシピＲから属性ａ消去の場合（Ｓ３５）は、Ｒを属性ａのカテゴリーCiから削除し（Ｓ３６）、Ｒが他のカテゴリーに属するかどうかを判定し（Ｓ３７）、属さない場合はＲを予備カテゴリーＣＳに仮分類する（Ｓ３８）。他方、属する場合にはカテゴリー情報ＤＢ１５のカテゴリー情報を更新する（Ｓ３９）。ところで、カテゴリーCiの属性ａと矛盾する属性ｂが付与された場合にもＲはCiに分類されるレシピではないと考えて上記同様レシピＲを属性ａのカテゴリーCiから削除し（Ｓ３６）、Ｒが他のカテゴリーに属するかどうかを判定し（Ｓ３７）、どのカテゴリーにも属さない場合はＲを予備カテゴリーＣＳに正式に分類する（Ｓ３８）。
【００４８】
例えば、「辛い」というカテゴリーに登録されていたあるカレーのレシピＸにユーザから「甘い」という属性が加えられた、あるいは「辛い」という属性に対して負の評価がつけられて「辛い」という属性がＸから消去された場合、Ｘはユーザにとって「甘い」カレーもしくは「辛くない」カレーであると認識されていることがわかる。そこで、Ｘが「辛い」料理に分類されているのは不自然であり、「辛い」カテゴリーからＸを消去するのが適切であることがわかる。
【００４９】
レシピの分類処理が終了するとレシピ分類の変更があったかどうかを判定し（Ｓ６）、変更がない場合には処理を終了する。変更があった場合には、カテゴリー更新処理（Ｓ７）を行う。このカテゴリー更新処理を示すのが、図１６であり、これらの処理はレシピ分類・カテゴリー管理手段７により実行される。
【００５０】
カテゴリーCiをチェックし（Ｓ４１）、Ｓ３３と同様の分類ルールを適用する。Ciのレシピ数が所定の上限値以上またはCiの属性値の平均値が所定の上限値以上かどうかを判別し（Ｓ４２）、上限値以上であればCiを２〜３個のカテゴリーに分離して、カテゴリー作成を行い（Ｓ４３）、カテゴリー情報ＤＢ１５のカテゴリー情報を更新する（Ｓ４７）。
【００５１】
すなわち、Ciのレシピ数が増えすぎたり、Ciの領域が広くなりすぎたりすると、カテゴリーの規模が大きくなりすぎてカテゴリーの特徴が薄れてくるので、これを防ぐために２〜３個のカテゴリーに分割するものである。対象レシピ群に対してクラスター分析を行ってグループを分割して新カテゴリーＣｎｊ（ｊ＝１、２またはｊ＝１、２、３）を作成する。このときの分割ルールをＣｎｊの属性とする。また、レシピに付与さているある属性ｃに着目した場合、ｃを有するレシピがＳ４２でいう上限値以上であれば、属性ｃのカテゴリーを新しく作成する。
【００５２】
一方、上限値未満の場合は、さらに、Ciのレシピ数が所定の下限値以下またはCiの属性値の平均値が所定の下限値以下かどうかを判別し（Ｓ４４）、下限値を超えているならば、処理を行わずに終了する。他方、下限値以下ならばカテゴリーCiを削除し（Ｓ４５）、Ci中のレシピを新規レシピとして新規レシピ追加処理を行う（Ｓ４６）。
【００５３】
すなわち、カテゴリーCi中のレシピ数が非常に少なくなったり、カテゴリーCiの範囲が非常に狭くなったりした場合には、カテゴリーCiは無意味なカテゴリーであると判断してCiを削除する。
【００５４】
Ｓ４６の新規レシピ追加処理のフローを示すのが、図１７である。図１７の処理はカテゴリー削除に伴う処理以外に、独自に新しい料理レシピが追加されてそのレシピの属性を分類する場合にも用いられる。また、図１９には以下に述べる新規レシピ追加時に分類ルールを適用した場合の概念図を、図２０には、削除されたカテゴリーからレシピが他のカテゴリーへ編入される様子の概念図を示す。
【００５５】
まず、削除されたカテゴリーCi中のレシピを新規レシピＲｎｅｗとして追加し（Ｓ５１）、Ｒｎｅｗを予備カテゴリーＣＳに仮分類する（Ｓ５２）。次にＳ３３と同様の分類ルールを適用し、ある属性ａを持つカテゴリーCiに対してCiでの平均値とＲｎｅｗの属性ａの値の距離が所定の閾値以下かどうか判定し（Ｓ５３）、閾値以下ならＲｎｅｗをカテゴリーCiに分類し（Ｓ５６）、閾値を超えるならば、Ｒｎｅｗを予備カテゴリーＣＳに分類する（Ｓ５７）。
【００５６】
全てのカテゴリーに対して以上の処理が終われば、再度図１６に戻り、カテゴリー情報ＤＢ１５のカテゴリー情報を更新する（Ｓ４７）。次に、図１２に戻り、基本的な処理の流れが終了することになる。
【００５７】
図１８は、料理レシピに対する意見をユーザが再利用する処理フローを示す。多数のユーザが実際に料理を作ってみた結果から寄せる意見には、システム提供者だけでなく、他のユーザにとっても有益な意見が含まれていることが多い。例えば、サラダに水菜を入れるとおいしいという情報などがあった場合、サラダを作ろうとしている他のユーザにとっては貴重な情報となる場合がある。
【００５８】
したがって、個々のユーザが入力した意見内容の情報は、全体のユーザで共有できることが望ましい。このように、図１８は、他のユーザが参考となるテキスト情報を検索する手順を示す。
【００５９】
まず、ユーザ１は入出力端末２を用いて検索条件を入力し、所望の料理レシピ情報Ｒを検索手段８により抽出する（Ｓ６１）。Ｒに対するテキスト内容をテキストＤＢ１０から検索し（Ｓ６２）、テキストが存在するかどうか判別し（Ｓ６３）、テキストが存在しない場合はテキスト内容は表示されず、レシピＲの他の内容が画面に表示される（Ｓ６５）。
【００６０】
一方、テキストが存在する場合は、ユーザが参考にしたいテキスト、例えば、「提案」の属性を持つものや「感想」の属性を持つものを選び出す。「提案」はユーザに対するアドバイスとなり、「感想」はおすすめの根拠として使用できる。これらの内容がレシピ情報とともに表示される（Ｓ６５）。
【００６１】
また、情報の表示の方法としては、レシピとテキスト内容をまとめて表示する他に、レシピとは別にユーザが参照したい情報を一覧から選択する形式としても良い。
【００６２】
ところで、分析対象とするテキストを不特定多数のユーザの意見とすることで、一般的なユーザの感覚に近いカテゴリーが生成でき、誰にとっても使いやすいカテゴリーを提供できるが、
他方、分析対象をある特定のユーザ１人に限定した場合、そのユーザが今までコメントしてきた意見に加えてユーザ情報ＤＢ１６に蓄えられている履歴（開いたレシピや使用した検索語句、意見を述べたレシピ、使用日時など）や家族構成、年齢、地域などの登録情報から推測した好みを判断材料に取り入れることで、そのユーザ用に特化したカテゴリーを提供できる。
【００６３】
ユーザは複数の分類方法によるカテゴリーを使用することで、例えば、いつもは個人カテゴリーからレシピを探しているが、今日はパーティ料理を見たいから一般的なカテゴリーから探すことで見つけることができたり、初期設定のカテゴリーしか使っていなかったが、個人カテゴリーを探したら参考になるものが見つけられたといったような利点が生じる。
【００６４】
このようなカテゴリー表示の一例を示すのが図２である。標準カテゴリーが初期設定のカテゴリーに、今月のカテゴリーが一般的なユーザ感覚に近いカテゴリーに、マイカテゴリーが個人カテゴリーに相当する。
【図面の簡単な説明】
【００６５】
【図１】本発明による料理レシピ提示システムの基本構成例を示す図である。
【図２】カテゴリー表示の一例を示す図である。
【図３】テキストＤＢのデータ構造例を示す図である。
【図４】テキスト内容分析ＤＢのデータ構造例を示す図である。
【図５】テキスト分析結果ＤＢのデータ構造例を示す図である。
【図６】テキスト内容数値化ＤＢのデータ構造例を示す図である。
【図７】レシピ属性値ＤＢ１４のデータ構造例を示す図である。
【図８】メモリ部のデータ構造例を示す図である。
【図９】カテゴリー情報ＤＢのデータ構造例を示す図である。
【図１０】レシピＤＢのデータ構造例を示す図である
【図１１】ユーザ情報ＤＢのデータ構造例を示す図である。
【図１２】基本的な処理手順を示す図である。
【図１３】テキスト分析処理内容の手順を示す図である。
【図１４】レシピ属性更新処理内容の手順を示す図である。
【図１５】レシピ分類処理内容の手順を示す図である。
【図１６】カテゴリー更新処理内容の手順を示す図である
【図１７】新規レシピ追加処理内容の手順を示す図である
【図１８】料理レシピに対する意見をユーザが再利用する処理フローを示す図である。
【図１９】新規レシピ追加時に分類ルールを適用した場合の概念を示す図である。
【図２０】削除されたカテゴリーからレシピが他のカテゴリーへ編入される様子の概念を示す図である。
【図１】
2005284406.tif 000003
【図２】
2005284406.tif 000004
【図３】
2005284406.tif 000005
【図４】
2005284406.tif 000006
【図５】
2005284406.tif 000007
【図６】
2005284406.tif 000008
【図７】
2005284406.tif 000009
【図８】
2005284406.tif 000010
【図９】
2005284406.tif 000011
【図１０】
2005284406.tif 000012
【図１１】
2005284406.tif 000013
【図１２】
2005284406.tif 000014
【図１３】
2005284406.tif 000015
【図１４】
2005284406.tif 000016
【図１５】
2005284406.tif 000017
【図１６】
2005284406.tif 000018
【図１７】
2005284406.tif 000019
【図１８】
2005284406.tif 000020
【図１９】
2005284406.tif 000021
【図２０】
2005284406.tif 000022