JP2010508731A - 要求されるイベントに関する通知を加入者に送信する方法及び装置 - Google Patents

Abstract

加入者は、ファックスやメモ等の選択された新着イベントを通知される。加入者プロフィールは、データベースに格納され、加入者が通知されることを希望する少なくとも一つの所定イベントと、加入者が好む通知手段に関するデータを含んでいる。新着イベントが発生すると（２００）、データが新着イベントから抽出され（２０５）、データベースが抽出されたデータを用いて照会され（２１０）、加入者プロフィールには、抽出されたデータの少なくとも一項目と、特定された加入者が希望する新着イベントの通知手段（２１５）を含む少なくとも一人の加入者を特定する。次に、イベント通知は、特定された加入者に対して決められた手段に従って新着イベントを作成し（２２０）、イベント通知は、決められた手段に従って、特定された加入者に送信される（２２５）。

Description

本発明は、選択されている新着イベントの発生を人に通知することに関する。

本出願は、米国仮特許出願番号６０／８６３，２９７号、出願日２００６年１０月２７日の優先権を主張し、前記出願の開示内容は全て参照によって本明細書に明示的に組み込まれる。

ＥＰ１２５９０８８Ａ

多くのビジネスでは、外回りの職員がおり、顧客や見込客を訪問したり、よく社外に出かけたりする一方で、顧客や見込客に関するビジネスイベントを知っておく必要がある。かかる外回りの職員は、「現場」にいると考えることもでき、その結果、「外務員」とも呼ばれる。かかる職員は、毎日あるいは定期的に出社してもしなくても良かったり、不定期あるいは任意に出社したり、及び／又は小人数の支社にいたりする。その一方で、かかる職員は、所定のイベントが発生したときは、効率的かつ確実に、職務を遂行及び／又は顧客に情報提供し、見込客を追跡管理し、及び／又は新規の機会を探ることができるように、通知を必要としている。例えば、顧客が保険証書の更新料を未払いであることを通知するメモがあれば、その保険証書や顧客を担当する外務員は、すぐに顧客と連絡を取って、顧客に保険証書の更新を納得させようと努めるべく、そのメモができるだけ早く通知されることを希望するであろう。

加入者は、選択した新着イベントを、例えばファックスやメモ等で通知される。データベースに格納されている加入者プロフィールには、加入者が通知を希望する少なくとも一つの所定イベント及び加入者が希望する通知手段のデータが入っている。新着イベント発生時には、当該新着イベントからデータを抽出し、抽出されたデータでデータベースを照会して、その抽出データの少なくとも一項目を含む会員プロフィールの会員を特定し、その特定された会員が希望している通知手段を特定する。そして、新着イベントのイベント通知が、特定された会員に対して決められている手段によって用意され、そのイベント通知は、その決められている手段によって送信される。上記に関する方法及び装置の両方を開示する。

典型的環境における典型的なイベント通知システムのブロック図。

典型的なイベント通知システムの処理を示す典型的なフローチャート。

加入者が入力する条件及び選好の処理を示す典型的なフローチャート。

このイベント通知システムは、外務員及び他に関与する権限のある職員（まとめて「加入者」）が、彼らにとって関心のある又は重要なイベントの通知を受信することを可能にする。イベント通知システムでは、加入者は、関心を持つイベントや関心を持つイベントの詳細を選択する。例えば、加入者は、特定の保険証書番号に関係するすべてのイベントについて通知されることを選択することができる。別の例として、加入者は、新しい保険証書の発行に関するすべてのイベントについて通知されることを選択することができる。

さらに、加入者は、このような通知を関心のある特定領域に制限するように希望することができる。例えば、会員は、新規の保険証書の発行に関するすべてのイベントが通知されることを選択することができるだけでなく、その国の特定の地域、すなわち特定の州、群、市、地方又は領域を選択することもできる。これらの選択（本明細書では「条件」と呼ばれる）は、加入者データベースに格納される。

さらに、例えば、特定の会議や訓練コースへの出席要求のように、所定イベントに関する会社指示の通知もある。このような通知は、職員の「選択」であるかどうかでなく、会社の方針、手続、必要に基づいて案内される。例えば、地元の休日、事務所移転のための特定日や特定期間中に、嵐、洪水あるいは落雷その他の被害のために、会社が特定の事務所を閉鎖することを通知するメモを発行する。このような重要なメモは、一部の又はすべての職員に案内可能であり、職員がそのメモに関する通知を受信しないように条件を変更する選択権を持たないようにすることが好ましい。

イベント通知システムでは、加入者は、希望する通知方法を選択することもできる。例えば、限定はしないが、好ましくは、音声合成を用いた電話連絡、テキストメッセージ／ショートメッセージサービス（ＳＭＳ）、電子メール、及び／又はインターネットを使った個人用の会社ポータルである。所定の通知方法、例えば電話連絡においては、会員は勤務時間内に配信されるように選択することもできる。これらの通知の選好も加入者データベースに格納される。このようにして、会員は選択された新着イベントを例えばファックスやメモ等で通知される。「メモ」の語は、本明細書において広く使われており、一般に何かを誰かに通知しようとするあらゆる文書を含み、覚書、通知書、指示書、お知らせ、要望書等を含むが、それらに限られない。メモは、必ずしもそうではないが、通常は社内文書であって、つまり、社外文書でも良いが、そうで無いことが好ましい。

イベント通知システムでは、新着イベント、例えば新規のメモがあったときに、メモの幾つかのフィールドを調査して所定データを抽出する。好ましくは、調査されるフィールドは予め決定されている。そして、加入者データベースは、データベースの条件フィールドにおいて抽出データを照会する。この照会は、好ましくは、抽出データの各項目について行われ、新着イベントの特定の側面に関心を持つ加入者のリストを提供する。他の方法として、加入者データベースは、加入者の選択した条件を示すインデックスを付けることもできる。そして、抽出データに対してインデックスに照会して、関心を持つ加入者のリストを提供する。何れかの方法の結果として、関心を持つ加入者、すなわち新着情報の通知を希望する（又は通知されるべき）加入者のリストが作成される。

次に、各加入者の通知の選好を調査して、どのように通知されることを希望しているかを決定する。新着イベント、その１以上のセクション、又はその概要、又はそれに関連する情報、又はそれへのインデックス又はリファレンス、又はその中の関連データの一部又は全部（まとめて「イベント通知データ」）を、関心を持つ加入者に送信する。通知の選好が電話連絡である場合には、加入者は、好ましくは電話を受けても良い（又は受けるべきでない）時間を指定することができる。

加入者の条件及び選好は、加入者プロフィールデータベースに格納される。使用される場合、条件インデックスは、加入者プロフィールデータベースに格納されてもよく、別個に格納されてもよい。

いくつかのイベントは、機密データを含んでおり、安全ではない通信リンクで送信すべきでない場合がある。したがって、機密データを含むイベントがあり、かつ、通知方法が安全でない場合には、限られた量の機密性のないデータだけを送信することが好ましい。会社所有のユーザ名及びパスワードで保護されるウェブサイト又はイントラネットは、安全であるとみなされるが、他の通信方法、例えば、電子メール、ファックス、更に音声伝送等は、一般に安全であるとは認められない。

また、好ましくは、上述した条件に加えて、加入者は、所定の「否定」条件を選択することもでき、否定条件が存在する場合には、加入者はイベントを通知されない。例えば、加入者は、新規の保険証書の発行に関するすべてのイベントが通知されることを希望してもよいが、特定の州、群、市、地方、テリトリー等において保険証書が発行される場合については、通知されることを希望しなくてもよい。別の例として、加入者は、特定の商品に対する新規の保険証書の発行に関するすべてのイベントについて通知されることを希望してもよいが、他の製品を含む場合には、通知されることを希望しなくてもよい。「否定条件」は、包括的であれ排他的であれ、例えば、限定はしないが、先の状態に対して５％以上（未満）の変化等のように、範囲制限を含んでいてもよい。

実施形態は、保険証書についてであるが、それは実施される具体例にすぎず、限定するものではない。従って、イベントは、保険証書に関連するものでもよいが、イベントは、このようなものに制限されず、人が通知されることを希望する他の処置、文書、出来事等を含むものでもよい。その他のイベントのタイプとしては、例示的なものであって限定するものではないが、サービス契約；供給契約；銀行又は証券会社の顧客による使用で、口座についての預金、引出し、借越しの通知、及びそれらの又は関連口座の開設及び閉鎖の通知；信用状態の信用調査所による販売等の信用報告書に関する個人又は会社による使用で、債権者又は第三者の債券情報、信用度、又は他の情報要求、又は信用度の点数の変更、好ましくても好ましくなくても信用報告書への新規の情報又は更新情報の入力を含む；学校、単科大学、総合大学の学生による使用で、クラスの登録、授業料、本及び手数料の支払い又は未払い、履修したコースの評価の発表、成績証明書の状態、卒業要件の状態又は変更、エントリー又は新規又は更新情報に対する通知等；年金受給者による使用で、個人及び／又は企業の年金制度の状態、投資戦略又は保有の変更、新規又は更新情報のエントリー、利益、支払い又は未払いの変更の通知、出資又は出資の変更、又は出資計画の変更の通知、毎月の年金の計算、又は年金の変更、計画又はステータスの変更における年金計画及び年金提供者に関するもの；その他がある。さらに、「条件」は、例えば、これらには限定されないが、名前、街路番号、所在地、市、群、州、郵便番号、テリトリー、地方、電話番号、ファックス番号、エリアコード、電子メールアドレス、電子メールドメイン名、保険証書番号、契約番号、信用報告書参照番号、学生証番号、年金計画番号、日付、時間、金額、保険証書の種類、グループ名又は番号、個々の従業員名又は番号、又はＳＩＣコード等の他の顧客情報等のイベント通知が適切であるかどうかを決定するために、定義され、使用される可能性があるフィールド、データ、又は用語を含むと理解されるべきである。

さて、保険証書又は契約についてのオペレーションの一例を考えてみる。複数の加入者が、ログインし、各自のプロフィールを構築し又は更新する。例えば、加入者１は、ジョージア州に関するすべてのイベントについて通知されることを希望し、加入者２は、電話番号のエリアコード４０４に関するすべてのイベントについて通知されることを希望し、加入者３は、電話番号のエリアコード４０４に関するすべてのイベントと、保険証書番号１２３４５に関するすべてのイベントについて通知されることを希望し、加入者４は、保険証書番号１２３４５に関するすべてのイベントと、コロラドに関するすべてのイベントについて通知されることを希望している。

ここで、会社が複数のメモを公表する場合を考える。メモＡは、新規の保険証書がジョージアで発行されたことを通知する；メモＢは、保険証書番号１２３４５がジョージアで更新されたことを通知する；メモＣは、コロラドの保険証書番号１３５７９が失効したことを通知する；そして、ファックスＤが、電話番号４０４−５５５−１２１２から受信される。様々なメモにおいて予め決められたフィールドが調査され、そこからデータが抽出される。例えば、メモＡは、主題フィールドにデータ「新規保険証書」、場所フィールドにデータ「ジョージア」、イベント種類フィールドに「メモ」を備えており、メモＢは、場所フィールドにデータ「ジョージア」、保険証書番号フィールドに保険証書番号「１２３４５」、イベント種類フィールドに「メモ」を備えており、メモＣは、場所フィールドにデータ「コロラド」、主題フィールドに「契約失効」、保険証書番号フィールドに「１３５７９」、イベント種類フィールドに「メモ」を備えており、ファックスは、電話番号フィールドにデータ「４０４−５５５−１２１２」、イベント種類フィールドに「ファックス」を備えている。

上記したフィールド及び名称は、典型的なものであり、必要に応じて、他のフィールド及び／又は異なるフィールド名を用いてもよい。例えば、区別される音声及びファックス電話番号フィールドが存在することが可能であり、「発信オフィス」フィールドが存在することも可能であり、「イベント種類」フィールドに、「メモ」又は「ファックス」等以外のイベントを備えることも可能である。

次に、これらのフィールドや、存在する他のフィールドからの本データを用いて、加入者プロフィールを照会し、関心を持つ加入者を決定する。加入者プロフィールデータは、この例では、以下のように示される。

場所：コロラド（加入者４）；ジョージア（加入者１）；

保険証書番号：１２３４５（加入者３と４）；と

電話番号：エリアコード４０４（加入者２と３）

条件フィールドの関連データに対して、加入者プロフィールを照会すると、この例では、以下のような結果となる。

加入者１は、メモＡとＢの通知を受信する；

加入者２は、ファックスＤの通知を受信する；

加入者３は、メモＢとファックスＤの通知を受信する；そして、

加入者４は、メモＢとＣの通知を受信する。

従って、イベント通知システムは、加入者にとって関心のある重要なイベントの通知をタイムリーに効率よく提供する。

図１は、典型的環境における典型的なイベント通知システム１０のブロック図である。イベント作成部８は、イベント（メモ、ファックス等）を作成する。イベント作成部は、一般的に単一装置でなく、複数の、通常、別個独立になっている装置を表している。例えば、イベント作成部は、一般に、少なくとも一台のファックス受信機と、ワードプロセッサ、スプレッドシート、又はプレゼンテーションプログラム等の文書作成プログラムを含んでいる。ファックス受信機は、ファックスを受信すると、それを処理及び格納するためにシステム１０に転送する。会社は、一般に複数のメモを作成するが、それは通常、草稿の形態で始まって、一回又は二回以上改訂され、それから最終的に公表される。メモが一旦公表されると、文書作成部は、それを処理及び格納のためにシステム１０に転送し、又はメモを格納する場合には、たとえ未公表でも草稿形態で格納しておき、その後、文書作成部がフラグを追加するか又はフラグを設定して文書が公表されたことを示す。いつメモを最終版とするかの決定及びその公表の決定は、一般に手動で実行される。その一方で、メモが最終版であるという目印が付けられて公表されると、その文書はシステム１０に転送され、及び／又はフラグが設定されて、文書がイベントとして処理される用意ができていることをシステムに通報する。システム１０に対する文書、メモ、ファックス、電子メール等は、電子的形態であると理解されるべきである。

前掲の典型的な実施形態において、システム１０はイベント入力待ち行列１１を含む。好ましくは、すべての新着イベントは、この待ち行列に入れられて連続的に処理される。一旦処理されると、新着イベントは、更なる処置のためにデータベース管理部１３に転送され、適切な場合は格納される。別の実施形態では、待ち行列１１は、格納及びその後の処置のため、すぐにデータベース管理部１３に新着イベントを転送する。更に別の実施形態では、イベント作成部は、格納及びその後処置のため、待ち行列１１とデータベース管理部１３の両方に新着イベントを直接提供する。単一のメモリを、イベント格納部１４と加入者プロフィール１５の両方として機能させてもよい。もしくは、各々に異なるメモリを用いてもよい。

新着イベントが発生すると、イベント解析部１２が処置する。イベント解析部１２によって実行される処置の一つは、イベント解析部１２が現在処理している新着イベントに関して、フラグを追加又は設定することである。これは信頼性機能である。電力不良又はシステム破壊等の問題があって、その問題を修正する際には、イベント解析部１２はフラグを探し、どこで処理を再開するかを決定する。これは、新着イベントが失われる可能性を低減する。新着イベントがイベント解析部１２によって一旦処理されると、その入新着イベントに対してフラグを除去するか又は下ろして、待ち行列１１の次の新着イベントに対してフラグを追加又は立てる。

イベント解析部１２によって実行される別の処置は、新着イベントを調査して、その内部の関連データを抽出することである。一実施形態では、新着イベント（メモ、ファックス）の性質によって、どのフィールドを調査すべきかを決定する。例えば、メモは、調査可能な主題フィールドを備えていてもよく、「メモ」、「新規の保険証書」、「失効」、「失効保留」等、限定されない所定の単語が存在するかどうかを決定するための調査をすることができる。この基本的な情報は、メモに用いる形式の種類を識別するために使用可能であり、すなわち、メモ内のフィールド、各フィールドの場所、及び各フィールドに含まれる情報の種類を識別するために使用可能である。もしくは、すべてのメモが、同じ形式に従って、同じ場所に、同じフィールドを備えることとしてもよく、異なるフィールドは、異なる種類のメモと関連しており、その結果、いくつかのフィールドには、情報がまったく含まれていないこともある。更に、所定の文書は、社内で作成されようと、外部から受け取られようと、人が目で検査して、その人が文書に関連する一以上のフィールドに適切な情報を入力することも想定される。

しかし、ファックス受信された新着イベントが、このような情報をほとんど備えていないことがある。新着ファックスは、例えば、送信側ファックス機から提供されるファクス発信元の電話番号、電話会社によって提供される発信元ＩＤ電話番号、受信日時、ページ数等を備えている。一以上のこれらのフィールドは存在していなくてもよく、又は情報を一つも含んでいなくてもよい。

フィールドと関連付けられていなくても、光学的文字認識（ＯＣＲ）技術を用いて、所定の単語、語句、数字等について、新着イベントを調査することも可能である。しかし、これは処理時間を増大させ、イベント通知の遅れの原因となる。また、所定の単語や語句は多くの文書に登場する可能性があり、これが不要で余分なイベント通知の原因となる可能性がある。ＯＣＲは使えないとまでは言わないが、好ましい実施形態ではないとだけは言える。

別の実施形態では、複数のイベント入力待ち行列があり、各イベント入力待ち行列は、特定の種類の新着イベント用である。例えば、一の入力待ち行列は、新着ファックスメッセージ用であってもよく、別の入力待ち行列は、新規の保険証書の発行に関するメモ用であってもよく、また別の入力待ち行列は、失効しそうな保険証書に関するメモ用であってもよく、さらに別の入力待ち行列は、失効したばかりの保険証書に関するメモ用であってもよく、そのまた別の入力待ち行列は、保留又は見込みの保険証書又はビジネス等に関するメモ用であってもよい。この実施形態では、複数のイベント作成部が存在し、各々が特定のイベント種類を作成し、各々が対応するイベント入力待ち行列にその特定イベントを提供することができる。この実施形態では、単一のイベント解析部とすることも可能であり、前記解析部は、新着イベントの種類を、どのイベント入力待ち行列にあるかによって自動的に「認識」する；又は複数のイベント解析部とすることも可能であり、各解析部は、少なくとも一つの、好ましくは唯一のイベント入力待ち行列用とされる。これは、種類が異なるイベントの「並列」処理を可能にし、いくつかの種類のイベントの送信を高速化される可能性はあるが、対応する入力待ち行列が長時間に亘って空く場合には、著しく利用率の低い資源となる可能性もある。

解析部１２は、新着イベントから関連データを読み出した後、加入者プロフィールへの照会として、データベース管理部１３に関連データを送信する。好ましくは、データベース管理部１３、イベント格納部１４、及び加入者プロフィール１５は、関係データベースとして実装される。次に、管理部１３は、加入者プロフィールに照会して、加入者が上記条件において興味を示したものを決定する。必須ではないが、好ましくは、速度と正確度のために、加入者プロフィールデータベースは、「条件」フィールド、又は照会インデックスを備えている。他の技術も使用可能であるが、使用する技術には関係なく、データベース管理部１３は、関心を持つ加入者のリストを作成する。

好ましくは、イベント解析部１２は、抽出されたデータ用語のすべてを含む単一の照会を、データベース管理部１３に送信する。この照会は、別の形態、すなわち、「用語Ａ」又は「用語Ｂ」又は「用語Ｃ」等であってもよく、データベース管理部１３は、別の形式で検索することによって照会を実行するようにプログラムされていてもよい。何れの場合でも、データベース管理部１３は、次に、加入者プロフィール１５を調査して、抽出されたデータ用語の何れかに適合するすべての加入者のリストを返信する。これは、加入者数が増えたときや、抽出されるデータ用語数が増えたときでさえ、各新着イベントについて、データベース管理部への単一の照会のみで足りる点において、優れた速度と拡張性を提供する。これは、抽出された各々のデータ用語に対して、データベース管理部１３へ別個に照会する必要がないためであり、また、抽出されたデータ用語に対して、各加入者プロフィールのデータベース管理部１３へ別個に照会する必要がないためである。しかし、好ましくはないが、他に取り得る形式においては、各加入者プロフィールに対し、データベース管理部へ別個に照会することが可能であり、又は、すべての加入者プロフィールにおいて、各々抽出されたデータ用語に対し、データベース管理部へ別個に照会することも可能である。

次に、データベース管理部１３は、このリスト及び対応するイベント通知データを、通知待ち行列１６に提供する。通知待ち行列１６は、関心を持つ加入者のリストを用いて、加入者プロフィール１５にアクセスし、関心を持つ加入者の選好を入手する。次に、通知待ち行列１６は、加入者の選好を用いて、関心を持つ加入者に何を送信するか、それをどのように送信するか、さらに、適切であれば、いつそれを送信するかを決定する。そして、通知待ち行列１６は、関心を持つ各加入者に、適切なイベント通知９を送信する。例えば、一人の加入者に対するイベント通知であれば、イベント解析部１２によって入手された関連データを単に述べる又は列挙する音声又はファックス電話連絡でもよく、別の加入者又は別の文書に対するイベント通知の場合には、特定の文書番号を参照するように加入者に注意喚起する電子メールメッセージや、関連文書等の一部又はすべてを示す会社のウェブポータルにおけるメッセージでもよい。加入者は、希望の発信方法を列挙することに加えて、電話を使う等の所定の発信オプションにおいて好ましい発信の時刻又は時間帯を列挙してもよいことが想起される。このようにして、好ましい時間になるまで電話連絡を遅らせるようにしてもよい。

別の実施形態では、イベント解析部１２は、加入者プロフィールデータベース１５から加入者プロフィールを直接入手し、通知待ち行列１６に加入者プロフィールのすべて又は一部を提供することとしてもよい。更に別の実施形態では、イベント解析部は、関心を持つ加入者のプロフィールの参照又はポインタを入手し、通知待ち行列１６にそのポインタを提供することもできる。更に別の実施形態では、データベース管理部は、関心を持つ加入者のプロフィールの参照又はポインタを通知待ち行列１６に提供することもできる。

別の実施形態では、複数の通知待ち行列が存在しており、各通知待ち行列は、特定の通知方法に関するものとされる。例えば、一つの通知待ち行列をファックス通知用とし、別の通知待ち行列を音声電話連絡用とし、別の通知待ち行列を電子メール用とし、別の通知待ち行列を会社の安全な個人用ウェブサイトページへの配信用等としてもよい。この実施形態では、各通知待ち行列は、単一のイベント種類の通知を提供可能であり、それは送信可能な関連データと、それをどのように形式化すべきか、を自動的に「認識」するが、それは、イベント通知データを送信するための特殊な方法に対処するように設計されているためである。これは、異なる方法の「並列」処理を可能にし、ある種の方法の形式の送出を高速化できるが、通知待ち行列が長時間、空であれば、利用率が低くなることもある。

イベント通知９が、一旦発行されると、関心がある人は、イベント通知をチェックし、その情報に基づいて、適切な又は希望する対応を取るか、又は特に対応しないことにする。

更に、イベント通知が送信される前に、好ましくは、イベントに機密情報がないかをチェックする。例えば、文書が社会保障番号フィールド、既往歴フィールド、又は内部に含まれる情報が機密又は機密の可能性がある他のフィールドを含み、すなわち安全でないリンクを介して送信すべきでない情報である場合に、この機密情報は安全でないリンクを介して加入者に送信される前に、イベント通知から削除される。イベント通知が安全なリンクを経由する場合は、機密情報をイベント通知から削除してもよいし、あるいはその情報を残すことを許容してもよい。このチェック及び削除は、必要に応じて、データベース管理部１３、通知待ち行列１６、又はそれらの二つに分割されたタスクの何れかによって実行される。

次に、典型的なイベント通知システムの処理を示す典型的なフローチャートである図２を参照する。新着イベントが発生すると（２００）、関連データを抽出し、好ましくは、イベントを格納する（２０５）。次に、新着イベントから抽出されたデータを用いて、加入者プロフィールデータベースに照会し（２１０）、関心を持つ加入者のリストを生成する。関心を持つ加入者について、加入者の選好を入手又は抽出する（２１５）。次に、それらの加入者の選好に基づいて、イベント通知を作成する（２２０）。次に、各加入者の選好に従って、関心を持つ加入者にイベント通知を送信する（２２５）。

上述したように、イベント通知の送信前に、そのイベントに機密情報がないかをチェックし、その情報は、イベント通知が安全でないリンクを介して送信される場合に削除される。

次に、加入者が条件と選好を入力する処理を示す典型的なフローチャートである図３を参照する。ログイン（３００）後、加入者は、イベント種類、例えばメモ又はファックス、又はサポートされるその他のイベント種類を選択する（３０５）。次に、加入者は、希望する条件、つまり条件の種類と条件データを選択する（３１０）。選択できる条件の種類と条件データは、選択したイベント種類に依存する。例えば、上記のように、ファックス用の条件の種類と条件データは、一般にメモ用の条件の種類と条件データとは異なっているが、それらはいくつかの共通したフィールドを備えていてもよい。また、「主題」の条件の種類は、「電話番号」又は「ファックス番号」の条件の種類とは異なる条件データを受付ける。例えば、加入者がイベント種類として「ファックス」を選択した場合、加入者は、オプションを提示され、ファックス用の条件の種類、例えば、送信ファックス機から提供されるファックス発信元電話番号、電話会社から提供される発信者ＩＤ電話番号、受信日時、ページ番号等を選択できる。次に、加入者は、希望する条件データを入力できる。例えば、加入者が「送信ファックス機によって提供されるファックス発信元電話番号」の条件種類を選択した場合、加入者は条件データとして希望するファックス発信元電話番号を入力できる。

次に、加入者は、希望するイベント通知方法、例えば、電話連絡、好ましくは音声合成を用いたもの、テキストメッセージ／ショートメッセージサービス（ＳＭＳ）、電子メール、及び／又は個人のウェブベースの会社ポータル等を選択することができる（３１５）。次に、加入者は、選択された方法に適したオプションを提示される。例えば、選択された方法が電話連絡であれば、加入者は、電話連絡をしてもよい（又はして欲しくない）時間及び／又は曜日、暦日等の範囲を選択できる。

加入者は、必要に応じて、複数のプロフィール入力をすることができる。例えば、加入者は、第１電話番号からファックス用の入力を行い、第２の異なる電話番号からファックス用の別の入力を行い、特定の保険証書番号を備えるメモ用の第三の入力を行い、特定事項を備えるメモ用の第四の入力を行い、特定の主題を備えるメモ用の第五の入力等をしてもよい。プロフィール入力の完了後、加入者は、プロフィール入力を完了したかどうかを尋ねられる（３２０）。完了していなければ、ステップ３０５に戻る。完了していれば、加入者はログアウトする（３２５）。

上述のように、加入者プロフィールには、「会社」入力、すなわち、会社によって指定されるものであって、加入者は操作を制限、又は操作できない入力を備えることとしてもよい。これらの会社入力は、一般に、加入者が入力するのと同じ方法で入力されるが、会社入力では、同じ情報を繰返し入力する必要はなく、一度に複数の加入者を指定することもできる。更に、加入者は、例えば、通知の方法又は時間を選択する等の会社入力における操作をしてもよく、又は加入者は、会社入力面の操作をしなくてもよい。

加入者プロフィールデータベース１５と、用いられるならば、加入者インデックスは、加入者の入力によって更新される（３３０）。これはログアウト後に発生するように示されているが、単に例示の簡略化のためであって、ある時点で、加入者プロフィールデータベース１５に入力が保存されることを示している。加入者プロフィールデータベース１５は、各プロフィール入力完了後に更新可能で、好ましくは更新される。加入者プロフィールデータベースの更新手続は、好ましくは、データベース管理部１３によって実行される。別の実施形態では、加入者プロフィールデータベースの更新手続は、別のプログラム又はプロセッサによって実行される。

好ましい実施形態では、通知システム１０は、メインフレームのデータベースシステム上のファームウェア及び／又はソフトウェアによって実装される。しかし、格納されるデータ量が過度でなければ、ＰＣベースのシステム上に実装してもよい。メインフレームシステムとＰＣシステムは、どちらも一つ以上のプロセッサ、揮発性及び不揮発性メモリ、電源、ユーザ入力装置（キーボード、マウス等）、ユーザ出力装置（表示装置、プリンタ等）、入出力ポート、ファームウェア、ソフトウェア等を備えていると理解される。

例示の明確化のため、図１では別個に示すが、イベント入力待ち行列１１、イベント解析部１２、加入者プロフィールデータベース１５、及び通知待ち行列１６は、好ましくは、データベース管理部１３等の関係データベース管理部を動作させるソフトウェア、及び／又はファームウェアと共に使用するためのプラグインソフトウェアモジュールとして実装される。これは、新着イベントが発生したとき、新着イベントのデータを用いて、例えばＳＱＬ（構造化照会言語）等によって加入者プロファイルデータベースに照会し、選択したデータと適合させるという点において、高速化と拡張性を実現する。これは、より迅速に関心のある加入者のリストを返信して、加入者数を著しく増加させることができ、イベント通知処理の速度をあまり低下させず、高速な計算システムを使う必要もないという点において、拡張性を実現する。高速化と拡張性のためには好ましくはないが、各加入者プロフィールの基準と、新着イベントに含まれる関連データの各々を実際に比較することも可能である。

Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ（登録商標）等の一部の従来技術のプログラムでは、電子メールメッセージの転送や他の処置を実現できると理解される。しかしながら、電子メールメッセージは、既に意図する相手に特に宛てられたものであるが、通知システムにおいて、会社のメモ又は会社の代表ファックス番号へのファックス等の新着イベントは、特定の誰かに宛てられたものではなくてもよい。従って、通知システムには、既知の従来技術のシステムからの著しい変更と改善がなされている。

実際の実装に関するいくつかの具体例は、以下の通りである。

イベントデータは、すべての関連データ環境、つまり一般にメインフレームベースのＤＢ２（ＩＢＭ Ｄａｔａｂｅｓｅ ２（登録商標））データベースと、ＶＳＡＭ（ＩＢＭ Ｖｉｒｔｕａｌ Ｓｔｏｒａｇｅ Ａｃｃｅｓ Ｍｅｔｈｏｄ）ファイルから取り出される。

システムは、単層方式で実装することも可能であり、可能であるが好ましい方式ではなく、なぜならば、選ばれたわずかな人だけに役立つ、及び／又は、時期を逸した通知ではなく、大部分の外務員にタイミングよく役立つまでシステムを拡張するため、例えば「新規ビジネス」処理ソフトウェアや、クレーム入力処理ソフトウェアの基礎となるソフトウェアの大幅な修正を必要とする可能性があるからである。更に、このような修正は、困難であり、例えばメインフレームアプリケーションのような影響を受けるエリアにおいて、専門性を備えた専任スタッフを必要とする可能性があり、その機能を検証し、他のソフトウェア機能又は速度に悪影響を及ぼさないことを確認するために、かなりの承認処理、共同作業、及び試験運転が必要になる。

好ましくは、モジュラ設計方式を用いて、新規のプラットフォーム及び／又はデータベースへの移植性を保証し、すべての会社データ格納部の拡張性を提供する。このモジュラ設計方式も、メインフレームＤＢ２とＶＳＡＭデータ格納部からのバックエンドデータの検索に含まれる課題に対処する。

加入者にリアルタイム情報を提供することによって、加入者との迅速な連携が実現され、これはコールセンタのポーリングを低減し、生産性を向上し、コストを削減する。更に、イベントデータは、好ましくは中央に格納されるので、時間が経つと、このイベントデータから、イベント集合及びそのレポートを容易にかつ効率的に作成できる。

また、イベント通知システムは、所定の閾値を超えたときに、加入者への通知を可能にし、このような加入者のために報告を作成し、現在の業績及び傾向を知らせるようにする。これは、より知識のある有能な外務員、負荷の少ないコールセンタ、及びリアルタイム情報のより迅速な管理伝達方法をもたらす。

好ましくは、通知システムは、メインフレーム層、中間層及びプレゼンテーション層という三層又は三つのサブシステムを備えている。

メインフレーム層は、イベントを取り出すバックエンドシステムを含む。実際の実装形態では、これらのシステムは、主にＤＢ２データベースとＶＳＡＭデータ格納部であり、メインフレームのＳ／３９０（ｚ／ＯＳ）ＬＰＡＲｓ（Ｌｏｇｉｃａｌ ＰＡＲｔｉｔｉｏｎｓ）上で動作する。他の実装形態も可能であり、そうすべき正当な理由が他になければ、メインフレームシステムの更新費用を避けるために好ましい場合もある。

プレゼンテーション層は、クロスプラットフォームポータル、例えばＰｌｕｍｔｒｅｅ Ｓｏｆｔｗａｒｅ（登録商標）によって提供されるクロスプラットフォームポータルを用いるアプリケーションサーバ上で動かされる。

中間層は、好ましくは、イベント処理用のフレームワークを提供し、予約購読に従ってイベントを送り、プレゼンテーション層用のポートレットを出して、カプセル化されたアプリケーションプログラミングインタフェース（ＡＰＩ）を介して、様々なイベント送出方法へのアクセスを提供する。中間層の処理動作は、主にコアＡＰＩを機能させる。一つの実装形態では、三つのコアＡＰＩがあり、各々がプラグインベースとなる。この設計は、新規の送出方法、データソース及び報告の種類が追加プラグインとして追加可能となり、診断過程でアプリケーション全体を再評価、認定する必要性を生じない点において有利である。好ましくは、中間層は、広範囲に及ぶ利用性をもたらすため、一般的な意味でプラットフォームにはとらわれないが、速度を高めて、処理時間を短縮するために、特定のプラットフォーム用に容易に最適化して、プラットフォーム上で既に利用可能な機能を有利に利用できることが好ましい。この構成では、中間層は、メインフレームベースのデータ格納部との簡便な統合を実現する。例えば、一つの実装形態では、例えばＩＢＭのＷｅｂＳｐｈｅｒｅ ＭＱ（登録商標）のようなネットワーク通信技術が、ＷｅｂＳｐｈｅｒｅ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ及びＪａｖａ（登録商標） Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅｓと共に用いられる。この実装形態は、必然的に厳重な管理下におかれるであろうリモートシステムとの相互作用のオーバーヘッドに制約されないシステムプログラミング開発を可能にする。他の可能で好ましいプラットフォームとしては、Ｉｎｔｅｌ ＮＶｉｎｄｏｗｓＩＤＢ２（登録商標）プラットフォーム及びｐＳｅｒｉｅｓ ＩＡＩＸＩＤＢ２（登録商標）プラットフォームがある。

バックエンドＡＰＩは、待ち行列ベースのデータ検索層であり、既存のメインフレームＤＢ２及びＶＳＡＭデータ格納部と接続する。この層は、知的分類戦略（インテリジェントクラシフィケーションストラテジー）を組み込んでおり、下層のデータベースから関連データを検索して、統合された形式でデータを引き出す。

イベントＡＰＩは、種々のイベントをＡＰＩへ配信するプッシュ法データ伝達部であり、加入者にイベントを実際に配信することを可能にする。好ましくは、この点で、イベントは、既に事前処理されており、受信側のイベント配信ＡＰＩは、更なる処理をせずに、適切な媒体を介してデータを渡すだけで良い。

報告ＡＰＩは、好ましくは、専用プラグインの配列を備える汎用層である。各プラグインは、特定の報告の種類の特徴を定義し、必要に応じてデータベースとやり取りする。次に、報告は、静的報告機構又はアプリケーションサーバの何れかを通じて、要求元に汎用層を介して戻される。

システムは、例えば、Ｊａｖａ（登録商標） Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅｓ（ＪＭＳ）をサポートするＪａｖａ（登録商標）２ Ｐｌａｔｆｏｒｍ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ １（Ｊ２ＥＥ１）、Ｅｎｔｅｒｐｉｒｓｅ Ｊａｖａ（登録商標） Ｂｅａｎｓ（ＥＪＢ）及びＷｅｂＳｐｈｅｒｅ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ内のＷｅｂＳｐｈｅｒｅ ＭＱ統合を用いて実装してもよい。これらの技術は、拡張可能で保守可能なコードを可能とし、それが実装及び既存のシステムとの統合を簡略化する。ストアドプロシージャ形態におけるデータベース機能は、データベースと大量の一時データを備えるアプリケーションサーバとの相互接続を妨げることなく、データベースサーバ内で生じるデータ境界計算を可能にする。従って、この設計は、データベースとアプリケーションサーバのクラスタ化を実現する。Ｊ２ＥＥフレームワークは、すべての必要な待ち行列、ＪＭＳプロバイダ及びデータオブジェクトへの容易なアクセスを維持しながら、アプリケーションレベルでの滑らかでシームレスなクラスタ化を可能にする。データベースサーバは、高度にクラスタ化可能であるため、データベースにあるロジックは、必要な場合、クラスタ化されたデータベースサーバを介してデータサイズを調整することができる。対象のデータベースとプラットフォーム（ｐＳｅｒｉｅｓ １ＡＩＸＩＤＢ２とＩｎｔｅｌ Ｗｉｎｄｏｗｓ（登録商標） ＳＱＬ Ｓｅｒｖｅｒ）はどちらも、このようなクラスタリング配列をサポートする。

中間層のメインサブシステムには、データベース自体と、三つの主要なＡＰＩ（バックエンド、イベント、及び報告）と、制御部と、Ｐｌｕｍｔｒｅｅポートレットが含まれる。データは、メインフレームベースのＤＢ２とＶＳＡＭデータ格納部から、バックエンドＡＰＩと接続するプラグインの一部であるＭＱｕｅｕｅを介してシステムに届く。このデータは、下層のデータベース表現の外観であるＥｎｔｉｔｙ Ｂｅａｎｓに送られる前に、同様にプラグインの一部であるＭｅｓｓａｇｅ Ｄｒｉｖｅｎ Ｂｅａｎｓ（ＭＤＢ）を介して処理される。データが、Ｅｎｔｉｔｙ Ｂｅａｎｓを介してデータベースに一旦格納されると、ＭＤＢは、制御を制御部オブジェクトに送るが、前記制御部オブジェクトはＳｔａｔｅｌｅｓｓ Ｓｅｓｓｉｏｎ Ｂｅａｎｓ（ＳＳＢ）として実装されている。ＳＳＢは適切なデータベースのストアドプロシージャを呼び出し、もしあれば、新規データを踏まえて通知を送るべき予約購読を決定し、必要ならば、出力通知用の制御ポイントとして機能する出力待ち行列に、ＪＭＳを介してメッセージを送信する。出力待ち行列は、種々の通知配信方法を列挙し、通知される予約購読にとって一つの適切な送信方法を呼び出すことができるＭＤＢである。通知配信方法は、適切な外部記述通知ＡＰＩと接続するＳＳＢを持つプラグインである。

このデータのメインフローを増大させると、二つの他の主要なサブシステムが非同期的に動作して、設定の修正、購読の作成、報告の作成、及びポータル視界を提供する。ポートレット部は、ＳｔｒｕｔｓベースのサーブレットとＪＳＰ構造を用いて、保守可能なポートレットアプリケーションを可能にする。これらのポートレットは、必要であれば、エンティティビーンズによってデータベースを修正可能なＳＳＢを介してシステムバランスと相互作用する。ポートレットは、本来、プラガブルであるため、実装用の特定のプラグインインタフェースやＡＰＩは存在しない。報告ＡＰＩは、データウェアハウス用の機能を用いて、データベースからの報告を非同期作成することができる。

データベーススキーマは、ストアドプロシージャを効率的で、小型でかつ、保守可能にする。ストアドプロシージャは、新規のイベント種類又は他の新規の機能が希望されている場合に、例えば、管理コンソールウェブインタフェースを用いて作成してもよい。このような変更用の管理コンソールの使用は、現在セットされているストアドプロシージャの安定性を保証し、更にスキーマの一貫しない変更の可能性を低減する安全性を提供する。各ストアドプロシージャは、所定のパラメータを満足する同種類（動作させるためにストアドプロシージャを作成する加入の種類）のすべての予約購読を配置する単一機能を備える。この制限範囲は、ストアドプロシージャが高速かつ堅牢で、それを維持することを保証し、大容量イベント通知システムにおいて必要とされる性能及び速度をもたらす。

イベントは、好ましくは、イベント種類といくつかのパラメータの変数からなる。イベントの詳細についての情報を提供する、これらのパラメータは、購読者が気にかけているイベントを、フィルタにかける機構である。イベント種類は、主観的な意味とイベントのクラス名、例えば「新規ビジネス−保険証書がたった今発行された」を定義するとともに、正当なパラメータのセットを指定するテンプレートである。そして、このイベント種類は、例えば、パラメータテンプレートして定義される保険証書番号やグループ番号等の正当なパラメータのセットを備える。これらのパラメータテンプレートは、イベントテンプレート中の名前及び位置とともに、値の種類及び値の主観的意味を定義する。

予約購読は，ユーザによって作成される選択のセットであって、通知が作成されるべきイベントを定義する。各予約購読は、好ましくは単一のイベント種類に制限されるが、そのイベント種類のパラメータの何れか又はすべてにおける様々な条件によって、フィルタにかけてもよい。予約購読は、ユーザが、フィルタパラメータを容易に選択及び定義し、予約購読がイベントによって十分となるときに割り当てられる通知の種類を決定することが可能となるポートレットインタフェースを介して作成される。

イベント通知は、出力プラグインモジュール又はモジュールを介して複数の方法で作成される。一つの実装形態では、サポートされる通知方法は、ポータル通知であって、それらには限定されるものではないが、電子メール、ＶＯＸ（音声合成）及びＳＭＳを含む。各通知方法は、適切なイベント通知方法を定義し、好ましくは、出力待ち行列によって呼び出されることができる関連プラグインを備えている。入力プラグインは、初期の位置からプラグイン内にデータを移動する方法を作成し、データベースへの出力に適するようにデータをフィルタ処理し、最終的にデータアクセス層方法を呼び出してデータベースに新規イベントを追加することによって定義される。この処置は、制御部を起動し、イベントを調査し、予約購読が新規イベントに適合するかどうかをストアドプロシージャに評価させる。

独自のイベント通知システムの一態様は、制御部において適用可能なイベントを動的に選択し、これらのイベントを、出力プラグインを介して加入者に渡すことによって、バックエンドデータ源からシステムを介してイベントの流れを制御する方式である。制御部は、データベースに格納された加入に対して、新着イベントを適合させることによりイベントの発送を処理する。これらの予約購読は、予約購読を作成した人と、その人が加入したイベント種類と、人が受け取るイベントをフィルタにかけるために使いたい選択基準とを記録する。予約購読は、規格化した形態でデータベース内に格納されて、各選択基準は、イベントに対する照会に対して動的に結合される別個の存在となる。これらの照会は、データベースにストアドプロシージャとして実装され、データベースは、すべての加入に対するすべての関連要素を結合し、新着メッセージについて通知されるべき加入のリストを返す単一の論理的ＳＱＬ照会のみを含む。このイベント毎の単一の照会は、システムが最小限のデータベース性能要件で、かなり大量のイベントを処理することができる。この整合に関与するストアドプロシージャは、新規のイベント種類が作成されたとき、又は過去のイベント種類が削除されたときに、特定のイベント種類に関するメタデータが変更される都度、システムによって実行される。ストアドプロシージャは、イベント定義（イベント種類は何か、どのバラメータを備えているか、一意識別子は何か等）で構成されるので、手動修正する必要はない。これらの作成されたストアドプロシージャは、最新のイベントについて通知するために、加入者リストを決定するように制御部が呼び出すものである。

ストアドプロシージャの使用によって得られる複数の利点のうち、二つは、イベントについてのメタデータが変更されたときに、ストアドプロシージャの作成又は更新するために人の介入が不要であることと、ストアドプロシージャ全体が、論理的に単一のＳＱＬ照会のみであり、一組の反復ステップでないということである。これによって、データベースが照会を自動的に最適化することでき、他の標準的な照会と同様に、その動作により、標準的なデータベース性能改善機能、例えば、インデックス、パーティショニング、及び透過クラスタリングを利用してもよい。

本明細書で記述される、及び／又は添付図面に描かれる、プロセス記述、ステップ、又はフロー図又はデータフロー図におけるブロックは、プロセスの具体的な論理機能又はステップを実装するための、一以上の実行可能な命令を含むコードのモジュール、セグメント、又は一部を潜在的に表したものと理解されるべきである。別の実装形態は、本明細書で記述されるシステム及び方法の好ましい実施形態の範囲内に含まれ、ステップ又は機能を削除し、図示又は議論されたものとは異なる順序で実行し、含まれる機能に依存して、並列に、実質的に並列に、又は連続的に、又は逆順に実行することもできる。

例えば「できる」、「可能である」、「可能性がある」、「してもよい」等の条件付きの言葉は、他に具体的に言及されない限り、又は用いられる文脈内で他に理解されない限り、一般に、所定の実施形態が選択的に含まれることを告げたものとみなされ、他の実施形態は、所定の機能、要素及び／又はステップを含まないとみなされる。従って、このような条件付き言語は、一般に、あらゆる実装形態又は実施形態に対して、それらの機能、要素及び／又はステップが必須ではないことを示す。

従来技術では得られない、種々の有用な態様、利点、性能、実施形態及び／又は機能を上述した。更に、これらの種々の態様、利点、性能、実施形態、及び／又は機能は、希望する結果を得るために、独立して、又は組み合せて使用してもよい。具体的に希望する態様、利点、性能、及び／又は機能を得るために、すべての態様、利点、性能、実施形態及び／又は機能を単一の実装形態に組み込む必要はない。

これらの態様、利点、性能、実施形態及び／又は機能の他の変形は、図面及び詳細な説明を調べることで、当業者に示唆され、すべてのこのような変形は、添付の請求項によって定義されるように、本発明の範囲に含まれている。従って、本発明の範囲は、下記請求項によってのみ制限される。

Claims (20)

1. 新着イベントの発生を加入者に通知する方法であって、
   加入者プロフィールを受信及び格納し、加入者プロフィールは、加入者が通知を希望する少なくとも一つの特定イベントと、加入者が好む通知手段と、に関するデータを含んでなり；
   前記加入者プロフィールをデータベースに格納し；
   新着イベントを受信し；
   新着イベントからデータを抽出し；
   抽出されたデータに関してデータベースに照会し、加入者プロフィールが抽出されたデータの少なくとも一項目を含んでなる、少なくとも一人の加入者を特定し；
   特定された加入者が好む通知手段をデータベースから決定し；
   特定された加入者に対して決められている手段に従って、新着イベント用のイベント通知を作成し；
   決められた手段に従って、特定された加入者にイベント通知を送信する方法。
2. イベントデータベースに新着イベントを格納することを更に含んでなる請求項１記載の方法。
3. 少なくとも一つの指定されたイベントに関するデータが、ファックス又はメモの少なくとも一つを含んでなる請求項１記載の方法。
4. 少なくとも一つの指定されたイベントに関するデータは、条件を含んでなり、前記条件は、主題、場所、イベント種類、保険証書番号、電話番号、又は事務所を含むグループから選択される請求項１記載の方法。
5. 加入者が希望する通知手段が、電話連絡、テキストメッセージ、ショートメッセージサービス、電子メール、又は会社ポータルを含むグループから選択される請求項１記載の方法。
6. データベースサーバを用いる方法を実装することを更に含んでなる請求項１記載の方法。
7. データベースサーバが予め決められたプログラムを実行し、その方法は、予め決められたプログラムの下で実行されるプラグインソフトウェアモジュールを用いて実装されている請求項６記載の方法。
8. データベースへの照会は、前記データベースへの単一の照会として、抽出されたデータのすべてを送信する請求項１記載の方法。
9. データベースへの照会は、前記データベースへの単一の照会として、抽出されたデータのすべてを送信し、加入者プロフィールが抽出されたデータの少なくとも一項目を含むすべての加入者を特定する請求項１記載の方法。
10. 手段の決定は、それぞれ特定された加入者が好む通知手段をデータベースから決定することを含んでなり、
    イベント通知の送信は、それぞれ個別の特定された加入者に対して決められた手段に従って、それぞれ特定された加入者にイベント通知を送信することを含んでなる請求項９記載の方法。
11. 指定されたイベントの発生を加入者に通知する装置であって、
    加入者プロフィールデータベースを格納し、加入者プロフィールは、加入者が通知されることを希望する少なくとも一つの指定したイベントと、加入者が好む通知手段に関するデータからなるメモリ；
    新着イベントを受信し、新着イベントからデータを抽出するイベント入力待ち行列及び解析部；
    抽出されたデータを受信し、加入者プロフィールデータベースに照会し、加入者プロフィールが抽出されたデータの少なくとも一項目を含む少なくとも一人の加入者を特定し、特定された加入者が好む通知手段を決定するデータベース管理部；
    特定された加入者に対して決められた手段に従って、新着イベント用のイベント通知を作成し、決定された手段に従って特定された加入者にイベント通知を送信する通知待ち行列からなる装置。
12. 更に、メモリがイベントデータベースに新着イベントを格納する請求項１１記載の装置。
13. イベント入力待ち行列及び解析部が、少なくとも新着イベントがファックスかメモかを判断するために作動している請求項１１記載の装置。
14. 一加入者の加入者プロフィールが少なくとも一つの指定されたイベントに関する条件を指定してするものであって、前記条件が、主題、場所、イベント種類、保険証書番号、電話番号、又は事務所を含むグループから選択される請求項１１記載の装置。
15. 一加入者の加入者プロフィールが、前記加入者が希望する通知手段を指定するものであって、前記手段が、電話連絡、テキストメッセージ、ショートメッセージサービス、電子メール、又は会社ポータルを含むグループから選択される請求項１１記載の装置。
16. メモリが、予め決められたプログラムと少なくとも一つのプラグインソフトウェアモジュールを含み、データベース管理部が、前記予め決められたプログラムを実行し、前記データベース管理部が、プラグインソフトウェアモジュールを実行して、イベント入力待ち行列とイベント解析部を実装する請求項１１記載の装置。
17. メモリが、予め決められたプログラムと少なくとも一つのプラグインソフトウェアモジュールを含み、データベース管理部が、前記予め決められたプログラムを実行し、前記データベース管理部が、プラグインソフトウェアモジュールを実行して、通知待ち行列を実装する請求項１１記載の装置。
18. データベース管理部が、加入者プロフィールデータベースの単一の照会として、抽出されたデータをすべて送信することによって、加入者プロフィールデータベースに照会するように動作可能である請求項１１記載の装置。
19. データベース管理部が、加入者プロフィールデータベースの単一の照会として、抽出されたデータをすべて送信することによって、加入者プロフィールデータベースに照会するように、かつ、加入者プロフィールに抽出されたデータの少なくとも一項目を含むすべての加入者を特定するように動作可能である請求項１１記載の装置。
20. データベース管理部が、それぞれ特定された加入者が好む通知手段を、加入者プロフィールデータベースから決定するように動作可能であり、
    イベント通知待ち行列が、それぞれ個別の特定された加入者に対して決定された手段に従って、それぞれ特定された加入者にイベント通知を送信するように動作可能である請求項１９記載の装置。

Images