IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 富士ゼロックス株式会社の特許一覧

特開2024-105286デバイス上でのメッセージ管理とドキュメント生成のためのプログラム、方法、及びデバイス
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024105286
(43)【公開日】2024-08-06
(54)【発明の名称】デバイス上でのメッセージ管理とドキュメント生成のためのプログラム、方法、及びデバイス
(51)【国際特許分類】
   G06F 3/0481 20220101AFI20240730BHJP
   H04L 51/216 20220101ALI20240730BHJP
   H04L 51/04 20220101ALI20240730BHJP
【FI】
G06F3/0481
H04L51/216
H04L51/04
【審査請求】有
【請求項の数】7
【出願形態】OL
(21)【出願番号】P 2024066020
(22)【出願日】2024-04-16
(62)【分割の表示】P 2023121024の分割
【原出願日】2017-04-27
(31)【優先権主張番号】15/285,878
(32)【優先日】2016-10-05
(33)【優先権主張国・地域又は機関】US
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.VISUAL BASIC
2.PYTHON
(71)【出願人】
【識別番号】000005496
【氏名又は名称】富士フイルムビジネスイノベーション株式会社
(74)【代理人】
【識別番号】110001519
【氏名又は名称】弁理士法人太陽国際特許事務所
(72)【発明者】
【氏名】ブリッタ マイクスナー
(72)【発明者】
【氏名】スコット カーター
(72)【発明者】
【氏名】マシュー リー
(57)【要約】
【課題】第1のメッセージと第2のメッセージとの繋がりが分かるようにする。
【解決手段】本明細書に記載のシステムと方法は、個人が協働グループとのメッセージ相互作用から手続き上のナレッジを収集、格納、及び自動抽出することを容易にする実装を目的としている。実装例には、通信し、且つコンテンツを編成するためにテキスト及びメディアにタグ付け機能を付与する、チャットインタフェースに係わる。実装例はまた、以前の単なる線形的なタイムラインのチャットに、新しくスレッド様の構造を追加する。チャットからのナレッジは自動的に抽出されて高品質のマルチメディアドキュメントとすることができる。
【選択図】図2(d)
【特許請求の範囲】
【請求項1】
コンピュータを、
チャットのタイムラインに投稿された複数の第1のメッセージを、メッセージが投稿された時間順に第1のディスプレイ画面上に表示させる表示手段、
前記第1のメッセージのうちいずれかのメッセージに対する応答である第2のメッセージを受信する受信手段、
前記第2のメッセージを受信すると、前記第2のメッセージの存在を示すユーザインタフェースインジケータを、前記第2のメッセージを受信した前記第1のメッセージ毎に、前記第1のディスプレイ画面上に生成する生成手段、
前記ユーザインタフェースインジケータに対する指示を受け付けると、前記第1のディスプレイ画面を、前記第1のディスプレイ画面からの分離画面として提供される第2のディスプレイ画面に変更する変更手段、及び、
前記指示を受け付けた前記ユーザインタフェースに対応する第1のメッセージと、当該第1のメッセージへの応答である第2のメッセージとを前記第2のディスプレイ画面に表示させる表示手段、
として機能させるためのプログラム。
【請求項2】
前記第2のディスプレイ画面は、前記チャットに対するサブチャットを表す画面として提供される、
請求項1に記載のプログラム。
【請求項3】
コンピュータを、
複数の第1のメッセージを、第1のディスプレイ画面上に表示させる表示手段、
前記第1のメッセージのうちいずれかのメッセージに対する応答である第2のメッセージを受信する受信手段、
前記第2のメッセージを受信すると、前記第2のメッセージの存在を示すユーザインタフェースインジケータを、前記第2のメッセージを受信した前記第1のメッセージ毎に、前記第1のディスプレイ画面上に生成する生成手段、
前記ユーザインタフェースインジケータに対する指示を受け付けると、前記第1のディスプレイ画面を、前記第1のディスプレイ画面とは異なる画面である第2のディスプレイ画面に変更する変更手段、及び、
前記第2のディスプレイ画面において、メッセージとして、前記指示を受け付けた前記ユーザインタフェースに対応する第1のメッセージと、当該第1のメッセージへの応答である全ての前記第2のメッセージと、のみを前記第2のディスプレイ画面に表示させる表示手段、
として機能させるためのプログラム。
【請求項4】
前記第1のディスプレイ画面において、投稿後、ユーザによる操作を受け付けていない第1のメッセージに対応付けられた表示要素としては、当該第1のメッセージの投稿者を特定する情報および当該第1のメッセージの投稿日時に関する情報、以外は表示しない、
請求項1又は請求項3に記載のプログラム。
【請求項5】
投稿済みの前記第1のメッセージに対するユーザの操作によって、当該第1のメッセージを開始点とする、メッセージのグループを作成する、
請求項1又は請求項3に記載のプログラム。
【請求項6】
コンピュータでメッセージを管理するための方法であって、
チャットのタイムラインに投稿された複数の第1のメッセージを、メッセージが投稿された時間順に第1のディスプレイ画面上に表示させること、
前記第1のメッセージのうちいずれかのメッセージに対する応答である第2のメッセージを受信すること、
前記第2のメッセージを受信すると、前記第2のメッセージの存在を示すユーザインタフェースインジケータを、前記第2のメッセージを受信した前記第1のメッセージ毎に、前記第1のディスプレイ画面上に生成すること、
前記ユーザインタフェースインジケータに対する指示を受け付けると、前記第1のディスプレイ画面を、前記第1のディスプレイ画面からの分離画面として提供される第2のディスプレイ画面に変更すること、及び、
前記指示を受け付けた前記ユーザインタフェースに対応する第1のメッセージと、当該第1のメッセージへの応答である第2のメッセージとを前記第2のディスプレイ画面に表示させること、
を含む方法。
【請求項7】
ユーザインタフェースを表示するように構成されたディスプレイと、
プロセッサと、
を備えるデバイスであって、前記プロセッサは、
チャットのタイムラインに投稿された複数の第1のメッセージを、メッセージが投稿された時間順に第1のディスプレイ画面上に表示させ、
前記第1のメッセージのうちいずれかのメッセージに対する応答である第2のメッセージを受信し、
前記第2のメッセージを受信すると、前記第2のメッセージの存在を示すユーザインタフェースインジケータを、前記第2のメッセージを受信した前記第1のメッセージ毎に、前記第1のディスプレイ画面上に生成し、
前記ユーザインタフェースインジケータに対する指示を受け付けると、前記第1のディスプレイ画面を、前記第1のディスプレイ画面からの分離画面として提供される第2のディスプレイ画面に変更し、
前記指示を受け付けた前記ユーザインタフェースに対応する第1のメッセージと、当該第1のメッセージへの応答である第2のメッセージとを前記第2のディスプレイ画面に表示させる、
デバイス。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は一般的に通信プラットフォームとデバイスに関し、より具体的にはデバイス上でのメッセージドキュメント生成とメッセージ管理に関する。
【背景技術】
【0002】
関連技術において、チャットなどのメッセージングアプリケーションでは、会話タイムラインの簡単でよく理解されたインタラクションメタファ(interaction metaphor)を利用して、人々が多様なマルチメディアを共有することを可能にする。そのような関連技術のアプリケーションによって、小さなタスク志向のユーザグループが、職場及び個人生活の場の両面においてグループチャットで相互調整することを支援可能とする。ただし、既存のチャットなどのアプリケーションは通信及びコンテンツ共有のための機能は提供可能であるが、長い時間の間に生成され、共有されたコンテンツを簡潔且つ有用な方法で見つけることは困難なことがある。関連技術実装のユーザは、単一の単語を見つけることしかできず、質問に対する応答のような一連の繋がったコメント又は回答(これらは従来のチャットインタフェースではチャット全体に広がっている可能性がある)を見つけることはできない。
【0003】
関連技術の実装では、コンテンツを後で利用するため、又はアクセスを容易にするために編成することはできない場合がある。これができれば、共通のゴール又はプロジェクトを有する小さなタスク志向のグループにとって有用となり得る。
【0004】
更には、そのようなチャットなどのメッセージングアプリケーションを実装するデバイスの多くは、デバイス(例えばスマートフォン、タブレットなど)の大きさのために表示スペースが限られたディスプレイを使用しているので、そのような限定された表示スペースを考慮に入れたチャットメッセージを提供するインタフェースが必要とされている。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】米国特許第8558693号明細書
【特許文献2】米国特許第8219115号明細書
【特許文献3】米国特許第7583972号明細書
【非特許文献】
【0006】
【非特許文献1】ALLAN, J., ET AL.,著、「TAKING TOPIC DETECTION FROM EVALUATION TO PRACTICE」、PROCEEDINGS OF THE 38TH HAWAII INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES, 4(04), 2005, 10 PGS.
【非特許文献2】CSELLE G., ET AL.,著、「BUZZ TRACK: TOPIC DETECTION AND TRACKING IN EMAIL」,IUI’07, JANUARY 28-31, 2007, HONOLULU, HAWAII, 8 PGS.
【非特許文献3】CHUNG, J., ET AL.,著、「”WITHOUT THE CLUTTER OF UNIMPORTANT WORDS”: DESCRIPTIVE KEY PHRASES FOR TEXT VISUALIZATION」、ACM TRANSACTIONS ON COMPUTER-HUMAN INTERACTION, 19(3), ARTICLE 19, OCTOBER 2012, 29 PGS.
【非特許文献4】FONG, V.,著、「AN EDITABLE MULTI-MEDIA AUTHORING EBOOK SYSTEM FOR MOBILE Learning」、ICHL 2014, LNCS 8595, PP. 184-195, 2014
【非特許文献5】KIM J.,著、「TOOL SCAPE: ENHANCING THE LEARNING EXPERIENCE OF HOW-TO VIDEOS」、CHI 2013 EXTENDED ABSTRACTS, APRIL 27-MAY 2, 2013, PARIS, FRANCE, PP. 2707-2712
【非特許文献6】「THE 2004 TOPIC DETECTION AND TRACKING (TDT2004) TASK DEFINITION AND EVALUATION PLAN」、VERSION 1.0, OCTOBER 19, 2004, 16 PGS.
【非特許文献7】「PATENT MESS FOR LOCATION-BASED REMINDERS FOR AMAZON, APPLE, MICROSOFT AND GOOGLE」、NOVEMBER 22, 2011, 1 PG.
【非特許文献8】「OUR HOME」(2016年5月23日取得)9 PGS. URL:HTTP://OURHOMEAPP.COM/
【非特許文献9】「SLACK TECHNOLOGIES」(2016年5月17日取得)2 PGS. URL:HTTP://SLACK.COM/
【非特許文献10】「WIKI HOW」(2016年5月23日取得)3 PGS. URL:HTTP://WIKIHOW.COM/MAIN-PAGE
【発明の概要】
【発明が解決しようとする課題】
【0007】
本開示の技術は、第1のメッセージと第2のメッセージとの繋がりが分かるようにするメッセージの管理プログラム、モバイルデバイス上でメッセージを管理するための方法、及びモバイルデバイスを提供する。
【課題を解決するための手段】
【0008】
本開示の態様は、プログラムであって、コンピュータを、チャットのタイムラインに投稿された複数の第1のメッセージを、メッセージが投稿された時間順に第1のディスプレイ画面上に表示させる表示手段、前記第1のメッセージのうちいずれかのメッセージに対する応答である第2のメッセージを受信する受信手段、前記第2のメッセージを受信すると、前記第2のメッセージの存在を示すユーザインタフェースインジケータを、前記第2のメッセージを受信した前記第1のメッセージ毎に、前記第1のディスプレイ画面上に生成する生成手段、前記ユーザインタフェースインジケータに対する指示を受け付けると、前記第1のディスプレイ画面を、前記第1のディスプレイ画面からの分離画面として提供される第2のディスプレイ画面に変更する変更手段、及び、前記指示を受け付けた前記ユーザインタフェースに対応する第1のメッセージと、当該第1のメッセージへの応答である第2のメッセージとを前記第2のディスプレイ画面に表示させる表示手段、として機能させる。
【0009】
また、本開示の態様は、プログラムであって、コンピュータを、複数の第1のメッセージを、第1のディスプレイ画面上に表示させる表示手段、前記第1のメッセージのうちいずれかのメッセージに対する応答である第2のメッセージを受信する受信手段、前記第2のメッセージを受信すると、前記第2のメッセージの存在を示すユーザインタフェースインジケータを、前記第2のメッセージを受信した前記第1のメッセージ毎に、前記第1のディスプレイ画面上に生成する生成手段、前記ユーザインタフェースインジケータに対する指示を受け付けると、前記第1のディスプレイ画面を、前記第1のディスプレイ画面とは異なる画面である第2のディスプレイ画面に変更する変更手段、及び、前記第2のディスプレイ画面において、メッセージとして、前記指示を受け付けた前記ユーザインタフェースに対応する第1のメッセージと、当該第1のメッセージへの応答である全ての前記第2のメッセージと、のみを前記第2のディスプレイ画面に表示させる表示手段、として機能させる。
【0010】
本開示の態様は、コンピュータでメッセージを管理するための方法であって、チャットのタイムラインに投稿された複数の第1のメッセージを、メッセージが投稿された時間順に第1のディスプレイ画面上に表示させること、前記第1のメッセージのうちいずれかのメッセージに対する応答である第2のメッセージを受信すること、前記第2のメッセージを受信すると、前記第2のメッセージの存在を示すユーザインタフェースインジケータを、前記第2のメッセージを受信した前記第1のメッセージ毎に、前記第1のディスプレイ画面上に生成すること、前記ユーザインタフェースインジケータに対する指示を受け付けると、前記第1のディスプレイ画面を、前記第1のディスプレイ画面からの分離画面として提供される第2のディスプレイ画面に変更すること、及び、前記指示を受け付けた前記ユーザインタフェースに対応する第1のメッセージと、当該第1のメッセージへの応答である第2のメッセージとを前記第2のディスプレイ画面に表示させること、を含む。
【0011】
本開示の態様は更に、ユーザインタフェースを表示するように構成されたディスプレイと、プロセッサと、を備えるデバイスであって、前記プロセッサは、チャットのタイムラインに投稿された複数の第1のメッセージを、メッセージが投稿された時間順に第1のディスプレイ画面上に表示させ、前記第1のメッセージのうちいずれかのメッセージに対する応答である第2のメッセージを受信し、前記第2のメッセージを受信すると、前記第2のメッセージの存在を示すユーザインタフェースインジケータを、前記第2のメッセージを受信した前記第1のメッセージ毎に、前記第1のディスプレイ画面上に生成し、前記ユーザインタフェースインジケータに対する指示を受け付けると、前記第1のディスプレイ画面を、前記第1のディスプレイ画面からの分離画面として提供される第2のディスプレイ画面に変更し、前記指示を受け付けた前記ユーザインタフェースに対応する第1のメッセージと、当該第1のメッセージへの応答である第2のメッセージとを前記第2のディスプレイ画面に表示させる、ように構成されている。
【図面の簡単な説明】
【0012】
図1】実装例による、システムの概要を示す図である。
図2(a)】実装例による、拡張チャットアプリケーション(管理プログラム)を示す図である。
図2(b)】実装例による、拡張チャットアプリケーション(管理プログラム)を示す図である。
図2(c)】実装例による、拡張チャットアプリケーション(管理プログラム)を示す図である。
図2(d)】実装例による、拡張チャットアプリケーション(管理プログラム)を示す図である。
図2(e)】実装例による、拡張チャットアプリケーション(管理プログラム)を示す図である。
図3】実装例による、全体的なフロー図である。
図4】実装例による、データフロー図である。
図5】実装例による、コンテンツ収集の流れを示す図である。
図6】実装例による、ドキュメント生成のフロー図である。
図7(a)】実装例による、チャットアプリケーション用のドキュメント生成インタフェースの例を示す図である。
図7(b)】実装例による、チャットアプリケーション用のドキュメント生成インタフェースの例を示す図である。
図7(c)】実装例による、チャットアプリケーション用のドキュメント生成インタフェースの例を示す図である。
図8】実装例による、ドキュメント準備、組み立て、及び提示のフロー図である。
図9】実装例での使用に好適な例示的コンピュータデバイスを有する、例示的コンピューティング環境を示す図である。
【発明を実施するための形態】
【0013】
以下の詳細な説明において、本出願の図面及び実装例の更なる詳細を提供する。図面間で重複する要素の参照番号及び説明は、明確にするために省略する。明細書全体を通して使用する用語は例示として提供されるものであり、限定を意図するものではない。例えば、「自動的」という用語の使用は、本出願の実装の実行において当業者が所望する実装に応じて、ユーザ又は管理者が本実装の特定の態様を制御することを含む完全自動又は半自動の実装を含み得る。
【0014】
本明細書に記載の実装例は、モバイルデバイスなどのデバイスに対する、メッセージ管理及びドキュメント生成システムに関する。そのようなデバイスにおいては、たとえばチャットなどのようなメッセージは、過去のメッセージとは、受信により出現した時間以外には、体系化されていなかったり関係性がない、アドホック(ad-hoc)的な現れ方をし得る。そのようなメッセージのアドホック受信は、モバイルデバイスなどのような画面スペースの限られたデバイスでは特に問題となり得るものであって、ユーザはメッセージのコンテキストを判断するためにメッセージを繰り返しスクロールしなければならない。実装例では、メッセージ管理インタフェースが提供され、コンテキスト(たとえばトピックやグループなど)によってメッセージをグループ化し、また特定のメッセージコンテキストに関連する人へタスクやリマインダを割り当てる。実装例では更にそのようなグループ化されたメッセージを、メッセージ送受信の参加者間で共有可能なドキュメントに変換するシステムが提供される。
【0015】
本明細書で説明する実装例の恩恵を受けることができるグループの例としては、これに限らないが、家族(又は高齢者)の世話人、動物の共同世話人、他人の支援又は共通の業務やプロジェクトの調整をするグループ、又は配信チームのメンバがある。これらのグループには次のような共通の特性がある。すなわち問題を解決するということであって、特に問題の複数の部分が将来再発する可能性のある反復性のタスクである場合にそうである。グループが繰り返し対処しなければならない可能性のあるいくつかの問題がある。グループはそのトピックに関して議論して、将来の現実的な解決策に至ることもある。グループによって完了しなければならないタスクリスト、並びにグループメンバが把握できる締切りが共通のゴールに到達する助けになることもある。すべてのグループメンバが同時に参加できるわけではないので、通信は違うトピックに関するものであったり、非同期的に発生したりし得る。したがって、実装例は、将来の利用のための生成されたナレッジ(knowledge)の抽出を容易にできる。
【0016】
関連技術の実装では、マルチメディアドキュメントを作成し、将来の利用のためにやり方指示、よくある質問(FAQ)、概要報告などのコンテンツをユーザが保存及び編集可能となるナレッジ抽出システムを有する、メッセージングアプリケーションのインタフェースが提供されていない。
【0017】
メッセージ管理プログラムのアプリケーションインタフェースの実装例として、拡張チャットインタフェースがあって、メッセージとしてのチャットを構成して、優先度でマーク付け可能なトピック及び質問の概要を与えることが可能である。これらの要素は、チャット内にハイライトされ、開始画面上に開始点として表示される。実装例において、メッセージのひとつであるチャットに蓄積されたナレッジに基づいた、やり方指示、FAQ、報告も作成される。これは、ユーザによりガイドされるか、半自動化又は自動化とすることができる。既存の関連技術の実装ではチャットを構成することはできない。更に、チャットのコンテンツを可読ドキュメントフォーマットに変換する機能も、関連技術には備えられていない。
【0018】
図1は、実装例によるシステムの概要を示している。システム100には、拡張チャットアプリケーション101、ドキュメント生成器102、及びドキュメントビューア103を含むことができる。拡張チャットアプリケーション101は、タスク指向の小グループを支援可能な機能で構成され、モバイルデバイス及びデスクトップコンピュータで利用可能である。ドキュメント生成器102は、やり方指示、FAQ、レポートなどのようなマルチメディアドキュメントの作成を可能とする。ドキュメントビューア103は、印刷可能レポート104としても生成可能であるドキュメントをフィルタリング、閲覧、及びプレイするために使用される。
【0019】
図2(a)は、チャットなどのメッセージを管理する管理プログラムの実装例による拡張チャットアプリケーションを示している。関連技術のチャットアプリケーションには、テキスト、画像、映像、及び音声のメッセージの送信、画像と映像の編集、アニメーションGIFと顔文字の送信、連絡先カードの送信、及びグループ通信などの機能を含むことができる。拡張チャットアプリケーションの実装例では、タスク志向の小グループ向けに設計された追加要素が提供される。そのような要素は、チャットビューにおける会話の間に作成されうる。チャットのエントリに依存して、ダイアログが開き、ユーザは追加情報(例えば、期日、選択されたグループメンバ、有効継続期間など)を入力可能である。次に、作成された要素はチャット内にマークされるか、及び/又は図2に示すような拡張された開始/概要画面に示される。これは単にグループと過去のチャットを示すだけではなく、未回答の質問やアクションを必要とする他の要素、並びにチャット内に新規に加えられた要素又はメッセージのインジケータが次のように示される。
【0020】
サブスレッド:サブスレッドの実装例では、質問や議論がチャット中にハイライトされ、終了としてマークされるまではそのアプリケーションの開始ページに表示される(例えば図2(a)の201の「どこで花を買えばいい?」を参照)。実装例では、チャットを厳密なタイムラインベースのビューに分割して、要素のスレッド状構造を開始することもできる。更に、サブスレッドが、所望の実装によっては他のサブスレッドも含み得る。例えば、サブスレッドが議論に参加しているグループに基づいて他のサブスレッドに分岐することもある。スレッド/サブスレッドがサブスレッドを持って、所望の実装によっては任意の深さのスレッドチェーンを容易にすることができる。
【0021】
メモ:メモの実装例では、メモがチャット内でハイライトされたり、受信者がマークして開始ページからそのメモを隠すことも可能である。そのようなメモは、「付箋」的なメタファについて行き、アプリケーションが終了するまでは開始画面上に留まることができる。対照的に、「付箋」的でない他の議論要素は、タイムライン中に適宜配置されて、新しいメッセージが追加されると画面から取り除くことができる。
【0022】
To―Do/タスク:実装例では、タスクはチャット中でハイライトされて、アプリケーション内の追加タブのto-doリストに表示することができる。タスクは、指定されたグループメンバの少なくとも一人によって完了したとしてマークすることができる。そして所望の実装によっては、締切りがある場合や、フィードバック(例えば結果の写真)を要求されることもある。
【0023】
将来へのメッセージ:実装例では、メッセージは未来のある時刻に送信されて、特定された未来のある時刻にのみ配信されるように計画することができる。
【0024】
時間ベースのリマインダ:実装例では、リマインダの日付/時刻を送信者が指定する以外は通常のメッセージと同じようにして、時間ベースのリマインダを作成可能である。このリマインダは受信者のメッセージのタイムラインリストに(例えば即時に)表示されるように構成することができるが、特定の日付/時刻にその受信者に最新のメッセージとして再表示するように構成することも可能である。
【0025】
場所ベースのリマインダ:場所ベースのリマインダ用の実装例では、送信者は、日付/時刻の代わりにリマインダ場所を設定してメッセージが再表示されるようにする。例えば、メッセージが場所ベースのリマインダで送信されると、メッセージはその受信装置が特定の場所に行くまでは、受信装置のキュー内に保持することができる。別の実装例では、メッセージは受信装置がその特定の場所に居ることを示したら、送信されてもよい。所望の実装に応じて他の実装を利用することも可能である。
【0026】
時間と場所ベースのリマインダ:実装例では、時間リマインダと場所リマインダを組み合わせて、送信者がメッセージを表示する日付/時刻に加えてリマインダ場所も設定できるようすることが可能である。
【0027】
グループカレンダ:実装例では、グループカレンダが、個人とグループの活動の概要を与える。グループカレンダはほかのカレンダに同期してもよい。イベントとアポイントメントをチャットからカレンダに直接送信することができる。
【0028】
マークメッセージ:実装例では、チャットのタイムラインに投稿されたメッセージは、重要又は「いいね!」としてマークすることが可能である。
【0029】
検索:実装例において、チャット等のメッセージ中の特定の単語、画像、音声、及び/又は映像の検索を容易にするインタフェースが提供される。メディア検索には、日付検索、メディア種類検索等の先進的検索方法が必要である。
【0030】
上記の各機能はグループメンバの集合に送信可能である。
・全グループ:全グループメンバが要素を受信する。
・グループの一部:グループメンバの画定された部分集合が要素を受信する。
・単一メンバ:グループメンバの一人だけが要素を受信する。
【0031】
チャットのサブセクションで新たな議論を開始する質問としてサブスレッドを追加することは、関連技術のチャットアプリケーションにはない概念である。サブスレッドを利用することで、着信チャットメッセージを受信済みとして編成することが可能である。そうすることで、関連技術の実装のように受信時にメッセージを表示するのではなく、関連メッセージを対応スレッドに関連付けることで画面上のスペースを節約することが可能である。
【0032】
実装例において、サブスレッドはいくつかの理由で作成可能である。例えば、サブスレッドは、トピックに関する情報をチャット内に一緒に保持することを容易とし、質問が確実に回答されるようにする。
【0033】
グループメンバがトピックを議論することを希望して議論を開始してもよい。関連技術のアプリケーションではチャットビューでの議論の開始を容易にしているが、時間経過とともに1つのトピック又は議論に関連するメッセージが他の議論やチャットトピックと混同される可能性がある。サブスレッドを立てることで、このグループから他のトピック及び議論へ迷い込みかねない過去の回答の参照や引用を必要としないで、グループを1つのトピックに集中させることができる。
【0034】
更に、グループチャットにおける質問と回答に関する1つの問題は、質問に対する応答が元の質問とは切り離されて、他のトピックからのメッセージに混同されてしまう可能性があることである。例えば、チャット対話中にユーザが質問しても、その質問に答えることのできる人がオンラインしていないことがあり、且つそのチャットの対話は継続していると、特定の人がオンラインに戻ってくるまでに、その質問は話題の中心から反れてしまうことがあり得る。他のユーザがすぐに回答しないうちに、あるユーザが連続するメッセージで複数の質問をする場合もある。グループ内の一人又は複数のユーザが1つの質問に答え始めて、話題の中心がずれてしまったためにその他の質問は忘れてしまうこともある。質問に関するサブスレッドを作成することで、チャット中にマークして示され、ホーム画面(これはユーザがそのアプリケーションを開くときのエントリ点である)に新規事項として表示されるために、質問を忘れられないようにすることができる。
【0035】
図2(b)は、実装例によるチャットアプリケーションを示している。特に図2(b)は特別の要素を生成する画面の例を示している。実装例において、メッセージ作成時にサブスレッドが作成され得る。サブスレッドは、新規のメッセージを作成するときか、又は既に投稿されているメッセージのレベルを上げることによって作成可能である。ユーザが送信する前にメッセージを入力(又はファイルを投稿)する場合、そのメッセージは図2(b)に示すように、特別な要素(例えばサブスレッド)として要素マーキング画面210上にマークされ得る。特別の要素を作成して、サブスレッドにテキストを書き込むことも可能である。
【0036】
実装例では、既に投稿されたメッセージは、フォローアップメッセージを利用しないでレベル上げすることが可能である。例えば、ユーザは(例えば、必ずしもエントリの制作者でなくても)、チャット内の要素に対してアクション(例えばタッチスクリーン上での長押し動作)をすることが可能である。メニューが図2(b)に示すように要素マーキング画面210を開き、そこでエントリが特別要素としてマークされ得る。
【0037】
実装例では、既に投稿されたメッセージは、フォローアップメッセージを手動選択することでレベル上げすることが可能である。実装例では、ユーザは(例えば、必ずしもエントリの制作者でなくても)、チャット内の要素に対してアクション(例えばタッチスクリーン上での長押し動作)をすることが可能である。メニューが図2(b)に示すように要素マーキング画面210を開き、そこでエントリが特別要素としてマークされ得る。そうしてユーザは次の画面に進んで、新規サブスレッドの一部となるべき既存のエントリを選択することが可能である。
【0038】
実装例では、既に投稿されたメッセージは、フォローアップメッセージを半自動選択することでレベル上げ可能である。実装例では、ユーザは(例えば、必ずしもエントリの制作者でなくても)、チャット内の要素に対してアクション(例えばタッチスクリーン上での長押し動作)をすることが可能である。メニューが図2(b)に示すように要素マーキング画面210を開き、そこにはエントリが特別要素としてマークされ得る。そうしてユーザは次の画面に進んで、新規サブスレッドの一部となるべき事前選択されたエントリを補正することが可能である。
【0039】
サブスレッドは、スレッド及びサブスレッドのインタフェース、カラービュー、あるいは2画面の分割ビューなどのような様々な異なる方法で閲覧できる。閲覧者はチャットアプリケーションを利用して異なる表示の間を切り替えることができる。表示は、同一情報の異なる表現であり得る。
【0040】
図2(c)に示すようなスレッド及びサブスレッドのインタフェースを含む実装例においては、スレッド及びサブスレッドのインタフェースはチャットを厳密にタイムラインベースのパラダイム(paradigm)に分解し、チャットウィンドウ内にサブスレッドを示す。サブスレッドへの返事又は回答はサブスレッドの末尾にある「+」を選択して追加可能であり、これはチャット全体の末尾ではなく対象となるサブスレッドの末尾にエントリを追加させるようにする。このパラダイムを使用すると、新規メッセージは必ずしもある時点以降の未読としてマークされているチャット全体の末尾に表示されるわけではない。メッセージはチャット全体の全スレッド中に広がる可能性がある。そのような実装では更に、チャットのどこかに新規エントリがあり得るというユーザへのヒントの表示を利用してもよい。そのようなヒントの例としては、トップバー内の警告サイン(例えばユーザの注意を促すボタン)があり、これはチャット全体の中にいくつの新エントリがあるかを示すとともに、ユーザが1つの新規エントリから別の新規エントリへチャット中をジャンプするのに利用可能なボタンとしても機能し得る。スレッド及びサブスレッドのインタフェースの実装例を図2(c)に示す。図2(a)の概要画面では、質問の横にその質問に関する新エントリの数が示されている。実装例では、質問を選択すると、チャット内のサブスレッドの最後の未読メッセージにジャンプする。
【0041】
実施例では、カラービューがチャットのタイムラインベースのパラダイムを維持し、サブスレッドが異なるエントリを違う色でマークする。サブスレッドへの返事又は回答は、質問の横の「+」をクリックして、質問と同じ色でマークされるエントリを追加できる。このパラダイムを使用すると、新規メッセージはある時点以降の未読としてマークされるチャット全体の末尾に表示される。ただし、質問はチャットのどこかへ広がっている可能性がある。このため、実装例には1つの質問から別の質問へユーザにチャット中をジャンプさせるボタンが含まれ得る。実装例では、サブスレッドの最後の回答上にジェスチャ(例えば長押し)を用いて、図2(d)に示すように1つのサブスレッドの一部として新エントリをマークすることも可能である。図2(d)に示すように、関連するメッセージは色でコード化され、プラス記号又は他の所望のユーザインタフェースインジケータに入力すると、デバイスは同じ色のメッセージをスキャンし、同じ色を有する次のメッセージをタイムスタンプに基づいて表示又はハイライトする。概要画面には、質問の横にその質問に関する新エントリの数が示される。質問を選択すると、チャット内のその質問に対する第1の未読回答へジャンプする。
【0042】
2画面ビューの実装例では、ビューをスレッドとサブスレッドインタフェースと同じようにして実装できる。更に2つの画面ビューがサブスレッドの開始をアイコンでマークしてチャットのタイムラインベースパラダイムを保持するようする。サブスレッドへの返事又は回答は、サブスレッドをタップして、まさにそのサブスレッドとそのフォローアップメッセージを示す新しい画面にユーザを導くことによって読むことが可能である。このパラダイムを使用すると、このサブスレッドに対する新規のフォローアプップメッセージを、最初に特別のボタンを選択することなく、代わりに図2(e)に示すように画面の下にテキスト入力を打ち込むだけで、サブスクリーン上に通常のメッセージとして入力可能である。概要画面には、質問の横にその質問に関する新エントリの数が示される。質問を選択すると、サブスレッドのビューへジャンプする。図2(e)に示すように、スレッドに対するサブスレッドを表すための分離画面が生成される。更に、分離画面内に同一インタフェースを与えることが可能であって、それにより、サブスレッド内にサブスレッドを実装すること及びサブスレッド内のサブスレッドに対する分離画面を生成することを、所望の実装に従って容易とする。
【0043】
実装例において、チャットアプリケーションに追加し得るドキュメント生成器がある。上記の新規導入機能は、以前の線形チャットに更なるレベルのアノテーションを追加する。要素をマーキングするやり方の違いが重要さのヒントを与える。ただし、より長いチャット等のメッセージのやり取りからでは、後から情報を見つけることは難しくなり得る。ここでは、要素にマーキングするばかりではなく、そのチャットからナレッジを含む意味上で関連する要素の組を抽出し、それをやり方指示、FAQ、又はレポートなどのようなより読みやすい形に変換することを支援できる。要素はユーザの選択に基づいて選択されるか、作成されるドキュメントに応じてアノテーション(例えば、要素の種類、ユーザが時間経過とともに与えるスター印/マーカ)によって事前選択可能である。以下では、実装例がチャットアプリケーションからのマルチメディアドキュメントの作成を容易にする。
【0044】
実装例では、マルチメディアドキュメントはユーザ誘導型であってよい。ユーザ誘導型の作成では、インタフェースは制作者の数ステップの遂行を容易にする。第1に、チャット要素がインタフェースを介して選択される。このプロセスはユーザが1つのチャットエントリをクリックして開始される。次に選択ツールがそのアプリケーション内の後続の要素のリストを提供する。その後、ユーザは、各要素についてそれをドキュメントに追加すべきかどうかを選択できる。そして、選択された要素が編集領域にコピーされて、そこで再配置、編集、及び以前又は後続の要素とマージすることができる。必要であれば新要素をローカルファイルシステムやインターネットから付け加えることが可能であり、フォーマット化が適用可能である。最後に、ドキュメントは所望のフォーマットにしてエクスポート可能である。
【0045】
実装例において、マルチメディアドキュメントが半自動プロセスによって生成可能である。半自動作成においては、ユーザがチャット内の選択開始箇所を選択した後、幾つかのアルゴリズムが適用される。基本的なテキスト解析並びにアノテーション(例えば、好き、マーカ)の解析は関連するエントリを示唆する。それはユーザにより変更されることもあり得る。コピープロセスにおいて、テキストの不要部分(例えば、顔文字、不要なスペース)が削除され、ユーザが連続した小さなメッセージとして投稿した要素が1つのテキストにマージされる。得られた要素のリストは次に、ユーザ誘導プロセスで記述されるように編集可能である。ここで、ユーザは、インターネットから映像シーン、画像、あるいは他の材料を提供する、検索及び調査アルゴリズムの支援を受ける。
【0046】
実装例において、マルチメディアドキュメントが自動プロセスによって生成可能である。自動作成もまた、ユーザ誘導及び半自動モードから学習し、機械学習アルゴリズムなどの学習アルゴリズムを使用して所望のドキュメントフォーマットを自動的にエクスポートするように構成可能である。
【0047】
リニアマルチメディアドキュメントに加えて、ハイパーメディアグラフもドキュメント作成インタフェースを使用して作成可能である。ハイパーメディアグラフには、グラフ内のフォークに適用されるロジックステートメントのためのグラフビューとエディタが必要である。そのような実装例では、異なるユーザグループに対して異なるレベルの詳細、難易度、又は命令を提供可能な、ハイパーメディアドキュメントを特にモバイルデバイス上に作成できる。モバイルインタフェースはドキュメントの概要を提供し、既存のドキュメントのインタラクティブ要素を提供する。ここでこのドキュメントを拡張してモバイルデバイス上で可能なハイパーメディア作成を行うことが可能である。APPに情報を記録することにより多くの情報を提供するためにより詳細な情報並びに異なる種類のメディア要素を追加することが可能である。
【0048】
ドキュメント生成時のより複雑なサブプロセスは、後続エントリの選択、テキストクリーニング、及びエントリのリオーダリングである。これらの構成要素は、トピック検出と追跡の関連技術の実装上に構築されて、チャットメッセージの初期トピッククラスタリングを導出し、その結果として検出したトピックを追跡することが可能である。そのような手法は、ニュースストリームやeメール編成にも適用されてきた。キーフレーズ抽出や会話力学解析などの手法もまた、重要度の低い投稿のフィルタリングや、生成されたドキュメントの構造化に役立てることができる。
【0049】
実装例では、マルチメディアドキュメントビューアがすべての種類のメディアとナビゲーション要素とを表示する機能を提供する。ビューアは、ハイパーメディアグラフをフィルタリングすることにより、再生デバイス及びユーザ特性に適応できる。再生デバイスに応じて、メディア要素のサイズとともにデータ量が調整可能である。実装例では、接続の遅いものはテキスト及び画像に集中することがある。その一方で(異なるタイプのメディアを使用可能な場合には)映像は高いバンド幅を利用して表示される。更に、レポート生成器には、得られるドキュメントをユーザの入力と目的に従って適応させるフィルタ機能を提供可能である。
【0050】
更に、情報に欠落があるか又は意図通りに提示されていない場合には、ユーザに閲覧中のドキュメントを拡張させて、受動閲覧者を共同制作者とすることができる機能が入手可能である。そのような機能は異なるモードで動作可能である。
【0051】
非制御モードの実装例では、コンテンツは承認プロセスなしでユーザによって編集可能である。
【0052】
制作者制御モードの実装例では、ユーザがコンテンツを追加/編集する場合には、マルチメディア/ハイパーメディアの制作者に通知が送信される。制作者が同意する場合には、制作者は変更を容認できる。制作者が同意しない場合には、そのコンテンツは拒否されるか、議論を開始できる。
【0053】
ユーザ制御モードの実装例では、ユーザがコンテンツを追加/編集する場合には、新コンテンツが未検証としてマークされる。そうして他のユーザは、そのコンテンツをピアレビュー(peer review)し、コンテンツを変更し、そしてそのコンテンツがドキュメント
への「正規」のコンテンツとして容認可能かどうかを票決することができる。こうすることで、新情報の良品質とドキュメントの不断の改善が保証される。
【0054】
図3は、実装例による、全体フロー図である。実装例において、システムは3つのサブプロセス(コンテンツ収集、ハイパーメディアドキュメント生成、ハイパーメディア準備)に分割可能である。これを図3に示すように以下で詳細に説明する。
【0055】
301において、システムは、図2(a)~図2(e)で説明したような、拡張チャットアプリケーションからコンテンツを収集するように構成されている。そのようなコンテンツには、チャットアプリケーションを介して投稿されたテキスト、画像、映像、音声、又はファイルが含まれ得る。302において、コンテンツを収集後、ハイパーメディアドキュメントをコンテンツから生成することができる。303において、ハイパーメディアドキュメントがユーザへの表示インタフェースに提供される。更に詳細なフローは図4に示されている。
【0056】
図4は、実装例による、データフローを示す。具体的には、図4に拡張チャットアプリケーション401と、ドキュメント生成器402と、ドキュメントビューア/レポート403の間のデータフローが示されている。拡張チャットアプリケーション401において、ユーザが410においてメッセージを送信する。これは411の拡張チャットUIに送信される。メッセージがテキストのみの場合、テキストはデータベースに追加されて、エントリとの間の接続が412で更新される。メッセージがメディアファイルの場合には、メディアファイルは413でサーバ上に格納され、データベースにリンクが追加される。そうしてエントリとの間の接続が更新される。そうして全ユーザに対してチャットが更新される。
【0057】
ドキュメント生成器402において、420でドキュメントを作成するユーザは、421でエントリセレクタを開いて開始エントリを選択し、ついで422でハイパーメディアドキュメントエディタ422に案内される。ハイパーメディアドキュメントエディタではインタフェースが備えられてコンテンツが編集可能であり、423に図示するようにインターネットからのコンテンツを追加可能である。コンテンツはハイパーメディアドキュメントに一緒にリンクされる。チャットに関しては、メディアファイルがファイルサーバに格納され、テキストと構造がデータベースに格納される。ユーザはドキュメントを選択し、更なる入力を追加できる。そうしてインタラクティブなハイパーメディアドキュメントが作成され、ビューアに表示されるか又はコンテンツがドキュメントファイル(例えばPDF、DOC)としてエクスポートされる。
【0058】
ドキュメントビューア/レポート403では、430でドキュメントを閲覧するユーザがハイパーメディアドキュメントビューア431を開く。これは432でインタラクティブハイパーメディアドキュメントを表示する。インタラクティブハイパーメディアドキュメント432はハイパーメディアドキュメントアセンブラ433で作成される。これはユーザがドキュメントを構築するようにハイパーメディアドキュメントビューア431に命令した後、ユーザのためのドキュメントファイルを434で生成するようにも構成されている。
【0059】
図5は、実装例によるコンテンツ収集のフローを示す図である。具体的に、図5はコンテンツ収集(例えばチャットアプリケーション)時のプロセスを示す。チャット/サブチャットの選択が501においてユーザを介してインタフェース上で受信される。502においてシステムはコンテンツの追加を継続する。このフローの間、システムは拡張チャットアプリケーションを介してタイプされたテキスト又はメディアを受信してもよい。503において、要素が図2(b)のインタフェースに示したようにマークされてよい。図2(b)に示すように、要素は、質問/議論、ToDo、メモ、リマインダ、イベント、今後へのメッセージ、等としてマークすることができる。特に要素がマークされない場合(No)、フローは504に進み、コンテンツ生成が終了したかどうかが判定される。マークされる場合(Yes)、流れは終了し、そうでない場合(No)にはフローは502に進んで、追加のコンテンツが処理される。
【0060】
505で、チェックを行い、マークされた要素が質問又は議論の開始指示であるかどうかを判定する。そうである場合(Yes)、フローは506に進んで、要素を質問又は議論の開始としてマークし、次に507に進んで可視性の設定をする。507では、特定の要素の可視性の設定を容易にするインタフェースを提供することができる。実装例では、単一ユーザ、グループの一部、グループ全体、の3つの可視性の設定があり得る。単一ユーザ又はグループの一部が選択された場合、グループの対応するサブセットが選択される。
【0061】
そうでない場合(No)、フローは508に進み、チェックを行って特定の要素がToDo要素かどうかを判定する。そうである場合(Yes)、フローは509に進んで、要素をToDo要素としてマークする。そうしてフローは510に進んで最終期限が設定される。ここで、要素が継続的に有効であるか、又は要素が終了しなければならない日時の選択を容易にするインタフェースが提供される。提供されるインタフェースには、511でリマインダ設定を容易にするインタフェースも含むことが可能であり、そこでインタフェースは、リマインダをいつに設定すべきか、及び最終期限のどれだけ前にリマインダがチャットアプリケーションを開かなければならないか、ということの選択を容易にする。更に、インタフェースは512でのアクションの設定も容易にすることができる。これは、所望の実装に従った、写真の撮影、質問への回答、値の記入、受信者から映像又は何らかの他の種類のドキュメンテーションを取得すること、に対する要求であり得る。
【0062】
そうでない場合(No)、フローは513に進み、チェックを行って特定の要素がメモ要素かどうかを判定する。そうである場合(Yes)、フローは514に進んで、要素をメモとしてマークする。フローは次に515に進み、インタフェースを介して有効性を設定する。ここでインタフェースが提供されて、要素がどれくらい有効で他のユーザに表示されているかを示す時間の長さの選択を容易にすることができる。
【0063】
そうでない場合(No)、フローは516に進み、チェックを行って特定の要素がリマインダに指向されているかどうかを判定する。そうである場合(Yes)、フローは517に進んで、要素をリマインダとしてマークする。フローは次に518に進んで、リマインダの種類を決定する。リマインダが場所と時間をベースとするリマインダである(Yes)場合、フローは524に進んで、インタフェースを介して場所とその他のリマインダ情報を設定する。実装例では、場所は住所をタイプするか、地図上で場所をマークするかのいずれかによって入力可能である。
【0064】
そうでない場合(No)、フローは519に進んで、特定の要素が時間ベースのリマインダであるかどうかを判定する。そうである場合(Yes)、フローは525に進んでインタフェースが提供され、開始日を設定し、526に進んで要素のための時間を設定する。そうでない場合(No)、フローは520に進んで、特定の要素が場所ベースのリマインダであるかどうかを判定する。そうである場合(Yes)、フローは521に進んで524でのフローと同様にして場所を設定する。そうでない場合(No)、フローは507に進んで、可視性を設定する。
【0065】
516で特定の要素がリマインダでない場合(No)、フローは522に進み、そこで要素がイベントに指向されているかどうかに関する判定がなされる。そうである場合(Yes)、フローは523に進んで、その要素をイベントとしてマークする。フローは次に524に進んでイベントの場所を取得して設定し、所望の実装に従ってイベントの日付や時間等のその他の情報の取得と設定に進む。
【0066】
特定の要素がイベントでない場合(No)、フローは527に進んで要素を今後へのメッセージとしてマークする。そして525に進んで、日付を設定し、526に進んで時間を設定する。
【0067】
別の実装においては、拡張チャットアプリケーション内のコンテンツが図3の301に示すように収集された後、ハイパーメディアドキュメントが302で生成されて、303でドキュメントビューアに提供されてもよい。図6は、実装例による、ドキュメント生成のフロー図を示す。601において、ドキュメント生成を、ユーザ誘導生成プロセス(例えば手動)とするか、あるいは半自動プロセスとするかに関する判定がなされる。
【0068】
ユーザ誘導ドキュメント生成プロセス(Yes)においては、613でチャット入力の選択を容易にするインタフェースが提供される。入力はインタフェースを介してそのそれぞれをマークすることで選択される。614でユーザの確認またはインタフェースを提供して、入力コンテンツが容認可能であるかどうかを判定することができる。そうでない場合(No)、フローは615に進み、そこでチャット入力の編集を容易にするインタフェースが提供される。そのようなインタフェースでは、入力は変更可能であって、例えばタイプミスや絵文字や望ましくないテキストを削除できる。テキストの追加または削除も可能である。
【0069】
616でユーザの確認またはインタフェースが提供されて、エントリオーダーが容認可能であるかどうかを判定できる。そうでない場合(No)、フローは617に進み、所望のドキュメントに従って、チャット入力の順序の再配列を容易にするインタフェースが提供される。実装例では、エントリオーダーがチャットのタイムラインのために間違っているという状況もあり得る。必要があれば単一エントリもオーダー変更可能である。
【0070】
618でユーザの確認またはインタフェースが提供されて追加コンテンツを付加すべきかどうかを判定できる。そうである場合(Yes)、フローは619に進み、そこで追加コンテンツを追加するためのインタフェースが提供される。情報が欠落している場合、又は制作者がチャット時に収集されたものよりも良いイラストを知っている場合には、所望の実証に従って、外部情報を追加可能である。
【0071】
620でユーザの確認またはインタフェースが提供されて、ハイパー構造を追加すべきかどうかを判定できる。追加すべきである場合(Yes)、フローは621に進み、そこでハイパーリンクが追加可能である。実装例では、ハイパー構造はコンテンツの異なるバージョン又はドキュメントを介する異なるパスを提供するために追加することが可能である。
【0072】
ドキュメント生成が半自動プロセスを介して行われる場合(No)、フローは602に進み、そこではチャットからの開始エントリの選択を容易にするためにインタフェースが提供される。自動モード又は半自動モードにおいて、1つの開始エントリが選択されると、それによって603において開始エントリに後続するエントリを選択することでコンテンツ生成が開始される。
【0073】
604、608、612において、半自動生成プロセスが所望されるかどうかに関してそれ以前に設定した決定をチェックする。そうである場合(Yes)、幾つかのインタフェースが提供される。それには以下のものが含まれ得る。
【0074】
605において選択補正用のインタフェースが提供可能であって、そこでは603での自動選択結果を、ユーザ誘導モードで使用したのと同じインタフェースで補正可能である。選択がOKの場合(yes)、フローは607に進んで、例えば615で説明したように自動的にテキストがクリーニングされる。そうでない場合(No)、フローは606に進んで、インタフェースを介したユーザからの指図に従って、エントリ選択が補正される。
【0075】
609においてテキスト補正用のインタフェースが提供可能であり、そこでは自動テキストクリーニング結果を、ユーザ誘導モードで使用したのと同じインタフェースで補正可能である。テキストがOKの場合(yes)、フローは611に進んで、例えば617で説明したように自動的にエントリの再配列を行う。そうでない場合(No)、610に示すようにテキストのクリーニングプロセスが提供される。
【0076】
次に622において、ドキュメント構造が、ドキュメントビューアによってドキュメントを取り出したデータベース412及びファイルストレージ413へエクスポートされる。自動生成が終了すると、あるいはユーザがユーザ誘導生成又は半自動生成を終了させると、ドキュメント構造はドキュメントコンテンツとともにビューアにエクスポートされる。
【0077】
図7(a)~図7(c)は、実装例によるチャットアプリケーション用のドキュメント生成インタフェースの例を示している。ユーザ誘導プロセス用のインタフェースでは、図7(a)に示すような、ユーザが作成しようとするドキュメンの種類(例えば、ハウツー、FAQ、レポートなど)をまずユーザに定義させる画面が提供される。次いで、ドキュメントに応じて、構造要素を所望の実装に従ったテンプレートに提供可能である。例えば、ステップとサブステップ要素は、図7(b)に示すようにハウツー指示のテンプレートの一部であり、質問要素はFAQ用のテンプレートの一部であり、タイトル、関係者、導入/目的、時間スパン、進捗などの要素はレポート用テンプレートの一部である。ステップは、ユーザがタイプインしてもよいし、既存要素から選択してもよい。チャット入力からのコンテンツ、todoメモ、メモ、あるいはチャットメッセージからのその他の特別な要素は、図7(b)に示すようにテンプレートに充当するために使用可能である。手動モードでは、ユーザはこれらの入力を図7(c)に示すような選択画面で選択する。コンテンツを追加した後、コンテンツを再編成及び編集することができる。完成したドキュメントは、この過程でハイパーメディアドキュメントを作成する他のバージョンを用いて拡張可能である。
【0078】
図8は、実装例による、ドキュメント準備及び生成のフロー図である。801において、ドキュメント選択を容易にするインタフェースが提供される。例えば、ユーザは概要タブでドキュメントを選択可能である。802において、出力デバイスがプリンタであるかどうかの判定がなされる。そうである場合(Yes)、フローは803に進み、そこでドキュメントがマルチメディアドキュメントから生成される。実装例において、各映像に対してキーフレームが抽出されてドキュメントに追加される。各音声に対してテキストが抽出されてドキュメントに追加される。804において、ドキュメントは印刷される。プリンタが使用できない場合にはローカルデバイスにダウンロードされる。
【0079】
出力デバイスがプリンタではない場合(No)、他のバージョンのドキュメントが利用可能かどうかが805で判定される。そうである場合(Yes)、806で入力変数を取得するためにインタフェースが提供される。実装例では、ドキュメントのカスタマイズ用インタフェースの入力変数としては、画面分解能、利用可能バンド幅、デバイス言語、ユーザナレッジ、ユーザの性別、所望のインタラクティブ性レベル(例えば、低/高)、他ユーザが同一ドキュメントから取ったパス、所望実装に依存するその他のもの、を含むことができる。入力変数の幾つかはデバイスから自動的に決定され、あるものはユーザに関するナレッジに基づき、またあるものはユーザ入力(例えば使用開始時に)を必要とする場合がある。フローは807に進んで、入力変数に基づいてドキュメントがカスタマイズされる。コンテンツは適応されて、ハイパーメディアドキュメント内のパスが事前選択され得る。
【0080】
808では、ドキュメントがビューアにロードされ、ユーザはドキュメントを監視又は拡張可能である。拡張プロセスは、制御不可、又は制作者が制御、又はユーザが制御、のいずれかであってよい。
【0081】
実装例においては、コンテンツ収集とチャットアプリケーションがあり得る。実装例は、非常に多種類の機能を提供する幾つかのツールの接続と同期を容易にする。チャット内の検索の他に、アプリケーション内にインデックス付けされて一旦保存された共有ファイルを検索することも可能である。メッセージをマークして今後のリマインダとすることも可能である。これにより実装例では、チャットビューから直接的にチャットを構造化し、又はチャット要素を重要要素としてマークする事が可能となる。
【0082】
図9は、実装例での使用に好適な例示的コンピュータデバイスを有する、例示的コンピューティング環境を示す。コンピューティング環境900内のコンピュータデバイス905は、一つ又は複数の処理ユニット、コア、プロセッサ910、メモリ915(例えばRAM、ROM、及び/又はそれに類似のもの)、内部ストレージ920(例えば、磁気ストレージ、光学ストレージ、ソリッドステートストレージ、及び/又は有機ストレージ)、及び/又はI/Oインタフェース925などを含むことが可能であり、それらの任意のものは情報通信のための通信機構又はバス930に連結可能であり、あるいはコンピュータデバイス905に埋設可能である。
【0083】
コンピュータデバイス905は、入力/ユーザインタフェース935、及び出力デバイス/インタフェース940に、通信可能に連結できる。入力/ユーザインタフェース935と出力デバイス/インタフェース940のいずれか1つ又は両方が有線または無線のインタフェースであって、取り外し可能であってよい。入力/ユーザインタフェース935は、物理的または仮想的であって、入力を提供するために使用可能な任意のデバイス、コンポーネント、センサ、又はインタフェース(例えば、ボタン、タッチスクリーンインタフェース、キーボード、ポインティング/カーソル制御器、マイクロフォン、カメラ、点字器、モーションセンサ、光学リーダ、等)を含み得る。出力デバイス/インタフェース940は、ディスプレイ、テレビ、モニタ、プリンタ、スピーカ、点字器、等を含み得る。いくつかの実装例では、入力/ユーザインタフェース935と出力デバイス/インタフェース940はコンピュータデバイス905に埋設されていてもよいし物理的に連結されていてもよい。別の実装例では、他のコンピュータデバイスが、コンピュータデバイス905のための入力/ユーザインタフェース935と出力デバイス/インタフェース940として機能するか、あるいはその機能を提供してもよい。タッチスクリーンディスプレイ、テレビジョンディスプレイ、又はその他の任意の形態のディスプレイを含む実装例では、ディスプレイが、例えば図2(a)~図2(e)及び図7(a)~図7(c)に示すようなユーザインタフェースを提供するように構成される。
【0084】
コンピュータデバイス905の例としては、これに限るものではないが、高度なモバイルデバイス(例えば、スマートフォン、車両及びその他の機械に搭載のデバイス、ヒト又は動物が携行するデバイスなど)、モバイルデバイス(例えば、タブレット、ノートブックコンピュータ、ラップトップコンピュータ、パーソナルコンピュータ、携帯テレビ、携帯ラジオなど)、及び可動用ではないデバイス(例えば、デスクトップコンピュータ、その他のコンピュータ、情報キオスク、内部に埋設及び/又は連結された一つ又は複数のプロセッサを有するテレビ、ラジオ、など)が含まれ得る。
【0085】
コンピュータデバイス905は、外部ストレージ945とネットワーク950に(例えばI/Oインタフェース925を介して)通信可能に接続されて、同じ構成又は異なる構成の一つ又は複数のコンピュータデバイスを含む、任意の数のネットワーク接続されたコンポーネント、デバイス、及びシステムと通信できるようになっていてもよい。コンピュータデバイス905又は任意の接続されたコンピュータデバイスは、サーバ、クライアント、シンサーバ、汎用機械、専用用途機械、あるいは別のラベルとして、機能するか、そのサービスを提供するか、又はそれらとして称することが可能である。
【0086】
I/Oインタフェース925には、コンピューティング環境900にある少なくともすべての接続コンポーネント、デバイス、及びネットワークに向けて、及び/又はそこから、情報を通信するための、任意の通信又はI/Oプロトコルまたは標準(例えば、イーサネット(登録商標)、802.11x、ユニバーサルシステムバス、WiMax、モデム、セルラーネットワークプロトコル、等)を利用する有線及び/又は無線インタフェースが含まれる。ただしこれに限るものではない。ネットワーク950は、任意のネットワーク又はネットワークの組合せ(例えば、インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク、電話ネットワーク、セルラーネットワーク、衛星ネットワーク、等)であってよい。
【0087】
コンピュータデバイス905は、一時媒体及び非一時媒体を含む、コンピュータ使用可能媒体またはコンピュータ可読媒体を利用して、使用及び/又は通信が可能である。一時媒体には、伝送媒体、(例えば金属ケーブル、ファイバ光学材料)、信号、搬送波などが含まれる。非一時媒体には、磁気媒体(例えばディスク及びテープ)、光学媒体(例えばCD ROM、デジタルビデオディスク、ブルーレイディスク)、固体素子媒体(例えば、RAM、ROM、フラッシュメモリ、ソリッドステートストレージ)、及びその他の不揮発性ストレージ又はメモリが含まれる。
【0088】
コンピュータデバイス905は、いくつかの例示的コンピューティング環境において技術、方法、アプリケーション、プロセス、又はコンピュータ実行可能命令の実装に使用可能である。コンピュータ実行可能命令は一時媒体から取出して、非一時媒体に格納して取出すことが可能である。実行可能命令は、任意のプログラミング言語、スクリプティング言語、及び機械言語(例えば、C、C++、C#、Java(登録商標)、Visual Basic、Python、Perl、JavaScript(登録商標)、他)の内の一つ又は複数から生じることができる。
【0089】
メモリ915は、例えば図1図3図6図8におけるフローに記載されたような、プロセッサ910によって実行されるアルゴリズムを格納又は管理するように構成され得る。本明細書に記載の実装例は、所望の実装に従って、単独又は相互に任意の組合せで実行され得るものであり、特定の実装例には限定されない。
【0090】
プロセッサ910は、ネイティブ環境又は仮想環境において任意のオペレーティングシステム(OS)(図示せず)の下で実行可能である。論理ユニット960、アプリケーションプログラミングインタフェース(API)ユニット965、入力ユニット970、出力ユニット975、及び異なるユニットが相互に、またOSと、そして他のアプリケーション(図示せず)と通信するためのユニット間通信機構995、を含む、一つ又は複数のアプリケーションを展開可能である。上記のユニット及び要素は、設計、機能、構成、又は実装において変形可能であり、ここでの記述に限定されるものではない。プロセッサ910は、メモリ915からロードされた命令を実行するように構成された、物理プロセッサ又は中央処理ユニット(CPU)であってもよい。
【0091】
いくつかの実装例において、情報または実行命令がAPIユニット965で受信されると、それは一つ又は複数の他のユニット(例えば論理ユニット960、入力ユニット970、出力ユニット975)へ通信され得る。いくつかの例では、論理ユニット960は、ユニット間の情報の流れを制御し、上記のいくつかの実装例におけるAPIユニット965、入力ユニット970、出力ユニット975により提供される業務を指揮するように構成され得る。例えば、一つ又は複数のプロセス又は実装のフローは、論理ユニット960だけで制御されてもよいし、APIユニット965と連携して制御されてもよい。入力ユニット970は実装例に記載の計算のための入力を取得するように構成され、出力ユニット975は実装例に記載の計算に基づく出力を提供するように構成されてもよい。
【0092】
実装例において、プロセッサ910は、モバイルデバイスから送信された第1のメッセージをユーザインタフェース上に表示するように構成されてもよい。図2(a)に示す実装例において、201でモバイルデバイスから他のデバイスに送信されたメッセージ201はディスプレイに配置され、プロセッサ910は、モバイルデバイスから送信された第1のメッセージに応答する他のモバイルデバイスからの一つ又は複数の第2のメッセージを監視する。他のモバイルデバイスから第2のメッセージを受信すると、プロセッサ910は、ユーザインタフェースに表示されている第1のメッセージ上にユーザインタフェースインジケータを生成して、第1のメッセージと第2のメッセージとの間の関係インタフェースをユーザインタフェース上に提供するように構成されている。ユーザインタフェースインジケータは、図2(c)に示すようなスレッド及びサブスレッドのインタフェースと、図2(d)に示すようなカラーコード化された関係インタフェースと、図2(e)に示すような別画面の生成との内の1つとして、この関係インタフェースを提供するように構成することができる。図2(c)から図2(e)に示すように、そのようなインジケータは所望の実装に依存して、プラス記号、矢印、Q記号、等の形態をとり得る。
【0093】
図2(c)の例において、ユーザインタフェースインジケータが、関係インタフェースをスレッド及びサブスレッドのインタフェースとして提供するように構成されている場合、プロセッサ910は、第1のメッセージをスレッドの開始として表示することと、ユーザインタフェースインジケータをスレッドの拡張指示として(例えば、Q記号、プラス記号などの形態で)提供することと、そしてユーザインタフェースインジケータ上に入力を受信すると、図2(c)に示す第1のメッセージへの応答によって図示されるように、第2のメッセージをスレッドの拡張を経てサブスレッドとしてユーザインタフェース上に表示することとによってユーザインタフェースインジケータを生成するように構成されている。更に、この実装例は、図2(a)の複数の送信メッセージの例に示されるように、複数のメッセージに拡張可能である。ここで送信メッセージに関係する複数のメッセージは、図2(c)に示すようにスレッドの拡張を経てサブスレッドとしてユーザインタフェース上に表示可能である。
【0094】
図2(d)の例において、ユーザインタフェースインジケータが関係インタフェースをカラーコード化された関係インタフェースとして提供するように構成されている場合には、プロセッサ910は、第1のメッセージを第1の色として表示することと、ユーザインタフェースインジケータを、第1の色を有する次のメッセージへの移動指示として提供することと、そしてユーザインタフェースインジケータ上に入力を受信すると、第2のメッセージを次のメッセージとして第1の色で表示することとによってユーザインタフェースインジケータを生成するように構成されている。第1の色とは異なる第2の色で表示されるメッセージは、第1のメッセージとは異なる関係にあるとして認識される。
【0095】
図2(e)の例において、ユーザインタフェースインジケータが関係インタフェースを分離画面として提供するように構成されている場合には、プロセッサ910は、分離画面の生成として関係インタフェースを提供することによってユーザインタフェースインジケータを生成するように構成されている。プロセッサ910は、第1のメッセージを第1のディスプレイ画面に表示することと、ユーザインタフェースインジケータを、第2の画面への変更指示(例えば矢印)として提供することと、そしてユーザインタフェースインジケータに入力を受信すると、第1のディスプレイ画面を第2のディスプレイ画面に変更して、図2(e)の右側に示すように第2のメッセージを第2のディスプレイ画面上に表示することとによって、ユーザインタフェースインジケータを生成するように構成されている。
【0096】
実装例において、第1のメッセージは場所ベースのリマインダの形態であってもよい。これは他のモバイルデバイスが場所ベースのリマインダに係わる場所に到達したときに、その別のモバイルデバイスに送信されるように構成されている。実装例では、メッセージはその別のモバイルデバイスに送信可能であるが、その別のモバイルデバイスが第1のメッセージで示された場所に、指定の時間にいることを検出するまでは別のモバイルデバイス上には表示されない。実装例では、メッセージは所望の実装に依存して、時間リマインダベースのみ又は場所リマインダベースのみのいずれかであってもよい。
【0097】
実装例では、第1のメッセージは完了すべきタスクを要求できる。そして第2のメッセージは、その完了すべきタスクに対応する、テキスト、映像、及び画像の少なくとも1つを含むことができる。すなわち、モバイルデバイスのユーザはタスクを処理するために画像又は映像が必要であることを示すことができ、画像又は映像を受信するとユーザはタスクが満たされたかどうかを確認することが可能である。ユーザがタスクは満たされたと決定すると、ユーザは確認インタフェース(例えば返信メッセージ、タスク完了を示すユーザインタフェースなど)によって別のモバイルデバイスからそのメッセージを消去することができる。
【0098】
実装例では、プロセッサ910は、図7(a)~図7(c)に示すように第1のメッセージと第2のメッセージに基づくドキュメントを生成するインタフェースからなる、第2のユーザインタフェースインジケータを提供するように構成可能である。第2のユーザインタフェースインジケータに入力を受信すると、プロセッサ910は、図7(a)~図7(c)に示すようにドキュメントエディタ上で第1のメッセージと第2のメッセージの選択処理をして、図8のフローで説明したようにドキュメントエディタで処理された、選択された第1のメッセージと第2のメッセージに対するドキュメントを生成するように構成されている。例えば、図4図8で説明したように、プロセッサ910は、第2のメッセージに関連する一つ又は複数の画像を取り出し、(例えばインターネット又はメッセージサーバから画像または映像のキーフレームをダウンロードすることから)その画像をドキュメント中に組み込むことによって、選択された第1のメッセージと第2のメッセージに対するドキュメント生成するように構成されている。実装例では、プロセッサ910は、第2のメッセージに関連する一つ又は複数の映像を取り出し、一つ又は複数の映像から一つ又は複数のキーフレーム画像を抽出し、その一つ又は複数のキーフレーム画像をドキュメント中に組み込むことによって、選択された第1のメッセージと第2のメッセージに対するドキュメントを生成するように構成されている。キーフレーム画像の抽出は、当分野で周知の、任意の所望の実装に従って行うことができる。更に、プロセッサ910は、図8に示すようにプリンタ上でドキュメントを印刷することによってドキュメントを生成するように構成できる。
【0099】
詳細な説明のいくつかの部分は、コンピュータ内操作のアルゴリズム及び記号表示で表されている。これらのアルゴリズム記述及び記号表示は、データ処理分野における当業者がその革新の要点を他の当業者に伝達するために使用する手段である。アルゴリズムは所望の最終状態又は結果を導く、一連の画定されたステップである。実装例においては、実行されるステップは、確実な結果を達成するための有形量の物理的操作を必要とする。
【0100】
特に別段の記述がない限り、議論から明らかなように本説明全体を通して、「処理する」、「計算する」、「算出する」、「決定する」、「表示する」などの用語を用いた議論には、コンピュータシステムのレジスタ及びメモリ内で物理的(電子的)量として表されたデータを、コンピュータシステムのメモリ又はレジスタ又はその他の情報の格納、送信、又は表示デバイス内に物理量として同様に表される他のデータに操作及び変換する、コンピュータシステムや他の情報処理デバイスの動作及び処理を含み得ることを理解されたい。
【0101】
実装例は本明細書に記載の操作を遂行するための装置にも関係し得る。この装置は、所要目的のために特別に構築されたものであってもよいし、コンピュータプログラムによって選択的に起動又は再構成された、一つ又は複数の汎用コンピュータを含んでもよい。そのようなコンピュータプログラムは、コンピュータ可読記憶媒体又はコンピュータ可読信号媒体などの、コンピュータ可読媒体に格納され得る。コンピュータ可読記憶媒体には、これに限るものではないが、光ディスク、磁気ディスク、読出し専用メモリ、ランダムアクセスメモリ、ソリッドステートデバイスおよびソリッドステートドライブなどのような有形媒体、又は電子情報の格納に好適な他の任意の種類の有形または非一時媒体が含まれ得る。コンピュータ可読信号媒体は、搬送波などの媒体を含み得る。本明細書に提示したアルゴリズム及び表示は、いかなる特定のコンピュータ又は他の装置に本質的に関わるものではない。コンピュータプログラムには、所望の実装操作を実行する命令を含む、純粋なソフトウェア実装が含まれ得る。
【0102】
様々な汎用システムが本明細書に記載の実施例に従うプログラム(管理プログラム)及びモジュールと共に使用可能である。あるいは、所望の方法ステップを実行するためにより特殊化した装置を構築することが便利となる場合もあり得る。更に、実装例は特定のプログラム言語を参照して記述されたものではない。本明細書に記載の実装例の教示は、様々なプログラム言語を使用して実装され得ることを理解されたい。プログラム言語の命令は、例えば中央処理ユニット(CPU)、プロセッサ、又はコントローラなどの、一つ又は複数の処理デバイスによって実行可能である。
【0103】
当分野において周知のように、上記の操作は、ハードウェア、ソフトウェア、又はソフトウェアとハードウェアの何らかの組合せによって実行可能である。実装例の様々な態様は、回路と論理デバイス(ハードウェア)を用いて実装され得る。他方、他の態様は機械可読媒体(ソフトウェア)上に格納された命令を用いて実装し得る。これはプロセッサによって実行されると、本出願の実装を遂行する方法をプロセッサに実行させるであろう。更に、本出願のいくつかの実装例がハードウェアのみで実行され、他の実装例がソフトウェアのみで実行されることもあり得る。更には、説明した様々な機能は単一ユニットで実行されてもよいし、任意の数の方法で複数のコンポーネントに跨って実行されてもよい。ソフトウェアによって実行される場合、方法は、コンピュータ可読媒体上に格納された命令に基づいて、汎用コンピュータのようなプロセッサによって実行され得る。必要に応じて、命令は媒体上に圧縮フォーマット又は暗号化フォーマットで格納可能である。
【0104】
更に、本出願の他の実装態様は、本明細書の考察及び本出願の教示の実行により当業者には明らかであろう。記載した実装例の様々な態様及び/又は構成要素は、単独、又は任意の組合せで使用され得る。明細書及び実装例は単なる例示として考慮されるものであって、本出願の真の範囲と精神は添付の特許請求の範囲に示されることが意図されている。
【符号の説明】
【0105】
101 拡張チャットアプリケーション
201 メッセージ
905 コンピュータデバイス
910 プロセッサ
図1
図2(a)】
図2(b)】
図2(c)】
図2(d)】
図2(e)】
図3
図4
図5
図6
図7(a)】
図7(b)】
図7(c)】
図8
図9