特許 7042000 情報処理装置、情報処理方法、及びプログラム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-03-16

(45)【発行日】2022-03-25

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

(51)【国際特許分類】

   G06Q 30/06 20120101AFI20220317BHJP

【ＦＩ】

G06Q30/06 306

【請求項の数】 8

(21)【出願番号】P 2019212073

(22)【出願日】2019-11-25

(65)【公開番号】P2021086171

(43)【公開日】2021-06-03

【審査請求日】2021-01-07

【早期審査対象出願】

(73)【特許権者】

【識別番号】514277905

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

(74)【代理人】

【識別番号】100079108

【弁理士】

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

(74)【代理人】

【識別番号】100109346

【弁理士】

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

(74)【代理人】

【識別番号】100117189

【弁理士】

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

(74)【代理人】

【識別番号】100134120

【弁理士】

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

(72)【発明者】

【氏名】中山 亮太郎

【審査官】安田 勇太

(56)【参考文献】

【文献】特開２０１７－１５６９２７（ＪＰ，Ａ）

【文献】特開２０１５－１９７９０４（ＪＰ，Ａ）

【文献】特開２０１７－２０４０３４（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１９／０１３０４８０（ＵＳ，Ａ１）

【文献】イギリスで高評価! 西陣織職人による色と技法にこだわったカードケース 「Hi-color」がクラウドファンディングで6 月 1 日から国内先行販売開始!［オンライン］，2017年06月01日，https://www.value-press.com/pressrelease/184023，2021年9月8日検索

【文献】濃さを簡単に調整できる、新開発コーヒードリッパーを届けたい！［オンライン］，2016年11月02日，https://web.archive.org/web/20161102150531/https://kibidango.com/67，2021年9月8日検索

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００ －９９／００

(57)【特許請求の範囲】

【請求項1】

情報処理装置が、
所定の商品又はサービスを先行予約販売するプロジェクトに対する予約販売を受け付け、前記予約販売の受付状況を公開するプラットフォームを提供すること、
他の処理装置から、識別情報を含むログイン情報を取得すること、
前記プラットフォームを利用するユーザの第１識別情報と、前記商品又はサービスを他人に提供するバイヤの第２識別情報とを記憶する記憶部に記憶される前記第１識別情報及び前記第２識別情報を用いて、前記ログイン情報に含まれる前記識別情報が前記第１識別情報又は前記第２識別情報のいずれであるかを判定すること、
前記プラットフォームにおいて登録され、前記予約販売を受け付けている１又は複数のプロジェクトの中から、少なくとも一のプロジェクトを選択すること、
前記識別情報が前記第２識別情報である場合に、前記予約販売を受け付けている前記１又は複数のプロジェクトの中から選択された前記プロジェクトの商品又はサービスに対し、前記バイヤからの発注要求を取得すること、
前記発注要求に関する処理を実行すること、
を含む情報処理方法。

【請求項2】

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

【請求項3】

前記発注要求に含まれる発注個数の上限値は、前記ユーザが購入できる数よりも多い、請求項１又は２に記載の情報処理方法。

【請求項4】

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

【請求項5】

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

【請求項6】

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

【請求項7】

所定の商品又はサービスに対する予約販売を受け付け、前記予約販売の受付状況を公開するプラットフォームを提供する提供部と、
他の処理装置から、識別情報を含むログイン情報を取得すること、
前記プラットフォームを利用するユーザの第１識別情報と、前記商品又はサービスを他人に提供するバイヤの第２識別情報とを記憶する記憶部に記憶される前記第１識別情報及び前記第２識別情報を用いて、前記ログイン情報に含まれる前記識別情報が前記第１識別情報又は前記第２識別情報のいずれであるかを判定すること、
前記プラットフォームにおいて登録され、前記予約販売を受け付けている１又は複数のプロジェクトの中から、少なくとも一のプロジェクトを選択する選択部と、
前記識別情報が前記第２識別情報である場合に、前記予約販売を受け付けている前記１又は複数のプロジェクトの中から選択された前記プロジェクトの商品又はサービスに対し、前記バイヤからの発注要求を取得する取得部と、
前記発注要求に関する処理を実行する処理部と、
を備える情報処理装置。

【請求項8】

情報処理装置に、
所定の商品又はサービスに対する予約販売を受け付け、前記予約販売の受付状況を公開するプラットフォームを提供すること、
他の処理装置から、識別情報を含むログイン情報を取得すること、
前記プラットフォームを利用するユーザの第１識別情報と、前記商品又はサービスを他人に提供するバイヤの第２識別情報とを記憶する記憶部に記憶される前記第１識別情報及び前記第２識別情報を用いて、前記ログイン情報に含まれる前記識別情報が前記第１識別情報又は前記第２識別情報のいずれであるかを判定すること、
前記プラットフォームにおいて登録され、前記予約販売を受け付けている１又は複数のプロジェクトの中から、少なくとも一のプロジェクトを選択すること、
前記識別情報が前記第２識別情報である場合に、前記予約販売を受け付けている前記１又は複数のプロジェクトの中から選択された前記プロジェクトの商品又はサービスに対し、前記バイヤからの発注要求を取得すること、
前記発注要求に関する処理を実行すること、
を実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

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

【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】