SE519936C2 - Anordning och förfarande relaterade till sessionshantering i en portalstruktur - Google Patents

Description

25 30 'rå I;_'L f» w |, »u -7 / . - . . .., ; 1* ; -_ 30 ¿«. -.., .. . . ._ .. . . f z . f i fl behöver sessionshantering såsom tillhandahållen av olika sessionshanteringsmedel integreras eller kombineras.

Det finns också ett växande behov» av att personalisera eller kundanpassa det sätt som en slutanvändare kan accessa tjänster på oavsett den faktiska befintligheten för tjänsterna eller applikationerna, eller vem som tillhandahåller dem. Också efterfrågan avseende access till mobila Internettjänster får större betydelse, dvs att slutanvändare vill kunna, på ett snabbt och okomplicerat sätt, få access till tjänster ifrån vilken slutanvändarstation som helst, dvs också ifrån mobila anordningar; det kan exempelvis relatera till att sända och ta emot e-mail, kortmeddelanden, access av web-baserad information från mobila såväl som från fasta slutanvändarapparater på ett användarvänligt, snabbt och enkelt sätt. Detta kallas det mobila Internet.

Browsing med användning av en mobil anordning är emellertid svårare än browsing med användning av en PC, eftersom den mobila anordningen, i med PC:n, har jämförelse begränsad in- och Detta betyder således att det blir ännu svårare tillfredsställande utmatningsförmåga. att förse mobila slutanvändare med såväl som alla personalisering, och hantering av tjänster sessionshantering blir ännu mera komplicerat. Under föreligger en ökande efterfrågan från alltid kunna omständigheter slutanvändarnas sida vad det gäller att accessa applikationer" och tjänster. En. portal är en sådan ingång till innehållet i tjänster och applikationer som speciellt ska vara skräddarsydd för att passa slutanvändarens preferenser.

Exempel på portalinnehåll är informationstjänster (också inkluderande push-innehåll som relaterar till en Internetteknik genom vilken all information som en användare abbonerar på automatiskt tillhandahàlles till användaren, eller information som 10 l5 20 25 30 « 1 « , w 519 956 « . @ . .. » 1 . 1 , . tjänsteleverantören eller operatören tycker att användaren ska förses med). Exempel på informationstjänster är väderrapporter eller väderinformation i. allmänhet, kommersiella tjänster såsom inköpsmallar, generellt sett vilket slag som helst av information, multimediatjänster såsom strömmande audio/video, spel, omedelbar meddelandeöverföring och nyhetsgrupper, web-baserad mail, access till speciella grupper genom “chat-rooms”. Det är också önskvärt att kunna tillhandahålla tilltalande grafiska användargränssnitt för att representera applikationer och menyer på PC:er, och speciellt också för anordningar som stödjer WAP, om en portal är mobil. Mycket ansträngning läggs också ned på personalisering av strukturen och innehållet för personliga portaler, och på att tillhandahålla möjlighet att styra samspelet och uppträdandet för individuella tjänster och applikationer genom att sätta personliga tillhandahålla vilket preferenser. Det är emellertid svårt att tillfredsställande accessmöjligheter oavsett slag av anordning som används av en slutanvändare. Speciellt när olika system behöver integreras, vad det gäller sessionshanteringsfrågor, dvs när olika system (portaler, tjänster/applikationer, andra portaler osv) har sin egen sessionshantering, då kan situationen bli mycket komplicerad.

Fram till nu är många applikationer i princip exklusivt designade för 2G telekommunikationsmiljön och de har implementerats som nwnolitiska block eller med ett proprietärt tjänstenät för att hantera de speciella QOS-kraven för de respektive applikationerna.

Detta har som konsekvens att sådana applikationer fungerar tillfredsställande som isolerade applikationer, men det är svårt att integrera dem med andra applikationer som är utvecklade på liknande sätt. Applikationer som är utvecklade för Internet (Internet Protocol)-miljön har* i stor utsträckning baserats på väletablerade och öppna de facto-standarder som stödjer omfattande integrering av olika applikationer. Många sådana standarder har . . » « > v 10 15 20 25 30 519 936 ~~~~ -- f . . . 1 v använts i 2G-miljön för icke-realtidskritiska applikationer. Genom införandet av 3G-nät (3GPP) kommer emellertid framtida applikationer att innehålla en blandning av telekommunikations-, och datakommunikationstjänster, och blanda högre och lägre bitrater såväl som realtids och icke-relatidstrafik. Dagens tjänstenät är inte designade för att hantera sådana blandningar, inte heller är de existerande IP-baserade applikationerna designade för de specifika kännetecken sonl gäller för trådlösa nät. Såsom kan ses härur finns det många komplicerande faktorer vad det gäller tillhandahållandet av tillfredsställande access för slutanvändare till tjänster, speciellt när sessionshantering hanteras av olika sessionshanterare för olika system/entiteter.

Sessionshantering av homogena portalmiljöer kan specificeras klart och kan exempelvis utföras baserat på Servlet session API (Application Programming Interface) specifikationen eller specifikationen session EJB (Enterprise Java Beans). Dessa specifikationer definierar de grundläggande operationerna för sessionshantering, nämligen att skapa/förstöra en session och att hämta, sätta och ta bort ett nyckel-värdepar i en konstruerad session.

Internetportaler är vanligen försedda med ett sessionshanteringsysten1 son1 medger spàrande av de aktioner som initierats av en slutanvändare. Sådana aktioner kan exempelvis inkludera aktionerna att slutanvändaren går in i systemet, autenticering av slutanvändaren, att slutanvändaren accessar en portaltjänst osv. Så länge som slutanvändaren navigerar inom portalen, dvs begär access till tjänster/applikationer som är interna för portalen, sonl här avser tjänster/applikationer för vilka sessionshanteringen hanteras centralt inom portalen, kan sessionshanteringen hanteras på ett enkelt sätt, eftersom varje portaltjänst kan be en central sessionshanterare, dvs 10 15 20 25 30 519 936 = = » ~ 1 - . . . . . portalsessionshanteringsmedlen, att hämta information som är lagrad i slutanvändarens session. Sessionerna lagras speciellt i lagringsmedel. Emellertid är situationen annorlunda om slutanvändaren begär access till ett externt system eller till en tjänst eller en applikation som är integrerad med portalen, eller en extern tjänst/applikation, som här betyder en tjänst/applikation som har en extern, eller egen, specifik, sessionshantering. Situationen kan då bli mycket komplicerad.

Ett allvarligt problem är att, om en tjänst eller en applikation (eller en annan portal), som en slutanvändare vill accessa via en portalstruktur, har sin egen sessionshantering, då kan den externa sessionshanteringen vara inkompatibel med portalsessionshanteringen. Detta är ofta fallet när applikations/ tjänsteleverantörer erbjuder tjänster till portalägare. Av olika skäl kan det förhålla sig så att det inte är önskvärt att exponera slutanvändaren. Dessutom den externa sessionshanteringen för tenderar skapade sessioner som också tar extern sessionshantering med i beräkningen att bli mycket långa, dvs sessionsidentiteten sonl används i kommunikation lned slutanvändaren lnåste inte bara utan därutöver också den Ofta kan innehålla portalsessionsidentiteten, externa sessionsidentiteten. sådana långa sessionsidentifikationer inte hanteras av klienter som servas av portalen. Detta är speciellt allvarligt om slutanvändarstationen är en mobil anordning, såsom en WAP-anordning, som helt enkelt kanske inte kan hantera sådana stora mängder av data. Även för en slutanvändarstation som kan hantera sådana mängder av data avsedda bara för identifikationsändamål, innebär det ett slöseri med resurser och tid.

REDOGÖRELSE FÖR UPPFINNINGEN Vad som behövs är därför en portalstruktur genom vilken sessionshantering kan hanteras på ett lätt och effektivt sätt, 10 15 20 25 30 519 936 ~~~~ ~ I ~ > , n 6 också när sessionshanteringen för de accessade systemen/tjänsterna/applikationerna hanteras av andra, annorlunda sessionshanteringssystem. Speciellt om en portalstruktur har sin egen portalsessionshanteringsmedel, och ett annat system, såom en tjänst, en applikation eller en annan portal, till vilken en slutanvändare begär access, har sina egna, här betecknade externa, eller proprietära, sessionshanteringsmedel, behövs en enkel och effektiv sessionshantering. Speciellt behövs en sömlös förening (unifiering) av sessionshantering mellan portaler och externt sessionshanterade (externa) system. En portalstruktur behövs också genom vilken sessionshantering som existerar i andra system, såsom tjänster/applikationer eller portaler som sessionshanteras av tredjeparts-sessionshanteringsmedel, eller externa sessionshanteringsmedel, kan kombineras och integreras med portalens sessionshantering.

En anordning behövs också genom vilken sessionshanteringen för en portal (intern) och åtskilliga andra sessionshanteringsförfaranden för tredjeparts-, eller externt sessionshanterade system kan unifieras till en unifierad sessionshantering. Speciellt behövs en portalstruktur som kan förse en slutanvändare med access till tjänster/applikationer för vilka sessionshantering hanteras av externa sessionshanteringsmedel (tredjeparts- sessionshanteringsmedel), dvs inte samma sessionshanteringsmedel som portalsessionshanteringsmedlen, likväl som till interna tjänster/applikationer. En slutanvändare bör således bli försedd med access till tjänster etc oavsett om tjänsterna/applikationerna (innehållet) befinner sig inom portalstrukturen själv, eller om applikationerna/tjänsterna och dess innehåll residerar utanför portalen, dvs tillhandahålles av externa leverantörer och/eller sessionshanteras av externa sessionshanteringsmedel. - ~ ; . f. 10 15 20 25 30 - v » - <- « » - 1 . - - . ; | .

Speciellt behövs en portalstruktur som medger access för mobila slutanvändarstationer (utöver fasta slutanvändarstationer) oavsett om accessade tjänster/applikationer osv sessionshanteras internt eller externt. En portalstruktur behövs också genom vilken antalet parametrar som behöver användas i kommunikation med slutanvändare är reducerat jämfört med för hitintills kända strukturer, och oavsett om accessade tjänster/applikationer residerar inom portalen eller ej, och oavsett om de är separat eller externt sessionshanterade. Speciellt behövs en portalstruktur som är kapabel att integrera olika sessionshanteringsförfaranden på samma gång som den integrerar Internet och WAP-baserade tjänster, så att access är möjlig ifrån vilken Internetansluten PC, WAP-anordning som helst, eller vilken annan mobil anordning som helst som använder vilket mobilt accessnät som helst.

En anordning för att hantera och integrera sessionshantering i en portalstruktur behövs också genom vilken ett eller flera av ovan nämnda mål kan uppfyllas. Dessutom behövs ett förfarande för likväl som ett till hantering av sessionshantering i en portalstruktur, förfarande för att förse en slutanvändare med access tjänster/applikationer, oavsett om dessa sessionshanteras av portalsessionshanteringsmedlen eller av externa sessionshanteringsmedel, genom vilket ett eller flera av ovan nämnda mål kan uppfyllas.

Genom att använda ett generiskt “markup”-språk i en portal, kan innehåll i applikationer och tjänster lagras oberoende av slutanvändarstation eller slutanvändaranordning, och innan innhållet i en applikation eller en tjänst visas, kan innehållet transformeras till det format, dvs det “markup”-språk som kan förstås av slutanvändaranordningen. Ett exempel på ett sådant generiskt “markup”-språk är XML (Extended Markup Language). Såsom en standard för navigering i en XML-baserad portal används XLink - | « V .p 10 15 20 25 30 - ~ 4 « 4 . ~ . . , u specifikationen, vilken tillåter element att införas i XML- dokument för att skapa och beskriva länkar mellan resurser. XLink tillhandahåller ett ramverk för att skapa både grundläggande enkelriktade länkar och mera komplicerade länkstrukturer. Det medger XML-dokument att etablera länkförhållanden mellan fler än två resurser, att associera metadata med en länk och att utrycka länkar som residerar på ett ställe som skiljer sig ifrån den länkade resursen. 6 oktober 2000, XML beskrivs i. W3C Recommendation, Extensible Markup Language (XML) l.O (andra utgåvan), som härmed inkorporeras häri genom hänvisning därtill.

I det följande kommer några begrepp som används i detta dokument att beskrivas eller definieras. En portal är i allmänhet en icke fysisk entitet i Internetdomänen som kan beskrivas som en “elektronisk publikationsrymd” som. ägs av' en individ eller en organisation, och som tillhandahåller antingen direkt access till eller länkar till andra entiteter i tillhandahåller information och tjänster, Internet eller intranätdomäner, som till privata information och tjänster auktoriserade slutanvändare. En portal är i sin enklaste form en vanlig hemsida eller en lista på länkar, men i mera avancerade former kan den erbjuda interaktiva tjänster, inte bara till dem som konsumerar vad som publiceras, utan också till dem som har medgivits rättighet av utgivaren att publicera i portalen, likväl som utgivaren själv, avseende olika aspekter på hur portalen användes.

Trådlösa slutanvändare ges access genom en “tjänste”-portal. En sådan “tjänste”-portal skiljer sig ifrån en vanlig fast Internetportal för PC:er, och slutanvändare begär personaliserade tjänster att levereras till, och presenteras på, deras mobila terminal åtminstone sonl en valmöjlighet. I det följande kommer emellertid inte terminologin “tjänste”-portal att användas, utan 10 15 20 25 30 | ~ - , 1 . . . . . _ , n .,, en portal (struktur) avser i detta dokument antingen en konventionell portal eller en “tjänste”-portal.

En applikation är en eller flera samverkande mjukvaruentiteter, där funktionellt fokus är användarinteraktion och användbarhet för slutanvändaren. En applikationsplattform är en definierad kombination av nüukvaru-, och hårdvaruentiteter som används för att implementera applikationer av ett visst slag, som kännetecknas av funktionaliteten och kvaliteten hos dess beståndsdelar.

Med en portalinfrastruktur menas, i allmänna termer, de mjukvaru-, och hàrdvaruentiteterna som behövs för att antingen agera som värd för eller producera eller generera en specifik portal. Speciellt innehåller den en portalkärna, en IP-infrastruktur och tjänsteaktiverare (enablers).

Ett tjänsteaktiverande medel, också kallat en tjänsteaktiverare (“service enabler”), är en stödfunktionalitet som accessas via API:er (Application Programming Interface) som höjer abstraktionsnivån och förenklar applikationsutvecklarens uppgift.

En portalkärna är kärnan i portalinfrastrukturen, dvs en portalkärna är den centrala delen i en portalstruktur som behövs för att utveckla ett portalramverk inom vilket innehåll och applikationer kan visas och accessas av Med slutanvändare på ett kontrollerat och unifierat sätt. ett tjänstenät menas i allmänhet ett IP-baserat nät, som består av noder som härbärgerar applikationsservrar, tjänstefunktions”capability”-servrar, applikationsstödservrar, IP-infrastrukturservrar osv.

Applikationsstödservrar bildar gränssnitt med tjänstenätresurser resurser än medan bildar eller andra externa kärnnät, tjänstefunktions”capability”-servrar gränssnitt med resurser och funktionalitet i kärnnät. lO l5 20 25 30 519 *Jaa ---- ~ f; >f=u .. k; 10 I föreliggande ansökan avses en portalstruktur innebära en portalkärna, ett flertal tjänster och applikationer med dess innehåll och tjänsteaktiverande medel (service enablers).

Generellt kan också konnektivitets-, och databärarfunktionaliteten inkluderas. Emellertid, vad som är viktigt för fungerandet av föreliggande uppfinning, är portalkärnans komponenter. De problem som ska lösas uppträder speciellt när accessade tjänster/applikationer sessionshanteras av andra medel än portalstrukturens egna sessionshanteringsmedel.

Därför tillhandahåller uppfinningen en portalstruktur, som förser slutanvändarstationer med access till tjänster/applikationer, som innehåller en portalkärna (och tjänsteaktiverande medel, konnektivitetsmedel, via vilka slutanvändaraccess tillhandahàlles). Portalkärnan innefattar en presentationsanordning, ett portalsessionshanteringsmedel som genererar och hanterar sessionsrelaterad information, t ex sessionsidentifikationer, och lagringsmedel för att lagra sessionsrelaterad information. Portalkärnan inkluderar också abonnenthanteringsmedel, som inte beskrives vidare. Åtminstone några av tjänsterna/applikationerna är externa tjänster/applikationer som sessionshanteras av externa sessionshanteringsmedel som genererar och hanterar extern applikation/servicesessionsrelaterad information, t ex externa sessionsidentifikationer.

Portalsessionshanteringsmedlen innefattar en sessionsunifierande anordning för att mappa eller transformera mellan portalsessionsidentifikationer och extern tjänste/applikations- sessionsidentifikationsinformation. För kommunikation mellan portalkärnan och externa tjänster/applikationer, används för de externa tjänster/applikationerna externa (proprietära) sessionsidentifikationer, medan för kommunikation mellan en « ø , 1 m 10 15 20 25 30 519 9:45 i W . I W , ~ - ~ I f r- ~ ~ » . . , ll slutanvändarstation och portalkärnan, bara portalsessionsidentifikationerna används. Speciellt genererar tjänsterna/applikationerna ett generiskt mark-up-språk, vilket ännu mera speciellt kan vara XML-språket.

I en fördelaktig implementering lagras extern sessionsidentifikationsinformation för alla externa tjänster/applikationer som är aktiva i en session i portalens lagringsmedel, åtminstone så länge respektive session varar, eller under en förutbestämd tidsperiod. En tidsperiod kan exempelvis definieras på så sätt att när det inte har förlegat någon aktivitet i sessionen under den givna tidsperioden, behöver informationen inte lagras längre.

I en speciell implementering är portalstrukturen mobil, vilket här innebär att den stödjer access av nwbila slutanvändarstationer, såsom exempelvis WAP-anordningar, utöver fasta slutanvändarstationer. Portalstrukturen inkluderar renderingsmedel för att översätta tjänste/applikationsdata i ett generiskt mark- up~språk till olika mark-up-språk som används av, eller förstås av, en slutanvändarstation. Om ett generiskt mark-up-språk används, speciellt XML, definieras data för tjänster/applikationer i ett dokumenttypsdefinitions(Document Type Definition; DTD)språk med ett URL-attribut (Uniform Resource Locator). DTD är (här) ett XML-dokument son1 beskriver alla element och deras attribut som tillåts i alla de dokument som kan ses som hörande till den speciella DTD:n. I en implementering består ett externt system (tjänst/applikation) med dess eget, eller externa, sessionshanteringsmedel, av en annan portal. I en speciell implementering arbetar portalsessionshanteringen i enlighet med servlet session API eller session EJB:r specifikationer för att definiera Detta grundläggande sessionshanteringsoperationer_ betyder att specifikationerna kan användas för att få en session | I . V V . , lO 15 20 25 30 12 från ett externt sessionshanterat system. I denna specifikation hänvisas det också till som ett bakre system, som således kan vara en tjänst/applikation som är extern, åtminstone i den betydelsen att den sessionshanteras externt. Det kan också vara en annan portal med sina egna (proprietära) sessionshanteringsmedel.

Enligt uppfinningen lagrar speciellt portalsessionshanteringsmedlen information som relaterar till slutanvändarinitierade aktioner, såsom att en slutanvändare går in i portalen, slutanvändarautenticering, slutanvändaraccess till en tjänst/applikation osv i portallagringsmedlen.

Enligt uppfinningen skapas, när en slutanvändarstation begär en tjänst/applikation från portalen, en session med en portalsessionsidentifikation, av portalsessionshanteringsmedlen.

Begäran vidarebefordras därpå till den begärda tjänsten/applikationen som, om det är en intern tjänst/applikation, använder portalsessionsidentifikationen. Om å andra sidan tjänsten/applikationen sessionshanteras externt, genereras en extern sessionsidentifikation för slutanvändaren, vilken används i kommunikation mellan portalen och tjänsten/applikationen. För en externt sessionshanterad tjänst/applikation, lagra det externa sessionshanteringmedlen den externa sessionsidentifikationsinformationen som genererats för en begärande slutanvändare under en definierad tidsperiod, t ex under tills sessionen har varit “inaktiv” under en sessionen, eller given tidsperiod.

När en påföljande anropsbegäran tas emot ifrån portalen, dvs ett påföljande anrop från samma slutanvändare i samma session avseende samma tjänst/applikation, används den genererade externa sessionsidentifikationen för att hitta sessionen i tjänsten/applikationen. Applikationsdata genereras och 10 l5 20 25 30 519 936 àYï*ff~m::¿i 13 applikationsinformationsdata sändes till portalen med användning av den externa sessionsidentifikationen som, av portalsessionsunifieringsmedlen, konverteras till/mappas mot portalsessionsidentifikationen.

I en implementering skapas en namnrymd inom portalsessionen, och för varje accessad extern tjänst/applikations-session lagras informationsdata inom rymden. I ett speciellt fördelaktigt utförande skapar en extern tjänst/applikation, eller ett externt sessionshanteringsmedel, en extern (eller proprietär) session med en för tjänsten/applikationen (proprietär) extern sessionsidentifikation för en slutanvändare som begär access till den externa tjänsten/applikationen via portalen, och inför en metainformationstagg, som åtminstone innehåller* den proprietära eller externa sessionsidentifikationen, till data i det generiska mark-up-språket, som ska sändas till portalkärnan. Speciellt är all data i metainformationstaggen lagrad i motsvarande portalsession för den slutanvändare som begär access.

I en speciell implementering tillhandahålles för kontinuerlig navigering för slutanvändarstationer, oberoende av var tjänstens/applikationens innehåll befinner sig, dvs oavsett om den är intern eller extern, genom införandet av metalänkar till tjänste/applikationsdata i ett generiskt mark-up-språk, t ex XML, till vilken portalsessionsid adderas som en parameter. För detta ändamål innefattar' portalkärnan (första) översättningsmedel för att behandla sådana metalänkar som är inkluderade i tjänste/applikationsdata. Portalkärnan innefattar dessutom renderingsmedel med (andra) översättningsmedel för att transformera datan i det generiska mark-up-språket till ett mark- up-språk som förstås av den slutanvändarstation som begär access, Kontinuerlig navigering såsom fördelaktig vilken kan vara mobil eller fast. hänvisats till ovan relaterar till en speciellt 10 15 20 25 30 . n ~ » | . . . - , m . K . . . f 14 implementering vilken med fördel kan kombineras med den unifierade sessionshanteringen såsom beskriven i föreliggande uppfinning.

Tillhandahållandet av kontinuerlig navigering genom införande av metalänkar till tjänste/applikationsdata av tjänsterna/applikationerna beskrivs i den samtidigt inlämnade svenska patentansökan “En anordning och ett förfarande relaterande till access av applikationer/tjänster” av samma sökande och inlämnad samma dag som föreliggande uppfinning, och vars innehåll härmed inkorporeras häri genom hänvisning därtill.

Således är i ett synnerligen fördelaktigt utförande portalstrukturen mobil, och den stödjer access av mobila slutanvändarstationer över ett mobilkommunikationsnät, såsom exempelvis GSM (Global System for Mobile communications), WCDMA (Wideband Code Division Multiple Access), GPRS (GSM General Packet Radio Service), UMTS (Universal Mobile Telecommunications System), Bluetooth (son) är en radioteknologi för korta räckvidder), WAP (Wireless Application Protocol) osv. Fördelaktigt stödjer portalstrukturen access av bredbandsanordningar såsom PC:er, eller mera generellt fasta anordningar, likväl som mobila anordningar såsom WAP-anordningar.

Med andra ord stödjer portalstrukturen access från fasta såväl som mobila slutanvändarstationer som använder olika accessformat eller olika kommunikation med som använder mark-up-språk för portalstrukturen.

Enligt ett speciellt utförande kan en tjänst eller en applikation valbart förses med en eller flera nætainformationstaggar utöver innehåller extern metainformationstagar som sessionsidentifikationsinformation. 10 15 20 25 30 » a » « »- 519 936 m, _.. 15 Även om uppfinningen inte är begränsad därtill, om ett generiskt mark-up-språk används, kan det generiska mark-up-språket vara XML.

XML-datan och möjliga metalänkar definieras i ett Document Type Definition språk (DTD). En metalänkstagg i XML-data innehåller information om metalänkstyp, ett referens och adresseringsattribut (URL) som innehåller tjänste/applikationsplatsinformation. Översättningsmedlen (i renderingsmedlen) översätter XML-data genom (XSL), dvs XML-datan att utföra en transformering med ett processas tillsammans “transformation stylesheet” (XSL transformation) för att åstadkomma ett utmatningsformat, dvs ett mark-up-språk, som är lämpligt för den accessande slutanvändarstationen, t ex HTML (Hypertext Markup Language) för en fast slutanvändarstation och WML (Wireless Markup Language) för XSL beskrivs i XSL Transformations en W3C en mobil slutanvändarstation.

(XSLT) 1.0, november 1999 och XSL Transformations ett W3C Working draft, rekommendation daterad 10 (XSLT) 12 december 2000, version som är version 1.1, som är vilka dokument härmed inkorporeras häri genom hänvisning därtill.

Speciellt kan vid en påföljande access av samma tjänst/applikation från samma slutanvändare i samma session, den lagrade metainformationen som innehåller den externa (proprietära) sessionsidentifikationen vidarebefordras ifrån portalsessionshanteringsmedelen av sessionsunifieringsmedlen till den externa tjänsten/applikationen (externa sessionshanteringsmedel), så att den externa sessionen såsom indikerat av det externa sessionsidzet kan hittas.

Uppfinningen visar också en anordning i en portalstruktur som innefattar en portalkärna med en presentationsanordning, portalsessionshanteringsmedel som genererar och hanterar sessionsrelaterad information, t ex sessionsidentifikationer, och lagringsmedel för att sessionsrelaterad lagra information. lO 15 20 25 30 n = » : s - » . . u 519 95 Ü* x. u. 16 Anordningen innefattar dessutom en sessionsunifieringsanordning för att unifiera hantering av portalsessioner och externa sessioner som genereras av externa sessionshanteringsmedel som hanterar externa tjänster/applikationer.

Portalsessionsidentifikationen (bara) används i kommunikation mellan portalen och en accessande slutanvändarstation, och den externa sessionsidentifikationsinformationen används i kommunikation mellan portalen och den externa tjänsten/applikationen. Unifieringsmedlen innefattar medel för att mappa mellan portalsessionsidentifikationer och externa sessionsidentifikationer_ Fördelaktigt lagras extern tjänste/applikationsidentifiktationsinformation i portallagringsmedlen under en förutbestämd tidsperiod, exempelvis under en session. Anordningen innefattar speciellt renderingsmedel for att översätta tjänste/applikationsdata i ett generiskt mark- mark-up-språk, beroende på typen på en up-språk till andra slutanvändarstation som begär access, for att rendera utdata för tjänsten/applikationen till slutanvändarstationer som har begärt access till en tjänst/applikation. Speciellt är ett sådant generiskt mark-up-språk XML.

I en fördelaktig implementering tillhandahålles extern sessionidentifikationsinformation i nætainformationstaggar som introduceras i den externa tjänste/applikationsdatan, och ännu mera speciellt lagras nætainformationsdatan i. portalsessionen i portallagringsmedlen som lagrar portalsessionsinformation.

Portalsessionsidentifikationen läggs speciellt till den externa applikations/tjänstedatan som en parameter.

Vid en påföljande begäran om access till portalen vad det gäller samma externa tjänst/applikation av en slutanvändare under en pågående session, inkluderas metainformationen i begäran av sessionsunifieringsmedlen vid vidarebefordran av begäran till den 10 15 20 25 30 - » - - m 519 956 ; . . ~ u Q « - - » :- 17 externa tjänsten/applikationen, dvs efter mappning/transformering ifrån portal till extern sessionsidentifikation.

Uppfinningen visar också ett förfarande för sessionshantering i en portalstruktur där externa tjänster/applikationer, som sessionshanteras externt, accessas. Portalstrukturen innefattar en portalkärna med en presentationsanordning, portalsessionshanteringsmedel som hanterar sessionsrelaterad information och portallagringsmedel för att lagra sessionsrelaterad information. Förfarandet inkluderar stegen att; skapa en portalsession med en portalsessionsidentifikation när en slutanvändare begär access till en tjänst/applikation, såtillvida en portalsession inte redan existerar; vidarebefordra begäran till den begärda externa tjänsten/applikationen; skapa, i eller för den externa tjänsten, genom externa sessionshanteringmedel, en extern tjänst/applikation varvid en extern tjänste/applikationsessionsidentifikation genereras såtillvida sessionen inte redan existerar* för den slutanvändare son1 begär access; varvid, i tjänsten/applikationen följande steg utföres; införande av information till tjänste/applikationsdatan; returnering av tjänste/applikationsdata generering av tjänste/applikationsdata; om den externa sessionsidentifikationen inkluderande den externa sessionsidentifikationen till portalen; varvid i portalen följande steg utföres: mappning av den externa sessionsidentifikationen till portalsessionsidentifikationen; lagring av den externa sessionsidentifikationen i portalsessionen i portallagringsmedlen; sändande av tjänste/applikationsdatan till den slutanvändare som begär access med användning av endast portalsessionsidentifikationen.

Förfarandet inkluderar dessutom stegen att; slå upp portalsessionen i portallagringsmedlen vid en påföljande begäran om access från slutanvändaren till den externa lO l5 20 25 30 18 tjänsten/applikationen; fastställa om portalsessionsrelaterad information innehåller en extern sessionsidentifikation; om ja, vidarebefordra begäran inkluderande den externa sessionsidentifikationen till den begärda externa tjänsten/applikationen; slå upp den externa, proprietära tjänste/applikationssessionen i tjänsten/applikationen eller i externa sessionshanteringsmedel, med användning av den externa sessionsidentifikationen; generera tjänste/applikationsdata; addera den externa sessionsidentifikationen till tjänste/applikationsdatan; sända tjänste/applikationsdatan med den externa sessionsidentifikationen till portalsessionshanteringmedlen osv. I en föredragen implementering genererar den externa tjänsten/applikationen ett generiskt mark- up-språk, exempelvis XML. Företrädesvis innefattar steget med att lägga till extern sessionsidentifikation generering av, och införande av, en nætainformationstagg som innehåller åtminstone extern sessionsidentifikation, till den externa tjänste/applikationsdatan.

Uppfinningen visar också ett förfarande för att integrera portalsessionshantering med extern sessionshantering av ett extert sessionshanterat system, som innefattar stegen att; mappa mellan portalsessionsidentifikationer och externa sessionsidentifikationer; lagra information relaterande till externa sessionsidentifikationer i portallagringsmedel i en genererad portalsession; använda portalsessionsidentifikationen i kommunikation med en slutanvändarstation; använda information som relaterar till den externa sessionsidentifikationen i kommunikation med externt sessionshanterade system. 10 15 20 25 u) *D , . ~ . .. 19 KORTFATTAD FIGURBESKRIVNING Uppfinningen kommer i det följande att ytterligare beskrivas på ett icke begränsande sätt, och under hänvisning till bifogade figurer, i vilka: Fig. l schematiskt illustrerar en överblick av en portalstruktur enligt en implementering av uppfinningen, Fig. 2 illustrerar en begreppsmässig uppdelning av presentationsanordningen (lagret) i ett funktionellt renderingslager och ett funktionellt tjänstelager, Fig. 3A är ett blockdiagram, över en portal genom vilken en slutanvändare först begär access till en extern applikation, Fig. 3B är ett blockdiagram såsom i Fig. 3A när en slutanvändare återigen accessar applikationen under pågående session, Fig. 4 är ett flödesdiagram som schematiskt beskriver en generell implementering av det uppfinningsmässiga konceptet, Fig. 5 är ett flödesdiagram som beskriver flödet när en slutanvändare accessar en portal och begär access till en extern tjänst/applikation när det inte finns någon session, Fig. 6 är ett flödesdiagram som beskriver förfarandet när en slutanvändare på nytt accessar samma applikation i samma session, och 10 20 25 30 . . | « . . 20 Fig. 7 är ett diagram som beskriver sessionsmappningssamspel i sessionsunifieringsproceduren_ DETALJERAD BESKRIVNING AV UPPFINNINGEN Under hänvisning till Fig. 1 och 2 kommer ett exempel på en portalstruktur att beskrivas på ett ganska detaljerat sätt. En sådan portalstruktur kan användas vid implementeringen av det uppfinningsmässiga konceptet som beskrivs under hänvisning till Fig. 3-7. Det skall också vara klart att uppfinningen inte på något sätt är begränsad till att implementeras i en portal såsom beskriven i Fig. l och 2, detta avsnitt av beskrivningen inkluderas uteslutande för att beskriva några exempel på underliggande begrepp och fungerandet av en portalstruktur som sådan.

Fig. 1 visar således ett exempel på en portalstruktur 10 enligt uppfinningen. Portalstrukturen 10 innefattar en portalkärna 1 som hanterar presentationsfunktionaliteter, abonnenmangs-, och sessionhanteringsfunktionaliteter, ett antal tjänster och applikationer 2, som exempelvis innefattar personliga kommunikationstjänster, personliga korthet är det informationstjänster och mobila E~handelstjänster. I inte viktigt vilka slag av tjänster som tillhandahålles, och det uppfinningsmässsiga konceptet är tillämpligt på vilket slag av tjänst, innehåll eller applikation som helst. Vid förklaring av det uppfinningsmässiga konceptet på ett mera detaljerat sätt (Fig. 3-7), och när en slutanvändare begär access till en tjänst eller en applikation, (eller innehåll) avses vilken tjänst eller applikation som helst, och kan ses som konceptuellt inkluderad portalstrukturen, även om några av tjänsterna och applikationerna faktiskt befinner sig utanför portalstrukturen och tillhandahålles av vilken extern tjänsteleverantör (service provider) som helst, som i detta dokument emellertid betecknas externa ifall de sessionshanteras 10 15 20 25 30 v» fl-v LW ...A \O \Q LM C“\ = . - - 1 - 21 externt, dvs ifall de inte sessionshanteras av portalsessionshanteringsmedlen.

Portalkärnans struktur l inkluderar dessutom ett lager 3 som innehåller ett antal tjänsteaktiverande medel, också kallade “service enablers” 31-37, 38A-38D. “Service enablers” är bland annat involverade i autenticering av grundläggande tjänster såsom gateways och IP-infrastruktur. I denna figur anges några exempel enablers” såsom “unified AAA-server 33, och underhållsstöd 36. på “service messaging” 31, IP- infrastruktur 32, notifikationsstöd 34, debiteringsstod 35 och drift- Ytterligare exempel på “service enablers” är nwbil-positioneringssystem 37, WAP-gateway 38A, SMS-C gateway 38B, multimediaproxy 38C, mobil E- pay 38D osv. Det ska vara klart att några av dessa “service enablers” är mer eller mindre obligatoriska, medan andra är valfria.

Portalstrukturen ses här också såsom inkluderande ett konnektivitets eller ett (mobil)bärarlager som innefattar de (Base (Mobile mobila basstationerna och switchingnoderna, såsom BTS Transceiver Station), BSC (Base Ststion Controller), MSC Switching Center) noder osv. Vilka noderna är, beror på over vilka mobila nät access tillhandahålles, t ex GSM. För GPRS eller UMTS inkluderas motsvarande noder i detta lager; exempelvis GGSN (Gateway GPRS Node). Vilket databäraren för portalen för access av mobila anordningar såsom Support nätet än ar, är nätet WAP-anordningar (Wireless Application Protocol). I Fig. 1 antas att den accessande slutanvändarstationen består av en WAP-telefon 5.

Ett exempel på en sådan cvIsET”. portalstruktur är Ericsson-portalen lO 15 20 25 30 @ - v - -ø 22 Interna applikationer eller tjänster kan ses som applikationer som ska förmå “service enablers” till och konnektivitetslager att lägga applikationsspecifika värden till mobila Internetapplikationer av olika kategorier, exempelvis mobila tjänster, personlig kommunikation som unified messaging eller neiltjänster, och personliga informationstjänster. Informationen kan hämtas av användaren genom sökningar, men informationen kan också tillhandahållas till slutanvändaren genom pushteknologin.

Detta är öppet för slutanvändaranpassning.

Det antas fördelaktigt att portalen stödjer access av" mobila slutanvändarstationer, såsom WAP-telefoner 5 över ett mobilt nät.

Därför" måste noder eller komponenter för det relevanta mobila nätet vara anordnade i mobilnätets konnektivitets och databärarlager. I Fig. 1 visas en komponent som betecknas ISP- nät, Internet Service Provider nät. Detta är en valfri komponent som kan vara inkluderad eller ej.

I lagret som innehåller tjänsteaktiverarna “service enablers” 3 är några av sagda “service enablers” obligatoriska medan andra ej är det. Några av “service enablers” betraktas som viktiga komponenter för att tillhandahålla funktionaliteter för mobilt Internet. Några av “service enablers” ses som en del av gränssnittskomponenterna mellan Internet och det mobila nätet. En komponent betecknas här IP-infrastruktur 32. En valfri “service enabler” utgörs av notifikationsstöd 34, vilken i allmänhet är en Valbar komponent som Inöjliggör för applikationer att sända ut filtrerade aviseringar till slutanvändare med användning av SMS- (Short Message Service) kanalen, men den kan också vara anpassad och 3G Debiteringsstödsaktiverare 35 kan vara anordnad att inkludera andra kanaler som (3GPP) stödjer WAP-teknologi teknologi. för att medge flexibelt val av debiteringshändelser. En annan “service enabler” 36 relaterar' till drift- och underhållsstöd, 10 15 20 25 30 « ~ , - . v 23 och det är generellt en obligatorisk komponent. En “service enabler” WAP-gateway 38A är en valfri “service enabler” WAP- gateway/proxy som bildar accesspunkten mellan den trådlösa världen och Internetvärlden. Den stödjer mobila klienter som accessar WAP-gatewayen/proxyn med användning av GSM kretskopplad data eller WAP över SMS (SMS över MAP (Mobile Application Protocol)). Klienten använder en WAP-stödjande browser i den mobila anordningen för att ansluta till WEB-servern där den önskade WAP-applikationen ligger. En annan “service enabler”, mobilpositioneringssystem, 37 är en valfri komponent som medger sändande av positionen för en användare till en applikation som begär den. En annan “service enabler” är multimedia proxy 38C som Detta Också SMS~C anvarar för att sända multimediadata över GPRS eller UMTS. är emellertid ett valfritt tjänsteaktiverande medel. (centrum) gateway 38B är en valfri komponent som ansvarar för att sända eller ta emot, lagra och vidarebefordra korta meddelanden mellan mobila stationer och servrar. Proprietära protokoll används för kommunikation med applikationer. Mobil E~pay 38D är en komponent som erbjuder grundfunktionaliteten för mobil E- handel och det är en valfri komponent. AAA-server 33 är en tjänsteaktiverande komponent som relaterar till autenticering, auktorisation och debitering. Dessa funktionaliteter kan tillhandahållas för på andra sätt, men de kan också vara integrerade i en funktionalitetsserver, och exempelvis möjliggöra trafikbaserad debitering och perioddebitering. En sådan komponent, antingen om den är uppsplittrad i olika komponenter, eller om den består av en enda komponent, som är gemensam för ett antal funktionaliteter, är obligatorisk, och i en fördelaktig implementering används den för sessionshanterings- funktionaliteter, Det ska emellertid vara klart att Fig. l bara visar exempel på tjänsteaktiverande medel (“service enablers”) som kan vara 10 15 20 25 30 01 ...à \O vä LN Cm 24 anordnade i ett tjänsteaktiverande lager (“service enabling layer”) 3. Åtminstone några av de illustrerade tjänsteaktiverarna kan exkluderas, återigen andra kan inkluderas osv.

Portalkärnan, eller portalkärnelagret, hanterar, såsom hänvisats till ovan, presentation, abonnenmang och sessionshantering och service lager (tiers) som innefattar ett antal interna (och externa) applikationsservrar. Kärnan 1 innehåller en presentationsanordning ll som nbjliggör mobil portalpresentation på multipla anordningar med användning av multipla protokoll. Den kan exempelvis vara XML-driven (eller mera generellt driven av ett generiskt mark-up-språk). I en implementering är det en Javam och XML-driven fler-mark-up-språkskapabel presentationsmodul. innehåller Presentationsanordningen ll renderingsmedel (en renderingsmotor) som i en implementering använder XML/XSLT- teknologier för att säkerställa att information som presenteras av tjänster inom portalen visas på ett standardiserat sätt, oavsett vilken typ av slutanvändarstation (eller browser) som en slutanvändare använder när han accessar portalstrukturen. Genom användningen av ett generiskt mark-up-språk, exempelvis XML/XSLT, kan “look and feel” för innehåll som presenteras för slutanvändare kundanpassas. XSL är en förkortning för Extensible Style Sheet Language. Den svenska patentansökan “En anordning och ett forfarande för presentationsanpassning i. en portalstruktur”, som är en ansökan ingiven på samma dag och av samma sökande som föreliggande uppfinning, och vars innehålle härmed inkorporeras häri genom hänvisning därtill, relaterar till användaranpassning i en portalstruktur såsom beskrivits häri, speciellt berör den kundanpassning vad det gäller “look and feel” (“utseende och känsla”). 10 15 20 25 30 U7 ...s UU \Q LN C\ n -.. 25 Funktionaliteterna inom portalkärnan 1 och i presentationsanordningen ll i synnerhet kommer att beskrivas ytterligare under hänvisning till Fig. 2.

Portalkärnan 1 inkluderar också abonnemangshanteraren. I en implementering lagras abonnemangshanteringskomponentinformation i ett LDAP (Lightweight Directory Access Protocol) bibliotek och den hanteras av' en tjänst kallad abonnemangshanterare(manager)_ funktioner för bort Abonnemangshanteraren inkluderar bibehålla och ta operatören för att skapa, abonnentinformation i abonnentdatabasen. Den möjliggör också för slutanvändaren av systemet att abonnera på tjänsterna i systemet. I en speciell implementering understöds ett självregisterings- och själv- servicekoncept för att ndnimera konstnaderna genom att ndnimera arbetsbelastningen på ett kundhanteringscentrum. Information om tillgängliga tjänster kan också hållas i biblioteket som hänvisats till ovan, och hanteras av abonnemangsmanagern. När en ny tjänst införs i registret, kommer den omedelbart att bli tillgänglig för att abonneras på av slutanvändarna. I registret kan slutanvändare grupperas så att nya tjänster kan göras tillgängliga bara för definierade grupper av slutanvändare.

Abonnemangshanteraren 12 kan bilda gränssnitt till ett existerande kundhanteringssystem genom det applikationsprogrammerings-interface (API) som den använder.

Sessionshanteraren 13 är en generell mekanism som kan användas av applikationer och tjänster. Den innehåller ett gränssnitt till ett undersystem för att hålla reda på alla besökare till portalen och för att tillhandahålla besökarnas profilinformation. När en slutanvändare går in i systemet/applikationen, allokeras en sessionsid-entitet, och den lagras för den speciella slutanvändaren tills denne loggar ut från tjänsten eller när slutanvändaren har varit inaktiv under en förutbestämd lO 15 20 25 30 26 tidsperiod. När en deltagande applikation startar, undersöker den först om det finns ett aktivt sessions-id för en speciell användare, och om det finns ett sådant, skall den kunna återuppta från det ställe där sessionen bröts.

Sessionshanteringsfunktionaliteterna enligt det uppfinningsmässiga konceptet kommer att beskrivas nedan under hänvisning till Fig. 3A-7.

Slutligen innefattar portalkärnstrukturen l här två “interna” applikationsservrar 14A, l4B och en eller flera externa applikationsservrar l4C. Den externa applikationsservern l4C innehåller länkar till externa applikationsservrar som kör existerande tjänster. I en implementering innefattar tjänstelagret (tier) tre klasser av tjänster, av vilken en första är utvecklad i överensstämmelse med portalkärnespecifikationerna som implementeras med användning av portalkärnemiljön. En andra tjänsteklass relaterar till tjänster som inte nödvändigtvis implementeras :i portalkärnemiljön, såsoni exempelvis ett externt e-mailsystem, som körs i. en icke-portalkärnemiljö, anpassat för att presentera sig själv genom portalkärnepresentationen. Den tredje tjänsteklassen relaterar till externa tjänster som, inte uppfyller portalkärnans tjänsteutveckling eller presentationsarkitekturer. Detta kommer att förklaras ytterligare under hänvisning till Fig. 2.

I det följande kommer portalkärnan, och speciellt presentationsanordningen, som innefattas i presentationslagret, att beskrivas mera noggrant, först under en generell hänvisning till rig. 2.

Tjänstelagret (tier) innefattar i en fördelaktig implementering tre tjänsteklasser. Tjänsteklassen portalkärneservice (pcoreservice) uppfyller specifikationerna för portalkärnan och 10 15 20 25 30 __ , | ' É I 8 2 x I V ' . _ i 5 jç) 9-5() Üšïiz: ;É"f .É> ': :JÉ ; . 'f IffÄ'Éf.Äf* * ' 27 används för att förmedla portalkärnekaraktäristika. I en implementering implementeras tjänsterna med användning av JZEE IBM WEBSphere Environment att utveckla (en applikationsserver som används för programmatiska tjänster involverande logik, algoritmer osv). Sådana tjänster har i allmänhet tre eller fyra lager (tier) arkitekturer som använder JSP (Java Server Pages) främst, Java servlets och Enterprise Java Beans (EJB) i det mellersta lagret och olika entiteter i det bakre lagret. Den andra tjänsteklassen är integrerade portalkärnetjänster (integrated pcore services) som förmedlar pcore presentationstjänster, men som inte nödvändigtvis är implementerade i portalkärne~, J2EE miljön, t ex ett externt e- mailsystem som körs i en icke-portalkärnemiljö, men som är anpassat att presentera sig själv genom portalkärnepresentationen_ Den tredje tjänsteklassen, pcore external services, varken uppfyller portalkärnetjänsteutvecklingen eller presentationsarkitekturerna, utan tjänsterna som inkluderas i denna klass kan exempelvis triggas till portalkärnan.

I en implementering finns det två slag av tjänsteoptioner som är tillgängliga inom tjänstelagret. En typ kan bestå av tjänster som tillhandahålles av Broadvision (CORBA) för att skapa optimerade regelbaserade och personaliserade tjänster kopplade till handel och minutförsäljning som är optimerade för innehållsleverans av en nmtchande motor som arbetar på innehåll, profil och affärsregler. En andra tjänstetyp är relaterad till programmatiska tjänster som exempelvis kräver algoritmer, logik osv, som inte lätt byggs in i ett optimerat innehållsleveranssystem. Om dessa tjänster är av klass pcoreservice, då kan de industrialiseras för IBM WEBSphere J2EE miljön, och om de är av klass integrerade tjänster och körs i en 10 l5 20 25 30 U1 ._å QS MD LM C; 28 extern tjänsteserver, är de anpassade till portalkärnepresentationen.

En tjänst behöver specifikationer som inkluderar element avseende renderingsfunktionaliteten för presentationslagret likväl som relaterande till tjänstelagerfunktionaliteten, dvs scheman och såsonn hänvisats J2EE logik. till Portalkärnepresentationsarkitekturen kan, ovan, i ett fördelaktigt utförande implementera arkitekturen för mekanismerna skapa och använda tjänstespecifika element eller för att definiera tjänster. Emellertid är uppfinningen inte begränsad till en portalstruktur som använder JZEE och Broadvision, vilka endast är angivna såsom exempel.

Presentationslagret är begreppsmässigt sett uppdelat i två lager (tiers), ett renderingslager som ligger i själva portalkärnan och ett tjänstelager som är tillgängligt för varje tjänst som vill presentera sitt innehåll genom portalkärnepresentations- strukturen. Renderingslagret använder i en fördelaktig implementering XML/XSLT-teknologier. Därigenom säkerställs också att information som presenteras av tjänster inom portalen kan visas pà ett standardiserat sätt oavsett vilken slutanvändarstationen är, dvs oavsett vilket slag av slutanvändarstation som en slutanvändare använder vid access av portalen. Genon1 användning av' XML/XSLT kan säkerställas att en enhetlig “look and, feel” (utseende och känsla) vad det gäller innehåll presenteras inom presentationsrymden.

OH1 XML används som ett generiskt mark-up-språk, producerar en tjänst utdata i form av ett XML-dokument som är formaterat med användning av strukturinformation ifrån en pcore DTD. XML utdatan ifrån tjänsten används då för att mata presentationsanordningens Presentationsmotorn använder presentationsmotor. och XML- pcore SS pcore grid information associerad med pcore DTD:n för 10 15 20 25 30 « . « . » . , , , , _ 29 dokumentet som tillhandahàlles av tjänsten för att generera det önskade gränssnittet. Tjänster som inte producerar XML ifrån en pcore DTD kan speciellt också presentera sig själva genom presentationstjänsterna.

Såsom hänvisats till tidigare är portalstrukturen fördelaktigt kapabel att hantera olika anordningar såsom WAP-telefoner och bredbandsanordningar såsom PC:er, eller den browser som används därav. En portalkärnestruktursplattform och däri är totalt logiken speciellt separerad ifrån presentationslagers- funktionaliteten, alla vilket gör det väldigt lätt att implementera stöd för röst- och blir det olika typer av klienter, även talsyntetiserare. Genom att använda exempelvis XML/XSL, mycket lätt att WAP-display implementera stöd exempelvis för en ny typ av storlek. Det är också möjligt att anpassa renderingsprocessen till olika WEB-anordningar, existerande och framtida bärbara anordningar, röst browsing och interaktiv TV.

I en speciell implementering är* WEB-gränssnittet sammansatt av fyrkantiga element, som också kallas tegelstenar (bricks). En “brick” är en tjänstebehållare, en bild eller en applikation, som visas på slutanvändarstationens skärm. “bricks” behållare, blir det Med användning av sådana eller möjligt att kundanpassa portalen. En “brick” är således en applikation som är skapad för att användas inuti portalstrukturen, som har en länk till applikationen. Applikationen måste tillhandahålla displayinformation till portalen när den önskar rendera sagda “brick”. “brick” fler än ett behållare Fördelaktigt kan en uppträda i format. Dispositionen av sagda “bricks” eller representerar ett sàkallat “brick” gränssnitt. För att möjliggöra snabb navigering, kan WAP-gränssnittet i. en implementering vara strukturerat på samma sätt. I WEB-gränssnittet presenteras användaren med en lista över tillgängliga “bricks”. Varje “brick” 10 15 20 25 30 » a . . . , . , , , , , 519 936 30 innehåller en applikation, en tjänst eller en bakgrundsbild som kan inkluderas i användarens byggda WEB-site. En “brick” kan också vara en förkonfigurerad tjänst av ett externt företag eller leverantör. En “brick-grid” är en icke synlig representation av en kundanpassad portal. Beroende på anordning, representeras sagda “brick-grid” på ett sätt som är det mest lämpliga för den anordning som används. Sagda “grid” kan vara designad på många sätt, likväl som de sätt som sagda “brick” visas och organiseras, exempelvis med taggar. “Brick-grid” lagras i ett generiskt format och är anordnings/slutanvändarstationsoberoende.

Företrädesvis autenticerar slutanvändaren sig själv mot portalen med en engångs-login, som kommer att ge slutanvändaren access till hela funktionaliteten inom portalen. Varje autenticering mot anslutna eller externa innehålls-, eller externa tjänsteleverantörer hanteras av plattformens säkerhetssystem.

Företrädesvis kan varje applikation eller tjänst inonl portalen anpassas för att passa slutanvändarens behov, och varje applikation kan anpassas för olika anordningar. Detta är speciellt fördelaktigt när en slutanvändare vill begränsa mängden av data som sändes till en annan slutanvändarstation med begränsad kapacitet vad det gäller att presentera större mängder av data, t ex en WAP-telefon. Det är möjligt att välja en applikation fler än en gång, och att ge var och en av de olika instanserna sin egen personalisering.

Ovan har ett exempel på en portalstruktur beskrivits, i vilken det uppfinningsmässiga konceptet kan implementeras. Emellertid är uppfinningen som sådan givetvis inte begränsad till att implementeras i en sådan portal, utan den baserar sig på antagandet att en portalstruktur finnes vilken är kapabel att slutanvändare, dvs entiteter med till förse som accessar portalen, access tjänster/applikationer. För varje slutanvändare lO 15 20 25 30 o» :Mv 1. :in - . . » - . < ~ - - 1 . 31 skapas en session av portalen, och varje session innehåller slutanvändarspecifik data. En tjänst/applikation kan vara extern eller intern. I detta sammanhang definieras en intern applikation eller tjänst som en applikation eller tjänst som utnyttjar portalens sessionshantering, medan extern applikation eller tjänst definieras som en applikation eller tjänst som använder en extern sessionshantering, vilket betyder att den antingen kan tillhandahålla för sessionshanteringen själv, eller också kan den sessionshanteras av en tredje part.

Det uppfinningsmässiga konceptet kommer i det följande att beskrivas i detalj under hänvisning till Fig. 3A-6.

Fig. 3A, 3B visar en implementering i vilken det antas att portalstrukturen stödjer access av mobila såväl som fasta slutanvändarstationer. till I en fördelaktig implementering möjliggörs access portalstrukturen själv, för olika slag av slutanvändarstationer, även om typerna inte är kända av portalstrukturen. Detta kan utföras såsom beskrivet i den svenska patentansökan “Anordning och förfarande relaterande till slutanvändarstationer som accessar en portal", sonx är inlämnad samtidigt, och av samma sökanden, som föreliggande uppfinning, och vars innehåll härmed häri därtill. inkorporeras genom hänvisning Fig. 3A är en schematisk illustration av en slutanvändarstation 5, son1 här är en WAP-anordning som accessar portalkärnan l i en portalstruktur för att få access till en extern applikation 26. I portalkärnan visas endast de medel som är av intresse för fungerandet av föreliggande uppfinning, nämligen presentationsanordningen ll med renderingsmedel 15, “request broker” 16, portalsessionshanteringsmedel 13, 10 l5 20 25 30 H » I - . . ., 519 956 šiïffï: .u nu 32 sessionsunifierings- (förenings)medel 50 och portalsessions- lagringsmedel 51.

Om slutanvändarstationen 5 vill få access till en extern applikation 26, tillhandahàlles en begäran (IQ) till sessionsunifieraren 50, och, eftersonl det är den första transaktionen för förbindelsen, dvs det finns inte någon session tillgänglig för slutanvändare 5 som relaterar till extern applikation 26, skapas en session av portalsessionshanteraren 13, som tar emot begäran (II0) ifrån sessionsunifieraren 50. Sessionen innehåller användarspecifik data och den lagras i portallagringsmedlen 51. En portalsessionsidentifikation, eller kort uttryckt ett portalsessions-id skapas. Sessionsunifieraren 50 vidarebefordrar också begäran (III0) till “request broker” 16, som vidarebefordrar den till den externa applikationen 26, (IVM.

Den externa applikationen detekterar att det inte finns någon session för den slutanvändare som (t ex XML), (extern) begär access, genererar data skapar en extern session med ett och introducerar det externa sessions-idzt (XML) externt sessions-id, som efli metainformationstagg till datan, sonl därpå sändes som ett svar innehållande nætainformationstaggen till portalens “request broker” 16 (V0). Datan med metainformationstaggen (VI0), sonx detekterar till till vidarebefordras till renderingsmedlen 15, metainformationstaggen och vidarebefordrar den transformerar den till portalsessions-id in i sessionsunifieraren 50, som portalsessions-id, som därpå returneras renderingsmedlen, (VII0). I renderingsprocessen skrivs svarsdatan som skickas vidare till “request broker” 16 att sedan sändas vidare till slutanvändarstationen 5.

I Fig. 3B antas att en session redan existerar, och att slutanvändarstation 5 på nytt försöker accessa applikation 26 inom samma session, (I). Sessionsunifieraren 50 hämtar 10 15 20 25 30 01 ._A QD \O (;~.' Q\ w. ..= v. h, 33 portalsessionen för användaren ifrån portalsessionshanteraren 13 (portallagringsmedlen)(II). Sessionsunifieraren 50 hämtar tjänste/applikationsdata för den tjänst/applikation som ska accessas, t ex externt (“backend”) sessions-id, (III). Det externa sessions-idzt skickas därpå vidare till 16 (IV), som “request broker” anropar den externa applikationen 26, (V).

Applikationen genererar data (t ex XML) som inkluderar det sessions~id:t i sänder den (VI). externa metainformationstaggen och till portalen, “Request broker” vidarebefordrar datan till renderingsmedlen 15 för rendering (VII). Renderingsmedlen 15 kommunicerar med sessionsunifieraren 50, som nappar det externa sessions-idzt på portalsessions-idzt och returnerar det senare till renderingsmedlen 15, (VIII). Renderingsmedlen skriver därpå in portalsessions-idzt i svaret avsett för slutanvändarstationen 5, (IV). Via sändes svaret till “request broker” slutanvändarstationen 5 (X).

För access av en intern applikation används portalsessions-idzt både för kommunikation mellan portalen och den interna applikationen, och för kommunikation mellan slutanvändarstationen och portalkärnan.

Om applikationen genererar ett generiskt mark-up~språk, t ex XML, översätts XML-datan också i renderingsmedlen 15 och renderas och matas ut till slutanvändarstationen 5 i det mark-up-språk som kan förstås av slutanvändarstationen, t ex HTML om det är en PC, och WML om det är en WAP-anordning.

Detta betyder att, för kommunikation mellan slutanvändarstationen och portalen, tilldelat, bara det bara portalsessions-idzt används när det väl är emedan, mellan portalen och den externa applikationen, externa applikations-idzt används, när det väl är genererat. 10 15 20 25 30 519 936 1 . « . . , 34 I en portalstruktur som implementerar det tillhandahålles ett uppfinningsmässiga konceptet sessionshanteringsunifierande ramverk som består av sessionsunifieraren. Sessionsunifieraren tillhandahåller en generisk en-till-många sessionsmappningsmekanism, dvs om det finns ett flertal externa system (applikationer, tjänster, portaler) som har sin egen sessionshantering, kan sessionsunifieraren transformera portalsessioner till de externa systemens sessioner och tvärtom.

Förfarandet kommer att beskrivas i allmänna termer under hänvisning till flödesdiagrammet i Fig. 4. Det antas således att en begäran om en applikation, här betecknad C, tas emot i 100. tillgänglig i portalstrukturen från slutanvändare U, Portalen undersöker om det finns en session lagringsmedlen for 101. skapas en portalsession som tilldelas ett portalsessions-id, slutanvändare U som relaterar till applikation C, Om ej, 102.

Det fastställes om applikation C sessionshanteras externt, 103.

Om inte, kommer applikationen att använda portalsessions-idzt i kommunikation med applikation C och med slutanvändare U, 104, och det finns inget behov av någon unifiering av sessioner. Om emellertid applikation C sessionshanteras externt, vidarebefordras begäran till applikation C, 106 (givetvis också om applikationen sessionshanteras externt, dvs använder portalsessionshanteringen, vidarebefordras begäran till applikationen osv, men detta är inte relevant för det uppfinningsmässiga konceptet och kommer därför inte att beskrivas ytterligare här). I applikation C (eller mera generellt det externa finns session 107. Om systemet), undersöks om det någon tillgänglig för slutanvändare U, inte, genereras en externt 108. information om det extern applikationssession som är proprietär med ett sessions-id, också betecknat externt(applikations)-id, Applikationsdata genereras, som förses med externa sessions-idzt. Ett svar som innehåller applikationsdata 10 15 20 25 30 01 __; \D \O (gå CF = . » . f. 35 och informationen om det externa sessions-idzt sändes till portalen, 109.

När svaret tas emot inom portalen, lagras informationen om det externa sessions-idzt i den portalsession som skapats for slutanvändare U för applikation C, 110. vilken portalsession lagras i portalsessionslagringsmedlen, Därefter, för ytterligare kommunikation mellan slutanvändaren och portalen, används portalsessions-idzt. Information om det externa sessions-idzt inkluderas i kommunikation med applikation C, 111.

Om. det i steg 101 ovan fastställts att det fanns en session för en extern 105. Då tillgänglig i lagringsmedlen, hittas speciellt, appliaktion, informationen om det externa sessions-idzt, används portalsessions-idzt i kommunikation mellan slutanvändaren och portalen, medan det externa sessions-idzt används för kommunikation mellan portalen och applikationen så som hänvisats lll. till ovan, Om det emellertid inte fanns någon information lagrad om något externt sessionsid i portalsessionen lagrad i 105, och portalsessions-idzt används i kommunikation både portallagringsmedlen, kan detta indikera att applikationen är intern, med applikation C och med slutanvändare U.

Steg 103 ovan kan ge intrycket att det måste finnas en separat detektering vad det gäller att se om en applikation är extern.

Detta kan emellertid detekteras inherent för en redan existerande session, när portalsessionen hämtas av sessionsunifieringsmedlen ifrån portallagringsmedlen via portalsessionshanteringsmedlen.

För en ny session kan det detekteras när svaret tas emot ifrån applikationen, vilket då innehåller en nætainformationstagg med det externa sessions-id:t, speciellt av renderingsmedlen. 10 15 20 25 30 | | = . . . 519 936 m f... 36 Fig. 5 är ett flödesdiagram som beskriver något mera i detalj, för ett speciellt utförande, förfarandet när en begäran ifrån en slutanvändare U1 tas emot i portalen som relaterar till en extern applikation A för 200. första gången, dvs det finns inte någon session, Portalsessionshanteringsmedlen detekterar att det inte finns någon session för Ul som relaterar till applikation A, 201. Då skapar portalen en session för slutanvändare Ul och applikation A med ett portalsessions-id, 202. Därpå vidarebefordras begäran till applikation. A, 203. Applikation A detekterar att det inte finns någon session för Ul, 204.

Applikation A skapar då en proprietär, extern session för Ul och en nætainformationstagg med åtminstone ett externt sessions~id, 205. i detta utföringsexempel i XML, till XML-datan en dvs med identiteten på den skapade sessionen, Applikationen genererar också applikationsdata, och sänder applikationsdatan med 206. Således metainformationstaggen portalkärnan, finns i metainformationstagg som innehåller applikationssessions-id:t_ Det kan t ex se ut som: Portalsessionsunifieringsmedlen, mappar" det externa sessions-idzt o pa portalsessions-idzt för Ul, 207.

Portalsessionshanteringsmedlen lagrar metainformationsdatan, speciellt all metainformationsdata om, i en fördelaktig implementering, inte bara metainformation som relaterar till sessions-idzt inkluderas, utan också annan data, i portalsessionen, 208. I en implementering innhåller applikationsdatan också metalänkar som hänvisar till andra tjänster/applikationer som kan processas och översättas av översättningsmedel, såsom ytterligare diskuteras i den samtidigt ingivna patentansökan “En anordning och ett förfarande 10 15 20 25 30 519 936 37 relaterande till access av applikationer/tjänster", och portalens sessions~id adderas som en parameter.

Renderingsmedlen i. portalkärnan renderar applikationsdatan, dvs till ett format som är till översätter den lämpligt för slutanvändarstationen, och sänder den slutanvändare U1 endast med användning av portalsessions-idzt, 209.

Fig. 6 är ett flödesdiagram som beskriver förfarandet när slutanvändare U1 försöker accessa applikation A på nytt under samma session. Det antas således att en påföljande begäran om 210. Detta betyder exempelvis att slutanvändare U1 klickar på en länk i sin browser till till applikation A tas emot i portalen ifrån U1, applikation A, vilken länk har en parameter portalsessions-idzt. Via sessionsunifieraren slår portalsessionshanteringsmedlen upp portalsessionen för Ul med 211. Det detekteras att det 212, som användning an/ portalsessions-idzt, metainformation i till finns portalsessionen för U1, relaterar applikation A. Portalens “request broker” metainformationen som 213. vilket kontaktar applikationen och inkluderar parametrar och vidarebefordrar begäran till applikation A, sessions-idzt, innehåller det externa till Metainformationen således kommer att sändas applikationen, dvs användas i kommunikation med applikation A. Applikation A använder sitt externa sessions-id såsom inkluderat i metainformationen för att externa sessionen för 214. slå upp den slutanvändare U1, inkluderar XML-datan med Applikationen skapar applikations(XML)data, metainformationstaggen i XML-datan och till sänder 215. (216) metainformationstaggen portalen, Därpå fortskrider flödet såsom i stegen 207, 208 i Fig. 5 osv.

Enligt en implementering tillhandahåller den externa applikationen, eller mera generellt det externa systemet, också 10 15 20 25 30 betecknat “backend” systemet, m ..-.| 38 följande operationer för att göra de sessionsunifierande medlen (session unifier) funktionella: BackendSession bs = backend,createSession() Bs.updateSession() Stream s = backend.serializeSession(BackendSession bs) Sessionsunifieraren implementerar följande operationer: 1. 2.

PortalSession ps = Portal.getSession() BackendSession bs = Ps.getBackendSession(backendService) 3. 4. ps.callBackendService(backendService), bs) ps.storeBackendSession(backendService, bs) Sessionsunifieringsproceduren fungerar således såsom följer enligt denna implementering: Unifieraren anropar ps.getSession () för att hämta portalsessionen som är associerad med begäran/anropet avseende tjänsten/applikationen.

Unifieraren anropar bs = ps.getBackendSession (backendService) Unifieraren anropar ps.callBackendService(backendService, bs) Om det inte finns någon “backend” session för användaren (bs = O), backend bs = sänder denna session tillsammans med svaret till portalen. anropar backend,createSession() och Annars anropar backend bs.updateSession(), och sänder detta svaret till fullbordas tillsammans med portalen. Sandandet av backendsessionen genom att anropa backend.serializeSession(bs). 10 15 20 25 30 « 1 , , r- 519 956 39 P.getSession() kan implementeras av vilket sessionshanteringssystem som helst som t ex följer Servlet Session API.

P.getBackendSession(backendService) kan implementeras genom att skapa en namnrymd inom portalsessionen för varje backendService som accessas, och lagra, inom namnrymden, den backendService relaterade datan.

För att reducera bandbreddskraven, kan b.serializeSession() implementeras genom att man bara sänder en identifikator för sessionen ifrån backendsystemet.

Det är en fördel med uppfinningen att genom tillhandahållandet av sessionsunifiering, erhålles en sömlös integrering av olika sessionshanteringssystenl till en sammanslagen sessionshantering.

För portalstrukturer kan detta påtagligt reducera integrationstiden mellan portal och externa applikations tjänsteleverantörer. I synnerhet för mobila portaler, som stödjer access också av nmbila stationer, ger en sådan sammanföring av sessionshantering ett kraftfullt medel för att reducera mängden av data som näste sändas till trådlösa slutanvändarstationer genom att man konverterar lång backend-sessionsdata till korta sammanslagna sessioner. Access från mobila slutanvändarstationer, såson1 WAP-anordningar, till externt sessionshanterade systenx är annars kanske inte ens möjligt beroende på den stora mängden data som måste överföras om både ett portalsessions-id och ett externt sessions-id måste inkluderas i kommunikation med slutanvåndarstationen, eftersom sådana mängder av data kan vara slutanvändarstation. Även om en faktiskt kan oacceptabelt för en mobil slutanvändarstation hantera sådana mängder data uteslutande för identifikationsändamål, är det ett slöseri med resurser och tid. 10 15 20 25 30 519 956 « - . , »p 40 sessions-id måste inkluderas i kommunikation med slutanvändarstationen, eftersom sådana mängder av data kan vara oacceptabelt för en mobil slutanvändarstation. Även om en faktiskt kan hantera sådana data är det ett slutanvändarstation mängder uteslutande för identifikationsändamål, slöseri med resurser och tid.

Det ska vara klart att uppfinningen inte är begränsad till de specifikt illustrerade utforingsexemplen, utan att den kan varieras på en rad sätt inom ramen för vidhängande patentkrav.

Claims (27)

10 15 20 25 30 « ø \ V . , 41 PATENTKRAV

1. l. En portalstruktur som förser slutanvandarstationer med access till tjänster/applikationer, innefattande en portalkårna, (tjänsteaktiverande medel, konnektivitetsmedel via vilka slutanvändaraccess tillhandahålles) och ett antal tjänster/applikationer, där sagda portalkärna innefattar en presentationsanordning, portalsessionshanteringsmedel som genererar sessionsrelaterad information, tex sessionsidentifikationer, portallagringsmedel för lagring av sessionsrelateradt information (och abonnenthanteringsmedel), där åtminstone några av tjänsterna/applikationerna består av externa tjänster/applikationer, eller tillhandahålles av externa system sonx implementerar externa sessionshanteringsmedel som genererar externa sessionsidentifikationer, k ä n n e t e c k n a d d ä r a v att portalstrukturen dessutom innefattar sessionssammanförande medel for mappning mellan portalsessionsidentifikationer och externa sessionsidentifikationer, och att for kommunikation mellan portalkärnan och externa tjänster/applikationer används den externa tjanste/applikations-identifikationen som sessionsidentifikation, medan i kommunikation mellan en slutanvandarstation och portalkärnan endast portalsessionsidentifikationen används som sessionsidentifikation.

2. En portalstruktur enligt patentkrav 1, k ä n n e t e c k n a d d ä r a v att tjänsterna/applikationerna genererar ett generiskt mark-up- språk.

3. En portalstruktur enligt patentkrav 2, k ä n n e t e c k n a d d ä r a v att det generiska mark-up-språket är XML. 10 15 20 25 519 9:a; 421

4. En portalstruktur enligt något av patentkraven 1-3, k ä n n e t e c k n a d d ä r a v att extern tjänste/applikationsproprietär extern sessionsidentifikationsinformation för alla externa tjänster/applikationer som är aktiva i en session lagras i motsvarande portalsession i portallagringsmedlen under en förutbestämd tidsperiod, exempelvis under varaktigheten för respektive session.

5. En portalstruktur åtminstone enligt patentkrav 2, k ä n n e t e c k n a d d ä r a v att presentationsanordningen innefattar renderingsmedel för att översätta tjänste/applikationsdata i det generiska mark-up-språket till ett annat mark-up-språk som används av en slutanvandarstation.

6. En portalstruktur enligt patentkrav 5, k ä n n e t e c k n a d d ä r a v att den är mobil, dvs den stödjer access av mobila slutanvändarstationer, t ex WAP~anordningar, utöver fasta slutanvändarstationer.

7. En portalstruktur åtminstone enligt patentkrav 2, k ä n n e t e c k n a d d ä r a v att data som representerar tjänster/applikationer i det generiska mark-up-språket definierade i ett Document Type Definition (DTD) språk med ett URL-attribut.

8. En portalstruktur enligt något av föregående patentkrav, k ä n n e t e c k n a d d ä r a v att ett externt system med ett externt proprietärt sessionshanteringsmedel består av en annan portal. lO 15 20 25 30 43

9. En portalstruktur enligt något av föregående patentkrav, k ä n n e t e c k n a d d ä r a V att portalsessionshanteringsmedlen arbetar enligt servlet session API eller session EJB:er specifikationerna som definierar grundläggande sessionshanteringsoperationer.

10. En portalstruktur enligt något av föregående patentkrav, k ä n n e t e c k n a d d ä r a v att portalsessionshanteringsmedlen lagrar information relaterande till slutanvändarinitierade aktioner, såsom slutanvändare går in i portalen, slutanvändarautenticering, slutanvändaraccess av en tjänst/applikation osv i portallagringsmedlen.

11. ll. En portalstruktur enligt något av föregående patentkrav, k ä n n e t e c k n a d d ä r a v att vid mottagning av en slutanvändarbegäran om en tjänst/applikation, skapas en portalsession med en sessionsidentifikation av portalsessionshanteringsmedlen, och när begäran vidarebefordras till tjänsten/applikationen, använder tjänsten/applikationen portalsessionsidentifikationsinformationen om det är en intern tjänst/applikation, medan tjänsten/applikationen förses med en extern (proprietär) sessionsidentifikation om den hanteras av ett externt sessionshanteringsmedel.

12. En portalstruktur enligt patentkrav ll, k ä n n e t e c k n a d d ä r a v att för en tjänst/applikation som hanteras av ett externt sessionshanteringsmedel, lagrar det externa sessionshanteringsmedlet den externa sessionsidentifikations- informationen som genererats för en begärande slutanvändare under en förutbestämd tidsperiod, exempelvis under sessionens varaktighet, och när en påföljande anropsbegäran tas emot ifrån 10 15 20 25 30 519 44 portalen under sessionen, genereras tjänsteapplikationsdata och till tjänste/applikationsdatan, och den ett svar returneras portalkärnan som innefattar externa sammanforande sessionsidentifikationen av de till konverteras/mappas medlen, portalsessionsidentifikationen så att tjänste/applikationsdata kan vidarebefordras till slutanvändaren genom att endast använda portalsessionsidentifikationen.

13. En portalstruktur enligt patentkrav 12, k ä n n e t e c k n a d d ä r a v att den namnrymd skapas inom portalsessionen for varje accessad tjänst/applikation och att den externa sessionsinformationsdatan som åtminstone inkluderar extern sessionsidentifikation lagras inom namnrymden.

14. En portalstruktur enligt patentkrav 2, 11 eller 12, k ä n n e t e c k n a d d ä r a v att en extern tjänst/applikation skapar en extern, proprietär session med ett extern-tjänst/applikations externt (proprietärt) id för en slutanvändare som begär access till den externa tjänsten/applikationen via portalen, och introducerar en metainformationstagg som innehåller åtminstone den externa (proprietära) sessionsidentifikationen i tjänste/applikationsdatan i det generiska mark-up-språket, for returnering till portalkärnan.

15. En portalstruktur enligt patentkrav 14, k ä n n e t e c k n a d d ä r a v att all data i motsvarande metainformationstaggen lagras i portalsession för slutanvändaren som begär access.

16. En portalstruktur enligt patentkrav 15, k ä n n e t e c k n a d d ä r a v 10 15 20 25 30 519 9236 45 att portalkärnan innefattar första översättningsmedel för att processa möjliga metalänkar som kan vara inkluderade i tjänste/applikationsdatan j. det generiska mark-up-språket varvid portalsessionsidentifikationen adderas som en parameter, och att portalkärnan dessutom innefattar renderingsmedel med ett andra översättningsmedel för transformering av data i till det generiska mark-up-språket ett mark-up-språk som förstås av den slutanvändarstation som begär access.

17. En portalstruktur enligt patentkrav 16, k ä n n e t e c k n a d d ä r a v att för en påföljande access till samma tjänst/applikation av samma slutanvändare i samma session, vidarebefordras den lagrade metainformationen som innehåller den externa sessionsidentifikationen ifrån till portalsessionsunifieringsmedlen den externa tjänsten/applikationen så att den externa tjänsten/applikationen kan hitta den externa sessionen såsom indikerad av den externa sessionsidentifikationen.

18. En anordning i en portalstruktur som innefattar en portalkärna med en presentationsanordning, portalsessionshanteringsmedel som genererar sessionsrelaterad information, åtminstone portalsessionsidentifikationer, och portallagringsmedel för lagring av portalsessionsrelaterad information, k ä n n e t e c k n a d d ä r a v att den innefattar sessionssammanförande medel för unifiering av hantering av portalsessioner och externa sessioner genererade av externa hanterar externa sessionshanteringsmedel som tjänster/applikationer, att endast portalsessionsidentifikationen används i kommunikation mellan portalen och en slutanvändarstation som begär access, och att den externa sessionsidentifikationen används i kommunikation mellan 10 15 20 25 30 I - - » i . 519 95" 46 portalkärnan och den externa tjänsten/applikationen, och att de sammanforande medlen används för att mappa/transformera mellan porta1sessionsidentifikationer och externa sessionsidentifikationer för externa tjänster/applikationer.

19. En anordning enligt patentkrav 18, k ä n n e t e c k n a d d ä r a v sessionsidentifikationsinformation för att extern, proprietär externa tjänster/applikationer lagras i den portalsession till vilket den är mappad, under en given tidsperiod, t ex under en session.

20. En anordning enligt patentkrav 18, k ä n n e t e c k n a d d ä r a v att presenteringsanordningen innefattar renderingsmedel för att översätta tjänste/applikationsdata i generiskt mark-up-språk till ett annat mark-up-språk beroende på typen av en slutanvändarstation som begär access för att rendera tjänste/applikationsdata för utmatning till slutanvändarstationer som har begärt access till en tjänst/applikation i ett nark-up- språk som kan förstås av slutanvändarstationen.

21. En anordning enligt patentkrav 20, k ä n n e t e c k n a d d ä r a v att det generiska mark-up~spràket är XML.

22. En anordning enligt något av patentkraven 18-21, k ä n n e t e c k n a d d ä r a v att extern sessionsidentifikationsinformation tillhandahàlles i en metainformationstagg introducerad i den externa tjänste/applikationsdatan, och att metainformationsdatan lagras i motsvarande portalsession i portallagringsmedlen som lagrar portalsessionsinformation, och att portalsessionsidentifikationen 10 15 20 25 30 - | - . .- 47 adderas till den externa applikations/tjänstedatan som en parameter i kommunikation med slutanvändarstationen, ersättande den externa sessionsidentifikationen.

23. En anordning enligt patentkrav 22, k ä n n e t e c k n a d d ä r a v att för en påföljande begäran om access till portalen avseende samma externa tjänst/applikation av en slutanvändare under en session, inkluderas metainformationen i begäran när den vidarebefordras ifrån portalkärnan till den externa tjänsten/applikationen.

24. Ett forfarande för sessionshantering i en portalstruktur som innefattar en portalkärna innefattande en presentationsanordning, hanterar portalsessionshanteringsmedel som sessionsrelaterad information, och portallagringsmedel för lagring av sessionsrelaterad information, innefattande stegen att: - skapa en portalsession med en portalsessionsidentifikation när en slutanvändare begär access till en tjänst/applikation, så till vida inte en portalsession redan existerar; - vidarebefordra begäran till den begärda externa tjänsten/applikationen om den begärda tjänsten/applikationen sessionshanteras externt; - skapa, i det externa sessionshanteringsmedlen, en extern tjänste/applikationssessionsidentifikation som är proprietär för den till vida inte en begärande slutanvändaren, så session redan existerar; - generera tjänste/applikationsdata i tjänsten/applikationen; - införa information om den externa sessionsidentifikationen i tjänste/applikationsdatan; 10 l5 20 25 30 519 936 ~~~~ ~ - . . 1 :- 48 - returnera tjänste/applikationsdata inkluderande extern sessionsidenfikation till portalen; - mappa den externa sessionsidentifikationen till portalsessionsidentifikationen; - lagra den externa sessionsidentifikationen i motsvarande portalsessionsmedel; - sända tjänste/applikationsdatan till slutanvändaren som begär access endast med användning av portalsessionsidentifikationen.

25. Ett förfarande enligt patentkrav 24, k ä n n e t e c k n a t d ä r a v att det innefattar stegen att: i portalen: - slå upp portalsessionen i lagringsmedlen vid en påföljande begäran om access av en slutanvändare till en extern tjänst/applikation under sessionen; - fastställa om portalsessionsrelaterad information innehåller en extern sessionsidentifikation, om ja; - vidarebefordra begäran inkluderande den externa sessionsidentifikationen till den begärda externa tjänsten/applikationen; i de externa sessionshanteringsmedlen eller i den externa tjänsten/applikationen: - slå upp den externa tjänste/applikationssessionen; - generera tjänste/applikationsdata; - lägga till den externa sessionsidentifikationen till tjänste/applikationsdatan; - returnera tjänste/applikationsdatan med den externa sessionsidentifikationen till portalsessionshanterings~ medlen; lO 15 20 25 v . X . 1 , 519 95 CW 49 i portalen: - ersätta den externa sessionsidentifikationen med motsvarande portalsessionsidentifikation; till slutanvändarstationen - sända tjänste/applikationsdatan med användning av uteslutande portalsessionidentifikationen.

26. Ett förfarande enligt patentkrav 24 eller 25, k ä n n e t e c k n a t d ä r a v att den externa tjänsten/applikationen genererar ett generiskt mark-up-språk, t ex XML.

27. Ett förfarande enligt patentkrav 26, d ä r a V till k ä n n e t e c k n a t att steget för att lägga extern sessionsidentifikation innefattar generering av och införande av en metainformationstagg, som åtminstone innehåller extern sessionsidentifikation, till tjänste/applikationsdatan_