(12) United States Patent
`Freishtat et al.
`
`US006317783B1
`US 6,317,783 B1
`Nov. 13, 2001
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`(54) APPARATUS AND METHODS FOR
`AUTOMATED AGGREGATION AND
`DELIVERY OF AND TRANSACTIONS
`INVOLVING ELECTRONIC PERSONAL
`INFORMATION OR DATA
`
`(75) Inventors: Gregg Freishtat; Palaniswamy Rajan,
`both of Atlanta, GA (US)
`
`(73) Assignee: Verticalone Corporation, Atlanta, GA
`(Us)
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`( * ) Notice:
`
`(21) Appl. No.: 09/428,511
`(22) Filed:
`Oct. 27, 1999
`
`Related US. Application Data
`(60) Provisional application No. 60/105,917, ?led on Oct. 28,
`1998, and provisional application No. 60/134,395, ?led on
`May 17, 1999.
`
`(51) Int. Cl.7 .................................................... .. G06F 13/00
`(52) US. Cl. ............................................. .. 709/218; 707/10
`(58) Field of Search ............................. .. 707/10; 709/217,
`709/218
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,347,632
`5,537,314
`
`9/1994 Filepp et al. ....................... .. 709/202
`7/1996 Kanter .................................. .. 705/14
`
`(List continued on neXt page.)
`
`OTHER PUBLICATIONS
`
`“Strategic Directions in Database Systems—Breaking Out
`of the Box,” Avi SilberschatZ, and Stan Zdonik et al., ACM
`Computing Surveys, vol. 28, No. 4, pp. 764—778, Dec.
`(1996).
`
`“Database Security and Privacy,” Sushil Jajodia, ACM
`Computing Surveys, vol. 28, Issue 1 pp. 129—131, Mar.
`(1996).
`“Managing Security and Privacy of information,” Sushil
`Jajodia, ACM Computing Surveys, vol. 28 Issue 4es, Dec.
`(1996).
`“Today’s Style Sheet Standards: The Great Vision Blinded,”
`Philip M. Marden, Jr. and Ethan V. Munson, IEEE Com
`puter, pp. 123—125.
`
`“Collapsible User Interfaces for Information Retrieval
`Agents,” Martin Frank and Pedro SZekely, Proceedings of
`International Conference on Intelligent User Interfaces, Jan.
`5—8, 1999, Redondo, CA, pp. 15—22.
`“A Softbot—based Interface to the Internet,” Oren EtZioni
`and Daniel Weld, Communications of the ACM, vol. 37, No.
`7, Jul., 1994, pp. 72—76.
`
`Primary Examiner—Kenneth R. Coulter
`(74) Attorney, Agent, or Firm—Needle & Rosenberg. PC.
`
`(57)
`
`ABSTRACT
`
`A system for delivering personal information according to
`the present invention includes a user store including end user
`data, a provider store including information provider data, a
`personal information store including personal information
`and a processor that communicates With these data stores.
`The processor selects an end user for personal infonmation
`aggregation. The processor connects With one or more
`information providers. The processor then proceeds to
`retrieve personal information for the selected end user from
`the connected information providers. This retrieval is based
`on end user data associated With the selected end user and
`provider data associated With the connected information
`providers. The retrieved personal information is stored in the
`personal information store.
`
`36 Claims, 11 Drawing Sheets
`
`510
`
`.1
`ORIGMTING Pl
`
`'
`(NATIONSBANK)
`
`END USER
`210
`
`s; 1?
`DATA]
`
`COMPANY WEB
`SITE (PI)
`
`COMPANY WEB COMPANY WEB
`SITE (Pl)
`SITE (PI)
`
`.
`
`l
`
`COM NY'S
`WEB SE \VER
`\\
`\
`\\
`\
`\\
`
`1
`
`1
`
`e
`/'
`/
`CRED" CARDS COMMUNICATIONS & CUSTOMER
`& MORTGAGES / MESSAGES (EMAIL,
`GENERIC
`FAX‘ VO|CE)
`CONTENT
`(PO RTAL)
`
`,/
`
`230
`
`/'
`(17
`pk PI ENGINE MK 24
`0
`
`/
`
`Plaid Technolgies Inc.
`Exhibit 1001
`
`Ex 1001-1
`
`

`
`US 6,317,783 B1
`Page 2
`
`US. PATENT DOCUMENTS
`_
`8/1997 B11001 ................................... .. 705/40
`5,655,089
`5,696,965 * 12/1997 Dedrick
`~707/10
`5,699,528
`12/1997 Hogan ....... ..
`. 705/40
`5,710,887
`1/1998 Chelliah et a1.
`705/26
`5,712,979
`1/1998 Graber er a1- --
`709/224
`5,724,567 * 3/1998 Rose ............. ..
`707/2
`5,825,884
`10/1998 Zdepski er a1-
`705/78
`5,848,396
`12/1998 Gerace ...... ..
`. 705/10
`705/26
`5,860,068
`1/1999 (399k ----- -
`5,862,325 * 1/1999 Reed et a1.
`.. 709/201
`5,878,219
`3/1999 Vance, Jr- et a1
`- 709/217
`5,884,033
`3/1999 Duvall et a1. ..
`.. 709/206
`5,884,045
`3/1999 Kurihara
`.. 709/237
`5,893,091
`4/1999 Hunt et a1. ..
`.... .. 707/3
`5,894,554
`4/1999 Lowery er a1-
`709/203
`5,895,468
`4/1999 Whitmyer, Jr.
`707/10
`5,897,622
`4/1999 Blinn et a1. .......................... .. 705/26
`
`5,898,836
`5,913,202
`5918214
`5,926,798
`579567709
`5963915
`5,978,766
`579787779
`5,983,200
`5983227
`5,987,440
`579877498
`5,991,735
`579917756
`5995965
`5999975
`6,029,175
`
`4/1999 Freivald et a1. ................... .. 709/218
`6/1999 Motoyama ........................... .. 705/35
`6/1999 Perkowski __________________________ u 705/27
`7/1999 Carter
`705/26
`9/1999 Xue
`" 707/3
`10/1999 Kirsch
`705/26
`11/1999 Luciw
`705/1
`11/1999 Stein et a1_
`705/37
`11/1999 Slotznick
`705/26
`11/1999 NaZem et aL
`707/10
`11/1999 O’Neil 6161.
`705/44
`11/1999 Athing et aL
`_ 709/203
`11/1999 Gerace
`705/10
`11/1999 Wu
`__ 707/3
`11/1999 Experton "
`707/10
`12/1999 Kittaka et a1_
`_ 7O9/224
`2/2000 Chow 6161. ....................... .. 707/104
`
`* cited by examiner
`
`Ex 1001-2
`
`

`
`U.S. Patent
`
`Nov. 13, 2001
`
`Sheet 1 0f 11
`
`US 6,317,783 B1
`
`REPEAT
`PROCESS TO
`SEEK
`ADDITIONAL
`PI
`
`Figure 1
`(Prior Art)
`
`I
`
`SELECT
`INFORMATION
`PROVIDER
`
`100
`
`LOCATE AND
`ENTER
`PROVIDER SITE
`ADDRESS
`
`120
`
`LOG INTO
`PROVIDER SITE
`
`130
`
`NAVIGATE
`EXTRANEOUS
`WEB PAGE(S)
`
`140
`
`VIEW DESIRED PI
`FROM PROVIDER
`SITE
`‘4
`
`150
`
`Ex 1001-3
`
`

`
`U.S. Patent
`
`Nov. 13, 2001
`
`Sheet 2 0f 11
`
`US 6,317,783 B1
`
`CLIENT
`COMPUTER
`
`2&0
`
`
`
`U‘ . . l-
`
`
`
`-
`
`__ D: *5
`
`l
`‘
`
`CLIENT
`SOFTWARE
`270
`
`p|
`HOST
`290
`
`Figure 2
`
`INTERNET
`
`PROV'DER
`
`COMFIUTER
`
`WEB SERVER 1
`
`—*_/
`
`\
`
`PROVIDER
`COMPUTER
`
`250
`
`Pl ENGINE
`240
`
`WEB SERVER
`
`Ex 1001-4
`
`

`
`U.S. Patent
`
`Nov. 13, 2001
`
`Sheet 3 0f 11
`
`US 6,317,783 B1
`
`Figure 3
`
`Site Monitor
`370
`
`Baseline Con?gure
`320
`
`End User
`Con?gure
`330
`
`Provider
`store
`310
`
`User Store
`360
`
`P1 Access/Transact
`340
`
`PI Store
`280
`
`Individual
`End User Pl
`375
`
`.
`PI Dellver
`350
`
`Ex 1001-5
`
`

`
`U.S. Patent
`
`Nov. 13, 2001
`
`Sheet 4 0f 11
`
`US 6,317,783 B1
`
`2N
`
`"DI
`
`
`
`1mm: 02m
`
`c2 2:5 w PEwE
`
`M
`
`wPEwzwm
`
`Ex 1001-6
`
`

`
`U.S. Patent
`
`Nov. 13, 2001
`
`Sheet 5 0f 11
`
`US 6,317,783 B1
`
`@mg
`
`emu
`
`m 95mg
`
`B M
`
`@ WQ\\\FW
`
`/
`
`Emma/02w
`
`J
`
`U /
`
`oNN
`
`Ex 1001-7
`
`

`
`U.S. Patent
`
`Nov. 13, 2001
`
`Sheet 6 0f 11
`
`US 6,317,783 B1
`
`Figure 6
`
`Provider
`Server
`250
`
`€——
`
`Client Computer
`PIEngme ——>
`.
`220
`240
`-.——-—> ‘—
`
`Individual
`End User P1
`375
`
`Ex 1001-8
`
`

`
`U.S. Patent
`
`Nov. 13, 2001
`
`Sheet 7 0f 11
`
`US 6,317,783 B1
`
`Figure 7
`
`Springboard
`Process
`13
`
`Traditional
`Process
`110
`
`Select Provider
`110
`
`PI Presentation
`Page
`760
`
`l
`
`Provider
`Desired Page
`150
`
`l
`
`Locate Provider
`Address
`120
`
`l
`
`Provider Login
`Page
`130
`
`Y
`
`Provider
`Main Page
`710
`
`Provider
`Intermediate
`Page
`—> 720
`
`140
`
`Y
`Provider
`Desired Page
`150
`
`Ex 1001-9
`
`

`
`U.S. Patent
`
`Nov. 13, 2001
`
`Sheet 8 0f 11
`
`US 6,317,783 B1
`
`DISTRIBUTOR STYLE
`SPECIFICATION
`830
`
`PROVIDER STYLR
`SPECIFICATION
`840 /
`
`PROVIDER
`CONTENT
`820
`
`?nsTRlsuToR
`CONTENT
`810
`
`870
`DYNAMIC PAGE
`GENERATION
`
`RESULTING
`PAGE
`880
`
`Ex 1001-10
`
`

`
`U.S. Patent
`
`Nov. 13, 2001
`
`Sheet 9 0f 11
`
`US 6,317,783 B1
`
`Figure9
`
`810
`
`820
`
`830
`
`840
`
`DISTRIBLTTOR
`~CONTENT
`LE‘
`
`PROVIDER
`\CONTENT
`\ ,
`
`DISTTRIBCTOR
`_\ STYLE
`‘if’,
`
`PEOVIO‘ER
`\ STYLE /
`X ,,
`
`\ I
`
`USER
`SPECIFIC
`CONTENT
`
`CONTENT
`MERGER
`910
`
`STYLE
`MERGER
`920
`
`860
`T
`
`GEES
`
`/ SPECIFIC \T
`I
`STYLE
`
`\_
`
`930
`COMPLETE
`CONTENT
`SPECIFICATION
`
`940
`COMPLETE
`STYLE
`SPECIFICATION
`
`!
`
`870
`
`STYLE
`APPLICATOR
`950
`
`#
`RESULTING
`PAGE
`880
`
`Ex 1001-11
`
`

`
`U.S. Patent
`
`Nov. 13, 2001
`
`Sheet 10 0f 11
`
`US 6,317,783 B1
`
`Figure 1 0
`
`IDENTIFY
`PROVIDER AND
`APPLET.
`1010
`
`ACCESS APPLET
`TEMPLATE.
`1020
`
`i ACCESS DATA j
`
`g 1
`
`FOR APPLET TEMPLATE.
`T
`'
`1030
`}
`
`INTERPRET
`APPLET.
`1040
`
`APPLET
`ENDS j
`106/
`
`SUPPLY OR
`RECEIVE DATA.
`1050
`
`Ex 1001-12
`
`

`
`U.S. Patent
`
`Nov. 13, 2001
`
`Sheet 11 0f 11
`
`US 6,317,783 B1
`
`Figure 1 1
`
`INTERMEDIATE SITE PAYS
`MINIlVIUM MONTHLY FEE FOR A
`GIVEN MONTH
`1 1 l 0
`
`PI ENGINE AUDITS USAGE BY END
`USERS VIA THE INTERMEDIATE
`SITE OVER A GIVEN MONTH
`1 120
`
`DEBIT MINIMUM MONTHLY FEE
`ACCORDING TO AN AUDITED
`USAGE
`l 130
`
`CHARGE INTERMEDIATE SITE FOR
`FEES IN EXCESS OF MINIMUM
`MONTHLY FEE
`1140
`
`Ex 1001-13
`
`

`
`US 6,317,783 B1
`
`1
`APPARATUS AND METHODS FOR
`AUTOMATED AGGREGATION AND
`DELIVERY OF AND TRANSACTIONS
`INVOLVING ELECTRONIC PERSONAL
`INFORMATION OR DATA
`
`CROSS-REFERENCE TO RELATED PATENT
`APPLICATION
`
`This application claims the bene?t, pursuant to 35 U.S.C.
`§119(e), of applicants’ provisional US. Patent Application
`Ser. No. 60/105,917, ?led Oct. 28, 1998, entitled “Apparatus
`and Method for Automated Aggregation and Delivery of and
`Transactions Involving Electronic Personal Information or
`Data” and of applicants’ provisional US. Patent Application
`Ser. No. 60/134,395, ?led May 17, 1999, entitled “Appara
`tus and Method for Automated Aggregation and Delivery of
`and Transactions Involving Electronic Personal Information
`or Data”.
`
`BACKGROUND OF INVENTION
`
`1. Field of Invention
`The invention relates to an apparatus and process for
`automated aggregation and delivery of electronic personal
`information or data (PI). The invention further relates to the
`automation of transactions involving electronic PI.
`2. Description of Related Art
`Looking back over the last ?ve years, it is apparent that
`as the Internet gained momentum, consumers demanded
`applications or services that make their online experience
`simpler, easier to use, and more satisfying. The development
`of successful Internet Sites has corresponded With a number
`of themes Which have developed over the last feW years.
`When carefully analyZed this evolution is a logical devel
`opment of the emerging digital economy.
`Prior to 1994, the Internet Was not a mass media, in part,
`because the existing technologies (FTP, Archie, Usenet, and
`Gopher) Were not user friendly and required the end user to
`do all of the Work (e.g., the end user had to learn of an
`existing data source, ?nd the address, navigate to the
`destination, and doWnload the information). As more con
`sumers began accessing the Internet, Search Engines Were
`created to solve this usability issue. With the advent of the
`commercial Search Engine, additional content could be
`easily added to the Internet and the end user had a means of
`?nding and accessing this information. Consumers required
`better tools than Search Engines for organiZing and access
`ing this Wealth of generic content. Push technologies Were
`explored, and eventually, the portal strategy Was success
`fully adopted as an ef?cient Way for consumers to easily
`access a variety of content sources in a single, easy to use
`format. As the volume of available online content continues
`to groW exponentially, portals are noW confronted With the
`need to make different types of content available to different
`consumers based upon their particular preferences and
`tastes.
`The phenomenal success of Internet portals and destina
`tion sites has demonstrated the importance of creatively and
`intelligently aggregating, organiZing and presenting the
`mass of information available on the Web. Search engines,
`portals and destination sites have Internet strategies based on
`the frequency, duration and quality of end user visits to their
`sites. For this reason, destination sites and portals are
`constantly seeking content and/or technologies Which drive
`quality traf?c to their site and keep it there. Recent trends
`indicate that Internet users are up to 25 times more likely to
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`come back to a site When this information is organiZed
`according to personal preferences.
`FIG. 1 displays the current process of acquiring online PI
`100. The end user ?rst selects an information provider site
`in step 110. The end user proceeds to step 120 by locating
`and entering the Internet address of the selected information
`provider. This step may be accomplished in several manners
`With varying levels of complexity. A simple means for
`accomplishing this step is the utiliZation of a bookmark or
`favorite Whereas locating an information provider for the
`?rst time might involve signi?cant time and effort perform
`ing online searches. In step 130, the end users logs into the
`selected information provider’s Web site utiliZing the site’s
`speci?c logon protocol. This protocol usually involves veri
`fying the identity of the end user using a user name and
`passWord or other means of veri?cation, acquiring the
`veri?cation data from cookies residing on the end user’s
`system or a combination of requested data and cookie data.
`The end user continues in step 140 by navigating through
`Web pages on the information provider’s Web site until the
`desired information is located. During this process, the end
`user is often required to visit Web pages of little or no use
`to the end user Whose goals is to simply acquire the
`particular PI residing on the Web site. Ultimately in step 150,
`the end user is presented With the desired PI. The entire
`process 100 is repeated for each individual piece of PI
`desired by the end user. Under this PI access model, the end
`user must visit each separate information provider, track
`potentially different identity veri?cation data for each, uti
`liZe a different user interface at each site and possibly Wade
`through a signi?cant number of ?ller Web pages.
`FIG. 4 pictorial illustrates the architecture of this current
`access process. The end user 210 utiliZes the client computer
`220 to access each PI Web site 250 across the Internet 230.
`This current model suffers from several signi?cant de?cien
`cies. The end user must login to each site separately. Each
`separate site has its oWn graphical user interface. Each site
`Wants the end user to stay and return; each visited site Wants
`to retain end user focus for as long as possible. No true
`aggregation of PI exists; multiple accesses simply alloW
`sequential access to particular pieces of PI.
`One partial solution to these problems has recently
`evolved in the form of portal sites. Generic portal sites
`aggregate resources into categories and provide links to sites
`covering topics Within those categories. Yahoo and Excite
`are examples of generic portal sites. These sites facilitate
`horiZontal aggregation of generic content; horiZontal aggre
`gation refers to aggregation of PI access Within a particular
`information provider category such as banks or utility com
`panies. Some portal site alloWs individual end users a
`limited capability to select and con?gure disparate generic
`PI. Generic PI refers to PI of interest to the particular end
`user that does not require speci?c identity veri?cation to
`obtain. For example, an end user might be interested in the
`Weather forecast for his local area. This information could be
`integrated into a portal page Without requiring identity
`veri?cation of the particular end user receiving this PI. The
`individualiZed portal page provides a signi?cant bene?t to
`users seeking to aggregate generic PI. HoWever, current
`portal pages do not generally provide PI requiring identity
`veri?cation such as an end user’s stock portfolio or bank
`balance. Further, these pages do not facilitate transactions
`utiliZing PI.
`Under current technology, aggregating PI available over
`the Internet requires a signi?cant burden in terms of time,
`effort and learning curve. An end user Wishing to access his
`PI needs to individually visit a variety of information
`
`Ex 1001-14
`
`

`
`US 6,317,783 B1
`
`3
`provider sites each With its oWn requirements, graphical user
`interface and login protocol.
`SUMMARY OF THE INVENTION
`In the present invention, a networked computer is used to
`facilitate end user access of, manipulation of and transac
`tions involving electronic PI associated With the particular
`end user such as stock portfolio, local Weather, sports scores,
`bank account balances or other pertinent information or data.
`According to the present invention, the PI relevant to the
`particular end user is aggregated on the netWorked com
`puter. This information or data is delivered to the end user
`in a uni?ed manner by a variety of selectable delivery
`platforms such as facsimile, client computer, telephone,
`conventional mail, electronic mail, pager, other Wireless
`device, Web page or channel or other delivery vehicle. The
`present invention further facilitates a variety of electronic
`transactions involving PI such as stock trading, retail
`purchases, bill payment, bank account fund transfers or
`other transactions.
`Asystem for delivering personal information according to
`the present invention includes a user store including end user
`data, a provider store including information provider data, a
`personal information store including personal information
`and a processor that communicates With these data stores.
`The processor supports the aggregation of personal infor
`mation. The processor selects an end user for personal
`information aggregation. Once the end user is selected, the
`processor connects With one or more information providers.
`The processor then proceeds to retrieve personal information
`for the selected end user from the connected information
`providers. This retrieval is based on end user data associated
`With the selected end user and provider data associated With
`the connected information providers. The retrieved personal
`information is stored in the personal information store.
`The above and other objects and advantages of the present
`invention Will become more readily apparent When reference
`is made to the folloWing description, taken in conjunction
`With the accompanying draWings.
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is a process diagram of the current process that end
`users perform to access Internet available PI.
`FIG. 2 is a block diagram of the components that could be
`used to implement present invention.
`FIG. 3 is a block diagram of the components of the PI
`engine.
`FIG. 4 is a diagram of the current PI access architecture.
`FIG. 5 is a diagram of an architecture supporting PI access
`utiliZing an intermediary Web site.
`FIG. 6 is a diagram of the cookie/client cache architec
`ture.
`FIG. 7 is a ?oWchart for accessing pages underlying
`particular PI via the traditional process of FIG. 1 and via
`springboard technology.
`FIG. 8 depicts the integration model for the dynamic
`generation of HTML pages.
`FIG. 9 displays the run-time process for dynamic genera
`tion of HTML page.
`FIG. 10 illustrates a process for automated applet inter
`action utiliZing a modi?ed Java virtual machine.
`FIG. 11 is a ?oWchart exemplifying an intermediary Web
`site transaction structure.
`
`15
`
`25
`
`35
`
`45
`
`55
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`Apreferred embodiment of the invention is noW described
`in detail. Referring to the draWings, like numbers indicate
`
`65
`
`4
`like parts throughout the vieWs. As used in the description
`herein and throughout the claims that folloW, the meaning of
`“a,” “an,” and “the” includes plural reference unless the
`conteXt clearly dictates otherWise. Also, as used in the
`description herein and throughout the claims that folloW, the
`meaning of “in” includes “in” and “on” unless the conteXt
`clearly dictates otherWise.
`In no time, end users Will have to log into a large number
`of different Web Sites, each With separate passWords,
`security, rules, softWare and “look and feel”—just to get the
`information currently obtained by checking one place—the
`mailboX at the end of the driveWay. The Internet Will
`fundamentally change the Way in Which end users Will
`access Personal Information (PI) and Will make e-commerce
`as familiar as using an ATM. “Personal Information” is all
`of the data that companies, information providers, have that
`is speci?c or unique to each person such as monthly bills,
`bank account balances, investments information, health care
`bene?ts, email, voice and faX messages, 401(k) holdings or
`potentially any other information pertinent to a particular
`end user.
`The present invention alleviates several of the problems
`With the current PI acquisition methods by automatically
`aggregating PI, not only generic PI as aggregated by portals
`but also PI speci?c to the end user requiring identity
`veri?cation for access. In one embodiment, the invention
`automates the PI acquisition and delivery process. FIG. 2
`provides a block diagram of components that could be used
`to implement the present invention. The end user 210
`accesses a client computer 220 running client softWare 270
`Which in a particular embodiment could be a general Web
`broWser such as Navigator or Communicator (Netscape).
`The client computer 220 utiliZes the Internet 230 to access
`a PI engine 240 running on a PI host 290. The PI engine 240
`eXamines stored PI 280 for freshness. Any stale PI items are
`refreshed by directly reacquiring the PI from the particular
`information provider’s Web site 250 running on the provid
`er’s computer system 260 accessed across the Internet 230.
`The PI engine 240 stores the fresh PI in its store 280 and
`delivers the PI to a selected destination, in this instance
`across the Internet 230 to the client computer 220 Which
`displays the information to the end user 210 using the client
`softWare 270. The PI engine 240 refreshes all stale PI in a
`like manner prior to forWarding the aggregated PI to both the
`store 280 and the delivery destination, the client computer
`220 in this instance. The PI engine 240 may refresh the PI
`sequentially or in parallel. For example, the end user’s
`checking account balance Would be updated through his
`bank’s Web site, his email from his particular email site, his
`portfolio information from his broker’s site and his electric
`ity bill from his electricity company’s site.
`FIG. 3 displays a block diagram of the components of the
`PI engine 240. The PI engine 240 is composed of both
`storage and processing components. The three primary stor
`age components are the PI store 280, the PI Provider store
`310 and the user store 360. The ?rst storage component of
`the PI engine 240 is the PI store 280. The PI store 280
`contains each individual’s PI record 375; the PI associated
`With a particular end user is segregated from the PI of all
`other end users. The PI engine also utiliZes a provider store
`310 that maintains general parameters associated With par
`ticular PI providers. The general parameters of a PI provider
`de?ne the types of veri?cation data necessary and the
`procedures to be folloWed to gain access to the particular PI
`provider. Each PI provider record also contains the types of
`PI provided by the PI provider and the types of transactions
`supported by the provider. Along With the type of PI or
`
`Ex 1001-15
`
`

`
`US 6,317,783 B1
`
`5
`transaction, the record also contains the additional types of
`data and procedures necessary to access the PI or execute the
`transaction. A user store 360 is also necessary to maintain
`con?guration and veri?cation information concerning par
`ticular end users. For each end user, the user selected PI
`providers, PI and transactions are registered along With the
`veri?cation data necessary to acquire the PI or execute the
`transaction from the PI provider.
`The PI store 280 may be implemented in a variety of
`Ways. Referring to FIG. 2, the PI store 280 may comprise a
`database residing on the PI Host 290. Under this approach,
`the PI for each individual end user 210 is stored as a separate
`record or object 375 in the database. In yet another
`embodiment, the PI for each end user 210 could be stored in
`a separate ?le 375, thus performing the task of segregating
`PI of different users at the ?le level.
`In addition, or as an alternative, the PI associated With
`each end user 210 may reside on his/her client computer 220
`using cookie technology as speci?ed in D. Kristol and L.
`Montulli, “HTTP State Management Mechanism”, Request
`For Comments (RFC) 2109, February, 1997 (available at
`http://WWW.ietf.org/rfc/rfc2109.txt), Which is expressly
`incorporated herein in its entirety. The PI associate With the
`end user 210 Would be stored as PI cookies 375. This
`implementation mechanism provides inherent support for
`segregating PI associated With one end user 375 from PI
`associated With all other end users. UtiliZing this method as
`a substitute for a centraliZed store provides a layer of
`security against unauthoriZed access. As a further measure,
`PI data stored in cookies could be stored in an encrypted
`format.
`FIG. 6 provides a diagram of a typical implementation of
`the PI store 280 using cookie technology; references in the
`foregoing description are also made to FIG. 3 With respect
`to the internal Workings of the PI engine 240. When an
`attempt is made to access PI by an end user 210 directly, or
`through an intermediary Web server, the PI access/transact
`component 340 of the PI engine 240 Would retrieve stored
`PI 375 from the PI store 280. Under this approach, this
`stored PI 375 Would be received directly from cookies sent
`by the client computer 220 of the end user 210. The PI
`access/transact component 340 Would perform any decryp
`tion if necessary. Any updates required Would be obtained by
`direct access of PI providers 250. The PI deliver component
`350 Would provide the mechanism for both updating the PI
`store 280 as Well as transmitting the requested PI to the end
`user 210, directly or through an intermediary Web site. The
`PI deliver component 350 Would place the updated PI in the
`PI store 280 by replacing the outdated PI cookies 375 stored
`on the client computer 220. The PI deliver component 350
`Would also handle any encryption if necessary. The PI
`deliver component 350 Would also be responsible for trans
`mitting requested PI. In a preferred embodiment, the PI store
`280 Would be implemented using this cookie-based archi
`tecture.
`The user store 360 may be implemented in a variety of
`Ways. Referring to FIG. 2, the user store 360 may comprise
`a database residing on the PI Host 290. Under this approach,
`the personal con?guration data for each individual end user
`210 is stored as a separate record or object in the database.
`In addition, or as an alternative, the end user data could be
`distributed in a manner similar to the cookie/cache archi
`tecture describe above With respect to the PI store 280.
`In a preferred embodiment, the user store 360 could be
`implemented through personal information con?guration
`(PIC) ?les. PIC ?les store a personal pro?le such as name,
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`6
`address, and social security number in secure, encrypted
`fashion for each end user. PIC ?les facilitate automatic
`registration of end users With information Providers via the
`end user con?guration component 330. This component Will
`read the PIC ?le and, using retrieved personal information,
`pre-populate registration templates for selected Providers.
`Then, it Will prompt the user to enter required information
`that is missing from pro?le, if necessary. If the information
`is complete, the registration is automatically completed.
`Next, the end user con?gure component 330 completes any
`Provider registration forms, gets responses and updates the
`end user’s PIC.
`The four primary processing components access and
`manipulate the data in the three stores. The processing
`components may execute on a single processor, such as a ?le
`server computer system based on a Pentium class (MMX,
`PRO, II, III, etc.) central processing unit or an equivalent, or
`multiple processors. These four processing components are
`the Baseline con?gure component 320, the end user con?g
`ure component 330, the PI access/transact component 340
`and the PI delivery component 350 as seen in FIG. 3. The
`Baseline con?gure component 320 provides the interface by
`Which neW user selectable PI providers are added to the
`system. This component 320 might be implemented in a
`variety of Ways including trial and error folloWed by manual
`entry of con?guration information, semi-automated trial and
`error (automated location of Hypertext Markup Language
`(HTML) <FORM> elements, Javascript functions and Java
`applets) folloWed by manual entry of con?guration infor
`mation or, preferably, con?guration by example (executing
`the protocol in a simulated Web client Where the simulated
`Web client automatically generates a list of required data and
`a list of steps in the access process). These processes Would
`be utiliZed at tWo levels: the ?rst level being the set of data
`and steps required for general access to the particular PI
`provider and the second level being the set of additional data
`and steps required for accessing each particular piece of PI
`on the PI provider’s site. The baseline con?guration com
`ponent 320 may be triggered independently When a neW PI
`provider is added to the system, or it might be triggered as
`a result of a failure of the PI access/transact component 340
`potentially indicating a change in access requirements for
`the failed access. This latter Warning Would more likely
`result Where the PI access/transact component 340 has made
`a comparison betWeen requirements supplied by the Pro
`vider store 310, both general to the PI provider and speci?c
`to the PI or transaction, and the end user data supplied by the
`user store 360 after seeking end user veri?cation via a
`request of the end user to con?rm the previously entered
`required access data via the end user con?gure component
`330 and found an inconsistency. When an inconsistency is
`determined, updates to the Provider store 320 are made to
`bring the Provider data into conformance With current
`access/transaction requirements.
`The end user con?gure component 330 alloWs an end user
`to select and con?gure PI and transactions of interest to the
`speci?c user. This con?guration information is maintained
`in the user store 360. When an end user initially subscribes
`to the system according to the present invention, the system
`alloWs the user to select the types and sources of PI and/or
`transactions desired. First, the system requests permission
`from the end user to act on his behalf to obtain any selected
`PI and to execute any authoriZed transactions. Next, the
`system provides the user With a list of knoWn information
`suppliers and the types of PI supplied from and transactions
`supported by the particular PI provider from the Provider
`store 320. The system requests the veri?cation data neces
`
`Ex 1001-16
`
`

`
`US 6,317,783 B1
`
`10
`
`15
`
`7
`sary for accessing each selected PI provider and the addi
`tional data required by the particular PIs and/or transactions
`desired from that PI provider. Assuming the end user is
`already a registered user With the selected PI provider or the
`particular PI provider does not require prior registration, the
`data supplied by the end user is placed in the user store 360.
`One method of obtaining any cookie data Would be for the
`end user to access each previously accessed PI utiliZing the
`PI engine 240 as a proxy server. The PI engine 240 Would
`pass the cookie data to the PI provider site With the appro
`priate Web page requests to obtain the PI or execute the
`transaction and With the end user’s permission retain a copy
`of the cookie data in the his record in the user store 360. An
`alternate means of obtaining the cookie data Would be a
`direct upload of the cookie information from the end user’s
`computer. In a preferred embodiment, no cookie data is
`necessary Where a user is already registered With a provider.
`All that is necessary is the veri?cation data for login.
`If the end user does not have the requisite information
`because he is not a registered user of a selected PI provider,
`the user con?gure component 330 prompts the user for the
`information necessary to register the end user With the PI
`provider and performs the registration procedure required by
`the PI provider. A simulated Web client could perform this
`process automatically supplying the access data as required
`and sending any necessary cookie data. The manner in
`Which such a simulated client registers the end user depends
`signi?cantly upon the interaction method used on the PI
`provider Web site. If the Web site uses HTML forms and
`common gateWay interface (CGI) applications, the end user
`con?gure comp