JP2010129093A

JP2010129093A - チャットとグラフィックスの同期オーサリングおよびアクセスのための方法

Info

Publication number: JP2010129093A
Application number: JP2009268502A
Authority: JP
Inventors: Eric Saund; サウンドエリック; Jaime G Ruiz; ジールイツジェイム; James V Mahoney; ブイマホニージェームス
Original assignee: Palo Alto Research Center Inc
Current assignee: Palo Alto Research Center Inc
Priority date: 2008-12-01
Filing date: 2009-11-26
Publication date: 2010-06-10
Anticipated expiration: 2029-11-26
Also published as: EP2192732A2; EP2192732B1; US8464167B2; EP2192732A3; US20100138756A1; JP5547461B2

Abstract

【課題】オンライン電子チャット環境においてユーザ間でより使い勝手がよくて充実した通信の提供を可能にする。
【解決手段】通信ネットワークにおいて互いに接続された複数の通信装置を備えるオンライン電子チャット環境において通信する方法であって、複数の通信装置の電子通信装置の表示画面９２４に、テキストを保持するチャット領域９０４およびグラフィックオブジェクトを保持するグラフィックス領域９０６を表示画面９２４の共通の電子キャンバス９０２に配置して表示し、チャット領域９０４からグラフィックス領域９０６にテキストを移動し、グラフィックス領域９０６からチャット領域９０４にグラフィックオブジェクトを移動する。
【選択図】図９Ａ

Description

本出願は、オンライン電子通信、特にチャットセッション形式による電子メッセージ通信の実行に関する。

通信チャネルによってクライアントワークステーションに接続されたチャットウェブサーバ上で、チャットルームの設定を可能にするオンライン電子メッセージ通信ソフトウエアが開発されている。２人以上のユーザ間のチャットセッションでは、ユーザはそれぞれリアルタイムでテキストベースのメッセージを送受信することができる。しかしながら、ユーザ間の通信をテキストベースのメッセージに制限すると、チャットルームユーザが通信を最大限活用することが制限されてしまうと考えられる。この問題に注目し、チャットルーム環境における通信体験の拡大を試みるコンセプトが提案されている。

例えば、２００８年４月１日付与の楠田の米国特許第７，３５３，２５４号「共同チャットシステム」では、ブラウズウィンドウのウェブページ上に直接表示するチャットウィンドウが開示されている。特に、チャットウィンドウ画面表示部により、ウェブページ内の構成要素や項目を示す位置にチャットウィンドウが表示される。２００７年５月２４日公示のトムプソンらの米国特許出願公開２００７／０１１６１９５号「異なる通信方法を統合するためのユーザインターフェース」では、メッセージの作成および送信用の統合通信インターフェースのコンセプトが開示されている。このインターフェースは、例えば電子メール、インスタントメッセージング、ＳＭＳ、チャット、音声など異なる通信方法間の切り替えを設定可能となっている。２００７年１０月１１日公示のデボイらの米国特許出願公開２００７／０２３９８２７号「グローバルチャットシステム」では、ユーザがウェブサイトを見ながらメッセージの送受信を行うことができるシステムについて記述している。２００７年１２月２７日公示のジョーンズらの米国特許出願公開２００７／０３００１６９号「チャットセッション内容にフラグを設定してトランスクリプトウィンドウ内の文章を強調する方法とシステム」では、ライブチャットウィンドウのトランスクリプト領域内の文字列の先頭にユーザが可視のフラグを設定可能なシステムを記述している。ここでは、視覚的なフラグをトランスクリプト領域に表示して関連する文字列を視覚的に表示し、更にライブチャットウィンドウを改良してユーザがフラグをナビゲートすることが出来るように構成している。２００８年２月７日公示のシウダドらの米国特許出願公開２００８／００３４０３７号「チャット環境におけるグラフィックユーザインターフェース出力の共有」では、チャット環境において共有可能なＧＵＩまたはアプリケーション出力について記述しており、ここではユーザがチャット内容の共有を選択および他のユーザとの共有を要求することが可能であり、共有された内容はチャットセッションの一部として送信内容に統合することが可能となっている。

その他のアプリケーションソフトウエアにおいても、例えばカリフォルニア州バークレーのシミュラット社のヴュー（Ｖｙｅｗ）に代表される非同期コラボレーション機能を備えたウェブ会議ツールなど、共有描画ウィンドウとチャットウィンドウを備えるコンセプトについて議論されている。

グループボード（ＧｒｏｕｐＢｏａｒｄ）は、カナダのアルバータ州ドラムヘラーのグループテクノロジー社が運営するオンラインＪａｖａ（登録商標）ホワイトボードおよびチャットソフトウェアである。１つの実施の形態では、グループボードは１組のマルチユーザＪａｖａアプレットであり、ウェブページ上に配置可能なホワイトボード、チャット、伝言ボード、ゲーム、インボイス会議を含む。グループテクノロジー社の他のソフトウエアとしてグループボードワールドネット（ＧｒｏｕｐＢｏａｒｄＷｏｒｌｄ．ｎｅｔ）があるが、これはユーザがホワイトボード、ボイス／ビデオ会議およびデスクトップシェアリングを備えたＷｅｂ会議室をセットアップすることが可能な高度なＷｅｂミーティング／会議ソフトウエアである。

アイスクリブル（ｉＳｃｒｉｂｂｌｅ）は地理的に離れた場所にいる人々が同時に描画作業を行うことが可能なオンライン描画サイトである。対話型のキャンバスによって、ユーザはマウスまたはグラフィックタブレットを使用して絵を描くことができる。他のシステムおよびプロセスとしては、ドイツのダルムシュタットのフラウンホーファー社（Ｆｒａｕｎｈｏｆｅｒ−Ｉｐｓｉ）が提供するコンサートチャット（ＣｏｎｃｅｒｔＣｈａｔ）がある。これは素材の共有を提供するテキストベースの通信である。コンサートチャット技術では、すべてのチャットユーザが任意の文書、ウェブページおよびスクリーンショットを共有して閲覧することが可能であり、また共同スケッチ作業用の共有ホワイトボードがサポートされている。サイトへの投稿はすべてアーカイブに保管する設定となっており、このため非同期議論、会話検索およびミーティングの後処理が可能となっている。

米国特許第７，３５３，２５４号明細書米国特許出願公開第２００７／０１１６１９５号明細書米国特許出願公開第２００７／０２３９８２７号明細書米国特許出願公開第２００７／０３００１６９号明細書米国特許出願公開第２００８／００３４０３７号明細書

このように、オンラインチャットシステムはユビキタスである一方、ユーザ間でより使い勝手がよくて充実した通信の提供を可能にする多くの改良が行われている。

本発明は、通信ネットワークにおいて互いに接続された複数の通信装置を含むオンライン電子チャット環境における通信方法を提供する。複数の通信装置の電子通信装置の表示画面には、テキストを保持するチャット領域およびグラフィックオブジェクトを保持するグラフィックス領域が表示され、チャット領域およびグラフィックス領域は上記表示画面の共通の電子キャンバスに配置される。テキストが上記チャット領域から上記グラフィックス領域に移動されることができ、また、グラフィックオブジェクトが前記グラフィックス領域から前記チャット領域に移動されてもよい。

図１はネットワーク構成を示す図である。図２は、本出願のシステムおよびプロセスを示す図である。図３はグラフィックオブジェクトのチャット領域への移動を示す図である。図４はグラフィックス領域へのテキストの統合を示す図である。図５は履歴移動を示す図である。図６はトグル処理を示す図である。図７はトグル処理を示す図である。図８はシステムとプロセスの異なる実行パスを示す図である。図９Ａ〜９Ｉはスクリーンショットを示す図である。図９Ａ〜９Ｉはスクリーンショットを示す図である。図９Ａ〜９Ｉはスクリーンショットを示す図である。図９Ａ〜９Ｉはスクリーンショットを示す図である。図９Ａ〜９Ｉはスクリーンショットを示す図である。図９Ａ〜９Ｉはスクリーンショットを示す図である。図９Ａ〜９Ｉはスクリーンショットを示す図である。図９Ａ〜９Ｉはスクリーンショットを示す図である。図９Ａ〜９Ｉはスクリーンショットを示す図である。図１０は半楽観的ロックのプロトコルを示す図である。図１１は非楽観的シリアライズのプロトコルを示す図である。図１２は楽観的シリアライズのプロトコルを示す図である。図１３は独立したグラフィックイベントの圧縮を示す図である。図１４は分岐機能を示す図である。図１５はシステムアーキテクチャを示す図である。図１６はグラフィックの編集操作を示す図である。

図１は、２人以上のチャット参加者またはユーザ１０２ａ〜１０２ｎが通信装置（またはクライアント）１０４ａ〜１０４ｎを操作する電子ネットワーク環境１００を示す。通信装置は、コンピュータ、携帯情報端末（ＰＤＡ）、携帯電話、電子式タブレットまたは他の通信装置であってもよい。

ユーザ１０２ａ〜１０２ｎは、通信装置１０４ａ〜１０４ｎによってインターネット１０６を通じてサーバ１０８と通信を行い、サーバ１０８はオンラインチャット通信の制御作動を行う。チャットを行うために、ユーザ１０２ａ〜１０２ｎはインターネット１０６または他のサーバ１１２を通してサーバ１０８へメッセージ１１０ａ〜１１０ｎのポスティングおよび受信を行う。すなわち、ユーザ１０２ａ〜１０２ｎは通信装置１０４ａ〜１０４ｎおよびインターネット１０６を通してサーバ１０８へメッセージを送信し、サーバ１０８はそのメッセージを他のユーザ１０２ａ〜１０２ｎへ届けることにより実質的にリアルタイムでの通信を実現する。通信装置（例えば１０４ｎ）は、接続ライン１１４によって、サーバ（例えば１０８）に直接接続してもよい。サーバ１０８は、接続ライン１１６で示すように他のサーバ１１２に直接接続してもよい。したがって、ユーザの通信装置１０４ａ〜１０４ｎをインターネット１０６によってサーバ１０８に接続する以外では、サーバ同士またはサーバ間はインターネット１０６または他の形式により接続してもよい。

本出願は、チャットユーザ間で他のマルチメディアの共有が可能な共通電子キャンバス上におけるテキストチャットの特徴およびアフォーダンス（ａｆｆｏｒｄａｎｃｅｓ）を提供する。提供するマルチメディアは、構造化グラフィックス、静止画像、オーディオクリップ、ビデオクリップ、描画アニメーションおよび合成アニメーション等をフリーフォームのデジタルインクを使って描画・編集する機能を含む（以後、「グラフィック」、「グラフィックス」「グラフィックオブジェクト」および「グラフィックオブジェクト（複数）」をしばしば使用するが、これらはマルチメディアに関する幅広い概念およびその概念が内包する内容を包含するものとする）。

テキストは電子キャンバスの１つの領域（例えばチャット領域）に入力され、グラフィックスは、例えば対話型のホワイトボードにおける同一の電子キャンバスの別の領域（例えばグラフィックス領域）で作成、編集またはその他の方法で提供されてもよい。チャットモード操作とグラフィックモード操作に区別はなく、ユーザは明確なモード切り替えなしでチャットまたは描画および／または編集動作をシームレスに経験することができる。

（スクロールによる）移動可能なタイムラインが提供されるため、テキストと削除箇所の同時スクロール（後方向）と、グラフィックスの再描画（前方向）により、履歴の閲覧またはチャットの再生を行うことができる。テキストおよびグラフィックスはテキストとグラフィックス領域間でコピーおよび／または移動することができる。グラフィックをテキスト領域に配置すると、時系列でみた場合にそのグラフィックはテキストと共にスクロールされるが、テキストをグラフィックス領域に配置した場合、テキストは静止状態となり、（例えば削除および再描画操作などによる）時系列的視点でみた場合にアクティブとなってもよい。したがって、本システム（例えばグラフィティチャット（ＧｒａｆｆｉｔｉＣｈａｔ））はハイブリッドチャット／共有ホワイトボード構造を有する。

図２のフローチャート２００において、まずシステムが起動される（２０２）。その後、チャット領域およびグラフィックス領域（例えばホワイトボード）を有するコンピュータ画面キャンバスが表示される（２０４）。システムがチャット／グラフィックスサーバなどのサーバに接続され、そこでユーザが認識される（２０６）。サーバはまた、ユーザのコンタクトリストにある各名前をユーザに提供し、当該ユーザの接続情報とコンタクトリストを含む一時ファイルを作成する。ユーザのコンタクトリストに記載されている人物がログインしたとサーバが判断すると、サーバはユーザコンピュータ上のクライアントに、ログインした人物の接続情報と共にメッセージを送信する。サーバはまた、ユーザのコンタクトリストに記載されている名前のなかでログインしているものに対して、当該ユーザの接続情報を送信する。クライアントがコンタクトリスト内のある名前の接続情報を得ると、その名前の状態が「オフライン」から「オンライン」に変化する。そしてユーザが、コンタクトリスト内の名前でオンライン状態のものをクリックすると、チャット領域およびグラフィックス領域を有する電子キャンバスを表示するウィンドウが開き、チャットテキストの入力と、グラフィックスの描画・編集の両方を行うことができるようになる（２０８）。

ユーザはキーボード入力によってテキスト形式のチャットを入力し、マウスまたはスタイラスコマンドや、キーボードの使用、スタイラス／マウス入力操作（２１０）およびキーボード入力動作受信（２１２）によってグラフィックおよびテキスト素材の描画・編集を行う。

ユーザインターフェースメソッドにより、キーボード入力がチャットテキストであるのか、またはグラフィックステキストオブジェクトであるのかが判断される（２１４）。この判断に基づいて、キーストロークに対応するチャットエントリが作成されるか（２１６）、またはキーストロークに対応するグラフィックテキストオブジェクトが入力される（２１８）（このプロセスは以下に詳細に説明する）。キーボード入力がチャットエントリであると判断されると、チャット入力の追加のために、チャット領域が必要な分だけスクロールされる（２２０）。

スタイラス／マウスからの入力を受信すると（２１０）、システムはスタイラス／マウス入力を、描画動作またはユーザが出したコマンド命令のいずれかであると判断する（２２２）。コマンドと判断されると、コマンドが実行される（２２４）。判断された入力（２２２）が描画動作である場合、作成されたグラフィックスが描画グラフィックスオブジェクトとして入力される（２２６）。

チャット領域（２１６）における各テキストチャットエントリ、グラフィックス領域（２１８、２２６）におけるグラフィックスまたはテキストオブジェクトに対する各操作、および実行された各コマンド（２２４）は、それぞれイベントとして登録され、そのようなイベントは、イベントを実行したユーザによるイベント実行時間によりタイムスタンプされる（２２８）。タイムスタンプされた各イベントはまた、イベント履歴リストに発生順に登録される（２３０）。その後、タイムスタンプされた登録イベントは、セッションの他の参加者に配布される（２３２）。

チャットとグラフィックスイベントに関連したタイムスタンプにより、キャンバスのチャットおよびグラフィックス領域の同期閲覧および再生機能が提供される。

図３では、キャンバス上のチャットおよびグラフィックスだけでなくこれらの２つの領域内のデータ間インタラクションについても図示する。プロセス３００では、スクロールするチャット領域にグラフィックオブジェクトを添付することができる。ユーザはマウスまたはスタイラスを使用してグラフィックス領域へ移動し（３０２）、グラフィックス領域のオブジェクトを識別・選択する（３０４）。ユーザは、シフトキーを使用して１つ以上のオブジェクト上でマウスボタンを左クリックすることにより複数のオブジェクトを選択し、１つ以上のオブジェクトをスタイラスでタップし、マウスまたはスタイラスを使用して１つ以上のオブジェクトを投げ縄ツールで囲み、そして／または１つ以上のオブジェクトを囲む選択矩形をドラッグしてもよい。一旦選択すると、ユーザはその選択したオブジェクトをマウスまたはスタイラスによって別の位置へドラッグする。選択したオブジェクトが所望の位置へドラッグされ、マウスボタンが解放またはスタイラスが持ち上げられると、この移動イベントがタイムスタンプされイベント履歴リストに登録される（３０６）。その後、オブジェクトがチャット領域にあるのか、またはグラフィックス領域にあるのかを判断するテストが行われる（３０８）。チャット領域にある場合、オブジェクトはスクロールオブジェクトとして認識され（３１０）、スクロールオブジェクトリストに置かれる（３１２）。グラフィック編集ツールが提供する編集機能によって、チャット領域にオブジェクトをドラッグする前にグラフィックス領域でオブジェクトの複写を行うことが可能である。オブジェクトがチャット領域に無い場合、そのオブジェクトは非スクロールオブジェクトとして認識される（３１４）。

図４では、プロセス４００によって示すように、チャットテキストエントリのコピーがキャンバスのグラフィックス領域にドラッグされる。ユーザはチャット領域に移動し（４０２）、チャット領域に現れたテキスト項目を識別・選択する（４０４）。一旦選択すると、ユーザは選択したテキストの一部上でマウスを押した状態でドラッグすることにより、ドラッグ移動を開始することができる。チャットテキストをドラッグする場合、オリジナルのテキストはそのまま残り、ドラッグ操作によって新しい複製が自動的に作成・配置される。マウスボタンの解放またはスタイラスの引き上げによりドラッグ移動が完了すると、複製イベントおよび移動イベントが共にイベント履歴リストに登録され、タイムスタンプされる（４０６）。ドラッグされたテキストがグラフィックス領域にあるのか、またはチャット領域にあるのかを判断するためにテストが行なわれる（４０８）。テキストがグラフィックス領域にあると判断されると、複写されたテキストオブジェクトはスクロールオブジェクトリストには配置されない（４１０）。複写されたテキストオブジェクトがチャット領域にあると判断されると、テキストはスクロールオブジェクトリストに追加される。

図５のプロセス５００は、チャット領域およびグラフィックス領域で発生するイベント間の時間同期を利用しており、この時間同期は、すべてのチャットおよびグラフィックス編集イベントがタイムスタンプされ、イベント履歴リストに登録されるために生じる。

ステップ５０２において、ユーザはタイムライン制御に対する操作を開始する。ユーザは、ポインタまたはカーソルをタイムバーまたはスクロールバーのタイムライン制御ハンドルの第１位置に配置し（５０４）、そしてポインタをクリックしてスクロールバーまたはタイムバー内の新たな位置へドラッグ、つまり、制御ハンドルを上方向または下方向へ移動、または時系列的な前方向または後方向に対応する他の方法で移動することができる（５０６）。あるいは、ユーザはポインタをタイムバーまたはスクロールバーの制御ハンドルの位置以外の位置に配置し（５０８）、そしてポインタをその位置から、つまり制御ハンドル位置から時系列的な前方向または後方向に対応する別の位置でクリックしてもよい（５１０）。いずれの場合も、タイムバーまたはスクロールバー上の現在位置は、時系列的な前方向または後方向に対応して、既存位置から移動する。これらの動作に基づいて、システムは新しい位置と、第１イベント（５１２）などのイベント履歴リスト上の前イベントからのイベント時間とを関連付けする。したがって、元のポインタ位置がチャットセッション開始から５分の位置であった場合、ユーザはタイムポインタを、例えばチャットセッション開始から３分の位置に移動することができる。この動作によって、システムはチャットセッション開始時からのイベント時間とタイムスタンプとを関連付けする（５１４）。システムは、開始３分の時点で発生したイベントのタイムスタンプをイベント履歴リスト内で検索し、ポインタ位置と関連付けされたものと同様のタイムスタンプを有するテキストおよびグラフィックスイベントを識別する（５１６）。システムは識別されたテキストを含むテキストを表示し、識別されたグラフィックスを含むグラフィックスを表示する（５１８）。

テキストとグラフィックスがタイムスタンプおよびイベント履歴リストへの記載によって同期しているため、タイムライン制御がチャット開始から３分の時点へ移動すると、システムはテキストチャットを識別し、スクロールされた会話をその時点へ移動して表示を行うことができる。同時に、同期によりグラフィックス領域において変更が生じる。例えば、時間を遡ってスクロールが行われると、グラフィックス部におけるイメージ生成、削除および移動イベントはグラフィックオブジェクトのタイムスタンプに従って元の未完状態に戻る。

スクロールが発生すると、どのテキストが画面から移動されたのかを判断するテストが行われ、まだ画面上に存在すると判断されたテキストのみが表示される。スクロールの上下動作が行われると、チャットキューまたはリストの一部だけがチャット側で可視となる。テキストが追加されるにつれて、システムはスクロールアップを行う。そしてユーザによりスクロールダウンされると、そのタイム枠に存在するものがスクロールバーによる選択により表示されて可視となり、そのタイム枠の範囲に無いものはすべて表示されない。グラフィック側からテキストチャット領域へオブジェクトが選択・移動されると、そのオブジェクトはもはやグラフィックス領域には存在しないことになる。また、チャット領域に移動されると、そのオブジェクトはスクロールリストに追加され、その移動動作時点で新しいタイムスタンプが付与される。

１つの実施の形態によると、グラフィックス領域では、ソーンドらの米国特許第７，０３６，０７７号で開示されているようないわゆるインクスクライブ（ＩｎｋＳｃｒｉｂｅ）システムや、ソーンドらの米国特許出願公開２００８／０２３２６９０号に記されているようなコンセプトスケッチ（ＣｏｎｃｅｐｔＳｋｅｔｃｈ）システムの推論型プロトコルのコンセプトを採用してもよい。グラフィックス領域で採用可能な他の編集システムとしては、スキャンスクライブ（ＳｃａｎＳｃｒｉｂｅ）として知られ、主として文書の画像編集を目的としたマウス／キーボードインターフェースがある。スキャンスクライブは、前景／背景分離、過負荷ループ選択、およびタップベース選択のための水平な束群またはラチスグループ（ｌａｔｔｉｃｅｇｒｏｕｐｓ）を提供する。このグループは、メニューコマンドの使用による手動形成、選択オブジェクトを一括操作する場合の自動形成、および編集メニューから呼び出された認識ベースのグルーピングコマンドによる自動生成の３つの方法であれば、どの方法においても形成することができる。

図６〜８は、例えばシステムがグラフィックの生成、表示および操作のためにインクスクライブ／コンセプトスケッチプロセスを使用する場合に、キーボードおよび／またはポインタエントリ機能をグラフィックス領域およびチャット領域において動作させるためのロジックフローを示す。

図６において、ユーザがグラフィックス領域にテキストを入力したい場合、まず「テキスト」と表示されたツールバーボタンを押すと（６００）、それまでの選択設定がすべて解除される（６０２）。次に、システムは、カーソル配置状態にあるかどうかを検知する（６０４）。カーソル配置状態にある場合、システムはインクスクライブ／コンセプトスケッチのペンアップ非選択状態へ移行する（６０６）。ペンアップ状態とは、インクスクライブ／コンセプトスケッチの標準推論型プロトコルであり、テキストまたはグラフィックス領域における単純な描画などの正常なペン操作であることを意味する。カーソル配置状態でない場合（６０４）、カーソル配置状態へ移行することができる（６０８）。したがって、ステップ６０４は本質的にトグルである。

カーソル配置状態とは、図７に示すようにマウスまたはスタイラスによる押圧がキャンバスに生じる場合に使われる（７００）。システムは、カーソル配置状態にあるかどうかを検知する（７０２）。カーソル配置状態でなければ（Ｎ）、システムはインクスクライブ／コンセプトスケッチの描画パス状態（非選択状態）へ移行する（７０４）。システムがカーソル配置状態であれば（Ｙ）、カーソルがマウスまたはスタイラスの位置に置かれる（７０６）。マウスまたはペンが押圧されると、プロセスはキャンバステキスト入力状態へ移行する（７０８）。つまり、現在のインクスクライブ／コンセプトスケッチ動作では、ユーザによるキーボード入力が行われると、システムは常にこの位置へ文字の配置を開始する。

図８では、キー押しがあると（８００）、システムがキャンバステキスト入力状態にあるかどうかを判断する（８０２）。イエス（Ｙ）の場合、プロセスは入力された文字がリターンマークかどうかを判断する（８０４）。リターンマークの場合（Ｙ）、カーソルをこのテキスト入力の第１文字位置の１行下に移動する（８０６）。ステップ８０４において文字がリターンマークでない場合、入力されたテキストが入力テキストコマンドかどうか判断するために、次の判定ブロックに移動する（８０８）。入力テキストコマンドは、例えば「Ｅｎｄ」キーまたは「Ｉｎｓｅｒｔ」キーの押圧であってもよい。テキストコマンドである場合（Ｙ）、イベントの登録およびタイムスタンプを含むグラフィックス領域上のテキストオブジェクトが完了するため、そのテキストオブジェクトは共有チャット／描画チャネル上で共有可能となる（８１０）。一旦完了すると、システムはインクスクライブ／コンセプトスケッチのペンアップ状態に戻る（８１２）。ステップ８１０のこの状態では、「テキストオブジェクト」はサーバに送られ、サーバはチャットセッションの他の参加者にこれを配布することができる。したがって、この末端分岐は、ユーザがグラフィックス領域にタイプされたテキストオブジェクトを入力している状況を示す。

ステップ８１０は、上記イベントの登録およびタイムスタンプコンセプトを含んでいる。本ステップおよび８００に示すその他のステップにおいて、本アプリケーションの実施の形態において生じるすべてのチャット、テキスト、グラフィックス入力および編集イベントは、図２に関連する説明に従ってタイムスタンプされ、イベント履歴リストに配置される。

ステップ８０８において、入力されたテキストがコマンド文字でない場合（Ｎ）、文字はグラフィックス領域のカーソル位置に入力され、カーソルが１文字分進められる（８１４）。その後、別のキー押しが入力されるまで、このプロセスがループの先頭へループバックされ（８００）、前述のようにステップ８０２へ移行する。

再びステップ８０２において、システムがキャンバステキスト入力状態でない場合（Ｎ）、言い換えれば、ユーザが単にチャットか描画かグラフィックス編集を行っている場合は、キー押しはユーザが単にチャット領域にテキストを入力していると判断される。この状態では、キー押しが行われると、入力された文字がリターンマークかどうかを判断するためにテストが行われる（８１６）。ノーの場合（Ｎ）、その文字はチャット領域の次の位置に入力される（８１８）。ステップ８２０において、システムは現在のチャットテキストラインが幅しきい値を越えて延長するかどうかを判断する（８２０）。延長する場合は、自動折り返しチャットテキストライン機能が実行される（８２２）。

しかしながら、ステップ８１６のリターンマーク照会において、文字がリターンマークであると判断された場合（Ｙ）は、ユーザがチャットエントリを終了したことを意味する。その後、ステップ８２４の一部として、チャットテキスト（つまりイベント）がタイムスタンプされ、イベント履歴リストに登録される。そして、ユーザによって登録されたイベントはサーバへ送られ、他のユーザに配布される（８２４）。

サーバから送られた別のユーザによるイベントはすべて、タイムスタンプを有する。イベントはユーザのローカルイベント履歴リストに登録され、そのイベントの示す動作が実行される。チャットイベントの結果、新しいチャットテキストオブジェクトが適切なスクロールによりチャット領域に入力される（８２６）。チャットテキストオブジェクトはスクロールオブジェクトリストに追加される。グラフィックス入力および編集イベントの結果、グラフィックまたはテキストオブジェクトの追加、移動、削除、または修正が発生する。このように、すべてのチャットおよびグラフィックスは、その配布を受けたユーザ間で同期される。

図６〜８におけるスタート地点では、システムによるユーザの入力待ちという共通の状態にある。各図は、ユーザの動作に応じて分岐した異なる処理ロジックを示す。図６は、ユーザが「テキスト」ボタンをクリックした時点でスタートする。図７のプロセスは、マウスまたはペンスタイラス等のスタイラスがチャット領域またはグラフィックス領域のどちらかのキャンバス自体に押圧された時点でスタートし、図８のプロセスは、任意のキー押しによりスタートする。図６〜８で図示する動作は、図２で示したステップ内に存在し、また図２のコンセプトは図６〜８の動作に内包される。

グラフィティチャットは、ハイブリッドチャット／共有ホワイトボードアプリケーションである。タイムラインにより、テキストと削除箇所の同時スクロール（後方向）と、グラフィックスの再描画（前方向）を行うことによって、履歴の閲覧またはセッション開始時からの再生を行うことができる。テキストと画像素材はテキストとグラフィックス領域間でコピーおよび／または移動することができる。チャット領域内のテキストおよびグラフィックスは共に時系列的にスクロールされるが、グラフィックス領域のチャットおよびグラフィックスは静止状態にあり、時系列でみた場合にアクティブとなる。

グラフィティチャット用のユーザインターフェース９００を図９Ａ〜９Ｉに示す。図９Ａにおいて、ユーザインターフェース９００は現在、チャット領域９０４を有する電子キャンバス９０２を表示しており、そこにはグラフィティチャットセッションの参加者が入力したテキスト行が含まれている。電子キャンバス９０２の右側に、グラフィックス領域９０６がある。グラフィックス領域９０６の現在の状態は空であるが、グラフィックス領域９０６は、一例としてフリーフォームのデジタルインク、構造化グラフィックス、静止画像、アニメーション画像、オーディオクリップ、ビデオクリップ、描画アニメーションおよび合成アニメーションなどを含むさまざまなグラフィックマルチメディアを収容するように設計されている。

グラフィックスおよびテキスト作成および／または編集操作では、インクスクライブ／コンセプトスケッチ描画エディタの推論型プロトコルを利用してもよく、他の明示型の図面／編集ユーザインターフェース手法を使用してもよい。「描画（Ｄｒａｗ）」、「選択（Ｓｅｌｅｃｔ）」および「スマート（Ｓｍａｒｔ）」の項目を有するボタンツールバー９０８により、ユーザは同一のインプリメンテーションにおいて推論型モードおよび明示型ユーザインターフェースプロトコルの両方へアクセスすることができる。「スマート」がチェックされていると、ユーザインターフェース９００はインクスクライブ／コンセプトスケッチの推論型プロトコルを使用し、「スマート」がチェックされていない場合、明示型描画プロトコルがアクティブとなる。

スクロールバー９１０は、タイムライン制御ハンドル９１０ａが存在する領域を規定し、スクロールバー９１０内の制御ハンドル９１０ａの移動によりセッション履歴の表示が制御される。ユーザがスクロールを行うと、チャットテキスト欄が下方向に進んでチャット領域に存在する過去のチャット項目（典型的にはテキストであるが、ボイスおよび／またはビデオクリップを含む）およびグラフィックオブジェクトが表示され、グラフィック作成および編集操作が巻き戻されて元の未完状態に戻る。制御ハンドル９１０ａを移動させることにより、セッションで発生したイベントを思いのままに後方向および／または前方向に表示できる。これは、チャットおよびグラフィックイベントがすべてイベント履歴リストに記憶されているため実現する。

「現在（ＮＯＷ）」ロケータアイコン９１０ｂは、現在表示されるチャットおよびグラフィックスの時刻歴における位置を示す。「現在」ロケータより下に表示されたチャット項目は、彩度の低い色で識別され、このチャットテキストが現在表示されている時点よりも未来のイベントであることを示す。

「プレイ」ボタン９１０ｃは、自動的にタイムラインを前方向へ進めることにより、テキストおよびグラフィックの編集動作から成るシーケンスを再生成する。

識別されたグラフィックオブジェクトをチャット領域９０４に移動し、チャットテキストに添付することにより、オブジェクトがテキスト欄（例えばチャット欄）９１２と共にスクロールされるようにしてもよい。グラフィックススクロール境界９１４は淡色のインジケータであり、グラフィック素材がチャット欄と共にスクロールされるキャンバスの一部を示す。

チャット領域からテキストを選び、選択されたテキストの複製をグラフィックス領域９０６へドラッグすることにより、テキストをキャンバスのグラフィックス領域９０６へ持ち込むことができる。選択テキストの複製は、グラフィックス領域に配置されると他のグラフィックオブジェクトと同様に動作する。これによりユーザは、チャットダイアログのなかの選択部分のみを、静止しているグラフィック領域へ持ち出すことができる。チャットの参加者はまた、テキストがグラフィックス領域にある場合にテキストを変更、例えば、一部をハイライトや太字に変更し、複製テキスト内の文字を追加または消去することができる。チャットをスクロールすることにより、時系列的に編成されたセッションダイアログが得られる。

タイムスクロールバーの操作により、チャット／グラフィックスセッションの時刻歴の閲覧が可能となる。グラフィティチャットの本システムおよびプロセスでは、検索語を検索ボックス９１６に入力するサーチウィジェットの使用によって、チャットおよびグラフィックス内容を履歴内でサーチすることができる。

チャットサーチで検出された各項目に関しては、サーチ項目が現在ロケータ９１０ｂの位置に表示されるように時刻歴が配置される。チャットスクロールとグラフィックスとの時間履歴同期のために、グラフィック画面は、あたかもサーチテキスト項目がユーザによってタイプされた時の状態で表示される。

また、サーチはグラフィックス領域においても可能である。ユーザはテキストまたはグラフィックオブジェクトを選択し、この素材の前回の編集または作成時をサーチするよう要求することができる。チャットスクロールとグラフィックスの時間履歴同期が取られているため、チャット欄はサーチされたグラフィック項目が描画、貼り付け、または修正された時の状態に配置される。

また、ユーザインターフェース９００はソーシャルネットワーキングツールバー９１８を備え、ソーシャルネットワーキングツールバー９１８は一例として「招待（Ｉｎｖｉｔｅ）」、「検索（Ｒｅｔｒｉｅｖｅ）」および「参加（Ｊｏｉｎ）」ボタンなどの様々なボタンを含み、ユーザのチャット参加への招待、ユーザ名のコンタクトリストにおける検索、ユーザのチャットルーム参加の許可などの機能を提供する。グラフィックス編集制御ツールバー９２０は、色、サイズ変更、ハイライト、回転、削除ボタンなど、グラフィックス領域９０６における編集を可能にする編集ボタンやその他の編集機能を備える。「テキスト」ボタン９２２により、ユーザはグラフィックス領域においてテキスト入力状態に移行することができる。このモードへの移行により、ユーザはキャンバスのグラフィックス部分にテキストを入力することができる。ユーザインターフェース９００の構成要素を、通信装置の表示画面９２４に表示する。図９Ａ〜９Ｉは、上記機能を実際に使用したシナリオについて説明している。

テキスト入力、イメージ作成および画像編集イベントは、ネットワーク上であるユーザから別のユーザへイベントして送信されるが、遅延時間を伴う可能性がある。多くの異なるプロトコルが開発されており、それぞれそれが独自のトレードオフを有する。３つの主なアプローチとして、図１０の「半楽観的ロック(Semi-optimistic locking)」、図１１の「非楽観的シリアライズ(Nonoptimistic Serialization)」、および図１２の「楽観的シリアライズ(Optimistic Serialization)」がある。図１０〜１２は、２人のユーザがテキストチャットをタイプしており、ほぼ同時にリターンキーを押すという状況をそれぞれ表わしている。

図１０は、即時入力および遅延整流により整合性のある結果を生成する半楽観的ロックプロトコルを示す。各ユーザのキーストロークは局所的に即時登録されるが、テキスト行が完成すると、完成したテキスト行がユーザ間の不整合性を解決するアービタ（サーバ）に送られ、どちらのユーザの入力が１番目で、どちらが２番目に表示されるかが決定される。各クライアントが画面を更新することにより、すべての画面が整合することになる。このプロトコルでは、一方のユーザの画面が、他方のユーザのメッセージを唐突に過去部分と思われる箇所に挿入する場合がある。

半楽観的ロックの最悪のシナリオとしては、チャット領域のテキストではなく、グラフィックス領域において、２人のユーザが同一のイメージオブジェクトを同時に選択し、その後、異なる方法でそれを修正しようと試みるといったような操作（例えば共有ホワイトボードのシナリオにおいて）で生じる。オブジェクトが選択されると、この情報をロックとしてサーバに登録し、他のクライアントがオブジェクトを選択することができないように他のクライアントに配布する必要がある。これは、複数ユーザ間で整合性のある状態を確保するための原理メカニズムである。しかしながら、２人のユーザがオブジェクトを同時に選択すれば、それぞれが局所ロックを得ることになり、両者がオブジェクトを変更することが可能になってしまう。後になって初めてサーバは両方のロックを受信し、どちらが有効であるか決定する。アービトレーションまたは仲裁を失ったユーザは、オブジェクトに対して既に何らかの動作を行っていたかもしれない。ロックおよびその後の動作が無効であったとサーバに通知を受けたユーザは、その動作を放棄しなければならない。

このプロトコルは、イベントをサーバへ送信、必要に応じて仲裁の実行、そして他のクライアントへの配布という観点で実行される。これらのイベントは一般に状態変更を表わし、場合によっては、全体的な整合性を維持するために、クライアントはローカルユーザーが行った動作を取消す必要がある。

図１１は、サーバを媒介とした入力を行う非楽観的シリアライズ動作を示し、遅延を伴うが整合性を有する結果が得られる。ソースクライアントを含むどのようなクライアントにおいても、動作はすべて登録される前に、サーバを経由する。ユーザＡおよびＢが同時にタイプし始めても、サーバが仲裁を行い、ユーザＡのエントリを１行目に表示し、ユーザＢのエントリをその下の行に表示する決定を行う。テキストは、キーストロークに応じて直ちに表示されるわけではなく、まずサーバを経由しなければならない。このプロトコルの現時点での問題は、遅延を引き起こす場合があることである。

図１２は、楽観的シリアライズを示し、これは持続的な入力が即時に可能であるが、整合性のない結果を生成する可能性がある。各ユーザのテキストは、各自のチャットウィンドウで直ちに登録され、一瞬後に到着する他のユーザのテキストは次の行に表示される。この手法では、２人のユーザの画面表示に不整合性が生じる可能性があるという問題がある。

次に、履歴の整合性について考える。１つの実施の形態では、時間は個別のチャットイベントと編集イベントにより規定される。ユーザがタイムラインスクロールハンドルを動かすことにより時間をさかのぼると、セッションの過去の状態に辿りつく。１つの実施の形態では、ユーザは、過去のチャットエントリまたは過去のグラフィック状態を修正することは許されない。

履歴の整合性は、実時間の観点からではなく、異なる時々に発生したイベントによって規定された時間境界として解釈される。例えば、ユーザが正方形を描画し、その後テキストチャットを入力した場合、その正方形は、セッションの最新の状態に関して過去に発生したことになる。しかしながら、チャットイベントは異なるオブジェクトであるので、この正方形の編集が禁じられるわけではない。

この考察によって、１つの実施の形態では、以下のオブジェクト編集戦略を採用している。これは、アプリケーションの現在の状態、および履歴スクロールによって遡る過去の状態の両方に適用される。したがって、グラフィティチャットの編集プロトコル戦略は以下を備える。
１．すべてのオブジェクトは、関連する最新の作成、変更および削除イベントによりタイムスタンプされる。これは、チャットイベントとグラフィックイベントの双方に適用される。
２．どのようなオブジェクトも、その時間履歴のどの時点においても選択可能である。
３．選択されたオブジェクトは、常にシステムのクリップボードにコピーすることができる。
４．選択されたオブジェクトは、時刻歴におけるその時点でのタイムスタンプが現在（最新）のタイムスタンプと一致する場合にのみ、修正（回転、移動、削除など）を行うことができる。言いかえれば、オブジェクトはその最新の編集からのみ修正することができる。
５．チャットオブジェクトは修正することはできないが、複写することができる。
６．移動、回転、削除、複写、貼り付けを含む任意の変更操作を行うと、時刻歴スクロールバーが直ちに現在時間に移動することになる。言いかえれば、操作により履歴を変更することはできないが、過去データから情報を検索して、現在時間において操作することができる。

別の実施の形態において採用するメカニズムでは、セッション履歴上の様々な時刻におけるグラフィック状態を、個々のグラフィックオブジェクトの収集物として記録するが、その状態をもたらした個別イベントについては廃棄する。これらの収集物はグラフィックス状態スナップショットと呼ぶことができる。これらのスナップショットはより狭いまたはより広い間隔で記録してもよい。

図１３は、１つの実施の形態における履歴ロールアップ状態のスナップショットシステムおよびプロセス１３００を示す。このプロセスが開始されると（１３０２）、イベントカウンタがイベントカウントをゼロにセットして（１３０４）、その後グラフィックイベントの発生を感知するために待機状態に移行する（１３０６）。一旦感知が行われると、感知されたグラフィックスイベント数が７（なお、上述のようにより狭いまたはより広い間隔を選択してもよい。）であるかどうかの問い合わせを行う。もし７つ未満のグラフィックイベントがあると判断すると、イベントカウンタを１追加し（１３１０）、グラフィックスイベントの感知ステップに戻る（１３０６）。ステップ１３０８において、感知イベント数が７であった場合は、イベント１〜７を含む簡潔なスナップショットが生成される（１３１２）。その後、イベント１〜７が廃棄され（１３１４）、スナップショットがシステムのメモリに記憶され、ユーザがタイムラインバーをスクロールする場合に検索可能となる（１３１６）。一旦スナップショットがメモリに記憶されると、ステップ１３０４に戻ってイベントカウンタをゼロにセットし、別のグラフィックスイベントのための待機状態に移行する。

テキストチャットエントリは連続したテキスト行からなるテキスト欄として表示され、その入力イベント自体を維持する必要がないため、キストチャットエントリをこのようにスクロールアップする必要はない。

イベント履歴をスナップショットにスクロールアップすると、履歴の時間分解能をスナップショットの間隔によって提供される分解能まで減少させる効果がある。

別の実施の形態では、セッションのスナップショットをその履歴の任意のポイントにて記憶、検索、分岐する機能を備える。これは希望時刻ポイントへスクロールを行い、その後、チャットとグラフィック状態を記録したファイルを保存することにより実現する。その後、この状態をスタート地点として別のセッションを開始することにより、履歴の分岐を効果的に実行にすることができる。図１４に示すように、セッションをその時刻歴における過去のポイントにおいて記憶し、その後検索・編集することにより、代替前方向シーケンスを作成することができる。これは分岐セッション履歴と同じものである。ここでは、キャンバスに円形オブジェクト追加する７つの編集イベントから成るシーケンスを作成する（１４００）。次に、ユーザは、時刻歴を後方向にスクロールし、４つの円形オブジェクトが存在する履歴状態のスナップショットから新しい分岐を開始する（１４０２）。最後に、ユーザは、この４つの円形オブジェクト状態から前方向へ移動する。この分岐において、ユーザは円形オブジェクの代わりにカラーの三角形オブジェクトを追加している（１４０４）。

別の実施の形態では、ユーザはプロが作成したグラフィックスや、芸能人等の有名人によるチャットセッションのコピーを購入する。グラフィックスは、ユーザがフェイスブック（Ｆａｃｅｂｏｏｋ）上で購入するビジュアル「ギフト」のように、限定数方式で提供されてもよい。グラフィティチャットでは、これらの有料グラフィックスは複雑で、ユーザの関心と人口分布を目標に設定され、限定的に販売される。付加価値として、このグラフィックスは単純な水平画像に限定されず、購入ユーザが有意義にカスタマイズ可能な構造化オブジェクトとして使用することができる。

さらに別の形態では、グラフィックコンテンツをユーザに提供するため、広告主および取引相手がグラフィティチャットの所有者に支払いを行う。

他のシナリオでは、グラフィティチャットのコンセプトに基づいて、一例として自分の筆跡などのカスタムフォントによるチャットテキストのタイプ機能をユーザに提供する。

以下では推論型プロトコルについて述べる。図１５はユーザインターフェース（ＵＩ）１５００のシステムアーキテクチャ概略図であり、ＧＵＩモジュール１５０２と認識モジュール１５０４の関係を示す。ＧＵＩモジュール１５０２は、キャンバス上のデジタルインクストロークの入力および表示、ならびにコマンドインタラクションロジックの大部分を処理するよう設計されている。ＧＵＩモジュール１５０２は、様々なプログラミング言語およびランタイム環境で実行可能であり、その環境は認識モジュール１５０４の環境と異なってもよい。認識モジュール１５０４は、コンセプトスケッチレコグナイザ（ＪＶＭ（Ｊａｖａバーチャルマシン）で実行可能）１５０４ａ、未処理ストロークキュー１５０４ｂ、処理済（判断）ストロークキュー１５０４ｃ、形式インターフェース１５０４ｄおよび手書きアクセスレコグナイザ１５０４ｅを含むスケッチ／図形／描画レコグナイザを備える。

認識モジュール１５０４は、単語、行、テキスト欄、グラフィックオブジェクトおよびノードリンクダイヤグラムモデルに基づいてユーザ入力記号を判断するよう設計されている。未処理ストロークキュー１５０４ｂは、ＧＵＩモジュール１５０２から電子インクストローク情報を得るよう設計されており、処理済ストロークキュー１５０４ｃは、認識モジュール１５０４からＧＵＩモジュール１５０２へ処理済ストローク情報を提供する。形式インターフェース１５０４ｄは２つのモジュール間のインタラクションパスを提供する。手書きレコグナイザは、タブレットＰＣ（ＴａｂｌｅｔＰＣ）オペレーティングシステムで使用するような、マイクロソフト株式会社の手書きソフトウエアであってもよい。

図１６は、前記コンセプトの実行を図示するハイレベルフローチャート１６００を示す。ステップ１６０２では、ＧＵＩモジュールはスタイラスやペンによる入力（例えばストローク）などのイベント待ち状態にある。ユーザがキャンバスの表面にペンを置くと、ＧＵＩモジュールはインクストローク１６０４を受信する。インクストロークの受信に際して、ＧＵＩモジュールは、インクストロークが（ｉ）インキング動作、（ｉｉ）タップ動作、（ｉｉｉ）囲み動作、または（ｉｖ）取り消し動作１６０６のどれに相当するのかを判断する。インキング動作はキャンバス上での書き込みまたは描画行為として判断される。タップ動作はキャンバスのある一点にスタイラスまたはペンを移動する行為であり、タップした項目の選択または選択解除を意味する。あるいは、項目が選択されている場合にキャンバスの背景でタップを行うことにより、その項目の選択が判断される。囲み動作は、他の既存のインクストロークまたは他の項目を囲むインクストロークであり、インキング動作または選択ジェスチャであってもよい。取り消し動作とは、既存のインクストロークまたは他の項目に対する、ジグザグ動作、前進後退動作、バツ印動作などによる書き込みおよび描画行為、またはその他「削除」系の動作である。このプロセスの一部において、囲み動作および取り消し動作はインキング動作または選択ジェスチャと判断される。

ステップ１６０８において、ストロークがインキング動作（つまり書き込みまたは描画を意図）かどうかの初期判断が行われる。ステップ１６０８では、以下のうちの１つが適合する場合、ストロークがインキング動作であると結論付ける。（ｉ）ストローク長が所定のサイズ未満であり、ストロークから所定距離内のキャンバス上にオブジェクトが存在せず、ストロークが前ストロークの終了（ペンの持ち上げ）から所定時間内に開始されている、（ｉｉ）ストロークはクローズパス形状を形成せず、ジグザグ（取り消し線）形状を形成しない、（ｉｉｉ）ストロークは、キャンバス上の他の素材を包囲しないクローズパス形状を形成する、または、（ｉｖ）ストロークはジグザグ（取り消し線）形状を形成するが、キャンバス上のストロークの所定距離内にオブジェクトが存在しない。

ストロークがインキング動作であるとプロセスが判断を下すと、ステップ１６１０に進んで、ストロークは未処理未加工ストロークキュー（例えば図１５の１０５４ｂ）に配置される。ストロークがインキング動作、またはタップ選択、囲み選択または取り消しコマンドジェスチャであるかが不明瞭な場合、ステップ１６１２に進んで、ストロークがタップ動作であるのか、または囲み動作、取り消し動作またはインキング動作のいずれかであるのかを判断する。ステップ１６１２では、ストローク長が所定のしきい値未満の場合、ストロークが前ストロークの終了（ペンの持ち上げ）から所定時間を越えて開始された場合、およびキャンバス上の少なくとも１つのオブジェクトがストローク位置から所定距離内にある場合、ストロークがタップ動作であると判断する。タップ動作であると判断すると（ステップ１６１２）、ステップ１６１４に移行し、対応するタップ選択コマンド（ここでは図示せず）関連動作を実行するために、レコグナイザモジュールにコマンドまたは信号を送る。ステップ１６１２において、タップ動作でないと判断されると、ステップ１６１６に進む。ステップ１６１６では、ストロークが囲み選択ジェスチャである可能性、または取り消し削除ジェスチャである可能性があるのかをストロークの形状に基づいて判断する。

ストロークが囲み選択ジェスチャである可能性があれば、「選択？」ボタンがユーザに表示される（１６１８）。つまり、囲み動作はシステムにとって不明瞭であり、システムは囲み動作がインキング動作（つまり書込みまたは描画）を意図しているのか、または選択ジェスチャを意図しているのかを判断できない。したがって、ステップ１６２０は、状況を明確にするためのユーザアクション収集位置に置かれている。より詳細には、ステップ１６２２において、ユーザが囲み情報に関連してスタイラスまたはペンを「選択？」ボタンに置けば、システムはステップ１６２４に進んで、囲み選択コマンドが認識モジュール（ここでは図示せず）に提供される。したがって、囲み動作は選択ジェスチャであることが分かる。その後、認識モジュールは、何が選択されたのかを判断する。認識モジュールは、例えば、囲み動作の対象または取り消しの対象を選択するか、または文字通り取り消しの対象または対象ではない認識されたストローク（または他の項目）に関するジェスチャの意図を判断することが可能である。ステップ１６２４では、ユーザはタップ選択操作を行なわず、キャンバスの背景にペンを配置したため、システムは囲み情報が単語または描画として意図されたと判断し、ストロークがステップ１６１０にてデジタルインクとしてキャンバスに追加される。

ストロークが取り消し削除ジェスチャである可能性がある場合（１６１６）、「削除？」ボタンがユーザに表示される（１６２６）。つまり、ストローク動作はシステムにとって不明瞭であり、システムはストローク動作がインキング動作（つまり書込みまたは描画）を意図しているのか、または削除ジェスチャを意図しているのかを判断できない。したがって、ステップ１６２８は、状況を明確にするためのユーザアクション収集位置に置かれる。ステップ１６３０で、ユーザがストロークに近接してオブジェクトに関連した「削除？」ボタンにスタイラスまたはペンを置くと、システムはステップ１６３２に進み、取り消し選択コマンドが認識モジュール（ここでは図示せず）に提供される。これは、インキング動作が削除ジェスチャであり、このジェスチャの対象となる項目が、認識モジュールおよびＵＩキャンバスから削除されることを示す。ステップ１６３０において、ユーザが「削除？」ボタンに対してタップ選択動作を行なわずに、キャンバスの背景にペンを置く場合、システムは取り消しストロークが単語または描画を意図することを示していると判断し、このストロークがステップ１６１０においてデジタルインクとしてキャンバスに追加される。

ステップ１６１０において、動作がインクストロークであると判断されると、インキング動作として識別されたストロークは未処理（未加工）ストロークキューに配置される。ステップ１６３４において、事前判断またはプロセスコマンドは、レコグナイザモジュールに送られ、未処理ストロークキュー内のストロークに対して「事前判断」および／または「プロセス」動作が行われる。ステップ１６０２〜１６３４で行なわれる動作は、ＧＵＩモジュール（例えば図１５の１５０２）で実行されると考えられる。ここで、認識モジュールは事前判断および／またはプロセスコマンドを実行する。ＧＵＩモジュールと認識モジュールがそれぞれの動作において一時的に非同期となるため、追加ストロークはこの間キャンバスに配置されてもよく、ＧＵＩモジュールは継続的に独立して作動する。

ステップ１６３６において、認識モジュールは、ＧＵＩモジュールによる「事前判断」または「プロセス」コマンドの発行待ち状態にある。コマンドを受信すると、認識モジュールの動作は判定ブロック１６３８に移動し、そこでコマンドが事前判断コマンドであると判断されると、ステップ１６４０に進む。そして、未処理ストロークキューの未加工ストロークはコーナー部分においてフラグメントへ分割される（この動作はより複雑なストローク用である。コーナー部分のない単純なストロークでは、この動作は必要ではない）。

ストロークフラグメントおよび／または単純なストロークは識別情報（ＩＤ）を付与され、処理済ストロークキュー１６４２に配置される。ＧＵＩ層１５０２ｙｊｒｍはステップ１６４６に進み、未加工ストロークが処理済ストロークキューのストロークフラグメントと交換される。ステップ１６４８において、ＧＵＩはすべてのストロークフラグメントをストロークＩＤと共に表または他のメモリ装置に追加する。一旦表または他のメモリ装置に入力されると、ストロークフラグメントはキャンバス上の未加工ストロークと交換される（ユーザはそのような交換を感知できない）。

ＧＵＩモジュール１５０２と認識モジュール１５０４間のストローク情報の初期送信において、ストロークフラグメントを構成する両情報（つまりｘ−ｙ位置および時間）が、ＩＤと共にＧＵＩモジュールへ転送される。こうして、レコグナイザモジュールとＧＵＩモジュールは、ストロークに関する同一の記憶情報を得る。

ＧＵＩモジュールからのコマンドが「事前判断」コマンドではなく「プロセス」コマンドである場合、ステップ１６３６からステップ１６４４へ進み、構造化認識動作が処理済のフラグメント化されたストロークに対して実行される。その後、（例えばオブジェクトとしての）ストロークがコマンド動作の対象に選択されるまで、構造化処理されたフラグメントは、認識モジュールにおいて維持されてもよい。

フローチャート１６００は、ストロークがインキング動作、タップ動作、囲み動作または取り消し動作かどうか判断するプロセス、およびそのような判断に基づいて実行される動作について概説する。上記のプロセスを使用することにより、ユーザは用紙やホワイトボードを使用する際と同じように直観的に、しかしながらコンピュータアプリケーションの能力と機能性を活用してノードリンクダイヤグラムを作成することが可能となる。

１００電子ネットワーク環境、１０２ａ〜１０２ｎユーザ、１０４ａ〜１０４ｎ通信装置、１０６インターネット、１０８，１１２サーバ、１１０ａ〜１１０ｎメッセージ、１１４接続ライン、９０２電子キャンバス、９０４チャット領域、９０６グラフィックス領域、９１０スクロールバー、９１０ａタイムライン制御ハンドル。

Claims

通信ネットワークにおいて互いに接続された複数の通信装置を備えるオンライン電子チャット環境において通信する方法であって、
前記複数の通信装置の電子通信装置の表示画面に、テキストを保持するチャット領域およびグラフィックオブジェクトを保持するグラフィックス領域を前記表示画面の共通の電子キャンバスに配置して表示し、
前記チャット領域から前記グラフィックス領域にテキストを移動し、
前記グラフィックス領域から前記チャット領域にグラフィックオブジェクトを移動する、方法。
請求項１に記載の方法において、
前記グラフィックス領域から前記チャット領域にグラフィックオブジェクトを移動させるステップは、前記移動されたグラフィックオブジェクトを前記チャット領域内のテキストリストに添付し、前記移動されたグラフィックオブジェクトを前記テキストリストと共にスクロールすることを含むことを特徴とする方法。
請求項１に記載の方法において、
前記テキストを前記チャット領域から前記グラフィックス領域に移動させるステップは、前記移動されたテキストを、編集可能な非スクロールテキストであると認識することを含むことを特徴とする方法。
請求項１に記載の方法において、
前記グラフィックス領域の前記グラフィックオブジェクトにタイムスタンプを提供し、
前記チャット領域に位置する前記テキストにタイムスタンプを提供し、
前記グラフィックオブジェクトのタイムスタンプと前記テキストのタイムスタンプとを同期させる、ことをさらに含むことを特徴とする方法。
請求項４に記載の方法において、
スクロールバーのタイムライン制御ハンドルを前方向および／または後方向に移動させることにより、ユーザがチャット領域に入力したテキストをスクロールすることをさらに含み、前記タイムライン制御ハンドルの前方向および／または後方向移動により前記テキストが前方向および／または後方向にスクロールされ、前記同期されたグラフィックオブジェクトは、前記グラフィックオブジェクトに同期される前記テキストの移動に対応して、前記グラフィックス領域内の前記キャンバスにおいて削除、追加および／または修正されることを特徴とする方法。