(57)【要約】記入シート表示部と、記入シート表示上に筆記される手書きデータを収集して複数の属性を付与するインク収集部と、前記手書きデータとその属性情報をネットワーク上のサーバに発信するデータ発信部とを有する端末装置で、安価な端末を用いて、より簡単な操作で電子メールを行うこと、通信料も抑えること、また、インターネットを活用した様々な用途に対応可能とすることができる。
2002101558.tif 000002
【特許請求の範囲】
【請求項１】
手書き入力が可能な記入シート表示部と、前記記入シート表示部上に筆記される手書きデータを収集し、複数の属性を付与する手書きデータ収集部と、前記手書きデータとその複数の属性情報をネットワーク上のサーバへ発信するデータ発信部とを備える端末装置。
【請求項２】
複数の属性を持つ手書きデータとその複数の属性情報を受信する手書きデータ受信部と、前記手書きデータを複数の属性情報に従って認識する認識部と、前記認識部の認識結果に従った処理を実施する処理部とを備えるサーバ装置。
【請求項３】
手書き入力が可能な記入シート表示部と、前記記入シート表示部上に筆記される手書きデータを収集して複数の属性を付与する手書きデータ収集部と、前記手書きデータとその属性情報をネットワーク上のサーバへ発信するデータ発信部とを有する端末装置と、前記手書きデータとその複数の属性情報を受信する手書きデータ受信部と、前記手書きデータを複数の属性情報に従って認識する認識部と、前記認識装置の認識結果に従った処理を実施する処理部とを有するサーバを備えた手書きで操作できるインターネットシステム。
【請求項４】
前記手書きデータ収集部は、タブレットから構成され、時系列の座標点データとして手書き筆跡を収集する請求項１〜３に記載の手書きで操作できるインターネットシステム。
【請求項５】
前記記入シート表示部を構成する液晶画面と、前記手書きデータ収集部を構成するタブレットは一体に構成されている請求項１〜４の手書きで操作できるインターネットシステム。
【発明の詳細な説明】
技術分野
本発明は、手元にある安価な端末装置を用いて、コマンドを手書きの筆跡データあるいは画像データとして送信し、遠隔地にある情報処理システムにより受信して処理を行う手書きで操作できる端末装置、およびそれを用いたインターネットシステムに関するものである。
背景技術
近年、携帯電話を用いた電子メールが急速に普及しつつあるが、小さくて、少ないキーを使ってメール文を作成するのは操作が難しい。こうした理由から、特開平１０−２６０９１６号に記載されているように、カメラを使って画像を取り込み、ペンを用いて上書きした後、サーバに送ってメール文を作成する方式が提案されている。
しかしながら、この公知例は、カメラ画像による入力のため、受信したメールに対して返信する操作も、一度、プリントアウトしたものを撮影してカメラ画像にし、それにペンで上書きし、元の画像とともに１つの画像にしてサーバへ送信しなければならない。このために、操作が複雑であり、元のメールのテキストデータも画像に落としたものを再度認識する必要があり、通信量が多くなる、サーバにおける画像処理の負荷が多くなる等の問題点がある。また、画像認識した結果を修正する手段がなく、誤認識の修正ができない。また、メール文だけでなく、携帯電話を用いた他の用途にも対応できていない。
本発明の目的は、安価な端末装置を用いて、より簡単な操作で電子メールを行うこと、通信料も抑えること、インターネットを活用した様々な用途に対応可能な手書きで操作できる端末装置、およびそれを用いたインターネットシステムを提供することである。
発明の開示
本発明は、手書き入力が可能で、複数の属性を表示可能な記入シート表示部と、前記記入シートの表示部上に筆記される手書きデータを収集し、複数の属性を付与する手書きデータ収集部と、前記手書きデータとその複数の属性情報をネットワーク上のサーバへ発信するデータ発信部とを備えたものである。
さらに本発明は、複数の属性を持つ手書きデータとその複数の属性情報を受信する手書きデータ受信部と、前記手書きデータを複数の属性情報に従って認識する認識部と、前記認識部の認識結果に従った処理を実施する処理部とを備えたものである。
さらに、本発明は、手書き入力が可能で、複数の属性を表示できる記入シート表示部と、前記記入シート表示部上に筆記される手書きデータを収集して複数の属性を付与する手書きデータ収集部と、前記手書きデータとその属性情報をネットワーク上のサーバへ発信するデータ発信部とを有する端末装置と、前記手書きデータとその複数の属性情報を受信する手書きデータ受信部と、前記手書きデータを複数の属性情報に従って認識する認識部と、前記認識装置の認識結果に従った処理を実施する処理部とを有するサーバとを備えたものである。
発明を実施するための最良の形態
以下、本発明の第１の実施例を第１図ないし第１７図に沿って説明する。
第１図は、本発明のシステムの全体構成図であり、端末１および端末２は、携帯端末であって、最寄の基地局を介して無線でネットワークに接続され、サーバも、ネットワークに接続している。
端末１を構成する記入シート表示部７は、液晶などのような表示機能を持ち、アプリケーション部５からの指令を受けて、手書きデータを記入したり、また、手書きデータのタ認識結果に対する修正を受け付けるためのシートを表示し、その表示シート上に筆記された手書きデータに複数の属性を与える。属性とは、たとえば、メールアプリケーションであれば、あて先、件名、メール文内容である。
インク収集部１は、手書きデータを収集する装置として動作し、タブレットから構成され、時系列の座標点データとして、手書き筆跡を収集する。記入シート表示部７の液晶画面とインク収集部１のタブレットは、一体化していると操作性の点で望ましい．
インク圧縮部２は、収集した手書きデータを圧縮する。圧縮の方式としては、特開平１１−９６３０１、特開平１０−２１４３１２に記述されている文字認識のための近似方式を用いることが可能である。
データ発信部３は、収集した手書きデータを圧縮したデータと記入シート表示部７により付与された複数の属性とを対応づけし、イベントｉｄ、端末ｉｄとともに、サーバに向けて発信する。
アプリケーション部５は、イベントｉｄを発行し、ユーザからのコマンドを受け付けたり、あるいは、データ受信部６からの信号を受けて所定の処理を実行し、インクデータをサーバにより処理する必要があれば、記入シートを表示するように記入シート表示部５に指令を出す。データ受信部６は、手書きデータの認識結果である候補つき文字列を受信する。
一方サーバを構成するインク受信部８は、収集した手書きデータを圧縮したデータと記入シート表示部７により付与された複数の属性とを対応づけたデータを、イベントｉｄ、端末ｉｄとともに受信する。また、すでに受け取ったイベントｉｄと同じならば、確認修正に関する処理であると認識し、もし、“実行命令”であれば確認修正待ち管理部１３にその信号を届ける。端末ｉｄは、ユーザｉｄでも良い。
インク管理部１４は、インク受信部８が受信したデータを、イベントｉｄ、端末ｉｄ手書きデータを圧縮したデータと記入シート表示部７にわけて、手書きデータをインク管理部１４に渡し、複数の属性を認識・解析し、その結果を処理動作部１１２へ渡す。イベントｉｄ、端末ｉｄは、これに関する処理中は保存しておく。
インク伸長部１３は、インク圧縮部２の処理の逆変換をするように圧縮したデータを伸長する。もし、インク圧縮部２が文字・パターン認識・解析部９の近似方式を用いていれば、インク伸長部１３は、不要である。
文字・パターン認識・解析部９は、手書きデータを受け取って、辞書１０−ｎを参照しながら、文字・パターン認識する．詳しくは、特開平１１−９６３０１、特開平１０−２１４３１２に開示されている。このとき、インク管理部１４によって手書きデータと分けられた属性を用いて認識しても良い。たとえば、時刻の入力属性であれば、数字の辞書のみを参照するようにすると、認識率を上げることができる。
辞書１０−ｎは、ユーザｎによる手書きデータを認識するのに参照する文字認識用の辞書であって、あらかじめ文字コードと文字パターンとを対応づけて用意しておく。また、ユーザは、所属グループｉｄを持つことができ、同じグループはグループ辞書を共有することができる。
認識・解析した結果により処理動作部１１は、文字・パターン認識・解析部９から手書きデータの認識結果を受け、インク管理部１４からその属性を受けて、所定の処理を行う。メールアプリケーションであれば、あて先、件名、メール文内容にしたがって、メール文を発送する準備を行い、確認修正待ち管理部１３に退避して、イベントｉｄとともに確認修正データをデータ送信・返信部１２を介して端末１の送信する。
確認修正待ち管理部１３は、認識・解析結果により処理動作部１１から所定の処理の準備を受け入れて、イベントｉｄとともに保持し、タイムアウトまたは同じイベントｉｄによる準備の再退避があれば以前の退避内容を破棄し、同じイベントｉｄによる実効命令があれば、これを実行する。
第２図から第４図は、端末１の処理フロー、第７図から第１１図は、その操作画面の例である。第２図は、端末の全体フローであるが、手順１−１により第図７（１）のようにメール作成メニューを受付けると、手順１−２で、記入シート表示部７により、第図７（２）のようにメール作成画面を表示する。手順１−３で、インク収集部１により、第図７（３）のように手書きデータの記入を受け付ける。画面が小さくて書ききれない場合は、第７図（４）のようにスクロールバーを使って、書き足していく。第８図のように、ページを切り替えて記入を受け付けるか、記入受付部と表示部をわけて操作画面を設計しても良い。ここでは、サーバで認識させたい文字を枠の中に１文字づつ書き込むことにより、文字の区切りを指定しているが、特開平１０−２６０９１６号のように、枠のないところに文字記入を受け付けて、サーバで認識する際に文字の区切りを認識する方式でも良い。
手順１−４では、第７図（４）のように所定のボタンをユーザが押すことにより、作成終了コマンドを受け付ける。手順１−５では手順１−３、手順１−４と平行して、データを送信する。
第３図は、手順１−３の詳細処理である。手順１−３−１では、手順１−４にうつる作成終了かどうか調べる。手順１−３−２では、ペンダウンがあるまで手順１−３−１に処理を戻す。
手順１−３−３では、前回ペンダウンと同じ領域にあったかどうかを調べる。領域とは、第７図（２）のあて先領域、件名領域、内容領域、また、文字枠領域などである。同じ領域であれば、１つの文字としてサーバで認識できるように手順１−３−４をスキップし文字の切り出し記号を入れず、同じ領域でなければ、手順１−３−４で文字の切り出し記号を入れる。手順１−３−５では、時系列の座標点データとして筆跡データを収集することを、手順１−３−６でペンアップがあるまで続ける。
第４図は、手順１−５の詳細処理である。手順１−５−１で、手順１−４にうつる作成終了までの筆跡データをすべて送信終了したかどうかを調べ、終了していなければ、以下の手順を実施する。手順１−５−２で、インク圧縮単位かどうかを調べる。インク圧縮単位は、切り出し記号ではさまれた単位であるが、ペンアップまでをその単位としても良い。
手順１−５−３で、インク圧縮部２により、インク圧縮を行う。手順１−５−４で、未送信のデータ量がパケット単位かどうか、１回のパケット容量と比較し、上回っているか、あるいは、上回っていなくとも、作成終了コマンドが発行された最終データであれば、未送信のデータの頭のほうからパケット容量分を切り出して、手順１−５−６でパケット化し、手順１−５−７で、送出する。
手順１−５は、筆記データ収集と平行して処理を行うと、その間、サーバでの処理を進めることができ、手順１−４のあと、手順１−６に移るまでの待ち時間を減らす効果がある。通信事情により、パケット間のタイムアウトが設けられている場合は、手順１−５−７は手順１−４のあとまとめて実行しても良い。
手順１−６で、データ受信部６により、サーバから、認識結果である候補つきテキストメールを受信し、手順１−７では第９図のように表示する。
手順１−８は、手順１−７で表示した内容に対して、第９図（４）のようにユーザがＯＫボタンを押したかどうかを調べ、ＯＫであれば、手順１−９で、サーバにＯＫ信号を送信する。
手順１−８でユーザがＯＫボタンを押さず、他の領域にペンダウンがあれば手順１−３に戻り、手書きメールの作成を受け付ける。たとえば、第９図（２）では、認識結果が違うときには、ユーザがその文字をペンタッチすると、認識結果の第２候補以下を表示し、ユーザがペンアップした位置に表示している候補を正しい認識結果として入れ替える。また、定型句として処理した場合は、１パターンの認識結果として複数文字が返される場合も同図（３）のように、表示する。
第１０図は、認識結果に正しい文字がなく、再度書き直す操作を受け入れるための操作画面表示である。（１）のように候補文字の中に、書き直し受付メニューを含めておき、それをペンタッチすると、（２）（３）のように手書きデータ収集画面を表示して、手書きデータを収集する。文字書き間違えた場合は、クリアメニューを押してクリアできるようにする。また、筆記終了後は、（４）のように認識ボタンを押す操作とする。
手順１−３で筆跡データを収集したものは、手順１−５により、サーバに送り、手順１−７では、第１０図（５）のように表示すると操作性を向上できる。そのためには、イベントｉｄの返信の、何番目の文字かの情報も手書きデータに添付する必要がある。また、サーバでは、このインクの認識処理後は、確認修正待ち管理部に保持してあるデータの該当部分を新しい認識結果に更新しておく。
操作の別の例として、第１１図を示す。メール文章の２文字以上を編集したい場合には、その文字列部分の指定を（１）のようにペンタッチする操作で受け付け、反転表示等で強調する。そして、（２）のように、削除、コピー、挿入、ＵＮＤＯの処理を受け付ける。削除、コピー、ＵＮＤＯであれば、その動作を実施する。挿入であれば、（３）〜（５）のように、手書きデータを受け付ける。手書き終了後は、手書きデータをサーバの送信するが、サーバで処理中は（６）のように表示しておくと良い。手順１−７では、第図９（１）のように認識結果を表示する。
この操作は、修正処理ではなく、受け取ったメールに対して行われる編集の場合もあり、この場合は、候補付きの文字列様式ではない。この場合は、新たにイベントｉｄを発生し、手順１−５でデータを送信する場合に、編集されない文字列メール部分をインクに添付して、サーバに送信する。
第５図、第６図は、サーバの処理フローである。
第５図の手順２−１は、インク受信部８により、手書きデータを含むデータを受信する。手順２−２で、インク管理部１４により、受信したデータを、イベントｉｄ、端末ｉｄ手書きデータを圧縮したデータと記入シート表示部７にわけて、手書きデータをインク管理部１４に渡し、属性を認識・解析結果による処理動作部１１２渡す。
手順２−３で、インク伸長を行うが、端末でのインク圧縮方式がサーバでの文字認識の近似方式を採用していれば、省略しても良い。伸長方式では、端末での圧縮方式の逆変換をする必要から、端末からサーバにインク圧縮方式を知らせる必要がある。
手順２−４で、文字・パターン認識・解析部９、辞書１０−ｎ、認識・解析結果による処理動作部１１により、文字切り出し記号で切り出されている文字ごとに、文字認識を行い、その結果の処理動作を得る。
手順２−５で、確認修正待ち管理部１３により、手順２−４で得た処理動作を、確認修正待ち管理部１３内にイベントｉｄとともに登録する。もしすでに、同じイベントｉｄにての登録があれば、これを今回のものと入れ替える。
手順２−６で、確認修正待ち管理部１３により、手順２−４で得た処理動作の確認修正データを端末１に返信する。
手順２−７で、先に返信した確認修正データの返信として、ＯＫ信号が戻ってくれば、手順２−８で、退避したイベントｉｄに関する処理を実行する。手順２−７で、先に返信した確認修正データの返信として、ＯＫ信号以外が戻ってくれば、手順２−１に戻って、修正を受け付ける。
第６図は、インク受信２−１の詳細フローである。第４図に示した端末側のデータ送信フローに対応して、パケットで受信する。手順２−１−１でタイムアウトかどうか調べる。前回最終回以外のパケットを受け取ってから所定時間過ぎたものは、何らかの問題によって、そのイベントｉｄの処理が中断されたものとして、手順２−１−７の異常処理を行う。そのイベントｉｄの処理を中断し、確認修正待ち管理部１３にての記録を消去することで、サーバ側の負担を少なくする。
手順２−１−２で、パケットを受信し、手順２−１−３で送りもとの端末ｉｄとイベントｉｄを識別し、手順２−１−４でこれ用のデータバッファにデータを保存する。手順２−１−５でイベントｉｄの最終パケットを受けたかどうか調べ、受けていれば、処理を終了し、そうでなければ、手順２−１−１に戻る。
第１２図は、１パターンを筆記することで、複数文字からなる定型句２変換するための処理を行うための、定型句サーバのシステム構成図である。第１図のサーバの構成と異なる部分のみをここに示しており、その他は、第１図と同様である。
文字・パターン認識・解析部９は、手書きデータを受け取って、辞書１０−ｎ−１を参照しながら、文字・パターン認識する．認識結果が、定型句コードであれば、それを、定型句変換１１−１に送る。
辞書１０−ｎ−１は、ユーザｎによる手書きデータを認識するのに参照する文字認識用の辞書であって、あらかじめ文字コードと文字パターンとを対応つけて用意しておく。また、ユーザは、所属グループｉｄを持つことができ、同じグループはグループ辞書を共有することができる。また、定型句辞書１０−ｎ−２は、ユーザｎによる定型句処理するのに参照する定型句の辞書であって、あらかじめ定型句コードと複数の文字列からなる定型句とを対応つけて用意しておく。また、ユーザは、所属グループｉｄを持つことができ、同じグループは定型句のグループ辞書を共有することができる。
アプリケーション１１−４は、端末からの処理要請を行うが、第図７（１）で指定されたアプリケーション指定を受けて、動作する。たとえば、メールであれば、文字・パターン認識・解析部９の結果から、候補つきメール文を作成する。また、定型句登録の場合は、定型句登録１１−２に処理を移し、辞書１０−ｎを次のように編集する。
定型句の手書きパターンと文字コード以外のまだパターンが割り当てられていない定型句コードを発生し、辞書１０−ｎ−１に、手書きパターンと定型句コードを登録する。また、定型句辞書１０−ｎ−２に、先の定型句コードと、定型句の文字列を登録する。
コラボレイティブ学習１１−３は、グループ辞書１０−４を編集しており、同じグループに所属しているメンバーの辞書１０−ｎ−１や定型句辞書１０−ｎ−２を調べて、辞書１０−４−１や定型句辞書１０−４−２を更新する。たとえば、メンバーのうち２人以上が同じ登録を辞書にしたとすると、グループ辞書１０−４にその記述を移し、他のグループ員もこの記述を利用したサービスを受けられるようにする。
ここでグループとは、ユーザの属性が定義されている時の同じ属性を持つユーザの集まりを意味し、属性とは、所属学校、勤務地、性別、年齢、嗜好、経験、職種などであり、または、これらを層別にしたものである。例えば、年齢を５歳きざみにする、嗜好をビジネス／学校／娯楽／その他の４種に大別するなどである。ユーザが定義した属性以外に、第１２図に示したコラボレイティブ学習１１−３により、ユーザ辞書間やユーザが定義した数種の属性間で相関が高いユーザ同士をグループとして定義付けることにより、定型句変換の機能を上げるなど、端末側で受けるデータをユーザが期待したものに近づけることができる。
第１２図に説明したシステムの定型句サービスを受ける場合の、端末側の動作フローを第１５図、第１６図に、操作画面の例を第１３図、第１４図に示す。
第１５図手順３−１で、定型句登録メニュー受付をし、第１３図（１）のように、手順３−２で定型句登録画面を表示し、手順３−３で登録情報を受け付ける。登録情報は、定型句の手書きパターンと、定型句の文字列であるが、サーバの文字認識を受ける前提で、文字列も手書き筆跡で記入すると良い。また、文字列は、手書き筆跡でなく、他の文章からのコピーを貼り付けることで直接文字列を記入する方式でも良い。
手順３−５は、第２図の手順１−５と同様である。第１５図手順３−１で作成終了コマンドを受け付け、サーバでの処理後、手順３−５で第１３図（２）のように候補付き定型句を表示する。修正の受付は、メール文作成の場合と同様である。
第１６図は、定型句の一覧を参照するための端末処理フローである。手順３−１０で、定型句一覧メニュー受付をし、第１３図（３）のように、手順３−１１で定型句一覧画面を表示し、手順３−１２で終了を受け付ける。登録情報は、サーバに一覧参照データを送るよう依頼し、サーバでは、その情報を端末に送る。
第１４図は、コラボレイティブ学習１１−３によるサービスの例である。同じグループに属するユーザが、端末１、端末２、端末３を用いており、端末１、端末２のユーザが、同じ内容で定型句登録すると、端末３のユーザも、自分では登録せずに、その登録情報を利用できる。
次に、本発明の第２の実施例として、第１８〜第２７図に沿って携帯電話を用いたテレビの録画予約サービスを説明する。第１７図は、その実施例のシステム全体構成図である。端末１、サーバは、第１の実施例と同じ構成である。端末２−２は、ビデオと一体型になっており、ビデオの機能のほかに、データ受信部２０、録画予約部２１、データ発信部２２からなる。サーバから端末２−２に、所定の命令フォーマットにて、録画すべき番組情報を送る。データ受信部２０は、その録画すべき番組情報を受けて、録画予約部２１に渡し、録画予約部２１は、録画予約を行う。エラーなしで予約が完了すれば、テータ発信部２２より、その旨のメッセージをサーバに発信する。サーバでは、それを受けて、端末１に送ると、ユーザには、完了がわかり安心できる。端末２−２から、直接端末１にエラーなしメッセージを送っても良い。もし、録画予約ができなければ、テータ発信部２２より、その旨のメッセージをサーバに発信する。サーバでは、それを受けて、端末１に送ると、ユーザは、予約情報に誤りがないか確認できる。
第１９図は、番組予約サービスをするための詳細なサーバのシステム構成図である。第１図のサーバの構成と異なる部分のみをここに示しており、その他は、第１図と同様である。
文字・パターン認識・解析部９は、手書きデータを受け取って、辞書１０−ｎ−１を参照しながら、文字・パターン認識し、番組情報一致度算出部１１−１に送る。
辞書１０−ｎ−１は、ユーザｎによる手書きデータを認識するのに参照する文字認識用の辞書であって、あらかじめ文字コードと文字パターンとを対応つけて用意しておく。また、ユーザは、所属グループｉｄを持つことができ、同じグループはグループ辞書を共有することができる。また、番組履歴１０−ｎ−２は、ユーザｎによるこれまでの録画予約番組情報を保持してある。また、ユーザは、所属グループｉｄを持つことができ、同じグループは定型句のグループ辞書を共有することができる。所属グループｉｄは、ユーザ本人の選択により定めても良いし、これまでの番組履歴情報をもとに、分類カテゴリを定め、これにより定めても良い。番組情報一致度算出部１１−１は、文字認識の結果から、該当する番組を番組情報１０−５から探し、文字認識の一致度、これまでの番組履歴との一致度をもとに、番組の一致度を算出する。番組名の一部しか指定されない場合も、番組名の一部と一致していれば、一致文字数が多いほど、一致度が上がるようにすると、うろ覚えの番組名からも番組指定することができる。これまでの番組履歴にある番組と、同じ曜日、同じ時間、同じシリーズであれば、一致度が上がるように定める。
番組情報リスト管理１１−４は、番組情報一致度算出部１１−１の結果を元に、一致度の高い順にリストを作成し、これの録画予約処理を行うべく、確認修正待ち管理部１３に処理データを退避する。
番組履歴登録は、端末２−２から予約ＯＫのメッセージが返されたとき、番組履歴１０−ｎ−２にその番組情報を登録する。
コラボレイティブ学習１１−３は、グループ辞書１０−４を編集しており、同じグループに所属しているメンバーの辞書１０−ｎ−１や番組履歴１０−ｎ−２を調べて、辞書１０−４−１や番組履歴１０−４−２を更新する。たとえば、メンバーのうち２人以上が同じ番組を録画予約にしたとすると、グループ辞書１０−４にその記述を移し、この番組の予約をしやすいようにする。あるいは、お勧め番組を端末から尋ねられた際に、この情報を提供する。
第２０図は、端末１の処理フローを、第１８図はその操作画面の例を示す。第２０図は、端末の全体フローであるが、手順４−１により第１８図（１）のように番組予約メニューを受付けると、手順４−２で、記入シート表示部７により、第１８図（２）のように番組予約画面を表示する。
手順４−３で、インク収集部１により、第１８図（３）のように手書きデータの記入を受け付ける。画面が小さくて書ききれない場合は、第７図、第８図に説明したのと同様である。
手順４−４で、第７図（４）のように所定のボタンをユーザが押すことで、作成終了コマンドを受け付ける。
また、手順４−５から手順４−９までも、第１の実施例と同様にでき、手順４−７で候補付き録画表示の例を第１８図（４）に示す。
第２１図はサーバの処理フローである。手順５−５を除いては、第５図による第１の実施例と同様である。手順５−５で、第１９図番組情報リスト管理１１−４により、ユーザが予約したい番組の順位を定める。
端末で、音声ガイドによる処理例を第２２図、第２３図に示す。第２３図は、端末の処理フローである。手順６−１でサーバから該当番組蟻の返信がくるまで、手順６−２から手順６−５を繰り返す。番組を特定するための属性情報として、日付、時間、番組名、チャンネル名、Ｇコードがあるが、音声ガイドに従って、ユーザの入力を受け付ける。入力なしで、次の属性に移っても良い。処理６−２で、第２２図（２）（３）のように、音声で、「何日ですか」など、入力要求する。手順６−３で、手書きデータを受け付け、手順６−４で、その属性に関する記入終了を受け付ける。手順６−５では、手書き筆跡データと、その属性とイベントｉｄとをサーバへ送信する。
手順６−１でサーバから該当番組ありの返信がくると、手順６−６で、候補付き録画予約受信をし、手順６−７で第２２図（４）に示すように候補付き録画予約表示する。「次」のメニューを押すと次の候補が表示されるようにする。
第２４図は、第２の実施例を、カメラ画像を用いて行う、第３の実施例のシステム構成図である。第２の実施例との違いは、端末１−２が、カメラおよび画像処理部からなることである。
第２５図は、第３の実施例のサーバのシステム構成図である。端末１−１は、画像カメラからなっており、実施例１のインク収集部１のかわりに、画像取り込み部１を有しており、詳細は、特開２０００−７６４１５に公開されている。端末で収集された画像は、サーバに送られて、第図２６または第２７図に示す手順により該当番組を識別し、その後は、第２の実施例に示した手順により番組録画予約を実施する。
第２６図は、サーバの処理フローであり、文字認識を行って処理する方式である。手順４−１で画像を受信し、手順４−２で画像の中から認識すべき文字列画像を抽出する。手順４−３で端末で圧縮した方式の逆変換である画像伸長を行うが、圧縮方式によっては、手順４−２と手順４−３は、逆転しても良い。手順４−４で文字列から１文字づつ切り出し、手順４−５で文字認識する。手順４−６で文字認識の結果から第２４図番組情報１０−５を参照し、文字列がどの番組であるかを識別する。
第２４図において、番組情報１０−５は、日付、時間、チャンネル、番組名などの属性データを持った文字列データで番組を登録してある。文字認識の誤認識も考えられるため、候補は複数あっても良い。手順４−７で確認修正待ち登録を行い、手順４−８で端末側に、候補番組を送る。手順４−９で端末側からＯＫコマンドがくれば、手順４−１０で手順４−７で確認修正待ち登録した内容を実施する。すなわち、実施例２と同様に番組を予約する。もし、手順４−９で端末側からＯＫコマンドがこなければ、手順４−１に戻って再度処理を行う。
第２７図は、サーバの別の処理フローで、文字認識を行わず、画像マッチングで処理を行う。このときは、第２４図番組情報１０−５は、特定のフォーマット、フォントによる画像データであって、手順４−１から手順４−３まで同様に処理を行った後、画像にて番組を識別する。
第２８図は、実施例において、端末からサーバに送られるデータの構造図である。第２９図は、サーバによる認識結果である、候補付きメール文のデータ構造図である。これにより、第５図のような認識結果の表示を行うことができる。
第３０図は、第１１図のように候補のないテキスト文に手書きで筆跡を記入したデータの構造図である。
第３１図は、ＴＶの番組予約を行う手順を説明するためのフローチャートである。
第３１は、テレビ番組の予約を行うときのフローチャートを示すもので、まず最初にステップ１０−１で画面を呼び出す。この画面はテレビ番組予約シートであり、チャンネル、日付、時間などの複数の属性毎に入力できる。ステップ１０−２で入力画面に入力したら、ステップ１０−３で送信し、ステップ１０−４で受信する。受信された予約内容は、ステップ１０−５でテレビチュナーへ送信し、テレビチューナの予約が完了する。このように簡単に番組予約を実行することが可能である。
産業上の利用可能性
本発明は、安価な端末を用いて、より簡単な操作で電子メールを行なうことができるとともに、通信料を抑えることができ、インターネットを活用した様々な用途に対応可能な手書きで操作できる端末装置、およびそれを用いたインターネットシステムを提供できる。
【図面の簡単な説明】
第１図は、本発明の第１の実施例のシステム構成図である。
第２図は、端末１の処理フローである。
第３図は、端末１の処理フローである。
第４図は、端末１の処理フローである。
第５図は、サーバの処理フローである。
第６図は、サーバの処理フローである。
第７図は、端末１の操作画面の例である。
第８図は、端末１の操作画面の例である。
第９図は、端末１の操作画面の例である。
第１０図は、端末１の操作画面の例である。
第１１図は、端末１の操作画面の例である。
第１２図は、サーバのシステム構成図である。
第１３図は、端末１の操作画面の例である。
第１４図は、端末１の操作画面の例である。
第１５図は、サーバの処理フローである。
第１６図は、サーバの処理フローである。
第１７図は、第２の実施例のシステム構成図である。
第１８図は、端末１の操作画面の例である。
第１９図は、サーバのシステム構成図である。
第２０図は、端末１の処理フローである。
第２１図は、サーバの処理フローである。
第２２図は、端末１の操作画面の例である。
第２３図は、端末１の処理フローである。
第２４図は、第３の実施例のシステム構成図である。
第２５図は、第３の実施例のサーバのシステム構成図である。
第２６図は、サーバの処理フローである。
第２７図は、サーバの処理フローである。
第２８図は、データ構造図である。
第２９図は、データ構造図である。
第３０図は、データ構造図である。
第３１図は、データ構造図である。
【図１】
2002101558.tif 000003
【図２】
2002101558.tif 000004
【図３】
2002101558.tif 000005
【図４】
2002101558.tif 000006
【図５】
2002101558.tif 000007
【図６】
2002101558.tif 000008
【図７】
2002101558.tif 000009
【図８】
2002101558.tif 000010
【図９】
2002101558.tif 000011
【図１０】
2002101558.tif 000012
【図１１】
2002101558.tif 000013
【図１２】
2002101558.tif 000014
【図１３】
2002101558.tif 000015
【図１４】
2002101558.tif 000016
【図１５】
2002101558.tif 000017
【図１６】
2002101558.tif 000018
【図１７】
2002101558.tif 000019
【図１８】
2002101558.tif 000020
【図１９】
2002101558.tif 000021
【図２０】
2002101558.tif 000022
【図２１】
2002101558.tif 000023
【図２２】
2002101558.tif 000024
【図２３】
2002101558.tif 000025
【図２４】
2002101558.tif 000026
【図２５】
2002101558.tif 000027
【図２６】
2002101558.tif 000028
【図２７】
2002101558.tif 000029
【図２８】
2002101558.tif 000030
【図２９】
2002101558.tif 000031
【図３０】
2002101558.tif 000032
【図３１】
2002101558.tif 000033
【国際調査報告】
2002101558.tif 000034
2002101558.tif 000035