特開 2022-67130 情報処理装置、情報処理方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022067130

(43)【公開日】2022-05-02

(54)【発明の名称】情報処理装置、情報処理方法、及びプログラム

(51)【国際特許分類】

   G06Q 30/06 20120101AFI20220422BHJP

【ＦＩ】

G06Q30/06 306

【審査請求】未請求

【請求項の数】8

【出願形態】ＯＬ

(21)【出願番号】P 2022036719

(22)【出願日】2022-03-10

(62)【分割の表示】P 2019212073の分割

【原出願日】2019-11-25

(71)【出願人】

【識別番号】514277905

【氏名又は名称】株式会社マクアケ

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫 敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口 昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤 和彦

(72)【発明者】

【氏名】中山 亮太郎

(57)【要約】

【課題】予約販売システムに対して、バイヤを支援対象者に含む新たな仕組みを提供する
。
【解決手段】情報処理方法は、情報処理装置が、所定の商品又はサービスに対する予約販
売を受け付け、前記予約販売の受付状況を公開するプラットフォームを提供すること、
前記プラットフォームにおいて登録されたプロジェクトの中から、少なくとも一のプロジ
ェクトを選択すること、選択された前記プロジェクトの商品又はサービスに対し、当該商
品又はサービスを他人に提供するバイヤからの発注要求を取得すること、前記発注要求に
関する処理を実行すること、を含む。
【選択図】図２

【特許請求の範囲】

【請求項1】

情報処理装置が、
所定の商品又はサービスを先行予約販売するプロジェクトに対する予約販売を受け付け
、前記予約販売の受付状況を公開するプラットフォームを提供すること、
前記プラットフォームにおいて登録されたプロジェクトの中から、少なくとも一のプロ
ジェクトを選択すること、
選択された前記プロジェクトの商品又はサービスに対し、当該商品又はサービスを他人
に提供するバイヤからの発注要求を取得すること、
前記発注要求に関する処理を実行すること、
を含む情報処理方法。

【請求項2】

前記情報処理装置が、
他の処理装置から識別情報を取得した場合、前記プラットフォームを利用するユーザの
第１識別情報と、前記バイヤの第２識別情報とを記憶する記憶部に記憶される前記第１識
別情報及び前記第２識別情報を用いて、取得された前記識別情報が前記第１識別情報又は
前記第２識別情報のいずれであるかを判定すること、
をさらに含む、請求項１に記載の情報処理方法。

【請求項3】

前記情報処理装置が、
前記識別情報が前記第１識別情報である場合に、前記他の処理装置に表示される第１表
示情報と、前記識別情報が前記第２識別情報である場合に前記他の処理装置に表示される
第２表示情報とを異ならせること
をさらに含む、請求項２に記載の情報処理方法。

【請求項4】

前記処理を実行することは、
前記他の処理装置から前記所定の商品又はサービスに関する発注情報を前記発注要求と
ともに取得すると、前記所定の商品又はサービスを供給するサプライヤが利用する処理装
置に、前記発注情報を送信することを含む、請求項２又は３に記載の情報処理方法。

【請求項5】

前記処理を実行することは、
前記発注情報に関する決済処理を実行することを含む、請求項４に記載の情報処理方法
。

【請求項6】

前記処理を実行することは、
前記所定の商品の取引に関する管理、又は発送処理を行うことを含む、請求項１から５
のいずれか一項に記載の情報処理方法。

【請求項7】

所定の商品又はサービスに対する予約販売を受け付け、前記予約販売の受付状況を公開
するプラットフォームを提供する提供部と、
前記プラットフォームにおいて登録されたプロジェクトの中から、少なくとも一のプロ
ジェクトを選択する選択部と、
選択された前記プロジェクトの商品又はサービスに対し、当該商品又はサービスを他人
に提供するバイヤからの発注要求を取得する取得部と、
前記発注要求に関する処理を実行する処理部と、
を備える情報処理装置。

【請求項8】

情報処理装置に、
所定の商品又はサービスに対する予約販売を受け付け、前記予約販売の受付状況を公開
するプラットフォームを提供すること、
前記プラットフォームにおいて登録されたプロジェクトの中から、少なくとも一のプロ
ジェクトを選択すること、
選択された前記プロジェクトの商品又はサービスに対し、当該商品又はサービスを他人
に提供するバイヤからの発注要求を取得すること、
前記発注要求に関する処理を実行すること、
を実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

開示の技術は、情報処理装置、情報処理方法、及びプログラムに関する。

【背景技術】

【0002】

近年、企業は、新製品や新サービスのマーケティングツールの一つとして、クラウドフ
ァンディングのような先行予約販売システムを利用する機会が増えている。先行予約販売
システムでは、商品やサービスの予約販売を受け付け（例えば支援とも称する）、この予
約状況を公開する（例えば特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特許第５７３３８６９号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、従来の予約販売システムでは、支援対象者は一般ユーザであり、例えば
卸売業者や小売業者などのバイヤにとっても利便性の良い予約販売システムは存在しなか
った。

【0005】

そこで、開示技術は、予約販売システムに対して、バイヤを支援対象者に含む新たな仕
組みを提供することを目的とする。

【課題を解決するための手段】

【0006】

開示の一態様における情報処理方法は、情報処理装置が、所定の商品又はサービスに対
する予約販売を受け付け、前記予約販売の受付状況を公開するプラットフォームを提供す
ること、 前記プラットフォームにおいて登録されたプロジェクトの中から、少なくとも
一のプロジェクトを選択すること、選択された前記プロジェクトの商品又はサービスに対
し、当該商品又はサービスを他人に提供するバイヤからの発注要求を取得すること、前記
発注要求に関する処理を実行すること、を含む。

【発明の効果】

【0007】

開示技術によれば、予約販売システムに対して、バイヤを支援対象者に含む新たな仕組
みを提供することができる。

【図面の簡単な説明】

【0008】

【図1】一実施形態に係る予約販売システムの構成の一例を示す図である。

【図2】一実施形態に係る予約販売システムの概要を説明するための図である。

【図3】一実施形態に係るサーバの一例を示すブロック図である。

【図4】一実施形態に係るユーザ端末の一例を示す図である。

【図5】一実施形態に係るユーザデータの一例を示す図である。

【図6】一実施形態に係るプロジェクトデータの一例を示す図である。

【図7】一実施形態に係るリターンデータの一例を示す図である。

【図8】一実施形態に係る取引データの一例を示す図である。

【図9】一実施形態に係るテンプレートデータの一例を示す図である。

【図10】一実施形態に係る納品書のテンプレートの一例を示す図である。

【図11】一実施形態に係る登録画面の一例を示す図である。

【図12】一実施形態に係るログイン画面から遷移例を示す図である。

【図13】一実施形態に係る予約販売システムの各装置による処理の一例を示すシーケンス図である。

【図14】一実施形態に係るサーバの処理の一例を示す図である。

【発明を実施するための形態】

【0009】

添付図面を参照して、本発明の好適な実施形態について説明する。なお、各図において
、同一の符号を付したものは、同一又は同様の構成を有する。

【0010】

［実施形態］
＜システム構成＞
図１は、開示の一実施形態に係る予約販売システム１の構成の一例を示す図である。図
１に示すとおり、予約販売システム１は、サーバ１０と、複数のユーザ端末２０と、複数
のユーザ端末３０とを含む。サーバ１０と、１又は複数のユーザ端末２０と、１又は複数
のユーザ端末３０は、ネットワークＮを介して通信プロトコルにＴＣＰ／ＩＰ等を用いて
相互にデータの送受信が可能になっている。ネットワークＮは、例えば、インターネット
、専用通信回線（例えば、ＣＡＴＶ（Community Antenna Television）回線）、移動体通
信網（基地局等を含む）、及びゲートウェイ等により構築されている。開示の予約販売シ
ステムは、例えば、所定の商品やサービス（以下、「商品等」ともいう。）に対して先行
して予約を受け付けるシステムをいう。所定の商品等は、予約販売システム１の運営側に
より承認された商品等を含み、例えば、実際に販売されていない未販売の商品等以外にも
、海外では販売されているが、その国では販売されていない商品等、また、BtoBで販売済
みではあるが、一般ユーザに認知又は販売されていない商品等、現状の商品等の改良版（
機能、色、形状等）、及び地方（限定されたエリア）のみで販売していた商品等の少なく
とも１つを含んでもよい。

【0011】

サーバ１０は、予約販売システム１を実行するプラットフォームを提供するサーバであ
る。予約販売システム１は、所定の商品又はサービスを提供するプロジェクトを実現する
ために、インターネットを通じて多数の支援者から資金を集め、このプロジェクトを実現
するための仕組みである。この予約販売システム１を実現するための例として、クラウド
ファンディング（Crowd Funding）がある。クラウドファンディングには、購入型や投資
型など様々なタイプがある。

【0012】

ユーザ端末２０は、サーバ１０が提供するプラットフォームにより実現される予約販売
システム１において公開されたプロジェクトを支援するユーザ（支援者又は購入者）が利
用する端末装置である。ユーザ端末２０として、例えばパーソナルコンピュータ、ＰＤＡ
（Personal Digital Assistant）、スマートフォン等の携帯情報端末、携帯電話機等が用
いられる。

【0013】

ユーザ端末３０は、サーバ１０が提供する予約販売システム１に実現されるプラットフ
ォームにおいて公開されたプロジェクトを実行するユーザ（プロジェクト実行者）が利用
する端末装置である。ユーザ端末３０として、例えばパーソナルコンピュータ、ＰＤＡ（
Personal Digital Assistant）、スマートフォン等の携帯情報端末、携帯電話機等が用い
られる。以下、ユーザ端末２０又はユーザ端末３０を区別しない場合、ユーザ端末２０（
３０）とも表記する。

【0014】

ユーザ端末２０（３０）には、サーバ１０が提供する予約販売システム１のプラットフ
ォームを利用するためのアプリケーションプログラム（アプリ）が記憶されてもよい。当
該アプリは、サーバ１０が提供する予約販売サービスにおいて、プロジェクトの企画、支
援などのサービスをユーザ端末２０（３０）に実行させる。当該アプリを実行することに
より、ユーザ端末２０（３０）はサーバ１０にアクセスして、アプリの実行に用いる情報
を送受信する。

【0015】

また、ユーザ端末２０（３０）は、ウェブブラウザを用いて、サーバ１０が提供するウ
ェブサイトにアクセスし、このウェブサイトにおいて公開されるプロジェクトを支援した
り、プロジェクトを起案したりしてもよい。

【0016】

＜システム概要＞
図２は、開示の一実施形態に係る予約販売システム１の概要を説明するための図である
。図２の左側には、１又は複数のバイヤを示し、中央には、予約販売システム１を実現す
るプラットフォームＡを示し、右側には、各プロジェクト実行者（サプライヤ）が実現し
たいプロジェクト内容が、プラットフォームＡにより公開されていることを示す。プロジ
ェクトの表示画面には、プロジェクトの詳細や、予約販売の状況を報告するレポートなど
が含まれる。公開されるプロジェクトは、予約販売を受付中のプロジェクト、予約販売の
受付終了のプロジェクトが含まれうる。

【0017】

図２に示す例では、バイヤは、プラットフォームＡを利用するため、ユーザ端末２０に
インストールされたアプリ又はウェブブラウザを用いてログイン操作を行う。プラットフ
ォームＡを提供するサーバ１０は、ユーザ端末２０からログイン情報を受信し、ログイン
情報の認証処理を実行する。ログイン情報は、バイヤにより入力されてもよいし、Ｃｏｏ
ｋｉｅなどに保存されていてもよい。

【0018】

サーバ１０は、ログイン情報に基づいて、ログインを要求したユーザがバイヤであるか
否かを判定する。この場合、サーバ１０は、ユーザ登録する際に、バイヤか否かを示す情
報をユーザ識別情報などに関連付けてデータベースに登録しておくとよい。これにより、
サーバ１０は、ログイン情報に含まれるユーザ識別情報を用いて、バイヤであるか否かを
判定することができる。

【0019】

サーバ１０は、ログインユーザがバイヤであると判定した場合、例えば、バイヤ用のウ
ェブページやアプリのページ（以下、バイヤ用ページとも称する。）を表示するようにし
、バイヤ用ページに表示されるプロジェクトの中から選択された一のプロジェクトに対し
、バイヤからの発注要求を取得する。選択可能なプロジェクトには、予約販売受付中のプ
ロジェクト、予約販売受付が終了したプロジェクトが含まれうる。ここで、バイヤ用ペー
ジは、例えば一般ユーザに表示されるページとは異なり、プロジェクト実行者に対して、
商品やサービスに対する発注を行ったり、仕入れ等の交渉を行ったりすることができるペ
ージを示す。

【0020】

プロジェクト実行者は、プラットフォームＡを介してバイヤから発注の連絡を受ける。
例えば、プロジェクト実行者が利用するユーザ端末３０は、サーバ１０から発注に関する
情報を受信し、画面に表示することで、発注内容をプロジェクト実行者に確認させる。ユ
ーザ端末３０は、受注される場合にプロジェクト実行者からの受注操作を受け付け、受注
操作に基づく受注情報をサーバ１０に送信する。また、ユーザ端末３０は、発注に対して
交渉が申し入れられた場合に、プロジェクト実行者からの交渉内容に対する回答操作を受
け付けることで、回答操作に基づく回答情報をサーバ１０に送信する。

【0021】

プロジェクト実行者は、発注された商品やサービスをバイヤに提供し、納品を行う。納
品時に、例えば、ユーザ端末３０は、サーバ１０を介して、バイヤが利用するユーザ端末
２０に納品書データを送信してもよい。

【0022】

以上の予約販売システム１によれば、バイヤを支援対象者に含む新たな仕組みを提供す
ることができる。例えば、バイヤは、支援対象者としてシステムにログインすることが可
能であり、さらに、一般ユーザとは異なり、所定の商品やサービスに対して発注を行うこ
とも可能である。これにより、予約販売システム１におけるプラットフォームを、サプラ
イヤ（プロジェクト実行者）と、バイヤとを仲介するプラットフォームとしても機能させ
ることが可能である。以下、上述した予約販売システム１の各構成等について詳細に説明
する。

【0023】

＜ハードウェア構成＞
図３は、開示の一実施形態に係るサーバ１０の一例を示すブロック図である。サーバ１
０は、１つ又は複数の処理装置（ＣＰＵ）１１０、１つ又は複数のネットワーク又は他の
通信インタフェース１２０、メモリ１３０、ユーザインタフェース１５０、及びこれらの
構成要素を相互接続するための１つ又は複数の通信バス１７０を含む。

【0024】

サーバ１０は、場合によりユーザインタフェース１５０を含んでもよく、これとしては
、ディスプレイ装置１５１、及び入力装置（キーボード及び／又はマウス、又は他の何ら
かのポインティングデバイス等）１５２を挙げることができる。

【0025】

メモリ１３０は、例えば、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ ＲＡＭ又は他のランダムアク
セス固体記憶装置などの高速ランダムアクセスメモリであり、また、１つ又は複数の磁気
ディスク記憶装置、光ディスク記憶装置、フラッシュメモリデバイス、又は他の不揮発性
固体記憶装置などの不揮発性メモリでもよく、非一時的な記録媒体でもよい。

【0026】

メモリ１３０は、予約販売システム１により用いられるデータを記憶する。例えば、メ
モリ１３０は、ユーザデータ、プロジェクトデータ、リターンデータ、発注に関する取引
データ、発注に関するテンプレートデータなどを記憶する。なお、各データの詳細は、図
５～９を用いて後述される。

【0027】

また、メモリ１３０の他の例として、ＣＰＵ１１０から遠隔に設置される１つ又は複数
の記憶装置でもよい。ある実施形態において、メモリ１３０はＣＰＵ１１０により実行さ
れるプログラム、モジュール及びデータ構造、又はそれらのサブセットを格納する。

【0028】

ＣＰＵ１１０は、メモリ１３０に記憶されるプログラムを実行することで、提供部１１
２、判定部１１３、処理部１１４、選択部１１５、取得部１１６を構成する。提供部１１
２は、所定の商品又はサービスに対する予約販売を受け付け、この予約販売の受付状況を
公開するプラットフォームＡを提供する。プラットフォームＡが提供されることで、予約
販売システム１が実現される。

【0029】

例えば、提供部１１２は、ユーザ登録を行ったり、プロジェクトを公開したり、プロジ
ェクトに対する予約販売を受け付けたり、予約販売の受付状況を報告したりする。一例と
して、提供部１１２は、購入型のクラウドファンディングのプラットフォームを提供する
。

【0030】

判定部１１３は、ユーザがプラットフォームＡを利用するためのログイン時のログイン
情報を取得し、取得したログイン情報を用いて認証処理を実行する。ログイン情報は、プ
ロジェクト実行者やバイヤや一般ユーザなどのユーザを識別するユーザ識別情報（ユーザ
ＩＤ）、パスワードなどを含む。ユーザＩＤは、例えばユーザ固有の情報であり、メール
アドレスやユーザにより設定された英数字の組み合わせなどである。

【0031】

また、判定部１１３は、バイヤや一般ユーザなどのユーザが利用する他の処理装置から
、ネットワーク通信インタフェース１２０を介して、ユーザＩＤを取得した場合、取得さ
れたユーザＩＤが、一般ユーザのユーザＩＤ（第１識別情報）又はバイヤのユーザＩＤ（
第２識別情報）のいずれであるかを判定する。なお、判定部１１３は、一般ユーザ、バイ
ヤ以外にも、プロジェクト実行者、他のカテゴリのユーザを判定してもよい。

【0032】

例えば、判定部１１３は、メモリ１３０に記憶されるユーザデータ（会員データ）を用
いて、ログイン情報に含まれるユーザＩＤに対応するユーザを判定する。ユーザデータに
は、少なくとも、プラットフォームＡを利用するユーザのユーザＩＤ（第１識別情報）と
、所定の商品又はサービスを他人に販売するバイヤのユーザＩＤ（第２識別情報）とが記
憶される。また、プロジェクト実行者のユーザＩＤなどもユーザデータに記憶されてもよ
い。

【0033】

処理部１１４は、判定部１１３の判定結果に基づく処理を実行する。例えば、取得され
たユーザＩＤが一般ユーザを示す場合、処理部１１４は、予約販売システム１における通
常のウェブページが、ユーザ端末２０に表示されるよう制御する。通常のウェブページと
は、個人ユーザ向けにプロジェクトを公開し、プロジェクトに対するリターンを表示し、
支援を募ったりする（プロジェクトの運転資金を集める）ことが可能なページである。

【0034】

また、処理部１１４は、取得されたユーザＩＤがバイヤを示す場合、バイヤ用のウェブ
ページが、ユーザ端末２０に表示されるよう制御する。バイヤ用のウェブページとは、例
えば、所定の商品やサービスに対して発注を申し入れることを可能にするウェブページで
あり、通常のウェブページに、バイヤ用のウェブページを表示させるためのＵＩ部品（例
えばボタン）が含まれるものも含む。

【0035】

これにより、ログイン時のユーザＩＤに基づく判定結果に応じて、処理部１１４が後段
の処理を実行することで、ログインユーザに適した後段の処理を実行することが可能にな
る。開示の予約販売システム１では、ログインユーザにバイヤが含まれるため、バイヤに
よる、プラットフォームＡ上で公開された予約販売の受付情報を参考にした発注等を可能
にすることができる。

【0036】

また、処理部１１４は、選択部１１５と、受付部１１６とを含む。選択部１１５は、プ
ラットフォームＡに登録されたプロジェクトの中から、少なくとも一のプロジェクトを選
択する。例えば、選択部１１５は、支援者（例えばバイヤ）の選択操作に基づいて、公開
中の１又は複数のプロジェクトの中から選択されたプロジェクトを示す情報（例えばプロ
ジェクトＩＤ）をユーザ端末２０から取得する。選択部１１５は、取得されたプロジェク
トＩＤに基づいて、一のプロジェクトを選択する。なお、選択可能なプロジェクトは、予
約販売受付中のプロジェクトや予約販売受付期間が終了したプロジェクトなどを含む。予
約販売受付期間が終了したプロジェクトも選択可能とすることにより、バイヤは、先行予
約販売の最終的な受付結果を考慮して、発注内容を決めることができる。また、バイヤに
対し、選択可能なプロジェクト数を増加させることもできる。

【0037】

取得部１１６は、選択されたプロジェクトの商品又はサービスに対し、この商品又はサ
ービスを他人に提供するバイヤからの発注要求を取得する。例えば、ユーザ端末２０にお
いて、発注画面から所定項目が入力されて、発注ボタンがバイヤにより押下されたときに
、取得部１１６は、ユーザ端末２０から、バイヤからの発注要求を取得する。

【0038】

また、処理部１１４は、取得された発注要求に関する処理を実行する。例えば、処理部
１１４は、発注要求に基づいて、取引データを生成し、生成した取引データをメモリ１３
０に管理する。具体的には、処理部１１４は、取引ＩＤを付与し、発注要求を取得した日
付や、発注要求に発注情報が付与されていれば、発注情報に含まれる発注個数、金額、納
期、決済方法などを取引ＩＤに関連付けてメモリ１３０に記憶する。

【0039】

これにより、プラットフォームＡでは、公開中の商品等に対して、バイヤからの仕入れ
等の発注要求を取得することで、円滑な処理による発注サービスを提供することが可能に
なる。なお、処理部１１４は、発注要求に関する処理として、以下に説明する処理も含む
。

【0040】

処理部１１４は、取得されたユーザＩＤが一般ユーザを示すＩＤ（第１識別情報）であ
る場合にユーザ端末２０に表示される第１表示情報（例えば通常のウェブページ）と、取
得されたユーザＩＤがバイヤを示すＩＤ（第２識別情報）である場合にユーザ端末２０に
表示される第２表示情報（例えばバイヤ用のウェブページ）とを異ならせてもよい。例え
ば、通常のウェブページと、バイヤ用のウェブページとにおいて、表示内容がそれぞれ異
なってもよいし、ユーザインタフェースの観点で画面の操作性が異なっていてもよい。例
えば、バイヤ用ウェブページでは、商品の発注を大量に行うことができたり、値段に対す
る交渉ができたり、仕様等についての質問ができたりするようなページ構成にすることが
可能である。

【0041】

これにより、予約販売システム１において、バイヤ用の表示情報を提供することにより
、一般ユーザの支援ではできない大量の発注を行ったり、商談を行ったりすることが可能
になる。また、一例として、バイヤは、予約販売の受付情報をチェックしつつ、どのプロ
ジェクトに対し、どれくらいの量や価格で発注するかを検討し、その検討結果をシステム
上で入力することが可能になる。

【0042】

また、処理部１１４は、取得されたユーザＩＤがバイヤのユーザＩＤである場合に、バ
イヤが利用するユーザ端末２０から所定の商品又はサービスに関する発注情報を発注要求
とともに受信してもよい。次に、処理部１１４は、所定の商品又はサービスを供給するプ
ロジェクト実行者が利用するユーザ端末２０に、受信した発注情報を送信するよう制御す
る。例えば、発注情報は、個数や納期や値段などの発注に関する各情報を含む。

【0043】

これにより、バイヤは、予約販売システム１が提供するプラットフォームＡを介して、
プロジェクト実行者（サプライヤ）に発注情報を送信することで、商品等の仕入れ交渉を
申し入れることが可能になる。

【0044】

また。処理部１１４は、発注情報に関する決済処理を実行してもよい。例えば、プロジ
ェクト実行者により発注が承認された場合には、バイヤからプロジェクト実行者への支払
いを行う決済処理を処理部１１４が行ってもよい。例えば、サーバ１０は、バイヤに支払
い情報を登録させておくことで、発注する個数と価格とが決定されれば、その合計金額を
算出し、決済してもよい。支払い情報は、例えば、銀行口座番号、クレジットカード情報
、電子マネーを用いるサービスのアカウント情報などのうち、少なくとも１つを含む。

【0045】

また、処理部１１４は、プロジェクト実行者が利用するユーザ端末２０に、納品書のテ
ンプレートファイルを送信してもよい。また、処理部１１４は、発注に関する書類（例え
ば発注書など）の各テンプレートファイルを、適時、購入者側のユーザ端末２０や、プロ
ジェクト実行者側のユーザ端末３０に送信するようにしてもよい。例えば、処理部１１４
は、発注情報を送信する際に、納品書のテンプレートファイルを合わせて送信したり、プ
ロジェクト実行者用のウェブページからダウンロード可能にしたりする。

【0046】

これにより、自社の納品書を保持していないプロジェクト実行者に対して、納品書のテ
ンプレートファイルを送信することが可能になり、より適切なサービスを提供することが
可能になる。

【0047】

処理部１１４は、バイヤに対して所定の保険に加入する処理を行ってもよい。例えば、
プラットフォームＡを提供する会社が、小売業、卸売業用の保険を提供する保険会社と連
携し、この保険をバイヤに推薦、提供するようにする。具体的には、バイヤ用のウェブペ
ージを表示する画面上に、生産物賠償責任保険などの保険の加入を促すＵＩ部品（例えば
チェックボタン、ラジオボタンなど）が表示される。このＵＩ部品がバイヤにより操作さ
れると、保険の内容を示す画面が表示され、処理部１１４により保険の加入手続きが実行
される。

【0048】

これにより、商品を販売するバイヤに対して、適切な保険を提供することが可能になる
。また、発注操作の中に保険加入操作を含めることで、バイヤは容易に保険に加入するこ
とが可能になる。また、処理部１１４は、プロジェクト実行者に対して、例えば、生産物
賠償責任保険などの保険に加入する処理を行ってもよい。例えば、プロジェクト実行者に
対して、発注に対する回答操作の中に保険加入操作を含めることで、プロジェクト実行者
は容易に保険に加入することが可能になる。

【0049】

また、処理部１１４は、所定の商品の取引に関する管理、又は発送処理を行ってもよい
。例えば、プラットフォームＡを提供する会社が保有する倉庫を利用して、処理部１１４
は、プロジェクト実行者から倉庫に配送された商品を管理したり、倉庫からバイヤ等への
発送を管理したりする。

【0050】

これにより、倉庫を保有しないプロジェクト実行者に対して、適切な商品管理を可能に
し、プラットフォームＡの信頼性を高めることができる。また、取引処理と在庫管理、発
送管理を一元管理することができ、処理の効率化を図ることができる。

【0051】

また、処理部１１４は、所定の商品又はサービスの取引相手に対するレビュー情報を取
得してもよい。この場合、メモリ１３０は、取得されたレビュー情報を、取引相手を示す
ユーザＩＤに関連付けて記憶する。例えば、処理部１１４は、納品が完了した後、バイヤ
からプロジェクト実行者のレビュー情報、プロジェクト実行者からバイヤへのレビュー情
報の入力を促すレビュー要求通知を、バイヤ及びプロジェクト実行者それぞれのユーザ端
末２０に送信するよう制御してもよい。この場合、レビュー要求通知に応答して入力され
た各レビュー情報がサーバ１０に受信されてもよい。

【0052】

これにより、プロジェクト実行者、バイヤは、これから取引をする相手のレビュー情報
を参照することが可能になり、取引相手の選定に役立てることができる。

【0053】

図４は、開示の一実施形態に係るユーザ端末２０（３０）の一例を示す図である。ユー
ザ端末２０（３０）は、１つ又は複数の処理装置（ＣＰＵ）２１０、１つ又は複数のネッ
トワーク又は他の通信インタフェース２２０、メモリ２３０、ユーザインタフェース２５
０、及びこれらの構成要素を相互接続するための１つ又は複数の通信バス２７０を含む。

【0054】

ユーザインタフェース２５０は、ディスプレイ装置２５１、及び入力装置（キーボード
及び／又はマウス、又は他の何らかのポインティングデバイス等）２５２を含む。

【0055】

メモリ２３０は、例えば、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ ＲＡＭ又は他のランダムアク
セス固体記憶装置などの高速ランダムアクセスメモリであり、また、１つ又は複数の磁気
ディスク記憶装置、光ディスク記憶装置、フラッシュメモリデバイス、又は他の不揮発性
固体記憶装置などの不揮発性メモリでもよく、非一時的な記録媒体でもよい。

【0056】

メモリ２３０は、予約販売システム１により用いられるデータやプログラムを記憶する
。例えば、メモリ２３０は、予約販売システム１における携帯端末用のアプリケーション
プログラムなどを記憶する。

【0057】

ＣＰＵ２１０は、メモリ２３０に記憶されるプログラムを実行することで、クライアン
トアプリケーション２１１を構成する。クライアントアプリケーション２１１は、例えば
、ウェブブラウザやメールアプリケーションなどを含む。ウェブブラウザは、プラットフ
ォームＡのウェブページの閲覧を可能にする。また、インストールされた予約販売システ
ム１における携帯端末用のアプリケーションの実行により、プラットフォームＡのウェブ
ページの閲覧が可能になる。

【0058】

支援対象者側のユーザ端末２０のＣＰＵ２１０は、プラットフォームＡにログインし、
商品等を予約販売するプロジェクトの閲覧などを可能にする。また、プロジェクト実行者
側のユーザ端末３０のＣＰＵ２１０は、プラットフォームＡにログインし、予約販売状況
などの確認や支援対象者からの質問等への回答が可能になる。

【0059】

＜各データの例＞
次に、サーバ１０のメモリ１３０に格納される各データについて図５～図９を用いて説
明する。図５は、一実施形態に係るユーザデータの一例を示す図である。図５に示す例の
ユーザデータには、ユーザＩＤに関連付けて、ユーザ名、メールアドレス、パスワード、
バイヤか否かを示す情報などが含まれる。

【0060】

「ユーザＩＤ」は、例えば、ユーザを識別するための情報を示す。「ユーザ名」は、例
えば、氏名、ニックネームなどのプラットフォームＡ上でユーザを表示する際に用いられ
るデータを示す。「メールアドレス」は、例えば、ユーザの連絡先である電子メールアド
レスを示す。「業者」は、小売り業者や卸売り業者などのバイヤか否かを示すデータを示
し、「〇」はバイヤを示し、「－」は一般ユーザを示す。また、ユーザデータには、住所
や、銀行口座番号やクレジットカード番号などの決済情報、プロジェクト実行者か否かを
示す情報などが含まれてもよい。

【0061】

図６は、一実施形態に係るプロジェクトデータの一例を示す図である。図６に示す例の
プロジェクトデータには、プロジェクトＩＤに関連付けて、名称、ユーザＩＤ、開始日、
終了日、目標額、Ｗｅｂページなどが含まれる。

【0062】

「プロジェクトＩＤ」は、例えば、商品やサービスの実現を目指すプロジェクトを識別
する情報を示す。「名称」は、例えば、プロジェクトの名称を示す。「ユーザＩＤ」は、
例えば、このプロジェクトを企画したプロジェクト実行者のユーザＩＤを示す。「開始日
」は、例えば、このプロジェクトが開始する日を示す。「終了日」は、このプロジェクト
が終了する日時を示す。「目標額」は、例えば、このプロジェクトの遂行に関して設定さ
れた下限の販売額を示す。「Ｗｅｂページ」は、例えば、このプロジェクトの内容を閲覧
したり、このプロジェクトを支援したりするウェブページのＵＲＬを示す。

【0063】

図７は、一実施形態に係るリターンデータの一例を示す図である。図７に示す例のリタ
ーンデータには、プロジェクトＩＤやリターンＩＤに関連付けて、名称、価格、最大販売
数、残り販売数、リターン詳細などが含まれる。

【0064】

「プロジェクトＩＤ」は、例えば、プロジェクトを識別するためのＩＤを示す。「リタ
ーンＩＤ」は、例えば、ユーザが支援した際に得られるリターンを識別するためのＩＤを
示す。「名称」は、例えば、このリターンの名称を示す。「価格」は、例えば、このリタ
ーンの販売価格を示す。「最大販売数」は、例えば、このリターンの最大販売数を示す。
「残り販売数」は、例えば、このリターンの残りの販売数を示す。「リターン詳細」は、
例えば、このリターンの詳細を説明するテキストデータなどを示す。なお、リターンは、
一つのプロジェクトに複数設定されてもよい。

【0065】

図８は、一実施形態に係る取引データの一例を示す図である。図８に示す例の取引デー
タには、プロジェクトＩＤや取引ＩＤ、プロダクトＩＤ等に関連付けて、ユーザＩＤ、発
注数、卸価格、発注日、取引形態、ステータス、納品予定日などが含まれる。取引データ
の少なくとも一部の情報が、上述した発注情報になりうる。

【0066】

「プロジェクトＩＤ」は、例えば、プロジェクトを識別するためのＩＤを示す。「取引
ＩＤ」は、例えば、発注などの取引を識別するためのＩＤを示す。「プロダクトＩＤ」は
、例えば、プロジェクトの商品等を識別するためのＩＤである。「ユーザＩＤ」は、例え
ば、バイヤのユーザＩＤを示す。「発注数」は、例えば、このプロジェクトの商品等に対
する発注数を示す。「卸価格」は、例えば、交渉中又は交渉成立した商品等の価格を示す
。「発注日」は、例えば、バイヤにより発注が要求された日を示す。また、「発注日」は
、取引が成立した日を示してもよい。「取引形態」は、例えば、取引の形態を示し、委託
販売や仕入れ販売などが取引形態に含まれる。「ステータス」は、例えば、バイヤとプロ
ジェクト実行者との取引の状況を示す。「納品予定日」は、例えば、商品等が納品される
予定日を示す。なお、取引データには、支払いの方法を示す決済方法、加入保険などがさ
らに含まれてもよい。

【0067】

また、一般ユーザの販売履歴データがサーバ１０のメモリ１１０に記憶されるが、図示
しない。販売履歴データには、例えば、プロジェクトＩＤ、購入者ＩＤ、リターンＩＤ、
販売日時、決済方法などが含まれる。

【0068】

図９は、一実施形態に係るテンプレートデータの一例を示す図である。図９に示す例の
テンプレートデータには、ファイルＩＤに関連付けて、テンプレート名、データなどが含
まれる。

【0069】

「ファイルＩＤ」は、例えば、テンプレートを識別するためのＩＤを示す。「テンプレ
ート名」は、例えば、取引に利用される文書の名称を示す。「データ」は、例えば、テン
プレートの格納場所を示す。

【0070】

図１０は、一実施形態に係る納品書のテンプレートの一例を示す図である。図１０に示
すテンプレートは、プロジェクト実行者に送信される、又はダウンロードされる納品書の
テンプレートである。図１０に示すようなテンプレートが、サーバ１０から、ユーザ端末
２０（３０）に適時送信されたり、テンプレートデータの格納先を含む通知が、サーバ１
０から、ユーザ端末２０（３０）に適時送信されたりする。

【0071】

＜表示画面例＞
図１１は、一実施形態に係る登録画面の一例を示す図である。図１１に示す例では、プ
ラットフォームＡの会員登録を行う画面には、右欄にメールアドレス、ユーザ名、パスワ
ードなどの入力欄、小売、卸売業者などのバイヤであるかを示すチェック欄が表示される
。また、左欄には、ソーシャルネットワーキングサービス（ＳＮＳ）などを用いて会員登
録を行う表示欄が設けられる。

【0072】

例えば、ユーザが、小売、卸売業者などのバイヤであるかを示すチェック欄にチェック
した場合、更にバイヤ用の登録画面が表示され、店舗の情報や決済方法などをバイヤに登
録させる。これにより、ユーザがバイヤか一般ユーザかを登録時に設定させることで、シ
ステム側で判断することが可能になる。なお、図１１に示す登録画面は一例であって、会
員登録の初めに、業者か一般ユーザかをユーザに選択させて、それぞれに対応する登録画
面が表示されるようにしてもよい。

【0073】

図１２は、一実施形態に係るログイン画面から遷移例を示す図である。図１２に示す例
では、ログイン画面は、任意のユーザに共通の画面であり、メールアドレス（ユーザ識別
情報の一例）やパスワードがユーザにより入力される。

【0074】

ログインが完了すると、例えば、一般ユーザであれば、処理部１１４は、中央左画面が
ユーザ端末２０に表示されるように制御し、バイヤであれば、処理部１１４は、中央右画
面がユーザ端末２０に表示されるように制御する。なお、ログイン画面から、中央の画面
に遷移する前に、プラットフォームＡのホーム画面が表示されてもよい。

【0075】

ここで、一般ユーザの場合の表示画面と、バイヤの場合の表示画面はそれぞれ異なる。
例えば、バイヤの場合には、プロジェクト実行者と仕入れ交渉等が可能な画面に遷移する
ための「業者の方」ボタンが表示される。

【0076】

バイヤは、「業者の方」ボタンを押下すると、処理部１１４は、右下の発注画面がユー
ザ端末２０に表示されるように制御する。この発注画面には、発注数の入力欄、希望価格
の入力欄、保険加入のチェックボックスなどが表示される。また、発注画面には、その他
、決済方法の入力欄、納期の入力欄などが表示されてもよい。

【0077】

これにより、例えば、予約販売システム１のプラットフォームＡにおいて、ログイン時
にバイヤであることが判定され、バイヤ用の表示画面が表示されることで、バイヤによる
発注を可能にするプラットフォームを提供することが可能になる。また、図１２に示すよ
うに、バイヤであっても、通常の支援を可能にしておいてもよい。なお、図１２に示す表
示画面は、一例であって、ログイン後に、一般ユーザと、バイヤとで全く異なる表示画面
が表示されるようにしてもよい。また、プラットフォームＡでは、ログイン時にバイヤか
否かが判定されるのではなく、ログイン後に、図１２に示す中央左の画面が表示され、「
業者の方」ボタンが押下されたときに、業者か否かが判定されてもよい。

【0078】

＜動作説明＞
次に、予約販売システム１の各動作について説明する。図１３は、一実施形態に係る予
約販売システム１の各装置による処理の一例を示すシーケンス図である。図１３に示す例
では、ユーザ端末２０Ａは、バイヤＡが利用する端末であり、ユーザ端末３０Ａは、バイ
ヤＡが発注したい商品を販売予定のプロジェクト実行者が利用する端末とする。

【0079】

ステップＳ１０２で、ユーザ端末２０Ａのクライアントアプリケーション２１１は、バ
イヤＡの操作に基づいて、サーバ１０にログイン要求を行う。例えば、ログイン要求は、
ユーザＩＤとパスワードとともに送信される。

【0080】

ステップＳ１０４で、サーバ１０の判定部１１３は、ログイン要求を受信すると、ユー
ザＩＤとパスワードを用いて認証処理を実行する。このとき、判定部１１３は、ユーザＩ
Ｄを用いて、メモリ１３０に記憶されるユーザデータを参照し、ログイン対象者が、一般
ユーザなのか、バイヤなのかを判定してもよい。また、この判定では、ユーザ端末２０Ａ
から取得されたユーザＩＤが、ユーザデータに登録されたどのユーザＩＤに一致するかの
照合処理が行われる。ここでは、判定部１１３によりログイン対象者はバイヤであると判
定されたとする。

【0081】

ステップＳ１０６で、サーバ１０の処理部１１４は、ログインの認証後の画面情報を、
ユーザ端末２０Ａに送信する。例えば、プラットフォームＡのホーム画面が表示される。

【0082】

ステップＳ１０８で、ユーザ端末２０Ａのクライアントアプリケーション２１１は、バ
イヤの操作に基づいて、プロジェクトの閲覧を表示制御したりし、例えば、図１２に示す
プロジェクト画面内の「業者の方」ボタンが押下されたとすると、発注用画面をサーバ１
０に要求するよう制御する。

【0083】

ステップＳ１１０で、サーバ１０の処理部１１４は、ユーザ端末２０Ａからの発注用画
面要求に応答して、発注用画面情報をユーザ端末２０Ａに送信する（例えば、図１２に示
す右下画面参照）。

【0084】

ステップＳ１１２で、ユーザ端末２０Ａのクライアントアプリケーション２１１は、バ
イヤの操作に基づいて、発注情報が入力され、送信ボタンなどが押下されると、発注情報
をサーバ１０に送信するよう制御する。発注情報は、プロジェクトＩＤ、発注数、希望価
格、バイヤのユーザＩＤなどを含む。

【0085】

ステップＳ１１４で、サーバ１０の処理部１１４は、ユーザ端末２０Ａから取得した発
注情報に基づいて、発注に関する取引ＩＤなどを付与し、この発注の取引情報を管理する
ようにした後で、発注情報をユーザ端末３０Ａに送信する。処理部１１４は、発注情報の
送信先として、発注情報に含まれるプロジェクトＩＤから特定したプロジェクト実行者の
ユーザＩＤに基づいて送信先を特定可能である。

【0086】

ステップＳ１１６で、ユーザ端末３０Ａのクライアントアプリケーション２１１は、プ
ロジェクト実行者の操作に基づいて、発注情報に対する回答を含む回答情報をサーバ１０
に送信するよう制御する。回答情報は、発注情報に対してプロジェクト実行者が希望する
希望価格や納期などの情報を含む。

【0087】

ステップＳ１１８で、サーバ１０の処理部１１４は、ユーザ端末３０Ａから受信した回
答情報を用いて取引情報を更新し、回答情報をユーザ端末２０Ａに送信する。

【0088】

ステップＳ１２０で、ユーザ端末２０Ａのクライアントアプリケーション２１１は、回
答情報を表示制御し、バイヤの操作に基づいて、発注に関して修正された修正情報を取得
し、修正情報をサーバ１０に送信する。

【0089】

ステップＳ１２２で、サーバ１０の処理部１１４は、ユーザ端末２０Ａから受信した修
正情報を用いて取引情報を更新し、修正情報をユーザ端末３０Ａに送信する。

【0090】

これにより、バイヤは、プラットフォームＡを介して、プロジェクト実行者と発注に関
して交渉を行うことができ、交渉手続をスムースに実行することができる。なお、ステッ
プＳ１１６からＳ１２２は、取引が成立するまで繰り返されてもよく、また、ステップＳ
１１４の発注内容でプロジェクト実行者が受注する場合は、省略されてもよい。

【0091】

ステップＳ１２４で、ユーザ端末３０Ａのクライアントアプリケーション２１１は、プ
ロジェクト実行者の操作に基づいて、ＯＫボタンなどの押下により、発注を受けることを
認識すると、受注を示す受注情報をサーバ１０に送信する。

【0092】

ステップＳ１２６で、サーバ１０の処理部１１４は、ユーザ端末３０Ａから受信した受
注情報を用いて取引情報のステータスを取引成立に更新し、受注情報をユーザ端末２０Ａ
に送信する。

【0093】

ステップＳ１２８で、サーバ１０の処理部１１４は、例えば、ユーザ端末３０Ａに納品
テンプレートを送信する。ステップＳ１２８の処理は、他のタイミングで行われてもよく
、例えば、ステップＳ１１４の発注情報とともに納品テンプレ―トが送信されてもよい。

【0094】

ステップＳ１３０で、サーバ１０の処理部１１４は、この取引における決済処理を実行
する。例えば、バイヤにより設定された決済方法で、取引により発生する費用がバイヤか
らプロジェクト実行者に支払われるように決定処理が行われる。

【0095】

ステップＳ１３２で、無事に納品が行われた後などに、ユーザ端末２０Ａのクライアン
トアプリケーション２１１は、バイヤの操作に基づいて、プロジェクト実行者に対するレ
ビューを含むレビュー情報をサーバ１０に送信するよう制御する。

【0096】

ステップＳ１３４で、商品等の発送が行われた後などに、ユーザ端末３０Ａのクライア
ントアプリケーション２１１は、プロジェクト実行者の操作に基づいて、バイヤに対する
レビューを含むレビュー情報をサーバ１０に送信するよう制御する。サーバ１０は、双方
のレビュー情報を受信すると、ユーザデータのそれぞれのユーザＩＤに関連付けてレビュ
ー情報を登録するとよい。

【0097】

以上の処理によれば、予約販売システム１に対して、バイヤを支援対象者に含む新たな
仕組みを提供することができる。また、バイヤは、所定の商品等に対して発注を行うこと
ができ、また、公開された予約販売状況を確認し、所定の商品等の成長性を予測して、発
注を行うか否か等を判断することができる。

【0098】

図１４は、一実施形態に係るサーバ１０の処理の一例を示すフローチャートである。図
１４に示す例では、ログインから発注情報の送信までの処理を示し、受注後の処理は省略
する。

【0099】

ステップＳ２０２で、サーバ１０の判定部１１３は、ユーザ端末２０からログイン情報
を受信する。

【0100】

ステップＳ２０４で、サーバ１０の判定部１１３は、取得されたログイン情報を用いて
認証処理を行い、認証に成功したか否かを判定する。認証が成功すれば（ステップＳ２０
４－ＹＥＳ）、処理はステップＳ２０８に進み、認証が失敗すれば（ステップＳ２０４－
ＮＯ）、処理はステップＳ２０６に進む。

【0101】

ステップＳ２０６で、サーバ１０の判定部１１３は、認証失敗をユーザ端末２０に通知
する。これにより、ログインのリトライをユーザに促す。

【0102】

ステップＳ２０８で、サーバ１０の判定部１１３は、ログインユーザが業者であるか否
かを判定する。ログインユーザが業者であれば（ステップＳ２０８－ＹＥＳ）、処理はス
テップＳ２１０に進み、ログインユーザが業者であれば（ステップＳ２０８－ＮＯ）、処
理はステップＳ２２０に進む。なお、この処理は、別のタイミングで行われてもよい。例
えば、この処理は、ステップＳ２１２の後などに行われてもよい。

【0103】

ステップＳ２１０で、サーバ１０の処理部１１４は、バイヤ用（業者用）の画面情報を
ユーザ端末２０Ａに送信するよう制御する。

【0104】

ステップＳ２１２で、サーバ１０の処理部１１４は、ユーザ端末２０から、発注画面の
表示要求を受信したか否かを判定する。発注画面の表示要求が受信されれば（ステップＳ
２１２－ＹＥＳ）、処理はステップＳ２１４に進み、発注画面の表示要求が受信されなけ
れば（ステップＳ２１２－ＮＯ）、処理は終了したり、ステップＳ２２２に進んだりする
。

【0105】

ステップＳ２１４で、サーバ１０の処理部１１４は、発注画面情報をユーザ端末２０に
送信する。

【0106】

ステップＳ２１６で、サーバ１０の処理部１１４は、ユーザ端末２０から、発注画面内
で設定された情報に基づいて発注情報を受信する。

【0107】

ステップＳ２１８で、サーバ１０の処理部１１４は、取得した発注情報を、プロジェク
ト実行者のユーザ端末３０に送信するよう制御する。

【0108】

ステップＳ２２０で、サーバ１０の提供部１１２は、一般ユーザ用の画面情報をユーザ
端末２０に送信する。

【0109】

ステップＳ２２２で、サーバ１０の提供部１１２は、ユーザからの支援があるか否かを
判定する。支援があれば（ステップＳ２２２－ＹＥＳ）、処理はステップＳ２２４に進み
、支援がなければ（ステップＳ２２２－ＮＯ）、処理は終了する。

【0110】

ステップＳ２２４で、サーバ１０の提供部１１２は、どのリターンに対する支援かを特
定することを含む支援処理を実行する。支援処理により、どのユーザが、どのプロジェク
トのどのリターンに支援したかを特定することができる。

【0111】

以上の処理により、既存のプラットフォームを利用して、バイヤ用のユーザインタフェ
ースを追加することで、バイヤに、所望の商品に対する発注を可能とする仕組みを提供す
ることが可能になる。

【0112】

以上、実施形態について詳述したが、上記実施形態に限定されるものではなく、特許請
求の範囲に記載された範囲内において、下記に示すように、上記実施形態以外にも種々の
変形及び変更が可能である。

【0113】

［変形例］
実施形態で説明した予約販売システム１は、ログイン時に、ログインユーザがバイヤで
あるかの判定を行うのではなく、プラットフォームＡにおいて任意のユーザに共通に表示
される画面内の「業者の方」ボタンが押下されたときなどに判定されてもよい。この場合
、プラットフォームＡのホーム画面やプロジェクト閲覧画面は、任意のユーザに共通であ
り、一般ユーザが「業者の方」ボタンを押下した場合には、エラー画面が通知されるとよ
い。また、業者は、納品された商品等に加工を加えて販売等してもよい。

【0114】

以上、実施形態及び変形例は、本発明を説明するための例示であり、本発明をその実施
形態及び変形例のみに限定する趣旨ではなく、本発明は、その要旨を逸脱しない限り、さ
まざまな変形が可能である。

【符号の説明】

【0115】

１…予約販売システム、１０…サーバ、２０、３０…ユーザ端末、１１０…ＣＰＵ、１３
０…メモリ、１１２…提供部、１１３…判定部、１１４…処理部、２１０…ＣＰＵ、２１
１…クライアントアプリケーション、２３０…メモリ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】