(57)【要約】【課題】複数のＳＮＳを提供するサーバにおいて、プロパティ情報の管理を容易にする。【解決手段】複数のＳＮＳを提供するＳＮＳサーバ１０において、各ＳＮＳのユーザのプロパティ情報１３１を、各ＳＮＳに共通な項目からなる共通テーブル１３２と、各ＳＮＳに独自な項目からなる独自テーブル１３３とにより構成した。そして、ＳＮＳサーバ１０は、各ユーザのプロパティ情報の項目値を更新するとき、共通項目２１０については共通テーブル１３２の項目値を更新し、独自項目２１１については独自テーブル１３３の項目値を更新する。また、ＳＮＳサーバ１０は、各ユーザのプロパティ情報の項目値を参照するとき、共通項目２１０については共通テーブル１３２の項目値を参照し、独自項目２１１については独自テーブル１３３の項目値を参照する。【選択図】図１
2011076478.tif 000002
【特許請求の範囲】
【請求項１】
複数のＳＮＳを提供し、前記複数のＳＮＳのプロパティ情報を管理するＳＮＳサーバであって、
ネットワーク経由で、前記ＳＮＳのユーザの端末装置から各種情報の入力を受け付ける入力部と、
（１）前記ユーザのユーザＩＤごとに、前記ＳＮＳそれぞれのプロパティ情報の項目の共通項目と、その共通項目の項目値を示した共通テーブルと、（２）前記各ＳＮＳについて、そのＳＮＳを利用する前記ユーザのユーザＩＤごとに、当該ＳＮＳのプロパティ情報の項目のうち、前記共通項目以外の項目である独自項目と、その独自項目の項目値とを示した独自テーブルとを記憶する記憶部と、
前記入力部経由で入力された前記端末装置からの処理要求に基づきＳＮＳのデータ処理を実行し、その実行結果を前記端末装置へ返すＳＮＳデータ処理部と、
前記ＳＮＳデータ処理部経由で、前記端末装置から、前記ユーザの前記プロパティ情報の参照要求を受け付けたとき、前記参照要求の対象となる項目値のうち、前記共通項目の項目値については前記共通テーブルから読み出し、前記独自項目の項目値については前記独自テーブルから読み出し、その読み出した項目値を前記ＳＮＳデータ処理部へ出力するデータベース参照部と、
前記ＳＮＳデータ処理部およびデータベース参照部による処理結果を、前記端末装置へ出力する出力部とを備えることを特徴とするＳＮＳサーバ。
【請求項２】
前記ＳＮＳサーバは、
前記ＳＮＳデータ処理部経由で、前記端末装置から、前記ユーザＩＤ、項目名および項目値を含む前記プロパティ情報の更新要求を受け付けたとき、前記更新要求に基づき、前記共通テーブルおよび独自テーブルにおける当該ユーザＩＤのユーザの前記項目名の項目値を更新し、前記項目値を更新した項目および当該ユーザＩＤを示す項目ＩＤを前記ＳＮＳデータ処理部へ出力するデータベース更新部を備え、
前記記憶部は、
前記項目ＩＤと、前記更新した項目値とを対応付けた項目情報を備え、
前記データベース更新部は、
（１）前記受け付けた更新要求に前記項目ＩＤが含まれていなかった場合、前記更新要求に含まれるユーザＩＤおよび項目名を示す項目ＩＤを発行し、前記更新要求に含まれる項目値を用いて前記共通テーブルおよび独自テーブルにおける当該ユーザに関する当該項目の項目値を更新し、前記発行した項目ＩＤと、前記更新した項目値とを対応付けて、前記項目情報に記憶し、前記発行した項目ＩＤを前記ＳＮＳデータ処理部へ出力し、
（２）前記受け付けた更新要求に前記項目ＩＤが含まれていた場合において、（ａ）この更新要求に含まれる項目値が、前記項目情報における当該項目ＩＤに対応付けられた項目値とは異なるとき、前記項目情報における当該項目に関する項目値を、前記更新要求に含まれる項目値に更新し、前記項目値を用いて前記共通テーブルおよび独自テーブルを更新し、（ｂ）この更新要求に含まれる項目値が、前記項目情報における当該項目ＩＤに対応付けられた項目値と同じとき、前記共通テーブルおよび独自テーブルを更新せず、
前記ＳＮＳデータ処理部は、
前記データベース更新部から出力された項目ＩＤに対応する項目の更新要求を、再度前記データベース更新部へ出力するとき、当該出力された項目ＩＤを含む更新要求を出力することを特徴とする請求項１に記載のＳＮＳサーバ。
【請求項３】
前記ＳＮＳサーバは、
前記ＳＮＳデータ処理部経由で、前記端末装置から、前記ユーザＩＤ、項目名および項目値を含む前記プロパティ情報の更新要求を受け付けたとき、前記更新要求に基づき、前記共通テーブルおよび独自テーブルにおける当該ユーザＩＤのユーザの前記項目名の項目値を更新するデータベース更新部を備え、
前記記憶部は、前記ユーザＩＤ、項目名およびその項目名の項目の項目値を対応付けた項目情報を備え、
前記データベース更新部は、
（１）この更新要求に含まれるユーザＩＤ、項目名および項目値の組み合わせが、前記項目情報に記憶されていないとき、前記項目情報における当該ユーザの当該項目の項目値を、前記更新要求に含まれる項目値により更新し、前記ユーザＩＤ、項目名および項目値を用いて前記共通テーブルおよび独自テーブルを更新し、
（２）この更新要求に含まれるユーザＩＤ、項目名および項目値の組み合わせが、前記項目情報に記憶されているとき、前記共通テーブルおよび独自テーブルを更新しないことを特徴とする請求項１に記載のＳＮＳサーバ。
【請求項４】
前記データベース更新部は、
所定期間ごとに、前記記憶部の項目情報に記憶された最新の項目値を用いて前記共通テーブルおよび独自テーブルを更新することを特徴とする請求項２または請求項３に記載のＳＮＳサーバ。
【請求項５】
前記記憶部は、
前記ユーザのフレンドであるユーザのユーザＩＤおよびそのフレンドであるユーザの属性を示したフレンド情報を備え、
前記ＳＮＳデータ処理部は、
第１のユーザに関するデータの処理要求を受け付けたとき、前記第１のユーザに関するフレンド情報を参照して、前記処理要求の送信元の端末装置の第２のユーザが、前記第１のユーザのフレンドであり、かつ、所定の属性を持つユーザであると判断したとき、前記第２のユーザの端末装置からの処理要求に応じ、前記第１のユーザに関するデータ処理を実行することを特徴とする請求項１ないし請求項４のいずれか１項に記載のＳＮＳサーバ。
【請求項６】
複数のＳＮＳを提供し、前記複数のＳＮＳのプロパティ情報を管理するＳＮＳサーバであって、（１）前記ＳＮＳのユーザのユーザＩＤごとに、前記ＳＮＳそれぞれのプロパティ情報の項目の共通項目と、その共通項目の項目値を示した共通テーブルと、（２）前記各ＳＮＳについて、そのＳＮＳを利用する前記ユーザのユーザＩＤごとに、当該ＳＮＳのプロパティ情報の項目のうち、前記共通項目以外の項目である独自項目と、その独自項目の項目値とを示した独自テーブルとを記憶する記憶部と、前記ユーザの端末装置からの処理要求に基づきＳＮＳのデータ処理を実行し、その実行結果を前記端末装置へ返すＳＮＳデータ処理部とを備えるＳＮＳサーバが、
前記端末装置から、前記ユーザの前記プロパティ情報の参照要求を受け付けたとき、前記参照要求の対象となる項目値のうち、前記共通項目の項目値については前記共通テーブルから読み出し、前記独自項目の項目値については前記独自テーブルから読み出し、その読み出した項目値を、前記参照要求の送信元の端末装置へ出力することを特徴とするプロパティ情報管理方法。
【請求項７】
前記端末装置から、前記ユーザＩＤ、項目名および項目値を含む前記プロパティ情報の更新要求を受け付けたとき、前記更新要求に基づき、前記共通テーブルおよび独自テーブルにおける当該ユーザＩＤのユーザの前記項目名の項目値を更新し、前記項目および当該ユーザＩＤを示す項目ＩＤを前記ＳＮＳデータ処理部へ出力するデータベース更新部を備える前記ＳＮＳサーバにおける前記データベース更新部が、
（１）前記受け付けた更新要求に前記項目ＩＤが含まれていなかった場合、
前記更新要求に含まれるユーザＩＤおよび項目名を示す項目ＩＤを発行し、前記更新要求に含まれる項目値を用いて前記共通テーブルおよび独自テーブルにおける当該ユーザに関する当該項目の項目値を更新するステップと、
前記発行した項目ＩＤと、前記更新した項目値とを対応付けて、項目情報に記憶するステップと、
前記発行した項目ＩＤを前記ＳＮＳデータ処理部へ出力するステップとを実行し、
（２）前記受け付けた更新要求に前記項目ＩＤが含まれていた場合において、
（ａ）この更新要求に含まれる項目値が、前記項目情報における当該項目ＩＤに対応付けられた項目値とは異なるとき、
前記項目情報における当該項目に関する項目値を、前記更新要求に含まれる項目値に更新するステップと、
前記項目値を用いて前記共通テーブルおよび独自テーブルを更新ステップとを実行し、
（ｂ）この更新要求に含まれる項目値が、前記項目情報における当該項目ＩＤに対応付けられた項目値と同じとき、
前記共通テーブルおよび独自テーブルを更新せず、
前記ＳＮＳデータ処理部が、
前記データベース更新部から出力された項目ＩＤに対応する項目の更新要求を、再度前記データベース更新部へ出力するとき、当該出力された項目ＩＤを含む更新要求を出力することを特徴とする請求項６に記載のプロパティ情報管理方法。
【請求項８】
請求項６または請求項７に記載のプロパティ情報管理方法を、コンピュータであるＳＮＳサーバに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
ソーシャルネットワーキングサービス（ＳＮＳ）のソーシャルデータベースの管理に関する技術である。
【背景技術】
【０００２】
現在、mixi（登録商標）や、GREE（登録商標）等、様々なＳＮＳが存在し、ＳＮＳごとに、ユーザのソーシャル情報を管理している。このソーシャル情報は、ＳＮＳに用いられるユーザの情報であり、例えば、ユーザの氏名、ニックネーム、現在地、趣味等のプロパティ情報（非特許文献１参照）を含む。なお、このソーシャル情報は、プロパティ情報のほかに、フレンド（フレンド情報）、アクティビティ（アクティビティ情報）を含む。フレンド情報は、ユーザの友人、同僚、家族等、ユーザの人間関係を示す情報である。アクティビティ情報とは、ブログを書く、音楽を聴く、写真を撮る等、ユーザの行動を示す情報であり、このアクティビティ情報は、ユーザのフレンドに通知される。なお、ここでの通知は、例えば、アクティビティ情報を、ユーザのフレンドの端末装置のWebブラウザ上に文字画像等で表示することにより行われる。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】オープンソーシャル、[online]、[平成21年9月16日検索]、インターネット、<URL: http://code.google.com/intl/ja/apis/opensocial/>
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ここで、同じユーザが複数のＳＮＳを利用する場合もある。すなわち、あるサーバがＳＮＳ１，２という２つのＳＮＳを提供している場合において、ユーザＡが、この両方のＳＮＳを利用することもある。このような場合において、ＳＮＳ１のプロパティ情報とＳＮＳ２のプロパティ情報とを別個に管理することになるが、それでは管理の手間がかかる。つまり、プロパティ情報には、各ＳＮＳで共通して用いられる項目（共通項目。例えば、氏名、生年月日、住所、メールアドレス等）があり、これらをＳＮＳのプロパティ情報ごとに管理すると二重の手間となる。例えば、共通項目のうち、ユーザのメールアドレスの内容に変更があった場合、それぞれのＳＮＳのプロパティ情報のメールアドレスの情報を変更しなければならない。
【０００５】
そこで、本発明は、前記した課題を解決し、複数のＳＮＳを提供するサーバにおいて、プロパティ情報の管理を容易にすることを目的とする。
【課題を解決するための手段】
【０００６】
前記した課題を解決するため、請求項１に記載の発明は、複数のＳＮＳを提供し、複数のＳＮＳのプロパティ情報を管理するＳＮＳサーバであって、ネットワーク経由で、ＳＮＳのユーザの端末装置から各種情報の入力を受け付ける入力部と、（１）ユーザのユーザＩＤごとに、ＳＮＳそれぞれのプロパティ情報の項目の共通項目と、その共通項目の項目値を示した共通テーブルと、（２）各ＳＮＳについて、そのＳＮＳを利用するユーザのユーザＩＤごとに、当該ＳＮＳのプロパティ情報の項目のうち、共通項目以外の項目である独自項目と、その独自項目の項目値とを示した独自テーブルとを記憶する記憶部と、入力部経由で入力された端末装置からの処理要求に基づきＳＮＳのデータ処理を実行し、その実行結果を端末装置へ返すＳＮＳデータ処理部と、ＳＮＳデータ処理部経由で、端末装置から、ユーザのプロパティ情報の参照要求を受け付けたとき、参照要求の対象となる項目値のうち、共通項目の項目値については共通テーブルから読み出し、独自項目の項目値については独自テーブルから読み出し、その読み出した項目値をＳＮＳデータ処理部へ出力するデータベース参照部と、ＳＮＳデータ処理部およびデータベース参照部による処理結果を、端末装置へ出力する出力部とを備える構成とした。
【０００７】
また、請求項６に記載の発明は、複数のＳＮＳを提供し、複数のＳＮＳのプロパティ情報を管理するＳＮＳサーバであって、（１）ＳＮＳのユーザのユーザＩＤごとに、ＳＮＳそれぞれのプロパティ情報の項目の共通項目と、その共通項目の項目値を示した共通テーブルと、（２）各ＳＮＳについて、そのＳＮＳを利用するユーザのユーザＩＤごとに、当該ＳＮＳのプロパティ情報の項目のうち、共通項目以外の項目である独自項目と、その独自項目の項目値とを示した独自テーブルとを記憶する記憶部と、ユーザの端末装置からの処理要求に基づきＳＮＳのデータ処理を実行し、その実行結果を端末装置へ返すＳＮＳデータ処理部とを備えるＳＮＳサーバが、端末装置から、ユーザのプロパティ情報の参照要求を受け付けたとき、参照要求の対象となる項目値のうち、共通項目の項目値については共通テーブルから読み出し、独自項目の項目値については独自テーブルから読み出し、その読み出した項目値を、参照要求の送信元の端末装置へ出力することを特徴とするプロパティ情報管理方法とした。
【０００８】
このようにすることで、ＳＮＳサーバは、複数のＳＮＳのプロパティ情報のうち、共通項目の項目値については共通テーブルに記録し、そのＳＮＳ独自の項目については、独自テーブルに記録する。そして、端末装置からの要求に応じて、あるＳＮＳのプロパティ情報を参照する際には、共通項目の項目値については、共通テーブルから読み出し、そのＳＮＳの独自の項目の項目値については、独自テーブルから読み出せばよい。このように、共通項目については、共通テーブルにより管理することで、ＳＮＳごとにプロパティ情報を用意する必要がなくなる。よって、プロパティ情報の管理が容易になる。例えば、各ＳＮＳのプロパティ情報のうち、共通項目の項目値を更新したい場合、共通テーブルの項目値を更新しておけばよい。
【０００９】
請求項２に記載の発明は、請求項１に記載のＳＮＳサーバが、ＳＮＳデータ処理部経由で、端末装置から、ユーザＩＤ、項目名および項目値を含むプロパティ情報の更新要求を受け付けたとき、更新要求に基づき、共通テーブルおよび独自テーブルにおける当該ユーザＩＤのユーザの項目名の項目値を更新し、項目値を更新した項目および当該ユーザＩＤを示す項目ＩＤをＳＮＳデータ処理部へ出力するデータベース更新部を備え、記憶部が、項目ＩＤと、更新した項目値とを対応付けた項目情報を備え、データベース更新部は、（１）受け付けた更新要求に項目ＩＤが含まれていなかった場合、更新要求に含まれるユーザＩＤおよび項目名を示す項目ＩＤを発行し、更新要求に含まれる項目値を用いて共通テーブルおよび独自テーブルにおける当該ユーザに関する当該項目の項目値を更新し、発行した項目ＩＤと、更新した項目値とを対応付けて、項目情報に記憶し、発行した項目ＩＤをＳＮＳデータ処理部へ出力し、（２）受け付けた更新要求に項目ＩＤが含まれていた場合において、（ａ）この更新要求に含まれる項目値が、項目情報における当該項目ＩＤに対応付けられた項目値とは異なるとき、項目情報における当該項目に関する項目値を、更新要求に含まれる項目値に更新し、項目値を用いて共通テーブルおよび独自テーブルを更新し、（ｂ）この更新要求に含まれる項目値が、項目情報における当該項目ＩＤに対応付けられた項目値と同じとき、共通テーブルおよび独自テーブルを更新せず、ＳＮＳデータ処理部は、データベース更新部から出力された項目ＩＤに対応する項目の更新要求を、再度データベース更新部へ出力するとき、当該出力された項目ＩＤを含む更新要求を出力する構成とした。
【００１０】
また、請求項７に記載の発明は、請求項６に記載のプロパティ情報管理方法において、端末装置から、ユーザＩＤ、項目名および項目値を含むプロパティ情報の更新要求を受け付けたとき、更新要求に基づき、共通テーブルおよび独自テーブルにおける当該ユーザＩＤのユーザの項目名の項目値を更新し、項目および当該ユーザＩＤを示す項目ＩＤをＳＮＳデータ処理部へ出力するデータベース更新部を備えるＳＮＳサーバのデータベース更新部が、（１）受け付けた更新要求に項目ＩＤが含まれていなかった場合、更新要求に含まれるユーザＩＤおよび項目名を示す項目ＩＤを発行し、更新要求に含まれる項目値を用いて共通テーブルおよび独自テーブルにおける当該ユーザに関する当該項目の項目値を更新するステップと、発行した項目ＩＤと、更新した項目値とを対応付けて、項目情報に記憶するステップと、発行した項目ＩＤをＳＮＳデータ処理部へ出力するステップとを実行し、（２）受け付けた更新要求に項目ＩＤが含まれていた場合において、（ａ）この更新要求に含まれる項目値が、項目情報における当該項目ＩＤに対応付けられた項目値とは異なるとき、項目情報における当該項目に関する項目値を、更新要求に含まれる項目値に更新するステップと、項目値を用いて共通テーブルおよび独自テーブルを更新ステップとを実行し、（ｂ）この更新要求に含まれる項目値が、項目情報における当該項目ＩＤに対応付けられた項目値と同じとき、共通テーブルおよび独自テーブルを更新せず、ＳＮＳデータ処理部が、データベース更新部から出力された項目ＩＤに対応する項目の更新要求を、再度データベース更新部へ出力するとき、当該出力された項目ＩＤを含む更新要求を出力するプロパティ情報管理方法とした。
【００１１】
このようなＳＮＳサーバによれば、データベース更新部は、初めてプロパティ情報の項目値の更新を受け付けたユーザ、また同じユーザでも初めて更新を受け付けた項目について項目ＩＤを発行し、ＳＮＳデータ処理部へ出力する。また、この発行した項目ＩＤを項目情報として記憶しておく。そして、データベース更新部は、ＳＮＳデータ処理部から、この項目ＩＤを含む更新要求を受け付けたとき、当該ユーザのプロパティ情報のうち、前回更新した項目と同じ項目の項目値の更新であると分かる。そして、この項目ＩＤの項目の項目値が同じであれば、各テーブルの更新はせず、項目値が異なれば、各テーブルの更新を行うようにする。つまり、ＳＮＳサーバは、プロパティ情報の更新要求を受け付けたとき、更新の必要がなければ、各テーブルにアクセスしないので、各テーブルの更新処理負荷を軽減できる。よって、プロパティ情報のうち、頻繁に更新される項目の項目値（例えば、ＧＰＳ等により測定されたユーザの現在位置を示す情報）の更新処理の負荷を軽減できる。また、このように共通テーブルと、独自テーブルとによりプロパティ情報を構成することで、例えば、新規にＳＮＳのプロパティ情報を作成するときも、共通テーブルに記録されている共通項目の項目値を用いればよいので、プロパティ情報の作成が容易かつ正確なものとなる。
【００１２】
請求項３に記載の発明は、請求項１に記載のＳＮＳサーバが、ＳＮＳデータ処理部経由で、端末装置から、ユーザＩＤ、項目名および項目値を含むプロパティ情報の更新要求を受け付けたとき、更新要求に基づき、共通テーブルおよび独自テーブルにおける当該ユーザＩＤのユーザの項目名の項目値を更新するデータベース更新部を備え、記憶部が、ユーザＩＤ、項目名およびその項目名の項目の項目値を対応付けた項目情報を備え、データベース更新部が、（１）この更新要求に含まれるユーザＩＤ、項目名および項目値の組み合わせが、項目情報に記憶されていないとき、項目情報における当該ユーザの当該項目の項目値を、更新要求に含まれる項目値により更新し、ユーザＩＤ、項目名および項目値を用いて共通テーブルおよび独自テーブルを更新し、（２）この更新要求に含まれるユーザＩＤ、項目名および項目値の組み合わせが、項目情報に記憶されているとき、共通テーブルおよび独自テーブルを更新しないことを特徴とする。
【００１３】
このようにすることでも、ＳＮＳサーバは更新要求を受け付けたとき、更新の必要がなければ、各テーブルにアクセスしないので、各テーブルの更新処理負荷を軽減できる。
【００１４】
請求項４に記載の発明は、請求項２または請求項３に記載のＳＮＳサーバのデータベース更新部が、所定期間ごとに、記憶部の項目情報に記憶された最新の項目値を用いて共通テーブルおよび独自テーブルを更新することを特徴とする。
【００１５】
このようにすることで、プロパティ情報のうち、更新頻度の高い項目の項目値は項目情報上で更新しておき、各テーブルへの反映は所定期間ごとに行うので、更新要求の都度、各テーブルの更新を行う必要がなくなり、各テーブルの更新処理負荷をさらに軽減できる。
【００１６】
請求項５に記載の発明は、請求項１ないし請求項４のいずれか１項に記載のＳＮＳサーバの記憶部が、ユーザのフレンドであるユーザのユーザＩＤおよびそのフレンドであるユーザの属性を示したフレンド情報を備え、ＳＮＳデータ処理部あ、第１のユーザに関するデータの処理要求を受け付けたとき、第１のユーザに関するフレンド情報を参照して、処理要求の送信元の端末装置の第２のユーザが、第１のユーザのフレンドであり、かつ、所定の属性を持つユーザであると判断したとき、第２のユーザの端末装置からの処理要求に応じ、第１のユーザに関するデータ処理を実行することを特徴とする。
【００１７】
このようにすることで、ＳＮＳサーバはＳＮＳに関する各種データ処理について、このデータ処理要求の送信元の端末装置のユーザの属性を考慮した処理を行うことができる。例えば、フレンド情報において、データ処理の要求元の端末装置のユーザＢの属性が、「ユーザＡ」に対し「家族」である、という情報が記録されている場合、このユーザＢの「家族」に対し許可されている範囲のデータ処理を行う。具体例を挙げると、ＳＮＳサーバの提供するサービスのうち、ユーザＡのブログのコメントの追加等が許可されていれば、ユーザＢの端末装置からのコメントの追加要求に応じて、コメントを追加する。
【００１８】
請求項８に記載の発明は、請求項６または請求項７に記載のプロパティ情報管理方法を、コンピュータであるＳＮＳサーバに実行させるためのプログラムである。
【００１９】
このようにすることで、請求項６または請求項７に記載のプロパティ情報管理方法を、一般的なコンピュータに実行させることができる。
【発明の効果】
【００２０】
本発明によれば、複数のＳＮＳを提供するサーバにおいて、各ＳＮＳのプロパティ情報の管理を容易なものとすることができる。
【図面の簡単な説明】
【００２１】
【図１】本実施の形態のＳＮＳサーバを含むシステムの構成図である。
【図２】図１の共通テーブルと独自テーブルとを例示した図である。
【図３】（ａ）は、新規に共通テーブルを作成するときの手順を示すシーケンス図であり、（ｂ）は、新規に独自テーブルを作成するときの手順を示すシーケンス図である。
【図４】（ａ）は、共通テーブルに新規項目を作成するときの手順を示すシーケンス図であり、（ｂ）は、独自テーブルに新規項目を作成するときの手順を示すシーケンス図である。
【図５】（ａ）は、共通テーブルの項目値の参照処理手順を示すシーケンス図であり、（ｂ）は、独自テーブル項目値の参照処理手順を示すシーケンス図である。
【図６】（ａ）は、共通テーブルの項目値の更新処理手順を示すシーケンス図であり、（ｂ）は、独自テーブル項目値の更新処理手順を示すシーケンス図である。
【図７】共通テーブルおよび独自テーブルの更新処理の詳細を示すシーケンス図である。
【図８】第２の実施の形態のＳＮＳサーバを含むシステムの構成図である。
【図９】図８のＳＮＳデータ処理部、データベース処理部およびモジュール管理部の処理手順を示したシーケンス図である。
【発明を実施するための形態】
【００２２】
以下、本発明を実施するための形態（以下、実施の形態とする）について説明する。
【００２３】
＜構成＞
まず、図１を用いて、本実施の形態のＳＮＳ（ソーシャルネットワークサービス）サーバを含むシステムの全体構成を説明する。システムは、複数のＳＮＳを提供するＳＮＳサーバ１０と、このＳＮＳサーバ１０との間でデータの送受信を行う端末装置２０とを備える。このＳＮＳサーバ１０と端末装置２０とは、ＩＰ（Internet Protocol）ネットワーク等のネットワーク３０により接続される。ＳＮＳサーバ１０は、ネットワーク３０経由で、端末装置２０から、プロパティ情報等の参照要求、更新要求、ＳＮＳに関する各種データ処理要求を受信すると、これに対する参照結果、更新結果、各種データ処理結果を返す。
【００２４】
このようなＳＮＳサーバ１０は、入出力部（入力部および出力部）１１、処理部１２および記憶部１３を備えるコンピュータにより実現される。入出力部１１は、前記したＳＮＳに関する各種データ処理要求の受信や、各種データ処理結果の送信等を司る。処理部１２は、このＳＮＳサーバ１０全体の制御を司り、ここでは主に、ＳＮＳに関する各種アプリケーション実行処理により、ユーザの端末装置２０に対しＳＮＳの提供を行う。また、記憶部１３に記憶されるプロパティ情報１３１（後記）の参照や更新を行う。なお、ＳＮＳの提供は、ＳＮＳデータ処理部１２１によるアプリケーションの実行処理により行われ、このＳＮＳデータ処理部１２１は、１以上のＳＮＳを提供するものとする。記憶部１３は、処理部１２が処理を実行するときに必要な各種情報やアプリケーション（アプリケーションプログラム）等を記憶する。また、各ＳＮＳに関する各ユーザのプロパティ情報は、各ＳＮＳに共通な項目とその項目値を示した共通テーブル１３２と、各ＳＮＳに独自の項目とその項目値を示した独自テーブル１３３とにより構成される。このことを図２を用いて概念的に説明する。
【００２５】
例えば、各ＳＮＳで用いられるプロパティ情報は、図２の符号２１０に示すような各ＳＮＳのプロパティ情報の共通項目（氏名、生年月日等）と、符号２１１に示すような各ＳＮＳのプロパティ情報の独自項目（趣味、現在地等）とから構成される。ここで、ユーザＩＤ＝ＸＸのＳＮＳＩＤ＝Ａ１のプロファイル情報のうち、共通項目の項目値を参照する際には、共通テーブル１３２のユーザＩＤ＝ＸＸの当該項目の項目値を読み出す。また、ＳＮＳＩＤ＝Ａ１のプロファイル情報の独自項目の項目値を参照する際には、独自テーブル１３３のうち、ＳＮＳＩＤ＝Ａ１のテーブルからユーザＩＤ＝ＸＸの当該項目の項目値を読み出す。なお、このユーザＩＤ＝ＸＸのＳＮＳＩＤ＝Ａ１のプロファイル情報の全体の参照要求であれば、共通項目および独自項目の項目値を読み出し、出力する。つまり、プロファイル情報のうち、共通項目については、共通テーブル１３２の項目値を用いるので、各ユーザのプロファイル情報を、ＳＮＳごとに管理する必要がなくなる。
【００２６】
なお、図１のＳＮＳサーバ１０の入出力部１１は、ネットワーク３０でデータの通信を行うための通信インタフェース、入出力インタフェースから構成される。また、処理部１２は、このＳＮＳサーバ１０が備えるＣＰＵ（Central Processing Unit）によるプログラム実行処理や、専用回路等により実現される。さらに、記憶部１３は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、フラッシュメモリ等の記憶媒体から構成される。なお、この記憶部１３は、ＳＮＳデータ処理部１２１の機能を実現するためのアプリケーションプログラムが格納される。また、項目情報１３４（後記）は、記憶部１３のＲＡＭ（メインメモリ）上に記憶されるものとする。これは、項目情報１３４の情報は、頻繁に更新される可能性が高いからである。
【００２７】
次に、処理部１２の構成を説明する。処理部１２は、ＳＮＳデータ処理部１２１およびデータベース処理部１２２を備える。
【００２８】
ＳＮＳデータ処理部１２１は、入出力部１１で入力された端末装置２０からの要求に基づき各ＳＮＳのデータ処理を実行し、その処理結果を端末装置２０へ返す。つまり、ＳＮＳに関する各種サービスを提供する。例えば、端末装置２０からブログの更新処理要求を受け付けると、これに応じて、ブログデータ（図示省略）を更新し、その更新結果を端末装置２０へ返す。また、ＳＮＳデータ処理部１２１は、端末装置２０から、ユーザのプロパティ情報の参照要求や更新要求を受け付けたとき、データベース処理部１２２に対し、プロパティ情報の参照や更新を指示し、データベース処理部１２２から、その結果を受け取ると、端末装置２０へ返す。
【００２９】
データベース処理部１２２は、ＳＮＳデータ処理部１２１からの指示に基づき、記憶部１３に記憶されたプロパティ情報１３１、フレンド情報１３５（後記）等各種情報を参照したり、更新したりする。そして、その参照結果や更新結果を、ＳＮＳデータ処理部１２１へ出力する。このようなデータベース処理部１２２は、データベース参照部１２３と、データベース更新部１２４と、フレンド参照部１２５と、フレンド更新部１２６とを含んで構成される。
【００３０】
データベース参照部１２３は、ユーザのプロパティ情報の参照要求を受け付けると、この参照要求の対象である項目が、共通テーブル１３２の項目か、独自テーブル１３３の項目か判断する。そして、その参照対象の項目を含むテーブルから、プロパティ情報の参照要求の対象であるユーザに関する、当該項目の項目値を読み出し、ＳＮＳデータ処理部１２１へ出力する。例えば、図２を用いて説明すると、データベース参照部１２３が、ＳＮＳデータ処理部１２１経由で、ユーザＩＤ＝ＸＸの氏名の参照要求を受け付けたとき、この項目は共通項目なので、共通テーブル１３２から、このユーザＩＤ＝ＸＸの氏名に関する項目値を読み出す。また、ユーザＩＤ＝ＸＸの現在地の参照要求を受け付けたときには、独自テーブル１３３から、このユーザＩＤ＝ＸＸのＳＮＳＩＤ＝Ａ１の現在地の項目値を読み出す。そして、読み出した項目値を、ＳＮＳデータ処理部１２１へ返す。
【００３１】
データベース更新部１２４は、プロパティ情報１３１の更新要求を受け付けると、共通テーブル１３２または独自テーブル１３３の情報のうち、更新要求の対象であるＳＮＳのユーザの情報を更新する。具体的には、まず、データベース更新部１２４は、ＳＮＳデータ処理部１２１経由で、プロパティ情報１３１の更新要求を入力を受け付けたとき、この更新要求に更新要求の対象となる項目名およびユーザＩＤを示す項目ＩＤが含まれているか否かを判断する。ここで、項目ＩＤが含まれていなかった場合、データベース更新部１２４は、この更新要求の対象となる項目名およびユーザＩＤを示す項目ＩＤを発行する。この項目ＩＤは、毎回ユニークな値（またはランダムな値）を発行するものとする。そして、入力された更新要求に含まれる項目値を用いて共通テーブル１３２および独自テーブル１３３における当該ユーザに関する当該項目の項目値を更新する。また、データベース更新部１２４は、発行した項目ＩＤと、項目値とを対応付けて項目情報１３４に記憶する。そして、この発行した項目ＩＤをＳＮＳデータ処理部１２１へ出力する。つまり、当該ユーザのプロパティ情報１３１のうち、今まで更新したことのない項目の項目値の更新であれば、その項目の項目ＩＤと、項目値とを項目情報１３４に記憶しておく。また、発行した項目ＩＤを、ＳＮＳデータ処理部１２１（および更新要求の端末装置２０）へ通知し、ＳＮＳデータ処理部１２１は、再度同じユーザについて同じ項目の更新要求を出力する際には、更新要求にこの項目ＩＤを含めて出力する。よって、データベース更新部１２４は、この更新要求に項目ＩＤがあるか否かで、この更新要求が、新たなユーザからの項目値の更新要求であるか否かや、同じユーザからの新たな項目の更新要求であるか否かを判断できる。
【００３２】
また、データベース更新部１２４は、入力された更新要求に項目名およびユーザＩＤを示す項目ＩＤが含まれていた場合において、この更新要求に含まれる項目値が、項目情報１３４における当該項目ＩＤに対応付けられた項目値と同じか否かを判断する。つまり、この更新要求が、同じユーザのプロファイル情報について、同じ項目について、同じ値で更新する旨の更新要求であるか否かを判断する。ここで、同じユーザ、同じ項目について、同じ値で更新する旨の更新要求でないと判断したとき、項目情報１３４における当該項目に関する項目値を、この更新要求に含まれる項目値に更新する。また、この項目値を用いて共通テーブル１３２または独自テーブル１３３の当該項目の項目値を更新する。一方、データベース更新部１２４は、更新要求に含まれる項目値が、項目情報１３４における当該項目ＩＤに対応付けられた項目値と同じとき、つまり、ここで、同じユーザ、同じ項目について、同じ値で更新する旨の更新要求であると判断したとき、共通テーブル１３２および独自テーブル１３３を更新しない。これにより、同じユーザから同じ項目について同じ項目値の更新要求を受け付けた場合、各種テーブルの更新処理を行う必要がなくなる。
【００３３】
フレンド参照部１２５は、ＳＮＳデータ処理部１２１経由で、ユーザＩＤを含むフレンド参照要求を受け付けたとき、フレンド情報１３５において、このユーザＩＤのフレンドのユーザＩＤ（フレンドＩＤ）と、そのフレンドの属性を読み出し、ＳＮＳデータ処理部１２１へ出力する。ここで読み出したフレンドの属性は、ＳＮＳデータ処理部１２１がフレンドの属性に基づく処理を行う際に参照される。つまり、ＳＮＳデータ処理部１２１は、第１のユーザに関するデータの処理要求を受け付けたとき、このフレンド情報１３５を参照して、処理要求の送信元の端末装置２０の第２のユーザが、第１のユーザのフレンドであり、かつ、所定の属性を持つユーザであると判断したとき、第２のユーザの端末装置２０からの処理要求に応じ、第１のユーザに関するデータ処理を実行する。例えば、フレンド情報１３５において、ユーザＡに関するデータ処理を受け付け、そのデータ処理の要求元がユーザＢの端末装置２０であった場合を考える。ここで、フレンド情報１３５において、ユーザＢの属性が、「ユーザＡ」に対し「家族」である場合、ＳＮＳデータ処理部１２１は、このユーザＡの「家族」に対し許可されている範囲のデータ処理を行う。
【００３４】
フレンド更新部１２６は、ＳＮＳデータ処理部１２１経由で、フレンド情報１３５の更新要求を受け付けたとき、この更新要求に基づきフレンド情報１３５のフレンドや、そのフレンドの属性の更新等を行う。例えば、フレンド情報１３５に既に登録されたフレンドの属性の変更であれば、その変更対象のフレンドの属性を変更する。また、フレンドの追加であれば、そのユーザのフレンドＩＤを追加し、また、そのフレンドの属性を追加する。
【００３５】
次に、記憶部１３を説明する。記憶部１３は、プロパティ情報１３１と、項目情報１３４、フレンド情報１３５と、ユーザＩＤ情報１３６とを記憶する。
【００３６】
プロパティ情報１３１は、共通テーブル１３２と、独自テーブル１３３とを備える。このうち、共通テーブル１３２は、プロパティ情報１３１の項目のうち、各ＳＮＳに共通する項目（共通項目）の項目値を示したテーブルである。例えば、図２に例示するように、ユーザＩＤごとに、そのユーザの参加しているＳＮＳのＩＤ（ＳＮＳＩＤ）と、共通項目と、そのユーザに関する共通項目の値とを示した情報である。例えば、図２の共通テーブル１３２は、ユーザＩＤ「ＸＸ」のユーザのＳＮＳＩＤは、「Ａ１，Ａ２」であり、氏名は「ａａ」であり、生年月日は「ｂｂ」であることを示す。
【００３７】
また、独自テーブル１３３は、図２に例示するように、ＳＮＳごとに、そのＳＮＳに参加しているユーザＩＤと、当該ユーザに関する、そのＳＮＳの独自項目の項目値とを示したテーブルである。図２の独自テーブル１３３のうち、一番手前側のテーブルは、ＳＮＳＩＤが「Ａ１」の独自項目の項目値を示したテーブルであり、ユーザＩＤ「ＸＸ」のユーザの現在地は「ｃｃ」であり、趣味は「ｄｄ」であることを示す。
【００３８】
図１の説明に戻る。項目情報１３４は、データベース更新部１２４により、プロパティ情報１３１のうち、項目値が更新された項目の項目ＩＤと、その項目の項目値とを対応付けて示した情報である。この項目情報１３４は、例えば、記憶部１３のＲＡＭ上に記憶される。そして、この項目情報１３４に示される項目ＩＤとその項目値とは、データベース更新部１２４が、各テーブルの項目値を更新する必要があるか否かを判断するときに参照される。
【００３９】
フレンド情報１３５は、各ＳＮＳについて、そのＳＮＳの各ユーザのフレンドとなるユーザのユーザＩＤ（フレンドＩＤ）と、そのフレンドとなるユーザの属性とを示した情報である。このフレンド情報１３５は、例えば、ＳＮＳデータ処理部１２１等が、所定のユーザの端末装置２０から、データ処理要求を受け付けたとき、そのユーザの属性をもとに、そのデータ処理要求に応じて処理を実行してよいか否かを判断するときに参照される。
【００４０】
ユーザＩＤ情報１３６は、ＳＮＳごとに、そのＳＮＳに加入しているユーザのユーザＩＤを示した情報である。このユーザＩＤ情報１３６は、新規に共通テーブル１３２や独自テーブル１３３を作成する際に参照される。このユーザＩＤ情報１３６の情報は、入出力部１１経由で事前に入力されているものとする。
【００４１】
以上説明したＳＮＳサーバ１０によれば、各ＳＮＳのプロパティ情報を、個別に管理する必要がないので、管理の手間を軽減できる。また、プロパティ情報１３１の項目値の更新要求を受け付けた場合において、その更新要求に含まれる項目値が、同じユーザ、同じ項目についての同じ項目値であったとき、各テーブルへの項目値の反映を省くことができる。これにより、各テーブルの更新処理の負荷を軽減できる。さらに、フレンド情報１３５は、各ユーザのフレンドのユーザＩＤ（フレンドＩＤ）のみならず、そのフレンドの属性も含む。よって、ＳＮＳデータ処理部１２１は、このフレンドの属性に基づくデータ処理を実行することができる。
【００４２】
＜処理手順＞
次に、図１を参照しつつ、図３〜図７を用いて、ＳＮＳサーバ１０の処理手順を説明する。まず、図３（ａ）および（ｂ）を用いて、新規に共通テーブル１３２および独自テーブル１３３の作成するときの作成手順を説明する。
【００４３】
＜新規作成処理＞
図１のＳＮＳデータ処理部１２１は、入出力部１１経由で、共通テーブル１３２に設ける項目名一覧を含む新規共通テーブル作成要求を受け付けると、この作成要求をデータベース処理部１２２に出力する（図３（ａ）のＳ１１）。これを受けてデータベース処理部１２２のデータベース更新部１２４は、この項目名一覧を記憶部１３の所定領域に登録する（Ｓ１２）。そして、データベース更新部１２４は、ユーザＩＤ情報１３６から全ユーザＩＤの一覧を取得し（Ｓ１３）、Ｓ１２で記憶部１３に登録しておいた項目名一覧と、Ｓ１３で取得した全ユーザＩＤの一覧とを用いて新規の共通テーブル１３２を作成する（Ｓ１４）。作成した共通テーブル１３２は記憶部１３の所定領域に記憶する。データベース処理部１２２のデータベース更新部１２４は、新規に共通テーブル１３２を作成したことを、ＳＮＳデータ処理部１２１に通知する（Ｓ１５）。
【００４４】
また、図１のＳＮＳデータ処理部１２１は、入出力部１１経由で、独自テーブル１３３に設ける項目名一覧と、ＳＮＳＩＤとを含む新規独自テーブル作成要求を受け付けると、データベース処理部１２２に出力する（図３（ｂ）のＳ２１）。これを受けてデータベース処理部１２２のデータベース更新部１２４は、Ｓ１２と同様に、この項目名一覧を記憶部１３の所定領域に登録する（Ｓ２２）。そして、データベース更新部１２４は、ユーザＩＤ情報１３６から、Ｓ２２で受け付けたＳＮＳＩＤのユーザＩＤの一覧を取得し（Ｓ２３）、Ｓ２２で記憶部１３に登録しておいた項目名一覧と、Ｓ２３で取得したユーザＩＤの一覧とを用いて新規に独自テーブル１３３を作成する（Ｓ２４）。作成した独自テーブル１３３は記憶部１３の所定領域に記憶する。データベース処理部１２２のデータベース更新部１２４は、新規に独自テーブル１３３を作成したことを、ＳＮＳデータ処理部１２１に通知する（Ｓ２５）。以上のようにして、データベース更新部１２４は、新規に共通テーブル１３２および独自テーブル１３３を作成する。
【００４５】
＜新規項目追加処理＞
次に、図４（ａ）および（ｂ）を用いて、共通テーブル１３２および独自テーブル１３３に新規項目を追加するときの手順を説明する。まず、ＳＮＳデータ処理部１２１は、入出力部１１経由で、共通項目に関する新規項目の項目名を含む作成要求を受け付けると、この作成要求を、データベース処理部１２２に出力する（図４（ａ）のＳ３１）。これを受けてデータベース処理部１２２のデータベース更新部１２４は、新規項目の項目名を記憶部１３の所定領域に登録し（Ｓ３２）、この登録した項目名を用いて、共通テーブル１３２に新規項目を作成する（Ｓ３３）。そして、新規項目を作成した共通テーブル１３２を記憶部１３の所定領域に記憶する。次に、データベース処理部１２２は、共通テーブル１３２に新規項目を作成したことを、ＳＮＳデータ処理部１２１に通知する（Ｓ３４）。
【００４６】
また、ＳＮＳデータ処理部１２１は、入出力部１１経由で、独自テーブル１３３に関する新規項目の項目名と、ＳＮＳＩＤとを含む新規項目の作成要求を受け付けると、この作成要求をデータベース処理部１２２に出力する（図４（ｂ）のＳ４１）。これを受けてデータベース処理部１２２のデータベース更新部１２４は、Ｓ３２と同様に、新規項目の項目名を記憶部１３の所定領域に登録し（Ｓ４２）、この登録した項目名を用いて、当該ＳＮＳＩＤの独自テーブル１３３に新規項目を作成する（Ｓ４３）。そして、新規項目を作成した独自テーブル１３３を記憶部１３の所定領域に記憶する。次に、データベース処理部１２２は、この独自テーブル１３３に新規項目を作成したことを、ＳＮＳデータ処理部１２１に通知する（Ｓ４４）。以上のようにして、データベース更新部１２４は、新規に共通テーブル１３２および独自テーブル１３３を作成する。
【００４７】
＜項目値の参照処理＞
次に、図５（ａ）および（ｂ）を用いて、共通テーブル１３２および独自テーブル１３３の項目値を参照するときの手順を説明する。まず、ＳＮＳデータ処理部１２１は、入出力部１１経由で、ユーザＩＤ、参照対象となる項目の項目名を含む項目値の参照要求を受け付けると、この参照要求をデータベース処理部１２２に出力する（図５（ａ）のＳ５１）。これを受けてデータベース処理部１２２のデータベース参照部１２３は、共通テーブル１３２および独自テーブル１３３の項目名から、参照要求の項目名の検索を行う（Ｓ５２）。そして、この参照要求の項目名が共通テーブル１３２の項目であると判断すると、共通テーブル１３２から、当該ユーザＩＤの当該項目名の項目値の参照（読み出し）を行う（Ｓ５３）。そして、この共通テーブル１３２から読み出した項目値を（Ｓ５４）、ＳＮＳデータ処理部１２１に出力する（Ｓ５５）。
【００４８】
また、ＳＮＳデータ処理部１２１は、入出力部１１経由で、ユーザＩＤと、参照対象となる項目の項目名と、ＳＮＳＩＤとを含む項目値の参照要求を受け付けると（図５（ｂ）のＳ６１）、データベース処理部１２２に出力する。これを受けてデータベース処理部１２２のデータベース参照部１２３は、共通テーブル１３２および独自テーブル１３３の項目名から、項目名の検索を行う（Ｓ６２）。そして、この項目名が独自テーブル１３３の項目であると判断すると、このＳＮＳＩＤの独自テーブル１３３から当該ユーザＩＤの当該項目名の項目値の参照（読み出し）を行う（Ｓ６３）。そして、この独自テーブル１３３から項目値を読み出し（Ｓ６４）、ＳＮＳデータ処理部１２１に出力する（Ｓ６５）。以上のようにして、データベース更新部１２４は、共通テーブル１３２および独自テーブル１３３の項目値の参照処理を行う。
【００４９】
＜項目値の更新処理＞
次に、図６（ａ）および（ｂ）を用いて、共通テーブル１３２および独自テーブル１３３の項目値を更新するときの手順を説明する。まず、ＳＮＳデータ処理部１２１は、入出力部１１経由で、ユーザＩＤと、更新対象となる項目の項目名と、項目値とを含む項目値の更新要求を受け付けると、データベース処理部１２２に出力する（図６（ａ）のＳ７１）。これを受けてデータベース処理部１２２のデータベース更新部１２４は、共通テーブル１３２および独自テーブル１３３の項目名から、項目名の検索を行う（Ｓ７２）。そして、データベース更新部１２４は、この項目名が共通テーブル１３２の項目であると判断すると、共通テーブル１３２における、当該ユーザＩＤの当該項目名の項目値の更新を行い（Ｓ７３）、更新した旨をＳＮＳデータ処理部１２１に通知する（Ｓ７４）。
【００５０】
また、ＳＮＳデータ処理部１２１は、入出力部１１経由で、ユーザＩＤと、更新対象となる項目の項目名と、ＳＮＳＩＤとを含む項目値の更新要求を受け付けると（図６（ｂ）のＳ８１）、データベース処理部１２２に出力する。これを受けてデータベース処理部１２２のデータベース更新部１２４は、共通テーブル１３２および独自テーブル１３３の項目名から、項目名の検索を行う（Ｓ８２）。そして、データベース更新部１２４は、この項目名が独自テーブル１３３の項目であることを確認すると、このＳＮＳＩＤの独自テーブル１３３における、当該ユーザＩＤの当該項目名の項目値の更新を行い（Ｓ８３）、更新した旨をＳＮＳデータ処理部１２１に通知する（Ｓ８４）。
【００５１】
ここで、データベース処理部１２２による、共通テーブル１３２および独自テーブル１３３の項目値の更新処理の詳細を、図７を用いて説明する。
【００５２】
まず、ＳＮＳデータ処理部１２１は、入出力部１１経由で、更新要求の対象となるユーザＩＤと、項目名と、項目値とを含む項目値の更新要求を受け付けると、この更新要求をデータベース処理部１２２に出力する（Ｓ９１、図６（ａ）のＳ７１に相当）。そして、データベース処理部１２２のデータベース更新部１２４は、この更新要求に項目ＩＤが含まれるか否かを判断する（Ｓ９２）。ここで、更新要求に項目ＩＤが含まれていなければ（Ｓ９２のＮｏ）、新規に項目ＩＤを発行する（Ｓ９４）。そして、更新要求に含まれるユーザＩＤおよび項目名をキーとして共通テーブル１３２または独自テーブル１３３を検索し、どのテーブルのどの項目名の項目値を更新すればよいか特定する。そして、データベース処理部１２２のデータベース更新部１２４は、この特定したテーブルの、当該ユーザ、当該項目名の項目値を、更新する（Ｓ９６）。また、データベース更新部１２４は、項目情報１３４に、発行した項目ＩＤと、更新要求に含まれる項目値とを対応付けて記憶する。そして、データベース処理部１２２のデータベース更新部１２４は、発行した項目ＩＤを、ＳＮＳデータ処理部１２１に出力する（Ｓ９７）。この後、ＳＮＳデータ処理部１２１は、同じユーザから同じ項目の更新要求を受け付けたとき、この項目ＩＤを含む更新要求をデータベース処理部１２２へ出力する。
【００５３】
一方、Ｓ９２においてＳＮＳデータ処理部１２１から出力された更新要求に項目ＩＤが含まれていれば（Ｓ９２のＹｅｓ）、データベース処理部１２２のデータベース更新部１２４は、この項目ＩＤが、項目情報１３４に記憶されているか否かを判断する（Ｓ９３）。ここで、この項目ＩＤが、項目情報１３４に記憶されていれば（Ｓ９３のＹｅｓ）、この項目情報１３４における、当該項目ＩＤに対応する項目値が、今回の項目値（更新要求に含まれる項目値）と同じか否かを判断する（Ｓ９５）。一方、項目ＩＤが、項目情報１３４に記憶されていなければ（Ｓ９３のＮｏ）、Ｓ９６へ進む。
【００５４】
Ｓ９５において、この項目情報１３４における当該項目ＩＤに対応する項目値が、今回の項目値（更新要求に含まれる項目値）と同じであれば（Ｓ９５のＹｅｓ）、データベース処理部１２３のデータベース更新部１２４は、ＳＮＳデータ処理部１２１に「ＯＫ」を返却する（Ｓ９７）。このとき、データベース更新部１２４は、項目情報１３４における項目値更新も、各テーブルにおける項目値更新も行わない。つまり、前回と同じユーザから、同じ項目について、同じ項目値での更新要求を受け付けたときには、データベース更新部１２４は、各テーブルにおける更新処理を行わない。これにより、データベース更新部１２４は、各テーブルの項目値について不要な更新処理を行う必要がなくなる。また、データベース更新部１２４は、この項目情報１３４における当該項目ＩＤに対応する項目値が、今回の項目値（更新要求に含まれる項目値）と異なる値であれば（Ｓ９５のＮｏ）、Ｓ９６へ進む。つまり、データベース更新部１２４は、更新要求に示されるユーザＩＤ、項目名、項目値を用いて、各テーブルの更新処理と、項目情報１３４の更新処理とを実行する。
【００５５】
以上説明したデータベース処理部１２２のデータベース更新部１２４によれば、ユーザから新たな項目値の更新要求を受け付けたとき、項目ＩＤを発行し、その項目ＩＤをＳＮＳデータ処理部１２１に出力する。そして、このＳＮＳデータ処理部１２１は、再度同じユーザのプロファイル情報について、同じ項目の項目値の更新要求を受け付けたときには、その項目ＩＤを含む更新要求を出力する。つまり、データベース更新部１２４は、過去に同じユーザから同じ項目の更新要求を受け付けたか否か、また、その項目の項目値がどのような値かを項目ＩＤをキーとして項目情報１３４を検索できるので、データベース更新部１２４は、同じユーザから同じ項目について同じ項目値での更新要求を受け付けたか否かを迅速に判断できる。
【００５６】
なお、ここでは説明を省略したが、ＳＮＳデータ処理部１２１は、ユーザＩＤ、そのユーザのフレンドのＩＤ（フレンドＩＤ）、そのユーザの属性を示すラベルを含むフレンドの更新要求を受け付けると、この更新要求をフレンド更新部１２６へ出力する。これを受けて、フレンド更新部１２６は、フレンド情報１３５に、フレンドやその属性を更新したり、追加したりする。また、ＳＮＳデータ処理部１２１は、ユーザＩＤ、そのフレンドの属性を示すラベル等を含むフレンドの参照要求を受け付けると、この参照要求をフレンド参照部１２５へ出力する。これを受けて、フレンド参照部１２５は、フレンド情報１３５から、当該ユーザのフレンドや、そのフレンドのうち、参照要求に示される属性を持つフレンドの一覧を、ＳＮＳデータ処理部１２１へ返す。
【００５７】
＜第２の実施の形態＞
次に、図８を用いて、本発明の第２の実施の形態のＳＮＳサーバ１０Ａを説明する。第２の実施の形態のＳＮＳサーバ１０Ａは、ＳＮＳデータ処理部１２１による処理結果を示すアクティビティ情報１３９を生成することを特徴とする。前記した実施の形態と同様の構成要素は、同じ符号を付して説明を省略する。
【００５８】
＜構成＞
図８のＳＮＳサーバ１０Ａの記憶部１３は、モジュール群１３７およびモジュールテーブル１３８を記憶する。また、記憶部１３は、アクティビティ情報１３９を記憶する領域を備える。さらに、ＳＮＳサーバ１０Ａの処理部１２は、モジュール管理部１２７をさらに備える。
【００５９】
モジュール群１３７は、ＳＮＳデータ処理部１２１のアプリケーションプログラム実行処理に伴い実行されるプログラムのモジュール群である。
【００６０】
モジュールテーブル１３８は、各アプリケーションプログラムの実行処理に伴い実行されるプログラムのモジュールを示した情報である（表１参照）。
【００６１】
【表１】
2011076478.tif 000003
【００６２】
アクティビティ情報１３９は、ＳＮＳデータ処理部１２１が実行した処理内容を示す情報である。例えば、ＳＮＳデータ処理部１２１がユーザＡのブログを公開した場合、アクティビティ情報１３９は、「ユーザＡがブログを公開した」という内容になる。また、ＳＮＳデータ処理部１２１がユーザＢに対し音楽の配信サービスを提供した場合、アクティビティ情報１３９は、「ユーザＢが音楽を聴いた」という内容になり、ＳＮＳデータ処理部１２１がユーザＣの端末装置２０から、写真の画像のアップロードを受け付けた場合、アクティビティ情報１３９は、「ユーザＣが写真の画像をアップロードした」という内容になる。
【００６３】
なお、ＳＮＳデータ処理部１２１およびデータベース処理部１２２は、第１の実施の形態で述べた処理に加え、以下の処理を行う。ＳＮＳデータ処理部１２１は、アプリケーションプログラムを実行すると、このプログラムの実行に関するアクティビティ情報登録要求をデータベース処理部１２２へ出力する処理をさらに行う。データベース処理部１２２は、アクティビティ情報登録要求を受け取ると、モジュール管理部１２７に対し、このアプリケーションの実行に伴い実行するモジュール（対象モジュール）を呼び出す処理をさらに行う。
【００６４】
モジュール管理部１２７は、データベース処理部１２２からのモジュール呼び出し指示に基づき、モジュールテーブル１３８を参照して、アプリケーションプログラムの実行に伴い実行すべきプログラムのモジュールを、モジュール群１３７から選択する。そして、このモジュール管理部１２７の備えるシナリオ実行部１２８は、選択されたモジュールの実行処理を行う。
【００６５】
例えば、ＳＮＳデータ処理部１２１がユーザＡのブログを公開したとき、このことをデータベース処理部１２２に通知する。そして、この通知を受けてデータベース処理部１２２は、対象モジュールの呼び出し指示をモジュール管理部１２７に出力する。また、この対象モジュールの呼び出し指示を受けてモジュール管理部１２７は、モジュールを選択し、この選択したモジュールを起動させる。そして、シナリオ実行部１２８は、アクティビティ情報登録要求に示されるユーザＡのフレンドの検索をデータベース処理部１２２に対し要求し、ここで検索されたフレンドへ通知するアクティビティ情報を生成する。例えば、シナリオ実行部１２８は、このモジュールに基づき、アクティビティ情報登録要求に示されるユーザのフレンドの検索をデータベース処理部１２２に対し要求し、ユーザＡのフレンドがユーザＢ，Ｃであるという検索結果を得た場合を考える。この場合、シナリオ実行部１２８は、ユーザＡがブログを公開したことを示すアクティビティ情報１３９を生成し、この生成したアクティビティ情報１３９を、ユーザＢ，Ｃの端末装置２０に通知する。
【００６６】
＜処理手順＞
次に、図８を参照しつつ、図９を用いて、ＳＮＳサーバ１０Ａの処理手順を説明する。まず、データベース処理部１２２は、アプリケーションプログラムの実行処理を行うと、この実行処理に伴うアクティビティ情報１３９の登録要求（アクティビティ情報登録要求）をデータベース処理部１２２へ出力する（Ｓ１０１）。この登録要求は、このアプリケーションプログラムの実行要求の送信元の端末装置２０のユーザＩＤ、アプリケーションプログラムによる処理内容を示すＸＭＬ（Extensible Markup Language）データ（ＸＭＬ）、実行したアプリケーションプログラムのＩＤ（ＡＰＬＩＤ）を含む。このようなアクティビティ情報登録要求を受信したデータベース処理部１２２は、このアプリケーションプログラムの実行に伴い実行する対象モジュールの呼び出し指示をモジュール管理部１２７に出力する（Ｓ１０２）。この呼び出し指示は、前記したユーザＩＤ、ＸＭＬ、ＡＰＬＩＤを含む。
【００６７】
このような呼び出し指示を受け付けたモジュール管理部１２７は、この呼び出し指示に含まれるＡＰＬＩＤをキーとして、モジュールテーブル１３８を参照して、このアプリケーションの実行に伴い起動させるモジュールをモジュール群１３７の中から選択する。そして、この選択したモジュールの起動処理を行う（Ｓ１０３）。そして、シナリオ実行部１２８は、この呼び出し要求に含まれるＸＭＬを解析し（Ｓ１０４）、この解析したＸＭＬに基づくモジュールの実行を行う。ここでは、対象モジュールの呼び出し指示に含まれるユーザＩＤを示したフレンドの検索要求をデータベース処理部１２２のフレンド参照部１２５に出力し、フレンドの呼び出しを行う（Ｓ１０５）。そして、フレンド参照部１２５は、ユーザＩＤをキーとしてフレンド情報１３５から、当該ユーザのフレンド検索処理を行う（Ｓ１０６）。次に、検索したフレンドをフレンドＩＤ一覧として、モジュール管理部１２７へ返す。そして、モジュール管理部１２７のシナリオ実行部１２８は、アプリケーションの実行結果を示すアクティビティ情報１３９を生成し（Ｓ１０７）、この生成したアクティビティ情報１３９を、Ｓ１０６で検索されたフレンドＩＤ一覧に示されるフレンドへ通知する（Ｓ１０８）。
【００６８】
例えば、シナリオ実行部１２８は、ユーザＡがブログを公開したというアクティビティ情報１３９を、ユーザＡのフレンドである、ユーザＢ，Ｃの端末装置２０のブラウザ等へ通知する。これにより、ユーザＢ，Ｃは、自身のフレンドであるユーザＡがブログを公開したことを知ることができる。
【００６９】
なお、モジュールテーブル１３８に記載されるアプリケーションプログラムの実行に伴い実行すべきプログラムのモジュールは、入出力部１１からの指示入力に基づき変更可能である。例えば、ユーザＡからの指示に基づき、アプリケーションプログラムＸＸの実行に伴い実行すべきプログラムのモジュールをｂ，ｃからｄ，ｅに変更することも可能である。このようにすることで、アプリケーションプログラムの実行に連動して実行すべきプログラムのモジュールを、ユーザの所望するものに変更可能となり、ユーザに様々なサービスを提供できる。
【００７０】
また、図１，８のデータベース更新部１２４は、ＳＮＳデータ処理部１２１により新たな項目値を含む更新要求を受け付けると、（１）項目情報１３４における当該更新要求に含まれる項目の項目値の更新と、（２）各テーブルの項目の項目値の更新とを行うが、（１）（２）の更新のタイミングは同じでなくてもよい。すなわち、データベース更新部１２４は、更新要求により新たな項目値を受け付けるたびに、項目情報１３４上の項目値を更新するが、この項目情報１３４に記憶された項目値を各テーブルに反映処理については、所定期間ごとに実行してもよい。つまり、データベース更新部１２４は、所定期間内は項目情報１３４上で項目値を更新していき、所定期間経過後、その項目情報１３４上の項目値（最新の項目値）をもって各テーブルの更新を行うようにしてもよい。このようにすることで、例えば、各端末装置２０から送信されてくる項目値が、ＧＰＳ（Global Positioning System）により測定されたユーザの位置情報等、頻繁に値が変わる項目値であっとしても、データベース更新部１２４は、この項目値を受信するたびに各テーブルを更新する必要がなくなる。よって、各テーブルの更新処理の負荷を軽減できる。
【００７１】
さらに、図１，８のデータベース更新部１２４は、受け付けた更新要求に含まれる項目ＩＤを用いて、同じユーザの同じ項目に関する更新要求か否かを判断することとしたが、更新要求に含まれるユーザＩＤと項目名を用いて判断するようにしてもよい。つまり、項目情報１３４には、過去に受け付けた更新要求のユーザＩＤおよび項目名と、その項目の項目値とを対応付けた情報を記憶しておき、データベース更新部１２４は、受け付けた更新要求に含まれるユーザＩＤ、項目名および項目値の組み合わせが、項目情報１３４に記憶されていれば、同じユーザから同じ項目について同じ項目値による更新要求を受け付けたと判断して、各テーブルへの更新処理を行わない。一方、受け付けた更新要求に含まれるユーザＩＤ、項目名および項目値の組み合わせが、項目情報１３４に記憶されていなければ、データベース更新部１２４は、（１）異なるユーザからの更新要求、（２）同じユーザでも異なる項目に関する更新要求、または、（３）同じユーザからの同じ項目に関する更新要求だが、異なる更新値による更新要求と判断して、各テーブルへの更新処理を行う。このようにすることで、データベース更新部１２４は、項目ＩＤを用いずに、同じユーザの同じ項目に関する更新要求か否かを判断することができる。
【００７２】
また、データベース更新部１２４は、項目情報１３４の情報を所定期間ごとに消去するようにしてもよい。このようにすることで、記憶部１３の項目情報１３４に確保されたリソースを有効活用できる。
【符号の説明】
【００７３】
１０，１０Ａ    ＳＮＳサーバ
１１    入出力部
１２    処理部
１３    記憶部
２０    端末装置
３０    ネットワーク
１２１  ＳＮＳデータ処理部
１２２  データベース処理部
１２３  データベース参照部
１２４  データベース更新部
１２５  フレンド参照部
１２６  フレンド更新部
１２７  モジュール管理部
１２８  シナリオ実行部
１３１  プロパティ情報
１３２  共通テーブル
１３３  独自テーブル
１３４  項目情報
１３５  フレンド情報
１３６  ユーザＩＤ情報
１３７  モジュール群
１３８  モジュールテーブル
１３９  アクティビティ情報
【図１】
2011076478.tif 000004
【図２】
2011076478.tif 000005
【図３】
2011076478.tif 000006
【図４】
2011076478.tif 000007
【図５】
2011076478.tif 000008
【図６】
2011076478.tif 000009
【図７】
2011076478.tif 000010
【図８】
2011076478.tif 000011
【図９】
2011076478.tif 000012