HK1161461B - Open gateway framework - Google Patents

Abstract

An open gateway framework addresses the need for efficient modularization, extension, and adaptation of device functionality, such as gateway or set top box functionally. The open gateway framework facilitates rapid third party application development on customer electronic devices, particularly for telecommunications service providers. The open gateway framework provides: portability between different devices; rapid development based on extended platform features with a custom Application Programming Interface (API); and deployment with little or no impact on device base software.

Description

Open gateway framework

Technical Field

The present disclosure relates to an architecture for a telecommunications services platform that enables more efficient modularization, control, and adaptation of services running on the platform.

Background

Digital homes and offices continue to evolve, incorporate a wider range of sophisticated devices, and become more complex. User equipment providers are constantly selling newly connected consumer electronic devices, as well as advanced and pervasive value-added services for homes and offices integrated with many different consumer electronic devices. However, digitally connected homes and offices are a complex ecosystem of service platforms, with each device having a closed overall design that prevents the rapid and efficient development and deployment of new services.

More specifically, the current application development model is a closed and custom model. Under the current model, a user device vendor designs an application, develops the application, and embeds it into a device that is typically designed and manufactured specifically for that particular vendor's device architecture. In particular, access gateways typically provide an access point for telecommunications services. Since all developments tend to be the only responsibility of the equipment provider, the telecommunication service provider does not have control over the software application lifecycle. The overall design of the access gateway makes it difficult, even for the vendor itself, to develop and deploy new services for sale in a short time.

Accordingly, there is a need for an enhanced architecture for service creation, execution, and provisioning.

Disclosure of Invention

The open gateway framework addresses the need for efficient modularity, expansion, and adaptation of device (e.g., telecommunications gateway) functionality. The open gateway framework may be implemented on other devices, such as set-top boxes or other Customer Premises Equipment (CPE). The open gateway framework facilitates rapid application development on consumer electronic devices, especially for telecommunication service providers. The open gateway framework provides portability between different devices (including access gateways and set-top boxes); rapid development of extension platform features and consistent Application Programming Interfaces (APIs) defined by helper functions through leveraging; and deployment with little to no impact on device base software, thereby greatly facilitating third party development.

The open gateway framework may be deployed as a complete architecture for application lifecycle management. The open gateway framework may include one or more of the following: the custom kernel interface layer leverages the OSGi alliance (TM) framework for service creation and execution; a management platform that can be fully integrated with a telecommunication service provider Operations Support System (OSS)/Business Support System (BSS) system; an application resource pool; and APIs for application development. The open gateway framework is remotely manageable for facilitating efficient user support. Once a telecommunication service provider integrates an open gateway framework into its devices, the telecommunication service provider is free to develop new services on those devices (and let others develop).

Other systems, methods, features and advantages will be, or will become, apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the invention, and be protected by the following claims.

Drawings

The open gateway framework may be better understood with reference to the following drawings and description. In the drawings, like reference numerals designate corresponding parts throughout the different views.

FIG. 1 shows an architecture illustrating the implementation and management of an open gateway framework;

FIG. 2 illustrates an open gateway framework management system;

FIG. 3 illustrates an apparatus including an open gateway framework services platform;

FIG. 4 illustrates another example of an open gateway framework services platform;

FIG. 5 illustrates a flow chart for creating and implementing an open gateway framework;

FIG. 6 shows a flow diagram of service management logic in an open gateway framework management system;

FIG. 7 is a flow diagram illustrating application storage logic in an open gateway framework management system;

FIG. 8 illustrates a message flow for installation of a new service initiated by a service platform through a service store;

FIG. 9 illustrates a message flow for an upgrade of a service initiated by a service platform through a service store;

FIG. 10 illustrates a message flow for installation of a new service initiated by a management system;

FIG. 11 illustrates a message flow for an upgrade of a service initiated by a management system;

FIG. 12 illustrates a message flow for offloading of services initiated by a management system;

FIG. 13 illustrates a message flow for offloading of a service initiated by a service platform;

FIG. 14 illustrates a message flow for activating and deactivating services by a management system;

FIG. 15 shows a message flow for service monitoring and service configuration by a management system;

FIG. 16 illustrates a signed packet format for communication between a management system and a service platform; and

FIG. 17 illustrates a logic flow diagram executed by a management service in a service platform.

Detailed Description

Fig. 1 shows an architecture 100 illustrating the implementation and management of an open gateway framework on various service platforms. The architecture includes an open gateway framework management system ("management system") 102. There may be any number of various devices 103 in communication with the management system 102. Fig. 1 gives three examples: telecommunications gateway 104, set top box 106, and universal telecommunications device 108. The device 103 provides telecommunication services to the terminal 110. Any device 103 may include a custom service platform (e.g., custom service platform 105). The open gateway framework described below implements the service platform 105 and may be adapted to any particular device and its hardware and software configuration. The management system 102 may also communicate with a Business Support System (BSS) 112.

The gateway may include a system that interfaces with a cellular phone, smart phone, personal data assistant, or other telecommunications device. A set-top box may include equipment provided by a cable service provider for delivering television programming, VoIP or other services to consumers in their homes or offices. As described in more detail below, the management system 102 may generally manage any device that delivers services to subscribers.

The terminal 110 may represent any consumer of telecommunication services. One example of a terminal 110 is a cellular telephone that subscribes to a Short Message Service (SMS) hosted by telecommunications gateway 104. Another example of a terminal is a digital video recorder that subscribes to a television program information service delivered by the set-top box 106.

BSS112 facilitates management of transactions by system 102. To this end, BSS112 may, for example, include: a billing system 114 and an electronic transaction system 116. BSS112 may communicate with management system 102 to accept payment information (e.g., credit or debit card information); processing a payment, credit or debit card prepaid or postpaid account; returning account balance information and payment authorization; or take other actions required by the management system 102.

For example, BSS112 supports third party purchases of additional services. Service storage server 118 may host a purchasing interface, a service catalog, and other purchasing infrastructure. Content server 120 may store services for delivery to device 103. However, the architecture 100 may be implemented in many different ways. For example, the functionality of any of the systems 102, 114, 116, 118, 120 may be implemented in fewer discrete systems (e.g., the management system 102 may perform all of the functionality), or further distributed among additional systems. Network 122 provides a communication infrastructure through which various systems and terminals can communicate and may include any combination of wired or wireless local or wide area networks, including the internet.

FIG. 2 illustrates one exemplary implementation of the management system 102. The processor 202 is connected to a communication interface 204, a memory 206, and databases 208 and 210. Service kernel database 208 and service parameter database 210 support management system 102.

The service management logic 212 coordinates the overall functionality of the management system 102. Examples of specific functions that service management logic 212 may implement are discussed below. To support the service management logic 212, the communication protocol 214 provides a message handler and interpreter for messages received at the communication interface 204. In one implementation, the communication protocol 214 may be the TR-069 communication protocol for remote management of devices, which is extended to support the functionality mentioned below.

As mentioned above, there may be multiple implementations where the management system 102 also provides service storage functionality. To this end, the management system 102 may include service storage logic 216. The service storage logic 216 may process the platform inventory 218 or other information to determine which services are available for the device that provided the platform inventory.

Fig. 3 shows a device 302 that includes an open gateway framework 304. The open gateway framework 304 provides a service platform that provides a technical solution to the technical problem of reusable services of modules that can be remotely managed. The processor 306 is coupled to a communication interface 308, a memory 310, and system resources 312, a first one of the system resources 312 being labeled as system resource 314. The system resources 312 may represent hardware or software resources present in the device 302. For example, the system resource 314 may be a hardware audio or video codec. As another example, system resource 314 may be a software processor for translating text between multiple languages or searching hundreds of cable channels for a next occurring television program.

To support the open gateway framework 304, the communication protocol 316 provides a message handler and interpreter for messages received at the communication interface 308. In one implementation, the communication protocol 316 may be the TR-069 communication protocol for remote management of devices, extended to support the functions mentioned below. To this end, the communication protocol 316 may route incoming messages from the management system 102 to the management service 334 and may facilitate the transmission of outgoing messages from the management service 334 to the management system 102.

Operating system 318 provides basic functionality to device 302. In particular, operating system 318, which includes a particular driver (e.g., driver 320), provides access to system resources 312. Local services 322 written specifically for device 302 may make calls to known functions and drivers present in operating system 318. However, such local services 322 are not easily ported between different device architectures and therefore must be rewritten if they need to be installed on different devices.

The open gateway framework 304 provides a technical solution to the technical problems of service portability and compatibility, as well as to the remote management of such services. The open gateway framework 304 serves as an abstraction layer to isolate specific hardware from exposed functions that all services have access to across open gateway frameworks installed on disparate devices. In one implementation, the open gateway framework 304 includes a kernel dynamic module system 324, optionally extended by custom kernel extensions (e.g., kernel extension 326), for implementing kernel functionality specifically tailored to the hardware/software configuration of the device 302. The kernel 324 may be, for example, an OGSi framework that provides a dynamically modular system for executing large amounts of machine-independent code, such as JAVA code. In addition, the open gateway framework 304 further includes a feature pack 328 that provides helper functions 330.

Helper functions 330 and kernel 324, including kernel extensions 326 (if present), comprise pre-designed, pre-packaged code that implements a wider range of functionality. This functionality is accessed through function calls defined by the helper functions 330 and the kernel 324, and made available (i.e., "exposed") for access by other entities (e.g., the service 332). While some function calls may not be available on all devices due to hardware or software limitations of the devices, the available set of function calls typically does not vary between open gateway frameworks. On the other hand, the manner in which function calls are translated to particular underlying system services is not changed to match a particular device and its hardware configuration. As a result, a function call set common across multiple devices provides a consistent Application Programming Interface (API) that services 332 use to implement their functionality across the multiple devices. In fig. 3, the function sets constituting the API are denoted by reference numeral 336, i.e., the API 336.

Helper functions 330 and kernel 324 translate API function calls made by services 332 into operating system, driver, or system resource specific calls (which may be proprietary and unique) for the device. Thus, each device 302 may have a particular open gateway framework 304, but services 332 written for the open gateway framework 304 need not be changed and rewritten when installed on various devices having different hardware. Instead, services 332 may be plugged directly into open gateway framework 304 through consistent API336, regardless of the specific hardware implementation of the device. Services 332 that are external to the open gateway framework 304, are not included by or are part of the open gateway framework 304, and may enable any desired processing that a device desires to provide to the terminal 110, such as SMS or MMS services, text-to-speech translation, video and voice conferencing, VoIP or cable video services, or other services.

The kernel extension 326 (if present) and the feature package 328 together form an open, custom service platform structure 331 on top of the operating system 318. The custom service platform architecture 331 is part of the open gateway framework 304 and supports highly portable custom services between different hardware as an extension of the basic functionality in the kernel 324. Fig. 3 shows several examples of such services 332. In particular, one of the services 332 is a management service 334. As explained in more detail below, the management service 334 coordinates the interaction of the devices 302 with the management system 102 so that the management system 102 can perform centralized remote control of the services running in the devices 103. The data model 338 may store service parameters for any service 332, including management services. The management service 334 may monitor, change, report, or otherwise manipulate service parameters in the database as directed by the management system 102.

The open gateway framework exposes the functionality available for services. Service developers quickly develop services that leverage the pre-designed exposed functionality implemented by helper functions 330. In turn, helper functions 330 use the kernel and kernel extensions to implement their functionality. The kernel 324 and kernel extensions 326 may invoke specific device drivers or operating system functions to perform the required processing.

Fig. 4 illustrates another example of a service platform 400 implemented by an open gateway framework 402. The open gateway framework 402 extends the OGSi kernel 404 and operating system through a custom service platform architecture 406 that includes a kernel extension 408, the kernel extension 408 including an audio driver 410, a Digital Signal Processor (DSP) driver 412, and a telephony port driver 414. Along with the kernel extensions, the custom service platform structure 406 further includes a feature pack that defines several helper functions, as explained in the helper and extension tables below.

The user interfaces 450 and 452 may provide configuration, review, and analysis functions to an administrator of the device 103. To this end, the user interfaces 450 and 452 may provide a mechanism for requesting or performing service installation, uninstallation, configuration, monitoring and activation/deactivation tasks as described in detail below with reference to FIGS. 8-15,

fig. 5 shows a flow diagram 500 for creating and implementing a new open gateway framework. Specifically, the designer obtains a list of device hardware capabilities (502). The designer may then determine a feature set exposed to the service to be inserted into the open gateway framework (504). By considering the hardware capabilities and the desired feature set, the designer generates helper functions and kernel extensions that the newly created service can call to implement its desired functionality (506).

Given the helper functionality and kernel extensions, the designer generates an open gateway framework for installation on a particular device (508). The open gateway framework may take the form of an installation package that is communicated to the device manufacturer (510). However, other forms of implementing and distributing the open gateway framework may also be employed. The device manufacturer installs the open gateway framework on its devices, for example, before shipping the devices to the customer (512). Note that this open gateway framework is typically left on the device for the lifetime of the device. However, services (e.g., management services) as well as helper and kernel extensions may be upgraded or changed so that the open gateway framework need not be completely replaced.

The device manufacturer may also install selected services, such as management service 334, obtained from the designer of the open gateway framework. In some implementations, the management service 334 may always be present and cannot be offloaded because its role is to process communications and configuration commands received from the management system 102.

FIG. 6 illustrates a flow diagram 600 of logic that may be performed by the service management logic 212. Specific message flows are discussed below. At any desired time interval, the service management logic 212 may check which services are installed on the service platform (602), such as service 332 installed on the open gateway framework 304. For each service, the service management logic 212 may determine whether there are any service parameters that need to be updated (604). To this end, the service management logic 212 may consult a service parameter database (210) reserved for each service for determining current parameter settings. When there is an update of the service parameters, the service management logic 212 retrieves the parameter update (e.g., from the parameter database 210) (606) and communicates the parameter update to the service platform (608). In particular, the service management logic 212 may pass the parameter update communication to the service management service 334, which service management service 334 in turn passes the parameter update communication to a local service that requires an update.

The service management logic 212 may also check which services are installed on the service platform (610) and check for updates (612). If there is a service change or update, the service management logic 212 may determine whether an install, uninstall, or activation/deactivation action is required. For installation, the service management logic 212 may retrieve a new service or service version (e.g., from the content server 120) (614) and communicate the new service or service version to the service platform (e.g., to the service management service 334 that performed the installation) (616). For offloading, the service management logic 212 determines services that should be removed (618) and communicates the instructions to the service platform (e.g., communicates to the service management service 334 that performs the offloading) (620). For activation or deactivation, the service management logic 212 determines the service to be activated or deactivated (622), and communicates the activation/deactivation instructions to the service platform (e.g., communicates to the service management service 334 executing the instructions) (624).

FIG. 7 presents a flow diagram 700 of application storage logic 216, which application storage logic 216 may be located in management system 102, service storage server 118, or elsewhere in architecture 100. Application store logic 216 receives device manifest 218 (702). The device manifest 218 may detail the hardware and/or software capabilities of the device. Application storage logic 216 obtains a list of available services and their hardware and/or software requirements (704) and filters the list of services for the hardware/software capabilities specified in the device manifest (706). Thus, for example, if an available service requires audio output hardware, but the device does not, the application storage logic 216 may remove the service from the list of available services.

Application storage logic 216 communicates the filtered list of services to the service platform (708) and responds to the service selection. Application storage logic 216 receives payment information, such as credit or debit card information, from the service platform (710) and attempts to validate the payment information by BSS112 (712). If the payment information is not verified, application storage logic 216 communicates an error message back to the service platform (714). Otherwise, the service delivery logic 216 returns a success message to the service platform (716) and arranges for communication of the newly purchased service to the service platform (718). In other cases, the service installation or update may be initiated by the service platform or management system 102, as described below.

The configuration message flows discussed in fig. 8-15 refer to the interaction of the device and its service platform (e.g., open gateway framework 304) with other systems including management system 102, content server 120, and service storage server 118. Configuration messages typically flow through a communication interface (e.g., communication interface 308) of a given device and are routed to a service platform (e.g., service platform 105) by a communication protocol. In particular, incoming messages may be delivered by the management system 102 directly to the management service 334 for facilitating remote management and control of the service platform. Any service platform on any device can process the configuration messages discussed below.

FIG. 8 illustrates a configuration message flow 800 for installation of a new service initiated by a service platform (e.g., service platform 105) through service store 118. Any of the message flows in the figures described below may be implemented via Remote Procedure Calls (RPCs) or other message transport mechanisms. The service platform in device 103 sends a request to purchase the application to service storage server 118 (802). The service storage server 118 notifies the management system 102(804) so that the management system 102 can maintain an updated configuration file for the services installed on the service platform. If all purchase conditions are satisfied (e.g., payment authorization and service authorization), management system 102 can communicate a download message to the service platform (806). The download message may convey download parameters that the service platform uses to obtain the purchased service, such as: file type, Uniform Resource Locator (URL) that can download the service, username and password for the download service, and file size.

The service platform executes a hypertext transfer protocol (HTTP) Get on URL for downloading the service from the content server 120 (808). Content server 120 returns the message (810), preferably in a signed packet format that includes the installation file in the payload and the installation command in the command list. Other file transfer options may be employed, including File Transfer Protocol (FTP) or remote file system access. In addition to installing the file, the content server 120 returns a data model of the service parameters to the service platform (810). The service platform locally maintains a database relating to running services. The management system 102 may remotely control the service parameters represented in the data model.

The service platform returns a download response message to the management system 102 (812). The download response message may include parameters such as: download and install status (e.g., if the service has been downloaded and installed correctly, status 1), start time, and finish time. When the service platform installs the service, the service platform communicates the information message to the management system 102 (814). The information message may communicate to the management system 102 that the service has been successfully installed and started running. The management system 102 returns an information response acknowledgement (816).

Typically, the service platform may send an information message to the management system 102 after each operation. The information communicates the result (e.g., success, failure, or other data). When management system 102 receives an information message from a device, management system 102 updates a record for the device identified in the information message. Thus, the management system 102 keeps the configuration information on the device in sync with the configuration retained on the management system 102.

The management system 102 may then communicate 818 the parameter setting message to the service platform. The parameter setting message may require a notification about the service, such as an active notification about the installation state of the application (i.e., "notify-2"). The service platform responds with a set parameter attribute response message (820) confirming receipt of the parameter set message.

The "notifications" parameter is used to instruct the service platform to send or not send notifications (e.g., install or uninstall) to the management system 102 regarding changes in the service installation. In one implementation, possible notification parameter values include:

0 ═ no notification should be sent;

1 ═ passive notification. The service platform sends the notification (e.g., using the management service 334) only when the next information message is required to be sent (e.g., for a timeout, a device reboot, a connection request from the management system 102, or other reason); and

2 is active notification. The management service 334 sends a notification as soon as the service state changes.

Fig. 9 illustrates a configuration message flow 900 for an upgrade of a service initiated by a service platform through an application store, such as the service store server 118. The service platform sends a version comparison message to the service storage server 118 (902). The service storage server 118 returns the comparison response to the service platform (904). If an upgrade is needed, the service platform sends an upgrade request to service storage server 118 (906). The service storage server 118 notifies the management system 102(908) so that the management system 102 can maintain the updated service profile installed on the service platform.

The management system 102 can communicate the download message to the service platform (910). The service platform executes a hypertext transfer protocol (HTTP) Get at the URL for downloading the service from the content server 120 (912). Content server 120 returns the message (914), preferably in a signed packet format that includes the upgrade file in the payload and the upgrade command in the command list. Content server 120 also returns the data model of the service parameters (914) to the service platform if the new version has a different data model.

The service platform returns a download response message to the management system 102 (916). The download response message may include parameters such as: download status (e.g., success or failure), start time, and completion time. When the service platform installs the upgraded service, the service platform communicates an information message to the management system 102 (918). The information message may communicate to the management system 102 that the upgrade has been successfully installed and started running. The management system 102 returns an information response acknowledgement (920).

The management system 102 may then communicate the parameter setting message to the service platform (922). The parameter setting message may require notification about the service, such as an active notification about the installation state of the application. The service platform 105 responds with a set parameter attribute response message (924) confirming receipt of the parameter set message.

Fig. 10 shows a configuration message flow 1000 for a new service installation initiated by a management system. In various situations, for example, where the management system 102 pushes a new service to the service platform 105, the management system may initiate the download process. Specifically, the management system 102 can communicate the download message to the service platform (1002). The service platform executes a hypertext transfer protocol (HTTP) Get at the URL for downloading the service from the content server 120 (1004). Content server 120 returns the message, preferably in a signed packet format (1006) that includes the install file in the payload and the install command in the command list. Content server 120 also returns the data model of the service parameters to the service platform (1006).

The service platform returns a download response message to the management system 102 (1008). The download response message may include parameters such as: download status (e.g., if the service has been downloaded and installed correctly, status 1), start time, and finish time. When the service platform installs the upgraded service, the service platform communicates an information message to the management system 102 (1010). The information message may communicate to the management system 102 that the service has been successfully installed and started running. The management system 102 returns an information response acknowledgement (1012).

The management system 102 can then communicate the parameter setting message to the service platform (1014). The parameter setting message may require notification about the service, such as an active notification about the installation state of the application. The service platform responds with a set parameter attribute response message (1016) confirming receipt of the parameter set message.

Fig. 11 shows a configuration message flow 1100 for an upgrade of a service initiated by a management system. In various cases, for example, where the management system 102 pushes an upgrade to a service platform, the management system may initiate the download process. Specifically, the management system 102 can communicate the download message to the service platform (1102). The service platform executes a hypertext transfer protocol (HTTP) Get at the URL for downloading the service from the content server 120 (1104). Content server 120 returns the message (1106), preferably in a signed packet format that includes the upgrade file in the payload and the upgrade command in the command list. The content server 120 returns the upgrade for the service and the data model for the parameters of the service (if needed for the upgrade) to the service platform (1106).

The service platform returns a download response message to the management system 102 (1108). The download response message may include parameters such as: download status (e.g., if the service has been downloaded and installed correctly, status 1), start time, and finish time. When the service platform installs the upgraded service, the service platform communicates an information message to the management system 102 (1110). The information message may communicate to the management system 102 that the service upgrade has been successfully installed and started running. The management system 102 returns an information response acknowledgement (1112).

The management system 102 can then communicate the parameter setting message to the service platform (1114). The parameter setting message may request a notification about the service, such as an active notification about the installation state of the application. The service platform responds with a set parameter attribute response message (1116) confirming receipt of the parameter set message.

Fig. 12 illustrates a configuration message flow 1200 for service offload initiated by a management system. The management system 102 can communicate the download message to the service platform (1202). The service platform executes a hypertext transfer protocol (HTTP) Get at the URL for downloading the service from the content server 120 (1204). Content server 120 returns the message with the empty payload, preferably in a signed packet format that includes the offload command in the list of commands in message (1206).

The service platform returns a download response message to the management system 102 (1208). The download response message may include parameters such as: download status (e.g., success or failure), start time, and completion time. When the service platform executes the command and uninstalls the service, the service platform communicates the information message to the management system 102 (1210). The information message may communicate to the management system 102 that the service has been successfully offloaded and is no longer running. The management system 102 returns an information response acknowledgement (1212).

Fig. 13 illustrates a configuration message flow 1300 for offloading of a service initiated by a service platform. Specifically, the service platform 103 offloads services locally. The service platform then communicates the information message to the management system 102 (1302). The information message may include parameters that convey, for example, the name of the offload service, that the service is no longer running, and that the offload is complete. The information message is only sent since the management system 102 previously set up an active notification about the installation status parameters. The management system 102 returns an acknowledgement response (1304).

Fig. 14 shows a configuration message flow 1400 for activating and deactivating services by the management system 102. Specifically, the management system 102 determines whether to activate or deactivate the service, and sends a parameter setting command specifying activation or deactivation in a set parameter value message (1402). For activation, the service status may be set to true. For deactivation, the service state may be set to false. The service platform returns a confirmation response (1404).

Fig. 15 shows a configuration message flow 1500 for service monitoring and service configuration by a management system. For service monitoring, the management system 102 can send a message (1502) for retrieving log data captured by the service platform. The service platform 103 may return (1504) log data requested by the management system 102.

For service configuration, the management system 102 sends a parameter setting message that specifies that the service platform 103 should set a specific parameter to a specific value (1506). The service platform 103 returns a confirmation (1508) optionally indicating success or failure in setting the parameters.

Fig. 16 shows a signed packet format 1600 for downloading files and communication instructions. The signed packet format 1600 may be a TR-069 extension that includes a fixed length header 1602, a command list 1604, and an authentication/authorization signature 1606. The signed packet format may further include fields for a payload file (e.g., fields 1608, 1610, 1612).

The signed packet format may be used to securely download files. Table (b): the command names illustrate command names that may be used to support installation, uninstallation, upgrade, and other functions of the management system 102 as described above. Alternatively, the management system 102 may define its own commands within the 1000-.

FIG. 17 illustrates a logic flow diagram 1700 executed by the management service 334 in the services platform 103. The management service 334 receives 1702 a configuration message from the management system 102 that is communicated over an installed protocol (e.g., TR-069). The management service 334 then performs control of the external service 332 and its parameters according to the configuration messages described in fig. 8-15 above.

For example, as explained in detail above with reference to fig. 8-11, the management service 334 may perform an installation or upgrade action by receiving a new service or service version (1704) and installing the new service version (1706). As another example, as explained in detail above with reference to fig. 12-13, the management service 334 may perform offloading of the service by determining the service to offload from the received command (1708) and performing an offload process (1710). The management service 334 also handles the activation/deactivation of services as explained above with reference to fig. 14. To do so, the management service 334 determines the services involved and determines whether to activate or deactivate the services (1712), and then performs the activation or deactivation (1714). In addition, the management service 334 handles service monitoring and configuration as explained in more detail with reference to FIG. 15. The management service 334 determines whether the received command requests monitoring or configuration, and the service involved (1716). The management service 334 then executes a monitoring or configuration command on the identified service (1718).

The open gateway framework provides a device-independent, open, modular platform for service creation and execution. Thus, the open gateway framework facilitates simpler and faster application development, as well as remote management. The open gateway framework provides a modular software layer installed on the device through which the open gateway framework allows services and applications to communicate with device drivers and resources.

By way of overview, the open gateway framework provides a grouping of functions (e.g., helper) located on top of the OGSi kernel (and extensions to that kernel) so that new services can leverage any function in the grouping. The packet may contain the most frequently used functional blocks from which new services can be easily created. For example, the new service does not need to overwrite the home automation actuator, but can leverage actuator functions that are already present in the function pre-configuration group.

Regardless of the gateway, each service uses the functions provided in the packet, and the packet translates these function calls into different specific operating system or driver calls depending on the underlying hardware in the device. In this way, services can be freely installed on any hardware platform without changes, as long as the new hardware platform has an open gateway framework installed. The open gateway framework abstracts the hardware layer for allowing portable application development. Should hardware change, a specific version of the open gateway framework for the hardware will be published to support the services that have been created to execute on the hardware.

The open gateway framework may include any combination of features, including: a software layer that leverages the OSGi framework for service creation and execution, which allows applications and services to be decoupled from the device base software and hardware, such as an operating system that is tightly coupled to the device hardware; a management platform for remote device monitoring and management fully integrated with a telecommunication service provider OSS/BSS system; the application resource library is used for issuing applications through a telecommunication service provider, a third party and application storage, and users can browse the catalogue and select the expected service through the application storage; and an API for application development that meets the requirements of the telecommunication service provider through custom extensions.

One of the advantages of the open gateway framework is: each service can be installed, upgraded and managed independently of other services and device base software and hardware (e.g., operating system). The services may be developed by the telecommunication service provider or any other third party, depending on any business model the telecommunication service provider wants to implement. The open gateway framework facilitates complete user support for installation/uninstallation of new services, activation/deactivation of services, or service monitoring and configuration.

The logic and processes described above may be encoded or stored in a machine-readable or computer-readable medium, such as a Compact Disc Read Only Memory (CDROM), magnetic or optical disk, flash memory, Random Access Memory (RAM) or Read Only Memory (ROM), Erasable Programmable Read Only Memory (EPROM) or other machine-readable medium, as instructions that are executed, for example, by a processor, controller or other processing device. The medium can be implemented as any device or tangible means that can contain, store, communicate, propagate, or transport the executable instructions for use by or in connection with the instruction executable system, apparatus, or device. Alternatively or in addition, logic may be implemented as analog or digital logic using hardware, such as one or more integrated circuits, or one or more processors executing instructions, or in software in an Application Programming Interface (API) or in a Dynamic Link Library (DLL), sharing functionality available in memory or defined as local or remote procedure calls, or as a combination of hardware and software.

In other implementations, the logic may be embodied in a signal or propagated signal medium. For example, the instructions that implement the logic of any given program may take the form of electrical, magnetic, optical, electromagnetic, infrared, or other types of signals. The system described above may receive such signals at a communication interface (such as a fiber optic interface, an antenna, or other analog or digital signal interface); recovering the instruction from the signal; storing them in a machine readable memory; and/or execute the instructions with a processor.

The system may include additional or different logic and may be implemented in a number of different ways. A processor may be implemented as a controller, microprocessor, microcontroller, Application Specific Integrated Circuit (ASIC), discrete logic, or a combination of other types of circuits or logic. Similarly, the memory may be DRAM, SRAM, flash, or other types of memory. The parameters (e.g., conditions and thresholds) and other data structures may be stored and managed separately, may be incorporated into a single memory or database, or may be logically and physically organized in many different ways. The programs and instructions may be a single program implemented in a library, such as a Dynamic Link Library (DLL), a part of a separate program, or distributed across several memories or processors.

While various embodiments of the invention have been described, it will be appreciated by those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the invention. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents.

Claims (15)

1. A service platform system operating on a device, the service platform system comprising:

a processor; and

a memory connected to the processor, the memory comprising:

an operating system comprising a device driver for system resources;

an abstraction layer located between the device driver and an external service, the abstraction layer comprising:

a kernel function in communication with the device driver; and

helper functions in communication with the kernel functions and including exposed consistent Application Programming Interfaces (APIs) abstracted from the operating system and device drivers, the API is operative to translate function calls from the external service to the kernel functions and operating system, and thereby to the device driver, wherein each of the device drivers is configured to interface the abstraction layer with hardware of the device, wherein the external service corresponds to code residing on the device that communicates with the consistent API of the abstraction layer to control the hardware, and wherein the code defining a given external service is written in a hardware and device driver independent manner, whereby the same service may reside on a second device that includes different hardware and device drivers for implementing functions associated with the external service;

a service management service located between the external services, the service management service operative to manage the external services in accordance with configuration messages received from a remote management system; and a communication interface operative to receive the configuration message from the remote management system and to communicate the configuration message to the service management service.

2. The services platform system according to claim 1, wherein the kernel functionality is included in a dynamic module for executing machine-independent commands.

3. The service platform system according to claim 1, wherein the memory further comprises a data model for service parameters of an external service manipulated by the service management service.

4. The service platform system according to claim 1, wherein the configuration message comprises a service install message that directs the service management service to install a new external service sent to the service platform system.

5. The service platform system according to claim 1, wherein the configuration message comprises a service parameter modification message that directs the service management service to change service parameters for any of the external services.

6. The service platform system according to claim 1, wherein the configuration message includes a service deactivation message directing the service management service to deactivate a particular external service specified in the configuration message from among the external services.

7. The service platform system according to claim 1, wherein the configuration message comprises a service activation message that directs the service management service to activate a particular external service specified in the configuration message from among the external services.

8. A method for implementing a service platform on a device, the method comprising:

providing, on the device, an abstraction layer between a device driver and an external service in an operating system, the abstraction layer comprising:

a kernel function in communication with the device driver; and

helper functions that communicate with the kernel functions and expose a consistent Application Programming Interface (API) abstracted from the operating system and device drivers, said API being operative to pass function calls in said external services to said kernel functions and operating system, and thence to said device driver, wherein each of the device drivers is configured to interface the abstraction layer with hardware of the device, wherein the external service corresponds to code residing on the device that communicates with the consistent API of the abstraction layer to control the hardware, and wherein the code defining a given external service is written in a hardware and device driver independent manner, whereby the same service may reside on a second device that includes different hardware and device drivers for implementing functions associated with the external service;

receiving, at a communication interface, a configuration message from a remote management system; and

communicating, between the external services, the configuration message to a service management service operative to manage the external services in accordance with the configuration message.

9. The method of claim 8, wherein providing an abstraction layer includes providing a dynamic module for executing machine-independent commands.

10. The method of claim 8, further comprising defining in memory a data model of service parameters for external services manipulated by the service management service.

11. The method of claim 8, wherein receiving a configuration message comprises receiving a service installation message that directs the service management service to install a new external service sent to a service platform system.

12. The method of claim 8, wherein receiving a configuration message comprises receiving a service parameter modification message that directs the service management service to change service parameters for any of the external services.

13. The method of claim 8, wherein receiving a configuration message comprises receiving a service deactivation message that directs the service management service to deactivate a particular external service specified in the configuration message from among the external services.

14. The method of claim 8, wherein receiving a configuration message comprises receiving a service activation message that directs the service management service to activate a particular external service specified in the configuration message from among the external services.

15. A processing device, comprising:

apparatus for providing an abstraction layer between a device driver and an external service in an operating system, the abstraction layer comprising:

a kernel module in communication with the device driver; and

a helper module in communication with the kernel module and exposing a consistent Application Programming Interface (API) abstracted from the operating system and device drivers, the API operates to communicate function calls in the external service to the kernel module and operating system, thereby to the device drivers, each of the device drivers configured to interface the abstraction layer with hardware of the device, wherein the external service corresponds to code residing on the device that communicates with the consistent API of the abstraction layer to control the hardware, and wherein the code defining a given external service is written in a hardware and device driver independent manner, whereby the same service may reside on a second device that includes different hardware and device drivers for implementing functions associated with the external service;

means for receiving a configuration message from a remote management system at a communication interface; and

means for communicating the configuration message between the external services to a service management service operative to manage the external services in accordance with the configuration message.