Browse Prior Art Database

Portal Registration State Engine and State Engine Administration Console

IP.com Disclosure Number: IPCOM000203561D
Publication Date: 2011-Jan-28
Document File: 5 page(s) / 179K

Publishing Venue

The IP.com Prior Art Database

Abstract

The present publication discloses a Portal Registration State Engine, whose main goal is to pilot the process flow according to a customisable XML state data model, where all the registration states and the related actions are described. The State Engine will use an IDM (IDentity Management) Web Services interface to retrieve/update information related to the online user. A State Engine Factory is also implemented as a global component and it will be a sort of container of all the state engines defined for each local operating country. State Engine Factory is managed by a State Engine Administration Console, which enables administrators/analysts to create or update state engines for all the operating countries.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 32% of the total text.

Page 01 of 5

Portal Registration State Engine and State Engine Administration Console

Portal Registration State Engine produces a global standard component to be later personalized in each local operating country. The portal user registration component has the following complexity factors:
- Local registration process implementation is different in each Operating Country (Opco)
- Multiple user types are involved (consumer, business, account manager, delegated….)
- Multiples products/services are not uniquely adopted or codified across OpCos
- User registration has a strong dependency on the local OpCo infrastructure
- Multiple input channels (shop, web, call centre, post, email, ...)

A conceptual data driven model had to support the following logical steps:
- Content/form to display at any point in the registration process (i.e. displayForm1(), displayForm2()..)
- Functions to be executed within portlets (i.e. function1(), function2()..)
- Data to be retrieved (i.e. getUserProfile(), getCustomerInfo(), getCustomerState()..)
- Data to be updated (i.e. updateCustomerUserProfile()..)
- Notification to be sent (i.e. eMail, SMS)
- State change conditions


The model of Portal Registration is supported by a bespoke "State Engine" component that will provide a data model pattern and an engine process service to support the implementation of a flexible registration process relied on the user/customer conditions and states.

State Engine component pilots the process flow based on customizable XML State Data Model, which can be extended to cope with local requirements, and provides interfaces to the portal, which will make use them in order to manage the entire registration process upon the customer state and the specific product/service lifecycle; XML State Data Model contains all the registration states and their related actions.

The state engine, based on the XML data model, will exercise the registration process in its entire path.

Below is an overall picture of State Engine interactions with other components, including Portal and IDM (IDentity Manager):

1


Page 02 of 5

(This page contains 00 pictures or other non-text object)

Figure 1 - Portal Registration Components

Each color (Figure 1) represents a different component or component type in the system from a static point of view; the arrows and related numbers, on the contrary, stand for the dynamic scenario and show the interactions among the different components.

The components that play some role in the registration process are the following, color by color:

(This page contains 01 pictures or other non-text object)

Figure 2 - Colors meaning of portal registration components

The main scenarios involved in the registration process are essentially the following:

2


Page 03 of 5

USER SCENARIO:

This may be a new user who wants to register itself to the portal or an already registered user that wants to (de)register some products/services or deregister its account.

When a user logs in the portal, a suitable portle...