專利名稱：用于全局目錄服務的系統(tǒng)和方法
技術領域：
本發(fā)明涉及在網(wǎng)絡用戶之間的聯(lián)系信息的設定。特別是(但是不排除其它)，本發(fā)明涉及用于使用電子商務卡對象的全局目錄服務的系統(tǒng)和方法。
背景技術：
電子商務卡的使用最初是由Versit聯(lián)盟(Versit Consortium)于1995年提出的，并且隨后由互聯(lián)網(wǎng)郵件聯(lián)盟(Internet Mail Consortium, IMC)著手研究。IMC至今已經(jīng)制定出了針對電子商務卡的很多標準(比如如，vCard或hCard),其中，最新的標準是開放標準vCard ν3· O。vCard ν3· O是根據(jù)兩個互聯(lián)網(wǎng)工程任務組(Internet EngineeringTask Force, IETF)文件(即，根據(jù)請求評議(Request for Comments, RFC) 2425 (MIMEContent-Type for Directory Information)以及根據(jù) RFC 2426 (MIME DirectoryProfile))來定義的。如這些標準中所定義的，vCard和hCard兩者都可以包括元數(shù)據(jù)、語義信息、圖形和圖像，以及甚至音頻或視頻剪輯。如這些標準中所定義的，因此，vCard和hCard都僅僅是被動信息元素。在標題為“Methodfor Management of vCards”的歐洲專利申請 EP1589730 中討論了 vCard的使用的一個示例。EP 1589730是針對一種用于在移動終端上創(chuàng)建vCard并且在移動終端和其它設備之間交換所述vCard的方法。根據(jù)EP 1589730的方法，通過將MME類型的vCard數(shù)據(jù)插入JPEG頭部，從而將vCard作為圖像數(shù)據(jù)保存在JPEG文件中。在Beaton 等人的標題為 “Electronic Business Cards” 的美國專利 No. 6442263中，討論了一種用于為通信設備提供電子商務卡的方法。根據(jù)Beaton的方法，商務卡是使用CLID信息來創(chuàng)建的，在電話網(wǎng)絡的用戶之間傳輸，并且用來自動地發(fā)起呼叫。在Feldhahn的美國專利No. 7246099中公開了采用vCard平臺的另一種系統(tǒng)。Feldhahn允許人們在他人的聯(lián)系軟件中保持當前的聯(lián)系信息，而不必將更新后的聯(lián)系信息分別通知接收人員或者向該人員手動地重新發(fā)送。針對個人的靜態(tài)聯(lián)系信息是保存在中央服務器上的，并且被分配了全局唯一 ID。所述靜態(tài)聯(lián)系信息包括動態(tài)鏈路，該動態(tài)鏈路含有創(chuàng)建者的全局唯一 ID，所述聯(lián)系信息的接收者可以使用該全局唯一 ID來檢索更新后的聯(lián)系信息。Desai的美國專利No. 5493015描述了一種電子商務卡系統(tǒng),其提供了精簡并且便攜的系統(tǒng)，用來從商務卡讀取并且保存商務卡數(shù)據(jù)，所述商務卡具有保存在該商務卡上的計算機可讀存儲介質上的計算機可讀數(shù)據(jù)。該電子商務卡系統(tǒng)使用了連接到計算機控制系統(tǒng)的讀取器。該電子商務卡系統(tǒng)還向被該電子商務卡系統(tǒng)所接受的商務卡數(shù)據(jù)提供組織和操作能力。雖然諸如vCard或hCard之類的電子商務卡可以在很多應用中使用，但是電子商務卡的功能目前受到一些限制。擴展這些商務卡的功能從而使它們包括功能、腳本、以及可操作元素，將是明顯有利的。本發(fā)明試圖解決現(xiàn)有的電子商務卡標準和實施的這類限制。

發(fā)明內(nèi)容
相應地，在本發(fā)明的一個方面中，提供了一種在多個網(wǎng)絡用戶之間傳輸聯(lián)系信息的方法，所述方法包括下列步驟在用戶終端處將所述聯(lián)系信息編譯到具有一個或多個文字字段的電子商務卡中；向目錄注冊所述電子商務卡，其中，所述注冊電子商務卡的步驟進一步包括通過將所述電子商務卡的文字字段映射到包含在所述電子商務卡
對象中的一個或多個對象屬性，來將所述電子商務卡封裝到所述電子商務卡對象；向目錄發(fā)送所述電子商務卡對象；以及將所述電子商務卡對象保存在數(shù)據(jù)庫中；在所述目錄處接收來自用戶的一組搜索參數(shù)；向所述數(shù)據(jù)庫搜索與所述搜索參數(shù)相匹配的電子商務卡對象；向所述用戶提供電子商務卡對象的列表；在所述目錄處接收來自所述用戶的針對來自所提供的電子商務卡對象的列表中的一個電子商務卡對象的請求；向所述用戶轉發(fā)所請求的電子商務卡對象。適宜地，每種電子商務卡對象都包括屬性和方法。方法是用于操作屬性、使用屬性或者執(zhí)行某種其它功能的功能或例行程序。所述電子商務卡對象還可以包括一個或多個可操作的元素。這些元素可以包括用于啟動本地設備應用程序、啟動應用程序或服務的腳本、和/或發(fā)起基于web界面或基于wap界面的腳本。所述電子商務卡對象可以包括元數(shù)據(jù)、語義信息、圖形、圖像、以及甚至音頻或視頻剪輯。在本發(fā)明的一個實施例中，所述電子商務卡對象可以是指向多個電子商務卡對象的指針或者是多個電子商務卡對象的掩碼，使得作為指向多個電子商務卡對象的指針的針對所述電子商務卡對象的任何用戶操作，實際上是分別對這些多個電子商務卡對象中的每個電子商務卡對象的相同操作。優(yōu)選地，所述網(wǎng)絡是移動通信網(wǎng)絡、IP網(wǎng)絡或者諸如此類的網(wǎng)絡。注冊的步驟可以進一步包括確認一組用戶證書的步驟。所述用戶證書可以是被動證書或主動證書或者兩者的結合。被動證書可以包括但不限于請求方的移動電話號碼、和/或在無需該請求方主動知曉或者參與的情況下能夠通過SIM認證從該請求方獲得并且認證的任何這類信息。主動證書包括但不應當限于PIN、密碼、和/或一方必須明確提供的任何這類信息。適宜地，搜索參數(shù)可以是一組關鍵詞。在這種情況下，接收的步驟可以包括在使用所述關鍵詞開始合適的數(shù)據(jù)庫查詢之前，對所接收到的關鍵詞進行解析。所述提供電子商務卡對象的列表的步驟可以包括根據(jù)現(xiàn)有的商業(yè)規(guī)則，對查詢的結果進行分類和/或過濾的步驟。這些規(guī)則可以包括但不限于賦給對象的已驗證狀態(tài)的相對權重、作為對象屬性的已確認的關系、關鍵詞匹配精度的級別、信息的新近程度、布爾運算，如果有的話，以及其它要考慮的因素。所述方法可以進一步包括允許用戶或者任何已授權方更新或者刪除所述電子商務卡對象的任何屬性的步驟。適宜地，所述對電子商務卡對象的屬性進行更新的步驟可以通過多個用戶界面執(zhí)行，包括但不限于web或wap界面、局部應用、或者使用了電子郵件、SMS、MMS、flash消息、或IP技術的菜單系統(tǒng)。所述方法還可以包括接收來自用戶的針對同步或下載的請求的步驟。適宜地，所述同步的步驟進一步包括驗證被請求進行同步或進行下載的電子商務卡對象是否存在；驗證被請求進行同步或進行下載的電子商務卡對象的隱私或訪問級別設置；如果在同步或下載之前電子商務卡對象的隱私或訪問級別設置需要征得同意，則向被請求進行同步或進行下載的所述電子商務卡對象的擁有者發(fā)送可操作通知，以便允許或不允許所述請求；當允許所述同步或下載請求時，或者如果在同步或下載之前這些對象的隱私或者訪問級別設置不需要征得同意時，則向所述請求用戶發(fā)送所述被請求進行同步或進行下載的電子商務卡對象的同步更新或副本；以及，向所述請求方發(fā)送合適的通知。所述方法還可以包括對所述電子商務卡對象的內(nèi)容進行驗證和認證的步驟。所 述驗證和認證的步驟可以包括當成功驗證或認證所述電子商務卡對象中的數(shù)據(jù)時，將被請求驗證的對象標記為已認證；并且向相關方發(fā)送合適的通知?？蛇x地，所述驗證和認證的步驟可以包括通過使用現(xiàn)有的后付費用戶數(shù)據(jù)庫、使用與所述對象相關聯(lián)的已驗證的關系、使用概況信息、以及使用類似的或者受到預設商業(yè)規(guī)則制約的這些中的任何或全部的組合，來對置信水平評分，從而自動地執(zhí)行電子商務卡對象驗證；并且然后，將產(chǎn)生與預設閾值相比相等或者更高的置信水平的那些對象標記為已驗證。在本發(fā)明的另一個方面中，提供了一種用于促進在網(wǎng)絡用戶之間傳輸聯(lián)系信息的系統(tǒng)，所述系統(tǒng)包括耦合到所述網(wǎng)絡的至少一個服務器；耦合到所述服務器的至少一個數(shù)據(jù)庫；耦合到所述網(wǎng)絡的多個用戶終端，其中，每個用戶的終端配置為響應于所述用戶的請求，向所述服務器發(fā)送與用戶相關聯(lián)的聯(lián)系信息；其中，所述請求使得所述用戶的終端將所述聯(lián)系信息編譯到具有一個或多個文字字段的電子商務卡中，并且將所述電子商務卡的一個或多個文字字段映射到電子商務卡對象的一個或多個屬性，并且向所述服務器發(fā)送所述電子商務卡對象，以便保存在所述數(shù)據(jù)庫中。優(yōu)選地，所述網(wǎng)絡是移動通信網(wǎng)絡、IP網(wǎng)絡或者諸如此類的網(wǎng)絡。用戶可以通過保存在數(shù)據(jù)庫中的多個電子商務卡對象來搜索和/瀏覽，其中，所述搜索/瀏覽可以通過多個用戶界面來執(zhí)行，包括但不限于web或wap界面、局部應用、或者使用了電子郵件、SMS、麗S、flash消息、或IP技術的菜單系統(tǒng)。所述系統(tǒng)可以允許用戶或者任何已授權方更新或者刪除所述電子商務卡對象的任何屬性。適宜地，所述對電子商務卡對象的屬性進行更新的步驟可以通過多個用戶界面執(zhí)行，包括但不限于web或wap界面、局部應用、或者使用了電子郵件、SMS>麗S、flash消息、或IP技術的菜單系統(tǒng)。保存在數(shù)據(jù)庫中的電子商務卡對象可以標記為已證實的條目。已證實的電子商務卡對象是服務器向其提供對以下情況的最低程度確認的那個電子商務卡對象該商務卡對象中的信息包含了該商務卡對象聲稱所歸屬的個人或者單位的信息。電子商務卡的驗證是基于由驗證過程產(chǎn)生的置信水平，其包括但不限于，需要物理上存在并且提交證書、使用現(xiàn)有的后付費用戶數(shù)據(jù)庫、使用與對象相關聯(lián)的已驗證關系、或者受到某些商業(yè)規(guī)則制約的這些中的任何或全部的組合。除了賦給已驗證的電子商務卡對象的置信水平，所述已驗證狀態(tài)同樣也用于增大其在搜索結果中的相對權重，其中，查詢具有多個精確的和/或相似的匹配。適宜地，所述系統(tǒng)可以實現(xiàn)為跨越多個網(wǎng)絡的分布式系統(tǒng)。在這種情況下，全局目錄可以包括與多個網(wǎng)絡中的每個網(wǎng)絡相連接的多個計算平臺，每個計算平臺適用于主持、管理以及保持全局目錄服務。


為了使本發(fā)明可以被更容易地理解并且付諸實施，現(xiàn)在將參照描繪本發(fā)明優(yōu)選實 施例的附圖，并且其中圖I是描繪了根據(jù)本發(fā)明的一個實施例，用于促進在網(wǎng)絡用戶之間傳輸聯(lián)系信息的系統(tǒng)的原理圖；圖2描繪了根據(jù)本發(fā)明的一個實施例，用于更新電子商務卡對象的過程；圖3是描繪了根據(jù)本發(fā)明的一個實施例的搜索過程的原理圖；圖4是描繪了根據(jù)本發(fā)明的一個實施例的電子商務卡對象的檢索的原理圖；圖5是描繪了根據(jù)本發(fā)明的一個實施例，電子商務卡對象的驗證和認證的過程的原理圖；圖6是描繪了根據(jù)本發(fā)明的一個實施例，用于將位于移動設備上的電子商務卡對象與所檢索到的卡細節(jié)同步的過程的原理圖；圖7A是根據(jù)本發(fā)明的一個實施例的EBC (電子商務卡)對象的一種可能架構的概念圖；圖7B是描繪了由圖7A的EBC對象架構所產(chǎn)生的一種可能的菜單結構的原理圖；圖7C是描繪了根據(jù)本發(fā)明的一個實施例，EBC對象的一種可能架構的概念圖；圖7D是描繪了由圖7C的EBC對象架構所產(chǎn)生的一種可能的菜單結構的原理圖；圖8A是描繪了根據(jù)本發(fā)明的一個實施例，被指定具體上下文的EBC對象的一種可能架構的概念圖；圖SB是描繪了根據(jù)本發(fā)明的一個實施例，被指定具體上下文的EBC對象的一種可能架構的概念圖；圖SC是描繪了根據(jù)本發(fā)明的一個實施例，被指定具體上下文的EBC對象的一種可能架構的概念圖；圖9是表示在本發(fā)明的一個實施例中所使用的服務發(fā)現(xiàn)過程的流程圖；圖IOA是根據(jù)本發(fā)明的一個實施例，被指定具體上下文的EBC對象的一種可能架構的概念圖；圖IOB是根據(jù)本發(fā)明的一個方面，當從第三方客戶設備觀察時，被指定具體上下文的EBC對象的架構的概念圖；圖11是表示根據(jù)本發(fā)明的一個實施例的掩碼功能的圖；以及圖12是表示根據(jù)本發(fā)明的另一個實施例的掩碼功能的實施的流程圖。
具體實施例方式參照圖1，其描繪了用于促進在多個網(wǎng)絡用戶100之間傳輸聯(lián)系信息的系統(tǒng)(申請人已經(jīng)將其命名為全局目錄)。如圖所示，全局目錄包括連接到數(shù)據(jù)庫102的至少一個服務器101，所述數(shù)據(jù)庫102包含一個或多個已注冊方104的聯(lián)系信息。如圖所示，服務器連接到主機網(wǎng)絡102，該主機網(wǎng)絡向多個用戶103^10 '…、103n提供多項服務，包括注冊和從全局目錄檢索聯(lián)系信息。每個用戶IOS1UOl…、103n可以訪問全局目錄，以輸入他們的聯(lián)系信息。一旦注冊，該具體用戶的聯(lián)系細節(jié)可以被任何其它用戶103^10 '…、103 通過對該全局目錄服務進行查詢而檢索到。各種注冊和檢索過程等將在下面更詳細地討論。雖然已經(jīng)從連接到單一主機網(wǎng)絡的服務器角度對上述全局目錄系統(tǒng)進行了說明，但是本領域技術人員應當理解，全局目錄也可以實現(xiàn)為跨越多個網(wǎng)絡的分布式系統(tǒng)。在這種情況下，全局目錄可以包括與多個網(wǎng)絡內(nèi)的每個網(wǎng)絡相連接的多個計算平臺，每個計算平臺適用于托管、管理以及維持全局目錄服務。
圖2描繪了根據(jù)本發(fā)明的一個實施例的注冊過程200，其允許用戶增加或修改包含在全局目錄中的他們的聯(lián)系細節(jié)。為了向全局目錄注冊他們的細節(jié)，用戶需要將他們的聯(lián)系細節(jié)以電子商務卡(EBC)的形式向全局目錄服務發(fā)送(步驟201)。在發(fā)送之前，將EBC封裝成對象(步驟202)，下文稱為EBC對象。然后，將該EBC對象向全局目錄服務轉發(fā)(步驟203)，以便進行注冊。將電子商務卡封裝入電子商務卡對象，實際上是將vCard的各個字段(其僅僅是文字信息)映射到EBC對象的相關屬性內(nèi)的文字信息屬性。此時，該映射利用了在vCard信息和EBC對象屬性之間的一一對應關系，或者可能是由商業(yè)規(guī)則定義所限定的對應關系。當收到EBC對象時(步驟204 )，全局目錄服務開始檢查EBC對象是否保存在其數(shù)據(jù)庫中(步驟205)。如果在全局目錄上找到該EBC對象的記錄，則其開始驗證用戶的證書(步驟206)。所述證書可以包括下列信息中的一個或多個請求方的移動電話號碼或SIM身份或IMEI和/或在無需該請求方主動知曉或參與的情況下可以從該請求方得到的任何此類信息、PIN、密碼和/或一方必須明確提供的任何此類信息。如果證書是足夠的，則用包含在EBC對象中的數(shù)據(jù)來更新全局目錄的數(shù)據(jù)庫內(nèi)的用戶的先前條目(步驟207)。向用戶發(fā)送成功更新的通知(步驟208)。在數(shù)據(jù)庫內(nèi)沒有EBC對象的記錄(S卩，請求注冊的新用戶)的情況下，則全局目錄服務獲取該用戶的證書(步驟209)。一旦全局目錄服務已經(jīng)抽出相關證書，全局目錄隨后將EBC對象保存在其數(shù)據(jù)庫中。一旦EBC對象保存在全局目錄中，其就開始向用戶發(fā)送通知(步驟208)。這個新的條目將會被默認標記為未確認的或未驗證的。圖3描繪了根據(jù)本發(fā)明的一個實施例，用于使用戶能夠搜索包含在全局目錄中的信息的過程300。如圖所示，所述搜索過程是由用戶輸入一組搜索參數(shù)(例如，一組關鍵詞)而開始的(步驟301)。然后，向全局目錄轉發(fā)所述搜索參數(shù)(步驟302)。當接收到所述搜索參數(shù)時，全局目錄服務開始向其數(shù)據(jù)庫查詢(步驟303)包含與所述搜索參數(shù)相匹配(步驟304)的屬性的EBC對象。在數(shù)據(jù)庫內(nèi)存在與搜素參數(shù)相匹配的EBC對象的情況下，則目錄服務根據(jù)隱私參數(shù)的規(guī)定對這些匹配的EBC對象的已分類列表進行編譯(步驟305)。然后，向用戶轉發(fā)所述已分類列表(步驟306)，以便在用戶的終端上顯示(步驟308)。如果根據(jù)步驟304，數(shù)據(jù)庫查詢303沒有匹配結果，則全局目錄開始向用戶發(fā)送通知，指示沒有找到結果(步驟307)。然后，向用戶的終端顯示空結果(308)。當接收到基于步驟306的結果的已分類列表時，用戶可以隨后根據(jù)隱私參數(shù)的規(guī)定從全局目錄檢索到所期望的電子商務卡對象(步驟308)?？梢缘玫较到y(tǒng)支持的隱私參數(shù)提供了具體的隱私設置，其定義了來自某個人的EBC對象的信息被公眾獲得的程度。可以設置不同級別的信息可用性，并且限制到不同的群組，每個群組由下列因素定義與EBC對象擁有者建立的關系、關系的程度、常用概況元素、以及可以作為呼叫群組時的基礎的這類其它適當?shù)膮^(qū)別。因此，向用戶轉發(fā)的EBC對象可以因用戶不同而不同，取決于所采用的隱私控制的不同級別，例如，用戶可以屬于一受信任的EBC對象擁有者群組，因此，將向這類用戶轉發(fā)的EBC對象將包含如下信息屬性和方法這些信息屬性和方法對于來自另一群組的另一用戶而言是不可用的。
考慮到信息技術中的目前趨勢，一個人可以具有不同的電話號碼、不同的電子郵件地址、或者類似的信息。這樣的多種信息可以構成不同EBC對象配置(所述不同EBC對象配置提供了具體用戶的隱私設置或者偏好)的基礎，但是所有這些信息涉及單個人。在這些情況下，GD可以對所給定的EBC對象擁有者分配內(nèi)部客戶參考號碼(CRN)。然后，該CRN用于將針對用戶的具體EBC對象與相關信息即時地(on-the-fly)相關聯(lián)。因此，從已經(jīng)請求了相同EBC對象的兩個用戶的角度來看，某個人的電話號碼可能是不同的，但是兩個號碼都將把電話呼叫連接到同一個人。由于如上面討論的CRN唯一地標識了 EBC對象擁有者，系統(tǒng)也使采用趣味號碼成為可能。趣味號碼是與EBC對象擁有者和請求該EBC對象的用戶兩者都相關聯(lián)的號碼。趣味號碼是即時產(chǎn)生的，但是作為EBC對象擁有者和請求用戶之間的唯一通信標識符(電話號碼、電子郵件地址、URL等)是有效的，除非被EBC對象擁有者禁用。不同趣味號碼與各個請求用戶相關聯(lián)，但是這樣的多個趣味號碼是與單個EBC對象擁有者相關聯(lián)的。趣味號碼采用了端到端關聯(lián)，因此趣味號碼是與EBC對象擁有者的CRN和請求用戶的CRN兩者都相關聯(lián)的。這允許雙方之間進行雙向通訊。使用由第三方針對用戶產(chǎn)生的趣味號碼來連接到與該趣味號碼相關聯(lián)的EBC擁有者或者用戶是不被允許的，因為該趣味號碼系統(tǒng)使用了內(nèi)置式(built-in)認證機制。即，只有已經(jīng)產(chǎn)生的趣味號碼所針對的人員能夠使用該趣味號碼連接到另一端的與該趣味號碼相關聯(lián)的人員。圖4描繪了根據(jù)本發(fā)明一個實施例，用于從⑶檢索EBC對象的過程400的一個示例。如圖所示，向用戶呈現(xiàn)來自圖3的步驟308的EBC對象的已分類列表。然后，用戶在列表中選擇他們希望檢索的電子商務卡對象所針對的條目(步驟401)。然后，向全局目錄發(fā)送所述選擇，全局目錄隨后開始查找被分配給該EBC對象的隱私設置(步驟402)。在這種具體情形中，EBC對象被分成兩個群組，即，隱私列表和公開列表。如果基于步驟403確定被請求的EBC對象是隱私列表，則目錄服務向EBC對象的擁有者發(fā)送具有可操作消息的形式的請求404 (步驟405)，以便準許向請求方公開包含在EBC對象中的信息。擁有者在接收到該請求后向目錄服務回復響應(步驟406)。然后，目錄服務判斷EBC對象的擁有者是已經(jīng)準許提供所請求的信息，還是拒絕了該請求(步驟407)。如果擁有者不準許提供所請求的EBC對象，則全局目錄進而向請求方409發(fā)送拒絕通知(步驟 408)。在EBC對象的擁有者已經(jīng)準許向請求方提供所請求的信息的情況下，目錄服務進而從其數(shù)據(jù)庫檢索EBC對象(步驟410)。在向請求方409發(fā)送EBC對象之前(步驟412)，目錄服務可以將EBC對象標記為針對請求方的備份聯(lián)系列表的一部分(步驟411)。如從圖4可以看到，在確定了 EBC對象是公開列表的情況下，也是遵循這些步驟。參照圖5，其描繪了根據(jù)本發(fā)明的一個實施例，對于保存在全局目錄內(nèi)的電子商務卡對象的驗證和認證過程500的一種可能的配置。如圖所示，全局目錄配置為向在目錄中注冊的每個用戶發(fā)送提醒，即，每個用戶具有保存在該目錄內(nèi)的EBC對象。根據(jù)步驟502，當接收到該提醒(步驟501)時，用戶有如下選項進行認證和確認、或者決定退出。如果用戶決定退出驗證過程，則該過程結束。在用戶選擇進行驗證過程的情況下，向用戶呈現(xiàn)用于手動或自動驗證的選項(步驟503)。如果用戶選擇手動驗證，則用戶需要物理地連接已認可的全局目錄無線數(shù)據(jù)中心、504 (例如，移動用戶的零售數(shù)據(jù)中心等)，并且提供適當?shù)奈臋n。然后，該無線數(shù)據(jù)中心開始向全局目錄發(fā)送針對該用戶的認證請求(步驟505 )。相比之下，選擇自動認證選項，使得認證請求從用戶的移動設備向全局目錄直接發(fā)送(步驟506)。當接收到認證請求(步驟507)時，全局目錄開始檢查發(fā)送方的證書(步驟508)，來判斷該請求是由無線數(shù)據(jù)中心發(fā)送的還是用戶發(fā)起的(步驟509)。如果該請求是由無線數(shù)據(jù)中心發(fā)送的，則將EBC對象標記為已認證(步驟510)，S卩，包含在EBC中的數(shù)據(jù)已經(jīng)被獨立地驗證和認證。然后，向用戶發(fā)送成功驗證和認證的通知(步驟513)。如果全局目錄確定該請求是由用戶發(fā)送的，則全局目錄開始檢查涉及EBC對象的所有可用數(shù)據(jù)(步驟511)，以驗證并且認證請求方的身份。所述數(shù)據(jù)可以包括，但不限于，在EBC對象和其它已認證的EBC對象之間已建立的鏈路和關系、包含在用戶的互聯(lián)網(wǎng)服務提供商(ISP)或移動服務提供商數(shù)據(jù)庫或者其它第三方數(shù)據(jù)庫(例如，社會網(wǎng)絡中的賬戶信息、公用事業(yè)消費者數(shù)據(jù)庫等)中的信息。如果根據(jù)判斷步驟512，所得到的數(shù)據(jù)是足夠的，則許可該認證請求，并且將EBC對象標記為已認證(步驟510)。然后，向用戶發(fā)送成功驗證和認證的通知(步驟513)。如果根據(jù)判斷步驟512，可用數(shù)據(jù)對于允許全局目錄對該請求方的身份進行驗證和認證而言是不足夠的，則向該請求方轉發(fā)失敗通知(步驟513)。如從上面的討論可知，所述驗證和認證過程被設計為提供如下某個級別的置信度包含在EBC對象中的信息是與EBC對象中所標識的具體個人或實體有關的正確信息。由于全局目錄沒有任何把握肯定在未認證的EBC對象中所含有的信息是準確的，所以用戶所采取與包含在未認證的EBC對象中的信息有關的任何行動是由用戶自己承擔風險的。圖6描繪了根據(jù)本發(fā)明的一個方面，用于將移動設備上本地保存的電子商務卡對象與全局目錄中的相應條目進行同步的過程的一個示例。同步過程是通過用戶向全局目錄發(fā)送同步請求而發(fā)起的(步驟601)。當接收到所述同步請求(步驟602 )時,全局目錄開始檢索在用戶的移動設備上保存的所有EBC對象(步驟603)。一旦全局目錄已經(jīng)從移動設備檢索到EBC對象的列表時，全局目錄開始把所檢索到的EBC對象的列表中的條目與包含在其數(shù)據(jù)庫中的EBC對象進行比較。如圖所示，全局目錄把在所檢索到的EBC對象的列表中的第一條目與保存在其數(shù)據(jù)庫中的每個EBC對象進行比較(步驟604)。如果數(shù)據(jù)庫中沒有給定EBC對象的記錄(步驟605)，則EBC對象被視為手動添加的條目，并且全局目錄跳過該條目(步驟607 )。然后，全局目錄判斷在所檢索到的EBC對象的列表內(nèi)是否有更多的EBC對象要被檢查(步驟611)，并且如果是這樣的，則全局目錄開始對所檢索到的EBC對象的列表中的下一個EBC對象進行檢查(步驟604)。如果在步驟604找到從用戶的設備檢索到的EBC對象的匹配記錄，則全局目錄將所檢索到的EBC中所包含的數(shù)據(jù)與其數(shù)據(jù)庫中所保存的EBC中所包含的數(shù)據(jù)進行比較(步驟606)。如果根據(jù)步驟608，包含在這些EBC對象中的每個EBC對象中的數(shù)據(jù)是相同的，則用戶設備上的EBC中所包含的信息被視為最新的，并且不需要進一步的操作，并且跳過該條目(步驟609 )。然后，全局目錄判斷在所檢索到的EBC對象的列表內(nèi)是否有更多的EBC對象要被檢查(步驟611)，并且如果是這樣的，則全局目錄開始對所檢索到的EBC對象的列表中的下一個EBC對象進行檢查(步驟604)。在步驟608從用戶設備檢索到的EBC對象中所包含的數(shù)據(jù)與在全局目錄中包含的EBC對象中所包含的數(shù)據(jù)不匹配的情況下，目錄把從用戶設備檢索到的EBC中的數(shù)據(jù)視為陳舊的并且需要更新。然后，全局目錄向用戶發(fā)送更新，其包含向用戶的設備發(fā)送更新后的EBC對象(步驟610)。當接收到該更新(步驟612)時，用戶設備上保存的EBC對象中所包含的數(shù)據(jù)被通知中所包含的數(shù)據(jù)覆蓋。然后，全局目錄判斷在所檢索到的EBC對象的列表 內(nèi)是否有更多的EBC對象要被檢查(步驟611)，如果是的話，則全局目錄開始對所檢索到的EBC對象的列表中的下一個EBC對象進行檢查(步驟604)。針對通過全局目錄檢索到的EBC對象的列表中的每個條目，重復如上面詳細描述的同步過程，直至從用戶設備檢索到的EBC對象的列表中沒有條目剩下為止。在成功完全同步的結尾處，系統(tǒng)可以設置檢驗點對象，從而可以遞增地處理后續(xù)同步，與執(zhí)行完全掃描相反。如上面簡述，EBC對象包括多個屬性和方法，圖7A描繪了 EBC對象的一個實施例的結構的概念圖。在該具體示例中，EBC對象包括兩個屬性TOl1JOl2,以及兩種方法702i、7022。如上所述，這些屬性是信息屬性，并且可以與實體虛擬商務卡的不同文字字段相關聯(lián)。在另一方面，所述方法定義了可以對EBC對象實施的操作。為了利用EBC對象結構所提供的面向對象范式(paradigm),申請人已經(jīng)開發(fā)出一種專門的菜單界面。目前大多數(shù)菜單系統(tǒng)是面向過程的，即，菜單系統(tǒng)設計為反映了完成某個具體任務所需要的一系列用戶操作。申請人所提出的菜單界面是以對象為中心的菜單系統(tǒng)，其重點關注用戶可以對具體對象實施哪些操作。圖7B描繪了用于說明在移動手機的上下文中的EBC對象中所保存的信息的菜單系統(tǒng)的示例。在本例中，EBC對象是由菜單系統(tǒng)的菜單引擎讀取的，并且作為電話簿條目703向用戶顯示。為了將EBC對象顯示為電話簿條目，菜單引擎確定分配給EBC對象的“名字屬性”的數(shù)值。如圖7A的示例中所示，EBC對象包含兩個屬性701^70“。這些屬性中的任一個可以被指定為名字屬性。在本例中，第一屬性YOl1是名字屬性，并且包含涉及實體名字(例如，“John Doe”)的相關信息。本例中的第二屬性7012是與該實體的電話號碼相關聯(lián)的。為了易于描述，與一個或多個實體聯(lián)系電話號碼相關聯(lián)的屬性在下文將被稱為電話屬性。就標準電話簿條目項而言，用戶可以自由選擇該項以引出子菜單704。本例中的子菜單704向用戶展現(xiàn)了與EBC對象的相關屬性有關聯(lián)的可用方法的選項。在本例中，方法702!和7022被分配具體任務“呼叫”和“匯款”。本例中的方法702i被分配“呼叫”功能，并且這樣一來，該方法與屬性7012 (即，電話屬性)相關聯(lián)。對菜單顯示器704上的呼叫進行選擇，使得方法702i從電話屬性7012檢索相關的聯(lián)系號碼，并且向相關方發(fā)起呼叫。因此，用戶一方不需要另外的菜單交互來發(fā)起呼叫。類似地，選擇“匯款”選項將使得方法二 7022發(fā)起相關操作，以實現(xiàn)將移動用戶指定的數(shù)量轉移至屬性TOl1JOl2之一所指定的賬戶。如圖所示，子菜單704還包括默認菜單項，“查看細節(jié)” 707。該菜單項允許對其它信息屬性的數(shù)值(比如，可以是電子郵件地址、生日、以及包含在EBC對象的一個或多個屬性中的類似信息)進行查看和編輯。雖然在圖7A和圖7B中所示的例子使用了兩個屬性和方法，但是本領域技術人員應當理解，EBC對象可以包括多個屬性和方法。圖7C描繪了具有多個屬性和方法的EBC對象的結構的概念圖。如圖所示，屬性可以有I到η個，其中η為上限。類似地，所述方法可以有I到m個，其中m為上限。圖7D描繪了由菜單引擎針對具有圖7C所示結構的EBC對象而產(chǎn)生的菜單。與上面討論的示例相同，本例中的菜單引擎翻譯了包含在EBC對象的名字屬性中的數(shù)值，并且將信息以電話簿條目705的形式展現(xiàn)給用戶。選擇條目“John Doe”顯示了包含可用方法
702^70 .....702_J^列表的子菜單706。如圖所示，顯示成菜單項的方法僅限于適合屏幕
的這些數(shù)量的方法減去一個方法。在上述示例中，盡管作為菜單項的5個方法將適合屏幕，但是只示出了與方法I到4 (702^702^702^7020相對應的4個菜單項，以便讓出位置給所需要的菜單項“查看細節(jié)”707。然后，菜單引擎將移動設備上的能夠實現(xiàn)滾動的鍵映射到菜單項的下一個全屏(screen full)。這可以使用方向鍵、內(nèi)置式控制桿、或者任何針對該目的而指定的任何熱鍵。因此，下一個全屏將用顯示方法(m-4)到方法m的上一次可用的屏幕來展示方法5到方法9。根據(jù)申請人提出的菜單系統(tǒng)，也可以向EBC對象提供不可見屬性“上下文(Context)”。所述上下文屬性定義了一組與EBC對象相關聯(lián)的默認屬性和方法。上下文屬性的使用示例在下表I中示出。在該具體例子中，提供了三種上下文類型，每種上下文具有一組默認屬性和方法。表I :針對具體上下文的默認數(shù)量的屬性和方法
上下文 Γ^Ι 人員67
機構45
設備擁有者 65本領域技術人員應當理解，上表僅僅是示意性的，而并非對每個上下文的定義的限制。其也沒有對根據(jù)所提出的菜單系統(tǒng)而能夠定義的上下文的數(shù)量進行限制。圖8Α、圖8Β和圖8C中描繪了針對上述所標識的每個上下文的每個EBC對象結構的概念圖。圖8Α描繪了針對上下文類別“人員”的一種可能的結構。根據(jù)上表1，針對該上下文的EBC對象結構包括六個屬性801 (包括不可見的上下文屬性SOl1)以及7種方法802。針對該上下文所設置的默認屬性包括名字8012和電話8013屬性，如上討論。除了這些屬性以外，EBC對象結構還包括附加屬性(其包括涉及名字屬性中所標識的人員的附加信息)。這些附加屬性可以包括，例如，電子郵件屬性8014、網(wǎng)站屬性8015、博客屬性8016。屬性801中的每一個可以與一種或多種方法802相關聯(lián)。如圖所示，根據(jù)“人員”上下文所設置的七種方法包括如下動作發(fā)送消息、呼叫8022、訪問網(wǎng)站8023、閱讀博客8024、搜尋(poke)8025、匯款8026、以及默認的查看細節(jié)8027。各種方法與各種屬性的關聯(lián)性將在下文中更詳細地討論。圖SB描繪了針對上下文類別“機構”的一種可能的EBC對象結構。如圖所示，針對這具體上下文的EBC對象結構包括四個屬性801和5種方法802。針對該具體上下文所設置的屬性801包括名字8012、電話8013、電子郵件8014、以及不可見的上下文屬性801:。在本例中，與屬性801相關聯(lián)的方法802，除了包括默認的查看細節(jié)方法8027以外，還包括的發(fā)送消息802i和呼叫8022，和在“人員”上下文中設置的一樣。除了這些方法之外，“機構”上下文包括具體針對機構上下文的一些方法，在該具體示例中，這些上下文具體方法是“觀察目錄” 80 28和“位置”8029方法。如名字所建議的，“觀察目錄”8028方法設置為允許用戶查看針對相關聯(lián)的名字屬性中所標識的機構的相關產(chǎn)品目錄，而“位置”8029方法提供 了與相關聯(lián)的名字屬性中所標識的相關機構的位置有關的信息。圖SC中描繪了針于上下文“設備擁有者”的一種可能的EBC對象結構。如上表I中所規(guī)定的，設備擁有者上下文包含六個屬性801和五種方法802。因此，設備擁有者上下文的關注焦點更多集中在信息屬性801上，而較少集中在方法802上。如圖所示，根據(jù)設備擁有者上下文而設置的信息屬性801類似于根據(jù)人員上下文而設置的信息屬性。在本例中，設備擁有者上下文，除了包括不可見上下文屬性SOl1以外，還包括名字8012、電話8013、電子郵件8014、網(wǎng)站8015、以及博客8016屬性。根據(jù)該具體上下文而設置的方法802可以包括，例如，閱讀備忘錄8021(|、管理金錢802n、檢查計劃80212、以及寫博客80213。如上面討論的上下文的例子，設備擁有者上下文還包含默認的查看細節(jié)802方法。從以上示例可見，每個具體的EBC對象上下文定義了一組默認的屬性和方法。因此，將容易推斷出由于具體上下文具有一組默認的屬性和方法，所以針對每個具體上下文的EBC對象而形成的菜單系統(tǒng)將是相同的。然而，并不是相同上下文的所有EBC對象都將使所有的屬性字段完全填充。為了確定哪些方法是將要向所給定的EBC對象的用戶顯示的，菜單引擎使用了服務發(fā)現(xiàn)過程。本質上，菜單引擎將屬性與方法的映射進行比較。服務發(fā)現(xiàn)過程的示例在圖9中示出。如圖所示，菜單引擎首先判斷映射到該方法的屬性是否存在(步驟901)。如果該屬性不存在，則該方法被標記為不可用(步驟902)，反之，如果該屬性存在，則該方法被標記為可用(步驟903)。然后，菜單引擎判斷是否還有針對具體EBC對象的其它方法要被檢查(步驟904)，如果有的話，則菜單引擎重復過程步驟901、902或903 (取決于方法的可用性)，直至沒有其它方法要被檢查為止，此時，菜單引擎產(chǎn)生僅包含如下菜單項的菜單所述菜單項與標記為對于所給定的EBC對象為可用的那些方法相對應(步驟905)。舉一個例子，考慮上下文“人員”的EBC對象。根據(jù)該上下文，EBC對象包括與博客屬性相映射的“閱讀博客”方法。所述博客屬性可以使其取值為博客URL或者為空。該取值正是菜單引擎在步驟901期間讀取的用來判斷該屬性是否存在的數(shù)值。如果該博客屬性為空，則“閱讀博客”方法不作為與EBC對象相關聯(lián)的菜單系統(tǒng)的一部分。另一方面，如果有與博客屬性相對應的數(shù)值，則“閱讀博客”方法成為與該具體EBC對象相關聯(lián)的菜單系統(tǒng)中的菜單項。雖然隨著電話簿中的條目被手動建立，上述服務發(fā)現(xiàn)過程是即時地執(zhí)行的，但是由此形成的菜單系統(tǒng)并不是靜態(tài)的。菜單引擎可以允許如下更新所述更新能夠改變針對具體EBC對象的菜單的外觀。這些更新可以由下列事件中的任一項觸發(fā) 來自信息擁有者的廣播·電話簿條目的共享·與全局目錄服務同步(如上所述) 來自信息擁有者的廣播是在信息擁有者使用移動網(wǎng)絡來發(fā)出屬于該具體信息擁有者的EBC對象的已更新副本時發(fā)生的。信息擁有者是局限于移動設備上的如具有“設備擁有者”的上下文的EBC對象。向這些信息擁有者提供特定工具，以更新并且甚至改變或者更改與EBC對象相關聯(lián)的屬性和方法。與該EBC對象相關聯(lián)的一組默認的屬性和方法被該用戶自定義撤銷。在圖IOA所示的示例中，信息擁有者(人員A)已經(jīng)編輯過他們的EBC對象的細節(jié)，使得其包括新的屬性和方法。在本具體示例中，人員A已經(jīng)將兩個新的屬性“社會網(wǎng)絡” IOOl1和“聊天” IOOl2添加到不可見上下文屬性SOl1、名字8012、電話8013、電子郵件8014、網(wǎng)站8015、以及博客SOl6屬性的默認屬性字段。同樣，兩種新方法(查看社會網(wǎng)絡KK^1、和聊天10022)已經(jīng)添加到針對設備擁有者上下文的默認方法的列表，即，閱讀備忘錄8021(|、管理金錢802n、檢查計劃80212、以及寫博客80213。由于本領域技術人員應當理解，雖然人員A的EBC對象在本地被視為屬于“設備擁有者”上下文，但是其被其它人員的設備視為屬于上下文“人員”。因此，站在人員B的設備來看，人員A的EBC對象是至少具有上面討論的人員上下文的默認屬性和方法的EBC對象。只要涉及人員B，屬于人員A的EBC對象就將會保留，但沒有屬性“社會網(wǎng)絡”和“聊天”，因而沒有方法“查看社會網(wǎng)絡”和“聊天”，直到最新的人員A的EBC對象出現(xiàn)為止，即，人員B的菜單引擎允許通過接收來自信息擁有者的廣播、與人員A共享電話簿條目、或者人員B請求將他們的EBC對象的列表與全局目錄服務進行同步，來進行更新(如上面關于圖6的討論)。共享EBC對象是點對點的，而廣播可以是定向廣播或者簡單廣播。定向廣播是將他的EBC對象向一群接收者同時發(fā)送，這群接收者通常選自人員A的電話簿或者任何已定 義的接收者列表。在另一方面，簡單廣播向已定義的地理區(qū)域內(nèi)的所有可能的接收者發(fā)出EBC0在這兩種情況下，效果是相同的已更新的EBC對象的接收者將有選擇權，以保存該更新或者拒絕它。如果接收者選擇接受所述已更新的EBC，則菜單引擎將即時地(B卩，當使用如圖IOB所示的已更新的EBC對象時)發(fā)起菜單更新。在相同的示例中，如果接收者確定通過他的電話簿來訪問已更新的EBC，則菜單引擎以通過與如圖9所示相似的服務發(fā)現(xiàn)過程所描繪的過程非常相似的方式來更新菜單系統(tǒng)。除了菜單更新，菜單引擎還可以對這些方法作為菜單項展現(xiàn)的方式進行重新布置。針對每個EBC對象，這些方法是根據(jù)下列準則來劃分等級的·交易成功·交易的頻率·交易的費用
·其它商業(yè)規(guī)則除了上述內(nèi)容，根據(jù)上述服務發(fā)現(xiàn)過程，已經(jīng)標識為不可用的方法將不再作為菜單系統(tǒng)的一部分示出，即，不存在與引起不可用服務的方法相對應的菜單項。這種菜單項的適應性重新布置是在多級菜單系統(tǒng)的所有級別處進行的。因此，屬于同一上下文的兩個EBC對象將不具有同樣的一組菜單項布置。根據(jù)設備擁有者與對象交互的方式，每個EBC對象將具有不同的菜單項布置。還包括另一個準則，使得在用戶交互中尚未使用一段預設時間段的那些EBC對象，將具有基于相似上下文類別的EBC對象的常用統(tǒng)計數(shù)據(jù)的默認布置的菜單項。菜單系統(tǒng)也可以采用掩碼功能，以允許用戶在無需具體識別每個個體的情況下與不同個體交互。掩碼功能利用了叫做“群組”上下文的上下文類別?！叭航M”上下文進一步劃分為局部類或全局類。上下文“局部群組”的EBC對象是用作在用戶設備本地保存的一 群EBC對象的別名(alias)的那個EBC對象。對該別名的任何操作是對鏈接到該局部群組別名的所有EBC對象的操作。但是，該操作將限于那些可以在群組中完成的那些，比如發(fā)送SMS。圖11描繪了針對局部群組上下文的使用掩碼功能的示例。如圖所示，SMS 1101是使用局部群組別名1102來處理的。掩碼功能開始向局部群組中所包含的EBC對象1103i、11032、11033、11034中所標識的每個個體發(fā)送SMS。可以類似地實現(xiàn)上下文“全局群組”的EBC對象。但是，“局部群組”和“全局群組”的區(qū)別是“局部群組”是由設備擁有者通過對位于設備上的EBC對象進行掩蔽而在設備上創(chuàng)建的，而“全局群組”是來自全局目錄服務的EBC對象(其用作指向其它EBC對象的指針)。在“局部群組”中的已掩蔽EBC對象對于設備擁有者而言是已知的，因為這些已掩蔽對象的實例是被假定為保存在設備中的，而“全局群組”中的已掩蔽EBC對象對于設備擁有者而言不是已知的?！叭秩航M”中的已掩蔽EBC對象是保存在目錄服務數(shù)據(jù)庫中的。圖12描繪了使用掩碼功能來向局部或全局群組上下文中的EBC對象發(fā)送消息。如圖所示，用戶向群組上下文別名發(fā)送SMS (步驟1201)。然后，掩碼功能開始檢查該群組上下文屬性是否為局部群組(步驟1202)。如果確定該群組為局部群組，則掩碼功能開始讀取掩蔽指針屬性(其標識了包含在該群組中的所有EBC對象K步驟1204)。然后，掩碼功能開始從EBC對象的局部列表抽出EBC對象(步驟1205)，并且向已抽出的EBC對象所標識的每個個體發(fā)送SMS (步驟1206)。在該群組為全局群組的情況下，掩碼功能向全局目錄服務轉發(fā)SMS (步驟1203)。然后，全局目錄服務開始讀取掩蔽指針(步驟1204)，以便從其數(shù)據(jù)庫中抽出相關的EBC對象(步驟1205)。一旦全局目錄已經(jīng)抽出包含在該群組中的EBC對象，其隨后開始向已抽出的EBC對象所標識的每個個體轉發(fā)SMS (步驟1206)。應當理解，上述實施例僅僅是通過本發(fā)明的示例的方式來提供的，并且對于相關領域的技術人員而言，對本發(fā)明的進一步修改和改進明顯將被視為落入本文所述的本發(fā)明的廣義范圍和界限之內(nèi)。
權利要求
1.一種用于在多個網(wǎng)絡用戶之間傳輸聯(lián)系信息的方法，所述方法包括下列步驟 在用戶終端處將所述聯(lián)系信息編譯到電子商務卡中； 向目錄注冊所述電子商務卡，其中，所述注冊電子商務卡的步驟進一步包括 通過將所述電子商務卡的文字字段映射到包含在電子商務卡對象中的一個或多個屬性，來將所述電子商務卡封裝到所述電子商務卡對象中； 向所述目錄發(fā)送所述電子商務卡對象；以及 將所述電子商務卡對象保存在數(shù)據(jù)庫中； 在所述目錄處接收來自用戶的一組搜索參數(shù)； 向所述數(shù)據(jù)庫搜索與所述搜索參數(shù)相匹配的電子商務卡對象； 向所述用戶提供電子商務卡對象的列表； 在所述目錄處接收來自所述用戶的針對來自所提供的電子商務卡對象的列表中的電子商務卡對象的請求；以及 向所述用戶轉發(fā)所請求的電子商務卡對象。
2.如權利要求I所述的方法，其中，所述注冊的步驟進一步包括確認一組用戶證書的步驟。
3.如權利要求2所述的方法，其中，所述用戶證書包括請求方的移動電話號碼、和/或在無需所述請求方主動知曉或者參與的情況下能夠從所述請求方獲得的任何這類信息。
4.如權利要求2所述的方法，其中，所述用戶證書包括以下至少一個PIN、密碼、和/或一方必須明確提供的任何這類信息。
5.如前述權利要求中的任一項所述的方法，其中，所述搜索參數(shù)是一組關鍵詞。
6.如權利要求5所述的方法，其中，所述接收所述搜索參數(shù)的步驟進一步包括在發(fā)起所述搜索之前，對所接收到的關鍵詞進行解析的步驟。
7.如前述權利要求中的任一項所述的方法，其中，所述提供電子商務卡對象的列表的步驟進一步包括對所述搜索結果進行分類和/或過濾的步驟。
8.如權利要求7所述的方法，其中，對所述電子商務卡對象的列表進行分類是根據(jù)下列中的一項賦給對象的已驗證狀態(tài)的權重；作為對象的屬性的已確認關系；關鍵詞匹配精度的級別；信息的新近程度；或者布爾運算。
9.如前述權利要求中的任一項所述的方法，進一步包括允許用戶或者任何已授權方更新或者刪除所述電子商務卡對象的所述屬性中的任何一個的步驟。
10.如權利要求9所述的方法，其中，所述對電子商務卡對象的屬性和/或方法進行更新的步驟是通過多個用戶界面執(zhí)行的。
11.如權利要求10所述的方法,其中，所述用戶界面包括以下至少一個web或者wap界面、局部應用、或者使用電子郵件、SMS、麗S、flash消息、或IP技術的菜單系統(tǒng)。
12.如前述權利要求中的任一項所述的方法，進一步包括接收來自用戶的針對同步的請求的步驟。
13.如權利要求12所述的方法，其中，所述同步的步驟進一步包括如下步驟 驗證被請求進行同步的所述電子商務卡對象是否存在； 驗證被請求進行同步的所述電子商務卡對象的隱私或者訪問級別設置； 根據(jù)電子商務卡對象的所述隱私或者訪問級別設置，向被請求進行同步的所述電子商務卡對象的擁有者發(fā)送可操作通知，用于允許或者不允許所述請求； 當允許所述同步請求時，向請求用戶發(fā)送被請求進行同步或進行下載的所述電子商務卡對象的同步更新或者副本；以及向所述請求方發(fā)送合適的通知。
14.如前述權利要求中的任一項所述的方法，進一步包括對所述電子商務卡對象的內(nèi)容進行驗證和認證的步驟。
15.如權利要求14所述的方法，其中，所述驗證和認證的步驟進一步包括下列步驟 當成功驗證或者認證電子商務卡對象中的數(shù)據(jù)時，將所述被請求進行驗證的對象標記為已認證；以及 向有關方發(fā)送合適的通知。
16.如權利要求14所述的方法，其中，所述驗證和認證的步驟進一步包括下列步驟 通過置信水平評分來驗證所述電子商務卡對象；以及 隨后將產(chǎn)生與預先定義的閾值相比相等或者更大的置信水平的那些對象標記為已驗證。
17.一種用于促進在網(wǎng)絡用戶之間傳輸聯(lián)系信息的系統(tǒng)，所述系統(tǒng)包括 耦合到所述網(wǎng)絡的至少一個服務器； 耦合到所述服務器的至少一個數(shù)據(jù)庫； 耦合到所述網(wǎng)絡的多個用戶終端，其中，每個用戶的終端配置為響應于用戶的請求，向所述服務器發(fā)送與所述用戶相關聯(lián)的聯(lián)系信息；其中，所述請求使得所述用戶的終端將所述聯(lián)系信息編譯到具有一個或多個文字字段的電子商務卡對象，并且將所述電子商務卡的所述一個或多個文字字段映射到包含在電子商務卡對象中的一個或多個對象屬性，并且向所述服務器發(fā)送所述電子商務卡對象，以便保存在所述數(shù)據(jù)庫中。
18.如權利要求17所述的系統(tǒng)，其中，每個用戶終端包括菜單引擎，該菜單引擎適用于讀取包含在所述電子商務卡對象中的每個對象屬性，并且顯示包含菜單項的多個菜單，所述菜單項表示能夠執(zhí)行的與所述電子商務卡對象所表示的聯(lián)系信息有關的一個或多個功倉泛。
19.如權利要求18所述的系統(tǒng)，其中，為所述電子商務卡對象分配了上下文，并且所述菜單引擎適用于產(chǎn)生針對所分配的上下文的一組默認菜單項。
20.如權利要求19所述的系統(tǒng)，其中，所述菜單引擎適用于響應于所述電子商務卡對象擁有者對所述電子商務卡對象的一個或多個對象屬性的修改，修改針對所述上下文的所述一組默認菜單項。
全文摘要
本申請公開了一種用于促進在網(wǎng)絡用戶之間傳輸聯(lián)系信息的系統(tǒng)和方法，所述系統(tǒng)包括耦合到所述網(wǎng)絡的至少一個服務器；耦合到所述服務器的至少一個數(shù)據(jù)庫；耦合到所述網(wǎng)絡的多個用戶終端，其中，每個用戶的終端配置為響應于用戶的請求，向所述服務器發(fā)送與所述用戶相關聯(lián)的聯(lián)系信息；其中，所述請求使得所述用戶的終端將所述聯(lián)系信息編譯到具有一個或多個文字字段的電子商務卡對象中，并且將所述電子商務卡的一個或多個文字字段映射到包含在電子商務卡對象中的一個或多個對象屬性，并且向所述服務器發(fā)送所述電子商務卡對象，以便保存在所述數(shù)據(jù)庫中。
文檔編號G06F17/00GK102713892SQ201080060581
公開日2012年10月3日 申請日期2010年12月15日 優(yōu)先權日2010年1月4日
發(fā)明者A·D·伊巴斯克, E·R·G·杰森, J·L·L·洛桑托斯, V·G·巴雷斯 申請人:斯瑪特哈伯私人有限公司