(57)【特許請求の範囲】
【請求項１】
コンテンツ提供者と、少なくとも一人以上で構成されるコンテンツ鑑賞者（又は購入者）が使用する各端末と、サーバ及び記憶装置とが、ネットワークに接続されて構成されるコンテンツ提供方法であって；
前記コンテンツ提供方法は、コンテンツの制作前から、事前に、前記コンテンツ観賞者（又は購入者）より、コンテンツ依頼（要求）信号を受信することのできる方法であって；
前記コンテンツ提供方法は、少なくとも一つは、既に過去に制作した過去作品を有する前記コンテンツ提供者の、過去作品情報を記憶装置に備えており；
且つ、既に、少なくとも一つは前記コンテンツ提供者の前記過去作品を観賞している前記コンテンツ鑑賞者より、前記過去作品の次回作を要求する信号（データｂ）＜例えば、次回作要求／過去作品ＩＤ＞を受信する処理を有しており；
尚、前記データｂの受信は、前記コンテンツ提供者より次回作の予定情報を受信して表示する処理を行わない段階から、前記コンテンツ鑑賞者より受信することが可能な処理であり；
且つ、前記コンテンツ提供方法は、前記次回作を要求する信号（データｂ）を受信すると、記憶装置へ記憶する処理と、且つ、前記コンテンツ提供者が確認する端末画面に、前記データｂの内容を表示する処理とを有し；
且つ、前記コンテンツ提供者より、制作を行う意思である（例えば「制作を行う／行わない」）信号（データe）を受信する処理とを有し；
且つ、前記データeが「制作を行う」であった場合は、コンテンツが完成し、コンテンツが提供された事を確認する確認信号を受信する処理とを有し；
これにより、前記コンテンツ鑑賞者は、過去作品の次回の作品を観賞したい場合に、前記コンテンツ提供者が、次回作を制作する予定の有無に関わらず、前記鑑賞者から前記提供者へ、コンテンツの次回作品の依頼（要求）信号を送信して、コンテンツの提供を受ける事が可能となる；コンテンツ提供方法
【請求項２】
請求項１に記載のコンテンツ提供方法は、前記次回作の要求信号（データｂ）の内容を受けた前記コンテンツ提供者より、次回作概要データ（データｃ）を受信して記憶装置へ記憶し、且つ、前記データｃの内容を前記コンテンツ鑑賞者が確認する端末画面へ表示する処理を有し；
且つ、前記次回作概要データ（データｃ）の内容を受けた前記コンテンツ鑑賞者より、コンテンツを「購入する・しない」の信号（データｄ）を受信して記憶装置へ記憶し、且つ、前記データｄの内容を前記コンテンツ提供者が確認する端末画面へ表示する処理を有し；
且つ、コンテンツ提供方法は、前記データｄの内容を受けた前記コンテンツ提供者より受信する前記データeが、「制作を行う」という信号の場合は、決算処理部にて決済を行う処理を有し、又は、前記データeが、「制作を行わない」という信号の場合は、決算処理部にて決済を行わない処理を有し；
且つ、「制作を行う」という前記データeを受信した場合は、コンテンツが完成して、コンテンツの受け渡しが行われた確認信号を受信する処理を有し；
且つ、前記作品の受け渡しが行われた確認信号を受信すると、前記コンテンツ提供者へ売上金額を支払う処理を有し、又は、前記作品の受け渡しが行われた確認信号が受信できない場合は、前記コンテンツ提供者へ売上金額を支払わない処理を有しており；
尚、一連のデータの送受信は、コンテンツＩＤコードにてヒモ付いている；以上の処理を備えたコンテンツ販売方法
【請求項３】
コンテンツ提供者と、少なくとも一人以上で構成されるコンテンツ鑑賞者（又は購入者）が使用する各端末と、サーバ及び記憶装置とが、ネットワークに接続されて構成されるコンテンツ提供システムであって；
前記コンテンツ提供システムは、コンテンツ制作前から事前に、前記コンテンツ観賞者より、コンテンツ依頼（要求）信号を受信することのできるシステムであって；
前記コンテンツ提供システムは、少なくとも一つは、既に過去に制作した過去作品を有する前記コンテンツ提供者の、ＩＤコードが付与された過去作品情報を記憶する記憶装置を有しており；
且つ、既に、少なくとも一つは前記コンテンツ提供者の前記過去作品を観賞している前記コンテンツ鑑賞者より、前記過去作品の次回作を要求する信号（データｂ）＜例えば、次回作要求／過去作品ＩＤ＞を受信する手段を有し；
尚、前記データｂの受信は、前記コンテンツ提供者より次回作の予定情報を受信して表示する処理を行わない段階から、前記コンテンツ鑑賞者より受信することが可能な手段であり；
且つ、前記コンテンツ提供システムは、受信した前記データｂを記憶する記憶部と、且つ、前記コンテンツ提供者が確認する端末画面へ、前記データｂの内容を表示する表示画面とを有し；
且つ、前記コンテンツ提供システムは、前記コンテンツ提供者より、制作を行う意思である＜例えば「制作を行う／行わない」＞の信号（データe）を受信する手段と；
且つ、前記データeが「制作を行う」であった場合は、コンテンツが完成し、コンテンツが提供された事を確認する確認信号を受信する手段とを有し；
又、一連のデータの送受信は、コンテンツＩＤコードにてヒモ付いており；
これにより、前記コンテンツ鑑賞者は、過去作品の次回の作品を観賞したい場合に、前記コンテンツ提供者が、次回作を制作する予定の有無に関わらず、前記鑑賞者から前記提供者へ、コンテンツの次回作品の依頼（要求）信号を送信して、コンテンツの提供を受ける事が可能となる；コンテンツ提供システム
【請求項４】
コンテンツ提供者と、少なくとも一人以上で構成されるコンテンツ鑑賞者（又は購入者）が使用する各端末と、サーバ及び記憶装置とが、ネットワークに接続されて構成されるコンテンツ提供システムであって；
前記コンテンツ提供システムは、コンテンツ制作前から事前に、前記コンテンツ観賞者より、コンテンツ依頼（要求）信号を受信することのできるシステムであって；
前記コンテンツ提供システムは、少なくとも一つは、既に過去に制作した過去作品を有する前記コンテンツ提供者の、過去作品情報を記憶する記憶装置を備えており；
且つ、既に、少なくとも一つは前記コンテンツ提供者の前記過去作品を観賞している前記コンテンツ鑑賞者より、前記過去作品の次回作を要求する信号（データｂ）＜例えば、次回作要求／過去作品ＩＤ＞を受信する手段を有しており；
尚、前記データｂの受信は、前記コンテンツ提供者より次回作の予定情報を受信して表示する処理を行わない段階から、前記コンテンツ鑑賞者より受信することが可能な手段であり；
且つ、前記コンテンツ提供システムは、前記次回作を要求する信号を受信すると、記憶装置へ記憶する記憶部と、且つ、前記コンテンツ提供者が確認する端末画面へ、前記データｂの内容を表示する表示画面と、且つ、前記コンテンツ鑑賞者が確認する端末画面には、受信した前記データｂとＩＤコードでヒモ付いたコンテンツデータ＜先行コンテンツアイコン/コンテンツ情報等＞を、カート画面内にて表示する表示画面とを有しており；
且つ、前記カート画面は、コンテンツ提供を受ける前段階のコンテンツ選択画面であって、且つ、鑑賞者より前記データｂを送信する事により選択された複数のコンテンツを表示する画面であり、且つ、鑑賞者が要求する次回作情報以外のその他の情報や、広告情報を明確に区分した形で表示する画面構成であって；
これにより、前記コンテンツ鑑賞者は、過去作品の次回の作品を観賞したい場合に、前記コンテンツ提供者が、次回作を制作する予定の有無に関わらず、前記鑑賞者から前記提供者へ、コンテンツの次回作品の要求信号を送信して、コンテンツの提供を受ける事が可能となり、且つ、カート画面内にてコンテンツを管理することが可能となる；コンテンツ提供システム
【請求項５】
コンテンツ提供者と、少なくとも一人以上で構成されるコンテンツ鑑賞者（又は購入者）が使用する各端末と、サーバ及び記憶装置とが、ネットワークに接続されて構成されるコンテンツ提供システムであって；
前記コンテンツ提供システムは、コンテンツの制作前から、事前に、前記コンテンツ観賞者（又は購入者）より、コンテンツ依頼（要求）信号を受信することのできるシステムであって；
前記コンテンツ提供システムは、少なくとも一つは、既に過去に制作した過去作品を有する前記コンテンツ提供者の、ＩＤコードが付与された過去作品情報を記憶する記憶装置を有しており；
且つ、既に、少なくとも一つは前記コンテンツ提供者の前記過去作品を観賞している前記コンテンツ鑑賞者より、前記過去作品の次回作を要求する信号（データｂ）＜例えば、次回作要求／過去作品ＩＤ＞を受信する手段を有し；
尚、前記データｂの受信は、前記コンテンツ提供者より次回作の予定情報を受信して表示する処理を行わない段階から、前記コンテンツ鑑賞者より受信することが可能な手段であり；
且つ、前記コンテンツ提供システムは、受信した前記データｂを記憶する記憶部と、且つ、前記コンテンツ提供者が確認する端末画面へ、前記データｂの内容を表示する表示画面とを有し；
且つ、前記コンテンツ提供システムは、コンテンツ提供者以外からの前記過去作品情報を受信して記憶装置へ記憶する手段を有し；
尚、これは、前記過去作品情報が前記記憶部に登録されていない場合に、コンテンツ提供者以外からでも登録可能な手段であって、前記コンテンツ提供者以外とは、鑑賞者、あるいは、システム運営者のいずれか、又はその両方であって；
且つ、前記コンテンツ提供システムは、コンテンツ提供者が、過去作品のコンテンツ提供者本人であること認証するＩＤ認証手段を有しており；
これにより、前記コンテンツ鑑賞者は、過去作品の次回の作品を観賞したい場合に、前記コンテンツ提供者が、次回作を製作する予定の有無に関わらず、前記鑑賞者から前記提供者へ、コンテンツの次回作品の依頼（要求）信号を送信し、コンテンツの提供を受ける事が可能となる；コンテンツ提供システム
【請求項６】
コンテンツ提供者と、少なくとも一人以上で構成されるコンテンツ鑑賞者（又は購入者）が使用する各端末と、サーバ及び記憶装置とが、ネットワークに接続されて構成されるコンテンツ提供システムであって；
前記コンテンツ提供システムは、コンテンツ制作前から事前に、前記コンテンツ観賞者より、コンテンツ依頼（要求）信号を受信することのできるシステムであって；
前記コンテンツ提供システムは、少なくとも一つは、既に過去に制作した過去作品を有する前記コンテンツ提供者の、過去作品情報を記憶する記憶装置を備えており；
且つ、既に、少なくとも一つは前記コンテンツ提供者の前記過去作品を観賞している前記コンテンツ鑑賞者より、前記過去作品の次回作を要求する信号（データｂ）＜例えば、次回作要求／過去作品ＩＤ＞を受信する手段を有しており；
尚、前記データｂの受信は、前記コンテンツ提供者より次回作の予定情報を受信して表示する処理を行わない段階から、前記コンテンツ鑑賞者より受信することが可能な手段であり；
且つ、前記コンテンツ提供システムは、受信した前記データｂを記憶する記憶部と、且つ、前記コンテンツ提供者の確認する端末画面へ、前記データｂの内容を表示する表示画面とを有し；
且つ、前記コンテンツ提供システムは、コンテンツ提供を行うタイミングを調整する自動入札設定手段を有し；
前記自動入札設定手段は、前記データｂの送信を行った前記コンテンツ鑑賞者の画面に、自動入札設定の入力画面を表示し、且つ、前記コンテンツ鑑賞者より、自動入札設定データ（データＪ−３/  自動入札回数、最大期限、等 ）を受信し、且つ、その内容道りに設定を行う手段である；以上の特徴を有するコンテンツ販売システム
【請求項７】
請求項３乃至６に記載のコンテンツ提供システムは、
コンテンツ提供を行うタイミングを調整する手段と、タイミングを調整する為のデータを表示する表示画面生成部とを有しており；
前記タイミングを調整する手段は、前記コンテンツ提供者より（Ｊ−２/提供側のざっくりとしたコンテンツ制作希望時間等）を受信する手段と、又、前記コンテンツ提供者より（Ｊ−４/確定した完成予定日時）とを受信する手段であって
又、前記タイミングを調整するデータを表示する表示画面生成部は、コンテンツスケジュール画面として、データＪ−２の内容を表示する画面、データＪ−４の内容を表示する画面の２つのパターンを表示することを特徴としている；以上の特徴を備えたコンテンツ販売システム
【請求項８】
請求項３乃至７に記載のコンテンツ提供システムは、
前記次回作の要求する信号（データｂ）の内容を受けた前記コンテンツ提供者より、次回作概要データ（データｃ）を受信して、記憶する記憶部と、且つ、前記データｃの内容を前記コンテンツ鑑賞者の確認する端末画面へ表示する表示画面とを有し；
且つ、前記次回作概要データ（データｃ）の内容を受けた前記コンテンツ鑑賞者より、コンテンツを「購入する・しない」の信号（データｄ）を受信して記憶する記憶部と、且つ、前記データｄの内容を前記コンテンツ提供者の確認する端末画面へ表示する表示画面を有し；
且つ、コンテンツ提供システムは、前記データｄを受けた前記コンテンツ提供者より受信する前記データeが、「制作を行う」という信号の場合は、決算処理部にて決済を行う手段を有し、又は、前記データeが、「制作を行わない」という信号の場合は、決算処理部にて決済を行わない手段を有し；
且つ、「制作を行う」という前記データeを受信した場合は、コンテンツが完成し、コンテンツの受け渡しが行われた確認信号を受信する手段を有し；
且つ、前記コンテンツの受け渡しが行われた確認信号を受信すると、前記コンテンツ提供者へ売上金額を支払う手段を有し、又は、前記作品の受け渡しが行われた確認信号が受信できない場合は、前記コンテンツ提供者へ売上金額を支払わない手段を有しており；
尚、一連のデータの送受信は、コンテンツＩＤコードにてヒモ付いている；
以上の特徴を有するコンテンツ販売システム
【請求項９】
請求項８に記載のシステムであって、決算処理部にて決済を行う手段は、プール型課金による手段、積立型課金による手段、混合型課金による手段の、いずれか、又は、いずれかの組み合わせ、又は、全ての組み合わせを有している；コンテンツ提供システム
【請求項１０】
請求項３乃至９に記載のシステムであって、前記次回作を要求する信号データｂの付属情報として、詳細情報を含んだデータＢ−２（詳細次回作要求情報）と、過去作品を厳密に指定したデータＢ−４（過去作品厳密指定情報）とを、受信する手段を有し；
且つ、前記データＢ−２/Ｂ−４を、記憶する記憶装置を有し、且つ、前記データＢ−２/Ｂ−４の内容を、前記コンテンツ提供者の確認する端末画面へ表示する表示画面を有している；コンテンツ販売システム
【請求項１１】
請求項３乃至１０に記載のシステムであって、
前記次回作要求信号データｂの内容を受けた前記コンテンツ提供者が、前記次回作要求信号データｂにて要求されたコンテンツとＩＤがヒモ付いた形で、次回作概要データｃを規定のフォーマット画面にて入力することのできる入力画面を有し；
前記フォーマット画面は、規定の作品情報を入力できる画面であって；
且つ、前記コンテンツ提供システムは、前記規定の作品情報を受信する手段と、且つ、前記前記規定の作品情報を記憶する記憶部と、且つ、前記規定の作品情報を、鑑賞者が要求する次回作情報以外のその他の情報や広告情報等と、明確に区分して、前記コンテンツ鑑賞者が確認するカート画面内にて表示する表示画面を有している；コンテンツ販売システム
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オンライン上で販売可能なコンテンツ、画像、動画、電子書籍・雑誌・漫画、音楽、ゲームを対象とした芸術的クリエイティブな創作活動を要する著作物の販売課金システムであり、制作者が制作するよりも前の段階から、鑑賞者よりコンテンツ売買に於ける手順が開始される事に特徴を有している。
【背景技術】
【０００２】
従来のオンライン上でのコンテンツ販売の方法は、コンテンツ制作者側及び仲介者が創作物をオンライン上にて表示し、鑑賞者はその表示された商品を観て判断し購入するというステップである。購入に至るまでの段階には、音楽であれば視聴機能、書籍であれば中身拝見機能などのお試し機能があり、これらによって購買の意思決定を高めるという手段がある。又、類似する既存のシステムには、予約販売システム、オーダーシステム、投資システム、アマゾン等のオンラインストアシステム、アンケートシステム、マーケティングシステム、コミュニティーシステムが存在する。尚、段落「００１８」〜「００１９」にて、相違点を詳細に述べる。
【先行技術文献】
【特許文献】
【０００３】
不明
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来の方法によると制作者側としては、作品を制作するかどうかの意思決定が難しいという問題がある。例えば、作品を制作しても必ずしも売れる（資金が回収できる）かどうかの確証はつかず、結果、資金不足で制作中止という判断に陥ってしまう。観賞者側の問題としては、お気に入りの作家の次回作品が見たくても、制作者側の予算不足の問題等で制作中止となり観賞が不可能になるケースがある。又、従来では作品を制作するかしないかは、作品の流通を担う販売会社等の予測による販売決定に委ねられているのだが、制作会社が鑑賞者側の意思を完全に組み切れているとは言い難いという問題が残る。又、現在、インターネットでのコンテンツの流通というのは、制作者の著作権を守りきれていない現状がある。不正コピー、不正な投稿等、今後もますますこの課題は広がっていき、課題として残ったままである。コンテンツ制作者はインターネットの到来により表現への自由度は高まったが、既存のビジネスモデルの崩壊など、制作改善の進展には効果が低い。
【０００５】
又、既存モデルの崩壊とは、コンテンツの無料化問題を指し、ＩＴ技術によりコンテンツ市場の無料化が益々進んでいく中で、コンテンツ市場での制作者の制作環境を維持するのが極めて困難であった。その一原因としてＩＴ以前の時代であれば制作者側は少数であったが、ＩＴ後の時代ではごく一般人でも容易に制作者側へと回れる環境である為、参加者が増加し、優良且つ無償の作品が競う様にＷＥＢ上で供給されている事が上げられる。この様な状況では、当初は、無償の優良のコンテンツが存在しているのだが、無料化がピークを越えると制作側が疲弊し、次には、反動で極端にコンテンツの質が低下するという問題がある。又、制作者が疲弊していくと鑑賞者は良質な作品を見る事が困難になる。（「図４３」参照）
【０００６】
以上は、ＷＥＢ上に存在している周知の課題であり、長らく解決できずにいる難問である。又、本発明は、原価というコストリスク（赤字リスク）回避に留まらず、制作者が作品（いわゆる画像、音楽、文書、動画等の表現作品）を制作するにあたり、アルバイトや仕事を行いながら作品を制作しないといけないという環境を解決したいとするものである。これを考えるにあたり「制作時間を捻出できないか？」という課題を持つものである。通常、作品を制作するにあたり“コスト”という物理的な費用の壁を感じたとしても、自分自身の“時間”の壁には絶対的な不可能なできない理由を感じず、多少不便を感じつつも“時間”は無料である為、仕方のない事、気合いで何とかなる事だと考えられている。一般的に、時間的障害とは制作者が当然、負担しなければならない制約であると考えられており、その為、時間は本人の「やる気」の問題という心理的問題で片付けられている。しかし、本発明は制作者の時間捻出に関しても解決を課題としている。
【課題を解決するための手段】
【０００７】
上記課題を解決する為に、請求項１に記載の内容は、コンテンツ提供者と、コンテンツ鑑賞者（購入者が）端末を介してネットワーク回線で繋がっているシステムの、コンテンツを売買するためのコンテンツ提供方法である。そして、鑑賞者から、コンテンツ提供者へ「次回作の要求」の信号を送信することで、コンテンツの売買を始めることができる処理に特徴を有している。まず、既に、コンテンツ提供者の過去作品を観賞している鑑賞者が前提として存在しており、その鑑賞者が、当該過去作品の提供者の次回の作品を観賞したい場合に、「次回作要求」信号（例えば、「続きが見たい」、というようなボタンを押すことで）送信することができるものである。※又、過去作品の情報は、コンテンツＩＤが付与されて記憶装置に記憶されており、鑑賞者により（コンテンツＩＤを含んだ）「次回作要求」信号を受信すると、ＩＤコードでヒモ付いた形で管理されている。そしてこれは、前記コンテンツ提供者が、次回作を製作する事を予定しているかの有無に関わらず、前記鑑賞者から前記提供者へ、コンテンツの次回作品の購入の要求を行うことが可能な処理である。そして、次回作要求信号を受けたコンテンツ提供者は、その内容から、次回作を制作するかを決定し、制作を行う場合であれば「作成を行う」という信号を送信することができる。これにより、コンテンツの売買が仮成立する。そして、制作が完了すれば、コンテンツの受け渡しを行いコンテンツの提供が行える。これにより、上記課題を解決する。（尚、段落「００１５」に記載の内容である）
【０００８】
又、請求項２に記載の内容は、鑑賞者より、次回作要求信号を受けた前記コンテンツ提供者にて、次回作の概要データであるデータｃを受信する処理と、次に、前記次回作概要データｃを受けて、内容を確認した鑑賞者より、「購入する・しない」の信号データｄを受信する処理とを有している提供方法である。又、「購入する」という前記データｄを受けた、前記コンテンツ提供者より、制作を行うのかの判断であるデータeを受信する処理を有し、前記データeが「制作を行う」という信号の場合は、決算処理部にて決済を行う処理を有し、又は、前記データeが、「制作を行わない」という信号の場合は、決算処理部にて決済を行わない処理を有している。且つ、「制作を行う」という前記データeを受信した場合は、作品制作が完了して、作品の受け渡しが行われると、受け渡しが完了した信号を受信する処理を有しており、且つ、前記作品の受け渡しが行われた信号を受信すると、前記コンテンツ提供者へ売上金額を支払う処理を有している。又、前記作品の受け渡しが行われた信号が受信できない場合は、前記コンテンツ提供者へ売上金額を支払う処理を行わない処理を有している。尚、一連の信号の送受信処理は、ヒモ付いたコンテンツＩＤコードにて処理が行われる方法である。（尚、段落「００１６」〜「００１７」/「００３０」〜「００３６」に記載の内容である。）又、請求項３に記載の内容は、請求項１に記載のコンテンツ提供システムである。
【０００９】
又、請求項４に記載の内容は、次回作要求信号であるデータｂを送信した前記鑑賞者の端末画面にて、次回作を要求した作品（前記データｂとヒモ付いたコンテンツ情報）を、ストックして表示するカート画面を備えるシステムである。又、カート画面とは、コンテンツ購入者が選択したコンテンツを表示するものであり、カート画面にて表示するコンテンツは、前記鑑賞者が次回作要求信号データｂを送信して選択したコンテンツであり、選択していないその他の情報や広告情報とは、明確に区分した形で表示している。（尚、段落「００３７」/「００６２」/ に記載の内容である）
【００１０】
又、請求項５に記載の内容は、コンテンツ提供者以外からの過去作品の登録手段である。前記コンテンツ販売システムは、過去著作登録部（１２）と、コンテンツ提供者ＩＤ認証部（１１）とを備えており、前記過去著作登録部（１２）は、前記ユーザー（１）又は、前記ユーザー（２）より、記憶装置へ、属性データである過去作品著作情報をデータ（Ａ−１）の格納（登録）を行う手段であり、前記コンテンツ提供者ＩＤ認証部（１１）は、
コンテンツ提供者が、過去作品のコンテンツ提供者本人であること認証する手段である。これにより、コンテンツ鑑賞者は、コンテンツ提供者が、制作を予定している有無に関わらず、過去作品ＩＤとヒモ付いた、依頼信号（データｂ）を送信する事が可能になる。（段落「００３９」/「００２７」/「００４２」〜「００４６」にて詳細に記載）
【００１１】
又、請求項６に記載の内容は、観賞者と、コンテンツ提供者の間で、コンテンツが提供される、売買及び契約等のタイミングを調整する為の手段である。そして、タイミングを調整する手段は、自動入札設定手段を有している。自動入札設定手段は、前記コンテンツ鑑賞者が、次回作要求信号データｂの送信を行うと、入力できるデータであり、自動入札を行う設定データ（データＪ−３/  自動入札回数、最大期限、上限金額等  ）を入力し設定することができる。これにより、処理を自動化して、タイミングを調整することが可能となる。又、コンテンツ提供システムは、前記データＪ−３を受信して、記憶装置へ記憶し、設定した内容にて処理を行う手段である。（段落「００３９」/「００５８」〜「００６１」に記載の内容である）又、請求項７に記載の内容は、観賞者と、コンテンツ提供者の間で、コンテンツが提供される、売買及び契約等のタイミングを調整する為の手段である。そして、コンテンツの売買及び契約等のタイミングを調整する為の契約タイミング調整手段として、前記コンテンツ鑑賞者より（データＪ−１/購入者側の希望タイミング等のデータ）を受信する手段と、前記コンテンツ提供者より（データＪ−２/提供側のざっくりとしたコンテンツ制作希望時間等）を受信する手段と、又、前記コンテンツ提供者より（Ｊ−４/確定した完成予定日時）とを受信する手段を有している。そして、コンテンツ提供システムは、前記タイミングを調整するデータを表示する画面構成を有しており、前記画面構成は、コンテンツスケジュール画面を有している。又、前記コンテンツスケジュール画面は、データＪ−２を表示する画面と、データＪ−４を表示する画面の２つのパターンを表示する事が可能である。（※「図４０」画面１９パターン１、画面１９パターン２）（段落「００３９」/「００５８」〜「００６１」に記載の内容である）又、請求項８に記載の内容は、請求項２に記載のコンテンツ提供システムである。
【００１２】
又、請求項９に記載の内容は、課金処理に於いて、制作者と鑑賞者と運営者の３者間の課金における負担のバランスを調整する手段である。そして、コンテンツ提供システムは、プール型課金による処理、積立型課金による処理、混合型課金による処理の、いずれか、又は、いずれかの組み合わせ、又は、全ての組み合わせを有している。（段落「００３９」/「００５５」〜「００５７」にて詳細に記載）
【００１３】
又、請求項１０に記載の内容は、前記次回作を要求する信号データｂの追加的な情報であり、さらに、詳細情報を含んだデータをデータＢ−２（詳細次回作要求情報）として、又、過去作品を厳密に指定したデータをデータＢ−４（過去作品厳密指定情報）として、受信する手段を有している。又、前記データＢ−２/Ｂ−４を、記憶する記憶装置を有し、且つ、前記データＢ−２/Ｂ−４を、前記コンテンツ提供者の画面へ表示する画面を有している。（尚、段落「００３９」/「００４７」〜「００４９」に記載の内容である）
【００１４】
又、請求項１１に記載の内容は、次回作要求信号データｂを受けた前記コンテンツ提供者より入力される、次回作概要データｃの入力手段であり、その画面構成である。そして、前記次回作概要データｃを入力することのできる画面構成は、鑑賞者より次回作を要求されたコンテンツの、次回作の情報を入力できる画面である。又、次回作の情報は、前記データｂより、コンテンツＩＤでヒモ付いた、コンテンツの情報を入力する事ができる。又、入力できるデータは、「図３２」に様に、入力できる内容が入力フォーマット等にて規定されている。又、入力されたデータは記憶装置に記憶される。そして、鑑賞者が要求していないその他の情報や広告情報とは明確に区分した形で、前記コンテンツ鑑賞者のカート画面に表示することができる。（段落「００３９」/「００５０」〜「００５４」に記載の内容である
【００１５】
本システムは、「図４４」の様に、既存のコンテンツ市場の流れを真逆にするものである。その為、鑑賞者と制作者の、相互間における商品売買のデータの送受信の流れは、既存システムのデータ送受信の流れと真逆のフローとなる。又、「図１２」に記載の「２次的欲求」とは、現在、鑑賞している作品を求める欲求ではなく、次回作（連続作品）を求める欲求である。本システムは、２次的欲求を対象としたコンテンツ（以降より、既存コンテンツと区別して、先行コンテンツと述べる）商品を販売するオンラインストアである。
＜１次欲求＞…現在確認している目の前の商品そのものを求める欲求。
＜２次欲求＞…現在確認している目の前の商品の次回作を求める欲求。
【００１６】
本発明はコンテンツ制作・販売・課金処理の流れに特長を持ったシステムであり、従来のステップと比較して説明を述べる。従来のコンテンツ制作販売者のステップは概ね次の様なものであった。
『既存コンテンツ販売のステップ』
ステップ（１）制作会社又は、制作決定者の販売予測「この作品は売れるだろう」という判断がされる。→ステップ（２）売れるという予測が立てられ、コンテンツの制作を開始する。→ステップ（３）コンテンツ（画像・動画・音楽・文書・ゲーム等）が完成する→ステップ（４）予約販売や、広告宣伝、制作数の調整等を行う→ステップ（５）販売結果が分かる≪販売予測通り販売できたor販売予測通り販売できなかった≫。以上の様な流れであった。
しかし本発明では次のステップを踏む。まず制作者側の流れを説明する。
『本システムのステップ：制作者フロー』
ステップ（１）制作者は自身で設定した「図２」の“続きを見たいボタン”が押されているか、確認することができる。“続きを見たい”ボタンとは、データ（b）であり本発明が提供する機能である。制作者は前記ボタンを設置すると、前記機能（ボタン）提供サイトで、前記ボタンを押したユーザー人数を確認することができる。前記機能は、今まで見過ごされていた鑑賞者のニーズを発見する機能である。又、”続きを見たい“という言葉は、同じ意味であれば、この言葉に限られるものではない。→次に、ステップ（２）では、制作者は”続きを見たい“ボタンを押した鑑賞者に、「図５」のデータ（ｃ）である制作計画（制作予告）を発信することができる。※この時点では制作者はまだ作品の制作は出来ていない状態である。→ステップ（３）では、制作予告を見た鑑賞者が「作品を購入する」というデータを送信する。そして、前記制作者はその内容を受け取り、コンテンツの購入人数を確認する事ができる。又、購入人数が事前に分かれば、前記制作者は制作を決行するかどうかの判断ができる。例えば、制作者は次の様な判断ができる「購入者が１０００人いるな。制作を行おう。バイトせずに制作できるな。（３ヶ月後作品完成）」or「購入者が１０人しかいないな。制作はやめよう。バイトをしよう（２年後作品完成）」となる。次にステップ（４）では、制作者は無事作品を完成させ搬入し、自身の口座に、コンテンツ売上金額が振り込まれたのを確認する。
『本システムのステップ：鑑賞者フロー』
次に、鑑賞者であるステップを説明する。ステップ（１）鑑賞者は、お気に入りの制作者の次の作品を見たいけれど、鑑賞できないでいる状態である。例えば、「この作品の続きをみたいけれど、全然制作してくれないな」と思っている状態である。→次にステップ（２）では、続きを制作して欲しいと思う、お気に入り制作者の”続きを見たい“ボタンを前記鑑賞者は押すことができる。（意思表示を行う）→ステップ（３）データ（ｃ）である制作予定表を前記鑑賞者は受け取ることができる。次に、料金と内容、制作期日を了承して購入するかしないかを判断することができる。→ステップ（４）購入する場合は購入ボタンを押すことができる。この段階ではまだ仮購入であり、先行販売締切日に（制作者の制作合否の意思を待ち）本購入が決まる。本購入が決まればコンテンツ料金が課金される。※又、この段階では鑑賞者に課金を行うが、金額はサイト運営側でプールしたままであり、コンテンツ制作者には振り込まれない。次にステップ（５）では、鑑賞者は、作品完成日に作品を無事受け取り、レビュー（評価）を行う事ができる。もし、前記鑑賞者が作品を受け取る事が出来なければ、課金された金額は前記鑑賞者にそのまま返金される。制作者が無事コンテンツを搬入すればこの時初めて、制作者に金額が振り込まれる。また、プールされた金額はサイト運営側が無断で使えない口座を設ける形か、第三者が介入するかを厳重に行うシステムを含める形にするか、又は、銀行等の機関に委託を行うか対処可能なものとする。※尚、サイト運営側の返金手数料の無駄は、プール期間の利子で相殺できるものとする。利子が余る場合はポイントなどで返金を自動処理により行えるものとする。又、何らかの問題が発生する場合の処置も含むものとする。以上が本発明の要約であり、次に、コンピュータでの処理を述べる。
【００１７】
本発明は作品提供者であるユーザ（１）と、作品観賞者であるユーザ（２）が作品を売買する為の課金システムであって、前記ユーザ（１）が端末（Ａ）より、情報データ（a）を送信して、且つ、記憶装置に格納するステップと、次に前記ユーザ（２）が端末（Ｂ）より、データ（b）を送信し、記憶装置に格納するステップと、次に前記ユーザ（１）が端末（Ａ）より、情報データ（c）を送信し、記憶装置に格納するステップと、次に前記ユーザ（２）が端末（Ｂ）より、データ（d）を送信し、記憶装置に格納するステップと、且つ、コンピュータが複数からなる前記ユーザ（２）の前記データ（d）の合計値を算出し、端末（Ａ）に表示させるステップと、次に前記ユーザ（１）がデータ（e）を送信し、前記データ（e）が合意であればデータ（f）を決済システムに送信し、前記ユーザ（２）に課金される決済ステップと、前記データ（e）が拒否であれば、データ（f）は決済システムには送信されず課金処理が行われないステップと、前記ユーザ（２）に対し課金された金額をプールしておく決済システムと、次に、作品が完成し前記ユーザ（１）が端末（Ａ）と記憶装置を用いて完成作品を搬入し、又、その処理をメール等により前記ユーザ（２）に自動的に通知するシステムと、前記ユーザ（２）が、作品を受領しその内容を確認すると、作品を受け取った信号であるデータ（g）が決済システムに送信されるステップと、データ（g）を受信した決済システムが、前記ユーザ（１）にプールしていた金額を振込むステップと、又、データ（ｇ）が受け取れなかった場合の前記ユーザ（２）へ金額が返金されるステップとを有している。以上により、本課題を解決するものとする。
【００１８】
以上が、本ビジネスモデルの概要である。以下より、既存ビジネスモデルとの相違を述べる。
『１．予約販売システムとの比較』
予約販売システムは「制作者が広告を表示して顧客を集う」ものであり、本システムは、『鑑賞者が作家に続きを見たいと依頼する』ので相違する。本システムは鑑賞者側から制作者へ、コンテンツ制作依頼を行うオーダーシステムであり、その過程で作家と鑑賞者が制作する条件を調整し合うシステムである。
『２.オーダーシステムとの比較』
既存のオーダーシステムとは、顧客から依頼を行う販売モデルだが、作品の続きを依頼している訳ではなく、その目的は、顧客側に明確な制作（デザイン・建築・衣類等）を行ってほしい何かがあり依頼を行う。この場合、自分だけのオリジナルの商品を、制作してもらう時に発生する販売方法である。本発明の先行販売は、オリジナルコンテンツを制作依頼するわけでは無く、鑑賞者が、制作の次回作を観賞可能にするものであり、既存のオー
ダー販売とは、概念そのものが相違する。
『３．投資システムとの比較』
本システムは資金運用を行うのではなく、販売する商品そのものを購入するので異なる。
『４．アマゾン等のオンラインショップとの比較』
本システムでは、顧客が「続きが見たいボタン」を押すと、続きが見たい作品（先行コンテンツ）を「図２９」の様な形で、商品が並ぶカート画面に入れる事ができる。これは、アマゾン等の商品を購入するカート画面と類似しているが、本システムの取り扱う商品は、「現段階では作者自身も作る事を予定していないコンテンツ」であり、「未だ作ることも予定していない、現実には存在していない作品群」の、商品一覧カート画面である。（※アマゾン等オンラインストアに商品として存在してあるのは、予告販売の商品と、通常販売の商品である。）本発明がカートでストックしているコンテンツは、「図２９」の様に先行販売の商品であり、そして、ショップが展開可能なフィールドは、ＩＴ上の概ね全コンテンツが対象である。
＜先行販売＞＝制作者が制作の意図すら行ってない状態の商品
＜予約販売＞＝制作者が制作の意図を持っており予約商品として発表している商品
＜通常販売＞＝今すぐにでも購入できる商品
『５．アンケートシステム及び、マーケティングシステムとの比較』
本システムでは、アンケートを行うシステムではなく、あくまでも制作者側が待ちの姿勢にて、鑑賞者から依頼を受ける商品の販売ストアであり、その交渉過程の中で、顧客のアンケート要素的な意見を聞く要素も含むというだけのシステムである。本システムは依頼を受け付けるものであり、アンケートを行っている訳でも、マーケティングを行っているものではなく概念自体が相違している。
『６．コミュニティーシステム（ＳＮＳ）との比較』
本システムは、SNSとも類似するのだが、SNSにて、商品を販売するのは非常に難しく（又販売機能を禁止しているシステムもある）SNS機能及びそのＦＡＮ機能と、オンラインストアの機能の組み合わせで販売促進を行い商品を販売しても効果が上げられないとされている。
『７．ＦＡＮ機能を取り入れたコンテンツ販売システムとの比較』
他にも本システムと類似のものに、既存のコンテンツ販売システムにてＦＡＮ等の機能を設置しているシステムが考えられる、この場合、コンテンツに対しＦＡＮ機能を付与して販売促進を行い効果を出す方法は、人に対しＦＡＮ機能を付与するよりも押される確率は難しくなる。例えば、ＦＡＮ機能を設置する目的は、販売促進の為の情報配信にあると考えられ、顧客が情報を受け取り損ねない様に予約販売の情報をメールで通知するなどである。これは、本機能と類似している様に見える。しかし相違点は、その情報が広告宣伝情報という性質に於いて異なっているところにある。広告宣伝としての情報を観賞者に送信するのは難しく、一般的には、その対策として公開しないプレミアム情報を用い、会員登録を促す方法が取られる。これは無料でプレミアム情報を提供す
る代わりに、顧客に、予約販売等の情報を送信する方法である。しかし、この場合も、厳密には顧客が欲しいのは、プレミアム情報であり、必ずしも予約情報を望んで、FAN登録を行っているとは言い難いと考えられる。以上により、「コンテンツ販売のＦＡＮ機能」では、販売促進へは限界があった。そして、本システムはSNSではなく、完全なオンラインストアであり送信する情報は顧客の指定に基づいた情報（フォーマットにより規定された情報）であり異なっている。
【００１９】
又、既存には、ＳＮＳの様な、ＦＡＮを募る為のＦＡＮ機能等がある。これは、本発明の次回作要求信号である「続きが見たい」という信号と類似するのだが、この様な機能には様々な種類があり、そのデータの送受信に於いて違いを述べる。（「図４７」参照）

Ａ）
SNSによるＦＡＮを募る機能は、対象が人に掛り（※ユーザーID）、人の繋がりを広げていく情報を表示する機能である。例えば、「私はこの人のＦＡＮです」と言う意思表示を示し、人と人の輪がリンクされ繋がっていくのを促している。この場合の一連のデータの送受信というのは、以下の様なものです。
１．（Ａ）さんが（Ｂ）さんのＦＡＮになる（ユーザーID：Aの記憶情報にユーザーID：Bを格納する）→２．（Ａ）さんのＦＡＮリストに（Ｂ）さんが入る（格納したユーザーID：Bを、Aさんの画面に公開する）。又、今後、（Ａ）さんには（Ｂ）さんの不特定多数の更新情報（記事等の件名）が送信されるようになる→３．（Ａ）さんのFANリストを一般or特定のグル―プに公開（共有）する→４．（Ａ）さんのFANリストを見た（Ｃ）さんが、そのリストの中から気になった（Ｂ）さんをＦＡＮとして登録する（ユーザーID：Cの記憶情報に、ユーザーID：Bを格納する）→（１．に戻る）というフローのデータ送受信である。

Ｂ）
公開ブックマークや、その他、評価ボタン等は、情報を拡散させる目的にあるものである。この場合の一連のデータの送受信というのは、以下の様なものでした。
１．（Ａ）さんが、特定の記事（情報）をブックマーク（あるいは評価）する。（ユーザーID：Aの記憶情報に、ブログ記事を特定する＜タイトル/若干の記事内容/URL等＞が格納される）→２．（Ａ）さんがFANを押して格納した情報が、任意の媒体（機能提供運営サイトの画面、あるいはAさんと、SNSにより繋がっているユーザーID：の端末画面）に公開表示（共有）される→３．次に、（A）さんの、お気に入り情報を見た（Ｂ）さんは、同じ様に情報を気に入りブックマークすると、Bさんの記憶情報に、ブログ記事を特定する＜タイトル/若干の記事内容/URL等＞が格納される。→４．さらに任意の媒体（サイト運営画面又は、BさんとSNSで繋がったユーザー端末画面）に公開表示（共有）される。→５．それを見た（Ｃ）さんも、情報を気に入りブックマークすると、さらに任意の媒体（サイト運営画面又は、CさんとSNSで繋がったユーザー画面）に公開表示される」→（限りなく情報が拡散される）というフローである。又、情報の共有も収集も拡散もしない非公開ブックマークは情報を単にクリップ（整理）しているものであり機能として相違する。
Ｃ）
又、ＲＳＳのFANを募る機能では、お気に入りブログの最新データ（更新記事）を配信し、又は、情報収集を行う目的の機能である。この場合の一連のデータの送受信というのは、以下の様なものです。
１．Aさんが、Bさんのブログを登録する（Aさんの記憶情報に、BさんのブログURLが格納される）→２．又、登録したブログURLの、＜記事タイトル/５０文字程度の記事/その他の評価情報等＞が格納されたコードを格納し、更新が在ると、自動配信、又は、検索エンジンによる収集等で、Aさんはリストより、Bさんのブログ更新記事を確認することができる。
Ｄ）
又、コンテンツに対し掛る既存のＦＡＮボタンでは、鑑賞者は、ＦＡＮボタンを押すと、わざわざサイトに訪問しなくても予約情報を送ってもらえる。又、この機能は、「会員登録機能」とも同等であると考えられる。そしてこの場合の一連のデータの送受信というのは、以下の様なものです。
１．Ａさんは、コンテンツ（Ａ）の何らかの情報を入手するためにＦＡＮボタンを押す（コンテンツIDと、ユーザーIDが、運営システムに格納される）→２．コンテンツ（Ａ）に関する不特定多数の情報が、メール等により送られる（又、不特定多数の中にコンテンツAの予約情報が含まれる）」
Ｅ）本システムの「次回作要求信号」データｂ
１．Aさんが、コンテンツAの次回作を要求する（Aさんの記憶情報に、コンテンツA / ID:0001等が格納される）→２．又、コンテンツAの制作者Bへと、＜コンテンツA/ID:0001 / 次回作依頼＞というデータが送信される。→３．次回作依頼データを確認した制作者Bは、その情報を参考に、コンテンツAの次回制作計画＜コンテンツA/ID:0001/次回作予告データ＞を入力し送信する。→４．Aさんが、コンテンツAの制作計画書を確認する。というフローである。
以上の様に、本システムは、Ａの機能の様に、ユーザー同士の繋がりを広げる機能ではなく、又、Ｂの機能の様に、情報を拡散する機能でもなく、商品を購入する機能である。又、Ｃの機能の様に、ブログの更新（タイトルや記事等情報）を自動で収集する機能でもなく、本システムは、動画、音楽、書籍、画像、ゲーム等の、コンテンツ制作依頼を送信するものである。又、Ｄの機能は、情報を指定しておらず、返信する内容も限定していない情報機能である。
以上の様に上記機能では、本発明が課題とする解決に効果がないものあった。本システムは、「図４８」の様に、特定の情報を顧客が指定して、特定の情報を提供者が返信するものである。又、本システムは、指定のない情報は広告宣伝情報として、指定している情報は広告宣伝ではない情報として区別しているものである。
又、既存にあるＦＡＮ機能と本システムとの違いは「図４８−１」と「図４８−２」の様なものであり、「図４８−２」では、既存、FANボタンの発信というのは、「Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ」の情報が全て一緒であり、違いが無い状態である。これは「Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ」は、＝「Ｚ」という一つの情報であるという認識をしている。つまり、「Ａ」も、「Ｂ」も、「Ｃ」も、＝「Ｚ」という認識をしている。これは例えば、「果物」に対し、「果物」という認識しかしていない状態であるといえる。本発明は、「Ａ」という情報は「Ａ」であり、「Ｂ」という情報は「Ｂ」であり、「Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ」は、「各Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ」の情報であり、違いがあるという事を発見し、その違いを明確化し、効果を出すものであると言える。これは例えば、「果物」に対し、「リンゴ、オレンジ、メロン、イチゴ」と認識する状態である。そして、各オレンジ、リンゴ、メロンは、含まれる成分が異なり、この違いを発見し区別する事は、その固体を認識するだけに足りうる必要と効果があるあらだと言える。
【００２０】
又、本システムの市場フローについて述べる。本システムは「図４４」の様な形で、市場を真逆にするものである。又、その真逆であるフローを、本システムと類似する既存のコミュニティーシステムと、予約や通常販売とを比較して以下に述べる。又、以下内容は、言語化が難しい抽象的なイメージや感覚を述べたものであり、しかしながら、システムの軸となる概念である為、以下に説明を述べる。
『予約販売 の場合のフロー』
「１．こんな商品があったら売れるのではないか？（発案）→２．販売したい→３、コスト障害を感じる→４．事前にどれぐらい売れるかの部数を知りたい（売上予測を立てたい）→５．予約販売を行って確認したい→６．購入してほしい→７．販売達成or販売未達→８．又、ニーズが無くて売り上げが無いと困るので、マーケティング機能も欲しい。→興味を持ってくれた購入予備軍のユーザーを囲い込みたい。過去に購入してくれたお客さんも囲い込みたい（ＦＡＮ機能を設置する。あるいは既存のコミュニティサイトで販売促進する。」
『コミュニティーシステム（ＦＡＮクラブ）の場合のフロー』
「そこそこに商品が売れていて人気が出た。（もしくは人気が在る）→２．顧客の囲い込みをしたい（もしくは顧客からファンクラブを作りたいと自発的に思う）→３．顧客とのコミュニケーションをはかりたい、仲良くなって新密度ＵＰをはかりたい、コミュニティーをつくりたい（もしくは作家とコミュニケーションを図りたい）→４．次の商品を販売する（もしくは次の商品が購入できる）」
『本システムの場合：制作者の視点』
「１．既に商品を制作して販売している自分（未来）→２．購入してくれた鑑賞者がいた（１より少しだけ過去）→２．作品が完成していた（２より少しだけ過去）→３．制作を行った（３より少しだけ過去）→４．制作したいと言う動機が在った（４より少しだけ過去）」
そしてこれを逆さまにすると、以下のステップが導かれる。
「制作したい→生活費と制作時間を捻出したい（この時点では、特に何を作ろうかの企画は決まっていない）→制作予定前より先に売り上げを確定して制作を行いたい→そして制作計画書を発行したらそれを購入してもらえないだろうか？→計画段階で購入しようとする人は誰だろう？→なぜ、購入してくれるのだろう？→９．前回の続きが見たいからだろう→１０．すると過去作品を見ていることが前提である（未来：既に販売している自分）」
以上が、人モノ流れである。※尚、ビジネスでは往々にして逆算して考えるケースが在るため上記は概ねの流れであります。例えば不揃いなケースには以下の様なものが在ります。→「作品作った→販売したい→その為には広告を行わなければ→情報一部公開→広告する→販売達成（次回作を制作する）」あるいは、「作品作った→早く次回作を作りたい→その前に、今作った作品を販売しよう→いろんな人に見て欲しい→その為には一部情報を公開しよう→広告しよう→販売達成」しかし、大きな流れはほぼ同じであります。そして、上記の内容をさらに簡素化したものを以下に述べる。
＜上記３種類のシステムの人・モノ・の流れの軸：さらに簡素化＞
『本システム』
「現在制作したい→生活費あるいは時間を確保したい（販売）→計画書（発案）→続きを見たい→過去作品」
『コミュニティーシステム（ＦＡＮクラブ）』
「人気が出た（ある）→仲良くなりたい（近づきたい）→もっと情報が欲しい（提供したい）」
『予約販売 』
「作品を作った→鑑賞してほしい→一部公開する→購入してほしい→商品引き渡して次回作の制作」
＜上記３種類のシステムの人・モノ・の流れの軸：さらに抽象化＞
・本システム          
「制作→課金→一部情報→続き見たい→過去作品」
・コミュニティーシステム
「人気過去作品→ＦＡＮ（続き見たい）→一部情報（発案）→課金（販売）→次回制作」
・通常＆予約販売システム
「作品有→見て欲しい→一部情報公開→購入してほしい→次回作制作」
＜上記３種類のシステムの機能的フロー＞
先行販売                「過去作品＋ＦＡＮボタン＋販売前作品情報＋課金機能＋制作搬入」
ＦＡＮクラブ            「過去作品＋ＦＡＮボタン＋販売前作品情報＋課金機能＋制作搬入」
予約販売（消費者視点）  「作品無→広告→一部情報公開→課金→完成商品提供」
予約販売（提供者視点）  「制作搬入→広告→一部情報公開→課金→完成商品提供」  
又、上記の予約販売の鑑賞者フローは、広告に興味を持ち、リンクを伝って商品の一部情報を見て、次に購入し、その後、完成作品を観賞するという形になります。しかし、消費者は、オンラインショップで商品を購入する際に、又、広告から入る場合ではなく、消費者が自ら特定の欲しい商品を求めていて、それを販売しているショップを探しているケースもあるためその場合のフローを以下に述べる。
＜機能的フロー：鑑賞者目線＞
「作品無し→作品を販売して欲しい（ストア探し）→商品の一部情報公開→
購入意思決定（カート）→完全商品」
↓
＜さらに簡素化する＞
「商品無し→販売（課金）→一部情報→カート→完全商品」
↓
＜さらに人・モノ・フローに置き換える＞
「完全商品→カート→一部情報→課金→商品無し」
この場合、消費者が広告から入らない場合のトリガーになる部分（ＦＡＮ機能になる部分）は、「カート」ボタンになり、消費者が広告から入る場合は、「広告リンク」ボタンが、トリガー（ＦＡＮ機能）になります。これは消費者から特定の商品を求めていた場合、「続きを見たい」という意思決定ボタンは「カートへ入れる」ボタンになるということになります。「カートへ入れるボタン」と、「広告リンクボタン」が、消費者と提供者のその時の状態で、質的な役割が変化しています。そして、さらに一連のフローをイメージとして抽象化すると以下になります。
＜機械的フロー＞
ＦＡＮクラブ  「作品有→トリガー→中→トリガー→作品無」
予約通常販売  「作品無→トリガー→中→トリガー→作品有」
先行販売      「作品有→トリガー→中→トリガー→作品無」
＜人・モノのフロー＞
ＦＡＮクラブ  「作品有→トリガー→中→トリガー→作品無」
予約通常販売  「作品有→トリガー→中→トリガー→作品無」
先行販売      「作品無→トリガー→中→トリガー→作品有」
（※トリガー＝意思決定）
以上の様に、本システムの、軸となるフローが、既存にある、コミュニティーシステム、予約＆通常販売と、真逆になっております。（「図４５」参照）
【００２１】
次に本発明の「続きを見たいボタン」の概念的な説明を、本システムと類似する既存の「カートボタン」、「ＦＡＮボタン」と比較しながら述べる。
『オンラインショップのカートへ入れるボタン』
既存のカートボタンの性質は、「購入前＋整理機能」である。そのフローとして、「購入前整理機能（カートへ入れる）」を押してから、「購入する（最終決済意思）」までの消費者の意思とそれに掛る情報（物）の変化（流れ）は、「カートボタンを押すと＝購入したい商品情報（通常又は予約販売）を≪完全に指定≫し、大量にある商品の中から選別（整理）する」そして、カート内に入ると「カートボタンで≪完全に指定≫した商品情報が表示される（これは先よりも整理された状態である）」。そして「選別して表示された商品（情報）の中からさらに、最終選別を行い最終決済意思購入ボタンを押す」というステップである。消費者は、カートボタンにより特定の情報（商品）を≪完全に指定≫し、カート内で、その消費者が≪完全に指定≫した情報をそのまま表示し、次に消費者は購入ステップを踏む。
『本システムの（続きを見たい）ボタン』
続きを見たいボタンの性質は、「アンケート的要素＋リピート的（評価的要素）＋（オーダー的）購入前意思＋情報整理機能（ＲＳＳ）」である。そして、そのフローは、「オーダー意思＋整理機能ボタン（カートへ入れる）」を押してから、「購入する（最終決済意思）」までの消費者の意思と、それに掛る情報（物）の変化（流れ）は、「（続きを見たい）ボタンを押すと＝購入したい商品（情報）を≪緩やかに指定≫し、大量にある商品の中から選別（整理）する」そして、本発明のサイト内に入ると「（続きを見たい）ボタンで≪緩やかに指定≫した商品（情報）が表示される（これは先よりも整理された状態である。又、先のボタンから情報表示までに小から大の時間差有）」そして「選別して表示された商品（情報）の中からさらに、最終選別を行い最終決済意思購入ボタンを押す」というステップである。消費者は、（続きを見たい）ボタンにより特定の情報（商品）を≪緩やかに指定≫し、本発明サイト内で、その消費者が≪緩やかに指定≫した情報をそのまま表示し、次に、消費者は購入ステップを踏みます。（※緩やかに指定するとは、商品が、未だ無いコンテンツの為、完全に指定していると言えない為、“緩やかに”とした表現である。）
※尚、カートへ入れる段階が、“ゆるやか”に購入を指定するという、“ゆるやか”とは、対象商品が未だ無いコンテンツである為、購入しようとする商品が無く（制作予定表すら無い状態である）、指定をしたくとも指定できない状態であるという意味の、“ゆるやか”である）しかし、どの過去作品の次回作なのか？という過去作品に対しては厳密に指定するものとする。（「図５１」参照）
『コミュニティシステム等のＦＡＮボタン』
ＦＡＮボタンの性質は「情報需要意思＋整理機能ボタン」を押してから、何らかのコンテンツに出会い「購入意思（最終決済意思）」を押すまでの消費者の意思と、それに掛る情報（物）の変化（流れ）は、「ＦＡＮボタンを押すと＝ある特定の情報（しかし不特定情報として需要する情報）を、購入商品として≪指定は行わない≫形で、大量にある情報の中から選別（整理）する」そして、コミュニティサイト内に入ると「ＦＡＮボタンで、購入商品として≪指定は行わなかった≫情報である、特定の情報（しかし不特定情報として需要する情報）が表示される。」（これは先よりも情報は整理された状態である）そして「選別して表示された特定（不特定）の情報の中からさらに、購入したい商品（情報）を見つけると、「カートへ入れるボタン」により購入したい商品（情報）を≪完全に指定≫し、大量にある商品の中から、又さらに選別（整理）する」そして、カート内に入ると「カートボタンで≪完全に指定≫した商品（情報）が表示される」（これは先よりも整理された状態である）そして「選別して表示された商品（情報）の中からさらに、最終選別を行い「最終決済意思」ボタンを押す」というステップを踏みます。これは、既存にある「コミュニティー＆オンラインショップ」の構造になります。
以上の様に、信号を送信してから返信される処理の内容が既存の機能とは異なっております
【００２２】
以上の既存ビジネスモデルとの相違から、本システムは、経済モデルそのものが過去に一つも事例の無い経済モデルである。
【発明の効果】
【００２３】
この方法により制作者であるユーザ（１）は、事前に売上を確定させる事ができるので、安心して創作活動に打ち込む事ができる。イメージとしては、両者の合意が必要なオークションの様なものであり（しかし商品がないのでオークションとは異なる）、オーダーの様なものであり（しかし購入者の細かく希望する商品を制作しないので依頼型のオーダーとは異なる。この“細部の細かく希望する商品を制作しないと言う意味”は、コンテンツの依頼とは、あくまでも“A”という作品の次回作という漠然とした依頼であり、作品Aという指定はできても内容事態までは顧客が細かく指定できない顧客の想像を越えた創造性を要する製造である、という意味を指す）又、資金調達の様なものであり（しかし利息ではなく商品を購入するので異なる。また、作品の搬入が完了しないと入金は行われないので資金調達とも異なる。）又、制作者からすると資金調達という言葉であるが投資家からすると投資システムという言葉が厳密である。
【００２４】
又、予約販売の様なもの（しかし販売の決まった商品の予約ではないので異なる。又、この“販売の決まった商品”という言葉が指しているのは、これは、一般的な予約販売の認識は予告通知を行って中止を行わないものが殆どの予約販売であるため、この認識を基準に述べるものである。その為、一般的な予約の認識を基準にして、本発明とは異なる事を述べるものであります。予約販売で鑑賞者を集い、その後、購入者の人数が足りなければ予約を取り下げるシステムは、周知のシステムではなく、「予約の発表を行う＝（イコール）既にそれは、ほぼ販売が決まっているのと同等である」という認識がまず前提にあり記載するものである。そして、そうすると「販売をしたいという意思が決まっていない＝（イコール）制作者が予約通知を行っていない」という状態のことであり、「販売の決まった商品ではないので異なる」という意味は、「本システムの扱う商品は、予約広告（販売をしたいという意思）を行っていない商品なので異なる」ということを指します。本システムは、作家がまだ制作の予定もしていない段階から、制作する作品を先行して依頼する事のできる販売システムであり、鑑賞者から、制作者へ依頼を行う販売であるという事を意味しております。（「図９」参照）又、あくまでも、（データa）の次回作の購入に至る、購入及び制作の合否は、依頼を行う過程に生じる交渉ステップに過ぎないものであり、予約販売とは異なるものである。
【００２５】
又、周知認識の予約販売は、概ね、販売が決まった商品に対して、販売側と購入者側の品切れによる販売ロスを避ける目的にあり、本発明は、販売ロスを避ける為だけの効果を目的とするものではない。又、予約販売にはキャンセルという仕組みもあるのだが、この機能が成立しているのは感覚的にも、交通サービスやホテル、イベント等のサービスを受ける日付が限定されるものに対して猶予を設けているケースである。そしてこの場合、販売者は事前にキャンセルを行えば、空いた分の補充が可能なので返金できる仕組みである。その為、本発明には、少額の為に、キャンセルを行う理由がなく、又依頼という要素が含まれるので、基本的には、購入すると送信した時点で責任を持つものとする。そして、本機能は、制作者に作品を制作してもらう意味もサービスの中に含まれるので予約販売とは性質が異なる。又、コンテンツ販売では、通常、予約を承った時点では課金はされないのが一般的である。しかし本発明は、鑑賞者から制作者へ依頼を受けて、その過程に相互間の交渉を行うものである為である。例えば、これは、鑑賞者が「Ａを作ってください」とすると、→制作者は、簡単なラフスケッチを見せ、「これでよろしいでしょうか？」と確認する→すると鑑賞者は、「購入します・購入しません」という流れである為、依頼という要素が強く、先行コンテンツ販売という、鑑賞者と制作者の間のバランスを考えた際に、「購入します」と送信した段階で、課金を行う形を取るものである。しかしながら、制作者は、未だ作品を、鑑賞者に渡してはいないためプールという形で処置を取るものである。又、販売を予定していない段階から、作家の制作する作品を先行して購入する課金システムは現状存在せず、従来の方法では作家は安定した収入の確保を行い制作をする事が難しいという現状にあった。
【００２６】
又、作家の制作する作品を先行して購入する課金システムというのは、制作者が制作を予定していない段階から、先行して依頼を行う行為を指し、そして、課金システムというのは先行コンテンツ（制作者が制作の予定していないコンテンツ）のオンラインストアであるという事を指しているものである。その為、本発明は完全なオンラインストアであり、鑑賞者が、次回作を依頼した過去作品（データa）は、ＳＮＳシステムの様に、公開共有され、情報が拡散されるものではなく、オンラインストアの、カートへ入れるボタンと性質が類似する。（「図１１」「図１２」参照）又、鑑賞者と制作者の間には、ＳＮＳの様なユーザー間の繋がりはないものである。又、先行して投資することのできるシステムであることから、投資システムの様な…、と述べるものである。又、オークションの様であるという言葉が指す意味は、オーダーでありながらも、鑑賞者の数が足りないと（合計の購入金額が上がらないと）制作実行が行われないという事を指し、（既存のオーダーとは、オリジナルの一つしかない製品を製造してもらう際に行う販売システムであり、本システムは顧客が求めるオリジナル製品を製造するわけではない）又、本発明によれば作家が生活の目途を立たせながら創作ができる環境が実現でき、制作者の自律を容易にするコンテンツ市場が可能になる。又、本発明はプロに留まらず、広く誰にでも参加可能なシステムである。
【００２７】
段落「００１２」の様な形で、作品を制作する予定をしていない状況においても鑑賞者側から制作依頼が入る効果が得られるということは、観賞側のメリットとしては、過去にお気に入りの作品が在ったにも関わらず様々な事情により見る事が不可能になってしまった作品や、又、過去のその時点においては、作品が評価されなかった作品であり、時間がたつ事により観賞したくなった作品や、又、現在、作家が制作活動すら行っていない場合の作品であっても、鑑賞者側から続きを見たいという情報を発信し、続き作品を制作依頼（促す事）ができる。そして、それは作家の応答の有無に関わらず（作家とのＩＤが一致している等の本人確認ができる限り）鑑賞者側から依頼が行えるシステムであり、鑑賞者側は、続きが見たい作品をストックする事ができる。そして、そのコンテンツが作成された期間は、作家が生存している限り、どこまでも過去にまで遡る事が可能であり（※例えば２０年〜５０年前等）、作家にとって現在、ＨＯＴな制作の作品の如何に関わらず、作家の過去制作した作品が全対象となる。その為、期間に縛られる事無く、顧客のニーズをくみ取れる自由度があり双方にメリットがある。
【図面の簡単な説明】
【００２８】
【図１】ユーザ（１）とユーザ（２）とで行われる売買に於けるフローチャート図
【図２】「続きが見たい」ボタン
【図３】「続きが見たい」制作者を一覧表示した画面
【図４】先行販売作品の一覧表示した画面
【図５】制作計画書（作品予告データ）の表示画面
【図６】先行販売作品の内容表示画面
【図７】購入後画面（参考例）
【図８】鑑賞者と制作者の作品売買におけるデータの送信のフロー
【図９】鑑賞者から先行して売買が始まる先行コンテンツ販売における図
【図１０】続きを見たいボタン配布図（イメージとしてRSS型オンラインショップである）
【図１１】既存オンラインショップのカートボタンとの比較
【図１２】先行コンテンツオンラインストアのイメージ図
【図１３】先行販売システムの全体構成図(※記憶装置１０１詳細図)
【図１４】先行販売システムの全体構成図（※受注サーバ６０１詳細図）
【図１５】各コンテンツの次回作依頼が送信された時の鑑賞者と制作者の相互間のステップ図        （※鑑賞者と制作者の間のデータ送受信は、各作品IDがヒモ付けられている図）
【図１６】制作者が鑑賞者群に次回作情報データCを送信する図        （※各次回作データが作品IDでヒモ付けられた各鑑賞者へ送信される）
【図１７】先行コンテンツ（依頼商品）と宣伝広告コンテンツとの明確な区分がされている図
【図１８】「続きを見たい」ボタン配布パターン１（制作者の手作業での設置）
【図１９】「続きを見たい」ボタン配布パターン２（任意サイト運営者側の設置）
【図２０】過去作品著作ＤＢ内のデータ（ａ）の制作者ＩＤ認証済データと認証未処理データ
【図２１】過去作品登録における鑑賞者からのステップと制作者からのステップのフロー図
【図２２】続き依頼であるデータ（B-2）の送信ステップ（画面）        （※「続きが見たい」ボタンが設置されている場合とされていない場合。又、本システム          に過去著作情報が登録されている場合とされていない場合におけるステップ）
【図２３】続き依頼であるデータ（B-2）の送信ステップ（画面）          （本システムに制作者側からの登録が無い場合、鑑賞者からの登録を行うステップ１）
【図２４】ボタン有無と、過去著作ＤＢ１０１内のデータ有無とに於いて、          ４つのパターンからのデータｂの送信ステップ
【図２５】続き依頼であるデータ（B-2）の送信ステップ（フロー図）（本システムに制作者側からの登録が無い場合の鑑賞者からの登録を行うステップ２）
【図２６】制作者の本人確認を行うＩＤ認証方法のパターン
【図２７】制作者の本人確認を行うＩＤ認証フロー
【図２８】依頼情報データベースに格納されるデータ（B-2）
【図２９】続き依頼（データB−2）を受けて、次回作（データｃ）を送信するフロー
【図３０】続き依頼を送信した後の、各３つの画面図（制作者画面、鑑賞者画面、本システムサイト）
【図３１】制作者端末Ａの、依頼データB-3の表示画面（パターン１とパターン２）
【図３２】依頼画面から、既定のフォーマット画面に入り、次回作情報を入力送信する図
【図３３】先行コンテンツサイト画面（※本システムのメイン画面）
【図３４】先行コンテンツサイト画面のID認証済みと未処理の２つの過去情報が検索表示される図          （※無料公開コンテンツＵＲＬは制作者管理による）
【図３５】制作者ログイン画面であり、本システムに制作者ＩＤは登録しているが、過去作品情報登録漏れがあり、鑑賞者側から先に過去作品情報の登録が在った際の作品認証画面。
【図３６】一連の制作者フローと一連の鑑賞者フロー
【図３７】課金システムのフロー図（プール型と積立型）
【図３８】課金システムのフロー図（プール型と積立型の混合型）
【図３９】鑑賞者と制作者の契約タイミング調整データ
【図４０】タイミング調整データを使った統計図
【図４１】コンテンツ制作時間相場表
【図４２】契約タイミング調整フロー
【図４３】本発明の課題
【図４４】本発明が課題を解決する方法である、真逆のビジネスモデルの概要
【図４５】本ビジネスモデルの軸の構造のイメージ図
【図４６】市場と機能のフローイメージ図と、提供者と顧客の力関係の比較
【図４７】既存FANボタンとの比較図１
【図４８−１】既存FANボタンとの比較図２
【図４８−２】既存FANボタンとの比較図３
【図４９】カートに入れる前とカートに入れた後の図
【図５０】データＢ群の詳細フロー
【図５１】厳密にコンテンツを指定する図
【図５２】同一制作者及び同一コンテンツの過去作品バリエーションの選択可能性
【図５３】購入フロー及び、機能のまとめ図
【発明を実施するための形態】
【００２９】
以下、本発明の実施形態を図１に基づいて詳細に説明する。尚、図示の形態は説明を容易にする為のものであり、これにより本発明が図示の形態に限定されるものではない。
【００３０】
本発明の課金システムは、作品制作者であるユーザ（１）が端末（Ａ）を介して、情報データ（a）を記憶装置に蓄積し、鑑賞者であるユーザ（２）は端末（Ｂ）を介して、前記データ（a）を確認する。前記ユーザ（２）は、お気に入りの作家を見つけると、自身が作品を観賞しているＦＡＮであり次回作を希望している意思表示を表すデータ（ｂ）を送信することができ、本システムはそのデータを記憶装置に記憶させる。又、前記ユーザー（１）は前記データ（ｂ）を基に、自身の次回作を要求している見込み顧客の確認が容易になる。
【００３１】
又、前記ユーザー（１）は、次回作品の予定である情報データ（ｃ）を発行する。この次回作と言う言葉が意味するのは、過去作品データaの次回作である。つまり、鑑賞者は、過去作品データaを観賞し、それを元に、前記データｂを送信し、それを受けて、制作者が、過去作品データaの次回作を制作するものであり、このデータｂは、「続きを見たい」（リピータ的要素）という信号を指している。そして、「続きが見たい」という、言葉が指す意味は、特定の過去作品aに対して、続きが見たいと述べるものであり、○○の続きが見たいという、○○が先に存在している事が前提である。つまり、作品Ａという、続きが見たくて、鑑賞者は、データｂを発信し、制作者は、作品Ａの次回作であるデータ（ｃ）を送信するものである。これは、鑑賞者は、情報を指定していると言う事を指す意味が含まれる。制作者が発信する、データＣとは、鑑賞者が、指定したデータaの次回作であり、あくまでも、作品Ａの続きを下さいと、鑑賞者が発信したら、「作品Ａ‘でどうですか？」という制作者側の返信の信号であり、データaと、データｂと、データｃは、作品ＩＤによって、ヒモ付けられているデータである事が前提である。過去作品データaは、（作品ＩＤ：０００１）であり、続きが見たいデータｂは（作品ＩＤ：０００１）の情報を送信するものであり、次回作データｃは、（作品ＩＤ：０００１）を返信するものである。また、データｃは、鑑賞者からの信号データｂ（作品ＩＤ：０００１）が届かないと、（作品ＩＤ：０００１）であるデータｃを送信できないという事を指す。
【００３２】
そして、過去作品Ｂを観賞し、続きが見たいと希望するなら、作品Ｂの次回作を提供するものであり、過去作品Ｃを観賞し、続きが見たいと希望するなら、作品Ｃの次回作を提供するものであり、鑑賞者から制作者への注文である。（「図８」参照）そして、データｃを端末（Ａ）を介して、記憶装置１０１に格納すると端末（Ｂ）に表示させる。ユーザー（２）は前記データ（ｃ）を確認すると作品を購入するかどうかの意思決定を行う。尚、前記データ（ｃ）は○○という作家の次回作であるというだけの情報であって作品の中身は現時点では分からない。これは既存のオーダーという概念の枠を超える、創造性が在る製造であるという事を指しているものである。そして、前記ユーザ（２）は過去作品情報である前記データ（a）を参考にして、お気に入りの作家に次回作を依頼するという形式である。そして、この“次回作を依頼する”というのは、ちょうど、レストランで、メニューリストを確認して注文を行う行為と類似する。過去作品情報であるデータaとは、レストランのメニュー票の様なものでり、鑑賞者が、注文したメニュー（コンテンツ）は、注文されて初めて制作者が、作り始めるというフローである。（※しかし本システムは、飲食店ビジネスとは明らかに相違する）。又、段落「００２５」のオーダーの様なシステムであるとは、このレストランで、注文を行う行為を指し、鑑賞者から制作者へ次回作を依頼する行為を指す。そして、次回作を依頼するというのは、特定のコンテンツを“指定”するということを指している。その“指定”は、過去作品データaにより、どの作品の次回作が見たいのか？を“指定”することができる。これは、カートへ入れるボタンと同等であり商品を指定して選択する。
【００３３】
又、制作時間は１カ月以内の短期のものもあれば１年という様な長期に渡る場合もある。そして前記ユーザー（２）が購入を選択した場合は、購入の意思であるデータ（ｄ）を端末（Ｂ）より送信を行い記憶装置に記憶させる。コンピュータは自動的に複数の鑑賞者からなる前記データ（ｄ）の合計値（人数、金額）を計算し、端末（Ａ）に表示させる。前記ユーザ（１）が端末（Ａ）に表示された前記データ（ｄ）を確認し、もし希望に見合う数値に到達すれば制作合意の意思であるデータ（e）を記憶装置に送信する。合意であるデータ（e）を受けたコンピュータは、支払い情報データ（f）を決済システムに送信し決済システムは前記ユーザ（２）に対し課金処理を行う。また、もし前記ユーザ（１）が希望する数値に満たない場合は、拒否の意思である前記データ（e）を送信することができる。この場合、前記データ（f）は決済システムに送信されず前記ユーザ（２）に対し課金処理は行われない。そして、以上より本発明の課金システムの特徴として、制作者は売上金を得る為には、全力で予定日に間に合う様に作品を完成導入しなくてはいけなくなる。（※完成期日を過ぎると、購入者に返金されてしまう為）制作者側の、制作実行の判断はコスト的障害ではなく時間的障害になる為、購入者が少ない場合、時間が長期になり、購入者が多ければ、時間が最短になるという設定を行う形もありえる。その為、制作者の制作実行判断は、時間と購入者の兼ね合いによる判断になる。導入日を早く設定しすぎて、未達になれば収益が得られず、搬入日が遅すぎる設定なら（待たせたら）顧客を減らし購入率を下げる可能性がある。（尚、本システムにより、売買を行う鑑賞者及び制作者は、本システムにログインしている事が前提である）  
【００３４】
次に作品が完成すると、前記ユーザ（１）は作品をアップロードするために端末（Ａ）を介して、作品を記憶装置に記憶させる。又、その処理がなされた情報がメール等により前記ユーザ（２）に送信される。そして、前記ユーザ（２）が、作品を受け取る処理が行われると、その処理がなされた信号である情報データ（g）が決済システムに送信される。決済システムは前記データ（g）を受信するとよってプールしていた金額を前記ユーザ（１）に振込む処理を実行する。また前記データ（ｇ）の確認がなされない場合、例えば期日以内に作品が搬入されなかった等の制作者側に過失のある場合は、課金された金額は前記ユーザ（２）に返還される。また逆に期日内に搬入したとしても前記ユーザ（２）が購入した事を忘れてしまった場合等、ケースに応じて前記ユーザ（１）に過失が無いと判断された場合は猶予期日を設けた上で前記データ（ｇ）を決済システムに送信し前記ユーザ（１）に金額が振り込まれる。
【００３５】
尚、上記決算手段は全てクレジット決済によるものであるが、金融機関での振込の形態をとる場合や人的手段を要する場合は上記形態に限られるものではない。振込課金である場合の課金方法は別途にプール先である振込口座を設ける等の処置も可能であるし、また同一の口座でも可能であるが個々に応じた対応を取れるものとする。クレジット課金以外の方法である振込に関しても、前述「００３４」の方法と同じものである。
【００３６】
又本発明は、決済後の前記ユーザ（２）による評価・レビュー機能も有するものとする。又、本ビジネスモデルは基本的には、ある一定の信用（質量）を超えないと、“続きを見たい”とは思われないという前提があるのだが、しかし商品が不良品であった場合は返品交換がある。又、不良品の判断は少額であり購入者が多いであろうことを考えたら、比較的容易に判断がつくと考えられ、レビューや、コメント等を指標に判断を行えるものとする。
【００３７】
次に、図２以降を順に説明する。「図２」は、データ（b）の「続きが見たい」ボタンである。鑑賞者である前記ユーザー（２）は、お気に入り制作者に対し、意思表示として「続きが見たい」ボタンを押す事ができる。又、この「ボタン」というのは、本システムでは過去にあった動画、音楽、画像、書籍、ゲーム等の、全てを公開（無料公開含む）できるデータベースを持ち合わせてはいない事が前提である為、「図１０」の様に本システム以外のサイトへも広く他サイトへ配布することが可能である事を示している。又、コンテンツそのものの観賞は、サイト以外からであったとしても、過去作品関連情報（題名、制作者名等）は、販売を行う際には必ず必要である為、過去作品データリストへの登録が必要である。次に「図３」は、前記ユーザー（２）の、「続きを見たいボタン」を押し登録を行った制作者の一覧管理画面である。データＢ’は「続きを見たい」登録の登録解除を行うボタンである。次に「図４」は、先行販売が行われるコンテンツが一覧表示された画面である。続きを見たいボタンを押した鑑賞者の次回制作予告データを「図４」の画面で受け取ることができる。次に「図５」は、先行販売するコンテンツの次回作計画書データ（ｃ）の内容である。次に「図６」は、次回作計画書であるデータＤ’（データｃと同一）を表示した販売画面である。尚、データＤ’に含まれる情報の延期有無や延期の対応方法というのは、例えば、１サイクルを３０日と設定するならば、まず延期の有、無を選択し、回数（何サイクルか）を設定する。１サイクル＝３０日と設定するならば、３回までと制作者は先に設定することができる、というものである。もし、設定をしない場合（延期無の場合）は延期はできない。又、延期有だとしても、制作期日をオーバーすれば、コンテンツ料は制作者に振り込まれず、鑑賞者へ返金される形になる。又、先行販売受付期間とは、購入者を募集する期間であり、鑑賞者はこの期間内にコンテンツを先行して購入することが出来る期間である。次に「図７」は、購入後画面である。又鑑賞者が、コンテンツダウンロードを忘れない方法として、購入履歴を表示する画面を設ける処置も取れるものとする。以上が図順に説明した本発明の機能である。
【００３８】
以上は、本システムの軸となる構成であるが、詳細部分についての幾つかの課題があり、以下により解決方法を述べる。
【００３９】
１つ目は、「続きを見たい」ボタンを配布する方法である。２つ目は、過去作品データ（A−１）を、どのように登録し、どのように参照を行うのかの詳細なフローである。３つ目は、制作者より先に、鑑賞者等から過去著作情報が登録された場合に、過去作品データaにおける制作者ユーザーが同一である照合（ＩＤ認証）をどのように行うのか、と言う問題である。４つ目は、次回要求作の要求を行うデータｂに関しての詳細なデータの送受信の処理である。５つ目は、データCを返信する詳細な処理である。６つ目は、課金システムに於いて、制作者と鑑賞者と、本システム運営側の、各者、条件のバランスの調整における問題である。７つ目は、契約タイミングの調整問題である。
【００４０】
そして、４つ目の課題である、次回作の要求を行うデータｂに関しての詳細なデータの送受信を述べる。データB−１は、データｂの簡易情報であり、データB−２は、データｂの詳細情報であり、データB−３は、データB−２より算出した分析データである。そして「図２２」は、データｂの送信ステップ画面である。画面１０は、「続きが見たい」ボタンが設置されている場合であり、画面１１は、設置されていない場合である。そして、過去著作情報ＤＢ１０１に、登録が在る場合は、画面１２へ進み、登録が無い場合は、画面１３へ進む。そして画面１２又は画面１３にて、データB−２を入力すると、送信ボタンを押すことにより依頼ステップは完了する。データB−２の送信を終えると、観賞者は自身のログイン画面カート内（依頼一覧）に、先行依頼を行ったコンテンツが入っていることを確認できる。画面１５は、カート内画面の、データｃの要約が表示された一覧であり、画面１６は、カート内画面の要約無しの一覧である。又、データB-2は、ログイン後の登録設定により省略も可能である。
【００４１】
次に、受注サーバ６０１の機能構成として、「図１４」の説明を述べる。受注処理サーバ６０１は、過去著作登録処理（１２）と、制作者ID認証処理（１１）と、依頼情報送受信処理（１３）と、次回作送受信処理（１４）と、受注処理（１５）と、ボタンコード生成処理（１６）と、搬入（アップロード）処理（１７）と、を有している。そして過去著作登録処理（１２）は、制作者又は鑑賞者より、過去著作ＤＢ１０１へ、データ（A−１）の格納を行う一連の処理である。制作者より登録された過去著作データ（A−1）は、ID認証処理済みデータとして、観賞者より登録されたデータ（A−１）は、ID認証未処理データとして、振り分けられる。制作者ID認証処理（１１）は、制作者のID認証を行う一連の処理であり、ID認証未処理データをID認証済データへの移行を行う処理である。依頼情報送受信（１３）は、データ（B群）を受信し依頼情報データベース２０１へ格納を行い、データ（B−２/Ｂ−４）より、データ（B−３）を算出し、制作者端末へ送信する一連の処理である。次回作情報送受信処理（１４）は、制作者の依頼画面フォーマットより入力されたデータ（ｃ）を、次回作データベース２０２へ格納し、鑑賞者端末へ送信する一連の処理である。受注処理（１５）は、鑑賞者の「購入する・しない」、制作者の「制作する・しない」の合意の信号を送受信する等、その他メールを自動配信する等、受注に関する諸々の処理である。ボタン配布処理（１６）は、「続きを見たい」ボタンの生成等の一連の処理である。搬入処理（１７）は、制作者が、完成作品を完成作品ＤＢへ格納する処理、及び、鑑賞者が完成作品をダウンロードする処理、及び、積立金DBサーバ（あるいは決済システム）に信号を送信する等の一連の処理である。又、作品が完成して、完成作品DB３０１に格納されると、自動的に過去作品著作情報DB１０１に完成作品のデータ（A−１）が格納される。又、積立金DBサーバは積立額を算出する。又、時間調整DBサーバは契約タイミングを調整するデータを算出し、諸々の時間調整処理を行う。そして以下により詳細を述べて行く。
【００４２】
１つ目の課題である「続きを見たい」ボタンを配布する方法として、「図１８」は、「続きを見たい」ボタン配布パターン１である。ステップ１では、制作者は自身の過去作品の一覧をDB101へ登録する。ステップ２では、「コード生成」処理により、作品ＩＤが埋め込まれた「続きを見たい」ボタンの、コードを生成することができる。生成されたコードにより、制作者自身で、任意のコンテンツ投稿サイトに、手動で設置を行うことができる。次に、「図１９」は、「続きを見たい」ボタンの設置パターン２である。これは任意のサイト運営者が、コンテンツ投稿システム全体に設置を行うパターンである。任意のサイト運営者は、本システムが配布を行っている「続きを見たい」ボタンの所定コードの場所に、制作者名と作品名を格納するコードを埋め込み、任意サイトオリジナルのコードを生成することにより設置可能とする。又、他にも、指定の著作情報と作者名のデータが送信される形であればこれに限るものではない。尚以上は、＜ボタンコード生成処理（１６）＞である。
【００４３】
そして２つ目の課題である過去作品データaの詳細を述べる。「図２１」は、データ（A−１）を、登録する２つのステップであり、制作者側からの登録と、鑑賞者側からの登録の２つのパターンがある。そして、「図２０」は、過去作品著作ＤＢ内のデータ（A−１）の内、制作者ＩＤ認証済データと認証未処理データの２つのデータを表した図である。上方（Ａ）のデータ（A−１）は、制作者からデータ（A−１）を本システムに投稿したデータであって、本人確認（ＩＤ認証）が済みのデータである。そして、下方（Ｂ）は、制作者が過去著作情報データベース１０１に、データ（A−１）を登録していないケースであって、鑑賞者側から次回作を観賞したい過去著作情報データ（A−１）の登録を行ったデータである。そして下方（Ｂ）は、制作者の本人確認（ＩＤ）認証は行われていないID未処理データである。又、データ（A−１）は、鑑賞者だけでなく、本システム運営側からの登録も可能である。尚、以上は＜過去著作登録処理（１２）＞である。
【００４４】
そして３つ目の課題として、鑑賞者から過去作品情報を、過去著作情報DB１０１に登録した際に、制作者ユーザが、過去作品の制作者である事を、照合（ＩＤ認証）する処理を述べる。「図２６」は、制作者の本人確認を行う為のＩＤ認証方法のパターンである。
＜パターン１＞
制作者が個人であって任意の他サイトにコンテンツを投稿している場合。任意サイトのログイン画面から、所定の認証コードを送信して本人確認をＯＫとする方法である。所定の認証コードとは、「図２７」に記載のステップにより取得するコードであり、制作者が本システムから、過去著作情報（A-1）を参照し、所定の認証コードを生成する。これは、本サイト画面からでも、本システムから、制作者へメール通知によりコードを配信する方法でもかまわない。
＜パターン２＞
制作者が企業であって、自サイト等でコンテンツを配信している場合。何らかの情報により確認を行う。又、企業であれば、アマゾン等の大手流通サイトを使用していると考えられ、大手流通サイト等のログイン画面から所定の認証コードを送信する方法でも可能である。
＜パターン３＞
制作者が個人であって、デジタルコンテンツではないコンテンツであり、さらに任意サイトのどこにも表示していない場合。著作者本人であることを証明できる、何らかの情報により確認を行う。
以上、３つのパターンが考えられるが、本人が確認できる形であればこれに限るものではない。尚、以上は＜制作者ID認証処理（１１）＞である。
【００４５】
又、「図３４」は、鑑賞者が本発明サイトにて、過去作品情報を検索した画面である。検索を行うと、ID認証済みとＩＤ認証未処理の２つの過去作品情報が表示される。又、無料公開コンテンツＵＲＬの表示は、ID認証済である、制作者管理データに限られている。
【００４６】
又、「図３５」の、画面１７のパターン５は、制作者の依頼確認画面である。この画面では、制作者は既に本システムにＩＤ登録を行っているのだが、過去作品情報に登録漏れがあり、一部の過去作品情報が、後から、鑑賞者側にて登録が行われたケースの処理である。この場合、制作者はID認証を行わないといけないのだが、既に、鑑賞者側が登録した過去著作情報が、過去に揃った認証可能なデータである場合、制作者依頼画面から承認ボタンを押すだけで、ID認証の省略が行える処理である。以上は＜制作者ID認証処理（１１）＞である。
【００４７】
そして、４つ目の課題である、次回作の要求を行うデータｂに関しての詳細なデータの送受信を述べる。データB−１は、データｂの簡易情報であり、データB−２は、データｂの詳細情報であり、データB−３は、（データB−２／データB−２／データB−４）より算出した分析データである。そして「図２２」は、データｂの送信ステップ画面である。画面１０は、「続きが見たい」ボタンが設置されている場合であり、画面１１は、設置されていない場合である。そして、過去著作情報ＤＢ１０１に、登録が在る場合は、画面１２へ進み、登録が無い場合は、画面１３へ進む。そして画面１２又は画面１３にて、データB−２を入力すると、送信ボタンを押すことにより依頼ステップは完了する。データB−２の送信を終えると、観賞者は自身のログイン画面カート内（依頼一覧）に、先行依頼を行ったコンテンツが入っていることを確認できる。画面１５は、カート内画面の、データｃの要約が表示された一覧であり、画面１６は、カート内画面の要約無しの場合の一覧である。又、データＢ−２は、ログイン後の登録設定により省略も可能である。
【００４８】
又、「図２３」は、「図２２」の、画面１１から画面１３へ、移行する間の詳細なフローであり、鑑賞者から、過去著作情報をＤＢ１０１へ格納するフローである。まず鑑賞者が、過去著作ＤＢ１０１に著作情報を問い合わせる（Ｓ７０１）。そして、希望の過去著作情報が無い場合、既存のオンラインショップ等から過去著作情報を引っ張ってくる方法（Ｓ７０２）が行える。しかし、既存オンラインショップ等から情報を拾えない場合は、鑑賞者の分かる範囲で、情報を手入力にて登録する（Ｓ７０３）。又、サイト運営者側からも情報を入手できる範囲内でリスト化する事も可能である為、この場合（鑑賞者から登録を行う場合）というのは、草の根的な情報と考えられる。又、「図２４」は、「続きを見たい」ボタンを送信する際に考えられる、４つのパターンを纏めた図である。ボタンの有無と、DB１０１内の著作情報の有無より、各４つのパターンのステップがある。又、「ボタン有」で、「本システムに登録が無い」パターンは、任意のサイト運営側が、ボタンを設置してはいるが、本システムには登録が無いと言うケースである。又、「図２５」は、データｂを送信したフローチャート図である。
【００４９】
次に、「図２８」は、依頼情報データベースに格納されるデータB−２である。＜購入確率/コメント/その他作品も要求 / 作品Ｂ・新規作品＞の情報が格納される。又、B−２は、省略する事も可能である。例えば、「購入確率５０％」「依頼商品は指定コンテンツのみ」という様に、「続きを見たい」ボタンの信号内容を事前に鑑賞者側で、ログイン画面により設定を行うことも可能である。この場合、鑑賞者はログイン後に「続きを見たい」ボタンを押すものとする。又、「図５１」は、過去作品を厳密に指定している図である。鑑賞者は、次回作の依頼を行う為に、どの過去作品の続きなのかを厳密に指定する必要がある。例えば、コンテンツAという、商品があったとしも、そのコンテンツAには、付随する関連アイテムが多数存在するケースがある。例えば、コンテンツAが映画作品であったとして、それに関する関連アイテムA（玩具）,B（小説）,C（CD）…と言う様に、コンテンツAという広い枠組みの中に、様々な商品があるというケースがある。こうした場合、厳密指定を行えるように、「図５１」の様に、過去作品を特定できる機能を有するものとする。また、この厳密指定を行うステップあるいは画面は、データB-2を入力する画面にて行うケースでも良く、自動入札画面にて行うケースでも良く、過去作品が厳密に特定できるケースであれば良いものとする。又、段落「００２１」の、”ゆるやか”に指定するという意味は、購入する作品に対して指した言葉であり、購入したい作品においては、未だコンテンツが無い為、購入商品を指定したくても指定する事ができず、購入する商品においては、“ゆるやかな”指定である。そして、既に鑑賞してしまった過去作品においては厳密に指定しなくてはならないものとする。又、「図５２」は、同一コンテンツや、同一制作者の過去作品バリエーションの中から、鑑賞者側から作品を選択する容易性（自由度）を表した図である。又、「図５０」は、データＢ群の送信フローを纏めたものである。又、「図３０」は、鑑賞者が続きを見たいボタンを押した後に、データの値に変更があれば、その値が反映される３つの画面である。画面１５は、鑑賞者のカート画面であり、ボタンを押した後に、コンテンツがカート内に入る。画面１７は、制作者の依頼画面であり、ボタンを押した後に、制作者に依頼内容が届く。画面１８は、本システムのプラットフォームサイト画面であり、コンテンツアイコン側に表示される「続きが見たい人」の人数が加算される。又、ユーザーは非公開である。以上は＜依頼情報送受信処理（１３）＞である。
【００５０】
そして、５つ目の課題として、データｃを送信する詳細なフローである。「図２９」は、制作者が、データ（B−３）を受けて、次回作（データｃ）を送信する一連のステップである。「図３１」は、データB−３を受信した制作者画面である。画面１７のパターン１は、ユーザー情報が伏せられた各観賞者の個別依頼確認画面であり、個別の購入確率やコメントを確認する事ができる。画面１７のパターン２は、依頼情報による統計や分析画面である。統計確認画面では、どの作品の続き依頼が一番多いのか？又、契約タイミング情報等、制作者が制作を行うのに有益な統計データが確認できる。
【００５１】
次に、「図３２」は、依頼画面より次回作情報を入力するステップであり、画面１７のパターン３は次回作情報入力選択画面である。制作者は、この画面１７のパターン３に表示される作品項目の選択肢により、画面１７パターン４の「次回作情報を作成する」フォーマット入力画面へ進む。この選択項目は、鑑賞者からの依頼があった作品に対して表示されるものである。制作者は、規定されたフォーマット画面内に、次回作情報データｃを入力し確認後送信を押すと、作品を依頼した鑑賞者端末である画面１５へ送信される。以上は＜次回作送受信処理（１４）＞である。
【００５２】
そして、一連の機能の流れをまとめると、「図３３」は、一連の制作者フローと一連の鑑賞者フローである。まず、制作者フローである、（Ｓ８０１）はログイン画面である。ログイン後、制作者は、過去著作情報を入力する（Ｓ８０２）。→その後、制作者は、コンテンツと続きを見たいボタンを設置する（Ｓ８０３）。→その後、依頼情報を確認する（Ｓ８０４）。→その後、次回作著作情報を送信し、購入者数を確認、及び制作の合意を行う（Ｓ８０５）。→その後、完成作品をUPロードし搬入する（Ｓ８０６）。又、コンテンツは、デジタルコンテンツに限らない為、コンテンツ搬入方法はこの限りではない。次に鑑賞者ステップでは、初めに、続きを見たいボタンを送信する（Ｓ９０１）。→ログインを行う（Ｓ９０２）※尚、ログインステップは前後しても構わない。→データB―２を送信する（Ｓ９０３）。→カート内確認を確認する（Ｓ９０４）。→次回作情報を確認して購入を行う（Ｓ９０５）→購入額である積立金を確認する（Ｓ９０６）。→作品完了通知が届き、作品を受け取る（Ｓ９０７）の流れである。
【００５３】
又、「図１１」は、鑑賞者と制作者の間で交わされるデータ送受信であり、IDでヒモ付けられた、各コンテンツデータの送受信を表した図である。以下より、既存ＦＡＮ機能と比較しながら、ステップ順に述べる。
≪ステップ１：依頼ステップ≫
□既存のＦＡＮ機能…
「ＦＡＮになりました」という意思を送信し、コンテンツを指定していない。
□本システムの「続きを見たい」ボタン…
「作品Aの続きを購入したいと思うので次回作を制作して下さい」又は
「作品Bの続きを購入したいと思うので次回作を制作して下さい」又は
「新規作品を購入したいと思うので次回作を制作して下さい」と言う意思であり
特定のコンテンツを指定している。
≪ステップ２：カート内確認≫
□既存のＦＡＮ機能…
ユーザーIDが、お気に入りユーザーに登録される。
□「続きを見たい」ボタン…
ユーザーの作品IDが登録される。「作品Ａ」、「作品Ｂ」、「作品Ｃ」、「新規作品」が入る。又、同じ制作者の作品であっても、「続きを見たいボタン」を押さないとカートには入らない。
≪ステップ３：依頼受信≫
□ＦＡＮ機能…
「ＦＡＮになりました」現在ＦＡＮ４０人。登録を行ったユーザーIDがカウントされる。
□「続きが見たいボタン」とは…
「作品Ａの続きの依頼がきました」…現在３０人  購入確率５０％
「作品Ｂの続きの依頼がきました」…現在２５人  購入確率３０％
「新規作品の依頼がきました」…現在１５人  購入確率６０％
登録された作品IDと、その他の情報がカウントされる。どの作品のどの続きが見たいのか？が明確であり、制作側は、注文票の様な形で、データ（ｂ）を受信する。
≪ステップ４：次回作送信≫
次回作である著作情報データ（ｃ）について
□ＦＡＮ機能…
様々な不特定多数の情報の中の（Ｄ）という一部の著作情報を送信する。この場合、顧客は商品を指定しておらず情報の性質としては（例え、鑑賞者が望んでいたとしても）宣伝広告の情報である。
□「続きが見たい」ボタン…
Ａという依頼を受けて（Ａ’）という（規定のフォーマットへ入力された）規定の著作情報
Ｂという依頼を受けて（Ｂ’）という（規定のフォーマットへ入力された）規定の著作情報
新規という依頼を受けて（新規）という（規定のフォーマットへ入力された）規定の著作情報
≪ステップ５：次回作受信≫
□ＦＡＮ機能…
お気に入りユーザーの不特定多数の情報の中から著作情報を受信する。
□「続きが見たい」ボタン…
作品Ａの依頼し、作品（Ａ’）という次回予告を受信する。
作品Ｂの依頼し、作品（Ｂ’）という次回予告を受信する。
作品新規の依頼し、作品（新規）という次回予告を受信する。
以上が、「図１１」の一連のフローである。
【００５４】
次に、「図１６」は、各作品IDでひも付いたユーザー群に、次回作予告データCが、送信される図である。又、「図１７」は、観賞者が指定したコンテンツと、指定をしていないコンテンツが、明解に区分けがされている図である。又、「図３３」は、既存のオンラインストアと、本オンラインストアの比較である。以上が、依頼から購入に至るまでの一連の流れである。
【００５５】
次に、６つ目の課題である、課金システムに於いて、制作者と鑑賞者と、本システム運営側の、各者、条件のバランスの調整における問題の処理方法を述べる。
【００５６】
まず先に、本システムの課金システムの特徴を述べると、本システムは、「事前購入→課金→商品搬入→達成の場合提供者へ振込or未達成の場合鑑賞者へ返金」というフローである。これは、既存の商取引で行われている事前に課金を行うオーダーシステムと類似している。しかし、本発明は、大規模な建築やシステムの開発ではなく、コンテンツ販売である為、必然的に、薄利多売的な広く購入者を集める販売システムとなる。（※相場的にも、２００円（画像、音楽、文章）〜高額でも1万円（ゲーム）である）又、本システムは、基本的に、イベント等の特定の日時にサービスを受けるものではなく、又、製造オーダー型で、少額であり、さらに前金を行わない場合は、キャンセルを行う理由がなく先行購入時に課金を行う課金システムである。その為基本的には、先行購入時に購入意思の責任を必ず持つ形である。又、予約購入時に課金を行い購入責任を負う予約システムとして、類似のものに交通サービスなどがある。本発明は、段落「００３３」に記載の通り、制作者には、慎重な時間配分が制作者に求められる特徴がある。また、本発明は、極端な話、制作期間は、短くて1日、長くて１０年という期間も可能である。しかしながら長期になればなるほど両者にとってはリスクとなり作品の質の問題も発生する為、期間制限（長期を禁止にする）を設ける方法等、別途、改良を行う形である。以上は、本システムの特徴である。
【００５７】
そして課題としては、鑑賞者と、制作者と、本システム運営側の負担におけるバランスについてである。これは、先行コンテンツという商品を扱うにあたり、購入から作品受け渡し迄の、宙に浮いてしまう空白期間が存在してしまう為、その期間の資金における３者の負担の分散を行いたいという問題である。以下に３者における各問題を述べる。
「制作者側の問題として」
例えば、制作に１カ月を要するコンテンツがあり、鑑賞者から依頼の注文だけが大量あったとしても直前になって購入を辞められてしまうリスクがある。これを防止する方法として、鑑賞者に依頼の段階で、購入の責任を負ってもらう事で対処を行う。しかしながら、まだ、作品を受け渡していないのに、売上金を得る事はできないものとし、プール型の課金方法を行うものとしている。
「鑑賞者側の問題として」
通常であれば制作を行わなかった製品に対し、鑑賞者側から依頼できるというメリットがある為、依頼を行っているという形態だからこそ、制作予定購入段階で課金に責任を負うものとする。しかしながら、商品を手に入れていない段階で課金を行うという事は、前倒しの支払いであり、負担があるという問題である。
「本システム運営側の問題として」
プール型の場合、システム運営側の管理に対する責任が重いという問題が在る。又、無駄な手数料が掛る場合もある。又、既存ビジネスモデルでは無い為一から複雑なシステムを考えなくてはならず、又、開発に於いても費用が掛る。
その為、以上により、「図３７」の様な、積立型を考える事ができる。積立型は、積立金DBサーバにより、データだけで購入金額を管理する方法である。これは、購入したトータル額を計算し、DB内にて金額を記憶し、商品受け渡し時に制作者口座に振り込む方法である。又、積立型の若干の問題としては、２カ月後、３ヶ月後、半年後と言う様に、制作期間が長期化するほど、鑑賞者及び制作者に於いて負担となる。例えば、鑑賞者としては、購入した事を忘れてしまい、後になって支払い請求が来るリスクであり、制作者としては、期限内に完成作品を搬入しても売り上げを回収できないリスクである。（※プール型と積立型の違いは、鑑賞者の口座からの引き落ちるタイミングが相違する点である。プール型は本システムのプール口座に一旦保管されるが、積立型は本システムのプール口座を経由しない形である）この場合の解決法として、積立型とプール型の併用である混合型を有するものとする。（「図３８」参照）混合型とは、一定以上迄は、積立金での管理を行うが、一定以上を越えると、プール型に切り替わる方式である。一定のラインとは、例えば、日数であったり、金額であったり、どちらでも構わないものとする。又、コンテンツの制作日数によりタイプ分けを行い、タイプによって、積立型か、プール型か、混合型かを設定し、併用する事も可能である（「図３８下図」参照）。尚、できるだけ短期制作型を行えるようにするものとする。又、「続きを見たい」ボタンにはチップ設定を行うことも可能である。先行コンテンツ販売では、観賞者からの依頼で始まり、制作者は基本的に制作することを予定してはおらず、「続きを見たい」と言われて初めて、制作計画表を立て発表を行う為である。これは、鑑賞者側にメリットが高すぎる場合は、チップを加算し（コンテンツ本体額の５％程度）、鑑賞者側にメリットがない場合は、チップを無しにする様な、両者の条件的な調整機能である。
【００５８】
そして次に、７つ目の契約タイミングの調整の問題について述べる。契約タイミング問題とは、例えば、コンテンツ制作には短期のものから長期を有するもの迄様々ある。そして、例えば「続きを見たい」ボタンを押されてから、一定数の人数が確保できるまで、仮に３年掛ったとする。すると、先の人は、最初に「続きを見たいボタン」を押してから、３年待って制作計画書を受け取ることになり、又、タイミング良く制作計画書を受け取らなければならなくなる。又、３年後にタイミング良く購入できたとしても、さらに１年後に作品を搬入してしまう、という事もありえてくる。又、鑑賞者は購入した事を忘れてはならないという課題もある。先行販売の特長としてこの様な性質を持っており、この問題解決として本システムは、時間調整ＤＢサーバ５０１を設置するものである。
【００５９】
契約タイミングの調整方法を大きく分けると「心理面でのアプローチ」と「システム面でのアプローチ」での２種類のアプローチから行う。心理的アプローチでは、主に制作希望タイミングを各自把握できるよう認識を容易にする等、又、コンテンツの種類により制作期間の相場を定める等、コンテンツの購入を忘れない様に促す等、完成するのに長期の時間が掛るものは、なるべく１つの作品を数回に区切り少量で出していく等である。次に、システム的アプローチでは、ダウンロード期間を長くする等、又開始期間や完了日を緩やかに定める事ができる等である。
【００６０】
そして、「図３９」は、鑑賞者と制作者の契約タイミング調整データである。鑑賞者から収集するデータを（Ｊ−１）とし、制作者から収集するデータを（Ｊ−２）とする。又、観賞者より設定される自動入札におけるデータを（J−３）とし、又、データ（４１）（４２）は、事前に既定の値等を設定し、調整を計る為のデータである。そして、「図３９」の様な形で、契約タイミングを幾つかのカテゴリに分解し、各パターン化する。そして区分けされたパターンに、ラベルを設ける。又、「制作タイミング」や「確認タイミング」等は、コンピュータにより、ユーザー行動を分析し確率を出す方法と、ユーザーからの自己申告によるものとどちらでも良い。そして、利用者の任意の判断である程度の時間的なタイミングが合う様に時間帯を計測し、鑑賞者と制作者の時間のリズムを調整する判断の補佐を行う。例えば、制作者の制作の頻度の情報や、鑑賞者のＷＥＢを訪問している頻度の情報（※鑑賞者のＩＤは表示しない）や、ざっくりと、「１カ月後や、２カ月後に訪問します」というような情報等である。
【００６１】
次に、「図４０」は、鑑賞者と制作者の契約タイミング調整データ及び、制作者であるユーザーの管理画面、及び、コンテンツスケジュール画面である。上図の左側のデータ表は、制作者の希望制作タイミングデータ（Ｊ−２）である。これは、ざっくりとした制作者の制作情報である。又、例えばこれは、「コンテンツA」という作品を制作するには、１カ月掛るという制作者の制作に要する時間情報でも構わない。制作者は、過去作品の次回作を制作する為に、必要な制作時間の情報を事前に、各コンテンツに対し付与する事が可能である。例えば、コンテンツAという過去作品があれば、事前に、その作品に対し、制作するに要する日数の予想情報を付与しておくことができる。次に、上図の右側のデータ表は、鑑賞者の自動入札設定である。例えば、制作者の希望制作タイミングが、＜１カ月に一回の割合で制作＞とか、＜制作を行うのに２カ月日数が掛る＞という情報が分かれば、鑑賞者は、作品Aであれば、例えば、＜３回まで自動的に入札する＞と言う設定が可能である。これを、自動入札データ（Ｊ−３）とする。そして、画面２１は、制作者画面であり、制作者は次回作依頼者（購入予備軍）の内、自動入札鑑賞者の人数やその内省の内訳が確認できる。又、画面２２は、以上の各契約タイミングデータを、グラフにした分析画面である。（各データ事にこの分析画面があるものとする。）又、画面２３は、鑑賞者カート画面のコンテンツスケジュール表であり、入札前コンテンツ群である。入札前のコンテンツスケジュールは、制作決定前のざっくりとした、制作者側が事前に付与した情報（データＪ−２）である。そして画面２４は、入札後コンテンツ群のスケジュール表である。入札後のコンテンツスケジュールは、確実な制作完成日（データＪ−４）である。また、「図４０」の自動ダウンロード装置とは、コンテンツを保管する記憶装置に自動でダウンロードを行う装置である。又、以上の自動入札設定のフローを纏めたものが「図４２」である。図では、まず画面３０にて、「続きが見たい」ボタンを押す。そして画面３１は、自動入札設定画面であり、制作者のざっくりとした制作時間等の情報が記載された画面である。又、画面３２は、制作者のざっくりとした希望タイミング等の情報が無い画面である。そして鑑賞者は、この画面にて＜自動入札回数、と最大期限、上限金額＞を設定する事ができる。又、「最大期限」というのは、自動入札設定の効力がある期間である。又、自動入札設定は、いつでも解除可能である。次に、画面３３は、制作者の、依頼情報確認画面（画面１７）である。この画面では自動入札者の内訳情報を統計的に確認することができる。又、自動入札者以外の依頼者の希望タイミングなど、参考までに、その他の情報を統計データ等により確認することができる。以上が、契約タイミング問題の対策である。又、「図４１」は、制作日数等の相場表である。又、制作日数以外にも、参考までに金額などの平均的な相場を表示しておくことも可能である。
【００６２】
次に、「図５３」は、以上の一連のステップと機能を纏めた図である。以上により本発明は構成されるものとする。
【符号の説明】
【００６３】
ユーザ（１）…自らが作品を制作する作品制作者、又は自らは制作を行わないが作品を提
供する作品提供者
ユーザ（２）…作品を購入しようとするもの・鑑賞者
端末（Ａ）  …ユーザ（１）の端末
端末（Ｂ）  …ユーザ（２）の端末
データ（a）…
ユーザ（１）の過去に創られた作品（完成作品）のデータ＜作品名、作家名、作品情報、ユーザ（１）の経歴及び情報等＞である。又、作品にはＩＤが付与され＜例、作品ID:０００１＞過去作品メニューリストとして管理される。
データ（b）…
過去作品データaを参考にしてお気に入りの作家に次回作を依頼する信号であり、過去作品データaよりひも付いた情報（作品ＩＤ等）を受けて、オーダー的要素を送信する信号であり、且つ、お気に入り鑑賞者（ＦＡＮ・リピータ）としての信号も含む＜作品ID：０００１/作品ID：０００１の次回作依頼＞という情報である。又、「図２」は、“続きを見たい”というボタンであり、これを押すことによりデータｂは送信される。又、「図２」は、他サイトへ広く配布可能な形態であるボタンとして表している。
データ（c）…
データｂより引きついた作品ＩＤ及び、（先行販売が行われる）募集期間、作品ID：0001次回作概要・形態（例、作画/枚数、書籍/頁数、［作品名］○○の続き…）、金額、完成予定日（○月○日、所要日数○カ月）制作実行可能人数（○人以上であれば制作実行）データ（d） …ユーザ（２）のコンテンツを購入するかどうかの意思決定（購入する）
データ（e） …ユーザ（１）の制作実行の合意or拒否の意思決定（制作するor制作しない）
データ（f） …ユーザ（２）の支払いに必要な情報（クレジットカード番号、氏名等）及び決済信号
データ（g） …ユーザ（２）による受け取りの確認データ信号
データ（h） …完成されたコンテンツ
１０１…記憶装置（ＤＢサーバ）
＿＿
データＡ’…コンテンツサムネイル
データＢ’…「続きが見たい」登録解除ボタン。
データＣ’…  コンテンツ題名、受付期間、制作者名等、コンテンツ内容の要約情報
（データＤ’の要約）
データＤ’…コンテンツの詳細内容（計画書）、題名、内容（あらすじ）、先行販売受付期間、完成期間、金額、コンテンツ形態（音楽、動画、画像…）制作実行予定人数（制作が実行される購入人数の目安）延長有無と延長の対応方法、他
≪データ（c）と同一≫
■データ関係
データ（Ａ−１）…
データaの内、著作情報部分  ＜過去に創られた作品情報であり：作品ＩＤ、作者名、作品名、金額、コンテンツ形態（書籍・音楽・動画…等）、その他、過去作品を特定する為のあらゆる情報。又、補足項目として、ユーザ（１）の情報（経歴等）、制作者のその他の作品情報等＞これは、本システムの過去著作ＤＢ１０１へ格納されるデータであり、本システムの売買には必ず必要なデータである）
データ（Ａ−２）…
データaの内、コンテンツそのもの制作者が過去に創ったコンテンツであり、例えば、無料で公開されているものであれば、鑑賞者はそれを観賞する事で『続きを見たいボタン』を押しやすくなる。又、Ａ−１と、切り離されても、コンテンツを識別するための簡易著作情報＜作品名、作品情報、コンテンツＩＤ＞も含んでおり付与されている。これは、本システムの過去作品データベース１０２に格納されていても、他サイトの任意のデータベースに格納されていてもどちらでもよく、オンライン上に表示される形であれば良い。又、無料で公開されていても、されていなくてもどちらでも良い。鑑賞者が次回作を購入する為の参考コンテンツである。
データ（Ｂ―１）…
データｂの信号の内、簡易な次回作要求信号。過去作品の側に配布されている「続きを見たい」ボタンを押すと送信されるデータであり、最低限の簡易な過去著作情報を含んでいるデータ  ＜例えば、作品ＩＤ/作品名/会社名著作名/等＞である。また、本システムの過去著作データベース１０１へ問い合わせて過去著作情報Ａ−１の有無を調べ、登録有無の値を返す。又、ボタンが無い場合は、直接「図２３」の形で、過去作品を特定するデータを手入力で入力し、本システムの過去著作データベースへ問い合わせする事も可能である。又、問い合わせしても過去作品情報（データＡ-1）が登録されていない場合は、鑑賞者から、（データＡ-1）を直接入力し、本システムへ登録を行い注文意思を送信することも可能である。
データ（Ｂ―２）…
データｂの信号の内、詳細情報を含んだ次回作要求信号「図２２」の画面１２、又は画面１３で、入力されるデータであり、「作品を特定するデータa＋続き依頼＋若干のコメント＋購入確率＋日時等」である。又は「作品を特定するデータa＋新規依頼＋続き依頼＋その他の商品の続きも見たい＋若干のコメント＋購入確率＋日時等」である。（※購入確率とは顧客が、どれぐらい続きが見たいかの指標を表すデータであり、例えば、星マーク等の５段階表示でも良い。又、このステップは、ログイン後であれば、鑑賞者が本システム内に一律の情報を登録しておき省略する事も可能である）
データ（Ｂ―３）…
データＢ−２等を基に、算出された値や統計データであって制作者端末Ａに表示されるデータ。
例：
「コンテンツＡの続きが依頼されました/依頼者ＩＤ/ 若干のコメント/日時/購入確率等」
→「コンテンツＡの依頼者総合人数/総合購入確率等」
「コンテンツＢの続きが依頼されました/依頼者ＩＤ/若干のコメント/日時/購入確率等」
→「コンテンツＢの依頼者総合人数/総合購入確率等」
「コンテンツＣの続きが依頼されました/依頼者ＩＤ/新規/鑑賞者人数/若干のコメント/日時等/購入確率等」→「コンテンツ新規の依頼者総合人数/購入確率等」というオーダー一覧（依頼票）形式の情報（「図３１」参照）
データ（Ｂ−４）…
過去作品を厳密に指定したデータ。
例：
過去作品コンテンツＡ（ＩＤ：０００１）があった場合、さらに、
過去作品コンテンツＡの内の（ＩＤ：０００１−１）という作品
過去作品コンテンツＡの内の（ＩＤ：０００１−２）という作品
過去策作品コンテンツＡの内の（ＩＤ：０００１−３）という作品のデータ。
データ（Ｃ―１）…
次回著作情報（制作者入力情報）≪データｃと同一≫
『著作情報である、販売が行われる募集期間（※先行販売受付期間）コンテンツの詳細内容（計画書・次回作概要・題名、あらすじ等）コンテンツ形態（音楽、動画、画像…）「例、作画/枚数、書籍/頁数、［作品名］○○の続き…」金額、完成予定日（○月○日、所要日数○カ月）制作実行可能人数（○人以上であれば制作実行等・制作が実行される購入人数の目安）延長有無と延長の対応方法、他』
また、顧客からの依頼が、作品（Ａ）であり、制作者は次回作（Ａ’）という作品を制作する場合は、作品（Ａ‘）というデータを、規定のフォーマットへ入力する規定の著作情報であり、顧客からの依頼が、作品（B）であり、制作者は次回作（B’）という作品を制作する場合は、作品（B‘）というデータを、規定のフォーマットへ入力する規定の著作情報であり、顧客からの依頼が、作品（新規）であり、制作者は次回作（新規’）という作品を制作する場合は、作品（新規‘）というデータを、規定のフォーマットへ入力する規定の著作情報であり、観賞者からの応答による情報である。
データ（Ｃ―２）…
鑑賞者の端末（カート内）に表示されるデータ（Ｃ−１）
「作品Ａの続き」であれば、「作品（Ａ’）の情報が届く」
「作品新規依頼」であれば、「作品新規の情報が届く」
と言う様に、鑑賞者が指定した商品データにひも付いて送信されるデータであり、
鑑賞者が、データ（ｂ）を送信する際に、作品Ａ、作品Ｂと、選択していなければ届かない。
同一作家の、その他の作品も可能であれば、宣伝広告として表示できるが
依頼商品とは明確に区別されている。
データ（Ｃ−３）…
コンテンツ題名、受付期間、制作者名等、コンテンツ内容の要約情報（※データc−１の要約）
データ（Ｉ）…積立金額  
データ（Ｉ−１）…積立金額の内、（鑑賞者の購入金額、積立金合計額）                                  
データ（I−２）…積立金額の内、（コンテンツ事に振り分けられる等した、積立型、プール型、混合型の情報）
データ（J）…時間調整データ
データ（J−１）…時間調整データの内、（自動入札者以外の鑑賞者側希望タイミング情報等）
データ（J−２）…
時間調整データの内（制作者のざっくりとしたコンテンツ制作希望タイミング・日数時間等）
データ（J−３）…
時間調整データの内、（鑑賞者の自動入札設定に関するデータ＜自動   入札回数、最大期限、上限金額等＞）
データ（J−４）…時間調整データの内（制作合意後の購入が決まった完成日時データ・搬入可能日時）
データ（Ｋ）…その他のデータ、（金額、日数等の相場表）
データ（Ｌ）…ユーザー情報等
■ＤＢサーバ関係：記憶装置１０１詳細
１０１…過去作品著作情報データベース（データＡ−１を格納する）
１０２…過去作品データベース（データＡ−２を格納する）
２０１…依頼情報データベース（データＢ−１、Ｂ−２、Ｂ−３、Ｂ−４を格納する）
２０２…次回作情報データベース（データＣ−１を格納する）
３０１…完成作品データベース（データｈを格納する）
４０１…積立金データベースサーバ
５０１…時間調整データベースサーバ
６０１…受注処理サーバ（一連のプログラムを処理する）
■プログラム処理関係
１１…作者ＩＤ認証に関する一連の処理
１２…過去作品を登録する一連の処理
１３…依頼情報を送受信する一連の処理
１４…次回作情報を送受信する一連の処理
１５…受注処理に関する一連の処理（メール通知等、その他諸々）
１６…ボタン生成など「続きを見たい」ボタンを配布する一連の処理
１７…完成作成搬入の一連の処理（ＵＰロード、ダウンロード等）
■画面関係
画面１０…ボタンが設置されている画面
画面１１…ボタンが設置されておらず鑑賞者が自身で制作者名と作品名を入力する画面
画面１２…過去作品著作情報ＤＢ（１０１）に作者の登録が在る依頼入力画面
画面１３…過去作品著作情報ＤＢ（１０１）に作者の登録が無い依頼入力画面
画面１４…受付画面
画面１５…カート内画面１（通知された、データcの簡易情報を表示した一覧）
※鑑賞者のプライベート情報であり情報保護画面、非公開画面
画面１６…カート内画面２（続きが見たい作品の全容が確認容易な画面）
※鑑賞者のプライベート情報であり情報保護画面、非公開画面
画面１７…データ（Ｂ−２）が表示されている制作者画面
パターン１：個別依頼確認
パターン２：統計確認
パターン３：次回作入力選択画面
パターン４：次回作入力フォーマット
パターン５：過去作品登録漏れにより、鑑賞者から先に入力された（認証可能な）
過去作品データ（a）に対し、ＩＤ認証を行う処理画面
画面１８…
本発明サイトのプラットフォーム（続きを見たい作品ランキング等、本システムに登録された続きを見たい作品、及び過去作品が、この画面から検索できる）
画面１９…
コンテンツスケジュール画面  
パターン１：ざっくりとした購入前コンテンツスケジュール画面
パターン２：作品搬入日時が決定した購入後コンテンツスケジュール画面
【図１】
0005296900.tif 000002
【図２】
0005296900.tif 000003
【図３】
0005296900.tif 000004
【図４】
0005296900.tif 000005
【図５】
0005296900.tif 000006
【図６】
0005296900.tif 000007
【図７】
0005296900.tif 000008
【図８】
0005296900.tif 000009
【図９】
0005296900.tif 000010
【図１０】
0005296900.tif 000011
【図１１】
0005296900.tif 000012
【図１２】
0005296900.tif 000013
【図１３】
0005296900.tif 000014
【図１４】
0005296900.tif 000015
【図１５】
0005296900.tif 000016
【図１６】
0005296900.tif 000017
【図１７】
0005296900.tif 000018
【図１８】
0005296900.tif 000019
【図１９】
0005296900.tif 000020
【図２０】
0005296900.tif 000021
【図２１】
0005296900.tif 000022
【図２２】
0005296900.tif 000023
【図２３】
0005296900.tif 000024
【図２４】
0005296900.tif 000025
【図２５】
0005296900.tif 000026
【図２６】
0005296900.tif 000027
【図２７】
0005296900.tif 000028
【図２８】
0005296900.tif 000029
【図２９】
0005296900.tif 000030
【図３０】
0005296900.tif 000031
【図３１】
0005296900.tif 000032
【図３２】
0005296900.tif 000033
【図３３】
0005296900.tif 000034
【図３４】
0005296900.tif 000035
【図３５】
0005296900.tif 000036
【図３６】
0005296900.tif 000037
【図３７】
0005296900.tif 000038
【図３８】
0005296900.tif 000039
【図３９】
0005296900.tif 000040
【図４０】
0005296900.tif 000041
【図４１】
0005296900.tif 000042
【図４２】
0005296900.tif 000043
【図４３】
0005296900.tif 000044
【図４４】
0005296900.tif 000045
【図４５】
0005296900.tif 000046
【図４６】
0005296900.tif 000047
【図４７】
0005296900.tif 000048
【図４８−１】
0005296900.tif 000049
【図４８−２】
0005296900.tif 000050
【図４９】
0005296900.tif 000051
【図５０】
0005296900.tif 000052
【図５１】
0005296900.tif 000053
【図５２】
0005296900.tif 000054
【図５３】
0005296900.tif 000055