特許 5763867 予告装置、プログラム、記録媒体、及び方法

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

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

(11)【特許番号】5763867

(24)【登録日】2015年6月19日

(45)【発行日】2015年8月12日

(54)【発明の名称】予告装置、プログラム、記録媒体、及び方法

(51)【国際特許分類】

   G06Q 30/08 20120101AFI20150723BHJP

【ＦＩ】

   G06Q30/08

【請求項の数】11

【全頁数】27

(21)【出願番号】特願2015-509653(P2015-509653)

(86)(22)【出願日】2014年5月20日

(86)【国際出願番号】JP2014063357

【審査請求日】2015年2月18日

【早期審査対象出願】

(73)【特許権者】

【識別番号】399037405

【氏名又は名称】楽天株式会社

(74)【代理人】

【識別番号】100110135

【弁理士】

【氏名又は名称】石井 裕一郎

(74)【代理人】

【識別番号】100132883

【弁理士】

【氏名又は名称】森川 泰司

(74)【代理人】

【識別番号】100148633

【弁理士】

【氏名又は名称】桜田 圭

(74)【代理人】

【識別番号】100163452

【弁理士】

【氏名又は名称】南郷 邦臣

(72)【発明者】

【氏名】孔 孝錫

(72)【発明者】

【氏名】シンデ ユワラジュ

【審査官】 阿部 潤

(56)【参考文献】

【文献】 国際公開第２０１２／０２９７０２（ＷＯ，Ａ１）

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

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

Ｇ０６Ｑ １０／００ − ５０／３４

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

【請求項1】

複数の取引の各取引について、前記各取引の期限に、設定された間隔だけ先行する予告日時を取得する取得部、
前記各取引について取得された前記予告日時が到来した後、前記各取引の前記期限の予告を、前記各取引をウォッチするユーザに通知する通知部、
前記各取引に係る前記予告を通知されたユーザが、前記各取引の前記期限までに、前記各取引に対して行ったアクションに基づいて、前記複数の取引について前記通知部により通知された前記予告に対する反応度を算出する算出部、
前記算出された反応度が向上するように、前記間隔を更新する更新部、を備え、
前記間隔を一時的に変化させることにより、前記反応度が向上すれば、前記更新部は、前記間隔を前記一時的に変化させた値に更新する、
ことを特徴とする予告装置。

【請求項2】

前記アクションは、前記各取引の期限までに前記各取引の申込ページへアクセスすることであり、前記反応度は、前記予告が通知されたユーザのアクセス率に正の相関を有するように、算出される、
ことを特徴とする請求項１に記載の予告装置。

【請求項3】

前記アクションは、前記各取引の期限までに前記各取引の申込ページへアクセスすることであり、前記反応度は、前記予告が通知された時点から前記申込ページへアクセスした時点までの応答期間から、算出される、
ことを特徴とする請求項１に記載の予告装置。

【請求項4】

前記アクションは、前記各取引の期限後に前記予告を通知されたユーザが当該予告を開封したことであり、前記反応度は、前記期限後の開封率に負の相関をするように、算出される、
ことを特徴とする請求項１に記載の予告装置。

【請求項5】

前記複数の取引の期限が属する時間帯毎に、前記間隔が設定される、
ことを特徴とする請求項１に記載の予告装置。

【請求項6】

前記複数の取引が属するジャンル毎に、前記間隔が設定される、
ことを特徴とする請求項１に記載の予告装置。

【請求項7】

前記複数の取引のうち、前記期限の自動延長がされる取引と、されない取引と、のそれぞれに対して、前記間隔が設定される、
ことを特徴とする請求項１に記載の予告装置。

【請求項8】

複数の取引を管理するサーバと、前記サーバと通信する端末装置と、を備えるシステムであって、
前記端末装置は、
前記複数の取引の各取引について、前記各取引の期限に、設定された間隔だけ先行する予告日時を取得する取得部、
前記各取引について取得された前記予告日時が到来した後、前記各取引の前記期限の予告を、前記各取引をウォッチするユーザに通知する通知部、を備え、
前記サーバは、
前記各取引に係る前記予告を通知されたユーザが、前記各取引の前記期限までに、前記各取引に対して行ったアクションに基づいて、前記複数の取引について前記通知部により通知された前記予告に対する反応度を算出する算出部、
前記算出された反応度が向上するように、前記間隔を更新する更新部、を備え、
前記間隔を一時的に変化させることにより、前記反応度が向上すれば、前記更新部は、前記間隔を前記一時的に変化させた値に更新し、
前記端末装置は、前記サーバから、前記更新された間隔を入手する、
ことを特徴とするシステム。

【請求項9】

コンピュータを、
複数の取引の各取引について、前記各取引の期限に、設定された間隔だけ先行する予告日時を取得する取得部、
前記各取引について取得された前記予告日時が到来した後、前記各取引の前記期限の予告を、前記各取引をウォッチするユーザに通知する通知部、
前記各取引に係る前記予告を通知されたユーザが、前記各取引の前記期限までに、前記各取引に対して行ったアクションに基づいて、前記複数の取引について前記通知部により通知された前記予告に対する反応度を算出する算出部、
前記算出された反応度が向上するように、前記間隔を更新する更新部、として機能させ、
前記間隔を一時的に変化させることにより、前記反応度が向上すれば、前記更新部は、前記間隔を前記一時的に変化させた値に更新する、
ことを特徴とするプログラム。

【請求項10】

コンピュータを、
複数の取引の各取引について、前記各取引の期限に、設定された間隔だけ先行する予告日時を取得する取得部、
前記各取引について取得された前記予告日時が到来した後、前記各取引の前記期限の予告を、前記各取引をウォッチするユーザに通知する通知部、
前記各取引に係る前記予告を通知されたユーザが、前記各取引の前記期限までに、前記各取引に対して行ったアクションに基づいて、前記複数の取引について前記通知部により通知された前記予告に対する反応度を算出する算出部、
前記算出された反応度が向上するように、前記間隔を更新する更新部、として機能させ、
前記間隔を一時的に変化させることにより、前記反応度が向上すれば、前記更新部は、前記間隔を前記一時的に変化させた値に更新する、
ことを特徴とするプログラムを記録したコンピュータ読み取り可能な記録媒体。

【請求項11】

取得部、通知部、算出部、更新部を備えた予告装置の動作方法であって、
前記取得部が、複数の取引の各取引について、前記各取引の期限に、設定された間隔だけ先行する予告日時を取得する取得ステップ、
前記通知部が、前記各取引について取得された前記予告日時が到来した後、前記各取引の前記期限の予告を、前記各取引をウォッチするユーザに通知する通知ステップ、
前記算出部が、前記各取引に係る前記予告を通知されたユーザが、前記各取引の前記期限までに、前記各取引に対して行ったアクションに基づいて、前記複数の取引について前記通知ステップにより通知された前記予告に対する反応度を算出する算出ステップ、
前記更新部が、前記算出された反応度が向上するように、前記間隔を更新する更新ステップ、を実行し、
前記更新ステップでは、前記間隔を一時的に変化させることにより、前記反応度が向上すれば、前記間隔を前記一時的に変化させた値に更新する、
ことを特徴とする方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、予告装置、プログラム、記録媒体、及び方法に関する。

【背景技術】

【0002】

従来から、オークションを含む各種の取引の申込期限よりも所定時間前に当該期限の到来をユーザに予告した後、当該ユーザが申込ページにアクセスしたが申込みをしなかった場合に、次の期限の予告を、当該次の期限よりも所定時間以上前に行う装置が知られている（例えば、特許文献１）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特許第５１４５５７８号公報

【発明の概要】

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

【0004】

しかし、特許文献１の装置は、例えば、販売ページなどのような、取引の申込みに用いられるウェブページにユーザがアクセスしなければ、予告時刻を調整しない。このため、特許文献１の装置では、予告に対するユーザの反応度合いを向上できるような適切な時期に予告が行われない場合があるという問題があった。

【0005】

本発明は、このような問題点に鑑みてなされたものであり、その目的とするところは、従来よりも適切な時期に期限の到来を予告できる予告装置、プログラム、記録媒体、及び方法を提供することにある。

【課題を解決するための手段】

【0006】

上記目的を達成するため、本発明の第１の観点に係る予告装置は、
複数の取引の各取引について、前記各取引の期限に、設定された間隔だけ先行する予告日時を取得する取得部、
前記各取引について取得された前記予告日時が到来した後、前記各取引の前記期限の予告を、前記各取引をウォッチするユーザに通知する通知部、
前記各取引に係る前記予告を通知されたユーザが、前記各取引の前記期限までに、前記各取引に対して行ったアクションに基づいて、前記複数の取引について前記通知部により通知された前記予告に対する反応度を算出する算出部、
前記算出された反応度が向上するように、前記間隔を更新する更新部、を備える、
ことを特徴とする。

【0007】

また、第１の観点に係る予告装置において、
前記間隔を一時的に変化させることにより、前記反応度が向上すれば、前記更新部は、前記間隔を前記一時的に変化させた値に更新する、
としても良い。

【0008】

また、第１の観点に係る予告装置において、
前記アクションは、前記各取引の期限までに前記各取引の申込ページへアクセスすることであり、前記反応度は、前記予告が通知されたユーザのアクセス率に正の相関を有するように、算出される、
としても良い。

【0009】

また、第１の観点に係る予告装置において、
前記アクションは、前記各取引の期限までに前記各取引の申込ページへアクセスすることであり、前記反応度は、前記予告が通知された時点から前記申込ページへアクセスした時点までの応答期間から、算出される、
としても良い。

【0010】

また、第１の観点に係る予告装置において、
前記アクションは、前記各取引の期限後に前記予告を通知されたユーザが当該予告を開封したことであり、前記反応度は、前記期限後の開封率に負の相関をするように、算出される、
としても良い。

【0011】

また、第１の観点に係る予告装置において、
前記複数の取引の期限が属する時間帯毎に、前記間隔が設定される、
としても良い。

【0012】

また、第１の観点に係る予告装置において、
前記複数の取引が属するジャンル毎に、前記間隔が設定される、
としても良い。

【0013】

また、第１の観点に係る予告装置において、
前記複数の取引のうち、前記期限の自動延長がされる取引と、されない取引と、のそれぞれに対して、前記間隔が設定される、
としても良い。

【0014】

上記目的を達成するため、本発明の第２の観点に係るシステムは、
複数の取引を管理するサーバと、前記サーバと通信する端末装置と、を備えるシステムであって、
前記端末装置は、
前記複数の取引の各取引について、前記各取引の期限に、設定された間隔だけ先行する予告日時を取得する取得部、
前記各取引について取得された前記予告日時が到来した後、前記各取引の前記期限の予告を、前記各取引をウォッチするユーザに通知する通知部、を備え、
前記サーバは、
前記各取引に係る前記予告を通知されたユーザが、前記各取引の前記期限までに、前記各取引に対して行ったアクションに基づいて、前記複数の取引について前記通知部により通知された前記予告に対する反応度を算出する算出部、
前記算出された反応度が向上するように、前記間隔を更新する更新部、を備え、
前記端末装置は、前記サーバから、前記更新された間隔を入手する、
ことを特徴とする。

【0015】

上記目的を達成するため、本発明の第３の観点に係るプログラムは、
コンピュータを、
複数の取引の各取引について、前記各取引の期限に、設定された間隔だけ先行する予告日時を取得する取得部、
前記各取引について取得された前記予告日時が到来した後、前記各取引の前記期限の予告を、前記各取引をウォッチするユーザに通知する通知部、
前記各取引に係る前記予告を通知されたユーザが、前記各取引の前記期限までに、前記各取引に対して行ったアクションに基づいて、前記複数の取引について前記通知部により通知された前記予告に対する反応度を算出する算出部、
前記算出された反応度が向上するように、前記間隔を更新する更新部、として機能させる、
ことを特徴とする。

【0016】

上記目的を達成するため、本発明の第４の観点に係るコンピュータ読み取り可能な記録媒体は、
コンピュータを、
複数の取引の各取引について、前記各取引の期限に、設定された間隔だけ先行する予告日時を取得する取得部、
前記各取引について取得された前記予告日時が到来した後、前記各取引の前記期限の予告を、前記各取引をウォッチするユーザに通知する通知部、
前記各取引に係る前記予告を通知されたユーザが、前記各取引の前記期限までに、前記各取引に対して行ったアクションに基づいて、前記複数の取引について前記通知部により通知された前記予告に対する反応度を算出する算出部、
前記算出された反応度が向上するように、前記間隔を更新する更新部、として機能させる、
ことを特徴とするプログラムを記録している。

【0017】

上記目的を達成するため、本発明の第５の観点に係る方法は、
複数の取引の各取引について、前記各取引の期限に、設定された間隔だけ先行する予告日時を取得する取得ステップ、
前記各取引について取得された前記予告日時が到来した後、前記各取引の前記期限の予告を、前記各取引をウォッチするユーザに通知する通知ステップ、
前記各取引に係る前記予告を通知されたユーザが、前記各取引の前記期限までに、前記各取引に対して行ったアクションに基づいて、前記複数の取引について前記通知ステップにより通知された前記予告に対する反応度を算出する算出ステップ、
前記算出された反応度が向上するように、前記間隔を更新する更新ステップ、を有する、
ことを特徴とする。

【発明の効果】

【0018】

本発明に係る予告装置、プログラム、記録媒体、及び方法によれば、従来よりも適切な時期に期限の到来を予告できる。

【図面の簡単な説明】

【0019】

【図1】実施例１に係る予告システムの一構成例を表すシステム構成図である。

【図2】端末装置が表示する検索ページの一例を表す図である。

【図3】端末装置が表示する予告メッセージの一例を表す図である。

【図4】端末装置が表示する入札申込ページの一例を表す図である。

【図5】予告装置の一例を表すハードウェア構成図である。

【図6】予告装置が有する機能の一例を表す機能ブロック図である。

【図7】予告装置が記憶する商品テーブルの一例を表す図である。

【図8】予告装置が記憶する入札テーブルの一例を表す図である。

【図9】実施例１に係る予告装置が記憶するパラメタテーブルの一例を表す図である。

【図10】予告装置が記憶するログテーブルの一例を表す図である。

【図11】予告装置が実行する登録処理の一例を表すフローチャートである。

【図12】予告装置が実行する予告処理の一例を表すフローチャートである。

【図13】実施例２に係る予告装置が記憶するパラメタテーブルの一例を表す図である。

【図14】実施例３に係る予告装置が記憶するパラメタテーブルの一例を表す図である。

【図15】実施例４に係る予告装置が記憶するパラメタテーブルの一例を表す図である。

【図16】実施例５に係る予告システムの一構成例を表すシステム構成図である。

【図17】実施例５に係る端末装置が有する機能の一例を表す機能ブロック図である。

【発明を実施するための形態】

【0020】

以下、本発明の実施例について添付図面を参照しつつ説明する。

【実施例1】

【0021】

本発明の実施例１に係る予告システム１は、取引の申し込み期限の前に、当該期限の到来を予告する。本実施例では、取引の申し込み期限一例としてインターネット・オークションの入札申込期限（以下単に、入札期限という）を挙げて説明する。

【0022】

予告システム１は、図１に示すような、端末装置１１０及び１２０と、端末装置１１０及び１２０と無線通信可能な基地局２００と、基地局２００とコンピュータ通信網１０（以下単に、通信網１０という）を介して通信可能に接続された予告装置３００と、で構成される。

【0023】

通信網１０は、例えば、インターネットで構成される。通信網１０は、ＬＡＮ（Local Area Network）又は公衆回線網であっても良い。

【0024】

端末装置１１０及び１２０は、例えば、携帯電話で構成される。端末装置１１０及び１２０は、ノート型のパーソナル・コンピュータであっても、タブレット型のコンピュータであっても良い。

【0025】

端末装置１１０は、例えば、タッチパッドなどの入力部１１１と、ＬＣＤ（Liquid Crystal Display）などの表示部１１９と、を備える。端末装置１２０は、端末装置１１０の有する入力部１１１及び表示部１１９と同様の構成を有する入力部１２１及び表示部１２９で構成される。端末装置１１０及び１２０は、互いに同様の構成を有し、同様の動作を行うため、以下主に、端末装置１１０について説明を行う。

【0026】

端末装置１１０は、インターネット・オークションで入札可能な商品を検索するために用いられる、図２に示すような検索ページを表示する。端末装置１１０は、入力部１１１をユーザに操作されると、当該操作に応じて商品の検索条件を入力し、入力された検索条件を表すデータ（以下、検索条件データという）と、検索リクエストと、を予告装置３００へ送信する。

【0027】

その後、端末装置１１０は、予告装置３００から検索条件を満足する商品の名称、現在価格、及び入札期限を表す情報を取得し、取得した情報を検索ページに表示する。その後、表示部１１９を確認したユーザは、取引をウォッチする商品（以下、ウォッチ商品という）を決定する。

【0028】

ここで、取引をウォッチするとは、取引状況の変化についての通知を受けることをいう。この通知は、予告装置３００が記憶するウォッチリストと称されるリストに識別情報（以下、ユーザＩＤという）が登録されているユーザに対して行われる。このため、取引をウォッチするユーザのことを、ウォッチリストに登録されたユーザともいう。

【0029】

取引状況の変化についての通知は、取引の申込期限の到来についての予告を含むが、これに限定される訳では無く、例えば、入札取引であれば、最高額入札額が変化したことや、最高額で入札しているユーザ（以下、最高額入札者という）が別のユーザに代わったことの通知を含む。

【0030】

その後、ユーザは、ウォッチする商品を選択する操作等を入力部１１１に行い、端末装置１１０は、ウォッチ対象とされる商品を識別する情報（以下、ウォッチ商品ＩＤという）と、ユーザＩＤと、を、当該操作に応じて入力部１１１から入力する。次に、端末装置１１０は、ウォッチ商品ＩＤと、ユーザＩＤと、当該ユーザＩＤをウォッチリストに登録することを求めるウォッチリクエストと、を予告装置３００へ送信する。

【0031】

その後、端末装置１１０は、ウォッチ商品の入札期限が近づくと、図３に示すような、入札期限の到来を予告するメッセージ（以下、予告メッセージという）を予告装置３００から受信し、受信したメッセージを表示部１１９に表示する。

【0032】

表示部１１９に表示された予告メッセージには、申込期限、申込期限が到来する商品名、及び商品の現在価格が記載されている。表示部１１９を確認したユーザが、表示された情報に基づいて商品の入札を決意すると、商品の入札申込みに用いられるページ（以下、入札申込ページという）を表示させる操作等を入力部１１１に行う。端末装置１１０は、当該操作に応じて、入札する商品（以下、入札商品という）を識別する情報（以下、入札商品ＩＤという）を入力部１１１から入力する。次に、端末装置１１０は、入札申込ページの送信を求める送信リクエストと、入力された入札商品ＩＤ及びユーザＩＤと、を予告装置３００へ送信する。

【0033】

その後、端末装置１１０は、予告装置３００から、図４に示すような入札申込ページを取得し、表示部１１９に表示する。その後、端末装置１１０は、ユーザの操作に応じて入力部１１１から入力された入札額を表す情報を予告装置３００へ送信することで、入札の申込みを行う。

【0034】

尚、本実施例では、ユーザは、検索結果を確認した後、ウォッチする商品を選択する操作を入力部１１１にするとして説明したが、ウォッチする商品を選択せずに入札する商品を選択する操作をしてもよい。この場合であっても、後述するように、ユーザは、ウォッチリストにユーザＩＤが登録されるので、入札期限の到来について予告を受ける。

【0035】

図１に戻り予告システムの説明を再開する。基地局２００は、例えば、携帯電話の基地局や無線ＬＡＮの基地局である。基地局２００は、端末装置１１０及び１２０と予告装置３００との通信を中継する。

【0036】

予告装置３００は、図５に示すようなサーバ機で構成される。予告装置３００は、ＣＰＵ（Central Processing Unit）３０１、ＲＯＭ（Read Only Memory）３０２、ＲＡＭ（Random Access Memory）３０３、ハードディスク３０４、メディアコントローラ３０５、ＬＡＮ（Local Area Network）カード３０６、ビデオカード３０７、ＬＣＤ（Liquid Crystal Display）３０８、キーボード３０９、スピーカ３１０、及びタッチパッド３１１で構成される。

【0037】

ＣＰＵ３０１は、ＲＯＭ３０２又はハードディスク３０４に保存されたプログラムに従ってプログラムを実行することで、予告装置３００の全体制御を行う。ＲＡＭ３０３は、ＣＰＵ３０１によるプログラムの実行時において、処理対象とするデータを一時的に記憶するワークメモリである。

【0038】

ハードディスク３０４は、各種のデータを保存したテーブルを記憶する情報記憶部である。尚、予告装置３００は、ハードディスク３０４の代わりに、フラッシュメモリを備えても良い。

【0039】

メディアコントローラ３０５は、フラッシュメモリ、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、及びブルーレイディスク（Blu-ray Disc）（登録商標）を含む記録媒体から各種のデータ及びプログラムを読み出す。

【0040】

ＬＡＮカード３０６は、通信網１０及び基地局２００を介して接続する端末装置１１０及び１２０との間でデータを送受信する。キーボード３０９及びタッチパッド３１１は、ユーザの操作に応じた信号を入力する。

【0041】

ビデオカード３０７は、ＣＰＵ３０１から出力されたデジタル信号に基づいて画像を描画（つまり、レンダリング）すると共に、描画された画像を表す画像信号を出力する。ＬＣＤ３０８は、ビデオカード３０７から出力された画像信号に従って画像を表示する。なお、予告装置３００は、ＬＣＤ３０８の代わりに、ＰＤＰ（Plasma Display Panel）又はＥＬ（Electroluminescence）ディスプレイを備えても良い。スピーカ３１０は、ＣＰＵ３０１から出力された信号に基づいて音声を出力する。

【0042】

次に、予告装置３００の有する機能について説明する。
図５に示したハードディスク３０４は、ＣＰＵ３０１と協働して、図６に示す情報記憶部３９０として機能する。

【0043】

情報記憶部３９０は、図７に示すような商品テーブルを記憶している。商品テーブルには、オークションに出品された商品を識別する情報（以下、商品ＩＤという）と、商品名を表す情報と、商品のジャンルを識別する情報と、ジャンル名を表す情報と、が対応付けられたレコードが複数保存されている。

【0044】

商品のジャンルとは、商品の種別をいい、オークションに出品される商品は、いずれかの種別（つまり、ジャンル）に分類される。ジャンルには、一例として、洋服などの商品が分類される「ファッション」や映画やテレビ番組等の映像や音楽を記録したＤＶＤが分類される「ＤＶＤ（Digital Versatile Disc）」を挙げることができる。

【0045】

また、情報記憶部３９０は、図８に示すような入札テーブルを記憶している。入札テーブルには、図７の商品テーブルに保存されている商品ＩＤと、商品ＩＤで識別される商品の入札期限を表す情報、期限の到来を予告する日時（以下、予告日時という）を表す情報、予告が行われたか否かを表す予告フラグ、当該商品の現在価格を表す情報、最高額入札者のユーザＩＤ、当該商品のウォッチリスト、及び入札の自動延長の有無を表す情報、が対応付けられたレコードが複数保存される。入札の自動延長については、実施例２で説明する。

【0046】

さらに、情報記憶部３９０は、予告日時を定めるパラメタ（以下単に、設定パラメタという）が保存される、図９に示すようなパラメタテーブルを記憶している。パラメタテーブルには、設定パラメタの更新に用いられる情報として、予告数を表す情報、予告後アクセス数を表す情報、予告後アクセス率を表す情報、応答時間の合計を表す情報、期限後開封数を表す情報、及び期限後開封率を表す情報、が対応付けられたレコードが１つ保存されている。

【0047】

予告数とは、予告装置３００が入札期限の到来を予告した回数をいう。予告後アクセス数は、入札期限の到来を予告された商品の入札申込ページに対するアクセス総数の内で、予告を受けたユーザによる予告後から期限までに行われたアクセスをカウントしたものをいう。予告後アクセス率は、予告数に対する予告後アクセス数の割合をいう。

【0048】

本実施例では、予告装置３００は、入札期限の到来を予告するために、予告メッセージを含んだ電子メール（以下、予告メールという）を送付する。このため、応答時間とは、予告メールの送信時点から、予告メールを確認したユーザが入札期限の到来を予告された商品の入札申込ページに予告後から期限までの間にアクセスした場合におけるアクセス時点までの時間をいう。

【0049】

応答時間の合計とは、予告メールを送信されたユーザに対する応答時間の合計をいう。期限後開封数とは、予告メールが予告する入札期限よりも後に、予告メールを開封したユーザの数をいい、期限後開封率は、予告数に対する期限後開封数の割合をいう。

【0050】

さらに、情報記憶部３９０は、アクセス数等のカウントに用いられるログが保存される、図１０に示すようなログテーブルを記憶している。ログテーブルには、ログの保存日時を表す保存日時情報と、ログの内容を表す内容情報と、ログの内容に関連したユーザＩＤ及び商品ＩＤと、が対応付けられたレコードが複数保存される。

【0051】

引き続き予告装置３００が有する機能について説明する。
図５のＣＰＵ３０１は、ＬＡＮカード３０６が検索リクエストを端末装置１１０から受信すると、商品を検索する検索処理の実行を開始する。ＣＰＵ３０１は、検索処理を実行することで、図６に示す情報取得部３２０及び検索部３２５として機能する。

【0052】

検索処理が開始されると、情報取得部３２０は、端末装置１１０から受信された検索条件データを、図５のＬＡＮカード３０６から取得する。次に、検索部３２５は、検索条件データから、検索キーワードと、検索対象とする商品が属するジャンルのジャンルＩＤと、を抽出する。その後、検索部３２５は、図７の商品テーブルから、抽出したジャンルＩＤと、検索キーワードに一部又は全部が一致する商品名を表す情報と、に対応付けられた商品ＩＤを複数検索する。次に、検索部３２５は、図８の入札テーブルから、検索した複数の商品ＩＤにそれぞれ対応付けられた期限を表す情報及び現在価格を表す情報を検索する。

【0053】

その後、検索部３２５は、検索した商品ＩＤ、商品名を表す情報、期限を表す情報、及び現在価格を表す情報を、端末装置１１０を宛先としてＬＡＮカード３０６に出力する。ＬＡＮカード３０６は、これらの情報を端末装置１１０に送信し、端末装置１１０はこれらの情報を、図２の検索ページに表示する。

【0054】

端末装置１１０のユーザは、検索ページを確認し、検索された複数の商品からウォッチする商品を決定する。端末装置１１０は、ユーザの操作に応じて、ユーザＩＤと、ウォッチ商品ＩＤと、ウォッチ商品のウォッチリストにユーザを登録するよう求めるウォッチリクエストと、を予告装置３００へ送信する。

【0055】

その後、ＬＡＮカード３０６が、ウォッチリクエストを端末装置１１０から受信すると、ＣＰＵ３０１は、図１１に示すような登録処理の実行を開始する。ＣＰＵ３０１は、登録処理を実行することで、図６に示す情報取得部３２０の他に、登録部３３０として機能する。

【0056】

登録処理の実行が開始されると、情報取得部３２０は、ＬＡＮカード３０６からリクエストを取得し、取得したリクエストがウォッチリクエストであると判別した後に（ステップＳ０１；Ｙｅｓ）、ＬＡＮカード３０６からユーザＩＤ及びウォッチ商品ＩＤを取得する（ステップＳ０２）。次に、登録部３３０は、図８の入札テーブルに保存されている、ウォッチ商品ＩＤと同じ商品ＩＤに対応付けられたウォッチリスト（つまり、ウォッチ商品のウォッチリスト）に、取得したユーザＩＤを追加登録する（ステップＳ０３）。その後、登録部３３０は、登録処理の実行を終了する。

【0057】

端末装置１１０のユーザが、図２の検索ページを確認し、ウォッチする商品ではなく、入札する商品を決定した場合には、端末装置１１０は、ユーザの操作に応じて、入札商品ＩＤと、ユーザＩＤと、入札申込ページの送信リクエストと、を予告装置３００へ送信する。その後、ＬＡＮカード３０６が送信リクエストを受信すると、ＣＰＵ３０１は、既に一部説明した、図１１の登録処理を開始する。

【0058】

登録処理の実行が開始されると、情報取得部３２０は、ＬＡＮカード３０６からリクエストを取得し、取得したリクエストがウォッチリクエストでないと判別した後に（ステップＳ０１；Ｎｏ）、取得したリクエストが送信リクエストであると判別する（ステップＳ０４；Ｙｅｓ）。尚、情報取得部３２０は、取得したリクエストが送信リクエストでないと判別すると（ステップＳ０４；Ｎｏ）、登録処理の実行を終了する。

【0059】

その後、情報取得部３２０がＬＡＮカード３０６から入札商品ＩＤとユーザＩＤとを取得した後に（ステップＳ０５）、登録部３３０は、取得された入札商品ＩＤで識別される商品の入札申込ページを、端末装置１１０を宛先としてＬＡＮカード３０６へ出力する（ステップＳ０６）。

【0060】

その後、登録部３３０は、ユーザＩＤと、入札商品ＩＤと、当該ユーザＩＤで識別されるユーザが、入札商品ＩＤで識別される商品の入札申込ページにアクセスしたという内容を表す内容情報と、ログの保存日時情報と、を対応付けて、図１０のログテーブルに保存する。尚、登録部３３０は、ログの保存日時情報として、入札申込ページへのアクセス日時を表す情報を保存してもいい。

【0061】

その後、ＬＡＮカード３０６は、入札申込ページを端末装置１１０に送信し、端末装置１１０は入札申込ページを表示する。端末装置１１０のユーザは、入札申込ページを確認し、入札額を決定する。端末装置１１０は、ユーザの操作に応じて、入札額を表す情報を予告装置３００へ送信する。

【0062】

その後、情報取得部３２０が、ＬＡＮカード３０６から入札額を表す情報を取得する（ステップＳ０７）。次に、登録部３３０は、図８の入札テーブルに保存されている、入札商品ＩＤと同じ商品ＩＤに対応付けられた最高額入札者のユーザＩＤと現在価格を表す情報とを、取得したユーザＩＤと入札額を表す情報とで更新する（ステップＳ０８）。

【0063】

その後、登録部３３０は、ユーザＩＤと、入札商品ＩＤと、当該ユーザＩＤで識別されるユーザが、入札商品ＩＤで識別される商品の入札をしたという内容を表す内容情報と、ログの保存日時情報と、を対応付けて、図１０のログテーブルに保存する。尚、登録部３３０は、ログの保存日時情報として、入札日時を表す情報を保存してもいい。

【0064】

次に、登録部３３０は、入札商品ＩＤと同じ商品ＩＤに対応付けられたウォッチリスト（つまり、入札商品のウォッチリスト）に、取得したユーザＩＤが含まれていない場合に、当該ユーザＩＤを当該ウォッチリストに追加登録する（ステップＳ０９）。その後、登録部３３０は、登録処理の実行を終了する。

【0065】

図５のＣＰＵ３０１は、電源を投入されると、図１２に示す予告処理の実行を開始する。予告処理は、ウォッチリストに登録されたユーザに入札期限の到来を予告する処理である。この処理の実行により、ＣＰＵ３０１は、図６に示す算出部３４０、更新部３５０、期限取得部３６０、及び通知部３７０として機能する。

【0066】

予告処理の実行が開始されると、図８の入札テーブルに商品ＩＤが保存された商品について、予告日時を設定する予告日時設定処理が実行される（ステップＳ１１）。

【0067】

予告日時設定処理が開始されると、算出部３４０は、図９のパラメタテーブルに保存された設定パラメタを取得する。次に、期限取得部３６０は、図８の入札テーブルに保存された複数のレコードのそれぞれから入札期限を表す情報を取得する。その後、算出部３４０は、取得した複数の情報でそれぞれ表される入札期限よりも設定パラメタで表される時間だけ早い日時を予告日時として算出する。本実施例では、設定パラメタは、当初３０分を表す値に設定されているとして説明するが、これに限定される訳ではない。

【0068】

その後、更新部３５０は、算出された複数の予告日時のそれぞれについて、算出に用いた入札期限を表す情報と入札テーブルでそれぞれ対応付けられた予告日時を表す情報を、算出された予告日時を表す情報で更新する。

【0069】

次に、更新部３５０は、予告日時を仮変更する日時（以下、仮変更日時という）を、所定時間後の日時に設定する。予告タイミングを適切な時期に調整するためである。また、更新部３５０は、予告タイミングの変更により、予告メールに対してユーザがどの程度反応したかを表す反応度合い（以下、反応度という）が改善したか否かを検証する日時（以下、検証日時という）を、仮変更日時よりも所定時間後の日時に設定する。その後、更新部３５０は、予告日時設定処理の実行を終了する。

【0070】

ステップＳ１１の次に、通知部３７０は、現在日時を、例えば、ＯＳ（Operating System）から取得した後に、入札期限の到来を予告する必要がある商品（以下、予告必要商品という）が存在するか否かを判別する（ステップＳ１２）。

【0071】

ここで、期限を予告する商品は、予告日時が到来しているが、未だ期限の予告が行われていない商品である。このため、通知部３７０は、図８の入札テーブルから、予告が行われていないことを表す予告フラグと、現在日時よりも前の予告日時を表す情報と、が保存されたレコードを１つ検索する。次に、通知部３７０は、検索したレコードに保存された商品ＩＤで識別される商品を予告必要商品と判別する。

【0072】

通知部３７０は、予告必要商品が存在すると判別すると（ステップＳ１２；Ｙｅｓ）、予告メッセージを出力する予告メッセージ出力処理を実行する（ステップＳ１３）。

【0073】

通知部３７０は、予告メッセージ出力処理を開始すると、入札テーブルから、予告必要商品の商品ＩＤに対応づけられた入札期限を表す情報、現在価格を表す情報、及び最高額入札者を表す情報等を取得し、取得した情報を含んだ予告メッセージを作成する。

【0074】

その後、通知部３７０は、入札テーブルから、予告必要商品の商品ＩＤに対応づけられたウォッチリストを取得する。本実施例では、ユーザＩＤは、ユーザのメールアドレスであるとして説明を行う。このため、通知部３７０は、取得したウォッチリストに登録されている複数のユーザＩＤを宛先とし、予告メッセージを含んだ予告メールを作成した後に、図５のＬＡＮカード３０６に予告メールを出力する。

【0075】

その後、ＬＡＮカード３０６が予告メールを送信し終えると、通知部３７０は、ウォッチリストに登録された複数のユーザに対して、予告必要商品の入札期限が記載された予告メールを送信したという内容の内容情報を作成する。次に、通知部３７０は、当該複数のユーザのユーザＩＤと、予告必要商品の商品ＩＤと、作成した内容情報と、ログの保存日時情報と、を対応付けて、図１０のログテーブルに保存する。その後、通知部３７０は、予告メッセージ出力処理の実行を終了する。尚、登録部３３０は、ログの保存日時情報として、予告メールの送信日時を表す情報を保存しても良い。

【0076】

尚、予告メールには、端末装置１１０で開封されると、開封されたことを通知する電子メール（以下、開封確認メールという）が送信元へ返信される設定がされている。この開封確認メールには、期限を予告した商品の商品ＩＤ及び予告を受けたユーザのユーザＩＤが記載されている。このため、ＬＡＮカード３０６が開封確認メールを受信すると、情報取得部３２０がＬＡＮカード３０６から開封確認メールを取得し、登録部３３０が開封確認メールに記載された商品ＩＤ及びユーザＩＤと、予告メールが開封されたという内容の内容情報と、ログの保存日時情報と、を対応付けてログテーブルに保存する。尚、登録部３３０は、ログの保存日時情報として、予告メールの開封日時や開封確認メールの受信日時を表す情報を保存しても良い。

【0077】

予告必要商品が存在しないと判別された場合（ステップＳ１２；Ｎｏ）、又は、ステップＳ１３が実行された後に、算出部３４０は、現在日時を取得する。次に、算出部３４０は、現在日時が設定パラメタの仮変更日時よりも後の日時であるか否かに基づいて、仮変更日時が到来したか否かを判別する（ステップＳ１４）。

【0078】

このとき、仮変更日時が到来したと算出部３４０が判別すると（ステップＳ１４；Ｙｅｓ）、更新部３５０は、設定パラメタの値を仮変更した値を決定する仮変更パラメタ値決定処理を実行する（ステップＳ１５）。このとき、更新部３５０は、現在の設定パラメタの値を所定値だけ増加させるか、所定値だけ減少させるか、をランダムに決定する。

【0079】

次に、設定パラメタの値を仮変更した値を用いた予告日時設定処理が実行される（ステップＳ１６）。ステップＳ１６で実行される予告日時設定処理は、ステップＳ１１で実行された予告日時設定処理と同様の処理である。ステップＳ１６で予告日時設定処理を開始すると、期限取得部３６０は、図８の入札テーブルに保存された複数のレコードのそれぞれから入札期限を表す情報を取得した後、取得した複数の情報でそれぞれ表される入札期限よりも仮変更した設定パラメタ値で表される時間だけ早い日時を予告日時として算出する。

【0080】

次に、更新部３５０は、算出された複数の予告日時のそれぞれについて、算出に用いた入札期限を表す情報とそれぞれ対応付けられた予告日時を表す情報を、算出された予告日時を表す情報で更新した後に、予告日時設定処理の実行を終了する。その後、ステップＳ１２から上記処理が繰り返される。

【0081】

ステップＳ１４において、算出部３４０は、仮変更日時が到来していないと判別すると（ステップＳ１４；Ｎｏ）、現在時刻が検証日時よりも後であるか否かに基づいて、検証日時が到来したか否かを判別する（ステップＳ１７）。このとき、算出部３４０は、検証日時が到来したと判別すると（ステップＳ１７；Ｙｅｓ）、入札期限の予告に対するユーザのアクションを記録したログデータを集計するアクション集計処理を実行する（ステップＳ１８）。

【0082】

アクション集計処理を開始すると、算出部３４０は、予告数、予告後アクセス数、予告後アクセス率、応答時間の合計値、期限後開封数、及び期限後開封率を算出する。

【0083】

先ず、予告数の算出方法の一例を説明する。算出部３４０は、図１０のログテーブルにおいて、予告メールを送信したという内容を表す内容情報（以下、送信内容情報という）に対応付けられたユーザＩＤの数をカウントする。これにより、算出部３４０は、予告メールの送信数を算出し、算出した送信数を予告数とする。

【0084】

次に、予告後アクセス数及び予告後アクセス率、並びに応答時間及び応答時間の合計値の算出方法の一例を説明する。算出部３４０は、図１０のログテーブルから、送信内容情報と、送信内容情報に対応付けられた保存日時情報と商品ＩＤと複数のユーザＩＤとの組合せを複数取得する。これにより、算出部３４０は、予告メールの送信日時と、入札期限が予告された商品と、予告を受けた複数のユーザと、の複数の組合せを特定する。

【0085】

次に、算出部３４０は、特定した複数の組合せの内から１つに注目し、注目した組合せを注目組合せとする。また、算出部３４０は、この注目組合せを構成する送信日時と商品と複数のユーザとを、注目送信日時、注目商品、及び複数の注目ユーザとする。

【0086】

その後、算出部３４０は、注目商品の商品ＩＤと対応付けられた入札期限を表す情報を、図８の入札テーブルから取得する。次に、算出部３４０は、注目送信日時から注目商品の入札期限までの日時を表す保存日時情報と、注目商品の商品ＩＤと、複数の注目ユーザのユーザＩＤのいずれかと、に対応付けられた内容情報の内で、入札申込ページにアクセスしたという内容の内容情報を複数取得する。注目送信日時から注目商品の入札期限までに、注目商品を予告されたユーザが、注目商品の入札申込ページにアクセスしたという内容の内容情報を取得するためである。

【0087】

その後、算出部３４０は、取得した内容情報の数をカウントする。注目商品について予告を受けた複数の注目ユーザのいずれかが、予告メールの送信後入札期限までに注目商品の入札申込ページへアクセスした回数を算出するためである。

【0088】

また、算出部３４０は、取得した複数の内容情報にそれぞれ対応付けられた情報で表される保存日時（つまり、アクセス日時）と、注目送信日時と、の差異でそれぞれ表される時間を応答時間とする。注目商品についての予告から、当該予告に反応した複数の注目ユーザのいずれかが入札期限前に入札申込ページへアクセスするまでに要した時間を算出するためである。

【0089】

その後、算出部３４０は、未注目の組合せが無くなるまで上記処理を繰り返した後、それぞれの組合せ毎にカウントした内容情報数を合算して、予告後アクセス数を算出する。その後、算出部３４０は、予告後アクセス数を予告数で除算することで、予告後アクセス率を算出する。また、算出部３４０は、それぞれの組合せ毎に算出した複数の応答時間を合算して、応答時間の合計値を算出する。

【0090】

次に、期限後開封数及び期限後開封率の算出方法の一例を説明する。算出部３４０は、予告後アクセス数の算出と同様に、入札期限が予告された商品と予告を受けた複数のユーザとの組合せを複数特定する。次に、算出部３４０は、特定した複数の組合せの内から１つに注目し、注目した組合せを構成する商品と複数のユーザとを、注目商品及び複数の注目ユーザとする。

【0091】

その後、算出部３４０は、注目商品の商品ＩＤと対応付けられた入札期限を表す情報を図８の入札テーブルから取得した後に、入札期限よりも後の日時を表す保存日時情報と、注目商品の商品ＩＤと、複数の注目ユーザそれぞれのユーザＩＤのいずれかと、に対応付けられた内容情報の内で、予告メールが開封されたという内容の内容情報を複数取得した後に、取得した内容情報の数をカウントする。その後、算出部３４０は、未注目の組合せが無くなるまで上記処理を繰り返した後、それぞれの組合せ毎にカウントした内容情報数を合算した値を期限後開封数とする。その後、算出部３４０は、期限後開封数を予告数で除算することで、期限後開封率を算出する。

【0092】

算出部３４０が、予告数、予告後アクセス率、応答時間の合計値、及び期限後開封率の算出を終了すると、更新部３５０は、これらの値を表す情報で、図９のパラメタテーブルに保存された情報をそれぞれ更新する。その後、更新部３５０は、アクション集計処理の実行を終了する。

【0093】

図１２のステップＳ１８が実行された後、更新部３５０は、ユーザが予告メールに対してどの程度反応したかを表す反応度の最新値を保存する保存パラメタに、最新の反応度を保存する。尚、反応度を一度も算出していない場合には、更新部３５０は、反応度の最低値を保存パラメタに保存する。

【0094】

次に、算出部３４０は、ステップＳ１８のアクション集計処理で算出した予告後アクセス率、応答時間の合計値、及び期限後開封率に基づいて反応度を算出する反応度算出処理を実行する（ステップＳ１９）。

【0095】

算出部３４０は、予告後アクセス率と正の相関を有し、応答期間の合計値と負の相関を有し、期限後開封率と負の相関を有する反応度を算出する。算出部３４０は、ユーザによる予告メールに対する反応が高い程、反応度を高く算出する。算出部３４０が反応度を算出するために用いる適切な算出式は、当業者が設計により定めることができる。

【0096】

その後、更新部３５０は、ステップＳ１９で算出された最新の反応度が、保存パラメタに保存された前回の反応度よりも大きいか否かに基づいて、反応度が向上したか否かを判別する（ステップＳ２０）。このとき、更新部３５０は、反応度が向上したと判別すると（ステップＳ２０；Ｙｅｓ）、図９のパラメタテーブルに保存された設定パラメタの値を、仮変更した値で更新する（ステップＳ２１）。

【0097】

反応度が向上しなかったと判別された場合（ステップＳ２０；Ｎｏ）、又はステップＳ２１の後に、ステップＳ１１から上記処理が繰り返される。

【0098】

これらの構成によれば、予告装置３００は、期限を予告されたユーザが当該期限までに行ったアクションに基づいて算出される反応度が向上するように、予告日時から申込期限までの間隔を更新する。このため、従来よりもユーザの反応度が高くなるような適切な時期に予告が行われる。予告が適切な時期に行われるので、予告から期限までの猶予時間が長すぎるためにユーザが入札の申し込みを忘れたり、猶予時間が短すぎるために入札が期限に間に合わなかったりすることを従来よりも確実に防止できる。

【0099】

これらの構成によれば、予告装置３００は、予告日時から申込期限までの間隔を一時的に変化させることにより反応度が向上すれば、当該間隔を一時的に変化させた値で更新する。このため、予告日時から期限までの間隔が短すぎるために適切な時期に予告が行われていないのか、当該間隔が長過ぎるために適切な時期に予告が行われていないのかが不明な場合であっても、より適切な時期に期限の到来を予告できるようになる。

【0100】

これらの構成によれば、予告装置３００は、期限後開封率と負の相関を有する反応度を向上させるように、予告日時から申込期限までの間隔を更新する。このため、期限到来前に予告メールを開封するユーザが従来よりも増えるので、入札申込ページに対するユーザのアクセス数が従来よりも向上する。

【0101】

これらの構成によれば、予告装置３００は、応答期間と負の相関を有する反応度を向上させるように、予告日時から期限までの間隔を更新する。このため、応答期間が従来よりも減少するので、予告を受けてから入札申込ページへユーザがアクセスし忘れることを従来よりも確実に防止できる。

【0102】

これらの構成によれば、予告装置３００は、予告後アクセス率と正の相関を有した反応度を向上させるように、予告日時から期限までの間隔を更新する。このため、期限前における入札申込ページへのアクセス数が従来よりも増加するので、より活発な取引が行われるようになる。

【実施例2】

【0103】

実施例１では、予告装置３００は、入札期限が属する時間帯にかかわらず、同じ設定パラメタを用いて予告日時を決定するとして説明した。本実施例では、予告装置３００は、入札期限が属する時間帯毎に値を設定されたパラメタを用いて予告日時を決定する。本実施例に係る予告装置３００は、実施例１に係る予告装置３００と同様の構成及び機能を有するので、以下主に相違点について説明する。

【0104】

先ず、図６の情報記憶部３９０が記憶するテーブルの相違について説明する。情報記憶部３９０は、図９のパラメタテーブルに代えて、図１３に示すようなパラメタテーブルを記憶している。図１３のパラメタテーブルには、予め定められた時間帯を表す情報と、当該時間帯に属する期限の予告日時を定める設定パラメタと、当該設定パラメタの更新に用いられる予告数を表す情報等が対応付けられたレコードが複数保存されている。

【0105】

次に、パラメタテーブルを用いた予告処理の相違について説明する。
図１２の予告処理におけるステップＳ１１に示した予告日時設定処理で、図６の算出部３４０は、図８の入札テーブルに保存された複数のレコードのそれぞれから入札期限を表す情報を取得する。次に、取得した複数の情報で表される入札期限のそれぞれについて、入札期限が属する時間帯を表す情報に対応付けられた設定パラメタを、図１３のパラメタテーブルから取得する。その後、算出部３４０は、取得した複数の情報でそれぞれ表される入札期限よりも、期限の属する時間帯用の設定パラメタで表される時間だけ早い日時を予告日時として算出する。

【0106】

その後、図１２のステップＳ１２からＳ１４まで実施例１と同様の処理がなされる。次に、ステップＳ１５に示した仮変更パラメタ値決定処理において、図６の更新部３５０は、図１３のパラメタテーブルに保存された複数の設定パラメタそれぞれについて、設定値を仮変更した値を決定する。

【0107】

その後、図１２のステップＳ１６及びＳ１７まで実施例１と同様の処理がなされる。次に、ステップＳ１８に示したアクション集計処理において、算出部３４０は、図１０のログテーブルに保存されたデータから、時間帯毎の設定パラメタの更新に用いられる数値を算出する。つまり、算出部３４０は、図１３のパラメタテーブルに保存された情報で表される複数の時間帯についてそれぞれ、当該時間帯に行われた予告の予告数、予告後アクセス率、応答時間の合計値、及び期限後開封率を算出する。

【0108】

次に、ステップＳ１９で、算出部３４０は、複数の時間帯毎に算出した予告後アクセス率、応答時間の合計値、及び期限後開封率に基づいて、時間帯毎の反応度を算出する。次に、更新部３５０は、ステップＳ２０で、反応度が向上したか否かを複数の時間帯毎に判別する。このとき、更新部３５０は、反応度が向上したと判別した時間帯の設定パラメタを仮変更した値で更新する。その後、ステップＳ１１から上記処理が繰り返される。

【0109】

ここで、ユーザの生活パターンは、時間帯毎にそれぞれ異なるため、予告に対する反応の仕方が異なることが多い。例えば、深夜１１時から１１時５９分までの時間帯における反応速度は、午前１０時から午後６時までの時間帯における反応速度よりも早いことが多い。午前１０時から午後６時までの時間帯では、多くのユーザが家事や仕事をしているためである。このため、これらの構成によれば、予告装置３００は、複数の取引の期限が属する時間帯毎に、予告日時から申込期限までの間隔を設定するので、時間帯に応じて、従来よりも適切な時期に予告できる。

【実施例3】

【0110】

実施例１では、予告装置３００は、商品が属するジャンルにかかわらず、同じ設定パラメタを用いて予告日時を決定するとして説明した。本実施例では、予告装置３００は、商品が属するジャンル毎に値を設定されたパラメタを用いて予告日時を決定する。本実施例に係る予告装置３００は、実施例１に係る予告装置３００と同様の構成及び機能を有するので、以下主に相違点について説明する。

【0111】

先ず、図６に示した予告装置３００の情報記憶部３９０が記憶するテーブルの相違について説明する。情報記憶部３９０は、図９のパラメタテーブルに代えて、図１４に示すようなパラメタテーブルを記憶している。図１４のパラメタテーブルには、ジャンルＩＤと、当該ジャンルＩＤに属する商品の期限を予告する日時を定める設定パラメタと、設定パラメタの更新に用いられる予告数を表す情報等、が対応付けられたレコードが複数保存されている。

【0112】

次に、パラメタテーブルを用いた予告処理の相違について説明する。
図１２の予告処理におけるステップＳ１１に示した予告日時設定処理において、図６の算出部３４０は、図８の入札テーブルに保存された情報で表される複数の入札期限について予告日時を算出する。このとき、算出部３４０は、複数の入札期限について、期限が予告される商品のジャンル毎に設定された設定パラメタによって表される時間だけ入札期限よりも早い日時を、期限の予告日時とする。

【0113】

また、ステップＳ１５に示した仮変更パラメタ値決定処理において、図６の更新部３５０は、商品のジャンル毎に、設定パラメタの値を仮変更した値を決定する。

【0114】

次に、ステップＳ１８に示したアクション集計処理において、算出部３４０は、商品のジャンル毎に、予告数、予告後アクセス率、応答時間の合計値、及び期限後開封率を算出する。

【0115】

その後、ステップＳ１９で、算出部３４０は、商品のジャンル毎に算出した予告後アクセス率、応答時間の合計値、及び期限後開封率に基づいて、ジャンル毎の反応度を算出する。次に、更新部３５０は、ステップＳ２０で、反応度が向上したか否かを複数のジャンル毎に判別する。このとき、更新部３５０は、反応度が向上したと判別したジャンル用の設定パラメタを仮変更した値で更新する。

【0116】

ここで、商品のジャンルが異なれば、商品の需用者層が異なることが多く、需用者層が異なれば、需用者の生活パターンや予告に対する反応の仕方が異なることが多い。また、ジャンルが異なると、代替品の有無や多少、又は、一品性や量産性が異なることが多い。特に、代替品が無い又は少ない商品や、一品制作的な商品については、需用者の購入意識が他の需用者よりも高く、予告に対する反応速度が速いことが多い。このため、これらの構成によれば、予告装置３００は、ジャンル毎に予告日時から申込期限までの間隔を設定するので、ジャンルに応じて、従来よりも適切な時期に予告できる。

【実施例4】

【0117】

実施例１では、予告装置３００は、申込期限の自動延長の有無にかかわらず、同じ設定パラメタを用いて予告日時を決定するとして説明した。本実施例では、予告装置３００は、自動延長の有無に基づいて値を設定されたパラメタを用いて予告日時を決定する。本実施例に係る予告装置３００は、実施例１に係る予告装置３００と同様の構成及び機能を有するので、以下主に相違点について説明する。

【0118】

入札の自動延長とは、入札期限から予め定められた第１時間だけ前の日時から入札期限までの間に入札があった場合に、入札期限を予め定められた第２時間だけ後の日時に延長することをいう。本実施例では、第１時間及び第２時間は、５分間であるとして説明するが、これに限定される訳では無い。

【0119】

先ず、図６に示した予告装置３００の情報記憶部３９０が記憶するテーブルの相違について説明する。情報記憶部３９０は、図９のパラメタテーブルに代えて、図１５に示すようなパラメタテーブルを記憶している。図１５のパラメタテーブルには、自動延長が有ることを表す情報と、自動延長が有る期限の予告日時を定める設定パラメタと、当該設定パラメタの更新に用いられる予告数を表す情報等、が対応付けられたレコードが１つ保存されている。また、図１５のパラメタテーブルには、自動延長が無いことを表す情報と、自動延長が無い期限の予告日時を定める設定パラメタと、当該設定パラメタの更新に用いられる予告数を表す情報等、が対応付けられたレコードが１つ保存されている。

【0120】

次に、パラメタテーブルを用いた予告処理の相違について説明する。
図１２の予告処理におけるステップＳ１１において、算出部３４０は、図８の入札テーブルに保存された情報で表される複数の入札期限の内で、自動延長される期限について、自動延長される期限用の設定パラメタを用いて予告日時を算出する。これに対して、算出部３４０は、複数の入札期限の内で、自動延長されない期限について、自動延長されない期限用の設定パラメタを用いて予告日時を算出する。

【0121】

また、ステップＳ１５において、図６の更新部３５０は、自動延長が有る期限用の設定パラメタと、自動延長が無い期限用の設定パラメタと、のそれぞれについて、設定値を仮変更した値を決定する。さらに、ステップＳ１８において、算出部３４０は、自動延長の有る期限と無い期限とについてそれぞれ、期限の予告数、予告後アクセス率、応答時間の合計値、及び期限後開封率を算出する。

【0122】

その後、ステップＳ１９で、算出部３４０は、自動延長の有無毎に算出した予告後アクセス率、応答時間の合計値、及び期限後開封率に基づいて、自動延長の有る期限と、自動延長の無い期限と、のそれぞれについて反応度を算出する。次に、更新部３５０は、ステップＳ２０で、反応度が向上したか否かを自動延長の有無それぞれについて判別する。このとき、更新部３５０は、自動延長の有る期限について反応度が向上したと判別すると、自動延長の有る期限用の設定パラメタを仮変更した値で更新し、自動延長の無い期限について反応度が向上したと判別すると、自動延長の無い期限用の設定パラメタを仮変更した値で更新する。

【0123】

ここで、期限の自動延長の有無が異なれば、予告に対するユーザの反応の仕方が異なることが多い。期限に自動延長が無ければ、期限までに申込みをしなければならないが、期限に自動延長があれば、期限までに申込みをしなくとも、期限が延長されれば、延長された期限までに申込みできる可能性があるためである。このため、これらの構成によれば、予告装置３００は、期限の自動延長がされる取引とされない取引とのそれぞれに対して、予告日時から申込期限までの間隔を設定するので、自動延長の有無に応じて、従来よりも適切な時期に予告できる。

【実施例5】

【0124】

実施例１では、予告装置３００は、ウォッチリストを記憶し、予告日時になるとウォッチリストに登録された複数のユーザそれぞれが使用する端末装置に予告メッセージを送信するとして説明した。しかし、本実施例では、予告装置３００は、ウォッチリストを記憶せず、予告メッセージを送信しない。本実施例に係る端末装置１１０及び１２０並びに予告装置３００は、実施例１に係る端末装置１１０及び１２０並びに予告装置３００とそれぞれ同様の構成及び機能を有するので、以下主に相違点について説明する。

【0125】

端末装置１１０及び１２０は、図５に示した予告装置と同様の構成を有し、互いにバスで接続されたＣＰＵ、ＲＯＭ、ＲＡＭ、大容量メモリ、メディアコントローラ、ＬＡＮカード、ビデオカード、ＬＣＤ等の表示部１１９、スピーカ、及びタッチパネル等の入力部１１１で構成される。尚、端末装置１１０及び１２０は、互いに同様の構成を有し、同様の動作を行うため、以下主に、端末装置１１０について説明を行う。

【0126】

端末装置１１０のＣＰＵは、大容量メモリに保存されたオークション用のアプリケーションを実行することで、図１７に示す期限取得部１１２、登録部１１３、及び通知部１１４として機能する。また、大容量メモリは、ＣＰＵと協働して、情報記憶部１１５として機能する。

【0127】

端末装置１１０は、オークションに出品された商品ＩＤ、商品の名称を表す情報、現在価格を表す情報、及び入札期限を表す情報から成る複数の組合せ、及び設定パラメタを、予告装置３００からＬＡＮカードで受信し、受信した情報を表示する。

【0128】

その後、表示を確認したユーザは、ウォッチする商品を選択する操作等を行い、端末装置１１０は、当該操作に応じてウォッチ商品ＩＤを入力する。その後、端末装置１１０の期限取得部１１２は、ウォッチ商品ＩＤに組み合わされた入札期限を表す情報と、設定パラメタと、をＬＡＮカードから取得する。

【0129】

その後、登録部１１３は、入札期限よりも設定パラメタが表す時間だけ前の日時を予告日時とする。次に、登録部１１３は、ウォッチ商品ＩＤと、ウォッチ商品の入札期限を表す情報と、に対応付けて予告日時を表す情報を、端末装置１１０の情報記憶部１１５に記憶されたウォッチリストに追加登録する。

【0130】

その後、端末装置１１０の通知部１１４は、定期的に現在時刻を取得する。通知部１１４は、現在時刻がウォッチリストに登録された予告日時となると、当該予告日時に対応付けられた商品ＩＤで識別されるウォッチ商品の入札期限が到来することを予告する予告メッセージを生成する。次に、通知部１１４は、予告メッセージを表示部１１９又はスピーカから出力させることで、期限の予告を行う。

【0131】

端末装置１１０は、予告メッセージを出力すると、予告メッセージを出力したという内容の内容情報を生成する。次に、端末装置１１０は、生成した内容情報を、期限が予告された商品の商品ＩＤと、予告を確認したユーザのユーザＩＤと、に対応付けて予告装置３００へ送信する。予告装置３００にログを保存させるためである。

【0132】

尚、ユーザが入札商品を選択する操作をした場合も同様に、端末装置１１０は、入札商品ＩＤと、入札期限を表す情報と、予告日時を表す情報と、を対応付けて、端末装置１１０のウォッチリストに追加登録する。

【0133】

端末装置１１０は、ユーザによって予告メッセージを確認したことを示す操作が行われると、予告メッセージが確認されたという内容の内容情報を生成する。次に、端末装置１１０は、期限が予告された商品の商品ＩＤと、予告を確認したユーザのユーザＩＤと、を対応付けて予告装置３００へ送信する。

【0134】

本実施例の予告装置３００は、図１６に示すように、情報取得部３２０、検索部３２５、登録部３３０、算出部３４０、及び更新部３５０を有する。

【0135】

予告装置３００は、図１２の予告処理において、ステップＳ１３の予告メッセージ出力処理を実行しない。端末装置１１０が予告メッセージを出力するためである。しかし、予告装置３００は、ステップＳ１３以外の処理を、情報取得部３２０、検索部３２５、登録部３３０、算出部３４０、及び更新部３５０で実行することで、設定パラメタをより好適な値に更新した後に、更新された設定パラメタを、要求に応じて端末装置１１０に送信する。

【0136】

これらの構成によれば、端末装置１１０が期限の到来を予告するので、予告装置３００が予告に要する処理負荷を従来又は実施例１よりも軽減できる。このため、取引をウォッチするユーザの数が増加しても、予告装置３００の処理負荷の増加を抑制できるので、処理負荷の増大による予告の遅延を防止できる。

【0137】

尚、端末装置１１０は、設定パラメタの値として、予告装置３００から送信された値のみを使用するのではなく、例えば、３０分などの予め定められた値を使用したり、ユーザが入力した値を使用したりできる。端末装置１１０は、ユーザの選択操作に従って、設定パラメタの値を変更できる。この構成によれば、ユーザが意図しない時期に期限が予告されることを防止できる。

【実施例6】

【0138】

実施例１では、予告装置３００の更新部３５０は、図１２のステップＳ１５において、設定パラメタの値を仮変更した値を、現在の設定パラメタの値から所定値だけ増加させた値とするか、所定値だけ減少させた値とするか、ランダムに決定するとして説明した。しかし、これに限定される訳ではない。例えば、更新部３５０は、前回に設定パラメタを所定値だけ増加させた値に仮変更した結果、反応度が向上したと判定された場合に、今回も、現在の設定パラメタの値を所定値だけ増加させた値とする、又は、所定値だけ増加させた値とする確率を増加させるとしても良い。逆に、更新部３５０は、前回に設定パラメタを所定値だけ減少させた値に仮変更した結果、反応度が向上したと判定された場合に、今回も、現在の設定パラメタの値を所定値だけ減少させた値とする、又は、所定値だけ減少させた値とする確率を増加させるとしても良い。

【実施例7】

【0139】

実施例１では、予告装置３００の算出部３５０は、予告後アクセス率、応答期間の合計値、及び期限後開封率を算出し、これらの値と相関を有する反応度を算出するとして説明した。実施例７では、入札期限までにアクセスが間に合ったユーザの数に占める、アクセスが間に合ったが入札が間に合わなかったユーザの割合と負の相関を有する反応度を算出する。

【0140】

具体的には、算出部３５０は、先ず、図１０のログテーブルに保存されたデータに基づいて、予告後から入札期限までの間に入札申込ページにアクセスしたユーザ（以下、アクセスが間に合ったユーザという）の数を算出する。また、算出部３５０は、アクセスが間に合ったユーザの内で、入札を行わなかったユーザ（以下、入札が間に合わなかったユーザという）の数を算出する。さらに、算出部３５０は、アクセスが間に合ったユーザに対する入札が間に合わなかったユーザの割合を算出し、この割合と負の相関を有する反応度を算出する。更新部３５０は、この割合と負の相関を有する反応度が向上するように設定パラメタを更新する。

【0141】

実施例１では、予告装置３００は、全ユーザに共通の設定パラメタを用いて予告日時を決定するとして説明したが、これに限定される訳では無く、ユーザ毎に個別の設定パラメタを用いて予告日時を決定しても良い。また、ユーザが属する需用者層毎に用意された設定パラメタを用いて予告日時を決定しても良い。

【0142】

実施例１から７の予告装置３００は、番組表を表す情報と、番組の予測視聴率を表す情報と、を対応付けてさらに記憶しており、期限よりも予め定められた時間前の時点から当該期限までの間に放送される番組の視聴率のいずれか１つ以上が所定の閾値を超える場合に、設定パラメタの値を増加させても良い。

【0143】

実施例１から７では、電子商取引について説明したが、これに限定される訳ではなく、取引は、商取引でなくともよく、無償の借り受けや貸し渡しであってもよい。また、取引は、電子取引でなくともよく、取引の一部又は全部が、コンピュータネットワークによる電子的な情報通信によって行われなくともよい。

【0144】

実施例１から７では、申し込み期限が設定された取引として、オークション取引を例に挙げて説明したが、これに限定される訳では無く、タイムセールや特売期間の設定された特売品の取引であってもよい。

【0145】

実施例１から７では、取引の申し込みとして、オークションに対する入札を例に挙げて説明したが、これに限定される訳では無く、商品の購入申し込みや、レンタルの申し込みであってもよい。

【0146】

実施例１から７では、取引の対象とされるものは、商品であるとして説明したが、役務であってもよく、取引の対象とされるものであればどのようなものでも良い。商品とは、商取引の目的足りうべき物を含み、動産に限定されるのではなく、不動産も含むが、これらに限定される訳では無い。役務とは、他人のために行う労務又は便益であって、独立して商取引の目的足りうべきものを含むが、これらに限定される訳では無い。

【0147】

実施例１から７では、予告後アクセス数は、入札期限の到来を予告された商品の入札申込ページに対するアクセス総数の内で、予告を受けたユーザによる予告後から入札期限までのアクセスをカウントしたものをいうとして説明した。しかし、これに限定される訳ではない。予告後アクセス数は、最初のアクセスのみをカウントしたものであってもよい。つまり、予告後アクセス数は、入札期限を予告された商品の入札申込ページに対するアクセス総数の内で、予告を受けたユーザによって予告後から期限前までの間に行われた最初のアクセスのみをカウントしたものであってもよい。また、予告後アクセス数は、予告日時から期限前に終了する予め定められた時間内に行われたアクセスをカウントしたものであっても良い。さらに、予告後アクセス数は、予告メールの送信日時、確認日時、及び開封日時のいずれかの時点から期限の到来時点までに行われたアクセスをカウントしたものであっても良い。

【0148】

応答時間は、予告メールの送信から最初のアクセスがあるまでの時間をいうとしても良い。つまり、応答時間は、予告メールの送信時点から、予告メールを確認したユーザが期限を予告された商品の入札申込ページに、予告後から期限までの間に最初にアクセスした時点までの時間をいうとしても良い。また、応答時間は、予告メールの送信時点から、当該送信日時から開始して期限前に終了する予め定められた時間内に入札申込ページへアクセスした時点までの時間をいうとしても良い。さらに、応答時間は、予告メールの送付時点、確認時点、及び開封時点のいずれかから、期限前に入札申込ページへアクセスした時点までの時間をいうとしても良い。

【0149】

実施例１から６では、算出部３４０は、予告後アクセス率と反応度とが正の相関を有し、応答期間の合計値と反応度とが負の相関を有し、期限後開封率と反応度とが負の相関を有するように、反応度を算出するとして説明した。しかし、これに限定されるのではなく、算出部３４０は、予告後アクセス率、応答期間の合計値、及び期限後開封率のいずれか１つのみと相関を有する反応度や、アクセス率、応答期間の合計値、及び期限後開封率のいずれか２つのみと相関を有する反応度を算出しても良い。

【0150】

実施例１から７は、互いに組み合わせることができる。実施例１から７のいずれかに係る機能を実現するための構成を備えた予告装置３００として提供できることはもとより、複数の装置で構成されるシステムであって、実施例１から７のいずれかに係る機能を実現するための構成をシステム全体として備えたシステムとして提供することもできる。

【0151】

尚、実施例１から７のいずれかに係る機能を実現するための構成を予め備えた予告装置３００として提供できることはもとより、プログラムの適用により、既存の予告装置を実施例１から７のいずれかに係る予告装置３００として機能させることもできる。すなわち、実施例１から７のいずれかで例示した予告装置３００による各機能構成を実現させるためのプログラムを、既存の予告装置を制御するコンピュータ（ＣＰＵなど）が実行できるように適用することで、実施例１から７のいずれかに係る予告装置３００として機能させることができる。

【0152】

このようなプログラムの配布方法は任意であり、例えば、メモリカード、ＣＤ−ＲＯＭ、又はＤＶＤ−ＲＯＭなどの記録媒体に格納して配布できる他、インターネットなどの通信媒体を介して配布することもできる。また、本発明に係る方法は、実施例１から７のいずれかに係る予告装置３００を用いて実施できる。

【0153】

以上本発明の好ましい実施例について詳述したが、本発明は係る特定の実施例に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形、変更が可能である。

【0154】

また、上述した実施形態は、本発明を説明するためのものであり、本発明の範囲を限定するものではない。つまり、本発明の範囲は、実施形態ではなく、請求の範囲によって示される。そして、請求の範囲内及びそれと同等の発明の意義の範囲内で施される様々な変形が、本発明の範囲内とみなされる。

【符号の説明】

【0155】

１０：通信網
１１０、１２０：端末装置
１１１、１２１：入力部
１１２：期間取得部
１１３：登録部
１１４：通知部
１１５：情報記憶部
１１９、１２９：表示部
３００：予告装置
３０１：ＣＰＵ
３０２：ＲＯＭ
３０３：ＲＡＭ
３０４：ハードディスク
３０５：メディアコントローラ
３０６：ＬＡＮカード
３０７：ビデオカード
３０８：ＬＣＤ
３０９：キーボード
３１０：スピーカ
３１１：タッチパッド
３２０：情報取得部
３２５：検索部
３３０：登録部
３４０：算出部
３５０：更新部
３６０：期限取得部
３７０：通知部
３９０：情報記憶部

【要約】

予告装置（３００）は、複数の取引の各取引について、前記各取引の期限に、設定された間隔だけ先行する予告日時を取得する情報取得部（３２０）を備える。予告装置（３００）は、前記各取引について取得された前記予告日時が到来した後、前記各取引の前記期限の予告を、前記各取引をウォッチするユーザに通知する通知部（３７０）を備える。予告装置（３００）は、前記各取引に係る前記予告を通知されたユーザが、前記各取引の前記期限までに、前記各取引に対して行ったアクションに基づいて、前記複数の取引について前記通知部により通知された前記予告に対する反応度を算出する算出部（３４０）を備える。予告装置（３００）は、前記算出された反応度が向上するように、前記間隔を更新する更新部（３５０）を備える。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】