JP2022023865A - デバイス上でのメッセージ管理とドキュメント生成のためのプログラム、方法、及びデバイス - Google Patents

Abstract

【課題】第１のメッセージと第２のメッセージとの繋がりが分かるようにするメッセージの管理プログラム、モバイルデバイス上でメッセージを管理するための方法及びモバイルデバイスを提供する。
【解決手段】モバイルデバイスは、メッセージを管理するプログラムにより、通信し、且つ、コンテンツを編成するために、テキスト及びメディアにタグ付け機能を付与するチャットインタフェースを有する。以前の単なる線形的なタイムラインのチャットに、新しくスレッド様の構造を追加する。第１のメッセージに対する入力を受け付けると、第１のディスプレイ画面を、第１のディスプレイ画面の分離画面である第２のディスプレイ画面に変更し、第１のメッセージと第２のメッセージとを第２のディスプレイ画面に表示する。
【選択図】図２（ｅ）

Description

本開示は一般的に通信プラットフォームとデバイスに関し、より具体的にはデバイス上でのメッセージドキュメント生成とメッセージ管理に関する。

関連技術において、チャットなどのメッセージングアプリケーションでは、会話タイムラインの簡単でよく理解されたインタラクションメタファ（interaction metaphor）を利用して、人々が多様なマルチメディアを共有することを可能にする。そのような関連技術のアプリケーションによって、小さなタスク志向のユーザグループが、職場及び個人生活の場の両面においてグループチャットで相互調整することを支援可能とする。ただし、既存のチャットなどのアプリケーションは通信及びコンテンツ共有のための機能は提供可能であるが、長い時間の間に生成され、共有されたコンテンツを簡潔且つ有用な方法で見つけることは困難なことがある。関連技術実装のユーザは、単一の単語を見つけることしかできず、質問に対する応答のような一連の繋がったコメント又は回答（これらは従来のチャットインタフェースではチャット全体に広がっている可能性がある）を見つけることはできない。

関連技術の実装では、コンテンツを後で利用するため、又はアクセスを容易にするために編成することはできない場合がある。これができれば、共通のゴール又はプロジェクトを有する小さなタスク志向のグループにとって有用となり得る。

更には、そのようなチャットなどのメッセージングアプリケーションを実装するデバイスの多くは、デバイス（例えばスマートフォン、タブレットなど）の大きさのために表示スペースが限られたディスプレイを使用しているので、そのような限定された表示スペースを考慮に入れたチャットメッセージを提供するインタフェースが必要とされている。

米国特許第８５５８６９３号明細書 米国特許第８２１９１１５号明細書 米国特許第７５８３９７２号明細書

ＡＬＬＡＮ， Ｊ．， ＥＴ ＡＬ．，著、「ＴＡＫＩＮＧ ＴＯＰＩＣ ＤＥＴＥＣＴＩＯＮ ＦＲＯＭ ＥＶＡＬＵＡＴＩＯＮ ＴＯ ＰＲＡＣＴＩＣＥ」、ＰＲＯＣＥＥＤＩＮＧＳ ＯＦ ＴＨＥ ３８ＴＨ ＨＡＷＡＩＩ ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＣＯＮＦＥＲＥＮＣＥ ＯＮ ＳＹＳＴＥＭ ＳＣＩＥＮＣＥＳ， ４（０４）， ２００５， １０ ＰＧＳ． ＣＳＥＬＬＥ Ｇ．， ＥＴ ＡＬ．，著、「ＢＵＺＺ ＴＲＡＣＫ： ＴＯＰＩＣ ＤＥＴＥＣＴＩＯＮ ＡＮＤ ＴＲＡＣＫＩＮＧ ＩＮ ＥＭＡＩＬ」，ＩＵＩ’０７， ＪＡＮＵＡＲＹ ２８－３１， ２００７， ＨＯＮＯＬＵＬＵ， ＨＡＷＡＩＩ， ８ ＰＧＳ． ＣＨＵＮＧ， Ｊ．， ＥＴ ＡＬ．，著、「"ＷＩＴＨＯＵＴ ＴＨＥ ＣＬＵＴＴＥＲ ＯＦ ＵＮＩＭＰＯＲＴＡＮＴ ＷＯＲＤＳ"： ＤＥＳＣＲＩＰＴＩＶＥ ＫＥＹ ＰＨＲＡＳＥＳ ＦＯＲ ＴＥＸＴ ＶＩＳＵＡＬＩＺＡＴＩＯＮ」、ＡＣＭ ＴＲＡＮＳＡＣＴＩＯＮＳ ＯＮ ＣＯＭＰＵＴＥＲ－ＨＵＭＡＮ ＩＮＴＥＲＡＣＴＩＯＮ， １９（３）， ＡＲＴＩＣＬＥ １９， ＯＣＴＯＢＥＲ ２０１２， ２９ ＰＧＳ． ＦＯＮＧ， Ｖ．，著、「ＡＮ ＥＤＩＴＡＢＬＥ ＭＵＬＴＩ－ＭＥＤＩＡ ＡＵＴＨＯＲＩＮＧ ＥＢＯＯＫ ＳＹＳＴＥＭ ＦＯＲ ＭＯＢＩＬＥ Ｌｅａｒｎｉｎｇ」、ＩＣＨＬ ２０１４， ＬＮＣＳ ８５９５， ＰＰ． １８４－１９５， ２０１４ ＫＩＭ Ｊ．，著、「ＴＯＯＬ ＳＣＡＰＥ： ＥＮＨＡＮＣＩＮＧ ＴＨＥ ＬＥＡＲＮＩＮＧ ＥＸＰＥＲＩＥＮＣＥ ＯＦ ＨＯＷ－ＴＯ ＶＩＤＥＯＳ」、ＣＨＩ ２０１３ ＥＸＴＥＮＤＥＤ ＡＢＳＴＲＡＣＴＳ， ＡＰＲＩＬ ２７－ＭＡＹ ２， ２０１３， ＰＡＲＩＳ， ＦＲＡＮＣＥ， ＰＰ． ２７０７－２７１２ 「ＴＨＥ ２００４ ＴＯＰＩＣ ＤＥＴＥＣＴＩＯＮ ＡＮＤ ＴＲＡＣＫＩＮＧ （ＴＤＴ２００４） ＴＡＳＫ ＤＥＦＩＮＩＴＩＯＮ ＡＮＤ ＥＶＡＬＵＡＴＩＯＮ ＰＬＡＮ」、ＶＥＲＳＩＯＮ １．０， ＯＣＴＯＢＥＲ １９， ２００４， １６ ＰＧＳ． 「ＰＡＴＥＮＴ ＭＥＳＳ ＦＯＲ ＬＯＣＡＴＩＯＮ－ＢＡＳＥＤ ＲＥＭＩＮＤＥＲＳ ＦＯＲ ＡＭＡＺＯＮ， ＡＰＰＬＥ， ＭＩＣＲＯＳＯＦＴ ＡＮＤ ＧＯＯＧＬＥ」、ＮＯＶＥＭＢＥＲ ２２， ２０１１， １ ＰＧ． 「ＯＵＲ ＨＯＭＥ」（２０１６年５月２３日取得）９ ＰＧＳ． ＵＲＬ：ＨＴＴＰ：／／ＯＵＲＨＯＭＥＡＰＰ．ＣＯＭ／ 「ＳＬＡＣＫ ＴＥＣＨＮＯＬＯＧＩＥＳ」（２０１６年５月１７日取得）２ ＰＧＳ． ＵＲＬ：ＨＴＴＰ：／／ＳＬＡＣＫ．ＣＯＭ／ 「ＷＩＫＩ ＨＯＷ」（２０１６年５月２３日取得）３ ＰＧＳ． ＵＲＬ：ＨＴＴＰ：／／ＷＩＫＩＨＯＷ．ＣＯＭ／ＭＡＩＮ－ＰＡＧＥ

本開示の技術は、第１のメッセージと第２のメッセージとの繋がりが分かるようにするメッセージの管理プログラム、モバイルデバイス上でメッセージを管理するための方法、及びモバイルデバイスを提供する。

本開示の態様は、モバイルデバイス上でメッセージを管理するためにコンピュータを、モバイルデバイスから送信された第１のメッセージをユーザインタフェース上に表示する手段、第１のメッセージに応答する別のモバイルデバイスからの第２のメッセージを監視する手段、及び別のモバイルデバイスからの第２のメッセージを受信すると、ユーザインタフェース上に表示されている第１のメッセージ上に、第２のメッセージを表示のために提供し、且つ第１のメッセージと第２のメッセージとの間の関係インタフェースをユーザインタフェース上に提供するように構成されたユーザインタフェースインジケータを生成する手段として機能させるためのメッセージの管理プログラムである。このユーザインタフェースインジケータは、スレッド及びサブスレッドのインタフェース、カラーコード化された関係インタフェース、及び第１のメッセージに関係するメッセージ用の分離画面の生成、のうちの１つとして関係インタフェースを提供するように構成されている。

本開示の態様には、モバイルデバイス上のメッセージを管理するための方法が含まれる。この方法には、モバイルデバイスから送信された第１のメッセージをユーザインタフェース上に表示することと、第１のメッセージに応答する別のモバイルデバイスからの第２のメッセージを監視することと、別のモバイルデバイスからの第２のメッセージを受信すると、ユーザインタフェース上に表示されている第１のメッセージ上に、第２のメッセージを表示のために提供し、且つ第１のメッセージと第２のメッセージとの間の関係インタフェースをユーザインタフェース上に提供するように構成されたユーザインタフェースインジケータを生成することとを含むことができる。このユーザインタフェースインジケータは、スレッド及びサブスレッドのインタフェース、カラーコード化された関係、及び第１のメッセージに関係するメッセージ用の分離画面の生成、のうちの１つとして関係インタフェースを提供するように構成されている。

本開示の態様はモバイルデバイスを含む。これはユーザインタフェースを表示するように構成されたディスプレイと、プロセッサと、を備え、このプロセッサは、モバイルデバイスから送信された第１のメッセージをユーザインタフェース上に表示し、第１のメッセージに応答する別のモバイルデバイスからの第２のメッセージを監視し、別のモバイルデバイスからの第２のメッセージを受信すると、ユーザインタフェース上に表示されている第１のメッセージ上に、第２のメッセージを表示のために提供し、且つ第１のメッセージと第２のメッセージとの間の関係インタフェースをユーザインタフェース上に提供するように構成されたユーザインタフェースインジケータを生成するように構成されている。このユーザインタフェースインジケータは、スレッド及びサブスレッドのインタフェース、カラーコード化された関係インタフェース、及び分離画面の生成、のうちの１つとして関係インタフェースを提供するように構成されている。

本開示の態様は、モバイルデバイス上でメッセージを管理するにコンピュータを、モバイルデバイスから送信された第１のメッセージをユーザインタフェース上に表示する手段、ユーザインタフェースの第１のメッセージ上に第１のユーザインタフェースインジケータを提供する手段、及び第１のメッセージと第２のメッセージとに基づいてドキュメントを生成するためのインタフェースを備える第２のユーザインタフェースインジケータを提供する手段として機能させるためのメッセージの管理プログラムである。ここで、第１のユーザインタフェースインジケータは、一つ又は複数の他のモバイルデバイスから第１のメッセージに応答して送信されて、モバイルデバイスによって受信された第２のメッセージを、第１のユーザインタフェースインジケータへの入力を受信すると表示のために提供するように構成された関係インタフェースを備え、第１のユーザインタフェースインジケータは、スレッド及びサブスレッドのインタフェース、カラーコード化された関係インタフェース、及び分離画面の生成、のうちの１つとして関係インタフェースを提供するように構成されている。

本開示の態様には、モバイルデバイス上のメッセージを管理するための方法を更に含む。この方法は、モバイルデバイスから送信された第１のメッセージをユーザインタフェース上に表示することと、ユーザインタフェースの第１のメッセージ上に第１のユーザインタフェースインジケータを提供することと、第１のメッセージと第２のメッセージとに基づいてドキュメントを生成するためのインタフェースを備える第２のユーザインタフェースインジケータを提供することと、を含む。ここで、第１のユーザインタフェースインジケータは、一つ又は複数の他のモバイルデバイスから第１のメッセージに応答して送信されて、モバイルデバイスによって受信された第２のメッセージを、第１のユーザインタフェースインジケータへの入力を受信すると表示のために提供するように構成された関係インタフェースを含み、第１のユーザインタフェースインジケータは、スレッド及びサブスレッドのインタフェース、カラーコード化された関係インタフェース、及び分離画面の生成、のうちの１つとして関係インタフェースを提供するように構成されている。

本開示の態様は更に、モバイルデバイスを含み、このモバイルデバイスには、ユーザインタフェースを提供するように構成されたディスプレイと、プロセッサであって、モバイルデバイスから送信された第１のメッセージをユーザインタフェース上に表示し、ユーザインタフェースの第１のメッセージ上に、第１のユーザインタフェースインジケータを提供するように構成されたプロセッサ、を含むことができる。ここで第１のユーザインタフェースインジケータは、第１のメッセージに応答し、モバイルデバイスで受信された、一つ又は複数の他のモバイルデバイスからの第２のメッセージを、ユーザインタフェースインジケータ上への入力を受信すると、表示のために提供するように構成され、第１のユーザインタフェースインジケータは、スレッド及びサブスレッドのインタフェース、カラーコード化された関係インタフェース、及び分離画面の生成、のうちの１つとして関係インタフェースを提供するように構成されている。またこのプロセッサは、第１のメッセージと第２のメッセージとに基づいてドキュメントを生成するためのインタフェースを備える第２のユーザインタフェースインジケータを提供するように構成されている。

実装例による、システムの概要を示す図である。 実装例による、拡張チャットアプリケーション（管理プログラム）を示す図である。 実装例による、拡張チャットアプリケーション（管理プログラム）を示す図である。 実装例による、拡張チャットアプリケーション（管理プログラム）を示す図である。 実装例による、拡張チャットアプリケーション（管理プログラム）を示す図である。 実装例による、拡張チャットアプリケーション（管理プログラム）を示す図である。 実装例による、全体的なフロー図である。 実装例による、データフロー図である。 実装例による、コンテンツ収集の流れを示す図である。 実装例による、ドキュメント生成のフロー図である。 実装例による、チャットアプリケーション用のドキュメント生成インタフェースの例を示す図である。 実装例による、チャットアプリケーション用のドキュメント生成インタフェースの例を示す図である。 実装例による、チャットアプリケーション用のドキュメント生成インタフェースの例を示す図である。 実装例による、ドキュメント準備、組み立て、及び提示のフロー図である。 実装例での使用に好適な例示的コンピュータデバイスを有する、例示的コンピューティング環境を示す図である。

以下の詳細な説明において、本出願の図面及び実装例の更なる詳細を提供する。図面間で重複する要素の参照番号及び説明は、明確にするために省略する。明細書全体を通して使用する用語は例示として提供されるものであり、限定を意図するものではない。例えば、「自動的」という用語の使用は、本出願の実装の実行において当業者が所望する実装に応じて、ユーザ又は管理者が本実装の特定の態様を制御することを含む完全自動又は半自動の実装を含み得る。

本明細書に記載の実装例は、モバイルデバイスなどのデバイスに対する、メッセージ管理及びドキュメント生成システムに関する。そのようなデバイスにおいては、たとえばチャットなどのようなメッセージは、過去のメッセージとは、受信により出現した時間以外には、体系化されていなかったり関係性がない、アドホック（ad-hoc）的な現れ方をし得る。そのようなメッセージのアドホック受信は、モバイルデバイスなどのような画面スペースの限られたデバイスでは特に問題となり得るものであって、ユーザはメッセージのコンテキストを判断するためにメッセージを繰り返しスクロールしなければならない。実装例では、メッセージ管理インタフェースが提供され、コンテキスト（たとえばトピックやグループなど）によってメッセージをグループ化し、また特定のメッセージコンテキストに関連する人へタスクやリマインダを割り当てる。実装例では更にそのようなグループ化されたメッセージを、メッセージ送受信の参加者間で共有可能なドキュメントに変換するシステムが提供される。

本明細書で説明する実装例の恩恵を受けることができるグループの例としては、これに限らないが、家族（又は高齢者）の世話人、動物の共同世話人、他人の支援又は共通の業務やプロジェクトの調整をするグループ、又は配信チームのメンバがある。これらのグループには次のような共通の特性がある。すなわち問題を解決するということであって、特に問題の複数の部分が将来再発する可能性のある反復性のタスクである場合にそうである。グループが繰り返し対処しなければならない可能性のあるいくつかの問題がある。グループはそのトピックに関して議論して、将来の現実的な解決策に至ることもある。グループによって完了しなければならないタスクリスト、並びにグループメンバが把握できる締切りが共通のゴールに到達する助けになることもある。すべてのグループメンバが同時に参加できるわけではないので、通信は違うトピックに関するものであったり、非同期的に発生したりし得る。したがって、実装例は、将来の利用のための生成されたナレッジ（knowledge）の抽出を容易にできる。

関連技術の実装では、マルチメディアドキュメントを作成し、将来の利用のためにやり方指示、よくある質問（ＦＡＱ）、概要報告などのコンテンツをユーザが保存及び編集可能となるナレッジ抽出システムを有する、メッセージングアプリケーションのインタフェースが提供されていない。

メッセージ管理プログラムのアプリケーションインタフェースの実装例として、拡張チャットインタフェースがあって、メッセージとしてのチャットを構成して、優先度でマーク付け可能なトピック及び質問の概要を与えることが可能である。これらの要素は、チャット内にハイライトされ、開始画面上に開始点として表示される。実装例において、メッセージのひとつであるチャットに蓄積されたナレッジに基づいた、やり方指示、ＦＡＱ、報告も作成される。これは、ユーザによりガイドされるか、半自動化又は自動化とすることができる。既存の関連技術の実装ではチャットを構成することはできない。更に、チャットのコンテンツを可読ドキュメントフォーマットに変換する機能も、関連技術には備えられていない。

図１は、実装例によるシステムの概要を示している。システム１００には、拡張チャットアプリケーション１０１、ドキュメント生成器１０２、及びドキュメントビューア１０３を含むことができる。拡張チャットアプリケーション１０１は、タスク指向の小グループを支援可能な機能で構成され、モバイルデバイス及びデスクトップコンピュータで利用可能である。ドキュメント生成器１０２は、やり方指示、ＦＡＱ、レポートなどのようなマルチメディアドキュメントの作成を可能とする。ドキュメントビューア１０３は、印刷可能レポート１０４としても生成可能であるドキュメントをフィルタリング、閲覧、及びプレイするために使用される。

図２（ａ）は、チャットなどのメッセージを管理する管理プログラムの実装例による拡張チャットアプリケーションを示している。関連技術のチャットアプリケーションには、テキスト、画像、映像、及び音声のメッセージの送信、画像と映像の編集、アニメーションＧＩＦと顔文字の送信、連絡先カードの送信、及びグループ通信などの機能を含むことができる。拡張チャットアプリケーションの実装例では、タスク志向の小グループ向けに設計された追加要素が提供される。そのような要素は、チャットビューにおける会話の間に作成されうる。チャットのエントリに依存して、ダイアログが開き、ユーザは追加情報（例えば、期日、選択されたグループメンバ、有効継続期間など）を入力可能である。次に、作成された要素はチャット内にマークされるか、及び／又は図２に示すような拡張された開始／概要画面に示される。これは単にグループと過去のチャットを示すだけではなく、未回答の質問やアクションを必要とする他の要素、並びにチャット内に新規に加えられた要素又はメッセージのインジケータが次のように示される。

サブスレッド：サブスレッドの実装例では、質問や議論がチャット中にハイライトされ、終了としてマークされるまではそのアプリケーションの開始ページに表示される（例えば図２（ａ）の２０１の「どこで花を買えばいい？」を参照）。実装例では、チャットを厳密なタイムラインベースのビューに分割して、要素のスレッド状構造を開始することもできる。更に、サブスレッドが、所望の実装によっては他のサブスレッドも含み得る。例えば、サブスレッドが議論に参加しているグループに基づいて他のサブスレッドに分岐することもある。スレッド／サブスレッドがサブスレッドを持って、所望の実装によっては任意の深さのスレッドチェーンを容易にすることができる。

メモ：メモの実装例では、メモがチャット内でハイライトされたり、受信者がマークして開始ページからそのメモを隠すことも可能である。そのようなメモは、「付箋」的なメタファについて行き、アプリケーションが終了するまでは開始画面上に留まることができる。対照的に、「付箋」的でない他の議論要素は、タイムライン中に適宜配置されて、新しいメッセージが追加されると画面から取り除くことができる。

Ｔｏ―Ｄｏ／タスク：実装例では、タスクはチャット中でハイライトされて、アプリケーション内の追加タブのｔｏ－ｄｏリストに表示することができる。タスクは、指定されたグループメンバの少なくとも一人によって完了したとしてマークすることができる。そして所望の実装によっては、締切りがある場合や、フィードバック（例えば結果の写真）を要求されることもある。

将来へのメッセージ：実装例では、メッセージは未来のある時刻に送信されて、特定された未来のある時刻にのみ配信されるように計画することができる。

時間ベースのリマインダ：実装例では、リマインダの日付／時刻を送信者が指定する以外は通常のメッセージと同じようにして、時間ベースのリマインダを作成可能である。このリマインダは受信者のメッセージのタイムラインリストに（例えば即時に）表示されるように構成することができるが、特定の日付／時刻にその受信者に最新のメッセージとして再表示するように構成することも可能である。

場所ベースのリマインダ：場所ベースのリマインダ用の実装例では、送信者は、日付／時刻の代わりにリマインダ場所を設定してメッセージが再表示されるようにする。例えば、メッセージが場所ベースのリマインダで送信されると、メッセージはその受信装置が特定の場所に行くまでは、受信装置のキュー内に保持することができる。別の実装例では、メッセージは受信装置がその特定の場所に居ることを示したら、送信されてもよい。所望の実装に応じて他の実装を利用することも可能である。

時間と場所ベースのリマインダ：実装例では、時間リマインダと場所リマインダを組み合わせて、送信者がメッセージを表示する日付／時刻に加えてリマインダ場所も設定できるようすることが可能である。

グループカレンダ：実装例では、グループカレンダが、個人とグループの活動の概要を与える。グループカレンダはほかのカレンダに同期してもよい。イベントとアポイントメントをチャットからカレンダに直接送信することができる。

マークメッセージ：実装例では、チャットのタイムラインに投稿されたメッセージは、重要又は「いいね！」としてマークすることが可能である。

検索：実装例において、チャット等のメッセージ中の特定の単語、画像、音声、及び／又は映像の検索を容易にするインタフェースが提供される。メディア検索には、日付検索、メディア種類検索等の先進的検索方法が必要である。

上記の各機能はグループメンバの集合に送信可能である。
・全グループ：全グループメンバが要素を受信する。
・グループの一部：グループメンバの画定された部分集合が要素を受信する。
・単一メンバ：グループメンバの一人だけが要素を受信する。

チャットのサブセクションで新たな議論を開始する質問としてサブスレッドを追加することは、関連技術のチャットアプリケーションにはない概念である。サブスレッドを利用することで、着信チャットメッセージを受信済みとして編成することが可能である。そうすることで、関連技術の実装のように受信時にメッセージを表示するのではなく、関連メッセージを対応スレッドに関連付けることで画面上のスペースを節約することが可能である。

実装例において、サブスレッドはいくつかの理由で作成可能である。例えば、サブスレッドは、トピックに関する情報をチャット内に一緒に保持することを容易とし、質問が確実に回答されるようにする。

グループメンバがトピックを議論することを希望して議論を開始してもよい。関連技術のアプリケーションではチャットビューでの議論の開始を容易にしているが、時間経過とともに１つのトピック又は議論に関連するメッセージが他の議論やチャットトピックと混同される可能性がある。サブスレッドを立てることで、このグループから他のトピック及び議論へ迷い込みかねない過去の回答の参照や引用を必要としないで、グループを１つのトピックに集中させることができる。

更に、グループチャットにおける質問と回答に関する１つの問題は、質問に対する応答が元の質問とは切り離されて、他のトピックからのメッセージに混同されてしまう可能性があることである。例えば、チャット対話中にユーザが質問しても、その質問に答えることのできる人がオンラインしていないことがあり、且つそのチャットの対話は継続していると、特定の人がオンラインに戻ってくるまでに、その質問は話題の中心から反れてしまうことがあり得る。他のユーザがすぐに回答しないうちに、あるユーザが連続するメッセージで複数の質問をする場合もある。グループ内の一人又は複数のユーザが１つの質問に答え始めて、話題の中心がずれてしまったためにその他の質問は忘れてしまうこともある。質問に関するサブスレッドを作成することで、チャット中にマークして示され、ホーム画面（これはユーザがそのアプリケーションを開くときのエントリ点である）に新規事項として表示されるために、質問を忘れられないようにすることができる。

図２（ｂ）は、実装例によるチャットアプリケーションを示している。特に図２（ｂ）は特別の要素を生成する画面の例を示している。実装例において、メッセージ作成時にサブスレッドが作成され得る。サブスレッドは、新規のメッセージを作成するときか、又は既に投稿されているメッセージのレベルを上げることによって作成可能である。ユーザが送信する前にメッセージを入力（又はファイルを投稿）する場合、そのメッセージは図２（ｂ）に示すように、特別な要素（例えばサブスレッド）として要素マーキング画面２１０上にマークされ得る。特別の要素を作成して、サブスレッドにテキストを書き込むことも可能である。

実装例では、既に投稿されたメッセージは、フォローアップメッセージを利用しないでレベル上げすることが可能である。例えば、ユーザは（例えば、必ずしもエントリの制作者でなくても）、チャット内の要素に対してアクション（例えばタッチスクリーン上での長押し動作）をすることが可能である。メニューが図２（ｂ）に示すように要素マーキング画面２１０を開き、そこでエントリが特別要素としてマークされ得る。

実装例では、既に投稿されたメッセージは、フォローアップメッセージを手動選択することでレベル上げすることが可能である。実装例では、ユーザは（例えば、必ずしもエントリの制作者でなくても）、チャット内の要素に対してアクション（例えばタッチスクリーン上での長押し動作）をすることが可能である。メニューが図２（ｂ）に示すように要素マーキング画面２１０を開き、そこでエントリが特別要素としてマークされ得る。そうしてユーザは次の画面に進んで、新規サブスレッドの一部となるべき既存のエントリを選択することが可能である。

実装例では、既に投稿されたメッセージは、フォローアップメッセージを半自動選択することでレベル上げ可能である。実装例では、ユーザは（例えば、必ずしもエントリの制作者でなくても）、チャット内の要素に対してアクション（例えばタッチスクリーン上での長押し動作）をすることが可能である。メニューが図２（ｂ）に示すように要素マーキング画面２１０を開き、そこにはエントリが特別要素としてマークされ得る。そうしてユーザは次の画面に進んで、新規サブスレッドの一部となるべき事前選択されたエントリを補正することが可能である。

サブスレッドは、スレッド及びサブスレッドのインタフェース、カラービュー、あるいは２画面の分割ビューなどのような様々な異なる方法で閲覧できる。閲覧者はチャットアプリケーションを利用して異なる表示の間を切り替えることができる。表示は、同一情報の異なる表現であり得る。

図２（ｃ）に示すようなスレッド及びサブスレッドのインタフェースを含む実装例においては、スレッド及びサブスレッドのインタフェースはチャットを厳密にタイムラインベースのパラダイム（paradigm）に分解し、チャットウィンドウ内にサブスレッドを示す。サブスレッドへの返事又は回答はサブスレッドの末尾にある「＋」を選択して追加可能であり、これはチャット全体の末尾ではなく対象となるサブスレッドの末尾にエントリを追加させるようにする。このパラダイムを使用すると、新規メッセージは必ずしもある時点以降の未読としてマークされているチャット全体の末尾に表示されるわけではない。メッセージはチャット全体の全スレッド中に広がる可能性がある。そのような実装では更に、チャットのどこかに新規エントリがあり得るというユーザへのヒントの表示を利用してもよい。そのようなヒントの例としては、トップバー内の警告サイン（例えばユーザの注意を促すボタン）があり、これはチャット全体の中にいくつの新エントリがあるかを示すとともに、ユーザが１つの新規エントリから別の新規エントリへチャット中をジャンプするのに利用可能なボタンとしても機能し得る。スレッド及びサブスレッドのインタフェースの実装例を図２（ｃ）に示す。図２（ａ）の概要画面では、質問の横にその質問に関する新エントリの数が示されている。実装例では、質問を選択すると、チャット内のサブスレッドの最後の未読メッセージにジャンプする。

実施例では、カラービューがチャットのタイムラインベースのパラダイムを維持し、サブスレッドが異なるエントリを違う色でマークする。サブスレッドへの返事又は回答は、質問の横の「＋」をクリックして、質問と同じ色でマークされるエントリを追加できる。このパラダイムを使用すると、新規メッセージはある時点以降の未読としてマークされるチャット全体の末尾に表示される。ただし、質問はチャットのどこかへ広がっている可能性がある。このため、実装例には１つの質問から別の質問へユーザにチャット中をジャンプさせるボタンが含まれ得る。実装例では、サブスレッドの最後の回答上にジェスチャ（例えば長押し）を用いて、図２（ｄ）に示すように１つのサブスレッドの一部として新エントリをマークすることも可能である。図２（ｄ）に示すように、関連するメッセージは色でコード化され、プラス記号又は他の所望のユーザインタフェースインジケータに入力すると、デバイスは同じ色のメッセージをスキャンし、同じ色を有する次のメッセージをタイムスタンプに基づいて表示又はハイライトする。概要画面には、質問の横にその質問に関する新エントリの数が示される。質問を選択すると、チャット内のその質問に対する第１の未読回答へジャンプする。

２画面ビューの実装例では、ビューをスレッドとサブスレッドインタフェースと同じようにして実装できる。更に２つの画面ビューがサブスレッドの開始をアイコンでマークしてチャットのタイムラインベースパラダイムを保持するようする。サブスレッドへの返事又は回答は、サブスレッドをタップして、まさにそのサブスレッドとそのフォローアップメッセージを示す新しい画面にユーザを導くことによって読むことが可能である。このパラダイムを使用すると、このサブスレッドに対する新規のフォローアプップメッセージを、最初に特別のボタンを選択することなく、代わりに図２（ｅ）に示すように画面の下にテキスト入力を打ち込むだけで、サブスクリーン上に通常のメッセージとして入力可能である。概要画面には、質問の横にその質問に関する新エントリの数が示される。質問を選択すると、サブスレッドのビューへジャンプする。図２（ｅ）に示すように、スレッドに対するサブスレッドを表すための分離画面が生成される。更に、分離画面内に同一インタフェースを与えることが可能であって、それにより、サブスレッド内にサブスレッドを実装すること及びサブスレッド内のサブスレッドに対する分離画面を生成することを、所望の実装に従って容易とする。

実装例において、チャットアプリケーションに追加し得るドキュメント生成器がある。上記の新規導入機能は、以前の線形チャットに更なるレベルのアノテーションを追加する。要素をマーキングするやり方の違いが重要さのヒントを与える。ただし、より長いチャット等のメッセージのやり取りからでは、後から情報を見つけることは難しくなり得る。ここでは、要素にマーキングするばかりではなく、そのチャットからナレッジを含む意味上で関連する要素の組を抽出し、それをやり方指示、ＦＡＱ、又はレポートなどのようなより読みやすい形に変換することを支援できる。要素はユーザの選択に基づいて選択されるか、作成されるドキュメントに応じてアノテーション（例えば、要素の種類、ユーザが時間経過とともに与えるスター印／マーカ）によって事前選択可能である。以下では、実装例がチャットアプリケーションからのマルチメディアドキュメントの作成を容易にする。

実装例では、マルチメディアドキュメントはユーザ誘導型であってよい。ユーザ誘導型の作成では、インタフェースは制作者の数ステップの遂行を容易にする。第１に、チャット要素がインタフェースを介して選択される。このプロセスはユーザが１つのチャットエントリをクリックして開始される。次に選択ツールがそのアプリケーション内の後続の要素のリストを提供する。その後、ユーザは、各要素についてそれをドキュメントに追加すべきかどうかを選択できる。そして、選択された要素が編集領域にコピーされて、そこで再配置、編集、及び以前又は後続の要素とマージすることができる。必要であれば新要素をローカルファイルシステムやインターネットから付け加えることが可能であり、フォーマット化が適用可能である。最後に、ドキュメントは所望のフォーマットにしてエクスポート可能である。

実装例において、マルチメディアドキュメントが半自動プロセスによって生成可能である。半自動作成においては、ユーザがチャット内の選択開始箇所を選択した後、幾つかのアルゴリズムが適用される。基本的なテキスト解析並びにアノテーション（例えば、好き、マーカ）の解析は関連するエントリを示唆する。それはユーザにより変更されることもあり得る。コピープロセスにおいて、テキストの不要部分（例えば、顔文字、不要なスペース）が削除され、ユーザが連続した小さなメッセージとして投稿した要素が１つのテキストにマージされる。得られた要素のリストは次に、ユーザ誘導プロセスで記述されるように編集可能である。ここで、ユーザは、インターネットから映像シーン、画像、あるいは他の材料を提供する、検索及び調査アルゴリズムの支援を受ける。

実装例において、マルチメディアドキュメントが自動プロセスによって生成可能である。自動作成もまた、ユーザ誘導及び半自動モードから学習し、機械学習アルゴリズムなどの学習アルゴリズムを使用して所望のドキュメントフォーマットを自動的にエクスポートするように構成可能である。

リニアマルチメディアドキュメントに加えて、ハイパーメディアグラフもドキュメント作成インタフェースを使用して作成可能である。ハイパーメディアグラフには、グラフ内のフォークに適用されるロジックステートメントのためのグラフビューとエディタが必要である。そのような実装例では、異なるユーザグループに対して異なるレベルの詳細、難易度、又は命令を提供可能な、ハイパーメディアドキュメントを特にモバイルデバイス上に作成できる。モバイルインタフェースはドキュメントの概要を提供し、既存のドキュメントのインタラクティブ要素を提供する。ここでこのドキュメントを拡張してモバイルデバイス上で可能なハイパーメディア作成を行うことが可能である。ＡＰＰに情報を記録することにより多くの情報を提供するためにより詳細な情報並びに異なる種類のメディア要素を追加することが可能である。

ドキュメント生成時のより複雑なサブプロセスは、後続エントリの選択、テキストクリーニング、及びエントリのリオーダリングである。これらの構成要素は、トピック検出と追跡の関連技術の実装上に構築されて、チャットメッセージの初期トピッククラスタリングを導出し、その結果として検出したトピックを追跡することが可能である。そのような手法は、ニュースストリームやｅメール編成にも適用されてきた。キーフレーズ抽出や会話力学解析などの手法もまた、重要度の低い投稿のフィルタリングや、生成されたドキュメントの構造化に役立てることができる。

実装例では、マルチメディアドキュメントビューアがすべての種類のメディアとナビゲーション要素とを表示する機能を提供する。ビューアは、ハイパーメディアグラフをフィルタリングすることにより、再生デバイス及びユーザ特性に適応できる。再生デバイスに応じて、メディア要素のサイズとともにデータ量が調整可能である。実装例では、接続の遅いものはテキスト及び画像に集中することがある。その一方で（異なるタイプのメディアを使用可能な場合には）映像は高いバンド幅を利用して表示される。更に、レポート生成器には、得られるドキュメントをユーザの入力と目的に従って適応させるフィルタ機能を提供可能である。

更に、情報に欠落があるか又は意図通りに提示されていない場合には、ユーザに閲覧中のドキュメントを拡張させて、受動閲覧者を共同制作者とすることができる機能が入手可能である。そのような機能は異なるモードで動作可能である。

非制御モードの実装例では、コンテンツは承認プロセスなしでユーザによって編集可能である。

制作者制御モードの実装例では、ユーザがコンテンツを追加／編集する場合には、マルチメディア／ハイパーメディアの制作者に通知が送信される。制作者が同意する場合には、制作者は変更を容認できる。制作者が同意しない場合には、そのコンテンツは拒否されるか、議論を開始できる。

ユーザ制御モードの実装例では、ユーザがコンテンツを追加／編集する場合には、新コンテンツが未検証としてマークされる。そうして他のユーザは、そのコンテンツをピアレビュー（peer review）し、コンテンツを変更し、そしてそのコンテンツがドキュメントへの「正規」のコンテンツとして容認可能かどうかを票決することができる。こうすることで、新情報の良品質とドキュメントの不断の改善が保証される。

図３は、実装例による、全体フロー図である。実装例において、システムは３つのサブプロセス（コンテンツ収集、ハイパーメディアドキュメント生成、ハイパーメディア準備）に分割可能である。これを図３に示すように以下で詳細に説明する。

３０１において、システムは、図２（ａ）～図２（ｅ）で説明したような、拡張チャットアプリケーションからコンテンツを収集するように構成されている。そのようなコンテンツには、チャットアプリケーションを介して投稿されたテキスト、画像、映像、音声、又はファイルが含まれ得る。３０２において、コンテンツを収集後、ハイパーメディアドキュメントをコンテンツから生成することができる。３０３において、ハイパーメディアドキュメントがユーザへの表示インタフェースに提供される。更に詳細なフローは図４に示されている。

図４は、実装例による、データフローを示す。具体的には、図４に拡張チャットアプリケーション４０１と、ドキュメント生成器４０２と、ドキュメントビューア／レポート４０３の間のデータフローが示されている。拡張チャットアプリケーション４０１において、ユーザが４１０においてメッセージを送信する。これは４１１の拡張チャットＵＩに送信される。メッセージがテキストのみの場合、テキストはデータベースに追加されて、エントリとの間の接続が４１２で更新される。メッセージがメディアファイルの場合には、メディアファイルは４１３でサーバ上に格納され、データベースにリンクが追加される。そうしてエントリとの間の接続が更新される。そうして全ユーザに対してチャットが更新される。

ドキュメント生成器４０２において、４２０でドキュメントを作成するユーザは、４２１でエントリセレクタを開いて開始エントリを選択し、ついで４２２でハイパーメディアドキュメントエディタ４２２に案内される。ハイパーメディアドキュメントエディタではインタフェースが備えられてコンテンツが編集可能であり、４２３に図示するようにインターネットからのコンテンツを追加可能である。コンテンツはハイパーメディアドキュメントに一緒にリンクされる。チャットに関しては、メディアファイルがファイルサーバに格納され、テキストと構造がデータベースに格納される。ユーザはドキュメントを選択し、更なる入力を追加できる。そうしてインタラクティブなハイパーメディアドキュメントが作成され、ビューアに表示されるか又はコンテンツがドキュメントファイル（例えばＰＤＦ、ＤＯＣ）としてエクスポートされる。

ドキュメントビューア／レポート４０３では、４３０でドキュメントを閲覧するユーザがハイパーメディアドキュメントビューア４３１を開く。これは４３２でインタラクティブハイパーメディアドキュメントを表示する。インタラクティブハイパーメディアドキュメント４３２はハイパーメディアドキュメントアセンブラ４３３で作成される。これはユーザがドキュメントを構築するようにハイパーメディアドキュメントビューア４３１に命令した後、ユーザのためのドキュメントファイルを４３４で生成するようにも構成されている。

図５は、実装例によるコンテンツ収集のフローを示す図である。具体的に、図５はコンテンツ収集（例えばチャットアプリケーション）時のプロセスを示す。チャット／サブチャットの選択が５０１においてユーザを介してインタフェース上で受信される。５０２においてシステムはコンテンツの追加を継続する。このフローの間、システムは拡張チャットアプリケーションを介してタイプされたテキスト又はメディアを受信してもよい。５０３において、要素が図２（ｂ）のインタフェースに示したようにマークされてよい。図２（ｂ）に示すように、要素は、質問／議論、ＴｏＤｏ、メモ、リマインダ、イベント、今後へのメッセージ、等としてマークすることができる。特に要素がマークされない場合（Ｎｏ）、フローは５０４に進み、コンテンツ生成が終了したかどうかが判定される。マークされる場合（Ｙｅｓ）、流れは終了し、そうでない場合（Ｎｏ）にはフローは５０２に進んで、追加のコンテンツが処理される。

５０５で、チェックを行い、マークされた要素が質問又は議論の開始指示であるかどうかを判定する。そうである場合（Ｙｅｓ）、フローは５０６に進んで、要素を質問又は議論の開始としてマークし、次に５０７に進んで可視性の設定をする。５０７では、特定の要素の可視性の設定を容易にするインタフェースを提供することができる。実装例では、単一ユーザ、グループの一部、グループ全体、の３つの可視性の設定があり得る。単一ユーザ又はグループの一部が選択された場合、グループの対応するサブセットが選択される。

そうでない場合（Ｎｏ）、フローは５０８に進み、チェックを行って特定の要素がＴｏＤｏ要素かどうかを判定する。そうである場合（Ｙｅｓ）、フローは５０９に進んで、要素をＴｏＤｏ要素としてマークする。そうしてフローは５１０に進んで最終期限が設定される。ここで、要素が継続的に有効であるか、又は要素が終了しなければならない日時の選択を容易にするインタフェースが提供される。提供されるインタフェースには、５１１でリマインダ設定を容易にするインタフェースも含むことが可能であり、そこでインタフェースは、リマインダをいつに設定すべきか、及び最終期限のどれだけ前にリマインダがチャットアプリケーションを開かなければならないか、ということの選択を容易にする。更に、インタフェースは５１２でのアクションの設定も容易にすることができる。これは、所望の実装に従った、写真の撮影、質問への回答、値の記入、受信者から映像又は何らかの他の種類のドキュメンテーションを取得すること、に対する要求であり得る。

そうでない場合（Ｎｏ）、フローは５１３に進み、チェックを行って特定の要素がメモ要素かどうかを判定する。そうである場合（Ｙｅｓ）、フローは５１４に進んで、要素をメモとしてマークする。フローは次に５１５に進み、インタフェースを介して有効性を設定する。ここでインタフェースが提供されて、要素がどれくらい有効で他のユーザに表示されているかを示す時間の長さの選択を容易にすることができる。

そうでない場合（Ｎｏ）、フローは５１６に進み、チェックを行って特定の要素がリマインダに指向されているかどうかを判定する。そうである場合（Ｙｅｓ）、フローは５１７に進んで、要素をリマインダとしてマークする。フローは次に５１８に進んで、リマインダの種類を決定する。リマインダが場所と時間をベースとするリマインダである（Ｙｅｓ）場合、フローは５２４に進んで、インタフェースを介して場所とその他のリマインダ情報を設定する。実装例では、場所は住所をタイプするか、地図上で場所をマークするかのいずれかによって入力可能である。

そうでない場合（Ｎｏ）、フローは５１９に進んで、特定の要素が時間ベースのリマインダであるかどうかを判定する。そうである場合（Ｙｅｓ）、フローは５２５に進んでインタフェースが提供され、開始日を設定し、５２６に進んで要素のための時間を設定する。そうでない場合（Ｎｏ）、フローは５２０に進んで、特定の要素が場所ベースのリマインダであるかどうかを判定する。そうである場合（Ｙｅｓ）、フローは５２１に進んで５２４でのフローと同様にして場所を設定する。そうでない場合（Ｎｏ）、フローは５０７に進んで、可視性を設定する。

５１６で特定の要素がリマインダでない場合（Ｎｏ）、フローは５２２に進み、そこで要素がイベントに指向されているかどうかに関する判定がなされる。そうである場合（Ｙｅｓ）、フローは５２３に進んで、その要素をイベントとしてマークする。フローは次に５２４に進んでイベントの場所を取得して設定し、所望の実装に従ってイベントの日付や時間等のその他の情報の取得と設定に進む。

特定の要素がイベントでない場合（Ｎｏ）、フローは５２７に進んで要素を今後へのメッセージとしてマークする。そして５２５に進んで、日付を設定し、５２６に進んで時間を設定する。

別の実装においては、拡張チャットアプリケーション内のコンテンツが図３の３０１に示すように収集された後、ハイパーメディアドキュメントが３０２で生成されて、３０３でドキュメントビューアに提供されてもよい。図６は、実装例による、ドキュメント生成のフロー図を示す。６０１において、ドキュメント生成を、ユーザ誘導生成プロセス（例えば手動）とするか、あるいは半自動プロセスとするかに関する判定がなされる。

ユーザ誘導ドキュメント生成プロセス（Ｙｅｓ）においては、６１３でチャット入力の選択を容易にするインタフェースが提供される。入力はインタフェースを介してそのそれぞれをマークすることで選択される。６１４でユーザの確認またはインタフェースを提供して、入力コンテンツが容認可能であるかどうかを判定することができる。そうでない場合（Ｎｏ）、フローは６１５に進み、そこでチャット入力の編集を容易にするインタフェースが提供される。そのようなインタフェースでは、入力は変更可能であって、例えばタイプミスや絵文字や望ましくないテキストを削除できる。テキストの追加または削除も可能である。

６１６でユーザの確認またはインタフェースが提供されて、エントリオーダーが容認可能であるかどうかを判定できる。そうでない場合（Ｎｏ）、フローは６１７に進み、所望のドキュメントに従って、チャット入力の順序の再配列を容易にするインタフェースが提供される。実装例では、エントリオーダーがチャットのタイムラインのために間違っているという状況もあり得る。必要があれば単一エントリもオーダー変更可能である。

６１８でユーザの確認またはインタフェースが提供されて追加コンテンツを付加すべきかどうかを判定できる。そうである場合（Ｙｅｓ）、フローは６１９に進み、そこで追加コンテンツを追加するためのインタフェースが提供される。情報が欠落している場合、又は制作者がチャット時に収集されたものよりも良いイラストを知っている場合には、所望の実証に従って、外部情報を追加可能である。

６２０でユーザの確認またはインタフェースが提供されて、ハイパー構造を追加すべきかどうかを判定できる。追加すべきである場合（Ｙｅｓ）、フローは６２１に進み、そこでハイパーリンクが追加可能である。実装例では、ハイパー構造はコンテンツの異なるバージョン又はドキュメントを介する異なるパスを提供するために追加することが可能である。

ドキュメント生成が半自動プロセスを介して行われる場合（Ｎｏ）、フローは６０２に進み、そこではチャットからの開始エントリの選択を容易にするためにインタフェースが提供される。自動モード又は半自動モードにおいて、１つの開始エントリが選択されると、それによって６０３において開始エントリに後続するエントリを選択することでコンテンツ生成が開始される。

６０４、６０８、６１２において、半自動生成プロセスが所望されるかどうかに関してそれ以前に設定した決定をチェックする。そうである場合（Ｙｅｓ）、幾つかのインタフェースが提供される。それには以下のものが含まれ得る。

６０５において選択補正用のインタフェースが提供可能であって、そこでは６０３での自動選択結果を、ユーザ誘導モードで使用したのと同じインタフェースで補正可能である。選択がＯＫの場合（ｙｅｓ）、フローは６０７に進んで、例えば６１５で説明したように自動的にテキストがクリーニングされる。そうでない場合（Ｎｏ）、フローは６０６に進んで、インタフェースを介したユーザからの指図に従って、エントリ選択が補正される。

６０９においてテキスト補正用のインタフェースが提供可能であり、そこでは自動テキストクリーニング結果を、ユーザ誘導モードで使用したのと同じインタフェースで補正可能である。テキストがＯＫの場合（ｙｅｓ）、フローは６１１に進んで、例えば６１７で説明したように自動的にエントリの再配列を行う。そうでない場合（Ｎｏ）、６１０に示すようにテキストのクリーニングプロセスが提供される。

次に６２２において、ドキュメント構造が、ドキュメントビューアによってドキュメントを取り出したデータベース４１２及びファイルストレージ４１３へエクスポートされる。自動生成が終了すると、あるいはユーザがユーザ誘導生成又は半自動生成を終了させると、ドキュメント構造はドキュメントコンテンツとともにビューアにエクスポートされる。

図７（ａ）～図７（ｃ）は、実装例によるチャットアプリケーション用のドキュメント生成インタフェースの例を示している。ユーザ誘導プロセス用のインタフェースでは、図７（ａ）に示すような、ユーザが作成しようとするドキュメンの種類（例えば、ハウツー、ＦＡＱ、レポートなど）をまずユーザに定義させる画面が提供される。次いで、ドキュメントに応じて、構造要素を所望の実装に従ったテンプレートに提供可能である。例えば、ステップとサブステップ要素は、図７（ｂ）に示すようにハウツー指示のテンプレートの一部であり、質問要素はＦＡＱ用のテンプレートの一部であり、タイトル、関係者、導入／目的、時間スパン、進捗などの要素はレポート用テンプレートの一部である。ステップは、ユーザがタイプインしてもよいし、既存要素から選択してもよい。チャット入力からのコンテンツ、ｔｏｄｏメモ、メモ、あるいはチャットメッセージからのその他の特別な要素は、図７（ｂ）に示すようにテンプレートに充当するために使用可能である。手動モードでは、ユーザはこれらの入力を図７（ｃ）に示すような選択画面で選択する。コンテンツを追加した後、コンテンツを再編成及び編集することができる。完成したドキュメントは、この過程でハイパーメディアドキュメントを作成する他のバージョンを用いて拡張可能である。

図８は、実装例による、ドキュメント準備及び生成のフロー図である。８０１において、ドキュメント選択を容易にするインタフェースが提供される。例えば、ユーザは概要タブでドキュメントを選択可能である。８０２において、出力デバイスがプリンタであるかどうかの判定がなされる。そうである場合（Ｙｅｓ）、フローは８０３に進み、そこでドキュメントがマルチメディアドキュメントから生成される。実装例において、各映像に対してキーフレームが抽出されてドキュメントに追加される。各音声に対してテキストが抽出されてドキュメントに追加される。８０４において、ドキュメントは印刷される。プリンタが使用できない場合にはローカルデバイスにダウンロードされる。

出力デバイスがプリンタではない場合（Ｎｏ）、他のバージョンのドキュメントが利用可能かどうかが８０５で判定される。そうである場合（Ｙｅｓ）、８０６で入力変数を取得するためにインタフェースが提供される。実装例では、ドキュメントのカスタマイズ用インタフェースの入力変数としては、画面分解能、利用可能バンド幅、デバイス言語、ユーザナレッジ、ユーザの性別、所望のインタラクティブ性レベル（例えば、低／高）、他ユーザが同一ドキュメントから取ったパス、所望実装に依存するその他のもの、を含むことができる。入力変数の幾つかはデバイスから自動的に決定され、あるものはユーザに関するナレッジに基づき、またあるものはユーザ入力（例えば使用開始時に）を必要とする場合がある。フローは８０７に進んで、入力変数に基づいてドキュメントがカスタマイズされる。コンテンツは適応されて、ハイパーメディアドキュメント内のパスが事前選択され得る。

８０８では、ドキュメントがビューアにロードされ、ユーザはドキュメントを監視又は拡張可能である。拡張プロセスは、制御不可、又は制作者が制御、又はユーザが制御、のいずれかであってよい。

実装例においては、コンテンツ収集とチャットアプリケーションがあり得る。実装例は、非常に多種類の機能を提供する幾つかのツールの接続と同期を容易にする。チャット内の検索の他に、アプリケーション内にインデックス付けされて一旦保存された共有ファイルを検索することも可能である。メッセージをマークして今後のリマインダとすることも可能である。これにより実装例では、チャットビューから直接的にチャットを構造化し、又はチャット要素を重要要素としてマークする事が可能となる。

図９は、実装例での使用に好適な例示的コンピュータデバイスを有する、例示的コンピューティング環境を示す。コンピューティング環境９００内のコンピュータデバイス９０５は、一つ又は複数の処理ユニット、コア、プロセッサ９１０、メモリ９１５（例えばＲＡＭ、ＲＯＭ、及び／又はそれに類似のもの）、内部ストレージ９２０（例えば、磁気ストレージ、光学ストレージ、ソリッドステートストレージ、及び／又は有機ストレージ）、及び／又はＩ／Ｏインタフェース９２５などを含むことが可能であり、それらの任意のものは情報通信のための通信機構又はバス９３０に連結可能であり、あるいはコンピュータデバイス９０５に埋設可能である。

コンピュータデバイス９０５は、入力／ユーザインタフェース９３５、及び出力デバイス／インタフェース９４０に、通信可能に連結できる。入力／ユーザインタフェース９３５と出力デバイス／インタフェース９４０のいずれか１つ又は両方が有線または無線のインタフェースであって、取り外し可能であってよい。入力／ユーザインタフェース９３５は、物理的または仮想的であって、入力を提供するために使用可能な任意のデバイス、コンポーネント、センサ、又はインタフェース（例えば、ボタン、タッチスクリーンインタフェース、キーボード、ポインティング／カーソル制御器、マイクロフォン、カメラ、点字器、モーションセンサ、光学リーダ、等）を含み得る。出力デバイス／インタフェース９４０は、ディスプレイ、テレビ、モニタ、プリンタ、スピーカ、点字器、等を含み得る。いくつかの実装例では、入力／ユーザインタフェース９３５と出力デバイス／インタフェース９４０はコンピュータデバイス９０５に埋設されていてもよいし物理的に連結されていてもよい。別の実装例では、他のコンピュータデバイスが、コンピュータデバイス９０５のための入力／ユーザインタフェース９３５と出力デバイス／インタフェース９４０として機能するか、あるいはその機能を提供してもよい。タッチスクリーンディスプレイ、テレビジョンディスプレイ、又はその他の任意の形態のディスプレイを含む実装例では、ディスプレイが、例えば図２（ａ）～図２（ｅ）及び図７（ａ）～図７（ｃ）に示すようなユーザインタフェースを提供するように構成される。

コンピュータデバイス９０５の例としては、これに限るものではないが、高度なモバイルデバイス（例えば、スマートフォン、車両及びその他の機械に搭載のデバイス、ヒト又は動物が携行するデバイスなど）、モバイルデバイス（例えば、タブレット、ノートブックコンピュータ、ラップトップコンピュータ、パーソナルコンピュータ、携帯テレビ、携帯ラジオなど）、及び可動用ではないデバイス（例えば、デスクトップコンピュータ、その他のコンピュータ、情報キオスク、内部に埋設及び／又は連結された一つ又は複数のプロセッサを有するテレビ、ラジオ、など）が含まれ得る。

コンピュータデバイス９０５は、外部ストレージ９４５とネットワーク９５０に（例えばＩ／Ｏインタフェース９２５を介して）通信可能に接続されて、同じ構成又は異なる構成の一つ又は複数のコンピュータデバイスを含む、任意の数のネットワーク接続されたコンポーネント、デバイス、及びシステムと通信できるようになっていてもよい。コンピュータデバイス９０５又は任意の接続されたコンピュータデバイスは、サーバ、クライアント、シンサーバ、汎用機械、専用用途機械、あるいは別のラベルとして、機能するか、そのサービスを提供するか、又はそれらとして称することが可能である。

Ｉ／Ｏインタフェース９２５には、コンピューティング環境９００にある少なくともすべての接続コンポーネント、デバイス、及びネットワークに向けて、及び／又はそこから、情報を通信するための、任意の通信又はＩ／Ｏプロトコルまたは標準（例えば、イーサネット（登録商標）、８０２．１１ｘ、ユニバーサルシステムバス、ＷｉＭａｘ、モデム、セルラーネットワークプロトコル、等）を利用する有線及び／又は無線インタフェースが含まれる。ただしこれに限るものではない。ネットワーク９５０は、任意のネットワーク又はネットワークの組合せ（例えば、インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク、電話ネットワーク、セルラーネットワーク、衛星ネットワーク、等）であってよい。

コンピュータデバイス９０５は、一時媒体及び非一時媒体を含む、コンピュータ使用可能媒体またはコンピュータ可読媒体を利用して、使用及び／又は通信が可能である。一時媒体には、伝送媒体、（例えば金属ケーブル、ファイバ光学材料）、信号、搬送波などが含まれる。非一時媒体には、磁気媒体（例えばディスク及びテープ）、光学媒体（例えばＣＤ ＲＯＭ、デジタルビデオディスク、ブルーレイディスク）、固体素子媒体（例えば、ＲＡＭ、ＲＯＭ、フラッシュメモリ、ソリッドステートストレージ）、及びその他の不揮発性ストレージ又はメモリが含まれる。

コンピュータデバイス９０５は、いくつかの例示的コンピューティング環境において技術、方法、アプリケーション、プロセス、又はコンピュータ実行可能命令の実装に使用可能である。コンピュータ実行可能命令は一時媒体から取出して、非一時媒体に格納して取出すことが可能である。実行可能命令は、任意のプログラミング言語、スクリプティング言語、及び機械言語（例えば、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（登録商標）、Ｖｉｓｕａｌ Ｂａｓｉｃ、Ｐｙｔｈｏｎ、Ｐｅｒｌ、ＪａｖａＳｃｒｉｐｔ（登録商標）、他）の内の一つ又は複数から生じることができる。

メモリ９１５は、例えば図１、図３～図６、図８におけるフローに記載されたような、プロセッサ９１０によって実行されるアルゴリズムを格納又は管理するように構成され得る。本明細書に記載の実装例は、所望の実装に従って、単独又は相互に任意の組合せで実行され得るものであり、特定の実装例には限定されない。

プロセッサ９１０は、ネイティブ環境又は仮想環境において任意のオペレーティングシステム（ＯＳ）（図示せず）の下で実行可能である。論理ユニット９６０、アプリケーションプログラミングインタフェース（ＡＰＩ）ユニット９６５、入力ユニット９７０、出力ユニット９７５、及び異なるユニットが相互に、またＯＳと、そして他のアプリケーション（図示せず）と通信するためのユニット間通信機構９９５、を含む、一つ又は複数のアプリケーションを展開可能である。上記のユニット及び要素は、設計、機能、構成、又は実装において変形可能であり、ここでの記述に限定されるものではない。プロセッサ９１０は、メモリ９１５からロードされた命令を実行するように構成された、物理プロセッサ又は中央処理ユニット（ＣＰＵ）であってもよい。

いくつかの実装例において、情報または実行命令がＡＰＩユニット９６５で受信されると、それは一つ又は複数の他のユニット（例えば論理ユニット９６０、入力ユニット９７０、出力ユニット９７５）へ通信され得る。いくつかの例では、論理ユニット９６０は、ユニット間の情報の流れを制御し、上記のいくつかの実装例におけるＡＰＩユニット９６５、入力ユニット９７０、出力ユニット９７５により提供される業務を指揮するように構成され得る。例えば、一つ又は複数のプロセス又は実装のフローは、論理ユニット９６０だけで制御されてもよいし、ＡＰＩユニット９６５と連携して制御されてもよい。入力ユニット９７０は実装例に記載の計算のための入力を取得するように構成され、出力ユニット９７５は実装例に記載の計算に基づく出力を提供するように構成されてもよい。

実装例において、プロセッサ９１０は、モバイルデバイスから送信された第１のメッセージをユーザインタフェース上に表示するように構成されてもよい。図２（ａ）に示す実装例において、２０１でモバイルデバイスから他のデバイスに送信されたメッセージ２０１はディスプレイに配置され、プロセッサ９１０は、モバイルデバイスから送信された第１のメッセージに応答する他のモバイルデバイスからの一つ又は複数の第２のメッセージを監視する。他のモバイルデバイスから第２のメッセージを受信すると、プロセッサ９１０は、ユーザインタフェースに表示されている第１のメッセージ上にユーザインタフェースインジケータを生成して、第１のメッセージと第２のメッセージとの間の関係インタフェースをユーザインタフェース上に提供するように構成されている。ユーザインタフェースインジケータは、図２（ｃ）に示すようなスレッド及びサブスレッドのインタフェースと、図２（ｄ）に示すようなカラーコード化された関係インタフェースと、図２（ｅ）に示すような別画面の生成との内の１つとして、この関係インタフェースを提供するように構成することができる。図２（ｃ）から図２（ｅ）に示すように、そのようなインジケータは所望の実装に依存して、プラス記号、矢印、Ｑ記号、等の形態をとり得る。

図２（ｃ）の例において、ユーザインタフェースインジケータが、関係インタフェースをスレッド及びサブスレッドのインタフェースとして提供するように構成されている場合、プロセッサ９１０は、第１のメッセージをスレッドの開始として表示することと、ユーザインタフェースインジケータをスレッドの拡張指示として（例えば、Ｑ記号、プラス記号などの形態で）提供することと、そしてユーザインタフェースインジケータ上に入力を受信すると、図２（ｃ）に示す第１のメッセージへの応答によって図示されるように、第２のメッセージをスレッドの拡張を経てサブスレッドとしてユーザインタフェース上に表示することとによってユーザインタフェースインジケータを生成するように構成されている。更に、この実装例は、図２（ａ）の複数の送信メッセージの例に示されるように、複数のメッセージに拡張可能である。ここで送信メッセージに関係する複数のメッセージは、図２（ｃ）に示すようにスレッドの拡張を経てサブスレッドとしてユーザインタフェース上に表示可能である。

図２（ｄ）の例において、ユーザインタフェースインジケータが関係インタフェースをカラーコード化された関係インタフェースとして提供するように構成されている場合には、プロセッサ９１０は、第１のメッセージを第１の色として表示することと、ユーザインタフェースインジケータを、第１の色を有する次のメッセージへの移動指示として提供することと、そしてユーザインタフェースインジケータ上に入力を受信すると、第２のメッセージを次のメッセージとして第１の色で表示することとによってユーザインタフェースインジケータを生成するように構成されている。第１の色とは異なる第２の色で表示されるメッセージは、第１のメッセージとは異なる関係にあるとして認識される。

図２（ｅ）の例において、ユーザインタフェースインジケータが関係インタフェースを分離画面として提供するように構成されている場合には、プロセッサ９１０は、分離画面の生成として関係インタフェースを提供することによってユーザインタフェースインジケータを生成するように構成されている。プロセッサ９１０は、第１のメッセージを第１のディスプレイ画面に表示することと、ユーザインタフェースインジケータを、第２の画面への変更指示（例えば矢印）として提供することと、そしてユーザインタフェースインジケータに入力を受信すると、第１のディスプレイ画面を第２のディスプレイ画面に変更して、図２（ｅ）の右側に示すように第２のメッセージを第２のディスプレイ画面上に表示することとによって、ユーザインタフェースインジケータを生成するように構成されている。

実装例において、第１のメッセージは場所ベースのリマインダの形態であってもよい。これは他のモバイルデバイスが場所ベースのリマインダに係わる場所に到達したときに、その別のモバイルデバイスに送信されるように構成されている。実装例では、メッセージはその別のモバイルデバイスに送信可能であるが、その別のモバイルデバイスが第１のメッセージで示された場所に、指定の時間にいることを検出するまでは別のモバイルデバイス上には表示されない。実装例では、メッセージは所望の実装に依存して、時間リマインダベースのみ又は場所リマインダベースのみのいずれかであってもよい。

実装例では、第１のメッセージは完了すべきタスクを要求できる。そして第２のメッセージは、その完了すべきタスクに対応する、テキスト、映像、及び画像の少なくとも１つを含むことができる。すなわち、モバイルデバイスのユーザはタスクを処理するために画像又は映像が必要であることを示すことができ、画像又は映像を受信するとユーザはタスクが満たされたかどうかを確認することが可能である。ユーザがタスクは満たされたと決定すると、ユーザは確認インタフェース（例えば返信メッセージ、タスク完了を示すユーザインタフェースなど）によって別のモバイルデバイスからそのメッセージを消去することができる。

実装例では、プロセッサ９１０は、図７（ａ）～図７（ｃ）に示すように第１のメッセージと第２のメッセージに基づくドキュメントを生成するインタフェースからなる、第２のユーザインタフェースインジケータを提供するように構成可能である。第２のユーザインタフェースインジケータに入力を受信すると、プロセッサ９１０は、図７（ａ）～図７（ｃ）に示すようにドキュメントエディタ上で第１のメッセージと第２のメッセージの選択処理をして、図８のフローで説明したようにドキュメントエディタで処理された、選択された第１のメッセージと第２のメッセージに対するドキュメントを生成するように構成されている。例えば、図４と図８で説明したように、プロセッサ９１０は、第２のメッセージに関連する一つ又は複数の画像を取り出し、（例えばインターネット又はメッセージサーバから画像または映像のキーフレームをダウンロードすることから）その画像をドキュメント中に組み込むことによって、選択された第１のメッセージと第２のメッセージに対するドキュメント生成するように構成されている。実装例では、プロセッサ９１０は、第２のメッセージに関連する一つ又は複数の映像を取り出し、一つ又は複数の映像から一つ又は複数のキーフレーム画像を抽出し、その一つ又は複数のキーフレーム画像をドキュメント中に組み込むことによって、選択された第１のメッセージと第２のメッセージに対するドキュメントを生成するように構成されている。キーフレーム画像の抽出は、当分野で周知の、任意の所望の実装に従って行うことができる。更に、プロセッサ９１０は、図８に示すようにプリンタ上でドキュメントを印刷することによってドキュメントを生成するように構成できる。

詳細な説明のいくつかの部分は、コンピュータ内操作のアルゴリズム及び記号表示で表されている。これらのアルゴリズム記述及び記号表示は、データ処理分野における当業者がその革新の要点を他の当業者に伝達するために使用する手段である。アルゴリズムは所望の最終状態又は結果を導く、一連の画定されたステップである。実装例においては、実行されるステップは、確実な結果を達成するための有形量の物理的操作を必要とする。

特に別段の記述がない限り、議論から明らかなように本説明全体を通して、「処理する」、「計算する」、「算出する」、「決定する」、「表示する」などの用語を用いた議論には、コンピュータシステムのレジスタ及びメモリ内で物理的（電子的）量として表されたデータを、コンピュータシステムのメモリ又はレジスタ又はその他の情報の格納、送信、又は表示デバイス内に物理量として同様に表される他のデータに操作及び変換する、コンピュータシステムや他の情報処理デバイスの動作及び処理を含み得ることを理解されたい。

実装例は本明細書に記載の操作を遂行するための装置にも関係し得る。この装置は、所要目的のために特別に構築されたものであってもよいし、コンピュータプログラムによって選択的に起動又は再構成された、一つ又は複数の汎用コンピュータを含んでもよい。そのようなコンピュータプログラムは、コンピュータ可読記憶媒体又はコンピュータ可読信号媒体などの、コンピュータ可読媒体に格納され得る。コンピュータ可読記憶媒体には、これに限るものではないが、光ディスク、磁気ディスク、読出し専用メモリ、ランダムアクセスメモリ、ソリッドステートデバイスおよびソリッドステートドライブなどのような有形媒体、又は電子情報の格納に好適な他の任意の種類の有形または非一時媒体が含まれ得る。コンピュータ可読信号媒体は、搬送波などの媒体を含み得る。本明細書に提示したアルゴリズム及び表示は、いかなる特定のコンピュータ又は他の装置に本質的に関わるものではない。コンピュータプログラムには、所望の実装操作を実行する命令を含む、純粋なソフトウェア実装が含まれ得る。

様々な汎用システムが本明細書に記載の実施例に従うプログラム（管理プログラム）及びモジュールと共に使用可能である。あるいは、所望の方法ステップを実行するためにより特殊化した装置を構築することが便利となる場合もあり得る。更に、実装例は特定のプログラム言語を参照して記述されたものではない。本明細書に記載の実装例の教示は、様々なプログラム言語を使用して実装され得ることを理解されたい。プログラム言語の命令は、例えば中央処理ユニット（ＣＰＵ）、プロセッサ、又はコントローラなどの、一つ又は複数の処理デバイスによって実行可能である。

当分野において周知のように、上記の操作は、ハードウェア、ソフトウェア、又はソフトウェアとハードウェアの何らかの組合せによって実行可能である。実装例の様々な態様は、回路と論理デバイス（ハードウェア）を用いて実装され得る。他方、他の態様は機械可読媒体（ソフトウェア）上に格納された命令を用いて実装し得る。これはプロセッサによって実行されると、本出願の実装を遂行する方法をプロセッサに実行させるであろう。更に、本出願のいくつかの実装例がハードウェアのみで実行され、他の実装例がソフトウェアのみで実行されることもあり得る。更には、説明した様々な機能は単一ユニットで実行されてもよいし、任意の数の方法で複数のコンポーネントに跨って実行されてもよい。ソフトウェアによって実行される場合、方法は、コンピュータ可読媒体上に格納された命令に基づいて、汎用コンピュータのようなプロセッサによって実行され得る。必要に応じて、命令は媒体上に圧縮フォーマット又は暗号化フォーマットで格納可能である。

更に、本出願の他の実装態様は、本明細書の考察及び本出願の教示の実行により当業者には明らかであろう。記載した実装例の様々な態様及び／又は構成要素は、単独、又は任意の組合せで使用され得る。明細書及び実装例は単なる例示として考慮されるものであって、本出願の真の範囲と精神は添付の特許請求の範囲に示されることが意図されている。

１０１ 拡張チャットアプリケーション
２０１ メッセージ
９０５ コンピュータデバイス
９１０ プロセッサ

Claims (9)

1. コンピュータを、
   第１のメッセージを第１のディスプレイ画面に表示する手段、
   ユーザインタフェースインジケータを、前記第１のメッセージへの応答である第２のメッセージを示す表示として、前記第１のディスプレイ画面上に生成する生成手段、
   前記第１のメッセージに対する入力を受け付けると、前記第１のディスプレイ画面を、前記第１のディスプレイ画面の分離画面である第２のディスプレイ画面に変更する変更手段、及び、
   前記第１のメッセージと前記第２のメッセージとを前記第２のディスプレイ画面に表示する表示手段、
   として機能させるためのプログラム。
2. 前記ユーザインジケータ上に入力を受信すると、前記第１のディスプレイ画面を前記第２のディスプレイ画面に変更する、請求項１に記載のプログラム。
3. 前記第２のディスプレイ画面には、メッセージとして、特定の前記第１のメッセージと、前記特定の前記第１のメッセージへの応答である前記第２のメッセージと、のみを表示する、請求項１又は請求項２に記載のプログラム。
4. 前記第２のディスプレイ画面でテキスト入力を可能とする、請求項１から請求項３までのいずれか１項に記載のプログラム。
5. 前記第１のディスプレイ画面と前記第２のディスプレイ画面とに対し同一のインタフェースを提供する、請求項１から請求項４までのいずれか１項に記載のプログラム。
6. 前記第１のディスプレイ画面には前記第２のメッセージが表示されない、請求項１から請求項５までのいずれか１項に記載にプログラム。
7. 前記第２のディスプレイ画面において、前記第２のメッセージは時間順に沿って表示される、請求項１から請求項６までのいずれか１項に記載にプログラム。
8. コンピュータでメッセージを管理するための方法であって、
   第１のメッセージを第１のディスプレイ画面に表示すること、
   ユーザインタフェースインジケータを、前記第１のメッセージへの応答である第２のメッセージを示す表示として、前記第１のディスプレイ画面上に生成すること、
   前記第１のメッセージに対する入力を受け付けると、前記第１のディスプレイ画面の分離画面である第２のディスプレイ画面に変更すること、及び、
   前記第１のメッセージと前記第２のメッセージとを前記第２のディスプレイ画面に表示すること、
   を含む、方法。
9. ユーザインタフェースを表示するように構成されたディスプレイと、
   プロセッサと、
   を備えるデバイスであって、前記プロセッサは、
   第１のメッセージを第１のディスプレイ画面に表示し、
   ユーザインタフェースインジケータを、前記第１のメッセージへの応答である第２のメッセージを示す表示として、前記第１のディスプレイ画面上に生成し、
   前記第１のメッセージに対する入力を受け付けると、前記第１のディスプレイ画面の分離画面である第２のディスプレイ画面に変更し、
   前記第１のメッセージと前記第２のメッセージとを前記第２のディスプレイ画面に表示する表示するように構成されている、
   デバイス。

Images