(57)【要約】【課題】第一次産業の従事者らにおける収入の安定化および早期化を図り、ひいては六次産業化の促進を支援する。【解決手段】収益配分システム１００を構成する情報処理装置において、第一次産業の従事者を起点にした当該従事者による産物の商流で生じる取引の情報を管理する記憶装置２０５と、前記取引の情報に基づいて、前記商流における所定取引に伴う納入物の所有権に対する、所定仲介業者を買い主とした所定の買取処理を実行し、前記仲介業者が当該取引の債権者に関して保持する債権と前記買取処理で得た所有権との間の価値の差分を算定し、当該取引の債権者に対する、前記差分に応じた金額の所定の支払処理を実行する演算装置２０２を含む構成とする。【選択図】図２
2019049930.tif 000002
【特許請求の範囲】
【請求項１】
第一次産業の従事者を起点にした当該従事者による産物の商流で生じる取引の情報を管理する記憶装置と、
前記取引の情報に基づいて、前記商流における所定取引に伴う納入物の所有権に対する、所定仲介業者を買い主とした所定の買取処理を実行し、前記仲介業者が当該取引の債権者に関して保持する債権と前記買取処理で得た所有権との間の価値の差分を算定し、当該取引の債権者に対する、前記差分に応じた金額の所定の支払処理を実行する演算装置と、
を含むことを特徴とする収益配分システム。
【請求項２】
前記演算装置は、
前記取引の情報に基づいて、前記商流の末端での取引にて当該取引の債権者が得た収益額を特定し、前記仲介業者が前記商流の各取引の債権者に関して保持する債権と前記買取処理で当該債権者から得た所有権との間の価値の差分に、前記収益額を加算し、前記各取引の債権者に対する、前記差分に前記収益額を加算して得た金額の所定の支払処理を実行するものである、
ことを特徴とする請求項１に記載の収益配分システム。
【請求項３】
前記演算装置は、
前記商流の末端での取引前に、前記収益額を所定の収益予測アルゴリズムに基づいて算出し、当該算出した収益額を前記差分に加算するものである、
ことを特徴とする請求項２に記載の収益配分システム。
【請求項４】
前記商流の参加者それぞれの端末において、前記商流の各取引に関する情報を当該端末の記憶装置で保持する分散台帳で管理してなることを特徴とする請求項１に記載の収益配分システム。
【請求項５】
第一次産業の従事者を起点にした当該従事者による産物の商流で生じる取引の情報を管理する記憶装置を備えた情報処理装置が、
前記取引の情報に基づいて、前記商流における所定取引に伴う納入物の所有権に対する、所定仲介業者を買い主とした所定の買取処理を実行し、前記仲介業者が当該取引の債権者に関して保持する債権と前記買取処理で得た所有権との間の価値の差分を算定し、当該取引の債権者に対する、前記差分に応じた金額の所定の支払処理を実行する、
ことを特徴とする収益配分方法。
【請求項６】
第一次産業の従事者を起点にした当該従事者による産物の商流で生じる取引の情報を管理する記憶装置を備えた情報処理装置に、
前記取引の情報に基づいて、前記商流における所定取引に伴う納入物の所有権に対する、所定仲介業者を買い主とした所定の買取処理を実行し、前記仲介業者が当該取引の債権者に関して保持する債権と前記買取処理で得た所有権との間の価値の差分を算定し、当該取引の債権者に対する、前記差分に応じた金額の所定の支払処理を実行させる、
ことを特徴とする収益配分プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、収益配分システム、収益配分方法、および、収益配分プログラムに関するものであり、具体的には、第一次産業の従事者らにおける収入の安定化および早期化を図り、ひいては六次産業化の促進を支援する技術に関する。
【背景技術】
【０００２】
農業を始めとする第一次産業の従事者における収入は、主として、作物・収穫物を市場や卸業者に卸すことで得られる。ところが、冷害等の天候不順や台風などの脅威によって不作、不漁となるか、逆に、気象条件等に恵まれて豊作、豊漁になり過ぎる、といった具合に生産量が変動しやすいことで、収入の安定化を図ることが難しい。
【０００３】
そこで、そうした第一次産業の生産物を、食品加工業や流通販売業にも展開することで、６次産業化を推進する流れがある。この六次産業化は、生産物を調理・加工・パッケージングした上で販売することで、市場等への卸価格に左右されることなく安定した収入の獲得を意図したものとなる。
【０００４】
一方、第一次産業の従事者らは、食品加工や流通販売に関するノウハウに乏しいケースが一般的である。従って実際には、六次産業化に際して既存の加工業者及び流通業者への販売を通じた業務委託を行うなどして、必要な商流構築に努めることが多い。この場合、第一次産業の従事者らの収入は、商流末端の流通販売業者によって販売された商品の代価として確定し、これを獲得することとなる。
【０００５】
ところで、商流の関係者間で収益を分配するための従来技術として、以下のような技術が提案されている。すなわち、商品販売のためにプロモーションを実行して収益の分配を受ける事業体について収益分配率を記憶するステップと、顧客番号と、予約者の指示に基づいて特定された予約商品の数量、上記事業体の識別子および商品の識別子とを含む予約レコードを生成するステップと、売上商品の数量、上記事業体の識別子および上記商品の識別子を含む決済済みレコードを、上記予約レコードから生成するステップと、上記収益分配率と、商品価格情報と、上記決済済みレコードに含まれる売上商品の数量、上記事業体の識別子および上記商品の識別子とに基づいて上記事業体の収益分配を算出するステップとを有することを特徴とする販売管理方法（特許文献１参照）などが提案されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特許第３２３９１１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述のように、六次産業化を図ったとしても、第一次産業の従事者らが収入を得られるタイミングは、実際に該当商品の販売が顧客になされて以降であり、次期の生産に必要な資材や設備の導入資金の確保が適切な時期までに間に合わない恐れがある。また、六次産業化の商流における加工業者や流通販売業者の階層や数が増えるにつれ、上述の従事者と様々な事業者との間での決済頻度も増大し、結果として金融機関に支払うべき決済手数料の増加につながりやすい。
【０００８】
そこで本発明の目的は、第一次産業の従事者らにおける収入の安定化および早期化を図り、ひいては六次産業化の促進を支援する技術を提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決する本発明の収益配分システムは、第一次産業の従事者を起点にした当該従事者による産物の商流で生じる取引の情報を管理する記憶装置と、前記取引の情報に基づいて、前記商流における所定取引に伴う納入物の所有権に対する、所定仲介業者を買い主とした所定の買取処理を実行し、前記仲介業者が当該取引の債権者に関して保持する債権と前記買取処理で得た所有権との間の価値の差分を算定し、当該取引の債権者に対する、前記差分に応じた金額の所定の支払処理を実行する演算装置と、を含むことを特徴とする。
【００１０】
また、本発明の収益配分方法は、第一次産業の従事者を起点にした当該従事者による産物の商流で生じる取引の情報を管理する記憶装置を備えた情報処理装置が、前記取引の情報に基づいて、前記商流における所定取引に伴う納入物の所有権に対する、所定仲介業者を買い主とした所定の買取処理を実行し、前記仲介業者が当該取引の債権者に関して保持する債権と前記買取処理で得た所有権との間の価値の差分を算定し、当該取引の債権者に対する、前記差分に応じた金額の所定の支払処理を実行する、ことを特徴とする。
【００１１】
また、本発明の収益配分プログラムは、第一次産業の従事者を起点にした当該従事者による産物の商流で生じる取引の情報を管理する記憶装置を備えた情報処理装置に、前記取引の情報に基づいて、前記商流における所定取引に伴う納入物の所有権に対する、所定仲介業者を買い主とした所定の買取処理を実行し、前記仲介業者が当該取引の債権者に関して保持する債権と前記買取処理で得た所有権との間の価値の差分を算定し、当該取引の債権者に対する、前記差分に応じた金額の所定の支払処理を実行させる、ことを特徴とする。
【発明の効果】
【００１２】
本発明によれば、第一次産業の従事者らにおける収入の安定化および早期化を図り、ひいては六次産業化の促進が支援可能となる。
【図面の簡単な説明】
【００１３】
【図１】実施例１における収益配分システムの構成例を示す図である。
【図２】実施例１の収益配分システムを構成する端末のハードウェア構成例を示す図である。
【図３】実施例１における注文情報データベースの構成例を示す図である。
【図４】実施例１における出荷記録データベースの構成例を示す図である。
【図５】実施例１における所有権データベースの構成例を示す図である。
【図６】実施例１における債権データベースの構成例を示す図である。
【図７】実施例１における契約データベースの構成例を示す図である。
【図８】実施例１における収益配分方法のフロー例１を示す図である。
【図９】実施例１における収益配分方法のフロー例２を示す図である。
【図１０】実施例１における収益配分方法フロー例３を示す図である。
【図１１】実施例１における収益配分方法のフロー例４を示す図である。
【図１２】実施例１における商流および収益配分の概念例を示す図である。
【図１３】実施例２における収益配分システムの構成例を示す図である。
【図１４】実施例２の収益配分システムを構成する端末のハードウェア構成例を示す図である。
【発明を実施するための形態】
【００１４】
＜実施例１＞
−−−システム構成例−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態における収益配分システム１００の構成例を示す図である。図１に示す収益配分システム１００は、第一次産業の従事者らにおける収入の安定化および早期化を図り、ひいては六次産業化の促進を支援するコンピュータシステムである。
【００１５】
ここで、第一次産業の従事者の一例として農家を想定する。よって、本実施形態における商流で流通する産物は農作物とこれを加工した加工品となる。農家が生産した農作物は、当該農家の六次産業化の意図に伴い、加工業者に販売され、そこで加工される。また、この加工によって生まれた商品すなわち加工品は、小売業者の店舗やインターネット上など所定の販売チャネルを介して消費者に販売される。
【００１６】
つまり、ここでイメージする商流は、農家での農作物の生産、当該農家と契約した加工業者での農作物加工に伴う加工品製造、当該加工業者と契約した小売業者での加工品販売、といった一連のサプライチェーンが該当する。
【００１７】
上述の前提の下、農家が操作する農家端末１０１、加工業者が操作する加工業者端末１０２、小売業者が操作する小売業者端末１０３、消費者が操作する消費者端末１０４、仲介業者が操作する仲介業者端末１０５、上述のサプライチェーンを管理する注文システム１０６、債権管理システム１０７、および、支払いシステム１０８が、ネットワーク１０で接続されている。なお、このネットワーク１０は、通信の内容、性質、組織等により適宜に選択されたものであるとする。例えば、商流の各参加者のうち同じ組織に所属する者の端末間のネットワーク１０は、組織内のＬＡＮなど内部ネットワークであり、異なる組織に所属する者の端末間のネットワーク１０は、インターネットとなる。
【００１８】
このうち、注文システム１０６、債権管理システム１０７、および、支払いシステム１０８で、本実施形態の収益配分システム１００を構成する形態が想定できる。但し、注文システム１０６、債権管理システム１０７、および、支払いシステム１０８の各機能を、いずれかのシステムが備え、単体で収益配分システム１００を構成するとしてもよい。或いは、当該ネットワーク１０に接続された各端末のうちいずれかが又は協働して、上述の注文システム１０６、債権管理システム１０７、および、支払いシステム１０８と同様に収益配分システム１００を構成するとしてもよい。
【００１９】
上述の構成のうち農家端末１０１は、当該農家が仲介業者や加工業者など、サプライチェーンにおける他者との取引に関して情報を授受する際に使用する端末である。農家は、こうした農家端末１０１を使用して、生産した農作物の直接販売先である加工業者からの注文を受注する手続、農作物生産に必要な農作機械等の設備リース契約を仲介業者との間で締結する手続、および、仲介業者や加工業者との間で発生した決済手続き、など各種手続をに関する情報の入出力を行うこととなる。
【００２０】
なお、本実施形態における仲介業者は、農作機械等の設備リース業を営む事業者であると想定するが、勿論、仲介業者がこうした事業者である形態は限定しない。よって、仲介業者は、当該商流における第一次産業の従事者以外のいずれの参加者であってもよいし、或いは、農作物や加工品の流通に直接関与しない金融機関など仲介業務のみを行う者であってもよい。
【００２１】
また、加工業者端末１０２は、当該加工業者が上述の農家や小売業者などサプライチェーンにおける他者との取引に関して情報を授受する際に使用する端末である。加工業者は、こうした加工業者端末１０２を使用して、農家に対する農作物の発注や入荷手続き、小売業者との間での加工品の受注手続き、仲介業者との間における生産機械等の設備リース手続き、および、仲介業者や小売業者との間で発生した決済手続き、など各種手続をに関
する情報の入出力を行うこととなる。
【００２２】
また、小売業者端末１０３は、当該小売業者が加工業者や消費者などサプライチェーンにおける他者との取引に関して情報を授受する際に使用する端末である。小売業者は、こうした小売業者端末１０３を使用して、加工業者に対する加工品（或いは農家に対する農作物）の発注や入荷手続き、小売販売に必要なＰＯＳ（Ｐｏｉｎｔ Ｏｆ Ｓａｌｅｓ）端末等の設備リース手続き、および、仲介業者や加工業者との間で発生した決済手続き、など各種手続をに関する情報の入出力を行うこととなる。
【００２３】
また、消費者端末１０４は、当該消費者が小売業者との取引すなわち商品購入に関して情報を授受する際に使用する端末である。消費者は、上述の農家の農作物や加工業者が生産した加工品を、上述の小売業者の実店舗やインターネット上の電子商店（オークションサイトの概念含む）を通じて購入し消費する人々である。
【００２４】
また、仲介業者端末１０５は、当該仲介業者が上述の商流の各参加者との取引に関して情報を授受する際に使用する端末である。既に述べたように、仲介業者は、農作機械、生産機械等の設備リース業を行う事業者である。よって仲介業者は、仲介業者端末１０５を使用して、農家や加工業者、小売業者などの間での農作機械や生産機械等の設備リース契約の受注手続、農家や加工業者との間での農作物やその加工品の買い取り手続とそれに伴う収益配分の手続、および、債権情報の管理、移動などを行う。
【００２５】
また、収益配分システム１００を構成する注文システム１０６は、上述の商流の参加者、すなわち農家、加工業者、小売業者、および、消費者らが、商品である農作物や加工品あるいは農作機械や生産機械等の設備リースの注文を行うにあたって利用するシステムである。この注文システム１０６としては、具体的には、上述のネットワーク１０において注文の受付とそれに伴う取引処理のＷＥＢサービスを提供するサーバ装置を想定する。こうした注文システムの基本的な構成自体は、既存のものを適宜に採用すればよい。
【００２６】
また、収益配分システム１００における債権管理システム１０７は、上述の注文システム１０６で処理した取引に伴って生じる債権の情報登録、移動、修正など債権管理の処理を実行するシステムである。
【００２７】
また、収益配分システム１００における支払いシステム１０８は、上述の注文システム１０６および債権管理システム１０７での各処理に伴い、当該取引に関する支払い手続きに応じた所定の処理を実行するシステムである。
【００２８】
なお、上述の注文システム１０６、債権管理システム１０７、および、支払いシステム１０８は、それぞれハードウェアとして構成して提供される形態に限定せず、例えば、ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）などネットワーク経由で遠隔提供
される形態を想定してもよい。
【００２９】
−−−ハードウェア構成−−−
続いて、収益配分システム１００のハードウェア構成を説明する。ここでは、収益配分システム１００を、単体の情報処理装置として構成したケースに関して説明する。すなわち、注文システム１０６、債権管理システム１０７、および、支払いシステム１０８らの機能、構成を、備えた情報処理装置のハードウェア構成である。
【００３０】
本実施形態の収益配分システム１００は、バス２０１を介して接続した、ＣＰＵ２０２、ネットワークインターフェイス２０３、入力装置２０４、記憶装置２０５、および、出力装置２０６から構成される。
【００３１】
このうちＣＰＵ２０２は、記憶装置２０５で保持するプログラム２１５を実行することで、収益配分システムとして必要な機能を実装し、システム自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なう演算装置である。
【００３２】
また、 ネットワークインターフェイス２０３は、インターネットやイントラネットな
どのネットワーク１０を介して、上述の農家端末１０１、加工業者端末１０２、小売業者端末１０３、消費者端末１０４、および、仲介業者端末１０５、らとデータ送受信を行う装置である。ネットワークインターフェイス２０３の送受信する内容はＣＰＵ２０２により制御される。こうしたネットワークインターフェイス２０３は、例えばＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）や無線ＬＡＮインターフェイスカードなどで構成される。
【００３３】
また、入力装置２０４は、必須の構成要素ではないが、例えば、当該収益配分システム１００の管理者等による指示を受け付ける、キーボードやマウス、タッチパネルなどの装置である。
【００３４】
また、 記憶装置２０５は、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）やハード
ディスクドライブなど適宜な不揮発性記憶素子で構成され、ＣＰＵ２０２で実行するプログラム２１５および各種データベース等のデータを格納している。
【００３５】
また、出力装置２０６は、ＣＰＵ２０２の指示に基づいて所定の情報を画面表示するディスプレイ等の装置である。
【００３６】
なお、記憶装置２０５内には、本実施形態の収益配分システム１００として必要な機能を実装する為のプログラム２１５に加えて、注文情報データベース２１０、出荷記録データベース２１１、所有権データベース２１２、債権データベース２１３、および、契約データベース２１４、が少なくとも記憶されている。
【００３７】
−−−データ構造例−−−
続いて、本実施形態の収益配分システム１００が用いるデータ類について説明する。図３に、本実施形態における注文情報データベース２１０の一例を示す。注文情報データベース２１０は、上述の商流の各参加者が各端末を操作して注文システム１０６に対して発した注文の情報を蓄積したデータベースである。
【００３８】
そのデータ構造は、例えば、注文番号３０１、発注先３０２、発注元３０３、発注日３０４、納期３０５、商品名３０６、および、数量３０７、の各値を対応付けたレコードの集合体となっている。
【００３９】
このうち 注文番号３０１は、注文情報データベース２１０に格納した注文レコードを
一意に特定する識別情報である。
【００４０】
また、発注先３０２は、当該注文における発注先業者の名称を示す。また発注元３０３は、当該注文における発注元業者の名称を示す。こうした発注先業者及び発注元業者の各名称は、業者を区別できる番号コードであっても良い。
【００４１】
また、発注日３０４は、上述の発注元業者と発注先業者とが当該注文の内容に合意した日付を示す。
【００４２】
また、納期３０５は、上述の注文の合意内容に含まれる納入予定日を示す。
【００４３】
また、商品名３０６は、当該発注元業者が注文した商品を示す名称である。なお、商品とは、上述したように農作物や加工品が該当する（以下同様）。
【００４４】
また、数量３０７は、当該発注元業者が当該注文にて発注した商品の数量を示す。
【００４５】
なお図３に示した注文情報データベース２１０の構成はあくまで一例であり、必要に応じて項目の順番や有無、項目名は適宜に採用すればよい。
【００４６】
また、図４に本実施形態における出荷記録データベース２１１の一例を示す。この出荷記録データベース２１１は、上述の注文システム１０６で処理した注文に基づき、当該注文の対象商品が出荷された事象に関して、その情報を管理するデータベースである。
【００４７】
こうした出荷記録データベース２１１は、出荷番号４０１、注文番号４０２、出荷元４０３、出荷先４０４、出荷日４０５、納入日４０６、商品番号４０７、の各値を対応付けたレコードの集合体となっている。
【００４８】
このうち出荷番号４０１は、出荷記録データベース２１１で保持する出荷レコードを一意に特定する識別情報である。
【００４９】
また、注文番号４０２は、当該出荷に紐づく注文を示す番号で、図３の注文情報データベース２１０の注文番号３０１と共通する。なお、１つの注文が複数の出荷に分かれた場合、その注文情報は複数の出荷履歴に含まれることとなる。
【００５０】
また、出荷元４０３は、当該商品の出荷を行った業者の名称を示す。また、出荷先４０４は、当該商品の出荷先の業者の名称を示す。こうした出荷元４０３および出荷先４０４の各名称は、当該業者を区別できる番号コードであっても良い。
【００５１】
また、出荷日４０５は、当該出荷における出荷元業者が出荷した日付を示す。また、納入日４０６は、当該出荷における出荷元業者が出荷した商品が出荷先４０４の業者に到着した日付を示す。
【００５２】
また、商品番号４０７は、上述の出荷先４０４の業者に到着した商品を一意に特定する識別情報である。この商品番号は、同じ商品であっても、出荷物を出荷ごとに区別するためのものである。よって、この商品番号４０７の値は、商品個々の単位で付与される必要はなく、発注単位や納品単位（ロット）毎に付与されたものを想定できる。
【００５３】
続いて、図５に本実施形態の所有権データベース２１２の一例を示す。この所有権データベース２１２は、上述の商流の参加者間で実際に取引される商品の所有者を示す所有権情報のＤＢである。
【００５４】
こうした所有権データベース２１２は、所有権ＩＤ５０１、出荷番号５０２、所有者５０３、評価資産物５０４、および、評価資産額５０５、の各値を対応付けたレコードの集合体となっている。
【００５５】
このうち所有権ＩＤ５０１は、所有権データベース２１２に含まれる所有権情報を一意に特定する識別情報である。
【００５６】
また、出荷番号５０２は、所有権データベース２１２と出荷記録データベース２１１を紐づける情報であり、図４の出荷番号４０１と共通する。
【００５７】
また、所有者５０３は、当該商品の所有者の名称を示す。
【００５８】
また、評価資産物５０４は、所有権対象の物品名称すなわち商品の名称を示す。
【００５９】
また、評価資産額５０５は、上述の評価資産物５０４が示す商品の評価額を示す。
【００６０】
続いて、図６に本実施形態の債権データベース２１３の一例を示す。この債権データベース２１３は、上述の商流における取引にて参加者間で商品の所有権が移動することに伴う、各債権の情報を格納したＤＢである。この債権データベース２１３は、債券ＩＤ６０１、注文番号６０２、債権者６０３、債務者６０４、および、債務額６０５、の各値を対応付けたレコードの集合体となっている。
【００６１】
このうち債権ＩＤ６０１は、当該債権データベース２１３のレコードを一意に特定する識別情報である。
【００６２】
また、注文番号６０２は、当該債権データベースと出荷記録データベース２１１を紐づける情報であり、図３の注文情報３０１と共通する。
【００６３】
また、債権者６０３は、当該債権者であり業者の名称を示す情報である。
【００６４】
また、債務者６０４は、当該債務者となる業者の名称を示す情報である。
【００６５】
また、債務額６０５は、当該債務の金額を示す情報である。
【００６６】
続いて、図７に本実施形態の契約データベース２１４の一例を示す。この契約データベース２１４は、本実施形態の収益配分方法における収益配分のプロトコルを、取引イベントごとに格納したＤＢである。こうした契約データベース２１４は、契約ＩＤ７０１、イベント７０２、および、実行内容７０３、の各値を対応付けたレコードの集合体となっている。
【００６７】
このうち契約ＩＤ７０１は、契約データベース２１４における各契約レコードを一意に特定する識別情報である。
【００６８】
また、イベント７０２は、当該契約内容の実行条件である取引イベントを示す情報である。例えば、「農家Ａから工場Ｂに対し、指定納期以内で農作物が納品される」といった取引イベントの情報を想定する。こうした取引イベントは、収益配分システム１００が検知するものである。
【００６９】
また、実行内容７０３は、収益配分システム１００によってイベント７０２に合致する取引イベントが検出された場合に実行される、支払い手続きや債権情報の移動方法を示す情報である。例えば、「農家Ａから工場Ｂに対し、指定納期以内で農作物が納品される」といった取引イベントが検出された場合、「農家Ａ」、「工場Ｂ」そして関係する仲介者等の業者間で実施される支払い内容や、債権の移動方法の情報が該当する。
【００７０】
なお、図７の契約データベース２１４に含まれるイベント７０２および実行内容７０３は、例示するように自然文章で記述された情報だけでなく、収益配分システム１００で実行されるプログラム言語で記述されたものであっても良い。
【００７１】
また、図７の契約データベース２１４の構成は必ずしもこの限りではない。例えばイベ
ント対象の業者を別の列にしておき、イベントはテンプレートとして用意して、対象を変えてコピーできるようにしても良い。
【００７２】
−−−フロー例１（注文処理）−−−
以下、本実施形態における収益配分方法の実際手順について図に基づき説明する。以下で説明する収益配分方法に対応する各種動作は、収益配分システム１００を構成する装置らがそれぞれメモリ等に読み出して実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
【００７３】
図８は、本実施形態における収益配分方法のフロー例１を示す図である。ここでは収益配分システム１００における注文システム１０６での処理について説明する。
【００７４】
この場合、注文システム１０６は、例えば、上述の商流における発注者による受注者に対する注文手続の要求を、注文受付用の所定のＷｅｂサイトを通じて、当該発注者の端末から受け付ける（ステップ８０１）。
【００７５】
特に例示はしないが、上述のＷｅｂサイトは、発注先、発注元、納期、注文対象商品の商品名、および、その数量、といった注文内容の指定を受け付けるインターフェイスを備えた画面を、加工業者端末１０２や小売業者端末１０３といった発注者の端末に配信し、当該画面を通じて注文内容を受け付けて、その値を取得することとする。
【００７６】
例えば、注文システム１０６は、野菜を原料にドレッシングを製造する或る加工業者の加工業者端末１０２から、或る農家に対する所定数量のにんじんの注文手続の要求を受け付ける。或いは、注文システム１０６は、或る小売業者の小売業者端末１０３から、上述の加工業者に対する、ドレッシングを１００ケース発注する注文手続の要求受け付ける。
【００７７】
続いて注文システム１０６は、上述の農家や加工業者など受注者の端末、すなわち農家端末１０１や加工業者端末１０２に対し、上述の発注者からの注文内容を含む所定画面を配信し、当該農家や当該加工業者など受注者による注文内容の確認結果を当該画面を介して取得する（ステップ８０２）。
【００７８】
この場合の受注者は、発注者による注文内容を当該発注者の端末で閲覧し、問題がないか確認する。この確認の結果、注文内容に問題が無かった場合、受注者は、当該端末を操作し、当該画面上の所定インターフェイス（例：合意ボタン）を選択する。一方、その受注者の端末は、当該選択を受けて、当該注文に対して受注する、すなわち合意の意図を、少なくとも注文システム１０６に通知する。
【００７９】
他方、上述の確認の結果、注文内容に問題があった場合、当該受注者は、当該画面にて受注できない旨の選択を所定のインターフェイス（例：不合意ボタン）にて行う。その場合、当該受注者の端末は、当該選択を受けて、当該注文に対して受注を許容しない、すなわち不合意の意図を、少なくとも注文システム１０６に通知する。
【００８０】
続いて注文システム１０６は、上述の発注者と受注者との間で、当該注文内容に関して合意が得られたか、上述のステップ８０２で得た、注文内容の確認結果に応じて判定する（ステップ８０３）。すなわち、受注者の端末から、注文内容に問題が無いため受注する、すなわち合意の意図に関する通知を受けた場合、合意が得られたと判定する。
【００８１】
上述の判定の結果、合意が得られなかった場合（ステップ８０３：Ｎｏ）、注文システム１０６は、注文不成立として処理を終了する。
【００８２】
他方、上述の判定の結果、合意が得られた場合（ステップ８０３：Ｙｅｓ）、注文システム１０６は、注文情報データベース２１０において、当該注文内容を含むレコードを格納し（ステップ８０４）、処理を終了する。
【００８３】
例えば、発注者である「工場Ｂ」の加工業者端末１０２が、受注者である「農家Ａ」に対する「１０００束」の「人参Ａ」の注文内容を含む注文手続の要求を、上述のＷｅｂサイトを介して注文システム１０６に行ったとする。また、発注者である「小売Ｃ」の小売業者端末１０３が、受注者である「工場Ｂ」に対する人参Ａの加工品たる「１００ケース」の「Ｂドレッシング」の注文内容を含む注文手続の要求を、上述のＷｅｂサイトを介して注文システム１０６に行ったとする。
【００８４】
一方、上述の「小売Ｃ」および「工場Ｂ」、「工場Ｂ」および「農家Ａ」、の各間で、該当注文に関して合意が得られた場合、すなわち、受注者の各端末から合意の通知を受けた場合、注文システム１０６は、図３の注文情報データベース２１０で示すように、注文番号「００００１１ａｂ２」および「００００１２ｂｃ７」の各レコードを生成し、これを格納することとなる。
【００８５】
なお、上述のステップ８０２および８０３の合意形成に伴う各処理は、例えば注文対象商品である農作物の発注先たる農家での在庫量と販売価格が、注文内容における該当項目の値から一定範囲内であれば、注文システム１０６が自律的に合意形成を行うとしても良い。その場合、そうした合意形成の条件が契約データベース２１４に記述されていて、注文システム１０６が適宜に利用できるものとすれば好適である。
【００８６】
−−−フロー例２（支払い処理）−−−
次に、本実施形態における支払いシステム１０８における処理について説明する。図９に、支払いシステム１０８における処理フローの一例を示す。
【００８７】
ここでは、上述の注文システム１０６で処理を行って注文情報データベース２１０に注文内容が登録された注文に関して、当該注文の受注者が発注者に対して対象商品の納入を行うことを本フローのトリガーとする。
【００８８】
そのため、上述の受注者の端末は、上述の注文内容に基づいて当該受注者により実行された納入作業について、所定の納品管理システム（例：受注者が運用）からの通知や、或いは所定の納入担当者からの入力を受け、これに基づく当該納入作業の内容について注文システム１０６に通知するものとする。
【００８９】
同様に、上述の発注者の端末は、上述の受注者による納入作業によって発注者が発注対象の商品を受領し、その検収もできた場合に、所定の検収管理システム（例：発注者が運用）からの通知や、或いは所定の検収担当者からの入力を受け、対象商品の受領・検収を行った内容について注文システム１０６に通知するものとする。
【００９０】
よって、この場合の支払いシステム１０８は、上述の受注者の端末からの納入作業に関する情報の通知、および、上述の発注者の端末からの対象商品の受領・検収に関する情報（例：対応する注文の注文番号、受注者、発注者、出荷日、および、対象商品の商品番号、の各値を含む）の通知、を受けて、当該注文に関する納入イベントの発生を検知する（ステップ９０１）。
【００９１】
また、支払いシステム１０８は、上述のステップ９０１で検知した納入イベントに関して、発注者の端末から受けた受領・検収に関する情報を参照し、対象商品である納品物や納期など、受注者との間で合意されている注文内容に関して問題がなかったか判定する（
ステップ９０２）。なお、発注者の端末は、上述の受領・検収に関する情報において、検収担当者による納入物のチェック結果や納期遅延の有無の情報を含め、支払いシステム１０８に通知しているものとする。
【００９２】
上述の判定の結果、当該受注者による納入に関して問題があったことが判明した場合（ステップ９０２：Ｎｏ）、支払いシステム１０８は、上述の受注者と発注者との間での所定の個別協議を促すメッセージ等を、当該受注者および当該発注者の各端末に向けて通知し（ステップ９０６）、処理を終了する。
【００９３】
他方、上述の判定の結果、受注者による納入に関して問題がないことが判明した場合（ステップ９０２：Ｙｅｓ）、支払いシステム１０８は、上述の発注者の端末から通知を受けた対象商品の受領・検収に関する情報に基づいて所定のレコードを生成し、これを出荷記録データベース２１１に書き込む（ステップ９０３）。
【００９４】
こうしたレコードの書き込みに際し、支払いシステム１０８は、納入イベントが発生した注文に関する注文番号（受領・検収に関する情報から抽出）を当該レコードの注文番号４０２として設定するものとする。なお、一つの注文番号すなわち一つの注文に関して、複数の納入イベントが発生した場合、支払いシステム１０８は、図４の出荷記録データベース２１１における出荷番号「００００２２３２５」、「００００２２３２６」のレコードのように、複数の出荷番号の列に１つの注文番号「００００１１ａｂ２」が紐付くこととなる。
【００９５】
続いて、支払いシステム１０８は、今回の納入イベントに伴って生じる債権の情報を、債権データベース２１３に格納する（ステップ９０４）。この場合、支払いシステム１０８は、今回発生した納品イベントに関するレコードを出荷記録データベース２１１で参照し、当該レコードにおける注文番号４０２の値を、注文番号６０２の値として設定する。また、支払いシステム１０８は、当該レコードにおける出荷元４０３の値を債権者６０３の値として設定する。また、支払いシステム１０８は、当該レコードにおける出荷４０４の値を、債務者６０４の値として設定する。これにより債務者６０４に設定された業者すなわち発注者は、債権者６０３たる受注者に対して、支払い義務が発生する。このとき、支払いシステム１０８は、当該レコードの注文番号４０２の値をキーに、注文情報データベース２１０で該当注文のレコードを特定し、数量３０７の値を抽出する。また、支払いシステム１０８は、この数量３０７の値に、対象商品の単価（受注者から予め情報を取得している）を乗じて支払額を算出し、これを支払額６０５の値として設定する。
【００９６】
なお、上述した債権データベース２１３へのレコードの追加は、必ずしも今回のような業者同士の納品イベントのみで発生するとは限らない。例えば、債権ＩＤ「００５」のような、仲介者として「リースＧ」という業者が「農家Ａ」に農作機械をリースすることにより、「リースＧ」に対する債務義務が発生しても良い。
【００９７】
次に、支払いシステム１０８は、今回発生した納入イベントに関する取引額を算出し、これに基づく支払い処理を実行し（ステップ９０５）、処理を終了する。このステップ９０５における処理の詳細については図１０のフローに基づき後述する。
【００９８】
−−−フロー例３（取引額算出処理）−−−
続いて、上述のフロー例２にて支払いシステム１０８が実行するステップ９０５の処理内容について説明する。図１０は本実施形態における収益配分方法のフロー例３を示す図であり、具体的には、取引額算出処理のフロー例である。
【００９９】
ここで、支払いシステム１０８は、ステップ９０５の取引額算出処理に際し、今回の納
品イベントに合致する契約データを契約データベース２１４にて特定し、取得する（ステップ１００１）。
【０１００】
この場合の支払いシステム１０８は、今回の納品イベントに対応する当該注文の注文番号をキーに、例えば注文情報データベースにてレコードを検索して、当該レコードから、発注先３０２、発注元３０３、納期３０５、商品名３０６、および、数量３０７の各値を取得し、また、当該注文番号のレコードを出荷記録データベース２１１にて特定し、該当レコードから納入日４０６の値を取得する。
【０１０１】
また、支払いシステム１０８は、こうして取得した発注先３０２、発注元３０３、納期３０５、商品名３０６、数量３０７、および、納入日４０６、の各値の組み合わせ（例：発注先“農家Ａ”、発注元“工場Ｂ”、納期“２０１７／０３／１２”、商品名“人参Ａ”、数量“１０００束”、および、納入日“２０１７／０３／１２”）をキーに、契約データベース２１４で検索を実行し、イベント７０２の値が当該キーと合致する契約データを特定し、当該契約データの実行内容７０３の値を取得する。
【０１０２】
一方、契約データベース２１４のレコードすなわち契約データのうち、或る契約データでは、イベント７０２の値として「“農家Ａ”から“工場Ｂ”に、農作物が指定した納期以内で納入される」と設定されたいた場合、支払いシステム１０８は、この契約データが、上述のキーにおける、“農家Ａ”から“工場Ｂ”に、農作物たる“人参Ａ”が指定した納期の“２０１７／０３／１２”以内に納入、との納入イベントの内容と合致すると判断し、この契約データを取得することとなる。
【０１０３】
続いて、支払いシステム１０８は、上述のフロー例２におけるステップ９０３で出荷記録データベース２１１に書き込んだ注文番号に該当する注文情報を注文情報データベース２１０より取得する（ステップ１００２）。
【０１０４】
また、支払いシステム１０８は、上述のステップ１００２で取得した注文情報に該当する債権データを債権データベース２１３にて取得する（ステップ１００３）。この場合の支払いシステム１０８は、該当注文情報に含まれる注文番号３０１の値を用いて、債権データベース２１３にて検索を実行し、債権データのうち注文番号６０２の値が注文番号３０１と合致するものを特定し、取得する。
【０１０５】
続いて支払いシステム１０８は、上述のステップ１００１で得た契約データの実行内容７０３の記述に、ステップ１００２で得た注文情報およびステップ１００３で得た債権データを適用して、支払額の算出処理を実行する（ステップ１００４）。
【０１０６】
例えば、“農家Ａ”が“工場Ｂ”に対して、“農家Ａ”が作成した農作物を納入し、
この農作物を“工場Ｂ”で製品に加工する状況を想定する。また、この“農家Ａ”が“小売Ｃ”に対して、“工場Ｂ”で加工した製品の販売を依頼するものとする。さらに、“農家Ａ”と“工場Ｂ”と“小売Ｃ”に対して、農作機械や生産機械やＰＯＳ端末等の商品のリースや融資を行う“リースＧ”が存在するものとする。
【０１０７】
従来であれば、“工場Ｂ”から“農家Ａ”に対する農作物の債務義務、及び“小売Ｃ”から“工場Ｂ”に対する製品の債務義務があり、それぞれで支払いが行われていた。また更に“農家Ａ”、“工場Ｂ”及び“小売Ｃ”から“リースＧ”へのリース設備に対する債務義務が存在し、支払いが行われていた。よって金融業者への支払いが度々発生することとなり、各当事者は金融業者に対して少なくない手数料の支払いが発生していた。
【０１０８】
更に“農家Ａ”、“工場Ｂ”及び“小売Ｃ”それぞれの間での支払いは、支払い手続き
が行われる業者間同士のみの取り決めになっている。よって“小売Ｃ”と“工場Ｂ”との間の取引に“農家Ａ”が加わることは困難である。しかし昨今の加工品は、農作物から加工品を製造する過程で様々な付加価値が加えられ、原料費よりも１５０％以上の値段が設定され、小売店で販売されることが多い。しかし“農家Ａ”は、その生産物である農作物が加工品に加工され、消費者に小売販売されるまでの過程で生じる利益を享受することができない現状があった。
【０１０９】
また、消費者への小売販売や加工品の製造過程で得た売上を、農家に分配しようとした場合、消費者への小売販売が実際に完了するまでは、当該農家に売上金が支払われないことになる。そのため、消費者への販売不振が発生すると農家の経営に深刻な影響を与える可能性が高い。
【０１１０】
そこで本実施例の収益配分システム１００では、仲介業者である“リースＧ”が“農家Ａ”のリスクを肩代わりするための処理を実行する構成となっている。すなわち収益配分システム１００は、“リースＧ”が、契約データベース２１４における、契約ＩＤ７０１が「００１」のレコードの実行内容７０３の記述に従い、“農家Ａ”へ想定売上金を支払うことを可能とする。
【０１１１】
つまり“工場Ｂ”から“農家Ａ”への債務を、“リースＧ”が肩代わりする。しかしこの際の支払いシステム１０８は、“リースＧ”から“農家Ａ”への支払い額を、“工場Ｂ”からの債務額（債権データベース２１３における該当レコードの債務額６０５の値）から、“農家Ａ”から“リースＧ”へ支払われる債務額（債権データベース２１３における該当レコードの債務額６０５の値）を差し引いた金額として特定し、所定の支払い処理（ステップ１００５）を行う。この支払い処理は、例えば、支払いシステム１０８が、金融機関提供の所定のバンキングサービスを用いて、該当金額を該当者の口座に当てた振込処理を行うものなどを想定する。
【０１１２】
なお、上述の支払いシステム１０８は、所有権データベース２１２において、所有権ＩＤ“００２”のレコードで示すように“人参Ａ”の所有者を“リースＧ”に移す処理を行うものとする。よって、“農家Ａ”から“リースＧ”へ支払う金額を“人参Ａ”のような実際の物で支払ったこととなる。しかし“農家Ａ”は売上金を早く確保することができる。また“リースＧ”にとっても、“農家Ａ”のようにキャッシュの確保に困っている業者を囲い込むことができ、リース顧客が増やすことが可能となる。また全体的に銀行への手数料を支払う回数の削減が図れる。
【０１１３】
また更に、支払いシステム１０８は、“リースＧ”に関して、“小売業Ｃ”から“工場Ｂ”に対する債務（債権データベース２１３における該当レコードの債務額６０５の値）を、上述同様の処理を行って肩代わりする処理を実行し、“工場Ｂ”の経営リスクを“リースＧ”が引き受けるよう図ることが可能である。
【０１１４】
“工場Ｂ”から“リースＧ”そして“小売業Ｃ”に至る支払いでは、“リースＧ”から“工場Ｂ”へ農作物（例えば“人参Ａ”）の所有権が移動する。その後、“小売業Ｃ”が“リースＧ”への支払いを完了した場合、加工品（例えば“Ｂドレッシング”）の所有権が“小売業Ｃ”に移る。当然ながら、支払いシステム１０８は、こうした所有権の移動に伴い、所有権データベース２１２を更新する。
【０１１５】
再び図１０の処理フローの説明に戻る。支払いシステム１０８は、債権データベース２１３を更新する（ステップ１００６）。債権データベース２１３の更新方法は、上述の例のように、“リースＧ”が“工場Ｂ”から“農家Ａ”への債務全てを肩代わりして、支払いを完了した場合は債務額６０５の値を０に設定する。もしくは債権データベース２１３
から該当レコードを削除する。一方で債権ＩＤ“００５”のレコードのように、“リースＧ”から“農家Ａ”への農作機械リースの債務額が存在し、“リースＧ”が肩代わりした債務額の残価が発生する場合、“農家Ａ”から“リースＧ”へ納入された“人参Ａ”のうち、従来のリース費用に相当する金額の債務額分を削減する。
【０１１６】
さらに、図７の契約データベース２１４の、契約ＩＤ「００３」のレコードにおける実行内容７０３に記述しているように、“小売業Ｃ”から消費者に商品が販売された場合、支払いシステム１０８は、そこで得られた利益の一部を“農家Ａ”や“工場Ｂ”に自動的に還元するとしてもよい。この場合、例えば“農家Ａ”や“工場Ｂ”から“リースＧ”に対する農作機械や生産設備の債務額を差し引くといった処理を行う。
【０１１７】
また、“農家Ａ”、“工場Ｂ”、“小売業Ｃ”のリスクの一部を肩代わりしている“リースＧ”に対し、上述の利益の一部を手数料として付与し支払いを行うとしてもよい。
【０１１８】
−−−フロー例４（債権データベースの更新処理）−−−
続いて、上述のフロー例３のステップ１００６、すなわち債権データベース２１３の更新処理の一例を図１１に基づき説明する。なお、こうした債権データベース２１３の更新処理は、収益配分システム１００における債権管理システム１０７が担うものとする。
【０１１９】
この場合、債権管理システム１０７は、更新対象となる債権データを債権データベース２１３から取得する（ステップ１１０１）。
【０１２０】
続いて、債権管理システム１０７は、上述のステップ１００４で特定された支払額（債権額の減額内容を含む）の情報を、上述のステップ１１０１で得た債務データにて債務者６０４として規定された事業者の端末に通知する（ステップ１１０２）。
【０１２１】
この通知方法としては、例えば電子メールや、ＳＮＳのメッセージサービス、スマートフォン等の携帯端末によるプッシュ通知などを想定できる。また、債権管理システム１０７が、専用のアプリケーションやＷＥＢサービスを各事業者の端末に配信・提供し、そのＧＵＩを介して通知を行うとしても良い。
【０１２２】
続いて、債権管理システム１０７は、上述の債務者の端末に対して、支払い内容の合意を得るように促す所定メッセージを通知する（ステップ１１０３）。例えば、先ほどのように“農家Ａ”への債務者が“工場Ｂ”から“リースＧ”に変わる場合、“工場Ｂ”および“リースＧ”双方の合意を得るように促すメッセージを、該当端末に通知する。また消費者への販売で得られた利益に基づいて債務額が減額される場合、債務者である例えば“農家Ａ”や“工場Ｂ”、“小売店Ｃ”の各端末に対して、減額内容の合意を促すメッセージを通知する。
【０１２３】
また、債権管理システム１０７は、上述のステップ１１０３における通知に応じ、該当債務者の端末から合意回答が得られたならば、債務データベース２１３及び所有権データベース２１２における該当レコードの該当項目（所有者５０３や、債権者６０３、債務者６０４、債務額６０５の各値）の値を、これまでに特定した値に変更する（ステップ１１０４）。
【０１２４】
その後、債権管理システム１０７は、上述のステップ１１０４にて変更対象の債権データが残っているか判定し（ステップ１１０５）、更新対象の債権データが残っている場合（ステップ１１０５：Ｙｅｓ）、処理をステップ１１０１に戻す。他方、上述の判定の結果、更新対象の債権データが残っていないことが判明した場合（ステップ１１０５：Ｎｏ）、債権管理システム１０７は、処理を終了する。
【０１２５】
以上で説明した、業者間の支払額の算出イメージ及び債権データベース２１３の管理方法の概念を図１２に示す。収益配分システム１００は、農作物の生産、加工、小売販売といった、第一次産業の第六次産業化を図った商流において、当該商流の各参加者のうち例えば“農家Ａ”に関して、その農作物“人参Ａ”の販売先たる“加工業者Ｂ”に関して保持する債権（“人参Ａ”の販売代金）から、仲介業者たる“リースＧ”に関して保持する債務（“リースＧ”に貸与された農作機械のリース代金）を差し引きした差分の金額に、“小売業者Ｃ”における商品“Ｂドレッシング”（“加工業者Ｂ”が“農家Ａ”から仕入れた“人参Ａ”を加工して製造した加工品）の小売販売で得た利益の所定割合を付加して、支払い額を算定し、これを“農家Ａ”に支払う。
【０１２６】
同様に、収益配分システム１００は、“加工業者Ｂ”に関して、上述の加工品“Ｂドレッシング”の販売先たる“小売業者Ｃ”に関して保持する債権（“Ｂドレッシング”の販売代金）から、仲介業者たる“リースＧ”に関して保持する債務（“リースＧ”に貸与された生産機械のリース代金）を差し引きした差分の金額に、“小売業者Ｃ”における商品“Ｂドレッシング”の小売販売で得た利益の所定割合を付加して、支払い額を算定し、これを“加工業者Ｂ”に支払う。
【０１２７】
また、収益配分システム１００は、“小売業者Ｃ”に関して、上述の加工品“Ｂドレッシング”の販売先たる消費者から商品代金を得る一方、“加工業者Ｂ小売業者Ｃ”に関して保持する債権（“Ｂドレッシング”の販売代金）から、仲介業者たる“リースＧ”に関して保持する債務（“リースＧ”に貸与された生産機械のリース代金）を差し引きした差分の金額に、“小売業者Ｃ”における商品“Ｂドレッシング”の小売販売で得た利益の所定割合を付加して、支払い額を算定し、これを“加工業者Ｂ”に支払う。
【０１２８】
つまり、収益配分システム１００は、農家により生産された農作物が流通することで得られる最終的な収益（“Ｂドレッシング”の小売販売による利益）を、当該農作物の流通に関わった“農家Ａ”をはじめとする各業者に配分するプラットフォームとなる。
【０１２９】
なお、収益配分システム１００は、仲介業者たる“リースＧ”による各者の債務の肩代わりに関する処理として、既に述べたように、“農家Ａ”について“加工業者Ｂ”が保持する債務（“人参Ａ”の販売代金）、“加工業者Ｂ”について“小売業者Ｃ”が保持する債務（“Ｂドレッシング”の販売代金）、をそれぞれ仲介業者が引き受ける形となるべく、所有権データベース２１２および債権データベース２１３において、所有権および債権の所在を“リースＧ”と設定する。
【０１３０】
また、収益配分システム１００は、農家など第一次産業の従事者において収益を得られるタイミングを早期化し、また金融機関への支払い手数料の発生を低減可能である。例えば、収益配分システム１００は、“小売業者Ｃ”での“Ｂドレッシング”の販売前のタイミング（例えば、“農家Ａ”が“加工業者Ｂ”に“人参Ａ”を納入した時点）で、上述の収益の額を、所定の収益予測アルゴリズムに基づいて算出し、当該算出した収益額を、“農家Ａ”をはじめとする各事業者への支払額に加算する。上述の収益予測アルゴリズムとしては、農作物や加工品の属性とその販売実績とに関する相関分析結果に基づいて、対象となる農作物等の所定時期での販売予測を行うなどといった、既存のものを適宜に採用すればよい。
【０１３１】
なお、収益配分システム１００は、債権データベース２１３の債務額６０５の値を、時間経過と共に所定規則にて変動させるとしてもよい。例えば、為替や市況などのマクロ環境の指数情報を外部ソースから取得し、該当情報を所定ルール（例：株価指数の上下動と債務額６０５の値の上下動とを所定割合で連動させる）に適用して債務額６０５の値を変
動させるといった構成を想定出来る。
【０１３２】
また、本実施形態にて示した業者の例の他、例えば、各種資材等の材料メーカー、農作機械用の部品メーカー、及び、セットメーカーのような、サプライチェーンに関係する業者を更に想定するとしてもよい。
【０１３３】
−−−実施例２−−−
実施例１では、従来型の中央集権型のシステムによる構成での収益配分システム１００の例を示した。実施例２では、収益配分システムを分散台帳システムとして構成し活用した例について示すものとする。こうした分散台帳システムを適用することで、ブロックチェーン技術における特性である、耐障害性向上やデータ改ざん防止などの効果が、実施例１における収益配分システム１００の効果に、更に付加されることとなる。
【０１３４】
図１３は、実施例２における収益配分システム１００の構成例を示す図であり、図１４は、実施例２の収益配分システムを構成する端末のハードウェア構成例を示す図である。
【０１３５】
図１３で示す構成は、図１の構成とほぼ同様であるが、ネットワーク１０がブロックチェーンネットワーク１３０９に置き換わっている。また、それに伴い、注文システム１０６、債権管理システム１０７、および、支払いシステム１０８は省略されている。なお、実施例２は実施例１と多くの点で同様の構成を取るため、以下では異なる点のみを示す。
【０１３６】
上述のブロックチェーンネットワーク１３０９は、農家端末１０１、加工業者端末１０２、小売業者端末１０３、および、仲介業者端末１０５を、分散台帳システムの構成ノードとして互いに通信可能に接続するネットワークである。よって、農家端末１０１、加工業者端末１０２、小売業者端末１０３、および、仲介業者端末１０５は、それぞれの記憶装置において分散台帳１２００を備える。各端末での処理に伴うトランザクションは、各端末に配信され、ブロックチェーン技術による各ノードでの合意形成の後、それぞれの分散台帳にて蓄積されブロックチェーンを形成する。こうしたブロックチェーン技術を活用することで、商流の参加者のうち悪意の者によるデータ改ざんが事実上不可能となる。
【０１３７】
なお、実施例１では示した注文システム１０６、債権管理システム１０７、および、支払いシステム１０８については、農家端末１０１、加工業者端末１０２、小売業者端末１０３、および、仲介業者端末１０５のそれぞれに、対応するプログラム１４２０、１４２１、１４２２をインストールして実装するとしても良い（図１４参照）。
【０１３８】
こうした構成において、例えば、“加工業者Ｂ”の加工業者端末１０２が、“農家Ａ”の農作物“人参Ａ”に関する注文処理を、自身の注文プログラム１４２０で実行したとする。すると、当該加工業者端末１０２は、当該注文における注文内容等の情報を含むトランザクションを発行し、ブロックチェーンネットワーク１３０９における他のノード、すなわち“農家Ａ”の農家端末１０１、“小売業者Ｃ”の小売業者端末１０３、および、仲介業者たる“リースＧ”の仲介業者端末１０５、のぞれぞれに配信する。こうした配信を受けた端末らは、ブロックチェーン技術における合意形成処理を実行し、当該トランザクションを含む一定時間内に生じたトランザクション群をブロックチェーンとして分散台帳１２００に格納する。
【０１３９】
上述のトランザクション発行を起点とした分散台帳１２００でのブロックチェーン格納に至る処理は、注文、注文内容の合意、注文情報データベース２１０への格納、納入イベント発生、出荷記録データベース２１１への書き込み、債権情報の追加、取引額算出、支払い額算出と支払い処理、債権データベース２１３の更新、といった各イベントの発生ごとに実行され、ブロックチェーンネットワーク１３０９に接続された各ノードたる端末そ
れぞれは、商流の参加者として自他の参加者の動向を全て検証できることとなる。
【０１４０】
なお、ブロックチェーン技術において、単純な取引だけでなく、複雑な取引条件に対応して自律的に取引を遂行すべく、いわゆるスマートコントラクトの仕組みが存在する。
【０１４１】
そこで、こうしたスマートコントラクトの仕組みを実施例２の収益配分システム１００に適用して、注文に対する合意確認処理、契約データベース２１４の契約データに基づく支払い額の算出と支払い実行の処理、債権データの更新処理、といった処理を、商流の各参加者の端末からそれぞれ得た情報や各データベース類から得た情報に基づき自律的に実行する、注文プログラム１４２０、支払プログラム１４２１、債権管理プログラム１４２２を、各端末にて備えるとしてもよい。勿論、これらスマートコントラクトたる各プログラムでの処理に伴うトランザクションも、ブロックチェーンネットワーク１３０９に配信され、各端末での合意形成の後、分散台帳１２００に格納され、ブロックチェーンを形成することとなる。
【０１４２】
以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【０１４３】
こうした本実施形態によれば、第一次産業の従事者らにおける収入の安定化および早期化を図り、ひいては六次産業化の促進が支援可能となる。
【０１４４】
本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の収益配分システムにおいて、前記演算装置は、前記取引の情報に基づいて、前記商流の末端での取引にて当該取引の債権者が得た収益額を特定し、前記仲介業者が前記商流の各取引の債権者に関して保持する債権と前記買取処理で当該債権者から得た所有権との間の価値の差分に、前記収益額を加算し、前記各取引の債権者に対する、前記差分に前記収益額を加算して得た金額の所定の支払処理を実行するものである、としてもよい。
【０１４５】
これによれば、いわゆる六次産業化した上述の商流における各取引にて、その当事者たる商流上流側の債権者（第一次産業の従事者含む）に対し、仲介業者から早期に収益分配がなされることに加えて、更に、商流末端の小売販売での収益も分配されることとなり、第一次産業の従事者らにおける、更なる収入の安定化および早期化を図ることができる。
【０１４６】
また、本実施形態の収益配分システムにおいて、前記演算装置は、前記商流の末端での取引前に、前記収益額を所定の収益予測アルゴリズムに基づいて算出し、当該算出した収益額を前記差分に加算するものである、としてもよい。
【０１４７】
これによれば、いわゆる六次産業化した上述の商流における各取引にて、その当事者たる商流上流側の債権者（第一次産業の従事者含む）に対し、仲介業者から早期に収益分配がなされることに加えて、更に、商流末端の小売販売を待たずして、その予想収益も分配されることとなり、第一次産業の従事者らにおける、より一層の収入の安定化および早期化を図ることができる。
【０１４８】
また、本実施形態の収益配分システムにおいて、前記商流の参加者それぞれの端末において、前記商流の各取引に関する情報を当該端末の記憶装置で保持する分散台帳で管理してなるとしてもよい。
【０１４９】
これによれば、収益配分方法の実行主体を、分散台帳システムにおける各端末（商流の参加者それぞれの端末）として、各取引に伴う情報の正しさの検証を当該参加者それぞれで検証し保証しあうことが可能となる。また、それぞれの取引で生じた収益、債権、債務
の内容等についても参加者それぞれでチェック可能であって、収益配分の正しさ、公正性を精度良く担保することができる。ひいては、第一次産業の従事者らにおける収入の安定化および早期化を高い精度で図ることができる。
【符号の説明】
【０１５０】
１０  ネットワーク
１００  収益配分システム
１０１  農家端末
１０２  加工業者端末
１０３  小売業者端末
１０４  消費者端末
１０５  仲介業者端末
１０６  注文システム
１０７  債権管理システム
１０８  支払いシステム
２０１  バス
２０２  ＣＰＵ
２０３  ネットワークインターフェイス
２０４  入力装置
２０５  記憶装置
２０６  出力装置
２１０  注文情報データベース
２１１  出荷記録データベース
２１２  所有権データベース
２１３  債権データベース
２１４  契約データベース
２１５  プログラム
１２００  分散台帳
１３０９  ブロックチェーンネットワーク
１４２０  注文プログラム
１４２１  支払プログラム
１４２２  債権管理プログラム
【図１】
2019049930.tif 000003
【図２】
2019049930.tif 000004
【図３】
2019049930.tif 000005
【図４】
2019049930.tif 000006
【図５】
2019049930.tif 000007
【図６】
2019049930.tif 000008
【図７】
2019049930.tif 000009
【図８】
2019049930.tif 000010
【図９】
2019049930.tif 000011
【図１０】
2019049930.tif 000012
【図１１】
2019049930.tif 000013
【図１２】
2019049930.tif 000014
【図１３】
2019049930.tif 000015
【図１４】
2019049930.tif 000016