JP2020024697A - 情報処理装置 - Google Patents

Abstract

【課題】古民家や、古民家の解体の際に派生する柱や梁といった古材を「手放したい」と思っている者と、「活用したい」と思っている者とを効率よくマッチングさせる情報処理装置を提供する。【解決手段】古民家又は古材を手放すことを希望する古民家又は古材の所有者と、古民家又は古材を活用することを希望する活用者とを支援するサーバ１において、古民家取得部１１１、及び古材取得部１１２の夫々は、所有者により提示された、古民家情報及び古材情報の夫々を取得する。リクエスト取得部１１３は、活用者により提示された、古民家又は古材の特徴に関するリクエスト情報を取得する。抽出部１０３は、リクエスト情報に含まれる、古民家又は古材の特徴に関するリクエストの内容と一致又は近似する古民家又は古材を示す情報を、古民家情報又は古材情報から抽出する。【選択図】図５

Description

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

従来より、建造から相当な年数が経過している古民家をリフォームすることで、住宅資源を有効活用する技術は既に提案されている（例えば、特許文献１参照）。

特開２００８−５９５３９号公報

しかしながら、特許文献１に記載された技術を含め従来の技術では、古民家や、古民家の解体の際に派生する柱や梁といった古材を「手放したい」と思っている者と、「活用したい」と思っている者とをマッチングさせることについては、何ら検討がなされていない。

本発明は、このような状況に鑑みてなされたものであり、古民家や、古民家の解体の際に派生する柱や梁といった古材を「手放したい」と思っている者と、「活用したい」と思っている者とを効率よくマッチングさせることを目的とする。

上記目的を達成するために、本発明の一態様の情報処理装置は、
物品を手放すことを希望する前記物品の所有者と、前記物品を活用することを希望する活用者とを支援する情報処理装置であって、
前記所有者により提示された、前記物品に関する第１情報を取得する第１取得手段と、
前記活用者により提示された、前記物品の特徴に関するリクエストを示す第２情報を取得する第２取得手段と、
前記第２情報に含まれる前記特徴に関するリクエストの内容と一致又は近似する物品を示す情報を、前記第１情報から抽出する抽出手段と、
を備える。

本発明によれば、古民家や、古民家の解体の際に派生する柱や梁といった古材を「手放したい」と思っている者と、「活用したい」と思っている者とを効率よくマッチングさせることができる。

本発明の情報処理装置の第１実施形態に係るサーバを含む、情報処理システムにより実現可能な本サービスの概要を示す図である。 所有者により提示された古民家情報、及び古材情報の夫々を、所定のデータベースに記憶されて管理する手法の具体例を示す図である。 本発明の情報処理装置の一実施形態に係るサーバを含む、情報処理システムの構成を示す図である。 図３に示す情報処理システムのうちサーバのハードウェア構成の一例を示すブロック図である。 図４のサーバを含む情報処理システムの機能的構成のうち、マッチング処理を実行するための機能的構成を示す機能ブロック図である。 図５の機能的構成を有するサーバにより記憶されて管理される古民家情報の具体例を示す図である。 図５の機能的構成を有するサーバにより記憶されて管理される古材情報の具体例を示す図である。 本発明の情報処理装置の第２実施形態に係るサーバを含む、情報処理システムの構成を示す図である。 図８のサーバを含む情報処理システムの機能的構成のうち、古材管理処理を実行するための機能的構成を示す機能ブロック図である。 図９の古材ＤＢに記憶されている古材識別情報、及び古材識別情報に対応付けられている各種情報の具体例を示す図である。

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

［第１実施形態］
まず、図１及び図２を参照して、本発明の情報処理装置が適用される情報処理システム（後述する図３参照）の適用対象となるサービス（以下、「本サービス」と呼ぶ）の概要について説明する。

図１は、本発明の情報処理装置の第１実施形態に係るサーバを含む、情報処理システムにより実現可能な本サービスの概要を示す図である。

図１には、サービス提供者Ｇと、サービス提供者Ｇにより管理されるサーバ１と、所有者Ｓと、所有者Ｓにより操作される所有者端末２と、活用者Ｒにより操作される活用者端末３とが描画されている。

本サービスは、サービス提供者Ｇから所有者Ｓ及び活用者Ｒに対して提供されるサービスの一例である。
本サービスにおいて、「所有者Ｓ」とは、建造から相当な年数（例えば数十年乃至百年以上）が経過している古い家屋Ｋ（以下、「古民家Ｋ」と呼ぶ）を所有する者（個人、又は法人等の団体）のことをいう。所有者Ｓには、自身が保有する古民家Ｋを諸々の事情により手放したいと考えている者が含まれる。

本サービスにおいて、「活用者Ｒ」とは、古民家Ｋ、又は後述する「古材Ｗ」を活用したいと望む者（個人、又は法人等の団体）のことをいう。活用者Ｒには、古民家Ｋ又は古材Ｗを販売する者（例えば加盟店、販売店等）、古民家Ｋ、又は古材Ｗを再利用した家屋や家財のデザインを行う者（例えばデザイン事務所等）、古民家Ｋ、又は古材Ｗを再利用した家屋や家財を用いて、各種の商品やサービスの提供を行う事業者（例えば店舗、旅館等）、古民家Ｋや古材Ｗをテーマとした記事や話題等を提供する者（例えばメディア等）、及びエンドユーザ等が含まれる。

本サービスにおいて、「古材Ｗ」とは、例えば、古民家Ｋの柱や梁等の用途に使用されていた古い材料等である。この古材Ｗは、人々の想いや愛着が込められた上質な材料である場合も多く、また、古材Ｗが使用されていた履歴や歴史等が明確に記録されているような場合もある。

一般的に、建築物については、新しければ新しいほど価値が高いとされることが多い。ただし、木造の建築物、及び木造の建築物を構成している木材の再利用や移築の分野においては、導入先の場所や状況、利用する人によっては、その古さに付加価値が見出される場合もある。
即ち、木材の煤け具合や刻まれた傷等が、かえって趣を感じさせる要因となり、そのような木材（即ち古材Ｗ）の再利用先（例えば、住居、店舗等）では、「味（味わい）」のある佇まいが醸し出され、再利用先の魅力を向上させることがある。

古材Ｗの「味（味わい）」とは、古材Ｗの外観の特徴に関するものであり、人に対して何らかの趣を感じさせ得る物品の様子のことをいう。「外観の特徴」とは、風合いや、外観から受ける感じ、又は手触りといったものであり、人間の五感のうち視覚及び触覚の少なくとも一方より得られる、物品の印象に関わる特徴のことをいう。
具体的には、古材Ｗの「味（味わい）」には、古材Ｗの煤け具合（例えば煤けの有無、ある場合はその割合やその位置等）、色、ほぞ穴に関するもの（例えば数や位置等）、傷に関するもの（例えば数や位置等）、模様に関するもの（例えば数や位置等）、木材が棒状である場合は曲がり具合、表面の状態（例えばざらざら感、すべすべ感等の質感）等、といったものが含まれる。
本サービスでは、この「味（味わい）」と「ストーリー」とを古材Ｗ毎に管理する。これにより、古材Ｗを活用したいとする活用者Ｒに対して、より満足感を与える古材Ｗを提供することができる。

古材Ｗには、既に単体として存在する古材Ｗａ１乃至Ｗａｎ（ｎは１以上の整数値）と、古民家Ｋ１乃至Ｋｂ（ｂは１以上の整数値）を解体した際に派生し得る古材候補Ｗｋ１乃至Ｗｋｍ（ｍは１以上の整数値）とが含まれる。
以下、古材Ｗａ１乃至Ｗａｎ、及び古材候補Ｗｋ１乃至Ｗｋｍの夫々を個々に区別する必要がない場合、これらをまとめて、「古材Ｗａ」及び「古材候補Ｗｋ」の夫々と呼ぶ。またさらに、古材Ｗａ及び古材候補Ｗｋの夫々を個々に区別する必要がない場合、これらをまとめて「古材Ｗ」の夫々と呼ぶ。

所有者Ｓ及び活用者Ｒの夫々は、本サービスの利用者向けの専用のアプリケーションソフトウェア（以下、「専用アプリ」と呼ぶ）がインストールされた所有者端末２及び活用者端末３の夫々を用いて本サービスを利用する。
なお、以下、断りのない限り、「所有者Ｓが所有者端末２を操作する」と表現している場合、それは、所有者Ｓが、所有者端末２にインストールされた専用アプリを起動して各種操作を行うことを意味している。また、同様に、「活用者Ｒが活用者端末３を操作する」と表現している場合、それは、活用者Ｒが、活用者端末３にインストールされた専用アプリを起動して各種操作を行うことを意味している。

本サービスにおいて、所有者Ｓは、古民家情報又は古材情報の夫々を提示する（ステップＳＳ１及びＳＳ２）。
具体的には、所有者Ｓは、所有者端末２を操作することにより、自身が所有する古民家Ｋ又は古材Ｗの夫々に関する情報を、古民家情報又は古材情報の夫々としてサービス提供者Ｇに提示する。
古民家情報にどのような情報が含まれるかは特に限定されない。例えば古民家Ｋ１乃至Ｋｂの夫々を一意に識別可能な古民家ＩＤ等の情報が含まれる。
また、古材情報にどのような情報が含まれるかは特に限定されない。例えば古材Ｗａ１乃至Ｗａｎ、及び古材候補Ｗｋ１乃至Ｗｋｍの夫々を一意に識別可能な古材ＩＤ等の情報が含まれる。
なお、古民家情報及び古材情報の夫々に含まれる情報の具体例については、図６及び図７の夫々を参照して後述する。

活用者Ｒは、リクエスト情報を提示する（ステップＳＳ３）。
具体的には、活用者Ｒは、活用者端末３を操作することにより、自身が所望する古民家Ｋや古材Ｗの少なくとも一方の特徴に関するリクエストを示す情報を、リクエスト情報としてサービス提供者Ｇに提示する。
活用者Ｒにより提示されるリクエスト情報には、例えば「根本の部分が湾曲している梁が欲しい」といったリクエストを示す情報が含まれる。

サービス提供者Ｇは、提示された古民家情報、古材情報、及びリクエスト情報の夫々を本サービスに登録する（ステップＳＳ４）。
具体的には、サーバ１は、提示された古民家情報、古材情報、及びリクエスト情報の夫々を、所定のデータベース（例えば後述する図４の古民家ＤＢ１８１、及びＫＤＢ１８２）に夫々記憶させて管理する。

サービス提供者Ｇは、登録されている古民家情報、古材情報、及びリクエスト情報に基づいて、所有者Ｓの「手放したい」という要望と、活用者Ｒの「活用したい」という要望とのマッチングを行う（ステップＳＳ５）。
具体的には例えば、活用者Ｒのリクエスト情報に「根本の部分が湾曲している梁が欲しい」というリクエストを示す情報が含まれているケースを想定する。このケースにおいて、サーバ１は、所有者Ｓの古材情報に「根本の部分が湾曲している梁」と一致又は近似する古材Ｗが存在する場合には、その古材Ｗの古材情報を抽出する。
また例えば、活用者Ｒのリクエスト情報に「刀傷がある１５０年以上前の柱」というリクエストを示す情報が含まれているケースを想定する。このケースにおいて、サーバ１は、所有者Ｓの古材情報に「刀傷がある柱」と、「１５０年以上経過している柱」という２つの特徴が一致又は近似する古材Ｗが存在する場合には、その古材Ｗの古材情報を抽出する。

リクエスト情報の内容と一致又は近似する古材Ｗがデータベースから抽出された場合、サービス提供者Ｇは、その抽出結果をマッチング結果として活用者Ｒ及び所有者Ｓに提示する（ステップＳＳ６）。
具体的には、活用者端末３により提示されたリクエスト情報と一致又は近似する古材Ｗがデータベースから抽出された場合、サーバ１は、その抽出結果をマッチング結果として活用者端末３及び所有者端末２に提示する。

本サービスによれば、所有者Ｓは、自身が所有する古民家Ｋ又は古材Ｗに関する情報を、古民家情報又は古材情報として予め登録しておくだけで、自ら販売先を探すことなく、販売先になり得る活用者Ｒを見つけてもらうことができる。
この場合、販売先になり得る活用者Ｒは、当然ながら所有者Ｓの古民家Ｋ又は古材Ｗを手に入れたい立場になるため、所有者Ｓは有利な条件で古民家Ｋ又は古材Ｗを売却することが可能となる。
なお、古民家情報及び古材情報が本サービスに登録される段階では、所有者Ｓに古民家Ｋ又は古材Ｗを手放す意思は必要とならない。即ち、所有者Ｓは、古民家情報又は古材情報を本サービスに登録し、その後、所有者Ｓにとって有利な条件の引き合いが出てきたタイミングで、改めて売却の有無を再検討すればよい。つまり、本サービスへの登録の時点で明確な売却の意思がない所有者Ｓであっても、気軽に本サービスを利用することができる。
これにより、サービス提供者Ｇは、本サービスの利用者数を増加させることができる。また、それとともに、データベースの充実化を図ることができる。

また、活用者Ｒは、リクエスト情報を提示するだけで、自身が所望する古民家Ｋや古材Ｗを所有する所有者Ｓを見つけてもらうことができる。
また、活用者Ｒは、自身が所望するイメージにマッチする古民家Ｋや古材Ｗを容易に検索して参照することもできる。

従来より、古民家Ｋ及び古材Ｗの分野では、マーケットが確立されていなかったため、取引の相手方を見つける場合、知人からの紹介や、偶然の出会い等に頼らざるを得なかった。
ただし、本サービスによれば、古民家Ｋや古材Ｗを「手放したい」という所有者Ｓの要望と、古民家Ｋや古材Ｗを「活用したい」という活用者Ｒの要望とを容易にマッチングさせることができる。

また、図示はしないが、活用者Ｒが所望する古材Ｗを入手し、実際に古材Ｗを活用した場合には、その感想を提示することもできる。
具体的には例えば、活用者Ｒが活用者端末３を操作することで、自身が活用した古材Ｗについてのコメントを入力したり、いわゆる「いいね」と表記されたボタン（以下、「いいねボタン」と呼ぶ）を押下したりすることができる。そして、活用者Ｒにより提示された感想（コメントの内容や「いいねボタン」が押下された数）は、古材情報としてＫＤＢ１８２に記憶されて管理される。
これにより、例えば「いいねボタン」を押下した活用者Ｒに対しては、サービス提供者ＧからＤＭ（ダイレクトメール）が自動的に送信されるようにすることができる。例えば活用開始から１０年が経過している繁盛店の古材Ｗと、活用開始から未だ３年が経過したに過ぎない通常店舗の古材Ｗとの「いいねボタン」の押下数を比較した場合を想定する。この場合、例えば繁盛店の古材Ｗに対する「いいねボタン」の押下数が１０万回であり、通常店舗の古材Ｗに対する「いいねボタン」の押下数が３０００回であれば、繁盛店の古材Ｗの方が通常店舗の古材Ｗよりも「価値がある」と判断することもできる。
また、活用者Ｒは、古材情報を参照することで楽しむこともできるし、所望する古材Ｗがデータベースに登録された場合に通知してもらうこともできる。

上述したように、本サービスでは、所有者Ｓにより提示された古民家情報、及び古材情報の夫々が、所定のデータベースに記憶されて管理されるが、具体的には例えば，図２に示す手法によって管理される。
図２は、所有者により提示された古民家情報、及び古材情報の夫々を、所定のデータベースに記憶されて管理する手法の具体例を示す図である。

図２（Ａ）には、古材Ｗａ１及びＷａ２の夫々を示す古材情報が、所定のデータベースに記憶されるイメージが示されている。
古材Ｗａ１及びＷａ２は、いずれも過去に古民家Ｋの一部を構成していた、又は古民家Ｋの一部を構成する予定であった古材Ｗである。このため、古材Ｗａ１及びＷａ２の夫々を示す古材情報は、古民家Ｋを示す古民家情報に帰属させることなく、夫々単体で所定のデータベース（図４のＫＤＢ１８２）に記憶される。
なお、古材情報にどのような情報が含まれ得るのかについては、図７を参照して後述する。

図２（Ｂ）には、古民家Ｋ１と、古民家Ｋ１を構成する古材候補Ｗｋ１乃至Ｗｋｐ（ｐは１以上ｍ以下の整数値）との夫々を示す、古民家情報と古材情報との夫々が、所定のデータベースに記憶されるイメージが示されている。
古民家Ｋ１を示す古民家情報は、古民家単位で所定のデータベース（図４の古民家ＤＢ１８１）に記憶される。
なお、古民家情報にどのような情報が含まれ得るのかについては、図６を参照して後述する。

古民家Ｋ１を構成する１以上の柱や梁等は、いずれも将来的に古材Ｗａとしてマーケットで流通され得る古材候補Ｗｋ１乃至Ｗｋｐとして、古材単位でデータベースに夫々記憶される。具体的には、古材候補Ｗｋ１乃至Ｗｋｐの夫々を示す古材情報が所定のデータベース（図２のＫＤＢ１８２）に記憶される。
なお、古材情報にどのような情報が含まれ得るのかについては、図７を参照して後述する。

このように、所有者Ｓから提示された、古民家Ｋを示す古民家情報と、古材Ｗを示す古材情報との夫々は、所定のデータベース（図２の古民家ＤＢ１８１、ＫＤＢ１８２）に記憶されて適切に管理される。
このため、本サービスでは、所定のデータベースにおいて適切に記憶され管理されている古民家情報及び古材情報に裏付けられた、適切なサービスを実現される。

次に、図３を参照して、上述した本サービスの提供を実現化させる情報処理システム、即ち本発明の情報処理装置の一実施形態に係るサーバ１を含む、情報処理システムの構成について説明する。
図３は、本発明の情報処理装置の一実施形態に係るサーバを含む、情報処理システムの構成を示す図である。

図３に示す情報処理システムは、サーバ１と、所有者端末２−１乃至２−ｒ（ｒは１以上の整数値）と、活用者端末３−１乃至３−ｔ（ｔは１以上の整数値）とを含むように構成されている。
サーバ１、所有者端末２−１乃至２−ｒ、及び活用者端末３−１乃至３−ｔの夫々は、インターネット等の所定のネットワークＮを介して相互に接続されている。

サーバ１は、所有者端末２−１乃至２−ｒ、及び活用者端末３−１乃至３−ｔの夫々と適宜通信をしながら、本サービスを実現するための各種処理を実行する。

所有者端末２−１乃至２−ｒ、及び活用者端末３−１乃至３−ｔの夫々は、例えばパーソナルコンピュータ、スマートフォン、タブレット等で構成される。
以下、所有者端末２−１乃至２−ｒ、及び活用者端末３−１乃至３−ｔの夫々を個々に区別する必要がない場合、これらをまとめて、「所有者端末２」、及び「活用者端末３」の夫々と呼ぶ。

図４は、図３に示す情報処理システムのうちサーバのハードウェア構成の一例を示すブロック図である。

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

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

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

入力部１６は、例えばキーボード等により構成され、各種情報を出力する。
出力部１７は、液晶等のディスプレイやスピーカ等により構成され、各種情報を画像や音声として出力する。
記憶部１８は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部１９は、インターネットを含むネットワークＮを介して他の装置（例えば図２の所有者端末２、及び活用者端末３等）との間で通信を行う。

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

なお、図示はしないが、図３の所有者端末２、及び活用者端末３も、図４に示すハードウェア構成と基本的に同様の構成を有することができる。従って、所有者端末２及び活用者端末３のハードウェア構成の説明については省略する。

このような図４のサーバ１の各種ハードウェアと各種ソフトウェアとの協働により、サーバ１におけるマッチング処理を含む各種処理の実行が可能になる。その結果、サービス提供者Ｇは、所有者Ｓ及び活用者Ｒに対し、上述の本サービスを提供することができる。
「マッチング処理」とは、上述の本サービスを提供するために実行される処理のことをいう。
以下、サーバ１において実行される、マッチング処理を実行するための機能的構成について説明する。

図５は、図４のサーバを含む情報処理システムの機能的構成のうち、マッチング処理を実行するための機能的構成を示す機能ブロック図である。

図５に示すように、サーバ１のＣＰＵ１１においては、マッチング処理の実行が制御される場合、取得部１０１と、管理部１０２と、抽出部１０３と、提示部１０４とが機能する。
また、サーバ１の記憶部１８の一領域には、古民家ＤＢ１８１と、ＫＤＢ１８２と、所有者ＤＢ１８３と、活用者ＤＢ１８４とが設けられている。

取得部１０１は、各種情報を取得する。取得部１０１では、古民家取得部１１１と、古材取得部１１２と、リクエスト取得部１１３とが機能する。

古民家取得部１１１は、所有者Ｓにより提示された、売却を希望する古民家Ｋに関する情報を、古民家情報として取得する。
具体的には、図５の例では、古民家取得部１１１は、所有者Ｓ１乃至Ｓｒの夫々により提示された、売却を希望する古民家Ｋ１乃至Ｋｂの夫々に関する情報を、古民家情報として夫々取得する。
なお、古民家情報にどのような情報が含まれるかは特に限定されない。例えば古民家Ｋ１乃至Ｋｂの夫々を一意に識別可能な古民家ＩＤ等の情報が含まれる。なお、古民家情報に含まれる情報の具体例については、図６を参照して後述する。

古材取得部１１２は、所有者Ｓにより提示された、売却を希望する古材Ｗに関する情報を、古民家情報として取得する。
具体的には、古材取得部１１２は、所有者Ｓ１乃至Ｓｒの夫々により提示された、売却を希望する古材Ｗａ１乃至Ｗａｎの夫々に関する情報を、古材情報として夫々取得する。
また、古材取得部１１２は、所有者Ｓ１乃至Ｓｒの夫々により提示された、売却を希望する古民家Ｋを解体した際に派生し得る古材候補Ｗｋ１乃至Ｗｋｍの夫々に関する情報を、古材候補情報として夫々取得する。
なお、古民家情報にどのような情報が含まれるかは特に限定されない。例えば古民家Ｋ１乃至Ｋｂの夫々を一意に識別可能な古民家ＩＤ等の情報が含まれる。なお、古民家情報に含まれる情報の具体例については、図６を参照して後述する。

リクエスト取得部１１３は、活用者Ｒにより提示された、購入を希望する古民家Ｋ又は古材Ｗのリクエスト情報を取得する。
具体的には例えば、リクエスト取得部１１３は、古材Ｗのリクエスト情報として、例えば「根本の部分が湾曲している梁」、「幕末の動乱時の刀傷が残された柱」といったリクエストを示す情報を取得する。

管理部１０２は、取得部１０１により取得された情報を含む各種情報を所定のデータベースに記憶させて管理する。
具体的には、管理部１０２は、古民家取得部１１１により取得された古民家情報を古民家ＤＢ１８１に記憶させて管理する。
上述したように、古民家情報にどのような情報が含まれるかは特に限定されない。例えば古民家Ｋ１乃至Ｋｂの夫々を一意に識別可能な古民家ＩＤ等の情報が含まれる。なお、古民家情報に含まれる情報の具体例については、図６を参照して後述する。

また、管理部１０２は、古材取得部１１２により取得された古材情報をＫＤＢ１８２に記憶させて管理する。
また、古材情報にどのような情報が含まれるかは特に限定されない。例えば古材Ｗａ１乃至Ｗａｎ、及び古材候補Ｗｋ１乃至Ｗｋｍの夫々を一意に識別可能な古材ＩＤ等の情報が含まれる。なお、古材情報に含まれる情報の具体例については、図７を参照して後述する。

また、管理部１０２は、所有者Ｓ１乃至Ｓｒの夫々に関する情報を所有者情報として所有者ＤＢ１８３に記憶させて管理する。
なお、所有者情報にどのような情報が含まれるかは特に限定されない。例えば所有者Ｓ１乃至Ｓｒの夫々を一意に識別可能な所有者ＩＤ等の情報が含まれる。

また、管理部１０２は、活用者Ｒ１乃至Ｒｔの夫々に関する情報を活用者情報として活用者ＤＢ１８４に記憶させて管理する。
なお、活用者情報にどのような情報が含まれるかは特に限定されない。例えば活用者Ｒ１乃至Ｒｔの夫々を一意に識別可能な活用者ＩＤ等の情報が含まれる。

抽出部１０３は、リクエスト情報に含まれる古民家Ｋ又は古材Ｗの夫々の特徴に関するリクエストの内容と一致又は近似する古民家Ｋ又は古材Ｗを示す情報を、古民家情報又は古材情報から抽出する。

提示部１０４は、抽出部１０３により抽出された、古民家Ｋ又は古材Ｗを示す情報を、マッチング結果として所有者及び活用者に提示する。
具体的には、提示部１０４は、抽出部１０３により抽出された、古民家Ｋ又は古材Ｗを示す情報を、マッチング結果として所有者端末２及び活用者端末３に提示する。

図６は、図５の機能的構成を有するサーバにより記憶されて管理される古民家情報の具体例を示す図である。

サーバ１の古民家ＤＢ１８１に記憶されて管理される古民家情報は、１以上の特徴により古民家毎に管理される。
具体的には例えば、図６の例では、古民家情報は、古民家ＩＤ、建物面積（延べ面積）、築年数、種類（例えば「蔵」、「町家」等）、階数、構成要素となる古材Ｗの古材ＩＤ、金額、図面や撮像画像（例えば６面図、３６０°撮像画像）へのリンクボタン、及び経歴等の特徴により古民家Ｋ毎に管理される。このうち「経歴」には、ストーリーを有する１以上の古民家Ｋ夫々にまつわるエピソードや特性として、誰がどのように関係した（している）のかといった人的な情報等の各種情報が含まれる。

図６には、古民家情報の一例として、古民家ＩＤが「Ａ」、建物面積（延べ面積）が「５５坪」、築年数が「８９年」、種類が「町家」、階数が「１階」、構成要素となる古材Ｗの古材ＩＤが「Ａ−ａ乃至Ａ−ｃ」、金額が「ＸＸ万円」、図面や撮像画像（例えば６面図、３６０°撮像画像）へのリンクボタンが「ｈｔｔｐｓ：／／・・・」、及び経歴が「夫婦で営んできた蕎麦屋」である古民家Ｋと、古民家ＩＤが「Ｂ」、建物面積（延べ面積）が「３０坪」、築年数が「１６０年」、種類が「町家」、階数が「２階」、構成要素となる古材Ｗの古材ＩＤが「Ｂ−ａ乃至Ｂ−ｃ」、金額が「ＸＸ万円」、図面や撮像画像（例えば６面図、３６０°撮像画像）へのリンクボタンが「ｈｔｔｐｓ：／／・・・」、及び経歴が「明治維新の志士である〇〇の隠れ家としても使用された旅籠」である古民家Ｋとの夫々が示されている。

図７は、図５の機能的構成を有するサーバにより記憶されて管理される古材情報の具体例を示す図である。

サーバ１のＫＤＢ１８２に記憶されて管理される古材情報は、１以上の特徴により定義され、古材Ｗ毎に管理される。
具体的には例えば、図７の例では、古材情報は、古材ＩＤ、古材単体ｏｒ古材候補、帰属する古民家ＩＤ、樹種、長さ、体積、色味（数値化も可能）、全体形状、金額（体積に基づいて算出）、図面や撮像画像（例えば６面図、３６０°撮像画像）へのリンクボタン、及び経歴等の特徴により定義され、古民家Ｋ毎に管理される。また、図示はしないが、元口の形状、元口の面積、末口の形状、末口の面積、太さ、傷の有無、状態等も古材Ｗの特徴とされて管理される。
古材情報を定義する１以上の特徴このうち「経歴」には、ストーリーを有する１以上の古材Ｗの夫々にまつわるエピソード（例えば人的なエピソード等）、特性、古民家Ｋのどの部分に使用されていた、又は使用されている古材Ｗなのかといった情報が含まれる。
ここで、色味（数値化も可能）とは、具体的に例えば、古材Ｗの色味は多くの場合、茶色等の色に分類され単に色を表記したのみでは実際の古材Ｗの色を判断するのが困難な場合がある。このような場合、例えば、単に色味の情報を格納するのではなく、例えば、濃い茶色や薄い茶色といった色の濃淡や輝度を数値化した情報等を合わせて取得してもよい。

図７には、古材情報の一例が示されている。例えば「古材ＩＤ」を「ａ」とする古材Ｗａは、「帰属する古民家」は「なし」、「樹種」が「松」、「長さ」が「１．０ｍ」、「体積」が「ＸＸＸｍ^３」、「色味」が「茶」、「全体形状」が「真っすぐ」、金額が「ＸＸ万円」、図面や撮像画像（例えば６面図、３６０°撮像画像）へのリンクボタンが「ｈｔｔｐｓ：／／・・・」、及び「経歴」が「民家の壁の一部」である古材Ｗａである。
また例えば、「古材ＩＤ」を「ｂ」とする古材Ｗａは、「帰属する古民家」は「なし」、「樹種」が「松」、「長さ」が「１．５ｍ」、「体積」が「ＸＸＸｍ^３」、「色味」が「茶」、「全体形状」が「真っすぐ」、金額が「ＸＸ万円」、図面や撮像画像（例えば６面図、３６０°撮像画像）へのリンクボタンが「ｈｔｔｐｓ：／／・・・」、及び「経歴」が「民家の天井の一部」である古材Ｗａである。
また例えば、「古材ＩＤ」を「Ａ−ａ」とする古材候補Ｗｋは、「帰属する古民家」の古民家ＩＤが「Ａ」、「樹種」が「欅」、「長さ」が「１．０ｍ」、「体積」が「ＸＸＸｍ^３」、「色味」が「焦茶」、「全体形状」が「真っすぐ」、金額が「ＸＸ万円」、図面や撮像画像（例えば６面図、３６０°撮像画像）へのリンクボタンが「ｈｔｔｐｓ：／／・・・」、及び「経歴」が「夫婦で営んできた蕎麦屋の屋根の一部」である古材候補Ｗｋである。
また例えば、「古材ＩＤ」を「Ａ−ｂ」とする古材候補Ｗｋは、「帰属する古民家」の古民家ＩＤが「Ａ」、「樹種」が「欅」、「長さ」が「５．０ｍ」、「体積」が「ＸＸＸｍ^３」、「色味」が「茶」、「全体形状」が「根元から湾曲」、金額が「ＸＸ万円」、図面や撮像画像（例えば６面図、３６０°撮像画像）へのリンクボタンが「ｈｔｔｐｓ：／／・・・」、及び「経歴」が「夫婦で営んできた蕎麦屋の梁」である古材候補Ｗｋである。
また例えば、「古材ＩＤ」を「Ａ−ｃ」とする古材候補Ｗｋは、「帰属する古民家」の古民家ＩＤが「Ａ」、「樹種」が「欅」、「長さ」が「３．５ｍ」、「体積」が「ＸＸＸｍ^３」、「色味」が「焦茶」、「全体形状」が「真っすぐ」、金額が「ＸＸ万円」、図面や撮像画像（例えば６面図、３６０°撮像画像）へのリンクボタンが「ｈｔｔｐｓ：／／・・・」、及び「経歴」が「夫婦で営んできた蕎麦屋の大黒柱」である古材候補Ｗｋである。
なお、図７に示すＫＤＢ１８２の項目には、例えば後述の第２実施形態における図１０に示すＫＤＢ１８２の項目が含めることもできる。

このように、図６に示す古民家情報と、図７に示す古材情報との夫々は、サーバ１において、古民家ＤＢ１８１と、ＫＤＢ１８２との夫々に記憶され、管理部１０２により管理される。
これにより、古民家Ｋ１乃至Ｋｂと、古民家Ｋ１乃至Ｋｂの解体に伴い派生し得る古材候補Ｗｋ１乃至Ｗｋｍと、既に単独で存在する古材Ｗａ１乃至日Ｗａｎとの夫々は、サーバ１において個々に管理されることが可能になる。
そして、活用者Ｒ１乃至Ｒｔの夫々により提示されたリクエスト情報の内容にマッチする古民家Ｋ又は古材Ｗの夫々を示す情報が、古民家ＤＢ１８１又はＫＤＢ１８２から抽出される。
これにより、古民家Ｋや、古民家Ｋを解体する際に派生する柱や梁といった古材Ｗを、「手放したい」と思っている所有者Ｓと、「活用したい」と思っている活用者Ｒとのマッチングを実現させることができる。

また、解体前の古民家Ｋの段階から古材Ｗ単位で管理することができるため、以下のような効果を奏する。即ち、解体後の取り扱い（例えば使用場所の特定、配送等）が容易となる。また、所有者Ｓの立場からすれば、古材Ｗの潜在的な在庫を古民家Ｋというかたちで保有していることを活用者Ｒにアピールすることができる。

また、古民家Ｋ及び古材Ｗの夫々の古民家情報及び古材情報の夫々は、本サービスに登録された後もトレーサビリティが確保される。
即ち、どこの森で誰によって切り出され、誰によって加工されたのかといった情報のみならず、登録後に転々流通された場合であっても、個々の取引に関する情報（例えば取引価格）や、修理や損傷に伴う価値の上昇又は下降に関する情報もつぶさにログとして記録され続ける。つまり、個々の古材Ｗが持つヒストリーが、過去は勿論、将来にわたっても、継続的に記録される。
その結果、古民家Ｋ及び古材Ｗの経歴の透明性、及び信憑性が確保されるので、所有者Ｓ及び活用者Ｒは、価格の根拠等を容易に把握することができる。また、サービス提供者Ｇは、本サービスの取引における市場価格に対する所有者Ｓ及び活用者Ｒからの信頼性を獲得することができる。
これにより例えば、ストーリーのある古材Ｗを店舗内に用いたレストラン、ホテル等は、そのことを宣伝材料の１つにしたり、古材Ｗ自体を象徴にしたりすることもできる。サービス提供者Ｇは、古材Ｗを題材としたガイドブック等を作成することもできる。

［第２実施形態］
上述したように、本発明の情報処理装置の第１実施形態に係るサーバ１において、古民家Ｋ１乃至Ｋｂ、古材候補Ｗｋ１乃至Ｗｋｍ、及び古材Ｗａ１乃至Ｗａｎの夫々は管理部１０２によって個々に管理される。
具体的には、管理部１０２は、古民家Ｋ１乃至Ｋｂの夫々を、古民家ＤＢ１８１に記憶させて、古民家ＩＤをキーとして管理する。また、管理部１０２は、古材候補Ｗｋ１乃至Ｗｋｍ、及び古材Ｗａ１乃至Ｗａｎの夫々を、ＫＤＢ１８２に記憶させて、古材ＩＤをキーとして管理する。
即ち、上述の第１実施形態では、古民家情報と古材情報とを効率よく管理することで、古民家Ｋ又は古材Ｗを「手放したい」と考える所有者Ｓと、「活用したい」と考える活用者Ｒとをマッチングさせる手法について説明した。
第２実施形態では、実物としての古材Ｗ（古材Ｗａ及び古材候補Ｗｋ）を効率よく管理する手法について説明する。

複数の商品の種類が同一である場合には、同質又は略同質である商品と、同質又は略同質ではない商品とに分けて管理されるのが一般的である。
同質又は略同質である商品には、例えば、書籍、飲料水、加工食品、新品で販売される衣服、家具、自動車、家電、コンピュータ等の量産品が含まれる。

これに対して、同質又は略同質ではない商品としては、例えば、木材、香木、模造刀等の刀剣、ペルシャ絨毯、ビンテージデニム、骨董品等の一品制作的な商品が含まれる。
同質又は略同質ではない商品は個々の特徴が異なるため、取引される価値も異なる。このため、個々の特徴を含む詳細な在庫管理が必要になる。
同質又は略同質ではない商品のうち「木材」を管理する従来からある手法としては、例えば個々の木材の表面にシリアルナンバー等の識別情報を直接刻印して管理する手法がある。

しかしながら、従来からある手法では、個々の木材に対し視覚を通じて識別可能なシリアルナンバー等を付す。このため、多くの木材を管理する場合には、所望の木材を見つけるために、シリアルナンバー等を１つ１つ確認しなければならなかった。
また、木材は、一見しただけではその違いを把握し難い。このため、同じような木材が積み重なった状態で多数並んでいる場合には、シリアルナンバー等を読み飛ばしてしまうことや、同じシリアルナンバー等を重複して読み取ってしまうことがあった。

このような問題の解決策としては、管理リスト等を用いて木材の配置場所を管理する手法が考えられる。
しかしながら、倉庫内に保管されている木材は、追加と搬出とが頻繁に繰り返えされるため、木材の配置場所も刻一刻と変わる性質を有するため、木材の配置場所が変わる度に管理リスト等を更新しなければならなくなる。
また、現場担当者が木材の配置場所を間違えたり、配置場所の変更が管理リストに反映されていなかったりする人的なミスが生じるおそれもある。一度ミスが生じると、管理リスト自体の信頼性が失墜してしまうため、結果的にシリアルナンバー等を１つ１つ確認しなければならないという事態に陥ることになりかねない。
さらに、古材候補Ｗｋは、未だ古民家Ｋを構成している状態であるため、倉庫のような場所に一か所に集積させて管理することができない。

そこで、本サービスによれば、同一種類の商品（例えば古材Ｗ）の夫々が個性を有するため、個別に管理する必要がある場合であっても、容易に管理することが可能になる。

本サービスにおいて管理の対象となり得る物品としては、同一の種類でありながらも、同質又は略同質とはならない物品であることが好ましい。さらに好ましくは、人間の五感のうち物品そのものの価値を変え得る「視覚」及び「触覚」の少なくとも一方に属する要素（例えば、味（味わい））を有する物品である。このような物品の一例が「古材Ｗ」である。

本サービスは、サービス提供者Ｇが、ＲＦＩＤ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）技術を用いて、１以上の古材Ｗの夫々を効率よく管理できるようにするサービスである。 具体的には、サービス提供者Ｇは、サービス提供者端末４（図８）を操作して、古材Ｗ毎に付されているＲＦＩＤタグに記憶された情報を読み取ることで、古材Ｗを一意に識別することができる。

古材Ｗに付されるＲＦＩＤタグの具体的態様は特に限定されないが、例えばパッシブ型のＩＣタグを採用することができる。この場合、リーダライタ機能を有するサービス提供者端末４（図８）からの電波（即ちパッシブ型のＲＦＩＤタグを起電させるための電波）をエネルギー源として動作するので、電源を内蔵させる必要がない。
ＲＦＩＤタグは、サービス提供者端末４（図８）から送信される電波を受信すると、予め記憶している、古材Ｗを一意に識別可能な情報（以下、「古材識別情報」と呼ぶ）で変調された電波を発信する。
ＲＦＩＤタグは、古材Ｗ毎に付されるが、古材ＷにＲＦＩＤタグを付す具体的手法は特に限定されない。例えば古材Ｗの表面のわかり易い位置に貼付してもよいし、古材Ｗに設けられたほぞ穴の内側に配置してもよい。

本サービスによれば、経年や作る段階で味要素が変わってきて、その結果価値が変わってくる古材Ｗを容易に特定することができる。また、本サービスによれば、古材Ｗを特定するだけではなく、古材Ｗの「味（味わい）」や「ストーリー」についても管理することができる。

本サービスでは、管理の対象となる物品を古材Ｗとし、既に単体で存在する古材Ｗａ、又は古民家Ｋの解体により派生し得る古材候補Ｗｋを再利用するために管理する。「再利用する」とは、例えば移築や、個々の古材Ｗを活用者Ｒに販売等することをいう。

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

図８に示す情報処理システムは、サーバ１と、サービス提供者端末４とを含むように構成されている。
サーバ１、及びサービス提供者端末４は、インターネット等の所定のネットワークＮを介して相互に接続されている。

サーバ１は、サービス提供者端末４と適宜通信をしながら、本サービスを実現するための各種処理を実行する。

サービス提供者端末４は、例えばパーソナルコンピュータ、スマートフォン、タブレット等で構成される。
サービス提供者Ｇは、専用アプリがインストールされたサービス提供者端末４を用いて本サービスを利用する。
なお、以下、断りのない限り、「サービス提供者Ｇがサービス提供者端末４を操作する」と表現している場合、それは、サービス提供者Ｇが、サービス提供者端末４にインストールされた専用アプリを起動して各種操作を行うことを意味している。

なお、図８に示す情報処理システムを構成するサーバ１、及びサービス提供者端末４のハードウェア構成については、図４に示す第１実施形態のサーバ１のハードウェア構成と基本的に同様の構成を有することができる。従って、本実施形態におけるサーバ１、及びサービス提供者端末４のハードウェア構成の説明については省略する。

このようなサーバ１の各種ハードウェアと各種ソフトウェアとの協働により、サーバ１における古材管理処理を含む各種処理の実行が可能になる。その結果、サービス提供者Ｇは上述の本サービスを提供することができる。
「古材管理処理」とは、上述の本サービスを提供するために実行される処理のことをいう。
以下、サーバ１において実行される、古材管理処理を実行するための機能的構成について説明する。

図９は、図８のサーバを含む情報処理システムの機能的構成のうち、古材管理処理を実行するための機能的構成を示す機能ブロック図である。

図９に示すように、サーバ１のＣＰＵ１１においては、古材管理処理の実行が制御される場合、取得部２０１と、特定部２０２とが機能する。
また、サーバ１の記憶部１８の一領域には、ＫＤＢ１８２が設けられている。ＫＤＢ１８２には、古材識別情報に各種情報が対応付けられて管理されている。

取得部２０１は、サービス提供者端末４により読み取られたＲＦＩＤタグに記憶された古材識別情報を取得する。

特定部２０２は、取得部２０１により取得された古材識別情報に基づいて、ＫＤＢ１８２に記憶されている１以上の古材Ｗのうち、１の古材Ｗを特定する。
なお、ＫＤＢ１８２に記憶されている古材識別情報、及び古材識別情報に対応付けられている各種情報の具体例については、図１０を参照して後述する。

図１０は、図９の古材ＤＢに記憶されている古材識別情報、及び古材識別情報に対応付けられている各種情報の具体例を示す図である。

図１０に示すように、ＫＤＢ１８２には、古材識別情報としてのタグＩＤに、解体日時、解体場所、煤け有無、煤け具合、保管日時、保管場所、保管区域、搬送日時、及び搬送先が対応付けられて記憶されている。
「タグＩＤ」はＲＦＩＤタグのＩＤ（即ち古材Ｗを一意に識別する古材識別情報）、「解体日時」は古民家Ｋを解体した日時、「解体場所」は解体された古民家Ｋが存在していた場所となる。また、「煤け有無」は古材Ｗに煤けがあるか否か、「煤け具合」は煤けがある場合にその存在割合（例えば入力者の目分量）、「保管日時」は古材Ｗの保管を開始した日時、「保管場所」はその保管場所、「保管区域」は古材Ｗが置かれている保管場所内の区域となる。また、「搬送日時」は古材Ｗが活用先（古材Ｗが実際に活用される場所）に向けて搬送された日時、「搬送先」はその搬送先（活用先）となる。
なお、図１０に示すＫＤＢ１８２の項目には、例えば上述の第１実施形態における図７に示すＫＤＢ１８２の項目が含めることもできる。

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

ここで、上述の実施形態の本サービスの応用例について、簡単に説明する。
上述の通り、本サービスは、古材及び古民家の管理に関するサービスであるが、これに利用されるデータベース等については、一般のユーザ等が気軽に情報の登録を行うことができる。また、このような情報の登録については、業者を介したサブスクリプションモデルとして提供してもよい。
また、上述の一般ユーザは、例えば、関連する情報を自由に閲覧することができたり、新たな情報が登録された際には当該ユーザに対して通知がなされるようなサービス、例えば上述の「いいね」機能等が提供されたりしてもよい。これにより、ユーザは、古民家Ｋや古材Ｗの価値を享受して、さらに楽しむことができる。
さらに言えば、一般ユーザは、上述のサービスを利用した結果、他のユーザ等との情報交換に利用してもよい。古民家Ｋや古材Ｗは、一般的な木材等と比べて、独自性が高く、情報交換の頻度やその価値自体が非常に高いものである。そのため、このような情報交換が活発に行われることで、情報交換の対象となった古民家Ｋや古材Ｗの価値は、さらに高まることになる。
以上をまとめると、本サービスとはいわば、現在の所有者が後世に価値を残したいと考える物（古民家Ｋや古材Ｗ）に関するログを取得し、蓄積することができるプラットフォームを提供するサービスである。これにより、当該物の価値はさらに高まり、それにより、一般ユーザは、その価値を、より享受することができるようになる。

例えば、上述の実施形態では、所有者Ｓ、活用者Ｒ、及びサービス提供者Ｇの夫々は、所有者端末２、活用者端末３、及びサービス提供者端末４の夫々にインストールされた専用アプリを用いて本サービスを利用する構成となっている。
ただし、本サービスを利用するための具体的手法は特に限定されない。例えば、所有者Ｓ、活用者Ｒ、及びサービス提供者Ｇの夫々は、所有者端末２、活用者端末３、及びサービス提供者端末４の夫々のブラウザ機能を用いて本サービスを利用することもできる。

また例えば、上述の実施形態における所有者Ｓは、古民家Ｋ又は古材Ｗを売却することが前提となっているが、これに限定されない。例えばサブスクリプションモデルとして、業者や個人に古民家Ｋ又は古材Ｗを使用させて、その使用料を徴収してもよい。この場合、所有者Ｓは、徴収した使用料を積立てておくことで、古民家Ｋの解体時に生じ得る将来の費用に備えることができる。

また例えば、図６、図７、及び図１０に示す、古民家情報、及び古材情報を示す特徴は例示に過ぎない。本発明の目的を達成できる範囲であれば、図６、図７、及び図１０に示す特徴以外のあらゆる特徴を採用することができる。
即ち、図７に示す古材情報を示す項目は例示に過ぎない。例えば図１０に示す古材情報と同様に、古民家Ｋの解体日時、及び解体場所、古材Ｗの煤け有無、煤け具合、保管日時、保管場所、保管区域、搬送日時、及び搬送先等が含まれていてもよい。また、図１０に示す古材情報を示す項目も例示に過ぎない。例えばほぞ穴の有無、傷の有無、手触り感、重さ、その他図７に示す古材情報と同様に古材Ｗの長さ、太さ、色味、古民家Ｋの経歴等が含まれていてもよい。
即ち、古材情報を構成する項目は、古材Ｗを定義し得る情報であればいずれであってもよい。
また、古民家情報も同様であり、古民家情報を構成する項目は、古民家Ｋを定義し得る情報であればいずれであってもよい。

また例えば、上述の実施形態では、古民家Ｋ及び古材Ｗがマッチングの対象、又は管理の対象となっているが、古民家Ｋ及び古材Ｗに限定されない。所有者が売却等することで価値を後世に残したいとする、あらゆる物品（例えば、家具、骨董品等）について、新品であるか、中古品であるかを問わず対象とすることができる。

また、図３及び図８に示すシステム構成、図４に示すサーバ１のハードウェア構成は、本発明の目的を達成するための例示に過ぎず、特に限定されない。

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

また、機能ブロックの存在場所も、図５及び図９に限定されず、任意でよい。
例えば、図５の例において、上述のマッチング処理はサーバ１側で行われる構成となっているが、これに限定されず、所有者端末２側、又は活用者端末３側でマッチング処理の少なくとも一部が行われてもよい。
即ち、マッチング処理の実行に必要となる機能ブロックは、サーバ１側が備える構成となっているが、これは例示に過ぎない。サーバ１側に配置された機能ブロックの少なくとも一部を、所有者端末２側、又は活用者端末３側が備える構成としてもよい。

また、上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。
また、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。

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

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

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。

以上まとめると、本発明が適用される情報処理装置は、次のような構成を取れば足り、各種各様な実施形態を取ることができる。
即ち、本発明が適用される情報処理装置は、
物品（例えば図１の古民家Ｋ又は古材Ｗ）を手放すことを希望する前記物品の所有者（例えば図１の所有者Ｓ）と、前記物品を活用することを希望する活用者（例えば図１の活用者Ｒ）とを支援する情報処理装置（例えば図５のサーバ１）であって、
前記所有者により提示された、前記物品に関する第１情報（例えば図６の古民家情報、図７の古材情報）を取得する第１取得手段（例えば図５の古民家取得部１１１、古材取得部１１２）と、
前記活用者により提示された、前記物品の特徴に関するリクエストを示す第２情報（例えば図１のリクエスト情報）を取得する第２取得手段（例えば図５のリクエスト取得部１１３）と、
前記第２情報に含まれる前記特徴に関するリクエストの内容と一致又は近似する物品を示す情報を、前記第１情報から抽出する抽出手段（例えば図５の抽出部１０３）と、
を備える。

これにより、所有者により提示された物品に関する情報と、活用者により提示された、物品の特徴に関するリクエストを示す情報が取得される。そして、そのリクエストの内容と一致又は近似する物品を示す情報が、物品に関する情報から抽出される。
その結果、物品を「手放したい」と思っている者と、「活用したい」と思っている者とを効率よくマッチングさせることができる。

また、前記物品は、建造から所定期間が経過した古民家、又は前記古民家の解体により派生する古材とすることができる。

これにより、所有者により提示された古民家Ｋ又は古材Ｗに関する情報と、活用者により提示された、古民家Ｋ又は古材Ｗの特徴に関するリクエストを示す情報が取得される。そして、そのリクエストの内容と一致又は近似する古民家Ｋ又は古材Ｗを示す情報が、古民家Ｋ又は古材Ｗに関する情報から抽出される。
その結果、古民家Ｋや、古民家Ｋの解体の際に派生する柱や梁といった古材Ｗを「手放したい」と思っている者と、「活用したい」と思っている者とを効率よくマッチングさせることができる。

また、前記第１情報及び前記第２情報の夫々には、前記特徴として、前記古民家又は前記古材の夫々の経歴を示す情報を含めることができる。

これにより、所有者により提示された古民家Ｋ又は古材Ｗの経歴に関する情報と、活用者により提示された、古民家Ｋ又は古材Ｗの経歴を含む特徴に関するリクエストを示す情報が取得される。そして、そのリクエストの内容と一致又は近似する古民家Ｋ又は古材Ｗを示す情報が、古民家Ｋ又は古材Ｗに関する情報から抽出される。
その結果、古民家Ｋや、古民家Ｋの解体の際に派生する柱や梁といった古材Ｗを「手放したい」と思っている者と、「活用したい」と思っている者とを効率よくマッチングさせることができる。

また、本発明が適用される情報処理装置は、
複数の物品の夫々が独特の特徴を有する場合に、当該複数の物品を管理する情報処理装置（例えば図９のサーバ１）において、
前記複数の物品の夫々に付された、当該複数の物品の夫々を一意に識別可能な第３情報を取得する取得手段（例えば図９の取得部２０１）と、
前記取得手段により取得された前記第３情報に基づいて、前記複数の物品のうち一の物品を特定する特定手段（例えば図９の特定部２０２）と、
を備える。

これにより、個々に特徴を有する物品を効率よく管理することができる。

また、前記物品は、建造から所定期間が経過した古民家、又は前記古民家の解体により派生する古材とすることができる。

これにより、個々に特徴を有する古民家Ｋ又は古材Ｗを効率よく管理することができる。

１・・・サーバ、２，２−１乃至２−ｒ・・・所有者端末、３，３−１乃至３−ｔ・・・活用者端末、１１・・・ＣＰＵ、１２・・・ＲＯＭ、１３・・・ＲＡＭ、１４・・・バス、１５・・・入出力インターフェース、１６・・・入力部、１７・・・出力部、１８・・・記憶部、１９・・・通信部、２０・・・ドライブ、３０・・・リムーバルメディア、１０１・・・取得部、１０２・・・管理部、１０３・・・抽出部、１０４・・・提示部、１１１・・・古民家取得部、１１２・・・古材取得部、１１３・・・リクエスト取得部、１８１・・・古民家ＤＢ、１８２・・・ＫＤＢ、１８３・・・所有者ＤＢ、１８４・・・活用者ＤＢ、２０１・・・取得部、２０２・・・特定部、Ｇ・・・サービス提供者、Ｓ，Ｓ１乃至Ｓｒ・・・所有者、Ｒ，Ｒ１乃至Ｒｔ・・・活用者、Ｎ・・・ネットワーク、Ｋ，Ｋ１乃至Ｋｂ・・・古民家、Ｗ・・・古材、Ｗａ，Ｗａ１乃至Ｗａｎ・・・古材（単体）、Ｗｋ，Ｗｋ１乃至Ｗｋｍ・・・古材候補、ＳＳ・・・各ステップ

Claims (5)

1. 物品を手放すことを希望する前記物品の所有者と、前記物品を活用することを希望する活用者とを支援する情報処理装置であって、
   前記所有者により提示された、前記物品に関する第１情報を取得する第１取得手段と、
   前記活用者により提示された、前記物品の特徴に関するリクエストを示す第２情報を取得する第２取得手段と、
   前記第２情報に含まれる前記特徴に関するリクエストの内容と一致又は近似する物品を示す情報を、前記第１情報から抽出する抽出手段と、
   を備える、
   情報処理装置。
2. 前記物品は、建造から所定期間が経過した古民家、又は前記古民家の解体により派生する古材である、
   請求項１に記載の情報処理装置。
3. 前記第１情報及び前記第２情報の夫々には、前記特徴として、前記古民家又は前記古材の夫々の経歴を示す情報が含まれる、
   請求項２に記載の情報処理装置。
4. 複数の物品の夫々が独特の特徴を有する場合に、当該複数の物品を管理する情報処理装置において、
   前記複数の物品の夫々に付された、当該複数の物品の夫々を一意に識別可能な第３情報を取得する取得手段と、
   前記取得手段により取得された前記第３情報に基づいて、前記複数の物品のうち一の物品を特定する特定手段と、
   を備える情報処理装置。
5. 前記物品は、建造から所定期間が経過した古民家、又は前記古民家の解体により派生する古材である、
   請求項４に記載の情報処理装置。
   

Images