TWI565292B - 用以於接收方裝置上顯示來源之識別符的系統與方法 - Google Patents

Description

用以於接收方裝置上顯示來源之識別符的系統與方法 發明領域

本發明係關於在接收方裝置上顯示來源之識別符的系統與方法。本發明尤其但非唯一地適於在接收方行動電話上顯示識別符，諸如呼叫者之呼叫者ID。

發明背景

以下對本發明背景之論述僅意欲促進對本發明之理解。應瞭解，此等論述並非承認或認同：截至本發明之優先權日，於任何管轄權領域中，所引用之任何內容已被公開、為已知或為熟悉此項技術者的公知常識之部分。

公眾交換電話網路(PSTN)號碼通常指派給實體線路，且彼號碼保持不變。類似地，行動電話號碼則指派給用戶識別模組(SIM)。

一種指派PSTN號碼及行動電話號碼之已知方法係基於E.164 ITU-T建議案，其定義在PSTN及其他資料網路中使用之電話號碼及國際公用電信編號計劃的格式。

然而，存在著對可提供電話號碼之動態及臨時分配之服務的感知需要，該分配要能允許建立源呼叫者針對不同接收方之不同識別符。

儘管行動電話之使用者可利用呼叫者ID及呼叫清單，但此等特徵僅為參考性(informational)，且需要使用者主動地更新及將呼叫者關聯至聯絡人，諸如藉由將每一呼叫者 之號碼儲存於聯絡簿或電子電話簿中。在呼叫者ID系統中，在呼叫者與被呼叫者之間不存在主動連結或自動關聯。

一種在呼叫者與被呼叫者之間建立關聯的已知方法為建立「社交連接」或社交連結。然而，歸因於信任/安全問題，此種系統受到限制且限定於相同網路內之呼叫者及接受呼叫者。

此外，雖然切斷呼叫者ID選項或遮蔽電話號碼為可能的，但許多當前電話及電話系統歸因於終端使用者之可能濫用而並不支援號碼遮蔽。

本發明尋求減輕或減少以上提及之缺點。

發明概要

根據本發明之第一態樣，提供一種用以於與來源通訊之接收方裝置上顯示來源的識別符之系統，該系統包含：一關聯資料庫，其定義與接收方裝置關聯之至少一來源之清單；及一處理管理器，其經佈置來處理來源與接收方裝置之通訊，且經佈置來存取該關聯資料庫以便判定來源是否與接收方裝置相關聯，及若是，則顯示來源的已建立識別符，否則判定來源之隱私設定且根據已判定隱私設定而於接收方裝置上顯示另一識別符。

較佳地，處理管理器與來源及/或接收方裝置整合在一起。

較佳地，此系統進一步包含基於位置的服務(LBS；適地性服務)以便判定來源位置。有利的是，LBS經進一步組 配來判定最接近來源位置之LBS之登記使用者的數目。

較佳地，接收方裝置為行動裝置。有利的是，接收方裝置包含用於判定來源是否被列入監視名單或黑名單之系統日誌。有利的是，在判定該來源被列入監視名單或黑名單時，即分別終止由來源起始之通訊，或觸發告警，其後終止該通訊。

較佳地，處理管理器經調適以於判定來源及接收方裝置不在相同通訊網路內時，則與外部閘道器進行資料通訊，以安排路由傳遞來自來源之通訊至接收方裝置。

較佳地，處理管理器經佈置來存取網路通訊錄以便判定來源是否與接收方裝置關聯。

較佳地，基於來源是否被公開列出、未被列出或使其識別符被遮蔽，來判定來源之隱私設定。

根據本發明之第二態樣，提供一種用以於與來源通訊之接收方裝置上顯示來源的識別符之方法，其包含以下步驟：a.定義與接收方裝置關聯之至少一來源之清單；b.處理自來源至接收方裝置之通訊；及c.自該清單判定該來源是否與該接收方裝置關聯；且若是，則顯示該來源的已建立識別符，否則，判定該來源之隱私設定，且根據已判定之隱私設定在接收方裝置上顯示另一識別符。

較佳地，判定來源之隱私設定之步驟包括判定來源是否未被列出或使其識別符被遮蔽。

較佳地，若判定來源及接收方裝置位於相同通訊網路內，則該方法進一步包括檢查來源是否被列入通訊網路內 的黑名單或監視名單之步驟。

較佳地，若來源未被列入黑名單或監視名單，檢查接收方裝置之隱私設定以便判定來源之識別符是否可被顯示在接收方裝置上。

較佳地，若來源被列入監視名單，則觸發告警且終止來源與接收方裝置之通訊。

較佳地，若來源被列入黑名單，則立即終止來源與接收方裝置之通訊。

較佳地，該方法包括在來源與接收方裝置之間建立路由之步驟，其中該路由建立步驟包括檢查來源之識別符屬性以便判定識別符如何得來。有利地，檢查識別符屬性之步驟包括判定識別符是否被進送、下載或人工輸入至來源。

較佳地，該方法包括判定來源及接收方裝置是否在相同通訊網路內之步驟，及若已判定來源及接收方裝置不在相同通訊網路內則安排路由傳遞來自來源之通訊。

較佳地，判定在來源與接收方裝置之間是否存在關聯之步驟包括存取網路通訊錄。

根據本發明之第三態樣，提供一種接收方裝置，其包含經佈置來處理自來源至接收方裝置之通訊的處理管理器；該處理管理器經佈置來存取關聯資料庫以便判定來源是否與接收方裝置關聯，該關聯資料庫定義與接收方裝置關聯之至少一來源之清單；其中，在判定來源與接收方裝置關聯時，即顯示來源的已建立識別符，且在判定來源不與接收方裝置關聯時，即判定來源之隱私設定，且根據已 判定之隱私設定於接收方裝置上顯示另一識別符。

圖式簡單說明

現將參看隨附圖式，僅藉由說明性實例來描述本發明，其中：第1圖為根據本發明之實施例的系統方塊圖。

第2圖為圖示根據本發明之實施例的發給接收方之電話呼叫的處理之流程圖。

第3圖為圖示根據本發明之實施例的發給接收方之電話呼叫的路由安排之流程圖。

第4圖為圖示自來源至預期接收方之電話呼叫起始的流程圖，該來源在使用本發明之實施例的相同網路內。

第5圖為圖示自來源至不同網路中預期接收方之電話呼叫起始的流程圖，及第6圖為圖示本發明之實施例可如何結合基於位置之服務用作「緊急狀況」工具的流程圖。

較佳實施例之詳細說明

根據圖示於第1圖中的本發明之實施例，存在用以於接收方裝置14上顯示來源12之識別符的系統10。作為實例，來源12及接收方14為行動裝置。來源12之識別符可為分配給來源12之行動電話號碼，或由系統10分配給來源12之任何其他號碼或ID。

系統10包含一經調適來處理諸如自來源12至接收方裝置14之電話呼叫之通訊的處理管理器16。處理管理器16可 與來源12及/或接收方14整合，例如處理管理器16可包括正在使用之行動裝置12、14中之一者或兩者。

該系統進一步包含關聯資料庫20及號碼遮蔽資料庫22。關聯資料庫20通常為一號碼詢查及管理資料庫。關聯資料庫20定義與接收方裝置關聯之來源之清單。

處理管理器16係佈置來存取關聯資料庫20以便判定來源12是否與接收方裝置14關聯。

關聯資料庫20進一步包含號碼解析資料庫24。號碼解析資料庫24解析來自呼叫之來源12之任何撥號號碼，以便判定該號碼是否在接收方14之社交網路內。號碼遮蔽資料庫22連接至外部閘道器26用於安排路由傳遞外部呼叫。自系統10中依路由傳遞之任何電話號碼遭遮蔽，以便與諸如E.164 ITU-T建議案之國際標準相容。

關聯資料庫20進一步維持系統10內所有用戶之網路通訊錄27。網路通訊錄27連結至號碼遮蔽資料庫22及號碼解析資料庫24。網路通訊錄27係組配來進一步建立/更新系統10內用戶之間的社交連結。此可藉由在通訊錄27與用戶之行動裝置本地電話簿之間執行定期同步化而達成。

當自來源12產生一呼叫時，自一號碼範圍動態產生一號碼，該號碼範圍被擬定以用於該目的。該號碼之動態產生可在該號碼範圍之界限內為隨機的。將所產生號碼添加至關聯資料庫20。關聯資料庫20提供原始電話號碼與動態產生(亦即，遮蔽)之電話號碼之對映。查詢號碼解析資料庫24以判定呼叫之發起者。此佈置保證來自呼叫之來源12之原 始電話號碼被遮蔽，且僅服務營運者知道該對映。該佈置進一步允許接收方裝置14禁止任何一方在詢查時呼叫他/她。

處理管理器16亦可包含一支援對映、解除對映及指派或管理該系統之客戶端介面。

來源行動裝置12可為此項技術中已知之任何行動裝置。

接收方行動裝置14經調適來允許使用者具有經由黑名單阻止來源之選項，賦予針對特定來源設定告警及旗標之設施(即監視清單)；或具有切離社交網路連接之選項。接收方裝置14經進一步組配來允許禁止電話呼叫。

接著就處理由呼叫之來源12(自此可互換地稱作呼叫者12)對接收方14起始之電話呼叫(步驟200)的情境來描述該實施例。作為實例，呼叫/撥號號碼為來源的識別符。

處理管理器16經由號碼解析資料庫24檢查撥號號碼是否在呼叫者12之社交網路內(步驟202)。該檢查涉及在網路通訊錄27上比較呼叫者12及接收方14兩者之聯絡簿或電子電話簿，以便驗證呼叫者12及接收方14有社交連接(步驟204)。進一步之驗證可包括判定呼叫者12與接收方14是否有先前通訊。

若基於步驟204判定呼叫者12及接收方14有社交連接，則呼叫即建立且連接(步驟206)。另一方面，若判定呼叫者12及接收方14未社交連接，則可能意味呼叫者12及接收方14無先前通訊，或撥號號碼藉由下載之號碼簿、進送之名片或人工輸入而剛被添加。在該狀況下，檢查呼叫者 12之隱私設定(步驟208)。該檢查涉及判定來源12是否未被列出(步驟210)或隱私設定是否阻止呼叫者之號碼顯露。若呼叫者之號碼未被列出，則該號碼利用系統指派之資訊而遮蔽，該資訊至少具有該號碼受遮蔽之指示(步驟212)。經遮蔽號碼接著變為呼叫者12之號碼，其接著將顯示於接收方裝置14上。

另一方面，若來源12之隱私設定不要求匿名，則已針對呼叫者12設定之較佳呼叫者之身份即與此呼叫關聯(步驟214)。此較佳身份將顯示於接收方裝置14上。

在步驟212或步驟214後，系統10接著檢查呼叫者12及接收方14是否位於相同行動通訊網路內(步驟216)。若其並不位於相同行動通訊網路內，則該呼叫需接受安排路由傳遞至外部閘道器26而至外部網路，其可為並非藉由本發明之系統啟用之獨立網路。在此情形下，該呼叫藉由與呼叫關聯之呼叫者之識別(步驟218)來安排傳遞路由(步驟222)。該路由安排涉及通過外部閘道器26，其涉及將系統10之內部傳訊協定轉譯為與外部通訊網路之PSTN、ISDN相容之協定。

然而，若確定呼叫者12及接收方14位於相同行動通訊網路中，則檢查系統日誌(步驟220)。該系統日誌可駐留於接收方裝置14中或存在於外部伺服器中。檢查該系統日誌以下內容：

a.呼叫者12是否在監視清單中(步驟224)，若判定呼叫者12在監視清單中，則告警或訊息可經觸發以便起始呼叫 追蹤或相似選項，從而告知要求呼叫追蹤之一方(步驟226)。其後，該呼叫被終止(步驟228)。

b.若判定呼叫者12不在監視清單內，則檢查系統日誌看看呼叫者12是否在黑名單內(步驟230)。若是，則阻斷呼叫者12且立即終止該呼叫(步驟228)。然而，若判定呼叫者12並非黑名單內之聯絡者，則檢查接收方裝置14之隱私設定(步驟232)，以便查看是否允許匿名呼叫或來自接收方之社交網路以外的呼叫者12之呼叫(步驟234)。若隱私設定並不允許匿名呼叫或來自接收方之社交網路外的呼叫，則呼叫被終止(步驟228)。另一方面，若接收方允許匿名呼叫或來自接收方之社交網路外的呼叫，則建立路由(步驟236)且連接呼叫(步驟206)。

呼叫之路由安排(步驟236)為一包含以下步驟之過程：該過程開始先檢查撥號號碼之屬性(步驟302)，其包括檢查該撥號號碼是否經由例如電子名片之分享而進送自朋友(步驟304)，是否例如自中央號碼簿服務下載(步驟306)，(或人工鍵入(步驟308)。

若自步驟304由系統10判定該撥號號碼進送自朋友，則該系統10在網路通訊錄27中自朋友的電話簿項目傳輸共用資訊(步驟310)。其後，建立各方之間的社交網路(步驟312)。

若自步驟304由系統10判定撥號號碼並非進送自朋友，則該系統10檢查該撥號號碼是否經下載(步驟306)。

若自步驟306認為該撥號號碼為經下載的，則使用中央號碼簿服務中之預設呼叫者識別資訊項目(步驟314)。其 後，建立各方之間的社交網路(步驟312)。

若自步驟306由系統10判定撥號號碼並非經下載的，則該系統10檢查該撥號號碼是否為人工輸入(步驟308)。

若自步驟308判定撥號號碼為人工輸入，則系統10檢查共通節點，即網路通訊錄27中經識別之共通朋友。該系統接著驗證撥號號碼是否在共通節點中為唯一的(步驟318)，若為唯一的，則使用該號碼及關聯呼叫資訊(步驟320)。另一方面，若該撥號號碼並非唯一，即存在重複號碼；則系統使用預設中央號碼簿呼叫資訊以便建立社交網路連接(步驟314)。

若自步驟308判定撥號號碼並非人工輸入，則該系統邏輯上假定資料已駐留於接收方裝置14中，且因此為先前與接收方14之社交網路連接的結果。若未能落入由步驟304、306及308所檢查之任何分類，則表示：在該呼叫之前的某時間，接收方14已切離其與呼叫者12之社交網路連接(322)。此可歸因於以下理由中之一或多者：黑名單、監視清單、社交取消或僅基於緊迫狀況，諸如清出電子電話通訊錄中空間之需要，或甚至平凡之事，如接收方認為已無與呼叫者保持社交連接之感知需要等。

基於以上邏輯，系統10繼續檢查呼叫者12是否被列入黑名單(步驟324)或監視清單(步驟328)。若判定被列入黑名單或監視清單，則終止該呼叫(步驟326)或觸發一告警(步驟330)，其後相應地終止該呼叫。

當呼叫者12位於相同行動通訊網路內時，系統10執行 如第4圖圖示之以下步驟，以便建立或安排路由傳遞該呼叫。

當產生該呼叫時(步驟402)，檢查與預期接收方裝置14關聯之社交網路，看看呼叫號碼是否為預期接收方14之社交網路中之節點(步驟404)。依預設，將該呼叫安排路由傳遞至社交網路中之識別節點。若預期接收方14號碼不在來源之社交網路中，則檢查電話網路看看預期接收方14是否在相同網路中(步驟406)。若預期接收方14在相同網路中，則依來源12之指定，遮蔽來源12之電話號碼(步驟408)，且建立起呼叫(步驟410)。

若判定預期接收方14在不同網路內，則系統10檢查接收方14是否為未被列出之號碼(步驟412)，且若接收方14為未被列出之號碼，則系統10發送網路ID資訊(步驟416)且安排路由傳遞該呼叫(步驟418)。若接收方14並非未被列出之號碼，則發送呼叫者ID資訊而非網路ID資訊(步驟420)且安排路由傳遞該呼叫(步驟418)。應瞭解，即使呼叫者12為他或她的號碼指定一遮蔽，若他或她先前曾與預期接收方14連接，則該指定之遮蔽將被來自先前建立連接之資訊所覆寫。作為實例，若呼叫者12與接收方14先前即有聯繫(即，建立社交連接)，其中呼叫者12使用號碼n；且呼叫者12隨後切離他或她與接收方14之連接，且呼叫者接著嘗試使用另一不同的指定號碼x與接收方14重新連接，則此號碼x將被n覆寫，且接收方14仍將看到呼叫者12之號碼為n而非新號碼x。應瞭解，由於社交分組不同，該呼叫者12之號碼將與社交群 組AC中另一接收方C不同。

在發話呼叫者12來自外部網路且接收方裝置14在網路內的狀況下，系統10執行如第5圖圖示的以下步驟，以便建立、終止或執行與該呼叫有關之任何任選動作。

在起始該呼叫後(步驟502)，隨即檢查呼叫者12之隱私設定(步驟504)。檢查呼叫者12之隱私設定之方式的實例涉及檢查該呼叫12是否被公開列出(步驟506)。若呼叫者12揭示呼叫者識別或被公開列出，則呼叫被連接(步驟522)。然而，若呼叫者12扣住呼叫者識別，以致未被公開列出，則檢查系統日誌(步驟508)以便判定呼叫者12是否在黑名單上(步驟510)。若呼叫者12之號碼被列入黑名單，則終止該呼叫(步驟512)，且系統10具有執行進一步動作之選項，諸如起始呼叫追蹤或發送告警(步驟514)至任何被提名之緊急聯絡者或社交聯絡者。

在判定呼叫者12之號碼未被列入黑名單時，隨即檢查接收方之隱私設定(步驟516)。檢查被呼叫方14且若匿名呼叫被接受(步驟518)，則該呼叫被系統記錄(步驟520)且隨後被連接(步驟522)。另一方面，若該被呼叫方並不接受匿名呼叫(匿名來電)，則該呼叫被立即終止(步驟512)。再次，系統具有執行特定進一步動作之選項，諸如起始呼叫追蹤或發送告警(步驟514)。

當呼叫被記錄時(步驟520)，系統10把呼叫號碼與被呼叫號碼配對。該配對變為一虛擬社交網路連接，以致在來自相同呼叫者12之隨後呼叫中及在檢查日誌時發現無貶損 性資訊(亦即位於黑名單中)存在的情形下，該呼叫已被連接至被呼叫方。然而，位於使用本發明之網路內部之預期接收方14，具有在任何時間將來源12放入黑名單及斷開或切離社交網路連接的選項。

以上描述之實施例亦可在緊急狀況(ICE)工具的狀況下結合基於位置之服務(LBS)使用。在描述於第6圖之說明性實例中，假定某些使用者報名參加緊急求助服務之志願者。用於此之商業規則可由監督緊急求助服務電話號碼或求助熱線(HELPline)之組織來定義。

該求助熱線程序由遇險終端使用者發起。變為呼叫者或來源12之此終端使用者呼叫指定求助熱線號碼，該求助熱線號碼在此實例中為4357，此對應於常規電話小鍵盤中之HELP(步驟602)。應瞭解，若為911呼叫，則該呼叫將被安排路由傳遞至911電話中心。然後，緊急求助服務系統調用LBS且判定來源12之位置(步驟604)。

處理管理器16繼續檢查其志願者資料庫(已知為援助群組)，且獲取其位置(步驟606)。在封閉性求助團體之狀況下，即使用者定義哪些號碼將與求助呼叫關聯，系統及LBS檢查志願者人員庫(pool)之位置。系統識別在位置上最接近來源12之志願者(步驟608)。由於來源12可能在屬於志願者人員庫成員之他人群體中，且此群體可能同時遇險，若把求助呼叫安排路由傳遞到這些他人，則將使遇險呼叫之目的失效。因此，緊急求助服務系統將判定，來源與目標志願者之相對位置並不相同到在與LBS所關聯之誤差容限內 的程度。

在判定最近志願者後，系統10隨即安排路由傳遞該呼叫至最近志願者(步驟610)。若志願者接收到呼叫(步驟612)，則建立會話(步驟614)。

另一方面，志願者可能未接到呼叫，因為志願者未能注意該呼叫，例如錯過呼叫(步驟615)，或因為志願者無興趣回應該遇險呼叫。若志願者無意地錯過該呼叫，則系統10會重新試圖呼叫(步驟616)。另一方面，若該呼叫被有意拒絕，則拒絕方之電話號碼會自志願者人員庫中移除(步驟618)。系統接著判定人員庫中之他人中最接近該過險方者，且嘗試安排路由傳遞該呼叫至該志願者，即用排除法重試(步驟616)。步驟610至步驟618可如所論述地重複施行。

另外，可存在一逾時特徵，其中若呼叫被安排路由傳遞至相同號碼且呼叫仍未被應答，則預設呼叫被安排路由傳遞至中央求助熱線，其可為類似於911之設施，或安排路由傳遞至可能被當地、行動網路營運者或其他相關方所採納之此類其他實施機構。

志願者資料庫可為由使用者界定者，即由過險使用者界定。其亦可為由系統產生，基於現有之號碼簿服務，該服務為用於所有用戶以及線上白頁/黃頁服務及社交網路登記簿的集中式資料庫。基於呼叫者聯絡簿或電話簿中之項目，或基於呼叫者與他或她的聯絡簿、電話簿、呼叫或訊息日誌文檔中之聯絡者的互動頻率與持續時間，其可亦為社交的。

本發明提供一號碼遮蔽特徵，其擴展單純的隱藏識別符或電子欺騙(spoofing)識別符或一來源的識別符。經由以上各種實例及實施例中描述之呼叫處理，本發明之號碼遮蔽特徵為一種自覺性努力成果，以便使與諸方相關或不相關的電話號碼能使用防止詐欺之安全基礎架構(即，在通訊網路內)。

相比於諸如RFC 3325的先前技術標準，此等習知標準使受信賴伺服器網路能夠斷定授權使用者之身份，而其中使用者必須在信任網路內，而本發明則涵蓋超越RFC 3325定義之情形，其中一方可在信任網路之外。

與本發明關聯之一優點在於，諸如行動識別號碼(MIN)之識別符從未被曝露，由於在來源及接收方裝置之隱私設定上執行檢查而提供可控制之隱私性。

此外，按照維持於系統網路內之社交網路通訊錄27，因為僅營運者始終知道識別對映內容，所以號碼電子欺騙不可能由行動呼叫者或接收方發起。

應理解，以上實施例僅通過本發明之例示(諸如以下之具體申明)而提供，且將對於熟習此項技術者為明顯的對該等實施例之進一步修改及改良，被視為落在所述本發明之廣泛範疇和範圍內，特別地：

˙來源裝置12及接收方裝置4可為行動電話或任何具有網路連接性之電子器件或裝置。

˙呼叫者及接收方裝置可經由行動網路(即3G、EDGE、GSM、無線電等)，經由無線網路(即Wi-Fi、WiMax、IrDA、藍牙、NFC)或經由有線連接性，進行無線通訊。

˙本發明可經由諸如交談型語音回應系統(IVR)或網站的其他介面實施。

此外，儘管可能已描述本發明之個別實施例，本發明意欲亦涵蓋所論述實施例之組合。

10‧‧‧系統

12‧‧‧來源(行動裝置)/呼叫者

14‧‧‧接收方(裝置)/行動裝置

16‧‧‧處理管理器

20‧‧‧關聯資料庫

22‧‧‧遮蔽資料庫

24‧‧‧號碼解析資料庫

26‧‧‧外部閘道器

27‧‧‧網路通訊錄

200~236、302~330、400~420、 502~522、602~618‧‧‧步驟

第1圖為根據本發明之實施例的系統方塊圖。

第2圖為圖示根據本發明之實施例的發給接收方之電話呼叫的處理之流程圖。

第3圖為圖示根據本發明之實施例的發給接收方之電話呼叫的路由安排之流程圖。

第4圖為圖示自來源至預期接收方之電話呼叫起始的流程圖，該來源在使用本發明之實施例的相同網路內。

第5圖為圖示自來源至不同網路中預期接收方之電話呼叫起始的流程圖，及第6圖為圖示本發明之實施例可如何結合基於位置之服務用作「緊急狀況」工具的流程圖。

10‧‧‧系統

12‧‧‧來源

14‧‧‧接收方

16‧‧‧處理管理器

20‧‧‧關聯資料庫

22‧‧‧遮蔽資料庫

24‧‧‧號碼解析資料庫

26‧‧‧外部閘道器

27‧‧‧網路通訊錄

Claims (35)

1. 一種用以於接收方裝置上顯示來源之識別符的系統，該接收方裝置與該來源通訊，該系統包含：一關聯資料庫，其配置以維持一網路通訊錄；及一處理管理器，其配置來處理由該來源至該接收方裝置之通訊，且配置來比較該網路通訊錄上之該來源之聯絡簿與該接收方裝置之聯絡簿，以便判定該來源是否與該接收方裝置相關聯，以及若該來源與該接收方裝置相關聯，則於該接收方裝置上顯示該來源之一已建立之識別符，以及其中若該來源不與該接收方裝置相關聯，則會檢查該接收方裝置之隱私設定，且若該接收方裝置之該隱私設定允許來自該接收方裝置之社交網路外的通訊，則該系統可操作來檢查該來源之一識別符屬性以判定如何得到該接收方裝置之一識別符，以及其後使用與如何得到該接收方裝置之該識別符有關的資訊在該來源與該接收方裝置之間建立一社交網路。
2. 如請求項1之系統，其中該處理管理器與該來源及/或該接收方裝置整合。
3. 如請求項1或2之系統，其中該接收方裝置為一行動裝置。
4. 如請求項1或2之系統，其中該來源係為一行動裝置。
5. 如請求項1或2之系統，其中該處理管理器包括允許存取該系統以管理該系統之一客戶端介面。
6. 如請求項1之系統，其中該系統進一步包含基於位置之服務(LBS)以便判定該來源之位置。
7. 如請求項6之系統，其中該LBS進一步組配來把該來源之位置通知給緊急服務。
8. 如請求項6之系統，其中該LBS進一步組配來通知來自該來源之至少一聯絡人。
9. 如請求項8之系統，其中該至少一聯絡人係由該來源於該處理管理器中指定。
10. 如請求項8之系統，其中來自該來源之該至少一聯絡人係基於與該來源之互動的頻率所指定。
11. 如請求項8之系統，其中來自該來源之該至少一聯絡人係基於與該來源之互動的持續時間所指定。
12. 如請求項6之系統，其中該LBS進一步組配來存取登記使用者之一資料庫，且判定最接近該來源之該位置的該LBS之登記使用者之數目。
13. 如請求項12之系統，其中該LBS進一步組配來把該來源之該位置通知給該LBS之所有該等登記使用者。
14. 如請求項12之系統，其中該LBS進一步組配來通知最接近該來源之該位置的至少一登記使用者。
15. 如請求項14之系統，其中該LBS進一步組配來存取該網路通訊錄，且通知不與該來源相關聯之至少一登記使用者。
16. 如請求項14之系統，其中該LBS進一步組配來存取該登記使用者之資料庫，且相應地根據被通知的該至少一登 記使用者之動作更新該資料庫。
17. 如請求項16之系統，其中該LBS進一步組配來存取該登記使用者之資料庫，且通知第二接近該來源之該位置的至少一登記使用者。
18. 如請求項14之系統，其中該LBS無法把該來源之該位置通知給至少一登記使用者，且該LBS進一步組配來通知該來源之該位置給緊急服務。
19. 如請求項1之系統，其中該接收方裝置包含用以判定該來源是否被列入監視清單或黑名單之一系統日誌。
20. 如請求項6之系統，其中一旦判定該來源係被列入監視清單或黑名單，則分別地終止由該來源起始之該通訊，或觸發一告警，其後終止該通訊。
21. 如請求項1之系統，其中該處理管理器經調適以於判定該來源及該接收方裝置不在一相同通訊網路內時，則與一外部閘道器進行資料通訊，以安排路由傳遞自該來源至該接收方裝置之通訊。
22. 如請求項1之系統，其中該網路通訊錄進一步組配來藉由在該網路通訊錄與該來源及該接收方裝置之間執行定期同步化來判定該來源是否與該接收方裝置關聯。
23. 如請求項1之系統，其中若該來源不與該接收方裝置相關聯，則該處理管理器可操作來判定該來源之隱私設定並依據該來源之經判定之該隱私設定於該接收方裝置上顯示一另一識別符，其中該來源之該隱私設定係基於該來源是否被公開列出、未被列出或使其識別符被遮蔽 來判定。
24. 一種用以於接收方裝置上顯示來源之識別符之方法，該接收方裝置與該來源通訊，該方法包括以下步驟：處理由該來源至該接收方裝置之通訊；比較一網路通訊錄上該來源之聯絡簿與該接收方裝置之聯絡簿；判定該來源是否與該接收方裝置相關聯；若該來源與該接收方裝置相關聯，則於該接收方裝置上顯示該來源之一已建立之識別符；以及若該來源不與該接收方裝置相關聯，則檢查該接收方裝置之隱私設定，且若該接收方裝置之該隱私設定允許來自該接收方裝置之社交網路外的通訊，則檢查該來源之一識別符屬性以判定如何得到該接收方裝置之一識別符，以及其後使用與如何得到該接收方裝置之該識別符有關的資訊在該來源與該接收方裝置之間建立一社交網路。
25. 如請求項24之方法，其包括若該來源不與該接收方裝置相關聯，則判定該來源之隱私設定之一步驟，及依據該來源之經判定之該隱私設定於該接收方裝置上顯示一另一識別符，其中判定該來源之該隱私設定之該步驟包括判定該來源是否未被列出或使其識別符被遮蔽。
26. 如請求項24之方法，其中若判定該來源及該接收方裝置位於一相同通訊網路內，則該方法進一步包括檢查該來源是否被列入該通訊網路內的黑名單或監視清單之一 步驟。
27. 如請求項26之方法，其中若該來源未被列入黑名單或監視清單，則檢查該接收方裝置之該隱私設定以判定該來源之該識別符是否顯示於該接收方裝置上。
28. 如請求項26之方法，其中若該來源被列入監視清單，則觸發一告警且終止由該來源至該接收方裝置之該通訊。
29. 如請求項26之方法，其中若該來源被列入黑名單，則終止由該來源至該接收方裝置之該通訊。
30. 如請求項24之方法，該方法包括在該來源與該接收方裝置之間建立一路由的步驟。
31. 如請求項30之方法，其中檢查該來源之該識別符屬性之該步驟包括判定該接收方之該識別符是否被進送、下載或手動輸入至該來源。
32. 如請求項24之方法，該方法包括判定該來源及該接收方裝置是否在一相同通訊網路內之一步驟，及若判定該來源及該接收方裝置不在該相同通訊網路內，則安排路由傳遞來自該來源之通訊。
33. 如請求項24之方法，其中比較該網路通訊錄上該來源之聯絡簿與該接收方裝置之聯絡簿之該步驟包括存取該網路通訊錄。
34. 如請求項33之方法，其中該網路通訊錄與該來源及該接收方裝置定期同步化。
35. 一種包含處理管理器之接收方裝置，該處理管理器經配置來處理一系統中自一來源至該接收方裝置之通訊； 該處理管理器係配置來維持一網路通訊錄，及比較該網路通訊錄上該來源之聯絡簿與該接收方裝置之聯絡簿以便判定該來源是否與該接收方裝置關聯；其中若該來源與該接收方裝置相關聯，則該接收方裝置顯示該來源之一已建立之識別符；以及若該來源不與該接收方裝置相關聯，則會檢查該接收方裝置之隱私設定，且若該接收方裝置之該隱私設定允許來自該接收方裝置之社交網路外的通訊，則該系統可操作來檢查該來源之一識別符屬性以判定如何得到該接收方裝置之一識別符，以及其後使用與如何得到該接收方裝置之該識別符有關的資訊在該來源與該接收方裝置之間建立一社交網路。