Patent Publication Number: US-2019191024-A1

Title: Method and apparatus for dynamic configuration of a multiprocessor health data system

Description:
RELATED APPLICATION DATA 
     This application is a continuation of U.S. patent application Ser. No. 15/140,950 filed Apr. 28, 2016, titled “METHOD AND APPARATUS FOR DYNAMIC CONFIGURATION OF A MULTIPROCESSOR HEALTH DATA SYSTEM”, which is a nonprovisional of provisional application Ser. No. 62/154,245 filed Apr. 29, 2015, titled “METHOD AND APPARATUS FOR DYNAMIC CONFIGURATION OF A MULTIPROCESSOR HEALTH DATA SYSTEM”. U.S. Ser. No. 15/140,950 is a continuation in part of patent application Ser. No. 14/981,616 filed Dec. 28, 2015, titled “METHOD AND SYSTEM FOR DYNAMIC CONFIGURATION OF MULTIPROCESSOR SYSTEM”, which is a continuation of patent application Ser. No. 14/255,435 filed Apr. 17, 2014, now U.S. Pat. No. 9,292,334, issued Mar. 22, 2016, titled “METHOD AND APPARATUS FOR DYNAMIC CONFIGURATION OF MULTIPROCESSOR SYSTEM”, which is a continuation of patent application Ser. No. 12/979,198 filed Dec. 27, 2010, now U.S. Pat. No. 8,744,672, issued Jun. 03, 2014, titled “METHOD AND APPARATUS FOR DYNAMIC CONFIGURATION OF MULTIPROCESSOR SYSTEM”, which is a division of patent application Ser. No. 12/483,214 filed Jun. 11, 2009, now U.S. Pat. No. 8,958,315, issued Feb. 17, 2015, titled “METHOD AND APPARATUS FOR DYNAMIC CONFIGURATION OF MULTIPROCESSOR SYSTEM”, which is a continuation of patent application Ser. No. 11/462,958, filed Aug. 7, 2006, now U.S. Pat. No. 7,778,739 issued Jul. 28, 2010 Titled “METHOD AND APPARATUS FOR DYNAMIC CONFIGURATION OF MULTIPROCESSOR SYSTEM”, which is a continuation of patent application Ser. No. 09/841,915, filed Apr. 24, 2001, now U.S. Pat. No. 7,146,260 issued Dec. 5, 2006 titled “METHOD AND APPARATUS FOR DYNAMIC CONFIGURATION OF MULTIPROCESSOR SYSTEM”, all of which are hereby incorporated by reference in their entirety. Additionally, the present application incorporates by reference U.S. Pat. No. 6,629,033, issued Sep. 30, 2003 titled “OPEN COMMUNICATION SYSTEM FOR REAL-TIME MULTIPROCESSOR APPLICATIONS”, and U.S. Pat. No. 7,178,049, issued Feb. 13, 2007 titled “METHOD FOR MULTI-TASKING MULTIPLE JAVA VIRTUAL MACHINES IN A SECURE ENVIRONMENT”, both U.S. Pat. No. 6,629,033 and U.S. Pat. No. 7,178,049 are hereby incorporated by reference in their entirety. 
    
    
     BACKGROUND OF THE INVENTION 
     This invention relates to a system and method for overall health and fitness monitoring, analysis, and reporting. 
     As background, from the U.S. Pat. No. 7,146,230 specification, which is incorporated by reference the related application data section above, it should be understood that the multiprocessor system described in the U.S. Pat. No. 7,146,260 could be used in applications other than cars as described in column 8, lines 38-48 of the &#39;260, For example,  FIG. 13  of the U.S. Pat. No. 7,146,260 shows a first GUI 212 that shows different processors and applications in appliances that are coupled together using the DC system 10 in a home network. Examples include appliance systems, electronic security systems, radios, Compact Disc (CD) players, internal and external lighting systems, temperature control systems, locking systems, etc. In another example, the dynamic configuration system could be used in the healthcare industry, particularly in wireless health data monitoring systems for aggregating certain health data for a user. 
     Improving and maintaining a user&#39;s health involves diligent and tedious monitoring of many critical health and fitness related components. For the average user, reduced time and motivation hampers the ability to track and manage personal health and fitness data. Currently there are numerous websites and applications that monitor only a portion of the health and fitness data, making it difficult for the user to examine their overall health. Consolidating all forms of health data into a manageable format will have benefits for those seeking better fitness and better medical care and insurance by creating a more complete picture of a user&#39;s health and wellness. In addition to the user&#39;s benefits, accessible health information will improve medical care. Allowing health care professionals the ability to observe lifestyles will lead to improved diagnosis of ailments, recommendations on healthy lifestyle changes, and improved emergency response. 
     DESCRIPTION OF RELATED ART 
     In a discussion of prior art, U.S. patent application Ser. No. 11/925,902 filed Oct. 27, 2007, titled MULTI-SENSOR SYSTEM, DEVICE, AND METHOD FOR DERIVING HUMAN STATUS INFORMATION generally describes a wireless communications device, such as a cellular telephone, having sensors to generate data indicative of a physiological or contextual parameters of a user. A processor on the wireless communications device is adapted derive physiological state information of the user from the contextual or physiological parameters. The apparatus may include a central monitoring unit remote from the sensors for storing data and transmitting data to a recipient. What this application did not disclose is the ability to provide feedback to a local application or device based on desired information, the ability to communicate with other devices and/or running applications, the ability to selectively connect to other devices or applications via user input or set preferences, the ability to request data from outside sources, and the ability to upload health and fitness related data to websites and/or social platforms. 
     In a discussion of prior art, U.S. patent application Ser. No. 13/046,707 filed Mar. 12, 2011, titled IN HOME HEALTH MONITORING APPARATUS AND SYSTEM generally describes a health monitoring system that allows users to maintain an autonomous lifestyle while providing health observation and reporting for family members, caregivers, and healthcare professionals. The system is supported by a network for critical, round-the-clock health monitoring and remote care, and may be used in the home or elsewhere. In one exemplary embodiment, the system comprises a touch-screen computing device that also may function as a television and video or DVD player, and provides a series of service options for users. The computing device is connected to a network and/or the Internet. What this application did not disclose is the ability to monitor, record, and recommend health and fitness information, the ability to connect to multiple devices such as televisions and personal computers, and the ability to collect, analyze and provide feedback to the user based on surrounding environmental data. 
     In a discussion of prior art, U.S. patent publication Ser. No. 10/445275 filed May 23, 2003, titled REAL-TIME MEDICAL MONITORING APPLICATION WITH A NETWORK INTERFACE DEVICE generally describes systems and methods provided for medical monitoring of a patient at a patient premises. A medical-data collection device is adapted to collect medical data from the patient. The medical-data collection device is interfaced with a transport medium internal to the patient premises. A network interface device is also provided with multiple application devices interfaced with the transport medium internal to the patient premises. One of the application devices is a medical-monitoring application device adapted to process the collected medical data. Another of the application devices adapted to exchange data with a transport medium external to the patient premises. A processor in communication with the application devices is adapted to coordinate transmission of the collected medical data over the transport medium external to the patient premises. What this application did not disclose is the ability to communicate with other devices such as televisions or personal computers, the ability to upload health and fitness related data to websites and/or social platforms, the ability to collect data outside the user&#39;s primary premises, and the ability to collect data related to health and fitness. 
     In a discussion of prior art, U.S. patent application Ser. No. 09/602,537 filed Jun. 23, 2000, titled SYSTEM FOR MONITORING HEALTH, WELLNESS AND FITNESS generally describes a system for detecting, monitoring and reporting physiological information includes a sensor device adapted to be worn on the upper arm that includes at least one of an accelerometer, a GSR sensor and a heat flux sensor and generates data indicative of at least one of activity, galvanic skin response and heat flow. The sensor device may also generate derived data from at least a portion of the data indicative of at least one of activity, galvanic skin response and heat flow. The system includes a central monitoring unit that generates analytical status data from at least one of the data indicative of at least one of activity, galvanic skin response and heat flow, the derived data, and previously generated analytical status data, a means for establishing electronic communication between the sensor device and the central monitoring unit, and a means for transmitting data to a recipient. What this application did not disclose is the ability to collect data from remote devices that are not worn on the body, the ability to recall information running on a second device or service application, the ability to diagnose users based on collected data, and the ability to set preferences to differentiate and consolidate data. 
     In a discussion of prior art, non-patent literature WEBMD that describes a corporation which provides health information as a service. WEBMD has information regarding health and health care, including a symptom checklist, pharmacy information, “drugs information”, blogs of physicians with specific topics, and a place to store personal medical information. The functions that WEBMD does not perform include tracking and automatic collection of data from users, providing feedback to applications or devices, connecting users to health professionals or peer networks, and generating feedback outside of a visual display. 
     What is needed is an application to monitor, aggregate, and relay health, fitness, nutrition, and environmental data from data generated by both contact and noncontact sensors, an application with the ability to communicate with other devices running a service application, the ability to connect to social platforms, the ability to connect and access data and feedback on multiple devices and applications, the ability to set preferences based on user goals, and the ability to restrict third party access to collected data. 
     With respect now to the aggregation and collection of data from wireless devices, and in a further discussion of prior art U.S. patent application Ser. No. 10/578,710 filed Nov. 18, 2004, titled MONITORING OF VITAL SIGNS AND PERFORMANCE LEVELS which generally describes a monitoring device for monitoring vital signs which includes a housing. Signal input components are positioned in the housing to receive an electrical signal carrying data representing at least one vital sign of a subject. Wireless communications circuitry is mounted in the housing and is connected to the input components for transmitting and receiving wireless signals. Additionally, U.S. patent application Ser. No. 12/652,377 filed Jan. 5,2010 titled SYSTEM, METHOD, AND DEVICE FOR MEDICAL DEVICE DATA CAPTURE AND PROCESSING, which generally discloses a system, method, and computer-readable medium for medical device data capture and processing having an application hosting device configured to modify data received from a medical device. A data processing server receives the modified data from the application hosting device and associates the modified data with a user, the medical device and/or the application hosting device. Another aspect provides an application hosting device that receives instructions relating to the medical device and transmits the instructions to the medical device. A data processing server receives the instructions relating to the medical device from a user and to transmit the instructions to the application hosting device. The data processing server receives the data from the application hosting device. Another aspect provides an application hosting device that includes a processor and a memory. Data relating to a plurality of users and a plurality of medical devices is stored in the memory. 
     Both of these applications and specifications fail to disclose a secure simple method of pairing a Bluetooth device to the data collection system. It was not known in the art of Bluetooth until 2007 when the Bluetooth Core Specification Version 2.1+EDR was published and adopted by the Bluetooth SIG on 26 Jul. 2007. The headline feature of 2.1 is Secure Simple Pairing (SSP) which was implemented to improve the pairing experience for Bluetooth devices while increasing the use and strength of security. Version 2.1 also allows various other improvements, including “Extended inquiry response”(EIR), which provides more information during the inquiry procedure to allow better filtering of devices before connection. U.S. Pat. No. 7,146,260 and its family of patents, claiming priority to Apr. 24, 2001. discloses and claims the steps of SSP as summarized below. 
     This application is filed as a continuation in part disclosing a METHOD AND APPARATUS FOR DYNAMIC CONFIGURATION OF A MULTIPROCESSOR HEALTH DATA SYSTEM; one reliant on the Secure Simple Pairing of portable health data devices and processors. So as to reduce the complexity and length of the Detailed Specification, and to fully establish the state of the art in certain areas of technology, Applicant(s) herein expressly incorporate(s) by reference all of the following materials identified in each numbered paragraph below. 
     To those skilled in the art of wireless network systems, and particularly Bluetooth wireless systems, will recognize the &#39;260 disclosure of April 2001 and the DCS described became known in the art of Bluetooth as “Secure Simple Pairing” in the Jul. 26, 2007 release of the Bluetooth Specification 2.1+EDR. In the discussion of architecture in Part A—Architecture page 131 of 1420, “ . . . The primary goal of Secure Simple Pairing is to simplify the pairing procedure for the user. Secondary goals are to maintain or improve the security in Bluetooth wireless technology. Since high levels of security and ease-of-use are often at opposite ends of the spectrum in many technologies and products, much care has been taken to maximize security while minimizing complexity from the end user&#39;s point of view.” This was the first time a dynamic configuration system was specified by Bluetooth, therefore: specification of the Bluetooth System Versions: 1.2 dated Nov. 5, 2003; 2.0+EDR dated Nov. 4, 2004; 2.1+EDR dated Jul. 26, 2007; 3.0+HS dated Apr. 21, 2009; and 4.0. dated 17 Dec., 2009 is incorporated by reference and is therefore not described in further detail. IEEE 802.11n specification for Wireless Local Area Networks dated 29 Sep., 2009 is incorporated by reference and is therefore not described in further detail. 
     Additionally, the U.S. 7,146,260 (&#39;260) specification which has been incorporated by reference describing a dynamic configuration system for wired and wireless devices, among other disclosures. Specifically &#39;260 generally discloses the steps of secure simple pairing for Bluetooth through the implementation of some or all of the steps of the Dynamic Configuration system; where the dynamic configuration system has multiple processors configured to operate together, including one or more of the processors coupled together into a multiprocessor network. At least one processor in the multiprocessor network is configured to operate a Bluetooth transceiver which is configured to detect and establish communication between the multiprocessor network and the new device in proximity to the multiprocessor network. Once detected, selectively connect the new device to the multiprocessor network, use a data manager to identify a particular type of data used in the new device and processed with a first software application controlled and operated by the new device. Once a particular type of data is identified, identify a second software application from among multiple different software applications located in a memory in the multiprocessor network, where the second software application is currently not loaded in or operated by any of the on-board processors, and the second software application is also configured to process the same particular type of data processed by the first software application controlled and operated by the new device. Using the data manager, select or use a pre-selected processor in the multiprocessor network for operating the second software application. Once selected, automatically move the second software application from the memory in the multiprocessor network to the processors selected. Configure the selected processors to run the second software application, where running the second software application causes the selected processors to take over control and operation of the new device including initiating transfer of the data from the new device. The foregoing steps of securely adding a new device to a system of one or more processors is called a Dynamic Configuration System or DCS. Once a health device is securely connected, operate a logging manager in at least one of the multiprocessors configured to monitor data from the processors and identify certain data for logging from the processors, wherein the certain data is logged from different health sensors. Once logged, the health data is stored in a data memory, wherein the stored data is based on a pre-determined condition and responds to an outgoing message from one of the health applications for sending out over the Bluetooth link to another processor, wherein the manager sends at least a portion of the logged certain data retrieved from the data memory based on the pre-determined condition. 
     Applicants believe that the material incorporated above is “non-essential” in accordance with 37 CFR 1.57, because it is referred to for purposes of indicating the background of the invention or illustrating the state of the art. However, if the Examiner believes that any of the above-incorporated material constitutes “essential material” within the meaning of 37 CFR 1.57(c)(1)-(3), applicants will amend the specification to expressly recite the essential material that is incorporated by reference as allowed by the applicable rules. 
     Aspects and applications of the invention presented here are described below in the drawings and detailed description of the invention. Unless specifically noted, it is intended that the words and phrases in the specification and the claims be given their plain, ordinary, and accustomed meaning to those of ordinary skill in the applicable arts. The inventors are fully aware that they can be their own lexicographers if desired. The inventors expressly elect, as their own lexicographers, to use only the plain and/ordinary meaning of terms in the specification and claims unless they dearly state otherwise and then further, expressly set forth the “special” definition of that term and explain how it differs from the plain and/ordinary meaning. Absent such clear statements of intent to apply a “special” definition, it is the inventors&#39; intent and desire that the simple, plain and/ordinary meaning to the terms be applied to the interpretation of the specification and claims. 
     The inventors are also aware of the normal precepts of English grammar. Thus, if a noun, term, or phrase is intended to be further characterized, specified, or narrowed in some way, then such noun, term, or phrase will expressly include additional adjectives, descriptive terms, or other modifiers in accordance with the normal precepts of English grammar. Absent the use of such adjectives, descriptive terms, or modifiers, it is the intent that such nouns, terms, or phrases be given their plain, and/ordinary English meaning to those skilled in the applicable arts as set forth above. 
     Further, the inventors are fully informed of the standards and application of the special provisions of 35 U.S.C. § 112, ¶ 6. Thus, the use of the words “function,” “means” or “step” in the Detailed Description or Description of the Drawings or claims is not intended to somehow indicate a desire to invoke the special provisions of 35 § 112, ¶ 6, to define the invention. To the contrary, if the provisions of 35 U.S.C. § 112, ¶ 6 are sought to be invoked to define the inventions, the claims will specifically and expressly state the exact phrases “means for” or “step for, and will also recite the word “function”(i.e., will state “means for performing the function of [insert function]”), without also reciting in such phrases any structure, material or act in support of the function. Thus, even when the claims recite a “means for performing the function of . . . ” or “step for performing the function of . . . ,”if the claims also recite any structure, material or acts in support of that means or step, or that perform the recited function, then it is the clear intention of the inventors not to invoke the provisions of 35 U.S.C. §112, ¶ 6. Moreover, even if the provisions of 35 U.S.C. §112, ¶ 6 are invoked to define the claimed inventions, it is intended that the inventions not be limited only to the specific structure, material or acts that are described in the preferred embodiments, but in addition, include, any and all structures, materials or acts that perform the claimed function as described in alternative embodiments or forms of the invention, or that are well known present or later-developed, equivalent structures, material or acts for performing the claimed function. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       A more complete understanding of the present invention may be derived by referring to the detailed description when considered in connection with the following illustrative figures. In the figures, like reference numbers refer to like elements or acts throughout the figures. 
         FIG. 1  is a diagram of the connection between the health application running on processor A and a service application running on processor B. 
         FIG. 2  is a diagram of the service application connecting to a third party. 
         FIG. 3  is a diagram of the communication between the health application, running on processor A, the service application, running on processor B, and a third party. 
         FIG. 4  is a diagram depicting how a health application can be connected to various data generating devices and a method to transmit data to a server. 
         FIG. 5  is a diagram of the service application receiving, transmitting and processing data. 
         FIG. 6  illustrates the health application and service application collecting data from multiple data generating devices located in a typical home. 
         FIG. 7  is a diagram depicting communication between applications, devices, and the server. 
         FIG. 8  is a diagram depicting a process for collecting health data after the user has been prompted for input by the health application. 
         FIG. 9  illustrates a user being notified by the service application running on a smartphone to locate and possibly use an inhaler based on collected environmental data. 
         FIG. 10  is a diagram depicting a user prompting the health application to begin collecting health data from a data generating device. 
         FIG. 11  illustrates the health application being prompted by the user through the activation of a data generating device and relaying user in to a smartphone. 
         FIG. 12  is a diagram depicting a smartphone running the health application capable of collecting, storing, and transmitting data. 
         FIG. 13  illustrates the health application running on a portable device that is collecting data. 
         FIG. 14  illustrates the health application running on a smartphone that is collecting data at a gym. 
         FIG. 15  is a flow diagram depicting a system check and troubleshooting routines of the initialization of an application. 
         FIG. 16  flow diagram depicting the process of connecting a data source to the health application and collecting data. 
         FIG. 17  is a flow diagram depicting system check and initialization of a data generating device. 
         FIG. 18  is a flow diagram depicting how a data packet with rowing information is transmitted to an application. 
         FIG. 19  is a block diagram depicting an example data packet. 
         FIG. 20  is a flow diagram depicting how information is retrieved. 
         FIG. 21  illustrates how the user&#39;s progress can be incorporated into a game. 
         FIG. 22  illustrates the health application being used to diagnose illnesses and make recommendations. 
         FIG. 23  illustrates the health application being used to diagnose a rash. 
         FIG. 24  is a flow diagram depicting a device capable of sampling and obtaining data from biological matter. 
         FIG. 25  depicts the process for obtaining feedback based on user specifications. 
         FIG. 26  illustrates a user receiving nutrition information about his meal in a restaurant. 
         FIG. 27  illustrates a health professional reviewing health data with a patient. 
         FIG. 28  is a flow diagram depicting process configuration. 
         FIG. 29  is a flow diagram depicting operating a logging manager. 
         FIG. 30  is a flow diagram depicting operating a security manager. 
     
    
    
     Elements and acts in the figures are illustrated for simplicity and have not necessarily been rendered according to any particular sequence or embodiment. 
     DETAILED DESCRIPTION OF THE INVENTION 
     In the following description, and for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the various aspects of the invention. It will be understood, however, those skilled in the relevant arts, that the present invention may be practiced without these specific details. In other instances, known structures and devices are shown or discussed more generally in order to avoid obscuring the invention. In many cases, a description of the operation is sufficient to enable one to implement the various forms of the invention, particularly when the operation is to be implemented software. It should be noted that there are many different and alternative configurations, devices and technologies to which the disclosed inventions may be applied. The full scope of the inventions is not limited to the examples that are described below. 
     The data collected by the application comes from multiple data generating devices that are present in everyday living environments comprising at least one of a home, car, gym, and workplace. The local application can be run on one of a smartphone, personal PC, tablet, or standalone unit. The application collects static or dynamic data that can be stored, processed or recalled as information. As the user goes about normal routines of the day, the application collects selected data relevant to the user. The application identifies data generated by a device and/organizes the data into user selected categories. The user has control over what information can be accessed by third parties and how the information is relayed. Users can also select format and interaction methods of feedback. The local application can be used to recall information from any combination of services about health, fitness, nutrition, or medicine. The application can track the user&#39;s nutrition, workout performance, medicine consumption, environmental conditions, and personal changes. The application can continuously monitor a user in an environment and provide feedback on the user&#39;s status in the environment. 
       FIG. 1  depicts a connection between the health application  110 , running on processor A  100 , and the service application  130 , running on processor B  120 . The health application  110  communicates with the service application  130  to transmit collected data from the data generating devices and to obtain requested data. The health application  110  is capable of processing or storing data itself or sending data to the service application  130  for processing or storage. 
       FIG. 2  depicts the service application  130 , running on processor B  120 , communicating with a third party  200 . The third party  200  may be one of a social platform, a health professional, a database, and a site providing health, fitness, and/or nutritional information. The service application  130  can either process the information or transmit the data to a third party  200  for processing and/or feedback. The third party  200  relays the processed data and/or feedback to the service application  130 . 
       FIG. 3  depicts the communication between the health application  110  running on processor A  100 , the service application  130  running on processor B  120 , and a third party  200 . Both the health application  110  and the service application  130  can be interacted with by one of a user, an authorized doctor, personal trainer, nutritionist, family member, or any other entity the user selects. The user is able to specify who may interact with their data and which data the other entities are allowed to review. For instance, the user may restrict a nutritionist to only be able to review data relating to the user&#39;s nutrition. The user may also restrict the time frame in which another entity may review their data. For instance, the user may choose to permit access to his overall health data by a doctor only for the duration of an appointment. 
       FIG. 4  depicts the health application  110  collecting data from data generating devices  420 . The health application  110  runs on one of a smartphone, tablet, personal computer, or standalone device designed with a processor to run the health application  110 . The health application  110  can run on any device capable of joining or creating networks so as to transmit and receive data. The devices connected to the health application  110  have the capability of sending, receiving, storing, and transmitting data packets through a router  410  to a health monitoring system server  400  located locally or in the cloud. The health monitoring system server  400  can send one of data or requested information to the health application  110 . Devices may be connected by one of wired or wireless networks. The communication between the health application  110  and a data generating device  420  consists of sending and receiving data packets comprising one of static and dynamic data, and device  420  updates. 
       FIG. 5  depicts the service application  130  ( FIG. 1 ) obtaining data from the health application  110  ( FIG. 1 ) and/or a third party  200 , processing  520 , and transmitting the data. Data obtained by the health application  110  ( FIG. 1 ) is uploaded  500  to the service application  130  ( FIG. 1 ). Based on user preferences the service application  130  ( FIG. 1 ) can perform one of store  510 , process  520  or transmit the data to a third party  200 . If a third party  200  is processing the data, the processed data will transfer back to the service application  130  ( FIG. 1 ) and the service application  130  ( FIG. 1 ) will either store  510  the data or transmit the data back to the health application  110  ( FIG. 1 ). When the data has been processed  520  by one of a third party  200  or the service application  130  ( FIG. 1 ), the service application  130  ( FIG. 1 ) will relay feedback  530  back to one of third party  200  and/or the health application  110  ( FIG. 1 ). 
       FIG. 6  depicts devices running the health application  110  ( FIG. 1 ) or service application  130  ( FIG. 1 ). The devices may comprise a smartphone  620 , a computer  600 , a television  630 , scale, refrigerator, humidifier, treadmill, exercise bike, and vehicle. Based on user preferences, each device has the capability of running the health application  110  ( FIG. 1 ) and the service application  130  ( FIG. 1 ) concurrently or individually. A personal smartphone  620  can run the service application  130  ( FIG. 1 ) when a dedicated processor  610  or a computer  600  running the health application  110  ( FIG. 1 ) is present. The smartphone  620  is capable of running the health application  110  ( FIG. 1 ) when the dedicated processor  100  running the health application  110  ( FIG. 1 ) is out of range. The health data collected by the smartphone  620  when running the health application  110  ( FIG. 1 ) can be transferred to a dedicated processor  100  running the health application  110  ( FIG. 1 ) when it comes within range. 
       FIG. 7  depicts how the health application  110  and the service application  130  can operate on multiple devices and selectively connect and communicate with each other and the health monitoring system server  400 . The device, running one of the health application  110  and the service application  130  is one of a standalone device with a processor  610 , the cloud  400 , a computer  600 , a television  630 , and a smartphone  620 . The device collecting the data runs the health application  110  and is capable of receiving, transmitting, or processing the health data and information. The data generating devices  420  ( FIG. 4 ) can connect to any device running the health application  110 , which may then transmit data to a service application  130 , running either locally or on the health monitoring system server  400 . The health monitoring service can be located on one of health monitoring system server  400  or a network based service. The communication can be relayed by one of wired or wireless methods between the data stored on the server and the health application  110 . The health monitoring system server  400  and the health application  110  are capable of communicating with external sources including one of social media, SMS messages, email, and other notification techniques. 
       FIG. 8  depicts a user being prompted by the health application  110  ( FIG. 1 ) to perform or acknowledge a required action  800 . Based on user preferences, the health application  110  ( FIG. 1 ) can prompt the user  810  by a notification. The user can interact  820  with the notification by one of performing, dismissing, or resetting the required action. The health application  110  ( FIG. 1 ) can recognize the action taken by one of the activation of a data generating device  420  ( FIG. 4 ) and/or user response. When a data generating device  420  ( FIG. 4 ) as in use, the health application  110  ( FIG. 1 ) can record  830  the data and provide feedback to the user. 
       FIG. 9  illustrates a user being notified by one of a health application  110  ( FIG. 1 ) and service application  130  ( FIG. 1 ) running on the smartphone  620  to advise the use of an inhaler  900  based on the analyzed environmental data obtained from a data generating device  420 . The dedicated processor  610  running the health application continuously collects and analyzes environmental data. The dedicated processor  610  running the health application transmits a notification to the smartphone  620  running one of a health application  110  ( FIG. 1 ) or service application  130  ( FIG. 1 ) advising the use of an inhaler  900 . The environmental data can be analyzed by one of health application  110  ( FIG. 1 ), service application  130  ( FIG. 1 ) and third party  200  ( FIG. 2 ) and generate feedback based on the analysis. 
       FIG. 10  depicts initialization  1000  of the health application  110  ( FIG. 1 ) by a user to collect and analyze health data obtained from a data generating device  420  ( FIG. 4 ). The activation of the health data generating device  1000  by the user prompts the health application  110  ( FIG. 1 ) to begin recording or process data  1010 . Based on user preferences, the recording session  1010  can be initiated by interacting with the health application  110  ( FIG. 1 ) or the data generating device  420  ( FIG. 4 ). When a data generating device  420  ( FIG. 4 ) is in use the data is recorded  1010 , transmitted to the health application  1020 , processed by the health application  1030 , and feedback is relayed to the user  1040 . 
       FIG. 11  depicts a user measuring his body parameters with a wireless scale  1110  and transmitting the data to a dedicated processor  610  running the health application. The data is then relayed to the smartphone  620 , running the service application  130  ( FIG. 1 ). The health application  110  ( FIG. 1 ) is capable of identifying the user that is on the wireless scale  1110  when the measurements are recorded. A secure connection is established between the wireless scale  1110  and the dedicated processor  6111  running the health application. The smartphone  620  running the service application  130  ( FIG. 1 ) displays the status of the connection on the smartphone&#39;s screen  1100 . The parameters of the user are then obtained from the health application  110  ( FIG. 1 ), displayed on the smartphone screen  1100 , and recorded based on user preferences. 
       FIG. 12  illustrates an instance of the health application  110  ( FIG. 1 ) running on a smartphone  620 . The smartphone  620  is able to perform at least one of collect, store, transfer, process, and provide feedback through the health application  110  ( FIG. 1 ). Data or processed information is received from any connected data generating device  420  ( FIG. 4 ), with or without the presence of a connected server. The health application  110  ( FIG. 1 ) is capable of modifying the data generating device  420  ( FIG. 1 ) function (e.g. mode, weight, necessary repetitions, resistance, speed, etc.) or generating feedback (e.g. vibrations, sounds, fights, displays, etc.). Feedback can prompt, provide, network, and/or otherwise influence user interaction. Though depicted as a smartphone  620  within the figure, any device can run the health application  110  ( FIG. 1 ). Data generating devices  420  ( FIG. 4 ) that can connect to the health application  110  ( FIG. 1 ) include: transportation device  1200 , medical device  1210 , gym device  1220 , office device  1230 , and home device  1240 . 
       FIG. 13  illustrates a user collecting exercise data with a device  1300  running the health application  110  ( FIG. 1 ). The device  1300  is securely connected to a data generating device  420   FIG. 4 ) and the built in sensors located in the footwear  1320 . The data generating device  420  ( FIG. 4 ) can be one of contact and noncontact sensors. The device  1300  running the health application  110  ( FIG. 1 ) is capable of constantly collecting health and fitness related data and storing the data based on user preferences. The collected data is also displayed on the device  1300  running the health application  110  ( FIG. 1 ) to allow the user to see their current progress and any problems that may have been detected during exercise. The problems could be related to health or the equipment being used during exercise. The collected data may be displayed to the user on the device&#39;s  1300  user interface  1310 . 
       FIG. 14  illustrates how the health application  110  ( FIG. 1 ) cart identify in-use health equipment  1400 ,  1420  and available health equipment  1410  in a gym. As the user enters the gym, the device running the health application  110  ( FIG. 1 ) will connect to the local gym network. The local gym network can provide a list of authorized workout equipment. From this authorized workout list, the health application  110  ( FIG. 1 ) will identify available equipment  1410  and/or notify the user when the equipment becomes available for use. The health application  110  ( FIG. 1 ) running on the smartphone  620  can do one of selectively connect to available equipment  1410  and/or notify the user when the in-use equipment  1400 ,  1420  becomes available  1410 . 
       FIG. 15  depicts how the health application  110  ( FIG. 1 ) or the service application  130  ( FIG. 1 ) goes through the initialization process  1500  which includes opening the application one of personal computer  600  ( FIG. 6 ), television  630  ( FIG. 6 ), smartphone  620  ( FIG. 6 ), or a stand-alone processor  610  ( FIG. 6 ). A system cheek  1510  accesses one of stored or streamed data to determine if the application is malfunctioning. Failure to pass the system check, will cause the application to relay the error  1520  to at least one of the server  400  ( FIG. 4 ) or the user. After an error is relayed, the health application  110  ( FIG. 1 ) or service application  130  ( FIG. 1 ) can attempt to resolve the error  1530  and prompt the user on failure. If no error exists, the application continues the initialization process by searching for a network  1540 . This process can include connecting to one of cellular network, existing wireless network, and ad hoc network. If no network is found or established, operation is limited to offline functions  1550 , including one of collecting, storing, processing, or recalling data or information stored on the device running the health application  110  ( FIG. 1 ) or service application  130  ( FIG. 1 ). 
       FIG. 16  depicts a network resolution  1600  that includes one of the process of identifying, connecting, authorizing  1620 , and any other steps that may be part of a selected network&#39;s initialization and connection process. Based on user preferences, the network will be resolved  1600  either automatically or after receiving manual user input. The network can consist of one of the server, local network, or offline network. Once selectively connected to a network, the health application  110  ( FIG. 1 ) will monitor  1610  for available data generating devices  400  ( FIG. 4 ). The health application  110  ( FIG. 1 ) can selectively connect  1620  to one or more data generating devices  490  ( FIG. 4 ) automatically or selected via user input. The health application  110  ( FIG. 1 ) connects  1620  to the device by sending a request to the device and receiving confirmation that the device is connected. The connection is secured through a variety of protocols. Once connected, a new or continued data session  1630  can be prompted by the health application  110  ( FIG. 1 ) by either opening a data session  1640  or recording the incoming data stream to an existing file  1680 . This can occur automatically or manually. When a new session is selected, the data can be stored in memory  1670  on one of the device, cloud, or server. Beginning a new session  1640  can associate data with personal preferences  1650 . New preferences can be created based on one of user input, advisory input, advisory are professional input, or based on repeated behavior and can be stored on one of the device, network, or server. The data streamed from the device will be recorded over the duration of the session. The health application  110  ( FIG. 1 ) can stream data to new session  1660  and store data  1670  on one of a device, server, local network, or website. If user opts to continue from previous session, the health application  110  ( FIG. 1 ) can load data from the previous session  1680  and new data can be added to the previous session. The data collected while on the offline network can be uploaded to one of the health monitoring system server  400  ( FIG. 4 ), website, or personal computer when a connection is established and can be combined with previous data as determined by the user. 
       FIG. 17  depicts how the data generating device  420  ( FIG. 4 ) powers up  1700  and continuously monitors the data generating device  420  ( FIG. 4 ) for error. The data generating device  420  ( FIG. 4 ) will perform a system check  1710  to identity if any system errors have occurred  1720 . If no system errors have occurred, the data generating device  420  ( FIG. 4 ) can connect  1730  to the health application  110  ( FIG. 1 ). If system errors have occurred, the data generating device will relay error  1740  to one of the user, health application  110  ( FIG. 1 ), or server. The data generating device  420  ( FIG. 4 ) will attempt to resolve error  1750 . 
       FIG. 18  depicts how data collected while on the offline network is transferred from the health application  110  ( FIG. 1 ) to one or more of the server  400  ( FIG. 4 ) local network, or website when a preferred connection is established. The health application  110  ( FIG. 1 ) will close the data packet  1800 , identify the recipient of the data packet  1810 , and then prepare the packet for transfer  1820 . When the preferred network is available  1830 , the health application  110  ( FIG. 1 ) will transmit data  1860  to one or more of the server  400  ( FIG. 4 ), local network, or website. When the data has been received by one of the server  400  ( FIG. 4 ), local network, or website, the health application  110  ( FIG. 1 ) will receive confirmation  1870  that the data has been successfully transmitted. After the data is received, one of the server  400  ( FIG. 4 ), local network, service application  130  ( FIG. 1 ), or website will execute data preferences  1880 . If no preferred network is available, the data packet will be stored locally  1840  on the device running the health application  110  ( FIG. 1 ). The health application  110  ( FIG. 1 ) can retry transmitting  1860  the assembled packet when the next preferred network is available. If a preferred network is available, the health application  110  ( FIG. 1 ) will transmit data  1860  to one or more Of the server  400  ( FIG. 4 ), local network, or website. 
       FIG. 19  depicts elements of, a transmission data packet. The diagram can include all components listed, but may vary according to the needs of connected applications and devices. When a device transmits a data packet, the routing  1960  portion will comprise at least one of the transmission protocol  1900 , the security tag  1910 , and the priority tag  1920 . The transmission protocol  1900  can vary based on the network used to connect the devices to the health application  110  ( FIG. 1 ). The security tag  1910  and the priority tag  1920  are detectable by any device, and can be modified based on the packet destination, or in the case of priority, different packet handling techniques. Error messages or emergency information can be decomposed and transmitted differently by the device running the health application  110  ( FIG. 1 ) or a service application  130  ( FIG. 1 ). The security tag  1920  will be used to prevent unauthorized access or use of the personal information including, but not limited to all of the application data  1970 . Application data  1970  comprises the device tag  1930  and the payload, comprising of measurement type  1940  and the data  1950 . The device tag  1930  identities the device and allows connected applications to locate drivers or files pertinent to data  1950  interpretation and allocation. 
       FIG. 20  depicts how the health application  110  ( FIG. 1 ) can request data  2000  from one of a server  400  ( FIG. 4 ), local network, website, or device. The requested data  2000  can comprise one or more of device drivers, past workouts, recommended workout, nutrition data, or medical data. The health application  110  ( FIG. 1 ) or the service application  130  ( FIG. 1 ) can request data automatically or by user selection. The health application  110  ( FIG. 1 ) will determine if the data is stored locally  2010 . If no data is stored locally, the health application  110   FIG. 1 ) will connect  2020  to one or more of the server  400  ( FIG. 4 ) local network, or website. The health application  110  ( FIG. 1 ) will request information  2030  and retrieve information  2040  from one or more of the server  400  ( FIG. 4 ), local network, or website. If the data is stored locally, the health application  110  ( FIG. 1 ) will retrieve data  2050  from the device and process data  2060 . When the requested information is retrieved from one of a server  400  ( FIG. 4 ), local network, website, or device the health application  110  ( FIG. 1 ) will relay information  2070  to the user. 
       FIG. 21  illustrates two users having used the health application  110  ( FIG. 1 ) to gather data which is used to reflect their personal fitness and health on their respective characters in a game  2100 . This game  2100  is incorporated in the abilities of the invention with a purpose to encourage users to improve personal physical fitness and health. A user&#39;s game character may directly reflect the real world fitness and health status of the user. The game may comprise any format such as one-on-one physical combat as depicted, military combat and strategy, fantasy role-playing, or any other form in which points, traits, skills, and other attributes or accessories may be rewarded based on one of personal fitness, health, nutrition, and improvement thereof. The points, traits, skills, and other attributes or accessories earned may also be applied to existing games that choose to participate. 
       FIG. 22  illustrates a user collecting data from a thermometer  2200  that is capable of generating data. The data is then sent to the health application  110  ( FIG. 1 ) running on a smartphone  620 . Additional symptom data may be submitted to the health application  110  ( FIG. 1 ) manually by the user or gathered from other data generating devices  420  ( FIG. 4 ). The health application  110  ( FIG. 1 ) may display feedback to the user about their health or fitness state, and suggestions for the user to review based on the collected and/or manually entered data. 
       FIG. 23  illustrates a user using a smartphone  620  to capture a picture of a rash on his arm. This picture is then uploaded to a diagnosing website and/or a health professional for immediate and convenient diagnosis. Although the figure shows a user utilizing a smartphone  620  to capture a picture, other methods of receiving a diagnosis are available. These other methods include using other devices to automatically upload information that can be accessed by a health professional for monitoring. An example would be an insulin device tracking sugar levels and automatically transmitting and/or storing the data on a server, local network, or web site that is remotely monitored by a health professional. User preferences may be set to only send data to one or more specific health professionals, or to automatically connect to the first available health professional. 
       FIG. 24  depicts a data generating device  420  ( FIG. 4 ) analyzing bio-material consisting of one of hair, blood, urine, stool and saliva. The data generating device  420  ( FIG. 4 ) system power up  2400  sequence will be initiated by one of contact or noncontact. When the data generating device  420  ( FIG. 4 ) is powered up  2400 , the device can securely connect  2410  to the health application  110  ( FIG. 1 ) if selected by the user. One of the data generating device  420  ( FIG. 4 ), user, or the health application  110  ( FIG. 1 ) will check for updates  2420  and calibrations located on one of a server  400  ( FIG. 4 ), local network, website, or device. One of the data generating device  420  ( FIG. 4 ), user, or the health application  110  ( FIG. 1 ) will apply updates and calibrations  2430  to the data generating device  420  ( FIG. 4 ), One of the data generating device  420  ( FIG. 4 ), user, or the health application  110  ( FIG. 1 ) will detect whether or not the biological sample is present  2440 . If the biological sample is not present  2440 , one of the health application  110  ( FIG. 1 ), server  400  ( FIG. 4 ), or data generating device  420  ( FIG. 4 ) will prompt for a sample  2450 . If the biological sample is present, one of the health application  110  ( FIG. 4 ), server  400  ( FIG. 4 ), or a data generating device  420  ( FIG. 4 ) will analyze sample  2460 . When the biological sample analysis  2460  is complete, one of the health application  110  ( FIG. 1 ) or the data generating device  420  ( FIG. 4 ) will relay results  2470  to at least one of the user, website, or health care provider and store results  2480 . 
       FIG. 25  depicts the process for requesting and obtaining feedback  2500  based on user specifications. The user requests health data using the health application  110  ( FIG. 1 .) or the service application  130  ( FIG. 1 ). The health data can be collected  2510  by one of health application  110  ( FIG. 1 ), service application  130  ( FIG. 1 ), and third party  200  ( FIG. 2 ). Once the health data has been collected  2510 , the health data is analyzed  2520  by one of the health application  110  ( FIG. 1 ), service application  130  ( FIG. 1 ), or third party  200  ( FIG. 2 ). The health data is then relayed to the user  2530  through the health or service application  130  ( FIG. 1 ). 
       FIG. 26  illustrates use of the nutrition functions of the device where a user is able to receive dietary information related to a meal. A restaurant might have meal information available online, on a device, or a running application designed to connect to the user&#39;s smartphone  620  running the health application  110  ( FIG. 1 ) or the service application  130  ( FIG. 1 ). Meal selection may be entered manually by the user or automatically by the device or server  400  ( FIG. 4 ). The health application  110  ( FIG. 1 ) or the service application  130  ( FIG. 1 ) may make recommendations for restaurant and meal selections based on user criteria such as allergies, past workouts, or preferred diet. The health application  110  ( FIG. 1 ) or the service application  130  ( FIG. 1 ) is also capable of recommending activities to assist in meeting nutritional goals based on user criteria. 
       FIG. 27  illustrates a user  2720  and health professional  2710  reviewing health data. The health application  110  ( FIG. 1 ) or service application  130  ( FIG. 1 ) is capable of presenting the health professional  2710  with selected information on a display  2750 . The health care professional  2710  can be one of a medical, professional, personal trainer, nutritionist or other professionals in health and/or fitness fields and the user&#39;s information is used to make accurate diagnosis and/or to help with recommendations. Though the illustration shows both the user and the professional  2710 , the data may be reviewed independently by either party, allowing a user to track their own health and overall wellness or for the professional  2710  to make recommendations without the need of a face to face meeting. 
       FIGS. 28, 29 and 30  illustrate the process steps of Secure Simple Pairing including configuration management, data logging management and security management as disclosed in the U.S. Pat. No. 7,146,260. 
     Non-Transitory Computer Readable Medium 
     Certain aspects of the present disclosure may also be embodied as computer readable code on a non-transitory computer readable recording medium. A non-transitory computer readable recording medium is any data storage device that can store data, which can be thereafter read by a computer system. Examples of the non-transitory computer readable recording medium include read only memory (ROM), random access memory (RAM), compact disc-ROMs (CD-ROMs), magnetic tapes, floppy disks, optical data storage devices, and carrier waves (such as data transmission through the Internet). The non-transitory computer readable recording medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion. In addition, functional programs, code, and code segments for accomplishing the present disclosure can be easily construed by programmers skilled in the art to which the present disclosure pertains. 
     It can be appreciated that a method and apparatus according to an embodiment of the present disclosure may be implemented by hardware, software and/or a combination thereof. The software may be stored in a non-volatile storage, for example, an erasable or re-writable ROM, a memory, for example, a RAM, a memory chip, a memory device, or a memory integrated circuit (IC), or an optically or magnetically recordable non-transitory machine-readable (e.g. computer-readable), storage medium (e.g., a CD, a digital versatile disk (DVD), a magnetic disk, a magnetic tape, and/or the like). A method and apparatus according to an embodiment of the present disclosure may be implemented by a computer or a mobile terminal that includes a controller and a memory, and the memory may be an example of a non-transitory machine-readable (e.g., computer-readable), storage medium suitable to store a program or programs including instructions for implementing various embodiments of the present disclosure. 
     The present disclosure may include a program including code for implementing the apparatus and method as defined by the appended claims, and a non-transitory machine-readable (e.g., computer-readable), storage medium storing the program. The program may be electronically transferred via any media, such as communication signals, which are transmitted through wired and/or wireless connections, and the present disclosure may include their equivalents. 
     An apparatus according to an embodiment of the present disclosure may receive the program from a program providing device which is connected to the apparatus via a wire or a wireless and store the program. The program providing device may include a memory for storing instructions which instruct to perform a content protect method which has been already installed, information used for the content protect method, and the like, a communication unit for performing a wired or a wireless communication with a graphic processing device, and a controller for transmitting a related program to a transmitting/receiving device based on a request of the graphic processing device or automatically transmitting the related program to the transmitting/receiving device. 
     While the present disclosure has been shown and described with reference to various embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present disclosure as defined by the appended claims and their equivalents. 
     For the sake of convenience, the operations are described as various interconnected functional blocks or distinct software modules. This is not necessary, however, and there may be cases where these functional blocks or modules are equivalently aggregated into a single logic device, program or operation with unclear boundaries. In any event, the functional blocks and software modules or described features can be implemented by themselves, or in combination with other operations in either hardware or software. 
     Having described and illustrated the principles of the systems, methods, processes, and/or apparatuses disclosed herein in a preferred embodiment thereof, it should be apparent that the systems, methods, processes, and/or apparatuses may be modified in arrangement and detail without departing from such principles. Claim is made to all modifications and variation coming within the spirit and scope of the following claims.