通信システム
【課題】 サーバから取得したデータに基づいて端末が複数のサービスを提供する場合に、サーバおよび端末でのデータ管理を簡略化できる通信システムを提供する。
【解決手段】 サーバ１は、複数のサービスを提供するためのアプリケーションが用いるデータを端末２へ送信する通信部１１と、データを管理するデータ処理サーバ部１２とを備え、端末２は、サーバ１からデータを受信する通信部２１と、サーバ１から取得したデータに基づいてアプリケーションを実行することによって、ユーザにサービスを提供するサービス機能部２２とを備え、データは、複数のサービスに共通のデータフォーマットで構成され、データフォーマットは、複数のサービスに共通の形式で記述されて、アプリケーションが用いるデータ本体領域と、複数のサービスに共通の形式で記述されて、データ本体領域が用いられるサービスに関する情報を少なくとも含む情報格納領域とで構成される。
【解決手段】 サーバ１は、複数のサービスを提供するためのアプリケーションが用いるデータを端末２へ送信する通信部１１と、データを管理するデータ処理サーバ部１２とを備え、端末２は、サーバ１からデータを受信する通信部２１と、サーバ１から取得したデータに基づいてアプリケーションを実行することによって、ユーザにサービスを提供するサービス機能部２２とを備え、データは、複数のサービスに共通のデータフォーマットで構成され、データフォーマットは、複数のサービスに共通の形式で記述されて、アプリケーションが用いるデータ本体領域と、複数のサービスに共通の形式で記述されて、データ本体領域が用いられるサービスに関する情報を少なくとも含む情報格納領域とで構成される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバと端末とが互いに通信可能に構成されて、端末が、サーバから取得したデータに基づいてユーザに複数のサービスを提供する通信システムに関するものである。
【背景技術】
【０００２】
集合住宅において、各住戸に設置された専用端末やパーソナルコンピュータ等の端末が、中継装置を介して集合住宅用のサーバに接続し、サーバが各住戸の端末へ各種のサービスを提供する通信システムがある（例えば、特許文献１参照）。
【０００３】
しかしながら、中継装置を介することなく、端末装置とサーバとが直接通信を行い、サーバが各住戸の端末へ各種のサービスを提供する通信システムがあり、システム構成の簡略化の点で優れている。
【０００４】
サービスとしては、掲示板サービス、メールサービス（簡易メッセージ）、スケジューラサービス等がある。
【０００５】
図１２は、従来の通信システムの構成を示し、サーバ５００と、クライアント側の端末６００とがネットワークＮＴ１１に接続して、互いに通信可能に構成されている。
【０００６】
サーバ５００は、サービス毎に個別のサーバ機能を有しており、掲示板用サーバ部５０１、メール用サーバ部５０２、スケジューラ用サーバ部５０３等が個別に設けられている。そして、各サーバ部５０１〜５０３には、それぞれのサービスに対応したサーバ側アプリケーション（サーバ側アプリ）が搭載されている。
【０００７】
さらに、掲示板用サーバ部５０１、メール用サーバ部５０２、スケジューラ用サーバ部５０３の各々は、個別の記憶部５１１，５１２，５１３を有している。そして、各サービスに対応したデータは、サービス毎に個別に設けられた記憶部５１１，５１２，５１３に格納される。
【０００８】
一方、端末６００も、サービス毎に個別の端末側アプリケーション（端末側アプリ）が搭載されており、図１２では、掲示板用アプリケーション６０１、メール用アプリケーション６０２、スケジューラ用アプリケーション６０３等が個別に設けられている。なお、以降、掲示板用アプリ６０１、メール用アプリ６０２、スケジューラ用アプリ６０３と称す。また、掲示板用アプリ６０１、メール用アプリ６０２、スケジューラ用アプリ６０３をまとめて端末側アプリと称す。
【０００９】
そして、端末側アプリ６０１〜６０３の各々は、個別の記憶部６１１，６１２，６１３を有しており、各サービスに対応したデータは、サービス毎に個別に設けられた記憶部６１１，６１２，６１３に格納される。
【００１０】
図１３は、従来の通信システムにおけるメールサービスを実行する際の通信シーケンスを示す。
【００１１】
まず、端末６００のメール用アプリ６０２が、定期的に「メールの存在確認」をサーバ５００へ送信し、サーバ５００のメール用サーバ部５０２は、端末６００宛のメールが記憶部５１２に蓄積されているか否かを判別する（Ｓ１０１）。メール用サーバ部５０２は、端末６００宛のメールが蓄積されていない場合、「メールなし」のメッセージを端末６００へ返信する（Ｓ１０２）。メール用アプリ６０２は、「メールの存在確認」をサーバ５００へ送信するポーリングを定期的に繰り返す。
【００１２】
「メールの存在確認」を受信したメール用サーバ部５０２は、端末６００宛のメールが蓄積されている場合、「メールあり」のメッセージを端末６００へ返信する（Ｓ１０３）。そして、メール用アプリ６０２は、ユーザの受信操作等のイベントをトリガとして（Ｓ１０４）、「受信要求」をサーバ５００へ送信する（Ｓ１０５）。「受信要求」を受信したメール用サーバ部５０２は、端末６００宛のメールデータを記憶部５１２から読み出し、この端末６００宛のメールデータを端末６００へ送信する（Ｓ１０６）。メールデータを受信したメール用アプリ６０２は、メールデータを保存するとともに、端末６００の画面上にメールの内容を表示する（Ｓ１０７）。
【００１３】
メール用アプリ６０２は、上記のようにサーバ５００から取得したメールデータを記憶部６１２に保存しており、端末６００の画面上に、記憶部６１２に保存しているメールのリストを表示することができる。
【００１４】
次に、図１４は、従来の通信システムにおける掲示板サービスを実行する際の通信シーケンスを示す。
【００１５】
まず、端末６００の掲示板用アプリ６０１は、端末６００のユーザ操作によって入力された記事情報をサーバ５００へ送信する記事書込み処理を行う（Ｓ１１１）。サーバ５００の掲示板用サーバ部５０１は、端末６００から受信した記事情報を処理して、掲示板用データに変換し、記憶部５１１に格納する（Ｓ１１２）。記憶部５１１に格納された掲示板用データは、個別の記事データだけでなく、記事リストデータも作成され、保存される。そして、掲示板用アプリ６０１は、ユーザの受信操作等のイベントをトリガとして（Ｓ１１３）、「記事リスト要求」をサーバ５００へ送信する（Ｓ１１４）。「記事リスト要求」を受信した掲示板用サーバ部５０１は、端末６００宛の記事リストデータを記憶部５１１から読み出し、この端末６００宛の記事リストデータを端末６００へ送信する（Ｓ１１５）。記事リストデータを受信した掲示板用アプリ６０１は、端末６００の画面上に記事リストデータを表示する（Ｓ１１６）。
【００１６】
そして、ユーザは、画面上に表示された記事リストデータから所望の記事を選択し、掲示板用アプリ６０１は、この選択された記事の取得要求をサーバ５００へ送信する。掲示板用サーバ部５０１は、取得要求の対象となる記事データを記憶部５１１から読み出し、この記事データを端末６００へ送信する。記事データを受信した掲示板用アプリ６０１は、端末６００の画面上に記事データを表示する。
【００１７】
一般の掲示板サービスでは、掲示板用サーバ部５０１としてＨＴＴＰ（HyperText Transfer Protocol）サーバが使用され、さらにはＣＧＩ（Common Gateway Interface）等のプログラムが準備されており、データの形式変換を行っている。掲示板用サーバ部５０１は、掲示板のデータ取得要求が端末６００からあった場合、形式変換を行ったＨＴＭＬ形式の掲示板用データ（記事データ、記事リストデータ）を端末６００へ送信する。そして、端末６００の掲示板用アプリ６０１には、ＷＥＢブラウザが用いられており、ＷＥＢブラウザによって、受信したＨＴＭＬ形式の掲示板用データを画面上に表示する。
【００１８】
次に、図１５は、従来の通信システムにおいて、サーバ５００から端末６００へコマンドを送信する際の通信シーケンスを示す。
【００１９】
サーバ５００が端末６００へ処理要求コマンドを送信すると（Ｓ１２１）、端末６００は、受信したコマンドを解釈し（Ｓ１２２）、コマンド応答をサーバ５００へ返信する（Ｓ１２３）。これらの動作は、例えば分散オブジェクト操作等を用いることが考えられる。そして、端末６００は、受信したコマンドの解釈に基づく処理を実行するために、必要に応じてアプリケーションを起動させる（Ｓ１２４）。以降、起動したアプリケーション固有の処理を行う（Ｓ１２５）。
【先行技術文献】
【特許文献】
【００２０】
【特許文献１】特開２００８−１６５４４７号公報
【発明の概要】
【発明が解決しようとする課題】
【００２１】
従来の通信システムにおいて、例えば掲示板サービスでは、サーバ５００に、ＨＴＭＬ形式の掲示板データ（記事データ、記事リストデータ）を作成するための掲示板用サーバ５０１が必要になる。さらに、端末６００には、ＷＥＢブラウザ機能を有する掲示板用アプリ６０１を搭載する必要があり、端末６００のコストが高くなる要因となっていた。
【００２２】
また、メールサービスでは、サーバ５００にメール用サーバ部５０２を設け、端末６００にメール用アプリ６０２を設けて、メール用サーバ部５０２とメール用アプリ６０２とが、例えばＰＯＰ（Post Office Protocol）等のメール用プロトコルにしたがってメールデータの送受信を行う。
【００２３】
上記以外のサービスにおいても、サービス毎に個別のサーバ部およびアプリを設ける必要があり、さらにはサービス毎に独自のデータ構造を有するデータを用いていた。
【００２４】
このように、従来の通信システムで扱うデータは、サービスを提供するアプリケーション毎にデータ構造（データフォーマット、記述形式）が異なる。したがって、サーバ５００では、サービス毎のサーバ部が必要となり、サーバ側でのデータ管理が複雑化していた。また、端末６００では、アプリケーション毎に扱うデータ構造が異なるため、端末側でのデータ処理も複雑化していた。
【００２５】
本発明は、上記事由に鑑みてなされたものであり、その目的は、サーバから取得したデータに基づいて端末が複数のサービスを提供する場合に、サーバおよび端末でのデータ管理を簡略化できる通信システムを提供することにある。
【課題を解決するための手段】
【００２６】
請求項１の発明は、サーバと端末とが互いに通信可能に構成されて、前記端末が、前記サーバから取得したデータに基づいてユーザに複数のサービスを提供する通信システムであって、前記サーバは、ユーザに複数の前記サービスを提供するためのアプリケーションが用いる前記データを前記端末へ送信する第１の通信部と、この第１の通信部が送信する前記データを管理するデータ処理サーバ部とを備え、前記端末は、前記サーバから前記データを受信する第２の通信部と、１つ以上の前記アプリケーションを具備して、前記サーバから取得した前記データに基づいて前記アプリケーションを実行することによって、ユーザに前記サービスを提供するサービス機能部とを備え、前記データは、複数の前記サービスに共通のデータフォーマットで構成され、前記データフォーマットは、複数の前記サービスに共通の形式で記述されて、前記アプリケーションが用いるデータ本体領域と、複数の前記サービスに共通の形式で記述されて、前記データ本体領域が用いられる前記サービスに関する情報を少なくとも含む情報格納領域とを含んで構成されることを特徴とする。
【００２７】
この発明において、前記端末の前記サービス機能部は、１または複数の前記情報格納領域を前記サーバから取得した後に、この取得した１または複数の前記情報格納領域から選択したいずれかの前記情報格納領域と対になる前記データ本体領域を前記サーバから取得することが好ましい。
【００２８】
この発明において、前記端末は、前記サービス機能部が前記サーバから取得した前記情報格納領域および前記データ本体領域をキャッシュするキャッシュ部と、このキャッシュ部への前記情報格納領域および前記データ本体領域の読み書きを行うキャッシュ管理部とを備えることが好ましい。
【００２９】
この発明において、前記情報格納領域は、前記キャッシュ部にキャッシュするか否かを示すフラグを含み、前記端末の前記キャッシュ管理部は、前記サービス機能部が取得した前記情報格納領域に含まれる前記フラグに基づいて、前記サービス機能部が取得した前記サービス機能部および前記データ本体領域を前記キャッシュ部にキャッシュするか否かを判断することが好ましい。
【００３０】
この発明において、前記端末の前記サービス機能部は、前記サーバから前記データを取得する場合、前記取得するデータの前記情報格納領域が前記キャッシュ部にキャッシュされていれば、この情報格納領域を前記キャッシュ部から取得し、前記取得するデータの前記情報格納領域が前記キャッシュ部にキャッシュされていなければ、この情報格納領域を前記サーバから取得し、前記取得した１つ以上の前記情報格納領域のうち、所望の前記情報格納領域と対になる前記データ本体領域を前記サーバから取得する場合、前記取得するデータ本体領域が前記キャッシュ部にキャッシュされていれば、このデータ本体領域を前記キャッシュ部から取得し、前記取得するデータ本体領域が前記キャッシュ部にキャッシュされていなければ、このデータ本体領域を前記サーバから取得することが好ましい。
【００３１】
この発明において、前記情報格納領域は、時間間隔を示すインターバル情報を含み、前記端末の前記サービス機能部は、前記インターバル情報を含む前記情報格納領域を取得した場合、前記インターバル情報に基づく時間間隔毎に、前記取得した情報格納領域と対になる前記データ本体領域を前記サーバから取得することが好ましい。
【発明の効果】
【００３２】
以上説明したように、本発明では、サーバから取得したデータに基づいて端末が複数のサービスを提供する場合に、サーバおよび端末でのデータ管理を簡略化できるという効果がある。
【図面の簡単な説明】
【００３３】
【図１】実施形態における通信システムの構成を示すブロック図である。
【図２】同上の共通データのデータフォーマットを示す構造図である。
【図３】同上のサーバが保持するアプリケーション情報を示すテーブル図である。
【図４】同上のサーバによるデータ変換処理を示すフローチャート図である。
【図５】同上のサーバのデータベースの格納されているデータ構造を示すテーブル図である。
【図６】同上の端末が保持するアプリケーション情報を示すテーブル図である。
【図７】同上の端末における共通データ取得処理を示すフローチャート図である。
【図８】同上のサーバにおける共通データ取得処理を示すフローチャート図である。
【図９】同上の端末における共通データ取得処理を示すフローチャート図である。
【図１０】同上の端末におけるキャッシュ済の共通データ取得処理を示すフローチャート図である。
【図１１】同上の端末における繰り返し要求処理を示すフローチャート図である。
【図１２】従来の通信システムの構成を示すブロック図である。
【図１３】従来の通信システムにおけるメールサービスを示すシーケンス図である。
【図１４】従来の通信システムにおける掲示板サービスを示すシーケンス図である。
【図１５】従来の通信システムにおけるコマンド送信を示すシーケンス図である。
【発明を実施するための形態】
【００３４】
以下、本発明の実施の形態を図面に基づいて説明する。
【００３５】
（実施形態）
本実施形態の通信システムは、図１に示すように、サーバ１と、クライアント側の複数の端末２とがネットワークＮＴ１に接続して、互いに通信可能に構成されている。この通信システムは、集合住宅において、各住戸に設置された専用端末やパーソナルコンピュータ等の端末２が、ネットワークＮＴ１を介して集合住宅用のサーバ１に接続し、サーバ１が各住戸の端末２へ各種のサービスを提供する。サービスには、掲示板サービス、メールサービス（簡易メッセージ）、スケジューラサービス等がある。
【００３６】
そして、サーバ１は、通信部１１と、データ処理サーバ部１２と、データ管理部１３と、データベース１４とを備える。なお、サーバ１の設置場所は、集合住宅の内外を問わない。
【００３７】
通信部１１は、ネットワークＮＴ１との間で信号授受を行うインターフェース機能を有しており、本発明の第１の通信部を構成している。
【００３８】
データベース１４は、上記サービスの各々に対応したデータが格納されており、各データを端末２へ送信することによって、端末２は各サービスをユーザへ提供可能となる。
【００３９】
データ管理部１３は、データベース１４内の各データを管理しており、データベース１４におけるデータの書き込み、読み出し、削除を行う。
【００４０】
データ処理サーバ部１２は、通信部１１によるデータの送受信、データ管理部１３によるデータベース１４のデータ管理、後述のデータ形式の変換処理等を行う。
【００４１】
次に、端末２は、通信部２１と、サービス機能部２２と、キャッシュ部２３と、キャッシュ管理部２４とを備える。
【００４２】
通信部２１は、ネットワークＮＴ１との間で信号授受を行うインターフェース機能を有しており、本発明の第２の通信部を構成している。
【００４３】
サービス機能部２２は、各種サービスを実行するためのアプリケーションが搭載されており、本実施形態では、掲示板用アプリケーション２２１と、メール用アプリケーション２２２と、スケジューラ用アプリケーション２２３とが搭載されている。なお、以降、掲示板用アプリ２２１、メール用アプリ２２２、スケジューラ用アプリ２２３と称す。また、掲示板用アプリ２２１、メール用アプリ２２２、スケジューラ用アプリ２２３をまとめて端末側アプリと称す。
【００４４】
キャッシュ部２３は、サーバ１から取得したデータをキャッシュし、キャッシュ管理部２４は、キャッシュ部２３内の各データを管理しており、キャッシュ部２３におけるデータの書き込み、読み出し、削除を行う。
【００４５】
そして、端末２の端末側アプリ２２１〜２２３は、サービス実行時に、サーバ１のデータベース１４に格納されているデータを取得する。
【００４６】
データベース１４に格納されているデータには、掲示板用アプリ２２１が用いる掲示板用データ、メール用アプリ２２２が用いるメール用データ、スケジューラ用アプリ２２３が用いるスケジューラ用データ等がある。
【００４７】
例えば、掲示板用データは、データ処理サーバ部１２が、端末２の掲示板用アプリ２２１が作成した記事情報を受信し、この受信した記事情報を処理して掲示板用データに変換しており、データ管理部１３が掲示板用データをデータベース１４に格納する。
【００４８】
メール用データは、データ処理サーバ部１２が、インターネット等の外部ネットワークからメール情報を受信し、この受信したメール情報を処理してメール用データに変換しており、データ管理部１３がメール用データをデータベース１４に格納する。
【００４９】
スケジューラ用データは、データ処理サーバ部１２が、端末２のスケジューラ用アプリ２２３が作成したスケジュール情報を受信し、この受信したスケジュール情報を処理してスケジューラ用データに変換している。そして、データ管理部１３がスケジューラ用データをデータベース１４に格納する。
【００５０】
本実施形態において、データベース１４に格納されている掲示板用データ、メール用データ、スケジューラ用データ等は、データ処理サーバ部１２によって、これらのデータを用いるサービスに関わらず、共通のデータフォーマットで構成されている。以降、共通のデータフォーマットで構成された掲示板用データ、メール用データ、スケジューラ用データ等のデータを、共通データと総称する。
【００５１】
図２は、共通データのデータフォーマット（以降、共通フォーマットと称す）を示しており、共通データの先頭に設けられた情報格納領域Ｒ１（ＩＮＤＥＸ）と、情報格納領域Ｒ１に続いて設けられたデータ本体領域Ｒ２（ＢＯＤＹ）とで構成される。
【００５２】
情報格納領域Ｒ１は、データ本体領域Ｒ２が用いられるサービス（掲示板サービス、メールサービス、スケジューラサービス等）に関する情報が少なくとも含まれている。本実施形態では、「ＩＤ」、「Ｆｒｏｍ」、「Ｔｏ」、「Ｄａｔｅ」、「Ｐｒｉｏｒｉｔｙ」、「Ｌｉｍｉｔ」、「Ｌｏｏｐ」、「Ｉｎｔｅｒｖａｌ」、「Ｔｙｐｅ」、「Ｃａｃｈｅ」の各情報が情報格納領域Ｒ１に含まれている。この情報格納領域Ｒ１におけるデータの記述形式は、掲示板用アプリ２２１、メール用アプリ２２２、スケジューラ用アプリ２２３等の各アプリケーションに対して共通に設定される。
【００５３】
「ＩＤ」情報は、この共通データを管理するための識別情報であり、「Ｆｒｏｍ」情報は、この共通データの送信元のアドレス情報であり、「Ｔｏ」情報は、この共通データの送信先のアドレス情報であり、「Ｄａｔｅ」情報は、共通データの作成日時を示す。「Ｐｒｉｏｒｉｔｙ」情報は、この共通データの優先度であり、「Ｌｉｍｉｔ」情報は、この共通データの有効期限を示す。「Ｌｏｏｐ」情報は、後述の繰り返し要求の有無を示し、「Ｉｎｔｅｒｖａｌ」情報（インターバル情報）は、繰り返し要求時におけるインターバル時間を示す。「Ｔｙｐｅ」情報は、この共通データが用いられるアプリケーションの種類や、この共通データの種類を示す。「Ｃａｃｈｅ」情報は、この共通データをキャッシュする必要性の有無を示す。
【００５４】
したがって、端末２のサービス機能部２２は、共通データの情報格納領域Ｒ１（の「Ｔｙｐｅ」情報）を参照することによって、この共通データを用いるアプリケーションを判別でき、対象のアプリケーションに共通データを引き渡すことができる。
【００５５】
データ本体領域Ｒ２は、端末２のサービス機能部２２に搭載している各アプリケーションが、サービス実行時に実際に用いるデータであり、データ本体領域Ｒ２を用いるアプリケーションの種類やデータの種類は、情報格納領域Ｒ１の「Ｔｙｐｅ」に示されている。このデータ本体領域Ｒ２におけるデータの記述形式は、掲示板用アプリ２２１、メール用アプリ２２２、スケジューラ用アプリ２２３等の各アプリケーションに対して共通に設定される。
【００５６】
本実施形態では、サーバ１のデータ処理サーバ部１２が、外部から入力される様々なフォーマットの情報を、共通フォーマットの共通データに変換して、データベース１４に格納している。ここで、外部から入力される様々なフォーマットの情報とは、掲示板サービスに用いる記事情報、メールサービスに用いるメール情報、スケジューラサービスに用いるスケジューラ用アプリ２２３が作成したスケジュール情報等である。これらの各情報は、集合住宅内のネットワークＮＴ１経由、インターネット等の外部ネットワーク経由で、サーバ１が受信する。
【００５７】
そして、データ処理サーバ部１２は、図３に示すアプリケーション情報Ｊ１を記憶しており、このアプリケーション情報Ｊ１に基づいて、共通データへの変換処理を行う。アプリケーション情報Ｊ１は、端末２のサービス機能部２２に搭載しているアプリケーション毎に、Ｔｙｐｅ情報、入力情報形式、変換手段の各項目が設定されている。
【００５８】
例えば、掲示板用アプリケーションは、Ｔｙｐｅ情報「ＩＤ１」、入力情報形式「ＨＴＭＬ」、変換手段「変換手法１」が設定されている。すなわち、「ＨＴＭＬ」の入力情報形式で作成された記事情報は、「変換手法１」によって共通フォーマットの掲示板用データに変換され、掲示板用データの情報格納領域Ｒ１の「Ｔｙｐｅ」情報には、「ＩＤ１」が設定される。
【００５９】
また、メール用アプリケーションは、Ｔｙｐｅ情報「ＩＤ２」、入力情報形式「ＭＢＯＸ」、変換手段「変換手法２」が設定されている。すなわち、「ＭＢＯＸ」の入力情報形式で作成されたメール情報は、「変換手法２」によって共通フォーマットのメール用データに変換され、メール用データの情報格納領域Ｒ１の「Ｔｙｐｅ」情報には、「ＩＤ２」が設定される。
【００６０】
また、スケジューラ用アプリケーションは、Ｔｙｐｅ情報「ＩＤ３」、入力情報形式「ｖＣａｌｅｎｄａｒ」、変換手段「変換手法３」が設定されている。すなわち、「ｖＣａｌｅｎｄａｒ」の入力情報形式で作成されたスケジュール情報は、「変換手法３」によって共通フォーマットのスケジューラ用データに変換され、スケジューラ用データの情報格納領域Ｒ１の「Ｔｙｐｅ」情報には、「ＩＤ３」が設定される。
【００６１】
図４は、サーバ１のデータ処理サーバ部１２によるデータ変換処理を示す動作フローチャートである。まず、データ処理サーバ部１２は、情報が入力されると（Ｓ１）、入力された情報に対応するアプリケーションタイプ（掲示板、メール、スケジューラ）を判定し（Ｓ２）、さらに共通フォーマットで作成された共通データであるか否かを判定する（Ｓ３）。入力された情報が共通データであれば、データベース１４に格納する（Ｓ５）。入力された情報が共通データでなければ、上記のようにアプリケーション情報Ｊ１に基づいて共通データへの変換処理を行った後（Ｓ４）、データベース１４に格納する（Ｓ５）。
【００６２】
そして、サーバ１のデータベース１４には、図５に示すように、情報格納領域Ｒ１とデータ本体領域Ｒ２とを対にした共通データが格納されている。
【００６３】
また、端末２のサービス機能部２２は、図６に示すアプリケーション情報Ｊ２を記憶しており、このアプリケーション情報Ｊ２に基づいて、サーバ１から取得した共通データを処理する。アプリケーション情報Ｊ２は、端末２のサービス機能部２２に搭載しているアプリケーション毎に、Ｔｙｐｅ情報、処理内容の各項目が設定されている。
【００６４】
例えば、サービス機能部２２は、Ｔｙｐｅ情報「ＩＤ１」が設定された共通データは掲示板用データであると判断して、掲示板用アプリ２２１を実行し、この掲示板用データを端末２の画面上に表示する。
【００６５】
また、サービス機能部２２は、Ｔｙｐｅ情報「ＩＤ２」が設定された共通データはメール用データであると判断して、メール用アプリ２２２を実行し、このメール用データを端末２の画面上に表示する。
【００６６】
また、サービス機能部２２は、Ｔｙｐｅ情報「ＩＤ３」が設定された共通データはスケジューラ用データであると判断して、スケジューラ用アプリ２２３を実行し、このスケジューラ用データを端末２の画面上に表示する。
【００６７】
次に、図７に示す端末２の動作フローチャート、図８に示すサーバ１の動作フローチャートを用いて、端末２によるサーバ１からの共通データ取得処理を説明する。以下、掲示板サービスを例にして説明する。
【００６８】
まず、端末２の掲示板用アプリ２２１は、端末２のユーザ操作によって、掲示板サービスのリスト要求をサーバ１へ送信する（Ｓ１１）。リスト要求には、送信元の端末２の端末ＩＤ（部屋番号）、要求するデータの「Ｔｙｐｅ」情報（この場合、ＩＤ１）が付加されている。
【００６９】
サーバ１のデータ処理サーバ部１２は、掲示板サービスのリスト要求を受信すると（Ｓ２１）、受信したリスト要求に基づいて、リスト要求の送信元である端末２の端末ＩＤを確認し（Ｓ２２）、さらに、「Ｔｙｐｅ」情報を確認する（Ｓ２３）。そして、データ管理部１３は、「Ｔｙｐｅ」情報が一致するデータ（この場合、掲示板用アプリ２２１が用いる掲示板用データ）から、リスト要求の送信元である端末２に関するデータを検索し、その情報格納領域Ｒ１のみをデータベース１４から読み出す（Ｓ２４）。データ処理サーバ部１２は、掲示板用データの情報格納領域Ｒ１のリストデータ（記事リストデータ）を端末２へ返信する（Ｓ２５）。
【００７０】
リスト要求を送信した端末２のサービス機能部２２は、リスト要求に対するサーバ１の応答（記事リストデータの返信）があるか否かを判定している（Ｓ１２）。そして、サービス機能部２２は、サーバ１から記事リストデータを取得すると（Ｓ１３）、記事リストデータを構成する情報格納領域Ｒ１に含まれる「Ｔｙｐｅ」情報に基づいて、掲示板サービス用のデータであると解釈し、掲示板用アプリ２２１を実行する（Ｓ１４）。掲示板用アプリ２２１は、掲示板用データの情報格納領域Ｒ１のリストを、端末２の画面上に表示する。
【００７１】
さらに、掲示板用アプリ２２１は、サーバ１から取得した記事リストデータを構成する情報格納領域Ｒ１の各々について、情報格納領域Ｒ１内の「Ｃａｃｈｅ」情報を参照して、リスト内の情報格納領域Ｒ１の各々をキャッシュする必要性を判定する（Ｓ１５）。そして、「Ｃａｃｈｅ」情報が必要性「有」に設定されている情報格納領域Ｒ１のみを、キャッシュ管理部２４によって、キャッシュ部２３にキャッシュする（Ｓ１６）。「Ｃａｃｈｅ」情報が必要性「無」に設定されている情報格納領域Ｒ１は、キャッシュ部２３にキャッシュされることなく、リスト表示の終了後に破棄される（Ｓ１７）。
【００７２】
また、掲示板用アプリ２２１以外のアプリケーション（メール用アプリ２２２、スケジューラ用アプリ２２３等）が用いるデータのリスト要求を端末２がサーバ１へ送信した場合も、上記同様に処理される。すなわち、端末２は、メールリストデータ、スケジュールリストデータをサーバ１から受信して、画面上に表示可能となる。
【００７３】
リストは、情報格納領域Ｒ１に含まれる各情報に基づいて表示されており、メールサービスであれば、メールの送信者、タイトル、受信日時等の情報である。掲示板サービスであれば、記事のタイトル、記事の作成者、記事の作成日時等の情報である。スケジュールサービスであれば、スケジュールのタイトル、スケジュールの作成日時等である。
【００７４】
図９は、リストデータ（記事リストデータ、メールリストデータ、スケジュールリストデータ等）を表示している端末２における処理を示す動作フローチャートである。以下、掲示板サービスを例にして説明する。
【００７５】
まず、端末２は、その画面上に、掲示板サービスの記事リストデータを表示している。そして、端末２は、画面上に表示している記事リストデータから、ユーザ操作によっていずれかの記事を選択可能に構成されており、選択待ち状態となる（Ｓ３１）。次に、記事の選択操作の有無を判定し（Ｓ３２）、記事の選択操作が発生すれば、掲示板用アプリ２２１は、掲示板サービスのデータ本体要求をサーバ１へ送信する（Ｓ３３）。すなわち、ユーザは、詳細な内容を知りたい記事を記事リストデータから選択し、この記事のデータ本体領域Ｒ２（記事データ）を取得するために、サーバ１へデータ本体要求を送信する。データ本体要求には、送信元の端末２の端末ＩＤ（部屋番号）、要求するデータの「Ｔｙｐｅ」情報（この場合、ＩＤ１）だけでなく、選択した記事に関する情報も付加されている。
【００７６】
サーバ１のデータ処理サーバ部１２は、受信したデータ本体要求に基づき、データ管理部１３によってデータベース１４から、要求対象となる掲示板用データのデータ本体領域Ｒ２を検索して読み出す。そして、データ処理サーバ部１２は、掲示板用データのデータ本体領域Ｒ２を端末２へ返信する。
【００７７】
データ本体要求を送信した端末２のサービス機能部２２は、データ本体要求に対するサーバ１の応答（記事データの返信）があるか否かを判定している（Ｓ３４）。そして、サービス機能部２２は、サーバ１から記事データを取得すると（Ｓ３５）、掲示板用アプリ２２１を実行し、取得した記事データ（掲示板用データのデータ本体領域Ｒ２）を、端末２の画面上に表示する（Ｓ３６）。
【００７８】
さらに、掲示板用アプリ２２１は、サーバ１から取得した記事データと対になる情報格納領域Ｒ１がキャッシュ部２３に格納されているか否かを判断することによって、サーバ１から取得したデータ本体領域Ｒ２をキャッシュする必要性を判定する（Ｓ３７）。サーバ１から取得した記事データと対になる情報格納領域Ｒ１がキャッシュ部２３に格納されている場合、サーバ１から取得したデータ本体領域Ｒ２を、キャッシュ管理部２４によって、キャッシュ部２３にキャッシュする（Ｓ３８）。サーバ１から取得したデータ本体領域Ｒ２と対になる情報格納領域Ｒ１がキャッシュ部２３に格納されていない場合、サーバ１から取得したデータ本体領域Ｒ２を、キャッシュ部２３にキャッシュすることなく、表示終了後に破棄する（Ｓ３９）。
【００７９】
また、掲示板用アプリ２２１以外のアプリケーション（メール用アプリ２２２、スケジューラ用アプリ２２３等）が用いるデータのデータ本体要求を端末２がサーバ１へ送信した場合も、上記同様に処理される。すなわち、端末２は、メール内容、スケジュール内容をサーバ１から受信して、画面上に表示可能となる。
【００８０】
このように、端末２がサーバ１から受信するデータの構造は共通フォーマットに統一されており、サーバ１、端末２では、複数のサービスに対して、共通のデータ構造を用いたデータ処理が可能となる。
【００８１】
したがって、複数のサービスを提供可能に構成した場合でも、サーバ１は、共通フォーマットで構成された共通データをデータベース１４に格納すればよく、データ管理部１３によるデータ検索が容易となる。また、データ処理サーバ部１２も、異なるサービスであっても、統一された共通データに対してデータ処理を行えばよいので、データ管理が容易となる。また、サービス毎のサーバ部が不要となり、サーバ１の構成を簡略化できる。
【００８２】
また、端末２においても、サーバ１から取得するデータは共通データに統一されるので、各サービスに対応するアプリケーション毎にデータのメモリ領域を確保する必要がなく、メモリリソースを有効に使用することができる。また、サービス毎のデータ管理も容易となる。
【００８３】
さらに、提供するサービスが互いに異なるアプリケーションにおいて、統一された共通データを用いるので、各アプリケーションでは同様のアルゴリズムを用いたデータ処理が可能となり、アプリケーションの作成が容易となる。
【００８４】
すなわち、本実施形態では、サーバ１および端末２でのデータ管理を簡略化できる。
【００８５】
また、共通データは、情報格納領域Ｒ１とデータ本体領域Ｒ２とで構成されており、端末２は、最初に情報格納領域Ｒ１のみをサーバ１から取得してリスト表示した後に、必要なデータ本体領域Ｒ２をサーバ１から取得することができる。したがって、情報格納領域Ｒ１とデータ本体領域Ｒ２との両方をサーバ１から一括して取得する場合に比べて、高速通信が可能となり、さらには通信路全体のデータ量も抑えることができる。また、サーバ１が全ての共通データをデータベース１４に格納しており、端末２は、必要なデータのみをキャッシュ部２３にキャッシュすればよく、端末２のメモリリソースを抑えることができる。
【００８６】
また、端末２のサービス機能部２２（アプリケーション）は、情報格納領域Ｒ１の「Ｃａｃｈｅ」情報を参照して、データをキャッシュする必要性の有無を判断している。したがって、不要なデータはキャッシュすることなく、端末２のメモリリソースをさらに抑えることができる。情報格納領域Ｒ１の「Ｃａｃｈｅ」情報は、サーバ１のデータ処理サーバ部１２が作成しており、サーバ１が端末２におけるキャッシュの要否を判断して、端末２のキャッシュ動作を制御することができる。
【００８７】
次に、情報格納領域Ｒ１およびデータ本体領域Ｒ２をキャッシュ部２３にキャッシュ済の共通データの取得処理について、図１０の動作フローチャートを用いて説明する。以下、掲示板サービスを例にして説明する。
【００８８】
まず、端末２は、その画面上に、掲示板サービスの記事リストデータを表示している。そして、端末２は、画面上に表示している記事リストデータから、ユーザ操作によっていずれかの記事を選択可能に構成されており、選択待ち状態となる（Ｓ４１）。次に、記事の選択操作の有無を判定し（Ｓ４２）、記事の選択操作が発生すれば、掲示板用アプリ２２１は、キャッシュ部２３を参照して（Ｓ４３）、選択した記事に対応するデータ本体領域Ｒ２がキャッシュ部２３にキャッシュされているか否かを判定する（Ｓ４４）。選択した記事に対応するデータ本体領域Ｒ２がキャッシュ部２３にキャッシュされている場合、該当するデータ本体領域Ｒ２をキャッシュ部２３から取得し、掲示板用アプリ２２１によって、取得した記事データ（掲示板用データのデータ本体領域Ｒ２）を、端末２の画面上に表示する（Ｓ４５）。
【００８９】
選択した記事に対応するデータ本体領域Ｒ２がキャッシュ部２３にキャッシュされていない場合、端末２は、図９のステップＳ３３以降と同様の処理を行い、サーバ１から記事データを取得して、表示する。
【００９０】
また、掲示板用アプリ２２１以外のアプリケーション（メール用アプリ２２２、スケジューラ用アプリ２２３等）が用いるデータのデータ本体要求を端末２がサーバ１へ送信した場合も、上記同様に処理される。すなわち、端末２は、メール内容、スケジュール内容の取得処理を、キャッシュ状況に応じて行うことができる。
【００９１】
このように、端末２のサービス機能部２２（アプリケーション）は、データ本体領域Ｒ２をサーバ１から取得する場合、まずキャッシュ部２３のキャッシュ状況を確認する。そして、取得するデータ本体領域Ｒ２がキャッシュされていれば、キャッシュされているデータを取得するので、処理速度を向上させることができる。また、アプリケーション毎に異なるフォーマットのデータをキャッシュすることなく、共通フォーマットの共通データをキャッシュしているので、キャッシュ部２３におけるデータの検索処理、保存処理が容易となる。
【００９２】
また、端末２のサービス機能部２２（アプリケーション）は、実行するサービスに対応するいずれかの情報格納領域Ｒ１をサーバ１から取得する場合も、まずキャッシュ部２３のキャッシュ状況を確認する。そして、取得する情報格納領域Ｒ１がキャッシュされていれば、キャッシュされているデータを取得するので、処理速度を向上させることができる。一方、取得する情報格納領域Ｒ１がキャッシュされていなければ、サーバ１から情報格納領域Ｒ１を取得する。
【００９３】
次に、共通データの情報格納領域Ｒ１に含まれる「Ｌｏｏｐ」情報、「Ｉｎｔｅｒｖａｌ」情報を用いた繰り返し要求処理について、図１１に示す動作フローチャートを用いて説明する。
【００９４】
共通データの情報格納領域Ｒ１に含まれる「Ｌｏｏｐ」情報は、繰り返し要求の有無を示し、「Ｉｎｔｅｒｖａｌ」情報は、インターバル時間を示す。そして、端末２のサービス機能部２２は、サーバ１から受信した情報格納領域Ｒ１を読み込み（Ｓ５１）、「Ｌｏｏｐ」情報に「繰り返し要求有り」が設定されている場合、以降、この情報格納領域Ｒ１と対になるデータ本体領域Ｒ２を定期的にサーバ１から取得する。
【００９５】
具体的に、端末２のサービス機能部２２は、情報格納領域Ｒ１に含まれる「Ｉｎｔｅｒｖａｌ」情報を参照して、インターバル時間を確認する（Ｓ５２）。そして、サービス機能部２２は、計時動作を開始し、計時時間がインターバル時間に達したか否かを判定する（Ｓ５３）。サービス機能部２２は、計時時間がインターバル時間に達した時点で、対応するアプリケーションを実行し、サーバ１へデータ本体要求を送信して、対応するデータ本体領域Ｒ１をサーバ１から取得して、画面上に表示する（Ｓ５４）。
【００９６】
したがって、時間の経過に伴ってサーバ１へ順次入力される情報を、端末２が定期的にサーバ１から取得することができ、簡易なサーバ側サービスを実現できる。
【００９７】
本発明では、サーバ１と端末２との間で授受されるデータを、共通フォーマットの共通データで構成しており、サーバ１および端末２においてデータ管理を容易にすることが目的である。データ構造は、図２に示す情報格納領域Ｒ１およびデータ本体領域Ｒ２において、そのデータ形式（ＸＭＬ等のテキストデータ、バイナリデータ等）は問わない。例えば、メール用データであれば、情報格納領域Ｒ１に、データ本体領域Ｒ２が用いられるメールサービスに関する情報が格納され、データ本体領域Ｒ２にメール内容が格納されていればよい。
【００９８】
また、図２に示す情報格納領域Ｒ１に含まれる各情報は一例であり、情報格納領域Ｒ１には、これらの情報のうち、共通データが用いられるアプリケーションの種類や、この共通データの種類を示す「Ｔｙｐｅ」情報が少なくとも含まれていればよい。さらに、情報格納領域Ｒ１には、図２に示されていない情報が含まれていてもよい。
【００９９】
さらに、共通データは、情報格納領域Ｒ１に情報が必ず含まれていなければならないが、データ本体領域Ｒ２における情報の有無は問わない。例えば、情報格納領域Ｒ１の「Ｔｙｐｅ」情報に特殊な情報を設定して、情報格納領域Ｒ１をコマンドとして使用する場合、データ本体領域Ｒ２に情報は格納されない。このような場合、データ本体領域Ｒ２における情報の有無を、情報格納領域Ｒ１に書き込んでもよい。
【０１００】
また、サーバ１に設けたデータベース１４の種類や記憶方法も問わない。例えば、一般的なＲＤＢＭＳ（Relational DataBase ManagementSystem）を用いてもよく、あるいは独自のデータベース構造を用いてもよい。すなわち、端末２からの要求に応じて、共通データの情報格納領域Ｒ１およびデータ本体領域Ｒ２を検索できればよい。
【０１０１】
また、サーバ１に情報を入力する方法も、その手段を問わない。例えば、メールサービスであれば、外部のプロバイダのメールサーバから、ＭＢＯＸ等の一般的なメール形式でデータを受け取った後に、共通データに変換する方法、プロバイダ独自のメール形式を用いた共通データ構造でデータを受け取る方法等がある。すなわち、外部からサーバ１に入力された情報が、最終的に、サーバ１のデータベース１４に共通データの構造で格納できればよい。
【０１０２】
また、端末２の画面上におけるデータの表示形態も問わない。例えば掲示板サービスの場合、記事リストデータの表示形態は、掲示板用アプリ２２１に依存している。すなわち、端末２は、サーバ１から取得した共通データの情報格納領域Ｒ１に含まれている各情報に基づいて、対応するアプリケーションが実行されるのであれば、データの表示方法や、アプリケーションの仕様等は問わない。
【０１０３】
また、端末２との間で共通データを授受する機器は、サーバ１に限定されることなく、例えば、端末２同士が行うチャットサービスにおいて、サーバ１を介することなく、端末２−端末２間の通信に共通データを用いてもよい。さらには、端末２が、図示しない宅内機器の監視制御サービスを行う場合も同様に、サーバ１を介することなく、端末２−宅内機器間の通信に共通データを用いてもよい。さらには、端末２が、玄関、エレベータ等に設置された図示しないインターホン機器との間でメッセージ通信を行う場合も同様に、サーバ１を介することなく、端末２−インターホン機器間の通信に共通データを用いてもよい。
【０１０４】
また、端末２のサービス機能部２２には、掲示板用アプリ２２１、メール用アプリ２２２、スケジューラ用アプリ２２３を個別に搭載している。例えば、掲示板サービスの場合、掲示板用データの表示方法があり、メールサービスの場合、メール用データの表示方法があり、スケジューラサービスの場合、スケジューラ用データの表示方法があり、それぞれのサービスに適した表示方法ある。そこで、サービス毎に適した表示機能内の検索処理、ソート処理等を実現するためには、サービス毎に個別のアプリケーションを用いたほうがよい。
【０１０５】
一方、本発明では、端末２が他の機器との間で授受するデータは、共通フォーマットの共通データで構成されているので、アプリケーションに要求される機能は、データの表示機能が主となる。そこで、端末２のサービス機能部２２には、掲示板用アプリ２２１、メール用アプリ２２２、スケジューラ用アプリ２２３等の各機能を有する１つのアプリケーションを搭載してもよい。また、掲示板サービス、メールサービス、スケジューラサービス等の各共通データを端末２において一括表示して、ユーザの選択操作によってフィルタリング処理を行う場合も、複数のサービスの各機能を有する１つのアプリケーションを搭載してもよい。
【０１０６】
また、上述の例では、端末２がサーバ１に対して要求を送信し、サーバ１が、この要求に対する返信として共通データを端末２へ送信している。しかし、サーバ１が共通データを端末２へ送信するトリガとしては、端末２からの要求以外であってもよい。例えば、サーバ１がメール用データを端末２へ送信するトリガとして、端末２からの要求を用いた場合、端末２によるメール確認が遅れてしまう虞がある。そこで、サーバ１が、外部からのメール情報の受信時、または定期的に、データベース１４に格納しているメール用データの情報格納領域Ｒ１のリスト（メールリストデータ）を、自発的に端末２へ送信してもよい。
【０１０７】
また、従来は、図１２に示すように、ユーザに提供するサービスの数だけ、サーバ５００のサーバ部（サーバ側アプリ）、および端末６００のアプリケーション（端末側アプリ）が必要であった。すなわち、新規のサービスを追加する場合には、図１２に示すように、サーバ５００に、新規のサーバ部５０４および記憶部５１４を追加し、端末６００に、新規のアプリ６０４および記憶部６１４を追加する必要があった。したがって、新規のサービスを追加することは容易ではなかった
一方、本発明において、サーバ１−端末２間で授受されるデータは、共通データに統一されているので、新規のサービスを追加する場合、サーバ部１のデータ処理サーバ部１２、端末２のサービス機能部２２に新しい機能を追加することは容易となる。
【符号の説明】
【０１０８】
１ サーバ
１１ 通信部
１２ データ処理サーバ部
１３ データ管理部
１４ データベース
２ 端末
２１ 通信部
２２ サービス機能部
２３ キャッシュ部
２４ キャッシュ管理部
ＮＴ１ ネットワーク
【技術分野】
【０００１】
本発明は、サーバと端末とが互いに通信可能に構成されて、端末が、サーバから取得したデータに基づいてユーザに複数のサービスを提供する通信システムに関するものである。
【背景技術】
【０００２】
集合住宅において、各住戸に設置された専用端末やパーソナルコンピュータ等の端末が、中継装置を介して集合住宅用のサーバに接続し、サーバが各住戸の端末へ各種のサービスを提供する通信システムがある（例えば、特許文献１参照）。
【０００３】
しかしながら、中継装置を介することなく、端末装置とサーバとが直接通信を行い、サーバが各住戸の端末へ各種のサービスを提供する通信システムがあり、システム構成の簡略化の点で優れている。
【０００４】
サービスとしては、掲示板サービス、メールサービス（簡易メッセージ）、スケジューラサービス等がある。
【０００５】
図１２は、従来の通信システムの構成を示し、サーバ５００と、クライアント側の端末６００とがネットワークＮＴ１１に接続して、互いに通信可能に構成されている。
【０００６】
サーバ５００は、サービス毎に個別のサーバ機能を有しており、掲示板用サーバ部５０１、メール用サーバ部５０２、スケジューラ用サーバ部５０３等が個別に設けられている。そして、各サーバ部５０１〜５０３には、それぞれのサービスに対応したサーバ側アプリケーション（サーバ側アプリ）が搭載されている。
【０００７】
さらに、掲示板用サーバ部５０１、メール用サーバ部５０２、スケジューラ用サーバ部５０３の各々は、個別の記憶部５１１，５１２，５１３を有している。そして、各サービスに対応したデータは、サービス毎に個別に設けられた記憶部５１１，５１２，５１３に格納される。
【０００８】
一方、端末６００も、サービス毎に個別の端末側アプリケーション（端末側アプリ）が搭載されており、図１２では、掲示板用アプリケーション６０１、メール用アプリケーション６０２、スケジューラ用アプリケーション６０３等が個別に設けられている。なお、以降、掲示板用アプリ６０１、メール用アプリ６０２、スケジューラ用アプリ６０３と称す。また、掲示板用アプリ６０１、メール用アプリ６０２、スケジューラ用アプリ６０３をまとめて端末側アプリと称す。
【０００９】
そして、端末側アプリ６０１〜６０３の各々は、個別の記憶部６１１，６１２，６１３を有しており、各サービスに対応したデータは、サービス毎に個別に設けられた記憶部６１１，６１２，６１３に格納される。
【００１０】
図１３は、従来の通信システムにおけるメールサービスを実行する際の通信シーケンスを示す。
【００１１】
まず、端末６００のメール用アプリ６０２が、定期的に「メールの存在確認」をサーバ５００へ送信し、サーバ５００のメール用サーバ部５０２は、端末６００宛のメールが記憶部５１２に蓄積されているか否かを判別する（Ｓ１０１）。メール用サーバ部５０２は、端末６００宛のメールが蓄積されていない場合、「メールなし」のメッセージを端末６００へ返信する（Ｓ１０２）。メール用アプリ６０２は、「メールの存在確認」をサーバ５００へ送信するポーリングを定期的に繰り返す。
【００１２】
「メールの存在確認」を受信したメール用サーバ部５０２は、端末６００宛のメールが蓄積されている場合、「メールあり」のメッセージを端末６００へ返信する（Ｓ１０３）。そして、メール用アプリ６０２は、ユーザの受信操作等のイベントをトリガとして（Ｓ１０４）、「受信要求」をサーバ５００へ送信する（Ｓ１０５）。「受信要求」を受信したメール用サーバ部５０２は、端末６００宛のメールデータを記憶部５１２から読み出し、この端末６００宛のメールデータを端末６００へ送信する（Ｓ１０６）。メールデータを受信したメール用アプリ６０２は、メールデータを保存するとともに、端末６００の画面上にメールの内容を表示する（Ｓ１０７）。
【００１３】
メール用アプリ６０２は、上記のようにサーバ５００から取得したメールデータを記憶部６１２に保存しており、端末６００の画面上に、記憶部６１２に保存しているメールのリストを表示することができる。
【００１４】
次に、図１４は、従来の通信システムにおける掲示板サービスを実行する際の通信シーケンスを示す。
【００１５】
まず、端末６００の掲示板用アプリ６０１は、端末６００のユーザ操作によって入力された記事情報をサーバ５００へ送信する記事書込み処理を行う（Ｓ１１１）。サーバ５００の掲示板用サーバ部５０１は、端末６００から受信した記事情報を処理して、掲示板用データに変換し、記憶部５１１に格納する（Ｓ１１２）。記憶部５１１に格納された掲示板用データは、個別の記事データだけでなく、記事リストデータも作成され、保存される。そして、掲示板用アプリ６０１は、ユーザの受信操作等のイベントをトリガとして（Ｓ１１３）、「記事リスト要求」をサーバ５００へ送信する（Ｓ１１４）。「記事リスト要求」を受信した掲示板用サーバ部５０１は、端末６００宛の記事リストデータを記憶部５１１から読み出し、この端末６００宛の記事リストデータを端末６００へ送信する（Ｓ１１５）。記事リストデータを受信した掲示板用アプリ６０１は、端末６００の画面上に記事リストデータを表示する（Ｓ１１６）。
【００１６】
そして、ユーザは、画面上に表示された記事リストデータから所望の記事を選択し、掲示板用アプリ６０１は、この選択された記事の取得要求をサーバ５００へ送信する。掲示板用サーバ部５０１は、取得要求の対象となる記事データを記憶部５１１から読み出し、この記事データを端末６００へ送信する。記事データを受信した掲示板用アプリ６０１は、端末６００の画面上に記事データを表示する。
【００１７】
一般の掲示板サービスでは、掲示板用サーバ部５０１としてＨＴＴＰ（HyperText Transfer Protocol）サーバが使用され、さらにはＣＧＩ（Common Gateway Interface）等のプログラムが準備されており、データの形式変換を行っている。掲示板用サーバ部５０１は、掲示板のデータ取得要求が端末６００からあった場合、形式変換を行ったＨＴＭＬ形式の掲示板用データ（記事データ、記事リストデータ）を端末６００へ送信する。そして、端末６００の掲示板用アプリ６０１には、ＷＥＢブラウザが用いられており、ＷＥＢブラウザによって、受信したＨＴＭＬ形式の掲示板用データを画面上に表示する。
【００１８】
次に、図１５は、従来の通信システムにおいて、サーバ５００から端末６００へコマンドを送信する際の通信シーケンスを示す。
【００１９】
サーバ５００が端末６００へ処理要求コマンドを送信すると（Ｓ１２１）、端末６００は、受信したコマンドを解釈し（Ｓ１２２）、コマンド応答をサーバ５００へ返信する（Ｓ１２３）。これらの動作は、例えば分散オブジェクト操作等を用いることが考えられる。そして、端末６００は、受信したコマンドの解釈に基づく処理を実行するために、必要に応じてアプリケーションを起動させる（Ｓ１２４）。以降、起動したアプリケーション固有の処理を行う（Ｓ１２５）。
【先行技術文献】
【特許文献】
【００２０】
【特許文献１】特開２００８−１６５４４７号公報
【発明の概要】
【発明が解決しようとする課題】
【００２１】
従来の通信システムにおいて、例えば掲示板サービスでは、サーバ５００に、ＨＴＭＬ形式の掲示板データ（記事データ、記事リストデータ）を作成するための掲示板用サーバ５０１が必要になる。さらに、端末６００には、ＷＥＢブラウザ機能を有する掲示板用アプリ６０１を搭載する必要があり、端末６００のコストが高くなる要因となっていた。
【００２２】
また、メールサービスでは、サーバ５００にメール用サーバ部５０２を設け、端末６００にメール用アプリ６０２を設けて、メール用サーバ部５０２とメール用アプリ６０２とが、例えばＰＯＰ（Post Office Protocol）等のメール用プロトコルにしたがってメールデータの送受信を行う。
【００２３】
上記以外のサービスにおいても、サービス毎に個別のサーバ部およびアプリを設ける必要があり、さらにはサービス毎に独自のデータ構造を有するデータを用いていた。
【００２４】
このように、従来の通信システムで扱うデータは、サービスを提供するアプリケーション毎にデータ構造（データフォーマット、記述形式）が異なる。したがって、サーバ５００では、サービス毎のサーバ部が必要となり、サーバ側でのデータ管理が複雑化していた。また、端末６００では、アプリケーション毎に扱うデータ構造が異なるため、端末側でのデータ処理も複雑化していた。
【００２５】
本発明は、上記事由に鑑みてなされたものであり、その目的は、サーバから取得したデータに基づいて端末が複数のサービスを提供する場合に、サーバおよび端末でのデータ管理を簡略化できる通信システムを提供することにある。
【課題を解決するための手段】
【００２６】
請求項１の発明は、サーバと端末とが互いに通信可能に構成されて、前記端末が、前記サーバから取得したデータに基づいてユーザに複数のサービスを提供する通信システムであって、前記サーバは、ユーザに複数の前記サービスを提供するためのアプリケーションが用いる前記データを前記端末へ送信する第１の通信部と、この第１の通信部が送信する前記データを管理するデータ処理サーバ部とを備え、前記端末は、前記サーバから前記データを受信する第２の通信部と、１つ以上の前記アプリケーションを具備して、前記サーバから取得した前記データに基づいて前記アプリケーションを実行することによって、ユーザに前記サービスを提供するサービス機能部とを備え、前記データは、複数の前記サービスに共通のデータフォーマットで構成され、前記データフォーマットは、複数の前記サービスに共通の形式で記述されて、前記アプリケーションが用いるデータ本体領域と、複数の前記サービスに共通の形式で記述されて、前記データ本体領域が用いられる前記サービスに関する情報を少なくとも含む情報格納領域とを含んで構成されることを特徴とする。
【００２７】
この発明において、前記端末の前記サービス機能部は、１または複数の前記情報格納領域を前記サーバから取得した後に、この取得した１または複数の前記情報格納領域から選択したいずれかの前記情報格納領域と対になる前記データ本体領域を前記サーバから取得することが好ましい。
【００２８】
この発明において、前記端末は、前記サービス機能部が前記サーバから取得した前記情報格納領域および前記データ本体領域をキャッシュするキャッシュ部と、このキャッシュ部への前記情報格納領域および前記データ本体領域の読み書きを行うキャッシュ管理部とを備えることが好ましい。
【００２９】
この発明において、前記情報格納領域は、前記キャッシュ部にキャッシュするか否かを示すフラグを含み、前記端末の前記キャッシュ管理部は、前記サービス機能部が取得した前記情報格納領域に含まれる前記フラグに基づいて、前記サービス機能部が取得した前記サービス機能部および前記データ本体領域を前記キャッシュ部にキャッシュするか否かを判断することが好ましい。
【００３０】
この発明において、前記端末の前記サービス機能部は、前記サーバから前記データを取得する場合、前記取得するデータの前記情報格納領域が前記キャッシュ部にキャッシュされていれば、この情報格納領域を前記キャッシュ部から取得し、前記取得するデータの前記情報格納領域が前記キャッシュ部にキャッシュされていなければ、この情報格納領域を前記サーバから取得し、前記取得した１つ以上の前記情報格納領域のうち、所望の前記情報格納領域と対になる前記データ本体領域を前記サーバから取得する場合、前記取得するデータ本体領域が前記キャッシュ部にキャッシュされていれば、このデータ本体領域を前記キャッシュ部から取得し、前記取得するデータ本体領域が前記キャッシュ部にキャッシュされていなければ、このデータ本体領域を前記サーバから取得することが好ましい。
【００３１】
この発明において、前記情報格納領域は、時間間隔を示すインターバル情報を含み、前記端末の前記サービス機能部は、前記インターバル情報を含む前記情報格納領域を取得した場合、前記インターバル情報に基づく時間間隔毎に、前記取得した情報格納領域と対になる前記データ本体領域を前記サーバから取得することが好ましい。
【発明の効果】
【００３２】
以上説明したように、本発明では、サーバから取得したデータに基づいて端末が複数のサービスを提供する場合に、サーバおよび端末でのデータ管理を簡略化できるという効果がある。
【図面の簡単な説明】
【００３３】
【図１】実施形態における通信システムの構成を示すブロック図である。
【図２】同上の共通データのデータフォーマットを示す構造図である。
【図３】同上のサーバが保持するアプリケーション情報を示すテーブル図である。
【図４】同上のサーバによるデータ変換処理を示すフローチャート図である。
【図５】同上のサーバのデータベースの格納されているデータ構造を示すテーブル図である。
【図６】同上の端末が保持するアプリケーション情報を示すテーブル図である。
【図７】同上の端末における共通データ取得処理を示すフローチャート図である。
【図８】同上のサーバにおける共通データ取得処理を示すフローチャート図である。
【図９】同上の端末における共通データ取得処理を示すフローチャート図である。
【図１０】同上の端末におけるキャッシュ済の共通データ取得処理を示すフローチャート図である。
【図１１】同上の端末における繰り返し要求処理を示すフローチャート図である。
【図１２】従来の通信システムの構成を示すブロック図である。
【図１３】従来の通信システムにおけるメールサービスを示すシーケンス図である。
【図１４】従来の通信システムにおける掲示板サービスを示すシーケンス図である。
【図１５】従来の通信システムにおけるコマンド送信を示すシーケンス図である。
【発明を実施するための形態】
【００３４】
以下、本発明の実施の形態を図面に基づいて説明する。
【００３５】
（実施形態）
本実施形態の通信システムは、図１に示すように、サーバ１と、クライアント側の複数の端末２とがネットワークＮＴ１に接続して、互いに通信可能に構成されている。この通信システムは、集合住宅において、各住戸に設置された専用端末やパーソナルコンピュータ等の端末２が、ネットワークＮＴ１を介して集合住宅用のサーバ１に接続し、サーバ１が各住戸の端末２へ各種のサービスを提供する。サービスには、掲示板サービス、メールサービス（簡易メッセージ）、スケジューラサービス等がある。
【００３６】
そして、サーバ１は、通信部１１と、データ処理サーバ部１２と、データ管理部１３と、データベース１４とを備える。なお、サーバ１の設置場所は、集合住宅の内外を問わない。
【００３７】
通信部１１は、ネットワークＮＴ１との間で信号授受を行うインターフェース機能を有しており、本発明の第１の通信部を構成している。
【００３８】
データベース１４は、上記サービスの各々に対応したデータが格納されており、各データを端末２へ送信することによって、端末２は各サービスをユーザへ提供可能となる。
【００３９】
データ管理部１３は、データベース１４内の各データを管理しており、データベース１４におけるデータの書き込み、読み出し、削除を行う。
【００４０】
データ処理サーバ部１２は、通信部１１によるデータの送受信、データ管理部１３によるデータベース１４のデータ管理、後述のデータ形式の変換処理等を行う。
【００４１】
次に、端末２は、通信部２１と、サービス機能部２２と、キャッシュ部２３と、キャッシュ管理部２４とを備える。
【００４２】
通信部２１は、ネットワークＮＴ１との間で信号授受を行うインターフェース機能を有しており、本発明の第２の通信部を構成している。
【００４３】
サービス機能部２２は、各種サービスを実行するためのアプリケーションが搭載されており、本実施形態では、掲示板用アプリケーション２２１と、メール用アプリケーション２２２と、スケジューラ用アプリケーション２２３とが搭載されている。なお、以降、掲示板用アプリ２２１、メール用アプリ２２２、スケジューラ用アプリ２２３と称す。また、掲示板用アプリ２２１、メール用アプリ２２２、スケジューラ用アプリ２２３をまとめて端末側アプリと称す。
【００４４】
キャッシュ部２３は、サーバ１から取得したデータをキャッシュし、キャッシュ管理部２４は、キャッシュ部２３内の各データを管理しており、キャッシュ部２３におけるデータの書き込み、読み出し、削除を行う。
【００４５】
そして、端末２の端末側アプリ２２１〜２２３は、サービス実行時に、サーバ１のデータベース１４に格納されているデータを取得する。
【００４６】
データベース１４に格納されているデータには、掲示板用アプリ２２１が用いる掲示板用データ、メール用アプリ２２２が用いるメール用データ、スケジューラ用アプリ２２３が用いるスケジューラ用データ等がある。
【００４７】
例えば、掲示板用データは、データ処理サーバ部１２が、端末２の掲示板用アプリ２２１が作成した記事情報を受信し、この受信した記事情報を処理して掲示板用データに変換しており、データ管理部１３が掲示板用データをデータベース１４に格納する。
【００４８】
メール用データは、データ処理サーバ部１２が、インターネット等の外部ネットワークからメール情報を受信し、この受信したメール情報を処理してメール用データに変換しており、データ管理部１３がメール用データをデータベース１４に格納する。
【００４９】
スケジューラ用データは、データ処理サーバ部１２が、端末２のスケジューラ用アプリ２２３が作成したスケジュール情報を受信し、この受信したスケジュール情報を処理してスケジューラ用データに変換している。そして、データ管理部１３がスケジューラ用データをデータベース１４に格納する。
【００５０】
本実施形態において、データベース１４に格納されている掲示板用データ、メール用データ、スケジューラ用データ等は、データ処理サーバ部１２によって、これらのデータを用いるサービスに関わらず、共通のデータフォーマットで構成されている。以降、共通のデータフォーマットで構成された掲示板用データ、メール用データ、スケジューラ用データ等のデータを、共通データと総称する。
【００５１】
図２は、共通データのデータフォーマット（以降、共通フォーマットと称す）を示しており、共通データの先頭に設けられた情報格納領域Ｒ１（ＩＮＤＥＸ）と、情報格納領域Ｒ１に続いて設けられたデータ本体領域Ｒ２（ＢＯＤＹ）とで構成される。
【００５２】
情報格納領域Ｒ１は、データ本体領域Ｒ２が用いられるサービス（掲示板サービス、メールサービス、スケジューラサービス等）に関する情報が少なくとも含まれている。本実施形態では、「ＩＤ」、「Ｆｒｏｍ」、「Ｔｏ」、「Ｄａｔｅ」、「Ｐｒｉｏｒｉｔｙ」、「Ｌｉｍｉｔ」、「Ｌｏｏｐ」、「Ｉｎｔｅｒｖａｌ」、「Ｔｙｐｅ」、「Ｃａｃｈｅ」の各情報が情報格納領域Ｒ１に含まれている。この情報格納領域Ｒ１におけるデータの記述形式は、掲示板用アプリ２２１、メール用アプリ２２２、スケジューラ用アプリ２２３等の各アプリケーションに対して共通に設定される。
【００５３】
「ＩＤ」情報は、この共通データを管理するための識別情報であり、「Ｆｒｏｍ」情報は、この共通データの送信元のアドレス情報であり、「Ｔｏ」情報は、この共通データの送信先のアドレス情報であり、「Ｄａｔｅ」情報は、共通データの作成日時を示す。「Ｐｒｉｏｒｉｔｙ」情報は、この共通データの優先度であり、「Ｌｉｍｉｔ」情報は、この共通データの有効期限を示す。「Ｌｏｏｐ」情報は、後述の繰り返し要求の有無を示し、「Ｉｎｔｅｒｖａｌ」情報（インターバル情報）は、繰り返し要求時におけるインターバル時間を示す。「Ｔｙｐｅ」情報は、この共通データが用いられるアプリケーションの種類や、この共通データの種類を示す。「Ｃａｃｈｅ」情報は、この共通データをキャッシュする必要性の有無を示す。
【００５４】
したがって、端末２のサービス機能部２２は、共通データの情報格納領域Ｒ１（の「Ｔｙｐｅ」情報）を参照することによって、この共通データを用いるアプリケーションを判別でき、対象のアプリケーションに共通データを引き渡すことができる。
【００５５】
データ本体領域Ｒ２は、端末２のサービス機能部２２に搭載している各アプリケーションが、サービス実行時に実際に用いるデータであり、データ本体領域Ｒ２を用いるアプリケーションの種類やデータの種類は、情報格納領域Ｒ１の「Ｔｙｐｅ」に示されている。このデータ本体領域Ｒ２におけるデータの記述形式は、掲示板用アプリ２２１、メール用アプリ２２２、スケジューラ用アプリ２２３等の各アプリケーションに対して共通に設定される。
【００５６】
本実施形態では、サーバ１のデータ処理サーバ部１２が、外部から入力される様々なフォーマットの情報を、共通フォーマットの共通データに変換して、データベース１４に格納している。ここで、外部から入力される様々なフォーマットの情報とは、掲示板サービスに用いる記事情報、メールサービスに用いるメール情報、スケジューラサービスに用いるスケジューラ用アプリ２２３が作成したスケジュール情報等である。これらの各情報は、集合住宅内のネットワークＮＴ１経由、インターネット等の外部ネットワーク経由で、サーバ１が受信する。
【００５７】
そして、データ処理サーバ部１２は、図３に示すアプリケーション情報Ｊ１を記憶しており、このアプリケーション情報Ｊ１に基づいて、共通データへの変換処理を行う。アプリケーション情報Ｊ１は、端末２のサービス機能部２２に搭載しているアプリケーション毎に、Ｔｙｐｅ情報、入力情報形式、変換手段の各項目が設定されている。
【００５８】
例えば、掲示板用アプリケーションは、Ｔｙｐｅ情報「ＩＤ１」、入力情報形式「ＨＴＭＬ」、変換手段「変換手法１」が設定されている。すなわち、「ＨＴＭＬ」の入力情報形式で作成された記事情報は、「変換手法１」によって共通フォーマットの掲示板用データに変換され、掲示板用データの情報格納領域Ｒ１の「Ｔｙｐｅ」情報には、「ＩＤ１」が設定される。
【００５９】
また、メール用アプリケーションは、Ｔｙｐｅ情報「ＩＤ２」、入力情報形式「ＭＢＯＸ」、変換手段「変換手法２」が設定されている。すなわち、「ＭＢＯＸ」の入力情報形式で作成されたメール情報は、「変換手法２」によって共通フォーマットのメール用データに変換され、メール用データの情報格納領域Ｒ１の「Ｔｙｐｅ」情報には、「ＩＤ２」が設定される。
【００６０】
また、スケジューラ用アプリケーションは、Ｔｙｐｅ情報「ＩＤ３」、入力情報形式「ｖＣａｌｅｎｄａｒ」、変換手段「変換手法３」が設定されている。すなわち、「ｖＣａｌｅｎｄａｒ」の入力情報形式で作成されたスケジュール情報は、「変換手法３」によって共通フォーマットのスケジューラ用データに変換され、スケジューラ用データの情報格納領域Ｒ１の「Ｔｙｐｅ」情報には、「ＩＤ３」が設定される。
【００６１】
図４は、サーバ１のデータ処理サーバ部１２によるデータ変換処理を示す動作フローチャートである。まず、データ処理サーバ部１２は、情報が入力されると（Ｓ１）、入力された情報に対応するアプリケーションタイプ（掲示板、メール、スケジューラ）を判定し（Ｓ２）、さらに共通フォーマットで作成された共通データであるか否かを判定する（Ｓ３）。入力された情報が共通データであれば、データベース１４に格納する（Ｓ５）。入力された情報が共通データでなければ、上記のようにアプリケーション情報Ｊ１に基づいて共通データへの変換処理を行った後（Ｓ４）、データベース１４に格納する（Ｓ５）。
【００６２】
そして、サーバ１のデータベース１４には、図５に示すように、情報格納領域Ｒ１とデータ本体領域Ｒ２とを対にした共通データが格納されている。
【００６３】
また、端末２のサービス機能部２２は、図６に示すアプリケーション情報Ｊ２を記憶しており、このアプリケーション情報Ｊ２に基づいて、サーバ１から取得した共通データを処理する。アプリケーション情報Ｊ２は、端末２のサービス機能部２２に搭載しているアプリケーション毎に、Ｔｙｐｅ情報、処理内容の各項目が設定されている。
【００６４】
例えば、サービス機能部２２は、Ｔｙｐｅ情報「ＩＤ１」が設定された共通データは掲示板用データであると判断して、掲示板用アプリ２２１を実行し、この掲示板用データを端末２の画面上に表示する。
【００６５】
また、サービス機能部２２は、Ｔｙｐｅ情報「ＩＤ２」が設定された共通データはメール用データであると判断して、メール用アプリ２２２を実行し、このメール用データを端末２の画面上に表示する。
【００６６】
また、サービス機能部２２は、Ｔｙｐｅ情報「ＩＤ３」が設定された共通データはスケジューラ用データであると判断して、スケジューラ用アプリ２２３を実行し、このスケジューラ用データを端末２の画面上に表示する。
【００６７】
次に、図７に示す端末２の動作フローチャート、図８に示すサーバ１の動作フローチャートを用いて、端末２によるサーバ１からの共通データ取得処理を説明する。以下、掲示板サービスを例にして説明する。
【００６８】
まず、端末２の掲示板用アプリ２２１は、端末２のユーザ操作によって、掲示板サービスのリスト要求をサーバ１へ送信する（Ｓ１１）。リスト要求には、送信元の端末２の端末ＩＤ（部屋番号）、要求するデータの「Ｔｙｐｅ」情報（この場合、ＩＤ１）が付加されている。
【００６９】
サーバ１のデータ処理サーバ部１２は、掲示板サービスのリスト要求を受信すると（Ｓ２１）、受信したリスト要求に基づいて、リスト要求の送信元である端末２の端末ＩＤを確認し（Ｓ２２）、さらに、「Ｔｙｐｅ」情報を確認する（Ｓ２３）。そして、データ管理部１３は、「Ｔｙｐｅ」情報が一致するデータ（この場合、掲示板用アプリ２２１が用いる掲示板用データ）から、リスト要求の送信元である端末２に関するデータを検索し、その情報格納領域Ｒ１のみをデータベース１４から読み出す（Ｓ２４）。データ処理サーバ部１２は、掲示板用データの情報格納領域Ｒ１のリストデータ（記事リストデータ）を端末２へ返信する（Ｓ２５）。
【００７０】
リスト要求を送信した端末２のサービス機能部２２は、リスト要求に対するサーバ１の応答（記事リストデータの返信）があるか否かを判定している（Ｓ１２）。そして、サービス機能部２２は、サーバ１から記事リストデータを取得すると（Ｓ１３）、記事リストデータを構成する情報格納領域Ｒ１に含まれる「Ｔｙｐｅ」情報に基づいて、掲示板サービス用のデータであると解釈し、掲示板用アプリ２２１を実行する（Ｓ１４）。掲示板用アプリ２２１は、掲示板用データの情報格納領域Ｒ１のリストを、端末２の画面上に表示する。
【００７１】
さらに、掲示板用アプリ２２１は、サーバ１から取得した記事リストデータを構成する情報格納領域Ｒ１の各々について、情報格納領域Ｒ１内の「Ｃａｃｈｅ」情報を参照して、リスト内の情報格納領域Ｒ１の各々をキャッシュする必要性を判定する（Ｓ１５）。そして、「Ｃａｃｈｅ」情報が必要性「有」に設定されている情報格納領域Ｒ１のみを、キャッシュ管理部２４によって、キャッシュ部２３にキャッシュする（Ｓ１６）。「Ｃａｃｈｅ」情報が必要性「無」に設定されている情報格納領域Ｒ１は、キャッシュ部２３にキャッシュされることなく、リスト表示の終了後に破棄される（Ｓ１７）。
【００７２】
また、掲示板用アプリ２２１以外のアプリケーション（メール用アプリ２２２、スケジューラ用アプリ２２３等）が用いるデータのリスト要求を端末２がサーバ１へ送信した場合も、上記同様に処理される。すなわち、端末２は、メールリストデータ、スケジュールリストデータをサーバ１から受信して、画面上に表示可能となる。
【００７３】
リストは、情報格納領域Ｒ１に含まれる各情報に基づいて表示されており、メールサービスであれば、メールの送信者、タイトル、受信日時等の情報である。掲示板サービスであれば、記事のタイトル、記事の作成者、記事の作成日時等の情報である。スケジュールサービスであれば、スケジュールのタイトル、スケジュールの作成日時等である。
【００７４】
図９は、リストデータ（記事リストデータ、メールリストデータ、スケジュールリストデータ等）を表示している端末２における処理を示す動作フローチャートである。以下、掲示板サービスを例にして説明する。
【００７５】
まず、端末２は、その画面上に、掲示板サービスの記事リストデータを表示している。そして、端末２は、画面上に表示している記事リストデータから、ユーザ操作によっていずれかの記事を選択可能に構成されており、選択待ち状態となる（Ｓ３１）。次に、記事の選択操作の有無を判定し（Ｓ３２）、記事の選択操作が発生すれば、掲示板用アプリ２２１は、掲示板サービスのデータ本体要求をサーバ１へ送信する（Ｓ３３）。すなわち、ユーザは、詳細な内容を知りたい記事を記事リストデータから選択し、この記事のデータ本体領域Ｒ２（記事データ）を取得するために、サーバ１へデータ本体要求を送信する。データ本体要求には、送信元の端末２の端末ＩＤ（部屋番号）、要求するデータの「Ｔｙｐｅ」情報（この場合、ＩＤ１）だけでなく、選択した記事に関する情報も付加されている。
【００７６】
サーバ１のデータ処理サーバ部１２は、受信したデータ本体要求に基づき、データ管理部１３によってデータベース１４から、要求対象となる掲示板用データのデータ本体領域Ｒ２を検索して読み出す。そして、データ処理サーバ部１２は、掲示板用データのデータ本体領域Ｒ２を端末２へ返信する。
【００７７】
データ本体要求を送信した端末２のサービス機能部２２は、データ本体要求に対するサーバ１の応答（記事データの返信）があるか否かを判定している（Ｓ３４）。そして、サービス機能部２２は、サーバ１から記事データを取得すると（Ｓ３５）、掲示板用アプリ２２１を実行し、取得した記事データ（掲示板用データのデータ本体領域Ｒ２）を、端末２の画面上に表示する（Ｓ３６）。
【００７８】
さらに、掲示板用アプリ２２１は、サーバ１から取得した記事データと対になる情報格納領域Ｒ１がキャッシュ部２３に格納されているか否かを判断することによって、サーバ１から取得したデータ本体領域Ｒ２をキャッシュする必要性を判定する（Ｓ３７）。サーバ１から取得した記事データと対になる情報格納領域Ｒ１がキャッシュ部２３に格納されている場合、サーバ１から取得したデータ本体領域Ｒ２を、キャッシュ管理部２４によって、キャッシュ部２３にキャッシュする（Ｓ３８）。サーバ１から取得したデータ本体領域Ｒ２と対になる情報格納領域Ｒ１がキャッシュ部２３に格納されていない場合、サーバ１から取得したデータ本体領域Ｒ２を、キャッシュ部２３にキャッシュすることなく、表示終了後に破棄する（Ｓ３９）。
【００７９】
また、掲示板用アプリ２２１以外のアプリケーション（メール用アプリ２２２、スケジューラ用アプリ２２３等）が用いるデータのデータ本体要求を端末２がサーバ１へ送信した場合も、上記同様に処理される。すなわち、端末２は、メール内容、スケジュール内容をサーバ１から受信して、画面上に表示可能となる。
【００８０】
このように、端末２がサーバ１から受信するデータの構造は共通フォーマットに統一されており、サーバ１、端末２では、複数のサービスに対して、共通のデータ構造を用いたデータ処理が可能となる。
【００８１】
したがって、複数のサービスを提供可能に構成した場合でも、サーバ１は、共通フォーマットで構成された共通データをデータベース１４に格納すればよく、データ管理部１３によるデータ検索が容易となる。また、データ処理サーバ部１２も、異なるサービスであっても、統一された共通データに対してデータ処理を行えばよいので、データ管理が容易となる。また、サービス毎のサーバ部が不要となり、サーバ１の構成を簡略化できる。
【００８２】
また、端末２においても、サーバ１から取得するデータは共通データに統一されるので、各サービスに対応するアプリケーション毎にデータのメモリ領域を確保する必要がなく、メモリリソースを有効に使用することができる。また、サービス毎のデータ管理も容易となる。
【００８３】
さらに、提供するサービスが互いに異なるアプリケーションにおいて、統一された共通データを用いるので、各アプリケーションでは同様のアルゴリズムを用いたデータ処理が可能となり、アプリケーションの作成が容易となる。
【００８４】
すなわち、本実施形態では、サーバ１および端末２でのデータ管理を簡略化できる。
【００８５】
また、共通データは、情報格納領域Ｒ１とデータ本体領域Ｒ２とで構成されており、端末２は、最初に情報格納領域Ｒ１のみをサーバ１から取得してリスト表示した後に、必要なデータ本体領域Ｒ２をサーバ１から取得することができる。したがって、情報格納領域Ｒ１とデータ本体領域Ｒ２との両方をサーバ１から一括して取得する場合に比べて、高速通信が可能となり、さらには通信路全体のデータ量も抑えることができる。また、サーバ１が全ての共通データをデータベース１４に格納しており、端末２は、必要なデータのみをキャッシュ部２３にキャッシュすればよく、端末２のメモリリソースを抑えることができる。
【００８６】
また、端末２のサービス機能部２２（アプリケーション）は、情報格納領域Ｒ１の「Ｃａｃｈｅ」情報を参照して、データをキャッシュする必要性の有無を判断している。したがって、不要なデータはキャッシュすることなく、端末２のメモリリソースをさらに抑えることができる。情報格納領域Ｒ１の「Ｃａｃｈｅ」情報は、サーバ１のデータ処理サーバ部１２が作成しており、サーバ１が端末２におけるキャッシュの要否を判断して、端末２のキャッシュ動作を制御することができる。
【００８７】
次に、情報格納領域Ｒ１およびデータ本体領域Ｒ２をキャッシュ部２３にキャッシュ済の共通データの取得処理について、図１０の動作フローチャートを用いて説明する。以下、掲示板サービスを例にして説明する。
【００８８】
まず、端末２は、その画面上に、掲示板サービスの記事リストデータを表示している。そして、端末２は、画面上に表示している記事リストデータから、ユーザ操作によっていずれかの記事を選択可能に構成されており、選択待ち状態となる（Ｓ４１）。次に、記事の選択操作の有無を判定し（Ｓ４２）、記事の選択操作が発生すれば、掲示板用アプリ２２１は、キャッシュ部２３を参照して（Ｓ４３）、選択した記事に対応するデータ本体領域Ｒ２がキャッシュ部２３にキャッシュされているか否かを判定する（Ｓ４４）。選択した記事に対応するデータ本体領域Ｒ２がキャッシュ部２３にキャッシュされている場合、該当するデータ本体領域Ｒ２をキャッシュ部２３から取得し、掲示板用アプリ２２１によって、取得した記事データ（掲示板用データのデータ本体領域Ｒ２）を、端末２の画面上に表示する（Ｓ４５）。
【００８９】
選択した記事に対応するデータ本体領域Ｒ２がキャッシュ部２３にキャッシュされていない場合、端末２は、図９のステップＳ３３以降と同様の処理を行い、サーバ１から記事データを取得して、表示する。
【００９０】
また、掲示板用アプリ２２１以外のアプリケーション（メール用アプリ２２２、スケジューラ用アプリ２２３等）が用いるデータのデータ本体要求を端末２がサーバ１へ送信した場合も、上記同様に処理される。すなわち、端末２は、メール内容、スケジュール内容の取得処理を、キャッシュ状況に応じて行うことができる。
【００９１】
このように、端末２のサービス機能部２２（アプリケーション）は、データ本体領域Ｒ２をサーバ１から取得する場合、まずキャッシュ部２３のキャッシュ状況を確認する。そして、取得するデータ本体領域Ｒ２がキャッシュされていれば、キャッシュされているデータを取得するので、処理速度を向上させることができる。また、アプリケーション毎に異なるフォーマットのデータをキャッシュすることなく、共通フォーマットの共通データをキャッシュしているので、キャッシュ部２３におけるデータの検索処理、保存処理が容易となる。
【００９２】
また、端末２のサービス機能部２２（アプリケーション）は、実行するサービスに対応するいずれかの情報格納領域Ｒ１をサーバ１から取得する場合も、まずキャッシュ部２３のキャッシュ状況を確認する。そして、取得する情報格納領域Ｒ１がキャッシュされていれば、キャッシュされているデータを取得するので、処理速度を向上させることができる。一方、取得する情報格納領域Ｒ１がキャッシュされていなければ、サーバ１から情報格納領域Ｒ１を取得する。
【００９３】
次に、共通データの情報格納領域Ｒ１に含まれる「Ｌｏｏｐ」情報、「Ｉｎｔｅｒｖａｌ」情報を用いた繰り返し要求処理について、図１１に示す動作フローチャートを用いて説明する。
【００９４】
共通データの情報格納領域Ｒ１に含まれる「Ｌｏｏｐ」情報は、繰り返し要求の有無を示し、「Ｉｎｔｅｒｖａｌ」情報は、インターバル時間を示す。そして、端末２のサービス機能部２２は、サーバ１から受信した情報格納領域Ｒ１を読み込み（Ｓ５１）、「Ｌｏｏｐ」情報に「繰り返し要求有り」が設定されている場合、以降、この情報格納領域Ｒ１と対になるデータ本体領域Ｒ２を定期的にサーバ１から取得する。
【００９５】
具体的に、端末２のサービス機能部２２は、情報格納領域Ｒ１に含まれる「Ｉｎｔｅｒｖａｌ」情報を参照して、インターバル時間を確認する（Ｓ５２）。そして、サービス機能部２２は、計時動作を開始し、計時時間がインターバル時間に達したか否かを判定する（Ｓ５３）。サービス機能部２２は、計時時間がインターバル時間に達した時点で、対応するアプリケーションを実行し、サーバ１へデータ本体要求を送信して、対応するデータ本体領域Ｒ１をサーバ１から取得して、画面上に表示する（Ｓ５４）。
【００９６】
したがって、時間の経過に伴ってサーバ１へ順次入力される情報を、端末２が定期的にサーバ１から取得することができ、簡易なサーバ側サービスを実現できる。
【００９７】
本発明では、サーバ１と端末２との間で授受されるデータを、共通フォーマットの共通データで構成しており、サーバ１および端末２においてデータ管理を容易にすることが目的である。データ構造は、図２に示す情報格納領域Ｒ１およびデータ本体領域Ｒ２において、そのデータ形式（ＸＭＬ等のテキストデータ、バイナリデータ等）は問わない。例えば、メール用データであれば、情報格納領域Ｒ１に、データ本体領域Ｒ２が用いられるメールサービスに関する情報が格納され、データ本体領域Ｒ２にメール内容が格納されていればよい。
【００９８】
また、図２に示す情報格納領域Ｒ１に含まれる各情報は一例であり、情報格納領域Ｒ１には、これらの情報のうち、共通データが用いられるアプリケーションの種類や、この共通データの種類を示す「Ｔｙｐｅ」情報が少なくとも含まれていればよい。さらに、情報格納領域Ｒ１には、図２に示されていない情報が含まれていてもよい。
【００９９】
さらに、共通データは、情報格納領域Ｒ１に情報が必ず含まれていなければならないが、データ本体領域Ｒ２における情報の有無は問わない。例えば、情報格納領域Ｒ１の「Ｔｙｐｅ」情報に特殊な情報を設定して、情報格納領域Ｒ１をコマンドとして使用する場合、データ本体領域Ｒ２に情報は格納されない。このような場合、データ本体領域Ｒ２における情報の有無を、情報格納領域Ｒ１に書き込んでもよい。
【０１００】
また、サーバ１に設けたデータベース１４の種類や記憶方法も問わない。例えば、一般的なＲＤＢＭＳ（Relational DataBase ManagementSystem）を用いてもよく、あるいは独自のデータベース構造を用いてもよい。すなわち、端末２からの要求に応じて、共通データの情報格納領域Ｒ１およびデータ本体領域Ｒ２を検索できればよい。
【０１０１】
また、サーバ１に情報を入力する方法も、その手段を問わない。例えば、メールサービスであれば、外部のプロバイダのメールサーバから、ＭＢＯＸ等の一般的なメール形式でデータを受け取った後に、共通データに変換する方法、プロバイダ独自のメール形式を用いた共通データ構造でデータを受け取る方法等がある。すなわち、外部からサーバ１に入力された情報が、最終的に、サーバ１のデータベース１４に共通データの構造で格納できればよい。
【０１０２】
また、端末２の画面上におけるデータの表示形態も問わない。例えば掲示板サービスの場合、記事リストデータの表示形態は、掲示板用アプリ２２１に依存している。すなわち、端末２は、サーバ１から取得した共通データの情報格納領域Ｒ１に含まれている各情報に基づいて、対応するアプリケーションが実行されるのであれば、データの表示方法や、アプリケーションの仕様等は問わない。
【０１０３】
また、端末２との間で共通データを授受する機器は、サーバ１に限定されることなく、例えば、端末２同士が行うチャットサービスにおいて、サーバ１を介することなく、端末２−端末２間の通信に共通データを用いてもよい。さらには、端末２が、図示しない宅内機器の監視制御サービスを行う場合も同様に、サーバ１を介することなく、端末２−宅内機器間の通信に共通データを用いてもよい。さらには、端末２が、玄関、エレベータ等に設置された図示しないインターホン機器との間でメッセージ通信を行う場合も同様に、サーバ１を介することなく、端末２−インターホン機器間の通信に共通データを用いてもよい。
【０１０４】
また、端末２のサービス機能部２２には、掲示板用アプリ２２１、メール用アプリ２２２、スケジューラ用アプリ２２３を個別に搭載している。例えば、掲示板サービスの場合、掲示板用データの表示方法があり、メールサービスの場合、メール用データの表示方法があり、スケジューラサービスの場合、スケジューラ用データの表示方法があり、それぞれのサービスに適した表示方法ある。そこで、サービス毎に適した表示機能内の検索処理、ソート処理等を実現するためには、サービス毎に個別のアプリケーションを用いたほうがよい。
【０１０５】
一方、本発明では、端末２が他の機器との間で授受するデータは、共通フォーマットの共通データで構成されているので、アプリケーションに要求される機能は、データの表示機能が主となる。そこで、端末２のサービス機能部２２には、掲示板用アプリ２２１、メール用アプリ２２２、スケジューラ用アプリ２２３等の各機能を有する１つのアプリケーションを搭載してもよい。また、掲示板サービス、メールサービス、スケジューラサービス等の各共通データを端末２において一括表示して、ユーザの選択操作によってフィルタリング処理を行う場合も、複数のサービスの各機能を有する１つのアプリケーションを搭載してもよい。
【０１０６】
また、上述の例では、端末２がサーバ１に対して要求を送信し、サーバ１が、この要求に対する返信として共通データを端末２へ送信している。しかし、サーバ１が共通データを端末２へ送信するトリガとしては、端末２からの要求以外であってもよい。例えば、サーバ１がメール用データを端末２へ送信するトリガとして、端末２からの要求を用いた場合、端末２によるメール確認が遅れてしまう虞がある。そこで、サーバ１が、外部からのメール情報の受信時、または定期的に、データベース１４に格納しているメール用データの情報格納領域Ｒ１のリスト（メールリストデータ）を、自発的に端末２へ送信してもよい。
【０１０７】
また、従来は、図１２に示すように、ユーザに提供するサービスの数だけ、サーバ５００のサーバ部（サーバ側アプリ）、および端末６００のアプリケーション（端末側アプリ）が必要であった。すなわち、新規のサービスを追加する場合には、図１２に示すように、サーバ５００に、新規のサーバ部５０４および記憶部５１４を追加し、端末６００に、新規のアプリ６０４および記憶部６１４を追加する必要があった。したがって、新規のサービスを追加することは容易ではなかった
一方、本発明において、サーバ１−端末２間で授受されるデータは、共通データに統一されているので、新規のサービスを追加する場合、サーバ部１のデータ処理サーバ部１２、端末２のサービス機能部２２に新しい機能を追加することは容易となる。
【符号の説明】
【０１０８】
１ サーバ
１１ 通信部
１２ データ処理サーバ部
１３ データ管理部
１４ データベース
２ 端末
２１ 通信部
２２ サービス機能部
２３ キャッシュ部
２４ キャッシュ管理部
ＮＴ１ ネットワーク
【特許請求の範囲】
【請求項１】
サーバと端末とが互いに通信可能に構成されて、前記端末が、前記サーバから取得したデータに基づいてユーザに複数のサービスを提供する通信システムであって、
前記サーバは、ユーザに複数の前記サービスを提供するためのアプリケーションが用いる前記データを前記端末へ送信する第１の通信部と、この第１の通信部が送信する前記データを管理するデータ処理サーバ部とを備え、
前記端末は、前記サーバから前記データを受信する第２の通信部と、１つ以上の前記アプリケーションを具備して、前記サーバから取得した前記データに基づいて前記アプリケーションを実行することによって、ユーザに前記サービスを提供するサービス機能部とを備え、
前記データは、複数の前記サービスに共通のデータフォーマットで構成され、前記データフォーマットは、複数の前記サービスに共通の形式で記述されて、前記アプリケーションが用いるデータ本体領域と、複数の前記サービスに共通の形式で記述されて、前記データ本体領域が用いられる前記サービスに関する情報を少なくとも含む情報格納領域とを含んで構成される
ことを特徴とする通信システム。
【請求項２】
前記端末の前記サービス機能部は、１または複数の前記情報格納領域を前記サーバから取得した後に、この取得した１または複数の前記情報格納領域から選択したいずれかの前記情報格納領域と対になる前記データ本体領域を前記サーバから取得することを特徴とする請求項１記載の通信システム。
【請求項３】
前記端末は、前記サービス機能部が前記サーバから取得した前記情報格納領域および前記データ本体領域をキャッシュするキャッシュ部と、このキャッシュ部への前記情報格納領域および前記データ本体領域の読み書きを行うキャッシュ管理部とを備えることを特徴とする請求項１または２記載の通信システム。
【請求項４】
前記情報格納領域は、前記キャッシュ部にキャッシュするか否かを示すフラグを含み、
前記端末の前記キャッシュ管理部は、前記サービス機能部が取得した前記情報格納領域に含まれる前記フラグに基づいて、前記サービス機能部が取得した前記サービス機能部および前記データ本体領域を前記キャッシュ部にキャッシュするか否かを判断する
ことを特徴とする請求項３記載の通信システム。
【請求項５】
前記端末の前記サービス機能部は、前記サーバから前記データを取得する場合、前記取得するデータの前記情報格納領域が前記キャッシュ部にキャッシュされていれば、この情報格納領域を前記キャッシュ部から取得し、前記取得するデータの前記情報格納領域が前記キャッシュ部にキャッシュされていなければ、この情報格納領域を前記サーバから取得し、
前記取得した１つ以上の前記情報格納領域のうち、所望の前記情報格納領域と対になる前記データ本体領域を前記サーバから取得する場合、前記取得するデータ本体領域が前記キャッシュ部にキャッシュされていれば、このデータ本体領域を前記キャッシュ部から取得し、前記取得するデータ本体領域が前記キャッシュ部にキャッシュされていなければ、このデータ本体領域を前記サーバから取得する
ことを特徴とする請求項３または４記載の通信システム。
【請求項６】
前記情報格納領域は、時間間隔を示すインターバル情報を含み、
前記端末の前記サービス機能部は、前記インターバル情報を含む前記情報格納領域を取得した場合、前記インターバル情報に基づく時間間隔毎に、前記取得した情報格納領域と対になる前記データ本体領域を前記サーバから取得する
ことを特徴とする請求項１乃至５いずれか記載の通信システム。
【請求項１】
サーバと端末とが互いに通信可能に構成されて、前記端末が、前記サーバから取得したデータに基づいてユーザに複数のサービスを提供する通信システムであって、
前記サーバは、ユーザに複数の前記サービスを提供するためのアプリケーションが用いる前記データを前記端末へ送信する第１の通信部と、この第１の通信部が送信する前記データを管理するデータ処理サーバ部とを備え、
前記端末は、前記サーバから前記データを受信する第２の通信部と、１つ以上の前記アプリケーションを具備して、前記サーバから取得した前記データに基づいて前記アプリケーションを実行することによって、ユーザに前記サービスを提供するサービス機能部とを備え、
前記データは、複数の前記サービスに共通のデータフォーマットで構成され、前記データフォーマットは、複数の前記サービスに共通の形式で記述されて、前記アプリケーションが用いるデータ本体領域と、複数の前記サービスに共通の形式で記述されて、前記データ本体領域が用いられる前記サービスに関する情報を少なくとも含む情報格納領域とを含んで構成される
ことを特徴とする通信システム。
【請求項２】
前記端末の前記サービス機能部は、１または複数の前記情報格納領域を前記サーバから取得した後に、この取得した１または複数の前記情報格納領域から選択したいずれかの前記情報格納領域と対になる前記データ本体領域を前記サーバから取得することを特徴とする請求項１記載の通信システム。
【請求項３】
前記端末は、前記サービス機能部が前記サーバから取得した前記情報格納領域および前記データ本体領域をキャッシュするキャッシュ部と、このキャッシュ部への前記情報格納領域および前記データ本体領域の読み書きを行うキャッシュ管理部とを備えることを特徴とする請求項１または２記載の通信システム。
【請求項４】
前記情報格納領域は、前記キャッシュ部にキャッシュするか否かを示すフラグを含み、
前記端末の前記キャッシュ管理部は、前記サービス機能部が取得した前記情報格納領域に含まれる前記フラグに基づいて、前記サービス機能部が取得した前記サービス機能部および前記データ本体領域を前記キャッシュ部にキャッシュするか否かを判断する
ことを特徴とする請求項３記載の通信システム。
【請求項５】
前記端末の前記サービス機能部は、前記サーバから前記データを取得する場合、前記取得するデータの前記情報格納領域が前記キャッシュ部にキャッシュされていれば、この情報格納領域を前記キャッシュ部から取得し、前記取得するデータの前記情報格納領域が前記キャッシュ部にキャッシュされていなければ、この情報格納領域を前記サーバから取得し、
前記取得した１つ以上の前記情報格納領域のうち、所望の前記情報格納領域と対になる前記データ本体領域を前記サーバから取得する場合、前記取得するデータ本体領域が前記キャッシュ部にキャッシュされていれば、このデータ本体領域を前記キャッシュ部から取得し、前記取得するデータ本体領域が前記キャッシュ部にキャッシュされていなければ、このデータ本体領域を前記サーバから取得する
ことを特徴とする請求項３または４記載の通信システム。
【請求項６】
前記情報格納領域は、時間間隔を示すインターバル情報を含み、
前記端末の前記サービス機能部は、前記インターバル情報を含む前記情報格納領域を取得した場合、前記インターバル情報に基づく時間間隔毎に、前記取得した情報格納領域と対になる前記データ本体領域を前記サーバから取得する
ことを特徴とする請求項１乃至５いずれか記載の通信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１２−９３８２６（Ｐ２０１２−９３８２６Ａ）
【公開日】平成２４年５月１７日（２０１２．５．１７）
【国際特許分類】
【出願番号】特願２０１０−２３８４１４（Ｐ２０１０−２３８４１４）
【出願日】平成２２年１０月２５日（２０１０．１０．２５）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２４年５月１７日（２０１２．５．１７）
【国際特許分類】
【出願日】平成２２年１０月２５日（２０１０．１０．２５）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]