JP7302803B1 - サーバ、合計価格算出方法、及びプログラム - Google Patents

Abstract

【課題】レシピの料理に使用される食材の合計価格を算出する際に、算出した合計価格と、実際の購入金額との乖離が大きくならないようにする。【解決手段】食材ごとの使用量を含む複数のレシピ情報、及び食材の単位量当たりの価格を、食材の取引に関する属性ごとに有する複数の食材価格情報にアクセス可能なサーバ１は、レシピ情報を識別するレシピ識別子を含む情報であり、そのレシピ情報の料理に使用される食材の合計価格の送信を要求する情報である要求情報を受信する受信部１２と、要求情報の受信に基づいて、食材の取引に関する属性を取得する取得部１３と、受信された要求情報に含まれるレシピ識別子によって識別されるレシピ情報、及び取得された属性に対応する単位量当たりの価格を用いて、レシピ情報の料理に使用される食材の合計価格を算出する算出部１４と、その合計価格を送信する送信部１５とを備える。【選択図】図１

Description

本発明は、レシピ情報に含まれる食材の合計価格を算出するサーバ等に関する。

従来、レシピに対応する料理を作成する際の材料費の合計を算出することが行われている（例えば、特許文献１参照）。このようにして、レシピに基づいて料理を行う際の材料費を、事前に知ることができるようになる。

特開２００８－１０８０５３号公報

しかしながら、食材の価格は、食材の販売地域や、食材の販売時期、食材を販売する小売の価格帯（例えば、高級スーパーなどの高価格帯、ディスカウントショップなどの低価格帯など）などの食材の取引に関する属性に応じて変わる。したがって、それらを考慮しないでレシピに含まれる食材の合計価格を算出た際には、算出した合計価格と、実際に購入した食材の合計価格との乖離が大きくなる可能性もあった。

本発明は、上記課題を解決するためになされたものであり、レシピの料理に使用される食材の合計価格を算出する際に、算出した合計価格と、実際に購入した食材の合計価格との乖離が大きくならないようにすることができるサーバ等を提供することを目的とする。

上記目的を達成するため、本発明の一態様によるサーバは、食材ごとの使用量を含む複数のレシピ情報、及び食材の単位量当たりの価格を、食材の取引に関する属性ごとに有する複数の食材価格情報にアクセス可能なサーバであって、レシピ情報を識別するレシピ識別子を含む情報であり、レシピ情報の料理に使用される食材の合計価格の送信を要求する情報である要求情報をユーザから受信する受信部と、要求情報の受信に基づいて、食材の取引に関する属性を取得する取得部と、受信された要求情報に含まれるレシピ識別子によって識別されるレシピ情報、及び取得部によって取得された属性に対応する単位量当たりの価格を用いて、レシピ情報の料理に使用される食材の合計価格を算出する算出部と、算出部によって算出された合計価格を送信する送信部と、を備えたものである。
このような構成により、レシピ情報に対応する料理に使用される食材の合計価格を算出する際に、食材の取引に関する属性を考慮することができる。そのため、例えば、食材の販売地域や、販売時期、食材を販売する小売の価格帯などに応じた、より精度の高い合計価格を算出することができるようになる。そして、その合計価格を用いて、例えば、レシピ情報の料理を作るかどうかを決めることができる。

また、本発明の一態様によるサーバでは、算出部は、レシピ情報に含まれる食材ごとの価格をも算出し、送信部は、算出部によって算出された食材ごとの価格をも送信してもよい。
このような構成により、合計価格のみでなく、各食材の価格も知ることができるようになる。

また、本発明の一態様によるサーバでは、サーバは、食材である商品ごとの販売に関する価格、量、日時、及び店舗を含む複数の販売情報、及び商品と食材との対応を示す複数の対応情報にアクセス可能であり、複数の販売情報、及び複数の対応情報を用いて、食材の単位量当たりの価格を、食材の取引に関する属性ごとに有する食材価格情報を取得して複数の食材価格情報に追加する追加部をさらに備えてもよい。
このような構成により、例えば、ＰＯＳデータなどの販売情報から、食材価格情報を取得して追加することができるようになる。

また、本発明の一態様によるサーバでは、受信部は、受信した要求情報に含まれるレシピ識別子によって識別されるレシピ情報に含まれる食材のうち、ユーザが購入する必要のない食材を示す不要食材情報をも受信し、算出部は、受信された不要食材情報に応じて、ユーザが購入する必要のない食材以外の食材の合計価格を算出してもよい。
このような構成により、例えば、食材の在庫を考慮した合計価格の算出を行うことができるようになる。

また、本発明の一態様によるサーバでは、送信部は、合計価格を、合計価格に対応するレシピ情報と共に送信してもよい。
このような構成により、ユーザは、例えば、レシピ情報と合計価格とを一緒に確認することができるようになる。

また、本発明の一態様によるサーバでは、属性は、食材の取引される地域を含んでおり、取得部は、受信された要求情報を送信したユーザに対応する地域を含む属性を取得してもよい。
このような構成により、食材の地域ごとの価格差を考慮して、合計価格を算出することができるようになる。

また、本発明の一態様によるサーバでは、属性は、食材を販売する小売の価格帯を含んでおり、取得部は、受信された要求情報を送信したユーザに対応する小売の価格帯を含む属性を取得してもよい。
このような構成により、食材を販売する小売の価格帯を考慮して、合計価格を算出することができるようになる。

また、本発明の一態様によるサーバでは、属性は、食材の取引される時期を含んでおり、取得部は、受信された要求情報に対応する時期を含む属性を取得してもよい。
このような構成により、食材の時期ごとの価格差を考慮して、合計価格を算出することができるようになる。

また、本発明の一態様による合計価格算出方法は、受信部と、取得部と、算出部と、送信部とを用いて処理される合計価格算出方法であって、受信部が、レシピ情報を識別するレシピ識別子を含む情報であり、レシピ情報の料理に使用される食材の合計価格の送信を要求する情報である要求情報をユーザから受信するステップと、取得部が、要求情報の受信に基づいて、食材の取引に関する属性を取得するステップと、算出部が、食材ごとの使用量を含む複数のレシピ情報、及び食材の単位量当たりの価格を、食材の取引に関する属性ごとに有する複数の食材価格情報にアクセスして、受信された要求情報に含まれるレシピ識別子によって識別されるレシピ情報、及び取得された属性に対応する単位量当たりの価格を用いて、レシピ情報の料理に使用される食材の合計価格を算出するステップと、送信部が、算出された合計価格を送信するステップと、を備えたものである。

本発明の一態様によるサーバ等によれば、レシピ情報に対応する料理に使用される食材の合計価格を算出する際に、食材の取引に関する属性を考慮することができる。そのため、例えば、食材の販売地域や、販売時期、食材を販売する小売の価格帯などに応じた合計価格を算出することができ、算出した合計価格と、実際に購入した食材の合計価格との乖離が大きくならないようにすることができる。

本発明の実施の形態によるサーバの構成を示すブロック図 同実施の形態によるサーバの動作を示すフローチャート 同実施の形態におけるレシピ情報の一例を示す図 同実施の形態における食材価格情報の一例を示す図 同実施の形態における送信されたレシピ情報の表示の一例を示す図 同実施の形態における販売情報の一例を示す図 同実施の形態における対応情報の一例を示す図 同実施の形態における送信されたレシピ情報の表示の一例を示す図 同実施の形態におけるコンピュータシステムの外観一例を示す模式図 同実施の形態におけるコンピュータシステムの構成の一例を示す図

以下、本発明によるサーバ、及び合計価格算出方法について、実施の形態を用いて説明する。なお、以下の実施の形態において、同じ符号を付した構成要素及びステップは同一または相当するものであり、再度の説明を省略することがある。本実施の形態によるサーバは、レシピ情報に対応する料理に使用される食材の合計価格を、食材の販売地域などの属性に応じて算出するものである。

図１は、本実施の形態による情報処理システムを示す図である。本実施の形態による情報処理システムは、有線または無線の通信回線５００を介して通信可能に接続されたサーバ１と、複数の情報処理端末２とを備える。通信回線５００は、例えば、インターネットやイントラネット、公衆電話回線網等であってもよい。また、情報処理端末２は、通常、レシピを閲覧するユーザが用いる端末であり、例えば、スマートフォンやタブレット端末、パーソナルコンピュータ等であってもよい。なお、図１では、情報処理システムが３個の情報処理端末２を有している場合について示しているが、情報処理端末２の個数は特に限定されない。

図１を参照して、本実施の形態によるサーバ１は、記憶部１１と、受信部１２と、取得部１３と、算出部１４と、送信部１５とを備える。また、サーバ１は、必要に応じて追加部１６を備えてもよい。

記憶部１１では、複数のレシピ情報や、複数の食材価格情報、複数の販売情報、複数の対応情報など記憶されてもよく、それ以外の情報が記憶されてもよい。なお、本実施の形態では、サーバ１が、自装置の記憶部１１で記憶されているレシピ情報等にアクセス可能である場合について主に説明するが、レシピ情報や、食材価格情報、販売情報、対応情報、及び記憶部１１で記憶されているその他の情報のうち、任意の１以上の情報は、サーバ１以外で記憶されていてもよい。この場合であっても、サーバ１は、サーバ１以外で記憶されている情報にアクセス可能になっていることが好適である。

レシピ情報は、料理のレシピを示す情報であり、食材ごとの使用量を含む情報である。レシピ情報は、例えば、料理に使用される食材を識別する食材識別子と、その食材の使用量との組を複数有してもよい。食材識別子は、例えば、食材の名称であってもよい。本実施の形態では、食材の名称である食材識別子を単に食材と呼ぶこともある。食材の使用量は、所定人数分の料理に必要な食材の量であり、例えば、食材の個数や重量、体積などであってもよい。所定人数は、例えば、１人や２人、４人などである。一例として、所定人数を示す情報がレシピ情報に含まれていてもよい。レシピ情報はさらに、例えば、レシピ情報を識別するレシピ識別子、料理の名称や料理の作り方、調理過程の絵や写真、料理の絵や写真などを含んでいてもよい。

食材価格情報は、食材の単位量当たりの価格を、食材の取引に関する属性ごとに有する情報である。食材の単位量当たりの価格は、例えば、食材の単位個数（例えば、１個、１０個など）当たりの価格であってもよく、単位重量（例えば、１００ｇ、１ｋｇなど）当たりの価格であってもよく、食材の単位体積（例えば、１ｃｃ、１カップ、１リットルなど）当たりの価格であってもよく、その他の単位量当たりの価格であってもよい。

食材の取引は、例えば、食材の販売や、食材の購入などであってもよい。食材の取引に関する属性は、例えば、食材の取引される地域、食材を販売する小売の価格帯、及び食材の取引される時期の少なくともいずれかを含んでいてもよい。すなわち、属性は、地域、価格帯、時期のいずれか１つであってもよく、または、それらのうちの２以上の情報であってもよい。食材の取引される地域は、例えば、食材を販売する店舗の存在する地域であってもよい。地域は、例えば、北海道、東北、関東などの地域区分であってもよく、北海道、青森県、岩手県などの都道府県であってもよく、札幌市、函館市などの市区町村であってもよく、その他の地域の区分であってもよい。食材を販売する小売の価格帯は、例えば、高価格帯、中価格帯、低価格帯などであってもよい。高価格帯である小売は、例えば、百貨店や高級スーパーなどである。低価格帯である小売は、例えば、ディスカウントストアなどである。それら以外の小売は、通常、中価格帯となる。食材の取引される時期は、例えば、１月から１２月の月単位であってもよく、春夏秋冬などの４つに区分される季節であってもよく、その他の時期であってもよい。

食材価格情報は、一例として、食材を識別する食材識別子と、その食材の取引に関する属性と、その食材の単位量当たりの価格とを含む情報であってもよい。例えば、食材がジャガイモであり、食材の取引に関する属性が地域を示す北海道である場合には、その北海道におけるジャガイモの単位量（１個）当たりの価格は、北海道で販売されているジャガイモの１個の価格の代表値であってもよい。代表値は、例えば、平均値、中央値、最大値、最小値などであってもよく、最大値と最小値との間の所定の値などであってもよい。最大値と最小値との間の所定の値は、例えば、最大値と最小値との価格差に０から１の範囲の所定の係数を乗算した結果に最小値を加算した値であってもよく、降順に並べたすべての価格のうち、上位から所定の割合の順位である値（例えば、上位から３割の順位の値）であってもよい。

この食材価格情報によって、属性に対応する単位量当たりの食材の価格を知ることができる。食材の価格は、通常、主要な産地では安くなり、産地から離れるほど高くなる傾向にある。また、食材の価格は、通常、食材の旬の時期には安くなり、そうでない時期には高くなる傾向にある。また、食材の価格は、通常、百貨店や高級スーパーなどの高価格帯の小売では高くなり、ディスカウントストアなどの低価格帯の小売では安くなる傾向にある。したがって、属性に応じた単位量当たりの価格を用いてレシピ情報に含まれる食材の合計価格を算出することによって、サーバ１において算出する合計価格と、実際に購入した食材の合計価格とがより近くなるようにすることができる。

販売情報は、食材である商品ごとの販売に関する価格、量、日時、及び店舗を含む情報である。この販売情報は、例えば、ＰＯＳデータであってもよく、広告データであってもよく、レシートなどから得られる情報であってもよい。販売情報には、例えば、商品名や、単位量当たりの価格なども含まれていてもよい。また、販売情報に含まれる店舗は、例えば、店舗を識別する店舗識別子であってもよい。店舗識別子は、例えば、店舗の名称や、店舗を識別する数字や記号などの情報であってもよい。なお、店舗識別子によって、例えば、小売の事業者、及び店舗の位置を特定できるようになっていることが好適である。そのため、店舗識別子は、一例として、小売の事業者を識別する小売識別子（例えば、事業者名や小売の名称など）と、店舗の存在する地域を示す情報とを含んでもよい。販売情報は、例えば、食材である商品を識別する商品識別子と、その商品の販売価格と、その商品の販売量と、その商品の販売日時と、その商品を販売した店舗の店舗識別子とを含む情報であってもよい。商品識別子は、一例として、ＪＡＮコードであってもよく、商品のその他の識別コードであってもよい。前者の場合には、例えば、販売情報にＪＡＮコードが含まれていてもよい。なお、ソースマーキングされたＪＡＮコードは、そのまま商品識別子として用いることができる。一方、販売情報にインストアマーキングされたＪＡＮコードが含まれる場合には、例えば、インストアマーキングされたＪＡＮコードと、小売識別子とによって商品識別子が構成されてもよい。

対応情報は、商品と食材との対応を示す情報である。対応情報は、例えば、商品と食材とを対応付ける情報であってもよい。商品の商品識別子や商品名から、必ずしも商品に対応する食材を特定できるとは限らない。したがって、この対応情報を用いて、商品に対応する食材を特定することになる。対応情報は、例えば、商品を識別する商品識別子と、食材を識別する食材識別子とを有する情報であってもよい。この場合には、一つの対応情報に含まれる商品識別子で識別される商品と、食材識別子で識別される食材とが互いに対応するものとなる。

なお、記憶部１１に情報が記憶される過程は問わない。例えば、記録媒体を介して情報が記憶部１１で記憶されるようになってもよく、通信回線等を介して送信された情報が記憶部１１で記憶されるようになってもよく、または、入力デバイスを介して入力された情報が記憶部１１で記憶されるようになってもよい。記憶部１１は、不揮発性の記録媒体によって実現されることが好適であるが、揮発性の記録媒体によって実現されてもよい。記録媒体は、例えば、半導体メモリや磁気ディスク、光ディスクなどであってもよい。

受信部１２は、ユーザから要求情報を受信する。要求情報は、通常、情報処理端末２から送信される。そのため、ユーザから要求情報を受信するとは、厳密には、ユーザが操作している情報処理端末２から要求情報を受信することであってもよい。要求情報は、レシピ情報を識別するレシピ識別子を含む情報であり、そのレシピ情報の料理に使用される食材の合計価格の送信を要求する情報である。要求情報には、例えば、要求情報を送信したユーザを識別するユーザ識別子が含まれていてもよい。また、要求情報には、例えば、要求情報を送信した情報処理端末２の位置を示す位置情報が含まれていてもよい。位置情報は、例えば、ＧＰＳなどによって取得することができる緯度、経度の情報であってもよく、住所であってもよい。また、要求情報には、例えば、要求情報を送信したユーザが指定した価格帯が含まれていてもよい。

受信部１２は、要求情報以外の情報を受信してもよい。受信部１２は、例えば、レシピ情報の一覧の送信を要求する一覧要求情報を受信してもよい。また、受信部１２は、例えば、レシピ情報や販売情報、対応情報などを受信してもよい。レシピ情報や販売情報、対応情報などを受信した場合には、受信部１２は、その受信した情報を記憶部１１に蓄積してもよい。なお、受信部１２は、受信を行うための有線または無線の受信デバイス（例えば、モデムやネットワークカードなど）を含んでもよく、または含まなくてもよい。また、受信部１２は、ハードウェアによって実現されてもよく、または受信デバイスを駆動するドライバ等のソフトウェアによって実現されてもよい。

取得部１３は、受信部１２による要求情報の受信に基づいて、食材の取引に関する属性を取得する。属性が、食材の取引される地域を含む場合には、取得部１３は、受信された要求情報を送信したユーザに対応する地域を取得してもよい。ユーザに対応する地域は、例えば、ユーザの現在位置の含まれる地域であってもよく、ユーザの登録している地域であってもよく、ユーザが指定した位置の含まれる地域であってもよい。一例として、要求情報に、要求情報を送信した情報処理端末２の位置を示す位置情報、またはユーザが指定した位置を示す位置情報が含まれる場合には、取得部１３は、要求情報から位置情報を取得し、その位置情報の示す位置を含む地域を取得してもよい。例えば、地域が都道府県であり、位置情報が緯度、経度の情報である場合には、取得部１３は、位置情報によって示される緯度、経度の含まれる都道府県を特定することによって、位置情報に対応する都道府県である地域を取得してもよい。例えば、地域が都道府県であり、位置情報が住所である場合には、取得部１３は、住所から都道府県である地域を取得してもよい。また、一例として、記憶部１１において、ユーザを識別するユーザ識別子と、そのユーザの地域とを対応付ける複数の地域対応情報が記憶されていてもよい。そして、取得部１３は、地域対応情報を用いて、要求情報に含まれるユーザ識別子に対応する地域を取得してもよい。地域対応情報は、例えば、ユーザ識別子と、そのユーザ識別子に対応する地域とを有する情報であってもよい。

属性が、食材を販売する小売の価格帯を含む場合には、取得部１３は、受信された要求情報を送信したユーザに対応する小売の価格帯を取得してもよい。ユーザに対応する価格帯は、例えば、ユーザが指定した価格帯であってもよく、ユーザの登録している価格帯であってもよい。一例として、要求情報に、その要求情報を送信したユーザの指定した価格帯が含まれる場合には、取得部１３は、要求情報から価格帯を取得してもよい。その取得した価格帯が、食材を販売する小売の価格帯となる。この場合には、例えば、情報処理端末２から要求情報が送信される際に、ユーザによって選択された価格帯を示す情報を含む要求情報が送信されてもよい。また、一例として、記憶部１１において、ユーザを識別するユーザ識別子と、そのユーザが選択した価格帯とを対応付ける複数のユーザ価格帯対応情報が記憶されていてもよい。そして、取得部１３は、ユーザ価格帯対応情報を用いて、要求情報に含まれるユーザ識別子に対応する価格帯を取得してもよい。ユーザ価格帯対応情報は、例えば、ユーザ識別子と、そのユーザ識別子に対応する価格帯とを有する情報であってもよい。価格帯は、例えば、高価格帯、中価格帯、低価格帯などであってもよい。

属性が、食材の取引される時期を含む場合には、取得部１３は、受信された要求情報に対応する時期を取得してもよい。受信された要求情報に対応する時期は、例えば、その要求情報の受信時点を含む時期であってもよい。一例として、取得部１３は、例えば、要求情報が受信された際に、カレンダー部から暦の月である時期を取得してもよい。時期が月以外である場合には、取得部１３は、その取得した月を用いて、季節などの時期を取得してもよい。この場合には、取得部１３は、例えば、月と季節とを対応付ける情報を用いて、月に対応する季節を取得してもよい。また、一例として、要求情報に、その要求情報の送信時点を含む時期が含まれていてもよい。この場合には、取得部１３は、要求情報から時期を取得してもよい。

算出部１４は、受信部１２によって受信された要求情報に含まれるレシピ識別子によって識別されるレシピ情報、及び取得部１３によって取得された属性に対応する単位量当たりの価格を用いて、レシピ情報の料理に使用される食材の合計価格を算出する。具体的には、算出部１４は、受信された要求情報からレシピ識別子を取得し、そのレシピ識別子で識別されるレシピ情報に含まれる食材ごとの使用量を記憶部１１から読み出す。そして、算出部１４は、ある食材に関する、取得部１３によって取得された属性に対応する単位量当たりの価格を特定し、その単位量当たりの価格に、その食材の使用量を乗算することによって、その食材の価格を算出する。この処理を、記憶部１１から読み出したすべての食材の使用量について繰り返し、最後に、食材ごとの価格の合計を算出する。その算出結果が、レシピ情報に含まれる複数の食材の合計価格となる。

なお、算出部１４は、レシピ情報に含まれる食材ごとの価格を算出してもよい。この食材ごとの価格は、例えば、合計価格を算出する過程で算出されてもよい。また、レシピ情報に含まれる食材ごとの使用量が複数人数分の量である場合には、算出部１４は、その複数人数分（ここでは、Ｎ人分とする。Ｎは２以上の整数である）の合計価格と共に、または、その合計価格に代えて、１人分の合計価格、すなわち上記のようにして算出した合計価格をＮで割った金額を算出してもよい。なお、レシピ情報に含まれる食材とは、レシピ情報に含まれる使用量に対応する食材のことであり、例えば、レシピ情報に含まれる食材識別子で識別される食材であってもよい。

送信部１５は、算出部１４によって算出された合計価格を送信する。送信先は、例えば、要求情報の送信元であってもよい。算出部１４によって食材ごとの価格も算出された場合には、送信部１５は、その食材ごとの価格を送信してもよい。合計価格は、例えば、レシピ情報を特定できる情報、例えば、レシピ情報に対応する料理の名称と共に送信されてもよい。また、食材ごとの価格は、例えば、食材を特定できる情報、例えば、食材の名称と共に送信されてもよい。

また、送信部１５は、合計価格や、食材ごとの価格を、その合計価格に対応するレシピ情報と共に送信してもよい。そのレシピ情報は、要求情報に含まれるレシピ識別子によって識別されるレシピ情報である。送信部１５は、一例として、レシピ情報に、合計価格と、食材ごとの価格とを含めて送信してもよい。このようにすることで、レシピ情報等を受信した情報処理端末２のユーザは、レシピ情報と共に、そのレシピ情報の料理を作る際に必要な材料費や、食材ごとの材料費などを知ることができ、それらの費用を、レシピ情報の料理を実際に作るかどうかを決めるために用いることもできる。例えば、あるレシピ情報の合計価格が想定よりも高い場合には、ユーザは、別のレシピ情報を選択することもできる。なお、レシピ情報を送信する際に、送信部１５は、例えば、レシピ識別子を削除したレシピ情報を送信してもよい。また、レシピ識別子を含むレシピ情報が送信された場合であっても、例えば、ユーザの情報処理端末２において、レシピ識別子は表示されなくてもよい。

また、送信部１５は、それら以外の情報を送信してもよい。例えば、受信部１２によって一覧要求情報が受信された場合には、送信部１５は、記憶部１１で記憶されている複数のレシピ情報の一覧を送信してもよい。複数のレシピ情報の一覧は、例えば、複数のレシピ情報に対応するレシピ識別子と料理の名称との一覧であってもよい。なお、レシピ識別子と料理の名称との一覧が送信された場合に、情報処理端末２では、料理の名称のみが表示されてもよい。そして、ある料理の名称が選択された場合に、その選択された料理の名称に対応するレシピ識別子を含む要求情報が、情報処理端末２からサーバ１に送信されてもよい。また、送信部１５は、送信を行うための送信デバイス（例えば、モデムやネットワークカードなど）を含んでもよく、または含まなくてもよい。また、送信部１５は、ハードウェアによって実現されてもよく、または送信デバイスを駆動するドライバ等のソフトウェアによって実現されてもよい。

追加部１６は、複数の販売情報、及び複数の対応情報を用いて、食材の単位量当たりの価格を、食材の取引に関する属性ごとに有する食材価格情報を取得して、記憶部１１で記憶されている複数の食材価格情報に追加してもよい。追加部１６は、販売情報に含まれる価格を量で除算することによって、商品の単位量当たりの価格を取得することができる。なお、販売情報に単位量当たりの価格が含まれる場合には、追加部１６は、それを取得してもよい。また、追加部１６は、販売情報を用いて、属性を取得してもよい。

属性が、食材の取引される地域を含む場合には、追加部１６は、販売情報に含まれる店舗の情報から、その店舗の含まれる地域を取得してもよい。一例として、店舗の情報が店舗識別子である場合には、その店舗識別子に含まれる地域を取得してもよい。また、一例として、記憶部１１において、店舗を識別する店舗識別子と、その店舗の地域とを対応付ける複数の店舗対応情報が記憶されていてもよい。そして、追加部１６は、店舗対応情報を用いて、販売情報に含まれる店舗識別子に対応する地域を取得してもよい。店舗対応情報は、例えば、店舗識別子と、その店舗識別子に対応する地域とを有する情報であってもよい。

属性が、食材を販売する小売の価格帯を含む場合には、追加部１６は、販売情報に含まれる店舗の情報から、その店舗の価格帯を取得してもよい。一例として、記憶部１１において、店舗を識別する店舗識別子と、その店舗の価格帯とを対応付ける複数の店舗価格帯対応情報が記憶されていてもよい。そして、追加部１６は、店舗価格帯対応情報を用いて、販売情報に含まれる店舗識別子に対応する価格帯を取得してもよい。店舗価格帯対応情報は、例えば、店舗識別子と、その店舗識別子に対応する価格帯とを有する情報であってもよい。

属性が、食材の取引される時期を含む場合には、追加部１６は、販売情報に含まれる日時から時期を取得してもよい。追加部１６は、例えば、販売情報に含まれる日時から月である時期を取得してもよく、時期が月以外である場合には、日時から季節などの時期を取得してもよい。

また、追加部１６は、対応情報を用いることによって、販売情報の商品に対応する食材を特定することができる。このようにして、追加部１６は、記憶部１１で記憶されている複数の販売情報と複数の対応情報とを用いて、食材ごとの単位量当たりの価格を、属性ごとに有する食材価格情報を取得することができる。追加部１６は、取得した食材価格情報を、記憶部１１で記憶されている複数の食材価格情報に追加する。なお、追加部１６は、取得した食材価格情報と同じ食材及び属性の食材価格情報がすでに記憶部１１で記憶されている場合には、例えば、食材価格情報を上書きで蓄積してもよく、または、最新の食材価格情報を特定可能なように蓄積してもよい。

また、追加部１６が複数の販売情報から食材価格情報を取得する際に、同じ食材及び属性の複数の食材価格情報を取得することが想定される。この場合には、追加部１６は、その複数の食材価格情報を１つの食材価格情報にまとめることが好適である。その際に、食材の単位量当たりの価格は、例えば、複数の食材価格情報に含まれる複数の価格の代表値としてもよい。代表値は、上記したように、例えば、平均値、中央値、最大値、最小値などであってもよい。

次に、サーバ１の動作について図２のフローチャートを用いて説明する。
（ステップＳ１０１）受信部１２は、一覧要求情報を受信したかどうか判断する。そして、一覧要求情報を受信した場合には、ステップＳ１０２に進み、そうでない場合には、ステップＳ１０７に進む。

（ステップＳ１０２）送信部１５は、レシピ情報の一覧を送信する。送信先は、例えば、一覧要求情報の送信元であってもよい。レシピ情報の一覧は、例えば、記憶部１１で記憶されている複数のレシピ情報ごとのレシピ識別子と料理の名称との組であってもよい。

（ステップＳ１０３）受信部１２は、要求情報を受信したかどうか判断する。そして、要求情報を受信した場合には、ステップＳ１０４に進み、そうでない場合には、要求情報を受信するまでステップＳ１０３の処理を繰り返す。

（ステップＳ１０４）取得部１３は、要求情報の受信に応じて属性を取得する。

（ステップＳ１０５）算出部１４は、要求情報に含まれるレシピ識別子で識別されるレシピ情報と、取得された属性と、記憶部１１で記憶されている食材価格情報とを用いて、レシピ情報の料理に使用される食材の合計価格を算出する。また、算出部１４は、食材ごとの価格を算出してもよい。

（ステップＳ１０６）送信部１５は、算出部１４による算出結果を送信する。なお、送信部１５は、算出結果を、要求情報に含まれるレシピ識別子で識別されるレシピ情報と一緒に送信してもよい。そして、ステップＳ１０１に戻る。

（ステップＳ１０７）受信部１２は、レシピ情報や販売情報などを受信したかどうか判断する。そして、受信した場合には、ステップＳ１０８に進み、そうでない場合には、ステップＳ１０９に進む。

（ステップＳ１０８）受信部１２は、受信した情報を記憶部１１に蓄積する。なお、情報が記憶部１１以外で記憶されている場合には、受信部１２は、受信した情報を記憶部１１以外の記録媒体やサーバ等に追加してもよい。そして、ステップＳ１０１に戻る。

（ステップＳ１０９）追加部１６は、食材価格情報の追加を行うかどうか判断する。そして、食材価格情報の追加を行う場合には、ステップＳ１１０に進み、そうでない場合には、ステップＳ１０１に戻る。なお、追加部１６は、例えば、食材価格情報の追加を行うと定期的（例えば、１日ごとや、１週間ごと、１か月ごとなど）に判断してもよい。

（ステップＳ１１０）追加部１６は、記憶部１１で記憶されている複数の販売情報等を用いて食材価格情報を取得する。

（ステップＳ１１１）追加部１６は、取得した食材価格情報を記憶部１１に蓄積する。なお、食材価格情報が記憶部１１以外で記憶されている場合には、追加部１６は、食材価格情報を記憶部１１以外の記録媒体やサーバ等に追加してもよい。そして、ステップＳ１０１に戻る。

なお、図２のフローチャートにおける処理の順序は一例であり、同様の結果を得られるのであれば、各ステップの順序を変更してもよい。また、図２のフローチャートにおいて、電源オフや処理終了の割り込みにより処理は終了する。

次に、本実施の形態によるサーバ１の動作について、具体例を用いて説明する。本具体例では、例えば、図３で示されるレシピ情報が記憶部１１で記憶されているものとする。図３のレシピ情報では、料理「肉じゃが」に関する４人分の食材の使用量が、食材の名称である食材識別子に対応付けられている。例えば、食材「ジャガイモ」の使用量が「６個」であることが示されている。また、レシピ情報には、作り方や、レシピ識別子「Ｍ００１」も含まれている。なお、記憶部１１では、料理「肉じゃが」以外のレシピ情報も記憶されていることは言うまでもない。

また、本具体例では、図４で示される複数の食材価格情報が記憶部１１で記憶されているものとする。本具体例では、属性は地域であるとする。図４で示されるように、食材価格情報は、食材を識別する食材識別子と、地域である属性と、その食材の属性に対応する単位量当たりの価格とを含む情報である。例えば、食材「ジャガイモ」の北海道における１個当たりの価格が示されている。

まず、あるユーザが、情報処理端末２を操作して、サーバ１に一覧要求情報を送信する処理を選択したとする。すると、それに応じて情報処理端末２からサーバ１に一覧要求情報が送信される。サーバ１の受信部１２は、一覧要求情報を受信すると、その一覧要求情報の送信元のアドレスと、一覧要求情報を受信した旨を送信部１５に渡す（ステップＳ１０１）。アドレス等を受け取ると、送信部１５は、記憶部１１にアクセスして、レシピ情報の一覧を取得して、受け取ったアドレスに送信する（ステップＳ１０２）。

サーバ１から送信されたレシピ情報の一覧は、ユーザの情報処理端末２で受信され、表示される。その表示において、ユーザが、肉じゃがのレシピを選択したとする。すると、その肉じゃがのレシピ識別子「Ｍ００１」と、その時点に情報処理端末２の現在位置取得部によって取得された現在位置を示す位置情報とを含む要求情報が情報処理端末２からサーバ１に送信される。現在位置取得部は、例えば、ＧＰＳなどによって現在位置を取得してもよい。

サーバ１の受信部１２は、要求情報を受信すると、その要求情報の送信元のアドレスを送信部１５に渡し、要求情報に含まれるレシピ識別子「Ｍ００１」を算出部１４に渡し、要求情報に含まれる位置情報を取得部１３に渡す（ステップＳ１０３）。位置情報を受け取ると、取得部１３は、その位置情報によって示される位置が含まれる都道府県を特定する。この場合には、その位置は北海道に含まれていたとする。すると、取得部１３は、地域を示す属性「北海道」を取得し、その属性を算出部１４に渡す（ステップＳ１０４）。

レシピ識別子と属性とを受け取ると、算出部１４は、レシピ識別子「Ｍ００１」で識別される肉じゃがのレシピ情報を記憶部１１から読み出し、そのレシピ情報から食材識別子と、使用量との複数の組を取得する。そして、算出部１４は、取得した各組について、食材識別子、及び属性に対応する単位量当たりの価格を取得する。例えば、食材識別子「ジャガイモ」、属性「北海道」に対応する１個当たりの価格「△△円」を、図４で示される食材価格情報から取得する。次に、算出部１４は、取得した１個当たりの価格「△△円」に、食材識別子「ジャガイモ」の使用量を乗算することによって、食材識別子「ジャガイモ」の価格を算出する。算出部１４は、このような食材ごとの価格の算出を、レシピ情報から取得した各組について行うことによって、レシピ情報に含まれる各食材の価格、すなわち、各食材の材料費を特定することができる。最後に、算出部１４は、食材ごとの価格の合計を算出する（ステップＳ１０５）。この算出結果が、肉じゃがのレシピ情報に含まれる食材の合計価格である。算出部１４は、合計価格、及び食材ごとの価格を追加したレシピ情報を送信部１５に渡す。なお、食材ごとの価格は、食材との対応関係が分かるように追加されることが好適である。例えば、食材の食材識別子に対応付けて、その食材の価格が追加されてもよい。

送信部１５は、合計価格等の追加されたレシピ情報を、受信部１２から受け取ったアドレスに送信する（ステップＳ１０６）。サーバ１から送信された合計価格等を含むレシピ情報は、ユーザの情報処理端末２で受信され、図５で示されるように表示される。図５において、「○○○円」が合計価格であり、「×××円」が食材ごとの価格であるとする。図５の表示を見たユーザは、肉じゃがのレシピと共に、４人分の材料費の合計と、食材ごとの材料費とを知ることができる。そして、ユーザは、例えば、材料費の合計や、特定の食材の材料費が想定していたよりも高いと感じた場合には、別のレシピを選択することもできる。一方、ユーザが、例えば、材料費の合計や各食材の材料費が妥当であると感じた場合には、食材を購入して肉じゃがを作ることもできる。このようにして、ユーザは、食費の予算に応じたレシピを選択して食事を作ることができるようになる。また、地域に応じた食材の単位量当たりの価格を用いて合計価格等を算出するため、算出した合計価格や食材ごとの価格と、実際に購入した食材の合計価格や食材ごとの価格との乖離を、属性を考慮しない場合と比較して、小さくすることができる。

サーバ１の受信部１２は、販売情報を受信すると、受信した販売情報を記憶部１１に蓄積する（ステップＳ１０７、Ｓ１０８）。このようにして、例えば、図６で示される販売情報が記憶部１１で記憶されるようになったとする。なお、図６の販売情報には、販売された商品のＪＡＮコードと、商品の販売された日時と、商品の販売された店舗を識別する店舗識別子と、商品の価格と、商品の量とが含まれる。販売情報に含まれるＪＡＮコードがソースマーキングされたものである場合には、そのＪＡＮコードが商品識別子となる。一方、ＪＡＮコードがインストアマーキングされたものである場合には、そのＪＡＮコードと小売識別子とによって、商品識別子が構成されてもよい。小売識別子は、例えば、店舗識別子から取得できるようになっていてもよい。この場合には、例えば、記憶部１１において、店舗識別子と、その店舗識別子で識別される店舗の属する事業者を識別する小売識別子とを対応付ける複数の情報が記憶されていてもよい。また、図６の販売情報に含まれる店舗識別子には、小売の名称と、店舗の存在する地域とが含まれている。

また、本具体例では、記憶部１１において図７で示される複数の対応情報も記憶されているものとする。図７の対応情報は、ＪＡＮコードを含む商品識別子と、食材の名称である食材識別子とを含む情報である。なお、ＪＡＮコードがインストアマーキングされたものである場合には、商品識別子に、小売識別子も含まれている。例えば、図７の対応情報によって、インストアマーキングされたＪＡＮコード「２０９８７...３２１」と、小売識別子「Ｒ００１」とを含む商品識別子で識別される商品がジャガイモであることが示されている。

次に、追加部１６が、食材価格情報を追加すると判断すると（ステップＳ１０９）、記憶部１１から、複数の販売情報を読み出す。なお、読み出しの対象となるのは、例えば、最新の所定の期間の販売情報であってもよい。追加部１６は、読み出した販売情報ごとに、食材識別子と、属性と、単位量当たりの価格とを取得する。例えば、図６で示される１番目の販売情報には、インストアマーキングされたＪＡＮコードが含まれているため、追加部１６は、記憶部１１で記憶されている店舗識別子と小売識別子とを対応付ける情報を参照して、店舗識別子に対応する小売識別子を取得する。取得された小売識別子は「Ｒ００１」であったとする。すると、追加部１６は、図７で示される対応情報を参照し、インストアマーキングされたＪＡＮコード「２０９８７...３２１」及び小売識別子「Ｒ００１」を含む商品識別子に対応する食材識別子「ジャガイモ」を取得する。また、追加部１６は、１番目の販売情報に含まれる店舗識別子から、店舗の存在する地域「北海道」を取得する。また、追加部１６は、１番目の販売情報に含まれる価格を量で除算することによって、単位量当たりの価格を算出する。このようにして、追加部１６は、１番目の販売情報から、食材識別子「ジャガイモ」、属性「北海道」、単位量当たりの価格を取得することができる。追加部１６は、このような処理を読み出した各販売情報について行い、その後に、同じ食材識別子及び属性に対応する１以上の単位量当たりの価格を特定し、その単位量当たりの価格の代表値を取得する。そして、追加部１６は、その食材識別子、属性、代表値である単位量当たりの価格を含む食材価格情報を記憶部１１に追加する（ステップＳ１１０，Ｓ１１１）。このようにして、記憶部１１で記憶されている食材価格情報を、最新のものにアップデートすることができる。

以上のように、本実施の形態によるサーバ１によれば、レシピ情報に対応する料理に使用される食材の合計価格を、属性に応じて算出することができる。したがって、例えば、地域や、時期、小売の価格帯などに応じた合計価格を算出することができる。その結果、算出した合計価格がより正確なものとなり、算出した合計価格と実際に購入した食材の合計価格との乖離を、属性を考慮しない場合と比較して小さくすることができる。また、食材ごとの価格も送信された場合には、ユーザは、合計価格と共に、各食材の材料費についても知ることができるようになる。また、販売情報等から食材価格情報を取得して複数の食材価格情報に追加することにより、例えば、記憶部１１で記憶されている食材価格情報を最新のものにアップデートすることができる。

なお、合計価格を算出する際に、ユーザの食材の在庫状況を考慮することも考えられる。一方、ユーザごとに食材の在庫状況を把握するためには、それに応じた装置やユーザの作業が必要になるという問題がある。そのため、ユーザから、レシピ情報に含まれる食材のうち、購入しなくてもよい食材を示す情報を受信し、その受信に応じて、合計価格を算出するようにしてもよい。この場合には、受信部１２は、受信した要求情報に含まれるレシピ識別子によって識別されるレシピ情報に含まれる食材のうち、ユーザが購入する必要のない食材を示す不要食材情報をも受信してもよい。不要食材情報には、ユーザが購入しなくてもよい食材を識別する食材識別子が含まれていてもよい。

不要食材情報は、ユーザがレシピ情報において、購入する必要のない食材を特定することによって、情報処理端末２から送信されてもよい。一例として、図８で示されるように、情報処理端末２でレシピ情報が表示される際に、ユーザが食材をすでに所有していることを示す「在庫あり」ボタンが各食材に対応付けて表示されてもよい。そして、例えば、ユーザが食材「牛肉（切り落とし）」に対応する「在庫あり」ボタンを選択すると、その選択に応じて、食材識別子「牛肉（切り落とし）」を含む不要食材情報がサーバ１に送信されてもよい。なお、ユーザが複数の「在庫あり」ボタンを選択する場合には、すべての選択後に複数の食材識別子を含む不要食材情報が送信されてもよく、ボタンの選択ごとに不要食材情報が送信されてもよい。

算出部１４は、受信された不要食材情報に応じて、ユーザが購入する必要のない食材以外の食材の合計価格を算出してもよい。この場合には、算出部１４は、不要食材情報によって購入する必要がないことが示されている食材以外の食材について、食材の合計価格を算出することになる。合計価格の算出から、購入する必要のない食材が除外される以外は、上記の説明と同様にして合計価格を算出することができる。算出部１４が、レシピ情報に含まれる食材ごとの価格も算出する場合にも、不要食材情報によって購入する必要がないことが示される食材については、その価格を算出しなくてもよい。

このように、レシピ情報に含まれる食材のうち、合計価格の算出に含めなくてもよい食材をユーザが特定できるようにすることで、ユーザがレシピ情報に応じた料理を作る際に新たに必要になる食材の合計価格を算出することができるようになる。また、ユーザは、レシピ情報において、所有している食材を選択するだけでよい。したがって、食材の在庫状況を把握するための装置を導入したり、ユーザが在庫状況を手動で更新したりする必要がないため、装置の導入のコストや、ユーザの過大な作業などが不要になるというメリットもある。

また、本実施の形態では、属性に含まれる地域が都道府県である場合について主に説明したが、地域はさらに細かい範囲であってもよい。地域は、例えば、一つの地域に一つの小売の店舗が含まれる程度に細かくてもよい。この場合であって、ユーザの現在位置を示す位置情報が要求情報に含まれる場合には、例えば、ユーザの現在位置の近くの小売の店舗における食材の価格によって、合計価格などが算出されることになり、合計価格などがより正確なものになり得る。

また、本実施の形態では、属性に時期が含まれる場合に、要求情報の受信時点の時期に応じた合計価格等が算出される場合について主に説明したが、そうでなくてもよい。ユーザが指定した時期に応じた合計価格等が算出されるようにしてもよい。この場合には、例えば、ユーザが指定した時期を示す情報が、要求情報に含まれていてもよい。そして、取得部１３は、要求情報に含まれている時期を取得してもよい。この場合には、受信された要求情報に対応する時期は、例えば、その要求情報に含まれる時期であってもよい。

また、本実施の形態では、サーバ１が追加部１６を有している場合について主に説明したが、そうでなくてもよい。サーバ１が追加部１６を有していない場合には、例えば、他の装置等によって、適宜、食材価格情報が追加されてもよく、手動で食材価格情報が生成されてもよい。

また、本実施の形態では、サーバ１においてユーザ識別子を用いた処理が行われる際に、そのユーザ識別子が要求情報に含まれる場合について主に説明したが、そうでなくてもよい。例えば、要求情報に含まれるユーザ識別子に代えて、要求情報に対応するユーザ識別子が用いられてもよい。要求情報に対応するユーザ識別子は、例えば、ログイン時などにサーバ１で受信されたユーザ識別子であってもよい。この場合には、ログイン後の処理においてユーザ識別子を用いる際に、ログイン時に受信されたユーザ識別子が用いられてもよい。要求情報に含まれる位置情報や価格帯についても同様である。例えば、要求情報に含まれる位置情報や価格帯に代えて、要求情報に対応する位置情報や価格帯が用いられてもよい。

また、本実施の形態では、レシピ情報が合計価格等と一緒に送信される場合について主に説明したが、そうでなくてもよい。合計価格や食材ごとの価格は、例えば、レシピ情報とは別に送信されてもよい。この場合には、サーバ１は、例えば、ユーザからレシピ情報の送信要求を受信し、その受信した送信要求に含まれるレシピ識別子で識別されるレシピ情報を、ユーザに送信してもよい。また、例えば、ユーザが紙媒体のレシピ情報を有している場合などには、サーバ１は、レシピ情報の送信を行わなくてもよい。

また、本実施の形態において、記憶部１１では、食材ごとに、栄養素の情報や、アレルギーに関する情報などが記憶されていてもよい。この場合には、合計価格や食材ごとの価格がレシピ情報と一緒に送信される際に、例えば、そのレシピ情報に含まれる食材に対応する栄養素の情報やアレルギーの情報なども一緒に送信されてもよい。また、送信されたレシピ情報において特定の食材が選択された場合に、その選択結果がサーバ１に送信されてもよい。この場合には、サーバ１は、その選択結果の受信に応じて、その選択結果に応じた食材の栄養素の情報や、アレルギーの情報を情報処理端末２に送信してもよい。

また、上記実施の形態において、各処理または各機能は、単一の装置または単一のシステムによって集中処理されることによって実現されてもよく、または、複数の装置または複数のシステムによって分散処理されることによって実現されてもよい。

また、上記実施の形態において、各構成要素間で行われる情報の受け渡しは、例えば、その情報の受け渡しを行う２個の構成要素が物理的に異なるものである場合には、一方の構成要素による情報の出力と、他方の構成要素による情報の受け付けとによって行われてもよく、または、その情報の受け渡しを行う２個の構成要素が物理的に同じものである場合には、一方の構成要素に対応する処理のフェーズから、他方の構成要素に対応する処理のフェーズに移ることによって行われてもよい。

また、上記実施の形態において、各構成要素が実行する処理に関係する情報、例えば、各構成要素が受け付けたり、取得したり、選択したり、生成したり、送信したり、受信したりした情報や、各構成要素が処理で用いる閾値や数式、アドレス等の情報等は、上記説明で明記していなくても、図示しない記録媒体において、一時的に、または長期にわたって保持されていてもよい。また、その図示しない記録媒体への情報の蓄積を、各構成要素、または、図示しない蓄積部が行ってもよい。また、その図示しない記録媒体からの情報の読み出しを、各構成要素、または、図示しない読み出し部が行ってもよい。

また、上記実施の形態において、各構成要素等で用いられる情報、例えば、各構成要素が処理で用いる閾値やアドレス、各種の設定値等の情報がユーザによって変更されてもよい場合には、上記説明で明記していなくても、ユーザが適宜、それらの情報を変更できるようにしてもよく、または、そうでなくてもよい。それらの情報をユーザが変更可能な場合には、その変更は、例えば、ユーザからの変更指示を受け付ける図示しない受付部と、その変更指示に応じて情報を変更する図示しない変更部とによって実現されてもよい。その図示しない受付部による変更指示の受け付けは、例えば、入力デバイスからの受け付けでもよく、通信回線を介して送信された情報の受信でもよく、所定の記録媒体から読み出された情報の受け付けでもよい。

また、上記実施の形態において、サーバ１に含まれる２以上の構成要素が通信デバイスや入力デバイス等を有する場合に、２以上の構成要素が物理的に単一のデバイスを有してもよく、または、別々のデバイスを有してもよい。

また、上記実施の形態において、各構成要素は専用のハードウェアにより構成されてもよく、または、ソフトウェアにより実現可能な構成要素については、プログラムを実行することによって実現されてもよい。例えば、ハードディスクや半導体メモリ等の記録媒体に記録されたソフトウェア・プログラムをＣＰＵ等のプログラム実行部が読み出して実行することによって、各構成要素が実現され得る。その実行時に、プログラム実行部は、記憶部や記録媒体にアクセスしながらプログラムを実行してもよい。なお、上記実施の形態におけるサーバ１を実現するソフトウェアは、以下のようなプログラムである。つまり、このプログラムは、食材ごとの使用量を含む複数のレシピ情報、及び食材の単位量当たりの価格を、食材の取引に関する属性ごとに有する複数の食材価格情報にアクセス可能なコンピュータを、レシピ情報を識別するレシピ識別子を含む情報であり、レシピ情報の料理に使用される食材の合計価格の送信を要求する情報である要求情報をユーザから受信する受信部、要求情報の受信に基づいて、食材の取引に関する属性を取得する取得部、受信された要求情報に含まれるレシピ識別子によって識別されるレシピ情報、及び取得部によって取得された属性に対応する単位量当たりの価格を用いて、レシピ情報の料理に使用される食材の合計価格を算出する算出部、算出部によって算出された合計価格を送信する送信部として機能させるためのプログラムである。

なお、上記プログラムにおいて、上記プログラムが実現する機能には、ハードウェアでしか実現できない機能は含まれない。例えば、情報を取得する取得部や、情報を受信する受信部、情報を送信する送信部などにおけるモデムやインターフェースカードなどのハードウェアでしか実現できない機能は、上記プログラムが実現する機能には少なくとも含まれない。

また、このプログラムは、サーバなどからダウンロードされることによって実行されてもよく、所定の記録媒体（例えば、ＣＤ－ＲＯＭなどの光ディスクや磁気ディスク、半導体メモリなど）に記録されたプログラムが読み出されることによって実行されてもよい。また、このプログラムは、プログラムプロダクトを構成するプログラムとして用いられてもよい。

また、このプログラムを実行するコンピュータは、単数であってもよく、複数であってもよい。すなわち、集中処理を行ってもよく、または分散処理を行ってもよい。

図９は、上記プログラムを実行して、上記実施の形態によるサーバ１を実現するコンピュータの外観の一例を示す模式図である。上記実施の形態は、コンピュータハードウェア及びその上で実行されるコンピュータプログラムによって実現されうる。

図９において、コンピュータシステム９００は、ＣＤ－ＲＯＭドライブ９０５を含むコンピュータ９０１と、キーボード９０２と、マウス９０３と、モニタ９０４とを備える。

図１０は、コンピュータシステム９００の内部構成を示す図である。図１０において、コンピュータ９０１は、ＣＤ－ＲＯＭドライブ９０５に加えて、ＭＰＵ（Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）９１１と、ブートアッププログラム等のプログラムを記憶するためのＲＯＭ９１２と、ＭＰＵ９１１に接続され、アプリケーションプログラムの命令を一時的に記憶すると共に、一時記憶空間を提供するＲＡＭ９１３と、アプリケーションプログラム、システムプログラム、及びデータを記憶するハードディスク９１４と、ＭＰＵ９１１、ＲＯＭ９１２等を相互に接続するバス９１５とを備える。なお、コンピュータ９０１は、ＬＡＮやＷＡＮ等への接続を提供する図示しないネットワークカードを含んでいてもよい。

コンピュータシステム９００に、上記実施の形態によるサーバ１の機能を実行させるプログラムは、ＣＤ－ＲＯＭ９２１に記憶されて、ＣＤ－ＲＯＭドライブ９０５に挿入され、ハードディスク９１４に転送されてもよい。これに代えて、そのプログラムは、図示しないネットワークを介してコンピュータ９０１に送信され、ハードディスク９１４に記憶されてもよい。プログラムは実行の際にＲＡＭ９１３にロードされる。なお、プログラムは、ＣＤ－ＲＯＭ９２１、またはネットワークから直接、ロードされてもよい。また、ＣＤ－ＲＯＭ９２１に代えて他の記録媒体（例えば、ＤＶＤ等）を介して、プログラムがコンピュータシステム９００に読み込まれてもよい。

プログラムは、コンピュータ９０１に、上記実施の形態によるサーバ１の機能を実行させるオペレーティングシステム（ＯＳ）、またはサードパーティプログラム等を必ずしも含んでいなくてもよい。プログラムは、制御された態様で適切な機能やモジュールを呼び出し、所望の結果が得られるようにする命令の部分のみを含んでいてもよい。コンピュータシステム９００がどのように動作するのかについては周知であり、詳細な説明は省略する。

また、以上の実施の形態は、本発明を具体的に実施するための例示であって、本発明の技術的範囲を制限するものではない。本発明の技術的範囲は、実施の形態の説明ではなく、特許請求の範囲によって示されるものであり、特許請求の範囲の文言上の範囲及び均等の意味の範囲内での変更が含まれることが意図される。

１ サーバ
１１ 記憶部
１２ 受信部
１３ 取得部
１４ 算出部
１５ 送信部
１６ 追加部

Claims (10)

1. 食材ごとの使用量を含む複数のレシピ情報、及び食材の単位量当たりの価格を、当該食材の取引に関する属性ごとに有する複数の食材価格情報にアクセス可能なサーバであって、
   レシピ情報を識別するレシピ識別子を含む情報であり、当該レシピ情報の料理に使用される食材の合計価格の送信を要求する情報である要求情報をユーザから受信する受信部と、
   要求情報に含まれる情報または要求情報の受信時点に基づいて、食材の取引に関する属性を取得する取得部と、
   受信された要求情報に含まれるレシピ識別子によって識別されるレシピ情報に含まれる食材ごとに、食材の使用量と、前記取得部によって取得された属性に対応する当該食材の単位量当たりの価格とを乗算して当該食材の価格を算出し、当該食材ごとの価格を合計することによって、当該レシピ情報の料理に使用される食材の合計価格を算出する算出部と、
   前記算出部によって算出された合計価格を送信する送信部と、を備えたサーバ。
2. 前記算出部は、前記レシピ情報に含まれる食材ごとの価格をも算出し、
   前記送信部は、前記算出部によって算出された食材ごとの価格をも送信する、請求項１記載のサーバ。
3. 前記サーバは、食材である商品ごとの販売に関する価格、量、日時、及び店舗を含む複数の販売情報、及び商品と食材との対応を示す複数の対応情報にアクセス可能であり、
   前記複数の販売情報、及び前記複数の対応情報を用いて、食材の単位量当たりの価格を、当該食材の取引に関する属性ごとに有する食材価格情報を取得して前記複数の食材価格情報に追加する追加部をさらに備えた、請求項１記載のサーバ。
4. 前記受信部は、受信した要求情報に含まれるレシピ識別子によって識別されるレシピ情報に含まれる食材のうち、ユーザが購入する必要のない食材を示す不要食材情報をも受信し、
   前記算出部は、受信された不要食材情報に応じて、ユーザが購入する必要のない食材以外の食材の合計価格を算出する、請求項１記載のサーバ。
5. 前記送信部は、合計価格を、当該合計価格に対応するレシピ情報と共に送信する、請求項１記載のサーバ。
6. 前記属性は、食材の取引される地域を含んでおり、
   前記取得部は、受信された要求情報を送信したユーザに対応する地域を含む属性を取得する、請求項１から請求項５のいずれか記載のサーバ。
7. 前記属性は、食材を販売する小売の価格帯を含んでおり、
   前記取得部は、受信された要求情報を送信したユーザに対応する小売の価格帯を含む属性を取得する、請求項１から請求項５のいずれか記載のサーバ。
8. 前記属性は、食材の取引される時期を含んでおり、
   前記取得部は、受信された要求情報に対応する時期を含む属性を取得する、請求項１から請求項５のいずれか記載のサーバ。
9. 受信部と、取得部と、算出部と、送信部とを用いて処理される合計価格算出方法であって、
   前記受信部が、レシピ情報を識別するレシピ識別子を含む情報であり、当該レシピ情報の料理に使用される食材の合計価格の送信を要求する情報である要求情報をユーザから受信するステップと、
   前記取得部が、要求情報に含まれる情報または要求情報の受信時点に基づいて、食材の取引に関する属性を取得するステップと、
   前記算出部が、食材ごとの使用量を含む複数のレシピ情報、及び食材の単位量当たりの価格を、当該食材の取引に関する属性ごとに有する複数の食材価格情報にアクセスして、受信された要求情報に含まれるレシピ識別子によって識別されるレシピ情報に含まれる食材ごとに、食材の使用量と、取得された属性に対応する当該食材の単位量当たりの価格とを乗算して当該食材の価格を算出し、当該食材ごとの価格を合計することによって、当該レシピ情報の料理に使用される食材の合計価格を算出するステップと、
   前記送信部が、算出された合計価格を送信するステップと、を備えた合計価格算出方法。
10. 食材ごとの使用量を含む複数のレシピ情報、及び食材の単位量当たりの価格を、当該食材の取引に関する属性ごとに有する複数の食材価格情報にアクセス可能なコンピュータを、
    レシピ情報を識別するレシピ識別子を含む情報であり、当該レシピ情報の料理に使用される食材の合計価格の送信を要求する情報である要求情報をユーザから受信する受信部、
    要求情報に含まれる情報または要求情報の受信時点に基づいて、食材の取引に関する属性を取得する取得部、
    受信された要求情報に含まれるレシピ識別子によって識別されるレシピ情報に含まれる食材ごとに、食材の使用量と、前記取得部によって取得された属性に対応する当該食材の単位量当たりの価格とを乗算して当該食材の価格を算出し、当該食材ごとの価格を合計することによって、当該レシピ情報の料理に使用される食材の合計価格を算出する算出部、
    前記算出部によって算出された合計価格を送信する送信部として機能させるためのプログラム。

Images