DETAILED ACTION
Notice of Pre-AIA or AIA Status
In the present application, filed on or after March 16, 2013, claims 1-19 have been considered and examined under the first inventor to file provisions of the AIA .
Respond to Applicant’s Arguments/Remarks
Applicant’s arguments, see Remarks, filed 12/03/2025, with respect to the rejection(s) of claims 1-19 has been fully considered, and the results are as followings:
On pages 10-11 of Applicant’s remarks, Applicant argues that the combination of Sobol, Ricci, Awiszus, and Jeong fails to disclose the claimed invention because Jeong does not teach a sensor module with a first sensor being configured to couple with a second sensor (component block sensor).
Examiner respectfully disagrees with Applicant because as discussed in the Non-Final rejection mailed on 07/28/2025, the rejection relied upon Jeong to clearly disclose a component block (Jeong: Abstract, [0064]-[0072], and FIG. 3-5: The first interface 2120 may be disposed at a predetermined position of the strap part 2100 of the wearable device 2000 and configured to accommodate the sensor 3000 which is attachable and detachable. The first interface 2120 may receive biological signal detection information from the sensor 3000 that is attached to the wearable device 2000);
the sensor module (Jeong: FIG. 7-8 the sensor 3000) configured to removable couple the component block to the sensor module (Jeong: Abstract, [0052]-[0063], [0069], [0090]-[0101], and FIG. 7-8: the first interface 2120 and the sensor 3000 may have a universal serial bus (USB) connector type such as type A, type B, Mini-A, Mini-B, Micro-A, Micro-B, or Micro-AB. In addition, although FIG. 3A illustrates the first interface 2120 as a male connector (also referred to as a plug) and the sensor as having a female connector (also referred to as a receptacle or a port), one or more other exemplary embodiments are limited thereto. For example, the first interface 2120 may correspond to a USB Type A female connector and the sensor 3000 may have a corresponding USB Type A male connector);
the component block comprising a sensor component block (FIG. 7-8 the sensor 3000 and FIG. 10) comprising a component block sensor (Jeong: [0068], [0098], FIG. 7-8, and FIG. 10: the first interface 2120 may have a pin for connection to ground, a sensing pin for sensing attachment or detachment of the sensor 3000, a power pin for checking a power supply to the attached sensor 3000, a transmitting pin for transmitting data to the attached sensor 3000, a receiving pin for receiving data from the attached sensor 3000, a clock pin for receiving a clock signal, or the like); and
a communication subsystem configured to transmit raw data from the sensor subsystem and the component block sensor and receive a data (Jeong: Abstract, [0052]-[0063], [0069], [0090]-[0101], and FIG. 7-8: the first interface 2120 may have a pin for connection to ground, a sensing pin for sensing attachment or detachment of the sensor 3000, a power pin for checking a power supply to the attached sensor 3000, a transmitting pin for transmitting data to the attached sensor 3000, a receiving pin for receiving data from the attached sensor 3000, a clock pin for receiving a clock signal, or the like).
Therefore, in view of teachings by Sobol, Ricci, Awiszus, and Jeong, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the wearable device of Sobol, Ricci, and Awiszus to include a component block; the sensor module configured to removable couple the component block to the sensor module; the component block comprising a sensor component block comprising a component block sensor; and a communication subsystem configured to transmit raw data from the sensor subsystem and the component block sensor and receive a data, as suggested by Jeong. The motivation for this is to selectively implement different features of a wearable device for monitoring biological information of a user.
On pages 11-13 of Applicant’s remarks, Applicant argues that the combination of Sobol, Ricci, and Awiszus does not teach the invention of claim 14 because Awiszus does not disclose the alert on “confirmed alerts” but avoid “false alerts” by using contextualized sensor data.
Examiner respectfully disagrees with Applicant because the alert on “confirmed alerts” but avoid “false alerts” by using contextualized sensor data are not claimed, especially claim 1. However, as discussed in the Non-Final ejection mailed on 07/28/2025, the rejection relied upon Awiszus to disclose a system for determining alert statuses of a worker based on usage data obtained from different sensors associated with the worker and his environment (Awiszus: [0029], [0036], [0090]-[0092], [0111], [0152], Tables 1-2, FIG. 1, and FIG. 5: In some examples, a safety event may be an injury or worker condition, workplace harm, or regulatory violation. For example, in the context of fall protection equipment, a safety event may be misuse of the fall protection equipment, a user of the fall equipment experiencing a fall, or a failure of the fall protection equipment. In the context of a respirator, a safety event may be misuse of the respirator, a user of the respirator not receiving an appropriate quality and/or quantity of air, or failure of the respirator) wherein the system performs different rules corresponding to different environments to determine/confirm the alert in response to determining a safety event of the worker (Awiszus: [0087], [0090]-[0091], [0094], and FIG. 5: PPEMS 6 may also perform fall data analysis after a fall has occurred and/or determine temperature, humidity and other environmental conditions as they relate to the likelihood of safety events) and environment are combined and based on alert rules before activating an alert (Awiszus: [0029], [0037],[0039]: For example, PPEMS 6 may utilize the environmental data to aid generating alerts or other instructions for respirators 13 and for performing predictive analytics, such as determining any correlations between certain environmental conditions (e.g., heat, humidity, visibility) with abnormal worker behavior or increased safety events. As such, PPEMS 6 may utilize current environmental conditions to aid prediction and avoidance of imminent safety events. Example environmental conditions that may be sensed by sensing stations 21 include but are not limited to temperature, humidity, presence of gas, pressure, visibility, wind and the like, [0127]-[0128], [0223], [0246], [0249]-[0250], and FIG. 5: if a hazard is not detected, the computing device returns to operation to query whether the visor is open. If a hazard is detected in step 330, an alert is generated (340). A variety of types of alerts may be generated. For example, an alert may comprise one or more of the following types of signals: tactile, vibration, audible, visual, heads-up display or radio frequency signal. In some instances, an alert is not generated unless an exposure threshold and/or a hazard threshold is first met).
Therefore, Awiszus suggests a method of confirm or avoid alerts in response to the determined safety events.
As a result, Applicant arguments are not deemed persuasive, and the previous rejections pertaining to the previous set of claims are sustained. Therefore, due to the claimed amendments, upon further consideration, a new ground of rejections necessitated by amendments is made in view of following reference/combinations.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 12/03/2025 are in compliance with the provision of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by Examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-8 and 10-14 are rejected under 35 U.S.C. 103 as being unpatentable over Sobol et al. (Sobol – US 2019/0209022 A1) in view of Ricci (Ricci – US 2016/0266606 A1) and Awiszus et al. (Awiszus – US 2019/0175411 A1) and further in view of Jeong (Jeong – US 2016/0100758 A1).
As to claim 1, Sobol discloses a sensor system comprising:
a mounting base (Sobol: [0153]-[0154] and FIG. 2 the housing 110 and the support tray 120);
a body area subsystem (Sobol: FIG. 2 the structural components) comprising a sensor module (Sobol: [0121], [0154], [0157], [0164], [0166]-[0169], and FIG. 2 the activity 121A, the environment 121B, the physiological 121C, and the sensors 121D: The various sensors 121 may be advantageously located on or inside the wearable electronic device 100 such as in or on the housing 110, lateral extensions 111, 112, support tray 120 or the like. As such, the sensors 121 are non-invasive in that they need not be ingested or in percutaneous, subcutaneous or intravenous form. In one exemplary form, some sensors 121 that are shown generally as being embedded in support tray 120 may otherwise be placed anywhere in or on the wearable electronic device 100 in such a manner as to facilitate acquiring data that in turn may be used by a behaviorist model (including machine learning and CDS variants) that can run as a set of instructions on the system 1 in order to correlate, manipulate and transform the data into a form such that it can provide indicia of one or more LEAP traits associated the wearer of the wearable electronic device 100);
the sensor module comprising a first sensor (Sobol: [0121], [0154], [0157], [0164], [0166]-[0169], and FIG. 2 the activity 121A, the environment 121B, the physiological 121C, and the sensors 121D: The various sensors 121 may be advantageously located on or inside the wearable electronic device 100 such as in or on the housing 110, lateral extensions 111, 112, support tray 120 or the like),
the sensor module comprising:
a sensor subsystem comprising the first sensor (Sobol: [0121], [0154], [0157], [0164], [0166]-[0169], and FIG. 2 the activity 121A, the environment 121B, the physiological 121C, and the sensors 121D: The various sensors 121 may be advantageously located on or inside the wearable electronic device 100 such as in or on the housing 110, lateral extensions 111, 112, support tray 120 or the like),
a communication subsystem (Sobol: [0126], [0129]-[0130], [0154]-[0156], [0168], [0182]-[0185], and FIG. 2 the hybrid wireless communication module 175);
a power subsystem configured to power the sensor subsystem and the communication subsystem (Sobol: [0140]-[0141], [0154]-[0155], and FIG. 2 the battery 180: (ii) the archival of events (for example, acquired LEAP data, system or component status or operability such as remaining life of a battery 180 (that will be discussed in more detail in conjunction with FIG. 2F) that is used to provide electric power to the wearable electronic device 100, time-stamping, alerts or notifications, or the like) sent from the wearable electronic device 100).
Sobol does not explicitly disclose
a component block;
the mounting base configured to removably couple the sensor module to the mounting base;
the sensor module configured to removable couple the component block to the sensor module;
the component block comprising a sensor component block comprising a component block sensor; and
a communication subsystem configured to transmit raw data from the sensor subsystem and the component block sensor and receive a contextualized data.
However, it has been known in the art of monitoring conditions of a user to implement the mounting base configured to removably couple the sensor module to the mounting base, as suggested by Ricci, which discloses the mounting base configured to removably couple the sensor module to the mounting base (Ricci: Abstract, [0093]-[0095], [0105]and FIG. 1 the body 104 and the shell 108 of the wearable device 100: Optionally, one or more of the body 104 and the shell 108 may include fasteners or clasps to align and interconnect to each other. Additionally or alternatively, the body 104 and the shell 108 may include one or more features 140, 144 for alignment, registration, and/or retention. The feature 140 of the body 104 may interact with the feature 144 of the shell 108 to create a predetermined alignment between the body 104 and the shell 108. These keying and/or receiving features 140, 144 may be configured to interface, couple, and/or interconnect the shell 108 to the body 104 or other component, for example as illustrated in FIGS. 1F-1K).
Therefore, in view of teachings by Sobol and Ricci, and it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the wearable device of Sobol to include the mounting base configured to removably couple the sensor module to the mounting base, as suggested by Ricci. The motivation for this is to selectively implement different features of a wearable device for particular activity.
The combination of Sobol and Ricci does not explicitly disclose a communication subsystem configured to transmit raw data from the sensor subsystem and receive a contextualized data.
However, it has been known in the art of managing wearable devices to implement a communication subsystem configured to transmit raw data from the sensor subsystem and receive a contextualized data, as suggested by Awiszus, which discloses a communication subsystem configured to transmit raw data (Awiszus: [0025]: Sensors may include any device that generates data or context information. Such data may generally be referred to herein as usage data or, alternatively, operation data or sensor data. In some examples, usage data may take the form of a stream of samples over a period of time. In some instances, the sensors may be configured to measure operating characteristics of components of the article of PPE, characteristics of a worker using or wearing the article of PPE, and/or environmental factors associated with an environment in which the article of PPE is located, [0033], [0037]-[0039], [0044], and FIG. 1) from the sensor subsystem (Awiszus: [0026], [0037]-[0040], and FIG. 1-2: while respirators 13 (and/or data hubs 14) may typically transmit usage data from sensors of respirators 13 to network 4 in real time or near real time, in some instances, respirators 13 (and/or data hubs 14) may not have connectivity to network 4. In such instances, respirators 13 (and/or data hubs 14) may store usage data locally and transmit the usage data to safety stations 15 upon being in proximity with safety stations 15. Safety stations 15 may then upload the data from respirators 13 and connect to network 4) and receive a contextualized data (Awiszus: [0025], [0037]-[0038], and FIG. 1-2: beacons 17A-17C may be GPS-enabled such that a controller within the respective beacon may be able to precisely determine the position of the respective beacon. Based on wireless communications with one or more of beacons 17, a given respirator 13 or communication hub 14 worn by a worker 10 is configured to determine the location of the worker within work environment 8B. In this way, event data (e.g., usage data) reported to PPEMS 6 may be stamped with positional information to aid analysis, reporting and analytics performed by the PPEMS).
Therefore, in view of teachings by Sobol, Ricci, and Awiszus, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the wearable device of Sobol and Ricci to include a communication subsystem configured to transmit raw data from the sensor subsystem and receive a contextualized data, as suggested by Awiszus. The motivation for this is to selectively implement different features of a wearable device for monitoring particular activity of a user.
The combination of Sobol, Ricci, and Awiszus does not explicitly disclose a component block; the sensor module configured to removable couple the component block to the sensor module; the component block comprising a sensor component block comprising a component block sensor; and a communication subsystem configured to transmit raw data from the sensor subsystem and the component block sensor and receive a data.
However, it has been known in the art of wearable sensors to implement a component block; the sensor module configured to removable couple the component block to the sensor module; the component block comprising a sensor component block comprising a component block sensor; and a communication subsystem configured to transmit raw data from the sensor subsystem and the component block sensor and receive a data, as suggested by Jeong, which discloses
a component block (Jeong: Abstract, [0064]-[0072], and FIG. 3-5: The first interface 2120 may be disposed at a predetermined position of the strap part 2100 of the wearable device 2000 and configured to accommodate the sensor 3000 which is attachable and detachable. The first interface 2120 may receive biological signal detection information from the sensor 3000 that is attached to the wearable device 2000);
the sensor module (Jeong: FIG. 7-8 the sensor 3000) configured to removable couple the component block to the sensor module (Jeong: Abstract, [0052]-[0063], [0069], [0090]-[0101], and FIG. 7-8: the first interface 2120 and the sensor 3000 may have a universal serial bus (USB) connector type such as type A, type B, Mini-A, Mini-B, Micro-A, Micro-B, or Micro-AB. In addition, although FIG. 3A illustrates the first interface 2120 as a male connector (also referred to as a plug) and the sensor as having a female connector (also referred to as a receptacle or a port), one or more other exemplary embodiments are limited thereto. For example, the first interface 2120 may correspond to a USB Type A female connector and the sensor 3000 may have a corresponding USB Type A male connector);
the component block comprising a sensor component block (FIG. 7-8 the sensor 3000 and FIG. 10) comprising a component block sensor (Jeong: [0068], [0098], FIG. 7-8, and FIG. 10: the first interface 2120 may have a pin for connection to ground, a sensing pin for sensing attachment or detachment of the sensor 3000, a power pin for checking a power supply to the attached sensor 3000, a transmitting pin for transmitting data to the attached sensor 3000, a receiving pin for receiving data from the attached sensor 3000, a clock pin for receiving a clock signal, or the like); and
a communication subsystem configured to transmit raw data from the sensor subsystem and the component block sensor and receive a data (Jeong: Abstract, [0052]-[0063], [0069], [0090]-[0101], and FIG. 7-8: the first interface 2120 may have a pin for connection to ground, a sensing pin for sensing attachment or detachment of the sensor 3000, a power pin for checking a power supply to the attached sensor 3000, a transmitting pin for transmitting data to the attached sensor 3000, a receiving pin for receiving data from the attached sensor 3000, a clock pin for receiving a clock signal, or the like);
Therefore, in view of teachings by Sobol, Ricci, Awiszus, and Jeong, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the wearable device of Sobol, Ricci, and Awiszus to include a component block; the sensor module configured to removable couple the component block to the sensor module; the component block comprising a sensor component block comprising a component block sensor; and a communication subsystem configured to transmit raw data from the sensor subsystem and the component block sensor and receive a data, as suggested by Jeong. The motivation for this is to selectively implement different features of a wearable device for monitoring biological information of a user.
As to claim 2, Sobol, Ricci, Awiszus, and Jeong disclose the limitations of claim 1 further comprising the sensor system of claim 1 wherein:
the sensor module housing the power subsystem (Sobol: [0140]-[0141], [0154]-[0155], and FIG. 2 the battery 180: (ii) the archival of events (for example, acquired LEAP data, system or component status or operability such as remaining life of a battery 180 (that will be discussed in more detail in conjunction with FIG. 2F) that is used to provide electric power to the wearable electronic device 100, time-stamping, alerts or notifications, or the like) sent from the wearable electronic device 100, Ricci: Abstract, [0128]-[0129], and FIG. 2 the power source and power control module 260A, and Awiszus: [0106]-[0108], FIG. 3-4, and FIG. 8), the sensor subsystem (Sobol: [0121], [0154], [0157], [0164], [0166]-[0169], and FIG. 2 the activity 121A, the environment 121B, the physiological 121C, and the sensors 121D: The various sensors 121 may be advantageously located on or inside the wearable electronic device 100 such as in or on the housing 110, lateral extensions 111, 112, support tray 120 or the like) and the communication subsystem (Sobol: [0126], [0129]-[0130], [0154]-[0156], [0168], [0182]-[0185], and FIG. 2 the hybrid wireless communication module 175); and
the sensor module is configured to removably couple the sensor module to the mounting base whereby a first sensor module with the first sensor coupled to the mounting base can be exchanged with a second sensor module with a second sensor (Ricci: Abstract, [0093]-[0095], [0105]and FIG. 1 the body 104 and the shell 108 of the wearable device 100: Optionally, one or more of the body 104 and the shell 108 may include fasteners or clasps to align and interconnect to each other. Additionally or alternatively, the body 104 and the shell 108 may include one or more features 140, 144 for alignment, registration, and/or retention. The feature 140 of the body 104 may interact with the feature 144 of the shell 108 to create a predetermined alignment between the body 104 and the shell 108. These keying and/or receiving features 140, 144 may be configured to interface, couple, and/or interconnect the shell 108 to the body 104 or other component, for example as illustrated in FIGS. 1F-1K and Jeong: Abstract, [0052]-[0063], [0069], [0079]-[0080], [0090]-[0101], FIG. 5, and FIG. 7-8: if a type of the sensor 3000 varies according to a type of a biological signal, a user of the wearable device 2000 has to attach different types of the sensors 3000 to the wearable device 2000. Alternatively, if it is required to simultaneously detect biological signals from several body parts of the user, the user of the wearable device 2000 may have to attach one type of the sensors 3000 to the wearable device 2000. Thus, the user may attach different types or one type of the sensors 3000 to the first interface 2120 of the wearable device 2000 that includes the sub-interfaces 2122).
As to claim 3, Sobol, Ricci, Awiszus, and Jeong disclose the limitations of claim 1 further comprising the sensor system of claim 1 wherein:
the sensor module housing the power subsystem (Sobol: [0140]-[0141], [0154]-[0155], and FIG. 2 the battery 180: (ii) the archival of events (for example, acquired LEAP data, system or component status or operability such as remaining life of a battery 180 (that will be discussed in more detail in conjunction with FIG. 2F) that is used to provide electric power to the wearable electronic device 100, time-stamping, alerts or notifications, or the like) sent from the wearable electronic device 100, Ricci: Abstract, [0128]-[0129], and FIG. 2 the power source and power control module 260A, and Awiszus: [0106]-[0108], FIG. 3-4, and FIG. 8), the sensor subsystem (Sobol: [0121], [0154], [0157], [0164], [0166]-[0169], and FIG. 2 the activity 121A, the environment 121B, the physiological 121C, and the sensors 121D: The various sensors 121 may be advantageously located on or inside the wearable electronic device 100 such as in or on the housing 110, lateral extensions 111, 112, support tray 120 or the like) and the communication subsystem (Sobol: [0126], [0129]-[0130], [0154]-[0156], [0168], [0182]-[0185], and FIG. 2 the hybrid wireless communication module 175);
the sensor module is configured to removably couple the sensor module to the mounting base whereby the first sensor module with a first sensor coupled to the mounting base can be exchanged with a second sensor module with a second sensor (Ricci: Abstract, [0093]-[0095], [0105]and FIG. 1 the body 104 and the shell 108 of the wearable device 100: Optionally, one or more of the body 104 and the shell 108 may include fasteners or clasps to align and interconnect to each other. Additionally or alternatively, the body 104 and the shell 108 may include one or more features 140, 144 for alignment, registration, and/or retention. The feature 140 of the body 104 may interact with the feature 144 of the shell 108 to create a predetermined alignment between the body 104 and the shell 108. These keying and/or receiving features 140, 144 may be configured to interface, couple, and/or interconnect the shell 108 to the body 104 or other component, for example as illustrated in FIGS. 1F-1K and Jeong: Abstract, [0052]-[0063], [0069], [0079]-[0080], [0090]-[0101], FIG. 5, and FIG. 7-8: if a type of the sensor 3000 varies according to a type of a biological signal, a user of the wearable device 2000 has to attach different types of the sensors 3000 to the wearable device 2000. Alternatively, if it is required to simultaneously detect biological signals from several body parts of the user, the user of the wearable device 2000 may have to attach one type of the sensors 3000 to the wearable device 2000. Thus, the user may attach different types or one type of the sensors 3000 to the first interface 2120 of the wearable device 2000 that includes the sub-interfaces 2122); and
the mounting base is configured to be mounted on a limb of a worker whereby the first sensor module can be exchanged with the second sensor module while the mounting base is mounted on the limb of the worker (Sobol: [0023], [0152], [0154], [0192]-[0194], and FIG. 1-2, Ricci: [0015], [0017], [0054], [0083]-[0084], [0109], and FIG. 1-2: although the band 120 is illustrated having a closed or substantially circular form, it will be appreciated that the band may have a shape that is at least partially open, such as similar to a bracelet. In this manner, the user may position the body 104 on the user's wrist or ankle by at least partially bending two portions of the band 120 apart, Awiszus: [0138], FIG. 1, FIG. 3 and FIG. 6-8 and Jeong: Abstract, [0052]-[0063], [0069], [0079]-[0080], [0090]-[0101], FIG. 5, and FIG. 7-8: The body part of the user who wears the wearable device 2000 may indicate a part of a body from which the detection-target biological signal is detected. For example, the body part of the user who wears the wearable device 2000 may include a wrist, an ankle, a head, a neck, an arm, or the like).
As to claim 4, Sobol, Ricci, Awiszus, and Jeong disclose the limitations of claim 1 further comprising the sensor system of claim 1 wherein the first sensor comprises an optical sensor (Sobol: [0192] and FIG. 1-2: the circuit layer may be formed by known methods such as textiles, thin-film printing (including ink jet, flexography, screen, gravure or the like), and may include circuitry configured to include one or more of an accelerometer, gyroscope, temperature sensor, strain moisture sensor, acoustic sensor, inertial sensor, optical sensor, pressure sensor, chemical sensor or the like and Jeong: Abstract, [0052]-[0063], [0069], [0079]-[0080], [0090]-[0101], FIG. 5, FIG. 7-8 and FIG. 10: the sensor 3000 may include an irradiator 3100, a detector 3200, and a sensor interface 3300. If the sensor 3000 of FIG. 2 is a photo-sensor that uses light, the irradiator 3100 may have a light source and may irradiate the body part using the light source. The detector 3200 may detect light that is reflected from a biological tissue and may include a photoelectric conversion device such as a photodiode. The irradiator 3100 and the detector 3200 may be disposed on a same surface of the sensor 3000).
As to claim 5, Sobol, Ricci, Awiszus, and Jeong disclose the limitations of claim 1 further comprising the sensor system of claim 1 wherein:
the sensor subsystem comprises an optical sensor (Jeong: Abstract, [0052]-[0063], [0090]-[0101], and FIG. 7-8: the second interface 2330 may receive biological signal detection information from the sensor 3000 that is attached to the wearable device 2000. Also, the second interface 2330 may receive a biological signal that is detected by the attached sensor 3000. Here, in a case of the photo-sensor such as the sensor 3000 shown in FIG. 6, the biological signal detection information may include information about a wavelength and intensity of light that is radiated by the sensor 3000 attached to the wearable device 2000); and
the mounting base comprises an opening configured to allow the optical sensor to be proximal to a portion of a skin of a wearer when the optical sensor is coupled to the mounting base and the mounting base is mounted on a limb of a wearer (Jeong: Abstract, [0052]-[0063], [0090]-[0101], and FIG. 7-8: when the wearable device 2000 is a watch-type wearable device, a predetermined portion of the exterior case of the main body 2300 that contacts the body part of the user who wears the wearable device 2000 may be transparent. For example, in a case of the photo-sensor such as the sensor 3000 shown in FIG. 6, the photo-sensor may radiate light to the body part of the user so as to detect a biological signal. When the sensor 3000 is attached to the second interface 2330 in the main body 2300 of the wearable device 2000, the predetermined portion of the exterior case of the main body 2300 that corresponds to an radiation path of the light may be formed of a transparent material in order to allow the light to pass through the predetermined portion of the exterior case so as to irradiate the body part of the user).
As to claim 6, Sobol, Ricci, Awiszus and Jeong disclose the limitations of claim 1 further comprising the sensor system of claim 1 wherein the first sensor comprises a sensor selected from the group consisting of:
an environmental sensor;
a location sensor;
a physiological sensor;
a behavior sensor; and
a posture sensor (Sobol: [0121], [0154], [0157], [0164], [0166]-[0169], and FIG. 2 the activity 121A, the environment 121B, the physiological 121C, and the sensors 121D: The various sensors 121 may be advantageously located on or inside the wearable electronic device 100 such as in or on the housing 110, lateral extensions 111, 112, support tray 120 or the like, Ricci: [0011], [0054], [0093], [0102], [0110], [0124]-[0126], and FIG. 1-2: The body 104 and the shell 108 may include any number of electronic components, typically one or more of a processor, memory, accelerometer, gyroscope, GPS or other sensor, and a communications module as described in more detail below, and Awiszus: [0026], [0033], [0037]-[0040], [0147], and FIG. 1-2: Sensors 808 may include, as examples, one or more accelerometers, one or more sensors to detect conditions present in a particular environment (e.g., sensors for measuring temperature, humidity, particulate content, noise levels, air quality, or any variety of other characteristics of environments in which respirator 13 may be used), or a variety of other sensors).
As to claim 7, Sobol, Ricci, Awiszus and Jeong disclose the limitations of claim 2 further comprising the sensor system of claim 2 wherein the mounting base further comprises a base coupling element configured to removably couple the sensor module to the mounting base (Sobol: [0121], [0154], [0157], [0164], [0166]-[0169], and FIG. 2 the activity 121A, the environment 121B, the physiological 121C, and the sensors 121D: The various sensors 121 may be advantageously located on or inside the wearable electronic device 100 such as in or on the housing 110, lateral extensions 111, 112, support tray 120 or the like. As such, the sensors 121 are non-invasive in that they need not be ingested or in percutaneous, subcutaneous or intravenous form. In one exemplary form, some sensors 121 that are shown generally as being embedded in support tray 120 may otherwise be placed anywhere in or on the wearable electronic device 100 in such a manner as to facilitate acquiring data that in turn may be used by a behaviorist model (including machine learning and CDS variants) that can run as a set of instructions on the system 1 in order to correlate, manipulate and transform the data into a form such that it can provide indicia of one or more LEAP traits associated the wearer of the wearable electronic device 100, Ricci: Abstract, [0093]-[0095], [0105]and FIG. 1 the body 104 and the shell 108 of the wearable device 100: Optionally, one or more of the body 104 and the shell 108 may include fasteners or clasps to align and interconnect to each other. Additionally or alternatively, the body 104 and the shell 108 may include one or more features 140, 144 for alignment, registration, and/or retention. The feature 140 of the body 104 may interact with the feature 144 of the shell 108 to create a predetermined alignment between the body 104 and the shell 108. These keying and/or receiving features 140, 144 may be configured to interface, couple, and/or interconnect the shell 108 to the body 104 or other component, for example as illustrated in FIGS. 1F-1K and Jeong: Abstract, [0052]-[0063], [0069], [0079]-[0080], [0090]-[0101], FIG. 5, and FIG. 7-8: if a type of the sensor 3000 varies according to a type of a biological signal, a user of the wearable device 2000 has to attach different types of the sensors 3000 to the wearable device 2000. Alternatively, if it is required to simultaneously detect biological signals from several body parts of the user, the user of the wearable device 2000 may have to attach one type of the sensors 3000 to the wearable device 2000. Thus, the user may attach different types or one type of the sensors 3000 to the first interface 2120 of the wearable device 2000 that includes the sub-interfaces 2122).
As to claim 8, Sobol, Ricci, Awiszus and Jeong disclose the limitations of claim 7 further comprising the sensor system of claim 7 wherein:
the sensor module further comprises a sensor module coupling element configured to removably couple the sensor module to the component block (Jeong: Abstract, [0052]-[0063], [0069], [0090]-[0101], and FIG. 7-8: the first interface 2120 and the sensor 3000 may have a universal serial bus (USB) connector type such as type A, type B, Mini-A, Mini-B, Micro-A, Micro-B, or Micro-AB. In addition, although FIG. 3A illustrates the first interface 2120 as a male connector (also referred to as a plug) and the sensor as having a female connector (also referred to as a receptacle or a port), one or more other exemplary embodiments are limited thereto. For example, the first interface 2120 may correspond to a USB Type A female connector and the sensor 3000 may have a corresponding USB Type A male connector);
the component block comprising a component block coupling element configured to removably mate with the sensor module coupling element; the component block coupling element comprises one or more pliant clasp; and the sensor module coupling element comprises one or more recesses to receive a portion of the pliant clasp (Jeong: Abstract, [0052]-[0063], [0090]-[0101], and FIG. 7-8: when the wearable device 2000 is a watch-type wearable device, a predetermined portion of the exterior case of the main body 2300 that contacts the body part of the user who wears the wearable device 2000 may be transparent. For example, in a case of the photo-sensor such as the sensor 3000 shown in FIG. 6, the photo-sensor may radiate light to the body part of the user so as to detect a biological signal. When the sensor 3000 is attached to the second interface 2330 in the main body 2300 of the wearable device 2000, the predetermined portion of the exterior case of the main body 2300 that corresponds to an radiation path of the light may be formed of a transparent material in order to allow the light to pass through the predetermined portion of the exterior case so as to irradiate the body part of the user).
As to claim 10, Sobol, Ricci, Awiszus and Jeong disclose the limitations of claim 8 further comprising the sensor system of claim 8 wherein the component block sensor comprises at least one sensor selected from the group consisting of:
an environmental sensor;
a location sensor;
a behavior sensor; and
a posture sensor (Sobol: [0121], [0154], [0157], [0164], [0166]-[0169], [0192], and FIG. 2 the activity 121A, the environment 121B, the physiological 121C, and the sensors 121D: The various sensors 121 may be advantageously located on or inside the wearable electronic device 100 such as in or on the housing 110, lateral extensions 111, 112, support tray 120 or the like, Ricci: [0011], [0054], [0093], [0102], [0110], [0124]-[0126], and FIG. 1-2: The body 104 and the shell 108 may include any number of electronic components, typically one or more of a processor, memory, accelerometer, gyroscope, GPS or other sensor, and a communications module as described in more detail below, Awiszus: [0026], [0033], [0037]-[0040], [0147], and FIG. 1-2: Sensors 808 may include, as examples, one or more accelerometers, one or more sensors to detect conditions present in a particular environment (e.g., sensors for measuring temperature, humidity, particulate content, noise levels, air quality, or any variety of other characteristics of environments in which respirator 13 may be used), or a variety of other sensors and Jeong: Abstract, [0052]-[0063], [0069], [0090]-[0101], and FIG. 7-8: the first interface 2120 and the sensor 3000 may have a universal serial bus (USB) connector type such as type A, type B, Mini-A, Mini-B, Micro-A, Micro-B, or Micro-AB. In addition, although FIG. 3A illustrates the first interface 2120 as a male connector (also referred to as a plug) and the sensor as having a female connector (also referred to as a receptacle or a port), one or more other exemplary embodiments are limited thereto. For example, the first interface 2120 may correspond to a USB Type A female connector and the sensor 3000 may have a corresponding USB Type A male connector).
As to claim 11, Sobol, Ricci, Awiszus, and Jeong disclose the limitations of claim 8 except for the claimed limitations of the sensor system of claim 8 wherein the component block comprises a communication component block comprising a communication protocol module programmed to communicate according to a communication protocol selected from the group consisting of: a Bluetooth protocol; a 802.11 protocol; and a LoRa protocol (Ricci: [0116] and FIG. 2: the body 104 and shell 108 can include an additional or other wireless communications module 232, 232A. As examples, the other wireless communications module 232 can comprise a Wi-Fi, Bluetooth™, WiMax, infrared, NFC, RFID, or other wireless communications link. The wireless communications module may be configured to send and/or receive data between the body 104 and the shell 108, a pairing or docking station, other wearable devices, and/or other peripheral devices. The cellular telephony module 228A and the other wireless communications module 232 can each be associated with a shared or a dedicated antenna 224, 224A).
As to claim 12, Sobol, Ricci, Awiszus, and Jeong disclose the limitations of claim 1 further comprising the sensor system of claim 1 further comprising a monitoring subsystem configured to determine a contextualized state of a worker (Awiszus: [0029], [0061-[0063], [0081], [0086], [0154], FIG. 1, and FIG. 8: In general, a safety event may refer to activities of a user of personal protective equipment (PPE), a condition of the PPE, or an environmental condition (e.g., which may be hazardous). In some examples, a safety event may be an injury or worker condition, workplace harm, or regulatory violation. For example, in the context of fall protection equipment, a safety event may be misuse of the fall protection equipment, a user of the fall equipment experiencing a fall, or a failure of the fall protection equipment. In the context of a respirator, a safety event may be misuse of the respirator, a user of the respirator not receiving an appropriate quality and/or quantity of air, or failure of the respirator. A safety event may also be associated with a hazard in the environment in which the PPE is located. In some examples, occurrence of a safety event associated with the article of PPE may include a safety event in the environment in which the PPE is used or a safety event associated with a worker using the article of PPE. In some examples, a safety event may be an indication that PPE, a worker, and/or a worker environment are operating, in use, or acting in a way that is normal operation, where normal operation is a predetermined or predefined condition of acceptable or safe operation, use, or activity) from a sensor data from the sensor module (Awiszus: [0025]: Sensors may include any device that generates data or context information. Such data may generally be referred to herein as usage data or, alternatively, operation data or sensor data. In some examples, usage data may take the form of a stream of samples over a period of time. In some instances, the sensors may be configured to measure operating characteristics of components of the article of PPE, characteristics of a worker using or wearing the article of PPE, and/or environmental factors associated with an environment in which the article of PPE is located, [0033], [0037]-[0039], [0044], and FIG. 1).
As to claim 13, Sobol, Ricci, Awiszus, and Jeong disclose the limitations of claim 1 further comprising the sensor system of claim 1 further comprising a monitoring subsystem comprising a situation classifier (Awiszus: [0061]-[0062], [0067]-[0068], and FIG. 2 the event selector 68B, the event processor 68 C, and the HP event processor 68D and FIG. 8: Event selector 68B operates on the stream of events 69 received from PPEs 62 and/or hubs 14 via frontend 68A and determines, based on rules or classifications, priorities associated with the incoming events. Based on the priorities, event selector 68B enqueues the events for subsequent processing by event processor 68C or high priority (HP) event processor 68D) configured to determine a contextualized state of a worker (Awiszus: [0029], [0061-[0063], [0081], [0086], [0154], FIG. 1, and FIG. 8: In general, a safety event may refer to activities of a user of personal protective equipment (PPE), a condition of the PPE, or an environmental condition (e.g., which may be hazardous). In some examples, a safety event may be an injury or worker condition, workplace harm, or regulatory violation. For example, in the context of fall protection equipment, a safety event may be misuse of the fall protection equipment, a user of the fall equipment experiencing a fall, or a failure of the fall protection equipment. In the context of a respirator, a safety event may be misuse of the respirator, a user of the respirator not receiving an appropriate quality and/or quantity of air, or failure of the respirator. A safety event may also be associated with a hazard in the environment in which the PPE is located. In some examples, occurrence of a safety event associated with the article of PPE may include a safety event in the environment in which the PPE is used or a safety event associated with a worker using the article of PPE. In some examples, a safety event may be an indication that PPE, a worker, and/or a worker environment are operating, in use, or acting in a way that is normal operation, where normal operation is a predetermined or predefined condition of acceptable or safe operation, use, or activity) from a sensor data from the sensor module (Awiszus: [0025]: Sensors may include any device that generates data or context information. Such data may generally be referred to herein as usage data or, alternatively, operation data or sensor data. In some examples, usage data may take the form of a stream of samples over a period of time. In some instances, the sensors may be configured to measure operating characteristics of components of the article of PPE, characteristics of a worker using or wearing the article of PPE, and/or environmental factors associated with an environment in which the article of PPE is located, [0033], [0037]-[0039], [0044], and FIG. 1).
As to claim 14, Sobol, Ricci, Awiszus, and Jeong disclose the limitations of claim 1 further comprising the sensor system of claim 1 further comprising:
a monitoring subsystem (Awiszus: FIG. 1 the personal protection equipment management system (PPEMS) 2) in communication with the communication subsystem (Awiszus: [0051]-[0056] and FIG. 2: In FIG. 2, personal protection equipment (PPEs) 62, such as SRLs 11, respirators 13 and/or other equipment, either directly or by way of hubs 14, as well as computing devices 60, operate as clients 63 that communicate with PPEMS 6 via interface layer 64);
the monitoring subsystem (Awiszus: FIG. 1 the personal protection equipment management system (PPEMS) 2) configured to receive the first sensor data from a first sensor of the sensor module for a time (Awiszus: Abstract, [0033], [0105], [0107], [0109], [0122], [0124], [0130]-[0132], and FIG. 4-5: position sensor 111 may detect whether visor 112 is partially open, and if so, what measure (e.g., percent or degree) it is open. As an example, the position sensor 110 may be a gyroscope that computes angular yaw, pitch, and/or roll (in degrees or radians) of the visor 112 relative to the helmet 118. In another example, the position sensor 110 may be a magnet. A percent may be estimated respecting how open a visor 112 is in relation to the helmet 118 by determining the magnetic field strength or flux perceived by the position sensor 110. “Partially open” visor information can be used to denote that the user may be receiving eye and face protection for hazards while still receiving a reasonable amount of respiratory protection. This “partially open” visor state, if kept to short durations, can assist the user in face to face communications with other workers. Position sensor 111 can be a variety of types of sensors, for example, an accelerometer, gyro, magnet, switch, potentiometer, digital positioning sensor or air pressure sensor. Position sensor 111 can also be a combination of any of the sensors listed above, or any other types of sensors that can be used to detected the position of the visor 112 relative to the helmet 118. Head top 110 may be supported on a user's head by a suspension (not shown)) and a second sensor data from a second sensor of the sensor module for the time (Awiszus: [0147], FIG. 8, FIG. 10, and FIG. 16: Sensors 808 may include one or more sensors that generate data indicative of an activity of a worker 10 associated with hub 14 and/or data indicative of an environment in which hub 14 is located. Sensors 808 may include, as examples, one or more accelerometers, one or more sensors to detect conditions present in a particular environment (e.g., sensors for measuring temperature, humidity, particulate content, noise levels, air quality, or any variety of other characteristics of environments in which respirator 13 may be used), or a variety of other sensors);
the monitoring subsystem comprising:
an expert subsystem (Awiszus: FIG. 2 the services 68 comprising the event endpoint frontend 68A, the event selector 68B, the event processor 68C, the HP event processor 68D, the notification service 68E, the stream analytics service 68F, the record management and reporting service 68G, the security service 68 H and the rule configuration component 68I and FIG. 8) comprising a situation classifier module (Awiszus: [0061]-[0062], [0067]-[0068], and FIG. 2 the event selector 68B, the event processor 68 C, and the HP event processor 68D and FIG. 8: Event selector 68B operates on the stream of events 69 received from PPEs 62 and/or hubs 14 via frontend 68A and determines, based on rules or classifications, priorities associated with the incoming events. Based on the priorities, event selector 68B enqueues the events for subsequent processing by event processor 68C or high priority (HP) event processor 68D) and an intervention/alert module (Awiszus: [0027], [0029], [0046], [0049], [0062], [0067]-[0069], FIG. 2 the notification service 68E, and FIG. 8: Based on the priorities, event selector 68B enqueues the events for subsequent processing by event processor 68C or high priority (HP) event processor 68D. Additional computational resources and objects may be dedicated to HP event processor 68D so as to ensure responsiveness to critical events, such as incorrect usage of PPEs, use of incorrect filters and/or respirators based on geographic locations and conditions, failure to properly secure SRLs 11 and the like. Responsive to processing high priority events, HP event processor 68D may immediately invoke notification service 68E to generate alerts, instructions, warnings or other similar messages to be output to SRLs 11, respirators 13, hubs 14 and/or remote users 20, 24. Events not classified as high priority are consumed and processed by event processor 68C),
a subsystem database (Awiszus: FIG. 2 the data repositories 74 comprising the event data 74A, the historical data and models 74 B, the audit 74C, the configuration 74D, the self check criteria 74E, and the work relation data 74F) comprising contextualization rules (Awiszus: [0043]-[0044], [0067]-[0068], [0078]-[0081], FIG. 2, and FIG. 8) and a library of alert rules (Awiszus: [0027], [0037], [0072]-[0073], [0079]-[0081], and FIG. 1-2: storing the safety rules may include associating a safety rule with context data, such that rule configuration component 68I may perform a lookup to select safety rules associated with matching context data. Context data may include any data describing or characterizing the properties or operation of a worker, worker environment, article of PPE, or any other entity. Context data of a worker may include, but is not limited to: a unique identifier of a worker, type of worker, role of worker, physiological or biometric properties of a worker, experience of a worker, training of a worker, time worked by a worker over a particular time interval, location of the worker, or any other data that describes or characterizes a worker),
the situation classifier module is configured to determine a first contextualized situation at the time from the first sensor data using the contextualization rules (Awiszus: [0029], [0061-[0063], [0081], [0086], [0154], FIG. 1, and FIG. 8: In general, a safety event may refer to activities of a user of personal protective equipment (PPE), a condition of the PPE, or an environmental condition (e.g., which may be hazardous). In some examples, a safety event may be an injury or worker condition, workplace harm, or regulatory violation. For example, in the context of fall protection equipment, a safety event may be misuse of the fall protection equipment, a user of the fall equipment experiencing a fall, or a failure of the fall protection equipment. In the context of a respirator, a safety event may be misuse of the respirator, a user of the respirator not receiving an appropriate quality and/or quantity of air, or failure of the respirator. A safety event may also be associated with a hazard in the environment in which the PPE is located. In some examples, occurrence of a safety event associated with the article of PPE may include a safety event in the environment in which the PPE is used or a safety event associated with a worker using the article of PPE. In some examples, a safety event may be an indication that PPE, a worker, and/or a worker environment are operating, in use, or acting in a way that is normal operation, where normal operation is a predetermined or predefined condition of acceptable or safe operation, use, or activity),
the situation classifier module is configured to determine a second contextualized situation at the time (Awiszus: [0029], [0061-[0063], [0081], [0086], [0154], FIG. 1, and FIG. 8) from the first sensor data and the second sensor data (Awiszus: [0025]: Sensors may include any device that generates data or context information. Such data may generally be referred to herein as usage data or, alternatively, operation data or sensor data. In some examples, usage data may take the form of a stream of samples over a period of time. In some instances, the sensors may be configured to measure operating characteristics of components of the article of PPE, characteristics of a worker using or wearing the article of PPE, and/or environmental factors associated with an environment in which the article of PPE is located, [0033], [0037]-[0039], [0044], and FIG. 1) using the contextualization rules (Awiszus: [0029], [0061-[0063], [0081], [0086], [0154], FIG. 1, and FIG. 8: In general, a safety event may refer to activities of a user of personal protective equipment (PPE), a condition of the PPE, or an environmental condition (e.g., which may be hazardous). In some examples, a safety event may be an injury or worker condition, workplace harm, or regulatory violation. For example, in the context of fall protection equipment, a safety event may be misuse of the fall protection equipment, a user of the fall equipment experiencing a fall, or a failure of the fall protection equipment. In the context of a respirator, a safety event may be misuse of the respirator, a user of the respirator not receiving an appropriate quality and/or quantity of air, or failure of the respirator. A safety event may also be associated with a hazard in the environment in which the PPE is located. In some examples, occurrence of a safety event associated with the article of PPE may include a safety event in the environment in which the PPE is used or a safety event associated with a worker using the article of PPE. In some examples, a safety event may be an indication that PPE, a worker, and/or a worker environment are operating, in use, or acting in a way that is normal operation, where normal operation is a predetermined or predefined condition of acceptable or safe operation, use, or activity),
the intervention/alert module configured to compare the first contextualized situation to the library of alert rules (Awiszus: [0067]-[0068], [0079]-[0082], [0090], [0100], and Table 4: PPEMS 6 may determine that a visor of a respirator 13 is up in hazardous work area. PPEMS 6 may also determine that a worker 10 is fitted with improper equipment (e.g., an improper filter for a specified area), or that a worker 10 is present in a restricted/closed area. PPEMS 6 may also determine whether worker temperature exceeds a threshold, e.g., in order to prevent heat stress. PPEMS 6 may also determine when a worker 10 has experienced an impact, such as a fall) to determine whether an alert situation has occurred at the time (Awiszus: [0027]: the output may be used to alert the user of the article of PPE that the safety event is likely to occur, allowing the user to alter their behavior. In other examples, circuitry embedded within the respirators or processors within intermediate data hubs more local to the workers may be programmed via the PPEMS or other mechanism to apply models or rule sets determined by the PPEMS so as to locally generate and output alerts or other preventative measure designed to avoid or mitigate a predicted safety event, [0029], [0039], [0046], [0049], [0062], [0069], FIG. 2 the notification service 68E, and FIG. 8: Based on the priorities, event selector 68B enqueues the events for subsequent processing by event processor 68C or high priority (HP) event processor 68D. Additional computational resources and objects may be dedicated to HP event processor 68D so as to ensure responsiveness to critical events, such as incorrect usage of PPEs, use of incorrect filters and/or respirators based on geographic locations and conditions, failure to properly secure SRLs 11 and the like. Responsive to processing high priority events, HP event processor 68D may immediately invoke notification service 68E to generate alerts, instructions, warnings or other similar messages to be output to SRLs 11, respirators 13, hubs 14 and/or remote users 20, 24. Events not classified as high priority are consumed and processed by event processor 68C ), and
the intervention/alert module configured to compare the second contextualized situation to the library of alert rules (Awiszus: [0067]-[0068], [0079]-[0082], [0090], [0100], and Table 4: In the example of FIG. 2, a safety manager may initially configure one or more safety rules. As such, remote user 24 may provide one or more user inputs at computing device 18 that configure a set of safety rules for work environment 8A and 8B. For instance, a computing device 60 of the safety manager may send a message that defines or specifies the safety rules. Such message may include data to select or create conditions and actions of the safety rules. PPEMS 6 may receive the message at interface layer 64 which forwards the message to rule configuration component 68I. Rule configuration component 68I may be combination of hardware and/or software that provides for rule configuration including, but not limited to: providing a user interface to specify conditions and actions of rules, receive, organize, store, and update rules included in safety rules data store 74E) to determine whether the alert situation has occurred at the time (Awiszus: [0039], [0044], [0086], [0090], [0093]-[0094], [0098]-[0100], and FIG. 1: PPEMS 6 may generate, in some examples, a warning when worker 10 is near a hazard in one of environments 8 (e.g., based on location data gathered from a location sensor (GPS or the like) of respirators 13). PPEMS 6 may also applying usage data to a safety learning model that characterizes a temperature of worker 10. In this example, PPEMS 6 may determine that the temperature exceeds a temperature associated with safe activity over the time period and alert worker 10 to the potential for a safety event due to the temperature).
The combination of Sobol, Ricci, and Awiszus does not explicitly disclose
whereby if the alert situation has occurred at the time based on the first contextualized situation, but the alert situation has not occurred at the time based on the second contextualized situation, the monitoring subsystem configured to not communicate an alert; and
whereby if the alert situation has occurred at the time based on the first contextualized situation, and the alert situation has occurred at the time based on the second contextualized situation, the monitoring subsystem configured to communicate an alert.
However, in one embodiment, Awiszus discloses the analytics service (Awiszus: FIG. 2) receives various information from the one or more sensors associated with the users and environment (Awiszus: FIG. 1) wherein the information of the one or more sensors associated with the users (Awiszus: [0087], [0090]-[0091], [0094], and FIG. 5: PPEMS 6 may also perform fall data analysis after a fall has occurred and/or determine temperature, humidity and other environmental conditions as they relate to the likelihood of safety events) and environment are combined and based on alert rules before activating an alert (Awiszus: [0029], [0037],[0039]: For example, PPEMS 6 may utilize the environmental data to aid generating alerts or other instructions for respirators 13 and for performing predictive analytics, such as determining any correlations between certain environmental conditions (e.g., heat, humidity, visibility) with abnormal worker behavior or increased safety events. As such, PPEMS 6 may utilize current environmental conditions to aid prediction and avoidance of imminent safety events. Example environmental conditions that may be sensed by sensing stations 21 include but are not limited to temperature, humidity, presence of gas, pressure, visibility, wind and the like, [0127]-[0128], [0223], [0246], [0249]-[0250], and FIG. 5: if a hazard is not detected, the computing device returns to operation to query whether the visor is open. If a hazard is detected in step 330, an alert is generated (340). A variety of types of alerts may be generated. For example, an alert may comprise one or more of the following types of signals: tactile, vibration, audible, visual, heads-up display or radio frequency signal. In some instances, an alert is not generated unless an exposure threshold and/or a hazard threshold is first met).
Therefore, in view of teachings by Awiszus, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the monitoring system of Awiszus to include if the alert situation has occurred based on the first contextualized situation, but the alert situation has not occurred based on the second contextualized situation, the monitoring subsystem configured to not communicate an alert; and if the alert situation has occurred based on the first contextualized situation, and the alert situation has occurred based on the second contextualized situation, the monitoring subsystems configured to communicate an alert, as suggested by Awiszus, as desired. The motivation for this is to combine various monitoring information regarding about a user and an environment where the user is located in order to provide an appropriate corrective actions.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Sobol et al. (Sobol – US 2019/0209022 A1) in view of Ricci (Ricci – US 2016/0266606 A1) and Awiszus et al. (Awiszus – US 2019/0175411 A1) and further in view of Jeong (Jeong – US 2016/0100758 A1) and further in view of Kita (Kita – US 2001/0043514 A1).
As to claim 9, Sobol, Ricci, Awiszus, and Jeong disclose the limitations of claim 8 except for the claimed limitations of the sensor system of claim 8 wherein the component block comprises one selected from the group consisting of:
a power component block; and
a battery clock component block.
However, it has been known in the art of wearable device to implement wherein the component block comprises one selected from the group consisting of:
a power component block; and
a battery clock component block, as suggested by Kita, which discloses wherein the component block comprises one selected from the group consisting of:
a power component block (Kita: [0184], and FIG. 18 the power supply module unit 26: a power supply module unit 26 are removably mounted on the other wrist band 15); and
a battery clock component block.
Therefore, in view of teachings by Sobol, Ricci, Awiszus, Jeong, and Kita, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement the wearable device of Sobol, Ricci, Awiszus, and Jeong to include wherein the component block comprises one selected from the group consisting of:
a power component block; and
a battery clock component block, as suggested by Kita. The motivation for this is to implement known alternative function blocks for wearable devices.
Claims 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Awiszus et al. (Awiszus – US 2019/0175411 A1).
As to claim 15, Awiszus discloses a processor based contextualized sensor system comprising:
a body area subsystem (Awiszus: FIG. 1 the respirators 13A-13N and the wearable communication hubs 14A-14N, FIG. 3-4 and FIG. 8 the communication hub 130) comprising:
a first sensor (Awiszus: FIG. 4 the head top 210 comprising the position sensor 211) configured to communicate a first sensor data from a time (Awiszus: Abstract, [0033], [0105], [0107], [0109], [0122], [0124], [0130]-[0132], and FIG. 4-5: position sensor 111 may detect whether visor 112 is partially open, and if so, what measure (e.g., percent or degree) it is open. As an example, the position sensor 110 may be a gyroscope that computes angular yaw, pitch, and/or roll (in degrees or radians) of the visor 112 relative to the helmet 118. In another example, the position sensor 110 may be a magnet. A percent may be estimated respecting how open a visor 112 is in relation to the helmet 118 by determining the magnetic field strength or flux perceived by the position sensor 110. “Partially open” visor information can be used to denote that the user may be receiving eye and face protection for hazards while still receiving a reasonable amount of respiratory protection. This “partially open” visor state, if kept to short durations, can assist the user in face to face communications with other workers. Position sensor 111 can be a variety of types of sensors, for example, an accelerometer, gyro, magnet, switch, potentiometer, digital positioning sensor or air pressure sensor. Position sensor 111 can also be a combination of any of the sensors listed above, or any other types of sensors that can be used to detected the position of the visor 112 relative to the helmet 118. Head top 110 may be supported on a user's head by a suspension (not shown)), and
a second sensor (Awiszus: FIG. 8 the sensors 808) configured to communicate a second sensor data from the time (Awiszus: [0147], FIG. 8, FIG. 10, and FIG. 16: Sensors 808 may include one or more sensors that generate data indicative of an activity of a worker 10 associated with hub 14 and/or data indicative of an environment in which hub 14 is located. Sensors 808 may include, as examples, one or more accelerometers, one or more sensors to detect conditions present in a particular environment (e.g., sensors for measuring temperature, humidity, particulate content, noise levels, air quality, or any variety of other characteristics of environments in which respirator 13 may be used), or a variety of other sensors);
a monitoring subsystem (Awiszus: FIG. 1 the personal protection equipment management system (PPEMS) 2) comprising:
a message broker (Awiszus: FIG. 2 the interface layer 64) configured to receive the first sensor data, the second sensor data and the time from the body area subsystem (Awiszus: [0051]-[0056] and FIG. 2: In FIG. 2, personal protection equipment (PPEs) 62, such as SRLs 11, respirators 13 and/or other equipment, either directly or by way of hubs 14, as well as computing devices 60, operate as clients 63 that communicate with PPEMS 6 via interface layer 64),
an expert subsystem (Awiszus: FIG. 2 the services 68 comprising the event endpoint frontend 68A, the event selector 68B, the event processor 68C, the HP event processor 68D, the notification service 68E, the stream analytics service 68F, the record management and reporting service 68G, the security service 68 H and the rule configuration component 68I and FIG. 8) comprising a situation classifier module (Awiszus: [0061]-[0062], [0067]-[0068], and FIG. 2 the event selector 68B, the event processor 68 C, and the HP event processor 68D and FIG. 8: Event selector 68B operates on the stream of events 69 received from PPEs 62 and/or hubs 14 via frontend 68A and determines, based on rules or classifications, priorities associated with the incoming events. Based on the priorities, event selector 68B enqueues the events for subsequent processing by event processor 68C or high priority (HP) event processor 68D) and an intervention/alert module (Awiszus: [0027], [0029], [0046], [0049], [0062], [0067]-[0069], FIG. 2 the notification service 68E, and FIG. 8: Based on the priorities, event selector 68B enqueues the events for subsequent processing by event processor 68C or high priority (HP) event processor 68D. Additional computational resources and objects may be dedicated to HP event processor 68D so as to ensure responsiveness to critical events, such as incorrect usage of PPEs, use of incorrect filters and/or respirators based on geographic locations and conditions, failure to properly secure SRLs 11 and the like. Responsive to processing high priority events, HP event processor 68D may immediately invoke notification service 68E to generate alerts, instructions, warnings or other similar messages to be output to SRLs 11, respirators 13, hubs 14 and/or remote users 20, 24. Events not classified as high priority are consumed and processed by event processor 68C),
a subsystem database (Awiszus: FIG. 2 the data repositories 74 comprising the event data 74A, the historical data and models 74 B, the audit 74C, the configuration 74D, the self check criteria 74E, and the work relation data 74F) comprising contextualization rules (Awiszus: [0043]-[0044], [0067]-[0068], [0078]-[0081], FIG. 2, and FIG. 8) and a library of alert rules (Awiszus: [0027], [0037], [0072]-[0073], [0079]-[0081], and FIG. 1-2: storing the safety rules may include associating a safety rule with context data, such that rule configuration component 68I may perform a lookup to select safety rules associated with matching context data. Context data may include any data describing or characterizing the properties or operation of a worker, worker environment, article of PPE, or any other entity. Context data of a worker may include, but is not limited to: a unique identifier of a worker, type of worker, role of worker, physiological or biometric properties of a worker, experience of a worker, training of a worker, time worked by a worker over a particular time interval, location of the worker, or any other data that describes or characterizes a worker),
the situation classifier module is configured to determine a first contextualized situation at the time from the first sensor data using the contextualization rules (Awiszus: [0029], [0061-[0063], [0081], [0086], [0154], FIG. 1, and FIG. 8: In general, a safety event may refer to activities of a user of personal protective equipment (PPE), a condition of the PPE, or an environmental condition (e.g., which may be hazardous). In some examples, a safety event may be an injury or worker condition, workplace harm, or regulatory violation. For example, in the context of fall protection equipment, a safety event may be misuse of the fall protection equipment, a user of the fall equipment experiencing a fall, or a failure of the fall protection equipment. In the context of a respirator, a safety event may be misuse of the respirator, a user of the respirator not receiving an appropriate quality and/or quantity of air, or failure of the respirator. A safety event may also be associated with a hazard in the environment in which the PPE is located. In some examples, occurrence of a safety event associated with the article of PPE may include a safety event in the environment in which the PPE is used or a safety event associated with a worker using the article of PPE. In some examples, a safety event may be an indication that PPE, a worker, and/or a worker environment are operating, in use, or acting in a way that is normal operation, where normal operation is a predetermined or predefined condition of acceptable or safe operation, use, or activity),
the situation classifier module is configured to determine a second contextualized situation at the time (Awiszus: [0029], [0061-[0063], [0081], [0086], [0154], FIG. 1, and FIG. 8) from the first sensor data and the second sensor data (Awiszus: [0025]: Sensors may include any device that generates data or context information. Such data may generally be referred to herein as usage data or, alternatively, operation data or sensor data. In some examples, usage data may take the form of a stream of samples over a period of time. In some instances, the sensors may be configured to measure operating characteristics of components of the article of PPE, characteristics of a worker using or wearing the article of PPE, and/or environmental factors associated with an environment in which the article of PPE is located, [0033], [0037]-[0039], [0044], and FIG. 1) using the contextualization rules (Awiszus: [0029], [0061-[0063], [0081], [0086], [0154], FIG. 1, and FIG. 8: In general, a safety event may refer to activities of a user of personal protective equipment (PPE), a condition of the PPE, or an environmental condition (e.g., which may be hazardous). In some examples, a safety event may be an injury or worker condition, workplace harm, or regulatory violation. For example, in the context of fall protection equipment, a safety event may be misuse of the fall protection equipment, a user of the fall equipment experiencing a fall, or a failure of the fall protection equipment. In the context of a respirator, a safety event may be misuse of the respirator, a user of the respirator not receiving an appropriate quality and/or quantity of air, or failure of the respirator. A safety event may also be associated with a hazard in the environment in which the PPE is located. In some examples, occurrence of a safety event associated with the article of PPE may include a safety event in the environment in which the PPE is used or a safety event associated with a worker using the article of PPE. In some examples, a safety event may be an indication that PPE, a worker, and/or a worker environment are operating, in use, or acting in a way that is normal operation, where normal operation is a predetermined or predefined condition of acceptable or safe operation, use, or activity),
the intervention/alert module configured to compare the first contextualized situation to the library of alert rules (Awiszus: [0067]-[0068], [0079]-[0082], [0090], [0100], and Table 4: PPEMS 6 may determine that a visor of a respirator 13 is up in hazardous work area. PPEMS 6 may also determine that a worker 10 is fitted with improper equipment (e.g., an improper filter for a specified area), or that a worker 10 is present in a restricted/closed area. PPEMS 6 may also determine whether worker temperature exceeds a threshold, e.g., in order to prevent heat stress. PPEMS 6 may also determine when a worker 10 has experienced an impact, such as a fall) to determine whether an alert situation has occurred at the time (Awiszus: [0027]: the output may be used to alert the user of the article of PPE that the safety event is likely to occur, allowing the user to alter their behavior. In other examples, circuitry embedded within the respirators or processors within intermediate data hubs more local to the workers may be programmed via the PPEMS or other mechanism to apply models or rule sets determined by the PPEMS so as to locally generate and output alerts or other preventative measure designed to avoid or mitigate a predicted safety event, [0029], [0039], [0046], [0049], [0062], [0069], FIG. 2 the notification service 68E, and FIG. 8: Based on the priorities, event selector 68B enqueues the events for subsequent processing by event processor 68C or high priority (HP) event processor 68D. Additional computational resources and objects may be dedicated to HP event processor 68D so as to ensure responsiveness to critical events, such as incorrect usage of PPEs, use of incorrect filters and/or respirators based on geographic locations and conditions, failure to properly secure SRLs 11 and the like. Responsive to processing high priority events, HP event processor 68D may immediately invoke notification service 68E to generate alerts, instructions, warnings or other similar messages to be output to SRLs 11, respirators 13, hubs 14 and/or remote users 20, 24. Events not classified as high priority are consumed and processed by event processor 68C ), and
the intervention/alert module configured to compare the second contextualized situation to the library of alert rules (Awiszus: [0067]-[0068], [0079]-[0082], [0090], [0100], and Table 4: In the example of FIG. 2, a safety manager may initially configure one or more safety rules. As such, remote user 24 may provide one or more user inputs at computing device 18 that configure a set of safety rules for work environment 8A and 8B. For instance, a computing device 60 of the safety manager may send a message that defines or specifies the safety rules. Such message may include data to select or create conditions and actions of the safety rules. PPEMS 6 may receive the message at interface layer 64 which forwards the message to rule configuration component 68I. Rule configuration component 68I may be combination of hardware and/or software that provides for rule configuration including, but not limited to: providing a user interface to specify conditions and actions of rules, receive, organize, store, and update rules included in safety rules data store 74E) to determine whether the alert situation has occurred at the time (Awiszus: [0039], [0044], [0086], [0090], [0093]-[0094], [0098]-[0100], and FIG. 1: PPEMS 6 may generate, in some examples, a warning when worker 10 is near a hazard in one of environments 8 (e.g., based on location data gathered from a location sensor (GPS or the like) of respirators 13). PPEMS 6 may also applying usage data to a safety learning model that characterizes a temperature of worker 10. In this example, PPEMS 6 may determine that the temperature exceeds a temperature associated with safe activity over the time period and alert worker 10 to the potential for a safety event due to the temperature).
Awiszus does not explicitly disclose whereby if the alert situation has occurred at the time based on the first contextualized situation, but the alert situation has not occurred at the time based on the second contextualized situation, the monitoring subsystem configured to not communicate an alert; and
whereby if the alert situation has occurred at the time based on the first contextualized situation, and the alert situation has occurred at the time based on the second contextualized situation, the monitoring subsystem configured to communicate an alert.
However, in one embodiment, Awiszus discloses the analytics service (Awiszus: FIG. 2) receives various information from the one or more sensors associated with the users and environment (Awiszus: FIG. 1) wherein the information of the one or more sensors associated with the users (Awiszus: [0087], [0090]-[0091], [0094], and FIG. 5: PPEMS 6 may also perform fall data analysis after a fall has occurred and/or determine temperature, humidity and other environmental conditions as they relate to the likelihood of safety events) and environment are combined and based on alert rules before activating an alert (Awiszus: [0029], [0037],[0039]: For example, PPEMS 6 may utilize the environmental data to aid generating alerts or other instructions for respirators 13 and for performing predictive analytics, such as determining any correlations between certain environmental conditions (e.g., heat, humidity, visibility) with abnormal worker behavior or increased safety events. As such, PPEMS 6 may utilize current environmental conditions to aid prediction and avoidance of imminent safety events. Example environmental conditions that may be sensed by sensing stations 21 include but are not limited to temperature, humidity, presence of gas, pressure, visibility, wind and the like, [0127]-[0128], [0223], [0246], [0249]-[0250], and FIG. 5: if a hazard is not detected, the computing device returns to operation to query whether the visor is open. If a hazard is detected in step 330, an alert is generated (340). A variety of types of alerts may be generated. For example, an alert may comprise one or more of the following types of signals: tactile, vibration, audible, visual, heads-up display or radio frequency signal. In some instances, an alert is not generated unless an exposure threshold and/or a hazard threshold is first met).
Therefore, in view of teachings by Awiszus, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the monitoring system of Awiszus to include if the alert situation has occurred based on the first contextualized situation, but the alert situation has not occurred based on the second contextualized situation, the monitoring subsystem configured to not communicate an alert; and if the alert situation has occurred based on the first contextualized situation, and the alert situation has occurred based on the second contextualized situation, the monitoring subsystems configured to communicate an alert, as suggested by Awiszus, as desired. The motivation for this is to combine various monitoring information regarding about a user and an environment where the user is located in order to provide an appropriate corrective actions.
As to claim 16, Awiszus disclose the limitations of claim 15 further comprising the processor based contextualized sensor system of claim 15 wherein:
the first sensor comprises a physiological sensor configured to communicate a physiological data as the first sensor data (Awiszus: [0042]-[0044], [0048]-[0049], [0086]-[0094], [0094], [0098], [0106]-[0107], and FIG. 1: PPEMS 6 may determine, based on usage data from respirators 13, a length of time that one or more components of respirator 13 (e.g., head top, blower, and/or filter) have been in use, an instantaneous velocity or acceleration of worker 10 (e.g., based on an accelerometer included in respirators 13 or hubs 14), a temperature of one or more components of respirator 13 and/or worker 10, a location of worker 10, a number of times or frequency with which a worker 10 has performed a self-check of respirator 13 or other PPE, a number of times or frequency with which a visor of respirator 13 has been opened or closed, a filter/cartridge consumption rate, fan/blower usage (e.g., time in use, speed, or the like), battery usage (e.g., charge cycles), or the like);
the situation classifier module further comprises a state contextualizer module configured to determine a first contextualized state of a worker at the time from the first sensor data (Awiszus: [0042]-[0044], [0048]-[0049], [0086]-[0094], [0094], [0098], [0106]-[0107], and FIG. 1: PPEMS 6 may generate, in some examples, a warning when worker 10 is near a hazard in one of environments 8 (e.g., based on location data gathered from a location sensor (GPS or the like) of respirators 13). PPEMS 6 may also applying usage data to a safety learning model that characterizes a temperature of worker 10. In this example, PPEMS 6 may determine that the temperature exceeds a temperature associated with safe activity over the time period and alert worker 10 to the potential for a safety event due to the temperature) and a second contextualized state of the worker at the time from the first sensor data and the second sensor data (Awiszus: [0043]-[0044], [0048]-[0049], [0070], [0090]-[0091]: For example, PPEMS 6 may, based on usage data from respirators 13, recognize motion that may indicate a pending fall by worker 10 (e.g., via one or more accelerometers included in respirators 13 and/or hubs 14). In some instances, PPEMS 6 may, based on usage data from respirators 13, infer that a fall has occurred or that worker 10 is incapacitated. PPEMS 6 may also perform fall data analysis after a fall has occurred and/or determine temperature, humidity and other environmental conditions as they relate to the likelihood of safety events, [0169], [0179], Table 1-2, FIG. 1-4 and FIG. 9-16: a non-limiting set of filters may include, as examples, identification of a user of a respirator of the at least one respirator, components of the at least one respirator, a geographic location, a time, a temperature, a motion of the user, an ambient noise, an impact to the at least one respirator, a posture of the user of the at least one respirator, a battery status of a battery of the at least one respirator, a visor position of a visor of the at least one respirator, a presence of a head in a head top of the at least one respirator, a pressure of a blower of the at least one respirator, a blower speed of the blower of the at least one respirator, a filter status of a filter of the at least one respirator, or a status of a cartridge of the at least one respirator);
the first contextualized situation comprises the first contextualized state of the worker at the time (Awiszus: [0029], [0036], [0090]-[0092], [0111], [0152], Tables 1-2, FIG. 1, and FIG. 5: In some examples, a safety event may be an injury or worker condition, workplace harm, or regulatory violation. For example, in the context of fall protection equipment, a safety event may be misuse of the fall protection equipment, a user of the fall equipment experiencing a fall, or a failure of the fall protection equipment. In the context of a respirator, a safety event may be misuse of the respirator, a user of the respirator not receiving an appropriate quality and/or quantity of air, or failure of the respirator); and
the second contextualized situation comprises the second contextualized state of the worker at the time (Awiszus: [0043]-[0044], [0048]-[0049], [0070], [0090]-[0091]: For example, PPEMS 6 may, based on usage data from respirators 13, recognize motion that may indicate a pending fall by worker 10 (e.g., via one or more accelerometers included in respirators 13 and/or hubs 14). In some instances, PPEMS 6 may, based on usage data from respirators 13, infer that a fall has occurred or that worker 10 is incapacitated. PPEMS 6 may also perform fall data analysis after a fall has occurred and/or determine temperature, humidity and other environmental conditions as they relate to the likelihood of safety events, [0169], [0179], Table 1-2, FIG. 1-4 and FIG. 9-16: a non-limiting set of filters may include, as examples, identification of a user of a respirator of the at least one respirator, components of the at least one respirator, a geographic location, a time, a temperature, a motion of the user, an ambient noise, an impact to the at least one respirator, a posture of the user of the at least one respirator, a battery status of a battery of the at least one respirator, a visor position of a visor of the at least one respirator, a presence of a head in a head top of the at least one respirator, a pressure of a blower of the at least one respirator, a blower speed of the blower of the at least one respirator, a filter status of a filter of the at least one respirator, or a status of a cartridge of the at least one respirator).
Claims 17 is rejected under 35 U.S.C. 103 as being unpatentable over Awiszus et al. (Awiszus – US 2019/0175411 A1) in view of Ricci (Ricci – US 2016/0266606 A1).
As to claim 17, Awiszus disclose the limitations of claim 15 except for the claimed limitations of the processor based contextualized sensor system of claim 15 wherein: the body area subsystem further comprises a mounting base; and the first sensor and the second sensor are configured to be removably coupled to the mounting base.
However, it has been known in the art of monitoring conditions of a user to implement the body area subsystem further comprises a mounting base; and the first sensor and the second sensor are configured to be removably coupled to the mounting base, as suggested by Ricci, which discloses the body area subsystem further comprises a mounting base; and the first sensor and the second sensor are configured to be removably coupled to the mounting base (Ricci: Abstract, [0093]-[0095], [0105]and FIG. 1 the body 104 and the shell 108 of the wearable device 100: Optionally, one or more of the body 104 and the shell 108 may include fasteners or clasps to align and interconnect to each other. Additionally or alternatively, the body 104 and the shell 108 may include one or more features 140, 144 for alignment, registration, and/or retention. The feature 140 of the body 104 may interact with the feature 144 of the shell 108 to create a predetermined alignment between the body 104 and the shell 108. These keying and/or receiving features 140, 144 may be configured to interface, couple, and/or interconnect the shell 108 to the body 104 or other component, for example as illustrated in FIGS. 1F-1K).
Therefore, in view of teachings by Awiszus and Ricci, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the wearable device of Awiszus to include the body area subsystem further comprises a mounting base; and the first sensor and the second sensor are configured to be removably coupled to the mounting base, as suggested by Ricci. The motivation for this is to selectively implement different features of a wearable device for particular activity.
Claims 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Awiszus et al. (Awiszus – US 2019/0175411 A1) in view of Arthur et al. (Arthur – WO 2019/234569 A1), Ricci (Ricci – US 2016/0266606 A1), and Jeong (Jeong – US 2016/0100758 A1).
As to claim 18, Awiszus discloses a processor based contextualized sensor system for determining a contextualized state of a worker, the system comprising:
a body area subsystem (Awiszus: FIG. 1 the respirators 13A-13N and the wearable communication hubs 14A-14N, FIG. 3-4 and FIG. 8 the communication hub 130) comprising:
one or more sensors configured to collect state data of a worker (Awiszus: [0025], [0033], [0063], [0103], [0147], FIG. 1, FIG. 3-4, and FIG. 8: each of respirators 13 includes embedded sensors or monitoring devices and processing electronics configured to capture data in real-time as a user (e.g., worker) engages in activities while wearing the respirators) comprising:
a sensor module comprising one or more sensors configured to collect a state data of a worker (Awiszus: [0025], [0033], [0063], [0103], [0147], FIG. 1, FIG. 3-4, and FIG. 8: each of respirators 13 includes embedded sensors or monitoring devices and processing electronics configured to capture data in real-time as a user (e.g., worker) engages in activities while wearing the respirators),
the state data comprising a first raw state data at a time (Awiszus: Abstract, [0033], [0105], [0107], [0109], [0122], [0124], [0130]-[0132], and FIG. 4-5: position sensor 111 may detect whether visor 112 is partially open, and if so, what measure (e.g., percent or degree) it is open. As an example, the position sensor 110 may be a gyroscope that computes angular yaw, pitch, and/or roll (in degrees or radians) of the visor 112 relative to the helmet 118. In another example, the position sensor 110 may be a magnet. A percent may be estimated respecting how open a visor 112 is in relation to the helmet 118 by determining the magnetic field strength or flux perceived by the position sensor 110. “Partially open” visor information can be used to denote that the user may be receiving eye and face protection for hazards while still receiving a reasonable amount of respiratory protection. This “partially open” visor state, if kept to short durations, can assist the user in face to face communications with other workers. Position sensor 111 can be a variety of types of sensors, for example, an accelerometer, gyro, magnet, switch, potentiometer, digital positioning sensor or air pressure sensor. Position sensor 111 can also be a combination of any of the sensors listed above, or any other types of sensors that can be used to detected the position of the visor 112 relative to the helmet 118. Head top 110 may be supported on a user's head by a suspension (not shown)) and a second raw state data at the time (Awiszus: [0147] and FIG. 8: Sensors 808 may include one or more sensors that generate data indicative of an activity of a worker 10 associated with hub 14 and/or data indicative of an environment in which hub 14 is located. Sensors 808 may include, as examples, one or more accelerometers, one or more sensors to detect conditions present in a particular environment (e.g., sensors for measuring temperature, humidity, particulate content, noise levels, air quality, or any variety of other characteristics of environments in which respirator 13 may be used), or a variety of other sensors), and
a communication subsystem (Awiszus: [0051]-[0056] and FIG. 2: In FIG. 2, personal protection equipment (PPEs) 62, such as SRLs 11, respirators 13 and/or other equipment, either directly or by way of hubs 14, as well as computing devices 60, operate as clients 63 that communicate with PPEMS 6 via interface layer 64) configured to communicate the first raw state data, the second raw state data and the time (Awiszus: [0051]-[0056] and FIG. 2: In FIG. 2, personal protection equipment (PPEs) 62, such as SRLs 11, respirators 13 and/or other equipment, either directly or by way of hubs 14, as well as computing devices 60, operate as clients 63 that communicate with PPEMS 6 via interface layer 64);
a monitoring subsystem (Awiszus: FIG. 1 the personal protection equipment management system (PPEMS) 2) comprising:
a message broker (Awiszus: FIG. 2 the interface layer 64) configured to receive the first raw state data, the second raw state data and the time from the body area subsystem (Awiszus: [0051]-[0056] and FIG. 2: In FIG. 2, personal protection equipment (PPEs) 62, such as SRLs 11, respirators 13 and/or other equipment, either directly or by way of hubs 14, as well as computing devices 60, operate as clients 63 that communicate with PPEMS 6 via interface layer 64),
an expert subsystem (Awiszus: FIG. 2 the services 68 comprising the event endpoint frontend 68A, the event selector 68B, the event processor 68C, the HP event processor 68D, the notification service 68E, the stream analytics service 68F, the record management and reporting service 68G, the security service 68 H and the rule configuration component 68I and FIG. 8) comprising a situation classifier module (Awiszus: [0061]-[0062], [0067]-[0068], and FIG. 2 the event selector 68B, the event processor 68 C, and the HP event processor 68D and FIG. 8: Event selector 68B operates on the stream of events 69 received from PPEs 62 and/or hubs 14 via frontend 68A and determines, based on rules or classifications, priorities associated with the incoming events. Based on the priorities, event selector 68B enqueues the events for subsequent processing by event processor 68C or high priority (HP) event processor 68D), a subsystem database (Awiszus: FIG. 2 the data repositories 74 comprising the event data 74A, the historical data and models 74 B, the audit 74C, the configuration 74D, the self check criteria 74E, and the work relation data 74F) comprising contextualization rules (Awiszus: [0043]-[0044], [0067]-[0068], [0078]-[0081], FIG. 2, and FIG. 8), and
the situation classifier module is configured to determine a raw state of the worker at the time from the first raw state data and determine a contextualized state of the worker at the time from the first raw state data at the time (Awiszus: [0029], [0061-[0063], [0081], [0086], [0154], FIG. 1, and FIG. 8: In general, a safety event may refer to activities of a user of personal protective equipment (PPE), a condition of the PPE, or an environmental condition (e.g., which may be hazardous). In some examples, a safety event may be an injury or worker condition, workplace harm, or regulatory violation. For example, in the context of fall protection equipment, a safety event may be misuse of the fall protection equipment, a user of the fall equipment experiencing a fall, or a failure of the fall protection equipment. In the context of a respirator, a safety event may be misuse of the respirator, a user of the respirator not receiving an appropriate quality and/or quantity of air, or failure of the respirator. A safety event may also be associated with a hazard in the environment in which the PPE is located. In some examples, occurrence of a safety event associated with the article of PPE may include a safety event in the environment in which the PPE is used or a safety event associated with a worker using the article of PPE. In some examples, a safety event may be an indication that PPE, a worker, and/or a worker environment are operating, in use, or acting in a way that is normal operation, where normal operation is a predetermined or predefined condition of acceptable or safe operation, use, or activity) and the second raw state data at the time (Awiszus: [0029], [0061-[0063], [0081], [0086], [0154], FIG. 1, and FIG. 8) and the contextualization rules (Awiszus: [0029], [0061-[0063], [0081], [0086], [0154], FIG. 1, and FIG. 8: In general, a safety event may refer to activities of a user of personal protective equipment (PPE), a condition of the PPE, or an environmental condition (e.g., which may be hazardous). In some examples, a safety event may be an injury or worker condition, workplace harm, or regulatory violation. For example, in the context of fall protection equipment, a safety event may be misuse of the fall protection equipment, a user of the fall equipment experiencing a fall, or a failure of the fall protection equipment. In the context of a respirator, a safety event may be misuse of the respirator, a user of the respirator not receiving an appropriate quality and/or quantity of air, or failure of the respirator. A safety event may also be associated with a hazard in the environment in which the PPE is located. In some examples, occurrence of a safety event associated with the article of PPE may include a safety event in the environment in which the PPE is used or a safety event associated with a worker using the article of PPE. In some examples, a safety event may be an indication that PPE, a worker, and/or a worker environment are operating, in use, or acting in a way that is normal operation, where normal operation is a predetermined or predefined condition of acceptable or safe operation, use, or activity); and
the situation classifier module is configured to use the contextualization rules (Awiszus: [0029], [0061-[0063], [0081], [0086], [0154], FIG. 1, and FIG. 8: In general, a safety event may refer to activities of a user of personal protective equipment (PPE), a condition of the PPE, or an environmental condition (e.g., which may be hazardous). In some examples, a safety event may be an injury or worker condition, workplace harm, or regulatory violation. For example, in the context of fall protection equipment, a safety event may be misuse of the fall protection equipment, a user of the fall equipment experiencing a fall, or a failure of the fall protection equipment. In the context of a respirator, a safety event may be misuse of the respirator, a user of the respirator not receiving an appropriate quality and/or quantity of air, or failure of the respirator. A safety event may also be associated with a hazard in the environment in which the PPE is located. In some examples, occurrence of a safety event associated with the article of PPE may include a safety event in the environment in which the PPE is used or a safety event associated with a worker using the article of PPE. In some examples, a safety event may be an indication that PPE, a worker, and/or a worker environment are operating, in use, or acting in a way that is normal operation, where normal operation is a predetermined or predefined condition of acceptable or safe operation, use, or activity) to (1) confirm the raw state of the worker at the time as the contextualized state of the worker at the time (Awiszus: [0027]: the output may be used to alert the user of the article of PPE that the safety event is likely to occur, allowing the user to alter their behavior. In other examples, circuitry embedded within the respirators or processors within intermediate data hubs more local to the workers may be programmed via the PPEMS or other mechanism to apply models or rule sets determined by the PPEMS so as to locally generate and output alerts or other preventative measure designed to avoid or mitigate a predicted safety event, [0029], [0039], [0046], [0049], [0062], [0069], FIG. 2 the notification service 68E, and FIG. 8: Based on the priorities, event selector 68B enqueues the events for subsequent processing by event processor 68C or high priority (HP) event processor 68D. Additional computational resources and objects may be dedicated to HP event processor 68D so as to ensure responsiveness to critical events, such as incorrect usage of PPEs, use of incorrect filters and/or respirators based on geographic locations and conditions, failure to properly secure SRLs 11 and the like. Responsive to processing high priority events, HP event processor 68D may immediately invoke notification service 68E to generate alerts, instructions, warnings or other similar messages to be output to SRLs 11, respirators 13, hubs 14 and/or remote users 20, 24. Events not classified as high priority are consumed and processed by event processor 68C) or (2) override the raw state of the worker at the time as the contextualized state of the worker at the time.
While Awiszus discloses a method of monitoring conditions/states of workers based on combination of sensing information from various sensors at a time in order to determine a safety event of the workers based on different set of rules (Awiszus: [0067]-[0068], [0079]-[0082], [0090], [0100], FIG. 8, FIG. 10, and FIG. 16, and Table 4: PPEMS 6 may determine that a visor of a respirator 13 is up in hazardous work area. PPEMS 6 may also determine that a worker 10 is fitted with improper equipment (e.g., an improper filter for a specified area), or that a worker 10 is present in a restricted/closed area. PPEMS 6 may also determine whether worker temperature exceeds a threshold, e.g., in order to prevent heat stress. PPEMS 6 may also determine when a worker 10 has experienced an impact, such as a fall), Awiszus does not explicitly disclose a mounting base,
the contextualization rules comprise a raw variable and a contextualization variable to identify a resulting contextualized variable;
the raw variable comprises the first raw state data of the worker at the time;
the contextualization variable comprises the second raw state data of the worker at the time;
the resulting contextualized variable comprises an objective representation of the contextualized state of the worker at the time given the first raw state data at the time and the second raw state data of the worker at the time.
However, it has been known in the art of monitoring conditions of a user to implement the contextualization rules comprise a raw variable and a contextualization variable to identify a resulting contextualized variable;
the raw variable comprises the first raw state data of the worker at the time;
the contextualization variable comprises the second raw state data of the worker at the time;
the resulting contextualized variable comprises an objective representation of the contextualized state of the worker at the time given the first raw state data at the time and the second raw state data of the worker at the time, as suggested by Arthur, which discloses the contextualization rules comprise a raw variable and a contextualization variable to identify a resulting contextualized variable (Arthur: [0018], [0021]-[0022], [0042]-[0043], [0076], [0080]-[0081] and FIG. 1: safety management service 68F may determine a category safety risk score for a category labeled Temp Exposure Risk based on current temperature and/or humidity data received from environmental sensors 21, historical temperature and/or humidity data, current physiological data for worker l0A, and historical physiological data for worker l0A and/or other workers. In other words, safety management service 68F may receive an indication of the location temperature and humidity in environment 8B of FIG. l and compare the current physiological data for worker l0A to the historical physiological data for workers in environment 8B that worked in environment 8B under similar conditions (e.g., when the current temperature and humidity was similar to or corresponds to historical temperature and humidity information);
the raw variable comprises the first raw state data of the worker at the time (Arthur: [0018], [0021]-[0022], [0042]-[0043]: SMS 6 may evaluate risk to a particular worker (e.g., worker JOA) based at least in part on physiological characteristics (e.g., heart rate, breathing rate, body temperature, etc.) detected by one or more sensors 22 for the particular worker l0A. For example, SMS 6 may receive an indication of the current heart rate of worker l0A and may compare the heart rate to a threshold heart rate. In some examples, SMS 6 may determine that the heart rate of worker l0A has exceeded the threshold heart rate for a threshold amount of time (e.g., 20 minutes), exceeds the threshold heart rate by a threshold amount (e.g., 30%), or has exceeded the threshold heart rate by a threshold amount for the threshold amount of time, and in response, may determine that worker 1 OA is at high risk, [0105]: SMS 6 may receive physiological data that is generated by one or more physiological sensors and is indicative of one or more physiological characteristics of a worker 1 0A ( 402). In some examples, the physiological sensors include a heart rate sensor, breathing sensor, sweat sensor, galvanic skin response sensor, temperature sensor, etc. SMS 6 may receive the physiological data (e.g., the raw sensor data, a summary of the sensor data, or a subset of the sensor data) directly from one or more physiological sensors or indirectly (e.g., via hub 14), FIG. 1 the physiological sensors 22A-22N, and FIG. 4);
the contextualization variable comprises the second raw state data of the worker at the time (Arthur:[0021]: when physiological sensor 22A includes a temperature sensor, the temperature sensor may output data indicative of a temperature (e.g., core body temperature or skin temperature) of the worker l0A), [0076], [0080]-[0081]: safety management service 68F may determine a category safety risk score for a category labeled Temp Exposure Risk based on current temperature and/or humidity data received from environmental sensors 21, historical temperature and/or humidity data, current physiological data for worker l0A, and historical physiological data for worker l0A and/or other workers. In other words, safety management service 68F may receive an indication of the location temperature and humidity in environment 8B of FIG. l and compare the current physiological data for worker l0A to the historical physiological data for workers in environment 8B that worked in environment 8B under similar conditions (e.g., when the current temperature and humidity was similar to or corresponds to historical temperature and humidity information), [0105]-[0106], [0112]-[0113], and FIG. 1);
the resulting contextualized variable comprises an objective representation of the contextualized state of the worker at the time given the first raw state data at the time and the second raw state data of the worker at the time (Arthur: [0104] and FIG. 3: SMS 6 of FIGS. 1 and 2 may determine a safety risk score for one or more workers 10. As illustrated in the example of FIG. 3, user interface 300 includes physiological data associated with a first worker 302 named John Doe and a second worker 322 named Jane Doe. Graphical user interface 300 includes physiological data for such as heart rate 304, temperature 306, and step count 308 for worker 302 and heart rate 324, temperature 326, and step count 328 for worker 322. Graphical user interface 300 may include an indication of the safety risk score for each of workers 302, 322. For example, as illustrated in FIG. 3, graphical user interface 300 includes a graphical element (e.g., a text box, image, etc.) 310 indicating the safety risk score for worker 302 and a graphical element 330 indicating the safety risk score for worker 322.).
Therefore, in view of teachings by Awiszus and Arthur, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the monitoring system of Awiszus to include the contextualization rules comprise a raw variable and a contextualization variable to identify a resulting contextualized variable;
the raw variable comprises the first raw state data of the worker at the time;
the contextualization variable comprises the second raw state data of the worker at the time;
the resulting contextualized variable comprises an objective representation of the contextualized state of the worker at the time given the first raw state data at the time and the second raw state data of the worker at the time, as suggested by Arthur. The motivation for this is to monitor conditions of a user in order to provide an appropriate corrective actions.
The combination of Awiszus and Arthur does not explicitly disclose a body area subsystem comprising: a mounting base.
However, it has been known in the art of monitoring conditions of a user to implement a body area subsystem comprising: a mounting base, as suggested by Ricci, which discloses a body area subsystem comprising: a mounting base (Ricci: Abstract, [0093]-[0095], [0105]and FIG. 1 the body 104 and the shell 108 of the wearable device 100: Optionally, one or more of the body 104 and the shell 108 may include fasteners or clasps to align and interconnect to each other. Additionally or alternatively, the body 104 and the shell 108 may include one or more features 140, 144 for alignment, registration, and/or retention. The feature 140 of the body 104 may interact with the feature 144 of the shell 108 to create a predetermined alignment between the body 104 and the shell 108. These keying and/or receiving features 140, 144 may be configured to interface, couple, and/or interconnect the shell 108 to the body 104 or other component, for example as illustrated in FIGS. 1F-1K).
Therefore, in view of teachings by Awiszus, Arthur, and Ricci, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the wearable device of Awiszus and Arthur to include a body area subsystem comprising: a mounting base, as suggested by Ricci. The motivation for this is to selectively implement different features of a wearable device for particular activity.
The combination of Awiszus, Arthur, and Ricci does not explicitly disclose a body area subsystem comprising: a mounting base, a component block, the sensor module comprising a first sensor, the sensor module configured to removably couple the component block to the sensor module, the component block comprising a sensor component block comprising a component block sensor.
However, it has been known in the art of wearable sensors to implement a body area subsystem comprising: a mounting base, a component block, the sensor module comprising a first sensor, the sensor module configured to removably couple the component block to the sensor module, the component block comprising a sensor component block comprising a component block sensor, as suggested by Jeong, which discloses a body area subsystem comprising: a mounting base, a component block (Jeong: Abstract, [0064]-[0072], and FIG. 3-5: The first interface 2120 may be disposed at a predetermined position of the strap part 2100 of the wearable device 2000 and configured to accommodate the sensor 3000 which is attachable and detachable. The first interface 2120 may receive biological signal detection information from the sensor 3000 that is attached to the wearable device 2000), the sensor module (Jeong: FIG. 7-8 the sensor 3000) comprising a first sensor, the sensor module (Jeong: FIG. 7-8 the sensor 3000) configured to removably couple the component block to the sensor module (Jeong: Abstract, [0052]-[0063], [0069], [0090]-[0101], and FIG. 7-8: the first interface 2120 and the sensor 3000 may have a universal serial bus (USB) connector type such as type A, type B, Mini-A, Mini-B, Micro-A, Micro-B, or Micro-AB. In addition, although FIG. 3A illustrates the first interface 2120 as a male connector (also referred to as a plug) and the sensor as having a female connector (also referred to as a receptacle or a port), one or more other exemplary embodiments are limited thereto. For example, the first interface 2120 may correspond to a USB Type A female connector and the sensor 3000 may have a corresponding USB Type A male connector), the component block comprising a sensor component block (FIG. 7-8 the sensor 3000 and FIG. 10) comprising a component block sensor (Jeong: [0068], [0098], FIG. 7-8, and FIG. 10: the first interface 2120 may have a pin for connection to ground, a sensing pin for sensing attachment or detachment of the sensor 3000, a power pin for checking a power supply to the attached sensor 3000, a transmitting pin for transmitting data to the attached sensor 3000, a receiving pin for receiving data from the attached sensor 3000, a clock pin for receiving a clock signal, or the like).
Therefore, in view of teachings by Awiszus, Arthur, and Ricci, and Jeong, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the wearable device of Awiszus, Arthur, and Ricci to include a body area subsystem comprising: a mounting base, a component block, the sensor module comprising a first sensor, the sensor module configured to removably couple the component block to the sensor module, the component block comprising a sensor component block comprising a component block sensor, as suggested by Jeong. The motivation for this is to selectively implement different features of a wearable device for monitoring biological information of a user.
As to claim 19, Awiszus, Arthur, and Ricci, and Jeong disclose the limitations of claim 18 further comprising the processor based contextualized sensor system of claim 18 wherein: the sensor module comprises a first sensor (Awiszus: [0039], [0044], [0086], [0090], [0093]-[0094], [0098]-[0100], and FIG. 1: PPEMS 6 may generate, in some examples, a warning when worker 10 is near a hazard in one of environments 8 (e.g., based on location data gathered from a location sensor (GPS or the like) of respirators 13). PPEMS 6 may also applying usage data to a safety learning model that characterizes a temperature of worker 10. In this example, PPEMS 6 may determine that the temperature exceeds a temperature associated with safe activity over the time period and alert worker 10 to the potential for a safety event due to the temperature and Arthur:[0021]: when physiological sensor 22A includes a temperature sensor, the temperature sensor may output data indicative of a temperature (e.g., core body temperature or skin temperature) of the worker l0A), [0076], [0080]-[0081]: safety management service 68F may determine a category safety risk score for a category labeled Temp Exposure Risk based on current temperature and/or humidity data received from environmental sensors 21, historical temperature and/or humidity data, current physiological data for worker l0A, and historical physiological data for worker l0A and/or other workers. In other words, safety management service 68F may receive an indication of the location temperature and humidity in environment 8B of FIG. l and compare the current physiological data for worker l0A to the historical physiological data for workers in environment 8B that worked in environment 8B under similar conditions (e.g., when the current temperature and humidity was similar to or corresponds to historical temperature and humidity information), [0105]-[0106], [0112]-[0113], and FIG. 1 and Jeong: Abstract, [0052]-[0063], [0069], [0090]-[0101], and FIG. 7-8) and a second sensor (Awiszus: [0169], [0179], Table 1, FIG. 1-4 and FIG. 9-16: a non-limiting set of filters may include, as examples, identification of a user of a respirator of the at least one respirator, components of the at least one respirator, a geographic location, a time, a temperature, a motion of the user, an ambient noise, an impact to the at least one respirator, a posture of the user of the at least one respirator, a battery status of a battery of the at least one respirator, a visor position of a visor of the at least one respirator, a presence of a head in a head top of the at least one respirator, a pressure of a blower of the at least one respirator, a blower speed of the blower of the at least one respirator, a filter status of a filter of the at least one respirator, or a status of a cartridge of the at least one respirator); and
the first sensor and the second sensor are configured to be removably coupled to the mounting base (Ricci: Abstract, [0093]-[0095], [0105]and FIG. 1 the body 104 and the shell 108 of the wearable device 100: Optionally, one or more of the body 104 and the shell 108 may include fasteners or clasps to align and interconnect to each other. Additionally or alternatively, the body 104 and the shell 108 may include one or more features 140, 144 for alignment, registration, and/or retention. The feature 140 of the body 104 may interact with the feature 144 of the shell 108 to create a predetermined alignment between the body 104 and the shell 108. These keying and/or receiving features 140, 144 may be configured to interface, couple, and/or interconnect the shell 108 to the body 104 or other component, for example as illustrated in FIGS. 1F-1K and Jeong: Abstract, [0052]-[0063], [0069], [0090]-[0101], and FIG. 7-8).
Citation of Pertinent Art
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
Sun et al., US 2024/0428675 A1, discloses distress information sending method and system.
Vajapey et al., US 2024/0398358 A1, discloses wearable device for collecting physiological health data.
Xu et al., US 2024/0172995 A1, discloses wearable device for monitoring fluid overload with built-in sensors.
Sakumoto et al., US 2021/0200842 A1, discloses electronic apparatus, authentication method, and program.
Ross et al., US 10,380,866 B1, discloses dual case system for fall detection device.
Conclusion
All claims are drawn to the same invention claimed in the application prior to the entry of the submission under 37 CFR 1.114 and could have been finally rejected on the grounds and art of record in the next Office action if they had been entered in the application prior to entry under 37 CFR 1.114. Accordingly, THIS ACTION IS MADE FINAL. See MPEP §706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to QUANG PHAM whose telephone number is (571)-270-3668. The examiner can normally be reached 09:00 AM - 05:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, QUAN-ZHEN WANG can be reached at (571)-272-3114. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/QUANG PHAM/Primary Examiner, Art Unit 2685