JP2010245795A - 通信端末、通信サーバーおよび通信システム - Google Patents

Abstract

【課題】視覚聴覚障害者、視覚障害者、聴覚障害者、健常者が相互に通信可能な通信システムを提供すること。
【解決手段】携帯電話機等の通信端末は、点字パターンあるいはモールス信号パターンによって表される文字情報を入力するキー入力手段、前記文字情報を長点および短点の組み合わせからなる振動パターンで出力する振動出力手段、前記文字情報をチャット手段を備えた通信サーバーへ送信し、通信サーバーから文字情報を受信して振動出力手段に出力する通信手段とを備える。通信サーバーはチャット手段および被呼通信端末にメール送信あるいは電話発呼して被呼状態を通知する呼び出し手段を備える。既存の携帯電話機上で動作するアプリプログラムを使用するだけで、視覚聴覚障害者、視覚障害者、聴覚障害者、健常者それぞれに適した入力方式、出力方式を選択できる。
【選択図】図１

Description

本発明は、通信端末、通信サーバーおよび通信システムに関するものであり、特に視覚聴覚障害者、視覚障害者、聴覚障害者、健常者が相互に通信可能な通信端末、通信サーバーおよび通信システムに関するものである。

従来、通信手段として音声通話や電子メールの機能を備えた携帯電話機が普及しているが、視覚および聴覚の双方の障害を持つ視覚聴覚障害者同志あるいは視覚聴覚障害者と健常者が遠隔で通信することは、音声や電子メールの通信方式では不可能である。また、聴覚障害者には音声通信は不可能であり、視覚障害者には電子メール等の文字通信は不可能である。従って、視覚障害者と聴覚障害者が通信するには音声や電子メールの通信方式は使用できない。

そこで、視覚聴覚障害者などのための通信装置として各種のものが提案されている。下記の特許文献１には、視覚と聴覚の二重障害者向けの、特定小電力型の小型無線通信機を用いた携帯用の個人呼出及び意志伝達装置が開示されている。

この装置は、電波の送受信が可能な一対の無線機部と、この無線機部の受信電気信号を入力信号とし、入力信号の立ち上がりによって起動する振動発生手段をそれぞれ具備するページャー部からなる無線機一体型の相互呼出機能を有する呼出装置であって、送信機能としてボタンスイッチによるモールス信号の入力部を有し、受信側にモールス信号弁別のためのロジック回路，マイコン部，モータ起動スイッチング回路，及び電力制御回路の信号処理回路を有する携帯用小型無線バイブレータ装置である。

特開平９−２４８３１５号公報

上記したような従来の通信装置は、視覚聴覚障害者同志あるいは視覚聴覚障害者と健常者が通信するために特殊な端末を使用しているので、端末が高価であり、汎用性や拡張性に乏しいという問題点があった。また、文字情報の入力方式、出力方式が限られており、視覚聴覚障害者、視覚障害者、聴覚障害者、健常者それぞれに適した入力方式、出力方式を選択出来ないという問題点もあった。本発明の目的は、上記した従来の問題点を解決し、視覚聴覚障害者、視覚障害者、聴覚障害者、健常者が相互に通信可能な通信端末、通信サーバーおよび通信システムを提供することにある。

本発明の通信端末は、点字パターンあるいはモールス信号パターンによって表される文字情報を入力するキー入力手段と、前記点字パターンあるいはモールス信号パターンによって表される文字情報を長点および短点の組み合わせからなる振動パターンで出力する振動出力手段と、チャット手段を備えた通信サーバーと接続し、前記キー入力手段によって入力された前記文字情報を送信し、前記通信サーバーから前記文字情報を受信して前記振動出力手段に出力する通信手段とを備えたことを主要な特徴とする。

また、上記した通信端末において、前記振動出力手段は点字パターンによって表される文字情報を出力する場合に前記振動パターンの末尾の短点を省略して出力する点にも特徴がある。また、上記した通信端末において、市販の携帯電話機に本発明の機能を実現するプログラムを実装し、前記振動出力手段は前記携帯電話機に装備されているバイブレータを駆動して振動出力する点にも特徴がある。

本発明の通信サーバーは、送信側通信端末から送られてきた文字情報を受信し、文字情報を受信側通信端末に転送するチャット手段と、必要に応じて受信した文字情報を受信側通信端末が希望する文字表現に変換する文字表現変換手段とを備えたことを主要な特徴とする。

また、上記した通信サーバーは、接続時に被呼通信端末にメール送信あるいは電話発呼して被呼状態を通知する呼び出し手段を備えた点にも特徴がある。

本発明の通信システムは、上記した通信端末と、上記したサーバーと、前記通信端末と前記サーバーとを接続する通信網とからなることを主要な特徴とする。

本発明によれば、以下のような効果がある。

（１）既存の携帯電話上で動作する本発明の機能を実現するアプリケーションプログラムを使用するだけで、視覚聴覚障害者同志あるいは視覚聴覚障害者と健常者などが対話するためのメッセージ交換用端末を実現できる。

（２）携帯電話機のキー入力手段を用いて６点点字入力方式、８進２桁点字入力方式、モールスパターン入力方式、既存のカナ入力方式、音声認識入力方式などを選択可能であり、出力方式としては、６点点字パターン出力方式、モールスパターン出力方式、既存の画面文字表示方式、文字読み上げ音声出力方式などを選択可能であるので、視覚聴覚障害者、視覚障害者、聴覚障害者、健常者それぞれに適した入力方式、出力方式を選択できる。

（３）被呼端末がオフラインの場合に、通信サーバーから被呼端末にメール送信あるいは電話発呼して着信（被呼状態、通信要求）を通知することにより、通常の電話と同様に被呼者を呼び出すことができる。

（４）通信端末としては携帯電話機の他、視覚障害者、聴覚障害者、健常者であればインターネット接続可能なパソコンや携帯データ端末をそのまま利用可能であり、パソコンに振動出力装置を接続すれば視覚聴覚障害者も利用可能である。

（５）点字、モールスパターン、カナ相互のモード変換を通信サーバーにおいて行うことにより、通信端末のプログラム容量や処理負荷が軽減されると共に、モード変換機能の追加、更新が容易となる。

従って、本発明により身体の接触でしかコミュニケーションを取ることができなかった視覚聴覚障害者が離れたところにいる家族や介助者とコミュニケーションできるようになり、介助のため家を空けることができなかった家族にも精神的、時間的な余裕が生まれる。

図１は本発明を実施可能なシステム全体の構成を示すブロック図である。 図２は通信端末の一般的な構成例を示すブロック図である。 図３は携帯端末における本発明のアプリの表示例を示す説明図である。 図４は本発明のアプリによる各種の入力方式を示す説明図である。 図５は本発明において使用する通信メッセージの例を示す説明図である。 図６は端末サーバー間で通信時にやり取りされるデータの内容を示す説明図である。 図７は本発明のアプリによる各種の出力方式を示す説明図である。 図８は本発明のアプリの機能を示す機能ブロック図である。 図９は本発明のサーバーの機能を示す機能ブロック図である。 図１０は本発明のサーバーにおけるセッション管理ＤＢの内容例を示す説明図である。 図１１は本発明における登録処理の手順を示すフローチャートである。 図１２は本発明におけるサーバーの処理内容を示すフローチャートである。 図１３は本発明におけるサーバーの待機中処理を示すフローチャートである。 図１４は本発明におけるサーバーの呼び出し中処理を示すフローチャートである。 図１５は本発明におけるサーバーの話中処理を示すフローチャートである。 図１６は本発明におけるサーバーの被呼中処理を示すフローチャートである。 図１７は本発明におけるサーバーの通話中処理を示すフローチャートである。 図１８は本発明における端末アプリの処理内容を示すフローチャートである。

以下に図面を参照して実施例について説明する。

図１は本発明を実施可能なシステム全体の構成を示すブロック図である。本発明による通信システムは、インターネットに接続可能な携帯電話機等の一対の端末装置と、インターネットに接続された通信サーバーによって構成される。インターネット２０やインターネット２０と接続されている携帯電話網２１、２２、公衆無線データ通信網２３、有線電話網２４は周知である。

端末装置としは、携帯電話網２１、２２を介してインターネット２０と接続可能な一般的な携帯電話機３０の他、携帯電話機３０に振動出力装置Ａ３１を装着したもの、本発明専用の入出力装置を備えた専用携帯端末装置３５、インターネット２０あるいはインターネット２０に接続された公衆無線データ通信網２３に接続された周知のＰＣ（パソコン、携帯データ端末を含む）あるいはＰＣに振動出力装置Ｄ２６を接続したものを使用できる。

振動出力装置Ａ３１、Ｄ２６は例えば振動モータ等の振動装置を２個、６個あるいはそれ以上備えたものであり、携帯電話機３０あるいはＰＣ２５とＵＳＢやその他の有線あるいは無線インターフェイスによって接続され、携帯電話機３０あるいはＰＣ２５にインストールされた本発明によるアプリプログラムから各振動装置を個別に制御可能な構成を備えている。

専用携帯端末装置３５は、例えば通常の携帯電話機に６点点字入力用のキーボードや２点あるいは６点振動点字出力機能を付加した本発明専用の端末装置である。なお、本発明においては端末とサーバー間においてはパケット通信方式のみを使用し、音声通話方式は使用しないので、音声通話機能の無い携帯データ端末も使用可能である。

インターネット２０に接続されている通信サーバーシステム１０は、Ｗｅｂサーバー、メールサーバー、アプリサーバー、データベース（ＤＢ）サーバー等の機能を備えたサーバーシステムでり、１台あるいはＬＡＮによって接続された複数台の市販のサーバー装置に本発明の機能を実現するプログラムを実装することにより実現できる。

図２は通信端末の一例である携帯電話機の一般的な構成例を示すブロック図である。ＲＦ処理回路４１はアンテナ４２を備え、携帯電話網の基地局とデータの送受信を行う。ベースバンド処理、ネットワーク処理制御回路４０はＣＰＵ、ＲＯＭ、ＲＡＭ、フラッシュメモリ等を備え、無線通信とネットワーク手続きの制御を行う。

アプリケーション処理、ユーザインターフェイス処理制御回路５０はやはりＣＰＵ、ＲＯＭ、ＲＡＭ、フラッシュメモリ等を備え、アプリ（アプリケーションプログラム）をサーバーからダウンロードしてインストールし、実行することが出来るように構成されている。本発明においては一般的な携帯電話機あるいはＰＣに本発明のアプリをダウンロードしてインストールすることにより本発明の端末装置として使用する。

携帯電話機３０は更に、テンキー入力装置４３、マイク４４、アプリから制御可能な振動モーター４５、液晶等の表示装置４６、スピーカ４７、デジタル入出力コネクタ４８、アナログ入出力コネクタ４９を備えている。デジタル入出力コネクタ４８あるいはアナログ入出力コネクタ４９を介して振動出力装置Ａ３１、Ｄ２６を接続可能である。

本発明による通信を行う場合に、視覚聴覚障害者の場合には、テンキー入力装置４３を用いた点字あるいはモールスパターンの入力を使用し、出力としては振動モーター４５を使用した振動パターンによる６点点字出力あるいはモールスパターン出力を使用する。視覚障害者の場合には、視覚聴覚障害者と同様の入出力方式を使用するか、あるいは入力として通常の文字入力（カナ入力）、出力としてスピーカ４７を使用した文字読み上げ音声出力を使用する。聴覚障害者および健常者は通常の文字入力（カナ入力）および表示装置４６への文字表示を使用する。

図３は携帯端末における本発明のアプリの表示例を示す説明図である。図３においては、相手端末と通信中の状態を示しており、左は６点点字入力方式を使用している場合の表示例、右はモールスパターン入力方式を使用している場合の表示例である。

左の６点点字入力方式の例においては、表示装置４６の上段の接続相手表示領域６１には相手ＩＤとして「１２３４」ニックネームとして「タロウ」が表示されている。これらの情報はサーバーから取得する。なお、通信状態以外の場合には接続相手表示領域６１にはオフライン、オンライン、ダイヤル中、被呼中などの端末内部状態を表示する。受信文表示領域６４には「モシモシ タロウデス」という受信文字列が表示されており、送信文表示領域６５には入力中の文字列（確定した文字）「コンニ」が表示されている。

点字パターン表示領域６３には、現在入力中の文字の点字パターンが表示されており、入力中文字表示領域６２には点字パターン表示領域６３に表示されている点字と対応するカナ文字「チ」が表示されている。なお、テンキー装置４３の内、６点点字入力方式においては、点字入力使用キー６０として例えば「０」〜「９」、「＊」、「＃」を使用する。

右のモールスパターン入力方式においては、点字パターン表示領域６３がモールスパターン表示領域６６に替わっている以外は６点点字入力方式と同じである。なお、モールスパターン入力方式においては、モールス入力使用キー６７として「０」、「３」〜「６」、「９」、「＊」、「＃」を使用する。

図４は本発明のアプリによる各種の入力方式を示す説明図である。図４（ａ）は通常の携帯電話機が備えている既存のカナ入力方式であり、例えばカナ入力モードにしてテンキーの「４」を２回押下し、確定キーを押下するか他の次の文字入力操作をすれば「チ」となる。

図４（ｂ）は６点点字入力方式を示す説明図である。図４の中央に示すように点字の各点にはそれぞれ１〜６の番号が付いている。本発明の６点点字入力（パターン）方式においては、点字の１番をテンキーの「１」に、以下２を「４」、３を「７」、４を「２」、５を「５」、６を「８」に割り当てている。更に、「６」は文字確定、「９」はクリヤ、「＊」は文字列送信、「＃」は終話の指示用にそれぞれ使用する。

例えば６点点字入力方式で「チ」を入力する場合には「１」「４」「５」「７」を任意の順序で押下することにより、図３左に示す状態となる。ここで「６」を押下すると文字「チ」が確定し、送信文の末尾に追加されると共に、「チ」に相当する６点点字パターンが振動出力される。この振動パターンは、点字の１〜６番の順に、点がある（突起、図３では黒丸）場合には長い振動、点が無い（平坦、図３では白丸）場合には短い振動を出力するものである。

図４（ｃ）は８進数２桁入力方式を示す説明図である。８進数２桁入力方式は、点字の１番〜３番および４番〜６番の点の有り無しを０〜７の８進数２桁で入力する入力方式である。例えば「チ」の場合には２進で表すと「111010」となり、８進では「７」「２」となる。この入力方式の場合には、８進２桁のコードを覚える必要があるが、テンキーを２回押下するだけで全ての点字を入力可能であり、６点点字入力方式よりも少ない操作で点字を早く入力可能である。

図４（ｄ）は２点モールスパターン入力方式を示す説明図である。モールス信号のパターンは長点と短点の並び順によって決まるので、例えば短点をテンキーの「４」に、長点を「５」に、文字の確定を「６」に割り当て、「チ」の場合には「４」「４」「５」「４」と順に押下することによりモールスバターンを入力して「６」で確定する。

入力された文字列はそれぞれの入力方式と対応した文字列として通信サーバーに送信される。カナ入力方式の場合にはテキスト情報（ユーザが送受信したい文字）がＵＲＬエンコードされる。例えば全角の「チ」を表す３ビットのユニコード（Unicode）を表す文字列「%E3%83%81」が送信される。カナのコードはユニコードの他、シフトＪＩＳコード、ＪＩＳ８ビットコードであってもよい。なお、文字列に変換せずに「チ」を表すユニコードをそのまま送信してもよい。

６点点字入力方式の場合にはテンキー装置において押下されたキーと対応する文字列「14576*」が、８進数２桁入力方式の場合には「72*」が送信される。（「*」は送信キーで、無くてもよい）また、モールスパターン入力方式の場合にはやはりテンキー装置において押下されたキーと対応する文字列「44546*」が送信される。なお、６点点字入力方式、８進数２桁入力方式の場合に入力キー文字列を点字コードに変換して点字コードを送信してもよい。また、モールスパターン入力方式の場合に入力キー文字列をモールスパターンコードに変換してモールスパターンコードを送信してもよい。

図５は本発明において使用する通信メッセージの例を示す説明図である。通信メッセージは、メッセージ種別情報とテキスト情報から構成され、それぞれ文字列によって表現される。メッセージ種別は、入出力モード（MODE）、言語（LANG）、文字種別（CHAR）を含む。それぞれの情報の区切りとして文字「&」を使用する。

入出力モード（MODE）としては、例えば６点点字（BRAIL）、８進数点字（OCTET）、モールス（MORSE）、文字（CHAR：ユニコード）を含む。言語（LANG）としては、例えば日本語（JA）、韓国語（KR）、英語（EN）、中国語（CN）、ドイツ語（DR）、フランス語（FR）などを含む。文字種別（CHAR）としては、例えば英文（ALPHA）、数字（NUMERIC）、カナ（KANA）を含む。なお文字種別のKANAはユニコードを標準とするが、異なる文字を定義してシフトＪＩＳコードやEUC-JPコードを割り当ててもよい。

メッセージとして例えば「チ」に相当する点字情報を送る場合には、メッセージの文字列は「MODE=BRAIL&LANG=JA&CHAR=KANA&TEXT=14576*」となる。また、カナで送る場合には「MODE=CHAR&LANG=JA&CHAR=KANA&TEXT=%E3%83%81」となる。

図６は端末サーバー間で通信時にやり取りされるデータの内容を示す説明図である。端末サーバー間においてはHTTP/HTTPSプロトコルを使用してパケット通信を行う。HTTP/HTTPSはインターネット上のWebサーバーからホームページの閲覧やプログラムのダウンロード取得に利用されるプロトコルである。HTTP/HTTPSはリクエスト・レスポンス型のプロトコルである。すなわち、クライアントがサーバーにリクエストメッセージを送信し、サーバーがそれに応じたレスポンスメッセージを返す。１回のリクエスト・レスポンスは独立で、他のリクエスト・レスポンスに関与しない。

そこで、１つのセッション（端末アプリが通信サーバーにアクセスしてからオフラインになるまで）について端末を特定するためにサーバーからセッションＩＤを発行し、セッション中の２回目以降のアクセス時には端末からのアップロードデータにこのセッションＩＤを記載することにより端末の認証を行う。

接続時には自ＩＤ、パスワードと共に、自端末から送信するアップ文字モード種別およびサーバーから送信してほしいダウン希望モード情報を送信する。これらの情報は予め端末アプリに設定しておく。ダイヤル時には相手情報として相手ＩＤの代わりにサーバーに予め登録されている相手ニックネームを送信してもよい。ニックネームはユーザ登録時にユーザが入力し、ユニークであれば承認され、ユーザーＤＢに登録される。

図６（Ａ）は通信状態（ESTA）における端末からのアップロードデータ例を示す説明図である。通信状態における端末からのアップロードデータには、セッションＩＤの他、ユーザーＩＤ、接続要求、ダイヤル要求、文字列送信、問い合わせ、終話、切断通知等のリクエスト、通信状態にある相手ＩＤ、図５に示した通信メッセージ（送信すべきメッセージがある場合）が含まれている。

図６（Ｂ）は通信状態における端末へのダウンロードデータ例を示す説明図である。通信状態における端末へのダウンロードデータには、セッションＩＤ、ユーザーＩＤの他、接続承認、ダイヤル中、文字列受信、終話通知、切断通知等のレスポンス、通信状態にある相手ＩＤ、ダウンロードメッセージ（メッセージがある場合）が含まれている。

本発明においては、端末からは設定されている入力モードと対応した文字列でメッセージを通信サーバーに送信する。従って、端末から送信される文字列が相手端末が希望する受信モードと異なる場合にはサーバーにおいてモード（文字列種別）の変換処理を行う。また、例えば受信希望するモードが点字である場合に、端末においては、受信した点字文字列と対応する文字を画面に表示するためにカナコードも必要である。しかし、モード変換処理は複雑であり、正確に変換するためには処理負荷やプログラム容量が大きくなってしまうという課題があった。

そこで、本発明においては、通信サーバーにおいて受信した文字列のカナ文字列への変換を必ず行い、サーバーから端末が希望する受信モードがカナ以外の場合には、端末が希望する受信モードの文字列と共に表示用のカナ文字列も付けて送るようにする。このようにすれば端末において表示用のモード変換処理が不要となり、端末アプリの処理負荷やプログラム容量が軽減される。

図６（Ｂ１）は、図５に示した端末からの送信メッセージ例に対して、ダウンロードメッセージとして、点字と文字（カナ）の双方と対応する文字列を送る例である。ダウンロードメッセージは「MODE=BRAIL,CHAR&LANG=JA&CHAR=KANA&TEXT=14576,%E3%83%81」となり、MODEに「CHAR」が追加されると共に、テキスト情報２の「%E3%83%81」が追加されている。

図７は本発明のアプリによる各種の出力方式を示す説明図である。本発明における出力方式としては、画面への文字表示の他、振動出力、音声出力、文字情報デジタル出力（ＵＳＢ、赤外線、Bluetooth）、文字情報アナログ出力（DTMF、FSK）を備える。振動出力としては、１点（振動子が１個）点字パターン出力方式およびモールスパターン出力方式の２方式があり、１点点字パターン出力方式においては、末尾の短点を省略して出力することも可能である。音声出力には文字読み上げ音声出力方式およびモールスパターンに基づくモールス音出力がある。

例えば文字「チ」を出力する場合、図７（ａ）のカナ出力においては、受信した文字のユニコードをそのまま画面に表示する。図７（ｂ）の１点点字出力方式においては、受信した文字列の内、ユニコードをそのまま画面に表示すると共に、点字文字列は１点点字パターンに変換して振動出力する。

この振動パターンは前述したように、点字の１〜６番の順に、点がある（突起、図３では黒丸）場合には長い振動（長点：例えば短点の３倍の長さ）、点が無い（平坦、図３では白丸）場合には短い振動（短点）を出力するものである。このとき、括弧書きで図示されているように末尾の短点を省略して出力することも可能である。

図７（ｃ）のモールスパターン出力方式においては、受信した文字列の内、ユニコードを画面に表示すると共に、モールス文字列は周知の長い振動（長点）と短い振動（短点）の組み合わせからなるモールス信号パターンに変換して振動出力する。

図８は本発明のアプリの機能を示す機能ブロック図である。キー入力処理部８４はテンキー８５のいずれかが押下された場合にＦＩＦＯバッファ８３に押下されたキーの情報を格納すると共に、必要に応じて各出力処理部の入力ＦＩＦＯバッファへも書き込む。通信処理部７１は、送信バッファ７３に送信すべき情報が格納されていれば、パケットを生成して送信し、受信したパケットのデータを受信バッファ７２に格納する。

制御処理部７０は、詳細は後述するが、受信バッファ７２およびキー入力用のＦＩＦＯバッファ８３の内容をチェックし、データが入力されている場合にはそのデータを読み出して解析し、必要な処理を実行する。そして、出力すべきＦＩＦＯバッファ８０および必要（設定）に応じてＦＩＦＯバッファ７４、７７の内の少なくとも１つに文字情報を書き込む。

画面出力処理部８１はＦＩＦＯバッファ８０に文字情報が書き込まれていればそれを読み出し、表示装置８２に表示する。振動出力処理部７５は、ＦＩＦＯバッファ７４に文字列が書き込まれていればそれを読み出し、指定された種別の振動パターンに変換してバイブレータ７６（＝振動モータ４５）を駆動する。音声出力処理部７８は、ＦＩＦＯバッファ７７に文字情報が書き込まれていればそれを読み出し、指定された種別の音波形信号に変換してスピーカー７９（＝４７）を駆動する。

図９は本発明の通信サーバーの機能を示す機能ブロック図である。パケット受信部９８は端末からパケットを受信し、周知のＷｅｂサーバプログラム９７に送る。Ｗｅｂサーバプログラム９７は受信したパケットの内容を解析し、登録処理の場合にはＣＧＩプログラムによって構成された登録処理部９２を起動する。

登録処理部９２はユーザーＤＢ９３へのユーザー登録／更新処理（ユーザ情報の登録、ＩＤの発行）、端末の種類に適合した端末アプリのダウンロード処理を実行する。ユーザーＤＢ９３には例えば、氏名、住所、ユーザＩＤ、ニックネーム、メールアドレス、端末電話番号、アップロードモード種別、ダウンロードモード種別、ダウンロードしたアプリのバージョン情報等が登録される。

受信したパケットの内容が接続、通信処理の場合にはＷｅｂサーバプログラム９７はＣＧＩプログラムによって構成された接続、通信処理部９０（９１）を起動する。発呼者用の接続、通信制御部９０と被呼者用の接続、通信制御部９１は同じ機能を有している。接続、通信制御部９０は、詳細は後述するが、受信したパケットの内容に応じてセッション管理ＤＢ９４の更新、モード変換部９５を使用したメッセージのモード変換、オンラインユーザ毎に割り当てた受信ボックス９６（受信データ格納領域）への文字列の書き込み、被呼端末の呼び出し等の接続、通信処理を実行する。

また、端末からパケットを受信した時に、当該端末と対応する受信ボックスに文字列が格納されていた場合には、そのデータを読み出して応答パケットを生成し、Ｗｅｂサーバプログラム９７、パケット送信部９７を介して対応する端末に送信する。モード変換部９５は、例えばカナ→点字、点字→カナ、点字→モールス、モールス→点字、カナ→モールス、モールス→カナ変換機能を備える。

図１０は本発明のサーバーにおけるセッション管理ＤＢの内容例を示す説明図である。セッション管理ＤＢ９４は、オンライン状態の端末を管理するためのデータベースであり、端末がサーバーに接続（オンライン待機状態）を要求してきた時にセッションが登録され、切断通知によって削除される。

セッション管理ＤＢには、ユーザＩＤ、セッションＩＤ、ユーザー認証の寿命、端末状態、状態更新時刻、アップロードモード種別、ダウンロードモード種別、（BR=BRAIL、MO=MORSE、CH=CHAR、KA=KANA、AL=ALPHA）相手ユーザーＩＤ、受信ボックス番号、シフトフラグ等が記録される。端末状態は、待機中（ONLN：オンライン）、ダイアル中（DIAL）、通信中（ESTA）、被呼中（CALL）、話中（BUSY）などの端末の状態を示す。

状態更新時刻は現在の端末状態になった時刻であり、これにより設定時間が経過したか否かを判定する。なお、セッション管理ＤＢにニックネームも記録するようにしてもよい。また、点字における外字（英字）シフト状態、数字シフト状態あるいは和文モールスパターンにおける英文シフト状態等を記憶するためのフラグ情報を記録してもよい。

図１１は本発明における登録処理の手順を示すフローチャートである。まず、Ｔ０１においては、端末（携帯電話機）のブラウザを起動し、通信サーバーのＵＲＬにアクセスする。Ｓ０１においては、サーバーから端末にユーザ登録に必要な事項の記入欄を備えたホームページ（ＨＰ）を送信する。Ｔ０２においては、登録に必要な情報を入力した後、端末からユーザ登録要求を送信する。

Ｓ０２においては、サーバーにおいて登録要求情報を確認してユーザ登録ＯＫであればユーザＩＤを生成し、ユーザデータベースに登録事項を登録すると共にユーザーに通知する。

Ｔ０３においては、端末から機種を指定してアプリのダウンロード（ＤＬ）を要求し、Ｓ０３においては、サーバーから対応するアプリをダウンロードする。Ｔ０４においては、端末においてアプリを受信して保存し、Ｔ０５においては、アプリを端末にインストールして実行する。Ｔ０６においては、アプリにユーザＩＤ、パスワード、入力方式、出力方式等の設定情報を入力し保存する。

図１２は本発明におけるサーバーの処理内容を示すフローチャートである。通信サーバーは通信端末同士のチャット処理を行い、必要ならば文字モードを変換する。また、接続時には被呼端末がオフラインの場合、被呼端末あてにメール送信あるいは電話発呼して着信（通信要求）を通知する。ユーザーはアプリを手動で起動して応答する。

Ｓ１０においては、いずれかの端末からアクセスが有ったか否かが判定され、肯定の場合にはＳ１１に移行する。Ｓ１１においては、セッションオープン処理が行われる。具体的には、セッション管理ＢＤに接続してセッションＩＤによってセッション管理ＤＢを検索する。Ｓ１２においては、セッション情報がセッション管理ＤＢに未登録か否かが判定され、判定結果が否定の場合にはＳ１４に移行するが、肯定の場合にはＳ１３に移行する。Ｓ１３においてはセッション登録処理が行われる。即ち、新たにセッションＩＤを生成し、セッション管理ＤＢに新たにセッション情報を登録する。この際、「状態」の初期値は待機中(ONLN)とする。

Ｓ１４においては、ユーザ認証処理が行われる。即ち、ユーザＩＤおよび正当なパスワードあるいは正当なセッションＩＤが記載されていれば登録ユーザと判定される。Ｓ１５においては、登録ユーザーからのアクセスか否かが判定され、判定結果が否定の場合にはＳ１７に移行するが、肯定の場合にはＳ１６に移行する。Ｓ１６においては、図１１において説明したユーザー登録、ダウンロード処理が行われる。Ｓ１７においてはセッション管理ＤＢを検索し、端末の「状態」情報を読み出す。

Ｓ１８においては、「状態」情報が待機中(ONLN)か否かが判定され、判定結果が否定の場合にはＳ２０に移行するが、肯定の場合にはＳ１９に移行する。Ｓ１９においては、後述する待機中(ONLN)処理が行われ、Ｓ２８に移行する。

Ｓ２０においては、「状態」情報が呼出し中(DIAL)か否かが判定され、判定結果が否定の場合にはＳ２２に移行するが、肯定の場合にはＳ２１に移行する。Ｓ２１においては、後述する呼出し中(DIAL)処理が行われ、Ｓ２８に移行する。Ｓ２２においては、「状態」情報が話中(BUSY)か否かが判定され、判定結果が否定の場合にはＳ２４に移行するが、肯定の場合にはＳ２３に移行する。Ｓ２３においては、後述する話中(BUSY)処理が行われ、Ｓ２８に移行する。

Ｓ２４においては、「状態」情報が被呼中(CALL)か否かが判定され、判定結果が否定の場合にはＳ２６に移行するが、肯定の場合にはＳ２５に移行する。Ｓ２５においては、後述する被呼中(CALL)処理が行われ、Ｓ２８に移行する。Ｓ２６においては、「状態」情報が通話中(ESTA)か否かが判定され、判定結果が否定の場合にはＳ２８に移行するが、肯定の場合にはＳ２７に移行する。Ｓ２７においては、後述する通話中(ESTA)処理が行われ、Ｓ２８に移行する。

Ｓ２８においては、リクエストが切断か否かが判定され、判定結果が否定の場合にはＳ３０に移行するが、肯定の場合にはＳ２９に移行する。Ｓ２９においては、セッション管理ＤＢからセッション情報を削除する。Ｓ３０においては、セッションクローズ処理が行われる。具体的には、セッション情報のユーザ認証の寿命更新、状態更新時刻の更新、セッション情報の保存などを行う。

図１３は本発明におけるサーバーの待機中処理（Ｓ１９）を示すフローチャートである。Ｓ５０においては、リクエストを抽出し、解析する。Ｓ５１においては、リクエストが問い合わせ(ENQ)か否かが判定され、判定結果が否定の場合にはＳ５３に移行するが、肯定の場合にはＳ５２に移行する。Ｓ５２においては、レスポンスとして「待機中(ONLN)」を返送する。

Ｓ５３においては、呼出し(DIAL)か否かが判定され、判定結果が否定の場合にはＳ６４に移行するが、肯定の場合にはＳ５４に移行する。Ｓ５４においては、相手ID=自分か否かが判定され、判定結果が否定の場合にはＳ５５に移行するが、肯定の場合にはＳ６２に移行する。Ｓ５５においては、セッション管理ＤＢにおいて相手ＩＤを検索する。

Ｓ５６においては、相手はオフライン、即ちセッション管理ＤＢに未登録か否かが判定され、判定結果が否定の場合にはＳ６０に移行するが、肯定の場合にはＳ５７に移行する。Ｓ５７においては、被呼端末あてに発呼者情報を記入したメールを送信し、呼び出しを通知する。なお、ユーザーが電話呼び出しを希望し、そのように設定されている場合には被呼端末あてに電話（インターネットを使用した電話サービスを含む）にて発呼するようにする。Ｓ５８においては、レスポンスとして呼出し中(DIAL)を返送する。Ｓ５９においては、状態を呼出し中に更新する。

Ｓ６０においては、相手は待機中（ONLN）か否かが判定され、判定結果が否定の場合にはＳ６２に移行するが、肯定の場合にはＳ６１に移行する。Ｓ６１においては、相手ID状態を被呼中に更新し、Ｓ５８に移行する。Ｓ６２においては、相手端末の状態が通信中（ESTA）、ダイヤル中（DIAL）、他の端末からの被呼中（CALL）、相手話中(BUSY)状態であるので、レスポンスとして話中(BUSY)状態を返送する。Ｓ６３においては、状態を話中に更新する。

Ｓ６４においては、切断(EXIT)か否かが判定され、判定結果が否定の場合には処理を終了するが、肯定の場合にはＳ６５に移行する。Ｓ６５においては、レスポンスとして「切断(EXIT)」を返送する。

図１４は本発明におけるサーバーの呼び出し中処理（Ｓ２１）を示すフローチャートである。Ｓ７０においては、リクエストを抽出し、解析する。Ｓ７１においては、リクエストが問い合わせ(ENQ)か否かが判定され、判定結果が否定の場合にはＳ８０に移行するが、肯定の場合にはＳ７２に移行する。Ｓ７２においては、セッション管理ＤＢにおいて相手ＩＤを検索する。

Ｓ７３においては、相手は自ＩＤと通信中（ESTA）か否かが判定され、判定結果が否定の場合にはＳ７６に移行するが、肯定の場合にはＳ７４に移行する。Ｓ７４においては、レスポンスとして通信中(ESTA)を返送する。Ｓ７５においては、状態を通信中に更新する。

Ｓ７６においては、相手は待機中（ONLN）か否かが判定され、判定結果が否定の場合にはＳ７８に移行するが、肯定の場合にはＳ７７に移行する。Ｓ７７においては相手ＩＤの状態を被呼中（CALL）に更新し、Ｓ８０に移行する。Ｓ７８においては、相手は被呼中（CALL）か否かが判定され、判定結果が否定の場合にはＳ７９に移行するが、肯定の場合にはＳ８０に移行する。

。Ｓ７９においては、呼び出し中状態になってから予め定められた時間（例えば数分）が経過したか否かが判定され、判定結果が否定の場合にはＳ８０に移行するが、肯定の場合にはＳ８１に移行する。Ｓ８０においては、レスポンス呼出し中(DIAL)を返送する。Ｓ８１においては、レスポンスとして待機中(ONLN)を返送し、Ｓ８２においては、状態を待機中に更新する。

Ｓ８３においては、終話(FIN)か否かが判定され、判定結果が否定の場合にはＳ８８に移行するが、肯定の場合にはＳ８４に移行する。Ｓ８４においてはセッション管理ＤＢにおいて相手ＩＤを検索する。Ｓ８５においては、相手ＩＤの状態を待機中(ONLN)に更新する。Ｓ８６においては、レスポンスとして「待機中(ONLN)」を返送する。Ｓ８７においては、状態を待機中(ONLN)に更新する。

Ｓ８８においては、切断(EXIT)か否かが判定され、判定結果が否定の場合には処理を終了するが、肯定の場合にはＳ８９に移行する。Ｓ８９においては、レスポンスとして「切断(EXIT)」を返送する。

図１５は本発明におけるサーバーの話中処理（Ｓ２３）を示すフローチャートである。Ｓ９０においては、リクエストを抽出し、解析する。Ｓ９１においては、リクエストが問い合わせ(ENQ)か否かが判定され、判定結果が否定の場合にはＳ９３に移行するが、肯定の場合にはＳ９２に移行する。Ｓ９２においては、レスポンスとして「話中(BUSY)」を返送する。

Ｓ９３においては、終話(FIN)か否かが判定され、判定結果が否定の場合にはＳ９６に移行するが、肯定の場合にはＳ９４に移行する。Ｓ９４においては、レスポンスとして「待機中(ONLN)」を返送し、Ｓ９５においては状態を待機中(ONLN)に更新する。

Ｓ９６においては、切断(EXIT)か否かが判定され、判定結果が否定の場合には処理を終了するが、肯定の場合にはＳ９７に移行する。Ｓ９７においては、レスポンスとして「切断(EXIT)」を返送する。

図１６は本発明におけるサーバーの被呼中処理（Ｓ２５）を示すフローチャートである。Ｓ１００においては、リクエストを抽出し、解析する。Ｓ１０１においては、リクエストが問い合わせ(ENQ)か否かが判定され、判定結果が否定の場合にはＳ１０７に移行するが、肯定の場合にはＳ１０２に移行する。Ｓ１０２においては、セッション管理ＤＢにおいて相手ＩＤを検索する。

Ｓ１０３においては、相手はダイヤル中（DIAL）か否かが判定され、判定結果が否定の場合にはＳ１０５に移行するが、肯定の場合にはＳ１０４に移行する。Ｓ１０４においては、レスポンスとして被呼中(CALL)を返送する。Ｓ１０５においては、レスポンスとして待機中(ONLN)を返送し、Ｓ１０６においては、状態を待機中に更新する。

Ｓ１０７においては、応答(OFHK)か否かが判定され、判定結果が否定の場合にはＳ１１１に移行するが、肯定の場合にはＳ１０８に移行する。Ｓ１０８においては受信ボックスを割り当て、Ｓ１０９においては、レスポンスとして「通信中(ESTA)」を返送し、Ｓ１１０においては状態を通信中(ESTA)に更新する。

Ｓ１１１においては、切断(EXIT)か否かが判定され、判定結果が否定の場合には処理を終了するが、肯定の場合にはＳ１１２に移行する。Ｓ１１２においては、レスポンスとして「切断(EXIT)」を返送する。

図１７は本発明におけるサーバーの通話中処理（Ｓ２７）を示すフローチャートである。Ｓ１２０においては、リクエストを抽出し、解析する。Ｓ１２１においては、リクエストが問い合わせ(ENQ)か否かが判定され、判定結果が否定の場合にはＳ１２８に移行するが、肯定の場合にはＳ１２２に移行する。Ｓ１２２においては、セッション管理ＤＢにおいて相手ＩＤを検索する。

Ｓ１２３においては、相手は通話中（ESTA）か否かが判定され、判定結果が否定の場合にはＳ１２５に移行するが、肯定の場合にはＳ１２４に移行する。Ｓ１２４においては、受信ボックス内に受信データがあれば受信データを添付して、レスポンスとして通信中(ESTA)を返送する。Ｓ１２５においては受信ボックスを解放し、Ｓ１２６においては、レスポンスとして待機中(ONLN)を返送し、Ｓ１２７においては状態を待機中に更新する。

Ｓ１２８においては、送信(SEND)か否かが判定され、判定結果が否定の場合にはＳ１３４に移行するが、肯定の場合にはＳ１２９に移行する。Ｓ１２９においては、セッション管理ＤＢにおいて相手ＩＤを検索する。Ｓ１３０においては、相手は通話中（ESTA）か否かが判定され、判定結果が否定の場合にはＳ１２５に移行するが、肯定の場合にはＳ１３１に移行する。

Ｓ１３１においては、必要に応じてモード変換処理が行われる。例えば送受信とも点字モードの端末と、送受信ともモールスモードの端末が通信する場合には、サーバーで受信された点字文字列はカナ文字列およびモールスパターン文字列の双方にモード変換され、例えば図６（Ｂ１）に示すようなフォーマットで双方の文字列が相手端末に送信される。また、サーバーで受信されたモールス文字列はカナ文字列および点字文字列の双方に変換され、やはり図６（Ｂ１）に示すようなフォーマットで双方の文字列が端末に送信される。モード変換においては、例えば点字表現の文字列を一旦点字コードに変換し、予め定められている変換テーブルを引いて、文字モードやモールスモードの文字列に変換する。

Ｓ１３２においては、相手のモードに合わせた通信メッセージが相手受信ボックスに書き込まれる。Ｓ１３３においては、受信ボックス内に受信データがあれば受信データを添付して、レスポンスとして通信中(ESTA)を返送する。

Ｓ１３４においては、終話(FIN)か否かが判定され、判定結果が否定の場合にはＳ１３７に移行するが、肯定の場合にはＳ１３５に移行する。Ｓ１３５においては、レスポンスとして待機中(ONLN)を返送し、Ｓ１３６においては、状態を待機中に更新する。Ｓ１３７においては、切断(EXIT)か否かが判定され、判定結果が否定の場合には処理を終了するが、肯定の場合にはＳ１３８に移行する。Ｓ１３８においては、レスポンスとして「切断(EXIT)」を返送する。

図１８は本発明における端末アプリの処理内容を示すフローチャートである。アプリは設定されているモードと対応して入力された文字あるいは押下したキー情報をそのままサーバーに送信し、サーバーから受信した文字あるいはキー情報を設定されている出力手段に出力する。アプリ、サーバー間はHTTP通信を行う。

Ｓ１５０においては、保存されている設定情報を読み出して初期設定を行い、端末内部状態をオフライン状態に設定する。Ｓ１５１においては、通信サーバーに接続要求（ONLN）を送信し、レスポンスを受信する。Ｓ１５２においては、受信したレスポンスが被呼（CALL）か否かが判定され、判定結果が否定の場合にはＳ１５３に移行するが、肯定の場合にはＳ１５４に移行する。

Ｓ１５３においては、待機(ONLN)状態を画面表示すると共に設定されている出力装置に出力する。また、端末内部状態を待機(ONLN)状態に設定する。Ｓ１５４においては、被呼状態であることおよびレスポンスに含まれる発呼者情報（ＩＤ、ニックネーム）を画面表示すると共に設定されている出力装置に出力する。また、端末内部状態を被呼状態に設定する。

Ｓ１５５においては、テンキー装置からキー入力が有ったか否かが判定され、判定結果が否定の場合にはＳ１６８に移行するが、肯定の場合にはＳ１５６に移行する。Ｓ１５６においては、キー入力がダイヤルの開始を指示するものか否かが判定され、判定結果が否定の場合にはＳ１５８に移行するが、肯定の場合にはＳ１５７に移行する。

なお、キー入力情報の意味は、その時点での端末内部状態、入力方式、押下されたキー情報の３種類の情報に基づいて判定される。例えば、待機状態、点字入力方式で「＊」キーが押下された場合にはダイヤル開始を意味するものとする。Ｓ６７においては、端末内部状態をダイヤル中に設定し、ダイヤルバッファをクリヤする。

Ｓ１５８においては、キー入力が応答を指示するものか否かが判定され、判定結果が否定の場合にはＳ１６０に移行するが、肯定の場合にはＳ１５９に移行する。Ｓ１５９においては、通信サーバーに応答リクエストを送信する。Ｓ１６０においては、キー入力が文字入力か否かが判定され、判定結果が否定の場合にはＳ１６２に移行するが、肯定の場合にはＳ１６１に移行する。

Ｓ１６１においては、内部状態がダイヤル中ならダイヤルバッファに、それ以外は入力バッファに書く。なお、文字を確定するキー入力があった場合には、それまでに入力バッファに入力されているキー情報によって決まる文字列を生成して文字列バッファに追加し、入力バッファをクリヤする。

Ｓ１６２においては、キー入力が送信を指示するものか否かが判定され、判定結果が否定の場合にはＳ１６４に移行するが、肯定の場合にはＳ１６３に移行する。Ｓ１６３においては、ダイヤル中の場合にはダイヤルリクエスト、通信中の場合には送信リクエストと共にダイヤルバッファあるいは文字列バッファ中の文字列を送信する。

Ｓ１６４においては、キー入力が終話を指示するものか否かが判定され、判定結果が否定の場合にはＳ１６６に移行するが、肯定の場合にはＳ１６５に移行する。Ｓ１６５においては、サーバーに終話リクエストを送信し、内部状態を待機状態とする。Ｓ１６６においては、キー入力がアプリ終了を指示するものか否かが判定され、判定結果が否定の場合にはＳ１６８に移行するが、肯定の場合にはＳ１６７に移行する。なお、「アプリ終了」は通信に使用しないソフトキーに割り当てておいてもよい。Ｓ１６７においては、サーバーにアプリ終了を通知し、アプリの処理を終了する。

Ｓ１６８においては、サーバーからパケットを受信したか否かが判定され、判定結果が否定の場合にはＳ１７８に移行するが、肯定の場合にはＳ１６９に移行する。Ｓ１６９においては、サーバーからのレスポンスが相手と接続したか、即ち通信中状態に移行したか否かが判定され、判定結果が否定の場合にはＳ１７１に移行するが、肯定の場合にはＳ１７０に移行する。Ｓ１７０においては、通信状態を表示、出力する。

Ｓ１７１においては、レスポンスが文字列受信か否かが判定され、判定結果が否定の場合にはＳ１７３に移行するが、肯定の場合にはＳ１７２に移行する。Ｓ１７２においては、設定されている出力装置と対応するバッファに文字列を書き込むことによって文字列を出力する。

Ｓ１７３においては、レスポンスが終話か否かが判定され、判定結果が否定の場合にはＳ１７５に移行するが、肯定の場合にはＳ１７６に移行する。Ｓ１７４においては、終話状態を出力し、内部状態を待機状態にする。Ｓ１７５においては、レスポンスが話中か否かが判定され、判定結果が否定の場合にはＳ１７７に移行するが、肯定の場合にはＳ１７６に移行する。Ｓ１７６においては、話中状態を出力し、内部状態を相手話中状態にする。Ｓ１７７においては、レスポンスが被呼状態か否かが判定され、判定結果が否定の場合にはＳ１５５に移行するが、肯定の場合にはＳ１５４に移行する。

Ｓ１７８においては、直前のパケット送信から所定の待機時間（例えば５秒）経過したか否かが判定され、判定結果が否定の場合にはＳ１５５に移行するが、肯定の場合にはＳ１７９に移行する。Ｓ１７９においては、サーバーに問い合わせ（ENQ）リクエストを送信する。この処理は相手からのメッセージをサーバーから読み出すためである。なお、Ｓ１７８の問い合わせの間隔は、通信状態においては短く、待機状態においては通信状態より長くしてもよい。

実施例１においては、オンラインでチャット通信を行う例を開示したが、相手端末が応答せず、オフラインのままでは通信を行うことができない。そこで、実施例２においては、相手がオフラインでも通信可能なメール機能を付加する。まず、サーバーにおいて、全てのユーザー対応にメールボックス（ファイル）を設置する。

端末においては、メール作成、送信機能を追加し、メール作成機能においては、複数行の文字列からなるメールを作成し、保存可能とする。メール送信機能においては、ユーザーＩＤあるいはニックネームで宛先を指定し、作成したメール本文と共にサーバーに送信する。

サーバーにおいては、メールを受信した場合には、発信者ＩＤ、ニックネーム、受信時刻を付加してメール本文を宛先ユーザーのメールボックスに書き込むと共に、宛先ユーザーにメール着信を知らせるメールを送信する。なおこの通知メールにも発信者ＩＤ、ニックネーム、受信時刻、メール本文の内容を記載する。ユーザーはアプリでサーバーに接続することにより、サーバーからのレスポンスでメール着信を知り、メール読み出し指示を行ってメールを受信する。

更にサーバーにおいて、予め定められたフォーマットで書かれた通常の電子メールを受信して内容を解析し、宛先のメールボックスにメールを転送する機能を付加すれば、視覚聴覚障害者と健常者が通信する場合、健常者はアプリを使用しなくても携帯電話機が備えている通常のメール機能を使用して通信が可能となる。

実施例１においては、２人のユーザー間で文字通信を行う例を開示したが、３人以上の任意数のユーザーによるチャットが出来るようにすることも可能である。この場合には、オンラインユーザーテーブルの相手ＩＤ欄に複数のＩＤを登録可能に構成し、ユーザーは通信中に更にダイヤル可能にする。また、サーバーにおいて配布する文字列の前に送信者のＩＤあるいはニックネームを付けて配布する。

以上、実施例について説明したが、以下のような変形例も考えられる。実施例においては、通信を行う例を開示したが、本発明の端末およびサーバーを使用することにより、ユーザーによるメモや日記などの文章ファイルの作成、保存、閲覧、編集が可能であり、更にブログとして公開することもできる。実施例においては、端末から入力方式と対応した文字列を送信する例を開示したが、端末内でカナコードなどの所定の文字コードにコード変換し、伝送する文字コードを統一することも可能である。

実施例においては、被呼端末がオフラインの場合、メール呼び出しによってユーザーが手動でアプリを起動する例を開示したが、被呼端末がオフラインの場合、メール呼び出しによって、あるいは携帯電話機を開くことによってアプリが自動的に起動するようにできれば応答操作が容易となる。

端末アプリは所定の周期でパケットを送信するので、切り忘れが発生した場合、従量制課金の場合には高額の通信費を請求される恐れがある。従って、一定時間文字列の送受信が無い場合にはアプリを終了するようにしてもよい。実施例においては、端末にアプリをインストールする例を開示したが、サーバー上に端末のシミュレータを置き、ＰＣ等のブラウザでサーバーにアクセスして通信を行う事も可能である。

本発明は視覚聴覚障害者、視覚障害者、聴覚障害者、健常者が相互に通信可能な通信端末、通信サーバーおよび通信システムとして利用可能である。

１０…通信サーバー
１１…Ｗｅｂサーバー
１２…データベース
１３…メールサーバー
１４…ＬＡＮ
２０…インターネット
２１、２２…携帯電話網
２３…公衆無線データ通信網
２４…有線電話網
２５…ＰＣ（パソコン）
２６、３１…振動出力装置
３０…通信端末（携帯電話機）
３５…専用端末装置

Claims (6)

1. 点字パターンあるいはモールス信号パターンによって表される文字情報を入力するキー入力手段と、
   前記点字パターンあるいはモールス信号パターンによって表される文字情報を長点および短点の組み合わせからなる振動パターンで出力する振動出力手段と、
   チャット手段を備えた通信サーバーと接続し、前記キー入力手段によって入力された前記文字情報を送信し、前記通信サーバーから前記文字情報を受信して前記振動出力手段に出力する通信手段と
   を備えたことを特徴とする通信端末。
2. 前記振動出力手段は点字パターンによって表される文字情報を出力する場合に前記振動パターンの末尾の短点を省略して出力することを特徴とする請求項１に記載の通信端末。
3. 市販の携帯電話機に本発明の機能を実現するプログラムを実装し、前記振動出力手段は前記携帯電話機に装備されているバイブレータを駆動して振動出力することを特徴とする請求項１に記載の通信端末。
4. 送信側通信端末から送られてきた文字情報を受信し、文字情報を受信側通信端末に転送するチャット手段と、
   必要に応じて受信した文字情報を受信側通信端末が希望する文字表現に変換する文字表現変換手段と
   を備えたことを特徴とする通信サーバー。
5. 接続時に被呼通信端末にメール送信あるいは電話発呼して被呼状態を通知する呼び出し手段を備えたことを特徴とする請求項４に記載の通信サーバー。
6. 請求項１乃至３のいずれかに記載された通信端末と、
   請求項４または５のいずれかに記載されたサーバと、
   前記通信端末と前記サーバーとを接続する通信網と
   からなることを特徴とする通信システム。

Images