Patent Publication Number: US-2013247152-A1

Title: Access device, access system and computer program product

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application is based upon and claims the benefit of priority from Japanese Patent Application No. 2012-056267, filed on Mar. 13, 2012; the entire contents of which are incorporated herein by reference. 
     FIELD 
     Embodiments described herein relate generally to an access device, an access system and a computer program product. 
     BACKGROUND 
     A known technique provides access authorization such as user authorization with a server on an external network in the event that an access device accesses an access target device. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram illustrating an exemplary access system according to a first embodiment; 
         FIG. 2  is a diagram illustrating an exemplary user authorization screen according to the first embodiment; 
         FIG. 3  is a sequence diagram illustrating an exemplary function access process according to the first embodiment; 
         FIG. 4  is a flowchart illustrating the exemplary function access process according to the first embodiment; 
         FIG. 5  is a block diagram illustrating an exemplary access system according to a second embodiment; 
         FIG. 6  is a diagram illustrating an exemplary user authorization screen according to the second embodiment; 
         FIG. 7  is a sequence diagram illustrating an exemplary function access process according to the second embodiment; 
         FIG. 8  is a flowchart illustrating the exemplary function access process according to the second embodiment; 
         FIG. 9  is a block diagram illustrating an exemplary access system according to a third embodiment; 
         FIG. 10  is a diagram illustrating an exemplary user authorization screen according to the third embodiment; 
         FIG. 11  is a diagram illustrating an exemplary user authorization screen according to the third embodiment; and 
         FIG. 12  is a schematic diagram illustrating a plurality of access target devices according to the third embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     According to an embodiment, an access device, includes a first obtaining unit configured to obtain a first authorization as user authorization; and a second obtaining unit configured to obtain a second authorization as authorization other than the user authorization through communication with a server via an external network. The access device also includes an accessing unit configured to access a function of an access target device via a local network by using the first authorization and the second authorization. 
     A description will be given of an embodiment in detail below by referring to the accompanying drawings. 
     First Embodiment 
       FIG. 1  is a block diagram illustrating an exemplary access system  100  according to a first embodiment. As illustrated in  FIG. 1 , the access system  100  includes an access device  110 , a server  130 , and an access target device  150 . 
     The access device  110  is coupled to the access target device  150  via a local network  101 . Both the access device  110  and the access target device  150  are coupled to the server  130  via the local network  101  and an external network  102 . 
     The local network  101  is a network that is configured of a wireless local area network (LAN), Ethernet (registered trademark), and similar network. The local network  101  is achieved, for example, by various LANs such as a home LAN and a company LAN. In the first embodiment, a description will be given of an example where the local network  101  is a home LAN and both the access device  110  and the access target device  150  are in the same home. However, this embodiment is not limited to this. 
     The local network  101  is not limited to the aforementioned configuration. The local network  101  may be power line communications (PLC), a personal area network (PAN), a cellular network, or similar network. The PAN may be configured of, for example, a universal serial bus (USB), an infrared, Bluetooth (registered trademark), Zigbee (registered trademark), or similar method. In the case where the local network  101  is a cellular network, the access device  110  is preferred to preliminarily employ a method (such as SIP Name) for coupling to the access target device  150  via the cellular network. 
     The external network  102  is achieved by, for example, the Internet, a next generation network (NGN), and similar network. The NGN is a quality guaranteed closed network. While in the first embodiment, a description will be given of an example where the external network  102  is the Internet, the external network  102  is not limited to this. 
     The access device  110  accesses a function of the access target device  150 . The access device  110  is achieved by, for example, a tablet terminal, a personal computer, a smart phone, a mobile phone, a digital television, a dedicated terminal, or similar device. The access device  110  is achieved by a hardware configuration with an ordinary computer. This ordinary computer includes a control unit such as a central processing unit (CPU), a storage device such as a read only memory (ROM) and a random access memory (RAM), an external storage device such as a hard disk drive (HDD) and a solid state drive (SSD), a display unit such as a display device, various input devices, and a communication I/F such as a NIC. While in the first embodiment, a description will be given of an example where the access device  110  is a tablet terminal connectable to the local network  101 , the access device  110  is not limited to this. 
     The server  130  provides authorization other than authorization (hereinafter referred to as “user authorization”) by an owner of the access target device  150  to allow the access device  110  to access the function of the access target device  150 . Any authorization other than the user authorization is possible insofar as the authorization is provided by a person who attempts to control the access of the access device  110  to a function of the access target device  150  except the owner of the access target device  150 . The server  130  is achieved by a hardware configuration with an ordinary computer. This ordinary computer includes a control unit such as a CPU, a storage device such as a ROM and a RAM, an external storage device such as an HDD and an SSD, a display unit such as a display device, various input devices, and a communication I/F such as a NIC. In the first embodiment, the authorization other than the user authorization is an authorization (hereinafter referred to as “manufacturer authorization”) by a manufacturer of the access target device  150 . The server  130  is a server operated by a manufacturing corporation and an affiliate corporation of the access target device  150  on the Internet. The first embodiment is not limited to these. 
     The access target device  150  has a target function to be accessed by the access device  110 , and also provides the user authorization to allow the access device  110  to access the function of the access target device  150 . The access target device  150  is achieved by, for example, a digital television, a personal computer, a hard disk recorder, a smart phone, a mobile phone, a tablet terminal, an air conditioner, an electric vehicle, an electric vehicle charger, a home energy management server (HEMS) as a communication device that controls equipment, or similar device. The access target device  150  is achieved by a hardware configuration with an ordinary computer. This ordinary computer includes a control unit such as a CPU, a storage device such as a ROM and a RAM, an external storage device such as an HDD and an SSD, a display unit such as a display device, various input devices, and a communication I/F such as a NIC. While in the first embodiment, a description will be given of an example where the access target device  150  is a digital television connectable to the local network  101 , the access target device  150  is not limited to this. 
     As illustrated in  FIG. 1 , the access device  110  includes a first obtaining unit  111 , a second obtaining unit  113 , a storage unit  115 , and an accessing unit  117 . The first obtaining unit  111 , the second obtaining unit  113 , and the accessing unit  117  are achieved by, for example, execution of a program in a processor such as a CPU, or by software. The storage unit  115  is implemented in a storage that stores information with at least one of magnetic, optical, and electrical methods. The storage unit  115  may be, for example, an HDD, an SSD, a RAM, a memory card, or a similar type of storage. 
     The first obtaining unit  111  obtains the user authorization. Specifically, the first obtaining unit  111  communicates with the access target device  150  via the local network  101  so as to obtain the user authorization from the access target device  150 . The first obtaining unit  111  obtains, for example, a user credential as the user authorization. 
     A communication protocol that is used to obtain the user credential by the first obtaining unit  111  employs, for example, HyperText Transfer Protocol (HTTP), File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), Internet Message Access Protocol (IMAP), ECHONET Lite, a Smart Energy Profile 2 (SEP2), Constrained Application Protocol (CoAP), or similar protocol. 
     The communication protocol used by the first obtaining unit  111  may be determined by a predetermined program. Alternatively, the first obtaining unit  111  may obtain the communication protocol using a method for detecting equipment or service such as Universal Plug and Play (UPnP), multicast Domain Name System (mDNS), and Network Basic Input Output System (NetBIOS), and a similar object at a timing when obtaining the user credential. 
     The second obtaining unit  113  communicates with the server  130  via the local network  101  and the external network  102  so as to obtain the authorization other than the user authorization from the server  130 . While in the first embodiment, the authorization other than user authorization is the manufacturer authorization, the authorization is not limited to this. The second obtaining unit  113  obtains, for example, a server credential as the manufacturer authorization. 
     Specifically, the second obtaining unit  113  transmits access device information, which is related to the access device  110 , to the server  130 . In the event that the second obtaining unit  113  succeeds in authorization of the access device information in the server  130 , the second obtaining unit  113  determines a content to be authorized and then obtains the server credential corresponding to the authorized content. The access device information includes an ID of the manufacturer, a vendor, the owner, a unique ID, a model, a device type, or similar parameter of the access device  110 , information indicating whether or not the access device  110  safely controls the user credential and the server credential, and similar information. This is because the user credential and the server credential are secret information. While the access device information is preferred to have signature of a third party or similar information to prevent impersonation, this is not mandatory. 
     The storage unit  115  stores the user authorization obtained by the first obtaining unit  111  and the manufacturer authorization obtained by the second obtaining unit  113 . The storage unit  115  stores, for example, the user credential and the server credential. 
     The accessing unit  117  accesses the function of the access target device  150  via the local network  101  by using the user authorization and the manufacturer authorization. Specifically, in the event that the accessing unit  117  transmits the user credential and the server credential to the access target device  150  and succeeds in authorization of the user credential and the server credential in the access target device  150 , the accessing unit  117  accesses the function of the access device  110 . 
     Accessing the function (which is occasionally referred to as “a function access”) is performed as follows. For example, the access target device  150  returns a response to the access device  110  so as to provide the access device  110  with the function of the access target device  150  (that is, the access device  110  receives the function of the access target device  150 ). Providing the function of the access target device  150  to the access device  110  is performed as follows. For example, the access target device  150  returns a list of recorded content to the access device  110  as a response so as to display the list of recorded content of the access target device  150  in the access device  110 . 
     The function access is not limited to this. The function access is also performed as follows. For example, the function access requests the access target device  150  for information (such as the list of recorded content) that is providable from the access target device  150  so as to obtain this information. Additionally, the function access may be performed as follows. For example, the function access may make the access target device  150  execute a function such as a modification of a state of the access target device  150 . Making the access target device  150  execute the function is performed as follows. For example, the function access makes the access target device  150  change a channel. Alternatively, the process makes the access target device  150  operate the recorded content (playing back, deleting, or a similar operation). 
     The communication protocol used for the function access by the accessing unit  117  employs, for example, HTTP, FTP, SMTP, IMAP, ECHONET Lite, SEP2, CoAP, or similar protocol. The procedure where the accessing unit  117  accesses the function of the access target device  150  may be preliminarily determined by a program and a similar method. Alternatively, the accessing unit  117  may obtain the procedure using a method for detecting equipment or service such as UPnP, mDNS, NetBIOS, and a similar object at a timing when performing the function access. 
     The server  130  includes a second authorizing unit  131  as illustrated in  FIG. 1 . The second authorizing unit  131  is achieved by, for example, execution of a program in a processor such as a CPU, or by software. 
     The second authorizing unit  131  communicates with the access device  110  via the external network  102  and the local network  101  so as to issue the manufacturer authorization to the access device  110 . The second authorizing unit  131  issues, for example, a server credential as the manufacturer authorization. While the server credential is provided with lifetime, the server credential is not limited to this. 
     Specifically, the second authorizing unit  131  receives the access device information from the access device  110 , and then authorizes the received access device information. When the second authorizing unit  131  succeeds in the authorization, the second authorizing unit  131  determines a content to be authorized and then issues the server credential correspond to the authorized content. When the second authorizing unit  131  fails in the authorization, the second authorizing unit  131  does not issue the server credential. 
     As illustrated in  FIG. 1 , the access target device  150  includes a first authorizing unit  151  and a providing unit  153 . The first authorizing unit  151  and the providing unit  153  are achieved by, for example, execution of a program in a processor such as a CPU, or by software. 
     The first authorizing unit  151  issues the user authorization to the access device  110  through communication with the access device  110  via the local network  101 . The first authorizing unit  151  issues, for example, a user credential as the user authorization. While the user credential is provided with lifetime, the user credential is not limited to this. Specifically, in the event that the first authorizing unit  151  starts the communication with the access device  110 , the first authorizing unit  151  displays a user authorization screen on a display device (not shown). In the event that the first authorizing unit  151  receives an authorization operation through the user authorization screen from the owner of the access target device  150 , the first authorizing unit  151  transmits the user credential to the access device  110 . The user authorization screen is displayed on, for example, a Webpage, an electric operation manual, and a similar medium. 
       FIG. 2  is a diagram illustrating an exemplary user authorization screen according to the first embodiment. In the example of  FIG. 2 , the owner of the access target device  150  selects a function to authorize the access device  110  to access the access target device  150  using a checkbox  10 . Clicking an authorization button  11  allows the first authorizing unit  151  to receive the authorization operation of the owner. The user authorization screen may include information such as CAPCHA or similar information that is difficult for a computer to decipher. In addition to clicking the authorization button  11 , the authorization operation of the owner may include input of information that is difficult for a computer to decipher. In addition to clicking the authorization button  11 , the authorization operation of the owner may include input of information such as a character, a number, and similar data that are displayed on the display device of the access target device  150  and not readily accessible except the owner of the access target device  150 . On the other hand, in the event that the owner clicks a rejection button  12  and then the first authorizing unit  151  receives a rejection operation from the owner, the first authorizing unit  151  does not transmit the user credential to the access device  110 . 
     A list of target functions to be accessed by the access target device  150  may be controlled by the access target device  150  or controlled by the access device  110 . When the list is controlled by the access device  110 , the access device  110  simply transmits the list to the access target device  150 . 
     The communication protocol used by the first authorizing unit  151  to issue the user credential may employ, for example, HTTP, FTP, SMTP, IMAP, ECHONET Lite, SEP2, CoAP, or a similar protocol. The communication protocol used by the first authorizing unit  151  may be preliminarily determined by a program or a similar method. Alternatively, the first obtaining unit  111  may obtain the communication protocol using a method for detecting equipment or service such as UPnP, mDNS, NetBIOS at a timing when obtaining the user credential. The first authorizing unit  151  is preferred to validate the communication with the aforementioned communication protocol after receiving the authorization operation from the owner of the access target device  150 . 
     The first authorizing unit  151  may issue the same user credential every time. However, the user credential is information that basically needs to be a secret to anyone except the access device  110  and the access target device  150 . Accordingly, the first authorizing unit  151  is preferred to issue a different user credential every time, and to issue a user credential that is changed at regular time intervals. 
     The providing unit  153  provides the access device  110  with the function based on the user authorization and the manufacturer authorization that are transmitted via the local network  101  from the access device  110 . Specifically, the providing unit  153  receives the user credential and the server credential from the access device  110 . Then, the providing unit  153  authorizes the user credential and the server credential, for example, determines lifetime of the received user credential and server credential. For example, the providing unit  153  authorizes the user credential itself, while the providing unit  153  communicates with the server  130  via the local network  101  and the external network  102  for authorization of the server credential. 
     Then, in the event that the providing unit  153  succeeds in the authorization, the providing unit  153  provides the access device  110  with a function of the target to be accessed via the local network  101 . For example, the providing unit  153  transmits the list of recorded content of the access target device  150  to the access device  110 , thus providing the access device  110  with a function that displays the list of recorded content. The providing unit  153  may execute the function of the access target device  150  on the access target device  150  instead of providing it to the access device  110 . 
     The access device  110 , the server  130 , and the access target device  150  may not include all functional units described above as mandatory configuration, and may have configuration without a part of these units. For example, the access device  110  does not need to include the storage unit  115 . In this case, the access device  110  simply obtains the user credential and the server credential every time the access device  110  performs the function access. 
     The functional units of the access device  110 , the server  130 , and the access target device  150  may be exchanged among the access device  110 , the server  130 , and the access target device  150 . For example, the access device  110  may include the first authorizing unit  151  of the access target device  150 . 
       FIG. 3  is a sequence diagram illustrating an exemplary procedure of the function access process in the access system  100  according to the first embodiment. 
     First, the access device  110  requests the function access from the accessing unit  117  (step S 101 ). Subsequently, the accessing unit  117  attempts to access the function of the access target device  150  via the local network  101  (step S 103 ). However, the user credential and the server credential are not obtained at this point. Accordingly, the providing unit  153  transmits an error (rejection of the function access) to the accessing unit  117  via the local network  101  (step S 105 ). The accessing unit  117  in turn returns the error to the access device  110  (step S 107 ). 
     The user credential and the server credential are not stored in the storage unit  115  at step S 101 . In view of this, steps S 101  to S 107  may be omitted if it is preliminary known that the access device  110  needs the user credential and the server credential to perform the function access. The user credential and the server credential are not stored in the storage unit  115  at step S 103  yet. In view of this, the accessing unit  117  may return the error to the access device  110  without attempting the function access. Accordingly, steps S 103  and S 105  may be omitted. 
     Subsequently, the access device  110  requests the first obtaining unit  111  to obtain the user credential (step S 109 ). Subsequently, the first obtaining unit  111  requests the user credential from the first authorizing unit  151  via the local network  101  (step S 111 ). Subsequently, the first authorizing unit  151  displays the user authorization screen as illustrated in  FIG. 2 . In the event that the first authorizing unit  151  receives the authorization operation from the owner of the access target device  150  through the user authorization screen, the first authorizing unit  151  transmits the user credential to the first obtaining unit  111  via the local network  101  (step S 113 ). The first obtaining unit  111  in turn returns the user credential to the access device  110  (step S 115 ). Subsequently, the access device  110  stores the user credential in the storage unit  115 . 
     Subsequently, the access device  110  requests the second obtaining unit  113  to obtain the server credential (step S 117 ). Subsequently, the second obtaining unit  113  transmits the access device information to the second authorizing unit  131  via the local network  101  and the external network  102 , thus requesting the server credential (step S 119 ). Subsequently, the second authorizing unit  131  authorizes the access device information. In the event that the second authorizing unit  131  succeeds in the authorization, the second authorizing unit  131  transmits the server credential to the second obtaining unit  113  via the external network  102  and the local network  101  (step S 121 ). The second obtaining unit  113  in turn returns the server credential to the access device  110  (step S 123 ). Subsequently, the access device  110  stores the server credential in the storage unit  115 . 
     The obtaining order of the user credential and the server credential may be the user credential and the server credential in that order as described above, and may the server credential and the user credential in that order. Alternatively, the user credential and the server credential may be obtained at the same time. 
     Subsequently, the access device  110  obtains the user credential and the server credential from the storage unit  115 , and then requests the function access from the accessing unit  117  again (step S 125 ). Subsequently, the accessing unit  117  transmits the user credential and the server credential to the providing unit  153  via the local network  101 , thus requesting the function access (step S 127 ). Subsequently, the providing unit  153  authorizes the user credential and the server credential. In the event that the providing unit  153  succeeds in the authorization, the providing unit  153  provides a function of the target to be accessed to the access device  110  through the accessing unit  117  (steps S 129  and S 131 ). 
       FIG. 4  is a flowchart illustrating the procedure of the function access process in the access system  100  according to the first embodiment. 
     First, the access device  110  determines whether or not the storage unit  115  stores the user credential (step S 140 ). If the user credential is not stored (No in step S 140 ), the first obtaining unit  111  obtains the user credential from the access target device  150  (step S 142 ). The access device  110  stores the user credential in the storage unit  115 . On the other hand, if the user credential is stored (Yes in step S 140 ), the process of step S 142  is not executed. 
     Subsequently, the access device  110  determines whether or not the storage unit  115  stores the server credential (step S 144 ). If the server credential is not stored (No in step S 144 ), the second obtaining unit  113  obtains the server credential from the server  130  (step S 146 ). The access device  110  stores the server credential in the storage unit  115 . On the other hand, if the server credential is stored (Yes in step S 144 ), the process of step S 146  is not executed. 
     The obtaining order of the user credential and the server credential may be the user credential and the server credential in that order as described above, or may be the server credential and the user credential in that order. The user credential and the server credential may be obtained at the same time. 
     Subsequently, the access device  110  obtains the user credential and the server credential from the storage unit  115 . The accessing unit  117  attempts the function access to the access target device  150  by using the user credential and the server credential (step S 148 ). 
     When the function access succeeds (Yes in step S 150 ), the function of the access target device  150  is provided to the access device  110 . On the other hand, when the function access fails (No in step S 150 ), lifetime of the user credential or the server credential is likely to be expired. In view of this, the access device  110  destroys the user credential and the server credential in the storage unit  115  (step S 152 ). The process returns to step S 140 , and then retries obtaining the user credential and the server credential. 
     The process may only destroy a credential with expired lifetime among the user credential and the server credential, and retry obtaining the credential with expired lifetime. When the owner of the access target device  150  does not explicitly cancel the authorization (approval) through the user authorization screen or a similar unit, the first authorizing unit  151  may reissue the user credential without authorization by the owner. When the owner of the access target device  150  explicitly cancel the authorization (approval) through the user authorization screen or a similar unit, the first authorizing unit  151  may issue an error without authorization by the owner (does not need to reissue the user credential). 
     As described above, with the first embodiment, the access target device  150  provides the user authorization, thus eliminating the need for user management in the server  130 . This ensures the access authorization without the user management in the server  130 . Especially, the first embodiment executes the user authorization of the access device  110  in the access target device  150 . This provides the user authorization without providing the user information outside, thus improving security. 
     While in the first embodiment, the access device  110  and the access target device  150  are coupled to the server  130  via the local network  101  and the external network  102 , the configuration is not limited to this. The access device  110  may be coupled to the server  130  not via the local network  101  but via the external network  102 . For example, the access device  110  may be coupled to the server  130  via two external networks  102 . In this case, the two external networks  102  are, for example, the external network  102 , which couples the access device  110  to the Internet, and the Internet. In this case, the second obtaining unit  113  of the access device  110  communicates with the server  130  not via the local network  101  but via the external network  102 . 
     Second Embodiment 
     In a second embodiment, a description will be given of an example where an application (hereinafter referred to as “an app”) performs the function access. Difference from the first embodiment will be mainly described below. Like names and reference numerals designate elements with functions corresponding or similar to those of the first embodiment, and therefore such elements will not be further elaborated here. 
       FIG. 5  is a block diagram illustrating an exemplary access system  200  according to the second embodiment. As illustrated in  FIG. 5 , the access system  200  in the second embodiment further includes a delivery device  270 . An access device  210  in the second embodiment further includes an execution unit  221  and a transferring unit  223 . 
     The delivery device  270  is coupled to the access device  210  via the external network  102  and the local network  101 . 
     The delivery device  270  delivers an app to the access device  210 . The delivery device  270  is achieved by a hardware configuration with an ordinary computer. The ordinary computer includes a control unit such as a CPU, a storage device such as a ROM and a RAM, an external storage device such as an HDD and an SSD, a display unit such as a display device, various input devices, and a communication I/F such as a NIC. While in the second embodiment, the app delivered by the delivery device  270  is a Web app that is executed on a browser and the delivery device  270  is a Web server on the Internet, the configuration is not limited to this. 
     The delivery device  270  includes a delivery unit  271  as illustrated in  FIG. 5 . The delivery unit  271  is achieved by, for example, execution of a program in a processor such as a CPU, or by software. 
     The delivery unit  271  delivers an app, which performs the function access, to the access device  210  via the external network  102  and the local network  101 . 
     The execution unit  221  and the transferring unit  223  in the access device  210  are achieved by, for example, execution of a program in a processor such as a CPU, or by software. While in the second embodiment, the execution unit  221  and the transferring unit  223  perform functions of the web browser, the configuration is not limited to this. 
     The execution unit  221  executes the app delivered by the delivery device  270 . Specifically, the execution unit  221  executes a Web app delivered by the delivery device  270 . For example, the execution unit  221  performs rendering of HyperText Markup Language (HTML) and JavaScript (registered trademark), so as to operate the Web app on the web browser. 
     The transferring unit  223  transfers a first authorization from the first obtaining unit  111  to the second obtaining unit  113 . Specifically, the transferring unit  223  transfers the user credential obtained by the first obtaining unit  111  to the second obtaining unit  113  such that the Web app does not recognize the user credential. When the second obtaining unit  113  obtains a second authorization in advance, the transferring unit  223  may transfer the second authorization from the second obtaining unit  113  to the first obtaining unit  111 . Specifically, the transferring unit  223  transfers the server credential obtained by the second obtaining unit  113  to the first obtaining unit  111  such that the Web app does not recognize the server credential. 
     The first obtaining unit  111  obtains the first authorization in accordance with an instruction from the Web app. In the second embodiment, the first obtaining unit  111  displays the user authorization screen on the web browser of the access device  210 . Similarly to the first embodiment, the first authorizing unit  151  may display the user authorization screen. 
       FIG. 6  is a diagram illustrating an exemplary user authorization screen according to the second embodiment. In the example of  FIG. 6 , when the owner of the access target device  150  selects a function to authorize the Web app to access the access target device  150  by using a checkbox  20  and then clicks an authorization button  21 , the first obtaining unit  111  receives the authorization operation of the owner and then requests the user credential from the first authorizing unit  151 . On the other hand, when the owner clicks a rejection button  22  and the first obtaining unit  111  receives the rejection operation of the owner, the first obtaining unit  111  does not request the user credential from the first authorizing unit  151 . 
     When the second obtaining unit  113  obtains the second authorization in advance, the first obtaining unit  111  may transmit the second authorization transferred by the transferring unit  223  to the access target device  150  and then obtain the first authorization, which doubles as the second authorization, from the access target device  150 . In this case, the first obtaining unit  111  may pass the first authorization, which doubles the second authorization, to the Web app. The first authorization, which doubles as the second authorization, is the encrypted second authorization for example. 
     The second obtaining unit  113  transmits the first authorization transferred from the transferring unit  223  to the server  130 , and obtains the second authorization, which doubles as the first authorization, from the server  130 . The second authorization, which doubles as the first authorization, is the encrypted first authorization for example. The second obtaining unit  113  passes the second authorization, which doubles the first authorization, to the Web app. 
     In the case where the second obtaining unit  113  obtains the second authorization in advance, the second obtaining unit  113  may obtain the second authorization based on an instruction from the Web app. 
     The accessing unit  117  employs the second authorization, which doubles as the first authorization, passed from the Web app so as to perform the function access. However, in the case where the accessing unit  117  is able to obtain the second authorization, which doubles as the first authorization, from the second obtaining unit  113  not through the Web app, the accessing unit  117  directly obtains the second authorization from the second obtaining unit  113 . 
     In the case where the second obtaining unit  113  obtains the second authorization in advance, the accessing unit  117  may employ the first authorization, which doubles as the second authorization, passed from the Web app so as to perform the function access. However, in the case where the accessing unit  117  is able to obtain the first authorization, which doubles as the second authorization, from the first obtaining unit  111  not through the Web app, the accessing unit  117  directly obtains the first authorization from the first obtaining unit  111 . 
       FIG. 7  is a sequence diagram illustrating a procedure of the function access process executed in the access system  200  according to the second embodiment. 
     First, the execution unit  221  requests the Web app, which performs the function access, from the delivery unit  271  via the local network  101  and the external network  102  (step S 201 ). For example, the execution unit  221  accesses a uniform resource locator (URL) of the delivery unit  271  (a Web server) from the web browser of the access device  210 , so as to request the Web app. Subsequently, the delivery unit  271  delivers the requested Web app to the execution unit  221  via the external network  102  and the local network  101  (step S 203 ). Subsequently, the execution unit  221  executes the Web app delivered from the delivery unit  271  (step S 205 ). Accordingly, the Web app operates on the web browser of the access device  210 . 
     Subsequently, the Web app requests the accessing unit  117  to perform the function access (step S 207 ). For example, the Web app calls JavaScript API (the app Program Interface) to perform the function access, and then requests the accessing unit  117  to perform the function access. Subsequently, the accessing unit  117  attempts to access the function of the access target device  150  via the local network  101  (step S 209 ). For example, the accessing unit  117  transmits an HTTP request to the providing unit  153  (a Web server), and then attempts to access the function of the access target device  150 . The user credential and the server credential are not obtained at this point yet. Accordingly, the providing unit  153  transmits an error (rejection of the function access) to the accessing unit  117  via the local network  101  (step S 211 ). Subsequently, the accessing unit  117  in turn returns the error to the Web app (step S 213 ). 
     The user credential and the server credential are not stored in the storage unit  115  at step S 207 . In view of this, steps S 207  to S 213  may be omitted if it is preliminary known that the Web app needs the user credential and the server credential to perform the function access. The storage unit  115  in the second embodiment may employ, for example, Cookie, WebSQL, WebStorage, IndexedDB, or a similar storage. The user credential and the server credential are not stored in the storage unit  115  at step S 103  yet. In view of this, the accessing unit  117  may return the error to the Web app without attempting the function access. Accordingly, steps S 209  and S 211  may be omitted. 
     Subsequently, the Web app redirects the web browser of the access device  210  to a URL of the first authorizing unit  151  (a Web server). The redirection cancels the Web app that is being displayed or to be displayed on the web browser, and replaces the access with an access to another URL. The URL of the first authorizing unit  151  may be preliminarily stored in the access device  210 , or may be obtained via a network, for example, when obtaining the Web app. Additionally, the URL of the first authorizing unit  151  may be obtained by a method for detecting equipment or service such as UPnP, mDNS, NetBIOS at a timing when the URL is redirected. 
     Subsequently, the first authorizing unit  151  transmits information for displaying the user authorization screen in  FIG. 6  to the first obtaining unit  111  as an HTTP response to the redirection. Accordingly, the first obtaining unit  111  displays the user authorization screen in  FIG. 6  on the web browser of the access device  110 . The Web app assigns an application ID of the Web app when redirecting the web browser. Accordingly, the first authorizing unit  151  may include information related to the Web app such as a name of the Web app and a function name of an access target in the information for displaying the user authorization screen. This consequently allows the first obtaining unit  111  to display the name of the Web app, the function name of the access target, and similar information on the user authorization screen as illustrated in  FIG. 6 . While the app ID is preferred to have signature of a third party or similar information to prevent impersonation, this is not mandatory. 
     The information related to the Web app may be preliminarily stored in the access target device  150  as information associated with the app ID. Alternatively, the information related to the Web app may be obtained from an app ID management server (not shown) or a similar server by the access target device  150  through communication when the access target device  150  first connects to a network, configures initial setting, requests the user credential, issues the user credential, or executes a similar process. If the Web app has assigned the information related to the Web app when redirecting the web browser, the access target device  150  may employ the assigned information related to the Web app. 
     Subsequently, in the event that the owner of the access target device  150  perform the authorization operation through the user authorization screen in  FIG. 6 , the first obtaining unit  111  receives this operation as a request for obtaining the user credential (step S 215 ). The first obtaining unit  111  then transmits an HTTP request to the first authorizing unit  151 , thus requesting the user credential (step S 217 ). Subsequently, the first authorizing unit  151  transmits the user credential to the first obtaining unit  111  as an HTTP response (step S 219 ). At this time, the first authorizing unit  151  instructs the first obtaining unit  111  to employ the transferring unit  223 . For example, the first authorizing unit  151  provides an HTTP response of the first authorizing unit  151  as a redirection to the URL of the second authorizing unit  131  (a Web server) so as to instruct the first obtaining unit  111  to employ the transferring unit  223 . Subsequently, in the event that the first obtaining unit  111  receives the user credential along with the instruction indicative of use of the transferring unit  223 , the first obtaining unit  111  passes the user credential to not the Web app but the transferring unit  223  (step S 221 ). The transferring unit  223  passes the user credential to the second obtaining unit  113  so as to request obtainment of the server credential (step S 223 ). This avoids notifying the Web app about the user credential that is secret information, thus improving safety. 
     On the other hand, in the event that the owner of the access target device  150  performs the rejection operation through the user authorization screen in  FIG. 6 , the first obtaining unit  111  does not request the user credential from the first authorizing unit  151 , and the first authorizing unit  151  in turn does not transmit the user credential to the first obtaining unit  111 . At this time, the web browser of the access device  210  redirects the URL of the first authorizing unit  151  to the URL of the delivery unit  271 . This consequently notifies the Web app about the error. 
     Subsequently, the second obtaining unit  113  transmits the user credential and access device information to the second authorizing unit  131  via the local network  101  and the external network  102 , thus requesting the server credential (step S 225 ). For example, the second obtaining unit  113  transmits the user credential and access device information to the second authorizing unit  131  as the HTTP request, thus requesting the server credential. 
     Subsequently, in the event that the second authorizing unit  131  authorizes the access device information and succeeds in the authorization, the second authorizing unit  131  generates the server credential, which doubles as the user credential (hereinafter referred to as “a combined user credential and server credential”). Subsequently, the second authorizing unit  131  transmits the combined user credential and server credential to the second obtaining unit  113  via the external network  102  and the local network  101  (step S 227 ). The second authorizing unit  131  stores, for example, a secret key corresponding to granularity of the access device information. The second authorizing unit  131  encrypts the user credential with the secret key, thus generating the combined user credential and server credential. A public key, which is paired with the secret key, may be preliminarily stored in the access target device  150 . Alternatively, the public key may be obtained from the second authorizing unit  131  or a similar unit by the access target device  150  through communication when the access target device  150  first connects to a network, configures initial setting, requests the user credential, issues the user credential, or executes a similar process. 
     Subsequently, the second obtaining unit  113  returns the combined user credential and server credential to the Web app through the transferring unit  223  or a similar unit (steps S 229  to S 233 ). The Web app stores the combined user credential and server credential in the storage unit  115 . 
     Subsequently, the Web app obtains the combined user credential and server credential from the storage unit  115 , and then requests the accessing unit  117  to perform the function access again (step S 235 ). Subsequently, the accessing unit  117  transmits the combined user credential and server credential to the providing unit  153  via the local network  101 , thus requesting the function access (step S 237 ). Subsequently, the providing unit  153  employs the public key to decrypt the combined user credential and server credential, and then extracts the user credential, so as to authorize the user credential. Success of the authorization of the user credential means a success of the authorization of the server credential. Accordingly, the providing unit  153  provides the Web app with a function of the target to be accessed through the accessing unit  117  (steps S 239  and S 241 ). 
     The user credential and the server credential may be obtained by a method similar to the first embodiment. 
       FIG. 8  is a flowchart illustrating an exemplary procedure of the function access process in the access system  200  according to the second embodiment. 
     First, the Web app determines whether or not the storage unit  115  stores the combined user credential and server credential (step S 250 ). If the combined user credential and server credential are not stored (No in step S 250 ), the first obtaining unit  111  obtains the user credential from the access target device  150  (step S 252 ). The transferring unit  223  transfers the user credential from the first obtaining unit  111  to the second obtaining unit  113 . The second obtaining unit  113  transmits the user credential to the server  130  to obtain the combined user credential and server credential from the server  130  (step S 254 ). On the other hand, if the combined user credential and server credential are stored (Yes in step S 250 ), steps S 252  and S 254  are not executed. 
     Subsequently, the Web app obtains the combined user credential and server credential from the storage unit  115 . Then, the accessing unit  117  attempts the function access to the access target device  150  by using the combined user credential and server credential (step S 256 ). 
     When the function access succeeds (Yes in step S 258 ), the function of the access target device  150  is provided to the Web app. On the other hand, when the function access fails (No in step S 258 ), lifetime of the user credential or the server credential is likely to be expired. Accordingly, the Web app destroys the combined user credential and server credential in the storage unit  115  (step S 260 ). The process returns to step S 250 , and then retries obtaining the user credential and the server credential. 
     For example, in the case where lifetime of the server credential is expired, the server credential is encrypted with an old secret key. Subsequently, the combined user credential and server credential is decrypted with a new public key. Accordingly, the combined user credential and server credential fails in decrypting. Thus, the function access fails. For example, in the case where lifetime of the user credential is expired, the user credential is obtained by decrypting the combined user credential and server credential and then fails in the authorization. Thus, the function access fails. 
     As described above, even in the case where the Web app performs the function access, the second embodiment hides the user credential from the Web app, which possibly leaks the secret information, thus ensuring improved security. Especially, even in the case where the Web app is an unauthorized app, the second embodiment is able to keep the user credential secret, thus ensuring improved security. 
     Even in the case where the Web app performs the function access, the second embodiment is able to hide the server credential from the Web app, which might leak the secret information. 
     Third Embodiment 
     In a third embodiment, a description will be given of an example where an authorization device different from the access target device performs the user authorization. Difference from the second embodiment will be mainly described below. Like names and reference numerals designate elements with functions corresponding or similar to those of the second embodiment, and therefore such elements will not be further elaborated here. 
       FIG. 9  is a block diagram illustrating an exemplary access system  300  according to the third embodiment. As illustrated in  FIG. 9 , the access system  300  in the third embodiment further includes a plurality of access target devices  350 - 1  to  350 - n  (n≧2) and an authorization device  390 . 
     The access device  210 , the plurality of access target devices  350 - 1  to  350 - n , and the authorization device  390  are coupled together via the local network  101 . The plurality of access target devices  350 - 1  to  350 - n  may be coupled to the authorization device  390  via a network other than the local network  101 . The number of the access target device may be one. 
     The plurality of access target devices  350 - 1  to  350 - n  each have a function of a target to be accessed by the access device  210 . The plurality of access target devices  350 - 1  to  350 - n  are achieved by, for example, a home appliance (a digital television, an air conditioner, a lighting, a refrigerator, a microwave oven, or a similar appliance), a personal computer, a hard disk recorder, a smart phone, a mobile phone, a tablet terminal, an electric vehicle, an electric vehicle charger, a fuel cell, a solar cell, a storage battery, a sensor, or a similar device. 
     The plurality of access target devices  350 - 1  to  350 - n  includes respective providing units  353 - 1  to  353 - n  as illustrated in  FIG. 9 . The providing units  353 - 1  to  353 - n  are similar to the providing unit  153  in the first and second embodiments, and will not be further elaborated here. 
     The authorization device  390  performs the user authorization to allow the access device  210  to access the functions of the plurality of access target devices  350 - 1  to  350 - n . The authorization device  390  is achieved by, for example, a digital television, a personal computer, a hard disk recorder, a smart phone, a mobile phone, a tablet terminal, a charge management unit, a home energy management server (HEMS) as a communication device that controls equipment, or similar device. The authorization device  390  is achieved by a hardware configuration with an ordinary computer. This ordinary computer includes a control unit such as a CPU, a storage device such as a ROM and a RAM, an external storage device such as an HDD and an SSD, a display unit such as a display device, various input devices, and a communication I/F such as a NIC. 
     As illustrated in  FIG. 9 , the authorization device  390  includes a first authorizing unit  391  (a typical authorizing unit) and a detecting unit  393 . 
     The detecting unit  393  detects change (for example, participation and disengagement) in connection of the plurality of access target devices  350 - 1  to  350 - n  with the local network  101 . 
     The first authorizing unit  391  is similar to the first authorizing unit  151  in the first and second embodiments. However, in the event that the detecting unit  393  detects any change in connection of the plurality of access target devices  350 - 1  to  350 - n  with the local network  101 , the first authorizing unit  391  invalidates the issued user authorization. For example, in the event that the detecting unit  393  detects connection of a new access target device with the local network  101 , the first authorizing unit  391  invalidates an issued user credential. In view of this, if the accessing unit  117  performs the function access using this user credential, the function access fails. 
     The access system  300  operates basically similarly to operation in the second embodiment. However, the target of the function access by the accessing unit  117  is any of the plurality of access target devices  350 - 1  to  350 - n . The target of the first obtaining unit  111  to obtain the user credential is the authorization device  390 . 
     In the third embodiment, the first obtaining unit  111  displays a user authorization screen in  FIG. 10 .  FIG. 10  is a diagram illustrating an exemplary user authorization screen according to the third embodiment. In the example of  FIG. 10 , when the owner of the access target device  150  selects a home appliance (an access target device) where the Web app is authorized to access using a checkbox  30  and clicks an authorization button  31 , the first obtaining unit  111  receives the authorization operation of the owner. Subsequently, the first obtaining unit  111  requests the user credential from the first authorizing unit  391 . On the other hand, when the owner clicks a rejection button  32  and then the first obtaining unit  111  receives the rejection operation of the owner, the first obtaining unit  111  does not request the user credential from the first authorizing unit  391 . 
     In the event that the detecting unit  393  detects a new connection of the access target device with the local network  101 , the first authorizing unit  391  invalidates the issued user credential. Accordingly, in the event that the accessing unit  117  performs the function access using this user credential, this function access fails. This allows the first obtaining unit  111  to request the first authorizing unit  391  to issue the user credential again. In this respect, the user authorization screen displayed by the first obtaining unit  111  includes the new home appliance (the access target device) detected by the detecting unit  393  as illustrated in  FIG. 11 . This allows obtaining the user authorization for the new home appliance (the access target device). 
     In the case where the plurality of access target devices  350 - 1  to  350 - n  are coupled to the authorization device  390  via a network other than the local network  101 , the accessing unit  117  accesses the functions of the plurality of access target devices  350 - 1  to  350 - n  through the authorization device  390 . In this case, a communication protocol between the accessing unit  117  and the authorization device  390  employs, for example, an HTTP or a similar protocol. A communication protocol among the authorization device  390  and the plurality of access target devices  350 - 1  to  350 - n  employs, for example, ECHONET Lite, SEP2, or a similar protocol. 
     In this case, the authorization device  390  is able to serve as a part of functions of the providing units  353 - 1  to  353 - n . More specifically, the authorization device  390  receives the first authorization and the second authorization from the access device  210  instead of the providing units  353 - 1  to  353 - n . The authorization device  390  then authorizes the received first authorization and second authorization. In this case, the providing units  353 - 1  to  353 - n  do not authorize the first authorization and the second authorization. The providing units  353 - 1  to  353 - n  simply provide functions with the access device  210  only, based on the authorization result of the authorization device  390 . The authorization device  390  may authorize one of the first authorization and the second authorization instead of authorizing both of them. 
       FIG. 12  is a schematic diagram illustrating an example of the plurality of access target devices  350 - 1  to  350 - n  in the case where the access system  300  is applied to a smart grid system  400  according to the third embodiment. In this case, the plurality of access target devices  350 - 1  to  350 - n  correspond to a bathroom  401 , a light  402 , an air conditioner  403 , a digital television  404 , a refrigerator  405 , a storage battery  406 , a fuel cell  407 , a solar panel  409 , and a similar device. 
     As described above, with the third embodiment, in the event that a new access target device is detected, the issued user credential is invalidated. This avoids the function access to the new access target device without the user authorization for the new access target device. 
     Modification 
     While in each aforementioned embodiment, the access device obtains the user credential via the local network, the method for obtaining the user credential is not limited to this. For example, the access device may obtain the user credential from the access target device through a QR code (registered trademark), near field communication, the media, or a similar method. The access device may obtain the user credential by user&#39;s manual input. In these cases, the access device reads the QR code, the access device is moved to the access target device in a position where near field communication is possible, or the user credential is manually input. These allow determining that the user intends to perform authorization. 
     In the first embodiment, the access target device may provide the access device with a function of a target to be accessed, similarly to the third embodiment. The authorization device may allow the owner of the access target device to authorize the access device to access the function of the access target device. 
     Hardware Configuration 
     A program, which is executed by the access device in each embodiment and modification described above, is provided as a file in an installable format or an executable format. This program is stored in a computer-readable media such as a CD-ROM, a CD-R, a memory card, a DVD, and a flexible disk (FD). 
     The program, which is executed by the access device in each embodiment and modification described above, may be stored on a computer coupled to a network such as the Internet, and may be downloaded via the network. The program, which is executed by the access device in each embodiment and modification described above, may be distributed via a network such as the Internet. 
     The program, which is executed by the access device in each embodiment and modification described above, may be preliminarily stored in a ROM or a similar storage. 
     The program, which is executed by the access device in each embodiment and modification described above, has a module configuration to implement the respective units described above on a computer. As actual hardware, for example, the control unit is configured to read out and execute the program in the storage unit from the external memory so as to implement the respective units on the computer. 
     Each embodiment and modification eliminates user management in the server. 
     For example, the respective steps in the flowchart of each of the aforementioned embodiments may be executed in a modified execution order, executed at the same time, or executed in a different execution order for each execution insofar as the execution is compatible with the respective steps. 
     While certain embodiments have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions. Indeed, the novel embodiments described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the embodiments described herein may be made without departing from the spirit of the inventions. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the inventions.