PATENT DOCUMENT

Publication Number: US-9141504-B2
Application Number: US-201213535995-A
Country: US
Kind Code: B2

Title: Presenting status data received from multiple devices

Abstract:
Disclosed herein are systems, methods, and non-transitory computer-readable storage media for presenting status data received from multiple computing devices in a single central interface. A computing device can be configured to gather and transmit status data. Status data can include any type of data known or discoverable by a computing device. The computing device can also be configured to receive status data from other computing devices and display the status data in a central interface. This functionality can be implemented as part of the operating system running on the computing device. The computing device can also utilize the received status data to select performance options regarding the performance of the computing device. For example, a computing device can select to disable functionality that requires the availability of a target computing device upon a determination that the target computing device is unavailable.

Claims:
We claim: 
     
       1. A method, comprising:
 receiving, by a receiving computing device, status data from a broadcasting computing device of an automobile, wherein:
 the receiving computing device and the broadcasting computing device are separate computing devices, 
 the status data describes automobile maintenance information obtained from a plurality of sensors and a location of the automobile, 
 the receiving computing device infers that the user will be traveling via car based on the location of the automobile being substantially similar to the location of the receiving computer device, and 
 the receiving computing device is presenting a travel route to a specified destination; 
 
 determining, by the receiving computing device, from the automobile maintenance information obtained from the plurality of sensors, that the automobile requires a particular maintenance service; 
 presenting, by the receiving computing device, an advertisement that is selected based on the particular maintenance service, the location of the automobile, and the travel route; 
 presenting, by the receiving computing device, the status data in a central interface that can present status data received from a plurality of broadcasting devices; and 
 sending, by the receiving computing device, an activity level to the broadcasting computing device, wherein the activity level includes at least one of a bandwidth currently used by the receiving computing device and an amount of time since the receiving computing device has been accessed, and wherein an amount and a frequency of the status data received from the broadcasting computing device is based on the activity level of the receiving computing device. 
 
     
     
       2. The method of  claim 1 , wherein the receiving computing device and the broadcasting computing device are running a form of an operating system that enables a computing device to transmit, receive and display the status data. 
     
     
       3. The method of  claim 1 , wherein the status data indicates that the broadcasting device is unavailable and in response, the receiving computing device disables functionality that requires the availability of the broadcasting computing device. 
     
     
       4. The method of  claim 1 , wherein the status data indicates an available bandwidth of the broadcasting device and the receiving computing device selects a performance option that includes transmitting data to the broadcasting device in a form determined to be optimal for the available bandwidth. 
     
     
       5. The method of  claim 1 , further comprising:
 selecting a performance option based upon the status data, wherein selecting the performance option includes adjusting settings of the receiving device. 
 
     
     
       6. A receiving computing device, comprising:
 a processor; and 
 a memory containing instructions that, when executed, cause the processor to:
 receive status data from a broadcasting computing device of an automobile, wherein: the receiving computing device and the broadcasting computing device are separate computing devices, 
 the status data describes automobile maintenance information obtained from a plurality of sensors and a location of the automobile, 
 the receiving computing device infers that the user will be traveling via car based on the location of the automobile being substantially similar to the location of the receiving computer device, and 
 the receiving computing device is presenting a travel route to a specified destination; 
 
 determine, from the automobile maintenance information obtained from the plurality of sensors, that the automobile requires a particular maintenance service; 
 present an advertisement that is selected based on the particular maintenance service, the location of the automobile, and the travel route; 
 present the status data in a central interface that can present status data received from a plurality of broadcasting devices; and 
 send an activity level to the broadcasting computing device, wherein the activity level includes at least one of a bandwidth currently used by the receiving computing device and an amount of time since the receiving computing device has been accessed, and wherein an amount and a frequency of the status data received from the broadcasting computing device is based on the activity level of the receiving computing device. 
 
     
     
       7. The receiving computing device of  claim 6 , wherein the receiving computing device and the broadcasting computing device are running a form of an operating system that enables a computing device to transmit, receive and display the status data. 
     
     
       8. The receiving computing device of  claim 6 , wherein the status data indicates that the broadcasting device is unavailable and in response, the receiving computing device disables functionality that requires the availability of the broadcasting computing device. 
     
     
       9. The receiving computing device of  claim 6 , wherein the status data indicates an available bandwidth of the broadcasting device and the receiving computing device selects a performance option that includes transmitting data to the broadcasting device in a form determined to be optimal for the available bandwidth. 
     
     
       10. The receiving computing device of  claim 6 , further comprising instructions that cause the processor to:
 select a performance option based upon the status data, wherein selecting the performance option includes adjusting settings of the receiving device. 
 
     
     
       11. A non-transitory computer-readable medium including instructions that, when executed by a receiving computing device, cause the receiving computing device to:
 receive status data from a broadcasting computing device of an automobile, wherein: the receiving computing device and the broadcasting computing device are separate computing devices, 
 the status data describes automobile maintenance information obtained from a plurality of sensors and a location of the automobile, 
 the receiving computing device infers that the user will be traveling via car based on the location of the automobile being substantially similar to the location of the receiving computer device, and 
 the receiving computing device is presenting a travel route to a specified destination; 
 determine, from the automobile maintenance information obtained from the plurality of sensors, that the automobile requires a particular maintenance service; 
 present an advertisement that is selected based on the particular maintenance service, the location of the automobile, and the travel route; 
 present the status data in a central interface that can present status data received from a plurality of broadcasting devices; and 
 send an activity level to the broadcasting computing device, wherein the activity level includes at least one of a bandwidth currently used by the receiving computing device and an amount of time since the receiving computing device has been accessed, and wherein an amount and a frequency of the status data received from the broadcasting computing device is based on the activity level of the receiving computing device. 
 
     
     
       12. The non-transitory computer-readable medium of  claim 11 , wherein the receiving computing device and the broadcasting computing device are running a form of an operating system that enables a computing device to transmit, receive and display the status data. 
     
     
       13. The non-transitory computer-readable medium of  claim 11 , wherein the status data indicates that the broadcasting device is unavailable and in response, the receiving computing device disables functionality that requires the availability of the broadcasting computing device. 
     
     
       14. The non-transitory computer-readable medium of  claim 11 , wherein the status data indicates an available bandwidth of the broadcasting device and the receiving computing device selects a performance option that includes transmitting data to the broadcasting device in a form determined to be optimal for the available bandwidth. 
     
     
       15. The non-transitory computer-readable medium of  claim 11 , further comprising instructions that cause the receiving computing device to:
 select a performance option based upon the status data, wherein selecting the performance option includes adjusting settings of the receiving device.

Description:
BACKGROUND 
     1. Technical Field 
     The present disclosure relates to presenting data and, more specifically, to presenting status data received from multiple devices. 
     2. Introduction 
     Modern technology has made gathering data easier than ever. For example, computing devices can monitor a variety of things such as location, lighting level, temperature, remaining battery levels, speed, network connection type, etc. Further, wireless data connections make connecting any computing device possible. While modern computing devices and wireless connections make gathering and transmitting data easier than ever, remotely viewing all of this data still faces numerous obstacles. 
     For one, the variety of device types and the volume of data make viewing data from multiple devices unpractical. Even if an application or interface is provided, viewing the variety of data requires accessing multiple applications to view the data regarding each application. This is both time consuming and resource intensive and provides the user a disjointed view of the data. Secondly, the technical requirements of creating an interface such as an application to allow data from a device to be viewed remotely can be costly and outside of the expertise of many types of product manufacturers. This is especially true for devices such as appliances like an oven or microwave. While being able to remotely view data regarding these devices would be useful, creating an application to view this data remotely may not be financially worthwhile for an appliance manufacturer, especially since writing software is not an appliance maker&#39;s expertise, and thus may not be available to a user. 
     These obstacles result in an underutilization of the current capabilities that computers and networking provide us to share data and thus be better informed to make better decisions. As a result, time and effort are often wasted by uninformed decisions. For example, being able to quickly determine whether the oven was left on can avoid a wasted trip home or higher utility bill resulting from not returning to turn off the oven. Even smaller tasks such as calling a friend can result in wasted time if his or her cellular phone is turned off. Knowing what forms of communication are currently available to contact the friend would result in an informed decision and avoid the wasted time. Accordingly, there is a need for a way to easily share and view data from a plurality of devices so that a user can make informed decisions. 
     SUMMARY 
     Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or can be learned by practice of the herein disclosed principles. The features and advantages of the disclosure can be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the disclosure will become more fully apparent from the following description and appended claims, or can be learned by the practice of the principles set forth herein. 
     Disclosed are systems, methods, and non-transitory computer-readable storage media for presenting status data received from multiple computing devices in a single central interface. A computing device can gather status data regarding the computing device and transmit the gathered status data to other computing devices. Status data can include any type of data known or discoverable by a computing device. Additionally, the computing device can receive status data from other computing devices and display the status data in a central interface. This functionality can be implemented as part of the operating system running on the computing device and can thus enable all computing devices running a form of the operating system to transmit and receive status data as well as display the status data. 
     Enabling the functionality as part of the operating system allows status data to be easily gathered and transmitted from any computing device without a need for developing software or custom interfaces. Further, displaying the status data in a central interface enables a user to quickly and easily view the status received from multiple devices and make informed decisions based on the status data. 
     The computing device can also utilize the received status data to select performance options regarding the performance of the computing device. For example, a computing device can select to disable functionality that requires the availability of a target computing device upon a determination that the target computing device is unavailable. Alternatively, the computing device can use status data received from a sensor on another computing device to select a performance option. For example, a computing device without a lighting sensor can adjust its display settings to be optimal for a reading received from a light sensor on another computing device. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In order to describe the manner in which the above-recited and other advantages and features of the disclosure can be obtained, a more particular description of the principles briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only exemplary embodiments of the disclosure and are not therefore to be considered to be limiting of its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings in which: 
         FIG. 1  illustrates an exemplary system embodiment of a general-purpose computing device; 
         FIG. 2  illustrates a general purpose computing environment wherein multiple computing devices can communicate with each other to transmit and receive status data; 
         FIG. 3  illustrates a screen shot of an exemplary central interface; and 
         FIG. 4  illustrates an exemplary method embodiment of using status data to select performance options. 
     
    
    
     DETAILED DESCRIPTION 
     Various embodiments of the disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the disclosure. 
       FIG. 1  illustrates an exemplary system  100  that includes a general-purpose computing device  100 , including a processing unit (CPU or processor)  120  and a system bus  110  that couples various system components including the system memory  130  such as read only memory (ROM)  140  and random access memory (RAM)  150  to the processor  120 . The system  100  can include a cache  122  of high speed memory connected directly with, in close proximity to, or integrated as part of the processor  120 . The system  100  copies data from the memory  130  and/or the storage device  160  to the cache  122  for quick access by the processor  120 . In this way, the cache  122  provides a performance boost that avoids processor  120  delays while waiting for data. These and other modules can control or be configured to control the processor  120  to perform various actions. Other system memory  130  may be available for use as well. The memory  130  can include multiple different types of memory with different performance characteristics. It can be appreciated that the disclosure may operate on a computing device  100  with more than one processor  120  or on a group or cluster of computing devices networked together to provide greater processing capability. The processor  120  can include any general purpose processor and a hardware module or software module, such as module  1   162 , module  2   164 , and module  3   166  stored in storage device  160 , configured to control the processor  120  as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor  120  may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric. 
     The system bus  110  may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. A basic input/output (BIOS) stored in ROM  140  or the like, may provide the basic routine that helps to transfer information between elements within the computing device  100 , such as during start-up. The computing device  100  further includes storage devices  160  such as a hard disk drive, a magnetic disk drive, an optical disk drive, tape drive or the like. The storage device  160  can include software modules  162 ,  164 ,  166  for controlling the processor  120 . Other hardware or software modules are contemplated. The storage device  160  is connected to the system bus  110  by a drive interface. The drives and the associated computer readable storage media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the computing device  100 . In one aspect, a hardware module that performs a particular function includes the software component stored in a non-transitory computer-readable medium in connection with the necessary hardware components, such as the processor  120 , bus  110 , display  170 , and so forth, to carry out the function. The basic components are known to those of skill in the art and appropriate variations are contemplated depending on the type of device, such as whether the device  100  is a small, handheld computing device, a desktop computer, or a computer server. 
     Although the exemplary embodiment described herein employs the hard disk  160 , it should be appreciated by those skilled in the art that other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, digital versatile disks, cartridges, random access memories (RAMs)  150 , read only memory (ROM)  140 , a cable or wireless signal containing a bit stream and the like, may also be used in the exemplary operating environment. Non-transitory computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se. 
     To enable user interaction with the computing device  100 , an input device  190  represents any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input and so forth. An output device  170  can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems enable a user to provide multiple types of input to communicate with the computing device  100 . The communications interface  180  generally governs and manages the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed. 
     For clarity of explanation, the illustrative system embodiment is presented as including individual functional blocks including functional blocks labeled as a “processor” or processor  120 . The functions these blocks represent may be provided through the use of either shared or dedicated hardware, including, but not limited to, hardware capable of executing software and hardware, such as a processor  120 , that is purpose-built to operate as an equivalent to software executing on a general purpose processor. For example, the functions of one or more processors presented in  FIG. 1  may be provided by a single shared processor or multiple processors. (Use of the term “processor” should not be construed to refer exclusively to hardware capable of executing software.) Illustrative embodiments may include microprocessor and/or digital signal processor (DSP) hardware, read-only memory (ROM)  140  for storing software performing the operations discussed below, and random access memory (RAM)  150  for storing results. Very large scale integration (VLSI) hardware embodiments, as well as custom VLSI circuitry in combination with a general purpose DSP circuit, may also be provided. 
     The logical operations of the various embodiments are implemented as: (1) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a general use computer, (2) a sequence of computer implemented steps, operations, or procedures running on a specific-use programmable circuit; and/or (3) interconnected machine modules or program engines within the programmable circuits. The system  100  shown in  FIG. 1  can practice all or part of the recited methods, can be a part of the recited systems, and/or can operate according to instructions in the recited non-transitory computer-readable storage media. Such logical operations can be implemented as modules configured to control the processor  120  to perform particular functions according to the programming of the module. For example,  FIG. 1  illustrates three modules Mod 1   162 , Mod 2   164  and Mod 3   166  which are modules configured to control the processor  120 . These modules may be stored on the storage device  160  and loaded into RAM  150  or memory  130  at runtime or may be stored as would be known in the art in other computer-readable memory locations. 
     Having disclosed some components of a computing system, the disclosure now turns to  FIG. 2 , which illustrates a general purpose computing environment  200  wherein multiple computing devices can communicate with each other to transmit and receive status data. As illustrated, multiple computing devices can be connected to a communication network  210  to communicate with each other through use of the communication network  210 . The communication network  210  can be any type of network, including a local area network (“LAN”), such as an intranet, a wide area network (“WAN”), such as the internet, or any combination thereof. Further, the communication network  210  can be a public network, a private network, or a combination thereof. The communication network  210  can also be implemented using any type or types of physical media, including wired communication paths and wireless communication paths associated with one or more service providers. Additionally, the communication network  210  can support the transmission of messages formatted using a variety of protocols such as an established transmission protocol such as Bluetooth® or other similar type of communications standard. 
     A computing device can be any type of general computing device capable of network communication with other computing devices. For example, a computing device can be a personal computing device such as a desktop or workstation, a business server, or a portable computing device, such as a laptop, smart phone, or a post-pc device, or any other device capable of network communication such as a computer embedded in an automobile or appliance such as a refrigerator, heart rate monitor, etc. A computing device can include some or all of the features, components, and peripherals of computing device  100  of  FIG. 1 . 
     A computing device can include a communications interface, which facilitates communication with other computing devices. The communications interface can receive a communication, such as a request, data, etc., from another computing device in network communication with the computing device and pass the communication along to an appropriate module running on the computing device. The communication interface can also send a communication to another computing device in network communication with the computing device. 
     As illustrated, three computing devices: a receiving device  205 , a broadcasting device  215  and a status server  220  can be connected to the communication network and communicate with each other to transmit and receive status data. Status data can be any type of data known or discoverable by a computing device. For example status data can include information identifying the computing device such as the device type, manufacturer, device name, etc. Status data can also include data pertaining to the current state of the computing device such as whether the computing device is powered on, what applications are installed and/or running on the computing device, current resource usage of the computing device, location of the computing device, etc. The status data can also include data gathered by a computing device such as data gathered from sensors or components included as part of the computing device, data gathered from applications running on the computing device such as requirements of an application, or data gathered from external sources such as other computing devices connected to the computing device. These examples are only some of the possible types of status data and are not meant to be limiting. One skilled in the art would recognize that there are numerous other types of status data. 
     The broadcasting device  215  can gather status data and broadcast the status data to an authorized receiving device  205  that can receive the status data from the broadcasting device  215  and display the received status data in a central interface. Although the broadcasting device  215  and the receiving device  205  are discussed as two separate types of devices, this is only done for ease of explanation and is not meant to be limiting. The receiving device  205  can also be a broadcasting device  215  that can gather status data and broadcast the status data to other receiving devices and the broadcasting device  215  can also receive status data and display the received status data in a central interface. 
     Likewise, the number of broadcasting and receiving devices is only used as a simple example and not meant to be limiting. A broadcasting device can broadcast status data to any number of authorized receiving devices and a receiving device can receive status data from any number of broadcasting devices and display status data received from each broadcasting device in the central interface. Further, the relationship does not have to be reciprocal. For example, a broadcasting device that can also receive status data does not have to be authorized to receive status data from each receiving device to which the broadcasting device broadcasts status data. Likewise, a receiving device does not have to broadcast status data to each broadcasting device from which the receiving device receives status data. 
     Returning to the discussion of  FIG. 2 , the broadcasting device  215  can include a broadcasting module  225  that can gather status data and broadcast the status data to the receiving device  205 . The broadcasting module  225  can gather status data from multiple sources, such as from hardware or software on the broadcasting device  215  as well as other devices connected to the broadcasting device. To gather the status data, the broadcasting module  215  can communicate with the operating system to request and receive status data regarding hardware and software on the device. In some embodiments, the broadcasting module  225  can be implemented as part of the operating system running on the broadcasting device  215  and thus have access to communicate with all hardware included in the device as well as all software running on the device. In some embodiments, the broadcasting module  225  can store the gathered status data in a broadcasting database  230  included in the broadcasting device  215 . 
     The broadcasting module  225  can broadcast the gathered status data to the receiving device  205 . Broadcasting the status data can include transmitting the status data to the receiving device  205 . In some embodiments, the broadcasting module  225  can transmit the status data directly to the receiving device  205 . For example, the broadcasting module  225  can use data identifying the receiving device  205 , such as an IP address, telephone number, device name, etc., to transmit the status data directly to the receiving device  205 . In some embodiments, the information identifying the receiving device  205  can be stored in the broadcasting database  230  and the broadcasting module  225  can communicate with the broadcasting database  230  to retrieve the information identifying the receiving device  205 . 
     In some embodiments, the broadcasting module  225  can transmit the status data to the receiving device indirectly. For example, the broadcasting module  225  can transmit the status data to a status server  220  in network communication with the broadcasting device  215  and the receiving device  205  and the status server  220  can transmit the status data to the receiving device  205 . For example, the status server  220  can include a status database  250  that can store a device profile for a plurality of broadcasting devices. The device profile can include data identifying all receiving devices authorized to receive status data from the broadcasting device  215 . The status server can also include a status module  245  that can communicate with the status database  250  to retrieve the data identifying the receiving device  205  and transmit the status data to the receiving device  205 . 
     The broadcasting module  225  can schedule the transmission of status data in numerous ways. For example, in some embodiments, the status data can be transmitted based on a predetermined schedule. For example, the broadcasting module  225  can transmit status data every ten minutes. In some embodiments, the broadcasting module  225  can transmit status data upon a determination that the status of the broadcasting device  215  has changed. For example, upon the broadcasting module  225  determining that the internet connection of the broadcasting device  215  has changed, the broadcasting module  225  can broadcast status data indicating the change in status. 
     The broadcasting module  225  can transmit different amounts of status data per transmission. For example, in some embodiments, the broadcasting module  225  can transmit all the gathered status data every time status data is transmitted. In some embodiments, the broadcasting module  225  can transmit only a portion of the status data. For example, upon a determination that the internet connection of the broadcasting device  215  has changed, the broadcasting module  225  can transmit status data indicating only the internet connection of the broadcasting device  215 . 
     In some embodiments, the broadcasting module  225  can vary the amount of status data transmitted based upon the situation. For example, the broadcasting module  225  can transmit all gathered status data based upon a set schedule such as every hour and transmit only a portion of the status data upon a determination that the particular status has changed. 
     In some embodiments, the broadcasting module  225  can broadcast status data based on the type of status data. For example, certain status data can be identified to be more important than other types of status data and thus the more important status data can be transmitted more frequently than status data considered to be less important. Alternatively, status data identified to be more important can be transmitted upon a determination that the status has changed whereas less important status data can be transmitted based on the set schedule. 
     In some embodiments, the broadcasting module  225  can vary the transmission of the status data based upon the receiving device  205 . For example, the frequency at which status data is sent, and the types of status data that is sent can be variable based upon the receiving device  205 . Thus the broadcasting device  215  can send different status data to different receiving devices  205  and send status data at different frequencies to different receiving devices  205 . 
     In some embodiments, the broadcasting module  225  can vary the transmission of status data based upon status data received from the receiving device  205 . For example, the broadcasting module  225  can limit the amount and frequency of status data that is transmitted to a receiving device  205  if, based on status data received from the receiving device  205 , it is determined that the receiving device  205  is currently using a high amount of bandwidth. Alternatively, the amount and frequency of status data that is transmitted to a receiving device  205  can be limited if it is determined that the device is inactive or has not been accessed for a long period of time. 
     In some embodiments, wherein the broadcasting module  225  transmits status data to the receiving device  205  indirectly via the status server  220 , the status module  245  can manage the status data that is transmitted to the receiving device  205 , including the functionality described above. 
     The receiving device  205  can receive status data transmitted by the broadcasting device  205 . The receiving device  205  can include a receiving module  235  to receive the status data. For example, the receiving module can be implemented as part of the operating system and await transmitted status data. In some embodiments, the receiving device  205  can include a receiving database  240  to store status data and the receiving module  235  can store the received status data in the receiving database  240 . 
     The receiving module  235  can cause the display of the received status data in a central interface, thus enabling a user of the receiving device  205  to easily view the status of all devices from which status data was received. The receiving device  205  can present the status data in any number of ways known in the art. For example, the status data can be presented as text, icons, etc., or use a variation of different colors or images to represent the data. Further, the status data can be grouped or categorized in any number of ways. 
     In some embodiments, the receiving module  235  can present all of the received status data. In some embodiments, the receiving module  235  can present only a portion of the status data. For example, the receiving module  235  can determine which status data to display based on a predetermined priority list, user entered preferences, predetermined rules, etc. 
       FIG. 3  illustrates a screen shot of an exemplary central interface  300 . As illustrated, the status data is separated into 5 categories: devices  305 , users  310 , places  315 , vehicles  320  and appliances  325 , each of which displays different types of status data. For example, the devices  305  category displays whether the device is powered on, the current battery power, whether the device is locked, the location of the device, the current internet connection type of the device and the current status of the device, whereas the places  315  category displays whether the location is locked, the current temperature and the status of the alarm. 
     Further, the central interface  300  can group status data from multiple devices and present it in relation to one entry. For example, the users  310  section categorizes users by name and displays status data received from multiple devices regarding the user. As illustrated, status data received from a smart phone indicating whether the user is available to receive a call, video chat, or text message is displayed as well as data received from a personal health monitoring device. Further, status data received from a pharmacy server indicates that user Chris has a prescription that is ready for pickup  330 . Grouping status data in this manner allows a user to quickly and easily determine the status of each user. 
     The central interface  300  offers a user a quick and easy way to monitor the status of multiple devices and other users to make informed decisions. For example, a user can easily determine that user Bob is not available to receive video chat and thus can make an informed decision to select between calling Bob and messaging Bob rather than wasting time trying to engage a video chat. 
     Returning to  FIG. 2 , in addition to presenting status data so that a user can make an informed decision, the receiving module  235  can also select a performance option based upon the received status data. For example, rather than a user having to view the central interface to determine that Bob is unavailable to receive a video chat, the receiving module  235  can select to disable the functionality enabling the user to initiate a video chat with Bob while the status data indicates that Bob is unavailable to receive a video chat. 
     The received status data can be used to select performance options in a variety of situations. In some embodiments, status data received from a broadcasting device  215  can be used to select a performance option regarding future communications with the broadcasting device  215 . For example, status data indicating the bandwidth usage of the broadcasting device  215  can be used to select which format of a media item should be transmitted to the broadcasting device  215 . If the bandwidth usage of the broadcasting device  215  is high, the receiving device  205  can select to transmit a format of the media item better suited for low bandwidth to the broadcasting device  215 . Alternatively, if the status data received from the broadcasting device  215  indicates that the current bandwidth usage is low, a format suited for higher bandwidth can be transmitted. 
     As another example, status data indicating whether a broadcasting device  215  is active can be used to select a frequency at which the receiving device  205  will transmit data to the broadcasting device  215 . If the broadcasting device  215  is not active, the receiving device  205  can select to transmit data to the broadcasting device  215  less frequently, however, if the status data indicates that the broadcasting device  215  is active, the data can be sent more frequently. 
     In some embodiments, the status data can be used to select whether to make an application or certain functionality available on the receiving device  205 . For example, status data received from a game server responsible for a multiplayer game can be used to select whether to make the game available to be executed on the receiving device  205 . If the status data indicates that there are no available players, the receiving device  205  can select to not make the game available. 
     As another example, status data indicating the bandwidth connection of a broadcasting device  215  can be used to select whether to enable a video chat function that requires a high speed connection. If the status data indicates that the broadcasting device  215  has a slow connection speed, the video chat function to the broadcasting device  215  can be disabled. 
     In some embodiments, status data gathered from a sensor of the broadcasting device  215  can be used to select a performance option on the receiving device  205 . For example, the receiving device  205  can use status data indicating the current input of a light sensor on the broadcasting device  215  to select the brightness level of a display on the receiving device  205 . 
     In some embodiments, the status data received from a broadcasting device  215  can be used to select advertisements displayed on the receiving device  205 . For example, if the status data indicates that the user&#39;s automobile requires an oil change, an advertisement including a coupon for an oil change can be selected to be presented on the receiving device  205 . 
     As explained above, the broadcasting  225  and receiving  235  modules can be implemented as part of the operating system running on a computing device. This implementation offers several advantages. One advantage is that the operating system has access to all hardware and software on a computing device and thus gathering status data and using received status data to select performance options can be easily performed from the operating system level. A second advantage is that the operating system is always running on the device and thus the user does not need to initiate an application. A third advantage is that the status data is protected by the operating system and is not shared with third party applications. A fourth advantage is that the functionality can be easily implemented on multiple computing devices. For example, an appliance maker can easily implement this functionality into an oven by installing a form of the operating system on a computing device included in the oven. The oven would thus be immediately capable of gathering status data and sharing it with all other computing devices running a form of the same operating system. 
       FIG. 4  illustrates an exemplary method embodiment of using status data to select performance options. As illustrated, the method begins with status data being received at a receiving device  405 . As explained above, status data can be any type of data known or discoverable by a computing device. For example, status data can include data describing the computing device, such as device name, device type, hardware capabilities, etc. Status data can include data regarding the current state of the device such as current network connection, current resource usage, applications running on the device, etc. Status data can also include data discoverable by the computing device such as data received by sensors included on the computing device or data received from other computing devices in communication with the computing device. 
     Further, status data can be received from any number and type of computing devices capable of network connection with the receiving device. For example, status data can be received from a desktop PC, tablet, automobile, home appliances, personal body monitors, business servers, etc. 
     Once the status data is received by the receiving device, at block  410 , the method displays the received status data in a central interface. The central interface allows a user to quickly and easily view the status data received from multiple devices in one place. The central interface can display the status data in any number of ways. For example, the status data can be displayed using text, symbols, colors, etc. Further, the status data can be grouped or categorized in any number of ways. 
     In some embodiments, the central interface can select which status data to display. For example, to keep the central interface easy to read, limited status data can be displayed. Status data can be selected in any number of ways, such as based on a predetermined priority or user selected preferences. Further, status data can be selected based on the specific device or type of device from which it was received, some devices being prioritized higher than others. 
     In some embodiments, status data can be selected based on how recent the status data was received or how critical the status data is determined to be. For example, status data indicating that an oven is on may not generally be considered of high importance, however this data becomes critical if the oven has been on for an overly extended period of time. 
     In some embodiments, status data from multiple computing devices can be used to ascertain what status data to display. For example, status data indicating that the oven is on and status data indicating that the alarm system is engaged can be used to determine that the oven is on and nobody is home. This can increase the priority of the status data indicating that the oven is on and thus it can be displayed in the central interface. 
     The displayed status data allows a user to make informed decisions, however the method can also automatically select a performance option based upon the received status data. For example, at block  415  the method can select a performance options based on the received status data. A performance option can be any variation regarding the performance of the receiving device, for example what applications to enable, what format of data to transfer, etc. 
     For example, the receiving device can automatically disable functionality that, based on the status data, will not succeed. For example, if the status data indicates that a user is not currently available to receive a video chat, functionality to initiate a video chat with that user can be disabled. 
     As another example, a mapping program running on a cellular phone can use status data received from the user&#39;s car that indicates that the user is nearly out of gas to select a route that takes a user by a gas station. In addition to selecting the altered route, in some embodiments, the mapping program can notify the user that the selected route was chosen because the user&#39;s car is low on gas. 
     The status data can also be used to infer the status of the user. Using the same example, status data received from a user&#39;s cellular phone and car can indicate that the two are at the same location and thus it can be inferred that, when the user initiates the mapping program, that the user will be traveling by using the car. 
     The above examples are only a few possibilities and are not meant to be limiting. Gathering status data from multiple computing devices and displaying the status data in one interface allows a user and the computing device to make numerous highly informed decisions. One skilled in the art would recognize that an endless number of possible embodiments can be implemented with use of the disclosed system. 
     As described above, one aspect of the present technology is the gathering and use of data available from various sources to improve the delivery of advertisements or any other content that may be of interest to users. The present disclosure contemplates that, in some instances, this gathered data may include personal information data that uniquely identifies or can be used to contact or locate a specific person. Such personal information data can include demographic data, location-based data, telephone numbers, email addresses, Twitter ID&#39;s, home addresses, or any other identifying information. 
     The present disclosure recognizes that the use of such personal information data in the present technology can be used to the benefit of users. For example, the personal information data can be used to better understand user behavior, facilitate and measure the effectiveness of advertisements, applications, and delivered content. Accordingly, use of such personal information data enables calculated control of the delivered content. For example, the system can reduce the number of times a user receives a given ad or other content and can thereby select and deliver content that is more meaningful to users. Such changes in system behavior improve the user experience. Further, other uses for personal information data that benefit the user are also contemplated by the present disclosure. 
     The present disclosure further contemplates that the entities responsible for the collection, analysis, disclosure, transfer, storage, or other use of such personal information data should implement and consistently use privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining personal information data private and secure. For example, personal information from users should be collected for legitimate and reasonable uses of the entity and not shared or sold outside of those legitimate uses. Further, such collection should occur only after the informed consent of the users. Additionally, such entities would take any needed steps for safeguarding and securing access to such personal information data and ensuring that others with access to the personal information data adhere to their privacy and security policies and procedures. Further, such entities can subject themselves to evaluation by third parties to certify their adherence to widely accepted privacy policies and practices. 
     Despite the foregoing, the present disclosure also contemplates embodiments in which users selectively block the use of, or access to, personal information data. That is, the present disclosure contemplates that hardware and/or software elements can be provided to prevent or block access to such personal information data. For example, in the case of advertisement delivery services, the present technology can be configured to allow users to select to “opt in” or “opt out” of participation in the collection of personal information data during registration for services. In another example, users can select not to provide location information for advertisement delivery services. In yet another example, users can configure their devices or user terminals to prevent storage or use of cookies and other mechanisms from which personal information data can be discerned. The present disclosure also contemplates that other methods or technologies may exist for blocking access to their personal information data. 
     Therefore, although the present disclosure broadly covers use of personal information data to implement one or more various disclosed embodiments, the present disclosure also contemplates that the various embodiments can also be implemented without the need for accessing such personal information data. That is, the various embodiments of the present technology are not rendered inoperable due to the lack of all or a portion of such personal information data. For example, content can be selected and delivered to users by inferring preferences based on non-personal information data or a bare minimum amount of personal information, such as the content being requested by the device associated with a user, other non-personal information available to the content delivery services, or publically available information. 
     Embodiments within the scope of the present disclosure may also include tangible and/or non-transitory computer-readable storage media for carrying or having computer-executable instructions or data structures stored thereon. Such non-transitory computer-readable storage media can be any available media that can be accessed by a general purpose or special purpose computer, including the functional design of any special purpose processor as discussed above. By way of example, and not limitation, such non-transitory computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions, data structures, or processor chip design. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or combination thereof) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of the computer-readable media. 
     Computer-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Computer-executable instructions also include program modules that are executed by computers in stand-alone or network environments. Generally, program modules include routines, programs, components, data structures, objects, and the functions inherent in the design of special-purpose processors, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps. 
     Those of skill in the art will appreciate that other embodiments of the disclosure may be practiced in network computing environments with many types of computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Embodiments may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination thereof) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. 
     The various embodiments described above are provided by way of illustration only and should not be construed to limit the scope of the disclosure. Those skilled in the art will readily recognize various modifications and changes that may be made to the principles described herein without following the example embodiments and applications illustrated and described herein, and without departing from the spirit and scope of the disclosure.

Metadata:
Filing Date: 20120628
Publication Date: 20150922
Grant Date: 20150922
Priority Date: 20120628
Inventors: GREENZEIGER MICHAEL FROIMOWITZ
SANGHAVI MEHUL K.
Assignee: APPLE INC
CPC Classifications: [{"code": "G06F11/3006", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F11/328", "inventive": true, "first": true, "tree": "[]"}, {"code": "G06F3/14", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F11/3055", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F11/328", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F11/3055", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F11/3006", "inventive": true, "first": true, "tree": "[]"}]
Family ID: 49779605