JP2002304500A - スケジュール管理方法および装置 - Google Patents

Abstract

(57)【要約】 【課題】 電子スケジュール帳に情報を入力する際、利
便性と再利用性に改善の余地があった。 【解決手段】 スケジュール通信システム１０はクライ
アント側のスケジュール通信装置１４とサーバ側のスケ
ジュール通信装置３８を有する。サーバ側のスケジュー
ル通信装置３８は、ユーザにスケジュールと、ユーザの
個人情報に基づく広告を送信する。クライアント側のス
ケジュール通信装置１４は、スケジュールと広告を受信
する。広告はスケジュールの中に組み込まれ、ユーザに
告知される。ユーザはスケジュールの書込にアイコンを
利用する。ユーザが利用したアイコンの組合せからその
ユーザのタイプや行動を推定し、広告が選定される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、ユーザを管理す
る技術に関する。

【０００２】

【従来の技術】個人のツールとして、またはグループウ
エアとしてスケジュールを管理するプログラムやWｅｂ
上のサービスが広がりつつある。個人側に立てば、より
利便性の高いシステムが望まれ、一方、サービス提供側
のひとつの目的はユーザの個人情報の獲得にある。

【０００３】

【発明が解決しようとする課題】本発明はそうした観点
からなされたものである。

【０００４】

【課題を解決するための手段】本発明のある態様は、ユ
ーザ管理方法に関する。この方法は、ユーザが電子的な
スケジュール帳に入力すべき内容に対応して設けられた
アイコンのうち、ユーザがスケジュール帳に実際に書き
込んだアイコンの組合せを検出する工程と、検出された
アイコンの組合せをもとにユーザの類型または行動を判
定する工程とを含む。

【０００５】本発明の別の態様は、ユーザ管理装置に関
する。この装置は、ユーザが電子的なスケジュール帳に
入力すべき内容に対応して設けられたアイコンの組合せ
とそのユーザの類型または行動を対応づけて保持する類
型テーブルと、ユーザが現実にスケジュール帳に書き込
んだアイコンを検出するアイコン検出部と、検出された
アイコンの組合せを類型テーブルに照合してユーザの類
型または行動を判定する判定部とを含む。

【０００６】この装置は、前記類型または行動と所定の
情報を対応づけて保持する情報テーブルと、ユーザの類
型または行動をその情報テーブルに照合してそのユーザ
に紹介すべき情報を選定する選定部とをさらに含んでも
よい。また、スケジュール帳に時系列的に広告を配信す
る配信部をさらに備えてもよい。配信部は広告にそれを
表示すべき目的時刻を付して配信してもよい。

【０００７】本発明のさらに別の態様もユーザ管理装置
に関する。この装置は、ユーザが電子的なスケジュール
帳に入力すべき内容に対応して設けられたアイコンを表
示する表示制御部と、ユーザが現実にスケジュール帳に
書き込んだアイコンを検出する検出部と、検出されたア
イコンをユーザ管理機能のあるサーバへ送信する送信部
とを含む。サーバから広告を受信する受信部をさらに含
んでもよい。

【０００８】また、受信した広告に付された目的時刻を
検出する日時検出部と、スケジュール帳の表示領域のう
ち、検出された目的時刻に当たる部分にその広告を表示
する広告表示部とをさらに含んでもよい。

【０００９】本発明のある態様は、ネットワークシステ
ムにおけるスケジュールの通信方法であって、前記ネッ
トワークを介してユーザの前記スケジュールを受信する
ステップと、前記ネットワークを介して前記ユーザの個
人情報に基づいて選択された広告を受信するステップ
と、前記広告の目的時刻を判定するステップと、前記ス
ケジュールまたはその関連欄の中に前記目的時刻に沿っ
て前記広告を組み込んで前記ユーザに告知するステップ
とを含む。前記個人情報は時間の経過とともにその内容
が変化する性質のものであり、その内容の変化が考慮さ
れた形にて前記広告が前記スケジュールの中に組み込ま
れる。前記個人情報はユーザの生活の習慣や健康に関連
するものであり、前記広告はその生活や健康の傾向を示
唆する情報、またはそれらに対するガイダンス情報を含
んでもよい。

【００１０】「ネットワーク」は有線、無線を問わず、
なんらかのデータのやりとりが可能な伝送手段を含む。
「スケジュール」とは、ユーザの個人的な予定など時間
軸をベースに組み立てられる個別情報全般をいう。

【００１１】本発明の別の態様は、ネットワークシステ
ムにおけるスケジュールの通信方法であって、前記ネッ
トワークを介してユーザに前記スケジュールを送信する
ステップと、前記ユーザの個人情報に基づいて広告を選
択するステップと、前記選択された広告に、当該広告を
前記スケジュールの中に組み込むための目的時刻を付加
して前記ユーザに送信するステップとを含む。

【００１２】本発明のさらに別の態様は、サーバとユー
ザ側であるクライアントを含むネットワークシステムに
おけるスケジュールの通信方法であって、前記サーバが
前記ユーザにスケジュールを送信するステップと、前記
ユーザ側にて前記スケジュールを受信するステップと、
前記サーバが前記ユーザの個人情報に基づいて広告を選
択するステップと、前記サーバが前記選択した広告を前
記ユーザに送信するステップと、前記ユーザ側にて前記
広告の目的時刻を判定するステップと、前記ユーザ側に
て前記スケジュールの中に前記目的時刻に沿って前記広
告を組み込んで前記ユーザに告知するステップとを含
む。

【００１３】本発明のさらに別の態様は、ネットワーク
システムにおけるスケジュールの通信装置であって、前
記ネットワークを介してユーザの前記スケジュールを取
得するユニットと、前記ネットワークを介して前記ユー
ザの個人情報に基づいて選択された広告を取得するユニ
ットと、前記広告の目的時刻を判定するユニットと、前
記スケジュールの中に前記目的時刻に沿って前記広告を
組み込んで前記ユーザに告知するための告知制御ユニッ
トとを含む。

【００１４】本発明のさらに別の態様は、サーバ側シス
テムとユーザ側であるクライアントを含むネットワーク
システムにおけるスケジュールの通信システムであっ
て、前記サーバ側システムは、前記ユーザに前記スケジ
ュールを送信するユニットと、前記ユーザの個人情報に
基づいて広告を選択するユニットと、前記選択した広告
を前記ユーザに送信するユニットとを含む。前記クライ
アントは、前記スケジュールを受信するユニットと、前
記広告を受信するユニットと、前記広告の目的時刻を判
定するユニットと、前記スケジュールの中に前記目的時
刻に沿って前記広告を組み込んで前記ユーザに告知する
ための告知制御ユニットとを含む。

【００１５】前記サーバ側システムは、前記クライアン
トとの通信をインターネットにて行うフロントサーバで
あるＷＷＷサーバと、前記クライアントとの通信の内容
に応じて前記スケジュールおよび前記広告を抽出して前
記ＷＷＷサーバに引き渡す広告サーバとを含んでもよ
い。

【００１６】なお、以上の構成要素の任意の組合せや、
方法、システム、装置、コンピュータプログラム、記録
媒体の間で表現を置換したり、表現を組み合わせたもの
もまた、本発明の態様として有効である。

【００１７】

【発明の実施の形態】以下、実施の形態の基本構成は、
本出願人がさきにＰＣＴ／ＪＰ００／０６０７２にて提
案しているものであり、これを［基礎技術］と題して図
１から図３０を用いて説明する。その後、［応用技術］
と題して本発明に特徴的な技術事項を説明する。

【００１８】［基礎技術］図１は、実施の形態に係るス
ケジュール通信システムの構成を示す。このシステムで
はサーバ側がユーザのスケジュールを管理している。ユ
ーザは自分のスケジュールを知るためにサーバ側にアク
セスする。その際、サーバ側はユーザに適した広告また
は企業の求人情報をスケジュールに組込可能な形で提供
する。

【００１９】スケジュール通信システム１０は、サーバ
側システム３０とユーザ側クライアントシステムである
ＰＣ（パーソナルコンピュータ）１２、および企業サー
バ５２を含む。ただし、クライアントシステムはＰＣ１
２である必要はなく、たとえば携帯電話１６その他任意
の情報端末であってよい。

【００２０】サーバ側システム３０は主に、ユーザにス
ケジュールを送信する機能と、ユーザの嗜好に沿う広告
を選択する機能と、選択した広告をユーザに送信する機
能とを含む。サーバ側システム３０はさらに、ユーザに
送信すべき求人広告を選択する機能と、選択した求人情
報をユーザに送信する機能を含む。一方クライアント
は、送信されたスケジュールを受信する機能と、送信さ
れた広告および求人情報を受信する機能と、それら広告
や求人情報の目的時刻を判定する機能と、送信されたス
ケジュールの中に目的時刻に沿って広告を組み込んでユ
ーザに告知する機能と、同じく送信されたスケジュール
と送信された求人情報をその目的時刻によって関連づけ
てユーザに告知する機能とを含む。ここで目的時刻と
は、たとえば広告の対象となるイベントの日時や求人情
報に含まれる勤務の日時等、広告や求人情報に何らかの
関連を有する時刻をいう。

【００２１】クライアントであるＰＣ１２は、実施の形
態に係るスケジュール通信装置１４を含む。スケジュー
ル通信装置１４は主にＰＣ１２のＣＰＵとメモリにロー
ドされたプログラムによって実現される。ただし、それ
以外の任意のハードウェアおよびソフトウェアの組合せ
によってこの装置を構成することも可能であり、その設
計自由度の高さは当業者には容易に理解されるところで
ある。スケジュール通信装置１４をソフトウェアモジュ
ール群として構成する場合、このプログラムをフロッピ
ー（登録商標）ディスク１８等の記録媒体によってＰＣ
１２へロードすることができる。

【００２２】サーバ側システム３０は、メインユニット
３２とユーザ情報データベース４０と広告データベース
５０をもつ。メインユニット３２は、クライアントとの
通信をインターネットにて行うフロントサーバであるＷ
ＷＷサーバ３４とクライアントとの通信の内容に応じて
スケジュール、広告および求人情報をユーザ情報データ
ベース４０から抽出してＷＷＷサーバ３４に引き渡す広
告サーバ３６を含む。

【００２３】広告サーバ３６は実施の形態に係るサーバ
側のスケジュール通信装置３８を内蔵する。ただしサー
バ側のスケジュール通信装置３８はその一部または全部
がＷＷＷサーバ３４の側に内蔵されてもよく、その設計
の自由度も高い。

【００２４】ユーザ情報データベース４０はユーザのス
ケジュールを保持するスケジュールデータベース４２と
ユーザの個人情報を保持する個人情報データベース４４
を含む。広告データベース５０は企業の広告を保持する
もので、その広告はたとえば企業サーバ５２からメイン
ユニット３２を経由して格納される。ただし、広告の格
納はオフライン処理で行われてもよい。企業サーバ５２
は、広告をメインユニット３２へ送付するサーバ機能の
他、クライアントから広告の詳細情報が問い合わされた
ときにアクセスされる企業のホームページとしての機能
も有する。

【００２５】以上の構成において、サーバとクライアン
トの通信の主体はユーザのスケジュールであるが、この
システムではそのスケジュールの時間を軸として広告や
求人情報がスケジュールの中に組み込まれる形でユーザ
に告知される。また、あらかじめ広告とユーザのマッチ
ングおよび求人情報とユーザのマッチングが検証され、
最も宣伝効果が高いと予想されるユーザに広告が送ら
れ、かつ企業が最も採用したいと思われるユーザに効果
的に求人広告が流される。またユーザにしても、自分が
一番興味を持ちそうな広告が自然に流され、自分が働い
てみたい条件の求人情報を効率的に得ることができる。

【００２６】図２は、クライアント側のスケジュール通
信装置１４の構成を示す。ユーザ識別情報入力部１００
は、スケジュールにアクセスする際のユーザの確認をす
るための情報を入力する。スケジュール登録部１０２
は、ユーザが自らスケジュールを登録または更新する際
に用いる。スケジュール取得部１０４は、ユーザが自ら
スケジュールを確認する際に利用する。スケジュール取
得部１０４によって取得されたスケジュールは、目的時
刻判定部１１０へ送られる。

【００２７】目的時刻判定部１１０は、取得されたスケ
ジュールの目的時刻を判定する。たとえばスケジュール
が、「１月１日から一週間旅行に出る」であれば、目的
時刻は「１月１日」または「１月１日から一週間」のよ
うに判定される。スケジュールおよびその目的時刻は告
知制御部１２０へ送られる。

【００２８】告知制御部１２０は、スケジュールの内容
とその目的時刻をユーザに告知するための各種制御を行
う。たとえばユーザのスケジュールが、１０月１０日に
コンサートに行くことであれば、告知制御部はまずディ
スプレイに１０月１０日前後のカレンダーを表示させ、
かつ１０月１０日の日付部分に「コンサート」と表示さ
せる。

【００２９】広告取得部１０６は、サーバ側システム３
０から送られてくる企業の広告を取得する。求人情報取
得部１０８は、同様に求人情報を取得する。求人情報は
あらかじめ選抜されたユーザのみが受信可能としても良
い。広告および求人情報はともに目的時刻判定部１１０
へ送られ、これらの目的時刻が判定される。判定の結果
は告知制御部１２０へ送られる。告知制御部１２０で
は、たとえば広告の内容が「××デパート、１１月１０
日、全品２０％オフ」であれば、１１月１０日前後のカ
レンダーを表示させ、かつその１１月１０日の日付部分
に例えば「××デパート、２０％オフ」と表示させる。
同様に、求人情報が「１２月１０日工事現場アルバイ
ト」であれば、告知制御部１２０はまず１２月１０日前
後のカレンダーを表示させ、かつ１２月１０日の日付部
分に「工事現場アルバイト募集中」などと表示させる。

【００３０】関連情報アクセス部１６０は、表示された
広告や求人情報に興味を持つユーザがその詳細情報を知
りたいときに利用する。たとえば、告知制御部１２０に
よって表示された広告や求人情報の下線付き情報をクリ
ックすると、関連情報アクセス部１６０はこのアクショ
ンを検出し、詳細情報へアクセスする。

【００３１】タイマー１５０は、スケジュール、広告、
求人情報の取得を所定の時刻や一定間隔で行うために利
用される。たとえば、スケジュール通信装置１４は通常
オフラインで利用され、５分おきにダイヤルアップして
広告を取得するといった制御が可能である。タイマー１
５０は、ソフトウェアによるポーリングやリアルタイム
クロックＩＣによって構成できる。リアルタイムクロッ
クＩＣが利用される場合、その出力を告知制御部１２０
におけるカレンダー表示に利用することができる。

【００３２】求人応答部１１４は、ユーザが求人に応募
するときに利用する。実際には、求人情報が表示された
ときに「応募する」というボタンも併せて表示し、ユー
ザがそのボタンをクリックしたとき求人応答部１１４が
その旨をサーバ側システム３０へ伝える。

【００３３】個人情報入力部１１６は、ユーザの住所氏
名をはじめとする個人情報を入力する。

【００３４】通信Ｉ／Ｆ部１１２は、通信部１６２とス
ケジュール通信装置１４のインタフェイスである。通信
部１６２は、たとえばＰＣ１４があらかじめ備えるモデ
ムやＬＡＮ回路や光通信回路等任意の通信機能ブロック
である。通信Ｉ／Ｆ部１１２は、通信部１６２がネット
ワークとの間のデータ授受が可能なようスケジュール通
信装置１４のデータを変換する。ただし、通信部１６２
が通信Ｉ／Ｆ部１１２の機能を備えている場合もあり、
その場合スケジュール通信装置１４は通信Ｉ／Ｆ部１１
２を持つ必要はない。

【００３５】図３はユーザ識別情報入力部１００の構成
を示す。ＰＩＤ入力部１００ａは、ユーザを個人として
認証するためのＩＤを入力する。ＰＰＷ入力部１００ｂ
はユーザを個人として認証するためのパスワードを入力
する。ＧＩＤ入力部３はユーザをグループとして認証す
るためのＩＤを入力する。ＧＰＷ入力部１００ｄはユー
ザをグループとして認証するためのパスワードを入力す
る。

【００３６】この実施の形態は、ユーザを個人として認
証できるだけでなく、そのユーザが属するグループの一
員として認証する機能を持つ。たとえば、友人同士でス
ケジュールを互いに見せることを認める場合、この友人
のグループが共通のグループＩＤおよびグループパスワ
ードを取得することにより、スケジュールの共有が可能
となる。

【００３７】ユーザ識別情報入力部１００はさらに、マ
シンＩＤ取得部１００ｅを備える。マシンＩＤ取得部１
００ｅは、たとえばＰＣ１２のＣＰＵのシリアル番号等
マシンに固有のＩＤを取得する。マシンＩＤを利用する
場合、たとえばユーザは個人のＩＤを入力しなくてもよ
い。マシンＩＤと通常の個人のＩＤやパスワード等の組
合せによるユーザの利便性の向上、またはセキュリティ
ーの向上についてはいろいろな変形技術が考えられる。

【００３８】図４は、サーバ側システム３０から送られ
てくるデータストリーム４００の構成を示す。データス
トリーム４００は、ヘッダ４０２と、ユーザのスケジュ
ール４０４と、そのユーザの嗜好に合うとして選択され
た広告４０６と、同じくそのユーザの嗜好やスキルに合
うとして選択された求人情報４０８を含む。ただし、ス
ケジュール４０４、広告４０６、求人情報４０８はこれ
らのうち任意のひとつ以上の情報が送られてくるもので
もよい。

【００３９】図５は、スケジュール取得部１０４の内部
構成を示す。定間隔アクセス部１０４ａは、既述のタイ
マー１５０の出力をもとに一定間隔でスケジュール、広
告または求人情報に対するアクセスを起動する。ユーザ
起動アクセス部１０４ｂは、ユーザが明示的にスケジュ
ール等へのアクセスを指示したとき、実際にスケジュー
ル取得動作を起動する。広告取得部１０６および求人情
報取得部１０８も一定の時間間隔またはユーザが指示し
たときにそれらの情報に対するアクセスを行ってもよ
い。広告や求人情報を取得するその他のタイミングの別
の例として、ユーザがスケジュールの登録を要求したと
き、スケジュールが実際に登録されたとき、ユーザがス
ケジュールを取得したとき等を挙げることができる。

【００４０】図６は、目的時刻判定部１１０の内部構成
を示す。スケジュール定型化部１１０ａは、サーバ側シ
ステム３０から送られてきたデータストリーム４００の
スケジュール４０４を解読し、スケジュールの内容と目
的時刻を所定のデータフォーマットに落とす。

【００４１】図７はそのフォーマット４３０を示す。こ
のフォーマット４３０は、ヘッダ４３２とスケジュール
の内容４３４とスケジュールの目的時刻４３６を含む。
広告定型化部１１０ｂおよび求人情報定型化部１１０ｃ
はそれぞれ広告と求人情報を図７同様のフォーマットへ
落とす。これら３種類のフォーマット化されたデータは
告知制御部１２０へ送られる。

【００４２】図８は告知制御部１２０の内部構成を示
す。告知制御部１２０は主に表示制御部１２２と音声通
知部１４０を含む。表示制御部１２２は、カレンダ表示
部１２４と非カレンダ表示部１２６を含む。

【００４３】カレンダ表示部１２４は、スケジュールを
カレンダに組み込んだ形で表示する。その際、広告およ
び求人情報もそのカレンダに組み込まれ、またはそのカ
レンダと関連づけられて表示される。カレンダ表示部１
２４は、月表示部１２８と、週表示部１３０と、日表示
部１３２と年表示部１３４と時刻表示部１３６を含む。
月表示部１２８は、広告の目的時刻が月単位で表現され
ていればスケジュールの該当する月の表示の中にその広
告を組み込む。同様に、週表示部１３０は広告の目的時
刻が週単位で表現されていればスケジュールの該当する
週の表示の中にその広告を組み込む。日表示部１３２、
年表示部１３４、時刻表示部１３６についても同様であ
る。

【００４４】これらの表示部は同時に複数が作動しても
よく、たとえば「１９９９年１１月２７日から１週間」
という目的時刻であれば、月表示部１２８、週表示部１
３０、日表示部１３２および年表示部１３４の４つの表
示部が同時に作動してもよい。ここでは広告について説
明したが、求人情報についても同様である。

【００４５】一方非カレンダ表示部１２６は、ユーザの
スケジュール、広告、求人情報等をカレンダではない
形、たとえばメモの形で表示する。カレンダ表示部１２
４と非カレンダ表示部１２６は同時に作動してもよく、
たとえばスケジュールはカレンダの中に記述するが、求
人情報はカレンダの外に表示することができる。

【００４６】音声通知部１４０は、ユーザのスケジュー
ル、広告、求人情報等を音声によって通知するための処
理を行う。たとえば「本日午前１０時東京駅」のような
メッセージでスケジュールを音声出力する構成としても
よい。メッセージをはじめとするテキストデータの音声
出力については既知の任意の技術を用いてもよく、ここ
では詳述しない。以上はＰＣ１２に内蔵されたクライア
ント側のスケジュール通信装置１４の構成である。

【００４７】図９は、サーバ側システム３０の広告サー
バ３６に内蔵されたスケジュール装置３８の内部構成を
示す。

【００４８】通信部２００は広告サーバ３６の有する任
意の通信機能であり、通信Ｉ／Ｆ部２０２はこの通信部
２００とスケジュール通信装置３８のインタフェイスと
して機能する。既述のごとく通信Ｉ／Ｆ部２０２は通信
部２００の中にあってもよい。

【００４９】スケジュール要求受付部２２４は、ユーザ
から発信されたスケジュールに関する要求を受け付け
る。この要求はユーザの識別情報とともに認証部２２６
へ送られる。認証部２２６はテーブル２３２に記録され
たＩＤとパスワードの組合せを参照し、ユーザを認証す
る。ユーザが正しく認証されたとき、ユーザのスケジュ
ールに対する要求はスケジュール管理部２２２に送られ
る。スケジュール管理部２２２は、スケジュールデータ
ベース４２に対するデータのリードライトを制御する。
したがって、ユーザのスケジュールに対する要求がスケ
ジュールの確認であれば、そのユーザに関するスケジュ
ールがスケジュールデータベース４２から読み出され、
これが送信データ生成部２０８へ送られる。送信データ
生成部２０８は、ユーザのスケジュールを図４に示した
データストリーム４００に変換し、これを通信Ｉ／Ｆ部
２０２および通信部２００を介してユーザへ送信する。

【００５０】個人情報取得部２０４は、図２に示すクラ
イアント側のスケジュール通信装置１４の個人情報入力
部１１６に入力された個人情報を取得する。この個人情
報は個人情報管理部２１０へ送られる。個人情報管理部
２１０は個人情報データベース４４に対するデータのリ
ードライトを制御する。個人情報データベース４４から
読み出されたデータは必要に応じて探索部２２０へ送ら
れる。

【００５１】広告取得部２４４は、企業サーバ５２その
他から広告を取得する。この広告にはすでに目的時刻が
付与されていてもよいし、されていなくともよい。目的
時刻が付与されていない場合、広告取得部２４４は企業
サーバ５２等に対してその情報の送信を要求する。広告
およびその目的時刻に関する情報は広告管理部２５０へ
送られる。広告管理部２５０は広告データベース５０に
対するデータのリードライトを制御する。広告データベ
ース５０から読み出された広告は必要に応じて探索部２
２０および課金管理部２４６へ送られる。

【００５２】求人情報受付部２０６は、企業サーバ５２
等から求人情報を取得する。取得された求人情報はバッ
ファメモリ２４２へ格納される。取得された求人情報は
送信データ生成部２０８および課金管理部２４６へ送ら
れる。送信データ生成部２０８は、後述する探索部２２
０によって選抜されたユーザに対し求人情報を送るため
に必要なデータを生成する。求人応答受付部２４０は、
ユーザに送信された求人情報に対する応募を受け付け
る。受け付けられた応募はバッファメモリ２４２に格納
される。

【００５３】関連情報指示部２３０は、送信された広告
や求人情報に関する関連情報に対してユーザがアクセス
を試みたとき、そのアクセスを実現するための処理を行
う。関連情報指示部２３０はユーザがどのような広告ま
たは求人情報に対して興味を示したかを把握できるた
め、その情報を探索部２２０へ送る。関連情報に対する
アクセスはまた、本スケジュール通信装置３８が適切な
ユーザに適切な広告や求人情報を送信できたことを示す
尺度となるため、その情報は課金管理部２４６へ送られ
る。すなわち、一種の成功報酬としての課金が発生す
る。

【００５４】図１０は、個人情報取得部２０４の内部構
成を示す。ゲーム配信部２０４ａは、ネットワークを介
してクライアントにゲームソフトウェアを配信する。ク
イズ配信部２０４ｂは、同様にクライアントにクイズを
配信する。アンケート通信部２０４ｃは、インセンティ
ブ型アンケート配信部２０４ｄと一般アンケート配信部
２０４ｅとアンケート受信部２０４ｆを含む。

【００５５】インセンティブ型アンケート配信部２０４
ｄは、ゲーム配信部２０４ａによって配信されたゲーム
で優秀な成績を収めたユーザにインセンティブ型のアン
ケートを配信する。インセンティブ型のアンケートと
は、ユーザがその住所、氏名、年齢、職業、趣味、勤務
先、好きなスポーツ、好きな音楽のジャンル、好きな映
画、好きな雑誌、ひいきにしているスポーツチーム、よ
く出かける街、好きな食べ物、ライフスタイルに関する
情報、行ってみたい国などの個人情報を回答することを
条件として、ゲームで優秀な成績を収めたことに対する
商品や景品をオンラインやオフラインで提供するもので
ある。同様のアンケートは、クイズに正解し、または優
秀な成績を収めたユーザにも配信される。

【００５６】ユーザメリット提供部２０４ｇは、そうし
た景品や商品等のユーザメリットをいろいろな形で提供
する。この実施の形態では、たとえばユーザに対してネ
ットワークの利用に関連するメリットを与える。たとえ
ばスケジュールの通信で発生する費用を割り引いたり、
音楽やゲーム等のソフトウェアを無料で配信したり、企
業サーバ５２を提供する企業の各種ネットワークサービ
スを低額で提供したり、ゲームまたはクイズの成績優秀
者としてネットワーク上で表彰する等が考えられる。

【００５７】一方、一般アンケート配信部２０４ｅは、
本実施の形態に係るスケジュールの通信サービスを開始
する際に所定の必要事項をユーザに記入させるためのア
ンケート、その他とくにインセンティブを与えないタイ
プのアンケートを配信する。

【００５８】アンケート受信部２０４ｆは、インセンテ
ィブ型のアンケートまたは一般アンケートに対するユー
ザの回答を受信する。この回答は個人情報管理部２１０
を介して個人情報データベース４４に格納される。これ
らのアンケート、とくにインセンティブ型のアンケート
により、ユーザの詳細な個人情報をユーザ自らが進んで
提供できる環境を作り出すことができる。そのため、ユ
ーザをその嗜好に応じてセグメンテーションすることが
できる。

【００５９】図１１は個人情報管理部２１０の内部構成
を示す。データベースリード部２１０ａは個人情報デー
タベース４４から必要なユーザの個人情報を読み出す。
読み出された個人情報は探索部２２０へ送られる。デー
タベースライト部２１０ｂは、個人情報取得部２０４か
ら送られた個人情報を個人情報データベース４４へ書き
込む。

【００６０】図１２はユーザごとに作成された個人情報
カード４５０の構成を示す。個人情報カード４５０は個
人情報データベース４４に格納されている。このカード
４５０は、アンケートの回答から得られた個人情報を格
納するための第一の領域４５２と、後述する関連情報指
示部２３０において得られた情報を格納する第二の領域
４５４を含む。第一の領域４５２は、既述のユーザの住
所氏名等の情報を格納する。一方、第二の領域４５４
は、後述のごとくユーザがアクセスした関連情報の内
容、すなわちジャンルとそのアクセス回数を格納する。
アクセスした関連情報の内容とその回数により、ユーザ
の嗜好を把握する趣旨である。

【００６１】図１３は、スケジュール要求受付部２２４
の内部構成を示す。スケジュール確認受付部２２４ａ
は、ユーザがそのスケジュールの確認の要求を送信した
ときこれを受け付ける。スケジュール更新受付部２２４
ｂは、ユーザがそのスケジュールの登録または更新の要
求を送信したとき、これを受け付ける。ただし、更新も
登録もスケジュールの書き込みに相当し、それらに技術
的な意味での相違はない。

【００６２】図１４は、認証部２２６の内部構成を示
す。ＰＩＤ／ＰＰＷ判定部２２６ａは、ユーザが個人識
別情報として送信してきた個人のＩＤとパスワードの整
合性を判定する。一方ＧＩＤ／ＧＰＷ判定部２２６ｂ
は、ユーザがグループの一員として送信してきたＩＤと
パスワードの整合性を判定する。これらふたつの判定部
は、ＩＤとパスワードの組合せが正しいかどうかをテー
ブル２３２に格納された組合せに照らして判断する。マ
シンＩＤ判定部２２６ｃは、ユーザのマシンのＩＤが送
られてきた際、これとユーザのパスワードの整合性等を
判定する。ユーザが正しく認証されたとき、スケジュー
ルの確認または更新を許可すべく、そのユーザの名前ま
たはＩＤ等の情報がスケジュール管理部２２２へ送られ
る。

【００６３】図１５は、企業サーバ５２から送信された
求人情報４６０を示す。求人情報４６０は求人情報受付
部２０６で受信され、バッファメモリ２４２へ一時的に
格納される。求人情報４６０は、任意の数の募集を含
む。ここでは、第一の募集４６２としてコンサートチケ
ット購入のためにアルバイトとして並ぶ人員が求められ
ている。また第二の募集４６４として、ＰＣ設計の正社
員が求められている。いずれの情報も、人員が必要とさ
れる目的時刻、勤務地、勤務内容、給与、勤務の内容ま
たは分類、募集の詳細を知るための企業のホームページ
のＵＲＬ等が記述されている。目的時刻の例として、勤
務開始日や開始時間、勤務の期間、勤務時間帯などがあ
る。

【００６４】図１６は、企業サーバ５２から送られた広
告４７０を示す。広告４７０は広告取得部２４４で受信
される。広告４７０は任意の数の広告アイテムを含む。
ここでは第一のアイテム４７２としてレコードショップ
におけるディスカウントセールが記述され、第二のアイ
テム４７４として美術館における特別展が記述されてい
る。いずれのアイテムも、ディスカウントの期間や展示
の期間等の目的時刻、広告の対象となるイベントの開催
場所、広告すべき内容、イベントの内容または分類、イ
ベントの詳細を知るためにアクセスすべきＵＲＬ等を含
む。

【００６５】図１７は関連情報指示部２３０の内部構成
を示す。アクセス検出部２３０ａは、ユーザから送信さ
れてきた広告や求人情報の関連情報、すなわちここでは
詳細情報を知るためにＰＣ１２の画面等に表示されたボ
タン等（図示せず）を押したとき、このアクションを検
出する。キャスティング部２３０ｂは、アクセス検出部
によって関連情報へのアクセスが検出されたとき、実際
にその関連情報を保持する企業サーバ５２またはそのホ
ームページへユーザのアクセスをキャストする。

【００６６】一方、アクセス情報分析部２３０ｃは、ユ
ーザがクリックした関連情報の内容を判定するアクセス
内容判定部２３０ｂと、その関連情報と同様の内容を持
つ関連情報へユーザがアクセスした合計回数をカウント
するアクセス回数計数部２３０ｅを含む。関連情報の内
容は、その関連情報が属するジャンル、分野、カテゴリ
ー等関連情報をインデキシングする任意の分類であって
よい。

【００６７】図１２の個人情報カード４５０の第二の領
域４５４は、こうして分析された関連情報の内容および
アクセス回数を示す。たとえば同図のごとく、このユー
ザは音楽関係の情報に１０回アクセスし、美術関係の情
報に５回アクセスし、以下同様にアクセスされた関連情
報の内容とその回数がリスト化されている。アクセス情
報分析部２３０ｃによって得られた情報は、個人情報取
得部２０４へ送られ、そこで個人情報カード４５０が作
成される。ただし、個人情報カード４５０は第一の領域
４５２のみを含む構成であってもよく、その場合、アク
セス情報分析部２３０ｃによって得られた情報は直接探
索部２２０へ送られる。これらの情報の管理および格納
の方法に種々の形態があることは当業者には容易に理解
されるところである。

【００６８】図１８は探索部２２０の内部構成を示す。
探索部２２０は主に、広告に関連する探索機能と、求人
情報に関連する探索機能を有する。広告に関連する探索
機能として、広告ベースユーザ検出部２２０ａおよびユ
ーザベース広告検出部２２０ｂが設けられている。

【００６９】広告ベースユーザ検出部２２０ａは、まず
企業がユーザに配信したいと考える広告を想定する。し
かるのち、その広告に適合するユーザを選択する。ユー
ザを選択する際、個人情報カード４５０が利用される。
たとえば広告があるデパートの大売り出しに関するもの
であれば、たとえばショッピングを趣味とするユーザが
選択される。また、音楽ＣＤのディスカウントセールが
広告の内容であれば、音楽に興味を持つユーザが選択さ
れる。別の例として、横浜のバーゲンセールに関する広
告であれば、まず横浜を中心とするユーザが選択され
る。ユーザは個人情報カード４５０の第一の領域４５
２、第二の領域４５４のいずれを用いて選択されてもよ
いし、それらの領域に含まれる任意の項目の任意の組合
せをもとに選択されてもよい。いずれにせよ、広告ベー
スユーザ検出部２２０ａは、ある広告をベースに、その
広告に何らかの意味で嗜好が合致する、または興味を持
ちうるユーザを選択すればよい。

【００７０】一方、ユーザベース広告検出部２２０ｂは
逆に、まずあるユーザを想定する。つづいてそのユーザ
にふさわしい広告を選択する。このときも個人情報カー
ド４５０が利用される。たとえば図１２に示す個人情報
カード４５０を持つユーザについて広告を選択する際、
そのユーザの趣味がドライブであり、頻繁にアクセスし
た分野が音楽や旅行であるとわかる。したがって、図１
６に示す広告４７０の複数のアイテム４７２、４７４等
から「ドライブ」「音楽」「旅行」等の言葉、またはそ
れらに関連する言葉を含むアイテムを選択する。図１６
のごとく、あらかじめアイテム４７２、４７４等が「分
類」という情報レコードを有していればその分類をもと
に広告を選択してもよい。

【００７１】ユーザベース広告検出部２２０ｂはさら
に、ユーザのプロファイル、たとえば年齢、住所、職業
等からそのユーザが興味を持ちうる広告を選択すること
もできる。ユーザのプロファイルからある程度その消費
傾向を推測することができるためである。ユーザのプロ
ファイルを利用した選択は、当然ながら広告ベースユー
ザ検出部２２０ａでも行うことができる。

【００７２】一方、求人情報に関する選択は、求人条件
マッチング判定部２２０ｃで行われる。求人条件マッチ
ング判定部２２０ｃは、ユーザスキル判定部２２０ｄと
ユーザ嗜好判定部２２０ｅとユーザスケジュール判定部
２２０ｆを含む。ユーザスキル判定部２２０ｄは求人情
報に明示的または暗黙的に含まれる求人の条件と整合す
るスキルを有するユーザを選抜する。

【００７３】たとえば図１５の求人情報４６０の第二の
アイテム４６４は、職務の内容がＰＣの設計である。し
たがって、現在または過去の職歴にＰＣの設計、情報機
器の開発等が記載されているユーザがまず選抜される。
求人の条件として年齢や資格の有無が定められている場
合、それらの条件も併せて満たすユーザが選抜される。
ユーザの選抜にあたり、あらかじめ求人情報を作成した
企業に、ユーザを探索する際のキーワードを選定させて
もよい。

【００７４】ユーザ嗜好判定部２２０ｅは、求人の職務
のジャンルに嗜好があうユーザを選抜する。たとえば求
人の内容が図１５の求人情報４６０の第一のアイテム４
６２のように、音楽に関連するアルバイトであれば、個
人情報カード４５０をもとに音楽に興味を持ちうるユー
ザが優先的に選抜される。

【００７５】ユーザスケジュール判定部２２０ｆは、求
人情報の目的時刻にスケジュールが整合するユーザを選
抜する。すなわち、求人情報の目的時刻にスケジュール
が入っていないユーザを優先的に選抜する。そのため、
ユーザスケジュール判定部２２０ｆは、スケジュール管
理部２２２を介してスケジュールデータベース４２へア
クセスする。ただし、企業が比較的長期にわたる勤務、
たとえば正社員としての人員を求めている場合、その条
件に見合うほど長期間にわたってスケジュールが入って
いないユーザはほとんど存在しないと考えられる。した
がってその場合、ユーザスケジュール判定部２２０ｆは
比較的短期の勤務に関する求人情報についてユーザを選
抜してもよい。

【００７６】以上、この探索部２２０によれば、広告を
流したときの効果が大きいと思われるユーザをあらかじ
め絞り込むことができ、そうしたユーザに集中的に広告
を流すことができる。逆にユーザから見た場合、配信さ
れてくる広告はいずれも比較的自分の興味をひくもので
あり、氾濫する情報の中で自分が欲する情報を見失う危
険性が減る。

【００７７】求人情報については、求人情報マッチング
判定部２２０ｃの作用により、企業における応募者の選
抜の手間を軽減できる。ユーザスキル判定部２２０ｄは
企業における応募者の書類選考を一部代行しうる。ユー
ザから見ても、自分のスケジュールが空いているときに
自分が比較的興味を持ちやすい仕事が提示されるため、
効率的に良質の求人情報を得ることができる。

【００７８】すなわち、探索部２２０はユーザのために
広告と求人情報をスクリーニングする機能を提供し、同
時に企業に対して効果的なマーケティングおよび人材の
確保のスクリーニング機能を提供する。しかも、こうし
た広告や求人情報がスケジュールにリンクされた形で提
供されるため、ユーザによる情報の活用に極めて高い利
便性を与える。流動性のある労働力の効率的かつ迅速な
確保が企業の存続に影響を与える今日、この実施の形態
の意義は大きい。

【００７９】図１９は送信データ生成部２０８によって
生成された送信データ５００を示す。送信データ５００
は、ヘッダ情報の一部であるユーザ／グループアドレス
５０２、スケジュール５０４、広告５０６、求人情報５
０８を含む。ユーザ／グループアドレス５０２は、探索
部２２０によって特定された、スケジュール５０４等を
送信すべきユーザまたはグループのアドレスである。た
だし、グループのアドレスは各ユーザと別個に存在する
必要はなく、そのグループに属する複数のユーザの複数
のアドレスの集合体であってもよい。スケジュール５０
４、広告５０６、求人情報５０８はそれぞれの中に目的
時刻を含むよう生成される。ただし、送信データ生成部
２０８は必ずしも目的時刻を含めた形でスケジュール５
０４等を記述する必要はない。その場合、クライアント
側のスケジュール通信装置１４の目的時刻判定部１１０
がスケジュール取得部１０４を介して目的時刻を問い合
わせる構成としてもよい。すなわち、目的時刻の最終的
な確定は、送信データ生成部２０８、クライアント側の
スケジュール取得部１０４および目的時刻判定部１１０
の間で分担することができる。

【００８０】図２０は課金管理部２４６の内部構成を示
す。この実施の形態では、課金は広告または求人情報の
ユーザへの配信を要請した企業に対して行われる。企業
サーバ識別部２４６ｅは求人情報、または広告の配信を
依頼した企業サーバを特定する。特定された企業サーバ
ごとにテーブル２４８の中に課金情報が生成される。

【００８１】求人情報カウンタ２４６ａは企業サーバか
ら依頼された求人情報、またはそれに含まれる求人アイ
テムを計数する。同様に広告カウンタ２４６ｂは企業サ
ーバから依頼された広告またはそれに含まれる広告アイ
テムを計数する。これらのカウンタによるカウント値に
それぞれ単価がかけられ、課金情報が生成される。

【００８２】この実施の形態ではさらに、企業が探索部
２２０によるユーザの探索を依頼したとき、探索の内容
や回数によって料金が加算される。探索加算部２４６ｃ
はそのための計算を行う。たとえばユーザを選抜する際
の条件の数に単価をかけて加算額を決定する。その他、
探索に要した時間等をもとに加算額を決定してもよく、
この部分も設計の自由度が高い。

【００８３】課金情報管理部２４６はさらに関連情報ア
クセスカウンタ２４６ｄを有する。このカウンタは、広
告または求人情報を受信したユーザがその関連情報にア
クセスした回数を記録する。この回数が多いほどユーザ
が高い興味を示したことになるので、前述のごとく一種
の成功報酬として料金が加算される。以上、全ての料金
が合計されこの企業に対する課金額がテーブル２４８へ
格納される。

【００８４】以上のスケジュール通信システム１０によ
るスケジュールの通信およびそれに伴う広告と求人情報
の配信処理について具体的に説明する。

【００８５】図２１は、ユーザがスケジュールを確認す
るときにＰＣ１２のディスプレイに表示される初期画面
３００を示す。ここではスケジュールを確認するための
個人識別情報入力画面３０２が表示されている。ユーザ
は、個人としてのスケジュールにアクセスしたい場合に
は個人に関するＩＤ（ＰＩＤ）およびパスワード（ＰＰ
Ｗ）を入力する。一方、自分が所属するあるグループの
スケジュールを見たい場合には、グループのＩＤ（ＧＩ
Ｄ）およびそのパスワード（ＧＰＷ）を入力する。

【００８６】図２２は、ユーザが携帯電話１６を用いて
スケジュールを確認する際に表示される初期画面３６０
を示す。携帯電話の場合、個人のＩＤは契約者番号（電
話番号）によって特定することができるため、ここでは
単にパスワードを入力すればよい。同図ではパスワード
の入力窓をひとつだけ描いているが、当然グループのパ
スワードを入力可能としてもよい。以下、ＰＣ１２を用
いるときと携帯電話１６を用いるときで本質的な相違は
ないため、ＰＣ１２を用いる例を中心に説明する。

【００８７】図２３は、ユーザが正しく認証された後表
示されたスケジュールである。スケジュール表示画面３
３２は、告知制御部１２０の表示制御部１２２の作用に
より、今日、今週、または今月のスケジュールが切り替
え可能に表示される。これらの切り替えは「今日」のタ
ブ３１０、「今週」のタブ３１２、「今月」のタブ３１
４によって切り替え可能である。

【００８８】図２３は、今日のスケジュールを示してい
る。スケジュール表示画面３３２の左半分は主に時経列
に並べられたスケジュールに関する。一方右半分はスケ
ジュールに対する補足情報を表示し、たとえばメモ、友
人等のアドレス、スケジュール帳の任意の場所に貼り付
けることが可能な各種マークを収めたシールの画面が選
択できる。選択は「メモ」タブ３１６、「アドレス」タ
ブ３１８、「シール」タブ３２０によって行われる。

【００８９】まず左画面において、「今日」のスケジュ
ールが選択されているとする。そのとき今日の日付１１
月２７日が表示され、その下に今日の予定が表示されて
いる。今日の予定の欄は、目的時刻の欄３４０とスケジ
ュールを象徴的に表すシンボルの欄３４２とスケジュー
ルの内容を示す欄３４４を含む。シンボルの欄３４２に
は、四角、三角、丸の３種類のシンボルが記入されてい
る。たとえば四角は個人のプライベートな予定に関連
し、丸は仕事に関連し、三角は企業から送られた広告を
示す。この図の場合、このユーザは１１時にスポーツク
ラブの予約をし、１３時にアルバイトに入る。１６時に
記述された「ｍｉｎｉライブＡＡＡ ｉｎ横浜」は、こ
のユーザが興味を持ちうるとして選択された広告であ
る。この場合、このユーザはたとえば「ＡＡＡ」という
ロックグループのファンクラブに入っていた可能性があ
る。このように広告はその目的時刻にしたがってユーザ
のスケジュールの中に組み込まれて表示される。

【００９０】ユーザのスケジュールが表示された「今日
の予定」の欄外に「１１／２８ ×××でチケット購入
バイトあり」という表示がなされている。これはこのユ
ーザが興味を持つとして、またはこのユーザの予定が空
いている日に相当するとして選択された求人情報であ
る。この情報の前に丸印３４６が付され、これが仕事す
なわち求人情報に関連することが明示されている。ただ
し、ユーザ自身がすでに行っている仕事、たとえば１３
時に入るアルバイトと区別するために、丸印３４６の色
を変える等の工夫をなしてもよい。

【００９１】この求人情報にはリンク３４８がはられて
おり、ユーザはその部分をクリックすることによりこの
アルバイトのより詳細な情報を確認することができる。

【００９２】なお、「今日の予定」のスケジュールの欄
は「日記」の表示と切り替えが可能である。また今日の
日付「１１／２７」および「今日の予定」以外の余白部
分にユーザが望む任意のキャラクターまたは画像を表示
する構成としてもよい。そうしたキャラクターや画像は
広告を流す企業が低額または無償で提供してもよい。

【００９３】一方、スケジュール表示画面３３２の右画
面は、現在メモを表示する状態になっている。ここでは
このユーザが１１時に予約をすべきスポーツクラブの電
話番号がメモとして書き込まれている。右画面にはサー
バから最新情報を取り寄せるためにクライアントとサー
バの間でコネクションを確立するための接続ボタン３２
２が設けられている。ユーザがこの接続ボタン３２２を
押すと、このＰＣ１２はダイヤルアップ等任意の接続方
法でインターネットに接続し、サーバから最新の広告や
求人情報等を受信する。

【００９４】ユーザがスケジュールの確認や更新をする
ときにもこの接続ボタン３２２を押せばよい。接続ボタ
ン３２２が押されたとき、その旨が図５のスケジュール
取得部１０４のユーザ起動アクセス部１０４ｂに伝えら
れる。一方、ユーザが接続ボタン３２２を押さない場合
であっても、この実施の形態ではタイマー１５０の作用
により、定間隔アクセス部１０４ａを介してユーザのス
ケジュール等が取得される。

【００９５】図２４はスケジュール表示画面３３２の別
の状態を示す。左画面では、「今週」のスケジュールが
選択されており、１１月７日から１３日の１週間のスケ
ジュールが表示されている。ここでも個人のスケジュー
ルが表示される他、１１月１１日には「ＢＢＢニューシ
ングル発売」という広告が表示されている。また、スケ
ジュールの領域の欄外には「ＡＢＣレコードセール中
（１１／６−１２）」という広告も表示されている。こ
の広告にもリンク３４８が設定され、関連情報へのアク
セスが可能となる。

【００９６】一方、右画面では「シール」の画面が選択
されている。ここでは「かいもの」を示す象のシンボル
３５０をはじめ、いろいろな行動予定やスケジュールに
関連することばに画像シンボル３５０が与えられてい
る。これらのシンボル３５０はスケジュールをより簡潔
に、かつわかりやすく表示するためにスケジュールの中
に貼り込むことができる。また、これらのシンボル３５
０をそのままシール用紙にハードコピーすることによ
り、実際にシールとして利用することもできる。これら
のシンボルも、ユーザが自ら描きうる他、広告等を提供
する企業から無償でダウンロードできる構成としてもよ
い。

【００９７】図２５はスケジュール表示画面３３２のさ
らに別の状態を示す。まず左画面において、「今月」の
スケジュールが選択され、１９９９年１１月の１ヶ月の
スケジュールが表示されている。この場合スケジュール
の内容を書き込むスペースがないため、先に導入した四
角、丸、三角のシンボル３４２のみを表示している。こ
の状態で任意の日付をクリックすることでその日のスケ
ジュールを表示する構成としてもよいし、任意のシンボ
ル３４２をクリックすることでそのシンボルに対応する
スケジュールの内容を表示する構成としてもよい。当然
ながら、シンボルの形状や色もユーザごとに任意に設定
できる構成としてもよい。

【００９８】図２６はユーザが携帯電話１６を利用する
際スケジュールの確認のために現れる画面３６０を示
す。この画面３６０は、図２３のスケジュール表示画面
３３２の左画面に対応する。一般に携帯電話１６は表示
画面が狭いため、ＰＣ１２のディスプレイに表示される
スケジュールのための画面の任意のサブセット、または
携帯電話１６に特化した画面を表示させればよい。

【００９９】図２７は、ユーザがスケジュールを確認す
る際の手順を示すフローチャートである。ユーザはまず
スケジュール取得部１０４を用い、スケジュール確認の
要求を送信する（Ｓ１０）。広告サーバ３６のスケジュ
ール要求受付部２２４はユーザから発信された要求を受
け付ける（Ｓ１２）。つづいて、認証部２２６がユーザ
を認証する（Ｓ１４）。認証が正しく終われば、スケジ
ュール管理部２２２によりそのユーザのスケジュールが
スケジュールデータベース４２から読み出され（Ｓ１
６）、これが送信データ生成部２０８へ送られる。送信
データ生成部２０８は、送信データ５００を生成し（Ｓ
１８）、これを通信Ｉ／Ｆ部２０２へ送る。送信データ
５００は通信Ｉ／Ｆ部２０２から通信部２００へ送ら
れ、ユーザへ送信される（Ｓ２０）。

【０１００】ユーザは送信された送信データ５００を通
信部１６２および通信Ｉ／Ｆ部１１２を介してスケジュ
ール取得部１０４にて取得する（Ｓ２２）。つづいて、
目的時刻判定部１１０においてスケジュール、および存
在する場合の広告と求人情報の目的時刻を判定する（Ｓ
２４）。つづいて、告知制御部１２０においてスケジュ
ールその他の情報のカレンダ表示がなされる（Ｓ２
６）。ユーザはカレンダ表示されたスケジュールその他
の情報を見ることにより、自らのスケジュールおよび広
告または求人情報を確認することができる（Ｓ２８）。

【０１０１】図２８、図２９はスケジュールを確認する
際に広告も表示するための手順を示すフローチャートで
ある。広告をユーザに配信する準備として、まず企業サ
ーバ５２から広告サーバ３６へ広告４７０が送信される
（Ｓ１００）。広告サーバ３６は、受信した広告４７０
のセグメント化と格納を行う（Ｓ１０２）。ここでセグ
メント化とは、後に必要な広告をより簡単に探索すべ
く、その広告に必要なキーワードを与えることをいう。
ただし、広告４７０が企業サーバ５２から送られてきた
時点ですでにこうした分類のためのキーワードが付与さ
れている場合、セグメント化は必要ない。広告４７０
は、広告管理部２５０を介して広告データベース５０に
格納される。

【０１０２】つづいて個人情報管理部２１０を介して個
人情報データベース４４を読み出し、目的ユーザを探索
する（Ｓ１０６）。ここで目的ユーザとは、先ほどの広
告を送信すべきユーザをいう。この探索は個人情報カー
ド４５０をもとに探索部２２０によって行われる。以上
で広告を配信するための準備が完了する。

【０１０３】ここでユーザがスケジュール確認の要求を
発信したとする（Ｓ１０）。広告サーバ３６はこの要求
を受け付け（Ｓ１２）、ユーザを認証し（Ｓ１４）、そ
のユーザのスケジュールを読み出す（Ｓ１６）。ここ
で、このユーザが先ほどの広告の目的ユーザであるか否
かにより処理が異なる（Ｓ１０８）。目的ユーザであれ
ば、送信データ５００にスケジュールのみならず広告を
格納し、データＴＤ１を生成する（Ｓ１１０）。一方、
目的ユーザでなければ、広告を格納せずにデータＴＤ２
を生成する（Ｓ１１２）。こうして生成された送信デー
タ５００はユーザに送信される（Ｓ２０）。

【０１０４】ユーザは、送信データ５００、すなわちデ
ータＴＤ１またはＴＤ２を受信する（Ｓ２２）。つづい
てそのスケジュールおよび必要な場合には広告の目的時
刻を判定する（Ｓ２４）。スケジュール等の情報はカレ
ンダ表示され（Ｓ２６）、ユーザはスケジュール等の情
報を確認する（Ｓ２８）。かりに、ユーザが表示された
広告に興味を示したとき、ユーザは関連情報、すなわち
詳細広告の表示を要求する（Ｓ１２０）。この要求は、
関連情報アクセス部１６０により発信される。この要求
は関連情報指示部２３０のアクセス検出部２３０ａによ
り検出される。キャスティング部２３０ｂは、ユーザに
詳細な情報を送るべくアクセスがあった旨を企業サーバ
５２へ取り次ぐ（Ｓ１２２）。それと並行して、アクセ
ス情報分析部２３０ｃによりユーザがアクセスした情報
の内容の判定およびアクセス回数のカウントが行われる
（Ｓ１２４）。

【０１０５】企業サーバ５２または企業のホームページ
は、ユーザに求められた関連情報、すなわち詳細広告を
ユーザに直接、またはＷＷＷサーバ３４を介して、また
は広告サーバ３６を介して送信する（Ｓ１２６）。詳細
広告を受信したユーザはその内容を確認する（Ｓ１２
８）。

【０１０６】なおここでは、まず広告を仮定してユーザ
を選択したが、当然これは逆であってもよい。すなわち
ユーザを先に仮定し、そのユーザにふさわしい広告を選
択する構成であってもよく、その処理については図１８
の探索部２２０の広告ベースユーザ検出部２２０ａまた
はユーザベース広告検出部２２０ｂのいずれかの機能に
よって実現される。

【０１０７】図３０は広告サーバ３６からユーザへ向け
て求人情報を発信する手順を示すフローチャートであ
る。ユーザに求人情報を配信する準備として、まず企業
サーバ５２が広告サーバ３６へ求人情報を発信する（Ｓ
２００）。求人情報は求人情報受付部２０６で取得され
る（Ｓ２０２）。つづいて個人情報管理部２１０が個人
情報データベース４４から個人情報を読み出す（Ｓ２０
４）。個人情報は個人情報カード４５０として探索部２
２０へ送られる。スケジュール管理部２２２はユーザの
スケジュールをスケジュールデータベース４２から読み
出す（Ｓ２０６）。スケジュールの情報も探索部２２０
へ送られる。

【０１０８】探索部２２０は目的ユーザを探索する（Ｓ
２０８）。まず個人情報をもとに、求人条件マッチング
判定部２２０ｃのユーザスキル判定部２２０ｄおよびユ
ーザ嗜好判定部２２０ｅがユーザの絞り込みを行う。つ
づいてユーザスケジュール判定部２２０ｆが求人情報の
目的時刻にスケジュールが入っていないユーザを選抜す
る。送信データ生成部２０８は、目的ユーザのアドレス
を格納して送信データ５００を生成し、これを通信Ｉ／
Ｆ部２０２および通信部２００を介してユーザに発信す
る（Ｓ２１０）。

【０１０９】ユーザはその求人情報取得部１０８によ
り、広告サーバ３６から送られた求人情報を取得する
（Ｓ２１２）。求人情報は目的時刻判定部１１０および
告知制御部１２０による処理を経てカレンダ表示される
（Ｓ２１４）。ここではかりにユーザが求人に応募する
とする（Ｓ２１６）。応募は求人応答部１１４を介して
行われる。応募はいったん広告サーバ３６へ送られ、求
人応答受付部２４０で取得され、バッファメモリ２４２
へ格納される。つづいて、応募があった旨が求人応答受
付部２４０から通信Ｉ／Ｆ部２０２および通信部２００
を経て企業サーバ５２へ取り次がれる（Ｓ２１８）。こ
の後、企業とユーザの間で任意の雇用契約が結ばれる
（Ｓ２２０）。

【０１１０】なお、ここでは任意のタイミングで求人情
報がユーザへ送信される例を示したが、当然ユーザがス
ケジュールを確認した際にこれを送信する構成としても
よい。この例でも求人情報を仮定し、それにふさわしい
ユーザを探索することにしたが、まずユーザを仮定しそ
のユーザに適合する求人情報を選択する構成としても何
ら差し支えはない。

【０１１１】以下、実施の形態の変形例のいくつかを挙
げる。

【０１１２】求人情報に関する目的時刻は、勤務時間で
なくともよい。スケジュール通信装置１４、３８は、た
とえば就職シーズンにおいて、いろいろな会社の説明会
や面接の時間を目的時刻としてスケジュール内に流し込
んでもよい。この場合、求人情報は広告と把握されても
よい。ユーザは希望する職種、勤務場所、勤務時間、給
与、その他の条件を予め登録しておくことにより、膨大
な求人情報の中から必要な情報をタイムリーに探し出す
ことができる。実施の形態では、すでに予定の入ってい
るユーザには求人情報を送らないとしたが、その場合に
も、状況によって送ってもよい。ユーザのスケジュール
通信装置１４の告知制御部１２０は、そうした情報を別
の色や薄い色で表示したり、ユーザのスケジュールより
も下または通常よりも小さく表示するなど、もともとの
ユーザのスケジュールが優先的に把握できる表示制御機
能をもってもよい。とくに、ユーザにとって重要な情
報、たとえば第一志望の会社の面接日時などは、たとえ
スケジュールが入っていても、ユーザはいち早く知りた
いはずである。そのためクライアント側に、自分のスケ
ジュールとバッティングする情報の表示許否を決めるオ
プション機能を設けてもよい。

【０１１３】スケジュール通信装置１４、３８は、入学
試験その他の試験に関する情報も求人情報または広告の
一種として扱ってもよい。たとえば、希望する学校の条
件をオンラインのアンケートその他の方法で登録してお
くことにより、その学校の試験日程等をスケジュールに
流し込む構成としてもよい。受験機関や塾が、カリキュ
ラムをスケジュールの中に表示すべくスケジュール通信
装置１４、３８を利用してもよい。カレンダーへ流し込
むべき広告や求人情報、またはそれにリンクされた関連
情報がある程度大きなデータになる場合、メインサーバ
３２側でその情報を整形してユーザのスケジュール通信
装置１４へ電子メールで送信してもよい。

【０１１４】試験、受験などに限らず、ユーザは自分が
興味をもつ情報のキーワードをアンケート等によって登
録しておくことにより、そのキーワードにヒットする情
報を広告としてスケジュール内に受信してもよい。その
ために、例えば個人情報入力部１１６でキーワードを受
け付け、これをサーバ側の個人情報管理部２１０で保持
し、探索部２２０によって広告またはその中のキーワー
ドと照合する。その結果、ヒットした情報がユーザへ広
告として送られ、これがスケジュールの目的時刻に沿っ
て告知される。課金管理部２４６は、より多数のキーワ
ードがヒットしたユーザへの広告配信単価をより高く設
定して広告費を企業へ課金してもよい。

【０１１５】目的時刻は、広告の対象となるセールスの
開催日時など、イベントに密着した客体的な要因で決め
る必要はなく、たとえば企業が広告をユーザに見せたい
日時のような主体的な要因で決めてもよい。その場合、
広告を打つ企業は、「１０月１０日の午前１０時の枠に
広告を入れたい」という要望を出せばよく、その日時が
目的時刻として扱われる。求人情報も同様である。サー
バ側のスケジュール管理部２２２は、広告や求人情報を
送るべきターゲットユーザのスケジュールが比較的あい
ている日時を検出し、その日時を目的時刻として広告ま
たは求人情報を出す企業を募ってもよい。そうして配信
された広告は、ユーザのスケジュール通信装置１４のカ
レンダーの当該日時に流し込まれる。このように、ユー
ザのスケジュールの空隙を埋める形の広告や求人情報に
ついては、カレンダー外で告知される広告よりも広告費
を安価に設定する方法もある。

【０１１６】実施の形態では、求人情報がユーザの空い
ている時間帯に送られたが、逆にユーザが、スケジュー
ル通信装置１４によって、自ら働きたい日時や希望職
種、すなわち「逆求人情報」ともいうべき労働力提供情
報を送信してもよい。その場合、スケジュール通信装置
１４のスケジュール登録部１０２などに、ユーザがカレ
ンダー表示の中に働きたい時間帯と希望等の付加情報を
入力する機能をもたせればよい。この労働力提供情報
は、メインサーバ３２を介して企業サーバ５２へと転送
される。

【０１１７】実施の形態では、ユーザを個人として認証
する機能と、グループとして認証する機能を述べた。自
分自身やその属するグループのスケジュールのみなら
ず、たとえば自分がある音楽バンドのファンクラブに入
っている場合、そのバンドのスケジュールを確認可能と
してもよい。すなわち、まったく他人のスケジュールを
所定の手続を経て確認できる構成も可能である。その場
合、そうしたアクセスを許す会員に特別なＩＤやパスワ
ードを設定してもよい。また、特別な課金管理を行って
もよい。課金の多様性については、実施の形態のさまざ
まなサービスにおいて同様である。

【０１１８】ユーザを個人またはグループとして認証す
る以外に、ユーザがスケジュールを入力する際、「パー
ソナル」「ビジネス」「全部公開」というような選択を
することで、それぞれ「ごく親しい仲間」「仕事関係
者」「自分のスケジュールを見たい全員」に対してスケ
ジュールを公開することができる。この場合クライアン
トであるスケジュール通信装置１４は、ユーザが入力す
るスケジュール情報の公開度に関するユーザの指定を受
け付ける機能をもてばよく、サーバ側システムのスケジ
ュール通信装置３８はその公開度をもとに、スケジュー
ルにアクセスを希望するユーザにアクセスを許すかどう
か判定する機能をもてばよい。別の方法として、各ユー
ザは「パーソナル」「ビジネス」「全部公開」について
別々のキーワードを設定し、相手にそれらのいずれかの
キーワードを教えることで、所望の公開度でスケジュー
ルを共有することができる。なお、これら任意のパスワ
ードは、各ユーザのスケジュール通信装置１４のメモリ
（図示せず）に保存しておいてもよく、その場合、パス
ワードを忘れる心配がなくなる。

【０１１９】ユーザによるスケジュール確認を容易にす
るために、決まった時刻、たとえば朝早い時間に、サー
バ側のスケジュール通信装置３８はその日のユーザのス
ケジュールを電子メールでユーザに送信する構成をもっ
てもよい。

【０１２０】ユーザのスケジュール内に広告や求人情報
を流し込む際、その数に上限を設けてもよい。その上限
はユーザが設定可能としてもよい。あまりにも多数の広
告等がユーザのカレンダーに流し込まれる事態を予防す
るためである。この場合、たとえばクライアントのスケ
ジュール通信装置１４の告知制御部１２０や広告取得部
１０６、その他任意の箇所で広告等の数が上限に達した
らそのカレンダー等への組込みまたは告知を中止、中断
する等の措置をとることができる。

【０１２１】ユーザが入力するスケジュールの量や流し
込まれる広告の量に応じて、カレンダーの日、週などの
枠の大きさを可変としてもよい。たとえば、日曜に予定
が多くなるユーザは、当然日曜の枠が大きいほうが都合
がよい。したがって、告知制御部１２０のカレンダー表
示部１２４は、表示すべき情報量を検出する機能と、そ
の情報量に応じて可変にカレンダーを表示する機能とを
備えればよい。

【０１２２】スケジュール管理プログラムは、すでにい
くつか市販されるか、ＷＷＷ上で利用可能になってい
る。また、ＰＣ等を購入するとき、プリインストールさ
れているときもある。そうした他のスケジュール管理装
置との連携をとるために、クライアントのスケジュール
通信装置１４は、他のスケジュール管理装置との間でユ
ーザのスケジュールデータをインポートまたはエクスポ
ートするためのデータフォーマット変換部を備えてもよ
い。

【０１２３】ニュースも広告の一種として配信すること
ができる。たとえば、２０００年４月２７日午後８時の
ニュースの見出しをユーザのスケジュールの該当日時に
流し込んでもよい。その場合、目的時刻判定部１１０
は、ニュース配信の時刻またはニュースのもととなった
できごとの発生時刻、たとえば地震の発生時刻など、ニ
ュースに関連する時刻を目的時刻と把握すればよい。

【０１２４】クライアント側のスケジュール通信装置１
４は、ユーザが期限のあるスケジュールをカレンダーに
記入するための機能を例えばスケジュール登録部１０２
に備えてもよい。たとえば、５月１０日までに提出のレ
ポートがあるとき、「５月１０日」の欄に「期限付き」
という属性を指定して「レポート提出」と記録してお
く。ユーザがこの記録を消さないうちに所定の日時、た
とえば一週間前に当たる５月４日になったとき、タイマ
ー１５０と告知制御部１２０などの協働により、ユーザ
に警告を出す構成としてもよい。

【０１２５】自分が追跡したい人の居場所をスケジュー
ルカレンダーの中に記録していってもよい。たとえば、
タイマー１５０によって一定時間ごとに自分の子供に持
たせたＰＨＳ端末の位置発信機能を利用してその位置を
検出し、子供の行動記録を自分またはその子供のカレン
ダーへ書き込むことができる。このために、スケジュー
ル通信装置１４、３８の通信部に、位置検出結果を受信
する機能をもたせ、目的時刻判定部１１０に、その場所
にいた時刻を目的時刻として検出する機能をもたせれば
よい。

【０１２６】前記通信部は、ユーザ本人の居場所を自動
的に検出し、これをそのユーザのカレンダーへ書き入れ
ていく構成であってもよい。その場合、ユーザは自分の
行動日誌を自動的にログファイルとして形成していくこ
とができる。自身の居場所の検出にＧＰＳシステムを利
用してもよい。

【０１２７】天気予報を広告としてカレンダーの対応す
る日時に流し込んでいってもよい。たとえば、５月５日
の欄に「晴れ」のマークを入れたり、５月５日の詳細な
スケジュールの欄に時刻ごとに変化する天気の予報を、
例えば午前１０時の箇所に「晴れ」、午後３時の箇所に
「曇り」というように詳細に入れてもよい。これらのマ
ークの近傍に、小さくスポンサーの表示を入れることに
より、広告価値が生じる。なお、天気予報のように地域
に依存する情報を配信する場合は、登録されているその
ユーザの住所を手かがりにするほか、ユーザがスケジュ
ールに書き込んだ地名をメインサーバ３２側で識別して
「横浜は晴れ」というような表示を出すほか、そのユー
ザのスケジュール通信装置１４に別途設けた位置発信装
置をもとに、メインサーバ３２側でユーザの居場所に合
わせた表示をすることもできる。

【０１２８】天気同様、株価、為替相場その他の刻々変
化する情報をユーザの登録内容にしたがって選択し、そ
の時々の情報をカレンダーに流し込んでもよい。この場
合、株価等の情報も広告と考えればよい。目的時刻はそ
の株価がついた時刻やそれを配信した時刻などである。
このサービスでもスポンサーを表示することができ、ま
たユーザは興味のある銘柄を簡便な仕組みでフォローで
きるため、双方に利益が大きい。

【０１２９】情報をセグメント化してカレンダーに流し
込んでもよい。セグメント化とは、情報をその内容やジ
ャンルに応じて分類する場合のほか、その情報を配信す
べきユーザのタイプに応じて分類する場合を含む。つま
り、情報をその客体によって分類するほか、主体によっ
て分類する場合を含む。

【０１３０】例として、セグメント化は、 ・スポーツ、トラベル、映画、レストランなどの客体的
特徴 ・若い人、男性など対象者の主体的特徴 にしたがって行われる。例えば、「レストラン」という
タイトルだけをカレンダーに流し込み、このタイトルか
らインターネット上のいろいろなレストランのサイトへ
リンクを張ったり、そうしたレストランを一カ所に集め
た「レストラン・ポータル・サイト」のような情報アイ
テム別の集約サイトまたは集約ページ（以下「集約ポイ
ント」という）へリンクを張ってもよい。実施の形態で
利用するスケジュール通信装置１４のカレンダーの日付
欄はさして大きなスペースを持たない場合も多く、セグ
メント化された情報ごとにひとつのタイトルで配信され
表示されることのユーザメリットは大きい。この方法に
よれば、ユーザは同様の商品を比較検討することもでき
る。

【０１３１】タイトル配信の際にも、目的時刻という概
念は利用可能である。例えば、そのタイトルを他の広告
等の情報が占領していない日時に入れることができる。
その場合、他の情報の目的時刻を予備的にチェックし、
重ならないか、または重なりの比較的少ない日時を目的
時刻として採用することができる。なお、こうした目的
時刻に関する選定方法は、タイトル配信以外にも利用で
きることに留意すべきである。

【０１３２】タイトル配信の目的時刻として、そのタイ
トルに関連する日を選定する方法もある。例えば、母の
日であれば、「母」をタイトルとするいろいろな情報を
サーバ側に集めてもよい。ユーザはタイトルをクリック
することで、「母」に関する情報アイテムへ、またはそ
のための集約ポイントへオンラインでアクセスし、必要
な情報の表示を受けることができる。

【０１３３】以上のほか、たとえばユーザが求める医
療、不動産、物品売買・提供、運勢、旅行、趣味、文化
などの情報を広告として配信することができ、実施の形
態の応用範囲は広い。

【０１３４】［応用技術］これまでは、個人の嗜好を中
心に広告配信とスケジュール管理の融合を説明した。応
用技術は、個人のタイプや行動を把握することにより、
よりユーザにふさわしい情報を配信するための技術に関
する。この方法は、ユーザがスケジュール通信装置のス
ケジュール欄（以下「スケジュール帳」ともいう）に入
力すべき内容に対応して設けられたアイコンのうち、ユ
ーザがスケジュール帳に実際に書き込んだアイコンの組
合せを検出する工程と、検出されたアイコンの組合せを
もとにユーザの類型または行動を判定する工程とを含
む。

【０１３５】この方法の実現にあたり、ユーザ側のスケ
ジュール通信装置は、アイコンを表示する表示制御部
と、ユーザが現実にスケジュール帳に書き込んだアイコ
ンを検出する検出部と、検出されたアイコンをユーザ管
理機能のあるサーバへ送信する送信部と、サーバから広
告を受信する受信部を含めばよい。また、受信した広告
に付された目的時刻を検出する日時検出部と、スケジュ
ール帳の表示領域のうち、検出された目的時刻に当たる
部分にその広告を表示する広告表示部とをさらに含むも
のである。

【０１３６】アイコンは、例えば５Ｗ１Ｈのそれぞれに
ついて複数設けられ、とくにイベントについて多数準備
されている。アイコンは画像ベースであり、以下の例が
ある。

【０１３７】１．ユーザ自身に関するもの 多数の似顔絵を容易しておき、ユーザが自ら気に入った
ものを選ぶ。他人に関して選ぶ場合は、その他人に似た
ものを選んでもよい。ユーザが自身をなぞらえる動物を
多数準備してもよい。いずれの場合も、ユーザの性別、
年齢、性質をはじめとする属性が反映されやすいアイコ
ンを準備することが望ましい。 ２．時間に関するもの 太陽や月のアイコンで昼夜を表す。その他、時刻を直接
表示した時計のアイコンを準備してもよい。 ３．場所に関するもの 駅、喫茶店、オフィス、球場、遊園地、学校、ニューヨ
ークを示す自由の女神など、場所を示すアイコンを用意
する。 ４．イベントに関するもの コンサート、試験、運動会、ドライブなどイベントを示
すアイコンを用意する。 ５．情報のコード化に関するもの ユーザが自分で文字や数字を所定のアイコンに割り当て
ることで、大事な情報を暗号化することができる。

【０１３８】以上のアイコンをスケジュール帳の画面の
任意の領域に表示し、またはそこから呼び出せるよう構
成することにより、ユーザはテキストベースで予定を入
力するかわりに、アイコンを選択して日付欄の中などに
書き込んでいくことができる。

【０１３９】こうしてユーザが複数のアイコンを書き込
んだ後、サーバ側はそのアイコンの組合せをもとにユー
ザのタイプや行動を判定し、ユーザにより適する広告、
求人、その他の情報を配信してもよい。このためにサー
バは、アイコンの組合せとそのユーザの類型または行動
を対応づけて保持する類型テーブルと、ユーザが現実に
スケジュール帳に書き込んだアイコンを検出するアイコ
ン検出部と、検出されたアイコンの組合せを類型テーブ
ルに照合してユーザの類型または行動を判定する判定部
とを備えればよい。

【０１４０】またサーバは、類型または行動と所定の情
報、例えば広告を対応づけて保持する情報テーブルと、
ユーザの類型または行動をその情報テーブルに照合して
そのユーザに紹介すべき情報を選定する選定部と、スケ
ジュール帳に時系列的に広告を配信する配信部をさらに
備える。配信部は広告にそれを表示すべき目的時刻を付
して配信する。

【０１４１】たとえば、ユーザが「コンサート」や「音
楽」に関するアイコンを多数回選択していれば、そのユ
ーザに対して音楽関係の情報や広告を配信することにメ
リットが出ると考えられる。多数のユーザの似顔絵から
ユーザ層がわかり、かつユーザ層と消費動向や行動パタ
ーンの関連等の情報もマイニングできる。

【０１４２】この方法のメリットは、以下のとおりであ
る。まず、画像ベースのアイコンの操作で必要な情報が
入力できるため、ＰＣ操作等に不慣れなユーザでも容易
に利用できる。また、現実問題として、アイコンのよう
な画像で示すことのできる情報量は概して多く、簡単な
テキストデータの代替として耐える場合が多い。一方、
ユーザが選択したアイコンはコードでサーバへ送信すれ
ばよいので、伝送データ量は少なくて済む。

【０１４３】つぎに、アイコンのサイズ統一等により、
表示に必要な領域が予定できるので、スケジュール帳の
設計面でも有利である。

【０１４４】また、アイコンの組合せは有限であるた
め、ユーザの類型化や行動パターンの判定が容易にな
る。

【０１４５】さらに、ユーザは情報をダイレクトに記述
する必要がないため、個人情報のセキュリティ面で安全
である。

【図面の簡単な説明】

【図１】 実施の形態に係るスケジュール通信システム
の構成図である。

【図２】 クライアント側のスケジュール通信装置の内
部構成図である。

【図３】 図２のユーザ識別情報入力部の内部構成図で
ある。

【図４】 図２のスケジュール取得部で取得されるデー
タストリームを示す図である。

【図５】 図２のスケジュール取得部の内部構成図であ
る。

【図６】 図２の目的時刻判定部の内部構成図である。

【図７】 目的時刻判定部から出力されたデータフォー
マットを示す図である。

【図８】 図２の告知制御部の内部構成図である。

【図９】 サーバ側のスケジュール通信装置の内部構成
図である。

【図１０】 図９の個人情報取得部の内部構成図であ
る。

【図１１】 図９の個人情報管理部の内部構成図であ
る。

【図１２】 個人情報カードを示す図である。

【図１３】 図９のスケジュール要求受付部の内部構成
図である。

【図１４】 図９の認証部の内部構成図である。

【図１５】 求人情報を示す図である。

【図１６】 広告を示す図である。

【図１７】 図９の関連情報指示部の内部構成図であ
る。

【図１８】 図９の探索部の内部構成図である。

【図１９】 図９の送信データ生成部で生成された送信
データの構成図である。

【図２０】 図９の課金管理部の内部構成図である。

【図２１】 ユーザがスケジュールを確認するための初
期画面を示す図である。

【図２２】 ユーザが携帯電話を用いてスケジュールを
確認するための初期画面を示す図である。

【図２３】 ユーザがスケジュールを確認するために表
示された画面を示す図である。

【図２４】 ユーザがスケジュールを確認するために表
示された別の画面を示す図である。

【図２５】 ユーザがスケジュールを確認するために表
示されたさらに別の画面を示す図である。

【図２６】 ユーザが携帯電話を利用する際に表示され
たスケジュールを示す図である。

【図２７】 ユーザがスケジュールを確認するための手
順を示すフローチャートである。

【図２８】 ユーザがスケジュールを確認する際広告を
表示する手順を示すフローチャートである。

【図２９】 ユーザがスケジュールを確認する際広告を
表示する手順を示すフローチャートである。

【図３０】 広告サーバからユーザへ求人情報を送信す
る手順を示す図である。

【符号の説明】

１０ スケジュール通信システム １４ スケジュール通信装置 ３０ サーバ側システム ３６ 広告サーバ ３８ スケジュール通信装置 ５０ 広告データベース １０２ スケジュール登録部 １０６ 広告取得部 １１０ 目的時刻判定部 １１６ 個人情報入力部 １２４ カレンダ表示部 ２０４ 個人情報取得部 ２４４ 広告取得部

───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5B075 KK07 ND20 NK39 PQ02 PR08

Claims (8)

【特許請求の範囲】
1. 【請求項１】 ユーザが電子的なスケジュール帳に入力
   すべき内容に対応して設けられたアイコンのうち、ユー
   ザがスケジュール帳に実際に書き込んだアイコンの組合
   せを検出する工程と、 検出されたアイコンの組合せをもとにユーザの類型また
   は行動を判定する工程と、 を含むことを特徴とするユーザ管理方法。
2. 【請求項２】 ユーザが電子的なスケジュール帳に入力
   すべき内容に対応して設けられたアイコンの組合せとそ
   のユーザの類型または行動を対応づけて保持する類型テ
   ーブルと、 ユーザが現実にスケジュール帳に書き込んだアイコンを
   検出するアイコン検出部と、 検出されたアイコンの組合せを類型テーブルに照合して
   ユーザの類型または行動を判定する判定部と、 を含むことを特徴とするユーザ管理装置。
3. 【請求項３】 前記類型または行動と所定の情報を対応
   づけて保持する情報テーブルと、 ユーザの類型または行動をその情報テーブルに照合して
   そのユーザに紹介すべき情報を選定する選定部と、 をさらに含む請求項２に記載の装置。
4. 【請求項４】 前記スケジュール帳に時系列的に広告を
   配信する配信部をさらに備える請求項２、３のいずれか
   に記載の装置。
5. 【請求項５】 前記配信部は広告にそれを表示すべき目
   的時刻を付して配信する請求項４に記載の装置。
6. 【請求項６】 ユーザが電子的なスケジュール帳に入力
   すべき内容に対応して設けられたアイコンを表示する表
   示制御部と、 ユーザが現実にスケジュール帳に書き込んだアイコンを
   検出する検出部と、 検出されたアイコンをユーザ管理機能のあるサーバへ送
   信する送信部と、 を含むことを特徴とするユーザ管理装置。
7. 【請求項７】 前記サーバから広告を受信する受信部を
   さらに含む請求項６に記載の装置。
8. 【請求項８】 受信した広告に付された目的時刻を検出
   する日時検出部と、 スケジュール帳の表示領域のうち、検出された目的時刻
   に当たる部分にその広告を表示する広告表示部と、 をさらに含む請求項６、７のいずれかに記載の装置。