JP6889427B1 - 生活の情報を記録し、管理し、分析し、表示するための情報端末、情報処理システム及びプログラム - Google Patents

Abstract

【課題】消費者の物品の利用状況を記録し、管理し、分析することにより、物品を有効活用するとともに、生活の快適性を高める。【解決手段】生活情報システム は、事前にユーザが意図を表す文字列を指定し、物品を特定するためのキーワードである呼名を登録するというルールに従って、ユーザにより音声等で情報端末に入力された、物品の購入から消費までの詳細に関する文を受け取り、文の中からユーザの意図を特定し、物品の呼名を抽出し、データベースのユーザ独自のデータが格納された種類別のテーブルからユーザの意図に対応した種類のテーブルを選択し、文から抽出された物品の呼名を、テーブルのユーザ毎に登録された物品の呼名と対応させることにより、ユーザの意図に応じて、データベースを一括して更新し、身の回りの物品の管理を手軽な操作方法で可能とし、データベースからユーザの要求に応じ、生活に役立つ様々な情報を抽出し提供する。【選択図】図３

Description

本発明は、消費者の物品の購入、消費および在庫の状況と、体調を記録し、管理し、分析し、表示するための情報端末、情報処理システム及びプログラムに関する。

近年スマートフォンなどの携帯情報端末の機能が向上し、各種情報を消費者が画像や音声、その他の様々な方法で容易かつ迅速に入力できる環境が整ってきている。そのような環境の中、消費者から食事内容と健康状態の情報を入手し、健康指導を行うサービスが出てきている。また、消費者が食品等の商品の情報を携帯情報端末で管理できる仕組みもある。

特許文献１には自動アシスタントを操作する方法として、自然言語処理モジュールが、テキスト文字列からユーザの意図を推測する技術が開示されている。

特許文献２には、文章、画像またはメニューを選択する方法により取得された食事の情報に基づき、栄養情報を取得し、さらに生活習慣アンケートや、生体ログ情報などにより、健康に関する情報を取得し、これらの情報を分析の上、アドバイス情報を送信する技術が開示されている。

特開２０１８−１４０８６号公報 特開２０１７−１５７１９８号公報

従来の仕組みでは、一般の消費者が生活の快適性を高め、無駄を削減するために日常的にデータベースを使用することは容易ではなかった。

画像やバーコードの認識による商品情報の情報端末への入力は、消費者にとっては簡単な操作で可能だが、画像では外観が類似していれば、中身が異なっていても、同じ商品として認識されてしまうという難点がある。また、バーコードで認識できるものは一部の商品に限定され、バーコードのついていない商品には対応することができない。

音声入力等による自然言語を処理することにより、より柔軟に、多くの種類の情報を扱うことができる可能性があるが、自然言語による文を機械的に解析し、ユーザの意図をくみ取る従来の方法は、不正確になりがちであるという課題があった。

本発明の生活情報システムは自由な内容を入力可能な文による入力方法を採用しつつも、ユーザが自ら取得し、消費する物品に関する文を入力する方法に、事前に一定のルールを設けることにより、自然言語による文を解析し、ユーザの意図を推測し、何ら取り決めなく入力された単語を抽出する方法よりも、より正確に文を解析した上で、ユーザ独自の物品に関するデータベースを更新する仕組みとする。
具体的には、生活情報システムは、ユーザが意図を表し、データベースに動作を指示するための文字列を事前に指定し、物品を特定するためのキーワードである呼名を事前にデータベースに登録するというルールを設けたうえで、ユーザからルールに従って入力された物品に関する文を受け取り、文の中の、データベースに動作を指示するための所定の文字列を認識することによりユーザの意図を特定し、残りの文字列から物品の呼名を抽出し、データベースのユーザ独自のデータが格納された種類別のテーブルからユーザの意図に対応した種類のテーブルを選択し、文から抽出された物品の呼名を、テーブルのユーザ毎に登録された物品の呼名と対応させることにより、ユーザ独自の物品のデータを抽出し、データベースを一括して更新し、ユーザの情報端末に通知を送信する。

音声入力などの情報端末からユーザにとって簡単な操作で直感的にスピーディーに行える入力方法により、ユーザの意図に対応して複数のデータを一括して更新することが可能となるため、従来難しかった一般家庭でのデータベースによる物品の在庫管理が可能となり、ユーザは記憶に頼らず効率的に生活することができ、心理的負担が軽減され、生活の快適性を高め、物品を有効活用することができる。

生活情報システムのハードウェア構成図 生活情報システムのブロック図 文から意図を認識し呼名を利用してデータ更新をするまでのフローを示す図 取得時の物品アイテムと呼名についてのフローを示す図 購入入力と保管入力に関する画面および処理の例を示す図 在庫一覧の画面の表示例 在庫の詳細を確認するための画面の表示例 物品消費と体調に関する画面および処理の例を示す図 購入予定に関する画面および処理の例を示す図 体調レベルと換算値の計算例と画面の表示例 物品アイテムの消費状況と問題の有無による可能性％の推移の例を示す図 物品アイテム別の可能性％と評点の計算例を示す図 物品消費と体調に関する反応確認の画面の表示例 物品消費と体調に関する参考情報を確認するための画面の表示例 ローリングストックに関する画面および処理の例を示す図 在庫の期限と保管場所を確認するための画面の表示例 消費の実績と目標に関する画面の表示例 データ入力から出力までのフローの概略を示す図

以下、添付図面を参照して、本発明の実施形態について詳細に説明する。図１は、本発明の一実施形態に係る情報処理システムである生活情報システム１のハードウェア構成図である。同図に示すように生活情報システム１はサーバ１００と、ユーザの使用する情報端末と、を含んで構成されており、これらはインターネットや無線通信回線等の通信ネットワーク２００で接続されている。ユーザの使用する情報端末としてコンピュータ３０１と、スマートフォン３０２と、スマートスピーカー３０３と、を例示している。図２のユーザが使用する情報端末３００はそれらの情報端末に加え、図１の例示以外の電子機器も含む。

図２は、生活情報システム１のブロック図である。取得部１０１はユーザが使用する情報端末３００より入力されたデータを受け取り、データは解析部１０２により内容が解析され、更新部１０３にその解析結果が受け渡される。解析部１０２は解析の際、文の解析に必要なユーザ独自の情報をデータベース１１０に照会する。更新部１０３は解析部１０２から得られた情報に基づきデータベース１１０を更新し、分析部１０４はデータベース１１０及び知識ベース１１１のデータに基づき分析を行い、分析結果を通知部１０５より、ユーザが使用する情報端末３００へ送信するとともに、必要に応じデータベース１１０と、知識ベース１１１のデータを更新する。通知部１０５が解析部１０２による認識済みの入力結果をユーザが使用する情報端末３００に送信することで、ユーザは入力内容の確認や、追加や、編集を行うことができる。なお、解析部１０２が解析したユーザからの入力内容が、データの抽出表示の要求のみであり、データの更新を伴わない場合、通知部１０５は、ユーザの要求内容を解析部１０２から直接受け取り、データベース１１０からユーザの意図に対応したデータを抽出し、ユーザが使用する情報端末３００へ送信する。

本実施形態は、生活情報システム１がユーザが使用する情報端末３００とは別に、サーバ１００で運用されるケースを想定しているが、生活情報システム１は知識ベース１１１の機能を限定した上で、ユーザが使用する情報端末３００内で運用しても良い。なお、本発明には、生活情報システム１の全部または一部の機能を実現するためのプログラムも含まれ、そのようなプログラムはサーバ上で実行されるだけでなく、ネットワーク上から、情報端末にダウンロードできるものでもよい。あるいは、あらかじめ情報端末に格納しておいてもよいし、情報端末で読み取り可能な記録媒体に格納してもよい。

上記の通り、ユーザによる情報端末３００への入力結果は、通信ネットワーク２００と、取得部１０１と、解析部１０２と、必要に応じ、更新部１０３と、分析部１０４を通して処理され、ユーザが使用する情報端末３００への情報の送信は、通知部１０５を通して処理されるが、以下の説明では、そのような途中経過を省略し、ユーザが直接データベース１１０を操作し、処理結果を情報端末３００に表示させるかのような説明を行っている場合がある。また、生活情報システム１の各部の処理であることを明記していない場合がある。そのような場合でも、実際には、上記の途中経過が伴うが、以下では誤解の生じる余地のない処理の説明については、説明を省略している。なお、以下で特に範囲を明記せず「既存の」として説明している箇所はデータベース１１０にデータが存在するということを意味している。

文での入力はデータベース１１０への記録を迅速に行うための手段であり、音声や、キーボードや、タッチパネルによる情報端末３００への入力や、その他の各種の入力方法によることもできる。以下の説明では、主にユーザがスマートフォン３０２などの画面を確認しながら操作する前提で記載を行っている。文での入力は、例として図８にあるようなスマートフォン３０２の画面上の文によるテキスト入力可能な部分（以下「入力ボックス」と呼ぶ）を表示するなどの方法で行い、入力内容をユーザが確認しながら時系列に入力し、さらに正確性のためにデータベース１１０の更新前に、ユーザに内容の確認を促すこともできる。

データベース１１０の更新前に、解析部１０２が入力された文を解析し、データベース１１０に記録するために変換した結果は、情報端末３００の確認画面として表示され、ユーザにより内容が確定されると、データベース１１０が更新される。ユーザが確認を行う時間がない時は、入力された文をそのまま記録し、ユーザが後で確認できるようにしてもよいし、備忘記録として食品等の画像を情報端末３００に記録しておき、ユーザがあらためて後で文を入力できるようにしても良い。情報端末３００からのデータの送信はメールなどで行っても良く、スマートスピーカー３０３の場合などで、入力時に画面で確認を行えない環境であっても、本発明の利用が可能である。ユーザが情報端末３００の画面で代表的なものの選択肢から逐一選択する方法では、表示と確認の手間がかかる上に、該当するものが選択肢にあるとは限らず、入力内容が不正確になるという問題があるが、文によらず、コンピュータ３０１や、スマートフォン３０２などの、情報端末３００の画面から入力内容をプルダウンメニューから選択したり、内容を項目ごとに一つずつ入力したりすることも可能である。

文による入力の場合は、取得したデータは取得部１０１と解析部１０２を介して更新部１０３により処理されるが、ユーザが情報端末３００の画面から直接データを項目ごとに個々に入力する場合は取得部１０１から解析部１０２を介さずに直接、更新部１０３により処理される。

本実施形態は、一般消費者を生活情報システム１の主たるユーザとして想定しているが、家庭内で一般消費者の入力をサポートする人や、たとえば飲食店などの消費財を扱う事業者などもユーザとして想定できる。また、生活情報システム１の利用の対象となる消費者は、自らが直接情報端末３００に入力しないか、入力内容や方法が不十分な場合、仲介者が対象となる消費者からヒアリングを行うか、生活情報システム１外から消費者のデータを収集し、編集した上で、仲介者がユーザとして、情報端末３００に入力をする方法をとることもできる。そのようなユーザは対象となる消費者の関係者でもよいし、事業として生活情報システム１を運営するか、消費者による生活情報システム１の利用をサポートする者でもよい。以下では、ユーザが対象となる消費者でもあるケースについて説明を行っている。

生活情報システム１は物品の情報を管理するための情報処理システムであり、管理の対象となりうる物品は食品にとどまらず、衣服などの消費財や、化粧品やサプリメントなど、生活の快適性に影響するユーザの身の回りの物すべてである。本実施形態では、物品のうち主として、特に数が多く、日々消費されるため、管理の必要性の高い食品を例にとり、説明を行っている。

一般消費者の家庭内の物品は、日々数多くの購入と消費が繰り返される。特に食品に関しては、その原材料も多岐にわたるため、従来の方法では日常で摂取される食品のブランド等の違いによる微量含有物の違いまでも把握可能な方法で情報を収集することは難しかった。簡単な操作で情報端末から直感的にスピーディーに食品等の購入、消費及び在庫確認時に、多数の品名のみならず原材料や、購入店や、消費期限などの関連事項を入力可能でなければユーザにとって継続的に日々の記録を続けることは難しい。また、記憶に頼る、あるいは日記や表計算ソフトなどへの食事内容や健康状態の時系列の記録だけでは効率的で客観的な分析は難しく、アンケートや生体ログ情報も、消費者に体感される体調のレベルの推移を適時かつ網羅的に把握するものではない。画像では物品の材料などの本質的な違いを把握することは難しく、バーコードでは外食の場合や生鮮食料品などを含めたすべての物品に対応することができないため、それらの方法は補完的に利用しても良いが、本実施形態では、文による入力方法を前提として説明を行っている。なお、本発明は一般消費者が家庭内等で保管する物品であっても、他の状態の物品と区別するために、企業の場合と同様に在庫と呼び、管理の対象としている。

図１８はユーザによる生活情報システム１へのデータ入力からユーザへ提供される情報のフローの概略を示している。生活情報システム１は家庭内の物品や、外食の状況のデータ（以下それらを「物のデータ」と呼ぶ）だけでなく、体調や、生活習慣の状況などのデータ（以下それらを「事のデータ」と呼ぶ）を、物のデータと関連付け、相関関係を分析することで、ユーザに有用な情報を提供することができる。

生活情報システム１は音声等により情報端末３００に入力された、ユーザの外食店などでの食品の摂取状況を含む、物品の購入から消費までの詳細な物のデータと、体調の状況などの事のデータに関する文を受け取り、内容を解析し、データベース１１０を更新し、知識ベース１１１に蓄積された情報を参照し、ユーザの物品の消費と体調との相関関係の分析を行い、分析結果に基づき体調改善のための参考情報をユーザに提示し、ユーザの要求に応じ、物品の目標消費ペースを設定し、物品の消費実績と比較した結果に基づくアドバイスをユーザに提示する他、データベースからユーザの要求に応じ、生活に役立つ様々な情報を抽出し提供する。

ユーザは物品の情報（物のデータ）の他、気になる体調が現れるなどの生活にかかわる情報（事のデータ）をその都度、イベントとして情報端末３００に入力する。それらの内容は、イベント発生の日時の情報とともにデータベース１１０に記録される。生活情報システム１には家庭内のすべての物品の購入、消費などの状況の変化や、その他の生活習慣や体調の変化などのイベントを記録することが可能だが、ユーザが当面注意したいと考えるイベントだけを記録することもできる。また、図１８にあるように、生活情報システム１はイベントだけでなく、考察や、目標や、計画も記録の対象としている。

生活情報システム１を利用することによりユーザは食事のメニュー作成や、服装の計画や、買い物の計画を無駄なく効率的に行うことができる。さらに物品のコストパフォーマンスを容易に確認できるようになり、無駄な支出を削減することもできる。物品の目標消費期限や保管場所の管理により、食品ロスをはじめとした資源の無駄が大幅に削減でき、食品等を鮮度の高いうちに消費することができ、保管場所の削減にもつながる。

以下の表１から表４はデータベース１１０に含まれるマスタテーブルと、テーブルと、抽出処理結果であるクエリと、レポートの種類の例を示している。これらは、ユーザが画面を操作することができる情報端末３００を利用している場合には、画面に表形式で表示され、ユーザが画面上で確認可能であり、編集することもできる。項目名の末尾の符号３文字のうち左の２文字は値や数値などの内容を示し、右の小文字は性質を示している。右の小文字の性質は表５の通りとなっている。種類テーブルＭ−１の種類Ｃ１ｏと、品名テーブルＭ−２の品名Ｃ２ｏと、種類Ｃ１ｓと、その対応関係のサンプルが初期設定されているのと、意図テーブルＭ−１１で選択可能な動作内容Ｃ４ｓと意図Ｒ６ｏとその対応関係のサンプルが初期設定されているのと、含有物換算テーブルＭ−１０、以外についてはユーザが末尾がｍ（マスタ）、ｏ（オリジナル）、またはｔ（オリジナル書き出しのため一時的利用）のデータを入力する仕組みとなっている。例として、食材とレベルレポートＲ−２のレベルＥ１ｖはレベルテーブルＴ−４のレベルＥ１ｏを参照したものである。末尾がｓのデータは末尾がｍ（マスタ）と、ｏ（オリジナル）のデータを参照し選択する仕組みだが、文による入力の場合は、対象となる文字列が参照先のｍ（マスタ）と、ｏ（オリジナル）と一致する場合のみ選択されるものとする。なお、表１から５には本実施形態の説明に関係する内容を例示してあるが、テーブル等の種類や、項目は、これらに限定されるものではない。

物品の大区分は「種類」とし、種類テーブルＭ−１であらかじめ例えば「乳製品」や「果物」といった種類毎に物品の種類Ｃ１ｏを設定することができる。物品の中区分は「品名」とし、例えば「乳製品」の種類の中の「チーズ」や「牛乳」などの一般的な品名を登録する。物品の初期登録の際に品名Ｃ２ｏを必須項目とし、品名Ｃ２ｏには品名のマスターテーブルである品名テーブルＭ−２で、種類Ｃ１ｓを割り当てることができる。新規の品名Ｃ２ｏを登録する場合は種類Ｃ１ｓを選択する。代表的な品名については品名テーブルＭ−２に、種類Ｃ１ｓと品名Ｃ２ｏのサンプルと、その対応関係の雛型を準備し、ユーザが適宜編集できるものとする。例えば雛形ではリンゴＣ２ｏという品名はあらかじめ果物という種類Ｃ１ｓに対応させられている。

物品の小区分は「ブランド」とする。食材テーブルＴ−２の項目のブランドＥ２ｏは物品を区別するために産地や、メーカー名、その他ユーザが家庭内で物品を特定するために必要な情報を自由に入力するための項目であり、例えばＡ商店で購入の「長野県産有機のキャベツ」という内容の入力の場合、キャベツは野菜という種類Ｃ１ｓのキャベツという品名Ｃ２ｓに対応させ、「長野県産有機」や「○○ブランド」といった内容を食材テーブルＴ−２のブランドＥ２ｏとして、登録する。図４（ｂ）のフロー図にあるように、ブランドＥ２ｏの項目の入力の有無と内容は物品アイテムの同一性を判断するために使われる。食材テーブルＴ−２のブランドＥ２ｏの入力は必須ではなく、未入力の場合、店Ｒ１ｏと品名Ｃ２ｏの組み合わせによっても同一性を判断することができる。なお、図５の別の例にあるように、店名と購入日時については同時に購入した物品の情報とともに一括して入力することができる。

個々の物品のデータは更新部１０３により場所Ｌ４ｓ、品名Ｃ２ｓ、ブランドＥ２ｏ、店Ｒ１ｏ、目標消費期限Ｔ５ｏ等の情報とともにデータベースの食材テーブルＴ−２に記録される。品名Ｃ２ｏには品名テーブルＭ−２で、種類Ｃ１ｓが割り当てられているので、在庫一覧クエリＱ−７で物品を種類Ｃ１ｅに対応させることができる。通知部１０５はユーザが使用する情報端末３００からの要求に応じて、在庫一覧クエリＱ−７の場所Ｌ４ｅ、種類Ｃ１ｅ等の別に物品の在庫一覧を表示するための情報をユーザが使用する情報端末３００に送信することができる。図６（ａ）は種類別在庫一覧の表示例となっている。

食材テーブルＴ−２は、食品を例とした場合のユーザの物品リストであり、食品以外の物品も食品同様に扱うことができる。食材テーブルＴ−２には物品の販売店を意味する店Ｒ１ｏと、品名Ｃ２ｓとブランドＥ２ｏの情報が含まれるので、その情報により、図４のフローに従って物品アイテムを特定することができる。図７は文による在庫確認画面の呼び出し例と、食材テーブルＴ−２を元とした在庫一覧クエリＱ−７の物品毎の表示例である。図６はこのような情報を一覧にしたものであり、画面操作可能な情報端末３００の場合は、ユーザは図６や、図７のような画面からも在庫内容の編集をすることができる。

本発明では、物品は原材料そのものであるか、あるいは同一原材料により作られた物品を同一アイテムの物品として扱うことを特徴としており、原材料として考慮されるのは、主な物質だけではなく、可能な限り微量な含有物も含まれる。そのため本実施形態では、同一品名Ｃ２ｓかつ同一ブランドＥ２ｏ、または、ブランドＥ２ｏが未入力の場合は同一品名Ｃ２ｓかつ同一販売店Ｒ１ｏの物品を同一アイテムの物品とみなしている。図４（ａ）にはブランドの有無による物品アイテムの特定方法のフローが含まれている。物品は例えば消費者の家庭での食品の調理における「キャベツ」や「にんじん」などの原材料そのものであるか、あるいは加工食品などの場合は同一品名かつ同一ブランドであれば同一原材料により作られたとみなし、そのような物品を同一の物品アイテムとして扱う。通常は、物品は物品アイテムと同じ物を意味するが、消費者は同一アイテムの物品でも購入日や目標消費期限が異なる複数の物品を扱う場合があり、その場合の各物品は食材テーブルＴ−２で別レコードとして扱い、日付の他、備考Ｄ１ｏなどに別の内容を入力することができる。また、新規の物品を追加する際に、食材テーブルＴ−２で既存の物品アイテムのレコードのコピーを利用して、更新することができる。

物品に関して生活情報システム１では、ユーザが物品を購入または譲り受けし、保管し、移動し、利用し、譲渡あるいは処分する際における、詳細な情報をデータベースに記録するものとする。そうすることにより、取得時に記録されたデータが物品の以後のイベントの際にも引き継がれ、管理及び分析の際に有用な情報を提供することができる。そのため、以下で説明するユーザの意図の種類には少なくとも、物品の取得の記録と消費の記録を含むものとする。物品アイテムは、取得の情報の処理により、品名、種類、ブランド、購入店、期限等の情報に紐づけされデータベースに格納されるため、物品の消費の記録の際には、在庫のうち、どの物品アイテムが消費されたかが特定でき、物品の消費の記録を、原材料が特定できる形で詳細に行うことができる。加工食品等については、ユーザが気になる原材料があれば、食材テーブルＴ−２の備考Ｄ１ｏに記録する。

ユーザが使用する情報端末３００から例えば食品等の販売店からの購入時や、消費時などのタイミング毎に、事前にユーザ毎に定められたルールに従って入力された、物品に関する文を取得部１０１が取得する。本発明は、ユーザにより自然言語により入力される文の意図及び内容を、ユーザから事前に合意を得たうえで限定することにより、正確に文の意図を把握し、データベースを更新することを可能としている。

図３は、ユーザが情報端末３００に文によるデータ入力を行った場合の意図認識から呼名を利用したデータ更新までのフローを示している。生活イベントのデータ入力に先立ち、まずユーザが意図を表し、データベースに動作を指示するための文字列（以下、「意図を表す文字列」と呼ぶ）を事前に指定するというルールを設ける。その方法として、図３の例にあるように例えば「食べた物は」というキーワードを含む文を消費入力の意図があるものとして扱う、また文の中に「買った物は」というキーワードがある場合は、「購入内容の入力」という意図があるものとして扱う、というルールを設ける。キーワードはユーザ毎に設定可能とする。なお、例えば消費入力が頻繁である場合などに、文の中に意図を表すキーワードが含まれない場合は、消費入力の意図とみなすというルールを設けても良い。

データベース１１０内には、表１と表２にあるように、構造が異なる複数の種類のテーブルがある。それぞれのテーブルのデータはユーザ毎に区別され、ユーザ独自のデータが格納されている。意図テーブルＭ−１１でデータベースに対する動作内容Ｃ４ｓに対応する意図を表す文字列を意図Ｒ６ｏの項目に登録することにより、ユーザが入力する文の中に意図を表す文字列を含めることで、ユーザの意図に対応した種類のテーブルが選択され、それに対しどのような動作がされるのかが決定される。意図テーブルＭ−１１には選択可能な動作内容Ｃ４ｓと意図Ｒ６ｏとその対応関係のサンプルが初期設定されているが、ユーザが独自の文字列を意図Ｒ６ｏの項目に登録することもできる。

解析部１０２は取得部１０１より取得された文の中の、データベース１１０に動作を指示するための所定の文字列を認識することによりユーザの意図を特定する。その場合、図３の例にあるような、意図を表す文字列が一つの場合だけでなく、主となる文字列であるメインワードの他、副次的な文字列であるサブワードを組み合わせてデータベースに動作を指示することができる。図９（ｄ）の例では、「買い物予定」がメインワード、「を確認」がサブワードとなっている。解析部１０２により文の中の意図が認識されると、どのテーブルに対しどのような動作を行うのかといった、データベースに対する具体的動作が認識され、文の中のその他の内容に応じて、更新部１０３による処理が可能となる。

図８は文の中の意図が認識され、対応するテーブルに記録が行われる例を示している。意図を表す文字列、たとえば外食を記録する場合について「外で食事」というキーワードを事前に取り決めた場合、外食テーブルＴ−５に外食のデータが記録される。図８の他の例の、「お腹の調子」を含む文の場合は、レベルテーブルＴ−４が更新される。食材入力テーブルＴ−６と消費日時テーブルＴ−３の更新については、意図を表す文字列の入力がないが、これは、そのような場合、食材入力テーブルＴ−６と消費日時テーブルＴ−３を更新するというルールを取り決めている場合の例である。解析部１０２により抽出された一つまたは複数の物品の呼名の文字列がデータベース１１０の中のユーザの意図に対応して選択されたテーブルに登録されている一つまたは複数の呼名の文字列と一致するものについて、更新部１０３がそれぞれの呼名に対応する既存の物品アイテムのデータを更新する。

解析部１０２は文の中の意図を表す文字列以外の文字列からあらかじめ登録された物品の呼名を抽出する。解析部１０２により抽出された一つまたは複数の物品の呼名の文字列が、データベース１１０の中のユーザの意図に対応して選択されたテーブルに登録されている一つまたは複数の呼名の文字列と一致するものについては、更新部１０３がそれぞれの呼名に対応する既存の物品アイテムのデータを一括して更新する。なお、ユーザの意図の認識に関して、体調入力などの事のデータや、目標設定などの処理も物のデータの処理と同様に扱うことができるが、以下では食品などの物のデータの場合を例として説明を行っている。

呼名は、ユーザ毎に物品アイテムと一対一の対応関係を持たせるためのキーワードで、事前に物品アイテムに、個々の物品アイテムを特定するためのキーワードとしての呼名を割り当てることにより、呼名を入力するだけで、正確にデータベースからの物品アイテムのデータの抽出が可能となり、複雑な処理の結果を一般消費者が簡単に利用することができるようになる。

呼名クエリＱ−１は食材テーブルＴ−２を元としたものであり、呼名クエリＱ−１により、呼名Ａ３ｉは食材テーブルＴ−２で別名Ｅ３ｏの指定がされていない限り、品名Ｃ２ｖが使われる。ユーザにより事前に別名Ｅ３ｏの指定がされている場合は別名が呼名Ａ３ｉとして使われる。たとえば、品名Ｃ２ｖが「りんご」であっても別名Ｅ３ｏに「青りんご」の指定があれば別名が優先され、呼名Ａ３ｉは「青りんご」となる。別名Ｅ３ｏの入力がなければ呼名Ａ３ｉは「りんご」となる。図３右下の表もそのような方法の例となっている。図４（ａ）は物品アイテムの特定方法と、別名の有無による呼名の決定方法を示している。物品の購入に関する購入内容テーブルＴ−８の呼名Ｉ３ｔまたは消費に関する食材入力テーブルＴ−６の呼名Ｉ１ｔの入力などの際に、入力された物品の呼名を在庫物品の呼名Ａ３ｉに対応させることにより、一括してデータベースを更新することができる。同じ品名Ｃ２ｖの異なる物品アイテムに別名Ｅ３ｖが設定されず、どちらにも済Ｆ２ｏや予備Ｆ１ｏのフラグがない場合、呼名Ａ３ｉとして品名Ｃ２ｖが抽出に使われるが、一つの呼名Ａ３ｉに対応して複数の異なる物品アイテムが抽出される場合がある。その際ユーザにどちらかに別名Ｅ３ｏをつけることを促すことにより、物品アイテムを正確に区別することができる。別名Ｅ３ｏがつけられない状態で消費入力がされるのであれば後述するように、設定状況に応じ、入手日の早い順に、消費するなどの扱いをすることができる。

一つの意図に対して複数の呼名が入力される場合、ユーザにより入力される文の中の、物品の呼名と呼名の間の単語や記号については、あらかじめユーザ毎に「と」や、「＆」や、「、」などの文字または記号を単語の区切りとして使用するというルールを取り決めることにより、より正確に文中の呼名の認識が可能となる。例えば「水曜日の１３時に食べた物はジャガイモと玉ねぎとオリーブオイル」のように「と」や「それと」などの語句あるいは「＆」や「、」などの記号や、スペースで区切るルールを設定する。例として「キャベツとにんにくと人参」あるいは「キャベツ＆にんにく＆人参」と入力された文字列は解析部１０２により、「キャベツ」と、「にんにく」と、「人参」の３つの単語に分解され抽出される。なお、抽出された文字列が呼名クエリＱ−１の既存の呼名Ａ３ｉと一致しない場合には、食材テーブルＴ−２の品名Ｃ２ｓとの一致により処理してもよく、入力された文字列が過去に食材テーブルＴ−２に記録された物品の品名Ｃ２ｓや、ブランドＥ２ｏに部分一致すれば、候補物品としてユーザに選択を促してもよいし、知識ベース１１１に品名等の誤入力のパターンを格納し、変換候補としてユーザに選択を促してもよい。または新規の物品アイテムとして、未分類の状態で文字列を品名として仮に記録してもよいし、その際またはその後、ユーザに登録内容の確認を求めてもよい。

上記の通り、一つの意図に対して複数の呼名を入力することにより、テーブルの複数のレコードをまとめて操作することができる。さらに解析部１０２が文の中の物品の呼名の後に入力された、物品に関する情報の項目を表す文字列を認識することにより、その後に続く項目の内容を抽出し、更新部１０３が物品の呼名とともに物品についての情報を記録することができる。例えば、それぞれの呼名に続けて、「でそれの備考は・・で考察は・・で今回メモは・・でそれと」といった文字列が入力されるものとした場合、「備考は」や、「考察は」などの文字列で項目名を明らかにすることにより解析部１０２はそれぞれの呼名に対する複数の項目の内容を認識することができる。なお、この例の末尾の「でそれと」は、呼名と呼名を区分し、１つの呼名に関する情報の区切りとして扱われる例となっている。なお、この例のような項目名を含めず、単に呼名の後に「でそれは」という文字列が使われる場合は備考Ｄ１ｏとして認識するというルールを設けても良い。さらに、備考Ｄ１ｏ等に特定の文字列を含めることにより、それをデータ抽出の際のユーザ独自のフラグとして利用することもできる。

購入内容の入力に際してはまず、購入時テーブルＴ−７で事前に登録されている購入店Ｒ２ｓを選択し、購入日時Ｔ４ｔを入力する。保管場所毎に場所Ｌ４ｓを選択しておくこともできる。さらに購入内容テーブルＴ−８で呼名Ｉ３ｔなどの入力などを行い、これらの入力内容に基づき食材テーブルＴ−２に購入品の追加を行う。物品の取得の情報は購入時テーブルＴ−７及び購入内容テーブルＴ−８を用いて、あるいは直接、食材テーブルＴ−２に物品在庫の増加としてレコードを追加する形で品名Ｃ２ｓ、ブランドＥ２ｏ、目標消費期限Ｔ５ｏ、金額Ｐ１ｏなどの情報が追加される。呼名の扱いは後述の物品消費などに関する入力と、取得時の入力とでは少し異なる。物品取得時の入力内容としては店名Ｒ２ｓの他、物品の名前Ｉ３ｔとして、呼名か品名の入力と、場合によりブランド名Ｅ２ｔの入力がされる。なお購入でなく譲受の場合などは、店名Ｒ２ｓに譲渡人の名前を記入すればよい。

図４（ｂ）は取得時の物品アイテムの割り当て方法のフローを示したものである。図４（ｂ）のフローは図４（ａ）の物品アイテムの特定方法のフローを、取得時の処理に当てはめたものとなっている。既存の物品と同じアイテムの物品が購入される場合は、購入内容テーブルＴ−８に入力された呼名Ｉ３ｔが、呼名クエリＱ−１の呼名Ａ３ｉと一致すれば、食材テーブルＴ−２の物品アイテムに対応させられ、既存のデータの一部が、新しい入手日Ｔ４ｏのものとして転記される。取得時には入力された呼名Ｉ３ｔのうち、既存の呼名Ａ３ｉと一致しないものについては新規の物品アイテムとして扱われるフローが基本であるが、図４（ｂ）にあるように、入力された物品の名前が呼名Ａ３ｉと一致しない場合は、食材テーブルＴ−２に記録されている既存の品名Ｃ２ｓと一致するかも確認される。これはユーザが、別名があるにもかかわらず、既存の物品アイテムのデータ呼び出しの際に品名を入力してしまったケースを想定している。さらに、入力されたブランドＥ２ｔが、既存のブランドＥ２ｏと同一か、または入力された店名Ｒ２ｓが既存の物品の店名Ｒ１ｏと同一か、という判断を経て、同一性が判断される。取得された物品が記録されると、店Ｒ２ｅ別、及び入手日Ｔ４ｅ別に、購入履歴クエリＱ−５により食材テーブルＴ−２のデータを参照し、購入履歴の確認が可能となる。

入力時以前のイベントの入力の際に日時を入力する方法として、選択肢から日時を選択する方法もあるが、それには少し手間がかかり、文による日時の入力は意図を限定しないと不正確になるという問題があるため、解析部１０２は入力された文の中の、ユーザの意図を表すキーワードの前に、日時を表す文字列がある場合は、当該文字列を入力直前のタイミングのものとして過去の日時のデータに変換し、文の入力時点に代えて、更新部１０３が実際のユーザの生活イベントの発生日時として、ユーザの意図に応じて消費日時テーブルＴ−３の日時Ｔ１ｔ、レベルテーブルＴ−４の日時Ｔ３ｏ、または外食テーブルＴ−５の日時Ｔ２ｏなどに記録し、通知部１０５が都度ユーザの要望に応じて抽出したユーザの生活イベントのデータを、ユーザが使用する情報端末３００に表示させるために送信する。図８は入力内容から日時を認識する例を示している。このほかの例として、例えば「昨日の１９時に」あるいは「２時間前に」といった記載についても、入力日時から、過去の日時を計算する。なお夕食は１９時とするなど、ユーザが事前に時間の入力を省略するための設定をすることができるようにしてもよい。その場合、例えば１２月２日に「昨日の夕食は」という文の入力が行われれば、そのイベントは１２月１日の１９時のイベントとして記録される。文の中に日時に関する文字列がない場合は、情報端末３００への入力日時をイベント発生時として扱い、対応するテーブルに記録する。

ユーザは頻繁に物品を購入する物品の販売店Ｒ２ｏを事前に店テーブルＭ−４に登録することができる。そこで店の金額が税込みかどうかのフラグＦ８ｏを設定すると、金額の入力の際に税別か税込かが統一されていなくても購入時テーブルＴ−７に店名Ｒ２ｓを入力するだけで、統一された方法で金額を計算することができる。また、販売店Ｒ２ｏを登録することにより、店毎の購入履歴クエリＱ−５で物品への考察Ｄ３ｒや金額Ｐ１ｖを一覧表示することができる。

ユーザは「冷蔵庫」や「冷凍庫」などの保管場所Ｌ４ｏを事前に場所テーブルＭ−７に登録することにより、物品在庫の保管場所別の管理を行うことができる。図５（ａ）は、物品の購入内容を文によりデータベースに記録する場合の例で、入手日Ｔ４ｔ、「買ったものは」という購入内容の入力を意図する文字列、店名Ｒ２ｓと物品のブランドＥ２ｔ、呼名Ｉ３ｔ、金額Ｐ１ｔなどを入力すると図５（ｂ）の内容が解析部１０２により認識され、更新部１０３により購入時テーブルＴ−７と購入内容テーブルＴ−８に記録される。購入入力と保管入力を分ける場合は未入庫物品として、保管場所を保留状態とすることもできる。図５（ｃ）の例のように、購入した物品を保管する際に、呼名Ｉ３ｔとともに、保管場所Ｌ４ｓも入力することができ、図５（ｄ）の例にあるように解析部１０２により保管に関する意図が認識されることにより、物品の保管場所が認識されるようになる。

購入時の金額Ｐ１ｔの入力は必須ではないが、図５の（ａ）と、（ｂ）にある例のように、金額Ｐ１ｔを記録しておけば、一定期間の消費に対応した、あるいはメニュー毎の費用の算定なども可能となる。物品が購入されてから済とされるまで、消費記録は一度でなく複数回される可能性があるが、購入金額Ｐ１ｏを消費イベントに割り当てることで、簡便的に費用の計算を行うことができる。例えば５回使用される場合は５分の１の金額が消費された物品に対応するものとして扱うことができる。予定使用回数はユーザの過去の消費パターンから計算しても良いし、品名に応じ、知識ベース１１１から標準使用量を参照し、購入時の物品の量から予定使用回数を算定しても良い。

なお、購入結果あるいは注文結果の入力はレシートや納品書の画像を情報端末３００で読み取る、あるいは注文結果メール文などの取り込みによって行っても良い。注文結果の段階から記録をする場合は、到着予定一覧を確認することもできる。ユーザは注文商品について、物品の実際の入手時にあらためて注文済みの物品データを呼び出し、現物を確認しながら、食材テーブルＴ−２に目標消費期限Ｔ５ｏや、保管場所Ｌ４ｓや、備考Ｄ１ｏの入力を行いデータを更新することができる。

近年問題となっている食品ロスの原因として、家庭での賞味期限切れ食品の廃棄の問題が挙げられる。その原因の一つは食品を大量に購入し、消費することを忘れてしまうことにある。同様の問題は食品以外の物にも当てはまる。物品に記載されている賞味期限や消費期限は必ずしもユーザが希望する消費期限とは限らない。また物品によっては期限の記載のないものや、開封後は早めに消費する必要のある物品も多い。劣化した食品等を摂取することは健康に悪影響を与えるため、鮮度の良い状態で消費することが望ましい。ユーザが効率的に目標消費期限を設定するためには実際に物品を確認しながら素早く入力する方法が求められる。

ユーザは食品ラベル等に記載された賞味期限にかかわらず、また賞味期限の記載がないものであっても、目標消費期限を自由に設定することができる。目標消費期限はユーザが購入入力または在庫確認の画面で、個々に日付を選択して入力することもできるが、文により入力する場合は購入入力または在庫確認の意図毎に区切られた文の中の、物品の呼名を表すキーワードの後の、日付を表す文字列を日付のデータに変換し、目標消費期限Ｔ５ｏとして、食材テーブルＴ−２に記録する。例えば、「期限の入力でごま油は１月１５日までそれとレタスは３日後」といった文による入力が可能である。この場合、「期限の入力」という文字列を意図テーブルＭ−１１の意図Ｒ６ｏに対応させることにより、食材テーブルＴ−２の目標消費期限Ｔ５ｏの更新という意図が認識され、「ごま油」と「レタス」という呼名がＡ３ｉと対応され認識され、例えば入力時点が２０２０年４月１０日である場合、「ごま油」と「レタス」の目標消費期限はそれぞれ、２０２１年１月１５日と、２０２０年４月１３日として、対応する物品の目標消費期限Ｔ５ｏに記録される。図５（ｃ）と図１５は物品の保管の入力の際に目標消費期限Ｔ５ｏも入力される例となっている。特定の物品アイテムについては、あらかじめ入手日Ｔ４ｏから目標消費期限Ｔ５ｏを計算できるように、追加的に保管可能日数の項目を設けても良い。

生活情報システム１により、ユーザは物品に関する少しの情報を追加するだけで、在庫をローリングストックとして、効率的に無駄なく備蓄することができる。ユーザが同一の物品アイテムを複数所有する場合、通知部１０５は、ユーザがその物品アイテムを消費可能な間隔である備蓄テーブルＴ−９の最短許容消費間隔Ｔ６ｏと、物品アイテムの個々の物品の目標消費期限Ｔ５ｏから個々の物品についての推奨消費期限Ｔ７ｉを計算し、ユーザが使用する情報端末３００からの要求に応じて、物品の推奨消費期限Ｔ７ｉを表示するための情報をユーザが使用する情報端末３００に送信する。最短許容消費間隔Ｔ６ｏを定めないと、複数の物品在庫がある場合、目標消費期限が近づくと、まとめて消費しなければならないケースが考えられ、ユーザにとって負担となるため、快適に物品を消費できる最短の間隔である最短許容消費間隔Ｔ６ｏを、事前にユーザが主観に基づき入力するか、入力がない場合は通知部１０５が知識ベースの他の消費者の情報を参照して決定することができる。通知部１０５はユーザが使用する情報端末３００からの要求に応じて、物品別の目標消費期限Ｔ５ｏまたは推奨消費期限Ｔ７ｉの一覧を、ユーザが使用する情報端末３００に送信することもでき、個々の物品の推奨消費期限Ｔ７ｉが近付くとユーザーに物品の消費を促すための通知を送信することもできる。

ユーザは備蓄対象物品を備蓄テーブルＴ−９に呼名Ｉ５ｏで入力し、必要に応じ対象の物品についての最短許容消費間隔Ｔ６ｏを入力する。入力された呼名Ｉ５ｏは呼名クエリＱ−１の呼名Ａ３ｉと対応させられることにより、備蓄明細クエリＱ−８と、備蓄数量クエリＱ−９のデータが抽出され、関連する計算が可能となる。推奨消費期限Ｔ７ｉは備蓄明細クエリＱ−８により確認可能となる。図１５は購入した物品の保管時に、文により、目標消費期限Ｔ５ｏと最短許容消費間隔Ｔ６ｏを入力する場合の例である。

図１６は文により目標消費期限Ｔ５ｏまたは推奨消費期限Ｔ７ｉと、保管場所Ｌ４ｓを確認する場合の情報端末３００の画面の表示例である。この図の期限についての例のうち「白がゆ」については備蓄対象物品として、図１５の例で入力された、目標消費期限Ｔ５ｏと最短許容消費間隔Ｔ６ｏから推奨消費期限Ｔ７ｉが計算されていることを想定している。

また、備蓄テーブルＴ−９において、ユーザが事前に備蓄対象物品として登録した物品については、通知部１０５が、食材テーブルＴ−２における過去の目標消費期限Ｔ５ｏと入手日Ｔ４ｏとの関係から当該物品の保存可能期間を計算し、さらに最短許容消費間隔Ｔ６ｏから、備蓄数量クエリＱ−９でユーザにとっての物品の最大保有可能数量を計算し、物品の合計数量Ｑ１ｉが最大保有可能数量を下回るとユーザが使用する情報端末３００に当該物品の購入可能数量Ｑ２ｉに関する通知を送信することができる。

ユーザが目標消費期限が異なる同一アイテムの物品を複数保有している場合で、最短許容消費間隔をｍ、ｎ個目の物品の目標消費期限をｔ_n、推奨消費期限をｒ_nとすると、ｒ_nはｔ _n+1-mまたはｔ_nのどちらか小さいほうとして計算される。なお、目標消費期限ｔ _n+1は同一アイテムの物品の中でｎ個目の物品の次に目標消費期限が到来する物品の目標消費期限とする。

さらに、ｎ個目の物品の保存可能期間をｐ_n、入手日をｄ_n、同一物品アイテムの過去の保存可能期間の実績の平均値、または知識ベース１１１のデータに基づく当該物品アイテムの標準的保存可能期間をｐ、同一物品アイテムの在庫量をｑ、最大保有可能数量ａとすると、購入可能数量ｂは以下の数式の通り計算される。
ｐ_n＝ｔ_n−ｄ_n
ａ＝ｐ／ｍ
ｂ＝ａ−ｑ

物品情報を場所別に管理するために、テーブルＭ−５からＭ−７には大区分としての所在まとめＬ２ｏ、中区分としての所在Ｌ３ｏ、小区分としての場所Ｌ４ｏの項目が設けられている。ユーザは購入や消費のイベントの入力に先立ち、所在テーブルＭ−６に所在Ｌ３ｏの登録を行うことにより、複数拠点の利用に対応した在庫の管理を行うことができ、食材テーブルＴ−２の記録の際に、物品の所在Ｌ３ｓを選択しておくことにより、在庫一覧クエリＱ−７で物品を所在Ｌ３ｅ別に表示することができる。また、所在まとめテーブルＭ−５の所在まとめＬ２ｏに今回Ｎ１ｏのフラグを立てることにより、それに対応した所在テーブルＭ−６の所在まとめＬ２ｓに紐づけられた所在Ｌ３ｏに対応した物品のデータのみが呼名に基づく食材記録書出クエリＱ−２による消費実績の書出し対象となるとともに、在庫一覧クエリＱ−７でも、それに対応した、所在Ｌ３ｅのデータのみを表示することができる。

例えばユーザの住居の場所などの「新宿」と、ユーザの移動予定を意味する「新宿から横浜へ」を、それぞれ中区分としての所在Ｌ３ｏに登録し、それらを所在テーブルＭ−６で所在まとめＬ２ｓの選択肢、例えば「東京」を選択し、関連付ける。その上で、所在まとめテーブルＭ−５の所在まとめＬ２ｏの「東京」に今回Ｎ１ｏのフラグを立てれば、在庫一覧クエリＱ−７で「新宿」だけでなく「新宿から横浜へ」も含めた物品在庫一覧を表示することができる。

ユーザがユーザ以外の人、例えばユーザの子供の生活習慣や体調を記録したい場合、一連のイベントの内容の入力に先立ち、または個々のイベントごとに対象消費者の名前の入力を行うことにより、食材の消費記録や、体調の入力を簡単に行うことができる。ユーザは複数の消費者の情報の管理をすることができるため、例えば家族の人別に対応した物や体調の管理を行うことができる。その方法は消費入力に先立ち消費者テーブルＭ−８で消費者Ｌ１ｏを設定する。なお、消費者Ｌ１ｏの項目には一度に複数の消費者名を入力することもできる。図８のように、消費日時テーブルＴ−３で対象者の名前を消費者Ｌ１ｓで選択しておくと、以後の入力は、個別に消費者を入力するか、消費者Ｌ１ｓを変更するまで、その対象者についてのものとして扱われる。複数の消費者の情報の管理をする場合は図８の例にあるようにイベント毎に個別に名前を入力することにより簡単に対象者の切り替えができ、対象者別にデータを抽出することにより対象者別のレポートを生成することができる。

消費された物品アイテムの入力には２つの方法があり、一つは呼名を利用する方法で、それに加えて、画面表示可能な情報端末３００の場合はフラグを利用して入力することもできる。画面表示可能な情報端末３００の場合は、頻繁に消費する物品は呼名による入力方法、それ以外の物品は、フラグを利用する方法というように、適宜方法を使い分けることができる。

呼名を利用する方法の場合は、図３の消費記録の例にあるように、認識された食材入力テーブルＴ−６の呼名Ｉ１ｔが呼名クエリＱ−１の呼名Ａ３ｉと対応し、かつ食材テーブルＴ−２に記録されている物品のうち所在Ｌ３ｓが所在まとめテーブルＭ−５の今回Ｎ１ｏのフラグと所在テーブルＭ−６に対応し、後述する予備Ｆ１ｏと済Ｆ２ｏのフラグが立っていないものについて、食材テーブルＴ−２のデータが抽出され食材記録レポートＲ−１として書き出される。食材記録書出クエリＱ−２は呼名を利用する場合の食材記録レポートＲ−１更新前の確認用のクエリとなっている。フラグを利用する場合は、ユーザが物品のデータを図６の例にあるような一覧を、情報端末３００の在庫一覧クエリＱ−７の画面から呼び出し、今回Ｎ２ｒのチェックボックスにチェックをし、今回Ｎ２ｔというフラグを食材テーブルＴ−２の複数の物品にまとめて付けることにより、更新部１０３が一括して、消費日時テーブルＴ−３で指定された日時Ｔ１ｔに消費された記録を食材記録レポートＲ−１に書き出す方法によって行う。食材今回確認クエリＱ−３はフラグを利用する場合の食材記録レポートＲ−１更新前の確認用のクエリとなっている。なお、食材テーブルＴ−２の今回フラグＮ２ｔは入力用に一時利用されるもので、データベース更新後は一括して削除される仕組みとする。

食材テーブルＴ−２には今回メモＭ１ｔという入力欄が設けられており、ユーザは消費の入力の際にその物品についての消費時のメモを記入することができる。この今回メモＭ１ｔは消費日時などの情報とともに消費履歴である食材記録レポートＲ−１にのみ書き出され、食材テーブルＴ−２の記録としては残らない。

図８の呼名を利用した消費イベント入力の画面例にあるように、ユーザは消費日時テーブルＴ−３と食材入力テーブルＴ−６の入力を連続した文で一括して行うことができる。例として、最初の入力ボックスにあるように、「朝８時にニンジンとレタスとマヨネーズとパンと牛乳とバター」という文が入力された場合、入力時刻の直前の８時が消費日時テーブルＴ−３の日時Ｔ１ｔに記録され、食材入力テーブルＴ−６のニンジン、レタス、マヨネーズ、パン、牛乳、およびバターという呼名Ｉ１ｔはそれぞれ呼名クエリＱ−１の呼名Ａ３ｉと対応の上、食材テーブルＴ−２の対応するデータと紐づけられ、消費されたものとして食材記録レポートＲ−１にデータが時系列に記録される。なお、入力された呼名Ｉ１ｔが既存の呼名Ａ３ｉと一対一の関係でなく、例外的に一対多の関係になる場合、ＩＤ番号Ａ１ｉの古いほうを優先して対応させるなどの仕組みを設けても良い。

入力ボックスや、メールによる文の入力内容は、通常、一回につき一つの意図が入力されることが想定されるが、図８の４番目の入力ボックスの例のように、複数の意図が連続して一つの文に入力された場合については、解析部１０２が文の中から、ユーザの意図を表す複数の文字列を検索し、検索された意図を表す複数の文字列の前後のそれぞれの文字列から、それぞれの意図に従属する文字列を抽出することにより、意図毎に文を区切ることができる。例えば「８時に食べたものは牛乳とバナナとリンゴ９時にお腹の調子レベル２冷蔵庫にあるものは牛乳１月３０日まで」という入力がされた場合、ユーザの意図を表す、「食べたもの」（食材の消費）と、「お腹の調子」（体調の記録）と、「冷蔵庫にあるものは」（在庫の確認）を認識し、更新部１０３は記録先のテーブルを選択する。それらの意図を表す文字列は事前にユーザと合意されたものなので、更新部１０３はユーザの意図を取りこぼすことなく確実に記録先テーブルを選択することができる。

一つの文に複数の意図が含まれる場合、認識されたそれぞれの意図に従属する文字列は通常、意図を表す文字列の後になるが、一部の項目の情報については、例外的に意図を表す文字列の前になる。上記の例では「お腹の調子」の前に「９時」という時間を表す文字列があり、その直後に「に」があるので、事前にそのような場合の処理のルールを定めておくことにより、時間を表す文字列を直後の意図に従属させることができる。 解析部１０２は「８時」の例についても同様に処理し、タイムスタンプによる入力日時および文の中の日時に関する文字列を解析して、食材の消費と、体調の変化というイベントの発生日時をそれぞれ入力当日の８時と９時として認識し、更新部１０３が対応するテーブルにイベントの日時を記録する。８時の食材の消費の内容としては、文から牛乳と、バナナと、リンゴという呼名Ａ３ｉが抽出され、食材テーブルＴ−２に登録されている物品の情報と対応させられた上で、食材記録レポートＲ−１に書き出される。なお、文の中の複数の意図は上記の方法で認識しても良いし、文の区切りを、ユーザの合意の上で、特定のキーワードを文中に含める方法により行ってもよい。

消費済みの物品には消費完了時などに食材テーブルＴ−２の物品にユーザが済Ｆ２ｏというフラグをたてることにより、在庫一覧クエリＱ−７には表示されない状態となる。消費後在庫がなくなる場合は食材記録書出クエリＱ−２または食材今回確認クエリＱ−３を確認するための画面で済Ｆ２ｏのフラグをたてることも可能である。頻繁に買い替えがされる、あるいは常時同じものが在庫として保管されているものについては、物品に済Ｆ２ｏのフラグを立てないことにより、データベース上、常時在庫があるという状態にしても良い。なお、生活情報システム１は一般消費者を主たるユーザとして想定しており、在庫の厳密な個数管理を行わなくても利用可能である。済Ｆ２ｏフラグの入力は、「ジャガイモはもう無い」といった文によっても行うことができ、消費入力の際に「ほうれんそうを全部と豚肉を全部と・・」というように呼名の後に「を全部」という文字列があると、消費入力と同時に済Ｆ２ｏフラグが立つように設定しても良い。

食材テーブルＴ−２において同一物品アイテムの物品在庫が複数ある場合、ユーザが特定のアイテムに予備Ｆ１ｏというフラグをたてることにより、複数在庫のうち予備でない在庫を優先的に消費する扱いとし、予備のフラグが無い場合は目標消費期限の早いもの順、次に購入日の早いもの順に優先的に消費されるなどの扱いをすることもできる。

ユーザは過去に購入した物品について、あるいは新たに購入希望の物品について、販売店Ｒ１ｏまたはブランドＥ２ｏと品名Ｃ２ｓの情報とともに記録の上、食材テーブルＴ−２で「購入予定」を意味するフラグの購入Ｆ３ｏを立てることにより、購入予定リストである買い物クエリＱ−６を表示することができ、販売店Ｒ１ｅや、販売のエリアＲ５ｅや、種類Ｃ１ｅ毎に表示することもできる。購入希望の物品は所在Ｌ３ｏを「購入予定」に設定することで、在庫一覧クエリＱ−７の在庫一覧から除外することができる。「購入予定」のフラグＦ３ｏは物品の消費時あるいは在庫確認時に文に含めて設定することもできるし、図６にあるような在庫一覧等の画面からでもチェックすることができる。図９は購入予定の更新及び確認の例であり、（ａ）は購入予定の情報を更新するための情報端末３００の画面の例で、（ｂ）は（ａ）の入力内容に対応した解析部１０２および、更新部１０３の対応を示すものであり、（ｃ）は既存の購入予定について、ユーザからの確認要求の例で、（ｄ）は解析部１０２および通知部１０５による対応の例であり、最終的に通知部１０５により（ｃ）の出力部分の表示内容が送信がされるという例になっている。

さらに、生活情報システム１により、ユーザは既知の購入予定物品だけでなく、未知の物品についても、推奨物品として購入のための参考情報を得ることができる。知識ベース１１１には他のユーザの経験にもとづく、あるいは他の情報源から得られた推奨物品の情報が蓄積され、分析部１０４は、知識ベース１１１に蓄積された推奨物品のデータから、個別ユーザのデータベース１１０の食材テーブルＴ−２または在庫一覧クエリＱ−７による物品在庫に含まれない推奨物品のデータを抽出し、通知部１０５により、ユーザが使用する情報端末３００に、購入の参考として送信することができる。データベース１１０のユーザの物品在庫に知識ベース１１１の推奨物品が含まれないかどうかの判定は、推奨物品毎に設けられたキーワードにより行う。分析部１０４はさらに、知識ベース１１１からの推奨物品のデータ抽出の際に、食材記録レポートＲ−１等の消費記録や、後述の体調の状況のデータなどを参考にしてもよい。また、通知される推奨物品の件数や、通知の頻度が増えないように、件数と頻度に制限を設けてもよい。

ユーザは在庫を確認したいという意図を表すキーワードと呼名または品名の一部を入力すると、在庫一覧クエリＱ−７により、食材テーブルＴ−２の在庫データを呼び出し、フラグを含めた情報を編集することができる。図７は文による在庫確認画面の呼び出しと物品毎の表示例である。複数の物品が検索された場合は同様の画面が複数表示される。この画面で、在庫の有無を表す済Ｆ２ｒフラグや、備考Ｄ２ｒや、考察Ｄ３ｒや、目標消費期限Ｔ５ｒなどを更新することができる。

図６の（ａ）と（ｂ）はスマートフォン３０２などの情報端末３００の在庫一覧クエリＱ−７の確認画面の例であり、ユーザは情報端末３００で、図６（ｂ）の例のように設定された目標消費期限Ｔ５ｒ順に在庫一覧クエリＱ−７で物品を一覧表示することができる。そうすることにより、ユーザが優先的に消費すべき食品等を確認できる。各物品は保管場所Ｌ４ｅ別、種類Ｃ１ｅ別、品名Ｃ２ｖ別、購入店Ｒ１ｅ別、目標消費期限Ｔ５ｒ別、などにより管理されているため、ユーザは家庭で優先的に消費すべきメニューを考案するなど、目的に合わせて無駄なく、容易に消費計画を立てることができる。

ユーザは図６や、図７の例にあるような画面のチェックボックスにチェックをすることで、食材テーブルＴ−２に各種フラグを立てることができる。 在庫一覧クエリＱ−７では初めに「済」と「予備」にチェックがないものであるＦ１ｎとＦ２ｎが表示されるが、図６にあるように、「済」、「予備」、「購入」などのフラグのチェック欄が表示され、画面上の「済」Ｆ２ｎにフラグを立ててＦ２ｙに変更をすれば以後は在庫が無いものとして在庫一覧に表示されなくなる。

また、ユーザは消費予定物品にも在庫一覧クエリＱ−７の確認画面から食材テーブルＴ−２にフラグを立てることができる。図６の例ではＤ１、Ｄ２、Ｄ３と書かれている項目のＤａｙ１Ｆ５ｒと、Ｄａｙ２Ｆ６ｒと，Ｄａｙ３Ｆ７ｒは、ユーザが物品に予定の初日を１日目として３日間の消費予定のフラグを立てることにより、食材計画クエリＱ−４で、Ｄａｙ１からＤａｙ３にフラグの立てられた物品の一覧を確認をすることができ、物品利用予定の参考とすることができる。その他、目標消費期限Ｔ５ｒとは別に、期限にかかわらず優先的に消費したいものについては、急ぎＦ４ｒのフラグを設定することもできる。

ユーザは家庭での食品等の消費の記録の際に、メニューを記録することにより、それら食品等が何のメニューに使われたかを、考察の項目なども参照しつつ、後日確認することができ、効率的に買い物やメニューの計画を立てることができる。また、その時点の在庫によりどのようなメニューを準備可能かも確認することができる。また、メニューに原材料が紐づいているので，購入時の価格と、消費時の量の記録により、メニュー毎の金額の算定も可能である。この仕組みは食品のメニュー（献立）だけでなく、洋服の組み合わせ（コーディネート）などにも応用することができる。

ユーザによる情報端末３００からの入力に基づき、更新部１０３は物品のデータにメニューを関連付けることができる。消費記録の際、ユーザはまず消費日時テーブルＴ−３でメニューテーブルＴ−１に記録されているメニュー名Ｅ５ｓを選択し、食材入力テーブルＴ−６にそのメニューの材料となる物品の呼名Ｉ１ｔを入力すると、食材記録レポートＲ−１には物品がメニューＥ５ｃと関連付けられて記録される。その後の消費記録の際などには、ユーザが個々に物品の呼名Ｉ１ｔを入力するのではなくメニュー名を呼名Ｉ１ｔとして入力すると、通知部１０５はメニューに関連付けられた複数の物品のデータを食材記録レポートＲ−１の直近のデータから抽出することができ、ユーザの確認を経て、あるいは、ユーザがメニューを構成する物品の確認を行わない場合は、直接更新部１０３がメニューを構成する複数の物品の消費等の記録を一括して行うことができる。別のテーブルにメニューと物品の呼名の組み合わせを登録できるようにして、食材記録レポートＲ−１の直近のデータなどから、あるいは直接、ユーザがメニューを登録できるようにしてもよい。例えば「朝食定番」などのメニュー名から、複数の物品を一括して書き出し、必要に応じ編集できるようにしてもよい。また、通知部１０５はユーザが使用する情報端末からの要求に応じて、物品の呼名から、上記の通り食材記録レポートＲ−１で関連付けられたメニューを検索、あるいはメニュー名から関連付けられた物品を検索し、ユーザが使用する情報端末３００に検索結果を送信することができる。

なお、調理済み食品はメニューと区別して扱うことも可能だが、本実施形態では家庭などでの在庫物品を利用した調理の際の、調理済み食品名もメニューＥ５ｓとして扱う。メニューテーブルＴ−１の備考Ｄ７ｏに調理方法を記録すれば、レシピも記録することができる。例として、ユーザが調理済み食品、例えば家庭で調理した「ハンバーグ」を冷凍庫に保管した場合、更新部１０３は「ハンバーグ」という料理をメニュー名Ｅ５ｏから品名Ｃ２ｏに変換し、変換された「ハンバーグ」という品名を、食材テーブルＴ−２で他の物品アイテム同様に扱えるようにする。その際、食材記録レポートＲ−１で材料として「ハンバーグ」というメニューＥ５ｏに関連付けられた物品を特定できるように備考Ｄ１ｏに書き出す。そして調理済みメニューを後日消費した場合は、ユーザは呼名に代えて、新たに品名として記録されたメニュー名を入力するだけで例えば、「玉ねぎ」や、「小麦粉」などの材料の詳細も含めた情報を消費履歴である食材記録レポートＲ−１に一括して書きだすことができる。在庫管理のためには「ハンバーグ」などの調理済み食品は、材料でなく調理済み食品の呼名で扱えるようにするほうが便利だが、後述の体調との分析などの際には、調理済み食品は、例えばその旨を区別する項目を設けることで、他の物品と区別して記録することにより、「ハンバーグ」そのものではなく、材料の「玉ねぎ」や、「小麦粉」などの物品に置き換えたうえで、分析対象とすることができる。

消費者の食生活などの生活習慣と体調との関係を詳細に分析し、体調改善のための参考情報を得て、生活の快適性を高めるためには、個人別に正確かつ詳細な記録を行うことが望ましい。消費者にとって体調が日々刻々と変化する場合、消費者が体感できる体調のレベルを軽微なものも含め適時に数値化し、数値化された体調のレベルの継続的な記録に基づき、長期的な傾向が確認できれば、生活習慣を改善しようという意欲の向上に役立つ。日々の体調が数値化されることにより、ユーザは長期的な体調の推移を確認することができ、病気とまでは言えないものの不健康状態のサインとなる軽微な体調の推移を見逃しにくくなる。また、不調だけでなく体調が好調な場合も記録できるため、体調に良い影響を与える生活習慣を見つけるための参考とすることもできる。生活情報システム１の利用により、ユーザは生活習慣と体調との因果関係に気づくことができ、生活習慣を改善するための参考とすることができ、客観的で事後検証可能な分析結果を入手することができる。

体調には、ユーザが注意したいと考える、軽微な健康状態の良し悪しや、精神的なものとして気分の良し悪しや、美容的なものとして肌や髪の状態などを含めても良い。内容はテキスト文字列を入力する方法によるので、幅広く自由に設定することができる。気分を体調と同様に記録することにより、快適性をもたらす物品の把握などにも応用することができる。

食品の体調への影響については品名毎には、比較的情報が入手しやすいが、さらに細分化されたブランド毎などでの体調への影響については、販売者による宣伝が主たる情報源であり、客観性の確保が難しいという問題があった。外食店や調理済み食品、いわゆる中食については、味や雰囲気を第三者が評価する仕組みはあるが、消費者個人の体調への影響を数値化して集計し、評価する仕組みはなかった。信頼できる情報が不十分な環境と、個々人の体質の違いを考慮すると、体調改善のためには、一般的な評価をそのまま対象者に当てはめるのではなく、まずは対象者本人の記録を精緻に分析することが求められる。

そこで、生活情報システム１は、家庭内での食品等物品の消費の内容のみならず、外食店や、中食の利用の内容の時系列の記録と、一定の時間間隔毎に数値化された体調の記録との相関関係の分析結果に基づき、体調に影響を与える可能性のある物品や店の情報をユーザに提供する。

体調と関連付けるために消費される物品は食品に限らない。例えば何かの香りであっても良い。また、以下では、主に食品を例にとって説明しているが、生活情報システム１は、食品以外の物も含んだ物品と体調との関係を扱い、わずかな体調の変化も対象とする。例えばサプリメントと体調、化粧品と肌の調子、ヘアケア製品と頭皮の状態、歯磨き粉と歯茎の状態、衣服と肌の調子なども対象となる。さらに、スポーツなどの生活習慣と体調や、各種環境要因と体調との関係などにも応用することができ、各種のデータを組み合わせて分析を行うことができる。

ユーザによる情報端末３００への入力に基づき、取得部１０１は物品の消費の情報だけでなく、体調の状況の情報を受け取り、文による入力の場合は、解析部１０２による処理結果を経て、または情報端末３００の画面から文によらず直接各データ項目に文字列が入力されるか選択される場合は、取得部１０１から直接更新部１０３が取得したデータを元に、データベース１１０のユーザ独自のデータを更新することにより、生活情報システム１は体調と物品の消費の状況を分析し、ユーザにアドバイスを提供する。ユーザ毎に例えば「胸やけ」や、「下痢」といった気になる体調について、例えばそのユーザにとって過去最も不快だった時をレベル３として、不快な体調を経験する都度、数値でレベルテーブルＴ−４にレベルＥ１ｏを入力する仕組みとする。上記の例で、もしも過去最も不快だった時を上回る不快な体調があれば３以上のレベル、例えば５を入力する仕組みとする。レベルＥ１ｏは、例えば、「湿疹」であればレベル２はレベル１の直径の２倍といったように、できるだけ客観的にわかりやすい指標となることを想定している。各レベルの程度を説明する表を作成し、ユーザによるレベル数値の入力にぶれが生じないようにしても良い。

ユーザは体調レベルの入力に先立ち、体調テーブルＭ−９に体調の特徴Ｒ４ｏを登録するものとする。体調には主たる特徴の他に、任意に副次的な複数の特徴を割り当てることができる。例えば主たる体調の特徴が「痒み」であれば副次的な特徴の例として「頭皮」や、「背中」などが考えられる。ユーザは自由にこれらの特徴を登録し、一つの主たる特徴に加えて、複数の副次的特徴を入力することができる。図８には文による体調イベント入力の例が記載されており、「レベル」という語句を含むものが体調イベントの記録の意図があるものとして処理されている。また、特徴の入力がなく「レベル」の語句のみが入力がされているものは、ユーザの事前の設定により「痒み」について記録されるというルールを取り決めてある場合の例となっている。そのような取り決めがなければ文に入力された特徴は体調テーブルＭ−９の特徴Ｒ４ｏと対応の上、そのままレベルテーブルＴ−４の特徴Ｒ４ｓとして、レベルＥ１ｏとともに記録される。

ユーザによる体調イベントの入力が頻繁に行われ、主たる体調の特徴Ｒ４ｏが同一のイベント（以下同種のイベントと呼ぶ）が持続するケースがありうるので、同種のイベントは一定時間毎、例えば、１時間に一度だけカウントされるというルールを設け、分析部１０４は、一定時間内に複数回のイベントが記録される場合、レベルの絶対値の大きい、より強いレベルの体調を優先し、対象となるイベントを特定し、以下で説明する換算値計算の対象とする。それにより、一週間や、一か月といった、個々の入力のタイミングよりも長い期間での体調の推移の分析も可能となる。なお、体調の記録は、その性質によっては、上記の例のような１時間に一度でなく、それより短くしてもよいし、一日あるいは一週間に一度だけのようにしてもよく、長短を調整可能である。レベルが小さいため換算値計算の対象とならなかった体調イベントの影響は、換算値計算の対象となった体調イベントに代表されるとみなし、以下で説明する、原因物質特定のプロセスにも影響させない。

レベルＥ１ｏは体調を数値として把握するためのもので、そのまま集計することもできるが、本実施形態ではその数値を単純に合算するのではなく、その体調をもたらす原因に強弱があるものと仮定し、体調の好不調の度合をよりユーザの体感に近づけるため、さらにレベルから換算値への換算計算を行う。具体的にはレベルＥ１ｏから一定の計算方法に基づき換算値レポートＲ−４の換算値Ａ２ｉを算出し、換算値Ａ２ｉの集計及び分析を行う。図１０は入力されたレベルＥ１ｏから換算値Ａ２ｉの計算例と換算値のグラフの表示例を示している。この例では、レベルをＬ、換算値をＩとした場合、数式
Ｉ ＝ Ｌ³／５
により計算を行っている。この場合、図１０（ｂ）にあるように、レベル２の場合の換算値は１．６、レベル３の場合の換算値は５．４、レベル４の場合の換算値は１２．８と計算される。レベルの入力は小数点以下も可能であり、例えばレベル０．５という入力も可能であるため、例えば不快な体調が改善しつつある局面で、レベル１以下の入力の機会が増える状況などにも柔軟に対応することができる。この方法は不快レベルの逆に好調レベルとして、場合によっては、レベルの正負を逆転することにより好調度を測る目安として利用できる。なお、上記の例のような数式を利用する目的は主観を数値に置き換えて分析することにあるので、実施例のように設定しても良いし、ユーザにとって最も体調を表していると感じられるように数式を変更しても良い。

図１０（ａ）は一日のうちの同種の体調イベント、例えば主たる体調の特徴Ｒ４ｏが「痒み」のものを時系列にし、一定の時間間隔は１時間毎とした場合の例である。この例の場合は１２月１２日にレベルテーブルＴ−４に記録された７つの体調イベントのうち４つが換算値計算の対象となる。この例の場合は、計算期間内、この場合は一日のうちのレベルの高い順に対象とする、ただし既に対象となったものとの間隔が１時間未満のものは対象としない方法で、対象となる体調イベントを特定している。図１０（ｂ）は、上記の数式に基づく、レベルから換算値の対応関係を示す計算例であり、図１０（ｃ）は（ａ）で計算対象となったレベルを換算値レポートＲ−４で集計し（ｂ）の方法で換算値Ａ２ｉに置き換えた上で、右列では、換算値を日毎に合算している。図１０（ｄ）はそのようにして集計された日々の換算値を１年以上の長期間にわたり集計し、グラフ化した場合の例である。グラフに移動平均線が表示されており、ユーザは日々の変動に一喜一憂することなく、長期的な傾向を確認することができる。

なお、体調と物品の消費の状況の詳細な分析のためには、ユーザが日常生活で、消費内容を記録したい物品について、情報端末３００から物品の購入から消費までの状況を入力することが望ましいが、少なくとも消費内容の記録があれば体調との比較、あるいは目標消費ペースとの比較は可能である。その場合、ユーザは物品の消費内容として、日時Ｔ１ｔと物品アイテムを認識するための呼名Ｉ１ｔ等の情報を入力する必要がある。それにより、物品のブランド、販売店または飲食店毎の体調への影響の評価結果を確認することができる。

分析部１０４は、ユーザが体調イベント以前に消費した食材等の物品について、例えば６時間など、事前にユーザが選択した任意の時間（以下観察時間と呼ぶ）で区切り、データベース１１０から対象の体調イベント発生時から６時間などの、観察時間以内に消費された物品を抽出し、物品の評点が高いものを原因疑い物品として抽出する。当初短い時間からスタートし、その後の状況に応じ、観察時間を例えば１日、次に１週間などといった要領で拡大するなど調整することもできる。観察時間を切り替えることにより以下で説明する物品アイテムの評点は変動する。

物品アイテムには、消費後の体調レベルの発生状況に応じて、評点レポートＲ−５で体調原因の可能性の度合いを表す可能性％Ａ４ｉが付与され、物品アイテム毎に最新の情報が保たれる。例として可能性％は以下のように変化する、新しい物品の可能性は不明なので５０％からスタートし、一回目消費後の観察時間内に体調が不良であることを意味するレベル数値が入力され（以下そのような場合を「問題」と呼ぶ）なければ、可能性を０％にする。観察時間内に問題がでなければ、その間消費された他のすべての物品の可能性％も０になる。観察時間内に問題が出れば、その間に消費された物品の可能性％に、１００％を各物品の可能性％の割合で按分したものを加算する。その結果１００％を超えた物品の可能性％は上限の１００％に置き換える。

例として、観察時間内に２個の物品を消費し、問題があった場合、その時点で１つ目が５０％、２つ目が０％の物品アイテムであったとすると、１つ目だけに％が加算され、１００％を超えるが、最大値は１００％に据え置く。１００％になった時点で、その物品は特定の体調の原因である可能性が最大となる。可能性％が１００％になった時点で、消費しないことが望ましいが、他の物品とともに消費して問題が出た場合、他の物品の可能性％は変動させず、可能性％が１００％になっていた物品が問題の原因であるとみなす。なお、一つの体調イベントに対し、原因となる可能性のある物品は一つとは限らない。

なお、上記の可能性％の計算方法に加え、特定の物品の消費を少量に抑えて体調の反応をテストする場合や、毎回の消費量に変動があり、都度量を記録している場合や、既に別の情報源により体調への影響が知られている物質が含まれている場合などは、食材テーブルＴ−２の今回メモＭ１ｔにその旨を意味するキーワードを別途定めた上で、含めるなどの方法により別の扱いをしても良い。また、体調不良が頻繁である場合などには、ある一定以上のレベルの体調イベントのみを可能性％Ａ４ｉを変動させる要因として扱ってもよい。あるいは、食品の鮮度を反映させる等の目的で、入手日からの経過日数を可能性％Ａ４ｉを変動させる要因として扱う、あるいは例として食材テーブルＴ−２に、食品の目標消費期限Ｔ５ｏの他に項目を設け、食品に表示されている賞味期限を記録し、消費日から賞味期限日までの残日数を、可能性％Ａ４ｉを変動させる要因として扱う、などの計算方法を追加しても良い。

体調イベントから遡った観察時間内の物品の消費について、可能性％がＡ４ｉのそれぞれの物品アイテムの評点Ａ６ｉは、体調イベント時の換算値Ａ２ｉを、最新の可能性％Ａ４ｉで物品アイテムに按分した食材記録レポートＲ−１の評点Ａ５ｉを、過去の記録に遡り、物品アイテム毎に平均したものである。この計算方法は一例であり、観察時間内で例えば物品の消費から近いイベントの評点を高くするなどの、調整を加えても良いし、知識ベース１１１を参照して、体調の特徴Ｒ４ｏと観察時間内での時間経過に応じた変化をつけても良い。体調イベントの原因となる物品の候補は体調イベントのタイミング前の観察時間内で消費された物品のうち評点Ａ６ｉの高いものとなる。

食材記録レポートＲ−１において、物品アイテムに対する可能性％Ａ４ｃはその時点のものが記録されているが、評点Ａ５ｉは評点レポートＲ−５の最新の可能性％Ａ４ｉにより計算され更新される。評点レポートＲ−５の物品アイテム毎の評点Ａ６ｉは食材記録レポートＲ−１の評点Ａ５ｉの平均値として計算される。評点Ａ６ｉの大きい順に影響が大きく体調の変動の原因物質となる可能性が高いと考えられる。

図１１（ｅ）は物品アイテムの消費状況と、図１０（ａ）の例を前提とした、問題の有無による可能性％の推移の例で、特定の物品アイテムを消費してから例として観察時間が６時間の場合、６時間以内に体調不良の問題を示すレベルが記録されたかどうかに応じて、物品消費前の可能性％Ａ４ｃをどのように変化させたかを示している。可能性％は体調イベントの状況に応じ変化するが、分析時点で図の「可能性％更新状況」に記載のある通り、最新の可能性％Ａ４ｉを用いて計算する。

この例では、物品アイテム１と２は消費後６時間以内に問題がなかったので、いずれも可能性％は０％に更新される。１２時に消費された物品アイテム３から８は消費後の１３時と１４時１０分に問題があったので、可能性％は１００％を消費前の可能性％の比率で按分したものが追加され増加した。物品アイテム４と８は１７時３０分にもその他の物品とともに消費された。最初に消費された物品アイテム１も再度消費された。１７時３０分の消費についてはその後の１８時２０分と２１時１５分に問題があったので、可能性％は１００％を消費前の可能性％の比率で按分したものがそれぞれの物品アイテムに追加された。物品アイテム１は計算前が０％だったため、計算後も０％で変わらず、物品アイテム９は計算結果が１３１％となっているが、上限が１００％であるため、１００％に置き換えられる。

図１２（ｆ）は図１０（ａ）で換算値計算の対象となった体調イベントについて、記録されたレベルから図１０（ｂ）の計算例に従って換算値を計算し、図１１（ｅ）で「可能性％の更新後状況」が最新となっている更新後の可能性％を、それぞれの物品アイテム消費後６時間以内の体調イベントに割り当てたもので、図１２（ｇ）では各体調イベントの換算値を、図１２（ｆ）の体調イベントに割り当てられた、物品アイテムの可能性％で按分計算した体調イベント毎の評点Ａ５ｉを物品アイテム毎に平均し、最新の評点Ａ６ｉを計算している。このように、評点レポートＲ−５では、物品アイテムの評点Ａ６ｉとして最新の情報が保持される。この例では物品アイテム５がこの日の体調不良の原因の可能性が最も高く、次に物品アイテム６と４が続く。

物品アイテム９のように可能性％が高くても、消費後の不調のレベルはさほどではないものは、評点は比較的小さくなっている。他の例として、例えば過去に５回以上など可能性％が０％であった物品アイテムについて、新たな物品を消費した後に問題が発生し、当該物品アイテムの可能性％が１００％になった場合は、原材料が変化した可能性があるため、備考Ｄ１ｏにその旨のフラグを含めたり、過去に問題がなかった物品は終了物品として、食材テーブルＴ−２から移動するなどして、新たな物品を、過去に消費された物品とは別物品アイテムであるかのように扱うこともできる。

なお、図１１は、物品の消費イベントの発生時刻を単純化した例となっているが、変化形として、物品消費イベントが特定の体調イベントから遡った観察時間内に同時に一度だけでなく、時間を変えて複数回行われるケースがある。そのようなケースでは、観察時間内の対象となる物品消費全体に１００％を按分した％が加算される。例として図１１の物品アイテム３と、４の消費時刻が１２：００ではなく、それぞれ１１：５０と、１２：１０であったとしても、評点の計算結果は変わらない。観察時間内に複数回の換算値計算の対象となる体調イベントがあったとしても、物品アイテムには一度だけ、１００％を按分した％が加算されるものとする。観察時間内に複数回の換算値計算の対象となる体調イベントがあった場合、物品消費後の観察時間内での換算値が最大になる体調イベントを基準として、消費された物品アイテムのグループを作り、１００％を按分計算する。図１０（ａ）の１３：００と１４：１０の２つの体調イベントを例にとり、観察時間を６時間とすると、それぞれの体調イベントについて、９：００より後、と１０：１０より後が観察時間となるが、１４：１０の体調イベントのレベルの方が１３：００のものより高いので、１００％の按分計算の対象となる消費された物品アイテムのグループは、９：００から１０：１０までのグループと、１０：１０から１４：１０までのグループの２つに分けられる。なお、観察時間内に複数回の同一物品アイテムの消費があった場合にも同一物品アイテムには一度だけ、１００％を按分した％が加算されるものとする。

通知部１０５は分析部１０４による分析結果から評点Ａ６ｉの高い物品について、事前に設定した方法により、例えば日毎に、前日に消費されたもののうち最も評点の高いものや、評点の高い順に３つなどの、物品アイテムを抽出し、ユーザが使用する情報端末３００に通知を送信することができる。ユーザは通知に基づき、該当の物品アイテムの消費を減らす、あるいは不調の逆に好調の原因となっている可能性が高い物品アイテムの消費を増やすなどの、物品消費の参考とすることができる。図１４（ａ）は、ユーザが使用する情報端末３００から、具体的な問い合わせ内容を入力すると、回答が出力される例を示している。

ユーザは外食店や、中食の利用の際には、消費日時Ｔ２ｏと、店名Ｒ３ｏと、メニュー名Ｅ４ｏと、内容Ｄ６ｏとして主要な、または気になる原材料名や、産地や、量などの特徴を外食テーブルＴ−５に入力する。外食や中食では消費者がすべての原材料を把握することは難しいが、原材料の質やメニュー毎の組み合わせ、調理方法などは、店毎に安定的であると仮定し、ユーザによる必須入力事項は、店名とメニュー名にとどめ、原材料の入力は必須事項とせず気づいたものにとどめる。図８の４番目の入力ボックスはそのような入力内容の例となっている。同じ店の同一メニューＥ４ｏ名で、二回目以降は内容Ｄ６ｏに原材料の記載がない場合は、前回の記載内容を参照する扱いにしても良い。外食店や、中食店の利用の場合には、入力のある原材料だけでなく、店そのもの、あるいは店のメニューそのものが分析対象となる。詳しい原材料の入力がないとしてもその店を利用した後の体調についての入力内容から、物品アイテムと同様に、ユーザ毎にデータが分析され、例えば、同じ店の同じメニューを複数回食べた後に決まって体調が悪くなる場合、その店のそのメニューは要注意である旨の分析がされる。

外食と中食の場合の内容Ｄ６ｏに記録された原材料と、家庭で消費される場合の食品等の物品アイテムと、食材テーブルＴ−２の備考Ｄ１ｏに記録された原材料は、分析部１０４による、さらに詳細なレベルでの相関関係の分析に用いられ、同一の文字列が検出されれば、同一品名の食品を摂取した場合と同様に分析対象とすることができる。例えば外食の際にメニューは「ホットケーキ」で内容に原材料として「はちみつ」の記載があるものとする。家庭で消費される物品の品名に「はちみつ」があったとする、その場合、どちらも「はちみつ」を摂取したものとして、体調との相関関係の分析対象とすることができる。

食材記録レポートＲ−１は食材テーブルＴ−２の物品のうち、消費されたものを時系列に記録したものである。食材とレベルレポートＲ−２は食材記録レポートＲ−１、外食テーブルＴ−５およびレベルテーブルＴ−４を統合したものである。反応確認レポートＲ−３は検索のために呼名Ｉ４ｏの項目に入力された特定の物品名の一部により、まずは統合された食材とレベルレポートＲ−２から物品の消費イベントを抽出、次に抽出された物品の消費イベントから一定時間内の体調データを抽出して作成されたものである。反応確認レポートＲ−３抽出のために、呼名Ｉ４ｏの項目に入力される特定の物品名の一部は、呼名クエリＱ−１における呼名Ａ３ｉだけでなく、品名Ｃ２ｗや、備考Ｄ１ｖや、今回メモＭ１ｖや、外食店のメニュー名Ｅ４ｖや、内容Ｄ６ｖに含まれる原材料名等から部分一致で検索を行うものであり、ユーザが過去に入力した内容に該当文字列が含まれれば漏れなく抽出することが可能である。

反応確認レポートＲ−３を利用し、図１４（ｂ）は文により物品消費後の体調を確認する例で、図１３は物品消費後の体調の確認結果の出力を表形式で行う場合の例となっている。図１４（ｂ）の例にあるように、ユーザが過去の物品の消費について、物品に関するキーワードを入力すると、通知部１０５は過去の物品の消費実績とともに、物品の消費日時から一定時間内の体調の情報をデータベースから抽出し、データを送信することにより、結果が情報端末３００に一覧表示される。経過時間はユーザにより別に指定されなければ観察時間とする。図１４（ｂ）は観察時間が６時間の場合の例となっている。

個人の体調に影響を与える可能性のある食品等の情報は膨大で、個人や医療関係者が網羅的に情報を収集するのは難しいため、生活情報システム１は知識ベース１１１に蓄積された、他の消費者の実績データを利用する。分析部１０４は個別ユーザの物品の消費と、体調の状況の相関関係の分析結果などのデータのうち、事前にユーザからデータ利用の許可を得ている範囲内で、他のユーザの参考のために、データベース１１０から得られた情報を知識ベース１１１に蓄積する。さらに、知識ベース１１１には、生活情報システム１外の情報源から収集された消費者のデータや、物品の原材料に関するデータや、人体に取り込まれた物質の動態に関するデータや、推奨商品に関するデータ等も蓄積される。

分析部１０４はデータベース１１０に記録されているユーザによる物品の消費と、体調の状況の相関関係の分析の際に、知識ベース１１１のデータを参照し、個別ユーザの記録からだけでなく、同様の特徴を持つ体調に影響を与える、品名や物品アイテムなどについて、他の消費者のデータを参照することにより、個別ユーザの記録が十分に蓄積される前の早い段階で、ユーザの体調に影響を与える可能性が高い物品アイテムを推測し、通知部１０５からユーザへの参考情報を送信することができる。

また、分析部１０４が知識ベース１１１に格納されている、他の消費者の物品の消費と体調の実績データの相関関係を、機械学習した結果を用いて、データベース１１０に記録されているユーザの消費記録と体調のデータから、ユーザの体調に影響を与える可能性が高い物品や、特定の物品の消費後に、体調に影響が表れる可能性が高いタイミングを予測し、ユーザに参考情報として提供してもよいし、上記の可能性％や評点の計算方法に反映させても良い。

生活情報システム１は、物品の消費以外に体調に影響を与える要因として、例えば「ランニング」などの、その他の生活習慣や、各種環境要因も物品の消費と同様に記録と分析の対象とすることができる。なお、生活習慣や物品の消費が長時間にわたる場合、時間や期間を、例として「○○から○○まで○○をした」、あるいは「今日から毎日○○をする」といった文で、入力することもできる。

食品等に含まれる物質も管理の対象としたい場合、ユーザはまず、例えば、「たんぱく質」や、「カルシウム」などといった消費量を確認して管理の対象としたいと考える物質を指定することができる。管理の対象とする物質が、物品アイテムそのものでなく、物品アイテムの含有物である場合は、含有量を計算するために、含有物換算テーブルＭ−１０の含有物Ｅ６ｏに記録されていることが前提であり、含有物換算テーブルＭ−１０は別途ユーザからの要望に応じて設定しても良いし、分析部１０４が知識ベース１１１を参照して設定してもよい。

ユーザは食品等の消費量については、例えば「卵を１個と豚肉を１５０グラムと・・」などの文によって入力することができ、そのようなユーザが使用する情報端末３００への入力に基づく食材記録レポートＲ−１の物品の量Ｑ３ｏについてのデータと、含有物換算テーブルＭ−１０の量Ｑ４ｏと、含有物Ｅ６ｏと、含有量Ｑ５ｏの対応関係のデータを用いて、更新部１０３は消費された物品に含まれる含有物Ｅ６ｏの量を計算し、食材記録レポートＲ−１の、今回メモＭ２ｏに、対応する物品の消費の際の、含有物名と、計算された含有量を記録し、分析部１０４がそれらを集計する。なお、食材記録レポートＲ−１の「今回メモ」や「備考」の項目は、情報の内容を示す文字列や符号を含めることにより、複数の目的のために利用することができ、分析部１０４や、通知部１０５が目的に応じ必要な情報を抽出することができる。分析部１０４はこれらのデータから、特定の物質の摂取量の推移と体調の推移との相関関係を分析し、通知部１０５が分析結果をユーザが使用する情報端末３００に送信する。

含有物換算テーブルＭ−１０の品名Ｃ３ｏに対応する含有物Ｅ６ｏは、品名Ｃ３ｏが食材記録レポートＲ−１の品名Ｃ２ｏと一致する場合に計算対象となるが、より詳細に換算計算を行うために、品名だけでなく、情報が得られるものについては、物品アイテムについての換算テーブルを設けても良い。計算の元となる物品の量は食材入力テーブルＴ−６の量Ｑ３ｔに例えば３グラムなど、数値と単位の組み合わせとして入力され、食材記録レポートＲ−１の量Ｑ３ｏに転記される。含有物換算テーブルＭ−１０の量Ｑ４ｏには例えば「１グラム」などの基準量が記録されており、品名Ｃ３ｏ毎の、基準量当たりの含有物Ｅ６ｏと含有量Ｑ５ｏから換算計算がされる。なお食材記録レポートＲ−１に記録された、含有物の接種時の含有量のデータは、分析部１０４による体調の状況との相関関係の分析の他、後述の消費目標と実績との比較分析にも使われる。

管理の対象としてユーザに指定された特定の物質と、体調との比較を行うためには、例として、図１０（ｃ）のように計算された、日々の体調の換算値合計の推移と、特定の物質の摂取量合計の推移を比較することによって行うことができる。例えば、日々の物質の摂取量合計が増加する際、体調の換算値合計も増加する傾向にあれば、その物質の摂取は体調の悪化をもたらしていることが推測できる。この例のように、体調の換算値の集計を日毎に行う場合、集計のタイミングを統一するために、物質の摂取量の集計も日毎に行う。例として、日々の特定の物質の摂取量合計の増加率と、日々の体調の換算値合計の増加率の比率の平均からそのような相関関係を推測することができる。集計のタイミングは週毎や月毎であってもよいし、管理対象となる物質や体調の性質に応じ長短を調整可能である。なお、管理の対象とする物質は、一つまたは複数の物品アイテムの含有物であってもよいし、一つまたは複数の物品アイテムそのものであってもよい。

摂取後、作用が最大となるまでに時間を要する物質や、人体への作用が長く続き、通常の摂取状況では蓄積される傾向にある物質の場合は、接種量だけでなく、知識ベース１１１に格納された、物質の接種直後に、体調への影響が最大になるタイミングや、半減期等に関する情報を用いて、物質の各時点での体内蓄積量を推計し、体調との比較を行うことができる。さらに性別、体重、身長、血圧、体脂肪率など、健康に関する測定値を別にユーザから入手し、物質の体内蓄積量の推計値を調整してもよい。分析部１０４は、ユーザにより指定された、特定の物質の摂取量を増減させた場合の体調を、ユーザの過去の実績、または知識ベース１１１に格納されたデータから、機械学習により予測してもよい。対象となる消費者により消費される物品に含まれる特定の物質の体内での推定蓄積量は、消費時に消費量の入力がされない場合であっても、知識ベース１１１から得られる、品名毎の一回当たりの標準的接種量から概算値を計算することもできる。

消費者にとって、複数の販売店で多数の物品を購入する場合、どこの店舗のものがどのようなものだったのかすべてを記憶するのは難しく、記憶に頼って購入をしていると、無駄につながりやすいが、生活情報システム１では、ユーザが個人の主観に基づき、物品や店のメニューなどについて、考察の項目に、コメントを入力することができ、常に最新の情報を参照することができ、考察一覧が、店毎や、物品の種類毎や、品名毎などに表示されることにより、ユーザは再購入の際の参考とすることができる。さらに、金額の情報も入力されている場合は、物品や店のコストパフォーマンスを確認することもできる。

具体的にはユーザが店テーブルＭ−４の考察Ｄ８ｏと、メニューテーブルＴ−１の考察Ｄ９ｏと、食材テーブルＴ−２の考察Ｄ３ｏなどの「考察」の項目に、コメントを入力する。例えばある食品を生で食べると毎回アレルギー症状が出るなど、体調不良になる場合は、「加熱しないと危険」など、そのユーザにとってわかりやすいコメントを記載することができる。図１３の例にあるような、反応確認レポートＲ−３の画面では、ユーザが最新のコメントである考察（Ｄ３ｒ、Ｄ４ｒ、Ｄ５ｒ）を参照し、編集することができる。食材への考察Ｄ３ｏは食材消費時にＤ３ｃとして食材記録レポートＲ−１に書き出されるが、Ｄ３ｃは書き出し時の記録であり、最新の情報ではない。Ｄ３ｏは常に最新の情報で上書きされ、Ｄ３ｒはその内容と一致する。他の種類の考察も同様である。外食店への考察Ｄ５ｏはメニューについて行う。一つの店で一つのメニューしか食べることがなければ、考察Ｄ５ｏの内容がそのまま店へのコメントとなるが、複数のメニューを食べる機会があれば、一つの店に複数のコメントがつくことになる。

考察は、ユーザの経験と考察に基づくものだけではなく、知識ベース１１１からも参考情報を追加することができる。上記の考察の項目に加えて、「おいしい」、「良い」、「悪い」、「要注意」、「要観察」、「リピート無し」などのフラグを設け、一つのアイテムにつき複数選択可能としても良い。これらは、いずれも入力必須事項ではない。

生活情報システム１は、ユーザが摂取量を増やしたほうが良いもの、減らしたほうが良いもの、あるいは一定のペースを保ったほうが良いと考えるものについて、消費実績を記録することにより、ユーザが簡単に特定の物品の消費のペースと、あらかじめ設定してある目標消費ペースとの比較をすることが可能となり、目標に近づけようとする動機付けとなる。例えば禁煙を目指す場合などや、薬の飲み忘れを防ぐといった目的の場合にも利用できる。

まず、ユーザは管理の対象としたいと考える物品について、目標消費ペースを設定する。均等なペースで消費したい物品、例えばサプリメントであれば一日３回一粒ずつという目標消費ペースを設定する。あるいは、消費量を削減したい物品、例えばタバコであれば段階的に削減して一定期間後に０にしたいという目標消費ペースを設定する。この設定は文によって行うか、端末の画面から数値を入力し、選択肢から方法を選択してもよい。分析部１０４は対象物品について目標消費ペースから計算された日々の目標消費量と、ユーザにより入力され、食材記録レポートＲ−１に記録された消費量の実績を比較し、通知部１０５は比較結果に基づくアドバイスや、ユーザによる入力の頻度が予想される頻度を下回る場合、ユーザに消費の有無を確認するための通知などをユーザが使用する情報端末３００に送信することができる。

この方法は物品そのものでなく、含有物換算テーブルＭ−１０を用いて物品に含まれる含有物Ｅ６ｏに応用することができる。その場合、ユーザの要望に基づき特定の物質に消費目標を設定する。例えば一日に複数の異なる物品が消費されたとしても、物品に含まれる目標値を設定したい物質が共通であれば、それらの物品の消費量が、対象となる物質の含有量に換算されたうえ、一日の消費量として集計され、目標値と比較される。

図１７（ａ）の「ビタミン」の例はユーザが例えば一日３回食後に一粒ずつビタミンのサプリメントを飲むことを目標に設定している例で、２１時の段階で消費実績の入力がなかったため、確認を求める通知を表示している。ユーザによる回答例では時間の入力はないものの「３回」という回数が入力されたため、その時点で消費記録がされ目標回数との差異がなくなったため問題がないものとして扱われている。図１７（ｂ）のタバコの例は、消費量は箱によって把握されるが、分析部１０４がさらに詳細に１日当たりの消費本数を計算し、ユーザに参考情報としてアドバイスを送信している例である。ユーザは１本毎に消費実績を入力することもできるが、図１７（ｂ）の例のようにタバコの箱単位で入力を行うこともできる。この例では「箱」が２０本入りの「〇〇ブランドのタバコ」という物品アイテムを表す呼名となっており、毎回の本数を記録しなくても、ユーザは「箱を開けた」という文だけの入力で、消費のペースを記録することができる。図１７（ｃ）は図１７（ｂ）の例の方法で入力された消費実績に基づき、タバコの箱の消費間隔の時間をグラフ化した例であり、消費間隔が大きくなるほど目標に近づいていることが確認できる。通知部１０５はこのようなグラフを、ユーザが使用する情報端末３００に表示させるためのデータを送信することができる。

１ 生活情報システム
１００ サーバ
１０１ 取得部
１０２ 解析部
１０３ 更新部
１０４ 分析部
１０５ 通知部
１１０ データベース
１１１ 知識ベース
２００ 通信ネットワーク
３００ 情報端末
３０１ コンピュータ
３０２ スマートフォン
３０３ スマートスピーカー

Claims (14)

1. 物品の情報を管理するための情報処理システムであって、
   ユーザ毎に定められたルールに従って入力された物品に関する文を受け取る取得部と、
   前記文の中の、データベースに動作を指示するための所定の文字列を認識することによりユーザの意図を特定し、残りの文字列から物品の呼名を抽出する解析部と、
   前記特定されたユーザの意図に基づき、データベースのユーザ独自のデータが格納された種類別のテーブルからユーザの意図に対応した種類のテーブルを選択し、前記文から抽出された一つまたは複数の物品の呼名を、前記選択されたテーブルのユーザ毎に登録された一つまたは複数の物品の呼名と対応させることにより、一つまたは複数のユーザ独自の物品のデータを抽出し、データベースを一括して更新する更新部と、
   ユーザが使用する情報端末に通知を送信する通知部を備え、
   前記ユーザ毎に定められたルールは、ユーザが意図を表し、データベースに動作を指示するための文字列を事前に指定し、物品を特定するためのキーワードである呼名を事前にデータベースに登録し、ユーザの意図の種類に少なくとも、物品の取得の記録と消費の記録を含む情報処理システム。
2. 物品の情報を管理するための情報端末であって、
   ユーザ毎に定められたルールに従って入力された物品に関する文を受け取る取得部と、
   前記文の中の、データベースに動作を指示するための所定の文字列を認識することによりユーザの意図を特定し、残りの文字列から物品の呼名を抽出する解析部と、
   前記特定されたユーザの意図に基づき、データベースのユーザ独自のデータが格納された種類別のテーブルからユーザの意図に対応した種類のテーブルを選択し、前記文から抽出された一つまたは複数の物品の呼名を、前記選択されたテーブルのユーザ毎に登録された一つまたは複数の物品の呼名と対応させることにより、一つまたは複数のユーザ独自の物品のデータを抽出し、データベースを一括して更新する更新部と、
   ユーザに通知を行う通知部を備え、
   前記ユーザ毎に定められたルールは、ユーザが意図を表し、データベースに動作を指示するための文字列を事前に指定し、物品を特定するためのキーワードである呼名を事前にデータベースに登録し、ユーザの意図の種類に少なくとも、物品の取得の記録と消費の記録を含む情報端末。
3. 前記解析部が前記文を所定の語句または記号で分割することにより、複数の物品の呼名を抽出し、
   前記ユーザ毎に定められたルールは、ユーザが文を分割するための語句または記号を事前に指定し、データベースに登録する請求項１に記載の情報処理システム。
4. 前記解析部が前記文の中の物品の呼名の後に入力された、物品に関する情報の項目を表す文字列を認識することにより、その後に続く項目の内容を抽出し、
   前記更新部が前記呼名に対応する物品についての項目の内容を記録する請求項１に記載の情報処理システム。
5. 前記解析部が前記文の中から、ユーザの意図を表す複数の文字列を検索し、前記意図を表す複数の文字列の前後のそれぞれの文字列から、それぞれの意図に従属する文字列を抽出し、意図毎に前記文を区切り、
   前記更新部が前記ユーザ毎に事前に定められたルールに従って、前記区切られた文をそれぞれデータベースの意図に対応した種類のテーブルに対応させる請求項１に記載の情報処理システム。
6. 前記解析部が、物品の購入記録または在庫確認のために入力された文の中の、物品の呼名の後の、日付を表す文字列を日付のデータに変換し、
   前記更新部が前記変換された日付のデータを目標消費期限として、データベースの対応するテーブルに記録し、
   ユーザが使用する情報端末からの要求に応じて、前記通知部が物品の目標消費期限順の一覧を表示するための情報をユーザが使用する情報端末に送信する請求項１に記載の情報処理システム。
7. ユーザが同一物品アイテムの物品を複数所有する場合、前記通知部が、ユーザが前記物品アイテムを消費可能な間隔である最短許容消費間隔と、前記物品アイテムの個々の物品の目標消費期限から個々の物品についての推奨消費期限を計算し、ユーザが使用する情報端末からの要求に応じて、推奨消費期限を表示するための情報をユーザが使用する情報端末に送信する請求項６に記載の情報処理システム。
8. ユーザが使用する情報端末からの要求に応じて、
   前記更新部が場所別、および種類別に物品のデータを記録し、
   前記通知部が場所別または種類別に物品の在庫一覧を表示するための情報をユーザが使用する情報端末に送信する請求項１に記載の情報処理システム。
9. ユーザが使用する情報端末からの要求に応じて、
   前記更新部が販売店別またはブランド別に物品のデータを記録し、物品のデータにユーザが購入予定であることを意味するフラグを設定することにより、
   前記通知部が販売店別またはブランド別に購入予定物品を表示するための情報をユーザが使用する情報端末に送信し、
   データベースに記録された物品の在庫の状況に応じて、知識ベースに蓄積された物品の情報を参照する分析部を備え、
   前記通知部が推奨物品の情報を、ユーザが使用する情報端末に送信する請求項１に記載の情報処理システム。
10. ユーザの入力に基づき、前記更新部は物品のデータにメニューを関連付けることができ、ユーザにより物品の呼名に代えてメニュー名が入力されると、メニューに関連付けられた複数の物品のデータを一括して更新することができ、
    前記通知部はユーザが使用する情報端末からの要求に応じて、関連付けられた物品の呼名からメニューを検索し、あるいはメニュー名から関連付けられた物品を検索し、ユーザが使用する情報端末に検索結果を送信する請求項１に記載の情報処理システム。
11. 事前にユーザの要望に基づき管理の対象とする物質を特定の上、ユーザが入力する物品の量についての記述から、ユーザが消費した物品に含まれる特定の物質の量を計算し、特定の物質の摂取量の状況と体調の状況との相関関係を分析する分析部を備え、
    前記通知部が分析結果をユーザが使用する情報端末に送信する請求項１に記載の情報処理システム。
12. 前記解析部がユーザにより入力された文の中の、意図を表す文字列の前に、日時を表す文字列がある場合は、当該文字列を日時のデータに変換し、
    前記更新部が前記変換された日時のデータを文の入力時点に代えて、実際のユーザの生活イベントの発生日時として、ユーザの意図に応じてデータベースの対応するテーブルに記録し、
    前記通知部がユーザが使用する情報端末からの要求に応じて抽出したユーザの生活イベントのデータを、ユーザが使用する情報端末に表示させるために送信する請求項１に記載の情報処理システム。
13. ユーザに物品の消費についてのアドバイスを提供するための情報端末であって、
    ユーザが消費した物品の呼名と消費量を表す文字列を情報端末に入力すると、消費に関する目標との比較結果を出力する請求項２に記載の情報端末。
14. 物品の情報を管理するためのプログラムであって、
    ユーザ毎に定められたルールに従って入力された物品に関する文を受け取るステップと、
    前記文の中の、データベースに動作を指示するための所定の文字列を認識することによりユーザの意図を特定し、残りの文字列から物品の呼名を抽出するステップと、
    前記特定されたユーザの意図に基づき、データベースのユーザ独自のデータが格納された種類別のテーブルからユーザの意図に対応した種類のテーブルを選択し、前記文から抽出された一つまたは複数の物品の呼名を、前記選択されたテーブルのユーザ毎に登録された一つまたは複数の物品の呼名と対応させることにより、一つまたは複数のユーザ独自の物品のデータを抽出し、データベースを一括して更新するステップと、を実行させ、
    前記ユーザ毎に定められたルールは、ユーザが意図を表し、データベースに動作を指示するための文字列を事前に指定し、物品を特定するためのキーワードである呼名を事前にデータベースに登録し、ユーザの意図の種類に少なくとも、物品の取得の記録と消費の記録を含むプログラム。

Images