throbber
ATTORNEY DOCKET NO. 22022.0001
`
`PROVISIONAL APPLICATION FOR PATENT
`COVERSHEET
`
`This is a request for filing a PROVISIONAL APPLICATION FOR PATENT under 37 C.F.R.
`
`§ 1.53(c).
`
`Docket Number
`
`22022.0001
`
`Type a Plus Sign ( +)
`inside this box - - - -
`
`+
`
`INVENTOR(s)/APPLICANT(s)
`
`LAST NAME
`
`FIRST NAME
`
`MIDDLE
`INITIAL
`
`RESIDENCE (City and Either State or Foreign Country)
`
`Freishtat
`
`Gregg
`
`Dunwoody, Georgia
`
`.~.
`
`'l ..
`:,i:
`
`/ ..
`
`..
`
`:~
`~~
`
`~!?.
`
`;i(;:
`
`. , ..
`
`~~·
`:;:,
`
`~:r
`
`..
`
`'
`
`"'"
`~f
`
`TITLE OF INVENTION (280 characters max)
`
`"APPARATUS AND METHOD FOR AUTOMATED DELIVERY OF AND TRANSACTIONS INVOLVING
`ELECTRONIC PERSONAL INFORMATION OR DATA"
`
`CORRESPONDENCE ADDRESS
`
`Gregory J. Kirsch, Esq .
`NEEDLE & ROSENBERG, P.C.
`Suite 1200, The Candler Building
`127 Peachtree Street, N.E.
`Atlanta
`
`STATE
`
`Georgia
`
`ZIP CODE
`
`30303-1811
`
`COUNTRY
`
`U.S.A.
`
`[X]
`
`[X]
`
`.
`
`ENCLOSED APPLICATION PARTS (Check All That Apply)
`
`Specification
`
`Number of Pages
`
`[ 17 J
`
`Drawing(s)
`
`Number of Sheets
`
`[5]
`
`(]
`
`[]
`
`[]
`
`Small Entity Statement
`
`Power of Attorney
`
`Other (specify)
`
`H: \apps\ss\docs\gjk\ W005018. WPD
`
`Plaid Technologies, Inc.
`
`Petitioner's Ex. 1012
`Page 1
`
`

`
`ATTORNEY DOCKET NO. 22022.0001
`
`METHOD PAYMENT OF FILING FEES FOR THIS PROVISIONAL APPLICATION FOR PATENT (Check One)
`
`[X)
`
`A check or money order is enclosed to cover the filing fees.
`
`[)
`
`[]
`
`The Commissioner is hereby authorized to charge filing fees
`and credit Deposit Account Number:
`
`FILING FEE
`AMOUNT
`
`$150.00
`
`The Commissioner is hereby authorized to charge any
`additional fees which may be required in connection with the
`following or credit any overpayment to Deposit Account No.
`14-0629.
`
`The invention was made by an agency of the United States Government or under a contract with an agency of
`the United States Government.
`
`[X]
`
`No.
`
`[]
`
`Yes. The name of the U.S. Government agency and the Government contract number are:
`
`Respectfully submitted,
`
`TYPED or PRINTED NAME:
`~J~ffi
`t ~~;~
`~EDLE & ROSENBERG, P .C.
`Suite 1200, The Candler Building
`127 Peachtree Street, N.E.
`Atlanta, Georgia 30303-1811
`
`Gregory J. Kirsch
`
`Date
`
`10/28/98
`
`REGISTRATION NO. 35,572
`(I,/'.'4.]J]JrO]Jriate)
`
`CERTIFICATE OF EXPRESS MAILING
`
`EXPRESS MAIL NO. EL055857402US
`
`I hereby certify that this correspondence is being deposited with the United States Postal Service as Express Mail Invoice No.
`EL055857402US in an envelope addressed to: BOX PROVISIONAL APPLICATION, Assistant Commissioner for Patents, Washington,
`D.C. 20231, on this ;::lif day of ~ , 1998.
`
`Charles Hancock
`
`DATE
`
`H:\apps\ss\docs\gjk\W005018.WPD
`
`Petitioner's Ex. 1012
`Page 2
`
`

`
`APPARATUS AND METHOD FOR AUTOMATED AGGREGATION AND
`DELIVERY OF AND TRANSACTIONS INVOLVING
`ELECTRONIC PERSONAL INFORMATION OR DATA
`
`FIELD OF INVENTION
`
`The invention relates to an apparatus and process related to the automated
`
`aggregation and delivery of electronic personal information or data (PI). The invention
`
`further relates to the automation of transactions involving electronic PI.
`
`5
`
`10
`
`SUMMARY OF THE INVENTION
`
`Under current technology, aggregating PI available over the Internet requires a
`
`significant burden in terms of time, effort and learning curve. An end user wishing to
`
`15
`
`access his PI needs to individually visit a variety of information provider sites each with
`
`its own requirements, graphical user interface and login protocol. In the present
`
`invention, a networked computer is used to facilitate end user access of, manipulation of
`
`and transactions involving electronic PI associated with the particular end user such as
`
`stock portfolio, local weather, sports scores, bank account balances or other pertinent
`
`20
`
`information or data. According to the present invention, the PI relevant to the particular
`
`end user is aggregated on the networked computer. This information or data is delivered
`
`to the end user in a unified manner by a variety of selectable delivery platforms such as
`
`facsimile, client computer, telephone, Web channel or other delivery vehicle. The
`
`present invention further facilitates a variety of electronic transactions involving PI such
`
`H:\apps\ss\docs\gik\W004975.DOC
`
`Petitioner's Ex. 1012
`Page 3
`
`

`
`as stock trading, retail purchases, bill payment, bank account fund transfers or other
`
`transactions.
`
`5
`
`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.
`
`10
`
`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.
`
`15
`
`DETAILED DESCRIPTION OF THE INVENTION
`
`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
`
`20
`
`driveway. The Internet will fundamentally change the way in which end users will
`
`access Personal Information (Pl) 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 specific or unique to each person such as monthly bills, bank account
`
`H:\apps\ss\docs\gjk\W004975.DOC
`
`2
`
`Petitioner's Ex. 1012
`Page 4
`
`

`
`balances, investments information, health care benefits, email, voice and fax messages,
`
`401(k) holdings or potentially any other information pertinent to a particular end user.
`
`FIG. I displays the current process of acquiring online PI I 00. The end user first
`
`5
`
`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 first time might involve significant time and
`
`10
`
`effort performing online searches. In step 130, the end users logs into the selected
`
`information provider's Web site utilizing the site's specific logon protocol. This protocol
`
`usually involves verifying the identity of the end user using a user name and password or
`
`other means of verification, acquiring the verification data from cookies residing on the
`
`end user's system or a combination of requested data and cookie data. The end user
`
`15
`
`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 a 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 I 00 is repeated for each
`
`20
`
`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
`
`verification data for each, utilize a different user interface at each site and possibly wade
`
`through a significant number of filler Web page.
`
`H:\apps\ss\docs\gjk\ W00497 5 .DOC
`
`3
`
`Petitioner's Ex. 1012
`Page 5
`
`

`
`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 significant deficiencies. The end
`
`5
`
`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.
`
`10
`
`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
`
`aggregation refers to aggregation of PI access within a particular information provider
`
`15
`
`category such as banks or utility companies. Some portal site allows individual end users
`
`a limited capability to select and configure disparate generic PI. Generic PI refers to PI
`
`of interest to the particular end user that does not require specific identity verification 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
`
`20
`
`verification of the particular end user receiving this PI. The individualized portal page
`
`provides a significant benefit to users seeking to aggregate generic PI. However, current
`
`portal pages do not generally provide PI requiring identity verification such as an end
`
`H:\apps\ss\docs\gjk\ W00497 5.DOC
`
`4
`
`Petitioner's Ex. 1012
`Page 6
`
`

`
`user's stock portfolio or bank balance. Further, these pages do not facilitate transactions
`
`utilizing PI.
`
`The present invention alleviates several of the problems with the current PI
`
`5
`
`acquisition methods by automatically aggregating PI, not only generic PI as aggregated
`
`by portal but also PI specific to the end user requiring identity verification 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
`
`10 which in a particular embodiment could be a general Web browser such as 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 locally 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 provider's computer system 260 accessed across
`
`15
`
`the Internet 230. The PI engine 240 stores the fresh PI in its local 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 local store 280 and the delivery destination, the
`
`20
`
`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 the his particular email site, his portfolio
`
`H:\apps\ss\docs\gjk\ W00497 5.DOC
`
`5
`
`Petitioner's Ex. 1012
`Page 7
`
`

`
`information from his broker's site and his electricity bill from his electricity company's
`
`site.
`
`FIG. 3 displays a block diagram of the components of the PI engine 240. The PI
`
`5
`
`engine 240 is composed of both storage and processing components. The three primary
`
`storage components are the PI store 280, the PI Provider store 310 and the user store 360.
`
`The first storage component of the PI engine 240 is the PI store 280. The PI store 280
`
`contains PI records for each individual end user; the PI associated with a particular end
`
`user is segregated from the PI of all other end users. The PI engine also utilizes a
`
`1 o provider store 310 that maintains general parameters associated with particular PI
`
`providers. The general parameters of a PI provider define the types of verification 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 transaction,
`
`15
`
`the record also contains the additional types of data and procedures necessary to access
`
`the PI or execute the transaction. An end user store 360 is also necessary to maintain
`
`configuration and verification information concerning particular end users. For each end
`
`user, the user selected PI providers, Pis and transactions are registered along with the
`
`verification data necessary to acquire the PI or execute the transaction from the PI
`
`20
`
`provider including any requisite cookie data.
`
`The four primary processing components access and manipulate the data in the
`
`three stores. These four processing components are the Baseline configure component
`
`H: \apps\ss\docs\gjk\ W00497 5 .DOC
`
`6
`
`Petitioner's Ex. 1012
`Page 8
`
`

`
`320, the end user configure component 330, the PI access/transact component 340 and
`
`the PI delivery component 350. The Baseline configure 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
`
`5
`
`followed by manual entry of configuration 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 configuration
`
`information or, preferably, configuration by example (executing the protocol in a
`
`simulated Web client where the simulated Web client automatically generates a list of
`
`10
`
`required data and a list of steps in the access process). These processes would be utilized
`
`at two levels: the first 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
`
`configuration component 320 may be triggered independently when a new PI provider is
`
`15
`
`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 Provider store 310, both general to the PI provider and specific to the PI or
`
`20
`
`transaction, and the end user data supplied by the user store 360 after seeking end user
`
`verification via a request of the end user to confirm the previously entered required
`
`access data via the end user configure component 330 and found an inconsistency.
`
`H:\apps\ss\docs\gjk\ W00497 5 .DOC
`
`7
`
`Petitioner's Ex. 1012
`Page 9
`
`

`
`The end user configure component 330 serves allows an end user to select and
`
`configure PI and transactions of interest to the specific user. This configuration
`
`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
`
`5
`
`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 verification
`
`10
`
`data necessary for accessing each selected PI provider and the additional 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 Pl 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 along with any cookie data necessary for access. One method of obtaining the
`
`15
`
`necessary 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 appropriate 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
`
`20 would be a direct upload of the cookie information from the end user's computer.
`
`If the end user does not have the requisite information because he is not a
`
`registered user of a selected PI provider, the user configure component 330 prompts the
`
`H:\apps\ss\docs\gik\W004975.DOC
`
`8
`
`Petitioner's Ex. 1012
`Page 10
`
`

`
`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
`
`5
`
`registers the end user depends significantly 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 configure component 330 can formulate a uniform
`
`resource locator (URL) to replicate the effect of actual form usage and submit this URL
`
`to the simulated Web client. The use of a URL to mimic an HTML form is equivalent to
`
`10 manually entering the data into the Web <FORM> element. See Kerven, Foust, Zakour,
`
`HTML 3.2 Plus How-To, Waite Group Press, 1997, pp. 559-569. If the Web site uses a
`
`mixture of HTML forms and Javascript functions, a simulated Web client with a
`
`modified Javascript interpreter could effectively register the user by following the end
`
`user registration process for the particular PI provider. The registration process to follow
`
`15 would be obtained from the record of the particular PI provider in the Provider store 320.
`
`The Javascript interpreter in the simulated Web client would follow this procedure and
`
`supply the data supplied by the end user. A similar process could be used if the
`
`registration process on the PI provider Web site utilizes a Java applet. A Web client with
`
`a modified Java bytecode interpreter could effectively register the user by following the
`
`20
`
`end user registration process stored for the particular PI provider in the Provider store
`
`320. The bytecode interpreter would supply the data previously entered by the user
`
`rather than requiring interactive input from the end user. If the PI provider Web site
`
`H:\apps\ss\docs\gjk\W004975.DOC
`
`9
`
`Petitioner's Ex. 1012
`Page 11
`
`

`
`utilizes a combination of forms, scripts and applets, the individual procedures above
`
`could be used in combination to accomplish the desired registration.
`
`A successful registration could result in displaying the registration information to
`
`5
`
`the end user for future reference. Further, the end user configure component 330 stores
`
`the requisite access verification data for the PI provider and the additional data required
`
`to access the selected PI or transaction in the user store 360. This would include storage
`
`of any cookie data appropriately in the user store 360.
`
`10
`
`A failed registration could result from several situations. First, the end user
`
`attempting to register with the PI provider does not qualify for registration; for example,
`
`an end user attempting to register with a bank with whom the end user does not maintain
`
`account and where the bank only allows access to account holders. Next, the end user
`
`may have supplied improper or incorrect information. For example, a bank registration
`
`15
`
`process might require a social security number, a password, a bank account number and
`
`the maiden name of the end user's mother; if the user entered an incorrect social security
`
`number, the registration process would fail. Finally, the PI provider may have altered the
`
`registration procedure for its Web site. In this situation, following the process supplied
`
`from the Provider store 320 would yield a failed registration. In the instance of any
`
`20
`
`registration failure, the end user could be presented with the data initially supplied to the
`
`system for registration. The system could then ask the end user to double check the
`
`correctness of the information provided and to correct and resubmit the data if an error is
`
`found. A second failure resulting from the submission of identical requisite data might
`
`H:\apps\ss\docs\gjk\W004975.DOC
`
`10
`
`Petitioner's Ex. 1012
`Page 12
`
`

`
`generate an error message presented to the end user stating that either the end user is
`
`ineligible to access the selected PI from the selected PI provider or that alteration by the
`
`PI provider may have caused an error in registration. This second failure could also
`
`trigger a warning suggesting the need to potentially reconfigure the record for the PI
`
`5
`
`provider in the Provider store 320.
`
`Ultimately, the user store 360 would contain a record for each end user. Each
`
`record would identify the selected PI providers along with the general access verification
`
`data needed and also under each PI provider would be a list of PI supplied and
`
`10
`
`transactions supported by the particular PI provider of interest to the end user along with
`
`the additional data, if any, necessary to access that PI or execute that transaction. Both
`
`the general verification data and the additional data would include any cookie data
`
`necessary for access.
`
`15
`
`The end user configure component 330 also allows the end user to select one or
`
`more delivery destinations. One destination might be the end user's computer as
`
`exemplified by the client computer 220 running client software 270 in FIG. 2; however, a
`
`computer is not the only destination contemplated by the present invention. The
`
`destination for PI delivery could include facsimile, email, telephone, conventional mail,
`
`20
`
`or other delivery mechanism. The present invention also contemplates indirect access of
`
`PI by the end user utilizing a Web site as an intermediary; however, such indirect access
`
`would not require the end user to specify a delivery destination unless additional delivery
`
`options were desired.
`
`H:\apps\ss\docs\gjk\W004975.DOC
`
`11
`
`Petitioner's Ex. 1012
`Page 13
`
`

`
`Further, access to the end user configure component 330 may occur through direct
`
`access to the PI engine via the Internet as contemplated by the client computer 220
`
`running client software 270 in FIG. 2; however, alternative methods of access are equally
`
`5
`
`feasible. For example, the user might indirectly access the PI engine through the use of
`
`an intermediary Web site. A telephone interface to allow access to the end user configure
`
`component is another alternative.
`
`With reference to FIG. 3, the PI access/transact component 340 supports the
`
`10
`
`update, acquisition and transaction functionality of the PI engine 240. The PI
`
`access/transact component is responsible for accessing and storing user PI and executing
`
`transactions authorized by the end user. When access or update is needed, the Pl
`
`access/transact component 340 combines information from the Provider store 320 and the
`
`user store 360 to update end user PI in the PI store 280. For each piece of PI requiring
`
`15
`
`access or update, the PI access/transact component 340 looks up the access procedure and
`
`information needed for the particular PI in the Provider store 320. The verification and
`
`access data, including cookie data needed for access, is found in the user store 360. The
`
`PI access/transact component 340 utilizes this information to access the PI across the
`
`Internet from the PI provider's Web site. Where multiple pieces of PI require updating or
`
`20
`
`access, the accesses may occur in series or parallel.
`
`Requested transactions would be similarly supported. For each transaction, the PI
`
`access/transact component 340 combines information from the Provider store 320 and the
`
`H:\apps\ss\docs\gjk\ W00497 5 .DOC
`
`12
`
`Petitioner's Ex. 1012
`Page 14
`
`

`
`user store 360 to perform the requested transaction. The PI access/transact component
`
`340 looks up the transaction procedure and information needed for the particular
`
`transaction in the Provider store 320. The verification and access data, including cookie
`
`data needed, is found in the user store 360. The PI access/transact component 340
`
`5
`
`utilizes this information to perform the transaction across the Internet from the PI
`
`provider's Web site
`
`A simulated Web client could perform access or transaction processes
`
`automatically supplying access and verification data and cookie data as necessary. The
`
`10 manner in which such a simulated client access PI or execute transactions depends
`
`significantly 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 PI
`
`access/transact component 340 can formulate a uniform resource locator (URL) to
`
`replicate the effect of actual form usage and submit this URL to the simulated Web client.
`
`15
`
`The use of a URL to mimic an HTML form is equivalent to manually entering the data
`
`into the Web <FORM> element. See Kerven, Foust, Zakour, HTML 3.2 Plus How-To,
`
`Waite Group Press, 1997, pp. 559-569. If the Web site uses a mixture of HTML forms
`
`and Javascript functions, a simulated Web client with a modified Javascript interpreter
`
`could effectively access the PI or perform the transaction by following the PI
`
`20
`
`access/transact process for the particular PI or transaction respectively. The access or
`
`transaction process to follow would be obtained from the record of the particular PI or
`
`transaction in the Provider store 320. The Javascript interpreter in the simulated Web
`
`client would follow this procedure and supply the data found in the user store 360. A
`
`H: \apps\ss\docs\gjk\ W00497 5 .DOC
`
`13
`
`Petitioner's Ex. 1012
`Page 15
`
`

`
`similar process could be used if the PI provider Web site utilizes a Java applet. A Web
`
`client with a modified Java bytecode interpreter could effectively access PI or perform
`
`transactions by following process stored for the particular PI or transaction in the
`
`Provider store 320. The bytecode interpreter would supply the data from the user store
`
`5
`
`360 rather than requiring interactive input from the end user. If the PI provider Web site
`
`utilizes a combination of forms, scripts and applets, the individual procedures above
`
`could be used in combination to accomplish the desired access.
`
`The PI deliver component 350 is responsible for formatting and delivering the PI
`
`10
`
`to the end user. Usually delivery will only occur subsequent to updating all PI. The PI
`
`will be delivered to one or more destinations as specified in the user store 360 except
`
`where the PI is accessed via an intermediary Web site. Where the destination is not an
`
`intermediary Web site, the PI deliver component 350 performs all fonnatting necessary to
`
`deliver the PI to the appropriate destinations. For example, where the destination is a
`
`15 Web browser, the PI would be formatted as an HTML document, or where the destination
`
`is a telephone, the PI would be submitted for voice synthesis and transmission.
`
`In the case of an intermediary Web site, the PI is delivered in a format
`
`configurable by the intermediary Web site. FIG. 5 pictorial illustrates a possible
`
`20
`
`embodiment of the current invention utilizing an intermediary Web site. An end user 210
`
`accesses utilizes a client computer 220 to access an intermediary Web site 510 across the
`
`Internet 230. The end user 210 logs into the intermediary Web site 510. The
`
`intermediary Web site 510 contacts the PI engine 240 across the Internet 230 and directly
`
`H: \apps\ss\docs\gjk\ W00497 5 .DOC
`
`14
`
`Petitioner's Ex. 1012
`Page 16
`
`

`
`receives the end user's PI updated as required from the PI provider Web sites 250. The
`
`intermediary Web site 510 receives the PI, incorporates it into pages according to its
`
`particular formatting style and graphical user interface and delivers these pages to the end
`
`user 210. The use of the PI engine 240 is transparent to the end user 210. Further, an
`
`5
`
`intermediary Web site 510 serving aggregate PI to an end user 210 may, and most likely
`
`will, simultaneously serve as a PI provider.
`
`One method of performing this task would be to format PI as HTML elements
`
`with predefined CLASS attributes. The intermediary Web site receiving these elements
`
`1 o
`
`could dynamically include them in page forwarded to the end user of the PL The pages
`
`incorporating such elements could include different style information associated with the
`
`predefined CLASS set. Level 1 cascading style sheet convention could be used to
`
`implement such configurability. See Kerven, Foust, Zakour, HTML 3.2 Plus How-To,
`
`•:
`
`Waite Group Press, 1997, pp. 651-693; Walsh, "An Introduction to Cascading Style
`
`15
`
`Sheets," World Wide Web Journal, Winter 1997, pp. 147-156. This option requires
`
`minimal programmatic support by the intermediary Web site but restricts to some degree
`
`the intermediary Web sites flexibility in presenting the PI to the end user.
`
`Alternatively, an intermediary Web site could develop an application utilizing a
`
`20
`
`standardized application programming interface (API) to directly access the PI data. In
`
`this instance, the PI deliver component 350 could either be bypassed or potentially used
`
`as the component responsible for servicing API requests for data. Under this model, the
`
`intermediary Web site would be responsible for all formatting decisions with respect to
`
`H:\apps\ss\docs\gjk\ W00497 5 .DOC
`
`15
`
`Petitioner's Ex. 1012
`Page 17
`
`

`
`the raw PI data. This implementation option requires additional programmatic support by
`
`the intermediary Web site but allows for greater flexibility in the use of the raw PL
`
`The ability to utilize an intermediate Web site to deliver PI is of significant utility.
`
`5
`
`This capability allows an end user already familiar with an existing PI provider to access
`
`not only the PI associated with the particular PI provider but also all PI from other PI
`
`providers in the comfort of a familiar user interface, namely the existing PI provider Web
`
`site. In this situation, the request for PI would directly originate with the intermediary PI
`
`provider Web site and indirectly from the end user. Security measures would restrict
`
`10
`
`access to authorized intermediate Web site access. These measure might include
`
`verification of the end user and the intermediate Web site. Further, verification of the
`
`association between the end user and the particular intermediate Web site might also be
`
`required for additional security.
`
`15
`
`The PI engine 240 of FIG. 3 may also include a site monitor 370 processing
`
`component. This component would systematically monitor supported PI provider Web
`
`sites for changes. This component enhances the ability of the system to identify
`
`alterations in PI provider Web site procedures, data requirements and cookies
`
`requirements. This component increases system efficiency by supplementing or
`
`20
`
`supplanting alteration identification via feedback from the PI access/transact component
`
`340.
`
`H: \apps\ss\docs\gjk\ W00497 5.DOC
`
`16
`
`Petitioner's Ex. 1012
`Page 18
`
`

`
`A further embodiment of the present invention might support the localize
`
`manipulation of PI. This could be accomplished where the client software 270 running
`
`on the client computer 220 in FIG. 2 is a specialized Web client rather than a general
`
`Web client such as Netscape. This specialized client might utilize Web channel
`
`5
`
`technology to automate the local PI download and update processes.
`
`In another embodiment, the PI engine 240 of FIG. 3 might support both system
`
`supported PI providers as well as PI providers specific to particular end users. In this
`
`embodiment, an end user is not limited to PI available from PI providers presen

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket