WO2010068109A1

WO2010068109A1 - A method, system, and computer program product for issuing commands

Info

Publication number: WO2010068109A1
Application number: PCT/NO2008/000444
Authority: WO
Inventors: Van Thanh Do; Van Thuan Do; Ivar Jorstad; Tore Erling Jonvik; Paal Einar Engelstad
Original assignee: Telenor Asa
Priority date: 2008-12-12
Filing date: 2008-12-12
Publication date: 2010-06-17

Abstract

A method of transmitting a command between software components using an intermediary server in a network. The command is issued as part of a message with a first format from a first software component, and received by the server. The server extracts the command from the message and derives a second command in a second format from the first command. The second command is sent as part of a second message and received by a second software component. The first and the second software components may for example be an application and a software library or framework, respectively. Also described are computer systems configured to perform the methods. The invention is particularly useful when the first and the second software components lack a common API to allow them to communicate directly. Examples involving IMS clients and IMS frameworks are included.

Description

TITLE OF INVENTION

A METHOD, SYSTEM, AND COMPUTER PROGRAM PRODUCT FOR ISSUING

COMMANDS

BACKGROUND OF THE INVENTION

Field of Invention

[0001] The invention includes a method, system, and computer program product issuing commands between software components. In particular the invention relates to transmission of commands between such components using intermediate functionality located in a computer network.

Description of Related Art

[0002] The rapidly developing convergence of telecommunication, computer and media technologies has created a situation where standardization has become necessary across industries, products and services. At the same time a number of competing alternatives covering at least partly the same functionality, and the fact that standardization lags behind technological development and proprietary alternatives compete for dominance, results in a heterogeneity that makes it difficult for developers and producers to create products that are able to take advantage of the various possibilities offered by technological development.

[0003] One area where this problem is not uncommon is the development of new services for communication devices. In order to facilitate simple and rapid development of software, particularly for handsets with limited computation power and memory resources, end user software is often developed as applications, applets or widgets that depend on middleware, software libraries or frameworks already installed on the device upon which the software is intended to run. However, access to such middleware, libraries or frameworks may depend upon the correct implementation of an Application Programming Interface (API) in the device, and because of the heterogeneity described above such access cannot be ensured on all devices. [0004] An example of this situation can be found in the field of IMS client implementations. There are currently many standardization and industrial organizations working on IMS client implementations, but presently, there is a lack of a really complete and unanimous architecture of IMS client implementations. A contemporarily popular and well-defined standardized IMS client implementation has an architecture which is derived from Java Community Process JSR 281. This standardized IMS client implementation is also adopted by non-Java organizations such as the Open Mobile Terminal Platform (OMTP).

[0005] IMS client applications make use of Internet Protocol (IP) Multimedia

Subsystem (IMS) functions and services offered by an IMS engine layer. The IMS engine layer is a software framework or platform that is typically pre-installed on a device and is intended to provide IMS functionality to client software installed on the device, and it is typically accessed through an implementation of an API.

[0006] The API is intentionally utilized to hide the complexity of the IMS engine layer to IMS client developers and to attempt to provide compatibility and portability for IMS clients. Presently, only a first aim of hiding complexity has been achieved, whereas a second aim of providing compatibility and portability of the IMS clients has not been addressed. Due to insufficient standardization of the API, there is no compulsion that every IMS client must have a similar functionality and that a given IMS client can be executed on different mobile telephones or similar communication devices.

[0007] Such lack of compatibility has prevented general adoption of IMS clients that are universally executable for mobile telephones and PDAs, irrespective of associated mobile telephone platforms being used. Such lack of compatibility restricts possible adaptations of mobile telephones and PDAs to specific user requirements and preferences, irrespective of model type and supplier.

[0008] Corresponding problems may arise in related fields of technology, and consequently there is a need for solutions that provide alternatives to accessing a local framework over an implementation of a standardized API in a device. SUMMARY OF THE INVENTION

[0009] Communication between software components may be achieved through issuance of commands in a first format from a first software component, and transmitting the command as part of a message sent to a server residing in a computer network. The first message may be received by the server where the first command can be extracted from the message and a second command in a second format may be derived based on the first command. A second message including the second command can then be transmitted to a device whereupon a second software component is residing. When the second message is received at the appropriate device the second command may be extracted from the message and executed under control of the second software component.

[0010] According to a first embodiment of the invention, the first and the second software modules are residing on the same device. In an alternative embodiment the first software module is residing on a first device and the second modules is residing on a second device. Consistent with this alternative embodiment, the first software module is residing on a first communication device and the second software module is residing on a second communication device. Alternatively the second software module may, for example, be residing on a communication server, such as - but not limited to - an instant messaging presence server.

[0011] In an exemplary embodiment that is consistent with the principles of the invention, one of the software components may be a software application and the other software component may be a software platform, a software framework or a software library. For example, one of the software components may be a combination of a widget and a widget engine upon which said widget is running. Alternatively, one of the software components may be a combination of an ECMAScript and an ECMAScript engine upon which said ECMAScript is running. Yet another alternative is that one of the software components may be a combination of a Java application and a Java virtual machine upon which said Java application is running. A software framework may, for example, be a SIP or IMS framework, although the invention is not limited in this respect. [0012] Various formats and communication protocols may be used to format the commands and messages. According to an exemplary embodiment of the invention, one of the first format and the second format is a request encapsulated in an HTTP request, and the other of the first format and the second format is a SIP request. A request encapsulated in an HTTP request may, for example, be an IMS function call.

[0013] In accordance with one aspect of the invention, the second command can be derived by invoking a function corresponding to the first command; selecting a service corresponding to the function; and issuing the second command in the second format from the selected service. The function may, for example, be an IMS native method in an IMS API server; and the service may be an IMS service enabler.

[0014] According to an exemplary embodiment of the invention, the first command may identify a calling party and a called party. The second command may then be configured to represent a call to the calling party, while a third command may be configured to represent a call to the called party. The second and the third command may be sent in a second and a third message, respectively. The second message may be transmitted back to the first communication device whereupon the second software component is residing, where the command is executed such that a call to the first communication device is established. Similarly the third message may be transmitted to the second communication device where it is executed by a third software component such that a call to the second communication device is established. In accordance with this embodiment of the invention the two calls may then be connected such that a connection between the first and the second communication device is created.

[0015] These and additional embodiments are discussed in greater detail below. The various aspects and features of the invention, including methods and computer systems as well as tangible media storing computer readable and executable software instructions, will become readily apparent from the following detailed description of the invention, from the claims and from the accompanying drawings. BRIEF DESCRIPTION QF THE DRAWINGS

[0016] A more complete appreciation of the invention and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:

[0017] Figure 1 illustrates a communication device that can be used with the invention;

[0018] Figure 2 shows a layered representation of a layered architecture of a client device;

[0019] Figure 3 is a more detailed representation of the layered architecture shown in Figure 2;

[0020] Figure 4 illustrates a system implementing certain features of the invention, including a server from which widgets can be downloaded to a device;

[0021] Figure 5 illustrates a system implementing certain features of the invention, including a widget server and an API server;

[0022] Figure 6 illustrates a first example of transmission of commands between software modules in accordance with the invention;

[0023] Figure 7 illustrates a second example of transmission of commands between software modules in accordance with the invention;

[0024] Figure 8 illustrates a third example of transmission of commands between software modules in accordance with the invention.

DETAILED DESCRIPTION OF THE INVENTION

[0025] The present invention provides methods and systems for providing messaging between software components, such as exchanging commands between software components using intermediate functionality located in a computer network. The invention is susceptible of embodiment in many different forms and of being practiced and carried out in various ways. The following explanation of exemplary embodiments is related to the field of communication, and in particular to the field of Internet Protocol Multimedia Subsystems (IMS), but the invention is not limited in this respect.

[0026] Contemporary communication devices such as personal computers with wired or wireless interfaces, wireless personal digital assistants (PDA) and mobile telephones, also known as "cell phones", as illustrated in Figure 1 , are each essentially a computer apparatus 10 including a wireless interface 20 for communicating with a wireless communication network 30, and a user interface 40 for interacting with a user 50 of the computer apparatus 10. The user interface 40 is conventionally implemented as a microphone, a loudspeaker, a keyboard, a screen and optionally a camera of a personal computer, mobile telephone or PDA. The computer apparatus 10 may include a processor 100 operable to execute software 110. The software 110 may be configured so that the computer apparatus 10 operating in cooperation with its wireless interface 20 complies with international standards for wireless communication for such devices, for example as defined in appropriate Internet Engineering Task Force (IETF), 3rd Generation Partnership Project (3GPP), Institute of Electrical and Electronics Engineers (IEEE), European Telecommunications Standards Institute (ETSI) and International Telecommunication Union (ITU) standards for example. However, a manner in which software modules comprising the software 110 interact within a computer apparatus 10 is determined by a manufacturer of the apparatus 10, for example mobile telephone or PDA.

[0027] The software 110 may include a number of different software modules, including one of a number of different operating systems or software platforms, for example SYMBIAN® OS, UIQ®, S60™, WINDOWS MOBILE®, and LINUX®, as well as various native applications including phone books, email and SMS applications, web browsers, etc. Many contemporary mobile telephones are also designed to receive Java code and execute it, thereby providing the mobile telephone with additional features or functionality which may, for example, be presented via the user interface 40 to the user 50. In this case the software 110 will typically include a Java Virtual Machine (JVM) as well as any Java code received or installed on the device. The software 110 adapted for a given manufacturer's mobile telephone is not necessarily portable to another manufacturer's mobile telephone. Such lack of compatibility creates problems for third parties desirous to generate software that is universally executable across a wide spectrum of mobile telephones offered by various diverse mobile telephone manufacturers from different parts of the World.

[0028] Referring to the software 110 of the computer apparatus 10, executable modules of the software 110 are susceptible to being conventionally considered to be structured in a layered manner. Figure 2 illustrates such a layered representation of an IMS client architecture that may be implemented on a device 10. Such a structured layered manner is pursuant, for example, to a JSR 281 architecture, which is described in further detail below. The software 110 comprises an application layer 200, an application programming interface (API) layer 210, an implementing Internet Protocol (IP) Multimedia Subsystem (IMS) engine layer 220, and a protocol stack layer 230. The JSR 281 proposes an API in Java, but there are many organizations, including OMTP, which adopts the same functionalities as those proposed by JSR 281 in a language agnostic API that can be implemented in any language, such as e.g. C and C++. The protocol stack layer 230, which is typically part of the device software platform, is operable to interface with the wireless interface 20 for enabling the computer apparatus 10 to communicate with the wireless communication network 30. Conceptually, the application layer 200 is a top layer on account of its operations being experienced directly by the user 50 in a form of a user environment presented by the computer apparatus 10 to the user 50.

[0029] There are currently many standardization and industrial organizations working on IMS client implementations. Presently, there is a lack of a really complete and unanimous architecture of IMS client implementations. A contemporarily popular and well-defined standardized IMS client implementation has an architecture which is derived from Java Community Process JSR 281. The standardized IMS client implementation is also adopted by non-Java organizations such as the OMTP.

[0030] IMS client applications in the application layer 200 make use of IMS functions and services offered by the IMS engine layer 220. Access to the IMS engine layer 220 is provided by the API layer 210. The IMS client implementations optionally include both standard and non-standard IMS-applications. [0031] The API layer 210 may include two APIs, namely the core API 300 and the service API 310 as shown in Figure 3. Inclusion of the core API 300 is relatively common in newer devices like the computer apparatus 10. The core API 300 includes IMS functionalities such as IMS session management and monitoring 320, quality-of-service (QoS) settings 330, as well as security and access functions 340. The service API 310 is, however, less common. Many devices may thus include the core API 300, but not the service API 310. The service API 310 is concerned with providing functions such as IMS services ofpush-to-talk over cellular (PoC) 350, IMS presence 360 and XML document management (XDM) 370, as well as utilities to support such functions 380.

[0032] The IMS engine layer 220 includes all IMS core functions and capabilities, as well as IMS service enablers, for example:

(a) an IMS core 400 including an IMS Session 410, PacketMedia 420, StreamMedia 430, Basic Messaging 440, Player 450, Recorder 460;

(b) IMS service enablers 500 including push-to-talk over cellular network (PoC) 510, IMS presence 520, group list management (GLM) 530 and XDM 540; and

(c) other software functions including event framework 550, registration/authorization 560, and network 570.

[0033] The protocol stack layer 230 includes a set of protocol implementations that optionally comprise one or more of the following protocols: Session Initiation Protocol (SIP) according to IETF standardization (IETF-SIP), SIP for IMS according to 3GPP standardization (3GPP-SIP), Session Description Protocol (SDP), Software Defined Radio (SDR)₁ Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Message Session Relay Protocol (MSRP), Extensible Markup Language (XML), Hypertext Transfer Protocol (HTTP), XML Configuration Access Protocol (XCAP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP) and Internet Protocol (IP).

[0034] The application layer 200 is susceptible to having executed therein one or more of: (a) non-standard applications 600 such as games;

(b) non-standard implementations of gaming, messaging and PoC as denoted by 610; and

(c) standard PoC providing voice communication 620 via the computer apparatus 10,

although not limited thereto.

[0035] The aforementioned API 210 is intentionally utilized to hide the complexity of the IMS engine layer 220 to IMS client developers and to attempt to provide compatibility and portability for IMS clients. Presently, only a first aim of hiding complexity has been achieved, whereas a second aim of providing compatibility and portability of the IMS clients has not been addressed. For example, on account of the aforementioned situation with devices where core API 300 has been implemented while the services API 310 is missing, there is no compulsion that every IMS client must have a similar functionality and that a given IMS client can be executed on different mobile telephones or similar communication devices. The incompatibility may also result from differences of the implemented core or service APIs, e.g. if the API layer 210 is written in a different programming language than an application in the application layer 200. For example, an IMS client written in C cannot function in a Java API environment and vice versa.

[0036] Such lack of compatibility has prevented general preparation of IMS clients that are universally executable for mobile telephones and PDAs, irrespective of associated mobile telephone platforms being used. Such lack of compatibility restricts possible adaptations of mobile telephones and PDAs to specific user requirements and preferences, irrespective of model type and supplier.

[0037] As applied to the exemplary problem outlined above, the present invention is, in overview, concerned with alternative ways of implementing an Internet Protocol Multimedia Subsystems (IMS) client which does not suffer problems caused by the heterogeneity of contemporary mobile telephones, computers and PDAs including wireless interfaces, while simultaneously: (a) addressing contemporarily diverging requirements of different customers; and

(b) offering better uniform experiences to users 50.

[0038] An important issue for mobile operators who are desirous to offer to their users 50 a uniform experience via IMS clients for many diverse models of mobile telephones is to ensure interoperability of their software between the diverse models.

[0039] A contemporary Netfront® IMS client package is operable to provide multimedia communication over Internet Protocol (IP) networks. The Netfront® IMS client package is provided by a company Access Co. Ltd. The IMS client package is able, for example, to provide Internet Protocol television services (IPTV) as well as, or alternatively, multi-communication tools. Moreover, the IMS client package combines Internet (web) technology and IMS together, conveniently referred to as "web + IMS" by the company. The package is designed so that a web browser is operable to receive messages from connected networks supporting an IMS user agent without pulling data from a server. Furthermore, the package allows service providers to develop software applications executable on IMS, for example voice- over-lntemet-Protocol (VoIP) applications, instant messaging (IM) applications, push-to-talk-over-cellular-networks (PoC) applications, presence applications, video sharing applications and similar. The aforesaid IMS client package is available in two versions, namely modules: a browser module, a widget module. The browser module is operable to provide an Internet browser, whereas the widget module is operable as an "always on" service; the widget module is optionally remaining on an idle screen of a mobile telephone or PDA even when the web browser is in a closed state. Thus, a widget is a downloadable application operable to be executed on a widget engine on a mobile telephone or PDA for example.

[0040] The Netfront® IMS client package has a major disadvantage that the user 50 must download and install some underlying IMS/SIP plug-in software applications having local application programming interfaces (APIs) which the aforementioned widget and widget player employs when implementing IMS and SIP functionality on the widget. This downloading requirement results in a widget not being able to be run in any widget player which, for example, does not require such downloading and installation. Thus, interoperability between different models of mobile telephone and/or PDA is not provided in contemporary situations.

[0041] It is anticipated that in the future many mobile telephones and/or PDAs will be provided with a native IMS or SIP client framework or platform pre-installed. Such provision is implemented with an intention of avoiding a need to download any special plug-in for obtaining SIP and IMS functionality. However, such a future approach has a technical problem that pre-installed software applications by manufacturers will normally work well with a given shipped mobile telephone and/or PDA, but subsequently downloaded IMS applications are susceptible to working sub- optimally or even not at all. This may e.g. be a result of the differences between the installed IMS or SIP client framework in terms of Core API and Service APIs and the subsequently downloaded clients, as mentioned above.

[0042] The present invention is directed towards addressing this problem as will now be further elucidated. In order to at least partially address this problem, the present invention according to this exemplary embodiment concerns accessing the IMS framework resources of a mobile telephone and/or PDA via its local API layer 210. Pursuant to the present invention, a given widget, for example a downloaded widget, contacts a server on a connected network in order to invoke IMS framework resources over the network by using standard IMS and/or SIP protocols which layers 230 in Figures 2 and 3 are capable of handling, substantially irrespective of type or model of mobile telephone and/or PDA. By such an approach pursuant to the present invention, the widgets are susceptible to being more universally executable among mobile telephones and/or PDAs from diverse manufacturers.

[0043] Thus, in overview, a conventional approach in mobile telephones and wireless-enabled PDAs is to access IMS and SIP application program interfaces (APIs) locally on the telephones and PDAs. The present invention adopts an alternative approach. The present invention utilizes an architecture of an IMS/SIP client which may involve an alternative implementation of methods of invoking IMS functions by seeking external assistance, for example via the Internet.

[0044] Conventional widgets or gadgets are usually small client-side Web application for displaying and updating remote data; these widgets and gadgets are packaged in such a manner to enable them to be downloaded and installed on a client machine, for example a mobile telephone and/or PDA. Pursuant to the present invention, the IMS client widget is hosted at an Internet web server and can be downloaded and executed on any wireless device, for example mobile telephone and/or wireless-enabled PDA.

[0045] Referring to Figure 4, there is shown a system implemented via the

Internet or a similar wide area network (WAN) 710. The system according to this example includes an Internet Protocol Multimedia System (IMS) widget server 720 and an IMS widget download server 730 including various IMS client widgets denoted by 740a, 740b. The computer apparatus 10, for example a user device implemented as a mobile telephone or wireless-enabled PDA, is provided with software applications including an IMS client widget 760, which may have been preinstalled or previously downloaded from the download server 730, a widget engine 770 and a web browser 780. In operation, downloading of widgets and related software on demand from the download server 730 to the computer apparatus 10 is denoted by 800 but occurs in practice by wireless via the IP network 710 and the wireless interface 20.

[0046] The IMS widget download server 730 of the computer apparatus 10 may be implemented as a standard contemporary Internet web server. In operation, the widget download server 730 is operable to store IMS/SIP client widgets such as:

(a) native IETF SIP client widgets, which are client widgets that support only the IETF SIP protocol;

(b) combined SIP/IMS client widgets, namely client widgets that support both IETF and 3GPP SIP (IMS) protocols;

(c) alternative IMS client widgets with alternative services being offered, for example VoIP IMS clients, PoC clients, Rich communication clients and so forth; "VoIP", "PoC" have meanings as previously defined above; and

(d) alternative versions of one or more IMS client widgets optimized for different types of the computer apparatus 10, for example different models of mobile telephones fabricated by a variety of manufacturers. The widget download server may be realized as any one or more servers, e.g. web servers, anywhere on the Internet. IMS widgets may also be available to be downloaded from the widget server 720, in which case the IMS widget server 720 and the download server 730 may, for example, be different services running on the same server hardware.

[0047] In order to download and install a particular widget that is made available over the server 730, the user 50 may use the web browser 780 of the user's computer apparatus 10 to visit the IMS widget download server 730. The user 50 may then select and download an IMS client widget 740a, 740b appropriate to both the user's specific type of computer apparatus and the user's personal preferences 10. The computer apparatus 10 then executes the downloaded IMS client widget 740a, 740b inside the widget engine 770, the downloaded widget 740a, 740b being operable to communicate, directly or indirectly, via the protocol stack layer 230 and the wireless interface 20 to the IMS widget server 720, typically using HTTP. The user 50 may then be able to use the IMS widget server 720 to perform one or more preferred functions, for example to make a telephone call, to check presence, to send messages such as SMS and e-mails, and so forth. As the illustration shows, due to the lack of consistent implementation of the API layer 210 discussed above, the client widgets cannot access the local IMS engine layer 220. The interaction with the IMS subsystem 720 will be described in further detail below.

[0048] A manner in which a method consistent with the principles of the present invention may be implemented, will now be further elucidated with reference to Figure 5. The IMS widget server 720 of Figure 4 is implemented in Figure 5 with assistance of an IMS Web Services (WS) API server 810 which is operable to invoke one or more IMS service enablers 820, for example: core services 830, presence services 840, PoC services 850, Instant Messaging (IM) services 860, video share services 870. An IMS client pursuant to the present invention provided on the computer apparatus 10 may be implemented as an executable widget which is executed in the widget engine 770. Consistent with the principles of one embodiment of the invention, in order to offer the user 50 services such as VoIP, PoC, Presence, a widget executing within the widget engine 770 may make use of an XmlHttpRequest object or similar for making asynchronous data requests over HTTP to send IMS commands to the IMS widget server 720. At present, XmlHttpRequest objects are supported in ECMAScript dialects such as JavaScript and JScript. ECMAScript is a scripting language specified in the ECMA-262 and ISO/IEC 16262 standard specifications. The IMS widget server 720 can be implemented as one or more servers connected to the Internet 710.

[0049] The IMS widget server 720 may include one or more software components which are operable to interpret commands sent from the computer apparatus 10 to the IMS widget server 720 and to cause the IMS WS API server 810 to invoke the appropriate functions of one or more IMS enabler services. The IMS Web Service (WS) API server 810 is beneficially a Web application server which is susceptible to invoking all the IMS core functions and capabilities and the IMS service enablers such as PoC, Presence, IM, but not limited thereto.

[0050] The IMS client widget 760 is susceptible to being at least one of the following:

(a) a standard IMS client application such as a PoC client, an IM client, a Presence client, a VoIP/IP telephony client and so forth;

(b) a graphical user interface (GUI) which the user 50 can use to access services on the Internet 710;

(c) an application operable to use one or more XmlHttpRequest objects or similar communication mechanisms for making asynchronous data requests via HTTP 700 offered by the widget engine 770 to send IMS command to the IMS widget server 720.

[0051] Several IMS client widgets are susceptible to being executed concurrently on the widget engine 770. Moreover, it is possible pursuant to the present invention for there to be for each IMS client widget several variants thereof even for a given model or type of computer apparatus 10. The IMS widget client 760 is operable to invoke functions on the IMS widget server 720 by utilizing XmlHttpRequest objects or similar communication mechanisms. Optionally, the objects, IMS widget client 760, and widget engine 770 are compliant with the ECMAScript standards mentioned above. XmlHttpRequest objects may allow both synchronous and asynchronous HTTP requests, and support HTTP GET and HTTP POST functions and associated methods. The widget engine 770 may be operable to support XmlHttpRequest object and similar mechanisms for performing asynchronous data requests over HTTP 700. An XmlHttpRequest object may implement an interface exposed by the widget engine 770 that allows widget ECMAScripts to perform HTTP client functionalities; such functionalities include, for example, submitting form data or loading data to the computer apparatus 10.

[0052] The IMS widget server 720 may be a Web server equipped with software in a form of a Web application which is operable to extract IMS commands sent from the computer apparatus 10, the IMS commands being encapsulated in HTTP methods, namely instructions, such as POST and GET. IMS functions can be encapsulated in HTTP POST using at least one of: using contemporary JavaScript Object Notation (JSON) or equivalents, using XML or equivalents. For example, a generic IMS function, represented internally within the widget 760 as an ECMAScript object, is susceptible to being serialized into a string and then encapsulated within an HTTP POST for sending from the computer apparatus 10 to the widget server 720 as follows:

IMS_REQUEST : ( function : ' <IMS function> ' , addi tional headers as key/val ue pa irs> }

[0053] wherein a more specific example is as follows:

IMS_REQUEST : { function : ^'makeCall ' , called Party : '<cal lee iden tifi ca tion> ' , cal l ingParty : ' <cal ler iden tifica tion> ' , ... }

[0054] In a similar manner, an IMS response message can be generated by the IMS widget server 720 and transported within an HTTP response message body to the computer apparatus 10 as follows:

IMS_RESPONSE : { s ta tus : ' <IMS s ta tus code>} , text : '<s ta tus text> ' , <addi tional headers as key/val ue pairs> }

[0055] wherein a more specific example is as follows:

IMS_RESPONSE : { s ta tus : { code : ' 200 } , text : OK ' , addi tional headers as key/val ue pairs> } [0056] The IMS widget client 760 of the computer apparatus 10 is operable to receive IMS response messages and extract from an HTTP body of the messages, the body being subsequently parsed by an ECMAScript engine on the computer apparatus 10 into native ECMAScript objects which are susceptible then to being further processed by the IMS widget client 760, for example to provide functionality to the user 50.

[0057] With reference to the above, an example of an XML request object is as follows:

<?xml version^ '1 . 0 'encoding=ύtf-8 ' ?>

<ims_request>

<function>makeCall</function>

<calledParty>...callee iden tifica tion...</calledParty> <callingParty>...caller iden tifica tion...</callingparty>

</ims_reques t>

[0058] Moreover, with reference to the above, an example of an XML response object is as follows:

<?xml version= '1.0 'encoding=*ύtf-8 '?> <ims_response> <status>

<code>200</code> <text>OK>/text> </status> <ims_response> [0059] Function calls encapsulated in the HTTP methods POST or GET beneficially include following functions as provided in Tables 1 , 2 and 3, but are not limited thereto:

Table 1 : IMS core instructions

Session functions to enable widget applications to create and manage IMS session: makeCall, endCall, getCalllnformation, createConference, disconnectParticipant, endConference, getConferencelnfo, getParticipantlnfo, getParticipants, inviteParticipant

Registration functions to enable widget applications to register user identities: registerUser, deregisterUser

Table 2: IMS service enablers

PoC functions to enable widget applications to support push-to-talk over cellular as specified: createPocSession, inviteParticipant, makePocCall, endPocCall, endPocSession

OMA SIMPLE Presence functions to enable widget applications to support OMA

SIMPLE Presence: providePresentity, subscribePresentity, fetch Presentitylnfo

OMA SIMPLE IM API for enabling widget applications to support Instant Messaging as specified by OMA: makeMessage, createlmSession, sendlm, reportlm

OMA XDM functions to enable widget applications to support OMA-XDM (XML Document Management): createDocument, replaceDocument, deleteDocument, retrieveDocument, createElement, replaceElement, deleteElement, retrieveElement, createAttribute, replaceAttribute, deleteAttribute, retrieveAttribute, fetchNamespace, subscribeToChange, searchDocument SIP-based PUSH functions to enable widget applications to support SIP PUSH: subscribePush

Multimedia telephony (MMTeI) functions to enable widget applications to support

MMTeI: makeCall, endCall, getCalllnformation, createConference, disconnectParticipant, endConference, getConferencelnfo, getParticipantlnfo, getParticipants, inviteParticipant

Video share functions to enable widget applications to support Video Share: makeCsCall, endCsCall, checkVsCapabilities, startVideoShareSession, startVideoShareSession, endVideoShareSession

Image share functions to enable widget applications to support Image Share: checklsCapabilities, startlmageShareSession, sendlmage

Table 3: Non-IMS services

SMS functions: clearReceivedSMS, getSMSDeliveryStatuses, getReceivedSMS, sendSMS, sendSMSWithEventing

MMS functions: clearReceivedMMS, getMMSDeliveryStatuses, getReceivedMMS, sendMMS, sendMMSWithEventing

Email API functions: clearEmailDeliveryEmail, getEmailDeliveryStatuses, getReceivedEmail, sendEmail, sendEmailWithEventing

[0060] The IMS Web Services API server 810 is a Web application server which is operable to expose both IMS core functions and IMS service enabler functions as XML Web services in a form of IMS core API and Service APIs as provided in Tables 4 to 12. Table 4: IMS core APIs for enabling widget applications to create and manage IMS sessions

makeCall: makeCallRequest callingParty calledParty dialTimeoutSec announcementType makeCallResponse callld

announcementType, callld, calledParty, callingParty, dialTimeoutSec; xs:any(JRI, xs:int, xs:string

endCall: endCallRequest callld endCallResponse status

callld, status, xs:string

getCalllnformation: getCalllnformationRequest callld getCalllnformationResponse calllnformation

callld, calllnformation=<callStatus, callTerminationCause, duration, startTime; Calllnformation, CallStatus, CaHTerminationCause>, xs:dateTime, xs:int, xs.string

createConference: createConferenceRequest createConferenceResponse conference Id

conferenceld; xs:sthng

disconnectParticipant: disconnectParticipantRequest participantld disconnectParticipantResponse status

participantld, status; xs:string

endConference: endConferenceRequest conferenceld endConferenceResponse status

conferenceld, status; xs:string

getConferencelnfo: getConferencelnfoRequest conferenceld getConferencelnfoResponse conferencelnfo

conferenceld, conferencelnfo=<conferenceStatus, duration, numberOfParticipants, startTime; Conferencelnfo, ConferenceStatus>, xs:dateTime, xs.int, xs:string

getParticipantlnfo: getParticipantlnfoRequest participantld getParticipantlnfoResponse participantlnfo

participantld, participantlnfo=<participantStatus, startTime; Participantlnfo, ParticipantStatus> xs:dateTime, xs:stήng

getParticipants: getParticipantsRequest conferenceld getParticipantsResponse participantlnfos

conferenceld, participantld=<participantlnfo, participantlnfos, participantStatus, starflϊme; Participantlnfo, Participantlnfos, ParticipantStatus>, xs.dateTime, xs.string

inviteParticipant: inviteParticipantRequest conferenceld participantUri announcementType inviteParticipantResponse participantld

announcementType, conferenceld, participantld, participantUri; xs:anyURI, xs.t^'nt, xs:string

registerUser: registerUserRequest userld userUri deregisterUserRequest userld userUri

userld, userUri; xs:anyURI, xs:string

Table 5: PoC APIs enabling widget applications to support push-to-talk over cellular as specified. createPocSession: createPoCRequest createPocResponse pocld

pocld; xs:string

inviteParticipant: inviteParticipantRequest pocld participantUri announcementType inviteParticipantResponse participantld

announcementType, pocld, participantld, participantUri; xs:anyURI, xs:int, xs:stήng

makePocCall: makeCalIRequest pocld

pocld; xs:int

endPocCall: endCalIRequest pocld

pocld; xs:int

endPocSession: endPocRequest pocld endPocResponse status

pocld, status; xs:string Table 6: OMA SIMPLE Presence API for enabling widget applications to support OMA SIMPLE Presence functions.

providePresentity: providePresentityRequest presentityld presentitylnfo providePresentityResponse status

presentitylnfo, presentityld, status; xs:int, xs:string

subscribePresentity: subscribePresentityRequest subscriberld presentityld subscribePresentityResponse presentitylnfo

subscriberld, presentityld, presentitylnfo; xs:int, xs:string

fetchPresentitylnfo: fetchPresentitylnfoRequest presentityld fetchPresentitylnfoResponse presentitylnfo

subscriberld, presentitylnfo; xs:int, xs:string

Table 7: OMA SIMPLE IM API for enabling widget applications to support Instant Messaging as specified by OMA.

makeMessage: makeMessageRequest callld content makeMessageResponse messageld status

callld, content, messageld, status; xs:int, xs:stήng

createlmSession: createlmSessionRequest callld participantld createSessionResponse

ImId

callld, participantld, ImId; xs:string, xs:int

sendlm: sendlmRequest callld content sendlmResponse messageld status

callld, content, messageld, status; xs:int, xs:string

reportlm: reportlmRequest messageld reportlmResponse status

messageld, status; xs:int, xs: string

Table 8: OMA XDM API for enabling widget applications to support OMA-XDM (XML Document Management). createDocument: createDocRequest docName createDocResponse docld

docName, docID; xs:string, xs:int

replaceDocument: replaceDocRequest docName replaceDocResponse status

docName, status; xs:sthng, xs:int

deleteDocument: deleteDocRequest docName deleteDocResponse docld

docName, docld, status; xs:string

retrieveDocument: retrieveDocRequest docName retrieveDocResponse docContent

docName, docContent; xs:string

createElement: createElementRequest elementName createElementResponse elementld

elementName, elementld; xs:string, xs:int

replaceElement: replaceElementRequest elementName replaceElementResponse elementld

elementName, elementld; xs:string, xs:int

deleteElement: deleteElementRequest elementName deleteElementResponse elementld

elementName, elementld, status; xs:string

retrieveElement: retrieveElementRequest elementName retrieveElementResponse elementContent

elementName, elementContent=<docName, docContent>; xs:string

create Attribute: createAttributeRequest attributeName createAttributeResponse attributeld

attributeName, attributeld; xs:sthng, xs.ϊnt

replaceAttribute: replaceAttributeRequest attributeName replaceAttributeResponse attributeld

attributeName, attributeld; xs:string, xs:int

deleteAttribute: deleteAttributeRequest attributeName deleteAttributeResponse attributeld

attributeName, attributeld; xs.string, xs:int

retrieveAttribute: retrieveAttributeRequest attributeName retrieveAttributeResponse attributeld

attributeName, attributeld; xs:string

fetchNamespace: fetchNameSpaceRequest docUri fetcNameSpaceResponse nsDoc

docUri, nsDoc; xs:string

subscribeToChange: subscribeToChangeRequest principalUri docld subscribeToChangeResponse status

principalUri, docld, status; xs:string, xs:int

searchDocument: search DocRequest docld reqElement maxResults searchDocResponse response status

reqElements, docld, response, maxResult, status; xs:string, xs:int

Table 9: SIP-based PUSH API for enabling widget applications to support SIP PUSH.

subscribePushRequest: receiverld eventld

subscribePushResponse: status

receiverld, eventld, status; xs:string, xs:int

Table 10: Multimedia Telephony (MMTeI) API for enabling widget applications to support MMTeI.

makeMmCall: makeMmCallRequest callingParty calledParty dialTimeoutSec announcementType makeMmCallResponse callld

announcementType, callld, calledParty, callingParty, dialTimeoutSec; xs:anyURI, xs.int, xs.string

endMmCall: endMmCallRequest callld endMmCallResponse status

callld, status; xs:string

getMmCalllnformation: getMmCalllnformationRequest callld getMmCalllnformationResponse calllnformation

callld, calllnformation=<callStatus, callTerminatioCause, duration, startTime; Calllnformation, CallStatus, CAIITerminationCause>, xs:dateTime, xs:int, xs:stήng

createMmConference: createMmConferenceRequest createMmConferenceResponse conferenceld

confereceld; xs.string

disconnetMmParticipant: disconnectMmPaticipantRequest participantld disconnectParticipantResponse status participantld, status; xs:string

endMmConference: endConferenceRequest conferenceld endConferenceResponse status

conferencsld, status; xs:string

getMmConferencelnfo: getConferencelnfoRequest conferenceld getConferencelnfoResponse conferencelnfo

conferenceld, conferencelnfo=<conferenceStatus, duration, numerOfParticipants, startTime; Conferencelnfo, ConferenceStatus>, xs:dateTime, xs:int, xs:string

getMmParticipantlnfo: getParticipantlnfoRequest participantld getParticipantlnfoResponse participantlnfo

participantld, participantlnfo=<participantStatus, startTime; Participantlnfo, ParticipantStatus>, xs:dateTime, xs:string

getMmParticipants: getParticipantsRequest conferenceld getParticipantsResponse participantlnfos

conferenceld, participantlnfo=<participantlnfos, participantStatus, startTime; Participantlnfo, Participantlnfos, PartcipantStatus>, xs:dateTime, xs.sthng inviteMmParticipant: inviteParticipantRequest conferenceld participantUri announcementType inviteParticipantResponse participantld

announcementType, conferenceld, participantld, participantUri; xs.anyURI, xs.t^'nt, xs.stήng

Table 11 : Video Share API for enabling widget applications to support Video Share.

makeCsCall: makeCsCallRequest callingParty called Party dialTimeoutSec announcementType makeCsCallResponse callld

announcementType, callld, calledParty, callingParty, dialTimeoutSec; xs.anyURI,, xsύnt, xs:string

endCsCall: endCsCallRequest callld endCsCallResponse status

callld, status; xs:string

checkVsCapabilities: checkCapabilitiesRequest calledPartyid checkVsCapabilitiesResponse status

calledPartyid, status; xs.string

startVideoShareSession: start VideoShareSessionRequest callingParty calledParty startVideoShareSessionResponse vsSessionld status

calledParty, callingParty, vsSessionld, status; xs:string xs:int

endVideoShareSession: endVideoShareSessionRequest vsSessionld endVideoShareSessionResponse status

vsSessionld, status; xs:string

Table 12: Image Share API for enabling widget applications to support Image Share.

checklsCapabilities: checklsCapabilitiesRequest calledPartyid checklsCapabilitiesResponse status

calledPartyid, status; xs:string

startlmageShareSession: startlmageShareSessionRequest callingPartyld called Partyld startlmageShareSessionResponse isSessionld status

callingPartyld, calledPartyld, isSessionld, status; xs:stήng

sendlmage: sendlmageRequest calledPartyld picture sendlmageResponse status

calledPartyld, picture, status; xs.string, xs:bitmap, xs:string

[0061] The IMS Web Services API server 810 is also operable to source non-

IMS services as provided in Tables 14 to 16.

Table 14: SMS API for enabling SMS functions at the computer apparatus 10.

clearReceivedSMS: clearReceivedSMSRequest

SMSId clearReceivedSMSResponse clearCount

clearCount, SMSId; xs.int, xs.string

getSMSDeliveryStatuses: getSMSDeliveryStatusesRequest

SMSId getSMSDeliveryStatusesResponse

SMSDeliveryStatuses SMSId, SMSDeliveryStatuses=<SMSId, SMSStatus;> xs:int, xs:string

getReceivedSMS: getReceivedSMSRequest keyword getReceivedSMSResponse

SMS

keyword, SMS=<SMSId, SMSText, SMS, receiveTime, senderUri>; xs:anyURI, xs:dateTime, xs: string

sendSMS: sendSMSRequest recipientUris from

SMSText sendSMSResponse

SMSId

from, SMSId, SMSText, recipientUris, uri, xsianyURI, xsistring

sendSMSWithEventing: sendSMSWithEventingRequest recipientUris from

SMSText url sendSMSWithEventingResponse

SMSId

from, SMSId, SMSText, recipientUris, uri, url, xs.anyURI, xs.string

Table 15: MMS API for enabling MMS functions at the computer apparatus 10.

clearReceivedMMS: clearReceived M MS Request

MMSIds clearReceivedMMSResponse clearedCount

clearedCount, MMSId; xs:int, xs:stήng

getMMSDeliveryStatuses: getMMSDeliveryStatusesRequest

MMSId getMMSDeliveryStatusesResponse

MMSDeliveryStatuses

MMSId, MMSDeliveryStatuses=<MMSId, MMSStatus>; xs:int, xs:string

getReceivedMMS: getReceivedMMSRequest keyword getReceivedMMSResponse

MMS

keyword, MMS=<MMSId, MMSText, MMS₁ receiveTime, senderUri>,xs:int; xs:dateTime, xs:string,xs:anyURI

sendMMS: sendMMSRequest recipientUris from

MMSText sendMMSResponse

MMSId

from, recipientUris, MMSText, MMSId, xs:anyURI, xs:stήng

sendMMSWIthEventing: sendMMSWithEventingRequest recipientUris from

MMSText url sendMMSWithEventingResponse MMSId

from, MMSId, MMSText, recipientUris, url, xs:anyURI, xs:string

Table 16: E-mail API for enabling E-mail functions at the computer apparatus 10.

clearReceivedEmail: clearReceivedEmailRequest emailAddresses clearReceivedEmailResponse clearedCount

clearedCount, emailAddresses; xs:int, xs:stήng

getEmailDeliveryStatuses: getEmailDeliveryStatusesRequest emailldGetEmailDeliveryStatusesResponse emailDeliveryStatuses

emailld, emailDeliveryStatuses, xs:int, xs:string

getReceivedEmail: getReceived EmailRequest keyword getReceivedEmailResponse email

keyword, email=<emailAddress, emailText, receiveTime, senderUri>; xs.anyURI, xs:dateTime, xs:string

SendEmail: sendEmailRequest recipientUris from emailText sendEmailResponse emailld

emailld, from, emailText, recipientUris, uri, xs:anyURI, xs:string

sendEmaMWithEventing: sendEmailWithEventingRequest recipientUris from emailText url sendEmailWithEventingResponse emailld

from, emailText, recipientUris, url, xs:anyURI, xs:string

[0062] Tables 1 to 16 provide examples for implementing the present invention for ensuring sufficiency of disclosure of the present invention. Tables 4 to 16 are in the following format:

<IMS core, IMS service enabler, or non-IMS service function name>:

<parameter declaration> ...

[0063] A method of invoking IMS functions from IMS client applications executing on the computer apparatus 10 will now be described with reference to Figure 6. In other words, there will now be described a manner in which a client on the computer apparatus 10 calls via ECMAScript the IMS server 720 and invokes an IMS function, for example makeCall. As such, the example involves two devices, the calling device 10 and the called device 10c, as well as the IMS widget server 720, the IMS Web Services API server 810 including the IMS Service Enablers 820. The method involves five steps denoted by A to E in Figure 6.

[0064] In a first step A of the method, an IMS client application 760 present in the computing apparatus 10 sends a request via an ECMAScript-compliant API using XmlHttpRequest including one or more ECMAScript objects. For example, an ECMAScript object is created and populated with appropriate values such as for example in the case of a call request: makeCall, callee_identification, callerjdentification, etc. The populated ECMAScript object is then serialized into a variable named IMS_REQUEST which enables it to be sent from the computer apparatus 10 via the wireless interface 20 to the IMS widget server 720. Exemplary ECMAScript-compliant JavaScript code that may be part of a client widget 760 that can be executed by the widget engine 770 as part of step A may look as follows: var request = new XMLHt tpRequest () ; // Create HTTP request object

String url = <complete URL of IMS Widget server>; request. open ("POST", url, true); // An asynchronous POST request

// Set up callback function: request. onreadystatechange = function () { if (request. readyState == 4 && request. status == 200) { var response = request . responseText;

IMSresponseHandler (response) ; // Forward response to a handler in the IMS widget client

request. send ("IMS_REQUEST=" + IMS_REQUEST) [0065] In a second step B, the widget engine 770 issues an HTTP POST, as requested in the code listed above, to the IMS Widget server 720 as follows:

POST /ims_widget_server.php HTTP/1 . 1

Hos t : ims . telenor . com

Con ten t - type : appl ica tion/x -www-form-url encoded

Con ten t -length : 133

IMS__REQUEST= { IMS_REQUEST : { function : 'makeCal l ' , calledParty : ^Λ <callee iden tifica tion> ' , callingParty : ' <caller iden tifica tion>*, ... } }

[0066] This assumes that the value of the url variable in the step A code was

"http://ims.telenor.com/ims_widget_server.php". The character strings <callee identification> and <caller identification> will include the phone number or the SIP address associated with device 10c and device 10, respectively.

[0067] In a third step C, the IMS widget server 720 upon receiving the HTTP

POST can extract and interpret the encapsulated IMS function and invoke an appropriate Web service method, at the IMS Web Services API server 810. In the following example the Web service method makeCallQ is invoked by programming code written in Java, assuming stubs built according to the Web Services Description Language (WSDL):

IMSLoca tor loca tor = IMSLo ca tor () ;

IMSSoap service = loca tor . IMSSoap () ;

MakeCall cal l = new MakeCall () ; call . setCalledParty (<cal ler_idenrtifica tion>) ; call . setCallingParty (<callee iden tifica tion>) ; service . makeCa 11 (call) ;

[0068] It will be understood by those with skill in the art that the programming language Java is only one example, and that the IMS widget server 720 may be programmed using various other languages such as for example C and C++. [0069] As illustrated in Figure 5, in some embodiments of the invention the

IMS Web Services API server 810 may be a separate server accessible to the IMS widget server 720 over the network 710. In such a case, the IMS widget server 720 may issue a SOAP message that is transmitted to the IMS Web Services API server 810. A SOAP message is in an XML message format and may rely on Remote Procedure Call (RPC) and HTTP for message negotiation and transmission.

[0070] A SOAP message corresponding with the exemplary Java code given above may look as follows:

POST /ims_web_service HTTP/1.1

Host: ims. telenor.com

Content-type: text/xml; charset="utf-8"

Content-length: ...

<S0AP-ENV: En vel ope> xmlns : soap="h t tp: //schemas . xmlsoap. or g/ soap/ envelope/ " xmlns: ; xs i="http : / / www . w3.org/2001/XMLSchema-instance" xmlns : xsd="http: //www. w3. org/2001/XMLSchema"> <S0AP-ENV: Body>

KmakeCall xmlns="http : / ^'/ ims . telenor.com/ws">

<calledParty>callee_identification</calledParty > <callingParty>caller_identification</callingParty>

</params> </ SOAP-ENV: Body> </ SOAP -ENV: Envelope>

[0071] According to alternative embodiments of the invention the IMS API

Web Services API server 810 may be implemented on the same server system as the widget server 720. In such a case, while SOAP is still an alternative, direct method invocation in native programming language such as C, C++, etc may be used instead. Generally speaking, the invention is not limited to any particular message format.

[0072] When the IMS Web Services API server 810 has received the SOAP message from the widget server 720, the necessary information can be extracted from the message. According to this example, it will be established that the appropriate method to invoke is makeCallQ and the identity of the calling party and the called party will also be extracted from the message. In a fourth step D of the method, the IMS Web Services API server 810 invokes an appropriate IMS method on the appropriate IMS core or service enablers as follows: makeCallResponse response = makeCall (callingParty, callerParty, ...) ;

[0073] In the example illustrated in Figure 6, the appropriate IMS service enabler is Core 830a.

[0074] In a fifth step E of the method, the IMS core functions or IMS service enabler then communicates using SIP and via the wireless interface 20 with their counterpart in the user's 50 computer apparatus 10 to execute the requested command as follows:

INVITE sip: callerlden tifica tion@telenor. com SIP/2. 0

From : "Dennis Baron " <sip: caller Iden tifica t ionθtelenor. com>; tag=l c41

To : sip: callerlden tifica tionθtelenor. com

Call -Id: call -1096504121 -2@193. 156. 19.227

Cseq: 1 INVITE [0075] The above command invites the caller's device to establish a connection with the network. A similar SIP command is sent to the called device 10c:

INVITE sip : calleelden tifica tion@ telenor. com SIP/2. 0

From : "Dennis Baron " <sip : cal ler Iden t if i ca tionβ telenor . com>; tag=l c41

To : sip : calleelden tifi ca tionθ telenor . com

Ca ll -Id: call -1096504121 -2βl 94. 126. 22. 127

Cseq: 1 INVITE

[0076] In this manner, even if the IMS APIs 210, 210c do not expose any interface to the application layers 200, 200c that is known to the widget engines 770, 770c, the user of device 10 is able to initiate a call to device 10c by using the client widget 760 because the necessary service enablers are available through the IMS Widget server 720 and the corresponding IMS Web Services API server 810.

[0077] The method of the invention is thereby operable to effectively issue commands or instructions, or transfer other types of messages or events, from a software application 760 to an associated software application 830b within the computer apparatus 10. It should be noted that the method is not limited to one-to- one mapping of functions invoked in the device and in the server. The function called by the client widget 760 is not necessarily the same or the only function invoked through the API server 820, and the function or functions invoked in the API server 820 are not necessarily the same function or functions invoked in the IMS framework 220 on the device 10 by the received SIP command.

[0078] The previous example illustrated how the present invention can be used in an IMS environment to initiate a call between to devices 10, 10c without the client widget 760 having direct access to the local IMS framework 200 due to inconsistent standardization or implementation of IMS APIs 210 on devices. A second example will now be described with reference to Figure 7. This example illustrates how the invention can be used when only one device is involved. In other words, the client widget 760 can be used to interact with the local IMS framework 220. This example also illustrates how messages can be sent from the IMS framework 220 to the client widget 760. [0079] In a first step A, the IMS client application 760 invokes an IMS function

"getCapabilities" via an ECMAScript-compliant API using the XMLHttpRequest objects, similar to what has been described in the previous example. Assuming an ECMAScript object has been created and populated with the appropriate values and has been serialized into a variable called IMS_REQUEST, it can be sent to the IMS widget server 720 as follows. var request = new XMLHttpRequest (); // Create HTTP request object

// Set up callback function: request .onreadystatechange = function () { if (request. readyState == 4 && request . status == 200) { var response = request . responseText;

reques t . send ( " IMS_REQUEST=" + IMS_REQUEST) ;

[0080] In a second step B, the widget engine 770 issues an HTTP POST to the IMS widget server 720 as follows:

POST /ims_widget_server.php HTTP/1 . 1

Hos t : ims . telenor . com

Con ten t - type : appl ica tion/x-www-form -urlencoded

Con ten t -length : 133

IMS_REQUEST= { IMS_REQUEST : { function : 'getCapabil i ties ' , capabili tyID '<capabili ty ID> ' , callingParty : *<caller iden tifica tion>' ... j } [0081] This assumes the uii variable in the step A code was

"http://ims.teleπor.com/ims_widget_server.php". The string 'getCapabilities' represents the function that should be invoked by the IMS Widget server 720. The string <capability ID> can, for example, be audio, video, text, application, etc. and will be used as the argument of the getCapabilitiesQ method. The elements audio, video, text, application, etc. are of Boolean type. They are inserted without any value in the request, and will be populated with true or false at the IMS response.

[0082] The string <caller identification> may include the phone number or the

SIP address associated with device 10.

[0083] In a third step C, the IMS widget server 720 upon receiving the HTTP

POST can extract and interpret the encapsulated IMS function and invoke an appropriate Web service method, at the IMS Web Services API server 810. Again the method, in this case GetCapabilities(), is invoked by program code written in Java, and again assuming stubs built according to WSDL. Other alternatives are within the scope of the invention.

IMSLocator locator = IMSLocator () ; IMSSoap service = locator. IMSSoapO ; GetCapabilities capa = new GetCapabilities (); capa . setCapabilityID (<capability_ID>) ; service . getCapabilities (caps) ;

[0084] The corresponding SOAP message that is sent to the API server 810 may look like this:

POST /ims_web_service HTTP/1 . 1

Host : ims . telenor. com

Con ten t -type : text/xml ; charset-"utf-8"

Con ten t-length : ...

< SOAP-ENV: En vel ope> xmlns : soap= "h t dp ; //schema s . xmlsoap . org/ soap/ en velope/ " xmlπs : xsi="h t tp : //www. w3. org/2001/XMLSchema -ins tance " xmlns : xsd="h ttp: / /www . w3. org/2001/XMLSchema "> <SOAP-ENV: Body>

<getCapabili ties xmlns="http: //ims . telenor. com/ws "> <params> <capabillty>capabili ty_id</ capabili ty >

<callingParty>caller_identifica tion</callingParty> </params>

</getCapabili ties >

</ SOAP-ENV :Body> </ 'SOAP-ENV: En vel ope>

[0085] When the IMS Web Services API server 810 has received the SOAP message from the widget server 720, the necessary information can be extracted from the message. According to this example, it will be established that the appropriate method to invoke is getCapabilitiesQ and the Capability ID such as for example audio, which can have the value true or false as described above.

[0086] In a fourth step D of the method, the IMS Web Services API server 810 invokes an appropriate IMS method on the appropriate IMS core or service enabler as follows: getCapabili tiesResponse response = getCapabili ties (Capabil i tyld) [0087] The IMS core functions 830a or one or more IMS service enablers

840a, 850a, 860a, 870a, may then communicate with their counterpart enablers in the device 10 using SIP. According to the current example the core functions 830a communicates with the core functions 830b of the device 10 in a step E as follows:

OPTIONS sip: callerldentification@telenor.com SIP/2.0

From: "Dennis Baron "<sip: caller Ident if icationβ t el enor. com>;tag=lc41

To: sip: callerldentificationβtelenor. com

Call-Id: call-1096504121-2@193.156.19.227

Cseq: 63104 OPTIONS

Contact: < sip.-callerldentificationβtelenor. com >

; audio; video; text Accept: application/ sdp Content-Length: 0

[0088] After the SIP command has been received by the IMS core functions

830b in the device 10, the core functions can answer, in a step F, with an OPTIONS response containing the client capabilities in the form of Boolean values associated with each respective capability as follows:

SIP/ 2.0 200 OK

To: "Dennis Baron "<sip: callerldentificationβtelenor. com>; tag=lc41 From: sip: caller Identificat ionθtelenor. com Call-ID: call-1096504121-2@193.156.19.227 CSeq: 1 OPTIONS

Contact: < sip:callerldentification@telenor.com > ;audio=true; video=false; text=true Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Accept: application/sdp Accept -Encoding: gzip Accept -Language : en Conten t-Type: applica tion/ 'sdp Content-Length : 274

[0089] The IMS core functions 830a or IMS service enabler 840a, 85Oa₁ 860a,

870a will then return the Capabilities parameters e.g. audio, video, text, back to the IMS Web Services API server 810 in a step G. The API server 810 in its turn sends the response back to the IMS widget server 720 in step H. The IMS widget server 720 will then return the response to the IMS widget 760 via the Widget engine 770 in steps I and J.

[0090] Reference is now made to Figure 8, wherein is illustrated an example of a method according to the invention where no message is sent back to the originating device. Rather, according to this example a client widget 760 on a first device 10 communicates with an on line IMS Widget server 720 in order to transmit a message to a second device 10c. The method will again be described in terms of five steps A through E.

[0091] In a first step A, the IMS client application 760 invokes an IMS function

"sendSMS" via an ECMAScript-compliant API using the XMLHttpRequest objects. Assuming an ECMAScript object has been created and populated with the appropriate values and that it has been serialized into a variable called IMS_REQUEST, it can be sent to the IMS Widget server 720. The following widget script invokes the appropriate functions in the widget engine: var request = new XMLHttpRequest (); // Create HTTP request object String url = <complete URL of IMS Widget server>;

request . open ("POST", url, true); // An asynchronous POST request

// Set up callback function: request. onreadystatechange = function () { if (request . readySta te == 4 && request . s ta tus = 200) { var response = reques t . responseText;

IMSresponseEandler (response) ; // Forward response to a handler in the IMS

// Widget clien t

} } request . send ("IMS_REQUEST=" + IMS_REQUEST) ;

[0092] As a result, the widget engine 770 generates and transmits an HTTP

POST request to the IMS Widget server 720 as follows:

POST /ims_widget_server.php HTTP/1 . 1

Hos t : ims . telenor. com

Con ten t- type : appl ica tion/x- www- form -urlen coded

Con ten t-length : 133

IMS_REQUEST= { IMS_REQUEST : { function : 'sendSMS' , msg : '<SMS>' , recipien t : ^Λ<RECIPIENT>' , ... } }

[0093] Again this assumes that the uri variable of the code described as part of step A was "http://ims.telenor.com/ims_widget_server.php". The string <SMS> will contain the actual SMS message, while the string <RECIPIENT> will include the phone number or the SIP address associated with device 10c. The string 'sendSMS¹ identifies the function that should be invoked by the IMS Widget server 720.

[0094] In a third step C, the IMS widget server 720 upon receiving the HTTP

POST request can extract and interpret the encapsulated IMS function and invoke an appropriate Web service method at the IMS Web Services API server 810. In this case the method is sendSMSQ, and it can, by way of example, be invoked by programming code written in Java, and again assuming stubs built according to WSDL. Other alternatives are within the scope of the invention.

IMSLocator locator = IMSLocator () ; IMSSoap service = locator. IMSSoapO ; SendSMS sms = new SendSMS () ; sms. setsms (<SMS>) ; sms.setRecipient (<RECIPIENT>) ; service. sendSMS (sms) ;

[0095] From the exemplary code above it will be seen that an object called sms is created, and populated with the <SMS> message string and the recipient address <RECIPIENT> message string that have been extracted from the IMS_REQUEST variable encapsulated in the received HTTP POST request. The code then calls the sendSMSQ method with the sms object as input argument. This may result in a SOAP message that is sent to the API server 810, for example as follows:

POST / ims_web_service HTTP/1.1

Host: ims.telenor.com

Content-type: text/xml; charset="utf-8"

Con tent -length: ...

<S0AP-ENV: Envelope> xmlns : soap="http: //schemas . xmlsoap. org/ soap/ envelope/ " xmlns : xsi="h t tp : //www. w3. org/ '2001 /XMLSchema- instance " xmlns :xsd="http: //www. w3. org/2001/XMLSchema"> <S0AP -ENV: Body>

</sendSMS >

</SOAP-ENV: Body> </SOAP-ENV: Envelope>

[0096] Upon receiving the SOAP message, the IMS Web Services API server

810 can now extract the necessary information and invoke the appropriate IMS method or methods on the appropriate IMS core or service enabler. According to this example the sendSMSQ method is invoked on the SMS/MMS service enabler 880a as follows: sendSMSResponse response = sendSMS (sms)

[0097] SMS and MMS are not part of IMS. Therefore, the non-IMS service enabler SMS/MMS 880a will have to communicate not with a corresponding service enabler in a receiving device, but with an SMS-C 900 in the mobile network and request that an SMS is sent to the appropriate recipient. The message of step E will therefore not be a SIP command.

[0098] The present invention is capable of contributing to help mobile operators to address problems of IMS client deployment. Moreover, the inventors have envisaged a need for mobile operators to introduce IMS to meet challenges of decreased voice traffic and expansion of services provided via the World Wide Web. Further, the present invention is capable of providing customization possibilities for improving customer satisfaction. Additionally, the present invention is also capable of reducing costs, for example operating costs and customer support costs, when implementing wireless telephone systems and associated networks. [0099] Although the present invention is described in the foregoing in relation to wireless communication, it will be appreciated that the present invention is optionally also applicable to wired systems. Such "wired systems" are to be construed to include electrically wired systems and/or optical-fibre systems.

[00100] Furthermore, the invention is not limited to IMS and SIP, but can be applied to a number of similar situations wherein a first software component is capable of issuing commands or messages, e.g. events, in a first format and a second software component is capable of receiving commands or messages in a second format.

[00101] The invention is particularly useful when one or more applications on a device are unable to access a library, framework or a platform due to incompatible or missing implementations of an API. The invention may thus provide for access from the application to a corresponding API available on a server residing in a computer network. The server may then give access to an implementation of the library, framework or platform on a network server in order to invoke the necessary functionality, and the necessary messages or commands may be sent either to the corresponding local framework, to a corresponding framework on a second device, back to the originating application, or different parts of the network where additional services can be invoked.

[00102] According to certain aspects of the invention, additional services residing on communication servers may be reached using the implementation of an API or a command translator in a server. Such communication servers may e.g. be presence servers indicating the presence of a subscriber in relation to instant messaging services, or a server providing services associated with mobile or cellular communications, such as SMS, MMS, positioning services etc.

[00103] It will be realized by those with skill in the art that the various functions described as part of a network server may be implemented on the same or on different server computers. As such, the terms server, servers, server system and server systems should all be understood to be representative of the various examples discussed only, and that the invention can be implemented on any combination of one or more servers with functionality or services implemented on individual servers or in any combination on one or more servers. Consequently, the terms server and server system are intended to cover any implementation of one or more servers capable of performing the functions described as part of the invention.

[00104] Modifications to embodiments of the invention described in the foregoing are possible without departing from the scope of the invention as defined by the accompanying claims.

[00105] Expressions such as "including", "comprising", "incorporating", "consisting of, "have", "is" used to describe and claim the present invention are intended to be construed in a non-exclusive manner, namely allowing for items, components or elements not explicitly described also to be present. Reference to the singular is also to be construed to relate to the plural.

[00106] Numerals included within parentheses in the accompanying claims are intended to assist understanding of the claims and should not be construed in any way to limit subject matter claimed by these claims.

Claims

WHAT IS CLAIMED

1. Method in a communication device, said device having a first software component capable of issuing commands in a first format and a second software component capable of receiving commands in a second format, the method comprising:

issuing a first command in a first format from said first software component;

transmitting a first message from said communication device to a server residing in a computer network, said message including said first command issued by said first software component;

receiving a second message at said communication device from said server, said second message including a second command in a second format, said second command being derived from said first command at said server; and

executing said second command under control of said second software component.

2. Method according to claim 1 , wherein one of said first software component and said second software component is a software application and the other of said first software component and said second software component is chosen from the group consisting of: a software platform, a software framework and a software library.

3. Method according to claim 1 , wherein one of said first format and said second format is a request encapsulated in an HTTP request, and the other of said first format and said second format is a SIP request.

4. Method according to claim 3, wherein said request encapsulated in an HTTP request is an IMS function call.

5. Method according to claim 1 , wherein said first software component or said second component is a combination of a widget and a widget engine upon which said widget is running.

6. Method according to claim 1, wherein said first software component or said second component is a combination of an ECMAScript and an ECMAScript engine upon which said ECMAScript is running.

7. Method according to claim 1 , wherein said first software component or said second component is a combination of a Java application and a Java virtual machine upon which said Java application is running.

8. Method according to claim 5, further comprising:

issuing an XMLHttpRequest from said widget to said widget engine, said XMLHttpRequest invoking a function in said widget engine; and

issuing an HTTP POST method request or an HTTP GET method request from said widget engine as said message from said communication device to said server.

9. Method according to claim 1 , wherein said second software component includes an API inaccessible to said first software component.

10. Method according to claim 2, wherein said software framework is a SIP or IMS framework.

11. Method in a computer server residing in a communication network, the method comprising:

receiving a first message from a first software component residing on a first communication device, said first message including a first command in a first format;

extracting said first command from said message;

deriving a second command in a second format from said first command; and

transmitting a second message including said second command in said second format to be executed by a second software component.

12. Method according to claim 11 , wherein one of said first software component and said second software component is a software application and the other of said first software component and said second software component is chosen from the group consisting of: a software platform, a software framework and a software library.

13. Method according to claim 11 , wherein said one of said first format and said second format is a request encapsulated in an HTTP request, and the other of said first format and said second format is a SIP request.

14. Method according to claim 13, wherein said request encapsulated in an HTTP request is an IMS function call.

15. Method according to claim 11 , wherein said first software component or said second component is a combination of a widget and a widget engine upon which said widget is running.

16. Method according to claim 11 , wherein said first software component or said second component is a combination of an ECMAScript and an ECMAScript engine upon which said ECMAScript is running.

17. Method according to claim 11 , wherein said first software component or said second component is a combination of a Java application and a Java virtual machine upon which said Java application is running.

18. Method according to claim 15, wherein said first message is an HTTP POST method request or an HTTP GET method request issued by said widget engine as a result of a function in said widget engine being invoked by an XMLHttpRequest issued from said widget.

19. Method according to claim 11 , wherein said second software component is residing on said first communication device.

20. Method according to claim 11 , wherein said second software component is residing on a second communication device.

21. Method according to claim 11 , wherein said second software component is residing on a communication server.

22. Method according to claim 21 , wherein said communication server is an instant messaging presence server.

23. Method according to claim 11 , wherein said deriving of said second command comprises:

invoking a function corresponding to said first command;

selecting a service corresponding to said function; and

issuing said second command in said second format from said service.

24. Method according to claim 23, wherein said function is an IMS native method in an IMS API server; and said service is an IMS service enabler.

25. Method according to claim 11 , wherein said first command identifies a calling party and a called party, the method further comprising:

configuring said second command to represent a call to said calling party;

transmitting said second message to said first communication device, said second software component residing on said first communication device;

deriving a third command in said second format from said first command;

configuring said third command to represent a call to said called party;

transmitting a third message including said third command in said second format to be executed by a third software component residing on a second communication device; and

connecting said call to said calling party and said call to said called party thus creating a connection between said first communication device and said second communication device.

26. Computer server system configured to communicate with software components installed and executing on communication devices connected to a computer network, and to perform a method comprising:

extracting said first command from said message;

deriving a second command in a second format from said first command; and

27. Computer server system according to claim 26, wherein one of said first software component and said second software component is a software application and the other of said first software component and said second software component is chosen from the group consisting of: a software platform, a software framework and a software library.

28. Computer server system according to claim 26, wherein said one of said first format and said second format is a request encapsulated in an HTTP request, and the other of said first format and said second format is a SIP request.

29. Computer server system according to claim 28, wherein said request encapsulated in an HTTP request is an IMS function call.

30. Computer server system according to claim 26, wherein said first software component or said second component is a combination of a widget and a widget engine upon which said widget is running.

31. Computer server system according to claim 26, wherein said first software component or said second component is a combination of an ECMAScript and an ECMAScript engine upon which said ECMAScript is running.

32. Computer server system according to claim 26, wherein said first software component or said second component is a combination of a Java application and a Java virtual machine upon which said Java application is running.

33. Computer server system according to claim 30, wherein said first message is an HTTP POST method request or an HTTP GET method request issued by said widget engine as a result of a function in said widget engine being invoked by an XMLHttpRequest issued from said widget.

34. Method according to claim 26, wherein said second software component is residing on said first communication device.

35. Method according to claim 26, wherein said second software component is residing on a second communication device.

36. Method according to claim 26, wherein said second software component is residing on a communication server.

37. Method according to claim 36, wherein said communication server is an instant messaging presence server.

38. Method according to claim 26, wherein said deriving of said second command comprises:

invoking a function corresponding to said first command;

selecting a service corresponding to said function; and

issuing said second command in said second format from said service.

39. Method according to claim 38, wherein said function is an IMS native method in an IMS API server; and said service is an IMS service enabler.

40. Method according to claim 26, wherein said first command identifies a calling party and a called party, the method further comprising:

configuring said second command to represent a call to said calling party;

deriving a third command in said second format from said first command;

configuring said third command to represent a call to said called party;