阅读说明：本技术 睡眠呼吸暂停装置的智能设置和推荐系统 (Intelligent setting and recommendation system for sleep apnea device ) 是由 拉杰万特·索迪 雷哈纳·纳斯万尼 柯林·布拉德利·肯尼迪 于 2019-12-09 设计创作，主要内容包括：公开了一种用于帮助患者设置和使用呼吸治疗装置的系统和方法。该系统包括设备数据库,该设备数据库存储与呼吸治疗装置类型和面罩类型相关的数据。装置识别模块可操作以根据由客户端计算装置捕获的呼吸治疗装置的图像与关于装置类型的数据的比较来识别呼吸治疗装置的类型。面罩识别模块可操作以根据由客户端计算装置捕获的面罩的图像与关于面罩类型的数据的比较来识别面罩的类型。媒体数据库包括与涉及面罩类型和装置类型的辅助信息有关的媒体。管理服务器可操作来向客户端计算装置发送与所识别类型的面罩或所识别类型的装置的辅助信息有关的媒体。(A system and method for assisting a patient in setting up and using a respiratory therapy device is disclosed. The system includes a device database that stores data related to respiratory therapy device types and mask types. The device identification module is operable to identify a type of the respiratory therapy device from a comparison of an image of the respiratory therapy device captured by the client computing device with data regarding the device type. The mask identification module is operable to identify a type of mask based on a comparison of an image of the mask captured by the client computing device with data regarding the type of mask. The media database includes media related to ancillary information relating to mask type and device type. The management server is operable to send media to the client computing device relating to the identified type of mask or the ancillary information of the identified type of device.)

1. A system for providing assistance to a patient for treating a respiratory disorder using a respiratory treatment device and a mask, the system comprising:

a device database storing data relating to a plurality of device types and a plurality of mask types;

a device identification module operable to identify a type of respiratory therapy device from a comparison of an image of the respiratory therapy device captured by a client computing device with data regarding a plurality of device types;

a mask identification module operable to identify a type of mask from a comparison of an image of the mask captured by a client computing device with data regarding a plurality of mask types;

a media database comprising media related to ancillary information related to at least one of a mask type or a device type; and

a management server operable to send media relating to assistance information for the identified mask type or the identified device type to the client computing device.

2. The system of claim 1, further comprising a mask positioning module operable to:

receiving, via an interface, a facial image of a patient captured by the client computing device;

performing facial analysis to identify and track locations of facial landmarks from the facial image;

overlaying a mask placement image on the received facial image frame aligned with the detected facial landmarks for display on a client computing device; and

instructions are provided to the client computing device regarding adjusting the mask based on the overlaid mask placement image.

3. The system of claim 2, wherein the mask positioning module provides the instructions to adjust the mask with indicia associated with the facial image displayed on the client computing device.

4. The system of claim 1, further comprising a mask leak detection module operable to detect whether the mask is properly sealed around the patient's face based on respiratory audio data captured from the client computing device while the respiratory therapy device is in operation.

5. The system of claim 1, wherein the device identification module comprises a machine learning model operable to identify a type of device based on a correlation of learned device images and device types.

6. The system of claim 1, wherein the mask identification module comprises a machine learning model operable to identify a type of mask based on a correlation of the learned mask image and mask type.

7. The system of claim 1, wherein the client computing device includes an interface for collecting input data from the patient relating to respiratory therapy; and wherein the collected input data is received by the management server via the interface.

8. The system of claim 7, further comprising a patient profile database including the identified device type and the identified mask type in relation to the collected input data.

9. The system of claim 1, wherein the client device is operable to instruct a user to at least one of remove, set, or use the respiratory therapy device.

10. The system of claim 1, wherein the respiratory therapy device is one of a Continuous Positive Airway Pressure (CPAP) device, an Automatic Positive Airway Pressure (APAP) device, a bi-level positive airway pressure device (BiPAP).

11. The system of claim 1, further comprising a client application executed by the client computing device, the client application comprising the device identification module and the mask identification module.

12. The system of claim 11, wherein the client application includes an interface that enables the patient to provide feedback related to the mask or the respiratory therapy device to the management server after respiratory therapy.

13. The system of claim 1, wherein the device identification module and the mask identification module are executed by the management server.

14. A method for providing automated assistance to a patient using a respiratory therapy device connected to a mask, the method comprising:

capturing, by a client computing device, an image of a respiratory therapy device and an image of a mask;

identifying, by a device identification module, a type of a respiratory therapy device from a comparison of an image of the respiratory therapy device captured by a client computing device to data in an equipment database regarding a plurality of device types;

identifying, by a mask identification module, a type of mask from a comparison of an image of the mask captured by the client computing device to data in a device database regarding a plurality of mask types; and

media related to the identified mask type or ancillary information of the identified device type is sent to the client computing device via the management server.

15. The method of claim 14, further comprising:

receiving, via an interface, an image of a face of the patient captured by the client computing device;

performing facial analysis via a mask localization module to identify and track locations of facial landmarks from a facial image;

overlaying a mask placement image on the received facial image frame aligned with the detected facial landmarks for display on the client computing device; and

instructions are provided to the client computing device regarding adjusting the mask based on the overlaid mask placement image.

16. The method of claim 15, further comprising providing instructions to adjust the mask with indicia associated with a facial image displayed on the client computing device.

17. The method of claim 14, further comprising:

capturing audio data of a breath from the client computing device while the respiratory therapy device is in operation; and

detecting, via a mask leak detection module, whether the mask is properly sealed around the patient's face based on the captured audio data of the breath.

18. The method of claim 14, wherein the device identification module comprises a machine learning model operable to identify a type of device based on a correlation of learned device images and device types.

19. The method of claim 14, wherein the mask identification module includes a machine learning model operable to identify a type of mask based on a correlation of the learned mask image and mask type.

20. The method of claim 14, further comprising:

collecting, from the client computing device, input data from the patient relating to respiratory therapy; and

the collected input data is received by the management server.

21. The method of claim 20, wherein the collected input data is stored in a patient profile database that includes the identified device type and the identified mask type in relation to the collected input data.

22. The method of claim 14, further comprising instructing, via the client computing device, a user to at least one of remove, set, or use the respiratory therapy device.

23. The method of claim 14, wherein the respiratory therapy device is one of a Continuous Positive Airway Pressure (CPAP) device, an Automatic Positive Airway Pressure (APAP) device, a bi-level positive airway pressure device (BiPAP).

24. The method of claim 14, wherein a client application is executed by the client computing device, the client application including the device identification module and the mask identification module.

25. The method of claim 14, further comprising:

collecting patient-provided feedback related to a mask or respiratory therapy device via an interface of a client application after respiratory therapy; and

the collected feedback is provided to the management server.

26. The method of claim 14, wherein the device identification module and the mask identification module are executed by the management server.

Technical Field

The present invention relates generally to sleep apnea systems and, more particularly, to an intelligent setup and recommendation system for sleep apnea patients.

Background

There are a range of respiratory diseases. Certain conditions may be characterized by specific events, such as apnea, hypopnea, and hyperpnea. Obstructive Sleep Apnea (OSA) is a form of Sleep Disordered Breathing (SDB) characterized by events that include obstruction or blockage of the upper airway during sleep. It is caused by a combination of abnormally small upper airways and normal loss of muscle tone in the region of the tongue, soft palate and posterior oropharyngeal wall during sleep. This condition causes the affected patient to stop breathing typically for a period of 30 to 120 seconds, sometimes 200 to 300 times per night. Often resulting in excessive daytime sleepiness and possibly cardiovascular disease and brain damage. This syndrome is a common condition, particularly in middle-aged overweight men, although the affected person may not be aware of the problem.

Other sleep-related disorders include cheyne-stokes respiration (CSR), Obesity Hyperventilation Syndrome (OHS), and Chronic Obstructive Pulmonary Disease (COPD). COPD encompasses any of a group of lower airway diseases with certain common features. These include increased resistance to air movement, prolonged expiratory phase of breathing, and loss of normal elasticity of the lungs. Examples of COPD are emphysema and chronic bronchitis. COPD is caused by chronic smoking (major risk factor), occupational exposure, air pollution and genetic factors.

Continuous Positive Airway Pressure (CPAP) has been used to treat Obstructive Sleep Apnea (OSA). The application of continuous positive airway pressure acts as a pneumatic splint and may prevent upper airway occlusion by pushing the soft palate and tongue forward and away from the posterior oropharyngeal wall.

Non-invasive ventilation (NIV) provides ventilatory support to a patient via the upper airway to assist the patient in fully breathing and/or maintaining adequate oxygen levels in the body by performing some or all of the respiratory effort. The ventilatory support is provided via a patient interface. NIV has been used in the treatment of CSR, OHS, COPD and chest wall disease. In some forms, the comfort and effectiveness of these therapies may be improved. Invasive Ventilation (IV) provides ventilatory support to patients who are no longer able to breathe effectively on their own and may be provided using a tracheostomy tube.

The therapy system may include a respiratory pressure therapy device (RPT device), an air circuit, a humidifier, a patient interface, and data management. The patient interface may be used to connect the breathing apparatus to its wearer, for example by providing a flow of air to an inlet of the airway. The air flow may be provided via a mask to the nose and/or mouth of the patient, to a tube to the mouth, or to a tracheostomy tube to the trachea. Depending on the therapy to be applied, the patient interface may form a seal with an area, such as a patient's face, for example, to facilitate a pressure of about 10cmH relative to ambient pressure₂The gas is delivered under a positive pressure of O at a pressure that varies sufficiently from ambient pressure to effect treatment. For other forms of therapy, such as delivery of oxygen, the patient interface may not include sufficient volume to facilitate delivery at about 10cmH₂The positive pressure of O delivers a seal of the gas supply to the airway. Treatment of respiratory diseases by such treatment may be voluntary, and thus a patient may choose not to comply with the treatment if the patient finds the device for providing such treatment uncomfortable, difficult to use, expensive, and/or aesthetically unappealing.

CPAP therapy is highly effective for treating certain respiratory conditions, provided that the patient complies with the therapy. The appropriate patient interface is obtained and the CPAP machine is appropriately set up to engage the patient in positive pressure therapy. Patients must now rely on paper instructions provided by the device manufacturer to set up their devices. Improper settings or configurations often frustrate the patient and, therefore, lead to improper operation of the sleep apnea apparatus. Thus, a sleep apnea device that is not properly configured for a particular patient may result in ineffective treatment

There is a need for a system that allows for a more efficient and active setting of a sleep apnea apparatus. There is also a need to use a mobile computing device with an augmented reality interface to assist a user in setting a sleep apnea device. There is also a need for a patient aid that can assess the operation of a sleep apnea apparatus.

Disclosure of Invention

The disclosed system provides a mask sizing system suitable for use with RPT devices to better fit individual patients. The system collects facial data from the primary patient and RPT usage, as well as other data from a larger population of patients, to help select the best mask for the primary patient.

One disclosed example is a system that provides assistance to a patient using a respiratory therapy device and a mask for treating a respiratory disorder. The system includes a device database that stores data related to a plurality of device types and a plurality of mask types. The device identification module is operable to identify a type of the respiratory therapy device from a comparison of an image of the respiratory therapy device captured by the client computing device with data regarding a plurality of device types. The mask identification module is operable to identify a type of mask based on a comparison of an image of the mask captured by the client computing device with data regarding a plurality of mask types. The media database includes media related to ancillary information related to at least one of a mask type or a device type. The management server is operable to send media to the client computing device relating to the identified type of mask or the ancillary information of the identified type of device.

Another disclosed example is a method for providing automated assistance to a patient using a respiratory therapy device connected to a mask. Capturing, by a client computing device, an image of the respiratory therapy device and an image of the mask. The type of the respiratory therapy device is identified by a device identification module from a comparison of an image of the respiratory therapy device captured by the client computing device with data regarding a plurality of device types in an equipment database. The type of mask is identified by a mask identification module from a comparison of an image of the mask captured by the client computing device to data in a device database regarding a plurality of mask types. Media related to assistance information for the identified mask type or the identified device type is sent to the client computing device via the management server.

The above summary is not intended to represent each embodiment, or every aspect, of the present invention. Rather, the foregoing summary merely provides examples of some novel aspects and features set forth herein. The above features and advantages and other features and advantages of the present invention are readily apparent from the following detailed description of the exemplary embodiments and modes for carrying out the invention when taken in connection with the accompanying drawings and appended claims.

Drawings

The invention will be better understood from the following description of exemplary embodiments, taken in conjunction with the accompanying drawings, in which:

FIG. 1 illustrates an example computing environment of a sleep apnea system that allows for help setting of a sleep apnea apparatus;

FIG. 2 illustrates an example of a management server in the computing environment of FIG. 1;

FIG. 3A illustrates a respiratory pressure treatment device in accordance with one form of the present technique;

FIG. 3B is a schematic illustration of the pneumatic path of a respiratory pressure treatment device in accordance with one form of the present technique;

FIG. 3C is a schematic diagram of electrical components of a respiratory pressure treatment device in accordance with one form of the present technique;

4A-4B illustrate screenshots provided by an example client application associated with an initial welcome, login, and sign-in process for device settings;

5A-5B illustrate screenshots provided by an example client application associated with a fetch and device identification process;

6A-6B illustrate screenshots provided by an example client application associated with assisting a patient in placing a mask;

7A-7C illustrate screenshots associated with a mask leak detection process provided by an example client application;

FIG. 8 illustrates a screenshot provided by an example client application associated with a setup completion process;

9A-B illustrate screenshots provided by an example client application associated with preparing a patient for first night therapy with a newly set sleep apnea device;

10A-10C illustrate screenshots provided by an example client application associated with obtaining feedback from a patient;

FIG. 11 shows an example of a mask identification module of an example client application; and

fig. 12 shows an example of a mask recommendation module of an example client application.

The invention is susceptible to various modifications and alternative forms. Some representative embodiments have been shown by way of example in the drawings and will be described in detail herein. However, it should be understood that the invention is not intended to be limited to the particular forms disclosed. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

Detailed Description

The invention may be embodied in many different forms. Representative embodiments are shown in the drawings and will be described in detail herein. The present invention is an example or illustration of the principles of the invention and is not intended to limit the broad aspect of the invention to the illustrated embodiment. In this regard, elements and limitations that are disclosed, for example, in the abstract, summary, and detailed description section, but not explicitly recited in the claims, should not be incorporated into the claims by implication, inference, or otherwise, either individually or collectively. For purposes of this detailed description, the singular includes the plural and vice versa unless specifically stated otherwise; and the word "comprising" means "including but not limited to". Further, for example, approximating language, such as "about," "nearly," "substantially," "about," or the like, may be used herein to mean "on," "near," or "within 3-5% or" within acceptable manufacturing tolerances, "or any logical combination thereof.

The present invention relates to an automated assistant for assisting a user or a respiratory therapy device. The assistant allows the user to confirm the device and mask type. The assistance comprises

Fig. 1 illustrates an example computing environment for a sleep apnea system 100. The sleep apnea system 100 includes a management server 110, a client computing device 120, a sleep apnea device 130, and a mask 140. Although only a single client device 120, sleep apnea device 130, and mask 140 are shown, embodiments of the computing environment 100 may have hundreds or thousands of client devices 120, sleep apnea devices 130, and masks 140 managed by the management server 110.

The sleep apnea device 130 may include, for example, a Continuous Positive Airway Pressure (CPAP) device, an Automatic Positive Airway Pressure (APAP) device, a bi-level positive airway pressure device (BiPAP), or other device for treating sleep apnea. Such devices are commonly referred to as respiratory therapy devices (RPTs). The sleep apnea apparatus 130 generally includes a pressurized respirator connected to a mask 140 by a hose. The sleep apnea apparatus 130 applies a slight air pressure through the hose and mask 140 to keep the patient's airway open during sleep. In a CPAP device, air pressure flows at a constant pressure to the mask 140. In a BiPAP device, the air pressure switches between two different pressure levels for inspiration and expiration, respectively. In an APAP device, the sleep apnea device 130 senses changes in breathing and adjusts the air pressure to an appropriate level based on the breathing pattern.

The sleep apnea apparatus 130 may include a wireless or wired communication interface to connect to the management server 110 via the network 150. For example, the sleep apnea device 130 may communicate with the network 150 via a WiFi connection, a cellular connection, an ethernet connection, or other connection. The sleep apnea device 130 may include sensors that monitor various data associated with the patient's usage and send the data to the management server 110. For example, the sleep apnea device 130 may sense the patient's breathing rate, breathing flow, and overall usage pattern (e.g., the frequency and duration of patient use of the device 130) and report this information to the management server 110.

The mask 140 is coupled to the sleep apnea device 130 via a hose and receives a flow of pressurized air generated by the sleep apnea device 130. The mask 140 is designed to be worn around the patient's mouth, nose, or both. When properly sized and worn, the mask 140 provides an airtight seal around the patient's mouth, nose, or both to enable pressurized air to flow into the patient's breathing cavity. The mask 140 may also include one or more straps that wrap around the patient's head to secure the mask 140 in place. These straps may be adjustable to provide a proper fit and seal for a given patient.

The client computing device 120 comprises a network-enabled computing device, such as a computer, mobile device, or tablet, that executes a client application 125. The client application 125 provides a user interface on the display that enables the patient to provide various information to the management server 110 and view various information from the management server 110 related to the treatment of respiratory diseases of the patient using the sleep apnea apparatus 130. For example, the client application 125 may enable the patient to establish a patient profile that includes various characteristics of the patient (e.g., age, gender, weight, height, sleep habits, etc.) and link the profile to the sleep apnea apparatus 130. The client application 125 may also provide various interfaces on the display to assist the patient during initial removal, setup, and use of the sleep apnea apparatus 130. Additionally, the client application 125 may enable the patient to access various usage data associated with the patient's use of the sleep apnea apparatus 130. Further, the client application 125 may provide alerts and recommendations from the management server 110 related to the patient's treatment, e.g., alert the patient when the mask 140 needs to be replaced, alert the patient when the patient does not follow the recommended usage amount, alert the patient when a malfunction is detected by the sleep apnea apparatus 130 or the mask 140, etc. The client application 125 may also enable the patient to provide feedback to the management server 110 regarding the patient's treatment experience. Although not shown in fig. 1, the client device 120 may be configured to communicate directly with the sleep apnea device 130 via a network connection (e.g., bluetooth, wifi, cellular, and/or other communication mechanisms).

The management server 110 includes a computer or group of computers that provide various management and control functions associated with one or more sleep apnea devices 130. For example, the management server 110 may obtain data associated with the patient, their device 130, and mask 140, and generate content to assist the patient in setting up and using the device 130 and mask 140. In addition, the management server 110 may collect various usage data associated with sleep apnea treatment in order to generate recommendations tailored to the particular characteristics of the patient.

Fig. 2 illustrates an example embodiment of the management server 110. The management server 110 includes an application server 202, a device identification module 204, a mask identification module 206, a mask location module 208, a mask leak detection module 210, a mask recommendation module 212, a patient profile database 250, a media database 252, and a device database 254. In alternative embodiments, the management server 110 may include additional or different modules. In an embodiment, each of the modules may include computer-executable instructions stored to a non-transitory storage medium that, when executed by a processor, cause the processor to perform functions attributed to the module as described herein.

The application server 202 provides an interface between the management server 110 and the client application 125. The application server 202 exchanges data and control information with the client application 125 to cause the client application 125 to perform various functions described herein. For example, when the patient first opens the client application 125, the application server 202 may obtain profile information from the patient and may store the profile information to the patient profile database 250. The application server 202 may also cause the client application 125 to present various user interface screens to guide the user through the login and setup process. Still further, the application server 202 may obtain various sensor data, usage information, and answers investigated associated with the patient throughout the course of treatment of the patient. The application server 202 may also provide the patient with access to various information to assist the patient in performing therapy for respiratory ailments, such as sleep apnea.

The device identification module 204 includes a machine learning model that is capable of automatically detecting a particular model of the sleep apnea device 130 based on one or more images of the sleep apnea device 130 captured by the patient via the client device 120. In one embodiment, the machine learning model is based on correlations between image features and device models learned from different device type data stored in the equipment database 254. For example, to generate a machine learning model, a large number of images of the device 130 for each different model may be captured from various angles, lighting conditions, and camera specifications. Features may be extracted from the image and a learning algorithm may learn which features are most closely related to the device model. During operation, the device identification module 204 may receive images of the sleep apnea device 130 (or features extracted from the images) and predict a device model based on the machine learning model. An example user interface associated with the device identification module 204 is described in more detail below with reference to fig. 5A.

The mask identification module 206 includes a machine learning model that is capable of automatically detecting a particular model of the mask 140 based on one or more images of the mask 140 captured by the patient via the client device 120. In one embodiment, the machine learning model is based on a correlation between the learned image features and the mask model. For example, to generate a machine learning model, a large number of images of the mask 140 for each different model may be captured from various angles, lighting conditions, and camera specifications. Features may be extracted from the images and a learning algorithm may learn which features are most closely related to the mask model. According to some embodiments, the learning algorithm may use mask CAD files stored in the device database 254 as inputs to analyze features and associate those features with a particular mask model. During operation, the mask identification module 206 may receive images of the mask 140 (or features extracted from the images) and predict a mask model based on a machine learning model. An example user interface associated with the mask identification module 206 is described in more detail below with reference to fig. 5B. A more detailed description of the mask identification module 206 is further described below with reference to fig. 11.

The mask positioning module 208 provides an augmented reality interface to assist the patient in properly placing the mask 140 on the patient's face. In one embodiment, the mask positioning module 208 receives an input video stream of the patient portrait, which may be captured via a camera of the client device 120. The mask localization module 208 performs facial analysis to identify and track the location of specific facial landmarks. The mask positioning module 208 then overlays a mask placement image (e.g., an image of the mask 140 or a contour of the mask 140) over the received image frames at an appropriate location aligned with the detected facial landmarks. The image frames are sent to the client application 125 as an augmented reality view of the patient's face with the mask placement image superimposed. Based on the augmented reality view, the patient may align the mask 140 with a mask placement image indicating correct mask placement. An example user interface associated with the mask positioning module 208 is described in more detail below with reference to fig. 6A-6C.

The mask leak detection module 210 detects whether the mask 140 is properly sealed around the patient's face based on audio of the patient's breath captured while the sleep apnea device is delivering therapy/pressure to the patient. For example, after the patient places the mask 140, the client device 110 may be configured to capture audio of the patient's breath (using the microphone of the client device 110). The captured audio (or features derived from the audio) may be sent to the management server 110. The mask leak detection module 210 detects the presence or absence of an audio feature indicative of a leak. In one embodiment, the mask leak detection module 210 may apply a machine learning model that learns correlations between audio features extracted from the audio of the breath when a leak is present. The mask positioning module 208 may also be configured to capture information from the client device 110 regarding how to position the client device 110. Such information may then be used to help determine the location on the patient's face where the leak is occurring. The leak detection results may be provided to the client application 125. An example user interface associated with the mask leak detection module 210 is described in more detail below with reference to fig. 7A-7C.

The mask recommendation module 212 generates patient-specific recommendations for the type and size of the mask 140 based on the image of the patient and various characteristics of the patient. For example, the mask recommendation module 212 may obtain an image of the patient (or features derived from the image) from the client device 110 and perform facial analysis to identify the mask size predicted to fit the patient's face and the type of mask 140 predicted to best fit the patient's face, which may be based in part on machine learning. In one embodiment, the mask recommendation module 212 may apply a machine learning model to learn correlations between patient facial features that may be extracted from the images and mask sizes and types. An example of the mask recommendation module 212 is described in more detail below with reference to fig. 12.

The patient profile database 250 stores various information about the patient. For example, the patient profile database 250 may store physical information such as age, gender, height, weight, etc., medical history, and various preferences. The patient profile database 250 may be updated during ongoing treatment to store various usage data associated with the patient's treatment and feedback provided by the patient.

The media database 252 stores various images, videos, animations or other media that help the patient set up and configure the sleep apnea system 100. For example, the media database 252 may include images or videos that show how the patient sets up, turns on and uses the sleep apnea apparatus 130, how to size, adjust and place the mask 140, or other aiding content to reduce the patient's learning curve when beginning sleep apnea treatment.

Fig. 3A illustrates an exploded view of components of an example RPT device (e.g., sleep apnea device 130) that includes mechanical, pneumatic, and/or electrical components and is configured to perform one or more algorithms, such as any of all or part of the methods described herein, in accordance with an aspect of the present technique. Fig. 3B shows a block diagram of an example RPT device 130. Fig. 3C shows a block diagram of the electrical control components of an example RPT device 130. The upstream and downstream directions are indicated with reference to the blower and patient interface. The blower is defined upstream of the patient interface and the patient interface is defined downstream of the blower, regardless of the actual flow direction at any particular time. Items located in the pneumatic path between the blower and the patient interface are downstream of the blower and upstream of the patient interface. The RPT device 130 may be configured to generate a flow of air for delivery to the airway of a patient to treat one or more of the respiratory conditions.

The RPT device 130 may have an outer housing 4010 formed in two parts, an upper part 4012 and a lower part 4014. In addition, the external housing 4010 can include one or more panels 4015. The RPT device 130 includes a chassis 4016 that supports one or more internal components of the RPT device 130. The RPT device 130 may include a handle 4018.

The pneumatic path of RPT device 130 may include one or more air path items, such as an inlet air filter 4112, an inlet muffler 4122, a pressure generator 4140 (e.g., blower 4142) capable of supplying air at positive pressure, an outlet muffler 4124, and one or more transducers 4270, such as a pressure sensor 4272, a flow rate sensor 4274, and a motor speed sensor 4276.

One or more air path items may be located within a removable unitary structure that will be referred to as a pneumatic block 4020. A pneumatic block 4020 may be located within the housing 4010. In one form, the pneumatic block 4020 is supported by the chassis 4016 or is formed as part of the chassis 4016.

RPT device 130 may have a power supply 4210, one or more input devices 4220, a central controller 4230, a pressure generator 4140, a data communication interface 4280, and one or more output devices 4290. A separate controller may be provided for the treatment device. The electrical components 4200 may be mounted on a single Printed Circuit Board Assembly (PCBA) 4202. In the alternative, the RPT device 130 may include more than one PCBA 4202. Other components, such as one or more protection circuits 4250, transducers 4270, data communication interface 4280, and storage devices may also be mounted on the PCBA 4202.

The RPT device may include one or more of the following components in a single integral unit. In the alternative, one or more of the following components may be positioned as respective independent units.

An RPT device in accordance with one form of the present technique may include an air filter 4110 or a plurality of air filters 4110. In one form, inlet air filter 4112 is located at the beginning of the pneumatic path upstream of pressure generator 4140. In one form, an outlet air filter 4114 (e.g., an antibacterial filter) is located between the outlet of the pneumatic block 4020 and a patient interface (e.g., the mask 140 in fig. 1).

An RPT device in accordance with one form of the present technique may include a muffler 4120 or a plurality of mufflers 4120. In one form of the present technique, inlet muffler 4122 is located in the pneumatic path upstream of pressure generator 4140. In one form of the present technology, the outlet muffler 4124 is located in the pneumatic path between the pressure generator 4140 and the patient interface (e.g., mask 140 in fig. 1).

In one form of the present technique, the pressure generator 4140 for generating a positive pressure air flow or air supply is a controllable blower 4142. For example, the blower 4142 may include a brushless dc motor 4144 having one or more impellers. The impellers may be located in a volute. The blower can be, for example, at a rate of up to about 120 liters/minute, at from about 4cmH₂O to about 20cmH₂Under a positive pressure in the range of O, or up to about 30cmH₂Other forms of O deliver the air supply. The blower may be as described in any of the following patents or patent applications, the contents of which are incorporated herein by reference in their entirety: us patent 7,866,944; us patent 8,638,014; us patent 8,636,479; and PCT patent application publication 2013/020167.

The pressure generator 4140 is controlled by the treatment device controller 4240. In other forms, pressure generator 4140 may be a piston driven pump, a pressure regulator connected to a high pressure source (e.g., a compressed air reservoir or bellows).

The air circuit 4170 in accordance with one aspect of the present technique is a conduit or tube constructed and arranged to allow a flow of pressurized air to travel between two components (e.g., the humidifier 5000 and the patient interface 140) in use. In particular, the air circuit 4170 may be in fluid communication with the outlet of the humidifier 5000 and the plenum chamber of the patient interface 140.

In one form of the present technology, the anti-spill back valve 4160 is located between the humidifier 5000 and the pneumatic block 4020. The anti-spill back valve is constructed and arranged to reduce the risk that water will flow upstream from the humidifier 5000 (e.g., to the motor 4144).

The power supply 4210 may be located inside or outside of the outer housing 4010 of the RPT device 130. In one form of the present technology, the power supply 4210 provides power only to the RPT device 130. In another form of the present technology, the power supply 4210 provides power to both the RPT device 130 and the humidifier 5000.

The RT system may include one or more transducers (sensors) 4270 configured to measure one or more of any number of parameters related to the RT system, its patient, and/or its environment. The transducer may be configured to produce an output signal indicative of one or more parameters that the transducer is configured to measure.

The output signal may be one or more of an electrical signal, a magnetic signal, a mechanical signal, a visual signal, an optical signal, an acoustical signal, or any number of other signals known in the art.

The transducer may be integrated with another component of the RPT system, with one exemplary arrangement being that the transducer is internal to the RPT device. The transducer may be essentially a "stand-alone" component of the RT system, an exemplary arrangement of which is that the transducer is external to the RPT device.

The transducer may be configured to transmit its output signal to one or more components of the RT system, such as the RPT device, a local external device, or a remote external device. The external transducer may be located, for example, on the patient interface or in an external computing device such as a smartphone. The external transducer may be located on or form part of an air circuit (e.g. a patient interface), for example.

The one or more transducers 4270 may be constructed and arranged to generate a signal indicative of a characteristic of the air (e.g., flow rate, pressure, or temperature). The air may be a flow of air from the RPT device 130 to the patient, a flow of air from the patient to the atmosphere, ambient air, or any other. These signals may be indicative of a characteristic of the airflow at a particular point, such as the airflow in the pneumatic path between RPT device 130 and the patient. In one form of the present technology, one or more transducers 4270 are located in the pneumatic path of RPT device 130, e.g., downstream of humidifier 5000.

In accordance with one aspect of the present technique, the one or more transducers 4270 include a pressure sensor in fluid communication with the pneumatic path, an example of a suitable pressure sensor is the HONEYWE LL ASDX Series of transducers, another suitable pressure sensor is the transducer of NPA Series of GENERA L E L ECTRIC, in one implementation, the pressure sensor is located in the air circuit 4170 adjacent the outlet of the humidifier 5000.

The microphone pressure sensor 4278 is configured to generate an acoustic signal indicative of a pressure change within the air circuit 4170. Sound signals from the microphone 4278 may be received by the central controller 4230 for sound processing and analysis configured by one or more algorithms as described below. The microphone 4278 may be directly exposed to the air path to be more sensitive to sound, or may be encapsulated behind a thin layer of flexible film material. The membrane may act to protect the microphone 4278 from heat and/or humidity.

Data from the transducers 4270 (e.g., pressure sensor 4272, flow rate sensor 4274, motor speed sensor 4276, and microphone 4278) may be periodically collected by the central controller 4230. Such data typically relates to the operational state of RPT device 130. In this example, the central controller 4230 encodes such data from the sensors in a proprietary data format. The data may also be encoded in a standardized data format.

In one form of the present technology, the RPT device 130 includes one or more input devices 4220 in the form of buttons, switches, or dials to allow a person to interact with the device. The buttons, switches or dials may be physical or software devices accessible via a touch screen. These buttons, switches or dials may be physically connected to the outer housing 4010 in one form, or may be in wireless communication with a receiver electrically connected to the central controller 4230 in another form. In one form, the input device 4220 may be constructed and arranged to allow an individual to select values and/or menu options.

In one form of the present technology, the central controller 4230 is one or more processors adapted to control the RPT device 130 suitable processors may include an x86 INTE L processor, based on those from ARM HoldingsIn one form of the present technology, the central controller 4230 is a dedicated electronic circuit, in one form the central controller 4230 is a dedicated integrated circuit, in another form the central controller 4230 includes discrete electronic components, the central controller 4230 may be configured to receive one or more input signals from one or more transducers 4270, one or more input devices 4220, and the humidifier 5000.

The central controller 4230 may be configured to provide output signals to one or more of the output device 4290, the therapy device controller 4240, the data communication interface 4280, and the humidifier 5000.

In some forms of the present technology, the central controller 4230 is configured to implement one or more methods described herein on internal memory, e.g., one or more algorithms represented as a computer program stored in a non-transitory computer-readable storage medium. In some forms of the present technology, central controller 4230 may be integrated with RPT device 130. However, in some forms of the present technology, some methods may be performed by a remotely located device, such as a mobile computing device. For example, the remotely located device may determine control settings for a ventilator or detect respiratory-related events by analyzing stored data (e.g., data from any of the sensors described herein). As noted above, all data and operations of the external source or central controller 4230 are generally proprietary to the manufacturer of the RPT device 130. Thus, data from the sensors and any other additional operational data are generally not accessible by any other device.

In one form of the present technology, a data communication interface is provided and connected to the central controller 4230. The data communication interface may be connectable to a remote external communication network and/or a local external communication network. The remote external communication network may be connected to a remote external device, such as a server or a database. The local external communication network may be connected to a local external device, such as a mobile device or a health monitoring device. Thus, the local external communication network may be used by the RPT device 130 or the mobile device to collect data from other devices.

In one form, the data communication interface 4280 is separate from the central controller 4230 and may comprise an integrated circuit or processor in another form, the remote external communication network is the Internet the data communication interface may access the Internet using wired communication (e.g., via Ethernet or fiber optics) or wireless protocols (e.g., CDMA, GSM, 2G, 3G, 4 GG/L TE, L TE Cat-M, NB-IoT, 5G New radio, satellite, beyond 5G). in one form, the local external communication network 4284 utilizes one or more communication standards, such as Bluetooth or consumer infrared protocol.

The example RPT device 130 includes integrated sensor and communication electronics, as shown in fig. 3C. Older RPT devices may be updated with sensor modules that may include communication electronics for transmitting the collected data. Such sensor modules may be attached to the RPT device and thus transmit operational data to an external device such as the management server 110 or the user device 120.

Fig. 4A-4B illustrate screen shots associated with the initial welcome, login, and sign-in processes provided by the client application 125. Accordingly, fig. 1A illustrates screen shots of a user interface, including a welcome interface 400, a login screen 410, a terms and conditions screen 420, and a personal data confirmation screen 430. Fig. 4B illustrates screen shots of a user interface including a health details confirmation screen 440, a check-in overview screen 450, and an assistant introduction screen 460. The client application 125 may present these user interfaces when the client device 120 opens the client application 125 for the first time after the client application 125 is downloaded and installed. Here, the client application 125 obtains various profile information (e.g., personal information and health information) and permissions from the patient via the terms and conditions screen 420, the personal data confirmation screen 430, and the health details confirmation screen 440 to collect and use additional data from the patient. The collected information may be transmitted from the client device 120 to the management server 110 for storage in association with the user profile of the patient. The assistant introduction screen 460 allows the user to ask questions during the installation process via the chat window.

Fig. 5A-5B illustrate screen shots associated with the unbinding and device identification processes provided by the client application 125. Thus, FIG. 5A shows a screenshot of an overview screen 500 and an instruction screen 510. Here, the client application 125 presents step-by-step instructions to the user interface for patient following. After instructing the patient to turn on the device in overview screen 500, client application 125 prompts the patient via instruction screen 510 to point the camera of client device 110 at sleep apnea device 130.

Fig. 5B illustrates an example screenshot of a client activation displayed device image capture interface screen 530 after activation from the instruction screen 510. Device image capture interface screen 530 includes a reticle 532 that may be centered on the image of RPT device 130. While processing the captured device image, a device image processing screen 540 is displayed. The captured image is sent to the management server 110 to enable the device identification module 204 to automatically identify the type of sleep apnea device 130 and store this information to the patient's profile. The client application 125 then confirms to the patient that the sleep apnea apparatus 130 was successfully identified. The device confirmation screen 550 is displayed with a graphical image 552, the graphical image 552 showing a confirmed model of the sleep apnea device. Such information may be used to confirm that the assembly/setup of the product and associated peripherals/connections (power, tubing, etc.) is correct for the product that the patient will use to receive respiratory therapy.

The client application 125 similarly prompts the patient to point the camera of the client device 110 at the mask 140 and sends the captured image to the management server 110. Fig. 5B illustrates an example screenshot of the client activation displayed mask image capture interface screen 560 after activation from the instruction screen 510. The mask image capture interface screen 560 includes a reticle 562 that may be centered on the image of the mask 140. The mask image processing screen 570 is displayed while the captured mask image is being processed. The mask identification module 206 automatically identifies the type of mask 140 based on the image and stores the mask type in the patient's profile. The mask confirmation screen 580 is displayed with a graphical image 582 showing the confirmed model of the mask.

Fig. 5C illustrates a screenshot of an interface 590 provided by the client application 125 associated with a complete mask assembly process. Here, the client application 125 may present a series of images or videos (e.g., products from the media database 252) that indicate how the patient assembled the mask 140 correctly. The presentation may be specific to a particular mask type previously identified. The mask identifying information may also be used to provide information about the particular components, their use/function, and proper attention (i.e., how to unload, how to clean). As shown, this is specific to previously identified mask types, as there are a large number of mask variations, and their composition and function may vary.

Fig. 6A-6B illustrate screenshots provided by the client application 125 associated with assisting a patient in placing a mask. Fig. 6A is a screenshot of an overview interface 600 indicating that the user is attempting the mask 140. Here, the client application 125 provides step-by-step instructions (e.g., in the form of text, images, video, or a combination thereof) that instruct the patient how to wear the mask 140. Fig. 6B is a screenshot of an example video 610 indicating how the patient donned the mask 140. Once the patient indicates that the mask 140 is being worn, the client application 125 presents an interface 620 that provides assistance to the patient in properly positioning the mask seal on the face to ensure that the seal is correct.

If the patient selects the help option on interface 620, client application 125 may capture a video of the user's face using the user-facing camera of client device 110 and present an augmented reality view on the display that includes the captured video and overlays indicia on the patient's face indicating proper mask placement. Fig. 6B shows a series of screen shots used to capture video to aid mask placement. An overview image 630 is displayed to the patient to initiate video capture. Using the augmented reality view, the user is instructed to align the mask 140 with the markers in order to properly position the mask 140. The self-timer interface 640 shows the application of a mask outline 642 over a captured self-image 644 that includes the face of a patient wearing the mask 130. The mask outline 642 may include position markers 646 to help align with facial features. The mask in the self-image 644 may be adjusted as shown in the second image of the self-portrait image interface 650, which the self-portrait image interface 650 helps the patient adjust the mask to match the mask contour 642.

In one embodiment, the client application 125 may detect when the mask is properly aligned and alert the patient based on the captured video. The self-timer interface 650 will generate symbols, such as arrows, that help the patient move the mask to align with the mask contours 642. The interface 650 will show an image of the actual mask 130 relative to the mask outline 642 to assist in proper alignment of the mask. Once the mask is properly positioned, a placement confirmation interface 660 is displayed indicating successful placement to the patient.

Fig. 7A-7C illustrate screen shots associated with a mask leak detection process that may be part of the client application 125. Upon detecting that the mask 140 is properly aligned, the client application 125 may instruct the patient to hold the client device 120 in proximity to the mask 140. The client application 125 displays the leak coordination overview interface 700 to instruct the patient to detect the leaked noise during operation of the respiratory therapy device 130. The client application 125 controls the microphone of the client device 120 to capture audio and send the audio or features extracted from the audio (e.g., audio fingerprints) to the management server 110. When the patient selects the continue button in interface 700, microphone interface 710 is displayed to allow the patient to activate the microphone of client device 120. When the microphone is activated, the active microphone interface 720 is displayed. The mask leak detection module 210 may then detect whether the mask 140 has a proper seal or an acceptable leak profile based on the extracted features. In one embodiment, the detection algorithm may be different for different types of masks 140 and/or for different facial features. For example, a different detection algorithm may be used for patients with facial hair than for patients without facial hair.

Upon detection of a proper seal, the patient may be alerted via the client application 125 that the test is complete. Otherwise, if a proper seal is not detected, the client application 125 may alert the patient and provide the patient with the option to reposition the mask 140 and attempt to access the interface shown in fig. 6A-6C above again. Fig. 7B shows leak detection interface 730 alerting the patient based on the detected leak. Alternatively, the client application 125 may provide the patient with the option of obtaining assistance from an automated assistant or from a live human representative. The example assistant introduction interface 740 may be activated to allow communication with an assistant. For example, in one embodiment, the patient may chat with the assistant via chat interface 750. If chat with the remote assistant fails to resolve the problem, the client application 125 may initiate a video call with a live representative to further assist the patient, as shown by video initiation interface 760. The video launch interface 760 allows a confirmation screen 770 to be displayed. If the patient confirms that an upgrade is needed to the live representative, the application will launch a video call screen 780 allowing the patient to initiate a video call with the live representative. If the problem cannot be resolved, the client application 125 may recommend that the patient order a different size or model of mask 140.

Fig. 8 illustrates a screenshot provided by the client application 125 associated with the setup complete process. Here, the client application 125 presents screen shots 800, 810, and 820 that inform the patient that the setup is complete, and may provide the patient with the option to repeat any of the previous steps. Screenshot 800 shows an interface 800 displaying this state. Screenshot 810 is a completion interface screen that allows the patient to repeat the procedure or complete the procedure. The patient may select the end setting, thereby displaying a done screen 820.

Fig. 9A illustrates a screenshot provided by the client application 125 associated with preparing a patient for first night therapy with a newly set sleep apnea apparatus 130. In one embodiment, the client application 125 may automatically present the notification user interface 900 prior to the patient's bedtime. Here, the client application 125 may present information to the patient related to preparing overnight treatment and may present a checklist to the patient to ensure that all devices are properly set up and ready. For example, interface 910 may allow a user to select a list button 912 for information related to preparing overnight treatment. The interface 910 includes an icon 914 indicating the date the sleep apnea apparatus 130 has been used. One exemplary checklist interface is a mask checklist screen 920 that provides a check on mask placement, e.g., whether the mask is properly connected, comfortable, and leak free. Another exemplary checklist interface is a device checklist screen 930 that provides checks on the operation of the device, such as whether the device is on, whether the device is properly connected, and whether there is water in the humidifier.

Fig. 9B shows a main interface 940 that includes a sleep input section 942 that allows a user to select icons representing quality of sleep, data fields 944 representing summary data and total scores for each therapy session using the device 130, and different activation buttons for the functions of the client application 125. Interface 950 shows menu options that allow the patient to access different application functions.

Fig. 10A-10C illustrate screenshots provided by the client application 125 associated with obtaining feedback from a patient after treatment for the first night. Here, the client application 125 may present the notification user interface 1000 in the morning around the predicted wake time of the patient. The client application 125 may request feedback from the patient regarding the patient's overnight sleep quality. For example, a sleep rating interface 1010 may be presented that includes selectable icons 1012, 1014, and 1016 that the patient may select to reflect his sleep experience. The feedback may be sent to the management server 110. Positive feedback, such as selection of icon 1016, may allow for the presentation of additional contextual interfaces 1020 that allow for the collection of additional data.

If the patient provides negative feedback, such as selecting icon 1012 or icon 1014 in interface 1010, client application 125 may present additional questions related to diagnosing the cause of the patient's poor experience. For example, the appliance analysis feedback screen 1030 shown in fig. 10B may present different options 1032 that allow the user to select the reasons for their dissatisfaction, such as mask discomfort, dry eyes, loud noise, waking up to find mask off, and mouth/nose dryness. Upon selection, the interface 1030 displays the selected question icon as a highlighted icon 1034, and transmits the data to the management server 110. An exemplary mask discomfort interface 1040 can be displayed to collect data about potential mask discomfort via icons 1042, which icons 1042 represent common mask-related discomfort, such as the mask feeling too light, the mast feeling too loose and noisy, or the mask feeling foreign objects on the face. Each selected icon may cause other feedback interfaces to be displayed. For example, if noise is identified as a problem, noise feedback interface 1050 may be displayed to collect data on noise problems via icon 1052, which icon 1052 represents common noise problems, such as noise from air around the mask, noise from machinery, or noise from contact hoses. The feedback may also be sent to the management server 110 and may be used to generate recommendations for a patient (or patient group) to help improve the experience. The exemplary summary and submission interface 1060 may be displayed with a review box 1062 for the patient to provide additional feedback.

Fig. 11 illustrates an example embodiment of the mask identification module 206. Here, the mask identification module 206 includes a learning module 1110 and a prediction module 1120. The learning module 1110 learns the correlation between image features derived from the image of the face mask 140, the face mask CAD file, and the type of face mask 140. In one embodiment, the learning module 1110 includes a data acquisition module 1112, a data set preparation module 1114, and a machine learning and evaluation module 1116. The data acquisition module 1112 collects an imaging dataset of sufficient sample size and condition changes to enable machine learning. For example, the data acquisition module 1112 may acquire images captured of various possible types of masks under various lighting conditions, environments, orientations, and using different acquisition devices, in order to obtain a data set having a large range of images representing images that may be captured by a patient during the mask inspection process described above in fig. 5A-5B. The dataset preparation module 1114 prepares an imaging dataset for machine learning by performing various processes on the image. For example, the dataset preparation module 1114 may normalize the image, place the image in a normalized format, and perform one or more transformations on the image (e.g., to extract image features). The machine learning and evaluation module 1116 trains the machine learning model to learn the correlation between the images and mask types. In various embodiments, the machine learning and assessment module 1116 may perform supervised learning, unsupervised learning, or a combination thereof. The machine learning and evaluation module 1116 may generate a candidate model 1118 representing the learned correlations.

The prediction module 1120 predicts the mask type based on the received image. In one embodiment, the prediction module 1120 includes a deployment module 1122, a field trial module 1124, and a production deployment module 1126. The deployment module 1122 transforms the candidate model 1118 into a machine learning model that can be deployed across multiple machine learning platforms. The field test module 1124 manages controlled field tests to evaluate predictions of the candidate model 1118 under different conditions using multiple machine learning platforms. The field trial module 1124 may refine the candidate model 1118 to generate a validated model 1128. The production deployment module 1126 applies the validated model 1128 to input images of the mask received during patient setup and generates a mask type prediction. Production deployment module 1126 may incorporate various analysis and data collection mechanisms to generate updates to verified model 1128 to continue to improve its accuracy.

Fig. 12 illustrates an example embodiment of the mask recommendation module 212. The mask recommendation module 212 recommends a particular mask type and size for a particular patient based on the portrait image of the patient. For example, in one embodiment, the mask recommendation module 212 applies a plurality of different feature extraction modules 1202 to identify various predicted features associated with an image of a patient. For example, the feature extraction module 1202 may include, for example: a camera, lens, and image properties module 1220 to identify a camera type, a lens type, and various image properties associated with an input image; a facial feature analysis and measurement module 1222 for analyzing and measuring facial features of the patient captured in the input image; a head skew/rotation module 1224 to detect a head skew and/or an amount of rotation in the input image; a gender identification module 1226 for detecting the gender of the patient from the input image; an age estimation module 1228 for estimating an age of the patient based on the input image; and a race identification module 1230 that predicts a race of the patient based on the input image.

Features from the feature extraction module 1212 are input to one or more machine learning models 1204, each trained to detect the suitability of a patient's face for different sizes and types of masks 140. The machine learning model 1204 generates a mask size recommendation 1206 and a mask type recommendation 1208.

In alternative embodiments, the various modules attributed to the management server 110 described above may instead be executed in whole or in part by the client application 125. For example, instead of the client application 125 sending images or image features to the management server 110, the client application 125 may directly apply one or more machine learning models (based on the models received from the management server 110). In other embodiments, the functions described herein as being performed by the client application 125 may instead be performed by the management server 110.

As used in this application, the terms "component," "module," "system," and the like are generally intended to refer to a computer-related entity, either hardware (e.g., circuitry), a combination of hardware and software, or an entity associated with an operating machine that has one or more specific functions. For example, a component may be, but is not limited to being, a process running on a processor (e.g., a digital signal processor, a microprocessor, an object, an executable, a thread of execution, a program, and/or a computer). By way of illustration, both an application running on a controller and the controller can be a component. One or more components can reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. Furthermore, an "apparatus" may take the form of specially designed hardware; general purpose hardware that is specially manufactured by executing thereon software that enables the hardware to perform specific functions; software stored on a computer-readable medium; or a combination thereof.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Furthermore, the terms "including", "having", or variants thereof, are used in the detailed description and/or the claims, and are intended to be inclusive in a manner similar to the term "comprising".

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art. Furthermore, terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Although the invention has been shown and described with respect to one or more embodiments, equivalent alterations and modifications will occur to others skilled in the art upon the reading and understanding of this specification and the annexed drawings. In addition, while a particular feature of the invention may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. Thus, the breadth and scope of the present invention should not be limited by any of the above-described embodiments. Rather, the scope of the invention should be defined in accordance with the following claims and their equivalents.