(58)【調査した分野】(Int.Cl.,DB名)
前記提示部は、前記まとめ期間内取引の各々の申込ページへのリンクを列挙したリストページを前記ユーザに提示することにより、前記まとめ期間内の取引の各々の申込ページの情報をまとめて、前記ユーザに提示する
ことを特徴とする請求項1に記載の予告装置。
前記第1時間長、前記第2時間長、ならびに、前記間隔を一時的に変化させることにより、前記反応度が向上すれば、前記更新部は、前記第1時間長、前記第2時間長、ならびに、前記間隔を一時的に変化させた値に更新する
ことを特徴とする請求項1に記載の予告装置。
前記アクションは、前記予告が通知された後に、前記ユーザが前記まとめ期間内の各取引の申込ページに前記リストページからアクセスすることであり、前記反応度は、前記予告が通知された時点から、前記まとめ期間内の各取引の申込ページにアクセスした時点の平均に負の相関をするように、算出される
ことを特徴とする請求項4に記載の予告装置。
前記アクションは、前記予告が通知された後に、前記ユーザが前記まとめ期間内に各取引の申込ページに前記リストページからアクセスすること、もしくは、前記リストページからアクセスした前記申込ページから申込を行うことであり、前記反応度は、当該アクセスの数、もしくは、当該申込の数に正に相関をするように、算出される
ことを特徴とする請求項4に記載の予告装置。
前記提示部は、前記まとめ期間内の取引の各々の申込ページをすべて、互いに異なるブラウザウィンドウもしくはブラウザ内の互いに異なるタブを介して提示することにより、前記まとめ期間内取引の各々の申込ページの情報をまとめて、前記ユーザに提示する
ことを特徴とする請求項1に記載の予告装置。
前記ユーザが新たな取引をウォッチの対象とするごとに、条件「前記ユーザがウォッチする既存の取引であって、当該既存の取引の期限が当該新たな取引の期限に先行し、当該既存の取引に対して定められたまとめ期間内に当該新たな取引の予告日時が含まれる既存の取引がある」が満たされるか否かを判定し、
前記条件が満たされなければ、前記新たな取引の予告日時に当該新たな取引の期限の予告をする通知が記載されたメールを送信すべき予約登録を、メールサーバに対して行い、
前記条件が満たされれば、前記新たな取引の期限の予告の通知を省略する旨を前記ユーザに知らせる
ことを特徴とする請求項1に記載の予告装置。
【発明の概要】
【発明が解決しようとする課題】
【0004】
特許文献1に開示されているようなシステムにおいて、購入申込期限が近い複数の商品がウォッチリストに登録されている場合、ユーザには複数のリマインダメールが近い時刻でそれぞれ送信される。従って、ユーザがその複数のリマインダメールのうち、いくつかを見逃す可能性があり、その結果、見逃したリマインダメールに係る商品の購入申込期限を忘れて申込ができなくなってしまう可能性がある。
【0005】
本発明は、上記実情に鑑みてなされたものであり、ユーザが、取引の期限が近い複数の取引をウォッチしている場合に、その取引の申込し忘れを防止することが可能な予告装置、予告方法、プログラム、及び記録媒体を提供することを目的とする。
【課題を解決するための手段】
【0006】
上記目的を達成するために、本発明の第1の観点に係る予告装置は、
ユーザがウォッチする複数の取引の各取引に対応付けられる予告日時であって、当該各取引の期限に設定された間隔だけ先行する予告日時を取得する取得部、
前記各取引に対応付けられる前記予告日時が到来した後、前記各取引の前記期限の予告を、前記ユーザに通知する通知部、
前記予告が通知された前記ユーザが、前記予告に係る前記取引の前記期限までに、前記予告に指定されたアクションを行うと、前記複数の取引のうち、前記予告に係る前記取引の前記期限を含むまとめ期間を定め、前記まとめ期間内に期限が到来するまとめ期間内取引が、前記予告に係る前記取引のみであれば、前記予告に係る前記取引の申込ページを、前記ユーザに提示し、前記まとめ期間内取引が、複数であれば、前記まとめ期間内取引の各々の申込ページの情報をまとめて、前記ユーザに提示する提示部
を備えることを特徴とする。
【0007】
上記の観点に係る予告装置において、
前記提示部は、前記まとめ期間内取引の各々の申込ページへのリンクを列挙したリストページを前記ユーザに提示することにより、前記まとめ期間内の取引の各々の申込ページの情報をまとめて、前記ユーザに提示する
ことを特徴とする。
【0008】
上記の観点に係る予告装置において、
前記まとめ期間の始期は、前記取引の前記期限から第1時間長だけ先行する時点であり、
前記まとめ期間の終期は、前記取引の前記期限から第2時間長だけ後行する時点であり、
前記ユーザが、前記まとめ期間内取引の各取引に対して行ったアクションに基づいて、前記通知された前記予告に対する反応度を算出する算出部、
前記算出された反応度が向上するように、前記第1時間長、前記第2時間長、ならびに、前記間隔を更新する更新部
をさらに備えることを特徴とする。
【0009】
上記の観点に係る予告装置において、
前記第1時間長、前記第2時間長、ならびに、前記間隔を一時的に変化させることにより、前記反応度が向上すれば、前記更新部は、前記第1時間長、前記第2時間長、ならびに、前記間隔を一時的に変化させた値に更新する
ことを特徴とする。
【0010】
上記の観点に係る予告装置において、
前記アクションは、前記予告が通知された後に、前記ユーザが前記まとめ期間内の各取引の申込ページに前記リストページからアクセスすることであり、前記反応度は、前記予告が通知された時点から、前記まとめ期間内の各取引の申込ページにアクセスした時点の平均に負の相関をするように、算出される
ことを特徴とする。
【0011】
上記の観点に係る予告装置において、
前記アクションは、前記予告が通知された後に、前記ユーザが前記まとめ期間内に各取引の申込ページに前記リストページからアクセスすること、もしくは、前記リストページからアクセスした前記申込ページから申込を行うことであり、前記反応度は、当該アクセスの数、もしくは、当該申込の数に正に相関をするように、算出される
ことを特徴とする。
【0012】
上記の観点に係る予告装置において、
前記提示部は、前記まとめ期間内の取引の各々の申込ページをすべて、互いに異なるブラウザウィンドウもしくはブラウザ内の互いに異なるタブを介して提示することにより、前記まとめ期間内取引の各々の申込ページの情報をまとめて、前記ユーザに提示する
ことを特徴とする。
【0013】
上記の観点に係る予告装置において、
前記ユーザが新たな取引をウォッチの対象とするごとに、条件「前記ユーザがウォッチする既存の取引であって、当該既存の取引の期限が当該新たな取引の期限に先行し、当該既存の取引に対して定められたまとめ期間内に当該新たな取引の予告日時が含まれる既存の取引がある」が満たされるか否かを判定し、
前記条件が満たされなければ、前記新たな取引の予告日時に当該新たな取引の期限の予告をする通知が記載されたメールを送信すべき予約登録を、メールサーバに対して行い、
前記条件が満たされれば、前記新たな取引の期限の予告の通知を省略する旨を前記ユーザに知らせる
ことを特徴とする。
【0014】
本発明の第2の観点に係る予告方法は、
取得部と、通知部と、提示部と、を備える予告装置が実行する予告方法であって、
前記取得部が、ユーザがウォッチする複数の取引の各取引に対応付けられる予告日時であって、当該各取引の期限に設定された間隔だけ先行する予告日時を取得する取得ステップと、
前記通知部が、前記各取引に対応付けられる前記予告日時が到来した後、前記各取引の前記期限の予告を、前記ユーザに通知する通知ステップと、
前記提示部が、前記予告が通知された前記ユーザが、前記予告に係る前記取引の前記期限までに、前記予告に指定されたアクションを行うと、前記複数の取引のうち、前記予告に係る前記取引の前記期限を含むまとめ期間を定め、前記まとめ期間内に期限が到来するまとめ期間内取引が、前記予告に係る前記取引のみであれば、前記予告に係る前記取引の申込ページを、前記ユーザに提示し、前記まとめ期間内取引が、複数であれば、前記まとめ期間内取引の各々の申込ページの情報をまとめて、前記ユーザに提示する提示ステップと、
を備えることを特徴とする。
【0015】
本発明の第3の観点に係るプログラムは、
コンピュータを、
ユーザがウォッチする複数の取引の各取引に対応付けられる予告日時であって、当該各取引の期限に設定された間隔だけ先行する予告日時を取得する取得部、
前記各取引に対応付けられる前記予告日時が到来した後、前記各取引の前記期限の予告を、前記ユーザに通知する通知部、
前記予告が通知された前記ユーザが、前記予告に係る前記取引の前記期限までに、前記予告に指定されたアクションを行うと、前記複数の取引のうち、前記予告に係る前記取引の前記期限を含むまとめ期間を定め、前記まとめ期間内に期限が到来するまとめ期間内取引が、前記予告に係る前記取引のみであれば、前記予告に係る前記取引の申込ページを、前記ユーザに提示し、前記まとめ期間内取引が、複数であれば、前記まとめ期間内取引の各々の申込ページの情報をまとめて、前記ユーザに提示する提示部
として機能させることを特徴とする。
【0016】
本発明の第4の観点に係るコンピュータ読み取り可能な記録媒体は、
コンピュータを、
ユーザがウォッチする複数の取引の各取引に対応付けられる予告日時であって、当該各取引の期限に設定された間隔だけ先行する予告日時を取得する取得部、
前記各取引に対応付けられる前記予告日時が到来した後、前記各取引の前記期限の予告を、前記ユーザに通知する通知部、
前記予告が通知された前記ユーザが、前記予告に係る前記取引の前記期限までに、前記予告に指定されたアクションを行うと、前記複数の取引のうち、前記予告に係る前記取引の前記期限を含むまとめ期間を定め、前記まとめ期間内に期限が到来するまとめ期間内取引が、前記予告に係る前記取引のみであれば、前記予告に係る前記取引の申込ページを、前記ユーザに提示し、前記まとめ期間内取引が、複数であれば、前記まとめ期間内取引の各々の申込ページの情報をまとめて、前記ユーザに提示する提示部
として機能させることを特徴とするプログラムを記録する。
【発明の効果】
【0017】
本発明によれば、ユーザが、取引の期限が近い複数の取引をウォッチしている場合に、その取引の申込し忘れを防止することができる。
【発明を実施するための形態】
【0019】
本発明の実施の形態について、図面を参照して詳細に説明する。
【0020】
(実施の形態1)
本発明の実施の形態1に係る予告システム1は、取引の申込期限の前に、当該期限の到来を予告する。本実施の形態1では、取引の申込期限の一例として、インターネット・オークションにおける入札が締め切られる日時(以下、入札期限という)を例に挙げて説明する。
【0021】
予告システム1は、
図1に示すような、端末装置110及び120と、端末装置110及び120と無線通信可能な基地局200と、基地局200とコンピュータ通信網10(以下単に、通信網10という)を介して通信可能に接続された予告装置300と、で構成される。
【0022】
通信網10は、例えば、インターネットで構成される。通信網10は、LAN(Local Area Network)又は公衆回線網であっても良い。
【0023】
端末装置110及び120は、例えば、携帯電話で構成される。端末装置110及び120は、ノート型のパーソナル・コンピュータであっても、タブレット型のコンピュータであっても良い。
【0024】
端末装置110は、ユーザが、インターネット・オークションで入札可能な商品を検索し、入札するために用いられる装置であって、例えば、タッチパッドなどの入力部111と、LCD(Liquid Crystal Display)などの表示部119と、を備える。端末装置120は、端末装置110が有する入力部111及び表示部119と同様の構成を有する入力部121及び表示部129で構成される。端末装置110及び120は、互いに同様の構成を有し、同様の動作を行うため、以下主に、端末装置110について説明を行う。
【0025】
基地局200は、例えば、携帯電話の基地局や無線LANの基地局である。基地局200は、端末装置110及び120と予告装置300との通信を中継する。
【0026】
予告装置300は、例えば、サーバ機で構成され、端末装置110からのリクエストに応じて、インターネット・オークションで入札可能な商品の検索処理や入札処理を実行する。
【0027】
また、予告装置300は、端末装置110から、ユーザが取引のウォッチを希望する商品(以下、ウォッチ商品と呼ぶ)の登録を受け付け、そのウォッチ商品のウォッチリストに登録する。ここで、取引をウォッチするとは、取引状況の変化についての通知を受けることをいう。この通知は、予告装置300が記憶するウォッチリストと称されるリストに識別情報(以下、ユーザIDという)が登録されているユーザに対して行われる。このため、取引をウォッチするユーザのことを、ウォッチリストに登録されたユーザともいう。なお、取引状況の変化についての通知は、取引の申込期限の到来についての予告を含むが、これに限定される訳では無く、例えば、入札取引であれば、最高額入札額が変化したことや、最高額で入札しているユーザ(以下、最高額入札者という)が別のユーザに代わったことの通知を含む。
【0028】
図2に、予告装置300のハードウェア構成の一例を示す。
図2に示すように、予告装置300は、CPU(Central Processing Unit)3001、ROM(Read Only Memory)3002、RAM(Random Access Memory)3003、ハードディスク3004、メディアコントローラ3005、LAN(Local Area Network)カード3006、ビデオカード3007、LCD(Liquid Crystal Display)3008、キーボード3009、スピーカ3010、及びタッチパッド3011で構成される。
【0029】
CPU3001は、ROM3002又はハードディスク3004に保存されたプログラムに従ってプログラムを実行することで、予告装置300の全体制御を行う。RAM3003は、CPU3001によるプログラムの実行時において、処理対象とするデータを一時的に記憶するワークメモリである。
【0030】
ハードディスク3004は、各種のデータを保存したテーブルを記憶する情報記憶部である。尚、予告装置300は、ハードディスク3004の代わりに、フラッシュメモリを備えても良い。
【0031】
メディアコントローラ3005は、フラッシュメモリ、CD(Compact Disc)、DVD(Digital Versatile Disc)、及びブルーレイディスク(Blu-ray Disc)(登録商標)を含む記録媒体から各種のデータ及びプログラムを読み出す。
【0032】
LANカード3006は、通信網10及び基地局200を介して接続する端末装置110及び120との間でデータを送受信する。キーボード3009及びタッチパッド3011は、ユーザの操作に応じた信号を入力する。
【0033】
ビデオカード3007は、CPU3001から出力されたデジタル信号に基づいて画像を描画(つまり、レンダリング)すると共に、描画された画像を表す画像信号を出力する。LCD3008は、ビデオカード3007から出力された画像信号に従って画像を表示する。なお、予告装置300は、LCD3008の代わりに、PDP(Plasma Display Panel)又はEL(Electroluminescence)ディスプレイを備えても良い。スピーカ3010は、CPU3001から出力された信号に基づいて音声を出力する。
【0034】
次に、予告装置300の有する機能について説明する。
図3に示すように、予告装置300は、情報記憶部310、予告日時取得部320、情報取得部330、検索部340、登録部350、通知部360、提示部370として機能する。
【0035】
情報記憶部310は、
図4に示すような商品テーブル311を記憶している。商品テーブル311には、オークションに出品された商品を識別する情報(以下、商品IDという)と、商品名と、その商品のオークションが開始される日時と、その商品のオークションが終了する日時(以下、入札期限という)と、オークション開始時における商品の価格と、が対応付けられたレコードが複数保存されている。これらのレコードは、商品の出品者または予告装置300の管理者により商品テーブル311に記録される。
【0036】
また、情報記憶部310は、
図5に示すような入札テーブル312を記憶している。入札テーブルには、
図4の商品テーブル311に保存されている商品IDと、商品IDで識別される商品の入札期限と、入札期限の到来を予告する日時(以下、予告日時という)と、当該商品の現在価格と、最高額入札者のユーザIDと、当該商品をウォッチリストに登録したユーザのユーザIDが対応付けられたレコードが複数保存される。
【0037】
図2に示したハードディスク3004は、CPU3001と協働して、
図3に示す情報記憶部310として機能する。
【0038】
予告日時取得部320は、入札テーブル312に記録された各商品について、その商品の入札期限から、予め設定された予告間隔だけ早い日時を予告日時として取得する。そして、予告日時取得部320は、取得された予告日時を入札テーブル312に保存する。なお、本実施の形態1では、予告間隔は、30分に設定されているとして説明するが、これに限定される訳ではない。
【0039】
図2に示したCPU3001は、
図3に示す予告日時取得部320として機能する。
【0040】
情報取得部330は、端末装置110から各種情報を取得する。例えば、情報取得部330は、端末装置110から、インターネット・オークションで入札可能な商品の検索を要求する検索リクエストを取得する。検索リクエストには、端末装置110の入力部111を介してユーザにより入力された、商品の検索条件を表すデータが含まれる。情報取得部330は、検索リクエストを取得すると、検索リクエストに含まれるデータを、検索部340に出力する。
【0041】
また、情報取得部330は、端末装置110から、インターネット・オークションで入札可能な商品のウォッチリストへの登録を要求するウォッチリクエストを取得する。ウォッチリクエストには、端末装置110のユーザのユーザIDと、ウォッチ対象とされる商品を識別する情報(以下、ウォッチ商品IDという)と、が含まれる。情報取得部330は、ウォッチリクエストを取得すると、ウォッチリクエストに含まれるデータを、登録部350に出力する。
【0042】
また、情報取得部330は、端末装置110から、インターネット・オークションで入札可能な商品の入札を申し込むための申込ページの送信を要求する送信リクエストを取得する。送信リクエストには、端末装置110のユーザのユーザIDと、入札する商品(以下、入札商品という)を識別する情報(以下、入札商品IDという)とが含まれる。情報取得部330は、送信リクエストを取得すると、送信リクエストに含まれるデータを、提示部370に出力する。
【0043】
また、情報取得部330は、端末装置110から、インターネット・オークションで入札可能な商品の入札の申込を要求する入札リクエストを取得する。入札リクエストには、端末装置110のユーザのユーザID(以下、入札ユーザIDという)と、入札商品IDと、入札商品の入札額と、が含まれる。情報取得部330は、入札リクエストを取得すると、入札リクエストに含まれるデータを、登録部350に出力する。
【0044】
図2に示したLANカード3006は、CPU3001と協働して、
図3に示す情報取得部330として機能する。
【0045】
検索部340は、情報取得部330により取得された検索リクエストに含まれる、商品の検索条件を表すデータに基づいて、商品テーブル311から、検索条件を満足する商品を検索する。そして、検索部340は、検索条件にマッチする商品の情報を、検索リクエストを送信した端末装置110に送信する。
【0046】
例えば、検索部340は、検索条件を満足する商品の名称、現在価格、入札数、及び入札期限を表す情報を商品テーブル311から取得する。そして、検索部340は、
図6に一例として示すように、取得した情報がリスト化された検索結果リスト41を含む検索結果ページ40を端末装置110に送信する。
【0047】
また、端末装置110のユーザが、表示部119に表示された検索結果ページ40を閲覧し、検索結果リスト41の中から興味がある商品を選択すると、検索部340は、
図7に一例として示すように、選択された商品の入札を申し込むための申込ページ50を端末装置110に送信する。申込ページ50は、商品及びその入札に関する情報を表す商品情報51と、端末装置110のユーザをその商品のウォッチリストに登録するための登録ボタン52と、その商品を入札するための入札ボタン53とを含む。ユーザが登録ボタン52を選択すると、端末装置110は、その商品のウォッチリクエストを予告装置300に送信する。また、ユーザが入札ボタン53を選択すると、端末装置110は、その商品の入札リクエストを予告装置300に送信する。
【0048】
図2に示したCPU3001は、LANカード3006と協働して、
図3に示す検索部340として機能する。
【0049】
登録部350は、情報取得部330により取得されたウォッチリクエストに含まれるウォッチ商品IDと、ユーザIDと、に基づいて、入札テーブル312のウォッチリストにユーザを追加する。具体的には、登録部350は、入札テーブル312において、ウォッチリクエストに含まれるウォッチ商品IDに対応する商品IDのウォッチリストに、そのウォッチリクエストに含まれるユーザIDを追加する。
【0050】
また、登録部350は、情報取得部330により取得された入札リクエストに含まれる入札商品IDと、入札ユーザIDと、入札額と、に基づいて、入札テーブル312のウォッチリストの現在価格及び最高額入札者IDを更新する。具体的には、登録部350は、入札テーブル312において、入札商品IDに対応する商品IDの現在価格を入札リクエストに含まれる入札額に更新し、最高額入札者IDを入札リクエストに含まれる入札ユーザIDに更新する。
【0051】
図2に示したCPU3001は、
図3に示す登録部350として機能する。
【0052】
通知部360は、現在日時が、入札テーブル312に記録された予告日時に達した場合、その予告日時に達した商品のウォッチリストに登録されているユーザIDのユーザに対し、その商品の入札期限が近い旨の予告メッセージ60を通知する。
図8に、端末装置110の表示部119に表示された予告メッセージ60の一例を示す。
図8に示す予告メッセージは、予告日時に達した商品の名称と、その商品の申込ページを表示するためのアクションを指定するメッセージと、ページ移動ボタン61と、を含む。具体的には、予告メッセージ60において、商品の申込ページ50を表示するためのアクションとして、ページ移動ボタン61をクリックすることが指定されている。端末装置110のユーザが、入力部111を介してページ移動ボタン61をクリックすると、端末装置110は、送信リクエストを予告装置300へ送信する。
【0053】
図2に示したCPU3001は、LANカード3006と協働して、
図3に示す通知部360として機能する。
【0054】
提示部370は、情報取得部330により取得された送信リクエストに含まれる入札商品IDと、ユーザIDと、に基づいて、端末装置110に、申込ページ、または、申込ページの情報をまとめた期限リストページを提示する。
【0055】
例えば、提示部370は、入札テーブル312において、送信リクエストに含まれる入札商品IDに対応する商品IDの入札期限が、現在日時よりも後である場合、まとめ期間を決定する。ここで、まとめ期間について、
図9を用いて説明する。
図9では、入札テーブル312において、商品ID“S002”,“S00X”及び“S00Y”のウォッチリストに、ユーザID“U003”が登録されている例について説明する。
図9に示すように、商品ID“S002”,“S00X”及び“S00Y”の入札期限がそれぞれ、“2014/04/15 00:00”,“2014/04/15 00:05”及び“2014/04/15 00:15”である場合、各商品IDに対応する予告日時は、それぞれ入札期限から予告間隔30分だけ先行する“2014/04/14 23:30”,“2014/04/14 23:35”及び“2014/04/14 23:45”である。ここで、現在日時が“2014/04/14 23:30”に達し、ユーザID“U003”のユーザに対し、商品ID“S002”の入札期限が近づいている旨の予告メッセージが送信され、“2014/04/14 23:35”に、ユーザID“U003”のユーザが、その予告メッセージに含まれているページ移動ボタン61をクリックしたとする。この場合、提示部370は、まとめ期間として、入札商品IDの入札期限から第1時間長だけ先行する時点から、その入札期限から第2時間長だけ後行する時点までの期間を決定する。具体的には、提示部370は、商品ID“S002”の入札期限“2014/04/15 00:00”から第1時間長10分だけ先行する時点“2014/04/14 23:50”から、商品ID“S002”の入札期限“2014/04/15 00:00”から第2時間長10分だけ後行する時点“2014/04/15 00:10”までの期間を、まとめ期間として決定する。なお、第1時間長及び第2時間長は、ともに10分であるとして説明したが、これに限られない。
【0056】
そして、提示部370は、入札テーブル312のウォッチリストに、送信リクエストに含まれるユーザIDが登録された商品のうち、まとめ期間内に入札期限が到来する商品が、入札商品IDに係る商品のみである場合、端末装置110に、
図7に示すような、その商品の申込ページ50を提示する。
【0057】
また、提示部370は、まとめ期間内に入札期限が到来する商品が、入札商品IDに係る商品以外にも存在する場合、端末装置110に、
図10に示すような、期限リストページ70を提示する。
図10に示す期限リストページ70は、まとめ期間内に入札期限が到来する商品毎に、商品名、入札数、現在価格、残り時間を表す情報を含む期限リスト71を含む。また、期限リスト71に含まれる各商品名は、その商品の入札の申込ページ50のリンクに対応する。従って、端末装置110のユーザが、期限リスト71に含まれる商品名を選択すると、その商品の入札の申込ページ50が端末装置110の表示部119に提示される。
【0058】
例えば、
図9の例では、まとめ期間として決定された“2014/04/15 00:00”から“2014/04/15 00:10”までの間に、商品ID“S002”及び“S00X”の入札期限が到来する。従って、提示部370は、まとめ期間内に入札期限が到来する商品が、入札商品ID“S002”に係る商品以外にも存在すると判定し、端末装置110に、
図10に示すような、期限リストページ70を提示する。
【0059】
申込ページ50が端末装置110に提示された後、端末装置110は、入力部111を介して、申込ページ50においてユーザによる入札額の入力と、入札ボタン53の選択が行われると、その入札額と、そのユーザのユーザIDとを含む入札リクエストを予告装置300へ送信することで、入札の申込みを行う。
【0060】
次に、本実施形態に係る予告システム1の動作について説明する。
【0061】
まず、予告装置300が実行する登録処理について説明する。
図11は、登録処理のフローチャートの一例である。
図11に示す登録処理は、例えば、端末装置110からリクエストを受信したことを契機として開始される。
【0062】
まず、情報取得部330は、端末装置110から受信したリクエストがウォッチリクエストか否かを判定する(ステップS11)。
【0063】
情報取得部330は、端末装置110から受信したリクエストがウォッチリクエストであると判定した場合(ステップS11;Yes)、ウォッチリクエストに含まれるユーザIDと、ウォッチ商品IDと、を取得する(ステップS12)。
【0064】
次に、登録部350は、
図5の入札テーブル312に保存されている、ウォッチ商品IDに対応する商品IDのウォッチリスト(つまり、ウォッチ商品のウォッチリスト)に、取得したユーザIDを追加登録する(ステップS13)。その後、登録部350は、登録処理の実行を終了する。
【0065】
また、情報取得部330は、端末装置110から受信したリクエストがウォッチリクエストでないと判定した場合(ステップS11;No)、端末装置110から受信したリクエストが送信リクエストか否かを判定する(ステップS14)。端末装置110から受信したリクエストが送信リクエストでないと判定した場合(ステップS14;No)、登録部350は、登録処理の実行を終了する。
【0066】
情報取得部330は、端末装置110から受信したリクエストが送信リクエストであると判定した場合(ステップS14;Yes)、入札リクエストに含まれる入札ユーザIDと、入札商品IDと、入札額とを取得する(ステップS15)。
【0067】
次に、登録部350は、
図5の入札テーブル312に保存されている、入札商品IDに対応する商品IDの最高額入札者ID及び現在価格を、それぞれ入札ユーザID及び入札額に更新する(ステップS16)。その後、登録部350は、登録処理の実行を終了する。
【0068】
次に、予告装置300が実行する予告処理について説明する。
図12は、予告処理のフローチャートの一例である。
図12に示す予告処理は、例えば、予告装置300の電源が投入されたことを契機として開始される。
【0069】
まず、通知部360は、現在日時を、例えば、OS(Operating System)から取得した後に、
図5の入札テーブル312に記録された商品のうち、その商品の予告日時が現在日時に一致する商品(以下、予告必要商品と呼ぶ)が存在するか否かを判別する(ステップS21)。予告必要商品が存在しないと判定すると(ステップS21;No)、予告必要商品が存在すると判定するまで待機する。
【0070】
通知部360は、予告必要商品が存在すると判定すると(ステップS21;Yes)、予告メッセージを通知する(ステップS22)。
【0071】
具体的には、通知部360は、入札テーブル312において、予告必要商品の商品IDに対応づけられたウォッチリストに登録されている複数のユーザIDを宛先として、
図8に示すような予告メッセージを含んだ予告メールを送信する。
【0072】
その後、通知部360は、ステップS21及びS22の処理を繰り返し実行する。
【0073】
次に、予告装置300が実行する提示処理について説明する。
図13は、提示処理のフローチャートの一例である。
図13に示す提示処理は、例えば、端末装置110から送信リクエストを受信したことを契機として開始される。
【0074】
まず、情報取得部330は、端末装置110から受信した送信リクエストに含まれる入札商品IDとユーザIDとを取得する(ステップS31)。
【0075】
次に、提示部370は、入札テーブル312を参照し、情報取得部330により取得された入札商品IDに対応する商品IDの入札期限が、現在日時よりも後であるか否かを判定する(ステップS32)。
【0076】
提示部370は、入札商品IDに対応する商品IDの入札期限が、現在日時よりも後であると判定した場合(ステップS32;Yes)、その入札商品IDの商品の入札期限を予告するためのまとめ期間を決定する(ステップS33)。具体的には、提示部370は、まとめ期間として、入札商品IDの入札期限から第1時間長だけ先行する時点から、その入札期限から第2時間長だけ後行する時点までの期間を決定する。
【0077】
次に、提示部370は、入札テーブル312のウォッチリストに、送信リクエストに含まれるユーザIDが登録された商品のうち、決定されたまとめ期間内に入札期限が到来する商品が、複数あるか否かを判定する(ステップS34)。
【0078】
提示部370は、決定されたまとめ期間内に入札期限が到来する商品が複数あると判定した場合(ステップS34;Yes)、提示部370は、その複数の商品の申込ページ50へのリンクを含む期限リストページ70を端末装置110に提示する(ステップS35)。そして、提示部370は、提示処理を終了する。
【0079】
また、提示部370は、決定されたまとめ期間内に入札期限が到来する商品が複数ないと判定した場合、すなわち、まとめ期間内に入札期限が到来する商品は、入札商品IDに係る商品のみである場合(ステップS34;No)、提示部370は、その入札商品IDに係る商品の申込ページ50を端末装置110に提示する(ステップS36)。そして、提示部370は、提示処理を終了する。
【0080】
提示部370は、入札商品IDに対応する商品IDの入札期限が、現在日時よりも後でないと判定した場合にも(ステップS32;No)、提示部370は、その入札商品IDに係る商品の申込ページ50を端末装置110に提示する(ステップS36)。この場合、入札期限は既に経過しており、この入札商品IDに係る商品のオークションは終了している。従って、端末装置110のユーザは、申込ページ50に含まれる商品の情報から、落札者や落札時の価格を確認することができる。
【0081】
これらの構成によれば、予告装置300は、申込期限を予告されたユーザが当該期限までに当該予告に指定されたアクションを行うと、当該予告に係る取引を含むまとめ期間内に期限が到来する取引が、当該予告に係る取引のみである場合、当該取引の申込ページ50を端末装置110に提示する。また、当該予告に係る取引を含むまとめ期間内に期限が到来する取引が、当該予告に係る取引以外にもある場合、当該取引の申込ページ50の情報をまとめた期限リストページ70を提示する。このため、申込期限が近い複数の取引があった場合に、ユーザにはそれらの取引の申込ページ50の情報がまとめて提示されるため、ユーザは申込忘れを従来よりも確実に防止することができる。
【0082】
(実施の形態2)
実施の形態1では、予告装置300は、予め設定された予告間隔を用いて、各取引の予告メッセージを通知する予告日時を決定し、予め設定された第1時間長及び第2時間長を用いて、予告に係る取引の期限を含むまとめ期間を決定する例について説明した。しかし、第1時間長、第2時間長、及び予告間隔としては、予め設定された値ではなく、動的に変化する値が用いられてもよい。本実施の形態2では、まとめ期間内取引の各取引に対して行ったアクションに基づいて、通知された予告に対する反応度を算出し、算出された反応度が向上するように、予告装置300が第1時間長及び第2時間長、予告間隔を更新する例について説明する。本実施の形態2に係る予告装置300において、実施の形態1に係る予告装置300と同様の構成及び機能については同様の符号を付し、その詳細な説明を省略する。
【0083】
まず、本実施の形態2に係る予告装置300の有する機能について説明する。
図14に示すように、実施形態2に係る予告装置300は、
図3に示す実施の形態1に係る各部の他、算出部380、更新部390としてさらに機能する。
【0084】
また、本実施の形態2に係る情報記憶部310は、第1時間長、第2時間長、及び予告間隔(以下、総称して設定パラメタと呼ぶ)が保存される、
図15に示すようなパラメタテーブル313を記憶している。パラメタテーブル313には、設定パラメタと、設定パラメタの更新に用いられる情報として、リスト応答時間、反応度が対応付けられたレコードが保存されている。パラメタテーブル313に格納された設定パラメタは、実施の形態1において説明した第1時間長、第2時間長、及び予告間隔として用いられる。
【0085】
リスト応答時間は、予告メールの送信時点から、ユーザがその予告メールに指定されたアクションを実行し、その予告に係る商品の入札期限までに、予告装置300から提示された期限リストページ70から申込ページ50にアクセスした場合におけるアクセス時点までの時間をいう。なお、ユーザが、期限リストページ70から、複数の申込ページ50へアクセスした場合、リスト応答時間は、予告メールの送信時点から、各申込ページ50へのアクセス時点までの時間の平均として算出される。
【0086】
反応度は、ユーザが予告を通知されてから、特定のアクションを実行するまでの時間の短さを表す度合である。本実施の形態2では、当該特定のアクションは、その予告に係る商品の入札期限までに、予告装置300から提示された期限リストページ70から申込ページ50にアクセスすることである。従って、反応度は、リスト応答期間が短いほど、高くなるように算出される。
【0087】
さらに、情報記憶部310は、リスト応答時間の算出に用いられるログが保存される、
図16に示すようなログテーブル314を記憶している。ログテーブル314には、ログの保存日時と、ログの内容と、ログの内容に関連したユーザID及び商品IDと、が対応付けられたレコードが複数保存される。
【0088】
算出部380は、ユーザが、まとめ期間内の取引に対して行ったアクションに基づいて、通知された予告に対する反応度を算出する。例えば、当該アクションが、予告が通知された後に、ユーザがまとめ期間内の各取引の申込ページ50に期限リストページ70からアクセスすることである場合、算出部380は、予告が通知された時点から、まとめ期間内の各取引の申込ページ50に期限リストページ70からアクセスした時点までの期間をリスト応答時間として求める。そして、算出部380は、そのリスト応答時間に負の相関をするように反応度を算出する。すなわち、算出部380は、ユーザが予告メールを受信してから、期限リストページ70を介して申込ページ50にアクセスするまでの時間が短い程、反応度を高く算出する。算出部380が反応度を算出するために用いる適切な算出式は、当業者が設計により定めることができる。
【0089】
更新部390は、算出部380により算出された反応度が向上するように、パラメタテーブル313に記録された第1時間長、第2時間長、及び予告間隔を更新する。例えば、更新部390は、第1時間長、第2時間長、及び予告間隔を、パラメタテーブル313に記録されている値から一時的に変化させ、その結果、算出部380により算出された反応度が向上した場合、その一時的に変化させた第1時間長、第2時間長、及び予告間隔の値を更新後の値として、パラメタテーブル313の、第1時間長、第2時間長、及び予告間隔にそれぞれ保存する。
【0090】
次に、予告装置300が実行するパラメタ更新処理について説明する。
図17は、パラメタ更新処理のフローチャートの一例である。
図17に示すパラメタ更新処理は、例えば、予告装置300の電源が投入されたことを契機として開始される。
【0091】
まず、更新部390は、現在日時を取得する。次に、更新部390は、現在日時が設定パラメタの仮変更日時よりも後の日時であるか否かに基づいて、仮変更日時が到来したか否かを判別する(ステップS41)。
【0092】
このとき、仮変更日時が到来したと更新部390が判定すると(ステップS41;Yes)、更新部390は、設定パラメタの値を仮変更した値を決定する仮変更パラメタ値決定処理を実行する(ステップS42)。このとき、更新部390は、パラメタテーブル313に記録された現在の設定パラメタの値を所定値だけ増加させるか、所定値だけ減少させるか、をランダムに決定し、決定した値により、仮変更パラメタ値を決定する。
【0093】
次に、更新部390は、パラメタテーブル313に記録された設定パラメタの値を、仮変更パラメタ値に更新する(ステップS43)。また、更新部390は、パラメタテーブル313に記録された仮変更前の設定パラメタ、反応度の値を、それぞれ仮変更前パラメタ、仮変更前反応度として記憶する。そして、更新部390は、ステップS41に処理を戻す。
【0094】
また、仮変更日時が到来していないと更新部390が判定すると(ステップS41;No)、更新部390は、現在時刻が検証日時よりも後であるか否かに基づいて、検証日時が到来したか否かを判定する(ステップS44)。検証日時が到来していないと判定した場合(ステップS44;No)、更新部390は、ステップS41に処理を戻す。
【0095】
検証日時が到来したと判定した場合(ステップS44;Yes)、算出部380は、リスト応答時間を算出する(ステップS45)。
【0096】
ここで、リスト応答時間の算出方法の一例を説明する。算出部380は、
図16のログテーブル314を参照し、対応する内容が“期限リストページからの申込ページアクセス”であるユーザのユーザID及び商品IDの組合せと、その保存日時とを特定する。そして、算出部380は、特定したユーザID及び商品IDの組合せにおいて、内容が“期限リストページ送信”に対応する保存日時を特定する。そして、算出部380は、特定された2つの保存日時から、リスト応答時間を算出する。算出部380は、“期限リストページからの申込ページアクセス”であるユーザのユーザID及び商品IDの組合せを複数特定した場合には、各組合せから算出されたリスト応答時間の平均値を反応度の算出に用いるリスト応答時間とする。そして、算出部380は、算出したリスト応答時間をパラメタテーブル313に格納する。
【0097】
次に、算出部380は、算出したリスト応答時間に負の相関をするように反応度を算出する(ステップS46)。例えば、算出部380は、リスト応答期間がT[分]である場合、反応度R=1/Tとして算出する。そして、算出部380は、算出した反応度をパラメタテーブル313に格納する。
【0098】
次に、更新部390は、ステップS46において算出された反応度が、仮変更前反応度よりも大きいか否かに基づいて、反応度が向上したか否かを判定する(ステップS47)。このとき、更新部390は、反応度が向上したと判定すると(ステップS47;Yes)、
図15のパラメタテーブル313の設定パラメタの値を仮変更パラメタ値のままとし、ステップS41に処理を戻す。
【0099】
また、反応度が向上しなかったと判定された場合(ステップS47;No)、
図15のパラメタテーブル313の設定パラメタの値を、仮変更パラメタ値から、仮変更前パラメタの値に変更し(ステップS48)、ステップS41に処理を戻す。
【0100】
これらの構成によれば、予告装置300は、期限を予告されたユーザが当該期限までに行ったアクションに基づいて算出される反応度が向上するように、第1時間長、第2時間長を更新する。このため、ユーザの反応度が高くなるようにまとめ期間を設定することができ、短い期間内に複数の入札期限が存在している場合であっても、ユーザは、各入札の申し込みを忘れることを確実に防止できる。
【0101】
また、予告装置300は、期限を予告されたユーザが当該期限までに行ったアクションに基づいて算出される反応度が向上するように、予告間隔を更新する。このためユーザの反応度が高くなるような適切な時期に予告を行うことができ、予告から期限までの猶予時間が長すぎるためにユーザが入札の申し込みを忘れたり、猶予時間が短すぎるために入札が期限に間に合わなかったりすることを従来よりも確実に防止できる。
【0102】
また、予告装置300は、第1時間長、第2時間長、及び予告間隔を一時的に変化させることにより反応度が向上すれば、当該第1時間長、第2時間長、及び予告間隔を一時的に変化させた値で更新する。このため、より適切なまとめ期間及び予告間隔を設定することができる。
【0103】
また、予告装置300は、リスト応答時間と負の相関を有する反応度を向上させるように、第1時間長、第2時間長、及び予告間隔を更新する。このため、リスト応答時間が従来よりも減少するので、予告を受けてから申込ページ50へユーザがアクセスし忘れることを従来よりも確実に防止できる。
【0104】
(実施の形態3)
実施の形態2では、第1時間長、第2時間長、及び予告間隔を、リスト応答時間に応じて更新する例について説明した。本実施の形態3では、別の例として、予告装置300が、期限リストページ70から申込ページ50へのアクセスの数に応じて、第1時間長、第2時間長、及び予告間隔を更新する例について説明する。本実施の形態3に係る予告装置300において、実施の形態2に係る予告装置300と同様の構成及び機能については同様の符号を付し、その詳細な説明を省略する。
【0105】
本実施の形態3において、算出部380は、
図17に示す実施の形態2のパラメタ更新処理のステップS45の代わりに、予告が通知された後に、ユーザが期限リストページ70から申込ページ50へのアクセスした数を算出する。例えば、算出部380は、
図16のログテーブル314を参照し、現在の設定パラメタが適用されている期間において、対応する内容が“期限リストページからの申込ページアクセス”であるユーザのユーザID及び商品IDの組合せの数(アクセス数)を特定する。また、算出部380は、
図5の入札テーブル312を参照し、現在の設定パラメタが適用されている期間に入札期限が到来する商品の総数を特定する。そして、算出部380は、特定された商品の総数に対するアクセス数の割合を算出する。
【0106】
そして、算出部380は、
図17に示す実施の形態2のパラメタ更新処理のステップS46の代わりに、算出されたアクセス数の割合に正の相関をするように反応度を算出する。すなわち、算出部380は、ユーザが期限リストページ70から申込ページ50へアクセスした数が多い程、反応度を高く算出する。算出部380が反応度を算出するために用いる適切な算出式は、当業者が設計により定めることができる。
【0107】
これらの構成によれば、予告装置300は、期限リストページ70から申込ページ50へアクセスした数と正の相関を有した反応度を向上させるように、第1時間長、第2時間長、及び予告間隔を更新する。このため、短い期間内に複数の入札期限が存在している場合であっても、ユーザが各入札の申し込みを忘れることを防止しつつ、申込ページ50へのアクセス数の増加を図り、より活発に取引を行わせることができる。
【0108】
(実施の形態4)
本実施の形態4では、予告装置300が、期限リストページ70からアクセスした申込ページ50からの入札申込の数に応じて、第1時間長、第2時間長、及び予告間隔を更新する例について説明する。本実施の形態4に係る予告装置300において、実施の形態2に係る予告装置300と同様の構成及び機能については同様の符号を付し、その詳細な説明を省略する。
【0109】
本実施の形態4において、算出部380は、
図17に示す実施の形態2のパラメタ更新処理のステップS45の代わりに、予告が通知された後に、ユーザが期限リストページ70からアクセスした申込ページ50からの入札申込への数を算出する。例えば、算出部380は、
図16のログテーブル314を参照し、現在の設定パラメタが適用されている期間において、対応する内容が“期限リストページからの申込ページアクセス”であるユーザのユーザID及び商品IDの組合せを特定する。また、算出部380は、特定したユーザID及び商品IDの組合せのうち、対応する内容が“入札リクエスト受信”が記録されているユーザID及び商品IDの組合せの数(入札申込数)を特定する。また、算出部380は、
図5の入札テーブル312を参照し、現在の設定パラメタが適用されている期間に入札期限が到来する商品の総数を特定する。そして、算出部380は、特定された商品の総数に対する入札申込数の割合を算出する。
【0110】
そして、算出部380は、
図17に示す実施の形態2のパラメタ更新処理のステップS46の代わりに、算出された入札申込数の割合に正の相関をするように反応度を算出する。すなわち、算出部380は、ユーザが期限リストページ70からアクセスした申込ページ50からの入札申込の数が多い程、反応度を高く算出する。算出部380が反応度を算出するために用いる適切な算出式は、当業者が設計により定めることができる。
【0111】
これらの構成によれば、予告装置300は、期限リストページ70から申込ページ50へアクセスした数と正の相関を有した反応度を向上させるように、第1時間長、第2時間長、及び予告間隔を更新する。このため、短い期間内に複数の入札期限が存在している場合であっても、ユーザが各入札の申し込みを忘れることを防止しつつ、入札申込数の増加を図り、より活発に取引を行わせることができる。
【0112】
(実施の形態5)
本実施の形態1では、予告装置300が、端末装置110に予告メールを送信する例について説明したが、メールサーバを介して、端末装置110に入札期限の予告を通知してもよい。本実施の形態5では、予告装置300が、メールサーバを介して、端末装置110に予告を通知する例について説明する。本実施の形態5に係る予告装置300において、実施の形態1に係る予告装置300と同様の構成及び機能については同様の符号を付し、その詳細な説明を省略する。
【0113】
実施の形態5に係る予告システム1は、
図18に示すような、端末装置110及び120と、端末装置110及び120と無線通信可能な基地局200と、基地局200とコンピュータ通信網10(以下単に、通信網10という)を介して通信可能に接続された予告装置300及びメールサーバ400と、で構成される。
【0114】
メールサーバ400は、例えば、サーバ機で構成され、実施の形態1の
図2に示す予告装置300と同様のハードウェアから構成されている。また、メールサーバ400は、
図19に示すように、予告装置300から受信した予告メール予約テーブル411を記憶している。予告メール予約テーブル411には、予告メールを送るべき商品毎に、商品IDと、予告日時と、送信先であるユーザIDとが対応付けて格納されている。メールサーバ400は、現在日時が、予告メール予約テーブル411に格納された予告日時に一致すると、その予告日時に対応するユーザIDを宛先として、その予告日時に対応する商品IDの入札期限が近いことを表す予告メールを送信する。
【0115】
また、本実施の形態5に係る予告装置300の通知部360は、
図12に示す予告処理の代わりに、
図20に一例として示す予約登録処理を実行する。
図20に示す予約登録処理は、例えば、端末装置110からウォッチリクエストを受信したことを契機として開始される。
【0116】
まず、情報取得部330は、ウォッチリクエストに含まれるユーザIDと、ウォッチ商品IDと、を取得する(ステップS51)。
【0117】
次に、通知部360は、
図5の入札テーブル312を参照して、ウォッチリクエストに含まれるユーザIDに対応する商品IDであって、対応する入札期限がウォッチ商品IDに対応する入札期限に先行し、その商品IDに対して定められたまとめ期間内に、ウォッチ商品IDに対応する予告日時が含まれる商品IDがあるか否かを判定する(ステップS52)。
【0118】
通知部360は、まとめ期間内に、ウォッチ商品IDに対応する予告日時が含まれる商品IDがあると判定した場合(ステップS52;Yes)、ウォッチリクエストに含まれるユーザIDのユーザに対し、ウォッチ商品IDの商品の入札期限の予告通知を省略する旨のメッセージを通知する(ステップS53)。そして、通知部360は、予約登録処理を終了する。
【0119】
また、通知部360は、まとめ期間内に、ウォッチ商品IDに対応する予告日時が含まれる商品IDがないと判定した場合(ステップS52;No)、メールサーバ400の予告メール予約テーブル411に、ウォッチ商品IDと、その予告日時と、ウォッチリクエストに含まれるユーザIDとを登録することにより、そのユーザIDのユーザに対し、ウォッチ商品IDの商品の入札期限の予告通知が記載されたメールを送信すべき旨の予約登録を行う(ステップS54)。そして、通知部360は、予約登録処理を終了する。
【0120】
これらの構成によれば、予告装置300は、新たにウォッチ商品が追加された場合に、すでにメールサーバ400に登録された予告通知の予約をキャンセルすることなく、予告メールの送付数を減らすことができる。
【0121】
以上、本発明の実施の形態1〜5について説明したが、本発明は実施の形態1〜5によって限定されるものではない。
【0122】
例えば、提示部370は、期限リストページ70を提示する代わりに、まとめ期間内に入札期限が到来する商品の各々の申込ページ50をすべて、互いに異なるブラウザウィンドウもしくはブラウザ内の互いに異なるタブを提示してもよい。
【0123】
また、上記の実施の形態1〜5において、期限リスト71には、まとめ期間内に入札期限が到来する商品が含まれているが、期限リスト71に含まれる商品はこれに限られず、まとめ期間内に入札期限が到来する商品が含まれていてもよい。例えば、期限リスト71には、入札テーブル312において、送信リクエストに含まれるユーザIDが登録されているウォッチリストの商品全てを含んでもよい。
【0124】
また、上記の実施の形態1〜5では、電子商取引について説明したが、これに限定される訳ではなく、取引は、商取引でなくともよく、無償の借り受けや貸し渡しであってもよい。また、取引は、電子取引でなくともよく、取引の一部又は全部が、コンピュータネットワークによる電子的な情報通信によって行われなくともよい。
【0125】
また、上記の実施の形態1〜5では、申込期限が設定された取引として、オークション取引を例に挙げて説明したが、これに限定される訳では無く、タイムセールや特売期間の設定された特売品の取引であってもよい。
【0126】
また、上記の実施の形態1〜5では、取引の申し込みとして、オークションに対する入札を例に挙げて説明したが、これに限定される訳では無く、商品の購入申し込みや、レンタルの申し込みであってもよい。
【0127】
また、上記の実施の形態1〜5では、取引の対象とされるものは、商品であるとして説明したが、役務であってもよく、取引の対象とされるものであればどのようなものでも良い。商品とは、商取引の目的足りうべき物を含み、動産に限定されるのではなく、不動産も含むが、これらに限定される訳では無い。役務とは、他人のために行う労務又は便益であって、独立して商取引の目的足りうべきものを含むが、これらに限定される訳では無い。
【0128】
また、上記の実施の形態1〜5は、互いに組み合わせることができる。実施の形態1から5のいずれかに係る機能を実現するための構成を備えた予告装置300として提供できることはもとより、複数の装置で構成されるシステムであって、実施の形態1から5のいずれかに係る機能を実現するための構成をシステム全体として備えたシステムとして提供することもできる。
【0129】
なお、上記実施の形態1〜5において、予告装置300が実行するプログラムは、フレキシブルディスク、CD−ROM(Compact Disk Read-Only Memory)、DVD(Digital Versatile Disk)、MO(Magneto-Optical Disk)等のコンピュータ読み取り可能な記録媒体に格納されて配布されてもよい。そして、そのプログラムがパーソナルコンピュータ等の情報処理装置にインストールされることにより、上述の処理を実行する予告装置300が構成されてもよい。
【0130】
また、プログラムは、インターネット等の通信ネットワーク上の所定のサーバ装置が有するディスク装置等に格納されてもよい。そして、プログラムは、例えば、搬送波に重畳されて、ダウンロードされてもよい。
【0131】
また、上述の機能を、OS(Operating System)が分担して実現する場合又はOSとアプリケーションとの協働により実現する場合、OSの機能を実現する部分以外のプログラムのみが、記録媒体に格納されて配布されてもよく、また、ダウンロードされてもよい。
【0132】
本発明は、本発明の広義の精神と範囲に逸脱することなく、様々な実施の形態及び変形が可能とされるものである。また、上述した実施形態は、本発明を説明するためのものであり、本発明の範囲を限定するものではない。つまり、本発明の範囲は、実施の形態ではなく、特許請求の範囲によって示される。そして、特許請求の範囲内及びそれと同等の発明の意義の範囲内で施される様々な変形が、本発明の範囲内とみなされる。
予告日時取得部(320)は、ユーザがウォッチする複数の取引の各取引に対応付けられる予告日時であって、当該各取引の期限に設定された間隔だけ先行する予告日時を取得する。通知部(360)は、各取引に対応付けられる予告日時が到来した後、各取引の期限の予告を、ユーザに通知する。提示部(370)は、予告が通知されたユーザが、予告に係る取引の期限までに、予告に指定されたアクションを行うと、複数の取引のうち、予告に係る取引の前記期限を含むまとめ期間を定める。そして、提示部(370)は、まとめ期間内に期限が到来するまとめ期間内取引が、予告に係る取引のみであれば、予告に係る取引の申込ページをユーザに提示する。また、提示部(370)は、まとめ期間内取引が、複数あれば、まとめ期間内取引の各々の申込ページの情報をまとめて、ユーザに提示する。