用于自動訪問個人信息的系統與方法

專利名稱：用于自動訪問個人信息的系統與方法
本申請是CN99801737.X的分案申請，原案申請日為1999年10月27日，其發明名稱為“用于自動聚集和投遞電子個人信息或數據以及涉及電子個人信息或數據的事務處理的裝置與方法”。
本申請依照35U.S.C.§119(e)，要求申請人的臨時美國專利申請系列號60/105,917(提交日1998年10月28日，名稱用于自動聚集和投遞電子個人信息或數據以及涉及電子個人信息或數據的事務處理的裝置與方法)和申請人的臨時美國專利申請系列號60/134,395(提交日1999年5月17日，名稱用于自動聚集和投遞電子個人信息或數據以及涉及電子個人信息或數據的事務處理的裝置與方法)的權益。
本發明涉及一種自動聚集和投遞電子個人信息或數據(PI)的裝置與過程。本發明進一步涉及對涉及電子PI的事務處理的自動化。
回顧過去的五年，顯然，隨著因特網的迅猛發展，消費者需要能使他們的在線體驗更加簡單、易用和令人滿意的應用和服務。成功的因特網站點的發展適應了在過去若干年中發展起來的許多主題。仔細分析的結論是，這種演變是正在出現的數字經濟的合乎邏輯的發展。
1994年之前，因特網并不是一種大眾媒體，部分原因是當時業已存在的技術(FTP、Archie、Usenet和Gopher)并不是用戶友好的，要求最終用戶做所有工作(例如，最終用戶要了解現有數據源，尋找地址，漫游到目的地，然后下載信息)。隨著越來越多的消費者開始訪問因特網，人們開發了搜索引擎來解決這種合用性問題。由于商業搜索引擎的出現，可以容易地將更多的內容添加到因特網，最終用戶也獲得一種尋找和訪問這種信息的工具。消費者們要求有比搜索引擎更好的工具來組織和訪問這種通用內容資源。人們探索過PUSH技術，最后，成功地采用了門戶策略，作為一種消費者用來容易地訪問格式單一、易用的各種內容資源的有效方法。隨著可用在線內容的數量指數級地持續增長，門戶現在面臨著根據消費者的特定偏好和趣味向不同的消費者提供不同類型的內容的需要。
因特網門戶(portal)和目的地站點的非凡成功，體現了創造性地、智能地對網上可用的海量信息進行聚集、組織和表示的重要性。搜索引擎、門戶和目的地站點有基于最終用戶對它們站點訪問的頻率、持續時間和品位的因特網策略。由于這個原因，目的地站點和門戶不斷地尋求能驅使優質業務量來到它們站點并作停留的內容和/或技術。近來的趨勢表明，如果按照個人偏好來組織信息，則因特網用戶回訪站點的可能性會增長25倍。


圖1顯示當前的獲取PI 100的過程。在步驟110，最終用戶首先選擇一個信息提供者站點。最終用戶繼續到步驟120，找出并輸入選定的信息提供者的因特網地址。這個步驟可以用若干種復雜程度不同的方式來完成。完成這個步驟的一個簡單方法是使用書簽或愛好，盡管第一次找出信息提供者時會費很多時間和努力來進行在線檢索。在步驟130，最終用戶用選定的信息提供者的網站的專用登錄協議在該網站登錄。這個協議一般要用用戶名和口令或其它驗證手段來驗證最終用戶的身份，從最終用戶的系統上駐留的cookies(餅干)獲取驗證數據或者所請求數據與cookie數據的組合。最終用戶繼續在步驟140在信息提供者網站上的網頁中漫游，直到找出所希望的信息。在這個過程期間，經常會要求最終用戶訪問其目的只是獲取網站上駐留的特定PI而對最終用戶來說用處不大或毫無用處的網頁。最后在步驟150，向最終用戶提交所希望PI。對最終用戶所希望的各條PI，重復整個過程100。按照這個PI訪問模型，最終用戶必須訪問各獨立的信息提供者，為每個信息提供者留下可能不同的身份驗證數據，使用各站點的不同用戶界面，還可能在數量可觀的填充網頁間奔忙。
圖4用圖形表示了當前這種訪問過程的體系結構。最終用戶210用客戶計算機220在因特網上訪問各PI網站250。當前這種模型有一些重大缺陷。最終用戶必須單獨登錄到各站點。各獨立站點有其自己的圖形用戶界面。各站點都希望最終用戶停留和再來訪問；各被訪問站點都希望盡可能長時間地保持用戶的注意。不存在真正的PI的聚集；多處訪問只是能夠順序訪問PI的各特定部分。
近來研究出了一種對這些問題的部分解決方案，其形式是門戶站點。通用門戶站點將聚集的資源分成門類，并提供向涉及這些門類包含的主題的站點的鏈接。Yahoo和Excite就是這種通用門戶站點的例子。這些站點方便了通用內容的橫向聚集(horizontalaggregation)-橫向聚集指的是對在特定信息提供者類別(諸如銀行或公用事業公司)內PI訪問的聚集。有的門戶站點有限制地讓個別最終用戶能選擇和配置種類不同的通用PI(generic PI)。通用PI指的是對特定最終用戶有價值的、不要求特定的身份驗證就能獲得的PI。例如，某最終用戶可能對其本地區的天氣預報有興趣。可以將這種信息綜合到一個門戶頁中，而無需對接收這個PI的特定最終用戶的身份驗證。這種個人化的門戶頁向尋求聚集通用PI的用戶提供了極大的好處。然而，當前的門戶頁一般不提供要求身份驗證的PI，諸如用戶的證券財產目錄或銀行帳戶余額。此外，這些頁不能簡化采用PI的事務處理。
在當前技術條件下，在因特網上聚集可用的PI，對時間、精力和學習曲線(learning curve)方面等方面的要求負擔很重。希望訪問其PI的最終用戶需要個別地訪問許多各有自己的要求、圖形用戶界面和登錄協議的信息提供者站點。
在本發明中，用一個連網的計算機來方便最終用戶對涉及與該特定最終用戶關聯的電子PI(諸如證券財產目錄、本地天氣、體育比賽比分、銀行帳戶余額或其它相關信息或數據)的訪問、操作及涉及該PI的事務處理。按照本發明，在連網的計算機上聚集與特定最終用戶相關的PI。由各種可選擇的傳遞平臺，諸如傳真、客戶計算機、電話、常規郵件、電子郵件、尋呼機、其它無線設備、網頁或頻道或其它傳遞載體，將這種信息或數據以統一的方式傳遞到最終用戶。本發明還能促進各種涉及PI的電子事務諸如證券交易、零售買賣、帳單支付、銀行帳戶資金轉移或其它事務。
按照本發明的一個傳遞個人信息的系統包括一個包含最終用戶數據的用戶儲存庫、一個包含信息提供者數據的提供者儲存庫、一個包含個人信息的個人信息儲存庫和一個與這些數據儲存庫通信的處理器。處理器支持個人信息的聚集。處理選擇一個最終用戶來進行個人信息聚集。一旦選定了最終用戶，處理器就連接一個或多個信息提供者。處理器然后開始從所連接的信息提供者為選定的最終用戶檢索個人信息。這種檢索根據的是與選定最終用戶關聯的最終用戶數據和與所連接信息提供者關聯的提供者數據。檢索出的數據被存入個人信息儲存庫。
在本發明的一個方面，用網絡計算機-或者叫宿主計算機-來發布、存儲和檢索與特定最終用戶關聯的電子信息。在特定實施例中，信息是諸如證券財產目錄、本地天氣、體育比賽比分、銀行帳戶余額或其它相關信息或數據的個人信息。按照這個方面，在宿主計算機上聚集與特定最終用戶相關的PI。宿主計算機將所聚集的數據傳輸到與為其而聚集數據的特定最終用戶相關聯的客戶計算機。最好將所聚集的數據以cookie數據的形式傳輸到客戶計算機并以cookie數據的形式由客戶計算機存儲。在有些實施例中，在傳輸之前將所聚集的數據加密。宿主計算機接收關于聚集數據的請求。請求的源最好是客戶計算機，然而在本發明范圍內也可以考慮是其它合適的設備源。宿主計算機從客戶計算機接收-最好是cookie數據形式的-聚集數據。如果所聚集數據是加密的，就解密。宿主計算機繼續服務該請求以生成請求結果。可以將請求結果傳遞到各種平臺，最好是網頁。另一方面，也可以將結果傳遞到電話、電子郵件目的地、傳真、或其它打印設備，直接傳遞到Web瀏覽器、第三者計算機、無線設備或其它合適的傳遞平臺。
在這個方面的另一個實施例中，在客戶計算機上可存在專用軟件，用它來在客戶計算機上服務關于由宿主計算機傳送的聚集數據的請求。這種專用軟件要包含適當的解密軟件。
在本發明的另一個方面，將可能來自不同的源的電子信息與從可能不同的源確定的式樣首選(style preferences)動態地組合起來，生成一致的電子文檔。在這個方面的一個實施例中，將與特定最終用戶相關聯的電子PI(諸如證券財產目錄、本地天氣、體育比賽比分、銀行帳戶余額或其它相關信息或數據)與分銷商或提供者內容組合，產生所生成文檔的內容。式樣信息是從最終用戶的首選項和發布者及提供者的式樣信息收集的。通過對組合的內容應用組合的式樣信息，生成適應性一致的(adaptably compliant)電子文檔。可以由各種可選擇的傳遞平臺，諸如傳真、客戶計算機、無線設備、個人組織器(organizer)、電話、尋呼機、網頁或頻道或其它傳遞載體，以統一的方式將生成的這種文檔傳遞給最終用戶。
按照本發明這個方面的一種用于生成適應地一致的電子文檔的系統包含式樣合并器單元(style merger unit)、內容合并器單元(content merger unit)和處理器，它們可以被包含在本發明的網絡計算機中。式樣合并器單元從一個或多個式樣提供者收集式樣信息并動態地合并所收集的式樣信息。內容合并器單元從一個或多個內容提供者收集內容信息并動態地合并所收集的內容信息。處理器接收合并的式樣和內容信息，并通過將所接收的式樣信息應用到所接收的內容信息來生成適應地一致的電子文檔。所生成的頁可以輸出到各種傳遞平臺。
在另一個方面，用宿主計算機調度從一個或多個信息提供者對與一個或多個最終用戶的信息的收獲。宿主計算機與一個存儲用戶的關聯數據的用戶數據儲存庫和一個存儲信息提供者的關聯數據的提供者儲存庫通信，并且包含一個處理器。
對于每個最終用戶，在用戶數據儲存庫中保存一個過去訪問時間、登錄時間的輪廓(profile)。對于每個信息提供者，在信息提供者儲存庫中保存一個以更新時間和標準為內容的輪廓。更新時間和標準可以按每個信息提供者所提供的所有信息來存儲，或者，更新時間和標準可以按每個信息提供者所提供的每條信息來存儲。
對于選定的信息提供者，宿主計算機處理器確定該選定信息提供者所存儲信息的更新時間和可以在更新時間由更新而修改其信息的最終用戶集合。宿主計算機處理器生成所確定最終用戶集合中每個最終用戶的預測登錄時間，及生成的每個登錄時間倒退預定的時間間隔。宿主計算機處理器按預測登錄時間或變動的登錄時間將所確定的最終用戶集合分類，根據每個最終用戶的變動的或預測的登錄時間為每個最終用戶分配一個收獲時間。在這個方面的一個實施例中，宿主計算機處理器進一步可以在分配給各最終用戶的收獲時間從選定信息提供者為所確定集合中每個最終用戶收獲信息。
在這個方面的另一個實施例中，宿主計算機處理器確定可以在所確定更新時間由更新修改其信息的最終用戶集合的方法是，首先選擇被配置成從所選定的信息提供者接收信息的最終用戶，剔除那些不是配置成從所選定的信息提供者接收在所確定的更新時間受更新的信息的最終用戶。宿主計算機處理器可以進一步從該集合中剔除不符合與信息提供者關聯的更新或在確定的更新時間受更新的信息的更新標準或條件的最終用戶。
宿主計算機處理器可以根據用戶儲存庫中存儲的登錄時間輪廓，為所確定集合中每個最終用戶生成一個預測登錄時間。對于所確定集合中每個最終用戶，判斷最終用戶的登錄時間輪廓是否符合預定信用閥值。如果輪廓符合這個閥值，就根據輪廓分配一個預測登錄時間。如果輪廓不符合這個閥值，就分配一個相當于當日當時的預測登錄時間。
宿主計算機處理器根據每個最終用戶的預測登錄時間為每個最終用戶分配一個收獲時間。在這個方面的一個實施例中，每個最終用戶所分配的收獲時間相當于其生成的預測登錄時間倒退預定時間間隔。
在這個方面的另一個實施例中，宿主計算機處理器為每個最終用戶分配收獲時間所根據的不僅是其預測登錄時間，還要根據預期的網絡活動。宿主計算機處理器首先執行一個時間上的分布擬合(distribution fit across time)，以生成一個能確定在特定時間段內須收獲的最終用戶的數目的多項式函數。下一步，宿主計算機處理器確定與其及選定信息提供者關聯的網絡活動的網絡活動曲線。生成所確定的網絡活動曲線的逆。然后，它用所生成的多項式函數和網絡活動曲線的逆執行一個整體匹配算法。最后，它為每個最終用戶分配收獲時間，將高峰收獲時間重新朝時間零分布，以整平時間上的分布擬合(distribution fit across time)。
在本發明的另一個方面，涉及與最終用戶關聯的個人信息(PI)的電子操作是自動為最終用戶執行的。最終用戶將具有各種與其關聯的電子PI，諸如證券財產目錄、本地天氣、體育比賽比分、銀行帳戶余額或其它相關信息或數據。在這個方面的一個實施例中，最終用戶儲存庫含有與最終用戶關聯的最終用戶數據和與最終用戶的應答相關的觸發事件的記錄。宿主計算機處理器訪問與最終用戶關聯的記錄。對于每個被訪問記錄，宿主計算機判斷記錄中的觸發事件是否發生，如果已經發生，就執行與確定發生的觸發事件關聯的應答。
應答的執行可能涉及將觸發事件發生的通知傳遞給特定傳遞平臺，諸如無線設備、傳真、電話、打印設備、尋呼機、Web服務器上駐留的網頁、電子郵件系統或其它合適的傳遞載體。宿主計算機可以不傳遞這種通知就-或者除傳遞這種通知外還-自動執行一個涉及與最終用戶相關聯的個人信息的事務處理。
在這個方面的另一個實施例中，自動執行這種事務處理，包含宿主計算機根據在確定觸發事件發生所在的被訪問最終用戶記錄中指示的應答，訪問某信息提供者的關聯記錄。宿主計算機與由被訪問的與該信息提供者關聯的數據指示的某個信息提供者計算機連接。宿主計算機然后根據被訪問的與該信息提供者關聯的數據、在確定觸發事件發生所在的被訪問最終用戶記錄中指示的應答、及最終用戶儲存庫中的最終用戶數據，在所連接的信息提供者計算機上執行一個事務處理腳本。
在本發明的另一個方面，宿主計算機監控最終用戶與個人信息提供者之間通過中介計算機的交互作用。交互作用一般不外乎有兩個類別請求傳遞個人信息和請求涉及個人信息的事務處理。宿主計算機與存儲最終用戶的關聯個人信息的個人信息儲存庫以及存儲中介計算機的關聯記帳數據(accounting data)的記帳儲存庫通信。宿主計算機包含一個處理器。
宿主計算機處理器從中介計算機接收關于最終用戶的關聯個人信息的請求并根據個人信息儲存庫中該最終用戶的關聯個人信息服務于該請求。宿主計算機處理器更新中介計算機的關聯記帳數據。宿主計算機處理器可用多種方式更新記帳數據。第一，宿主計算機處理器可以為在選定時間段內中介計算機的每個新最終用戶遞增用戶計數。其次，宿主計算機處理器可以為通過中介計算機進行的交互作用計數。第三，在服務請求是請求進行事務處理的情況下，宿主計算機處理器可以根據所服務的請求遞增服務費總額。最后，宿主計算機處理器可以用這些方式的任何組合來更新中介計算機的關聯記帳數據。
宿主計算機處理器根據更新的記帳數據生成給中介計算機的發票。宿主計算機處理器可在定期的基礎上生成這些發票。在這個方面的另一個實施例中，宿主計算機處理器可以將所生成的發票傳遞到選定的目的地，諸如電子郵件目的地、打印設備、Web服務器上駐留的web頁、因特網客戶機、電話和傳真。
在這個方面的另一個實施例中，中介計算機有與之關聯的帳戶。宿主計算機可以在生成發票之前計入該帳戶的借方，使得所生成的發票僅反映中介計算機帳戶表明的數額以外的其它收入。計入借方的數額可以根據用上述任何更新方式更新過的中介計算機的關聯記帳數據來得出。
本發明的另一個方面是一種自動訪問最終用戶的關聯個人信息的系統與方法，其中，在個人信息提供者上存儲個人信息。將個人信息提供者上存儲的個人信息對應的一個個人信息的表示和一個鏈接通過客戶計算機提交給最終用戶。當啟動該鏈接時，客戶計算機被自動驅動到通過客戶程序向用戶提交個人信息提供者上的一頁的個人信息提供者。
在這個方面的一個實施例中，向客戶機下載一個應用程序。下載的應用程序啟動客戶計算機與個人信息提供者之間的連接。應用程序在個人信息提供者上的各頁之間漫游，直到到達該個人信息。最后，應用程序在客戶計算機上將該個人信息提交給用戶。應用程序可以與任何必要的與最終用戶關聯的和與個人信息提供者關聯的數據一起生成，或者可以將這種數據傳輸給應用程序。與個人信息提供者關聯的數據包含一個導航腳本(navigation script)，用于將應用程序引導到該個人信息。與最終用戶關聯的數據可以包含通過導航腳本啟動漫游所必需的任何數據。
在這個方面的另一個實施例中，將一個包含任何必需的用戶信息和個人信息提供者數據的消息傳送給客戶計算機，使客戶計算機自動地將該最終用戶登錄到個人信息提供者，由此讓最終用戶留在一個后登錄頁(post login page)上。在這個方面的一個最佳實施例中，該消息包含的一頁中含有一個表格，表格中包含登錄信息，當客戶計算機上的軟件打開登錄信息時，登錄信息將客戶計算機重定向到一個后登錄頁。
在這個方面的另一個實施例中，將客戶計算機驅動到個人信息的方法是，連接到個人信息提供者，漫游到個人信息提供者上的個人信息，將個人信息通過客戶計算機提交給用戶，代理隨后在與個人信息提供者的給定會話期內客戶計算機與個人信息提供者之間的交互作用。
在以下結合個附圖的說明中，本發明的以上和其它的目的與優點將更加顯而易見。
圖1是最終用戶執行的訪問因特網可用PI的當前過程的過程圖。
圖2是可用來實現本發明的部件的框圖。
圖3是PI引擎的部件的框圖。
圖4是當前PI訪問體系結構的圖。
圖5是支持用中介網站的PI訪問的體系結構的圖。
圖6是Cookie/客戶機高速緩存體系結構的圖。
圖7是通過圖1的傳統過程和通過跳板技術(springboardtechnology)訪問特定PI的基礎頁的流程圖。
圖8表示HTML頁的動態生成的集成模型。
圖9表示HTML頁的動態生成的運行時過程。
圖10表示采用改進的Java虛擬機的自動化小應用程序交互作用的過程。
圖11是舉例說明中間網站事務處理結構(transactionstructure)的流程圖。
現在詳細說明本發明的最佳實施例。參看各附圖，各視圖中相同的數字指示相同的部分。
最終用戶很快將不得不登錄到眾多不同的網站-每個網站有獨立的口令、安全、規則、軟件和“觀感”-在一連串的操作最后，就是要通過檢查郵箱，取出當前獲得的信息。因特網將在根本上改變最終用戶訪問個人信息(PI)的方式，將使電子商務成為與使用ATM一樣為人們熟悉的東西。“個人信息”是公司即信息提供者具有的、特定于各人或各人獨有的所有數據，諸如每月帳單、銀行帳戶余額、投資信息、保健津貼、電子郵件、話音和傳真消息、401(k)保有(holdings)或與特定最終用戶相關的可能的任何其它信息。
本發明通過自動聚集PI-不僅有由門戶所聚集的通用PI，而且有特定于需要身份驗證才能訪問的最終用戶的PI，緩和了當前一些PI獲取方法具有的一些問題。在一個實施例中，本發明將PI獲取和傳遞過程自動化。圖2提供了可用來實現本發明的各成分的框圖。最終用戶210訪問一個運行客戶機軟件270的客戶計算機220。在特定實施例中，客戶機軟件可以是一個通用網絡瀏覽器，諸如(Netscape公司的)Navigator或Communicator。客戶計算機220利用因特網230訪問在PI宿主機290上運行的PI引擎240。PI引擎240檢查所存儲PI的新舊。如果有陳舊的PI項，就將其更新，方法是從在因特網230上訪問到的在特定信息提供者的計算機系統260上運行的信息提供者網站250直接重新獲取該PI。PI引擎240將新版PI存儲在其儲存庫280中并將該PI傳遞到選定目的地-在本實例中是通過因特網230傳遞到客戶計算機220，后者用客戶機軟件270向最終用戶210顯示該信息。PI引擎240在將所聚集PI傳遞到儲存庫280和投遞目的地-本實例中是客戶計算機220-之前，要以同樣的方式刷新所有陳舊的PI。PI引擎240可以順序地或并行地刷新PI。例如，最終用戶的檢查帳戶余額要通過其銀行的網站更新，其電子郵件從其特定電子郵件站點更新，其證券財產目錄信息從其經紀人的站點更新，其電費帳單從其電力公司的站點更新。
圖3顯示的是PI引擎240的各部件的框圖。PI引擎240由存儲和處理兩種部件組成。三個主要存儲部件是PI儲存庫280、PI提供者儲存庫310和用戶儲存庫360。PI引擎240的第一個存儲部件是PI儲存庫280、PI儲存庫280含有各個PI記錄375；與特定最終用戶關聯的PI是與所有其它最終用戶的PI分開的。PI引擎也利用提供者儲存庫310，它保存著與特定PI提供者關聯的通用參數。PI提供者的通用參數定義了欲接入該PI提供者時要遵守的程序和必要的驗證數據的類型。每個PI提供者記錄也包含該提供者所提供的PI的類型和該提供者所支持的事務處理的類型。與PI或事務處理的類型一起包含在記錄中的還有其它數據類型和訪問PI或執行事務處理的必要程序。用戶儲存庫360也是維護關于特定最終用戶的配置和驗證信息所必需的。對于每個最終用戶來說，用戶選定的PI提供者、PI和事務處理，是連同從該PI提供者獲取該PI或執行該事務處理所必需的驗證數據一起登記的。
PI儲存庫280可以以各種方式實現。參看圖2，PI儲存庫280可包含一個在PI宿主機290上駐留的數據庫。按照這種方式，各個最終用戶210的PI是作為獨立的記錄或對象375在數據庫中存儲的。在另一個實施例中，各個最終用戶210的PI可存儲在單獨的文件375中，所以在文件層上執行分離不同用戶的PI的任務。
此外，或者作為替代，采用cookie技術，與每個最終用戶210關聯的PI可以駐留在其客戶計算機220上。這種cookie技術登載于D.Kristol和L.Montulli的《HTTP狀態管理機制》意見征詢(RFC)2109(1997年2月)(訪問網址http//www.itef.org/rfc/rfc2109.txt)，本文明確地全文引用。與每個最終用戶210關聯的PI要被存儲為PI cookies 375。這種實現機制為將一個最終用戶的關聯PI 375與所有其它最終用戶的關聯PI的分離提供了內在的支持。采用這種方法來代替中央化儲存庫，提供了一個防非授權訪問的安全層。進一步的措施是，可以將cookies中存儲的PI數據以加密格式存儲。
圖6是采用cookies技術的PI儲存庫208的典型實現的示意圖，關于PI引擎240的內部操作，也要參考上述對圖3的說明。如果用戶試圖直接地或通過中介Web服務器訪問PI，PI引擎240的訪問/事務處理部件340就從PI儲存庫280中檢索所存儲的PI 375。按照這種方式，該存儲的PI 375將被直接從最終用戶210的客戶計算機220發送的cookies接收。PI訪問/事務處理部件340將進行任何必要的解密。所要求的任何更新都由PI提供者250的直接訪問所獲得。PI傳遞部件350將提供機制來更新PI儲存庫280以及將所請求的PI直接地或通過中間網站傳輸到最終用戶210。PI傳遞部件350通過替換客戶計算機220上存儲的過時的PI cookies 375來將更新過的PI放入PI儲存庫280。PI傳遞部件350也要進行任何必要的加密。PI傳遞部件350還負責傳輸所請求的PI。在最佳實施例中，PI儲存庫280要用這種基于cookies的體系結構來實現。
用戶儲存庫360可以以各種方式實現。參看圖2，用戶儲存庫360可以包含一個駐留在PI宿主機290上的數據庫。按照這種方式，各個最終用戶210的個人配置數據都是以獨立的記錄或對象在數據庫中存儲的。此外或者作為替代，最終用戶數據可以按類似于以上就PI儲存庫280所述的cookie/高速緩存體系結構的方式來分布。
在最佳實施例中，用戶儲存庫360可以通過個人信息配置(PIC)文件來實現。PIC文件為每個最終用戶存儲一個安全加密的個人輪廓，內容諸如是姓名、地址、社會保障號。PIC文件便于最終用戶通過最終用戶配置部件330自動向信息提供者注冊。這個部件將讀取PIC文件并用所提取的個人信息預先填充選定各提供者的注冊模板。然后，如果需要，它將提示用戶輸入要求輸入的但在輪廓中沒有的信息。如果信息是完整的，注冊就自動完成。下一步，最終用戶配置部件330完成任何提供者表格，得到應答并更新最終用戶的PIC。
這四個主要處理部件訪問并操作三個儲存庫中的數據。處理部件可以在單一處理器上或多處理器上執行，前者例如基于奔騰級(MMX、PR0、II、III等)中央處理單元的文件服務器計算機系統或同等系統。如圖3所示，這四個處理部件是基準配置部件320、用戶配置部件330、PI訪問/事務處理部件340和PI傳遞部件350。基準配置部件320提供通過其向系統添加新用戶可選擇的PI提供者的界面。這個部件320可以以各種方式實現，包括試探出錯后由人工輸入配置信息，半自動試探出錯(自動的超文本標記語言(HTML)<FORM>元素、Javascript函數和Java小應用程序的定位)后由人工輸入配置信息，或者最好舉例配置(在模擬的Web客戶機中執行協議，模擬的Web客戶機自動生成一系列所需數據和訪問過程中的一系列步驟)。這些過程要在兩個層次被使用第一層是對特定PI提供者的一般訪問所需的數據和步驟的集合，第二層是在PI提供者站點訪問各特定PI項時所需的另外的數據和步驟的集合。基準配置部件320可以在有新的PI提供者加入系統時獨立啟動，也可以由于PI訪問/事務處理部件340的故障、可能表明對失敗訪問的訪問要求有變化而導致啟動。后一種警告更可能發生的情形是PI訪問/事務處理部件340應最終用戶的請求來驗證前面通過最終用戶配置部件330輸入的必要訪問數據，而將提供者儲存庫310提供的對訪問PI提供者的一般要求和對訪問PI或事務處理的特定要求二者與用戶儲存庫360提供的最終用戶數據比較，最后發現不一致。如果確定不一致，就對提供者儲存庫320作更新，使提供者數據與當前的訪問/事務處理的要求一致。
最終用戶配置部件330允許最終用戶選擇和配置特定用戶感興趣的PI和事務處理。這種配置信息保存在用戶儲存庫360中。當最終用戶向按照本發明的系統預訂時，系統允許用戶選擇所希望的PI和/或事務處理的類型和源。首先，系統請求最終用戶允許它代表用戶獲得任何選定的PI來執行任何授權的事務處理。然后，系統從提供者儲存庫320向用戶提供一系列已知的信息供給者和特定PI提供者所提供的PI的類型及所支持的事務處理的類型。系統請求由PI提供者要求的、訪問各PI提供者所必需的驗證數據以及特定PI和/或事務處理所要求的其它數據。假定最終用戶是所選定的PI提供者的已注冊用戶，或特定PI提供者不要求在先注冊，則將最終用戶提供的數據放入用戶儲存庫360。
一種獲得任何cookie數據的方法是最終用戶用PI引擎240作為代理服務器訪問各個以前訪問過的PI。PI引擎240將cookie數據與適當的網頁請求傳送給PI提供者，以獲得PI或執行事務處理，并在最終用戶的準許下在用戶儲存庫360中的該用戶的記錄中保留cookie數據的副本。另一種獲得cookie數據的方法是從最終用戶的計算機直接上載cookie信息。在最佳實施例中，如果用戶已經在提供者登錄過，就不需要cookie數據。所需的只是用于登錄的驗證數據。
如果最終用戶因為不是選定PI提供者的注冊用戶而沒有必需的信息，用戶配置部件330就提示用戶提供將最終用戶向PI提供者注冊所必需的信息，并執行PI提供者所要求的注冊程序。模擬的Web客戶機可以通過提供所需訪問數據和發送任何必需的cookie數據而自動地執行這個過程。這種模擬客戶機為最終用戶注冊的方式主要取決于PI提供者網站所用的交互方法。如果該網站使用HTML表格和公共網關接口(CGI)應用程序，則最終用戶配置部件330可以構建一個能模仿表格實際使用效果的統一資源定位器(URL)并將該URL提交給模擬的Web客戶機。用URL模仿表格相當于人工地向Web<表格>(Web<FORM>)元素輸入數據。參看Kerven、Foust、Zakour的《HTML3.2及問題解答》(HTML 3.2 Plus How-ToWaite Group Press出版，1997，559-569頁)。如果網站使用HTML表格與Javascript函數的組合，則用帶改進的Javascript解釋程序的模擬的Web客戶機遵循特定PI提供者的最終用戶注冊過程就能有效地為用戶注冊。要遵循的注冊過程可從提供者儲存庫320內該特定PI提供者的記錄中獲得。模擬的Web客戶機中的Javascript解釋程序將按照這個過程并提供由最終用戶提供的數據。如果PI提供者網站上的注冊過程采用Java小應用程序，則也可以使用類似的過程。帶Java字節碼解釋程序的網絡客戶機通過遵循儲存庫320內特定PI提供者的最終用戶注冊過程就能有效地為用戶注冊。字節碼解釋程序會提供最終用戶以前輸入過的數據，而不要求由最終用戶進行交互式輸入。如果PI提供者采用表格、腳本和小應用程序的組合，則可以將上述各個過程組合起來完成所希望的注冊。
參看圖2和圖3，用改進的Java虛擬機(VM)可以實現PI引擎240的各種功能部件與可通過提供者網絡服務器250得到的Java小應用程序之間的自動交互。用于與特定小應用程序交互的模板可駐留在提供者儲存庫310上。這種模板所使用的具體輸入數據可存儲在用戶儲存庫360中。當諸如最終用戶配置部件330或訪問/事務處理部件340的功能部件要求與提供者網絡服務器計算機250上的Java小應用程序自動通信時，改進的Java虛擬機就為這種交互提供條件。
圖10表示一個用這種改進的Java虛擬機實現這種自動交互作用的過程。在步驟1010，要求交互作用的功能部件標識提供者及部件需要與之交互作用的提供者上的特定小應用程序。在步驟1020，部件訪問提供者儲存庫310中與小應用程序交互作用所必需的模板。繼續到步驟1030，部件訪問用戶儲存庫360，以獲得模板所要求的數據。改進的Java虛擬機在步驟1040解釋小應用程序，并且并不像標準Java小應用程序執行時那樣要求來自用戶的交互式輸入，而是等待來自PI引擎的交互功能部件的輸入或是輸出到PI引擎的交互功能部件。在步驟1050，功能部件按照所訪問的模板向改進的Java虛擬機提供輸入數據并按照所訪問的模板檢索數據和接收輸出數據。只要小應用程序繼續輸入或輸出其它數據，步驟1040和1050就重復執行。小應用程序結束時，功能部件在步驟1060繼續其自己的處理。
注冊成功后會向最終用戶顯示注冊信息供將來參考。此外，最終用戶配置部件330還在用戶儲存庫360中存儲PI提供者必要的訪問驗證數據和訪問選定PI或事務處理所要求的額外數據。
在這種自動注冊的最佳實施例中，任何必需的cookie數據都為最終用戶配置部件330接受并按需存儲起來。在許多情況中，cookie數據是通話特有的，因此長期用途不大。在注冊期間生成的cookie僅在注冊期間使用，一旦注冊完成就丟棄。
注冊失敗的原因有幾種情況。首先，試圖向PI提供者注冊的最終用戶不符合注冊條件，例如試圖向銀行注冊的最終用戶在該銀行沒有帳戶，而銀行只對帳戶持有者開放。其次，最終用戶可能提供了不適當或不正確的數據，例如銀行注冊過程可能要求社會保險號、口令、銀行帳號和最終用戶母親的父姓，如果用戶輸入了不正確的社會保險號，注冊過程就會失敗。最后，PI提供者可能已經修改了其站點的注冊程序。在這種情況下，遵循由提供者儲存庫320提供的過程會導致注冊的失敗。在任何注冊失敗的情況下，都會將最初向系統提供的注冊數據向最終用戶表示。系統然后會請最終用戶復查所提供信息的準確性，如果發現錯誤就更正，然后再提交數據。如果由于提交相同的必需數據而導致第二次失敗，就會生成一個向最終用戶表示的出錯消息，表示要么用戶沒有從所選定的PI提供者訪問所選定PI的資格，要么由于PI提供者所作的修改導致了注冊的出錯。這第二次失敗也會觸發一個警告，建議可能需要重新配置提供者儲存庫320中該PI提供者的記錄。
最終，用戶儲存庫360就含有每個最終用戶的記錄。前文說過，這個記錄可以是一個數據庫項、一個或多個cookies或者是一個諸如PIC文件的文件。每個記錄標識所選定的各PI提供者及所需的一般訪問驗證數據并且在每個PI提供者下標識該最終用戶感興趣的、該特定PI提供者所提供的PI和所支持事務處理以及訪問該PI或執行該事務處理所需的任何額外數據的表。準確地說，諸如最終用戶名的重復信息只在記錄中集中存儲一次。
最終用戶配置部件330也允許最終用戶選擇一個或多個投遞目的地。一個目的地可能會是最終用戶的計算機-其代表是圖2中所示的運行客戶機軟件270的客戶計算機220。然而，計算機并不是本發明所設想的唯一目的地。PI傳遞的目的地可以包括傳真、電子郵件、電話、常規郵件、尋呼機、諸如Palm Pilot(3Com)的其它無線設備、網頁或頻道、網絡瀏覽器或其它傳遞機構。本發明也設想由最終用戶用網站作為中介間接地訪問PI，然而，這種間接訪問不要求最終用戶指定傳遞目的地，除非希望有另外的傳遞選擇。
此外，可以考慮通過由圖2中所示的運行客戶機軟件270的客戶計算機220經因特網直接訪問PI引擎來訪問最終用戶配置部件330。然而，其它訪問方法也是同樣可行的。例如用戶可通過使用中介網站來間接訪問PI引擎。另一種選擇方案是用電話接口來實現對最終用戶配置部件的訪問。
參考圖3，PI訪問/事務處理部件340支持PI引擎240的更新、獲取和事務處理功能。PI訪問/事務處理部件340負責訪問和存儲用戶PI并執行最終用戶授權的事務處理。當需要為選定的最終用戶進行訪問或更新時，PI訪問/事務處理部件340就綜合提供者儲存庫320和用戶儲存庫360的信息，以更新PI儲存庫280中的最終用戶PI。對于每條要求訪問或更新的PI，PI訪問/事務處理部件340在提供者儲存庫320中查找該特定PI所需的訪問過程和信息。在用戶儲存庫360中找出驗證與訪問數據。PI訪問/事務處理部件340用這個信息在因特網上連接該PI提供者的網站，以訪問該PI。如果有多條PI要求更新或訪問，則訪問可以串行地或并行地進行。
被請求的事務處理也得到類似的支持。對于每個事務處理，PI訪問/事務處理部件340綜合提供者儲存庫320和用戶儲存庫360的信息，來執行所請求的事務處理。PI訪問/事務處理部件340在提供者儲存庫320中查找該特定事務處理所需的事務處理過程和信息。在用戶儲存庫360中找到驗證和訪問數據。PI訪問/事務處理部件340用這個信息從該PI提供者的網站在因特網上執行該事務處理。
模擬的Web客戶機可以自動執行訪問或事務處理過程，同時提供必要的訪問和驗證數據。這種模擬客戶機訪問PI或執行事務處理的方式，極大地依賴于PI提供者網站上所用的交互方法。如果網站采用HTML表格和公共網關接口(CGI)應用程序，則PI訪問/事務處理部件340可以構建一個統一資源定位器(URL)來復制表格實際使用效果，并將該URL提交給模擬的Web客戶機。用URL模仿HTML表格相當于人工向Web<FORM>元素輸入數據。參看Kerven、Foust、Zakour的《HTML 3.2 plus How-To》(Waite Group Press出版，1997，559-569頁)。如果網站使用HTML表格與Javascript函數的組合，則帶改進的Javascript解釋程序的模擬的Web客戶機只要分別按照特定PI或事務處理的PI訪問/事務處理過程就能有效地訪問PI或執行事務處理。要遵守的訪問/事務處理過程可從提供者儲存庫320中該特定PI或事務處理的記錄中獲得。模擬的Web客戶機中的Javascript解釋程序將按照這個程序及提供在用戶儲存庫360中找到的數據。如果PI提供者網站采用Java小應用程序，則也可以使用一個類似過程。帶Java字節碼解釋程序的網絡客戶機通過遵循提供者儲存庫320內存儲的該特定PI或事務處理的過程就能有效地訪問PI或執行事務處理。字節碼解釋程序會提供來自最終用戶儲存庫360的數據，而不要求由最終用戶進行交互式輸入。如果PI提供者Web站點采用表格、腳本和小應用程序的組合，則可以將上述各個過程組合起來完成所希望的訪問。
在這種自動訪問或事務處理的一個最佳實施例中，任何必需的cookie數據都為PI訪問/事務處理部件340接受并按需存儲起來。在許多情況中，cookie數據是通話特有的，因此長期用途不大。所生成的cookie僅在這些功能期間使用，一旦挖掘(mining)或事務處理操作完成就被丟棄。
為了在登錄后迅速向最終用戶提供個人信息，PI訪問/處理部件340有必要在最終用戶登錄之前就選擇數據收獲的最終用戶。一種解決方法是，每當某最終用戶直接或通過中介網站請求訪問其PI時就更新最終用戶的所有PI。另一種方法是，每當向特定提供者請求PI時，就更新該提供者所提供的某最終用戶的所有PI。所以，由最終用戶登錄到系統的操作，實際上為立即PI更新選擇了該最終用戶。然而，這種方法可能導致對PI引擎240資源的低效使用。
鑒于潛在用戶和提供者的龐大數目以及提供盡可能最新數據的目標，另一個實施例包括一個為優化選擇從提供者收集數據的最終用戶的進度表(Schedule)而開發的算法。這個算法分解是提供者的更新策略、用戶的登錄習慣和用戶-提供者帳戶特點。適當應用該算法，會保證對給定用戶來說要盡可能不頻繁進行PI的收獲，由此盡量減少系統資源的消耗。
如果能準確預測下一個提供者更新時間和下一個期待的用戶登錄，就能創建一個能更聰明收獲的模型。并非在提供者更新其網站時就立即收獲提供者所有用戶的數據，而是可以根據用戶的預期登錄時間和網絡活動輪廓(profiles)隨著時間的延續而分散地收獲。例如，如果提供者A在星期五夜間更新其網站，并且預計該提供者的一大批用戶在星期一早晨之前不會登錄，則收獲負荷就可以分布在若干天中。這種作法的優點是將PI引擎240的負荷峰值以及由PI引擎240對提供者帶寬的耗費都最小化。要取得這種優化，PI引擎240就必須維護并改進每個提供者和用戶的模型。可以將這種數據分別維護在提供者儲存庫310和用戶儲存庫360中。
每當用戶使用PI引擎240時，都可以捕獲時間和日期。一旦積累了足夠的登錄次數，就可以就每月哪些天、每周哪些天、每天哪些時間來分析登錄時間。在一個模型中用這些分析結果來預測預期的下一次用戶登錄。然后用以后的登錄來測試并改進該模型，直到建立了一定程度的可信度。一旦確定了較高的可信度，就將該用戶模型并入到自適應收集調度程序中。在特定最終用戶的模型達到較高的可信度之前，可以使用上述的收獲方法之一。
每個提供者根據因其獨特資源和商務模型而產生的策略更新其站點。要使任何自適應的調度程序(adaptive scheduler)工作，必須使每個提供者的策略模型化。在有些情形中，策略是不言自明的。在另外一些情形中，必須根據經驗來確定策略。提供者的策略最可能是下述各類之一·類型I.為所有用戶定期更新的·類型II.相對于每個用戶定期更新的·類型III.以偽隨機(pseudo-random)方式更新的根據提供者的類型可以使用以下方法。
第I類提供者策略調度算法1.假設具有“無可信度”模型的用戶有一個立即登錄時間。
2.根據用戶的預測登錄時間對用戶按時間順序排序。
3.將所有用戶的預期登錄時間后推1小時。
4.執行一個沿時間邊界的密度曲線擬合(density curve fit)，以得到一個多項式函數，可用多項式函數來確定給定時期要求收獲的用戶帳戶的數目。
5.用討論中的時間段的網絡活動曲線的逆執行一個累計匹配算法(integral matching algorithm)，以調節分布曲線。
6.可能的活，朝時間零的方向重新分配高峰收獲時間，以整平分布曲線。
7.按照分布曲線向排序的用戶分配收獲時間。
8.監控時間并在適當時收獲用戶帳戶。
第II類提供者策略調度算法對于這類的每個提供者來說，必須標識一個確定個人信息何時被更新的用戶屬性。在有些情況中，可能需要向用戶詢問這種信息。其它情況下，可以從所收獲的信息中確定這種信息。如果用這些手段的哪一種都不能確定用戶的這個屬性，可以每天監控該提供者網站上個人信息的變化，直到確立了一個模式。
由于給定的一天中提供者所更新的帳戶是自然、均勻分布的，所以可以在用戶預期登錄時間之前一小時收獲用戶的帳戶。如同第I類算法一樣，具有“無可信度”模型的用戶應當被立即收獲。
第III類提供者策略調度算法這種策略是最困難的策略。由于提供者更新用戶帳戶的方式不是確定不變的，所以每個提供者要決定信息對用戶的要害程度。對于那些非常關鍵的提供者來說，應當每天、甚至更頻繁地收獲每個用戶帳戶。對于那些不太關鍵的提供者來說，應當次數較少地、可能在總體的系統活動程度較低時收獲用戶帳戶。
PI傳遞部件350負責將PI格式化并傳遞到最終用戶。傳遞一般是在對所有過時的PI更新之后進行的。除通過中間網站訪問的PI外，PI將被傳遞到如在用戶儲存庫360中所指定一個或多個目的地(例如傳真、電話、尋呼機、網絡瀏覽器、電子郵件等等)。如果目的地不是中間網站，PI傳遞部件就執行將PI傳遞到適當的目的地所必須的所有格式化。例如，如果目的地是網絡瀏覽器，就將PI按HTML文檔進行格式化；如果目的地是電話，就將PI提交去進行語音合成和傳輸。
就目的地是中間網站的情況而言，PI是以一種能被中間網站配置的格式傳遞的。圖5是本發明采用中間網站的一個可能的實施例的示意圖。最終用戶210用客戶計算機220在因特網230上訪問中間網站510。最終用戶210登錄到中間網站510。中間網站510在因特網230上聯系PI引擎240，并從PI提供者網站250直接接收按要求更新過的該最終用戶的PI。中間網站510接收PI，按照其特定的格式風格和圖形用戶界面，將其并入若干頁，并將這些頁傳遞給最終用戶210。PI引擎240的使用對最終用戶210是透明的。此外，起著給最終用戶210聚集PI的作用的中間網站510，可以—并極其可能—同時起PI提供者的作用。
在另一個實施例中，這種格式化是通過一個結合各種來源的樣式和布局信息的動態HTML生成系統而發生的。PI傳遞部件350動態地生成定制的HTML頁。這些頁是根據來自各種源的若干樣式要素(諸如背景顏色、前景顏色、字體大小、顏色和樣式、頁面布局等等)和來自各種源的內容而定制的。信息提供者、發布者、最終用戶、PI傳遞部件350或這些源的任何組合、或者其它相關源，都可以提供用于頁面生成的定制要素。最后，每個HTML頁必須用數據填充。這種頁中使用的數據，可以來自例如信息提供者、發布者、最終用戶、PI傳遞部件350或這些源的任何組合、或者其它相關源。所要求的解決方案是一個代表在運行時執行這種HTML生成的通用算法的系統。樣式和內容可以以任何適當的格式提供，例如可擴展樣式表語言(XSL-Extensible Stylesheet Language，由W3C在http//www.w3.org/TR/WD-xsl中規定，本文全部采用作為參考)和/或可擴展標記語言(XSL-Extensible Markup Language，由W3C在http//www.w3.org/TR/REC-xsl中規定，本文全部采用作為參考)或者其它合適的格式化標準。對這種系統的關鍵要求是問題域的完全封裝和運行效率。
在最佳實施例中，解決方案根據的是如圖8所示的以下基本模型1.確定6組定制要素發布者內容810、提供者內容820、發布者樣式規范830、提供者樣式規范840、用戶特定的內容850和用戶特定的樣式860。
2.每組定制要素810-860被視為是向執行動態頁生成的運行時系統870的一個單獨、獨立和必要的輸入。
3.每個輸入810-860都將采用XML流的形式。
4.輸出880將采用HTML流的形式。
5.動態頁生成系統870針對每組6個有效輸入810-860生成有效輸出880。
圖9表示了由這種系統870實際執行的運行時輸入處理序列1.由內容合并器單元910將發布者內容810與提供者內容820及用戶特定的內容850組合，以便產生一個完整的內容說明930。
2.由樣式合并器單元920將發布者樣式810與提供者樣式840及用戶特定的樣式860組合，以便產生一個完整的樣式說明940。
3.由樣式應用器950將樣式說明940應用到內容說明930，以便產生生成頁880。
為了完全地封裝問題域，必須對系統870作以下要求1.每個XML輸入810-860都是有效的XML流。
2.內容說明810、820和850對于同一個文檔類型定義來說全部都是有效的。
3.樣式說明830、840和860對于同一個文檔類型定義(諸如XSL DTD標準)來說全部都是有效的。
4.以接受兩個或更多XML流并產生組合的XML輸出為任務的合并單元910和920必須能夠為任何一組有效的XML輸入生成這種輸出。
另一個執行這種任務的方法是將PI格式化或帶有預定義的類(CLASS)屬性的HTML單元。接收這些單元的中間Web網站可以動態地將它們附入向PI的最終用戶傳遞的頁中。并入這種單元的頁可以包括與預定義的類(CLASS)集相關的不同樣式信息。可以用第1層級聯樣式表來實現這種可配置性。參看Kerven、Foust、Zakour的《HTML 3.2 Plus How-To》(Waite Group Press 1997年出版，651-693頁)和Walsh的《An Introduction to Cascading Style Sheets》(World Wide Web Journal雜志，1997年冬季，147-156頁)。這個選擇對中間網站的程序支持要求最小，但是對中間網站向最終用戶提交PI的靈活性有一定程度的限制。
另一方面，中間網站可以用標準化應用程序設計接口(API)開發一種應用程序來直接訪問PI數據。在這種情況下，可以不用PI傳遞部件350，也可能要將PI傳遞部件350用作負責服務于對數據的API請求的部件。按照這個模型，中間網站要負責作出對原始PI數據格式化的全部決定。這個實施選擇要求中間網站更多的程序支持，但是允許中間網站在使用原始PI時有更大的靈活性。
能利用中間網站來傳遞PI是有十分重要的用途的。這種功能使已經熟悉某個現有PI提供者的最終用戶不僅能訪問該特定PI提供者的相關PI，也能方便地在熟悉的用戶界面—即該現有PI提供者網站中訪問其它PI提供者的所有PI。在這種情況下，對PI的請求直接發端于中間PI提供者網站而間接發端于最終用戶。安全措施會限制對授權的中間網站的訪問。這些措施可能包括對最終用戶和中間網站的驗證。此外，為了更加安全，可能還要求驗證最終用戶與特定中間網站之間的關聯。
此外，中間網站的使用也支持一種新型的事務處理模型。在這個事務處理模型中，中間網站補充或全面補償PI引擎管理員向最終用戶提供的服務。這些事務處理由于PI引擎的審計和跟蹤功能而變得更加方便。這些功能允許對按人的費用、按交易的費用、按訪問的費用或它們某種組合的計算進行評估。可以直接向中間網站要求支付各評估值。或者，可將這些值從向中間Web站點收取的最低月費中記帳，而超出最低收費的費用則直接向中間Web站點收取。
圖11表示按所述模型的典型過程的流程圖。在步驟1110，中間網站支付最低月費。在步驟1120，PI引擎審計和跟蹤用戶通過中間網站的使用情況。所審計的使用情況用于按用戶、按訪問、按交易或它們的組合評估費用。在步驟1130，將所審計的數額從在步驟1110支付的費用計入借方。在步驟1140向中間網站收取超出所支付的最低費用的任何費用。
最終用戶經常需要訪問由特定PI的提供者生成的基礎網頁。傳遞部件可以不僅傳遞PI，也傳遞直通提供該PI的提供者的網頁的訪問點。訪問點的形式可以是鏈接、表格按鈕或其它某種交互式訪問機制。
這種訪問點大大地提高了最終用戶訪問基礎網頁的效率，如圖7所示。在訪問PI的傳統過程100中，最終用戶必須經歷許多中間網頁才能到達所需的網頁，這期間要求進行各種經常是繁瑣的交互作用。
最終用戶首先必須標識提供者(110)。下一步，最終用戶必須定位該提供者的網址(120)。然后，用戶請求提供者的登錄頁面(130)。如果最終用戶忘記了登錄所必需的信息，就必須找出這種信息，否則就不能通過萬維網訪問所需的信息。最終用戶然后漫游提供者的網站(140)。這通常必然要訪問提供者的主頁(710)，然后在提供者網站上瀏覽各種中間網頁(720)。最終用戶可能不得不數次返回主頁(710)，也可能偶然地完全離開系統，只好再次登錄(140)，直到最終定位所需的信息(150)。
如果采用跳板技術，整個過程被精簡成只要點擊一次訪問點。PI引擎的傳遞部件連同PI一起傳遞一個對提供者的基礎網頁的訪問點。結果，最終用戶只要與PI表示頁進行一次交互作用(760)。這種交互作用立即執行為將用戶帶到所需基礎網頁(150)而必需的與提供者網站的交互作用。
在一個實施例中，可以用Java小應用程序來實現這個跳板技術。參看圖2，小應用程序要由最終用戶的客戶機軟件270—通常是網絡瀏覽器—從PI宿主機290下載，并由最終用戶的計算機220在本地執行。小應用程序會將客戶機軟件270驅動到所需的頁。這種小應用程序能從提供者儲存庫310和用戶儲存庫360提取用于驅動客戶機軟件的程序和數據。
在另外一個實施例中，PI引擎240可以作為一個按需直接訪問提供者儲存庫310和用戶儲存庫360的代理服務器工作。當PI引擎240接到向特定信息的源跳轉的請求時，該引擎就執行必要的操作，以漫游到所希望的頁，并將所希望的頁傳送到最終用戶的計算機220。與該頁的進一步交互作用可能要求由PI引擎240進行其它的代理操作，因為累積的cookie數據可能駐留在PI宿主機290上。這個實施例局限于在處理標準HTTP通訊而不是安全HTTP通訊中使用。
在最佳實施例中，跳板為最終用戶提供向PI提供者網站250的自動登錄并允許最終用戶210通過客戶機軟件270漫游。這種自動登錄可以通過使用超文本傳輸協議(HTTP)重定向來完成。當接收到最終用戶210通過客戶機軟件270發出的跳板訪問請求時，PI宿主機290就向該跳板訪問的目標PI提供者網站250請求登錄頁。在PI宿主機290上運行的PI引擎240接收這個登錄頁并通過訪問提供者儲存庫310和用戶儲存庫360中的適當數據來構造一個登錄請求。該登錄請求被內置在向客戶機軟件270發送的HTTP重定向中。客戶機軟件270被重定向到目標PI提供者網站250，然后將最終用戶210自動登錄到該網站。
另一方面，這個功能也能通過如上所述的Java小應用程序來實現。此外，PI引擎240還能生成一個含有有關登錄請求而不是HTTP重定向的Javascript頁。該Javascript頁可以被返回到客戶機軟件270。然后由客戶機軟件270執行該頁，以完成自動登錄。
圖3的PI引擎240也可以包含一個網站監控器3 70處理部件。這個部件有系統地監控所支持的PI提供者網站的變化。這個部件加強了系統識別PI提供者網站過程、數據要求和cookies要求中的變化的能力。這個部件由于通過來自PI訪問/事務處理部件340的反饋來補充或替代變化標識而提高系統的效率。
本發明的另外一個實施例可支持PI的本地化操作。這在圖2的客戶計算機220上運行的客戶機軟件270是一個專用網絡客戶軟件而不是諸如Netscape的通用網絡客戶程序時可以實現。這個專用客戶程序可以用Web頻道技術來使本地PI下載和更新過程自動化。如果PI儲存庫是通過前文所述的cookie體系結構實現的，這個專用客戶程序就可以提供對所存儲的PI的直接本地訪問。
在另一個實施例中，圖3的PI引擎240可以既支持系統支持的PI提供者也支持特定于特定最終用戶群的PI提供者。在這個實施例中，最終用戶不限于只能使用存在于提供者儲存庫310中的PI提供者的PI。如果最終用戶要增加由不受支持的PI提供者提供的數據，則最終用戶要訪問基準配置部件320并為該不受支持的PI提供者創建一個配置。該提供者和PI配置連同驗證和訪問數據，要與用戶的記錄一起存儲在用戶儲存庫360中。
本發明的另一個實施例支持在圖3的提供者儲存庫310中加入PI事務處理過程和訪問要求。實現這種事務處理所需的最終用戶特定的信息要與用戶記錄一起駐留在用戶儲存庫360中。PI訪問/事務處理部件340的功能要擴展到支持執行事務處理。這個額外的功能可以以與前文針對用模擬的Web客戶機執行訪問所述的過程類似的方式得到支持。這個實施例的另外一個特點是包含通過提供自動啟動事務處理的觸發事件而實現的自動化或半自動化的帳戶管理。
例如，圖2的最終用戶210能通過PI引擎240保持其帳戶的在線狀態。如果某信息提供者能夠接受在線支付，PI引擎240就能支持這種事務處理的完全活部分自動化。如果某個信息提供者有帳單到期日期，PI引擎240就能設置該信息標志并向最終用戶210發電子郵件，通知帳單到期。所以，用戶就不必逐個地向每個提供者查詢到期日期信息。PI引擎240也能為允許通過網絡服務器260支付的提供者自動實現有限帳單額度內的支付，然后用電子郵件將支付通知發送給用戶。
到期日期的獲取可以用圖3所示的PI訪問/事務處理部件340來完成。通過任何由PI傳遞部件350支持的傳遞都能將到期日期信息提供給最終用戶。PI訪問/事務處理部件340會用標準電子商務帳單支付方法來向提供者支付用戶的帳單(如果用戶選擇這種方式的話)。一旦支付了帳單，就向用戶發送電子郵件通知，內有提供者信息和付帳信息。用戶能在用戶儲存庫360中規定自動支付的數額范圍。如果帳單超出用戶規定的數額，PI引擎就向用戶發出電子郵件通知，而不是自動地支付帳單。
以上所述的各實施例都是僅作為示例性的例子給出的。非常顯然，可以對本說明書中披露的具體實施例作出許多改動而不偏離本發明。因此，本發明的范圍應當由下面的各項權利要求來確定而不是局限于以上具體描述的實施例。
權利要求
1.一種自動訪問與最終用戶關聯的個人信息的方法，其中，個人信息在個人信息提供者上存儲，該方法包含的步驟有(a)將與存儲在個人信息提供者上的個人信息對應的一個個人信息的表示和一個鏈接顯示在與最終用戶關聯的客戶計算機上；(b)當啟動所顯示的鏈接時，向客戶機下載一個應用程序，其中，下載的應用程序在客戶計算機上執行時執行下述步驟(i)連接到個人信息提供者；(ii)漫游到個人信息提供者上的個人信息；以及(iii)將個人信息提交給客戶計算機的用戶。
2.權利要求1的方法，進一步包含的步驟為(a)將與最終用戶關聯的最終用戶數據傳輸到客戶計算機；以及(b)將與個人信息提供者關聯的個人信息提供者數據傳輸到客戶計算機。
3.權利要求2的方法，其中，傳輸與個人信息提供者關聯的個人信息提供者數據的步驟包含傳輸一個與個人信息對應的導航腳本。
4.權利要求3的方法，其中，傳輸與最終用戶關聯的最終用戶數據的步驟包含根據所傳輸的導航腳本來傳輸與最終用戶關聯的最終用戶數據。
5.權利要求1的方法，進一步包含的步驟是，根據與個人信息提供者關聯的個人信息提供者數據、根據個人信息和根據與最終用戶關聯的最終用戶數據，生成一個向客戶計算機下載的一個應用。
6.一種自動訪問與最終用戶關聯的個人信息的方法，其中，個人信息在個人信息提供者上存儲，該方法包含的步驟為(a)將與存儲在個人信息提供者上的個人信息對應的一個個人信息的表示和一個鏈接在與最終用戶關聯的客戶計算機上表示出來；(b)當啟動所表示的鏈接時，傳輸一個含有表格的頁，表格中包括登錄信息，當客戶計算機打開登錄信息時，登錄信息將客戶計算機重定向到個人信息提供者上的一個后登錄頁
7.一種自動訪問與最終用戶關聯的個人信息的方法，其中，個人信息在個人信息提供者上存儲，該方法包含的步驟為(a)將與存儲在個人信息提供者上的個人信息對應的一個個人信息的表示和一個鏈接在與最終用戶關聯的客戶計算機上表示出來；(b)當啟動所表示的鏈接時，通過執行下述步驟，將客戶計算機驅動到個人信息提供者上存儲的個人信息(i)連接到個人信息提供者；(ii)漫游到個人信息提供者上的個人信息；(iii)將個人信息提交給客戶計算機的用戶；以及(iv)代理客戶計算機隨后向個人信息提供者提出的請求。
8.一種存儲指令的計算機可讀的存儲器，它存儲的指令在執行時使處理器自動地訪問與最終用戶關聯的個人信息，其中，個人信息在個人信息提供者上存儲，所執行的步驟有(a)在與最終用戶關聯的客戶計算機上顯示與存儲在個人信息提供者上的個人信息對應的一個個人信息的表示和一個鏈接；(b)當啟動所顯示的鏈接時，向客戶機下載一個應用程序，其中，下載的應用程序在客戶計算機上執行時執行下述步驟(i)連接到個人信息提供者；(ii)漫游到個人信息提供者上的個人信息；以及(iii)將個人信息顯示給客戶計算機的用戶。
9.一種用于自動地訪問與最終用戶關聯的個人信息的系統，其中，個人信息在個人信息提供者上存儲，該系統包含(a)一個用于存儲與最終用戶相關聯的數據的用戶儲存庫；(b)一個用于存儲與個人信息提供者相關聯的數據的個人信息提供者儲存庫；(c)一個與用戶儲存庫及個人信息提供者儲存庫通信的處理器，處理器執行下列步驟(i)在與最終用戶關聯的客戶計算機上顯示與存儲在個人信息提供者上的個人信息對應的一個個人信息的表示和一個鏈接；(ii)當啟動所顯示的鏈接時，向客戶機下載一個應用程序，其中，下載的應用程序在客戶計算機上執行時執行下述步驟(A)連接到個人信息提供者；(B)漫游到個人信息提供者上的個人信息；以及(C)將個人信息顯示給客戶計算機的用戶。
全文摘要
按照本發明的用于傳遞個人信息的系統，具有包含最終用戶數據的用戶儲存庫、一個包含信息提供者數據的提供者儲存庫、一個包含個人信息的個人信息儲存庫和一個與這些儲存庫通信的處理器。處理器選擇一個最終用戶來進行個人信息聚集。處理器與一個或更多的信息提供者連接。然后，處理器就開始從所連接的信息提供者為選定最終用戶檢索個人信息。這種檢索所根據的是與選定最終用戶關聯的最終用戶數據和與所連接的信息提供者關聯的提供者數據。檢索出的個人信息被存儲到個人信息儲存庫。
文檔編號G06Q30/00GK1497465SQ0012024
公開日2004年5月19日 申請日期1999年10月27日 優先權日1998年10月28日
發明者R·布爾森, R 布爾森, └ , D·烏爾博格, G·弗雷斯塔特, 姿顧 申請人:維迪科隆有限公司