Patent Description:
No aspect of these documents is intended to be limiting in any way. The scope of the invention remains defined by the claims of this Application. These Included Documents are additive in nature, and can be combined with the technical matter described herein, in whole or in part.

Each document description includes, where applicable, its Application Serial Number, Filing Date, and First Inventor:.

This Application generally relates to enuresis amelioration, alerts, and training, and similar issues.

For one example, this Application includes information relating to sensing, alerting and signaling, analysis and reporting, patient care and sensor care, statistical and other review of data relating to alerts and signals, and other sensing or treatment functions; with respect to enuresis, other medical fluids, other electrolytes, and other sensed events. For another example, this Application includes information relating to server communication, sensor identification, telemetry and data backup, system maintenance and customer assistance, business methods, and other system functions; with respect to sensors, receivers of alerts and signals, data relating to alerts and signals, and other system apparatus or methods.

Other and further possibilities are described herein.

The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived. Therefore, unless specifically indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.

Enuresis (sometimes referred to as "bedwetting") is the event when a patient loses bladder control during sleep, and voids urine into their underclothes, clothes, or bedding. This is sometimes referred to herein as a "wetting event. " A caregiver should be available to wake the patient, send them to a restroom, and assist them in replacing any wetted objects, and assist them in returning to sleep. Typically the patient will be a child, in which case the wetting might be an isolated event; however, when wetting events are chronic, the caregiver, who will typically be a parent or guardian, will wish to assist the child in learning to awake in time to arrive at the restroom and avoid a wetting event. The patient could also be an adult, such as a post-menopausal woman, an elderly person, a post-surgical patient, or another person lacking bladder control, for each of whom enuresis might be a relatively temporary or a more extended problem. In such cases, the caregiver might be a hospital nurse, a practical nurse, a volunteer, a close relative, or another person.

To assist the patient in waking quickly, and to assist the caregiver in reaching the patient quickly, the patient and caregiver can use an enuresis alert system. Typically, an alert system includes a sensor and an alerting device. The sensor would detect the wetting event, and trigger the alerting device. The alerting device would, in response to the sensor, present an alert to the patient or to the caregiver. In such cases, the alert system would either wake the patient directly, or would inform the caregiver, so that the caregiver could wake the patient and assist the patient as described. For example, the sensor would include an electrical circuit that is completed by the presence of urine (or other electrolytes), thus providing an electrical trigger to the alert. Also for example, the alerting device would include an audible alarm that sounds when triggered by the sensor. The alarm would either wake the patient directly, or would inform the caregiver that a wetting event has occurred, so that the caregiver can provide patient care.

Enuresis alert systems are typically available in one of two types: wired or wireless. Wired alert systems couple the sensor directly to the alerting device, while wireless alert systems couple the sensor to a wireless transmitter, which sends a wireless signal to a wireless receiver, which is coupled directly to the alerting device. Wired systems have the disadvantage of being uncomfortable for the patient, and the further disadvantage of requiring a relatively loud alarm to inform the caregiver. Wireless systems mostly avoid these disadvantages, but at the cost of having the disadvantage of being substantially more expensive, the further disadvantage of operating in a relatively noisy portion of the EM (electromagnetic) spectrum, and the further disadvantage of draining battery power even when only awaiting their trigger. If noise in the EM spectrum is too great, sensor alerts could be lost, or spurious sensor alerts could occur. If battery power is drained too much, the alerting system could be insufficiently loud, or could fail completely.

One problem with some known enuresis alert systems is that, when a wetting event occurs, urine could cause corrosion with the sensor's contacts, particularly when electrical current continues to be coupled to those contacts. Thus, wetting events could involve the patient or caregiver removing the sensor while the patient is concurrently rapidly attending the restroom. This could be both complex and subject to mistakes. This problem is exacerbated when the enuresis alert systerns includes a wired coupling between the sensor and the alerting device, as the wiring itself can present an obstacle to the patient or caregiver.

Another problem with some known enuresis alert systems is that, when a wetting event occurs and the patient is alerted, it is desirable for the patient to wake quickly, such as to limit the amount of wetting due to the wetting event. While known enuresis alert systems terminate their alarms in response to disconnection by the patient, they do not record the amount of time taken by the patient to wake and disconnect the alarm, nor do they record the progress---if any---by the patient in waking more quickly in response to the alarm. Superior alacrity by the patient has advantages that known enuresis alert systems do not promote.

Another problem with some known enuresis alert systems is that, when a wetting event occurs, only the patient or only the caregiver is alerted; that is, only one, not both, are alerted. With wired systems, only the patient would be alerted, unless the alerting system is so loud that it can be heard several rooms away. With wireless systems, the sensor might be coupled, similar to wired systems, to alert only the patient or to alert only the caregiver. Alternatively, wireless systems could couple the sensor to alert more than one person, but with the drawback that wireless receivers for alerting devices could be relatively expensive.

Another problem with some known enuresis alert systems is that, when a wetting event occurs, the caregiver typically wishes to record the event. However, due to the desire for rapid response and for substantially cleaning effort, it could occur that the wish to record the event is forgotten, or that data with respect to the event are not recorded accurately or precisely. Recording the wetting event could be important: The amount of time that the patient avoids a wetting event is generally considered, for children, to be about <NUM> consecutive days. Moreover, the record of wetting events could be used for predicting future events, and for avoiding those future events.

Another problem with some known enuresis alert systems is that it can be desirable to train the patient (such as a child) to respond rapidly to a wetting event. Thus, it might be desirable for the child to wake immediately, turn off the alarm, and continue any further urination in a restroom. One measure of progress (such as by the child) in avoiding future wetting events, might include a measure of speed in responding to a wetting event, such as an amount of time the child takes in performing these steps. However, as with recording the event itself, it could occur that the wish to time the speed of response, and the wish to record that timing information, might be forgotten, or that data with respect to the event are not recorded accurately or precisely.

Another problem with some known enuresis alert systems is that it can be difficult for a user of the system to obtain customer service. First, the user's request for customer service would come within ordinary business hours. Second, the user's request would involve contacting a human being at customer service, providing information to identify the user and their equipment, and providing information to identify the problem. Third, customer service might involve technical support, such as in the form of a trouble ticket. The request could involve several days of effort, which could involve restarting the patient's training to avoid wetting events from the beginning.

<CIT>) discloses a patient activity monitoring (PAM) system with customizable alarms indicating a patient's status, including incontinent events. In the event the patient requires immediate assistance, the PAM system alerts an associated pager.

If the primary caregiver assigned to that pager does not respond, the PAM system initiates a secondary page to a back-up caregiver. The document <CIT> does not disclose the alert processor being configured to immediately direct the alert signal to the secondary caregiver without waiting for the primary caregiver to respond, if more than one wetting event is occuring concurrently.

Each of these issues, either alone or in combination with others (whether mentioned herein or otherwise), at some times, or in some conditions, can cause one or more problems with respect to enuresis amelioration, alerts, and training, with respect to similar and other matters, or with respect to some combination or conjunction thereof.

This Summary is provided to introduce one or more concepts, in a simplified form, otherwise and further described in this Application. This Summary does not intend to specify particular features of the claimed subject matter, nor does this Summary intend to be used to determine the scope of the claimed subject matter.

This Application provides patentable subject matter that can ameliorate the problems described above, as well as others.

Aspects and preferred features are set out in the accompanying claim. The scope of the invention is defined by the appended claim <NUM>.

There is provided an apparatus including an alert processor, having an input port disposed to receive a signal output from a sensor in response to a fluid exiting a body of a patient, having instructions determining whether the signal output from the sensor indicates a wetting event, and having an output port disposed to send an alert signal in response to the wetting event; an alert presenter including an alarm responsive to the alert signal.

The alarm may be responsive to one or more of: a set of multiple patients subject to wetting events.

The alert processor has access to second instructions, the second instructions directing the alert signal to at least one or more of a set of alert presenters.

Aspects can be combined and it will be readily appreciated that features described in the context of one aspect can be combined with other aspects.

After reading this Application, those skilled in the art would recognize that many variations of techniques shown in this Application are possible that would be workable, and would not require undue experiment or further invention. The characteristics and possible utility of the embodiments described in this Application are not all-inclusive.

Those skilled in the art would recognize both additional advantages and additional features beyond those explicitly shown or suggested in this Application.

After reading this Application, those skilled in the art would also recognize that techniques shown in this Application are applicable to more than just the specific embodiments shown herein. The examples described herein are not intended to be limiting in any way. One or more combinations of these examples, in whole or in part, are also possible.

For one example, the system can be configured to detect biological electrolytes other than urine. Some examples include those found in blood, fecal matter, lymph, mucus, pus, saliva, skin oils, spinal fluid, sweat, tears, vomit, and other bodily substances. In one such case, the system can be configured to detect and inform the patient about onset of menses.

For another example, the system can be configured to detect non-biological electrolytes. Some examples include those found in alcohol, juices, water and other drinking materials, and other foods and non-foods.

These examples are not exclusive from other uses. Instead, they are meant to describe one or more possible applications of systems, methods, devices, and other techniques shown in this Application.

In the figures, like references generally indicate similar elements, although this is not strictly required by the text.

After reading this Application, those skilled in the art would recognize that the figures are not necessarily (<NUM>) drawn to scale for construction, or (<NUM>) specify any particular location or order of construction. After reading this Application, those skilled in the art will recognize that many alternatives, in construction, shape, size, and otherwise, would allow them to make and use the invention, without undue experiment or further invention.

Ideas and technologies shown or suggested by this Application should be thought of in their most general form, including without limitation, considering one or more of the following:
The phrases and terms "Application," "this Application," "this Disclosure," and variants thereof, generally refer to this Specification, Drawings, Figures, and Claims, all other parts of this Application, and all facts known in the art at the time of filing, and all facts that can be rationally concluded therefrom.

The phrases and terms "disposed," "disposed for," "disposed to," and variants thereof, generally refer to the possibility that a particular element, collection of elements, portion of an element, or linkage between or among elements, is capable of (and optionally, well suited to) performing the described activity.

The phrases and terms "in one example," "in one embodiment," "in one implementation," "in one scenario," "in possible examples," "in possible embodiments," "in possible implementations," "in possible scenario," and variants thereof, generally refer to the possibility that a particular characteristic, feature, or structure, described herein is included in at least one possible embodiment of the invention. Multiple uses of this phrase do not necessarily all refer to the same possible embodiment. Rather, the specific particular characteristic, feature, or structure, described herein might be combined in any suitable manner into one or more distinct possible embodiments.

The phrases and terms "perform," and variants thereof, generally refer (in the context of a program of instructions) any one or more means by which those instructions are executed or interpreted, or a device (such as a computing device) otherwise conducts the process indicated by that program of instructions. A program of instructions can be detected or interpreted at one location, and executed or its process conducted at another location. A program of instructions can be performed by a portion of a device, rather than the entire device, or by one or more devices, or by one or more portions of devices (the same device or different devices). A program of instructions can be performed by an emulated device, such as a virtual machine, "sandbox" environment, or otherwise. A program of instructions can be performed in part, halted or paused or stopped, transferred to another device, in whole or in part, and possibly continued.

The phrases and terms "relatively," and variants thereof, generally refer to any relationship in which a comparison is possible, including without limitation "relatively less," "relatively more," and otherwise. In the context of the invention, where a measure or value is indicated to have a relationship "relatively," that relationship need not be precise, need not be well-defined, and need not be by comparison with any particular or specific other measure or value. For one example, whenever a measure or value is "relatively increased" or "relatively more," that comparison need not be with respect to any known measure or value, but might be with respect to a measure or value held by that measurement or value at another place or time, or with respect to a measure or value commonly used in the art.

The phrases and terms "substantially," and variants thereof, generally refer any circumstance in which a determination, measure, value, or otherwise; is equal, equivalent, nearly equal, nearly equivalent, or approximately; what the measure or value is recited to be. For example, the phrases and terms "substantially all," and variants thereof, generally refer to any circumstance in which all, except possibly a relatively minor amount or number, have the stated property. For example, the phrases and terms "substantially none," and variants thereof, generally refer any circumstance in which none, except possibly a relatively minor amount or number, have the stated property. For example, the phrases and terms "substantial effect," and variants thereof, generally refer any circumstance in which an effect might be detected or determined.

The phrases and terms "techniques," and variants thereof, generally refer to any material suitable for description, including without limitation all such material within the scope of patentable subject matter. Whenever a method step is described, those skilled in the art would know, without further invention or undue experiment, that this application thereby also describes (<NUM>) at least a first product, such as one maintaining instructions that are interpretable by a computing device, where those instructions direct one or more devices to perform that method step; and (<NUM>) at least a second product, such as one capable of performing that method step.

The phrases and terms "alarm," "alert," "signal," and variants thereof, can generally refer to any technique for informing a patient, caregiver, or other person, regarding a wetting event, or recording information relating thereto. For example, an alarm can include a sound (such as a buzzer or noise), a visible signal (such as a flashing screen or other light), a haptic signal (such as shaking or vibration), or another type of detectable information.

The phrases and terms "caregiver," and variants thereof, can generally refer to any person with the task of assisting or caring for a patient, as that term is described herein, in the event of a wetting event. A caregiver can also be assigned the task of waking the patient to prevent a wetting event, dealing with the consequences of a wetting event, or other related tasks.

The phrases and terms "instructions," can generally refer to any information that can be understood by a processor to perform operations. For example, "instructions," can generally refer to directions to perform operations, to data used in those operations, and to other signals that might be used by a processor. When applied thereto, the phrases and terms "execute," "interpret," and variants thereof, generally refer to operation of a processor, in response to those instructions, to perform those operations.

The phrases and terms "patient," and variants thereof, can generally refer to any person for whom enuresis, bedwetting, wetting events, for whom other leakage of fluids is being detected, or related events. More generally, these phrases and terms can generally refer to any person or persons for whom a sensor is to be used to detect an event. For example, a sensor can be used to detect when a person falls asleep or awakens, has their temperature or blood pressure meet selected criteria, or other events of interest.

The phrases and terms "publish," and variants thereof, can generally refer to any event during which information is sent from one entity (such as a first device or person) to another entity (such as a second device or person). For example, an alert or other signal can generally be published by the alert processor to one or more alert presenters, possibly including one or more of: a patient, a primary caregiver, a backup caregiver, a supervisory caregiver, and storage.

The phrases and terms "user" and variants thereof, generally refer any one or more persons, devices, software elements, or groups thereof, authorized or capable of interacting with one or more portions of a system disclosed herein, or authorized or capable of triggering one or more steps of a method disclosed herein. For example, a "user" can include one or more persons; one or more programs disposed to make requests of, and receive responses from, the system; one or more software elements disposed to control the system or method; an artificial intelligence or machine learning technique capable of interacting with the system or method; or combinations or conjunctions thereof.

The phrases and terms "wetting event," and variants thereof, can generally refer to any event in which enuresis, bedwetting, for whom other leakage of fluids, occurs, or any related events. More generally, these phrases and terms can generally refer to any proximate cause or result of any such event, such as any time relaxation of muscles, opening of strictures or wounds, or leakage of fluids occurs, whether or not immediately detected.

<FIG> shows a conceptual drawing of a system.

A system <NUM> can include elements shown in the figure, such as at least the following: a sensor <NUM>, a transceiver <NUM>, an alert processor <NUM>, an alert presenter <NUM>, a server <NUM>, and other elements necessary or convenient to give effect to the functions described herein.

In one embodiment, the system <NUM> is usable by a patient <NUM>, one or more caregivers <NUM>, one or more operators <NUM>, and with a server interface <NUM>.

The sensor <NUM> can include elements shown in the figure, such as at least the following: an electrical circuit <NUM>, a replaceable test strip <NUM>, an (optional) clamp <NUM>, an output node <NUM>, and a waterproof cover <NUM>. A bodily exit <NUM> for urine (or another electrolyte) is not part of the sensor <NUM>, but would typically be associated with a patient. Although the test strip <NUM> is referred to herein as "replaceable," it can be "disposable," in the sense that a used test strip <NUM> can be disposed of (such as in a trash can or other receptacle, after a wetting event) and a new test strip <NUM> can be incorporated into the electrical circuit <NUM> instead of the old test strip <NUM>. In this context, the term "replaceable," and variants thereof, are intended to be more general than the term "disposable," and variants thereof.

The electrical circuit <NUM> can include a positive node 111a, a resistive element 111b, a negative node 111c, and a power source 111d (such as a battery or a wall plug). In some embodiments, the resistive element 111b can limit the amount of current that flows through the electrical circuit <NUM> when the electrical circuit <NUM> is activated.

In this context, the electrical circuit <NUM> remains uncompleted until the replaceable test strip <NUM> is present and a wetting event occurs. When the replaceable test strip <NUM> is present and a wetting event occurs, the electrical circuit <NUM> becomes completed, including the positive node 111a, the resistive element 111b, the negative node 111c, and the power source 111d.

In other possible implementations, the electrical circuit <NUM> may omit the resistive element 111b and the power source 111d; these elements may be integrated into the transceiver <NUM>. This can have the similar effect that the electrical circuit <NUM> is completed, using electrical components that are integrated with the transceiver <NUM>.

The replaceable test strip <NUM> can include elements shown in the figure, such as at least the following: a wicking element 112a, a first conductive node 112b, a second conductive node 112c, a conductive patch 112d, an adhesive side 112e, and a waterproof covering 112f. In this configuration, the replaceable test strip <NUM> is optionally held by the clamp <NUM> (or optionally stuck to the patient's underwear (or other clothing, or a body location) using an adhesive strip, as described herein), with the positive node 111b being coupled to the first conductive node 112b, and with the negative node 111c being coupled to the second conductive node 112c.

The wicking element 112a can be disposed near the bodily exit <NUM> with the conductive patch 112d proximal thereto, with the effect that when a wetting event occurs, the urine is absorbed by the wicking element 112a, which couples the first conductive node 112b to the second conductive node 112c, thus coupling the positive node 111b to the negative node 111c.

The conductive patch 112d can have the effect that less urine is needed to couple the positive node 111b to the negative node 111c. The urine wets less of the wicking element 112a, thus less time is taken before the positive node 111b couples to the negative node 111c.

The adhesive side 112e can be coupled, such as by a removable glue adhesive, to the patient's clothing. For example, in one context, the adhesive side 112e can be coupled to an outside surface of the patient's underwear, so as to allow wicking of fluid into the replaceable test strip <NUM> in the even of a wetting event. In this context, the waterproof covering 112f can be disposed between the outside surface of the patient's underwear and any of the patient's further clothing, with the effect of preventing the fluid from the wetting event from wicking further from the replaceable test strip <NUM> into the patient's further clothing. Of course, if the fluid spreads through the patient's underwear, the fluid might further spread from the outside surface of the patient's underwear to the patient's further clothing or to the patient's bedding.

In one implementation, the adhesive side 112e is all that is necessary to dispose the test strip <NUM> near to the body exit <NUM>, so the clamp <NUM> is optional. In an alternative implementation, the test strip <NUM> can alternatively or in addition be held in place by an (optional) clamp <NUM>, with the effect of preventing the test strip <NUM> from unwanted movement while the patient (child) is asleep.

When the replaceable test strip <NUM> is stuck to the patient's underwear (or other clothing, or a body location) using an adhesive strip, the replaceable test strip <NUM> can be stuck on an inside location (thus, between the bodily exit <NUM> and the patient's clothing) or on an outside location (thus, near the bodily exit <NUM> but on the patient's clothing). In either such case, the replaceable test strip <NUM> is disposed so that the replaceable test strip <NUM> generally absorbs fluid from the bodily exit <NUM>, with one or more effects noted herein.

The waterproof cover <NUM> is coupled to the wicking element 112a, with the effect that the wicking element 112a can absorb urine from the bodily exit <NUM> without wetting the patient's underclothes, clothes, or bedding. As noted above, though, if the fluid spreads through the patient's underwear, the fluid might further spread from the outside surface of the patient's underwear to the patient's further clothing or to the patient's bedding. The waterproof cover <NUM> can also make it easier to remove the wicking element 112a without the caregiver's hands or the patient's hands becoming dirty from fluid from the wetting event. However, as noted above, if the fluid has spread beyond the wicking element 112a itself, the (optional) waterproof cover <NUM> might not be very effective in preventing the caregiver's hands or the patient's hands from becoming dirty from fluid from the wetting event.

Attachment of the replaceable test strip <NUM>, either to a portion of the sensor <NUM>, to a portion of the transceiver, or to some other element, is described in other and further detail with respect to <FIG>.

As described herein, the replaceable test strip <NUM> in the sensor <NUM> can both assist in detecting a wetting event, and can be replaced after the event in preparation for a possible new event. Thus, the sensor <NUM> can be maintained without extensive cleaning, instead by involving only removing the test strip <NUM> from the sensor <NUM> after a wetting event, and replacing the replaceable test strip <NUM> in the sensor <NUM>.

The transceiver <NUM> can be coupled to the sensor <NUM>, and can receive a signal from the sensor <NUM> indicative of a wetting event. For example, the wetting event can be (<NUM>) not in progress, that is, there is no current wetting event involving the sensor <NUM>; (<NUM>) in progress, that is, the wetting event is ongoing and urine is being vented into the sensor <NUM>; or (<NUM>) finished, that is, the wetting event has occurred and urine has been completely vented onto the sensor <NUM>.

In other embodiments, the transceiver <NUM> can include at least some of the components of the electrical circuit <NUM>, with the effect that the transceiver <NUM> may generate its own signal indicative of the wetting event. In such other embodiments, the transceiver <NUM> can itself provide the signal indicative of a wetting event.

The transceiver <NUM> can include a signal coupling from the sensor <NUM> to the alert processor <NUM>.

For one example, the transceiver <NUM> can include a wired node <NUM> coupled to the sensor <NUM> at a first location and to the alert processor <NUM> at a second location.

For another example, the transceiver <NUM> can include a wireless transmitter <NUM> receiving an alert or other signal from the sensor <NUM> and sending the alert or other signal <NUM> to the alert processor <NUM>. As described herein, an alert or other signal <NUM> includes one or more of (<NUM>) an alert, that is, an indicator that a wetting event has started or has occurred, or (<NUM>) another signal, that is, an EM (electromagnetic) or other informational signal with respect to the progress of a wetting event. In this context, a signal can include a measure of an amount of wetting, encoded onto an EM carrier in AM (amplitude modulation) or another form of signal modulation.

Further, while in this Application, an alert or other signal <NUM> is primarily described with respect to EM carriers, there is no particular requirement for any such limitation. For example, the alert or other signal <NUM> can be sent using a sonic carrier or another form of sending information.

As described herein, the transceiver <NUM> can include a wireless converter <NUM>. The wireless converter <NUM> can be coupled both to a legacy wireless receiver <NUM> (not part of the transceiver <NUM>), and to the wireless transmitter <NUM>. This can have the effect that the transceiver <NUM> can receive a wireless signal <NUM> configured for the legacy wireless receiver <NUM> and retransmit that wireless signal <NUM> to the alert processor <NUM>.

As described herein, this can have the effect that a user of the legacy wireless receiver <NUM> can couple that legacy wireless receiver <NUM> to the wireless transmitter <NUM> (that is, to the wireless converter <NUM>) without having to replace the legacy wireless receiver <NUM> to use the system <NUM>.

The alert processor <NUM> can include elements shown in the figure. It includes at least the following: a mobile device <NUM> (such as a cellular telephone, music player, or similar mobile device; a "smart watch" or other wearable or implantable computing device; a portable computer such as a Raspberry Pi™; or any similar device) operating under control of a mobile app <NUM>. The mobile device <NUM> can include a processor 131a, memory and storage 131b, one or more input elements 131c, and one or more output elements 131d. For example, the mobile device <NUM> can include an Android™ cellular telephone available from Google, Inc. of Mountain View, California (and other suppliers), or an iPhone™ cellular telephone available from Apple Computer of Cupertino, California; including a standard processor 131a, memory and storage 131b, input elements 131c and output elements 131d (such as one or more accelerometers or gyroscopes, one or more buttons, a capacitive touch and display screen, a GPS locator, one or more short-range wireless communicators (such as Bluetooth™ or NFC, near-field communication), one or more speakers, one or more switches), and other equipment known to be used with such devices.

As described herein, the mobile device <NUM> operates under control of the mobile app <NUM>. As described herein, the mobile app <NUM> can operate using a computing device, and can include instructions and data maintained in the mobile device <NUM>, wherein the instructions can be executed or interpreted using an operating system resident on the mobile device <NUM>. For example, the operating system can include iOS <NUM>. <NUM>™, or any similar operating system, and the mobile app <NUM> can include instructions and data suitable to perform the functions described herein.

As described herein, the mobile device <NUM> can receive alerts or other signals from the transceiver <NUM>. The technique for receiving alerts or other signals can use the instructions in the mobile app <NUM>, or can use instructions originally having a different purpose, but which are effective to receive alerts or other signals <NUM>. For example, the mobile device <NUM> can receive those alerts or other signals <NUM> in memory or storage 121b, and maintain digitized versions thereof.

The mobile app <NUM>, by its instructions, can: (a) analyze those alerts or other signals; (b) determine whether and when to publish alarms to recipients, such as to patients, to caregivers, to substitute caregivers, to data storage, and possibly otherwise; and can (c) present published alarms to recipients in a form that attracts the attention of those recipients.

For one example, the mobile app <NUM> can receive alerts or other signals <NUM> from the transceiver <NUM> and determine if those alerts or other signals <NUM> indicate an actual wetting event, as opposed to noise or a likely false positive.

The mobile app <NUM> can execute instructions from the memory or storage 121b, wherein those instructions direct the mobile device <NUM> to compare those alerts or other signals <NUM> with one or more threshold values. In such cases, the mobile app <NUM> can determine that those alerts or other signals <NUM> indicate a wetting event if sufficient current passes through the electrical circuit <NUM> in the sensor <NUM> (because the wicking element 112a is sufficiently wet, because fluid has vented from the body exit <NUM>). Accordingly, the mobile app <NUM> can compare incoming alerts or other signals <NUM> with a threshold to determine if the amount of current is sufficient.

As described herein, the threshold can be adjusted to account for the possibility that perspiration is also vented onto the wicking element 112a of the replaceable test strip <NUM>. If the mobile app <NUM> notes greater amounts of perspiration, it can raise the threshold, and vice versa.

For another example, the mobile app <NUM>, having determined that received alerts or other signals represent a wetting event, can record information about the event. For example, the mobile app <NUM> can maintain information about the received alerts or other signals in the memory and storage 131b, or can use the one or more output elements 131d to present that information to a user, or to send that information to the server <NUM>.

In one possible implementation, information about the alert can include one or more of the following:
A record that the alert occurred, and a date and time of the alert, such as a number of days that have passed since an earlier alert: This can be valuable to determine whether the patient is learning to sleep through the night without a wetting event, or is making progress to that goal.

A duration of the alert, such as a time from a start of the wetting event to a time when a response is made to the alert, or such as a time from when the response is made to the alert, to a time when the alert is turned off or the sensor is removed: This can be valuable to determine whether the patient is learning to respond to the alert, such as to remove the sensor and to use the restroom.

A record of improvement by the patient, such as either raw improvement, or with respect to a guide to improvement. For example, in some recommendations, it is desirable for the patient (such as a child) to sleep dry through the night (that is, no wetting events all evening) for at least <NUM> days to determine that the patient has broken the habit of wetting events. In such cases, the mobile app <NUM> can determine whether the patient has made substantial progress, and how much further progress is desired before the habit of wetting events can be declared broken.

The mobile app <NUM> can also cause the alert processor <NUM> to direct the sensor <NUM> to alter its electrical or other parameters, such as by adjusting a resistance of the electrical circuit <NUM> using a potentiometer (coupled to the electrical circuit <NUM>), in response to signals from the sensor <NUM>.

In such cases, for example, if the patient perspires excessively, the alert processor <NUM> can reduce the sensitivity of the sensor <NUM> (such as by increasing the resistance of the electrical circuit <NUM>) so that the sensor <NUM> does not generate a false positive for a wetting event.

In such cases, for another example, when a wetting event occurs, the mobile app <NUM> can also cause the alert processor <NUM> to direct the sensor <NUM> to eliminate an electrical current through the electrical circuit <NUM> in the sensor <NUM>, so that the patient does not suffer burns or rash due to that current.

In such cases, for another example, when the caregiver replaces the replaceable test strip <NUM> after a wetting event, the mobile app <NUM> can also cause the alert processor <NUM> to direct the sensor <NUM> to restart the electrical current through the electrical circuit <NUM> in the sensor <NUM> in preparation for a possible future event.

The mobile app <NUM> can also cause the alert processor <NUM> to direct the sensor <NUM> to alter its electrical or other parameters in response to information so far collected about the patient (such as a child).

For example, the mobile app <NUM> can maintain a record of chemical aspects of wetting events, such as an amount of acidity or salinity. If the mobile app <NUM> determines that changes in chemical aspects of wetting events are significant enough to advise changes in parameters of the sensor <NUM>, the mobile app <NUM> can cause the alert processor <NUM> to direct the sensor <NUM> to alter the parameters of the electrical circuit <NUM> (such as by using a potentiometer, as described herein, or by using another circuit element to otherwise alter the parameters of the electrical circuit <NUM>).

For another example, the mobile app <NUM> can maintain a record of volumetric aspects of wetting events, such as in response to a time duration of each wetting event. Similarly, If the mobile app <NUM> determines that changes in chemical aspects of wetting events are significant enough to advise changes in parameters of the sensor <NUM>, the mobile app <NUM> can cause the alert processor <NUM> to direct the sensor <NUM> to alter the parameters of the electrical circuit <NUM>, such as by adjusting a timing circuit to automatically break the electrical circuit <NUM> after a selected duration during which the wetting event has continued.

The mobile app <NUM> can also cause the alert processor <NUM> to direct the sensor <NUM> to record and maintain information with respect to the during, timing, and other information, with respect to wetting events.

In one particular implementation, as described herein, the mobile app <NUM> can automatically record and maintain information (such as at the server <NUM>) with respect to wetting events, while the patient or caregiver is possibly preoccupied with responding to those wetting events. Since the mobile app <NUM> can perform these actions without human intervention, this can have the effect that information with respect to wetting events can be maintained accurately, despite the possibility of human error in remembering to record those wetting events, or the possibility of human error in accurately recording, pertinent information with respect to those wetting events.

For example, the mobile app <NUM> can record the occurrence, duration, and other timing aspects of wetting events. As noted herein, this can include, without limitation, (<NUM>) how frequently wetting events occur, (<NUM>) an amount of time between an earlier wetting event and a current wetting event, (<NUM>) a first, second, or other derivative of a measure of times between wetting events, (<NUM>) an amount of time taken by the patient, such as a child, or a caregiver, such as a parent, in responding to the wetting event, (<NUM>) a first, second, or other derivative thereof, or another timing or other responsive measure with respect to wetting events.

For example, as described herein, the mobile app <NUM> can record and maintain information with respect to how much time, such as a number of days, which have passed since the most recent wetting event. This can be valuable in determining whether the patient has been free of wetting events for <NUM> days, after which the patient can be deemed free of any substantial likelihood of future wetting events.

Naturally, the value of the time duration of "<NUM> days" can be adjusted in response to circumstances, such as (<NUM>) a significant, or even just a recent, history of wetting events; (<NUM>) becoming subject to or resuming significant life stressors; (<NUM>) having relapsed to wetting events after earlier having been deemed free of future wetting events; (<NUM>) becoming subject to or resuming a medical ailment, such as a bladder infection, insomnia, or other physical or psychological condition; or alternatively, (<NUM>) in response to the nature of the wetting events, such as whether those wetting events are relatively larger or smaller than earlier recorded. For example, the mobile app <NUM> can choose to substantially ignore wetting events below a certain volume threshold (such as only a "dribble") when determining the <NUM>-day dryness duration.

The mobile app <NUM> can adopt one or more policies, such as might be set as a default by the manufacturer, or set by the patient or caregiver for a sequence of wetting events, with respect to determining when the patient is making progress with respect to wetting events. These policies can include those described above, and can include determining a selected time duration after which the patient has made sufficient progress with respect to wetting events that monitoring is no longer significantly necessary. Moreover, these policies can be adjusted by the patient or caregiver, or can be updated by the manufacturer as part of a software update.

In addition, the mobile app <NUM> can record and maintain information with respect to how long it takes the patient to respond to a wetting event alarm, to terminate the alarm, and to attend to the restroom in lieu of continuing the wetting event. For example, when a wetting event is detected, the alert processor can start a timer that records the amount of time it takes for the patient to respond to the wetting event alarm, such as "<NUM> seconds to respond on Monday; <NUM> seconds to respond on Tuesday; <NUM> seconds to respond on Wednesday; no wetting event on Thursday; <NUM> seconds to respond on Friday;" or similar patient progress. Naturally, a shorter amount of time is likely to be considered better. The alert processor can maintain the amount of time for each wetting event, and determine whether the patient is responding more quickly (good) or failing to respond more quickly (not as good).

In addition, the mobile app <NUM> can receive information from the sensor with respect to movement by the patient. For example, the sensor can include one or more accelerometers, such as a digital triaxial acceleration sensor. For another example, the one or more accelerometers, such as a digital triaxial acceleration sensor can be included in the transceiver. In either technique, the one or more accelerometers can determine when the patient is moving. When the patient is merely moving as part of sleeping, the sensor will not detect a wetting event, so the patient's movement can be discounted. When the sensor detects a wetting event, the accelerometer can detect the patient's movement (such as at a selected degree of sensitivity), with the effect of determining how quickly the patient responds to the alarm. Improved time to respond to the alarm should indicate progress by the patient. Moreover, the sensor can respond to the accelerometer to turn off the alarm without action by the patient or the caregiver, to turn on the lights in the patient's bedroom, or other appropriate actions. In such cases, the sensor does not have to wait for the patient or caregiver to locate and hit a button or switch to indicate that they are responding to the wetting event, but can respond directly and allow the sensor to measure that they are making that response.

For another example, the mobile app <NUM>, having determined that received alerts or other signals represent a wetting event, can determine to which recipients to publish an alarm. For example, the patient <NUM> can have more than one caregiver <NUM> associated therewith, such as: a child with a babysitter and one or more parents, or a child with two parents, or a hospital patient with a designated nurse and one or more backup nurses; each of whom is designated as a possible caregiver <NUM> who will attend to the child if a wetting event occurs.

In such cases, the mobile app <NUM> can also cause the alert processor <NUM> to publish one or more alerts to the one or more caregivers <NUM>.

In such cases, for example, the mobile app <NUM> can publish the alert to a first caregiver <NUM> a selected number of times. In such examples, the mobile app <NUM> can publish the alert with a first degree of urgency a first time (such as sounding an alarm to indicate a wetting event), with a second degree of urgency a second time (such as sounding a more urgent alarm to indicate a wetting event that has not yet been dealt with), and possibly with third or further degrees of urgency thereafter.

In such cases, for another example, the mobile app <NUM> can publish the alert to one or more first caregivers <NUM> a first time, to one or more second caregivers <NUM> a second time, and possibly to third or other caregivers <NUM> thereafter. The mobile app <NUM> can also publish the alert with varying combinations of degrees of urgency, number of caregivers <NUM>, selected caregivers <NUM>, and otherwise to inform caregivers <NUM> of the fact of, and information about, the wetting event. The mobile app <NUM> can also publish the alert to the patient <NUM> themselves, with the effect that the patient <NUM> can hear the alarm, awake, and attend to the wetting event (and take themselves to the restroom).

The mobile app <NUM> is configured to receive alert signals from two or more possible patients <NUM> concurrently, such as for all of the patients <NUM> in a wing or on a floor of a hospital, or assigned to a particular nurses' station, or such as multiple small children in a children's daycare facility. The mobile app <NUM> can associate selected particular patients <NUM> with selected particular caregivers <NUM>.

In one example embodiment, the mobile app <NUM> can associate particular patent <NUM> A with particular caregiver <NUM> B, and can associate particular patent <NUM> C with particular caregiver <NUM> D. The mobile app <NUM> can receive alerts and other signals from both patient <NUM> A and patient <NUM> C, and can publish alerts to both caregiver <NUM> B and caregiver <NUM> D.

In this example embodiment, when patient <NUM> A has a wetting event, the mobile app <NUM> can publish an alert to associated primary caregiver <NUM> B. If caregiver <NUM> B fails to attend to the wetting event, the mobile app <NUM> can publish a second alert to associated secondary caregiver <NUM> D. Similarly, when patient <NUM> C has a wetting event, the mobile app <NUM> can publish an alert to associated primary caregiver <NUM> D. If caregiver <NUM> D fails to attend to the wetting event, the mobile app <NUM> can publish a second alert to associated secondary caregiver <NUM> B.

This can have the effect that caregiver <NUM> B provides backup for caregiver <NUM> D, and vice versa. Other and further possibilities exist. For example, patient <NUM> A can have their own primary caregiver <NUM> B, patient <NUM> C can have their own primary caregiver <NUM> D, and caregiver <NUM> E can provide backup to more than one caregiver <NUM> (B and D).

In another example embodiment, the mobile app <NUM> can associate more than one particular patient <NUM>, such as both particular patient <NUM> A and particular patient <NUM> F, with a primary caregiver <NUM> B, and possibly a secondary caregiver <NUM> D.

In this example embodiment, when patient <NUM> A has a wetting event, the mobile app <NUM> can publish an first type of alert to primary caregiver <NUM> B, such as a first sound pattern for the alarm. When patient <NUM> F has a wetting event, the mobile app <NUM> can publish a second type of alert, also to primary caregiver <NUM> B, such as a second sound pattern for the alarm. For example, the first sound pattern could be the song "Purple Rain," while the second sound pattern could be the song "Raindrops Keep Falling On My Head" or "Yellow Submarine.

This can have the effect that primary caregiver <NUM> B can determine, from the nature of the sound pattern for the alarm, which particular patient <NUM> (A or F) has had the wetting event. In the context of the invention, there is no particular requirement that the sound alarm for the patient <NUM> and the caregiver <NUM> are the same; however, it might be convenient to make those sound alarms the same so the caregiver <NUM> is not confused by two different and concurrent sound alarms.

This can have the effect that the primary caregiver <NUM> B can attend to wetting events for multiple patients <NUM> (A and F), so long as those patients <NUM> do not have their wetting events concurrently. In such cases, the mobile app <NUM> can determine that more than one wetting event is occurring concurrently, and immediately publishes an alert to the secondary caregiver <NUM> D without waiting for the primary caregiver B to fail to respond timely.

Each patient <NUM> can have more than one caregiver <NUM> associated therewith. The alert processor <NUM> can alert those caregivers <NUM> in series or in parallel.

For an example of alerting caregivers <NUM> in series, the alert processor <NUM> can fail-over from one caregiver <NUM> to another (such as, B to D to E, to possibly another set of caregivers) in order, when it determines that any particular caregiver <NUM>, or set thereof, do not attend to the patient <NUM>. In such cases, the alert processor <NUM> can also reorder those caregivers <NUM>, either because selected ones are more attentive or less attentive, or because selected ones are known to be currently attending to a different patient <NUM>.

For an example of alerting caregivers <NUM> in parallel, the alert processor <NUM> can publish the alert to more than one caregiver <NUM> (such as, B and D and E, and possibly other caregivers) concurrently, canceling the alert when one of those caregivers <NUM> (such as B) indicates they are attending to the patient <NUM>. The alert processor <NUM> can obtain a message from the alert presenter <NUM> that one of the caregivers <NUM> B has noted the alert, or can obtain a message from the alert presenter <NUM> that one of the caregivers <NUM> B is physically moving toward, or physically near, the patient <NUM>.

More generally, the alert processor <NUM> can associate groups of patients <NUM> with groups of caregivers <NUM>, alerting whichever ones of those caregivers <NUM> it chooses when it detects a wetting event for any one of those patients <NUM>. The alert processor <NUM> can also organize groups of caregivers <NUM> into subgroups, alerting caregivers <NUM> in those subgroups in parallel or series, and alerting those subgroups themselves in parallel or series. For example, the alert processor <NUM> can select a group of primary caregivers <NUM>, alerting them in parallel or series as it chooses, a group of secondary caregivers <NUM>, alerting them in parallel or series as it chooses when the primary caregivers <NUM> do not tend to the patient <NUM>, a group of tertiary caregivers <NUM>, and so on.

This can have the effect that the mobile app <NUM> can connect patients to caregivers in an m : n multiplicity rather than a <NUM> : <NUM> multiplicity.

For another example, the mobile app <NUM>, having determined to which recipients to publish alarms, can receive information from those recipients with respect to whether those recipients respond to the alarms. In this context, if a selected recipient does not respond, the mobile app <NUM> can publish the alarm to a substitute recipient. This can include a cascade of substitute recipients:
If the alert processor <NUM> publishes an alarm directly to the patient (such as using a loud sonic alarm), without the patient responding, the mobile app <NUM> can fail-over to publishing the alarm to a primary caregiver.

If the alert processor <NUM> publishes an alarm to the primary caregiver for that patient (such as using either a sonic alarm or a flashing screen), without that caregiver responding, the alert processor <NUM> can fail-over to publishing the alarm to a substitute caregiver.

If the alert processor <NUM> publishes an alarm to the substitute caregiver (again, such as using either a sonic alarm or a flashing screen), the alert processor <NUM> can fail-over to publishing the alarm to another caregiver.

The alert processor <NUM> can also publish the alarm to a data storage element, such as the memory and storage 131b for the mobile device <NUM>, or such as a database (not shown in this figure) coupled to the mobile device <NUM>, both as a record that the alarm was published, and as a message for another recipient to review the published alarm.

As described herein, when the alert processor <NUM> publishes an alarm to a selected recipient, it sends that alarm to the alert presenter <NUM> associated with that selected recipient. The alert presenter <NUM> presents the alarm to the selected recipient, determines if the selected recipient responds to the alarm, and so informs the alert processor <NUM>. If the alert presenter <NUM> informs the alert processor <NUM> that the selected recipient is not responding to the alarm, the alert processor <NUM> can fail-over to the next selected recipient.

While the mobile device <NUM> is primarily described with respect to a cellular telephone, the alert processor <NUM> can instead include another type of general-purpose processor, or a type of special-purpose processor specifically configured for the purposes described herein, or other electronic circuitry configured for the purposes described herein.

The alert presenters <NUM> each can include elements shown in the figure, such as at least the following: a mobile device similar to the alert processor <NUM>. For example, the alert presenters <NUM> can include an iPhone <NUM>™ cellular telephone similar to the alert processor <NUM>. For another example, the alert presenters <NUM> can include another device, such as a computing device (desktop, laptop, wearable or implantable), or other device capable of receiving signals and alerting the user.

The alert presenter <NUM> can be associated with the alarm recipient, and can receive the published alarm from the alert processor <NUM>. As described herein, when the alert processor <NUM> determines the presence of a wetting event, the alert processor <NUM> publishes an alarm to one or more selected recipients.

If the alert presenter <NUM> publishes an alarm directly to the patient, it can provide a loud sonic alarm to wake the patient quickly. In one alternative, if the patient does not wish to be awakened by a sonic alarm, the alert presenter <NUM> can publish the alarm to the patient by flashing a light. In another alternative, the alert presenter <NUM> can publish the alarm to the patient by vibrating or generating another type of haptic, or other, alert.

If the alert presenter <NUM> publishes an alarm to a caregiver for that patient (such as either the primary caregiver or a substitute caregiver), it can provide one or more of: a sonic alarm or a flashing screen, such as on a cellular telephone for the caregiver.

If the alert presenter <NUM> publishes an alarm to a data storage element, such as data storage for a cellular telephone, or for the server <NUM>, or such as a database (possibly available at the remote element <NUM> of the server <NUM>), the alert presenter <NUM> can send a message including information that the alarm was published, and can send a message for another recipient to review the published alarm.

The server <NUM> can include elements shown in the figure, such as at least the following: a computing device (including a processor <NUM>, memory or storage <NUM>), a communication link <NUM>, an input/output port <NUM>), and other elements necessary or sufficient for the functions described herein. The server <NUM> can also couple to one or more remote elements <NUM> (which are not actually part of the system <NUM> or the server <NUM>).

The server <NUM> can couple to the alert processor <NUM> or the alert presenter <NUM>, such as using the communication link <NUM> and the input/output port <NUM>. For one example, the communication link <NUM> can include a telephone switching system and the input/output port <NUM> can include a telephone number. For another example, the communication link <NUM> can include a computer network (such as the Internet) and the input/output port <NUM> can include a network interface card.

In such cases, the server <NUM> can receive messages from either the alert processor <NUM> or the alert presenter <NUM>. The messages can include data with respect to patients, caregivers, wetting events, and other information related to patient care or customer relations. The server <NUM> can send messages to the alert processor <NUM> or the alert presenter <NUM>.

In such cases, receiving or sending messages with the alert processor <NUM> or the alert presenter <NUM> has the effect of allowing the server <NUM> to communicating with the patient, caregivers, or alert system customer. This allows the server <NUM> to perform one or more of the following functions:
The server <NUM> can collect information with respect to wetting events. The server <NUM> can forward this information to the patient, to caregivers (such as to substitute caregivers or persons in supervisory positions with respect to caregivers), or to alert system customers.

The server <NUM> can collect information with respect to patients. For example, the server <NUM> can determine whether the patient (or particular patients, when there is more than one patient coupled to the alert system <NUM>) is successfully learning to avoid wetting events. It is sometimes asserted that patients should be free of wetting events for about <NUM> days to assure that enuresis is deemed "cured. " In such cases, the server <NUM>, or the alert processor <NUM>, can determine, in response to information about wetting events, how many more days the patient should remain free of wetting events before their enuresis is deemed cured.

The server <NUM> can collect information with respect to caregivers. For example, the server <NUM>, or the alert processor <NUM>, can determine an average response time for particular caregivers, or a number of times each particular caregiver has been alerted to care for a patient. In the former such case, the server <NUM>, or the alert processor <NUM>, can provide feedback to the caregiver. In the latter such case, the server <NUM>, or the alert processor <NUM>, can determine a next caregiver to present an alert or other signal to, in response to an attempt to balance caregiving load.

The server <NUM>, or the alert processor <NUM>, can collect information with respect to sensors <NUM>. For example, when wetting events occur, and the patient or caregiver reports this, but the sensor <NUM> failed to report this, the server <NUM>, or the alert processor <NUM>, can adjust parameters with respect to the sensor <NUM> (such as sensitivity to moisture, loudness of alarm, or other parameters related to detecting wetting events or presenting alarms), or can inform a customer of the alert system <NUM> that the sensor <NUM> should be replaced.

The sensor <NUM> can collect backup information in the event that the alert processor <NUM> is damaged, loses memory, or is otherwise disabled. For example, when the alert processor <NUM> is replaced or upgraded, stored information for use by the alert processor <NUM> can be restored from backup information maintained at the server <NUM>.

The sensor <NUM>, or the alert processor <NUM>, can collect information with respect to usage of the alert system <NUM>. For one example, the sensor <NUM>, or the alert processor <NUM>, can inform the patient, caregiver, or customer of the alert system <NUM> that more (or fewer) alert processors <NUM> or alert presenters <NUM> should be integrated with the alert system <NUM>. For another example, the sensor <NUM>, or the alert processor <NUM>, can inform the patient, caregiver, or customer of the alert system <NUM> that the patient has learned to avoid wetting events, and usage of the alert system <NUM> can be stopped.

The sensor <NUM>, or the alert processor <NUM>, can collect business information with respect to interaction between the alert system <NUM> and its supplier. For one example, depending on the nature of the business arrangement between the supplier and the customer, the sensor, or the alert processor <NUM>, can collect information related to billing, repairs, quality assurance, and other information assisting the supplier and customer in obtaining value received from the alert system <NUM>. For another example, the server <NUM> can collect information related to system components and type, repair and help-desk records, and successful (or unsuccessful) solutions, to assist the customer in their experience with requests for service of the alert system <NUM>.

In one or more embodiments, the server <NUM> can be coupled to one or more remote elements <NUM>. In this context, the terms and phrases "remote," "remote element," and variants thereof, refer to logical remoteness, not necessarily to physical remoteness or to difficulty of connectivity. For example, remote elements <NUM> can be coupled to the server <NUM> by sharing the memory or storage <NUM> with the server <NUM>, by sending and receiving messages to and from the server <NUM>, by coupling to the input/output port <NUM>, or by any other technique allowing information to flow at least from the server <NUM> to a remote element <NUM> or to the server from a remote element <NUM>.

For example, remote elements <NUM> can include one or more of the following: a remote memory or storage, such as for archive or backup, cloud storage, or memory or storage for use by another device; a remote processor, such as a special-purpose processor, a processor operating under control of special-purpose software, a particular electrical circuit, a cloud computing device, or any other computing element not incorporated into the system <NUM>; or any other device not particularly specified herein, but useful with the system <NUM>.

As described herein, the patient <NUM> can include a child, such as a child who has difficulty sleeping dry through the evening, or otherwise having wetting events, an elderly person with similar problems, a hospital or other medical patient with similar problems, a patient with one or more leaking bodily orifices, such as a bleeding or suppurating wound, or another type of person subject to wetting events. In alternative embodiments, a "patient" <NUM> can be sufficiently general to include a device, sensor, or other equipment subject to wetting events, such as the possibility of leakage from a canister, or a similar concern.

As described herein, the caregivers <NUM> can include one or more of: a parent, a nurse, medical personnel, or other persons charged with the responsibility for noting wetting events and responding thereto. For example, caregivers can include a babysitter or one or both parents for a child, a patient's assigned nurse and one or more backup nurses, an attending physician and one or more on-call physicians, or any other person who can reasonably be expected to respond to an alert or other signal.

As described herein, the operators <NUM> can include any person who can reasonably be expected to respond to alerts or other signals from the system <NUM>.

The server interface <NUM> can include elements shown in the figure, such as at least the following: a mobile device similar to the alert processor <NUM>. For example, the server interface <NUM> can include an iPhone <NUM>™ cellular telephone similar to the alert processor <NUM>. For another example, the server interface <NUM> can include another device, such as a computing device (desktop, laptop, wearable or implantable), or other device capable of receiving signals and alerting the user.

The server interface <NUM> can be associated with a user of the system <NUM>, such as an operator <NUM>, and can interact with the server <NUM> to retrieve information with respect to wetting events, alerts, history for patients <NUM>, history for caregivers <NUM>, history for elements of the system <NUM>, and any business interactions between the user and a provider of the system <NUM>.

<FIG> shows a conceptual drawing of a clamp.

A clamp 112f and the waterproof box <NUM> can collectively include a plastic (or otherwise urine-resistant, or resistant to the fluid to be detected) box-like object, as shown in the figure. As described herein, these are collectively referred to as a clamp assembly <NUM>.

The clamp assembly <NUM> can be coupled to the replaceable test strip <NUM>, as shown in the figure, or in some other similar configuration. As otherwise and further described herein, the clamp assembly <NUM> can include elements shown in the figure, including without limitation: a clamp base <NUM>, a test strip receiving zone <NUM>, an attachment point <NUM>, a cover <NUM>, one or more visible indicators <NUM>, and possibly other elements, or possibly other aspects of those elements described herein.

The clamp base <NUM> can include a substantially box-like object, as shown in the figure, with substantially rounded sides and beveled edges. This can have the effect of limiting the likelihood of cuts or bruises to the patient when the clamp base <NUM> is disposed near the body exit <NUM> or otherwise within the patient's clothing.

However, in the context of the invention, there is no requirement for any such limitation. For example, the clamp base <NUM> can include a substantially rectilinear box-line object, possibly with rounded corners and possibly with beveled edges, but not required. Similarly, the clamp base <NUM> can include a substantially ellipsoidal object, possibly with attachments and possibly with jutting elements, but not required. The clamp base <NUM> need only be able to perform the functions described herein.

The test strip receiving zone <NUM> can include a substantially flat region bounded by a bottom 202a (defined by a portion of the clamp base <NUM>), a top 202b (defined by a portion of the cover <NUM>), and disposed in size and shape to receive one or more replaceable test strips <NUM>.

The attachment point <NUM> can be disposed substantially in or near the test strip receiving zone <NUM>, and can include a protrusion onto which the replaceable test strip <NUM> can be attached. For example, the replaceable test strip <NUM> can be punctured by the protrusion, with the effect of anchoring the replaceable test strip <NUM> within the receiving zone <NUM>.

However, in the context of the invention, there is no requirement for any such limitation. For example, the attachment point <NUM> can include a substantially crimping region, such as possibly an edge of the cover <NUM>, disposed suitably for holding the replaceable test strip <NUM>. For another example, the attachment point <NUM> can include a substantial detent, into which the replaceable test strip <NUM> can be fitted. The attachment point <NUM> need only be able to perform the functions described herein.

The cover <NUM> can include a hinge 204a coupled to one or more points on the clamp base <NUM>, the hinge 204a being capable of providing the cover with at least two possible positions: open and closed. In the open position, the replaceable test strip <NUM> can be placed substantially in or near the test strip receiving zone <NUM>, and can be coupled to the attachment point <NUM>. In the closed position, the replaceable test strip <NUM> can be held at least partially within or near the test strip receiving zone <NUM>. Other possible positions are possible, such as possibly a partially-open partially-closed position.

The visible indicators <NUM> can be disposed to provide a visible indication of when the clamp base <NUM> is open, closed, or in some other state. For example, the visible indicators <NUM> can include liquid crystal diodes (LCD's), light-emitting diodes (LED's), incandescent lamps, or other devices that can be seen by a user, particularly a casual user who is not making a close inspection, but is just looking at the visible indicators <NUM> to see its status.

<FIG> shows a conceptual drawing of a method.

A method <NUM> of using the system <NUM> can include flow points and process steps shown in the figure, such as at least the following:.

A flow point 300A indicates the method <NUM> is ready to start.

A flow point <NUM> indicates the method <NUM> is ready to dispose the sensor <NUM> to detect a wetting event.

At a step <NUM>, the caregiver <NUM> (or the patient <NUM>) disposes the replaceable test strip <NUM> in the clamp <NUM>, and disposes the clamp <NUM> near the body exit <NUM>.

At an optional step <NUM>, the caregiver <NUM> couples the legacy wireless receiver <NUM> to the wireless converter <NUM> and to the wireless transmitter <NUM>. This can have the effect that the legacy wireless receiver <NUM> can receive the signal <NUM> from the sensor <NUM> and retransmit that signal <NUM> to the alert processor <NUM>.

The method <NUM> proceeds with the flow point <NUM>, at which the method <NUM> is ready to receive and process signals, unless and until a wetting event occurs.

At a flow point <NUM>, a wetting event occurs.

At a step <NUM>, the replaceable test strip <NUM> receives fluid from near the body exit <NUM>, as a consequence of a wetting event. The wicking element 112a of the replaceable test strip <NUM> draws the fluid, causing the first conductive node 112b to couple to the second conductive node 112c. This can cause the positive node 111b to couple to the negative node 111c, which can complete the electrical circuit <NUM>, which can provide the signal <NUM> at the output node <NUM> of the sensor <NUM>. This can cause the transceiver <NUM> to send the signal <NUM> to the alert processor <NUM>.

The method <NUM> proceeds with the flow point <NUM>, at which the method <NUM> publishes alerts to caregivers <NUM>, unless and until a caregiver <NUM> attends to the patient <NUM>.

At a flow point <NUM>, the wetting event has been tended to.

At a step <NUM>, the caregiver <NUM> (or the patient <NUM>) removes the old replaceable test strip <NUM> from the clamp <NUM>, and discards the old replaceable test strip <NUM>.

At a step <NUM>, if the wetting event is still ongoing, the patient <NUM> continues urination at a restroom. The caregiver <NUM> wakes the patient <NUM> to perform this step if necessary or desirable.

At a step <NUM>, once the patient <NUM> completes their tasks at the restroom, the method <NUM> proceeds with the flow point <NUM>, at which the sensor <NUM> is redis-posed for a possible next wetting event by disposing a new replaceable test strip <NUM>.

A flow point <NUM> indicates that the method <NUM> is ready to receive and process signals with respect to wetting events.

At a step <NUM>, the alert processor <NUM> receives the signal <NUM> from the transceiver <NUM>. The alert processor <NUM> provides the signal <NUM> to the mobile app <NUM>, which determines whether the signal <NUM> indicates a wetting event. If not, the method <NUM> returns to the flow point <NUM>. If so, the method <NUM> proceeds with the next step.

At a step <NUM>, the alert processor <NUM> publishes an alert to the patient <NUM>.

At a step <NUM>, the alert processor <NUM> determines if the alert to the patient <NUM> is sufficient to deal with the wetting event. If so, the method <NUM> proceeds with the flow point <NUM>, at which the patient <NUM> tends to the wetting event. If not, the method <NUM> proceeds with the flow point <NUM>, at which the alert is published to one or more caregivers <NUM>.

A flow point <NUM> indicates that the method <NUM> is ready to publish alerts with respect to wetting events to caregivers <NUM>.

At a step <NUM>, the alert processor <NUM> selects a set of one or more caregivers <NUM> to whom to publish the alert. As described herein, this set of caregivers <NUM> can be statically associated with the patient <NUM>, or can be selected dynamically with the patient <NUM> by the alert processor <NUM>.

At a step <NUM>, the alert processor <NUM> publishes the alert to the set of selected caregivers <NUM>. As described herein, publishing the alert to the set of selected caregivers <NUM> can include sending a message from the alert processor <NUM> to the one or more alert presenters <NUM> associated with the selected caregivers <NUM>. For example, when the alert processor <NUM> and the alert presenters <NUM> are each mobile devices, such as cellular telephones, the alert processor <NUM> can send a text message, voice message, or other data message, to the alert presenters <NUM> to that effect.

The method <NUM> proceeds, as described herein with respect to the flow point <NUM>, with presenting the alert to the selected caregivers <NUM>. When the alert presenter <NUM> succeeds in causing at least one of the selected caregivers <NUM> to attend to the patient <NUM>, the alert presenter <NUM> sends a message back to the alert processor <NUM> to that effect. Similarly to sending a message from the alert processor <NUM> to the alert presenter <NUM>, the alert presenter <NUM> can send a text message, voice message, or other data message, to the alert processor <NUM> to that effect.

If the alert processor <NUM> receives a message from the alert presenter <NUM> that one of the selected caregivers <NUM> is tending to the patient <NUM>, the method <NUM> proceeds with the next step <NUM>. If not, the method <NUM> skips the next step <NUM> and proceeds with the step <NUM> thereafter.

At a step <NUM>, the alert processor <NUM> receives the message from the alert presenter <NUM> that one of the selected caregivers <NUM> is attending to the patient <NUM>. The method <NUM> proceeds with the flow point <NUM>, at which the method <NUM> redisposes the sensor <NUM> by discarding the old replaceable test strip <NUM> and disposing a new replaceable test strip <NUM>.

At a step <NUM>, the alert processor <NUM> receives the message from the alert presenter <NUM> that one of the selected caregivers <NUM> is attending to the patient <NUM>. The method <NUM> proceeds with the flow point <NUM>, at which the method <NUM> selects a new set of one or more caregivers <NUM> to attend to the wetting event, and publishes the alert to this new set of caregivers <NUM>.

The method <NUM> repeats the step <NUM> and the step <NUM> until at least one caregiver <NUM> tends to the wetting event.

A flow point <NUM> indicates that the method <NUM> is ready to present alerts with respect to wetting events.

At a step <NUM>, those alert presenters <NUM> selected by the alert processor <NUM> present their alerts to their associated caregivers <NUM>. For example, when alert presenters <NUM> include cellular telephones, the alert presenters <NUM> can buzz, ring, or flash, to tell caregivers <NUM> to attend to a wetting event.

At a step <NUM>, each alert presenter <NUM> determines whether its associated caregivers <NUM> is attending to the patient <NUM>, or moving to attend to the patient <NUM>. The alert presenter <NUM> can.

If the associated caregiver <NUM> tends to the wetting event, the method <NUM> proceeds with the flow point <NUM>, at which the method <NUM> removes the old replaceable test strip <NUM> and disposes a new replaceable test strip <NUM> at the sensor <NUM>. The method <NUM> repeats from the flow point <NUM> as long as the patient <NUM> is still at risk for wetting events.

A flow point <NUM> indicates that the method <NUM> is ready to interact between the user and the server.

At a step <NUM>, an operator <NUM> associated with a server interface <NUM> begins operation of the server interface <NUM>. The server interface <NUM> presents information to, and receives information from, the operator <NUM>, in response to input from the operator <NUM>.

At a step <NUM>, the operator <NUM> decides to interact with the server <NUM> using the server interface <NUM>. The server interface <NUM> sends a message to the server <NUM> telling the server <NUM> that the operator <NUM> desires to interact with it.

At a step <NUM>, the server <NUM> and the server interface <NUM> present a login screen to the operator <NUM>, receive login information from the operator <NUM>, and verify the login.

At a step <NUM>, the server <NUM> and the server interface <NUM> collectively present information to, and receive information from, the operator <NUM>, in response to input from the operator <NUM>.

For example, the server <NUM> and the operator <NUM> can interact in one or more of the following ways:
The operator <NUM> can obtain detailed information about configuration of the system <NUM> from the server <NUM>. The server <NUM> can obtain this information from its records of the user's system <NUM>, or from diagnostics or telemetry with respect to the system <NUM>.

The operator <NUM> can inform the server <NUM> of errors or failures of operation by the system <NUM>. The server <NUM> can provide troubleshooting information, or can generate a trouble ticket for repair or replacement of one or more of the system's elements.

The operator <NUM> can obtain detailed information about a business relationship between the user and a provider of the system <NUM>. For example, even though the replaceable test strips <NUM> are disposable, the user can rent the system <NUM> from the provider. For another example, the user can pay the provider for each wetting event, or for each use of the alert processor <NUM> or the alert presenter <NUM> (specifically, the mobile apps <NUM> associated therewith). For another example, the user can pay a one-time fee for a reasonable amount of time to train the patient <NUM> to avoid wetting events.

A flow point 300B indicates the method <NUM> is finished. The method <NUM> can be restarted at the flow point 300A.

After reading this Application, those skilled in the art will recognize that this Application includes additional teaching beyond those explicitly shown or suggested.

Moreover, although control elements of the one or more described apparatuses include more than one computing device (or more than one specialized computing device), not necessarily all similar, on which the element's functions are performed.

Individual elements or method steps of the described embodiments could be replaced with substitutes that perform similar functions in other contexts.

Elements of the system are described herein with respect to one or more possible embodiments, and are not intended to be limiting in any way. In the context of the invention, there is the particular requirement for any such limitations as described with respect to any elements of the system. For example, individual elements of the described apparatuses could be replaced with substitutes that perform similar functions. Moreover, as described herein, many individual elements of the described apparatuses are optional, and are not required for operation.

Although control elements of the one or more described apparatuses are described herein as being executed as if on a single computing device, in the context of the invention, there is no particular requirement for any such limitation. For example, the control elements of the one or more described apparatuses can include more than one computing device, not necessarily all identical, on which the element's functions are performed.

Certain aspects of the embodiments described in the present disclosure may be provided as a computer program product. The computer program product can include instructions that are maintained on a computer-readable storage medium or a non-transitory machine-readable medium. A computing device can interpret the instructions and perform one or more methods as described herein. The non- transitory medium can include a magnetic, optical or magneto-optical storage medium; a flash storage medium; and/or otherwise.

The Claims in this Application are hereby included by reference in the text of the Specification.

After reading this Application, those skilled in the art would recognize that this Application describes techniques (including machines, methods, articles of manufacture, and compositions of matter) that can make use of new concepts to provide useful and tangible results, which provide significantly more than a software concept. In one embodiment, this Application describes techniques that can significantly improve the technologies of clean and rapid detection of wetting events, alerting and response to wetting events, and recording and processing of wetting events. Moreover, in additional embodiments, this Application describes techniques that provide meaningful limitations beyond generally linking an patent-ineligible subject matter to use of a generalized computing environment. Some of these meaningful limitations are shown herein with respect to the described embodiments.

Claim 1:
Apparatus including
an alert processor including a mobile device operating under control of a mobile app, the alert processor having an input port disposed to receive a signal output from a sensor in response to a fluid exiting a body of a patient, having instructions determining whether the signal output from the sensor indicates a wetting event, and having an output port disposed to send an alert signal in response to the wetting event, wherein the mobile app is configured to receive alert signals from two or more patients concurrently;
an alert presenter including an alarm responsive to the alert signal;
wherein the alert processor has access to second instructions, the second instructions directing the alert signal to at least one or more of a set of alert presenters, wherein the set of alert presenters are associated with at least two distinct caregivers;
wherein the two distinct caregivers comprise a primary caregiver and a secondary caregiver, and wherein the mobile app is configured to associate more than one patient with the primary caregiver, and
wherein the mobile app is configured to direct the alert signal to the primary caregiver, and
wherein, if the mobile app determines that more than one wetting event is occurring concurrently, the mobile app is configured to immediately direct the alert signal to the secondary caregiver without waiting for the primary caregiver to respond.