WO2002031689A1

WO2002031689A1 - Method, arrangement and computer program for providing a network service and user interface

Info

Publication number: WO2002031689A1
Application number: PCT/FI2001/000871
Authority: WO
Inventors: Antti Tapani Nousiainen; Kenneth Christoffer Falck; Jussi Pekka Puhakka; Jyrki Antero Poteri; Juhani Aleksandr Lith; Juha Pekka TÖRÖNEN; Joona Kallio
Original assignee: Sanomawsoy Oyj
Priority date: 2000-10-09
Filing date: 2001-10-09
Publication date: 2002-04-18
Also published as: AU2001295634A1; FI20002227A0; FI20002227A

Abstract

In the method (300) for presenting the second network service as part of a set of first network services, the service request (SR1) is received, which is related to one of the first network services and comprises the identifier identifying the sender of the said service request. After this, identifier-specific status data of the second network service related to the said identifier are determined (302) to modify the service component related to the second network service, relating to the functionality of the user interface of the second network service. The modified service component is connected (305) to the service component related to the said first network service, and the said combined service component is sent (306) to the sender of the said service request. In the method (310) for changing the status of the second network service provided as an independent part of a set of first network services identifier-specific status data are mainitained (312), identifier-specific status data are relayed (313) to modify the service component related to the second network service, a relay request related to the second network service and a certain identifier is received (314), the status data related to the said identifier are updated (315) in accordance with the said relay request, and the answer based on the said status data related to the said identifier is relayed (316) to the sender of the relay request. The arrangements and computer programs corresponding to the methods are also presented; likewise the user interface, which includes the user interface components related to the first network service and the second network service.

Description

Method, arrangement and computer program for providing a network service and user interface

The invention relates to network services provided through a data network.

Network service refers here to such a service, which is provided through a data network by transferring data related to the said network service typically between a server and data terminal equipment. Examples of data networks, which generally are packet networks, may comprise public data networks, such as Internet, or data networks with restricted access, such as intranet inside an organisation, or extranet be- tween organisations. It is typical of the network services that they gather a number of different sub-services to the same place: content and supplementary services. Content services refer here to, for example, news, weather information or articles. Data related to content services may comprise, for example, text, images, graphics, moving images, animation, sound, music, or a combination of these. Supplementary services refer here to e-mail, chat groups and games, among others. It is typical of the network services that they can be used through various kinds of data terminal equipment. For example, a computer provided with a browser program, mobile phone, digital TN receiver, or browser phone, may work as data terminal equipment. A browser program refers here to a program or software, which is able to present data received from a data network to the user through data terminal equipment. Data related to a network service is generally transferred to data terminal equipment and with a browser program, using a suitable data transfer protocol, such as HTTP protocol (Hypertext Transfer Protocol).

A portal service refers to a certain kind of network service, with the help of which the user of the network is able to utilise the amount of data in the network in a more controlled way. The portal aims at being the network user's starting service (or starting page) or anchor page, which the user often visits. The portal service often offers a selection of popular sub-services, for example data search, e-mail, chat groups, news, sports, weather information, yellow pages / classified advertisements, ex- change rates, maps, phone numbers, links divided according to subjects, and shopping sites. The portals usually are either general portals, containing data from several fields, or target group portals, offering services from a certain subject or to a certain group. Problems of the portal services and other network services include, among others, their maintenance and updating and how to get the users to return to the network service in question.

Figure 1 discloses a schematic view of the providing a network service 101, which may comprise, for example, a web site. The user connects to the network service through the network 130, for example Internet, by transmitting, for example, an HTTP retrieval request to the server 110 by using his data terminal equipment, which may be, for example, a palmtop computer 100a, a mobile station 100b, a computer 100c, or a digital television receiver lOOd with remote control. Then the server 110 transmits data to the data terminal equipment 100 in accordance with, for example, the HPPT protocol, the browser program in the data terminal equipment presenting the data to the user. Part of the sub-services provided by the network service is local, i.e. they are provided, for example, with the help of the e-mail server 111, chat server 112, or game server 113 presented in the figure 1. Content services may be provided with the help of the content database 114. For example, a separate organisation may be in charge of the production and updating of the contents of the content database 114, feeding data to the database 114 from its own publishing system and updating the data in the database 114. It is typically desired that the users register to the network service, and the user data can be kept in the user database (or customer database) 115. The network service 100 may be, for example, a portal service or some other network service.

Figure 1 also shows the network service 102, which is provided to the users with the server 120. For example, an e-mail service provided to the users of the network service 102 with the help of the e-mail server 121 is connected to this network service 102. Thus, two e-mail servers 111 and 121 have to be maintained with regard to the network services 101 and 102. It is also possible that the e-mail service is available only to the users of the network service 101. In this case, if the users of the network service 102 wish to use an e-mail service, they have to acquire it through some other network service.

The proyiders of network services try to get the users to register and come back to the network services. For example, the advertising income of the network services often depend on the number of users. Generally a versatile selection of interesting supplementary services and a wide selection of contents attract the users. However, the providing of these supplementary sendees separately in each service presents its own problems. Adding a supplementary service or a content service to the network service always requires development work to be done to the network service itself. The development work may, for example, comprise the adding of one link and WWW page, from which the new content component will be found. Adding a new supplementary service, such as e-mail or chat groups, often requires considerably more integration work. If the same supplementary service is desired to be introduced to a number of existing network services, this development stage has to be carried out separately to every network service. Correspondingly, adding of, for example, a new automatic content flow as a part of several network services requires work to be done to the existing pages of every network service.

It is technically possible to provide the users of the network service 102, for exam- pie, a link to the chat service of the network service 101, for example server 112. However, this kind of solution often requires that the user has registered both to the network service 101 and the network service 102. Secondly, from the appearance of the chat service and the user identification typically required by it separately, the user notices that he is transferring to the other network service 101 from the network service 102. Thus, the provider of the network service 102 does not succeed in making the user to think that the network service 102 provides, for example, the chat service in question. The user may end up using the network service 101 (or some other network service), and will possibly no more return to the network service 102.

Thus, the providing of different kinds of supplementary services as part of the net- work services is often important from the users' point of view. However, adding these supplementary services to the network services and maintaining these requires overlapping work. Even a certain organisation may have to do overlapping work inside the organisation in order to be able to provide certain same supplementary services as part of certain separate network services or when updating the said supple- mentary services. Thus, technical and business-economical problems as well as problems connected with the users are related to the providing of versatile network services.

The object of the invention is to present a flexible and versatile method, system, computer program and user interface for providing the network service.

The objects of the invention are achieved by linking a separate second network service as part of certain first network services so that the said second network service is presented as an independent part of the said first network services; that the user interface of each first network service comprises a user interface component connected with the second network service; and that the said second network service is connected to the first network service when providing the first network service. The invention relates to the method for presenting the second network service as part of a set of first network services, and the said method is characterised in that it comprises the following steps:

- receiving a service request, which relates to one of the first network services and comprises the identifier identifying the sender of the said service request;

- determining identifier-specific status data of the second network service related to the said identifier;

- the first service component related to said first network service and the second service component related to the second network service are combined into a single in- tegrated service component, the second service component being dependent on said identifier-specific status data and being related to the functionality of the user interface of the second network service; and

- said one integrated service component is transmitted to the sender of the said service request.

The invention also relates to the method for changing the status of the second network service provided as an independent part of a set of first network services, the method being characterised in that it comprises the following steps:

- maintaining identifier-specific status data;

- relaying identifier-specific status data to modify a service component related to the second network service in order to combine it with a service component related to the first network service into a single combined service component;

- receiving a relay request related to the second network service and connected with a certain identifier;

- updating status data related to said identifier according to said relay request; and

- transmitting an answer to the sender of the relay request based on said status data and related to the said identifier.

The invention also relates to an arrangement for presenting the second network service as part of a set of first network services, and said arrangement is characterised in that it comprises: - means for receiving the service request that is related to one of the first network services and that comprises the identifier identifying the sender of the said service request;

- means for determining the status data of the identifier-specific status data of the second network service, related to the said identifier;

- means for combining the said first service component related to the first network service and the second service component related to the second network service, depending on the said identifier-specific status data and relating to the functionality of the second network service, into a single combined service component; and

- means for transmitting the said one combined service component to the sender of the said service request.

The second arrangement according to the invention is an arrangement for changing the status of the second network service provided as an independent part of a set of first network services, and it is characterised in that it comprises

- means for maintaining the identifier-specific status data;

- means for relaying the identifier-specific status data in order to modify the service component related to the second network service;

- means for receiving the relay requests related to the second network service and comprising one said identifier;

- means for updating the status data related to the identifiers in accordance with the said relay requests; and

- means for transmitting the answer based on the said status data related to the identifier included in the relay request to the sender of the said relay request.

The invention further relates to two computer programs, which are characterised by that which is specific in the enclosed claims.

The user interface of the network service according to the invention, which comprises the first user interface component related to the first network service, and which is characterised in that it further comprises a second user interface component related to the second network service; and that - said second user interface component is part of the first user interface component in the area of the first user interface component;

- said second user interface component is a graphic user interface component; and

- said second user interface component is arranged to provide a view of the second network service, which is independent of the changes in the status of the first network service presented in the said first user interface component.

The enclosed dependent claims describe some embodiments of the invention.

In this specification and in the enclosed claims, the term first network service refers to a network service, to which a second network service is connected preferably automatically. The first network service may be, for example, some web site. The term second network service again refers to a network service, which is connected to at least one, but typically to several first network services, and which is an own separate functional network service. The set of first network services may thus include one or several first network services. The said second network service typi- cally comprises various kinds of sub-services, such as e-mail service, chat group service, service related to electronic trade, or a number of content services. A second service component, which makes it possible to present said second network service as an independent part of said first network services and which typically comprises a description of the functionality of the second network service, is connected to said first network services, for example, to all WWW pages of a web site. The second service component may be realised by using, for example, the DHTML language (Dynamical Hypertext Transfer Language), which is suitable for presenting certain data and its way of presentation, and a program code, such as JavaScript code, which suits for the implementation of the functions in the user interface. The browser program of the user's data terminal equipment presents the user interface component specific by the second service component as part of the user interface of the first network service.

In order to be able to present the said second network service as an independent network service in connection of several first network services, the status data of the second network service typically have to maintained. In this way, the second network service and the related user interface component can be presented to the user in an unmodified status, for example, as the user chooses another first network service instead of a one first network service. The status data of the second network service are typically maintained by distributing identifiers related to the second net- work service, which, for example, the browser program adds to the service requests related to the first network services and the second network service. It is also possible for the browser program to have an identifier of its own, which it automatically adds to all service requests it sends. Also such an identifier identifying the browser program, which is not expressly generated for the use of the second network service, can be used in the method according to the invention. For example, the said identifier can be added to retrieve requests according to the HTTP protocol in the cookie. If the user wishes to change the status of the second network service (for example, if the user chooses an e-mail service or if he wishes to look at the contents of a certain second network service) and sends a service request related to the second network service, the identifier-specific status data are updated to include the status data of the second network service. The term status data refers here to the changing browser program-specific or user-specific data of the second network service. The status data may thus be connected, for example, both to the appearance or place in the area of the user interface component related to the second network service, and to the view presented by the second user interface component from the second network service and to the service selected last. The status data also typically include information about the current user related to the identifier, if the user is identified at the beginning of or during the session of the second network service. It is alternatively possible that the user is identified during the session of the first network service, and the information about the user is updated to the status data related to the second network service.

The said second network service and its user interface can be adapted according to the user's user profile and/or data terminal equipment, as any network service. In this connection, adaptation refers to the adaptation of the data terminal equipment support of the network service, the appearance, or, for example, the adaptation of the set of sub services provided to the user. One of the advantages of the solution of the invention is that the second network service and/or its user interface can also be adapted according to the first network service. This means, for example, that the second network service connected to one first network service can be presented to the user of the first network service in question in a different way as the second network service related to the second first network service is presented to the user of the second first network service. However, the second service component to be connected to the service components related to these first network services can be the same (the identifier-specific status data deviate from each other, i.e. also the first network service can belong to the status data of the second network service), and the second network service can be provided, for example, from one server to the users of both the first network services. In the solution of the invention, it thus often is sufficient that the second service component is arranged to be automatically connected to the first network services and that the relay of the status data between the server related to the first network service and the server related with the second ser- vice works. Other measures are typically not demanded of the providers of first network services. For example, network addresses or names of the first network services do not need to be changed to add the second network service. In case of known network services, this can be a considerable advantage, and it guarantees that the users will further find the first services in question.

The solution according to the invention can thus be used, for example, to connect certain sub services to the first network services provided by different organisations. In this case, those sub services can be presented to the users of the network service of each organisation as part of the network service in question, and the organisations do not have to separately maintain the said sub services, but the maintenance of the sub services can, for example, be bought from external sources. Thus, one of the advantages of the solution according to the invention is that the said second network service can be maintained and managed in a centralised manner. For example, the updates of the second network service only have to be made once, and they will be seen by the users of all the first network services.

A second example of the use of the solution according to the invention is to provide a versatile, combined general and target group portal. In this case, the second network service may be a virtual portal, providing certain general services that are always available to the user, and the first services may be services directed to different target groups. If the first network services and the said second network service are provided by the same organisation, it is advantageous to use the same user IDs in all the first services and the second service, and to arrange the transfer of the user's identification between the services so that the log-in of the user to one of the first network services or to the second network service is sufficient to automatically open sessions to the user to all the network services in question. Also in connection of other network services besides the virtual portal, the same user IDs can be used in the first network services and the second network service.

The invention is next explained in more detail referring to the enclosed drawings, in which

Figure 1 is a diagrammatic view of a portal service and how to provide it according to the state of the art; Figure 2 presents diagrammatic views of a user interface according to the invention;

Figure 3 presents flow charts of two methods according to a first advantageous embodiment of the invention;

Figure 4 is a diagrammatic view of an arrangement of the first advantageous em- bodiment of the invention;

Figure 5 is a diagrammatic view of a solution according to a second advantageous embodiment of the invention to connect the first and second network services;

Figure 6 is a diagrammatic view of a solution according to a third advantageous embodiment of the invention to connect the first and second network services;

Figure 7 is a more detailed diagrammatic view of a solution of the third advantageous embodiment of the invention to connect the first and second network services;

Figure 8 is a diagrammatic view of a solution according to a fourth advantageous embodiment of the invention to connect the first and second network services;

Figure 9 is a more detailed diagrammatic view of a solution according to a fourth advantageous embodiment of the invention to connect the first and second network services; and

Figure 10 is a diagrammatic view of a method applicable to the transfer of the user's identification.

Figure 1 has been discussed in a section treating the prior art.

Figure 2 shows diagrammatic views of the user interface 200 according to the invention. Figure 2a shows an exemplary graphic user interface component 210, which is the user interface of the second network sendee, shown as part of the user interfaces of the first network services. The user interface component 210 comprises, in an exemplary way, the main menu, the news of which and the links chosen by the user are shown in Figure 2a, and the service menu that the user gets, for example, in the place of the news and links. The services of the second network service are typically presented in the area of the user interface component 210, but it is possible that some sub services provided by the second networ service, such as games, are presented by using also the user interface component 201 of the first network service. The user interface 200 in Figure 2b comprises the user interface component 201 related to the first network service and the graphic user interface component 210 related to the second network service, which is functionally separate from the user interface component 201. The user can, for example, downsize the user interface component 210 so that it is shown as a small icon in the area of the user interface component 201 (Figure 2c). By clicking the icon, the user can typi- cally restore the user interface component 210 to its former form. These are known characteristics of user interface windows. It is possible that the user interface component 201 downsized to an icon presents so-called push data, for example news. Push data refers here to such data that some network service provides at its own initiative (for example, after updating the data in question), without that the user has to separately retrieve the updated data in question.

The user interface component related to the second network service is preferably a floating user interface component. The floating user interface component refers here to such a user interface component that can freely be moved on the display screen or on the user interface component 201. Alternatively, it can be, for example, realised as part of the user interface component 201, for example, as part of a frame so that the manipulation of the user interface component 201, for example, by using the scroll bar 202 affects the location of the user interface component 210 on the display screen of the data terminal equipment (Figure 2d). However, as the user interface component 210 again appears, its status is typically the same as the last time it was displayed.

The second user interface component 210 is arranged to provide a view of the second network service independent from the changes in the status of the first network service presented in the said first user interface component 201. The term view refers here to the features or sub services of the second network service that have been presented with the help of the user interface component 210 at given time.

The user interface component 201 is used for presenting the first network services to the user. If the user transfers from one first network service, to which the second network service is connected, to another first network service, the user interface component 201 presents data related to the other first network service, but the status of the user interface component 210 does preferably not change. In addition, the location of the user interface component 210 in the area of the user interface component 201 does not preferably change in this situation, either.

The floating user interface component can be realised, for example, by Dynamic

Hypertext Markup Language (DHTLM) commands and/or JavaScript. The window functions can be realised by JavaScript commands, with which the characteristics, methods and transactions of HTML elements, provided by the object model of the DHTML, are processed. The program code producing the functionality of the floating user interface component is then typically transmitted by the HTTP protocol and as text commands to the user's browser program. Certain requirements are then di- rected to the ability of the user's browser program to interpret JavaScript and DHTML commands. On the other hand, any browser program using, for example, the HTTP protocol can display the realisation of the integration of the first network service(s) and the second network service, if only it can interpret the commands related to the floating user interface component. For example, the version 4 (or newer) of Microsoft Internet Explorer and the version 4.07 of NetScape Navigator can display the floating user interface component 210 realised by using the JavaScript and DHTML commands.

One of the strong features of the user interface component related to the second network service is its possibility to load contents irrespective of the first network service presented in the user interface component 201, such as a WWW page. In other words, the user can manipulate the user interface component of the second network service; for example, browse the pages of the second network service with the help of the user interface component 210 without that also the first network service below, for example, a WWW page, is reloaded. The contents of the user inter- face component 210 related to the second network service is typically dynamic, and it is produced when requesting the sub service in question. Typically, the view of the user interface component 210 of the second network service can be updated, and contents can be retrieved to the user interface component without retrieving again the network service presented in the user interface component 201.

It is possible that the browser program presents the user simultaneously with two user interfaces 200a and 200b, for example, in different browser windows. In this case, the first user interface component 201a of the user interface 200a can be related to the first network service, and the first user interface component 201b of the user interface 200b can be related to the second first network service. The second user interface component 210a, 210b of both the user interfaces can be related to the same second network sendee. It is possible that, in a situation like this, one of the second user interface components 210a, 210b is not updated, as the status of the second network service is changed through the other.

Figure 3 presents flow charts of two methods 300 and 310 according to the first ad- vantageous embodiment of the invention. The method 300 is a method for presenting the second network service as part of a set of first network services. At 301, a service request SRI related to a first network service is received, including the identifier ID identifying the sender of the service request. At 302, the status data SI(ID) related to the identifier ID of the second network service are determined. At 303, the service component SCI, for example, an HTML page, related to the first network service is retrieved. The service component SC2 related to the second network service, typically comprising the functionality of the user interface of the second network service, is usually locally retrievable. At 304, the service component SC2 is adapted on the basis of the status data SI(ID) of the second network service. At 305, the service components SCI and SC2(SI(ID)) are combined into one service com- ponent CC, which is transmitted to the sender of the service request SRI at 306.

The method 310 is a method for changing the status of the second network service provided as an independent part of a set of first network services and for providing a sub service of the second network service. For example, if the browser programs do not automatically have identifying identifiers that they could connect to the service requests, an identifier ID related to the second network service can be created at 311. The ID identifier is created, for example, in a case in which a service request SRI does not include the ID identifier. The ID identifier is typically delivered to the user (or browser program), which saves it for further use. The ID identifier can be delivered to the browser program, for example, as part of a cookie. Cookies gener- ally operate so that, after receiving a cookie from a server, the browser program will connect the cookie in question to all service requests it has transmitted to the said server or to the servers in the same domain. The identifier ID in question is used for maintaining status data (312), including, among others, the user's identifier, the data included in the personisation of the user interface component of the second network service, and the latest view of the second network sendee to the second network service in question. At 313, the status data SI(ID) is relayed; this is typically done to adapt the service component SC2 to correspond to the latest status data SI(ID). At 314, the relay request related to the second network service is received, which typically includes the ID identifier, or which can otherwise be connected to a certain ID identifier. This relay request is usually transmitted by a second server after the service request SR2 related to the second network service and transmitted by the user/browser program. After the reception of the relay request in question, status data SI(ID) are updated at 315, and an answer V corresponding to the relay request is transmitted to the sener that sent the relay request. It is possible that the relay re- quest is processed locally in one sener: this means that the sender notices that the user desires a sub service of some other network senice, and the server in question is in charge of at least the provision of the sub service in question. Figure 4 shows a diagrammatic view of two arrangements 400 and 410 according to the first advantageous embodiment of the invention. The arrangement 400 is an arrangement for presenting the second network as part of a set of first network services, and it comprises the equipment 401 for receiving the service request SRI re- lated to the first network service and comprising the identifier ID related to the second network senice; the means 402 for determining the identifier-specific status data SI(ID) of the second network service and related to the said identifier ID; the means 405 for combining the first service component SCI related to the said first network service and the second senice component SC2 related to the second net- work service, depending on the said identifier-specific status data and related to the functionality of the second network service into one combined service component; and the means 406 for transmitting the one combined senice component to the sender of the said service request. The arrangement 400 further typically comprises the means 403 and/or 404 for retrieving the service components SCI and SC2, ei- ther locally or from another server. The arrangement 400 typically comprises also the means 407 for receiving the service request SR2 related to the second network service, and the means 408 for retrieving the sub senice according to the service request SC2 in question (typically) from another server.

The arrangement 410 is an arrangement for changing the status of the second net- work service provided as part of a set of first network services. It may comprise the means 411 for creating the identifiers ID related to the second network service. The arrangement 410 typically comprises the means 412 for maintaining the identifier- specific status data SI(ID), the means 413 for relaying the identifier-specific status data SI(ID) to adapt the senice component SC2 related to the second network ser- vice; the means 414 for receiving the relay requests related to the second network senice, typically comprising one said identifier ID; the means 415 for updating the status data SI(ID) related to the identifiers according to the said relay requests; and the means 416 for transmitting the answer N based on the said status data related to the identifier to the sender of the said relay request.

The means 401-408 and 411-416 have typically been realised as program components. It is possible to modify the arrangements 400 and 410 and the means 401-408 and 411-416 so that a method according to any presented embodiment of the invention can be realised with the help of these.

Figures 5, 6 and 8 present different solutions for combining the first and second network senice. These figures show in an exemplar}' manner the servers 520a, 520b and 520c related to three first network services. The server 510 is in charge of the production of the second network service. For the sub services related to the second network senice, the servers 511, 512 and 513, which may, for example, be e-mail, chat group and game servers, are connected to the server 510. Also the database 514 related to the production of content services is connected to the server 510. If it is desired that the users register to the second network service, as is generally the case, user data is maintained in the user database 515. For example, the database 516 and related update and information retrieval components can be used for maintaining the status data. The server 510 comprises, for example, the arrangement 410 for changing the status of the second network service provided as an independent part of the first network service and for providing the services in the second network service.

Figure 5 is a diagrammatic view of a solution according to the second advantageous embodiment of the invention for combining the first and second network service. In Figure 5, the service requests SRI related to the first network services are directed to the front-end server 501. Also the service requests related to the second network service are directed to the front-end sener 501 in Figure 5. This front-end server comprises, for example, the arrangement 400 for combining the service components of the first and second network service. In the solution presented in Figure 5, the status data SI(ID) is delivered from the server 510 to the sener 501 typically as a response to a status data request, and also data related to the sub services of the sec- ond network service are relayed to the server 501.

The service requests SRI related to the first network services can be automatically directed to the front-end server 501, for example, by changing the IP addresses of the domain names related to the first network senices on the name server to the IP address of the front-end sener 501. The front-end sener 501 typically retrieves the network senices according to the senice requests SRI from the servers 501, for example, by using commands according to the HTTP protocol. The fact that the network services from the servers 520 are retrieved to the user through the front-end sener 501, does not typically require changes to be made to the seners 520 or to the first network services. The solution according to Figure 5 can thus be realised, for example, without changing the first network services or, for example, without installing any new program components to the seners 520. The service component SC2 related to the functionality of the user interface of the second network service can be saved locally in the front-end server 501. If the service component SC2 in question is updated, the updating of the service component SC2 saved in the front- end server 501 is easy. Figure 6 is a diagrammatic view of a solution of the third advantageous embodiment of the invention for combining the first and second network service. In this solution, the server 510, which is related to the second network service, operates simultaneously as the front-end server. As is shown in Figure 6, the server 510 comprises in this case typically the arrangements 400 and 410. The senice components related to the first network services are retrieved from the servers 520, typically according to the HTTP protocol. Also in this solution, the updating of the service component SC2 related to the second network service is easy, as it is only found on the server 510. No changes need to be done to the servers 520 or the first network services in the solution of Figure 6, either. In the solution of Figure 6, the service requests related to the first network services can be directed automatically to the server 510 with the help of the name service in a similar way than to the server 501 in the solution presented in Figure 5.

Figure 7 is a more detailed diagrammatic view of a solution according to the second or third advantageous embodiment of the invention for combining the first and second network service. In this example, the first network service is in an exemplary manner a web site, and for example, the utility services of Microsoft IIS, the main program programmed with the VBScript to the ASP page (Active Server Page), and COM+ components are used for modifying the service component related to the first network service.

The arrow 701 shows the service request SRI or SR2, which is directed, for example, to the front-end server 501 and is, for example, an HTTP request. At 702 it is determined, whether the service request is used for requesting a WWW page of the first network service or a sub service related to the second network service. If this concerns a sub service related to the second network senice, it is delivered (arrow 703) to the user typically after it has been retrieved from the server 510, which can be a separate server or the same server with the front-end server 501. If the requested service is a WWW page of the first network senice, the service component related to the first network service can be retrieved from the server 520 by using, for example, the utility senices of Microsoft IIS. Typically, one tries to retrieve the service primarily requested from the second service component SC2 or from the content pages of the second network senice. If no page corresponding to the HTTP request is found from there, the utility service of IIS can be used to trigger the execution of an ASP page, for example (arrow 704).

The arrow 705 shows how the said ASP page requests the COM+ component to retrieve the WWW page of the first network sendee from the server 520. The arrows 706 and 707 present this retrieval typically carried out with the HTTP protocol. The said COM+ component delivers the received message, typically an HTTP message, for example to the ASP page. After this, the ASP page can call, for example, another COM+ component, which modifies the contents and headers of the retrieved, WWW page (arrow 709). The modification is carried out, for example, so that it is possible to get the cookies transmitted by the first network service (server 520) to the user and to retrieve images and other files directly from the server 520. It is possible that part of the files (especially files the second network service is not sensible to show or cannot be shown as part of) is retrieved directly from the server 520 in- stead of the front-end server 501. This can be done, for example, by modifying the links referring to these files to refer directly to the server 520. The arrow 710 shows how the ASP page retrieves a code related to the functionality of the user interface component related to the second network service and connects it to the WWW page retrieved from the server 520. The code itself or its parameters or other data trans- mitted with it are typically modified according to the status data SI(ID) before linking the code to the WWW page retrieved from the sener 520. The arrow 711 shows how the WWW page retrieved from the server 520 and the code combined to it are transmitted to the user, typically according to the HTTP protocol. It is possible that the said code is only linked to the HTML pages retrieved from the server 520; for example, image files, Java applets and other files can be delivered as such to the user.

At 706 it may be necessary to change, for example, the names of the cookies (i.a. ASPSESSIONID and SITESERVER) reserved by Microsoft Internet Information Server to avoid conflicts. Respectively, as the cookies transmitted by the user's browser are relayed from the front-end sener 501 to the sener 520, the cookies are typically changed (for example, at 709) back to the same cookies.

The contents of the second network service are typically produced dynamically, for example, by retrieving them from a separate database. The components retrieving the data can be, for example, Windows 2000 COM+ components realised by Micro- soft Visual Basic. In the solution presented in Figure 5 (and also in Figure 8), in which the contents of the second network senice are retrieved to the front-end server 501 (or to the server 520 in Figure 8) from the sener 510, these contents can be retrieved, for example, by using commands according to the HTTP protocol. The contents of the second network service can be retrieved from the server 510, for ex- ample, by transmitting the method call as an XML message to a secured URL (Uniform Resource Locator), which is the URL for the sener 510. In Figures 5, 6 and 8, the server 510 again typically retrieves the contents from the database 514. The record from the database is preferably modified into XML format (Extensible Markup Language). The data in the XML format is combined (either in the front-end server 501 in Figure 5 or in the server 510 in Figure 6), for example, into an XSL file (Extensible Stylesheet Language) realised for the purpose so that an HTML/JavaScript page (arrow 703) to be sent to the user is got.

Naturally, using XML to relay data and using XSL to modify the presentation of data offers a possibility to format the data/contents to be returned in different ways, for example, to different data terminal equipment types. It is also possible to use other alternative ways to modify the second network senice on the basis of the user, the data terminal equipment type or the first network service.

Figure 8 is a diagrammatic view of a solution according to the fourth advantageous embodiment of the invention for combining the first and second network service. In this solution, the service requests SRI related to the first network services are di- rected directly to the servers 520. These servers 520 contain, for example, the arrangement 400 to combine the service components SCI related to the first network services and the service component SC2 related to the second network service. In this solution, the servers 520 typically request the server for the status data SI(ID) after having received the senice request SRl(ID). In the solution in Figure 8, the service requests SR2 related to the second network service are also directed to the servers 520 according to that to which first network service the second network service presented to the user has last been connected.

In the solution according to Figure 8, the service component SC2 related to the second network service has generally been saved locally in the servers 520. Because of this, the updates for the certain service component must generally be done separately on each server 520. In addition, the servers 520 typically have to have a connection either to the server 510 or directly to the status database 516 so that they get identifier-specific status data, for example, after having received a service request related to the first network service. In the solution of Figure 8, the connection to the sener 510 is typically needed also for retrieving the sub services related to the second network service in order to deliver them to the user.

Figure 9 is a more detailed diagrammatic view of a solution according to the fourth advantageous embodiment of the invention for combining the first and second network service. In this example, the first network service is, for example, a web site, and for example, the utility senices of Microsoft IIS, the main program pro- grammed to the ASP page (Active Server Page) by VBScript, and COM+ components are used for modifying the service component related to the first network service.

The arrow 901 is a service request that is directed directly to the server 520. At 902 it is found out whether a WWW page of the first network service or a content page of the second network service is retrieved. If a WWW page of the first network service (arrow 903) is retrieved, the service component SC2 (which is modified according to the status data SI(ID)) related to the functionality of the user interface component of the second service is linked to it (arrow 904). The service component SC2 can be added to a WWW page of the first network service, for example, by using the Sener Side Include command. The WWW page in question and the service component SC2 linked to it are delivered to the user according to the HTTP protocol (arrow 905).

If a content page of the second network service is retrieved (arrow 906), the con- tents are requested (arrow 907) dynamically from the COM+ components, which again retrieve them from the server 510 according to the HTTP protocol, for example, as XML messages, which are transmitted to an encrypted URL indicating the server 510 (arrows 908, 909). The COM+ component returns (arrow 910) the contents to the IIS server, which modifies an HTTP answer from the contents, for ex- ample, by using an XLS file. The arrow 911 describes the transmission of the page related to the second network service to the user according to HTTP protocol.

If the second network service, which is connected to one or several first network services, is provided by using the HTTP protocol for relaying the network services from the servers to the browser program, the following problem has to be solved. The HTTP communication between the browser and the server is in its basic form stateless, and no fixed connection or session is found between them, the status data of which could be maintained on the server. In other words, the server answers blindly to the requests it receives.

In order to make the second network service, which is connected to the first network service, operate as an independent senice, data on the status of the second network service (for example, size or location of the user interface window in the browser window or the contents of the user interface window) has to be relayed, for example, to the browser or to the server, in which the service component SC2 is linked to the data component related to the first network service. In addition, answers to the service requests concerning the second network service must also typically be modified according to the status data SI(ID).

For example, data identifying the user or the browser can be transmitted in the header of the HTTP retrieval message with different generally agreed parameters (i.a. cookies). A cookie typically identifies only the browser, because for example in computers, which are in common use, the identification of the user on the basis of the mere browser is not reliable. The cookies generally operate so that if a server has delivered a cookie to the browser, the browser connects the cookie in question always (until the validity time for the cookie terminates or the cookie is removed) to the HTTP retrieval message it transmits to that sener. According to the Internet standards, a cookie received from a certain server can only be transmitted to servers in the same domain: for example, a cookie from the address www.pl.fi_can be transmitted to the servers chat.pl.fi and email.pl.fi., but not to the servers pl.p2.fi or www.p2.fi.

The mere cookies do thus not solve the problem concerning the relay of the status data of the second network service operating on top of the HTTP protocol, because a certain browser can be used at different times by several users, and the status of the second network senice cannot be deducted from the mere data relayed in the cookie. The status data typically has to be maintained, for example, by using the da- tabase 516 and according to the method 310. The ID identifying the browser program can be relayed by using the cookies, for example, in the following way.

A unique identifier ID is generated to each browser using the second network service. These identifiers are generated, for example, in the server 510. This browser identifier is delivered, for example, to the browser program in the cookie from the second network senice, for example, the server 501 (the solution according to Figure 5); 510 (the solution according to Figure 6); or 520 (the solution according to Figure 8). The browser program links the cookie and identifier ID typically to all HTTP requests sent by it and related to the second network service. In order to check the authenticity of the identifier, the cookie may be, for example, provided with a verification calculated by the MD5 hash function equipped with a secret key k: v = hash(k,ID). The value of this verification v can be checked by such a server that knows the said secret key. Typically, data on the possible secret key k has to be delivered to the servers receiving and processing the service requests related to a certain second network service and to be connected to the first network senice (to the servers 520 in the solution in Figure 8, and to the sener 501 in the solution in Figure 5). The status data of the second network service are typically maintained in a session management system, which is, for example, a database. The status data are maintained for each identifier ID: for example, the location and size of the user interface component, the view presented of the second network senice by the second user in- terface component, etc. The status data only comprise the information which is necessary for determining the status of the user interface of the second network service. This status data is typically retrieved as the service component SC2 is linked to the senice component of the first network service, and on the basis of the status data, either the service component SC2 is modified, or the status data in question is re- layed to the browser program together with the service component SC2.

It is possible that the user is identified also, for example, as part of the log-in to the second network service. In this case, besides status data of the second network service, also user data can be combined into the ID identifier in the session management system. The identification of the user makes it possible to adapt the second network service according to the user. Also data on the data terminal equipment or browser program can be saved in the status data, in which case it is possible to adapt the second network senice also on the basis of the type of the browser program or the type of the data terminal equipment. For example in HTTP requests, information on the data terminal equipment comes in the headers. The browser program con- nects the identifier it wishes to the headers.

Typically, the following steps are adopted in the solution of the invention. As the browser program transmits a senice request, for example an HTTP retrieval message, it links the identifier ID (and generally also the verification) to the service request; for example in connection of an HTTP retrieval message, the identifier and verification are preferably combined as a cookie. The sener receiving the service request checks, if the cookie with the identifier ID and possibly the verification v is included. If this is the case, identifier-specific status data is then retrieved on the basis of the identifier. The service component SC2 is then modified according to the status data, or the status data is transmitted to the browser program along with the senice component SC2.

Because the cookie usually has to be received from the network senice (or from a network service connected to the same network area), to which the transmitted HTTP request relates, for example in the solution in Figure 8, the cookie transmitted by the second network service is not necessarily connected to the HTTP request re- lated to the first network senice. Thus, it is possible that the received senice request does not include the identifier ID identifying the browser program. Figure 10 is a diagrammatic view of a method suitable for the transfer of the user's identification, i.e. of a method, with which the identifier ID is relayed to the user.

The arrow 1001 presents the service request SRI related to the first network service or the service request SR2 related to the second network service, for example, a re- quest according to the HTTP protocol. At 1002, it is checked if the service request includes the identifier ID and the possible verification v. If both are included in the request, and if the verification matches, the first and second network service are then combined (arrow 1003), for example, in a manner presented above in Figure 9. The arrow 1004 presents the retrieval of the identifier-specific status data, for ex- ample, from the sener 510 or, for example, directly from the database 516. The arrow 1005 presents the transmission of the first and second network service (or only of the second network service, if the service request was related to the second network service) to the user/browser program.

If the service request does not include the identifier ID, or if the verification v does not match, the browser program is preferably automatically directed to the second network service (for example with an HTTP redirect message). Because the browser program send the service request related to the second network service due to the redirection, it can add a cookie related to this second network service to the service request. At 1007, the second network service, for example, the server 510, checks the identifier and verification of the cookie possibly added by the browser program. If the identifier and the verification are all right, they are read from the cookie. If the identifier and the verification do not match, or if either one is missing, new ones are created. The user/browser program is directed back to the first network senice, for example, to the sener 520 (arrow 1008). If a new identifier and verification were created to the user, they are linked to the redirection request as a cookie given by the second network senice. In connection of this redirection, the identifier ID (and verification v) are also transmitted to the first network service, for example, the sener 520. The first network service creates a new cookie, to which it connects the identifier ID (and verification v) sent by the second network senice, and connects (arrow 1009) this new cookie to the page to be sent to the browser program.

If the browser program does not connect the identifier ID (and verification v) to the service request related to the second network senice, either (arrow 1006), at 1007, it is typically stated (arrow 1010) that a new identifier ID (and verification v) has to be created. As the new identifier ID (and verification v) is created, it is/they are saved, for example, in the database 516 (arrow 1011). After this (arrow 1012) one proceeds typically in a similar way as from 1008 forwards. The figures 5 and 8 show how the service requests related to the second network service are directed to the front-end server 501 (Figure 5) or to the server 520 related to the first network services (Figure 8), and not directly to the server 510 related to the second network service. One reason for this is that the data security set- tings of the browser program do not necessarily allow the content component retrieved directly from the server 510 to be combined to the service component related to the functionality of the user interface component of the second network service, for example a JavaScript program code, from the second server (for example, the sener 501 in Figure 5, or the server 520 in Figure 8).

However, it is possible, for example if the browser program allows it, to combine the service components retrieved from different network senices or servers, for example, if the data security point of view is taken into account digitally by signing the service components, that the service requests SR2 related to the second network senice are directed directly to the second network service, for example, the server 510. In this case, the arrangement 400 does not have to include the means 407 and 408, and the means processing the relay requests of the arrangement 410 process the service requests SR2. The advantage of this solution is that the service requests related to the second network senice and the delivery of the sub services in question do not burden the first network services or the servers in charge of these.

In this specification and in the enclosed claims, the term user can refer either to the user of the data terminal equipment or the process carried out in the data terminal equipment. Identifying the user may mean, for example, the identification of the user of the data terminal equipment (for example by using a password) or the identification of a process or terminal equipment (for example on the basis of crypto- graphic methods and data saved beforehand in the terminal equipment or the peripheral devices connected to it). The term sender of the senice request typically refers to the browser program process in certain data terminal equipment or in the server related to the sener process of a certain network service.

Claims

1. Method (300) for presenting a second network senice as part of a set of first network services, characterised in that it comprises the following steps:

- receiving (301) a senice request (SRI) that relates to one of the first network ser- vices and comprises an identifier identifying the sender of said service request;

- determining (302) identifier-specific status data of second network service related to the said identifier;

- combining (305) the first senice component related to a first network service and the second service component related to the second network service, said second senice component depending on the said identifier-specific status data and relating to the functionality of the user interface of the second network service, into one combined senice component; and

- sending (306) said one combined service component to the sender of the said service request.

2. Method according to claim 1, characterised in that it further comprises the following steps:

- receiving a service request that relates to a second first network service and comprises said identifier;

- combining a service component related to the second first network service and the second service component related to the second network service, said second service component depending on the identifier-specific status data, into a second combined senice component; and

- sending the said second combined service component to the sender of the service request related to the second first network sendee.

3. Method according to claim 1, characterised in that all service requests sent by the data terminals and related to a certain first network senice are received.

4. Method according to claim 3, characterised in that it further comprises the followdng step:

- if the received senice request, which is related to the first network service, does not include the identifier, the sender of the sendee request is directed (1006) to send the sendee request related to the second network service in order to relay the identifier from the second network senice to the first network service; and

- receiving (306) a message comprising the identifier.

5. Method according to claim 4, characterised in that the service requests comprise cookies and the identifier is relayed in the cookies, and that it further comprises the following step:

- sending a cookie comprising the identifier received in the said message to the sender of the ervice request.

6. Method according to claim 1 , characterised in that if the first service component is a WWW page, the said first service component and the second service component are combined into said combined service component.

7. Method according to claim 1, characterised in that it further comprises the following steps:

- identifying the type of the data terminal equipment that sent the service request; and

- adapting the second service component according to the type of the data terminal equipment.

8. Method according to claim 1, characterised in that it further comprises the following steps:

- identifying the user, who uses the data terminal equipment that transmitted the service request; and

- adapting the second service component according to the user.

9. Method according to claim 1, characterised in that it further comprises the following step:

- adapting the second senice component on the basis of the first network service.

10. Method according to claim 9, characterised in that it further comprises the following steps: - identifying the user, who uses the data terminal equipment that sent the said service request; and

- adapting said second senice component according to the user.

11. Method according to claim 9, characterised in that it further comprises the following steps: - identifying the type of the data terminal equipment that sent the senice request; and

12. Method according to claim 1, characterised in that it further comprises the following steps:

- receiving a second service request (SR2), which relates to the second network service and comprises the identifier - updating status data related to the identifier according to the second service request; and

- sending to the sender of the second service request a senice component according to the status data related to the identifier.

13. Method according to claim 1, characterised in that - the senice request related to the first network service is received in the first server (520); and

- the first service component and the second senice component are combined into one service component in the said first server.

14. Method according to claim 13, characterised in that it further comprises the following steps:

- saving the second service component in said first server;

- receiving status data related to the said identifier in said first server; and

- modifying the second senice component on the basis of said status data.

15. Method according to claim 13, characterised in that it further comprises the following steps:

- ralaying the identifier data to the second server (510); and

- receiving said second senice component sent from the said second sener in the said first sener.

16. Method according to claim 1, characterised in that - the senice request related to the first network service is received in the second server (510); and

- the first senice component and the second senice component are combined into the one service component in the second server; and that it further comprises the following step: - retrieving the first service component to the said second server.

17. Method according to claim 1, characterised in that

- the senice request related to the first network service is received in a third server (501); and - the first service component and the second service component are combined into the one service component in the third server; and that it further comprises the following step:

- retrieving the said first service component to the third server.

18. Method according to claim 17, characterised in that it further comprises the following steps:

- saving the said second senice component in the third sener;

- receiving status data related to the said identifier in the third server; and

- modifying the second service component according to the status data.

19. Method according to claim 17, characterised in that it further comprises the following steps:

- relaying the identifier to the second sener; and

- receiving the second service component sent from the second server in the third sener.

20. Method according to claim 1, characterised in that the second service component comprises a program suitable to be run in the data terminal equipment

21. Method according to claim 20, characterised in that the second service component is at least partly Dynamic Hypertext Markup Language and/or JavaScript programming language.

22. Method according to claim 20, characterised in that the combined service component is sent by using the data transmission protocol meant for the data transmission between the server and the browser program.

23. Method according to claim 22, characterised in that the combined service component is sent according to HTTP protocol.

24. Method (310) for changing the status of the second network service provided as part of a set of first network services, characterised in that it comprises the following steps:

- maintaining (312) identifier-specific status data;

- relaying (313) identifier-specific status data for modifying the service component related to the second network service to combine it together with a service component related to a first network service into one combined service component;

- receiving (314) relay request related to the second network service and a certain identifier; - updating (315) status data related to the identifier according to the relay request; and

- relaying (316) to the sender of the relay request an answer based on the status data related to the identifier.

25. Method according to claim 24, characterised in that it further comprises the following step:

- creating (311) identifying identifiers related to the second network service.

26. Method according to claim 24, characterised in that the relay request and the answer are in accordance with a certain data transmission protocol.

27. Method according to claim 26, characterised in that said service request and the answer are in accordance with the HTTP protocol.

28. Arrangement (400) for presenting the second network service as part of a set of first network services, characterised in that it comprises

- means (401) for receiving a sendee request, which is related to one of the first network services and comprises the identifier identifying the sender of the service request;

- means (402) for determining identifier-specific status data of the second network senice related to the said identifier;

- means (405) for combining a first service component related to the one first net- work service and a second service component related to the second network service, the second service component depending on the identifier-specific status data and relating to the functionality of the user interface of the second network senice, into one combined senice component; and

- means (406) for sending the one integrated service component to the sender of the said service request.

29. Arrangement (410) for changing the status of the second network service provided as part of a set of first network services, characterised in that it comprises

- means (412) for maintaining identifier-specific status data;

- means (413) for relaying identifier-specific status data to modify the service component related to the second network senice;

- means (414) for receiving relay requests comprising one said identifier and related to the second network service;

- means (415) for updating the status data related to the identifier in accordance with the relay requests; and - means (416) for sending the answer based on the status data related to the identifier to the sender of the said relay request.

30. Computer program for presenting a second network service as part of a set of first network services, the computer program comprising means realised as com- mands suitable to be run in a computer for carrying out all the said steps mentioned in claim 1, when the computer program is run on a computer.

31. Computer program for changing the status of a second network service provided as part of a set of first network services, the computer program comprising means realised as commands suitable to be run in a computer for carrying out all the steps mentioned in claim 24, when the computer program is run on a computer.

32. User interface (200) of a network service, comprising a first user interface component (201) related to a first network sendee, characterised in that it further comprises a second user interface component (210) related to a second network service, and that - the second user interface component is a part of the first user interface component residing in the area of the first user interface component;

- the second user interface component is a graphic user interface component; and

- the second user interface component is arranged to offer a view of the second network service independent from the changes in the status of the first network service presented in the first user interface component.

33. User interface according to claim 32, characterised in that the second user interface component is arranged to display the status of the second network senice and/or to offer means for changing the status of the second network service.

34. User interface according to claim 32, characterised in that the first user inter- face component is arranged to display the status of the first network service and/or to offer means for changing the status of the first network senice.

35. User interface according to claim 32, characterised in that the second user interface component is a floating user interface component.

36. User interface according to claim 32, characterised in that the second user in- terface component is downsizeable to an icon in the area of the first user interface component.

37. User interface according to claim 32, characterised in that the second user in-, terface component is arranged to display the status of the second network service irrespective of the change of a one first network service related to the first user interface component to a second first network service related to the first user interface component.

38. User interface according to claim 32, characterised in that the second user interface component is at least partly realised in a language meant for presenting the data and/or as a program suitable to be run in the data terminal equipment.

39. User interface according to claim 38, characterised in that the second user in- terface component is realised in Dynamic Hypertext Markup Language and/or

JavaScript programming language.