WO2002051178A1 - Centralized session management - Google Patents

Centralized session management Download PDF

Info

Publication number
WO2002051178A1
WO2002051178A1 PCT/FI2001/001119 FI0101119W WO0251178A1 WO 2002051178 A1 WO2002051178 A1 WO 2002051178A1 FI 0101119 W FI0101119 W FI 0101119W WO 0251178 A1 WO0251178 A1 WO 0251178A1
Authority
WO
WIPO (PCT)
Prior art keywords
session
client
application
information
characterized
Prior art date
Application number
PCT/FI2001/001119
Other languages
French (fr)
Inventor
Markku Koskela
Original Assignee
Sonera Oyj
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to FI20002821 priority Critical
Priority to FI20002821A priority patent/FI20002821A/en
Application filed by Sonera Oyj filed Critical Sonera Oyj
Publication of WO2002051178A1 publication Critical patent/WO2002051178A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00
    • H04L29/02Communication control; Communication processing
    • H04L29/06Communication control; Communication processing characterised by a protocol
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/14Network-specific arrangements or communication protocols supporting networked applications for session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32High level architectural aspects of 7-layer open systems interconnection [OSI] type protocol stacks
    • H04L69/322Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer, i.e. layer seven

Abstract

This invention relates to the handling of sessions between clients and services. The invention is to use a centralized element for keeping and managing information of the sessions. Each session (client) is identified by a session-specific ID. The application in the server to which the client is connected checks the session's, i.e. the client's, ID from a centralized element, called session management, by sending the ID to the session management. The session management checks that the ID is correct. If it is, the session management sends the session information of the client to the application. When the session information changes from the act of the client and/or the application, the application updates the changes to the session management.

Description

European patent (AT, BE, CH, CY, DE, DK, ES, FI, FR, For two-letter codes and other abbreviations, refer to the "GuidGB, GR, IE, IT, LU, MC, NL, PT, SE, TR), OAPI patent ance Notes on Codes and Abbreviations " appearing at the begin(BF, BJ, CF, CG, CI, CM, GA, GN, GQ, GW, ML, MR, ning of each regular issue of the PCT Gazette NE, SN, TD, TG).

Published:

Centralized Session Management

Field of the Invention

This invention relates to the handling of sessions between clients and services. In particular, the invention relates to the telecommunications field where there can be thousands of clients using the same sen/ice simultaneously. There can also be thousands of different services that are offered to the customers.

Background of the Invention

A session is conceived to be the time period between the login and the logout of a service in a datacommunications network, or the dialing of the phone number and the hanging up of the phone in a telecommunications network. The present evolution goes towards a common network structure, which is capable of transmitting data, voice and audio, i.e. towards a network comprising features of a datacommunications and telecommunications network.

Each session contains session-specific information, such as the phone number, the name of the client, the rights of use, and the state of the session. FIG. 1 shows an example of a known solution to handle the sessions and the session-specific information. Each client 1 has its own process (a copy of the application in use) 2 in a server 3 for offering the service to the client. The client-specific process handles the session information. For example, if the service (application) is a spreadsheet, each client has his own application copy of the sheet and the state of the sheet. The drawback of this solution is that the server must process several copies of the same application.

FIG. 2 shows another example of a known solution to handle the sessions and the session-specific information. In the Web, cookies are the normal way to handle session management. A cookie 21 is a code for identifying the browser 22 so that the process (the web-page application) 23 can identify each browser that is using the application. The server 24 containing the application sends client-specific cookies, which contain client-specific state information. Typically, the size of a cookie is about 2 kbytes. The browser can keep the cookie information in the cache only during the session, or the cookie is saved in the memory of the client for a certain period. The use of URLs (Uniform Resource Locator) corresponds to the use of cookies. URL is a string that gives the location of a piece of information (such as a web-page). Furthermore, URL may contain session-specific information. However, the capacity of URL is less than the capacity of a cookie to carry session information. Drawbacks of the cookie or URL are that they have a low capacity to carry information, and the communication traffic between the client and the server will grow. Furthermore, the client must have the ability to use cookies. In addition, session management is dependent on a client terminal. When the client wants to change something in the web-page (i.e. use the service page), the desired changes are delivered to the application using URL (or a query string technique). Also the cookie is sent back to the server containing the session information. The application is adapted for the client according to the desired changes. In turn, the application updates the cookie, and sends it back to the client. In this way, the session-specific information is sent back and forth between the client and the server, the browsers keeping the session-specific information in their memories.

The aim of the invention is to reduce the drawbacks of the known solutions and to offer a more efficient way to handle session management. These are achieved in a way described in the claims.

Summary of the Invention

The idea of the invention is to use a centralized element for keeping and managing information of the sessions. Each session (client) is identi- fied by a session-specific ID. In the case of a phone the ID can preferably be the phone number. The application in the server to which the client is connected checks the session's, i.e. the client's, ID from a centralized element, called session management, by sending the ID to the session management. The session management checks that the ID is correct. If it is, the session management sends the session information of the client to the application.

When the session information changes from the act of the client and/or the application, the application updates the changes to the session management. Due to the centralization, it is easy to monitor and manage sessions. Furthermore, the clients are independent of the technology used in an application. Brief Description of the Drawings

In the following the invention is described in more detail by means of FIGs 1 - 5 in the attached drawings where.

FIG. 1 illustrates an example of the traditional way to handle session information, FIG. 2 illustrates an example of the prior way to handle session information in a Web-based network, FIG. 3 illustrates an example of the way according to the invention to handle session information, FIG. 4 illustrates an example of where the client uses the services of the application according to the invention, FIG. 5 shows an example of a flow chart that describes the method ac- cording to the invention.

Detailed Description of the Invention

FIG. 3 shows an example of an arrangement according to the invention. When a client 31 wants to use some service 32, he calls the service number (or address). The client terminal is preferably a PC or a WAP phone. The client terminal can also be an SMS terminal, a normal phone, or any other type of device. The service, i.e. the application can be in any server 33 in the network. Actually, it is preferable that a sufficient number of the servers contain their own copy of the application. In this way, the service can be of- fered to very many clients in a large geographical area.

At the beginning of the session, when the client is logging in for using the application 32, the session ID does not exist. Thus the client does not send a cookie or URL containing the session ID which is noticed by the application. Noticing that the session is new, the application asks the session management 35 to create a data storage and session ID for session information. The session management sends the session ID to the application, which is now ready to create, use and update the session information storage in the session management. The application sends the created session ID, 34 to the client (in cookie or URL). When using the service the client sends the session ID to the application. The application checks that the client is ok, by using the session ID 34 (or the phone number) of the client. The checking is done by using the session management 35. The application asks the session information that is identified by using the session ID from the session management, which checks the validity of the ID, i.e. that the data storage that corresponds to the ID exists. If the ID is correct, the session management sends the session information 36 of the client to the application. The session information comprises the client-specific information, such as the client's name, address, phone numbers, state information of the application, and the rights of use. The client's session information of the application is created at the first ses- sion in the application, when the session information needed is saved in the session management.

It is worth noting that the client can actually use several applications during one session. For example, the client can use another application for a while, and then go back to use the originally used application. The ses- sion information keeps state information of both applications (or all applications used in the session) until the client logs out of the session when the session information is deleted in the session management.

The application can use databases 37 in the network for getting necessary information for accomplishing the required service. The state of the application (the session) changes when it is performing its tasks. The changes are saved in the application state information (in the session information). So, the session information needed is sent between the application and the centralized session management. Since the transmission path between the application and the session management is preferably in the net- work part with high capacity, there is no strict limit on the amount of session information. Usually, the path between the application and the session management is also safer than the path between the client and the application. When the session is terminated, the session information is deleted. So, the next time, when the client wants to use the application, a new client-specific session ID and a data storage in the session management must be created.

FIG. 4 shows an example of a calendar service. The client 41 wants to look at his calendar information, so he calls to the calendar service

42. The calendar service has been distributed all over the network, several servers 43 containing the calendar application 42. Preferably the nearest ap- plication handles the call. At the beginning of the session, the client-specific session ID 44 (in this case the WAP phone number) and a session informa- tion data storage 46 are created in the session management 45. The session management keeps a data storage for the session information of the clients. The session ID is sent to the application, which forwards it to the client. When the client uses the calendar, the changes are updated in the session man- agement. The calendar application uses the session ID for requesting and updating the session information. If the ID is valid (the session-specific storage exists), the session management sends the client-specific session information 45, such as the name, time, and date, to the application.

In this case, the application uses a special calendar database 47 for keeping the actual calendar information, such as meetings, holidays, and short memos. The application loads the calendar information from the database, and uses the date information of the session information for creating the calendar service for the client. The client can make necessary changes to the calendar, and the application handles the updating of the changes for the calendar database and for the session management. The application also sends the desired service information to the client.

Client-specific session information must be created in the centralized session management. This is done when the client logs into the service as mentioned before. In the session information configuration, the client gets a session ID, which is used when the client uses the application, for identifying the client and the client-specific information. Further, in the configuration, the session management saves the session information needed for successful running of the application. FIG. 5 shows an example of a flow chart according to the invention, illustrating the method in a running time, assuming that the session information configuration has been done earlier. First, the session ID must be checked 51. As described above, the checking is handled by the cooperation of the application and the session management. The application sends the session ID to the session management, and if the ID is ok, i.e. the session-specific information storage exists, the session manage- ment sends the session information to the application, i.e. the session information is requested 52 by the application. As the session information changes, it must be updated 53 in the session management. The application sends the update information to the session management. The aim is that the application does not keep the session information in its own cache, but in- stead, the session management does, as it has enough capacity to handle session information of several (thousands) clients. Due to this, the requesting and the updating steps must be repeated 54 as many times as needed during the session.

Session information is application state-specific and client-specific information for each application and client. Thus, the session management may contain a number of session information storages for each client, each storage containing the information that the application or applications need during the session.

As mentioned before, clients are independent of the technology used in the applications. Since the clients do not need to receive or keep session information, such as cookies or URLs, they do not need complicated features. Applications use, for example, HTTP-protocol, and the applications have been created using different techniques. For example, an application is a CGI (Common Gateway Interface) application having a connection for client terminals. Other possible application technologies are NSAPI (Netscape Application Program Interface), ISAPI (Internet Service Application Program Interface), and JavaServlet.

Since the session management information is sent in the trunk network with high capacity, it is possible to efficiently use the central session management as a database. The trend seems to be towards services, which need more session management information. The prior art solutions do not offer an efficient way to handle the growth of such services. Further, it is worth noting that the path between the application and the session management usually is safer than the path between the application and the client. For example, CORBA (Common Object Request Broker Architecture) can work as a technological base (interface) for the interworking between the application and the session management.

The invention is not restricted to the examples above. For example, the invention can comprise several session management elements, each of them handling a part of the network. It is worth noting, that in this case the session management elements have to update session information among themselves so that each element has the latest session information. It is evident that the invention can also be used in other solutions, in the scope of the inventive idea.

Claims

Claims
1. An arrangement for handling client-specific session information in a network that comprises at least one client terminal and at least one server, the server comprising at least one service application, whereby said session information is for a session established between a client terminal used by a client and a service application, and whereby the session is the period the client uses the service, characterized in that the arrangement further comprises a centralized element for keeping and managing the session information.
2. An arrangement according to claim 1, characterized in that the arrangement further comprises a session identifier for each session, for identifying the session information, specific for each client.
3. An arrangement according to claim 2, characterized in that the arrangement further comprises at least one connection between the central element and the service applications for transmitting the session information.
4. An arrangement according to claim 3, characterized in that the arrangement further comprises at least one connection between the client terminals and the service applications for transmitting services of the service applications to the client.
5. An arrangement according to claim 4, characterized in that the arrangement further comprises means in the client terminal for sending the session identifier to the application.
6. An arrangement according to claim 2, characterized in that the session identifier is the phone number of the client terminal, the terminal being a phone.
7. An arrangement according to claim 1, 2, 3, 4, 5, or 6, c h a r- acterized in that the arrangement comprises several central elements.
8. A method for handling client-specific session information in a communication network, the session being between a client and a service application in a network, characterized in that the method comprises the step of using a centralized element for creating, keeping, and managing session information of several clients.
9. A method according to claim 8, characterized by cre- ating a session information data storage and a session ID for the session at the beginning of the session.
10. A method according to claim 8 or 9, characterized in that the method comprises for each session the steps of
- checking that the client-specific session information exists using the ID of the session for identifying the session information, - requesting the client-specific session information from the centralized element that keeps and manages the session information, for the use of the application,
- updating the client-specific session information in the central element, when needed, and - repeating the requesting step as many times as needed during the session
- repeating the updating step as many times as needed during the session.
11. A method according to claim 10, characterized in that the checking step comprises the steps of
- sending the session ID from the client to the application,
- sending the session ID from the application to the central element.
12. A method according to claim 8, 9 or 10, characterized in that the method further comprises the step of updating the session specific information among several central elements.
PCT/FI2001/001119 2000-12-21 2001-12-18 Centralized session management WO2002051178A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FI20002821 2000-12-21
FI20002821A FI20002821A (en) 2000-12-21 2000-12-21 The centralized session management

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
AU1926502A AU1926502A (en) 2000-12-21 2001-12-18 Centralized session management

Publications (1)

Publication Number Publication Date
WO2002051178A1 true WO2002051178A1 (en) 2002-06-27

Family

ID=8559781

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2001/001119 WO2002051178A1 (en) 2000-12-21 2001-12-18 Centralized session management

Country Status (3)

Country Link
AU (1) AU1926502A (en)
FI (1) FI20002821A (en)
WO (1) WO2002051178A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009088333A1 (en) 2008-01-11 2009-07-16 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for establishing a streamed media session

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5835724A (en) * 1996-07-03 1998-11-10 Electronic Data Systems Corporation System and method for communication information using the internet that receives and maintains information concerning the client and generates and conveys the session data to the client
US6076108A (en) * 1998-03-06 2000-06-13 I2 Technologies, Inc. System and method for maintaining a state for a user session using a web system having a global session server
US6289333B1 (en) * 1998-01-16 2001-09-11 Aspect Communications Corp. Methods and apparatus enabling dynamic resource collaboration when collaboration session host is distinct from resource host

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5835724A (en) * 1996-07-03 1998-11-10 Electronic Data Systems Corporation System and method for communication information using the internet that receives and maintains information concerning the client and generates and conveys the session data to the client
US6289333B1 (en) * 1998-01-16 2001-09-11 Aspect Communications Corp. Methods and apparatus enabling dynamic resource collaboration when collaboration session host is distinct from resource host
US6076108A (en) * 1998-03-06 2000-06-13 I2 Technologies, Inc. System and method for maintaining a state for a user session using a web system having a global session server

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009088333A1 (en) 2008-01-11 2009-07-16 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for establishing a streamed media session
US8838805B2 (en) 2008-01-11 2014-09-16 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for establishing a streamed media session
TWI506993B (en) * 2008-01-11 2015-11-01 Ericsson Telefon Ab L M Method and apparatus for establishing a streamed media session
EP2418823A3 (en) * 2008-01-11 2016-11-30 Telefonaktiebolaget LM Ericsson (publ) Method and apparatus for establishing a streamed media session

Also Published As

Publication number Publication date
FI20002821A0 (en) 2000-12-21
FI20002821A (en) 2002-06-22
AU1926502A (en) 2002-07-01
FI20002821D0 (en)

Similar Documents

Publication Publication Date Title
US7155519B2 (en) Systems and methods for enhancing connectivity between a mobile workforce and a remote scheduling application
US6298356B1 (en) Methods and apparatus for enabling dynamic resource collaboration
FI105249B (en) Method and arrangement for connecting the information network resources,
US6615263B2 (en) Two-tier authentication system where clients first authenticate with independent service providers and then automatically exchange messages with a client controller to gain network access
CA2160945C (en) Script preprocessing system and method
US6717938B1 (en) System controlling use of a communication channel
US6393467B1 (en) Network interconnected computing device, server and notification method
US6353851B1 (en) Method and apparatus for sharing asymmetric information and services in simultaneously viewed documents on a communication system
US6510463B1 (en) Service quality monitoring process
US6747679B1 (en) Time keeping and expense tracking server that interfaces with a user based upon a user's atomic abilities
US7962575B2 (en) System and method for data synchronization between devices
FI105311B (en) Method and arrangement for finding information
US6567411B2 (en) Method and apparatus for continuous narrowcast of individualized information over a data network
US20020069272A1 (en) System and method for managing server configurations
US5907677A (en) Method for establishing anonymous communication links
US6868444B1 (en) Server configuration management and tracking
US20030061512A1 (en) Method and system for a single-sign-on mechanism within application service provider (ASP) aggregation
JP4336647B2 (en) View and / or update system of Dns server and / or ldap directory
CA2448918C (en) Method and system for automatically configuring a client-server network
US20020138427A1 (en) Systems and methods for communicating from an integration platform to a billing unit
DE69924103T2 (en) A method and network for managing wsp (Wireless Session Protocol) sessions
US5951637A (en) Bandwidth reservation system
US20040181580A1 (en) Method, computer useable medium, and system for portable email messaging
US8576712B2 (en) Method and apparatus for providing a reliable voice extensible markup language service
US6687241B1 (en) Enterprise contact server with enhanced routing features

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP