JP2003015977A - 情報管理装置 - Google Patents

Abstract

(57)【要約】 【課題】 ユーザはスケジュールを管理するとき、同時
にいろいろな情報を関連づけて一括管理したいが、その
方法が確立していない。 【解決手段】 スケジュール通信システム１０はクライ
アント側のスケジュール通信装置１４とサーバ側のスケ
ジュール通信装置３８を有する。サーバ側のスケジュー
ル通信装置３８は、ユーザの入力したスケジュールを管
理している。ユーザがあるページをブラウザで見ている
とき、それを「リマインド指定」すると、前記スケジュ
ールが記述されたカレンダのリマインド指定日時欄に前
記ページのＵＲＬがクリック可能に記入される。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

【従来の技術】電子手帳をはじめ、ユーザに電子的な方
法でカレンダを提供し、スケジュールを管理する技術が
知られている。しかし、ユーザは自分のスケジュールだ
けではなく、そのスケジュールに関連する各種情報も併
せて管理したい場合がある。たとえば、「コンサート」
とだけ入力しても、実際にはそのコンサートの場所その
他の詳細情報をいちどに管理できたほうが便利である。

【０００３】

【発明が解決しようとする課題】しかしながら、そのた
めの方法は確立しているわけではない。本発明者はこう
した状況の洞察をもとにこの発明をなしたもので、その
目的は、利便性と有用性の高いスケジュールまたは情報
管理技術の提供にある。

【０００４】

【課題を解決するための手段】本発明のある態様は、情
報管理装置に関する。この装置は、所定の情報ページ、
たとえばウェブページ上にリマインド用のボタンを表示
するとともに、そのボタンがクリックされたとき、以下
の処理が起動されるようそのボタンに機能モジュールが
リンクされている。

【０００５】工程１： リマインドの日時をユーザに入
力せしめる処理、 工程２： 入力された日時に、前記情報ページを直接表
示せしめ、または前記情報ページを参照すべき旨を表示
せしめる処理。

【０００６】情報ページを参照すべき旨の表示は、その
情報ページのアドレスをクリック可能な形でなされても
よい。たとえばＵＲＬをクリック可能に表示する場合が
これに当たる。

【０００７】工程２は、そのユーザのスケジュールを記
入した電子的なカレンダにおいて、前記入力された日時
の欄に前記表示を行ってもよい。

【０００８】本発明の別の態様も情報管理装置に関す
る。この装置は、情報ページを表示するブラウザにリマ
インド機能を実装し、当該機能はリマインド用のボタン
を表示するとともに、そのボタンがクリックされたと
き、上記の工程１、２の処理が起動されるようそのボタ
ンに機能モジュールがリンクされている。この態様の例
として、リマインド機能がブラウザのプラグインとして
提供される場合が考えられる。

【０００９】本発明のさらに別の態様も情報管理装置に
関する。この装置は、サーバから情報を受信する受信部
と、受信された情報を電子的なカレンダにおいて前記情
報に関連づけられた日時に一致する日時欄に表示する第
１表示部と、ユーザがリマインド指定をした情報を前記
カレンダにおいてそのリマインドの指定日時に一致する
日時欄に表示する第２表示部とを含む。

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

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

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

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

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

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

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

【００１７】本発明のさらに別の態様は、情報管理装置
に関する。この装置は、所定の情報ページ上に形成され
たイベント登録ボタンがクリックされたときに送信さ
れ、そのボタンに予め対応付けられているイベント情報
を受信する受信部と、受信したイベント情報を前記登録
ボタンをクリックしたユーザに対応付けてスケジュール
データベースに登録する登録処理部と、前記ユーザに要
求されたとき、前記ユーザのスケジュール通信装置に前
記スケジュールデータベースに格納されているイベント
情報を送信する送信部とを備える。「イベント情報」
は、スケジュールとして登録すべき事柄の内容、日時、
場所などを含み、予定として登録するひとつひとつの事
柄を示す。

【００１８】本発明のさらに別の態様は、情報管理装置
に関する。この装置は、所定の情報ページ上に形成され
たイベント登録ボタンがクリックされたときに送信さ
れ、そのボタンに予め対応付けられているイベント識別
情報を受信する受信部と、イベント識別情報とイベント
情報とを対応付けて格納するイベント格納部と、受信し
たイベント識別情報に対応付けられたイベント情報を前
記登録ボタンをクリックしたユーザに対応付けてスケジ
ュールデータベースに登録する登録処理部と、前記ユー
ザに要求されたとき、前記ユーザのスケジュール通信装
置に前記スケジュールデータベースに格納されているイ
ベント情報を送信する送信部とを備える。

【００１９】この装置は、イベント情報を予め受け付
け、そのイベント情報に対応付けてイベント識別情報を
生成する識別情報生成部を更に備えてもよい。

【００２０】この装置は、前記スケジュール通信装置に
イベント情報を送信する場合に、送信するデータのフォ
ーマットまたは通信手順を、前記スケジュール通信装置
の種類に応じて変換するデータ生成部を更に備えてもよ
い。これにより、様々なベンダーが開発したスケジュー
ル通信装置を対象にスケジュールデータの送信が可能に
なる。

【００２１】この装置は、前記受信部が受信したイベン
ト情報またはイベント識別情報を計数して、前記イベン
ト情報の提供主に対して課金を行う課金部を更に備えて
もよい。

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

【００２３】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１４０】［応用技術］これまでは、個人の嗜好を中
心に広告配信とスケジュール管理の融合を説明した。応
用技術は、同じくユーザのスケジュールを軸に、広告を
はじめとする情報のリマインド機能を提供する。処理の
起点はカレンダではなく、ユーザがあるウェブページを
参照しているときにある。すなわち、ユーザがそのペー
ジを再度あるタイミングで参照したいとき、これを「リ
マインド」指定し、かつ「リマインド日時」を指定す
る。そのページのＵＲＬはカレンダの対応する日時欄に
自動的に記入される。ユーザが自分のスケジュールを確
認するためにカレンダを見たとき、リマインド日時に対
応する日時欄にＵＲＬがクリック可能に記入されてお
り、これをクリックすればブラウザが起動してそのペー
ジへアクセスできる。

【０１４１】ユーザがページをリマインド指定する方法
は、大別してふたつある。第１の方法では、そのページ
に直接リマインド用のボタンその他のユーザアクション
取得手段（本明細書では「ボタン」で代表させる）を埋
め込んでおく。これはそのページの運営者が本スケジュ
ール通信システムの協賛者その他の関係者であるとき実
現しやすい。ボタンはそのページの背後でＣＧＩ等のプ
ログラムにリンクされており、このプログラムから逆に
ユーザのカレンダの該当日時へＵＲＬが記入される。Ｕ
ＲＬの記入は、そのプログラムとユーザ端末のスケジュ
ール通信プログラムの間でプロトコルを決めておけば、
たとえばテキストデータの受け渡しだけでも容易に実現
できる。

【０１４２】第２の方法では、ユーザのブラウザにプラ
グインでリマインド指定用の機能を組み込んでおく。た
とえばツールバーなどに「リマインド」という項目を表
示させ、ユーザがこの項目をクリックすると、現在開か
れているページのＵＲＬが取得され、つづいて「リマイ
ンド日時」の入力画面を出力する。日時が入力されたら
これをプラグインプログラムで取得し、前述同様の方法
でユーザ端末のスケジュール通信プログラムに引き渡
す。

【０１４３】この技術を利用するシーンの例は以下のと
おりである。まずユーザが、あるテーマパークに興味を
もち、この公式ホームページその他関連ページへアクセ
スする。ユーザはこのテーマパークへ５月５日に行くこ
とを決め、「リマインド日時」として「５月５日」を設
定する。このアクションにより、そのユーザのカレンダ
の５月５日の欄にそのテーマパークのホームページその
他のページのＵＲＬが入る。ユーザは当日、またはそれ
に先立つ任意のタイミングでそのＵＲＬをクリックする
ことにより、そのテーマパークの詳細情報を参照するこ
とができる。

【０１４４】以上、この応用技術によれば、ユーザがブ
ックマークを設定する要領でリマインド機能を実現でき
る。そのためのベースとなる装置として、基礎技術で説
明したスケジュール通信装置の任意の機能を想定すれば
よく、その場合ユーザが頻繁に確認するカレンダ上にリ
マインド情報が表示されるため、実効性も利便性も高
い。

【０１４５】＜第２の実施の形態＞図３１は、応用技術
を有する第２の実施の形態におけるスケジュール通信シ
ステム６００の構成図である。同図において、図１を用
いて説明した機能ブロックと同一の符号を付した構成
は、その機能ブロックと同様の機能を有する。事業者サ
ーバ６０４は、ホームページなどの電子的な手段により
ユーザに対して商品や役務の説明、発売日、予約受付
日、営業開始日、ネットショッピングなどを提供するサ
ーバであり、例えば上述したテーマパークのホームペー
ジを提供するサーバである。

【０１４６】閲覧装置６１２は、ネットワーク６０２を
介して事業者サーバ６０４が提供するホームページを閲
覧するための機能をユーザに提供する。ウェブページ６
０６は、閲覧装置６１２により表示された画面の一例で
ある。このウェブページ６０６は、コンサートチケット
の予約受付開始日を通知する画面であり、従来はそのコ
ンサートチケットの購入を希望するユーザは予約受付開
始日を自ら記憶し、またはメモをとるなどしていた。し
かし、本システムでは、ユーザが、スケジュール登録ボ
タン６０８を押すことで、予約受付開始日などの情報
（以下、「イベント」または「イベント情報」という）
が電子的なスケジュール帳（以下、「スケジュール帳」
という）に自動的に格納される。

【０１４７】スケジュール登録ボタン６０８をクリック
すると、そのイベントを特定する情報（以下、「イベン
ト識別情報」という）がユーザを特定する情報（以下、
「ユーザ識別情報」という）とともにネットワーク６０
２を介してサーバ側スケジュール通信装置６２０（以
下、「サーバ６２０」という）に送信される。閲覧装置
６１２は、ユーザ識別情報または認証情報を、イベント
識別情報を送信するときにユーザから受け付けてもよい
し、例えば一般にクッキー（Cookie）と呼ばれるクライ
アント側にデータを保持し、必要に応じてそれをサーバ
側で呼びだす仕組みを利用して予め保持してもよい。こ
の仕組みを利用することで、イベント識別情報を送信す
るたびにユーザ識別情報を入力するという手間が省け
る。

【０１４８】サーバ６２０は、イベント情報をスケジュ
ールとして格納する前に、イベントの内容とユーザ識別
情報に対応付けられたユーザの情報をウェブページとし
て提示し、ユーザから内容の確認を受けた後に格納して
もよい。この確認処理において、ユーザの情報が本人と
は異なる場合、ユーザは自分の情報に変更することがで
きる。このような、確認処理を行うことで、他人の閲覧
装置６１２を使った場合でも、ユーザは自分のスケジュ
ール帳にイベント情報を登録できる。また、ユーザ識別
情報をサーバ６２０からスケジュールを取得するための
識別情報と異なるものにすることで、セキュリティーを
高めることができる。

【０１４９】サーバ６２０は、イベントの詳細情報と、
イベント識別情報とを対応付けて格納しており、受信し
たイベント識別情報に対応付けられた詳細情報を、その
イベント識別情報を送信したユーザに対応付けて格納す
る。

【０１５０】クライアント側スケジュール通信装置１４
（以下、「クライアント１４」という）は、ユーザの指
示に応じてサーバ６２０からスケジュールデータを取得
して、表示装置にスケジュール画面６１０を表示する。
「スケジュールデータ」は、クライアント１４がスケジ
ュールを表示するために必要な、個々のイベントの情報
であり、例えばそのイベントの日時、内容等の情報群で
ある。本図では、スケジュール画面６１０の、「２００
２年４月６日」の欄にコンサートチケットの予約開始日
の旨が表示されている。

【０１５１】クライアント１４は、様々なベンダーによ
り開発されたものであってよく、サーバ６２０は、ユー
ザのクライアント１４に応じてスケジュールデータのフ
ォーマットや、転送手順を変えて転送を行う。閲覧装置
６１２およびクライアント１４は、例えばプログラムを
実行することでＰＣ１２に形成される。ＰＣ１２は、デ
スクトップ型のＰＣや、携帯電話などの携帯端末であっ
てもよい。

【０１５２】図３２は、図３１の事業者サーバ６０４か
ら閲覧装置６１２に提供されるウェブページ６０６を形
成するためのウェブファイルに含まれる、スケジュール
登録ボタン６０８を形成するコマンド群の一例である。
このファイルは、ＨＴＭＬ（Hyper Text Markup Langua
ge）で作成されている。＜ＦＯＲＭ＞タグは、指定され
たサーバに対してデータを送信する際に利用するコマン
ドである。コマンド７０４はスケジュール登録ボタン６
０８を表示することを意味し、そのボタンが押下される
と、ＣＧＩ設定欄７００に設定されているアドレス宛て
に、イベントＩＤ欄７０２に保持されているイベント識
別情報「３４２３４４３２」が送信される。このような
コマンド群を含むウェブファイルを事業者サーバ６０４
は配信する。

【０１５３】図３３は、図３１のサーバ側スケジュール
通信装置６２０の内部構成図である。このサーバ６２０
は、同図に表記した機能ブロックに加えて、図示しない
が図９を用いて説明したスケジュール通信装置３８の機
能ブロックを有する。受付部６２４は、事業者サーバ６
０４を運営する事業者からイベント情報を受け付け、Ｉ
Ｄ生成部６２２が生成したイベント識別情報に対応付け
てイベント格納部６３４に格納するとともに、そのイベ
ント識別情報を事業者に提供する。受付部６２４は、事
業者に対して、例えばイベントの日時、内容、場所など
のイベント情報の入力フォームを提供してもよい。事業
者は、その入力フォームに必要事項を入力した後、受付
部６２４から提供されるイベント識別情報を図３２で示
したボタン表示用のコマンドに含めてウェブファイルを
作成する。

【０１５４】登録要求受信部６２６は、図３１のスケジ
ュール登録ボタン６０８をユーザが押下することで、閲
覧装置６１２から送信されたイベント識別情報とユーザ
識別情報を受信し、登録処理部６３２に供給する。登録
処理部６３２は、イベント格納部６３４からイベント識
別情報に対応付けられたイベント情報を取得し、ユーザ
識別情報で特定されるユーザのスケジュールとして図９
のスケジュールデータベース４２に格納する。登録要求
受信部６２６は、イベント情報とそれをスケジュールに
登録するユーザの情報を提示するウェブページのウェブ
ファイルを閲覧装置６１２に送信し、そのページを確認
したユーザから、登録確認を受信した後、登録処理部６
３２に登録処理を指示してもよい。

【０１５５】課金部６２８は、登録要求受信部６２６に
おいてイベント識別情報を受信するごとに、そのイベン
ト情報を提供する事業者に対して課金を行う。そして、
課金部６２８は、課金額を、例えば定期的に事業者に請
求する。他の例では、課金部６２８は、イベント情報を
スケジュールデータベース４２に格納するたびに課金を
行ってもよい。この課金処理により、イベントの登録回
数に応じた課金ができる。

【０１５６】調査部６３０は、イベント識別情報を受信
した回数、時間、イベント識別情報を送信したユーザの
性別、年齢、所在地などに基づいて、そのイベントに関
するユーザの反応を集計、分析する。この分析結果に基
づいて、事業者はユーザの動向調査、すなわち前評判を
把握でき、それに応じてマーケティング戦略や広告戦略
をリアルタイムで打ち出すことができる。事業者は、ユ
ーザの動向に追随した戦略を立てることができるので、
効率的なマーケティングが可能になる。

【０１５７】ユーザがクライアント１４を起動して、ス
ケジュールデータを要求すると、図９の送信データ生成
部２０８は、クライアント１４の種類に応じて、送信手
順やデータ形式にあったスケジュールデータを生成す
る。このために、図９の個人情報データベース４４は、
ユーザが利用するクライアント１４を特定する情報を保
持する。送信データ生成部２０８は、個人情報データベ
ース４４を参照して、クライアント１４を把握した上
で、適当な送信データを生成する。他の例では、クライ
アント１４は、スケジュールデータをサーバ６２０に要
求する際に、自身を特定する情報を送信してもよい。こ
れにより、サーバ６２０は、様々な種類のクライアント
１４に対してスケジュールデータの送信が可能である。

【０１５８】図３４は、図３３のイベント格納部６３４
のデータ構造の一例である。イベントＩＤ欄７１０は、
イベント識別情報を保持する。日時欄７１２は、イベン
トを行う日時を保持する。内容欄７１４は、イベントの
内容を保持する。確定フラグ欄７１６は、イベントの例
えば、日時や内容が確定しているか、否かを保持する。
同図では、「１」はイベントが確定していることを意味
し、「０」は未確定であることを意味する。例えば、ゲ
ームソフトなどは発売が予定されていても、その発売日
が決まっていない場合がある。こういった場合、確定フ
ラグ欄７１６には「０」が保持される。

【０１５９】図３３の登録処理部６３２は、確定してい
るイベントをユーザのスケジュールに登録し、確定して
いないイベントは、例えば「６月発売予定」などとし
て、適当な日付に対応付けてそのイベントを仮登録して
おく。例えば、登録処理部６３２は、月の上旬ならば
「１日」、中旬ならば「１０日」、下旬ならば「２０
日」と予め対応関係を持っていてもよい。そして、イベ
ントが確定した段階で、登録処理部６３２は、正式な日
時に対応付けてそのイベントを登録する。図３３の受付
部６２４は、そういった確定していないイベントの登録
も受け付け、更にイベントが確定した段階で再びイベン
ト情報を受け付ける。

【０１６０】図３５は、図３１のスケジュール通信シス
テム６００におけるイベント登録処理のフローチャート
である。事業者は、サーバ側スケジュール通信装置６２
０にイベント情報を登録し、そのイベントのイベント識
別情報を要求する（Ｓ３００）。サーバ６２０は、イベ
ント情報を登録するとともに、識別情報を生成し（Ｓ３
０２）、それを事業者に送信する（Ｓ３０４）。事業者
は、イベント識別情報を含むウェブファイルを作成し
（Ｓ３０６）、それを事業者サーバ６０４において公開
する（Ｓ３０８）。

【０１６１】ユーザは、一般にブラウザと呼ばれている
閲覧装置６１２を起動し（Ｓ３１４）、事業者サーバ６
０４に対してウェブページ６０６のウェブファイルを要
求する（Ｓ３１０）。事業者サーバ６０４は、その要求
に対してウェブファイルを送信する（Ｓ３１２）。閲覧
装置６１２は、そのウェブファイルを表示装置に表示
し、ユーザはそれを閲覧する（Ｓ３１６）。そして、ユ
ーザがウェブページ６０６のスケジュール登録ボタン６
０８を押すと、閲覧装置６１２はイベント識別情報をサ
ーバ６２０に送信してイベントの登録を要求する（Ｓ３
１８）。サーバ６２０は、イベント情報をユーザのスケ
ジュールとして登録し（Ｓ３２０）、そのイベント情報
を提供した事業者に対して課金を行う（Ｓ３２２）。こ
れにより、サーバ６２０には、イベント情報が登録され
る。

【０１６２】ユーザがクライアント側スケジュール通信
装置１４を起動し（Ｓ３２４）、スケジュールデータを
サーバ６２０に要求する（Ｓ３２６）。サーバ６２０
は、スケジュールデータを生成し（Ｓ３２８）、クライ
アント１４に送信する（Ｓ３３０）。クライアント１４
は、それを例えば、時系列的に配置してユーザに提示す
る（Ｓ３３２）。

【０１６３】図３６は、図３２を用いて説明したウェブ
ファイルとは別のコマンド群の一例である。同図におい
て、図３２と同一の符号を付したコマンドは同様の意味
を有する。コマンド７０６は、イベントの日時、内容を
示す情報を送信することを意味し、別のコマンド７０８
は、事業者ＩＤを送信することを意味する。これらのコ
マンド群により、ユーザがスケジュール登録ボタン６０
８を押すことで、閲覧装置６１２は、イベント日時、内
容、事業者ＩＤをサーバ６２０に送信する。このような
コマンドをウェブファイルに記してもよい。事業者ＩＤ
を送信するためのコマンド７０８は、図３３の課金部６
２８が課金処理を行うために記されているものであり、
他の例では設けられなくてもよい。

【０１６４】＜第３の実施の形態＞図３７は、応用技術
を有する第３の実施形態のスケジュール通信システム６
５０の構成図である。スケジュール通信システム６５０
は、ウェブファイルを受信した閲覧装置６６０が、ウェ
ブファイルに含まれるイベント情報を、クライアント側
スケジュール通信装置１４に供給する形態である。この
供給に際して、閲覧装置６６０は、イベント情報に、ク
ライアント１４に応じたデータ形式に変換する処理６５
４を施して供給する。同図において、図１および図３１
と同一の符号を付した機能ブロックは、図１および図３
１を用いて説明した機能ブロックと同一の機能を有す
る。

【０１６５】図３８は、図３７の閲覧装置６６０の内部
構成図である。ウェブファイル受信部６６２は、ウェブ
ファイルを事業者サーバ６０４から取得して解析部６６
４に送信する。解析部６６４は、そのウェブファイルに
含まれるコマンド、すなわちＨＴＭＬタグを解析して、
ウェブページ６０６を形成するために必要な画像デー
タ、その他ファイルの取得をウェブファイル受信部６６
２に指示するとともに、ウェブページ６０６を形成す
る。表示処理部６６６はウェブページ６０６を表示装置
に表示するための処理を行う。

【０１６６】指示受付部６７０は、ユーザからスケジュ
ールへの登録指示を受け付ける。指示受付部６７０は、
例えば閲覧装置６６０のメニューバーに「スケジュール
に登録」といったボタンを形成し、そのボタンが押され
ると取得部６７２にその旨を通知する。取得部６７２
は、ウェブファイルに含まれるイベント情報を取得す
る。例えば、イベント情報は、所定のタグによりウェブ
ファイルに含まれている。スケジュール装置情報格納部
６７６は、図３７のクライアント１４へスケジュールを
供給する際の、データ形式や供給手順などの情報を保持
する。

【０１６７】登録処理部６７４は、取得したイベント情
報を、クライアント１４に応じたデータ形式に変換して
出力する。その出力先は、例えば、クライアント１４が
独自に有する、外部アプリケーションからスケジュール
データを受け付けるための登録モジュール６７８、複数
のアプリケーション間でスケジュールデータの交換をす
る目的で図３７のＰＣ１２に設けられた共有格納領域６
８０、クライアント１４のスケジュールデータベースを
操作して格納６８２するなどがある。また、イベントデ
ータを図３７のサーバ側スケジュール通信装置３８に送
信してもよい。

【０１６８】図３９は、別の形態の閲覧装置６９０の内
部構成図である。この閲覧装置６９０は、図３１を用い
て説明したスケジュール通信システム６００で利用され
ても、図３７を用いて説明したスケジュール通信システ
ム６５０で利用されてもよい。閲覧装置６９０は、ユー
ザが閲覧中のウェブページを再び閲覧するリマインド日
時を自ら設定してスケジュールとして登録するための機
能を有する。同図において、図３８と同一の符号を付し
た機能ブロックは、図３８で説明した機能ブロックと同
一の機能を有する。指示受付部６７０は、ユーザからの
指示を受け付けると、その旨をアドレス取得部６９２に
出力する。指示受付部６７０は、例えば閲覧装置６９０
のメニューバーに「リマインド登録」といったボタンを
形成し、そのボタンが押されるとアドレス取得部６９２
にその旨を通知する。アドレス取得部６９２は、現在表
示中のウェブページのアドレスを解析部６６４から取得
する。リマインド日時設定部６９４は、リマインド日時
をユーザから受け付ける。登録処理部６７４は、リマイ
ンド日時に、再び閲覧すべきウェブページのアドレスを
スケジュールとして登録する処理を行う。

【０１６９】図３９では、閲覧装置６９０がウェブペー
ジのアドレスを取得し、ユーザからリマインド日時を受
け付けるとしたが、図３２または図３６を用いて説明し
たようにウェブファイルにボタンを形成するためのコマ
ンド群を含め、そのボタンを押下したときに、閲覧中の
ウェブページのアドレスを図３３のサーバ側スケジュー
ル通信装置６２０に送信してもよい。そして、サーバ側
スケジュール通信装置６２０は、リマインド日時をユー
ザから受け付けるためのウェブページをユーザに提供し
てもよい。

【０１７０】上述した応用技術により、ユーザが、例え
ばウェブページに表示されたボタンを押すことで、自動
的にイベント情報をスケジュール帳に時系列に加えるこ
とができる。イベント情報は、例えばテレビやラジオの
番組情報、料理レシピ、新聞記事などの様々なコンテン
ツであってもよい。「テレビ番組情報」は、番組名、放
映日、開始時間、終了時間、チャンネル等の情報であ
り、ユーザがウェブページに形成されたボタンを押すこ
とで、このテレビ番組情報がユーザのスケジュール帳に
登録される。クライアント側スケジュール通信装置１４
に、テレビ番組情報をビデオ等の記録装置に送信する機
能を設けてもよい。

【０１７１】

【発明の効果】本発明によれば、ユーザのスケジュール
を電子的に管理できる。また、単純な操作で容易にスケ
ジュールの登録ができる。さらに、イベントの登録状況
を分析して種々の目的で利用できる。

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図３２】 図３１のウェブページを形成するためのウ
ェブファイルの一部を示す図である。

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

【図３４】 図３３のイベント格納部のデータ構造の一
例を示す図である。

【図３５】 図３１のスケジュール通信システムにおけ
る各装置間のシーケンス図である。

【図３６】 図３２のウェブファイルとは別のウェブフ
ァイルの一部を示す図である。

【図３７】 第３の実施形態におけるスケジュール通信
システムの構成図である。

【図３８】 図３７の閲覧装置の内部構成図である。

【図３９】 図３８の閲覧装置とは別の閲覧装置の内部
構成図である。

【符号の説明】

１０ スケジュール通信システム、１４ スケジュール
通信装置、３０ サーバ側システム、３６ 広告サー
バ、３８ スケジュール通信装置、５０ 広告データベ
ース、１０２ スケジュール登録部、１０６ 広告取得
部、１１０ 目的時刻判定部、１１６ 個人情報入力
部、１２４ カレンダ表示部、２０４ 個人情報取得
部、２４４ 広告取得部、６２２ ＩＤ生成部、６２６
登録要求受信部、６２８ 課金部、６３０ 調査部、
６３２ 登録処理部、６３４ イベント格納部、６７０
指示受付部、６７２ 取得部、６７６ スケジュール
装置情報格納部、６９２ アドレス取得部、６９４ リ
マインド日時設定部。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 17/60 ＺＥＣ Ｇ０６Ｆ 17/60 ＺＥＣ

Claims (12)

【特許請求の範囲】
1. 【請求項１】 所定の情報ページ上にリマインド用のボ
   タンを表示するとともに、そのボタンがクリックされた
   とき、以下の処理が起動されるようそのボタンに機能モ
   ジュールがリンクされたことを特徴とする情報管理装
   置。 工程１： リマインドの日時をユーザに入力せしめる処
   理、 工程２： 入力された日時に、前記情報ページを直接表
   示せしめ、または前記情報ページを参照すべき旨を表示
   せしめる処理。
2. 【請求項２】 前記情報ページを参照すべき旨の表示
   は、その情報ページのアドレスをクリック可能な形でな
   される請求項１に記載の装置。
3. 【請求項３】 工程２は、そのユーザのスケジュールを
   記入した電子的なカレンダにおいて、前記入力された日
   時の欄に前記表示を行う請求項１、２のいずれかに記載
   の装置。
4. 【請求項４】 情報ページを表示するブラウザにリマイ
   ンド機能を実装し、当該機能はリマインド用のボタンを
   表示するとともに、そのボタンがクリックされたとき、
   以下の処理が起動されるようそのボタンに機能モジュー
   ルがリンクされたことを特徴とする情報管理装置。 工程１： リマインドの日時をユーザに入力せしめる処
   理、 工程２： 入力された日時に、前記情報ページを直接表
   示せしめ、または前記情報ページを参照すべき旨を表示
   せしめる処理。
5. 【請求項５】 前記情報ページを参照すべき旨の表示
   は、その情報ページのアドレスをクリック可能な形でな
   される請求項４に記載の装置。
6. 【請求項６】 工程２は、そのユーザのスケジュールを
   記入した電子的なカレンダにおいて、前記入力された日
   時の欄に前記表示を行う請求項４、５のいずれかに記載
   の装置。
7. 【請求項７】 サーバから情報を受信する受信部と、 受信された情報を電子的なカレンダにおいて前記情報に
   関連づけられた日時に一致する日時欄に表示する第１表
   示部と、 ユーザがリマインド指定をした情報を前記カレンダにお
   いてそのリマインドの指定日時に一致する日時欄に表示
   する第２表示部と、 を含むことを特徴とする情報管理装置。
8. 【請求項８】 所定の情報ページ上に形成されたイベン
   ト登録ボタンがクリックされたときに送信され、そのボ
   タンに予め対応付けられているイベント情報を受信する
   受信部と、 受信したイベント情報を前記登録ボタンをクリックした
   ユーザに対応付けてスケジュールデータベースに登録す
   る登録処理部と、 前記ユーザに要求されたとき、前記ユーザのスケジュー
   ル通信装置に前記スケジュールデータベースに格納され
   ているイベント情報を送信する送信部と、 を備えることを特徴とする情報管理装置。
9. 【請求項９】 所定の情報ページ上に形成されたイベン
   ト登録ボタンがクリックされたときに送信され、そのボ
   タンに予め対応付けられているイベント識別情報を受信
   する受信部と、 イベント識別情報とイベント情報とを対応付けて格納す
   るイベント格納部と、 受信したイベント識別情報に対応付けられたイベント情
   報を前記登録ボタンをクリックしたユーザに対応付けて
   スケジュールデータベースに登録する登録処理部と、 前記ユーザに要求されたとき、前記ユーザのスケジュー
   ル通信装置に前記スケジュールデータベースに格納され
   ているイベント情報を送信する送信部と、 を備えることを特徴とする情報管理装置。
10. 【請求項１０】 イベント情報を予め受け付け、そのイ
    ベント情報に対応付けてイベント識別情報を生成する識
    別情報生成部を更に備えることを特徴とする請求項９に
    記載の情報管理装置。
11. 【請求項１１】 前記スケジュール通信装置にイベント
    情報を送信する場合に、送信するデータのフォーマット
    または通信手順を、前記スケジュール通信装置の種類に
    応じて変換するデータ生成部を更に備えることを特徴と
    する請求項８または１０に記載の情報管理装置。
12. 【請求項１２】 前記受信部が受信したイベント情報ま
    たはイベント識別情報を計数して、前記イベント情報の
    提供主に対して課金を行う課金部を更に備えることを特
    徴とする請求項８または９に記載の情報管理装置。