(57)【特許請求の範囲】
【請求項１】
ユーザデバイス上で、ユーザの少なくとも１つのコンタクトとコンテンツアイテムとを含む共有要求を受信することと、
前記ユーザデバイス上でローカルに、前記コンテンツアイテムを蓄積するために共有仮想空間を生成することと、
前記ユーザデバイスにおいて、前記コンテンツアイテムを含む前記共有仮想空間を表示することであって、前記ユーザはグローバルバージョンの前記共有仮想空間が生成される前に、前記コンテンツアイテムとインタラクトすることができる、表示することと、
コンテンツ・マネージメント・システムに、前記共有仮想空間の前記グローバルバージョンを生成するためのデータを送信することと、
前記コンテンツ・マネージメント・システムから前記グローバルバージョンの前記共有仮想空間のグローバル識別子を受信するよりも前に、ローカル識別子を前記共有仮想空間に割当てることと、
前記コンテンツ・マネージメント・システムから、前記グローバルバージョンの前記共有仮想空間の前記グローバル識別子を受信することと、
前記ユーザデバイスにおいて、前記ローカル識別子を前記グローバル識別子により置き換えることと
を含むことを特徴とする方法。
【請求項２】
前記ユーザデバイスにおいて、前記共有仮想空間内での前記コンテンツアイテムとのユーザインタラクションを検出することと、
前記表示された共有仮想空間内のコンテンツアイテムと共に、ユーザインタラクションと関連づけられたデータを、前記グローバルバージョンの前記共有仮想空間が適用される前記コンテンツ・マネージメント・システムに送信することと
を更に含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記共有仮想空間、及び、前記グローバルバージョンの前記共有仮想空間は、前記ユーザデバイス上でコンテンツアイテムを所定の順序で提示することを可能とするデータ構造を有する
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記少なくとも１つのコンタクトは、前記コンテンツ・マネージメント・システムの登録ユーザ及び非登録ユーザとのうち少なくとも１つを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記共有仮想空間から前記コンテンツアイテムが削除されるのを防止するために、前記コンテンツアイテムが追加された後に前記共有仮想空間をロックすること更に含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記ユーザと前記少なくとも１つのコンタクトとのうちの１つ以上は、前記共有仮想空間に新しいメンバーを追加することが許可されることを特徴とする請求項１に記載の方法。
【請求項７】
前記ユーザ、または、前記少なくとも１つのコンタクトの１つ以上に対して通知を送信することを更に含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記通知は、
前記コンテンツアイテムが前記共有仮想空間に追加されたこと、
前記グローバルバージョンの前記共有仮想空間が生成されたこと、または、
前記グローバルバージョンの前記共有仮想空間の名前が入力されたこと
のうち少なくとも１つに応じて送信されることを特徴とする請求項７に記載の方法。
【請求項９】
前記通知は、
前記ユーザが、追加の共有仮想空間に追加されたこと、
追加のコンテンツアイテムが、前記共有仮想空間、または、前記グローバルバージョンの前記共有仮想空間の１つ以上に追加されたこと、
追加のコンタクトが、前記グローバルバージョンの前記共有仮想空間に追加されたこと、または、
新しいメッセージが、前記共有仮想空間、または、前記グローバルバージョンの前記共有仮想空間の１つ以上に追加されたこと、
のうち少なくとも１つに応じて送信されることを特徴とする請求項７に記載の方法。
【請求項１０】
前記コンテンツ・マネージメント・システムとの接続性に関わらず、前記ユーザデバイス上に前記共有仮想空間を生成することを更に含むことを特徴とする請求項１に記載の方法。
【請求項１１】
前記コンテンツ・マネージメント・システムとの接続性に関わらず、前記ユーザに対して前記共有仮想空間の全ての機能を提供することを更に含むことを特徴とする請求項１に記載の方法。
【請求項１２】
前記共有仮想空間と関連する将来的な通信を、前記グローバル識別子と関連づけることを更に含むことを特徴とする請求項１に記載の方法。
【請求項１３】
前記共有仮想空間を表示することは、前記グローバルバージョンの前記共有仮想空間が生成される前であって、かつ、前記グローバルバージョンの前記共有仮想空間が生成される前に前記共有仮想空間のいかなる機能も制限されることなく、前記共有仮想空間を表示することを含むことを特徴とする請求項１に記載の方法。
【請求項１４】
前記コンテンツアイテムの１以上の特性を識別するために前記コンテンツアイテムを分析することと、
１以上の特性を共有する１以上の追加のコンテンツアイテムを識別するために、前記ユーザデバイス上に格納された追加のコンテンツアイテムを分析することと、
前記１以上の追加のコンテンツアイテムを前記共有仮想空間に追加するための提案を提供することと
を更に含むことを特徴とする請求項１に記載の方法。
【請求項１５】
複数のコンテンツアイテムと、前記ユーザの複数のコンタクトのリストとを含むユーザインタフェースを表示することとを更に含み、
前記共有要求を受信することは、前記ユーザインタフェースを介して、前記複数のコンテンツアイテムからの前記コンテンツアイテムの選択と、前記複数のコンタクトからの少なくとも１つのコンタクトの選択とを受信することを含む、ことを特徴とする請求項１に記載の方法。
【請求項１６】
ユーザデバイスであって、
少なくとも１つのプロセッサと、
命令群を格納する少なくとも１つのコンピュータ可読記憶媒体と
を備え、前記命令群は、前記少なくとも１つのプロセッサにより実行されると、前記ユーザデバイスに、
ユーザの少なくとも１つのコンタクトとコンテンツアイテムとを含む共有要求を受信することと、
前記ユーザデバイス上でローカルに、前記コンテンツアイテムを蓄積するために共有仮想空間を生成することと、
前記ユーザデバイスの前記ユーザにより前記共有仮想空間に対し投稿が追加されたことを検出することと、
グローバルバージョンの前記共有仮想空間が生成される前に、前記コンテンツアイテム及び前記投稿を前記ユーザデバイス上で前記ユーザに対して表示することと、
前記コンテンツアイテムのコピーと前記投稿のコピーとを含む前記グローバルバージョンの前記共有仮想空間をコンテンツ・マネージメント・システムで生成するために、前記コンテンツ・マネージメント・システムにデータを送信することと、
前記コンテンツ・マネージメント・システムから前記グローバルバージョンの前記共有仮想空間のグローバル識別子を受信するよりも前に、ローカル識別子を前記共有仮想空間に割当てることと、
前記コンテンツ・マネージメント・システムから、前記グローバルバージョンの前記共有仮想空間のグローバル識別子を受信することと、
前記ユーザデバイスにおいて、前記ローカル識別子を前記グローバル識別子により置き換えることと
を実行させることを特徴とするユーザデバイス。
【請求項１７】
前記投稿は、前記コンテンツアイテムと関連づけられたメッセージと、追加のコンテンツアイテムと、追加のコンテンツアイテムとメッセージと、前記グローバルバージョンの前記共有仮想空間内に既に蓄積されているコンテンツアイテムと関連づけられたメッセージとの１つ以上を含む、ことを特徴とする請求項１６に記載のユーザデバイス。
【請求項１８】
前記表示することは更に、
前記コンテンツ・マネージメント・システムに前記グローバルバージョンの前記共有仮想空間を生成するために前記データを送信する前に、前記共有仮想空間内の前記コンテンツアイテム及び前記投稿を前記ユーザデバイス上で表示することを含むことを特徴とする請求項１６に記載のユーザデバイス。
【請求項１９】
前記命令群は、前記少なくとも１つのプロセッサにより実行されると、前記ユーザデバイスに更に、
前記共有仮想空間上での前記投稿に対するユーザインタラクションを検出すること
を実行させることを特徴とする請求項１６に記載のユーザデバイス。
【請求項２０】
前記命令群は、前記少なくとも１つのプロセッサにより実行されると、前記ユーザデバイスに更に、
前記共有仮想空間上での前記投稿に対する１以上のユーザインタラクションを検出することと、
前記１以上のユーザインタラクションと関連づけられたデータを前記コンテンツ・マネージメント・システムへ送信することと、
前記１以上のユーザインタラクションと関連づけられた前記データを送信する前に、あたかも前記データが前記コンテンツ・マネージメント・システムへ既に送信されたかのように、前記ユーザデバイス上に前記共有仮想空間を表示することと
を実行させることを特徴とする請求項１９に記載のユーザデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
様々な実施形態は、共有仮想空間を生成するためのシステム及び方法に全般的に関連する。
【０００２】
［関連出願へのクロスリファレンス］
本出願は、２０１４年４月８日出願の米国仮特許出願第14/247,853号「共有仮想空間を生成するためのシステム及び方法」、２０１３年１２月２４日出願の米国仮特許出願第61/920,730号「共有仮想空間（「ストリーム」）を提供するためのシステム及び方法」、及び、２０１４年２月２７日出願の米国仮特許出願第61/945,814号「共有仮想空間を生成するためのシステム及び方法」の優先権を主張するものであり、かつ、各出願の記載は参照により本明細書に組込まれる。
【背景技術】
【０００３】
写真アプリケーション、ビデオアプリケーション及び他のコンテンツ共有アプリケーションがますます一般的になる一方で、それらの種類のアプリケーションによって現在提供されるサービスや機能は固有の制限を有する。これらの制限を認識しつつ、複数のオンラインのコンテンツ・マネージメント・システムは、クラウドストレージのための便利なポータルと、ユーザに彼らのコンテンツとの対話機能とを提供することを目的としている。しかしながら、そのようなシステムでは、システムがサポートするユーザデバイス上で実行されているアプリケーションはもちろんのこと、コンテンツもユーザの「アカウント」内で体系化されがちである。アカウント内には様々なフォルダ、コレクション、及び、他のグルーピングが存在しえるが、そのようなグルーピングはコンテンツタイプによって実行され得るが、必ずしも特定のコンテンツアイテムを通常共有している人々に基づいて行われるわけではない。しかし、彼らの心の中では、人々はフォルダやファイル階層においてデータを体系化しているわけではない点に留意すべきである。例えば、写真、ビデオといった特定のコンテンツアイテムは、単にそれらの本来的な内容のみで関連づけられるのではなく、それらを自然に共有する人々の組によって関連づけられるべきと考えられている。ある実施形態では、コンテンツアイテムは、コンテンツアイテムに含まれる内容に基づいて体系化されてもよい。例えばユーザは、例えば「家族の休暇の写真」、「ボブの結婚式の写真」、「祖母、祖父の結婚４０周年のビデオ」、或いは、例えば、「わがアーキテクチャチームが開発している新しいレストランサイトの写真」といった具合に、画像コンテンツの特定のサブセットを体系化してもよい。当該コンテンツアイテムやそのコレクションでさえもユーザは共有したいと思えば、ユーザは、希望する誰とでもそのようにするであろう。しかしながら、１以上のこれらのコンテンツアイテムやコレクションの受領者が、追加のコンテンツアイテムを共有したり、共有されたコンテンツアイテムやコレクションに対するフィードバックを提供したりするためには、受領者は新しい受領者を個別に選択しなければならない。この問題は、コレクションの共有に包含される人々の数が多数（例えば、１０００ユーザ）になった場合には、特に扱いにくく、解決しづらいものとなる。この問題は、複数ユーザが多くの類似コンテンツアイテムを共有しようとする場合や、異なるエリアに位置する異なるユーザが経験するネットワークレイテンシによって、さらに悪化するかもしれない。
【０００４】
このように、ネットワーク状況やグループサイズにかかわらず、ユーザのグループ間でコンテンツの集団的共有を可能とする手段を開発することは利益がある。この集団的共有は、ユーザグループが、グループの各ユーザと共有コンテンツを通信することを可能にしてもよく、また、共有コンテンツに簡単にアクセスができ、そこに含まれるパーティのいずれとも共有コンテンツを相互交換できるようなフォーラムを提供してもよい。
【発明の概要】
【０００５】
「ルームス」あるいは、単数形で「ルーム」として知られるマルチパーティによる仮想共有空間のために、システム、方法、非一時的なコンピュータで読取り可能な記憶媒体が提供される。ルームの関係者には、ルームの生成者、及び、その彼または彼女が最初にコンテンツを共有した他の人々を含んでもよい。これらの関係者は、時にはルームの「メンバー」と呼ばれてもよい。ある実施形態では、ルームは、コンテンツ・マネージメント・システムのユーザが、コンテンツアイテム又はコンテンツアイテムについてのメッセージを他のユーザと共有するといつでも自動的に生成されてよい。一例として、１以上のユーザコンタクトと、１以上のコンテンツアイテムを共有するための共有リクエストを受信してもよい。共有リクエストを受信したことに応じて、共有仮想空間が自動的に生成されてもよく、共有仮想空間は、共有のために選択された１つ以上のコンテンツアイテムのコピーを含んでもよい。共有仮想空間は、例えば、システムサーバ上で割り当てられたメモリ・ロケーションと関連づけられてもよい。共有仮想空間は、ユーザ及び他のメンバーの両方からアクセスされてもよく、彼らはそれぞれ、更なるコンテンツ（例えばコンテンツアイテム、及びメッセージ）を共有仮想空間に追加してもよい。コンテンツが共有仮想空間に追加されたときはいつでも、全てのメンバー関係者に通知がなされてもよい。ある実施形態では、他の非メンバーに対しても、ルームサービスやアプリケーションを提供するコンテンツ・マネージメント・システムにユーザとして登録されていない人々であっても、通知がなされてもよい。通知は、インバンド（in-band）（すなわち、コンテンツ・マネージメント・システム内、又は、当該システムにより提供されるアプリケーション内）、アウトバンド（out-of-band）（例えば電子メール、ＳＭＳ、ソーシャルメディアの通知又は投稿）、又はこれらの通信経路の任意の組み合わせにより、なされてもよい。
【０００６】
説明の簡単のため、以下の用語集を使用する。ルームは、メンバーを有するものとする。実施形態によっては、メンバーは、ルームの機能を提供するコンテンツ・マネージメント・システムの登録ユーザだけに限定されてもよい。他の典型的な実施形態では、コンテンツ・マネージメント・システムの未登録ユーザも、ルームのメンバーになることを許可されてもよい。その際、アクセス権は制限付きでも、無制限でもよい。ゆえに、所与のコンテンツ・マネージメント・システムのユーザは、どのルームの「メンバー」でもあり、また「非メンバー」でもあり得る。上述のように、実施形態によっては、ユーザでもない者がルームの全体、または、一部のメンバーであってもよい。
【０００７】
ある実施形態では、ルームのメンバーはルーム内の任意のコンテンツをコンテンツ・マネージメント・システム上の個人アカウントにコピーしてもよく、また、電子メール、ＳＭＳ又はソーシャルメディアへの投稿により、ルームから他の者に自由にコンテンツのコピーを送信することもできる。ルームに招待された各パーティは、いつでもルームにアクセスすることができ、ルームは、ルーム内の全てのコンテンツの相互インタラクションを保持、また促進するように設計された永続的データ構造である。ある実施形態では、ルームに追加されたコンテンツアイテムは別々の「ルームデータベース」にコピーされ、「ロック」されてもよい。即ち、元の所有者が自身のアカウント内でオリジナルのコンテンツアイテムを後々修正したとしても、コピーされたデータが更に修正されることはない。そのような場合、ルームに以前にコピーされたコンテンツアイテムには修正は適用されないであろう。コンテンツは、ルーム内に所定期間、例えば永久的に、あるいは、それよりは短い期間保存されてもよい。ユーザのモバイルデバイス上で、ユーザにより行われた共有仮想空間に対するローカル変更（例えば、コンテンツの追加、投稿、新しい人の追加等）は、サーバへの情報送信を待機する必要がないように、当該変更が行われると直ぐに、ローカルで表示されてもよい。このように、コンテンツ・マネージメント・システムのサーバにその情報が到達する前に、ルームのメンバーがローカルで生成され、様々なコンテンツアイテムがルームに追加され、様々な人がルームのメンバーに追加されてもよい。これにより、ユーザからはインタラクションが発生すると直ちにルームが構成され、「共有され」ているように見える。
【０００８】
ユーザが共有空間に追加したいかなるコンテンツアイテムも、モバイルデバイス上にローカルで表示されてもよい。また、（ｉ）共有仮想空間がコンテンツ・マネージメント・システム上に既に生成され、かつ、（ii）少なくとも１つのコンテンツアイテムが既にそこにコピーされていたかのように、全てのインタラクティブ性が促進されてもよい。所与のユーザによって生成されたか、あるいは、ユーザにより共有仮想空間に加入するように招待されたコンタクトであるかによらず、既存の共有仮想空間にコンテンツを追加するために、類似の機能を適用してもよい。
【図面の簡単な説明】
【０００９】
上述及び他の側面と発明の利点とは、添付図面と併用される以下の詳細な記載の考慮のもとにより明らかとなる。また、全体を通して、類似の参照番号は類似の部分を指し示している。
【図１】様々な実施形態に対応する、例示的なシステムを示す図である。
【図２】様々な実施形態に対応する、モバイルデバイス上に蓄積されたコンテンツアイテムのセットを表示する例示的ユーザインタフェースを示す図である。
【図３】様々な実施形態に対応する、６つの例示的ルームを表示するユーザインタフェースを例示する図である。
【図４】様々な実施形態に対応する、ユーザが共有のためにセットから６つのコンテンツアイテムを選択した場合の図２のユーザインタフェースを例示する図である。
【図５】様々な実施形態に対応する、共有用に選択された例示的コンテンツアイテムの１つと、ユーザインタフェースの上側に表示される対応する共有バーを表示するユーザインタフェースを例示する図である。
【図６】様々な実施形態に対応する、選択されたコンテンツを共有する相手になり得る、ユーザの様々なコンタクトを表示する「ルーム」のユーザインタフェースを例示する図である。
【図７】様々な実施形態に対応する、コンテンツアイテムを共有する２つのコンタクトをユーザが選択した（よって、チェックマークがこれらのコンタクトの近くに表示されている）後の、図６の「ルーム」ユーザインタフェースを例示する図である。
【図８】様々な実施形態に対応する、図７のユーザインタフェースに続くユーザインタフェースを例示する図であって、「ケイリーとキーガン」として知られる「ルーム」内で、ユーザは「ベニス  ２０１３年８月１３日」のイベントから６つのコンテンツアイテムが共有されたことを通知され、また希望するならば、更にルームへのメッセージの追加を促される。
【図９】様々な実施形態に対応する、図８のユーザインタフェースに続くユーザインタフェースを示す図であって、そこではユーザが「ルーム」へのコメントを（例えば、図８のキーボードを介して）追加しており、それがインタラクティブウィンドウ内に表示される。
【図１０】様々な実施形態に対応する、「ルーム」のユーザインタフェースを例示する図であって、「ルーム」は「ケイリーとキーガン」のものとして知られ、ルームのメンバーは名前とプロフィール写真がリストされて表示される。
【図１１】様々な実施形態に対応する、一般的な「ルーム」のユーザインタフェースを例示する図であって、「新ルーム生成」というアクティブボタンとともに、ユーザが利用可能な様々なルームがリストされている。
【図１２】様々な実施形態に対応する、ルームのリストの例示的なスクリーンショットの変化を例示する図である。
【図１３】様々な実施形態に対応する、ルームのリストの例示的なスクリーンショットの変化を例示する図である。
【図１４】様々な実施形態に対応する、ルームを生成し、提供するための処理のフローチャートの一例を示す。
【図１５】様々な実施形態に対応する、他の例示的なシステムを示す図である。
【発明を実施するための形態】
【００１０】
仮想共有空間の生成をサポートするための、方法、システム及びコンピュータ可読媒体が、例示的特徴の一式と共に提供される。この機能は、既存のコンテンツ・マネージメント・システム又はサービスに組み込まれてもよいし、或いは、別々のアプリケーションとして又は強化されたコンテンツ・マネージメント・システムを提供する個別のアプリケーションにおける多くの特徴のうちの１つとして提供されてもよい。仮想共有空間を提供する例示的なアプリケーションは、例えばスマートフォンのようなユーザデバイス上で動作してもよく、また、コンテンツ・マネージメント・システムのユーザアカウント、即ち、コンテンツ・マネージメント・システムは１以上のリモートサーバにアクセスしてもよい。そのような場合、アプリケーションは究極的には当該１以上のサーバによりサポートされる一方、拡張機能は、例えばユーザデバイス上で動作しているローカルクライアントに搭載されてもよい。そのため、ユーザデバイスとサーバとの接続が、貧弱であるか、間欠的であるか、或いは、全くなされていないかに関わらず、ユーザには、仮想共有空間機能があたかもユーザデバイス上でローカルに動作しているかのように見える。ユーザが、彼らのデバイスが接続性が制限されている場合でさえ十分にインタラクティブであると感じることを可能にすることで、ユーザに提供されるユーザ体験及び機能の充実さが十分に増強され得る。
【００１１】
なお、「デバイス」及び「コンテンツ・マネージメント・システム」との語は、本明細書中で、多種多様のストレージプロバイダ及びデータマネージメントサービスプロバイダと、電子デバイスとユーザデバイスとを広く指すものとして用いられる。また、「コンテンツアイテム」との語は、本明細書中で、多種多様のデジタルデータ、ドキュメント、テキストコンテンツアイテム、音声コンテンツアイテム、ビデオコンテンツアイテム、コンテンツアイテムの一部、及び／又は他の種類のデータを広く指すものである。コンテンツアイテムはまた、ファイル、フォルダ、又は、コンテンツアイテムのコレクション、プレイリスト、アルバム等のような、異なる性質を有するコンテンツアイテムをグループ化する他のメカニズムを含んでもよい。ここで、「ユーザ」の語もまた、本明細書中で広く用いられ、単一ユーザ、複数ユーザ、認証済アカウント、人の代わりに又は人からの命令により自動的に動作するアプリケーション又はプログラム、任意の他のユーザタイプ、又はこれらの任意の組み合わせに相当し得る。ここで、「ジェスチャ」及び「複数のジェスチャ」との語はまた、本明細書中で広く用いられ、１以上の運動、動き、ホバリング、推定、サイン、又は１つ以上のセンサとの任意の他の物理的なインタラクション、又は、これらの任意の組み合わせに相当し、音声コマンドや網膜追跡に基づく目の動きの解釈を含む。「連続的なリアルタイム画像」はまた、本明細書中で広く用いられ、１以上の撮影コンポーネントにより撮影されたライブ画像、撮影された連続画像、記録画像、又は撮影コンポーネントにより撮影され得る任意の他の種類の画像、又はこれらの任意の組み合わせに相当してもよい。
【００１２】
本発明は、様々なコンポーネント及びコンポーネントの配置、様々な技術、方法、又はステップの手順と配置を具体化し得る。参照される図面は、実施形態を説明する目的ためだけのものであり、本発明を限定するものとして解釈されるべきではない。それぞれが互いに独立して又は他の特徴との組み合わせにおいて用いることができる、様々な発明の特徴が以下に記載される。
【００１３】
図１は、様々な実施形態に従う例示的なシステムを示す。システム１００は、ネットワーク１０６を介してコンテンツ・マネージメント・システム１０４と通信するユーザデバイス１０２ａと１０２ｂとを含むことができる。２つのユーザデバイスのみがシステム１００と示されているが、当業者であれば、任意の数のユーザデバイスがコンテンツ・マネージメント・システム１０４及び／又はネットワーク１０６とインタラクトすること、また、上述の説明は単なる例示に過ぎないことを理解するであろう。
【００１４】
ネットワーク１０６は、任意の数のプロトコルをサポートしてもよく、当該プロトコルには、伝送制御プロトコル、インターネットプロトコル（「ＴＣＰ／ＩＰ」）、ハイパーテキスト・トランスファー・プロトコル（「ＨＴＴＰ」）及び／又はワイヤレス・アプリケーション・プロトコル（「ＷＡＰ」）が含まれるが、これらに限定されるものではない。  例えば、ユーザデバイス１０２ａとユーザデバイス１０２ｂ（纏めると１０２）とは、ＴＣＰ／ＩＰを利用してコンテンツ・マネージメント・システム１０４と通信してもよく、また、より上位のレベルでは、コンテンツ・マネージメント・システム１０４におけるウェブサーバとＨＴＴＰを利用して通信するためにブラウザを使用してもよい。
【００１５】
様々なユーザ・デバイス１０２が、コンテンツマネージメントシステム１０４と通信してもよい。当該ユーザ・デバイスには、デスクトップ・コンピュータ、モバイル・コンピュータ、モバイル通信デバイス（例えば携帯電話機、スマートフォン、タブレット）、テレビ、セットトップボックス、及び／又は、任意の他のネットワーク利用可能デバイスが含まれるが、これらに限定されるものではない。様々なタイプのユーザデバイスは、スマートフォン、携帯電話機、タブレットコンピュータ、パーソナル・デジタル・アシスタント（ＰＤＡｓ）、ラップトップコンピュータ、デジタル音楽プレイヤ、及び／又は、タッチ感知式表示インタフェースを含む任意の他の種類のユーザデバイスを含んでもよいが、これらに限定されるものではない。様々なタッチ感知式表示インタフェースは、液晶ディスプレイ（ＬＣＤ）、モノクロ・ディスプレイ、カラー・グラフィックス・アダプタ（ＣＧＡ）ディスプレイ、エンハンスト・グラフィックス・アダプタ（ＥＧＡ）ディスプレイ、可変グラフィックス・アレイ（ＶＧＡ）ディスプレイ、任意の他のディスプレイ、又は、これらの任意の組み合わせを含んでもよいが、これらに限定されるものではない。ある実施形態では、タッチ感知式ディスプレイ・インタフェースは、ジェスチャを受け付けて検出するために、１以上のプロセッサと結合されたマルチタッチパネルを含んでもよい。マルチタッチパネルは、例えば、１つ以上の行トレース及び／又は駆動用ライントレースを有し、また、１つ以上の列トレース、及び／又は検知ラインを有する、容量性の検知媒体であってもよい。マルチタッチパネルは、この中でタッチ感知式ディスプレイ・インターフェースの１例として記載されるが、当業者であれば、任意のタッチ感応式ディスプレイインターフェースを使用してもよいことを理解するであろう。更に、様々な種類のユーザデバイスは、ある実施形態では、１以上の撮影コンポーネントを含んでいてもよい。例えば、ユーザデバイス１０２は、フロントカメラ及び／又はリアカメラを含んでいてもよい。
【００１６】
コンテンツ・マネージメント・システム１００は、認証済アカウントを有するユーザにコンテンツの蓄積を許可すると共に、検索、修正、ブラウズ、同期及び／又は他のアカウントとのコンテンツ共有といった管理タスクの実行を許可してもよい。ある実施形態では、ユーザデバイス１０２上の対応ユーザインタフェース（例えば、スタンドアロン・アプリケーション、クライアント・アプリケーション等）は、ユーザがコンテンツ・マネージメント・システム１０４のモジュールによって提供される機能を実行できるように、コンテンツ・マネージメント・インターフェース・モジュールを用いて実装されてもよい。システム１００の更なる詳細な説明を、図１５を参照して以下に示す。
【００１７】
＜基本的なルーム機能：共有及び会話のための仮想空間＞
説明の簡単のため、本明細書中に記載する仮想共有空間のことを、「ルーム」という場合がある。図１から図１４は、そのような共有空間を指し示すために当該用語を用いている。本発明の例示的な実施形態では、「ルーム」の核心的アイデアは、ユーザが写真のセット（或いは、他のコンテンツのセット）を誰とでもいつでも共有できることにある。彼らは、「ルーム」と呼ばれる仮想共有空間を、彼ら自身やそれら人々のために自動的に生成する。ルームは稼働中の会話スレッドであって、ユーザとユーザの共有者との間で共有されており、彼らはいつでもそこにアクセスが可能である。所与のルームにおけるコンテンツは全て、ルームのメンバーならば誰でもいつでもアクセスが可能である。また、彼らは、例えばコンテンツ・マネージメント・システム上の彼ら自身のアカウントへそれを１つ１つ、或いは、自動的にダウンロードしてもよい。これについて以下で詳細を述べる。更に、ルームは永続的である。このように、ユーザがルームにより共有するコンテンツは全てルームの一部として残り、ルームのメンバーは全てのルームのコンテンツにアクセスすることができる。ある実施形態では、ルームのメンバーがルームから去った場合や、メンバーが１人以上の他のメンバーやルーム作成者によりルームから除外された場合は、場合によっては元メンバーはルームのコンテンツへのアクセスを継続することはできないであろうが、元メンバーが退去前に残したコンテンツはルームに残ることになろう。この特徴により、他のユーザのグループで共有しているというより、単に「ルーム」で共有していると言うのが最もふさわしい。このようにメンバーは誰でも、例えば、ルーム内のコンテンツにアクセスし、及び／又は、自身のアカウントにダウンロードすることができ、電子メールやテキストメッセージにそれらを取り込むことができ、それらをソーシャル・メディア・ウェブサイトやシステムに投稿することができ、また、これらのオプションの組み合わせることもできる。本発明の例示的な実施形態において、ルームの発想は、他のメンバーと会話を継続するためにユーザが訪れる場所に相当する。
【００１８】
注目すべきは、ルームは私的なインバンド共有に対して焦点をより一層当てている点である。ルームは、例えば、コンテンツ・マネージメント・システム上のユーザアカウント内の写真に対するコメント付与や閲覧者に関する同一のプライバシー問題を有さない。これはルームが招待専用の共有空間だからである。ルームはまた、共有されている写真に対するレスポンスを許可する。これは、写真を送信する大半の人々は、彼らが見られていること、或いは、評価されていることを知りたがっているからである。また、ルームは従来のコンテンツ・マネージメント・システムの機能に関する所定の最適化を可能にする。同一の人々のグループで関連コンテンツを繰り返し共有する代わりに、ユーザはルームへコンテンツを追加するだけでよい。例えば、ルームはイベントに関する全ての写真を収集するために利用されてもよい。
【００１９】
本発明の例示的実施形態では、コンテンツ・マネージメント・システムのユーザは、少なくとも一人の他のユーザとコンテンツを共有することにより新たなルームを生成してもよい（この場合、同一の人々のためのルームが存在していないと推測される）。ルームはこのようにして、ルームに対するアクセスが提供されている人々の集合によって定義されてもよい。よって、例えば、ユーザＡとユーザＢがルームにいる場合であって、ユーザＡがその後に何か他のものをユーザＢに送信した場合、追加のコンテンツは同一ルームに加えられる。同様に、もしルーム内に３人のユーザが一緒にいる場合、彼らのうちの誰かが他の２人に何かを送信すれば常に、全てのコンテンツはそのルームに加えられる。
【００２０】
ある実施形態では、メンバーは誰でもより多くの人々をルームに追加することができる。一旦追加されれば、新メンバーはルームの全履歴に対するアクセスを有することになる。他の実施形態では、この点がより制限的になってもよい。ある実施形態では、メンバーは誰でも自身がいたルームから退去することができ、一度彼らが退去すれば、彼らはルームの一部では無かったかのようになる。よって、戻る場合には、例えば、彼らは当該ルームのメンバーによって再追加してもらわなければならないか、或いは、より制限的なルールが適用される。ある実施形態では、メンバーが２人しかいない場合はメンバーはルームから退去できない。
【００２１】
これに関連して、例えば、個人Ａ、Ｂ、Ｃがルームに属し、個人Ｃがルームからの退去を決断したシナリオが発生する。これにより、個人Ａと個人Ｂとの間の「派生」または「存続」ルームが生成される。もし、個人Ａと個人Ｂとの間のルームが既に存在していた場合は、新たに生成されたルームは既存のルームとマージされず、異なるルームとして機能する。そのような場合、新たなルームは個人Ａと個人Ｂとの間での共有のためのデフォルトルームではなく、むしろ、個人Ａと個人Ｂとの間の元のルームがデフォルトルームとなる。ある実施形態では、個人Ｃが退去したときに個人Ａと個人Ｂのためのルームが存在していない場合であっても、この新たなルームは依然として個人Ａと個人Ｂが共有するためのデフォルトルームにはならないであろう。様々な実施形態では、個人Ｃが自身で再エントリをブロックしない限り、個人Ｃが個人Ａまたは個人Ｂによって再追加されてもよい。
【００２２】
他の例示的実施形態では、上記のように閲覧者サイズによって定義されるルームサイズが２以上である限り、同一のユーザグループが、彼らが欲しいだけの数のルームを有してもよい。また、単一ユーザであっても、例えば行為を定義することにより、１以上のルームを生成してもよい。この場合、ユーザがユーザ自身と共有するものとして扱われる。従って、同一の１以上のメンバーが複数ルームを生成することを許可することは、イベントや時間で仕切られたルームを定義することを許可することになる。例えば、ある個人Ａ、Ｂ及びＣは親友であり、写真を彼らの間で共有するルームを有している。彼らは、レイク・タホに遊びに行くことに決め、また、そのイベントのために「タホ」ルームを作成することを決める。或いは、例えば、ユーザが友達とハイキングに出かけたが、ユーザはそこにいた一部の人々をよく知らなかった場合、ユーザは彼らを、ハイキングに出かけた人々と既に生成していた現ルームではなく、新たなルーム「ハイキングルーム」に招待することができる。新しい人と知り合うと、ユーザは彼らを最初のルームに追加することを決めるので、結果的に同一閲覧者について２つのルームが生成されることになる。しかし、上記のように、１つはより全般的であり、１つはより個別的なルームになる。よって、ルームは、ルーム内の誰かが新しいルームを生成し、オリジナルメンバーをそこに招待するまでは、ルームのメンバーによって定義されてもよい。その場合、ルームはより区別され、メンバー及びコンテンツによって定義されるようになる。
【００２３】
このように、ある実施形態では、メンバーがルームの他のメンバーと共有していた任意のコンテンツを当該ルームに追加するデフォルトのパラメータが設定されてもよい。他の実施形態では、ルームでなく他のメンバーとのそのような共有は、新たなルームを生成することとなり、上記のように各ルームは同一閲覧者を有することになる。しかしながら、ユーザが新たなルームを生成することを選択すれば、同一メンバーとであっても、それが許容される。そのようなイベントでは、ユーザは新たなルームに名前を付けるように促されるか、或いは、同一閲覧者の既存のルームの名前を変更するように促されてもよい。同一閲覧者に対し複数ルームを許容することで、コンテンツ及びそのようなコンテンツの周りの会話の特別なセットが生成されてもよい。これは、例えば、クリスマスのような特定種類の繰り返されるイベントや、例えば卒業、子供の結婚等のために個別のルームを作りたい大家族にとっては便利になりえる。所定量のコンテンツがルームで共有された後は、ルームは非常に大きくなり得るため、幾分扱い難くなる。ユーザデバイス上で、都合よくスクロールするには、大きくなりすぎるかもしれないし、容量が限られているユーザデバイスにダウンロードするのは困難になるかもしれない。よって、ルームコンテンツをセグメンテーションすることは、例えルームの閲覧者が同一であっても、実施形態によっては非常に便利になるかもしれない。
【００２４】
また、その後に２つの個別のルームにおける会話が重複し、マージされ、互いを引用しがちであることが判明した場合、例えば２つのルームを統合してもよい。例示的な実施形態では、これは２つのルームのメンバーが同一の場合にのみ実施してもよい。別の実施形態では、メンバーが重複しているが同一ではない２つのルームをマージしてもよい。
【００２５】
ある実施形態では、ルームは、例えば「投稿（post）」と呼ばれる構造を有していてもよいが、これは数多くのことのうちの１つに過ぎない。投稿は、例えば、１枚の写真、１つのビデオ、写真やビデオのセット、または、幾つかの写真やビデオとコメントを含んでいてもよい。投稿はまた、例えば、先行する投稿、ルームにメンバーを追加した誰か、ルームから去った誰か、或いは、ルームの名前を変更した誰かに対する「いいね（like）」を含んでいてもよい。よって、本発明の典型的な実施形態では、ルーム内で発生するあらゆる種類のアクティビティが投稿を構成することができる。
【００２６】
ある実施形態では、ルームの永続的な性質により、誰もルームから他のどのメンバーも削除することができないかもしれない。よって、ユーザはルームから退去して、ルームへの自分自身のアクセスを断ってもよい一方で、人々は強制的に排除されることはないかもしれない。従って、ユーザが一旦ルームへのアクセスを有するようになると、自ら退去を選択して自身のルームに対するアクセスを削除しない限り、彼らは常に留まってもよい。もしそのような事態が発生しても、以下にその詳細を説明するように、彼らが退去前にルームに追加した全ての投稿はルーム内に残されてもよい。他の例示的実施形態では、より多くのオーナーシップモデルが存在してもよい。そこでは、開始者や開設者、或いは、メンバーの過半数が、望ましくないメンバーをルームから処分する権原を有していてもよい。
【００２７】
ある実施形態では、ルームの一員になってもよいメンバーの数に制限はない。しかしながら、これはスケーリング問題を引き起こす。特に、とてもアクティブなルームは数多くの通知を生成することになる。よって、他の実施形態では、例えばルーム毎に３０、４０又は５０人にメンバー数が決めうちされていてもよい。また、より多いメンバー数では、純然たるサンプルサイズの問題として、招待者のうちの一人が望ましくない者である確率が上がる。よって、ルーム単位のメンバー数が多数或いは無制限となるような実施形態では、オーナーシップモデルを採用してもよい。そこでは、何人かのメンバー（例えば、開設者）は他のメンバーに対して継続的にメンバーシップを管理する権原を有していてもよい。
【００２８】
メンバー数が多いルームや、メンバー数は少ないが投稿の数が多いルームについて、ユーザは、一時期所定のルームを「ミュート」するか、見ないようにしたいかもしれない。ある実施形態では、ユーザは１つ以上のルームをミュートしてもよい。係るミュート期間内は、コンテンツはユーザのデバイスにはロードされないであろう。ユーザのデバイスの容量が有限の場合、ユーザがどのルーム見たいかをいつでも手動で指定できるようにすることは便利である。同様に、ある実施形態では、ユーザは単一ルーム内での会話をミュートしてもよい。それは、例えばユーザの二人の妹がある結婚写真について議論している会話のようなルーム内の所定の会話を表示しない設定を実施することにより、行うことができる。
【００２９】
本発明に対応する典型的な実施形態では、ユーザがどの投稿を見て、どの投稿を見ていないかが分かるようにするために、既読確認（read receipt)が提供されてもよい。これは、ユーザがルームに行き、以前に読むのを止めたところから再開する場合に必要とされる。ある実施形態では、この特徴はユーザレベルの既読アイテムであってもよい。ある実施形態では、受領者が投稿を読んだか或いは、共有されたコンテンツを見たかについて、送信者に通知を行ってもよい。
【００３０】
本発明の例示的な実施形態では、ユーザが一旦コンテンツをルームで共有すると、当該コンテンツは「ロック」されてもよい。言い換えると、ユーザは、ルーム内の当該コンテンツを削除したり、修正したりできない。更に、ユーザがその後に自分のアカウントから当該コンテンツを削除した場合でさえ、当該コンテンツはルーム内に残る。当該特徴をサポートするために、コンテンツアイテムがルームで共有されると、そのコンテンツアイテムの複製が生成される。当該複製は、その後、その元となったユーザアカウントとは別のデータ構造に蓄積される。ユーザは「自分の」コピーを自由に修正したり削除したりすることはできるが、ルーム内のコピーは決して修正できないかもしれない。よって、例えば、ユーザは自分のスマートフォン上で幾つかの写真を撮影し、それをコンテンツ・マネージメント・システム上の自分のアカウントにアップロードしてもよい。彼は、その写真のサブセットをルームで共有することにしてもよい。もし、彼がその後に、コンテンツ・マネージメント・システムの自分のアカウントから全ての写真を削除しても、共有された当該写真のサブセットはルーム内に残り、「独立した存在」となって、オリジナルユーザが元の写真に対して何を行っても、それに束縛を受けることなく、独立している。ルーム内で共有されているコンテンツアイテムに対するコメントとして提供されたテキストメッセージについても、同様に扱うことができる。
【００３１】
本発明の典型的な実施形態では、ユーザに対する通知は、以下のいずれかが発生するとプッシュ（送信）されてもよい。（i）誰かが当該ユーザをルームに追加した、（ii）誰かがルームに１枚以上の写真を追加した、（iii）誰かが当該ユーザがメンバーであるルームに、新しい人を追加した、（iv）誰かがルームに新しいメッセージを追加した、（v）誰かが写真に「いいね」した、（vi）ルーム名が変更された、（vii）当該ユーザの写真が（初めて）ロードされた、（viii）当該ユーザの写真が共有可能になっている、（ix）ルーム内に当該ユーザが未読のメッセージがある、及び／又は、（x）一定期間アプリケーションが開かれていない。この後者の通知では、ユーザに対し、当該ユーザがアプリケーションを最近利用したこと、及び、未読のメッセージやユーザが離れている間に発生したアクティビティがあるかもしれないことを通知してもよい。
【００３２】
さらに、ルーム機能を提供するコンテンツ・マネージメント・システムのユーザが例えルームのメンバーでない場合であっても、当該ユーザに通知が送信されてもよい。例えば、ユーザがルームサービスに登録していない、或いは、ルームサービスを取得していない場合であっても、ユーザは、アプリケーション及び所定のアクティビティやイベントについての通知を依然として受けてもよい。例えば、これはユーザがルームの候補であるが、未だ加入していない場合に発生する。説明に役立つ例としては、学生のクラスメンバーはクラスに関連するルームを生成してもよい。このシナリオにおいて、クラスメンバー以外もクラスに関連するルームへの加入の招待を受けてもよい。そして、参加の可否をユーザが選択することを可能とする通知が送信されてもよい。ある例では、コンテンツ・マネージメント・システムの登録ユーザでない個人に対しても通知が送信されてもよい。ある実施形態では、当該個人にコンテンツ・マネージメント・システム、サービス、及び／又は、ルーム機能をサポートするアプリケーションに加入する機会を提供するために、個人が興味を持っているであろうコンテンツのルームでの共有を利用してもよい。例えば、ある個人が写っている写真や、当該個人と写真の共有者の両方が何らかの関係（女子学生クラブにおけるパーティ、家族の集まり、仕事のイベントなど）を共有していることを示す内容を含みうる写真は、コンテンツ・マネージメント・システムへの参加の提案の一部として当該個人との間で共有されてもよい。実際、写真を共有しているルームのメンバーには、当該個人を参加させる動機付けが与えられるかもしれない。そのような個人に対し通知を送信するために、彼又は彼女は登録ユーザのコンタクトであってもよく、コンタクト情報は、コンテンツ・マネージメント・システムにより利用されるコンタクトインポート技術により取得されてもよい。
【００３３】
本発明の典型的な実施形態では、任意の個人に対する通知は、様々な方法により送信されてもよい。当該方法には、例えば電子メール、ＳＭＳ、或いは、ソーシャルメディアネットワーク内で送信されるメッセージ、または、これらの通信経路の組み合わせを含んでもよい。例えば、ソーシャルメディアネットワークでは、当該通知が当該個人の対応するソーシャルメディアネットワークの電子メールアドレス宛てにメッセージまたは電子メール、或いはその両方として送信されてもよい。ある実施形態では、通知はリンク、ルームへのリンクを取得するボタン、或いは、当該通知と関連するコンテンツ・マネージメント・システム内の他の関連するユーザインタフェースを含んでいてもよい。通知はリンクを含んでいてもよく、当該リンクは受信者が共有されている写真、彼らが共有しているルーム、名付けられたルーム等を見るために使用してもよい。ルームのメンバー、或いは、ルームのメンバーではないかもしれないコンテンツ・マネージメント・システムのユーザへ通知するために、例えば、一般にはコンテンツマネージメントシステムアプリケーション内、或いは、そのルームアプリケーションにおける通知トレイといったインバンド通知を介して、ルームアクティビティがそのようなユーザやメンバーに通知されてもよい。
【００３４】
ある実施形態では、通知機能はＳＭＳ通知と電子メール通知との両方を含んでもよく、これによりコンテンツ・マネージメント・システムや、ルームをサポートするそのアプリケーションやサービスに入会させることができる。ある実施形態では、当該通知はアクセス制御リストを形成してもよい。当該リストは、できるだけシームレスに入会処理を実行させるための様々なステップを含んでもよい。
【００３５】
ある実施形態では、ルームのメンバーはシグナルを発してルームへの投稿に「いいね」してもよい。これは、それ自体が一種の投稿とみなされてもよく、ルームメンバーに通知として送信されてもよい。帯域幅を最適化するために、短時間（例えば１０分未満）に多数のいいねがあった場合、当該いいねを集約してもよい。例えば、「個人ＡとＢがこの写真にいいねしました」、或いは、「個人Ａは写真１、２、４にいいねしました」というように、写真により集約してもよい。ある実施形態では、写真と個人を纏めて集約してもよい。ある実施形態では、メンバーはルーム内のすべてのいいねを見ることを選択してもよいし、それらを無効化することを選択してもよい（さらに、これは当該ユーザのルーム全体に渡って全体的に行われてもよい。）。そのような場合、同一ルーム内でメンバーが異なれば、ルームのビューが異なってもよい。例えば、ルームへのいいねと投稿は、ルーム内でのみ見られるようにしてもよいし、そのメタデータの一部として、写真や他のコンテンツアイテムの寸評(snapshot)と関連づけられてもよい。そこで、ユーザは写真や写真のセットを多くのルームで共有してもよい。各写真はいいね、コメント、反応の異なるセットをルームレベルで有してもよいが、当該ルームの全ては、上述のような「ルーム」データベースに蓄積された同一の寸評を参照するであろう。
【００３６】
＜ルームについてのより高度な特徴＞
ある実施形態では、ルームの全メンバー、又は、ルームの「管理者」が、ルームからコンテンツを削除する決断をした場合、それを実行してもよい。例えば、いとこ、叔母、叔父の組み合わせに基づくルームであって、家族の集いの写真を共有しているとする。当該ルームは、「トンプソン家族の集いルーム」と呼ばれてもよい。ルームのメンバーは全て同一イベントの参加者であるから、全員が当該同一イベントにおいて写真やビデオを撮影しているか、及び／又は、家族のルームにおいて彼らの写真やビデオを全員で共有しているので、ルーム内ではほぼ重複したコンテンツがしばしば共有されてしまうことが大いにあり得る。同一人物やアクティビティのいくつもの写真は、技術的には個別の写真であるので、ルームのデータ構造内にひとりでに蓄積されてしまう。しかしながら、人間の目からすると、多くはほとんど区別できないものである。そのような不測の事態に対応し、本質的に冗長なコンテンツによりルームに過度に負担がかかることを防止するため、例えば２つの方法を採用してもよい。まず、メンバーには投票によりコンテンツアイテムを削除する権原が与えられてもよい。これは、例えば、全員一致でもよいし、単純な多数決であってもよい。次に、既に述べたように、所定のルームについて管理グループを用意してもよい。当該グループはコンテンツを削除する権原を与えられてもよい。最後に、例えば、重複している、或いは、実質的に重複していることを検出するアルゴリズムを冗長コンテンツ（これは、１つ以上の類似指標により定義されてもよい）を削除するために利用してもよい。これは、例えばシステムのデフォルトであってもよいし、また、メンバーごとに調整可能であっても、なくてもよい。
【００３７】
同様に、本発明の例示的実施形態では、類似性検出器を共有推奨器として利用してもよい。そのような例示的実施形態では、所定のユーザがあるコンテンツをルームで共有する場合、コンテンツ・マネージメント・システムは、当該ユーザに対して、ユーザ体験を向上させるべく関連するコンテンツや、非常に類似しているコンテンツを共有するように提案してもよい。
【００３８】
ある実施形態では、ユーザのルーム内に誰がいるか、また、当該個人が誰と写真を共有してきたかを知っている例示的システムは、ユーザが当該個人と関係を構築していると推測してもよい。よって、二人の人間が同一の場所にいて、同時に写真を撮っていることが検出されれば、他方の人にルームへの共有に関する指示を出したり提案を行ってもよい。例えば、彼らが共に同時に同じ場所で写真を撮っていることを捕捉することにより、彼らは同一のイベントに属しているか、属しているであろうことを推測してもよい。よって、例えば、彼らがサンクスギビングに一緒に参加し、サンクスギビングの写真を二人のうちの一人が共有すれば、ある実施形態では、「あなたもそこにいらっしゃたようですね。ルームであなたの写真も共有しませんか？」と効果的に言うために当該データを利用してもよい。そのような実施形態では、例示的システムは、ユーザが関連コンテンツをより簡単に共有することのできる方法を提案する。これは、当該他のユーザが「ああ、自分も実際あそこに行ったよな。カメラロールに戻って、ルームで共有する写真を選択しなきゃ」と自覚しなければならないのに比べ、遙かに優れた体験である。例えば、これは「あなたの２６枚の写真も共有しますか？」との通知またはクエリーを送信することにより最適化されてもよい。
【００３９】
ある実施形態では、システムはユーザがルームを生成するのを実際にアシスト又は指示してもよい。例えば、写真タギングを利用して、所定のユーザの写真に誰が写っているかを識別することにより、例示的システムは、これらの写真をそこで検出された人と共有するように、そして、ルームを生成するようにユーザにアドバイスしてもよい。例えば、もしユーザが写真を別のユーザと共有し、システムが写真に誰が写っているかを検出した場合、例えば「あなたは今、この１枚の写真を共有することを希望されましたね。写真に誰が写っているかは、分かっていますよ。この写真を彼と共有したいですか？」のようにユーザに指示してもよい。この機能は、公知技術を利用した写真検出、顔検出／顔認識に依存している。ある実施形態では、別の関連する特徴を利用して、ユーザの写真に写っている各人の顔の側面像（facial profile）を生成し、共有提案を行うために新しく追加された写真をフィルタリングすべく、当該顔の側面像を適用してもよい。
【００４０】
ある実施形態では、例えば、ルームのサブセットが生成されてもよい。技術的には、これは新たなルームであるが、現在のルームのコンテンツに基づいている。例えば、カップルが結婚式の写真を結婚式の招待客と共有するためのルームを設置するかもしれない。例えば、結婚式の招待客が２００人もいて、新郎が、彼の大学からの招待客を選択して、より個人的なコンテンツを共有したいと思う場合、彼は例えば、最初は結婚式のルームに全員を入れ、その後に、彼の大学の友人でない人たちを削除することにより新たなルームを開始してもよい。或いは、例えば、ユーザは例えばサンクスギビングからの写真のセットを上手く加工し、最良の１枚を彼の両親と共有することを決断するかもしれない。その後、彼は、例えば何人かの他の友達やガールフレンドと同一の写真のセットを共有したいかもしれない。そのような機能をサポートするために、ユーザは、例えば、彼の両親とのルームに投稿した任意の投稿を選んで、別のルームで再度共有することができる。
【００４１】
本発明の例示的実施形態では、ルームのコンテンツを永久的なものとし、全メンバーがいつでも利用可能にすることに加えて、「マイアカウントとの同期（sync to my account）」の特徴が提供されてもよい。例えば、ユーザと彼の妻が共有ルームを一緒に持っている場合、ユーザは彼女の写真をいつも共有したいと思うであろうことは大いにあり得る。それは、彼らは非常に親密であり、一緒に暮らしており、彼らの生活は互いに絡み合っているからである。そこで、ユーザの妻の撮る写真の大半が例えば彼らの子供達の写真になりがちであれば、ユーザは彼女の写真が、（彼がアクセスするかもしれない彼女のルームではなく）コンテンツ・マネージメント・システム上の彼のアカウントに入ることを望むであろう。そこで、そのような実施形態では、ユーザはルームの設定を有効にして、新しいものも古いものも、全ての写真をコンテンツ・マネージメント・システム上の彼の個人アカウントに保存してもよい。これにより、例えば連続性のあるルームが生成され、当該ルームに新しい写真が追加された時はいつでも彼の個人アカウントに自動的にコンテンツが保存される。より詳細には、例えば、単に妻だけでなく、ルームにより多くのメンバーがいる場合、当該設定では、妻によってルームに共有されたコンテンツのみをダウンロードしてもよい。また、当該設定は、単一人により共有された特定のタイプのコンテンツのみを自動的にダウンロードするように構成されてもよい。例えば、上述の顔認識を利用して、ユーザは彼の妻が共有した彼らの子供達を含む全ての写真を彼のアカウントに自動的にダウンロードするように当該設定を行ってもよい。
【００４２】
本発明の様々な例示的実施形態では、ユーザインタフェースは以下の特徴を含んでいてもよい。ルームはナビゲーションバー内にアイコンを有していてもよい。当該アイコンは、アクチベートされるとユーザの全ルームのフルビューを生成する。アイコンには、新しい通知のためのバッジが付されてもよく、当該バッジは新しい通知のあるユニークなルーム数の表示を含む。各ルームは、ルームの最後のアクティビティが発生すると、当該アクティビティと、該アクティビティを投稿した人を示してもよく、また、ルーム全体にいる人々のセットを示してもよい。ルームは未読表示を有していてもよい。ルーム内では、好ましくはページによる区切りがなくてもよい（効果的には、ＵＩ上で無限にスクロールする。）。ある実施形態では、ユーザがルームを持っていない場合、空き状態があってもよい。これは、彼にルームが何であるかを知らせることになるかもしれない。ルーム内には、ルームへの参加順にメンバーの名前が登場する。ある実施形態では、せいぜい２つの名前が示され、更に、「＋＜あと何人＞」とだけ示されてもよい。ルーム内のアクティビティについては、最後のアクティビティ（最新の投稿）が表示されてもよい。
【００４３】
本発明のさまざまな例示的実施形態では、ユーザはルームビュー内から新しいルームを生成しなくてもよい。新しいルームを生成するためには、ユーザはコンテンツから開始しなければならない。ある実施形態では、ルームをタッピングすることによりルームに行く。一般に、ユーザはルームを削除したり、ルームを並べ替えたりはしないかもしれない。しかし、ルーム全体を、又は所定のルーム内で、人やコンテンツをフィルタリングしたり探したりするかもしれない。投稿は、（他人による）最新のアクティビティの順で表示される。これは、ユーザに対し、ユーザが未見のアイテムを知らせることになる。同一の順序づけを、メッセージや通知について行ってもよい。しかしながら、これによりユーザが注意していないかもしれないコンテンツが上位に出てくることになる点に留意すべきである。そこで、ある実施形態では、上述のようにユーザは人々、会話、メッセージのタイプ（例えば、いいね）等を、全体的に或いは特定のルーム内のいずれかで「ミュート」してもよい。
【００４４】
図２は典型的なユーザインタフェースの一例を示す。ある実施形態では、表示されているコンテンツアイテムは、ユーザデバイス（例えば、クライアントデバイス１０２）、及び／又はコンテンツ・マネージメント・システム（例えば、コンテンツ・マネージメント・システム１００）上のユーザアカウント内に保存されてもよい。ある実施形態では、ユーザインタフェース２００は、ユーザのプロフィール写真２１６、アプリケーション名２０５、ここで示すように「カルーセル」を、ユーザに現在のプログラム及び／又はユーザインタフェースのモード、ユーザインタフェースがその一部であるアプリケーションを示すために表示する。ユーザインタフェース２００はコンテンツアイテムのコレクション２２０及び２４０を含んでもよい。各コレクションは、１以上のコンテンツアイテムを含んでもよい。コンテンツアイテムコレクション２２０は、後述のようにメインウィンドウ画像２１８及び残りの画像２３０を含むことができる。コンテンツアイテムのコレクション２２０及び２４０に含まれるコンテンツアイテムは、任意の種類の画像及びビデオに対応してもよい。それらは、高品質（ＨＱ）画像、低品質（ＬＱ）画像、高解像度画像、低解像度画像、サムネイル解像度、サムネイル、高精細（ＨＤ）画像、パノラマ画像、モザイク画像、短編ビデオ、短編ループビデオ、映画、ビデオクリップ、或いは、他の任意の種類の画像やそれらの組み合わせを含むが、それらに限定されない。
【００４５】
本発明の典型的実施形態では、コンテンツアイテムのコレクション２２０及び／又は２４０は、任意の適切なソースから取得されてもよい。ある実施形態では、ユーザはコンテンツアイテムを自身のユーザデバイス上に設置された１以上の画像キャプチャコンポーネントを介して取得してもよい。例えば、１以上の画像及び／又はビデオはカメラ１３８を利用して取得されてもよい。ある実施形態では、１以上のコンテンツアイテムは受信メッセージや受信電子メールから取得されてもよい。例えば、ユーザはコンテンツアイテムを含むＳＭＳメッセージをコンタクトから取得してもよい。ユーザはコンテンツアイテムを自分のデバイスに保存してもよい。コンテンツアイテムはユーザインタフェース２００内に表示されてもよい。さらなる実施形態では、ユーザは１以上のコンテンツアイテムをソーシャルメディアネットワーク、ウェブサイト、写真ルーミングサービス、及び／又はコンテンツ・マネージメント・システムから取得してもよい。
【００４６】
２つのコンテンツアイテムのコレクションにおいて、一方が他方よりもより高い解像度で表示されることに注意すべきである。ここでは、「ベニス、イタリア、今日、写真６枚」の識別子を有するコンテンツアイテムのコレクション２２０が表示されている。図２に示す例では、これは、このユーザのアカウント内で最も最近に取得されたコレクションである。上記のように、コンテンツアイテムのコレクション２２０はメインウィンドウ２１８内の単一のコンテンツアイテムとともに、２３０に示すように残りの５つのコンテンツアイテムを実際に含む。ユーザインタフェース２００のこのセクションの下には、別のコレクションが現れる。それがコンテンツアイテムのコレクション２４０であり、「ローマ、バチカン市国、８月１５日金曜日、写真１２枚」と名付けられている。
【００４７】
ある実施形態では、以下に詳述するように、ユーザはコンテンツアイテムのコレクション２２０及び／又は２４０内の１以上のコンテンツアイテムを共有してもよい。例えば、ユーザは選択されたコンテンツアイテムを１以上のユーザのコンタクト、１以上のソーシャルメディアネットワーク、及び／又はコンテンツ・マネージメント・システムと共有してもよい。そのような共有は上述のように「ルーム」を形成するであろう。
【００４８】
図３は、ユーザがメンバーであるところの現在のルーム３２０のセットを表示するユーザインタフェース３００の構成を示す。各ルームは、例えば、現在のユーザではなくメンバーによって識別されてもよく、ルーム内での最後の投稿が表示されてもよい。このように各ルームは、３つのサブエリアによりユーザインタフェース３００の領域を占有する。当該サブエリアは、左から右へ最後に投稿された写真、ルーム名と最後のメッセージ／最後のアクティビティ、及び、プロフィール写真である。ルームは更新されたコンテンツの逆年代順で表示されてもよい。このように、「ケイリー  キュリー」のルームには２枚の新しい写真が追加されたばかりであり、ルームリストの先頭に表示されており、「グレッグ  ガウス」ルームは少し前に更新され、リストの下に現れている。上記のように、矩形領域の左側には、ルームに投稿された最新のコンテンツアイテムや写真３１０が表示されてもよい。中央には、もしあるのならルームに投稿された最新メッセージが表示されてもよい。もし無い場合は、最新のアクティビティが表示されてもよく、一番右側には、プロフィール写真３１５、３１７のようなプロフィール写真が表示されてもよく、これによってルームが識別されてもよい。このユーザインタフェースは、ユーザがアクセスを有する現在のルームを表示するので、インタフェース識別子３０５は、たとえば「ルーム」を示している。
【００４９】
ルームのプロファイル写真３１５、３１７と関連して、３１５に示されるように他の別の一人がルームのメンバーである場合、所与のルームを識別するために彼らのプロファイル写真が表示されてもよい。しかしながら、「ケイリーとキーガン」のルームのように、ルームが複数メンバーを有する場合は、プロフィール写真３１７のように合成ルームプロフィール写真が表示されてもよい。これは、円形のルームプロフィール写真の半分に表示されたお互いのメンバーのプロフィール画像により「分割表示」効果を有している。  下の３つのルーム「トム  トレイルブレイザー」、「テイラー  ハーツ」、「グレッグ  ガウス」のようにルームに最後に投稿されたコメントが無い場合は、最後のアクティビティのみが表示される。ルームの合成写真は、扱いやすく、また、認識しやすいように、３人または４人のメンバーを含むものに制限されてもよい。
【００５０】
図４は、図２のユーザインタフェースにおけるユーザ選択後のグリッド選択モードの一例を示す。例えば、ユーザは「イタリア、ベニス、今日」のコレクション４１５内に示される６つのコンテンツアイテムを共有のために選択してもよい。よって、「共有」インジケータ４１０は、６つ（６）のコンテンツアイテムが共有のために選択されたことを示してもよい。図４に示す例示的な選択／共有モードでは、各コレクションは、コレクション内にいくつのコンテンツアイテムがあるかを示す合計数ボックス４２０及び／又は４４５を含んでもよい。図示された例示的なグリッド選択モードでは、各写真は、例えば、チェックボックスを有していてもよい。チェックボックスは、右上の角に配置されてもよく、各写真が選択されたことを示してもよい。ユーザが写真を選択すると、写真が選択されたことを示すために、各写真の右上の角のチェックボックスがソリッドカラーで示される。チェックボックスがソリッドカラーで示されない場合、写真はその後選択されなくてもよい。写真が選択されたことの表示はどのような形態であってもよい。また、チェックボックスの利用は単なる例示に過ぎない。上述の選択された６つのコンテンツアイテムは、コレクション４１５からのコンテンツアイテムの全てに対応してもよい。以下、インタフェース領域４３０はコレクション４４０の「ローマ、バチカン市国、金曜日、８月１５日」を含むように示されてもよく、そのインジケータ４４５は当該コレクションが１２枚（１２）の写真を含むことをユーザに通知してもよい。また、それらは選択対象にもなる。
【００５１】
一般に、本発明の例示的実施形態では、ユーザは１以上のコンテンツアイテムを、上述のような任意の適切な手段を利用して様々なコレクションの中から選択してもよい。ユーザが、コレクション表示モードから選択モードへ切替えたのに応じて、ユーザインタフェースの１つ以上の特徴が変化してもよい。例えば、図２の２００に類似したユーザインタフェースがあってもよく、それはユーザの写真のセットのグリッドビューに対応してもよい。ユーザは、幾つかの図を選択するために、例えばジェスチャー或いはインタラクティブボタンを使用し、その後、別のジェスチャーを実行するか、或いは、「共有」ボタンを操作すると、図５に示すようなユーザインタフェースが示される。図５の最上部には共有バーが表示され、共有バー内に表示されたセットの写真５０５のうちの１枚が、写真の縁を囲むフレームによって示されように選択されてもよい。選択写真はメインウィンドウ５１８にも表示され、希望があれば、ルームを生成するか、或いは、ルームに追加するためにユーザの１つ以上のコンタクトと共有することができる。
【００５２】
図６は、様々な実施形態に対応する、選択されたコンテンツを共有する相手になり得る、ユーザの様々なコンタクトを表示する「ルーム」のユーザインタフェースを例示する図である。このユーザインタフェースは当然ながら、ユーザが幾つかのコンテンツアイテムを共有のために選択した後、例えば図４のインタフェースの後、または、例えば図５のインタフェースの後に表示されてもよい。図６のユーザインタフェースは、例えば図４から続くので、コレクション４１５（「イタリア、ベニス、２０１３年８月１３日」）の６枚の写真を、６３０にリストされたコンタクトの１つ以上、或いは、６２０に登録されるべき新たなコンタクトと共有するために、６１０に提示する。この例では、図示するようにコンタクトリストはコンタクト名及び彼らのプロフィール写真含む。
【００５３】
図７は、ユーザが選択コンテンツアイテムを共有しようとする２つのコンタクト「ケイリー  キュリー」と「キーガン  カース」とを選択した後の、図６の「ルーム」ユーザインタフェースの一例を示す。この選択は、７３５、７４０において、これらのコンタクトのそれぞれをチェックすることによって実行されてもよい。これにより、彼らの名前は「To：」欄７２０に表示される。当業者であれば、上記説明はあくまで例示であって、様々なシンボルや、「共有」の選択を示す手段を利用可能であることを理解するであろう。
【００５４】
図７に示した「共有者」の選択に応じて、図８では、図７のユーザインタフェースの後に続く、新たに生成された「ケイリーとキーガン」という名の「ルーム」内のユーザインタフェースの一例を示す。新ルームの名前は、ユーザインタフェースのタイトルまたは表題として表示されてもよい。ユーザは情報バー８１５により、「ベニス  ２０１３年８月１３日」というコレクションから６つのコンテンツアイテムがこのルームで共有されたことを知らされてもよい。ユーザは、もし希望するならば、様々な実施形態に従い、共有写真に合うメッセージを追加するように更に促されてもよい。図８に示すように、ユーザ８１６（共有をまさに行った人物）のプロフィール写真が情報バー８１５内に表示されてもよく、その下に共有されたセットのうちの最初のコンテンツアイテムが８１８に表示されてもよい。ユーザインタフェースの底部には、ユーザによるオプションメッセージの入力を支援するために仮想キーボード８３０が表示されてもよい。最上部には、「キャンセル」、「実行」といった動作ボタンを含むタイトルバーが表示されてもよく、これらは、キャンセルや、メッセージがたった今完了したことを示すために利用されてもよい。その際（いずれの場合も）仮想キーボード８３０は削除されてもよい。
【００５５】
図９は、図８に示すように、ユーザが促されて実際にメッセージを入力した場合を示している。当該メッセージは情報バー９１５内に表示され、「先週私の撮ったベニスの写真を見てね。君たちがいてとっても嬉しかったよ！」と示されている。ユーザのプロフィール写真が９１３に示されるので、「共有者」が誰であるかがシステムにとって明白であり、ルームにとっても同様である。これは、３人で一緒に休暇を取ったり、或いは所定の場所への旅行して、彼らの一人以上が写真及び／ビデオを撮った場合におけるルームの利点の典型例である。旅行から帰ってくると、これらの写真及び／又はビデオを互いに共有したいかもしれない。そんな場合に、「共有スペース」に何度も戻ってそれらを見ることができ、また、それらを他の友人に見せたり、それらについて議論したり、コメントしたりすることができる。図９のユーザインタフェースの底部では、ユーザ用の２つの動作ボタンが利用可能となっている。９６０はメッセージを送信するためのもので、電子メールクライアントの「送信」ボタンと同類である。９５０は「写真追加」ボタンであって、これによりユーザは追加写真をルームに追加することができる。
【００５６】
図１０は、様々な実施形態に対応する、「ルーム」のユーザインタフェースを例示する図であって、「ルーム」は「ケイリーとキーガン」のものとして知られ、ルームのメンバーは名前とプロフィール写真がリストされて１０１５に表示される。
【００５７】
図１１は、一般的な「ルーム」のユーザインタフェースを例示する。ここでは、ユーザはコンテンツアイテムを選択し、それを自分のルームのうちの１つで共有したいと考えているかもしれない。図２から図１０の例を続けると、典型的なユーザは図２のコレクション２２０から第１の写真２１８をルームでの共有のために選択する。よって、当該画像の低解像度バージョンが「メッセージ作成」のプロンプトとともに情報用領域１１１５に表示されてもよい。１１３０には、画像を追加することが可能なルームがリストされる。１１２０には、希望する場合には新しいルームの生成を促すための「新ルーム作成」ボタンが示される。１１３０にリストされている利用可能なルームのうち、複数メンバーを含むルームについては、合成プロフィール写真が表示される。例えば、「アダム、イ、他３人」のルームに示されるようになる。ここで、例えば、プロフィール写真はユーザ「アダム」と「イ」のみを含んでいる。これは、当該ルームが元々「アダム」と「イ」のみによって生成されたものであり、他の３人は後から加わったからである。この例示的な実施形態では、ルームのプロフィール写真が一度生成されると、仮に追加ユーザが後に加わった場合であってもそのままである。他の例示的実施形態では、この点がそのまま適用されなくてもよい。即ち、プロフィール写真は、メンバーがルームに追加されたり、ルームから退去するのに応じて動的に変形してもよい。図１２及び図１３は、詳細及び実際の「見た目（look and feel）」を理解できるように、ユーザインタフェースの例示的スクリーンショットの２つの変形例を、あたかも実際に表示されたかのように示す。
【００５８】
図１２及び図１３は、ある実施形態に対応する、例えばスマートフォンに実際に表示されているかのような「ルーム」ユーザインタフェースの例示的スクリーンショットを示す。この２つの図は、同一スクリーンの変形例であって、インタフェースのトップの情報がどのように示されるかのみが異なっている。リストされたルームの２つは複数メンバーを有している（即ち、「イ、ソレイヨ」及び「テイラー、アナ＋３」）ので、合成プロフィール写真が示されている。このように小さいサイズであっても、各ルームのプロフィール写真には相当に詳細なものとなっていてもよい。これにより、ある実施形態では、ルームとインタラクトする場合にユーザが抱く個人的な感情を刺激することができる。従来的には、コンテンツ・マネージメント・システムのユーザは,システムとインタラクトしているという感覚を持つ。ルームのアプリケーションまたは機能のユーザは、彼らの友人とインタラクトしているという感覚を持つ。
【００５９】
図１４は、本発明の様々な実施形態に対応する、ルームを生成し、提供するための処理のフローチャートの一例を示す。図１４の処理は、例えばユーザデバイス上で実行されてもよいし、グローバルデータ及びデータ識別子を記憶するコンテンツ・マネージメント・システムのサーバと通信してもよい。図１４を参照すると、開始後、１４１０では、一人以上の個人と第１の写真またはビデオを共有するためのユーザ要求を受信する処理を実行ことができる。上記のように、「個人」は実施形態に依存してもよく、コンテンツ・マネージメント・システムの登録ユーザを含んでもよく、或いは、他のパーティを含んでもよい。要求を受信すると、１４２０では、ルームを生成し、ルーム識別子を割り当てる処理を実行することができる。
【００６０】
この分岐では、ルーム識別子及びコンテンツアイテム識別子はローカルなもの、即ち、ユーザデバイス上でのみ把握され、参照されるものであっても、或いは、コンテンツ・マネージメント・システムのサーバ及びユーザデバイスが把握して使用するグローバルなものであってもよい。そして、どの種類の識別子が生成されるかは、ユーザデバイスとサーバとの間で優勢な接続性に依存する。ある実施形態では、ローカル識別子がユーザデバイス上で実行されているクライアントアプリケーションによって常に最初に割り当てられ、グローバル識別子の要求が本質的に同時にサーバ宛てに送信される。そして、ローカル識別子は、グローバル識別子が受信されると直ちに置換される。接続性が完全な場合、ローカル識別子は非常にライフスパンが短く、本質的にユーザデバイス上での全てのインタラクティブ性は、ルーム及びルーム内の任意のコンテンツアイテムについてグローバル識別子を参照することにより実現される。
【００６１】
接続性がより間欠的な場合、グローバル識別子が判明するまではローカル識別子を参照することにより多くの動作がユーザデバイス上で実行され（例えば、共有、いいね、コメント付与等）、その後、プロセス、或いは待ち行列にある命令やタスク内における全インスタンスのローカル識別子がグローバル識別子により置換される。図１４の目的のためには、いずれの種類の識別子が利用されてもよい。究極的には全てのローカル識別子は短命で、グローバル識別子により置換されると推定される。
【００６２】
図１４について更に参照を続けると、１４３０では、１４１０における共有要求の対象であった写真やビデオが、ルームデータベースに蓄積されることにより新たに生成されたルームにコピーされてもよい。これにより、写真やビデオは、共有者による更なる修正から守られ、また、ルーム識別子によりルームデータベース内に関連づけられる。ルームデータベースは、ルームアプリケーションが、各メンバーへ様々なルームを表示する場合に引用する基本的データ構造と考えてもよい。それは、論理的には多数のレコードを有するデータベースとみなされてもよく、各レコードがルームである。しかしながら、実際には、コンテンツアイテムは通常はルームデータベース内に１回だけ蓄積されるであろう。もし、コンテンツアイテムが多くのルームで共有された場合、各ルームのレコードは単一のコンテンツアイテムへの参照を含むことになるであろう。
【００６３】
コンテンツ・マネージメント・システム上のユーザのアカウント内に蓄積されたコンテンツアイテムは、直ちに修正可能であって、ユーザによる削除の対象にさえなることが理解される。そのため、ルームに一旦追加された係るコンテンツアイテムを「据え置く」或いは「ロックする」ために、例えばコンテンツ・マネージメント・システム上の標準的ユーザアカウントにサービスするデータベースとは異なる第２のデータベースが利用されてもよい。任意のコンテンツアイテムは、それがルームデータベースに一旦追加されると、それを共有した、或いは、ルームに追加したユーザの制御下に置かれることはなくなる。
【００６４】
１４４０において、新たに生成されたルームは、生成者及び元の共有者のアカウントと関連づけることにより、メンバーのそれぞれと関連づけられてもよい。一度これが達成されると、ルーム及びそのコンテンツが各メンバーのホームページ（又はルートディレクトリ）上に、例えば図３及び図６に示したルームと類似の形態で表示されてもよい。これは、さまざまな方法で実施されてもよい。例えば、各ルームのデータ構造が、当該ルームと関連づけられている全コンテンツアイテムを参照して、ルームデータベース内で生成されてもよい。また、当該コンテンツアイテムもルームデータベース内に蓄積されている。各メンバーの識別番号や、各メンバーのアカウント上に表示されるべき、上述の様々な可能性のあるフォーマットにおいてルームを表示するアイコンフォーマットが、ルームデータ構造内に追加で蓄積されてもよい。  １４５０では、追加コンテンツのルームへの追加を受けつけると、コンテンツがルームデータベースに蓄積され、例えばルームの全メンバーに通知が送信されてもよい。上記のように、所定の実施形態では、ルームアクティビティの通知は、様々な目的のために、コンテンツ・マネージメント・システムのユーザと非登録ユーザとを含む他の個人にも送信されてもよい。
【００６５】
＜接続性に関係なくユーザデバイス上の全機能を維持する＞
上述のように、本発明の様々な例示的実施形態では、ルームは究極的にはコンテンツ・マネージメント・システムのサーバから管理されてもよい。しかしながら、更に記載するように、そのような例示的実施形態では、コンテンツ・マネージメント・システムのクライアントアプリケーションは、データ通信ネットワークを介してサーバと通信しているユーザデバイス上で実行される。更に、（ｉ）ルームの生成、（ｉｉ）既存のルームへの写真やメッセージの追加、（ｉｉｉ）ルームからコンテンツ・マネージメント・システム内の個人アカウントへのコンテンツのダウンロード、及び、（ｉｖ）ユーザのアプリケーションとのインタラクションに対する他の応答（これは常に可能ではない）、に対するシステムのシームレスな応答を体験できるようにすることは、ユーザデバイスのユーザにとって非常に望ましい。これは、ユーザインタフェースと基本クライアントソフトウェアとの間のユーザデバイス上での接続性が永久的である一方、基本クライアントソフトウェアと遠隔サーバとの間の接続性はしばしば間欠的であるかもしれないとの事実のせいである。
【００６６】
従って、ある実施形態では、ルームは一意のインデックス番号、又は、ルームに割り当てられ又は関連付けられた識別子を参照して管理される。標準的なコンテンツ・マネージメント・システムでは、各ユーザには一意の識別子が割り当てられ、全てのコンテンツ及びそのユーザのインタラクションは一意の識別子を利用して、コンテンツ・マネージメント・システムが適切にコンテンツアイテムを彼らのアカウントに蓄積すると共に、サポートされた様々なインタラクションを実装できるようにする。   
ユーザが共有を開始することによりルームを生成しようと、ルームにコンテンツを追加しようと、サーバにとっては動作は等価に見えるかもしれない。但し、後者の場合ではルームＩＤは既に存在していてもよく、その一方で前者の場合では共有が成されたときにはルームＩＤが未だ存在していない。ユーザが最初にルームを生成すると、ルームＩＤの要求が基本クライアントソフトウェアからデータネットワークを介してコンテンツ・マネージメント・システムのサーバに送信される。クライアントアプリケーションが、ルームＩＤをサーバから受信するまで待機しなければならない場合、クライアントアプリケーションはルームを生成することはできず、従ってルームＩＤを受信するまでルーム内でコンテンツを表示することができない。クライアントアプリケーションとサーバの接続性が間欠的である場合、これにより待ち状態及び待ち時間が生ずる可能性があり得る。完全にローカルの機能のユーザデバイス上での体験を生み出すために、解決されるべき基本的問題は、貧弱な又は間欠的なデータ接続による影響を、いかにしてユーザが実際に見ているものに対し与えないようにするかである。よって、ユーザが一旦ユーザインタフェースを介して要求を投入し、タスクを待ち行列に入れた場合、サーバがまだこれらの行動を認識していない、或いは、要求を実行または処理していない場合であっても、基本ソフトウェア内で可能な範囲でローカルの機能を維持すべくこれらの行動をユーザインタフェースに反映しなければならない。
【００６７】
例えば、オフラインであってもユーザはルームを生成してもよい。ユーザは複数枚の写真を撮り、共有をクリックし、個人を追加してもよく、これにより基本ソフトウェアへルームを生成するためのメッセージを送信してもよい。その場合、クライアントソフトウェアは、新しいルームが生成されたことをユーザインタフェースに通知するよう試みてもよい。また、そうする一方で、クライアントソフトウェアは、サーバに対しても並列に新しいルームが生成されたことを通知するであろう。しかしながら、その時点ではサーバはアクセス可能ではないかもしれない。それでもなお、そのようなシナリオにおいて、ユーザがルームに対してコメントを付与すると、例えサーバに対して要求が未だ送信されていなかったり、また、サーバによって要求が処理されていなかったりする場合であっても、ユーザに対しては当該コメントがルーム内にあることを示さなければならない。
【００６８】
よって、接続性が依然として間欠的であるか、或いは貧弱な場合であっても、本発明の例示的実施形態では、ユーザはそれでもなお、スムーズでほぼシームレスなローカル体験を享受してもよい。そのような例示的実施形態では、ルームの生成は常に成功することが保証できる。そのような実施形態では、クライアントアプリケーションは、ある時点で「ルーム生成及びルームＩＤの割当て」メッセージをサーバに対して送信しようとするが、その間にも新しい投稿をシミュレートするかもしれない。例えば、クライアントソフトウェアはローカルＩＤと新たな投稿テーブル（どの投稿がルーム内にあるか、どのルームがあるか等を管理するテーブル）とを生成する。クライアントソフトウェアは、あたかも新たなルームがグローバルに存在し、かつ、コンテンツがルームに実際に投稿されたかのように、ローカルでこれらの結果を生成する。ひとたびサーバが応答すると、各ユーザデバイス上でのシームレスなインタラクションを維持するために、実際の（グローバル）ルームＩＤがローカルルームＩＤと関連付けられなければならず、また、ローカルでの行為が二度又は全く実行されることがないように、ローカルルームＩＤは実際の（グローバル）ルームＩＤと置換される。よって、ローカルルームＩＤが待ち行列命令に含められている場合、命令が待ち行列にあって、まだ実行されていないうちか、或いは、曖昧性をもたらしかねない実行中ではなく実行後のいずれかに、ＩＤの切替が行われなければならない。例えば、ユーザが、ルームアプリケーションが動作しているスマートフォンで何枚かの写真を撮った場合を考える。彼女は、自分のコンテンツマネージメントアカウントに写真をアップロードし、それらを彼女の妹たちと共有する。しかし、ユーザは写真を彼女と妹たちで所有しているルームには追加しない。本実施形態では、同一閲覧者の間で複数ルームを所有することが認められていると仮定すれば、この新しい共有により新しいルームが生成されてもよい。さらに、この処理を行っている間、ネットワークの問題のために彼女のスマートフォンがコンテンツ・マネージメント・システムのサーバに接続されていない場合を想定する。写真はサーバにアップロードされていないが、彼女のアカウントにはローカルで追加され、そしてルームにもローカルで追加されたことになっているため、これらの写真及び新しいルームは全てローカルＩＤのみを有していることになる。従って、これらのアイテムそれぞれとルームのためのＩＤを要求するタスクと、ルームにアイテムを追加するタスクとは、待ち行列に追加され、ローカルで実行される。これらの命令のいくつかの実行中にサーバへの接続性が復旧した場合、タスクが未処理のままとなったり、一度目はローカルＩＤを参照し、二度目は実際のＩＤを参照することで、タスクが二度実行されたりすることがないように、ローカルＩＤと実際の（グローバル）ＩＤとの置換を管理する必要がある。
【００６９】
この文脈では、二人のオフラインユーザが相関がある、或いは、関連する動作を実行するといった、興味深いケースが発生する。ルームは、「共有者」によって選ばれたルーム内のメンバーによって定義されるので、ユーザＡ及びユーザＢの二人が共に自分たちのスマートフォン上で、共にオフラインの間に互いの写真を共有し合うことがあり得る。各ユーザのスマートフォン上では、あたかもユーザがルーム「ＡとＢ」を生成し、他方のユーザとコンテンツを共有したように見えるであろう。そして、接続性が回復した場合、互いにサーバへのメッセージを急いで送信するが、どちらが先に到達するかの保証はない。よって、そのような例示的実施形態では、最終的にはサーバがグローバル動作を実施する場合に、ローカル動作の衝突を解決するための仕組みが導入される。例えば、競合状態が発生する場合、タイムスタンプを利用して、ユーザによって最初に取られた行動により制御してもよく、その場合は、それらがいつサーバで受信されたかは関係ない。また、サーバで最初に受信した行動により制御してもよい。別の例では、コンテンツ・マネージメント・システムにおけるアカウントの登録年数、会員資格が標準か、高級か、アクティビティのレベル、郵便番号、名字（ラストネーム）のアルファベット順等の二人のユーザの詳細に基づき、より普通に解決してもよい。３人以上のユーザの場合には、問題は更に悪化するかもしれない。例えば、４人のユーザ（Ａ、Ｂ、Ｃ及びＤ）がいて、各自が互いに写真を残り３人と共有する場合、１つのルームが生成されるが、各自は自分がそのルームを生成したと信じている。任意のメンバーがルーム名を変更可能である実施形態、或いは、最初の生成者がルームに名前を付ける実施形態では、サーバは４方向の競合条件を有することになる。
【００７０】
そのような競合状態が発生すると、サーバにおける最終的解決により、上記のように１つ以上の通信チャネルを介してルームの各メンバーに通知が自動的に送信されてもよい。当該通知は、競合状態について、及び、どのようにしてそれを解決したか、また、競争に勝った１人を除いた残りのメンバーが自分のユーザデバイスで元々見ていたものとは名前が異なっていたり、ルームへの投稿順序が異なっていたりするのはなぜか、を説明している。そのような通知は、サーバ上で最終的に実行されたルームへのリンクを含んでいてもよく、これによりユーザはルームの最終的な形式及び状態を見ることができる。
【００７１】
図１５は、様々な実施形態に対応する、例示的なシステムを示す図である。ある実施形態では、図１５のシステム１５００は、図１のシステム１００と実質的に類似していてもよい。但し、前者では、システム１００の要素をより細かいレベル（例えばモジュール、アプリケーション等）で表している。
【００７２】
ある実施形態では、ユーザデバイス１０２は、ユーザデバイス１０２上のコンテンツアイテムシステム１０８ａ及び１０８ｂ（纏めると１０８）内にローカルに蓄積された、及び／又は、コンテンツ・マネージメント・システム１０４上（例えばデータストア１１８内）にリモートで蓄積された、コンテンツアイテム１１０ａ及び１１０ｂ（纏めると１１０）を、生成し、アクセスし、修正し、及び管理するために使用されてもよい。例えば、ユーザデバイス１０２ａは、コンテンツ・マネージメント・システム１０４のデータストア１１８にリモートで蓄積されているコンテンツアイテム１１０ｂにアクセスしてもよく、また、ユーザデバイス１０２ａ上のコンテンツアイテムシステム１０８ａ内でコンテンツアイテム１１０ｂをローカルに蓄積してもよいし、蓄積しなくてもよい。引き続きこの例では、ユーザデバイス１０２ａは、コンテンツアイテム１１０ｂを、ユーザデバイス１０２ａ上のキャッシュ内にローカルに一時的に蓄積し、コンテンツアイテム１１０ｂを修正してもよい。また、コンテンツアイテム１１０ｂに対する修正は、コンテンツ・マネージメント・システム１０４のデータストア１１８に通知され、蓄積されてもよい。オプションとして、コンテンツアイテム１１０ａのローカルコピーはユーザデバイス１０２ａに蓄積されてもよい。ある実施形態では、データストア１１８は、コンテンツアイテムの１つ以上のコレクション１３２を含んでもよい。例えば、コレクション１３２は、類似する特性（例えばメタデータ）を有する、及び／又は類似のコンテンツを含む、１つ以上のコンテンツアイテムを含んでもよい。
【００７３】
ある実施形態では、ユーザデバイス１０２は、デジタル画像及び／又はビデオを撮影し記録するためのカメラ１３８（例えば１３８ａ及び１３８ｂ）を含んでもよい。ユーザデバイス１０２は、カメラ１３８を利用して画像のようなコンテンツアイテムを撮影し、記録し、及び／又は蓄積してもよい。例えば、カメラ１３８は画像を撮影及び記録し、画像をメタデータと共に蓄積してもよい。メタデータは、生成時のタイムスタンプ、地理的位置、方向、回転、タイトル及び／又は任意の他の属性や、撮影画像に関連するデータを含んでもよいが、これらに限定されない。メタデータの値は、メタデータをコンテンツアイテムと関連付け、メタデータの種類を容易に特定するために、属性１１２として、名前と値の組、タグと値の組、及び／又は任意の他の方法、または、これらの任意の組み合わせが蓄積されてもよい。ある実施形態では、属性１１２は、特定の規格により規定されるタグと値の組であってもよい。当該規格には、Ｅｘｉｆ（Ｅｘｃｈａｎｇｅａｂｌｅ  Ｉｍａｇｅ  Ｆｉｌｅ  Ｆｏｒｍａｔ）、Ｊｆｉｆ（ＪＰＥＧ  Ｆｉｌｅ  Ｉｎｔｅｒｃｈａｎｇｅ  Ｆｏｒｍａｔ）及び／又は他の標準が含まれるが、これらに限定されない。
【００７４】
ある実施形態では、ユーザデバイス１０２が時間正規化モジュール１４６を含んでもよく、コンテンツ・マネージメント・システム１０４が時間正規化モジュール１４８を含んでもよい。時間正規化モジュール１４６（例えば１４６ａと１４６ｂ）は、コンテンツアイテムと共に蓄積される日時を正規化するために用いられてもよい。時間正規化モジュール１４６、対応する時間正規化モジュール１４８及び／又はそれらの任意の組合せは、コンテンツアイテムについて蓄積された日時を正規化するために用いられてもよい。正規化された日時は、コンテンツアイテムを、ソート、グループ化、比較の実行、基本的な計算の実行、及び／又はクラスタリングするために用いられてもよい。
【００７５】
ある実施形態では、ユーザデバイス１０２は、体系化モジュール１３６を含んでもよく、コンテンツ・マネージメント・システム１０４は体系化モジュール１４０を含んでもよい。体系化モジュール１３６（例えば１３６ａと１３６ｂ）は、コンテンツアイテムをコンテンツアイテムのクラスタやコレクションに体系化するため、コンテンツアイテムを体系化して、ユーザインタフェース内での表示のためのコンテンツアイテムのサンプリングを提供するため、及び／又は提示目的で体系化されたコンテンツアイテムを取得するために使用されてもよい。体系化モジュール１３６は、任意のクラスタリングアルゴリズムを用いてよい。体系化モジュール１３６は、ユーザデバイス１０２及びコンテンツ・マネージメント・システム１０４上のユーザインタフェース内での提示のためにコンテンツアイテムを体系化すべく、クラスタのために類似コンテンツアイテムを識別するために用いられてもよい。様々な類似性の規則に従う各コンテンツアイテム間の類似性の情報を具体化する１つ以上の数値的表現を生成するために、類似性の規則が定義されてもよい。体系化モジュール１３６は、コンテンツアイテムをクラスタ化するために、コンテンツアイテム間の類似性のリファレンスとして数値的表現を用いてもよい。
【００７６】
ある実施形態では、検索要求に応じて類似コンテンツアイテムの取得を支援するために、コンテンツアイテムがクラスタに体系化されてもよい。例えば、体系化モジュール１３６ａは、２つの画像が類似すると識別して、これらの画像を共に１つのクラスタにグループ化してもよい。体系化モジュール１３６ａは、対応する体系化モジュール（例えば１４０及び／又は１３６ｂ）とは独立に、及び／又は、共同して、クラスタを決定するためにコンテンツアイテムを処理してもよい。他の実施形態では、体系化モジュール１３６ａは、対応する体系化モジュール（例えば１４０及び／又は１３６ｂ）に、識別したクラスタのみを表示のために提供してもよい。この例を続けると、クラスタを決定するためのコンテンツアイテムの処理は、新たなコンテンツアイテム及び／又は新たな類似性規則を受けつけると実行される、反復処理であってもよい。
【００７７】
ある実施形態では、ユーザデバイス１０２ａが分類モジュール１５０ａを含む一方、ユーザデバイス１０２ｂが分類モジュール１５０ｂ（纏めて１５０）を含んでいてもよい。これらは、独立に、コンテンツ・マネージメント・システム１０４の体系化モジュール１５２とともに、及び／又は、コンテンツアイテムを分類するため、コンテンツアイテムを修正するため、及び／又は画像を分類するために、それらの任意の組み合わせにおいて、利用されてもよい。例えば、分類モジュール１５０及び／又は１５２は、画像がドキュメントを含むかを判定し、含む場合に蓄積されるドキュメントの種類を判定するために用いられてもよい。コンテンツアイテムの修正は、コンテンツアイテムの表示を改善（例えば、画像内のドキュメントの表示を修正）すべく、コンテンツアイテムを訂正するため、更なる変換を実行するため、及び／又はコンテンツアイテムをクロップするために実行されてもよい。
【００７８】
ある実施形態では、ユーザデバイス１０２ａは、検索モジュール１４２ａを含んでもよく、その一方でユーザデバイス１０２ｂは検索モジュール１４２ｂを含んでもよい。これらは纏めて検索モジュール１４２として参照されてもよい。コンテンツ・マネージメント・システム１０４には、対応する検索モジュール１４４が提供されてもよい。検索モジュール１４２及び１４４のそれぞれは、ユーザデバイス１０２及び／又はコンテンツ・マネージメント・システム１０４の両方に置かれたコンテンツアイテムの検索をサポート可能であってもよい。１つ以上のコンテンツアイテムを要求する検索要求が、検索モジュール１４２及び／又は１４４によって受け付けられてもよい。ある実施形態では、検索は、マネージメントサービスの提供の際にコンテンツアイテムに割り当てられるメタデータ及び／又は属性を検索することによって処理され得る。例えば、コンテンツアイテムと共に蓄積されたクラスタマーカは、日付によりコンテンツアイテムを発見するために用いられてもよい。この特定のシナリオでは、クラスタマーカは、クラスタマーカと共に蓄積されたコンテンツアイテムの概算時刻または平均時刻を示してもよい。また、このマーカは、検索を高速化すること、及び／又は、検索結果に特定のクラスタマーカを有するクラスタのコンテンツを付与するために利用されてもよい。
【００７９】
コンテンツ・マネージメント・システム１０４によって管理されているコンテンツアイテム１１０は、各ユーザデバイス１０２のコンテンツアイテムシステム１０８にローカルに、及び／又は、コンテンツ・マネージメント・システム１０４のデータストア１１８にリモートに（例えばデータストア１１８内のコンテンツアイテム１３４）に蓄積されていてもよい。コンテンツ・マネージメント・システム１０４は、そこで管理されているコンテンツアイテムの同期をとってもよい。属性１１２ａ及び１１２ｂ（纏めて１１２）、または他のメタデータが、コンテンツアイテム１１０と共に蓄積されていてもよい。例えば、特定の属性は、コンテンツ・マネージメント・システム１０４によって管理及び／又は同期される、ユーザデバイス１０２にローカルに蓄積されたコンテンツアイテムを追跡するために、コンテンツアイテムと共に蓄積され得る。ある実施形態では、属性１１２は、拡張属性、リソースフォーク、又は、コンテンツアイテムシステム１０８等のコンテンツアイテムシステムによって解釈されないコンテンツアイテムと共にメタデータを蓄積可能な任意の他の実装を用いて実装されてもよい。特に、属性１１２ａ及び１１２ｂは、コンテンツアイテムのためのコンテンツ識別子であってもよい。例えば、コンテンツ識別子は、コンテンツアイテムを識別する、ユニーク又はほぼユニークな識別子（例えば番号や文字列）であってもよい。コンテンツアイテムと共にコンテンツ識別子を蓄積することにより、コンテンツアイテムを追跡してもよい。例えば、ユーザがコンテンツアイテムをコンテンツアイテムシステム１０８内の階層的に別の場所に移動し、及び／又は、当該コンテンツを修正しても、コンテンツアイテムはユーザデバイス１０２のコンテンツアイテムシステム１０８内で依然として識別されてもよい。コンテンツ識別子で識別されたコンテンツアイテムに対する任意の変更又は修正は、コンテンツ・マネージメント・システム１０４が提供する同期及び／又はバージョン管理サービスのためにアップロード又は提供されてもよい。
【００８０】
スタンドアローンのコンテンツマネージメントアプリケーション１１４ａと１１４ｂ（纏めて１１４）、クライアントアプリケーション、及び／又はサードパーティアプリケーションが、ユーザデバイス１０２ａ及び１０２ｂ上でそれぞれ実行されてもよく、ユーザがコンテンツ・マネージメント・システム１０４とインタラクトするためのユーザインタフェースが提供される。コンテンツマネージメントアプリケーション１１４は、コンテンツマネージメントインターフェースモジュール１５４に提供される機能と、ユーザデバイス１０２のためにアクセス可能なモジュールを示してもよい。ウェブブラウザ１１６ａと１１６ｂ（纏めて１１６）は、クライアントアプリケーションのためにウェブページフロントエンドを表示するのに利用されてもよい。クライアントアプリケーションは、コンテンツマネージメントインターフェースモジュール１５４により提示、或いは、提供されるコンテンツマネージメント１０４の機能を提供してもよい。
【００８１】
コンテンツ・マネージメント・システム104は、認証されたアカウントを有するユーザがコンテンツを蓄積することを許容し、また、取得、修正、ブラウズ、同期及び／又は他のアカウントとのコンテンツ共有のような管理タスクを実行する。コンテンツ・マネージメント・システム１０４の様々な実施形態は、以下の要素を含むことができるが、これらに限定されるものではない。コンテンツマネージメントインターフェースモジュール１５４、アカウントマネージメントモジュール１２０、同期モジュール１２２、コレクションモジュール１２４、共有モジュール１２６、ファイルシステム抽象化１２８、データストア１１８、及び体系化モジュール１４０。コンテンツマネージメントインターフェースモジュール１５４は、コンテンツ・マネージメント・システム１０４のサーバサイド又はバックエンドの機能／性能を提示してもよい。例えば、ユーザがコンテンツ・マネージメント・システム１０４が提供する機能を実行できるようにするために、ユーザデバイス１０２上の対応ユーザインタフェース（例えばスタンドアローンのアプリケーション、クライアントアプリケーション等）は、コンテンツマネージメントインターフェースモジュール１５４を利用して実装されてもよい。
【００８２】
ユーザデバイス１０２に表示されるユーザインタフェースは、アカウントマネージメントモジュール１２０を利用して、ユーザがアカウントを生成し、及び／又はユーザの当該アカウントの利用を認証するために利用されてもよい。アカウントマネージメントモジュール１２０は、ユーザ及び／又はユーザデバイス１０２によるアカウントの利用を、ユーザ名／パスワード、デバイス識別子、及び／又は任意の他の認証方法を用いて認証する機能を提供してもよい。アカウント情報１３０は、データストア１１８内でアカウントのために保持されてもよい。アカウント情報は、以下を含むことができるが、それに限定されるものではない。個人情報（例えば、電子メールアドレス又はユーザ名）、アカウント管理情報（例えば、「無料」や「有料」等のアカウントの種類）、利用情報（コンテンツアイテムの編集履歴）、最大許容ストレージ空間、使用済みストレージ空間、コンテンツの蓄積場所、セキュリティ設定、個人構成設定、コンテンツ共有データ等。また、コンテンツ・マネージメント・システム１０４上のストレージ空間の量は、予約され、分配され、確保され、蓄積され、及び／又は認証済アカウントによりアクセスされてもよい。アカウントは、データストア１１８内のそのアカウント用のコンテンツアイテム１３４及び／又はコンテンツアイテム１１０にアクセスするために、及び／又は、コンテンツアイテム１３４及び／又はコンテンツアイテム１１０を、他のアカウントと共有されたアカウントからアクセス可能にするために利用されてもよい。ある実施形態では、アカウントマネージメントモジュール１２０は、コンテンツ・マネージメント・システム１０４の任意の数の他のモジュールとインタラクトしてもよい。
【００８３】
ある実施形態では、コンテンツ・マネージメント・システム１０４上のアカウントは、アカウントにより認証された１つ以上のユーザデバイス１０２からのドキュメント、テキストアイテム、音声アイテム、ビデオアイテム等のコンテンツを蓄積するために利用されてもよい。コンテンツはまた、振る舞いの異なる様々な種類のコンテンツのコレクション、又は、複数のコンテンツアイテムを一緒にグループ化する他のメカニズムに基づく様々な種類のコンテンツのコレクションを含んでもよい。例えば、アカウントは、任意のユーザがアクセス可能であってもよいところの公開コレクションを含んでもよい。ある実施形態では、公開コレクションにはウェブでアクセスが可能なアドレスが割り当てられてもよい。ウェブでアクセス可能な当該アドレスへのリンクは、公開フォルダのコンテンツにアクセスするために利用されてもよい。他の例では、アカウントは、写真及び／又はビデオを蓄積し得る写真コレクションを含んでいてもよく、また、写真及び／又はビデオ用の特定の属性及び行為を提供してもよい。アカウントはまた、音声アイテムを再生し、他の音声関連の行為を実行する性能を提供する、音声コレクションを含んでもよい。アカウントはさらに、特定目的のコレクションを含んでもい。アカウントはまた、複数のユーザアカウントにリンクされ、これらのアカウントから利用可能な共有コレクション又はグループコレクションを含んでもよい。ある実施形態では、共有コレクションへのアクセスは、共有コレクションにアクセス可能な個々のユーザごとに異なっていてもよい。
【００８４】
コンテンツアイテム１１０及び／又はコンテンツアイテム１３４は、データストア１１８に蓄積されてもよい。ある実施形態では、データストア１１８は、ストレージデバイス、複数のストレージデバイス、又はサーバであってもよい。また、データストア１１８は、１つ以上の通信ネットワークを介してアクセス可能な、クラウドストレージプロバイダ又はネットワークストレージであってもよい。コンテンツ・マネージメント・システム１０４は、コンテンツアイテムがコンテンツ・マネージメント・システム１０４によってどこに蓄積されているのかをユーザデバイス１０２が正確に知る必要がないように、コンテンツアイテムのシステム抽象化１２８（例えば、コンテンツアイテムのシステムデータベース抽象化レイヤ）を用いて、複雑さや詳細をユーザデバイス１０２から秘密にしてもよい。実施形態では、コレクションアイテムがユーザデバイス１０２上に現れるように、それらを同一コレクション階層に蓄積してもよい。また、コンテンツ・マネージメント・システム１０４は、様々な順番、配置、及び／又は階層においてコンテンツアイテムを蓄積してもよい。コンテンツ・マネージメント・システム１４０は、コンテンツアイテムを、ネットワークアクセス可能ストレージ（ＳＡＮ）デバイス、ＲＡＩＤ（ｒｅｄｕｎｄａｎｔ  ａｒｒａｙ  ｏｆ  ｉｎｅｘｐｅｎｓｉｖｅ  ｄｉｓｋｓ）等に蓄積してもよい。コンテンツ・マネージメント・システム１０４は、コンテンツアイテムを、ＦＡＴ、ＦＡＴ３２、ＮＴＦＳ、ＥＸＴ２、ＥＸＴ３、ＥＸＴ４、ＲｅｉｓｅｒＦＳ、 ＢＴＲＦＳ等の１つ以上のパーティションタイプを用いて蓄積してもよい。
【００８５】
データストア１１８はまた、コンテンツアイテム、コンテンツアイテムの種類、及び様々なアカウント、フォルダ、コレクション、又はグループとのコンテンツアイテムの関係を表すメタデータを蓄積してもよい。このコンテンツアイテムのためのメタデータは、コンテンツアイテムの一部として、及び／又は別々に蓄積されてもよい。メタデータは、オブジェクト指向データベース、リレーショナルデータベース、コンテンツアイテムシステム、又は任意の他のデータのコレクションに蓄積されてもよい。ある実施形態では、データストア１１８に蓄積された各コンテンツアイテムは、システム全体にわたってユニークな識別子が割り当てられてもよい。
【００８６】
ある実施形態では、データストア１１８は、コンテンツアイテムの複製やコンテンツアイテムのチャンクを特定することにより、要求されるストレージ空間の量を削減してもよい。複数のコピーを蓄積する代わりに、データストア１１８は、コンテンツアイテム１３４の１つのコピーを蓄積し、かつ、ポインタや１つのコピーと複製をつなぐための他のメカニズムを利用してもよい。同様に、データストア１１８は、より効率的にコンテンツアイテム１３４を蓄積すると共に、コンテンツアイテムに対する変更、コンテンツアイテムの異なるバージョン（バージョンツリーの分岐を含む）、及び変更履歴を追跡するコンテンツアイテムバージョン管理を利用することによって、アンドゥ（Undo）操作の機能を提供してもよい。変更履歴は、いつ元のコンテンツアイテムのバージョンに変更が適用され、変更されたコンテンツアイテムのバージョンを生成したかの、変更のセットを含んでもよい。
【００８７】
コンテンツ・マネージメント・システム１０４は、１つ以上のユーザデバイス１０２からのコンテンツの自動同期処理をサポートするように構成されてもよい。同期処理は、プラットフォーム非依存であってもよい。すなわち、コンテンツは、種類、性能、オペレーティングシステム等が様々な複数のユーザデバイス１０２にわたって同期されてもよい。例えば、ユーザデバイス１０２ａは、コンテンツ・マネージメント・システム１０４の同期モジュール１２２を介して、ユーザデバイス１０２のコンテンツアイテムシステム１０８内のコンテンツを、関連ユーザアカウントのコンテンツと同期させるクライアントソフトウェアを含んでもよい。場合によっては、クライアントソフトウェアは、コンテンツアイテムやフォルダ等の新規作成、削除、修正、コピー又は移動といった、指定されたコレクション及びそのサブコレクション内のコンテンツに対する任意の変更の同期を取ってもよい。既存のコンテンツマネージメントアプリケーションと統合されるクライアントソフトウェアの一例では、ユーザはローカルフォルダ内でコンテンツを直接に操作してもよく、その一方でバックグラウンドプロセスがローカルコンテンツの変更を監視し、コンテンツ・マネージメント・システム１０４と変更を同期する。ある実施形態では、バックグラウンドプロセスは、コンテンツ・マネージメント・システム１０４において更新されたコンテンツを特定し、ローカルコレクションと当該変更の同期を取る。クライアントソフトウエアは同期操作の通知を提供してもよく、コンテンツマネージメントアプリケーション内で直接、コンテンツ状態の表示を提供してもよい。ある実施形態では、ユーザデバイス１０２は利用可能なネットワーク接続を有さない場合がある。このシナリオでは、クライアントソフトウエアはコンテンツアイテムの変更がないかリンクされたコレクションを監視し、後にネットワーク接続が利用可能となったときにコンテンツ・マネージメント・システム１０４に対して同期を実行するべくそのような変更を待ち行列に入れてもよい。同様に、ユーザは、コンテンツ・マネージメント・システム１０４との同期を手動で止めるか一時停止してもよい。
【００８８】
ユーザはまた、コンテンツマネージメントインターフェースモジュール１５４によって生成され提供されるウェブインターフェースを介してコンテンツを見たり操作したりしてもよい。例えば、ユーザはウェブブラウザ内でコンテンツ・マネージメント・システム１０４によって提供されたウェブアドレスへ、辿り着いてもよい。  コンテンツアイテムの新バージョンをアップロードするといったウェブインターフェースを介したデータストア１１８内のコンテンツに対する変更や更新は、ユーザアカウントと関連付けられた他のユーザデバイス１０２へ伝搬されてもよい。例えば、それぞれが自身のクライアントソフトウェアを有する複数のユーザデバイス１０２が１つのアカウントと関連付けられてもよく、アカウント内のコンテンツアイテムは複数のユーザデバイス１０２のそれぞれの間で同期されてもよい。
【００８９】
コンテンツ・マネージメント・システム１０４は、コンテンツ及び／またはコンテンツのコレクションの公的又は私的な共有を管理するための共有モジュール１２６を含んでもよい。共有モジュール１２６は、共有の管理を独立に行ってもよいし、あるいは、ユーザデバイス１０２ａに配置された対応共有モジュール１５２ａ及びユーザデバイス１０２ｂに配置された対応共有モジュール１５２ｂ（纏めて、共有モジュール１５２）と共同で行ってもよい。コンテンツの公的共有は、コンテンツアイテム及び／又はそのコレクションを、コンテンツ・マネージメント・システム１０４を利用したネットワーク通信における任意のデバイスからアクセス可能にすることを含んでもよい。コンテンツの私的共有は、データストア１１８内のコンテンツアイテム及び／又はそのコレクションを、２以上のユーザアカウントとリンクして、各ユーザアカウントがコンテンツへアクセス可能にすることを含んでもよい。この共有は、プラットフォーム非依存形態で実行されてもよい。すなわち、コンテンツは、種類、性能、オペレーティングシステム等が様々の複数のユーザデバイス１０２にわたって共有されてもよい。例えば、共有コンテンツアイテムにアクセスするために、１つ以上の共有リンクがユーザ又はユーザのコンタクトに提供されてもよい。コンテンツはまた、様々な種類のユーザアカウントにわたって共有されてもよい。特に、仮想コレクションを他のユーザ又は他のユーザアカウントと共有することを可能にために、共有モジュール１２６がコレクションモジュール１２４と共に用いられてもよい。仮想コレクションは、コンテンツ識別子のコレクションであってもよく、それらは、ユーザデバイス１０２のコンテンツアイテムシステム１０８内の様々な場所に、及び／又は、リモートでコンテンツ・マネージメント・システム１０４に、蓄積されてもよい。
【００９０】
ある実施形態では、コンテンツ・マネージメント・システムのアカウントのための仮想コレクションは、（例えば、ストレージ内のコンテンツアイテムを識別する）コンテンツアイテムの１つ以上の識別子のコレクションに対応してもよい。仮想コレクションは、コレクションモジュール１２４を用いて、コンテンツ・マネージメント・システムによって蓄積され及び／又は管理された既存のコンテンツアイテムから選択し、データストレージにある既存のコンテンツアイテムを仮想コレクションと関連付ける（例えば、蓄積場所、コンテンツ識別子、又は蓄積されたコンテンツアイテムのアドレスと関連付ける）ことにより生成されてもよい。既存のコンテンツアイテムを仮想コレクションと関連付けることにより、コンテンツアイテムを仮想コレクションの一部に指定してもよい。その際、コンテンツアイテムをコレクション内に置くために、データストレージ内の他の場所にコンテンツアイテムを蓄積する（例えばコンテンツアイテムをディレクトリにコピー及びペーストする）必要がない。
【００９１】
ある実施形態では、コンテンツ・マネージメント・システム１０４は、コンテンツアイテムのためのコンテンツディレクトリ又はデータベーステーブル／エントリを保持するように構成されてもよい。ここで、各エントリや行は、データストア１１８内の各コンテンツアイテムの場所を特定する。  ある実施形態では、データストア１１８内に蓄積される各コンテンツアイテムのために、ユニーク又はほぼユニークな識別子が蓄積されてもよい。
【００９２】
ある実施形態では、メタデータが各コンテンツアイテムのために蓄積されてもよい。例えば、メタデータは、コンテンツアイテムを識別するために用いられるコンテンツのパスを含んでいてもよい。コンテンツのパスは、コンテンツアイテムの名前と、コンテンツアイテムと関連付けられたコンテンツアイテムの階層（例えば、ユーザデバイス１０２内のローカルな蓄積に対するパス）とを含んでもよい。コンテンツ・マネージメント・システム１０４は、従来的な階層ビューを有するユーザインタフェースにおいて適切なコンテンツアイテムの階層でコンテンツアイテムを表示するために、コンテンツのパスを使用してもよい。データストア１１８内のコンテンツアイテムの場所を識別するコンテンツのポインタもまた、コンテンツ識別子と共に蓄積されてもよい。例えば、コンテンツのポインタは、メモリ内のコンテンツアイテムの正確な蓄積アドレスを含んでもよい。ある実施形態では、コンテンツのポインタは、それぞれがコンテンツアイテムの一部を含む複数の場所を指し示してもよい。
【００９３】
コンテンツのパス及びコンテンツのポインタに加えて、コンテンツアイテムのエントリ／コンテンツアイテムデータベースエンティティのデータベーステーブル行は、コンテンツアイテムへのアクセス権を有するユーザアカウントを識別するユーザアカウント識別子を含んでもよい。ある実施形態では、複数のユーザアカウント識別子は、コンテンツアイテムのアクセス権が複数のユーザアカウントにより共有されていることを示す単一コンテンツエントリと関連付けられてもよい。
【００９４】
コンテンツアイテムを私的に共有するために、共有モジュール１２６は、コンテンツアイテムと関連付けられたコンテンツエントリ又はデータベーステーブル行にユーザアカウント識別子を追加するように構成されてもよく、これにより、追加されたユーザアカウントによるコンテンツアイテムへのアクセスを許可する。共有モジュール１２６はまた、コンテンツアイテムへのユーザアカウントのアクセスを制限するために、コンテンツエントリ又はデータベーステーブル行からユーザアカウント識別子を削除するように構成されてもよい。仮想コレクションについて、データベーステーブルへユーザアカウントを追加又は削除するために、共有モジュール１２６が利用されてもよい。
【００９５】
コンテンツを公的に共有する場合、共有モジュール１２６は、ＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）のようなカスタムネットワークアドレスを生成するように構成されてもよい。これにより、認証無しで任意のブラウザからコンテンツ・マネージメント・システム１０４内のコンテンツにアクセスすることが可能となる。これを実現するために共有モジュール１２６は、生成されたＵＲＬにコンテンツ識別データを含めるように構成されてもよく、当該コンテンツ識別データは、要求されたコンテンツアイテムを適切に識別し、返信するために後に用いられてもよい。例えば、共有モジュール１２６は、ユーザアカウント識別子とコンテンツのパスとを生成されたＵＲＬに含めるように構成されてもよい。ＵＲＬが選択されると、ＵＲＬに含まれるコンテンツ識別データはコンテンツ・マネージメント・システム１０４に送信されてもよい。コンテンツ・マネージメント・システム１０４は受信したコンテンツ識別データを使用して適切なコンテンツエントリを識別し、そのコンテンツエントリに関連付けられたコンテンツアイテムを返信してもよい。
【００９６】
仮想コレクションを公的に共有する場合、共有モジュール１２６は、ＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）のようなカスタムネットワークアドレスを生成するように構成されてもよい。これにより、認証無しで任意のブラウザからコンテンツ・マネージメント・システム１０４内のコンテンツにアクセスすることが可能となる。これを実現するために共有モジュール１２６は、生成されたＵＲＬにコレクション識別データを含めるように構成されてもよく、当該コンテンツ識別データは、要求されたコンテンツアイテムを適切に識別し、返信するために後に用いられてもよい。例えば、共有モジュール１２６は、ユーザアカウント識別子とコレクション識別子とを生成されたＵＲＬに含めるように構成されてもよい。ＵＲＬが選択されると、ＵＲＬに含まれるコンテンツ識別データはコンテンツ・マネージメント・システム１０４に送信されてもよい。コンテンツ・マネージメント・システム１０４は受信したコンテンツ識別データを使用して適切なコンテンツエントリまたはデータベース行を識別し、そのコンテンツエントリまたはデータベース行に関連付けられたコンテンツアイテムを返信してもよい。
【００９７】
ＵＲＬの生成に加えて、共有モジュール１２６はまた、コンテンツアイテムへのＵＲＬが生成されたことを記録するように構成されてもよい。ある実施形態では、コンテンツアイテムに関連付けられたコンテンツエントリは、コンテンツアイテムへのＵＲＬが生成されたかどうかを示すＵＲＬフラグを含んでもよい。例えば、ＵＲＬフラグは、コンテンツアイテムへのＵＲＬがまだ生成されていないことを示すために最初に０またはｆａｌｓｅに設定されるブール値であってもよい。共有モジュール１２６は、コンテンツアイテムへのＵＲＬを生成した後は、フラグの値を１またはｔｒｕｅに変更するよう構成されてもよい。
【００９８】
ある実施形態では、共有モジュール１２６は生成されたＵＲＬを非活性化するように構成されてもよい。例えば、各コンテンツエントリは、生成されたＵＲＬからの要求に応じてコンテンツが返信されるべきかどうかを示すＵＲＬ活性フラグを含んでもよい。例えば、共有モジュール１２６は、ＵＲＬ活性フラグが１又は「真」に設定されている場合、生成されたリンクにより要求されたコンテンツアイテムのみを返信するように構成されてもよい。ＵＲＬ活性フラグ値又はブール値を変更することで、ＵＲＬが生成されたコンテンツアイテム又はコレクションへのアクセスを容易に制限してもよい。これにより、ユーザは、コンテンツアイテムを移動したり生成されたＵＲＬを削除したりする必要なく、共有コンテンツに対するアクセスを制限することができる。同様に、共有モジュール１２６は、ＵＲＬ活性フラグの値を１又は「真」に再び変更することによりＵＲＬを再活性化してもよい。従って、ユーザは、新たなＵＲＬを生成する必要なしに、コンテンツアイテムへのアクセスを容易に回復してもよい。
【００９９】
＜例示的システム＞
本発明の例示的な実施形態では、特定の実施形態のルーチンを実装するために任意の適切なプログラミング言語を用いてもよい。当該プログラミング言語には、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｐｙｔｈｏｎ、Ｒｕｂｙ、ＣｏｆｆｅｅＳｃｒｉｐｔ、アセンブリ言語等を含む。また、手続型又はオブジェクト指向等の異なるプログラミング技術を採用してもよい。ルーチンは、１つの処理デバイス又は複数のプロセッサ上で実行し得る。ステップ、操作、コンピュータ処理は特定の順番で表され得るが、この順番は異なる特定の実施形態において変更され得る。ある特定の実施形態では、本明細書において連続的に示された複数のステップは、同時に実行され得る。
【０１００】
特定の実施形態は、命令実行システム、装置、システム又はデバイスと共に使用するためのコンピュータ可読ストレージデバイス又は非一時的なコンピュータ可読媒体に実装され得る。特定の実施形態は、ソフトウェア又はハードウェア又は両方の組み合わせの制御ロジックの形式で実装され得る。この制御ロジックは、１つ以上のプロセッサで実行されたときに、特定の実施形態に記載されたものを実行するために動作可能であり得る。
【０１０１】
特定の実施形態が、プログラムされた汎用デジタルコンピュータ、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックデバイス、ＦＰＧＡ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙｓ）、光学的、化学的、生物学的、量子又はナノ加工のシステム、コンポーネント及び機構を利用して実装されてもよい。一般に、特定の実施形態の機能は、この分野で知られている任意の手段により実現されてもよい。分散化され、ネットワーク化されたシステム、コンポーネント、及び／又は回路が用いられてもよい。データの通信又は伝送は有線、無線又は任意の他の手段により実施されてもよい。
【０１０２】
図／図面に示された要素の１つ以上は、より分割された又は統合された方法で実装されてもよく、また、特定のアプリケーションに従って有用なものであっても、削除され又はある場合には動作しないものとみなされてもよいことは理解されるであろう。ストレージデバイス等のマシン可読媒体に蓄積されてもよいところのプログラムやコードを実装して、上述した任意の方法をコンピュータに実行させることは、精神及び範囲の内である。
【０１０３】
本明細書中及び以下の特許請求の範囲において使われるように、「ａ」、「ａｎ」及び「ｔｈｅ」は文脈において明示的に述べない限り複数の参照を含む。また、本明細書中の記載及び以下の特許請求の範囲において使われるように、「中で（in）」の意味はコンテキストが明示的に述べない限り「中で（ｉｎ）」及び「上で（ｏｎ）」を含む。
【０１０４】
共有仮想空間を提供するための方法について記載してきたが、本発明の精神及び範囲から乖離することなく多くの変更がなされ得ることが理解されるべきである。技術分野の当業者から見てクレームされた主題に対して実質的でない変更や、知られていない、或いは、後に発明されたものも、同等に請求項の範囲内に含まれるものである。従って、技術分野の当業者にとって、現在または後に知られることになる明白な代替物は、定義された要素の範囲内であると定義される。本発明の記述した実施形態は、説明の目的のために提示されたものであって、限定目的で提示されてものではない。
【図１】
0006311030.tif 000002
【図２】
0006311030.tif 000003
【図３】
0006311030.tif 000004
【図４】
0006311030.tif 000005
【図５】
0006311030.tif 000006
【図６】
0006311030.tif 000007
【図７】
0006311030.tif 000008
【図８】
0006311030.tif 000009
【図９】
0006311030.tif 000010
【図１０】
0006311030.tif 000011
【図１１】
0006311030.tif 000012
【図１２】
0006311030.tif 000013
【図１３】
0006311030.tif 000014
【図１４】
0006311030.tif 000015
【図１５】
0006311030.tif 000016