Abstract:
Systems, methods and devices are disclosed for monitoring sobriety of a first user by a second user which can be discrete, wirelessly linked via a communications network and can provide various forms of alerts to the first and second users.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims priority to U.S. Provisional Application, No. 62/089,140, entitled “SOBRIETY MONITORING SYSTEM”, filed Dec. 8, 2014, which is hereby incorporated in its entirety by reference. 
     
    
     FIELD OF THE INVENTION 
       [0002]    This disclosure relates generally to systems, device and methods for remote sobriety monitoring. 
       BACKGROUND OF THE INVENTION 
       [0003]    Recovering alcoholics or other substance abusers may benefit from the supervision of a sober chaperone such as a sober buddy, sober companion or sober coach to assist a recovering alcoholic in maintaining abstinence from alcohol outside of a treatment facility. Such a sober companion commonly chaperones the recovering alcoholic or substance abuser on a constant basis, or may be available on an on-call basis to accompany a recovering alcoholic or substance abuser periodically or as needed during certain activities. Such supervisory care can be quite expensive, which may have the unfortunate consequence of reducing or eliminating the services of such supervisory care. 
         [0004]    People struggling with alcohol often conceal their abuse, making it difficult for concerned family members to confirm their suspicions and intervene. Because alcohol leaves the system quickly, it is important to test for alcohol consumption by using a breathalyzer or another similar alcohol testing method. Confirmation of a drinking problem becomes increasingly difficult during periods when testing for alcohol consumption is not easily enforced, such as during travel for business or college, for example. It would be useful to provide a method for parents to be able to monitor alcohol use anywhere by their children, and for spouses to monitor alcohol use anywhere by their spouses, in order to eliminate suspicions and confirm whether the family member has a drinking problem. It would also be useful to provide a method for companies to deter alcohol abuse by employees during work hours. Industries that rely heavily on driving and have limited employee supervision could also benefit from a method allowing the monitoring of alcohol use by employees as a way to confirm employee sobriety during work hours. Although drug testing is common in the workplace, since alcohol is metabolized relatively quickly, and is not easily tested, it would also be useful to provide a method for immediate confirmation of an employee&#39;s alcohol level at any given time. 
         [0005]    Court ordered sobriety is also commonly required as a condition of probation or other court imposed rehabilitative or behavior altering programs. Reporting to a stationary facility, one&#39;s probation officer, or even one&#39;s home in order to be tested for substance use is often an embarrassing and time consuming ordeal that does not facilitate healthy reintegration into society. Thus, the discrete remote monitoring of a person under such a program by the court, or other authority, without requiring the monitored person to excuse themselves from society for more than a brief period of time would be useful in reintegrating the monitored person into society without the awkward and embarrassing effects of traditional monitoring procedures. Such a system is also useful to provide a system of monitoring where those monitored are emboldened to no longer feel like societal outcasts and are thus increasingly motivated to maintain their sobriety. 
         [0006]    It would therefore be desirable to provide methods, devices and systems of providing supervisory monitoring of sobriety that are discrete, portable, tamper-proof, and effective, and that can automatically alert a monitoring station of the need for attention and possible corrective or medical action by such a supervisory sober buddy or sober companion on an on-call basis. The present invention meets these and other needs. 
       SUMMARY OF THE INVENTION 
       [0007]    Briefly, and in general terms, the present invention provides for systems, devices and methods for monitoring sobriety of a user, utilizing a portable, handheld breath testing device transmitting breath test results to a monitoring station via a wireless network. The breath test data is stored by the monitoring station and is retrievable therefrom by a monitor, such as a parent, guardian, parole officer, court liaison, spouse, sobriety coach, friend, sobriety monitoring company, or other authorized group or individual. In this manner, the monitor is able to respond appropriately to the detected utilization of alcohol and/or other substances by a user. 
         [0008]    By using the methods, devices and system of the present invention, a family member trying to build back trust in family relationships can prove that they are making behavior changes by sending breath test reports on a predetermined schedule, or when randomly requested by the family. The present invention helps a person prove that they are making healthier choices in life and making steps toward rebuilding trust in family relationships. Families can benefit from knowing that loved ones are sober enough to drive, and the present invention can be used remotely to determine a person&#39;s sobriety or that blood alcohol levels are in an acceptable range. For families who want to monitor their children or spouses, the sobriety monitoring system of the present invention can send a breath test report directly to a mobile device such as a smartphone or tablet. 
         [0009]    The present invention can also be used for immediate confirmation of an employee&#39;s alcohol level at any given time. Particularly those companies with employees who drive as a part of their employment would benefit by keeping their employees sober during working hours. The present invention also can be used in rehabilitative aftercare, and can be used to monitor multiple patients, and the present invention can be used by a sober companion during times when they are not able to accompany one or more of the patients. 
         [0010]    Due to the compact, handheld portable nature of the present invention, the present invention mitigates the social stigma, personal embarrassment and general inconvenience typically associated with traditional sobriety monitoring techniques, e.g. ankle bracelets, urinalysis, fixed testing sites, etc. 
         [0011]    These and other aspects and advantages of the invention will be apparent from the following detailed description and the accompanying drawing, which illustrates by way of example the features of the invention. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWING(S) 
         [0012]    Illustrated in the accompanying drawing(s) is at least one of the best mode embodiments of the present invention In such drawing(s): 
           [0013]      FIG. 1A  is a schematic diagram of an example embodiment of a sobriety monitoring system in accordance with the present invention; 
           [0014]      FIG. 1B  is an example embodiment of a network connected server system in accordance with the present invention; 
           [0015]      FIG. 1C  is an example embodiment of a user device in accordance with the present invention; 
           [0016]      FIG. 2  is a schematic diagram of an example embodiment of a breath testing device in accordance with the present invention; 
           [0017]      FIG. 3  is an example embodiment of a web portal in accordance with the present invention; 
           [0018]      FIG. 4  is a perspective view of an example embodiment of a breath testing device in accordance with the present invention; 
           [0019]      FIG. 5  is an example embodiment of a report in accordance the present invention; 
           [0020]      FIGS. 6A-6B  are example embodiments of web portals in accordance with the present invention; 
           [0021]      FIGS. 7A-7C  are example embodiments of web portals in accordance with the present invention; 
           [0022]      FIG. 8  is an example embodiment of a report in accordance with the present invention; 
           [0023]      FIG. 9  is a schematic of an example embodiment of a breath intake of a breath monitoring device in accordance with the present invention; 
           [0024]      FIG. 10  is a flowchart of an example embodiment of a counter process in accordance with the present invention; 
           [0025]      FIG. 11  is a schematic diagram of an example embodiment of a breath testing device utilizing personal-area-network connectivity in accordance with the present invention; and 
           [0026]      FIG. 12  is a front elevated view of an example embodiment of a portable calibration unit according to the present invention. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0027]    The above described drawing figures illustrate the invention in at least one preferred, best mode embodiment, which is further defined in detail in the following description. Those having ordinary skill in the art may be able to make alterations and modifications to what is described herein without departing from its spirit and scope. Therefore, it should be understood that what is illustrated is set forth only for the purposes of example and should not be taken as a limitation on the scope of the present system and method. 
         [0028]    Described now in detail is a method and system for monitoring sobriety of a user according to at least one preferred embodiment. 
       Basic Structure 
       [0029]    As shown in  FIG. 1A , a schematic diagram of an example embodiment of a sobriety monitoring system  100  can include: a portable, handheld breath testing device  1000  communicatively coupled to a monitoring station  1200  and server  1700  via a wireless network  1300 . The breath testing device  1000  tests the breath of a user  200  for the presence of alcohol and/or other substances. The breath testing device  1000  generates breath test data in response to assessment of the user&#39;s breath, the breath test data can indicate whether the user  200  has recently utilized alcohol and/or other substances. The breath test data can be wirelessly transmitted by the breath testing device  1000  via the network  1300  to the monitoring station  1200  and the server  1700 , which may be any device or system at a location where the breath test data is received, including by way of non-limiting example: a cellular/smart phone, an email account, a website, a network database, and a memory device. The breath test data is stored by the monitoring station  1200 , the server  1700  or both, and is retrievable therefrom by a monitor  300 , such as a parent, guardian, parole officer, court liaison, spouse, sobriety coach, friend, sobriety monitoring company, or other authorized group, individual or combination thereof. In this manner, monitor  300  is able to respond appropriately to the detected utilization of alcohol and/or other substances by the user  200 . Preferably, the monitor  300  is able to retrieve the breath test data via a network connected user interface device  1500 , communicatively coupled—via the network  1300 —to the monitoring station  1200 , the server  1700  and/or to the breath testing device  1000 . 
         [0030]    Server  1700  can include applications distributed on one or more physical servers, each having one or more processors, memory banks, operating systems, input/output interfaces, and network interfaces, all known in the art. A plurality of user interface devices  1500  can be communicatively coupled to network  1300  such as a public network (e.g. the Internet and/or a cellular-based wireless network, or other network), a private network or a combination thereof. User interface devices  1500  and monitoring stations  1200  can include for example mobile devices (e.g. phones, tablets, or others) desktop or laptop devices, wearable devices (e.g. watches, bracelets, glasses, etc.), other devices with computing capability and network interfaces and so on. Sobriety monitoring system architecture  100  can include a network connected server system  1700  which can include hosting and/or interfacing, by way of physical servers, websites, webpages, web applications, social media platforms, advertising platforms, and others. 
         [0031]      FIG. 1B  shows an example embodiment of a diagram of a server system  1700  according to the invention including at least one user device interface  1730  implemented with technology known in the art for communication with user devices (e.g. user devices  1500  of  FIG. 1A ). The server system  1700  can also include at least one web application server system interface  1740  for communication with web applications, websites, webpages, websites, social media platforms, and others over a network. The server system  1700  can further include an application program interface (API)  1720  that is coupled to an account database  1710 , event database  1712 , and scheduling database  1714  and can communicate with interfaces such as the user device interface  1730 , breath testing device interface  1750  and web application server system interface  1740 , or others. The API  1720  can instruct the databases  1710 ,  1712 ,  1714  to store (and retrieve from the databases) information such as user account information, associated account information, event information or others as appropriate. The databases  1710 ,  1712 ,  1714  can be implemented with technology known in the art such as relational databases and/or object oriented databases or others. 
         [0032]      FIG. 1C  shows a diagram of a user device  1500  according to an embodiment of the invention that includes a network connected sobriety monitoring application  1902  that is installed in, pushed to, or downloaded to the user mobile device  1500 . In many embodiments user mobile devices  1500  are touch screen devices such as smart phones or tablets. User mobile devices  1500  are implemented with memory, processors, communications links, power supplies such as rechargeable batteries, interfaces such as screens displaying GUI&#39;s, buttons, touchpads, software stored in memory and executed by processors, audio input and output components, video input and output components, and others. Software can include computer readable instructions stored on non-transitory computer readable media such as computer memory. 
         [0033]    In some embodiments, a server supported website comprises a mobile website accessible via a sobriety monitoring application  1902  on a personal computing device  1500  such as a mobile device (e.g. smart phone). The mobile website may be a modified version of the server supported website with limited or additional capabilities suited for mobile sobriety monitoring by monitor  300 . In some embodiments no specific application  1902  is required but users can access a sobriety monitoring system through a web browser of the user mobile device  1500 . 
         [0034]    As shown in the example embodiment of  FIG. 2 , a breath testing device  1000  may comprise a memory  1005 , such as a SPI FLASH 8 MB memory, communicatively coupled to a breath testing module  1400 . Breath testing module  1400  is operable to measure the user&#39;s breath and convert the measurements into breath test data, as will be described elsewhere herein and breath testing module  1400  can be communicatively coupled to a wireless transceiver  1600 , such as a personal area network (PAN). Each of memory  1005 , breath testing module  1400  and transceiver  1600  can be communicatively coupled to a control unit  1800 , such as an ARM processor, for controlling the operations thereof in accordance with the functionalities described herein. As breath testing device  1000  is portable and handheld, each of the components are preferably located within, immediately adjacent to, or exposed within and/or without, a device housing (e.g. housing  1002  of  FIG. 4 ) whose dimensions are such that the breath testing device  1000 —as a whole—may be discretely carried by the user, for example, within a pocket or small purse. 
         [0035]    Further, as shown for example in the breath testing device architecture  2000  of  FIG. 2 , corresponding to a breath testing device  1000 , may comprise: a central processing unit  1800  communicatively coupled to: a pump  1402 , one or more pressure sensors  1404 , a fuel cell  1406 , and one or more temperature sensors  1408 , which together can be included in a breath testing module  1400 . An imager  1006 , a test interface  1010 , a flash memory  1005 , a test connector  1003 , a display  1004 , an LED prompt  1009 , a flash LED  1008 , a test request/power button  1018 , a wireless transceiver  1600 , batteries  1012  and  1014 , and associated charging interface  1016  can also be communicatively coupled to central processing unit  1800 . Pump  1402  can also be connected through a converter  1012  to transceiver  1600 . Each of these components are described further herein in the context of their functionalities within the described embodiments. 
         [0036]    In an example embodiment, a monitoring station  1200 , as shown for example in  FIG. 1A , can comprise a server system  1700 , hosting a server supported website (not shown). Server supported website can be supported by a server system  1700  comprising one or more physical servers, each having a processor, a memory, an operating system, input/output interfaces, and network interfaces, all known in the art, coupled to the network  1300 . The server supported website can comprise one or more interactive web portals through which a monitor  300  may monitor the sobriety of a user  200  using a breath monitoring device  1000 , in accordance with the described embodiments. In particular, the interactive web portals may enable the monitor  300  to retrieve breath test reports generated using data from the breath testing devices  1000  of one or more users (e.g. user  200 ), set or modify breath test schedules, and/or set or modify preferences, as described herein. Preferably, the interactive web portals are accessible via a personal computing device  1500 , such as for example, a home computer, laptop, tablet, and/or smart phone. 
         [0037]    Additional details of these features and others may be found in U.S. Pat. No. 8,707,758, issued on Apr. 29, 2014; U.S. Pat. No. 8,381,573, issued on Sep. 15, 2010; and U.S. application Ser. No. 13/274,553, filed on Oct. 17, 2011, the entire disclosures and contents of which are herein incorporated by reference in their entirety. Additional details of these features and others may also be found in the Appendix hereto filed herewith, the entire disclosure and content of which is herein incorporated by reference in its entirety. 
       Scheduling 
       [0038]    In order to more effectively monitor a user  200  for sobriety, in some embodiments a breath testing device  1000  preferably receives and tests the user&#39;s breath in accordance with a schedule. The schedule may be generated and/or stored by the server system  1700  in a scheduling database  1714  based on input provided by the monitor  300 . The schedule may be pushed to or accessed by the breath testing device  1000  so as to prompt the user  200  to initiate scheduled breath tests. When breath test data associated with a scheduled breath test is not received by monitoring station  1200  in accordance with the schedule, the lack of scheduled breath test may be associated with a ‘missed’ result of the breath test. 
       Test Period 
       [0039]    In an example embodiment, the schedule may be accessed and/or manipulated by the monitor  300  via the server supported website.  FIG. 3  reflects an example embodiment of an interactive web portal  1220  for a monitor  300  to generate and/or modify the schedule  1222  as displayed on a display of a user device (e.g. devices  1500  of  FIG. 1A ). As reflected in  FIG. 3 , the schedule may consist of predetermined test periods  1221 , random test periods  1223 , and/or on-demand test periods  1225 . The monitor  300  sets a predetermined test period  1221  by selecting a single or multiple date/time options for the test to occur. The monitor  300  may set multiple predetermined test periods  1221  by selecting a plurality of single dates/times for the test to occur, as shown by the Monday-Friday 4:00 pm timeslots of  FIG. 3 . In some embodiments, the system provides for selection of pre-constructed testing using testing programs stored in memory. 
         [0040]    The monitor  300  can set a random test period  1223  by selecting a single date/time option or a continuous range of date/time options—reflecting the temporal bounds within which the monitor  300  desires the breath test to randomly occur—as well as selecting the number of breath tests the monitor desires to be taken during the random test period. As the selection includes or consists of a range, it may be ‘resized’ according to the preference of the monitor  300 . The server system  1700  then randomly schedules the desired number of tests to occur during the set random test period  1223 . Preferably, if the generated schedule is a periodic schedule (e.g. weekly, bi-weekly, monthly, etc.), the randomly generated test periods  1223  are re-randomized within each set random test period for each successive schedule cycle. In the example embodiment, a period from 9:00 am-12:00 pm has been selected. 
         [0041]    In addition, or as an alternative, the monitor  300  may also select an on-demand test  1225 , reflecting a desire to schedule an immediate breath test (or as closely thereto as practical). Preferably, on-demand tests  1225  are not recycled to the next schedule cycle. 
       Test Window 
       [0042]    Additionally, for each scheduled breath test, there may exist a test window, i.e. a period of time from the inception of the test period during which the scheduled breath test can be taken by the user before the breath test is considered ‘missed’ by the system. The test window may be a default test window, or may be generated or otherwise modified by the monitor  300 , preferably via the server supported website. The monitor  300  may select from a plurality of predetermined options for the test window, including for example, 30 min, 60 min, 120 min, 180 min, 240 min, or custom duration test windows. In some embodiments, the monitor  300  may assign unique test windows to one or more of the test periods. In some embodiments, the test window may not exceed a predetermined duration. Additionally, presets can allow these windows to occur multiple times per day, week, or month. 
       Conflict Check 
       [0043]    In some embodiments, the system may perform a check for ‘conflicts’ between the scheduled test periods and test windows. For example, if test periods are scheduled for every other hour of the day with test windows of 180 minutes, then successive test periods would overlap with the test windows of the prior test period. This can be an undesirable result, as it may encourage users to perform a single breath test (or closely successive breath tests) during the overlapping period, so as to provide the user with more time before the next scheduled breath test in which to imbibe alcohol and more time in which it could be metabolized by the user without triggering an alert. This undesirable result may also occur even with merely abutting—rather than overlapping—test periods/windows. Consequently, in some embodiments, a ‘conflict’ may be determined where there is an insufficient buffer period between scheduled breath tests such that the temptation to drink alcohol is not sufficiently mitigated. 
         [0044]    Preferably in some embodiments, when a ‘conflict’ is detected, the system displays a prompt to the monitor  300  identifying the conflict as well as optional monitor actions to resolve the conflict. The optional monitor actions may include, for example, modifying one or more of the test periods and/or testing windows, and/or cancelling the proposed modification. Alternatively, one or more of these options may be automatically executed without monitor action, input or confirmation 
       User Alerts 
       [0045]    As discussed herein, the schedule may be accessed by the breath testing device  1000 , and the breath testing device  1000  may prompt a user  200  to initiate scheduled breath tests based on the schedule. The prompt may be one or more of: a visual prompt, an audio prompt, and a tactile prompt. Accordingly, as shown in  FIG. 4 , the breath testing device  1000  may comprise: a display screen  1004  for displaying a visual prompt, an audio speaker (not shown) for playing an audio prompt, and a vibrator (not shown) for producing a tactile prompt. These prompts are varied in possible nature and should be understood to those of skill in the art as being performed by the components which are operatively coupled to one or more processing units. Each of the display screen  1004 , audio speaker and vibrator can be communicatively coupled to non-transitory memory storing instructions for functions or operations thereof and a control unit including one or more processors for controlling the functions and operations by executing the stored instructions. The visual prompt may include text, images or a combination thereof, or a series of such visual prompts or combinations of visual prompts displayed on display screen  1004 . An audio prompt may include one or more different audio prompts, or a series thereof, such as sounds or language based statements or instructions. Each prompt may be stored in the memory and retrieved in accordance with the schedule using, for instance, one or more timers or time monitoring elements (not shown). 
         [0046]    In some embodiments, a prompt can be an e-mail, text message or both generated by a monitoring station  1200 , server  1700  or otherwise (e.g. the server supported website), or a combination thereof and transmitted to a stored e-mail account or cellular phone of the user  200 , monitor  300  or both. In some embodiments—particularly in those embodiments utilizing a mobile website, mobile software application (“app”) or combination of both described herein—the prompt may comprise a ‘post’ on the user&#39;s ‘wall,’ ‘feed,’ or otherwise or a message delivered to a private messaging interface of the monitor  300 . In some embodiments, the prompt may comprise an automated or live phone call to the user  200 , monitor  300 , or both. As such, prompts can generally be generated by the breath monitoring device  1000  itself or by server system  1700 . 
         [0047]    Additional details of these features and others may be found in U.S. Pat. No. 8,707,758, issued on Apr. 29, 2014; U.S. Pat. No. 8,381,573, issued on Sep. 15, 2010; and U.S. application Ser. No. 13/274,553, filed on Oct. 17, 2011, the entire disclosures and contents of which are herein incorporated by reference in their entirety. Additional details of these features and others may also be found in the Appendix hereto filed herewith, the entire disclosure and content of which is herein incorporated by reference in its entirety. 
       Testing 
       [0048]    As discussed herein with reference to  FIG. 1 , the breath testing device  1000  tests the breath of the user  200  for the presence of alcohol and/or other substances, generating breath test data in response to receiving the user&#39;s breath and analyzing it. The breath test data is then transmitted to the monitoring station  1200 , server  1700 , user device  1500 , or a combination thereof, preferably via wireless transmission over the network  1300 . 
         [0049]    During a breath test, the breath testing device  1000  receives a user&#39;s breath, analyzes the user&#39;s breath and converts this information into breath test data to be transmitted to the monitoring station  1200 , server  1700 , user device  1500 , or a combination thereof. The breath test data preferably reflects the blood alcohol content (“BAC”) of the user  200  during the breath test, or an indication of whether the user&#39;s BAC is above or below a certain BAC threshold. The BAC threshold may be set and modified by the monitor  300  via the server supported website. 
         [0050]    Additionally, the breath test data may be displayed on the breath testing device  1000  via the display screen  1004  located exterior to the device housing  1002 , as shown in  FIG. 4 , for example. Alternatively, or in addition, a visual prompt may be generated based on the breath test data and displayed on the display screen  1004  of the breath testing device  1000 , the visual prompt indicating a ‘pass,’ ‘fail,’ ‘missed,’ or ‘inconclusive’ result of the breath test. Moreover, in the event of either a ‘fail’ or ‘inconclusive’ breath test, the visual prompt may also instruct the user  200  to re-administer a breath test. 
         [0051]    Additional details of these features and others may be found in U.S. Pat. No. 8,707,758, issued on Apr. 29, 2014; U.S. Pat. No. 8,381,573, issued on Sep. 15, 2010; and U.S. application Ser. No. 13/274,553, filed on Oct. 17, 2011, the entire disclosures and contents of which are herein incorporated by reference in their entirety. Additional details of these features and others may also be found in the Appendix hereto filed herewith, the entire disclosure and content of which is herein incorporated by reference in its entirety. 
       Queueing 
       [0052]    In some instances, a breath testing device  1000  may be temporarily disconnected from the network  1300  and/or otherwise unable to transmit the breath test data, as described herein. In such instances, it is desirable for the breath testing device  1000  to store the breath test data from one or more administered breath tests until such time as the breath testing device regains network connectivity, and thereafter to transmit the breath test data to the monitoring station  1200 , server  1700 , user device  1500 , or a combination thereof. In such instances, it is also desirable that the belatedly transmitted breath test data be identifiable as in accordance with a scheduled breath test. 
         [0053]    As shown in  FIG. 2 , the breath testing device architecture  2000  may comprise the memory  1005  communicatively coupled to the breath testing module  1400  for converting the user&#39;s breath into breath test data, a clock (not shown) for generating timestamp data in association with the administered breath test, and a transceiver  1600 , each communicatively coupled to the control unit  1800  for controlling the operations thereof in accordance with the functionalities described herein. 
         [0054]    The timestamp data is preferably utilized to determine whether an associated breath test has been administered in accordance with the schedule. Accordingly, the timestamp data may be retrievably stored in the memory  1005  in association with the administered breath test, and/or transmitted to the monitoring station  1200  in association with the breath test data. 
         [0055]    When the breath testing device  1000  fails to transmit the breath test data of one or more administered breath tests to the monitoring station  1200 , as described herein, due to, for example, a lack of network connectivity, the breath testing device  1000  can store breath test data associated with one or more breath tests (and associated timestamps) in a queue in the memory  1005 , preferably according to their associated timestamps. In such event, the breath testing device  1000  may periodically retry transmitting the breath test data (and associated timestamps) stored in the queue, such that when network connectivity is re-established the data is transmitted in accordance with the embodiments described herein. 
         [0056]    In some embodiments, breath test data (and associated timestamps) are saved in the memory  1005  with a transmission status data indicating whether the breath test data has been successfully transmitted to the monitoring station  1200 . If the breath test data has been successfully transmitted to the monitoring station  1200 , as indicated by the associated transmission status data, the control unit  1800  will not retry transmitting the breath test data. Data can be updated based on confirmation or acknowledgement data sent over the network from the monitoring station  1200  or server  1700  to the breath monitoring device  1000 . However, if breath test data has not been successfully transmitted to the monitoring station  1200 , as indicated by the associated transmission status data, the control unit  1800  will retry transmitting the breath test data based on predetermined or pre-programmed rules, thresholds and timers. In some embodiments, the transmission status data identifies the number of unsuccessful attempts at transmitting the breath test data. 
         [0057]    In some embodiments, the breath test data (and associated timestamp data) may be manually retrieved if necessary. Accordingly, in some embodiments, the breath testing device  1000  may further comprise a data input/output port (not shown), such as for a USB, fire-wire, or other wired data transfer, communicatively coupled to the memory  1005  and a user interface device for accessing the data stored in the memory  1005 . The user interface device can include a variety of devices including and not limited to specialty devices, smart phones, laptop computers, desktop computers, and others as described herein and known in the art or later developed. 
         [0058]    Additional details of these features and others may be found in U.S. Pat. No. 8,707,758, issued on Apr. 29, 2014; U.S. Pat. No. 8,381,573, issued on Sep. 15, 2010; and U.S. application Ser. No. 13/274,553, filed on Oct. 17, 2011, the entire disclosures and contents of which are herein incorporated by reference in their entirety. Additional details of these features and others may also be found in the Appendix hereto filed herewith, the entire disclosure and content of which is herein incorporated by reference in its entirety. 
       Reporting 
       [0059]    The breath test data (and the other types of data described herein) may be utilized by the system to generate one or more reports based thereon. Such reports may include the breath test data (and other data) from one or more administered and/or scheduled breath tests. In some embodiments, the reports are generated automatically at specified intervals, e.g. daily, weekly, monthly, per breath test. 
         [0060]      FIG. 5  reflects an example embodiment of a report  1240  generated in accordance with the embodiments described herein. The report  1240  can include: user identification data  1242 , including a user name and, in some embodiments, a reference image  1243 ; device identification data  1244 , including a unique device identification number such as a serial number or other identifier, a device mobile number; and monitoring program data  1246 , including a program initiation date, a number of days monitored, a number of tests administered and/or submitted as well as information about whether various features (e.g. queueing and/or facial recognition) are active/enabled or inactive/disabled. The report  1240  can also include information on one or more administered and/or scheduled breath tests  1248 , including: whether the breath test was scheduled or unscheduled, the date/time of the breath test, the BrAC (Breath Alcohol Content) level of the user&#39;s breath, the test status (such as completed or incomplete), a captured image of the user (or other user identification data such as biometric fingerprinting, or others) during the breath test, and/or whether the captured image matches, corresponds or is similar to the reference image  1243 . This matching can be processed by the device  1000  itself or can be accomplished on the server  1700  or other computing devices. While the information displayed in the report  1240  of  FIG. 5  is discussed herein, it should be understood that generated reports may include more or less information, as appropriate in various embodiments. In particular, it is contemplated that the information contained in the generated reports may be customized by a monitor  300  via an interactive web portal to the server supported website. It is also contemplated that the monitor  300  may customize one or more monitoring preferences not only with regards to the information provided, but as to how the reports are transmitted and/or displayed. 
         [0061]    In some embodiments, generated reports may be accessed by the monitor  300  via an interactive web portal to the server supported website, whereby the monitor  300  may review one or more reports by accessing them online over a network  1300  (see e.g.  FIG. 1 ). In some embodiments, the generated reports may be e-mailed, text messaged or both to an e-mail account or cellular phone of the monitor  300 , user  200  or both, respectively. In some embodiments—particularly in those embodiments utilizing a mobile website and/or mobile software application (“app”) (see e.g.  FIG. 1C  Sobriety Monitoring Application  1902 ) described herein—the generated reports may comprise a ‘post’ on the user&#39;s or monitor&#39;s (or a combination of both) ‘wall,’ ‘feed,’ or otherwise. 
         [0062]    In some embodiments, the system can provide a ‘text-message’ opt-in option. When, through a registration process of creating an account, a mobile number is added to the system or otherwise updated on the website, the system identifies whether the number has previously been blacklisted or confirmed. If it has not been either blacklisted, confirmed or both, the system can transmit an invitation notification, such as a text message, to that mobile number to opt-in to receive text-message alerts and/or reports. If a monitor  300  (or user  200 ) responds to the invite with a “SUBSCRIBE” response, the mobile number can be marked as confirmed in memory and from that point forward is able to receive text messages from the system. At any time, the monitor  300  (or user  200 ) may text “STOP” to unsubscribe.  FIGS. 6A-6B  illustrate example embodiments of web portals  1220 ,  1227  respectively, whereby a monitor  300  may opt-in to receive text-message alerts and/or reports via mobile number field  1224  of web portal  1220  and a confirmation notification in web portal  1227 . 
         [0063]      FIGS. 7A, 7B and 7C  illustrate example embodiments of web portals  1228 ,  1229  and  1231  respectively whereby a monitor  300  may customize ‘alert’ preferences for a given user or users  200 . As reflected therein, these web portals  1228 ,  1229 ,  1231  contain functionality allowing the monitor  300  to: add/delete/edit monitor contact information; select for each monitor contact the circumstances (e.g. missed/failed breath tests, daily, weekly, monthly) and methods (e.g. text or email) in which the monitor contact associated with the monitor contact information will receive automated reports and/or alerts. Each of these functionalities, as well as the functionalities of other web portals may be implemented in part or in whole via monitor/user fillable fields, drop down menus and/or selectable icons  1226  and previously created contact fields  1230  which can be implemented via similar components. As shown in  FIG. 7C , a confirmation screen can be shown in a web portal  1231 . 
         [0064]    As discussed with respect to the example embodiments, generated reports may include more or less information than what is described herein, but which is nonetheless apparent to one of ordinary skill in the art as desirable for effective sobriety monitoring. Accordingly, in some embodiments, the generated reports may comprise an alert, which can be a simplified report with limited information transmitted to the monitor  300  so that the monitor  300  may be apprised of an important event such as a missed/failed breath test by a user  200 . An alert, for example, may include a text message that identifies the user  200  and the important event. Upon receiving the alert, the monitor  300  may use the monitoring station  1200  (or any of a variety of wired or mobile devices as described herein) to access the server supported website and review the full generated report having all the requested and/or provided monitoring information. As with the previously described reports, it is contemplated that the monitor  300  may customize preferences regarding the alerts not only with regards to the information provided, but as to how the alerts are transmitted and/or displayed. 
         [0065]    In some circumstances, the monitor  300  may be responsible for monitoring a plurality of users. In such circumstances, the teachings described herein are applicable to the plurality of users. Further, the generated report may be a combined report, viewable via the server supported website, containing hyperlinks or other access to the reports of each individual user  200 . 
         [0066]      FIG. 8  illustrates an exemplary combined report  1240 ( a ), comprising a table of monitored users  200  with fields for user (i.e. client) name, device activation date, number of days monitored, number of administer breath tests, number of missed/failed/late tests as well as compliant follow-up tests, and hyperlinks to downloadable reports for each user  200 . In some embodiments, the combined report may indicate—via highlighting or other visual cue—where one or more monitored user(s)  200  have failed one or more administered breath tests, so as to draw the monitor&#39;s  300  attention to those user(s)  200 . 
         [0067]    Additional details of these features and others may be found in U.S. Pat. No. 8,707,758, issued on Apr. 29, 2014; U.S. Pat. No. 8,381,573, issued on Sep. 15, 2010; and U.S. application Ser. No. 13/274,553, filed on Oct. 17, 2011, the entire disclosures and contents of which are herein incorporated by reference in their entirety. Additional details of these features and others may also be found in the Appendix hereto filed herewith, the entire disclosure and content of which is herein incorporated by reference in its entirety. 
       Additional Data Based Features 
       [0068]    In addition to the breath test data, in various embodiments other data may also be transmitted to the monitoring station  1200 , server  1700  and devices  1500  (and/or included in the report), including but not limited to: user-identification data (as further described herein), device location data, breath test timestamp data, anti-cheating data and/or device status data (including device connectivity, calibration and/or security data). Importantly, these categories of data types are supplied for illustrative purposes only, and it should be understood that the generated data referred to herein may belong one or more (or other) of these data types. It will be understood by one of ordinary skill in the art that wherever the transmission of breath test data is herein described, such descriptions may also apply to the transmission of other data described herein. 
       User Verification Features 
       [0069]    User identification data for a particular user  200  can include or consist of data utilized by the system to verify the identity of the user  200  taking a breath test using a particular breath monitoring device  1000 . The user identification data may comprise one or more of: image data, video data, biometric data (e.g. fingerprint, DNA, retinal scan, etc. data), username/password entry data, or any other type of data that may be used to verify the identity of the user taking the breath test (see, e.g.  FIG. 5 ). This verification is useful to make it more difficult for non-users to administer the scheduled breath test (to themselves) in lieu of the particular monitored user  200 , i.e. to curtail cheating. Where the user identification data indicates that a non-user has administered the scheduled breath test in lieu of the user  200 , the breath test report generated therefrom may identify the administered breath test as a ‘fail’ event. In some embodiments, this can trigger unique “attempted cheating” alerts. 
         [0070]    As reflected for example in  FIG. 4 , in some embodiments, a breath testing device  1000  comprises a test interface  1010  (see e.g. breath intake  1020  of  FIG. 9 ), for receiving the user&#39;s breath during the scheduled breath test, and a camera or imager  1006  substantially adjacent the breath intake or otherwise positioned so as to capture an image of the user  200  during a breath test. Preferably, the camera  1006  is equipped with a lens capable of capturing the entire face of the user at close distances, such as a fish-eye lens. The captured image may be converted into image data to be transmitted to the monitoring station  1200 , stored by server  1700  and/or utilized to verify the identity of the user taking the breath test. 
         [0071]    Additional details of these features and others may be found in U.S. Pat. No. 8,707,758, issued on Apr. 29, 2014; U.S. Pat. No. 8,381,573, issued on Sep. 15, 2010; and U.S. application Ser. No. 13/274,553, filed on Oct. 17, 2011, the entire disclosures and contents of which are herein incorporated by reference in their entirety. Additional details of these features and others may also be found in the Appendix hereto filed herewith, the entire disclosure and content of which is herein incorporated by reference in its entirety. 
       Other Anti-Cheating Features 
       [0072]    In an example embodiment, anti-cheating data includes or consists of data verifying that the breath testing device  1000  (or the administered breath test itself) has not been interfered with in a way that would compromise the veracity of the breath test. The anti-cheating data may include or consist of breath characteristics data, component integrity data, image data, or any other type of data that may be used to verify that the breath testing device  1000  (or the administered breath test itself) has not been interfered with in a way that would compromise the veracity of the administered breath test. Where the anti-cheating data indicates the breath testing device  1000  (or the administered breath test itself) has been interfered with in a way that would compromise the veracity of the breath test, the breath test report generated therefrom may identify the administered breath test as a ‘fail’ event or, additionally or alternatively, as an ‘attempted cheating’ event. 
       Breath Characteristic Data 
       [0073]    In some embodiments, the breath testing device  1000  comprises one or more sensors for determining characteristics of the user&#39;s breath such as pressure (see e.g.  FIG. 2  pressure sensor(s)  1404 ) and/or temperature (see e.g.  FIG. 2  Temp sensor Breath+Ambient  1408 ), which may be utilized to generate breath characteristic data. The breath characteristic data may in turn be utilized to determine whether the breath testing device  1000  has been tampered or otherwise interfered with in a way that would compromise the breath testing data. 
         [0074]      FIG. 9  illustrates a schematic diagram of an exemplary breath intake  1020  comprising: an input pressure sensor  1021 , an output pressure sensor  1022 , an ambient temperature sensor  1023 , a breath temperature sensor  1024 , a fuel cell  1025 , a sample pump  1026  and a breath chamber  1027 , including an input chamber  1027 ( a ) partially separated from an output chamber  1027 ( b ) by a pressure orifice  1028 . As shown in  FIG. 9 , various components can be isolated or coupled with each other and/or breath areas as necessary. In an example embodiment, a user  200  breathes into input chamber  1027 ( a ) and the breath leaves the device  1000  via output chamber  1027 ( b ). 
         [0075]    In some embodiments, the breath temperature sensor  1024  can detect the temperature of an airflow during an administered breath test, while an ambient temperature sensor  1023  can detect an ambient temperature of non-tested air, isolated from the breath flow. The pressure sensors  1021  and  1022  can detect the pressure of an airflow between the input side  1027 ( a ) and the output side  1027 ( b ) of chamber  1027  of breath applied during an administered breath test. Each of these components may be individually or collectively used to detect airflow tampering by a user  200 . 
         [0076]    As an example, human breath is generally no colder than thirty-three degrees Celsius, while compressed air from a container or other source may be significantly colder. Should a user  200  attempt to tamper with a scheduled breath test by ‘blowing’ into the breath testing device  1000  with compressed air, the breath temperature sensor may generate breath characteristic data indicating that the breath testing device has been tampered with accordingly. Moreover, the ambient temperature may be measured by ambient temperature sensor  1023  and used to further verify ‘human breath’ is being applied by comparing a measured temperature value with a temperature value measured by the breath temperature sensor  1024  using a processor and comparing with a threshold, range or other set of values to verify accuracy. For example, human respiration typically heats human breath temperature to at least fifteen degrees Celsius. If a measured ambient temperature is between ten and fifteen degrees Celsius, human respiration typically heats the breath temperature to at least twenty degrees Celsius. If the ambient temperature is above fifteen degrees Celsius, human respiration typically heats the breath temperature to at least twenty-eight degrees Celsius. When the ambient temperature is above thirty-three degrees Celsius, human respiration measured by the breath temperature sensor will typically be cooler than the ambient temperature. The temperature sensors  1023 ,  1024  may also be coupled with or include timers (not shown) detect time variances in temperature. Such time variances may indicate, for example, the presence of a heated air source that is heating up. 
         [0077]    As an additional example, should a user block airflow from the output side  1027 ( b ) of chamber  1027  to an exterior of the device  1000 , the pressure in the output side  1027 ( b ) of chamber  1027  would tend to increase relative to the pressure in the input side  1027 ( a ) of the chamber  1027 . The pressure sensors  1021 ,  1022  may detect this tampering and, when compared using a processor and programmed thresholds, ranges or other sets of values, generate breath characteristic data that indicates this tampering accordingly. 
       Image Data—Blue Ring, etc. 
       [0078]    As reflected for example in  FIG. 4 , in some embodiments, a breath intake of a test interface  1010  can comprise structural components whose images are captured by a camera  1006  during a breath test to verify the veracity of the breath test. 
         [0079]    In some embodiments, this can comprise a transparent mouthpiece  1010  into which a user  200  blows to administer a breath test. During the breath test, the mouthpiece  1010  may become more opaque upon exposure to the user&#39;s breath, an image of such transformation being captured by the camera  1006  and converted into image data to be transmitted to the monitoring station  1200 , stored by server  1700  and/or utilized to determine whether the user  200  is faithfully performing the breath test, i.e. is not cheating. The mouthpiece  1010  may also comprise an indicator  1008 , such as a ring, spot or other indicator, configured to illuminate during a breath test, such illumination to be captured by the camera  1006  during the breath test. In some embodiments, the indicator  1008  may be formed of a material that reacts to a light source on or within the breath testing device  1000 , the light source activating during the scheduled breath test. The image data may be transmitted to the monitoring station  1200 , server  1700 , and/or user devices  1500  in association with the breath test data and utilized by monitoring station  1200 , server  1700 , and/or user devices  1500  to confirm the veracity of the administered breath test. Alternatively, or additionally, the breath testing device may utilize the image data to confirm the veracity of the administered breath test. 
         [0080]    In some embodiments the light source or indicator  1008  may change colors if a user passes or fails an administered breath test based on temperature, BrAC, pressure or other measurements. 
       Breath Counting 
       [0081]    In some embodiments, the breath testing device  1000  tracks a blow count reflecting the number of administered breath tests. The breath testing device  1000  generates blow count data from the tracked blow counts, and utilizes the blow count data to confirm the veracity of the administered breath test. 
         [0082]    Accordingly, in some embodiments, the breath testing device  1000  may comprise a counter coupled to the breath testing module that registers a count during the administered breath test. In some embodiments, the breath testing module may comprise a pump (see, e.g. pump  1402  of  FIG. 2 ) that engages when the air flowing through the pump  1402  exceeds a predetermined pressure. The counter may be coupled to the pump such that when the pump  1402  engages, the counter registers a count. 
         [0083]    The monitoring station  1200 , server  1700 , and/or user devices  1500  may also track the number of received breath test data transmissions to compare against the blow count of the breath testing device  1000 . The breath testing device  1000  may also transmit blow count data to the monitoring station  1200 , server  1700 , and/or user devices  1500  to be compared with the tracked number of received breath test data transmissions. In this manner, the monitor  300  may determine whether the cause of a missed breath test is because the breath test was not properly administered, or because the breath test data was not transmitted to the monitoring station  1200 , server  1700 , and/or user devices  1500  correctly. 
         [0084]      FIG. 10  illustrates an exemplary logic flow-chart for counter operation. At the initiation of the breath test sequence (Step  2020 ), the breath testing device checks for errors (Step  2040 ). If an error is detected, the device displays an error message (Step  2042 ) on the device display and then returns to an idle state (Step  2060 ). If no errors are detected, the counter is incremented (Step  2080 ), the breath test data is transmitted (Step  2100 ), and the device returns to the idle state (Step  2060 ). In some embodiments, the counter tracks the number of administered breath tests since the breath testing device  1000  was initiated, as well as the number of administered breath tests since the breath testing device  1000  was last calibrated. Accordingly, when the breath testing device  1000  is calibrated, the count value for the number of administered breath tests since the breath testing device  1000  was last calibrated may be reset. 
         [0085]    In addition to monitoring the user  200 , the blow count data may be utilized to track the reliability of the breath testing device  1000  for the purposes of maintenance, replacement or others. 
       Timestamps 
       [0086]    As described herein, in some embodiments timestamp data may be generated from a clock in association with an administered breath test using breath testing device  1000 . The timestamp data reflects the time and/or date in which the breath test was administered, and may be transmitted to the monitoring station  1200 , server  1700 , and/or user devices  1500  in association with the administered breath test data. 
         [0087]    In some embodiments, a monitoring station  1200 , server  1700 , and/or user devices  1500  operate(s) according to a default time, e.g. UTC time, while the breath testing device  1000  operates according to the clock time. In some embodiments, during a period of connectivity, a clock time may be reset to match the default time. In such circumstances, any timestamp data transmitted prior to the reset may be prorated to generate a modified timestamp reflecting the date/time of the administered breath test according to the default time. For example, when a periodic ‘check-in’ occurs and it is determined that the clock time is—for example—5 seconds behind the default time, the timestamp data for the associated breath tests transmitted at the ‘check-in’ is modified by that 5 second discrepancy to reflect the time of the administered breath test according to the default time. In this manner, the timestamp data for each administered breath test stored by the monitoring station  1200 , server  1700 , and/or user devices  1500  is according to a uniform date/time standard, e.g. the default time. 
       Device Location Features 
       [0088]    Device location data in some embodiments includes or consists of data utilized by the system to establish the geographical location of a breath testing device  1000 . The device location data may comprise one or more of: global positioning system (“GPS”) data, Assisted GPS (“A-GPS”) data, and Advanced Forward Link Trilateration (“AFLT”) data. Many appropriate hardware/software components for generating the aforementioned device location data are known in the art. The device location data may be useful to verify the location of the user  200  during an administered breath test. Additionally, the device location data may be useful to verify the location of the breath testing device  1000  in the event it becomes lost or otherwise misplaced. Accordingly, the device location data may be transmitted to the monitoring station  1200 , server  1700 , and/or user devices  1500  independent of some or all breath test data, for example, during a periodic check-in with the monitoring station  1200 , server  1700 , and/or user devices  1500 . 
         [0089]    In some embodiments, location data is utilized by monitoring station  1200 , server  1700 , and/or user devices  1500  to record the geographic location of the breath testing device  1000  and in can be stored on monitoring station  1200 , server  1700 , and/or user devices  1500 . The monitor  300  (and/or user  200 ) may access the location data via the interactive web portal, so as to track the location of the breath testing device  1000  at least when the device  1000  is administering a test. In this manner, the monitor  300  (and/or user  200 ) may determine the location of the breath testing device  1000 . This feature may be useful to, for example, locate misplaced breath testing devices  1000 , or track the location of the user  200 , for example, if the user  200  is on house-arrest or some other form of detention. 
         [0090]    Additional details of these features and others may be found in U.S. Pat. No. 8,707,758, issued on Apr. 29, 2014; U.S. Pat. No. 8,381,573, issued on Sep. 15, 2010; and U.S. application Ser. No. 13/274,553, filed on Oct. 17, 2011, the entire disclosures and contents of which are herein incorporated by reference in their entirety. Additional details of these features and others may also be found in the Appendix hereto filed herewith, the entire disclosure and content of which is herein incorporated by reference in its entirety. 
       Device Status Features 
       [0091]    Device status data can include or consist of data reflecting the operation status and parameters of the breath testing device  1000 . As discussed herein, the breath testing device  1000  may periodically connect to a monitoring station  1200 , server  1700 , and/or user devices  1500  via the network  1300  so as to transmit—or otherwise exchange—data therewith. During this data transmission, the breath testing device  1000  may the transmit device status data to the monitoring station  1200 , server  1700 , and/or user devices  1500 , which may include, for example, calibration data and/or security data. 
         [0092]    In some embodiments, the periodic ‘check-in’ may occur according to predetermined time intervals. For example, the ‘check-in’ may coincide with the scheduled breath test. Alternatively, or in addition thereto, the ‘check-in’ may occur according to a schedule as, for example, every few hours, or minutes. In some embodiments, the periodic ‘check-in’ may occur every 5 minutes. However, if the ‘check-in’ fails, for example, due to failed network connectivity, the subsequent ‘check-in’ may be rescheduled according to one or more backup time intervals. For example, if the 5 minute check-in fails, the ‘check-in’ period may be reset to occur every 15 minutes, 30 minutes, or 60 minutes. In this way, the breath testing device  1000  may conserve battery life during extended periods of connectivity. In some embodiments, when connectivity is reestablished, the ‘check-in’ period may be automatically reset to the default period. 
         [0093]    As discussed herein, during the ‘check-in,’ any data stored in device  1000  memory to be transmitted may be transmitted to a monitoring station  1200 . 
         [0094]    Additional details of these features and others may be found in U.S. Pat. No. 8,707,758, issued on Apr. 29, 2014; U.S. Pat. No. 8,381,573, issued on Sep. 15, 2010; and U.S. application Ser. No. 13/274,553, filed on Oct. 17, 2011, the entire disclosures and contents of which are herein incorporated by reference in their entirety. Additional details of these features and others may also be found in the Appendix hereto filed herewith, the entire disclosure and content of which is herein incorporated by reference in its entirety. 
       Portable Calibration Station 
       [0095]    It may be desirable that a breath testing device  100  be calibrated so as to maintain overall device  1000  and component reliability in some embodiments. 
         [0096]    In many embodiments, device  1000  calibration may occur during a period of connectivity with s monitoring station  1200 , e.g. the status check, as described herein. During device  1000  calibration, calibration data may be exchanged between the breath testing device  1000  and the monitoring station  1200  via wireless or wired communications. The calibration data may indicate whether the breath testing device  1000 , and/or its component parts, is functioning as desired, as well as identify which—if any—errors are detected due to mis-calibration or tampering. The calibration data may also be utilized by the system to re-calibrate any mis-calibrated or tampered with components. For example, in some embodiments, a breath testing device clock may during calibration be reset to the time standard used by the monitoring station  1200 , e.g. the current Coordinated Universal Time (“UTC”). System updates for the device  1000 , such as software updates, may also be implemented during calibration. 
         [0097]    In some embodiments, device  1000  calibration may occur via a calibration station  3000 , such as for example shown in  FIG. 12 , which may be used by a monitor  300  to perform breath testing device calibrations, i.e. to calibrate the breath testing device  1000 . Preferably, the calibration station  3000  is a portable calibration station. Additional details of these features and others may be found in U.S. Pat. No. 8,707,758, issued on Apr. 29, 2014; U.S. Pat. No. 8,381,573, issued on Sep. 15, 2010; and U.S. application Ser. No. 13/274,553, filed on Oct. 17, 2011, the entire disclosures and contents of which are herein incorporated by reference in their entirety. Additional details of these features and others may also be found in the Appendix hereto filed herewith, the entire disclosure and content of which is herein incorporated by reference in its entirety. 
       Bluetooth 
       [0098]    In some embodiments, a breath testing device  1000  may transmit the breath test data to an intermediary device, such as cellular phone, which in turn transmits the breath test data to a monitoring station  1200  via a network  1300  as shown for example in  FIG. 1 . Accordingly, a local network may comprise a personal-area-network (“PAN”), and the transceiver may comprise a personal-area-network transceiver (e.g. transceiver  1600  of  FIG. 2 ). This can be part of or separate from network  1300 . 
         [0099]    As shown for example in  FIG. 11 , a breath testing device  1000  may comprise a PAN module  1601  driven by a driver module and communicatively coupled to an intermediary device, such as a smartphone  2060 . The intermediary device  2060  is in turn coupled to a monitoring station  1200  or other server  1700  via a wireless network over a cellular and/or Wi-Fi Internet Connection  1301 . The PAN module  1601  and driver functionalities described herein may be controlled by a control unit (see e.g. processor  1800  of  FIG. 2 ) executing software instructions retrievably stored in a non-transitory device memory. 
         [0100]    In the example embodiment a device application  1902  can be stored in device memory and is associated with a data exchange module  1904  and proxy command set  1906  which combine to form a data module  1900 . This data module  1900  can communicate with a Bluetooth driver  4002  and RS232 logic level module  4004  that combine to form a transmission control module  4000 . Transmission control module can communicate via Bluetooth module  1602  which can include at least a Bluetooth transceiver  1602  communicating using Bluetooth protocol via connection with a Bluetooth transceiver of smartphone  2060  (not shown). 
         [0101]    Additional details of these features and others may be found in U.S. Pat. No. 8,707,758, issued on Apr. 29, 2014; U.S. Pat. No. 8,381,573, issued on Sep. 15, 2010; and U.S. application Ser. No. 13/274,553, filed on Oct. 17, 2011, the entire disclosures and contents of which are herein incorporated by reference in their entirety. Additional details of these features and others may also be found in the Appendix hereto filed herewith, the entire disclosure and content of which is herein incorporated by reference in its entirety. 
         [0102]    The enablements described in detail above are considered novel over the prior art of record and are considered critical to the operation of at least one aspect of the invention and to the achievement of the above described objectives. The words used in this specification to describe the instant embodiments are to be understood not only in the sense of their commonly defined meanings, but to include by special definition in this specification: structure, material or acts beyond the scope of the commonly defined meanings. Thus if an element can be understood in the context of this specification as including more than one meaning, then its use must be understood as being generic to all possible meanings supported by the specification and by the word or words describing the element. 
         [0103]    The definitions of the words or drawing elements described herein are meant to include not only the combination of elements which are literally set forth, but all equivalent structure, material or acts for performing substantially the same function in substantially the same way to obtain substantially the same result. In this sense it is therefore contemplated that an equivalent substitution of two or more elements may be made for any one of the elements described and its various embodiments or that a single element may be substituted for two or more elements. 
         [0104]    Changes from the claimed subject matter as viewed by a person with ordinary skill in the art, now known or later devised, are expressly contemplated as being equivalents within the scope intended and its various embodiments. Therefore, obvious substitutions now or later known to one with ordinary skill in the art are defined to be within the scope of the defined elements. This disclosure is thus meant to be understood to include what is specifically illustrated and described above, what is conceptually equivalent, what can be obviously substituted, and also what incorporates the essential ideas. 
         [0105]    Furthermore, the functionalities described herein may be implemented via hardware, software, firmware or any combination thereof, unless expressly indicated otherwise. If implemented in software, the functionalities may be stored as one or more instructions on a computer readable medium, including any available media accessible by a computer that can be used to store desired program code in the form of instructions, data structures or the like. Thus, certain aspects may comprise a computer program product for performing the operations presented herein, such computer program product comprising a computer readable medium having instructions stored thereon, the instructions being executable by one or more processors to perform the operations described herein. It will be appreciated that software or instructions may also be transmitted over a transmission medium as is known in the art. Further, modules and/or other appropriate means for performing the operations described herein may be utilized in implementing the functionalities described herein. 
         [0106]    The scope of this description is to be interpreted only in conjunction with the appended claims and it is made clear, here, that the named inventor believes that the claimed subject matter is what is intended to be patented.