JP5051242B2 - ゲームイベントに基づく、ブログ、ウェブページ又はファイル共有サイトのための自動エントリ作成のためのシステム及び方法 - Google Patents

Description

本出願は、何れも本発明の譲受人に譲渡され、全体が引用によって本出願に援用される、２００７年１月２９日に出願された米国仮出願第６０／８９８，３５９号、発明の名称「Auto-blogs」及び２００８年１月２５日に出願された米国仮出願第６１／０６２，３０９号、発明の名称「Automatic Gaming Video Highlights Reel」の優先権を主張する。

マルチプレイヤゲーム及び他のマルチユーザシステムを含むビデオゲームのプレイヤは、自らの成績及び手柄を少なくとも友人及び他の興味を有する第三者に公表することを以前より望んできた。例えば、アーケードゲームには、伝統的に、「トップスコア」リストが組み込まれており、これによって、高得点を獲得したユーザは、その得点が上位の得点の１つであれば、自らのイニシャルをリストに入力することができた。

ユーザ情報を提供する新しいシステムには、マルチプレイヤゲーム内のキャラクタに関する統計を提供するシステムが含まれる。このようなシステムの１つは、ウェブサイトwww.EQ2players.comに組み込まれており、これは、大規模多人数参加型オンラインロールプレイングゲーム（massive multiplayer online role-playing game：ＭＭＯＲＰＧ）であるエバークエストＩＩ（Everquest II：登録商標）内のプレイヤキャラクタに関する統計を提供する。これらのシステムは、ある量のプレイヤキャラクタデータ、例えば、レベル及び装備（equipment）情報を自動的に提供する。

エンティティのマルチユーザ環境とのインタラクションを記録に残すウェブページエントリのコンテンツ生成を少なくとも部分的に自動化するシステム及び方法を提供する。これは、自動データ生成と、ユーザが生成し及び／又はユーザが編集又は作成した叙述とを組み合わせたバランスがとれた手法で実行してもよい。

例えば、ブログ記事を投稿する等、記述を自動的に生成及び公表するシステム及び方法を提供する。一具体例では、システムは、ＭＭＯＲＰＧ等のビデオゲーム内で発生したイベントの自動スクリーンショット及び自動的に生成された記述的コピーを含むブログ記事を自動的に投稿する。

具体例において提供される特徴は、以下に限定されるものではないが、オンラインイベント及び活動を追跡し、記述をいつ生成するかを認識すること、テキスト及びオプションの画像、音声及び／又は映像を含むオンラインイベントの記述の自動生成、生成された記述のユーザ編集を受け付けること、ユーザテキスト入力を許可すること、及び１つ以上の場所における生成された記述の自動公表のうちの１つ以上を含むことができる。

一具体例では、イベントの記述は、少なくとも部分的に自動的に生成される。システム及び方法は、オンラインゲームのプレイヤ又はユーザのためのブログを作成でき、エントリは、このプレイヤ又はユーザ及びその友人のゲーム内の成績及びイベントに基づいて、自動的に追加にされる。プレイセッションの間にトリガされた何らかの顕著なイベントは、シーンのスクリーンショットを自動的に保存し、エリア、イベント、ＮＰＣ、ＰＣ等に関するメタデータによって情報を付加してもよい。したがって、例えば、ユーザのプレイセッションの最後に、イベントを用いて、ユーザのブログ内にエントリを作成することができる。このとき、ユーザは、システムが作成したエントリに手を加えなくてもよく、自らの好みに応じてこれを編集してもよい。このようにして、イベントに関する、ゲーム内からのデータ、テキスト、スクリーンショット及び映像の１つ以上が取り込まれた、ユーザのゲーム内の冒険のブログ形式の日誌（blog-format journal）が作成される。

また、プレイヤのブログページには、プレイヤの友人のブログからの最新のエントリを含ませてもよい。更に、ユーザは、完全にオリジナルの記事又は他の素材（すなわち、自動ブログシステムによって作成されていない項目）をブログに追加してもよい。

他の具体例では、システムは、記述を完全に自動的に生成及び公表する。この場合、記述及びこれに伴うあらゆるメディアは、ユーザが編集できない。自動化された記述は、ゲームの世界において、プレイヤにイベントを通知するブログ又は他の公表メカニズムのために使用してもよい。例えば、この手法によって、ゲーム内新聞（in-game newspaper）を生成することができる。これに代えて、自動的に作成されたエントリは、例えば、プレイヤであるエンドユーザではなく、システム管理者又はゲームプロバイダが編集できるようにしてもよい。

更なる具体例では、システムは、単一のユーザのために統合されたページを生成する。統合されたページは、ユーザが遊戯している複数のキャラクタ及び／又はゲームのために生成されたコンテンツを含む。このようなページは、ユーザの全てのキャラクタからのブログ記事を１つの場所にまとめる。

他の具体例では、システムは、ユーザがＸＭＬを用いて、単なるユーザの現実生活のブログ、すなわち、非ゲームブログとしてユーザが有する他のウェブページにこれらのキャラクタブログを埋め込むこをサポートしてもよい。

一側面においては、本発明は、ブログ又はウェブページ内で、マルチユーザ環境内のエンティティに関係するイベントに対応する少なくとも部分的なエントリを自動的に生成するためのシステムにおいて、少なくともユーザインタフェース、データベース及びユーザインタラクションを行うためのソフトウェアエンジンを含み、マルチユーザ環境を実現及び操作する第１のモジュールと、マルチユーザ環境内のエンティティに関係するイベントを監視する第２のモジュールと、所定の基準に基づいて、第２のモジュールによって監視されたイベントの少なくとも１つを選択する第３のモジュールと、選択されたイベントに対応するブログのためのエントリを生成する第４のモジュールとを備えるシステムを提供する。

本発明の具体例は、以下の１つ以上を含んでいてもよい。マルチユーザ環境内のエンティティは、マルチプレイヤゲームのプレイヤキャラクタであってもよい。第４のモジュールは、ウェブサイト上のブログのためのエントリを生成してもよい。所定の基準は、プレイヤキャラクタがマルチプレイヤゲーム内で所定の地理的な境界に達したか、プレイヤキャラクタが所定の非プレイヤキャラクタ又はアイテムとインラクトしたか、プレイヤキャラクタがマルチプレイヤゲーム内で所定のレベルに到達したか、及びプレイヤキャラクタがマルチプレイヤゲーム内で所定の期間内に少なくとも所定数のポイントを蓄積したかのうちの１つ以上を含んでいてもよい。第４のモジュールは、イベントに対応するスクリーンショット、イベントに対応する音声ファイル、イベントに対応する映像、イベントに対応する所定のテキストからなるグループから選択されるメディアアイテムを含むエントリを生成してもよい。第４のモジュールは、ユーザがエントリを編集できるように、編集画面を更に提供してもよい。システムは、第５のモジュールを更に備えていてもよく、第５のモジュールは、ブログ、ウェブページ、ソーシャルネットワーキングサイト及びファイル共有サイトからなるグループから選択されるサイトにエントリを送信する。

他の側面として、本発明は、ウェブページ内で、マルチユーザ環境内のエンティティに関係するイベントに対応する少なくとも部分的なエントリを自動的に生成するための方法において、マルチユーザ環境内のエンティティに関係するイベントを監視するステップと、所定の基準に基づいて、監視されたイベントの少なくとも１つを選択するステップと、選択されたイベントに対応するブログ内のエントリを生成するステップとを有する方法を提供する。マルチユーザ環境は、マルチプレイヤゲームであってもよい。

本発明の具体例は、以下の１つ以上を含んでいてもよい。エントリは、スクリーンショットを含んでいてもよく、生成は、イベントに関連する適切な非プレイヤキャラクタ及びプレイヤキャラクタの少なくともサブセットの単一の画像へのグループ化又は構成を含んでいてもよい。

更なる側面として、本発明は、コンピュータに上述の方法を実行させる命令を格納するコンピュータにより読取可能な媒体を提供する。

更なる側面として、本発明は、環境内の活動のオンライン記述を構築する方法において、環境内でイベントが発生したことを示すデータを受信するステップと、トリガイベント及び応答を示すトリガと、イベントとを照合するステップと、トリガの応答に基づいて、テキスト、画像データ、及び映像データの少なくとも１つを含む記述データを生成するステップと、ネットワークが使用可能なときに、記述データをオンラインリソースに公表するステップとを有する。

本発明の具体例は、以下の１つ以上を含んでいてもよい。方法は、生成の後に、生成された記述データをユーザが編集できるように、編集画面を提供するステップを更に有していてもよい。方法は、公表の通知を１人以上のユーザに送信するステップを更に有していてもよい。

本発明の利点は、以下の１つ以上を含むことができる。ユーザは、自らのキャラクタに関する情報をブログ又は他のウェブページに手作業で入力する必要がない。自動テキスト又は画像及び編集可能なテキスト又は画像の組合せによって、キャラクタに関する非常に興味深い情報を提供できる。ユーザは、ユーザのキャラクタに関する如何なる情報が自動的に投稿されるようにするかを制御できる。この他の利点は、この教示及び開示から、当業者にとって明らかである。

マルチユーザ環境の概要を示す図である。 マルチプレイヤゲームの概要を示す図である。 イベントに対応するエントリを自動的に投稿するための方法のフローチャートである。 図３内のステップの詳細を示すフローチャートである。 図３内の他のステップの詳細を示すフローチャートである。 図３内の更なるステップの詳細を示すフローチャートである。 イベントに対応するエントリを自動的に投稿するためのシステムの概略図である。 キャラクタのための例示的なブログページを示す図である。 キャラクタのための他の例示的なブログページを示す図である。 複数のキャラクタ及び複数の友人又は関連するユーザを示す、ユーザのためのブログページを示す図である。

以下の説明では、次のような定義を採用する。

「マルチユーザ環境」とは、１人以上のユーザが環境とインタラクトし、及び（２人以上のユーザが含まれる場合）互いにインタラクトするあらゆる種類のネットワーク接続されたシステムを意味する。例えば、ＭＭＯＲＰＧの場合、マルチユーザ環境は、マルチプレイヤゲームである。用語「ユーザ」は、個人を表す。幾つかの場合、ユーザは、環境内の「エンティティ」に関連付けられる。マルチプレイヤゲームの場合、ユーザは、通常、「プレイヤキャラクタ（player character：ＰＣ）」又はアバタといったエンティティに関連付けられる。ユーザは、複数のプレイヤキャラクタに関連付けてもよく、複数のマルチプレイヤゲームに関連付けてもよい。多くの場合、マルチプレイヤゲーム内には、「非プレイヤキャラクタ（Non-player characters：ＮＰＣ）」が存在し、これらは、ユーザによる制御ではなく、環境自体によって生成及び操作されるキャラクタである。また、通常、マルチプレイヤゲーム内の環境は、ゲームの重要な特徴であり、環境とのインタラクションは、ゲームプレイの重要な部分を構成する。環境は、一般的には、例えば、都市、建造物、山、水域、川、洞窟等の地理的特徴によって予め定められている。「ゲームエンジン」、「ソフトウェアエンジン」又は単なる「エンジン」は、ユーザのシステムのユーザインタフェースに表示される所定の環境をレンダリングする。ゲームエンジンは、環境内のＰＣの地理的位置に関して保存されたデータを有するので、ＰＣが移動すると、ゲームエンジンは、ユーザインタフェース上で視野を再レンダリングする。用語「サブジェクトＰＣ」又は「サブジェクトユーザ」は、例えば、グループ、ギルド、パーティ等の１人以上の他のＰＣ又はユーザに対して、特定のＰＣ又はユーザについて説明するために用いる。

「ブログ」は、コンテンツの集合であり、幾つかの具体例では、ブログは、ウェブページ又はウェブサイトに開設される。コンテンツの集合は、同じ包括的サブジェクトに対応するエントリを有していてもよい。ここで説明する幾つかの具体例では、ブログは、ユーザによって編集可能であってもよい。他の具体例では、ブログは、編集不能である。ブログは、マルチユーザ環境に関連付けてもよく、特定の具体例では、マルチプレイヤゲームに関連付けてもよい。但し、ブログは、完全に独立しており、マルチプレイヤゲームに関連付けられていなくてもよい。ここに説明するシステム及び方法では、イベントからのエントリは、ブログに投稿するのではなく、ソーシャルネットワーキングサイト又は他のファイル共有サイト、例えば、映像ファイル共有サイトに送信してもよい。

「イベント」は、エンティティの状態を定義する変数の１つ以上に何らかの変化が発生したことを意味する。例えば、マルチプレイヤゲームでは、イベントは、プレイヤキャラクタの状態、位置、統計的データ（demographics）、蓄積されたグッズ及びマネー、スキル、能力、職業等の１つ以上の何らかの変化の発生を意味する。異なる種類のゲームでは、異なる種類のイベントを採用することができる。

「顕著な」又は「トリガ」イベント、若しくは「所定の基準を満たすイベント」等は、注目に値するイベントを包括的に表し、したがって、システム及び方法によって、そのイベントのために作成されたエントリを有する。マルチプレイヤゲームでは、このようなイベントは、例えば、所定のレベルへの到達（又は何らかのレベルの向上であってもよい。）、特定の地理的位置を発見し、若しくは特定のＮＰＣを発見し及び／又は特定のＮＰＣとインタラクトした最初のＰＣとなったこと、所定の時間内に特定の金額又はポイント（例えば、経験値）を蓄積したこと、クエスト（quest:冒険）、ダンジョン（dungeon：迷宮）又はレイド（raid：襲撃）の完了等であってもよい。このようなイベントは、ゲームコミュニティの全体に関して最初、所定のサーバに関して最初、単一のユーザに関連する全てのＰＣの中で最初等と評価してもよい。エンティティ、例えば、ＰＣに「関係する」イベントとは、何らかの形でＰＣに関わるイベントである。例えば、グループがクエストを完了した場合、クエストイベントは、グループの全てのメンバ、すなわち、グループ内の全てのＰＣに関係する。そして、グループの全てのメンバは、クエストの完了をイベントエントリのサブジェクトとしてもよい。グループ自体がエンティティである場合、例えば、ギルドがブログを有している場合、クエストの完了をギルドのブログに掲載してもよい。

「イベントデータ」は、イベントに関する及びイベントを説明するスクリーンショット、音声、映像及び／又はテキスト及び説明、並びにこれらの組合せであってもよい。このようなイベントデータは、これに関連するある程度のユーザ生成を含んでいてもよい。例えば、ユーザは、自らの記述テキストを生成してもよく、自動的に生成されたテキストを編集してもよい。幾つかの具体例では、ユーザは、スクリーンショット又は映像が表示される視野又は角度を選ぶことができる。幾つかの具体例では、ユーザは、画像を「再構成」してもよく、これは、元のスクリーンショット内に存在していなかったか、又は美的に適切に構成されていなかったＰＣ又はＮＰＣ、若しくは環境の特徴を含ませることを意味する。また、再構成は、適切ではないＮＰＣ又は環境の詳細を消し、ユーザにとって関心が高いものに焦点を合わせることを含んでいてもよい。また、イベントデータは、どのＰＣ及びＮＰＣがイベントに関わったか、どのグループ、ギルド及びレイドパーティがイベントに関わったか、イベントの地理的位置及び環境設定、及びイベントに関する他のあらゆるデータ及び／又はメタデータに関するより客観的な情報を含んでいてもよい。

「自動テキスト作成」又は「自動的に生成されたテキスト（又は記述）」は、プリセットのテキスト又は予め定義された部分から構成されたテキストを意味し、エントリ内でそのまま使用され、又はユーザによって編集可能である。例えば、クエストが完了すると、多くの場合、ＰＣがどのようにクエストを完了したかにかかわらず、表示に適するテキストがある。ＰＣが特定の地理的位置、アイテム若しくはＰＣ又はＮＰＣを発見した場合、あるレベルに到達した場合等も同様である。

アクションを「自動的に」行うとは、ユーザの介入なしで、トリガの条件に応じてアクションを発生させることを意味する。例えば、所定の基準を満たすイベントの発生に応じて、ブログのために自動的にエントリを作成してもよい。

「エントリ」は、所定の基準を満たすイベントを記述する「メディアアイテム」であり、メディアアイテムは、テキスト、画像、映像等の１つ以上を含むことができる。エントリは、後述するように、ソフトウェアモジュールによって作成され、自動的に又はユーザによる適切な指示によって、ブログ、ソーシャルネットワーキングサイト又はファイル共有サイトに投稿してもよい。また、エントリは、例えば、ＸＭＬフォーマットに変換する等によって、ユーザがエントリを加工できるようにしてもよい。このようにして、ユーザは、エントリを手作業でブログにコピーしてもよい。このような機能は、自動的又は半自動的に作成されたエントリを、自動投稿機能がないブログにコピーすることをユーザが望む場合に特に好適である。この種のブログの例としては、ライフジャーナルタイプのブログ（life-journal-type blog）又はマルチユーザ環境に関係ないブログ等がある。エントリを「生成する」とは、少なくともイベントデータのサブセットを使用して、投稿又は他の手法によって公表されると、イベントに関する情報を他のユーザに伝えるコードを形成することを意味する。

「ソーシャルネットワーキングサイト」とは、通常、インターネットを介して接続されるユーザのオンラインコミュニティである。ユーザは、通常、メッセージング及び電子メールを介して互いにインタラクトでき、様々な興味及びグループに関して、嗜好を互いに表明することができる。例示的なソーシャルネットワーキングサイトとしては、Ｃｒａｃｋｌｅ（商標）がある。Ｃｒａｃｋｌｅ（商標）を含む多くのソーシャルネットワーキングサイトは、映像又は画像データの共有に特に適している。また、ここでは、これらを映像又は画像「ファイル共有サイト」とも呼ぶ。

「第１のモジュール」は、ここに説明するシステム及び方法のためのサポートを包括的に提供する一組のソフトウェアアプリケーションである。例えば、第１のモジュールは、ＰＣ、ＮＰＣ及び環境に関する情報を保存するためのデータベースを含んでいてもよい。第１のモジュールは、更に、ユーザインタフェースを提供してもよい。更に、第１のモジュールは、ゲームを操作し、ＰＣ同士、並びにＰＣ、ＮＰＣ及び環境の間のインタラクションを実行及び調整するソフトウェア又はゲームエンジンを含んでいてもよい。このモジュール及びこの他について、アプリケーションは、ハードウェア、ファームウェア又はコンピュータ命令の保存及び実行が可能なあらゆる媒体によって実現してもよいことは、当業者にとって明らかである。更に、開発者の指示に応じて、モジュールの何れかを互いに結合してもよい。

「第２のモジュール」は、マルチユーザ環境内のエンティティに関係するイベントを監視する、例えば、マルチプレイヤゲームのイベントを監視する１つ以上のソフトウェアアプリケーションである。「第３のモジュール」は、第２のモジュールによって監視されたイベントを検査し、所定の基準を満たすものを選択する１つ以上のソフトウェアアプリケーションである。多くの具体例では、第２のモジュール及び第３のモジュールを単一のモジュールに結合してもよい。「第４のモジュール」は、第３のモジュール又は結合された第２及び第３のモジュールによって選択される各イベントについてウェブページ又はブログのためのエントリを生成する１つ以上のソフトウェアアプリケーションである。また、第４のモジュールは、コード、例えば、ＸＭＬコードを作成してもよく、ユーザが他の何らかの適切なアプリケーションを用いてこのコードをコピーしてもよい。「第５のモジュール」は、ウェブページ、ブログ又はファイル共有サイトにエントリを送信する１つ以上のソフトウェアアプリケーションである。幾つかの具体例では、第４のモジュールを第５のモジュールに結合してもよい。

「グループ」は、例えば、ギルド、友人のグループ、パーティ、レイドパーティ等、ＰＣの集まりの任意のグループ化又はリストである。グループは、グループ自身のブログ又はこれに関連付けられたウェブページを有していてもよい。イベントについてエントリのサブジェクトが作成されると、グループの全てのメンバにメッセージを送信して、エントリを通知してもよい。

図１は、マルチユーザ環境３０を有するマルチユーザ構成２０を示している。ここでは、複数のユーザ（ユーザ１、２、ｉ、ｋ、（Ｎ−１）及びＮとして示す。）を、それぞれ対応する参照ブロック１１〜１６によって示している。任意の具体例では、ユーザの数は、これより多くても少なくてもよい。小さなオフィスの具体例では、数Ｎは、例えば、１０より少なくてもよい。ＭＭＯＲＰＧの場合、数Ｎは、例えば、数百万であってもよい。図１の具体例では、各ユーザは、１つ以上のエンティティを制御する。他の具体例では、ユーザは、アプリケーション及びデータに直接的に従って行動し、したがって、エンティティプロキシは、なくてもよい。図１の具体例では、エンティティ１、２、３、ｉ、ｊ、ｋ、Ｍ−２、Ｍ−１及びＭを、それぞれ対応する基準ブロック２１〜２９によって示している。上述と同様、任意の具体例では、エンティティの数は、これより多くても少なくてもよい。ＭＭＯＲＰＧの場合、数Ｍは、例えば、数百万となる場合がある。ユーザは、２つ以上のエンティティを制御してもよい。例えば、ユーザ１５は、エンティティ２７及びエンティティ２８を制御する。逆に、幾つかのエンティティは、ユーザによって制御されなくてもよい。例えば、エンティティ２２、２５は、ユーザによって制御されない。

図２は、マルチプレイヤゲームに特化するように構成されたマルチユーザ環境を示している。具体的には、マルチプレイヤゲーム構成４０は、マルチプレイヤ環境５０及び一組のプレイヤ又はユーザ４１〜４６（それぞれプレイヤ１、プレイヤ２、プレイヤｉ、プレイヤｋ、プレイヤＮ−１及びプレイヤＮとして示されている。）を含む。Ｎ人のプレイヤは、Ｍ個のエンティティのサブセットを形成するＰＣを制御する。ここでは、例示的な手法として、Ｍ個のエンティティを、ＰＣ１、ＮＰＣ２、ＰＣ３、ＰＣｉ、ＮＰＣｊ、ＰＣｋ、ＰＣＭ−２、ＰＣＭ−１及びＰＣＭと呼び、それぞれを参照ブロック５１〜５９によって示している。プレイヤは、２つ以上のＰＣを制御してもよい。例えば、プレイヤ４５は、ＰＣＭ−２及びＰＣＭ−１を制御する。ＮＰＣ５２、５５は、後述するゲームエンジンによって制御される。図２の具体例では、残りのプレイヤは、それぞれ１つのＰＣを制御する。もちろん、任意のマルチプレイヤゲームにおいて、これより多い又は少ないプレイヤがいてもよく、これより多い又は少ないＰＣ及びＮＰＣがあってもよい。

このように、Ｎ人のプレイヤと、ＰＣ及びＮＰＣの組合によって形成されるＭ個のエンティティがある。Ｍは、通常、Ｎより大きい。

図３は、ブログ又は他のウェブページのための少なくとも部分的なエントリを自動的に生成する方法６０のフローチャートを示している。まず、如何なるマルチユーザ環境又はマルチプレイヤゲームにおいても、イベントは、実際に絶え間なく発生する（ステップ６２）。このようなイベントは、上述した如何なるイベント又はこれに類するイベントであってもよく、これらの大部分は、通常、ブログエントリ又はウェブページの表記に適するレベルにはない。しかしながら、イベントは、監視される（ステップ６４）。そして、監視されたイベントが所定の基準を満たすか否かが判定される（ステップ６６）。例えば、監視されたイベントは、何らかの形で注目に値するイベントであることがあり、この結果、トリガイベントのレベルにしてもよい。そして、このようなイベントは、ブログ又は他のウェブページにおけるエントリのサブジェクトとされる。

あるイベントが所定の基準を満たさない場合、方法は、単にイベントの監視を継続する。あるイベントが所定の基準を満たす場合、そのイベントは、選択される（ステップ６８）。そして、イベントに関係するエントリが生成される（ステップ７２）。そして、エントリは、ウェブページに送信され（ステップ７４）、ブログ（ステップ７６）に送信され、又はファイル共有サイト（ステップ７８）に送信される。代替となる具体例では、エントリは、他の如何なる場所又は装置に送信してもよい。例えば、エントリをインスタントメッセージ、ＳＭＳ又は電子メールとしてフォーマットし、携帯電話機、ＰＤＡ又は独立したコンピュータシステムに送信してもよい。換言すれば、エントリは、必ずしもブログに送信しなくてもよい。

何れの場合も、図に示すように、この方法は、繰り返してもよい。もちろん、エントリ生成の間、システム及び方法は、この間に発生するかもしれないイベントを監視し続けてもよい。更に、エントリをウェブサイト、ブログ、ファイル共有サイト等に送信することに代えて、ユーザは、如何なる所望の形式で生成されたエントリを操作及び使用してもよい。

図４は、ステップ６６の更なる詳細を示すフローチャート８０である。特に、イベントが所定の基準を満たすか否かを判定するステップは、様々なアクションが発生したか否かを判定することを含んでもよい。エントリにされる１つの種類のイベントは、ＰＣが期間内にある数のポイント、例えば、経験値、金額、コイン等を蓄積したことである（ステップ８２）。閾値レベルは、ユーザによって設定してもよく、システムによって設定してもよく、他の如何なる手段を介して設定してもよい。生成されるエントリにされる他の種類のイベントは、ＰＣが所定のレベルに到達したことである。なお、これに関して説明すると、ＰＣは、通常、経験値が獲得される、クエストが完了する等に応じて、レベルを高める。エントリは、各レベルの完了に応じて作成してもよく、注目に値するレベル、例えば、レベル２０、４０、６０等の達成に応じて作成してもよい。他の具体例では、他の何らかの形でＰＣがその状態を変化させた場合、例えば、スキル又は能力の変化又は向上の際にエントリを作成してもよい。

エントリ生成の原因となり、又はエントリ生成を引き起こすことができる更なる種類のイベントは、ＰＣが所定のＮＰＣとインタラクトすることである（ステップ８６）。具体的には、所定のＮＰＣは、特別である又は注目に値するとみなされ、ＰＣがこのようなＮＰＣとインタラクトすることは、何らかの達成として評価される。ＰＣがＮＰＣを標的とする場合、ＰＣがＮＰＣの所定の半径内（これは、レベル、レベル差、又は他の何らかのパラメータに基づいて変化してもよい。）に入ったときに、このようなインタラクションが発生したとみなしてもよく、他の如何なる尺度を用いてもよい。ＮＰＣではなく、ＰＣが他のＰＣとインタラクトしたことによってエントリ生成をトリガしてもよい。何れの場合も、後述するように、ブログエントリによってこの達成を記録に残してもよい（chronicled）。

結果としてエントリ生成に至り、又はエントリ生成を引き起こすことができる更なる種類のイベントは、ＰＣが、仮想ゲーム環境内のある境界又は地理的位置に到達し、又は何らかの形で地理的に一致することである（ステップ８８）。例えば、ＰＣが特定の都市、ゲート、目印（landmark）、ダンジョン又は他の地理的位置に到達した場合、このイベントをイベント生成のために選択してもよい。

この開示及び教示から、開発者の指示によって、他の多数の種類のイベントからエントリを生成してもよいことは、当業者にとって明らかである。例えば、所定のアイテム又は環境の詳細を発見することがエントリ生成の原因となってもよい。サブジェクトＰＣの生命力が非常に低いレベル（例えば、５％以下）のときに所定のＮＰＣ又はＰＣを打ち負かすことによって、エントリを生成してもよい。特定のＰＣ（ユーザが決定及び設定する、例えば、友人）を打ち負かすことによって、エントリを生成してもよい。幾つかの場合、ユーモラスなイベントがエントリのサブジェクトとなる。例えば、特に悪名高いＮＰＣによる敗北をエントリにしてもよく、この状況又は他の状況では、ユーザの友人への自動通知が特に適切である場合がある。エントリ生成のための他のトリガとして、システムが、チャットチャンネル、例えば、ギルド又はレイドチャンネルを監視して、キーワード、例えば、特定のＮＰＣの名称が使用されたとの判定に応じてエントリを作成してもよい。音声チャットチャンネルでは、システムは、音声認識を使用して、このようなキーワードが発話されたことを判定してもよい。

幾つかの具体例では、ユーザは、どのようなトリガを採用するか、生成されたエントリをどこに送信するかに関する入力を提供してもよい。例えば、ユーザは、ＰＣが１０のレベルを達成した際、例えば、ＰＣがレベル１０、２０、３０等を達成した際にエントリを作成することを指示してもよい。これに代えて、ユーザは、自らのＰＣが新たなレベルを達成する都度、エントリが生成されることを希望してもよい。また、ユーザは、エントリ送信をカスタマイズできる。例えば、ユーザは、特定のクエストの完了に応じて、選択されたユーザグループに通知を行うようにシステムを構成してもよく、また、同じユーザが、新たなレベルの達成について、ユーザに通知を行わないが、ＰＣのブログページ内に小さいエントリを生成して、イベントを記録するようにシステムを構成してもよい。

図５は、ステップ７２の更なる詳細を示すフローチャート９０である。具体的には、イベントに関するエントリを生成するステップは、複数のアクションを含んでいてもよい。１つの種類のエントリ生成は、イベントの映像又は動画を含むエントリを生成することである（ステップ９２）。例えば、エントリは、ダウンロード、ストリーミング又はこの他の視聴のためのビデオクリップを含んでいてもよい。これに代えて、エントリは、映像を視聴又はダウンロードできるサイトへのリンクを含んでいてもよい。何れの場合も、映像は、イベントの実際の発生の前後の期間を含む所定の秒数間又は数分間の映像を含むことができる。映像の長さは、ユーザが設定してもよく、又はシステムが自動的に提供してもよく、ユーザが使用可能なシステムリソースに基づいて決定してもよい。

他の種類のエントリ生成は、イベントのスクリーンショットを含むエントリを生成することである（ステップ９４）。スクリーンショットは、単純に、イベントの発生時の実際のスクリーンショットと同じであってもよく、又は再構成のステップを行ってもよい。再構成は、上述のように、プレイヤから見て実際のスクリーンショットには存在しなかったＰＣ又はＮＰＣの追加、望まれないＰＣ又はＮＰＣの除外、環境の風景の除外又は追加、スクリーンショットの見栄えをよくするためのキャラクタのポーズ変更等を含むことができる。なお、再構成は、イベントの映像及び動画についても実行できる。

更なる種類のエントリ生成は、イベントに関するプリセットテキストを含むエントリを生成することである（ステップ９６）。テキストは、ユーザが適切な編集画面を介して編集できるようにしてもよい（ステップ９８）。これにより、ユーザは、プリセットテキストを編集し、追加を行い、及び完全に書き換えてもよい。ポップアップ画面を用いて、ユーザが幾つかのプリセットテキストオプションを選択できるようにしてもよい。プリセットテキストは、キャラクタ毎に異なっていてもよい。これにより、プリセットテキストは、ＰＣの種族、階級、職業、性別等の差異を反映してもよい。

この開示及び教示から、他の様々な種類のエントリ生成を用いてもよいことは、当業者にとって明らかである。

図６は、ステップ７８の更なる詳細を示すフローチャート１００である。具体的には、ファイル共有サイトにエントリを送信するステップは、複数のアクションを含んでいてもよい。１つの種類の送信は、例えば、Ｃｒａｃｋｌｅ（商標）等のソーシャルネットワーキングサイトにエントリを送信することを含む（ステップ１０２）。このステップは、自動的に実行してもよく、このような送信をユーザに促してもよく、生成されたコードを、ユーザが手動で、ファイル共有サイト上の適切な形式にコピーしてもよい。他の種類の送信は、映像ファイル共有サイト（又は他の同様な音声、画像又はテキストファイル共有サイト）にエントリを送信することを含む（ステップ１０４）。ソーシャルネットワーキングサイトでも、多くの場合、マルチメディアファイルをアップロードできるため、これは、幾つかの点でステップ１０２と同様である。

また、図６は、サブジェクトプレイヤに関連するユーザにエントリの通知を送信してもよいことも示している（ステップ１０６）。具体的には、適用可能なシステム上でサブジェクトプレイヤがユーザグループを構築している場合、エントリ自体ではなく、エントリの通知をユーザグループに送信してもよい。例えば、マルチプレイヤゲームは、ゲーム内のＰＣに関するブログ及びブログエントリを維持する対応するブログシステムを有することができる。ユーザは、イベントを誰に通知したいかに関する情報をブログシステムに提供できる。ユーザは、例えば、友人リスト、ギルドリスト、レイドパーティリスト及び他の同様のグループ化等、幾つかのリストを提供できる。エントリが投稿されると、１つ以上のリスト上の各ユーザ（サブジェクトプレイヤによって制御される設定によって指示されている。）は、電子メール、ＳＭＳ、ゲーム内メール（in-game mail）又はエントリの投稿についての他の同様の通知を受信できる。

同様に、各グループは、グループのためのブログ又は他のサイトを作成していてもよい。例えば、ギルドは、自らのブログを有することができる。トリガイベントがギルドに発生すると、このイベントは、ギルドブログ上にイベントとなりうる。レイドパーティ、友人のグループ及び同様の興味を有する人々のグループ等についても同様のことが言える。

ブログ又は他のファイル共有サイトへのエントリの自動的な伝送又は送信は、様々なスケジュールで行うことができる。例えば、イベントが選択され、及びエントリが生成されると、直ちに送信を行ってもよい。これに代えて、プレイセッションの最後にエントリを送信してもよい。他の具体例では、エントリは、定期的に１日に１回、１週間に１回等の間隔で送信してもよい。

また、システム及び方法は、ユーザが手動で適切な形式又はファイル共有サイト上の他の同様のエディタにコピーするためのコードを生成及び提供する（ステップ１０８）。このような目的のために、コードは、例えば、ＸＭＬフォーマットで提供してもよい。もちろん、他の同様のコードを提供してもよい。ユーザは、提供されたコードを用いて、ウェブページ、ファイル共有サイト又はブログに、若しくは他の何らかの目的のためにエントリを挿入することができる。如何なる画像、映像又は他のマルチメディアファイルを組み込んでもよく、リンクさせてもよく、他の何らかの適切な手法で提供してもよい。

図７は、ブログ又は他のウェブページのために少なくとも部分的なエントリを自動的に生成するシステムを実現することができる構成１１０を示している。この構成は、第１のモジュール１１２、第２のモジュール１１４、第３のモジュール１１６、第４のモジュール１１８及び第５のモジュール１２２を備える。この教示及び開示から、これらのモジュールは、様々に組み合わせてもよいことは、当業者にとって明らかである。第１のモジュール１１２は、ユーザインタフェースモジュール１２４、データベースモジュール１２６及びソフトウェア又はゲームエンジンモジュール１２８を備えていてもよい。包括的に言えば、第１のモジュールは、マルチユーザ環境又はマルチプレイヤゲームの大部分を操作する。

第２のモジュール１１４は、例えば、ゲームエンジン１２８の動作の一部として発生するイベントを監視するよう機能する。第２のモジュール１１４は、多くの手法でこのタスクを実行できる。例えば、第２のモジュールは、所定の基準のリストに対して、発生するイベントを検査してもよい。イベントが（イベントの性質に応じて）所定の基準に一致又は基準を超えていると判定されると、そのイベントを選択できる。イベントは、第３のモジュール１１６によって選択してもよく、第２のモジュール１１４によって選択してもよい。図７では、第２のモジュール１１４及び第３のモジュール１１６を別個のモジュールとして示しているが、上述のように、これらを単一のモジュールに結合してもよい。更に、上述したように、全てのモジュールを１つ以上のソフトウェアアプリケーションに結合してもよい。

第４のモジュール１１８は、選択されたイベントを検査し、これに対応するエントリを作成する。例えば、第４のモジュール１１８は、例えば、イベントの前後それぞれ１０秒間の映像を読み出し、（必要であれば、）保存してもよく、これをブログエントリフォーマットに挿入してもよい。第４のモジュール１１８は、イベントのスクリーンショットを読み出し、ブログエントリに挿入してもよく、スクリーンショットによって描画される画像を再構成するためのオプションをユーザに提供してもよい。例えば、第４のモジュール１１８は、ＰＣのグループメンバ、又はこれに代えてイベントの設定された半径内のＰＣ及びＮＰＣのドロップダウンリストを提供してもよく、指定されたキャラクタの画像をスクリーンショットに追加し、又はスクリーンショットから削除するためのオプションをユーザに与えてもよい。イベントが特定のＮＰＣ又はＰＣを打ち負かしたことに対応している場合、ユーザは、多くの場合、勝利を表明するために、打ち負かしたＰＣ又はＮＰＣの上又は隣にＰＣを立たせることを望む。また、環境の詳細の追加又は除外のために、ポップアップリスト又はドロップダウンリストを提供してもよい。

また、第４のモジュール１１８は、イベントに関するプリセットテキスト、所定のテキスト又は自動テキストを読み出し、ブログエントリに挿入することができる。更に、第４のモジュール１１８は、自動テキスト又はスクリーンショットを編集できるように、編集画面をユーザに提供してもよい。

何れの場合も、第４のモジュール１１８は、イベントに対応する映像、音声、スクリーンショット画像、テキスト及び他のあらゆるマルチメディアファイルを、これらがブログエントリ、ファイル共有サイト等のサブジェクトとなることができるようにフォーマットする。

第５のモジュール１２２は、ウェブページ、ブログ、ファイル共有サイトにエントリを送信し、又はこれに代えて、例えば、ＸＭＬコード等の既成のコードを提供し、ユーザは、如何なる種類の所望のファイル又はウェブページにもこのコードをカットアンドペーストすることができる。一具体例では、第５のモジュールは、ユーザが、Ｃｒａｃｋｌｅ（商標）等のファイル共有サイトにエントリを投稿するか、後の投稿のためにＸＭＬコードを作成するか、又はＰＣのブログサイト上にエントリを投稿するかを選択するための一連のラジオボタン（又は他のインジケータ）を提供する。他の具体例では、個々のエントリ毎にユーザに選択を行わせるのではなく、設定パネル又はメニューによって、ユーザが、将来のエントリの何れか又は全てを所望のサイトに投稿することを指示できるようにしてもよい。

上述したシステムを用いて集められたデータは、クライアント側に保存してもよく、サーバ側に保存してもよく、クライアント側及びサーバ側のストレージの組合せによって保存してもよい。

この教示及び開示から、当業者は、多くの変形例を想到できる。例えば、幾つかのイベントは、グループ又はギルドイベントとみなすことでき、他のイベントは、単独又は個々のイベントとみなすことができる。前者は、グループ又はギルドブログに投稿してもよく、後者は、個々のＰＣのブログに投稿してもよい。特に視覚的に面白い幾つかのイベントは、映像ファイル共有サイトに投稿してもよい。関心は高いが、視覚的には必ずしも面白くない他のイベント、例えば、キャラクタがレベル６０又は７０に到達したこと等は、ＰＣのブログ上に示してもよいが、必ずしもイベントの映像をアップロードしなくてもよい。どこに何を投稿するかについての決定は、ユーザ設定又はこれに代わるデフォルトの基準に基づいて、完全に又は部分的に自動化してもよく、又は手動で、例えば、エントリ毎に行ってもよい。

上述したように、様々なモジュールは、結合でき、ハードウェア、ソフトウェア等の如何なる組合せによって実現してもよいことは、当業者にとって明らかである。更に、多くのマルチプレイヤゲームにおいては、各構成１１０は、プレイヤの人数及び帯域幅の要求のために、幾つのサーバに何回も複製してもよい。

図８は、サブジェクトＰＣ「キャラクタ１」のためのブログタイプのウェブページ１３０を示している。ここでは、キャラクタ１の画像１３２を表示してもよく、この画像は、ユーザが選択してもよく、又はＭＭＯＲＰＧ内の画像ファイルから提供又は導出されたデフォルト画像であってもよい。一連のブログエントリ１〜４、すなわち、エントリ１３４〜１４２が示されている。エントリ１３４は、プリセットテキスト１４４と共に示されており、エントリ１３４は、編集可能な、又は編集されたテキストを有していない。エントリ１３６は、ユーザが入力し、編集し又は編集可能なテキスト１４６と共に示されている。エントリ１３８は、映像１４８及びテキスト１３９と共に示されており、テキスト１３９は、上述したように、プリセットであってもよく、及び／又は編集可能であってもよい。再生ボタン「>>」をクリックすると、イベントの映像の再生、例えば、ストリーミングが開始される。そして、エントリ１４２上には、スクリーンショット１５２が表示されている。スクリーンショットは、再構成されたスクリーンショットを含む、先に列挙した如何なる種類のものであってもよい。

また、図８には、検索ボタン１５４も示されている。また、他のウェブページツールを提供してもよい（図示せず）。

もちろん、ブログ１３０のエントリは、図８に示すエントリより多くても少なくてもよい。

グループ、ＰＣ、ユーザ等のブログは、ユーザがインターネット又は他のネットワークを用いてアクセスできるようにしてもよいが、ゲーム内でもアクセスできるようにしてもよい。例えば、マルチプレイヤゲームのユーザには、ＰＣ、ギルド又は他のこのようなブログに直接アクセスするためのメニューオプション、ボタン又は他のゲーム内ツール（in-game tool）を与えてもよい。これらのゲーム内ブログは、上述したブログと同じであってもよく、又は上述したブログの短縮され、要約され、抄録され、又は他の何らかの形で簡略化されたバージョンであってもよい。これは、独立したブログ画面でアクセスできるようにしてもよく、又は他の様々な手法を介してアクセスできるようにしてもよい。例えば、所定の手法でＰＣを選択すると、そのＰＣのブログが表示されるようにしてもよい。同様に、選択及びギルド名又はバナーを選択すると、そのギルドのブログが表示されるようにしてもよい。この教示及び開示から、他の変形例も明らかである。

図９は、キャラクタブログの他の具体例、ここでは、キャラクタ「Ｈａｍｍｅｒｆｅｌ」のためのキャラクタブログを示している。このキャラクタブログ１６０には、タイトルライン１６２と、ヘッドラインに対応するテキスト１６４（キャラクタに関する最新の投稿に関係していてもよい。）と、１つ以上のスクリーンショット１６６（ＰＣの最新の手柄に関係していてもよい。）と、キャラクタの手柄によって受け取った仮想のグッズに対応するアイコン１６８（Lewt：ゲーム用語で”戦利品”や”獲得アイテム”を意味する）とが組み込まれている。更に、キャラクタに関する他の多数のアイテムを投稿してもよいことは明らかである。また、ボタン１７２、１７４によって示すように、様々なウェブツールを提供できる。

図１０は、ユーザブログ又はファイル共有ウェブページ１８０の他の具体例を示している。この具体例は、ページ１８０を、ユーザ（「ユーザ１」）によって制御される様々なＰＣにリンクする幾つかのボタンを含む。図１０は、この機能を実行するボタン１８２〜１８６を示している。この具体例では、ボタンの上には、キャラクタの画像が描画されている。これらのキャラクタは、ユーザによって遊戯される１つ以上のマルチプレイヤゲームのためのものであってもよい。ページ１８０は、更に、ページ１８０のユーザに関連する友人又はユーザのページへのリンクを提供するセクション１９０を有する。例えば、ユーザは、セットアップページにおいて、これらの友人をこのセクションにリンクさせてもよく、又はこのようなリンクは、ユーザのギルド、グループ等の一部として自動的にセットアップしてもよい。図１０は、ユーザ２、ユーザ３及びユーザ４のページにリンクするボタン１９８〜２０４を示している。また、図１０は、これらのユーザのための最新の投稿に対応する画像を示している。画像は、スクリーンショット、テキスト、映像等であってもよい。映像の場合、画像上にカーソルを重ねると、映像が再生されるようにしてもよい。このレイアウトは、単なる例示であり、様々な変形例を採用することができる。例えば、ページには、ユーザ１のキャラクタのみをリストとして示してもよく、ユーザ１の友人のみをリストとして示してもよい。キャラクタ及び友人の数は、ゼロから仮想的に如何なる数であってもよい。

１つの具体例は、ブログシステムを提供し、ブログ処理方法を実行して、例えば、テキスト記述を生成し、画像又は映像を選択し、ブログエントリに含ませるコンピュータ命令を保存及び実行するための１つ以上のプログラミング可能なプロセッサ及び対応するコンピュータシステム構成要素を含む。

また、更なる変形例及び具体例も可能である。例えば、上述の説明では、ゲームアプリケーションに焦点を絞ったが、他の文脈において同様の技術を適用して、例えば、電子メールシステム、オンラインミーティングツール、バージョン管理ソフトウェア、プロジェクト立案及び管理ソフトウェア、会計システム及びこの他のオンラインの又はオフラインの活動に関する記述を構築することもできる。他の具体例として、ここで説明したシステム及び方法は、行われた仕事、閲覧されたウェブサイト等を記録に残すブログの作成を介して、従業員又は家族の活動を監視するために使用してもよい。他の具体例として、オンライン教育ソフトウェアの分野において、生徒の勉強の進捗状況を記録に残し、又は他の何らかの目的のためにブログエントリを使用してもよい。

更なる具体例では、ここで説明したシステム及び方法は、非ＭＭＯＲＰＧゲームの文脈で用いてもよい。例えば、ゲームシステムは、継続的にオンラインである必要はなく、ゲームは、マルチプレイヤゲームである必要はない。ユーザのゲームシステムを用いてイベントを追跡し、エントリを生成し、一旦、インターネット（又は他のこのようなネットワーク）への接続が確立されると、上述した何れかの手法でエントリを送信し、及び使用してもよい。

したがって、本発明は、特許請求の範囲のみによって限定される。

Claims (15)

1. ブログ内で、マルチユーザ環境内のエンティティに関係するイベントに対応する少なくとも部分的なエントリを自動的に生成するためのシステムにおいて、
   ａ．少なくともユーザインタフェース、データベース及びユーザインタラクションを行うためのソフトウェアエンジンを含み、マルチユーザ環境を実現及び操作する第１のモジュールと、
   ｂ．マルチプレイヤゲームのプレイヤキャラクタであるエンティティであって、前記マルチユーザ環境内のエンティティに関係するイベントを監視する第２のモジュールと、
   ｃ．所定の基準に基づいて、前記第２のモジュールによって監視されたイベントの少なくとも１つを選択する第３のモジュールと、
   ｄ．前記選択されたイベントに対応するブログのためのエントリを生成する第４のモジュールとを備え、
   前記第４のモジュールは、前記イベントに対応する所定のテキストを有するメディアアイテムを含むエントリを生成し、さらに、編集画面を提供し、これにより、ユーザが当該エントリを編集又は追加を行うことができることを特徴とするシステム。
2. 前記第４のモジュールは、ウェブサイト上のブログのためのエントリを生成する請求項１記載のシステム。
3. 前記所定の基準は、
   ａ．プレイヤキャラクタがマルチプレイヤゲーム内で所定の地理的な境界に達したか、
   ｂ．プレイヤキャラクタが所定の非プレイヤキャラクタ又はアイテムとインラクトしたか、
   ｃ．プレイヤキャラクタがマルチプレイヤゲーム内で所定のレベルに到達したか、及び
   ｄ．プレイヤキャラクタがマルチプレイヤゲーム内で所定の期間内に少なくとも所定数のポイントを蓄積したか、
   のうちの１つ以上を含む請求項１記載のシステム。
4. 前記第４のモジュールは、イベントに対応するスクリーンショット、イベントに対応する音声ファイル、イベントに対応する映像、及びイベントに対応する予め定義されたテキストブロックから構築されたテキストからなるグループから選択されるメディアアイテムを含むエントリを生成する請求項１記載のシステム。
5. ブログ、ウェブページ、ソーシャルネットワーキングサイト及びファイル共有サイトからなるグループから選択されるサイトにエントリを送信する第５のモジュールを更に備える請求項１記載のシステム。
6. ブログ内で、マルチユーザ環境内のエンティティに関係するイベントに対応する少なくとも部分的なエントリを自動的に生成するための方法において、
   ａ．マルチプレイヤゲームのプレイヤキャラクタであるエンティティであって、マルチユーザ環境内のエンティティに関係するイベントを監視するステップと、
   ｂ．所定の基準に基づいて、前記監視されたイベントの少なくとも１つを選択するステップと、
   ｃ．前記選択されたイベントに対応するブログ内のエントリを生成するステップとを有し、
   前記エントリを生成するステップは、前記イベントに対応する所定のテキストを有するメディアアイテムを含むエントリを生成するステップ、さらに、編集画面を提供するステップを有し、これにより、ユーザが当該エントリを編集又は追加を行うことができることを特徴とする方法。
7. 前記ブログは、ウェブサイトである請求項６記載の方法。
8. 前記所定の基準は、
   ａ．プレイヤキャラクタがマルチプレイヤゲーム内で所定の地理的な境界に達したか、
   ｂ．プレイヤキャラクタが所定の非プレイヤキャラクタ又はアイテムとインラクトしたか、
   ｃ．プレイヤキャラクタがマルチプレイヤゲーム内で所定のレベルに到達したか、及び
   ｄ．プレイヤキャラクタがマルチプレイヤゲーム内で所定の期間内に少なくとも所定数のポイントを蓄積したか、
   のうちの１つ以上を含む請求項６記載の方法。
9. 前記エントリは、イベントに対応するスクリーンショット、イベントに対応する音声ファイル、イベントに対応する映像、及びイベントに対応する予め定義されたテキストブロックから構築されたテキストからなるグループから選択されるメディアアイテムを含む請求項６記載の方法。
10. 前記エントリは、スクリーンショットを含み、前記生成は、イベントに関連する適切な非プレイヤキャラクタ及びプレイヤキャラクタの少なくともサブセットの単一の画像へのグループ化又は構成を含む請求項９記載の方法。
11. 前記生成は、前記エントリを、ソーシャルネットワーキングサイト及びファイル共有サイトからなるグループから選択されるサイトに送信することを含む請求項６記載の方法。
12. コンピュータに請求項６記載の方法を実行させる命令を格納するコンピュータにより読取可能な媒体。
13. 環境内の活動のオンライン記述を構築する方法において、
    ａ．環境内でイベントが発生したことを示すデータを受信するステップと、
    ｂ．トリガイベント及び応答を示すトリガと、前記イベントとを照合するステップと、
    ｃ．前記トリガの応答に基づいて、所定の編集可能なテキストを少なくとも含む記述データを生成するステップと、
    ｄ．ネットワークが使用可能なときに、前記記述データをオンラインリソースに公表するステップと、
    ｅ．前記生成の後に、生成された記述データをユーザが編集できるように、編集画面を提供するステップと、
    を有する方法。
14. 前記公表の通知を１人以上のユーザに送信するステップを更に有する請求項１３記載の方法。
15. 前記オンラインリソースは、ブログ又はファイル共有サイトである請求項１３記載の方法。

Images