(57)【要約】  融通管理システム１００は、第１の主体と第２の主体間でのエネルギー等の相互融通を管理する融通管理装置１０４と、第１の主体と第２の主体間でのエネルギー等の融通実績情報を融通管理装置１０４へ入力する情報端末１０２を備える。融通管理装置１０４は、情報端末１０２から入力されたエネルギー等の融通実績情報に基づいて、エネルギー等の融通元、融通先、融通対象、融通量を対応付けた情報であり、エネルギー等についての債権情報と債務情報を記録する。融通管理装置１０４は、ある主体に関するエネルギー等の債権情報と債務情報の少なくとも一方を集計することにより、当該主体に関するエネルギー等の残高情報を生成する。
2017030086.tif 000002
【特許請求の範囲】
【請求項１】
第１の主体と第２の主体間でのエネルギー、廃棄物、または汚染物質等（以下「エネルギー等」と称する。）の相互融通を管理する融通管理装置と、
前記第１の主体と第２の主体間での前記エネルギー等の融通実績情報を前記融通管理装置へ入力する情報端末と、を備え、
前記融通管理装置は、
前記情報端末から入力された前記エネルギー等の融通実績情報に基づいて、前記エネルギー等の融通元、融通先、融通対象、融通量を対応付けた情報であり、前記エネルギー等についての債権情報と債務情報を記録する記録部と、
ある主体に関する前記エネルギー等の債権情報と債務情報の少なくとも一方を集計することにより、当該主体に関する前記エネルギー等の残高情報を生成する評価部と、を含むことを特徴とする融通管理システム。
【請求項２】
前記評価部は、前記債権情報が示す債権と前記債務情報が示す債務とを相殺した結果を含む残高情報を生成することを特徴とする請求項１に記載の融通管理システム。
【請求項３】
前記評価部は、ある主体に関する前記エネルギー等の残高情報を生成した場合に、生成した残高情報を当該主体に対応付けて記憶部へ格納することを特徴とする請求項１または２に記載の融通管理システム。
【請求項４】
前記融通管理装置は、融通対象となるエネルギー等の価格情報を取得する価格情報取得部をさらに含み、
前記評価部は、取得された価格情報に基づいて、前記債権情報が示す債権、または、前記債務情報が示す債務の大きさを示す値を、物量単位から、金銭、電子マネー、または仮想通貨の単位に変換することを特徴とする請求項１から３のいずれかに記載の融通管理システム。
【請求項５】
前記融通管理装置は、前記エネルギー等の融通に関して予め定められた交換レートを取得する交換レート取得部をさらに含み、
前記評価部は、取得された交換レートに基づいて、前記債権情報が示す債権と前記債務情報が示す債務とを相殺することを特徴とする請求項１から４のいずれかに記載の融通管理システム。
【請求項６】
前記融通管理装置は、前記情報端末から評価情報の提供の要求を受け付けた場合に、前記評価部により生成された残高情報であって、前記情報端末により指定された主体に関する残高情報を前記情報端末へ送信することを特徴とする請求項１から５のいずれかに記載の融通管理システム。
【請求項７】
第１の主体と第２の主体間でのエネルギー、廃棄物、または汚染物質等（以下「エネルギー等」と称する。）の相互融通を管理する融通管理装置であって、
前記第１の主体と第２の主体間での前記エネルギー等の融通実績情報を取得する融通実績取得部と、
取得された融通実績情報に基づいて、前記エネルギー等の融通元、融通先、融通対象、融通量を対応付けた情報であり、前記エネルギー等についての債権情報と債務情報を記録する記録部と、
ある主体に関する前記エネルギー等の債権情報と債務情報の少なくとも一方を集計することにより、当該主体に関する前記エネルギー等の残高情報を生成する評価部と、
を備えることを特徴とする融通管理装置。
【請求項８】
第１の主体から第２の主体へ金銭の移動を伴わずに財が融通された場合に、融通量に応じた債権の大きさを前記財の計量単位で示す債権情報を第１の主体に対応付けて記録するとともに、前記融通量に応じた債務の大きさを前記財の計量単位で示す債務情報を第２の主体に対応付けて記録する記録部と、
所定の評価タイミングに至った場合に、前記記録部により１つの主体に対応付けて記録された債権情報と債務情報の少なくとも一方を集計した残高情報を生成する評価部と、
を備えることを特徴とする融通管理装置。
【請求項９】
第１の主体から第２の主体へマイナスの価値を有する財である環境負荷財が金銭の移動を伴わずに移転された場合に、移転量に応じた債務の大きさを前記環境負荷財の計量単位で示す債務情報を前記第１の主体に対応付けて記録するとともに、前記移転量に応じた債権の大きさを前記環境負荷財の計量単位で示す債権情報を前記第２の主体に対応付けて記録する記録部と、
所定の評価タイミングに至った場合に、前記記録部により１つの主体に対応付けて記録された債権情報と債務情報の少なくとも一方を集計した情報を生成する評価部と、
を備えることを特徴とする環境負荷財移転管理装置。
【請求項１０】
第１の主体と第２の主体間でのエネルギー、廃棄物、または汚染物質等（以下「エネルギー等」と称する。）の相互融通を管理する装置と通信網を介して接続される情報端末であって、
前記第１の主体と第２の主体間での前記エネルギー等の融通実績情報を前記管理する装置へ送信することにより、前記管理する装置に、前記エネルギー等の融通実績情報に基づいて、前記エネルギー等の融通元、融通先、融通対象、融通量を対応付けた情報であり、前記エネルギー等についての債権情報と債務情報を記録させる送信部と、
前記管理する装置により生成された残高情報であって、ある主体に関する前記エネルギー等の債権情報と債務情報の少なくとも一方を集計することにより生成された前記エネルギー等の残高情報を取得し、取得した前記エネルギー等の残高情報を表示装置に表示させる表示部と、
を備えることを特徴とする情報端末。
【請求項１１】
第１の主体と第２の主体間における金銭の移動を伴わない財の融通を管理する装置と通信網を介して接続される情報端末であって、
第１の主体から第２の主体へ金銭の移動を伴わずに財が融通されたことを示す情報を前記管理する装置へ送信することにより、前記管理する装置に、前記財の融通量に応じた債権の大きさを前記財の計量単位で示す債権情報を第１の主体に対応付けて記録させるとともに、前記財の融通量に応じた債務の大きさを前記財の計量単位で示す債務情報を第２の主体に対応付けて記録させる送信部と、
前記管理する装置により生成された残高情報であって、１つの主体に対応付けて記録された債権情報と債務情報の少なくとも一方を集計した残高情報を取得し、取得した残高情報を表示装置に表示させる表示部と、
を備えることを特徴とする情報端末。
【請求項１２】
マイナスの価値を有する財である環境負荷財について、第１の主体と第２の主体間における金銭の移動を伴わない環境負荷財の移転を管理する装置と通信網を介して接続される情報端末であって、
第１の主体から第２の主体へ金銭の移動を伴わずに環境負荷財が移転されたことを示す情報を前記管理する装置へ送信することにより、前記管理する装置に、前記環境負荷財の移転量に応じた債務の大きさを前記環境負荷財の計量単位で示す債務情報を前記第１の主体に対応付けて記録させるとともに、前記移転量に応じた債権の大きさを前記環境負荷財の計量単位で示す債権情報を前記第２の主体に対応付けて記録させる送信部と、
前記管理する装置により生成された残高情報であって、１つの主体に対応付けて記録された債権情報と債務情報の少なくとも一方を集計した残高情報を取得し、取得した残高情報を表示装置に表示させる表示部と、
を備えることを特徴とする情報端末。
【請求項１３】
第１の主体と第２の主体間でのエネルギー、廃棄物、または汚染物質等（以下「エネルギー等」と称する。）の相互融通を管理する方法であって、
前記第１の主体と第２の主体間での前記エネルギー等の融通実績情報を取得するステップと、
取得された融通実績情報に基づいて、前記エネルギー等の融通元、融通先、融通対象、融通量を対応付けた情報であり、前記エネルギー等についての債権情報と債務情報を記録するステップと、
ある主体に関する前記エネルギー等の債権情報と債務情報の少なくとも一方を集計することにより、当該主体に関する前記エネルギー等の残高情報を生成するステップと、
をコンピュータが実行することを特徴とする融通管理方法。
【請求項１４】
第１の主体と第２の主体間でのエネルギー、廃棄物、または汚染物質等（以下「エネルギー等」と称する。）の相互融通を管理するコンピュータプログラムであって、
前記第１の主体と第２の主体間での前記エネルギー等の融通実績情報を取得する機能と、
取得された融通実績情報に基づいて、前記エネルギー等の融通元、融通先、融通対象、融通量を対応付けた情報であり、前記エネルギー等についての債権情報と債務情報を記録する機能と、
ある主体に関する前記エネルギー等の債権情報と債務情報の少なくとも一方を集計することにより、当該主体に関する前記エネルギー等の残高情報を生成する機能と、
をコンピュータに実現させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ処理技術に関し、特に融通管理システム、融通管理装置、環境負荷財移転管理装置、情報端末、融通管理方法およびコンピュータプログラムに関する。
【背景技術】
【０００２】
本発明者は、交換代数を適用して実物の取引を記録する手法を提案している（例えば非特許文献１参照）。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】出口  弘、"トランザクションベースの経済システム学  - そのリサーチプログラムと方法論 -"、[online]、平成25年2月21日、進化経済学会、[平成27年8月10日検索]、インターネット<URL:http://c-faculty.chuo-u.ac.jp/~jafee/papers/Deguchi_Hiroshi2.pdf>
【発明の概要】
【発明が解決しようとする課題】
【０００４】
「市場」という仕組みは、近代資本主義の発明品であり、交換対象の財やサービスの価格を事前に評価することで、互いに面識のない多数の人々の間で財やサービスの交換を可能にする。また市場によって結果的に需給が均衡するとされている。しかし、比較的小規模なコミュニティ内で互いに面識のあるメンバ間で財やサービスを融通しあう場合、財やサービスに事前に価格づけすることはなじまないことが多々ある。市場的な価格づけに基づく需給は、コミュニティ内での相互融通の適切性を必ずしも保証しないからである。また、融通対象の財やサービスに対する事前の価格づけが困難なこともある。【０００５】
持続可能な融通型のシステムを実現するためには、融通を行う主体間で一方的な有利や不利が生じないようにバランスを取る必要があると本発明者は考えた。例えば、財やサービスの相互融通が行われた場合に、事後のあるタイミングでは金銭的または実物的な清算が必要になる。しかし、このような融通型のシステムを適切に管理する具体的な方法はこれまで十分に提案されていなかった。【０００６】
本発明は上記課題を鑑みてなされたものであり、その主な目的は、複数の主体間でなされる財の融通を適切に管理することを支援する技術を提供することである。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明のある態様の融通管理システムは、第１の主体と第２の主体間でのエネルギー、廃棄物、または汚染物質等（以下「エネルギー等」と称する。）の相互融通を管理する融通管理装置と、第１の主体と第２の主体間でのエネルギー等の融通実績情報を融通管理装置へ入力する情報端末と、を備える。融通管理装置は、情報端末から入力されたエネルギー等の融通実績情報に基づいて、エネルギー等の融通元、融通先、融通対象、融通量を対応付けた情報であり、エネルギー等についての債権情報と債務情報を記録する記録部と、ある主体に関するエネルギー等の債権情報と債務情報の少なくとも一方を集計することにより、当該主体に関するエネルギー等の残高情報を生成する評価部と、を含む。【０００８】
本発明の別の態様は、融通管理装置である。この装置は、第１の主体と第２の主体間でのエネルギー、廃棄物、または汚染物質等（以下「エネルギー等」と称する。）の相互融通を管理する融通管理装置であって、第１の主体と第２の主体間でのエネルギー等の融通実績情報を取得する融通実績取得部と、取得された融通実績情報に基づいて、エネルギー等の融通元、融通先、融通対象、融通量を対応付けた情報であり、エネルギー等についての債権情報と債務情報を記録する記録部と、ある主体に関するエネルギー等の債権情報と債務情報の少なくとも一方を集計することにより、当該主体に関するエネルギー等の残高情報を生成する評価部と、を備える。【０００９】
本発明のさらに別の態様もまた、融通管理装置である。この装置は、第１の主体から第２の主体へ金銭の移動を伴わずに財が融通された場合に、融通量に応じた債権の大きさを財の計量単位で示す債権情報を第１の主体に対応付けて記録するとともに、融通量に応じた債務の大きさを財の計量単位で示す債務情報を第２の主体に対応付けて記録する記録部と、所定の評価タイミングに至った場合に、記録部により１つの主体に対応付けて記録された債権情報と債務情報の少なくとも一方を集計した残高情報を生成する評価部と、を備える。【００１０】
本発明のさらに別の態様は、環境負荷財移転管理装置である。この装置は、第１の主体から第２の主体へマイナスの価値を有する財である環境負荷財が金銭の移動を伴わずに移転された場合に、移転量に応じた債務の大きさを環境負荷財の計量単位で示す債務情報を第１の主体に対応付けて記録するとともに、移転量に応じた債権の大きさを環境負荷財の計量単位で示す債権情報を第２の主体に対応付けて記録する記録部と、所定の評価タイミングに至った場合に、記録部により１つの主体に対応付けて記録された債権情報と債務情報の少なくとも一方を集計した情報を生成する評価部と、を備える。【００１１】
本発明のさらに別の態様は、情報端末である。この情報端末は、第１の主体と第２の主体間でのエネルギー、廃棄物、または汚染物質等（以下「エネルギー等」と称する。）の相互融通を管理する装置と通信網を介して接続される情報端末であって、第１の主体と第２の主体間でのエネルギー等の融通実績情報を管理する装置へ送信することにより、管理する装置に、エネルギー等の融通実績情報に基づいて、エネルギー等の融通元、融通先、融通対象、融通量を対応付けた情報であり、エネルギー等についての債権情報と債務情報を記録させる送信部と、管理する装置により生成された残高情報であって、ある主体に関するエネルギー等の債権情報と債務情報の少なくとも一方を集計することにより生成されたエネルギー等の残高情報を取得し、取得したエネルギー等の残高情報を表示装置に表示させる表示部と、を備える。【００１２】
本発明のさらに別の態様もまた、情報端末である。この情報端末は、第１の主体と第２の主体間における金銭の移動を伴わない財の融通を管理する装置と通信網を介して接続される情報端末であって、第１の主体から第２の主体へ金銭の移動を伴わずに財が融通されたことを示す情報を管理する装置へ送信することにより、管理する装置に、財の融通量に応じた債権の大きさを財の計量単位で示す債権情報を第１の主体に対応付けて記録させるとともに、財の融通量に応じた債務の大きさを財の計量単位で示す債務情報を第２の主体に対応付けて記録させる送信部と、管理する装置により生成された残高情報であって、１つの主体に対応付けて記録された債権情報と債務情報の少なくとも一方を集計した残高情報を取得し、取得した残高情報を表示装置に表示させる表示部と、を備える。【００１３】
本発明のさらに別の態様もまた、情報端末である。この情報端末は、マイナスの価値を有する財である環境負荷財について、第１の主体と第２の主体間における金銭の移動を伴わない環境負荷財の移転を管理する装置と通信網を介して接続される情報端末であって、第１の主体から第２の主体へ金銭の移動を伴わずに環境負荷財が移転されたことを示す情報を管理する装置へ送信することにより、管理する装置に、環境負荷財の移転量に応じた債務の大きさを環境負荷財の計量単位で示す債務情報を第１の主体に対応付けて記録させるとともに、移転量に応じた債権の大きさを環境負荷財の計量単位で示す債権情報を第２の主体に対応付けて記録させる送信部と、管理する装置により生成された残高情報であって、１つの主体に対応付けて記録された債権情報と債務情報の少なくとも一方を集計した残高情報を取得し、取得した残高情報を表示装置に表示させる表示部と、を備える。【００１４】
本発明のさらに別の態様は、融通管理方法である。この方法は、第１の主体と第２の主体間でのエネルギー、廃棄物、または汚染物質等（以下「エネルギー等」と称する。）の相互融通を管理する方法であって、第１の主体と第２の主体間でのエネルギー等の融通実績情報を取得するステップと、取得された融通実績情報に基づいて、エネルギー等の融通元、融通先、融通対象、融通量を対応付けた情報であり、エネルギー等についての債権情報と債務情報を記録するステップと、ある主体に関するエネルギー等の債権情報と債務情報の少なくとも一方を集計することにより、当該主体に関するエネルギー等の残高情報を生成するステップと、をコンピュータが実行する。【００１５】
なお、以上の構成要素の任意の組合せ、本発明の表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１６】
本発明によれば、複数の主体間でなされる財の融通を適切に管理することを支援できる。
【図面の簡単な説明】
【００１７】
【図１】売上伝票の例を示す図である。
【図２】前提技術２のデータ編集装置の機能構成を示すブロック図である。
【図３】会計型データを操作するためのユーザコードの一例を示す図である。
【図４（ａ）】図３のユーザコードに対応する実行コードを示す図である。
【図４（ｂ）】図３のユーザコードに対応する実行コードを示す図である。
【図５】レコード型データを操作するためのユーザコードの一例を示す図である。
【図６（ａ）】図５のユーザコードに対応する実行コードを示す図である。
【図６（ｂ）】図５のユーザコードに対応する実行コードを示す図である。
【図７】データ編集装置の動作を示すフローチャートである。
【図８】第１実施形態の融通管理システムの構成を示す図である。
【図９】融通管理装置の動作を説明するフローチャートである。
【図１０】第４変形例の融通管理システムの構成を示す図である。
【図１１】第２実施形態の環境負荷財移転管理システムの構成を示す図である。
【図１２】ある企業における様々な取引を実物簿記記述により記録したデータを示す図である。
【図１３】ある企業における様々な取引を実物簿記記述により記録したデータを示す図である。
【図１４】価格情報を示す図である。
【図１５】実物簿記データを金額表示へ変換した財務会計データを示す図である。
【図１６】実物簿記データを金額表示へ変換した財務会計データを示す図である。
【図１７】第３実施形態の企業状態管理システムの構成を示す図である。
【図１８】第４実施形態の融通管理システムの構成を示す図である。
【発明を実施するための形態】
【００１８】
（前提技術１）
本発明の実施の形態の構成を説明する前に、本実施の形態の前提となる交換代数について説明する。
【００１９】
本発明者は、以下に示す２つのデータ構造により、企業等の組織における８〜９割のデータを表現することができると考えた。
１．多分類数値型（以下、「会計型データ」とも呼ぶ。）
データの値とデータの属性（以下、「基底」とも呼ぶ。）の組み合わせであり、データの値として数値が用いられ、データの属性として名称・単位・時間・主体が用いられる。例えば、４０＜現金，円＞＋３０＜ミカン，個＞・・・と表現される。
２．多分類混合型（以下、「レコード型データ」とも呼ぶ。）
データの値と基底の組み合わせであり、データの値および基底には数値や数値以外の様々なリテラルが用いられる。例えば、５５＜年齢＞＋山田太郎＜名前＞＋津軽＜好きな果物＞・・・と表現される。
以下では、主に会計型データについて詳細に説明する。
【００２０】
会計型データは、何らかの分類された項目ごとに与えられた数値データをまとめて表現し、その上で演算を行うための代数系（以下、「交換代数」とも呼ぶ。）に属するものであり、交換代数データとも言える。会計型データにおける基底（すなわち分類項目）は、＜名称，単位，時間，主体＞と４つの項目からなる。データは、１以上の基底に対する値の組み合わせ、言い換えれば、１以上の基底に対する値の和で表現される。
例１：ｘ＝２００＜リンゴ，円，＃，＃＞＋４００＜さんま，円，＃，＃＞
例２：ｙ＝２００＜リンゴ，円，２００６年第１四半期，＃＞＋４００＜リンゴ，円，２００６年第２四半期，＃＞＋７２０＜リンゴ，円，２００６年第３四半期，＃＞
上記の例１では時間と主体が省略されており、例２では主体が省略されている。例２は時系列データが表現されたものとも言える。また基底の主体には企業名等の組織の識別情報が設定されてもよい。
【００２１】
交換代数による表現のメリットとして、様々な基底（分類）を用いてデータを表現できること、またプログラムコードではなく人間に解釈容易な文字で基底を表現できることが挙げられる。さらにまた、後述するように振替という演算による統一的なデータ編集が可能になる。
【００２２】
前提技術の交換代数では、マイナスの数値の代わりに＾（ハット）という記号を用いる。例えばｘ＝２０＾＜リンゴ，＃，＃，＃＞はリンゴが２０減ることを示す。言い換えれば、＾はある項目に対して相殺すべき反対項目を意味する基底を示す。また相殺操作を表す作用素（オペレータ）として「〜（バー）」を導入する。以下例を示す。
ｘ１＝３０＜現金＞＋２０＜リンゴ＞＋５０＜負債＞
ｙ１＝＾ｘ１＝３０＾＜現金＞＋２０＾＜リンゴ＞＋５０＾＜負債＞
〜（ｙ１＋ｘ１）＝（３０＾＜現金＞＋２０＾＜リンゴ＞＋５０＾＜負債＞）＋（３０＜現金＞＋２０＜リンゴ＞＋５０＜負債＞）＝０
【００２３】
次に、交換代数による振替え操作について説明する。簿記では振替という操作がある。これは一種の分類替え（基底変換）の操作と言える。ここでは、図１の（ａ）に示す八百屋の売上伝票を図１の（ｂ）に示す売上伝票へ振替える例を示す。
【００２４】
図１の（ａ）および（ｂ）で示す取引は円表示で以下のように表現できる。
ｘ１＝２００＜現金，円＞＋１００＾＜リンゴ，円＞＋１００＜利益，円＞
ｘ２＝５０＜光熱費，円＞＋５０＾＜現金，円＞
ｘ３＝１００＾＜利益，円＞＋１００＜営業収益，円＞
ｘ４＝５０＾＜営業収益，円＞＋５０＾＜光熱費，円＞
ｙ＝ｘ１＋ｘ２＋ｘ３＋ｘ４＝（２００＜現金，円＞＋１００＾＜リンゴ，円＞＋１００＜利益，円＞）＋（５０＜光熱費，円＞＋５０＾＜現金，円＞）＋（１００＾＜利益，円＞＋１００＜営業収益，円＞）＋（５０＾＜営業収益，円＞＋５０＾＜光熱費，円＞）
〜ｙ＝１５０＜現金，円＞＋１００＾＜リンゴ，円＞＋５０＜営業収益，円＞
【００２５】
次に、振替え操作と見なすアグリゲーション（合併）と按分について説明する。
１．アグリゲーション
３００円の津軽と２００円の富士と１００円の紅玉（いずれもリンゴの１品種）があったとする。これを、ｘ＝３００＜津軽，円＞＋２００＜富士，円＞＋１００＜紅玉，円＞と表現する。この津軽・富士・紅玉を「リンゴ」とまとめて分類する操作も一種の振替であり、アグリゲーションとよぶ。なお前提として｛津軽，富士，紅玉｝-->{リンゴ}という対応関係のマップが与えられている必要がある。
【００２６】
この例では上記の対応関係のマップにしたがって、Ｆ（ｘ）＝３００＾＜津軽，円＞＋２００＾＜富士，円＞＋１００＾＜紅玉，円＞＋３００＜リンゴ，円＞＋２００＜リンゴ，円＞＋１００＜リンゴ，円＞、という元を生成する。基底＜リンゴ＞の値は、集約対象の基底＜津軽＞、＜富士＞、＜紅玉＞のそれぞれに対する値である。言い換えれば、集約対象の基底＜津軽＞、＜富士＞、＜紅玉＞のそれぞれに対する値の集計値が、基底＜リンゴ＞の値として算出される。
【００２７】
アグリゲーションを表す振替Ｇ（ｘ）は、Ｆ（ｘ）を用いて、〜｛ｘ＋Ｆ（ｘ）｝で与えられる。すなわち、Ｇ（ｘ）＝〜｛ｘ＋Ｆ（ｘ）｝＝（３００＜津軽，円＞＋２００＜富士，円＞＋１００＜紅玉，円＞）＋（３００＾＜津軽，円＞＋２００＾＜富士，円＞＋１００＾＜紅玉，円＞＋３００＜リンゴ，円＞＋２００＜リンゴ，円＞＋１００＜リンゴ，円＞）＝６００＜リンゴ，円＞、となる。
【００２８】
２．按分
按分とは、１つの分類項目をさらに細かく複数の分類項目へ分割することである。例えば、アグリゲーションに示した例では基底＜リンゴ＞に対応する値を、津軽・富士・紅玉へ分割することを意味する。なお前提として｛リンゴ｝-->｛津軽，富士，紅玉｝の按分比率が与えられている必要があり、ここでは１：１：１であることとする。
【００２９】
この例では上記の按分比率にしたがって、ｘ＝６００＜リンゴ，円＞に対して、Ｆ（ｘ）＝６００＾＜リンゴ，円＞＋２００＜津軽，円＞＋２００＜富士，円＞＋２００＜紅玉，円＞、という元を生成する。
按分を表す振替えＧ（ｘ）は、Ｆ（ｘ）を用いて、〜｛ｘ＋Ｆ（ｘ）｝で与えられる。すなわち、Ｇ（ｘ）＝〜｛ｘ＋Ｆ（ｘ）｝＝６００＜リンゴ，円＞＋（６００＾＜リンゴ，円＞＋２００＜津軽，円＞＋２００＜富士，円＞＋２００＜紅玉，円＞）＝２００＜津軽，円＞＋２００＜富士，円＞＋２００＜紅玉，円＞、となる。
【００３０】
（前提技術２）
以下、前提技術１の交換代数の考え方を利用してデータ編集処理を実行する情報処理装置（以下、「データ編集装置」と呼ぶ。）について説明する。前提技術２において、ユーザは、対象がその集合に属するための必要十分条件を与えることによって集合を記述する方法である内包的記法を用いて、データの編集内容を記述する。前提技術２のデータ編集装置は、内包的記法により記述された編集内容に基づいて、集合の要素をすべて列挙することで集合を記述する方法である外延的記法で記述されたプログラムコードを出力する。そして、編集対象のデータを、交換代数に対応する形式のデータオブジェクトとしてメモリに読み込み、上記のプログラムコードを実行することによりデータの編集処理を実行する。
【００３１】
図２は、前提技術２のデータ編集装置１０の機能構成を示すブロック図である。データ編集装置１０は、データ保持部１２と、コード対応関係テーブル１４と、集約規則テーブル１６と、按分規則テーブル１８と、コード取得部２０と、コード生成部２２と、編集処理部２４を備える。
【００３２】
本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、図２の各機能ブロックは、ソフトウェアとして記録媒体に格納されデータ編集装置１０のハードディスクにインストールされ、データ編集装置１０のメインメモリに適宜読み出されてＣＰＵにて実行されてもよい。
【００３３】
データ保持部１２は、編集対象となる編集前のデータと編集後のデータとを保持する記憶領域である。データ保持部１２は、編集前のデータと編集後のデータのそれぞれについて、データの値と基底とを対応づけたＣＳＶ（Comma Separated Values）ファイルを保持する。例えば、ＣＳＶファイルの一行が「値，ハットの有無，名称，単位，時間，主体」となり、空白行が元（げん）の区切りを示してもよい。なおデータ保持部１２は、データ編集装置１０とは異なる情報処理装置、例えばデータベースサーバ内に設けられてもよいことはもちろんである。この場合、ＬＡＮ・ＷＡＮ・インターネット等の通信網を介して当該データベースサーバとデータ編集装置１０が接続された情報処理システムが構築されてもよい。
【００３４】
コード対応関係テーブル１４は、データの編集内容（編集操作）を内包的記法により記述するためのプログラム言語（以下、「内包的記法言語」とも呼ぶ。）と、データの編集内容を外延的記法により記述するためのプログラム言語（以下、「外延的記法言語」）との対応関係を保持する記憶領域である。前提技術２における外延的記法言語はＪａｖａ（登録商標）言語であることとするが、Ｃ言語等、他のプログラム言語であってもよい。
【００３５】
内包的記法言語と外延的記法言語との対応関係は、例えば、内包的記法言語における編集操作を示すキーワードと、外延的記法言語におけるその編集操作を実現するためのロジックを実装したコード（関数）とを対応づけたものである。より具体的には、内包的記法言語における複数のデータから特定のデータを抽出する条件の記述は、外延的記法言語における複数のデータを逐次列挙するための繰り返し命令の記述と対応づけられる。また例えば、内包的記法言語において入力データを指定するコードと、外延的記法言語においてその入力データをメモリ内に読み込むロジックを実装したコードとを対応づけたものである。なお、対応関係の具体例は図３〜図６において後述する。
【００３６】
集約規則テーブル１６は、アグリゲーション操作時に参照されるべき複数種類の基底の集約関係を定めた集約規則を保持する記憶領域である。集約規則は、例えば上述の｛津軽，富士，紅玉｝-->{リンゴ}という集約関係を定めたものである。複数種類の基底を集約する基底（上記例ではリンゴ）を以下では「集約基底」と呼ぶこととする。按分規則テーブル１８は、按分操作時に参照される複数種類の基底の按分比率を定めた按分規則を保持する記憶領域である。按分規則は、例えば上述の｛リンゴ｝-->｛津軽，富士，紅玉｝という按分関係と、１：１：１という按分比率を定めたものである。
【００３７】
コード取得部２０は、キーボード等の所定の入力装置を介してユーザにより入力されたプログラムコード（以下、「ユーザコード」とも呼ぶ。）を取得する。このユーザコードは、内包的記法言語で記述される。具体的なユーザコード例は後述する。
【００３８】
コード生成部２２は、コード対応関係テーブル１４に保持された対応関係にしたがって、ユーザコードから、ユーザコードに記述されたデータ編集内容が外延的記法言語で記述されたプログラムコード（以下、「実行コード」とも呼ぶ。）を生成する。前提技術２における実行コードはＪａｖａバイトコードであることとする。具体的には、ユーザコードに対応するＪａｖａソースコードを生成し、そのソースコードをコンパイルすることによりＪａｖａバイトコードを生成する。具体的な実行コード例は後述する。
【００３９】
編集処理部２４は、コード生成部２２において生成された実行コードにしたがって、データ保持部１２に保持された編集対象のデータを編集する。編集処理部２４は、データ読込部２６とデータ編集部２８と編集結果出力部３０を含む。なお、実行コードが所定の実行エンジンにおいて実行されることにより、編集処理部２４（データ読込部２６〜編集結果出力部３０）の機能が実現されてもよいことはもちろんである。例えば、実行コードがＪａｖａバイトコードの場合、実行エンジンはＪＶＭ（Java Virtual Machine）となる。
【００４０】
データ読込部２６は、データ保持部１２から編集対象のデータを読み込み、そのデータから、データの値と基底とが対応づけられたデータオブジェクトをメモリ上に生成する。データ編集部２８は、データ読込部２６において生成されたデータオブジェクトに対する操作を実行して編集結果のデータを設定する。編集結果出力部３０は、データ読込部２６において設定された編集結果のデータをＣＳＶファイルとして記録し、データ保持部１２へ格納する。
【００４１】
図３は、会計型データを操作するためのユーザコードの一例を示す。以下のコード例では、左端に行番号を示しており、その行番号によりコードの位置を適宜示す。図３では、編集対象データとして、２００＜現金＞＋１００＜小麦＞という元と、２００＜現金＞＋２００＜大豆＞という元を含む集合Ｃが指定されている。ここでは説明の簡明化のため編集対象データを直接入力しているが、典型的には入力ファイルとしてのＣＳＶファイルの名称や、そのＣＳＶファイルにおける入力データの記述位置が指定されることにより入力データを示すデータオブジェクトが生成される。
【００４２】
図３の４行目では、交換代数のプロジェクション処理、すなわち指定された基底と一致する部分要素を抽出する射影操作が指定されている。具体的には、集合Ｃから基底＜現金＞もしくは＜小麦＞に該当し、かつ、値が設定済という条件を充足する元を抽出して集合ａｓｅｔへ代入する処理が指定されている。そして５行目でａｓｅｔ内の元の加算処理が指定されている。ａｓｅｔは２００＜現金＞、１００＜小麦＞、２００＜現金＞を含むため、加算結果ａｌｐｈａは４００＜現金＞＋１００＜小麦＞となる。ここでは説明の簡明化のため編集結果を標準出力へ出力することとしているが、典型的には出力ファイルとしてのＣＳＶファイルが指定されて、当該ＣＳＶファイルに編集結果（ここでは加算結果ａｌｐｈａの内容）が記録される。
【００４３】
図４（ａ）は、図３のユーザコードに対応する実行コードを示す。具体的には図３の２行目に応じてコード生成部２２が生成する実行コードであり、データ読込部２６の機能に対応する。なお、前提技術２の説明では実行コードとして便宜的にＪａｖａソースプログラムを示す。同図では、集合Ｃに対応するＥｘＡｌｇｅＳｅｔオブジェクトに、２００＜現金＞＋１００＜小麦＞という元に対応するＥｘＡｌｇｅオブジェクト（１５〜２３行目）と、２００＜現金＞＋２００＜大豆＞という元に対応するＥｘＡｌｇｅオブジェクト（２４〜３２行目）が格納されている。
【００４４】
図４（ｂ）は、図３のユーザコードに対応する実行コードを示す。具体的には図３の４行目に応じてコード生成部２２が生成する実行コードであり、データ編集部２８の機能に対応する。同図では、集合Ｃに含まれる複数の元に対応するＥｘＡｌｇｅオブジェクトを列挙するｆｏｒループと、集合Ｄに含まれる複数の基底に対応するＥｘＢａｓｅオブジェクトを列挙するｆｏｒループとの２重ループの中で、プロジェクションメソッドが呼び出され、プロジェクション処理の結果がリストへ追加される。そして、そのリストから集合ａｓｅｔが設定されている。
【００４５】
図５は、レコード型データを操作するためのユーザコードの一例を示す。同図では、山田＜ｎａｍｅ＞＋５＜ｓｃｏｒｅ＞、田中＜ｎａｍｅ＞＋３＜ｓｃｏｒｅ＞、鈴木＜ｎａｍｅ＞＋４＜ｓｃｏｒｅ＞、佐藤＜ｎａｍｅ＞＋２＜ｓｃｏｒｅ＞、本田＜ｎａｍｅ＞＋５＜ｓｃｏｒｅ＞の５つの元を含む集合ｄａｔａｓｅｔが指定されている。
【００４６】
図５の９行目では、基底＜ｓｃｏｒｅ＞に対応づけられた値が４以上の元が存在するたびに、元「１＜４以上，人，＃，＃＞」を集合ａｓｅｔへ代入する処理が指定されている。そして、１１行目でａｓｅｔ内の元の加算処理が指定されている。この結果として、ａｓｅｔには元「１＜４以上，人，＃，＃＞」が３個含まれることになり、ｒｅｔ＝３＜４以上，人，＃，＃＞となる。すなわちこの例は、ｓｃｏｒｅが４以上の人数を集計するものとなる。
【００４７】
図６（ａ）は、図５のユーザコードに対応する実行コードを示す。具体的には図５の２〜７行目に応じてコード生成部２２が生成する実行コードであり、データ読込部２６の機能に対応する。同図では、集合ｄａｔａｓｅｔに対応するＤｔＡｌｇｅＳｅｔオブジェクトに、上記５つのレコード型データの元のそれぞれに対応するＤｔａｌｇｅオブジェクトが格納される。レコード型データは値と基底の両方で様々なデータ型を許容するため、値と基底のそれぞれのデータ型を示す情報もＤｔａｌｇｅオブジェクトに設定される。
【００４８】
図６（ｂ）は、図５のユーザコードに対応する実行コードを示す。具体的には図５の９行目に応じてコード生成部２２が生成する実行コードであり、データ編集部２８の機能に対応する。同図では、集合ｄａｔａｓｅｔに含まれる複数の元に対応するＤｔＡｌｇｅＳｅｔオブジェクトを列挙するｆｏｒループの中で、基底＜ｓｃｏｒｅ＞に対応する値が４以上の場合に、元「１＜４以上，人，＃，＃＞」がリストへ追加される。そして、そのリストから集合ａｓｅｔが設定されている。
【００４９】
なおユーザコードにアグリゲーション命令（関数）が設定された場合、コード生成部２２は、集約規則テーブル１６に保持された集約規則を参照して、まず簿記の記載に対応するオブジェクト（以下、「中間オブジェクト」とも呼ぶ。）を設定する実行コードを生成する。具体的には、集約対象の複数のデータの集計値を算出し、その集計値と集約基底とを対応づけたデータと、集約対象の複数のデータそれぞれの値を差し引くことを示すデータ（すなわち集約対象の複数のオリジナルデータにハット属性を付加したデータ）とを加算する元を示すオブジェクトを、中間オブジェクトとして設定する実行コードを生成する。この中間オブジェクトは、前提技術１のアグリゲーションで示したＦ（ｘ）に対応する。
【００５０】
そしてコード生成部２２は、集約対象の複数のオリジナルデータが加算される元を示すオブジェクトと中間オブジェクトとを加算する、言い換えれば、集約対象の複数のオリジナルデータとそれらのデータにハット属性を付加したデータとを相殺することにより、集約対象の複数のデータの集計値と集約基底とを対応づけたデータを、集計結果のオブジェクトへ格納する実行コードを生成する。この実行コードは、前提技術１のアグリゲーションで示した〜（ｘ＋Ｆ（ｘ））に対応するコードである。なおコード生成部２２は、中間オブジェクトの内容を所定のファイルへ出力する実行コードをさらに生成してもよい。この態様によると、中間オブジェクトの内容をユーザへ提示することにより、効率的なデバッグを支援するとともに、簿記の振替計算に利用可能な情報をユーザへ提供できる。
【００５１】
またユーザコードに按分命令（関数）が設定された場合、コード生成部２２は、按分規則テーブル１８に保持された集約規則を参照して、アグリゲーション時と同様にまず中間オブジェクトを設定する実行コードを生成する。具体的には、按分対象のデータの値を按分比率にしたがって按分し、按分した値と按分先の各基底とを対応づけたデータと、按分対象のオリジナルデータにハット属性を付加したデータとを加算する元を示すオブジェクトを、中間オブジェクトとして設定する実行コードを生成する。この中間オブジェクトは、前提技術１の按分で示したＦ（ｘ）に対応する。
【００５２】
そしてコード生成部２２は、按分対象のオリジナルデータの元を示すオブジェクトと中間オブジェクトとを加算する、言い換えれば、按分対象のオリジナルデータとそのデータにハット属性を付加したデータとを相殺することにより、按分した値と按分先の各基底とを対応づけたデータを、按分結果のオブジェクトへ格納する実行コードを生成する。この実行コードは、前提技術１の按分で示した〜（ｘ＋Ｆ（ｘ））に対応するコードである。なおコード生成部２２は、アグリゲーションと同様に、中間オブジェクトの内容を所定のファイルへ出力する実行コードをさらに生成してもよい。
【００５３】
以上の構成による動作を以下説明する。
図７は、データ編集装置１０の動作を示すフローチャートである。まずユーザは、内包的記法言語を用いてデータの編集内容を内包的記法により記述し、そのプログラムコードを指定したデータの編集指示をデータ編集装置１０へ入力する。データ編集装置１０が所定の入力装置を介してデータの編集指示を受け付けた場合（Ｓ１０のＹ）、データ編集装置１０のコード取得部２０は、ユーザにより入力されたプログラムコードをユーザコードとして取得する（Ｓ１２）。コード生成部２２は、コード対応関係テーブル１４に保持されたユーザコードと実行コード間の対応関係にしたがって、ユーザコードから実行コードの生成処理を開始する（Ｓ１４）。
【００５４】
ユーザコードにアグリゲーション命令や按分命令等の振替え命令が存在する場合（Ｓ１６のＹ）、コード生成部２２はその振替え命令に応じた相殺処理のための中間オブジェクトの出力命令を実行コードへ設定する（Ｓ１８）。ユーザコードに振替え命令がなければ（Ｓ１６のＮ）、Ｓ１８をスキップする。編集処理部２４は、生成された実行コードにしたがって編集対象データに対する編集処理を実行する（Ｓ２０）。例えば、データ読込部２６は、データ保持部１２の入力データ格納用のＣＳＶファイルから、ユーザコードおよびユーザコードから生成された実行コードにおいて指定された編集対象のデータを読み込みデータオブジェクトを生成する。そしてデータ編集部２８は、生成されたデータオブジェクトに対して実行コードにて指定された編集操作（基底に基づく射影操作・アグリゲーション操作・按分操作等）を実行し、編集結果を示すデータオブジェクトを生成する。編集結果出力部３０は、編集処理部２４による編集結果、例えばデータ編集部２８により生成された編集結果を示すデータオブジェクトの内容（属性値等）を、データ保持部１２の編集結果格納用のＣＳＶファイルへ出力する（Ｓ２２）。データ編集装置１０がデータの編集指示を受け付けなければ（Ｓ１０のＮ）、Ｓ１２以降はスキップされる。
【００５５】
前提技術２のデータ編集装置１０によれば、従来ＲＤＢで扱われていたデータを、会計型データに対応するデータオブジェクト、もしくは、レコード型データに対応するデータオブジェクトとして表現することができる。これにより、コンピュータ上におけるデータオブジェクト表現の標準化を支援することができる。また、編集対象のデータの蓄積においてＲＤＢのような複雑な仕組みを必要とせず、可視性の高いＣＳＶファイルで蓄積することができる。
【００５６】
またデータ編集装置１０によれば、ユーザはデータの編集内容を内包的記法言語で記述できるため、データの編集内容を正しく理解しているユーザであれば、実際にコンピュータを動作させるための外延的記法言語について理解していなくても、正しいデータ編集を実現させることができる。またデータ編集装置１０では編集対象のデータが値と基底との組み合わせとして保持されるため、ユーザは内包的記法を用いることで、規定に基づく編集内容を容易に記述することができる。また内包的記法はコンピュータに依存せず、データ編集の仕様を反映するものであるため、ユーザは正しい仕様記述を行えば、正しいデータ編集を実現させることができる。例えば、ｆｏｒループ等を意識せずに、ユーザはデータの編集内容を仕様通りに記載すればよい。したがって、ユーザコードへのバグの混入を低減させることができ、言い換えれば、バグの発生箇所をデータそのもののバグに限定させやすくなる。例えば、会計型データの操作においては、アグリゲーションや按分等、様々な振替処理をロバストに記述することができる。
【００５７】
またデータ編集装置１０によれば、データの基底に基づいて値の編集処理が行われることにより、データの形式（スキーマ）に変更があった場合でも、その影響範囲を限定することができる。例えば、編集対象のデータを格納したテーブルにおいてカラムの入れ替えが発生しても、ユーザコードにおける編集ロジックへの影響を排除することができる。
【００５８】
またデータ編集装置１０によれば、アグリゲーションや按分等の振替処理の規則がプログラムコード外のテーブルに保持されるため、規則に変更が生じてもテーブルのデータを変更すればよく、プログラムコードへの影響を排除できる。
【００５９】
変形例として、データ編集装置１０は振替規則テーブルをさらに備えてもよい。振替規則テーブルは、振替操作（ここではアグリゲーションや按分を伴わない基底の変換操作であることとする）において参照されるべき振替規則を保持する記憶領域である。振替規則は、振替元の基底と振替先の基底とを対応づけたデータである。コード生成部２２は、ユーザコードに振替命令が設定された場合、振替規則テーブルに保持された振替規則を参照して、中間オブジェクトＦ（ｘ）を設定する実行コードを生成する。例えば、ｘ＝数値Ａ＜振替元の基底＞の場合、Ｆ（ｘ）＝数値Ａ＾＜振替元の基底＞＋数値Ａ＜振替先の基底＞となる。そしてコード生成部２２は、〜（ｘ＋Ｆ（ｘ））に対応した実行コードを生成する。当該コードの実行結果として、上記の例では、数値Ａ＜振替元の基底＞が、数値Ａ＜振替先の基底＞に変換されることになる。
【００６０】
（実施の形態）
実施の形態では、実物簿記記述を用いて多主体間での多段階資源配分を管理する技術を提案する。この実物簿記記述は、前提技術１および前提技術２で説明した交換代数を適用したものである。第１の実施の形態（以下「第１実施形態」とも呼ぶ。）では、複数の主体間で、プラスの価値を有する財やサービスが金銭の移動を伴わずに融通される場合の管理技術を説明する。第２の実施の形態（以下「第２実施形態」とも呼ぶ。）では、複数の主体間で、マイナスの価値を有する財やサービス（以下「環境負荷財」とも呼ぶ。）が金銭の移動を伴わずに移転される場合の管理技術を説明する。第３の実施の形態（以下「第３実施形態」とも呼ぶ。）では、実物簿記記述を企業の一般的な状態記述に適用する例を示す。第４の実施の形態（以下「第４実施形態」とも呼ぶ。）では、財やサービスの移転、または、環境負荷財の移転を管理する装置に接続される情報端末の特徴を説明する。
【００６１】
財とサービスはどちらも人間の欲求を満足させるモノと言えるが、典型的には財は物理的な実体のある有形物や資源であり、サービスは物理的な実体のない無形物である。以下、両者を特に区別しない場合、財とサービスを総称して「財」と呼ぶ。融通は、取引、提供、移転、移管、貸与とも言える。融通は金銭的な取引を含んでもよいが、実施の形態では金銭の移動を伴わない財の融通や環境負荷財の移転にフォーカスする。なお、各実施形態において融通や移転の対象になる財やサービスに制限はないが、好適な対象として様々な種類のエネルギー（「エネルギー等」とも呼ぶ。）が考えられる。エネルギー等は、電気、ガス、温熱、環境負荷財、使用済み天ぷら油、バイオ燃料用のゴミ、アルコール、メタンガス、バイオチップ、熱排水、地熱温水、金属屑等を含む。
【００６２】
（第１実施形態の概要説明）
第１実施形態では、多主体が複数回に亘り財を相互融通する段階と、最終的にその貸借を清算する段階を含む多段階の資源配分を適切に管理する装置を提案する。この装置は、財が融通された状態の記録処理と、その記録に基づいて融通結果の評価処理を実行する。
【００６３】
第１実施形態で提案するシステムでは、初期段階では融通対象となる財の価格評価を実施しない。そして、財の融通を多段階に亘って実施し、最終段階でそれまで実施した融通の結果を清算する。これを可能にするために、第１実施形態の装置（後述の融通管理装置１０４）は、財が融通された事実を、実物記述を許す複式簿記の拡張された形式で記録し、最終的に融通の結果を価格評価する。
【００６４】
多段階交換では、第一段階では物量レベルで財を計測し、この物量レベルの計測結果に基づき、多主体からなるコミュニティの目的を充足するための交換（融通・貸与や移管替え等）を行う。現金（価値）計測された形での支払いや負債、債権の記述は最後の段階まで実行しない。融通の事実は、融通対象の財の計量単位（財の固有の単位とも言え、物量単位とも言える）に基づいた実物簿記的な記述により記録される。この実物簿記記述は、交換代数によって可能となる。
【００６５】
特に従来なかった記述方法として、債権と債務の実物表示、言い換えれば、債権と債務の実物簿記記述がある。例えば、主体Ｂが主体Ｃから味噌を３Ｋｇ融通してもらった場合に、そこに生じるＣに対するＢの債務を「３＜味噌＿債務＿Ｃ、Ｋｇ、＃、Ｂ＞」と表現する。また同時に生じるＢに対するＣの債権を「３＜味噌＿債権＿Ｂ、Ｋｇ、＃、Ｃ＞」と表現する。交換に伴う債権と債務は、通常現金評価で記載される。第１実施形態では債権債務関係（貸借関係とも言える）を実物財ベースで評価することで、最終段階まで財の現金評価をせずに、多段階の融通や取引を迅速かつ手軽に進めることができる。
【００６６】
多段階（複数回数）の融通の後、最終段階では、物量単位で示される融通結果としての債権と債務に対して、事後的な価格評価を実行する。または、融通された財同士での相殺取引（ネッティング）を実行する。結果として、金銭評価に基づく債権と債務の支払いや、取引同士の相殺により、取引を清算する。
【００６７】
第１実施形態で提案する多段階交換は、単に支払いを事後にする金銭的なツケとしての交換ではない。ツケでの販売という交換が行われる場合は、当初から財の価格、すなわち金銭的価値は定まっており、支払いだけが事後的になされる。しかし、第１実施形態で提案する多段階交換は、債権と債務が物量ベースで記述され保持されることで、その時点で金銭価値評価がなされていなくても融通（交換）が可能になる。それゆえ極端なケースとしては、一般交換の様に、貸与はコミュニティの中で継続的に連鎖し、長期的には相殺されるという前提で、最終段階での清算を行わないというパターンも想定される。
【００６８】
第１実施形態では、財の融通を実物記述のレベルで記録することで、多段階の財の貸与・融通・移管替えなどによる主体間の融通プロセスを、システムとして設計し、管理することを可能にする。
【００６９】
いわゆる「市場」という仕組みは近代の資本主義の発明品であり、事前に価格評価を行って交換を行うことで、面識のない多数の人々の間での財の交換を可能とし、結果的に需給が均衡するとされる。しかし歴史的には、また現在でも、金銭の移動を伴わずに、必要なものを必要な所に融通することは、互いに面識のある人々で構成されるコミュニティ内での取引として重要である。これは、財の貸与や移管を必要とする際に、その財やサービスに価格付けができる条件が整っていないことが多いからである。あるいは、事後的に様々な条件を踏まえ、貸借関係を評価することが適当なケースが多々あるからである。
【００７０】
米や味噌等を互いに融通するコミュニティでは、典型的には、それらの財の価格を基準に融通が実施されるのではなく、それらの財が余っている主体からそれらの財を必要とする主体へ金銭の移動を伴わずに融通が実施される。しかし、そのような融通において特定の主体だけが有利になるのでは継続性、持続性がなく、どこかの段階では清算が必要になる。また清算は必ずしも金銭によるものだけではない。従来小さなコミュニティ内でなされていた、余裕のある主体から不足する主体への財の融通を、現代的な組織やコミュニティ等のメンバーシップのある関係の中で可能とすることが第１実施形態の効果となる。
【００７１】
市場的意思決定では、最初から、財の評価がシンプルな１段階での需要と供給の均衡というモデルが用いられる。その一方、実際の組織やコミュニティにおける、余裕のある主体から不足する主体へ財を融通する際の意思決定では、需要と供給のマッチングには複雑な制約条件が存在することが多く、その均衡点も一つではない。さらに、事前に価格等の形で財の価値を決定し、財の相互融通等の調整を同時に実施することはなじまないケースが多々ある。
【００７２】
他方で、従来のコミュニティ等での多段階交換にはその管理に限界があった。例えば、それぞれの段階で行われる融通を複式簿記的に記録する発想が事実上存在しなかった。それゆえ融通の多段階交換は、小さなコミュニティの中や、長期的に貸し借りが相殺されるようなコミュニティ等、極めて限定的な状況でしか実行できなかった。第１実施形態では、融通の多段階交換に対して交換代数を用いた実物簿記の枠組みを導入することで、融通を実物ベースの複式記述で記録し、融通の連鎖と最終段階での清算という多段階交換の仕組みをより広い社会システムデザインに適用することを可能とする。
【００７３】
（第１実施形態の詳細説明）
コミュニティ内での融通を交換代数を用いて記述する例を示す。ここでは、米、味噌、醤油を相互に融通するコミュニティを考える。
（１−１）取引主体の設定
取引主体：Ａ、Ｂ、Ｃの３主体
取引主体が所有する財：米（単位Ｋｇ）、醤油（単位Ｌ（リットル））、味噌（単位Ｋｇ）
初期状態：Ａは米を５０Ｋｇ所有し、Ｂは醤油を１０Ｌ所有し、Ｃは味噌を２０Ｋｇ所有する。
【００７４】
（１−２）勘定科目の基底
交換代数の４項基底、具体的には＜科目の名称、測定単位（財の計量単位）、日付、主体名等＞を用いる。今回は第３項の日付は使用しない（「＃」と表現する）。変形例として、第３項に、多段階取引における段階を示す情報を設定してもよい。第４項の主体名等には、財を最初に所有した主体名を設定する。例えば初期ストックにおける所有主体を設定する。なお、実施の形態の説明における「情報」は「データ」と同じ意味であり、相互に読み替えることもできる。
【００７５】
例えば財に関する基底は、＜米、Ｋｇ、＃、Ａ＞、＜醤油、Ｌ、＃、Ｂ＞、＜味噌、Ｋｇ、＃、Ｃ＞となる。
また資本に関する基底は、＜米＿資本、Ｋｇ、＃、Ａ＞、＜醤油_資本、Ｌ、＃、Ｂ＞、＜味噌＿資本、Ｋｇ、＃、Ｃ＞となる。資本の基底は、期首における財の保有を資本と見なすために導入する。例えば主体Ａの期首の財は、５０＜米、Ｋｇ、＃、Ａ＞＋５０＜米＿資本、Ｋｇ、＃、Ａ＞と表現できる。
【００７６】
また債権と債務に関する基底も導入する。第１実施形態では、融通時には、その融通の結果を、金銭債権および金銭債務として表現するのではなく、実物債権および実物債務として表現する。
例えば、味噌４ＫｇをＣからＡに融通した場合、
４＾＜味噌、Ｋｇ、＃、Ｃ＞＋４＜味噌＿債権＿Ａ、Ｋｇ、＃、Ｃ＞  ・・・（式１）
という取引記述を融通元の主体Ｃに対応付けて記録する。
【００７７】
式１の第１項は、Ｃが保有していた味噌が４Ｋｇ減少したことを示し、式１の第２項は、Ａに対する味噌４Ｋｇの債権をＣが保有することを示す。すなわち、第２項の基底のうち「味噌＿債権＿Ａ」は、味噌の債権であり、債権の相手先、すなわち債務者がＡであることを示している。また第２項の基底の４つ目「Ｃ」は債権の保有者、すなわち債権者がＣであることを示している。式１は債権情報とも言え、第１実施形態では債権情報を複式で記録する。すなわち、式１の第１項は、当初Ｃが保有していた味噌が融通により減少した事実を示し、第２項はその事実により生じた味噌債権を示している。
【００７８】
また、第１実施形態では式１の債権情報が記録されるとともに、
４＜味噌、Ｋｇ、＃、Ｃ＞＋４＜味噌＿債務＿Ｃ、Ｋｇ、＃、Ａ＞  ・・・（式２）
という債務情報を融通先の主体Ａに対応付けて記録する。
【００７９】
式２の第１項は、Ｃが保有していた味噌が４Ｋｇ増加したことを示し、式２の第２項は、Ｃに対する味噌４Ｋｇの債務をＡが保有することを示す。すなわち、第２項の基底の「味噌＿債務＿Ｃ」は、味噌の債務であり、債務の相手先、すなわち債権者はＣであることを示している。また第２項の基底の４つ目「Ａ」は債務の保有者、すなわち債務者がＡであることを示している。第１実施形態では債務情報を複式で記録する。すなわち、式２の第１項は、当初Ｃが保有していた味噌が融通により増加した事実を示し、第２項はその事実により生じた味噌債務を示している。
【００８０】
このように、コミュニティ内で財やサービスが融通された場合、融通元主体に対応付けて実物ベースの債権を記録するとともに、融通先主体に対応付けて実物ベースの債務を記録する。第１実施形態ではさらに、現金、利益、コスト等の一般基底も導入する。例えば現金については通常主体を設定せず、＜現金、円、＃、＃＞という基底になる。
【００８１】
図８は、第１実施形態の融通管理システムの構成を示す。融通管理システム１００は、あるコミュニティ内での財の融通状態を管理するための情報処理システムである。コミュニティは、共同体、組合、団体とも言え、典型的には互いのことを知っている複数の主体の集合である。また、他者に対する財・サービス・金銭の提供が可能な複数の主体の集合である。コミュニティは、例えば、特定の地域の住民を主体として構成されてもよく、財やサービス（例えばエネルギー等の資源）を融通しあう個人や企業を主体として構成されてもよい。
【００８２】
融通管理システム１００は、情報端末１０２と融通管理装置１０４を備える。これらの装置は、ＬＡＮやＷＡＮ、インターネット等の公知の通信網を介して接続される。融通管理装置１０４は、コミュニティに属する主体（「メンバー」とも言える）間で財が融通された場合に、その事実を記録し、所定のタイミングでの清算を支援する情報処理装置である。以下、１つのコミュニティにおける融通状態を管理する例を説明するが、融通管理装置１０４は、複数のコミュニティに対して、各コミュニティ内での融通の状態を管理するサービスを提供してもよいことはもちろんである。
【００８３】
情報端末１０２は、コミュニティの各メンバーや融通取引の管理者等により操作される情報処理装置である。例えばＰＣ、スマートフォン、タブレット端末であってもよい。図１では情報端末１０２を１つ示しているが、融通管理システム１００は、コミュニティの複数のメンバーが操作する複数の情報端末１０２を備えてもよく、また、異なる複数のコミュニティのメンバーが操作する複数の情報端末１０２を備えてもよい。
【００８４】
情報端末１０２は、融通管理装置１０４への入力データとなるストック情報２００、融通実績情報２０２、価格情報２０４、支払情報２０６を記憶し、これらのデータをユーザの操作に応じて融通管理装置１０４へ送信する。これらのデータの形式に制限はなく、後述の情報項目を含む自然文のデータであってもよく、表形式のデータであってもよい。
【００８５】
ストック情報２００は、コミュニティ内の各主体の財の所有状況に関する情報である。例えば、財の融通の評価がなされる単位期間の期首、言い換えれば、財の融通がなされる前の初期段階において各主体が保持する財の量を示す情報である。融通実績情報２０２は、コミュニティにおける財の融通の実績（事実）を示す情報である。融通実績情報２０２は、融通元の主体、融通先の主体、融通された財、融通された量を示す情報を含む。例えば「主体Ｃから主体Ｂへ味噌を３Ｋｇ融通した」という内容であってもよい。
【００８６】
価格情報２０４は、主体間で融通がなされた財の価格に関する情報である。例えば、融通対象財の所定の単位量当りの価格、言わば単価であってもよい。有形物の財の場合、単位量は１Ｋｇや１Ｌ等であってもよく、無形物のサービスの場合、単位量は１回や１日等であってもよい。支払情報２０６は、主体間でなされた金銭の支払に関する情報である。支払情報２０６は、支払元の主体、支払先の主体、現金での支払であること、支払額のそれぞれを示す情報を含む。例えば「主体Ｂから主体Ｃへ６０００円支払った」という内容であってもよい。
【００８７】
また情報端末１０２は、ユーザの操作に応じて、融通管理装置１０４により生成された評価情報２０８を取得してユーザへ提示する。例えば、融通管理装置１０４から評価情報２０８をダウンロードしてディスプレイに表示させ、またプリンタに印刷させる。評価情報２０８は、コミュニティ内でなされた融通の清算を支援するための情報であり、融通清算支援情報とも言える。例えば評価情報２０８は、コミュニティ内での１回以上の融通結果を集計した情報を含み、例えば後述の残高情報（価格振替後残高等）を含む。
【００８８】
図８は、第１実施形態の融通管理装置１０４の機能構成をブロック図の形式で示している。融通管理装置１０４は、制御部１１０、記憶部１１２、通信部１１４を備える。制御部１１０は、各種データ処理を実行する。記憶部１１２は、制御部１１０により参照され、また更新されるデータを記憶する記憶領域である。通信部１１４は、各種の通信プロトコルにしたがって外部装置と通信する。制御部１１０は、通信部１１４を介して、情報端末１０２とデータを送受する。
【００８９】
記憶部１１２は、対応関係保持部１２０、ストック情報保持部１２２、債権債務情報保持部１２４、価格保持部１２６、評価情報保持部１２８を含む。以下、会計型データに言及するが、前提技術で既述したように、会計型データは、データの値と、データの属性を示す基底とを組み合わせたものである。会計型データは、人間的に自然な文章を、コンピュータによる情報処理が可能なように、会計的な意味を持つ代数的データオブジェクトとしてコード化（エンコード）したものである。
【００９０】
ストック情報保持部１２２は、ストック情報２００に対応する会計型データを保持する。例えば、コミュニティ内の各主体の財の保有状況を示す会計型データを保持する。債権債務情報保持部１２４は、上記の式１で示したような債権を示す会計型データ（以下「債権情報」と呼ぶ。）と、上記の式２で示したような債務を示す会計型データ（以下「債務情報」と呼ぶ。）を保持する。価格保持部１２６は価格情報２０４のデータを保持する。価格保持部１２６が保持するデータは、融通対象財の時価であってもよく、また、評価処理の都度、最新の価格情報に更新されてもよい。
【００９１】
評価情報保持部１２８は、後述の評価部１３８により生成された評価情報を保持する。この評価情報は、コミュニティ内での１回以上の融通結果を集計した情報を含み、例えば後述の残高情報（価格振替後残高等）を含む。評価情報保持部１２８は、少なくとも評価情報を示す会計型データを保持するが、評価情報を変形した会計情報、例えばバランスシート等の財務諸表の形式に加工されたデータをさらに保持してもよい。
【００９２】
対応関係保持部１２０は、情報端末１０２から入力される非会計型データと、融通管理装置１０４で処理対象となる会計型データとの対応関係を示す情報（以下「対応関係データ」と呼ぶ。）を保持する。対応関係データは、情報端末１０２から入力される非会計型データから、記憶部１１２に記憶される会計型データを生成するための規則とも言える。
【００９３】
例えば対応関係保持部１２０は、情報端末１０２から入力されるストック情報２００を、債権債務情報保持部１２４に記憶される会計型データの形式へ変換するための対応関係データを保持する。この対応関係データは、主体名称、財名称、ストック量（単位含む）を示すストック情報２００を、「ストック量＜財名称、単位、＃、主体名称＞」の形式へ変換することを定めた規則であってもよい。
【００９４】
また対応関係保持部１２０は、情報端末１０２から入力される融通実績情報２０２を、債権債務情報保持部１２４に保持される会計型データの形式へ変換するための対応関係データを保持する。この対応関係データは、融通実績情報２０２から債権情報と債務情報を生成する規則と言える。
【００９５】
具体的には対応関係データは、融通元主体、融通先主体、融通対象財、融通量（単位含む）を示す融通実績情報２０２を、融通元主体の債権情報として、「融通量＾＜融通対象財、単位、＃、融通元主体＞＋融通量＜融通対象財＿債権＿融通先主体、単位、＃、融通元主体＞」の形式へ変換することを定めた規則であってもよい。さらに同じ融通実績情報２０２を、融通先主体の債務情報として、「融通量＜融通対象財、単位、＃、融通元主体＞＋融通量＜融通対象財＿債務＿融通元主体、単位、＃、融通先主体＞」の形式へ変換することを定めた規則であってもよい。
【００９６】
さらにまた対応関係保持部１２０は、情報端末１０２から入力される支払情報２０６を、評価部１３８へ入力すべき会計型データの形式へ変換するための対応関係データを保持する。この対応関係データは、支払元主体、支払先主体、現金、支払額（単位含む）を示す支払情報２０６を、支払先主体の債権回収情報として、「支払額＾＜債権＿支払元主体、円、＃、支払先主体＞＋支払額＜現金、円、＃、＃＞」の形式へ変換することを定めた規則であってもよい。
【００９７】
制御部１１０は、ストック情報取得部１３０、融通実績取得部１３２、債権債務記録部１３４、価格情報取得部１３６、評価部１３８、評価情報提供部１４０、支払情報取得部１４２を含む。これらの機能ブロックに対応する複数のモジュールを含むコンピュータプログラムがＤＶＤ等の記録媒体に格納されて、融通管理装置１０４のストレージへインストールされてもよい。そして融通管理装置１０４のプロセッサ（ＣＰＵ等）が各モジュールをメインメモリへ読み出して実行することにより、制御部１１０の各機能ブロックの機能が発揮されてもよい。
【００９８】
ストック情報取得部１３０は、情報端末１０２から送信されたコミュニティの各メンバー（言い換えれば融通を行う各主体）のストック情報２００を取得する。ストック情報取得部１３０は、対応関係保持部１２０の対応関係データにしたがって、取得したストック情報２００を会計型データへ変換し、変換後の会計型データを各主体に対応付けてストック情報保持部１２２へ格納する。融通実績取得部１３２は、情報端末１０２から送信された融通実績情報２０２を取得して債権債務記録部１３４に渡す。
【００９９】
債権債務記録部１３４は、コミュニティ内で第１の主体から第２の主体へ金銭の移動を伴わずに財が融通された場合に、融通量に応じた債権の大きさを財の計量単位で示す債権情報を生成し、その債権情報を第１の主体に対応付けて債権債務情報保持部１２４へ格納する。それとともに債権債務記録部１３４は、融通量に応じた債務の大きさを財の計量単位で示す債務情報を生成し、その債務情報を第２の主体に対応付けて債権債務情報保持部１２４へ格納する。この融通量は、主体間での財の移動量と言え、第１の主体における財の減少量、第２の主体における財の増加量とも言える。
【０１００】
債権情報と債務情報を生成する際に、債権債務記録部１３４は、債権情報と債務情報のそれぞれに相手先を示す情報を設定する。具体的には債権情報には債務者を示す情報を設定し、債務情報には債権者を示す情報を設定する。また債権債務記録部１３４は、債権と債務の大きさを示す値として、金銭単位の値ではなく、融通された財の計量単位に基づく値を設定する。すなわち債権債務記録部１３４により債権債務情報保持部１２４に記録される債権情報および債務情報は、融通対象財の金銭的価値を示す情報を含まない。
【０１０１】
債権債務記録部１３４は、対応関係保持部１２０の対応関係データにしたがって、１つの融通実績情報２０２から、会計型データである債権情報と債務情報の両方を生成して債権債務情報保持部１２４へ記録する。
【０１０２】
価格情報取得部１３６は、情報端末１０２から送信された融通対象となる複数の財それぞれの価格情報２０４を取得する。価格情報取得部１３６は、各財の価格を示すデータを価格保持部１２６へ格納する。
【０１０３】
評価部１３８は、所定の評価タイミングに至った場合に、債権債務情報保持部１２４に格納された債権情報と債務情報のうち特定の１つの主体（以下「評価対象主体」と呼ぶ。）に対応付けられた債権情報と債務情報の少なくとも一方を集計した残高情報を生成する。この残高情報は、評価対象主体に対応付けられた債権情報が示す債権と債務情報が示す債務との相殺結果を含んでもよい。
【０１０４】
すなわち評価部１３８は、評価対象主体に対応付けられた複数の債権情報を基底に基づいて集計し、同様に、評価対象主体に対応付けられた複数の債務情報を基底に基づいて集計することにより残高情報を生成する。また評価部１３８は、評価対象主体に対応付けられた債権情報と債務情報の両方が存在する場合、それらの債権情報と債務情報を基底に基づいて相殺し、その相殺結果を含む残高情報を生成する。評価部１３８は、生成した残高情報のデータを評価対象主体と対応付けて評価情報保持部１２８へ格納する。
【０１０５】
評価部１３８は、評価処理の開始を要求するデータを情報端末１０２から受け付けた場合や、融通管理装置１０４の管理者により評価処理の開始を指示する操作が入力された場合に、評価タイミングに至ったと判定してもよい。また、予め定められた日時、例えば予め定められた評価期間の期末に到達したことを検出した場合に、評価タイミングに至ったと判定してもよい。
【０１０６】
評価部１３８は、同じ相手先を示す債権情報と債務情報とを相殺する。具体的には、評価対象主体に対応付けられた債権情報の基底が示す債務者と、その評価対象主体に対応付けられた債務情報の基底が示す債権者が同一の場合に、当該債権情報が示す債権額と当該債務情報が示す債務額とを相殺する。
【０１０７】
第１実施形態の評価部１３８は、事後的価格評価による評価処理（清算処理とも言える）を実行する。具体的には、評価部１３８は、価格保持部１２６に格納された融通対象財の価格に基づいて、評価対象主体の債権情報が含む債権の大きさを示す値を、融通対象財の計量単位の値から金銭単位の値へ変換する。同様に、評価対象主体の債務情報が含む債務の大きさを示す値を、融通対象財の計量単位の値から金銭単位の値へ変換する。評価部１３８は、変換後の債権情報が示す債権額と債務情報が示す債務額とを相殺する。
【０１０８】
評価情報提供部１４０は、評価情報２０８の提供要求データを情報端末１０２から受け付けた場合に、評価情報保持部１２８に格納された評価情報を情報端末１０２へ送信する。提供要求データにおいて主体の識別情報が指定されてもよく、評価情報提供部１４０は、指定された主体に対応付けられた評価情報を情報端末１０２へ送信してもよい。評価情報提供部１４０は、評価期間の期末等、予め定められたタイミングで、１つのコミュニティに属する全主体の評価情報を情報端末１０２へ自動で送信してもよい。
【０１０９】
支払情報取得部１４２は、情報端末１０２から送信された主体間でなされた金銭支払の事実を示す支払情報２０６を取得する。支払情報取得部１４２は、対応関係保持部１２０の対応関係データにしたがって、取得した支払情報２０６を会計型データへ変換する。そして、変換後の会計型データを、支払先主体の債権回収情報として評価部１３８に渡す。
【０１１０】
評価部１３８は、支払先主体の評価情報（例えば残高情報）が示す債権額と、債権回収情報が示す債権回収額とを相殺して評価情報を更新する。評価部１３８は、更新後の評価情報、例えば後述の債権債務回収後残高のデータを支払先主体に対応付けて評価情報保持部１２８へ格納する。なお債権情報、債務情報と同様に、債権回収情報も一旦記憶部１１２へ格納されてよい。そして評価タイミングに至った際に、評価部１３８が債権回収情報を読み出して評価情報に反映させてもよい。
【０１１１】
非会計型データから会計型データへの変換は融通管理装置１０４が実行することとしたが、情報端末１０２にインストールされたアプリケーションにより実行されてもよい。この場合、融通管理装置１０４に代わり情報端末１０２が、上記アプリケーションの導入に伴って対応関係保持部１２０を備えてもよい。
【０１１２】
以上の構成による融通管理システム１００の動作を説明する。
図９は、融通管理装置１０４の動作を説明するフローチャートである。ここでは各主体の初期ストックは融通管理装置１０４に予め設定されていることとする。融通管理装置１０４は、融通管理アプリケーションが終了された場合等、所定の終了条件が充足するまでの間、図９に示す処理を繰り返し実行する。
【０１１３】
情報端末１０２からアップロードされた融通実績情報２０２を融通実績取得部１３２が受け付けると（Ｓ１０のＹ）、債権債務記録部１３４は、融通元主体に生じた債権を示す債権情報と、融通先主体に生じた債務を示す債務情報の両方を記録する（Ｓ１２）。融通実績取得部１３２が融通実績情報２０２を未取得であれば（Ｓ１０のＮ）、Ｓ１２をスキップする。既述したように図９に示す処理は繰り返し実行される。そのため、１つの評価期間においてコミュニティでの融通がなされる都度、各融通に対応する融通実績情報２０２がアップロードされ、各融通に対応する債権情報と債務情報のペアが債権債務情報保持部１２４に蓄積されていく。
【０１１４】
情報端末１０２からアップロードされた価格情報２０４を価格情報取得部１３６が受け付けると（Ｓ１４のＹ）、価格情報取得部１３６は、その価格情報２０４が示す各財の価格を価格保持部１２６へ記録する（Ｓ１６）。価格情報２０４が示す財の価格が価格保持部１２６に記録済の場合、価格情報取得部１３６は、記録済の価格を価格情報２０４が示す最新の価格へ更新する。価格情報取得部１３６が支払情報２０６を未取得であれば（Ｓ１４のＮ）、Ｓ１６をスキップする。
【０１１５】
予め定められた評価タイミングに至った場合（Ｓ１８のＹ）、評価部１３８は、１つの評価期間内に蓄積された複数の債権情報および債務情報にしたがって、コミュニティに属する各主体に関する評価情報を生成し、記録する（Ｓ２０）。後述するように、各主体に対応付けて複数種類の評価情報を記録する。評価タイミングに至らなければ（Ｓ１８のＮ）、Ｓ２０をスキップする。なお、情報端末１０２から支払情報２０６が受け付けられた場合、評価部１３８は、支払情報２０６が示す債権回収額を相殺するように評価情報を更新する。
【０１１６】
情報端末１０２から特定の主体に関する評価情報の提供要求を受け付けると（Ｓ２２のＹ）、評価情報提供部１４０は、評価情報保持部１２８に格納された特定の主体に関する評価情報のデータを情報端末１０２へ送信する（Ｓ２４）。評価情報の提供要求を受け付けなければ（Ｓ２２のＮ）、Ｓ２４をスキップする。
【０１１７】
次に、あるコミュニティにおける財の融通の事例を示しつつ、その融通を管理する融通管理装置１０４の動作を説明する。以下の説明では、情報端末１０２をコミュニティのメンバーが操作することとする。このメンバーは、コミュニティ内での融通の事実を把握する管理者であってもよく、互いに財を融通する融通元主体と融通先主体のいずれかであってもよい。また、以下では１つの情報端末１０２がストック情報２００、融通実績情報２０２等の情報を融通管理装置１０４へアップロードすることとするが、複数の情報端末１０２がこれらの情報を分散して保持し、アップロードしてもよい。
【０１１８】
コミュニティのメンバーは、ストック情報２００を融通管理装置１０４へアップロードする。このストック情報は、主体Ａが初期ストックとして米５０Ｋｇを所有し、主体Ｂが初期ストックとして醤油１０Ｌを所有し、Ｃが初期ストックとして味噌２０Ｋｇを所有することを示す。融通管理装置１０４のストック情報取得部１３０は、主体Ａ〜Ｃそれぞれの初期ストックを示す会計型データを各主体に対応付けてストック情報保持部１２２へ格納する。
【０１１９】
このときストック情報保持部１２２には、以下の会計型データが記録される。
ＳＴ[Ａ](１)＝５０＜米、Ｋｇ、＃、Ａ＞＋５０＜米＿資本、Ｋｇ、＃、Ａ＞
ＳＴ[Ｂ](１)＝１０＜醤油、Ｌ、＃、Ｂ＞＋１０＜醤油＿資本、Ｌ、＃、Ｂ＞
ＳＴ[Ｃ](１)＝２０＜味噌、Ｋｇ、＃、Ｃ＞＋２０＜味噌＿資本、Ｋｇ、＃、Ｃ＞
【０１２０】
ここで主体Ａから主体Ｂへ米を２０Ｋｇ融通し、主体Ａから主体Ｃへ米を１０Ｋｇ融通する。米の融通時点では主体間で金銭は移動せず、例えば主体Ｂおよび主体Ｃは融通された米の対価を主体Ａへ支払っていない。後述の醤油や味噌の融通時も同様である。コミュニティのメンバー（例えば主体Ａ〜Ｃのいずれか）は、米の融通の事実を示す融通実績情報２０２を情報端末１０２から融通管理装置１０４へアップロードする。
【０１２１】
融通管理装置１０４の債権債務記録部１３４は、主体Ａ〜Ｂ間の融通事実に基づいて債権情報を主体Ａに対応付けて記録し（後述のｘ[Ａ:１]）、同時に債務情報を主体Ｂに対応付けて記録する（後述のｘ[Ｂ:１]）。また債権債務記録部１３４は、主体Ａ〜Ｃ間の融通事実に基づいて債権情報を主体Ａに対応付けて記録し（後述のｘ[Ａ:２]）、同時に債務情報を主体Ｃに対応付けて記録する（後述のｘ[Ｃ:１]）。
【０１２２】
このとき債権債務情報保持部１２４には、以下の会計型データが記録される。
ｘ[Ａ:１]＝２０＾＜米、Ｋｇ、＃、Ａ＞＋２０＜米＿債権＿Ｂ、Ｋｇ、＃、Ａ＞
「ｘ[Ａ:１]」は、Ａにとってｘ取引の１番目の伝票番号であることを示す。
ｘ[Ｂ:１]＝２０＜米、Ｋｇ、＃、Ａ＞＋２０＜米＿債務＿Ａ、Ｋｇ、＃、Ｂ＞
ｘ[Ａ:２]＝１０＾＜米、Ｋｇ、＃、Ａ＞＋１０＜米＿債権＿Ｃ、Ｋｇ、＃、Ａ＞
ｘ[Ｃ:１]＝１０＜米、Ｋｇ、＃、Ａ＞＋１０＜米＿債務＿Ａ、Ｋｇ、＃、Ｃ＞
【０１２３】
次に主体Ｂから主体Ａへ醤油を２Ｌ融通し、主体Ｂから主体Ｃへ醤油を１Ｌ融通する。コミュニティのメンバーは、その融通の事実を示す融通実績情報２０２を情報端末１０２から融通管理装置１０４へアップロードする。融通管理装置１０４の債権債務記録部１３４は、主体Ｂ〜Ａ間の融通事実に基づいて債権情報を主体に対応付けて記録し（後述のｙ[Ｂ:１]）、同時に債務情報を主体Ａに対応付けて記録する（後述のｙ[Ａ:１]）。また債権債務記録部１３４は、主体Ｂ〜Ｃ間の融通事実に基づいて債権情報を主体Ｂに対応付けて記録し（後述のｙ[Ｂ:２]）、同時に債務情報を主体Ｃに対応付けて記録する（後述のｙ[Ｃ:１]）。
【０１２４】
このとき債権債務情報保持部１２４には、以下の会計型データが記録される。
ｙ[Ｂ:１]＝２＾＜醤油、Ｌ、＃、Ｂ＞＋２＜醤油＿債権＿Ａ、Ｌ、＃、Ｂ＞
ｙ[Ａ:１]＝２＜醤油、Ｌ、＃、Ｂ＞＋２＜醤油＿債務＿Ｂ、Ｌ、＃、Ａ＞
ｙ[Ｂ:２]＝１＾＜醤油、Ｌ、＃、Ｂ＞＋１＜醤油＿債権＿Ｃ、Ｌ、＃、Ｂ＞
ｙ[Ｃ:１]＝１＜醤油、Ｌ、＃、Ｂ＞＋１＜醤油＿債務＿Ｂ、Ｌ、＃、Ｃ＞
【０１２５】
次に主体Ｃから主体Ａへ味噌を４Ｋｇ融通し、主体Ｃから主体Ｂへ味噌を１Ｋｇ融通する。コミュニティのメンバーは、その融通の事実を示す融通実績情報２０２を情報端末１０２から融通管理装置１０４へアップロードする。融通管理装置１０４の債権債務記録部１３４は、主体Ｃ〜Ａ間の融通事実に基づいて債権情報を主体Ｃに対応付けて記録し（後述のｚ[Ｃ:１]）、同時に債務情報を主体Ａに対応付けて記録する（後述のｚ[Ａ:１]）。また債権債務記録部１３４は、主体Ｃ〜Ｂ間の融通事実に基づいて債権情報を主体Ｃに対応付けて記録し（後述のｚ[Ｃ:２]）、同時に債務情報を主体Ｂに対応付けて記録する（後述のｚ[Ｂ:１]）。
【０１２６】
このとき債権債務情報保持部１２４には、以下の会計型データが記録される。
ｚ[Ｃ:１]＝４＾＜味噌、Ｋｇ、＃、Ｃ＞＋４＜味噌＿債権＿Ａ、Ｋｇ、＃、Ｃ＞
ｚ[Ａ:１]＝４＜味噌、Ｋｇ、＃、Ｃ＞＋４＜味噌＿債務＿Ｃ、Ｋｇ、＃、Ａ＞
ｚ[Ｃ:２]＝１＾＜味噌、Ｋｇ、＃、Ｃ＞＋１＜味噌＿債権＿Ｂ、Ｋｇ、＃、Ｃ＞
ｚ[Ｂ:１]＝１＜味噌、Ｋｇ、＃、Ｃ＞＋１＜味噌＿債務＿Ｂ、Ｋｇ、＃、Ｂ＞
このように評価タイミングに至るまでの間に、融通対象財の金銭的評価を含まない債権情報と債務情報が債権債務情報保持部１２４に蓄積されていく。
【０１２７】
評価タイミングとして予め定められた日時に至ると、評価部１３８は、コミュニティにおいて事後的に決定された融通対象財の価格に基づいて、実物ベースの債権、債務から、金銭ベースの債権、債務を取得し、コミュニティの各主体に関する評価情報を作成する。主体毎の評価情報を順次作成してもよく、並行して作成してもよい。
【０１２８】
ここでは、評価タイミングにおける米、味噌、醤油の時価が、以下のように定まり、価格保持部１２６に格納されていることとする。
米：１Ｋｇあたり４００円
醤油：１Ｌあたり１０００円
味噌：１Ｋｇあたり５００円
【０１２９】
まず評価部１３８は、債権債務情報保持部１２４に格納された複数の債権情報と債務情報の中から、特定の評価対象主体に対応付けられた債権情報と債務情報を読み出す。
【０１３０】
この例では、評価対象主体Ａについて以下の債権情報、債務情報を読み出す。
Ａの債権情報、言い換えれば、Ａが融通元（貸与する側）となった会計型データ：
ｘ[Ａ:１]＝２０＾＜米、Ｋｇ、＃、Ａ＞＋２０＜米＿債権＿Ｂ、Ｋｇ、＃、Ａ＞
ｘ[Ａ:２]＝１０＾＜米、Ｋｇ、＃、Ａ＞＋１０＜米＿債権＿Ｃ、Ｋｇ、＃、Ａ＞
Ａの債務情報、言い換えれば、Ａが融通先（貸与される側）となった会計型データ：
ｙ[Ａ:１]＝２＜醤油、Ｌ、＃、Ｂ＞＋２＜醤油＿債務＿Ｂ、Ｌ、＃、Ａ＞
ｚ[Ａ:１]＝４＜味噌、Ｋｇ、＃、Ｃ＞＋４＜味噌＿債務＿Ｃ、Ｋｇ、＃、Ａ＞
【０１３１】
また、評価対象主体Ｂについて以下の債権情報、債務情報を読み出す。
Ｂの債権情報：
ｙ[Ｂ:１]＝２＾＜醤油、Ｌ、＃、Ｂ＞＋２＜醤油＿債権＿Ａ、Ｌ、＃、Ｂ＞
ｙ[Ｂ:２]＝１＾＜醤油、Ｌ、＃、Ｂ＞＋１＜醤油＿債権＿Ｃ、Ｌ、＃、Ｂ＞
Ｂの債務情報：
ｘ[Ｂ:１]＝２０＜米、Ｋｇ、＃、Ａ＞＋２０＜米＿債務＿Ａ、Ｋｇ、＃、Ｂ＞
ｚ[Ｂ:１]＝１＜味噌、Ｋｇ、＃、Ｃ＞＋１＜味噌＿債務＿Ｂ、Ｋｇ、＃、Ｂ＞
【０１３２】
また、評価対象主体Ｃについて以下の債権情報、債務情報を読み出す。
Ｃの債権情報：
ｚ[Ｃ:１]＝４＾＜味噌、Ｋｇ、＃、Ｃ＞＋４＜味噌＿債権＿Ａ、Ｋｇ、＃、Ｃ＞
ｚ[Ｃ:２]＝１＾＜味噌、Ｋｇ、＃、Ｃ＞＋１＜味噌＿債権＿Ｂ、Ｋｇ、＃、Ｃ＞
Ｃの債務情報：
ｘ[Ｃ:１]＝１０＜米、Ｋｇ、＃、Ａ＞＋１０＜米＿債務＿Ａ、Ｋｇ、＃、Ｃ＞
ｙ[Ｃ:１]＝１＜醤油、Ｌ、＃、Ｂ＞＋１＜醤油＿債務＿Ｂ、Ｌ、＃、Ｃ＞
【０１３３】
以下では、主体Ａについての評価情報を生成する処理を説明するが、主体Ｂ、Ｃについての評価情報を生成する処理も同様である。
評価部１３８は、債権情報および債務情報を実物ベースから金銭ベースへ変換するための会計型データである価格振替データを生成する。具体的には以下の４つを生成する。
【０１３４】
価格振替[Ａ:米＿債権＿Ｂ]＝２０＾＜米＿債権＿Ｂ、Ｋｇ、＃、Ａ＞＋８０００＜債権＿Ｂ、円、＃、Ａ＞  ・・・（式３）
式３は、米２０Ｋｇ分の実物債権を８０００円（２０×４００）分の金銭債権へ変換するための価格振替データを示している。
価格振替[Ａ:米＿債権＿Ｃ]＝１０＾＜米＿債権＿Ｃ、Ｋｇ、＃、Ａ＞＋４０００＜債権＿Ｃ、円、＃、Ａ＞  ・・・（式４）
【０１３５】
価格振替[Ａ:醤油＿債務＿Ｂ]＝２＾＜醤油＿債務＿Ｂ、Ｌ、＃、Ａ＞＋２０００＜債務＿Ｂ、円、＃、Ａ＞  ・・・（式５）
式５は、醤油２Ｌ分の実物債務を２０００円（２×１０００）分の金銭債務に変換するための価格振替データを示している。
価格振替[Ａ:味噌＿債務＿Ｃ]＝４＾＜味噌＿債務＿Ｃ、Ｋｇ、＃、Ａ＞＋２０００＜債務＿Ｃ、円、＃、Ａ＞  ・・・（式６）
【０１３６】
ここで一旦残高情報を生成してもよいが、第１実施形態の評価部１３８はさらに、債権債務関係を相殺するための会計型データである相殺振替データを生成する。具体的には、評価部１３８は、式３と式５に基づいて、同一主体Ｂを相手先とする債権と債務の組み合わせが存在することを検出する。そして、債権額と債務額のうち低い方（ここでは２０００円）を相殺額として決定し、次の相殺振替データを生成する。
相殺振替[Ａ:Ｂとの相殺]＝２０００＾＜債権＿Ｂ、円、＃、Ａ＞＋２０００＾＜債務＿Ｂ、円、＃、Ａ＞
相殺によって債権額と債務額の両方が減少するため、相殺額に「＾」を付与する。
【０１３７】
同様に評価部１３８は、式４と式６に基づいて、同一主体Ｃを相手先とする債権と債務が存在することを検出する。そして、債権額と債務額のうち低い方（ここでは２０００円）を相殺額として決定し、次の相殺振替データを生成する。
相殺振替[Ａ:Ｃとの相殺]＝２０００＾＜債権＿Ｃ、円、＃、Ａ＞＋２０００＾＜債務＿Ｃ、円、＃、Ａ＞
なお同一主体を相手先とする債権と債務の組み合わせが存在しなければ、相殺振替データの生成処理、すなわち債権と債務の相殺処理をスキップしてもよい。
【０１３８】
評価部１３８は、評価対象主体Ａの債権情報、債務情報、価格振替データ、相殺振替データに基づいて残高情報を生成する。具体的には次の計算を実行する。
価格振替後残高[Ａ]＝〜｛ｘ[Ａ:１]＋ｘ[Ａ:２]＋ｙ[Ａ:１]＋ｚ[Ａ:１]＋価格振替[Ａ:米＿債権＿Ｂ]＋価格振替[Ａ:米＿債権＿Ｃ]＋価格振替[Ａ:醤油＿債務＿Ｂ]＋価格振替[Ａ:味噌＿債務＿Ｃ]＋相殺振替[Ａ:Ｂとの相殺]＋相殺振替[Ａ:Ｃとの相殺]｝
＝２０＾＜米、Ｋｇ、＃、Ａ＞＋１０＾＜米、Ｋｇ、＃、Ａ＞＋２＜醤油、Ｌ、＃、Ｂ＞＋４＜味噌、Ｋｇ、＃、Ｃ＞＋６０００＜債権＿Ｂ、円、＃、Ａ＞＋２０００＜債権＿Ｃ、円、＃、Ａ＞
【０１３９】
なお、価格振替後残高の生成に際して、同一主体を相手先とする債権、すなわち基底の１項目が同一の債務者を示す債権が複数存在する場合、評価部１３８は、それら複数の債権の値を合計する。同様に、同一主体を相手先とする債務、すなわち基底の１項目が同一の債権者を示す債務が複数存在する場合、評価部１３８は、それら複数の債務の値を合計する。これにより、例えば主体Ａから主体Ｂへの米の融通が複数回なされた場合に、それら複数回の融通により生じた複数の債権（基底は＜債権＿Ｂ、円、＃、Ａ＞）を、１つの債権に集約する。
【０１４０】
評価部１３８は、価格振替後残高[Ａ]を主体Ａに関する評価情報として評価情報保持部１２８へ格納する。この価格振替後残高[Ａ]を見た主体Ａは、Ｂに対する６０００円分の債権と、Ｃに対する２０００円分の債権が存在することを把握できる。また、複式での記録であるため、そのような債権が生じた要因としての実物の融通状態も把握できる。評価部１３８は、主体Ａと同様に、主体Ｂと主体Ｂについての価格振替後残高を生成して評価情報保持部１２８へ格納する。主体Ｂの価格振替後残高は、Ａに対する６０００円の債務と、Ｃに対する５００円の債権を示すものになる。また主体Ｃの価格振替後残高は、Ａに対する２０００円の債務と、Ｂに対する５００円の債務を示すものになる。
【０１４１】
次に、価格振替後残高を見た主体Ｂが主体Ａに対して現金６０００円を支払い、同じく価格振替後残高を見た主体Ｃが主体Ａに対して現金２０００円を支払ったとする。コミュニティのメンバーは、その事実を示す支払情報２０６を情報端末１０２から融通管理装置１０４へアップロードする。
【０１４２】
融通管理装置１０４の支払情報取得部１４２は、支払情報２０６から次の債権回収データを生成し、評価部１３８に渡す。
債権回収[Ａ:債権＿Ｂ]＝６０００＾＜債権＿Ｂ、円、＃、Ａ＞＋６０００＜現金、円、＃、＃＞
この債権回収データは、Ａが保有するＢに対する６０００円分の債権を、現金６０００円に振替えるための振替データとも言える。
債権回収[Ａ:債権＿Ｃ]＝２０００＾＜債権＿Ｃ、円、＃、Ａ＞＋２０００＜現金、円、＃、＃＞
【０１４３】
評価部１３８は、価格振替後残高と債権回収データに基づいて次の残高情報を生成し、主体Ａに関する新たな評価情報として評価情報保持部１２８へ格納する。
債権債務回収後残高[Ａ:財の実物簿記表示]＝〜｛価格振替後残高[Ａ]＋債権回収[Ａ:債権＿Ｂ]＋債権回収[Ａ:債権＿Ｃ]｝
＝２０＾＜米、Ｋｇ、＃、Ａ＞＋１０＾＜米、Ｋｇ、＃、Ａ＞＋２＜醤油、Ｌ、＃、Ｂ＞＋４＜味噌、Ｋｇ、＃、Ｃ＞＋６０００＜現金、円、＃、＃＞＋２０００＜現金、円、＃、＃＞
＝２０＾＜米、Ｋｇ、＃、Ａ＞＋１０＾＜米、Ｋｇ、＃、Ａ＞＋２＜醤油、Ｌ、＃、Ｂ＞＋４＜味噌、Ｋｇ、＃、Ｃ＞＋８０００＜現金、円、＃、＃＞
【０１４４】
ここまでで、債権債務関係の実物ベース表示が金銭ベース表示に変換され、主体間での金銭の支払が債権債務の回収として残高情報に反映された。ただし、個々に融通される財については実物ベース表示のままである。評価部１３８は、価格保持部１２６に保持された融通対象財の価格に基づいて、財の取引についても現金表示へ振替える。評価部１３８は、この振替後の残高情報も主体Ａに関する評価情報として評価情報保持部１２８へ格納する。
【０１４５】
債権債務回収後残高[Ａ:財の現金表示]＝８０００＾＜米、Ｋｇ、＃、Ａ＞＋４０００＾＜米、Ｋｇ、＃、Ａ＞＋２０００＜醤油、Ｌ、＃、Ｂ＞＋２０００＜味噌、Ｋｇ、＃、Ｃ＞＋８０００＜現金、円、＃、＃＞
＝１２０００＾＜米、Ｋｇ、＃、Ａ＞＋２０００＜醤油、Ｌ、＃、Ｂ＞＋２０００＜味噌、Ｋｇ、＃、Ｃ＞＋８０００＜現金、円、＃、＃＞
【０１４６】
評価部１３８は、債権債務回収後残高[Ａ:財の現金表示]にしたがって、試算表のデータを作成し、評価情報として評価情報保持部１２８へ格納してもよい。以下の試算表で示されるように、多段階の期中取引は、借方と貸方がバランスする。
借方    ｜貸方
現金  ８０００円  ｜  米  １２０００円
醤油  ２０００円  ｜
味噌  ２０００円  ｜
【０１４７】
評価部１３８は、ストック情報保持部１２２に保持された初期ストックに対して債権債務回収後残高を足して期末（最終段階）のストックを算出し、算出した最終段階のストック情報を評価情報として価格保持部１２６へ格納する。なお、最終段階のストック情報は、次回の評価期間における期首のストック情報としてストック情報保持部１２２にも格納されてよい。
【０１４８】
この事例では、評価部１３８は、最終段階のストック情報を生成するために次の計算を実行する。
ＳＴ[Ａ]（最終段階）＝〜｛ＳＴ[Ａ]（１）＋債権債務回収後残高[Ａ:財の実物簿記表示]
＝５０＜米、Ｋｇ、＃、Ａ＞＋５０＜米＿資本、Ｋｇ、＃、Ａ＞＋２０＾＜米、Ｋｇ、＃、Ａ＞＋１０＾＜米、Ｋｇ、＃、Ａ＞＋２＜醤油、Ｌ、＃、Ｂ＞＋４＜味噌、Ｋｇ、＃、Ｃ＞＋８０００＜現金、円、＃、＃＞
＝２０＜米、Ｋｇ、＃、Ａ＞＋５０＜米＿資本、Ｋｇ、＃、Ａ＞＋２＜醤油、Ｌ、＃、Ｂ＞＋４＜味噌、Ｋｇ、＃、Ｃ＞＋８０００＜現金、円、＃、＃＞
【０１４９】
評価部１３８は、最終段階のストック情報をさらに現金表示へ振替え、振替後のストック情報も評価情報として評価情報保持部１２８へ格納する。
ＳＴ[Ａ:財の現金表示]（最終段階）＝８０００＜米、円、＃、Ａ＞＋２０００＜醤油、円、＃、Ｂ＞＋２０００＜味噌、円、＃、Ｃ＞＋８０００＜現金、円、＃、＃＞＋２００００＜米＿資本、Ｋｇ、＃、Ａ＞
【０１５０】
さらに評価部１３８は、現金表示のストック情報に基づいてバランスシートを作成してもよい。評価部１３８は、バランスシートのデータを評価情報として評価情報保持部１２８へ格納する。
借方    ｜貸方
現金  ８０００円  ｜  米＿資本  ２００００円
米  ８０００円  ｜
醤油  ２０００円  ｜
味噌  ２０００円  ｜
バランスシートを見たコミュニティメンバーは、自身が期首に所有した財が、コミュニティの融通を経て、どのような資産に置き換わったかを容易に把握できる。
【０１５１】
第１実施形態の融通管理装置１０４によると、コミュニティに所属する主体間でなされた財の相互融通を会計的に管理し、その清算を支援することができる。また、財の融通により生じた債権債務の情報を、その融通に関わる主体のそれぞれに対応付けて記録することで、コミュニティメンバーの個々が保有する債権と債務を明確化でき、清算の確実性を高めることができる。
【０１５２】
また融通管理装置１０４によると、融通結果の評価規則（第１実施形態では主に財の価格）をコミュニティメンバーが納得の上、決定しやすくなり、不透明な善意や貸しの概念を用いずに、相互融通の透明性を確保できる。また、融通管理装置１０４が評価情報を提供し、適切な清算を促すことにより、コミュニティメンバーのそれぞれが財の融通に納得感を持って、持続可能な財の融通サイクルを実現できる。
【０１５３】
以上、本発明を第１実施形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。
【０１５４】
第１変形例を説明する。上記第１実施形態ではコミュニティメンバ間の債権債務関係を現金で評価した。第１変形例では、コミュニティ内で有効になる仮想的な価値交換媒体により債権債務関係を評価する。仮想的な価値交換媒体は、現金と異なり、コミュニティ内だけで価値が保証されるものでもよい。例えば、保有額が大きくなるほどコミュニティ内で大きな利益や便宜を享受できるポイントや擬似的な通貨、電子マネーでもよく、以下「仮想通貨」と呼ぶこととする。
【０１５５】
第１変形例の評価部１３８は、コミュニティの特定のメンバに対応付けて記録された物量単位の債権情報と債務情報を、コミュニティ内で有効な仮想通貨の単位で債権と債務の大きさを示す債権情報と債務情報へ変換する。そして変換後の債権情報と債務情報とを相殺する。具体的には、価格保持部１２６には、仮想通貨を基準とした財の価値を示す情報が保持される。評価部１３８は、債権と債務の大きさを、仮想通貨基準で示す価格振替データを作成する。そして、債権債務記録部１３４により各主体に対応付けて記録された物量単位の債権情報と債務情報を、仮想通貨単位の債権情報と債務情報に変換する。
【０１５６】
第１変形例によると、融通の清算手段として現金通貨を持たないコミュニティや、あるいは現金通貨を使用したくないコミュニティにおいても、実物ベースの債権債務関係を仮想通貨ベースに変換して相殺でき、融通のシステムを効率的に運営できる。なお、ポイント等の仮想通貨は、コミュニティ内での価値の保証、利用の保証が必要になる。
【０１５７】
第２変形例を説明する。上記第１実施形態では、主体間で米、醤油、味噌を融通する例を示したが、第１実施形態の技術は、様々な財やサービスの融通の管理および清算の支援に適用可能である。例えば、コミュニティにおいて、充電や太陽光発電等を用いて、エネルギーを生成し、またタイムシフトができる場合、コミュニティのメンバー間でエネルギーを相互融通することが可能になる。第１実施形態の技術は、電気や熱等のエネルギーを財として相互融通するビルエネルギー管理（主体は例えばビルに入居する複数のテナント）や地域エネルギー管理（主体は例えば地域の住民、企業、建物等）に適用できる。
【０１５８】
この場合、エネルギー消費最小化、エネルギーコスト最小化、ＣＯ２削減最大化等のコミュニティポリシーにあわせた決済原理が適用されてよい。例えば、価格保持部１２６には、このような決済原理にしたがって予め定められたエネルギー種類毎の価格データが保持されてよい。これにより、評価部１３８が作成する評価情報に、エネルギー種類毎の価格を反映させる。結果として、コミュニティポリシーをエネルギー融通結果の評価情報に反映させることができる。なお、第１変形例と組み合わせて、エネルギー融通の不均衡を現金通貨で評価する代わりに、コミュニティ内で有効なポイント等の仮想通貨で評価してもよい。
【０１５９】
第３変形例を説明する。上記第１実施形態では、事後的価格評価による評価処理（清算処理とも言える）を実行した。第３変形例では、実物融通の相殺（ネッティング）による評価処理（清算処理）を実行する。具体的には、２主体間で相殺可能な相互取引がある場合、財の金銭評価がなくても、２主体間の債権債務関係を解消する。第３変形例の評価部１３８は、評価対象主体に対応付けて記録された債権情報と債務情報のうち、同一または対応する財の融通に伴って記録された債権情報が示す債権と債務情報が示す債務とを、物量ベースの記述のまま相殺する。物量ベースの記述のまま相殺するとは、債権情報および債務情報が財の計量単位の値のまま相殺することと言え、また、金銭単位に変換することなく相殺することと言える。
【０１６０】
事例として、評価期間内の第１時点では主体Ａに米が余り、主体Ｂに米が不足する一方、第２時点では主体Ａに米が不足し、主体Ｂに米が余る状況を想定する。そして、第１時点において主体Ａから主体Ｂへ米２０Ｋｇを融通し、第２時点において主体Ｂから主体Ａへ米１０Ｋｇを融通する。
【０１６１】
債権債務情報保持部１２４に記録される債権情報と債務情報は次のとおりである。ｘはＡからＢへ米を融通した取引、ｙはＢからＡへ米を融通した取引を示す。
ｘ[Ａ]＝２０＾＜米、Ｋｇ、＃、Ａ＞＋２０＜米＿債権＿Ｂ、Ｋｇ、＃、Ａ＞
ｘ[Ｂ]＝２０＜米、Ｋｇ、＃、Ａ＞＋２０＜米＿債務＿Ａ、Ｋｇ、＃、Ｂ＞
ｙ[Ｂ]＝１０＾＜米、Ｋｇ、＃、Ｂ＞＋１０＜米＿債権＿Ａ、Ｋｇ、＃、Ｂ＞
ｙ[Ａ]＝１０＜米、Ｋｇ、＃、Ｂ＞＋１０＜米＿債務＿Ｂ、Ｋｇ、＃、Ａ＞
【０１６２】
ここでは、評価部１３８は、評価対象主体Ａの債権情報ｘ[Ａ]と債務情報ｙ[Ａ]とが、相手先が同じで、かつ、同一財の融通を示すことを検出し、両者を相殺するための以下の相殺取引データを生成する。なお、評価部１３８は、債権額と債務額の小さい方を相殺額として設定し、ここでの相殺額は１０Ｋｇとなる。
相殺振替[Ａ]＝１０＾＜米＿債権＿Ｂ、Ｋｇ、＃、Ａ＞＋１０＾＜米＿債務＿Ｂ、Ｋｇ、＃、Ａ＞
同様に評価部１３８は、評価対象主体Ｂについても同様に以下の相殺取引データを生成する。
相殺振替[Ｂ]＝１０＾＜米＿債務＿Ａ、Ｋｇ、＃、Ｂ＞＋１０＾＜米＿債権＿Ａ、Ｋｇ、＃、Ｂ＞
【０１６３】
評価部１３８は、実物財ベースの債権情報および債務情報に対して相殺振替データを足すことにより、評価対象主体の残高情報を生成し、評価情報として評価情報保持部１２８へ格納する。ここでは評価対象主体を主体Ａとする。
相殺振替後残高[Ａ]＝〜｛ｘ[Ａ]＋ｙ[Ａ]＋相殺振替[Ａ]｝
＝２０＾＜米、Ｋｇ、＃、Ａ＞＋１０＜米＿債権＿Ｂ、Ｋｇ、＃、Ａ＞＋１０＜米、Ｋｇ、＃、Ｂ＞
【０１６４】
上記の相殺振替後残高は、Ａの米が２０Ｋｇ出て行き、Ｂの米が１０Ｋｇ入ってきて、Ｂに対する米１０Ｋｇ分の債権が残っている状況を示している。さらに米の種別（初期の所有主体）を同一に振替えれば、第１項と第３項を統合でき、Ａの米が１０Ｋｇ出て行き、Ｂに対する米１０Ｋｇ分の債権が残っている状況を示すものになる。このように第３変形例の構成によると、評価時点で財の金銭的評価が未定であっても、財の融通に伴って記録された実物ベースの債権情報と債務情報を相殺して評価情報を作成することができる。
【０１６５】
上記第３変形例では、同一の財「米」について実物ベースの債権情報と債務情報を相殺することを示したが、厳密には異なるが同一と見なせる対応する財についても実物ベースの債権情報と債務情報を相殺してもよい。例えば、銘柄Ｘの米、銘柄Ｙの米を同一の財と見なして、銘柄Ｘの米債権と銘柄Ｙの米債務を相殺してもよい。同様に、米と麦を同一の財と見なして、米債権と麦債務を相殺してもよく、米債務と麦債権を相殺してもよい。対応する財の情報は、コミュニティ毎にメンバーの承認の下、決定されて、コミュニティ毎に融通管理装置１０４へ登録されればよい。
【０１６６】
第４変形例を説明する。第４変形例では、異なる財・サービス間の交換レートを決めることにより評価処理を実行する。図１０は、第４変形例の融通管理システム１００の構成を示す。情報端末１０２は、コミュニティにおいて定められた異なる複数の財間の交換レートを示すデータ（交換レート２１０）を融通管理装置１０４へアップロードする。交換レート２１０は例えば、米と醤油の交換比率が２Ｋｇ：１Ｌであること、言い換えれば米２Ｋｇと醤油１Ｌが等価であることを示すデータであってもよい。
【０１６７】
融通管理装置１０４は、交換レート取得部１４４と交換レート保持部１２９をさらに備える。交換レート保持部１２９は、異なる財・サービス間の交換レートを保持する。交換レート取得部１４４は、情報端末１０２から送信された交換レート２１０を取得して交換レート保持部１２９へ格納する。
【０１６８】
融通管理装置１０４の評価部１３８は、第１の財の融通に伴って記録された債権情報が示す債権額と、第２の財の融通に伴って記録された債務情報が示す債務額を、交換レート保持部１２９に保持された交換レートに基づいて相殺する。例えば、米と醤油の交換比率が２Ｋｇ：１Ｌである場合、米債権（Ｋｇ単位）と醤油債務（Ｌ単位）を２：１で相殺してもよい。同様に、米債務（Ｋｇ単位）と醤油債権（Ｌ単位）を２：１で相殺してもよい。なお、第１の財の債権情報と第２の財の債務情報がある場合に、一旦、交換比率に基づいて第１の財の債権情報を第２の財の債権情報に変換した上で、第２の財の債権情報と債務情報を相殺してもよい。
【０１６９】
第１の財と第２の財の交換レートを１：１にすることで、第３の変形例で説明したように第１の財と第２の財を同一視した評価処理を実現できる。また第１実施形態と第４変形例を組み合わせる場合、価格保持部１２６には、コミュニティ内で融通対象となる複数の財のうち一部の価格が保持されてもよい。価格が未定の財については、交換レート保持部１２９に、価格が定められた財との交換レートが保持されてもよい。これにより、評価時に一部の財のみ価格が決定されている場合でも、債権情報と債務情報の集計と相殺を実現でき、また、事後的価格評価による評価処理を漏れなく実現できる。
【０１７０】
第５変形例を説明する。第１実施形態における融通対象財の価格、第３変形例における同一視すべき対応する財、第４変形例における交換レートは、融通管理装置１０４により融通状態が管理されるコミュニティ毎に決定されてよい。すなわち、各コミュニティではメンバーの同意の下、融通対象財の価格等を他のコミュニティとは独立して任意に決定することができる。言い換えれば、コミュニティ毎にメンバーの都合や意思に応じた価格や交換レートを柔軟に設定できる。
【０１７１】
（第２実施形態の概要説明）
第２実施形態では、第１実施形態の応用として、金銭の移動を伴わずに環境負荷財（「バッズ」とも言える）が移転されたことを記録する環境会計技術を説明する。生産活動で生じる産業廃棄物（すなわち環境負荷財）は、発生時点では環境への影響や管理コストが不明なものが多い。環境負荷財が経済取引の中でどのように主体間で移転（移管とも言える）されるか、あるいは環境に放出されるかを記述し、最後の環境浄化作業を含む清算プロセスまでを多段階の交換として記述するために、実物ベースの簿記記述（債権債務の記録）が好適である。この方法によると、多段階の実物債権、実物債務の記録と、トレーサビリティの確保が同時に可能になる。
【０１７２】
環境負荷財移転の評価では、事後的な処理コストの評価替えを可能としてもよい。これにより、事後的な環境負荷財の負債拡大に備えて、環境負荷財を事後請求権付き環境負荷財として、環境負荷財の処理に必要なコストを一種の評価替えとして扱い、長期に亘り責任を記述することも可能になる。
【０１７３】
一見すると、環境負荷財の評価替えを認めることは、コストの算定を不安定にするという議論を惹起しかねない。しかし、財の評価替えそのものは、通常の財務会計の中でプラスの価値の財に対して行われることがある。例えば土地や株式の資産は、取得原価で評価されるだけでなく、国際会計基準では時価評価による評価替えが常に求められている。同様に在庫品の価格変動に伴う在庫評価替え等も普通に行われる。そのため、環境負荷財に関してもその処理コストの変動に応じた時価評価が行われることは当然である。
【０１７４】
企業活動あるいは個人の生活に起因して、マイナスの価値を持つ廃棄物等の環境負荷財が環境へ投棄、排出されることを管理することはサステイナブルな社会経済システムの維持のために必須である。しかし貨幣ベースでの取引の記述と、廃棄物の実物レベルでの環境への投棄や排出による自然環境の変化等をトレーサブルな形で記述することは、複式簿記と同一の枠組みでは困難である。従来、環境会計として記述されるものは、アカウンティング（説明責任）のための、複式の交換記述に対するサテライト勘定としての付加情報の形を取っていた。このようなサテライト勘定記録は、交換という行為と紐づけることは難しく、限界があった。
【０１７５】
そこで、第１実施形態で説明した実物の債務債権勘定を持つ多段階資源配分会計を用いることで、複式簿記の枠組みの中で、環境会計を構築することが可能となる。この場合、環境に環境負荷財（廃棄物や汚染物質）を排出する企業のみならず、環境の側にもバランスシートを設定することになる。この環境という主体のバランスシートは政府等の公的主体が管理することになる。実際に環境負債が現金化され、企業がそれを環境債権を持つ自然に払う場合には、代理人たる政府等の公的主体の勘定に入ることになる。このような公的代理人による自然のバランスシートの管理は、共有地やナショナル・トラストに対しても適用できる。
【０１７６】
例として、α社が１００Ｋｇの廃棄物を環境に排出することを考える。なお、環境は「Ｅｎｖ」と表記する。
１）α社の記述：
１００＾＜環境負荷財、Ｋｇ、＃、α＞＋１００＜環境負荷財＿債務＿Ｅｎｖ、Ｋｇ、＃、α＞
２）環境側の記述：
１００＜環境負荷財、Ｋｇ、＃、α＞＋１００＜環境負荷財＿債権＿α、Ｋｇ、＃、Ｅｎｖ>
この記述では、α社が環境に排出した環境負荷財は、金銭評価はできなくても、α社が環境に対して持つ債務として負債記述される。
【０１７７】
なお環境負荷財の排出に関する取引はマイナスの価値を持つ財の移転であるため、環境負荷財の排出元主体では債務の発生と記述される。逆に環境負荷財の排出先主体（環境等）では債権の発生と記述される。環境負荷財に関する取引記述は、具体的には汚染物質や廃棄物毎、また排出の行為毎に記録される。このような環境負荷財の排出に基づいて記録される企業側の環境債務、環境側の環境債権は、環境負荷財の種類毎に、排出が制度上許されているか否かは別として記録される。各企業と環境に関して、廃棄物の種類毎に、毎年のフローを作成でき、同時にバランスシートも作成できる。また、環境債務と環境債権を記録することで、汚染物質毎に、どのような交換関係と蓄積関係があるかを記録でき、それにより長期的に汚染物質に対する管理やコスト負担の責任を明確にすることができる。
【０１７８】
３）環境自体による環境負荷財の無害化：
自然（環境）の中で、有害物質を分解するなどの形で、無害化がなされることがある。これは自然を主体とした会計という意味では、ある種の生産に伴う付加価値形成が行われたことになる。ここでは環境負荷財の無害化という意味での価値生成を自然が行った場合の付加価値形成の記述を示す。ここでは、環境負荷財債権のコストが確定した時点でその分が自然による付加価値形成となる。
１０＾＜環境負荷財、Ｋｇ、＃、α>＋５＜一般物質、Ｋｇ、＃、Ｅｎｖ＞
【０１７９】
ここでは一般物質をＫｇで記述するが、経済的価値はニュートラル、即ちゼロ価格ということにする。一般物質の実物記述としての管理は実物簿記を通じて行われ、事後的にそのプラス価値あるいはマイナス価値が判明した時点で、再評価（ある種の時価評価による評価替え）を可能にする。この会計処理では、仮に環境債務が価格化され、その債務を持つ企業がその債務額を、自然主体（通常はその代理勘定を政府などの公的機関が持つ）に対して支払うことも想定される。
【０１８０】
４）企業αによる環境負荷財の無害化：
企業αが生産した環境負荷財は環境に放出されるばかりではない。企業自身が環境負荷財を除去、無害化することもある。ここでは、環境負荷財の除去、無害化のために原料２Ｋｇの投入が必要だと仮定する。この場合、以下のような一種の生産取引が生じる。
１０＾＜環境負荷財、Ｋｇ、＃、α＞＋５＜一般物質、Ｋｇ、＃、Ｅｎｖ＞＋２＜原料、Ｋｇ、＃、α＞
これは環境負荷財を消去するつまり、負債勘定を消滅させることになる。このような負債勘定の消滅を、金銭評価でなく物質変化として記述できることが実物簿記の利点となる。
【０１８１】
なお、一般に環境負荷財の発生は、生産プロセスで生じ、例えば次のような取引として記述される。
４０＾＜製品原料、Ｋｇ、＃、α＞＋５０＜製品、Ｋｇ、＃、α＞＋１０＜環境負荷財、Ｋｇ、＃、α＞
【０１８２】
マテリアルコストフロー（ＭＦＣ）会計は、環境負荷財ではなく屑（それ事態の評価不明）の生産に関して、材料の按分や資本コストを按分し、管理会計的に無駄を見える化することを目指すものである。これに対し、第２実施形態の環境会計の目的は、環境負荷財自体をトレーサブルにし、量も含めてダブルエントリーで環境債務と環境債権を明らかにし、環境汚染の責任按分を明確にすることにある。なお、環境会計が進めば、そこから環境負荷財に関するＭＦＣ的な解析も可能になる。
【０１８３】
次に、サービス生産財毎の環境汚染の複式記述について説明する。自動車によるＮＯｘ排出のように、個人や家計による環境負荷財の排出では、個人側に環境会計の作成を求めることは難しい。他方で環境問題を考える上では、ＮＯｘだけでなく、従来の経済学の分類で言う消費者サイドでのサービス生産とそれに基づく環境汚染の記述が必須となる。
【０１８４】
個人が例えば自動車等で環境を汚染する場合は、当該の「財」そのものに紐付ける環境会計が可能となる。この場合、当該の「財」は、個人・家計におけるサービス生産に伴い汚染物質を生産する財として、生産財と見なされる必要がある。その意味では生産の境界の概念を変化させる必要がある。しかし今日のサービス産業化の中で、家計の中でのサービス生産を論じることは必須であり、必然の流れでもある。むろんサービス生産に付随した汚染の発生については、事業所でも同様であり、ＮＯｘの発生は事業所の車についても求められる必要がある。その意味では、自動車という消費財そのものがサービス生産財であり、そのサービス生産に伴う汚染の排出が、従来の経済学の区分である消費財と生産財、消費者と生産者の区別を超えてなされている状況を補足する必要がある。
【０１８５】
まずサービス生産に用いられる家計内資本財毎に、環境汚染を引き起こす、環境負債の発生を記述することを試みる。以下では、家計内資本財として自動車を例とする。
１）環境汚染を引き起こす財毎の環境債権と環境債務の記述例：
ここでは、車という資本財を個人Ｐ（集合的な個人をＰで示す）がガソリンａ３リットルを燃料としてａ１時間利用することを想定する。また、車の利用に伴う環境汚染物質ＮＯｘの発生量をａ２Ｋｇとする。このことは以下のように記述される。
ａ１＜車利用サービス、時間、＃、Ｐ＞＋ａ２＜ＮＯｘ、Ｋｇ、＃、Ｐ＞＋ａ３＾＜ガソリン、Ｌ、＃、Ｐ＞
【０１８６】
更に一般的に言えば、様々な消費財は、電気やガソリン等のエネルギーを原料にサービスを生み出すサービス資本財である。消費財が必要とするエネルギーの総量や、消費財が生み出すサービスと、同時に排出する汚染物質の総体は、財毎のサービス生産の特質に基づく取引記述と、サービス資本財の総量等に基づいて推計が原理的には可能となる。また、このような形でサービスプロファイリングを行うことで、現状の技術により、あるサービス需要を想定するとどのようなエネルギーニーズと排出があるかが推計できる。技術革新の目標もまたこのサービス生産取引の変化として論じることができる。
【０１８７】
不特定多数の個人の集合として家計セクターを一つの（あるいは地域別等の）集合的な主体として、そこでのサービス生産取引や汚染物質の排出を環境簿記で記述することは可能である。しかし、具体的な個人の責任按分は難しい。更にそもそもサービス生産に伴う汚染物質の排出そのものの推計も難しい場合が多い。
【０１８８】
このような場合には、環境の側の汚染の実測から、家計セクターの環境会計における環境負荷財の排出項を事後的に推計し按分することも可能となる。また、環境の側で、実際に測定された環境データを基に環境債権を実物レベルで測定し、それを排出側として推定される個人や企業に按分する方式も考える必要がある。これらはいずれも、まず現物の物質測定レベルでの環境債務や環境債権を明らかにすることから出発し、事後的にその処理コストや負担の配分を行うための、共通の現実を構築することを目的とする。
【０１８９】
（第２実施形態の詳細説明）
図１１は、第２実施形態の環境負荷財移転管理システムの構成を示す。環境負荷財移転管理システム２２０は、環境負荷財の排出状況を管理するための情報処理システムである。融通管理システム１００は、情報端末２２２と環境負荷財移転管理装置２２４を備える。環境負荷財移転管理装置２２４は、第２実施形態の概要説明に記載した環境会計を実行する情報処理装置である。すなわち環境負荷財移転管理装置２２４は、第１の主体と第２の主体間で環境負荷財が移転された場合に、その事実を記録し、所定のタイミングでの清算を支援する。
【０１９０】
情報端末２２２は、環境負荷財が移転された事実を環境負荷財移転管理装置２２４に登録すべき主体により操作される端末である。この操作者は、環境負荷財の移転元主体または移転先主体であってもよく、環境負荷財の移転状況（例えば廃棄物の排出状況）を測定する主体であってもよい。また環境負荷財の移転先が環境（自然）である場合等、環境の代理人となる国や行政機関であってもよい。実際には複数台の情報端末２２２が環境負荷財移転管理装置２２４に接続されてもよい。
【０１９１】
図１１では、第１実施形態で説明した機能ブロックと同一または対応する機能ブロックには同一の符号を付している。以下、第１実施形態で説明済の内容は適宜省略し、主に、第１実施形態と異なる構成および動作を説明する。
【０１９２】
環境負荷財移転情報２１２は、第１実施形態の融通実績情報２０２に対応するものであり、環境負荷財移転の事実を示す情報である。環境負荷財移転情報２１２は、移転元の主体、移転先の主体、移転された環境負荷財、移転された量を示す情報を含む。例えば「企業αから湖（環境）へ汚水を１００Ｋｇ排出した」という内容であってもよい。なお、以下の例では環境負荷財の排出先を環境（自然）とするが、環境負荷財の排出先は環境に限られず、個人や企業であってもよい。例えば環境負荷財を無害化し、または保管する企業であってもよい。
【０１９３】
価格情報２０４は、環境負荷財を処理するための費用であり、例えば単位量の廃棄物や汚水を無害化するための費用が設定される。支払情報２０６は、環境債務の解消のために債務者の主体が支払った金額である。支払情報２０６には、例えば、環境負荷財排出の対価として企業が行政機関へ支払った金額が設定される。
【０１９４】
環境負荷財移転管理装置２２４の対応関係保持部１２０は、情報端末１０２から入力される環境負荷財移転情報２１２を、債権債務情報保持部１２４に保持される会計型データの形式へ変換するための対応関係データを保持する。この対応関係データは、環境負荷財移転情報２１２から債権情報と債務情報を生成する規則と言える。
【０１９５】
具体的には対応関係データは、移転元主体、移転先主体、移転対象環境負荷財、移転量（単位含む）を示す環境負荷財移転情報２１２を、移転元主体の債務情報として、「移転量＾＜移転対象環境負荷財、単位、＃、移転元主体＞＋移転量＜移転対象環境負荷財＿債務＿移転先主体、単位、＃、移転元主体＞」の形式へ変換することを定めた規則であってもよい。さらに同じ環境負荷財移転情報２１２を、移転先主体の債権情報として、「移転量＜移転対象環境負荷財、単位、＃、移転元主体＞＋移転量＜移転対象環境負荷財＿債権＿移転元主体、単位、＃、移転先主体＞」の形式へ変換することを定めた規則であってもよい。
【０１９６】
環境負荷財移転管理装置２２４は、第１実施形態の融通実績取得部１３２に代えて環境負荷財移転情報取得部２２６を備える。環境負荷財移転情報取得部２２６は、情報端末２２２から送信された環境負荷財移転情報２１２を取得して債権債務記録部１３４に渡す。
【０１９７】
債権債務記録部１３４は、第１の主体から第２の主体へ金銭の移動を伴わずに環境負荷財が移転された場合に、移転量に応じた債務の大きさを環境負荷財の計量単位で示す債務情報を生成し、その債務情報を第１の主体に対応付けて債権債務情報保持部１２４へ格納する。それとともに債権債務記録部１３４は、移転量に応じた債権の大きさを環境負荷財の計量単位で示す債権情報を生成し、その債権情報を第２の主体に対応付けて債権債務情報保持部１２４へ格納する。この移転量は、第１の主体における環境負荷財の減少量、第２の主体における環境負荷財の増加量と言える。また、廃棄物の排出の場合、典型的な第１の主体は廃棄物を生産する企業等になり、第２の主体は環境（または代理人としての行政機関）となる。
【０１９８】
このように第２実施形態の債権債務記録部１３４は、第１実施形態の処理とは逆に、環境負荷財の移転元に対応付けて債務情報を記録し、環境負荷財の移転先に対応付けて債権情報を記録する。環境負荷財はマイナスの価値を有する財だからである。第１実施形態の債権債務記録部１３４の他の特徴は、第２実施形態の債権債務記録部１３４にも当てはまる。また第１実施形態の評価部１３８の特徴は、第２実施形態の評価部１３８にも当てはまる。
【０１９９】
以上の構成による環境負荷財移転管理システム２２０の動作を説明する。
環境負荷財移転管理装置２２４の動作は図９に示した融通管理装置１０４の動作と同様である。ただし、Ｓ１０では融通実績情報２０２に代えて環境負荷財移転情報２１２が入力される。
【０２００】
ここで、主体間の融通（貸与）に関する、実物債権および実物債務による記述を、環境会計に適用する例を説明する。具体的には、環境負荷財移転の事例を示しつつ、環境負荷財の移転状況を管理する環境負荷財移転管理装置２２４の動作を説明する。
【０２０１】
ここではマイナスの価値を持つ財である環境負荷財の環境への放出を、負の価値を持つ（負債と同じで貸方勘定に属する）財に関する融通と考える。本来、マイナスの価値を持つ財の融通という概念は、字義的にはおかしく、環境負荷財の放出は環境への環境負荷財の強制であり、押しつけであるというべきであるが、ここでは第１実施形態にあわせて融通という用語を適宜用いる。
【０２０２】
ここでは環境負荷財移転として汚水の排出を考える。汚水の生産を製造取引の範囲でどのように記述するかは別の課題ではあるが、例えば以下のように表現できる。
例えば、α社が、電気を使用して、基板加工品に対してエッチング＆メッキ処理を実施し、エッチング・メッキ済の製品を製造するプロセスを想定する。
Ｘ[α:生産]＝５０＾＜基盤加工品、個、＃、＃＞＋５０＜エッチング・メッキ済製品、個、＃、＃＞＋３＾＜電力、ＷＨ、＃、＃＞＋１００＜汚水、Ｋｇ、＃、α＞
なお、本来汚水は汚染物質の濃度とＬ（リットル）から物質量でも計測すべきだが単純化のために、Ｋｇを単位としている。
【０２０３】
ここでは湖の汚染を課題とし、α社とβ社が隣接する湖（すなわち自然環境）に汚水を排水する。まず、前回の評価期間におけるα社、β社、湖の最終ストック量であり、今回の評価期間における初期ストック量を以下のとおりとする、これらのデータは環境負荷財移転管理装置２２４のストック情報保持部１２２に格納される。
ＳＴ[α](１)＝３００＾＜汚水、Ｋｇ、＃、α＞＋３００＜汚水＿債務＿湖、Ｋｇ、＃、α＞
ＳＴ[β](１)＝２００＾＜汚水、Ｋｇ、＃、β＞＋２００＜汚水＿債務＿湖、Ｋｇ、＃、β＞
ＳＴ[湖](１)＝３００＜汚水、Ｋｇ、＃、α＞＋２００＜汚水、Ｋｇ、＃、β＞＋３００＜汚水＿債権＿α、Ｋｇ、＃、湖＞＋２００＜汚水＿債権＿β、Ｋｇ、＃、湖＞
【０２０４】
評価期間内のある時点で、α社が湖へ汚水８０Ｋｇを排出し、β社が湖へ汚水５０Ｋｇを排出する。汚水の排出時点では汚水移転の主体間で金銭は移動せず、例えばα社およびβ社は汚水の排出量に応じた金銭を環境側（代理人としての公的機関）へ支払っていない。汚水排出の関係者（汚水排出の状況を把握する人であり、例えばα社、β社、または行政機関の担当者等）は、汚水排出の事実を示す環境負荷財移転情報２１２を情報端末１０２から環境負荷財移転管理装置２２４へアップロードする。
【０２０５】
融通管理装置１０４の債権債務記録部１３４は、環境負荷財移転情報２１２が示すα社の汚水排出事実に基づいて債務情報をα社に対応付けて記録し（後述のｘ[α:１]）、同時に債権情報を湖に対応付けて記録する（後述のｘ[湖:１]）。また債権債務記録部１３４は、環境負荷財移転情報２１２が示すβ社の汚水排出事実に基づいて債務情報をβ社に対応付けて記録し（後述のｙ[β:１]）、同時に債権情報を湖に対応付けて記録する（後述のｙ[湖:１]）。
【０２０６】
このとき債権債務情報保持部１２４には、以下の会計型データが記録される。
ｘ[α:１]＝８０＾＜汚水、Ｋｇ、＃、α＞＋８０＜汚水＿債務＿湖、Ｋｇ、＃、α＞
これは汚水を環境へ排出融通した取引を示す。この取引の結果、企業αに環境債務（債権主体は湖）が発生する。
ｘ[湖:１]＝８０＜汚水、Ｋｇ、＃、α＞＋８０＜汚水＿債権＿α、Ｋｇ、＃、湖＞
これは排出された汚水を湖（環境）が引き受けた取引を示す。この取引の結果、湖に環境債権（債務主体はａ社）が発生する。
【０２０７】
ｙ[β:１]＝５０＾＜汚水、Ｋｇ、＃、β＞＋５０＜汚水＿債務＿湖、Ｋｇ、＃、β＞
ｙ[湖:１]＝５０＜汚水、Ｋｇ、＃、β＞＋５０＜汚水＿債権＿β、Ｋｇ、＃、湖＞
このように、α社およびβ社が環境へ排出した環境負荷財としての汚水は、金銭評価ができなくても物量表示され、α社およびβ社が環境に対して持つ債務として負債記述がなされる。逆に、環境負荷財の排出先の主体である湖（環境と言え、実際には代理人としての行政機関等）は、α社とβ社のそれぞれに対して債権を持つことが記録される。
【０２０８】
評価期間中の別の時点で、α社が湖へ汚水４０Ｋｇを排出する。汚水排出の関係者は、その排出の事実を示す新たな環境負荷財移転情報２１２を情報端末１０２から環境負荷財移転管理装置２２４へアップロードする。融通管理装置１０４の債権債務記録部１３４は、新たな環境負荷財移転情報２１２に基づいて債務情報をα社に対応付けて記録し（ｚ[α:１]）、同時に債権情報を湖に対応付けて記録する（ｚ[湖:１]）。このとき債権債務情報保持部１２４には、以下の会計型データが記録される。
ｚ[α:１]＝４０＾＜汚水、Ｋｇ、＃、α＞＋４０＜汚水＿債務＿湖、Ｋｇ、＃、α＞
ｚ[湖:１]＝４０＜汚水、Ｋｇ、＃、α＞＋４０＜汚水＿債権＿α、Ｋｇ、＃、湖＞
【０２０９】
評価タイミングとして予め定められた日時に至ると、評価部１３８は、環境負荷財の排出に関わる複数の主体のうち各評価対象主体について評価期間中に記録された債権情報および債務情報を集計した情報（以下「試算表」と呼ぶ。）を生成する。そして、生成した試算表のデータを評価情報として評価対象主体に対応付けて評価情報保持部１２８へ記録する。
【０２１０】
ここではα社と湖の試算表を示す。
試算表[α]＝〜｛ｘ[α:１]＋ｚ[α:１]｝
＝１２０＾＜汚水、Ｋｇ、＃、α＞＋１２０＜汚水＿債務＿湖、Ｋｇ、＃、α＞
試算表[湖]＝〜｛ｘ[湖:１]＋ｙ[湖:１]＋ｚ[湖:１]｝
＝１２０＜汚水、Ｋｇ、＃、α＞＋５０＜汚水、Ｋｇ、＃、β＞＋１２０＜汚水＿債権＿α、Ｋｇ、＃、湖＞＋５０＜汚水＿債権＿β、Ｋｇ、＃、湖＞
【０２１１】
評価部１３８は、環境負荷財の排出に関わる各主体について評価期間の期末のストック量を示す期末ストック情報を生成する。そして、生成した期末ストック情報を評価情報として評価対象主体に対応付けて評価情報保持部１２８へ記録する。なお、期末ストック情報は、次回の評価期間における初期ストック情報としてストック情報保持部１２２にも格納されてよい。
【０２１２】
この例では以下の期末ストック情報を生成する。
ＳＴ[α](２)＝〜｛ＳＴ[α](１)＋ｘ[α:１]＋ｚ[α:１]｝
＝４２０＾＜汚水、Ｋｇ、＃、α＞＋４２０＜汚水＿債務＿湖、Ｋｇ、＃、α＞
ＳＴ[β](２)＝〜｛ＳＴ[β](１)＋ｙ[β:１]｝
＝２５０＾＜汚水、Ｋｇ、＃、β＞＋２５０＜汚水＿債務＿湖、Ｋｇ、＃、β＞
ＳＴ[湖](２)＝〜｛ＳＴ[湖](１)＋ｘ[湖:１]＋ｙ[湖:１]＋ｚ[湖:１]｝
＝４２０＜汚水、Ｋｇ、＃、α＞＋２５０＜汚水、Ｋｇ、＃、β＞＋４２０＜汚水＿債権＿α、Ｋｇ、＃、湖＞＋２５０＜汚水＿債権＿β、Ｋｇ、＃、湖＞
【０２１３】
第２実施形態の環境負荷財移転管理装置２２４によると、環境を含む主体間での環境負荷財の移転を会計的に管理し、その清算を支援することができる。すなわち、環境負荷財の移転により生じた債権債務の情報を、その移転に関わる主体のそれぞれに対応付けて記録することで、個々の主体が保有する債権と債務を明確化でき、清算の責任の所在を明確化できる。
【０２１４】
なお第１実施形態と同様に、第２実施形態の評価部１３８は、価格保持部１２６に保持された環境負荷財の清算価格（現在時点において無害化に要するコスト等）に基づいて、各主体に対応付けられた試算表やストック情報を金銭評価してもよい。言い換えれば、価格への振替処理を実行してもよい。これにより、個々の主体が有する環境債権や環境債務の大きさを金銭的に示すことができる。なお、技術革新等に伴い環境負荷財の処理コストが変化した場合は、環境負荷財の清算価格が更新されることにより、最新の清算価格に基づいて環境債権や環境債務の金銭評価を見直すことができる。
【０２１５】
また第２実施形態の評価部１３８は、環境負荷財の排出に伴う環境債務を解消するための金銭支払がなされたことを示す支払情報２０６が情報端末２２２から受け付けられた場合に、金銭評価済の債権情報および債務情報を清算してもよい。具体的には、支払情報２０６に基づいて会計型データである債権回収データを生成し、試算表やストック情報の会計型データと足すことで、債権回収後の試算表データ、ストック情報を生成してもよい。
【０２１６】
以上、本発明を第２実施形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【０２１７】
第１実施形態の各変形例は第２実施形態にも適用可能である。例えば、主体間で相互になされた同一または対応する環境負荷財移転の相殺処理を実行することができる。また、異なる環境負荷財間の交換レートを決めることによる相殺処理を実行することができる。この場合、環境負荷財移転管理装置２２４は、交換レート保持部１２９、交換レート取得部１４４をさらに備えてもよい。さらにまた、現金に換えて仮想通貨を基準として、環境債権および環境債務の価値評価（債権債務情報の仮想通貨単位への振替）を実行してもよい。
【０２１８】
（第３実施形態の概要説明）
上記の第１実施形態および第２実施形態で説明した実物簿記記述は、様々な企業や団体等、評価対象主体における一般的な状態記述に適用することもできる。具体的には、実物簿記記述を用いて、評価対象主体で発生した財やサービスの生産、流通、提供等に関するイベント（取引等）毎に、そのイベントによる状態変化を示すデータを記録する。記録された実物簿記記述によるデータは、評価対象主体の状態を示す最も基本となるデータ（原点データとも言える）になる。例えば、そのデータから財務会計のデータを生成することもでき、また環境やエネルギーに関する諸データを抽出することもできる。
【０２１９】
図１２と図１３は、ある企業における様々な取引を実物簿記記述により記録したデータ（以下「実物簿記データ」とも呼ぶ。）を示す。図１３は図１２の続きを示している。第１実施形態および第２実施形態における実物簿記記述と同様に、財やサービスの取引量を、金額表示ではなく、物量単位で示しており、言い換えれば、財やサービスを計量する際に通常使用される単位で示している。
【０２２０】
例えば、図１２の項番１’は、物量単位の簿記記述にて原料購入の取引を示している。また項番５’は、運輸サービス８０Ｋｍを提供するためにガソリン１０Ｌが使用され、同時に環境負荷財であるＣＯ２が２３Ｋｇ発生したことを示している。また図１３の項番１４は、第２実施形態で説明した環境債務概念を用いて環境債務を計上している。金銭取引を伴わずに単に汚染物質（環境負荷財）を排出するだけであれば財務的には債務ゼロと評価される。すなわち財務会計上の記録は残らない。しかし、実物簿記記述では、汚染物質（環境負荷財）排出の事実を残すことができ、言い換えれば、環境債務を事実に即して記録できる。なお、第２実施形態で説明したように、環境債権は環境側で記録されるべきものである。
【０２２１】
図１４は価格情報を示す。この価格情報は、図１２と図１３で示した取引対象の財やサービスの金銭評価を示している。この価格情報に基づいて、図１２と図１３の実物簿記データを変換することにより、物量表示の実物簿記データに対応する金額表示の財務会計データを作成できる。図１５と図１６は、図１２と図１３に対応し、実物簿記データを金額表示へ変換した財務会計データを示す。図１６は図１５の続きを示している。これは試算表に対応するデータとなる。
【０２２２】
このように、第３実施形態における評価対象主体の状態記述では、記述する対象を財務、環境、エネルギー等に分離しない。第３実施形態では、どのような財やサービスが中間生成され、それらがさらにどの工程へ投入されるかを含む評価対象主体の一連の活動を、イベント単位で実物簿記記述により逐次記録する。これにより、財務会計データやエネルギー簿記データ、環境会計データ等、様々な情報を抽出可能な、評価対象主体についての統合的な状態空間の記述を記録できる。例えば、金額表示にした場合等に発生しうる情報の欠落（例えば環境債務の欠落等）を防止できる。
【０２２３】
（第３実施形態の詳細説明）
図１７は、第３実施形態の企業状態管理システムの構成を示す。企業状態管理システム３００は、企業や団体、またそれらの一部門（工場等）を含む様々な評価対象主体の状態管理を支援する情報処理システムである。図１７に示すブロックのうち第１実施形態および第２実施形態で説明したブロックと同一または対応するブロックには同じ符号を付している。以下、第１実施形態および第２実施形態と重複する説明は適宜省略し、異なる点を主に説明する。
【０２２４】
企業状態管理システム３００は、情報端末３０２と企業状態管理装置３０４を含む。企業状態管理装置３０４は、第１実施形態の融通管理装置１０４、第２実施形態の環境負荷財移転管理装置２２４に対応する情報処理装置である。企業状態管理装置３０４は、評価対象主体（ここでは企業）の状態を実物簿記記述によるデータで管理する。情報端末３０２は、評価対象主体の担当者により操作される情報処理装置である。情報端末３０２は、イベント情報３１０、価格情報２０４を企業状態管理装置３０４へアップロードし、企業状態管理装置３０４で生成された評価情報２０８をユーザへ提示する。
【０２２５】
イベント情報３１０は、企業における財やサービスの生産、流通、提供等を含む様々なイベント（取引とも言える）の内容を示すデータである。例えば、あるイベント情報３１０には図１２の取引「鉄の購入」が含まれてよく、別のイベント情報３１０には図１３の取引「塗装サービス生産」が含まれてよい。
【０２２６】
実物簿記データ保持部３１２は、図１２および図１３で示した実物簿記データを保持する。具体的には実物簿記データは、情報端末３０２からアップロードされたイベント情報３１０を実物簿記記述で示す会計型データである。また、借方科目と貸方科目を含む仕分情報とも言える。
【０２２７】
対応関係保持部１２０は、イベント情報３１０から、実物簿記データ保持部３１２に格納すべき実物簿記データを生成するための変換規則を保持する。この変換規則は、例えば、イベント情報３１０に含まれる各データ要素に対して、企業の実物簿記データで予め定められた複数の基底であって、複式簿記において借方にあたる基底である借方基底と複式簿記において借方にあたる基底である貸方基底のうち、どの基底を対応付けるかを定めた対応関係を示すものであってもよい。
【０２２８】
例えば、対応関係保持部１２０に保持される変換規則は、イベント情報３１０が図１２の項番１’の取引「鉄の購入」を示すものであるときに、イベント情報３１０に記録された鉄材の購入量に、借方基底＜鉄材、Ｋｇ、＃、＃＞を対応付けることを定めてもよい。また、イベント情報３１０に記録された買掛金の額に、貸方基底＜買掛金、円、＃、＃＞を対応付けることを定めた情報であってもよい。
【０２２９】
イベント記録部３１４は、情報端末３０２から送信されたイベント情報３１０を受け付け、対応関係保持部１２０が保持する変換規則にしたがって、イベント情報３１０に対応する実物簿記データを実物簿記データ保持部３１２へ格納する。例えば、図１２の項番１’の取引「鉄の購入」を示すイベント情報３１０を受け付けた場合、「５００＜鉄材、Ｋｇ、＃、＃＞＋２００００＜買掛金、円、＃、＃＞」のレコードを実物簿記データ保持部３１２へ格納してもよい。これにより、ある評価期間における企業の実物簿記データ（例えば図１２、図１３の各レコード）が実物簿記データ保持部３１２に蓄積されていく。
【０２３０】
価格情報取得部１３６は、情報端末３０２から送信された価格情報２０４（例えば図１４）を受け付けて、価格保持部１２６へ格納する。評価部１３８は、評価タイミングに至った場合に、実物簿記データ保持部３１２に格納された当期の実物簿記データから各種評価情報を生成し、生成した評価情報のデータを評価情報保持部１２８へ格納する。例えば、実物簿記データ保持部３１２に保持された実物簿記データのうち、評価情報の種類毎に予め定められた情報項目を示す実物簿記データを抽出し、抽出した実物簿記データを集計して評価情報を生成してもよい。また、抽出した実物簿記データを適宜変換（例えば振替や相殺）して評価情報を生成してもよい。
【０２３１】
第３実施形態の評価部１３８は、価格保持部１２６の価格情報にしたがって、実物簿記データ保持部３１２に格納された当期の実物簿記データを金銭表示に変換する。例えば、第１実施形態で示した価格振替計算を実行してもよい。そして実物簿記データ保持部３１２に格納された当期の実物簿記データのうち、金銭表示に変換されたデータを抽出して、図１５と図１６に示したような財務会計データを生成する。この財務会計データは、会計型データの形式、または、図１５、図１６のような財務諸表（試算表やバランスシート等）の形式で評価情報提供部１４０により情報端末３０２へ提供される。
【０２３２】
以上、本発明を第３実施形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【０２３３】
（第４実施形態）
第４実施の形態では、上記の第１実施形態〜第３実施形態に適用可能な情報端末の構成を詳細に説明する。以下では、第４実施形態の情報端末を、第１実施形態の情報端末１０２に対応するものとして説明する。第４実施形態の情報端末は、ＬＡＮ・ＷＡＮ・インターネット等の通信網を介して融通管理装置１０４に接続される。なお、第４実施形態の情報端末は、第２実施形態の情報端末２２２にも適用可能であり、その場合、通信網を介して環境負荷財移転管理装置２２４に接続される。さらに、第４実施形態の情報端末１０２は、第３実施形態の情報端末３０２にも適用可能であり、その場合、通信網を介して企業状態管理システム３００に接続される。
【０２３４】
図１８は、第４実施形態の融通管理システム１００の構成を示す。同図では、図８の融通管理装置１０４を簡略化して描いている。情報端末１０２は、制御部１５０、記憶部１５２、通信部１５４を備える。制御部１５０は、情報端末１０２における各種データ処理を実行する。記憶部１５２は、制御部１５０により参照され、または更新される各種データを記憶する記憶領域である。通信部１５４は、所定の通信プロトコルにしたがって、通信網（不図示）を介して、融通管理装置１０４の通信部１１４と通信する。制御部１５０は、通信部１５４を介して融通管理装置１０４とデータを交換する。
【０２３５】
記憶部１５２は、第１実施形態において説明したストック情報２００、融通実績情報２０２、価格情報２０４、支払情報２０６、評価情報２０８を保持する。なお、第２実施形態に適用する場合、記憶部１５２は、図１１に示した各種情報を保持する。また、第３実施形態に適用する場合、記憶部１５２は、図１７に示した各種情報を保持する。
【０２３６】
制御部１５０は、表示制御部１６０、情報入力部１６２、情報取得部１６４を含む。表示制御部１６０は、記憶部１５２に記憶されたデータをユーザへ提示するためのユーザインタフェースを制御する。具体的には、表示制御部１６０は、ストック情報２００、融通実績情報２０２、価格情報２０４、または支払情報２０６を融通管理装置１０４へ登録（アップロード）するための入力画面を所定の表示装置（不図示）に表示させる。この入力画面は、ストック情報２００、融通実績情報２０２、価格情報２０４、支払情報２０６の具体的な内容（値）をユーザに入力させるためのフィールドを含んでもよい。
【０２３７】
情報入力部１６２は、入力画面に対して情報登録を指示する操作が入力された場合に、入力画面に入力されたストック情報２００、融通実績情報２０２、価格情報２０４、または支払情報２０６を融通管理装置１０４へ送信する。なお、第２実施形態では融通実績情報２０２に代えて環境負荷財移転情報２１２を送信し、第３実施形態では融通実績情報２０２に代えてイベント情報３１０を送信する。これにより、融通管理装置１０４に財（エネルギー等）の融通に関する債権情報および債務情報を記録させる。
【０２３８】
情報取得部１６４は、融通管理装置１０４により生成された評価情報２０８（財やサービス、エネルギー等の残高情報を含む）を融通管理装置１０４から取得し、記憶部１５２へ格納する。情報取得部１６４は、融通管理装置１０４から定期的に提供される評価情報２０８を取得してもよく、ユーザの指示に応じて融通管理装置１０４へ評価情報２０８の提供を要求してもよい。表示制御部１６０は、情報取得部１６４により取得された評価情報２０８、または、記憶部１５２に格納済の評価情報２０８を所定の表示装置に表示させる。
【０２３９】
ユーザは、ストック情報２００や、過去の融通に関する評価情報２０８を表示させて、現在ストック中の財またはサービスを他のユーザへ融通するか否かを決定してもよい。第２実施形態では環境負荷財を他の主体へ移転するか否かを決定してもよい。融通を決定した場合（融通を実行した場合）、ユーザは、入力画面に今回の融通実績情報２０２を入力し、入力した融通実績情報２０２を融通管理装置１０４へ登録してもよい。所定の評価期間の期末になった場合、ユーザは、記憶部１５２に格納された評価情報２０８を表示させて、現在の融通の状況や相殺結果等を確認してもよい。
【０２４０】
また、情報端末１０２の入力画面に、ユーザが評価処理の開始要求を入力した場合、または、融通の管理者が評価処理の開始指示を入力した場合に、情報入力部１６２は、その要求や指示を融通管理装置１０４へ送信してもよい。融通管理装置１０４は、この要求や指示に応じて評価タイミングに至ったと判定し、融通に関する評価処理（事後的価格評価による清算処理とも言える）を実行してもよい。情報取得部１６４は、融通管理装置１０４による評価処理の結果である評価情報２０８を取得して評価情報保持部１２８へ格納してもよい。また、表示制御部１６０は、情報取得部１６４により取得された評価情報２０８を表示させてもよい。なお、情報端末１０２は、ユーザ毎に設けられてもよく、コミュニティ内での融通を管理する管理者のみに設けられてもよく、コミュニティ内の複数のユーザで共用されてもよい。
【０２４１】
以上、本発明を第４実施形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【０２４２】
上述した実施の形態、変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態、変形例それぞれの効果をあわせもつ。
【０２４３】
上述の第１実施形態では、金銭の移動を伴わない財やサービスの融通として、消費財である米、醤油、味噌を例に記述したが、小さなコミュニティ内での物・物交換（融通）や物とサービスの融通にも適用できる。さらに、電気エネルギーと熱・ガスなど他のエネルギーとの交換（融通）、蓄積された電気エネルギーと流通されている電気エネルギーとの交換（融通）、異なる媒体のエネルギーの交換（融通）にも適用できる。
第２実施形態では、環境負荷財として、産業廃棄物を対象として説明したが、ＣＯ２等、環境負荷物質を対象としてもよい。
第３実施形態では、企業における価格が事前に定まらない財やサービスの融通としての生産、流通、提供等を対象として説明したが、企業内での融通のみならず、企業間での融通を対象としてよい。
【０２４４】
上述の各実施形態に記載の評価タイミングは、デフォルトとしては月末、期末、会計年度末等であってもよい。評価部は、予め設定された時刻情報に基づく評価情報生成指示、または、（ユーザ端末等から入力された）随時の評価情報生成指示を受け付けた後に、各種評価情報の生成処理を開始してもよい。評価情報提供部は、生成された評価情報を、評価情報生成指示の発信元宛、または、予め定められた端末装置宛に配信してもよい。
【０２４５】
また、評価部は、ローカルの入力装置またはリモートの情報端末から、評価情報要求信号を検出した後に集計処理を開始して、集計結果（評価情報）を生成して所定のデータ保存手段へ保存し、その後に集計結果（評価情報）を要求元へ配信してもよい。所定のタイミング（例えば月末、期末、会計年度末等）までに評価情報要求信号を未受信である場合、評価部は、評価情報要求信号を受け付けたものとして、集計結果（評価情報）を生成して所定のデータ保存手段へ保存し、その後に集計結果（評価情報）を所定の外部装置へ配信してもよい。この場合、融通管理装置１０４（環境負荷財移転管理装置２２４）は、評価情報要求信号に代わる擬似信号を評価部へ入力する擬似信号入力部をさらに備え、評価部はこの擬似信号の入力を検出したことを契機に集計結果（評価情報）を生成してもよい。
【０２４６】
明細書または請求項に記載の「エネルギ等」は、エネルギ、環境負荷財、廃棄物の総称であってもよい。具体的には「エネルギ等」は、電気、ガス、温熱、環境負荷財、使用済み天ぷら油、バイオ燃料用のゴミ、アルコール、メタンガス、バイオチップ、熱排水、地熱温水、金属屑等を含んでもよい。明細書または請求項に記載の「環境負荷財」は、廃棄物と汚染物質等の総称であってもよい。また、「環境負荷財」は、再利用できない廃棄物を含んでもよく、例えば、使用済み天ぷら油、バイオ燃料用のゴミ、アルコール、メタンガス以外の廃棄物を含むものであってもよい。
【０２４７】
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。
【符号の説明】
【０２４８】
１００  融通管理システム、  １０４  融通管理装置、  １２９  交換レート保持部、  １３２  融通実績取得部、  １３４  債権債務記録部、  １３８  評価部、  １４０  評価情報提供部、  １４４  交換レート取得部、  ２１０  交換レート、  ２２０  環境負荷財移転管理システム、  ２２４  環境負荷財移転管理装置。
【産業上の利用可能性】
【０２４９】
本発明は、財の融通または移転を管理するシステムに利用できる。
【図１】
2017030086.tif 000003
【図２】
2017030086.tif 000004
【図３】
2017030086.tif 000005
【図４（ａ）】
2017030086.tif 000006
【図４（ｂ）】
2017030086.tif 000007
【図５】
2017030086.tif 000008
【図６（ａ）】
2017030086.tif 000009
【図６（ｂ）】
2017030086.tif 000010
【図７】
2017030086.tif 000011
【図８】
2017030086.tif 000012
【図９】
2017030086.tif 000013
【図１０】
2017030086.tif 000014
【図１１】
2017030086.tif 000015
【図１２】
2017030086.tif 000016
【図１３】
2017030086.tif 000017
【図１４】
2017030086.tif 000018
【図１５】
2017030086.tif 000019
【図１６】
2017030086.tif 000020
【図１７】
2017030086.tif 000021
【図１８】
2017030086.tif 000022
【国際調査報告】
2017030086.tif 000023
2017030086.tif 000024
2017030086.tif 000025
2017030086.tif 000026