The present invention relates to an apparatus for intermediating a plurality of network operators and one or more developers.
Many telecom operators and internet service providers are deploying gateways such as DSL modems, O/E converters, PPPoE terminators in their networks to interface with the users' home networks. The traditional function of the gateway is to manage the protocol conversion for devices which are not able to access the network without mediation by the gateway.
Those gateways are now getting to include software execution environment such as OSGi framework that is a dynamic module system for Java. OSGi framework makes it possible to add/remove software modules on it dynamically without restarting Java virtual machine. Such a software module is called a bundle in OSGi terminology. By combining a remote management protocol, OSGi framework is capable of being remotely managed and dynamically deploying new software modules on demand.
By utilizing such a software execution environment, it is possible for a network operator to run software on a gateway which discovers devices in a personal network and exposes control API for those devices so that the network operator can access and control the devices for the user. That means that, by leveraging managed gateways, network operators can offer various kinds of caretaking services which are achieved by monitoring and controlling devices in the personal network, e.g. WiFi access point auto configuration service, home automation and energy management for a home. When the operators try to offer such services, controlling and monitoring programs for wide range of devices are required since a personal network can include wide range of devices which may use different set of protocols. Some devices support standard protocols which can be used for remote control, such as UPnP. However, there are significant amount of devices which need to use proprietary protocols to control and configure. For example, for remotely configuring a Wifi access point which does not support UPnP, but only supports Web GUI, the gateway needs to implement a set of commands which are based on invoking specific HTTP URLs.
For a single network operator, it is not realistic to implement such protocol specific communication software or device specific control program for every device in the personal networks. Such kind of computer program is called device specific software (DSS). Although one solution would be asking third party to develop DSS, it is costly. If multiple network operators form a federation, creates specifications for DSS together and orders third party to make the DSS, the cost for each operator might be reduced by splitting it. According to such an idea for federated market place, US2008103795 introduces federated market place for advertisement. However, making such a federation creates more issues such as: making an agreement and specifications between multiple network operators require a lot of cost and effort; and each network operator needs to expose the requirements to other network operators, that is, network operators in the federation become able to guess what the other network operators are going to deliver to the users.
Therefore, it is desired to provide a technique in which the developers can determine the necessity and requirements for a computer program required by the network operators while each network operator conceals requirements for the computer program.
According to an aspect of the invention, an apparatus for intermediating a plurality of network operators and one or more developers is provided. The apparatus includes an obtaining unit for obtaining a requirement about a computer program required by each network operator, an integration unit for integrating mutually-related requirements among the obtained requirements into one requirement, a generation unit for generating information about the necessity for development of a computer program implementing the integrated requirement, and a presentation unit for presenting the one or more developers with the integrated requirement and the information about the necessity.
Further features of the present invention will become apparent from the following description of exemplary embodiments with reference to the attached drawings.
Embodiments of the present invention will now be described with reference to the attached drawings. Each embodiment described below will be helpful in understanding a variety of concepts from the generic to the more specific. It should be noted that the technical scope of the present invention is defined by claims, and is not limited by each embodiment described below. In addition, not all combinations of the features described in the embodiments are always indispensable for the present invention.
The operator network 101a is connected with personal networks 103. The personal network 103 is a network in which devices around an owner of the personal network 103 are interconnected with each other to compose a logical network. The devices are exposed to third party service providers and other users' personal networks through wide area network. The personal network 103 is an example of a local network for which the present invention applies. Other examples of the local network are a local area network (LAN), a personal area network (PAN), a car network, and so on. The devices in the personal network 103 are called personal network elements (PNEs) 106. The personal network 103 also comprises a gateway (G/W) 105 though which the PNEs 106 and the operator network 101a communicate with each other. The gateway 105 exposes control API for controlling the PNEs 106.
The operator network 101a comprises a Personal Network Application Server (PNAS) 104. The PNAS is an apparatus used as a central point to retrieve and disseminate context information of the PNEs 106, which includes device presence and capabilities information.
The network operator A offers various services for a user of the personal network 103 by monitoring and controlling the PNEs 106. Examples of the services offered by the network operator A is:
The network operator A has a service description for each service. The service description describes operations for performing a corresponding service. An example of a service description will be described later. The network operator A provides the service descriptions to the FBS 100 in order to ask to create a computer program (DSS) required to perform the operation for the PNEs 106. According to this embodiment, a requirement in a service description is described in the form of API. However, the present invention applies to a requirement described in any form even if the developers 102 can develop a computer program in reference to the requirement.
The FBS 100 intermediates the network operators and the developers 102. The FBS 100 obtains service descriptions from the network operators. It is reasonably assumed that network operators require the same or similar API for devices in the same category since each device only has a specific set of functionalities, and thus lists of required API from network operators tend to overlap. Therefore, the FBS 100 integrates the overlapped APIs into one API. It can easily happen that different network operators have slightly different requirements for each API, such as unit of input and output values, path name. The FBS 100 solves the issue by providing template APIs to the network operators, as described in detail later.
The developer 102a develops computer programs presented by the FBS 100. The developer 102a may be a third party developer, an open source developer, or a non-employed programmer.
In step S301, the collection unit 211 collects statistics about the PNEs 106 from the PNASs 104 in the operator networks 101. The collection unit 211 registers the collected statistics in the statistics database in the storage device 204. The statistics may include the number of devices included in the personal networks 103 connected to each operator network 101, for each device type.
In step S302, the obtaining unit 209 obtains a service description from the network operator A. As described above, the service description includes requirements for DSSs in the form of API. The network operator A prepares a service description prior to step S302, in a format agreed with the owner of the FBS 100. The presenting unit 210 may present template APIs to the network operator A in order to assist the network operator A in the creation of a service description.
The network operator A may describe a service description using the list 400 of template APIs. FIG. 5 illustrates an exemplary service description 500. Each entry of the service description 500 defines a requirement for performing a certain service. The column “SERVICE NAME” 501 describes a name of the service which the network operator A performs. The columns 502, 503 are the same as the columns 401, 403 in
In step S302, the obtaining unit 209 stores the obtained service description in the storage device 204. The service descriptions obtained from the network operators are maintained as a service description list.
In step S304, the integration unit 205 integrates the required APIs which are related mutually into one API. According to this embodiment, in order to integrate APIs, the integration unit 205 compares the required API with the template API. When two or more required APIs in the service description list 600 correspond to the same template API, the integration unit 205 determines that these required APIs are related mutually and integrates these required API into one integrated API. For example, both the first and fifth entries in the service description list 600 correspond to the first entry in the template API list 400, and thus the integration unit 205 integrates these required APIs.
The integration unit 205 registers the integrated API in the required DSS list.
In step S306, the generation unit 206 generates information about the necessity for development of a DSS implementing the integrated API. According to this embodiment, the generation unit 206 determines the necessity for each device type stored in the statistics database. The generation unit 206 registers every device type for each integrated API, as shown in
In step S308, the presentation unit 210 presents the developers 102 with the required DSS list 700 via the developer I/F 207. It should be noted that the required DSS list 700 does not show any information about the individual network operator. That is, each network operator can conceal its service descriptions and the number of devices for which the network operator provides services, from other network operators and the developers 102.
In step S309, the developer 102a develops a DSS with reference to the required DSS list 700. The developer 102a would develop a DSS with higher necessity. In step S310, the obtaining unit 209 obtains a developed DSS from the developer 102a via the developer I/F 207. In step S311, the obtaining unit 209 forwards the obtained DSS to the validation unit 208.
In step S312, the validation unit 208 verifies the obtained DSS. For example, the validation unit 208 checks whether the DSS includes a malicious code, using sandbox technique in Java. After checking the DSS, the validation unit 208 registers the DSS in the DSS repository. The validation unit 208 may not check the DSS against specific devices because it is up to network operators how to test the DSS before widely deploying the DSS. In step S313, the validation unit 208 notifies the presentation unit 210 that the DSS repository is updated.
In step S314, the presentation unit 210 presents the updated DSS repository to the network operators via the operator I/F 203. In step S315, the network operator A requests a DSS in the DSS repository in order to, for example, deliver the DSS to the gateway 105 or put its own Application Store. The FBS 100 may charge the network operator for the DSS.
In step S316, the operator I/F 203 notifies the integration unit 205 of which DSS is requested from which network operator A.
In step S317, the integration unit 205 creates an adaptation program. As described above, the API in the service description 500 and the API in the required DSS list 600 are different. That is, the developed DSS does not work without an adaptation program. For example, when the network operator A requests a DSS for the API whose name is “Get SSID”, the integration unit 205 refers the service description list 600 and finds the required API obtained from the network operator A. Then, the integration unit 205 creates an adaptation program 800 such as described in
In step S318, the integration unit 205 notifies the presentation unit 210 that the adaptation program is created.
In step S319, the presentation unit 210 provides the requested DSS and the corresponding adaptation program with the network operator A via the operator I/F 203.
According to this embodiment, the developers can determine the necessity for a computer program required by the network operators while each network operator conceals requirements for the computer program. Each network operator can lower costs for obtaining a computer program. Each network operator does not have to share requirements with each other or co-develop a specification for a particular DSS together.
While the present invention has been described with reference to exemplary embodiments, it is to be understood that the invention is not limited to the disclosed exemplary embodiments. The scope of the following claims is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures and functions.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/JP2010/053013 | 2/19/2010 | WO | 00 | 8/14/2012 |