(57)【要約】 【課題】ユーザ同士の情報共有が容易な情報管理サーバを提供する。【解決手段】サーバ１において、ユーザＩＤ管理部１１０は、登録ユーザの情報を記憶し、データベース１３０には、各登録ユーザが入力したデータ等が保存され、ユーザＤＢ管理部１２０は、要求を行ったユーザの情報に応じてインデックス情報を生成して、ブログ画面を示す画面データを生成し、ユーザＤＢ管理部１２０は、要求を行ったユーザの情報に応じてインデックス情報を生成して、受信メール情報や更新通知の有無を示す画面データを生成し、サーバ管理部１００は、アクセスしたユーザの要求に応じて、生成された画面データを当該ユーザに送信し、情報配送部１４０は、ユーザからのブログ更新やメール送信の要求に応じて、ユーザＤＢ管理部１２０等に当該要求に応じたデータの更新をさせる。【選択図】図５
2007249310.tif 000002
【特許請求の範囲】
【請求項１】
予めサーバに所定のメンバーであることが登録された複数の登録ユーザにより端末に入力された情報を通信回線を通じて受信し、記憶し、前記端末で前記情報の閲覧を可能とする情報管理サーバであって、
前記一の登録ユーザにより端末に入力された、情報の伝達相手を示す送信先情報と、当該情報の内容を示す送信内容情報とを通信回線を通じて受け付ける受付部と、
前記送信先情報と前記送信内容情報とに基づき前記一の登録ユーザの閲覧画面を制御する送信元インデックス情報を更新する第１更新部と、
前記送信先情報および前記送信内容情報を記憶する情報記憶部と、
前記送信元インデックス情報に基づき、当該情報の伝達相手である他の登録ユーザの閲覧画面を制御する送信先インデックス情報を更新する第２更新部と、
を有することを特徴とする情報管理サーバ。
【請求項２】
予めサーバに所定のメンバーであることが登録された複数の登録ユーザにより端末に入力された情報を通信回線を通じて受信し、記憶し、前記端末で前記情報の閲覧を可能とする情報管理サーバであって、
前記一の登録ユーザにより端末に入力された、情報の伝達相手を示す送信先情報と、当該情報の内容を示す送信内容情報とを通信回線を通じて受け付ける受付部と、
前記送信先情報と前記送信内容情報とに基づき前記一の登録ユーザの閲覧画面を制御する送信元インデックス情報を更新する第１更新部と、
前記送信先情報および前記送信内容情報を記憶する情報記憶部と、
前記送信先情報に基づき、当該情報を伝達したい相手が前記登録ユーザであるかどうかを判断する判断部と、
当該情報の伝達相手が登録ユーザである場合は、前記送信元インデックス情報に基づき、前記他の登録ユーザの閲覧画面を制御する送信先インデックス情報を更新する第２更新部と、
当該情報を伝達したい相手が登録ユーザでない場合は、前記送信元インデックス情報に基づき、所定の電子メールデータを生成する電子メール生成部と、
を有することを特徴とする情報管理サーバ。
【請求項３】
予めサーバに所定のメンバーであることが登録された複数の登録ユーザにより端末に入力された情報を通信回線を通じて受信し、記憶し、前記端末で前記情報の閲覧を可能とする情報管理サーバであって、
登録ユーザでないユーザの端末から通信回線を通じて送信された、情報の伝達相手である前記一の登録ユーザを示す送信先情報と、当該情報の内容を示す送信内容情報とを通信回線を通じて受信する外部メール受信部と、
前記送信先情報と前記送信内容情報とに基づき前記一の登録ユーザの閲覧画面を制御する送信元インデックス情報を更新する第１更新部と、
を有することを特徴とする情報管理サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを通じてユーザが情報を伝達するための技術に関する。
【背景技術】
【０００２】
従来、情報共有システムにおいて情報の発信者の発信情報が更新された場合には、他のシステム利用者に対して、当該更新があったことを通知するシステムがある。
【特許文献１】特開２００３−３０８４５８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
従来、インターネット等の通信ネットワークを利用した情報共有システムとして、メール、ブログといったものがある。しかし、これらは個別にツールを使い分ける必要があり、ユーザにとっては煩わしい。また、メールは、情報の送信者および受信者の双方に情報内容を記憶させるため、記憶容量が増加する。ブログは、一方的な情報発信になり、個人宛に情報を直接的に送るものではない。
【０００４】
また、最近では、ソーシャルネットワーキングサイトと呼ばれる会員登録制の情報共有技術が提案されているが、登録制をとる場合、登録されたユーザ同士では当該ソーシャルネットワーキングの形式に合わせたサービスを利用して、ブログによる情報共有ができるが、登録されていないユーザにも同様の情報を共有したい場合は、形式が異なるため、改めて電子メールソフトを立ち上げ、電子メールに同じ内容の情報を入力し、送信するという手順を余儀なくされており、登録ユーザと非登録ユーザとでは完全に分断されていた。
【０００５】
本発明は、上記課題に鑑みたものであり、その目的は、登録制のサービスに加入しつつも、ユーザがツールの形式や手続き、ならびに情報を共有したい相手が登録されたユーザかそうでないかを意識することなくシームレスに情報の発信・閲覧を可能とし、ユーザの利便性を高めるとともに、登録ユーザが非常に多くなり大量の情報交換があってもサーバ内での通信トラフィックの軽減および記憶容量の節約を図ることにある。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、本発明に係るサーバは、予めサーバに所定のメンバーであることが登録された複数の登録ユーザにより端末に入力された情報を通信回線を通じて受信し、記憶し、前記端末で前記情報の閲覧を可能とする情報管理サーバであって、前記一の登録ユーザにより端末に入力された、情報の伝達相手を示す送信先情報と、当該情報の内容を示す送信内容情報とを通信回線を通じて受け付ける受付部と、前記送信先情報と前記送信内容情報とに基づき前記一の登録ユーザの閲覧画面を制御する送信元インデックス情報を更新する第１更新部と、前記送信先情報および前記送信内容情報を記憶する情報記憶部と、前記送信元インデックス情報に基づき、当該情報の伝達相手である他の登録ユーザの閲覧画面を制御する送信先インデックス情報を更新する第２更新部と、を有することを特徴とする。
【０００７】
また、本発明に係るサーバは、予めサーバに所定のメンバーであることが登録された複数の登録ユーザにより端末に入力された情報を通信回線を通じて受信し、記憶し、前記端末で前記情報の閲覧を可能とする情報管理サーバであって、前記一の登録ユーザにより端末に入力された、情報の伝達相手を示す送信先情報と、当該情報の内容を示す送信内容情報とを通信回線を通じて受け付ける受付部と、前記送信先情報と前記送信内容情報とに基づき前記一の登録ユーザの閲覧画面を制御する送信元インデックス情報を更新する第１更新部と、前記送信先情報および前記送信内容情報を記憶する情報記憶部と、前記送信先情報に基づき、当該情報を伝達したい相手が前記登録ユーザであるかどうかを判断する判断部と、当該情報の伝達相手が登録ユーザである場合は、前記送信元インデックス情報に基づき、前記他の登録ユーザの閲覧画面を制御する送信先インデックス情報を更新する第２更新部と、当該情報を伝達したい相手が登録ユーザでない場合は、前記送信元インデックス情報に基づき、所定の電子メールデータを生成する電子メール生成部と、を有することを特徴とする。
【０００８】
さらに、本発明に係るサーバは、予めサーバに所定のメンバーであることが登録された複数の登録ユーザにより端末に入力された情報を通信回線を通じて受信し、記憶し、前記端末で前記情報の閲覧を可能とする情報管理サーバであって、登録ユーザでないユーザの端末から通信回線を通じて送信された、情報の伝達相手である前記一の登録ユーザを示す送信先情報と、当該情報の内容を示す送信内容情報とを通信回線を通じて受信する外部メール受信部と、前記送信先情報と前記送信内容情報とに基づき前記一の登録ユーザの閲覧画面を制御する送信元インデックス情報を更新する第１更新部と、を有することを特徴とする。
【０００９】
本発明によれば、ユーザがブログ・メールの形式や手続き、ならびに情報を共有したい相手の登録・非登録を意識することなくシームレスに情報を発信し閲覧することができ、ユーザの利便性が高まるとともに、大量の情報交換があってもサーバ内での通信トラフィックの軽減および記憶容量の節約を図ることにある。また、非登録のユーザからのメールも一元管理でき、利便性が高くなる。
【発明の効果】
【００１０】
本発明によれば、ユーザ同士の情報共有が容易な情報管理サーバを提供することができる。
【発明を実施するための最良の形態】
【００１１】
本発明の実施の形態を、図面を参照しながら説明する。図１は、本実施形態の全体図である。本実施例のサーバ１には、インターネット２を介して複数のクライアントＡ、Ｂ、Ｃ、Ｄが接続されている。
【００１２】
まずは、サーバ１が提供するサービスについて説明する。サーバ１は、いわゆる登録制のソーシャルネットワーキングサイトを提供するものであり、登録された各ユーザがブログおよびメールを利用できるようにしている。登録ユーザは、個人サイト用のＵＲＬを与えられ、サーバ１のソフトウェアや記憶資源を利用して、ブログのサイトを運営し、メールの送受信を行うことができるようになっている。登録ユーザは、パーソナルコンピュータ等のクライアントから個人サイトのＵＲＬにアクセスすることでブログの更新、メールの送受信を行うことができる。ブログ、メールの内容や添付ファイルはすべてサーバ１のデータベースに保存されるため、クライアント３には、ブログやメールのテキストデータ等を保存しないでよい。
【００１３】
各ユーザはインターネット２に接続されたパーソナルコンピュータ等からサーバ１のＵＲＬにアクセスし、所定の入会受付ページにおいて、氏名、住所等の所定事項を入力し、会員登録を行うことができる。登録を行ったユーザには、ユーザＩＤ、電子メールアドレス、個人サイト用のＵＲＬを配布し、会員登録後は、ユーザＩＤを入力してログインすることにより、個人サイトでのブログの公開、電子メール等のサービスの提供を受けることができる。
【００１４】
登録していないユーザは、サーバ１のＵＲＬにアクセスし、登録したユーザのブログなどを一定の範囲で閲覧することはできるが、その内容は制限されている。本実施形態においては、図１のユーザＡおよびユーザＢ、ユーザＣは、サーバ１が提供するサービスの会員として登録されており、ユーザＤは登録されていないものとする。
【００１５】
図２（ａ）は、登録ユーザＡが、パーソナルコンピュータの画面にウェブブラウザを利用して、登録ユーザＡの個人サイトのブログ画面１０を表示した状態を示したものである。ＵＲＬは各登録ユーザによって異なる。画面上方には、ブログの画面タイトル１１が表示され、登録ユーザＡの発信情報１２から１４が上から日付が新しい順に表示されている。各発信情報には、公開レベル１５が設定されている。また、宛先欄１６には当該発信情報を発信した相手を表示するようになっている。
【００１６】
公開レベル１５は、個人サイトのオーナーである登録ユーザが、ブログに記載された各情報について「非公開」、「グループ」、「会員」、「一般」の４段階のレベルを任意に設定することができるようになっている。「非公開」に設定すると、自己だけがその情報を閲覧することができる。「グループ」に設定すると、頻繁に連絡をとる他の会員などをグループ登録することができ、その限られた会員だけがその情報を閲覧することができる。「グループ」には、現実の友達や共通の興味を持つ他の会員同士で設定されることが多い。「会員」に設定すると、全会員が閲覧することができる。「一般」に設定すると、会員に限らず、インターネットに接続して情報を閲覧しているすべての人が閲覧することができる。したがって、複数のユーザが、同じユーザの個人サイトを閲覧しても、閲覧できる情報内容が異なる。
【００１７】
図２（ｂ）は、会員であってグループ登録されていない登録ユーザが、登録ユーザＡの画面を閲覧した状態を示すものである。図２（ａ）にあるように発信情報１２の公開レベルは「会員」、発信情報１３の公開レベルは「グループ」、発信情報１４の公開レベルは「一般」となっていることから、会員であってグループ登録されていない登録ユーザには、発信情報１３を閲覧することは許されていない。したがって、サーバ１は、会員であってグループ登録されていない登録ユーザには、登録ユーザＡのブログ画面１０は図２（ｂ）のように表示するよう制御する。
【００１８】
図３は、登録ユーザが、発信したい情報を入力する画面を示したものである。登録ユーザは、パーソナルコンピュータ等のクライアントからサーバ１の所定のＵＲＬにアクセスすることにより、ウェブブラウザに入力フォーマット２０を表示させることができる。
【００１９】
入力フォーマット２０上方には、画面タイトル２１が表示される。公開レベル２２において、これから発信する情報の公開レベルを設定することができる。宛先欄２３において、発信する情報の送り先を設定することができる。タイトル欄２４には、発信する情報のタイトルをテキスト入力する。メッセージ２５には、発信したい情報内容をテキスト入力する。補足欄２６は、発信する情報にコメントやトラックバックの許否を選択することができるようになっている。添付欄２７は、画像ファイルや文書ファイルを添付することができる。送信ボタン２８をクリックすることで、クライアントから入力データをサーバ１に送信することができる。本実施形態の個人サイトでは、登録ユーザは、この入力フォーマット２０を利用することにより、ブログ、電子メールの形式を問わず、情報を発信することができるようになっている。
【００２０】
次に、ブログのサービスについて説明する。登録ユーザは、入力フォーマット２０から、ブログとして情報を発信する場合は、宛先欄２３に何も入力をせず、送信ボタン２８をクリックして、サーバ１に入力データを送信する。サーバ１は、当該入力データを受信すると、当該登録ユーザのブログ画面１０を更新する。また、公開レベルを「グループ」、「会員」、「一般」のいずれかに設定した場合は、当該登録ユーザがグループ登録した他の登録ユーザに、当該登録ユーザのブログ画面が更新されたことを示す更新通知を行う。グループ登録されている他の登録ユーザは、更新通知を受け、当該登録ユーザのブログ画面にアクセスすることで、当該ユーザが発信した情報の内容を閲覧することができる。「非公開」に設定した場合は、宛先欄２３に設定した登録ユーザにだけ通知を行う。
【００２１】
なお、更新通知を行うレベルの設定は適宜変更が可能であり、たとえば、自身が更新した旨を自身のみに通知し、他のユーザには通知を行わない完全プライベートモードを用意しておくこともできる。自身のみが通知を受ける、との設定は、たとえば、自身のブログ画面にトラックバックがあって自身のブログ画面が更新されたことを知得したり、何らかの事故によって、自身のブログ画面が荒らされたことを検知したりするのに有用である。
【００２２】
図４は、登録ユーザＢの受信画面３０を示すものである。ＵＲＬは各登録ユーザによって異なる。受信画面３０は、受信を受けた登録ユーザのみがアクセスすることができるサイトである。受信メール欄３１には、登録ユーザＢを宛先としたメールが表示される。登録ユーザＢを宛先とするメールについては、全文または要約が表示される。また、更新通知欄３４には、グループ登録された他の登録ユーザのブログ画面の更新通知が一覧表示される。更新通知欄３４には、更新された旨のみが表示される。
【００２３】
次に、メールのサービスについて説明する。登録ユーザは、入力フォーマット２０から、宛先欄２３に情報を発信したい相手のユーザＩＤまたはメールアドレスを入力し、送信ボタン２８をクリックして、サーバ１に入力データを送信することで、メールとして情報を発信することもできる。宛先は、登録ユーザであっても、非登録ユーザであってもよい。宛先欄２３に登録ユーザを入力する場合は、情報を発信したい登録ユーザのユーザＩＤを入力する。非登録ユーザを入力する場合は、情報を発信したい非登録ユーザのメールアドレスを入力する。ユーザＩＤまたはメールアドレスは、予め宛先データを保存している「アドレス帳」から選択する形式でもよいし、直接ユーザＩＤやメールアドレスを入力する形式でもよい。
【００２４】
また、登録ユーザにメールアドレスが割り振られている場合には、ユーザＩＤにかえてメールアドレスを入力しても、ユーザＩＤに自動変換するような形態を採用することもできる。なお、登録ユーザのメールアドレスが「アドレス帳」で管理されている場合には、このような自動変換は容易に行える。
【００２５】
また、複数の宛先にまとめてメール発信できるように、あらかじめ複数のメールアドレスをグループ（メーリングリストのように）として登録しておけるようにすることもできる。
【００２６】
メールを受けた相手が登録ユーザである場合は、受け取った登録ユーザの受信画面３０の受信メール欄３１にメールの内容が表示されるようになる。メールを受けた相手が非登録ユーザである場合は、受け取った非登録ユーザのクライアントにインストールされているメール送受信ソフトを利用して、メールの内容を確認することができる。
【００２７】
また、当該メールの公開レベルを「グループ」、「会員」、「一般」のいずれかに設定した場合は、当該登録ユーザがグループ登録した他の登録ユーザに、当該登録ユーザのブログ画面が更新されたことを示す更新通知を行う。
【００２８】
なお、受信画面３０は、非登録ユーザから受信したメールを表示することもできる。受信画面３０は、自己の個人サイトおいてタブ機能を利用して、受信画面３０とブログ画面１０とを表示切替することができるようになっている。
【００２９】
また、登録ユーザから受信したメール（「ブログ」的な記事で、公開先を当該ユーザが含まれるグループに限定されているようなものを含む。）も、非登録ユーザから受信したメールと同様の形態で、本受信画面３０に表示されるように構成することも可能である。
【００３０】
この際に、特定の登録ユーザについてのみ、上記の処理を行うこととしても良い。たとえば当該ユーザの「アドレス帳」にユーザＩＤとメールアドレスの両方が登録されている登録ユーザからのメッセージについてのみ、受信メールとして表示する等である。
【００３１】
このように、登録ユーザは、入力フォーマット２０に入力するだけで、ブログの更新を行うことができるとともに、ブログと同じ内容をメールとして送信することも可能となる。また、メールを送信する場合は、情報を発信したい相手が、登録ユーザか、非登録ユーザかによってツールを変更することなく送信することができるようになっている。
【００３２】
なお、同様の形式で、コミュニティと呼ばれるウェブ上の会員向け掲示板に更新情報を掲載することとしても良い。
【００３３】
次に、上記サービスを実現するサーバ１の構成について説明する。サーバ１は、一般的なサーバ用のコンピュータによって実現されるのが典型的であり、所定のプログラムを実行することによって、ＣＰＵ（Central Processing Unit）の制御の下、一時的な記憶領域としてＲＡＭ（Random Access Memory）等を利用し、持続的な記憶領域としてハードディスクやＤＶＤ−ＲＡＭ等を利用し、外部との通信にはネットワークインターフェースカードを利用することにより、本実施形態に係るサーバ１として機能する。
【００３４】
図５は、本実施形態に係るサーバの構成の一例を示すブロック図である。サーバ１は、サーバ管理部１００、情報配送部１４０、ユーザＩＤ管理部１１０、ユーザＤＢ管理部１２０、ユーザに関連する各種の情報を蓄積するデータベース１３０、外部メール送受信部１５０からなる。
【００３５】
サーバ管理部１００は、パーソナルコンピュータ等のクライアントからのアクセスを監視し、クライアント３からの要求に応じた処理を管理する。具体的には、クライアント３からのブログの更新およびメールの送信の要求を受付け、所定のデータをユーザＤＢ管理部１２０に送る。また、クライアント３がサーバにアクセスしたときに、ウェブブラウザで閲覧可能なようにＰＨＰ（Hypertext Preprocessor）等のソフトウェアを利用して画面データを生成し、クライアント３に送信する。入力データには、公開レベル設定データ、宛先データ、タイトルデータ、メッセージデータ、コメントデータ、トラックバックデータ、トラックバックＵＲＬデータ、添付ファイルデータが含まれる。
【００３６】
ブログ画面１０の画面データを生成する際には、ユーザＤＢ管理部１２０で生成されるインデックスに基づき、アクセスしたユーザごとにブログ画面上の表示位置と内容を決定し、画面データを生成する。アクセスしたユーザごとに画面データを生成するのは、ユーザごとに公開レベルが異なるからである。通常は、ブログ画面１０の画面上から下に向かって日時が新しいデータ順に表示されるよう構成する。
【００３７】
具体的には、インデックスには、後述するように、「種別」、「種別コード」、「日時」、「タイプ」、「ユーザＩＤ」、「タイプコード」、「メール」、「宛先データ」、「送信元データ」の各データが記録されており、サーバ管理部１００はこれらのデータに基づき画面表示を制御する。
【００３８】
「種別」、「日時」に基づき画面上の上下位置や受信画面３０に表示するか、ブログ画面１０に表示するかを決定する。また、「種別」と「種別コード」により識別されるデータＩＤに基づき、データベース１３０から所定のテキストデータ等を呼び出し画面の所定位置に情報内容として表示する。「タイプ」、「ユーザＩＤ」、「タイプコード」に基づき、公開レベルを制御し、図２のブログ画面１０の公開レベル欄１５に対応する表示を行う。
【００３９】
「宛先データ」が記録されている場合は、図２のブログ画面１０の宛先欄１６に表示するように制御する。また「送信元データ」が記録されている場合は、図４の受信画面３０の送信者欄３２に表示するよう制御する。
【００４０】
受信画面３０の画面データを生成する際には、ユーザＤＢ管理部１２０で生成されるインデックスに基づき、受信したメールの情報については受信メール欄３１に表示し、更新通知があった場合には更新通知欄３４に表示するように画面データを生成する。
【００４１】
公開レベルの制御は、登録ユーザの個人サイトへのアクセス要求をしたユーザが、登録ユーザか否かをログイン情報から判断し、登録ユーザでない場合は、当該アクセス要求をされた個人サイトの登録ユーザのインデックスの「タイプ」に「一般」が設定されているレコードに記憶されている情報のみを表示するよう制御する。
【００４２】
登録ユーザである場合は、当該要求をしている登録ユーザが、当該要求を受けている個人サイトのオーナーである登録ユーザのグループ登録をされているかどうかをユーザＩＤ管理部１１０に問い合わせ、ユーザＩＤが一致するかどうかを判断する。
【００４３】
一致する場合は「タイプ」に「グループ」、「会員」および「一般」が設定されているレコードに記憶されている情報を表示するように制御する。一致しない場合は、「会員」および「一般」が設定されているレコードに記憶されている情報を表示するように制御する。
【００４４】
ログイン情報により当該サイトのオーナーである登録ユーザであると判断した場合は、「非公開」設定されている情報も含めすべてのレコードの情報を表示するように制御する。
【００４５】
ユーザＩＤ管理部１１０は、各登録ユーザの情報および各登録ユーザのグループ登録を管理する。図６は、各登録ユーザのグループ登録状況を示すグループテーブルである。たとえば、登録ユーザＡは、登録ユーザＢおよびＣをグループ登録しており、このグループには、グループＩＤ「Ａ００１」が付与されている。
【００４６】
ユーザＤＢ管理部１２０は、登録ユーザごとの個人サイトの表示画面の構成を制御する。図７は、登録ユーザＡの個人サイトの表示構成を制御するインデックスである。インデックスは、クライアント３側で入力フォーマット２０に入力され送信された入力データに基づいて生成される。「種別」は、ブログ、メール、更新通知等のいずれであるかを識別する。
【００４７】
なお、更新通知には、このほかいくつかの種類を設定できるようにしても良い。
【００４８】
種別の内容は、それぞれ、「Ｂ」はブログ、「Ｍ」は電子メール受信通知、「Ｎ」は更新通知を示す。宛先情報が含まれている場合は、「Ｍ」を記録する。宛先情報が含まれていない場合は、「Ｂ」を記録する。他者のブログ更新を示す更新通知は情報配送部１４０から更新通知として受け取るため、更新通知情報として受け取った場合に「Ｎ」を記録する。
【００４９】
「種別コード」は、それぞれのデータの識別子であり、「種別」と「種別コード」を合わせてデータＩＤを構成する。「日時」は、その情報が処理された日時を示す。
【００５０】
「タイプ」は、アクセス権限を示す。「非公開」の場合は「Ｈ」、「グループ」の場合は「Ｇ」、「会員」の場合は「Ｋ」、「一般」の場合は「Ｉ」が記録され、識別できるようになっている。「ユーザＩＤ」は、その個人サイトのオーナーである登録ユーザだけが閲覧できる場合、すなわち公開レベルを「非公開」に設定した場合に当該オーナーのユーザＩＤが記録される。
【００５１】
「タイプコード」は、ここでは、「一般」の場合は「０００」、公開レベルが「会員」の場合は「００１」、を記録するようにしている。
【００５２】
また、図６のように、ユーザＩＤ管理部１１０で管理されている登録ユーザＡのグループ登録には、登録ユーザＢおよびＣを登録しており、このグループにはグループＩＤ「Ａ００１」が付されているので、これに応じてタイプコードには「Ａ００１」が挿入されている。「メール」は、自己が電子メールを送信した場合にフラグが立つ。メールを送信する処理を行った場合は「宛先データ」にメールの宛先のユーザＩＤまたはメールアドレスが記録される。「送信元データ」には、メールの送信者のユーザＩＤまたは外部メールアドレスが記録される。
【００５３】
このようにレコードを構成することで、閲覧表示、ソートを可能とするとともに、登録ユーザの増加やグループ構成員の変更などに柔軟に対応できるようにしている。
【００５４】
データベース１３０は、各登録ユーザが入力したテキストデータ、添付ファイル等を保存し、登録ユーザごとに所定の記憶領域が割り当てられている。保存されているデータは、データＩＤによりいつでも呼び出し可能である。
【００５５】
情報配送部１４０は、各登録ユーザからのブログの更新またはメールの送信の要求に応じたサーバ内でのデータの配送を行う。具体的には、ユーザＤＢ管理部１２０でインデックスを生成すると、所定のデータが情報配送部１４０に送られる。そのデータに基づき、情報配送部１４０は、ブログまたはメールかどうか、登録ユーザ間のメールまたは非登録ユーザへのメールかどうか、更新通知を行うかどうかについて判断する。具体的には、登録ユーザＡのブログの更新を受け付けた場合は、グループ登録された登録ユーザＢおよびＣのユーザＤＢ管理部１２０に、当該ブログが更新されたことを示す更新通知を配送する。
【００５６】
また、登録ユーザ間の電子メールには宛先に任意の文字列であるユーザＩＤが使われ、非登録ユーザとの間の電子メールには宛先に「@AAA.jp」というドメイン名が使われるため、これにより両者を区別することができる。あるいは、登録ユーザには共通のドメイン名の電子メールアドレス、たとえば「@XXX.jp」が付与されているため、ドメイン名が共通のドメイン名である場合は、登録ユーザ宛の電子メールであり、異なるドメイン名である場合は、非登録ユーザ宛の電子メールであると判断することもできる。
【００５７】
受け付けた電子メールが登録ユーザ間での電子メールであると判断した場合は、宛先に含まれる登録ユーザのユーザＤＢ管理部１２０に、所定の電子メールデータを配送する。また、非登録ユーザへの電子メールであると判断した場合は、非登録ユーザとの電子メールの送受信を制御する外部メール送受信部１５０に所定の電子メールデータの配送を行う。
【００５８】
外部メール送受信部１５０は、非会員との電子メールの送受信をＳＭＴＰ（Simple Mail Transfer Protocol）とＰＯＰ（Post Office Protocol）を用いて制御する。
【００５９】
次に、本実施形態のサーバ１の処理のフローを説明する。図８は、本実施形態のサーバ１の処理を示すフローチャートである。
【００６０】
まず、クライアント３から、登録ユーザによってブログまたは電子メールの入力が行われ、サーバ１に向けて送信される。図３のとおり、入力フォーマット２０から入力される入力データは、公開レベル、宛先、タイトル、メッセージ、添付ファイルを含むデータである。
【００６１】
サーバ管理部１００は、クライアント３から送信された入力データを受信し、入力データに含まれている発信者のユーザＩＤを識別し、いずれの登録ユーザからのものかを特定する。（Ｓ１０１）。
【００６２】
次に、特定された登録ユーザのユーザＤＢ管理部１２０において、入力データに基づき当該発信者のインデックスの更新を行う（Ｓ１０２）。
【００６３】
インデックスが更新されると、データベース１３０は、タイトルやメッセージ等のテキストデータ等を保存する（Ｓ１０３）。
【００６４】
続いて、情報配送部１４０は当該発信者のインデックスを参照して、ブログまたは電子メールかどうかを判断する。本実施形態では、当該入力データ中に宛先が指定されていた場合は、当該発信者のインデックスの「メール」にフラグが立つ。「メール」にフラグが立っていない場合はブログ、「メール」にフラグが立っている場合は電子メールであると判断する（Ｓ１０４）。
【００６５】
ブログであると判断した場合、更新通知を行うかどうかを判断する。更新通知を行うかどうかは、第１段階として公開レベルがいずれに設定されているかによって判断する。当該発信者のインデックスの公開レベルを示す「タイプ」が「非公開（Ｈ）」である場合は、更新通知を行わない。公開レベルが「グループ（Ｇ）」、「会員（Ｋ）」、「一般（Ｉ）」のいずれかである場合は、更新通知を行う（Ｓ１０５）。
【００６６】
第２段階として、いずれの登録ユーザに更新通知をするかを判断する。情報配送部１４０は発信者である登録ユーザにグループ登録した登録ユーザがいるかどうかを、当該発信者のインデックスの「タイプ」を参照して判断する。「タイプ」が「グループ（Ｇ）」である場合は、更新通知を行う処理へ進む（Ｓ１０６）。
【００６７】
更新通知を行う場合は、当該発信者のインデックスの「タイプコード」を参照し、グループ登録を管理するユーザＩＤ管理部１１０に当該タイプコードを問い合わせ、グループ登録されている登録ユーザのユーザＩＤを取得し、その情報を含む更新通知を情報配送部１４０に送る（Ｓ１０７）。更新通知を受けた情報配送部１４０は、当該発信者のインデックスに基づき、ユーザＤＢ管理部１２０が管理するインデックスを書き換えて更新する（Ｓ１０８）。Ｓ１０５およびＳ１０６において、更新通知を行わない場合は、処理は終了する。
【００６８】
次に、情報配送部１４０が、Ｓ１０４において、電子メールであると判断した場合、登録ユーザ間での電子メールまたは非登録ユーザへの電子メールかを判断する。当該発信者のインデックスの宛先データを参照し、宛先がユーザＩＤである場合は登録ユーザ間での電子メールであると判断し、それ以外、すなわちドメイン名が付されている場合は非登録ユーザへの電子メールであると判断する（Ｓ１０９）。１つの電子メールに登録ユーザおよび非登録ユーザのいずれも含めることができ、電子メールの処理は宛先ごとに行われる。宛先データを参照し、登録ユーザが含まれていると判断した場合は、当該ユーザＩＤに対応するユーザＤＢ管理部１２０に電子メール通知を配送する（Ｓ１１０）。当該電子メール通知を受けたユーザＤＢ管理部１２０は、当該発信者のインデックスに基づき自己の管理するインデックスを書き換えて更新する（Ｓ１１１）。続いて、更新通知を行うかどうかのステップに移る（Ｓ１０５）。
【００６９】
宛先データを参照し、非登録ユーザが含まれていると判断した場合は、当該発信者のインデックスに基づき、データベースからテキストデータ、添付ファイルを読み出し、インターネットを通じて送信できる当該非登録ユーザを宛先とした電子メールデータを生成する（Ｓ１１２）。生成した電子メールデータは、外部メール送受信部１５０に送られ、外部メール送受信部１５０は、インターネット経由で当該電子メールデータを送信し（Ｓ１１３）、本処理を終了するが、続いて、更新通知を行うかどうかのステップ（Ｓ１０５）に移行しても良い。
【００７０】
なお、本フローチャートに示す制御の流れは、理解を容易にするためのものであり、実際には、各種のサーバ実装と同様に、各ステップの処理を互いに依存関係のある処理でグループ分けし、各処理ごとに、スレッドやプロセスとして並行に実行させるのが、一般的である。
【００７１】
各スレッド等は、それぞれが実行すべき処理に対応付けられるキューを監視していて、処理を開始できるような状況になるまで待機している。他のスレッド等からキューに処理すべき事項が投入されると、これを順次取り出して、処理を実行する。そして、キューが空になると、また待機する、という態様である。このような態様も、本発明の範囲に含まれる。
【００７２】
さて、以下では、本実施形態における登録ユーザと非登録ユーザへの電子メール送信の処理について説明する。
【００７３】
登録ユーザＡは、図３に示される入力フォーマット２０から、公開レベル２２、宛先２３、タイトル２４、メッセージ２５を入力し、添付ファイル２７がある場合はファイル添付処理を行い、入力画面を完成させる。ここで、宛先には、情報を発信したい相手である登録ユーザＢのユーザＩＤおよび非登録ユーザＤの電子メールアドレスを入力する。宛先の入力は、ユーザＩＤ管理部１１０にて予め宛先データを保存している「アドレス帳」から選択する形式でもよいし、直接ユーザＩＤや電子メールアドレスを入力する形式でもよい。ここでは、公開レベルは、「グループ」に設定するものとする。登録ユーザＡが送信ボタン２８をクリックすると、クライアントＡからインターネット２を通じてサーバ１に当該入力データが送信される。
【００７４】
サーバ管理部１００は、当該入力データを受信する。
【００７５】
当該入力データに含まれる登録ユーザＡのユーザＩＤに基づき、登録ユーザＡのデータベースＡを特定し、当該入力データは、登録ユーザＡのユーザＤＢ管理部１２０Ａに送られる。
【００７６】
ユーザＤＢ管理部１２０Ａは、当該入力データを受け取るとインデックスＡを更新する。図９は、インデックスが更新される様子を示すものである。同図（ａ）は、入力データ受信前のインデックスＡの状態を示すものである。同図（ｂ）は、入力データ受信後のインデックスＡの状態を示すものである。インデックス中の一番上のレコード１が更新されている。「種別」にはメールであることを示す「Ｍ」が記録される。「種別コード」には当該メールのＩＤが記録される。ここでは、「Ａ００８」が記録されている。「日時」には、サーバ管理部１００が受信した日時が記録される。「タイプ」には、グループを示す「Ｇ」が記録される。「ユーザＩＤ」には何も記録されない。「タイプコード」には、登録ユーザＡのグループ登録を示すグループＩＤが記録される。グループＩＤは、登録ユーザＡのユーザＩＤに基づき、ユーザＩＤ管理部１１０を参照することにより取得する。
【００７７】
図６にあるように、登録ユーザＡにはグループ登録があり、そのグループＩＤが「Ａ００１」であることから、インデックスＡの「グループＩＤ」に「Ａ００１」が記録される。登録ユーザここでは宛先データに入力があるため「メール」にはフラグが立っている。宛先データには、宛先となるユーザＩＤおよびメールアドレスが記録されている。
【００７８】
当該データに含まれるタイトルデータおよびメッセージデータ等のテキストデータ等は、登録ユーザＡの情報記憶領域であるデータベース１３０Ａに保存される。データベース１３０Ａに保存されたテキストデータ等は、「種別」および「種別コード」から識別されるデータＩＤとともに保存されており、いつでもデータを呼び出すことができるようになっている。
【００７９】
ユーザＤＢ管理部１２０Ａにより、インデックスの更新が完了すると、処理されるべきレコードの存在を情報配送部１４０に通知する。
【００８０】
情報配送部１４０は、ユーザＤＢ管理部ＡのインデックスＡを参照し、「メール」にフラグが立っていることから電子メールありと判断し、メール配送処理を開始する。
【００８１】
情報配送部１４０は、情報配送部は、インデックスＡの「宛先データ」に記録されたデータが、登録ユーザかどうかを判断する。当該登録ユーザＢのユーザＩＤに基づき、登録ユーザＢが登録ユーザであると判断するとともに、非登録ユーザＤのメールアドレスに基づき、非登録ユーザＤが登録ユーザではないと判断する。当該判断に基づき、情報配送部１４０は、宛先ごとに電子メール配送処理を決定する。
【００８２】
情報配送部１４０は、非登録ユーザについては、インデックスＡの「種別」および「種別コード」によって構成されるデータＩＤ「Ｍ−Ａ００８」に基づき、データベースＡからテキストデータ等を呼び出し、複製するとともに、インデックスＡの「宛先データ」に記録されたメールアドレスに基づき、インターネットを通じて送受信されるメールフォーマットに合わせたメールデータを生成する。
【００８３】
情報配送部１４０は、当該生成したメールデータを外部メール送受信部１５０に送る。
【００８４】
外部メール送受信部１５は、当該電子メールデータをインターネット経由で非登録ユーザＤの電子メールアドレスに送信する。クライアントＤは、非登録ユーザＤの操作により、登録ユーザＡからの電子メールを受信する。
【００８５】
情報配送部１４０は、登録ユーザについては、インデックスＡの「宛先データ」に記録された登録ユーザＢのユーザＩＤに基づき、電子メール通知をユーザＤＢ管理部１２０Ｂに送る。電子メール通知は、電子メールであることを示すデータおよび更新されたインデックスＡのレコード１の「種別コード」、「日時」、「タイプ」、「ユーザＩＤ」、「タイプコード」、「宛先データ」、「送信元データ」と同じデータである。
【００８６】
電子メール通知を受けたユーザＤＢ管理部１２０Ｂは、電子メールであることを示すデータに基づき、インデックスＢの「種別」を「Ｍ」と記録する。「種別コード」、「日時」、「タイプ」、「ユーザＩＤ」、「タイプコード」、「宛先データ」、「送信元データ」については、インデックスＡのレコード１と同じデータを記録してインデックスＢを更新する。
【００８７】
図１０は、インデックスＢの更新の様子を示すものである。図１０（ａ）は、更新前のインデックスＢを示す。同図（ｂ）は、更新後のインデックスＢを示す。なお、電子メール通知は、ユーザＤＢ管理部１２０Ｂに対し、ユーザＤＢ管理部１２０Ａの更新されたインデックスＡのレコード１を参照させ、更新させる命令としてもよい。
【００８８】
情報配送部１４０は、インデックスＡの「タイプ」および「タイプコード」に基づき、登録ユーザＡの個人サイトの更新通知を行うかどうかを判断する。ここでは、「タイプ」には公開レベル「グループ」を示す「Ｇ」が記録されていることから、更新通知を行うと判断する。
【００８９】
続いて、情報配送部１４０は、「タイプコード」を参照し、ユーザＩＤ管理部１１０に問い合わせ、通知すべき相手のユーザＩＤを特定する。ここでは、登録ユーザＡのグループ登録には登録ユーザＣが登録されていることから、登録ユーザＣのユーザＩＤ「ユーザＣ」を取得する。なお、登録ユーザＢもグループ登録されているが、登録ユーザＢは宛先に含まれているため更新通知の対象から除外する。
【００９０】
情報配送部１４０は、当該ユーザＩＤ「ユーザＣ」に基づき、ユーザＤＢ管理部１２０Ｃに、更新通知を行う。更新通知は、更新通知であることを示すデータおよび更新されたインデックスＡのレコード１の「種別コード」、「日時」、「タイプ」、「ユーザＩＤ」、「タイプコード」、「宛先データ」、「送信元データ」と同じデータである。ユーザＤＢ管理部１２０Ｃは、更新通知であることを示すデータに基づき、インデックスＣの「種別」を「Ｎ」と記録し、「種別コード」、「日時」、「タイプ」、「ユーザＩＤ」、「タイプコード」、「宛先データ」、「送信元データ」については、インデックスＡのレコード１と同じデータを記録してインデックスＣを更新する。
【００９１】
サーバ管理部１００は、登録ユーザＡの個人サイトに閲覧アクセスがあったことを検出すると、ユーザＤＢ管理部１２ＡからインデックスＡを取得する。
【００９２】
サーバ管理部１００は、当該インデックスＡの「種別」および「種別コード」によって構成されるデータＩＤ「Ｍ−Ａ００８」に基づき、データベースＡからテキストデータ等を呼び出す。
【００９３】
当該インデックスＡおよび当該テキストデータ等に基づき、登録ユーザＡの個人サイトの画面を生成する。
【００９４】
サーバ管理部１００は、登録ユーザＢの個人サイトに閲覧アクセスがあったことを検出すると、ユーザＤＢ管理部１２０ＢからインデックスＢを取得する。サーバ管理部１００は、当該インデックスＢの「種別」および「種別コード」によって構成されるデータＩＤ「Ｍ−Ａ００８」に基づき、データベースＡからテキストデータ等を呼び出す。ここで、登録ユーザＡから発信されたメール情報については、データベースＡに保存されているので、当該データＩＤ「Ｍ−Ａ００８」はデータベースＡの情報を示すものである。サーバ管理部１００は、当該電子メールのテキストデータ等についてはデータベースＡを参照して表示することとなる。サーバ管理部１００は、当該インデックスＢおよび当該テキストデータ等に基づき、登録ユーザＢの個人サイトの画面データを生成し、クライアント３に当該画面データを送信する。
【００９５】
このように、登録ユーザ宛のメールであっても非登録ユーザ宛のメールであっても同じフォーマットで入力可能であるため、ユーザは登録・非登録を意識することなく１つのツールを利用して情報をシームレスに発信することができる。また、登録ユーザ宛・非登録ユーザ宛に関わらず同じインデックスに格納されるため、画面表示も統一的に行うことが可能となっており、ユーザへの利便性は格段に高まる。登録ユーザ間ではデータベースの１つの情報を参照しあうため、記憶容量を削減することができる。
【００９６】
登録ユーザが非登録ユーザからのメールを受信する場合について説明する。非登録ユーザは、自己のクライアント３に、情報を発信したい相手である登録ユーザのメールアドレスおよびメッセージ等を入力し、インターネット経由で送信する。
【００９７】
外部メール送受信部１５０は、当該メールを受信し、情報配送部１４０に送る。
【００９８】
情報配送部１４０は、ユーザＩＤ管理部１１０に問い合わせ、当該メールアドレスとユーザＩＤとを照合し、いずれの登録ユーザのメールアドレスであるかを判別するとともに、当該メールの情報を、入力フォーマット２０の入力データに変換する。通常のメールデータには公開レベルを示すデータは存在しないので、公開レベルを示すデータを付加する。通常は「非公開」とする。
【００９９】
情報配送部１４０は、特定したユーザＩＤに対応するユーザＤＢ管理部１２０に当該入力データを送る。
【０１００】
ユーザＩＤ管理部１１０は、当該入力データを受け取ると、図７に示されたインデックスに記録し、またテキストデータ等は、当該ユーザＩＤに対応するデータベース１３０に保存される。
【０１０１】
このように、非登録ユーザからのメールについても同じインデックスに記録されるため、画面表示もシームレスに行うことが可能となっている。
【０１０２】
なお、上記実施形態においては、外部への電子メールと、登録ユーザ同士のメッセージのやりとりと、を、まとめて「メール」として扱い、これらを「ブログ」と区別して説明しているが、本発明においては、登録ユーザ同士のメッセージのやりとりは、所定の公開レベルに応じて行うことができる。
【０１０３】
したがって、公開レベルや公開先を限定した登録ユーザ同士のメッセージのやりとりであっても、「ブログ」として処理することも可能である。この場合、Ｓ１０４およびＳ１０９にかわって、外部宛の電子メールであれば、ステップＳ１１２に進み、内部宛のメッセージであれば一般的なブログ記事と同様の処理（Ｓ１０５〜Ｓ１０８に相当）を行うとともに、もし必要があれば、当該メッセージの公開レベルや公開先に応じて登録ユーザに更新があった旨を通知する（Ｓ１１０〜Ｓ１１１に相当）こととしても良い。
【産業上の利用可能性】
【０１０４】
本発明によれば、ユーザ同士の情報共有が容易な情報管理サーバを提供することができる。
【図面の簡単な説明】
【０１０５】
【図１】本発明の一つの実施形態にかかるネットワークの全体を示す説明図である。
【図２】本発明の一つの実施形態にかかるユーザＡのブログ画面を示す説明図である。
【図３】本発明の一つの実施形態にかかる入力フォーマットを示す説明図である。
【図４】本発明の一つの実施形態にかかるユーザＡの受信画面を示す説明図である。
【図５】本発明の一つの実施形態にかかるサーバの構成を示すブロック図である。
【図６】本発明の一つの実施形態にかかるグループテーブルを示す説明図である。
【図７】本発明の一つの実施形態にかかるインデックスを示す説明図である。
【図８】本発明の一つの実施形態にかかるサーバ処理を示すフローチャートである。
【図９】本発明の一つの実施形態にかかるユーザＡのインデックスを示す説明図である。
【図１０】本発明の一つの実施形態にかかるユーザＢのインデックスを示す説明図である。
【符号の説明】
【０１０６】
１      サーバ
２      インターネット
３      クライアント
１０    ブログ画面
２０    入力フォーマット
３０    受信画面
１００  サーバ管理部
１１０  ユーザＩＤ管理部
１２０  ユーザＤＢ管理部
１３０  データベース
１４０  情報配送部
１５０  外部メール送受信部
【図１】
2007249310.tif 000003
【図２】
2007249310.tif 000004
【図３】
2007249310.tif 000005
【図４】
2007249310.tif 000006
【図５】
2007249310.tif 000007
【図６】
2007249310.tif 000008
【図７】
2007249310.tif 000009
【図８】
2007249310.tif 000010
【図９】
2007249310.tif 000011
【図１０】
2007249310.tif 000012