(57)【要約】【課題】　いずれの種類の携帯電話からも開閉体開閉状態の確認及び鍵の施解錠の遠隔操作を行えるようにする。【解決手段】　複数種類の携帯電話９と開閉体管理装置５との間に設置する開閉体管理用サーバ３が、携帯電話の機種の識別手段と、各種の携帯電話が備える機能に見合う最適な形式の情報を提供する手段とを備え、各種携帯電話９の指示に基づき開閉体管理装置５を管理する。さらに、開閉体管理装置５を介する鍵１３の処理結果を、コンテンツ記述言語ファイル１５の形式で携帯電話９へ送信する。この構成により、いずれの種類の携帯電話からも開閉体開閉状態の確認及び鍵の施解錠の遠隔操作を行うことができる。【選択図】　　　　　図１
2004088774.tif 000002
【特許請求の範囲】
【請求項１】
　複数種類の携帯電話とコンピュータネットワークを介してインタラクティブに通信可能に構成してある開閉体の開閉状態を管理するための開閉体管理サーバと、当該開閉体管理サーバからコンピュータネットワークを介して管理可能に構成してある開閉体管理装置と、を含み、
　当該開閉体管理サーバが、接続された携帯電話毎のキャリア及び機種を少なくとも識別する識別手段、および、
　当該携帯電話から送信されたＩＤと予め登録されたＩＤとの一致又は不一致を判別する判別手段、および、
　当該判別手段の判別によってＩＤが一致した携帯電話の要求に基づき、当該開閉体が鍵を備える場合は当該鍵の施解錠の有無、及び／又は、当該開閉体の開閉に関する情報信号の送信を当該開閉体管理装置に要求し、当該開閉体管理装置から送信された情報信号を、当該識別手段の識別結果に基づいて解読可能とするコンテンツ記述言語として生成し当該ＩＤが一致した携帯電話に送信する生成手段、を有している
　ことを特徴とする開閉体管理システム。
【請求項２】
　前記識別手段が、携帯電話から前記開閉体管理サーバへの接続要求時に、当該携帯電話から送信されるヘッダ情報により当該携帯電話のキャリア及び機種情報を取得し、当該機種情報に基づきキャリア及び機種の識別を行うように構成してある
　ことを特徴とする請求項１に記載した開閉体管理システム。
【請求項３】
　前記開閉体管理装置が、前記開閉体が鍵を備える場合に前記開閉体管理サーバを介した前記ＩＤが一致した携帯電話からの要求に基づき当該鍵を施解錠可能に構成してある
　ことを特徴とする請求項１又は２に記載した開閉体管理システム。
【請求項４】
　コンピュータネットワークを介して複数種類の携帯電話とインタラクティブに通信可能に構成してあり、かつコンピュータネットワークを介して開閉体管理装置を管理可能に構成してある開閉体の開閉状態を管理するための開閉体管理サーバであって、
　接続された携帯電話毎のキャリア及び機種を少なくとも識別する識別手段、および、
　当該携帯電話から送信されたＩＤと予め登録されたＩＤとの一致又は不一致を判別する判別手段、および、
　当該判別手段の判別によってＩＤが一致した携帯電話の要求に基づき、当該開閉体が鍵を備える場合は当該鍵の施解錠の有無、及び／又は、当該開閉体の開閉に関する情報信号の送信を当該開閉体管理装置に要求し、当該開閉体管理装置から送信された情報信号を、当該識別手段の識別結果に基づいて解読可能なコンテンツ記述言語として生成し当該ＩＤが一致した携帯電話に送信する生成手段、を有する
　ことを特徴とする開閉体管理サーバ。
【請求項５】
　前記識別手段が、携帯電話から前記開閉体管理サーバへの接続要求時に、当該携帯電話から送信されるヘッダ情報により当該携帯電話のキャリア及び機種情報を取得し、当該機種情報に基づきキャリア及び機種の識別を行うように構成してある
　ことを特徴とする請求項４に記載した開閉体管理サーバ。
【請求項６】
　前記生成手段が、さらに前記識別された携帯電話のキャリア及び機種に対応する画面表示情報又はセキュリティ機能に関する情報に基づくコンテンツ記述言語を作成し、前記ＩＤが一致した携帯電話が前記識別手段の識別結果に基づいて解読可能とする形式で送信する機能を有する
　ことを特徴とする請求項４又は５に記載した開閉体管理サーバ。
【請求項７】
　前記開閉体管理装置が、前記開閉体が鍵を備える場合に前記ＩＤが一致した携帯電話からの要求に基づき当該鍵を施解錠可能に構成してある
　ことを特徴とする請求項４乃至６何れかに記載した開閉体管理サーバ。
【請求項８】
　コンピュータネットワークを介して開閉体管理装置を管理可能に構成してある開閉体の開閉を管理するための開閉体管理サーバと、当該開閉体管理サーバとコンピュータネットワークを介してインタラクティブに通信可能に構成してある携帯電話とを接続し、
　当該開閉体管理サーバが、接続された携帯電話のキャリア及び機種を少なくとも識別し、
　当該携帯電話から送信されたＩＤと予め登録されたＩＤとの一致又は不一致を判別し、
当該判別によってＩＤが一致した携帯電話の要求に基づき、当該開閉体が鍵を備える場合に当該鍵の施解錠の有無、及び／又は、当該開閉体の開閉に関する情報信号の送信を当該開閉体管理装置に要求し、当該開閉体管理装置から送信された情報信号を、当該識別結果に基づいて解読可能とするコンテンツ記述言語として生成し当該ＩＤが一致した携帯電話に送信する
　ことを特徴とする開閉体管理方法。
【請求項９】
　前記開閉体が鍵を備える場合に前記ＩＤが一致した携帯電話からの要求に基づき当該鍵を施解錠可能に構成してある
　ことを特徴とする請求項８に記載した開閉体管理方法。
【請求項１０】
　携帯電話からの要求を受けた開閉体管理サーバが、コンピュータネットワークを介して管理可能に構成された開閉体管理装置を通じ、開閉体の開閉状態を管理するための開閉体管理プログラムを含む記憶媒体であって、
　接続された携帯電話毎のキャリア及び機種を少なくとも識別する識別機能、および、
　当該携帯電話から送信されたＩＤと予め登録されたＩＤとの一致又は不一致を判別する判別機能、および、
　当該ＩＤが一致した携帯電話の要求に基づき、当該開閉体が鍵を備える場合は当該鍵の施解錠の有無、及び／又は、当該開閉体の開閉に関する情報信号の送信を当該開閉体管理装置に要求し、当該開閉体管理装置から送信された情報信号を、当該識別機能の識別結果に基づいて解読可能なコンテンツ記述言語として生成し当該ＩＤが一致した携帯電話に送信する生成機能、を有する
　ことを特徴とする開閉体管理プログラムを含む記憶媒体。
【請求項１１】
　前記開閉体が鍵を備える場合に前記ＩＤが一致した携帯電話からの要求に基づき当該鍵を施解錠可能とする機能を有している
　ことを特徴とする請求項１０に記載した開閉体管理プログラムを含む記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
　この発明は、住宅、工場その他の建造物のドアや金庫、トランク、ロッカー、机の引出し、その他の開閉可能な物品収納物などに代表される開閉体の開閉状態の管理、及び、そのような開閉体が鍵を備える場合における鍵の施解錠を携帯電話により遠隔操作で行う際に、携帯電話の機種、機能の違いを補うことにより、より確実かつ簡単な遠隔操作を行えるようにするための開閉体管理システム、開閉体管理サーバ、開閉体管理方法及び開閉体管理プログラムを含む記憶媒体に関するものである。なお、本明細書における「携帯電話」とは、ＰＨＳその他の移動体通信装置を含む概念である。
【背景技術】
【０００２】
　特許文献１には、ＮＴＴＤｏＣｏＭｏ（商標）の携帯電話であるｉモード（商標）とインターネットとを利用して、家庭内機器等の遠隔監視と遠隔操作とを行う技術が開示されている。その一例として、ｉモード携帯電話からインターネットを介して、ドアの開閉状態を監視したり、自宅のドアの鍵を施解錠したりする管理システムが開示されている。この技術は、インターネットにアクセス可能な携帯電話であるｉモード携帯電話からの指令により、ＷｅｂサーバがＷｅｂ端末機に接続された駆動装置を管理して、ドアの開閉状態を管理したりドアの鍵を施解錠できるようにするためのものである。また、Ｗｅｂサーバに接続されたＷｅｂ端末機は、鍵の施解錠やドアの開閉状態を検知するセンサを備えており、当該センサから得た情報を、Ｗｅｂサーバを介してｉモード携帯電話に送信するものである。
【特許文献１】特開２００１−３０９０６７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
　しかしながら、携帯電話を用いてドアの開閉状態や鍵の施解錠を管理しようとすると、次に述べる問題が生じた。すなわち、一言に「携帯電話」といっても、キャリア（たとえば、ＮＴＴＤｏＣｏＭｏ，ＫＤＤＩ，Ｊ−Ｐｈｏｎｅ　何れも商標）の違いや、携帯電話の製造メーカー（たとえば、ＳＯＮＹ，Ｐａｎａｓｏｎｉｃ，ＮＥＣ，Ｆｕｊｉｔｓｕ　何れも商標）の違いがある。さらに、同じ製造メーカーの携帯電話であっても、型番（世代）により機能が異なっている。何れの「携帯電話」も電話の基本機能である「通話」機能は持っているが、たとえば「Ｅメールの送受信」や「画像の送受信」のできる機種とできない機種とが混在している。そして今後も新たな機能を持った機種の販売が予想されるが、その一方で複雑な操作を避けるためにシンプルな機能だけを持つ機種の販売も求められており、機能の違いは広がるばかりである。
【０００４】
　このような機能の違いがある限り、キャリアや製造メーカーの違い、さらには型番の違いを無視してドアの開閉状態や鍵の施解錠を管理することは極めて難しい。このことを「画像表示」を例にして説明する。上記したように携帯電話の機種によっては画像表示できるものであっても、カラー表示できるものと白黒表示しかできないものとがある。カラー表示すれば見やすい映像であっても、白黒表示するとコントラストの関係から見誤りやすくなってしまうことは誰もが経験する。また、現行の画像デジタル情報形式にはＪＰＧ，ＧＩＦ，ＢＭＰなど数十種類あるため、形式が違うために同じ画像であっても、その画像を表示できる携帯電話とできない携帯電話が出てくる。
【０００５】
　ドアの開閉状態や鍵の施解錠を遠隔管理したいと考える者は、持っている携帯電話が遠隔管理に適するものである場合はよいが、そうでない場合はそれに適する新たな携帯電話を買わなければならない。携帯電話が格納するプログラムを修正する方法もあるが、１台１台の携帯電話のプログラムを修正することは時間的費用的に難しい。本発明が解決しようとする課題は、上記した事情を改善することにある。つまり、キャリア、製造メーカー、型番等の違いがある各種の携帯電話に対して、情報伝達形式の整合をとってそれぞれの携帯電話が備える機能に見合った最適な形式の情報を提供することにより、いずれの種類の携帯電話からもドアの開閉状態や鍵の施解錠の遠隔管理を行えるようにするための管理システム、管理サーバ、管理方法及び管理プログラムを含む記憶媒体の提供が、本発明の目的である。
【課題を解決するための手段】
【０００６】
　本発明の発明者らは、各種の携帯電話が使用する情報伝達形式を整合するための手段を、携帯電話と鍵の開閉体管理装置との間に設けることにより上記目的の達成を図った。その詳しい内容については、項を改めて説明する。
【０００７】
　（請求項１に記載した発明の特徴）
　請求項１に記載した発明に係る開閉体管理システムは、複数種類の携帯電話とコンピュータネットワークを介してインタラクティブに通信可能に構成してある開閉体の開閉状態を管理するための開閉体管理サーバと、当該開閉体管理サーバからコンピュータネットワークを介して管理可能に構成してある開閉体管理装置と、を含み、当該開閉体管理サーバが、接続された携帯電話毎のキャリア及び機種を少なくとも識別する識別手段、および、当該携帯電話から送信されたＩＤと予め登録されたＩＤとの一致又は不一致を判別する判別手段、および、当該判別手段の判別によってＩＤが一致した携帯電話の要求に基づき、当該開閉体が鍵を備える場合は当該鍵の施解錠の有無、及び／又は、当該開閉体の開閉に関する情報信号の送信を当該開閉体管理装置に要求し、当該開閉体管理装置から送信された情報信号を、当該識別手段の識別結果に基づいて解読可能とするコンテンツ記述言語として生成し当該ＩＤが一致した携帯電話に送信する生成手段、を有している。
【０００８】
　（請求項２に記載した発明の特徴）
　請求項２に記載した発明に係る開閉体管理システムは、請求項１に係る開閉体管理システムであって、前記識別手段が、携帯電話から前記開閉体管理サーバへの接続要求時に、当該携帯電話から送信されるヘッダ情報により当該携帯電話のキャリア及び機種情報を取得し、当該機種情報に基づきキャリア及び機種の識別を行うように構成してある。
【０００９】
　（請求項３に記載した発明の特徴）
　請求項３に記載した発明に係る開閉体管理システムは、請求項１又は２に係る開閉体管理システムであって、前記開閉体管理装置が、前記開閉体が鍵を備える場合に前記開閉体管理サーバを介した前記ＩＤが一致した携帯電話からの要求に基づき当該鍵を施解錠可能に構成してある。
【００１０】
　（請求項４に記載した発明の特徴）
　請求項４に記載した発明に係る開閉体管理サーバは、コンピュータネットワークを介して複数種類の携帯電話とインタラクティブに通信可能に構成してあり、かつコンピュータネットワークを介して開閉体管理装置を管理可能に構成してある開閉体の開閉状態を管理するための開閉体管理サーバであって、接続された携帯電話毎のキャリア及び機種を少なくとも識別する識別手段、および、当該携帯電話から送信されたＩＤと予め登録されたＩＤとの一致又は不一致を判別する判別手段、および、当該判別手段の判別によってＩＤが一致した携帯電話の要求に基づき、当該開閉体が鍵を備える場合は当該鍵の施解錠の有無、及び／又は、当該開閉体の開閉に関する情報信号の送信を当該開閉体管理装置に要求し、当該開閉体管理装置から送信された情報信号を、当該識別手段の識別結果に基づいて解読可能なコンテンツ記述言語として生成し当該ＩＤが一致した携帯電話に送信する生成手段、を有している。
【００１１】
　（請求項５に記載した発明の特徴）
　請求項５に記載した発明に係る開閉体管理サーバは、請求項４に係る開閉体管理サーバであって、前記識別手段が、携帯電話から前記開閉体管理サーバへの接続要求時に、当該携帯電話から送信されるヘッダ情報により当該携帯電話のキャリア及び機種情報を取得し、当該機種情報に基づきキャリア及び機種の識別を行うように構成してある。
【００１２】
　（請求項６に記載した発明の特徴）
　請求項６に記載した発明に係る開閉体管理サーバは、請求項４又は５に係る開閉体管理サーバであって、前記生成手段が、さらに前記識別された携帯電話のキャリア及び機種に対応する画面表示情報又はセキュリティ機能に関する情報に基づくコンテンツ記述言語を作成し、前記ＩＤが一致した携帯電話が前記識別手段の識別結果に基づいて解読可能とする形式で送信する機能を有している。
【００１３】
　（請求項７に記載した発明の特徴）
　請求項７に記載した発明に係る開閉体管理サーバは、請求項４乃至６の何れかに係る開閉体管理サーバであって、前記開閉体管理装置が、前記開閉体が鍵を備える場合に前記ＩＤが一致した携帯電話からの要求に基づき当該鍵を施解錠可能に構成してある。
【００１４】
　（請求項８に記載した発明の特徴）
　請求項８に記載した発明に係る開閉体管理方法は、コンピュータネットワークを介して開閉体管理装置を管理可能に構成してある開閉体の開閉を管理するための開閉体管理サーバと、当該開閉体管理サーバとコンピュータネットワークを介してインタラクティブに通信可能に構成してある携帯電話とを接続し、当該開閉体管理サーバが、接続された携帯電話のキャリア及び機種を少なくとも識別し、当該携帯電話から送信されたＩＤと予め登録されたＩＤとの一致又は不一致を判別し、当該判別によってＩＤが一致した携帯電話の要求に基づき、当該開閉体が鍵を備える場合に当該鍵の施解錠の有無、及び／又は、当該開閉体の開閉に関する情報信号の送信を当該開閉体管理装置に要求し、当該開閉体管理装置から送信された情報信号を、当該識別結果に基づいて解読可能とするコンテンツ記述言語として生成し当該ＩＤが一致した携帯電話に送信することを特徴とする。
【００１５】
　（請求項９に記載した発明の特徴）
　請求項９に記載した発明に係る開閉体管理方法は、請求項８に係る開閉体管理方法であって、前記開閉体が鍵を備える場合に前記ＩＤが一致した携帯電話からの要求に基づき当該鍵を施解錠可能に構成してあることを特徴とする。
【００１６】
　（請求項１０に記載した発明の特徴）
　請求項１０に記載した発明に係る開閉体管理プログラムを含む記憶媒体は、携帯電話からの要求を受けた開閉体管理サーバが、コンピュータネットワークを介して管理可能に構成された開閉体管理装置を通じ、開閉体の開閉状態を管理するための開閉体管理プログラムを含む記憶媒体であって、接続された携帯電話毎のキャリア及び機種を少なくとも識別する識別機能、および、当該携帯電話から送信されたＩＤと予め登録されたＩＤとの一致又は不一致を判別する判別機能、および、当該ＩＤが一致した携帯電話の要求に基づき、当該開閉体が鍵を備える場合は当該鍵の施解錠の有無、及び／又は、当該開閉体の開閉に関する情報信号の送信を当該開閉体管理装置に要求し、当該開閉体管理装置から送信された情報信号を、当該識別機能の識別結果に基づいて解読可能なコンテンツ記述言語として生成し当該ＩＤが一致した携帯電話に送信する生成機能、を有することを特徴とする。
【００１７】
　（請求項１１に記載した発明の特徴）
　請求項１１に記載した発明に係る開閉体管理プログラムを含む記憶媒体は、請求項１０に係る開閉体管理プログラムを含む記憶媒体であって、前記開閉体が鍵を備える場合に前記ＩＤが一致した携帯電話からの要求に基づき当該鍵を施解錠可能とする機能を有していることを特徴とする。
【発明の効果】
【００１８】
　本発明によれば、開閉体管理サーバを、各種の携帯電話と開閉体管理装置との間に設け、当該開閉体管理サーバが、携帯電話の機種の識別手段と、各種の携帯電話が備える機能に見合う最適な形式の情報を提供する手段とを備えることによって、開閉体の開閉状況及び／又は鍵の施解錠の遠隔操作に適さない携帯電話の場合に、それに適する新たな携帯電話を購入するか、又は携帯電話が格納するプログラムを１台１台修正しなければならない、という問題を解消することができ、いずれの種類の携帯電話からも開閉体の開閉状況及び必要に応じて鍵の施解錠の遠隔操作を行うことが可能となる。
【発明を実施するための最良の形態】
【００１９】
　次に、各図を参照しながら、本発明の実施の形態について説明する。図１に示すのは、開閉体管理システム（以下、単に「管理システム」という）の概略全体図である。図２に示すのは、携帯電話のキャリアと機種の識別及びコンテンツ記述言語の生成を実現するための動作フローである。図３に示すのは、アクセスしてきたユーザーの認証を行うための動作フローである。図４に示すのは、携帯電話からの操作要求を開閉体管理サーバが開閉体管理装置を介して実現するための動作フローである。図５に示すのは、遠隔操作による開閉体の開閉状態及び鍵の施解錠の管理を行うための、携帯電話と開閉体管理サーバとの間の処理手順を示すフローチャートである。図６に示すのは、メインページの操作メニュー画面と操作処理結果を表示する画面とを表す図である。
【００２０】
　（開閉体管理システムの概略構成）
　図１に基づいて、開閉体管理システムの概略構成について説明する。開閉体管理システム１（以下、適宜「管理システム１」という）は、開閉体管理サーバ３（以下、適宜「管理サーバ３」という）と、開閉体管理装置５（以下、適宜「管理装置５」という）と、を備えている。管理サーバ３は、コンピュータネットワークの一例であるインターネット７を介して管理装置５を管理できるように構成してある。管理サーバ３は、ＣＧＩへのリンク１６を含むコンテンツ記述言語ファイル１５と、各種ＣＧＩプログラム１７と、データベース１９と、を備えている。管理システム１は、さらに複数種類の携帯電話９（９ａ，９ｂ，９ｃ，...９ｎ）を含み、これらの携帯電話９ａ，９ｂ，９ｃ，...９ｎは、それぞれが持つ通信網１１（１１ａ，１１ｂ，１１ｃ，...１１ｎ）を介して管理サーバ３とインタラクティブ（双方向通信可能）に接続できるように構成してある。管理装置５は、住宅、工場その他の建造物のドアや金庫、トランク、ロッカー、机の引出し、その他の開閉可能な物品収納物などに代表される開閉体の開閉状態の管理（たとえば、開閉状態の確認、鍵が設けられているときの当該鍵の施解錠の操作）を行うための装置であって、携帯電話９の指示に基づき管理サーバ３により管理できるように構成してある。なお、本実施形態におけるドア（開閉体）には鍵１３が設けてあり、鍵１３の施解錠は、管理サーバ３の指令に基づいて管理装置５が有するソレノイドの駆動により行われるようになっている。つまり、管理装置５が、鍵１３に設けられているコイルに電流を流して電磁石を生じさせ、この電磁石の吸引力や反発力とバネのエネルギーとを組み合わせて可動コイルに機械的な直線運動を行わせる。この運動を利用することによって、鍵１３の施解錠が行われる。また、コンテンツ記述言語ファイル１５の記述言語は、複数種類の携帯電話９（９ａ，９ｂ，９ｃ，...９ｎ）の属すキャリア（たとえば、ＮＴＴＤｏＣｏＭｏ，Ｊ−Ｐｈｏｎｅ，ＫＤＤＩ　何れも商標）の違いに応じてＣＨＴＭＬ（Ｃｏｍｐａｃｔ　Ｈｙｐｅｒ　Ｔｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ），ＭＭＬ（Ｍｏｂｉｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ），ＨＤＭＬ（Ｈａｎｄｈｅｌｄ　Ｄｅｖｉｃｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）など複数種類用意してある。これらの記述言語は、いずれもＨＴＭＬ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）を基礎にして各キャリアが独自仕様を加えて携帯端末用に開発したものである。また、複数種類の携帯電話９（９ａ，９ｂ，９ｃ，...９ｎ）は、携帯端末用のブラウザを備えておりインターネットに通信可能である。各携帯電話９ａ，９ｂ，９ｃ，...９ｎは、説明の都合上それぞれが異なる機種であって、それぞれのキャリアが採用する通信方式等を利用して別々のユーザーにより操作されるものとする。
【００２１】
　データベース１９は、各ユーザーの携帯番号及び機種と、各ユーザーを識別するための識別情報（ＩＤ、パスワード等）とを関連付けて格納したユーザー管理テーブルＴ１と、複数種類の携帯電話についてそのメーカー名や機種名等の情報及び機能情報を格納した携帯電話情報テーブルＴ２と、によって構成されている。ユーザー管理テーブルＴ１のデータは、管理サーバ３の管理者の作業により登録・更新されたり、携帯電話やはがき等を通したユーザーの申込等により登録・更新できるようにしてある。また、これらのデータのすべてを格納しておく必要は必ずしもなく、少なくとも識別情報、携帯電話の機種及び携帯電話番号のデータがあればよい。また、携帯電話情報テーブルＴ２における機能情報の差異（セキュリティ機能の有無、コンテンツ記述言語や画像形式の違い等）は、たとえば、キャリア（たとえば、ＮＴＴＤｏＣｏＭｏ，ＫＤＤＩ，Ｊ−Ｐｈｏｎｅ　何れも商標）の違いや、携帯電話の製造メーカー（たとえば、ＳＯＮＹ，Ｐａｎａｓｏｎｉｃ，ＮＥＣ，Ｆｕｊｉｔｓｕ　何れも商標）の違いによって生じてくる。さらに、同じ製造メーカーであっても、携帯電話の型番の違いによっても機能情報の差異は生じてくる。なお、データベース１９は、上記実施例のように管理サーバ３に内蔵されている必要は必ずしもない。データベース機能を担うデータベース専用サーバを別途設けて、管理サーバ３との連携によって処理を行わせてもよい。
【００２２】
　ＣＧＩとは、Ｃｏｍｍｏｎ　Ｇａｔｅｗａｙ　Ｉｎｔｅｒｆａｃｅの略で、ブラウザからの要求を受けつけたＷｅｂサーバが、対応するプログラムを起動し、当該プログラムの実行結果をブラウザに返すための仕組みである。管理サーバ３は、携帯電話９からＣＧＩへのリンク１６を介してなされる起動要求に応じて、各種ＣＧＩプログラム１７を起動させて対応処理２１を行う。各種ＣＧＩプログラム１７の詳しい構成については次項以下で述べる。なお、管理サーバ３において起動するプログラムは、ＣＧＩプログラム１７以外に、例えばサーバサイドスクリプティングであってもよい。サーバサイドスクリプティングとは、Ｗｅｂサーバが備えるコンテンツ記述言語ファイルの中に、ＣＧＩ機能を直接組み込んでしまう技術である。さらには、開閉又は施解錠の管理を可能にするプログラムそのものを、管理サーバ３が備えるＯＳ（オペレーティングシステム）にあらかじめ実装しておいてもよい。さらには、管理プログラムをアプリケーションソフトとして保有しておき、必要な時にインストールするか若しくは管理サーバ３内に標準装備しておいてもよい。また、管理サーバ３において起動する各種プログラムは、コンピュータ内のハードディスク上にファイルとして保存するか又はメモリに一時的に蓄積しておくか又は符号２２に示すようなＣＤ−ＲＯＭ若しくはＤＶＤ又はＭＯ若しくはフロッピー（登録商標）ディスク等の外部の記憶媒体に保存しておくことができる。
【００２３】
　（管理サーバの機能）
　次に図２乃至図４に基づいて、図１に示した管理サーバ３に設けられている各種ＣＧＩプログラム１７の動作原理の詳細について説明する。管理サーバ３を設置する第１の目的は、キャリア、製造メーカー、型番等の違いがある各種の携帯電話９ａ，９ｂ，９ｃ，...９ｎに対して、情報伝達形式の整合をとってそれぞれの携帯電話が備える機能に見合った最適な形式の情報を提供することにある。第２の目的は、いずれの種類の携帯電話からもドアの開閉状態及び鍵の施解錠の遠隔操作を可能にすることにある。そして管理サーバ３が上記目的を達成するためのＣＧＩプログラム１７には、図２に示すキャリア及び機種の識別とコンテンツ記述言語ファイルの生成を行う手段２３と、図３に示すユーザー認証手段２７と、図４に示す管理装置の管理及び操作処理結果の表示を行う開閉体管理手段３３と、がある。次項以下で各々のＣＧＩの働きについて順を追って説明していく。
【００２４】
　（識別及びコンテンツ記述言語ファイル生成）
　図２に示すのは、管理サーバ３がアクセスしてきた携帯電話９ａ，９ｂ，９ｃ，...９ｎのキャリア及び機種を識別し、当該携帯電話に見合ったコンテンツ記述言語ファイルを生成する手段（以下、「識別及び生成手段」という）２３を実現するためのＣＧＩの動作フローである。例えばアクセスしてきたのが携帯電話９ａであるとすると、手順としては、最初に、携帯電話９ａのキャリアと当該キャリアに対応するコンテンツ記述言語を識別する。次に、携帯電話９ａの機種情報に基づいて当該機種のコンテンツ記述言語及び機能情報を確認する。そして、各々の機種に対応するコンテンツ記述言語を設定した後、当該機種の個々の機能情報を格納したファイルの保管場所を指定するパス名を、生成中のコンテンツ記述言語ファイルに逐次書き込んでいく。キャリアに関しては、今後、更なる多様化や複数キャリアの統廃合が行われる可能性は多いにありうるが、本実施形態では、現行の通信会社（ＮＴＴＤｏＣｏＭｏ，Ｊ−Ｐｈｏｎｅ，ＫＤＤＩ　何れも商標）が提供するｉモード，Ｊ−ｓｋｙ，Ｅｚｗｅｂ（何れも商標）の３つを識別するように設定してある。機能情報に関しては、多岐にわたるものであるし、将来は情報の種類や量も増加することが予想されるが、本実施形態では、コンテンツ記述言語の種類と、表示画面の配色と、枠線表示の有無と、画像形式の種類と、を識別するように設定してある。
【００２５】
　ステップ２０１において、携帯電話９ａが内蔵の携帯端末用ブラウザを用いて、管理サーバ３のＵＲＬに基づくＷｅｂ情報の提供を要求する。これに応じて、管理サーバ３側のＣＧＩプログラムであるｃｒｅａｔｅＨＴＭＬ．ｃｇｉ２５が起動を開始する。まず、ステップ２０３で、アクセスしてきた携帯電話９ａのキャリア及び機種に関する情報を引数として取得する。当該キャリア及び機種に関する情報は、管理サーバ３へアクセスする際に携帯電話９ａから送信される要求メッセージの中の要求ヘッダから読み取ることができる。ステップ２０５では、ステップ２０３で得た引数を基に、当該引数に対応するキャリアのコンテンツ記述言語を識別する。まず、ステップ２０７で、ｉモードであるかを判断し、ｉモードである場合は、ステップ２０９で、コンテンツ記述言語としてＣＨＴＭＬを使用するよう設定する。ｉモードでない場合は、ステップ２１１で、Ｊ−ｓｋｙであるかを判断する。Ｊ−ｓｋｙである場合は、ステップ２１３で、コンテンツ記述言語としてＭＭＬを使用するよう設定する。Ｊ−ｓｋｙでない場合は、ステップ２１５で、ＥｚＷｅｂであると判断し、ステップ２１７で、コンテンツ記述言語としてＨＤＭＬを使用するよう設定する。
【００２６】
　コンテンツ記述言語を設定した後、各機種に対応する機能情報の識別を行う。ステップ２１９では、画面表示配色の識別を行う。まず、ステップ２２１で、カラー表示であるかを判断する。カラー表示である場合は、ステップ２２３で、カラー表示用のファイルを格納した保管場所を指定するパス名を生成中のコンテンツ記述言語ファイルに記述する。その後、生成後のコンテンツ記述言語ファイルが携帯電話９ａに転送され、携帯端末用ブラウザが解析し、当該パスに含まれるファイルの転送要求を行う。そして、転送されたファイルを再度携帯端末用ブラウザが解析することで、携帯電話９ａの表示画面がカラー表示となる。また、カラー表示でない場合は、ステップ２２５で、モノクロ表示用ファイルを格納した保管場所を指定するパス名を生成中のコンテンツ記述言語ファイルに記述する。その後携帯電話９ａの表示画面がモノクロ表示されるまでの過程は、カラー表示の場合と同様である。
【００２７】
　次に、ステップ２２７で、枠線表示か否かを識別する。まず、ステップ２２９で、枠線表示が可能であるかを判断する。枠線表示可能である場合は、ステップ２３１で、枠線表示用ファイルを格納した保管場所を指定するパス名を生成中のコンテンツ記述言語ファイルに記述する。その後、生成後のコンテンツ記述言語ファイルが携帯電話９ａに転送され、携帯端末用ブラウザが解析し、当該パスに含まれるファイルの転送要求を行う。そして、転送されたファイルを再度携帯端末用ブラウザが解析することで、携帯電話９ａの表示画面に枠線が表示される。枠線表示が可能でない場合、ステップ２３３で、枠線非表示用ファイルを格納した保管場所を指定するパス名を生成中のコンテンツ記述言語ファイルに記述する。その後携帯電話９ａの表示画面上で枠線非表示の画面が表示されるまでの過程は、枠線表示の場合と同様である。
【００２８】
　次に、ステップ２３５で、画像表示形式を識別する。まず、ステップ２３７で、画像表示形式がＢＭＰ形式であるかを判断する。ＢＭＰ形式である場合、ステップ２３９で、ＢＭＰ形式ファイルを格納した保管場所を指定するパス名を生成中のコンテンツ記述言語ファイルに記述する。その後、生成後のコンテンツ記述言語ファイルが携帯電話９ａに転送され、携帯端末用ブラウザが解析し、当該パスに含まれるファイルの転送要求を行う。そして、転送されたファイルを再度携帯端末用ブラウザが解析して、画像表示形式がＢＭＰ形式に設定される。ＢＭＰ形式でない場合、ステップ２４１で、ＪＰＥＧ形式であるか判断する。ＪＰＥＧ形式である場合、ステップ２４３で、ＪＰＥＧ形式ファイルを格納した保管場所を指定するパス名を生成中のコンテンツ記述言語ファイルに記述する。ＪＰＥＧ形式でない場合、ステップ２４５で、ＧＩＦ形式であると判断し、ＧＩＦ形式ファイルを格納した保管場所を指定するパス名を生成中のコンテンツ記述言語ファイルに記述する。その後携帯電話９ａの画像表示形式が、ＪＰＥＧ形式又はＧＩＦ形式に設定されるまでの過程は、ＢＭＰ形式の場合と同様である。
【００２９】
　ステップ２４９で、前記コンテンツ記述言語及び機能情報の識別と、その後のパスの設定を全て行うことで、コンテンツ記述言語ファイルの生成が完了する。その結果、ステップ２５１で、アクセスしてきた携帯電話９ａのキャリア及び機種に見合った最適な形式のトップページを表示させることが可能となる。なお、本実施例において生成するファイルのコンテンツ記述言語はＨＴＭＬであるが、識別及び生成手段２３において生成されるファイルのコンテンツ記述言語は、ＨＴＭＬの他に、ＸＨＴＭＬ（ｅＸｔｅｎｓｉｂｌｅ　Ｈｙｐｅｒ　Ｔｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）やＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）であってもよい。
【００３０】
　（ユーザー認証手段）
　図３に示すのは、管理サーバ３にアクセスしてきた携帯電話９ａの認証を行うユーザー認証手段２７を実現するためのＣＧＩの動作フローである。これは、アクセスしてきた携帯電話９ａが、予め登録されたユーザーにより操作されているかどうかを確認するためのものである。具体的には、当該ユーザーでなければ知り得ないＩＤとパスワードの入力を促し、これをユーザー管理テーブルＴ１に格納してある当該ユーザーのＩＤとパスワードとの比較の結果、一致であると判定することにより、携帯電話９ａの認証を行うようにしてある。まず、ステップ３０１で、ユーザーがトップページのＥＮＴＥＲボタン、若しくはメインページへのリンク表示部分をクリックする。すると、ステップ３０３で、携帯端末用ブラウザが標準で備えるＩＤとパスワードの入力画面が表示され、ステップ３０５で、当該ユーザーがＩＤとパスワードを入力する。そして、当該ユーザーの入力したＩＤとパスワードの情報が管理サーバ３に送信された時点で、ｃｈｅｃｋ．ｃｇｉ２９の起動要求が管理サーバ３に対してなされる。ｃｈｅｃｋ．ｃｇｉ２９は、ステップ３０７で、引数としてＩＤ及びパスワードを取得し、ステップ３０９で、データベース１９が備えるユーザー管理テーブルＴ１に格納してあるＩＤ及びパスワードとの比較を行う。ステップ３１１で、比較の結果、ＩＤ及びパスワードが一致した場合、ｃｒｅａｔｅＨＴＭＬ．ｃｇｉ３１が起動し、図２で示した識別及び生成手段２３によってコンテンツ記述言語を生成する。そして、ステップ３１３で、メインページを作成して当該ＩＤ及びパスワードが一致した携帯電話９ａに送信する。他方、当該ユーザーが入力したＩＤ及びパスワードと、データベース１９に登録してあるＩＤ及びパスワードと、が不一致であった場合には、ステップ３１５で、認証失敗を示すコンテンツ記述言語を生成して携帯電話９ａに送信する。
【００３１】
　（ドア管理手段）
　次に、図４及び図６に基づき、携帯電話９ａの指示で管理サーバ３が管理装置５を管理する開閉体管理手段３３（以下、適宜「管理手段３３」という）について説明する。管理サーバ３と管理装置５とはインターネット７を介して接続されており、インターネット７における通信には、ＴＣＰ／ＩＰが用いられている。なお、ＴＣＰ／ＩＰにおいて通信管理を担うトランスポート層のプロトコルには、ＴＣＰが用いられているが、ＵＤＰを用いてもよい。ＵＤＰには、ＴＣＰと異なりパケットが正常に送信されているかを確認する機能がない。その分信頼性に欠けるが、手続が簡略化されている分効率のよい通信が実現できる。また、ファイル転送やメッセージ通信など、ユーザー相互間で実行する多くのサービスを管理するアプリケーション層には、独自のプロトコルを設定している。当該プロトコルは、管理サーバ３と管理装置５との間で、ドアの開閉状態とともに施錠や解錠等の各々の操作に対応する電気信号の種類を予め特定しておくことで、それぞれの電気信号に応じた処理を互いに行うことを可能にするものである。
【００３２】
　図４に示すのは、管理手段３３を実現するためのＣＧＩの動作フローである。図６に示すのは、操作処理要求項目をユーザーが選択するための操作メニュー画面と、各々の操作要求に対応する処理を行った結果を表示する画面とを表す図である。まず、ユーザーが、図６のメインメニュー４５にある４つのメニュー（施錠確認４７，ドア確認４９，施錠５１，解錠５３）の中からいずれかの操作項目を選択する（ステップ４０１）。操作項目の選択が行われると、操作処理．ｃｇｉ３５が起動し、ステップ４０３で、引数としてユーザーが選択した操作要求項目を取得する。ステップ４０５で、選択された操作要求項目が、図６の符号４７に示す施錠確認である場合、ステップ４０７で、操作処理．ｃｇｉ３５が管理装置５に操作処理の要求を行う。ステップ４０９では、管理装置５が、操作処理．ｃｇｉ３５からの操作処理要求項目を解析する。ステップ４１１で、操作処理要求項目が施錠確認４７であることを確認した後、ステップ４１３で、現在施錠中かどうかを確認し、確認後の結果を管理サーバ３に送信する。結果を受信した管理サーバ３は、ステップ４１５で、処理結果を一時的に格納しておく。そして、ステップ４１７で、施錠中であれば、図６の符号５７に示すような表示画面を、解錠中であれば、符号５９に示すような表示画面を結果ＨＴＭＬファイルとして生成し、携帯電話９ａに送信する。なお、本実施例において生成するファイルのコンテンツ記述言語はＨＴＭＬであるが、管理手段３３において生成されるファイルのコンテンツ記述言語は、ＨＴＭＬの他に、ＸＨＴＭＬやＸＭＬであってもよい。
【００３３】
　次に、ステップ４１９で、操作要求項目が、図６の符号４９に示すドア確認である場合、ステップ４２１で、操作処理．ｃｇｉ３５が管理装置５に操作処理の要求を行う。ステップ４２３では、管理装置５が、操作処理．ｃｇｉ３５からの操作処理要求項目を解析する。ステップ４２５で、ドア確認４９であることを確認した後、ステップ４２７で、現在ドアが開いているかどうかを確認し、確認後の結果を管理サーバ３に送信する。結果を受信した管理サーバ３は、ステップ４２９で、処理結果を一時的に格納しておく。そして、ステップ４３１で、ドアが開いていれば、図６の符号６１に示すような表示画面を、ドアが閉まっていれば、符号６３に示すような表示画面を結果ＨＴＭＬファイルとして生成し、携帯電話９ａに送信する。
【００３４】
　次に、ステップ４３３で、操作要求項目が、図６の符号５１に示す施錠である場合、ステップ４３５で、操作処理．ｃｇｉ３５が管理装置５に操作処理の要求を行う。ステップ４３７では、管理装置５が、操作処理．ｃｇｉ３５からの操作処理要求項目を解析する。ステップ４３９で、施錠５１であることを確認した後、ステップ４４１で、鍵１３が開いているかを確認する。鍵１３が開いていれば、ステップ４４３で、施錠処理を行う。そして、施錠処理を行った場合はその結果を、又は鍵１３が開いていなければその結果を管理サーバ３に送信する。結果を受信した管理サーバ３は、ステップ４４５で、処理結果を一時的に格納しておく。そして、ステップ４４７で、施錠処理が完了すれば、符号６５に示すような表示画面を結果ＨＴＭＬファイルとして生成し、携帯電話９ａに送信する。
【００３５】
　次に、ステップ４４８で、操作要求項目が、図６の符号５３に示す解錠である場合、ステップ４４９で、操作処理．ｃｇｉ３５が管理装置５に操作処理の要求を行う。ステップ４５１では、管理装置５が、操作処理．ｃｇｉ３５からの操作処理要求項目を解析する。ステップ４５３で、解錠５３であることを確認した後、ステップ４５５で、鍵１３が閉まっているかを確認する。鍵１３が閉まっていれば、ステップ４５７で、解錠処理を行う。そして、解錠処理を行った場合はその結果を、又は鍵１３が閉まっていなければその結果を管理サーバ３に送信する。結果を受信した管理サーバ３は、ステップ４５９で、処理結果を一時的に格納しておく。そして、ステップ４６１で、解錠処理が完了すれば、符号６７に示すような表示画面を結果ＨＴＭＬファイルとして生成し、携帯電話９ａに送信する。なお、図６に示す、メニュー６９をクリックすれば、もとのメインメニューを表示する画面に戻る。
【００３６】
　最後に、図５に基づいて、本発明の方法に係る鍵１３の施解錠の遠隔操作を行うための処理をフローチャートによって説明する。ステップ５０１で、アクセスしてきた携帯電話３７から開閉体管理サーバ３９（以下、適宜「管理サーバ３９」という）へトップページのＵＲＬに基づくＷｅｂ情報の転送要求がなされる。それとともに、ステップ５０３で、携帯電話３７から管理サーバ３９へ、ＨＴＴＰのヘッダ情報として、キャリア及び機種に関する情報が送信される。ステップ５０５で、取得した携帯電話３７のキャリア及び機種情報に基づき、管理サーバ３９がコンテンツ記述言語ファイルを生成する。その結果、ステップ５０７で、アクセスしてきた携帯電話３７のキャリア及び機種に最適な形式のトップページを作成し、ステップ５０９で、携帯電話３７に送信する。次に、ステップ５１１で、アクセスしている携帯電話３７のユーザーが、表示されているトップページのＥＮＴＥＲをクリックする。すると、ステップ５１３で、携帯端末用ブラウザに標準に設けられているＩＤとパスワード入力画面が表示され、ユーザーが自身のＩＤとパスワードとを入力する。ステップ５１５では、管理サーバ３９にメインページの送信を要求するとともに、ステップ５１７で、入力したＩＤとパスワードとを管理サーバ３９に引き渡す。ステップ５１９では、管理サーバ３９がデータベース４１に予め登録されている当該ユーザーのＩＤ及びパスワードと、引き渡されたＩＤ及びパスワードとを比較する。一致すれば、ステップ５２３で、コンテンツ記述言語を生成し、ステップ５２５で、アクセスしてきた携帯電話３７のキャリア及び機種に最適な形式のメインページを作成する。そして、ステップ５２７で、携帯電話３７に送信する。携帯電話３７は、ステップ５２９で、メインページにあるメインメニューの中から操作項目を選択し、ステップ５３１で、選択した操作項目の処理を行うリクエストを管理サーバ３９に送信する。ステップ５３３では、携帯電話３７の指示に基づき、管理サーバ３９から管理装置４３へ操作処理のリクエストを行う。ステップ５３５では、管理装置４３から管理サーバ３９へ、操作処理の実行結果が送信される。次に、ステップ５３７で、管理サーバ３９は、送信された実行結果に基づいてコンテンツ記述言語を生成する。そして、ステップ５３９で、実行結果を表示するコンテンツ記述言語ファイルを携帯電話３７に送信する。
【００３７】
　上記説明は、ドアに鍵１３が設けてあることを前提に行ったが、鍵１３が設けてない場合や設けてあるが常に解錠してあるため管理不要の場合には施解錠プログラムは必要がない。たとえば、会社がある建物の入口に鍵のあるドアがあるが、建物内部にある各ドアには鍵を設けていないか設けてあるが常に解錠状態にしてある場合に、建物内部のドアについてだけいえば、施解錠プログラムは不要となる。また、使用者の意図に応じて、鍵の施解錠を管理せずにドアの開閉のみを管理するようにすることもできる。しかし、ドアの設置環境にもよるが、ドアの開閉状態とともに鍵の施解錠を管理することにより、より好ましいセキュリティ環境の構築に貢献することができる。たとえば、ドアが閉鎖状態で鍵が解錠状態であることは鍵を施錠すれば対処可能な問題であるが、ドアが開放状態なのに鍵が施錠状態にあるときは管理者の注意が必要である。すなわち、鍵を解錠してドアを開放するはずであるのに対し、鍵が施錠されたままドアが開放状態であるときは、何らかの理由によりドアがこじあけられた可能性が高いといえる。そのような場合は、そのドアにアクセス可能な知人や、場合によっては警察に連絡をとる必要がある。その結果、セキュリティが確保される。
【図面の簡単な説明】
【００３８】
【図１】開閉体管理システムの概略全体図である。
【図２】携帯電話のキャリアと機種の識別及びコンテンツ記述言語の生成を実現するための動作フローである。
【図３】アクセスしてきたユーザーの認証を行うための動作フローである。
【図４】携帯電話からの操作要求を開閉体管理サーバが開閉体管理装置を介して実現するための動作フローである。
【図５】遠隔操作による開閉体の開閉状態及び鍵の施解錠の管理を行うための、携帯電話／開閉体管理サーバ間の処理を示すフローチャートである。
【図６】メインページの操作メニュー画面と操作結果を表示する画面とを表す図である。
【符号の説明】
【００３９】
　　　　１　　　開閉体管理システム
　　　　３　　　開閉体管理サーバ
　　　　５　　　開閉体管理装置
　　　　７　　　インターネット
　　　　９　　　複数種類の携帯電話
　　　１１　　　通信網
　　　１３　　　鍵
　　　１５　　　コンテンツ記述言語ファイル
　　　１６　　　ＣＧＩへのリンク
　　　１７　　　各種ＣＧＩプログラム
　　　１９　　　データベース
　　　２１　　　対応処理
　　　２２　　　外部記憶媒体
　　　Ｔ１　　　ユーザー管理テーブル
　　　Ｔ２　　　携帯電話情報テーブル
　　　２３　　　識別及び生成手段
　　　２５　　　ｃｒｅａｔｅＨＴＭＬ．ｃｇｉ
　　　２７　　　ユーザー認証手段
　　　２９　　　ｃｈｅｃｋ．ｃｇｉ
　　　３１　　　ｃｒｅａｔｅＨＴＭＬ．ｃｇｉ
　　　３３　　　開閉体管理手段
　　　３５　　　操作処理．ｃｇｉ
　　　３７　　　携帯電話
　　　３９　　　開閉体管理サーバ
　　　４１　　　データベース
　　　４３　　　開閉体管理装置
　　　４５　　　メインメニュー
　　　４７　　　施錠確認
　　　４９　　　ドア確認
　　　５１　　　施錠
　　　５３　　　解錠
　　　５５　　　操作処理実行結果
　　　５７　　　施錠確認画面
　　　５９　　　施錠確認画面
　　　６１　　　ドア確認画面
　　　６３　　　ドア確認画面
　　　６５　　　施錠画面
　　　６７　　　解錠画面
　　　６９　　　メニュー
【図１】
2004088774.tif 000003
【図２】
2004088774.tif 000004
【図３】
2004088774.tif 000005
【図４】
2004088774.tif 000006
【図５】
2004088774.tif 000007
【図６】
2004088774.tif 000008