• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04L
管理番号 1379615
審判番号 不服2020-6952  
総通号数 264 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-12-24 
種別 拒絶査定不服の審決 
審判請求日 2020-05-21 
確定日 2021-11-30 
事件の表示 特願2018-166524「データ通信のためのシステム、方法及び装置」拒絶査定不服審判事件〔平成30年12月27日出願公開、特開2018-207532、請求項の数(15)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、2013年(平成25年)12月20日(パリ条約による優先権主張外国庁受理2012年12月21日 米国、2012年12月21日 米国、2013年5月23日 米国、2013年5月23日 米国、2013年12月20日 米国、2012年12月21日 米国、2012年12月21日 米国)を国際出願日とする出願である特願2015-549773号の一部を平成30年9月6日に新たな特許出願としたものであって、その手続の経緯は以下のとおりである。
令和 元年 6月14日付け:拒絶理由通知書
令和 元年12月27日 :意見書、手続補正書の提出
令和 2年 1月10日付け:拒絶査定
令和 2年 5月21日 :拒絶査定不服審判の請求、手続補正書の提

令和 3年 4月28日付け:拒絶理由(当審拒絶理由)通知書
令和 3年 8月10日 :意見書、手続補正書の提出

第2 原査定の概要
原査定(令和2年1月10日付け拒絶査定)の概要は、次のとおりである。
この出願の請求項1?24に係る発明は、以下の引用文献A?Eに記載された発明に基いて、その発明の属する技術の分野における通常の知識を有する者(以下、「当業者」という。)が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。
引用文献A:米国特許出願公開第2011/0021140号明細書
引用文献B:特開2005-109849号公報
引用文献C:特開平7-245625号公報
引用文献D:特開2000-224223号公報
引用文献E:特開2001-22656号公報

第3 当審拒絶理由の概要
当審が令和3年4月28日付けで通知した拒絶理由(以下、「当審拒絶理由」という。)の概要は次のとおりである。
この出願の請求項1?9に係る発明は、以下の引用文献1?5に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。
引用文献1:米国特許出願公開第2012/0185267号明細書
引用文献2:特開2003-23413号公報
引用文献3:特開2006-211380号公報
引用文献4:特開2005-215996号公報
引用文献5:特許第4661440号公報

第4 本願発明
本願請求項1?15に係る発明(以下、それぞれ「本願発明1」?「本願発明15」という。)は、令和3年8月10日に提出された手続補正書により補正された特許請求の範囲の請求項1?15に記載された事項により特定される発明であり、それらのうちの本願発明1は、次のとおりの発明である。
「【請求項1】
システムであって、
ローカルエリアネットワークを介して医療機器との間でデータを通信し、そして少なくとも1つのアプリケーション層パケットにデータをパッケージ化するように構成されている第1のハブと、
少なくとも1つのセルラーネットワークを介して動作可能に前記第1のハブから前記少なくとも1つのアプリケーション層パケットを受信するように構成される第2のハブとを備え、
前記第1のハブは、少なくとも1つのグローバル・ポジショニング信号を用いて時間パラメータを決定するように構成されたグローバル・ポジショニング・コンポーネントを含み、
前記第1のハブは、少なくとも1つのアプリケーション層パケットのうちのアプリケーション層パケットのヘッダに時間パラメータを追加するように構成され、
前記第2のハブは、前記時間パラメータが所定の基準を満たすか否かを判定するように構成され、
前記第1のハブは、致命的なエラー状態信号を提供するように構成されたフェイルセーフコンポーネントを含み、
前記医療機器は、致命的なエラー状態信号を受信する前記第1のハブに動作可能に接続されており、致命的なエラー状態が、前記致命的なエラー状態信号を介して存在するとされた場合、前記医療機器はハブから独立して動作するように構成されているシステム。」

なお、本願発明2?15は、本願発明1を減縮した発明である。

第5 引用文献の記載、引用発明等
1 引用文献1、引用発明
(1)当審拒絶理由にて引用された引用文献1(米国特許出願公開第2012/0185267号明細書)には、図面とともに次の事項が記載されている(下線は当審による。以下同様。)。

「[0536] FIG. 63 shows as system 3900 having an infusion pump 3902 docked to a dock 3904, a pill dispenser 3906 docked into a dock 3908, and a hub 3910 for interfacing with the docks 3904 and 3908 via USB cables. The hub 3910 also interfaces with as tablet dock 3912 that receives the tablet 3914. Additionally or alternatively, the tablet 3914 communicates with the hub 3910 wirelessly. The tablet 3914 may issue an alert and/or alarm when the mode of technology used for communicating changes, e.g., when changing from wired to wireless or from wireless to wired.
[0537] The hub 3910 includes a display 3916 and provides an interface between the tablet 3914 through the dock 3912. The hub 3910 can support a GUI displayed on the display 3916 (which may be a touchscreen) for programming, setup guidance, status, displaying alerts, displaying alarm, etc.
[0538] In some embodiments of the present disclosure, the hub 3910 includes all of the patient-safety circuitry enabling the system 3900 to be fully fault tolerant of any faults or errors that may occur within or regarding the tablet 3914, and the user interface necessary for patient safety is either on the hub 3910 or on a display of a patient-care devices 3906 and 3902 (e.g., the infusion pump 3902 include a display 3918, but not explicitly shown device 3906). For example, the hub 3910 may require user confirmation (e.g., via a touchscreen of the hub 3910) of an infusion rate and drug to be delivered prior to sending the request or command for the infusion rate to the infusion pump 3902. Additionally or alternatively, in some embodiments, the infusion pump 3902 requests user confirmation of the infusion rate and drug to be delivered prior to operation (e.g., via a touchscreen of the infusion pump 3902).
[0539] The hub 3910 may sound audible indicators for help guidance, alert prompts, alarm prompts, may include independent safety systems to monitor safety critical tasks, may be a fail-safe system for putting patient-care devices into a safety state when an alert or alarm condition occurs, may include independent sensors for critical sensors, may include an independent time base or real-time clock for time critical patient-care devices, e.g., real-time patient-care devices, may include a battery backup to power the patient-care devices through a USB cable, and may include a battery charging to circuit for charging the internal battery therein.」
(当審訳: [0536] 図63は、ドック3904にドッキングされた注入ポンプ3902、ドック3908にドッキングされたピルディスペンサ3906、及び、USBケーブルを経てドック3904、3908とインターフェースするためのハブ3910を有するシステム3900として示す。ハブ3910はまた、タブレット3914を受信するタブレットドック3912とインターフェースする。追加又は代替として、タブレット3914が、ハブ3910と無線通信する。通信に使用される技術のモードが、例えば、有線から無線に又は無線から有線に変化すると、タブレット3914は、アラート及び/又はアラームを発行してもよい。
[0537] ハブ3910は、表示器3916を含み、ドック3912を介してタブレット3914との間のインターフェースを提供する。ハブ3910は、プログラミング、設定ガイダンス、ステータス、アラート表示、アラーム表示等のために、ディスプレイ3916(タッチスクリーンであってもよい)に表示されたGUIをサポートすることができる。
[0538] 本開示のいくつかの実施形態では、ハブ3910は、システム3900が、タブレット3914内またはそれに関して発生し得るあらゆる故障若しくはエラーに対して完全な耐障害性があることを可能にする患者の安全回路のすべてを含み、患者の安全性に必要なユーザインターフェースは、ハブ3910上であるか、又は、患者ケア装置3906及び3902(例えば、注入ポンプ3902はディスプレイ3918を含むが、装置3906に明示的には示されていない)のディスプレイ上であるか、のいずれかである。例えば、ハブ3910は、注入速度に対する要求又はコマンドを注入ポンプ3902に送る前に、送達する注入速度及び届けられる薬剤についてのユーザ確認を(例えば、ハブ3910のタッチスクリーンで)必要とし得る。追加的または代替的に、いくつかの実施形態では、注入ポンプ3902は、注入速度及び届けられる薬剤についてのユーザ確認を、動作前に(例えば、注入ポンプ3902のタッチスクリーンで)要求する。
[0539] ハブ3910はヘルプ案内、アラートプロンプト、アラームプロンプトの可聴インジケータを鳴らしてもよく、安全性にクリティカルなタスクを監視するために独立した安全システムを含んでいてもよく、アラートまたはアラーム状態が発生した時に、患者ケア装置を安全状態にするフェールセーフシステムであってもよく、クリティカルなセンサのための独立したセンサを含んでいてもよく、例えばリアルタイムの患者ケア装置など、時間にクリティカルな患者ケア装置のための、独立した時間ベース又はリアルタイムクロックを含んでいてもよく、USBケーブルを介してthrough患者ケア装置に電力を供給するためにバッテリバックアップを含んでいてもよく、また、内蔵電池を充電するための回路に充電する電池を含んでいてもよい。)

「[0545] The hub 3910 may include two separate processors, each being a watchdog to each other. The hub 3910 may also include various sensors, such as an ambient temperature sensor, a pressure sensor, a humidity sensor, etc. The sensors of the hub 3910 may be redundant to the sensors on the patient-care devices 3902, 3906, 3920 or the tablet 3914, or the hub 3910 may give the patient-care devices 3902, 3906, 3920, or the tablet 3914 access to the measurement taken by the sensors of the hub 3910.
[0546] The hub 3910 may include, for example, WiFi capabilities, Zigbee, Bluetooth. Low Energy Bluetooth, Xbee, Near Field Communication, ranging devices, or the like. The hub 3910 may also include various wired interfaces, such as for example, RS-232, SPI, CAN, USB, Ethernet connectivity, etc.
[0547] The hub 3910 may also include a failsafe line that is coupled to one or more of the on the patient-care devices 3902, 3906, 3920 or the tablet dock 3912 which, when pulled low, can cause a safety circuit to cause all of the patient-care devices 3902, 3906, 3920 or the tablet dock 3912, or the particular device that cause the fault, to enter into a fail safe mode. For example, an electrical conductor (i.e., a wire or line) may exists between the hub 3910 and one or more of that is coupled to a voltage source via a resistor (i.e., the line is high), and another circuit can couple the conductor to a ground (the conductor may be so-called pulled low.). In some embodiments, but not all embodiments, of the present disclosure, when a patient-care device disclosed herein, such one or more of the patient-care devices 3902, 3906, 3920, or a monitoring client, such as a tablet 3914, enters into a fail-safe mode, only critical (a predetermined set) of software routines are enabled and/or only critical circuitry (a predetermined set) is powered. In some embodiments, but not embodiments, for example, all circuitry except for the motor driver circuitry of an infusion pump may be disabled, such as radios, displays, display drivers, or other circuitry. Additionally or alternatively, in some embodiments, but not all embodiments, some software routines or functionality may be disabled that are not necessary when a specific fail safe mode is entered, such as in an infusion pump, the software that displays configuration information may be disabled.
[0548] The hub 3910 may also include a camera 3922 may be used to allow access to the system 3900, or identify a patient, nurse or drug using facial-recognition software, or by reading a barcode (2D or 3D). The camera 3922 of the hub 3910 may also read drug information and check it against the one or more servers 3926 for accuracy, and to ensure the drug is being delivered to the correct patient. Additionally or alternatively, the hub 3910 may also include a microphone 3924 to identify a patient, nurse, or caregiver using voice-recognition software.」
(当審訳: [0545] ハブ3910は、2個の別個のプロセッサを含んでいてもよく、各々が互いの監視者である。ハブ3910はまた、周囲温度センサ、圧力センサ、湿度センサのような、様々なセンサを含んでいてもよい。ハブ3910のセンサは、患者ケア装置3902、3906、3920若しくはタブレット3914上のセンサに対して冗長なものであってもよく、又は、ハブ3910が、ハブ3910のセンサによって測定された測定値へのアクセスを、患者ケア装置3902、3906、3920若しくはタブレット3914に与えてもよい。
[0546] ハブ3910は、例えば、WiFi性能、ZigBee、Bluetoothを含んでいてもよい。低エネルギーブルートゥース、Xbee、近接場通信は、測距装置等。ハブ3910はまた、RS-232、SPI、CAN、USB、イーサネット接続のような、種々の有線インターフェースを含んでいてもよい。
[0547] ハブ3910はまた、患者ケア装置3902、3906、3920のうちの1つ以上又はタブレットドック3912に結合され、ローレベルに引き下げられた場合、安全回路に、患者ケア装置3902、3906、3920の全て、タブレットドック3912、又は障害を引き起こす原因となった特定のデバイスを、フェールセーフモードに入れさせることができる、フェールセーフ線を含んでいてもよい。例えば、導電体(即ち、ワイヤまたはライン)が、ハブ3910との間に存在してもよく、その1つまたは複数は、抵抗(すなわち、ラインがハイである)を介して電圧源に接続され、別の回路が、導体を接地することができる(導体が、いわゆる“ロー引き下げ”状態とされてもよい。)。すべての実施形態ではないが、本発明のいくつかの実施形態では、患者ケア装置3902、3906、3920の1つまたは複数のような、ここで開示される患者ケア装置、又は、タブレット3914などの監視クライアントが、フェールセーフモードに入ると、ソフトウェアルーチンのクリティカル(所定のセット)のみがイネーブルされる、及び/又は、クリティカルな回路(所定のセット)のみに電力が供給される。実施例ではないが、いくつかの実施例では、例えば、注入ポンプのモータ駆動回路以外の、ラジオ、ディスプレイ、ディスプレイドライバ、又は他の回路のような、全ての回路が無効にされてもよい。追加的または代替的に、全ての実施形態ではないが、いくつかの実施形態では、注入ポンプにおけるもののような、特定のフェールセーフモードに入った時に不要な、入力された、いくつかのソフトウェアルーチンまたは機能が、無効にされてもよく、設定情報を表示するソフトウェアを無効にされてもよい。
[0548] ハブ3910はまた、システム3900へのアクセスを許可するため、又は、顔認識ソフトウェアを使用して若しくは(2D又は3Dの)バーコードを読み取って患者、看護婦又は薬剤を認識するためのカメラ3922を含んでいてもよい。ハブ3910のカメラ3922はまた、薬剤情報を読み取り、正確のため、1つまたは複数のサーバ3926に対してチェックし、薬剤が正しい患者に供給されることを保証する。追加的または代替的に、ハブ3910はまた、患者、看護士、または介護者を音声認識ソフトウェアを使用して識別するためのマイクロフォン3924を含んでいてもよい。)

「[0595] FIG. 90 shows a block diagram of circuitry 6000 of a hub disclosed herein. Additionally or alternatively, the circuitry 6000 may be used within a dock, a communication module, or a pump disclosed elsewhere herein. The circuitry 6000 may interface into a bus or hub to communicate with several devices via the device module interface and/or to provide power thereto. Circuitry 6000 includes a first failsafe line 6002 that may be activated by a device processor subsystem 6004, and a second failsafe line 6006 that may be activated by an interface processor subsystem 6008. The first and second failsafe lines 6002, 6006, are fed into an OR gate 6010, which has an output for an output failsafe line 6011 if ether the device process subsystem 6004 or the interface processor subsystem 6008 detects a fault or error, the first or second failsafe lines 6002, 6006 can activate the output failsafe line 6012. The failsafe line 6012 may be coupled to appropriate circuitry and/or devices in response to the output failsafe line 6012, e.g., an automatic occluding device that can automatically prevent fluid flow through an intravenous line when it receives a signal from the output failsafe line 6012. In some embodiments, a patient-care device coupled to the device module interface may request one or more voltages from the regulated power supplies, which each may be a buck, a boost, or a buck-boost power supply.」
(当審訳: [0595] 図90は、ここで開示されるハブの回路6000のブロック図を示す。追加的または代替的に、回路6000は、ドック、通信モジュール、または本明細書の他の箇所で開示されているポンプ内で使用されてもよい。回路6000は、装置モジュールインターフェースを介していくつかの装置と通信するために及び/又はそれに電力を供給するためにバスまたはハブにインターフェースすることができる。回路6000は、装置プロセッササブシステム6004によって起動され得る第1フェールセーフ線6002と、インターフェースプロセッササブシステム6008によって起動され得る第2フェールセーフ線6006を含む。第1及び第2フェールセーフ線6002、6006は、装置プロセッササブシステム6004又はインターフェースプロセッササブシステム6008のいずれかが故障又はエラーを検出した場合に、出力フェールセーフ線6011のための出力を有する、ORゲート6010に供給され、第1又は第2のフェールセーフ線6002、6006は、出力フェールセーフ線6012を起動することができる。出力フェールセーフ線6012は、出力フェールセーフ線6012に応答する適切な回路及び/又は装置、例えば、フェールセーフ線6012からの信号を受信した時に静脈ラインを通る流体の流れを自動的に止めることができる自動閉塞装置に結合されてもよい。一部の実施形態において、装置モジュールインターフェースに結合された患者ケア装置は、バック、ブースト、またはバックブースト電源であり得る、調整電源から1つまたは複数の電圧を要求してもよい。)

(図63)




(図90)




(2)上記(1)から、引用文献1には、次の発明(以下、「引用発明」という。)が記載されていると認められる。なお、段落[0595]の「an output failsafe line 6011」(当審訳:出力フェールセーフ線6011)は「an output failsafe line 6012」の誤記と認められるので、その点を考慮している。

「ドック3904にドッキングされた注入ポンプ3902、ドック3908にドッキングされたピルディスペンサ3906、及び、USBケーブルを経てドック3904、3908とインターフェースするためのハブ3910を有するシステム3900であって、
タブレット3914がハブ3910と無線通信し、
ハブ3910は、注入速度に対する要求又はコマンドを注入ポンプ3902に送り、
ハブ3910は、アラートまたはアラーム状態が発生した時に、患者ケア装置を安全状態にするフェールセーフシステムであってもよく、
ハブ3910はまた、周囲温度センサ、圧力センサ、湿度センサのような、様々なセンサを含んでいてもよく、ハブ3910が、ハブ3910のセンサによって測定された測定値へのアクセスを、患者ケア装置3902、3906、3920若しくはタブレット3914に与えてもよく、
ハブ3910は、WiFi性能、ZigBee、Bluetoothを含んでいてもよく、また、RS-232、SPI、CAN、USB、イーサネット接続のような、種々の有線インターフェースを含んでいてもよく、
ハブ3910はまた、患者ケア装置3902、3906、3920のうちの1つ以上又はタブレットドック3912に結合され、ローレベルに引き下げられた場合、安全回路に、患者ケア装置3902、3906、3920の全てを、フェールセーフモードに入れさせることができる、フェールセーフ線を含んでいてもよく、
ハブの回路6000は、装置プロセッササブシステム6004によって起動され得る第1フェールセーフ線6002と、インターフェースプロセッササブシステム6008によって起動され得る第2フェールセーフ線6006を含み、第1及び第2フェールセーフ線6002、6006は、装置プロセッササブシステム6004又はインターフェースプロセッササブシステム6008のいずれかが故障又はエラーを検出した場合に、出力フェールセーフ線6012のための出力を有する、ORゲート6010に供給され、第1又は第2のフェールセーフ線6002、6006は、出力フェールセーフ線6012を起動することができ、出力フェールセーフ線6012は、フェールセーフ線6012からの信号を受信した時に静脈ラインを通る流体の流れを自動的に止めることができる自動閉塞装置に結合されてもよい、
システム3900。」

2 引用文献A
原査定の拒絶の理由にて引用された引用文献A(米国特許出願公開第2011/0021140号明細書)には、図面とともに次の事項が記載されている。

「[0024] FIG. 1 is a diagram of a communication system capable of managing a sensor network, according to an exemplary embodiment. As discussed previously, a significant portion of the healthcare costs and labor go to acquiring data or testing patients with respect to various medical parameters (e.g., blood pressure, pulse, weight, temperature, glucose level, blood oxygen level, etc.). When a patient is treated in the home (e.g., home nursing or hospice care), healthcare professionals (e.g., nurses and doctors) often must make frequent visits to collect this information, which can result in substantial costs. Moreover, because of limited labor or availability of healthcare professionals, testing in some circumstances may be curtailed to a minimum level, resulting in a less complete picture of the patient's health.
[0025] To address this problem, the approach described herein leverages electronic sensors and communications technologies to provide a system 100 including a sensor hub 101 with connectivity to a family of wireless enabled devices and sensors (e.g., sensors 103a-103m; also collectively referred to as sensors 103) for collecting health-related (e.g., medical parameters and status) and other environmental data (e.g., smoke detectors, carbon monoxide (CO) detectors, movement sensors, etc.). Through this automated approach, patients can be monitored more frequently with less cost than with conventional approaches. In addition, the sensor hub 101 is linked to a sensor backend platform 105 that offers access to collected sensor data via a web portal 107 to the patient and other authorized users (e.g., doctors, nurses, other caregivers, family members, etc.) over a public data network 109 (e.g., the Internet). The patient may also access collected sensor information or other sensor backend platform 105 functions via a wireless display 111 connected (e.g., via Bluetooth) to the sensor hub 101. The sensor hub 101 may also be used to identify authorized users via a near field communication (NFC) tag 113 (e.g., radio frequency identification (RFID) tag, contactless card, or similar technology) associated with the user.
[0026] In one embodiment, the public data network 109 enables the sensor backend platform 105 to connect to or provide a variety of related services. For example, the sensor backend platform 105 may be automatically configured to bill appropriate health accounts (e.g., insurance, Medicare, social aid, etc.) for tests conducted or services performed. In another example, the public data network 109 may facilitate two-way communication (e.g., voice, text messaging, E-mail, media file sharing, etc.) between the patient and a doctor, nurse, or caregiver through the sensor hub 101. In another example, the sensor hub 101 may facilitate tracking of authorized caregivers via NFC tags 113. For instance, when a caregiver enters a patient's home to provide a service to the patient, the caregiver may log into an electronic timesheet application available over the sensor hub 101 by placing the caregiver's NFC tag 113 on or near the sensor hub 101 for reading. The caregiver can then access any of the sensors 103 or data available through the sensor hub 101 (e.g., via the wireless display) to record check points, relevant information on the patient's health and wellness, and/or completed services.
[0027] The specific monitored parameters and/or available functions are determined by the type of sensors 103a-103m installed at the sensor hub 101. According to certain embodiments, to maintain ease of use, the system 100 of FIG. 1 employs dongles 115a-115m that are automatically associated with their corresponding sensors and/or devices 103a-103m to offer a plug and play experience when adding or changing sensors 103a-103m. For example, a dongle 115 includes authentication information (e.g., sensor or device identification number and password) to enable the sensor hub 101 to automatically pair and communicate with a sensor or device 103 corresponding to the dongle 115 via, for instance, short range radio such as Bluetooth, WiFi, or other similar radio frequency protocol. In one example use case, to monitor patient weight, the user plugs a dongle 115 corresponding to a wireless enabled scale into the sensor hub 101. On detecting the dongle 115, the sensor hub 101 retrieves the authentication information stored in the dongle 115 to automatically initiate pairing with the associated wireless scale. The patient does not need to perform any other action, other than plugging the dongle 115 into the sensor hub 101, to initiate pairing with a sensor or device 103, thereby advantageously reducing the need to perform a traditional complex pairing procedure. As the patient uses the scale, the sensor hub 101 collects and transmits the patient's weight to the sensor backend platform 105 for storage and access. The same installation process can be performed to activate any of a variety of sensors 103a-103m (e.g., health or environmental) compatible with the sensor hub 101.
[0028] As shown in FIG. 1, the sensor hub 101 has connectivity to the public data network 109 over either a wireless network 117 and/or a wired network 119. By way of example, the wireless network 117 may be a cellular network and may employ various technologies including enhanced data rates for global evolution (EDGE), general packet radio service (GPRS), global system for mobile communications (GSM), Internet protocol multimedia subsystem (IMS), universal mobile telecommunications system (UMTS), etc., as well as any other suitable wireless medium, e.g., microwave access (WiMAX), Long Term Evolution (LTE) networks, code division multiple access (CDMA), wireless fidelity (WiFi), satellite, mobile ad-hoc network (MANET), and the like. The wired network 119 may be, for instance, any local area network (LAN), metropolitan area network (MAN), wide area network (WAN), or any other suitable packet-switched network, such as a commercially owned, proprietary packet-switched network, e.g., a proprietary cable or fiber-optic network.
[0029] In one embodiment, the sensor hub 101 is by default configured to operate over the wireless network 117. The wireless network 117 enables connectivity to the sensor backend platform 105 even when the patient does not have separate Internet capabilities installed at the patient's home. If the patient's home does have Internet capabilities (e.g., wired network 119), the sensor hub 101 may be connected to the wired network 119 for access to the sensor backend platform 105. In certain embodiments, the sensor hub 101 may connect to both the wireless network 117 and the wired network 119 to provided redundant network access in case either the wireless network 117 or the wired network 119 is not available.
[0030] By way of example, the sensor hub 101 communicates with the sensors/devices 103a-103m, the sensor backend platform 105, and other network components (e.g., the terminal 121, display 111, or web portal 107) using standard protocols. In this context, a protocol includes a set of rules defining how the network nodes within the system of FIG. 1 interact with each other based on information sent over the communication links. The protocols are effective at different layers of operation within each node, from generating and receiving physical signals of various types, to selecting a link for transferring those signals, to the format of information indicated by those signals, to identifying which software application executing on a computer system sends or receives the information. The conceptually different layers of protocols for exchanging information over a network are described in the Open Systems Interconnection (OSI) Reference Model.
[0031] Communications between the network nodes are typically effected by exchanging discrete packets of data. Each packet typically comprises (1) header information associated with a particular protocol, and (2) payload information that follows the header information and contains information that may be processed independently of that particular protocol. In some protocols, the packet includes (3) trailer information following the payload and indicating the end of the payload information. The header includes information such as the source of the packet, its destination/address, the length of the payload, and other properties used by the protocol. Often, the data in the payload for the particular protocol includes a header and payload for a different protocol associated with a different, higher layer of the OSI Reference Model. The header for a particular protocol typically indicates a type for the next protocol contained in its payload. The higher layer protocol is said to be encapsulated in the lower layer protocol. The headers included in a packet traversing multiple heterogeneous networks, such as the Internet, typically include a physical (layer 1) header, a data-link (layer 2) header, an internetwork (layer 3) header and a transport (layer 4) header, and various application headers (layer 5, layer 6 and layer 7) as defined by the OSI Reference Model.」
(当審訳: [0024] 図1は、センサネットワークを管理することができる通信システムの一実施形態を示すブロック図である。前述したように、ヘルスケアの費用及び労力のかなりの部分は、様々な医学的パラメータ(例えば、血圧、脈拍、体重、体温、血糖値、血中酸素レベルなど)に関して、データを取得することや患者を検査することに向かう。患者が家庭で治療される場合(例えば、在宅介護、ホスピスケア)、医療専門家(例えば、看護師および医師)は、多くの場合、この情報を収集するために頻繁に訪問しなければならず、それは、実質的な支出につながる。さらに、限りある労働又は医療関係者の利用可能性のため、ある状況下では試験が最低限に切り詰められ、患者の健康状態のより不完全な初見という結果となる。
[0025] この問題に対処するために、本明細書に記載のアプローチは、健康関連(例えば、医療パラメータ及びステータス)及び他の環境データ(例えば、煙検知器、一酸化炭素(CO)検出器、動きセンサなど)を収集するための無線可能装置及びセンサ(例えば、センサ103a-103m; 総称してセンサ103とも呼ばれる)のファミリーへの接続性を備えたセンサハブ101を含むシステム100を提供するために、電子センサ及び通信技術を活用する。この自動化アプローチによって、患者は、従来のアプローチよりも低コストでより頻繁に監視され得る。加えて、センサハブ101は、収集されたセンサデータへのウェブポータル107によるアクセスを、公衆データネットワーク109(例えば、インターネット)越しに患者及び他の権限のあるユーザ(例えば、医師、看護師、介護士、家族、など)に提供する、センサバックエンドプラットフォーム105にリンクされている。患者はまた、収集されたセンサ情報又はその他のセンサバックエンドプラットフォーム105に、センサハブ101に(例えば、ブルートゥースを介して)接続されたワイヤレスディスプレイ111によってアクセスし得る。センサハブ101はまた、ユーザに関連づけられた近距離場通信(NFC)タグ113(例えば、無線周波数識別(RFID)タグ、非接触カード、または類似の技術)によって、権限のあるユーザを識別するために使用され得る。
[0026] 一実施形態では、公衆データネットワーク109は、センサバックエンドプラットフォーム105が、様々な関連のサービスに接続する又はそれらを提供することを可能にする。例えば、センサバックエンドプラットフォーム105は、自動的に、実施された試験または実行されたサービスに対する適切な健康アカウント(例えば、保険、医療保険、社会的支援、等)に請求するように構成することができる。別の例では、公衆データネットワーク109は、患者と医師、看護師又は介護者との間のセンサハブ101を介した2方向通信(例えば、音声、テキストメッセージ、電子メール、メディアファイル共有など)を容易にする。別の例において、センサハブ101は、NFCタグ113により権限のある介護者の追跡を容易にすることができる。例えば、介護者が、患者宅に入り、患者にサービスを提供するときに、介護者は、センサハブ101上又はその近くに読み取りのために介護者のNFCタグ113を置くことによって、センサーハブ101越しに利用可能な電子予定表アプリケーションにログインし得る。すると、介護者は、チェックポイント、患者の健康及びウェルネスに関連する情報、並びに/又は完了したサービスを記録するために、いずれかのセンサ103又はセンサハブ101を介して利用可能なデータに(例えば、ワイヤレスディスプレイによって)アクセスすることができる。
[0027] 特定の監視されるパラメータ及び/又は利用可能な機能は、センサハブ101に取り付けられたセンサ103a-103mのタイプによって決定される。特定の実施形態によれば、使いやすさを維持するため、図1のシステム100は、センサ103a-103mを追加又は変更する時にプラグアンドプレイ体験を提供するための、対応するセンサ及び/又はデバイス103a-103mに自動的に関連付けられるドングル115a-115mを採用している。例えば、ドングル115は、センサハブ101が、ドングル115に対応するセンサ又はデバイス103と、例えば、ブルートゥース、WiFi、又は他の同様の無線周波数プロトコルなどの短距離無線によって、自動的に対となり、通信することを可能にするため、認証情報(例えば、センサ又はデバイスの識別番号、及びパスワード)を含む。1つの使用例において、患者の体重を監視するために、ユーザは、無線可能とされたスケールに対応したドングル115をセンサハブ101に差し込む。ドングル115を検出すると、センサハブ101は、ドングル115に記憶されている認証情報を検索して、関連する無線スケールとのペアリングを自動的に開始する。患者は、ドングル115をハブ101に差し込む以外、センサまたはデバイス103とのペアリングを開始するために他のアクションを行うことを必要としないので、従来の複雑なペアリング手順の必要性を有利に低減する。患者は、スケールを使用すると、センサハブ101は、保管およびアクセスのために患者の体重を収集しセンサバックエンドプラットフォーム105に送信する。同様の取り付けプロセスが、センサハブ101と互換性のある種々のセンサ103a-103m(例えば、健康又は環境)のいずれかを活性化するために行うことができる。
[0028] 図1に示されるように、センサハブ101は、無線ネットワーク117及び/又は有線ネットワーク119のいずれかを介した、公衆データネットワーク109への接続を有する。一例として、無線通信ネットワーク117は、セルラーネットワークであってよく、グローバルエボリューション用拡張高速データ伝送(EDGE)、汎用パケット無線サービス(GPRS)、移動通信用グローバルシステム(GSM)、インターネットプロトコルマルチメディアサブシステム(IMS)、ユニバーサル移動体通信システム(UMTS)等を含む、種々の技術を、他の適切な無線媒体、例えば、マイクロ波アクセス(WiMAX)、ロングタームエボリューション(LTE)ネットワーク、コード分割多重アクセス(CDMA)、ワイヤレスFidelity(WiFi)、衛星、モバイルアドホックネットワーク(MANET)等と同様に、採用してもよい。有線ネットワーク119は、例えば、任意のローカルエリアネットワーク(LAN)、メトロポリタンエリアネットワーク(MAN)、ワイドエリアネットワーク(WAN)、又は任意の他の適切なパケット交換ネットワーク、商業的に所有される、専用パケット交換ネットワーク、例えば、専有ケーブルもしくは光ファイバネットワークであってもよい。
[0029] 一実施形態において、センサハブ101は、無線ネットワーク117上で動作するように設定されたデフォルトによるものである。無線ネットワーク117は、患者が患者の家に設置された個別のインターネット能力を有しない場合であっても、センサバックエンドプラットフォーム105に接続することを可能にする。患者の家がインターネット能力(例えば、有線ネットワーク119)を有しない場合、センサハブ101は、センサバックエンドプラットフォーム105へのアクセス用の有線ネットワーク119に接続されてもよい。ある実施形態において、センサハブ101は、無線ネットワーク117又は有線ネットワーク119のいずれかが利用可能でない場合でも、冗長なネットワーク・アクセスを提供するため、無線ネットワーク117及びネットワーク119の両方に接続し得る。
[0030] 例えば、センサハブ101は、センサ/デバイス103a-103m、バックエンドプラットフォーム105、及び他のネットワーク要素(例えば、端末121、ディスプレイ111、あるいは、ウェブポータル107)と、標準的なプロトコルを使用して通信する。この文脈において、プロトコルは、図1のシステム内のネットワークノードが、通信リンクを介して送信される情報に基づいて、互いにどのように相互作用するかを定義する一連の規則を含む。そのプロトコルは、種々のタイプの物理信号を生成および受信から、それらの各ノード内の異なるレイヤで、それらの信号によって示される情報の形式に、これらの信号を、コンピュータシステム上で実行するソフトウェアアプリケーションが、情報を送信または受信するかを識別する。ネットワーク上で情報を交換するためのプロトコルの概念的に異なるレイヤが、開放型システム間相互接続(OSI)参照モデルに記載されている。
[0031] ネットワークノード間の通信は、典型的に、データの個別パケットを交換することによって達成される。各パケットは通常(1)特定のプロトコルに関連付けられるヘッダ情報、および(2)ヘッダ情報に続く、ペイロード情報を含む、その特定のプロトコルとは独立して処理され得る情報を含んでいる。いくつかのプロトコルでは、パケットは(3)ペイロードに続き、かつペイロード情報の終了を示す、トレイラ情報を含む。ヘッダは、パケットを、その宛先、ペイロードの長さ、およびプロトコルによって使用される他の特性のような情報を含む。しばしば、特定のプロトコルに対する、ペイロードにおけるデータは、OSI参照モデルの異なる上位レイヤに関連付けられる異なるプロトコルのヘッダおよびペイロードを含む。特定のプロトコルのヘッダは通常、そのペイロードで次のプロトコルに対するタイプを示す。上位レイヤプロトコルは、下位レイヤプロトコルにおいていわゆるカプセル化がなされる。複数の異種ネットワークを横断するパケットに含まれるヘッダであり、インターネットのような、典型的には、物理(レイヤ1)ヘッダ、データリンク(レイヤ2)ヘッダ、インターネットワーク(レイヤ3)ヘッダ、およびトランスポート(レイヤ4)ヘッダ、および、OSI参照モデルによって定義されるような種々のアプリケーションヘッダ(レイヤ5、レイヤ6、およびレイヤ7)を含む。)

(図1)




第6 対比・判断
1 本願発明1について
(1)対比
ア 本願発明1と引用発明とを対比すると、次のことがいえる。
(ア)引用発明の「システム3900」は、後述する相違点は別として、本願発明1の「システム」に相当する。

(イ)引用発明では、「システム3900」は、「ドック3904にドッキングされた注入ポンプ3902、ドック3908にドッキングされたピルディスペンサ3906、及び、USBケーブルを経てドック3904、3908とインターフェースするハブ3910を有する」ものであり、「ハブ3910」は、「注入速度に対する要求又はコマンドを注入ポンプ3902に送」ること及び「ハブ3910のセンサによって測定された測定値へのアクセスを、患者ケア装置3902、3906、3920」に「与え」ることを行うものである。
ここで、「患者ケア装置」は、「注入ポンプ3902」、「ピルディスペンサ3906」等を総称したものであることが明らかである。
したがって、「ハブ3910」は、「USBケーブル」や「ドック3904」を介して、「注入ポンプ3902」との間で、「注入速度に対する要求又はコマンド」に関するデータや「測定値」のデータを通信するといえる。
そして、引用発明の「注入ポンプ3902」は、本願発明1の「医療機器」に含まれる。
以上のことから、本願発明1の
「ローカルエリアネットワークを介して医療機器との間でデータを通信し、そして少なくとも1つのアプリケーション層パケットにデータをパッケージ化するように構成されている第1のハブ」
との構成に関して、引用発明と本願発明1とは、
「医療機器との間でデータを通信する第1のハブ」
を備える点で共通している。

(ウ)引用発明は、
「ハブ3910はまた、患者ケア装置3902、3906、3920のうちの1つ以上又はタブレットドック3912に結合され、ローレベルに引き下げられた場合、安全回路に、患者ケア装置3902、3906、3920の全てを、フェールセーフモードに入れさせることができる、フェールセーフ線を含んでいてもよく、
ハブの回路6000は、装置プロセッササブシステム6004によって起動され得る第1フェールセーフ線6002と、インターフェースプロセッササブシステム6008によって起動され得る第2フェールセーフ線6006を含み、第1及び第2フェールセーフ線6002、6006は、装置プロセッササブシステム6004又はインターフェースプロセッササブシステム6008のいずれかが故障又はエラーを検出した場合に、出力フェールセーフ線6012のための出力を有する、ORゲート6010に供給され、第1又は第2のフェールセーフ線6002、6006は、出力フェールセーフ線6012を起動することができ、出力フェールセーフ線6012は、フェールセーフ線6012からの信号を受信した時に静脈ラインを通る流体の流れを自動的に止めることができる自動閉塞装置に結合されてもよい」
ものである。
ここで、「ハブ3910」は、「ハブの回路6000」として「装置プロセッササブシステム6004又はインターフェースプロセッササブシステム6008」を含み、当該「装置プロセッササブシステム6004又はインターフェースプロセッササブシステム6008」は、それらの「いずれかが故障又はエラーを検出した場合に」、「出力フェールセーフ線6012のための出力」として「ローレベル」の信号を「提供するように構成された」ものであり、また、「患者ケア装置」は、「出力フェールセーフ線6012」から「ローレベル」の信号を受信するために「ハブ3910」に「結合」すなわち「動作可能に接続」されており、「故障又はエラーを検出」した状態である場合、すなわち「エラー状態」が、「ローレベル」の信号を介して「存在するとされた場合」、前記「患者ケア装置」は、例えば「静脈ラインを通る流体の流れを自動的に止める」ような、「フェールセーフモード」で動作するものと理解することができる。
そして、「ローレベル」の信号は、本願発明1の「致命的なエラー状態信号」と、「エラー状態信号」である点で共通し、「装置プロセッササブシステム6004又はインターフェースプロセッササブシステム6008」のいずれかは、本願発明1の「フェイルセーフコンポーネント」に相当する。
また、「フェールセーフモード」で動作することと、本願発明1の「ハブから独立して動作する」こととは、「所定の態様で動作する」ことである点で共通している。
以上の点について上記(イ)も踏まえると、本願発明1の
「前記第1のハブは、致命的なエラー状態信号を提供するように構成されたフェイルセーフコンポーネントを含み、
前記医療機器は、致命的なエラー状態信号を受信する前記第1のハブに動作可能に接続されており、致命的なエラー状態が、前記致命的なエラー状態信号を介して存在するとされた場合、前記医療機器はハブから独立して動作するように構成されている」
ことに関して、引用発明と本願発明1とは、
「前記第1のハブは、エラー状態信号を提供するように構成されたフェイルセーフコンポーネントを含み、
前記医療機器は、エラー状態信号を受信する前記第1のハブに動作可能に接続されており、エラー状態が、前記エラー状態信号を介して存在するとされた場合、前記医療機器は所定の態様で動作するように構成されている」
という点で共通している。

イ 上記アから、本願発明1と引用発明とは、以下の点で一致する。
(一致点)
「システムであって、
医療機器との間でデータを通信する第1のハブを備え、
前記第1のハブは、エラー状態信号を提供するように構成されたフェイルセーフコンポーネントを含み、
前記医療機器は、エラー状態信号を受信する前記第1のハブに動作可能に接続されており、エラー状態が、前記エラー状態信号を介して存在するとされた場合、前記医療機器は所定の態様で動作するように構成されているシステム。」

ウ また、本願発明1と引用発明とは、以下の点で相違する。
(相違点1)
本願発明1では、「第1のハブ」が「医療機器との間でデータを通信」することが、「ローカルエリアネットワークを介して」行われるのに対し、引用発明では、「ハブ3910」が「注入速度に対する要求又はコマンドを注入ポンプ3902に送」ること等が「USBケーブル」や「ドック3904」を介して行われるものである点。

(相違点2)
本願発明1の「第1のハブ」は、「少なくとも1つのアプリケーション層パケットにデータをパッケージ化するように構成されている」のに対し、引用発明の「ハブ3910」は、そのように構成されていると特定されるものではない点。

(相違点3)
本願発明1の「第1のハブ」は、「少なくとも1つのグローバル・ポジショニング信号を用いて時間パラメータを決定するように構成されたグローバル・ポジショニング・コンポーネントを含」むとともに、「少なくとも1つのアプリケーション層パケットのうちのアプリケーション層パケットのヘッダに時間パラメータを追加するように構成され」たものであるのに対し、引用発明の「ハブ3910」は、それらのような機能・構成を有するとは特定されない点。

(相違点4)
本願発明1の「システム」は、「第1のハブ」に加えて、「少なくとも1つのセルラーネットワークを介して動作可能に前記第1のハブから前記少なくとも1つのアプリケーション層パケットを受信するように構成される第2のハブ」を備え、ここで、「前記第2のハブは、前記時間パラメータが所定の基準を満たすか否かを判定するように構成され」るものであるのに対し、引用発明の「システム3900」は、「ハブ3910」とは別のハブを備えると特定されるものではない点。

(相違点5)
本願発明1の「フェイルセーフコンポーネント」が提供する信号は「致命的なエラー状態信号」であり、また、「致命的なエラー状態」が「存在するとされた場合」の「医療機器」の動作は、「ハブから独立して動作する」というものであるのに対し、引用発明の「装置プロセッササブシステム6004又はインターフェースプロセッササブシステム6008のいずれかが故障又はエラーを検出した場合」に「装置プロセッササブシステム6004又はインターフェースプロセッササブシステム6008」が「出力フェールセーフ線6012のための出力」として提供するものは、「ローレベル」の信号であって、当該信号は「故障又はエラー」が「致命的」であることを示すとは特定されず、また、「故障又はエラーを検出した場合」の「患者ケア装置」は、「フェールセーフモード」で動作するものであって、「ハブから独立して動作する」とは特定されない点。

(2)判断
事案に鑑みて、相違点5について先に検討する。
医療機器との間でデータを通信するハブを、致命的なエラー状態信号を提供し得るように構成するとともに、医療機器を、致命的なエラー状態信号をハブから受信した場合にハブから独立して動作するように構成することは、引用文献1?5のいずれにも記載されておらず、本願の優先日前において周知技術であったともいえない。
よって、他の相違点について判断するまでもなく、本願発明1は、当業者であっても引用文献1?5に記載された発明に基づいて容易に発明をすることができたものであるとはいえない。

2 本願発明2?15について
本願発明2?15は、本願発明1を減縮した発明であるから、本願発明1と同様の理由により、当業者であっても引用文献1?5に記載された発明に基づいて容易に発明をすることができたものであるとはいえない。

第7 原査定についての判断
令和2年2月17日(拒絶査定不服審判の請求日)に提出された手続補正書により、請求項10?24は、「医療機器との間でデータを通信」する「第1のハブ」を備える「システム」において、「前記医療機器は、致命的なエラー状態信号を受信する前記第1のハブに動作可能に接続されており、致命的なエラー状態が、前記致命的なエラー状態信号を介して存在するとされた場合、前記医療機器はハブから独立して動作するように構成されている」との技術的事項を含むものとなり、その後、令和3年8月10日に提出された手続補正書により、請求項1?9が削除されて、上記請求項10?24が新たな請求項1?15とされた。
そして、原査定における引用文献A?Eのうちの引用文献Aには、上記第5の2において摘記した記載はあるものの、上記技術的事項については引用文献A?Eには記載されておらず、本願の優先日前において周知技術であったとも認められないので、本願発明1?15は、当業者であっても、原査定における引用文献A?Eに基づいて容易に発明をすることができたものではない。したがって、原査定を維持することはできない。

第8 むすび
以上のとおり、原査定の理由によって、本願を拒絶することはできない。
また、他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2021-11-04 
出願番号 特願2018-166524(P2018-166524)
審決分類 P 1 8・ 121- WY (H04L)
最終処分 成立  
前審関与審査官 野元 久道  
特許庁審判長 ▲吉▼田 耕一
特許庁審判官 小田 浩
富澤 哲生
発明の名称 データ通信のためのシステム、方法及び装置  
代理人 内藤 忠雄  
代理人 赤松 利昭  
代理人 山崎 行造  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ