JP2013101590A - コンテンツ販売システム、及び、その方法 - Google Patents

Abstract

【課題】制作者側の、販売予想の難しさを解消する。観賞者側の、お気に入り作家の次回作品を観賞したくても制作者側の予算不足で制作中止となり観賞が不可能になるという問題を解消する。
【解決手段】鑑賞者は、過去作品情報に基づき、次回作の制作を要求する信号を端末から送信する。制作者は、次回作の制作を要求する信号を端末で受信し、次回作の制作を行うか行わないかを判断する。制作者が、次回作の制作を行う信号を端末で送信すると、決算処理部が鑑賞者に課金する。その後、制作されたコンテンツが鑑賞者に受け渡しされてから、制作者に売上金額が支払われる。
【選択図】図１

Description

本発明は、オンライン上で販売可能なコンテンツ、画像、動画、電子書籍（雑誌・漫画を含む）、音楽、ゲームを対象とした芸術的クリエイティブな創作活動を要する著作物の販売課金システムであって、その課金における手順に関する。

従来のオンライン上でのコンテンツ販売の方法は、コンテンツ制作者側及び仲介者が創作物をオンライン上にて表示し、鑑賞者はその表示された商品を観て判断し購入するというステップである。購入に至るまでの段階には、音楽であれば視聴機能、書籍であれば中身拝見機能などのお試し機能があり、これらによって購買の意思決定を高めるという手段がある。

不明

従来の方法によると制作者側としては、作品を制作するかどうかの意思決定が難しいという問題がある。例えば、作品を制作しても必ずしも売れる（資金が回収できる）かどうかの確証はつかず、結果、資金不足で制作中止という判断に陥ってしまう。観賞者側の問題としては、お気に入りの作家の次回作品が見たくても、制作者側の予算不足の問題等で制作中止となり観賞が不可能になるケースがある。又、従来では作品を制作するかしないかは、作品の流通を担う販売会社等の予測による販売決定に委ねられているのだが、制作会社が鑑賞者側の意思を完全に組み切れているとは言い難いという問題が残る。又、現在、インターネットでのコンテンツの流通というのは、制作者の著作権を守りきれていない現状がある。不正コピー、不正な投稿等、今後もますますこの課題は広がっていき、課題として残ったままである。コンテンツ制作者はインターネットの到来により表現への自由度は高まったが、既存のビジネスモデルの崩壊など、制作改善の進展には効果が低い。

又、既存モデルの崩壊とは、コンテンツの無料化問題を指し、ＩＴ技術によりコンテンツ市場の無料化が益々進んでいく中で、コンテンツ市場での制作者の制作環境を維持するのが極めて困難であった。その一原因としてＩＴ以前の時代であれば制作者側は少数であったが、ＩＴ後の時代ではごく一般人でも容易に制作者側へと回れる環境である為、参加者が増加し、優良且つ無償の作品が競う様にＷＥＢ上で供給されている事が上げられる。この様な状況では、当初は、無償の優良のコンテンツが存在しているのだが、無料化がピークを越えると制作側が疲弊し、次には、反動で極端にコンテンツの質が低下するという問題がある。又、制作者が疲弊していくと鑑賞者は良質な作品を見る事が困難になる。（「図４３」参照）

以上は、ＷＥＢ上に存在している周知の課題であり、長らく解決できずにいる難問である。又、段落「０００７」に記載の「販売側と購入者側の品切れによる販売ロスを避ける目的の為にあり…」と言うのは、制作者側の時間捻出の問題の解決を試みるもので異なるという意味であり、本発明は、原価というコストリスク（赤字リスク）回避に留まらず、制作者が作品（いわゆる画像、音楽、文書、動画等の表現作品）を制作するにあたり、アルバイトや仕事を行いながら作品を制作しないといけないという環境を解決したいとするものである。これを考えるにあたり「制作時間を捻出できないか？」という課題を持つものである。通常、作品を制作するにあたり“コスト”という物理的な費用の壁を感じたとしても、自分自身の“時間”の壁には絶対的な不可能なできない理由を感じず、多少不便を感じつつも“時間”は無料である為、仕方のない事、気合いで何とかなる事だと考えられている。一般的に、時間的障害とは制作者が当然、負担しなければならない制約であると考えられており、その為、時間は本人の「やる気」の問題という心理的問題で片付けられている。しかし、本発明は制作者の時間捻出の解決を課題としている。

本システムは、「図４４」の様に、既存のコンテンツ市場の流れを真逆にするものである。その為、鑑賞者と制作者の、相互間における商品売買のデータの送受信の流れは、既存システムのデータ送受信の流れと真逆になる。又、「図１２」に記載の「２次的欲求」とは、現在、鑑賞している作品を求める欲求ではなく、次回作（第二段・連続作品）を求める欲求である。本システムは、２次的欲求を対象とした先行コンテンツ商品を販売するオンラインストアである。

＜１次欲求＞…現在確認している目の前の商品そのものを求める欲求。
＜２次欲求＞…現在確認している目の前の商品の次回作を求める欲求。

本発明は以上の課題を解決する為のコンテンツ先行課金システムである。本発明はコンテンツ制作・販売・課金処理の流れに特長を持ったシステムであり、従来のステップと比較して説明を述べる。従来のコンテンツ制作販売者のステップは概ね次の様なものであった。

『既存コンテンツ販売のステップ』
ステップ（１）制作会社又は、制作決定者の販売予測「この作品は売れるだろう」という判断がされる。→ステップ（２）売れるという予測が立てられ、コンテンツの制作を開始する。→ステップ（３）コンテンツ（画像・動画・音楽・文書・ゲーム等）が完成する→ステップ（４）予約販売や、広告宣伝、制作数の調整等を行う→ステップ（５）販売結果が分かる≪販売予測通り販売できたor販売予測通り販売できなかった≫。以上の様な流れであった。

しかし本発明では次のステップを踏む。まず制作者側の流れを説明する。
『本システムのステップ：制作者フロー』
ステップ（１）制作者は自身で設定した「図２」の“続きを見たいボタン”が押されているか、確認することができる。“続きを見たい”ボタンとは、データ（b）であり本発明が提供する機能である。制作者は前記ボタンを設置すると、前記機能（ボタン）提供サイトで、前記ボタンを押したユーザー人数を確認することができる。前記機能は、今まで見過ごされていた鑑賞者のニーズを発見する機能である。又、”続きを見たい“という言葉は、同じ意味であれば、この言葉に限られるものではない。→次に、ステップ（２）では、制作者は”続きを見たい“ボタンを押した鑑賞者に、「図５」のデータＤ’（※又はデータ（ｃ）同一データ）である制作計画（制作予告）を発信することができる。※この時点では制作者はまだ作品の制作は出来ていない状態である。→ステップ（３）では、制作予告を見た前記鑑賞者が「作品を購入した」というデータを、前記制作者は受け取り、コンテンツの購入人数が確認できる。購入人数が事前に分かれば、前記制作者は制作を決行するかどうかの判断ができる。例えば、制作者は次の様な判断ができる「購入者が１０００人いるな。制作を行おう。バイトせずに制作できるな。（３ヶ月後作品完成）」or「購入者が１０人しかいないな。制作はやめよう。バイトをしよう（２年後作品完成）」となる。次にステップ（４）では、制作者は無事作品を完成させ搬入し、自身の口座に、コンテンツ売上金額が振り込まれたのを確認する。

『本システムのステップ：鑑賞者フロー』
次に、鑑賞者であるステップを説明する。ステップ（１）鑑賞者は、お気に入りの制作者の次の作品を見たいけれど、鑑賞できないでいる状態である。例えば、「この作品の続きをみたいけれど、全然制作してくれないな」と思っている状態である。→次にステップ（２）では、続きを制作して欲しいと思う、お気に入り制作者の”続きを見たい“ボタンを前記鑑賞者は押すことができる。（意思表示を行う）→ステップ（３）データＤ’である制作予定表を前記鑑賞者は受け取ることができる。次に、料金と内容、制作期日を了承して購入するかしないかを判断することができる。→ステップ（４）購入する場合は購入ボタンを押すことができる。この段階ではまだ仮購入であり、先行販売締切日に（制作者の制作意思を待ち）本購入が決まる。本購入が決まればコンテンツ料金が課金される。※又、この段階では鑑賞者に課金を行うが、金額はサイト運営側でプールしたままであり、コンテンツ制作者には振り込まれない。次にステップ（５）では、鑑賞者は、作品完成日に作品を無事受け取り、レビュー（評価）を行う。もし、前記鑑賞者が作品を受け取る事が出来なければ、課金された金額は前記鑑賞者にそのまま返金される。制作者が無事コンテンツを搬入すればこの時初めて、制作者に金額が振り込まれる。また、プールされた金額はサイト運営側が無断で使えない口座を設ける形か、第三者が介入するかを厳重に行うシステムを含める形にするか、又は、銀行等の機関に委託を行うか対処可能なものとする。※尚、サイト運営側の返金手数料の無駄は、プール期間の利子で相殺できるものとする。利子が余る場合はポイントなどで返金を自動処理により行えるものとする。又、何らかの問題が発生する場合の処置も含むものとする。以上が本発明の要約であり、次に、コンピュータでの処理を述べる。

本発明は作品提供者であるユーザ（１）と、作品観賞者であるユーザ（２）が作品を売買する為の課金システムであって、前記ユーザ（１）が端末（Ａ）と記憶装置を用いて情報データ（a）を提示するステップと、次に前記ユーザ（２）が端末（Ｂ）と記憶装置を用いてデータ（b）を提示するステップと、次に前記ユーザ（１）が端末（Ａ）と記憶装置を用いて情報データ（c）を提示するステップと、次に前記ユーザ（２）が端末（Ｂ）と記憶装置を用いてデータ（d）を提示し、コンピュータが複数からなる前記ユーザ（２）の前記データ（d）の合計値を算出し端末（Ａ）に表示させるステップと、次に前記ユーザ（１）がデータ（e）を提示し、前記データ（e）が合意であればデータ（f）を決済システムに自動的に配信し、前記ユーザ（２）に自動的に課金される決済ステップと、前記データ（e）が拒否であれば、データ（f）は決済システムには配信されず課金処理が行われないステップと、前記ユーザ（２）に対し課金された金額をプールしておく決済システムと、次に、作品が完成し前記ユーザ（１）が端末（Ａ）と記憶装置を用いて完成作品を搬入し、又その処理をメール等により前記ユーザ（２）に自動的に通知するシステムと、前記ユーザ（２）が記憶装置から作品を取り出し確認すると、その信号であるデータ（g）が決済システムに自動的に送られるステップと、データ（g）を受け取った決済システムが前記ユーザ（１）にプールしていた金額を自動的に振込むステップと、又、データ（ｇ）が受け取れなかった場合の前記ユーザ（２）へ金額が自動的に返金されるステップとを有している。以上により、本課題を解決するものとする。

以上が、本ビジネスモデルの概要である。以下より、既存ビジネスモデルとの相違を述べる。

『１．予約販売システムとの比較』
予約販売システムは「制作者が広告を表示して顧客を集う」ものであり、本システムは、『鑑賞者が作家に続きを見たいと依頼する』ので相違する。本システムは鑑賞者側から制作者へ、コンテンツ制作依頼を行うオーダーシステムであり、その過程で作家と鑑賞者が制作する条件を調整し合うシステムである。

『２.オーダーシステムとの比較』
既存のオーダーシステムとは、顧客から依頼を行う販売モデルだが、作品の続きを依頼している訳ではなく、その目的は、顧客側に明確な制作（デザイン・建築・衣類等）を行ってほしい何かがあり依頼を行う。この場合、自分だけのオリジナルの商品を、制作してもらう時に発生する販売方法である。本発明の先行販売は、オリジナルコンテンツを制作依頼するわけでは無く、鑑賞者が、制作の次回作を観賞可能にするものであり、既存のオーダー販売とは、概念そのものが相違する。

『３．投資システムとの比較』
本システムは資金運用を行うのではなく、販売する商品そのものを購入するので異なる。

『４．アマゾン等のオンラインショップとの比較』
本システムでは、顧客が「続きが見たいボタン」を押すと、続きが見たい作品（先行コンテンツ）を「図２９」の様な形で、商品が並ぶカート画面に入れる事ができる。これは、アマゾン等の商品を購入するカート画面と類似しているが、本システムの取り扱う商品は、「現段階では作者自身も作る事を予定していないコンテンツ」であり、「未だ作ることも予定していない、現実には存在していない作品群」の、商品一覧カート画面である。（※アマゾン等オンラインストアに商品として存在してあるのは、予告販売の商品と、通常販売の商品である。）本発明がカートでストックしているコンテンツは、「図２９」の様に先行販売の商品であり、そして、ショップが展開可能なフィールドは、ＩＴ上の概ね全コンテンツが対象である。
＜先行販売＞＝制作者が制作の意図すら行ってない状態の商品
＜予約販売＞＝制作者が制作の意図を持っており予約商品として発表している商品
＜通常販売＞＝今すぐにでも購入できる商品

『５．アンケートシステム及び、マーケティングシステムとの比較』
本システムでは、アンケートを行うシステムではなく、あくまでも制作者側が待ちの姿勢にて、鑑賞者から依頼を受ける商品の販売ストアであり、その交渉過程の中で、顧客のアンケート要素的な意見を聞く要素も含むというだけのシステムである。本システムは依頼を受け付けるものであり、アンケートを行っている訳でも、マーケティングを行っているものではなく概念自体が相違している。

『６．コミュニティーシステム（ＳＮＳ）との比較』
本システムは、機能に於いて、SNSと類似するのだが、SNSにて、商品を販売するのは非常に難しく（又販売機能を禁止しているシステムもある）SNS機能及びそのＦＡＮ機能と、オンラインストアの機能の組み合わせで販売促進を行い商品を販売しても効果が上げられないのは周知の通りである。

『７．ＦＡＮ機能を取り入れたコンテンツ販売システムとの比較』
コンテンツに対しＦＡＮ機能を付与して販売促進を行い効果を出す方法は、人に対しＦＡＮ機能を付与するよりも押される確率は難しくなる。又、コンテンツ制作者が販売促進を行う為に、ＦＡＮボタンを押されないと予約販売を行えないというのは、購入される確率を極端に下げてしまう。この場合、ＦＡＮ機能を設置する目的は、販売促進の為の情報配信にあると考えられる。例えば、顧客が情報を受け取り損ねない様に予約販売の情報をメールで通知するなどである。これは、本機能と類似している様に見える。しかし相違点は、その情報が広告宣伝情報という性質に於いて異なっているところにある。広告宣伝としての情報を観賞者に送信するのは難しく、一般的には、その対策として公開しないプレミアム情報を用い、会員登録を促す方法が取られる。これは無料でプレミアム情報を提供する代わりに、顧客に、予約販売等の情報を送信する方法である。しかし、この場合も、厳密には顧客が欲しいのは、プレミアム情報であり、必ずしも予約情報を望んで、FAN登録を行っているとは言い難いと考えられる。その為、大抵の場合、顧客はプレミアム情報と宣伝情報が送られてくる事の損得を天秤にかけ、メリットが高いならＦＡＮボタンを押すというケースである。以上により「コミュニティーシステムのＦＡＮ機能」でも、「コンテンツ販売のＦＡＮ機能」でも、その組み合わせである、「コミュニティ」＆「オンラインショップ」も、販売促進へは限界があり販売効果を上げていない事は周知の通りである。そして、本システムはSNSではなく、完全なオンラインストアであり送信する情報は顧客の指定に基づいた情報（フォーマットにより規定された情報）である。

以上は、既存ビジネスモデルとの比較である。以下より、既存にある「ＦＡＮ機能」との比較を述べる。「ＦＡＮ機能」には様々な種類があり、「FAN」という要素は類似していても、そのデータの送受信に於いて全く異なる機能である。その為、FAN機能を一括りにはできず周知にある技術を順に上げ、その違いを述べる。（「図４７」参照）

『ＦＡＮ機能Ａ：SNSによるＦＡＮ機能』
SNSによるＦＡＮ機能は、対象が人に掛り（※ユーザーID）、人の繋がりを広げていく情報を表示する機能である。例えば、「私はこの人のＦＡＮです」と言う意思表示を示し、人と人の輪がリンクされ繋がっていくのを促している。この場合、一連のデータの送受信は以下になります。

１．（Ａ）さんが（Ｂ）さんのＦＡＮになる（ユーザーID：Aの記憶情報にユーザーID：Bを格納する）→２．（Ａ）さんのＦＡＮリストに（Ｂ）さんが入る（格納したユーザーID：Bを、Aさんの画面に公開する）。又、今後、（Ａ）さんには（Ｂ）さんの不特定多数の更新情報（記事等の件名）が送信されるようになる→３．（Ａ）さんのFANリストを一般or特定のグル―プに公開（共有）する→４．（Ａ）さんのFANリストを見た（Ｃ）さんが、そのリストの中から気になった（Ｂ）さんをＦＡＮとして登録する（ユーザーID：Cの記憶情報に、ユーザーID：Bを格納する）→（１．に戻る）というフローのデータ送受信である。

『ＦＡＮ機能Ｂ：お気に入り情報を拡散させるＦＡＮ機能』
公開ブックマークや、その他、評価ボタン等は、情報を拡散させる目的の「FAN要素」を含むボタンである。この場合の一連の情報の送受信は、

１．（Ａ）さんが、特定の記事（情報）をブックマーク（あるいは評価）する。（ユーザーID：Aの記憶情報に、ブログ記事を特定する＜タイトル/若干の記事内容/URL等＞が格納される）→２．（Ａ）さんがFANを押して格納した情報が、任意の媒体（機能提供運営サイトの画面、あるいはAさんと、SNSにより繋がっているユーザーID：の端末画面）に公開表示（共有）される→３．次に、（A）さんの、お気に入り情報を見た（Ｂ）さんは、同じ様に情報を気に入りブックマークすると、Bさんの記憶情報に、ブログ記事を特定する＜タイトル/若干の記事内容/URL等＞が格納される。→４．さらに任意の媒体（サイト運営画面又は、BさんとSNSで繋がったユーザー端末画面）に公開表示（共有）される。→５．それを見た（Ｃ）さんも、情報を気に入りブックマークすると、さらに任意の媒体（サイト運営画面又は、CさんとSNSで繋がったユーザー画面）に公開表示される」→（限りなく情報が拡散される）というフローである。又、情報の共有も収集も拡散もしない非公開ブックマークは情報を単にクリップ（整理）しているものであり機能として相違する。

『ＦＡＮ機能C：ＲＳＳ機能』
FAN機能Cでは、お気に入りブログの最新データ（更新記事）を配信し、又は、情報収集を行う目的の機能である。又、FAN機能Bが、情報の拡散を行わず、ユーザー同士のつながりが無いパターンと、同等の機能であるとする。この場合のデータの送受信は、

１．Aさんが、Bさんのブログを登録する（Aさんの記憶情報に、BさんのブログURLが格納される）
→２．又、登録したブログURLの、＜記事タイトル/５０文字程度の記事/その他の評価情報等＞が格納されたコードを格納し、更新が在ると、自動配信、又は、検索エンジンによる収集等で、Aさんはリストより、Bさんのブログ更新記事を確認することができる。


『ＦＡＮ機能D：コンテンツに掛るＦＡＮボタン』
FAN機能Dでは、予約情報の表示はＦＡＮボタンを押されずとも端末上に表示を行う為、この場合FANボタンは、宣伝広告の為の情報の配信の為に存在する。鑑賞者は、ＦＡＮボタンを押すと、わざわざサイトに訪問しなくても予約情報を送ってもらえる。又、この機能は、「会員登録機能」とも同等であると考えられる。そしてこの場合の一連のデータの送受信は、

１．Ａさんは、コンテンツ（Ａ）の何らかの情報を入手するためにＦＡＮボタンを押す（コンテンツIDと、ユーザーIDが、運営システムに格納される）→２．コンテンツ（Ａ）に関する不特定多数の情報が、メール等により送られる（又、不特定多数の中にコンテンツAの予約情報が含まれる）」

又、ＦＡＮ機能Ｄと本システムとの違いは「図４８−１」と「図４８−２」の様なものであり、「図４８−２」では、既存、FANボタンの発信というのは、「Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ」の情報が全て一緒であり、違いが無い状態である。これは「Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ」は、＝「Ｚ」という一つの情報であるという認識をしている。つまり、「Ａ」も、「Ｂ」も、「Ｃ」も、＝「Ｚ」という認識をしている。これは例えば、「果物」に対し、「果物」という認識しかしていない状態であるといえる。本発明は、「Ａ」という情報は「Ａ」であり、「Ｂ」という情報は「Ｂ」であり、「Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ」は、「各Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ」の情報であり、違いがあるという事を発見し、その違いを明確化し、効果を出すものであると言える。これは例えば、「果物」に対し、「リンゴ、オレンジ、メロン、イチゴ」と認識する状態である。そして、各オレンジ、リンゴ、メロンは、含まれる成分が異なり、この違いを発見し区別する事は、その固体を認識するだけに足りうる必要と効果があるあらだと言える。

『本システムのデータｂ』
１．Aさんが、コンテンツAの次回作を要求する（Aさんの記憶情報に、コンテンツA / ID:0001等が格納される）→２．又、コンテンツAの制作者Bへと、＜コンテンツA/ID:0001 / 次回作依頼＞というデータが送信される。→３．次回作依頼データを確認した制作者Bは、その情報を参考に、コンテンツAの次回制作計画＜コンテンツA/ID:0001/次回作予告データ＞を入力し送信する。→４．Aさんが、コンテンツAの制作計画書を確認する。というフローである。

＜ＦＡＮ機能Ａ＞と比較すると、本システムは、ユーザー同士の繋がりを広げる機能ではなく、商品を購入する機能である。ユーザー情報は公開されず制作者と鑑賞者の繋がりは無いシステムであり、目的と機能において相違しており、FAN機能Aは、本発明が課題とする解決に効果がない。＜ＦＡＮ機能Ｂ＞と比較すると、本システムは、情報を拡散する機能ではなく、鑑賞者がプライベートに商品を購入するシステムである。その為、目的と機能において相違しており、本発明が課題とする解決に効果がない。
＜ＦＡＮ機能Ｃ＞と比較すると、FAN機能Cは、FAN機能Bの情報を拡散させないパターンであるが、
データの送受信において、ブログの更新（タイトルや記事等情報）を自動で収集する機能であり、本システムは、動画、音楽、書籍、画像、ゲーム等の、コンテンツ制作依頼を送信するものであり、目的と機能において相違しており、本発明が課題とする解決に効果がない。＜FAN機能D＞と比較すると、FAN機能Dは、情報を指定しておらず、返信する内容も限定していない情報機能である。本システムは、「図４８」の様に、特定の情報を顧客が指定して、特定の情報を提供者が返信するものである。又、指定のない情報は広告宣伝情報として、指定している情報は広告宣伝ではない情報として区別している。又、本システムは顧客から依頼を行うシステムであり、目的と機能において相違しており、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）
…ユーザ（１）の過去に創られた作品（完成作品）作品名、作家名、作品情報、ユーザ（１）の経歴及び情報である。又作品にはＩＤが付与され＜例、作品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）に対し、ＩＤ認証を行う処理画面
画面１８…本発明サイトのプラットフォーム
（続きを見たい作品ランキング等、本システムに登録された続きを見たい作品、
及び過去作品が、この画面から検索できる）
画面１９…コンテンツスケジュール画面
パターン１：ざっくりとした購入前コンテンツスケジュール画面
パターン２：作品搬入日時が決定した購入後コンテンツスケジュール画面

以下、本発明の実施形態を図１に基づいて詳細に説明する。尚、図示の形態は説明を容易にする為のものであり、これにより本発明が図示の形態に限定されるものではない。

本発明の課金システムは、作品制作者であるユーザ（１）が端末（Ａ）を介して、情報データ（a）を記憶装置に蓄積し、鑑賞者であるユーザ（２）は端末（Ｂ）を介して、前記データ（a）を確認する。前記ユーザ（２）は、お気に入りの作家を見つけると、自身が作品を観賞しているＦＡＮである意思表示を表すデータ（ｂ）を記憶装置に記憶させる。前記ユーザー（１）は前記データ（ｂ）を基に、見込み顧客の確認が容易になる。

又、前記ユーザー（１）は、次回作品の予定である情報データ（ｃ）を発行する。この次回作と言う言葉が意味するのは、過去作品データaの次回作である。つまり、鑑賞者は、過去作品データaを観賞し、それを元に、前記データｂを送信し、それを受けて、制作者が、過去作品データaの次回作を制作するものであり、このデータｂは、「続きを見たい」（リピータ的要素）という信号をさす。そして、「続きが見たい」という、言葉が指す意味は、特定の過去作品aに対して、続きが見たいと述べるものであり、○○の続きが見たいという、○○が先に存在している事が前提である。つまり、作品Ａという、続きが見たくて、鑑賞者は、データｂを発信し、制作者は、作品Ａの次回作であるデータ（ｃ）を送信するものである。これは、鑑賞者は、情報を指定していると言う事を指す意味が含まれている。制作者が発信する、データＣとは、鑑賞者が、指定したデータaの次回作であり、あくまでも、作品Ａの続きを下さいと、鑑賞者が発信したら、「作品Ａ‘でどうですか？」という制作者側の返信の信号であり、データaと、データｂと、データｃは、作品ＩＤによって、ヒモ付けられているデータである事が前提である。過去作品データaは、（作品ＩＤ：０００１）であり、続きが見たいデータｂは（作品ＩＤ：０００１）の情報を送信するものであり、次回作データｃは、（作品ＩＤ：０００１）を返信するものである。また、データｃは、鑑賞者からの信号データｂ（作品ＩＤ：０００１）が届かないと、（作品ＩＤ：０００１）であるデータｃを送信できないという事を意味する。

そして、過去作品Ｂを観賞し、続きが見たいと希望するなら、作品Ｂの次回作を提供するものであり、過去作品Ｃを観賞し、続きが見たいと希望するなら、作品Ｃの次回作を提供するものであり、鑑賞者から制作者への注文である。（「図８」参照）そして、データｃを端末（Ａ）を介して、記憶装置１０１に格納すると端末（Ｂ）に表示させる。ユーザー（２）は前記データ（ｃ）を確認すると作品を購入するかどうかの意思決定を行う。尚、前記データ（ｃ）は○○という作家の次回作であるというだけの情報であって作品の中身は現時点では分からない。これは既存のオーダーという概念の枠を超える、創造性が在る製造であるという事を指す。そして、前記ユーザ（２）は過去作品情報である前記データ（a）を参考にして、お気に入りの作家に次回作を依頼するという形式である。そして、この“次回作を依頼する”というのは、ちょうど、レストランで、メニューリストを確認して注文を行う行為と類似する。過去作品情報であるデータaとは、レストランのメニュー票の様なものでり、鑑賞者が、注文したメニュー（コンテンツ）は、注文されて初めて制作者が、作り始めるというフローである。（※しかし本システムは、飲食店ビジネスとは明らかに相違する）。又、段落「０００７」のオーダーの様なシステムであるとは、このレストランで、注文を行う行為を指し、鑑賞者から制作者へ次回作を依頼する行為を指す。そして、次回作を依頼するというのは、特定のコンテンツを“指定”するということを指している。その“指定”は、過去作品データaにより、どの作品の次回作が見たいのか？を“指定”することができる。これは、カートへ入れるボタンと同等であり商品を指定して選択する。

又、制作時間は１カ月以内の短期のものもあれば１年という様な長期に渡る場合もある。そして前記ユーザー（２）が購入を選択した場合は、購入の意思であるデータ（ｄ）を端末（Ｂ）を介して記憶装置に記憶させる。コンピュータは自動的に複数の鑑賞者からなる前記データ（ｄ）の合計値（人数、金額）を計算し、端末（Ａ）に表示させる。前記ユーザ（１）が端末（Ａ）に表示された前記データ（ｄ）を確認し、もし希望に見合う数値に到達すれば制作合意の意思であるデータ（e）を記憶装置に送信する。合意であるデータ（e）を受けたコンピュータは、支払い情報データ（f）を決済システムに送信し決済システムは前記ユーザ（２）に対し課金処理を行う。また、もし前記ユーザ（１）が希望する数値に満たない場合は、拒否の意思である前記データ（e）を送信することができる。この場合、前記データ（f）は決済システムに送信されず前記ユーザ（２）に対し課金処理は行われない。そして、以上より本発明の課金システムの特徴として、制作者は売上金を得る為には、全力で予定日に間に合う様に作品を完成導入しなくてはいけなくなる。（※完成期日を過ぎると、購入者に返金されてしまう為）制作者側の、制作実行の判断はコスト的障害ではなく時間的障害になる為、購入者が少ない場合、時間が長期になり、購入者が多ければ、時間が最短になるという設定を行う形もありえる。その為、制作者の制作実行判断は、時間と購入者の兼ね合いによる判断になります。導入日を早く設定しすぎて、未達になれば収益が得られず、搬入日が遅すぎる設定なら（待たせたら）顧客を減らし購入率を下げる可能性がある。（尚、本システムにより、売買を行う鑑賞者及び制作者は、本システムにログインしている事が前提である）

次に作品が完成すると、前記ユーザ（１）は作品を搬入するために端末（Ａ）を介して、作品を記憶装置に記憶させる。又、その処理がなされた情報がメール等により前記ユーザ（２）に送信される。前記ユーザ（２）が記憶装置から作品を取り出し確認が行われると、その処理がなされた信号である情報データ（g）が決済システムに送信される。決済システムは前記データ（g）の確認によってプールしていた金額を前記ユーザ（１）に振込む処理を実行する。また前記データ（ｇ）の確認がなされない場合、例えば期日以内に作品が搬入されなかった等の制作者側に過失である場合は、課金された金額は前記ユーザ（２）に返還される。また逆に期日内に搬入したとしても前記ユーザ（２）が購入した事を忘れてしまった場合等、ケースに応じて前記ユーザ（１）に過失が無いと判断された場合は猶予期日を設けた上で前記データ（ｇ）を決済システムに送信し前記ユーザ（１）に金額が振り込まれる。

尚、上記決算手段は全てクレジット決済によるものであり振込の形態をとる場合や人的手段を要する場合は上記形態に限られるものではない。振込課金である場合の課金方法は別途にプール先である振込口座を設ける等の処置も可能であるし、また同一の口座でも可能であるが個々に応じた対応を取れるものとする。クレジット課金以外の方法である振込に関しても前述「００１３」の方法と同じものである。

又本発明は、決済後の前記ユーザ（２）による評価・レビュー機能も有するものとする。又、本ビジネスモデルは、基本的に、ある一定の信用（質量）を超えないと、“続きを見たい”とは思われないという前提があるのだが、しかし商品が不良品であった場合は返品交換がある。又、不良品の判断は少額であり購入者が多いであろうことを考えたら、比較的容易に判断がつくと考えられ、レビューや、コメント等を指標に判断を行えるものとする。

次に、図２以降を順に説明する。「図２」は、データ（b）の「続きが見たい」ボタンである。鑑賞者である前記ユーザー（２）は、お気に入り制作者に対し、意思表示として「続きが見たい」ボタンを押す事ができる。又、この「ボタン」というのは、本システムでは過去にあった動画、音楽、画像、書籍、ゲーム等の、全てを公開（無料公開含む）できるデータベースを持ち合わせてはいない事が前提である為、「図１０」の様に本システム以外のサイトへも広く他サイトへ配布することが可能である事を示している。又、コンテンツそのものの観賞は、サイト以外からであったとしても、過去作品関連情報（題名、制作者名等）は、販売を行う際には必ず必要である為、過去作品データリストへの登録が必要な事は、目的を行う際に容易に判断できる範囲内とする。次に「図３」は、前記ユーザー（２）の、「続きを見たいボタン」を押し登録を行った制作者の一覧管理画面である。データＢ’は「続きを見たい」登録の登録解除を行うボタンである。次に「図４」は、先行販売が行われるコンテンツが一覧表示された画面である。続きを見たいボタンを押した制作者の次回制作予告データを「図４」の画面で受け取ることができる。次に「図５」は、先行販売するコンテンツの予告（計画書）データである。次に「図６」は、前記計画書であるデータＤ’を表示した販売画面である。尚、データＤ’に含まれる情報の延期有無や延期の対応方法というのは、例えば、１サイクルを３０日と設定するならば、まず延期の有、無を選択し、回数（何サイクルか）を設定する。１サイクル＝３０日と設定するならば、３回までと制作者は先に設定することができる、というものである。もし、設定をしない場合（延期無の場合）は延期はできない。又、延期有だとしても、制作期日をオーバーすれば、コンテンツ料は制作者に振り込まれず、鑑賞者へ返金される形になる。又、先行販売受付期間とは、購入者を募集する期間であり、鑑賞者はこの期間内にコンテンツを先行して購入することが出来る期間である。次に「図７」は、購入後画面である。又鑑賞者が、コンテンツダウンロードを忘れない方法として、購入履歴を表示する画面を設ける処置も取れるものとする。以上が図順に説明した本発明の機能である。

以上は、本システムの軸となる構成であるが、詳細部分についての幾つかの課題があり、以下により解決方法を述べる。

１つ目は、「続きを見たい」ボタンを配布する方法である。２つ目は、過去作品データ（A−１）を、どのように登録し、どのように参照を行うのかの詳細なフローである。３つ目は、制作者より先に、鑑賞者等から過去著作情報が登録された場合に、過去作品データaにおける制作者ユーザーが同一である照合（ＩＤ認証）をどのように行うのか、と言う問題である。４つ目は、次回要求作の要求を行うデータｂに関しての詳細なデータの送受信の処理である。５つ目は、データCを返信する詳細な処理である。６つ目は、課金システムに於いて、制作者と鑑賞者と、本システム運営側の、各者、条件のバランスの調整における問題である。７つ目は、契約タイミングの調整問題である。

まず初めに、「図１３」と「図１４」は、記憶装置１０１をより詳細に記したシステムの構成図である。そしてまず「図１３」の説明を述べる。本システムの構成は、制作者端末Ａと鑑賞者端末Ｂとがインターネットで繋がっており、一連の受注手続きの処理を行う、受注処理サーバ６０１と、データ（Ａ−１）を格納する過去作品著作データベース１０１と、又、任意サイト過去作品サーバ（本システム以外）と、過去作品（コンテンツそのもの）であるデータ（Ａ−２）を格納する過去作品データベース１０２と、データ（Ｂ−１）（Ｂ−２）（Ｂ−３）（Ｂ−４）のデータＢ群を格納する依頼情報データベース２０１と、次回著作情報であるデータ（ｃ）を格納する次回著作情報データベース２０２と、完成作品（ｈ）を格納する完成作品データベース３０１と、積立金を計算し積立額データ（Ｉ）を記憶する積立金データベースサーバ４０１と、契約タイミングを調整するための情報データ（Ｊ）を格納する時間調整データベースサーバ５０１と、その他ユーザー情報管理サーバとで構成されている。

次に、受注サーバ６０１の機能構成として、「図１４」の説明を述べる。受注処理サーバ６０１は、過去著作登録処理（１２）と、制作者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認証の省略が行える処理である。

そして、４つ目の課題である、次回作の要求を行うデータｂに関しての詳細なデータの送受信を述べる。データB−１は、データｂの簡易情報であり、データB−２は、データｂの詳細情報であり、データB−３は、データB−２とデータB−２より算出した分析データである。そして「図２２」は、データｂの送信ステップ画面である。画面１０は、「続きが見たい」ボタンが設置されている場合であり、画面１１は、設置されていない場合である。そして、過去著作情報ＤＢ１０１に、登録が在る場合は、画面１２へ進み、登録が無い場合は、画面１３へ進む。そして画面１２又は画面１３にて、データB−２を入力すると、送信ボタンを押すことにより依頼ステップは完了する。データB−２の送信を終えると、観賞者は自身のログイン画面カート内（依頼一覧）に、先行依頼を行ったコンテンツが入っていることを確認できる。画面１５は、カート内画面の、データｃの要約が表示された一覧であり、画面１６は、カート内画面の要約無しの一覧である。又、データB-2は、ログイン後の登録設定により省略も可能である。

又、「図２３」は、「図２２」の、画面１１から画面１３へ、移行する間の詳細なフローであり、鑑賞者から、過去著作情報をＤＢ１０１へ格納するフローである。まず鑑賞者が、過去著作ＤＢ１０１に著作情報を問い合わせる（Ｓ７０１）。そして、希望の過去著作情報が無い場合、既存のオンラインショップ等から過去著作情報を引っ張ってくる方法（Ｓ７０２）が行える。しかし、既存オンラインショップ等から情報を拾えない場合は、鑑賞者の分かる範囲で、情報を手入力にて登録する（Ｓ７０３）。又、サイト運営者側からも情報を入手できる範囲内でリスト化する事も可能である為、この場合（鑑賞者から登録を行う場合）というのは、草の根的な情報と考えられる。又、「図２４」は、「続きを見たい」ボタンを送信する際に考えられる、４つのパターンを纏めた図である。ボタンの有無と、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内にて金額を記憶し、商品受け渡し時に制作者口座に振り込む方法である。又、積立型の若干の問題としては、２カ月後、３ヶ月後、半年後と言う様に、制作期間が長期化するほど、鑑賞者及び制作者に於いて負担となる。例えば、鑑賞者としては、購入した事を忘れてしまい、後になって支払い請求が来るリスクであり、制作者としては、期限内に完成作品を搬入しても売り上げを回収できないリスクである。（※プール型と積立型の違いは、鑑賞者の口座からの引き落ちるタイミングが相違する点である。プール型は本システムのプール口座に一旦保管されるが、積立型は本システムのプール口座を経由しない形である）この場合の解決法として、積立型とプール型の併用である混合型を有するものとする。（「図３８」参照）混合型とは、一定以上迄は、積立金での管理を行うが、一定以上を越えると、プール型に切り替わる方式である。一定のラインとは、例えば、日数であったり、金額であったり、どちらでも構わないものとする。又、コンテンツの制作日数によりタイプ分けを行い、タイプによって、積立型か、プール型か、混合型かを設定し、併用する事も可能である（「図３８下図」参照）。尚、できるだけ短期制作型を行えるようにするものとする。又、「続きを見たい」ボタンにはチップ設定を行うことも可能である。先行コンテンツ販売では、観賞者からの依頼で始まり、制作者は基本的に制作することを予定してはおらず、「続きを見たい」と言われて初めて、制作計画表を立て発表を行う為である。これは、鑑賞者側にメリットが高すぎる場合は、チップを加算し（コンテンツ本体額の５％程度）、鑑賞者側にメリットがない場合は、チップを無しにする様な、両者の条件的な調整機能である。

そして次に、７つ目の契約タイミングの調整の問題について述べる。契約タイミング問題とは、例えば、コンテンツ制作には短期のものから長期を有するもの迄様々ある。そして、例えば「続きを見たい」ボタンを押されてから、一定数の人数が確保できるまで、仮に３年掛ったとする。すると、先の人は、最初に「続きを見たいボタン」を押してから、３年待って制作計画書を受け取ることになり、又、タイミング良く制作計画書を受け取らなければなりません。又、３年後にタイミング良く購入できたとしても、さらに１年後に作品を搬入してしまう、という事もありえてきます。又、鑑賞者は購入した事を忘れてはなりません。先行販売の特長としてこの様な性質を持っており、この問題解決として本システムは、時間調整ＤＢサーバ５０１を設置するものである。

契約タイミングの調整方法を大きく分けると「心理面でのアプローチ」と「システム面でのアプローチ」での２種類のアプローチから行う。心理的アプローチでは、主に制作希望タイミングを各自把握できるよう認識を容易にする等、又、コンテンツの種類により制作期間の相場を定める等、コンテンツの購入を忘れない様に促す等、完成するのに長期の時間が掛るものは、なるべく１つの作品を数回に区切り少量で出していく等である。次に、システム的アプローチでは、ダウンロード期間を長くする等、又開始期間や完了日を緩やかに定める事ができる等である。

そして、「図３９」は、鑑賞者と制作者の契約タイミング調整データである。「図３９」の様な形で、契約タイミングを幾つかのカテゴリに分解し、各パターン化する。そして区分けされたパターンに、ラベルを設ける。又、「制作タイミング」や「確認タイミング」等は、コンピュータにより、ユーザー行動を分析し確率を出す方法と、ユーザーからの自己申告によるものとどちらでも良い。そして、利用者の任意の判断である程度の時間的タイミングが合う様に時間帯を計測し、鑑賞者と制作者の時間のリズムを調整する判断の補佐を行う。例えば、制作者の制作の頻度の情報や、鑑賞者のＷＥＢを訪問している頻度の情報（※鑑賞者のＩＤは表示しない）や、ざっくりと、「１カ月後や、２カ月後に訪問します」というような情報等である。以上を、鑑賞者のデータ（Ｊ−１）とする。

次に、「図４０」は、鑑賞者の自動入札設定機能である。上図の左側のデータ表は、制作者の希望制作タイミング情報である。これは、ざっくりとした制作者の制作情報でありデータ（Ｊ−２）とする。又、「コンテンツ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）に対し、ＩＤ認証を行う処理画面
画面１８…本発明サイトのプラットフォーム
（続きを見たい作品ランキング等、本システムに登録された続きを見たい作品、
及び過去作品が、この画面から検索できる）
画面１９…コンテンツスケジュール画面
パターン１：ざっくりとした購入前コンテンツスケジュール画面
パターン２：作品搬入日時が決定した購入後コンテンツスケジュール画面

ユーザ（１）…自らが作品を制作する作品制作者、又は自らは制作を行わないが作品を提
供する作品提供者
ユーザ（２）…作品を購入しようとするもの・鑑賞者
端末（Ａ） …ユーザ（１）の端末
端末（Ｂ） …ユーザ（２）の端末
データ（a）
…ユーザ（１）の過去に創られた作品（完成作品）作品名、作家名、作品情報、ユーザ（１）の経歴及び情報である。又作品にはＩＤが付与され＜例、作品ID:０００１＞過去作品メニューリストとして管理される。
データ（b） …過去作品データ（a）を参考にしてお気に入りの作家に次回作を依頼
する信号であり、過去作品データaよりひも付いた情報（作品ＩＤ等）を受
けて、オーダー的要素を送信する信号であり、且つ、お気に入り鑑賞者（ＦＡＮ・リ
ピータ）としての信号も含む＜作品ID：０００１/作品ID：０００１の次回作依頼＞とい
う情報である。又、「図２」は、“続きを見たい”というボタンであり、これを押すことに
よりデータｂは送信される。又、「図２」は、他サイトへ広く配布可能な形態であるボ
タンとして表している。
データ（c）
…データｂより引きついた作品ＩＤ及び、（先行販売が行われる）募集期間、作品ID：0001次回作概要・形態（例、作画/枚数、書籍/頁数、［作品名］○○の続き…）、金額、完成予定日（○月○日、所要日数○カ月）制作実行可能人数（○人以上であれば制作実行）
データ（d） …ユーザ（２）のコンテンツを購入するかどうかの意思決定（購入する）
データ（e） …ユーザ（１）の制作実行の合意or拒否の意思決定（制作するor制作しない）
データ（f） …ユーザ（２）の支払いに必要な情報（クレジットカード番号、氏名等）及び決済信号
（鑑賞者より引き落とし信号）
データ（g） …ユーザ（２）による受け取りの確認データ信号
データ（h） …完成されたコンテンツ
データ（ｍ）…制作者への振込信号
１０１…記憶装置（ＤＢサーバ）
＝＝＝＝＝＝＝＝＝＝＝＝
データＡ’…コンテンツサムネイル
データＢ’…「続きが見たい」登録解除ボタン。
データＣ’… コンテンツ題名、受付期間、制作者名等、コンテンツ内容の要約情報
（データＤ’の要約）
データＤ’…コンテンツの詳細内容（計画書）、題名、内容（あらすじ）、先行販売受付期間、完成期間、金額、コンテンツ形態（音楽、動画、画像…）制作実行予定人数（制作が実行される購入人数の目安）延長有無と延長の対応方法、他
≪データ（c）と同一≫
＝＝＝＝＝＝＝＝＝＝＝
■データ関係
データ（Ａ−１）…データaの内、著作情報部分
＜過去に創られた作品情報であり：作品ＩＤ、作者名、作品名、金額、コンテンツ形態
（書籍・音楽・動画・・・等）、その他、過去作品を特定する為のあらゆる情報。又、補足項目
として、ユーザ（１）の情報（経歴等）、制作者のその他の作品情報等＞これは、本システム
の過去著作ＤＢ１０１へ格納されるデータであり、本システムの売買には必ず必要なデータ
である）
データ（Ａ−２）…データaの内、コンテンツそのもの
制作者が過去に創ったコンテンツであり、例えば、無料で公開されているものであれば、
鑑賞者はそれを観賞する事で『続きを見たいボタン』を押しやすくなる。又、Ａ−１
と、切り離されても、コンテンツを識別するための簡易著作情報＜作品名、作品情報、
コンテンツＩＤ＞も含んでおり付与されている。これは、本システムの過去作品データベース１
０２に格納されていても、他サイトの任意のデータベースに格納されていてもどちらでもよく、オ
ンライン上に表示される形であれば良い。又、無料で公開されていても、されていなくてもどち
らでも良い。鑑賞者が次回作を購入する為の参考コンテンツである。
データ（Ｂ―１）…データｂの信号の内、簡易な次回作要求信号
（※尚、本システムは、鑑賞者から次回作の依頼を行う形のオーダー型販売システムである為、これをシステム上実行していくには、完成前商品と完成後商品を認識する事が必要であり、先行コンテンツ（本システムの取扱商品である）には必然的にIDは付与されていくものとする。
過去作品の側に配布されている「続きを見たい」ボタンを押すと送信されるデータであり、
最低限の簡易な過去著作情報を含んでいるデータ ＜例えば、作品ＩＤ/作品名/会社名著
作名/等＞である。また、本システムの過去著作データベース１０１へ問い合わせて
過去著作情報Ａ−１の有無を調べ、登録有無の値を返す。又、ボタンが無い場合は、
直接「図２３」の形で、過去作品を特定するデータを手入力で入力し、本システムの過去著作
データベースへ問い合わせする事も可能である。又、問い合わせしても過去作品情報（デー
タＡ-1）が登録されていない場合は、鑑賞者から、（データＡ-1）を直接入力し、本システムへ
登録を行い注文意思を送信することも可能である。
データ（Ｂ―２）…データｂの信号の内、詳細情報を含んだ次回作要求信号
「図２２」の画面１２、又は画面１３で、入力されるデータであり、
「作品を特定するデータa＋続き依頼＋若干のコメント＋購入確率＋日時等」である。
又は「作品を特定するデータa＋新規依頼＋続き依頼＋その他の商品の続きも
見たい＋若干のコメント＋購入確率＋日時等」である。
（※購入確率とは顧客が、どれぐらい続きが見たいかの指標を表すデータ。例えば、星マーク等
の５段階表示でも良い。又、このステップは、ログイン後であれば、鑑賞者が本システム内に
一律の情報を登録しておき省略する事も可能である）
データ（Ｂ―３）…データＢ−２を基に、算出された値や統計データであって、
制作者端末Ａに表示されるデータ。
「コンテンツＡの続きが依頼されました/依頼者ＩＤ/ 若干のコメント/日時/購入確率等」
→「コンテンツＡの依頼者総合人数/総合購入確率等」
「コンテンツＢの続きが依頼されました/依頼者ＩＤ/若干のコメント/日時/購入確率等」
→「コンテンツＢの依頼者総合人数/総合購入確率等」
「コンテンツＣの続きが依頼されました/依頼者ＩＤ/新規/鑑賞者人数/若干のコメント/
日時等/購入確率等」→「コンテンツ新規の依頼者総合人数/購入確率等」
というオーダー一覧（依頼票）形式の情報（「図３１」参照）
データ（Ｂ−４）…過去作品を厳密に指定したデータ。
過去作品コンテンツＡ（ＩＤ：０００１）があった場合、さらに、
過去作品コンテンツＡの内の（ＩＤ：０００１−１）という作品
過去作品コンテンツＡの内の（ＩＤ：０００１−２）という作品
過去策作品コンテンツＡの内の（ＩＤ：０００１−３）という作品の
データ。
データ（Ｃ―１）…次回著作情報（制作者入力情報）≪データｃと同一≫
『著作情報である、販売が行われる募集期間（※先行販売受付期間）
コンテンツの詳細内容（計画書・次回作概要・題名、あらすじ等）
コンテンツ形態（音楽、動画、画像…）「例、作画/枚数、書籍/頁数、［作品名］
○○の続き…」金額、完成予定日（○月○日、所要日数○カ月）制作実行可能人数
（○人以上であれば制作実行等・制作が実行される購入人数の目安）延長有無と
延長の対応方法、他』
また、顧客からの依頼が、作品（Ａ）であり、制作者は次回作（Ａ’）という作品を制作する場合は、
作品（Ａ‘）というデータを、規定のフォーマットへ入力する規定の著作情報であり、
顧客からの依頼が、作品（B）であり、制作者は次回作（B’）という作品を制作する場合は、
作品（B‘）というデータを、規定のフォーマットへ入力する規定の著作情報であり、
顧客からの依頼が、作品（新規）であり、制作者は次回作（新規’）という作品を制作する場合は、
作品（新規‘）というデータを、規定のフォーマットへ入力する規定の著作情報であり、
観賞者からの応答による情報である。
データ（Ｃ―２）…鑑賞者の端末（カート内）に表示されるデータ（Ｃ−１）
「作品Ａの続き」であれば、「作品（Ａ’）の情報が届く」
「作品新規依頼」であれば、「作品新規の情報が届く」
と言う様に、鑑賞者が指定した商品データにひも付いて送信されるデータであり、
鑑賞者が、データ（ｂ）を送信する際に、作品Ａ、作品Ｂと、選択していなければ届かない。
同一作家の、その他の作品も可能であれば、宣伝広告として表示できるが
依頼商品とは明確に区別されている。
データ（Ｃ−３）… コンテンツ題名、受付期間、制作者名等、コンテンツ内容の要約情報
（※データc−１の要約）
データ（Ｉ）…積立金額
データ（Ｉ−１）…積立金額の内、（鑑賞者の購入金額、積立金合計額）
データ（I−２）…積立金額の内、（コンテンツ事に振り分けられる等した、積立型、プール型、混合型の情報）
データ（J）…時間調整データ
データ（J−１）…時間調整データの内、（自動入札者以外の鑑賞者側希望タイミング情報等）
データ（J−２）…時間調整データの内、（制作者の、ざっくりとしたコンテンツ制作希望タイミング・日数時間等）
データ（J−３）…時間調整データの内、（鑑賞者の自動入札設定に関するデータ
＜自動入札回数、最大期限、上限金額等＞）
データ（J−４）…時間調整データの内（制作合意後の購入が決まった完成日時データ・搬入可能日時）
データ（Ｋ）…その他のデータ、（金額、日数等の相場表）
データ（Ｌ）…ユーザー情報等
■ＤＢサーバ関係：記憶装置１０１詳細
１０１…過去作品著作情報データベース（データＡ−１を格納する）
１０２…過去作品データベース（データＡ−２を格納する）
２０１…依頼情報データベース（データＢ−１、Ｂ−２、Ｂ−３、Ｂ−４を格納する）
２０２…次回作情報データベース（データＣ−１を格納する）
３０１…完成作品データベース（データｈを格納する）
４０１…積立金データベースサーバ
５０１…時間調整データベースサーバ
６０１…受注処理サーバ（一連のプログラムを処理する）
■プログラム処理関係
１１…作者ＩＤ認証に関する一連の処理
１２…過去作品を登録する一連の処理
１３…依頼情報を送受信する一連の処理
１４…次回作情報を送受信する一連の処理
１５…受注処理に関する一連の処理（メール通知等、その他諸々）
１６…ボタン生成など「続きを見たい」ボタンを配布する一連の処理
１７…完成作成搬入の一連の処理（ＵＰロード、ダウンロード等）
■画面関係
画面１０…ボタンが設置されている画面
画面１１…ボタンが設置されておらず鑑賞者が自身で制作者名と作品名を入力する画面
画面１２…過去作品著作情報ＤＢ（１０１）に作者の登録が在る依頼入力画面
画面１３…過去作品著作情報ＤＢ（１０１）に作者の登録が無い依頼入力画面
画面１４…受付画面
画面１５…カート内画面１（通知された、データcの簡易情報を表示した一覧）
※鑑賞者のプライベート情報であり情報保護画面、非公開画面
画面１６…カート内画面２（続きが見たい作品の全容が確認容易な画面）
※鑑賞者のプライベート情報であり情報保護画面、非公開画面
画面１７…データ（Ｂ−２）が表示されている制作者画面
パターン１：個別依頼確認
パターン２：統計確認
パターン３：次回作入力選択画面
パターン４：次回作入力フォーマット
パターン５：過去作品登録漏れにより、鑑賞者から先に入力された（認証可能な）
過去作品データ（a）に対し、ＩＤ認証を行う処理画面
画面１８…本発明サイトのプラットフォーム
（続きを見たい作品ランキング等、本システムに登録された続きを見たい作品、
及び過去作品が、この画面から検索できる）
画面１９…コンテンツスケジュール画面
パターン１：ざっくりとした購入前コンテンツスケジュール画面
パターン２：作品搬入日時が決定した購入後コンテンツスケジュール画面

ユーザ（１）とユーザ（２）とで行われる売買に於けるフローチャート図 「続きが見たい」ボタン 「続きが見たい」制作者を一覧表示した画面 先行販売作品の一覧表示した画面 制作計画書（作品予告データ）の表示画面 先行販売作品の内容表示画面 購入後画面（参考例） 鑑賞者と制作者の作品売買におけるデータの送信のフロー 鑑賞者から先行して売買が始まる先行コンテンツ販売における図 続きを見たいボタン配布図（イメージとしてRSS型オンラインショップである） 既存オンラインショップのカートボタンとの比較 先行コンテンツオンラインストアのイメージ図 先行販売システムの全体構成図(※記憶装置１０１詳細図) 先行販売システムの全体構成図（※受注サーバ６０１詳細図） 各コンテンツの次回作依頼が送信された時の鑑賞者と制作者の相互間のステップ図 （※鑑賞者と制作者の間のデータ送受信は、各作品IDがヒモ付けられている図） 制作者が鑑賞者群に次回作情報データCを送信する図 （※各次回作データが作品IDでヒモ付けられた各鑑賞者へ送信される） 先行コンテンツ（依頼商品）と宣伝広告コンテンツとの明確な区分がされている図 「続きを見たい」ボタン配布パターン１（制作者の手作業での設置） 「続きを見たい」ボタン配布パターン２（任意サイト運営者側の設置） 過去作品著作ＤＢ内のデータ（ａ）の制作者ＩＤ認証済データと認証未処理データ 過去作品登録における鑑賞者からのステップと制作者からのステップのフロー図 続き依頼であるデータ（B-2）の送信ステップ（画面） （※「続きが見たい」ボタンが設置されている場合とされていない場合。又、本システム に過去著作情報が登録されている場合とされていない場合におけるステップ） 続き依頼であるデータ（B-2）の送信ステップ（画面） （本システムに制作者側からの登録が無い場合、鑑賞者からの登録を行うステップ１） ボタン有無と、過去著作ＤＢ１０１内のデータ有無とに於いて、 ４つのパターンからのデータｂの送信ステップ 続き依頼であるデータ（B-2）の送信ステップ（フロー図）（本システムに制作者側からの登録が無い場合の鑑賞者からの登録を行うステップ２） 制作者の本人確認を行うＩＤ認証方法のパターン 制作者の本人確認を行うＩＤ認証フロー 依頼情報データベースに格納されるデータ（B-2） 続き依頼（データB−2）を受けて、次回作（データｃ）を送信するフロー 続き依頼を送信した後の、各３つの画面図（制作者画面、鑑賞者画面、本システムサイト） 制作者端末Ａの、依頼データB-3の表示画面（パターン１とパターン２） 依頼画面から、既定のフォーマット画面に入り、次回作情報を入力送信する図 先行コンテンツサイト画面（※本システムのメイン画面） 先行コンテンツサイト画面のID認証済みと未処理の２つの過去情報が検索表示される図 （※無料公開コンテンツＵＲＬは制作者管理による） 制作者ログイン画面であり、本システムに制作者ＩＤは登録しているが、過去作品情報登録漏れがあり、鑑賞者側から先に過去作品情報の登録が在った際の作品認証画面。 一連の制作者フローと一連の鑑賞者フロー 課金システムのフロー図（プール型と積立型） 課金システムのフロー図（プール型と積立型の混合型） 鑑賞者と制作者の契約タイミング調整データ タイミング調整データを使った統計図 コンテンツ制作時間相場表 契約タイミング調整フロー 本発明の課題 本発明が課題を解決する方法である、真逆のビジネスモデルの概要 本ビジネスモデルの軸の構造のイメージ図 市場と機能のフローイメージ図と、提供者と顧客の力関係の比較 既存FANボタンとの比較図１ 既存FANボタンとの比較図２ 既存FANボタンとの比較図３ カートに入れる前とカートに入れた後の図 データＢ群の詳細フロー 厳密にコンテンツを指定する図 同一制作者及び同一コンテンツの過去作品バリエーションの選択可能性 購入フロー及び、機能のまとめ図 その他事項

そして課題としては、鑑賞者と、制作者と、本システム運営側の負担におけるバランスについてである。これは、先行コンテンツという商品を扱うにあたり、購入から作品受け渡し迄の、宙に浮いてしまう空白期間が存在してしまう為、その期間の資金における３者の負担の分散を行いたいという問題である。以下に３者における各問題を述べる。

「制作者側の問題として」
例えば、制作に１カ月を要するコンテンツがあり、鑑賞者から依頼の注文だけが大量あったとしても直前になって購入を辞められてしまうリスクがある。これを防止する方法として、鑑賞者に依頼の段階で、購入の責任を負ってもらう事で対処を行う。しかしながら、まだ、作品を受け渡していないのに、売上金を得る事はできないものとし、プール型の課金方法を行うものとしている。

「鑑賞者側の問題として」
通常であれば制作を行わなかった製品に対し、鑑賞者側から依頼できるというメリットがある為、依頼を行っているという形態だからこそ、制作予定購入段階で課金に責任を負うものとする。しかしながら、商品を手に入れていない段階で課金を行うという事は、前倒しの支払いであり、負担があるという問題である。

「本システム運営側の問題として」
プール型の場合、システム運営側の管理に対する責任が重いという問題が在る。又、無駄な手数料が掛る場合もある。又、既存ビジネスモデルでは無い為一から複雑なシステムを考えなくてはならず、又、開発に於いても費用が掛る。

その為、以上により、「図３７」の様な、積立型を考える事ができる。積立型は、積立金DBサーバにより、データだけで購入金額を管理する方法である。これは、購入したトータル額を計算し、DB内にて金額を記憶し、商品受け渡し時に制作者口座に振り込む方法である。又、積立型の若干の問題としては、２カ月後、３ヶ月後、半年後と言う様に、制作期間が長期化するほど、鑑賞者及び制作者に於いて負担となる。例えば、鑑賞者としては、購入した事を忘れてしまい、後になって支払い請求が来るリスクであり、制作者としては、期限内に完成作品を搬入しても売り上げを回収できないリスクである。（※プール型と積立型の違いは、鑑賞者の口座からの引き落ちるタイミングが相違する点である。プール型は本システムのプール口座に一旦保管されるが、積立型は本システムのプール口座を経由しない形である）この場合の解決法として、積立型とプール型の併用である混合型を有するものとする。（「図３８」参照）混合型とは、一定以上迄は、積立金での管理を行うが、一定以上を越えると、プール型に切り替わる方式である。一定のラインとは、例えば、日数であったり、金額であったり、どちらでも構わないものとする。又、コンテンツの制作日数によりタイプ分けを行い、タイプによって、積立型か、プール型か、混合型かを設定し、併用する事も可能である（「図３８下図」参照）。尚、できるだけ短期制作型を行えるようにするものとする。又、「続きを見たい」ボタンにはチップ設定を行うことも可能である。先行コンテンツ販売では、観賞者からの依頼で始まり、制作者は基本的に制作することを予定してはおらず、「続きを見たい」と言われて初めて、制作計画表を立て発表を行う為である。これは、鑑賞者側にメリットが高すぎる場合は、チップを加算し（コンテンツ本体額の５％程度）、鑑賞者側にメリットがない場合は、チップを無しにする様な、両者の条件的な調整機能である。
又、以上の、データh 〜 mまでの流れを纏めると、
『積立型のフロー』（※５００円は仮数字）
１．データｆ受信＜作品ＩＤ：０００１/タイプＡ型/積立型/５００円＞次に、
２．データｈ受信＜搬入完了＞次に、
３．データｍ送信＜鑑賞者ＩＤ：０１より課金/制作者ユーザーＩＤ:０１口座へ振込/５ ００円＞
『プール型フロー』
１．データｆ受信＜作品ＩＤ：０００２/タイプＢ型/プール型/５００円＞次に、
２．送信＜鑑賞者ＩＤ：０１より課金/プール口座振込/５００円/制作者ＩＤ：０２/売上 保管/引落予定日.（第１）○年○月○日（第２）○年○月○日（第３）○年○月○日＞次 に、
３．データｈ受信＜搬入完了＞次に、
４．データｍ送信＜プール口座より引落/制作者ユーザーＩＤ：０２口座へ振込/５００円 ＞
『混合型』
１．データｆ受信
＜作品ＩＤ：０００３/タイプＣ型/混合型/５００円＞
＜作品ＩＤ：０００４/タイプＣ型/混合型/５００円＞
＜作品ＩＤ：０００５/タイプＣ型/混合型/５００円＞
＜作品ＩＤ：０００６/タイプＣ型/混合型/５００円＞
＜作品ＩＤ：０００７/タイプＣ型/混合型/５００円＞次に、
２．日数（１カ月等）or一定金額を越える（条件は設定可能。※纏めて振込）
送信＜鑑賞者ＩＤ：０２より課金/プール口座へ振込/１５００円/
内、作品ＩＤ：０００３/制作者ユーザーＩＤ：０３/売上保管/引落予定日
内、作品ＩＤ：０００４/制作者ユーザーＩＤ：０４/売上保管/引落予定日
内、作品ＩＤ：０００５/制作者ユーザーＩＤ：０５/売上保管/引落予定日＞ 次に、
（※又、混合型は、プール口座へ引き落ちる条件は設定変更・追加できる。例えば、コン テンツ個々にプール口座へ引き落ちる設定を行っても構わないし、鑑賞者ユーザー積立額 に対して条件を設定する事も可能。）
３．データｈ受信＜搬入完了＞次に、
４．データｍ送信
＜プール口座より引落/制作者ユーザーＩＤ：０３口座へ振込/５００円＞
＜プール口座より引落/制作者ユーザーＩＤ：０４口座へ振込/５００円＞
＜プール口座より引落/制作者ユーザーＩＤ：０５口座へ振込/５００円＞）で ある。

次に、「図５３」は、以上の一連のステップと機能を纏めた図である。又、本システムの 要件定義は、「制作者の未だ制作の予定のしていないコンテンツを、鑑賞者から先に制作 者へ、“続きを見たい”と言って次回作の依頼を行うシステムである」この定義を、シス テム上に実相していくと必然的に行わざる負えない設定として以下の事柄があります。例 えば、ボタンの形も、「続きが見たい」だけではなく、「続き依頼」「次回依頼」「つづ き」「ＮＥＸＴ：Contents」「ＮＥＸＴ：Ｃ」「もっと見たい」というパターンもあり最 適なネーミングを考えて行くことになります。又、コンテンツアイコン表示画面に対して も、制作が決まったコンテンツと決まっていないコンテンツの２つのパターンが在るため 、その違いを認識するための画面は必然的に作られるものとします。又、ＩＤは、システ ム実相上識別番号として必ず付与せざる負えないデータである為、付与するものとしてお ります（「図５４」参照）。以上により本発明は構成されるものとする。

ユーザ（１）…自らが作品を制作する作品制作者、又は自らは制作を行わないが作品を提供する作品提供者
ユーザ（２）…作品を購入しようとするもの・鑑賞者
端末（Ａ） …ユーザ（１）の端末
端末（Ｂ）…ユーザ（２）の端末

データ（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）に対し、ＩＤ認証を行う処理画面
画面１８…本発明サイトのプラットフォーム
（続きを見たい作品ランキング等、本システムに登録された続きを見たい作品、
及び過去作品が、この画面から検索できる）
画面１９…コンテンツスケジュール画面
パターン１：ざっくりとした購入前コンテンツスケジュール画面
パターン２：作品搬入日時が決定した購入後コンテンツスケジュール画面

本発明は、オンライン上で販売可能なコンテンツ、画像、動画、電子書籍・雑誌・漫画、音楽、ゲームを対象とした芸術的クリエイティブな創作活動を要する著作物の販売課金システムであり、制作者が制作するよりも前の段階から、鑑賞者よりコンテンツ売買に於ける手順が開始される事に特徴を有している。

従来のオンライン上でのコンテンツ販売の方法は、コンテンツ制作者側及び仲介者が創作物をオンライン上にて表示し、鑑賞者はその表示された商品を観て判断し購入するというステップである。購入に至るまでの段階には、音楽であれば視聴機能、書籍であれば中身拝見機能などのお試し機能があり、これらによって購買の意思決定を高めるという手段がある。又、昨今、制作者の制作環境は悪化しており、これらを解決する方法として寄付金を集って、制作者の制作資金を集める方法が存在する。又、従来よりの市場モデルとしては、予約販売システム、オーダーシステム、投資システム、アマゾン等のオンラインストアシステム、アンケートシステム、マーケティングシステム、コミュニティーシステムが存在する。尚、段落「００１８」〜「００１９」にて、相違点を詳細に述べる。

不明

従来の方法によると制作者側としては、作品を制作するかどうかの意思決定が難しいという問題がある。例えば、作品を制作しても必ずしも売れる（資金が回収できる）かどうかの確証はつかず、結果、資金不足で制作中止という判断に陥ってしまう。観賞者側の問題としては、お気に入りの作家の次回作品が見たくても、制作者側の予算不足の問題等で制作中止となり観賞が不可能になるケースがある。又、従来では作品を制作するかしないかは、作品の流通を担う販売会社等の予測による販売決定に委ねられているのだが、制作会社が鑑賞者側の意思を完全に組み切れているとは言い難いという問題が残る。又、現在、インターネットでのコンテンツの流通というのは、制作者の著作権を守りきれていない現状がある。不正コピー、不正な投稿等、今後もますますこの課題は広がっていき、課題として残ったままである。コンテンツ制作者はインターネットの到来により表現への自由度は高まったが、既存のビジネスモデルの崩壊など、制作改善の進展には効果が低い。

又、既存モデルの崩壊とは、コンテンツの無料化問題を指し、ＩＴ技術によりコンテンツ市場の無料化が益々進んでいく中で、コンテンツ市場での制作者の制作環境を維持するのが極めて困難であった。その一原因としてＩＴ以前の時代であれば制作者側は少数であったが、ＩＴ後の時代ではごく一般人でも容易に制作者側へと回れる環境である為、参加者が増加し、優良且つ無償の作品が競う様にＷＥＢ上で供給されている事が上げられる。この様な状況では、当初は、無償の優良のコンテンツが存在しているのだが、無料化がピークを越えると制作側が疲弊し、次には、反動で極端にコンテンツの質が低下するという問題がある。又、制作者が疲弊していくと鑑賞者は良質な作品を見る事が困難になる。（「図４３」参照）

以上は、ＷＥＢ上に存在している周知の課題であり、長らく解決できずにいる難問である。又、段落「００２５」２行目に記載の「販売側と購入者側の品切れによる販売ロスを避ける目的の為にあり…」と言うのは、制作者側の時間捻出の問題の解決を試みるもので異なるという意味であり、本発明は、原価というコストリスク（赤字リスク）回避に留まらず、制作者が作品（いわゆる画像、音楽、文書、動画等の表現作品）を制作するにあたり、アルバイトや仕事を行いながら作品を制作しないといけないという環境を解決したいとするものである。これを考えるにあたり「制作時間を捻出できないか？」という課題を持つものである。通常、作品を制作するにあたり“コスト”という物理的な費用の壁を感じたとしても、自分自身の“時間”の壁には絶対的な不可能なできない理由を感じず、多少不便を感じつつも“時間”は無料である為、仕方のない事、気合いで何とかなる事だと考えられている。一般的に、時間的障害とは制作者が当然、負担しなければならない制約であると考えられており、その為、時間は本人の「やる気」の問題という心理的問題で片付けられている。しかし、本発明は制作者の時間捻出の解決を課題としている。

上記課題を解決する為に、請求項１に記載のコンテンツ販売方法は、コンテンツ提供者であるユーザー（１）と、少なくとも一人以上で構成されるコンテンツ鑑賞者（又は購入者）であるユーザー（２）の各端末が、インターネット回線より繋がっており、前記ユーザ（１）は、既に過去に制作した観賞可能な過去作品を有している事を前提として、過去作品を観賞した前記ユーザー（２）が、その過去作品の提供者であるユーザー（１）の次回の作品を観賞したい場合、前記ユーザー（１）が、次回作を製作する事を「予定している / 予定していない」に関わらず、制作者が、制作予定を立てる段階からでも、前記ユーザー（２）から前記ユーザー（１）へ、コンテンツの次回作品の購入の要求を行い売買が始まる事を特徴とし、前記ユーザー（１）が、前記ユーザー（２）の要求を受けて制作の判断を行い、そして「制作を行う」という判断ならば次回作を作成し、コンテンツの提供を行えることで解決を行う。（尚、段落「００１５」に詳細に記載）

又、請求項２に記載のコンテンツ販売方法は、コンテンツ制作開始から商品引き渡し迄に於ける売買における一連の販売工程であり、主に、九段階のステップを特徴としている。

第１のステップは、過去作品の情報を本システムに登録する工程であり、
第２のステップは、鑑賞者が、次回作要求信号を送信する工程であり、
第３のステップは、制作者が次回作概要データを送信する工程であり、
第４のステップは、次回作概要データを確認した鑑賞者が、「購入する・しない」の信号を送信する工程であり、
第５のステップは、制作者が制作を「する・しない」の信号を送信する工程であり、
第６のステップは、制作者が制作を「する」と選択した場合は、決算処理部にて決済を行っていく処理の工程、又は、制作者が制作を「しない」と選択した場合は、決算処理部にて決済を行っていかない処理の工程であり、
第７のステップは、制作者が、作品が完成した事を通知する工程であり、
第８のステップは、購入者が、完成作品を受け取る工程であり、
第９のステップは、作品が購入者に渡されると、制作者へ売上金額を支払う処理の工程、又は、作品が購入者に渡されなければ、制作者へ売上金額が支払われない処理の工程であり、
以上の一連の工程である。

尚、第１のステップと第２のステップは、順序が逆であっても構わずとは、本システムに過去作品の登録が無かったとしても、先に、次回作信号を発信して、そのコンテンツのストックを行い、その後、過去作品情報を登録する方法である。又、第７と第８のステップに於いても、順序が逆であっても構わずとは、例えば、完成作品を購入者へ先に渡し、その後、制作者が、完成作品の登録を本システムに行う方法である。尚、完成作品が本システムに登録されると、過去作品（データa）として記憶装置に格納されるものとする。その為、完成作品（データｈ）の登録とは、過去作品（データa）の登録と本質的には同じである。又、段落「０００９」に記載の様な、ステップのショートカットに於いても、同様とする。（尚、段落「００１６」〜「００１７」/ 参考までに「００２０」/「００３０」〜「００３６」に詳細に記載。）又、請求項３に記載の内容は、次回作依頼を行う方法として、データｂを送信する操作方法である。

又、請求項４に記載のコンテンツ販売システムは、コンテンツ販売システムにおける一連の流れである。そして、一連の特徴的なデータの流れを纏めると、以下の流れとなる（※尚、ＩＤは、ヒモ付いている事を説明するための仮の数字である）。

ステップ１ → データa＜作品ID:0001/過去作品＞の登録
ステップ２ → データb＜作品ID:0001/ nxID01/次回作依頼＞の受信及び、端末Ａへ表示
ステップ３ → データC＜作品ID:0001 nxID01/次回作概要＞の受信及び、端末Ｂへ表示
ステップ４ → データｄ＜作品ID:0001 nxID01/次回作/購入する＞の受信及び、端末Ａへ表示
ステップ５ → データe＜作品ID:0001 nxID01/次回作/制作する・しない＞
の受信及び、端末Ｂへ表示
ステップ６ → データｆ＜作品ID:0001 nxID01/決済処理信号（データ）＞の送信
ステップ７ → データｈ＜作品ID:0001 nxID01/→完成作品ID:0002＞を受信及び、端末Ｂへ通知
ステップ８ → データｇ＜作品ID:0001 nxID01（完成ID:0002）作品受領信号＞を受信
ステップ９ → データｍ＜作品ID:0001nxID01（完成ID：0002）制作者振込データ＞）
を基に決済処理の実行

以上のデータの流れと、そのデータ移動に伴う、各処理を含むコンテンツ販売システムである。※尚、nｘID01とは、完成したコンテンツと区別した仮番号のＩＤであり、システム実相上必然的に付与されるデータとする。又、あらかじめ事前にデータを作成し、自動処理を行う事による処理の前後関係の入れ替えによる方法でも同様の処理とする。又、ショートカットにより間の処理を飛ばす場合に於いても同様とする。例えば、間のショートカットとは、ステップ２のデータｂを送信した時点で、ステップ６へ飛び、決算処理を行う方法である。そして、ステップ８で作品の受領が行われるとステップ９へ飛び、提供者へ売上金額が振り込まれる方法である。又、作品の受領が行われなければ、制作者へ売上金額は振り込まれず、同様の処理を行うものとする。しかしながら、ステップ３の次回作概要が、第１ステップで行う場合に於いては、既存の予約販売と同様である為、本発明には該当しない。（尚、本発明には該当はしないが、本システムが使用する事は可能である）尚、購入者の失念等の過失により受領通知（データｇ）が受信されない場合に於いては、ステップ８を飛ばし、ステップ９の制作者への振込を行う処理を行う方法も同様とする。又、ステップ４の「購入する・しない」の工程を、「見なし購入」という形で何らかに購入する確保を行うが、しかしながら購入したわけではなくステップ６の決算処理を行わない形で、ステップ８の段階で購入した、という形にして決済処理を行う方法でも同様である。これは、積立課金による処理と本質的には同様であるとする。（尚、段落「００１６」〜「００１７」/参考までに「００２０」/「００３０」〜「００３６」に記載）

又、請求項５に記載に記載のコンテンツ販売方システムは、上記の販売フローをスムーズに行う為の、画面操作及び、その画面構成であり、前記データ（b）の送信処理として、前記ユーザー（２）が次回作を要求する行為として認識が容易な名称のボタン（例えば、「続きが見たい」という様な名称のボタン）にて前記データｂを送信する方法である（尚、「図２」参照）。又、データｂを送信する処理は、「続きを見たい」ボタンの設置の有・無におけるパターンと、過去作品（データa）が事前に登録されている・されていない、場合におけるパターンの、主に４つの状況からなるパターンの処理を、その状況に応じて対処する事が可能な処理を有している。（「図２４」参照）又、請求項６に記載のコンテンツ販売方システムに於いても、上記の販売フローをスムーズに行う為の、画面操作及び、画面構成であり、前記ユーザー（２）の端末にて表示するカート画面を有しており、前記カート画面は、前記ユーザー（２）が前記データｂの送信ボタン＜仮に、コンテンツＩＤ：０００１とする＞を押すと、画面内に、コンテンツＩＤ：０００１の＜先行コンテンツアイコン/コンテンツ属性データ/等＞を表示する構成と、且つ、当該コンテンツをストックして表示する構成を有している。尚、依頼要求のあるものは次回作概要（データｃ）として表示し、依頼要求が無いものは、その他の広告情報として区分して表示する構成も有しているものとする。又、前記カート画面は、コンテンツ一覧リスト画面（「図３」「図４」参照）と、コンテンツ詳細画面（「図６」参照）を有しており、前記コンテンツ一覧リスト画面は、データｂを送信して選択を行ったコンテンツが、複数の先行コンテンツが表示された一覧で表示された画面であり、各先行コンテンツアイコンとその属性データ、及び次回作概要データｃの要約、各解約ボタン等、を表示する画面構成である。又、前記コンテンツ詳細画面は、前記一覧リストより、コンテンツを選択すると表示される画面であり、コンテンツの詳細データ＜データＣの全部の情報＞と、購入の流れに進む＜購入ボタン＞が設置されている画面構成である。（尚、段落「００３７」/「００６２」/参考までに「００２１」/ にて詳細に記載）

又、請求項７に記載のコンテンツ販売システムの決済処理は、制作者と鑑賞者と運営者の３者間の課金における負担のバランスを調整する手段であって、コンテンツの形態等の条件により調整が可能であって、プール型課金による処理、積立型課金による処理、混合型課金による処理の、いずれかの課金処理、又は、いずれかの課金処理の組み合わせ、又は、全ての課金処理の組み合わせを有しており、前記プール型課金による処理は、前記ユーザー（１）より、制作＜合意＞であるデータ（e）を受信すると、前記ユーザー（２）より課金処理を行うのだが、前記ユーザ（２）より課金した金額は、完成作品の受け渡しが完了するまで、一旦プール口座で保留しておく処理であり、そして作品が完了し、前記ユーザー（２）に完成作品が渡されると、受領完了通知として信号データ（g）が決済処理部に送信され、前記データ（g）を受信した決済処理部は、プール口座より、前記ユーザ（１）へ売上金額を支払う処理であり、又、決済処理部が、前記データ（ｇ）を受信できなかった場合は、前記ユーザ（２）へ金額が返金される処理を有しており、又、前記積立型課金による処理は、前記ユーザー（１）より、制作＜合意＞であるデータ（e）を受信すると、前記ユーザー（２）より直ぐに課金を行うのではなく、購入額を積立額として記憶装置に記憶しておく処理を行い、そして、前記ユーザー（２）が完成作品を受け取ると、受領完了通知として前記データ（g）が、決算処理部に送信され、前記データ（ｇ）を受信した決算処理部が、前記ユーザー（２）より積立額の金額を課金し、前記ユーザー（１）へ売上金額を支払う処理であり、又、前記データ（ｇ）を受信出来なかった場合は、積立額を帳消しにする処理を有しており、又、前記混合型課金による処理は、前記プール型による処理と前記積立型による処理を合わせた課金処理であり、定められた条件により、プール型と積立型の設定を使い分ける課金処理である。（段落「００３９」/「００５５」〜「００５７」にて詳細に記載）

又、請求項８に記載のコンテンツ販売システムは、第一のステップである過去作品の詳細な登録方法であって、前記データaの詳細データとして、属性データである過去作品著作情報をデータ（Ａ−１）とし、コンテンツそのものである過去作品のデータをデータ（Ａ−２）として有しており、又、コンテンツそのものである（Ａ−２）に於いては、他のシステム（サイト）等を利用して観賞を行い、当該記憶装置に記憶しない方法であっても構わないものとする。又、過去作品の登録方法は、主に、２つのバリエーションがあり、コンテンツ提供者から登録される方法、又、コンテンツ提供者以外から登録される方法があり、その処理方法として、前記コンテンツ販売システムは、過去著作登録処理部（１２）と、コンテンツ提供者ＩＤ認証処理部（１１）とを備えており、前記過去著作登録処理部（１２）は、前記ユーザー（１）又は、前記ユーザー（２）より、記憶装置へ、データ（Ａ−１）の格納（登録）を行う一連の処理であって、又、前記データ（Ａ−１）の記憶装置への登録は、例えば、本人である前記ユーザー（１）より、過去コンテンツが登録されるケース等で、コンテンツ提供者とのＩＤ認証が照合されている場合であれば、ＩＤ認証処理＜済み＞のデータ（Ａ−１）として記憶装置に格納され、又、例えば、提供者本人ではなく前記ユーザー（２）より過去コンテンツが登録されるケース等で、コンテンツ提供者とのＩＤ認証が照合されていない場合であれば、ＩＤ認証＜未処理＞のデータ（Ａ−１）として、振り分けられる処理を有しており、又、コンテンツ提供者ＩＤ認証処理部（１１）は、ＩＤ認証＜未処理＞データをＩＤ認証＜済＞データへと照合を行う一連の処理であって、コンテンツ提供者である前記ユーザー（１）が、当該システムの所定の認証方法でＩＤ認証を行う処理である。（段落「００３９」/「００２７」/「００４２」〜「００４６」にて詳細に記載）

又、請求項９に記載の内容は、鑑賞者（又は購入者）が次回作を要求する（データｂを送信する）詳細なフローであって、前記データｂの詳細データとして、最低限の簡易な過去著作情報を含んでいるデータ ＜例えば、作品ＩＤ/作品名/会社名/作者名/等＞を（Ｂ−１/ 簡易・過去作品指定情報）として、又、詳細情報を含んだデータ＜例えば、コメント/日時/新規作品可/鑑賞者の購入予定パーセンテージ度/等＞を（Ｂ−２ / 詳細・次回作依頼情報）として、又、過去作品を厳密に指定したデータを（Ｂ−４/過去作品厳密指定情報）として、又、データ（Ｂ−１/Ｂ−２/Ｂ−４）を基に算出された値や統計データを（Ｂ−３/算出された値）として備えており、データＢ群を前記ユーザー（２）より受信し、前記ユーザー（１）の端末へ表示する処理である。（尚、段落「００３９」/「００４７」〜「００４９」にて詳細を記載）。又、請求項１０に記載の次回作情報送受信処理部（１４）は、前記ユーザー（１）が、前記データｂを受けて、次回作概要データｃを入力し、前記次回作概要データｃを送信するまでの操作における一連のフローであり、これは、前記ユーザー（１）が、前記データｂの内容を確認すると、要求を受けたコンテンツの中から、制作を行うコンテンツを選択し、コンテンツＩＤがヒモ付いた形で、前記データｃの入力を行える規定のフォーマット画面を表示する処理であり（「図３２」参照）、前記ユーザー（１）が、当該規定のフォーマット画面より、次回作概要データ（ｃ）を入力及び送信すると、記憶装置へと格納し、且つ、広告情報を明確に区分した形で前記ユーザー（２）の端末へと表示する処理である。（段落「００３９」/「００５０」〜「００５４」にて詳細に記載）

又、請求項１１に記載のシステムは、観賞者と、コンテンツ提供者のが、コンテンツの売買及び契約等のタイミングを調整する為の契約タイミング調整処理であり、前記契約タイミング調整処理は、タイミング調整を行う為のデータ（Ｊ−１/購入者側の希望タイミング等のデータ）（Ｊ−２/提供側のざっくりとしたコンテンツ制作希望時間等）（Ｊ−３/購入側の自動入札を行う設定データ）（Ｊ−４/確定した完成予定日時）の収集を行う処理を有している。又、前記データ（Ｊ−１）は、前記ユーザー（２）より付与される参考データであり、コンテンツの自動入札者以外の鑑賞者又は、購入者側の希望タイミング等のデータである。又、前記データ（Ｊ−２）は、前記ユーザー（１）より付与される参考データであり、制作合意前であって購入が決まる前の、制作者のざっくりとしたコンテンツ制作希望時間や制作日数時間等の予定データである。又、前記（Ｊ−３）は、前記ユーザー（２）より付与されるデータであって、前記ユーザー（２）の自動入札を行う設定データ＜自動入札回数、最大期限、上限金額等＞である。又、前記（Ｊ−４）は、前記ユーザー（１）より付与されるデータであって、制作合意後の購入が決まったデータ＜完成日時/搬入可能日時データ/延長の有無＞の確定した完成予定日時である。そして、前記契約タイミングの調整処理は、収集されたデータの統計を算出し、各データを記憶装置に格納する処理と、各データ（Ｊ群）を各ユーザー端末へと表示する処理を有している。これは、前記データ（J−１）を統計データとして算出し、前記ユーザー（１）の端末に表示する処理であり、且つ、参考データとして、前記データ（J−２）を過去作品の属性データとして付与し、前記ユーザー（２）にて確認が行えるようにその端末に表示する処理とである。（尚、データJ − 1及び、データJ−２
は参考データであり、必ずしも、データの収集及び各端末への表示を行わなければならないものではなく、データの有無は、いずれでもよい）。又、契約タイミング調整処理は、売買及び契約等のタイミングの確認及び調整をスムーズに行う為の画面構成として、２パターンのデータ（Ｊ−２/Ｊ−４）を表示するコンテンツスケジュール画面を表示する処理を有しており、これは、前記ユーザー（２）がその端末より確認を行う画面であって、購入前のざっくりした完成予定日のデータ（Ｊ−２）を表示したスケジュールパターンと、購入決定後の確実な完成日の日程であるデータ（Ｊ−４）を表示した画面である。又、契約タイミング調整処理は、前記ユーザー（２）が、前記データ（J−３）を入力設定してコンテンツの自動購入を行える処理も有している。（段落「００３９」/「００５８」〜「００６１」にて詳細に記載）

本システムは、「図４４」の様に、既存のコンテンツ市場の流れを真逆にするものである。その為、鑑賞者と制作者の、相互間における商品売買のデータの送受信の流れは、既存システムのデータ送受信の流れと真逆のフローとなる。又、「図１２」に記載の「２次的欲求」とは、現在、鑑賞している作品を求める欲求ではなく、次回作（連続作品）を求める欲求である。本システムは、２次的欲求を対象としたコンテンツ（以降より、既存コンテンツと区別して、先行コンテンツと述べる）商品を販売するオンラインストアである。

＜１次欲求＞…現在確認している目の前の商品そのものを求める欲求。
＜２次欲求＞…現在確認している目の前の商品の次回作を求める欲求。

尚、２次的要求を満たす商品というのは、既に、販売されている商品では無く、未だ、制作されていない商品であり、商品を探してもどこにも存在しないというものである。その為、次の作品を購入すると言っても、購入して当日or１日等の短期間で手に入るものではなく（※未だ、存在していない為）、購入を行ってから、商品を手に入れるまでには、制作を行う迄の制作時間も、その売買における工程に含んでいるというものである。これは、制作者の制作時間の捻出を解決する目的に在るためである。

本発明はコンテンツ制作・販売・課金処理の流れに特長を持ったシステムであり、従来のステップと比較して説明を述べる。従来のコンテンツ制作販売者のステップは概ね次の様なものであった。

『既存コンテンツ販売のステップ』
ステップ（１）制作会社又は、制作決定者の販売予測「この作品は売れるだろう」という判断がされる。→ステップ（２）売れるという予測が立てられ、コンテンツの制作を開始する。→ステップ（３）コンテンツ（画像・動画・音楽・文書・ゲーム等）が完成する→ステップ（４）予約販売や、広告宣伝、制作数の調整等を行う→ステップ（５）販売結果が分かる≪販売予測通り販売できたor販売予測通り販売できなかった≫。以上の様な流れであった。

しかし本発明では次のステップを踏む。まず制作者側の流れを説明する。
『本システムのステップ：制作者フロー』
ステップ（１）制作者は自身で設定した「図２」の“続きを見たいボタン”が押されているか、確認することができる。“続きを見たい”ボタンとは、データ（b）であり本発明が提供する機能である。制作者は前記ボタンを設置すると、前記機能（ボタン）提供サイトで、前記ボタンを押したユーザー人数を確認することができる。前記機能は、今まで見過ごされていた鑑賞者のニーズを発見する機能である。又、”続きを見たい“という言葉は、同じ意味であれば、この言葉に限られるものではない。→次に、ステップ（２）では、制作者は”続きを見たい“ボタンを押した鑑賞者に、「図５」のデータ（ｃ）である制作計画（制作予告）を発信することができる。※この時点では制作者はまだ作品の制作は出来ていない状態である。→ステップ（３）では、制作予告を見た鑑賞者が「作品を購入する」というデータを送信する。そして、前記制作者はその内容を受け取り、コンテンツの購入人数を確認する事ができる。又、購入人数が事前に分かれば、前記制作者は制作を決行するかどうかの判断ができる。例えば、制作者は次の様な判断ができる「購入者が１０００人いるな。制作を行おう。バイトせずに制作できるな。（３ヶ月後作品完成）」or「購入者が１０人しかいないな。制作はやめよう。バイトをしよう（２年後作品完成）」となる。次にステップ（４）では、制作者は無事作品を完成させ搬入し、自身の口座に、コンテンツ売上金額が振り込まれたのを確認する。

『本システムのステップ：鑑賞者フロー』
次に、鑑賞者であるステップを説明する。ステップ（１）鑑賞者は、お気に入りの制作者の次の作品を見たいけれど、鑑賞できないでいる状態である。例えば、「この作品の続きをみたいけれど、全然制作してくれないな」と思っている状態である。→次にステップ（２）では、続きを制作して欲しいと思う、お気に入り制作者の”続きを見たい“ボタンを前記鑑賞者は押すことができる。（意思表示を行う）→ステップ（３）データ（ｃ）である制作予定表を前記鑑賞者は受け取ることができる。次に、料金と内容、制作期日を了承して購入するかしないかを判断することができる。→ステップ（４）購入する場合は購入ボタンを押すことができる。この段階ではまだ仮購入であり、先行販売締切日に（制作者の制作合否の意思を待ち）本購入が決まる。本購入が決まればコンテンツ料金が課金される。※又、この段階では鑑賞者に課金を行うが、金額はサイト運営側でプールしたままであり、コンテンツ制作者には振り込まれない。次にステップ（５）では、鑑賞者は、作品完成日に作品を無事受け取り、レビュー（評価）を行う事ができる。もし、前記鑑賞者が作品を受け取る事が出来なければ、課金された金額は前記鑑賞者にそのまま返金される。制作者が無事コンテンツを搬入すればこの時初めて、制作者に金額が振り込まれる。また、プールされた金額はサイト運営側が無断で使えない口座を設ける形か、第三者が介入するかを厳重に行うシステムを含める形にするか、又は、銀行等の機関に委託を行うか対処可能なものとする。※尚、サイト運営側の返金手数料の無駄は、プール期間の利子で相殺できるものとする。利子が余る場合はポイントなどで返金を自動処理により行えるものとする。又、何らかの問題が発生する場合の処置も含むものとする。以上が本発明の要約であり、次に、コンピュータでの処理を述べる。

本発明は作品提供者であるユーザ（１）と、作品観賞者であるユーザ（２）が作品を売買する為の課金システムであって、前記ユーザ（１）が端末（Ａ）より、情報データ（a）を送信して、且つ、記憶装置に格納するステップと、次に前記ユーザ（２）が端末（Ｂ）より、データ（b）を送信し、記憶装置に格納するステップと、次に前記ユーザ（１）が端末（Ａ）より、情報データ（c）を送信し、記憶装置に格納するステップと、次に前記ユーザ（２）が端末（Ｂ）より、データ（d）を送信し、記憶装置に格納するステップと、且つ、コンピュータが複数からなる前記ユーザ（２）の前記データ（d）の合計値を算出し、端末（Ａ）に表示させるステップと、次に前記ユーザ（１）がデータ（e）を送信し、前記データ（e）が合意であればデータ（f）を決済システムに送信し、前記ユーザ（２）に課金される決済ステップと、前記データ（e）が拒否であれば、データ（f）は決済システムには送信されず課金処理が行われないステップと、前記ユーザ（２）に対し課金された金額をプールしておく決済システムと、次に、作品が完成し前記ユーザ（１）が端末（Ａ）と記憶装置を用いて完成作品を搬入し、又、その処理をメール等により前記ユーザ（２）に自動的に通知するシステムと、前記ユーザ（２）が、作品を受領しその内容を確認すると、作品を受け取った信号であるデータ（g）が決済システムに送信されるステップと、データ（g）を受信した決済システムが、前記ユーザ（１）にプールしていた金額を振込むステップと、又、データ（ｇ）が受け取れなかった場合の前記ユーザ（２）へ金額が返金されるステップとを有している。以上により、本課題を解決するものとする。

以上が、本ビジネスモデルの概要である。以下より、既存ビジネスモデルとの相違を述べる。

『１．予約販売システムとの比較』
予約販売システムは「制作者が広告を表示して顧客を集う」ものであり、本システムは、『鑑賞者が作家に続きを見たいと依頼する』ので相違する。本システムは鑑賞者側から制作者へ、コンテンツ制作依頼を行うオーダーシステムであり、その過程で作家と鑑賞者が制作する条件を調整し合うシステムである。

『２.オーダーシステムとの比較』
何らかの商品を制作する製造業という市場モデルは、顧客から依頼を受けて作成するものが殆どである。そして、広告クリエイティブに於いても、建築や、彫刻、絵画や芸術作品に於いても、オーダーを受けて制作を行う方法は存在しており、至極当然の様に行われている。例えば、絵画の販売に於いても制作依頼があって行われるのは通常の方法である。そして、既存にも、娯楽コンテンツをオーダーして販売するものとして考えられるものは、例えば、子供等へ送るプレゼント等に記念としての絵本/小説/グッツ等を独自に作成してもらう依頼という方法も考えられる。しかしながら、これらは、本システムとは異なっている。既存のオーダーシステムとは、概ね、依頼側には特定の欲しい商品のイメージがあり、その要求を制作者が作成するというものであり下請け的な作業となっていた。既存のオーダー販売とは、仮に、芸術作品であっても、依頼側には概ね、明確な制作（デザイン・建築・衣類等）を行ってほしい欲求があり、依頼を行う者としての認識であった。又、これらは、既成の製品では間に合わない為、独自のオリジナル商品を制作してもらう時に発生する等の販売モデルとして存在していた。そして、従来のオーダー販売モデルの認識というのは、依頼者の“発想”を超えるレベルの創造を扱う商品を販売するモデルでは無く、顧客が想像もしていない創作レベルの商品というのは、通常、商品が開発されて販売するのが当然であり、顧客を驚かせる娯楽商品や、研究開発等の商品というのは、顧客が求めてもいなかったもの、思ってもいなかったもの、想像もしていなかったものが求められ顧客の考えを裏切らないといけない制作である。そして、既存のオーダー販売では、これらの商品を提供できる販売モデルでは無かったとする。又、そもそも、依頼者の発想を越えてしまえば、依頼自体が出来ず、依頼を行う行為が成り立たないものである。そしてこれらの商品（顧客が想像もしていない商品）を既存のオーダー販売システムでは扱えるものではなく、又、作家が、作家の裁量で、クリエイティブな創作を行える環境というのは、既存のオーダーシステムで解決できるものでは無かった。又、それを解決するのは長らくの難問であったとする。顧客から「先行して次回作を購入する」という販売モデルは存在せず、既存では、ただただ、顧客は受け身でコンテンツを消費するしかないのが現状であり、そして、仮に、「続きが見たい」と思ったとしても、制作打ち切りを行われて作品を見れなくなるというのは、昔から存在しているものであり、その認識が当然であった。又、その問題は鑑賞者にとっては、本気で解決するほどの深刻な問題では無いと考えられ、もし、鑑賞したいのであれば、観賞したいと言えば良いだけの話であり、制作側は、そのニーズを拾い、制作に反映すれば良いだけであった。その為、本発明は、既存のオーダーシステムでは無く、既存の価値観の範疇を越えるものである。又、本システムは、次回作の購入を行うシステムである。本システムは、オーダーの様な、投資の様な、オークションの様なモデルであり、既存には無いシステムである。又、既存のオーダーシステムはクリエイティブに於いて顧客主導のモデルあったとする。そして、本システムは、依頼が行われて制作を行うのだが、しかしながら、クリエイティブ（制作作業）に於いては、制作側の全面的な、主導にて制作を行うものである。

『外食市場』
本システムは、その性質的に飲食店モデルとも類似する。しかしながら、コンテンツ販売市場と、外食市場モデルとは明らかに相違があり、異なるものである。

『３．投資システムとの比較』
本システムは資金運用を行うのではなく、販売する商品そのものを購入するので異なる。

『４．アマゾン等のオンラインショップとの比較』
本システムでは、顧客が「続きが見たいボタン」を押すと、続きが見たい作品（先行コンテンツ）を「図２９」の様な形で、商品が並ぶカート画面に入れる事ができる。これは、アマゾン等の商品を購入するカート画面と類似しているが、本システムの取り扱う商品は、「現段階では作者自身も作る事を予定していないコンテンツ」であり、「未だ作ることも予定していない、現実には存在していない作品群」の、商品一覧カート画面である。（※アマゾン等オンラインストアに商品として存在してあるのは、予告販売の商品と、通常販売の商品である。）本発明がカートでストックしているコンテンツは、「図２９」の様に先行販売の商品であり、そして、ショップが展開可能なフィールドは、ＩＴ上の概ね全コンテンツが対象である。
＜先行販売＞＝制作者が制作の意図すら行ってない状態の商品
＜予約販売＞＝制作者が制作の意図を持っており予約商品として発表している商品
＜通常販売＞＝今すぐにでも購入できる商品

『５．アンケートシステム及び、マーケティングシステムとの比較』
本システムでは、アンケートを行うシステムではなく、あくまでも制作者側が待ちの姿勢にて、鑑賞者から依頼を受ける商品の販売ストアであり、その交渉過程の中で、顧客のアンケート要素的な意見を聞く要素も含むというだけのシステムである。本システムは依頼を受け付けるものであり、アンケートを行っている訳でも、マーケティングを行っているものではなく概念自体が相違している。

『６．コミュニティーシステム（ＳＮＳ）との比較』
本システムは、機能に於いて、SNSと類似するのだが、SNSにて、商品を販売するのは非常に難しく（又販売機能を禁止しているシステムもある）SNS機能及びそのＦＡＮ機能と、オンラインストアの機能の組み合わせで販売促進を行い商品を販売しても効果が上げられないとされている。

『７．ＦＡＮ機能を取り入れたコンテンツ販売システムとの比較』
コンテンツに対しＦＡＮ機能を付与して販売促進を行い効果を出す方法は、人に対しＦＡＮ機能を付与するよりも押される確率は難しくなる。又、コンテンツ制作者が販売促進を行う為に、ＦＡＮボタンを押されないと予約販売を行えないというのは、購入される確率を極端に下げてしまう。この場合、ＦＡＮ機能を設置する目的は、販売促進の為の情報配信にあると考えられる。例えば、顧客が情報を受け取り損ねない様に予約販売の情報をメールで通知するなどである。これは、本機能と類似している様に見えるが、しかしながら相違点は、その情報が広告宣伝情報という性質に於いて異なっているものとする。広告宣伝としての情報を観賞者に送信するのは難しく、一般的には、その対策として公開しないプレミアム情報を用い、会員登録を促す方法が取られる。これは無料でプレミアム情報を提供する代わりに、顧客に、予約販売等の情報を送信する方法である。しかし、この場合も、厳密には顧客が欲しいのは、プレミアム情報であり、必ずしも予約情報を望んで、FAN登録を行っているとは言い難いと考えられる。その為、大抵の場合、顧客はプレミアム情報と宣伝情報が送られてくる事の損得を天秤にかけ、メリットが高いならＦＡＮボタンを押すというケースである。以上により「コミュニティーシステムのＦＡＮ機能」でも、「コンテンツ販売のＦＡＮ機能」でも、その組み合わせである、「コミュニティ」＆「オンラインショップ」も、販売促進へは限界があり販売効果を上げれていない現状にある。そして、本システムはSNSではなく、完全なオンラインストアであり送信する情報は顧客の指定に基づいた情報（フォーマットにより規定された情報）である。

以上は、既存ビジネスモデルとの比較である。以下より、既存にある「ＦＡＮ機能」との比較を述べる。「ＦＡＮ機能」には様々な種類があり、「FAN」という要素は類似していても、そのデータの送受信に於いて全く異なる機能である。その為、FAN機能を一括りにはできず周知にある技術を順に上げ、その違いを述べる。（「図４７」参照）

『ＦＡＮ機能Ａ：SNSによるＦＡＮ機能』
SNSによるＦＡＮ機能は、対象が人に掛り（※ユーザーID）、人の繋がりを広げていく情報を表示する機能である。例えば、「私はこの人のＦＡＮです」と言う意思表示を示し、人と人の輪がリンクされ繋がっていくのを促している。この場合、一連のデータの送受信は以下の通りである。

１．（Ａ）さんが（Ｂ）さんのＦＡＮになる（ユーザーID：Aの記憶情報にユーザーID：Bを格納する）→２．（Ａ）さんのＦＡＮリストに（Ｂ）さんが入る（格納したユーザーID：Bを、Aさんの画面に公開する）。又、今後、（Ａ）さんには（Ｂ）さんの不特定多数の更新情報（記事等の件名）が送信されるようになる→３．（Ａ）さんのFANリストを一般or特定のグル―プに公開（共有）する→４．（Ａ）さんのFANリストを見た（Ｃ）さんが、そのリストの中から気になった（Ｂ）さんをＦＡＮとして登録する（ユーザーID：Cの記憶情報に、ユーザーID：Bを格納する）→（１．に戻る）というフローのデータ送受信である。

『ＦＡＮ機能Ｂ：お気に入り情報を拡散させるＦＡＮ機能』
公開ブックマークや、その他、評価ボタン等は、情報を拡散させる目的の「FAN要素」を含むボタンである。この場合の一連の情報の送受信は、以下の通りである。

１．（Ａ）さんが、特定の記事（情報）をブックマーク（あるいは評価）する。（ユーザーID：Aの記憶情報に、ブログ記事を特定する＜タイトル/若干の記事内容/URL等＞が格納される）→２．（Ａ）さんがFANを押して格納した情報が、任意の媒体（機能提供運営サイトの画面、あるいはAさんと、SNSにより繋がっているユーザーID：の端末画面）に公開表示（共有）される→３．次に、（A）さんの、お気に入り情報を見た（Ｂ）さんは、同じ様に情報を気に入りブックマークすると、Bさんの記憶情報に、ブログ記事を特定する＜タイトル/若干の記事内容/URL等＞が格納される。→４．さらに任意の媒体（サイト運営画面又は、BさんとSNSで繋がったユーザー端末画面）に公開表示（共有）される。→５．それを見た（Ｃ）さんも、情報を気に入りブックマークすると、さらに任意の媒体（サイト運営画面又は、CさんとSNSで繋がったユーザー画面）に公開表示される」→（限りなく情報が拡散される）というフローである。又、情報の共有も収集も拡散もしない非公開ブックマークは情報を単にクリップ（整理）しているものであり機能として相違する。

『ＦＡＮ機能C：ＲＳＳ機能』
FAN機能Cでは、お気に入りブログの最新データ（更新記事）を配信し、又は、情報収集を行う目的の機能である。又、FAN機能Bが、情報の拡散を行わず、ユーザー同士のつながりが無いパターンと、同等の機能であるとする。この場合のデータの送受信は、以下の通りである。

１．Aさんが、Bさんのブログを登録する（Aさんの記憶情報に、BさんのブログURLが格納される）
→２．又、登録したブログURLの、＜記事タイトル/５０文字程度の記事/その他の評価情報等＞が格納されたコードを格納し、更新が在ると、自動配信、又は、検索エンジンによる収集等で、Aさんはリストより、Bさんのブログ更新記事を確認することができる。

『ＦＡＮ機能D：コンテンツに掛るＦＡＮボタン』
FAN機能Dでは、予約情報の表示はＦＡＮボタンを押されずとも端末上に表示を行う為、この場合FANボタンは、宣伝広告の為の情報の配信の為に存在する。鑑賞者は、ＦＡＮボタンを押すと、わざわざサイトに訪問しなくても予約情報を送ってもらえる。又、この機能は、「会員登録機能」とも同等であると考えられる。そしてこの場合の一連のデータの送受信は、以下の通りである。

１．Ａさんは、コンテンツ（Ａ）の何らかの情報を入手するためにＦＡＮボタンを押す（コンテンツIDと、ユーザーIDが、運営システムに格納される）→２．コンテンツ（Ａ）に関する不特定多数の情報が、メール等により送られる（又、不特定多数の中にコンテンツAの予約情報が含まれる）」

又、ＦＡＮ機能Ｄと本システムとの違いは「図４８−１」と「図４８−２」の様なものであり、「図４８−２」では、既存、FANボタンの発信というのは、「Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ」の情報が全て一緒であり、違いが無い状態である。これは「Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ」は、＝「Ｚ」という一つの情報であるという認識をしている。つまり、「Ａ」も、「Ｂ」も、「Ｃ」も、＝「Ｚ」という認識をしている。これは例えば、「果物」に対し、「果物」という認識しかしていない状態であるといえる。本発明は、「Ａ」という情報は「Ａ」であり、「Ｂ」という情報は「Ｂ」であり、「Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ」は、「各Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ」の情報であり、違いがあるという事を発見し、その違いを明確化し、効果を出すものであると言える。これは例えば、「果物」に対し、「リンゴ、オレンジ、メロン、イチゴ」と認識する状態である。そして、各オレンジ、リンゴ、メロンは、含まれる成分が異なり、この違いを発見し区別する事は、その固体を認識するだけに足りうる必要と効果があるあらだと言える。

『本システムのデータｂ』
１．Aさんが、コンテンツAの次回作を要求する（Aさんの記憶情報に、コンテンツA / ID:0001等が格納される）→２．又、コンテンツAの制作者Bへと、＜コンテンツA/ID:0001 / 次回作依頼＞というデータが送信される。→３．次回作依頼データを確認した制作者Bは、その情報を参考に、コンテンツAの次回制作計画＜コンテンツA/ID:0001/次回作予告データ＞を入力し送信する。→４．Aさんが、コンテンツAの制作計画書を確認する。というフローである。

＜ＦＡＮ機能Ａ＞と比較すると、本システムは、ユーザー同士の繋がりを広げる機能ではなく、商品を購入する機能である。ユーザー情報は公開されず制作者と鑑賞者の繋がりは無いシステムであり、目的と機能において相違しており、FAN機能Aは、本発明が課題とする解決に効果がない。＜ＦＡＮ機能Ｂ＞と比較すると、本システムは、情報を拡散する機能ではなく、鑑賞者がプライベートに商品を購入するシステムである。その為、目的と機能において相違しており、本発明が課題とする解決に効果がない。
＜ＦＡＮ機能Ｃ＞と比較すると、FAN機能Cは、FAN機能Bの情報を拡散させないパターンであるが、
データの送受信において、ブログの更新（タイトルや記事等情報）を自動で収集する機能であり、本システムは、動画、音楽、書籍、画像、ゲーム等の、コンテンツ制作依頼を送信するものであり、目的と機能において相違しており、本発明が課題とする解決に効果がない。＜FAN機能D＞と比較すると、FAN機能Dは、情報を指定しておらず、返信する内容も限定していない情報機能である。本システムは、「図４８」の様に、特定の情報を顧客が指定して、特定の情報を提供者が返信するものである。又、指定のない情報は広告宣伝情報として、指定している情報は広告宣伝ではない情報として区別している。又、本システムは顧客から依頼を行うシステムであり、目的と機能において相違しており、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を返信する詳細な処理である。６つ目は、課金システムに於いて、制作者と鑑賞者と、本システム運営側の、各者、条件のバランスの調整における問題である。７つ目は、契約タイミングの調整問題である。

まず、「図１３」と「図１４」は、記憶装置１０１をより詳細に記したシステムの構成図である。そしてまず「図１３」の説明を述べる。本システムの構成は、制作者端末Ａと鑑賞者端末Ｂとがインターネットで繋がっており、一連の受注手続きの処理を行う、受注処理サーバ６０１と、データ（Ａ−１）を格納する過去作品著作データベース１０１と、又、任意サイト過去作品サーバ（本システム以外）と、過去作品（コンテンツそのもの）であるデータ（Ａ−２）を格納する過去作品データベース１０２と、データ（Ｂ−１）（Ｂ−２）（Ｂ−３）（Ｂ−４）のデータＢ群を格納する依頼情報データベース２０１と、次回著作情報であるデータ（ｃ）を格納する次回著作情報データベース２０２と、完成作品（ｈ）を格納する完成作品データベース３０１と、積立金を計算し積立額データ（Ｉ）を記憶する積立金データベースサーバ４０１と、契約タイミングを調整するための情報データ（Ｊ）を格納する時間調整データベースサーバ５０１と、その他ユーザー情報管理サーバとで構成されている。

次に、受注サーバ６０１の機能構成として、「図１４」の説明を述べる。受注処理サーバ６０１は、過去著作登録処理（１２）と、制作者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内にて金額を記憶し、商品受け渡し時に制作者口座に振り込む方法である。又、積立型の若干の問題としては、２カ月後、３ヶ月後、半年後と言う様に、制作期間が長期化するほど、鑑賞者及び制作者に於いて負担となる。例えば、鑑賞者としては、購入した事を忘れてしまい、後になって支払い請求が来るリスクであり、制作者としては、期限内に完成作品を搬入しても売り上げを回収できないリスクである。（※プール型と積立型の違いは、鑑賞者の口座からの引き落ちるタイミングが相違する点である。プール型は本システムのプール口座に一旦保管されるが、積立型は本システムのプール口座を経由しない形である）この場合の解決法として、積立型とプール型の併用である混合型を有するものとする。（「図３８」参照）混合型とは、一定以上迄は、積立金での管理を行うが、一定以上を越えると、プール型に切り替わる方式である。一定のラインとは、例えば、日数であったり、金額であったり、どちらでも構わないものとする。又、コンテンツの制作日数によりタイプ分けを行い、タイプによって、積立型か、プール型か、混合型かを設定し、併用する事も可能である（「図３８下図」参照）。尚、できるだけ短期制作型を行えるようにするものとする。又、「続きを見たい」ボタンにはチップ設定を行うことも可能である。先行コンテンツ販売では、観賞者からの依頼で始まり、制作者は基本的に制作することを予定してはおらず、「続きを見たい」と言われて初めて、制作計画表を立て発表を行う為である。これは、鑑賞者側にメリットが高すぎる場合は、チップを加算し（コンテンツ本体額の５％程度）、鑑賞者側にメリットがない場合は、チップを無しにする様な、両者の条件的な調整機能である。

又、以上の、データh 〜 mまでの流れを纏めると、
『積立型のフロー』（※５００円は仮数字）
１．データｆ受信＜作品ＩＤ：０００１/タイプＡ型/積立型/５００円＞次に、
２．データｈ受信＜搬入完了＞次に、
３．データｍ送信＜鑑賞者ＩＤ：０１より課金/制作者ユーザーＩＤ:０１口座へ振込/５
００円＞
『プール型フロー』
１．データｆ受信＜作品ＩＤ：０００２/タイプＢ型/プール型/５００円＞次に、
２．送信＜鑑賞者ＩＤ：０１より課金/プール口座振込/５００円/制作者ＩＤ：０２/売上保管/引落予定日.（第１）○年○月○日（第２）○年○月○日（第３）○年○月○日＞次に、
３．データｈ受信＜搬入完了＞次に、
４．データｍ送信＜プール口座より引落/制作者ユーザーＩＤ：０２口座へ振込/５００円＞
『混合型』
１．データｆ受信
＜作品ＩＤ：０００３/タイプＣ型/混合型/５００円＞
＜作品ＩＤ：０００４/タイプＣ型/混合型/５００円＞
＜作品ＩＤ：０００５/タイプＣ型/混合型/５００円＞
＜作品ＩＤ：０００６/タイプＣ型/混合型/５００円＞
＜作品ＩＤ：０００７/タイプＣ型/混合型/５００円＞次に、
２．日数（１カ月等）or一定金額を越える（条件は設定可能。※纏めて振込）
送信＜鑑賞者ＩＤ：０２より課金/プール口座へ振込/１５００円/
内、作品ＩＤ：０００３/制作者ユーザーＩＤ：０３/売上保管/引落予定日
内、作品ＩＤ：０００４/制作者ユーザーＩＤ：０４/売上保管/引落予定日
内、作品ＩＤ：０００５/制作者ユーザーＩＤ：０５/売上保管/引落予定日＞次に、
（※又、混合型は、プール口座へ引き落ちる条件は設定変更・追加できる。例えば、コンテンツ個々にプール口座へ引き落ちる設定を行っても構わないし、鑑賞者ユーザー積立額に対して条件を設定する事も可能。）
３．データｈ受信＜搬入完了＞次に、
４．データｍ送信
＜プール口座より引落/制作者ユーザーＩＤ：０３口座へ振込/５００円＞
＜プール口座より引落/制作者ユーザーＩＤ：０４口座へ振込/５００円＞
＜プール口座より引落/制作者ユーザーＩＤ：０５口座へ振込/５００円＞）である。

そして次に、７つ目の契約タイミングの調整の問題について述べる。契約タイミング問題とは、例えば、コンテンツ制作には短期のものから長期を有するもの迄様々ある。そして、例えば「続きを見たい」ボタンを押されてから、一定数の人数が確保できるまで、仮に３年掛ったとする。すると、先の人は、最初に「続きを見たいボタン」を押してから、３年待って制作計画書を受け取ることになり、又、タイミング良く制作計画書を受け取らなければならなくなる。又、３年後にタイミング良く購入できたとしても、さらに１年後に作品を搬入してしまう、という事もありえてくる。又、鑑賞者は購入した事を忘れてはならないという課題もある。先行販売の特長としてこの様な性質を持っており、この問題解決として本システムは、時間調整ＤＢサーバ５０１を設置するものである。

契約タイミングの調整方法を大きく分けると「心理面でのアプローチ」と「システム面でのアプローチ」での２種類のアプローチから行う。心理的アプローチでは、主に制作希望タイミングを各自把握できるよう認識を容易にする等、又、コンテンツの種類により制作期間の相場を定める等、コンテンツの購入を忘れない様に促す等、完成するのに長期の時間が掛るものは、なるべく１つの作品を数回に区切り少量で出していく等である。次に、システム的アプローチでは、ダウンロード期間を長くする等、又開始期間や完了日を緩やかに定める事ができる等である。

そして、「図３９」は、鑑賞者と制作者の契約タイミング調整データである。鑑賞者から収集するデータを（Ｊ−１）とし、制作者から収集するデータを（Ｊ−２）とする。又、観賞者より設定される自動入札におけるデータを（J−３）とし、又、データ（４１）（４２）は、事前に既定の値等を設定し、調整を計る為のデータである。そして、「図３９」の様な形で、契約タイミングを幾つかのカテゴリに分解し、各パターン化する。そして区分けされたパターンに、ラベルを設ける。又、「制作タイミング」や「確認タイミング」等は、コンピュータにより、ユーザー行動を分析し確率を出す方法と、ユーザーからの自己申告によるものとどちらでも良い。そして、利用者の任意の判断である程度の時間的なタイミングが合う様に時間帯を計測し、鑑賞者と制作者の時間のリズムを調整する判断の補佐を行う。例えば、制作者の制作の頻度の情報や、鑑賞者のＷＥＢを訪問している頻度の情報（※鑑賞者のＩＤは表示しない）や、ざっくりと、「１カ月後や、２カ月後に訪問します」というような情報等である。

次に、「図４０」は、鑑賞者と制作者の契約タイミング調整データ及び、制作者であるユーザーの管理画面、及び、コンテンツスケジュール画面である。上図の左側のデータ表は、制作者の希望制作タイミングデータ（Ｊ−２）である。これは、ざっくりとした制作者の制作情報である。又、例えばこれは、「コンテンツA」という作品を制作するには、１カ月掛るという制作者の制作に要する時間情報でも構わない。制作者は、過去作品の次回作を制作する為に、必要な制作時間の情報を事前に、各コンテンツに対し付与する事が可能である。例えば、コンテンツAという過去作品があれば、事前に、その作品に対し、制作するに要する日数の予想情報を付与しておくことができる。次に、上図の右側のデータ表は、鑑賞者の自動入札設定である。例えば、制作者の希望制作タイミングが、＜１カ月に一回の割合で制作＞とか、＜制作を行うのに２カ月日数が掛る＞という情報が分かれば、鑑賞者は、作品Aであれば、例えば、＜３回まで自動的に入札する＞と言う設定が可能である。これを、自動入札データ（Ｊ−３）とする。そして、画面２１は、制作者画面であり、制作者は次回作依頼者（購入予備軍）の内、自動入札鑑賞者の人数やその内省の内訳が確認できる。又、画面２２は、以上の各契約タイミングデータを、グラフにした分析画面である。（各データ事にこの分析画面があるものとする。）又、画面２３は、鑑賞者カート画面のコンテンツスケジュール表であり、入札前コンテンツ群である。入札前のコンテンツスケジュールは、制作決定前のざっくりとした、制作者側が事前に付与した情報（データＪ−２）である。そして画面２４は、入札後コンテンツ群のスケジュール表である。入札後のコンテンツスケジュールは、確実な制作完成日（データＪ−４）である。また、「図４０」の自動ダウンロード装置とは、コンテンツを保管する記憶装置に自動でダウンロードを行う装置である。又、以上の自動入札設定のフローを纏めたものが「図４２」である。図では、まず画面３０にて、「続きが見たい」ボタンを押す。そして画面３１は、自動入札設定画面であり、制作者のざっくりとした制作時間等の情報が記載された画面である。又、画面３２は、制作者のざっくりとした希望タイミング等の情報が無い画面である。そして鑑賞者は、この画面にて＜自動入札回数、と最大期限、上限金額＞を設定する事ができる。自動入札回数とは、同一の著者の同一の作品に於いて、自動で入札する回数を設定するものである。又、「最大期限」というのは、自動入札設定の効力がある期間である。又、上限金額とは、自動にて購入を行う上限金額である。又、自動入札設定は、いつでも解除可能である。次に、画面３３は、制作者の、依頼情報確認画面（画面１７）である。この画面では自動入札者の内訳情報を統計的に確認することができる。又、自動入札者以外の依頼者の希望タイミングなど、参考までに、その他の情報を統計データ等により確認することができる。以上が、契約タイミング問題の対策である。又、「図４１」は、制作日数等の相場表である。又、制作日数以外にも、参考までに金額などの平均的な相場を表示しておくことも可能である。

次に、「図５３」は、以上の一連のステップと機能を纏めた図である。又、本システムの要件定義は、「制作者の未だ制作の予定のしていないコンテンツを、鑑賞者から先に制作者へ、“続きを見たい”と言って次回作の依頼を行うシステムである」この定義を、システム上に実相していくと必然的に行わざる負えない設定として以下の事柄があります。例えば、ボタンの形も、「続きが見たい」だけではなく、「続き依頼」「次回依頼」「つづき」「ＮＥＸＴ：Contents」「ＮＥＸＴ：Ｃ」というパターンもあり最適なネーミングを考えて行くことになります。又、コンテンツアイコン表示画面に対しても、制作が決まったコンテンツと決まっていないコンテンツの２つのパターンが在るため、その違いを認識するための画面は必然的に作られるものとします。又、ＩＤは、システム実相上識別番号として必ず付与せざる負えないデータである為、付与するものとしております（「図５４」参照）。以上により本発明は構成されるものとする。

ユーザ（１）…コンテンツ制作者、又は、コンテンツ提供者
ユーザ（２）…コンテンツ鑑賞者又は購入者
端末（Ａ） …ユーザ１の端末
端末（Ｂ） …ユーザ２の端末
データ（a）…
コンテンツ提供者（ユーザー１）の過去に創られた作品（完成作品）のデータ＜作品名/作家名/作品の属性データ/制作者の経歴及び情報/作品ＩＤ/等＞であり去作品メニューリストの様な形で管理される
データ（b）…
過去作品データaを参考にしてお気に入りの作家に次回作を依頼する信号であり、過去作品データaよりひも付いた情報（作品ＩＤ等）を受けて、オーダー的要素を送信する信号であり、且つ、お気に入り鑑賞者（ＦＡＮ・リピータ）としての信号も含む＜作品ID：０００１/作品ID：０００１の次回作依頼＞という情報である。又、「図２」は、“続きを見たい”というボタンであり、これを押すことによりデータｂは送信される。又、「図２」は、他サイトへ広く配布可能な形態であるボタンとして表している。
データ（c）…
データｂより引きついた作品ＩＤ及び、（先行販売が行われる）募集期間、作品ID：0001次回作概要・形態（例、作画/枚数、書籍/頁数、［作品名］○○の続き…）、金額、完成予定日（○月○日、所要日数○カ月）制作実行可能人数（○人以上であれば制作実行）データ（d） …ユーザ（２）のコンテンツを購入するかどうかの意思決定（購入する）
データ（e） …ユーザ（１）の制作実行の合意or拒否の意思決定（制作するor制作しない）
データ（f） …ユーザ（２）の支払いに必要な情報（クレジットカード番号、氏名等）及び決済信号
（鑑賞者より引き落とし信号）
データ（g） …ユーザ（２）による受け取りの確認データ信号
データ（h） …完成されたコンテンツ
（デジタルコンテンツの場合はコンテンツ属性データ及びコンテンツその物であるデータであり、デジタル以外は完成の作品属性データであり、又はデジタルデータであっても記憶媒体等にて提供する場合は完成作品の属性データとする）
データ（ｍ）…制作者への振込処理に伴うデータ等
１０１…記憶装置（ＤＢサーバ）
＿＿
データＡ’…コンテンツサムネイル
データＢ’…「続きが見たい」登録解除ボタン。
データＣ’… コンテンツ題名、受付期間、制作者名等、コンテンツ内容の要約情報
（データＤ’の要約）
データＤ’…コンテンツの詳細内容（計画書）、題名、内容（あらすじ）、先行販売受付期間、完成期間、金額、コンテンツ形態（音楽、動画、画像…）制作実行予定人数（制作が実行される購入人数の目安）延長有無と延長の対応方法、他
≪データ（c）と同一≫
■データ関係
データ（Ａ−１）…
データaの内、著作情報部分 ＜過去に創られた作品情報であり：作品ＩＤ、作者名、作品名、金額、コンテンツ形態（書籍・音楽・動画…等）、その他、過去作品を特定する為のあらゆる情報。又、補足項目として、ユーザ（１）の情報（経歴等）、制作者のその他の作品情報等＞これは、本システムの過去著作ＤＢ１０１へ格納されるデータであり、本システムの売買には必ず必要なデータである）
データ（Ａ−２）…
データaの内、コンテンツそのもの制作者が過去に創ったコンテンツであり、例えば、無料で公開されているものであれば、鑑賞者はそれを観賞する事で『続きを見たいボタン』を押しやすくなる。又、Ａ−１と、切り離されても、コンテンツを識別するための簡易著作情報＜作品名、作品情報、コンテンツＩＤ＞も含んでおり付与されている。これは、本システムの過去作品データベース１０２に格納されていても、他サイトの任意のデータベースに格納されていてもどちらでもよく、オンライン上に表示される形であれば良い。又、無料で公開されていても、されていなくてもどちらでも良い。鑑賞者が次回作を購入する為の参考コンテンツである。
データ（Ｂ―１）…
データｂの信号の内、簡易な次回作要求信号。（※尚、本システムは、鑑賞者から次回作の依頼を行う形のオーダー型販売システムである為、これをシステム上実行していくには、完成前商品と完成後商品を認識する事が必要であり、先行コンテンツ（本システムの取扱商品である）には必然的にIDは付与されていくものとする。過去作品の側に配布されている「続きを見たい」ボタンを押すと送信されるデータであり、最低限の簡易な過去著作情報を含んでいるデータ ＜例えば、作品ＩＤ/作品名/会社名著作名/等＞である。また、本システムの過去著作データベース１０１へ問い合わせて過去著作情報Ａ−１の有無を調べ、登録有無の値を返す。又、ボタンが無い場合は、直接「図２３」の形で、過去作品を特定するデータを手入力で入力し、本システムの過去著作データベースへ問い合わせする事も可能である。又、問い合わせしても過去作品情報（データＡ-1）が登録されていない場合は、鑑賞者から、（データＡ-1）を直接入力し、本システムへ登録を行い注文意思を送信することも可能である。
データ（Ｂ―２）…
データｂの信号の内、詳細情報を含んだ次回作要求信号「図２２」の画面１２、又は画面１３で、入力されるデータであり、「作品を特定するデータa＋続き依頼＋若干のコメント＋購入確率＋日時等」である。又は「作品を特定するデータa＋新規依頼＋続き依頼＋その他の商品の続きも見たい＋若干のコメント＋購入確率＋日時等」である。（※購入確率とは顧客が、どれぐらい続きが見たいかの指標を表すデータであり、例えば、星マーク等の５段階表示でも、購入予定パーセンテージ度でも良い。又、このステップは、ログイン後であれば、鑑賞者が本システム内に一律の情報を登録しておき省略する事も可能である）
データ（Ｂ―３）…
データ（Ｂ−１/２/４）を基に、算出された値や統計データであって制作者端末Ａに表示されるデータ。
例：
「（Ｂ−２）コンテンツＡの続きが依頼されました/依頼者ＩＤ/ 若干のコメント/日時/購入確率等」
→「（Ｂ−３）コンテンツＡの依頼者総合人数/総合購入確率等」
「（Ｂ−２）コンテンツＢの続きが依頼されました/依頼者ＩＤ/若干のコメント/日時/購入確率等」
→「（Ｂ−３）コンテンツＢの依頼者総合人数/総合購入確率等」
「（Ｂ−２）コンテンツＣの続きが依頼されました/依頼者ＩＤ/新規/鑑賞者人数/若干のコメント/日時等/購入確率等」→「（Ｂ−３）コンテンツ新規の依頼者総合人数/購入確率等」というオーダー一覧（依頼票）形式の情報（「図３１」参照）
データ（Ｂ−４）…
過去作品を厳密に指定したデータ。過去作品コンテンツＡ（ＩＤ：０００１）があった場合、さらに、
過去作品コンテンツＡの内の（ＩＤ：０００１−１）という作品
過去作品コンテンツＡの内の（ＩＤ：０００１−２）という作品
過去策作品コンテンツＡの内の（ＩＤ：０００１−３）という作品のデータ。
データ（Ｃ―１）…
次回著作情報（制作者入力情報）≪データｃと同一≫
『著作情報である、販売が行われる募集期間（※先行販売受付期間）コンテンツの詳細内容（計画書・次回作概要・題名、あらすじ等）コンテンツ形態（音楽、動画、画像…）「例、作画/枚数、書籍/頁数、［作品名］○○の続き…」金額、完成予定日（○月○日、所要日数○カ月）制作実行可能人数（○人以上であれば制作実行等・制作が実行される購入人数の目安）延長有無と延長の対応方法、他』
また、顧客からの依頼が、作品（Ａ）であり、制作者は次回作（Ａ’）という作品を制作する場合は、作品（Ａ‘）というデータを、規定のフォーマットへ入力する規定の著作情報であり、顧客からの依頼が、作品（B）であり、制作者は次回作（B’）という作品を制作する場合は、作品（B‘）というデータを、規定のフォーマットへ入力する規定の著作情報であり、顧客からの依頼が、作品（新規）であり、制作者は次回作（新規’）という作品を制作する場合は、作品（新規‘）というデータを、規定のフォーマットへ入力する規定の著作情報であり、観賞者からの応答による情報である。
データ（Ｃ―２）…
鑑賞者の端末（カート内）に表示されるデータ（Ｃ−１）
「作品Ａの続き」であれば、「作品（Ａ’）の情報が届く」
「作品新規依頼」であれば、「作品新規の情報が届く」
と言う様に、鑑賞者が指定した商品データにひも付いて送信されるデータであり、
鑑賞者が、データ（ｂ）を送信する際に、作品Ａ、作品Ｂと、選択していなければ届かない。
同一作家の、その他の作品も可能であれば、宣伝広告として表示できるが
依頼商品とは明確に区別されている。
データ（Ｃ−３）…
コンテンツ題名、受付期間、制作者名等、コンテンツ内容の要約情報（※データc−１の要約）
データ（Ｉ）…積立金額
データ（Ｉ−１）…積立金額の内、（鑑賞者の購入金額、積立金合計額）
データ（I−２）…積立金額の内、（コンテンツ事に振り分けられる等した、積立型、プール型、混合型の情報）
データ（J）…時間調整データ
データ（J−１）…時間調整データの内、（自動入札者以外の鑑賞者側希望タイミング情報等）
データ（J−２）…
時間調整データの内（制作者のざっくりとしたコンテンツ制作希望タイミング・日数時間等）
データ（J−３）…
時間調整データの内、（鑑賞者の自動入札設定に関するデータ＜自動入札回数、最大期限、上限金額等＞）
データ（J−４）…時間調整データの内（制作合意後の購入が決まった完成日時データ・搬入可能日時）
データ（Ｋ）…その他のデータ、（金額、日数等の相場表）
データ（Ｌ）…ユーザー情報等
■ＤＢサーバ関係：記憶装置１０１詳細
１０１…過去作品著作情報データベース（データＡ−１を格納する）
１０２…過去作品データベース（データＡ−２を格納する）
２０１…依頼情報データベース（データＢ−１、Ｂ−２、Ｂ−３、Ｂ−４を格納する）
２０２…次回作情報データベース（データＣ−１を格納する）
３０１…完成作品データベース（データｈを格納する）
４０１…積立金データベースサーバ
５０１…時間調整データベースサーバ
６０１…受注処理サーバ（一連のプログラムを処理する）
■プログラム処理関係
１１…作者ＩＤ認証に関する一連の処理
１２…過去作品を登録する一連の処理
１３…依頼情報を送受信する一連の処理
１４…次回作情報を送受信する一連の処理
１５…受注処理に関する一連の処理（メール通知等、その他諸々）
１６…ボタン生成など「続きを見たい」ボタンを配布する一連の処理
１７…完成作成搬入の一連の処理（ＵＰロード、ダウンロード等）
■画面関係
画面１０…ボタンが設置されている画面
画面１１…ボタンが設置されておらず鑑賞者が自身で制作者名と作品名を入力する画面
画面１２…過去作品著作情報ＤＢ（１０１）に作者の登録が在る依頼入力画面
画面１３…過去作品著作情報ＤＢ（１０１）に作者の登録が無い依頼入力画面
画面１４…受付画面
画面１５…カート内画面１（通知された、データcの簡易情報を表示した一覧）
※鑑賞者のプライベート情報であり情報保護画面、非公開画面
画面１６…カート内画面２（続きが見たい作品の全容が確認容易な画面）
※鑑賞者のプライベート情報であり情報保護画面、非公開画面
画面１７…データ（Ｂ−２）が表示されている制作者画面
パターン１：個別依頼確認
パターン２：統計確認
パターン３：次回作入力選択画面
パターン４：次回作入力フォーマット
パターン５：過去作品登録漏れにより、鑑賞者から先に入力された（認証可能な）
過去作品データ（a）に対し、ＩＤ認証を行う処理画面
画面１８…
本発明サイトのプラットフォーム（続きを見たい作品ランキング等、本システムに登録された続きを見たい作品、及び過去作品が、この画面から検索できる）
画面１９…
コンテンツスケジュール画面
パターン１：ざっくりとした購入前コンテンツスケジュール画面
パターン２：作品搬入日時が決定した購入後コンテンツスケジュール画面

上記課題を解決する為に、請求項１に記載のコンテンツ販売方法は、コンテンツ提供者であるユーザー（１）と、少なくとも一人以上で構成されるコンテンツ鑑賞者（又は購入者）であるユーザー（２）の各端末が、インターネット回線より繋がっており、前記ユーザ（１）は、既に過去に制作した観賞可能な過去作品を有している事を前提として、過去作品を観賞した前記ユーザー（２）が、その過去作品の提供者であるユーザー（１）の次回の作品を観賞したい場合、前記ユーザー（１）が、次回作を製作する事を「予定している / 予定していない」に関わらず、制作者が、制作予定を立てる段階からでも、前記ユーザー（２）から前記ユーザー（１）へ、コンテンツの次回作品の購入の要求を行い売買が始まる事を特徴とし、前記ユーザー（１）が、前記ユーザー（２）の要求を受けて制作の判断を行い、そして「制作を行う」という判断ならば次回作を作成し、コンテンツの提供を行えることで解決を行う。又、本発明が次回作と述べるその対象となりえるのは、連続する作品の次回作（同シリーズ）、同じ作家の異なる作品（新作）としての次回作（異なるシリーズ）、同作品のリメイク・復刻版等（改良としての次回作）も含まれる。（尚、段落「００１５」に詳細に記載）

従来のオンライン上でのコンテンツ販売の方法は、コンテンツ制作者側及び仲介者が創作物をオンライン上にて表示し、鑑賞者はその表示された商品を観て判断し購入するというステップである。購入に至るまでの段階には、音楽であれば視聴機能、書籍であれば中身拝見機能などのお試し機能があり、これらによって購買の意思決定を高めるという手段がある。又、類似する既存のシステムには、予約販売システム、オーダーシステム、投資システム、アマゾン等のオンラインストアシステム、アンケートシステム、マーケティングシステム、コミュニティーシステムが存在する。尚、段落「００１８」〜「００１９」にて、相違点を詳細に述べる。

以上は、ＷＥＢ上に存在している周知の課題であり、長らく解決できずにいる難問である。又、本発明は、原価というコストリスク（赤字リスク）回避に留まらず、制作者が作品（いわゆる画像、音楽、文書、動画等の表現作品）を制作するにあたり、アルバイトや仕事を行いながら作品を制作しないといけないという環境を解決したいとするものである。これを考えるにあたり「制作時間を捻出できないか？」という課題を持つものである。通常、作品を制作するにあたり“コスト”という物理的な費用の壁を感じたとしても、自分自身の“時間”の壁には絶対的な不可能なできない理由を感じず、多少不便を感じつつも“時間”は無料である為、仕方のない事、気合いで何とかなる事だと考えられている。一般的に、時間的障害とは制作者が当然、負担しなければならない制約であると考えられており、その為、時間は本人の「やる気」の問題という心理的問題で片付けられている。しかし、本発明は制作者の時間捻出に関しても解決を課題としている。

上記課題を解決する為に、請求項１に記載の内容は、コンテンツ提供者と、コンテンツ鑑賞者（購入者が）端末を介してネットワーク回線で繋がっているシステムの、コンテンツを売買するためのコンテンツ提供方法である。そして、鑑賞者から、コンテンツ提供者へ「次回作の要求」の信号を送信することで、コンテンツの売買を始めることができる処理に特徴を有している。まず、既に、コンテンツ提供者の過去作品を観賞している鑑賞者が前提として存在しており、その鑑賞者が、当該過去作品の提供者の次回の作品を観賞したい場合に、「次回作要求」信号（例えば、「続きが見たい」、というようなボタンを押すことで）送信することができるものである。※又、過去作品の情報は、コンテンツＩＤが付与されて記憶装置に記憶されており、鑑賞者により（コンテンツＩＤを含んだ）「次回作要求」信号を受信すると、ＩＤコードでヒモ付いた形で管理されている。そしてこれは、前記コンテンツ提供者が、次回作を製作する事を予定しているかの有無に関わらず、前記鑑賞者から前記提供者へ、コンテンツの次回作品の購入の要求を行うことが可能な処理である。そして、次回作要求信号を受けたコンテンツ提供者は、その内容から、次回作を制作するかを決定し、制作を行う場合であれば「作成を行う」という信号を送信することができる。これにより、コンテンツの売買が仮成立する。そして、制作が完了すれば、コンテンツの受け渡しを行いコンテンツの提供が行える。これにより、上記課題を解決する。（尚、段落「００１５」に記載の内容である）

又、請求項２に記載の内容は、鑑賞者より、次回作要求信号を受けた前記コンテンツ提供者にて、次回作の概要データであるデータｃを受信する処理と、次に、前記次回作概要データｃを受けて、内容を確認した鑑賞者より、「購入する・しない」の信号データｄを受信する処理とを有している提供方法である。又、「購入する」という前記データｄを受けた、前記コンテンツ提供者より、制作を行うのかの判断であるデータeを受信する処理を有し、前記データeが「制作を行う」という信号の場合は、決算処理部にて決済を行う処理を有し、又は、前記データeが、「制作を行わない」という信号の場合は、決算処理部にて決済を行わない処理を有している。且つ、「制作を行う」という前記データeを受信した場合は、作品制作が完了して、作品の受け渡しが行われると、受け渡しが完了した信号を受信する処理を有しており、且つ、前記作品の受け渡しが行われた信号を受信すると、前記コンテンツ提供者へ売上金額を支払う処理を有している。又、前記作品の受け渡しが行われた信号が受信できない場合は、前記コンテンツ提供者へ売上金額を支払う処理を行わない処理を有している。尚、一連の信号の送受信処理は、ヒモ付いたコンテンツＩＤコードにて処理が行われる方法である。（尚、段落「００１６」〜「００１７」/「００３０」〜「００３６」に記載の内容である。）又、請求項３に記載の内容は、請求項１に記載のコンテンツ提供システムである。

又、請求項４に記載の内容は、次回作要求信号であるデータｂを送信した前記鑑賞者の端末画面にて、次回作を要求した作品（前記データｂとヒモ付いたコンテンツ情報）を、ストックして表示するカート画面を備えるシステムである。又、カート画面とは、コンテンツ購入者が選択したコンテンツを表示するものであり、カート画面にて表示するコンテンツは、前記鑑賞者が次回作要求信号データｂを送信して選択したコンテンツであり、選択していないその他の情報や広告情報とは、明確に区分した形で表示している。（尚、段落「００３７」/「００６２」/ に記載の内容である）

又、請求項５に記載の内容は、コンテンツ提供者以外からの過去作品の登録手段である。前記コンテンツ販売システムは、過去著作登録部（１２）と、コンテンツ提供者ＩＤ認証部（１１）とを備えており、前記過去著作登録部（１２）は、前記ユーザー（１）又は、前記ユーザー（２）より、記憶装置へ、属性データである過去作品著作情報をデータ（Ａ−１）の格納（登録）を行う手段であり、前記コンテンツ提供者ＩＤ認証部（１１）は、
コンテンツ提供者が、過去作品のコンテンツ提供者本人であること認証する手段である。これにより、コンテンツ鑑賞者は、コンテンツ提供者が、制作を予定している有無に関わらず、過去作品ＩＤとヒモ付いた、依頼信号（データｂ）を送信する事が可能になる。（段落「００３９」/「００２７」/「００４２」〜「００４６」にて詳細に記載）

又、請求項６に記載の内容は、観賞者と、コンテンツ提供者の間で、コンテンツが提供される、売買及び契約等のタイミングを調整する為の手段である。そして、タイミングを調整する手段は、自動入札設定手段を有している。自動入札設定手段は、前記コンテンツ鑑賞者が、次回作要求信号データｂの送信を行うと、入力できるデータであり、自動入札を行う設定データ（データＪ−３/ 自動入札回数、最大期限、上限金額等 ）を入力し設定することができる。これにより、処理を自動化して、タイミングを調整することが可能となる。又、コンテンツ提供システムは、前記データＪ−３を受信して、記憶装置へ記憶し、設定した内容にて処理を行う手段である。（段落「００３９」/「００５８」〜「００６１」に記載の内容である）又、請求項７に記載の内容は、観賞者と、コンテンツ提供者の間で、コンテンツが提供される、売買及び契約等のタイミングを調整する為の手段である。そして、コンテンツの売買及び契約等のタイミングを調整する為の契約タイミング調整手段として、前記コンテンツ鑑賞者より（データＪ−１/購入者側の希望タイミング等のデータ）を受信する手段と、前記コンテンツ提供者より（データＪ−２/提供側のざっくりとしたコンテンツ制作希望時間等）を受信する手段と、又、前記コンテンツ提供者より（Ｊ−４/確定した完成予定日時）とを受信する手段を有している。そして、コンテンツ提供システムは、前記タイミングを調整するデータを表示する画面構成を有しており、前記画面構成は、コンテンツスケジュール画面を有している。又、前記コンテンツスケジュール画面は、データＪ−２を表示する画面と、データＪ−４を表示する画面の２つのパターンを表示する事が可能である。（※「図４０」画面１９パターン１、画面１９パターン２）（段落「００３９」/「００５８」〜「００６１」に記載の内容である）又、請求項８に記載の内容は、請求項２に記載のコンテンツ提供システムである。

又、請求項９に記載の内容は、課金処理に於いて、制作者と鑑賞者と運営者の３者間の課金における負担のバランスを調整する手段である。そして、コンテンツ提供システムは、プール型課金による処理、積立型課金による処理、混合型課金による処理の、いずれか、又は、いずれかの組み合わせ、又は、全ての組み合わせを有している。（段落「００３９」/「００５５」〜「００５７」にて詳細に記載）

又、請求項１０に記載の内容は、前記次回作を要求する信号データｂの追加的な情報であり、さらに、詳細情報を含んだデータをデータＢ−２（詳細次回作要求情報）として、又、過去作品を厳密に指定したデータをデータＢ−４（過去作品厳密指定情報）として、受信する手段を有している。又、前記データＢ−２/Ｂ−４を、記憶する記憶装置を有し、且つ、前記データＢ−２/Ｂ−４を、前記コンテンツ提供者の画面へ表示する画面を有している。（尚、段落「００３９」/「００４７」〜「００４９」に記載の内容である）

又、請求項１１に記載の内容は、次回作要求信号データｂを受けた前記コンテンツ提供者より入力される、次回作概要データｃの入力手段であり、その画面構成である。そして、前記次回作概要データｃを入力することのできる画面構成は、鑑賞者より次回作を要求されたコンテンツの、次回作の情報を入力できる画面である。又、次回作の情報は、前記データｂより、コンテンツＩＤでヒモ付いた、コンテンツの情報を入力する事ができる。又、入力できるデータは、「図３２」に様に、入力できる内容が入力フォーマット等にて規定されている。又、入力されたデータは記憶装置に記憶される。そして、鑑賞者が要求していないその他の情報や広告情報とは明確に区分した形で、前記コンテンツ鑑賞者のカート画面に表示することができる。（段落「００３９」/「００５０」〜「００５４」に記載の内容である

本システムは、「図４４」の様に、既存のコンテンツ市場の流れを真逆にするものである。その為、鑑賞者と制作者の、相互間における商品売買のデータの送受信の流れは、既存システムのデータ送受信の流れと真逆のフローとなる。又、「図１２」に記載の「２次的欲求」とは、現在、鑑賞している作品を求める欲求ではなく、次回作（連続作品）を求める欲求である。本システムは、２次的欲求を対象としたコンテンツ（以降より、既存コンテンツと区別して、先行コンテンツと述べる）商品を販売するオンラインストアである。

＜１次欲求＞…現在確認している目の前の商品そのものを求める欲求。
＜２次欲求＞…現在確認している目の前の商品の次回作を求める欲求。

以上が、本ビジネスモデルの概要である。以下より、既存ビジネスモデルとの相違を述べる。

『１．予約販売システムとの比較』
予約販売システムは「制作者が広告を表示して顧客を集う」ものであり、本システムは、『鑑賞者が作家に続きを見たいと依頼する』ので相違する。本システムは鑑賞者側から制作者へ、コンテンツ制作依頼を行うオーダーシステムであり、その過程で作家と鑑賞者が制作する条件を調整し合うシステムである。

『２.オーダーシステムとの比較』
既存のオーダーシステムとは、顧客から依頼を行う販売モデルだが、作品の続きを依頼している訳ではなく、その目的は、顧客側に明確な制作（デザイン・建築・衣類等）を行ってほしい何かがあり依頼を行う。この場合、自分だけのオリジナルの商品を、制作してもらう時に発生する販売方法である。本発明の先行販売は、オリジナルコンテンツを制作依頼するわけでは無く、鑑賞者が、制作の次回作を観賞可能にするものであり、既存のオー
ダー販売とは、概念そのものが相違する。

『３．投資システムとの比較』
本システムは資金運用を行うのではなく、販売する商品そのものを購入するので異なる。

『４．アマゾン等のオンラインショップとの比較』
本システムでは、顧客が「続きが見たいボタン」を押すと、続きが見たい作品（先行コンテンツ）を「図２９」の様な形で、商品が並ぶカート画面に入れる事ができる。これは、アマゾン等の商品を購入するカート画面と類似しているが、本システムの取り扱う商品は、「現段階では作者自身も作る事を予定していないコンテンツ」であり、「未だ作ることも予定していない、現実には存在していない作品群」の、商品一覧カート画面である。（※アマゾン等オンラインストアに商品として存在してあるのは、予告販売の商品と、通常販売の商品である。）本発明がカートでストックしているコンテンツは、「図２９」の様に先行販売の商品であり、そして、ショップが展開可能なフィールドは、ＩＴ上の概ね全コンテンツが対象である。
＜先行販売＞＝制作者が制作の意図すら行ってない状態の商品
＜予約販売＞＝制作者が制作の意図を持っており予約商品として発表している商品
＜通常販売＞＝今すぐにでも購入できる商品

『５．アンケートシステム及び、マーケティングシステムとの比較』
本システムでは、アンケートを行うシステムではなく、あくまでも制作者側が待ちの姿勢にて、鑑賞者から依頼を受ける商品の販売ストアであり、その交渉過程の中で、顧客のアンケート要素的な意見を聞く要素も含むというだけのシステムである。本システムは依頼を受け付けるものであり、アンケートを行っている訳でも、マーケティングを行っているものではなく概念自体が相違している。

『６．コミュニティーシステム（ＳＮＳ）との比較』
本システムは、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販売未達→８．又、ニーズが無くて売り上げが無いと困るので、マーケティング機能も欲しい。→興味を持ってくれた購入予備軍のユーザーを囲い込みたい。過去に購入してくれたお客さんも囲い込みたい（ＦＡＮ機能を設置する。あるいは既存のコミュニティサイトで販売促進する。」

『コミュニティーシステム（ＦＡＮクラブ）の場合のフロー』
「そこそこに商品が売れていて人気が出た。（もしくは人気が在る）→２．顧客の囲い込みをしたい（もしくは顧客からファンクラブを作りたいと自発的に思う）→３．顧客とのコミュニケーションをはかりたい、仲良くなって新密度ＵＰをはかりたい、コミュニティーをつくりたい（もしくは作家とコミュニケーションを図りたい）→４．次の商品を販売する（もしくは次の商品が購入できる）」

『本システムの場合：制作者の視点』
「１．既に商品を制作して販売している自分（未来）→２．購入してくれた鑑賞者がいた（１より少しだけ過去）→２．作品が完成していた（２より少しだけ過去）→３．制作を行った（３より少しだけ過去）→４．制作したいと言う動機が在った（４より少しだけ過去）」
そしてこれを逆さまにすると、以下のステップが導かれる。
「制作したい→生活費と制作時間を捻出したい（この時点では、特に何を作ろうかの企画は決まっていない）→制作予定前より先に売り上げを確定して制作を行いたい→そして制作計画書を発行したらそれを購入してもらえないだろうか？→計画段階で購入しようとする人は誰だろう？→なぜ、購入してくれるのだろう？→９．前回の続きが見たいからだろう→１０．すると過去作品を見ていることが前提である（未来：既に販売している自分）」

以上が、人モノ流れである。※尚、ビジネスでは往々にして逆算して考えるケースが在るため上記は概ねの流れであります。例えば不揃いなケースには以下の様なものが在ります。→「作品作った→販売したい→その為には広告を行わなければ→情報一部公開→広告する→販売達成（次回作を制作する）」あるいは、「作品作った→早く次回作を作りたい→その前に、今作った作品を販売しよう→いろんな人に見て欲しい→その為には一部情報を公開しよう→広告しよう→販売達成」しかし、大きな流れはほぼ同じであります。そして、上記の内容をさらに簡素化したものを以下に述べる。

＜上記３種類のシステムの人・モノ・の流れの軸：さらに簡素化＞
『本システム』
「現在制作したい→生活費あるいは時間を確保したい（販売）→計画書（発案）→続きを見たい→過去作品」
『コミュニティーシステム（ＦＡＮクラブ）』
「人気が出た（ある）→仲良くなりたい（近づきたい）→もっと情報が欲しい（提供したい）」
『予約販売 』
「作品を作った→鑑賞してほしい→一部公開する→購入してほしい→商品引き渡して次回作の制作」

＜上記３種類のシステムの人・モノ・の流れの軸：さらに抽象化＞
・本システム
「制作→課金→一部情報→続き見たい→過去作品」
・コミュニティーシステム
「人気過去作品→ＦＡＮ（続き見たい）→一部情報（発案）→課金（販売）→次回制作」
・通常＆予約販売システム
「作品有→見て欲しい→一部情報公開→購入してほしい→次回作制作」

＜上記３種類のシステムの機能的フロー＞
先行販売 「過去作品＋ＦＡＮボタン＋販売前作品情報＋課金機能＋制作搬入」
ＦＡＮクラブ 「過去作品＋ＦＡＮボタン＋販売前作品情報＋課金機能＋制作搬入」
予約販売（消費者視点） 「作品無→広告→一部情報公開→課金→完成商品提供」
予約販売（提供者視点） 「制作搬入→広告→一部情報公開→課金→完成商品提供」

又、上記の予約販売の鑑賞者フローは、広告に興味を持ち、リンクを伝って商品の一部情報を見て、次に購入し、その後、完成作品を観賞するという形になります。しかし、消費者は、オンラインショップで商品を購入する際に、又、広告から入る場合ではなく、消費者が自ら特定の欲しい商品を求めていて、それを販売しているショップを探しているケースもあるためその場合のフローを以下に述べる。

＜機能的フロー：鑑賞者目線＞
「作品無し→作品を販売して欲しい（ストア探し）→商品の一部情報公開→
購入意思決定（カート）→完全商品」
↓
＜さらに簡素化する＞
「商品無し→販売（課金）→一部情報→カート→完全商品」
↓
＜さらに人・モノ・フローに置き換える＞
「完全商品→カート→一部情報→課金→商品無し」

この場合、消費者が広告から入らない場合のトリガーになる部分（ＦＡＮ機能になる部分）は、「カート」ボタンになり、消費者が広告から入る場合は、「広告リンク」ボタンが、トリガー（ＦＡＮ機能）になります。これは消費者から特定の商品を求めていた場合、「続きを見たい」という意思決定ボタンは「カートへ入れる」ボタンになるということになります。「カートへ入れるボタン」と、「広告リンクボタン」が、消費者と提供者のその時の状態で、質的な役割が変化しています。そして、さらに一連のフローをイメージとして抽象化すると以下になります。

＜機械的フロー＞
ＦＡＮクラブ 「作品有→トリガー→中→トリガー→作品無」
予約通常販売 「作品無→トリガー→中→トリガー→作品有」
先行販売 「作品有→トリガー→中→トリガー→作品無」
＜人・モノのフロー＞
ＦＡＮクラブ 「作品有→トリガー→中→トリガー→作品無」
予約通常販売 「作品有→トリガー→中→トリガー→作品無」
先行販売 「作品無→トリガー→中→トリガー→作品有」

（※トリガー＝意思決定）
以上の様に、本システムの、軸となるフローが、既存にある、コミュニティーシステム、予約＆通常販売と、真逆になっております。（「図４５」参照）

次に本発明の「続きを見たいボタン」の概念的な説明を、本システムと類似する既存の「カートボタン」、「ＦＡＮボタン」と比較しながら述べる。

『オンラインショップのカートへ入れるボタン』
既存のカートボタンの性質は、「購入前＋整理機能」である。そのフローとして、「購入前整理機能（カートへ入れる）」を押してから、「購入する（最終決済意思）」までの消費者の意思とそれに掛る情報（物）の変化（流れ）は、「カートボタンを押すと＝購入したい商品情報（通常又は予約販売）を≪完全に指定≫し、大量にある商品の中から選別（整理）する」そして、カート内に入ると「カートボタンで≪完全に指定≫した商品情報が表示される（これは先よりも整理された状態である）」。そして「選別して表示された商品（情報）の中からさらに、最終選別を行い最終決済意思購入ボタンを押す」というステップである。消費者は、カートボタンにより特定の情報（商品）を≪完全に指定≫し、カート内で、その消費者が≪完全に指定≫した情報をそのまま表示し、次に消費者は購入ステップを踏む。

『本システムの（続きを見たい）ボタン』
続きを見たいボタンの性質は、「アンケート的要素＋リピート的（評価的要素）＋（オーダー的）購入前意思＋情報整理機能（ＲＳＳ）」である。そして、そのフローは、「オーダー意思＋整理機能ボタン（カートへ入れる）」を押してから、「購入する（最終決済意思）」までの消費者の意思と、それに掛る情報（物）の変化（流れ）は、「（続きを見たい）ボタンを押すと＝購入したい商品（情報）を≪緩やかに指定≫し、大量にある商品の中から選別（整理）する」そして、本発明のサイト内に入ると「（続きを見たい）ボタンで≪緩やかに指定≫した商品（情報）が表示される（これは先よりも整理された状態である。又、先のボタンから情報表示までに小から大の時間差有）」そして「選別して表示された商品（情報）の中からさらに、最終選別を行い最終決済意思購入ボタンを押す」というステップである。消費者は、（続きを見たい）ボタンにより特定の情報（商品）を≪緩やかに指定≫し、本発明サイト内で、その消費者が≪緩やかに指定≫した情報をそのまま表示し、次に、消費者は購入ステップを踏みます。（※緩やかに指定するとは、商品が、未だ無いコンテンツの為、完全に指定していると言えない為、“緩やかに”とした表現である。）

※尚、カートへ入れる段階が、“ゆるやか”に購入を指定するという、“ゆるやか”とは、対象商品が未だ無いコンテンツである為、購入しようとする商品が無く（制作予定表すら無い状態である）、指定をしたくとも指定できない状態であるという意味の、“ゆるやか”である）しかし、どの過去作品の次回作なのか？という過去作品に対しては厳密に指定するものとする。（「図５１」参照）

『コミュニティシステム等のＦＡＮボタン』
ＦＡＮボタンの性質は「情報需要意思＋整理機能ボタン」を押してから、何らかのコンテンツに出会い「購入意思（最終決済意思）」を押すまでの消費者の意思と、それに掛る情報（物）の変化（流れ）は、「ＦＡＮボタンを押すと＝ある特定の情報（しかし不特定情報として需要する情報）を、購入商品として≪指定は行わない≫形で、大量にある情報の中から選別（整理）する」そして、コミュニティサイト内に入ると「ＦＡＮボタンで、購入商品として≪指定は行わなかった≫情報である、特定の情報（しかし不特定情報として需要する情報）が表示される。」（これは先よりも情報は整理された状態である）そして「選別して表示された特定（不特定）の情報の中からさらに、購入したい商品（情報）を見つけると、「カートへ入れるボタン」により購入したい商品（情報）を≪完全に指定≫し、大量にある商品の中から、又さらに選別（整理）する」そして、カート内に入ると「カートボタンで≪完全に指定≫した商品（情報）が表示される」（これは先よりも整理された状態である）そして「選別して表示された商品（情報）の中からさらに、最終選別を行い「最終決済意思」ボタンを押す」というステップを踏みます。これは、既存にある「コミュニティー＆オンラインショップ」の構造になります。

以上の様に、信号を送信してから返信される処理の内容が既存の機能とは異なっております

以上の既存ビジネスモデルとの相違から、本システムは、経済モデルそのものが過去に一つも事例の無い経済モデルである。

ユーザ（１）とユーザ（２）とで行われる売買に於けるフローチャート図 「続きが見たい」ボタン 「続きが見たい」制作者を一覧表示した画面 先行販売作品の一覧表示した画面 制作計画書（作品予告データ）の表示画面 先行販売作品の内容表示画面 購入後画面（参考例） 鑑賞者と制作者の作品売買におけるデータの送信のフロー 鑑賞者から先行して売買が始まる先行コンテンツ販売における図 続きを見たいボタン配布図（イメージとしてRSS型オンラインショップである） 既存オンラインショップのカートボタンとの比較 先行コンテンツオンラインストアのイメージ図 先行販売システムの全体構成図(※記憶装置１０１詳細図) 先行販売システムの全体構成図（※受注サーバ６０１詳細図） 各コンテンツの次回作依頼が送信された時の鑑賞者と制作者の相互間のステップ図 （※鑑賞者と制作者の間のデータ送受信は、各作品IDがヒモ付けられている図） 制作者が鑑賞者群に次回作情報データCを送信する図 （※各次回作データが作品IDでヒモ付けられた各鑑賞者へ送信される） 先行コンテンツ（依頼商品）と宣伝広告コンテンツとの明確な区分がされている図 「続きを見たい」ボタン配布パターン１（制作者の手作業での設置） 「続きを見たい」ボタン配布パターン２（任意サイト運営者側の設置） 過去作品著作ＤＢ内のデータ（ａ）の制作者ＩＤ認証済データと認証未処理データ 過去作品登録における鑑賞者からのステップと制作者からのステップのフロー図 続き依頼であるデータ（B-2）の送信ステップ（画面） （※「続きが見たい」ボタンが設置されている場合とされていない場合。又、本システム に過去著作情報が登録されている場合とされていない場合におけるステップ） 続き依頼であるデータ（B-2）の送信ステップ（画面） （本システムに制作者側からの登録が無い場合、鑑賞者からの登録を行うステップ１） ボタン有無と、過去著作ＤＢ１０１内のデータ有無とに於いて、 ４つのパターンからのデータｂの送信ステップ 続き依頼であるデータ（B-2）の送信ステップ（フロー図）（本システムに制作者側からの登録が無い場合の鑑賞者からの登録を行うステップ２） 制作者の本人確認を行うＩＤ認証方法のパターン 制作者の本人確認を行うＩＤ認証フロー 依頼情報データベースに格納されるデータ（B-2） 続き依頼（データB−2）を受けて、次回作（データｃ）を送信するフロー 続き依頼を送信した後の、各３つの画面図（制作者画面、鑑賞者画面、本システムサイト） 制作者端末Ａの、依頼データB-3の表示画面（パターン１とパターン２） 依頼画面から、既定のフォーマット画面に入り、次回作情報を入力送信する図 先行コンテンツサイト画面（※本システムのメイン画面） 先行コンテンツサイト画面のID認証済みと未処理の２つの過去情報が検索表示される図 （※無料公開コンテンツＵＲＬは制作者管理による） 制作者ログイン画面であり、本システムに制作者ＩＤは登録しているが、過去作品情報登録漏れがあり、鑑賞者側から先に過去作品情報の登録が在った際の作品認証画面。 一連の制作者フローと一連の鑑賞者フロー 課金システムのフロー図（プール型と積立型） 課金システムのフロー図（プール型と積立型の混合型） 鑑賞者と制作者の契約タイミング調整データ タイミング調整データを使った統計図 コンテンツ制作時間相場表 契約タイミング調整フロー 本発明の課題 本発明が課題を解決する方法である、真逆のビジネスモデルの概要 本ビジネスモデルの軸の構造のイメージ図 市場と機能のフローイメージ図と、提供者と顧客の力関係の比較 既存FANボタンとの比較図１ 既存FANボタンとの比較図２ 既存FANボタンとの比較図３ カートに入れる前とカートに入れた後の図 データＢ群の詳細フロー 厳密にコンテンツを指定する図 同一制作者及び同一コンテンツの過去作品バリエーションの選択可能性 購入フロー及び、機能のまとめ図

本発明の課金システムは、作品制作者であるユーザ（１）が端末（Ａ）を介して、情報データ（a）を記憶装置に蓄積し、鑑賞者であるユーザ（２）は端末（Ｂ）を介して、前記データ（a）を確認する。前記ユーザ（２）は、お気に入りの作家を見つけると、自身が作品を観賞しているＦＡＮであり次回作を希望している意思表示を表すデータ（ｂ）を送信することができ、本システムはそのデータを記憶装置に記憶させる。又、前記ユーザー（１）は前記データ（ｂ）を基に、自身の次回作を要求している見込み顧客の確認が容易になる。

尚、上記決算手段は全てクレジット決済によるものであるが、金融機関での振込の形態をとる場合や人的手段を要する場合は上記形態に限られるものではない。振込課金である場合の課金方法は別途にプール先である振込口座を設ける等の処置も可能であるし、また同一の口座でも可能であるが個々に応じた対応を取れるものとする。クレジット課金以外の方法である振込に関しても、前述「００３４」の方法と同じものである。

そして、４つ目の課題である、次回作の要求を行うデータｂに関しての詳細なデータの送受信を述べる。データB−１は、データｂの簡易情報であり、データB−２は、データｂの詳細情報であり、データB−３は、データB−２より算出した分析データである。そして「図２２」は、データｂの送信ステップ画面である。画面１０は、「続きが見たい」ボタンが設置されている場合であり、画面１１は、設置されていない場合である。そして、過去著作情報ＤＢ１０１に、登録が在る場合は、画面１２へ進み、登録が無い場合は、画面１３へ進む。そして画面１２又は画面１３にて、データB−２を入力すると、送信ボタンを押すことにより依頼ステップは完了する。データB−２の送信を終えると、観賞者は自身のログイン画面カート内（依頼一覧）に、先行依頼を行ったコンテンツが入っていることを確認できる。画面１５は、カート内画面の、データｃの要約が表示された一覧であり、画面１６は、カート内画面の要約無しの一覧である。又、データB-2は、ログイン後の登録設定により省略も可能である。

次に、「図２８」は、依頼情報データベースに格納されるデータB−２である。＜購入確率/コメント/その他作品も要求 / 作品Ｂ・新規作品＞の情報が格納される。又、B−２は、省略する事も可能である。例えば、「購入確率５０％」「依頼商品は指定コンテンツのみ」という様に、「続きを見たい」ボタンの信号内容を事前に鑑賞者側で、ログイン画面により設定を行うことも可能である。この場合、鑑賞者はログイン後に「続きを見たい」ボタンを押すものとする。又、「図５１」は、過去作品を厳密に指定している図である。鑑賞者は、次回作の依頼を行う為に、どの過去作品の続きなのかを厳密に指定する必要がある。例えば、コンテンツAという、商品があったとしも、そのコンテンツAには、付随する関連アイテムが多数存在するケースがある。例えば、コンテンツAが映画作品であったとして、それに関する関連アイテムA（玩具）,B（小説）,C（CD）…と言う様に、コンテンツAという広い枠組みの中に、様々な商品があるというケースがある。こうした場合、厳密指定を行えるように、「図５１」の様に、過去作品を特定できる機能を有するものとする。また、この厳密指定を行うステップあるいは画面は、データB-2を入力する画面にて行うケースでも良く、自動入札画面にて行うケースでも良く、過去作品が厳密に特定できるケースであれば良いものとする。又、段落「００２１」の、”ゆるやか”に指定するという意味は、購入する作品に対して指した言葉であり、購入したい作品においては、未だコンテンツが無い為、購入商品を指定したくても指定する事ができず、購入する商品においては、“ゆるやかな”指定である。そして、既に鑑賞してしまった過去作品においては厳密に指定しなくてはならないものとする。又、「図５２」は、同一コンテンツや、同一制作者の過去作品バリエーションの中から、鑑賞者側から作品を選択する容易性（自由度）を表した図である。又、「図５０」は、データＢ群の送信フローを纏めたものである。又、「図３０」は、鑑賞者が続きを見たいボタンを押した後に、データの値に変更があれば、その値が反映される３つの画面である。画面１５は、鑑賞者のカート画面であり、ボタンを押した後に、コンテンツがカート内に入る。画面１７は、制作者の依頼画面であり、ボタンを押した後に、制作者に依頼内容が届く。画面１８は、本システムのプラットフォームサイト画面であり、コンテンツアイコン側に表示される「続きが見たい人」の人数が加算される。又、ユーザーは非公開である。以上は＜依頼情報送受信処理（１３）＞である。

そして課題としては、鑑賞者と、制作者と、本システム運営側の負担におけるバランスについてである。これは、先行コンテンツという商品を扱うにあたり、購入から作品受け渡し迄の、宙に浮いてしまう空白期間が存在してしまう為、その期間の資金における３者の負担の分散を行いたいという問題である。以下に３者における各問題を述べる。

「制作者側の問題として」
例えば、制作に１カ月を要するコンテンツがあり、鑑賞者から依頼の注文だけが大量あったとしても直前になって購入を辞められてしまうリスクがある。これを防止する方法として、鑑賞者に依頼の段階で、購入の責任を負ってもらう事で対処を行う。しかしながら、まだ、作品を受け渡していないのに、売上金を得る事はできないものとし、プール型の課金方法を行うものとしている。

「鑑賞者側の問題として」
通常であれば制作を行わなかった製品に対し、鑑賞者側から依頼できるというメリットがある為、依頼を行っているという形態だからこそ、制作予定購入段階で課金に責任を負うものとする。しかしながら、商品を手に入れていない段階で課金を行うという事は、前倒しの支払いであり、負担があるという問題である。

「本システム運営側の問題として」
プール型の場合、システム運営側の管理に対する責任が重いという問題が在る。又、無駄な手数料が掛る場合もある。又、既存ビジネスモデルでは無い為一から複雑なシステムを考えなくてはならず、又、開発に於いても費用が掛る。

その為、以上により、「図３７」の様な、積立型を考える事ができる。積立型は、積立金DBサーバにより、データだけで購入金額を管理する方法である。これは、購入したトータル額を計算し、DB内にて金額を記憶し、商品受け渡し時に制作者口座に振り込む方法である。又、積立型の若干の問題としては、２カ月後、３ヶ月後、半年後と言う様に、制作期間が長期化するほど、鑑賞者及び制作者に於いて負担となる。例えば、鑑賞者としては、購入した事を忘れてしまい、後になって支払い請求が来るリスクであり、制作者としては、期限内に完成作品を搬入しても売り上げを回収できないリスクである。（※プール型と積立型の違いは、鑑賞者の口座からの引き落ちるタイミングが相違する点である。プール型は本システムのプール口座に一旦保管されるが、積立型は本システムのプール口座を経由しない形である）この場合の解決法として、積立型とプール型の併用である混合型を有するものとする。（「図３８」参照）混合型とは、一定以上迄は、積立金での管理を行うが、一定以上を越えると、プール型に切り替わる方式である。一定のラインとは、例えば、日数であったり、金額であったり、どちらでも構わないものとする。又、コンテンツの制作日数によりタイプ分けを行い、タイプによって、積立型か、プール型か、混合型かを設定し、併用する事も可能である（「図３８下図」参照）。尚、できるだけ短期制作型を行えるようにするものとする。又、「続きを見たい」ボタンにはチップ設定を行うことも可能である。先行コンテンツ販売では、観賞者からの依頼で始まり、制作者は基本的に制作することを予定してはおらず、「続きを見たい」と言われて初めて、制作計画表を立て発表を行う為である。これは、鑑賞者側にメリットが高すぎる場合は、チップを加算し（コンテンツ本体額の５％程度）、鑑賞者側にメリットがない場合は、チップを無しにする様な、両者の条件的な調整機能である。

次に、「図４０」は、鑑賞者と制作者の契約タイミング調整データ及び、制作者であるユーザーの管理画面、及び、コンテンツスケジュール画面である。上図の左側のデータ表は、制作者の希望制作タイミングデータ（Ｊ−２）である。これは、ざっくりとした制作者の制作情報である。又、例えばこれは、「コンテンツ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）に対し、ＩＤ認証を行う処理画面
画面１８…
本発明サイトのプラットフォーム（続きを見たい作品ランキング等、本システムに登録された続きを見たい作品、及び過去作品が、この画面から検索できる）
画面１９…
コンテンツスケジュール画面
パターン１：ざっくりとした購入前コンテンツスケジュール画面
パターン２：作品搬入日時が決定した購入後コンテンツスケジュール画面

Claims (5)

1. 作品提供者であるユーザ（１）と、作品観賞者であるユーザ（２）が作品を売買するための課金システムを搭載したオラインストアであって、
   鑑賞者から制作者へ、次回作品を制作するように、先行して依頼を行う販売システムであり、制作者が制作を予定していない内から、鑑賞者からアクションを起こすコンテンツの販売システムであって、
   端末Ａと端末Ｂが、インターネットを介して記憶装置であるデータベースサーバ１０１と繋がっており、
   前記制作者ユーザー（１）が端末（Ａ）より、過去作品情報データ（a）を送信し、過去作品情報メニューリストとして記憶装置１０１へと格納を行う処理のステップと、
   鑑賞者ユーザー（２）は、鑑賞者端末Ｂにより前記過去作品情報データ（a）を参照する事が可能なシステムであって、前記鑑賞者ユーザ（２）が端末Ｂより、過去作品の観賞を行って続きを見たいコンテンツに対し、参照を行ったデータa（作品ＩＤ含む。例えば、作品ID：０００１）の情報を含んでいる次回作要求情報であるデータ（b）＜作品ID:０００１/作品ID０００１の次回作依頼＞を送信し、記憶装置１０１へと格納すると、前記制作者ユーザー（１）の端末Ａへと、送信する処理のステップと、
   （※データｂは、過去作品データ（a）を参考にしてお気に入りの作家に次回作を依頼する信号であり、これにより前記鑑賞者は、自身が過去作品を観賞したリピータであり、オーダー意思を含む次回作品要求信号を制作者に通知することができる）
   次に、前記制作者ユーザ（１）は、制作者端末画面にて、鑑賞者が過去作品データaを参照して送信を送ったデータ（ｂ）を確認すると、鑑賞者がどの作品の次回作を要求（依頼）してきたのかをチェックし、鑑賞者が次回作を要求してきた指定の作品（※例えば、作品ID:０００１/次回作依頼）に対し、その次回作である情報データc（例えば、作品ID：０００１の次回作品概要）を発行する処理のステップと、
   次に、制作者ユーザー（１）より、次回作情報データ（c）が送信されると、記憶装置１０１に格納され、
   （例えば、作品ID：0001の次回作を要求していた）前記鑑賞者ユーザ群２の端末へと送信する処理ステップと、
   （※尚、過去作品データaと、次回作要求データｂと、次回予告情報データｃは、依頼の流れにより同一の作品であり、認識を行う為に作品ＩＤでヒモ付けられている。又、データCは、規定された情報であり、情報内容は“次回作”という限定されたデータである）
   次に、前記鑑賞者ユーザー群（２）は、自身で次回作を要求したコンテンツに対し、前記制作者ユーザー（１）から返信された次回作情報データｃを確認すると、「購入する・しない」の意思であるデータ（d）を送信し、記憶装置へ信号を格納する処理ステップと、
   次に、コンピュータが購入判断である前記データ（d）の合計値（合計人数・合計金額等）を算出し、制作者端末（Ａ）に表示する処理のステップと、
   次に前記制作者ユーザ（１）が、制作意思の合否であるデータ（e）を送信し、前記データ（e）が合意であれば、前記鑑賞者ユーザーにその内容が通知され、又、同時に、前記鑑賞者の決済情報であるデータ（f）が、決済システムに自動的に送信され、前記鑑賞者ユーザ（２）に自動的に課金される処理のステップと、
   又、前記制作判断であるデータ（e）が拒否であれば、決済情報データ（f）は決済システムには送信されず課金は行われない処理のステップと、
   次に、前記ユーザ（２）に課金された金額は、制作者には直接振り込まれず、一旦プール口座等で保留しておく処理を有しており、
   次に、作品が完成すると、前記ユーザ（１）は、端末（Ａ）により、完成作品データ（ｈ）
   を記憶装置１０１へと格納し、完成作品の搬入を行える処理のステップと、
   次に、記憶装置１０１へ完成作品が搬入されると、前記鑑賞者ユーザ（２）に、作品が完成したことを通知するメールを自動的に送信する処理のステップと、
   次に、前記鑑賞者ユーザ（２）が記憶装置１０１より作品が完成したのを確認し、作
   品を受け取る処理を行うと、作品が鑑賞者に渡された信号であるデータ（g）が決済システムに自動的に送られる処理のステップと、
   データ（g）を受け取った決済システムは、前記制作者ユーザ（１）の口座に、プールしていた金額を自動的に振込む処理のステップと、
   また、決済システムが、作品受渡し完了データ（ｇ）を受信できなかった場合は、前記ユーザ（２）へ金額が自動的に返金される処理のステップを有した、
   先行課金システムに関する。
2. 本システムは、先行コンテンツによるオンラインストアであって、
   「続きを見たい」という様な次回作依頼を示すボタンを押すことにより、
   過去作品データa（作品Ａ/ＩＤ：０００１/次回作依頼等）を含んだデータｂが配信され、
   前記鑑賞者ユーザー２が、前記制作者ユーザー１へと次回作要求信号を送信できるものであって、広く他サイトへボタンを配布する事が可能である。そして、「続きを見たいボタン」を押した前記鑑賞者端末Ｂには、続きを見たいコンテンツ（次回作の購入予定コンテンツ）が一覧リストとしてカート内にストックされ、（※尚、リスト情報は非公開情報である。又、制作者と観賞者はコミュニティの様に繋がらない）前記鑑賞者はこのリスト画面により、前記制作者から通知される次回作品情報データｃ（※データCとは、例えば、作品Ａ、ＩＤ：０００１の次回作情報と言う様に、情報入力フォーマットは規定されており、さらに、端末Bへの表示フォーマットに於いても規定されており、鑑賞者が求める次回作という限定された情報であり、顧客から依頼信号が無く求められていない情報に関しては広告情報として区別されている）である制作予告を確認することが可能な機能を有する請求項１に記載のシステム。
3. コンテンツを先行して依頼する事のできる課金処理であって、制作者よりも先に依頼を行う先行コンテンツ（動画・音楽・画像・書籍・ゲーム等）を販売するに当たり、制作者と鑑賞者の間の課金フローのバランスを調整するシステムであって、
   次回作情報データｃを確認した、前記鑑賞者ユーザー（２）が、購入の意思決定であるデータ（d）により、「購入する」という信号を送信すると、
   それを確認した前記制作者ユーザー（１）は、制作合否であるデータ（e）を送信し、
   「制作を行う」ならば、決済信号であるデータ（f）が決済システムに送信されると、前記鑑賞者ユーザー（２）に、その時点で課金が行われる処理と、
   （※課金処理が実行される最終決定は、鑑賞者側にあるのではなく、時間と売り上げのバランスを考える制作者側の判断である為、課金モデルとしてはオークションと類似するが、顧客は一人ではないということと、商品の中身においても未だ無い先行コンテンツという商品の購入を行うので投資システムのモデルとも類似するが金融商品ではなくコンテンツであること）
   又、課金された金額は、直ぐに制作者に振り込まれず一旦プールされる処理と、
   次に、完成コンテンツ（ｈ）が記憶装置１０１へ格納されると、作品が完成し搬入された事を通知する信号が鑑賞者へ送られる処理と、
   次に、作品の受け渡しが完了した信号データ（g）を決済システムが受け取ると、前記制作者ユーザー（１）の口座にプールされた金額が振り込まれる処理と、
   又、受け渡しが完了した信号データ（g）が、受信されなければ、前記ユーザー（２）にプールされていた金額が返金される処理を有し、
   以上の一連のフローであるプール型を基本とし、さらに、積立型と、混合型の併用により、決済処理を行う機能であって、積立金ＤＢサーバは、積立額の合計値を算出し、データ（Ｉ−１）を記憶管理し、また、データ（Ｉ−２）により、条件によって課金処理が選択可能な請求項１に記載のシステム。
4. 端末Aと、端末Bがインターネット回線で繋がっており、
   本システム以外である、任意サイトの過去作品ＤＢサーバと、
   （※以下より本システムである）受注処理サーバ６０１と、
   過去作品著作情報データ（Ａ−１）を格納する過去作品著作データベース１０１と、
   過去作品（コンテンツそのもの）であるデータ（Ａ−２）を格納する過去作品データベース１０２とを有し、
   （※尚、データaの内、著作情報をA−１として、コンテンツそのものをA−２として、過去作品をメニューリストとして管理するものであり、コンテンツそのものであるA−２に関しては、任意のサイトでの表示でも可能であるとする）
   さらに、鑑賞者からの次回作要求情報データＢ群（Ｂ−１/簡易情報）（Ｂ−２/詳細情報）（Ｂ−３/算出された値）（Ｂ−４/厳密指定情報）を格納する依頼情報データベース２０１を有し、
   そして、データＢ群よりヒモ付けられた作品ＩＤにより作成された、制作者からの次回著作情報データ群（ｃ）を格納する次回著作情報データベース２０２と、
   完成作品（ｈ）を格納する完成作品データベース３０１と、
   積立金を計算し積立額データを記憶する積立金データベースサーバ４０１と、
   契約タイミングを調整するための情報データを格納する時間調整データベースサーバ５０１と、
   その他のデータ（ユーザー情報等）を格納する管理サーバとを有しており、
   さらに受注サーバ６０１は、過去著作登録処理（１２）と、
   制作者ID認証処理（１１）と、依頼情報送受信処理（１３）と、次回作送受信処理（１４）と、
   受注処理（１５）と、「続きを見たい」ボタンコード生成処理（１６）と、搬入処理（１７）と、を有しており、
   そして過去著作登録処理（１２）は、制作者又は鑑賞者より、過去著作ＤＢ１０１へ、データ（A−１）の格納を行う一連の処理であり、
   制作者より登録された過去著作データ（A−1）は、ID認証処理済みデータとして、
   観賞者より登録されたデータ（A−１）は、ID認証未処理データとして振り分けられ、
   そして、制作者ID認証処理（１１）は、ID認証未処理データを、ID認証済データへと移行させる一連の処理であり、これは本システムより過去著作データA−１を参照し、それにより所定の認証コードを抽出しID認証を行う処理であり、
   次に、依頼情報送受信（１３）は、データ（Ｂ−１/簡易信号）（B−２/詳細信号）（Ｂ−３/算出された値）（Ｂ−４/厳密指定）を受信し、依頼情報データベース２０１へ格納を行う処理や、
   データ（B−２）（Ｂ−４）より、算出したデータ（B−３）を、制作者端末へ送信する一連の処理であって、
   （※尚、鑑賞者が「続きを見たい」ボタンを押してから、商品をカートに入れる迄のフローとして、ボタンの有無と、過去著作データA−１の有無とによる、其々各４パターンの状況からの処理を有しており）
   次に、次回作情報送受信処理（１４）は、データ（Ｂ群）を受けて、制作者端末Ａに、依頼のあった作品に対し、次回作情報入力画面（規定のフォーマット画面）を表示し、制作者より入力された次回作情報データ（ｃ）を、次回作データベース２０２へと格納し、鑑賞者端末へ送信する一連の処理であり、
   （※これは、依頼作品情報と、広告情報を明確に区分する）
   受注処理（１５）は、鑑賞者の「購入する・しない」、制作者の「制作する・しない」の合意の信号を送受信し、又、その通知をメール等により自動配信し、又、積立金サーバに信号（鑑賞者への課金処理へ）を送信する、受注に関する諸々の処理であり、
   ボタン配布処理（１６）は、過去作品の＜作品ＩＤ/タイトル/制作者等＞を認識可能とするコードを埋め込んだ「続きを見たい」ボタンを生成し、他サイトに広く設置可能とする一連の処理であり、
   搬入処理（１７）は、制作者が、完成作品を完成作品ＤＢへ格納する処理や、鑑賞者が完成作品をダウンロードする処理や、積立金DBサーバ（又決済システム）に最終決済の信号（制作者口座への振込処理へ）を送信する等の一連の処理であり、
   作品が完成して、完成作品DB３０１に格納されると、自動的に過去作品著作情報DB１０１に完成作品のデータ（A−１）が格納される処理を有する、請求項１に記載のシステム
5. 鑑賞者と制作者の契約タイミングを調整する時間調整DBサーバであって、
   データ（J−１）は、自動入札者以外の鑑賞者側の希望タイミング等のデータであって、
   前記データ（J−１）を、統計データとして算出し、制作者が、前記統計データを端末Ａにより確認できる機能であって、
   データ（J−２）は、制作者のざっくりとしたコンテンツ制作希望タイミングや制作日数時間等のデータであって、
   前記データ（J−２）は、過去作品等に付与され、鑑賞者が端末Ｂによって確認する事が可能な機能であって、
   次に、データ（J−３）は、鑑賞者の自動入札を行う設定データ＜自動入札回数、最大期限、上限金額等＞
   であって、前記データ（J−３）により、自動入札を行える機能を有しており、
   さらに、コンテンツスケジュール画面より前記鑑賞者が端末Ｂにより、
   契約タイミングの確認が容易な機能を有しており、
   前記コンテンツスケジュール画面は、データ（Ｊ−２）による購入前のざっくりしたスケジュールパターンと、
   データ（Ｊ−４）による、購入後の確実な日程（決定した完成日）であるスケジュールパターンの２つのパターン画面を有している、請求項１に記載のシステム
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   

Images