JP7340131B2 - 情報処理装置 - Google Patents

Description

本発明は、情報処理装置に関する。

従来より、各種情報をマッチングさせるシステム（特許文献１参照）は存在する。

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

しかしながら、特許文献１の技術を含む従来の技術では、生鮮食品のように、取引の直前になるまで取引の内容が確定されない商品を効率良くマッチングさせることはできない。このため、地元で採れた生産物を使用する使用者と、その使用者に対し地元産の生産物を提供する生産者との関係の円滑化を図ることができない。

本発明は、このような状況に鑑みてなされたものであり、地元で採れた生産物を使用する使用者と、その使用者に対し地元産の生産物を提供する生産者との関係を円滑化させて、地元の価値を見出すことができる新たな仕組みを提供することを目的とする。

上記目的を達成するため、本発明の一態様の情報処理装置は、
１以上の生産者の夫々により生産され、出荷できることが確定した１以上の生産物の夫々の内容を示す情報を、出荷確定情報として受け付ける確定受付手段と、
受け付けられた１以上の前記出荷確定情報を、前記生産物を使用し得る１以上の使用者に提示する確定提示手段と、
前記１以上の使用者のうち少なくとも一部から、生産物を購入する旨の提示があった場合に、これを注文として受け付ける注文受付手段と、
前記提示をした前記生産者に対し、前記注文が受け付けられた旨を提示する注文提示手段と、
受け付けられた前記注文に基づいて、当該注文の対象を少なくとも含む、出荷できることが確定した前記生産物の集荷及び配送のルートを生成するルート生成手段と、
を備える。

本発明によれば、地元で採れた生産物を使用する使用者と、その使用者に対し地元産の生産物を提供する生産者との関係を円滑化させて、地元の価値を見出すことができる新たな仕組みを提供することができる。

本発明の情報処理装置を適用したサービスの概要の例を示す図である。 本発明の情報処理装置の一実施形態に係るサーバを含む情報処理システムの構成の概要を示す図である。 図２のサーバのハードウェア構成を示すブロック図である。 図３のサーバの機能的構成の一例を示す機能ブロック図である。 図４のサーバが実行する確定前処理、及び確定後処理の流れを説明するフローチャートである。 図４の生産者端末に表示される、出荷確定情報の入力画面の具体例を示す図である。 図４のレストラン端末に表示される、注文の内容を入力する画面の具体例を示す図である。 図４の配送端末に表示される、野菜の集荷及び配送に必要となる集荷配送ルート、及びこの集荷配送ルートが反映された地図の具体例を示す図である。

以下、本発明の実施形態について図面を用いて説明する。

［サービス内容］
本発明の情報処理装置を適用したサービス（以下、「本サービス」と呼ぶ）の流れについて説明する。
図１は、本サービスの概要を示すイメージ図である。

本サービスは、サービス提供者Ｍが提供する所定地域（地元）に密着したサービスであり、例えば地元で採れた野菜を使用した料理を提供するレストランＲに対し、その生産者Ｐの顔が見える安全で新鮮な野菜を効率良く供給することを目的としたサービスである。
昨今のビジネスでは、生産者よりも卸売業者、卸売業者よりも小売業者といったように、より消費者に近いところでビジネスを行う者が立場的に強くなっている。このため、ものづくりの根本を担う生産者の価値が総じて評価されていない。その結果、商品の品質を追求するよりも、例えばＩＴを駆使した上手な売り方を追求した方がよく売れるという状況が生み出されている。これは、消費者が、商品を選択して購入する際に、テレビやインターネットに氾濫する不確かな商品評価に対し必要以上に信頼を寄せているからである。
しかしながら、商品を購入する者は、１人１人個性を有しているため、ものの見方も千差万別である。このため、ものの価値は、評価する者によって異なるのが通常であり、全ての者が同じ評価をすることは本来ありえない。即ち、夫々の者が「自分はこれが好き」という自分自身の考えに自信を持つとともに、夫々の者の意見に互い耳を傾けることができる社会が本来あるべき社会である。
そのためには、都会中心のみのビジネスではなく、例えば農業を中心とした地方の産業に目を向けて、地元の価値を見出すことができる新たな仕組みを設けることが重要である。地元で採れた野菜を使用した料理を提供するレストランと、そのレストランに対し地元産の野菜を提供する生産者との関係を円滑化させる仕組みは、地元の価値を見出すことができる新たな仕組みの一例である。
このような状況の下、本サービスが提供されることにより、地元のレストランを訪れた人々に対し、地元で採れた新鮮な野菜を使用した美味しい料理を提供することができる。その結果、地産地消を実現させることができるとともに、料理の提供を受けた人々の地元意識を醸成させることができる。

本サービスの提供を受けるユーザとしては、生産者Ｐと、配送業者Ｌと、使用者（図１の例ではレストランＲ）とが含まれる。
生産者Ｐは、販売対象のもの（ここでは野菜）の生産を行う者であり、農家、農業法人等が含まれる。
ここで、「野菜の生産」とは、野菜を栽培し、収穫するまでの一連の行為をいう。生産された野菜は出荷される。
配送業者Ｌは、生産者Ｐにより生産された野菜をレストランＲに配送する者である。
レストランＲは、配送業者Ｌにより配送された野菜を使用した料理を提供する者である。なお、レストランＲは、生産者Ｐにより生産されたものを使用する使用者の一例である。即ち、本サービスの提供を受ける者は、レストランＲに限定されず、生産者Ｐにより生産されたもの（野菜に限らない）を使用する使用者も含まれる。
ただし、以下、説明の便宜上、断りのない限り、本サービスのユーザは、野菜を生産する生産者Ｐと、その野菜を配送する配送業者Ｌと、その野菜を使用した料理を提供するレストランＲとであるものとする。

本サービスは、出荷される野菜の種類、量、及び出荷のタイミングが、生産者Ｐによって確定される前と後との２段階にわたって提供されるサービスである。以下、出荷される野菜の種類、量、及び出荷のタイミングが、生産者Ｐによって確定されることを「出荷内容が確定する」、又は「出荷内容確定」と表現する。
即ち、野菜は、出荷する日の早朝に収穫してそのまま出荷することが多いため、天候や温度といったその日の状況が生育に影響を与える。その結果、出荷可能な野菜の種類、量、出荷のタイミングについては、その日の朝になってみなければ確定できないことが多い。
そこで、本サービスは、出荷内容確定前と、出荷内容確定後との２段階に分けて提供される。
ただし、出荷内容確定前のサービスは、本サービスにとって必須ではなく、適宜省略されてもよい。

（出荷内容確定前）
出荷内容が確定する前は、ステップＳＳ１において、レストランＲは、サービス提供者Ｍに対し、料理に使用する野菜の具体的内容と、野菜を使用するタイミングとを含む、料理に使用しようと予定している野菜に関する情報を提供する。具体的には例えば、レストランＲは、顧客からの予約に基づいて、「明後日のディナータイムで使用する、新鮮なトマト２５個の購入の予約を行いたい」といった情報をサービス提供者Ｍに提示する。

ステップＳＳ２において、サービス提供者Ｍは、レストランＲにより提示された情報を、事前予約として受け付ける。ただし、事前予約は、レストランＲの顧客からの予約等を根拠とする予定に過ぎず、レストランＲからの注文を確約するものではない。つまり、事前予約は、顧客からの予約のキャンセル等により変動する可能性の高い情報に基づいたものとなるため、例えば事前予約時がなされた野菜の価格を割高に設定することもできる。
ステップＳＳ３において、サービス提供者Ｍは、取得した事前予約の内容を生産者Ｐに提供する。

ステップＳＳ４において、生産者Ｐは、サービス提供者Ｍに対し、出荷可能と予測される野菜の種類と、量と、出荷のタイミングとを含む、生産した野菜に関する予測情報を提供する。具体的には例えば、生産者Ｐは、「トマトを１００個、明後日の朝８：００頃出荷可能と予測できる」といった情報をサービス提供者Ｍに提供する。

ステップＳＳ５において、サービス提供者Ｍは、生産者Ｐから提供された情報を、出荷予測情報として取得する。ただし、出荷予測情報は、野菜の生育状況を見た生産者Ｐの主観的な予測に過ぎず、生産者Ｐからの出荷を確約するものではない。つまり、出荷予測情報は、天候の変化等により変動する可能性の高い不確定情報となる。
ここで、サービス提供者Ｍは、出荷予測情報を取得するタイミングを固定してもよい。例えば、毎日午後８：００の時点における出荷予測情報を一斉に取得するようにしてもよい。
ステップＳＳ６において、サービス提供者Ｍは、取得した出荷予定情報をレストランＲに提供する。
ここで、サービス提供者Ｍは、出荷予測情報を提示するタイミングを固定してもよい。例えば、毎日午後８：３０の時点で出荷予測情報を一斉に公開するようにしてもよい。

なお、ステップＳＳ１乃至ＳＳ３と、ステップＳＳ４乃至ＳＳ６とは順番が逆であってもよい。つまり、レストランＲは、出荷予測情報が提供される前に、自らの発案に基づいて料理の内容を決めることもできるし、提供された出荷予測情報を参考にしながら料理の内容を決めることもできる。また、生産者Ｐは、出荷可能と予測される野菜の種類、量、及び出荷のタイミングを決める際に、提供された事前予約の内容を参考にすることもできるし、自らの判断に基づいて、出荷可能と予測される野菜の種類、量、及び出荷のタイミングを決めることもできる。

このように、出荷内容が確定する前は、レストランＲ及び生産者Ｐの夫々から、生産者Ｐ及びレストランＲの夫々に対し、未確定ではあるが予測可能な情報が提供される。これにより、生産者Ｐは、提供された事前予約の内容に基づいて、今後の収穫予定を立案することができる。また、レストランＲは、提供された出荷予測情報に基づいて、メニューを立案することができるようになる。

（出荷内容確定後）
出荷内容が確定した後は、ステップＳＳ７において、生産者Ｐは、サービス提供者Ｍに対し、出荷可能な野菜の品種、品質（例えば大きさや出来具合）、数量、価格、撮像画像、出荷可能なタイミング等を含む、生産した野菜に関する情報を提供する。具体的には例えば、生産者Ｐは、「トマト（大）を１００個○○円で本日の朝８：００頃出荷できる」といった文字情報と、撮像画像とをサービス提供者Ｍに提供する。
ここで、サービス提供者Ｍは、出荷確定情報を取得するタイミングを固定してもよい。例えば、毎日午前７：００の時点における出荷確定情報を一斉に取得するようにしてもよい。

ステップＳＳ８において、サービス提供者Ｍは、生産者Ｐから提供された情報を、出荷確定情報として取得する。
ステップＳＳ９において、サービス提供者Ｍは、取得した出荷確定情報をレストランＲに提供する。
ここで、出荷確定情報がレストランＲに提供されるタイミングは、サービス提供者Ｍにより任意に決定される。サービス提供者Ｍは、出荷確定情報を提示するタイミングを固定してもよい。例えば、毎日午前７：３０の時点で出荷確定情報を一斉に公開するようにしてもよい。

ステップＳＳ１０において、レストランＲ１乃至Ｒｍ（ｍは１以上の任意の整数値）の夫々は、提供された出荷確定情報を見ながら所望の野菜を注文する。具体的には例えば、レストランＲは、「トマト２５個を注文する。納期は本日の午後４：００とする」といった情報をサービス提供者Ｍに提示する。

ステップＳＳ１１において、サービス提供者Ｍは、レストランＲにより提示された情報を、注文として受け付ける。ここで、同じ商品について複数の注文があった場合には、注文のタイミングが一番早かったレストランＲがその商品を購入できることとなる。
ステップＳＳ１２において、サービス提供者Ｍは、取得した注文の内容を生産者Ｐに提示する。ここで、生産者Ｐが受注可能であれば、その旨をサービス提供者Ｍを介してレストランＲに提示する。これにより、レストランＲと生産者Ｐとの間の売買契約を成立させることができる。
ステップＳＳ１３において、サービス提供者Ｍは、売買契約が成立した注文に基づいて、対象となる野菜の集荷及び配送に必要となる集荷配送ルート、及びこの集荷配送ルートが反映された地図を生成する。

ステップＳＳ１４において、配送業者Ｌは、生成された地図に反映された集荷配送ルートに従って、生産者Ｐ１乃至Ｐｎ（ｎは１以上の任意の整数値）を訪問しながら野菜の集荷を行う。また、配送業者Ｌは、レストランＲ１乃至Ｒｍに対する野菜の配送を行う。
なお、配送業者Ｌが生産者Ｐから集荷する野菜は、ステップＳＳ１３で売買契約が成立したものに限定されない。売買契約の対象となっていない野菜を集荷配送してもよい。
これにより、売買契約の対象となっている野菜をレストランＲ１乃至Ｒｍに配送するとともに、売買契約の対象となっていない野菜をレストランＲ１乃至Ｒｍに直接販売することもできる。その結果、レストランＲ１のシェフは、売買契約の対象となっていない野菜を直接品定めして購入することもできる。

また、配送業者Ｌによる配送に、専門家（図示せず）を同行させて、野菜の特性に関する情報をレストランＲに提供するサービスを行ってもよい。
また、集荷配送ルートの前半に位置するレストランＲと、後半に位置するレストランＲとの間では、直接購入できる野菜の種類や鮮度等に差が生じてしまうため、集荷配送ルートを定期的に変更してもよい。

本サービスが提供されることにより、以下のような効果を期待することもできる。
即ち、出荷確定情報に基づいて立案された料理の具体的内容は、レストランＲの広告に用いることもできるし、レストランＲが所在する地元の地域おこしに活用することもできる。レストランＲの広告を見た地元の人々が、レストランＲに足を運べば、地元で採れた新鮮な野菜を使用した美味しい料理を堪能することができる。その結果、地産地消を実現させることができるとともに、料理を堪能した地元の人々における地元意識を醸成させることもできる。

また、生産者Ｐの立場からすれば、レストランＲという直接的な販売先が増えるので、安心して作付けを行うことができる。その結果、地元産の野菜の生産量を増やすことができる。
さらに、生産量が多いために供給過多となり売れ残ってしまった野菜については、サービス提供者Ｍが買い取ったうえで加工・消費することもできる。具体的には例えば、サービス提供者Ｍが、売れ残ってしまった野菜について、生産者希望価格の５０乃至７０％、あるいは地元の農業協同組合の買取価格で買い取るようにしてもよい。そして、サービス提供者Ｍが買い取った野菜は、例えばサービス提供者Ｍの店舗等の社員食堂等で加工・消費するようにしてもよい。また、地元のスーパーマーケットや八百屋等の店内に「直売コーナー」を設け、売れ残ってしまった野菜をそこで販売してもよい。ここで、従来であれば、直売コーナーで販売される野菜は、生産者Ｐが自ら運んでいたが、この配送業務を配送業者Ｌが行うことにより、生産者Ｐの負担を減らすことができる。その結果、生産者Ｐにおける、本サービスへの安心感を構築することができる。

また、レストランＲを利用する地元の人々の立場からすれば、以下のような効果を期待することもできる。
即ち、生産者Ｐが主導的に提供する出荷予測情報や出荷確定情報に基づいて受発注が行われることになるため、流通の中心は、季節の旬の野菜となる。その結果、レストランＲを利用する地元の人々は、レストランＲで旬の野菜を中心に食べることになる。このため、食べたいものを食べたいときに食べれるだけ食べるのではなく、その年々の本当の旬を肌で感じることができる野菜を使用した、文化的で健康的な食事をとることができるようになる。

［システム構成］
図２は、本発明の情報処理装置の一実施形態に係るサーバ１を含む情報処理システムの構成の概要を示す図である。

図２に示す情報処理システムは、サーバ１と、生産者端末２－１乃至２－ｎと、レストラン端末３－１乃至３－ｍと、配送端末４とが、インターネット等の所定のネットワークＮを介して相互に接続されることで構成される。
サーバ１は、本サービスを提供するサービス提供者Ｍが管理する情報処理装置である。サーバ１は、生産者端末２－１乃至２－ｎ、及びレストラン端末３－１乃至３－ｍの各動作を管理すべく、各種処理を実行する。
生産者端末２－１乃至２－ｎの夫々は、生産者Ｐ１乃至Ｐｎの夫々が操作する情報処理装置であって、例えばパーソナルコンピュータ、スマートフォン、タブレット等で構成される。
レストラン端末３－１乃至３－ｍの夫々は、レストランＲ１乃至Ｒｍの夫々が操作する情報処理装置であって、例えばパーソナルコンピュータ、スマートフォン、タブレット等で構成される。
なお、以下、生産者Ｐ１乃至Ｐｎ、生産者端末２－１乃至２－ｎ、レストランＲ１乃至Ｒｍ、及びレストラン端末３－１乃至３－ｍの夫々を個々に区別する必要がない場合、これらをまとめて、「生産者Ｐ」、「生産者端末２」、「レストランＲ」、及び「レストラン端末３」の夫々と呼ぶ。
配送端末４は、配送業者Ｌが操作する情報処理装置であり、サーバ１により生成された、集荷配送ルート、及びこの集荷配送ルートが反映された地図を表示する。配送業者Ｌは、この地図にある集荷配送ルートに従って、集荷配送を行う。

［ハードウェア構成］
次に、本サービスを提供するために各種処理を実行するサーバ１のハードウェア構成について説明する。
図３は、図２のサーバ１のハードウェア構成を示すブロック図である。

サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３と、バス１４と、入出力インターフェース１５と、出力部１６と、入力部１７と、記憶部１８と、通信部１９と、ドライブ２０とを備えている。

ＣＰＵ１１は、ＲＯＭ１２に記録されているプログラム、又は、記憶部１８からＲＡＭ１３にロードされたプログラムに従って各種の処理を実行する。
ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

ＣＰＵ１１、ＲＯＭ１２及びＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インターフェース１５も接続されている。入出力インターフェース１５には、出力部１６、入力部１７、記憶部１８、通信部１９及びドライブ２０が接続されている。

出力部１６は各種液晶ディスプレイ等で構成され、各種情報を出力する。
入力部１７は、各種ハードウェア鉛等で構成され、各種情報を入力する。
記憶部１８は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部１９は、インターネットを含むネットワークＮを介して他の装置（例えば図１の生産者端末２－１乃至２－ｎ、レストラン端末３－１乃至３－ｍ、及び配送端末４）との間で行う通信を制御する。

ドライブ２０は、必要に応じて設けられる。ドライブ２０には磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア４０が適宜装着される。ドライブ２０によってリムーバブルメディア４０から読み出されたプログラムは、必要に応じて記憶部１８にインストールされる。またリムーバブルメディア４０は、記憶部１８に記憶されている各種データも、記憶部１８と同様に記憶することができる。

［機能的構成］
次に、サーバ１の機能について、図４を参照して説明する。
図４は、図３のサーバ１の機能的構成の一例を示す機能ブロック図である。

図４に示すように、サーバ１のＣＰＵ１１においては、確定前処理が実行される場合には、予測受付部１０１と、予測提示部１０２と、予約受付部１０３と、予約提示部１０４とが機能する。確定後処理が実行される場合には、確定受付部１０５と、確定提示部１０６と、注文受付部１０７と、注文提示部１０８と、ルート生成部１０９とが機能する。
記憶部１８の一領域には、ユーザＤＢ４０１と、生産物ＤＢ４０２とが設けられている。

確定前処理とは、出荷内容が確定する前に、サーバ１により実行される処理であり、レストランＲからの事前予約と、生産者Ｐからの出荷予測情報とを受け付ける処理、及びこれに関連する処理のことをいう。

確定後処理とは、出荷内容が確定した後に、サーバ１により実行される処理であり、レストランＲからの注文情報と、生産者Ｐからの出荷確定情報とを受け付ける処理、及びこれに関連する処理のことをいう。

（ＣＰＵ）
予測受付部１０１は、１以上の生産者の夫々により生産され、出荷することができると予測される１以上の生産物の夫々の内容を示す情報を、出荷予測情報として受け付ける。
具体的には、予測受付部１０１は、生産者Ｐ１乃至Ｐｎの夫々により生産され、出荷することができると予測される１以上の野菜の夫々の内容を示す情報を、出荷予測情報として受け付ける。受け付けられた出荷予測情報は、生産物ＤＢ４０２に記憶されて管理される。

予測提示部１０２は、受け付けられた１以上の出荷予測情報を、生産物を使用する１以上の使用者に提示する。
具体的には、予測提示部１０２は、受け付けられた１以上の出荷予測情報を、レストランＲ１乃至Ｒｍに提示する。これにより、レストランＲ１乃至Ｒｍは、料理の内容を考える際の参考情報の１つとして、出荷予測情報を活用することができる。

予約受付部１０３は、生産物を使用する１以上の使用者から、生産物の購入の予約をしたい旨の提示があった場合に、これを事前予約として受け付ける。
具体的には、予約受付部１０３は、レストランＲ１乃至Ｒｍから、野菜の購入の予約をしたい旨の提示があった場合に、これを事前予約として受け付ける。

予約提示部１０４は、１以上の生産者に対し、事前予約が受け付けられた旨を提示する。
具体的には、予約提示部１０４は、生産者Ｐ１乃至Ｐｎに対し、レストランＲ１乃至Ｒｍからの事前予約が受け付けられた旨を提示する。

確定受付部１０５は、１以上の生産者の夫々により生産され、出荷できることが確定した１以上の生産物の夫々の内容を示す情報を、出荷確定情報として受け付ける。受け付けられた出荷確定情報は、生産物ＤＢ４０２に記憶されて管理される。
具体的には、確定受付部１０５は、生産者Ｐ１乃至Ｐｎの夫々により生産され、出荷できることが確定した１以上の野菜の夫々の内容を示す情報を、出荷確定情報として受け付ける。

確定提示部１０６は、受け付けられた１以上の出荷確定情報を、生産物を使用する１以上の使用者に提示する。
具体的には、確定提示部１０６は、受け付けられた１以上の出荷確定情報を、レストランＲ１乃至Ｒｍに提示する。これにより、レストランＲ１乃至Ｒｍは、料理の内容を決定する際の根拠情報の１つとして、出荷確定情報を活用することができる。

注文受付部１０７は、生産物を使用する１以上の使用者から、生産物を購入する旨の提示があった場合に、これを注文として受け付ける。
具体的には、予約受付部１０３は、レストランＲ１乃至Ｒｍから、野菜の購入の予約をしたい旨の提示があった場合に、これを事前予約として受け付ける。

注文提示部１０８は、１以上の生産者に対し、注文が受け付けられた旨を提示する。
具体的には、注文提示部１０８は、生産者Ｐ１乃至Ｐｎに対し、レストランＲ１乃至Ｒｍからの注文が受け付けられた旨を提示する。

ルート生成部１０９は、売買契約が成立した注文に基づいて、売買契約の対象となる生産物の集荷及び配送に必要となる地図情報を生成する。
具体的には、ルート生成部１０９は、売買契約が成立した注文に基づいて、売買契約の対象となる野菜の集荷及び配送に必要となる集荷配送ルート、及びこの集荷配送ルートが反映された地図を生成する。

（記憶部）
ユーザＤＢ４０１には、本サービスにユーザ登録されたユーザ（生産者Ｐ、レストランＲ、及び配送業者Ｌ）に関する情報（以下、「ユーザ情報」と呼ぶ）が記憶され管理されている。ユーザ情報には、本サービスにユーザ登録されたユーザを一意に識別する情報（ＩＤ等）、名前、会社名、住所、連絡先等の情報が含まれる。

生産物ＤＢ４０２には、本サービスにおいて商品として取引される生産物に関する情報が記憶され管理されている。生産物情報には、生産者Ｐから提示された、出荷予測情報、出荷確定情報等が記憶され管理されている。

［フローチャート］

次に、図５を参照して、図４の機能的構成を有するサーバ１が実行する各種処理について説明する。
図５は、図４のサーバ１が実行する確定前処理、及び確定後処理の流れを説明するフローチャートである。

図５（Ａ）は、確定前処理の流れを説明するフローチャートである。
図５（Ａ）に示すように、サーバ１では、次のような一連の処理が実行される。
ステップＳ１において、予測受付部１０１は、１以上の生産者の夫々により生産され、出荷することができると予測される１以上の生産物の夫々の内容を示す情報を、出荷予測情報として受け付ける。具体的には、予測受付部１０１は、生産者Ｐ１乃至Ｐｎの夫々により生産され、出荷することができると予測される１以上の野菜の夫々の内容を示す情報を、出荷予測情報として受け付ける。
ステップＳ２において、予測提示部１０２は、受け付けられた１以上の出荷予測情報を、生産物を使用する１以上の使用者に提示する。具体的には、予測提示部１０２は、受け付けられた１以上の出荷予測情報を、レストランＲ１乃至Ｒｍに提示する。
ステップＳ３において、予約受付部１０３は、生産物を使用する１以上の使用者から、生産物の購入の予約をしたい旨の提示があった場合に、これを事前予約として受け付ける。具体的には、予約受付部１０３は、レストランＲ１乃至Ｒｍから、野菜の購入の予約をしたい旨の提示があった場合に、これを事前予約として受け付ける。
ステップＳ４において予約提示部１０４は、１以上の生産者に対し、事前予約が受け付けられた旨を提示する。具体的には、予約提示部１０４は、生産者Ｐ１乃至Ｐｎに対し、レストランＲ１乃至Ｒｍからの事前予約が受け付けられた旨を提示する。これにより、登録前処理は終了する。

図５（Ｂ）は、確定後処理の流れを説明するフローチャートである。
図５（Ｂ）に示すように、サーバ１では、次のような一連の処理が実行される。
ステップＳ１１において、確定受付部１０５は、１以上の生産者の夫々により生産され、出荷できることが確定した１以上の生産物の夫々の内容を示す情報を、出荷確定情報として受け付ける。具体的には、確定受付部１０５は、生産者Ｐ１乃至Ｐｎの夫々により生産され、出荷できることが確定した１以上の野菜の夫々の内容を示す情報を、出荷確定情報として受け付ける。
ステップＳ１２において、確定提示部１０６は、受け付けられた１以上の出荷確定情報を、生産物を使用する１以上の使用者に提示する。具体的には、確定提示部１０６は、受け付けられた１以上の出荷確定情報を、レストランＲ１乃至Ｒｍに提示する。
ステップＳ１３において、注文受付部１０７は、生産物を使用する１以上の使用者から、生産物を購入する旨の提示があった場合に、これを注文として受け付ける。具体的には、予約受付部１０３は、レストランＲ１乃至Ｒｍから、野菜の購入の予約をしたい旨の提示があった場合に、これを事前予約として受け付ける。
ステップＳ１４において、注文提示部１０８は、１以上の生産者に対し、注文が受け付けられた旨を提示する。具体的には、注文提示部１０８は、生産者Ｐ１乃至Ｐｎに対し、レストランＲ１乃至Ｒｍからの注文が受け付けられた旨を提示する。
ステップＳ１５において、ルート生成部１０９は、売買契約が成立した注文に基づいて、売買契約の対象となる生産物の集荷及び配送に必要となる地図情報を生成する。具体的には、ルート生成部１０９は、売買契約が成立した注文に基づいて、売買契約の対象となる野菜の集荷及び配送に必要となる集荷配送ルート、及びこの集荷配送ルートが反映された地図を生成する。これにより、確定後処理は終了する。

［具体例］
次に、図６乃至図８を参照して、生産者端末２、レストラン端末３、及び配送端末４の夫々に表示されるＧＵＩ（グラフィカルユーザインタフェース）の具体例について説明する。
図６は、生産者端末２に表示される、出荷確定情報の入力画面の具体例を示す図である。

図６に示すように、出荷確定情報の入力画面には、生産した野菜に関する情報として、出荷可能な野菜の品種、品質（例えば大きさや出来具合）、数量、価格、及び出荷可能な日時の夫々を入力するための入力欄Ｈ１と、生産した野菜の撮像画像を登録するためのボタンＢ１が設けられている。
生産者Ｐは、入力欄Ｈ１に所定事項を入力するとともに、ボタンＢ１を押下することで、予め撮像しておいた野菜の撮像画像に基づく情報を登録する。
これにより、出荷確定情報がサーバ１に送信されるので、生産者Ｐは、サービス提供者Ｍに出荷確定情報を容易に提示することができる。
なお、図６のＧＵＩは、出荷確定後における、出荷確定情報の入力画面の具体例を示す図であるが、出荷確定前における、出荷予測情報を入力する画面についても、野菜の撮像画像を登録するボタンＢ１を除き、図６のＧＵＩと同様又は略同様の構成とすることができる。

図７は、レストラン端末３に表示される、注文の内容を入力する画面の具体例を示す図である。

図７に示すように、注文の内容を入力する画面には、注文する野菜に関する情報として、購入したい野菜の品種、品質（例えば大きさや出来具合）、数量、価格、及び納期の夫々を入力するための入力欄Ｈ２が設けられている。
レストランＲは、入力欄Ｈ２に所定事項を入力する。これにより、注文の内容がサーバ１に送信されるので、レストランＲは、サービス提供者Ｍに対し、生産物を購入する旨を容易に提示することができる。
なお、図７のＧＵＩは、出荷確定後における、注文の内容を入力する画面の具体例を示す図であるが、出荷確定前における、事前予約の内容を入力する画面についても、図７のＧＵＩと同様又は略同様の構成とすることができる。

図８は、配送端末４に表示される、野菜の集荷及び配送に必要となる集荷配送ルート、及びこの集荷配送ルートが反映された地図の具体例を示す図である。

図８に示すように、配送端末４には、配送業者Ｌが野菜を集荷して配送するまでの一連のルートが表示される。これにより、配送業者Ｌは、配送端末４に表示された集荷配送ルートに沿って集荷及び配送することで落ち度なく業務を遂行することができる。特に、上述したように、集荷配送ルートは定期的に変更されるため、配送業者Ｌが集荷及び配送の順番を間違うおそれがある。このため、配送業者Ｌは、配送端末４に表示された集荷配送ルートに忠実に集荷及び配送することで順番を間違えることなく業務を遂行することができる。

具体的には、図８の例では、配送業者Ｌは、生産者Ｐ１乃至Ｐ５の順番で集荷し、その後、レストランＲ１乃至Ｒ３の順番で配送する。これにより、配送業者Ｌは、配送端末４に表示された集荷配送ルートに忠実に集荷及び配送することで順番を間違えることなく業務を遂行することができる。

以上、本発明の一実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。

例えば、上述の実施形態では、生産物を「野菜」としているが、これは例示にすぎない。地元で生産された生産物であり、商品として提供可能なものであればよい。例えば、水産物や畜産物であってもよい。つまり、上述の実施形態では、野菜を生産することについて、野菜を栽培し、収穫するまでの一連の行為と定義づけているが、水産物を生産すること、及び畜産物を生産することについては、以下のように定義することができる。即ち、水産物を生産することについては、水産物を育て、又は捕獲して、商品としての形態に加工するまでの一連の行為と定義することができる。また、畜産物を生産することについては、畜産物を育て、又は捕獲して、商品としての形態に加工するまでの一連の行為と定義することができる。

また例えば、上述の実施形態では、同じ商品について、複数のレストランＲからの注文があった場合には、注文のタイミングが一番早かったレストランＲがその商品を購入できることとされているが、これは例示にすぎない。注文の内容に含まれる各種要素に基づいて、その商品を購入できるレストランＲを決めてもよい。例えば、生産者Ｐからの出荷確定情報に含まれる価格を「目安となる価格」という取り扱いにして、一番高い金額で注文したレストランＲが購入できるようにしてもよい（即ち、入札方式）。この場合、生産者Ｐは、生産物を高く売ることができる。

また例えば、図６乃至図８に示すＧＵＩは例示にすぎず、他の画面構成としてもよい。

また例えば、図６に示す出荷確定情報の入力項目は例示すぎず、図６に示す入力項目に限定されない。例えば、生産者Ｐは、手間や時間的コストの見地から、袋等で生産物（野菜）を梱包せずに、表面に土がついた状態で出荷する場合がある。この場合、梱包してからの出荷なのか、又は梱包せずに土がついた状態での出荷なのかを入力する項目を、出荷確定情報の入力項目に設けてもよい。

また、上述の実施形態では、生産者Ｐが野菜を出荷する際の具体的態様について特に限定していないが、例えば野菜の梱包に使用する袋にＱＲコード（登録商標）を付してもよい。このＱＲコード（登録商標）には、生産者Ｐに関する情報や、野菜（出荷商品）に関する情報を関連付けることができる。これにより、野菜の購入者であるレストランＲは、レストラン端末３を用いてＱＲコード（登録商標）を読み取ることにより、容易に有益な情報を得ることができる。
具体的には、生産者Ｐに関する情報には、生産者Ｐのプロフィール、生産者Ｐによる野菜の説明、生産者Ｐのこだわり等を含めることができる。また、野菜（出荷商品）に関する情報には、専門家によるワンポイントアドバイスとして、例えばおすすめの調理方法等の情報を含めることができる。
なお、生産者Ｐに関する情報や、野菜（出荷商品）に関する情報は、レストラン端末３を用いてＱＲコード（登録商標）を読み取ることにより直接的に取得できるようにしてもよいし、これらの情報にアクセス可能なＵＲＬを取得できるようにしてもよい。

また例えば、ルート生成部１０９により生成される集荷配送ルートは、予め設定された優先順位に基づいて生成されてもよい。優先順位の設定基準は特に限定されず、生産者Ｐの利益を重視した優先順位、レストランＲの利益を重視した優先順位、配送業者Ｌの利益を重視した優先順位等、任意に設定することができる。
ここで、生産者Ｐが野菜を販売した際の利幅は、野菜の販売先が、（１）レストランＲ、（２）スーパーマーケットや八百屋等の小売業者、（３）サービス提供者Ｍの順で次第に小さくなっていく。即ち、生産者Ｐは、レストランＲに販売すると最も利幅が大きく、スーパーマーケット等の小売業者に販売すると中間マージンが引かれるため、レストランＲに販売するよりも利幅は小さくなる。そして、サービス提供者Ｍに販売するときは、ほとんど売れ残りの状態となるため最も利幅が小さくなる。このため、例えば生産者Ｐの利益を重視した優先順位に基づいた場合には、上記（１）乃至（３）の順番の集荷配送ルートが生成される。
即ち、まず第１優先として、注文が受け付けられたレストランＲをまわり、第２優先として、地元のスーパーマーケットや八百屋等の小売店舗をまわる。具体的には、ルート生成部１０９は、地元のスーパーマーケットや八百屋からの注文があったものと擬制して、地元のスーパーマーケットや八百屋等の小売店舗の夫々が経由地点に含まれるように集荷配送ルートを生成する。

また、上述の実施形態では、生産者Ｐの野菜の販売先は、レストランＲ、スーパーマーケット等の小売店舗、及びサービス提供者Ｍとされており、一般消費者が含まれていない。しかしながら、これは例示にすぎず、生産者Ｐは一般消費者に直接販売してもよい。具体的には例えば、人通りが多い団地内の路地を集荷配送ルートに入れてもよい。これにより、路地を通行する一般消費者に対し、積極的に野菜を売り込むことができる。一般消費者への販売は、レストランＲへの販売よりもさらに利幅が大きくなるため、生産者Ｐが得られる利益の増加を図ることができる。

また、図３に示すハードウェア構成は、本発明の目的を達成するための例示に過ぎず、特に限定されない。

また、図４に示す機能ブロック図は、例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能が情報処理システムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは、特に図４の例に限定されない。

また、機能ブロックの存在場所も、図４に限定されず、任意でよい。
また、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。

各機能ブロックの処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。

このようなプログラムを含む記録媒体は、各ユーザにプログラムを提供するために装置本体とは別に配布される、リムーバブルメディアにより構成されるだけではなく、装置本体に予め組み込まれた状態で各ユーザに提供される記録媒体等で構成される。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に添って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。

また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものである。

以上まとめると、本発明が適用される情報処理装置は、次のような構成を取れば足り、各種各様な実施形態を取ることができる。
即ち、本発明が適用される情報処理装置（例えばサーバ１）は、
１以上の生産者（例えば図１の生産者Ｐ）の夫々により生産され、出荷できることが確定した１以上の生産物（例えば野菜）の夫々の内容を示す情報を、出荷確定情報として受け付ける確定受付手段（例えば図４の確定受付部１０５）と、
受け付けられた１以上の前記出荷確定情報を、前記生産物を使用し得る１以上の使用者（例えば図１のレストランＲ）に提示する確定提示手段（例えば図４の確定提示部１０６）と、
前記１以上の使用者のうち少なくとも一部から、生産物を購入する旨の提示があった場合に、これを注文として受け付ける注文受付手段（例えば図４の注文受付部１０７）と、
前記提示をした前記生産者に対し、前記注文が受け付けられた旨を提示する注文提示手段（例えば図４の注文提示部１０８）と、
受け付けられた前記注文に基づいて、当該注文の対象を少なくとも含む、出荷できることが確定した前記生産物の集荷及び配送のルート（例えば図８の集荷配送ルート）を生成するルート生成手段（例えば図４のルート生成部１０９）と、
を備える
これにより、地元で採れた生産物を使用する使用者と、その使用者に対し地元産の生産物を提供する生産者との関係を円滑化させて、地元の価値を見出すことができる新たな仕組みを提供することができる。

さらに、１以上の生産者（例えば図１の生産者Ｐ）の夫々により生産され、出荷することができると予測される１以上の生産物（例えば野菜）の夫々の内容を示す情報を、出荷予測情報として受け付ける予測受付手段（例えば図４の予測受付部１０１）と、
前記生産物を使用する１以上の使用者（例えば図１のレストランＲ）から、前記生産物の購入の予約をしたい旨の提示があった場合に、これを事前予約として受け付ける予約受付手段（例えば図４の予約受付部１０３）と、
を備えることができる。
これにより、地元で採れた生産物を使用する使用者は、前日等に事前に予約することができるので、使用計画を容易に立てることが可能になる。また、この予約は、売買契約を成立させるものではなく、次の日の朝悪天候により生産物を集荷できないときはキャンセルさせることができるので、生産者にとっても安心して出荷計画を容易に立てることができる。

また、前記出荷確定情報に含まれる前記生産物の数量よりも、前記事前予約の内容に含まれる当該生産物の数量の方が少ない場合に、
前記注文受付手段は、当該生産物の前記配送が開始されるタイミングの所定時間前（例えば集荷配送が開始される３０分前）まで前記注文を受け付けることができる。
これにより、レストランＲにおける急な予約の変更に対応することができる。

また、前記出荷予測情報を前記１以上の使用者に提示する予測提示手段（例えば図４の予測提示部１０２）をさらに備えることができる。
これにより、レストランＲは、料理の内容を考える際に、出荷予測情報を参考にすることができる。

また、前記１以上の生産者に対し、前記事前予約が受け付けられた旨を提示する予約提示手段（例えば図４の予約提示部１０４）をさらに備えることができる。
これにより、生産者Ｐは、事前予約の内容を考慮して出荷内容を確定することができる。

１：サーバ、２、２－１、２－ｎ：生産者端末、３、３－１、３－ｍ：レストラン端末、４：配送端末、１１：ＣＰＵ、１２：ＲＯＭ、１３：ＲＡＭ、１４：バス、１５：入出力インターフェース、１６：出力部、１７：入力部、１８：記憶部、１９：通信部、２０：ドライブ、３０：リムーバブルメディア、１０１：予測受付部、１０２：予測提示部、１０３：予約受付部、１０４：予約提示部、１０５：確定受付部、１０６：確定提示部、１０７：注文受付部、１０８：注文提示部、１０９：ルート生成部、４０１：ユーザＤＢ、４０２：生産物ＤＢ、Ｈ１：入力欄、Ｂ１：ボタン、ＳＳ１乃至ＳＳ１４：本サービスにおける各ステップ、Ｓ１乃至Ｓ４：サーバの処理における各ステップ、Ｐ，Ｐ１，Ｐｎ：生産者、Ｍ：サービス提供者、Ｎ：ネットワーク、Ｒ，Ｒ１，Ｒｎ：レストラン、Ｌ：配送業者

Claims (7)

1. １以上の生産者の夫々により生産され、出荷できることが確定した１以上の生産物の夫々の内容を示す情報を、出荷確定情報として受け付ける確定受付手段と、
   受け付けられた１以上の前記出荷確定情報を、前記生産物を使用し得る１以上の使用者に提示する確定提示手段と、
   前記１以上の使用者のうち少なくとも一部から、生産物を購入する旨の提示があった場合に、これを注文として受け付ける注文受付手段と、
   前記提示をした前記生産者に対し、前記注文が受け付けられた旨を提示する注文提示手段と、
   受け付けられた前記注文、及び前記１以上の使用者に基づいて、当該注文の対象を少なくとも含む、出荷できることが確定した前記生産物の集荷並びに配送及び販売のルートを生成するルート生成手段と、
   を備える情報処理装置。
2. 前記１以上の生産者の夫々により生産され、出荷することができると予測される１以上の前記生産物の夫々の内容を示す情報を、出荷予測情報として受け付ける予測受付手段と、
   前記１以上の使用者から、前記生産物の購入の予約をしたい旨の提示があった場合に、これを事前予約として受け付ける予約受付手段と、
   をさらに備える請求項１に記載の情報処理装置。
3. 前記出荷確定情報に含まれる前記生産物の数量よりも、前記事前予約の内容に含まれる当該生産物の数量の方が少ない場合に、
   前記注文受付手段は、当該生産物の前記配送が開始されるタイミングの所定時間前まで前記注文を受け付ける、
   請求項２に記載の情報処理装置。
4. 前記出荷予測情報を前記１以上の使用者に提示する予測提示手段をさらに備える、
   請求項２又は３に記載の情報処理装置。
5. 前記１以上の生産者に対し、前記事前予約が受け付けられた旨を提示する予約提示手段をさらに備える、
   請求項２乃至４のうちいずれか１項に記載の情報処理装置。
6. 情報処理装置が実行する情報処理方法において、
   １以上の生産者の夫々により生産され、出荷できることが確定した１以上の生産物の夫々の内容を示す情報を、出荷確定情報として受け付ける確定受付ステップと、
   受け付けられた１以上の前記出荷確定情報を、前記生産物を使用し得る１以上の使用者に提示する確定提示ステップと、
   前記１以上の使用者のうち少なくとも一部から、生産物を購入する旨の提示があった場合に、これを注文として受け付ける注文受付ステップと、
   前記提示をした前記生産者に対し、前記注文が受け付けられた旨を提示する注文提示ステップと、
   受け付けられた前記注文、及び前記１以上の使用者に基づいて、当該注文の対象を少なくとも含む、出荷できることが確定した前記生産物の集荷並びに配送及び販売のルートを生成するルート生成ステップと、
   を含む情報処理方法。
7. コンピュータに、
   １以上の生産者の夫々により生産され、出荷できることが確定した１以上の生産物の夫々の内容を示す情報を、出荷確定情報として受け付ける確定受付ステップと、
   受け付けられた１以上の前記出荷確定情報を、前記生産物を使用し得る１以上の使用者に提示する確定提示ステップと、
   前記１以上の使用者のうち少なくとも一部から、生産物を購入する旨の提示があった場合に、これを注文として受け付ける注文受付ステップと、
   前記提示をした前記生産者に対し、前記注文が受け付けられた旨を提示する注文提示ステップと、
   受け付けられた前記注文、及び前記１以上の使用者に基づいて、当該注文の対象を少なくとも含む、出荷できることが確定した前記生産物の集荷並びに配送及び販売のルートを生成するルート生成ステップと、
   を含む制御処理を実行させるプログラム。

Images