CA2305112A1 - System and method for relocation of telecommunication services - Google Patents

Description

ServiceSwitch.com Want users with pre-loaded stickiness?
We've got 500 million for you!
Project Overview - DRAFT
March 30th, 2000 ServiceSwitch.com Inc. Confidential and Proprietary ServiceSwitch.com "Creating Internet LiquidityT"""
Executive Summary:
The Internet landscape is getting more and more competitive and so is the battle to get and keep customers. Stickiness is the only weapon that will guarantee a customer will stay with you...
What if something better comes along?... Better Features, Quality of service, Price, etc... How do you get users to switch service providers if their lives (stickiness) are already are embedded in a competitor's service?
We offer a solution to this problem!
Our Mission:
ServiceSwitch.com provides the first comprehensive system which enables consumer and business users of Internet services to move their intellectual property (stickiness) to a competitor's, our partners, services for an incentive... To become the leading Internet persona movement company.
We displace stickiness and make 500 million existing Internet service provider users and their data available to our affiliate/partner Service Providers for a nominal fee...
Our partners will be able to offer their own branded and customized version of our service and get new customers that would not otherwise be possible!
ServiceSwitch.com will offer a complete affiliate branded hosted solution.
The Opportunity:
Users generate revenues and are the biggest asset for any Service Provider!
Pureplay Internet Portal Service Providers spend an average of $108 U.S. to acquire each customer (March 2000 issue of Business 2.0). Telcos and financial institutions spend a much higher amount to acquire customers since subscribers of these services generate much higher revenues for them.
There currently exists thousands of well established and financed service providers worldwide which could be ServiceSwitch.com customers in the following markets:
~ Pureplay Internet Portals (ex: Yahoo.com) ~ Wireless Service Providers (ex: Bell Mobility) ~ Telecommunications Service Providers (ex: AT&T) ~ Application Service Providers (ex: HotOffice.com) The number of web-based services is growing exponentially. Primarily due to the wide spread growth of web software-development tools and the market demand for browser-based software. With this explosion, it will be more important for users to have the ability to switch from one service to another ...taking all of their content-creation efforts along with them from one site to another.
Thinking big:
Banks and Financial Institutions have excelled due to the high switching costs of moving from one bank to another. Via the web, a bank customer can check account balances, pay bills and review account transactions. That's all that ServiceSwitch.com needs. By establishing a partnership with banks and getting permission from the customer, we can generate all the necessary forms required to switch services.
How much would this be worth to the customer? How much would this be worth to the service provider, in this case, the online financial institutionlbank (ex:
Wingspan.com)?
Current Status:
We already have a working prototype which has been developed and tested over the past 5 months and have filed for patents regarding our concepts and technology. We have a management team with the experience and knowledge to succeed and we plan on being first to market with a production service which will be ready by October 2000 We want to establish ourselves as the Ebay of services switching.
ServiceSwitch.com now requires $x.x million of investment in order to expand and speed up it's development and marketing activities for it's next phase.

The ServiceSwitch.com Market Opportunities:
Services Convergence:
As the Internet continues it's explosive growth and new technologies in the Wireless space and increases in bandwidth capacity, convergence especially between the telephony, wireless and Internet service providers will be significant.
As this happens, there will be a high turnaround of customers who will require their persona to be moved. ServiceSwitch.com is prime to take advantage of this phenomenon.
We will partner with customers in the following markets...
Telecommunications Services Wireless Financial Services Services Service Switching Engine>
"Creating Internet lJquidity"
ASPS Internet Portal Services ~ Wireless Market:
With the advent of emerging wireless devices and communications services which offer instant access to your e-mail, calendaring and stock information. More and more celco's (cellular communication services providers) are partnering with established Internet portals to integrate each other's services and offer 1 bundle to the user...
As an example, in Canada, Bell Mobility will be bundling the Lycos.com services such as e-mail, calendaring and stocks to their wireless customers. Rogers/AT&T will be bundling the Excite e-mail, calendaring and stocks to their wireless customers. What will happen if a Bell Mobility customer wants to switch to Rogers/AT&T (because Rogers/AT&T is now offering a much better price than Bell Mobility?... The Bell Mobility customer has his or her entire life now integrated into the Bell Mobility/Lycos system and would require alot of work to switch this over manually to Rogers/AT&T... ServiceSwitch.com will have significant opportunities in the wireless market where high turnarounds are frequent based on ever changing prices, quality of service and new features...
~ Pureplay Internet Portals:
~ Telcommunications Service Providers It will be absolutely critical for telcos (and celcos) within the next 3 years to own the majority (or 100%) of your online persona. All communication services and devices will enhance the life of it's users (communications management services) by relying and leveraging information from the following sources:
~ Your Unified messaging mailbox ~ Your calendar ~ Your address Book ~ Your folders ~ Your mailing lists...
~ Your behaviour Your stock portfolio ~ Your sports preferences ~ Your Weather preferences ~ ... and any other service based persona information which can be leveraged Communication Service Providers will offer super bundles to users and since their persona will be completely tied into the service, owning that persona will be essential and worth a significant amount to the service provider.
ServiceSwitch.com will allow our Telco and Celco partners to obtain users' persona from service provider sources or competitors. The opportunity is enormous in this space.
~ Financial Service Providers More and more people are starting to take control of their investments and the Internet is enabling them to do so conveniently. A high percentage of novice investors first start by monitoring stocks of interest on sites that allow users to build free stock portfolios and get near real-time quotes. Owning users at this level is worth a lot to service providers since they can generate revenues by advertising and up-selling possibilities. All online financial service providers are constantly adding new features and improving service quality.

The Value Chain:
"Everyone Wins!"
Service Providers get new customers which would not have been possible to obtain otherwise...

Service Providers com ServiceSwitch Users .

(affiliates/partners) servlceswltch.com will earn a fee .Users switch .service Providers obtainfrom the service providers to another servicenew (or re-sellers) Provider and get users which are Instantlyeverytime users switche a better deal pre- service either on features,loaded with stlckyness providers.
price, quality and have of service or offered them a better brand deal. This will Increase their fmmedlate and long term revenue base either by advertising and/or subscriptions revenues and up-selling capabilities.

Version 1 Features:
~ This version is built to be extremely high speed, reliable and scalable.
This is achieved by using a sophisticated switching queue control system and a multi-threaded architecture that can spawn a high number of simultaneous transfer sessions It's components will be built to run on Windows NT with minor components on Linux to fully maximize on speed advantages.
It will offer affiliate administrator the option of totally customizing the look and feel of the service so that the user continues to think they are still in our affiliate's site and keeps the trust.
The switching experience for the user will be extremely easy and rapid.
Another major aspect of this version is the Billing module.
User Features:
~ Switch services ~ Service Provisioning ~ View transactions log Administration Features:
~ System Administration ~ Affiliate/Partner system administration Core Architecture Special Technical Features:
~ High level of Security ~ Affiliate/Partner Billing Module ~ Affiliate/Partner service provider interface (API) ~ Friendly user interface ~ Conflict management and resolution agent ~ Switching Incentives Wizard ~ Service Provisioning Module ~ Service Switching Engine ~ Modular based architecture ~ Multi-threaded architecture This version will switch the following elements:
- User profiles - Messages - Folder structures - Address books - Calendars/Reminders Version 1 Source Service Providers:
~ Yahoo, Hotmail, Excite, Infoseek, Lycos, AOL, MSN
Version 1 Components Overview:
Wnte -~- Wnte - ~. wee-_._~ ~ user -.
Thread Thread Thread i Intertace _ O r-1 i Multi Thread Process _7 ~ ~ , -. Mgr.
Read ~ Read ~_I Read Thread ~ Thn:ad ~ Thread Multi Queue __-Mgr. ri Aff iliate ~l lMgr l Read/Write Queue Transactions ,'~~~ Affiliate Request DB ~ DB~ ~ DB
I
Billing L
L.~... Mgr.
Future Strategy I Vision:
(insert here) Future Versions Features:
- Contact Managers - WorkGroup / Collaboration - Bank/Financial accounts - Document Storage - News and Weather Preferences - Sports Preferences - Persona Management Future Versions Source Service Providers:

~ USA.net, MyEvents.com, eCal.com, Altavista.com, NetCenter.com, When.com, (Planet Calendar Services, (Planet Web Messaging Services, AnyWho.com (AT8~T), Egroups.com, & many others...

Business Model:
Users are worth money to service providers!
Why?
~ Advertising Brand awareness ~ Upselling ~ Subscriptions Our partner's browsing userslpotential customers will be presented with compelling incentives for switching from their current services...
Switching Incentives are:
~ Price Quality of service ~ Features ~ Other Revenue Streams:
~ User switching transaction fees (from partnerslaffiliates and re-sellers) Selling aggregate market data on users behaviors Licensing technology Evolve... Offer Free version of service (self-portal) with Advertising...

ServiceSwitch.Com - Vision Statement "Creating Liguidity for LifeT'"~~
Sandy Walsh - Jan 27, 2000 A Little History Stickiness is an over-worked term in the Internet business. Stickiness is the ability for a web site to draw its users back to the site time and time again. There are a number of ways to accomplish this:
~ constantly change the content, and keep it interesting enough for people to come back ~ provide a simple way for people to enter data into the site, thus producing a dependency on the site.
Consider a web site that offers some service like email. You can easily create and receive emails, you can easily create a list of your friends email addresses. The bigger the list gets the easier it is to create emails.
The more emails you send, the more you get. The more you email get, the more you become dependent on the web service to receive critical information. It quickly snowballs into something huge.
Now, consider the work you have to go through to switch to another email service. First, you have to create the new account. Then you have to start using it ... but all your contacts still use the old email address.
Even if you email them all and let them know the email address has changed, it still takes time for this to sink in. They still send email to the old address. Your friendly address book is stashed away on some server that you can't get at, so you have to manually re-enter all your email addresses. Without doing a surgical cut from the old service, this switch can take a lifetime. So, the switching time from Service A to Service B
can take months.
Well, that's email. But consider all the other web services cropping up daily:
~ stock portfolios ~ group calendaring ~ project planning ~ threaded discussion groups ~ document management All of these services generally create stickiness by drawing you in, but giving you very little means for getting out. It's usually a long drawn-out manual process. In short, people usually stick with one service.
That leaves very little opportunity for the up and coming little guys.
ServiceSwitch.Com intends to fix this by Creating Liguidity for Life!
The Opportunity ServiceSwitch will create proprietary software to log into a web-based service, extract the users private and personal information and, for a fee, move it to another web-based service ...
all in a secure and expedient manner.
The number of web-based services is growing exponentially. Primarily due to the wide spread growth of web software-development tools and the market demand for browser-based software.
A few notable services include:
~ www.concentric.net ~ www.netopiavo.com ~ MyExcite ~ MyYahoo MyAOL
~ MyDeja ~ www.321 intranet.com ~ Twigllmp Intralink ST
~ Catouzer Synergy www.hotmail.com www.anyday.com www.jump.com www.desktop.com www.hotoffice.com www.visto.com Netcentral ~ www.instinctive.com ~ Web.Dox www.when.com ~ www.appoint.net Some interesting growth figures for web-based service are as follows:
Deja.com 45,000 discussion forums Zcentral.com Launched in April 1999 ... 10,000 users so far .comfax 30,000 registered users since June 2, '99 Critical Path 5,000,000 outsourced mailboxes USA.net 8,000,000 email users HotMail 12 million registered users as of '98 70,000 new users daily Excite@Home 20 million registered users as of Jan '99 @Home has 65 million cable installations HotOffice about 3,000 clients as of April, '99 Sympatico over 500,000 users The ASP market is growing at exponential rates, which by its nature will force more and more software vendors to offer web-only versions of popular software. With this explosion, it will be more important for users to have the ability to switch from one service to another ... taking all of their content-creation efforts along with them from one site to another.
Thinking Big Without even knowing it, some very big companies have exposed themselves to the power of the Internet.
Consider banking institutions ... in a rush to get to the web, they opened themselves to a weakness. Banks have excelled due to the high switching costs of moving from one back to another. Look at an average customer with a chequing account, a savings account, a line-of credit and a visa card. They also have automatic deposit from their work into their chequing account and automatic withdrawal from the same account for their mortgage, car and RRSP. They still have to manually pay their cable, heat, property tax, cell phone, Internet connection and phone bill.
If that customer desired to switch these accounts from, let's say, CIBC to Royal Bank, it would take a considerable amount of work. Hows and hours of analyzing their account numbers, all the dependant creditors, account balances, etc. It's really too much for the average person to bear.
But what if this was automated?
Via the web, CIBC has "PC Banking". You can check your account balances, pay your bills and review account transactions.
That's all ServiceSwitch needs!

By scraping this data from the web, we can extract the following information about this customer:
~ which accounts they have ~ account balances including credit cards and PLC's ~ which automated deposits are made in each account ~ which bills are registered to the customer, with the 3'd party account numbers ~ and much more By establishing a partnership with Royal Bank and getting permission from the customer, we can generate all the necessary paperwork required to switch services.
We have to create filled-in forms for:
~ the Royal Bank to create all the required accounts and credit cards (with enough of an overdraft to avoid in-sufficient fiends during the switch) ~ the Royal Bank to create all the required pre-registered billing accounts ~ the customers employer to change direct deposit locations ~ the third-party creditors to change automatic withdrawals How much would this capability be worth to the Customer? To the Royal Bank?
Thinking Big for ServiceSwitch means exploiting holes created by old companies jumping into the web too quickly.
Creating Stickiness for ServiceSwitch.Com We can simply charge a transaction for a user to move from one service to another and expect reasonable success. However, as with any successful web site, we need to draw the user back for multiple transactions.
To successfully switch from one email service to another requires, not only moving the email addresses, folders and mailing lists. But also monitoring the old email service for activity after-the-fact. So, for a period of time, let's say three months, ServiceSwitch.Com will monitor the old email site for stray emails.
We can report to the user on the activity levels that these old services are experiencing.
For example, let's say you use four web-based email systems:
Bill~(~hotmail.com BbobCa7fyahoo.com But, you have just moved over to Deja.Com, so your new active account is:
Bill~(yde'ao com Over the three month period after the switch, you should see a decrease in the amount of traffic this site experiences:

Exam le switch from Hotmail and Yahoo to Deja:
_ r ~_.
v. ., w By giving a on-going update on how successful the transition has been, the user has a reason to return to our site. More importantly, for a fee we can notify the straggler sends informing them of the new address.
We have to think of creative ways to draw users back to our site after the initial conversion has occurred.
The Strategy ServiceSwitch.com is in an interesting position.
First, we need a proof of concept to illustrate the potential of what we have in mind. We need to show that it is technically feasible to do.
Secondly, we don't want to publicly show our hand so as not to invite competition too early. To hit the widest audience we need to create support for as many different services as possible.
This is in itself a tricky decision, as many site have considerable depth of functionality. We can spend our time become experts on a given site or become moderately knowledgeable on a wide range of sites. We need to hit the sweet-spot of functionality across all services, extracting from them the critical information that will assist the widest audience. We don't need to spend a lot of time supporting every little feature of a service.
Phase One - Proof of Concept Important questions for a proof of concept include:
~ Which categories of web services will we support?
~ Which web services will we support?
~ What level of support will we provide for each service?
As a first pass, we should look at the majority of web-services currently in use by the population. This generally means emai! and stock portfolio management.
Specifically, the web services of interest should be the ones with the largest user communities. Other possibilities for this selection would be to select the most technically challenging. The rationale being, if we can handle them, we can handle any of them. Since we are interesting in showing this prototype off, we should stick to what people can relate to. Therefore we will go after the widest audience.
Finally, we have to look at email and stock portfolios individually to determine what level of support we should offer for each.
Email Services A typical email service has the following components:
~ address book ~ mailing lists (lists of users, grouped by a particular interest) ~ storage folders (groups of received emails, clustered by a category) ~ each storage folder contains a list of actual emails An email consists of:
~ the recipient (To:) ~ the sender (From:) ~ carbon copied recipients (Cc:) the subject line ~ the send/received date ~ the body of the message ~ attachments Once read, an email generally has little use to a user. The real value is the email addresses. Whether they are in the address book or still living in the actual email itself. When moving to another service, the user should have the option of only moving the primary data, the secondary data or both.
Stock Portfolio Services Stock portfolio services do not always have to manage your personal actual stock portfolio ... if you even have one. Rather many people use web-based portfolio services to monitor hunches. They generally enter the stock symbols of interest, the current market value and then keep an eye on it over time.
A general stock portfolio consists of:
~ the portfolio name (often classified by some category. Le. mining, technology, biomed, etc.) Within each portfolio, we generally are interested in:
~ the stock symbol ~ the purchase price ~ the number of shares held ~ the date the stock was purchased (optional) We do not need the hi-low, buy-sell, market value or any of the other statistical values, since these are obtained by the web-service itself.
When the user locates a new portfolio service with more/better features, they may want to change. For example, from MyExcite to SmartMoney.com (a real world example ... because I
really want to do this!) Similar to the email strategy, we simply provide the username and password for MyExcite, then for SmartMoney. The system then extracts the above list of available portfolios, then stores it to its local database, and ultimately transfers it to its new home.
Limitations with a Proof of Concept As the name implies, a proof of concept means that it's not-ready-for-prime-time, but rather shows that something is technically possible. The realities of the real world often impose radically different design considerations than the proof of concept.
The purpose of this proof of concept is to create a demo, not a final product.
Once we waltz the demo under the noses of enough market-savvy people we can start on creation of a robust, flexible and scalable implementation.
This is often called Kleenex Software, because it's like a tissue: Blow and Throw.
Phase Two - Getting Ready for Market After the proof of concept, and a "product viability" roadshow, we start on the full-blown commercial version. This version must exhibit the following characteristics:
~ Scalable; able to service hundreds of concurrent user sessions ~ Wide market scope; providing support for a full range of existing web services. Including the ones listed above ~ Sound underlying technology; with a set of base software that allows for quick driver development. A
driver is a piece of software that support a specific web service. There would be a separate driver for each service available ... one for HotMail, one for Excite email, one for Excite stocks, one for Deja, etc. Our ability to rapidly develop these drivers is key to our success.
~ Isolating the screen-scraping code; as we move into other verticals and services, we will quickly need to change our system to accommodate alternative user interfaces. By having a flexible, component-based underlying architecture this can be achieved.
~ Full e-commerce support, including on-line credit card processing and outbound SSL support to secure web services likes banking. Security is king in this market.
~ A rapidly configurable web-site; with the ability to quickly change the daily content on the site.
Making a web site like a newspaper increases repeat usage, which equates to more transactions for us.
This implies a strong database driven content architecture vs. custom HTML
code.
~ Brand-able; creating an Other Equipment Manufacturer (OEM) version of the software is also key to our success. Services like AOL, Yahoo, CIBC will certainly want to offer our movement services within their site. To play in their game, we have to be able to change the look-and-feel of the system to match theirs.
A Phase One Use Case Use Cases are used in software development to articulate how an average user will interact with the system in a typical fashion. Use Cases are intended to identify the 80% functionality that most people will use.
Most other interactions and features/functionality are usually variations cm this base Use Case.
The user comes to the www.ServiceSwitch.Com web site v The user enters his username and password W w Q

N
c U
(~
.

"e O
C
~' O

U
(B

Q
C_ fB

O
IB

d N .1 (6 U

f0 a7 Q7 _(B

O
O
O O

U d O
U
t a U O
~ _ N

CE ?, _ fn ~_' 7 O

a7 a7 7, ~
(B

S, C O

~ N O
~

CO
N
O

~ Q
_ O d ~ O
O
~
O

O ~

Q
C O O
~ O
J

N cu ~ o A d -a C C
~ (~

U cB ~ ~ ~

U
_ fB L,~, ay D o I I

LLJ C~ ~ a ~ LLI
U

i .1,;.

VI ~ ~ Y7 ml °~ ~ N
NI C01 m N M
~I WI ~ N N
hl ~ N N
471 ~ N N
ml N ° N 'Yi;
nl ~ N N
ml ~ ~ N
hl VI ~ ~ N 3 MI ~ ~ N C1 NI QI m H
~I WI
A.
n A:
u, 3.
of ml of °ml °o mo M oI c°o of ml of ~~ of ml WaDCD01 O O~'~'tW~~~NN('!f'7 z~ y fI'~
~~

,c y ~~~aa ~t ~
y ~aa:-s a ,r t~

;;$~,~r "..
~

'~'. ~ ~
, t r~
z'~

~#~ 3t~:..a,.
z , ~
" , wrr~rrrr ~ 0 , i# ~
~" ~ 3 a ~

1 ~'i~ d 7 ~ t ' . f _ , i Ya.

~A ~~~~' ~ a~
~. ~ ~..

9~FI~ r ..
1~ ~
~
~~~

.~t, .,07 2 i~
~'.3..... : 5 .. ~ r.
,, ~.. ~7.~
,..~rtS3 ,., 9k :zE ~ ' a ~p v 5 psrs it Functional Units User SSL Support ISPs, ASPS
Residencies Cookie Management Switch Tendencies POST/GET operations Inference Engine Multi-threaded architecture High availability Conflict Resolution Address Books Portfolio Accounts Content Purchases Automatic Transactions Lists/Groups (symbol, amount, when) Bills Yahoo SmartMoney CIBC

Excite E-trade TD

HotMail Ameritrade Royal Bank Sympatico CIBC ' Bank of Montreal Deja TD Greenline Bank' of Nova Scotia Note that each of the following components are proprietary software packages developed, maintained, hosted and managed by ServiceSwitch.com Web Presence: this is the ServiceSwitch.com web-site. This site is not normally accessed directly by the client, but rather is referred to by a partner web-site. The web-site will then portray the look and feel of the referring web site.
Queuing Engine: The queuing engine is a front-end application to the RDBMS. It takes business logic events and translates them into entries in the database schema. The Scheduling Engine, Read/Writers and Persona Managers all interact with the Queuing Engine rather than with the RDBMS directly. Items such as queue items, logging and billing information all pass through this application.
Scheduling Engine: The Scheduling Engine watches for items in the queue and matches them with the appropriate Reader/Writer based on the current load of the system, the priority of the request, and the "best-match" of the reader/writer to the request. It may be considered a "dating service" for switch-reauests.
Core Reader/Writer: Reader/Writers (RW) fetch client data from one service and move the data to other services. There are specific RW's for each service the client may use. The Core RW
takes care of operations common to all RW's regardless of their specialty.
This includes, but is not limited to, 'Cookie' management, talking with the services web server, and SSL (Secure Sockets Layer) certificate negotiations.
Vertical R/W: To build on the Core RW's, there are also RW's that are specific to a particular vertical, e.g., Email, Stock Portfolios, Banking, Application Service Providers (ASP). These Vertical RW's (VRW's) take the raw HTTP/web communications and translate them into industry specific business objects. Business entities such as accounts, portfolios, mailing lists, etc all reside in the VRW's Specific VRW: at the most fine-grained level of the system are the Specific VRW's (SVRW's).
The SVRW's are the exact implementations for dealing with a single web-based service. Services such as YahooTM Email, YahooT"~ Stock quotes, CIBCT~~ portfolio manager, HotmailT~~ email would all require their own SVRW's.
Persona Manager: As the system extracts more and more information about a particular client, this information is accumulated in the Persona Manager. The service traits, level of support, feature utilization, etc., of a particular user are stored in this system and analyzed with an inference engine.

Database Schema Features Supported Site Features Integer ID Integer SiteID Integer SiteID

Integer Feature Integer FeatureType String SiteName Type String Desc String URL

Re uest Audit Integer ID State Change Table Integer ReqID DateTime Request Integer ReqID

DateTime When Integer State Integer FromState Integer EntryType Long FromSite Integer ToState String Comment String FromUsr DateTime ChangeTime Integer CurrState String FromPwd String Comment Long ToSite String ToUsr ransaction Data String ToPwd Integer ReqID

Integer ReadWriteID Integer DataType DateTime RefreshTime Text XMLData Integer TransID

Data Tvpes DateTime EntryTime Integer DataType String DTD
This is the database schema which is managed by the Queuing Engine. All operations stem from the Request Table. Each operation, e.g., extraction, move, or refresh, is written into this schema.

The schema does not depend on the content of the data being moving, that is, it does not care whether the data is an email or a stock portfolio. The details of this information are stored in the Data_Type and Transaction tables as eXtensible Markup Language (XML)-based textual information. The Document/Data(?) Type Definition (DTD) of the vertical specific data is updated and versioned in the Data Type table.

State Transition Diagrams To Be Assigned:
New request waiting to be assigned to an R/W
Read: Read Error:

A Reader has been The read could not proceed.
assigned to extract data from Retry later.
source site. Retry Sleep:

Waiting to try again.

Write: Write error:

A Writer has been The Write did not succeed.
assinged to put data on the atargetRetry later.
site.

Sleep:
The operation was successful.
Check again after appropriate period.
Refresh: Expired:
Recheck the legacy Source This is a dead request. It wont sites) for any activity. be looked at again.
A request has a life-cycle. It starts as a new request, ("To Be Assigned"), for a switch to occur.
Then, behind the scenes, it transitions through the steps of actually performing the switch, "Read", "Write", and at the end of the session, "Sleep". If an error occurs on the read ("Read Error") or write ("Write Error"), it waits for a while ("Retry Sleep") and retries the operation.
Once the initial switch is performed, the request sleeps for a while until the system thinks that something new or interesting may have occurred on the source site.
At this point it lives for a period in "Refresh" state, where it periodically wakes up and checks the source site for any renewed activity there. After a spell of refreshes (about 3-6 months or suitable inactivity in the account), the request is "Expired" and the job is done.

Primary Sequence Diagram Ready A sequence diagram is basically a flow-chart without the decision-making portions. It shows the relationship between multiple components of a software system in terms of message flows.
S~1"'YK~ - l'~1 This first sequence diagram shows a request from a user to move some data from one service to another service. The specifics of what type of service it is are irrelevant since this is handled at the SVRW level. Whenever we speak of a RW, we are actually talking about an SVRW.
Remember that we only ever create SVRW's, it just so happens that all SVRW's share Core RW
code. Similarly, all email related SVRW's share Email-VRW code.
We see the request for a move come in from our "Web-Presence" on the left. The queuing engine handles the request and waits for the scheduling engine to find the best-suited RW to handle it.
Based on the load of the system and the priority of the request (e.g., new switches are higher priority than refresh switches), the scheduler will allocate a RW to do the work. When the SVRW is finished with its previous chores it asks the queuing engine for the next item to process. First the reader portion of the RW extracts the information from the source web-site and places the data in the RDBMS via the queuing engine. All the data extracted is stored in a specific XML format for the type of data it relates to. There is a single definition for an email, just as there is a single definition of a portfolio and bank account. This is critical in ensuring consistent data movement across RW'ers.
All the while, the user may carry on with other activities while this work is being performed.
When the reader is done, it marks the request as "READ DONE" and waits for the "Scheduler"
to allocate the appropriate writer to finish the job.

grimar-y Sequence Diagram (Write) Continuing on from the read, once the write is finished, the user is notified and the billing information is updated.
~. ~ 1t~"lrC~~t a _, 1 .

Primary Sequence Diagram Update Periodically, e.g., daily, weekly or monthly, the (old) source account (Legacy Site) is reviewed for activity.
While particular embodiments of the present invention have been shown and described, it is clear that changes and modifications may be made to such embodiments without departing from the true scope and spirit of the invention.
The method steps of the invention may be embodiment in sets of executable machine code stored in a variety of formats such as object code or source code. Such code is described generically herein as programming code, or a computer program for simplification. Clearly, the executable machine code may be integrated with the code of other programs, implemented as subroutines, by external program calls or by other techniques as known in the art.
The embodiments of the invention may be executed by a computer processor or similar device programmed in the manner of method steps, or may be executed by an electronic system which is provided with means for executing these steps. Similarly, an electronic memory medium such computer diskettes, CD-Roms, Random Access Memory (RAM), Read Only Memory (ROM) or similar computer software storage media known in the art, may be programmed to execute such method steps. As well, electronic signals representing these method steps may also be transmitted via a communication network.
The invention could, for example, be applied to computers, smart terminals, personal digital assistants, Internet or two-way pagers, satellite telephones, Internet-ready telephones or other Internet, television or telephony appliances. Again, such implementations would be clear to one skilled in the art, and do not take away from the invention.
S~1"V~~.".,~W'I~'C~11't ' -~ 1.

Claims (34)

WHAT IS CLAIMED IS:

1. A method of data extraction comprising the steps of:
comparing a data file to a data template to extract non-template data.

2. A method of legacy data extraction comprising the steps of:
comparing a new data file to an older data file to extract time varying updates.

3. A method of automatic account set up comprising the steps of:
responding to requests for data from a web site by providing said data.

4. A method of automatic account set up comprising the steps of:
responding to requests for data from a web site by providing said data in emulation of a user entering said data.

5. A method of data extraction comprising the steps of:
extracting formatting code from a markup language data file to obtain data.

6. A method of data extraction comprising the steps of:
extracting formatting code from a markup language data file to obtain data types.

7. A method of obtaining data from a web site comprising the steps of:
requesting and obtaining data from a web site in emulation of a user requesting said data.

8. A method of converting data comprising the steps of:
converting said data from a source format to an intermediate format.

9. A method of converting data comprising the steps of:
converting said data from an intermediate format to a target format.

10. A computer-based method comprising the steps of:
extraction of data from a source in the source's format transmission of said data from the source to the service switching facility, conversion of said data from the source's format to an intermediate format , storage of said data in intermediate format in a temporary memory, conversion of said data in intermediate format into the format required for the destination, transmission of said data from the service switching facility to the destination

11. As 10 with the addition of means to analyse, record, and reconstruct the data structures [folder structures] of the source system in the destination system.

12. As 10 with the [additional] [preliminary] step comprising:

the end-user initiates the process by [filling in an html form] and [pressing a submit button].

13. As 10 with the [additional] [preliminary] step comprising:
~ prior to the transmission of any data to the destination, the said destination is [prepared] primed to receive the data

14. As 10 with the addition of a means to [take account of] OR [circumvent]
the complex and ever-changing session control requirements of the source service.

15. As 10 with the addition of a [timer] means to log on to the source system at [appropriate]
intervals to monitor for the arrival of mail and send a message to the end-user at the destination system informing of said activity.

16. As 10 with the addition of a means to invoke automatic forwarding of mail received at the source (now the 'legacy') system.

17. As 11 with the addition of a means to record details of the transaction for billing purposes, to provide and audit trail, and to give credible feedback to the initiating end-user.

18. As 10 with the mechanism to derive the relevant source data by analysis of the html using a 'delta' technique [subtracting template information from the data and recognising the various types of data by 'positional information', tags or sequence] ([I
assume this is prior art andnot to be subject of a separate application!])

19. As all of preceding claims with addition of a single queuing system for tasks to ensure optimal use made of resources, and that priorities can be assigned to tasks to minimise affect on the end-user of system delays.

20. As all preceding claims, with the addition of the ability to generate multiple parallel transactions with the source system to improve the speed of transfer of the data. [multi-threading]

21. As all preceding claims with the addition of the ability to include 'brandlining' of web-page to amke it 'appear' to be 'owned by' the 'partnering organisation', although in fact it resides on the 'service switching facility'

22. As claim 10, but adding the ability extract data from multiple sources, combining like data in the service switching facility, and transferring said combined data to a single destination service.

23. As claim 10 with the addition of a means to generate multiple destination copies for each source.

24. As claim 10 with the addition of a means of [SSL] encryption to provide a level of security for the data throughout the transfer process.

25. As for claim 10, but omitting steps for translating into a temporary meta data, instead doing 'on the fly' translation between source and destination formats.

26. As for Claim 10 with the addition of step(s) to record information directly pertaining t o the habits of the end-user in order to provide a 'persona' profile of the user for business purposes.

27. A method of data extraction comprising the steps of:
sorting and extracting data from a plurality of arriving data packets.

28. A method of data extraction comprising the steps of:
creating a folder structure for arriving data.

29. A method of data extraction comprising the steps of:
creating a folder structure for a target web site which mirrors a source web site.

30. A method of data extraction comprising the steps of:
extracting a folder structure from a target web site.

31. A system for executing the method of any one of claims 1 through 30.

32. An apparatus for executing the method of any one of claims 1 through 30.

33. A computer readable memory medium for storing software code executable to perform the method steps of any one of claims 1 through 30.

34. A carrier signal incorporating software code executable to perform the method steps of any one of claims 1 through 30.