コンピュータシステム
媒体によって利用者へ伝達され、ユニットを販売するための電話またはインターネットを基本としたリバースオークションを運営する方法であって、販売するいくつかのユニットを提供し、販売に供される数を最初に示す割り当てデータベースに暫定利用可能数量を格納するステップと、前記リバースオークションに参加するために利用者が電話または注文をすることのできる電話番号またはウェブサイトを提供するステップと、前記電話番号または前記ウェブサイトに１つまたは複数の着呼または注文が受信された時刻をレコードデータベースに記録するステップと、ユニットを販売するために、発呼者をいずれも待ち行列に配置し、その発呼者をコールオペレータまたはシステムに割り当てるステップと、人またはシステムが前記示されたユニットの価格を一定の期間にわたって下げ、プロデューサまたはシステムが前記暫定利用可能数量を減らすリバースオークションを運営するステップとを含み、前記リバースオークションは、前記暫定利用可能数量がゼロなどの所定の数まで減った時刻に終了するとともに、前記終了時の価格はオークションデータベースに格納され、前記暫定利用可能数量は、前記オークションのタイミングに対する前記着呼レコード内の前記着呼または注文の受け付け時刻などの、着呼／発呼者と関連づけられた１つまたは複数の暫定指標に少なくとも部分的に基づいて減らされ、前記指標はユニットの販売が完了／確定する前に発生する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オークションを運営するためのシステムおよび方法に関し、特に、電話および／またはテレビおよびインターネットによるリバースオークションに関する。
【背景技術】
【０００２】
テレビまたはその他の媒体を使用して商品を販売しようとする試みが知られている。これは典型的には、商品をそれに伴う価格と共にテレビに示すことによって行われる。このとき、商品の販売者は、誰もが電話をかけ、テレビに表示されている商品を購入できるようにする。このようなシステムでは、利用者の電話を随時許可することも可能であるし、商品が画面上に示されている間に限って利用者の電話及び注文を許可することも可能である。前者のシステムでは、電話をかけようと人を駆り立てる期間がなく、また、利用者は、売りに出されている複数の商品を次々と簡単に見てから、商品を購入するかどうかを決定することができるという不利な点がある。後者のシステムは、商品をすぐに購入しようと人を電話に駆り立てる刺激を与えるのに役立つが、その商品が画面に映されている間に、一定の通話数しか処理することができないという不都合がある。したがって、単一の商品の販売に要する全期間にわたって、テレビ放送帯の容量と電話網の容量を両方とも同時に消費しなければならない。これは理屈の上からいっても効率的ではない。
【０００３】
英国では、テレビ上で流動的な価格を扱うオークションを運営しようとする試みも知られている。これによると、人に電話をかけるタイミングを与えるよう刺激するという利点が得られる。しかしこの場合、利用者は注文、購入および登録の各プロセスを経るが、それを行うのにかなりの時間がかかるので、電話網の容量を消費してしまうという不都合がある。オークションプロセスの全容をテレビで放送する必要があることから、各競りの完了が遅くなると、オークション全体の進行が遅くなり、よって、テレビネットワークの容量が大量に消費されてしまう。これに対する１つの代替策は、事前登録された利用者だけ競ることを許し、これにより、オークションのタイミングを早めることである。この代替策には、登録していない利用者はオークションに参加することができないという不都合がある。
【０００４】
他のタイプのオークションには、リバースオークションがあるが、これをテレビ画面上で実施するには問題がある。というのは、このオークションは、全てのユニットが購入されて初めて終了するからである。最終的な価格は、最終ユニットの落札時に付けられ、場合によっては、全ての落札者に対して同じ価格になる。この方式は、利用者が登録と購入手続きを済ませるまで、ユニットの割り当てを確定することができないため、問題である。したがって、テレビなどの媒体を使用する場合、かなり時間がかかり、容量を効率よく使用することができない。
【０００５】
注文が全て完了する前に、次のユニットの販売をテレビ上で進めたとしても、利用者は前の商品のときと同じ電話番号を使用することができない。これは、電話番号が商品間の区別に使用されるので、ある特定の電話番号に電話をかけている利用者は、特定の商品を購入していると見なされるからである。その電話番号に対応する商品を注文の途中で変更すると、その利用者がどの商品を購入しようとしているのか、混乱をきたす可能性がある。
【０００６】
落札されたユニット数に対して在庫数を制御し続ける点にも問題がある。周知のオークションシステムでは、比較的に、在庫数よりも商品を売り過ぎてしまいやすい。また、商品を安売りしてしまう可能性も高い。こういった状況では、その商品の購入に興味があり、オークションに参加しようとしている利用者が他にいる可能性があっても、テレビおよび電話網の望ましい容量使用量の枠内では、商品が非効率な形で売れ残ってしまう。この問題を回避するには、各通話を継続的に監視し続ける必要がある。これにより、もしある通話が最終的に落札につながるようであれば、その電話をかけてきた利用者を売れ残った商品の再販売対象にすべきではないことがわかる。しかしながら、これは、各通話をその通話の間に渡って監視し、かつ、各通話の詳細を全て単一のデータベースエントリに格納しなければならないため、技術的に非効率でありコストもかかる。
【０００７】
インターネットを介して商品を販売するシステムも知られているが、このような利用者は、テレビ販売に付きものの対話型の商品説明が受けられない。
【発明の概要】
【０００８】
本発明は、上述したいくつかの問題を軽減することを目的とする。また、上述のいくつかの技術的な問題に対する技術的な解決策によって、より効率的なシステムを使用できるようにすることを目的とする。
【課題を解決するための手段】
【０００９】
本発明の第１の態様によれば、媒体によって利用者へ伝達され、ユニットを販売するための電話を基本としたリバースオークションを運営する方法が提供され、該方法は、販売するいくつかのユニットを提供し、販売に供される数を最初に示す割り当てデータベースに暫定利用可能数量を格納するステップと、上記リバースオークションに参加するために発呼者から電話をかけることができる電話番号を提供するステップと、上記電話番号に１つまたは複数の着呼が受信された時刻を着呼データベースの着呼レコードに記録するステップと、ユニットを販売するために、各発呼者を待ち行列に配置し、その発呼者をコールオペレータまたはシステムに割り当てるステップと、人またはシステムが上記示されたユニットの価格を一定の期間にわたって下げ、プロデューサまたはシステムが上記暫定利用可能数量を減らすリバースオークションを運営するステップとを含み、上記リバースオークションは、上記暫定利用可能数量がゼロなどの所定の数まで減った時刻に終了するとともに、上記終了時の価格がオークションデータベースに格納され、上記暫定利用可能数量は、上記オークションのタイミングに対する上記着呼レコード内の上記着呼の受け付け時刻などの、着呼／発呼者と関連づけられた１つまたは複数の暫定指標に少なくとも部分的に基づいて減らされ、上記指標はユニットの販売が完了／確定する前に発生する。
【００１０】
本発明の第２の態様によれば、ユニットのリバースオークションを運営するためのコンピュータシステムが提供され、該システムは、プロセッサと、割り当てデータベース、オークションデータベース、および着呼データベースを含んだメモリと、電話システムと、ディスプレイとを備え、上記割り当てデータベースは、オークションに提供されるユニット数を示す暫定利用可能数量を含み、上記電話システムは、上記着呼データベースの着呼レコードに着呼が受信された時刻とダイヤルされた番号を記録するように構成されるとともに、ユニットを販売するために各発呼者を待ち行列に配置して、その発呼者をコールオペレータまたはシステムに割り当てるように構成され、上記プロセッサは、上記ディスプレイに価格を表示し、上記表示された価格を一定の期間にわたって下げ、上記暫定利用可能数量を減らし、上記暫定利用可能数量がゼロなどの所定の数まで減るタイミングを判定し、その時刻で上記表示された価格を上記オークションデータベースに格納し、上記電話システムへ新しく着呼した通話が上記オークションに参加できないように構成され、上記システムは、上記オークションのタイミングに対する上記着呼レコード内の上記着呼の受け付け時刻などの、着呼／発呼者と関連付けられた１つまたは複数の暫定指標に少なくとも部分的に基づいて上記暫定利用可能数量を減らし、上記指標がユニットの販売が終了する前に発生する。
【００１１】
本発明の第３の態様によれば、テレビでリバースオークションによりユニットを販売する方法が提供され、販売するためのユニットを、最初の価格および上記ユニットの上記オークションでの販売に利用可能な数と共にテレビに表示するステップと、オークションに参加するための電話着呼を許可するステップと、販売が行われる可能性がある、また行われたという十分な指標を発呼者が示していると考えられる場合に、前記表示された利用可能な数量が減らされるステップと、より多くの発呼者を促し、上記テレビの上記オークションに費やされる時間を減らすために、上記ユニットの上記表示された価格を下げるステップと、上記表示された利用可能な数量がゼロに達すると、上記オークションを終了するステップとを含む。
【００１２】
本発明の第４の態様によれば、媒体によって利用者へ伝達され、ユニットを販売するためのインターネットを基本としたリバースオークションを運営する方法が提供され、該方法は、販売するいくつかのユニットを提供し、販売に供される数を最初に示す割り当てデータベースに暫定利用可能数量を格納するステップと、上記リバースオークションに参加するために利用者から注文を出すことができるウェブサイト購入機能を提供するステップと、上記電話番号に１つまたは複数の注文が受信された時刻を着呼データベースの着呼レコードに記録するステップと、ユニットを販売するために、各発呼者を待ち行列に配置し、その発呼者をコールオペレータまたはシステムに割り当てるステップと、人またはシステムが上記示されたユニットの価格を一定の期間にわたって下げ、プロデューサまたはシステムが上記暫定利用可能数量を減らすリバースオークションを運営するステップとを含み、上記リバースオークションは、上記暫定利用可能数量がゼロなどの所定の数まで減った時刻に終了するとともに、上記終了時の価格がオークションデータベースに格納され、上記暫定利用可能数量は、上記オークションのタイミングに対する上記着呼レコード内の上記注文の受け付け時刻などの、着呼／発呼者と関連づけられた１つまたは複数の暫定指標に少なくとも部分的に基づいて減らされ、上記指標はユニットの販売が完了／確定する前に発生することが好ましい方法が提供される。
【００１３】
上記コールオペレータまたはシステムにつながる着呼の順序が、上記着呼レコードの上記格納された時刻によって決まり、かつ／または、ユニットの販売価格が、上記オークションデータベースに格納された上記終了時の価格から決定されることが好ましい。
【００１４】
上記方法は、各発呼者にデータを１つ入力するよう促し、好ましくは、各発呼者を待ち行列に入れる前に書く発呼者にデータを１つ入力するよう促し、そのデータを上記着呼レコードに格納するステップを含むのが好ましい。更に好ましくは、上記着呼が待ち行列に配置されるかどうかが上記入力されたデータによって決まり、かつ／または、１つの暫定指標が、上記入力されたデータを含むとともに上記着呼レコードに格納され、かつ／または、１つの暫定指標が、上記データが入力され、上記着呼レコードに格納される時刻を含むとよい。
【００１５】
上記入力を促すステップは、上記利用者に、１つの番号をその利用者の電話に入力するよう促し、好ましくは、１つまたは複数の番号が暫定指標と解釈され、かつ、ゼロ、１つまたは複数の番号が暫定指標でないと解釈されるとよい。
【００１６】
提供されるユニット数および最終的な割り当てもまた、上記割り当てデータベースに格納され、最終的な販売が完了するたびに、上記最終的な割り当てが増やされ、上記システムが、上記割り当てがまだ上記提供されるユニット数を下回っているかどうか判定することによって、販売を行うことができるかどうかを決定することが好ましい。上記方法が、上記割り当ての増加に応じて上記最終的な割り当てが増加するたびに、上記着呼に対応する暫定指標によりすでに、上記暫定利用可能性が低減していることを確認し、そうでない場合は、上記暫定利用可能数量を減らすステップを含み、かつ／または、販売が確定されるたびに、支払い明細を含んだ注文レコードを作成するステップを含むことがさらに好ましい。
【００１７】
登録済み発呼者も未登録発呼者も上記オークションに参加することができることが好ましい。
【００１８】
上記方法が、発呼した電話番号を判定し、これを登録済み利用者の顧客データベースと比較し、上記比較が一致した場合、上記格納された顧客細目を上記発呼者に割り当てるステップを含み、かつ／または、暫定指標、初期および最終的な価格および／または販売数などのイベントを競りデータベースに格納するステップを含むことが好ましい。一致するものがない場合、上記発呼者に上記ユニットを販売する上記コールオペレータまたはシステムが、上記発呼者の細目を取得し、該細目をその電話番号と共に、今後使用するために上記顧客データベースに入れるステップを含み、かつ／または、個々の発呼者と関連づけられたイベントが、上記着呼データベースまたは上記顧客データベースなどの、その発呼者にリンクされた上記競りデータベースに格納され、発呼者が特定されると、予め格納されたデータが呼び出されることが好ましく、かつ／または、１つの暫定指標が、上記オークションの１つまたは複数のイベントの上記競りデータベース内の履歴イベントとの比較を含み、かつ／または、１つの暫定指標は、発呼者が頻出する消費パターン履歴を有することが判明しているといった、上記競りデータベースに格納された特定された発呼者のイベントを含むことがさらに好ましい。
【００１９】
暫定指標を示す発呼者が利用可能なユニットよりも多い場合には、該発呼者らの着呼レコードにおいて時刻がより早い発呼者に上記ユニットを販売するか、または適切な暫定指標を示す上記発呼者に上記ユニットを販売し、更に、上記適切な暫定指標を示す発呼者が利用可能なユニットよりも多い場合には、上記適切な指標をしており、より早い格納時刻を有する上記発呼者に上記ユニットを販売することが好ましい。
【００２０】
上記発呼者が発呼した時刻に上記オークションの構成要素であった上記商品もまた、上記着呼データベースに格納され、上記発呼者が上記オペレータまたはシステムにつながると、上記発呼者へ販売するために提供される上記ユニットが、上記着呼レコードに格納された商品から決定されることが好ましく、上記オークションが別の商品の販売に使用され、上記暫定利用可能数量が上記所定の数まで下がった後、好ましくはすべての販売が完了する前、または上記最終的な割り当てがいくらかでも増加する前に、上記別の商品が新しい発呼者のための上記着呼データベースに格納され、新しい発呼者を含む発呼者が上記別の商品のための上記リバースオークションに参加する場合に、発呼者が電話をかけるための電話番号として上記第１の商品のために提供されたのと同じ電話番号が提供されることが更に好ましい。
【００２１】
上記番号の１つが上記オークションで上記商品を購入する意志の確認を構成するのが好ましい。上記キーパッドの正しい番号が発呼者によって押されていなければ、または上記発呼者がその後注文に進まなければ、上記暫定利用可能数量が減らされないことがより好ましい。
【００２２】
電話だけでなく、インターネットによっても注文をすることができるとよい。上記オークションは、上記インターネットを介して伝達され、テレビなどの別の媒体でも伝達されることが好ましく、かつ／または、オークション・ユニットをショッピングカートに入れるなどといった、上記インターネット上で購入する意志を知らせる利用者の行為が暫定指標を構成してもよく、かつ／または上記最終的な割り当てを増やすことができるとより好ましい。
【００２３】
上記オークションで不首尾に終わった１人または複数の発呼者は、上記オークション後において、他の販売を行うため、または細目を調べられるために、該発呼者の判定された電話番号を使用して折り返し電話されることが好ましい。発呼者は、上記オークション中、該発呼者の着呼に対応する１つまたは複数の暫定指標に基づいて、折り返し電話されたり、折り返し電話されなかったりし、かつ／または、着呼レコードを注文レコードと照合し、一致する発呼者を、折り返し電話するためのリストから削除することによって、上記オークションで不首尾に終わった１人または複数の発呼者の特定が行われ、かつ／または、着呼ごとに一意の番号を生成し、それを両方のレコードに格納することによって、上記注文レコードと着呼レコードとの照合が行われることがより好ましい。
【００２４】
上記注文レコードを上記顧客データベース内のデータと照合し、上記顧客データベース内に格納された該データに対応する電話番号を使用することによって、電話番号が記録された着呼レコードと該データとを結び付け、続いてその着呼レコードと注文レコードとをタグ付けることにより、前記注文レコードと着呼レコードとの照合が行われると更によい。
【００２５】
人またはシステムが上記暫定利用可能数量の低減を要求するステップと、上記要求した低減数を予定最大販売数量と比較することによって、上記要求の低減を行うことができるかどうか判定するステップと、「上記開始値−上記予定最大販売数量」を下回る数まで上記利用可能暫定数量を減らす減数を許可しないステップとを含むことが好ましい。上記要求された低減数により上記暫定数量が上記予定最大販売数量を下回るまで減らされることとなるが、それに代えて、上記暫定数量が上記開始値から上記予定最大販売数量を減算した値まで減らされ、かつ／または、上記最大値が、上記受信された着呼および任意のウェブサイトの注文の総数および／または上記販売プロセスを済ませた発呼者によって購入された追加のユニット数を合計することによって計算されることがより好ましい。
【００２６】
上記表示された利用可能な数量がゼロに達すると、上記価格が凍結され、上記オークションの全ての上記ユニットが上記凍結された価格で販売され、かつ／または、テレビ上とほぼ同時にウェブサイト上で上記オークションに関する情報を提供し、上記オークションへの参加を上記インターネットから行うことを可能にするステップを含むことが好ましい。
【図面の簡単な説明】
【００２７】
【図１】本発明によるシステムのアーキテクチャの概略図である。
【図２】本発明の一部分を形成する着呼レコードの説明図である。
【図３ａ】本発明に従って保持される注文レコードのカテゴリの概略図である。
【図３ｂ】本発明に従って保持される顧客レコードのカテゴリの概略図である。
【図４】本発明に従ってオークションを実施するプロセスのフローチャート図である。
【図５】リバースオークションの決定がそれを基に行われる割り当てを、減らすことができるかどうか検証するプロセスのフローチャート図である。
【図６】支払いの仕組みのフローチャート図である。
【図７】注文票に修正を行うフローチャート図である。
【図８】本発明に従って、図２の着呼レコードと図３の注文レコードなど、着呼レコードを注文レコードと照合するプロセスのフローチャート図である。
【図９】注文履歴をチェックするフローチャート図である。
【図１０】注文をキャンセルするプロセスのフローチャート図である。
【図１１】支払い明細を変更するプロセスのフローチャート図である。
【図１２】クレジットカードを認証するフローチャート図である。
【発明を実施するための形態】
【００２８】
次に、本発明の実施形態を、添付の図面を参照して説明するが、これは単なる例に過ぎない。
【００２９】
図１を参照すると、中央コンピュータシステム１２、着呼受信機１４、通信アプリケーションモニタ１６、コールセンタ１８、ウェブサイト２０、競りデータベース２２、テレビプロデューサ２４、放送グラフィックス・コンポーネント／コンピュータ２６および配達システム２８を備えるシステム１０が示されている。構成部品１４〜２８は、代替実施形態で、コンピュータシステム１２の一部分を形成してもよい。着呼通信アプリケーション１６は、着呼受信機１４およびコールセンタ１８を監視することができる。着呼受信機１４もまた、コールセンタ１８と通信状態にある。
【００３０】
コンピュータシステム１２は、様々なデータベースおよびプロセッサ１３を備える。このシステムは、着呼レコード３２が格納された着呼データベース３０と、電話検索システム３４と、顧客レコード３７を有する顧客データベース３６と、注文レコード４０を有する注文データベース３８と、商品割り当て４４を有する商品データベース４２とを備える。
【００３１】
着呼受信機１４は、交換機からの着呼を受け付けることができ、かかる着呼の受信は、着呼モニタアプリケーション１６によって監視され、この着呼は最終的に、コンピュータシステム１２によりコールセンタ１８につなぐことができる。着呼受信機１４は、着呼データベース３０と通信し、コールセンタ１８は、着呼データベース３０及び注文データベース３８の両方と通信する。
【００３２】
注文データベース３８および商品データベース４２は、配達システム２８と通信する。
【００３３】
図２は、着呼レコード３２をより詳細に示した図である。着呼レコードが、データを入力できる一連のカテゴリを有していることがわかる。実際には、このカテゴリは、データベースエントリのフィールドになる。このフィールドは、基準日付１０２、コールＩＤ１０４、コール番号１０６、受信１１０、受付時間１１２、応答１１４、クリア１１６、商品ＩＤ１１８、受付価格１２０、チャンネル１２２、および内線１２４である。
【００３４】
基準日付１０２は、着呼受信機１４で着呼が最初に受信された時刻および日付に関連するデータを含む。着呼受信機１４で着呼毎にタイムスタンプが付与され、それが新規に作成された着呼レコード３２に記録される。コールＩＤ１０４は、その着呼に付与される識別番号である。これは、各着呼レコード３２に対して一意の番号とすることが可能であり、より好ましくは、基準日付１０２と組み合わされて着呼レコード３２の一意の識別子として使用されるとよい。例えば、これは、新しい着呼レコード機能が作成されるたびに、順番に次の番号に進む、４桁などの固定桁数を有する循環式の番号を生成する生成器によって生成することが可能である。この固定桁数は最終的にはゼロに戻るが、コールＩＤ１０４の識別番号と基準日付１０２とを組み合わせることによって、各着呼を一意的に識別することが可能である。これには、基準日付１０２で記録されている最小時間間隔の範囲内で取得される総着呼数が、コールＩＤ１０４で利用可能な整数の総数よりも小さいことが必要である。例えば、これは、基準日付１０２が着呼した時刻の秒を含み、かつ、コールＩＤ１０４が４桁とされていてもよい。システム１０における１秒毎の着呼数は９，９９９件を超えることなどあり得ないので、基準日付１０２およびコールＩＤ１０４を使用して各着呼レコード３２を一意的に識別することが可能である。
【００３５】
コール番号１０６は、発呼者が発呼に使用した電話番号に対する一意の識別子である。これは、多くの場合、電話会社から自動的に取得することができる。英国では例えば、これは発呼者ライン識別として知られ、それに関連付けられたＣＬＩＤすなわちＣａｌｌｅｒ Ｌｉｎｅ Ｉｄｅｎｔｉｆｉｅｒ（発呼者回線識別子）を有するシステムによって行われる。その他の国では、本発明に関する限り同様の効果がある、ＡＮＩすなわちＡｕｔｏｍａｔｉｃ Ｎｕｍｂｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ（自動番号識別）とよばれるシステムを使用することができる。一部の国や状況では、場合によってＣＬＩＤの提供が保証されない。例えば、ＣＬＩＤの提供を発呼者が伏せることができる場合がある。１つにはこの理由のため、システム１０では、着呼レコード３２の識別に、コールＩＤフィールド１０４を使用することが好ましい。
【００３６】
受信フィールド１１０は、着呼を受信した日付および時刻を格納するので、基準日付１０２のフィールドによく似ている。このフィールドは、基準日付１０２より詳細に時刻を示す情報など（例えば、秒ではなくミリ秒など）、追加の情報を含むことができる。基準日付１０２は、主に一意の識別を可能とするためにコールＩＤ１０４と共に使用される。よって、ゼロに戻る循環式コールＩＤカウンタ用に使用される時間間隔よりも細かく時刻を記録する必要はない。こういった理由のために、２人の発呼者のうちどちらが先に着呼したか決定しようとする場合には、受信フィールドが使用される。
【００３７】
受付時間１１２は、発呼者が電話のキーパッドの数字１を押したことを着呼監視コンポーネント１６が検出した時刻および日付を含む。数字１を押すことによって、その通話はコールセンタ１８の販売待ち行列に転送される。応答フィールド１１４は、コールセンタ１８において着呼に応答した日付および時刻を含み、クリア１１６は、販売の終了時にせよ、顧客による繰り上げ終了によるにせよ、その電話へのリンクが終了した日付および時刻を格納する。商品ＩＤ１１８は、基準日付１０２のエントリに対応する時刻に、画面上にあった商品の商品コードを含む。
【００３８】
商品コードは、どの商品が画面上にあったかを一意に識別することができる。したがって、顧客がどの商品を購入しようとしていたかを一意に識別することができる。受付価格フィールド１２０は、着呼が受信された時刻、すなわち、受信基準時刻１１０において画面上にあったユニットの有効価格を含む。チャンネル１２２は、発呼者が視聴していたチャンネルを格納する。オークションが複数のテレビチャンネルにわたって行われる実施形態においては、チャンネル１２２は、利用者が選局した番号によって決定されるチャンネルを格納する。例えば、システム１０は、別個の電話番号がそれぞれ与えられた３つの異なるテレビチャンネルを有することとしてもよい。着呼受信機１４が着呼する電話番号を検出することによって、利用者がどこのチャンネルをいつの日付に視聴していたかを判別でき、これにより、その利用者がどのオークションに参加していたかを判定することができる。
【００３９】
最後に、内線フィールド１２４は、コールセンタ１８でその通話が転送された応答内線番号を格納する。この内線フィールドは、着呼の応答が行われた後に初めて、応答フィールド１１４が埋まるのと同時に作成される。
【００４０】
ウェブ利用者がウェブサイト２０を使用すると、該当する場合には着呼レコード３２のフィールドに対応するフィールドを使用して、データベースにレコードが作成される。こういったレコードは、別個のデータベースにも、着呼データベース３０にも格納することができる。
【００４１】
図３ａには、注文レコード４０の一例が示されている。注文レコード４０は、フィールドを含み、データベースのエントリとして機能する。注文レコード４０は、顧客名２０２、住所２０４、電話番号２０６、商品コード２０８、追加品目２１０、支払い明細２１２、価格２１４および、場合によっては、基準日付における対応コールＩＤ２１６の、各フィールドを含む。
【００４２】
商品コード２０８は、通信監視システム１６が注文レコード４０に対応する着呼レコード３２の商品コードを判定することにより埋められる。ただし、これは、細目が間違っていることが判明した場合にコールセンタ１８によって変更可能とされている。電話番号フィールド２０６のデータは、ＣＬＩＤから監視コンポーネント１６によって提供されたものを発呼者が確認しても、あるいは、発呼者との対話から、コールセンタ１８でコールセンタオペレータが取得してもよい。住所２０４フィールドおよび顧客名２０２フィールドは、顧客レコード３７から提供されるか、またはコールセンタ１８のオペレータによって取得される。追加品目フィールド２１０を設けることによって、例えばオークション商品のケースやギフト用の箱など、オークションにかけられているユニットに付属する商品をシステム１０で販売することが可能になる。
【００４３】
価格フィールド２１４は、システム１０によって埋められる。システム１０は、オークションにかけられている商品の現在表示価格を判定することによって、又は、受付価格１２０から、或いは、競りデータベース２２に格納されているオークションの最終価格から価格フィールド２１４を埋める。
【００４４】
対応コールＩＤフィールド２１６は、対応する着呼レコード３２のコールＩＤフィールド１０４および基準日付１０２から得られるデータで埋めることができる。
【００４５】
図３ｂには、顧客データベース３６のエントリが示されている。レコード３７は、顧客名２２２、住所２２４、１つまたは複数の電話番号２２６、２２８、２２９、および参照番号２２７の各フィールドを含む。
【００４６】
図４に、運営されるリバースオークションのプロセスが示されている。このプロセスは、ステップＳ３００から開始する。テレビプロデューサ２４は、人であっても、ある決まった所定のアルゴリズムに従う自動化されたコンピュータであってもよい。このテレビプロデューサ２４はまた、手動でオーバーライドできる自動化アルゴリズムを使用した、上記２つの組み合わせであってもよい。
【００４７】
ステップＳ３０２で、テレビプロデューサ２４は、選択された商品の商品コードを入力する。これは、その日の好ましいスケジュールを示すよう開発された所定の商品注文リスト８０からのものであっても、あるいはその他、任意のコードであってもよい。次のステップＳ３０４で、コンピュータシステム１２により、この選択された商品に関する情報が商品データベース４２から呼び出され、必要となるその詳細事項が、競りデータベース２２と放送グラフィックス・コンピュータ２６に送られる。商品自体の詳細事項だけでなく、その商品が用いられた以前の競りの詳細事項もまた提供される。こういった以前の競りの詳細事項により、その商品がどの時刻にどのように良く売れたかが、テレビプロデューサ２４に示される。これにより、テレビプロデューサ２４が、自動にしろ手動にしろ、商品をいつ、どのように販売すべきか判定することが可能になる。この情報は、商品割り当て４４を含んだ商品データベース４２や、競りデータベース２２に格納された競りの過去の履歴から引き出すことができる。
【００４８】
次のステップ３０６で、コンピュータシステム１２が、テレビプロデューサ２４に、この競りを開始したいかどうかを質問する。テレビプロデューサが以前の履歴を調べ、その時刻にその競りを開始するのは適していないと判断し、したがって「いいえ」と判定した場合には、このプロセスはＳ３０２に戻る。プロデューサ２４が「はい」と判断した場合には、このプロセスはステップＳ３０８へと続く。
【００４９】
ステップＳ３０８で、テレビプロデューサ２４は番組司会者の名前、テレビプロデューサが人の場合には自分自身の名前、及びユニットの開始数量を入力する。次いで、ステップＳ３１２で競りが開始される。このとき、このステップＳ３０８およびＳ３１０で入力された全ての情報は、プロセスが繰り返された場合のステップＳ３０４における今後の呼び出しに備えて、競りデータベース２２の履歴記録に入力される。
【００５０】
次いで、ステップＳ３１４において、プロデューサ２４と、番組司会者と、場合によっては一般の人々により、テレビを閲覧するためのある決まった競りの画像が生成される。この画像は、ステップＳ３１８において、ユニットの統計データおよびデータシートを含むことができる。放送グラフィックス・コンピュータ２６によって表示された画像は、データ列をグラフィックス・デバイスへ送り、事前に作成されたテンプレートを呼び出すことによって変更される。
【００５１】
競りが開始されると、着呼監視デバイス１６により着呼が監視され、こういった呼に関する必要かつ／または有用な情報を、テレビプロデューサ２４が確認できるようになる。これにより、ステップ３２０において、放送グラフィックス２６を使用して、その場の画像（グラフィック）情報を放送することも可能になる。こういった情報は、現在の通話について目下発生していることに関するものでもよく、例えば、電話で競っている発呼者またはウェブ利用者の名前を、テレビ上に放送させて、その貢献度を知らせ、そのユニットは需要があると人々に感じさせることによって、需要をさらに喚起するために使用することも可能である。また、その他の係る競売時点の情報を放送してもよい。
【００５２】
ステップＳ３１６と同時に、着呼受信機１４およびコールセンタ１８において、テレビプロデューサ２４に送る情報の内容を左右する処理が行われる。これらの処理は、図４のステップＳ４００からステップＳ４０８を含む別枠に示されている。
【００５３】
最初に、ステップＳ４００において、着呼が受信され、新しい着呼レコード３２が作成され、基準日付フィールド１０２、コールＩＤフィールド１０４、コール番号フィールド１０６、および受信フィールド１１０が埋められる。電話の着信は、新たな通話毎（場合によっては、その基準日付１０２毎）の表示リスト等の形として、テレビプロデューサ２４にも通知される。
【００５４】
次に、注文する場合は１を、顧客サービスは２を、配達状況の確認は３を押すよう求める自動メッセージ、または係るその他の着呼手順の仕組みが、発呼者に対して通知される。
【００５５】
ステップＳ４０２で、発呼者によって１が押されると、監視コンポーネント１６は発呼者をコールセンタ１８の販売待ち行列に入れる。また、受付時間フィールド１１２も埋められる。また、ステップＳ４０２では、表示リスト上の通話細目の色を赤色から緑色へ変化させることなどにより、テレビプロデューサにも通知される。
【００５６】
また、システム１２は、発呼者の発呼者回線識別子ＣＬＩＤを調べ、このＩＤを使用して、発呼者の細目の検索を試みる。これは、電話番号検索コンポーネント３４および顧客データベース３６を介して行われる。発呼者番号１０４などのＣＬＩＤが、電話検索テーブル３４とつき合わせて比較される。一致するものが検出されると、電話検索テーブルより、顧客レコード３７の参照番号２２７に対応する参照値が与えられる。フィールド２２２および２２４からの顧客の名前および市町村が、テレビプロデューサ２４へ送信され、追加の細目が表示リスト上の通話に追加される。プロデューサは、ＣＬＩＤを直接確認しない、すなわちＣＬＩＤには直接アクセスするのではなく、この検索された情報を確認する。システム１２は、この特定の顧客レコード３２にリンクされた注文レコード４０の履歴があれば、それらの履歴から情報を収集し、テレビプロデューサ２４にそれらを示す。これにより、プロデューサは、発呼者の今までの購入傾向を閲覧することができる。
【００５７】
テレビプロデューサは、この提供された情報のいくつかを、番組司会者または視聴している一般の人々に、放送グラフィックス２６を使用して示すこととしてもよい。これにより、既知の利用者からのリバースオークションにおける値付け予想をテレビに出すことが可能になり、視聴者は、より積極的に参加しているように感じることが可能となる。
【００５８】
顧客データベース３６で直接検索するのではなく、別個の電話検索システム３４を使用するので、このシステムでは、複数の電話番号や、同一電話番号の複数の利用者にも対応することが可能となる。顧客データベース３６が、複数の、場合によっては重複する電話番号をそれぞれ入力できる複数のレコード３２を有する一方で、電話検索システム３４は、各電話番号に対して１つの名前だけしか使用することができない。一般に、この名前は、その番号から問題なく購入を行うための最新の発呼者と解釈される。したがって、このシステムでは、１つのシステムで一意のこの番号を、１つの特定の参照番号と照合することができ、顧客データベース３６からの対応する参照番号２７７を使用して、人の名前を検索することができる。
【００５９】
着呼は、受信された順、すなわち受信基準時刻１１２の順に販売待ち行列に入り、次いで、コールセンタ１８の内線番号に割り当てられる。ステップＳ４０４で着呼がコールセンタ１８のオペレータに応答されると、着呼モニタアプリケーション１６は、どのコール番号ＩＤ（場合によっては基準日付１０２と組み合わせたコールＩＤ１０４）が、どの内線番号と共にあるか記録する。着呼レコード３２内の応答フィールド１１４および内線フィールド１２４には、それぞれ時刻、応答内線が入る。
【００６０】
次のステップは、ステップＳ４０８における購入の確定となり、次いで最後に、Ｓ４１０で着呼をクリアすることができる。この２つのステップＳ４０８およびＳ４１０によって、着呼レコード３２のクリア・フィールド１１６が埋まる。ステップＳ４０６での購入の確定は、場合によっては緑色または赤色から青色への色の変化によって、テレビプロデューサに通知される。
【００６１】
テレビプロデューサ２４には、この監視プロセス中における様々な情報が与えられ、これら様々な情報には、識別された何人かの発呼者の細目、受信された着呼の番号、識別された発呼者のうちだれが１を押したか、そのうちだれが応答されたか、だれが確定プロセスまで進んだかといった情報が含まれている。これらは全て、利用者に対するユニットの販売および最終割り当てが行われる見込みがあるという、暫定指標を構成する。テレビプロデューサ２４は、自動的にこれらの暫定落札指標を使用することができ（または購入が確定の場合、確定落札指標）、あるいは人であるテレビプロデューサ２４が手動で使用することもできる。１つまたは複数の暫定指標に基づいて、テレビプロデューサ２４は、ステップＳ３２２またはステップＳ３２４に進むことが可能となる。
【００６２】
テレビプロデューサ２４が、着呼が十分受信されていない、あるいは商品が十分売れていないと考える場合、テレビプロデューサは、ステップＳ３２２に進む可能性がある。ここで、テレビプロデューサ２３は、これから行う値下げを入力し、次いでステップＳ３１６に戻る。価格は、１ポンドまたは１ドルなどの制限された幅だけしか下げることができないようにしてもよいし、あるいは、プロデューサ２４が、価格の劇的な下落が存在する、いわゆる「価格の暴落」を、放送グラフィックス２６から得られる適当に活発な実り多いグラフの付随情報によって示唆するよう指示してもよい。下がった価格は競りデータベース２２に格納される。競りデータベース２２は、任意の新しい着呼の受付価格フィールド１２０と任意の新しい注文の価格フィールド２１４とに、その価格データを簡単にコピーできる位置にある。競りデータベース２２は、金銭的損失が大きすぎる時点でプロデューサの販売を止めさせるために、商品に許される可能な最低価格を知らせることとしてもよい。
【００６３】
テレビプロデューサ２４は、着呼受信機１４およびコールセンタ１８におけるイベントからの暫定指標に応じて、商品の利用可能数量を減らしてもよい。利用者が、そのために、ステップＳ４０６で購入が確定されるのを待つ必要がないので有利である。購入の確定を待つと、オークションの進行が非常に遅くなり、数量がゆっくりとしか減らず、リバースオークションにかなりの時間がかかってしまうはずである。さらに、残っている大きな数量を見て、電話してくる新たな発呼者によって、限られた電話交換機容量の使用にかなりの負担がかかるはずである。実際は、購入を計画したけれどもまだステップＳ４０４に達していないそれ以前の発呼者数のために、新たな発呼者には獲得のチャンスはほとんどない。常にステップＳ４０６の完了を待ってからステップＳ３２４に進むこととすると、発呼者／ウェブ利用者対販売の比が大きくなり、オークション毎に、ウェブサイトと共にテレビの時間とスペースとが長々と使用されてしまう。電話交換機の容量、テレビの放送時間、およびウェブサイト２０にリンクするインターネットの帯域は、限られた資源であるので、理屈から言えば非効率的である。
【００６４】
その代わりとして、テレビプロデューサ２４は、発呼者または商品の販売履歴、及びオークションの際にステップＳ４０６において販売が確定されるまでに発生したそういったイベントの経時的類似性と比べるために、任意の数の暫定指数を使用することとしてもよい。この暫定指数には、着呼の時刻か、受信された着呼の数か、Ｓ４００において受信されている着呼か、Ｓ４０２において１を押している発呼者か、Ｓ４０４において応答されている着呼か、或いはこれらのうちのいずれかを含んでいる。最も一般には、テレビプロデューサ２４は、Ｓ４０２で１を押している発呼者を、ユニットがその発呼者に販売される可能性がある指標として使用する。利用者は、その発呼者が１を押した場合に数量を減らすかどうか、オークションが適当な時刻になっているかどうか、さらにその顧客が特定された場合には、その履歴も考慮することができる。例えば、ある競りにおいて、オークションの出だしに１を押した着呼は、販売につながるものではなく、オークション経路を通過することによって質問システムを迂回しようとしている発呼者による前の商品についての問い合わせとなることが、テレビプロデューサの経験と競りデータベース２２に格納されているイベントから分かる。したがって、１が押されても、ステップＳ３２４で数量が減らないようにしてもよい。あるいは、テレビプロデューサは、発呼者の経過履歴を考慮して、こういった通常の直感や指示を変更することができる。例えば、テレビプロデューサは顧客について思い出すことも、保存されているレコードから顧客の過去の行動を確認することもできる。これにより、通常なら不適当な時間に１を押したとしても、この場合は販売につながる可能性があるので、当てにすることができるということを顧客にほのめかすように導く。以上の全てを、競りデータベース２２内の過去の競りに基づく自動アルゴリズムによって行うことができる。
【００６５】
ステップＳ３２４で、テレビプロデューサ２４は、監視してきた着呼の活動状況に応じて、任意の数だけ数量を減らすことができる。次のステップＳ３２６で、コンピュータシステム１２は、現在の競りの対象物の在庫数がゼロに達したかどうかを判定する。ゼロに達していない場合は、ステップＳ３１６に戻る。テレビプロデューサ２４は、「開始数量−ステップＳ４００での総受信着呼数−競りの注文数およびウェブサイトでの注文数」を下回るレベルにまで、数量を減らすことができない（注文とは、ユニットをショッピングカート内に入れることを意味する）。
【００６６】
数量を減らすと、商品割り当て４４に格納された暫定利用可能数量が、その数まで減る。この暫定利用可能数量は、放送グラフィックス２６を使用して、司会者および一般に人々に示される。
【００６７】
ステップＳ３２６で暫定利用可能数量がゼロに達すると、このプロセスは、競りが終了するステップＳ３２８に進む。この終了は、競りデータベース２２に記録され、ステップＳ３３０に進む。ステップＳ３３０では、競りグラフィックスを終了するよう求められ、それが放送グラフィックス・コンポーネント２６に送信される。最後に、ステップ３３２において、既存の注文明細の行に価格の付け直しが行われる。競りの終了前に、ステップＳ４０６で注文レコードが埋められ、購入を確定することができる。したがって、価格の付け直しの仕組みは、競りの最も低い最終価格よりも高い価格に対して出された注文明細の行の価格を下げるために、定位置にある必要がある。この位置は、注文レコード内のフィールド価格２１４である。フィールド価格は、記録された着呼に関連付けられたフィールド１２０の価格、または、注文が切り替わるときの現在の価格に基づいている。また、この位置は、ステップＳ３２２における値下げにより、競りデータベースに格納されている最終価格まで下げられる。この確認は、その時点までの３０分内に完了した全ての競りに対して行われるが、任意の期間にわたって行うこととしてもよい。最低価格は、別個に運営されるウェブサイト２０のウェブ上の競りを含む必要はないが、含むこととしてもよい。注文の合計は、再計算される必要がある。この注文の合計には、注文明細行における価格の見直し後の値下げ率を申し込むクーポンなど、提示されている全てのクーポンが含まれる。
【００６８】
ウェブ注文伝票ＷＯは、ウェブサイト２０で作成することもできる。オンラインの顧客は一般に、事前登録するべきである。登録が済み、ログインすると、オンライン上の顧客は、商品をクリックして、それをショッピングカートに入れることができる。ウェブオークションは独立して実施することができる。あるいは、ウェブサイト２０をテレビ中継オークションに参加する代替媒体にすることも可能である。後者の場合、表示リストにウェブ注文伝票ＷＯが示され、通常、テレビプロデューサ２４はこれを暫定指標とする。ステップＳ３２４において、ユニットをショッピングカートの中に入れるウェブ利用者の暫定指標が与えられたとすると、商品購入に使用可能なウェブサイトにおける公知の方法と同じようなやり方で、数量を減らすようテレビプロデューサ２４に求めることができる。他の暫定指標と同様に、特にこのイベントが競りの早い時点であって価格がまだ高い場合には、プロデューサは数量低減の決定を先延ばしにしてもよい。これは、顧客が、ユニットをショッピングカートの中に入れてから数秒後にそれを削除することによって、このウェブサイトを試すことが可能だからである。
【００６９】
ユニットをショッピングカートの中に入れるという購入のためのクリックは、競りの終了３２８前に行わなければならない。ただし、精算プロセスは、ユニットをショッピングカートの中に入れてから数日後に行ってもよい。このためには、クレジットカード所有者の住所、配達先住所、および支払い明細を含んだ項目を埋めることが必要とされる。このユニットは、新しい注文レコード４０で取り扱われてもよく、或いは、顧客が配送料を節約するために、既存の注文レコード４０に追加されることも可能である。このとき、このような購入はＥメールによって確認することができる。
【００７０】
図５には、ステップＳ３２４において、テレビプロデューサ２４によって行われる暫定利用可能数量を減らす要求を処理するプロセスが示されている。
【００７１】
最初に、ステップＳ５００において、暫定利用可能数量を一定量減らす要求が受信される。次のステップＳ５０２において、プロセッサ１３は、着呼データベース３０にアクセスし、競りの間に受信された着呼の総数をカウントする。次のステップＳ５０４において、その着呼の総数が、システム１２のデータベース、またはサーバもしくは現在の競りに対応するウェブサイト２０を提供するサーバに格納されているウェブ注文伝票ＷＯの総数に追加される。
【００７２】
ステップＳ５０６において、数量が注文レコード４０から得られる数量より多い場合、システムは、競りに任意の増分数を追加する。発呼者はコールセンタ１８につながると、オークションで複数のユニットを購入することが許される。したがって、仮に、商品を１つではなく５つ購入したとすると、そのことが注文データベース３８にある追加の注文レコード４０に記録され、ステップＳ５０６において追加される。ステップＳ５０８において、着呼数と、ウェブ注文数と、ステップＳ５０２、５０４および５０６からの追加の販売数の合計とから販売できた予定最大数量が計算される。このことから、Ｓ５１０において、コンピュータシステム１２のプロセッサ１３は、「開始数量−予定最大販売数量」が「現在の画面上の数量−低減要求数」以下であるかどうか計算することにより、低減を要求されている数量を全数減らすことができるか否かを計算する。
【００７３】
ステップＳ５１０において、答えが「はい」の場合、システム１２は、ステップ５１２に進む。ステップ５１２では、商品割り当て４４の暫定利用可能数量が全要求数量だけ減らされる。割り当て４４を使用して、画面に表示されている数量が、要求された数量だけ減らされ、ウェブと同期をとるためのデータベースに格納される。次いで、プロセスの終了ステップＳ５２２に進む。このとき、メインのオークションプロセスは、ステップＳ３２６に続く。
【００７４】
販売せずに残しておくことが可能な予定最大数量を下回るまで、テレビプロデューサ２４が数量を減らそうとしているために、ステップＳ５１０において要求数を全数減らすことができない場合は、システムはステップＳ５１４に進む。ステップＳ５１４では、商品割り当て４４における暫定利用可能数量の低減数が、「開始数量−販売できた予定最大数量」までとなるように制限される。次のステップＳ５１６において、コンピュータシステム１２のプロセッサ１３が、修正された低減数が１を下回っていないかどうか判定する。１を下回っていない場合、ステップＳ５１８に進み、新しい修正された低減数だけ数量が減らされ、その後ステップＳ３２６に進む。修正された低減数が１を下回っている場合（すなわちゼロの場合）、ステップＳ５２０では現在の暫定利用可能数量は減らされず、ステップＳ３２６にプロセスが進み、Ｓ３１６に戻る。
【００７５】
図６には、クレジットカードによる支払いプロセスのフローチャートが示されている。
【００７６】
図７には、すでにある注文票についてのコールセンタのオペレータによる商品の修正プロセスが示されている。ステップＳ７００において、オペレータは商品の修正を試みる。ステップＳ７０２において、オペレータは、その商品が標準品なのか、元展示品なのかを判定する。標準品の場合は、ステップＳ７０４に進み、元展示品の場合は、ステップＳ７１８に進む。
【００７７】
ステップＳ７０４において、オペレータは、コンピュータシステム１２から、注文伝票のユニットの数量を変更したいかどうか質問を受ける。答えが「いいえ」の場合は、ステップＳ７１０に直接進む。答えが「はい」の場合は、ステップＳ７０６に進む。Ｓ７０６において、オペレータが割り当てられた数量を減らすと、商品データベース４２内の商品割り当て４４が減らされ、そのことが示される。このようにして、ステップＳ７０８において、まだ販売可能であり、人々に割り当て可能な未割り当ての数量が増やされる。このことは、商品データベース４２の商品割り当てコンポーネント４４にも記録される。
【００７８】
ステップＳ７１０で、システム１０は、現在の競りがテレビの競りであるか、単にウェブベースの競りのみであるか判定する。テレビの競りの場合はＳ７１２に進み、そうでない場合はステップＳ７１４に進む。Ｓ７１２では、価格がテレビの競りで入力された最低値に変更される。Ｓ７１４では、標準品の注文明細行が修正され、そのことが注文データベース３８に記録される。次いでステップＳ７１６において、伝票はいずれも再計算され、システムはステップＳ７２６に進む。
【００７９】
ステップＳ７１８、Ｓ７２０、およびＳ７２２は、変更点が、元展示品の割り当て数量を処理する商品割り当てコンポーネント４４の特殊コンポーネントであることを除いて、ステップＳ７０４、Ｓ７０６、およびＳ７０８と同一である。次いで、元展示品の注文明細行が修正されて、ステップＳ７２４に進み、ここでデータベース３８に記録された後、ステップＳ７１６に進む。
【００８０】
ステップＳ７２６で、送料、ＶＡＴ（付加価値税）および注文の合計が再計算され、Ｓ７２８で、これらの明細が注文データベース３８に保存される。
【００８１】
図８には、着呼と注文を照合するプロセスが示されている。時には、ステップＳ４０２において、顧客が１を押した後、ステップＳ４０４において着呼の応答が行われる前に競りを降りる場合がある。さらに、Ｓ４０４において、着呼の応答が行われた後、顧客がコールセンタ１８のオペレータと通話して購入しないと決定し、ステップＳ４０６が実施されない場合がある。また、ステップＳ４０６において、購入を確定しようと試みたが、支払い明細の認証を受けられなかったり、支払い明細が正しく取得されなかったりする場合がある。このような場合、通常は、その顧客らは十分な暫定指標を与えたことになり、その顧客らの着呼によって、テレビプロデューサ２４はステップＳ３２４において、割り当てコンポーネント４４の暫定利用可能数量を減らすことになる。しかしながら、割り当てコンポーネント４４の最終的な割り当てでは、販売も増数も行われない可能性があり、オークション終了後、ユニットが完売しない可能性がある。この場合、かかる顧客に電話を折り返して入れ、彼らにそのユニットをオークションの終値で注文するよう求めることが可能である。
【００８２】
この場合、ステップＳ４０２で１を押したが購入しなかった顧客は、いずれも着呼の応答が行われる前に電話を切ったとしてもある種の興味を示したのだから、このような顧客には連絡をとることが好ましい。かかる顧客は、そのＣＬＩＤが顧客データベース３６内のレコードと確実に照合できるように既に登録されていてもよく、あるいは未登録であってもよい。
【００８３】
適切な者にシステム１２から連絡を取ることができるようにするために、すでに注文が済んだ者に電話がかからないように、着呼レコード３２を注文レコード４０と照合する。
【００８４】
ステップＳ８００において、競りの開始と終了（Ｓ３１２とＳ３２８）の間に受信された着呼のリストが着呼データベース３０から取得される。ステップＳ８０２において、この着呼レコードが、電話検索システム３４を使用して顧客レコード３７と照合される。これに代えて、通信監視コンポーネント１６により、コールＩＤ１０４および基準日付１０２が全ての新規注文レコード４０および新規着呼レコード３２の追加フィールド２１６に入力されてもよい。これにより、注文レコード４０は、電話検索システム３４を必要とすることなく、フィールド２１６、１０２、および１０４のデータを比較することによって照合されることとなる。ステップＳ８０４では、顧客データベース３６において特定された顧客によってなされた全ての注文レコード４０にタグ付けが行われる。タグ付けされる情報には、サイズおよび／または色のオプションが提供される下位商品の検討項目も含まれる。次のステップＳ８０６において、電話によって手配される場合と同様に、ウェブ注文ＷＯが扱われる。
【００８５】
ステップＳ８０４およびＳ８０６の結果から、注文レコード４０は、顧客レコード３７に対してタグ付けされている。これにより、ステップＳ８０２においてその顧客レコードと合致することがわかっている着呼レコード３２に対して注文レコードをタグ付けすることができる。
【００８６】
したがって、ステップＳ８００からＳ８０６において、顧客および注文と照合された着呼のリスト８０８と、顧客と照合されたが注文明細行にリンクされていない着呼のリスト８１０と、顧客にも注文にも照合されていない着呼のリスト８１２と、顧客レコード３２と照合されたが着呼レコード３２とリンクされていない注文レコード４０のリスト８１４との、４つの別々のリストが得られる。
【００８７】
リスト８０８および８１０は、最終的なリスト８２４の一部分を形成するために送信される。ステップＳ８１６では、２つのリスト８１２と８１４とが比較される。ステップＳ８１６において、例えば、注文明細行が先入れ先出し形式であると想定した場合には、２つのリスト８１２と８１４とが照合される。先入れ先出しは、仮定としては単純すぎるが、これによって、着呼が異なる発呼者であった場合でも、落札が着呼レコード３２と照合されることとなる。ステップＳ８１６により、顧客および注文明細行と照合された、最終的なリスト８２４の一部分を形成するために送信される着呼のリスト８１８と、顧客３７とも注文レコード４０とも照合されない着呼のリスト８２０の、２つのリストが得られる。
【００８８】
ステップＳ８２２において、リスト８２０は、コール番号フィールド１０６にある全ての発呼者回線識別子から追加されたエリアコード情報を有し、既存の従来のデータベースからエリアコードおよびそれぞれのエリアを検索する。ステップＳ８２２の後、このリストの補足版８２０もまた最終的なリスト８２４の中に含められる。したがって、最終リスト８２４に含まれる着呼レコード３２およびウェブ注文のリストは、顧客および注文レコード４０と照合されたものと、顧客レコード３７と照合されたが注文レコード４０とリンクされていないものであってエリアコードを有する顧客とは照合されていないもの、または、エリアコードをもたない顧客とは照合されていないものになる。後者のリストは、例えばＣＬＩＤが無い場合、その番号は留保される。
【００８９】
注文レコード４０にリンクされていないがＣＬＩＤが利用可能な受付時間フィールド１１２にあるデータエントリを含んだ着呼のリストは、競りが終了し、その競りのために受信された着呼が全てクリアされた後、売れ残った商品を販売するために電話を折り返す顧客のベースを形成することができる。
【００９０】
図９には、ステップＳ４００、Ｓ４０２、およびＳ４０４をすでに済ませた、商品を購入しようとしている顧客、またはいずれの競りにも関係のない、コールセンタに直接電話をした顧客を照合するシステム１２のプロセスが示されている。このプロセスは、ステップＳ４００と同等のステップＳ９００から開始する。安売りユニットを一掃するのに役立つように記録を照合する場合など、競りが進行中でない状況では、システムは、直接ステップＳ９１６までスキップすることができる。あるいは、注文番号が直接使用された場合、ステップＳ９２８を経由して進むことができる。Ｓ９２８の場合は、コールセンタのオペレータが注文番号を入力してから、ステップＳ９３０に進む。
【００９１】
ステップＳ４０４と同等のステップＳ９０６において、着呼が受信された後、オペレータがその着呼に応答する。ステップＳ９０８において、コンピュータシステム１２が、発呼者がどの着呼レコード３２に対応するかについての情報を受け取るために、着呼モニタアプリケーション１６にアクセスする。着呼レコード３２は、商品ＩＤフィールド１１８を含んでおり、新しく作成された注文レコード４０の商品コードフィールド２０８にあるその商品の細目がオペレータに示される。さらに、ステップＳ９０８において、コールセンタ１８のオペレータは、パソコンにある顧客検索ボタンを押すなどして、システム１２から発呼者の顧客細目を要求して新しい注文レコード４０を表示させることができる。次いで、システム１２は、コール番号フィールド１０６に格納された発呼者ラインＩＤを使用して、顧客細目の検索を試みる。このとき、システムは、テレビプロデューサ２４に情報を提供する場合と同様に、電話検索システム３４を使用して、顧客データベース３６に顧客レコード３７があるかどうかを確認する。これは、オペレータが電話番号をキー入力する必要なく、コンピュータシステム１２によって自動的に行うことができる。というのは、オペレータが作業している内線がシステムで分かっており、かつ、ボタンを押したときに、その内線を使用している発呼者に対応する着呼レコード２０を検索することができるからである。
【００９２】
照合用の顧客レコード３７が検出されると、顧客の細目および過去の注文履歴の全てを、そのオペレータが利用できるようになり、該当する場合は、注文レコード４０の関連フィールドが埋められる。例えば、顧客名２０２、住所２０４、電話番号２０６を、照合される顧客レコード２０２から埋めることができ、商品フィールド２０８は、照合される着呼レコード３２およびその商品ＩＤフィールド１１８から埋めることができる。ＣＬＩＤが利用可能でない場合、あるいはその顧客の現在の電話番号が電話検索３４内に無い場合、オペレータは、顧客にその顧客の郵便番号を要求し、その郵便番号を使用して、顧客の位置の特定を試みる。オペレータは、発呼者にその発呼者の郵便番号を要求し、その郵便番号を使用して、顧客データベース３６を介して顧客レコード３７の検索を試みる。もちろん、それが顧客の最初の購入である場合は、レコード２７の位置は特定されない。
【００９３】
ＣＬＩＤから使用可能な顧客レコード３７が与えられない場合でも、着呼レコード３２から得られるＣＬＩＤから、やはり電話番号フィールド２０６を埋めることができる。かかる注文レコード４０が格納されると、その後の着呼と照合するために、新しい電話番号フィールド２０６を使用して電話番号検索テーブルにエントリが作成／更新される。
【００９４】
顧客レコードが検出できない場合は、オペレータが手作業で、細目の全てを要求し、注文レコード４０にその細目を入れると同時に、新しい顧客レコード３７を作成する。
【００９５】
ステップＳ９１０で、システムは、一時的な割り当てを作成するが、暫定指標として採用するために、この割り当てをテレビプロデューサに伝達できることが好ましい。これは、発呼者がこの時点で落札に進もうというその意志をしっかり確認しているので、単に「１」が押されたよりも強力な指標になる。発呼者が１を押さず、間違った番号を押し、そのまま進んで、オークションが終了する前になんとか購入を遂げる可能性もある。このような状況では、該当する場合は割り当ての数を減らすことができるように、その状況がテレビプロデューサ２４に示される。この一時割り当ての仕組みにより、実際の注文がコンピュータシステム１２に入るのにどのくらい時間がかかるかには関係なく、発呼者が順調にそのユニットを確保できるようになる。
【００９６】
ステップＳ９１２におけるユニットの落札確定後に、ステップＳ９１４にて、割り当て４４における最終的な商品割り当ての利用可能なユニット数が増やされ、販売可能な数が減らされる。
【００９７】
ステップＳ９１６において、顧客レコード３７が顧客データベース３６から検出される。次のステップＳ９１８において、コンピュータシステム１２および／またはオペレータが、そのレコードが正しく検出されたかどうかを判定する。正しく検出されなかった場合、ステップＳ９２０に進み、新しい顧客レコード３７が作成されて顧客データベース３６に入力され、次いでステップＳ９２２に進む。ステップＳ９１８で正しく検出された場合は、ステップＳ９２２に進む。
【００９８】
ステップＳ９２２では、顧客の注文履歴が顧客データベース３６から取り出され、さらに、対応する以前の注文が、注文データベース３８から、顧客レコード３７と合致する注文レコード４０を使用して検出される。次いで、各発呼者は、注文の新規作成を選択することも、新しい注文を既存の注文レコードに追加することもできる。注文が新規作成された場合はステップＳ９３４に進み、既存の注文レコードが選択された場合はステップＳ９２６に進む。ステップＳ９２６では特定の注文レコードが選択され、ステップＳ９３０でその細目が注文データベース３８から取得される。
【００９９】
次のステップＳ９３２において、システム１２は注文票が完成したかどうか判定する。完成した場合はステップＳ９４４に進み、完成していない場合はステップＳ９３８に進む。
【０１００】
ステップＳ９３４では、顧客の新しい注文レコード４０が作成され、その注文レコードが注文データベース３８に挿入される。ステップＳ９３６において、システム１２が、注文レコードがロックされたかどうかを判定する。ロックされた場合は、プロセスが中止され、ロックされていない場合は、ステップＳ９３８に進み、ステップＳ９１０の一時割り当ての有無をチェックする。一時割り当てが存在しない場合は、ステップＳ９４４に進む。一時割り当てが検出された場合は、ステップＳ９４０においてそれが削除され、ステップＳ９４２において、データベース３８に予め割り当てられているユニットの新しい注文レコードが作成される。
【０１０１】
ステップＳ９４４では、システムが、データベース３８から既存の注文票の上にその商品を呼び出す。次いでステップＳ９４６において、その注文票の顧客細目が呼び出される。ステップＳ９４８において、不正の有無をチェックする段階があり、疑いのある場合は、ステップＳ９５０において、その注文をキャンセルし、ステップＳ９５２に直接スキップすることができる。不正が存在しない場合は、ステップＳ９５４に進む。このとき注文票の見直しが行われ、最終的に完了する。
【０１０２】
次いで、注文をキャンセルするには、ステップＳ９５２に進み、変更を中止するにはステップＳ９５３に進む。その注文が既存のもので、変更が行われなかった場合は、マーケティングの情報源を記録するステップＳ９５６に進み、そうでない場合は注文票を計算し、変更を格納するステップＳ９５８に進む。ステップＳ９６０で、ステップＳ３５２、Ｓ９５３、およびＳ９５６の全てにより、関連する注文票が得られる。
【０１０３】
ステップＳ９５８の前に、このシステムまたはオペレータは、ユニットまたは伝票を追加することも、ユニットを修正することも、ユニットまたは伝票を削除することも、支払い明細を変更することも、配送住所を変更することも（国を変更した場合、ＶＡＴ支払額を変更することができる）、指定出荷日付を変更することもできる。ステップＳ９５８後、注文データベース３８に何らかの変更が保存された場合は、Ｓ９５４の注文票の見直し段階に戻ることができる。ステップＳ９５２、Ｓ９５４、およびＳ９５６の場合は、そのステップが終了した後にプロセスが終了する。
【０１０４】
ステップＳ９５６の前に、注文票を出荷可能行と欠品行に分割することも、データに応じて注文票を保存し、注文データベース３８にそれを格納することもできる。
【０１０５】
図１０には注文をキャンセルするプロセスが示され、図１１には支払い明細を変更するプロセスが示されている。
【０１０６】
図１２には、クレジットカードを認証するシステムが示されている。
【符号の説明】
【０１０７】
１０ システム
１２ 中央コンピュータシステム
１４ 着呼受信機
１３ プロセッサ
１６ 通信アプリケーションモニタ、着呼通信アプリケーション、着呼モニタアプリケーション、着呼監視アプリケーション
１８ コールセンタ
２０ ウェブサイト
２２ 競りデータベース
２４ テレビプロデューサ
２６ 放送グラフィックス・コンポーネント／コンピュータ
２８ 配達システム
３０ 着呼データベース
３２ 着呼レコード
３４ 電話検索システム
３６ 顧客データベース
３７ 顧客レコード
３８ 注文データベース
４０ 注文レコード
４２ 商品データベース
４４ 商品割り当て
１０２ 基準日付フィールド
１０４ コールＩＤフィールド
１０６ コール番号フィールド
１１０ 受信フィールド
１１２ 受付時間フィールド
１１４ 応答フィールド
１１６ クリア・フィールド
１１８ 商品ＩＤフィールド
１２０ 受付価格フィールド
１２２ チャンネルフィールド
１２４ 内線フィールド
２０２ 顧客名フィールド
２０４ 住所フィールド
２０６ 電話番号フィールド
２０８ 商品コードフィールド
２１０ 追加品目フィールド
２１２ 支払い明細フィールド
２１４ 価格フィールド
２１６ 対応コールＩＤフィールド
８０８ 顧客および注文と照合された着呼のリスト
８１０ 顧客と照合されたが注文明細行にリンクされていない着呼のリスト
８１２ 顧客にも注文にも照合されていない着呼のリスト
８１４ 顧客レコード３２と照合されたが着呼レコード３２とリンクされていない注文レコード４０のリスト
８１８ 顧客および注文明細行と照合された着呼のリスト
８２０ 顧客３７とも注文レコード４０とも照合されない着呼のリスト
８２４ 最終的な着呼およびウェブ注文のリスト
【技術分野】
【０００１】
本発明は、オークションを運営するためのシステムおよび方法に関し、特に、電話および／またはテレビおよびインターネットによるリバースオークションに関する。
【背景技術】
【０００２】
テレビまたはその他の媒体を使用して商品を販売しようとする試みが知られている。これは典型的には、商品をそれに伴う価格と共にテレビに示すことによって行われる。このとき、商品の販売者は、誰もが電話をかけ、テレビに表示されている商品を購入できるようにする。このようなシステムでは、利用者の電話を随時許可することも可能であるし、商品が画面上に示されている間に限って利用者の電話及び注文を許可することも可能である。前者のシステムでは、電話をかけようと人を駆り立てる期間がなく、また、利用者は、売りに出されている複数の商品を次々と簡単に見てから、商品を購入するかどうかを決定することができるという不利な点がある。後者のシステムは、商品をすぐに購入しようと人を電話に駆り立てる刺激を与えるのに役立つが、その商品が画面に映されている間に、一定の通話数しか処理することができないという不都合がある。したがって、単一の商品の販売に要する全期間にわたって、テレビ放送帯の容量と電話網の容量を両方とも同時に消費しなければならない。これは理屈の上からいっても効率的ではない。
【０００３】
英国では、テレビ上で流動的な価格を扱うオークションを運営しようとする試みも知られている。これによると、人に電話をかけるタイミングを与えるよう刺激するという利点が得られる。しかしこの場合、利用者は注文、購入および登録の各プロセスを経るが、それを行うのにかなりの時間がかかるので、電話網の容量を消費してしまうという不都合がある。オークションプロセスの全容をテレビで放送する必要があることから、各競りの完了が遅くなると、オークション全体の進行が遅くなり、よって、テレビネットワークの容量が大量に消費されてしまう。これに対する１つの代替策は、事前登録された利用者だけ競ることを許し、これにより、オークションのタイミングを早めることである。この代替策には、登録していない利用者はオークションに参加することができないという不都合がある。
【０００４】
他のタイプのオークションには、リバースオークションがあるが、これをテレビ画面上で実施するには問題がある。というのは、このオークションは、全てのユニットが購入されて初めて終了するからである。最終的な価格は、最終ユニットの落札時に付けられ、場合によっては、全ての落札者に対して同じ価格になる。この方式は、利用者が登録と購入手続きを済ませるまで、ユニットの割り当てを確定することができないため、問題である。したがって、テレビなどの媒体を使用する場合、かなり時間がかかり、容量を効率よく使用することができない。
【０００５】
注文が全て完了する前に、次のユニットの販売をテレビ上で進めたとしても、利用者は前の商品のときと同じ電話番号を使用することができない。これは、電話番号が商品間の区別に使用されるので、ある特定の電話番号に電話をかけている利用者は、特定の商品を購入していると見なされるからである。その電話番号に対応する商品を注文の途中で変更すると、その利用者がどの商品を購入しようとしているのか、混乱をきたす可能性がある。
【０００６】
落札されたユニット数に対して在庫数を制御し続ける点にも問題がある。周知のオークションシステムでは、比較的に、在庫数よりも商品を売り過ぎてしまいやすい。また、商品を安売りしてしまう可能性も高い。こういった状況では、その商品の購入に興味があり、オークションに参加しようとしている利用者が他にいる可能性があっても、テレビおよび電話網の望ましい容量使用量の枠内では、商品が非効率な形で売れ残ってしまう。この問題を回避するには、各通話を継続的に監視し続ける必要がある。これにより、もしある通話が最終的に落札につながるようであれば、その電話をかけてきた利用者を売れ残った商品の再販売対象にすべきではないことがわかる。しかしながら、これは、各通話をその通話の間に渡って監視し、かつ、各通話の詳細を全て単一のデータベースエントリに格納しなければならないため、技術的に非効率でありコストもかかる。
【０００７】
インターネットを介して商品を販売するシステムも知られているが、このような利用者は、テレビ販売に付きものの対話型の商品説明が受けられない。
【発明の概要】
【０００８】
本発明は、上述したいくつかの問題を軽減することを目的とする。また、上述のいくつかの技術的な問題に対する技術的な解決策によって、より効率的なシステムを使用できるようにすることを目的とする。
【課題を解決するための手段】
【０００９】
本発明の第１の態様によれば、媒体によって利用者へ伝達され、ユニットを販売するための電話を基本としたリバースオークションを運営する方法が提供され、該方法は、販売するいくつかのユニットを提供し、販売に供される数を最初に示す割り当てデータベースに暫定利用可能数量を格納するステップと、上記リバースオークションに参加するために発呼者から電話をかけることができる電話番号を提供するステップと、上記電話番号に１つまたは複数の着呼が受信された時刻を着呼データベースの着呼レコードに記録するステップと、ユニットを販売するために、各発呼者を待ち行列に配置し、その発呼者をコールオペレータまたはシステムに割り当てるステップと、人またはシステムが上記示されたユニットの価格を一定の期間にわたって下げ、プロデューサまたはシステムが上記暫定利用可能数量を減らすリバースオークションを運営するステップとを含み、上記リバースオークションは、上記暫定利用可能数量がゼロなどの所定の数まで減った時刻に終了するとともに、上記終了時の価格がオークションデータベースに格納され、上記暫定利用可能数量は、上記オークションのタイミングに対する上記着呼レコード内の上記着呼の受け付け時刻などの、着呼／発呼者と関連づけられた１つまたは複数の暫定指標に少なくとも部分的に基づいて減らされ、上記指標はユニットの販売が完了／確定する前に発生する。
【００１０】
本発明の第２の態様によれば、ユニットのリバースオークションを運営するためのコンピュータシステムが提供され、該システムは、プロセッサと、割り当てデータベース、オークションデータベース、および着呼データベースを含んだメモリと、電話システムと、ディスプレイとを備え、上記割り当てデータベースは、オークションに提供されるユニット数を示す暫定利用可能数量を含み、上記電話システムは、上記着呼データベースの着呼レコードに着呼が受信された時刻とダイヤルされた番号を記録するように構成されるとともに、ユニットを販売するために各発呼者を待ち行列に配置して、その発呼者をコールオペレータまたはシステムに割り当てるように構成され、上記プロセッサは、上記ディスプレイに価格を表示し、上記表示された価格を一定の期間にわたって下げ、上記暫定利用可能数量を減らし、上記暫定利用可能数量がゼロなどの所定の数まで減るタイミングを判定し、その時刻で上記表示された価格を上記オークションデータベースに格納し、上記電話システムへ新しく着呼した通話が上記オークションに参加できないように構成され、上記システムは、上記オークションのタイミングに対する上記着呼レコード内の上記着呼の受け付け時刻などの、着呼／発呼者と関連付けられた１つまたは複数の暫定指標に少なくとも部分的に基づいて上記暫定利用可能数量を減らし、上記指標がユニットの販売が終了する前に発生する。
【００１１】
本発明の第３の態様によれば、テレビでリバースオークションによりユニットを販売する方法が提供され、販売するためのユニットを、最初の価格および上記ユニットの上記オークションでの販売に利用可能な数と共にテレビに表示するステップと、オークションに参加するための電話着呼を許可するステップと、販売が行われる可能性がある、また行われたという十分な指標を発呼者が示していると考えられる場合に、前記表示された利用可能な数量が減らされるステップと、より多くの発呼者を促し、上記テレビの上記オークションに費やされる時間を減らすために、上記ユニットの上記表示された価格を下げるステップと、上記表示された利用可能な数量がゼロに達すると、上記オークションを終了するステップとを含む。
【００１２】
本発明の第４の態様によれば、媒体によって利用者へ伝達され、ユニットを販売するためのインターネットを基本としたリバースオークションを運営する方法が提供され、該方法は、販売するいくつかのユニットを提供し、販売に供される数を最初に示す割り当てデータベースに暫定利用可能数量を格納するステップと、上記リバースオークションに参加するために利用者から注文を出すことができるウェブサイト購入機能を提供するステップと、上記電話番号に１つまたは複数の注文が受信された時刻を着呼データベースの着呼レコードに記録するステップと、ユニットを販売するために、各発呼者を待ち行列に配置し、その発呼者をコールオペレータまたはシステムに割り当てるステップと、人またはシステムが上記示されたユニットの価格を一定の期間にわたって下げ、プロデューサまたはシステムが上記暫定利用可能数量を減らすリバースオークションを運営するステップとを含み、上記リバースオークションは、上記暫定利用可能数量がゼロなどの所定の数まで減った時刻に終了するとともに、上記終了時の価格がオークションデータベースに格納され、上記暫定利用可能数量は、上記オークションのタイミングに対する上記着呼レコード内の上記注文の受け付け時刻などの、着呼／発呼者と関連づけられた１つまたは複数の暫定指標に少なくとも部分的に基づいて減らされ、上記指標はユニットの販売が完了／確定する前に発生することが好ましい方法が提供される。
【００１３】
上記コールオペレータまたはシステムにつながる着呼の順序が、上記着呼レコードの上記格納された時刻によって決まり、かつ／または、ユニットの販売価格が、上記オークションデータベースに格納された上記終了時の価格から決定されることが好ましい。
【００１４】
上記方法は、各発呼者にデータを１つ入力するよう促し、好ましくは、各発呼者を待ち行列に入れる前に書く発呼者にデータを１つ入力するよう促し、そのデータを上記着呼レコードに格納するステップを含むのが好ましい。更に好ましくは、上記着呼が待ち行列に配置されるかどうかが上記入力されたデータによって決まり、かつ／または、１つの暫定指標が、上記入力されたデータを含むとともに上記着呼レコードに格納され、かつ／または、１つの暫定指標が、上記データが入力され、上記着呼レコードに格納される時刻を含むとよい。
【００１５】
上記入力を促すステップは、上記利用者に、１つの番号をその利用者の電話に入力するよう促し、好ましくは、１つまたは複数の番号が暫定指標と解釈され、かつ、ゼロ、１つまたは複数の番号が暫定指標でないと解釈されるとよい。
【００１６】
提供されるユニット数および最終的な割り当てもまた、上記割り当てデータベースに格納され、最終的な販売が完了するたびに、上記最終的な割り当てが増やされ、上記システムが、上記割り当てがまだ上記提供されるユニット数を下回っているかどうか判定することによって、販売を行うことができるかどうかを決定することが好ましい。上記方法が、上記割り当ての増加に応じて上記最終的な割り当てが増加するたびに、上記着呼に対応する暫定指標によりすでに、上記暫定利用可能性が低減していることを確認し、そうでない場合は、上記暫定利用可能数量を減らすステップを含み、かつ／または、販売が確定されるたびに、支払い明細を含んだ注文レコードを作成するステップを含むことがさらに好ましい。
【００１７】
登録済み発呼者も未登録発呼者も上記オークションに参加することができることが好ましい。
【００１８】
上記方法が、発呼した電話番号を判定し、これを登録済み利用者の顧客データベースと比較し、上記比較が一致した場合、上記格納された顧客細目を上記発呼者に割り当てるステップを含み、かつ／または、暫定指標、初期および最終的な価格および／または販売数などのイベントを競りデータベースに格納するステップを含むことが好ましい。一致するものがない場合、上記発呼者に上記ユニットを販売する上記コールオペレータまたはシステムが、上記発呼者の細目を取得し、該細目をその電話番号と共に、今後使用するために上記顧客データベースに入れるステップを含み、かつ／または、個々の発呼者と関連づけられたイベントが、上記着呼データベースまたは上記顧客データベースなどの、その発呼者にリンクされた上記競りデータベースに格納され、発呼者が特定されると、予め格納されたデータが呼び出されることが好ましく、かつ／または、１つの暫定指標が、上記オークションの１つまたは複数のイベントの上記競りデータベース内の履歴イベントとの比較を含み、かつ／または、１つの暫定指標は、発呼者が頻出する消費パターン履歴を有することが判明しているといった、上記競りデータベースに格納された特定された発呼者のイベントを含むことがさらに好ましい。
【００１９】
暫定指標を示す発呼者が利用可能なユニットよりも多い場合には、該発呼者らの着呼レコードにおいて時刻がより早い発呼者に上記ユニットを販売するか、または適切な暫定指標を示す上記発呼者に上記ユニットを販売し、更に、上記適切な暫定指標を示す発呼者が利用可能なユニットよりも多い場合には、上記適切な指標をしており、より早い格納時刻を有する上記発呼者に上記ユニットを販売することが好ましい。
【００２０】
上記発呼者が発呼した時刻に上記オークションの構成要素であった上記商品もまた、上記着呼データベースに格納され、上記発呼者が上記オペレータまたはシステムにつながると、上記発呼者へ販売するために提供される上記ユニットが、上記着呼レコードに格納された商品から決定されることが好ましく、上記オークションが別の商品の販売に使用され、上記暫定利用可能数量が上記所定の数まで下がった後、好ましくはすべての販売が完了する前、または上記最終的な割り当てがいくらかでも増加する前に、上記別の商品が新しい発呼者のための上記着呼データベースに格納され、新しい発呼者を含む発呼者が上記別の商品のための上記リバースオークションに参加する場合に、発呼者が電話をかけるための電話番号として上記第１の商品のために提供されたのと同じ電話番号が提供されることが更に好ましい。
【００２１】
上記番号の１つが上記オークションで上記商品を購入する意志の確認を構成するのが好ましい。上記キーパッドの正しい番号が発呼者によって押されていなければ、または上記発呼者がその後注文に進まなければ、上記暫定利用可能数量が減らされないことがより好ましい。
【００２２】
電話だけでなく、インターネットによっても注文をすることができるとよい。上記オークションは、上記インターネットを介して伝達され、テレビなどの別の媒体でも伝達されることが好ましく、かつ／または、オークション・ユニットをショッピングカートに入れるなどといった、上記インターネット上で購入する意志を知らせる利用者の行為が暫定指標を構成してもよく、かつ／または上記最終的な割り当てを増やすことができるとより好ましい。
【００２３】
上記オークションで不首尾に終わった１人または複数の発呼者は、上記オークション後において、他の販売を行うため、または細目を調べられるために、該発呼者の判定された電話番号を使用して折り返し電話されることが好ましい。発呼者は、上記オークション中、該発呼者の着呼に対応する１つまたは複数の暫定指標に基づいて、折り返し電話されたり、折り返し電話されなかったりし、かつ／または、着呼レコードを注文レコードと照合し、一致する発呼者を、折り返し電話するためのリストから削除することによって、上記オークションで不首尾に終わった１人または複数の発呼者の特定が行われ、かつ／または、着呼ごとに一意の番号を生成し、それを両方のレコードに格納することによって、上記注文レコードと着呼レコードとの照合が行われることがより好ましい。
【００２４】
上記注文レコードを上記顧客データベース内のデータと照合し、上記顧客データベース内に格納された該データに対応する電話番号を使用することによって、電話番号が記録された着呼レコードと該データとを結び付け、続いてその着呼レコードと注文レコードとをタグ付けることにより、前記注文レコードと着呼レコードとの照合が行われると更によい。
【００２５】
人またはシステムが上記暫定利用可能数量の低減を要求するステップと、上記要求した低減数を予定最大販売数量と比較することによって、上記要求の低減を行うことができるかどうか判定するステップと、「上記開始値−上記予定最大販売数量」を下回る数まで上記利用可能暫定数量を減らす減数を許可しないステップとを含むことが好ましい。上記要求された低減数により上記暫定数量が上記予定最大販売数量を下回るまで減らされることとなるが、それに代えて、上記暫定数量が上記開始値から上記予定最大販売数量を減算した値まで減らされ、かつ／または、上記最大値が、上記受信された着呼および任意のウェブサイトの注文の総数および／または上記販売プロセスを済ませた発呼者によって購入された追加のユニット数を合計することによって計算されることがより好ましい。
【００２６】
上記表示された利用可能な数量がゼロに達すると、上記価格が凍結され、上記オークションの全ての上記ユニットが上記凍結された価格で販売され、かつ／または、テレビ上とほぼ同時にウェブサイト上で上記オークションに関する情報を提供し、上記オークションへの参加を上記インターネットから行うことを可能にするステップを含むことが好ましい。
【図面の簡単な説明】
【００２７】
【図１】本発明によるシステムのアーキテクチャの概略図である。
【図２】本発明の一部分を形成する着呼レコードの説明図である。
【図３ａ】本発明に従って保持される注文レコードのカテゴリの概略図である。
【図３ｂ】本発明に従って保持される顧客レコードのカテゴリの概略図である。
【図４】本発明に従ってオークションを実施するプロセスのフローチャート図である。
【図５】リバースオークションの決定がそれを基に行われる割り当てを、減らすことができるかどうか検証するプロセスのフローチャート図である。
【図６】支払いの仕組みのフローチャート図である。
【図７】注文票に修正を行うフローチャート図である。
【図８】本発明に従って、図２の着呼レコードと図３の注文レコードなど、着呼レコードを注文レコードと照合するプロセスのフローチャート図である。
【図９】注文履歴をチェックするフローチャート図である。
【図１０】注文をキャンセルするプロセスのフローチャート図である。
【図１１】支払い明細を変更するプロセスのフローチャート図である。
【図１２】クレジットカードを認証するフローチャート図である。
【発明を実施するための形態】
【００２８】
次に、本発明の実施形態を、添付の図面を参照して説明するが、これは単なる例に過ぎない。
【００２９】
図１を参照すると、中央コンピュータシステム１２、着呼受信機１４、通信アプリケーションモニタ１６、コールセンタ１８、ウェブサイト２０、競りデータベース２２、テレビプロデューサ２４、放送グラフィックス・コンポーネント／コンピュータ２６および配達システム２８を備えるシステム１０が示されている。構成部品１４〜２８は、代替実施形態で、コンピュータシステム１２の一部分を形成してもよい。着呼通信アプリケーション１６は、着呼受信機１４およびコールセンタ１８を監視することができる。着呼受信機１４もまた、コールセンタ１８と通信状態にある。
【００３０】
コンピュータシステム１２は、様々なデータベースおよびプロセッサ１３を備える。このシステムは、着呼レコード３２が格納された着呼データベース３０と、電話検索システム３４と、顧客レコード３７を有する顧客データベース３６と、注文レコード４０を有する注文データベース３８と、商品割り当て４４を有する商品データベース４２とを備える。
【００３１】
着呼受信機１４は、交換機からの着呼を受け付けることができ、かかる着呼の受信は、着呼モニタアプリケーション１６によって監視され、この着呼は最終的に、コンピュータシステム１２によりコールセンタ１８につなぐことができる。着呼受信機１４は、着呼データベース３０と通信し、コールセンタ１８は、着呼データベース３０及び注文データベース３８の両方と通信する。
【００３２】
注文データベース３８および商品データベース４２は、配達システム２８と通信する。
【００３３】
図２は、着呼レコード３２をより詳細に示した図である。着呼レコードが、データを入力できる一連のカテゴリを有していることがわかる。実際には、このカテゴリは、データベースエントリのフィールドになる。このフィールドは、基準日付１０２、コールＩＤ１０４、コール番号１０６、受信１１０、受付時間１１２、応答１１４、クリア１１６、商品ＩＤ１１８、受付価格１２０、チャンネル１２２、および内線１２４である。
【００３４】
基準日付１０２は、着呼受信機１４で着呼が最初に受信された時刻および日付に関連するデータを含む。着呼受信機１４で着呼毎にタイムスタンプが付与され、それが新規に作成された着呼レコード３２に記録される。コールＩＤ１０４は、その着呼に付与される識別番号である。これは、各着呼レコード３２に対して一意の番号とすることが可能であり、より好ましくは、基準日付１０２と組み合わされて着呼レコード３２の一意の識別子として使用されるとよい。例えば、これは、新しい着呼レコード機能が作成されるたびに、順番に次の番号に進む、４桁などの固定桁数を有する循環式の番号を生成する生成器によって生成することが可能である。この固定桁数は最終的にはゼロに戻るが、コールＩＤ１０４の識別番号と基準日付１０２とを組み合わせることによって、各着呼を一意的に識別することが可能である。これには、基準日付１０２で記録されている最小時間間隔の範囲内で取得される総着呼数が、コールＩＤ１０４で利用可能な整数の総数よりも小さいことが必要である。例えば、これは、基準日付１０２が着呼した時刻の秒を含み、かつ、コールＩＤ１０４が４桁とされていてもよい。システム１０における１秒毎の着呼数は９，９９９件を超えることなどあり得ないので、基準日付１０２およびコールＩＤ１０４を使用して各着呼レコード３２を一意的に識別することが可能である。
【００３５】
コール番号１０６は、発呼者が発呼に使用した電話番号に対する一意の識別子である。これは、多くの場合、電話会社から自動的に取得することができる。英国では例えば、これは発呼者ライン識別として知られ、それに関連付けられたＣＬＩＤすなわちＣａｌｌｅｒ Ｌｉｎｅ Ｉｄｅｎｔｉｆｉｅｒ（発呼者回線識別子）を有するシステムによって行われる。その他の国では、本発明に関する限り同様の効果がある、ＡＮＩすなわちＡｕｔｏｍａｔｉｃ Ｎｕｍｂｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ（自動番号識別）とよばれるシステムを使用することができる。一部の国や状況では、場合によってＣＬＩＤの提供が保証されない。例えば、ＣＬＩＤの提供を発呼者が伏せることができる場合がある。１つにはこの理由のため、システム１０では、着呼レコード３２の識別に、コールＩＤフィールド１０４を使用することが好ましい。
【００３６】
受信フィールド１１０は、着呼を受信した日付および時刻を格納するので、基準日付１０２のフィールドによく似ている。このフィールドは、基準日付１０２より詳細に時刻を示す情報など（例えば、秒ではなくミリ秒など）、追加の情報を含むことができる。基準日付１０２は、主に一意の識別を可能とするためにコールＩＤ１０４と共に使用される。よって、ゼロに戻る循環式コールＩＤカウンタ用に使用される時間間隔よりも細かく時刻を記録する必要はない。こういった理由のために、２人の発呼者のうちどちらが先に着呼したか決定しようとする場合には、受信フィールドが使用される。
【００３７】
受付時間１１２は、発呼者が電話のキーパッドの数字１を押したことを着呼監視コンポーネント１６が検出した時刻および日付を含む。数字１を押すことによって、その通話はコールセンタ１８の販売待ち行列に転送される。応答フィールド１１４は、コールセンタ１８において着呼に応答した日付および時刻を含み、クリア１１６は、販売の終了時にせよ、顧客による繰り上げ終了によるにせよ、その電話へのリンクが終了した日付および時刻を格納する。商品ＩＤ１１８は、基準日付１０２のエントリに対応する時刻に、画面上にあった商品の商品コードを含む。
【００３８】
商品コードは、どの商品が画面上にあったかを一意に識別することができる。したがって、顧客がどの商品を購入しようとしていたかを一意に識別することができる。受付価格フィールド１２０は、着呼が受信された時刻、すなわち、受信基準時刻１１０において画面上にあったユニットの有効価格を含む。チャンネル１２２は、発呼者が視聴していたチャンネルを格納する。オークションが複数のテレビチャンネルにわたって行われる実施形態においては、チャンネル１２２は、利用者が選局した番号によって決定されるチャンネルを格納する。例えば、システム１０は、別個の電話番号がそれぞれ与えられた３つの異なるテレビチャンネルを有することとしてもよい。着呼受信機１４が着呼する電話番号を検出することによって、利用者がどこのチャンネルをいつの日付に視聴していたかを判別でき、これにより、その利用者がどのオークションに参加していたかを判定することができる。
【００３９】
最後に、内線フィールド１２４は、コールセンタ１８でその通話が転送された応答内線番号を格納する。この内線フィールドは、着呼の応答が行われた後に初めて、応答フィールド１１４が埋まるのと同時に作成される。
【００４０】
ウェブ利用者がウェブサイト２０を使用すると、該当する場合には着呼レコード３２のフィールドに対応するフィールドを使用して、データベースにレコードが作成される。こういったレコードは、別個のデータベースにも、着呼データベース３０にも格納することができる。
【００４１】
図３ａには、注文レコード４０の一例が示されている。注文レコード４０は、フィールドを含み、データベースのエントリとして機能する。注文レコード４０は、顧客名２０２、住所２０４、電話番号２０６、商品コード２０８、追加品目２１０、支払い明細２１２、価格２１４および、場合によっては、基準日付における対応コールＩＤ２１６の、各フィールドを含む。
【００４２】
商品コード２０８は、通信監視システム１６が注文レコード４０に対応する着呼レコード３２の商品コードを判定することにより埋められる。ただし、これは、細目が間違っていることが判明した場合にコールセンタ１８によって変更可能とされている。電話番号フィールド２０６のデータは、ＣＬＩＤから監視コンポーネント１６によって提供されたものを発呼者が確認しても、あるいは、発呼者との対話から、コールセンタ１８でコールセンタオペレータが取得してもよい。住所２０４フィールドおよび顧客名２０２フィールドは、顧客レコード３７から提供されるか、またはコールセンタ１８のオペレータによって取得される。追加品目フィールド２１０を設けることによって、例えばオークション商品のケースやギフト用の箱など、オークションにかけられているユニットに付属する商品をシステム１０で販売することが可能になる。
【００４３】
価格フィールド２１４は、システム１０によって埋められる。システム１０は、オークションにかけられている商品の現在表示価格を判定することによって、又は、受付価格１２０から、或いは、競りデータベース２２に格納されているオークションの最終価格から価格フィールド２１４を埋める。
【００４４】
対応コールＩＤフィールド２１６は、対応する着呼レコード３２のコールＩＤフィールド１０４および基準日付１０２から得られるデータで埋めることができる。
【００４５】
図３ｂには、顧客データベース３６のエントリが示されている。レコード３７は、顧客名２２２、住所２２４、１つまたは複数の電話番号２２６、２２８、２２９、および参照番号２２７の各フィールドを含む。
【００４６】
図４に、運営されるリバースオークションのプロセスが示されている。このプロセスは、ステップＳ３００から開始する。テレビプロデューサ２４は、人であっても、ある決まった所定のアルゴリズムに従う自動化されたコンピュータであってもよい。このテレビプロデューサ２４はまた、手動でオーバーライドできる自動化アルゴリズムを使用した、上記２つの組み合わせであってもよい。
【００４７】
ステップＳ３０２で、テレビプロデューサ２４は、選択された商品の商品コードを入力する。これは、その日の好ましいスケジュールを示すよう開発された所定の商品注文リスト８０からのものであっても、あるいはその他、任意のコードであってもよい。次のステップＳ３０４で、コンピュータシステム１２により、この選択された商品に関する情報が商品データベース４２から呼び出され、必要となるその詳細事項が、競りデータベース２２と放送グラフィックス・コンピュータ２６に送られる。商品自体の詳細事項だけでなく、その商品が用いられた以前の競りの詳細事項もまた提供される。こういった以前の競りの詳細事項により、その商品がどの時刻にどのように良く売れたかが、テレビプロデューサ２４に示される。これにより、テレビプロデューサ２４が、自動にしろ手動にしろ、商品をいつ、どのように販売すべきか判定することが可能になる。この情報は、商品割り当て４４を含んだ商品データベース４２や、競りデータベース２２に格納された競りの過去の履歴から引き出すことができる。
【００４８】
次のステップ３０６で、コンピュータシステム１２が、テレビプロデューサ２４に、この競りを開始したいかどうかを質問する。テレビプロデューサが以前の履歴を調べ、その時刻にその競りを開始するのは適していないと判断し、したがって「いいえ」と判定した場合には、このプロセスはＳ３０２に戻る。プロデューサ２４が「はい」と判断した場合には、このプロセスはステップＳ３０８へと続く。
【００４９】
ステップＳ３０８で、テレビプロデューサ２４は番組司会者の名前、テレビプロデューサが人の場合には自分自身の名前、及びユニットの開始数量を入力する。次いで、ステップＳ３１２で競りが開始される。このとき、このステップＳ３０８およびＳ３１０で入力された全ての情報は、プロセスが繰り返された場合のステップＳ３０４における今後の呼び出しに備えて、競りデータベース２２の履歴記録に入力される。
【００５０】
次いで、ステップＳ３１４において、プロデューサ２４と、番組司会者と、場合によっては一般の人々により、テレビを閲覧するためのある決まった競りの画像が生成される。この画像は、ステップＳ３１８において、ユニットの統計データおよびデータシートを含むことができる。放送グラフィックス・コンピュータ２６によって表示された画像は、データ列をグラフィックス・デバイスへ送り、事前に作成されたテンプレートを呼び出すことによって変更される。
【００５１】
競りが開始されると、着呼監視デバイス１６により着呼が監視され、こういった呼に関する必要かつ／または有用な情報を、テレビプロデューサ２４が確認できるようになる。これにより、ステップ３２０において、放送グラフィックス２６を使用して、その場の画像（グラフィック）情報を放送することも可能になる。こういった情報は、現在の通話について目下発生していることに関するものでもよく、例えば、電話で競っている発呼者またはウェブ利用者の名前を、テレビ上に放送させて、その貢献度を知らせ、そのユニットは需要があると人々に感じさせることによって、需要をさらに喚起するために使用することも可能である。また、その他の係る競売時点の情報を放送してもよい。
【００５２】
ステップＳ３１６と同時に、着呼受信機１４およびコールセンタ１８において、テレビプロデューサ２４に送る情報の内容を左右する処理が行われる。これらの処理は、図４のステップＳ４００からステップＳ４０８を含む別枠に示されている。
【００５３】
最初に、ステップＳ４００において、着呼が受信され、新しい着呼レコード３２が作成され、基準日付フィールド１０２、コールＩＤフィールド１０４、コール番号フィールド１０６、および受信フィールド１１０が埋められる。電話の着信は、新たな通話毎（場合によっては、その基準日付１０２毎）の表示リスト等の形として、テレビプロデューサ２４にも通知される。
【００５４】
次に、注文する場合は１を、顧客サービスは２を、配達状況の確認は３を押すよう求める自動メッセージ、または係るその他の着呼手順の仕組みが、発呼者に対して通知される。
【００５５】
ステップＳ４０２で、発呼者によって１が押されると、監視コンポーネント１６は発呼者をコールセンタ１８の販売待ち行列に入れる。また、受付時間フィールド１１２も埋められる。また、ステップＳ４０２では、表示リスト上の通話細目の色を赤色から緑色へ変化させることなどにより、テレビプロデューサにも通知される。
【００５６】
また、システム１２は、発呼者の発呼者回線識別子ＣＬＩＤを調べ、このＩＤを使用して、発呼者の細目の検索を試みる。これは、電話番号検索コンポーネント３４および顧客データベース３６を介して行われる。発呼者番号１０４などのＣＬＩＤが、電話検索テーブル３４とつき合わせて比較される。一致するものが検出されると、電話検索テーブルより、顧客レコード３７の参照番号２２７に対応する参照値が与えられる。フィールド２２２および２２４からの顧客の名前および市町村が、テレビプロデューサ２４へ送信され、追加の細目が表示リスト上の通話に追加される。プロデューサは、ＣＬＩＤを直接確認しない、すなわちＣＬＩＤには直接アクセスするのではなく、この検索された情報を確認する。システム１２は、この特定の顧客レコード３２にリンクされた注文レコード４０の履歴があれば、それらの履歴から情報を収集し、テレビプロデューサ２４にそれらを示す。これにより、プロデューサは、発呼者の今までの購入傾向を閲覧することができる。
【００５７】
テレビプロデューサは、この提供された情報のいくつかを、番組司会者または視聴している一般の人々に、放送グラフィックス２６を使用して示すこととしてもよい。これにより、既知の利用者からのリバースオークションにおける値付け予想をテレビに出すことが可能になり、視聴者は、より積極的に参加しているように感じることが可能となる。
【００５８】
顧客データベース３６で直接検索するのではなく、別個の電話検索システム３４を使用するので、このシステムでは、複数の電話番号や、同一電話番号の複数の利用者にも対応することが可能となる。顧客データベース３６が、複数の、場合によっては重複する電話番号をそれぞれ入力できる複数のレコード３２を有する一方で、電話検索システム３４は、各電話番号に対して１つの名前だけしか使用することができない。一般に、この名前は、その番号から問題なく購入を行うための最新の発呼者と解釈される。したがって、このシステムでは、１つのシステムで一意のこの番号を、１つの特定の参照番号と照合することができ、顧客データベース３６からの対応する参照番号２７７を使用して、人の名前を検索することができる。
【００５９】
着呼は、受信された順、すなわち受信基準時刻１１２の順に販売待ち行列に入り、次いで、コールセンタ１８の内線番号に割り当てられる。ステップＳ４０４で着呼がコールセンタ１８のオペレータに応答されると、着呼モニタアプリケーション１６は、どのコール番号ＩＤ（場合によっては基準日付１０２と組み合わせたコールＩＤ１０４）が、どの内線番号と共にあるか記録する。着呼レコード３２内の応答フィールド１１４および内線フィールド１２４には、それぞれ時刻、応答内線が入る。
【００６０】
次のステップは、ステップＳ４０８における購入の確定となり、次いで最後に、Ｓ４１０で着呼をクリアすることができる。この２つのステップＳ４０８およびＳ４１０によって、着呼レコード３２のクリア・フィールド１１６が埋まる。ステップＳ４０６での購入の確定は、場合によっては緑色または赤色から青色への色の変化によって、テレビプロデューサに通知される。
【００６１】
テレビプロデューサ２４には、この監視プロセス中における様々な情報が与えられ、これら様々な情報には、識別された何人かの発呼者の細目、受信された着呼の番号、識別された発呼者のうちだれが１を押したか、そのうちだれが応答されたか、だれが確定プロセスまで進んだかといった情報が含まれている。これらは全て、利用者に対するユニットの販売および最終割り当てが行われる見込みがあるという、暫定指標を構成する。テレビプロデューサ２４は、自動的にこれらの暫定落札指標を使用することができ（または購入が確定の場合、確定落札指標）、あるいは人であるテレビプロデューサ２４が手動で使用することもできる。１つまたは複数の暫定指標に基づいて、テレビプロデューサ２４は、ステップＳ３２２またはステップＳ３２４に進むことが可能となる。
【００６２】
テレビプロデューサ２４が、着呼が十分受信されていない、あるいは商品が十分売れていないと考える場合、テレビプロデューサは、ステップＳ３２２に進む可能性がある。ここで、テレビプロデューサ２３は、これから行う値下げを入力し、次いでステップＳ３１６に戻る。価格は、１ポンドまたは１ドルなどの制限された幅だけしか下げることができないようにしてもよいし、あるいは、プロデューサ２４が、価格の劇的な下落が存在する、いわゆる「価格の暴落」を、放送グラフィックス２６から得られる適当に活発な実り多いグラフの付随情報によって示唆するよう指示してもよい。下がった価格は競りデータベース２２に格納される。競りデータベース２２は、任意の新しい着呼の受付価格フィールド１２０と任意の新しい注文の価格フィールド２１４とに、その価格データを簡単にコピーできる位置にある。競りデータベース２２は、金銭的損失が大きすぎる時点でプロデューサの販売を止めさせるために、商品に許される可能な最低価格を知らせることとしてもよい。
【００６３】
テレビプロデューサ２４は、着呼受信機１４およびコールセンタ１８におけるイベントからの暫定指標に応じて、商品の利用可能数量を減らしてもよい。利用者が、そのために、ステップＳ４０６で購入が確定されるのを待つ必要がないので有利である。購入の確定を待つと、オークションの進行が非常に遅くなり、数量がゆっくりとしか減らず、リバースオークションにかなりの時間がかかってしまうはずである。さらに、残っている大きな数量を見て、電話してくる新たな発呼者によって、限られた電話交換機容量の使用にかなりの負担がかかるはずである。実際は、購入を計画したけれどもまだステップＳ４０４に達していないそれ以前の発呼者数のために、新たな発呼者には獲得のチャンスはほとんどない。常にステップＳ４０６の完了を待ってからステップＳ３２４に進むこととすると、発呼者／ウェブ利用者対販売の比が大きくなり、オークション毎に、ウェブサイトと共にテレビの時間とスペースとが長々と使用されてしまう。電話交換機の容量、テレビの放送時間、およびウェブサイト２０にリンクするインターネットの帯域は、限られた資源であるので、理屈から言えば非効率的である。
【００６４】
その代わりとして、テレビプロデューサ２４は、発呼者または商品の販売履歴、及びオークションの際にステップＳ４０６において販売が確定されるまでに発生したそういったイベントの経時的類似性と比べるために、任意の数の暫定指数を使用することとしてもよい。この暫定指数には、着呼の時刻か、受信された着呼の数か、Ｓ４００において受信されている着呼か、Ｓ４０２において１を押している発呼者か、Ｓ４０４において応答されている着呼か、或いはこれらのうちのいずれかを含んでいる。最も一般には、テレビプロデューサ２４は、Ｓ４０２で１を押している発呼者を、ユニットがその発呼者に販売される可能性がある指標として使用する。利用者は、その発呼者が１を押した場合に数量を減らすかどうか、オークションが適当な時刻になっているかどうか、さらにその顧客が特定された場合には、その履歴も考慮することができる。例えば、ある競りにおいて、オークションの出だしに１を押した着呼は、販売につながるものではなく、オークション経路を通過することによって質問システムを迂回しようとしている発呼者による前の商品についての問い合わせとなることが、テレビプロデューサの経験と競りデータベース２２に格納されているイベントから分かる。したがって、１が押されても、ステップＳ３２４で数量が減らないようにしてもよい。あるいは、テレビプロデューサは、発呼者の経過履歴を考慮して、こういった通常の直感や指示を変更することができる。例えば、テレビプロデューサは顧客について思い出すことも、保存されているレコードから顧客の過去の行動を確認することもできる。これにより、通常なら不適当な時間に１を押したとしても、この場合は販売につながる可能性があるので、当てにすることができるということを顧客にほのめかすように導く。以上の全てを、競りデータベース２２内の過去の競りに基づく自動アルゴリズムによって行うことができる。
【００６５】
ステップＳ３２４で、テレビプロデューサ２４は、監視してきた着呼の活動状況に応じて、任意の数だけ数量を減らすことができる。次のステップＳ３２６で、コンピュータシステム１２は、現在の競りの対象物の在庫数がゼロに達したかどうかを判定する。ゼロに達していない場合は、ステップＳ３１６に戻る。テレビプロデューサ２４は、「開始数量−ステップＳ４００での総受信着呼数−競りの注文数およびウェブサイトでの注文数」を下回るレベルにまで、数量を減らすことができない（注文とは、ユニットをショッピングカート内に入れることを意味する）。
【００６６】
数量を減らすと、商品割り当て４４に格納された暫定利用可能数量が、その数まで減る。この暫定利用可能数量は、放送グラフィックス２６を使用して、司会者および一般に人々に示される。
【００６７】
ステップＳ３２６で暫定利用可能数量がゼロに達すると、このプロセスは、競りが終了するステップＳ３２８に進む。この終了は、競りデータベース２２に記録され、ステップＳ３３０に進む。ステップＳ３３０では、競りグラフィックスを終了するよう求められ、それが放送グラフィックス・コンポーネント２６に送信される。最後に、ステップ３３２において、既存の注文明細の行に価格の付け直しが行われる。競りの終了前に、ステップＳ４０６で注文レコードが埋められ、購入を確定することができる。したがって、価格の付け直しの仕組みは、競りの最も低い最終価格よりも高い価格に対して出された注文明細の行の価格を下げるために、定位置にある必要がある。この位置は、注文レコード内のフィールド価格２１４である。フィールド価格は、記録された着呼に関連付けられたフィールド１２０の価格、または、注文が切り替わるときの現在の価格に基づいている。また、この位置は、ステップＳ３２２における値下げにより、競りデータベースに格納されている最終価格まで下げられる。この確認は、その時点までの３０分内に完了した全ての競りに対して行われるが、任意の期間にわたって行うこととしてもよい。最低価格は、別個に運営されるウェブサイト２０のウェブ上の競りを含む必要はないが、含むこととしてもよい。注文の合計は、再計算される必要がある。この注文の合計には、注文明細行における価格の見直し後の値下げ率を申し込むクーポンなど、提示されている全てのクーポンが含まれる。
【００６８】
ウェブ注文伝票ＷＯは、ウェブサイト２０で作成することもできる。オンラインの顧客は一般に、事前登録するべきである。登録が済み、ログインすると、オンライン上の顧客は、商品をクリックして、それをショッピングカートに入れることができる。ウェブオークションは独立して実施することができる。あるいは、ウェブサイト２０をテレビ中継オークションに参加する代替媒体にすることも可能である。後者の場合、表示リストにウェブ注文伝票ＷＯが示され、通常、テレビプロデューサ２４はこれを暫定指標とする。ステップＳ３２４において、ユニットをショッピングカートの中に入れるウェブ利用者の暫定指標が与えられたとすると、商品購入に使用可能なウェブサイトにおける公知の方法と同じようなやり方で、数量を減らすようテレビプロデューサ２４に求めることができる。他の暫定指標と同様に、特にこのイベントが競りの早い時点であって価格がまだ高い場合には、プロデューサは数量低減の決定を先延ばしにしてもよい。これは、顧客が、ユニットをショッピングカートの中に入れてから数秒後にそれを削除することによって、このウェブサイトを試すことが可能だからである。
【００６９】
ユニットをショッピングカートの中に入れるという購入のためのクリックは、競りの終了３２８前に行わなければならない。ただし、精算プロセスは、ユニットをショッピングカートの中に入れてから数日後に行ってもよい。このためには、クレジットカード所有者の住所、配達先住所、および支払い明細を含んだ項目を埋めることが必要とされる。このユニットは、新しい注文レコード４０で取り扱われてもよく、或いは、顧客が配送料を節約するために、既存の注文レコード４０に追加されることも可能である。このとき、このような購入はＥメールによって確認することができる。
【００７０】
図５には、ステップＳ３２４において、テレビプロデューサ２４によって行われる暫定利用可能数量を減らす要求を処理するプロセスが示されている。
【００７１】
最初に、ステップＳ５００において、暫定利用可能数量を一定量減らす要求が受信される。次のステップＳ５０２において、プロセッサ１３は、着呼データベース３０にアクセスし、競りの間に受信された着呼の総数をカウントする。次のステップＳ５０４において、その着呼の総数が、システム１２のデータベース、またはサーバもしくは現在の競りに対応するウェブサイト２０を提供するサーバに格納されているウェブ注文伝票ＷＯの総数に追加される。
【００７２】
ステップＳ５０６において、数量が注文レコード４０から得られる数量より多い場合、システムは、競りに任意の増分数を追加する。発呼者はコールセンタ１８につながると、オークションで複数のユニットを購入することが許される。したがって、仮に、商品を１つではなく５つ購入したとすると、そのことが注文データベース３８にある追加の注文レコード４０に記録され、ステップＳ５０６において追加される。ステップＳ５０８において、着呼数と、ウェブ注文数と、ステップＳ５０２、５０４および５０６からの追加の販売数の合計とから販売できた予定最大数量が計算される。このことから、Ｓ５１０において、コンピュータシステム１２のプロセッサ１３は、「開始数量−予定最大販売数量」が「現在の画面上の数量−低減要求数」以下であるかどうか計算することにより、低減を要求されている数量を全数減らすことができるか否かを計算する。
【００７３】
ステップＳ５１０において、答えが「はい」の場合、システム１２は、ステップ５１２に進む。ステップ５１２では、商品割り当て４４の暫定利用可能数量が全要求数量だけ減らされる。割り当て４４を使用して、画面に表示されている数量が、要求された数量だけ減らされ、ウェブと同期をとるためのデータベースに格納される。次いで、プロセスの終了ステップＳ５２２に進む。このとき、メインのオークションプロセスは、ステップＳ３２６に続く。
【００７４】
販売せずに残しておくことが可能な予定最大数量を下回るまで、テレビプロデューサ２４が数量を減らそうとしているために、ステップＳ５１０において要求数を全数減らすことができない場合は、システムはステップＳ５１４に進む。ステップＳ５１４では、商品割り当て４４における暫定利用可能数量の低減数が、「開始数量−販売できた予定最大数量」までとなるように制限される。次のステップＳ５１６において、コンピュータシステム１２のプロセッサ１３が、修正された低減数が１を下回っていないかどうか判定する。１を下回っていない場合、ステップＳ５１８に進み、新しい修正された低減数だけ数量が減らされ、その後ステップＳ３２６に進む。修正された低減数が１を下回っている場合（すなわちゼロの場合）、ステップＳ５２０では現在の暫定利用可能数量は減らされず、ステップＳ３２６にプロセスが進み、Ｓ３１６に戻る。
【００７５】
図６には、クレジットカードによる支払いプロセスのフローチャートが示されている。
【００７６】
図７には、すでにある注文票についてのコールセンタのオペレータによる商品の修正プロセスが示されている。ステップＳ７００において、オペレータは商品の修正を試みる。ステップＳ７０２において、オペレータは、その商品が標準品なのか、元展示品なのかを判定する。標準品の場合は、ステップＳ７０４に進み、元展示品の場合は、ステップＳ７１８に進む。
【００７７】
ステップＳ７０４において、オペレータは、コンピュータシステム１２から、注文伝票のユニットの数量を変更したいかどうか質問を受ける。答えが「いいえ」の場合は、ステップＳ７１０に直接進む。答えが「はい」の場合は、ステップＳ７０６に進む。Ｓ７０６において、オペレータが割り当てられた数量を減らすと、商品データベース４２内の商品割り当て４４が減らされ、そのことが示される。このようにして、ステップＳ７０８において、まだ販売可能であり、人々に割り当て可能な未割り当ての数量が増やされる。このことは、商品データベース４２の商品割り当てコンポーネント４４にも記録される。
【００７８】
ステップＳ７１０で、システム１０は、現在の競りがテレビの競りであるか、単にウェブベースの競りのみであるか判定する。テレビの競りの場合はＳ７１２に進み、そうでない場合はステップＳ７１４に進む。Ｓ７１２では、価格がテレビの競りで入力された最低値に変更される。Ｓ７１４では、標準品の注文明細行が修正され、そのことが注文データベース３８に記録される。次いでステップＳ７１６において、伝票はいずれも再計算され、システムはステップＳ７２６に進む。
【００７９】
ステップＳ７１８、Ｓ７２０、およびＳ７２２は、変更点が、元展示品の割り当て数量を処理する商品割り当てコンポーネント４４の特殊コンポーネントであることを除いて、ステップＳ７０４、Ｓ７０６、およびＳ７０８と同一である。次いで、元展示品の注文明細行が修正されて、ステップＳ７２４に進み、ここでデータベース３８に記録された後、ステップＳ７１６に進む。
【００８０】
ステップＳ７２６で、送料、ＶＡＴ（付加価値税）および注文の合計が再計算され、Ｓ７２８で、これらの明細が注文データベース３８に保存される。
【００８１】
図８には、着呼と注文を照合するプロセスが示されている。時には、ステップＳ４０２において、顧客が１を押した後、ステップＳ４０４において着呼の応答が行われる前に競りを降りる場合がある。さらに、Ｓ４０４において、着呼の応答が行われた後、顧客がコールセンタ１８のオペレータと通話して購入しないと決定し、ステップＳ４０６が実施されない場合がある。また、ステップＳ４０６において、購入を確定しようと試みたが、支払い明細の認証を受けられなかったり、支払い明細が正しく取得されなかったりする場合がある。このような場合、通常は、その顧客らは十分な暫定指標を与えたことになり、その顧客らの着呼によって、テレビプロデューサ２４はステップＳ３２４において、割り当てコンポーネント４４の暫定利用可能数量を減らすことになる。しかしながら、割り当てコンポーネント４４の最終的な割り当てでは、販売も増数も行われない可能性があり、オークション終了後、ユニットが完売しない可能性がある。この場合、かかる顧客に電話を折り返して入れ、彼らにそのユニットをオークションの終値で注文するよう求めることが可能である。
【００８２】
この場合、ステップＳ４０２で１を押したが購入しなかった顧客は、いずれも着呼の応答が行われる前に電話を切ったとしてもある種の興味を示したのだから、このような顧客には連絡をとることが好ましい。かかる顧客は、そのＣＬＩＤが顧客データベース３６内のレコードと確実に照合できるように既に登録されていてもよく、あるいは未登録であってもよい。
【００８３】
適切な者にシステム１２から連絡を取ることができるようにするために、すでに注文が済んだ者に電話がかからないように、着呼レコード３２を注文レコード４０と照合する。
【００８４】
ステップＳ８００において、競りの開始と終了（Ｓ３１２とＳ３２８）の間に受信された着呼のリストが着呼データベース３０から取得される。ステップＳ８０２において、この着呼レコードが、電話検索システム３４を使用して顧客レコード３７と照合される。これに代えて、通信監視コンポーネント１６により、コールＩＤ１０４および基準日付１０２が全ての新規注文レコード４０および新規着呼レコード３２の追加フィールド２１６に入力されてもよい。これにより、注文レコード４０は、電話検索システム３４を必要とすることなく、フィールド２１６、１０２、および１０４のデータを比較することによって照合されることとなる。ステップＳ８０４では、顧客データベース３６において特定された顧客によってなされた全ての注文レコード４０にタグ付けが行われる。タグ付けされる情報には、サイズおよび／または色のオプションが提供される下位商品の検討項目も含まれる。次のステップＳ８０６において、電話によって手配される場合と同様に、ウェブ注文ＷＯが扱われる。
【００８５】
ステップＳ８０４およびＳ８０６の結果から、注文レコード４０は、顧客レコード３７に対してタグ付けされている。これにより、ステップＳ８０２においてその顧客レコードと合致することがわかっている着呼レコード３２に対して注文レコードをタグ付けすることができる。
【００８６】
したがって、ステップＳ８００からＳ８０６において、顧客および注文と照合された着呼のリスト８０８と、顧客と照合されたが注文明細行にリンクされていない着呼のリスト８１０と、顧客にも注文にも照合されていない着呼のリスト８１２と、顧客レコード３２と照合されたが着呼レコード３２とリンクされていない注文レコード４０のリスト８１４との、４つの別々のリストが得られる。
【００８７】
リスト８０８および８１０は、最終的なリスト８２４の一部分を形成するために送信される。ステップＳ８１６では、２つのリスト８１２と８１４とが比較される。ステップＳ８１６において、例えば、注文明細行が先入れ先出し形式であると想定した場合には、２つのリスト８１２と８１４とが照合される。先入れ先出しは、仮定としては単純すぎるが、これによって、着呼が異なる発呼者であった場合でも、落札が着呼レコード３２と照合されることとなる。ステップＳ８１６により、顧客および注文明細行と照合された、最終的なリスト８２４の一部分を形成するために送信される着呼のリスト８１８と、顧客３７とも注文レコード４０とも照合されない着呼のリスト８２０の、２つのリストが得られる。
【００８８】
ステップＳ８２２において、リスト８２０は、コール番号フィールド１０６にある全ての発呼者回線識別子から追加されたエリアコード情報を有し、既存の従来のデータベースからエリアコードおよびそれぞれのエリアを検索する。ステップＳ８２２の後、このリストの補足版８２０もまた最終的なリスト８２４の中に含められる。したがって、最終リスト８２４に含まれる着呼レコード３２およびウェブ注文のリストは、顧客および注文レコード４０と照合されたものと、顧客レコード３７と照合されたが注文レコード４０とリンクされていないものであってエリアコードを有する顧客とは照合されていないもの、または、エリアコードをもたない顧客とは照合されていないものになる。後者のリストは、例えばＣＬＩＤが無い場合、その番号は留保される。
【００８９】
注文レコード４０にリンクされていないがＣＬＩＤが利用可能な受付時間フィールド１１２にあるデータエントリを含んだ着呼のリストは、競りが終了し、その競りのために受信された着呼が全てクリアされた後、売れ残った商品を販売するために電話を折り返す顧客のベースを形成することができる。
【００９０】
図９には、ステップＳ４００、Ｓ４０２、およびＳ４０４をすでに済ませた、商品を購入しようとしている顧客、またはいずれの競りにも関係のない、コールセンタに直接電話をした顧客を照合するシステム１２のプロセスが示されている。このプロセスは、ステップＳ４００と同等のステップＳ９００から開始する。安売りユニットを一掃するのに役立つように記録を照合する場合など、競りが進行中でない状況では、システムは、直接ステップＳ９１６までスキップすることができる。あるいは、注文番号が直接使用された場合、ステップＳ９２８を経由して進むことができる。Ｓ９２８の場合は、コールセンタのオペレータが注文番号を入力してから、ステップＳ９３０に進む。
【００９１】
ステップＳ４０４と同等のステップＳ９０６において、着呼が受信された後、オペレータがその着呼に応答する。ステップＳ９０８において、コンピュータシステム１２が、発呼者がどの着呼レコード３２に対応するかについての情報を受け取るために、着呼モニタアプリケーション１６にアクセスする。着呼レコード３２は、商品ＩＤフィールド１１８を含んでおり、新しく作成された注文レコード４０の商品コードフィールド２０８にあるその商品の細目がオペレータに示される。さらに、ステップＳ９０８において、コールセンタ１８のオペレータは、パソコンにある顧客検索ボタンを押すなどして、システム１２から発呼者の顧客細目を要求して新しい注文レコード４０を表示させることができる。次いで、システム１２は、コール番号フィールド１０６に格納された発呼者ラインＩＤを使用して、顧客細目の検索を試みる。このとき、システムは、テレビプロデューサ２４に情報を提供する場合と同様に、電話検索システム３４を使用して、顧客データベース３６に顧客レコード３７があるかどうかを確認する。これは、オペレータが電話番号をキー入力する必要なく、コンピュータシステム１２によって自動的に行うことができる。というのは、オペレータが作業している内線がシステムで分かっており、かつ、ボタンを押したときに、その内線を使用している発呼者に対応する着呼レコード２０を検索することができるからである。
【００９２】
照合用の顧客レコード３７が検出されると、顧客の細目および過去の注文履歴の全てを、そのオペレータが利用できるようになり、該当する場合は、注文レコード４０の関連フィールドが埋められる。例えば、顧客名２０２、住所２０４、電話番号２０６を、照合される顧客レコード２０２から埋めることができ、商品フィールド２０８は、照合される着呼レコード３２およびその商品ＩＤフィールド１１８から埋めることができる。ＣＬＩＤが利用可能でない場合、あるいはその顧客の現在の電話番号が電話検索３４内に無い場合、オペレータは、顧客にその顧客の郵便番号を要求し、その郵便番号を使用して、顧客の位置の特定を試みる。オペレータは、発呼者にその発呼者の郵便番号を要求し、その郵便番号を使用して、顧客データベース３６を介して顧客レコード３７の検索を試みる。もちろん、それが顧客の最初の購入である場合は、レコード２７の位置は特定されない。
【００９３】
ＣＬＩＤから使用可能な顧客レコード３７が与えられない場合でも、着呼レコード３２から得られるＣＬＩＤから、やはり電話番号フィールド２０６を埋めることができる。かかる注文レコード４０が格納されると、その後の着呼と照合するために、新しい電話番号フィールド２０６を使用して電話番号検索テーブルにエントリが作成／更新される。
【００９４】
顧客レコードが検出できない場合は、オペレータが手作業で、細目の全てを要求し、注文レコード４０にその細目を入れると同時に、新しい顧客レコード３７を作成する。
【００９５】
ステップＳ９１０で、システムは、一時的な割り当てを作成するが、暫定指標として採用するために、この割り当てをテレビプロデューサに伝達できることが好ましい。これは、発呼者がこの時点で落札に進もうというその意志をしっかり確認しているので、単に「１」が押されたよりも強力な指標になる。発呼者が１を押さず、間違った番号を押し、そのまま進んで、オークションが終了する前になんとか購入を遂げる可能性もある。このような状況では、該当する場合は割り当ての数を減らすことができるように、その状況がテレビプロデューサ２４に示される。この一時割り当ての仕組みにより、実際の注文がコンピュータシステム１２に入るのにどのくらい時間がかかるかには関係なく、発呼者が順調にそのユニットを確保できるようになる。
【００９６】
ステップＳ９１２におけるユニットの落札確定後に、ステップＳ９１４にて、割り当て４４における最終的な商品割り当ての利用可能なユニット数が増やされ、販売可能な数が減らされる。
【００９７】
ステップＳ９１６において、顧客レコード３７が顧客データベース３６から検出される。次のステップＳ９１８において、コンピュータシステム１２および／またはオペレータが、そのレコードが正しく検出されたかどうかを判定する。正しく検出されなかった場合、ステップＳ９２０に進み、新しい顧客レコード３７が作成されて顧客データベース３６に入力され、次いでステップＳ９２２に進む。ステップＳ９１８で正しく検出された場合は、ステップＳ９２２に進む。
【００９８】
ステップＳ９２２では、顧客の注文履歴が顧客データベース３６から取り出され、さらに、対応する以前の注文が、注文データベース３８から、顧客レコード３７と合致する注文レコード４０を使用して検出される。次いで、各発呼者は、注文の新規作成を選択することも、新しい注文を既存の注文レコードに追加することもできる。注文が新規作成された場合はステップＳ９３４に進み、既存の注文レコードが選択された場合はステップＳ９２６に進む。ステップＳ９２６では特定の注文レコードが選択され、ステップＳ９３０でその細目が注文データベース３８から取得される。
【００９９】
次のステップＳ９３２において、システム１２は注文票が完成したかどうか判定する。完成した場合はステップＳ９４４に進み、完成していない場合はステップＳ９３８に進む。
【０１００】
ステップＳ９３４では、顧客の新しい注文レコード４０が作成され、その注文レコードが注文データベース３８に挿入される。ステップＳ９３６において、システム１２が、注文レコードがロックされたかどうかを判定する。ロックされた場合は、プロセスが中止され、ロックされていない場合は、ステップＳ９３８に進み、ステップＳ９１０の一時割り当ての有無をチェックする。一時割り当てが存在しない場合は、ステップＳ９４４に進む。一時割り当てが検出された場合は、ステップＳ９４０においてそれが削除され、ステップＳ９４２において、データベース３８に予め割り当てられているユニットの新しい注文レコードが作成される。
【０１０１】
ステップＳ９４４では、システムが、データベース３８から既存の注文票の上にその商品を呼び出す。次いでステップＳ９４６において、その注文票の顧客細目が呼び出される。ステップＳ９４８において、不正の有無をチェックする段階があり、疑いのある場合は、ステップＳ９５０において、その注文をキャンセルし、ステップＳ９５２に直接スキップすることができる。不正が存在しない場合は、ステップＳ９５４に進む。このとき注文票の見直しが行われ、最終的に完了する。
【０１０２】
次いで、注文をキャンセルするには、ステップＳ９５２に進み、変更を中止するにはステップＳ９５３に進む。その注文が既存のもので、変更が行われなかった場合は、マーケティングの情報源を記録するステップＳ９５６に進み、そうでない場合は注文票を計算し、変更を格納するステップＳ９５８に進む。ステップＳ９６０で、ステップＳ３５２、Ｓ９５３、およびＳ９５６の全てにより、関連する注文票が得られる。
【０１０３】
ステップＳ９５８の前に、このシステムまたはオペレータは、ユニットまたは伝票を追加することも、ユニットを修正することも、ユニットまたは伝票を削除することも、支払い明細を変更することも、配送住所を変更することも（国を変更した場合、ＶＡＴ支払額を変更することができる）、指定出荷日付を変更することもできる。ステップＳ９５８後、注文データベース３８に何らかの変更が保存された場合は、Ｓ９５４の注文票の見直し段階に戻ることができる。ステップＳ９５２、Ｓ９５４、およびＳ９５６の場合は、そのステップが終了した後にプロセスが終了する。
【０１０４】
ステップＳ９５６の前に、注文票を出荷可能行と欠品行に分割することも、データに応じて注文票を保存し、注文データベース３８にそれを格納することもできる。
【０１０５】
図１０には注文をキャンセルするプロセスが示され、図１１には支払い明細を変更するプロセスが示されている。
【０１０６】
図１２には、クレジットカードを認証するシステムが示されている。
【符号の説明】
【０１０７】
１０ システム
１２ 中央コンピュータシステム
１４ 着呼受信機
１３ プロセッサ
１６ 通信アプリケーションモニタ、着呼通信アプリケーション、着呼モニタアプリケーション、着呼監視アプリケーション
１８ コールセンタ
２０ ウェブサイト
２２ 競りデータベース
２４ テレビプロデューサ
２６ 放送グラフィックス・コンポーネント／コンピュータ
２８ 配達システム
３０ 着呼データベース
３２ 着呼レコード
３４ 電話検索システム
３６ 顧客データベース
３７ 顧客レコード
３８ 注文データベース
４０ 注文レコード
４２ 商品データベース
４４ 商品割り当て
１０２ 基準日付フィールド
１０４ コールＩＤフィールド
１０６ コール番号フィールド
１１０ 受信フィールド
１１２ 受付時間フィールド
１１４ 応答フィールド
１１６ クリア・フィールド
１１８ 商品ＩＤフィールド
１２０ 受付価格フィールド
１２２ チャンネルフィールド
１２４ 内線フィールド
２０２ 顧客名フィールド
２０４ 住所フィールド
２０６ 電話番号フィールド
２０８ 商品コードフィールド
２１０ 追加品目フィールド
２１２ 支払い明細フィールド
２１４ 価格フィールド
２１６ 対応コールＩＤフィールド
８０８ 顧客および注文と照合された着呼のリスト
８１０ 顧客と照合されたが注文明細行にリンクされていない着呼のリスト
８１２ 顧客にも注文にも照合されていない着呼のリスト
８１４ 顧客レコード３２と照合されたが着呼レコード３２とリンクされていない注文レコード４０のリスト
８１８ 顧客および注文明細行と照合された着呼のリスト
８２０ 顧客３７とも注文レコード４０とも照合されない着呼のリスト
８２４ 最終的な着呼およびウェブ注文のリスト
【特許請求の範囲】
【請求項１】
媒体によって利用者へ伝達され、ユニットを販売するための電話を基本としたリバースオークションを運営する方法であって、
販売するいくつかのユニットを提供し、販売に供される数を最初に示す割り当てデータベースに暫定利用可能数量を格納するステップと、
前記リバースオークションに参加するために発呼者が電話をかけることのできる電話番号を提供するステップと、
前記電話番号に１つまたは複数の着呼が受信された時刻を着呼データベースの着呼レコードに記録するステップと、
ユニットを販売するために、各発呼者を待ち行列に配置し、その発呼者をコールオペレータまたはシステムに割り当てるステップと、
人またはシステムが前記示されたユニットの価格を一定の期間にわたって下げ、プロデューサまたはシステムが前記暫定利用可能数量を減らすリバースオークションを運営するステップとを含み、
前記リバースオークションは、前記暫定利用可能数量がゼロなどの所定の数まで減った時刻に終了するとともに、前記終了時の価格はオークションデータベースに格納され、
前記暫定利用可能数量は、前記オークションのタイミングに対する前記着呼レコード内の前記着呼の受け付け時刻などの、着呼／発呼者と関連づけられた１つまたは複数の暫定指標に少なくとも部分的に基づいて減らされ、前記指標はユニットの販売が完了する前に発生する方法。
【請求項２】
前記コールオペレータまたはシステムにつながる着呼の順序が、前記着呼レコードの前記格納された時刻によって決まる請求項１に記載の方法。
【請求項３】
ユニットの販売価格は、前記オークションデータベースに格納された前記終了時の価格から決定される請求項１または請求項２に記載の方法。
【請求項４】
各発呼者にデータを１つ入力するよう促し、好ましくは、各発呼者を待ち行列に入れる前に各発行者にデータを１つ入力するよう促し、そのデータを前記着呼レコードに格納するステップを含む請求項１から請求項３のいずれかに記載の方法。
【請求項５】
前記着呼が待ち行列に配置されるかどうかは、前記入力されたデータによって決まる請求項４に記載の方法。
【請求項６】
１つの暫定指標は、前記入力されたデータを含むとともに前記着呼レコードに格納される請求項４または請求項５に記載の方法。
【請求項７】
１つの暫定指標は、前記データが入力されて前記着呼レコードに格納される時刻を含む請求項４から請求項６のいずれかに記載の方法。
【請求項８】
前記入力を促すステップは、前記利用者に、１つの番号をその利用者の電話に入力するよう促し、好ましくは、１つまたは複数の番号が暫定指標と解釈され、かつ、ゼロ、１つまたは複数の番号が暫定指標でないと解釈される請求項４から請求項７のいずれかに記載の方法。
【請求項９】
提供されるユニット数および最終的な割り当てもまた、前記割り当てデータベースに格納され、最終的な販売が完了するたびに前記最終的な割り当ては増やされ、前記システムは、未だに前記割り当てが前記提供されるユニット数を下回っているかどうかを判定することによって、販売を行うことができるかどうかを決定する請求項１から請求項８のいずれかに記載の方法。
【請求項１０】
前記割り当ての増加に応じて前記最終的な割り当てが増加するたびに、前記着呼に対応する暫定指標によりすでに、前記暫定利用可能性が低減していることを確認し、そうでない場合は、前記暫定利用可能数量を減らすステップを含む請求項９に記載の方法。
【請求項１１】
販売が確定されるたびに、支払い明細を含んだ注文レコードを作成するステップを含む請求項１から請求項１０のいずれかに記載の方法。
【請求項１２】
登録済み発呼者も未登録発呼者も前記オークションに参加することができる請求項１から請求項１１のいずれかに記載の方法。
【請求項１３】
発呼した電話番号を判定し、これを登録済み利用者の顧客データベースと比較し、前記比較が一致した場合、前記格納された顧客細目を前記発呼者に割り当てるステップを含む請求項１から請求項１２のいずれかに記載の方法。
【請求項１４】
一致するものがない場合、前記発呼者に前記ユニットを販売する前記コールオペレータまたはシステムが、前記発呼者の細目を取得し、該細目を発呼した電話番号と共に、今後使用するために前記顧客データベースに格納する請求項１３に記載の方法。
【請求項１５】
暫定指標、初期および最終的な価格、および／または販売数などのイベントを競りデータベースに格納するステップを含む請求項１から請求項１４のいずれかに記載の方法。
【請求項１６】
個々の発呼者と関連づけられたイベントが、前記着呼データベースまたは前記顧客データベースなどの、その発呼者にリンクされた前記競りデータベースに格納され、好ましくは、発呼者が特定された場合に、予め格納されたデータが呼び出される請求項１５に記載の方法。
【請求項１７】
１つの暫定指標は、前記オークションにおける１つまたは複数のイベントと前記競りデータベース内の履歴イベントとの比較を含む請求項１５に記載の方法。
【請求項１８】
１つの暫定指標は、発呼者が頻出する消費パターン履歴を有することが判明しているといった、前記競りデータベースに格納された特定された発呼者のイベントを含む請求項１６に記載の方法。
【請求項１９】
暫定指標を示す発呼者が利用可能なユニットよりも多い場合には、該発呼者らの着呼レコードにおいて時刻がより早い発呼者に前記ユニットを販売するか、または、適切な暫定指標を示す前記発呼者に前記ユニットを販売し、更に、前記適切な暫定指標を示す発呼者が利用可能なユニットよりも多い場合には、前記適切な指標を示しており、より早い格納時刻を有する前記発呼者に前記ユニットを販売する請求項１から請求項１８のいずれかに記載の方法。
【請求項２０】
前記発呼者が発呼した時刻に前記オークションの構成要素であった前記商品もまた、前記着呼データベースに格納され、前記発呼者が前記オペレータまたはシステムにつながると、前記発呼者へ販売するために提供される前記ユニットが、前記着呼レコードに格納された商品から決定される請求項１から請求項１９のいずれかに記載の方法。
【請求項２１】
前記オークションが別の商品の販売に使用され、
前記暫定利用可能数量が前記所定の数まで下がった後に、好ましくは、全ての販売が終了する前、または、前記最終的な割り当てがいくらかでも増加する前に、前記別の商品が新しい発呼者のために前記着呼データベースに格納され、
好ましくは、新しい発呼者を含む発呼者が前記別の商品のための前記リバースオークションに参加する場合に、発呼者が電話をかけるための電話番号として前記第１の商品のために提供されたのと同じ電話番号が提供される請求項２０に記載の方法。
【請求項２２】
前記番号の１つが前記オークションで前記商品を購入する意志の確認を構成する請求項８に従属した場合の請求項１から請求項２１のいずれかに記載の方法。
【請求項２３】
前記キーパッドの正しい番号が発呼者によって押されていない場合、または、前記発呼者がその後注文に進まない場合には、前記暫定利用可能数量は減らされない請求項２２に記載の方法。
【請求項２４】
電話だけでなく、インターネットによっても注文することができる請求項１から請求項２３のいずれかに記載の方法。
【請求項２５】
前記オークションは前記インターネットを介して伝達され、好ましくは、テレビなどの別の媒体でも伝達される請求項２４に記載の方法。
【請求項２６】
オークション・ユニットをショッピングカートに入れるなどいった、前記インターネット上で購入する意志を知らせる利用者の行為が暫定指標を構成してもよく、かつ／または、前記最終的な割り当てを増やすこととしてもよい請求項２４または請求項２５に記載の方法。
【請求項２７】
前記オークションで不首尾に終わった１人または複数の発呼者は、前記オークション後において、他の販売を行うためまたは細目を調べるために、該発呼者の判定された電話番号を使用して折り返し電話される請求項１から請求項２６のいずれかに記載の方法。
【請求項２８】
発呼者は、前記オークション中、該発呼者の着呼に対応する１つまたは複数の暫定指標に基づいて、折り返し電話されたり、折り返し電話されなかったりする請求項２７に記載の方法。
【請求項２９】
着呼レコードを注文レコードと照合し、一致する発呼者を折り返し電話するためのリストから削除することによって、前記オークションで不首尾に終わった１人または複数の発呼者の特定が行われる請求項２７に記載の方法。
【請求項３０】
着呼ごとに一意の番号を生成し、それを両方のレコードに格納することによって、前記注文レコードと着呼レコードとの照合が行われる請求項２９に記載の方法。
【請求項３１】
該注文レコードを前記顧客データベース内のデータと照合し、前記顧客データベース内に格納された該データに対応する電話番号を使用することによって、電話番号が記録された着呼レコードと該データとを結び付け、続いてその着呼レコードと注文レコードとをタグ付けることにより、前記注文レコードと着呼レコードとの照合が行われる請求項１１に従属した場合の請求項２９または請求項３０に記載の方法。
【請求項３２】
人またはシステムが前記暫定利用可能数量の低減を要求するステップと、
前記要求した低減数を予定最大販売数量と比較することによって、前記要求の低減を行うことができるかどうか判定するステップと、
「前記開始値−前記予定最大販売数量」を下回る数まで前記利用可能暫定数量を減らす減数を許可しないステップとを含む請求項２９から請求項３１のいずれかに記載の方法。
【請求項３３】
前記要求された低減数により前記暫定数量が前記予定最大販売数量を下回るまで減らされることとなるが、それに代えて、前記暫定数量が前記開始値から前記予定最大販売数量を減算した値まで減らされる請求項３２に記載の方法。
【請求項３４】
前記最大値は、前記受信された着呼および任意のウェブサイトの注文の総数および／または前記販売プロセスを済ませた発呼者によって購入された追加のユニット数を合計することによって計算される請求項３２または請求項３３に記載の方法。
【請求項３５】
ユニットのリバースオークションを運営するためのコンピュータシステムであって、
プロセッサと、
割り当てデータベース、オークションデータベース、および着呼データベースを含んだメモリと、
電話システムと、
ディスプレイとを備え、
前記割り当てデータベースは、オークションに提供されるユニット数を示す暫定利用可能数量を含み、
前記電話システムは、前記着呼データベースの着呼レコードに着呼が受信された時刻とダイヤルされた番号とを記録するように構成されるとともに、ユニットを販売するために、各発呼者を待ち行列に配置して、その発呼者をコールオペレータまたはシステムに割り当てるように構成され、
前記プロセッサは、前記ディスプレイに価格を表示し、前記表示された価格を一定の期間にわたって下げ、前記暫定利用可能数量を減らし、前記暫定利用可能数量がゼロなどの所定の数まで減るタイミングを判定し、その時刻で前記表示された価格を前記オークションデータベースに格納し、前記電話システムへ新しく着呼した通話が前記オークションに参加できないように構成され、
前記システムは、前記オークションのタイミングに対する前記着呼レコード内の前記着呼の受け付け時刻などの、着呼／発呼者と関連付けられた１つまたは複数の暫定指標に少なくとも部分的に基づいて前記暫定利用可能数量を減らし、前記指標がユニットの販売が終了する前に発生するコンピュータシステム。
【請求項３６】
テレビでリバースオークションによりユニットを販売する方法であって、
販売するためのユニットを、最初の価格および前記ユニットの前記オークションでの販売に利用可能な数と共にテレビに表示するステップと、
前記オークションに参加するための電話着呼を許可するステップと、
販売が行われる可能性がある、また行われたという十分な指標を発呼者が示していると考えられる場合に、前記表示された利用可能な数量が減らされるステップと、
より多くの発呼者を促し、前記テレビの前記オークションに費やされる時間を減らすために、前記ユニットの前記表示された価格を下げるステップと、
前記表示された利用可能な数量がゼロに達すると、前記オークションを終了するステップとを含む方法。
【請求項３７】
前記表示された利用可能な数量がゼロに達すると、前記価格が凍結され、前記オークションの全ての前記ユニットが前記凍結された価格で販売される請求項３６に記載の方法。
【請求項３８】
テレビ上とほぼ同時にウェブサイト上で前記オークションに関する情報を提供し、前記オークションへの参加を前記インターネットから行うことを可能にするステップを含む請求項３７に記載の方法。
【請求項３９】
媒体によって利用者へ伝達され、ユニットを販売するためのインターネットを基本としたリバースオークションを運営する方法であって、
販売するいくつかのユニットを提供し、販売に供される数を最初に示す割り当てデータベースに暫定利用可能数量を格納するステップと、
前記リバースオークションに参加するために利用者から注文を出すことができるウェブサイト購入機能を提供するステップと、
前記電話番号に１つまたは複数の注文が受信された時刻を着呼データベースの着呼レコードに記録するステップと、
ユニットを販売するために、各発呼者を待ち行列に配置し、その発呼者をコールオペレータまたはシステムに割り当てるステップと、
人またはシステムが前記示されたユニットの価格を一定の期間にわたって下げ、プロデューサまたはシステムが前記暫定利用可能数量を減らすリバースオークションを運営するステップとを含み、
前記リバースオークションは、前記暫定利用可能数量がゼロなどの所定の数まで減った時刻に終了するとともに、前記終了時の価格はオークションデータベースに格納され、
前記暫定利用可能数量は、前記オークションのタイミングに対する前記着呼レコード内の前記着呼の受け付け時刻などの、着呼／発呼者と関連づけられた１つまたは複数の暫定指標に少なくとも部分的に基づいて減らされ、好ましくは、前記指標はユニットの販売が完了／確定する前に発生する方法。
【請求項１】
媒体によって利用者へ伝達され、ユニットを販売するための電話を基本としたリバースオークションを運営する方法であって、
販売するいくつかのユニットを提供し、販売に供される数を最初に示す割り当てデータベースに暫定利用可能数量を格納するステップと、
前記リバースオークションに参加するために発呼者が電話をかけることのできる電話番号を提供するステップと、
前記電話番号に１つまたは複数の着呼が受信された時刻を着呼データベースの着呼レコードに記録するステップと、
ユニットを販売するために、各発呼者を待ち行列に配置し、その発呼者をコールオペレータまたはシステムに割り当てるステップと、
人またはシステムが前記示されたユニットの価格を一定の期間にわたって下げ、プロデューサまたはシステムが前記暫定利用可能数量を減らすリバースオークションを運営するステップとを含み、
前記リバースオークションは、前記暫定利用可能数量がゼロなどの所定の数まで減った時刻に終了するとともに、前記終了時の価格はオークションデータベースに格納され、
前記暫定利用可能数量は、前記オークションのタイミングに対する前記着呼レコード内の前記着呼の受け付け時刻などの、着呼／発呼者と関連づけられた１つまたは複数の暫定指標に少なくとも部分的に基づいて減らされ、前記指標はユニットの販売が完了する前に発生する方法。
【請求項２】
前記コールオペレータまたはシステムにつながる着呼の順序が、前記着呼レコードの前記格納された時刻によって決まる請求項１に記載の方法。
【請求項３】
ユニットの販売価格は、前記オークションデータベースに格納された前記終了時の価格から決定される請求項１または請求項２に記載の方法。
【請求項４】
各発呼者にデータを１つ入力するよう促し、好ましくは、各発呼者を待ち行列に入れる前に各発行者にデータを１つ入力するよう促し、そのデータを前記着呼レコードに格納するステップを含む請求項１から請求項３のいずれかに記載の方法。
【請求項５】
前記着呼が待ち行列に配置されるかどうかは、前記入力されたデータによって決まる請求項４に記載の方法。
【請求項６】
１つの暫定指標は、前記入力されたデータを含むとともに前記着呼レコードに格納される請求項４または請求項５に記載の方法。
【請求項７】
１つの暫定指標は、前記データが入力されて前記着呼レコードに格納される時刻を含む請求項４から請求項６のいずれかに記載の方法。
【請求項８】
前記入力を促すステップは、前記利用者に、１つの番号をその利用者の電話に入力するよう促し、好ましくは、１つまたは複数の番号が暫定指標と解釈され、かつ、ゼロ、１つまたは複数の番号が暫定指標でないと解釈される請求項４から請求項７のいずれかに記載の方法。
【請求項９】
提供されるユニット数および最終的な割り当てもまた、前記割り当てデータベースに格納され、最終的な販売が完了するたびに前記最終的な割り当ては増やされ、前記システムは、未だに前記割り当てが前記提供されるユニット数を下回っているかどうかを判定することによって、販売を行うことができるかどうかを決定する請求項１から請求項８のいずれかに記載の方法。
【請求項１０】
前記割り当ての増加に応じて前記最終的な割り当てが増加するたびに、前記着呼に対応する暫定指標によりすでに、前記暫定利用可能性が低減していることを確認し、そうでない場合は、前記暫定利用可能数量を減らすステップを含む請求項９に記載の方法。
【請求項１１】
販売が確定されるたびに、支払い明細を含んだ注文レコードを作成するステップを含む請求項１から請求項１０のいずれかに記載の方法。
【請求項１２】
登録済み発呼者も未登録発呼者も前記オークションに参加することができる請求項１から請求項１１のいずれかに記載の方法。
【請求項１３】
発呼した電話番号を判定し、これを登録済み利用者の顧客データベースと比較し、前記比較が一致した場合、前記格納された顧客細目を前記発呼者に割り当てるステップを含む請求項１から請求項１２のいずれかに記載の方法。
【請求項１４】
一致するものがない場合、前記発呼者に前記ユニットを販売する前記コールオペレータまたはシステムが、前記発呼者の細目を取得し、該細目を発呼した電話番号と共に、今後使用するために前記顧客データベースに格納する請求項１３に記載の方法。
【請求項１５】
暫定指標、初期および最終的な価格、および／または販売数などのイベントを競りデータベースに格納するステップを含む請求項１から請求項１４のいずれかに記載の方法。
【請求項１６】
個々の発呼者と関連づけられたイベントが、前記着呼データベースまたは前記顧客データベースなどの、その発呼者にリンクされた前記競りデータベースに格納され、好ましくは、発呼者が特定された場合に、予め格納されたデータが呼び出される請求項１５に記載の方法。
【請求項１７】
１つの暫定指標は、前記オークションにおける１つまたは複数のイベントと前記競りデータベース内の履歴イベントとの比較を含む請求項１５に記載の方法。
【請求項１８】
１つの暫定指標は、発呼者が頻出する消費パターン履歴を有することが判明しているといった、前記競りデータベースに格納された特定された発呼者のイベントを含む請求項１６に記載の方法。
【請求項１９】
暫定指標を示す発呼者が利用可能なユニットよりも多い場合には、該発呼者らの着呼レコードにおいて時刻がより早い発呼者に前記ユニットを販売するか、または、適切な暫定指標を示す前記発呼者に前記ユニットを販売し、更に、前記適切な暫定指標を示す発呼者が利用可能なユニットよりも多い場合には、前記適切な指標を示しており、より早い格納時刻を有する前記発呼者に前記ユニットを販売する請求項１から請求項１８のいずれかに記載の方法。
【請求項２０】
前記発呼者が発呼した時刻に前記オークションの構成要素であった前記商品もまた、前記着呼データベースに格納され、前記発呼者が前記オペレータまたはシステムにつながると、前記発呼者へ販売するために提供される前記ユニットが、前記着呼レコードに格納された商品から決定される請求項１から請求項１９のいずれかに記載の方法。
【請求項２１】
前記オークションが別の商品の販売に使用され、
前記暫定利用可能数量が前記所定の数まで下がった後に、好ましくは、全ての販売が終了する前、または、前記最終的な割り当てがいくらかでも増加する前に、前記別の商品が新しい発呼者のために前記着呼データベースに格納され、
好ましくは、新しい発呼者を含む発呼者が前記別の商品のための前記リバースオークションに参加する場合に、発呼者が電話をかけるための電話番号として前記第１の商品のために提供されたのと同じ電話番号が提供される請求項２０に記載の方法。
【請求項２２】
前記番号の１つが前記オークションで前記商品を購入する意志の確認を構成する請求項８に従属した場合の請求項１から請求項２１のいずれかに記載の方法。
【請求項２３】
前記キーパッドの正しい番号が発呼者によって押されていない場合、または、前記発呼者がその後注文に進まない場合には、前記暫定利用可能数量は減らされない請求項２２に記載の方法。
【請求項２４】
電話だけでなく、インターネットによっても注文することができる請求項１から請求項２３のいずれかに記載の方法。
【請求項２５】
前記オークションは前記インターネットを介して伝達され、好ましくは、テレビなどの別の媒体でも伝達される請求項２４に記載の方法。
【請求項２６】
オークション・ユニットをショッピングカートに入れるなどいった、前記インターネット上で購入する意志を知らせる利用者の行為が暫定指標を構成してもよく、かつ／または、前記最終的な割り当てを増やすこととしてもよい請求項２４または請求項２５に記載の方法。
【請求項２７】
前記オークションで不首尾に終わった１人または複数の発呼者は、前記オークション後において、他の販売を行うためまたは細目を調べるために、該発呼者の判定された電話番号を使用して折り返し電話される請求項１から請求項２６のいずれかに記載の方法。
【請求項２８】
発呼者は、前記オークション中、該発呼者の着呼に対応する１つまたは複数の暫定指標に基づいて、折り返し電話されたり、折り返し電話されなかったりする請求項２７に記載の方法。
【請求項２９】
着呼レコードを注文レコードと照合し、一致する発呼者を折り返し電話するためのリストから削除することによって、前記オークションで不首尾に終わった１人または複数の発呼者の特定が行われる請求項２７に記載の方法。
【請求項３０】
着呼ごとに一意の番号を生成し、それを両方のレコードに格納することによって、前記注文レコードと着呼レコードとの照合が行われる請求項２９に記載の方法。
【請求項３１】
該注文レコードを前記顧客データベース内のデータと照合し、前記顧客データベース内に格納された該データに対応する電話番号を使用することによって、電話番号が記録された着呼レコードと該データとを結び付け、続いてその着呼レコードと注文レコードとをタグ付けることにより、前記注文レコードと着呼レコードとの照合が行われる請求項１１に従属した場合の請求項２９または請求項３０に記載の方法。
【請求項３２】
人またはシステムが前記暫定利用可能数量の低減を要求するステップと、
前記要求した低減数を予定最大販売数量と比較することによって、前記要求の低減を行うことができるかどうか判定するステップと、
「前記開始値−前記予定最大販売数量」を下回る数まで前記利用可能暫定数量を減らす減数を許可しないステップとを含む請求項２９から請求項３１のいずれかに記載の方法。
【請求項３３】
前記要求された低減数により前記暫定数量が前記予定最大販売数量を下回るまで減らされることとなるが、それに代えて、前記暫定数量が前記開始値から前記予定最大販売数量を減算した値まで減らされる請求項３２に記載の方法。
【請求項３４】
前記最大値は、前記受信された着呼および任意のウェブサイトの注文の総数および／または前記販売プロセスを済ませた発呼者によって購入された追加のユニット数を合計することによって計算される請求項３２または請求項３３に記載の方法。
【請求項３５】
ユニットのリバースオークションを運営するためのコンピュータシステムであって、
プロセッサと、
割り当てデータベース、オークションデータベース、および着呼データベースを含んだメモリと、
電話システムと、
ディスプレイとを備え、
前記割り当てデータベースは、オークションに提供されるユニット数を示す暫定利用可能数量を含み、
前記電話システムは、前記着呼データベースの着呼レコードに着呼が受信された時刻とダイヤルされた番号とを記録するように構成されるとともに、ユニットを販売するために、各発呼者を待ち行列に配置して、その発呼者をコールオペレータまたはシステムに割り当てるように構成され、
前記プロセッサは、前記ディスプレイに価格を表示し、前記表示された価格を一定の期間にわたって下げ、前記暫定利用可能数量を減らし、前記暫定利用可能数量がゼロなどの所定の数まで減るタイミングを判定し、その時刻で前記表示された価格を前記オークションデータベースに格納し、前記電話システムへ新しく着呼した通話が前記オークションに参加できないように構成され、
前記システムは、前記オークションのタイミングに対する前記着呼レコード内の前記着呼の受け付け時刻などの、着呼／発呼者と関連付けられた１つまたは複数の暫定指標に少なくとも部分的に基づいて前記暫定利用可能数量を減らし、前記指標がユニットの販売が終了する前に発生するコンピュータシステム。
【請求項３６】
テレビでリバースオークションによりユニットを販売する方法であって、
販売するためのユニットを、最初の価格および前記ユニットの前記オークションでの販売に利用可能な数と共にテレビに表示するステップと、
前記オークションに参加するための電話着呼を許可するステップと、
販売が行われる可能性がある、また行われたという十分な指標を発呼者が示していると考えられる場合に、前記表示された利用可能な数量が減らされるステップと、
より多くの発呼者を促し、前記テレビの前記オークションに費やされる時間を減らすために、前記ユニットの前記表示された価格を下げるステップと、
前記表示された利用可能な数量がゼロに達すると、前記オークションを終了するステップとを含む方法。
【請求項３７】
前記表示された利用可能な数量がゼロに達すると、前記価格が凍結され、前記オークションの全ての前記ユニットが前記凍結された価格で販売される請求項３６に記載の方法。
【請求項３８】
テレビ上とほぼ同時にウェブサイト上で前記オークションに関する情報を提供し、前記オークションへの参加を前記インターネットから行うことを可能にするステップを含む請求項３７に記載の方法。
【請求項３９】
媒体によって利用者へ伝達され、ユニットを販売するためのインターネットを基本としたリバースオークションを運営する方法であって、
販売するいくつかのユニットを提供し、販売に供される数を最初に示す割り当てデータベースに暫定利用可能数量を格納するステップと、
前記リバースオークションに参加するために利用者から注文を出すことができるウェブサイト購入機能を提供するステップと、
前記電話番号に１つまたは複数の注文が受信された時刻を着呼データベースの着呼レコードに記録するステップと、
ユニットを販売するために、各発呼者を待ち行列に配置し、その発呼者をコールオペレータまたはシステムに割り当てるステップと、
人またはシステムが前記示されたユニットの価格を一定の期間にわたって下げ、プロデューサまたはシステムが前記暫定利用可能数量を減らすリバースオークションを運営するステップとを含み、
前記リバースオークションは、前記暫定利用可能数量がゼロなどの所定の数まで減った時刻に終了するとともに、前記終了時の価格はオークションデータベースに格納され、
前記暫定利用可能数量は、前記オークションのタイミングに対する前記着呼レコード内の前記着呼の受け付け時刻などの、着呼／発呼者と関連づけられた１つまたは複数の暫定指標に少なくとも部分的に基づいて減らされ、好ましくは、前記指標はユニットの販売が完了／確定する前に発生する方法。
【図１】
【図２】
【図３ａ】
【図３ｂ】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３ａ】
【図３ｂ】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公表番号】特表２００９−５４５７９５（Ｐ２００９−５４５７９５Ａ）
【公表日】平成２１年１２月２４日（２００９．１２．２４）
【国際特許分類】
【出願番号】特願２００９−５２２３３９（Ｐ２００９−５２２３３９）
【出願日】平成１９年８月３日（２００７．８．３）
【国際出願番号】ＰＣＴ／ＧＢ２００７／００２９５６
【国際公開番号】ＷＯ２００８／０１５４５２
【国際公開日】平成２０年２月７日（２００８．２．７）
【出願人】（５０９０３２４２７）ジェムス ティービー リミテッド (1)
【Ｆターム（参考）】
【公表日】平成２１年１２月２４日（２００９．１２．２４）
【国際特許分類】
【出願日】平成１９年８月３日（２００７．８．３）
【国際出願番号】ＰＣＴ／ＧＢ２００７／００２９５６
【国際公開番号】ＷＯ２００８／０１５４５２
【国際公開日】平成２０年２月７日（２００８．２．７）
【出願人】（５０９０３２４２７）ジェムス ティービー リミテッド (1)
【Ｆターム（参考）】
[ Back to top ]