Title of Invention	A METHOD FOR PROVIDING SECURE ACCESS TO EMBEDDED DEVICE
Abstract	Abstract SYSTEMS AND METHODS FOR PROVIDING SECURE ACCESS TO EMBEDDED DEVICES USING A TRUST MANAGER AND A SECURITY BROKER A trust manager receives client account information from a client, nines whether the client account information is valid, and determines er the client is authorized to access one or more embedded devices that are ctronic communication with a security broker. The trust manager also security broker account information from the security broker, determines ler the security broker account information is valid, and determines whether security broker is authorized to provide access to the embedded device(s). If lent account information from the client is valid and the client is authorized less the embedded device(s), and if the security broker account information the security broker is valid and the security broker is authorized to provide s to the embedded device(s), the trust manager establishes a secure trusted ;ction between the client and the security broker.

Title of Invention

A METHOD FOR PROVIDING SECURE ACCESS TO EMBEDDED DEVICE

Abstract

Abstract SYSTEMS AND METHODS FOR PROVIDING SECURE ACCESS TO EMBEDDED DEVICES USING A TRUST MANAGER AND A SECURITY BROKER A trust manager receives client account information from a client, nines whether the client account information is valid, and determines er the client is authorized to access one or more embedded devices that are ctronic communication with a security broker. The trust manager also security broker account information from the security broker, determines ler the security broker account information is valid, and determines whether security broker is authorized to provide access to the embedded device(s). If lent account information from the client is valid and the client is authorized less the embedded device(s), and if the security broker account information the security broker is valid and the security broker is authorized to provide s to the embedded device(s), the trust manager establishes a secure trusted ;ction between the client and the security broker.

Full Text	DESCRIPTION SYSTEMS AND METHODS FOR PROVIDING SECURE ACCESS TO EMBEDDED DEVICES USING ATRUST MANAGER AND A SECURTTY BROKER TECHNICAL FIELD The present invention relates generally to computers and computer-related technology. More specifically, the present invention relates to providing secure access to embedded devices tising a trust manager and a security broker. BACKGROUND ART Computer and communication technologies continue to advance at a rapid pace. Indeed, computer and commutucation technologies are involved in many aspects of a person's day. For example, many devices being used today by consumers have a small computer inside of the device. These small computers come in varying sizes and degrees of sophistication. These small computers include everything firom one microcontroller to a fiilly-functional complete computer syston. For example, these small computers may be a one-chip computer, such as a microcontroller, a one-board type of computer, such as a controller, a typical desktop computer, such as an IBM-PC compatible, etc. Computers typically have one or more processors at the heart of the computer. The processor(s) usually are interconnected to different external inputs and outputs and function to manage, the particular computer or device. For example, a processor in a themostat may be connected to buttons used to select the temperature setting, to the furmace or air conditioner to change the temperature, and to temperature sensors to read and display the current temperature on a display. Many appliances, devices, etc., include one or more small computers. For example, thermostats, fiimaces, air conditioning systems, refiigerators, telephones, typewriters, automobiles, vending machines, and many differrait types of industrial equipment now typically have small computers, or processors, inside of them. Computo" software runs the processors of these computers and instructs the processors how to carry out certain tasks. For example, the computer software running on a thermostat may cause an air conditioner to stop running when a particular ten^>CTature is reached or may cause a heater to turn on when needed. These types of small computers that are a part of a device, appUance, tool, etc., are often referred to as embedded devices or embedded systems. (The terms "embedded device" and "eirfjedded system" will be used interchangeably herein.) An embedded system usually refers to computer hardware and software that is part of a larger system. Embedded systems may not have typical input and ou^ut devices such as a keyboard, mouse, and/or monitor. Usually, at the heart of each embedded system is one or more processor(s). A lighting system may incorporate an embedded system. The embedded system may be used to monitor and control the effects of the lighting system. For example, the embedded system may provide controls to dim the bri^tness of the li^ts within the lighting system. Alternatively, the embedded system may provide controls to increase the brightness of the lights. The embedded system may provide controls to initiate a specific lighting pattern among the individual lights within die lighting system. Embedded systems may be coupled to individual switches within the lighting system. These embedded systems may instruct the switches to power up or power down individual lights or the entire lighting system. Similarly, embedded systems may be coupled to individual lights within the lighting system. The brightness or power state of each individual light may be controlled by the embedded system. A security system may also incorporate an embedded system. The embedded system may be used to control the individual security sensors that ccMnprise the security system. For example, the embedded system may provide controls to power i^ each of ifae security sensors automatically. Embedded systems may be coupled to each of the individual security sensors. For example, an embedded system may be coupled to a moticHi sensor. The embedded system may power up tl^ individual motion sensor automatically and provide controls to activate the motion sensor if motion is detected. Activating a motion sensor may include providing instructions to power up an LED located within the motion sensor, ou^ut an alann fiom the output ports of the motion sensor, and the like. Embedded systems may also be coupled to sensors monitoring a door. The embedded system may provide instmctions to the sensor monitoring the door to activate when the door is opened or closed. Similarly, embedded systems may be coupled to sensors monitoring a window. The embedded system may provide instructions to activate the sensor monitoring the window if the window is opened or closed. Some embedded systems may also be used to control wireless products such as cell phones. The embedded system may provide instructions to power up the LED display of the cell phone. The embedded system may also activate the audio speakers within the cell phone to provide the user with an audio notification relating to die cell phone. Home appliances may also incorporate an anbedded system. Home appliances may include appliances typically used in a conventional kitchen, e.g., stove, refiigerator, microwave, etc. Home ^pliances may also include appliances that relate to the health and well-being of the user. For example, a massage recliner may incorporate an embedded system. The embedded system may provide instiiictions to automatically recline the back portion of the chair acconling to the j)references of the user. The embedded system may also provide instructions to initiate the oscillating components within the chair that cause vibrations within the recliner according to the preferences of the user. Additional products typically found in homes may also incoiporate embedded systems. For example, an embedded system may be used within a toilet to control the level of water used to refill the container tank. Embedded systems may be used within a jetted bathtub to control the outflow of air. As stated, embedded systems may be used to monitor or control many different systems, resources, products, etc. With the growth of the Internet and the World Wide Web, embedded systems are increasingly connected to the internet so that they can be remotely monitored and/or contixslled. Other embedded systems may be connected to computer networks including local area networks, wide area networks, etc. As used herein, the term "computer network" (or simply "network") refers to any system in which a series of nodes are interconnected by a communications path. The tenii "node" refers to any device that may be connected as part of a computer netwoik. Some embedded systems may provide data and/or services to other computing devices using a computer network. Altanatively, tha« may be typical computers or computing devices that provide data and/or services to otiier computing devices using a computer network. Sometimes it is beneficial to minimize the number of secrets required to maintain secure connections. Using large numbers of secrets can cause additional traffic over the network. These situations, as well as others, may cause ineflBciencies in communication across the network Benefits may be realized if systems and methods were available to provide secure access to embedded devices using a trast manager and a security broker. DISCLOSURE OF INVENTION Systems and methods for providing secure access to embedded devices using a trust manager and a security broker are disclosed. In an exemplary embodiment, a trust manager receives fiiom a client a request for access to at least one embedded device that is in electronic cdmmunication with a. security broker. The trust manager receives client account information fiom the client, determines whether the client account information is valid, and determines whether the client is authorized to access the embedded device(s). The trust manager also receives security broker account information from the security broker, determines whether the security broker account information is valid, and determines whether the security broker is authorized to provide access to the embedded device(s). If the client account information from the client is valid and the client is authorized to access the embedded device(s), and if the security broker account information from the security broker is valid and the security broker is authorized to provide access to the onbedded device(s), the trust manager establishes a secure trusted connection betwem the client and the security broker. The method just desaibed may be performed in response to a request from the client for access to the embedded device(s). Alternatively, the method may be performed in response to a request from ttie security broker. The cliait account infomiation may include security credentials for die client, and authorization information for die client The security credentials for the client may include a client identifier and a client secret The audiorization infoitnation for die client may include device access pentiissions, i.e., die device(s) diat the client is audiorized to access. Similariy, the security broker account information may include security credentials for die security broker, and authorization information for the security broker. The security credentials for the security broker may include a security broker identifier and a security broker secret The authorization information for the security broker may include device provide permissions, i.e., die device(s) for which the security broker is authorized to provide access. BRIEF DESCRIPTION OF THE DRAWINGS Exemplary embodiments of the invention will become more fully apparent from the following description and appended claims, taken in conjunction with the accompanying drawings. Understanding that these drawings dapict only exemplary embodiments and are, therefore, not to he considered limiting of the invaition's scope, the exemplary embodiments of the invention will be described with additional specificity and detail through use of the accompanying drawings in which: Figure 1 is a block diagram illustrating a system for providing secure access to embedded devices using a trust manager and a security broker according to an embodiment; Figure 2 is a block diagram illustrating a system for providing secure access to embedded devices using a trust manager and a security broker acconing to another embodiment; Figure 3 is a flow diagram that illustrates one embodiment of a method for providing secure access to embedded devices using a trust manager and a security broker; Figure 4 is a timing diagram UlustiBting a method for providing secure access to embedded devices using a trust manager and a security broker in a networic, where the method is initiated by a client; Figure S is a timing diagram illustrating a method for providing secure access to embedded devices using a tnist manager and a security broker in a networic, where the method is initiated by a security broker. Figure 6 is a block diagram of an embodiment of the components stored on a bust manager, Figure 7 is a block diagram of an embodiment of a client accounts database stored on atiiistinanager, Figure 8 is a block diagram of an embodiment of a security broker accounts database stored on a trust manager, Figure 9 is a block diagram of an embodiment of a client illustrating the information stored on the client; Figure 10 is a block diagram of an embodiment of a security broker illustrating the information stored on the security broker; Figure 11 is a flow diagram of an embodimait of a method for providing secure access to embedded devices xising a trust manager and a security broker in a networic, where the method is initiated by a chent; Figure 12 is a flow diagram of an embodiment of a method for providing secure access to embedded devices using a trust manager and a security broker in a network, where the method is initiated by a security broker, Figure 13 is a block diagram of hardware components that may be used in an embodiment of a computing device that may be accessed tiirough a security broker, Figure 14 illustrates an exemplary lighting system in which the present systems and methods may be implemented; Figure 15 illustrates an exemplary security system in which the jjresent systems and methods may be implemented; and Figure 16 illustrates an exemplary home controller system in which the present systems and methods may be implemented. BEST MODE FOR CARRYING OUT THE INVENTION Various embodiments of the invention are now described with reference to the Figures, where like reference numbers indicate identical or flinctionally similar elements. The embodiments of the presait invention, as generally described and illustrated in the Figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of several racemplary embodiments of the present invention, as represaited in the Figures, is not intended to limit the scope of the invention, as claimed, but is merely rq>resaitabve of the embodiments of the invention. The word "exemplary" is used exclusively herein to mean "serving as an example, instance, or illustration." Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments. While the various aspects of the embodiments are presented in drawings, the drawings are not necessarily drawn to scale uriless specifically indicated. Many features of the embodiments disclosed herein may be implemented as computer software, electronic hardware, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various components will be described generally in terms of their ftinctionality. Whether such ftinctionality is implemented as hardware or software dqjends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described ftinctionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a dqjarture from the scope of the present invention. Wha^ the described fimctionality is implemented as computer software, such software may include any type of computer instruction or computer executable code located within a memory device and/or transmitted as electronic signals over a system bus or network. Software that implements the ftinctionality associated with components described herein may comprise a single instruction, or many instructions, and may be distributed over several different code segments, among diflferent programs, and across several memory devices. Providing a secure network of devices and clients that want to interact securely is diflBcult to manage and may even not be possible with some devices. As the scale of the network grows, the management problem may likewise grow. For example, it is diflBcult to store and manage security credentials for potentially millions of devices. A security broker may be granted permissions that allow it to provide access to various devices. A trust manager may establish tmst between a client and a security broker A trust manager and security broker may be beneficial because a device may not be capable of providing security credentials, such as a device identification and secret The device may also be unable to cotnmtmicate witii the required security protocols. A tmst manager and security broker may also be boieficial in order to reduce the number of security credentials that may be installed, configured, and managed for (he network. A security broker may be connected to several devices. Using a security broker with a trust manager may eliminate the need to store the secrets for each device on the trust manager. Instead, the tnist manager would only need to store one secret fi)r each security broker. This may significantly reduce the number of secrets stored on the trust manager. In a typical network, a secure access point may have implied trust between raidpoints in the network. This implied tmst of a secure access point can open one of the endpoints to unrestricted access from the other endpoint. This unrestricted access is problematic from a security point of view. In contrast to implied trust of a secure access point, a security broker may use a trust manager that establishes the devices to which the security broker can provide secure access and place restrictions on the type of access allowed. For a clirait to access a device through flie security broker, the client may be required to have ^jecific, enumerated device permissions and the broker may be required to have specific, numerated device proxy permissions. In some embodiments, if a client is granted access, it can trust that the security broker can provide access to the device to which the cliait requested access. Figure I is a block diagram illustrating a system 100 for providing secure access to an embedded device 102 using a trust manager 108 and a security broker 110 according to an embodiment. A client 104 is in electronic communication with the tmst manager 108 and the security broker 110. Communication among the client 104, the tmst manager 108, and the security broker 110 may occur via one or more networics 106. A device 102 is also in electronic communication with the security broker 110. The device 102 may communicate with the security broker 110 over one or more networks (not shown). Of course alternate embodimaits may include more than a single client 104, security broker 110 or device 102. Figure 2 is a blodc diagram illustrating a system 200 for providing secure access to ' embedded devices 202 using a trust manager 208 and a security broko* 210 according to another embodiment Like the embodiment of Figure 1, the system 200 includes a trust manager 208. However, in the embodimrait depicted in Figure 2, the system 200 includes multiple clients 204, multiple security brokers 210 and multiple devices 202. In pjarticular, the system 200 includes client A 204a, client B 204b, and client C 204c. The system 200 also includes security broko" A 210a and security broker B 210b. The system 200 further includes device A 202a, device B 202b, device C 202c, device D 202d, device E 202e and device F 202f Communication among the clients 204, the security brokers 210, and the trust manager 208 may occur via one or more computer networks 206. The security brokers 210a, 210b also are in electronic communication with multiple devices 202. In particular, security broker A 210a is in electronic communication with device A 202a, device C 202c and device D 202d. Security broker B 210b is in electronic communication with device B 202b, device E 202e and device F 202f. Figure 3 is a flow diagram that illustrates one embodiment of a method 300 for providing secure access to embedded devices 102 using a trust manager 108 and a security broker 110. In accordance with the method 300, the cliait 104 may request 302 access to a desired device 102 from the trust manager 108. A client 104 may desire access to a device, for example, to obtain information stored on the device 102 or services provided by the device 102. In response to the request received from the client 104, the trust manager 108 may receive 304 the client's account information. Account information may include security credentials and authorization informatioiL Security credentials may be used to determine whether the client 104 is who it represents it is. The security credentials may include a client ID and a client secret The clioit's 104 authorization information may identify specific permissions that it wishes to exercise on the device 102. The trust manager 108 may determine 306 the validity of the client's account information. Determining 306 the validity of the client's account information may involve authenticating the client 104. For example, the tinst manager 108 may compare security credentials provided by the client 104 with validated security cralentials for the client 104. The validated security credentials may be stored on the trust manager 108. Of course, other methods may be utilized for authenticating the client 104. Determining 306 the validity of the client's account information may also involve verifying that the client 104 is authorized to access the desired device 102. TTiis may involve evaluating the pemiissions included in the authorization information against those stored in the tinst manager 108 for the client 104. The trust manager 108 may request 308 the security brok^'s 110 account information. As Mdth the client's 104 account information, the security broker's 110 account information may include security credentials and authorization information. Security credentials may be used to determine whether the security broker 110 is who it represents it is. The security broker's 110 security credentials may include a security broker ID and a security broker secret. The security broker's 110 autiiorization information may include device pomissions, which may indicate the devices 102 for which the security broker 110 is authorized to provide access. The trust manager 108 may determine 310 the validity of the security broker's account information. Determining 310 the validity of the security broker's 110 account information may involve authenticating the security broker 110. For example, the trust manager 108 may compare security credentials provided by the security broker 110 with validated security credentials for the security broker 110. The validated security credentials may be stored on the tmst manager 108. Of course, other methods may be utilized for authenticating the security broker 110. Determining 310 the validity of the security broker's 110 account information may also involve evaluating the device peniiissions included in the authorization information against those stored in the trust manager 108 for the security broker 110 to verify that it is authorized to provide access to the desired device 102. This may involve evaluating device permissions for the security broker 110. If the trust manager 108 determines that the client's 104 account infonnation and the security broker's 110 account infonnation are valid, then the trust manager 108 may grant 312 the client 104 access to the requested device 102 via the security broker 110. The security broker 110 then provides 314 access to the requested device 102 to the client 104. In some embodimaits, the client 104 may relay for the security broker 110. In other words, the trust manager 108 may authenticate the security broker 110 based on infonnation that it receives through the client 104 for the security broker 110. If this occurs, it may not be necessary for the triist manager 108 to receive security credentials directly from the security broker HO itself Further, in other embodiments, the cUent 104 may provide its account information at the same time that it requests access to the device 102 to the trust manager 108. In yet fiatiier embodiments, dl of the required information (client infonnation and security broker infonnation) may be passed from the client 104 to the trust manager 108 at the same time. Figure 4 is a timing cfiagram 400 illustrating communication among a client 404, a trust manager 408, and a security broker 410 according to an embodiment The timing diagram 400 includes a time axis 401. At time tl, the client 404 requests 405 access to a device 102 from the trust manager 408. At time t2, the trust manager 408 receives 425 the client's 404 account information. As discussed above, the client's 404 account information may include security credentials (e.g., client ID, client secret) and authorization information (e.g., requested permissions). In response, the trust manager 408 detemiines the validity of the client's 404 account information. At time t3, the trust manager 408 receives 445 the security broker's 410 account infomiation. In response, the trust manager 408 determines the validity of the security broker's 410 account infonnation. If the tmst manager 408 is able to verify the client's 404 account information and the security broker's 410 account information, at time t4 the trust manager 408 provides 455 the client 404 access to the security broker 410. At time t5, the client 404 accesses 465 the device 102 through the security broker 410. As noted in conjunction with Figure 3, alternate embodiments allow the different flows of information noted in Figure 4 to be combined in diflFerent ways. Figure 5 is a timing diagram 500 illustrating communication among a client 504, a trust managCT 508, and a security broker 510 according to another embodiment. The timing diagram 500 includes a time axis 501. At time tl, a device 102 (not shown in Figure 5) requests 505 access to a client 504 fiom the trast manager 508. The device 102 makes this request via the security broker 510. In an alternate embodiment, the security broker 510 may request access to a client 504 without initiation fix)m a device 102. At time t2, flie trust manager 508 receives 525 the security broker's 510 account information. As discussed above, the security broker's 510 account iirfoimation may include security credentials and authorization information. The security credentials may include a security broker ED and a security broker secret The autiiorization inforaiation may include device pemoissions, which may be used by the tmst manager 508 to detemune whether the device 102 may be provided access to the client 504 through the security broker 510. The trust manager 508 determines the validity of the security broker's 510 account informatioa At time t3, the trust manager 508 receives 545 the client's 504 account information. ITie trust manager 508 detemiines the validity of the client's 504 account information. If the trust manager 508 is able to verify the cHent's 504 account information and the security broker's 510 account information, at time t4 the trust manager 508 provides 555 the security broko- 510 access to the client 504. At time t5, the security broker 510 accesses 565 the client 504, and the device 102 that initially requested 505 access is able to access the chent 504 via the security broker 510. Figure 6 is a block diagram of an embodiment of the components stored on a trust manager 608. The trust manager 608 may include a security broker accounts database 620 and a client accounts database 622. The security broker accounts database 620 may include security credentials and authorization information for one or more security brokers 110. The client accounts database 622 may include security credentials and authorization information for clients 104. The contents of the client accounts database 622 and the security broker accsounts database 620 will be discussed in greater detail below. These databases 620, 622 may be used by an authentication and authorization program 624 stored on the trust manager 608 to determine the validity of account information that is provided to the tmst manager 608. Of course the trust manager 608 may be implemented with the authentication and authorization program 624 on a separate node Sum the databases 620,622. Figure 7 is a block diagram of an embodiment of a client accounts database 722 stored on a trust manager 108. The client accounts database 722 may include client account information 730a, 730b. The client account information 730 may include cUent security credentials 732a, 732b and client authorization information 740a, 740b. The client security credentials 732a, 732b may include client ©s 734a, 734b and client secrets 736a, 736b. The client authorization information 740 may include allowed permissions 742, 744, 746,748, 750. The allowed pwnissions 742, 744,746, 748, 750 may indicate the devices 102 to which the chent 104 has been granted access, and are therefore labeled "access device permissions" in Figure 7. As discussed above, the client account information 730 may be used to determine whether the clirat 104 is who. it represents it is and whether it is authorized to access a device 102. Figure 8 is a block diagram of an embodiment of a security broker accounts database 820 stored on a tmst manager 108. The security broker account database 820 may include security broker account information 850a, 850b. The security broker account information 850a, 850b may include security broker security credentials 852a, 852b and security broker authorization information 860a, 860b. The security broker security credentials 852a, 852b may include security broker IDs 854a, 854b and security broker secrets 856a, 856b. The security broker authorization information 860a, 860b may include device permissions 862a, 862b, 862c, 862d, 862e. The device permissions 862 may indicate the devices 102 to which the security broker 110 is authorized to provide access to a client 104, and are therefore labeled "provide device permissions" in Figure 8. As discussed above, the security broker account information 850a, 850b may be used to determine whether the security broker 110 is who it represents it is and whether it is authorized to provide access to a device 102. Figure 9 is a block diagram of an embodiment of a client 904 illustrating the infomiation stored on flie client 904. The client 904 may include client security credentials 932 and client authorization information 940. The client security credentials 932 may include a client ID 934 and a client secret 936. Hie client ID 934 and client secret 936 may be provided by the manufactura* or may be provided by the clioit instaUer. Altanatively, the client ED 934 and cliait secret 936 may be chosen by a user after manufacture and installation. Alternatively still, the client ID 934 and client secret 936 may be provided by a user at the time the cliait initiates the request to the device 102. The client authorization information 940 may include access device permissions 942a, 942e. Figure 10 is a block diagram of an embodiment of a security broker 1010 illustrating the information stored on the security broker 1010. The security broker 1010 may include security broker security credentials 1052 and security broker authorization information 1060. The security broker security credentials 1052 may include a security broker ID 1034 and a security broker secret 1036. Like the client ID 934 and client secret 936, the security broker ID 1034 and security broko" secret 1036 may be provided by a manufecturer of the security broker 1010 or by an installer. Altematively, the security broker ID 1034 and security broker secret 1036 may be chosen by a user after manufacture and installation. The security broko-authorization information 1060 may include provide device pemiissions 1062a, 1062c, 1062d These pemiissions rqmesoit the ability of tiie security broker 1010 to represent &e respective devices identified in the permissions 1062a, 1062c and I062d Figure 11 is a flow diagram of an embodiment of a method 1100 for providing secure access to embedded devices 102 using a trust managa 108 and a security broker HO in a network 106 where the mediod is initiated by a client 104. In response to a request from a client 104 for access to a device 102, the trust manager 108 may authenticate 1105 the client 104. Authenticating 1105 the climt 104 may involve recdving the client's security credentials 932. For oiample, the trust manager 108 may receive the client ID 934 and client secret 936. Tlie trust manager 108 may compare the client's security credentials 932 with the client security credentials 732 stored in the trust manager's 108 client accounts database 622. The trust manager 108 may determine 1115 whether the client 104 was authenticated. A client 104 may be authenticated when its security credentials 932 correspond with the client security credentials 732 stored on the tmst manager 108. If the tmst manager 108 is not able to authenticate the client 104, then the trust manager 108 denies 1195 access to the desired device 102. However, if the trust manager 108 determines 1115 that the client 104 has been properly authaiticated, the trust manager 108 may determine 1125 to which device 102 the client 104 desires access. For example, if the client 904 of Figure 9 were the client attempting to access device A 202a of Figure 2, the trust manager 108 would deteraiine 1125 that the client 904 desired to access device A 202a. The trust manager 108 may determine 1135 whether the client 104 is authorized to access the draired device 102. The trust manager 108 may make this determination 1135 by receiving the client's authorization information 940. For example, the trast manager 108 may receive the client's access device pennissions 942. The trust OMnager 108 may compare the client's authorization information 940 with the client authorization infomiation 740 stored in the trust manager's client accounts database 622. If the client 104 is not authorized to access die desired device 102, thea the trust manager 108 denies 1195 the client 104 access to the desired device 102. However, if the client 104 is authorized to access the desired device 102, the trust manager 108 determines 1145 which (if any) security broker 110 may provide access to the desired device 102. The trust manager 108 may make this detemiination 1145 by querying the security broker accounts database 620 to determine 1145 which security broker 110 is authorized to provide access to the desired device 102. For example, if die client 904 requests access to device A 202a, the trust manager 108 would query its security broker accounts database 620 to find a security broker 110 that has a provide device Apermission 862a for device A 202a. As discussed above, the trust manager 108 may only be in electronic communication with one security broker 110. Where there is only one security broker 110, the trust manager 108 may simply detemiine 1155 whether the security broker 110 is authorized to provide the client 104 access to the desired device 102. If the trust manager 108 is not able to identiiy a security broker 110 tiiat is authorized to provide acx:ess to the desired device 102, then the trust manager 108 denies 1195 the client 104 access to the desired device 102. However, if the tmst manager 108 identifies a security broker 110 that has the appropriate provide device permission 862, then the trust manager 108 authaiticates 1165 that security broker 110. Authenticating 1165 the security broker 110 may include receiving the security broker's security credentials 1052. For example, the trust manager 108 may receive the security broker ED 1034 and security broker secret 1036. The trust manager 108 may compare the security broker's security credentials 1052 with the security broker security credentials 852 stored in the trust manager's security broko* accounts database 620. A security broke-110 may be authenticated when its security credentials 1052 correspond with the security broker security credentials 852 stored on the trust manager 108. If the trust manager 108 detamines 1175 that it is unable to authenticate the security broker 110, then the tmst manager 108 denies 1195 the client 104 access to the requested device 102. However, if the trust manager 108 determines 1175 that the security broker 110 has been successfully authenticated, then the trust manager 108 may establish 1185 a secure tnisted connection between the client 104 and the security broker 110. In an alternate embodiment, the client 104 may indicate the security broker 110 that should provide the access to the device 102. In this case the detemiination 1145 is already specified, but the validity of the specification may still be verified by checking the security broker security credentials 852 in the broker accounts database 620. Figure 12 is a flow diagram of an embodiment of a method 1200 for providing secure access to embedded devices 102 using a trust manager 108 and a security broker 110 in a network 106 where the method 1200 is initiated by a security broker 110. This method 1200 may be used ■v/hen a security broker 110 wants to access a client 104 on behalf of a device 102. A secxirity broker 110 may request access to a client 104 fit>m the tmst manager 108. In response, the tmst manager 108 may authenticate 1205 the security broker 110. The trust manager 108 may detemiine 1215 whether the security broker 110 was authenticated. As with the embodiment of Figure 11, a security broker 110 may be audienticated when its security credentials 1052 correspond with the security broker security credentials 852 stored on the trust manager 108. If the trust manager 108 determines 1215 that it is not able to authenticate the security broker 110, then the trust manager 108 daiies 1285 the security broker 110 access to the client 104. However, if the trust manager 108 deteraiines 1215 that the security broker 110 has been properly authenticated, the trust manager 108 may determine 1225 to which client 104 the security broker 110 desires access. For example, if security broker B 210b of Figure 2 were attempting to access client B 204b of Figure 2, the trust manager 108 would determine that security broker B 21 Ob desired access to client B 204b. The trust manager 108 may determine 1235 whether the security broker 110 is authorized to proxy for a device 102 to the desired client 104. The trust manager 108 may make this determination 1235 by receiving the security broker's 110 authorization information 1060. For example, the trust manager 108 may receive the security broker's provide device permissions 1062. The tnist manager 108 may compare the security broker's authorization information 1060 with the security broker iaulhorization information 860 stored in the trust manager's security broker accounts database 620. In the present embodiment, the provide device permissions 1062 may be used to determine 1235 whether the security broker 110 is authorized to proxy for a device 102 to a client 104. For example, if in the embodiment of Figure 2 security broker B 210b desires to proxy for device B 202b to client B 204b, the trust manager 208 would determine whether security broker B 210b, to which device B 202b is connected, is authorized to allow access to client B 204b. The trust manager 208 would query its security broker accounts database 620 to deterriiine whether security broko- B's account information 850b included a provide device B pemiission 862b. If the trust manager 208 deteraiines that security broker B 210b does contain a provide device 6 permission 862b, then the security broker B 210b may be authorized to allow client B 204b to access device B 202b and to allow device B 202b to access client B 204b. In an alternative embodiment, the security broker 110 may have a separate set of pemnissions that allow it to proxy for a device 102 to a client 104. This separate set of permissions may be stored on the tmst manager 108 with its corresponding security broker authorization information 860 in the security broker accounts database 620. If the trust manager 108 detennines 1235 that the security broker 110 is not authorized to provide access to the client 104, then the trust manager 108 denies 1285 the security broker 110 access to the client 104. However, if the tmst manager 108 determines 1235 that the security broker 110 is authorized to provide access to the client 104, then the trust manager 108 may attempt to authenticate 1245 the client 104 and may determine 1255 whether the client 104 was authenticated. If the trust manager 108 determines 1255 that the client 104 was not successMly authenticated, then the trust manager 108 denies 1285 the security broker 110 access to the client 104. However, if the trust manager 108 determines 1255 that the client 104 was successfully authenticated, then the trust manager 108 may also determine 1265 whether the chent 104 is authorized to allow the security broker 110 access to the cliait 104. This may involve receiving the client's authorization information 940 and comparing it to the client authorization infonnation 740 stored in the client accounts database 622 on the trust manager 108. As discussed above, the client authorization infonnation 740 may include access device permissions 742. The access device permissions 742 may be used to determine 1265 whether the chent 104 is authorized to access a device 102 through the security broko' 110. For example, if security broker B 21 Ob desires to proxy for device B 202b to client B 204b, the trust manager 208 would determine whether climt B 204b is authorized to access device B 202b. The trust manager 208 woxdd query its client accounts database 622 to determine whether chent B's account information 730b included an access device B permission 742b. If the trust manager 208 d^ecmines that client B 204b does contain an access device B permission 742b, ihen a secure connection may be established 1275 between security broko- B 210b and client B 204b. In an sdtemative embodiment, the client 104 may have a separate set of pennissions for allowing a security broker 110 to proxy for a device 102 to the client 104. This sqjarate set of permissions may be stored on die trust manager 108 with its corresponding cUent authorization information 740 in the client accounts database 622. If the tmst manager 108 determines 1265 that tiie security broker 110 is not authorized to proxy for the device 102 to the client 104, then the trust manager 108 denies 1285 the security broker 110 access to the client 104. However, if the tmst manager 108 determines 1265 that the security broker 110 is authorized to proxy for the device 102 to the client 104, tfien the trust manager 108 may establish 1275 a secure trusted connection between the client 104 and the security broker 110. Figure 13 is a block diagram of hardware components that may be used in an embodiment of a computing device or an embedded device. A computing device and/or an embedded device may be used as a client 104, security broker 110, trust manager 108, or device 102. A CPU 1310 or processor may be provided to control the operation of the device 1302, including the other components thereof, which are coupled to the CPU 1310 via a bus 1312. The CPU 1310 may be embodied as a microprocessor, microcontroller, digital signal processor or other device known in the art. The CPU 1310 performs logical and arithmetic operations based on program code stored within the memory 1314. In certain embodiments, the memory 1314 may be on-board monory included with the CPU 1310. For example, microcontrollers often include a certain amount of on-board memory. The computing or anbedded device 1302 may also include a network interface 1316. The network interface 1316 facilitates communication between the device 1302 and other devices connected to the network 100. The network 100 may be a pager network, a cellular network, a global communications network, the Internet, a compute network, a telqjhone network, etc. The network interface 1316 operates according to standard protocols for the applicable network 106. The device 1302 may also include memory 1314. The memory 1314 may include a random access memory (RAM) for storing temporary data. Alternatively, or in addition, the memory 1314 may include a read-only memory (ROM) for storing more permanent data, such as fixed code and ccnifiguration data. The memory 1314 may also be embodied as a magnetic storage device, such as a hard disk drive. The memory 1314 may be any typ)e of electronic device capable of storing electronic information. The device 1302 may also include communication ports 1318, which facilitate communication with other devices. The device 1302 may also include input/ouiput devices 1320, such as a keyboard, a mouse, a joystick, a touchscreen, a monitor, speakers, a printer, etc. The present systems and methods may be used in several contexts. Figure 14 illustrates one embodiment of a system wherein the present systems and methods may be implemented. Figure 14 is a block diagram that illustrates one embodiment, of a lifting system 1400 that includes a lighting controller system 1408. The lighting system 1400 of Figure 14 may be incorporated in various rooms in a home. As illustrated, the system 1400 includes a room A 1402, a room B 1404, and a room C 1406. Although three rooms are shown in Figure 14, the system 1400 may be implemented in any number and variety of rooms within a home, dwelling, or other sivironment The lighting controllo- system 1408 may monitor and control additional embedded systems and components within the system 1400. In one embodiment, the room A1402 and the room B 1404 each include a switch componoit 1414,1418. The switch components 1414,1418 may also include a secondary embedded system 1416,1420. The secondary embedded systems 1416, 1420 may receive instructions from the lifting controller system 1408. The secondary embedded systems 1416, 1420 may then execute these instmctions. The instructions may include powering on or powering off various light components 1410, 1412, 1422, 1424. The instmctions may also include dimming the brightness or increasing the brightness of the various light components 1410, 1412, 1422, 1424. The instmctions may further include arranging the brightness of the light components 1410,1412, 1422, 1424 in various patterns. The secondary embedded systems 1416, 1420 fecilitate the lighting controller system 1408 to monitor and control each light componait 1410,1412,1422,1424 located in the room A 1402 and the room B1404. The lighting controller system 1408 mi^t also provide instmctions directly to a light component 1426 that includes a secondary embedded system 1428 in die depicted room C 1406. The lighting controller system 1408 may instruct the secondary embedded system 1428 to power down or power up the individual light component 1426. Similariy, the instructions received from the lighting controller system 1408 may include dimming the brightness or increasing the brightness of the individual light component 1426. The lighting controller system 1408 may also monitor and provide instmctions directly to individual light components 1430 1432 within die system 1400. Tbese instructions may include similar instructions as described previously. In the embodiment of Figure 14, the lighting controller system 1408 may act as a client 104. The lighting controller system 1408 may desire access to one of the light components 1410, 1412, 1422, 1424, 1426, 1430, 1432, which maybe treated as devices 102. Secondary embedded systems 1416, 1420,1428 may act as both a security broker 110 and a device 102. The lighting controller system 1408 may request access to the secondary embedded systems 1416,1420,1428 from a trust manager 108. When the trust manager 108 grants a secure trusted connection between the secondary embedded systems 1416, 1420, 1428 and the lighting controller system 1408, these light components may provide data regarding their status, for example whether a light component is on or off or the current or past wattage passing through the light component. Figure 15 is an additional embodiment of a system whaein flie present systems and methods of the present invention may be implemented. Figure 15 is a block diagram illustrating a security system 1500. The security system 1500 in the depicted anbodiment is implemented in a room A 1502, a room B 1504, and a room C 1506. These rooms may be in the confines of a home or other enclosed aivironment The system 1500 may also be implemented in an open environment where the rooms A, B and C, 1502,1504,1506 respectively represait territories or boundaries. The system 1500 includes a security controller system 1508. The security controller system 1508 monitors and receives infomiation fiom the various con^KDnents within the system 1500. For example, a motion sensor 1514, 1518 may include a secondary embedded system 1516, 1520. The motion sensors 1514, 1518 may monitor an immediate space for motion and alert the security controller system 1508 when motion is detected via the secondary embedded system 1516, 1520. The security controller system 1508 may also provide inshuctions to (he various components within the isystem 1500. For example, the security controller system 1508 may provide insbuctions to the secondary embedded systems 1516,1520 to powier up or power down a window saisor 1510, 1522 and a door sensor 1512, 1524. In one embodiment, the secondary embedded systems 1516, 1520 notify the security controller system 1508 when the window sensors 1510,1522 detect movement of a window. Similariy, the secondary embedded systems 1516, 1520 notify the security controller system 1508 whoi the door sensors 1512, 1524 detect movement of a door. The secondary embedded systems 1516, 1520 may instruct the motion sensors 1514, 1518 to activate the LED (not shown) located within the motion sensors 1514,1518. The security controller system 1508 may also monitor and provide instmctions directly to individual components wifliin the system 1500. For example, the security controller system 1508 may monitor and provide instructions to power up or power down to a motion sensor 1530 or a window sensor 1532. The security controUer system 1508 may also instruct the motion sensor 1530 and the window sensor 1532 to activate the LED (not shown) or audio alert notifications within the sensors 1530,1532. Each individual component comprising the system 1500 may also include a secondary embedded system. For example. Figure 15 illustrates a door sensor 1526 including a secondary embedded system 1528. The security controller system 1508 may monitor and provide instructions to the secondary embedded system 1528 in a similar manner as previously described. In the embodiment of Figure 15, the security controller system 1508 may act as a client 104. The security controller system 1508 may desire access to one of the sensors 1510, 1512, 1522, 1524, 1526, 1530, 1532. which may be treated as devices 102. Secondary embedded systems 1516, 1520,1528 may act as both a security broker 110 and a device 102. The security controller system 1508 may request access to the secondary embedded systems 1516,1520,1528 fix)m a trust manager 108. When the trust manager 108 grants a secure trusted connection betweai the secondary embedded systems 1516, 1520, 1528 and the security controller system 1508, these sensors 1510,1512, 1522,1524, 1526, 1530, 1532 may provide data regarding their status. For example, the window sensors 1510, 1522, 1532 may provide data regarding whdher ihey are open or closed. Figure 16 is a block diagram iUustrating one embodiment of a home system 1600. The home system 1600 includes a home controller 1608 that fecilitates the monitoring of various systems such as ttie lifting system 1400, the security system 1500, and the like. The home system 1600 allows a user to control various components and systems throu^ one or more embedded systems. In one embodiment, the home controUer system 1608 monitors and provides information in the same manner as previously described in relation to Figures 14 and 15. In the depicted embodiment, the home controller 1608 provides instructions to a heating component 1624 via a secondary embedded system 1620. The heating component 1624 may include a fiimace or other heating device typically found in resident locations or oflSces. The home controller system 1608 may provide instructions to power up or power down the heating component 1624 via the secondary embedded system 1620. Similarly, the home controller 1608 may monitor and provide instructions directly to a component within the home system 1600 such as a cooling component 1630. The cooling component 1630 may include an air conditioner or other cooling device typically found in resident locations or offices. The central home controller 1608 may instruct the cooling component 1630 to power- up or power down depending on the temperature reading collected by the caitral embedded system 1608. The home system 1600 functions in a similar manner as previously described in relation to Figures 14 and 15. In the embodiment of Figure 16, the home controller system 1608 may act as a client 104. The home controller system 1608 may desire access to the window sensor 1610, door sensor 1612, heating component 1624, cooling component 1630, or lighting components 1622, 1626, 1632, all of which may be treated as devices 102. Secondary embedded systems 1616, 1620,1628 may act as both a security broker 110 and a device 102. The home controller system 1608 may request access to the secondary embedded systems 1616, 1620, 1628 from a tmst manager 108. When the trust manager 108 grants a secure tmsted connection between the secondary embedded systems 1616, 1620, 1628 and the home controller system 1608, these elements 1610,1612,1622,1624,1626,1630,1632 may provide data regarding their status. For example, the heating and cooling components 1624, 1630 may provide data regarding the present tempaature in their respective rooms 1604,1606. The heating and cooling components 1624, 1630 may provide data regarding the status of the component, whether it is on or off, its recent power usage, any system errors, etc. There are many types of anbedded devices and many reasons for creating device networks. Several examples of device networking applications will be set forth. It will be appreciated by those skilled in the art that the examples discussed are not exhaustive. One example of a device networking application is remote monitoring. Many useiul device networks involve remote monitoring, the one-way transfer of information fiom one node to another. In these ajqilications, providers typically act as small servers that report certain information in response to a requestor. Providers can also be set up to publish their state information to subscribers. A requestor may ask for periodic reports or for updates whenever the state changes, perhaps with some means of limiting how often updates are to be sent. Providers can be set up to notify requestors when some event or exceptional condition occurs. Another example of a device network application is remote control, where requestors are able to send commands to providers to invoke some specific action. In most cases, remote control involves some sort of feedback. A still further example of a device networking application is distributed control systems. The functions and data associated with individual providers can be combined and coordinated through a network to create a distributed system that provides additional value. Sometimes these distributed control systems can be established more or less automatically. In many cases, a more sophisticated device joins a peer-to-peer network to perform configuration, monitoring or diagnostic duties. Such systems may be created by objects that communicate as peers or through a master-slave configuration, in which each object in the system communicates with a single, central node that contains all of the control logic. With each category of networking application, there are a variety of ways in which requestors may connect to providers. When a relatively small number of provides are involved, a requestor may use a web browser, pager or even a WAP-enabled cell phone to communicate with a provider in a more or less interactive manner. As the number of providers grows, however, these methods may become unworkable and requestors may employ more general data management techniques such as a spreadsheet or database application As a variety of networks are implemented over time and with different technologies, the situation can arise in which multiple networks might sit in the same home or facility, each using their own protocols and unable to communicate with the othrs. In this case, the various networks and protocols can be bridged to create a single, larger network. This can allow a single application to access each provider, simplifying the interaction with all of the providers. Information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instmctions, commands, information, signals, bits, symbols, and chips that may be represented throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and stqps have been described above generally in terms of their functionality. Whether such fiinctionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall systen. Skilled artisans may implement the described fimctionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure fiom the scope of the present invention. The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array signal (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete handware components, or any combination thereof designed to perform the functions described herein. A genoal purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art An exemplary storage medium is coapled to the processor such that the processor can read infomiation fixDm, and write infomiation to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and die storage medium may reside in an ASIC. The ASIC may reside in a user temiinal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal. Hie methods disclosed herein comprise one or more steps or actions for achieving the described method. The method steps and/or actions may be interchanged with one another without departing from the scope of the present invention. In other words, unless a specific order of steps or actions is required for proper operation of the embodiment, the order and/or use of specific steps and/or actions may be modified without departing fiom the scope of the present invention. While specific embodiments and applications of the present invention have been illustrated and described, it is to be understood that the invention is not limited to the precise configuration and components disclosed herein. Various modifications, changes, and variations which will be apparent to those skilled in the art may be made in the arrangemoit, operation, and details of the methods and systems of the present invention disclosed herein without departing fiiom the spirit and scope of the inventioa INDUSTRIAL APPLICABILITY The present invention is applicable to an embedded system. CLAIMS 1. A method for providing secure access to embedded devices, the method being implemented by a trust manager, the method comprising: receiving client account information from a client; determining whether the client account information from the client is valid; determining whether the client is authorized to access at least one embedded device that is in electronic communication with a security brokerr, receiving security broker account infomation from the security broker, detennining whether the security broker account information from the security broker is valid; determining whether the security broker is authorized to provide access to the at least one anbedded device; and if the client account infonnation from the client is valid and tihe client is authorized to access die at least one embedded device, and if the security broker account infonnation from the security broker is valid and the security broker is authorized to provide access to the at least one embedded device, establishing a secure trusted connection between the client and the security broker. 2. The method of claim 1, wherein the method is performed in response to receiving a request from the client for access to the at least one embedded device. 3. The method of claim 1, wherein tfie method is perfonmed in respwise to receiving a request from the security broker to provide access to the at least one embedded device. 4. The method of claim 1, wherein the client account information comprises: security credentials for the client; and authorization information for the client 5. The method of claim 4, wherein the security credentials for the client comprise a client identifier and a client secret. 6. The method of claim 4, wherein, the authorization information for the client comprises device access permissions. 7. The method of claim 1, wherein detennrning whether the client account information is valid comprises comparing the client account information that was received fiom the client with validated client account information. 8. The method of claim 7, wherein the validated client account information is stored on the trust manager. 9. The method of claim 1, what in the security broker account information comprises: security credentials for the security broker, and authorization information for the security broker. 10. The method of claim 9, wherein the security credentials comprise a security broker identifier and a security broker secret 11. The method of claim 9, wherein the authorization information for the security broker comprises device provide permissions. 12. The method of claim 1, wherein detennining whether the security broker account information is valid comprises comparing the security broker account information that was received fiom the security broker with validated security broker account information. 13. The method of claim 12, wherein the validated security broker account information is stored on the trust managa: 14. A trust manager that is configured to implement a method for providing secure access to embedded devices, the trust manager comprising: a processor, memory in electronic communication with the processor, instructions stored in the memory, the instmctions being executable to implement a method comprising: receiving client account information from a client; determining whether the client account information from the client is valid; determining whether the client is authorized to access at least one embedded device that is in electronic communication with a security broker, receiving security broker account information from the security broker, determining whether the security broker account information from the security broker is valid; determining whether the security broker is authorized to provide access to the at least one embedded device; and if the client account information from the client is valid and the client is authorized to access the at least one embedded device, and if the security broker account information from the security broker is valid and the security broker is authorized to provide access to the at least one embedded device, establishing a secure trusted connection between the client and the security broker. 15. "Die trust manager of claim 14, wherein the method is performed in response to receiving a request from the client for access to the at least one embedded device. 16. The trust manager of claim 14, wherein die method is performed in response to receiving a request from the security broker to provide access to the at least one embedded device. 17. The trust manager of claim 14, wherein the client account information comprises security credentials for the client and authorization information for the client, and wherein the security broker account information comprises security credentials for the security broker and authorization infomation for the security broker. 18. A computer-readable medium comprising executable instructions for implementing a method for providing secure access to embedded devices, the method being implemented by a trust manager, the method comprising: receiving client account information from a client; determining whether the client account information from the cliait is valid; detennining whether the client is authorized to access at least one embedded device that is in electronic communication with a security broker; receiving security broker account infomiation from the security broker, detennining whether the security broker account information from the security broker is valid; determining whethCT the security broker is autiiorized to provide access to the at least one embedded device; and if the dieat account infomiation ficnn the client is valid and the client is authorized to access the at least one embedded device, and if the security broker account information from the security broker is valid and the security broker is authorized to provide access to the at least one embedded device, establishing a secure trusted connection between the cli«it and the security broker. 19. The computer-readable medium of claim 18, wherein the method is performed in response to receiving a request from the client for access to the at least one embedded device. 20. The computer-readable medium of claim 18, wherein the method is performed in response to receiving a request from the security broker to provide access to the at least one embedded device.

Full Text

DESCRIPTION
SYSTEMS AND METHODS FOR PROVIDING SECURE ACCESS TO EMBEDDED DEVICES USING ATRUST MANAGER AND A SECURTTY BROKER
TECHNICAL FIELD
The present invention relates generally to computers and computer-related technology. More specifically, the present invention relates to providing secure access to embedded devices tising a trust manager and a security broker.
BACKGROUND ART
Computer and communication technologies continue to advance at a rapid pace. Indeed, computer and commutucation technologies are involved in many aspects of a person's day. For example, many devices being used today by consumers have a small computer inside of the device. These small computers come in varying sizes and degrees of sophistication. These small computers include everything firom one microcontroller to a fiilly-functional complete computer syston. For example, these small computers may be a one-chip computer, such as a microcontroller, a one-board type of computer, such as a controller, a typical desktop computer, such as an IBM-PC compatible, etc.
Computers typically have one or more processors at the heart of the computer. The processor(s) usually are interconnected to different external inputs and outputs and function to manage, the particular computer or device. For example, a processor in a themostat may be connected to buttons used to select the temperature setting, to the furmace or air conditioner to change the temperature, and to temperature sensors to read and display the current temperature on a display.
Many appliances, devices, etc., include one or more small computers. For example, thermostats, fiimaces, air conditioning systems, refiigerators, telephones, typewriters, automobiles, vending machines, and many differrait types of industrial equipment now typically have small computers, or processors, inside of them. Computo" software runs the processors of these computers and instructs the processors how to carry out certain tasks. For example, the

computer software running on a thermostat may cause an air conditioner to stop running when a particular ten^>CTature is reached or may cause a heater to turn on when needed.
These types of small computers that are a part of a device, appUance, tool, etc., are often referred to as embedded devices or embedded systems. (The terms "embedded device" and "eirfjedded system" will be used interchangeably herein.) An embedded system usually refers to computer hardware and software that is part of a larger system. Embedded systems may not have typical input and ou^ut devices such as a keyboard, mouse, and/or monitor. Usually, at the heart of each embedded system is one or more processor(s).
A lighting system may incorporate an embedded system. The embedded system may be used to monitor and control the effects of the lighting system. For example, the embedded system may provide controls to dim the bri^tness of the li^ts within the lighting system. Alternatively, the embedded system may provide controls to increase the brightness of the lights. The embedded system may provide controls to initiate a specific lighting pattern among the individual lights within die lighting system. Embedded systems may be coupled to individual switches within the lighting system. These embedded systems may instruct the switches to power up or power down individual lights or the entire lighting system. Similarly, embedded systems may be coupled to individual lights within the lighting system. The brightness or power state of each individual light may be controlled by the embedded system.
A security system may also incorporate an embedded system. The embedded system may be used to control the individual security sensors that ccMnprise the security system. For example, the embedded system may provide controls to power i^ each of ifae security sensors automatically. Embedded systems may be coupled to each of the individual security sensors. For example, an embedded system may be coupled to a moticHi sensor. The embedded system may power up tl^ individual motion sensor automatically and provide controls to activate the motion sensor if motion is detected. Activating a motion sensor may include providing instructions to power up an LED located within the motion sensor, ou^ut an alann fiom the output ports of the motion sensor, and the like. Embedded systems may also be coupled to sensors monitoring a door. The embedded system may provide instmctions to the sensor monitoring the door to activate when the door is opened or closed. Similarly, embedded systems may be coupled to sensors monitoring a window. The embedded system may provide

instructions to activate the sensor monitoring the window if the window is opened or closed.
Some embedded systems may also be used to control wireless products such as cell phones. The embedded system may provide instructions to power up the LED display of the cell phone. The embedded system may also activate the audio speakers within the cell phone to provide the user with an audio notification relating to die cell phone.
Home appliances may also incorporate an anbedded system. Home appliances may include appliances typically used in a conventional kitchen, e.g., stove, refiigerator, microwave, etc. Home ^pliances may also include appliances that relate to the health and well-being of the user. For example, a massage recliner may incorporate an embedded system. The embedded system may provide instiiictions to automatically recline the back portion of the chair acconling to the j)references of the user. The embedded system may also provide instructions to initiate the oscillating components within the chair that cause vibrations within the recliner according to the preferences of the user.
Additional products typically found in homes may also incoiporate embedded systems. For example, an embedded system may be used within a toilet to control the level of water used to refill the container tank. Embedded systems may be used within a jetted bathtub to control the outflow of air.
As stated, embedded systems may be used to monitor or control many different systems, resources, products, etc. With the growth of the Internet and the World Wide Web, embedded systems are increasingly connected to the internet so that they can be remotely monitored and/or contixslled. Other embedded systems may be connected to computer networks including local area networks, wide area networks, etc. As used herein, the term "computer network" (or simply "network") refers to any system in which a series of nodes are interconnected by a communications path. The tenii "node" refers to any device that may be connected as part of a computer netwoik.
Some embedded systems may provide data and/or services to other computing devices using a computer network. Altanatively, tha« may be typical computers or computing devices that provide data and/or services to otiier computing devices using a computer network. Sometimes it is beneficial to minimize the number of secrets required to maintain secure connections. Using large numbers of secrets can cause additional traffic over the network. These

situations, as well as others, may cause ineflBciencies in communication across the network Benefits may be realized if systems and methods were available to provide secure access to embedded devices using a trast manager and a security broker.
DISCLOSURE OF INVENTION
Systems and methods for providing secure access to embedded devices using a trust manager and a security broker are disclosed. In an exemplary embodiment, a trust manager receives fiiom a client a request for access to at least one embedded device that is in electronic cdmmunication with a. security broker. The trust manager receives client account information fiom the client, determines whether the client account information is valid, and determines whether the client is authorized to access the embedded device(s). The trust manager also receives security broker account information from the security broker, determines whether the security broker account information is valid, and determines whether the security broker is authorized to provide access to the embedded device(s). If the client account information from the client is valid and the client is authorized to access the embedded device(s), and if the security broker account information from the security broker is valid and the security broker is authorized to provide access to the onbedded device(s), the trust manager establishes a secure trusted connection betwem the client and the security broker.
The method just desaibed may be performed in response to a request from the client for access to the embedded device(s). Alternatively, the method may be performed in response to a request from ttie security broker.
The cliait account infomiation may include security credentials for die client, and authorization information for die client The security credentials for the client may include a client identifier and a client secret The audiorization infoitnation for die client may include device access pentiissions, i.e., die device(s) diat the client is audiorized to access.
Similariy, the security broker account information may include security credentials for die security broker, and authorization information for the security broker. The security credentials for the security broker may include a security broker identifier and a security broker secret The authorization information for the security broker may include device provide permissions, i.e., die device(s) for which the security broker is authorized to provide access.

BRIEF DESCRIPTION OF THE DRAWINGS
Exemplary embodiments of the invention will become more fully apparent from the following description and appended claims, taken in conjunction with the accompanying drawings. Understanding that these drawings dapict only exemplary embodiments and are, therefore, not to he considered limiting of the invaition's scope, the exemplary embodiments of the invention will be described with additional specificity and detail through use of the accompanying drawings in which:
Figure 1 is a block diagram illustrating a system for providing secure access to embedded devices using a trust manager and a security broker according to an embodiment;
Figure 2 is a block diagram illustrating a system for providing secure access to embedded devices using a trust manager and a security broker acconing to another embodiment;
Figure 3 is a flow diagram that illustrates one embodiment of a method for providing secure access to embedded devices using a trust manager and a security broker;
Figure 4 is a timing diagram UlustiBting a method for providing secure access to embedded devices using a trust manager and a security broker in a networic, where the method is initiated by a client;
Figure S is a timing diagram illustrating a method for providing secure access to embedded devices using a tnist manager and a security broker in a networic, where the method is initiated by a security broker.
Figure 6 is a block diagram of an embodiment of the components stored on a bust manager,
Figure 7 is a block diagram of an embodiment of a client accounts database stored on atiiistinanager,
Figure 8 is a block diagram of an embodiment of a security broker accounts database stored on a trust manager,
Figure 9 is a block diagram of an embodiment of a client illustrating the information stored on the client;
Figure 10 is a block diagram of an embodiment of a security broker illustrating the

information stored on the security broker;
Figure 11 is a flow diagram of an embodimait of a method for providing secure access to embedded devices xising a trust manager and a security broker in a networic, where the method is initiated by a chent;
Figure 12 is a flow diagram of an embodiment of a method for providing secure access to embedded devices using a trust manager and a security broker in a network, where the method is initiated by a security broker,
Figure 13 is a block diagram of hardware components that may be used in an embodiment of a computing device that may be accessed tiirough a security broker,
Figure 14 illustrates an exemplary lighting system in which the present systems and methods may be implemented;
Figure 15 illustrates an exemplary security system in which the jjresent systems and methods may be implemented; and
Figure 16 illustrates an exemplary home controller system in which the present systems and methods may be implemented.
BEST MODE FOR CARRYING OUT THE INVENTION
Various embodiments of the invention are now described with reference to the Figures, where like reference numbers indicate identical or flinctionally similar elements. The embodiments of the presait invention, as generally described and illustrated in the Figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of several racemplary embodiments of the present invention, as represaited in the Figures, is not intended to limit the scope of the invention, as claimed, but is merely rq>resaitabve of the embodiments of the invention.
The word "exemplary" is used exclusively herein to mean "serving as an example, instance, or illustration." Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments. While the various aspects of the embodiments are presented in drawings, the drawings are not necessarily drawn to scale uriless specifically indicated.
Many features of the embodiments disclosed herein may be implemented as computer

software, electronic hardware, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various components will be described generally in terms of their ftinctionality. Whether such ftinctionality is implemented as hardware or software dqjends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described ftinctionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a dqjarture from the scope of the present invention.
Wha^ the described fimctionality is implemented as computer software, such software may include any type of computer instruction or computer executable code located within a memory device and/or transmitted as electronic signals over a system bus or network. Software that implements the ftinctionality associated with components described herein may comprise a single instruction, or many instructions, and may be distributed over several different code segments, among diflferent programs, and across several memory devices.
Providing a secure network of devices and clients that want to interact securely is diflBcult to manage and may even not be possible with some devices. As the scale of the network grows, the management problem may likewise grow. For example, it is diflBcult to store and manage security credentials for potentially millions of devices.
A security broker may be granted permissions that allow it to provide access to various devices. A trust manager may establish tmst between a client and a security broker A trust manager and security broker may be beneficial because a device may not be capable of providing security credentials, such as a device identification and secret The device may also be unable to cotnmtmicate witii the required security protocols. A tmst manager and security broker may also be boieficial in order to reduce the number of security credentials that may be installed, configured, and managed for (he network. A security broker may be connected to several devices. Using a security broker with a trust manager may eliminate the need to store the secrets for each device on the trust manager. Instead, the tnist manager would only need to store one secret fi)r each security broker. This may significantly reduce the number of secrets stored on the trust manager.
In a typical network, a secure access point may have implied trust between raidpoints in the network. This implied tmst of a secure access point can open one of the endpoints to

unrestricted access from the other endpoint. This unrestricted access is problematic from a security point of view.
In contrast to implied trust of a secure access point, a security broker may use a trust manager that establishes the devices to which the security broker can provide secure access and place restrictions on the type of access allowed. For a clirait to access a device through flie security broker, the client may be required to have ^jecific, enumerated device permissions and the broker may be required to have specific, numerated device proxy permissions. In some embodiments, if a client is granted access, it can trust that the security broker can provide access to the device to which the cliait requested access.
Figure I is a block diagram illustrating a system 100 for providing secure access to an embedded device 102 using a trust manager 108 and a security broker 110 according to an embodiment. A client 104 is in electronic communication with the tmst manager 108 and the security broker 110. Communication among the client 104, the tmst manager 108, and the security broker 110 may occur via one or more networics 106.
A device 102 is also in electronic communication with the security broker 110. The device 102 may communicate with the security broker 110 over one or more networks (not shown). Of course alternate embodimaits may include more than a single client 104, security broker 110 or device 102.
Figure 2 is a blodc diagram illustrating a system 200 for providing secure access to ' embedded devices 202 using a trust manager 208 and a security broko* 210 according to another embodiment Like the embodiment of Figure 1, the system 200 includes a trust manager 208. However, in the embodimrait depicted in Figure 2, the system 200 includes multiple clients 204, multiple security brokers 210 and multiple devices 202. In pjarticular, the system 200 includes client A 204a, client B 204b, and client C 204c. The system 200 also includes security broko" A 210a and security broker B 210b. The system 200 further includes device A 202a, device B 202b, device C 202c, device D 202d, device E 202e and device F 202f Communication among the clients 204, the security brokers 210, and the trust manager 208 may occur via one or more computer networks 206. The security brokers 210a, 210b also are in electronic communication with multiple devices 202. In particular, security broker A 210a is in electronic communication with device A 202a, device C 202c and device D 202d. Security

broker B 210b is in electronic communication with device B 202b, device E 202e and device F 202f.
Figure 3 is a flow diagram that illustrates one embodiment of a method 300 for providing secure access to embedded devices 102 using a trust manager 108 and a security broker 110. In accordance with the method 300, the cliait 104 may request 302 access to a desired device 102 from the trust manager 108. A client 104 may desire access to a device, for example, to obtain information stored on the device 102 or services provided by the device 102.
In response to the request received from the client 104, the trust manager 108 may receive 304 the client's account information. Account information may include security credentials and authorization informatioiL Security credentials may be used to determine whether the client 104 is who it represents it is. The security credentials may include a client ID and a client secret The clioit's 104 authorization information may identify specific permissions that it wishes to exercise on the device 102.
The trust manager 108 may determine 306 the validity of the client's account information. Determining 306 the validity of the client's account information may involve authenticating the client 104. For example, the tinst manager 108 may compare security credentials provided by the client 104 with validated security cralentials for the client 104. The validated security credentials may be stored on the trust manager 108. Of course, other methods may be utilized for authenticating the client 104. Determining 306 the validity of the client's account information may also involve verifying that the client 104 is authorized to access the desired device 102. TTiis may involve evaluating the pemiissions included in the authorization information against those stored in the tinst manager 108 for the client 104.
The trust manager 108 may request 308 the security brok^'s 110 account information. As Mdth the client's 104 account information, the security broker's 110 account information may include security credentials and authorization information. Security credentials may be used to determine whether the security broker 110 is who it represents it is. The security broker's 110 security credentials may include a security broker ID and a security broker secret. The security broker's 110 autiiorization information may include device pomissions, which may indicate the devices 102 for which the security broker 110 is authorized to provide access. The trust manager 108 may determine 310 the validity of the security broker's account information. Determining

310 the validity of the security broker's 110 account information may involve authenticating the security broker 110. For example, the trust manager 108 may compare security credentials provided by the security broker 110 with validated security credentials for the security broker 110. The validated security credentials may be stored on the tmst manager 108. Of course, other methods may be utilized for authenticating the security broker 110. Determining 310 the validity of the security broker's 110 account information may also involve evaluating the device peniiissions included in the authorization information against those stored in the trust manager 108 for the security broker 110 to verify that it is authorized to provide access to the desired device 102. This may involve evaluating device permissions for the security broker 110.
If the trust manager 108 determines that the client's 104 account infonnation and the security broker's 110 account infonnation are valid, then the trust manager 108 may grant 312 the client 104 access to the requested device 102 via the security broker 110. The security broker 110 then provides 314 access to the requested device 102 to the client 104.
In some embodimaits, the client 104 may relay for the security broker 110. In other words, the trust manager 108 may authenticate the security broker 110 based on infonnation that it receives through the client 104 for the security broker 110. If this occurs, it may not be necessary for the triist manager 108 to receive security credentials directly from the security broker HO itself Further, in other embodiments, the cUent 104 may provide its account information at the same time that it requests access to the device 102 to the trust manager 108. In yet fiatiier embodiments, dl of the required information (client infonnation and security broker infonnation) may be passed from the client 104 to the trust manager 108 at the same time.
Figure 4 is a timing cfiagram 400 illustrating communication among a client 404, a trust manager 408, and a security broker 410 according to an embodiment The timing diagram 400 includes a time axis 401.
At time tl, the client 404 requests 405 access to a device 102 from the trust manager 408. At time t2, the trust manager 408 receives 425 the client's 404 account information. As discussed above, the client's 404 account information may include security credentials (e.g., client ID, client secret) and authorization information (e.g., requested permissions). In response, the trust manager 408 detemiines the validity of the client's 404 account information.

At time t3, the trust manager 408 receives 445 the security broker's 410 account infomiation. In response, the trust manager 408 determines the validity of the security broker's 410 account infonnation.
If the tmst manager 408 is able to verify the client's 404 account information and the security broker's 410 account information, at time t4 the trust manager 408 provides 455 the client 404 access to the security broker 410. At time t5, the client 404 accesses 465 the device 102 through the security broker 410. As noted in conjunction with Figure 3, alternate embodiments allow the different flows of information noted in Figure 4 to be combined in diflFerent ways.
Figure 5 is a timing diagram 500 illustrating communication among a client 504, a trust managCT 508, and a security broker 510 according to another embodiment. The timing diagram 500 includes a time axis 501.
At time tl, a device 102 (not shown in Figure 5) requests 505 access to a client 504 fiom the trast manager 508. The device 102 makes this request via the security broker 510. In an alternate embodiment, the security broker 510 may request access to a client 504 without initiation fix)m a device 102. At time t2, flie trust manager 508 receives 525 the security broker's 510 account information. As discussed above, the security broker's 510 account iirfoimation may include security credentials and authorization information. The security credentials may include a security broker ED and a security broker secret The autiiorization inforaiation may include device pemoissions, which may be used by the tmst manager 508 to detemune whether the device 102 may be provided access to the client 504 through the security broker 510. The trust manager 508 determines the validity of the security broker's 510 account informatioa At time t3, the trust manager 508 receives 545 the client's 504 account information. ITie trust manager 508 detemiines the validity of the client's 504 account information.
If the trust manager 508 is able to verify the cHent's 504 account information and the security broker's 510 account information, at time t4 the trust manager 508 provides 555 the security broko- 510 access to the client 504. At time t5, the security broker 510 accesses 565 the client 504, and the device 102 that initially requested 505 access is able to access the chent 504 via the security broker 510.
Figure 6 is a block diagram of an embodiment of the components stored on a trust

manager 608. The trust manager 608 may include a security broker accounts database 620 and a client accounts database 622. The security broker accounts database 620 may include security credentials and authorization information for one or more security brokers 110. The client accounts database 622 may include security credentials and authorization information for clients 104. The contents of the client accounts database 622 and the security broker accsounts database 620 will be discussed in greater detail below. These databases 620, 622 may be used by an authentication and authorization program 624 stored on the trust manager 608 to determine the validity of account information that is provided to the tmst manager 608. Of course the trust manager 608 may be implemented with the authentication and authorization program 624 on a separate node Sum the databases 620,622.
Figure 7 is a block diagram of an embodiment of a client accounts database 722 stored on a trust manager 108. The client accounts database 722 may include client account information 730a, 730b. The client account information 730 may include cUent security credentials 732a, 732b and client authorization information 740a, 740b. The client security credentials 732a, 732b may include client ©s 734a, 734b and client secrets 736a, 736b.
The client authorization information 740 may include allowed permissions 742, 744, 746,748, 750. The allowed pwnissions 742, 744,746, 748, 750 may indicate the devices 102 to which the chent 104 has been granted access, and are therefore labeled "access device permissions" in Figure 7. As discussed above, the client account information 730 may be used to determine whether the clirat 104 is who. it represents it is and whether it is authorized to access a device 102.
Figure 8 is a block diagram of an embodiment of a security broker accounts database 820 stored on a tmst manager 108. The security broker account database 820 may include security broker account information 850a, 850b. The security broker account information 850a, 850b may include security broker security credentials 852a, 852b and security broker authorization information 860a, 860b. The security broker security credentials 852a, 852b may include security broker IDs 854a, 854b and security broker secrets 856a, 856b.
The security broker authorization information 860a, 860b may include device permissions 862a, 862b, 862c, 862d, 862e. The device permissions 862 may indicate the devices 102 to which the security broker 110 is authorized to provide access to a client 104, and

are therefore labeled "provide device permissions" in Figure 8. As discussed above, the security broker account information 850a, 850b may be used to determine whether the security broker 110 is who it represents it is and whether it is authorized to provide access to a device 102.
Figure 9 is a block diagram of an embodiment of a client 904 illustrating the infomiation stored on flie client 904. The client 904 may include client security credentials 932 and client authorization information 940. The client security credentials 932 may include a client ID 934 and a client secret 936. Hie client ID 934 and client secret 936 may be provided by the manufactura* or may be provided by the clioit instaUer. Altanatively, the client ED 934 and cliait secret 936 may be chosen by a user after manufacture and installation. Alternatively still, the client ID 934 and client secret 936 may be provided by a user at the time the cliait initiates the request to the device 102. The client authorization information 940 may include access device permissions 942a, 942e.
Figure 10 is a block diagram of an embodiment of a security broker 1010 illustrating the information stored on the security broker 1010. The security broker 1010 may include security broker security credentials 1052 and security broker authorization information 1060. The security broker security credentials 1052 may include a security broker ID 1034 and a security broker secret 1036. Like the client ID 934 and client secret 936, the security broker ID 1034 and security broko" secret 1036 may be provided by a manufecturer of the security broker 1010 or by an installer. Altematively, the security broker ID 1034 and security broker secret 1036 may be chosen by a user after manufacture and installation. The security broko-authorization information 1060 may include provide device pemiissions 1062a, 1062c, 1062d These pemiissions rqmesoit the ability of tiie security broker 1010 to represent &e respective devices identified in the permissions 1062a, 1062c and I062d
Figure 11 is a flow diagram of an embodiment of a method 1100 for providing secure access to embedded devices 102 using a trust managa 108 and a security broker HO in a network 106 where the mediod is initiated by a client 104. In response to a request from a client 104 for access to a device 102, the trust manager 108 may authenticate 1105 the client 104. Authenticating 1105 the climt 104 may involve recdving the client's security credentials 932. For oiample, the trust manager 108 may receive the client ID 934 and client secret 936. Tlie trust manager 108 may compare the client's security credentials 932 with the client security

credentials 732 stored in the trust manager's 108 client accounts database 622.
The trust manager 108 may determine 1115 whether the client 104 was authenticated. A client 104 may be authenticated when its security credentials 932 correspond with the client security credentials 732 stored on the tmst manager 108. If the tmst manager 108 is not able to authenticate the client 104, then the trust manager 108 denies 1195 access to the desired device 102. However, if the trust manager 108 determines 1115 that the client 104 has been properly authaiticated, the trust manager 108 may determine 1125 to which device 102 the client 104 desires access. For example, if the client 904 of Figure 9 were the client attempting to access device A 202a of Figure 2, the trust manager 108 would deteraiine 1125 that the client 904 desired to access device A 202a.
The trust manager 108 may determine 1135 whether the client 104 is authorized to access the draired device 102. The trust manager 108 may make this determination 1135 by receiving the client's authorization information 940. For example, the trast manager 108 may receive the client's access device pennissions 942. The trust OMnager 108 may compare the client's authorization information 940 with the client authorization infomiation 740 stored in the trust manager's client accounts database 622.
If the client 104 is not authorized to access die desired device 102, thea the trust manager 108 denies 1195 the client 104 access to the desired device 102. However, if the client 104 is authorized to access the desired device 102, the trust manager 108 determines 1145 which (if any) security broker 110 may provide access to the desired device 102. The trust manager 108 may make this detemiination 1145 by querying the security broker accounts database 620 to determine 1145 which security broker 110 is authorized to provide access to the desired device 102. For example, if die client 904 requests access to device A 202a, the trust manager 108 would query its security broker accounts database 620 to find a security broker 110 that has a provide device Apermission 862a for device A 202a.
As discussed above, the trust manager 108 may only be in electronic communication with one security broker 110. Where there is only one security broker 110, the trust manager 108 may simply detemiine 1155 whether the security broker 110 is authorized to provide the client 104 access to the desired device 102.
If the trust manager 108 is not able to identiiy a security broker 110 tiiat is authorized

to provide acx:ess to the desired device 102, then the trust manager 108 denies 1195 the client 104 access to the desired device 102. However, if the tmst manager 108 identifies a security broker 110 that has the appropriate provide device permission 862, then the trust manager 108 authaiticates 1165 that security broker 110. Authenticating 1165 the security broker 110 may include receiving the security broker's security credentials 1052. For example, the trust manager 108 may receive the security broker ED 1034 and security broker secret 1036. The trust manager 108 may compare the security broker's security credentials 1052 with the security broker security credentials 852 stored in the trust manager's security broko* accounts database 620. A security broke-110 may be authenticated when its security credentials 1052 correspond with the security broker security credentials 852 stored on the trust manager 108.
If the trust manager 108 detamines 1175 that it is unable to authenticate the security broker 110, then the tmst manager 108 denies 1195 the client 104 access to the requested device 102. However, if the trust manager 108 determines 1175 that the security broker 110 has been successfully authenticated, then the trust manager 108 may establish 1185 a secure tnisted connection between the client 104 and the security broker 110. In an alternate embodiment, the client 104 may indicate the security broker 110 that should provide the access to the device 102. In this case the detemiination 1145 is already specified, but the validity of the specification may still be verified by checking the security broker security credentials 852 in the broker accounts database 620.
Figure 12 is a flow diagram of an embodiment of a method 1200 for providing secure access to embedded devices 102 using a trust manager 108 and a security broker 110 in a network 106 where the method 1200 is initiated by a security broker 110. This method 1200 may be used ■v/hen a security broker 110 wants to access a client 104 on behalf of a device 102.
A secxirity broker 110 may request access to a client 104 fit>m the tmst manager 108. In response, the tmst manager 108 may authenticate 1205 the security broker 110. The trust manager 108 may detemiine 1215 whether the security broker 110 was authenticated. As with the embodiment of Figure 11, a security broker 110 may be audienticated when its security credentials 1052 correspond with the security broker security credentials 852 stored on the trust manager 108.
If the trust manager 108 determines 1215 that it is not able to authenticate the security

broker 110, then the trust manager 108 daiies 1285 the security broker 110 access to the client 104. However, if the trust manager 108 deteraiines 1215 that the security broker 110 has been properly authenticated, the trust manager 108 may determine 1225 to which client 104 the security broker 110 desires access. For example, if security broker B 210b of Figure 2 were attempting to access client B 204b of Figure 2, the trust manager 108 would determine that security broker B 21 Ob desired access to client B 204b.
The trust manager 108 may determine 1235 whether the security broker 110 is authorized to proxy for a device 102 to the desired client 104. The trust manager 108 may make this determination 1235 by receiving the security broker's 110 authorization information 1060. For example, the trust manager 108 may receive the security broker's provide device permissions 1062. The tnist manager 108 may compare the security broker's authorization information 1060 with the security broker iaulhorization information 860 stored in the trust manager's security broker accounts database 620.
In the present embodiment, the provide device permissions 1062 may be used to determine 1235 whether the security broker 110 is authorized to proxy for a device 102 to a client 104. For example, if in the embodiment of Figure 2 security broker B 210b desires to proxy for device B 202b to client B 204b, the trust manager 208 would determine whether security broker B 210b, to which device B 202b is connected, is authorized to allow access to client B 204b. The trust manager 208 would query its security broker accounts database 620 to deterriiine whether security broko- B's account information 850b included a provide device B pemiission 862b. If the trust manager 208 deteraiines that security broker B 210b does contain a provide device 6 permission 862b, then the security broker B 210b may be authorized to allow client B 204b to access device B 202b and to allow device B 202b to access client B 204b.
In an alternative embodiment, the security broker 110 may have a separate set of pemnissions that allow it to proxy for a device 102 to a client 104. This separate set of permissions may be stored on the tmst manager 108 with its corresponding security broker authorization information 860 in the security broker accounts database 620.
If the trust manager 108 detennines 1235 that the security broker 110 is not authorized to provide access to the client 104, then the trust manager 108 denies 1285 the security broker 110 access to the client 104. However, if the tmst manager 108 determines 1235 that the security

broker 110 is authorized to provide access to the client 104, then the trust manager 108 may attempt to authenticate 1245 the client 104 and may determine 1255 whether the client 104 was authenticated.
If the trust manager 108 determines 1255 that the client 104 was not successMly authenticated, then the trust manager 108 denies 1285 the security broker 110 access to the client 104. However, if the trust manager 108 determines 1255 that the client 104 was successfully authenticated, then the trust manager 108 may also determine 1265 whether the chent 104 is authorized to allow the security broker 110 access to the cliait 104. This may involve receiving the client's authorization information 940 and comparing it to the client authorization infonnation 740 stored in the client accounts database 622 on the trust manager 108.
As discussed above, the client authorization infonnation 740 may include access device permissions 742. The access device permissions 742 may be used to determine 1265 whether the chent 104 is authorized to access a device 102 through the security broko' 110. For example, if security broker B 21 Ob desires to proxy for device B 202b to client B 204b, the trust manager 208 would determine whether climt B 204b is authorized to access device B 202b. The trust manager 208 woxdd query its client accounts database 622 to determine whether chent B's account information 730b included an access device B permission 742b. If the trust manager 208 d^ecmines that client B 204b does contain an access device B permission 742b, ihen a secure connection may be established 1275 between security broko- B 210b and client B 204b.
In an sdtemative embodiment, the client 104 may have a separate set of pennissions for allowing a security broker 110 to proxy for a device 102 to the client 104. This sqjarate set of permissions may be stored on die trust manager 108 with its corresponding cUent authorization information 740 in the client accounts database 622.
If the tmst manager 108 determines 1265 that tiie security broker 110 is not authorized to proxy for the device 102 to the client 104, then the trust manager 108 denies 1285 the security broker 110 access to the client 104. However, if the tmst manager 108 determines 1265 that the security broker 110 is authorized to proxy for the device 102 to the client 104, tfien the trust manager 108 may establish 1275 a secure trusted connection between the client 104 and the

security broker 110.
Figure 13 is a block diagram of hardware components that may be used in an embodiment of a computing device or an embedded device. A computing device and/or an embedded device may be used as a client 104, security broker 110, trust manager 108, or device 102. A CPU 1310 or processor may be provided to control the operation of the device 1302, including the other components thereof, which are coupled to the CPU 1310 via a bus 1312. The CPU 1310 may be embodied as a microprocessor, microcontroller, digital signal processor or other device known in the art. The CPU 1310 performs logical and arithmetic operations based on program code stored within the memory 1314. In certain embodiments, the memory 1314 may be on-board monory included with the CPU 1310. For example, microcontrollers often include a certain amount of on-board memory.
The computing or anbedded device 1302 may also include a network interface 1316. The network interface 1316 facilitates communication between the device 1302 and other devices connected to the network 100. The network 100 may be a pager network, a cellular network, a global communications network, the Internet, a compute network, a telqjhone network, etc. The network interface 1316 operates according to standard protocols for the applicable network 106.
The device 1302 may also include memory 1314. The memory 1314 may include a random access memory (RAM) for storing temporary data. Alternatively, or in addition, the memory 1314 may include a read-only memory (ROM) for storing more permanent data, such as fixed code and ccnifiguration data. The memory 1314 may also be embodied as a magnetic storage device, such as a hard disk drive. The memory 1314 may be any typ)e of electronic device capable of storing electronic information.
The device 1302 may also include communication ports 1318, which facilitate communication with other devices. The device 1302 may also include input/ouiput devices 1320, such as a keyboard, a mouse, a joystick, a touchscreen, a monitor, speakers, a printer, etc.
The present systems and methods may be used in several contexts. Figure 14 illustrates one embodiment of a system wherein the present systems and methods may be implemented. Figure 14 is a block diagram that illustrates one embodiment, of a lifting system 1400 that includes a lighting controller system 1408. The lighting system 1400 of Figure 14

may be incorporated in various rooms in a home. As illustrated, the system 1400 includes a room A 1402, a room B 1404, and a room C 1406. Although three rooms are shown in Figure 14, the system 1400 may be implemented in any number and variety of rooms within a home, dwelling, or other sivironment
The lighting controllo- system 1408 may monitor and control additional embedded systems and components within the system 1400. In one embodiment, the room A1402 and the room B 1404 each include a switch componoit 1414,1418. The switch components 1414,1418 may also include a secondary embedded system 1416,1420. The secondary embedded systems 1416, 1420 may receive instructions from the lifting controller system 1408. The secondary embedded systems 1416, 1420 may then execute these instmctions. The instructions may include powering on or powering off various light components 1410, 1412, 1422, 1424. The instmctions may also include dimming the brightness or increasing the brightness of the various light components 1410, 1412, 1422, 1424. The instmctions may further include arranging the brightness of the light components 1410,1412, 1422, 1424 in various patterns. The secondary embedded systems 1416, 1420 fecilitate the lighting controller system 1408 to monitor and control each light componait 1410,1412,1422,1424 located in the room A 1402 and the room B1404.
The lighting controller system 1408 mi^t also provide instmctions directly to a light component 1426 that includes a secondary embedded system 1428 in die depicted room C 1406. The lighting controller system 1408 may instruct the secondary embedded system 1428 to power down or power up the individual light component 1426. Similariy, the instructions received from the lighting controller system 1408 may include dimming the brightness or increasing the brightness of the individual light component 1426.
The lighting controller system 1408 may also monitor and provide instmctions directly to individual light components 1430 1432 within die system 1400. Tbese instructions may include similar instructions as described previously.
In the embodiment of Figure 14, the lighting controller system 1408 may act as a client 104. The lighting controller system 1408 may desire access to one of the light components 1410, 1412, 1422, 1424, 1426, 1430, 1432, which maybe treated as devices 102. Secondary embedded systems 1416, 1420,1428 may act as both a security broker 110 and a device 102.

The lighting controller system 1408 may request access to the secondary embedded systems 1416,1420,1428 from a trust manager 108. When the trust manager 108 grants a secure trusted connection between the secondary embedded systems 1416, 1420, 1428 and the lighting controller system 1408, these light components may provide data regarding their status, for example whether a light component is on or off or the current or past wattage passing through the light component.
Figure 15 is an additional embodiment of a system whaein flie present systems and methods of the present invention may be implemented. Figure 15 is a block diagram illustrating a security system 1500. The security system 1500 in the depicted anbodiment is implemented in a room A 1502, a room B 1504, and a room C 1506. These rooms may be in the confines of a home or other enclosed aivironment The system 1500 may also be implemented in an open environment where the rooms A, B and C, 1502,1504,1506 respectively represait territories or boundaries.
The system 1500 includes a security controller system 1508. The security controller system 1508 monitors and receives infomiation fiom the various con^KDnents within the system 1500. For example, a motion sensor 1514, 1518 may include a secondary embedded system 1516, 1520. The motion sensors 1514, 1518 may monitor an immediate space for motion and alert the security controller system 1508 when motion is detected via the secondary embedded system 1516, 1520. The security controller system 1508 may also provide inshuctions to (he various components within the isystem 1500. For example, the security controller system 1508 may provide insbuctions to the secondary embedded systems 1516,1520 to powier up or power down a window saisor 1510, 1522 and a door sensor 1512, 1524. In one embodiment, the secondary embedded systems 1516, 1520 notify the security controller system 1508 when the window sensors 1510,1522 detect movement of a window. Similariy, the secondary embedded systems 1516, 1520 notify the security controller system 1508 whoi the door sensors 1512, 1524 detect movement of a door. The secondary embedded systems 1516, 1520 may instruct the motion sensors 1514, 1518 to activate the LED (not shown) located within the motion sensors 1514,1518.
The security controller system 1508 may also monitor and provide instmctions directly to individual components wifliin the system 1500. For example, the security controller

system 1508 may monitor and provide instructions to power up or power down to a motion sensor 1530 or a window sensor 1532. The security controUer system 1508 may also instruct the motion sensor 1530 and the window sensor 1532 to activate the LED (not shown) or audio alert notifications within the sensors 1530,1532.
Each individual component comprising the system 1500 may also include a secondary embedded system. For example. Figure 15 illustrates a door sensor 1526 including a secondary embedded system 1528. The security controller system 1508 may monitor and provide instructions to the secondary embedded system 1528 in a similar manner as previously described.
In the embodiment of Figure 15, the security controller system 1508 may act as a client 104. The security controller system 1508 may desire access to one of the sensors 1510, 1512, 1522, 1524, 1526, 1530, 1532. which may be treated as devices 102. Secondary embedded systems 1516, 1520,1528 may act as both a security broker 110 and a device 102. The security controller system 1508 may request access to the secondary embedded systems 1516,1520,1528 fix)m a trust manager 108. When the trust manager 108 grants a secure trusted connection betweai the secondary embedded systems 1516, 1520, 1528 and the security controller system 1508, these sensors 1510,1512, 1522,1524, 1526, 1530, 1532 may provide data regarding their status. For example, the window sensors 1510, 1522, 1532 may provide data regarding whdher ihey are open or closed.
Figure 16 is a block diagram iUustrating one embodiment of a home system 1600. The home system 1600 includes a home controller 1608 that fecilitates the monitoring of various systems such as ttie lifting system 1400, the security system 1500, and the like. The home system 1600 allows a user to control various components and systems throu^ one or more embedded systems. In one embodiment, the home controUer system 1608 monitors and provides information in the same manner as previously described in relation to Figures 14 and 15. In the depicted embodiment, the home controller 1608 provides instructions to a heating component 1624 via a secondary embedded system 1620. The heating component 1624 may include a fiimace or other heating device typically found in resident locations or oflSces. The home controller system 1608 may provide instructions to power up or power down the heating component 1624 via the secondary embedded system 1620.

Similarly, the home controller 1608 may monitor and provide instructions directly to a component within the home system 1600 such as a cooling component 1630. The cooling component 1630 may include an air conditioner or other cooling device typically found in resident locations or offices. The central home controller 1608 may instruct the cooling component 1630 to power- up or power down depending on the temperature reading collected by the caitral embedded system 1608. The home system 1600 functions in a similar manner as previously described in relation to Figures 14 and 15.
In the embodiment of Figure 16, the home controller system 1608 may act as a client 104. The home controller system 1608 may desire access to the window sensor 1610, door sensor 1612, heating component 1624, cooling component 1630, or lighting components 1622, 1626, 1632, all of which may be treated as devices 102. Secondary embedded systems 1616, 1620,1628 may act as both a security broker 110 and a device 102. The home controller system 1608 may request access to the secondary embedded systems 1616, 1620, 1628 from a tmst manager 108. When the trust manager 108 grants a secure tmsted connection between the secondary embedded systems 1616, 1620, 1628 and the home controller system 1608, these elements 1610,1612,1622,1624,1626,1630,1632 may provide data regarding their status. For example, the heating and cooling components 1624, 1630 may provide data regarding the present tempaature in their respective rooms 1604,1606. The heating and cooling components 1624, 1630 may provide data regarding the status of the component, whether it is on or off, its recent power usage, any system errors, etc.
There are many types of anbedded devices and many reasons for creating device networks. Several examples of device networking applications will be set forth. It will be appreciated by those skilled in the art that the examples discussed are not exhaustive.
One example of a device networking application is remote monitoring. Many useiul device networks involve remote monitoring, the one-way transfer of information fiom one node to another. In these ajqilications, providers typically act as small servers that report certain information in response to a requestor. Providers can also be set up to publish their state information to subscribers. A requestor may ask for periodic reports or for updates whenever the state changes, perhaps with some means of limiting how often updates are to be sent. Providers can be set up to notify requestors when some event or exceptional condition occurs.

Another example of a device network application is remote control, where requestors are able to send commands to providers to invoke some specific action. In most cases, remote control involves some sort of feedback.
A still further example of a device networking application is distributed control systems. The functions and data associated with individual providers can be combined and coordinated through a network to create a distributed system that provides additional value. Sometimes these distributed control systems can be established more or less automatically. In many cases, a more sophisticated device joins a peer-to-peer network to perform configuration, monitoring or diagnostic duties. Such systems may be created by objects that communicate as peers or through a master-slave configuration, in which each object in the system communicates with a single, central node that contains all of the control logic.
With each category of networking application, there are a variety of ways in which requestors may connect to providers. When a relatively small number of provides are involved, a requestor may use a web browser, pager or even a WAP-enabled cell phone to communicate with a provider in a more or less interactive manner. As the number of providers grows, however, these methods may become unworkable and requestors may employ more general data management techniques such as a spreadsheet or database application
As a variety of networks are implemented over time and with different technologies, the situation can arise in which multiple networks might sit in the same home or facility, each using their own protocols and unable to communicate with the othrs. In this case, the various networks and protocols can be bridged to create a single, larger network. This can allow a single application to access each provider, simplifying the interaction with all of the providers.
Information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instmctions, commands, information, signals, bits, symbols, and chips that may be represented throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof
The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this

interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and stqps have been described above generally in terms of their functionality. Whether such fiinctionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall systen. Skilled artisans may implement the described fimctionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure fiom the scope of the present invention.
The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array signal (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete handware components, or any combination thereof designed to perform the functions described herein. A genoal purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art An exemplary storage medium is coapled to the processor such that the processor can read infomiation fixDm, and write infomiation to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and die storage medium may reside in an ASIC. The ASIC may reside in a user temiinal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.
Hie methods disclosed herein comprise one or more steps or actions for achieving the described method. The method steps and/or actions may be interchanged with one another

without departing from the scope of the present invention. In other words, unless a specific order of steps or actions is required for proper operation of the embodiment, the order and/or use of specific steps and/or actions may be modified without departing fiom the scope of the present invention.
While specific embodiments and applications of the present invention have been illustrated and described, it is to be understood that the invention is not limited to the precise configuration and components disclosed herein. Various modifications, changes, and variations which will be apparent to those skilled in the art may be made in the arrangemoit, operation, and details of the methods and systems of the present invention disclosed herein without departing fiiom the spirit and scope of the inventioa
INDUSTRIAL APPLICABILITY
The present invention is applicable to an embedded system.

CLAIMS
1. A method for providing secure access to embedded devices, the method being
implemented by a trust manager, the method comprising:
receiving client account information from a client;
determining whether the client account information from the client is valid;
determining whether the client is authorized to access at least one embedded device that is in electronic communication with a security brokerr,
receiving security broker account infomation from the security broker,
detennining whether the security broker account information from the security broker is valid;
determining whether the security broker is authorized to provide access to the at least one anbedded device; and
if the client account infonnation from the client is valid and tihe client is authorized to access die at least one embedded device, and if the security broker account infonnation from the security broker is valid and the security broker is authorized to provide access to the at least one embedded device, establishing a secure trusted connection between the client and the security broker.
2. The method of claim 1, wherein the method is performed in response to receiving a request from the client for access to the at least one embedded device.
3. The method of claim 1, wherein tfie method is perfonmed in respwise to receiving a request from the security broker to provide access to the at least one embedded device.
4. The method of claim 1, wherein the client account information comprises:
security credentials for the client; and
authorization information for the client
5. The method of claim 4, wherein the security credentials for the client comprise a client

identifier and a client secret.
6. The method of claim 4, wherein, the authorization information for the client comprises device access permissions.
7. The method of claim 1, wherein detennrning whether the client account information is valid comprises comparing the client account information that was received fiom the client with validated client account information.
8. The method of claim 7, wherein the validated client account information is stored on the trust manager.
9. The method of claim 1, what in the security broker account information comprises:
security credentials for the security broker, and
authorization information for the security broker.
10. The method of claim 9, wherein the security credentials comprise a security broker identifier and a security broker secret
11. The method of claim 9, wherein the authorization information for the security broker comprises device provide permissions.
12. The method of claim 1, wherein detennining whether the security broker account information is valid comprises comparing the security broker account information that was received fiom the security broker with validated security broker account information.
13. The method of claim 12, wherein the validated security broker account information is stored on the trust managa:
14. A trust manager that is configured to implement a method for providing secure access

to embedded devices, the trust manager comprising:
a processor,
memory in electronic communication with the processor,
instructions stored in the memory, the instmctions being executable to implement a method comprising:
receiving client account information from a client;
determining whether the client account information from the client is valid;
determining whether the client is authorized to access at least one embedded device that is in electronic communication with a security broker,
receiving security broker account information from the security broker,
determining whether the security broker account information from the security broker is valid;
determining whether the security broker is authorized to provide access to the at least one embedded device; and
if the client account information from the client is valid and the client is authorized to access the at least one embedded device, and if the security broker account information from the security broker is valid and the security broker is authorized to provide access to the at least one embedded device, establishing a secure trusted connection between the client and the security broker.
15. "Die trust manager of claim 14, wherein the method is performed in response to receiving a request from the client for access to the at least one embedded device.
16. The trust manager of claim 14, wherein die method is performed in response to receiving a request from the security broker to provide access to the at least one embedded device.
17. The trust manager of claim 14, wherein the client account information comprises security credentials for the client and authorization information for the client, and wherein the security broker account information comprises security credentials for the security broker and

authorization infomation for the security broker.
18. A computer-readable medium comprising executable instructions for implementing a
method for providing secure access to embedded devices, the method being implemented by a
trust manager, the method comprising:
receiving client account information from a client;
determining whether the client account information from the cliait is valid;
detennining whether the client is authorized to access at least one embedded device that is in electronic communication with a security broker;
receiving security broker account infomiation from the security broker,
detennining whether the security broker account information from the security broker is valid;
determining whethCT the security broker is autiiorized to provide access to the at least one embedded device; and
if the dieat account infomiation ficnn the client is valid and the client is authorized to access the at least one embedded device, and if the security broker account information from the security broker is valid and the security broker is authorized to provide access to the at least one embedded device, establishing a secure trusted connection between the cli«it and the security broker.
19. The computer-readable medium of claim 18, wherein the method is performed in
response to receiving a request from the client for access to the at least one embedded device.
20. The computer-readable medium of claim 18, wherein the method is performed in
response to receiving a request from the security broker to provide access to the at least one
embedded device.

Documents:

3316-CHENP-2008 CORRESPONDENCE OTHERS 11-04-2013.pdf

3316-CHENP-2008 FORM-13 30-01-2009.pdf

3316-CHENP-2008 OTHERS 17-06-2013.pdf

3316-CHENP-2008 AMENDED CLAIMS 17-06-2013.pdf

3316-CHENP-2008 AMENDED PAGES OF SPECIFICATION 17-06-2013.pdf

3316-chenp-2008 claims.pdf

3316-chenp-2008 description (complete).pdf

3316-CHENP-2008 EXAMINATION REPORT REPLY RECEIVED. 17-06-2013.pdf

3316-CHENP-2008 FORM-1 17-06-2013.pdf

3316-chenp-2008 form-1.pdf

3316-chenp-2008 form-18.pdf

3316-CHENP-2008 FORM-3 17-06-2013.pdf

3316-chenp-2008 form-3.pdf

3316-chenp-2008 form-5.pdf

3316-chenp-2008 pct.pdf

3316-chenp-2008 abstract.pdf

3316-chenp-2008 correspondence -others.pdf

3316-CHENP-2008 CORRESPONDENCE OTHERS 03-05-2012.pdf

3316-chenp-2008 drawings.pdf

3316-CHENP-2008 ENGLISH TRANSLATION 03-05-2012.pdf

3316-CHENP-2008 FORM-6 03-05-2012.pdf

3316-CHENP-2008 POWER OF ATTORNEY 03-05-2012.pdf

« Previous Patent

Next Patent »

Patent Number

257792

Indian Patent Application Number

3316/CHENP/2008

PG Journal Number

45/2013

Publication Date

08-Nov-2013

Grant Date

04-Nov-2013

Date of Filing

27-Jun-2008

Name of Patentee

PANASONIC CORPORATION

Applicant Address

1006, OAZA- KADOMA, KADOMA-SHI, OSAKA 571-8501.

Inventors:

#	Inventor's Name	Inventor's Address
1	MILLIGAN, THOMAS	C/o. MATSUSHITA ELECTRIC WORKS, LTD., 1048, OAZA- KADOMA, KADOMA-SHI, OSAKA
2	EASTHAM, BRYANT,	C/o. MATSUSHITA ELECTRIC WORKS, LTD., 1048, OAZA- KADOMA, KADOMA-SHI, OSAKA

PCT International Classification Number

HO4L 29/06

PCT International Application Number

PCT/JP06/303507

PCT International Filing date

2006-02-20

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1	11/320,164	2005-12-28	U.S.A.