JP2011215702A - 代行装置、代行方法及び代行システム - Google Patents

Abstract

【課題】関係する相手先の情報を管理し、自己や相手先に所定の事象が発生した場合に、当該相手先に対して行うべき処理として設定された処理を代行してもらえるようにする。
【解決手段】代行サーバ１の利用が可能な１以上のユーザのユーザデータと、各ユーザの１以上の相手先のそれぞれのデータであって当該相手先に対して行うべき処理に関する指示情報が含まれるプロファイルデータとをユーザ毎にプロファイルＤＢ１０４で管理する。ユーザや相手先について、住所変更、昇進、死亡などの所定の事象の発生をプロファイル保守部１０２が検知すると、ユーザが当該相手先に対して行うべき処理を、対応する相手先のプロファイルデータに応じて儀礼代行処理部１０３が代行するように処理する。
【選択図】図２

Description

この発明は、例えば、ビジネス（仕事）関係の相手先や友人や親類などの個人関係の相手先等に対して、自己や相手先に所定の事象（事柄）が発生した場合に、所定の処理を代行して行ってもらえるようにする装置、方法およびシステムに関する。

ビジネスの場面では名刺交換は頻繁に行われ、受け取って名刺はビジネス上の重要な資産となる。しかし、紙の名刺は管理が大変で、組織変更等によりその情報内容がすぐに陳腐化してしまう場合も少なくない。このため、社員が受け取った名刺情報を、社内で電子化して一元管理して多数の社員によって共有することができると共に、組織変更等に応じた情報の変更等にも比較的に簡単に対応できるようにすることが考えられている。

例えば、後に記す特許文献１には、名刺情報の管理を一元化し、名刺情報の電子化やメンテナンスの手間を削減し、名刺情報を適切に管理していることを保証できるようにする名刺管理装置等に関する発明が開示されている。さらに、管理している名刺情報を、年賀状や暑中見舞いの郵送やお中元やお歳暮の発送などに利用することなども考えられている。

特開２００８−０２２３４２号公報

ところで、個人が関係する相手先は、ビジネス関係だけでなく、友人、知人、親類、更には所属しているサークルや加入している団体、種々の契約関係にある相手先（例えば、クレジット会社や電話会社）など様々な相手先が存在する。これらビジネス関係以外の関係の相手先についても一元的に管理できた方が便利な場合もある。

また、相手先に関する情報を精度よく保つためには、当該情報を登録したユーザが知り得る範囲でメンテナンスするだけでなく、他の経路を通じても相手先に関する情報の変更等が生じる場合を検知できたほうが好ましい。そして、相手先に関する情報をより有効に活用することによって、例えば、種々の通知や儀礼などの相手先に対して行うべき処理を自分自身が行うようにしなくても確実に行えるようにすることが望まれている。

以上の点に鑑み、この発明は、関係する相手先の情報を精度よくかつ効率的に管理し、自己や自己と関係する相手先に所定の事象が発生した場合に、当該相手先に対して行うべき処理を自己に代わって適切に行えるようにすることを目的とする。

上記課題を解決するため、請求項１に記載の発明の処理代行装置は、
１以上のユーザについてのユーザデータを記憶する第１の記憶手段と、
各ユーザの１以上の相手先のそれぞれについてのデータであって、各相手先に対して設定された処理に関する指示情報を含むプロファイルデータをユーザ毎に記憶する第２の記憶手段と、
前記ユーザデータにより特定されるユーザあるいは前記プロファイルデータにより特定される相手先に関する事象の発生を検知する検知手段と、
前記検知手段により事象の発生が検知された場合に、対応する相手先の前記プロファイルデータの前記指示情報に基づいて、当該相手先に対して設定された処理を実行するようにする処理手段と
を備えることを特徴とする。

請求項１に記載の発明の代行装置によれば、当該代行装置の利用が可能な１以上のユーザのユーザデータが第１の記憶手段で管理され、各ユーザの１以上の相手先に関するプロファイルデータがユーザ毎に第２の記憶手段で管理される。第２の記憶手段で管理される各プロファイルデータには、当該プロファイルデータにより特定される相手先に対して行うべき処理として設定された処理に関する指示情報が含まれる。

そして、ユーザデータにより特定されるユーザやプロファイルデータにより特定される相手先について、例えば、住所変更、昇進、死亡などの所定の事象の発生が検知手段により検知されると、ユーザが当該相手先に対して行うべき処理（設定された処理）を、対応する相手先のプロファイルデータの指示情報に応じて処理手段により代行するようにされる。

これにより、ユーザデータと相手先のプロファイルデータとを管理すると共に、ユーザ自身の手を煩わせることなく、ユーザやユーザと関係する相手先に所定の事象が発生した場合に、ユーザ自身が行うべき相手先に対する処理を、適切に代行することができるようにされる。

この発明によれば、関係する相手先の情報を精度よくかつ効率的に管理し、自己や自己と関係する相手先に所定の事象が発生した場合に、関係する相手先に対して行うべき処理を自己に代わって適切に行えるようにすることができる。

この発明による代行システムの一実施の形態を説明するための図である。 図１に示した代行サーバ１の構成例を説明するためのブロック図である。 プロファイルＤＢ１０４におけるデータの管理構造の一例を説明するための図である。 ユーザデータファイル４１に格納されるユーザデータ４１１の例について説明するための図である。 ビジネス関係相手先ファイル４２（１）、４２（２）、…に格納されるビジネス先データ４２−Ｘの例について説明するための図である。 個人関係相手先ファイル４３（１）、４３（２）、…に格納される個人相手先データ４３−Ｘの例について説明するための図である。 所属・加入先ファイル４４（１）、４４（２）、…に格納される所属加入先データ４４−Ｘの例について説明するための図である。 プロファイル保守部１０２がユーザや相手先に関する所定の事象の発生を検知する経路（１）〜（４）について説明するための図である。 図８の（１）、（３）の経路を通じてユーザや相手先に関する所定の事象の発生を検知する処理を説明するためのフローチャートである。 図８の（２）の経路を通じてユーザや相手先に関する所定の事象の発生を検知する処理を説明するためのフローチャートである。 図８の（４）の経路を通じてユーザや相手先に関する所定の事象の発生を検知する処理を説明するためのフローチャートである。 図８の（４）の経路を通じてユーザや相手先に関する所定の事象の発生を検知する処理を説明するためのフローチャートである。 代行サーバ１の主に儀礼代行処理部１０３によって行われる儀礼等の代行処理について説明するためのフローチャートである。

以下、図を参照しながら、この発明の装置、方法、システムの一実施の形態について説明する。

［システムの概要］
図１は、この発明による代行システムの一実施の形態を説明するための図である。この実施の形態の代行システムは、プロファイル管理及び儀礼代行サーバ（以下、代行サーバと略称する。）１と、端末装置２（１）、２（２）、…や携帯端末装置３（１）、…が、通信ネットワーク１００を通じて接続されて形成されている。

ここで、端末装置２（１）、２（２）、…や携帯端末装置３（１）、…は、代行サーバ１を運営する会社や団体などと予め契約を結ぶことによって、代行サーバ１の利用が認められたユーザ（代行サーバ１の会員となったユーザ）によって使用されるものである。このため、この実施の形態において、「ユーザ」という文言は、代行サーバ１の利用が許可された者を意味する。

そして、具体的に、端末装置２（１）、２（２）、…は通信機能を備えたパーソナルコンピュータであり、携帯端末装置３（１）、…は例えば携帯電話端末である。このため、携帯端末装置３（１）は、携帯電話網の基地局４（１）等を通じて通信ネットワーク１００に接続される。なお、図１においては、端末装置２（１）、２（２）および携帯端末装置３（１）しか示していないが、代行サーバ１の利用が許可された多数のユーザの端末装置や携帯端末装置が通信ネットワーク１００を通じて代行サーバ１にアクセスすることができるようにされる。また、以下においては、端末装置２（１）、２（２）、…を総称して端末装置２と呼び、携帯端末装置３（１）、…を総称して携帯端末装置３と言う場合もある。

また、代行サーバ１を運営する会社や団体との契約は、通信ネットワーク１００を通じて契約の申し込みを行ったり、電話や郵送により契約の申し込みを行ったり、当該会社や団体の事務所等に出向いて契約の申し込みを行ったりすることにより行われる。そして、契約が成立すると、識別ＩＤやパスワードなどの必要な情報がユーザに付与されて、ユーザの端末装置や携帯端末装置を通じて代行サーバ１にアクセスすることができるようにされる。

このように、代行サーバ１の利用が認められたユーザの端末装置２（１）、２（２）、…や携帯端末装置３（１）、…から代行サーバ１へアクセスする場合には、ユーザＩＤやパスワードなどの情報が必要になる。しかし、この実施の形態において代行サーバ１のおける代行サーバ１の利用が可能なユーザか否かの認証処理は例えば従来の技術を用いて行うものとし、認証処理の詳細な説明については省略する。

そして、この実施の形態において、通信ネットワーク１００は主にインターネットを想定しているが、インターネットへの接続経路として、一部にＰＳＴＮやＩＳＤＮ、基地局を含む携帯電話網などをも含んでいる。なお、ＰＳＴＮは公衆交換電話網を意味し、Public Switched Telephone Networksの略称である。また、ＩＳＤＮはサービス総合デジタル網を意味し、Integrated Services Digital Networkの略称である。

さらに、通信ネットワーク１００上には、図１に示したように、種々の会社や団体、あるいは個人が運営するＷｅｂページ５（１）、…、Ｗｅｂページ６（１）、…などがサーバ装置に格納されて開示されている。また、通信ネットワーク１００には、印刷会社のサーバ７、デパートのサーバ８、オペレータ会社のサーバ９、電話会社のサーバ１０など、種々の会社がサービスを提供するために設けたサーバ装置も接続されている。

そして、ユーザが使用する端末装置２（１）、２（２）、…や携帯端末装置３（１）、…は、通信ネットワーク１００を介して種々の通信処理を行うことができる。すなわち、端末装置２（１）、２（２）、…や携帯端末装置３（１）、…は、通信ネットワーク１００上に開示されたＷｅｂページの閲覧、サーバ装置からの情報のダウンロード、サーバ装置への情報のアップロード、電子メールの送受信などを行うことができる。つまり、ユーザが使用する端末装置２（１）、２（２）、…や携帯端末装置３（１）、…は、目的とするサーバ装置などに対して要求や情報を送信する送信手段と、当該サーバ装置などからの情報を受信する受信手段とを備えたものである。

そして、一般に、端末装置２（１）、２（２）、…には、例えば、得意先リスト（顧客リスト）等のビジネス上関係のある相手先についての情報を登録したデータや、ユーザに関係する種々の相手先の電話番号、電子メールアドレス、住所等を登録したいわゆるアドレス帳データ等が記憶保持されている。また、携帯端末装置３（１）、…にも、相手先の電話番号、電子メールアドレス、住所等を登録したいわゆるアドレス帳データ等が記憶保持されている。

このように、端末装置２（１）、２（２）、…や携帯端末装置３（１）、…等は、これらの使用者であるユーザが関係する種々の相手先についてのプロファイルデータが登録されて、これを利用することができるようにされている。しかし、この実施の形態の代行システムにおいては、端末装置２（１）、２（２）、…や携帯端末装置３（１）、…が個別に保持している種々の相手先についてのプロファイルデータを、代行サーバ１に送信して代行サーバ１において一元的に登録管理することができるようにしている。

通常、端末装置２（１）、２（２）、…や携帯端末装置３（１）、…のそれぞれでは、相手先についてのプロファイルデータを種々の形式で保持している。そこで、この実施の形態の代行サーバ１は、ユーザの端末装置２（１）、２（２）、…や携帯端末装置３（１）、…からの種々の形式の相手先についてのプロファイルデータを受け付けて、データ形式を統一し、所定の記憶部に記憶して管理することができるようにしている。すなわち、代行サーバ１は、通信ネットワーク１００を通じて接続される種々の端末装置から、例えば、エクセルシートやＣＳＶ（Comma Separated Values）形式等の種々の形式のデータを受け付けてインポートすることができる。

また、代行サーバ１は、端末装置２（１）、２（２）、…や携帯端末装置３（１）、…のユーザに関するユーザデータをも受け付けてこれを管理する。また、代行サーバ１は、ユーザデータによって特定されるユーザ毎に、当該ユーザと関係のある相手先のプロファイルデータを管理するようにしている。すなわち、ユーザデータと当該ユーザデータにより特定されるユーザに関係する相手先のプロファイルデータとは対応付けされて管理されている。したがって、異なるユーザが、同じ相手先を得意先としている場合などにおいては、当該異なるユーザ同士は同じ相手先についてのプロファイルデータを有することになる。しかし、この場合、相手先のプロファイルデータの内容までが全て同じと言うわけではない。

そして、代行サーバ１で管理されるユーザデータは、詳しくは後述するが、代行サーバ１の利用可能なユーザを特定することが可能なデータであり、例えば、当該ユーザの識別ＩＤ、氏名、住所、電話番号などの情報や、勤務先に関する情報等からなるものである。また、代行サーバ１においてユーザ毎に管理される各ユーザに関係する相手先についてのプロファイルデータは、相手先の氏名、住所、電話番号、電子メールアドレスといった情報の他に、種々の儀礼などのその相手先に対して行うべき処理として設定された処理に関する指示情報をも含むものである。

ここで、「儀礼などのその相手先に対して行うべき処理として設定された処理に関する指示情報」は、詳しくは後述もするが、その一例を示すと以下のようなものがある。例えば、年賀状や暑中見舞を送るか否か、お中元やお歳暮をどうするか、誕生日や昇進などのお祝いをどうするか、さらには、当該相手先が亡くなられた（死亡した）場合にはどのように対応するかなどといったことを指示するものである。

このため、代行サーバ１を利用可能なユーザは、自己の端末装置などを通じて自己と関係のある相手先のプロファイルデータを代行サーバ１に登録するに際して不足している情報がある場合には、必要な情報を追加することができるようにされる。この場合、代行サーバ１から提供される入力画面を通じて、比較的に簡単な操作を行うことによって不足している情報の追加入力を行うことができるようにされる。

そして、代行サーバ１は、自己が管理するユーザデータにより特定されるユーザや自己が管理するプロファイルデータにより特定される相手先について、所定の事象（事柄）が発生したことを検知した場合に、プロファイルデータの指示情報に応じてユーザが行うべき処理（設定された処理）を代行して実行することができるものである。

ここで所定の事象の発生は、例えば、年賀状や暑中見舞いの発送時期の到来、お中元やお歳暮の発送時期の到来、相手先の誕生日や記念日の到来、ユーザの住所移転、相手先の住所移転、相手先についての昇進、結婚、事故、死亡などの事象（事柄）の発生を意味している。また、ユーザが行うべき処理（設定された処理）は、年賀状や暑中見舞いの作成と発送、誕生日や記念日のお祝いの購入や発送、ユーザの住所変更に伴う相手先への変更通知の作成と発送、相手先の住所移転、昇進、結婚に対するお祝いの購入と発送、事故に対するお見舞の発送、死亡に対するお悔やお香典のお届けなどである。なお、ユーザが行うべき処理には、通知、お祝い、お悔やみなどについては、電話連絡によって内容を伝え、さらに詳しい情報を伺うようにすることも含む。

このため、代行サーバ１は、年賀状や暑中見舞いの送付時期の到来を検知したり、ユーザの住所移転の発生を検知したりした場合には、プロファイルデータの指示情報に応じて、印刷会社のサーバ７にたいして、年賀状、暑中見舞、案内状といった所定の書面の作成と発送を、通信ネットワーク１００を通じて依頼することができるようにしている。

また、代行サーバ１は、お中元やお歳暮の送付時期の到来や相手先の誕生日や記念日の到来を検知した場合、あるいは、相手先の住所移転、昇進、結婚などの事象の発生を検知した場合には、通信ネットワーク１００を通じてデパートのサーバ８にお祝いの品物の発送を依頼することができるようにしている。

また、相手先の事故（交通事故や火災等）といという事象の発生を検知した場合には、通信ネットワーク１００を通じて例えばデパートのサーバ８にお見舞の品物の発送を依頼することができるようにしている。また、相手先の死亡といという事象の発生を検知した場合には、電話局１０にお悔やみ電報の配達を依頼すると共に、例えば、郵便事業会社などの所定の会社にお香典の郵送を依頼するなどのことができるようにしている。

このように、この実施の形態の代行システムは、本来、端末装置２（１）、２（２）、…や携帯端末装置３（１）、…の使用者であるユーザが行うべき、関係する相手先に対する種々の処理を、代行サーバ１が登録されているユーザデータや関係する相手先のプロファイルデータに基づいて代行することができるように構成したものである。

［代行サーバ１の構成例］
次に、図１に示した代行システムにおいて、端末装置２（１）、２（２）、…、携帯端末装置３（１）、…のユーザが行うべき処理を代行する代行サーバ１の構成例について説明する。図２は、この実施の形態の代行サーバ１の構成例を説明するためのブロック図である。

図２に示すように、代行サーバ１は、通信部１０１と、プロファイル保守部１０２と、儀礼代行処理部１０３と、プロファイルデータベース（以下、プロファイルＤＢと略称する。）１０４と、地図データベース（以下、地図ＤＢと略称する。）１０５とを備えている。さらに、代行サーバ１は、スケジュール管理メモリ１０６と、操作入力部１０７と、カレンダ回路１０８と、制御部１１０とを備えている。なお、図２において２重線で示したプロファイル保守部１０２と儀礼代行処理部１０３とは、制御部１１０で実行されるプログラムにより、制御部１１０の機能として実現することもできる。

そして、代行サーバ１において、主に、通信部１０１とプロファイル保守部１０２と儀礼代行処理部１０３とが、その重要な機能を実現するための主要部となる。これらの主要部の説明を簡単にするために、当該主要部の説明に先立って、その周辺部分について説明する。

制御部１１０は、図２に示すように、ＣＰＵ（Central Processing Unit）１１１、ＲＯＭ（Read only Memory）１１２、ＲＡＭ（Random access Memory）１１３、ＥＥＰＲＯＭ（Electrically Erasable and Programmable ROM）１１４が、ＣＰＵバス１１５を通じて接続されて構成されたマイクロコンピュータであり、代行サーバ１の各部を制御することによって、代行サーバ１の全体を制御する。

ここで、ＣＰＵ１１１は、制御の主体となるものであり、ＲＯＭ１１２やＥＥＰＲＯＭ１１４に記憶されているプログラムを読み出して実行し、各部への制御信号を形成し、これを関係する各部に供給したり、また、各部からのデータを受信してこれを処理したりする。ＲＯＭ１１２は、上述したように、ＣＰＵ１１１によって実行される種々の処理プログラムや処理に必要となるデータを予め記憶したものである。

ＲＡＭ１１３は、各種の処理において、処理の途中結果を一時記憶するなど、主に作業領域として用いられるものである。また、ＥＥＰＲＯＭ１１４は、書き換え可能ないわゆる不揮発性メモリであり、電源が落とされても保持しておくべきデータ、例えば、機能追加のための新たなプログラム、各種設定パラメータなどのほか、例えば、自機に割り当てられたＩＰアドレスなど、種々の情報を記憶保持するものである。

そして、スケジュール管理メモリ１０６は、決まった時期に行うべき儀礼等についての情報を管理する。例えば、７月初旬はお中元時期であること、７月下旬は暑中見舞時期であること、１２月初旬はお歳暮時期であること、１２月中旬が年賀状時期であることなどを管理する。

その他、成人の日、節分、ひな祭り、端午の節句、七五三などの伝統的な行事の時期に共通して行うべき処理がある場合には、それらについても、スケジュール管理メモリ１０６に登録しておくことで管理することができる。また、暑中見舞は梅雨明け後に出すのが慣習であるので、制御部１１０は、例えば７月に入った場合に通信ネットワーク１００上の天気予報会社から情報を得て、梅雨明け予想時期をスケジュール管理メモリ１０６に更新するなどのこともできるようにされる。

操作入力部１０７は、オペレータによる情報の手入力を可能にするものである。具体的に操作入力部１０７は、アルファベットキーなどの種々の操作キーを備えたキーボードといわゆるマウスなどのポインティングデバイスとの一方あるいは両方からなるものである。なお、ポインティングデバイスとして、タッチパネル、タブレットとタッチペンからなる入力装置などの種々のものを用いるようにすることももちろん可能である。

カレンダ回路１０８は、現在年月日、現在曜日、現在時刻を提供するものであり、具体的には、ＲＴＣ（Real Time Clock）として実現される。このカレンダ回路１０８のカレンダ情報（現在年月日を示す情報）に基づいて、上述したスケジュール管理メモリ１０６において管理されている種々の時期の到来を検知することができる。また、このカレンダ回路１０８のカレンダ情報（現在年月日を示す情報）に基づいて、後述する相手先のプロファイルデータに含まれる誕生日や記念日を示す情報に応じた誕生日や記念日の到来を検知することもできる。

そして、プロファイルＤＢ１０４は、代行サーバ１の機能として上述したように、代行サーバ１の利用が許可されたユーザのユーザデータや、当該ユーザに関係する相手先についてのプロファイルデータをユーザ毎に記憶保持して管理するものである。また、地図ＤＢ１０５は、種々の地図情報を管理するものであり、例えば、会社移転の通知に際して、会社の位置を示す地図を含む案内を作成するなどの場合に利用することができるようにされる。すなわち、地図ＤＢ１０５のデータは、住所等によりジオコーディングして用いることもできるようにされる。

［プロファイルＤＢ１０４の詳細］
ここで、プロファイルＤＢ１０４において記憶保持されるデータの詳細について説明する。図３は、プロファイルＤＢ１０４におけるデータの管理構造の一例を説明するための図である。

この例の場合、プロファイルＤＢ１０４には、代行サーバ１の利用が許可された１以上のユーザのユーザデータ４１１（１）、４１１（２）、…が格納されるユーザデータファイル４１が設けられる。そして、ユーザデータファイル４１のユーザデータ４１１（１）、４１１（２）、…のそれぞれには、ユーザデータ４１１（１）、４１１（２）、…によって特定されるユーザに関係する１以上の相手先のプロファイルデータを格納するファイルが対応付けられる。

図３に示した例の場合には、相手先のプロファイルデータを格納するファイルとして、ビジネス関係相手先ファイル４２（１）、４２（２）、…、個人関係相手先ファイル４３（１）、４３（２）、…、所属・加入先ファイル４４（１）、４４（２）、…が設けられた場合を示している。

ビジネス関係相手先ファイル４２（１）、４２（２）、…は、対応するユーザデータによって特定されるユーザとビジネス（仕事）上関係する相手先についてのプロファイルデータ（図３ではビジネス先データと記載。）が格納されるものである。具体的に、ビジネス関係相手先ファイル４２（１）、４２（２）、…には、得意先、発注先、提携先、共同開発先といったビジネス上関係のある相手先のプロファイルデータが格納される。また、ビジネス関係相手先ファイル４２（１）、４２（２）、…のそれぞれには、図３にも示したように、複数の相手先についてのプロファイルデータが格納可能にされている。

また、個人関係相手先ファイル４３（１）、４３（２）、…は、対応するユーザデータによって特定されるユーザと個人的に関係する１以上の相手先についてのプロファイルデータ（図３では個人相手先データと記載。）が格納されるものである。具体的に、個人関係相手先ファイル４３（１）、４３（２）、…には、友人、知人、親類といったユーザが個人的に関係する相手先のプロファイルデータが格納される。また、個人関係相手先ファイル４３（１）、４３（２）、…のそれぞれには、図３にも示したように、複数の相手先についてのプロファイルデータか格納可能にされている。

また、所属・加入先ファイル４４（１）、４４（２）、…は、対応するユーザデータによって特定されるユーザが所属している団体、あるいは、契約関係にある会社などについてのプロファイルデータ（図３では所属・加入先データと記載。）が格納されるものである。具体的に、所属・加入先ファイル４４（１）、４４（２）、…には、ユーザが所属している趣味のサークル、ユーザが入会しているスポーツクラブ、ユーザが利用しているクレジットカードの提供会社など、所属・加入等している種々の団体や会社などについてのプロファイルデータが格納される。

この他にも、所属・加入先ファイル４４（１）、４４（２）、…には、ユーザが利用している電話会社、電力会社、ガス会社、インターネットのサービスプロバイダなど、ユーザが契約を結ぶことによってサービスの提供を受けている種々の団体や会社などのプロファイルデータも格納される。また、所属・加入先ファイル４４（１）、４４（２）、…のそれぞれには、図３にも示したように、複数の相手先についてのプロファイルデータか格納可能にされている。

そして、図３に示した例の場合には、ユーザデータファイル４１のユーザデータ４１１（１）に対して、ビジネス関係相手先ファイル４２（１）、個人関係相手先ファイル４３（１）、所属・加入先ファイル４４（１）が対応付けられている。また、ユーザデータファイル４１のユーザデータ４１１（２）に対して、ビジネス関係相手先ファイル４２（２）、個人関係相手先ファイル、４３（２）、所属・加入先ファイル４４（２）が対応付けられている。このようなユーザデータと相手先についてのプロファイルデータとの対応付けは、この実施の形態の代行サーバ１においては、ユーザＩＤによってなされるようにされている。

なお、図３においては、全てのファイルがプロファイルＤＢ１０４に形成されるものとして説明したが、各ファイルを異なる記録媒体に形成するようにすることももちろん可能である。要は、各ファイルがユーザによって関連付けて管理するようにされればよい。

［プロファイルＤＢ１０４で管理されるデータの詳細］
次に、図３を用いて説明したように、プロファイルＤＢ１０４に形成される各ファイルにおいて管理されるユーザデータや相手先についてプロファイルデータの具体例について説明する。

［ユーザデータのデータ構造の例］
まず、図３に示したプロファイルＤＢ１０４のユーザデータファイル４１に格納されるユーザデータの例（ユーザデータの構成例）について説明する。図４は、ユーザデータファイル４１に格納されるユーザデータ４１１（１）、４１１（２）、…の例について説明するための図である。なお、ユーザデータ４１１（１）、４１１（２）、…のそれぞれは、同様のデータ構造を有するため、ここでは、それらを総称してユーザデータ４１１と言う。

図４に示すように、ユーザデータ４１１は、ユーザＩＤを備えている。このユーザＩＤは、代行サーバ１の運営会社等により契約時において代行サーバ１の利用が可能になったユーザに対して付与される固有の識別ＩＤであり、ユーザのそれぞれを個別に識別可能なものである。さらに、ユーザデータは、当該ユーザの氏名、フリガナを有すると共に、当該ユーザの私的な情報として、性別、生年月日、自宅郵便番号、自宅住所、自宅電話番号、携帯電話番号、電子メールアドレスを有する。なお、携帯電話番号、電子メールアドレスは、ユーザが主に私的に利用しているものである。

さらに、ユーザデータは、当該ユーザの公的な情報として、勤務先名称（会社名等）、所属部署、職位、勤務先郵便番号、勤務先住所、勤務先電話番号１、勤務先電話番号２、ファクシミリ番号、勤務先電子メールアドレスを有する。ここで、勤務先電話番号が２つあるのは、例えば、代表電話番号と直通電話番号というように、複数の電話番号が存在する場合を考慮しているためである。

また、ユーザデータは、例えば、１００文字程度のテキストデータの入力が可能な備考欄を有している。この備考欄は、ユーザの例えばメモ欄として用いられるものであり、ユーザデータが元々管理していない情報について記載して管理するなどのことができるようにされる。

また、ユーザデータは、登録した情報について変更するなどの更新を行った場合にその履歴を保持する更新履歴欄を備えている。図４に示したユーザデータの例の場合には、更新履歴として、２０１０年３月５日に電子メールアドレスが変更され、２０１０年２月１７日には携帯電話番号が変更されたことが示されている。なお、ユーザデータの更新履歴には、発生した種々の事象（例えば、何かの賞を受賞したり、交通事故にあったりしたことなど）を記録することもできるようにされる。

そして、図４に示したユーザデータによって、代行サーバ１は、代行サーバ１の利用が可能なユーザについての情報を管理する。なお、例えば、ユーザＩＤには、パスワードなどの情報も含められ、代行サーバ１の利用が可能なユーザの認証などに用いることができるようにされる。もちろん、パスワードなどのユーザ固有の情報を独立に管理することもできる。

［ビジネス関係相手先ファイルのビジネス先データのデータ構成の例］
次に、図３に示したプロファイルＤＢ１０４のビジネス関係相手先ファイル４２（１）、４２（２）、…に格納されるビジネス先データの例について説明する。このビジネス先データは、ユーザがビジネス上関係する相手先のプロファイルデータである。図５は、ビジネス関係相手先ファイル４２（１）、４２（２）、…に格納されるビジネス先データの例について説明するための図である。

なお、ビジネス関係相手先ファイル４２（１）に格納されるビジネス先データ４２（１）−１、４２（１）−２、…も、ビジネス関係相手先ファイル４２（２）に格納されるビジネス先データ４２（２）−１、４２（２）−２、…も同様のデータ構造を有する。このため、ここでは、それらを総称してビジネス先データ４２−Ｘと言う。

図５に示すように、ビジネス先データ４２−Ｘは、ユーザＩＤを有している。このユーザＩＤは、図４を用いて説明したユーザデータのユーザＩＤに対応するものであり、このユーザＩＤによって、どのユーザに関係するビジネス先データであるのかを確実に区別することができる。

そして、ビジネス先データ４２−Ｘは、当該ビジネス先（ビジネスの相手先）を特定するためのビジネス先ＩＤ、当該ビジネス先の氏名、フリガナを有している。すなわち、ビジネス先（ビジネスの相手先）は、ビジネスの相手先となる会社や団体自体を意味するものではなく、実際にビジネス上で交渉などの相手となる担当者ベースのものである。さらに、当該ビジネス先の私的な情報として、性別、生年月日、自宅郵便番号、自宅住所、自宅電話番号、携帯電話番号、電子メールアドレスを有する。

これら私的な情報の内、自宅郵便番号、自宅住所、自宅電話番号は、当該ビジネス先（ビジネスの相手先（担当者））の自宅についてのものであり、携帯電話番号、電子メールアドレスは、当該ビジネス先が私的に利用しているものである。なお、これらの私的な情報が不明な場合もあり、その場合には空欄のままとすることができる。

さらに、ビジネス先データ４２−Ｘは、当該ビジネス先の公的な情報として、勤務先名称（会社名等）、勤務先郵便番号、勤務先住所、所属部署、職位、勤務先電話番号１、勤務先電話番号２、ファクシミリ番号、勤務先電子メールアドレスを有する。ここで、勤務先電話番号が２つあるのは、上述したユーザデータの場合と同様に、例えば、代表電話番号と直通電話番号というように、複数の電話番号が存在する場合を考慮しているためである。

また、ビジネス先データ４２−Ｘは、記念日情報や家族情報の管理エリアを有している。記念日情報は、当該ビジネス先とビジネスを行っていく過程において知り得た、当該ビジネス先についての結婚記念日や新築記念日など、当該ビジネス先が有する種々の記念日についての情報である。また、家族情報は、当該ビジネス先とビジネスを行っていく過程において知り得た、当該ビジネス先の家族の氏名、生年月日、所属（会社、団体、学校、学年）、備考（当該家族についての他の種々の情報）などである。これら記念日情報や家族情報に基づいて、お祝いをすべきタイミングを自動的に検知するなどのことができるようにされる。

さらに、ビジネス先データ４２−Ｘは、当該ビジネス先をビジネスの相手先としている当該ユーザからの変更通知に関する指示情報と、変更通知の対象項目についての指示情報を有している。当該ユーザからの変更通知に関する指示情報は、当該ユーザの図４に示したユーザデータについて所定の変更が生じた場合に、その変更を当該ビジネス先に通知するか否か、また、通知する場合にはどのような方法で通知するかを指示する情報からなる。

具体的には、ユーザからの変更通知の欄に示したように、「有無」が通知を行うか否かを指示する情報である。そして、通知を行う場合には、「はがき」、「手紙」、「電報」、「Ｖメール（ボイスメール）」、「Ｅメール（電子メール）」、「電話（オペレータによる電話連絡）」の１つ以上により通知を行うことができるようにされる。

なお、ユーザからの変更通知の欄のそれぞれの項目の指示は、フラグのオン／オフ（「１」または「０（ゼロ）」）により指示される。例えば、ユーザからの変更通知を行う場合には、「有無」欄が「１」とされ、はがきで通知する場合には、「はがき」欄が「１」とされ、その他の欄が「０」とされる。なお、「はがき」欄と「電話」欄を共に「１」としておくことで、はがきと電話の両方で通知を行うようにすることもできる。

そして、変更通知の対象項目に挙げられたいずれかの項目の変更が当該ユーザの図４に示したユーザデータに発生した場合に、当該ビジネス先に対して変更通知が行うようにされる。図５に示した例の場合、当該ユーザのユーザデータの勤務先、所属部署、勤務先住所、勤務先電話番号、勤務先ファクシミリ番号、勤務先電子メールアドレスのいずれかについて変更が生じた場合に、当該ビジネス先への変更通知が指示された方法で行うようにされる。

なお、図５に示したビジネス先データ４２−Ｘは、あくまでもビジネスの相手先についてのプロファイルデータであるので、当該ビジネス先とビジネスを行っているユーザの私的な情報、例えば自宅住所が変更になっても、当該ビジネス先には通知しないようにしている。しかし、図５に示した変更通知の対象項目の欄に「自宅住所」と言う項目を追加しておくことで、ユーザが引っ越して自宅住所が変わった場合に、その通知を当該ビジネス先にすることができる。このように、ビジネスの相手先であっても、親しいビジネス先には、ユーザの私的な情報の変更についても通知することができる。

また、ビジネス先データ４２−Ｘは、当該ビジネス先に対して行うべきいわゆる儀礼についての指示情報として儀礼対応情報をも有している。図５に示した例の場合、儀礼対応情報として、年賀状を送るか否か、暑中見舞を送るか否か、お中元を贈るか否か、贈る場合にはその予算、お歳暮を贈るか否か、贈る場合にはその予算を予め登録することができるようにされている。

そして、図５に示した例の場合には、当該ビジネス先に対して行うべき儀礼（処理）として、誕生日、結婚記念日、家族のお祝い、昇進についてお祝いを行うことが指示され、そのそれぞれについて、どのようにしてお祝いを行うかが指示するようにされている。具体的には、「カード」、「電報」、「Ｅメール（電子メール）」、「電話（オペレータによる電話連絡）」、「プレゼント」の１つ以上を行うことができるようにさる。また、「プレゼント」を行う場合には、その予算についても予め指示しておくことができるようにされる。

また、儀礼をどのように行うかを指示するそれぞれの項目については、上述したユーザからの変更通知をどのように行うかを指示する場合と同様に、フラグのオン／オフ（「１」または「０（ゼロ）」）によりその内容を指示することができる。例えば、当該ビジネス先の誕生日にバースデイカードを贈る場合には、「カード」の欄が「１」とされる。また、誕生日にプレゼントを贈る場合には、「プレゼント」の欄が「１」とされるとともに、「予算」の欄に予算（例えば、１万円）等といった金額情報が入力される。

また、当該ビジネス先（ビジネスの相手先）が亡くなられた場合、当該ユーザの事情あるいは当該ビジネス先の事情により、葬儀に出席できない場合、あるいは、葬儀自体が行われない場合もある。このような場合には、電報または電話によりお悔やみを伝えることを指示しておいたり、また、お香典を郵送することを指示したておいたりすることができる。もちろん、電報または電話によりお悔やみを伝えると共に、お香典を郵送することを指示しておくこともできる。また、お香典の金額についても事前に指示しておくことができる。なお、この場合にも、電報によりお悔やみを伝えるか、電話によりお悔やみを伝えるかは、フラグのオン／オフ（「１」または「０（ゼロ）」）により指示することができる。

また、図５に示した例においては、ビジネス先に対して行うべき儀礼として、誕生日、結婚記念日、家族のお祝い、昇進、葬儀の５つとしたが、これに限るものではない。これよりも少なくてももちろんよいし、他の儀礼を含めるようにすることももちろんできる。例えば、ビジネス先が独身の人であれば、その人が結婚した場合にお祝いを贈るように指示しておいたり、また、そのビジネス先の人に子供が誕生した場合にお祝いを贈るように指示しておいたりするなどのこともできる。

また、当該ビジネス先が著名な賞を受賞したり、褒章を受けたりした場合にお祝いを贈るように指示しておくなど、種々の儀礼（処理）を行うように、事前に指示しておくことができる。また、当該ビジネス先が事故などにあわれた場合にお見舞を送るように指示しておくこともできる。つまり、この図５に示したビジネス先データ４２−Ｘの場合、各ビジネス先に応じて、行うべき儀礼を選択し、登録しておくことができる。

また、ビジネス先データ４２−Ｘにおいても、当該ビジネス先データ４２−Ｘについて変更が生じ更新した場合には、その履歴情報が更新履歴に記録される。図５に示した例の場合には、２０１０年４月１日に当該ビジネス先（ビジネスの相手）が昇進したことを示す履歴情報が記録されている。なお、ビジネス先データの更新履歴には、発生した種々の事象（例えば、何かの賞を受賞したり、交通事故にあったりしたことなど）を記録することもできるようにされる。

このように、ビジネス先データ４２−Ｘにより、ビジネスの相手先の私的な情報、公的な情報、記念日情報、家族情報、ユーザからの変更通知に関する指示情報、儀礼についての指示情報を登録し、管理することができるようにされる。

［個人関係相手先ファイルの個人相手先データのデータ構成の例］
次に、図３に示したプロファイルＤＢ１０４の個人関係相手先ファイル４３（１）、４３（２）、…に格納される個人相手先データの例について説明する。この個人相手先データは、ユーザが個人的に関係する相手先のプロファイルデータである。図６は、個人関係相手先ファイル４３（１）、４３（２）、…に格納される個人相手先データの例について説明するための図である。

なお、個人関係相手先ファイル４３（１）に格納される個人相手先データ４３（１）−１、４３（１）−２、…も、個人関係相手先ファイル４３（２）に格納される個人相手先データ４３（２）−１、４３（２）−２、…も同様のデータ構造を有する。このため、ここでは、それらを総称して個人相手先データ４３−Ｘと言う。

そして、図５に示したビジネス先データ４２−Ｘと図６に示す個人相手先データ４３−Ｘとを比較すると分かるように、その基本的な部分についてはほぼ同様のデータとなっている。このため、重複する部分についての説明は省略し、図５に示したビジネス先データ４２−Ｘと異なる部分を中心にして、図６に示す個人相手先データ４３−Ｘについて説明する。

図６に示すように、個人相手先データ４３−Ｘもまたは、ユーザＩＤを有している。このユーザＩＤは、図４を用いて説明したユーザデータのユーザＩＤと同じものであり、このユーザＩＤによって、どのユーザに関係する個人相手先データであるのかを確実に区別することができる。

そして、個人相手先データ４３−Ｘは、当該個人相手先を特定するための相手先ＩＤを有している。また、個人相手先データ４３Ｘは、当該個人相手先と当該ユーザとはどのような関係かを示す「関係」欄が設けられている。この「関係」欄には、例えば、「友人」、「知人」、「親類」といった当該ユーザとの関係を示す情報が入力される。

そして、個人相手先データ４３−Ｘにおいて、氏名、フリガナ、性別、生年月日、私的な情報、公的な情報、記念日情報、家族情報のそれぞれは、図５を用いて説明したビジネス先データ４２−Ｘの対応する情報と同様の意味を有する情報である。すなわち、図５と図６とでは、ビジネス先についての情報か、個人相手先についての情報かは異なるが、対応する情報の意味するところは同じである。

なお、個人相手先の私的な情報は、自宅郵便番号、自宅住所、自宅電話番号、携帯電話番号、電子メールアドレスである。また、個人相手先の公的な情報は、勤務先名称、勤務先郵便番号、勤務先住所、所属部署、職位、勤務先電話番号１、勤務先電話番号２、ファクシミリ番号、電子メールアドレスである。また、個人相手先データ４３−Ｘは、ユーザが個人的に関係する相手先についての情報であるので、相手先についての上述した公的な情報が分からない場合には、それらの情報については空欄のままとすることができる。

そして、図６に示した個人相手先データ４３−Ｘのユーザからの変更通知に関する指示情報と、変更通知の対象項目についての指示情報についても、その意味は、図５に示したビジネス先データ４２−Ｘの対応するものと同様のものである。しかし、図６に示した個人相手先データ４３−Ｘは、ユーザと個人的な関係を有する相手先のプロファイルデータであるため、変更通知の対象項目については、ユーザの私的な情報部分に変更が生じた場合に通知を行うものとなっている。すなわち、図６に示した例の場合には、当該ユーザのユーザデータにおける自宅住所、自宅電話番号、携帯電話番号、電子メールアドレスに変更が生じた場合に、当該個人相手先に通知するようになっている。

なお、図５に示したビジネス先データ４２−Ｘの場合とは逆に、図６に示した変更通知の対象項目の欄に「勤務先」と言う項目を追加しておくことで、ユーザが転勤になったり、あるいは、転職したりした場合に、その通知を当該個人相手先にすることもできる。このように、個人的な付き合いの相手先であっても、ユーザのビジネスに関する変更を通知するようにすることもできる。

また、個人相手先データ４３−Ｘの儀礼対応情報も、図５を用いて説明したビジネス先データ４２−Ｘの儀礼対応情報が有する機能と同様の機能を有するものである。しかし、当該個人相手先に対して行うべき儀礼（処理）が一部異なっている。すなわち、図６に示した個人相手先データ４３−Ｘの場合には、図５に示したビジネス先データ４２−Ｘにおける「昇進」に替えて、「引越し（自宅住所変更）」がお祝い対象の儀礼として登録されている。なお、この図６に示した個人相手先データ４３−Ｘの場合にも、各個人相手先に応じて、行うべき儀礼を選択し、登録しておくことができる。

また、個人関係相手先ファイル４３（１）、４３（２）、…に格納される個人相手先データ４３−Ｘにおいても、当該個人相手先データ４３−Ｘについて変更が生じ更新した場合には、その履歴情報が更新履歴に記録される。図６に示した例の場合には、２０１０年１月２０日に引越しによる住所変更が生じたことを示す履歴情報が記録されている。なお、個人相手先データの更新履歴には、発生した種々の事象（例えば、何かの賞を受賞したり、交通事故にあったりしたことなど）を記録することもできるようにされる。

このように、個人相手先データ４３−Ｘにより、ユーザが個人的に関係する相手先の私的な情報、公的な情報、記念日情報、家族情報、ユーザからの変更通知に関する指示情報、儀礼についての指示情報を登録し、管理することができるようにされる。

［所属・加入先ファイルの所属・加入先データのデータ構成の例］
次に、図３に示したプロファイルＤＢ１０４の所属・加入先ファイル４４（１）、４４（２）、…に格納される所属・加入先データのデータ構成の例について説明する。この所属・加入先データは、ユーザが所属しているサークル、加入している団体、あるいは、契約関係のある団体や会社などについてのプロファイルデータである。図７は、所属・加入先ファイル４４（１）、４４（２）、…に格納される所属加入先データの例について説明するための図である。

なお、所属・加入先ファイル４４（１）に格納される所属・加入先データ４４（１）−１、４４（１）−２、…も、所属・加入先ファイル４４（２）に格納される所属・加入先データ４４（２）−１、４４（２）−２、…も同様のデータ構造を有する。このため、ここでは、それらを総称して所属・加入先データ４４−Ｘと言う。

図７に示すように、所属・加入先データ４４−Ｘにおいてもまた、ユーザＩＤを有している。このユーザＩＤは、図４を用いて説明したユーザデータのユーザＩＤに対応するものであり、このユーザＩＤによって、どのユーザに関係する所属・加入先データであるのかを確実に区別することができる。

そして、所属・加入先データ４４−Ｘは、所属・加入先ＩＤ、種別、所属・加入先名称、郵便番号、住所、電話番号、電子メールアドレス、担当部署、担当者名を有している。ここで、所属・加入先ＩＤは、当該所属・加入先を一意に特定するための識別ＩＤである。また、種別は、例えばサークル、スポーツクラブ、クレジット会社、ＩＳＰ（Internet Services Provider）、電話会社等の当該所属・加入先の種別（種類）を示すものである。

また、所属・加入先名称は、所属あるいは加入している先のサークル、団体、会社等の名称である。また、郵便番号、住所、電話番号、電子メールアドレス、担当部署、担当者名は、当該所属・加入先についての連絡先を示す情報である。

さらに、所属・加入先データ４４−Ｘは、ユーザからの変更通知に関する指示情報と、変更通知の対象項目についての指示情報を有している。ユーザからの変更通知に関する指示情報は、当該所属・加入先に所属あるいは加入しているユーザについて所定の変更が生じた場合に、どのように通知するかを指示する情報からなる。

具体的には、「はがき」、「手紙」「電報」、「Ｅメール（電子メール）」、「電話（オペレータによる電話連絡）」の１つ以上により通知を行うことができるようにされる。なお、この場合においても、ユーザからの変更通知の欄のそれぞれの項目の指示は、フラグのオン／オフ（「１」または「０（ゼロ）」）により指示するようにされる。例えば、はがきで通知する場合には、「はがき」欄が「１」とされ、その他の欄が「０」とされる。なお、「はがき」欄と「電話」欄を共に「１」としておくことで、はがきと電話の両方で通知を行うようにすることもできる。

そして、変更通知の対象項目に挙げられたいずれかの項目の変更が当該ユーザの図４に示した構成のユーザデータに発生した場合に、当該所属・加入先に対して変更通知が行うようにされる。図７に示した例の場合には、当該ユーザのユーザデータの自宅住所、自宅電話番号、携帯電話番号、電子メールアドレスのいずれかについて変更が生じた場合に、当該所属・加入先への変更通知が指示された方法で行うようにされる。

また、所属・加入先データ４４−Ｘには、備考欄が設けられており、ユーザによりメモ欄として用いることができるようにされている。そして、当該備考欄により、例えば、当該所属・加入先データ４４−Ｘが管理していない情報について記載し、管理するなどのことができる。

このように、所属・加入先データ４４−Ｘにより、ユーザが所属・加入している相手先についての主に連絡先やユーザからの変更通知に関する指示情報を登録し、管理することができるようにされる。

そして、図３〜図７を用いて説明したように、代行サーバ１のプロファイルＤＢ１０４によって、代行サーバ１の利用が可能とされたユーザのユーザデータを管理することができると共に、当該ユーザが関係する種々の相手先についてのプロファイルデータを管理することができる。そして、相手先のプロファイルデータは、ユーザ毎に管理されるが、更に、ビジネス上の関係のある相手先、個人的に関係のある相手先、所属・加入している団体や会社などである相手先というように、相手先の種類（種別）毎に管理することができるようになっている。

［代行サーバ１の主要部分］
次に、この実施の形態の代行サーバ１の主要な構成部分である通信部１０１、プロファイル保守部１０２、儀礼代行処理部１０３について詳細に説明する。

通信部１０１は、この代行サーバ１が通信ネットワーク１００を通じて情報を送受する機能を実現する。すなわち、通信部１０１は、通信ネットワーク１００を通じて自機宛に送信されてくる信号を受信し、これを自機において処理可能な形式の信号に変換して制御部１１０に供給する。また、通信部１０１は、制御部１１０を通じて供給される信号を、送信する形式の信号に変換し、これを通信ネットワーク１００に送出する。これにより代行サーバ１の制御部１１０は、自機宛の情報を受信して処理したり、所定のサーバ装置にアクセスして情報を参照したり、必要な情報を取得したりすることができるようにされる。

プロファイル保守部１０２は、上述したプロファイルＤＢ１０４へのユーザデータや相手先についてのプロファイルデータの追加、プロファイルＤＢ１０４に格納されているユーザデータや相手先についてのプロファイルデータの変更や削除を行う。このような、データの追加、変更、削除は、通信部１０１を通じて受信したユーザの端末装置２（１）、２（２）、…やユーザの携帯端末装置３（１）、…からの要求や操作入力部１０７を通じて受け付けた要求に基づいて行われる。

例えば、ユーザＩＤを付与されたユーザは、自己が使用する端末装置２や携帯端末装置３を用い、通信ネットワーク１００を通じて代行サーバ１にアクセスして、図４に示したユーザデータや図５〜図７に示した相手先のプロファイルデータをプロファイルＤＢ１０４に登録する処理を行う。この場合、代行サーバ１が提供する入力画面を通じて、自己のユーザデータや相手先についてのプロファイルデータを比較的に簡単に入力することができるようにされる。

また、ユーザが用いる端末装置等に得意先リストやアドレス帳データが存在する場合には、それらを指定して代行サーバ１のプロファイルＤＢ１０４にインポートすることもできる。この場合、得意先リストやアドレス帳データの一部のデータを指定して、プロファイルＤＢ１０４にインポートすることもできる。

また、データのインポートの場合には、図５〜図７を用いて説明したように、記念日情報、家族情報、ユーザからの変更通知に関する指示情報、変更通知の対象項目についての指示情報、儀礼対応情報については、代行サーバ１から提供される入力画面を通じて入力することができるようにされる。このようにして、ユーザは、自己のユーザデータや相手先についてのプロファイルデータを通信ネットワーク１００に接続可能な自己の端末装置や携帯端末外を通じて代行サーバ１のプロファイルＤＢ１０４に登録することができる。

また、代行サーバ１のプロファイルＤＢ１０４に格納されているユーザデータや相手先についてのプロファイルデータの変更や削除についても、ユーザは、自己が使用する端末装置２や携帯端末装置３を通じて、代行サーバ１にアクセスし、目的とするデータの変更や削除を行うことができる。

なお、代行サーバ１が運営する会社に紙面などを通じてユーザデータや相手先のプロファイルデータの追加、変更、削除を依頼することにより、代行サーバ１側のオペレータが操作入力部１０７を通じて、ユーザデータやプロファイルデータの追加、変更、削除を行うようにすることもできる。

また、代行サーバ１のプロファイルＤＢ１０４に登録されているデータについては、プロファイル保守部１０２が通信部１０１を通じて通信ネットワーク１００上のＷｅｂページをクロールすることにより得た情報に基づいて変更することもできる。ここでクロールは、自動的に通信ネットワーク上のＷｅｂページの情報を参照し、必要な情報を収集することを意味する。さらに、新聞、雑誌、テレビ、ラジオ等を通じて行われるマスコミ発表に基づいて、代行サーバ１のオペレータが操作入力部１０７を通じてプロファイルＤＢ１０４に登録されているデータの変更を行うこともできるようにされている。

このように、代行サーバ１のプロファイルＤＢ１０４に登録された種々のデータについては、ユーザが自己の使用する端末装置等を通じて変更することができるだけでない。プロファイル保守部１０２が実現するクロール機能により通信ネットワーク１００上に開示された情報に基づいて、自動的に変更するようにしたり、また、新聞発表等に基づいて、オペレータが操作入力部１０７を通じて変更したりすることもできるようにされる。

なお、プロファイル保守部１０２が実現するクロール機能に基づいて、あるいは、オペレータが新聞発表等に基づいて、プロファイルＤＢ１０４のデータを変更した場合には、変更したことをユーザの使用する端末装置に対して例えば電子メールの形式で通知するようにされる。また、変更に先立って、事前に該当するユーザの端末装置等に変更確認通知を送信し、変更に同意が得られた場合に変更を行うようにするといった対応を取ることもできる。また、複数の変更確認通知をまとめておいてまとめて確認し、複数の変更を一度に行うようにすることも可能である。

なお、プロファイルＤＢ１０４に登録されているユーザデータやビジネス先データや個人相手先データや所属・加入先データに変更が生じた場合には、当該変更対象となった１つのデータだけが変更されるものではない。例えば、ユーザＡのビジネス先Ｘについてデータの変更が生じた場合、ユーザＢの同じビジネス先Ｘについても、当該変更を反映させることができる。

これにより、ユーザＡがビジネス先Ｘのビジネス先データについて行った変更を、ユーザＢのビジネス先Ｘのビジネス先データにも反映させることができる。したがって、ユーザＢはビジネスＸについての変更を知り得なかった場合でも、ユーザＢについてのビジネス先Ｘのビジネス先データを正確なものに維持することができる。

同様に、ユーザデータに変更が生じた場合に、当該ユーザデータが特定するユーザを、ビジネス先や個人相手先としている他のユーザがいたとする。この場合には、当該ユーザデータの変更に基づいて、当該他のユーザの対応するビジネス先データ、あるいは、対応する個人相手先データに変更を反映することができる。

このように、１のデータについて変更が生じた場合には、その変更対象のデータと例えば氏名と住所など予め決められた２つ以上の項目が一致するデータを同一のユーザまたは相手先のデータであると判別し、この同一のユーザまたは相手先のデータに対して、当該変更を反映させることができる。これにより、代行サーバ１の利用可能なユーザは相互に同じ相手先のデータを正確なものとなるように維持しあうことができるようにされる。

さらに、プロファイル保守部１０２は、プロファイルＤＢ１０４に登録されているユーザデータにより特定されるユーザやプロファイルデータにより特定される相手先についての所定の事象の発生を検知する。そして、当該所定の事象の発生を検知した場合には、これを儀礼代行処理部１０３に通知する。この実施の形態の代行サーバ１のプロファイル保守部１０２は、以下の４つの経路を通じて、当該事象の発生の検知を行う。

図８は、プロファイル保守部１０２がユーザや相手先についての所定の事象の発生を検知する経路（１）〜（４）について説明するための図である。この実施の形態の代行サーバ１のプロファイル保守部１０２は、上述したプロファイルＤＢ１０４の変更や更新を行う３つの場合に、ユーザや相手先についての所定の事象の発生を検知することができる。さらに、プロファイル保守部１０２はカレンダ回路１０８が提供する現在年月日を基準にして、所定の事象の発生（到来）を検知することができる。

すなわち、上述もしたように、ユーザは、自己の端末装置と通信ネットワーク１００を通じて、代行サーバ１にアクセスし、プロファイルＤＢのデータの変更を行うことができる。この場合、ユーザデータの項目について変更した場合には、ユーザデータの当該変更項目についての事象が発生したと検知することができる。例えば、ユーザデータの自宅住所が変更された場合には、当該ユーザが引越しを行ったと言う事象を検知することができる。同様に、ビジネス先データ、個人相手先データ、所属・加入先データの項目について変更した場合には、それらのデータの当該変更項目についての事象が発生したと検知することができる。例えば、ビジネス先データの職位が上位の職位に変更された場合には、当該ユーザが昇進したと言う事象を検知することができる。

すなわち、図８において（１）が示すように、通信ネットワーク１００を通じて送信されてくるユーザからの指示によりプロファイルＤＢ１０４の情報の変更を行った場合が、代行処理発生パターン１となり、当該検知した事象の発生（どのデータのどの情報に変更が生じたか）が儀礼代行処理部１０３に通知される。

また、上述もしたように、代行サーバ１のプロファイル保守部１０２は、クロール機能により、通信ネットワーク１００に開示された情報に基づいてプロファイルＤＢのデータの変更や更新を行うことができる。この場合に、例えば、通信ネットワーク１００上に開示されたブログにおいて、プロファイルＤＢ１０４のユーザデータにより特定されるユーザが引越しを行ったことを記載していれば、当該ユーザが引越しを行ったと言う事象を検知することができる。この場合、新住所が記載されていれば、当該ユーザのユーザデータの自宅住所が変更の対象となり、更新履歴も更新される。また、新住所が記載されていなければ、引越ししたことを示す情報が、更新履歴に記載されて当該事象の発生が管理される。

また、通信ネットワーク１００上に開示されたＷｅｂページにおいて、プロファイルＤＢ１０４のビジネス先データにより特定されるビジネス先の勤務先が移転したことが記載していれば、当該ビジネス先の勤務先が移転したと言う事象を検知することができる。この場合、新住所が記載されていれば、当該ビジネス先のビジネス先データの勤務先住所が変更の対象となり、更新履歴も更新される。また、勤務先住所が記載されていなければ、勤務先が移転したことを示す情報が、更新履歴に記載されて当該事象の発生が管理される。また、通信ネットワーク１００上に開示されたＷｅｂページにおいて、プロファイルＤＢ１０４のビジネス先データにより特定されるビジネス先についての死亡記事が見つかった場合には、当該ビジネス先の死亡と言う事象を検知することができる。この場合には、死亡したことを示す情報が、更新履歴に記載されて当該事象の発生が管理される。

すなわち、図８において（２）が示すように、クロール処理によりプロファイルＤＢ１０４に登録されているユーザデータに対応するユーザやビジネス先データや個人相手先データに対応する相手先に対する事象（事柄）の発生を検知した場合が、代行処理発生パターン２となり、当該検知した事象の発生（どのデータにどのようなことが発生したか）が儀礼代行処理部１０３に通知される。

なお、この場合、プロファイルＤＢ１０４に登録されている該当データの該当箇所が変更可能な場合も在れば、所定の事象が発生したことが検知できるだけで、データの変更ができない場合もある。しかし、所定の事象が発生したことは、上述したように更新履歴に記録され、どのような事象（事柄）がいつ発生したかなどを把握することができるようにされる。

また、新聞発表等に基づいて、代行サーバ１のオペレータが操作入力部１０７を通じてプロファイルＤＢ１０４に登録されているデータの変更や更新を行うこともできる。例えば、新聞発表により、ユーザデータにより特定されるユーザの職位が上位の職位に変更になったり、ビジネス先データにより特定されるビジネス先の職位が上位の職位に変更になったりしたことを検知したとする。この場合に、該当するユーザデータの職位や該当するビジネス先データの職位を変更すると、当該ユーザやビジネス先において昇進と言う事象が発生したことを検知することができる。また、新聞の死亡記事により、当該ビジネス先が死亡したことを検知したとする。この場合に、該当するビジネス先データの更新履歴にビジネス先の死亡の事実を更新（記録）すると、当該ビジネス先について死亡と言う事象が発生したことを検知することができる。

この場合、図８において（３）が示すように、新聞、雑誌、テレビ、ラジオ等のマスコミ発表に基づいて、プロファイルＤＢ１０４に登録されているユーザデータ、ビジネス先データ、個人相手先データを変更したり更新したりすることにより、対応するユーザや対応する相手先に当該変更した項目や更新した情報に対応する事象（事柄）が発生したと検知した場合が、代行処理発生パターン３となり、当該検知した事象の発生（どのデータにどのようなことが発生したか）が儀礼代行処理部１０３に通知される。

なお、この場合においても、プロファイルＤＢ１０４に登録されている該当データの該当箇所をオペレータが変更可能な場合も在れば、所定の事象が発生したことが検知できるだけで、データの変更ができない場合もある。しかし、所定の事象が発生したことは、上述したように更新履歴に記録され、どのような事象（事柄）がいつ発生したかなどを把握することができるようにされる。

さらに、代行サーバ１は、上述もしたようにスケジュール管理メモリ１０６、カレンダ回路１０８を備えている。このため、プロファイル保守部１０２は、スケジュール管理メモリ１０６の管理データとカレンダ回路１０８が提供する現在年月日を参照し、年賀状や暑中見舞の発送時期、お中元やお歳暮の発送時期などの到来を検知した場合には、これを儀礼代行処理部１０３に通知する。同様に、プロファイル保守部１０２は、カレンダ回路１０８が提供する現在年月日と相手先のプロファイルデータが有する生年月日や記念日情報とを参照し、誕生日や記念日の到来を検知した場合には、これを儀礼代行処理部１０３に通知する。

この場合、図８において（４）が示すように、カレンダ回路１０８が提供する現在年月日に基づいて、いわゆる季節性の儀礼や期日の明確なお祝い等の実行時期の到来を検知した場合が、代行処理発生パターン４となり、当該検知した事象の発生（季節性の儀礼の発生、あるいは、どのデータの相手先にどのような事象が発生したか）が儀礼代行処理部１０３に通知される。

そして、儀礼代行処理部１０３は、上述したように、プロファイル保守部１０２から所定の事象が発生したことの通知を受けると、その事象が発生したユーザのユーザデータ、あるいは、その事象が発生した相手先のプロファイルデータに基づいて本来ユーザが行うべき処理を代行して行うようにする処理を実行する。

［ユーザデータに変更が生じた場合の代行処理］
例えば、プロファイルＤＢ１０４に格納されているユーザデータについて変更が生じたことがプロファイル処理部１０２から通知されると、儀礼代行処理部１０３は、ユーザからの変更通知の必要性が発生したことを検知する。この場合、儀礼代行処理部１０３は、当該ユーザデータにより特定されるユーザに対応付けられているビジネス関係相手先ファイル４２（ｎ）と、個人関係相手先ファイル４３（ｎ）と、所属・加入先ファイル４４（ｎ）の変更通知の対象項目の指示欄を参照し、今回の変更の対象となっている項目が登録されているか否かを確認する。

そして、今回の変更の対象となっている項目が登録されている場合に、儀礼代行処理部１０３は、各プロファイルデータが有するユーザからの変更通知欄の指示情報に応じて、当該相手先に対して変更通知を行うようにする処理を実行する。この場合、儀礼代行処理部１０３は、変更通知を送付する相手先のプロファイルデータに基づいて、変更通知の送付先リストを作成する。

より具体的には、儀礼代行処理部１０３は、「はがき」により変更通知を行う送付先（相手先）リスト、「手紙」により変更通知を行う送付先（相手先）リスト、「電報」により変更通知を行う送付先（相手先）リスト、「Ｖメール」により変更通知を行う送付先（相手先）リスト、「Ｅメール」により変更通知を行う送付先（相手先）リスト、「電話」により変更通知を行う送付先（相手先）リストを作成する。

この場合、「はがき」、「手紙」、「電報」により変更通知を行う送付先（相手先）リストは、送付方法の別と、当該相手先の氏名、住所、通知内容（文面）からなるものである。また、「Ｖメール」、「Ｅメール」により変更通知を行う送付先（相手先）リストは、送付方法の別と、当該相手先の氏名、電子メールアドレス、通知内容からなるものである。また、「電話」により変更通知を行う送付先（相手先）リストは、送付方法の別と、当該相手先の氏名、電話番号、通知内容からなるものである。

そして、儀礼代行処理部１０３は、「はがき」、「手紙」により変更通知を行う送付先（相手先）リストを、通信部１０１、通信ネットワーク１００を通じて、図１に示した印刷会社のサーバ７に送信し、「はがき」、「手紙」による変更通知を行うようにする。また、儀礼代行処理部１０３は、「電報」により変更通知を行う送付先（相手先）リストを、通信部１０１、通信ネットワーク１００を通じて、図１に示した電話会社のサーバ１０に送信し、「電報」による変更通知を行うようにする。

また、儀礼代行処理部１０３は、「Ｖメール」、「Ｅメール」により変更通知を行う送付先（相手先）リストを用いて、「Ｖメール」、「Ｅメール」を作成し、これを当該リストに応じて、通信部１０１、通信ネットワーク１００を通じて、目的とする相手先に送信する。また、儀礼代行処理部１０３は、「電話」により変更通知を行う送付先（相手先）リストを、通信部１０１、通信ネットワーク１００を通じて、図１に示したオペレータ会社のサーバ９に送信し、「電話」による変更通知を行うようにする。

なお、「はがき」、「手紙」、「Ｅメール」などにより変更通知を行う場合であって、例えば、引越しにより自宅住所が変わった場合などにおいては、儀礼代行処理部１０３は、地図ＤＢ１０５の地図情報を用いて、新住所近辺の地図を通知内容に含めることができる。

また、図５〜図７に示したように、ビジネス先データ及び個人相手先データと、所属・加入先データとでは、ユーザからの変更通知に関する指示情報が異なるが、通知方法に違いがあるだけであるので、同様にして処理することができる。また、ビジネス先データ及び個人相手先データは、ユーザからの変更通知に関する指示情報に通知の「有無」が指定でき、所属・加入先データでは指定できない構成となっている。

これは、ビジネス先データ及び個人相手先データについては、状況に応じて、変更通知を行う場合と行わない場合とを使い分けることができるが、所属・加入先に対しては、必ず通知する必要があるとの前提に基づいている。したがって、所属・加入先に対しても、変更通知の「有無」を設定できるようにすることももちろん可能である。

［年賀状、暑中見舞、お中元、お歳暮の時期が到来した場合の代行処理］
また、年賀状、暑中見舞、お中元、お歳暮の時期が到来したことがプロファイル処理部１０２から通知されると、儀礼代行処理部１０３は、季節性の儀礼が発生したことを検知する。この場合、儀礼代行処理部１０３は、全てのユーザのビジネス関係相手先ファイル４２（１）、４２（２）、…、個人関係相手先ファイル４３（１）、４３（２）、…に格納されているデータの儀礼対応情報の対応項目を確認する。

そして、儀礼代行処理部１０３は、到来した時期に応じて、年賀状の送付先リストや暑中見舞の送付先リストを形成し、これを通信部１０１、通信ネットワーク１００を通じて、図１に示した印刷会社のサーバ７に送信し、年賀状や暑中見舞の作成と発送を依頼する。したがって、年賀状の送付先リストや暑中見舞の送付先リストは、年賀状や暑中見舞を送付するように設定している相手先の氏名、郵便番号、住所、文面などからなる。なお、文面については、予め用意されている定型の文面から選択したり、例えば、別ファイルにユーザが予め用意しておいたものを用いるようにしたりするなどのことができるようにされる。

また、儀礼代行処理部１０３は、到来した時期に応じて、お中元の送付先リストやお歳暮の送付先リストを形成し、これを通信部１０１、通信ネットワーク１００を通じて、図１に示したデパートのサーバ８に送信し、お中元やお歳暮の発送を依頼する。したがって、お中元の送付先リストやお歳暮の送付先リストは、お中元やお歳暮を送付するように設定している相手先の氏名、郵便番号、住所、予算などからなる。なお、例えば、お酒、果物、商品券などといった、予め決められた商品群の中から贈りたい商品を指定するようにしておくことも可能である。当該指定情報の設定欄を設ければよい。

［登録されている事象が発生した場合の代行処理］
また、図５を用いて説明したビジネス先データや図６を用いて説明した個人相手先データの生年月日に基づく相手先の誕生日の到来や、登録されている記念日情報や家族情報に基づくお祝い事の発生、さらには相手先の事故や死亡といったことがプロファイル処理部１０２から通知されたとする。この場合、儀礼代行処理部１０３は、対応するビジネス先データや個人相手先データの儀礼対応情報に行うべき儀礼として予め登録されている儀礼か否かを判別する。ここで予め登録されている儀礼である場合には、当該儀礼を行う必要性が発生したことを検知する。

この場合、儀礼代行処理部１０３は、儀礼が発生した相手先のプロファイルデータ（ビジネス先データや個人相手先データ）の儀礼対応情報に基づいて、儀礼を代行する処理を行う。例えば、相手先の誕生日、結婚記念日、家族のお祝い、引越しなどのお祝い事が発生した場合には、対応する処理内容に応じた処理を行う。

例えば、お祝いのカードを贈ることが指示されている場合には、カードの送付先リストを形成し、これを通信部１０１、通信ネットワーク１００を通じて、図１に示した印刷会社のサーバ７に送信し、お祝いカードの作成と発送を依頼する。したがって、カードの送付先リストは、カードを送付するように設定している相手先の氏名、郵便番号、住所、文面（何のお祝いカードかを示す情報）などからなる。なお、文面については、予め用意されている定型の文面から選択したり、例えば、別ファイルにユーザが予め用意しておいたものを用いるようにしたりするなどのことができるようにされる。

また、お祝いの電報を送ることが指示されている場合には、電報の送付先リストを形成し、これを通信部１０１、通信ネットワーク１００を通じて、図１に示した電話会社のサーバ１０に送信し、電報の発送を依頼する。したがって、電報の送付先リストは、電報を送付するように設定している相手先の氏名、郵便番号、住所、文面（何のお祝い電報かを示す情報）などからなる。なお、文面については、予め用意されている定型の文面から選択したり、例えば、別ファイルにユーザが予め用意しておいたものを用いるようにしたりするなどのことができるようにされる。

また、Ｅメール（電子メール）を送ることが指示されている場合には、電子メールの送付先リストを形成し、これに応じてお祝いの電子メールを作成し、これを通信部１０１、通信ネットワーク１００を通じて、当該目的とする相手先に送信する。したがって、電子メールの送付先リストは、電子メールを送付するように設定している相手先の氏名、電子メールアドレス、文面（何のお祝い電子メールかを示す情報）などからなる。なお、文面については、予め用意されている定型の文面から選択したり、例えば、別ファイルにユーザが予め用意しておいたものを用いるようにしたりするなどのことができるようにされる。

また、プレゼントを贈ることが指示されている場合には、プレゼントの送付先リストを形成し、これを通信部１０１、通信ネットワーク１００を通じて、図１に示したデパートのサーバ８に送信し、プレゼントの発送を依頼する。したがって、プレゼントの送付先リストは、プレゼントを送付するように設定している相手先の氏名、郵便番号、住所、予算などからなる。なお、プレゼントについては、例えば、生花、貴金属、果物、…といった予め決められた商品群の中から贈りたい商品を指定するようにしておくことも可能である。当該指定情報の設定欄を設ければよい。

また、相手先の死亡がプロファイル処理部１０２から通知された場合には、図５、図６を用いて説明したように、「葬儀」と言う設定欄の情報に基づいて、代行処理を行う。この場合、電報によりお悔やみを伝えることが設定されている場合には、お悔やみ電報の送付先リストを形成し、これを通信部１０１、通信ネットワーク１００を通じて、図１に示した電話会社のサーバ１０に送信し、お悔やみ電報の発送を依頼する。したがって、お悔やみ電報の送付先リストは、お悔やみ電報を送付するように設定している相手先の氏名、郵便番号、住所、文面などからなる。なお、文面については、予め用意されている定型の文面から選択したり、例えば、別ファイルにユーザが予め用意しておいたものを用いるようにしたりするなどのことができるようにされる。

また、電話によりお悔やみを伝えることが設定されている場合には、お悔やみ電話の相手先リストを形成し、これを通信部１０１、通信ネットワーク１００を通じて、図１に示したオペレータ会社のサーバ９に送信し、お悔やみの電話をかけることを依頼する。したがって、お悔やみ電話の相手先リストは、お悔やみの電話をかけるように設定している相手先の氏名、電話番号、お悔やみの文言などからなる。なお、お悔やみの文言については、予め用意されている定型の文言から選択したり、例えば、別ファイルにユーザが予め用意しておいたものを用いるようにしたりするなどのことができるようにされる。また、葬儀の日程や場所などを聞きたい場合には、問い合わせ事項などの情報を当該リストに含めることができる。

また、お香典を郵送することが指示されている場合には、お香典の送付先リストを形成し、これを通信部１０１、通信ネットワーク１００を通じて、図１には図示しなかったが、例えば、お香典の郵送を行う所定の会社のサーバに送信し、お香典の郵送を依頼する。したがって、お香典の送付先リストは、お香典を郵送するように設定している相手先の氏名、郵便番号、住所、金額などからなる。

そして、上述したように、代行サーバ１の儀礼代行処理部１０３の機能により行うようにされる代行処理には、費用、料金が発生する場合が生じる。この場合には、ユーザが使用可能なクレジット会社のクレジットカード番号を代行サーバ１側に登録するなどしておくことにより、クレジットにより決済することができる。この他にも、代行サーバ１の運営会社が、代行サーバ１を利用しているユーザに発生した費用、料金を請求し、費用、料金が発生した会社等に支払うようにすることもできる。また、費用、料金が発生した会社が、直接にユーザに請求を行うようにすることもできる。

このように、この実施の形態の代行サーバ１は、利用が許可されたユーザのユーザデータや当該ユーザと関係のある相手先のプロファイルデータをユーザ毎に管理し、これらのデータに基づいて相手先に関する所定の事象（事柄）が発生したことを検知する。そして、発生した事象（事柄）に応じて、プロファイルデータに登録されている相手先に対して行うべき処理に関する指示情報に応じて、本来ユーザが行うべき処理を代行して他のものが行うようにすることができる。

［代行サーバ１の処理のまとめ］
次に、上述した代行サーバ１において行われる処理について、図９〜図１３のフローチャートを用いて説明する。

［相手先に関する所定の事象（事柄）が発生したことの検知処理］
まず、代行サーバ１の主にプロファイル保守部１０２によって行われる、プロファイルデータにより管理されている相手先に関する所定の事象（事柄）が発生したことの検知処理について説明する。この実施の形態の代行サーバ１においては、プロファイルデータにより管理されている相手先に関する所定の事象（事柄）が発生したことの検知は、図８に示した（１）〜（４）の４つの経路を通じて行うようにしている。すなわち、代行サーバ１のプロファイル保守部１０２は、図９〜図１２に示す処理を順次に実行し、図８に示した（１）〜（４）の４つの経路でユーザやユーザと関係する相手先に関する所定の事象（事柄）の発生を検知するようにしている。

図９は、図８の（１）に示した端末装置等を通じたユーザからの指示により、あるいは、図８（３）に示した操作入力部１０７を通じたオペレータからの指示により、プロファイルＤＢ１０４で管理されているデータの変更を行った場合をユーザや相手先に関する所定の事象（事柄）が発生した場合として検知する処理を説明するためのフローチャートである。

プロファイル保守部１０２は、常時、通信部１０１や操作入力部１０７を通じて、プロファイルＤＢ１０４に格納されているユーザデータやビジネス先データや個人相手先データについての変更指示を受け付けるようにしている（ステップＳ１０１）。そして、プロファイル処理部１０２は、上記いずれかのデータについての変更指示を通信部１０１や入力操作部１０７を通じて受け付けたか否かを判別する（ステップＳ１０２）。

ステップＳ１０２の判別処理において、上記いずれかのデータについての変更指示を受け付けていないと判別したときには、ステップＳ１０１からの処理を繰り返す。また、ステップＳ１０２の判別処理において、上記いずれかのデータについての変更指示を受け付けたと判別したときには、プロファイル処理部１０２は、プロファイルＤＢ１０４の該当データを変更する処理を実行する（ステップＳ１０３）。そして、プロファイル保守部１０２は、検知した事象の発生、すなわち、どのデータのどの情報に変更が生じたかを示す情報を儀礼代行処理部１０３に通知する（ステップＳ１０４）。この後、ステップＳ１０１からの処理を繰り返す。

このように、この実施の形態の儀礼代行サーバ１のプロファイル保守部１０２は、プロファイルＤＢ１０４に格納されているいずれかのデータについての変更指示を受け付けた場合に、当該データに応じた相手先について、所定の事象が発生したと判別し、これを儀礼代行処理部１０３に通知することができる。

図１０は、図８の（２）に示したクロール処理によりプロファイルＤＢ１０４に登録されているユーザデータに対応するユーザやビジネス先データや個人相手先データに対応する相手先に対する所定の事象（事柄）の発生を検知する場合の処理について説明するためのフローチャートである。

プロファイル保守部１０２は、常時、通信部１０１を通じて、通信ネットワーク１００上に公開されている種々のＷｅｂページを参照し、プロファイルＤＢ１０４のユーザデータにより特定されるユーザやビジネス先データや個人相手先データにより特定される相手先についての所定の事象の発生を検知するクロール処理を行うようにしている（ステップＳ２０１）。具体的にステップＳ２０１においては、公開されているＷｅｂページ等の情報に基づいて、上述もしたように住所の移転（住所変更）、種々の事故、結婚、出産、死亡等のユーザ、ビジネス先、個人相手先について起こった種々の事象（事柄）の発生を検知する
そして、プロファイル処理部１０２は、ユーザや相手先について所定の事象が発生したことを検知したか否かを判別する（ステップＳ２０２）。ステップＳ２０２の判別処理において、所定の事象の発生を検知していないと判別したときには、ステップＳ２０１からの処理を繰り返し、クロール処理を続行する。また、ステップＳ２０２の判別処理において、所定の事象の発生を検知したと判別したときには、プロファイル処理部１０２は、プロファイルＤＢ１０４の該当データを変更したり更新したりする処理を実行する（ステップＳ２０３）。

なお、ステップＳ２０３においては、住所の変更などである場合には、該当データの該当項目が変更され、事故、結婚、出産、死亡等の事象の発生の場合には、例えば、更新履歴欄に当該事象の発生を示す情報が更新される。そして、プロファイル保守部１０２は、検知した事象の発生、すなわち、どのデータについてどのような事象が発生したかを儀礼代行処理部１０３に通知する（ステップＳ２０４）。この後、ステップＳ２０１からの処理を繰り返し、クロール処理を続行する。

このように、この実施の形態の儀礼代行サーバ１のプロファイル保守部１０２は、プロファイルＤＢ１０４に格納されているデータに対応するユーザやビジネス先や個人相手先について、所定の事象が発生した場合をクロール処理により検知し、これを儀礼代行処理部１０３に通知することができる。

図１１は、図８の（４）に示したカレンダ回路１０８が提供する現在年月日に基づいて、いわゆる季節性の儀礼の実行時期の到来を検知する場合の処理について説明するためのフローチャートである。

プロファイル保守部１０２は、所定のタイミングで図１１に示す処理を実行し、カレンダ回路１０８が提供する現在年月日と、スケジュール管理メモリ１０６の管理情報とを比較する（ステップＳ３０１）。そして、プロファイル保守部１０２は、ステップＳ３０１の比較結果に基づいて、上述もしたように、年賀状、暑中見舞、お中元、お歳暮の発送時期など、スケジュール管理メモリ１０６において管理されている儀礼の実行時期が到来したか否かを判別する（ステップＳ３０２）。

ステップＳ３０２の判別処理において、儀礼の実行時期が到来したと判別したときには、プロファイル保守部１０２は、儀礼の実行時期が到来したことを儀礼代行処理部１０３に通知する（ステップＳ３０３）。このステップＳ３０３の通知処理においては、どのような儀礼の実行時期が到来したかが通知するようにされる。

そして、ステップＳ３０３の通知処理の後、および、ステップＳ３０２の判別処理において、儀礼の実行時期は到来していないと判別したときには、この図１１に示し処理を終了し、次の実行時期を待つことになる。なお、図１１に示す処理は、季節性の儀礼の実行時期の到来を検知するものであるため、各月の１日、１０日、２０日などのように、１ヶ月に数回程度実行すればよい。しかし、処理内容も多くないので、１日に１回予め決められた時刻に実行するようにしてももちろんよい。

図１２は、図８の（４）に示したカレンダ回路１０８が提供する現在年月日に基づいて、期日の明確なお祝い等の実行時期の到来を検知する場合の処理について説明するためのフローチャートである。

プロファイル保守部１０２は、所定のタイミングで図１２に示す処理を実行し、カレンダ回路１０８が提供する現在年月日と、各ユーザのビジネス関係相手先ファイルや個人関係相手先ファイルのデータの生年月日、記念日情報の日付情報、家族情報の生年月日のそれぞれとを比較する（ステップＳ４０１）。そして、プロファイル保守部１０２は、ステップＳ４０１の比較結果に基づいて、ビジネス先や個人相手先の誕生日、ビジネス先や個人相手先の記念日、ビジネス先や個人相手先の家族のお祝いなどのいわゆるお祝いの実行時期が到来したか否かを判別する（ステップＳ４０２）。

このステップＳ４０２においては、例えば、誕生日の当日にお祝いの実行時期の到来を検知しても処理が間に合わないため、例えば、実際の該当日の例えば、１週間前などの時点において、お祝いの実行時期が到来したことが検知するようにされる。また、家族の誕生日から、小学校、中学校、高校の卒業時期や入学時期などの到来も検知することができるようにされる。

ステップＳ４０２の判別処理において、お祝いの実行時期が到来したと判別したときには、プロファイル保守部１０２は、お祝いの実行時期が到来したことを儀礼代行処理部１０３に通知する（ステップＳ４０３）。このステップＳ４０３の通知処理においては、どのデータの相手先について、どのようなお祝いの実行時期が到来したかが通知するようにされる。

そして、ステップＳ４０３の通知処理の後、および、ステップＳ４０２の判別処理において、お祝いの実行時期は到来していないと判別したときには、この図１２に示し処理を終了し、次の実行時期を待つことになる。なお、図１２に示す処理は、例えば、１日に１回予め決められた時刻に実行される処理である。

［儀礼等の代行処理］
次に、代行サーバ１の主に儀礼代行処理部１０３によって行われる儀礼等の代行処理について説明する。図１３は、代行サーバ１の主に儀礼代行処理部１０３によって行われる儀礼等の代行処理について説明するためのフローチャートである。この図１３に示すフローチャートの処理は、上述した図９〜図１２のいずれかの処理により、プロファイル保守部１０２から儀礼代行処理部１０３に対して所定の事象の発生が検知されたことが通知された場合に、儀礼代行処理部１０３において実行される。

まず、儀礼代行処理部１０３は、プロファイル保守部１０２からの通知内容に基づいて、ユーザデータの変更が生じたか否かを判別する（ステップＳ５０１）。ステップＳ５０１の判別処理において、ユーザデータの変更が生じたと判別したときには、儀礼代行処理部１０３は、変更の通知対象となっている相手先に対して、ユーザデータの変更の通知処理を実行する（ステップＳ５０２）。このステップＳ５０２の通知処理は、各ビジネス関係相手先ファイルのビジネス先データと各個人関係相手先ファイルの個人相手先データの変更通知についての指示情報及び変更通知の対象項目に基づいて、ユーザデータの当該変更が通知事項として登録されているビジネス先や個人相手先に対して、登録されている方法（はがき、手紙、電報、Ｖメール、Ｅメール、電話等）で行うようにされる。

次に、儀礼代行処理部１０３は、ユーザデータの私的な情報について変更が生じたか否かを判別する（ステップＳ５０３）。ユーザの自宅住所や自宅電話番号が変更になった場合には、所属しているサークルや利用しているクレジット会社などに通知する必要が生じるためである。ステップＳ５０３の判別処理において、ユーザデータの私的な情報に変更が生じたと判別したときには、儀礼代行処理部１０３は、変更の通知対象となっている所属・加入先に対して、ユーザデータの変更の通知処理を実行する（ステップＳ５０４）。このステップＳ５０４の通知処理は、各所属・加入先ファイルに属する所属・加入先データの変更通知についての指示情報及び変更通知の対象項目に基づいて、ユーザデータの当該変更が通知事項として登録されている所属・加入先に対して、登録されている方法（はがき、手紙、Ｅメール、電話等）で行うようにされる。

ステップＳ５０４の処理の後、および、ステップＳ５０１の判別処理においてユーザデータの変更は生じていないと判別した場合、および、ステップＳ５０３の判別処理において、ユーザデータの私的な情報に変更は生じていないと判別したときには、儀礼代行処理部１０３は、ステップＳ５０５の判別処理を実行する。すなわち、儀礼代行処理部１０３は、プロファイル保守部１０２からの通知内容に基づいて、ビジネス先または個人相手先に所定の事象が発生したか否かを判別する（ステップＳ５０５）。ここで、所定の事象とは、上述もしたように、ビジネス先や個人相手先についての誕生日、記念日、家族のお祝いの時期の到来や、ビジネス先や個人相手先の結婚、出産、事故、死亡などの発生である。

ステップＳ５０５の判別処理において、ビジネス先または個人相手先に所定の事象が発生した判別した時には、儀礼代行処理部１０３は、所定の事象が発生した相手先のデータにより特定される相手先に対して、儀礼やお祝い等の処理の実行を代行する（ステップＳ５０６）。この場合、儀礼代行処理部１０３は、当該所定の事象が発生した相手先のデータであるビジネス先データまたは個人相手先データの儀礼対応情報に基づいて、ユーザに代わり儀礼等の処理を実行する。

また、ステップＳ５０５の判別処理において、ビジネス先または個人相手先に所定の事象は発生していないと判別した時には、儀礼代行処理部１０３は、プロファイル保守部１０２からの通知内容に基づいて、所定の儀礼の実行時期が到来したか否かを判別する（ステップＳ５０７）。このステップＳ５０７の判別処理は、年賀状や書中見舞などの季節性の儀礼の実行時期が到来したか否かを判別する処理である。

ステップＳ５０７の判別処理において、所定の儀礼の実行時期が到来したと判別したときには、儀礼代行処理部１０３は、当該季節性の儀礼の実行を代行する（ステップＳ５０６）。この場合、儀礼代行処理部１０３は、当該季節性の儀礼が発生した相手先のデータであるビジネス先データまたは個人相手先データの儀礼対応情報に基づいて、ユーザに代わり儀礼等の処理を実行する。

このようにして、儀礼代行処理部１０３は、プロファイルＤＢ１０４において管理されているユーザデータに変更が生じた場合には、所定の相手先に変更通知を自動的に送付することができる。また、儀礼代行処理部１０３は、プロファイルＤＢ１０４においてプロファイルデータが管理されている相手先について所定の事象（事柄）が発生した場合に、その事象に応じて、お祝い、お見舞い、お悔やみ等のいわゆる儀礼を代行して行うことができる。さらに、儀礼代行処理部１０３は、年賀状、暑中見舞、お中元、お歳暮といった季節性の儀礼の実行時期になった場合には、プロファイルＤＢ１０４で管理されているプロファイルデータに基づいて、当該季節性の儀礼を自動的に行うようにすることができる。

［儀礼等の代行処理時におけるユーザへの通知］
なお、上述した実施の形態においては、プロファイルＤＢ１０４に予め登録されているプロファイルデータに応じて儀礼等の処理の代行を行うようにしているので、儀礼代行時において、儀礼を代行することをユーザに通知する処理は行わないようにした。

しかし、実際には、所定の儀礼を行うようにプロファイルデータに登録していても、直近の状況などに応じて、当該儀礼を行わないようにしたいといった場合も発生する。そこで、例えば、ユーザが自己の端末装置２や携帯端末装置３を通じて、ユーザデータや相手先のプロファイルデータの変更を行った場合であって、例えば、当該端末装置２や携帯端末装置３に設けられた通知連絡ボタンや代行処理ボタンなどの所定の操作キーを押下操作した場合に、変更通知や儀礼等の代行処理を行うように、儀礼代行処理部１０３を制御すこともできる。

また、通知処理や儀礼代行処理を行う前に、どの相手先にどのような処理を行うのかをユーザに通知し、ユーザが当該処理の実行を指示した場合に通知や儀礼等の当該処理についての代行を行うようにすることもできる。当該ユーザへの通知は、例えば、Ｖメール（ボイスメール）やＥメール（電子メール）により行うようにするなどのことができる。

また、別の例として、例えば、年賀状や暑中見舞など多数の相手先に対して行う儀礼についてはユーザへの事前通知は行わないようにする。そして、お中元、お歳暮、誕生日や記念日のお祝い、家族のお祝い、あるいは、お悔やみやお香典のお届けなどの予め決められた儀礼等の代行については、ユーザへの事前通知を行うようにすることもできる。この場合には、プロファイルデータの儀礼対応情報の対応する儀礼についての指示情報に、事前通知の有無の欄を設けるようにしておけばよい。また、儀礼代行処理部１０３が儀礼を代行する処理を行った後に、どの相手先にどのように儀礼を代行するようにしたかを事後に通知するようにすることもできる。

このように、変更通知や種々の儀礼等の実行に際しては、ユーザの確認を得てから実行したり、また、実行した後に実行の事実をユーザに通知したりするなどのことができるようにされる。

［変更通知の出し忘れ防止対策］
なお、上述した実施の形態において、ユーザデータに変更が生じた場合に、当該ユーザに対応するビジネス関係相手先ファイルと個人関係相手先ファイルに登録されている相手先に対して、変更通知に関する指示情報に応じて変更通知を行うようにした。しかし、変更通知を出したい相手先のプロファイルデータをビジネス関係相手先ファイルや個人関係相手先ファイルに登録し忘れている場合もあると考えられる。

そこで、ユーザデータに変更が生じた場合に、当該ユーザデータに対応するユーザのプロファイルデータを登録しているビジネス関係相手先ファイルや個人関係相手先ファイルを検索する。そして、変更が生じたユーザデータに対応するユーザのプロファイルデータを登録しているビジネス関係相手先ファイルや個人関係相手先ファイルが存在した場合には、それらのファイルに関連付けられたユーザに、予め決められた方法で変更通知を送付することも可能である。

これにより、自己のファイルに未登録の相手先であって、自己に関係するであろう相手先に対しても、漏れなく変更通知を送付することができる。なお、変更通知の送付前に、自己のファイルに未登録の当該ユーザに変更通知を送付するか否かをＥメール等によりユーザに確認し、送付する場合には、送付方法の指示を受けて、当該方法により送付するようにすればよりよい。

［ユーザの端末装置や携帯端末装置のデータの更新］
なお、上述もしたように、代行サーバ１のプロファイルＤＢ１０４で管理される相手先のプロファイルデータについては、基本的な情報が同じある得意先リストやアドレス帳データ等がユーザの端末装置２や携帯端末装置３に残っている場合もある。

そこで、代行サーバ１のプロファイルＤＢ１０４で管理されているプロファイルデータの住所や電話番号などの基本的な情報に変更が生じた場合には、これをＥメール等により、対応するユーザの端末装置２や携帯端末装置３に通知することもできる。この場合、端末装置２や携帯端末装置３に、代行サーバ１からの情報変更通知に応じて情報を書き換えるソフトウェアを搭載しておくことにより、端末装置２や携帯端末装置３の該当データを自動的に変更することもできる。

具体的には、行サーバ１のプロファイルＤＢ１０４で管理されているプロファイルデータの住所や電話番号などの基本的な情報に変更が生じた場合に、代行サーバ１が例えばＥメールにより、当該ユーザの端末装置２あるいは携帯端末装置３にどの相手先のどの情報が変更になったかを通知するデータの変更通知を行う。当該ユーザの端末装置２あるいは携帯端末装置３は、当該変更通知の内容を自機のＬＣＤ（Liquid Crystal Display）等の表示素子の表示画面に表示してユーザに確認を求める。そして、ユーザが変更を許可する操作を行った場合に、得意先リストやアドレス帳データの氏名などの所定の情報が一致するデータの該当データを変更する処理を実行する。

このようにしておくことにより、代行サーバ１のプロファイルＤＢ１０４に登録したプロファイルデータと、ユーザの端末装置や携帯端末装置に残っている得意先リストやアドレス帳データの整合性をユーザの手を煩わせることなく維持することができる。

［その他］
なお、上述した実施の形態においては、代行サーバ１のプロファイルＤＢ１０４が第１、第２の記憶手段を実現し、プロファイル保守部１０２が検知手段を実現し、儀礼代行処理部１０３が、処理手段を実現している。また、通信部１０１が通信手段を実現し、入力操作部１０７が受付手段を実現し、カレンダ回路１０８がカレンダ手段を実現している。

また、上述した実施の形態の端末装置２や携帯端末装置３と代行サーバ１とが通信ネットワーク１００を通じて接続されることにより、この発明により代行システムの一実施の形態を構成している。

また、主に、図９〜図１３を用いて説明した処理が、この発明の方法によって実現される処理である。また、図９〜図１３を用いて説明した処理を実行するプログラムを形成し、これを所定のサーバ装置に搭載することによって、この発明の代行装置を実現することができる。この場合、当該サーバ装置には、プロファイルＤＢやこれにデータを登録するためのエントリープログラムも用意する必要がある。

また、上述した実施の形態において例示したユーザや相手先についての所定の事象（事柄）はあくまでも一例であり、その他の種々の事象、例えば、人事異動、入社、退社、新規事業の開始、事業の閉鎖等、種々の事象を検知するようにすることが可能である。

また、上述した実施の形態の代行サーバ１は、多数のユーザの個人情報等を扱うものである。このため、代行サーバ１を運営する団体あるいは会社は、個人情報保護に関して一定の要件を満たした事業者等に対し、財団法人日本情報処理開発協会（ＪＩＰＤＥＣ）により使用を認められる登録商標であるプライバシーマーク（Ｐマーク）の利用ライセンスを取得するなど、社会的信頼性を獲得しておくことが望ましい。

１…プロファイル管理及び儀礼代行サーバ（代行サーバ）、１０１…通信部、１０２…プロファイル保守部、１０３…儀礼代行処理部、１０４…プロファイルＤＢ、１０５…地図ＤＢ、１０６…スケジュール管理メモリ、１０７…操作入力部、１０８…カレンダ回路、１１０…制御部、１１１…ＣＰＵ、１１２…ＲＯＭ、１１３…ＲＡＭ、１１４…ＥＥＯＲＯＭ、１１５…ＣＰＵバス、２…端末装置、３…携帯端末装置、４…基地局、５、６…Ｗｅｂページ、７…印刷会社のサーバ、８…デパートのサーバ、９…オペレータ会社のサーバ、１０…電話会社のサーバ

Claims (7)

1. １以上のユーザについてのユーザデータを記憶する第１の記憶手段と、
   各ユーザの１以上の相手先のそれぞれについてのデータであって、各相手先に対して設定された処理に関する指示情報を含むプロファイルデータをユーザ毎に記憶する第２の記憶手段と、
   前記ユーザデータにより特定されるユーザあるいは前記プロファイルデータにより特定される相手先に関する事象の発生を検知する検知手段と、
   前記検知手段により事象の発生が検知された場合に、対応する相手先の前記プロファイルデータの前記指示情報に基づいて、当該相手先に対して設定された処理を実行するようにする処理手段と
   を備えることを特徴とする代行装置。
2. 請求項１に記載の代行装置であって、
   通信ネットワークを通じて通信を行うための通信手段を備え、
   前記検知手段は、前記通信手段を通じて前記ユーザからの前記ユーザデータあるいは前記プロファイルデータについての変更情報を受け付けた場合に、前記ユーザデータにより特定されるユーザあるいは前記プロファイルデータにより特定される相手先に、前記変更情報に応じた事象が発生したことを検知する
   ことを特徴とする代行装置。
3. 請求項１または請求項２に記載の代行装置であって、
   通信ネットワークを通じて通信を行うための通信手段を備え、
   前記検知手段は、前記通信手段を通じて接続される前記通信ネットワーク上に開示された情報を参照していくことにより、前記ユーザデータにより特定されるユーザあるいは前記プロファイルデータにより特定される相手先に関する事象の発生を検知することを特徴とする代行装置。
4. 請求項１、請求項２または請求３に記載の代行装置であって、
   オペレータからの操作入力を受け付ける受付手段を備え、
   前記検知手段は、前記受付手段を通じて前記ユーザからの前記ユーザデータあるいは前記プロファイルデータへの変更情報を受け付けた場合に、前記ユーザデータにより特定されるユーザあるいは前記プロファイルデータにより特定される相手先に、前記変更情報に応じた事象が発生したことを検知する
   ことを特徴とする代行装置。
5. 請求項１、請求項２、請求項３または請求項４に記載の代行装置であって、
   前記相手先に対して設定された処理は、予め決められた時期に、あるいは、前記プロファイルデータに予め登録された時期に行うべきものであり、
   カレンダ情報を提供するカレンダ手段を備え、
   前記検知手段は、前記カレンダ手段により提供されるカレンダ情報に基づいて前記予め決められた時期が到来したと判別した場合、あるいは、前記カレンダ手段により提供されるカレンダ情報と前記プロファイルデータに予め登録された時期とに基づいて、前記予め登録された時期が到来したと判別した場合に、前記プロファイルデータにより特定される前記相手先に関する事象が発生したことを検知する
   ことを特徴とする代行装置。
6. ユーザについてのユーザデータが第１の記憶手段に記憶され、各ユーザの１以上の相手先のそれぞれについてのデータであって、各相手先に対して設定された処理に関する指示情報を含むプロファイルデータがユーザ毎に区別可能な態様で第２の記憶手段に記憶されており、
   前記ユーザデータにより特定されるユーザあるいは前記プロファイルデータにより特定される相手先に関する事象の発生を検知手段が検知する検知工程と、
   前記検知工程において事象の発生を検知した場合に、対応する相手先の前記プロファイルデータの前記指示情報に基づいて、処理手段が当該相手先に対して設定された処理を実行するようにする処理工程と
   を有することを特徴とする代行方法。
7. 通信ネットワークを通じて接続される１以上の端末装置と代行サーバ装置とからなる代行システムであって、
   前記端末装置は、
   ユーザに関する情報からなるユーザデータと、当該ユーザの１以上の相手先のそれぞれについてのデータであって、それぞれの相手先に対して設定された処理に関する指示情報を含むプロファイルデータとを前記代行サーバ装置に送信する送信手段を備え、
   前記代行サーバ装置は、
   前記端末装置からの前記ユーザデータを受信する第１の受信手段と、
   前記第１の受信手段を通じて受け付けた前記ユーザデータを記憶する第２の記憶手段と、
   前記端末装置からの１以上の相手先のそれぞれについてのプロファイルデータを受信する第２の受信手段と、
   前記第２の受信手段を通じて受信した１以上の相手先のそれぞれについての前記プロファイルデータをユーザ毎区別可能に記憶する第２の記憶手段と、
   前記ユーザデータにより特定されるユーザあるいは前記プロファイルデータにより特定される相手先に関する事象の発生を検知する検知手段と、
   前記検知手段により事象の発生が検知された場合に、対応する相手先の前記プロファイルデータの前記指示情報に基づいて、当該相手先に対して設定された処理を実行するようにする処理手段と
   を備えることを特徴とする代行システム。

Images