亚洲狠狠干,亚洲国产福利精品一区二区,国产八区,激情文学亚洲色图

有效地處理大量復雜的小值的金融交易的方法和系統(tǒng)的制作方法

文檔序號:6495261閱讀:896來源:國知局
有效地處理大量復雜的小值的金融交易的方法和系統(tǒng)的制作方法
【專利摘要】本發(fā)明提供了一種用于對合同的金融條款進行建模的系統(tǒng)的裝置。系統(tǒng)接收合同以及受合同所控制的交易的細節(jié)為輸入,并輸出經(jīng)處理的交易。該系統(tǒng)將合同的金融條款建模為一個或多個參數(shù)的函數(shù)。參數(shù)中的每一個都進一步被減少為一個或多個規(guī)則,每個規(guī)則代表的合同條款為一組條件及相關(guān)的操作。當相應的條件被滿足時,由系統(tǒng)執(zhí)行操作。系統(tǒng)通過分析相關(guān)于給定輸入交易的條件-操作集的結(jié)果來確定各種參數(shù)的值。
【專利說明】有效地處理大量復雜的小值的金融交易的方法和系統(tǒng)
[0001]對相關(guān)申請的交互引用
[0002]本申請要求2011年3月16日遞交的美國臨時專利申請61 / 453,427的優(yōu)先權(quán),其內(nèi)容通過引用被明確地合并于此。
【技術(shù)領(lǐng)域】
[0003]本文公開的技術(shù)涉及金融處理方法和系統(tǒng),特別是處理大量復雜的受買方和賣方之間的合同所管理的小值交易的系統(tǒng)。
【背景技術(shù)】
[0004]本文所公開的技術(shù)是由在最近幾年出現(xiàn)在線數(shù)字市場和網(wǎng)絡(luò)中的一類新的金融交易所激發(fā)的,其導致從傳統(tǒng)分銷模式的寬帶網(wǎng)絡(luò)的覆蓋。這些類型的金融交易具有以下特點:(1)小值,通常在幾毛錢不到一美元的范圍;(2)雙向,買方可以是賣方,反之亦然;(3)復雜,受買方和賣方之間的一套復雜正向的合同所管理;及(4)大的交易量,通常在每天數(shù)十億的范圍。
[0005]在這種分銷模式中的寬帶網(wǎng)絡(luò)的采用大幅減少了購買和銷售商品和服務的交易成本?,F(xiàn)在買方(如消費者)具有消費選擇以“字節(jié)大小”量進行消費,而賣方可以以“字節(jié)大小”量獲利地出售他們的商品和服務。其結(jié)果是個別交易價值的顯著減少,但整體交易量的增加。
[0006]這一類的網(wǎng)上交易市場也產(chǎn)生了更復雜的業(yè)務模式和買方和賣方之間的合同關(guān)系。首先,交易市場參與者可以是買方,賣方或雙方。其次,新的商業(yè)模式,如贊助、關(guān)聯(lián)公司、商品和服務的聚集涉及單交易各方。最后,買方和賣方之間的合同關(guān)系是復雜且不斷變化的。
[0007]現(xiàn)有技術(shù)將這些合同關(guān)系建模為定制軟件,其中,例如,每個合約條款被編程作為子程序,然后當合同條款將被建模時,再由建模軟件調(diào)用。這種實施作用于非常簡單,靜態(tài),單向的合同關(guān)系,但他們不足以支持當前復雜的在線市場。其一,在任何給定的交易中,有可能存在具有由他們自己的、獨立的合同關(guān)系管理的每一交易方的多方。這樣的情況下,將要求這些不同合同的每以個的編程及其相關(guān)的子程序,以支持在網(wǎng)上市場的交易。此外,在任何一方改變他們的合同關(guān)系的條款的情況下,不僅需要重新編程管理合同的改變條款的子程序,利用重新編程的子程序的整個軟件還需要被重新編譯。
[0008]重新編譯對于將最新的子程序合并至建模軟件而言是必須的。支持當前復雜的網(wǎng)上市場世界的軟件源代碼的這種重新編譯是十分重要的。其一,當重新編譯軟件時,該軟件需要停止和重新啟動以反映合同條款的改變。此外,當交易的一部分已經(jīng)被處理時,在軟件被停止的情況下由軟件處理的所有交易需要被停止并有時回滾。最后,在不斷變化的網(wǎng)上市場中,該軟件可能需要不斷被重新編程以反映不斷發(fā)展的合同關(guān)系,使得利用預編程軟件包建模合同關(guān)系實際上并不可行。所公開的技術(shù)代表了通用的金融應用程序,其解決現(xiàn)有技術(shù)的各種缺點,而填充市場中的市售金融服務中的空白(參見圖1)。[0009]這些金融服務通常根據(jù)一方面金融服務必須支持的買方和賣方之間的金融服務的定價關(guān)系以及另一方面其他的商業(yè)模式來被歸類。支付解決方案和ERP被設(shè)計為支持基于現(xiàn)貨價格的購買和銷售:買方和賣方同意在交易發(fā)生時的交易價格以及支付解決方案處理交易。消費者支付解決方案,如信用卡和借記卡,使商家出售商品和服務給消費者(一到多)。解決方案如ACH和ERP啟用企業(yè)對企業(yè)的付款解決方案,而小額支付解決方案如PAYPAL啟用點對點等消費支付。計費系統(tǒng)允許服務提供商根據(jù)服務提供商和他們的客戶之間的預先約定的合同評估交易的價值,并收取客戶的款項(一到多)。然而,相對于消費者的支付解決方案,計費系統(tǒng)支持服務提供商和客戶之間的正向合同。所公開的技術(shù)填充存在在點對點的付款和計費系統(tǒng)的交叉點上的空白。它使任何個人和企業(yè)基于預先安排的協(xié)議銷售商品和服務至另一方,在交易前,在交易發(fā)生的各種情況下指定交易將如何進行評估。
[0010]這樣的網(wǎng)上交易市場的兩個例子發(fā)生在媒體和能源市場中,在這樣的網(wǎng)上交易市場中購買和銷售是基于降低的價值的復雜的金融合同和交易。在公用事業(yè)市場,新一代的智能電網(wǎng)已導致超過傳統(tǒng)電網(wǎng)的寬帶網(wǎng)絡(luò)的覆蓋(見圖2)。在這些智能電網(wǎng)中的買方和賣方是受更復雜的合同關(guān)系所管理,交易價值要小得多,交易量更大。在過去,公用事業(yè)單位是能源的唯一的賣方以及消費者的唯一買方,合同關(guān)系簡單得多(通常是靜態(tài)的定價)以及家用電源電表每月只讀取一次以計算在該月份的能源使用。公用事業(yè)計費系統(tǒng)被用來計算應收客戶的每月的能源消耗。新的智能電網(wǎng)使公用事業(yè)單位以更加頻繁的時間間隔讀取功率計,由于大幅降低抄表成本,以及已更小的增量,如每隔一小時或每15分鐘出售電力-經(jīng)常在不同的動態(tài)定價稅。除向客戶銷售能源之外,公用事業(yè)單位可以買到其客戶通過屋頂?shù)奶柲茈姵匕逶趦?nèi)部產(chǎn)生的能量。雖然公用事業(yè)單位的銷售是基于零售電價,購買是基于被稱為上網(wǎng)電價的價格結(jié)構(gòu)。單獨的電表是專門測量由公用事業(yè)單位購買的并由公用事業(yè)單位在時間間隔讀取的能源和不同的定價點以計算向客戶累計的支付。
[0011]在一個更復雜的商業(yè)模式中,客戶可以使用用于自我消耗的內(nèi)部產(chǎn)生的能源,因此少從公用事業(yè)單位購買或以上網(wǎng)電價出售內(nèi)部產(chǎn)生的所有量至公用事業(yè)單位并以零售電價從公用事業(yè)單位購買更多的能源。
[0012]上述模型的變化涉及客戶銷售非能源(或能源相關(guān))的商品和服務。除了銷售內(nèi)部產(chǎn)生的能源至公用事業(yè)單位,客戶銷售某些權(quán)利,基于被稱為需求響應合同的合同性協(xié)議,至公用事業(yè)單位已使得公用事業(yè)單位可以在有限供應的時間非自愿地減少客戶的能源消耗。其他與能源相關(guān)的商品和服務包括配套服務、可再生能源信貸和溫室氣體。
[0013]甚至更復雜的模型涉及了客戶銷售能源到另一個客戶。在這樣的模式中,客戶A內(nèi)部產(chǎn)生能源可以出售到另一客戶B,根據(jù)兩者之間的單獨的合同,并因此銷售較少能源至公用事業(yè)單位,但允許客戶B從相同的公用事業(yè)單位少買能源。在這種應用中,獨立的電表專用于測量由客戶出售給他的鄰居的能源量。公用事業(yè)單位可以以某定期間隔讀取電表并計算代表客戶B欠客戶A的量。
[0014]另一個例子是在媒體市場中(見圖3)。新一代網(wǎng)絡(luò)的增加帶寬不僅使得通過網(wǎng)上交易市場提供數(shù)字化商品,如內(nèi)容,應用和廣告是可行的,而且還降低了交易成本。由于總是在網(wǎng)絡(luò)上,使得在線和移動消費者需要分拆傳統(tǒng)內(nèi)容,媒體,娛樂和交易成本的降低成為可能。他們購買音樂單曲而不是CD或相冊等捆綁音樂;他們需要鈴聲或音樂片段,而不是全軌音樂;他們收聽播客,而不是預先編排的廣播電臺;他們選擇劇集或視頻剪輯,而不是線性的電視節(jié)目。這種分拆的內(nèi)容、應用和媒體顯著降低個別交易的價值并增加交易量。
[0015]在線數(shù)字商品的生產(chǎn)商和消費者之間的價值交換往往是雙向的。消費者可以是生產(chǎn)商,反之亦然。事實上,在交易中的一方,既可以是數(shù)字商品消費者同時也是生產(chǎn)商。
[0016]這一類的在線交易市場通常是由一個或多個中介介導,一起工作協(xié)調(diào)提供至消費者的數(shù)字商品。參與者之間的關(guān)系通常被復雜的、預先商定的金融協(xié)議所定義。與消費者交換的價值和在生產(chǎn)商和中介之間的價值分布通常在交易前預先商定,因此必須基于交易中所涉及的情況進行動態(tài)評估。由于多個參與者和多個相互關(guān)聯(lián)的交易市場工作的人士提供數(shù)字商品,交易的價值必須分布在那些作出貢獻的人之間。
[0017]這種金融交易處理技術(shù)必須是具有相應高可靠性和完整性的高吞吐量。此外,該技術(shù)必須是高效的,從而可以經(jīng)濟地和盈利地處理小額交易。
[0018]本技術(shù)公開了一種方法和系統(tǒng)以根據(jù)買方和賣方之間的預先約定的合同協(xié)議,在任意復雜的交易關(guān)系基礎(chǔ)上,弄清相關(guān)于兩方或多方之間的購買和銷售商品和服務的金融交易。由于這樣的買方和賣方之間的合同協(xié)議是取決于交易發(fā)生的情況,交易價值通常不會被明顯得知,只有在交易后以及基于將合同的金融條款應用至交易記錄才會變得清晰。該等合同協(xié)議通常跨越相當一段時間,在此期間的買方和賣方可以進行大量的重復交易。交易各方可以是買方和賣方之間或多個買方和賣方之間。交易可以是雙向的,買方可以是賣方,反之亦然。最后,交易關(guān)系的拓撲結(jié)構(gòu),如由交易各方之間的預協(xié)議所定義,可以是任意復雜的而事實上往往級聯(lián)的。
[0019]公開的技術(shù)的受益者從投資者擁有的公用事業(yè)單位(IOUs)到市政公用事業(yè)單位;從充電式電動汽車(PEV)充電網(wǎng)絡(luò)到批發(fā)能源市場;從能源服務提供商到需求響應服務集成商;從傳統(tǒng)媒體公司,如唱片公司、電影制片廠、電視網(wǎng)絡(luò)、報紙、雜志和圖書出版商到在線應用商店;從內(nèi)容聚合網(wǎng)絡(luò)公司到廣告網(wǎng)絡(luò)公司。

【發(fā)明內(nèi)容】

[0020]本發(fā)明提供了一種通用的裝置,用于將合同條款建模為一個或多個參數(shù)的函數(shù),其中一個或多個參數(shù)中的每一個被一個或多個規(guī)則所定義。規(guī)則引擎然后評估并執(zhí)行這些規(guī)則,這些規(guī)則,例如,表示為“如果-則”的語句。根據(jù)規(guī)則,規(guī)則引擎內(nèi)部確定順序或規(guī)則相關(guān)性。接下來,規(guī)則引擎基于所需規(guī)則的輸入以及從以前規(guī)則的評價所獲得的結(jié)果,決定來自規(guī)則集合的哪一個規(guī)則進行評估。因此,將合同條款建模為由規(guī)則引擎所解釋的規(guī)則的基本思想是從它的實現(xiàn)邏輯中分離合同的建模。這種分離,反過來,使將合同條款的變化建模為從規(guī)則集合中簡單添加或刪除規(guī)則,而無需實現(xiàn)邏輯源代碼的任何改變。
[0021]因此,規(guī)則引擎可以被看作是復雜的如果-則語句的解釋器。規(guī)則被表示為如果-則語句。規(guī)則,如描述的那樣,是由兩部分組成,條件和操作:當條件滿足時,執(zhí)行操作?!叭绻辈糠职瑮l件(例如,花費金額>=$100),以及“則”部分包含操作(如,優(yōu)惠折扣5% )。規(guī)則引擎接收稱為規(guī)則執(zhí)行集和輸入數(shù)據(jù)的規(guī)則集合(例如,實際花了多少錢)作為輸入。規(guī)則引擎解釋規(guī)則的關(guān)系,適用輸入數(shù)據(jù)至解釋的規(guī)則,并確定最終的輸出(例如,提供給客戶的最終折扣)。因此,本發(fā)明提供了一種通用裝置,用于建模合同條款,而不需要實施邏輯的源代碼的任何改變。【專利附圖】

【附圖說明】
[0022]圖1是市售的金融服務組合,擬議的金融結(jié)算技術(shù)填補了一項空白,其間買方和賣方之間的關(guān)系是基于復雜的正向合同,買方可以是賣方,反之亦然。此外,涉及的交易通常是大量的小額交易。圖1說明公開技術(shù)的新的金融服務旨在啟用。
[0023]圖2顯示了在智能電網(wǎng)應用中的簡單交易社區(qū)的拓撲結(jié)構(gòu)。寬帶覆蓋已經(jīng)將單向電力分布電網(wǎng)轉(zhuǎn)為消費者不僅可以購買電力也可以出售光伏屋頂產(chǎn)生的電力的市場,如果他們參與需求響應程序則通過切除負荷的權(quán)利,并通過配套或存儲的服務或可再生能源認證-所有的都具有復雜,動態(tài)的價格或合同。箭頭指示支付方向。
[0024]圖3顯示了在數(shù)字媒體應用中的簡單的交易社區(qū)的拓撲結(jié)構(gòu)。通過寬帶網(wǎng)絡(luò)的數(shù)字媒體分布將在線音樂商店引入市場,其中內(nèi)容可以從轉(zhuǎn)售給消費者的內(nèi)容提供商處購買,其中消費者可以生成內(nèi)容和廣告印象,以及其中內(nèi)容提供商也可以購買廣告庫存。箭頭指示支付方向。
[0025]圖4顯示了典型環(huán)境:智能電網(wǎng),據(jù)此公開的技術(shù)的金融處理系統(tǒng)可以被利用。
[0026]圖5顯示了另一種代表性的環(huán)境:數(shù)字媒體,據(jù)此公開的技術(shù)金融處理系統(tǒng)可以被利用。
[0027]圖6顯示了建模合同的金融條款的通用方法,從買方支付給賣方的合同付款可以被一個或多個決策樹的算術(shù)函數(shù)所表示,決策樹包括交易的合同有效量,有效價格和有效的調(diào)整后的縮放因子。
[0028]圖7顯示了零售電價的例子,買方(客戶)和賣方(公用事業(yè)單位)之間的合同,被由決策樹進行表示。在這種情況下,電價取決于在一年中的季節(jié)、使用時間和買方客戶使用的電壓電平而不同。
[0029]圖8顯示了電力上網(wǎng)電價的例子,買方(公用事業(yè)單位)和賣方(客戶)之間的由客戶內(nèi)部產(chǎn)生的能源的合同,被在決策樹中表示。公用事業(yè)單位買方從它的客戶賣方購買的電價取決于一年中的季節(jié)、交貨時間、合同開始年度和合同條款而不同。
[0030]圖9顯示了由決策樹、買方(公用事業(yè)單位)和賣方(客戶)之間用于銷售他的權(quán)利至他的能源消耗的合同表示的需求響應合同。由公用事業(yè)單位到客戶的這種權(quán)利的合同支付是承諾負荷減少和承諾價格的產(chǎn)品。承諾價格本身是四個決策樹的產(chǎn)品:承諾負載基準價格和三個修改器。承諾負載基準價隨需求響應事件的通知時間而變化。修改器#1隨著在月內(nèi)的需求響應事件調(diào)用的數(shù)量而改變,修改器#2隨著需求響應事件的頻率而改變,修改器#3隨著需求響應事件調(diào)用時間而改變。
[0031]圖10顯示了買方(音樂廠牌)和賣方(藝術(shù)家)之間的銷售音樂權(quán)的音樂特許合同的一部分的例子。由買方支付給賣方的整體特許費的三個決策樹:有效的特許費率,有效的價格和有效的單位。有效特許費率本身是基本US費率、升級因素、通道減少和區(qū)域減少的算術(shù)函數(shù),每一個都是決策樹本身。此圖顯示了其中的兩個決策樹:有效價格和有效單位。
[0032]圖11顯不了表不圖10中的首樂特許例的基本特許費率、基本US費率、升級因素的決策樹。
[0033]圖12顯示了表示圖10中的音樂特許例的通道減少和區(qū)域減少的決策樹。
[0034]圖13顯示了由音樂廠牌的廣告贊助的被許可人的音樂特許應付費的例子,其是基于兩個決策樹的較大一個所確定的。第一個代表至少每次播放的許可費,而第二個代表廣告收入的部分的收入份額計算。
[0035]圖14顯示了合同規(guī)則引擎和處理節(jié)點之間的整合的例子,其中處理節(jié)點用合同的標識號和相關(guān)的輸入?yún)?shù)查詢規(guī)則引擎并以合同的金融條款進行更新。條款被用來計算交易價。規(guī)則文件被用來更新規(guī)則引擎中的合同。
[0036]圖15顯示了公開技術(shù)所澄清的兩方和多方交易的例子。多方例子包括兩個子例,一個代表在級聯(lián)供應鏈中的多供應商,而另一個則代表在平行供應鏈中的多供應商。
[0037]圖16是表示雙方金融結(jié)算過程的流程圖,其中公開的技術(shù)首先通過檢索買方ID、賣方ID和事件類型進行查找,然后通過查詢合同規(guī)則引擎獲得合同條款并最終計算交易價值,從而適當價格可以從買方賬戶存入賣方帳戶。
[0038]圖17是表示多方金融結(jié)算流程的流程圖。在處理這樣的多方交易中,公開的技術(shù)分解多方交易為包括相關(guān)的雙向交易。
[0039]圖18顯示了一微小(atom)工作之結(jié)構(gòu),其中的買方和賣方的標識,他們進行交易前的原來的賬戶余額,原來的交易記錄,以及其他相關(guān)信息打包成單個的軟件包。交易處理的結(jié)果,以帳戶結(jié)余(或者新的結(jié)余量)的變化的形式,可被暫時存儲直到結(jié)果可以被存儲文件更新為止。這種微小計算作業(yè)建設(shè)是自包含單元并且可以被發(fā)送到遠程處理節(jié)點。該軟件包包含了所有需要的信息以處理交易以及規(guī)定以臨時存儲中間和最終的處理結(jié)果用于審計目的和旨在提高交易處理吞吐量。
[0040]圖19顯示了用于基于文件的交易處理的系統(tǒng)的分布式版本的實施例。借助分布式系統(tǒng),電腦通過合并來自主存儲文件的信息并將它們分派給使用分布式文件系統(tǒng)的處理節(jié)點將輸入交易打包成微小計算作業(yè)。處理節(jié)點應用交易處理規(guī)則進行交易,決定在所有相關(guān)賬戶余額的金融狀況并將帳戶余額借記和貸記增量存儲在微小作業(yè)中。第二計算機從微小計算作業(yè)收集處理結(jié)果并更新存儲文件。第一和第二計算機可以是一個且相同的。公開技術(shù)突出檢查點的方案以提高交易處理的可靠性。在微小作業(yè)被發(fā)送至處理節(jié)點之前,復制是出于檢查點的目的。每個處理節(jié)點基于包含在微小作業(yè)中的信息獨立地處理交易。如果交易成功處理,那么買方和賣方的金融狀況在微小作業(yè)中被更新。如果交易沒有成功處理,處理任務通過提取以前的檢查點作業(yè)被重新啟動并且交易被重新處理。這種工作重新啟動和交易重新處理確保所有交易被成功和可靠的處理。
[0041]圖20是交易排序和重新排序的圖解說明,其中交易根據(jù)交易屬性(例如買方和賣方的識別,合同識別,時間戳及其他)被存儲并重新排序。這種排序和重新排序集合喜歡交易集中以使得交易規(guī)則可以通通適用于他們以進一步提高交易處理效率并同時重新建立交易的時間順序,因此,時間和順序敏感的交易處理規(guī)則可以被正確應用。
[0042]圖21顯示了預處理流程圖,其中來自零售和批發(fā)電表的數(shù)據(jù)被導入并被歸一化到通用數(shù)據(jù)格式,驗證參考數(shù)據(jù)存儲在文件或分布式文件系統(tǒng)中,以及如果數(shù)據(jù)丟失或錯誤的話自動校正基于預處理規(guī)則。如果數(shù)據(jù)不能被自動校正,錯誤的電表數(shù)據(jù)暫存在暫存文件或分布式文件系統(tǒng)中,以及單獨的手動編輯過程被用來糾正錯誤。正確的電表數(shù)據(jù)稍后被檢查并消除重復,檢查異常大或小的值,并以其他相關(guān)信息進行豐富以作進一步處理。最后,同一電表數(shù)據(jù)匯總到合同條款所應用至的交易記錄上(參見圖19)。
[0043]圖22顯示了分布式文件系統(tǒng)和集群計算機的使用以處理大規(guī)模和高吞吐量中的儀表數(shù)據(jù)。在一個實施例中,一個節(jié)點通過分布式文件系統(tǒng)分區(qū)和分配電表數(shù)據(jù)至一個或多個處理節(jié)點,其中如在圖21中描述的處理被用來處理電表數(shù)據(jù)。處理的數(shù)據(jù)稍后根據(jù)某些共同標準由一個或多個節(jié)點收集并匯集成輸出交易記錄。預處理規(guī)則被配置成規(guī)則引擎和通過以處理節(jié)點集成規(guī)則引擎的副本進行分布。
[0044]圖23顯示了所公開的技術(shù)的體系結(jié)構(gòu),其包含三個主要部分:市場管理系統(tǒng),主存儲文件和分布式執(zhí)行引擎。市場管理系統(tǒng)是基于網(wǎng)頁的應用程序,其被用于管理市場中的實體以及參與買和賣的交易實體之間的合同的金融條款。所配置的數(shù)據(jù)模型被存儲在存儲文件、一組文件或數(shù)據(jù)庫中。在存儲文件中所載的合同和結(jié)余信息被用于正確處理輸入交易。執(zhí)行引擎由計算機組成,計算機驗證交易、清除錯誤和翻新交易數(shù)據(jù)記錄至交易;打包交易到微小計算作業(yè);發(fā)送它們至處理節(jié)點并行處理并收集它們且更新處理結(jié)果到存儲文件中。
[0045]圖24顯示了使用決策樹建模合同模板的公開方法,其可以結(jié)合價格參數(shù)以建模共同結(jié)構(gòu)的合同以及不同的價格參數(shù)。
[0046]圖25顯示了能源市場的交易結(jié)算技術(shù)的應用。
[0047]圖26顯示了音樂許可市場的交易結(jié)算技術(shù)的應用。
[0048]圖27是可以用來實現(xiàn)執(zhí)行本文所描述的某些技術(shù)的金融計算系統(tǒng)的處理系統(tǒng)的框圖。
[0049]圖28顯示了用來建模合同條款的金融計算系統(tǒng)。
【具體實施方式】
[0050]現(xiàn)在將描述本發(fā)明的各個方面。下面的描述提供透徹理解的具體細節(jié)以及這些實施例的啟用描述。然而,本領(lǐng)域技術(shù)人員將理解無需許多這些細節(jié)也可以實施本發(fā)明。此夕卜,一些公知的結(jié)構(gòu)或功能可能不被示出或詳細描述,以避免不必要地模糊相關(guān)描述。雖然圖中示出功能上獨立的組件,這樣的描述是僅僅是用于說明目的的。對于本領(lǐng)域中的技術(shù)人員而言在該圖中描繪的組件可以被任意組合或分成單獨的組件是顯而易見的。
[0051]在下面的描述中使用的術(shù)語的目的是以其最廣泛的合理方式來解釋,即使它被結(jié)合用在本發(fā)明的某些特定實施例的詳細描述中。某些條款甚至可能被強調(diào);然而,任何旨在以任何限制的方式來解釋的術(shù)語將被公開和具體定義為在此詳細說明部分中的一樣。
[0052]在本說明書中所提到的“一個實施例”,“一個實施例”或類似表示該特定特征,結(jié)構(gòu)或特性被包括在所描述的本發(fā)明的至少一個實施例的。在本說明書中出現(xiàn)的這類短語不一定都是指相同的實施例。
[0053]公開的技術(shù)設(shè)想了各種改進的方法和系統(tǒng),用于通過使用通用方法建模買方和賣方之間的合同條款并通過應用合同處理與有效高吞吐量低交易成本系統(tǒng)的交易來澄清一類新的金融交易。所指定的該類交易被賦予如上特色。廣義的合同建模技術(shù)是基于基于決策樹的規(guī)則的算術(shù)結(jié)合。該技術(shù)通過分布式文件系統(tǒng)的使用提高了效率和吞吐量。該技術(shù)可以用來建模任何復雜的買方和賣方之間的雙向合同的或多個買主和賣主之間的多邊合同,并增加吞吐量和降低交易處理成本。在一個使用分布式文件系統(tǒng)和多處理計算機實施例中,該技術(shù)可以通過并行分發(fā)處理大量的計算機工作進一步提高吞吐量。
[0054]圖4顯示了具有代表性的智能電網(wǎng)市場,所公開的金融處理技術(shù)可被用于其中。雖然所公開的技術(shù)被描述為與涉及在能量網(wǎng)中購買和銷售能源和非能源的處理交易相關(guān),本領(lǐng)域技術(shù)人員將認識到所公開的技術(shù)可以用在其它領(lǐng)域,如專利知識產(chǎn)權(quán)、企業(yè)軟件和
云計算等。
[0055]在圖4中公開的示例性實施例中,公用事業(yè)單位10提供能量至一些住宅用戶12-14。使用智能電網(wǎng),公用事業(yè)單位10可以以定期的時間間隔讀取每一住戶或企業(yè)的電表。這樣的時間間隔取決公用事業(yè)單位收取的能源動態(tài)電價結(jié)構(gòu)可能是每周一次,一天一次,一天幾次,一小時幾次。例如,公用事業(yè)單位可能會在能源消耗高峰時段(11點到下午6點、周末等)收取不同的價格。為了能夠正確地向客戶收費,公用事業(yè)單位在定期的時間間隔讀取每個住戶的電表以確定在抄表前在每個周期內(nèi)被消耗多少電力。其結(jié)果是在不同的價格點的大量的小值交易必須被進行處理以產(chǎn)生最終的客戶公用事業(yè)帳單。
[0056]在圖6公開的示例性實施例中,數(shù)字產(chǎn)品市場11 (如廣告網(wǎng)絡(luò)、內(nèi)容聚合網(wǎng)絡(luò))以及權(quán)利市場,購買內(nèi)容、相關(guān)的權(quán)利,至其客戶。另外,市場的運營商可以從供應商購買廣告庫存并出售給廣告商。在這兩種情況下,參與三方交易的三方(權(quán)利人-市場-客戶或存貨供應商-市場-廣告)是基于收益共享協(xié)議(取決于市場所產(chǎn)生的收入,累計至權(quán)利人和廣告庫存供應商的付款)。交易記錄,以廣告服務器日志和內(nèi)容交付服務器日志的形式,被收集在中央存管庫中。
[0057]上述使用場景的一個變化是,所公開的技術(shù)可用于第三方金融信息交流,而不是公用事業(yè)單位以基于各自的雙邊或多邊合約計算在公用事業(yè)單位及其客戶之間的一個累計至另一個的支付金額和相應的電表讀數(shù)。
[0058]建模合同的金融條款
[0059]在商品和服務的買方和賣方之間的合約通常涉及買方支付賣方的金融條款。這些金融條款代表買方對賣方的合同義務。有時這些金融合同條款可能會非常復雜,因為買方和賣方不會提早知道交易的價值,因此達成如何估價交易的一致取決于大量的偶然交易。合同可以是能源供應商和客戶之間的許可協(xié)議、特許協(xié)議、租賃協(xié)議、定價條款、能源價格,以及購電協(xié)議的形式。復雜的金融條款使得建模、表示、證明、實施和執(zhí)行符合合同金融義務變得困難。
[0060]公開的技術(shù)涉及的合同的金融條款使用規(guī)則被建模的過程。本發(fā)明提供了一種通用裝置,用于將合同條款建模為一個或多個參數(shù)的函數(shù),其中一個或多個參數(shù)的每一個被一個或多個規(guī)則所定義。然后規(guī)則引擎評估并執(zhí)行這些規(guī)則,這些規(guī)則是,例如,由“如果-則”的語句所表示?;谝?guī)則,規(guī)則引擎內(nèi)部確定規(guī)則的順序或?qū)傩?。接下來,?guī)則引擎基于所需的輸入規(guī)則以及從之前規(guī)則的評估所獲得的結(jié)果確定來自規(guī)則集的哪個規(guī)則用于評估。因此,由規(guī)則引擎所解釋的將合同條款建模為規(guī)則的基本思想是從它的實現(xiàn)邏輯分離合同的建模。反過來,這種分離使建模合同條款的改變成為從規(guī)則集簡單的添加或刪除規(guī)則,而無需任何實現(xiàn)邏輯的源代碼的改變。
[0061]圖28是金融計算系統(tǒng)2801的說明性實施例,其中合同的金融條款被表示為如果-則規(guī)則語句。金融計算系統(tǒng)2801包括合同規(guī)則引擎2810和金融計算引擎2820。金融計算系統(tǒng)2801接收金融交易2830的細節(jié)及管理金融交易2830的合同2840的條款作為輸入。金融計算系統(tǒng)2801采用金融計算引擎2830來分析交易細節(jié)的金融交易。此外,金融計算系統(tǒng)2801利用金融計算引擎2820解析合同條款為各種參數(shù)的函數(shù)。金融計算引擎2820解析參數(shù)為對應于每一個被解析的參數(shù)的規(guī)則集合。此外,金融計算系統(tǒng)2801基于由合同規(guī)則引擎2810所提供的解釋規(guī)則利用金融計算引擎2820處理交易細節(jié)。
[0062]金融計算引擎2820轉(zhuǎn)發(fā)對應于各種參數(shù)的規(guī)則的集合至合同規(guī)則引擎2810。合同規(guī)則引擎2810采用規(guī)則引擎來解釋對應于每一個給定參數(shù)的各種規(guī)則之間的屬性。合同規(guī)則引擎2810轉(zhuǎn)發(fā)解釋規(guī)則的金融計算引擎2820。使用規(guī)則之間的該被解釋的關(guān)系,金融計算引擎2820可以稍后應用交易細節(jié)以確定每個參數(shù)的結(jié)果值。在不同的實施例中,金融計算引擎2820可以轉(zhuǎn)發(fā)交易細節(jié)至合同規(guī)則引擎2810,其稍后可以采用交易細節(jié)至被解釋的規(guī)則以確定每個參數(shù)的結(jié)果值。合同規(guī)則引擎2810可以稍后轉(zhuǎn)發(fā)每個參數(shù)的計算值至金融計算引擎2820。金融計算引擎2820采用計算的參數(shù)值以確定最終的交易價值,參數(shù)是該最終交易價值的函數(shù)。金融計算引擎2820輸出最終的交易價值作為處理的交易2850的值。
[0063]在2801中公開的金融計算系統(tǒng)的一個例子將在下面被討論。金融系統(tǒng)2801接收有關(guān)交易的發(fā)票以及管理該發(fā)票的合同。金融計算系統(tǒng)2801轉(zhuǎn)發(fā)合同和交易細節(jié)至金融計算引擎2820。金融計算引擎解析合同為對應于每一參數(shù)和相關(guān)的交易狀態(tài)值的規(guī)則集。金融計算引擎2820轉(zhuǎn)發(fā)作為規(guī)則的合同條款至合同規(guī)則引擎2810。基于合同,表示合同條款的一個規(guī)則集合可能是,如果客戶的信用額度大于發(fā)票金額和發(fā)票狀態(tài)是“未付”,則以發(fā)票金額減少信用額度并將發(fā)票狀態(tài)設(shè)置為“已付”。來自表示相同合同條款的另一方面的規(guī)則集的第二規(guī)則可能是,如果客戶的信用額度是低于發(fā)票金額以及發(fā)票狀態(tài)是“未付”,則將信用額度減為零并保持發(fā)票狀態(tài)不變,即“未付”。
[0064]金融計算引擎2820也將交易狀態(tài)值轉(zhuǎn)發(fā)至合同規(guī)則引擎2810。合同規(guī)則引擎2810接收,交易狀態(tài)值作為輸入,交易狀態(tài)對應于客戶的信用額度、發(fā)票金額、以及發(fā)票的付款狀態(tài)。合同規(guī)則引擎2810被給定客戶的信用額度為5000美元,發(fā)票金額為2000美元、發(fā)票的付款狀態(tài)為“未付”。合同規(guī)則引擎2810解釋規(guī)則的關(guān)系,將輸入數(shù)據(jù)適用至被解釋的規(guī)則,并確定最終的輸出。因此,在分析規(guī)則集之上,合同規(guī)則引擎2810作出這兩個規(guī)則表示相互排斥的條件的決定。將交易狀態(tài)值應用至被解釋的規(guī)則關(guān)系,合同規(guī)則引擎2810確定客戶的最終信用額度和發(fā)票狀態(tài)。合約規(guī)則引擎2810轉(zhuǎn)發(fā)客戶的最終信用額度和發(fā)票狀態(tài)至金融計算引擎2820。金融計算引擎2820設(shè)置客戶的最終信用額度為$3000以發(fā)票狀態(tài)為“已付”。因此,金融計算系統(tǒng)代表用于建模合同條款的通用裝置,而無需實現(xiàn)邏輯的源代碼任何改變。
[0065]在用于建模合同條款的通用裝置的另一示例性實施例中,合同條款被建模為一個或多個參數(shù)的函數(shù),其中一個或多個參數(shù)中的每一個由決策樹所定義。決策樹代表的規(guī)則之間的關(guān)系。規(guī)則,如上所述,是由兩部分組成,條件和操作:當條件滿足時,操作被執(zhí)行。決策樹組成的分支,具有條件節(jié)點作為其根部,并終于操作。每個節(jié)點是一個條件節(jié)點,除葉節(jié)點以外。正如將被理解的是,決策樹是樹狀圖或模型,其最初被設(shè)計為建模決策的可能的結(jié)果、概率事件的結(jié)果、不同的條件的資源成本以及不同選擇的經(jīng)濟效用。公開技術(shù)重改決策樹的目的作為一種工具以建模合同的金融條款。更具體地說,決策樹是用來表示相關(guān)金融條款的各種參數(shù),包括買方和賣方之間每一個協(xié)議處理的商品和服務的有效金額、買方同意支付賣方每單位交換的貨物和服務的的實際稅率以及雙方同意可以用來修改各種突發(fā)事件和情景下的違約率的縮放因素。此外,公開的技術(shù)同時還采用了決策樹來描述替代方法以評估交易和買方和賣方之間的協(xié)議價值以作為應該被用來評估他們之間的交易(例如,較大較小或兩個替代估值方法的算術(shù)平均值)。
[0066]以這樣的程序,在利率被應用于交易的何種條件下,處理的有效單位以及被指定的縮放因子的占有率均被首先列出。決策樹稍后使用這些條件被構(gòu)建,其中每個樹的決策分支對應于相關(guān)聯(lián)的條件。最后,樹的葉節(jié)點被用于指定,例如,被處理的商品和服務的有效占有量,每一單位的違約率或每一協(xié)議的縮放因素。一旦合同的金融條款被建模,決策樹可以根據(jù)個案情況遍歷以迅速確定有效的處理金額、違約率和特定組合條件的縮放因子。
[0067]最后,公開的技術(shù)使用決策樹的算術(shù)運算結(jié)合以最廣義的方式建模合同的金融條款。以這樣的模型,買方對賣方的財政承諾可以通常以多個決策樹算術(shù)函數(shù)形式被表示。圖6示出一個例子,其中可以合同金融條款可以被個決策樹的算術(shù)函數(shù)進行表示。根據(jù)本發(fā)明的教導,合同規(guī)定的付款可以計算為多個參數(shù)的函數(shù),其中每個參數(shù)被描述為一個決策樹。在圖6的例子中,合同規(guī)定的付款是三個參數(shù)的算術(shù)函數(shù):“交易量”,“價格”和“縮放因子”。這三個變量分別是指定被處理的有效的商品和服務量、默認價格和分別被用在不同條件和場景下每一買方和賣方之間的協(xié)議的縮放因子的三個決策樹的每個運算函數(shù)。特殊情況涉及三個決策樹乘法函數(shù),而其他算術(shù)關(guān)系也可以被建模。
[0068]參考圖7-13,公開的技術(shù)被應用于建模各種真實合同的金融條款。
[0069]圖7是決策樹100的圖解說明,決策樹100建模公用事業(yè)單位零售電價的金融條款,公用事業(yè)單位(能源賣方)和客戶(能量買方)之間的合同是基于很多情況的,正如一組條件所定義的一樣。這些條件包括當交易發(fā)生和電壓等級應用到客戶買方時的一年中的季節(jié)和一天的時間。決策樹指定在這些情況下的定價。為了計算的定價條款,決策樹100必須根據(jù)情況被遍歷。
[0070]圖8是公用事業(yè)單位上網(wǎng)電價的金融條款的圖解說明,公用事業(yè)單位(能源賣方)和客戶(能量買方)之間的合同。與圖7類似,在圖8中的決策樹建模價格,公用事業(yè)單位以按該價格支付給其客戶以購買由他/她的屋頂太陽能光伏系統(tǒng)所產(chǎn)生的能源。在這種情況下,公用事業(yè)單位從客戶購買能源的價格取決于包括一年中的季節(jié)(夏季或冬季),一天的時間(高峰時段,半高峰時段和非高峰時段)以及最后合同開始的年份(2001年、2002年、2003年或2004年)的情況。
[0071]圖9是公用事業(yè)單位及其需求響應客戶之間的需求響應合同的金融條款的圖解說明,客戶(賣方)依該合同銷售權(quán)利以減少其至公用事業(yè)單位的能源消耗來換取公用事業(yè)付費。根據(jù)合同的條款,支付給客戶的公用事業(yè)付費是承諾價格、決策樹以及承諾負載的乘積,一個變量。承諾價格是包括承諾負載基本價格和三個修正系數(shù)的四個決策樹的乘積。承諾負載基本價格基于通知時間而變化,該時間是需求響應事件在負載減少之前被調(diào)用的時間。修正系數(shù)#1是基于事件被調(diào)用的數(shù)量,修正系數(shù)#2是這些事件被調(diào)用的頻率以及修正系數(shù)#3是事件被調(diào)用的天的時間。
[0072]圖10-12是使用所公開的技術(shù)的音樂廠牌(音樂作品的權(quán)利的買方)和藝術(shù)家(權(quán)利賣方)之間的許可合同的金融條款的共同的圖解說明。如圖10所示,從音樂廠牌到藝術(shù)家的合同規(guī)定的支付有三個關(guān)鍵組成部分:有效的交易單位,有效的許可費率和有效的許可。有效的許可費是由US區(qū)域內(nèi)基本價格、基于升級因素的體積、基于通道的折減系數(shù)和區(qū)域?qū)傩詼p少因子所確定的。每個組件本身是決策樹。根據(jù)該協(xié)議,在計算支付給藝術(shù)家的許可費中使用的有效單位是基于零售商店售出的單位數(shù)量較少的推廣單位,并允許收縮和依賴于分銷渠道。在計算許可費中使用的基本零售價被基于US標價和依賴特定的專輯或零售銷售的CD。在計算支付給藝術(shù)家的許可費中使用的有效許可費的本身是四個決策樹的算術(shù)函數(shù)?;綰S價格是基礎(chǔ)許可費并依賴于產(chǎn)品類(專輯或單品)及生產(chǎn)期(第一,第二,第三或第四)。升級是基于累計發(fā)行量在許可價中的提高,其是基于成交量閾值的分層(見圖11)。通道減少和區(qū)域減少是US基準費率的折扣以及依賴于US零售外的分銷渠道和US以外的區(qū)域(見圖12)。
[0073]圖13是音樂廠牌和在線廣告支持音樂零售商之間的許可合同的金融條款的圖解說明,正如使用公開技術(shù)說表示的一樣。根據(jù)許可合同,由音樂被許可人支付給音樂許可人的費用大于每播放最低費用并且是在線廣告收入的份額,每一個都是決策樹。每播放最小費是基于音樂流持續(xù)時間(大于25秒或少于25秒)進行計算的,交互性(交互或非交互)和自動播放模式(首次自動播放或非首次自動播放)。在線廣告收入份額是基于目錄類型(新版本或標準)和釋放窗口(超過30天或少于30天)進行計算的。
[0074]在一個實施例中,電子處理器用合適的數(shù)據(jù)模型和可執(zhí)行指令進行編程以允許用戶創(chuàng)建決策樹對不同的合約條款進行建模。建??梢酝ㄟ^提供圖形用戶界面來完成,圖形用戶界面使用戶能夠通過提示用戶輸入合同的特定元素和參數(shù)來建立有關(guān)的決策樹。決策樹可以被實時構(gòu)造和填充,并顯示給用戶以易于評論。另外,書面合同可以被映射到表單模板,其反過來可以轉(zhuǎn)化成決策樹。同樣,合同甚至可以根據(jù)特定語言如HTML或XML被撰寫,這使得準備轉(zhuǎn)換成決策樹的計算機表示。在步驟184中,金融合同條款的決策樹模型被表示內(nèi)存中并被保存在計算機系統(tǒng)的配置文件中。配置文件,數(shù)據(jù)模型和可執(zhí)行文件被作為庫打包,其被分配到各處理節(jié)點。
[0075]除了建模合同的金融條款,公開的技術(shù)也可以使用決策樹建模合同模版,參數(shù)化的決策樹被用來建模一類相似合同的通用結(jié)構(gòu)。圖24顯示了作為合同模板的決策樹的使用。通過結(jié)合合同模板和一組或多組的參數(shù),相同結(jié)構(gòu)的合同但不同價格的參數(shù)可以被建模。這樣的合同模版進一步加大公開技術(shù)有效處理大量合同的能力。
[0076]除了基于方法的決策樹,公開技術(shù)也要求涉及決策表及其他修正的制表格式的方案。
[0077]圖14是如何使用合同規(guī)則引擎的圖解說明。表示可以被發(fā)現(xiàn)作為可執(zhí)行代碼,并可以被直接從步驟182決策樹的建設(shè)中獲得。在步驟186中,特定金融交易的細節(jié)可以在計算機系統(tǒng)被接收。這些可以被手動輸入,但更可能是當前系統(tǒng)將執(zhí)行大量的交易,因此模型被耦合到執(zhí)行流水線,該執(zhí)行流水線從交易中獲得輸入條件,提供輸入條件的詳細信息至合同規(guī)則引擎并接收有關(guān)合同的金融條款的信息。在步驟188中,定價和調(diào)整因子通過遍歷決策樹而被確定。在步驟190中,根據(jù)合同的支付被計算。
[0078]結(jié)算金融交易
[0079]除了以廣義方式建模合同的金融條款,公開技術(shù)采用了一種新的方法根據(jù)合同條款對雙方和多方的金融交易進行結(jié)算以確定參與其中的各方的金融狀況。圖15顯示了這樣的雙方和多方交易。在買方A和賣方B之間的雙方交易中,根據(jù)合同BA,買方A從賣方B購買商品和服務并匯款支付到賣方B。在多方交易中,A從B某些商品和服務,其中一部分是從C購買的并且B從C購買的部分是來源于D。多方交易完成后,A根據(jù)合同BA支付給B, B基于合同CB支付給C以及C基于合同DC支付給D。在多方交易的第一回合中,A是買方而B是賣方,在第二回合中,B是買方而C是賣方,在第三回合中,C是買方而D是賣方。只有交易的首回合被在交易中記錄捕獲而隨后的交易的回合必須從交易記錄推斷。需要注意的是,只有A和B之間發(fā)生交易后C和D才獲得報酬。因此,所有的交易回合必須在同一時間被處理以維持該交易的完整性。
[0080]多方交易的一種變化涉及B從C和D進行購買并因此分別基于合同CB支付給C而基于合同DB支付給D。在這種情況下,A是買方而B是在多方交易的首回合的賣方,B是買方而C和D是在第二和第三回合中的賣方。同樣地,所有交易的回合必須在同一時間被處理以維持該交易的完整性。
[0081]多方交易的例子涉及將捆綁權(quán)利銷售給客戶A的銷售捆綁內(nèi)容(例如,音樂曲目)和單一內(nèi)容(例如,單個音樂曲目)的內(nèi)容聚合者B。內(nèi)容構(gòu)成是來自權(quán)利人C和/或權(quán)利人D的授權(quán)。
[0082]圖16為雙方金融結(jié)算程序的流程圖以及圖17是多方金融結(jié)算過程的流程圖。
[0083]如圖16所示,在賣方A和買方B之間的交易結(jié)算中的第一步,是基于買方ID、賣方ID和事件類型查找適當?shù)暮贤?。合同一旦被識別,為了適當?shù)慕鹑跅l款,處理管道通過遍歷決策樹和計算交易價值以合同ID查詢合同規(guī)則引擎。然后該交易價值被計算。從買方賬戶中扣除金額以及相同的金額被存入賣方的賬戶。
[0084]如圖17所示,公開技術(shù)分解多方交易結(jié)算為同時結(jié)算多個相關(guān)的雙方交易。原來的三方交易記錄必須首先被轉(zhuǎn)化為一組雙方交易記錄。這些衍生的交易記錄與買方ID、賣方ID和事件類型一起稍后被用于尋找合適的合同。然后合同條款在借記卡和信用卡業(yè)務被向買方和賣方作出之前被用于計算交易值。
[0085]為了避免部分交易并維護交易的完整性,公開技術(shù)以金融結(jié)算執(zhí)行引擎為特色,金融結(jié)算執(zhí)行引擎將衍生交易作為完整的交易集對待。如果這種雙方交易中的一個失敗,則其他的必須被中止,直到所有衍生雙方交易被正確處理。
[0086]圖25和圖26顯示了上述公開的復雜的、多方交易被定期處理的行業(yè)方案。圖25顯示了各方及能源市場上在他們之間的各種交易。圖26顯示了各方及在受版權(quán)保護的音樂許可中的他們之間的交易。
[0087]如圖25所示,能源市場是由多方組成,其中一些參與方參與了能源的購買和銷售,而其他方參與購買或出售能源但不能同時參加購買和銷售。此外,各方可以在能源市場同時與多方進行交易。
[0088]在能源市場的主要參與方之一是公用事業(yè)提供商2501,其經(jīng)常在能源市場上與多方交易。公用事業(yè)提供商2501通常以各種能源供應商與能源的終端消費者2513連接。公用事業(yè)提供商2501可能是多種類型。公用事業(yè)提供商2501可能是投資者擁有的公用事業(yè)(IOU)、公有制公用事業(yè)(POU)、市政公用事業(yè)(MOU),或商業(yè)合作公用事業(yè)(COU)。公用事業(yè)提供商通常通過電廠2514、柴油發(fā)電商(DG) 2512等滿足其能源需求。此類交易必須妥善處理以維持定期結(jié)算。
[0089]公用事業(yè)提供商2501還定期在整體出售能源市場2504(WSEM)交易能源,其中整體出售能源市場2504為各種能源供應商和消費者提供了平臺以在能源市場上進行交易。這種交易通常涉及解決多方交易,其中由公用事業(yè)提供商2501購買的總能源已被從多個獨立的能源供應商(如另一公用事業(yè)單位(U4) 2513、能源服務提供商(ESP)等)聚集在一起以滿足公用事業(yè)提供商2501的全部能源需求。解決此類交易時,WSEM需要聘請交易結(jié)算所,其中每個涉及多方的交易被分為雙向買方和賣方的集合。交易被進一步排序和執(zhí)行以使得始終保持交易的完整性。
[0090]公用事業(yè)提供商2501還定期與獨立電力生產(chǎn)商(IPP)2503交換能源,如個別住戶,其不僅是能源消費者也是能源的生產(chǎn)者和銷售者。IPP2503使用在獨立發(fā)電商2503物業(yè)上安裝的太陽能2510、風車2509、柴油發(fā)電機組(DG) 2511等等生產(chǎn)能源。此外,IPP2503可以在彼此之間買賣能源及使用公用事業(yè)提供商2501的基礎(chǔ)設(shè)施與在能源市場的其他各方買賣能源。公用事業(yè)提供商2501將收取IPP2503使用其基礎(chǔ)設(shè)施的費用。在這種情況下,公用事業(yè)提供商2501也作為IPPs2503能源的各種買方和賣方之間結(jié)算所。解決此類交易時,公用事業(yè)提供商2501需要聘用交易結(jié)算所,其中每個涉及多方的交易又分為雙向買方和賣方集合。交易被進一步排序和執(zhí)行以使得始終保持交易的完整性。
[0091]除個別終端消費者2513之外,一些公用事業(yè)提供商2501的最大客戶是企業(yè)2502,其可以是任何使用輸電系統(tǒng)能源的消費者。企業(yè)2502是能源的重度消費者,其通常從多個公用事業(yè)2506、2707購買能源。企業(yè)2502,類似于IPPs2503,有時也產(chǎn)生自己的能源并使用公用事業(yè)提供商2501的基礎(chǔ)設(shè)施使其輪轉(zhuǎn)至他們的位置。此外,企業(yè)2502與公用事業(yè)提供商2501進行交易以在另一個位直使用自有發(fā)電廠、太陽能電池所產(chǎn)生的能量抵消一個位置的能源消耗。每一個這樣復雜的交易需要企業(yè)2502采用結(jié)算所快速處理交易并同時保持過程的完整性。
[0092]如圖26所示,音樂許可市場是由多方組成,其中一些參與方參與購銷音樂許可證,而其他方參與任何購買或出售音樂許可證但不能同時參加購買和銷售。此外,各方可以同時在音樂許可市場與多方進行交易。
[0093]音樂許可市場中的主要參與方之一是唱片公司(Record Label) 2601,其定期與多方在許可市場進行交易。唱片公司2601在市場中通過自己的專賣店或者通過在線音樂商店2603,如iTunes、亞馬遜音樂等許可音樂出版者。此外,唱片公司2601可以購買和銷售其他獨立唱片公司2605所產(chǎn)生的音樂。對于每一次這樣的交易,其中,例如,唱片公司2601許可來自獨立公司2605并分許可在線音樂商店2603,唱片公司2601需要聘請結(jié)算所以確保來自在線支付音樂商店2603到獨立公司2605的合適支付。此外,在這樣的交易中,結(jié)算所應確保獨立公司2605僅在唱片公司2601由在線音樂商店2603支付后才會支付以及唱片公司2601在獨立公司2605接收其許可費之前收到其費用。
[0094]唱片公司2601還經(jīng)常從音樂聚集者2602購買和銷售許可,如音樂報告,其主要任務是根據(jù)他們客戶如廣播電臺2610、個人2608的許可要求確定和購買許可證。個人2608可以是電影制片人、翻唱樂隊等。類似于唱片公司2601,音樂聚合者2602定期需要結(jié)算涉及多方的交易,其中賣方可能是唱片公司2601和獨立唱片公司2605,而買方是廣播電臺2610,個人2608,在線音樂商店2603,直接市場2609等。
[0095]除了音樂聚合者2602,唱片公司2601也經(jīng)常從企業(yè)2604,如電影制片廠,購買和銷售許可證。企業(yè)2604反過來從音樂許可市場中的其他各方,如獨立唱片公司2606、在線音樂商店2603等,購買和出售許可證。企業(yè)2604還需要定期結(jié)算涉及多方的交易,賣方可以是獨立唱片公司2606,而買方可以走在線音樂商店2603等。[0096]圖25和圖26,如上文所公開的,從而顯示了行業(yè)方案,其中復雜的,多方交易可以被使用在我們的發(fā)明中所描述的交易結(jié)算機制被結(jié)算。
[0097]高吞吐暈低成本金融交易處理
[0098]除了建模買方和賣方之間的合同關(guān)系的通用方法外,將這些合同適用于確定交易價值,并為買方和賣方史新金融賬目,公開技術(shù)涉及高效、快速處理大量交易的方法。
[0099]處理金融交易的最傳統(tǒng)的方法是基于關(guān)系型數(shù)據(jù)庫。但是,這些現(xiàn)有的方法由于涉及存儲數(shù)據(jù)中的延遲和從數(shù)據(jù)庫的檢索,同時保持交易的完整性被顯著限制于吞吐量。
[0100]在交易可以被財政地處理之前,交易必須經(jīng)過一組預處理,包括交易記錄元素的驗證,如果錯誤則進行糾正,所需的附加信息的合并以正確適用合同。所公開的技術(shù)使用文件系統(tǒng)執(zhí)行這樣的預處理以增加交易預處理的吞吐量。
[0101]如圖4和5所示,該交易記錄被導入和由計算機系統(tǒng)20進行處理,計算系統(tǒng)20將交易打包成若干微小計算作業(yè):30、31和32等,其被發(fā)送到若干網(wǎng)絡(luò)計算機或在云計算環(huán)境50中的處理節(jié)點40、41和42。在一個實施例中,每個微小計算作業(yè)30、31、32包含足夠的信息來結(jié)算買方和賣方之間的金融交易。這些信息可包括買方或賣方的標識號和一或多個與買方或賣方達成購買或出售合同的對手方的標識號,各自合同的標識號管理能源買入和賣出交易的金融條款,買方和賣方否各自起始帳戶結(jié)余,其他的信息(如圖18所示)。微小計算作業(yè)30還包括一些特定的涉及到他的買入和賣出交易的買方和賣方的交易記錄。通過打包和儲存所有的輸入和輸出賬戶余額和與交易一起的交易處理的其他必要的信息,這樣的微小計算作業(yè)保存來自通過網(wǎng)絡(luò)遠程訪問帳戶余額的處理節(jié)點并從而提高處理能力。
[0102]在圖19中,微小計算作業(yè)被稍后發(fā)送到一個或多個處理計算機,在其中適當合同條款將通過以合同標識號和其他輸入?yún)?shù)查詢規(guī)則引擎來查找被查找,然后合同條款被應用到交易記錄和適當?shù)慕璺?,以及貸方按照合同條款被計算并通過追加微小計算作業(yè)被暫時儲存。最后,單獨的計算機記錄這些借方和貸方,并且相應的借方和貸方被存儲到在微小計算業(yè)中所存儲的賬戶中。在另一個實施例中,生成微小作業(yè)的處理節(jié)點可指示在云計算環(huán)境中的其他處理節(jié)點以處理一個或多個微小作業(yè)。
[0103]在市場上的買方和賣方之間的所有合同條款被在合同規(guī)則引擎中進行定義,其被發(fā)送到處理節(jié)點并與處理節(jié)點集成為庫。按照合同規(guī)則引擎所需的合同標識號和其他輸入被用于查詢規(guī)則引擎以獲得一組合同價格,其由處理節(jié)點所使用以正確和準確地計算交易價值。
[0104]完成處理一批微小計算作業(yè)之后,處理節(jié)點40以帳戶余額變化更新所有的存儲文件。更新的存儲文件稍后被運回非暫時性的存儲節(jié)點以及余額被轉(zhuǎn)移和更新至文件系統(tǒng)或數(shù)據(jù)庫。當一批新的交易將要處理時,存儲文件或數(shù)據(jù)庫被用于打包一批新的計算作業(yè)。
[0105]計算機系統(tǒng)20接收修改的存儲文件并為買方產(chǎn)生來自賣方的帳單。在一些實施例中,該生成的帳單可以聚合多個小型交易。在其它實施例中,客戶可被收取每一微小交易的帳單。
[0106]為了進一步提高交易吞吐量,所公開的技術(shù)使用例如交易分類和重新排序的技術(shù)以聚合類似交易(見圖20)。在一個實施例中,分類涉及兩個階段:按合同分類和按帳號/實體分類。在其他實施例中,分類可能包括額外的階段。
[0107]為了增加交易處理效率和吞吐量,多個交易被捆綁到一個批處理以使他們可以在同一時間被處理。
[0108]為了保持交易的完整性和可靠性,所公開的技術(shù)采用了一種或多種措施用于檢查指向和在交易處理故障事件中的交易再處理。在一個實施例中,技術(shù)使用檢查指向和重新嘗試方案,在其中輸入微小計算作業(yè)的副本被復制在本地或遠程處理節(jié)點中。如果微小處理作業(yè)成功,副本將被丟棄。如果微小作業(yè)處理失敗,復制的微小作業(yè)將被用于再加工。在交易處理故障事件中的這樣的重新啟動和再處理方案被反復進行直到作業(yè)被成功處理。
[0109]所公開的技術(shù)中的最基本的配置由包含編程指令序列和執(zhí)行可靠的金融交易處理的過程的非臨時性計算機可讀存儲器構(gòu)成,該編程指令序列由電子處理器執(zhí)行以產(chǎn)生存儲文件并將其發(fā)送到處理節(jié)點。有了這樣的配置,如買方和賣方之間的合同協(xié)議所指定的交易處理規(guī)則以及他們各自的用于跟蹤買方和賣方之間的價值交換的賬戶余額被以文件系統(tǒng)或數(shù)據(jù)庫形式存儲在非臨時性存儲器中。
[0110]在處理一批新的交易之前,計算機20將交易連同來自存儲文件的最新的信息一起打包。這樣的方案確保最新賬戶余額被用來處理交易。同樣,規(guī)則文件被更新并被發(fā)送至與合同規(guī)則引擎集成的處理節(jié)點。新的處理規(guī)則,作為買方和賣方之間的合同協(xié)議的變化的結(jié)果,以及新的賬戶余額,作為調(diào)整的結(jié)果,可以被在兩個作業(yè)之間進行更新。
[0111]上述技術(shù)的一個變化是使用關(guān)系數(shù)據(jù)庫作為一個非短暫性的計算機存儲以使其更容易開發(fā)軟件應用來管理買方和賣方之間的交易并跟蹤買方和賣方的帳戶余額。數(shù)據(jù)庫的使用也使得它更容易為其他應用查詢信息。有了這樣的變化,存儲在關(guān)系數(shù)據(jù)庫中的處理規(guī)則和帳戶余額被轉(zhuǎn)換成存儲文件并被發(fā)送到被用于交易處理的處理節(jié)點。處理的返回結(jié)果然后被更新到關(guān)系數(shù)據(jù)庫中。
[0112]所公開技術(shù)的另一種更復雜的變化涉及分布式文件系統(tǒng)和多個分布式處理節(jié)點(參見圖19)的使用。分布式文件系統(tǒng)可用于分區(qū)和發(fā)送多個存儲文件和交易至處理節(jié)點。每個節(jié)點獨立和并行地處理交易的子集。
[0113]在實施例中,所公開的技術(shù)使用映射減少計算模型和開放資源的Hadoop軟件被實施。Hadoop分布式文件系統(tǒng)(HDFS)是用來將存儲文件分配到本地處理節(jié)點的,而Hadoop映射減少是用于打包微小計算作業(yè)和平行處理交易的。
[0114]使用文件系統(tǒng)的高吞吐暈的智能電表數(shù)據(jù)預處理
[0115]為了構(gòu)建在具有高吞吐量和規(guī)模的智能電網(wǎng)中的購買和銷售能源和非能源交易的金融記錄,公開的技術(shù)采用文件或分布式文件系統(tǒng)預處理的電表數(shù)據(jù),而現(xiàn)有技術(shù)采用關(guān)系數(shù)據(jù)庫。電表數(shù)據(jù)的預處理和金融交易記錄的生成涉及一個或多個子流程,子流程被用于驗證電表讀取數(shù)據(jù)的正確性,糾正錯誤的電表數(shù)據(jù),估計和插入缺少的電表數(shù)據(jù),消除極端值,檢測和消除重復的電表數(shù)據(jù),聚合類似交易至單交易,以及以相關(guān)的信息豐富電表數(shù)據(jù)以使得合同條款可以應用于金融交易處理過程中。
[0116]實施
[0117]本發(fā)明公開的技術(shù)由三個主要部分組成:市場管理系統(tǒng)(MMS),存儲文件和一組包括數(shù)據(jù)預處理器、結(jié)算引擎和后處理器(參見圖21)的執(zhí)行引擎。執(zhí)行引擎由一些網(wǎng)絡(luò)處理節(jié)點支撐,其平行地處理交易。
[0118]麗S是用于配置和管理市場的基于Web的應用,包括參與市場的實體和實體間的合同協(xié)議。隨著在市場上和合同中的新的實體參與者的增加,MMS被用于配置新的實體和合同。此外,MMS被用來系統(tǒng)地修改實體和合同。被配置的數(shù)據(jù)模型,存儲在存儲文件中,被用于配置執(zhí)行引擎。數(shù)據(jù)預處理器被用于驗證,清理和條件輸入數(shù)據(jù)以使得高品質(zhì)的交易記錄可以被獲得??赡苌婕耙粋€或多個處理節(jié)點以增加數(shù)據(jù)預處理器的吞吐量。結(jié)算引擎是核心交易處理器,其適用合同條款和其他信息至交易并作出借記和貸記項目至參與交易的買方和賣方實體。同樣地,一個或多個處理節(jié)點可能被涉及以增加結(jié)算引擎的吞吐量。每一個與結(jié)算引擎相關(guān)的處理節(jié)點被與合同規(guī)則引擎集成,合同規(guī)則引擎被配置為在市場上所涉及所有的合同的合同條款。結(jié)算的交易可被進一步處理并由后處理器聚合。
[0119]圖27的處理系統(tǒng)的框圖,處理系統(tǒng)可以被用來實施任何上面描述的技術(shù),如金融計算系統(tǒng),結(jié)算引擎,合同規(guī)則引擎或金融計算引擎。注意在某些實施例中,圖27中所示的至少一些組件可能被分布在兩個或多個物理上分開但連接的計算平臺或箱子上。處理可以表示傳統(tǒng)的服務器類計算機,個人電腦,移動通信設(shè)備(如智能手機),或任何其它已知或常規(guī)的處理/通信裝置。
[0120]如圖27中所示的處理系統(tǒng)2701包括一個或多個處理器2710,即中央處理單元(CPU),存儲器2720,至少一個通信裝置2740,如以太網(wǎng)適配器和/或無線通信子系統(tǒng)(例如,蜂窩電話、無線網(wǎng)絡(luò)、藍牙或類似),和一個或多個I / O設(shè)備2770、2780,所有都通過互連2790相互耦合。
[0121]處理器2710控制計算機系統(tǒng)2701的操作并可以是或包括一個或多個可編程的通用目的或特殊目的微處理器,微控制器,專用集成電路(ASICs),可編程邏輯器件(PLDs),或這些設(shè)備的組合?;ミB2790可以包括一個或多個總線,直接連接和/或其它類型的物理連接,并且可包括如在本【技術(shù)領(lǐng)域】是眾所周知的各種橋,控制器和/或適配器?;ミB2790還可以包括“系統(tǒng)總線”,其可以通過一個或多個適配器一個或多個擴展總線被連接,如夕卜圍組件互連(PCI)總線,HyperTransport或工業(yè)標準結(jié)構(gòu)(ISA)總線,小型計算機系統(tǒng)接口(SCSI)總線,通用串行總線(USB)或電氣和電子工程師協(xié)會(IEEE) 1394標準總線(有時也被稱為“火線”)的形式。
[0122]存儲器2720可以是或可以包括一個或多個類型的一個或多個存儲器設(shè)備,如只讀存儲器(ROM),隨機存取存儲器(RAM),閃速存儲器,磁盤驅(qū)動器等。網(wǎng)絡(luò)適配器2740是適于使處理系統(tǒng)2701通過通信η鏈接與遠程處理系統(tǒng)進行數(shù)據(jù)通信的設(shè)備,并且可以是,例如,傳統(tǒng)的電話調(diào)制解調(diào)器,無線調(diào)制解調(diào)器,數(shù)字用戶線路(DSL的)調(diào)制解調(diào)器,電纜調(diào)制解調(diào)器,無線收發(fā)器,衛(wèi)星收發(fā)信機,以太網(wǎng)適配器,或類似物。I / O設(shè)備2770、2780可以包括,例如,一個或多個設(shè)備,例如:指點設(shè)備,例如鼠標,跟蹤球,操縱桿,觸摸板,或類似物;一個鍵盤;具有語音識別接口的麥克風;音頻揚聲器;顯示設(shè)備;等等。然而,注意這樣的I / O設(shè)備在系統(tǒng)中可以是不必要的,該系統(tǒng)只作為服務器并提供不是直接的用戶界面,因為是在至少某些實施例中與服務器的情況下?;谑境龅囊惶捉M件的其他變型可以以與本發(fā)明相一致的方式實施。
[0123]對處理器2710編程以執(zhí)行上述操作的軟件和/或硬件2730可被存儲在存儲器2720。在某些實施例中,通過經(jīng)由計算機系統(tǒng)2701 (例如,通過網(wǎng)絡(luò)適配器2740)從遠程系統(tǒng)下載,這樣的軟件或硬件可被最初提供給計算機系統(tǒng)2701。
[0124]上面介紹的技術(shù)可以實現(xiàn)通過,例如,以軟件和/或硬件編程的可編程電路(例如,一個或多個微處理器),或完全在特殊目的的硬件電路中的,或以這些形式的組合。特殊目的的硬件電路的形式可能是,例如,一個或多個專用應用集成電路(ASICs),可編程邏輯器件(PLDs),現(xiàn)場可編程門陣列(FPGA)等。
[0125]在執(zhí)行此處介紹的技術(shù)中使用的軟件或硬件可被存儲在機器可讀存儲介質(zhì)中,并且可以由一個或多個通用目的或特殊目的的可編程微處理器執(zhí)行?!皺C器可讀存儲介質(zhì)”,作為在本文所用的術(shù)語,包括任何可以將信息存儲在由機器訪問的一種形式(可能是一臺機器,例如,計算機,網(wǎng)絡(luò)設(shè)備,蜂窩電話,個人數(shù)字助理(PDA),制造工具,具有一個或多個處理器的任何設(shè)備,等等)的有關(guān)機制。例如,一臺機器可訪問存儲介質(zhì)包括可記錄/不可記錄介質(zhì)(例如,只讀存儲器(ROM);隨機存取存儲器(RAM);磁盤存儲介質(zhì);光存儲介質(zhì);閃存設(shè)備,等等)。
[0126]如本文所用的術(shù)語“邏輯”可包括,例如,以特定軟件和/或硬件編程的可編程電路,特殊目的的硬線電路,或它們的組合。
[0127]要求保護的主題的各種實施例的前述說明已經(jīng)被提供用于說明和描述的目的。其目的不是要窮舉或限制要求保護的主題為所公開的精確形式。許多修改和變化對于本領(lǐng)域技術(shù)人員將是顯而易見的。實施例的選擇和描述是為了最好地描述本發(fā)明的原理及其實際應用,從而使本領(lǐng)域技術(shù)人員在其他相關(guān)領(lǐng)域理解要求保護的主題,各種實施例及各種修改適合于預期的特定用途。
[0128]在此提供的本發(fā)明的技術(shù)可以應用于其他系統(tǒng)而不一定是上述系統(tǒng)??梢越Y(jié)合上述的各種實施例的元素和操作以提供進一步的實施例。雖然上面的說明描述了本發(fā)明的某些實施例,并描述了設(shè)想的最佳模式,但不管上述文本中顯示的如何詳細,本發(fā)明可以以多種方式被實施。系統(tǒng)的細節(jié)在其實現(xiàn)細節(jié)中可以有很大的不同,而仍被這里所公開的本發(fā)明所包含。如上文所述,當描述本發(fā)明的某些特征或方面所使用的術(shù)語不應被視為暗示該術(shù)語正在被在本文中重新定義以限制任何特定的特性,特征,或與該術(shù)語相關(guān)的本發(fā)明的方面。一般情況下,在以上的權(quán)利要求書中所使用的術(shù)語不應該被解釋為限制本發(fā)明為在本說明書中公開的具體實施例,除非上述詳細說明部分明確定義這樣的術(shù)語。因此,本發(fā)明的實際范圍不僅包括所公開的實施例,而是根據(jù)權(quán)利要求實踐或?qū)嵤┍景l(fā)明的所有等同的方式。
【權(quán)利要求】
1.一種用于根據(jù)合同確定付款的方法,所述方法包括: 由金融計算系統(tǒng)將所述合同的金融條款建模作為一個或多個第一參數(shù)的函數(shù),所述一個或多個第一參數(shù)中的每一個作為一個或多個第二個參數(shù)的函數(shù),所述一個或多個第一或第二參數(shù)中的每一個與一個或多個規(guī)則相關(guān)聯(lián),其中每一個規(guī)則代表將所述合同的條款表示為一組的多個條件和相關(guān)的多個操作,當相應的多個條件被滿足時,所述多個操作中的每一個被執(zhí)行; 由所述金融計算系統(tǒng)轉(zhuǎn)發(fā)一個或多個規(guī)則至合同規(guī)則引擎; 對于所述第一或第二參數(shù)中的每一個,由所述合同規(guī)則引擎解釋與所述給定參數(shù)相關(guān)聯(lián)的一個或多個規(guī)則之間的關(guān)系; 由所述金融計算系統(tǒng)接收由所述合同管理的金融交易的細節(jié); 由所述金融計算系統(tǒng)從所述接收到的詳細中識別一個或多個交易條件; 由所述金融計算系統(tǒng)基于所述金融交易的所述細節(jié),確定所述一個或多個交易條件的狀態(tài)值; 由所述金融計算系統(tǒng)基于所述一個或多個交易條件的所述計算的狀態(tài)值,遍歷每一個參數(shù)的所述被解釋的關(guān)系,以確定所述多個參數(shù)中的每一個的交易值;以及 由所述金融計算系統(tǒng)確定根據(jù)所述合同的所述金融條款的所述付款,作為所述一個或多個第一或第二參數(shù)的所述確定的交易值的函數(shù)。
2.如權(quán)利要求1所述的方法,遍歷所述多個參數(shù)中的每一個的所述被解釋的關(guān)系,包括: 由所述金融計算系統(tǒng)提供所述一個或多個交易條件的所述計算出的狀態(tài)值至所述規(guī)則解釋引擎; 由所述合同規(guī)則引擎將所述一個或多個交易條件中的每一個的所述計算的狀態(tài)值,應用到與所述參數(shù)中的每一個相關(guān)聯(lián)的規(guī)則;以及 當與所述多個被執(zhí)行的操作中的每一個相關(guān)聯(lián)的所述多個條件被基于所述計算出的狀態(tài)值進行評估時,由所述合同規(guī)則引擎基于所述多個操作中的每一個的執(zhí)行結(jié)果,確定所述參數(shù)中的每一個的所述交易值。
3.如權(quán)利要求1所述的方法,其中合同的所述金融條款是藉由將合同分解成多個合同模板來確定的,每個合同模板表不預定的多個金融條款。
4.如權(quán)利要求1所述的方法,其中所述合同與出售或購買電力相關(guān)聯(lián),進一步地,其中所述出售或購買電力的合同包括一個或多個第一或第二參數(shù),所述一個或更多的第一或第二參數(shù)包括: 承諾費率;或者 承諾負載基準費率。
5.如權(quán)利要求1所述的方法,其中所述合同與音樂許可證相關(guān)聯(lián),進一步地,其中所述音樂許可證的合同包括一個或多個第一或第二參數(shù),所述一個或更多的第一或第二參數(shù)包括: 有效的提成率; 有效的單位; 升級費率;基本的US費率; 通道減少費率;或者 區(qū)域減少費率。
6.如權(quán)利要求1的方法,其中所述合同規(guī)則引擎包括一個或多個的: 決策表;或者 規(guī)則引擎。
7.如權(quán)利要求6所述的方法,其中所述規(guī)則引擎是第三方軟件。
8.如權(quán)利要求1所述的方法,其中所述將所述合同的金融條款建模為一個或多個第一或第二參數(shù)的函數(shù)進一步包括: 通過增加或移除所述一個或多個規(guī)則,將更改合并至所述合同的金融條款。
9.一種用于根據(jù)合同確定付款的方法,所述方法包括: 由金融計算系統(tǒng)將所述合同的金融條款建模作為一個或多個參數(shù)的函數(shù),所述一個或多個參數(shù)中的每一個被表示作為獨立的決策樹; 由所述金融計算系統(tǒng)以適合計算機實現(xiàn)遍歷的格式進行表示每一個與所述合同相關(guān)聯(lián)的決策樹; 由所述金融計算系統(tǒng)接收由所述合同管理的金融交易的細節(jié); 由金融計算系統(tǒng)基于所述金融交易的所述接收到的細節(jié),遍歷與所述一個或多個參數(shù)中的每一個 相關(guān)聯(lián)的每個決策樹以確定所述一個或多個參數(shù)中的每一個的值;以及 由金融計算系統(tǒng)根據(jù)在所述合同中指定的金融條款來確定所述付款,所述付款被作為所述一個或多個參數(shù)的所述確定的交易值的函數(shù)進行計算。
10.如權(quán)利要求9所述的方法,其中建模包括: 確定合同條款的用法、價格或修改因素;確定合同條件;基于確定的合同條件構(gòu)造決策樹的分支;構(gòu)建葉節(jié)點;填寫用法、價格或修改因素。
11.如權(quán)利要求9所述的方法,其中所述將所述合同的金融條款建模作為一個或更多第一或第二參數(shù)的函數(shù)進一步包括: 提供圖形用戶界面已使用戶能夠?qū)碜运龊贤男畔⒂成涞侥0逯?;以及通過所述被映射的信息自動生成映射信息表不,所述被映射的信息是用來對合同的金融條款進行建模的。
12.如權(quán)利要求9所述的方法,其中所述金融計算系統(tǒng)使用Hadoop軟件來實現(xiàn)分布式文件系統(tǒng)。
13.如權(quán)利要求9所述的方法,其中所述金融計算系統(tǒng)使用映射減少計算模塊來處理所述金融交易。
14.一種用于根據(jù)合同確定付款的方法,所述方法包括: 由金融計算系統(tǒng)將所述合同的金融條款建模作為一個或多個第一參數(shù)的函數(shù),所述一個或多個第一參數(shù)中的每一個作為一個或多個第二個參數(shù)的函數(shù),所述一個或多個第一或第二參數(shù)中的每一個與一個或多個規(guī)則相關(guān)聯(lián),其中每一個規(guī)則將所述合同的條款表示為一組的多個條件和相關(guān)的多個操作,當相應的多個條件被滿足時,所述多個操作中的每一個被執(zhí)行。
15.如權(quán)利要求14所述的方法,其中合同的所述金融條款通過將合同分解成多個合同模板被確定,每個合同模板表不預定的多個金融條款。
16.如權(quán)利要求14所述的方法,其中將所述合同的金融條款建模作為一個或多個第一或第二參數(shù)的函數(shù)進一步包括: 通過增加或移除所述一個或多個規(guī)則,將更改合并至所述合同的金融條款。
17.如權(quán)利要求14所述的方法,其中對于所述第一或第二參數(shù)中的每一個,由所述合同規(guī)則引擎解釋與所述給定參數(shù)相關(guān)聯(lián)的一個或多個規(guī)則之間的關(guān)系。
18.如權(quán)利要求14所述的方法,其中所述合同規(guī)則引擎包括一個或多個的: 決策表;或者 規(guī)則引擎。
19.如權(quán)利要求14所述的方法,其中所述合同與出售或購買電力相關(guān)聯(lián),進一步地,其中所述出售或購買電力的合同包括一個或多個第一或第二參數(shù),所述一個或更多的第一或第二參數(shù)包括: 承諾費率;或者 承諾負載基準費率。
20.如權(quán)利要求14所述的方法,其中所述合同與音樂許可證相關(guān)聯(lián),進一步地,其中所述音樂許可證的合同 包括一個或多個第一或第二參數(shù),所述一個或更多的第一或第二參數(shù)包括: 有效的提成費率; 有效的單位; 升級費率; 基本的US費率; 通道減少費率;或者 區(qū)域減少費率。
21.一種用于根據(jù)合同確定付款的金融計算系統(tǒng),所述系統(tǒng)包括: 金融處理模塊,用于將所述合同的金融條款建模作為一個或多個第一參數(shù)的函數(shù),所述一個或多個第一參數(shù)中的每一個作為一個或多個第二個參數(shù)的函數(shù),所述一個或多個第一或第二參數(shù)中的每一個與一個或多個規(guī)則相關(guān)聯(lián),其中每一個規(guī)則將所述合同的條款表示為一組的多個條件和相關(guān)的多個操作,當相應的多個條件被滿足時,所述多個操作中的每一個被執(zhí)行; 所述金融處理模塊,用于轉(zhuǎn)發(fā)一個或多個規(guī)則制合同規(guī)則引擎; 對于所述第一或第二參數(shù)中的每一個,合同規(guī)則引擎用于解釋與所述給定參數(shù)相關(guān)聯(lián)的一個或多個規(guī)則之間的關(guān)系; 所述金融處理模塊,用于接收由所述合同管理的金融交易的細節(jié); 所述金融處理模塊,用于從所述接收到的詳細中識別一個或多個交易條件; 所述金融處理模塊,用于基于所述金融交易的所述細節(jié)確定所述一個或多個交易條件的狀態(tài)值; 所述金融處理模塊,用于基于所述一個或多個交易條件的所述計算的狀態(tài)值,遍歷每一個參數(shù)的所述被解釋的關(guān)系以確定所述多個參數(shù)中的每一個的交易值;以及 所述金融處理模塊,用于確定根據(jù)所述合同的所述金融條款的所述付款,作為所述一個或多個第一或第二參數(shù)的所述確定的交易值的函數(shù)。
22.如權(quán)利要求21所述的金融處理系統(tǒng),其中所述金融測量系統(tǒng)用于遍歷所述多個參數(shù)中的每一個的所述被解釋的關(guān)系,進一步包括: 提供所述一個或多個交易條件的所述計算出的狀態(tài)值至所述規(guī)則解釋引擎; 將所述一個或多個交易條件中的每一個的所述計算的狀態(tài)值應用到與所述參數(shù)中的每一個相關(guān)聯(lián)的規(guī)則;以及 當與所述多個被執(zhí)行的操作中的每一個相關(guān)聯(lián)的所述多個條件被基于所述計算出的狀態(tài)值進行評估時,基于所述多個操作中的每一個的執(zhí)行結(jié)果,確定所述參數(shù)中的每一個的所述交易值。
23.如權(quán)利要求21所述的金融處理系統(tǒng),其中合同的所述金融條款是由所述金融處理系統(tǒng)通過提供將合同分解成多個合同模板來確定的,每個合同模板表示預定的多個金融條政。
24.如權(quán)利要求21所述的金融處理系統(tǒng),其中由所述金融處理模塊建模的所述合同與出售或購買電力相關(guān)聯(lián),進一步地,其中所述出售或購買電力的合同包括一個或多個第一或第二參數(shù),所述一個或更多的第一或第二參數(shù)包括: 承諾費率;或者 承諾負載基準費率。
25.如權(quán)利要求21所述的金融處理系統(tǒng),其中由所述金融處理建模的所述合同與音樂許可證相關(guān)聯(lián),進一步地,其中所述音樂許可證的合同包括一個或多個第一或第二參數(shù),所述一個或更多的第一或第二參數(shù)包括: 有效的提成費率; 有效的單位; 升級費率; 基本的US費率; 通道減少費率;或者 區(qū)域減少費率。
26.如權(quán)利要求21所述的金融處理系統(tǒng),其中所述合同規(guī)則引擎包括一個或多個的: 決策表;或者規(guī)則引擎。
27.如權(quán)利要求26所述的金融處理系統(tǒng),其中所述規(guī)則引擎是第三方軟件。
28.如權(quán)利要求21所述的金融處理系統(tǒng),其中由所述金融處理模塊將所述合同的金融條款建模為一個或多個第一或第二參數(shù)的函數(shù)進一步包括: 通過增加至所述一個或多個規(guī)則或從所述一個或多個規(guī)則中移除,將更改合并至所述合同的金融條款。
29.一種用于根據(jù)合同確定付款的金融計算系統(tǒng),所述系統(tǒng)包括: 金融計算系統(tǒng),用于將所述合同的金融條款建模作為一個或多個參數(shù)的函數(shù),所述一個或多個參數(shù)中的每一個被表示作為獨立的決策樹; 所述金融計算系統(tǒng),用于將每一個與所述合同相關(guān)聯(lián)的決策樹以適合計算機實現(xiàn)遍歷的格式進行表示; 所述金融計算系統(tǒng),用于接收由所述合同管理的金融交易的細節(jié);所述金融計算系統(tǒng),用于基于所述金融交易的所述接收到的細節(jié)遍歷與所述一個或多個參數(shù)中的每一個相關(guān)聯(lián)的每個決策樹以確定所述一個或多個參數(shù)中的每一個的值;以及 所述金融計算系統(tǒng),用于根據(jù)在所述合同中指定的金融條款來確定所述付款,所述付款被作為所述一個或多個參數(shù)的所述確定的交易值的函數(shù)進行計算。
30.如權(quán)利要求29所述的金融處理系統(tǒng),其中所述建模包括: 確定合同條款的用法、價格或修改因素;確定合同條件;基于確定的合同條件構(gòu)造決策樹的分支;構(gòu)建葉節(jié)點;填寫用法、價格或修改因素。
31.如權(quán)利要求29所述的金融處理系統(tǒng),其中由所述金融計算系統(tǒng)將所述合同的金融條款建模作為一個或更多第一或第二參數(shù)的函數(shù)進一步包括: 提供圖形用戶界面已使用戶能夠?qū)碜运龊贤男畔⒂成涞侥0逯?;以及通過所述被映射的信息自動生成映射信息表不,所述被映射的信息是用來對合同的金融條款進行建模的。
32.如權(quán)利要求29所述的金融處理系統(tǒng),其中所述金融計算系統(tǒng)使用Hadoop軟件來實現(xiàn)分布式文件系統(tǒng)。
33.如權(quán)利要求29所述的金融處理系統(tǒng),其中所述金融計算系統(tǒng)使用映射減少計算模塊來處理所述金融交易。
34.一種用于根據(jù)合同確定付款的金融計算系統(tǒng),所述系統(tǒng)包括: 金融計算系統(tǒng),用于將所述合同的金融條款建模作為一個或多個第一參數(shù)的函數(shù),所述一個或多個第一參數(shù)中的每一個`作為一個或多個第二個參數(shù)的函數(shù),所述一個或多個第一或第二參數(shù)中的每一個與一個或多個規(guī)則相關(guān)聯(lián),其中每一個規(guī)則將所述合同的條款表示為一組的多個條件和相關(guān)的多個操作,當相應的多個條件被滿足時,所述多個操作中的每一個被執(zhí)行。
35.如權(quán)利要求34所述的金融處理系統(tǒng),其中合同的所述金融條款由所述金融處理系統(tǒng)通過將合同分解成多個合同模板來確定,每個合同模板表示預定的多個金融條款。
36.如權(quán)利要求34所述的金融處理系統(tǒng),其中由所述金融處理系統(tǒng)將所述合同的金融條款建模作為一個或多個第一或第二參數(shù)的函數(shù)進一步包括: 通過增加至所述一個或多個規(guī)則或從所述一個或多個規(guī)則中移除,將更改合并至所述合同的金融條款。
37.如權(quán)利要求34所述的金融處理系統(tǒng),其中對于所述第一或第二參數(shù)中的每一個,由所述合同規(guī)則引擎解釋與所述給定參數(shù)相關(guān)聯(lián)的一個或多個規(guī)則之間的關(guān)系。
38.如權(quán)利要求37所述的金融處理系統(tǒng),其中所述合同規(guī)則引擎包括一個或多個的: 決策表;或者 規(guī)則引擎。
39.如權(quán)利要求34所述的金融處理系統(tǒng),其中由所述金融處理模塊建模的所述合同與出售或購買電功率相關(guān)聯(lián),進一步地,其中所述出售或購買功率的合同包括一個或多個第一或第二參數(shù),所述一個或更多的第一或第二參數(shù)包括: 承諾費率;或者 承諾負載基準費率。
40.如權(quán)利要求34所述的金融處理系統(tǒng),其中由所述金融處理模塊建模的所述合同與音樂許可證相關(guān)聯(lián),進一步地,其中所述音樂許可證的合同包括一個或多個第一或第二參數(shù),所述一個或更多的第一或第二參數(shù)包括: 有效的提成費率; 有效的單位; 升級費率; 基本的US費率; 通道減少費率; 或者 區(qū)域減少費率。
【文檔編號】G06Q30/06GK103765463SQ201280024052
【公開日】2014年4月30日 申請日期:2012年3月16日 優(yōu)先權(quán)日:2011年3月16日
【發(fā)明者】張健 申請人:格里迪克斯公司
網(wǎng)友詢問留言 已有0條留言
  • 還沒有人留言評論。精彩留言會獲得點贊!
1