説明

通信端末、通信サーバーおよび通信システム

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

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信端末、通信サーバーおよび通信システムに関するものであり、特に視覚聴覚障害者、視覚障害者、聴覚障害者、健常者が相互に通信可能な通信端末、通信サーバーおよび通信システムに関するものである。
【背景技術】
【0002】
従来、通信手段として音声通話や電子メールの機能を備えた携帯電話機が普及しているが、視覚および聴覚の双方の障害を持つ視覚聴覚障害者同志あるいは視覚聴覚障害者と健常者が遠隔で通信することは、音声や電子メールの通信方式では不可能である。また、聴覚障害者には音声通信は不可能であり、視覚障害者には電子メール等の文字通信は不可能である。従って、視覚障害者と聴覚障害者が通信するには音声や電子メールの通信方式は使用できない。
【0003】
そこで、視覚聴覚障害者などのための通信装置として各種のものが提案されている。下記の特許文献1には、視覚と聴覚の二重障害者向けの、特定小電力型の小型無線通信機を用いた携帯用の個人呼出及び意志伝達装置が開示されている。
【0004】
この装置は、電波の送受信が可能な一対の無線機部と、この無線機部の受信電気信号を入力信号とし、入力信号の立ち上がりによって起動する振動発生手段をそれぞれ具備するページャー部からなる無線機一体型の相互呼出機能を有する呼出装置であって、送信機能としてボタンスイッチによるモールス信号の入力部を有し、受信側にモールス信号弁別のためのロジック回路,マイコン部,モータ起動スイッチング回路,及び電力制御回路の信号処理回路を有する携帯用小型無線バイブレータ装置である。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開平9−248315号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
上記したような従来の通信装置は、視覚聴覚障害者同志あるいは視覚聴覚障害者と健常者が通信するために特殊な端末を使用しているので、端末が高価であり、汎用性や拡張性に乏しいという問題点があった。また、文字情報の入力方式、出力方式が限られており、視覚聴覚障害者、視覚障害者、聴覚障害者、健常者それぞれに適した入力方式、出力方式を選択出来ないという問題点もあった。本発明の目的は、上記した従来の問題点を解決し、視覚聴覚障害者、視覚障害者、聴覚障害者、健常者が相互に通信可能な通信端末、通信サーバーおよび通信システムを提供することにある。
【課題を解決するための手段】
【0007】
本発明の通信端末は、点字パターンあるいはモールス信号パターンによって表される文字情報を入力するキー入力手段と、前記点字パターンあるいはモールス信号パターンによって表される文字情報を長点および短点の組み合わせからなる振動パターンで出力する振動出力手段と、チャット手段を備えた通信サーバーと接続し、前記キー入力手段によって入力された前記文字情報を送信し、前記通信サーバーから前記文字情報を受信して前記振動出力手段に出力する通信手段とを備えたことを主要な特徴とする。
【0008】
また、上記した通信端末において、前記振動出力手段は点字パターンによって表される文字情報を出力する場合に前記振動パターンの末尾の短点を省略して出力する点にも特徴がある。また、上記した通信端末において、市販の携帯電話機に本発明の機能を実現するプログラムを実装し、前記振動出力手段は前記携帯電話機に装備されているバイブレータを駆動して振動出力する点にも特徴がある。
【0009】
本発明の通信サーバーは、送信側通信端末から送られてきた文字情報を受信し、文字情報を受信側通信端末に転送するチャット手段と、必要に応じて受信した文字情報を受信側通信端末が希望する文字表現に変換する文字表現変換手段とを備えたことを主要な特徴とする。
【0010】
また、上記した通信サーバーは、接続時に被呼通信端末にメール送信あるいは電話発呼して被呼状態を通知する呼び出し手段を備えた点にも特徴がある。
【0011】
本発明の通信システムは、上記した通信端末と、上記したサーバーと、前記通信端末と前記サーバーとを接続する通信網とからなることを主要な特徴とする。
【発明の効果】
【0012】
本発明によれば、以下のような効果がある。
【0013】
(1)既存の携帯電話上で動作する本発明の機能を実現するアプリケーションプログラムを使用するだけで、視覚聴覚障害者同志あるいは視覚聴覚障害者と健常者などが対話するためのメッセージ交換用端末を実現できる。
【0014】
(2)携帯電話機のキー入力手段を用いて6点点字入力方式、8進2桁点字入力方式、モールスパターン入力方式、既存のカナ入力方式、音声認識入力方式などを選択可能であり、出力方式としては、6点点字パターン出力方式、モールスパターン出力方式、既存の画面文字表示方式、文字読み上げ音声出力方式などを選択可能であるので、視覚聴覚障害者、視覚障害者、聴覚障害者、健常者それぞれに適した入力方式、出力方式を選択できる。
【0015】
(3)被呼端末がオフラインの場合に、通信サーバーから被呼端末にメール送信あるいは電話発呼して着信(被呼状態、通信要求)を通知することにより、通常の電話と同様に被呼者を呼び出すことができる。
【0016】
(4)通信端末としては携帯電話機の他、視覚障害者、聴覚障害者、健常者であればインターネット接続可能なパソコンや携帯データ端末をそのまま利用可能であり、パソコンに振動出力装置を接続すれば視覚聴覚障害者も利用可能である。
【0017】
(5)点字、モールスパターン、カナ相互のモード変換を通信サーバーにおいて行うことにより、通信端末のプログラム容量や処理負荷が軽減されると共に、モード変換機能の追加、更新が容易となる。
【0018】
従って、本発明により身体の接触でしかコミュニケーションを取ることができなかった視覚聴覚障害者が離れたところにいる家族や介助者とコミュニケーションできるようになり、介助のため家を空けることができなかった家族にも精神的、時間的な余裕が生まれる。
【図面の簡単な説明】
【0019】
【図1】図1は本発明を実施可能なシステム全体の構成を示すブロック図である。
【図2】図2は通信端末の一般的な構成例を示すブロック図である。
【図3】図3は携帯端末における本発明のアプリの表示例を示す説明図である。
【図4】図4は本発明のアプリによる各種の入力方式を示す説明図である。
【図5】図5は本発明において使用する通信メッセージの例を示す説明図である。
【図6】図6は端末サーバー間で通信時にやり取りされるデータの内容を示す説明図である。
【図7】図7は本発明のアプリによる各種の出力方式を示す説明図である。
【図8】図8は本発明のアプリの機能を示す機能ブロック図である。
【図9】図9は本発明のサーバーの機能を示す機能ブロック図である。
【図10】図10は本発明のサーバーにおけるセッション管理DBの内容例を示す説明図である。
【図11】図11は本発明における登録処理の手順を示すフローチャートである。
【図12】図12は本発明におけるサーバーの処理内容を示すフローチャートである。
【図13】図13は本発明におけるサーバーの待機中処理を示すフローチャートである。
【図14】図14は本発明におけるサーバーの呼び出し中処理を示すフローチャートである。
【図15】図15は本発明におけるサーバーの話中処理を示すフローチャートである。
【図16】図16は本発明におけるサーバーの被呼中処理を示すフローチャートである。
【図17】図17は本発明におけるサーバーの通話中処理を示すフローチャートである。
【図18】図18は本発明における端末アプリの処理内容を示すフローチャートである。
【発明を実施するための形態】
【0020】
以下に図面を参照して実施例について説明する。
【実施例1】
【0021】
図1は本発明を実施可能なシステム全体の構成を示すブロック図である。本発明による通信システムは、インターネットに接続可能な携帯電話機等の一対の端末装置と、インターネットに接続された通信サーバーによって構成される。インターネット20やインターネット20と接続されている携帯電話網21、22、公衆無線データ通信網23、有線電話網24は周知である。
【0022】
端末装置としは、携帯電話網21、22を介してインターネット20と接続可能な一般的な携帯電話機30の他、携帯電話機30に振動出力装置A31を装着したもの、本発明専用の入出力装置を備えた専用携帯端末装置35、インターネット20あるいはインターネット20に接続された公衆無線データ通信網23に接続された周知のPC(パソコン、携帯データ端末を含む)あるいはPCに振動出力装置D26を接続したものを使用できる。
【0023】
振動出力装置A31、D26は例えば振動モータ等の振動装置を2個、6個あるいはそれ以上備えたものであり、携帯電話機30あるいはPC25とUSBやその他の有線あるいは無線インターフェイスによって接続され、携帯電話機30あるいはPC25にインストールされた本発明によるアプリプログラムから各振動装置を個別に制御可能な構成を備えている。
【0024】
専用携帯端末装置35は、例えば通常の携帯電話機に6点点字入力用のキーボードや2点あるいは6点振動点字出力機能を付加した本発明専用の端末装置である。なお、本発明においては端末とサーバー間においてはパケット通信方式のみを使用し、音声通話方式は使用しないので、音声通話機能の無い携帯データ端末も使用可能である。
【0025】
インターネット20に接続されている通信サーバーシステム10は、Webサーバー、メールサーバー、アプリサーバー、データベース(DB)サーバー等の機能を備えたサーバーシステムでり、1台あるいはLANによって接続された複数台の市販のサーバー装置に本発明の機能を実現するプログラムを実装することにより実現できる。
【0026】
図2は通信端末の一例である携帯電話機の一般的な構成例を示すブロック図である。RF処理回路41はアンテナ42を備え、携帯電話網の基地局とデータの送受信を行う。ベースバンド処理、ネットワーク処理制御回路40はCPU、ROM、RAM、フラッシュメモリ等を備え、無線通信とネットワーク手続きの制御を行う。
【0027】
アプリケーション処理、ユーザインターフェイス処理制御回路50はやはりCPU、ROM、RAM、フラッシュメモリ等を備え、アプリ(アプリケーションプログラム)をサーバーからダウンロードしてインストールし、実行することが出来るように構成されている。本発明においては一般的な携帯電話機あるいはPCに本発明のアプリをダウンロードしてインストールすることにより本発明の端末装置として使用する。
【0028】
携帯電話機30は更に、テンキー入力装置43、マイク44、アプリから制御可能な振動モーター45、液晶等の表示装置46、スピーカ47、デジタル入出力コネクタ48、アナログ入出力コネクタ49を備えている。デジタル入出力コネクタ48あるいはアナログ入出力コネクタ49を介して振動出力装置A31、D26を接続可能である。
【0029】
本発明による通信を行う場合に、視覚聴覚障害者の場合には、テンキー入力装置43を用いた点字あるいはモールスパターンの入力を使用し、出力としては振動モーター45を使用した振動パターンによる6点点字出力あるいはモールスパターン出力を使用する。視覚障害者の場合には、視覚聴覚障害者と同様の入出力方式を使用するか、あるいは入力として通常の文字入力(カナ入力)、出力としてスピーカ47を使用した文字読み上げ音声出力を使用する。聴覚障害者および健常者は通常の文字入力(カナ入力)および表示装置46への文字表示を使用する。
【0030】
図3は携帯端末における本発明のアプリの表示例を示す説明図である。図3においては、相手端末と通信中の状態を示しており、左は6点点字入力方式を使用している場合の表示例、右はモールスパターン入力方式を使用している場合の表示例である。
【0031】
左の6点点字入力方式の例においては、表示装置46の上段の接続相手表示領域61には相手IDとして「1234」ニックネームとして「タロウ」が表示されている。これらの情報はサーバーから取得する。なお、通信状態以外の場合には接続相手表示領域61にはオフライン、オンライン、ダイヤル中、被呼中などの端末内部状態を表示する。受信文表示領域64には「モシモシ タロウデス」という受信文字列が表示されており、送信文表示領域65には入力中の文字列(確定した文字)「コンニ」が表示されている。
【0032】
点字パターン表示領域63には、現在入力中の文字の点字パターンが表示されており、入力中文字表示領域62には点字パターン表示領域63に表示されている点字と対応するカナ文字「チ」が表示されている。なお、テンキー装置43の内、6点点字入力方式においては、点字入力使用キー60として例えば「0」〜「9」、「*」、「#」を使用する。
【0033】
右のモールスパターン入力方式においては、点字パターン表示領域63がモールスパターン表示領域66に替わっている以外は6点点字入力方式と同じである。なお、モールスパターン入力方式においては、モールス入力使用キー67として「0」、「3」〜「6」、「9」、「*」、「#」を使用する。
【0034】
図4は本発明のアプリによる各種の入力方式を示す説明図である。図4(a)は通常の携帯電話機が備えている既存のカナ入力方式であり、例えばカナ入力モードにしてテンキーの「4」を2回押下し、確定キーを押下するか他の次の文字入力操作をすれば「チ」となる。
【0035】
図4(b)は6点点字入力方式を示す説明図である。図4の中央に示すように点字の各点にはそれぞれ1〜6の番号が付いている。本発明の6点点字入力(パターン)方式においては、点字の1番をテンキーの「1」に、以下2を「4」、3を「7」、4を「2」、5を「5」、6を「8」に割り当てている。更に、「6」は文字確定、「9」はクリヤ、「*」は文字列送信、「#」は終話の指示用にそれぞれ使用する。
【0036】
例えば6点点字入力方式で「チ」を入力する場合には「1」「4」「5」「7」を任意の順序で押下することにより、図3左に示す状態となる。ここで「6」を押下すると文字「チ」が確定し、送信文の末尾に追加されると共に、「チ」に相当する6点点字パターンが振動出力される。この振動パターンは、点字の1〜6番の順に、点がある(突起、図3では黒丸)場合には長い振動、点が無い(平坦、図3では白丸)場合には短い振動を出力するものである。
【0037】
図4(c)は8進数2桁入力方式を示す説明図である。8進数2桁入力方式は、点字の1番〜3番および4番〜6番の点の有り無しを0〜7の8進数2桁で入力する入力方式である。例えば「チ」の場合には2進で表すと「111010」となり、8進では「7」「2」となる。この入力方式の場合には、8進2桁のコードを覚える必要があるが、テンキーを2回押下するだけで全ての点字を入力可能であり、6点点字入力方式よりも少ない操作で点字を早く入力可能である。
【0038】
図4(d)は2点モールスパターン入力方式を示す説明図である。モールス信号のパターンは長点と短点の並び順によって決まるので、例えば短点をテンキーの「4」に、長点を「5」に、文字の確定を「6」に割り当て、「チ」の場合には「4」「4」「5」「4」と順に押下することによりモールスバターンを入力して「6」で確定する。
【0039】
入力された文字列はそれぞれの入力方式と対応した文字列として通信サーバーに送信される。カナ入力方式の場合にはテキスト情報(ユーザが送受信したい文字)がURLエンコードされる。例えば全角の「チ」を表す3ビットのユニコード(Unicode)を表す文字列「%E3%83%81」が送信される。カナのコードはユニコードの他、シフトJISコード、JIS8ビットコードであってもよい。なお、文字列に変換せずに「チ」を表すユニコードをそのまま送信してもよい。
【0040】
6点点字入力方式の場合にはテンキー装置において押下されたキーと対応する文字列「14576*」が、8進数2桁入力方式の場合には「72*」が送信される。(「*」は送信キーで、無くてもよい)また、モールスパターン入力方式の場合にはやはりテンキー装置において押下されたキーと対応する文字列「44546*」が送信される。なお、6点点字入力方式、8進数2桁入力方式の場合に入力キー文字列を点字コードに変換して点字コードを送信してもよい。また、モールスパターン入力方式の場合に入力キー文字列をモールスパターンコードに変換してモールスパターンコードを送信してもよい。
【0041】
図5は本発明において使用する通信メッセージの例を示す説明図である。通信メッセージは、メッセージ種別情報とテキスト情報から構成され、それぞれ文字列によって表現される。メッセージ種別は、入出力モード(MODE)、言語(LANG)、文字種別(CHAR)を含む。それぞれの情報の区切りとして文字「&」を使用する。
【0042】
入出力モード(MODE)としては、例えば6点点字(BRAIL)、8進数点字(OCTET)、モールス(MORSE)、文字(CHAR:ユニコード)を含む。言語(LANG)としては、例えば日本語(JA)、韓国語(KR)、英語(EN)、中国語(CN)、ドイツ語(DR)、フランス語(FR)などを含む。文字種別(CHAR)としては、例えば英文(ALPHA)、数字(NUMERIC)、カナ(KANA)を含む。なお文字種別のKANAはユニコードを標準とするが、異なる文字を定義してシフトJISコードやEUC-JPコードを割り当ててもよい。
【0043】
メッセージとして例えば「チ」に相当する点字情報を送る場合には、メッセージの文字列は「MODE=BRAIL&LANG=JA&CHAR=KANA&TEXT=14576*」となる。また、カナで送る場合には「MODE=CHAR&LANG=JA&CHAR=KANA&TEXT=%E3%83%81」となる。
【0044】
図6は端末サーバー間で通信時にやり取りされるデータの内容を示す説明図である。端末サーバー間においてはHTTP/HTTPSプロトコルを使用してパケット通信を行う。HTTP/HTTPSはインターネット上のWebサーバーからホームページの閲覧やプログラムのダウンロード取得に利用されるプロトコルである。HTTP/HTTPSはリクエスト・レスポンス型のプロトコルである。すなわち、クライアントがサーバーにリクエストメッセージを送信し、サーバーがそれに応じたレスポンスメッセージを返す。1回のリクエスト・レスポンスは独立で、他のリクエスト・レスポンスに関与しない。
【0045】
そこで、1つのセッション(端末アプリが通信サーバーにアクセスしてからオフラインになるまで)について端末を特定するためにサーバーからセッションIDを発行し、セッション中の2回目以降のアクセス時には端末からのアップロードデータにこのセッションIDを記載することにより端末の認証を行う。
【0046】
接続時には自ID、パスワードと共に、自端末から送信するアップ文字モード種別およびサーバーから送信してほしいダウン希望モード情報を送信する。これらの情報は予め端末アプリに設定しておく。ダイヤル時には相手情報として相手IDの代わりにサーバーに予め登録されている相手ニックネームを送信してもよい。ニックネームはユーザ登録時にユーザが入力し、ユニークであれば承認され、ユーザーDBに登録される。
【0047】
図6(A)は通信状態(ESTA)における端末からのアップロードデータ例を示す説明図である。通信状態における端末からのアップロードデータには、セッションIDの他、ユーザーID、接続要求、ダイヤル要求、文字列送信、問い合わせ、終話、切断通知等のリクエスト、通信状態にある相手ID、図5に示した通信メッセージ(送信すべきメッセージがある場合)が含まれている。
【0048】
図6(B)は通信状態における端末へのダウンロードデータ例を示す説明図である。通信状態における端末へのダウンロードデータには、セッションID、ユーザーIDの他、接続承認、ダイヤル中、文字列受信、終話通知、切断通知等のレスポンス、通信状態にある相手ID、ダウンロードメッセージ(メッセージがある場合)が含まれている。
【0049】
本発明においては、端末からは設定されている入力モードと対応した文字列でメッセージを通信サーバーに送信する。従って、端末から送信される文字列が相手端末が希望する受信モードと異なる場合にはサーバーにおいてモード(文字列種別)の変換処理を行う。また、例えば受信希望するモードが点字である場合に、端末においては、受信した点字文字列と対応する文字を画面に表示するためにカナコードも必要である。しかし、モード変換処理は複雑であり、正確に変換するためには処理負荷やプログラム容量が大きくなってしまうという課題があった。
【0050】
そこで、本発明においては、通信サーバーにおいて受信した文字列のカナ文字列への変換を必ず行い、サーバーから端末が希望する受信モードがカナ以外の場合には、端末が希望する受信モードの文字列と共に表示用のカナ文字列も付けて送るようにする。このようにすれば端末において表示用のモード変換処理が不要となり、端末アプリの処理負荷やプログラム容量が軽減される。
【0051】
図6(B1)は、図5に示した端末からの送信メッセージ例に対して、ダウンロードメッセージとして、点字と文字(カナ)の双方と対応する文字列を送る例である。ダウンロードメッセージは「MODE=BRAIL,CHAR&LANG=JA&CHAR=KANA&TEXT=14576,%E3%83%81」となり、MODEに「CHAR」が追加されると共に、テキスト情報2の「%E3%83%81」が追加されている。
【0052】
図7は本発明のアプリによる各種の出力方式を示す説明図である。本発明における出力方式としては、画面への文字表示の他、振動出力、音声出力、文字情報デジタル出力(USB、赤外線、Bluetooth)、文字情報アナログ出力(DTMF、FSK)を備える。振動出力としては、1点(振動子が1個)点字パターン出力方式およびモールスパターン出力方式の2方式があり、1点点字パターン出力方式においては、末尾の短点を省略して出力することも可能である。音声出力には文字読み上げ音声出力方式およびモールスパターンに基づくモールス音出力がある。
【0053】
例えば文字「チ」を出力する場合、図7(a)のカナ出力においては、受信した文字のユニコードをそのまま画面に表示する。図7(b)の1点点字出力方式においては、受信した文字列の内、ユニコードをそのまま画面に表示すると共に、点字文字列は1点点字パターンに変換して振動出力する。
【0054】
この振動パターンは前述したように、点字の1〜6番の順に、点がある(突起、図3では黒丸)場合には長い振動(長点:例えば短点の3倍の長さ)、点が無い(平坦、図3では白丸)場合には短い振動(短点)を出力するものである。このとき、括弧書きで図示されているように末尾の短点を省略して出力することも可能である。
【0055】
図7(c)のモールスパターン出力方式においては、受信した文字列の内、ユニコードを画面に表示すると共に、モールス文字列は周知の長い振動(長点)と短い振動(短点)の組み合わせからなるモールス信号パターンに変換して振動出力する。
【0056】
図8は本発明のアプリの機能を示す機能ブロック図である。キー入力処理部84はテンキー85のいずれかが押下された場合にFIFOバッファ83に押下されたキーの情報を格納すると共に、必要に応じて各出力処理部の入力FIFOバッファへも書き込む。通信処理部71は、送信バッファ73に送信すべき情報が格納されていれば、パケットを生成して送信し、受信したパケットのデータを受信バッファ72に格納する。
【0057】
制御処理部70は、詳細は後述するが、受信バッファ72およびキー入力用のFIFOバッファ83の内容をチェックし、データが入力されている場合にはそのデータを読み出して解析し、必要な処理を実行する。そして、出力すべきFIFOバッファ80および必要(設定)に応じてFIFOバッファ74、77の内の少なくとも1つに文字情報を書き込む。
【0058】
画面出力処理部81はFIFOバッファ80に文字情報が書き込まれていればそれを読み出し、表示装置82に表示する。振動出力処理部75は、FIFOバッファ74に文字列が書き込まれていればそれを読み出し、指定された種別の振動パターンに変換してバイブレータ76(=振動モータ45)を駆動する。音声出力処理部78は、FIFOバッファ77に文字情報が書き込まれていればそれを読み出し、指定された種別の音波形信号に変換してスピーカー79(=47)を駆動する。
【0059】
図9は本発明の通信サーバーの機能を示す機能ブロック図である。パケット受信部98は端末からパケットを受信し、周知のWebサーバプログラム97に送る。Webサーバプログラム97は受信したパケットの内容を解析し、登録処理の場合にはCGIプログラムによって構成された登録処理部92を起動する。
【0060】
登録処理部92はユーザーDB93へのユーザー登録/更新処理(ユーザ情報の登録、IDの発行)、端末の種類に適合した端末アプリのダウンロード処理を実行する。ユーザーDB93には例えば、氏名、住所、ユーザID、ニックネーム、メールアドレス、端末電話番号、アップロードモード種別、ダウンロードモード種別、ダウンロードしたアプリのバージョン情報等が登録される。
【0061】
受信したパケットの内容が接続、通信処理の場合にはWebサーバプログラム97はCGIプログラムによって構成された接続、通信処理部90(91)を起動する。発呼者用の接続、通信制御部90と被呼者用の接続、通信制御部91は同じ機能を有している。接続、通信制御部90は、詳細は後述するが、受信したパケットの内容に応じてセッション管理DB94の更新、モード変換部95を使用したメッセージのモード変換、オンラインユーザ毎に割り当てた受信ボックス96(受信データ格納領域)への文字列の書き込み、被呼端末の呼び出し等の接続、通信処理を実行する。
【0062】
また、端末からパケットを受信した時に、当該端末と対応する受信ボックスに文字列が格納されていた場合には、そのデータを読み出して応答パケットを生成し、Webサーバプログラム97、パケット送信部97を介して対応する端末に送信する。モード変換部95は、例えばカナ→点字、点字→カナ、点字→モールス、モールス→点字、カナ→モールス、モールス→カナ変換機能を備える。
【0063】
図10は本発明のサーバーにおけるセッション管理DBの内容例を示す説明図である。セッション管理DB94は、オンライン状態の端末を管理するためのデータベースであり、端末がサーバーに接続(オンライン待機状態)を要求してきた時にセッションが登録され、切断通知によって削除される。
【0064】
セッション管理DBには、ユーザID、セッションID、ユーザー認証の寿命、端末状態、状態更新時刻、アップロードモード種別、ダウンロードモード種別、(BR=BRAIL、MO=MORSE、CH=CHAR、KA=KANA、AL=ALPHA)相手ユーザーID、受信ボックス番号、シフトフラグ等が記録される。端末状態は、待機中(ONLN:オンライン)、ダイアル中(DIAL)、通信中(ESTA)、被呼中(CALL)、話中(BUSY)などの端末の状態を示す。
【0065】
状態更新時刻は現在の端末状態になった時刻であり、これにより設定時間が経過したか否かを判定する。なお、セッション管理DBにニックネームも記録するようにしてもよい。また、点字における外字(英字)シフト状態、数字シフト状態あるいは和文モールスパターンにおける英文シフト状態等を記憶するためのフラグ情報を記録してもよい。
【0066】
図11は本発明における登録処理の手順を示すフローチャートである。まず、T01においては、端末(携帯電話機)のブラウザを起動し、通信サーバーのURLにアクセスする。S01においては、サーバーから端末にユーザ登録に必要な事項の記入欄を備えたホームページ(HP)を送信する。T02においては、登録に必要な情報を入力した後、端末からユーザ登録要求を送信する。
【0067】
S02においては、サーバーにおいて登録要求情報を確認してユーザ登録OKであればユーザIDを生成し、ユーザデータベースに登録事項を登録すると共にユーザーに通知する。
【0068】
T03においては、端末から機種を指定してアプリのダウンロード(DL)を要求し、S03においては、サーバーから対応するアプリをダウンロードする。T04においては、端末においてアプリを受信して保存し、T05においては、アプリを端末にインストールして実行する。T06においては、アプリにユーザID、パスワード、入力方式、出力方式等の設定情報を入力し保存する。
【0069】
図12は本発明におけるサーバーの処理内容を示すフローチャートである。通信サーバーは通信端末同士のチャット処理を行い、必要ならば文字モードを変換する。また、接続時には被呼端末がオフラインの場合、被呼端末あてにメール送信あるいは電話発呼して着信(通信要求)を通知する。ユーザーはアプリを手動で起動して応答する。
【0070】
S10においては、いずれかの端末からアクセスが有ったか否かが判定され、肯定の場合にはS11に移行する。S11においては、セッションオープン処理が行われる。具体的には、セッション管理BDに接続してセッションIDによってセッション管理DBを検索する。S12においては、セッション情報がセッション管理DBに未登録か否かが判定され、判定結果が否定の場合にはS14に移行するが、肯定の場合にはS13に移行する。S13においてはセッション登録処理が行われる。即ち、新たにセッションIDを生成し、セッション管理DBに新たにセッション情報を登録する。この際、「状態」の初期値は待機中(ONLN)とする。
【0071】
S14においては、ユーザ認証処理が行われる。即ち、ユーザIDおよび正当なパスワードあるいは正当なセッションIDが記載されていれば登録ユーザと判定される。S15においては、登録ユーザーからのアクセスか否かが判定され、判定結果が否定の場合にはS17に移行するが、肯定の場合にはS16に移行する。S16においては、図11において説明したユーザー登録、ダウンロード処理が行われる。S17においてはセッション管理DBを検索し、端末の「状態」情報を読み出す。
【0072】
S18においては、「状態」情報が待機中(ONLN)か否かが判定され、判定結果が否定の場合にはS20に移行するが、肯定の場合にはS19に移行する。S19においては、後述する待機中(ONLN)処理が行われ、S28に移行する。
【0073】
S20においては、「状態」情報が呼出し中(DIAL)か否かが判定され、判定結果が否定の場合にはS22に移行するが、肯定の場合にはS21に移行する。S21においては、後述する呼出し中(DIAL)処理が行われ、S28に移行する。S22においては、「状態」情報が話中(BUSY)か否かが判定され、判定結果が否定の場合にはS24に移行するが、肯定の場合にはS23に移行する。S23においては、後述する話中(BUSY)処理が行われ、S28に移行する。
【0074】
S24においては、「状態」情報が被呼中(CALL)か否かが判定され、判定結果が否定の場合にはS26に移行するが、肯定の場合にはS25に移行する。S25においては、後述する被呼中(CALL)処理が行われ、S28に移行する。S26においては、「状態」情報が通話中(ESTA)か否かが判定され、判定結果が否定の場合にはS28に移行するが、肯定の場合にはS27に移行する。S27においては、後述する通話中(ESTA)処理が行われ、S28に移行する。
【0075】
S28においては、リクエストが切断か否かが判定され、判定結果が否定の場合にはS30に移行するが、肯定の場合にはS29に移行する。S29においては、セッション管理DBからセッション情報を削除する。S30においては、セッションクローズ処理が行われる。具体的には、セッション情報のユーザ認証の寿命更新、状態更新時刻の更新、セッション情報の保存などを行う。
【0076】
図13は本発明におけるサーバーの待機中処理(S19)を示すフローチャートである。S50においては、リクエストを抽出し、解析する。S51においては、リクエストが問い合わせ(ENQ)か否かが判定され、判定結果が否定の場合にはS53に移行するが、肯定の場合にはS52に移行する。S52においては、レスポンスとして「待機中(ONLN)」を返送する。
【0077】
S53においては、呼出し(DIAL)か否かが判定され、判定結果が否定の場合にはS64に移行するが、肯定の場合にはS54に移行する。S54においては、相手ID=自分か否かが判定され、判定結果が否定の場合にはS55に移行するが、肯定の場合にはS62に移行する。S55においては、セッション管理DBにおいて相手IDを検索する。
【0078】
S56においては、相手はオフライン、即ちセッション管理DBに未登録か否かが判定され、判定結果が否定の場合にはS60に移行するが、肯定の場合にはS57に移行する。S57においては、被呼端末あてに発呼者情報を記入したメールを送信し、呼び出しを通知する。なお、ユーザーが電話呼び出しを希望し、そのように設定されている場合には被呼端末あてに電話(インターネットを使用した電話サービスを含む)にて発呼するようにする。S58においては、レスポンスとして呼出し中(DIAL)を返送する。S59においては、状態を呼出し中に更新する。
【0079】
S60においては、相手は待機中(ONLN)か否かが判定され、判定結果が否定の場合にはS62に移行するが、肯定の場合にはS61に移行する。S61においては、相手ID状態を被呼中に更新し、S58に移行する。S62においては、相手端末の状態が通信中(ESTA)、ダイヤル中(DIAL)、他の端末からの被呼中(CALL)、相手話中(BUSY)状態であるので、レスポンスとして話中(BUSY)状態を返送する。S63においては、状態を話中に更新する。
【0080】
S64においては、切断(EXIT)か否かが判定され、判定結果が否定の場合には処理を終了するが、肯定の場合にはS65に移行する。S65においては、レスポンスとして「切断(EXIT)」を返送する。
【0081】
図14は本発明におけるサーバーの呼び出し中処理(S21)を示すフローチャートである。S70においては、リクエストを抽出し、解析する。S71においては、リクエストが問い合わせ(ENQ)か否かが判定され、判定結果が否定の場合にはS80に移行するが、肯定の場合にはS72に移行する。S72においては、セッション管理DBにおいて相手IDを検索する。
【0082】
S73においては、相手は自IDと通信中(ESTA)か否かが判定され、判定結果が否定の場合にはS76に移行するが、肯定の場合にはS74に移行する。S74においては、レスポンスとして通信中(ESTA)を返送する。S75においては、状態を通信中に更新する。
【0083】
S76においては、相手は待機中(ONLN)か否かが判定され、判定結果が否定の場合にはS78に移行するが、肯定の場合にはS77に移行する。S77においては相手IDの状態を被呼中(CALL)に更新し、S80に移行する。S78においては、相手は被呼中(CALL)か否かが判定され、判定結果が否定の場合にはS79に移行するが、肯定の場合にはS80に移行する。
【0084】
。S79においては、呼び出し中状態になってから予め定められた時間(例えば数分)が経過したか否かが判定され、判定結果が否定の場合にはS80に移行するが、肯定の場合にはS81に移行する。S80においては、レスポンス呼出し中(DIAL)を返送する。S81においては、レスポンスとして待機中(ONLN)を返送し、S82においては、状態を待機中に更新する。
【0085】
S83においては、終話(FIN)か否かが判定され、判定結果が否定の場合にはS88に移行するが、肯定の場合にはS84に移行する。S84においてはセッション管理DBにおいて相手IDを検索する。S85においては、相手IDの状態を待機中(ONLN)に更新する。S86においては、レスポンスとして「待機中(ONLN)」を返送する。S87においては、状態を待機中(ONLN)に更新する。
【0086】
S88においては、切断(EXIT)か否かが判定され、判定結果が否定の場合には処理を終了するが、肯定の場合にはS89に移行する。S89においては、レスポンスとして「切断(EXIT)」を返送する。
【0087】
図15は本発明におけるサーバーの話中処理(S23)を示すフローチャートである。S90においては、リクエストを抽出し、解析する。S91においては、リクエストが問い合わせ(ENQ)か否かが判定され、判定結果が否定の場合にはS93に移行するが、肯定の場合にはS92に移行する。S92においては、レスポンスとして「話中(BUSY)」を返送する。
【0088】
S93においては、終話(FIN)か否かが判定され、判定結果が否定の場合にはS96に移行するが、肯定の場合にはS94に移行する。S94においては、レスポンスとして「待機中(ONLN)」を返送し、S95においては状態を待機中(ONLN)に更新する。
【0089】
S96においては、切断(EXIT)か否かが判定され、判定結果が否定の場合には処理を終了するが、肯定の場合にはS97に移行する。S97においては、レスポンスとして「切断(EXIT)」を返送する。
【0090】
図16は本発明におけるサーバーの被呼中処理(S25)を示すフローチャートである。S100においては、リクエストを抽出し、解析する。S101においては、リクエストが問い合わせ(ENQ)か否かが判定され、判定結果が否定の場合にはS107に移行するが、肯定の場合にはS102に移行する。S102においては、セッション管理DBにおいて相手IDを検索する。
【0091】
S103においては、相手はダイヤル中(DIAL)か否かが判定され、判定結果が否定の場合にはS105に移行するが、肯定の場合にはS104に移行する。S104においては、レスポンスとして被呼中(CALL)を返送する。S105においては、レスポンスとして待機中(ONLN)を返送し、S106においては、状態を待機中に更新する。
【0092】
S107においては、応答(OFHK)か否かが判定され、判定結果が否定の場合にはS111に移行するが、肯定の場合にはS108に移行する。S108においては受信ボックスを割り当て、S109においては、レスポンスとして「通信中(ESTA)」を返送し、S110においては状態を通信中(ESTA)に更新する。
【0093】
S111においては、切断(EXIT)か否かが判定され、判定結果が否定の場合には処理を終了するが、肯定の場合にはS112に移行する。S112においては、レスポンスとして「切断(EXIT)」を返送する。
【0094】
図17は本発明におけるサーバーの通話中処理(S27)を示すフローチャートである。S120においては、リクエストを抽出し、解析する。S121においては、リクエストが問い合わせ(ENQ)か否かが判定され、判定結果が否定の場合にはS128に移行するが、肯定の場合にはS122に移行する。S122においては、セッション管理DBにおいて相手IDを検索する。
【0095】
S123においては、相手は通話中(ESTA)か否かが判定され、判定結果が否定の場合にはS125に移行するが、肯定の場合にはS124に移行する。S124においては、受信ボックス内に受信データがあれば受信データを添付して、レスポンスとして通信中(ESTA)を返送する。S125においては受信ボックスを解放し、S126においては、レスポンスとして待機中(ONLN)を返送し、S127においては状態を待機中に更新する。
【0096】
S128においては、送信(SEND)か否かが判定され、判定結果が否定の場合にはS134に移行するが、肯定の場合にはS129に移行する。S129においては、セッション管理DBにおいて相手IDを検索する。S130においては、相手は通話中(ESTA)か否かが判定され、判定結果が否定の場合にはS125に移行するが、肯定の場合にはS131に移行する。
【0097】
S131においては、必要に応じてモード変換処理が行われる。例えば送受信とも点字モードの端末と、送受信ともモールスモードの端末が通信する場合には、サーバーで受信された点字文字列はカナ文字列およびモールスパターン文字列の双方にモード変換され、例えば図6(B1)に示すようなフォーマットで双方の文字列が相手端末に送信される。また、サーバーで受信されたモールス文字列はカナ文字列および点字文字列の双方に変換され、やはり図6(B1)に示すようなフォーマットで双方の文字列が端末に送信される。モード変換においては、例えば点字表現の文字列を一旦点字コードに変換し、予め定められている変換テーブルを引いて、文字モードやモールスモードの文字列に変換する。
【0098】
S132においては、相手のモードに合わせた通信メッセージが相手受信ボックスに書き込まれる。S133においては、受信ボックス内に受信データがあれば受信データを添付して、レスポンスとして通信中(ESTA)を返送する。
【0099】
S134においては、終話(FIN)か否かが判定され、判定結果が否定の場合にはS137に移行するが、肯定の場合にはS135に移行する。S135においては、レスポンスとして待機中(ONLN)を返送し、S136においては、状態を待機中に更新する。S137においては、切断(EXIT)か否かが判定され、判定結果が否定の場合には処理を終了するが、肯定の場合にはS138に移行する。S138においては、レスポンスとして「切断(EXIT)」を返送する。
【0100】
図18は本発明における端末アプリの処理内容を示すフローチャートである。アプリは設定されているモードと対応して入力された文字あるいは押下したキー情報をそのままサーバーに送信し、サーバーから受信した文字あるいはキー情報を設定されている出力手段に出力する。アプリ、サーバー間はHTTP通信を行う。
【0101】
S150においては、保存されている設定情報を読み出して初期設定を行い、端末内部状態をオフライン状態に設定する。S151においては、通信サーバーに接続要求(ONLN)を送信し、レスポンスを受信する。S152においては、受信したレスポンスが被呼(CALL)か否かが判定され、判定結果が否定の場合にはS153に移行するが、肯定の場合にはS154に移行する。
【0102】
S153においては、待機(ONLN)状態を画面表示すると共に設定されている出力装置に出力する。また、端末内部状態を待機(ONLN)状態に設定する。S154においては、被呼状態であることおよびレスポンスに含まれる発呼者情報(ID、ニックネーム)を画面表示すると共に設定されている出力装置に出力する。また、端末内部状態を被呼状態に設定する。
【0103】
S155においては、テンキー装置からキー入力が有ったか否かが判定され、判定結果が否定の場合にはS168に移行するが、肯定の場合にはS156に移行する。S156においては、キー入力がダイヤルの開始を指示するものか否かが判定され、判定結果が否定の場合にはS158に移行するが、肯定の場合にはS157に移行する。
【0104】
なお、キー入力情報の意味は、その時点での端末内部状態、入力方式、押下されたキー情報の3種類の情報に基づいて判定される。例えば、待機状態、点字入力方式で「*」キーが押下された場合にはダイヤル開始を意味するものとする。S67においては、端末内部状態をダイヤル中に設定し、ダイヤルバッファをクリヤする。
【0105】
S158においては、キー入力が応答を指示するものか否かが判定され、判定結果が否定の場合にはS160に移行するが、肯定の場合にはS159に移行する。S159においては、通信サーバーに応答リクエストを送信する。S160においては、キー入力が文字入力か否かが判定され、判定結果が否定の場合にはS162に移行するが、肯定の場合にはS161に移行する。
【0106】
S161においては、内部状態がダイヤル中ならダイヤルバッファに、それ以外は入力バッファに書く。なお、文字を確定するキー入力があった場合には、それまでに入力バッファに入力されているキー情報によって決まる文字列を生成して文字列バッファに追加し、入力バッファをクリヤする。
【0107】
S162においては、キー入力が送信を指示するものか否かが判定され、判定結果が否定の場合にはS164に移行するが、肯定の場合にはS163に移行する。S163においては、ダイヤル中の場合にはダイヤルリクエスト、通信中の場合には送信リクエストと共にダイヤルバッファあるいは文字列バッファ中の文字列を送信する。
【0108】
S164においては、キー入力が終話を指示するものか否かが判定され、判定結果が否定の場合にはS166に移行するが、肯定の場合にはS165に移行する。S165においては、サーバーに終話リクエストを送信し、内部状態を待機状態とする。S166においては、キー入力がアプリ終了を指示するものか否かが判定され、判定結果が否定の場合にはS168に移行するが、肯定の場合にはS167に移行する。なお、「アプリ終了」は通信に使用しないソフトキーに割り当てておいてもよい。S167においては、サーバーにアプリ終了を通知し、アプリの処理を終了する。
【0109】
S168においては、サーバーからパケットを受信したか否かが判定され、判定結果が否定の場合にはS178に移行するが、肯定の場合にはS169に移行する。S169においては、サーバーからのレスポンスが相手と接続したか、即ち通信中状態に移行したか否かが判定され、判定結果が否定の場合にはS171に移行するが、肯定の場合にはS170に移行する。S170においては、通信状態を表示、出力する。
【0110】
S171においては、レスポンスが文字列受信か否かが判定され、判定結果が否定の場合にはS173に移行するが、肯定の場合にはS172に移行する。S172においては、設定されている出力装置と対応するバッファに文字列を書き込むことによって文字列を出力する。
【0111】
S173においては、レスポンスが終話か否かが判定され、判定結果が否定の場合にはS175に移行するが、肯定の場合にはS176に移行する。S174においては、終話状態を出力し、内部状態を待機状態にする。S175においては、レスポンスが話中か否かが判定され、判定結果が否定の場合にはS177に移行するが、肯定の場合にはS176に移行する。S176においては、話中状態を出力し、内部状態を相手話中状態にする。S177においては、レスポンスが被呼状態か否かが判定され、判定結果が否定の場合にはS155に移行するが、肯定の場合にはS154に移行する。
【0112】
S178においては、直前のパケット送信から所定の待機時間(例えば5秒)経過したか否かが判定され、判定結果が否定の場合にはS155に移行するが、肯定の場合にはS179に移行する。S179においては、サーバーに問い合わせ(ENQ)リクエストを送信する。この処理は相手からのメッセージをサーバーから読み出すためである。なお、S178の問い合わせの間隔は、通信状態においては短く、待機状態においては通信状態より長くしてもよい。
【実施例2】
【0113】
実施例1においては、オンラインでチャット通信を行う例を開示したが、相手端末が応答せず、オフラインのままでは通信を行うことができない。そこで、実施例2においては、相手がオフラインでも通信可能なメール機能を付加する。まず、サーバーにおいて、全てのユーザー対応にメールボックス(ファイル)を設置する。
【0114】
端末においては、メール作成、送信機能を追加し、メール作成機能においては、複数行の文字列からなるメールを作成し、保存可能とする。メール送信機能においては、ユーザーIDあるいはニックネームで宛先を指定し、作成したメール本文と共にサーバーに送信する。
【0115】
サーバーにおいては、メールを受信した場合には、発信者ID、ニックネーム、受信時刻を付加してメール本文を宛先ユーザーのメールボックスに書き込むと共に、宛先ユーザーにメール着信を知らせるメールを送信する。なおこの通知メールにも発信者ID、ニックネーム、受信時刻、メール本文の内容を記載する。ユーザーはアプリでサーバーに接続することにより、サーバーからのレスポンスでメール着信を知り、メール読み出し指示を行ってメールを受信する。
【0116】
更にサーバーにおいて、予め定められたフォーマットで書かれた通常の電子メールを受信して内容を解析し、宛先のメールボックスにメールを転送する機能を付加すれば、視覚聴覚障害者と健常者が通信する場合、健常者はアプリを使用しなくても携帯電話機が備えている通常のメール機能を使用して通信が可能となる。
【実施例3】
【0117】
実施例1においては、2人のユーザー間で文字通信を行う例を開示したが、3人以上の任意数のユーザーによるチャットが出来るようにすることも可能である。この場合には、オンラインユーザーテーブルの相手ID欄に複数のIDを登録可能に構成し、ユーザーは通信中に更にダイヤル可能にする。また、サーバーにおいて配布する文字列の前に送信者のIDあるいはニックネームを付けて配布する。
【0118】
以上、実施例について説明したが、以下のような変形例も考えられる。実施例においては、通信を行う例を開示したが、本発明の端末およびサーバーを使用することにより、ユーザーによるメモや日記などの文章ファイルの作成、保存、閲覧、編集が可能であり、更にブログとして公開することもできる。実施例においては、端末から入力方式と対応した文字列を送信する例を開示したが、端末内でカナコードなどの所定の文字コードにコード変換し、伝送する文字コードを統一することも可能である。
【0119】
実施例においては、被呼端末がオフラインの場合、メール呼び出しによってユーザーが手動でアプリを起動する例を開示したが、被呼端末がオフラインの場合、メール呼び出しによって、あるいは携帯電話機を開くことによってアプリが自動的に起動するようにできれば応答操作が容易となる。
【0120】
端末アプリは所定の周期でパケットを送信するので、切り忘れが発生した場合、従量制課金の場合には高額の通信費を請求される恐れがある。従って、一定時間文字列の送受信が無い場合にはアプリを終了するようにしてもよい。実施例においては、端末にアプリをインストールする例を開示したが、サーバー上に端末のシミュレータを置き、PC等のブラウザでサーバーにアクセスして通信を行う事も可能である。
【産業上の利用可能性】
【0121】
本発明は視覚聴覚障害者、視覚障害者、聴覚障害者、健常者が相互に通信可能な通信端末、通信サーバーおよび通信システムとして利用可能である。
【符号の説明】
【0122】
10…通信サーバー
11…Webサーバー
12…データベース
13…メールサーバー
14…LAN
20…インターネット
21、22…携帯電話網
23…公衆無線データ通信網
24…有線電話網
25…PC(パソコン)
26、31…振動出力装置
30…通信端末(携帯電話機)
35…専用端末装置

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

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate

【図15】
image rotate

【図16】
image rotate

【図17】
image rotate

【図18】
image rotate


【公開番号】特開2010−245795(P2010−245795A)
【公開日】平成22年10月28日(2010.10.28)
【国際特許分類】
【出願番号】特願2009−91661(P2009−91661)
【出願日】平成21年4月6日(2009.4.6)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.Bluetooth
【出願人】(501200778)
【出願人】(509098515)
【出願人】(509097781)
【出願人】(509098526)
【出願人】(599161269)
【出願人】(509098537)
【出願人】(509098548)
【出願人】(509098560)
【出願人】(507289128)
【出願人】(592173663)
【出願人】(509098342)
【氏名又は名称原語表記】Oskar BARTENSTEIN
【出願人】(509098504)
【出願人】(509098490)
【Fターム(参考)】