在線收費管理伺服器的製作方法

2023-05-29 14:31:16

專利名稱：在線收費管理伺服器的製作方法
技術領域：
本發明涉及在線收費伺服器，並更具體地但非排他地涉及用於提 供用於無線蜂窩網絡的預付費功能的在線收費伺服器。
背景技術：
通信系統是支持在兩個或更多個實體之間的通信的設施，實體諸 如用戶終端裝備和/或網絡實體，以及同通信系統相關聯的其他節點。通信可以包括例如語音、電子郵件(email)、文本消息、數據、多媒 體等的通信。可由固定線路和/或無線通信接口提供通信。無線通信系統的特性 在於，它們向其用戶提供移動性。提供無線通信的通信系統的例子是 公共陸地行動網路(PLMN)。固定線路系統的例子是公共交換電話 網絡(PSTN )。通信系統典型地根據給定的標準或規範而操作，該標準或規範列 出了允許系統的多種元件作什麼，以及它們應該^f皮如何實現。例如， 該標準或規範可以定義，是否向用戶或更精確地向用戶裝備，提供電 路交換伺服器或分組交換伺服器或(上述)兩者。還典型地定義了將 用於該連接的通信協議和/或參數。例如，在用戶裝備和通信網元之間 如何實現通信的方式，是典型地基於預定義的通信協議的。換句話說， 需要定義專用的"規則"集，來支持用戶裝備經由通信系統通信，該 "規則"集是通信可以基於的。第三代(3G)通信系統的引入，將顯著地增加經由移動用戶裝備 (UE)以及其他類型的UE接入網際網路上的服務的可能性。本領域技術人員知曉諸如計算機(固定的或便攜的)、行動電話、 個人數字助理或(個人數字)組織者的多種用戶裝備(UE)，並且， 其能夠被用於接入網際網路以獲得服務。可將被稱作移動臺(MS)的移動用戶裝備定義為一種裝置，其能夠經由無線接口同諸如移動電信 網絡的基站或任何其他站的設備進行通信。上面以及下文中使用的術語"服務"，將被理解為廣泛地覆蓋了 用戶希望、需要或提供給用戶的任何服務或商品。也應該將該術語理 解為覆蓋了免費服務的提供。具體但非排他地，術語"服務"將理解為包括網際協議多媒體IM服務、會議、電話、遊戲、多信息呼叫(rich call)、電子商務以及例如即時通訊的通訊。"月艮務"可以包括兩部 分或更多個部分。例如，糹見頻電話包括語音部分和糹見頻部分。可選地， 可以同時提供兩個或更多個服務，例如，可以同時提供遊戲服務和聊 天室服務。3G夥伴計劃(3GPP)正在定義用於通用移動電信系統(UMTS) 核心網絡的參考架構，通用移動電信系統(UMTS)核心網絡將向用 戶裝備UE的用戶提供對這些服務的接入。此UMTS核心網絡分為三 個主要的域。它們是電路交換域、分組交換域和網際協議多媒體(IM)域。這些域中的後者即IM域中，確保充分地管理多媒體服務。IM域 支援由網際網路工程任務組(IETF)開發的會話發起協議(SIP)。同IMS和非IMS系統(即，經由核心網之外的服務節點提供給 訂戶的服務，例如，多媒體通訊和位置估計服務)兩者相關的管理的 一方面是向用戶就所提供的服務而收費。可將收費分為兩種收費模 式。第一種是在線收費，其中用戶為服務有效地預付費，而第二種是 離線收費，其中在會話之後，向用戶開具服務的帳單。因而，通過當 進入時付費(pay-as-you-go)的系統而實現第 一種收費方法，而用定 期地向用戶就其已經做出的呼叫開具帳單來實現第二種方法。當前，對於在線收費，打算向用戶收費的任何網絡功能需要向本 領域中作為在線收費系統(OCS)而為人所知的網元傳送信用控制請 求消息。在諸如第三代夥伴計劃(3GPP)技術規範(TR) 32.815的 標準中定義了對標準化OCS架構的嘗試。而且，由OCS操作的一些
接口和應用已經進一步地由3GPPTS 32.296標準化。當前，作為實現於這些標準之內的OCS的架構，對嘗試操作統 一的(即，在線和離線)帳單開具系統的任何操作者存在著問題。如 同由上述標準定義的，OCS包括帳戶資料庫，其由帳戶餘額管理系統 操作。在OCS內的帳戶餘額管理系統和帳戶資料庫有效地是由操作 者所持有的用於離線記帳系統的信息的部分複製。發明內容本發明及其實施方式的目的在於提供對在線記帳系統的改進，其 提出了創建集中式操作此類系統進行記帳的可能性。根據本發明，提供了一種在線收費管理系統伺服器，包括接收 裝置，被安排接收從網絡服務提供商傳輸的至少 一個帳戶請求消息； 以及傳輸裝置，被安排基於所接收的帳戶請求，向另外的獨立伺服器 傳輸在線帳戶餘額消息。所述在線帳戶餘額消息可以是在線帳戶餘額請求消息。所述在線帳戶餘額請求消息可以包括對下列至少 一 個的請求做 出保留，實行保留以及做出新保留，實行保留，釋放保留，餘額查詢， 增加餘額，以及減少餘額。可以進一步安排所述接收裝置，來從所述另外的伺服器接收在線 帳戶餘額消息。來自所述另外的伺服器的所述在線帳戶餘額消息可以是在線帳 戶餘額應答消息。所述在線帳戶餘額應答消息可以包括基於所述在線帳戶餘額請求消息的值。所述在線帳戶餘額消息可以是直徑(Diameter)消息。 所述在線帳戶餘額消息可以是直徑信用控制消息。 所述伺服器可以是評估伺服器。根據本發明的第二方面，提供了一種在線收費帳戶管理伺服器， 包括接收裝置，被安排以接收來自至少一個另外的獨立伺服器在線
帳戶餘額消息，所述在線帳戶餘額消息基於所接收的從網絡服務提供 商傳輸的帳戶請求消息，以及處理裝置，被安排來基於所述所接收的 在線帳戶餘額消息來執行在線帳戶餘額動作。所述伺服器進一步包括傳輸裝置，被安排來向所述另外的伺服器 傳輸在線帳戶餘額消息。所述在線帳戶餘額消息可以是在線帳戶餘額請求消息。所述在線帳戶餘額請求消息可以包括對下列至少一個的請求做 出保留，實行保留以及做出新保留，實行保留，釋放保留，餘額查詢， 增加佘額，以及減少餘額。向所述另外的伺服器傳輸的所述在線帳戶餘額消息可以是在線 帳戶餘額應答消息。所述在線帳戶餘額應答消息可以包括由所述處理裝置基於所述 才丸行的動作而確定的值。一種系統可以包括如上面所描述的所述在線收費管理伺服器， 以及如上面所描述的所述獨立在線收費帳戶管理伺服器。根據本發明的第三方面，提供了 一種用於執行在包括在線收費管 理伺服器以及獨立在線收費帳戶管理伺服器的通信網絡內的在線收 費的方法，所述方法包括下列步驟在所述在線收費管理伺服器接收 從網絡服務提供商傳輸的至少一個帳戶請求消息，以及基於所述所接 收的帳戶請求消息，從所述在線收費管理伺服器向所述獨立在線收費 帳戶管理伺服器傳輸在線帳戶餘額消息。所述方法可以進一步包括下列步驟在所述獨立在線收費帳戶管 理伺服器接收所述在線帳戶餘額消息；以及基於所述所接收的在線帳 戶餘額消息，在所述獨立在線收費帳戶管理伺服器執行至少一個帳戶 管理功能。所述方法可以進 一 步包括在執行所述至少 一 個帳戶管理功能的 所述步驟的基礎上，從所述獨立在線收費帳戶管理伺服器向所述在線 收費管理伺服器傳輸在線帳戶餘額消息。根據本發明的第四方面，提供了一種電腦程式產品，其被安排
來實現用於執行在包括一個在線收費管理伺服器和一個獨立在線收 費帳戶管理伺服器的通信網絡內的在線收費的所述步驟的方法，所述方法包括下列步驟在所述在線收費管理伺服器接收從網絡服務提供 商傳輸的至少 一 個帳戶請求消息，以及基於所述所接收的帳戶請求消 息，從所述在線收費管理伺服器向所述獨立在線收費帳戶管理伺服器 傳輸在線帳戶餘額消息。所述電腦程式產品可以進一步實現下列步驟在所述獨立在線 收費帳戶管理伺服器接收所述在線帳戶餘額消息；以及基於所述所接 收的在線帳戶餘額消息，在所述獨立在線收費帳戶管理伺服器執行至 少一個帳戶管理功能。所述電腦程式產品可以進 一 步實現在執行所述至少 一 個帳戶 管理功能的所述步驟的基礎上，從所述獨立在線收費帳戶管理伺服器 向所述在線收費管理伺服器傳輸一個在線帳戶餘額消息的步驟。根據本發明的第五方面，提供了 一種組合的在線和離線收費服務 器，包括 一個在線收費帳戶管理伺服器，包括接收裝置，被安排 來從至少 一個另外的獨立伺服器接收在線帳戶餘額消息，所述在線帳 戶餘額消息基於所接收的從網絡服務提供商傳輸的帳戶請求消息，以 及處理裝置，被安排來基於所述所接收的在線帳戶餘額消息來執行在 線帳戶餘額動作，以及一個離線收費帳戶管理伺服器。


僅通過參考附圖的舉例方式描述本發明，其中圖1示出了包括傳統在線收費系統的通信網絡的簡化視圖；圖2示出了改進的在線收費系統的簡化視圖，在該在線收費系統中，實現了本發明及其實施方式；以及圖3-圖8示出了用於演示針對一系列記帳操作的該改進的在線收費系統才喿作的流程圖。
具體實施例方式
這裡，通過舉出參考了大量實施方式的例子的方法描述本發明。 做出對圖l的引用，圖1原理性地展示了一個系統，其中能夠實現本發明的實施方式。該系統包括用戶裝備2。用戶裝備2能夠採用任何合適的形式，並作為舉例可以是諸如行動電話、個人數字助理(PDA)、便攜計算機、膝上計算機、固定計算機或任何其他合適的 設備的移動或固定實體。安排用戶裝備2經由無線連接同無線接入網 絡(RAN)通信。此無線連接可以是在任何合適的頻率，諸如作為舉 例的射頻。無線接入網絡8通常包括基站實體(有時被稱作節電B)。對於 本文檔的目的，將使用術語基站，並且，其意在覆蓋任何適合的實體。 無線接入網絡8也包括控制元件。根據該標準，在UMTS系統的情況 中，可將控制元件稱為無線網絡控制器(RNC),或者，在GSM系 統的情況中，可將控制元件稱為基站控制器(BSC)。意在用術語控 制器覆蓋任何此類控制實體。在一些安排中，從基站功能單獨地提供 控制功能，以及單一的控制實體可以控制大量基站。在本發明的其他 實施方式中，每個基站可以合併控制功能的部分。安排無線接入網絡來同核心網絡10通信。在圖1中示出的核心 網絡IO是分組交換核心網。核心網絡包括至少一個服務GPRS(通用 分組無線服務)支持節點SGSN,使用其來交換分組交換事務，以及 至少一個GPRS支持節點GGSN,其是在將核心網10連接到外部分 組交換網的地點的交換機。將核心網絡連接到IM (IP多媒體)子系統14。將GGSN連接到 在IMS 14中的P-CSCF 16 (代理呼叫會話控制功能)。將P-CSCF連 接到服務S-CSCF24。 S-CSCF聯繫在終止網絡中的詢問I-CSCF 22。 安排I-CSCF 22來為被叫方的終端用戶確定恰當的服務CSCF( S )24。圖l展示了呼叫方。可將被叫方連接到不同或相同的IMS。同樣 地，可將被叫方連接到不同或相同的OCS。將被叫方連接到不同的 IMS的地方，提供了不同的核心網和RAN。在IMS相同的地方，可 能需要或不需要不同的核心網。同樣地，用於被叫方的RAN同呼叫
方的RAN可以相同或者不同。儘管在上面的例子中，但為了簡化對本發明的解釋的目的，將 IMS14展示為連接到OCS16，本領域衝支術人員應當理解，OCS6也可 以連同其他非IMS網元而操作。特別地，3GPP指定了能夠向OCS6 通信消息的三種類型協議消息。在圖1中展示的消息的第一類型是在 3GPP規範中由Ro接口定義的IMS在線收費參考點。在圖1中沒有 展示出的消息的第二類型是用於針對諸如來自多媒體通訊服務、 WLAN和作為Ro接口而定義在3GPP >見範中的網關GPRS服務節點 (GGSN)的在線收費參考點。在圖1中未示出，但在3GPP規範中 指定了的消息的第三類型是用於行動網路增強邏輯(CAMEL)應用 部分(AP)消息的可定製的應用，該行動網路增強邏輯(CAMEL) 應用部分(AP )消息能夠被從諸如移動交換中心(MSC )和服務GPRS 服務節點(SGSN)傳輸。參看圖2,展示出改進的OCS106。改進的OCS106包括至少兩 個物理上獨立的伺服器。第一伺服器是帳戶餘額管理伺服器103，而 第二伺服器是收費和評估(rating)伺服器101。也作為帳戶餘額管理伺服器103而為人所知的帳戶管理伺服器， 包括被安排來向收費和評估部分傳輸消息和從收費和評估部分接收 消息的帳戶餘額管理功能。而且，帳戶餘額伺服器103包括能夠由帳 戶餘額管理功能訪問的帳戶數據111。進一步安排帳戶餘額伺服器來連接到充值伺服器3。使用充值服 務器來對由帳戶數據111所存儲的帳戶值充值。因而，例如當用戶帳戶在信用方面是低時，充值伺服器能夠向帳戶餘額管理伺服器103傳 送消息來"加滿(top up)"正被討論的帳戶，其中信用是例如幣種 (currency)、通話時段帶寬(bandwidth air time )或數據傳輸可用性。 作為在線收費管理伺服器而也為人所知的收費和評估伺服器，包 括在線收費功能(OCF) 151,收費網關功能161,以及評估功能171。 OCF自身包括基於會話的收費功能153,其在本領域中為人所知地用 於執行根據來自IMS呼叫會話控制功能(CSCF)的信用控制消息的
接收而收費的IMS會話，以及基於事件的收費功能155，其執行使用 Ro或Ro接口信用控制消息的基於事件的收費。儘管在圖2中未展示 出，在進一步的實施方式中，OCF 151能夠包括基於承載的收費功能。 安排基於承載的收費功能來執行使用CAP協議消息類型的基於承載 的收費。由OCF 151使用收費網關功能161來收集並向操作者通告處理系 統5傳輸收費信息，將該收費網關功能161連接到OCF 151以及該操 作者通告處理系統5。將評估功能171連接到OCF 151，以及由OCF 151來使用該評估 功能171以推導可用服務的價格和費率。作為單位確定、對大量同會 話相關的非貨幣單元(服務單元、數據量、時間和事件)的計算和保 留、價格確定(用於對給定數量的非貨幣單元的貨幣單位計算)、價 格確定(基於訂戶合同條款和被請求的服務而對價格信息的確定)以 及得到/設置用於評估的可用的計數器中的一個，是在3GPP TR 32.815 中很好地定義的評估功能171的功能性。關於帳戶餘額管理伺服器103和收費及評估伺服器101的交互， 下面公開了帳戶餘額請求(ABR)和帳戶餘額應答(ABA)對。下面展示出ABR消息的模板ABR:{-Normal routing based information as in Diameter base-}{Account-Balance-Action}{Account-Balance-Request-Number}{User-Name/Account-Id}[Requested-Service-Unit][Used-Service-Unit]其中，欄位〈session-Id〉是由OCF 151提供的唯一的會話號碼， 欄位《Account-Balance-Action)代表從帳戶餘額管理伺服器103請求的 動作。欄位(Account畫Balance-Request-Number〉是標識從收費和評估服 務器101到帳戶餘額管理伺服器103的專用請求。欄位 (User-Name/Account-Id)是將請求服務的用戶連結到在帳戶餘額管理 伺服器103內存儲的帳戶代碼的標識符。欄位[Requested-Service-Unit] 標識了一種服務，該服務提供網元而從該網元用戶已經請求了服務。 欄位[Used-Service-Unit]標識了任何提供網元的服務，該網元已經向用 戶提供了服務。並且下面展示出ARA消息的模板ABA:{-Normal routing based information as in Diameter base-} [Account-Balance-Action} {Account-Balance-Request-Number} {User-Name/Account-Id} [Granted-Service-Unit]唯一額外的欄位是[Granted-Service-Unit],其為標識了由帳戶餘而且，Account-Balance-Action AVP欄位具有下列值 l做出保留2實行保留以及做出新保留3實行保留4釋放保留5餘額查詢6增加餘額7減少餘額在將在線收費伺服器分成在通過上述消息的裝置而通信的在線 收費管理和在線收費帳戶餘額管理伺服器中，繼而，可以將在線收費 帳戶餘額管理伺服器的功能性合併入組合的在線和離線帳戶餘額管 理伺服器，以及因而，克服在具有在線和離線帳戶的用戶之間的帳戶 和數據複製的問題。下面，將關於圖3-9進一步公開根據這些值的帳戶和餘額管理服 務器103的操作。關於這些圖所描述的例子包括用戶裝備2、網元51 (在由圖l提供的例子中，該網元51將在IMS14之中，但同樣地， 其可以是較早先所描述的任何網元)、OCF151以及帳戶餘額管理服 務器111的簡化的網絡架構。關於圖3，展示出用於標準的服務操作和終止的這些帳戶餘額請 求(ABR)以及帳戶餘額應答(ABA)消息的使用的第一個例子。當 UE2向網元51傳輸發起服務請求時，第一步驟21發生。當網元51向OCF 151傳輸信用控制請求發起消息時，接下來的 步驟203發生。發送信用控制消息發起消息，以便確定用戶是否具有 足夠的信用用於所請求的服務以及來請求在線支付。在接下來的步驟205中，OCF 151向帳戶餘額管理伺服器 (ABMS ) 103傳輸ABR保留消息(即,具有Account-Balance-Action AVP欄位設置為1的ABR消息)。當接收到此消息，在接下來的步驟207中，ABMS1034企查帳戶 信息，以及如果在該帳戶內有足夠的信用，則在此帳戶內做出信用保 留。信用保留有效地監督了在移除該保留之前，使用信用的預定義數 量。如前所述，此信用可以是本質上貨幣的，或者，可以依賴於網絡， 例如，同帶寬、數據、事件計數相關。在此後描述的下面的例子中， 信用是本質上貨幣的。在做出此信用保留後，在步驟209, ABMS 103將ABA消息向回 傳輸到承認該保留成功的OCF 151。繼而，OCF 151 (使用在圖3中未示出的評估功能)計算同用戶 使用保留的貨幣值而獲得的服務相關的單位數量。因而，作為舉例， 如果服務是根據所接收的數據的kB以及將所接收的每kB評估為F
歐元的點播視頻，具有每個保留所保留的貨幣值是G歐元，那麼，OCF計算在耗盡該保留之前，每個保留能夠提供G/F kB的視頻。然後，在步驟213， OCF向NE51傳輸信用控制應答消息，其包括對於此服務的提供對該用戶可用的單位數量的值。 一旦NE51接收此消息，繼而，該NE開始向UE2提供服務。如果操作UE 2的用戶希望在耗盡全部所計算出的單位之前結束該服務，步驟215到277描述了在本發明中使用的用來將剩餘單位值記帳的過程。當UE 2向NE 51傳輸服務終止請求時，步驟215發生。在接收 終止請求後，NE51計算剩餘單位，以及，在步驟217向OCF 151傳 輸CCR終止消息，該消息包括剩餘單位值。OCF 151根據接收的剩餘單位值，在步驟219計算步驟211的相 反的算法，來確定剩餘信用值，對於上面的例子，其為歐元幣種值。繼而，OCF 151向ABMS 103傳輸ABR實行消息(即，具有將 Account-Balance-Action AVP欄位設置為3的ABR消息)。在此消息 內，也傳送來自保留數量的幣種剩餘值。繼而，在步驟223, ABMS 103檢查信用保留，以及向活躍帳戶 值返回剩餘值，有效地退還了部分未使用的保留的貨幣在下面的步驟225， ABMS 103向OCF 1512傳輸通知OCF 151 確定過程成功的ABA消息。在進一步的步驟227中，OCF 151向NE傳輸另外的CCA消息， 該消息確定在NE51處，該確定收費已經#1計入信用。關於圖4，描述了本發明的第二個例子，其中，在終止服務之前， 耗盡了由OCF 151提供的單位。第二個例子的前六個步驟201-213遵循同在前面的描述服務的發 起的例子中的前六個步驟裡所描述的相同的過程。當已經耗盡了保留的和轉換的單位，而同時，繼續該服務，那麼， 在步驟301中，NE51確定需要新的單位來繼續該服務的操作。在下面的步驟303， NE51向OCF 151傳輸CCR更新消息。
當接收到CCR更新消息，OCF 151執行評估和轉換操作來將所 使用的單位轉換為等值的貨幣。步驟305是同由第一個例子的步驟 219所執行的相似的操作，唯一的差別在於返回值等於最初保留的數量。繼而，在跟著該計算的步驟中，OCF 151向ABMS 103傳輸ABR 實行和保留消息(即，具有將Account-Balance-Action AVP欄位設置 為2的ABR消息)。當接收到ABR實行和保留消息，接下來，ABMS 103在步驟309 執行實行來自所保留的帳戶的所使用的信用，以及創建進一步的保留 的動作。在接下來的步驟中，ABMS 103向OCF 151傳輸包含所保留的帳 戶的值的ABA消息。在接下來的兩個步驟211a和213a中，OCF 151執行信用向單位 的轉換操作，類似於在步驟211中實現的，為向NE51的CCA消息 的傳輸所跟隨的操作。現在能夠繼續在此過程的末尾的服務，直到由 用戶如圖3中在先步驟215所示出的第 一個例子中所描述的對其加以 終止，或者耗盡了更多的單位，而NE循環至在先步驟303以請求進 一步的更新。關於圖5，演示了本發明的進一步的例子，其中，用戶最初請求 服務，但實際上沒有使用向NE51傳遞的任何單位。第三個例子的前六個步驟201-213同示出了服務的發起中的第一 和第二個例子的前六個步驟201-213相同。在接下來的步驟215中，UE 2向NE 51傳輸服務終止請求。在 步驟401中，NE51確定該服務沒有使用任何單位。如同上面關於前 面的服務終止序列以及通過參看步驟217所描述的，NE 51向OCF 151 傳輸CCR終止消息。當接收到CCR終止消息，在步驟403中，OCF 151計算所使用 的貨幣信用數量。此步驟類似於前面例子的步驟219和305，除了在 此例子中也存在零使用的單位，並因此所使用的貨幣信用數量也是零。OCF151,當檢測到使用了零單位時，在步驟405，向AMBS 103 傳輸ABR釋放消息(即，具有Account-Balance-Action AVP欄位設 置為4的ABM消息)。在步驟409中，已經接收了 ABR釋放消息的AMBS103釋放該 保留。這有效地向活躍帳戶返回了在步驟207中已經被監督的信用。接下來，在步驟411， AMBS103向OCF 151傳輸承認保留釋放 成功的ABA消息。接下來，在步驟413, OCF 151向NE 51傳輸通知NE終止記帳 過程成功的CCA消息。關於圖6，展示了本發明的進一步實施方式，其中操作UE 2的 用戶希望看到用戶當前帳戶餘額的值。在步驟501， UE2向NE51傳輸餘額查詢消息。在步驟503,當接收到餘額查詢請求，NE51向OCF 151傳輸CCR 事件消息。該事件消息包括用於該用戶將讀取的帳戶餘額的指示符。在步驟505中，OCF向ABMS 103傳輸ABR查詢消息(即，具 有將Account-Balance-Action AVP欄位設置為5的ABR消息)。在步驟507，當接收到ABR查詢消息，ABMS 103衝全查所指出的 用戶帳戶，來確定帳戶的餘額。在步驟509,在一個ABA消息中，從ABMS 103向OCF 151傳 輸所確定的帳戶的餘額。在步驟511,在一個CCA消息中，從OCF 151向NE 51傳輸所 確定的餘額。最後，在步驟513,在一個餘額響應消息中，從NE向UE2傳輸 所確定的餘額。繼而，能夠在UE上為用戶顯示所確定的響應。關於圖7，展示了本發明的進一步的例子。在此例子中，至少部 分地由操作者或第三方補貼對所提供的服務的使用，以及因而，應向 用戶帳戶支付退款。其中的一個例子可以是如下情形，其中操作者贊 助一項忠誠獎金策劃，例如，"購買10分鐘視頻，向您的帳戶贈送l 歐元信用"的激勵策劃。在步驟601, UE2通過向NE51傳輸服務請求消息而請求服務。在步驟603， NE 51確定由於該服務的使用是被贊助的，所請求 的服務被授權退款。在步驟605, NE 51繼而向OCF 151傳輸CCR事件/退款消息， 換句話說，CCR消息包括退款將付給該用戶的帳戶的指示。在步驟607中，OCF 151向ABMS 103傳輸ABR增加消息(即， 具有將Accoimt-Balance-Action AVP欄位設置為6的ABR消息)。 該消息包括將向該用戶帳戶退款的數量的細節。在步驟609, —旦ABMS 103已經接收到ABR增加消息，ABMS 103通過所指出的信用值，增加該用戶帳戶的餘額。在步驟611, —旦ABMS 103已經成功地增加了該用戶的帳戶， 繼而，ABMS向OCF 151傳llT ABA消息來確定此動作是成功的。在步驟613，當接收到ABA消息，OCF 151向NE 151傳輸CCA 消息來確定在NE51處該動作是成功的。在本發明的進一步的實施方式中，當接收到CCR事件/退款消息， OCF 151能夠進一步核對以確定該用戶帳戶是否應當被退款。進一步 的實施方式的步驟(在圖7中未示出)能夠被用來作為第二核對來防 止欺詐性地嘗試對接收帳戶進行充值。關於圖8,展示了本發明的實施方式的進一步的例子。在圖8中 示出的例子是，用戶請求的服務是固定費用服務。其中的一個例子可 以是系統，藉此系統使用行動電話上的預付費設施來購買諸如運輸票 證的條目。在步驟701, UE向NE51傳輸服務請求。在步驟703,當接收到該請求，NE計算同該請求相關的費用。在步驟705, NE 51向OCF 151傳輸CCR借記事件/命令消息。 此消息包括所計算的費用。在步驟707， OCF 151評估所使用的單位數量，以及如果先前沒 有完成的話，在必要的地方，將所收費的信用改變為單位(在上面的
例子中，已經是貨幣信用)。在步驟709中，OCF 151向ABMS 103傳輸ABR減少消息(即， 具有將Account-Balance-Action A VP欄位設置為7的ABR消息)。 減少消息包括經評估的信用值，用戶的帳戶將按照該值來減少。在步驟711, ABMS 103按照在ABR減少消息內的值來減少用戶 的帳戶。減少帳戶的操作不同於在前面例子中描述的步驟，因為，在 該帳戶上沒有做出保留。在步驟713， ABMS繼而向OCF傳輸ABA消息713,來確定該 請求^皮成功地實現。在步驟715, ABMS繼而向NE51傳輸CCA消息，來確定在NE 51處，該請求被成功地實現。因而，通過對上面描述例子的引用能夠看到帳戶餘額管理伺服器 103能夠在同收費和評估伺服器(CRS) 101的組合中實現寬範圍的 一系列在線收費管理操作。而且，由於ABMS 103和CRS 101已經良 好的定義了通信的範圍，將在線收費帳戶管理系統併入能夠操控在線 和離線請求二者的集中式帳戶操控系統的部分，並因而可以克服帳戶 複製的問題。而且，此類系統允許操作者利用帳戶操作的更多的靈活 性，諸如向用戶提出單一組合的(在線和離線)帳戶，其可以具有由 用戶使用以產生幾乎即時的餘額查詢的優點。在本發明的進一步的實施方式中，在CRS 101和ABMS 103之間 加以發送的請求和應答消息(對於前面描述的例子，是ABR和ABA 消息)基於已有的直徑基礎消息而被替代。在本發明的其他實施方式中，請求和應答消息是分別是直徑信用 控制請求和直徑信用控制應答;肖,包、。本領域技術人員將理解對所描述的實施方式的多種調整。由本發 明提出的保護範圍由隨附的權利要求書定義。
權利要求
1.一種在線收費管理伺服器，包括接收裝置，被安排以接收從網絡服務提供商傳輸的至少一個帳戶請求消息，以及傳輸裝置，被安排以基於所述接收的帳戶請求向另外的獨立伺服器傳輸在線帳戶餘額消息。
2. 根據權利要求1所述的伺服器，其中所述在線帳戶餘額消息是在 線帳戶餘額請求消息。
3. 根據權利要求2所述的伺服器，其中所述在線帳戶餘額請求消息 包括對下列至少 一個的請求做出保留；實行保留並做出新保留；實行保留；釋放保留；餘額查詢；增加餘額；以及減少餘額。
4. 根據權利要求1-3中任一項所述的伺服器，其中進一步安排所述 接收裝置以接收來自所述另外的伺服器的在線帳戶餘額消息。
5. 根據權利要求4所述的伺服器，其中來自所述另外的伺服器的所 述在線帳戶餘額消息是在線帳戶餘額應答消息。
6. 根據權利要求5所述的伺服器，其中所述在線帳戶餘額應答消息 包括基於在線帳戶餘額請求消息的值。
7. 根據權利要求1和4所述的伺服器，其中所述在線帳戶餘額消息 是直徑消息。
8. 根據權利要求7所述的伺服器，其中所述在線帳戶餘額消息是直 徑信用控制消息。
9. 根據權利要求1-8中任一項所述的伺服器，其中所述伺服器是評 估伺服器。
10. —種在線收費帳戶管理伺服器，包括接收裝置，被安排以接收來自至少一個另外的獨立伺服器的在線帳 戶餘額消息，所述在線帳戶餘額消息基於所接收的從網絡服務提供商傳 輸的帳戶請求消息；以及處理裝置，被安排以基於所接收的在線帳戶餘額消息來^丸行在線帳 戶餘額動作。
11. 根據權利要求IO所述的伺服器，進一步包括傳輸裝置，被安排 以向所述另外的伺服器傳輸在線帳戶餘額消息。
12. 根據權利要求10和11所述的伺服器，其中所述在線帳戶餘額 消息是在線帳戶餘額請求消息。
13. 根據權利要求12所述的伺服器，其中所述在線帳戶餘額請求消 息包括對下列至少 一 個的請求做出保留；實行保留以及做出新保留實行保留釋放保留；餘額查詢；增加餘額，以及減少餘額。
14. 根據權利要求11所述的伺服器，其中向所述另外的伺服器傳輸 的所述在線帳戶餘額消息是在線帳戶餘額應答消息。
15. 根據權利要求14所述的伺服器，其中所述在線帳戶餘額應答消 息包括由所述處理裝置基於所述執行動作而確定的值。
16. —種系統，包括如權利要求1-9中任一項所述的在線收費管理伺服器，以及 如權利要求10-15中任一項所述的獨立在線收費帳戶管理伺服器。
17. —種用於在包括在線收費管理伺服器和獨立在線收費帳戶管理 伺服器的通信網絡內執行在線收費的方法，所述方法包括下列步驟 在所述在線收費管理伺服器處，接收從網絡服務提供商傳輸的至少 一個帳戶請求消息，以及基於所述接收的帳戶請求消息，從所述在線收費管理伺服器向所述 獨立在線收費帳戶管理伺服器傳輸在線帳戶餘額消息。
18. 根據權利要求17所述的方法，進一步包括下列步驟 在所述獨立在線收費帳戶管理伺服器處接收所述在線帳戶餘額消息，以及在所述獨立在線收費帳戶管理伺服器處，基於所述所接收的在線帳 戶餘額消息，執行至少一個帳戶管理功能。
19. 根據權利要求18所述的方法，其中，所述方法進一步包括在執 行所述至少一個帳戶管理功能的步驟的基礎上，從所述獨立在線收費帳 戶管理伺服器向所述在線收費管理伺服器傳輸在線帳戶餘額消息。
20. —種電腦程式產品，被安排以實現用於在包括在線收費管理 伺服器和獨立在線收費帳戶管理伺服器的通信網絡中執行在線收費的 所述方法，所述方法包括下列步驟在所述在線收費管理伺服器處接收從網絡服務提供商傳輸的至少 一個帳戶請求消息；以及基於所述接收的帳戶請求消息，從所述在線收 費管理伺服器向所述獨立在線收費帳戶管理伺服器傳輸在線帳戶餘額 消息。
21. 根據權利要求20所述的電腦程式產品，進一步被安排以實現 下列步驟在所述獨立在線收費帳戶管理伺服器處接收所述在線帳戶餘額消 息；以及在所述獨立在線收費帳戶管理伺服器處，基於所述所接收的在線帳 戶餘額消息，執行至少一個帳戶管理功能。
22. 根據權利要求21所述的電腦程式產品，進一步被安排以在執 行所述至少一個帳戶管理功能的所述步驟的基礎上，實現從所述獨立在 線收費帳戶管理伺服器向所述在線收費管理伺服器傳輸在線帳戶餘額 消息的所述步驟。
23. —種組合的在線和離線收費伺服器，包括在線收費帳戶管理伺服器，包括接收裝置，被安排以接收來自至 少一個另外的獨立伺服器的在線帳戶餘額消息，所述在線帳戶餘額消息 基於所接收的從網絡服務提供商傳輸的帳戶請求消息，以及處理裝置， 被安排以基於所述接收的在線帳戶餘額消息來執行在線帳戶餘額動作； 以及離線收費帳戶管理伺服器。
全文摘要
一種在線收費管理伺服器，包括接收裝置，被安排以接收從網絡服務提供商傳輸的至少一個帳戶請求消息；以及傳輸裝置，被安排基於所接收的帳戶請求，向另外的獨立伺服器傳輸在線帳戶餘額消息。
文檔編號H04M17/00GK101213863SQ200680023972
公開日2008年7月2日 申請日期2006年7月24日 優先權日2005年8月19日
發明者A·納爾伊, J-P·科斯基南 申請人:諾基亞公司