(57)【要約】【課題】ユーザの近辺において購入できる食材と、それを用いた献立を、複数の店舗間におけるリアルタイムな食材情報を元に提案する、情報プランニングサービス処理方法とこれに用いるプランエージェント装置を提供すること。【解決手段】ユーザ端末から送信されるユーザの帰宅時刻と場所を受信して、ユーザの献立利用履歴をもとに適切な献立リストを選択し（１１，１２，１４の機能）、リアルタイムな店舗の食材在庫情報を受信して、店舗の位置情報とユーザの帰宅場所とを照合し、ユーザが購入可能な店舗を絞り込む（１３，１５の機能）とともに、選択した献立リストの候補の中から上記食材在庫情報にある食材を組み合わせることによって、献立リストの必要食材が充足する献立リストを選択して、上記選択した献立と食材とをユーザ端末に送信する（１１の機能）ことを特徴とするもの。【選択図】　　　図１
2004102670.tif 000002
【特許請求の範囲】
【請求項１】
ユーザが近辺で購入できる食材と、それを用いた献立を提案することにより、帰宅途中における食材の購入並びに提示された献立のレシピに従って帰宅後調理することを支援するサービスを実現するための情報プランニングサービス処理方法であって、
ユーザ端末から送信されるユーザの帰宅時刻と場所を受信し、
ユーザの献立利用履歴をもとに適切な献立リストを選択し、
リアルタイムな店舗の食材在庫情報を受信して、店舗の位置情報とユーザの帰宅場所とを照合し、
ユーザが購入可能な店舗を絞り込むとともに、選択した献立リストの候補の中から上記食材在庫情報にある食材を組み合わせることによって、献立リストの必要食材が充足する献立リストを選択して、
上記選択した献立と食材とをユーザ端末に送信することを特徴とする情報プランニングサービス処理方法。
【請求項２】
請求項１に記載の情報プランニングサービス処理方法を、コンピュータの制御により実現するためのプログラム。
【請求項３】
請求項２に記載のプログラムを記録した、コンピュータにより読み取り可能な記録媒体。
【請求項４】
請求項１に記載の情報プランニングサービス処理方法を実現するための、ネットワークに接続されており、ユーザ端末との間の通信が可能なプランエージェント装置であって、少なくとも、
前記ユーザ端末からユーザの帰宅時刻と場所を受信するとともに、前記ユーザ端末に検討結果である推奨情報を送信情報入出力機能部と、
ユーザの献立利用履歴を保持し、それをもとに適切な献立リストを選択するユーザ履歴情報管理並びに献立リスト選択出力機能部と、
予め位置情報が取得されている店舗との間においてリアルタイムな食材在庫情報を送受信する食材情報管理機能部と、
前記店舗の位置情報とユーザの帰宅場所とを照合し、ユーザが前記献立リストに必要な食材を購入可能な店舗を絞り込む候補店舗選定機能部とを有し、
前記献立リストの候補の中から前記食材在庫情報にある食材を組み合わせることによって、献立リストの必要食材が調達可能な献立リストを選択して、当該食材を購入可能な店舗の情報とともに前記ユーザ端末に送信することを特徴とするプランエージェント装置。
【請求項５】
前記各機能部に加えて、前記選択・提案された食材を購入可能な店舗としてユーザに紹介した店舗に対し、所定の対価を通知し、対象店舗から前記対価を受け取る対価処理機能部を有することを特徴とする請求項４に記載のプランエージェント装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、情報プランニングサービス処理方法とこれに用いるプランエージェントに関する。より具体的には、例えば会社帰りのユーザが、帰宅してから料理を作る必要があるというような場合に有効な、このユーザが帰宅途中で購入できる食材と、それを用いた献立を提案することにより、本システムが提示する商店において、ユーザが食材を帰宅途中に購入し、併せて提示する献立のレシピに従って帰宅後調理することを支援するためのサービス技術に関する。
【０００２】
【従来の技術】
従来、一般には、退社後、帰宅してから調理をしようとする場合には、調理者自身が献立を考え、それに必要な食材を用意する必要があった。
【０００３】
近年、ＷＥＢにおいて、例えば、インターウィン（ｈｔｔｐ：／／ｗｗｗ．ｓｐｉｒａｌｓｙｓ．ｃｏｍ／ｉｎｔｅｒｗｉｎ）、味の素Ａ−Ｋｉｔｃｈｅｎ（ｈｔｔｐ：／／ｗｗｗ．ａｊｉｎｏｍｏｔｏ．ｃｏ．ｊｐ／ａｊｉｎｏｍｏｔｏ／ｉｎｄｅｘ．ｈｔｍｌ）（いずれも、商標）などの献立・レシピの紹介サイトがあり、そのページ、もしくは雑誌などのメディア媒体を通じて、毎日の献立を考えずに決定することができる。
【０００４】
また、タイヘイ食材宅配サービス（ｈｔｔｐ：／／ｗｗｗ．ｓｈｏｋｕｓｈｏｋｕ．ｃｏｍ），ベネッセ食材宅配（ｈｔｔｐ：／／ｗｗｗ．ｂｅｎｅｓｓｅ−ｅｆ．ｊｐ）（いずれも、商標）などのように、宅配業者に予め予約しておくことにより、調理するための材料を決まった時間に自宅に宅配してくれるサービスもある。さらに、出前のように、調理された料理を宅配してくれるサービスもある。
【０００５】
一方、インターネットを通じたサービスとしては、ＮＴＴのＬモードサービス（商標）や、携帯電話にタイムサービス情報を配信してくれるサービスが行われている。
また、本発明と同様の食材購入先情報を提供する技術も提案されている（例えば、特許文献１参照）。
【０００６】
この特許文献１に開示されているサービスは、調理メニューで使用される食材に関連する食材購入先のうち、所定の検索範囲内に位置する食材購入先を求め、その食材購入先の位置を、ユーザの端末に分かりやすく表示できるようにすることを目的とするものである。
【０００７】
そして、この目的を達成するために、上記サービスでは、上述の食材購入先の位置情報をインターネットを介して接続されるサーバから取得して、そのうちで、予め設定された範囲内に存在するものだけを選択して、その位置を示す地図とともにディスプレイに表示するように構成している。
【０００８】
【特許文献】
特許文献１：特開２００２−１８３１６２号公報
【０００９】
【発明が解決しようとする課題】
しかしながら、以上述べた従来の種々のサービスには、以下に述べるような問題点が存在する。
第１の問題点は、献立を参考情報なしで考える場合はもちろんであるが、メディア媒体を通じて献立を決定する場合でも、食材については入手（購入）できるかどうかの保証がなされていないので、帰宅途中に必要な食材を探し、購入する必要があり、手間であるという点である。
【００１０】
第２の問題点は、食材を購入する商店が、必ずしも他店と比べて安いとは限らず、コストパフォーマンスを向上させようとすると、ユーザ自身が各店舗の食材の在庫状況と値段を調査する必要があり、手間がかかるという点である。この原因は、各店舗のリアルタイムな食材在庫情報を取得し、ユーザのコスト要求に合ったコーディネートがなされていなかったためである。
【００１１】
また、第３の問題点は、商店側からの観点で、タイムサービス商品などの、商店側の意図で早めに処分したい商品について、効率よく広告することができず、その場にたまたま居合わせた人や、馴染みの顧客が利用するに留まり、効率的な商売ができないという点である。
【００１２】
さらに、前述の、インターネットを介したリアルタイム情報の提供サービスにおいても、以下の問題点があった。すなわち、これらのサービスは、情報を加工して、ユーザ個々人にカスタマイズするものではない。そのため、ユーザは情報を受け取ってもそれを自身で判断し、どの店で何の食材を購入するかなどを決定する必要があり、提供される情報の利便性が高いとは言えない。
【００１３】
なお、前記特許文献１に開示されたサービスにおいては、食材購入先情報提供装置がユーザの保持端末を兼ねており、直接インターネットに接続していることが条件となっているため、通信手段が限定されるという重大な問題がある。
【００１４】
本発明は、上記事情に鑑みてなされたものであり、その目的とするところは、従来の技術における上述のような諸問題を解消し、ユーザの近辺において購入できる食材と、それを用いた献立を、複数の店舗間におけるリアルタイムな食材情報を元に提案する、情報プランニングサービス処理方法とこれに用いるプランエージェント装置を提供することにある。
【００１５】
【課題を解決するための手段】
上記目的を達成するため、本発明に係る情報プランニングサービス処理方法は、ユーザ端末から送信されるユーザの帰宅時刻と場所を受信し、ユーザの献立利用履歴をもとに適切な献立リストを選択し、リアルタイムな店舗の食材在庫情報を受信して、店舗の位置情報とユーザの帰宅場所とを照合し、ユーザが購入可能な店舗を絞り込むとともに、選択した献立リストの候補の中から上記食材在庫情報にある食材を組み合わせることによって、献立リストの必要食材が充足する献立リストを選択して、上記選択した献立と食材とをユーザ端末に送信することを特徴とする。
【００１６】
なお、本発明に係る情報プランニングサービス処理方法は、コンピュータ制御により実現することが可能であり、そのためのプログラム並びにこのプログラムを記録した記録媒体の形で商品化することが可能である。本発明の権利範囲は、このような形態での利用にも及ぶことはいうまでもない。
【００１７】
また、本発明に係る情報プランニングサービス処理方法を実施する際に用いられるプランエージェント装置は、前記ユーザ端末からユーザの帰宅時刻と場所を受信するとともに、前記ユーザ端末に検討結果である推奨情報を送信情報入出力機能部と、ユーザの献立利用履歴を保持し、それをもとに適切な献立リストを選択するユーザ履歴情報管理並びに献立リスト選択出力機能部と、予め位置情報が取得されている店舗との間においてリアルタイムな食材在庫情報を送受信する食材情報管理機能部と、前記店舗の位置情報とユーザの帰宅場所とを照合し、ユーザが前記献立リストに必要な食材を購入可能な店舗を絞り込む候補店舗選定機能部とを有し、前記献立リストの候補の中から前記食材在庫情報にある食材を組み合わせることによって、献立リストの必要食材が調達可能な献立リストを選択して、当該食材を購入可能な店舗の情報とともに前記ユーザ端末に送信することを特徴とする。
【００１８】
ここで、前記プランエージェント装置は、前記各機能部に加えて、前記選択・提案された食材を購入可能な店舗としてユーザに紹介した店舗に対し、所定の対価を通知し、対象店舗から前記対価を受け取る対価処理機能部を有していることがより好ましい。
【００１９】
本発明に係る情報プランニングサービス処理方法によれば、第１に、帰宅途中のユーザに対して、リアルタイムな店舗の食材在庫情報（タイムサービスなどを含む）に基づき、適切な（コストパフォーマンス良好，在庫あり）食材と、それを用いた献立を提案することが可能となるという効果が得られる。
また、第２に、複数の店舗のタイムサービス情報等を比較することにより、コストパフォーマンスを向上させた食材の購入提案が可能となり、ユーザが各店舗の食材の在庫状況と値段を調査する手間が省けるという利点が得られる。
【００２０】
さらに、商店側からの観点としては、タイムサービス商品などの商店側の意図で早めに処分したい商品について、効率よく広告することができるようになるという利点が得られる。
さらに、本発明に係る情報プランニングサービス処理方法によれば、献立配信サービスプロバイダが献立リストを提供する動機付けができ、健全なビジネスモデルの構築が可能となるという効果も期待できる。
【００２１】
またさらに、本発明に係るプランエージェント装置は、上記情報プランニングサービス処理方法を実施するにあたり、その動作全般を仲介することにより、献立配信サービスプロバイダと店舗間の談合・不当な交渉を防止することが可能となるという効果も期待できる。
【００２２】
【発明の実施の形態】
以下、本発明の実施の形態を、図面に示す好適実施例に基づいて、詳細に説明する。
【００２３】
〔第１の実施例〕
図１は、本発明の第１の実施例を示すシステムの構成図である。本システム内においては、プランエージェント，献立配信サービスホスト，店舗ホストが特徴的な構成であり、ユーザ端末に関しては、既存の技術が用い得る。
【００２４】
図１において、１はプランエージェント、２はプランエージェント１の献立取り扱い部からの要求に対し、自身が保持管理する献立リストの中から適当な献立を提供する献立配信サービスホスト、３はプランエージェント１の食材情報取り扱い部からの要求に対し、自店舗が保持するリアルタイムな食材在庫情報を提供する店舗ホスト、４はユーザが本システムを利用したい時に、そのサービス要求を受け付け、プランエージェントのユーザ情報入出力部に転送し、戻り値である献立・食材リストを受信し、表示するユーザ端末である。
【００２５】
図２は、図１におけるプランエージェント１の詳細を示す図である。
図２において、１１はユーザ端末からのサービス要求（入力データ）を受け取り、その結果として献立取り扱い部１４から受信したサービス（提案する献立・食材情報）をユーザ端末に通知するユーザ情報入出力部である。また、このユーザ情報入出力部１１は、献立取り扱い部１４と位置情報取り扱い部１５にユーザのサービス要求を転送する。
【００２６】
１２は、ユーザへ過去に提案した献立履歴を蓄積するユーザ履歴情報管理部である。献立取り扱い部１４からの問合せに対して、連続して同じ献立を提案しないための条件として、当該ユーザの履歴情報を示す。蓄積されているデータ構造を、図３に示す。１３は、位置情報取り扱い部１５からの依頼を受けて、各店舗ホスト３からリアルタイムな食材在庫情報を入手し、得られた結果を位置情報取り扱い部１５に送信する食材情報取り扱い部である。
【００２７】
１４は、献立取り扱い部である。ユーザ情報入出力部１１からのサービス要求転送を受信し、献立配信サービスホスト２に対し、献立を要求・入手する。そして、ユーザに対して提案する献立の重複を避けるため、ユーザ履歴情報管理部１２に対して過去の献立履歴を問い合わせる。また、位置情報取り扱い部１５から送信される食材リストと、複数の献立の候補のマッチングをとり、ユーザに提案する献立と食材リストを選択し、ユーザ情報入出力部１１に送信する。
【００２８】
１５は位置情報取り扱い部である。ユーザ情報入出力部１１からのサービス依頼を受信し、ユーザが駅に到着する直前に、食材情報取り扱い部１３に対して店舗ホスト３からの食材在庫情報を要求する。戻ってきた食材リストと、ユーザの到着駅名のマッチングをとり、到着駅近くの店舗と食材リストを絞り込み、献立取り扱い部１４に送信する。
【００２９】
以下、上述のように構成される本実施例に係るシステムの動作を、図４，図６，図８および図１０の各フローチャートに基づいて説明する。なお、図３，図５，図７，図９および図１１は、各ステップにおいてやり取りされる通信のデータ構造を示している。
【００３０】
図４は、本発明の第１の実施例におけるユーザからのプランエージェント１へのサービス要求、および献立配信サービスホスト２への献立リスト要求に係る処理を示すフローチャートである。
ステップ１０１：ユーザからのサービス要求（帰宅時刻と到着駅名）を入力されたユーザ端末４は、プランエージェント１内のユーザ情報入出力部１１に対して要求を転送する。なお、本実施形態では、ユーザがユーザ端末４に直接帰宅時刻と到着駅名を手入力している例を挙げるが、本発明の範囲はこれに限定されるものではなく、常にユーザの位置情報を把握しておき、適切なタイミングで到着駅と到着予定時刻をユーザ情報入出力部１１に通知することも可能である。
【００３１】
図８は、本発明の第１の実施例に係るプランエージェント１内部での処理を示すフローチャートである。
ステップ３０１：ユーザ端末４からサービス要求（帰宅時刻と到着駅名）を受信したユーザ情報入出力部１１は、献立取り扱い部１４と位置情報取り扱い部１５に対してこの要求を転送する。その際、帰宅時刻と到着駅名については、位置情報取り扱い部１５にのみ転送するものとし、献立取り扱い部１４に対しては、引数はない。
ステップ３０２：ユーザ情報入出力部１１からの要求転送を受信した位置情報取り扱い部１５は、ユーザが到着する直前のタイミングで、食材情報取り扱い部１３に対して、複数の店舗ホスト３に対してリアルタイムな食材在庫情報を要求する。その際、引数はない。
【００３２】
図６は、本発明の第１の実施例を示す店舗ホスト３への食材在庫情報要求の処理を示すフローチャートである。
ステップ　２０１：位置情報取り扱い部１５からの要求を受けた食材情報取り扱い部１３は、複数の店舗ホスト３に対して、その時点での食材在庫情報を要求する。
ステップ７０１：ステップ２０１で食材情報取り扱い部１３からの要求を受信した店舗ホスト３は、自身の持つ食材在庫情報のリストを抽出する。ここで、食材在庫情報のリスト更新は、レジの情報などから自動的に行われることを想定しているが、本発明はこれに限られるものではない。
【００３３】
ステップ２０２：店舗ホスト３は、抽出した食材在庫情報のリストを食材情報取り扱い部１３に返す。
ステップ３０３：複数の店舗ホスト３から提供された食材在庫情報を受信した食材情報取り扱い部１３は、その情報を位置情報取り扱い部１５に転送する。
ステップ３０６：食材情報取り扱い部１３から食材リストを受信した位置情報取り扱い部１５は、予めステップ３０１で受信している到着駅名と、食材リストで示されている各店舗位置の駅名とを比較し、合致する食材リストを献立取り扱い部１４に対して送信する。
【００３４】
ステップ１０２：上記ステップとは独立して、ステップ３０１でユーザ情報入出力部１１からのサービス要求を受信した献立取り扱い部１４は、献立配信サービスホスト２に対して、献立のリストを要求する。
ステップ６０１：献立取り扱い部１４からの要求を受信した献立配信サービスホスト２は、必要となる食材のリストを含んだ献立リストを複数準備する。ここで、上述の献立リストは、献立配信サービスホスト２内のデータベースにおいて管理されており、その中から適当な複数の（もしくは全ての）献立リストを選択することを想定している。
【００３５】
ステップ１０３：献立配信サービスホスト２は、選択した献立のリストを献立取り扱い部１４に返す。
ステップ３０４：献立配信サービスホスト２から献立リストを受信した献立取り扱い部１４は、ユーザ履歴情報管理部１２に対して、献立配信サービスホスト２から受信した献立リストを転送し、当該ユーザの過去の献立履歴とのマッチングを要求する。
【００３６】
ステップ３０５：献立取り扱い部１４から献立リストを受信したユーザ履歴情報管理部１２は、自身が蓄積しているユーザの過去の献立リストと合致する献立リスト候補を除外して（立て続けに同じ献立を提供する事を避けるため）、絞り込んだ献立リスト候補を献立取り扱い部１４に返す。
【００３７】
ステップ３０７：ユーザ履歴情報管理部１２から献立情報を受信した献立取り扱い部１４は、先にステップ３０６で受信した食材リストに記載されている食材を用いて、献立リスト内で要求されている全ての食材を準備できる条件を満たし、かつ、献立リストの食材の必要数量が、ステップ３０６で受信した食材の在庫数量より小さいという条件を満たすことのできる献立リストを選択し、最終的に提案する献立リストおよびそこで必要となる食材リストをユーザ情報入出力部１１に送信する。
【００３８】
図１０は、本実施例におけるユーザへ献立・食材情報を提案する処理を示すフローチャートである。
ステップ４０１：献立取り扱い部１４から要求食材リストを含んだ献立リストを受信したユーザ情報入出力部１１は、ユーザ端末４に対して当該情報を通知し、ユーザに提案する。
【００３９】
以上説明したように、本実施例によれば、ユーザの帰宅時刻に合わせて、帰宅途中に位置する店舗とそこで購入すべき食材とを、それらの食材を用いた献立とともに提示することにより、ユーザの無駄な稼動（購入する店舗の選択，在庫状況の確認など）を省くことが可能になり、ユーザにとっての利便性を大幅に向上させることができるという顕著な効果を奏するものである。
【００４０】
次に、本発明のさらなる実施例を示す。
〔第２の実施例〕
【００４１】
図１２は、本発明の第２の実施例に係るシステムの構成図である。
第１の実施例との差分は、プランエージェント１内に対価取り扱い部１６が追加されたことである。
【００４２】
図１２において、１６は対価取り扱い部で、選択・提案された食材を提供する店舗ホスト３に対してその旨を通知し、対象店舗ホスト３から対価を受け取り、献立配信サービスホスト２へ対価を支払う。
【００４３】
図１，図１２を用いて、図１３のステップ（第１の実施例に対する追加分）を説明する。なお、図１４は、各ステップにおいてやり取りされる通信のデータ構造の追加分を示している。
【００４４】
ステップ５０１：献立取り扱い部１４において最終的に決定された献立リストに要求される食材リストを提供している店舗に対し、献立取り扱い部１４からの最終提案リストを転送された対価取り扱い部１６が、当該店舗をユーザに対して紹介した旨を店舗ホスト３に通知する。
【００４５】
ステップ８０１：対価取り扱い部１６からの通知を受信した各店舗ホスト３は、紹介料を対価として支払うため、対価の値を決定する。
ステップ５０２：店舗ホスト３は、紹介料として準備した対価を支払うため、対価取り扱い部１６に当該紹介料を送信する。
ステップ５０３：店舗ホスト３からの対価を受信した対価取り扱い部１６は、献立配信サービスホスト２に対して、ロイヤリティとして店舗ホスト３から集めた対価を送信する。
【００４６】
本実施例によれば、第１の実施例により得られる効果に加えて、システムの運営者にとっても店舗側からのロイヤリティが得られることから、システムの運営がより円滑に行えるようになるという効果を奏するものである。
【００４７】
なお、前述の通り、本発明に係る情報プランニングサービス処理方法は、コンピュータ制御により実現することが可能であり、そのためのプログラム並びにこのプログラムを記録した記録媒体の形で商品化することが可能である。本発明の権利範囲は、このような形態での利用にも及ぶことはいうまでもない。
【００４８】
また、上記各実施例はいずれも本発明の一例を示すものであり、本発明はこれらに限定されるべきものではなく、本発明の要旨を逸脱しない範囲内で、適宜の変更・改良を行ってもよいことはいうまでもない。
【００４９】
【発明の効果】
以上、詳細に説明したように、本発明によれば、ユーザにとっても利便性の大幅な向上が得られるばかりでなく、システムの運営者・参加者側にとっても、顧客獲得のチャンスが増えて、収入増加につながるという効果が得られる。
【００５０】
より具体的には、従来は、日中働いているユーザが夕食の献立を考える際、帰宅途中において、どの商店でどのような食材を購入するかを全てプランニングする必要があり、そのため、どの商店がどのような食材を扱っているかを全て予め把握している範囲でしか、献立，食材を選択することができず、また、その商店に帰宅途中に寄ったとしても、目的の商品の在庫があるかどうかは実際に行ってみないとわからなかったという問題があったのが、本発明によりこの問題が解消し、ユーザの無駄な稼動（購入する商店の選択，在庫状況の確認など）を省くことができるようになるという顕著な効果が得られる。
【００５１】
また、従来のシステムでは、夕方の帰宅途中にゲリラ的に行われるタイムサービスの情報や対象商品について、経験則に基づいてしか知り得る手段はなく、そのため、食材を購入する商店を選び、商品を購入したとしても、それが最もコストパフォーマンスがいいかどうかは保証されず、各商店の値段の比較をしようとすると、ユーザ自身が物理的に移動して調査する必要があり、非常に非効率であったが、本発明によりこの問題が解消し、動的にその場の状況に応じてコストパフォーマンスの高い食材の組み合わせを、各商店の在庫状況を確認した上でユーザに提示することが可能になるという効果が得られる。
【００５２】
さらにまた、本発明は店舗側にとってもメリットがある。従来は、タイムサービスの商品などは事前に広告を流すことが困難であり、広くユーザにその存在を通知することができなかったため、商品の在庫処理が非効率にしか実施できなかった。これに対し、本発明では、タイムサービス対象商品をより多くのユーザに献立とともに提示することになるので、より効率よく商品を捌くことが可能になる。
【００５３】
結局のところ、本発明では、複数の店にリアルタイムな情報を加工して提示することにより、プランニングの煩わしさを軽減することが可能になる点、およびユーザ端末は必ずしもインターネットに接続している必要はなく、インターネットに接続しているプランエージェントと何らかの手段で通信できればよい。本発明においては、ユーザ保持端末が通信不可能な環境下にいる際にも、プランエージェントはインターネットを通じて常にサービスを実行できるため、ユーザ端末と非同期通信することにより、通信可能時にユーザに情報を提供することが可能であるという点も、大きな利点である。
【図面の簡単な説明】
【図１】本発明の第１の実施例を示す献立・食材のサービスシステム構成図である。
【図２】図１におけるプランエージェントの一例を示す詳細構成図である。
【図３】図１におけるプランエージェント，献立配信サービスホスト，店舗ホストが各々保持するデータのデータ構造である。
【図４】本発明の第１の実施例を示すユーザのサービス要求および献立配信サービスホストへの献立リスト要求の処理のフローチャートである。
【図５】図４におけるステップにおいて送受信されるデータ構造である。
【図６】本発明の第一の実施例を示す店舗ホストへの食材在庫情報要求の処理のフローチャートである。
【図７】図６におけるステップにおいて送受信されるデータ構造である。
【図８】本発明の第一の実施例を示すプランエージェント内部の処理のフローチャートである。
【図９】図８におけるスップにおいて送受信されるデータ構造である。
【図１０】本発明の第一の実施例を示すユーザへ献立・食材情報を提案する処理のフローチャートである。
【図１１】図８，１０におけるステップにおいて送受信されるデータ構造である。
【図１２】本発明の第２の実施例を示す献立・食材サービスシステムにおけるプランエージェントの一例を示す詳細構成図である。
【図１３】本発明の第２の実施例を示す対価の支払いに関する処理のフローチャートである。
【図１４】図１３におけるステップにおいて送受信されるデータ構造である。
【符号の説明】
１　プランエージェント
２　献立配信サービスホスト
３　店舗ホスト
４　ユーザ端末
１１　ユーザ情報入出力部
１２　ユーザ履歴情報管理部
１３　食材情報取り扱い部
１４　献立取り扱い部
１５　位置情報取り扱い部
１６　対価取り扱い部
【図１】
2004102670.tif 000003
【図２】
2004102670.tif 000004
【図３】
2004102670.tif 000005
【図４】
2004102670.tif 000006
【図５】
2004102670.tif 000007
【図６】
2004102670.tif 000008
【図７】
2004102670.tif 000009
【図８】
2004102670.tif 000010
【図９】
2004102670.tif 000011
【図１０】
2004102670.tif 000012
【図１１】
2004102670.tif 000013
【図１２】
2004102670.tif 000014
【図１３】
2004102670.tif 000015
【図１４】
2004102670.tif 000016