JP2004021382A - 電子作品の受発注方法およびその管理サーバー - Google Patents

Abstract

【課題】管理サーバーを介してコンピュータネットワークで結ばれた会員間において電子作品を円滑に受発注する。
【解決手段】管理サーバー２０を介してコンピュータネットワークで結ばれた会員２１、２２間において電子作品を受発注２４する方法であって、発注会員２１による電子作品の発注仕様を管理サーバー２０が公開した後、これに応募してきた会員２２の電子作品を管理サーバー２０が発注会員２１に提示するに際し、前記応募電子作品を減衰した上で提示する。
【選択図】　　　　図２

Description

【０００１】
【発明の属する技術分野】
本発明は、管理サーバーを介してコンピュータネットワーク上で電子作品を受発注する方法に関するものである。
【０００２】
【従来の技術】
従来、創作的要素の含まれる、デザイン、イラスト、絵、写真などは、それを必要とする側（利用者またはその代理を行う施工者等。以下、依頼者と呼ぶ。）に作成能力が無い場合、通常、外部デザイナーに依頼して作成することが行われている。また、近年では、インターネットに代表されるコンピュータネットワークの普及により、デザイン、イラスト、絵、写真などは、ネットワークを利用し易いことと相俟って、外部デザイナーを求める場が依頼者の活動範囲を超え、数多くのデザイナーとの取引が可能と成りつつある。しかしながら、コンピュータネットワークを利用したデザイン作品の受発注といっても、現実には、電子ファイル化したデザイン作品を電子メールにより添付して納品する程度である。
【０００３】
図１は、従来、前記依頼者が外部のデザイナーに作成を依頼する際のステップを図示したものである。
図示されているように、デザイナーはせっかく受注しても（図１の１０参照）、既知のデザイナーという限られた人材の中では、創作という自動化が困難な業務であるが故に個人の有限な時間の割り振りに左右されたり（１１）、その人材に得意、不得意などの分野が存在したり（１２）と、多くの阻害要因が存在している。また、容易に発注先が見つかった場合でも、時間的ロス（１３）は覚悟する必要があった。
さらに、発注仕様の確認、その他の打合せにも多くの時間を要し（１４）、ようやく、発注が完了したとしても（１５）、デザインが無形かつアイディア的発想を要求されるものであることから、依頼者とデザイナー間の意思伝達が不明確となり易く、出来上がったデザイン作品に不満を覚える（１６、１７）依頼者も少なくないというのが現実である。また、依頼者側の不満だけに留まらず、納期に遅れる（１８）、デザイナー側の一方的な思い込みによる仕様の無視された作品の納品（１９）など、致命的な結論に到ることもある。これは、ネットワークの普及により選択可能な人材が増えた現在でも同じことが言える。
【０００４】
【発明が解決しようとする課題】
本発明の目的は、このような創作成果物に対する依頼者の不満を解決すると共に、デザイナー等の創作者の受注機会の増大を企図するものである。
また、発注後受注に至らなかったデザイン、その他の電子作品の再利用の機会を与え、作品の死蔵を可及的に防止し、以て、創作者の安定収入と相反する依頼者のコスト負担の減少を図るネットワークシステムの構築を行うことにある。
【０００５】
【課題を解決するための手段】
本発明は、管理サーバーを介してコンピュータネットワークで結ばれた会員間において電子作品を受発注する方法であって、会員による電子作品の発注仕様を管理サーバーが公開した後、これに応募してきた会員の電子作品を管理サーバーが前記発注会員に提示するに際し、前記応募電子作品を減衰した上で提示することを特徴とするものである。
前記管理サーバーへの会員による発注仕様の伝達をファクシミリ通信で行うと共に、該通信で使用されるＴＳＩ信号に含まれる電話番号を識別子として会員認証を行うことが好ましい。
前記電話番号をキーとして予め蓄積された会員情報の検索を行うことが好ましい。
前記減衰作品の提示後、発注会員の応諾を条件として管理サーバーが正規の電子作品を送信することが好ましい。
前記正規電子作品の送信を条件として管理サーバーが課金ファイルを作成することが好ましい。
前記発注仕様の公開後または前記応募作品の提示後、前記管理サーバーが会員から寄せられた照会および／または応答を関連する会員に転送することが好ましい。
前記管理サーバーは、会員ファイルと、発注仕様ファイルと、発注仕様管理ファイルと、応募作品ファイルと、応募作品管理ファイルと、応募作品減衰ファイルとを備えることを特徴とするものである。
前記管理サーバーは、更に、課金ファイルと入金ファイルとを備えることが好ましい。
前記管理サーバーは、前記応募作品の発注処理完了後、応募会員の意思に基づき応募作品を蓄積しておくためのライブラリー作品ファイルと、その管理ファイルであるライブラリー作品管理ファイルとを備えることが好ましい。
【０００６】
【発明の実施の形態】
以下、本発明に係る電子作品の受発注方法の好適な実施形態を説明するが、始めに本発明方法の全体像を図２を参照しながら説明する。
本発明において「電子作品」の範疇には、図案、絵、写真、ロゴを含むデザインの他、設計図、企画書、楽曲、映像（動画）、その他、コンピュータネットワーク上で受け渡しできるものが含まれる。
本発明は電子作品の受発注を管理するサービス提供者の管理サーバー２０によって実現されるものであり、本発明には、発注者となる依頼者（２１）と未知の遠隔地（近接地でも良い）の複数のデザイナー（２２）との間における、コンペティション方式によるデザイン受発注方法（２４）と、発注仕様等の打合せに要する時間を短縮可能なコンピュータネットワークを利用した打合せ方法（２５）と、電子作品の提供方法（２６）と、コンペティション方式によって発生した余剰デザインの共有ライブラリ化方法（２７）とが含まれる。
また、本発明には、前記デザインの作成と利用対価をネットワーク上で随時、確認することのできる決済方法（２８）が含まれる。
【０００７】
本発明方法では、依頼者（２１）がデザイン仕様の発注に当り、ファクシミリ装置による入力（２３）を利用可能なものとして利便性を向上させている。
このファクシミリ装置による入力（２３）を説明する前に、ファクシミリ装置における通常の通信手順を示す信号シーケンス図である図３を参照しながら、その標準的な通信手順を説明する。
【０００８】
標準的なファクシミリ通信の手順は、送信側ファクシミリ装置３１０から、ＣＮＧ信号３２１を受信側ファクシミリ装置３４０に送信し、これに応答して受信側ファクシミリ装置３４０はＣＥＤ信号３２２を送信し、このＣＥＤ信号３２２に続いてＮＳＦ信号、ＣＳＩ信号、フレーム構成のＤＩＳ信号３２３を送信する。このＤＩＳ信号により受信側ファクシミリ装置３４０が持つ機能を送信側ファクシミリ装置３１０に通知する。ここでは、このＤＩＳ信号３２２によりカントリーコード、言語情報、キャラクタコード受信の可／不可、受信可能なキャラクタコードが送信側ファクシミリ装置２１０に対して通知される。
次いで、送信側ファクシミリ装置３１０は、必要に応じて送信端末であるＴＳＩ信号３２４を送信し、続いて受信側ファクシミリ装置３４０に対して機能を指定するためのＤＣＳ信号３２５を送信する。そして、このＤＣＳ信号の送信後に、トレーニング信号を送信し、ＴＣＦ信号３２６によりトレーニングのチェックを行う。
このトレーニング後、受信側ファクシミリ装置３４０は、ＣＦＲ信号３２７を送信し、送信側ファクシミリ装置３１０に対してファシクミリメッセージの送信を促す。送信側ファクシミリ装置３１０は、ＣＦＲ信号２２７を受信すると、トレーニング信号に続けてファクシミリメッセージ３２８を送信し、このファクシミリメッセージの送信が終了すると、ＥＯＰ信号３２９を送信する。そして、受信側ファクシミリ装置３４０は、ＥＯＰ信号３２９を確認したことを示すＭＣＦ信号３３０を送信し、送信側ファクシミリ装置３１０が、ＭＣＦ信号３３０を受信すると、切断を指示するためのＤＣＮ信号３３１を送信し終了する。
【０００９】
前記必要に応じて使用されるＴＳＩ信号３２４には、通常、送信者側の電話番号が用いられるが、本実施形態ではこのＴＳＩ信号３２４を識別子として利用し、ファクシミリ通信により送られてくるファクシミリ画像を整理、管理しようとするものである。
図４は、本発明を実施するサービス提供者が設置するファクシミリ送受信機能を備えた管理サーバーにおける、ファクシミリ信号の識別手順を示すフロー図である。
まず、予め登録された会員であるデザインの発注依頼者からファクシミリ信号が受信４０される。この受信４０を受けた管理サーバーは、着信（ＣＮＧ信号）の有無を判断４１し、着信を確認した場合にはＣＥＤ信号を返信４３する。着信が確認されなかった場合には受信待機状態４２を続ける。
【００１０】
管理サーバーは、ＣＥＤ信号を返信４３すると同時に、図３で説明した如く自機能である各種データ４４を通知し、送信者側に受信機能を知らせ、送信者側から送られて来るＴＳＩ信号３２４を待つ。
送信者側は、この信号により受信者側の受信機能を知り、該機能に合せた信号の発信を準備し、先ず初段の信号としてＴＳＩ信号３２４を送信する。このＴＳＩ信号３２４を受信４５した管理サーバーは、ＴＳＩ信号３２４の持つ内容である送信者側電話番号を取り出し、登録者であるかどうかを判断４６する。ここで「登録者でない」と判断された場合、管理サーバーはＤＣＮ信号を送信４７し、以後の受信を拒否する。他方、「登録者である」と判断された場合は、次の受信作業４８へと移行する。
【００１１】
図５は管理サーバーにおけるＦＡＸ画像の受信・格納手順を示すフロー図であり、前記図４で説明した後半の手順を一部重複して記載している。即ち、ＴＳＩ信号３２４の受信により発信元の電話番号を取得５０１した管理サーバーは、予め登録してある会員の電話番号であるかどうかを判断４６する為、登録者ファイル５０４に問い合わせ、受信作業４８に移行するか、終了４７するかを判断する。会員と認められた受信信号はファクシミリ受信作業４８へ移行されるが、この部分については図６を用いて後述する。
会員と認められた受信信号つまり電話番号は、登録者ファイル５０４に照会されると同時に登録者の情報を取得５０６される。本実施形態では登録者ＩＤを取得し、該ファクシミリ信号の管理番号として、後述のレコード番号の取得まで一時的な管理キーとして使用する。この管理番号は、発信元の電話番号であっても良いし、その他、会員が識別可能なものであれば良い。
【００１２】
受信され、管理用ＩＤを得たファクシミリ信号（以後、仕様画像と呼ぶ）は、仕様画像管理ファイル５０８に新規追加情報として登録５０７され、同時に前記登録者ＩＤ及び取得日付、仕様画像枚数（ファクシミリページ数）などの書込５０９が行われる。
次いで、該ファイル５０８よりレコード番号（ユニークな整理用番号であれば良い）を取得５１０し、Ｗｅｂファイル（ｇｉｆ、ｐｎｇ、ｊｐｅｇ等のファイル）にページ毎に変換５１１後、前記レコード番号にページ番号を組み合わせた所定のファイル名を付け５１２、仕様画像ファイル５１３に蓄積する。この際、前記の仕様画像管理ファイル５０８に該ファイル名の全てが登録される。また、該仕様画像をＷｅｂ上で公開できるように、Ｗｅｂ画面を作成５１４し、そのＵＲＬを会員である各デザイナーに通知５１５する。
【００１３】
次に、図６を用い管理サーバーにおけるファクシミリ受信手順４８を説明するが、この受信手順４８は前記図３に示したファクシミリ信号の受信部分に相当する。
即ち、図５の判断子４６により「登録者である」と判断された場合、管理サーバー内にあるファクシミリ受信処理手段は、引き続き送信者側からのファクシミリ信号を受信し、送信側も引き続きファクシミリ信号を送信する。送信側は、ＤＣＳ信号を送信６０１、引き続きトレーニング信号を送信６０２、ＴＣＦ信号によるトレーニングチェック６０３へと続く。該信号を受信し異常が無い場合、受信側は「ファクシミリメッセージ送信の許可」（ＣＦＲ）を送信６０４し、送信側はトレーニングに問題が無いと判断６０５、再度のトレーニング信号の送信６０６に続き、ファクシミリメッセージの送信６０７を始める。この間、受信側は受信状態にあり、送信側のファクシミリメッセージの送信終了信号ＥＯＰの送信６１０を監視６０８し、ＥＯＰの受信の際は、送信終了信号確認信号であるＭＣＦ信号を送信６１１する。このＭＣＦ信号を受信した送信側は、ＤＣＮ信号の送信６１２を最後に、送信を終了６１３する。これ以後、管理サーバー内にあるファクシミリ受信処理手段は、該ファクシミリ信号に対しては終了６１４するが、待機状態となり次の受信を待つ。
【００１４】
上述の説明は、会員である依頼者がファクシミリ装置によって手軽に発注仕様を管理サーバ―に送信するための方法に関するものであり、この方法は、会員がコンピュータ等の操作に不慣れな場合を想定したものである。しかしながら、コンピュータ操作に慣れた会員に対しては、電子メールやＦＴＰによる発注仕様や仕様画像の転送方法を採用することもできる。これを図７から図１０を参照しながら説明する。
【００１５】
図７は、発注仕様や仕様画像（以下、仕様画像で代表する。）を電子メールに添付したファイルにより転送する方法を説明したものである。
会員７００は、電子メールに添付可能なファイル形式で仕様画像を作成し、ネットワークに接続されたコンピュータからメーラーを起動７０１し、サービス提供者側の指定するメールアドレス宛に目的の仕様画像を添付７０２して、送信７０３する。この電子メールを受信したサービス提供者側のメールサーバー７１０は、常時、管理サーバー２０により監視７２１されており、その到着７２２を管理サーバー２０は即座に感知する。この管理サーバー２０の監視ターゲットは、サービス提供者側の指定するメールアドレス用ボックス７１１（Ａ−ＭａｉｌＢｏｘ）である。
管理サーバー２０は電子メールを取得７２３後、送信者等の解析７２４を行い、送信者のメールアドレスが予め登録された会員のものか否かを判断７２５する。ここで、「登録者のものでない」と判断された場合、不明なメールとして、送信者側より返信されてもよいように事故担当者名の電子メールアドレス用ボックス７１２（Ｂ−　ＭａｉｌＢｏｘ）より転送７２６される。一方、「登録者のものである」と判断した場合には、メールから目的の仕様画像を分離７２７する。
【００１６】
続いて、仕様画像の登録・公開処理を図８を用いて説明する。
前記分離処理７２７により分離された情報については、管理サーバー２０は再度発信元のメールアドレスを取得８０１後、登録者ファイル５０４を参照して登録者か否かの確認８０２を行い、登録者の場合は、登録者ファイル５０４の登録データより登録者ＩＤを取得８０５し、これを次述するレコード番号の取得まで一時的な管理キーとして使用する。仕様画像とその関連データとは、仕様画像管理ファイル５０８により関連付けられて管理され、電子メールで受信した仕様画像１つに付き１レコードの管理レコードが付与８０６される。また、ページ分離されたものも該１レコードの管理下になる。該１レコードの管理レコードには、前記取得された登録者ＩＤやその他登録者データの必要項目、該１レコードが生成された日時などが、該１レコード生成と同時に書込８０８される。
この該１レコード生成及び書込み後、データベースが自動的にレコード毎に付与するレコード番号を、該１レコードの整理番号として書込み８０９、以後の仕様画像と仕様画像管理レコードの共通キーとする。尚、この整理番号は、ユニークな値付けの可能なものであれば、該レコード番号でなくても構わない。
【００１７】
一方、電子メールより分離された仕様画像は、インターネットブラウザ上で表示されることを前提に、インターネットブラウザ対応のファイル形式に変換８１０され、ファイル名を前記の整理番号名に変換（リレーション化）され仕様画像ファイル５１３に蓄積８１１される。管理サーバー２０は蓄積後、予め用意された仕様画像表示画面用のＵＲＬと該データの個別のＵＲＬを組み合せたＵＲＬを作成８１３し、該ＵＲＬを記載した新規仕様の登録を通知するメールを会員デザイナーに送信８１４する。
【００１８】
次に、ＦＴＰ方式による仕様画像の転送方法を、図９を用いて説明する。
会員９００は、ネットワークに接続されたコンピューターからＦＴＰを起動９０１し、サービス提供者側の指定するＦＴＰ−Ｂｏｘ宛９１１に目的の仕様画像を指定９０２し、送信９０３する。このＦＴＰを受信したサービス提供者側のＦＴＰサーバー９１０は、送信者側の接続の際、パスワードのチェックを行い、予め登録された会員か否かを確認９１２する。会員と認められた場合のみ転送可能となり、送信者側は転送終了９０４する。
このＦＴＰ転送を許可したサービス提供者側のＦＴＰサーバー９１０は、管理サーバー２０により、サービス提供者が指定した会員毎の固有ボックス（ディレクトリ）９１１を常時監視９２１されており、管理サーバー２０はその転送（着信）を即座に感知９２２することができる。管理サーバー２０は、送られて来た仕様画像を取得９２３し、固有のボックス９１１に関連付けられた登録者ファイル５０４と照合し、登録者（転送者）との関連付けを行う。
【００１９】
次に、図１０を参照しながら、仕様画像と関連データとの関連付けを説明する。
登録者（転送者）との関連付けが行なわれた仕様画像は、登録者ファイル５０４の登録データより登録者ＩＤを取得し、後述のレコード番号の取得まで一時的な管理キーとして使用し、目的の仕様画像は関連データと関連付けられ管理される。仕様画像と関連データとの関連付けは、仕様画像管理ファイル５０８により管理され、ＦＴＰ受信仕様画像１つに付き１レコードの管理レコードが付与１００２される。尚、ページ分離されたものも該１レコードの管理下になる。
該１レコードの管理レコードには、前記取得された登録者ＩＤやその他登録者データの必要項目、該１レコードが生成された日時などが、該１レコード生成と同時に書込１００３される。
この該１レコード生成及び書込み後、データベースが自動的にレコード毎に付与するレコード番号を、該１レコードの整理番号として書込み１００４、以後の仕様画像と仕様画像管理レコードの共通のキーとする。尚、この整理番号は、ユニークな値付けの可能なものであれば、該レコード番号でなくても構わない。
一方、仕様画像はインターネットブラウザ上で表示されることを前提に、インターネットブラウザ対応のファイル形式に変換１００５され、ファイル名を前記の整理番号名に変換（リレーション化）され仕様画像ファイル５１３に蓄積１００６される。管理サーバー２０は蓄積後、予め用意された仕様画像表示画面用のＵＲＬと該データの個別のＵＲＬを組合せたＵＲＬを作成１００７し、会員デザイナーに新規仕様の登録を通知するメールを送信１００８する。
【００２０】
上述した３方法により仕様画像を管理サーバー２０に送信した会員は、指定ＵＲＬ、パスワード入力等、所定の操作を経て、自端末のモニターで送信した仕様画像が受理されたかどうかを確認することができる。
図１１は会員の自端末のモニター画面１１００であり、同画面１１００には自分の会員名１１０１、管理サーバーによって受理された仕様画像群１１０２などと共に、タイトル表示１１０３及び納期を示す期日表示１１０４が表示されている。また、これらの情報が未入力のタイトル未設定ボタン１１０５及び期日未設定ボタン１１０６も表示されている。会員はモニター画面１１００から、必要に応じて、その整理された仕様画像に対して、補足情報を追加入力することができ、タイトル未設定ボタン１１０５または期日未設定ボタン１１０６をクリックして入力画面を表示させ、所定事項を入力する。
このようにして管理サーバーに登録された各仕様画像はその仕様に基き、会員デザイナーに閲覧されるので、これを閲覧したデザイナーは、自分の得意、不得意または嗜好を選択し、また余裕時間なども考慮した上で、コンペティションに応募することができる。
【００２１】
図１２は、登録された仕様画像を会員デザイナーが閲覧する手順を示すフロー図であり、デザイナー側と管理サーバー２０のフローにより構成されている。
デザイナーが管理サーバー２０にアクセス１２１０する方法には、少なくとも２通りあり、１つは図５で説明した会員デザイナー宛の通知メールに記載されたＵＲＬから指定の画面に到達１２１１する方法であり、もう１つは、管理サーバー２０を運用するサービス提供者のホームページ１２１２から到達する方法である。いずれの方法においても、予め割り当てられたかまたは取得したパスワードを入力１２１３し、送信１２１４された入力信号が管理サーバー２０に受信されて、登録済の会員であるか否かが判断１２２１される。
ここで、ホームページ１２１２経由でアクセスしてきた会員であると認定された場合は、管理サーバー２０によりどの仕様画像を閲覧するかを選択する為の検索画面が送信１２２３され、表示１２１５される。会員デザイナーが該画面に検索条件を入力して送信すると、管理サーバー２０は仕様画像を検索１２２４し、検索結果を一覧とした仕様画像一覧画面を送信１２２５する。また、会員デザイナー宛の通知メールに記載されたＵＲＬ経由でアクセスしてきた会員であると認定された場合は、管理サーバー２０は会員デザイナーに通知メールに指定してある仕様画像または仕様画像一覧を送信１２２５する。上記いずれにも該当しない場合は、管理サーバー２０によりログイン拒否画面１２２２が送信され、閲覧不可能となる。
【００２２】
図１３には、前記会員デザイナーの操作により閲覧が認められた場合の表示画面例が示されており、同図には、図１１で説明した項目の他、質問メールボタン１３０１と応募ボタン１３０２が付加されている。ただし、図１１に表示されたタイトル未設定ボタン１１０５と期日未設定ボタン１１０６は表示されておらず、画面中央にはマウス矢印１１０６が表示されている。
この画面を閲覧したデザイナーが、仕様書一覧の中から画像を自由に選択すると、右の吹き出し内に表示されている画面１３０３の如く、選択された特定の仕様画像が拡大表示されると同時に、関連する仕様画像がリンク表示用のページボタン１３０４となって表示される。このリンク表示用のページボタン１３０４をクリックすることにより、関連仕様画像の閲覧が可能となる。
質問メールボタン１３０１は、その上部に表示された仕様画像の発注者に対し、デザイナーが仕様確認等に関するメールを送信する為のボタンである。質問メールボタン１３０１をクリックすることにより送信されるメールは、図１４の説明において後述するように、発注者に直接送信されるのではなく、管理サーバー２０宛に送信され、データベース化された後、発注者宛に送信されるものである。また、応募ボタン１３０２は、デザイナーが画面上部に表示される仕様画像について応募し、作成した作品をアップロードする為のボタンであり、詳しくは図１５を用いて後述する。
【００２３】
図１４を参照しながら、質問メールボタン１３０１の作用について説明する。前記のように質問メールボタン１３０１は、仕様確認等に関するメールを直接デザイナー側から発注者宛に送るのではなく、サービス提供者の管理サーバー宛に送り、質問内容を保管した後該当する発注者宛に送る、というシステムを採っている。これは、両者が直接メールを交換し合う際に発生しがちなトラブルを回避することを目的としたものである。従って、図１４は、サービス提供者を媒介とし、デザイナー側、依頼者側の３ブロックから構成されている。
図１３の仕様画像に関してデザイナーが照会しようとする場合には、質問メールボタン１３０１をクリックして質問入力画面を表示させる。この過程は、図１４において、デザイナーが指定画面を閲覧１４１１した後、指定個所（即ち、質問メールボタン１３０１）をクリック１４１２して、要求信号を送信１４１３すると、この要求信号を受信した管理サーバーは、質問事項書込み画面を送信１４２１し、デザイナーのモニターに質問入力画面を表示１４１４させる、というステップになる。次いで、質問者であるデザイナーが質問事項を入力１４１５し管理サーバーへ送信１４１６すると、該信号を受信した管理サーバーは、メール内容を日時、送信者、宛先などの必要情報と共に所定のファイルに保存１４２２し、この後、前記宛先を基に電子メールを作成１４２３し、メールサーバーを仲介（１４２５、１４２６）して、発注者宛に送信１４２４する。
この電子メールを受信１４３１した発注者は、同様の方法により必要に応じて回答を寄せることができる。
【００２４】
上記やり取りされた質問内容及び回答などは、掲示板、その他の方法により公開することが他のデザイナーの為にも好ましい。また、そのためには質問内容及び回答などをデータベース管理する必要があることから、前記デザイナーと管理サーバー間の質問メールは、電子メールによる送受信信号ではなく、ＨＴＭＬ等による送信方法が望ましい。
【００２５】
上記した手順により、会員デザイナーは仕様画像に合せたデザイン作品を作成し、所定のファイル形式にて管理サーバーに送信することによりコンペティションに参加する。
図１５は、その応募方法を説明したフロー図である。同図において、「指定画面へ」１５１１とあるのは、図１３に示したモニターの表示画面であり、「指定個所のクリック」１５１２とあるのは、図１３に示した応募ボタン１３０２のクリックを指している。このクリックにより出された送信信号１５１３を受けた管理サーバーは、デザイナーによって選択された応募ボタン１３０２に相当する仕様画像に関する応募画面を送信１５２１し、デザイナーの端末モニターに表示１５１４させる。表示画面の案内に従い、デザイナーが応募しようとするデザイン作品のファイル名を指定１５１５すると共に、必要に応じて、一時的または専用的な許諾金額、その他を入力１５１６し、送信者ＩＤなども入力して、送信ボタンにより送信１５１７する。この際の送信方法は、通常のブラウザ画面で対話形式の入力が可能なことから、ＦＴＰ／ＨＴＭＬ等による方法１５１８が望ましい。また、この際の「デザイン作品のファイル名」は任意のもので良い。
該信号を受信した管理サーバーは、パスワードなどによる登録者管理１５２２を行い、もし、登録者でなかった場合は接続を拒否１５１９する。また、登録者と認められた場合は、送られて来たデザイン作品（以下、応募画像と呼ぶ）のファイル名を管理サーバー内で統一する為、所定のファイル名に書き換え１５２３、先の許諾金額などの入力文字情報と関連付けた形１５２４で、応募画像は応募画像ファイル１５３１に、入力文字情報は応募画像管理ファイル１５３２に夫々蓄積する。
【００２６】
図１６は、発注者が応募状況を参照するための画面例であり、上記応募画像と入力文字情報が仕様画像と共に閲覧可能となる。また、この画面は、自分が応募した作品の応募状況を確認したいデザイナーからの閲覧も可能である。但し、この画面に表示される応募画像は管理サーバーによって減衰処理されたものである。
ここで減衰した応募画像とは、インターネットの特性である画面上に表示された画像のダウンロード機能により、課金されることなく応募画像をダウンロードされることに対する対策である。つまり、この一覧にある応募画像をダウンロードしても、使用に耐えない画像を表示することにより、この画面からのダウンロードを無意味なものにし、正規の作品を入手するために後述する課金を必須のものとするためである。
【００２７】
図１６には、図１３で説明した仕様画像に関する表示１６１と、応募者全員の応募画像を減衰処理した画像の一覧１６２が表示されており、応募画像の一覧１６２には前記した入力文字情報１６３と質問メールボタン１６４も含まれる。質問メールボタン１６４は、表示された当該応募画像に対して、発注者としての追加または変更等に関する希望事項や要求を送信するためのものであり、この質問メールの送信手順は図１７に示すように、図１４とほぼ同様の方法で発信され、かつ、回答される。図１７において、依頼者とデザイナーとを置き換えれば図１４となる。重複を避けるために図１７の説明は省略するが、図１６の質問メールボタン１６４は図１３の質問メールボタン１３０１と同様、単に直接メールを送受信するものではない。
【００２８】
次に、図１８を用い、発注者が図１６に表示された応募画像の一覧から、任意の応募画像を選定し、受け取る手順を説明する。
発注者は、図１６で説明したように、自分が発注した特定の仕様画像ページを閲覧するための手順１８１１から、管理サーバーに特定の仕様画像ページを要求し、管理サーバーは、要求のあった指定画面を送信１８２１し、発注者端末に表示１８１２させる。この表示画面が図１６に相当する。
この際、表示される応募画像は、図１６でも説明したように、減衰処理した表示専用の応募画像であり、この画像は送信画面生成の際、応募画像管理ファイル１５３２に関連付けられた画像を応募画像減衰ファイル１８３１の中から指定する。ただし、この減衰された応募画像は、この送信時に生成する方法を採っても良いし、図１５を用いて説明したアップロードの際に生成する方法でも良い。また、ここでいう減衰とは、その状態では発注者にとって利用価値がないことを意味し、必ずしも一般にいう色数の減色や画像サイズの縮小によるファイル容量の減少だけを意味するものではない。
また、発注者の画面要求により指定された仕様画像は、仕様画像管理ファイル５０８に関連付けられた仕様画像を仕様画像ファイル５１３の中から指定する。
【００２９】
発注者が、表示された画面の中の応募画像一覧より任意の応募画像の金額部分をクリック１８１３することにより、その応募画像のダウンロード手順に入る。管理サーバーはこの信号を受け、まず最初に、該当の応募画像が発注者の指定期限を過ぎているかをチェック１８２２し、過ぎていれば使用許諾規約画面を送信１８２３、発注者はその端末に表示１８１４された規約を読み、承諾する場合は承諾ボタンをクリック１８１５し、正規の応募画像の表示要求を出す。尚、指定の期限内であった場合は、元の画面（図１６）を送信し直す。
この要求を受けた管理サーバーは、減衰処理されてない元の応募画像を応募画像ファイル１５３１から呼び出し、ダウンロード画面として送信１８２４し、発注者端末に表示１８１６する。
表示された正規の応募画像に対し、発注者はインターネットによる通常のダウンロード操作１８１７を行い、管理サーバーは指定のダウンロードファイルを送出１８２５する。
【００３０】
このダウンロードが正常に終了１８１８すると、管理サーバーは、課金処理１８２６に入る。課金処理は、先にクリックされた応募画像毎に持つ金額を保持しておき、他の必要事項（日時やダウンロード者ＩＤなど）と一緒に課金ファイル１８３２に課金情報として蓄積するものである。
課金処理の終了後、管理サーバーは、発注者端末（ダウンロード者）に対し正常に課金されたこと、その金額の確認などを知らせる課金のお知らせ画面を送信１８２７、発注者端末側はこれを確認１８１９する。この確認画面には、同時に応募され、前項の操作によりダウンロードされなかった他の応募画像を、引き続き、ダウンロードするかどうかの案内が表示されており、再度他の応募画像をダウンロードするかどうか選択１８２０出来る。「ダウンロードする」場合は、選択画像の表示画面１８１２が表示され、前項の操作を繰り返すことにより、２つ目の応募画像、３つ目の応募画像と複数のダウンロードが可能である。また、「ダウンロードしない」場合は、ここで該作業は終了する。
【００３１】
この後、前記の選定から洩れた応募画像作品については、管理サーバーが「不採用」をメールにより各応募者（デザイナー）に告知する。該応募者は、必要により該不採用応募画像の固有部分（ロゴ、会社名、指定コピーなど）を変更後、いつでも自由に使用可能な画像ライブラリーへとアップロードすることができる。
この管理サーバーと各応募者（デザイナー）によって行われる不採用応募画像のライブラリー化手順を、図１９を用い説明する。
図１９は図１８のフローから連続する処理手順であり、課金終了に続いて、管理サーバーは、採用結果を各応募者（デザイナー）に知らせるための結果通知処理１９００に入る。
先ず、管理サーバーは各応募画像について採用、不採用の状態を確認１９１０し、「採用応募画像」の場合は、「専用仕様」か「一時使用」かを判断１９２０する。ここで専用使用契約であると判断された場合、予め用意された専用使用採用告知メール文に、該当の仕様画像のタイトルを入れ１９３１、応募者（デザイナー）に通知１９３２する。通知後、応募画像ファイル１５３１より該当作品（応募画像）を削除１９３３し、続いて応募画像管理ファイル１５３２から該当応募画像の関連レコードを削除１９３４して、終了する。
一方、一時使用契約であると判断された場合は、予め用意された一時使用採用告知メール文に、該当の仕様画像のタイトルを入れ１９４１、応募者に通知１９４２する。通知後、応募画像ファイル１５３１より該当作品（応募画像）を削除１９６１し、続いて応募画像管理ファイル１５３２から該当応募画像の関連レコードを削除１９６２して、終了する。
【００３２】
さらに、各応募画像について採用、不採用の状態を確認１９１０し、「不採用応募画像」の場合は、予め用意された不採用告知メール文に、該当の仕様画像のタイトルを入れ１９５１、応募者に通知１９５２する。通知後、応募画像ファイル１５３１より該当作品（応募画像）を削除１９６１し、続いて応募画像管理ファイル１５３２から該当応募画像の関連レコードを削除１９６２して、終了する。
これらの処理により、「一時使用告知メール文」または「不採用告知メール文」を受け取った１９７１応募者は、必要により該当する応募画像の固有部分（ロゴ、会社名、指定コピーなど）を一般的なものに変更１９７２し、サービス提供者の指定する画面よりアップロード１９７３する。このアップロード操作手段は、図１５を用い説明した「デザイナー側の応募手段」と、ほぼ同様であるため、図１９にライブラリー作品ファイル１９８０と、ライブラリー作品管理ファイル１９８２と、これらの関連付け１９８１を図示してその説明を省略する。一方、「専用使用告知メール文」を受け取った応募者は、再利用すべきライブラリー化作業は無く、専用使用料金の決済を待つのみとなる。
上記処理以後、応募画像はライブラリー機能によって利用され、仕様画像は確認のみを目的として履歴閲覧に利用される。
【００３３】
最後に、上記デザイン作品の受発注に伴う決済状況の確認方法について説明する。本発明方法では、受発注者共、課金状態をリアルタイムで確認することができる。
図２０は時系列のフローとして表記されているが、これは説明の便宜上のためであって、各状況は個々に閲覧することが可能である。
発注者は基本的に、利用課金状況、支払済み状況、次期支払予定状況の３状況を閲覧することができる。これらは、課金ファイル１８３２と入金ファイル２０３１に書き込まれたデータを基にして、発注者の端末に表示させることが可能である。即ち、利用課金状況は課金履歴の確認２０１１という操作により、管理サーバーは、指定される期間などの条件に応じて課金ファイル１８３２より一覧化する処理２０２１によって可能となる。発注者はそれを閲覧２０１２すればよい。また、支払済み状況は、依頼者の支払状況の確認２０１３という操作により、管理サーバーが指定される期間などの条件に応じ入金ファイル２０３１より一覧化する処理２０２２により可能となる。さらに、次期支払予定状況は、依頼者の当月請求の確認２０１５という操作により、管理サーバーが、該操作時点以後の指定された締め日などの条件により課金ファイル１８３２と入金ファイル２０３１に書き込まれたデータを時系列的に一覧化をする処理２０２３を行うことにより可能となる。
また、デザイナーに対する対価の支払に関しても、前記課金ファイル１８３２と入金ファイル２０３１を基にして、同様の方法によって、利用課金状況、支払済み状況、次期支払予定状況をデザイナーの端末に表示させることが可能である。
【００３４】
【発明の効果】
本発明方法によれば、管理サーバーを介してコンピュータネットワークで結ばれた会員間において電子作品を迅速かつ極めて円滑に受発注することができる。また、デザイナー等の創作者の受注機会を増大させることができる。
【図面の簡単な説明】
【図１】外部デザイナーにデザイン作成を依頼する際の従来の手順図である。
【図２】本発明に係る電子作品の受発注方法の全体概要図である。
【図３】ファクシミリ装置の標準的な通信手順を示す信号シーケンス図である。
【図４】管理サーバーにおけるファクシミリ信号の識別手順を示すフロー図である。
【図５】管理サーバーにおけるＦＡＸ画像の受信・格納手順を示すフロー図である。
【図６】管理サーバーにおけるファクシミリ受信手順を示すフロー図である。
【図７】電子メール添付ファイルによる仕様画像の転送手順図である。
【図８】管理サーバーにおける仕様画像の格納手順図である。
【図９】ＦＴＰ方式による仕様画像の転送手順図である。
【図１０】管理サーバーにおける仕様画像の格納手順図である。
【図１１】送信した仕様画像を確認する時の発注会員のモニター画面である。
【図１２】登録された仕様画像を会員デザイナーが閲覧する手順を示すフロー図である。
【図１３】会員デザイナーが仕様画像を閲覧する時の表示画面例である。
【図１４】会員デザイナーからの仕様確認メールに関する管理サーバーにおける処理フロー図である。
【図１５】会員デザイナーによって応募されたデザイン作品を管理サーバーが受理する際の手順図である。
【図１６】発注会員が応募状況を参照する時のモニター画面例である。
【図１７】発注会員からのデザイン作品に対する要望メールに関する管理サーバーにおける処理フロー図である。
【図１８】発注会員によるデザイン作品のダウンロード手順を示すフロー図である。
【図１９】管理サーバーにおける不採用デザイン作品のライブラリー化手順を示すフロー図である。
【図２０】受発注に伴う決済状況の確認方法を説明するためのフロー図である。
【符号の説明】
２０　管理サーバー
２１　会員発注者
２２　会員受注者
２３　ファクシミリ装置による入力
２４　電子作品の受発注
２５　ネットワークを利用した打合
２６　電子作品の提供
２７　共有ライブラリ化
２８　決済
５０４　登録者ファイル
５０８　仕様画像管理ファイル
５１３　仕様画像ファイル
１５３１　応募画像ファイル
１５３２　応募画像管理ファイル
１８３１　応募画像減衰ファイル
１８３２　課金ファイル
２０３１　入金ファイル

Claims (9)

1. 管理サーバーを介してコンピュータネットワークで結ばれた会員間において電子作品を受発注する方法であって、会員による電子作品の発注仕様を管理サーバーが公開した後、これに応募してきた会員の電子作品を管理サーバーが前記発注会員に提示するに際し、前記応募電子作品を減衰した上で提示することを特徴とする電子作品の受発注方法。
2. 前記管理サーバーへの会員による発注仕様の伝達をファクシミリ通信で行うと共に、該通信で使用されるＴＳＩ信号に含まれる電話番号を識別子として会員認証を行う請求項１記載の電子作品の受発注方法。
3. 前記電話番号をキーとして予め蓄積された会員情報の検索を行う請求項２記載の電子作品の受発注方法。
4. 前記減衰作品の提示後、発注会員の応諾を条件として管理サーバーが正規の電子作品を送信する請求項１記載の電子作品の受発注方法。
5. 前記正規電子作品の送信を条件として管理サーバーが課金ファイルを作成する請求項４記載の電子作品の受発注方法。
6. 前記発注仕様の公開後または前記応募作品の提示後、前記管理サーバーが会員から寄せられた照会および／または応答を関連する会員に転送する請求項１記載の電子作品の受発注方法。
7. 会員ファイルと、発注仕様ファイルと、発注仕様管理ファイルと、応募作品ファイルと、応募作品管理ファイルと、応募作品減衰ファイルと、を備えた請求項１記載の電子作品の受発注方法を管理するサーバー。
8. 更に、課金ファイルと入金ファイルとを備えた請求項７記載の電子作品の受発注方法を管理するサーバー。
9. 前記応募作品の発注処理完了後、応募会員の意思に基づき応募作品を蓄積しておくためのライブラリー作品ファイルと、その管理ファイルであるライブラリー作品管理ファイルとを備えた請求項８記載の管理サーバー。

Images