米国特許情報 | 欧州特許情報 | 国際公開(PCT)情報 | Google の米国特許検索
 
     特許分類
A 農業
B 衣類
C 家具
D 医学
E スポ−ツ;娯楽
F 加工処理操作
G 机上付属具
H 装飾
I 車両
J 包装;運搬
L 化学;冶金
M 繊維;紙;印刷
N 固定構造物
O 機械工学
P 武器
Q 照明
R 測定; 光学
S 写真;映画
T 計算機;電気通信
U 核技術
V 電気素子
W 発電
X 楽器;音響


  ホーム -> 計算機;電気通信 -> 三洋電機株式会社

発明の名称 データ処理システムおよびそれを用いたデータ表示装置
発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開2003−36258(P2003−36258A)
公開日 平成15年2月7日(2003.2.7)
出願番号 特願2001−224463(P2001−224463)
出願日 平成13年7月25日(2001.7.25)
代理人 【識別番号】100064746
【弁理士】
【氏名又は名称】深見 久郎 (外3名)
【テーマコード(参考)】
5B075
5B082
【Fターム(参考)】
5B075 NK02 NK54 PP13 PQ02 PQ04 
5B082 BA03 BA12 EA05
発明者 岡田 誠
要約 課題
可変長のレコードから構成されるデータ列から所望のレコードデータを取得する所要時間を短縮することが可能なデータ処理システムを提供する。

解決手段
受信機101において、データ列の各レコードの先頭位置に示される長さ情報からレコードデータの先頭位置のアドレス情報を取得し、固定長アドレス管理用リストをアドレス管理用メモリ206に予め格納する。たとえば、データ列の受信時に、すべてのレコードデータの先頭位置のアドレス情報がアドレス管理用リストとして作成される。レコードデータを取得する場合、アドレス管理用リストを検索し、当該レコード先頭位置のアドレス情報からレコードデータの取得を行なう。
特許請求の範囲
【請求項1】 外部から順次受信した複数の可変長レコードで構成されるデータ列から、ユーザの指示に従って任意のレコードデータを取得するデータ処理システムであって、前記複数の可変長レコードのうち、少なくとも複数の可変長レコードの先頭位置のアドレス情報を前記可変長レコードのインデクスと対応付けて、予め抽出しておくアドレス情報抽出手段と、前記アドレス情報抽出手段の抽出結果を格納するための固定長アドレス管理リストを作成するためのアドレス管理リスト作成手段と、前記ユーザの指示により指定されたレコードデータを、前記アドレス管理リスト作成手段に格納された情報を参照して探索するデータ探索手段とを備える、データ処理システム。
【請求項2】 各前記可変長レコードは、先頭位置にレコード長情報を有し、前記アドレス情報抽出手段は、前記データ列の受信時に、前記レコード長情報に基づいて、受信されたすべての前記レコードデータの前記先頭位置のアドレス情報を抽出して、前記アドレス管理リスト作成手段に保持させる、請求項1記載のデータ処理システム。
【請求項3】 前記データ探索手段は、前記レコードデータを取得する場合、取得対象の前記レコードの前記インデックスに基づいて前記アドレス管理用リストを探索し、前記レコードの先頭位置に対するアドレス情報に基づいて前記レコードデータの取得を行なう、請求項1記載のデータ処理システム。
【請求項4】 各前記可変長レコードは、先頭位置にレコード長情報を有し、前記アドレス情報抽出手段は、前記レコードデータを取得時に、前記レコード長情報に基づいて、取得対象の前記レコードまでの連続するすべてのレコード先頭位置のアドレス情報を抽出して、前記アドレス管理リスト作成手段に保持させる、請求項1記載のデータ処理システム。
【請求項5】 前記データ探索手段は、前記レコードデータを取得する際に、取得しようとするレコードのインデックスが以前に取得したレコードのインデックスの範囲に含まれている場合、取得対象の前記レコードのインデックスに基づいて前記アドレス管理用リストを探索し、レコード先頭位置のアドレス情報を取得することによりレコードデータの取得を行なう、請求項4記載のデータ処理システム。
【請求項6】 前記データ探索手段は、前記レコードデータを取得する際に、取得しようとするレコードのインデックスが以前に取得したレコードのインデックスの範囲に含まれていない場合、前記アドレス管理用リスト内の既に抽出されている前記レコード先頭位置のアドレス情報に基づいて、新規に取得するレコードまでスキャンを行なって、当該レコードデータを取得する、請求項4または5記載のデータ処理システム。
【請求項7】 前記アドレス情報抽出手段は、前記レコードデータを取得する際に、前記レコードデータを取得する際に、取得しようとするレコードのインデックスが以前に取得したレコードのインデックスの範囲に含まれていない場合、前記アドレス管理用リスト内の既に抽出されている前記レコード先頭位置のアドレス情報に基づいて、新規に取得するレコードまでのすべてのレコード先頭位置のアドレス情報を前記固定長アドレス管理用リストに保持し、前記データ探索手段は、前記固定長アドレス管理用リストに基づいて、新規に取得するレコードデータを取得する、請求項4または5記載のデータ処理システム。
【請求項8】 外部からの放送を受信するための受信手段と、前記受信手段を介して順次受信した複数の可変長レコードで構成されるデータ列から、ユーザの指示に従って任意のレコードデータを取得するデータ処理手段とを備え、前記データ処理手段は、前記複数の可変長レコードのうち、少なくとも複数の可変長レコードの先頭位置のアドレス情報を前記可変長レコードのインデクスと対応付けて、予め抽出しておくアドレス情報抽出手段と、前記アドレス情報抽出手段の抽出結果を格納するための固定長アドレス管理リストを作成するためのアドレス管理リスト作成手段と、前記ユーザの指示により指定されたレコードデータを、前記アドレス管理リスト作成手段に格納された情報を参照して探索するデータ探索手段とを含み、前記データ探索手段の探索結果に応じて、対応するデータを表示するための表示手段をさらに備える、データ表示装置。
【請求項9】 各前記可変長レコードは、先頭位置にレコード長情報を有し、前記アドレス情報抽出手段は、前記データ列の受信時に、前記レコード長情報に基づいて、受信されたすべての前記レコードデータの前記先頭位置のアドレス情報を抽出して、前記アドレス管理リスト作成手段に保持させる、請求項8記載のデータ表示装置。
【請求項10】 前記データ探索手段は、前記レコードデータを取得する場合、取得対象の前記レコードの前記インデックスに基づいて前記アドレス管理用リストを探索し、前記レコードの先頭位置に対するアドレス情報に基づいて前記レコードデータの取得を行なう、請求項8記載のデータ表示装置。
【請求項11】 各前記可変長レコードは、先頭位置にレコード長情報を有し、前記アドレス情報抽出手段は、前記レコードデータを取得時に、前記レコード長情報に基づいて、取得対象の前記レコードまでの連続するすべてのレコード先頭位置のアドレス情報を抽出して、前記アドレス管理リスト作成手段に保持させる、請求項8記載のデータ表示装置。
【請求項12】 前記データ探索手段は、前記レコードデータを取得する際に、取得しようとするレコードのインデックスが以前に取得したレコードのインデックスの範囲に含まれている場合、取得対象の前記レコードのインデックスに基づいて前記アドレス管理用リストを探索し、レコード先頭位置のアドレス情報を取得することによりレコードデータの取得を行なう、請求項11記載のデータ表示装置。
【請求項13】 前記データ探索手段は、前記レコードデータを取得する際に、取得しようとするレコードのインデックスが以前に取得したレコードのインデックスの範囲に含まれていない場合、前記アドレス管理用リスト内の既に抽出されている前記レコード先頭位置のアドレス情報に基づいて、新規に取得するレコードまでスキャンを行なって、当該レコードデータを取得する、請求項11または12記載のデータ表示装置。
【請求項14】 前記アドレス情報抽出手段は、前記レコードデータを取得する際に、前記レコードデータを取得する際に、取得しようとするレコードのインデックスが以前に取得したレコードのインデックスの範囲に含まれていない場合、前記アドレス管理用リスト内の既に抽出されている前記レコード先頭位置のアドレス情報に基づいて、新規に取得するレコードまでのすべてのレコード先頭位置のアドレス情報を前記固定長アドレス管理用リストに保持し、前記データ探索手段は、前記固定長アドレス管理用リストに基づいて、新規に取得するレコードデータを取得する、請求項11または12記載のデータ表示装置。
発明の詳細な説明
【0001】
【発明の属する技術分野】本発明は、外部から受信した可変長レコードで構成されるデータ列を処理するためのデータ処理システムおよびそれを用いるデータ表示装置の構成に関する。
【0002】
【従来の技術】近年、テレビ放送等においても、放送される映像情報および音声情報と関連する文字データが放送局から送信され、受信機側において映像情報および音声情報と並行して、あるいは文字情報のみがディスプレイ上に表示されるという放送形態がとられる場合がある。
【0003】たとえば、テレビ放送において、天気予報の情報をデータ放送により伝送する場合、このような天気予報に関する情報は、連続したバイナリデータであって、その内容自体は表形式であるデータとして伝送されることが多い。受信機側では、ユーザの指示に従って、このようにして放送されたバイナリデータから所望のデータの取得を行なって、ユーザが求めた地域や時刻等の天気予報情報をディスプレイ上に表示することになる。
【0004】ところが、このような天気予報の情報等は、複数の可変長なレコードデータがバイナリデータとして順次伝送される。このようなバイナリデータから複数の可変長レコードデータの取得を行なう際には、受信機においては、先頭から1行ずつスキャンを行なって所望のレコード位置を探索する必要がある。
【0005】
【発明が解決しようとする課題】しかしながら、上述したような従来の技術を用いた場合、所望のレコード位置が受信したバイナリデータ中の後方にあると、先頭から1行ずつスキャンすることにより、レコードデータ取得までに膨大な時間を要するという問題点があった。
【0006】この発明は、上記のような問題点を解決するためになされたものであって、その目的は、外部から順次受信した複数の可変長レコードで構成されるバイナリデータから、ユーザの指示に従って任意のレコードデータを取得する際に、レコードデータ取得までの時間を短縮することが可能なデータ処理システムおよびこれを用いたデータ表示装置を提供することである。
【0007】
【課題を解決するための手段】本発明では、上記課題を解決するために、請求項1記載のデータ処理システムは、外部から順次受信した複数の可変長レコードで構成されるデータ列から、ユーザの指示に従って任意のレコードデータを取得するデータ処理システムであって、複数の可変長レコードのうち、少なくとも複数の可変長レコードの先頭位置のアドレス情報を可変長レコードのインデクスと対応付けて、予め抽出しておくアドレス情報抽出手段と、アドレス情報抽出手段の抽出結果を格納するための固定長アドレス管理リストを作成するためのアドレス管理リスト作成手段と、ユーザの指示により指定されたレコードデータを、アドレス管理リスト作成手段に格納された情報を参照して探索するデータ探索手段とを備える。
【0008】請求項2記載のデータ処理システムは、請求項1記載のデータ処理システムの構成に加えて、各可変長レコードは、先頭位置にレコード長情報を有し、アドレス情報抽出手段は、データ列の受信時に、レコード長情報に基づいて、受信されたすべてのレコードデータの先頭位置のアドレス情報を抽出して、アドレス管理リスト作成手段に保持させる。
【0009】請求項3記載のデータ処理システムは、請求項1記載のデータ処理システムの構成に加えて、データ探索手段は、レコードデータを取得する場合、取得対象のレコードのインデックスに基づいてアドレス管理用リストを探索し、レコードの先頭位置に対するアドレス情報に基づいてレコードデータの取得を行なう。
【0010】請求項4記載のデータ処理システムは、請求項1記載のデータ処理システムの構成に加えて、各可変長レコードは、先頭位置にレコード長情報を有し、アドレス情報抽出手段は、レコードデータを取得時に、レコード長情報に基づいて、取得対象のレコードまでの連続するすべてのレコード先頭位置のアドレス情報を抽出して、アドレス管理リスト作成手段に保持させる。
【0011】請求項5記載のデータ処理システムは、請求項4記載のデータ処理システムの構成に加えて、データ探索手段は、レコードデータを取得する際に、取得しようとするレコードのインデックスが以前に取得したレコードのインデックスの範囲に含まれている場合、取得対象のレコードのインデックスに基づいてアドレス管理用リストを探索し、レコード先頭位置のアドレス情報を取得することによりレコードデータの取得を行なう。
【0012】請求項6記載のデータ処理システムは、請求項4または5記載のデータ処理システムの構成に加えて、データ探索手段は、レコードデータを取得する際に、取得しようとするレコードのインデックスが以前に取得したレコードのインデックスの範囲に含まれていない場合、アドレス管理用リスト内の既に抽出されているレコード先頭位置のアドレス情報に基づいて、新規に取得するレコードまでスキャンを行なって、当該レコードデータを取得する。
【0013】請求項7記載のデータ処理システムは、請求項4または5記載のデータ処理システムの構成に加えて、アドレス情報抽出手段は、レコードデータを取得する際に、レコードデータを取得する際に、取得しようとするレコードのインデックスが以前に取得したレコードのインデックスの範囲に含まれていない場合、アドレス管理用リスト内の既に抽出されているレコード先頭位置のアドレス情報に基づいて、新規に取得するレコードまでのすべてのレコード先頭位置のアドレス情報を固定長アドレス管理用リストに保持し、データ探索手段は、固定長アドレス管理用リストに基づいて、新規に取得するレコードデータを取得する。
【0014】請求項8記載のデータ表示装置は、外部からの放送を受信するための受信手段と、受信手段を介して順次受信した複数の可変長レコードで構成されるデータ列から、ユーザの指示に従って任意のレコードデータを取得するデータ処理手段とを備え、データ処理手段は、複数の可変長レコードのうち、少なくとも複数の可変長レコードの先頭位置のアドレス情報を可変長レコードのインデクスと対応付けて、予め抽出しておくアドレス情報抽出手段と、アドレス情報抽出手段の抽出結果を格納するための固定長アドレス管理リストを作成するためのアドレス管理リスト作成手段と、ユーザの指示により指定されたレコードデータを、アドレス管理リスト作成手段に格納された情報を参照して探索するデータ探索手段とを含み、データ探索手段の探索結果に応じて、対応するデータを表示するための表示手段をさらに備える。
【0015】請求項9記載のデータ表示装置は、請求項8記載のデータ表示装置の構成に加えて、各可変長レコードは、先頭位置にレコード長情報を有し、アドレス情報抽出手段は、データ列の受信時に、レコード長情報に基づいて、受信されたすべてのレコードデータの先頭位置のアドレス情報を抽出して、アドレス管理リスト作成手段に保持させる。
【0016】請求項10記載のデータ表示装置は、請求項8記載のデータ表示装置の構成に加えて、データ探索手段は、レコードデータを取得する場合、取得対象のレコードのインデックスに基づいてアドレス管理用リストを探索し、レコードの先頭位置に対するアドレス情報に基づいてレコードデータの取得を行なう。
【0017】請求項11記載のデータ表示装置は、請求項8記載のデータ表示装置の構成に加えて、各可変長レコードは、先頭位置にレコード長情報を有し、アドレス情報抽出手段は、レコードデータを取得時に、レコード長情報に基づいて、取得対象のレコードまでの連続するすべてのレコード先頭位置のアドレス情報を抽出して、アドレス管理リスト作成手段に保持させる。
【0018】請求項12記載のデータ表示装置は、請求項11記載のデータ表示装置の構成に加えて、データ探索手段は、レコードデータを取得する際に、取得しようとするレコードのインデックスが以前に取得したレコードのインデックスの範囲に含まれている場合、取得対象のレコードのインデックスに基づいてアドレス管理用リストを探索し、レコード先頭位置のアドレス情報を取得することによりレコードデータの取得を行なう。
【0019】請求項13記載のデータ表示装置は、請求項11または12記載のデータ表示装置の構成に加えて、データ探索手段は、レコードデータを取得する際に、取得しようとするレコードのインデックスが以前に取得したレコードのインデックスの範囲に含まれていない場合、アドレス管理用リスト内の既に抽出されているレコード先頭位置のアドレス情報に基づいて、新規に取得するレコードまでスキャンを行なって、当該レコードデータを取得する。
【0020】請求項14記載のデータ表示装置は、請求項11または12記載のデータ表示装置の構成に加えて、アドレス情報抽出手段は、レコードデータを取得する際に、レコードデータを取得する際に、取得しようとするレコードのインデックスが以前に取得したレコードのインデックスの範囲に含まれていない場合、アドレス管理用リスト内の既に抽出されているレコード先頭位置のアドレス情報に基づいて、新規に取得するレコードまでのすべてのレコード先頭位置のアドレス情報を固定長アドレス管理用リストに保持し、データ探索手段は、固定長アドレス管理用リストに基づいて、新規に取得するレコードデータを取得する。
【0021】
【発明の実施の形態】以下、図面を参照して本発明の実施の形態について説明する。
【0022】図1は、本発明に係るデータ処理システムを備えるデータ表示装置1000の構成の例を示した概念図である。
【0023】図1においては、一例として、上述したようなデータ放送を受信することが可能な受信機101において、本発明に係るデータ処理システムが使用され、データ表示装置1000が実現されている場合の構成を示している。
【0024】図1を参照して、受信機101は、アンテナ2を介して、映像および音声ストリームと多重されたデータ放送コンテンツを受信し、データ放送コンテンツに記述された情報に従って、ディスプレイ102およびスピーカ103を介して、映像、音声、文字、図形などを表示する。
【0025】ユーザは、リモコン104を用いて、データ放送サービスを選択し、所望の情報を得ることができる。
【0026】図1に示した例においては、ユーザが、各地の明日の天気に対する天気予報の情報を得るにあたり、東京地方をその天気予報の対象として選択した状態を示している。したがって、ディスプレイ102上において、「東京」が選択され、画面上で四角形の枠で囲まれている。
【0027】図2は、図1に示した受信機101の内部構成を説明するための概略ブロック図である。
【0028】図2を参照して、受信機101において、アンテナ2により受信されたRF信号は、受信部201において、選局されて復調処理およびデコード処理等を行なわれ、分離部202に与えられる。分離部202は、受信部201からの信号を、映像音声情報に対する信号と、データ放送コンテンツとに分離する。分離部202から、映像および音声ストリームは、AV処理部203へ送られ、データ放送コンテンツはコンテンツ用メモリ204に送られる。AV処理部203は、映像および音声ストリームを受けて、対応するカラー画像を表示可能な信号に変換する。
【0029】一方、コンテンツ用メモリ204に蓄積されたデータ放送コンテンツに対して、CPU207が処理を行なうことにより、文字や図形等をデータ放送コンテンツによって指定されたディスプレイ102の画面上の指定位置へ表示するための信号が、オンスクリーンディスプレイ処理部(以下、「OSD処理部」と呼ぶ)205に与えられ、さらにOSD処理部205によって、映像データと文字や図形等が合成された後、ディスプレイ102上に表示される。
【0030】ユーザからの入力信号は、リモコン104からユーザインターフェイス208を介してCPU207に伝えられる。CPU207では、データ放送コンテンツとして受信されたプログラム内に記述された入力情報に対する処理を実行して、メディアの表示制御や受信機の動作制御を行なう。
【0031】次に、データ放送コンテンツ内にバイナリデータが含まれている場合の処理手順について説明する。
【0032】図3および図4は、データ放送コンテンツに基づいた表示例を示す概念図である。
【0033】まず、図3に示すように、天気予報情報の画面において、地域選択画面が表示される。図3に示した例では、たとえば、地域として札幌、東京、大阪および福岡の中から、ユーザが天気予報を見たいと思う地域を選択する構成となっているものとする。図3では、ユーザからのリモコン104を介しての指示により、東京が選択されている状態を示す。
【0034】図4は、図3のようにしてユーザによって選択された東京地方の明日の天気の情報が表示されている状態を示す。
【0035】図4に示されている表示のうち1行目の「の明日の天気」、2行目の「天気」、3行目の「最高気温」および「℃」、4行目の「最低気温」、「℃」および「戻る」との表示は、ユーザがどの地域を選択するかにかかわらず固定された表示が行なわれる領域である。
【0036】一方、1行目の「東京」、2行目の「晴れのち曇り」、3行目の「22」、4行目の「16」等の表示は、ユーザがどの地域を選択するかに応じてその表示内容が変更される部分である。
【0037】後に説明するように、このようなユーザの選択に応じてその表示内容が変更される部分については、放送局からは、表形式のデータとして、受信機101に対して送信されている。
【0038】すなわち、データ放送コンテンツに、選択した地域の天気情報が、表形式データを表現するバイナリデータとして含まれており、図4の画面を表示する際に、このバイナリデータから天気情報データの検索が行なわれることになる。
【0039】図5は、図3および図4で示したような天気予報提供サービスを実現するためのデータ放送コンテンツのうち、ユーザからの指示に従って、バイナリデータから天気情報データを取得するための検索処理に対応するプログラムリストを示す。
【0040】ここで、図5に示したようなプログラムは、XML(eXtensible Markup Language)に基づいて、放送用に仕様変更を行なった言語である「BML(Broadcast Markup Language)」により記述されている。
【0041】図5を参照して、まず、1行目の「var bt」によって、変数btの宣言が行なわれる。
【0042】続いて、放送局から受信した表形式のデータである”tenki.bt”というバイナリデータを変数btに読込むための関数bt_new()の定義が行なわれる。
【0043】このようにして、変数btに読込まれた天気情報に対応したバイナリデータから、ユーザによって指定される地域を表わす変数locationを引き数とする関数getTenkiData(location)により、選択された地域に応じて、天気、最高気温、最低気温の値の検索および取得が行なわれる。取得された天気、最高気温、最低気温は、関数dispData()により画面に表示される。
【0044】ここで、まず関数bt_new()の定義式中で用いられる関数newBinaryTable(X,Y)は、第1番目の引き数Xによって指定されるバイナリデータからのデータを読出すことを示す。さらに、この関数の2番目の引き数Yの“1,S:1V,S:1V,I:1B,I:1B”は、Xで示されるバイナリデータに格納されているレコードデータのフォーマットを示している。
【0045】すなわち、1番最初の「1」は、バイナリデータの可変長レコードの先頭の1バイト目には、各可変長レコードのレコード長が格納されていることを示す。続く「S:1V」は、その各可変長レコードの先頭には、1バイト目にそのデータ長が記述されている第1の可変長文字列データがあることを示す。さらに、この第1の可変長文字列データに続いて、「S:1V」で表される第2の可変長文字列データが存在する。この第2の可変長文字列データに続いて、各可変長レコードには、「I:1B」で表される2つのデータが存在する。ここで、「I:1B」は、1バイト長の固定長(「1B」で表される)の整数値データ(「I」で表される)がレコード内に格納されていることを示している。
【0046】一方、5行目からは、ユーザから指定された地域locationに基づいて、天気情報のデータをバイナリデータから獲得するための関数getTenkiData()の定義が行なわれる。この定義中において、まず、「var tenki, maxTemp,minTemnp」は、それぞれ、天気、最高気温、最低気温を表す変数tenki, maxTemp,minTemnpを宣言するものである。また、関数bt.toString(X,Y)は、バイナリデータのテーブル中から、文字列データを取得するための関数であり、1番目の引き数Xはバイナリテーブル内のレコード位置のインデックスを表わし、2番目の引き数Yはレコード内のデータ位置のインデックスを示している。
【0047】関数toNumber(X,Y)も、バイナリデータ中から、整数値データを取得するための関数であり、引き数Xは、バイナリテーブル内のレコード位置のインデックスであり、引き数Yはレコード内のデータ位置のインデックスを示している。
【0048】図6は、天気情報を表わす可変長レコード形式のバイナリデータtenki.btのダンプ内容を示す概念図である。
【0049】図6中では、バイナリデータのダンプ内容に対応した文字および数値データを、ダンプデータの下に対比のために示している。
【0050】図6において、四角で囲んだバイトは各レコードの長さを示している。すなわち、図5で説明した関数newBinaryTable()関数中の2番目の引き数において、先頭の「1」が示していたように、各レコードの1バイト目には、当該レコードのレコード長を示すデータが存在している。
【0051】たとえば、1番最初の札幌の天気情報を示すレコードにおいては、レコード長として「0C」が指定されているために、このレコードは、このレコード長を示すデータの後に、12バイト分のデータが存在するレコードであることが示されている。すなわち、各レコードのデータは、四角で囲んだバイトの次バイトから始まり、次の四角で囲んだバイトの手前までとなる。
【0052】続いて、この「札幌」の天気情報が格納されているデコードについて見ると、関数newBinaryTable()の2番目の引き数に示されているとおり、そのフォーマットとして次のデータは「S:1V」である。このため、まず先頭の「04」がこれに続く可変長文字列データのバイト数を示す。つまり、「04」に続く「8E」〜「79」までの4バイトのデータが、「札幌」という文字列に対応するデータである。
【0053】さらに、関数newBinaryTable()関数の第2引き数のデータフォーマットに従うと、これに続いて、「S:1V」のデータ、すなわち先頭バイトにデータ長が示されている可変長文字列データが格納されていることになる。すなわち、「札幌」のデータに続く「04」は、これに続く文字列データが4バイトであることを示す。したがって、「90」〜「EA」が、「晴れ」との文字列に対応している。
【0054】さらに、関数newBinaryTable()の第2引き数のデータフォーマットによれば、この「晴れ」との文字列データの後に、「I:1B」で表わされるデータが2つ続いていることになる。上述のとおり、「I:1B」は、整数値のデータ(「I」により表現される)が、固定長の1バイトのデータであることを示している。
【0055】したがって、「晴れ」のデータに続く16進数の「12」という1バイトのデータが、10進表示で最高気温の「18」を示し、これに続く1バイトの「0A」との16進データが、10進表示では「10」という最低気温を表現していることになる。
【0056】以上で、第1番目のレコードの「札幌」の天気情報に対するデータが終了し、引続いて、「東京」に対応するレコードが存在している。「東京」に対応するレコードは、「14」との1バイトのデータの直後から始まっており、すなわち、20バイトの長さを有していることがわかる。
【0057】以下同様にして、「大阪」および「福岡」の天気情報が可変長レコードにより構成される一連のバイナリデータとして、放送局から送信されてくることになる。
【0058】以上のような連続したバイナリデータで表わされる可変長レコードの天気情報が放送により伝送された後に、ユーザが、たとえば「東京」の天気情報を知りたい場合、リモコン104から、受信機101に対して「東京」の選択を指示する。これに応じて、CPU207では、コンテンツ用メモリ204中に格納されている図5に示したような検索用のプログラムに基づいて、やはりコンテンツ用メモリ204中に格納されている放送されたバイナリデータから東京の天気情報を獲得する。
【0059】より具体的に言えば、図5に示したプログラムにおいて、関数bt.toString(1,1)の処理によって、1番目のレコード内の1番目のデータ位置からのデータの取得が行なわれる。
【0060】このとき、従来の方法では、まず第0番目の札幌の天気の情報を含むレコードについては、その先頭の「0C」で表わされるレコードの長さ、すなわち12バイト分だけデータを先頭からスキャンすることにより、続く1番目のレコードの東京の天気情報が格納されたレコードの長さが20バイト(0x14)であることを検知して、この20バイトのレコードのデータのうち、1番目のデータから天気情報として“晴れ後曇り”の文字列を取出す。同様にして、関数bt.toNumber(1,2)、関数bt.toNumber(1,3)の処理により、東京の最高気温、最低気温をバイナリデータから取出す。
【0061】大阪や福岡の天気情報を取出す場合も、一連のバイナリデータから、札幌、東京のレコードデータを先頭からスキャンしていくことにより、大阪のデータさらには福岡のデータの抽出を行なう。
【0062】このように、従来の方法では、所望のレコードがバイナリデータの後方に存在する場合でも、先頭から順次レコードをスキャンする必要があり、大きなサイズのバイナリデータからレコードデータを取出すとき処理に時間を要してしまうことになる。
【0063】そこで、本発明に係る受信機101においては、図2に示すようにアドレス管理用メモリ206を設け、たとえば、図5の関数bt_new()がCPU207から呼出された際などに、バイナリデータの各レコードの先頭位置のアドレスをアドレス管理用メモリ206に対してリストとして保持しておく処理をさらに追加する。
【0064】このようなリストを参照して、各天気情報を抽出することとすれば、ユーザがリモコン104を用いて地域選択を行なう2回目以降の処理においては、検索時間を短縮することが可能となる。
【0065】図7は、アドレス管理用メモリ206に格納される、アドレス管理用リストの例を示す図である。図7に示すとおり、0番目のレコードであるrecord[0]の先頭アドレスがアドレス“00000001”であることが格納されている。他のレコードについても同様である。
【0066】つまり、図7に示すとおり、アドレス管理用メモリ206は、各レコードのインデクスの0〜3の値と対応づけて、各レコードデータの先頭位置である、図6において四角で囲んだバイトの次のバイトのアドレスを保持している。このアドレス管理用メモリ206に格納されるアドレス管理用リストは、固定長レコードのリストデータである。
【0067】[アドレス管理用リストの作成タイミング]このようなアドレス管理用リストをいつの時点で、また、どのレコードのアドレスまでアドレス管理用メモリ206に作成して格納しておくかについては、以下に説明するようないくつかの方式が考えられる。
【0068】[作成タイミング1]図8は、このようなアドレス管理用メモリ206に、レコードの先頭位置のアドレスを格納する第1番目の処理を示すフローチャートである。
【0069】なお、以下に説明するような関数newBinaryTable()によるバイナリデータの読出しの処理とアドレス管理リストの作成処理は、このバイナリデータの受信完了時に行なっておき、予め受信されたすべてのレコードデータの先頭位置のアドレス情報をアドレス管理リストとして作成しておくことが可能である。
【0070】すなわち、図8を参照して、CPU207が、図5に示したプログラムを実行するに当たり、関数newBinaryTable()が呼出される(ステップS100)。
【0071】バイナリデータが格納されたファイルを、コンテンツ用メモリ204から読出処理が行なわれる(ステップS102)。
【0072】このとき、ファイル読込に失敗した場合は(ステップS104)、エラー終了のため、メインルーチンにはエラーが生じたことを示す“false”を返す処理を行なう(ステップS106)。
【0073】一方、ステップS104において、ファイル読込が正常に行なわれた場合、続いて、読込まれたファイルに対するスキャン動作が終了したか否かの判定が行なわれる(ステップS110)。
【0074】スキャン動作が終了していない場合、続いて、変数tempにスキャン対象となるレコードのレコード長を格納する(ステップS112)。
【0075】次に、レコード長が格納されたバイトをスキャンし(ステップS114)、レコードデータが格納されているアドレスへ移り、そのアドレスをアドレス管理用リストに格納する(ステップS116)。
【0076】その後、変数tempで示されているレコードデータのバイト長分だけさらにバイナリデータのスキャンを行なって(ステップS118)、処理はステップS110に復帰する。
【0077】次のレコードに対しても同様に、変数tempにレコード長のデータを格納し(ステップS112)、レコード長のバイトをスキャンして(ステップS114)、現在のアドレスすなわちレコード内のデータの先頭アドレスをアドレス管理用リストに格納する(ステップS116)。続いて、変数tempバイト分だけスキャンを行なって(ステップS118)、処理が再びステップS110に復帰する。
【0078】以下同様にして、バイナリデータに含まれるすべてのレコードの先頭位置のアドレスの格納が完了した場合に、関数newBinaryTable()の処理を終了する。
【0079】このような処理が終了すると、CPU207は、ユーザがリモコン104により天気予報の対象地域の選択を行なうのを待機することになる。
【0080】図9は、図8に示したような処理を行なって、アドレス管理用メモリ206中にアドレス管理用リストが格納された後の、レコードデータの取得処理を示すフローチャートである。
【0081】すなわち、ユーザがリモコン104により天気予報の対象地域の選択を行なった後に、図5に示したプログラムの処理において、関数toString()や、関数toNumber()に処理が行なわれる際の処理のフローを示している。
【0082】図9を参照して、関数toString(row, column)や関数toNumber(row, Column)が呼出されると(ステップS200)、これら引数rowの大きさとアドレス管理用リストの格納レコード数との比較が行なわれる(ステップS202)。
【0083】引数rowがアドレス管理用リストの格納レコード数以上の場合、関数toString()や関数toNumber()は、引数値がエラーを示す値“false”を返す(ステップS204)。
【0084】一方、ステップS202において、引数rowがアドレス管理用リストの格納レコード数よりも少ない場合、続いて、アドレス管理用リストのインデックスの値が引数rowである位置に対応するアドレス値の取得が行なわれる(ステップS210)。
【0085】続いて、アドレス管理用リストから取得したアドレスをもとに、バイナリデータからレコードデータの読込が行なわれ(ステップS212)、読込まれたレコードデータから、図5のフォーマット指定に基づいて、引数columnで指定される位置のデータの取得が行なわれる(ステップS214)。
【0086】以上の処理が終了した段階で処理が終了し、正常終了であることを示す返り値“true”がメインルーチンに返される(ステップS216)。
【0087】このような処理により、ユーザが天気情報を画面上で見ようとした場合に、各地の天気情報を格納したバイナリデータの先頭から、所望の地域に対応したレコードまでスキャンしてデータの読出しを行なうという必要がなく、当該所望の地域に対応したレコードをそのアドレスにより直接参照できるので、天気情報の表示までの所要時間を短縮することができる。
【0088】[作成タイミング2]以上説明したような作成タイミング1の処理では、アドレス管理用リストへバイナリデータの各レコードの先頭位置のアドレスを格納する処理を、関数newBinaryTable()がメインルーチンから呼出された時点で行なっていた。
【0089】これに対して、メインルーチンにおいて、関数newBinaryTable()が呼出された時点ではなく、図5に示したプログラム処理内において、関数toString()や関数toNumber()が実行された際に、この関数の引数で指定されたレコードまでについて、その都度アドレス管理用リストを作成して、アドレス管理用メモリ206に格納するという処理を行なうことも可能である。
【0090】図10は、このようにレコードデータの取得処理が行なわれるごとに逐次的にアドレス管理用リストを作成する処理を示すフローチャートである。
【0091】図10に示す処理では、関数toString()や関数toNumber()の処理で初めて読込が行なわれるファイルの場合、まだアドレス管理用リストにはレコード先頭位置を示すアドレスが格納されていない状態である。このため、所望のレコードまでのデータを1レコードずつスキャンし、その際、各レコードの先頭位置を逐次アドレス管理用リストに格納するという処理を行なう。
【0092】すなわち、図10を参照して、関数toString(row, column)や関数toNumber(row, column)が呼出されると(ステップS300)、まず、読出対象となっているファイルが、初めてデータの読込を行なうファイルであるか否かの判定が行なわれる(ステップS302)。初めて読込むファイルでない場合は、後に説明する「処理2」に処理が移行する(ステップS304)。
【0093】一方、初めて読込むファイルである場合(ステップS302)、変数indexに0が代入され、変数maxIndexに引数rowが代入される(ステップS310)。
【0094】続いて、バイナリデータのスキャンが開始され、先頭のレコードに対応するレコード長が変数tempに代入され、インデックスの値が1だけインクリメントされる(ステップS312)。
【0095】次に、レコード長を表すバイト(たとえば、図6の説明では1バイト分)についてはバイナリデータをスキャンし(ステップS314)、レコード長を表わすバイトの次のアドレスをアドレス管理用リストに当該レコードの先頭アドレスとして格納する(ステップS316)。
【0096】次に、変数indexの値と、引数rowの値とが比較される。変数indexの値が引数row以下である場合は、処理はステップS320に移行して、変数tempで表わされるバイト分だけバイナリデータをスキャンした上で、再び処理がステップS312に復帰する。ステップS312では、次のレコードに対応するレコード長を表すバイトから次のレコードのレコード長のデータを読取り、これを変数tempに代入し、変数indexの値を1だけインクリメントする。
【0097】以下、同様の処理がステップS318まで繰返される。一方、ステップS318において、変数indexが引数rowよりも大きい場合は、現在の位置が引数rowによって指定されたレコードであるため、現在の位置からレコードデータの読込が行なわれる(ステップS322)。
【0098】読込まれたレコードデータから、続いて、引数columnの位置のデータの取得が行なわれ(ステップS324)、処理が終了して、正常終了であることを示す値“true”がメインルーチンに返される(ステップS326)。
【0099】図11は、図10において示した「処理2」、すなわち、関数toString(row,column)や関数toNumber(row, column)が呼出された際に、読出の対象となるファイルが初めて読込むファイルではなく、2回目以降の読出処理である場合の処理を示すフローチャートである。
【0100】すなわち、「処理2」が開始されると(ステップS304)、まず、所望のレコードのインデックスrowが、アドレス管理用リストに格納されたレコード数を示す値maxIndexよりも小さいか否かの判定が行なわれる(ステップS402)。
【0101】インデックスrowがレコード数maxIndex以下である場合、続いて、アドレス管理用リストのインデックスが引数rowである位置のアドレスをアドレス管理用リストから取得する(ステップS410)。
【0102】取得したアドレスをもとに、バイナリデータからレコードデータの読込が行なわれ(ステップS412)、レコードデータから引数columnの位置のデータの取得が行なわれる(ステップS414)。
【0103】以上により、処理が終了し、正常終了であることを示す値“true”がメインルーチンに返される(ステップS416)。
【0104】一方、ステップS402において、所望のレコードのインデックスrowがアドレス管理用リストに格納されたレコード数maxIndexよりも大きい場合、アドレス管理用リストのインデックスがmaxIndexである位置のアドレスを、すなわち、アドレス管理用リストに格納された最後尾のレコードの先頭位置のアドレスを取得する(ステップS420)。
【0105】この取得されたアドレスからレコード長のバイト分だけアドレスを引き戻した後(ステップS422)、所望のレコードまでのデータを1レコードずつスキャンする。すなわち、まず、変数indexに変数maxIndexの値が代入され、変数maxIndexには引数rowの値が代入される(ステップS424)。
【0106】続いて、現状のレコードの先頭位置の1バイトのデータから、レコード長に相当するデータを取得して、変数tempに代入し、変数indexの値を1だけインクリメントする(ステップS426)。
【0107】次に、レコード長のバイト+変数tempのバイト分のデータをスキャンし(ステップS428)、処理は、「処理3」に移行する(ステップS430)。
【0108】図12は、図11に示した「処理3」を示すフローチャートである。図12を参照して、「処理3」にCPU207の処理が移行すると(ステップS430)、続いて、読出対象となっているバイナリデータの最終データまで処理が終了しているか否かの判定が行なわれる(ステップS432)。
【0109】データが最終データまで到達している場合は、エラー終了として、メインルーチンに値“false”が返される(ステップS434)。
【0110】一方、データが最終位置までスキャンされていない場合は(ステップS432)、変数tempに現在のレコードの先頭のデータからレコード長が読出され代入され、かつ変数indexの値が1だけインクリメントされる(ステップS440)。
【0111】次に、レコード長を表わすバイトをスキャンし(ステップS442)、現在のレコードのデータ内容を表わす領域の先頭のアドレスをアドレス管理用リストに格納する(ステップS444)。
【0112】続いて、変数indexの値と引数rowとの値が比較され(ステップS446)、変数indexが引数row以下である場合は、変数tempバイト分だけデータのスキャンが行なわれて(ステップS448)、処理は、ステップS432に復帰する。
【0113】一方、ステップS446において、変数indexの値が引数rowよりも大きい場合は、現在の位置からレコードデータの読込が行なわれ(ステップS450)、レコードデータから引数columnの位置のデータの取得が行なわれる(ステップS452)。
【0114】以上により処理が終了して、正常終了であることを示す値“true”がメインルーチンに返される(ステップS454)。
【0115】このような処理を行なうことで、関数toString()や関数toNumber()がメインルーチンから呼出されるごとに、逐次各レコードの先頭位置をアドレス管理用リストに格納するので、一括して各レコードの先頭位置を探索してアドレス管理用リストに格納する場合に比べて、最初のデータの表示までの時間を短縮することが可能となる。
【0116】なお、以上の説明では、可変長レコードの先頭の直前に1バイトのレコード長を示すデータが配置されるものとして説明したが、レコード長を示すデータの大きさは、さらに大きなものでも、あるいはより小さいものでもよく、レコード長を示すデータの位置も、可変長レコードの先頭の直前に限定されるものではない。たとえば、可変長レコードの先頭とレコード長を示すデータと間に所定の大きさの管理データ等が挿入されていてもよい。
【0117】今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【0118】
【発明の効果】以上説明したとおり、本発明に係るデータ処理システムおよびそれを用いたデータ表示装置によれば、データ列に対応したアドレス管理リストを予め作成することで、少なくとも一度取得したレコードのインデックスよりも小さいインデックスのレコードデータを取得する場合、高速にレコードデータを取得できる。
【0119】また、一度取得したレコードのインデックスよりも大きいインデックスのレコードデータを取得する場合も、一度取得したレコードのアドレス位置からスキャンし当該レコードデータを取得することにより、データ列の先頭から検索する方法に比べて、高速にレコードデータを取得できる。
【0120】すなわち、アドレスを管理するためのリストの追加のみで、可変長のレコードから構成されるデータ列から所望のレコードデータを取得する際の所要時間を短縮することが可能となる。




 

 


     NEWS
会社検索順位 特許の出願数の順位が発表

URL変更
平成6年
平成7年
平成8年
平成9年
平成10年
平成11年
平成12年
平成13年


 
   お問い合わせ info@patentjp.com patentjp.com   Copyright 2007-2013