図面 (/)
課題・解決手段
モバイルデバイスとの通信を確立し、モバイルデバイスからのユーザIDを受信し、複数のデバイスに関するデバイスIDをモバイルデバイスへ提供し、ユーザIDおよびデバイスIDをデバイスマネージャサーバへ提供するように構成されたプロバイダサーバと、ユーザIDおよびデバイスIDを受信し、データベース内でそれらを関連付け、デバイスIDと関連するモバイルデバイスへデバイスIDを提供するように構成されたデバイスマネージャサーバと、プロバイダサーバと関連するアプリケーションおよび短距離通信インタフェースを備え、短距離通信インタフェースを介して複数のデバイスIDを受信し、受信したデバイスIDを、デバイスマネージャから受信したデバイスIDとともに提供し、デバイスIDが一致する場合、デバイスIDと関連するデバイスと自動的にペアリングし、デバイスからのデータの受信を開始するように構成されたモバイルデバイスとを備えるシステム。
概要
背景
mHealth(m−healthとも書き表し、接続型ヘルスとも称される)は、モバイルヘルスの省略形であり、モバイルデバイスによってサポートされた医学および公衆衛生の業務に関して用いられる用語である。この用語は、最も一般的には、健康サービス、情報、およびデータ収集のために、たとえばモバイルフォン、タブレットコンピュータおよびPDA、およびスマートウォッチなどの装着型デバイスなどのモバイル通信デバイスを用いることに関して用いられる。mHealth分野は、たとえばコンピュータ、モバイルフォン、通信衛星、患者用モニタなどの情報および通信技術(ICT)を健康サービスおよび情報のために使用することである、eHealthおよびデジタルヘルスの副分野として出現した。mHealthアプリケーションは、地域および臨床健康データの収集、開業医、調査員、および患者への健康管理情報の配信、患者のバイタルサインのリアルタイム監視、および(モバイル遠隔医療を介した)治療の直接提供におけるモバイルデバイスの使用を含む。
mHealth空間において、(特に僻地の住民に関する)健康管理および健康関連情報へのアクセスの増加、疾患を診断および追跡するための能力の改善、より時を得た、実行可能性の高い公衆衛生情報、および保健従業員のための現在実施中の医学教育および訓練へのアクセスの拡大を含む様々な目的でプロジェクトが動作する。分析会社によると、2012年の終わりには、世界中で約280万人の患者が、統合接続性を有する機器に基づいて家庭用監視サービスを使用していた。この数字は、PCまたはモバイルフォンに接続された監視デバイスを使用する患者を含んでいない。この数字は、統合接続性を有するモニタに依拠するシステムまたは統合セルラまたは固定線モデムを有する監視ハブを用いるシステムのみを含むが、成長するmhealth分野は、たとえば体重計、血圧測定用カフ、血糖値測定器、活動トラッカ、およびPC、ラップトップ、またはスマートフォンやタブレットなどのモバイルデバイスとの単距離無線接続性を有する任意のデバイスといった遠隔監視デバイスとインタフェース接続することを伴う。
今日、700万人以上の患者が、遠隔監視、および自身の治療ルーティンの不可欠な部分として接続型医療デバイスの使用から恩恵を得ていると、ベルグインサイト社の新たな見積書は示している。提供者および患者がmHealthツールの利便性を迅速に取り入れたため、遠隔監視の使用は、2016年に44パーセント増加した。遠隔監視の使用は、47.9パーセントの年平均成長率(CAGR)で成長し続け、2021年までに5020万人に到達すると予想される。
遠隔監視デバイスとインタフェース接続するために、たとえばスマートフォンを用いる能力は、そのようなデバイスの採用を大幅に増加させ得る可能性があり、さらに大きな割合でmHealth空間を成長させる触媒となり得る。現在、上述したように、多くのデバイスは、モバイルデバイスまたはPCとインタフェース接続することがない。むしろ、従来のデバイスは、一般にハブとインタフェース接続し、ハブがその後、遠隔バックエンドシステムとインタフェース接続するか、あるいは、デバイス自体が、自身をバックエンドとインタフェース接続することを可能にするセルラ機能を含む。これらのシステムのインテグレータは、ハブおよびデバイスを完全に制御し、全てのデバイスを容易に識別してそれらをペアリングし得る。
そのような従来のシステムに伴う問題は、インテグレータが全てのデバイスを完全に制御する必要があること、およびハブの使用が追加の月額セルラ料金を発生させることである。多くの使用事例は、ハブがデバイスに接続するための月額セルラ料金である追加の費用をサポートすることができない。
遠隔監視デバイスをスマートフォンとインタフェース接続することにより、患者/消費者は、自身の携帯電話を用い、ハブまたは余分なセルラ線にかかる費用を削減することができる。しかし、従来のデバイスに伴う問題は、セットアップおよびモバイルデバイスとのペアリングが困難であり得るという点である。多くの場合、各デバイスは、異なる製造会社から得られ、デバイスを異なる製造会社に登録し、その後、デバイスのペアリングを試みることを必要とするが、これは、独自の特定のペアリングプロトコルまたは手順を有し得る。ユーザが多数のデバイスを有する場合、この問題は増す。その結果、そのようなデバイスに関する使用プロトコルの使用における採用および関心、およびそれらの固守が制限される。
概要
モバイルデバイスとの通信を確立し、モバイルデバイスからのユーザIDを受信し、複数のデバイスに関するデバイスIDをモバイルデバイスへ提供し、ユーザIDおよびデバイスIDをデバイスマネージャサーバへ提供するように構成されたプロバイダサーバと、ユーザIDおよびデバイスIDを受信し、データベース内でそれらを関連付け、デバイスIDと関連するモバイルデバイスへデバイスIDを提供するように構成されたデバイスマネージャサーバと、プロバイダサーバと関連するアプリケーションおよび短距離通信インタフェースを備え、短距離通信インタフェースを介して複数のデバイスIDを受信し、受信したデバイスIDを、デバイスマネージャから受信したデバイスIDとともに提供し、デバイスIDが一致する場合、デバイスIDと関連するデバイスと自動的にペアリングし、デバイスからのデータの受信を開始するように構成されたモバイルデバイスとを備えるシステム。
目的
mHealth分野は、たとえばコンピュータ、モバイルフォン、通信衛星、患者用モニタなどの情報および通信技術(ICT)を健康サービスおよび情報のために使用することである
効果
実績
- 技術文献被引用数
- 0件
- 牽制数
- 0件
この技術が所属する分野
(分野番号表示ON)※整理標準化データをもとに当社作成
請求項1
モバイルデバイスとの通信を確立し、前記モバイルデバイスからのユーザIDを受信し、前記ユーザIDおよび複数のデバイスIDをデバイスマネージャサーバへ提供するように構成されたプロバイダサーバと、前記ユーザIDおよび前記複数のデバイスIDを受信し、データベース内でそれらを関連付け、前記デバイスIDと関連する前記モバイルデバイスへ前記複数のデバイスIDを提供するように構成されたデバイスマネージャサーバと、前記プロバイダサーバと関連するアプリケーションおよび短距離通信インタフェースを備えるモバイルデバイスであって、前記短距離通信インタフェースを介して複数のデバイスIDを受信し、前記受信したデバイスIDと、デバイスマネージャから受信したデバイスIDとを比較し、前記デバイスIDが一致する場合、前記デバイスIDと関連するデバイスと自動的にペアリングし、前記デバイスからのデータの受信を開始するように構成されたモバイルデバイスとを備えるシステム。
請求項2
請求項3
前記複数のデバイスIDの各々は、MACアドレスを含む、請求項1に記載のシステム。
請求項4
前記モバイルデバイスは、ユーザによるいかなる追加のセットアップまたはアクションも伴わず、自身がペアリングされた前記デバイスの少なくとも1つからの前記短距離通信インタフェースを介した測定値の受信を開始する、請求項1に記載のシステム。
請求項5
前記モバイルデバイスはディスプレイを更に備え、前記アプリケーションは、前記受信した測定値を前記ディスプレイに出力させる、請求項4に記載のシステム。
請求項6
前記モバイルデバイスは更に、前記測定値データを前記プロバイダサーバへ提供するように構成される、請求項1に記載のシステム。
請求項7
アプリケーションと、撮像デバイスと、短距離通信インタフェースとを備えるモバイルデバイスであって、前記撮像デバイスを介して1または複数のデバイスに関するデバイスID情報を受信し、前記短距離通信インタフェースを介して1または複数のデバイスIDを受信し、前記短距離通信インタフェースを介して受信した前記デバイスIDと、前記撮像デバイスを介して受信したデバイスIDとを比較し、前記デバイスIDが一致する場合、前記デバイスIDと関連するデバイスを自動的にペアリングし、前記デバイスからのデータの受信を開始するように構成されたモバイルデバイス。
請求項8
前記1または複数のデバイスは、体重計、血圧測定用カフ、血糖値測定器、および活動トラッカの少なくとも1つを備える、請求項7に記載のシステム。
請求項9
前記1または複数のデバイスIDの各々は、MACアドレスを含む、請求項7に記載のシステム。
請求項10
前記モバイルデバイスは、ユーザによるいかなる追加のセットアップまたはアクションも伴わず、自身がペアリングされた前記1または複数のデバイスからの前記短距離通信インタフェースを介した測定値の受信を開始する、請求項7に記載のシステム。
請求項11
前記モバイルデバイスはディスプレイを更に備え、前記アプリケーションは、前記受信した測定値を前記ディスプレイに出力させる、請求項10に記載のシステム。
請求項12
前記モバイルデバイスは更に、前記測定値データをプロバイダサーバへ提供するように構成される、請求項7に記載のシステム。
請求項13
前記アプリケーションは、前記プロバイダサーバと関連する、請求項12に記載のシステム。
技術分野
背景技術
0002
mHealth(m−healthとも書き表し、接続型ヘルスとも称される)は、モバイルヘルスの省略形であり、モバイルデバイスによってサポートされた医学および公衆衛生の業務に関して用いられる用語である。この用語は、最も一般的には、健康サービス、情報、およびデータ収集のために、たとえばモバイルフォン、タブレットコンピュータおよびPDA、およびスマートウォッチなどの装着型デバイスなどのモバイル通信デバイスを用いることに関して用いられる。mHealth分野は、たとえばコンピュータ、モバイルフォン、通信衛星、患者用モニタなどの情報および通信技術(ICT)を健康サービスおよび情報のために使用することである、eHealthおよびデジタルヘルスの副分野として出現した。mHealthアプリケーションは、地域および臨床健康データの収集、開業医、調査員、および患者への健康管理情報の配信、患者のバイタルサインのリアルタイム監視、および(モバイル遠隔医療を介した)治療の直接提供におけるモバイルデバイスの使用を含む。
0003
mHealth空間において、(特に僻地の住民に関する)健康管理および健康関連情報へのアクセスの増加、疾患を診断および追跡するための能力の改善、より時を得た、実行可能性の高い公衆衛生情報、および保健従業員のための現在実施中の医学教育および訓練へのアクセスの拡大を含む様々な目的でプロジェクトが動作する。分析会社によると、2012年の終わりには、世界中で約280万人の患者が、統合接続性を有する機器に基づいて家庭用監視サービスを使用していた。この数字は、PCまたはモバイルフォンに接続された監視デバイスを使用する患者を含んでいない。この数字は、統合接続性を有するモニタに依拠するシステムまたは統合セルラまたは固定線モデムを有する監視ハブを用いるシステムのみを含むが、成長するmhealth分野は、たとえば体重計、血圧測定用カフ、血糖値測定器、活動トラッカ、およびPC、ラップトップ、またはスマートフォンやタブレットなどのモバイルデバイスとの単距離無線接続性を有する任意のデバイスといった遠隔監視デバイスとインタフェース接続することを伴う。
0004
今日、700万人以上の患者が、遠隔監視、および自身の治療ルーティンの不可欠な部分として接続型医療デバイスの使用から恩恵を得ていると、ベルグインサイト社の新たな見積書は示している。提供者および患者がmHealthツールの利便性を迅速に取り入れたため、遠隔監視の使用は、2016年に44パーセント増加した。遠隔監視の使用は、47.9パーセントの年平均成長率(CAGR)で成長し続け、2021年までに5020万人に到達すると予想される。
0005
遠隔監視デバイスとインタフェース接続するために、たとえばスマートフォンを用いる能力は、そのようなデバイスの採用を大幅に増加させ得る可能性があり、さらに大きな割合でmHealth空間を成長させる触媒となり得る。現在、上述したように、多くのデバイスは、モバイルデバイスまたはPCとインタフェース接続することがない。むしろ、従来のデバイスは、一般にハブとインタフェース接続し、ハブがその後、遠隔バックエンドシステムとインタフェース接続するか、あるいは、デバイス自体が、自身をバックエンドとインタフェース接続することを可能にするセルラ機能を含む。これらのシステムのインテグレータは、ハブおよびデバイスを完全に制御し、全てのデバイスを容易に識別してそれらをペアリングし得る。
0006
そのような従来のシステムに伴う問題は、インテグレータが全てのデバイスを完全に制御する必要があること、およびハブの使用が追加の月額セルラ料金を発生させることである。多くの使用事例は、ハブがデバイスに接続するための月額セルラ料金である追加の費用をサポートすることができない。
0007
遠隔監視デバイスをスマートフォンとインタフェース接続することにより、患者/消費者は、自身の携帯電話を用い、ハブまたは余分なセルラ線にかかる費用を削減することができる。しかし、従来のデバイスに伴う問題は、セットアップおよびモバイルデバイスとのペアリングが困難であり得るという点である。多くの場合、各デバイスは、異なる製造会社から得られ、デバイスを異なる製造会社に登録し、その後、デバイスのペアリングを試みることを必要とするが、これは、独自の特定のペアリングプロトコルまたは手順を有し得る。ユーザが多数のデバイスを有する場合、この問題は増す。その結果、そのようなデバイスに関する使用プロトコルの使用における採用および関心、およびそれらの固守が制限される。
発明が解決しようとする課題
0008
本明細書において、多数の遠隔監視デバイスをモバイルデバイスと自動的にペアリングするためのシステムおよび方法が説明される。
課題を解決するための手段
0009
一態様によると、モバイルデバイスとの通信を確立し、モバイルデバイスからのユーザIDを受信し、複数のデバイスに関するデバイスIDをモバイルデバイスへ提供し、ユーザIDおよびデバイスIDをデバイスマネージャサーバへ提供するように構成されたプロバイダサーバと、ユーザIDおよびデバイスIDを受信し、データベース内でそれらを関連付け、デバイスIDと関連するモバイルデバイスへデバイスIDを提供するように構成されたデバイスマネージャサーバと、プロバイダサーバと関連するアプリケーションおよび短距離通信インタフェースを備え、短距離通信インタフェースを介して複数のデバイスIDを受信し、受信したデバイスIDを、デバイスマネージャから受信したデバイスIDとともに提供し、デバイスIDが一致する場合、デバイスIDと関連するデバイスと自動的にペアリングし、デバイスからのデータの受信を開始するように構成されたモバイルデバイスとを備えるシステム。
0010
他の態様によると、アプリケーションと、撮像デバイスと、短距離通信インタフェースとを備え、撮像デバイスを介して1または複数のデバイスに関するデバイスID情報を受信し、短距離通信インタフェースを介して1または複数のデバイスIDを受信し、短距離通信インタフェースを介して受信したデバイスIDと、撮像デバイスを介して受信したデバイスIDとを比較し、デバイスIDが一致する場合、デバイスIDと関連するデバイスと自動的にペアリングし、デバイスからのデータの受信を開始するように構成されたモバイルデバイス。
0011
上記および他の特徴、態様、および実施形態は、「発明を実施するための形態」と題されたセクションにおいて後述する。
0012
特徴、態様、および実施形態は、添付図面と関連して説明される。
図面の簡単な説明
0013
一実施形態に係る、デバイスの自動ペアリングのためのシステム例を示す図である。
他の実施形態例に係る、図1のシステムにおいて、または図1のシステムを実現するために用いられ得る有線または無線処理システム例を示す図である。
実施例
0014
図1は、多数のデバイスの自動ペアリングを可能にする遠隔監視システム100を示す図である。システム100において、プロバイダ102は、多数の種類の健康またはウェルネス情報を収集し監視するために、多数のデバイス104を自身のモバイルデバイス112とインタフェース接続しようとしているユーザに多数のデバイス104を提供する。留意すべき点として、デバイス104は、健康またはウェルネス監視デバイスでなくてはならない。本明細書で説明されるシステムおよび方法は、他の種類の遠隔デバイスに等しく適用可能である。
0015
システム100において、様々なエンティティまたは関係者は、様々な有線または無線通信ネットワークおよび機能を備え得るネットワーク114を介して通信することができる。図1の実施形態において、システム100は、モバイルデバイス112のユーザにサービスを提供し、またはモバイルデバイス112のユーザを管理するエンティティであるプロバイダ102を備える。デバイスマネージャ106は、後述するように、デバイス104とモバイルデバイス112との関係性を管理する。
0016
システム100において、プロバイダシステム/サーバ102と関連するプロバイダは、モバイルデバイス112のユーザにデバイス104を提供しようとしている。デバイス104は、デバイスマネージャシステム/サーバ106と関連するデバイスマネージャまたは第三者から得られ得る。ユーザは最初に、プロバイダ102と関連するアプリケーション113をダウンロードし、アプリケーション113のセットアップまたは登録において、アプリケーション113は、ネットワーク114を介して確立された通信リンク116を介して、モバイルデバイス112と関連するユーザIDを提供する。
0017
プロバイダ102はその後、ユーザへ送信しようとしているデバイス104の各々に関するデバイスIDを取得してよい。デバイスID(複数も可)は、各デバイスに関するMACアドレスを備えてよい。たとえば各デバイス104は、デバイスIDを取得するためにスキャンまたは他の方法で撮像され得る、あるいは手動で入力され得るバーコードまたはQRコードを含むラベル111を備えてよい。ユーザIDおよび関連デバイスIDはその後、ネットワーク114を介して確立された通信リンク118を介してデバイスマネージャ106へ送信され、ここで、データベース(複数も可)108に、例えばテーブル(複数も可)110に格納され得る。
0019
デバイスマネージャ106はその後、ネットワーク114を介して確立された通信リンク120を介して、モバイルデバイス112およびアプリケーション113へデバイスIDを送信する。アプリケーション113はこの時点で、自身がインタフェース接続しようとしているデバイスに関するデバイスIDを有する。
0020
ユーザがデバイス104を受け取ると、ユーザは、たとえばWiFi、Bluetoothなど、使用されるどんなインタフェース機構が可能であるかを確かめ、その後、アプリケーション113を起動することができる。すなわち、モバイルデバイス112およびデバイス104は多くの場合、他のデバイスとインタフェース接続するために用いられ得る短距離通信インタフェースを有する。デバイス104がモバイルデバイス112と接続すると、アプリケーション113は、デバイスIDを認識し、自動的にペアリングし、受信を開始し、および実施形態に依存して、デバイス104から受信したデータの表示を開始する。ユーザは、デバイス104をモバイルデバイス112およびアプリケーション113とペアリングするために、特に何かをする必要はない。
0021
当然、ユーザは、デバイスを最初にセットアップし、測定を行ってデータを提供するためにそれらを設置する必要があり得る。たとえばユーザは、デバイスがプラグインされ、またはバッテリが取り付けられ、デバイスがオン状態になったことを確認する必要があり得る。加えて、ユーザは通常、デバイスがデータを集めるためにデバイスと対話し、デバイスを装着、設置するなどの必要がある。たとえばユーザは、血圧測定用カフを身に着けて作動させる、または体重計の上に乗るなどの必要があり得る。
0022
ペアリングされて情報/データを受信すると、アプリケーション113は、情報をデバイス112に格納し、格納および分析のために情報をプロバイダ102または他の何らかのバックエンドへ送信してよい。これにより、多数のデバイスからのデータの統合が大幅に容易になり得る。いうまでもなく、たとえばデバイス112などのモバイルデバイスが遠隔監視デバイス104とペアリングする方法を改善することによって、はるかに多くの採用および支持が得られる。
0023
より消費者直結型の実施形態において、デバイス112のユーザは単に、たとえば既製のデバイス104を購入し、その後、デバイスIDを取得するために、デバイス112に含まれたスキャナまたはカメラを用いて画像ラベル111をスキャンまたは撮像してよい。デバイスIDはその後、上述したように自動ペアリングおよび情報/データ収集を可能にするために、アプリケーション113へ提供され得る。
0024
図2は、本明細書で説明される様々な実施形態と関連して用いられ得る有線または無線システム例550を示すブロック図である。たとえばシステム550は、図1に関して上述したように、システム100として、またはシステム100とともに用いられ得る。システム550は、従来のパーソナルコンピュータ、コンピュータサーバ、パーソナルデジタルアシスタント、スマートフォン、タブレットコンピュータ、車両ナビゲーションおよび/または制御システム、または有線または無線データ通信機能を持つ他の任意のプロセッサ対応デバイスであってよい。当業者には明らかであるように、他のコンピュータシステムおよび/またはアーキテクチャが用いられてもよい。
0025
システム550は好適には、たとえばプロセッサ560などの1または複数のプロセッサを含む。たとえば入力/出力を管理するための補助プロセッサ、浮動小数点数学演算を行うための補助プロセッサ、信号処理アルゴリズムの高速実行に適したアーキテクチャを有する専用マイクロプロセッサ(たとえばデジタル信号プロセッサ)、主要処理システムに従属するスレーブプロセッサ(たとえばバックエンドプロセッサ)、二重または多重プロセッサシステムのための追加のマイクロプロセッサまたはコントローラ、またはコプロセッサなどの追加のプロセッサが提供され得る。そのような補助プロセッサは、個別プロセッサであってよく、あるいはプロセッサ560と統合され得る。
0026
プロセッサ560は好適には、通信バス555に接続される。通信バス555は、システム550のストレージと他の周辺機器との間の情報伝達を容易にするためのデータチャネルを含んでよい。通信バス555は更に、データバス、アドレスバス、および制御バス(不図示)を含む、プロセッサ560との通信のために用いられる信号のセットを提供してよい。通信バス555は、たとえば業界標準アーキテクチャ(「ISA」)、拡張業界標準アーキテクチャ(「EISA」)、マイクロチャネルアーキテクチャ(「MCA」)、周辺機器相互接続(「PCI」)ローカルバス、またはIEEE488汎用インタフェースバス(「GPIB」)、IEEE696/S−100などを含む電気電子技術者協会(「IEEE」)によって公布された規格に準拠するバスアーキテクチャなど、任意の標準または標準外バスアーキテクチャを備えてよい。
0027
システム550は好適には、メインメモリ565を含み、二次メモリ570も含んでよい。メインメモリ565は、たとえば上述したモジュールの1または複数など、プロセッサ560で実行しているプログラムに関する命令およびデータの格納を提供する。メインメモリ565は一般に、たとえばダイナミックランダムアクセスメモリ(「DRAM」)および/またはスタティックランダムアクセスメモリ(「SRAM」)などの半導体ベースのメモリである。他の半導体ベースのメモリ型式は、たとえば、読取専用メモリ(「ROM」)を含む、シンクロナスダイナミックランダムアクセスメモリ(「SDRAM」)、ラムバスダイナミックランダムアクセスメモリ(「RDRAM」)、強誘電体ランダムアクセスメモリ(「FRAM」)などを含む。
0028
二次メモリ570は、任意選択的に、内部メモリ575および/または取外し可能媒体580、たとえばフロッピーディスクドライブ、磁気テープドライブ、コンパクトディスク(「CD」)ドライブ、デジタルバーサタイルディスク(「DVD」)ドライブなどを含んでよい。取外し可能媒体580は、周知の方法で読出しおよび/または書込みされる。取外し可能媒体580は、たとえばフロッピーディスク、磁気テープ、CD、DVD、SDカードなどであってよい。
0029
取外し可能記憶媒体580は、コンピュータ実行可能コード(すなわちソフトウェア)および/またはデータがそこに格納された非一時的コンピュータ可読媒体である。取外し可能記憶媒体580に格納されたコンピュータソフトウェアまたはデータは、プロセッサ560による実行のためにシステム550内に読み込まれる。
0030
代替実施形態において、二次メモリ570は、コンピュータプログラムまたは他のデータまたは命令がシステム550内にロードされることを可能にするための他の同様の手段を含んでよい。そのような手段は、たとえば外部記憶媒体595およびインタフェース570を含んでよい。外部記憶媒体595の例は、外部ハードディスクドライブまたは外部光学ドライブ、および/または外部光磁気ドライブを含んでよい。
0031
二次メモリ570の他の例は、たとえばプログラマブル読取専用メモリ(「PROM」)、消去可能プログラマブル読取専用メモリ(「EPROM」)、電気的消去可能読取専用メモリ(「EEPROM」)、またはフラッシュメモリ(EEPROMと同様のブロック指向メモリ)などの半導体ベースのメモリを含んでよい。また、ソフトウェアおよびデータが外部媒体595からシステム550へ転送されることを可能にする他の任意の取外し可能記憶媒体580および通信インタフェース590が含まれる。
0032
システム550は、通信インタフェース590も含んでよい。通信インタフェース590は、ソフトウェアおよびデータが、システム550と外部デバイス(たとえばプリンタ)、ネットワーク、または情報源との間で転送されることを可能にする。たとえば、コンピュータソフトウェアまたは実行可能コードは、通信インタフェース590を介してネットワークサーバからシステム550へ転送され得る。通信インタフェース590の例は、ほんの数例を挙げると、モデム、ネットワークインタフェースカード(「NIC」)、無線データカード、通信ポート、PCMCIAスロットおよびカード、赤外線インタフェース、およびIEEE1394ファイアワイヤを含む。
0033
通信インタフェース590は好適には、たとえばEthernetIEEE802規格、Fiber Channel、デジタル加入者線(「DSL」)、非同期デジタル加入者線(「ADSL」)、フレームリレー、非同期転送モード(「ATM」)、統合デジタルサービスネットワーク(「ISDN」)、パーソナル通信サービス(「PCS」)、伝送制御プロトコル/インターネットプロトコル(「TCP/IP」)、シリアルラインインターネットプロトコル/ポイントツーポイントプロトコル(「SLIP/PPP」)などの業界公布プロトコル規格を実装するが、カスタマイズ型または標準外インタフェースプロトコルも同様に実装してよい。
0034
通信インタフェース590を介して転送されたソフトウェアおよびデータは、一般に電気通信信号605の形式である。これらの信号605は好適には、通信チャネル600を介して通信インタフェース590へ提供される。一実施形態において、通信チャネル600は、有線または無線ネットワーク、または他の任意の様々な通信リンクであってよい。通信チャネル600は、信号605を搬送し、ほんの数例を挙げると、ワイヤまたはケーブル、光ファイバ、従来の電話線、携帯電話リンク、無線データ通信リンク、無線周波数(「RF」)リンク、または赤外線リンクを含む、様々な有線または無線通信手段を用いて実装され得る。
0035
コンピュータ実行可能コード(すなわちコンピュータプログラムまたはソフトウェア)は、メインメモリ565および/または二次メモリ570に格納される。コンピュータプログラムもまた、通信インタフェース590を介して受信され、メインメモリ565および/または二次メモリ570に格納され得る。そのようなコンピュータプログラムは、実行されると、システム550が、上述したような本発明の様々な機能を実行することを可能にする。
0036
本説明において、「コンピュータ可読媒体」という用語は、システム550にコンピュータ実行可能コード(たとえばソフトウェアおよびコンピュータプログラム)を提供するために用いられる任意の非一時的コンピュータ可読記憶媒体を指すために用いられる。これらの媒体の例は、メインメモリ565、(内部メモリ575、取外し可能媒体580、および外部記憶媒体595を含む)二次メモリ570、および(ネットワーク情報サーバまたは他のネットワークデバイスを含む)通信インタフェース590と通信可能に結合された任意の周辺デバイスを含む。これらの非一時的コンピュータ可読媒体は、システム550に実行可能コード、プログラミング命令、およびソフトウェアを提供するための手段である。
0037
ソフトウェアを用いて実現される実施形態において、ソフトウェアは、コンピュータ可読媒体に格納され、取外し可能媒体580、I/Oインタフェース585、または通信インタフェース590によってシステム550内にロードされ得る。そのような実施形態において、ソフトウェアは、電気通信信号605の形式でシステム550内にロードされる。ソフトウェアは、プロセッサ560によって実行されると、好適にはプロセッサ560に、本明細書で上述した本発明の特徴および機能を実行させる。
0038
システム550は、音声およびデータネットワークを介した無線通信を容易にする任意選択的な無線通信部品も含む。無線通信部品は、アンテナシステム610、無線システム615、およびベースバンドシステム620を備える。システム550において、無線周波数(「RF」)信号は、無線システム615の管理の下、アンテナシステム610によって無線で送信および受信される。
0039
一実施形態において、アンテナシステム610は、送信および受信信号経路をアンテナシステム610に提供するために切換え機能を実行する1または複数のアンテナおよび1または複数のマルチプレクサ(不図示)を備えてよい。受信経路において、受信RF信号は、マルチプレクサから、受信RF信号を増幅させ増幅信号を無線システム615へ送信する低雑音増幅器(不図示)へ結合され得る。
0040
代替実施形態において、無線システム615は、様々な周波数にわたり通信するように構成された1または複数の無線装置を備えてよい。一実施形態において、無線システム615は、復調器(不図示)および変調器(不図示)を1つの集積回路(「IC」)に結合してよい。復調器および変調器は、個別の部品であってもよい。入来経路において、復調器は、無線システム615からベースバンドシステム620へ送信されるベースバンド受信オーディオ信号を残し、RF搬送波信号を少しずつ取り除く。
0041
受信信号がオーディオ情報を含む場合、ベースバンドシステム620は、信号を復号し、アナログ信号に変換する。その後、信号は増幅され、スピーカへ送信される。ベースバンドシステム620は、マイクロフォンからのアナログオーディオ信号も受信する。これらのアナログオーディオ信号は、デジタル信号に変換され、ベースバンドシステム620によって符号化される。ベースバンドシステム620はまた、送信のためにデジタル信号を符号化し、無線システム615の変調器部分にルート指定されるベースバンド送信オーディオ信号を生成する。変調器は、ベースバンド送信オーディオ信号をRF搬送波信号と混合し、アンテナシステムにルート指定され電力増幅器(不図示)を通過し得るRF送信信号を生成する。電力増幅器は、RF送信信号を増幅し、それをアンテナシステム610にルート指定し、そこで信号は送信のためにアンテナポートへ切り換えられる。
0042
ベースバンドシステム620はまた、プロセッサ560に通信可能に結合される。中央処理ユニット560は、データ記憶領域565および570へのアクセスを有する。中央処理ユニット560は好適には、メモリ565または二次メモリ570に格納され得る命令(すなわちコンピュータプログラムまたはソフトウェア)を実行するように構成される。ベースバンドプロセッサ610からのコンピュータプログラムもまた受信され、データ記憶領域565または二次メモリ570に格納され、または受信時に実行され得る。そのようなコンピュータプログラムは、実行されると、システム550が、上述したように本発明の様々な機能を実行することを可能にする。たとえば、データ記憶領域565は、図3に関して上述した様々なソフトウェアモジュール(不図示)を含んでよい。
0043
様々な実施形態は、たとえば特定用途向け集積回路(「ASIC」)またはフィールドプログラマブルゲートアレイ(「FPGA」)などの構成要素を用いて、主にハードウェアにおいて実現され得る。本明細書で説明される機能を実行する機能を持つハードウェアステートマシンの実装もまた、当業者には明らかである。様々な構成要素が、ハードウェアおよびソフトウェア両方の組み合わせを用いて実現されてもよい。
0044
さらに、当業者は、上記で説明された図面および本明細書で開示される実施形態と関連して説明された様々な例示的な論理ブロック、モジュール、回路、および方法ステップが、多くの場合、電子ハードウェア、コンピュータソフトウェア、または両者の組み合わせとして実装され得ることを理解する。このハードウェアとソフトウェアとの相互置換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップは、それらの機能性の点から一般に説明された。そのような機能性がハードウェアとして実装されるかソフトウェアとして実装されるかは、システム全体に課された特定の用途および設計制約に依存する。当業者は、説明された機能を特定のアプリケーションごとに様々な方法で実現することができるが、そのような実現の決定は、本発明の範囲からの逸脱をもたらすものとして解釈されてはならない。加えて、モジュール、ブロック、回路、またはステップ内での機能のグループ化は、説明を容易にするためである。特定の機能またはステップが、本発明から逸脱することなく、1つのモジュール、ブロック、または回路から他のモジュール、ブロック、または回路へ移動され得る。
0045
また、本明細書に開示された実施形態と関連して説明された様々な例示的な論理ブロック、モジュール、および方法は、汎用プロセッサ、デジタル信号プロセッサ(「DSP」)、ASIC、FPGAまたは他のプログラマブル論理デバイス、ディスクリートゲートまたはトランジスタロジック、ディスクリートハードウェア構成要素、または本明細書で説明される機能を実行するために設計されたそれらの任意の組み合わせを用いて実装または実行され得る。汎用プロセッサは、マイクロプロセッサであってよいが、代替として、プロセッサは、任意のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであってもよい。プロセッサは、たとえばDSPとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、DSPコアと一体化した1または複数のマイクロプロセッサ、または他の任意のそのような構成など、コンピューティングデバイスの組み合わせとして実装されてもよい。
0046
加えて、本明細書で開示された実施形態と関連して説明された方法またはアルゴリズムのステップは、ハードウェアにおいて直接、プロセッサによって実行されるソフトウェアモジュールにおいて、またはその両者の組み合わせで具体化され得る。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、取外し可能ディスク、CD−ROM、またはネットワーク記憶媒体を含む他の任意の形式の記憶媒体に常駐してよい。典型的な記憶媒体は、プロセッサが記憶媒体から情報を読み出し、記憶媒体へ情報を書き込むことができるように、プロセッサに結合され得る。代替として、記憶媒体は、プロセッサと一体であってよい。プロセッサおよび記憶媒体がASIC内に存在してもよい。
0047
特定の実施形態が上述されたが、説明された実施形態は例示に過ぎないことが理解される。したがって、本明細書で説明されたシステムおよび方法は、説明された実施形態に基づいて限定されてはならない。むしろ、本明細書で説明されたシステムおよび方法は、上記説明および添付図面とともに用いられた場合、以下に続く特許請求の範囲の観点からのみ限定されなければならない。
技術視点だけで見ていませんか?
この技術の活用可能性がある分野
分野別動向を把握したい方- 事業化視点で見る -
(分野番号表示ON)※整理標準化データをもとに当社作成