W3C Device API is a technique for accessing an internal resource (function or information) of a terminal, such as PC and smartphone, via a Web page on a site operated by a service provider. A typical example is Geolocation API that accesses GPS information in a smartphone to make it possible to provide services based on locational information. As an example of the Device API technique (here, indicates a technique that uses an internal function of a terminal, which basically cannot be used from a Web page), a technique is known in which UPnP function that realizes Plug and Play of a rooter and an AV device on a home network is used from a Web page. When this technique is used, it is possible to realize mash-up (cooperation) of a Web page provided by a service provider and a home appliance resource on a home network.
A Web browser acquires components included in Web contents from a site on a network and displays the Web contents. In this case, an optimization method is known in which only the data to be displayed is acquired from a server and layout information and templates of static image data are previously cached.
However, when the technique described above is used, the service provider directly accesses devices on a home network (via a Web page), so that there are some problems.
First, the service has to know the presence of a device to be accessed (a resource providing apparatus). In other words, a device including Web browser, such as a PC and a smartphone, has to disclose device information on the home network to the service.
Second, the service has to use access methods that may be different for each device on the home network.
The above problems will be described with reference to a specific example. For example, a case is considered in which a service provider operates an electronic program guide service on the Internet. It is assumed that a “recording reservation button” is set in each program field in the displayed electronic program guide on a Web page of the electronic program guide service and when a user displays the electronic program guide service on a Web browser in a home PC and presses the “recording reservation button”, the user can make a recording reservation of the program on a digital TV in home.
At this time, when realizing this use case by the technique described above, a program (JavaScript script code) embedded in the Web page of the electronic program guide service directly uses a function of DLNA (Digital Living Network Alliance) from the Web page. Therefore, the presence of the digital TV on the home network on which the PC is installed is detected by DLNA Discovery, detailed information of the detected digital TV is directly acquired from the digital TV by DLNA Description, and a DLNA Action command for the recoding reservation is transmitted, so that the recording reservation from the Web page is realized.
However, in the series of sequences, the program provided by the service provider can easily acquire a list of devices located on user's home network and detailed information of the devices. In other words, if a logic that the program uploads acquired information to a server of the service provider is embedded, personal information (what devices the user has, and the like) is leaked to the service provider.
Further, if devices that use other protocols such as ECHONET in addition to DLNA are to be operated, the above-described program has to include codes compatible with a plurality of protocols. In particular, the types of devices present on home networks are unknown, so that the service provider has to handle all transmission protocols and further all authentication/permission methods that may be supported by the devices. Thus, the service provider has to spend high development costs.
As described above, in the conventional art, there is a problem that the service provider has to know the presence of the devices to be accessed.
USPTO Backgrounds
USPTO Backgrounds