專利名稱：預訂方法和系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及電信領域。具體而言，本發(fā)明涉及在預訂系統(tǒng)中進行預訂和使包括至少一個預訂系統(tǒng)的幾個預訂系統(tǒng)中的預訂同步的方法和系統(tǒng)；涉及至少一個服務提供者；中介器服務；客戶端和至少一個客戶終端裝置，可以是移動裝置，并包括對話。此外，該系統(tǒng)包括用于連接預訂系統(tǒng)、服務提供者、中介器、和客戶終端裝置的電信連接。
背景技術：
通過互聯(lián)網(wǎng)進行預訂或使用的服務在不斷增加?；ヂ?lián)網(wǎng)使人們可以使用多種在線服務，例如連接到銀行的服務、保健服務、旅行社、車輛維護等。
移動計算和通信裝置的逐漸普及為互聯(lián)網(wǎng)上的服務帶來新的挑戰(zhàn)。移動終端能在需要時傳送信息給用戶。用戶希望從手邊的裝置無處不在地訪問信息和應用。他們也希望無論在哪里都能訪問和更新信息。
然而，重要的是注意到，不是所有的終端都是移動的。未來的服務必須能與大量終端裝置通信，這些終端裝置是移動的或不能移動的。不同的終端裝置具有差別很大的能力。
不同服務和終端裝置的互用性需要多種等級的標準。也就是說，具有公共通信協(xié)議是不夠的。共享公共原理和理解一定的數(shù)據(jù)片段在特定的環(huán)境中意思是什么是非常重要的。然而，因為在本領域中存在非常多的公司、組織、和其它參與者，所以對這些問題達成協(xié)議是非常困難的。
很多服務必須能管理預訂。它們舉例來說包括預訂保健服務預約；預訂旅行旅館、航線、和出租車預約；預訂會場門票；預訂車輛維護預約；預訂公寓維護等等。如果這些服務相互獲得信息，則這是非常有用的。例如，如果顧客正在預訂音樂會的票，則他或她也可能希望預訂餐館中的臺位。如果餐館預訂服務得到基本信息，例如從劇院的預訂系統(tǒng)得到日期和顧客姓名，則這是有幫助的。遺憾的是，沒有方法在不同類型的預訂系統(tǒng)中交換信息。
有多種方法在服務之間交換信息。涉及到包括預訂或日歷功能的服務，信息交換常常發(fā)生在使預訂或日歷條目同步時。為此，正在進行幾種重要的標準化努力。例如，SyncML是提出公共數(shù)據(jù)同步協(xié)議的工業(yè)發(fā)起者。
vCalendar是個人日程安排信息的交換格式。它可應用于很多日歷和日程安排產(chǎn)品，且在多種的運輸方法中交換信息中是有用的。很多賣主已經(jīng)采用了這個規(guī)范，因為它允許賣主的產(chǎn)品交換日歷和日程安排信息。vCalendar是基于例如x/Open和XAPIA日歷和日程安排API(CSA)等工業(yè)標準、ISO 8601國際日期和時間標準、和相關MIME電子郵件標準的開放規(guī)范。vCalendar格式使用通常儲存在日歷和日程安排應用中的數(shù)據(jù)，便于對關于諸如事件(events)和做事(to-do′s)等條目的信息進行交叉平臺交換。事件是表示日歷上時間的指定量的日歷和日程安排實體。做事是表示行為條目或任務的日歷和日程安排視體。例如，它可以是分配給個人的工作條目。
vCard用于自動交換通常出現(xiàn)在傳統(tǒng)名片上的個人信息。vCard用在諸如互聯(lián)網(wǎng)郵件、語音郵件、網(wǎng)絡瀏覽器、電話應用、呼叫中心、視頻會議、PIM(個人信息管理器)、PDA(個人數(shù)據(jù)助理)、尋呼機、傳真機、辦公設備、和智能卡。除了文本外，vCard信息可包括例如圖片、公司標識、現(xiàn)場網(wǎng)址等元素。
如這些實例所示出的，已經(jīng)花費大量努力來建立能使預訂系統(tǒng)同步的系統(tǒng)。所有這些現(xiàn)有的解決方法所共有的一個問題是，它們不提供用于不同系統(tǒng)的公共語義。例如，如果登錄(entry)是嘗試性的，則不同系統(tǒng)可以不同方式理解此登錄。
另一問題是，預訂系統(tǒng)具有多種不同的且常常是十分復雜的用戶界面。如果用戶想預約牙醫(yī)和預訂出租車載他或她到那兒，則用戶需要以不同方式將所有的預訂信息輸入兩個預訂系統(tǒng)。
再一問題是，如果給予客戶端很多問題，則管理客戶回復變得具有挑戰(zhàn)性。例如，由于在很多國家，例如芬蘭，利用SMS文本消息通信和它們?yōu)椴僮髡邉?chuàng)收是非常普通的，所以使用SMS文本消息詢問客戶他或她選擇哪個選項是有意義的。然而，如果客戶通過發(fā)送多條文本消息來回復多個詢問，則找出哪個回答(answer)對應于特定問題可能是麻煩的，因為回復(reply)沒有自動包含對該問題的參考。比方說，一項服務詢問客戶他或她除了飛機票外是否想要預訂出租車和旅館房間，且客戶對一個問題作出回復“是”，對另一問題作出回復“否”，則該項服務不一定知道該客戶已經(jīng)接受了哪項預訂。

發(fā)明內(nèi)容
本發(fā)明的一個目的是消除上述缺陷之一或至少較大程度上避免它們帶來的不利影響。本發(fā)明實現(xiàn)了特別對移動服務必不可少的新的增值服務。
本發(fā)明的另一目的是提供能進行預訂型交易的方法和系統(tǒng)，該預訂型交易包括至少一個服務提供者和多個用戶，每個用戶都可用能接收和發(fā)送短的文本消息的移動電話通信。
本發(fā)明的再一目的是提供一種在多個服務提供者和多個用戶之間進行預訂型交易的方法和系統(tǒng)，每個用戶都可用能接收和發(fā)送短的文本消息的移動電話通信。


在以下部分中，本發(fā)明將借助于其實施例的幾個實例進行詳細描述，其中圖1表示根據(jù)本發(fā)明的第一實施例的系統(tǒng)；圖2表示根據(jù)本發(fā)明的第二實施例的系統(tǒng)；圖3表示根據(jù)本發(fā)明的第三實施例的系統(tǒng)；圖4是順序圖的第一實施例，表示在根據(jù)本發(fā)明的系統(tǒng)內(nèi)傳輸?shù)南?；圖5是順序圖的第二實施例，表示在根據(jù)本發(fā)明的系統(tǒng)內(nèi)傳輸?shù)南ⅲ?
圖6示出根據(jù)本發(fā)明應用于詢問和回復的動態(tài)對話矩陣的實例；圖7示出本發(fā)明的優(yōu)選實施例中的預訂過程的各階段；以及圖8示出根據(jù)本發(fā)明的優(yōu)選實施例對應于實例2的矩陣圖。
具體實施例方式
本發(fā)明涉及在預訂系統(tǒng)和用戶終端裝置之間交換信息并使這些信息同步。服務舉例來說可以是預訂保健服務預約；預訂旅行旅館、航線、和出租車預約；預訂會場門票；預訂車輛維護預約；預訂公寓維護等等。
根據(jù)本發(fā)明的預訂系統(tǒng)包括至少一個服務提供者預訂系統(tǒng)；至少一個服務提供者；中介器(mediator，又稱中介者)；客戶；至少一個客戶終端裝置，該裝置可以是能接收文本消息的移動裝置，且包括對話(dialogue)；以及電信連接，該電信連接用于使服務提供者預訂系統(tǒng)、服務提供者、中介器、和客戶終端裝置彼此互連。
服務提供者是客戶想要與之預約、預訂、或其它預訂的服務提供者，且具有待分配的預訂系統(tǒng)的資源。服務提供者通過服務提供者預訂服務管理商業(yè)。如在本申請中使用的，中介器是基于網(wǎng)絡的服務，可通過網(wǎng)絡為服務提供者預訂服務所用，提供另外的語義、翻譯、客戶完成與服務提供者的交易所需要的信息的通信所需要的同步服務。服務提供者預訂服務和中介器優(yōu)選是在例如互聯(lián)網(wǎng)或專有內(nèi)聯(lián)網(wǎng)等網(wǎng)絡服務器上運行的應用。一般而言，系統(tǒng)將包括多個服務提供者和服務提供者預訂系統(tǒng)(實現(xiàn)服務提供者預訂服務)，但是可能具有一個僅用于一個服務提供者的簡單預訂系統(tǒng)，在這種情形下，中介器和服務提供者可緊緊地整合到單個應用中。
客戶端優(yōu)選包括在能接收例如短消息服務(SMS)消息等短文本消息的移動電話上通信的客戶端。當然，能處理SMS消息的系統(tǒng)也將以更大的能力處理其它客戶端。中介器優(yōu)選通過SMS網(wǎng)關與移動電話客戶端通信，例如通過移動電話提供者和今天眾所周知的裝置操作。中介器使用對話與客戶端通信。對話是將信息呈現(xiàn)給客戶端且允許簡單回復的短消息。對話優(yōu)選將例如是/否等簡單選擇提供給用戶，或允許從有序表(ordered list)中進行選擇。對話也可是單向的，例如肯定預訂。一項交易可典型地涉及一列對話，每個對話都包括簡單回復。對話包括消息的異步通信。所述系統(tǒng)使得在不同的服務提供者系統(tǒng)中協(xié)調(diào)預訂以滿足客戶需要成為可能，例如使航線預訂與到機場的運輸協(xié)調(diào)。
圖1是最簡單的系統(tǒng)的圖示，該系統(tǒng)包括用于單個服務提供者的單個服務提供者預訂系統(tǒng)100、通過網(wǎng)絡與服務提供者通信的中介器102、和具有上面已輸入對話的移動電話的用戶。
圖2示出多個通過網(wǎng)絡與中介器通信的服務提供者預訂系統(tǒng)。
圖3示出與各個服務提供者系統(tǒng)和具有能進行通信對話的電話裝置的用戶通信的名為BooKIT的中介器。
從客戶方面看，基于原因的客戶對話是理想改進，因為服務提供者能創(chuàng)建其自己的與每個預訂時間連接的對話。一個對話與特定的預訂條件密切相關。此時自動變得成運行，或客戶端可根據(jù)需要啟動對話，或系統(tǒng)中的另一實體能發(fā)送消息給對話以啟動它。該對話接著發(fā)送詢問給系統(tǒng)中的另一實體，或通知客戶，且可能詢問客戶的選擇。通過這種類型的對話，客戶可僅使用一個用戶界面在幾個預訂系統(tǒng)中進行預訂。該對話例如通過互聯(lián)網(wǎng)乃至移動網(wǎng)絡連接到遠程預訂系統(tǒng)。
中介器服務能在服務提供者預訂系統(tǒng)之間傳送預訂信息。例如，在將預訂輸入航線預訂系統(tǒng)后，出租車預訂系統(tǒng)能提供到機場的運送給客戶端。在此應用中，預訂是單個資源(前一實例中的航線預訂或出租車預訂)的分配，而預訂是對于同一事件(前一實例中的航線預訂加上出租車預訂)的所有資源進行預訂的結合?？蛻?、中介器、和預訂系統(tǒng)之間的對話以及所儲存的用戶概要確保了客戶獲得他或他需要的基于原因的服務，而沒有插入廣告。
客戶可使用很多類型的通信裝置進行預訂以及確認、改變、和取消它們，這些通信裝置包括但不限于互聯(lián)網(wǎng)、電子郵件、和移動終端等。客戶也可使用中介器的同步功能使由中介器或服務提供者提供的日歷與終端裝置同步。
服務提供者可提醒客戶進行定期預訂，從而提高客戶忠誠度。中介器可幫助服務提供者將其預訂系統(tǒng)集合在一起，能提供更全面的服務，而不必擴展其商業(yè)規(guī)模。由于國際化，中介器能舉例來說支持很多語言、時區(qū)、貨幣、和數(shù)據(jù)格式。
該系統(tǒng)包括至少一個對話、中介器、服務提供者、和服務提供者預訂系統(tǒng)，可以是基于以下標準之一1.在系統(tǒng)中存在一組預先確定的對話。預先設定它們的內(nèi)容和可能的選擇。例如，如果客戶預訂機票，則對話總是提供某些其它預訂。不考慮客戶的在先行為。
2.存在數(shù)量不限的動態(tài)或“智能”對話，這些對話舉例來說基于客戶為他或她自身創(chuàng)建的概要、使用歷史記錄、和客戶位置。簡單邏輯支持決定。它是一個低級專家系統(tǒng)。
3.該系統(tǒng)能自己做出決定，且支持客戶做出決定。在此等級上，對話可包括高級專家系統(tǒng)。它可充當代理，與幾個服務提供者談判，無需客戶直接參與就可獲得最好的服務。
在該方法的一個優(yōu)選實施例中，客戶預訂來自服務提供者的服務?？墒褂眠B接到中介器服務的終端執(zhí)行該預訂。首先，客戶使用對話連接到中介器服務?？蛻魧㈩A訂詢問輸入發(fā)送該詢問給中介器的對話。中介器使用那些服務能理解的原理和術語從服務提供者的信息系統(tǒng)詢問可能的預訂。該詢問基于客戶喜好。該客戶在他或她將預訂詢問輸入對話時披露與該具體預訂有關的一些喜好。此外，該對話和該中介器服務可能已經(jīng)儲存了客戶的一般喜好，并使用它們，以使客戶不需要每次都輸入所有喜好。
基于復雜的狀態(tài)模型管理詢問和預訂。每個預訂都包括幾個階段，這些階段用通過其生活周期跟蹤其情況的狀態(tài)描述。例如，當中介器已經(jīng)詢問來自服務提供者的預訂時，每個系統(tǒng)中的相應條目具有預訂待決但未確認的狀態(tài)。如果這些系統(tǒng)沒有就特定狀態(tài)意思是什么達成共識，則中介器翻譯它們。包括階段和狀態(tài)的優(yōu)選的預訂過程在實例1中描述。
除了詢問來自服務提供者的預訂外，中介器能使幾個服務提供者的系統(tǒng)中的預訂同步。該同步基于在中介器服務中規(guī)定的規(guī)則。例如，規(guī)則可以是“如果客戶詢問對飛機票的預訂，則也詢問對到機場的出租車的預訂”。因此，來自客戶的詢問可以在中介器服務中增多，形成多個詢問。如果服務提供者能提供所請求的服務，則它們對中介器做出回答，且可添加一些例如座位或定時等另外的信息。中介器合并收集的信息，并將其發(fā)送給顯示選項的簡單表給客戶的對話。例如，客戶可顯示三個飛行選項，且詢問客戶是否也想預訂出租車，該出租車實際上已經(jīng)被中介器暫時預訂。客戶通過從可選方案的簡單表選擇選項做出決定。該對話將關于客戶選擇的信息發(fā)送給中介器，該中介器根據(jù)客戶選擇確認預訂，并取消不必要的預訂。
圖4示出客戶使用發(fā)送給中介器的對話DINQ1發(fā)起的詢問CINQ1的順序圖。中介器向到預訂系統(tǒng)1(服務提供者預訂系統(tǒng))發(fā)起相應于的CINQ1和DINQ1的詢問MINQ1。最終，回答DANQ1重新回到客戶端，提供了用選項CSEL1響應的選擇，使得預訂系統(tǒng)1上的客戶進行預訂。中介器確認對來自預訂服務2的輔助服務的潛在需要，并向預訂系統(tǒng)2發(fā)起詢問MINQ2，MINQ2最終形成包括幾個選項DANS2的建議，返回做出選擇CSEL2的客戶端，導致在預訂系統(tǒng)2上進行補充預訂。
預訂也可以其它方式完成，例如，通過用電話呼叫服務提供者，或通過現(xiàn)場訪問服務提供者的辦公室。在此情形下，服務提供者可通知中介器客戶的預訂，從而中介器可通知客戶其它選項。例如，牙醫(yī)告訴中介器，客戶已經(jīng)預訂了約會，從而中介器也可提供預訂出租車。
同樣，可以將催詢單添加到中介器服務中，以使中介器可在特定時間詢問客戶是否想要進行新的預訂。例如，中介器可發(fā)送通知給客戶，自從客戶最后一次與其牙醫(yī)約會已經(jīng)過了一年，并詢問客戶是否向進行新的預訂。這種通知可已經(jīng)包括一些約會選項。如果客戶已允許，則中介器檢查他或她的日歷，從而給定的選項對客戶來說是方便的。對話以簡單而方便的方式顯示選項?？蛻魞H需要選擇哪個選項對他或她是最好的，或他或她是否想要得到新選項或推遲預訂。圖5是原始詢問MINQ1由中介器發(fā)起的情況的時間順序表。
實例1-優(yōu)選的預訂系統(tǒng)下面就名稱為BookIt的系統(tǒng)描述根據(jù)本發(fā)明的優(yōu)選預訂系統(tǒng)。
BookIT設計為服務提供者預訂系統(tǒng)和例如互聯(lián)網(wǎng)等網(wǎng)絡上的其它方之間的接口，和裝配有能接收文本消息的移動電話的終端用戶客戶端。前者優(yōu)選用普通XML界面實現(xiàn)。BookIT支持vCard和vCalendar標準，因為它們被所有主要的預訂和日歷系統(tǒng)使用。
BookIT使用經(jīng)由SMS網(wǎng)關進行異步通信的短消息服務(SMS)與移動電話用戶通信。BookIT使用新型動態(tài)對話矩陣(DynamicDialogue Matrix，DDM)對SMS消息進行安全傳輸和映射。DDM將在下面進一步描述。
需要在服務提供者過程和BookIT過程之間作出清楚的區(qū)分。前者僅用時間和資源預訂覆蓋標準預訂。后者包括預訂、工作、和金融業(yè)務。這兩個過程結束于同一點。BookIT過程包括以下幾個階段階段(狀態(tài)處理)這些階段在資源之間進行結合(rubber band)。在BookIT過程的每個階段，將修改與預訂有關的數(shù)據(jù)，以反映正在討論的階段的需要。對于狀態(tài)和值，請參看下面的表。
在以下討論中將更詳細地描述這些階段。
1.提交提交是指BookIT過程和預訂過程的初始化。作為初始化的結果，將條目插入數(shù)據(jù)庫w/基本信息中。由于不存在日程安排信息，所以它不會出現(xiàn)在日歷中。它可作為開放的任務顯示在所有者的分開的任務列表中。
2.請求在請求階段中，將預訂請求發(fā)送給先前提交的任務所需要的資源。由于不存在日程安排(這在大多數(shù)情況下將是必不可少的)，所以這個階段可與日程安排階段一起執(zhí)行。
3.日程安排將日程表給予所有者和資源。作為日程安排的部分和結果，需要以下數(shù)據(jù)a建議的開始時間(ISO時間戳w/時區(qū))b建議的開始位置(坐標)c建議的結束時間(ISO時間戳w/時區(qū))d結束的結束位置(坐標)4.確認時間和位置被已經(jīng)接收的資源接收。與此階段有關的數(shù)據(jù)a所接收的開始時間(ISO時間戳w/時區(qū))
b所接收的開始位置(坐標)c所接收的結束時間(ISO時間戳w/時區(qū))d所接收的結束位置(坐標)缺省情況下數(shù)據(jù)從計劃階段復制。
實際上，如果不需要計劃的時間，則可將相同的數(shù)據(jù)結構用于此階段，且狀態(tài)表示數(shù)據(jù)的實際意義。
5.工作這些資源執(zhí)行預訂的任務。與此階段有關的數(shù)據(jù)包括不同屬性及其值，這些值與實際任務有關。此外，需要以下靜態(tài)結構a實際的開始時間(ISO時間戳w/時區(qū))b實際的開始位置(坐標)c實際的結束時間(ISO時間戳w/時區(qū))d實際的結束位置(坐標)e所使用的產(chǎn)品、額外費用、英里程，…缺省情況下數(shù)據(jù)從確認階段復制。
6.結算此時，為了貨品計價目的，對在先前的階段儲存在數(shù)據(jù)結構上的所有數(shù)據(jù)進行分析和處理。
與此階段有關的數(shù)據(jù)結算數(shù)據(jù)。將分別定義。
7.完成已經(jīng)完成了此任務。從整個BookIT過程的觀點看，與任務成功不成功不相關。與其中進行了對組織者的財政動作的結算階段有關。在此階段，為了完成BookIT過程進行內(nèi)務處理(數(shù)據(jù)庫內(nèi)容、臨時文件，…)。
下表顯示在每個階段中可用的數(shù)據(jù)。預訂階段用斜體字表示。

階段狀態(tài)、值、和轉移下表描述了階段、其狀態(tài)、和值以及根據(jù)所得到的值到下一邏輯階段的轉變。此外，示出應用時的相應的vCalendar狀態(tài)。


在任何點，對于所有相關階段，暫停、重新開始、取消的內(nèi)部階段動作如下所述

圖6示出從一階段到另一階段的作業(yè)流程轉移。對于條件，參見上表。另外，請注意取消狀態(tài)總是導致結算。
確認(整個)預訂為了保證整個預訂成功，接收預訂的所有資源需要具有相同的日程安排。此外，將存在具有不同作用的資源，且與工作階段有關的數(shù)據(jù)可能變化很大。
整個預訂的不同狀態(tài)是a“無回復(NoReplies)”(0)表示“沒有人對組織者的請求做出回復”b“無拒絕(NoDeclines)”(1)表示“并不是所有被邀請者都已回復。已經(jīng)回復的人接受了。”c“全部接受(AllAccepts)”(2)表示“所有被邀請者都已確認”
d“部分拒絕(SomeDeclines)”(3)表示“部分被邀請者已經(jīng)拒絕”e“全部拒絕(AllDeclines)”(4)表示“所有被邀請者都已拒絕”以下判定表有助于估計整個預訂的狀態(tài)。“可能(Maybe)”是指這種條件不是不容置疑地指定真或假結果。

根據(jù)上述信息和決定表，組織者/應用必須決定利用預訂做什么。這可以是系統(tǒng)根據(jù)預置規(guī)則自動做出的決定或由組織者人工做出的決定。
本發(fā)明解決的一個主要問題是，在已經(jīng)給予客戶很多問題，且用戶使用SMS文本消息或類似技術時，管理客戶回復的挑戰(zhàn)，其中回復沒有自動包含對詢問的精確參考。本發(fā)明使用動態(tài)對話矩陣解決了此問題。詢問總是包括某種類型的接收者的地址或身份證明。在SMS文本消息情形下，這是所謂的B訂閱者的號碼。另一方面，發(fā)送者的A訂閱者的號碼或主叫線路識別(CLI)、或類似識別也可附加在每條文本消息上。因此，客戶或B訂閱者常常易于使用移動裝置的回答或回復功能回答消息。如果發(fā)送詢問給客戶的中介器服務在不同的詢問中使用不同的A訂閱者號碼，則可能根據(jù)客戶發(fā)送的哪個號碼進行回復在回答之間進行區(qū)分。例如，如果中介器使用訂閱者號碼A1發(fā)送詢問“你還需要出租車嗎？”給客戶，然后從A訂閱者號碼A2詢問“你需要旅館房間嗎？”，則客戶對第一問題的回復到號碼A1，第二回答到號碼A2。使用對話矩陣，中介器跟蹤詢問和回答。在此矩陣中，列用于每個客戶，行用于中介器使用的每個A訂閱者號碼。顯然，也可將行用于每個客戶，相應地將列用于每個A訂閱者號碼。在發(fā)送來自某個A訂閱者號碼的詢問給客戶后，將狀態(tài)和回復儲存在矩陣的相應外殼(shell)中。結果，中介器能發(fā)現(xiàn)客戶是否回復特定請求和發(fā)現(xiàn)回答是什么。同樣，也可能使用矩陣來收集關于客戶行為的信息，且舉例來說將其用于營銷目的。中介器僅需要有限數(shù)目的A訂閱者號碼。對話矩陣還可用于找出在下一詢問被發(fā)送給特定客戶的情況下能夠被使用的A訂閱者號碼。
如上所述的動態(tài)對話矩陣的使用在圖7中示出。
動態(tài)對話矩陣也是用來鑒別僅具有發(fā)送和接收消息的能力的移動電話用戶的有力但非常簡單的安裝措施。問題是服務需要確認發(fā)送者的身份。試圖識別用戶的一種方法是檢查發(fā)送者的地址。通常，SMS、電子郵件、和其它詳細消息附加有發(fā)送者的地址。此地址舉例來說可以是發(fā)送者的A訂閱者號碼或主叫線路識別(CLI)、或電子郵件地址或IP地址。然而，偽造發(fā)送者地址是十分容易的。從服務提供者方面看，從服務提供者到用戶的下行鏈路通常是相對可靠的，且其他人難以捕捉或改變消息，但是從用戶到服務提供者的上行鏈路是非常易受攻擊的，且給出錯誤的發(fā)送者的地址是非常困難的。對上述問題的眾所周知的解決方法是使用加密技術確保通信，公鑰基礎設施(PKI)是很好的實例。例如，用戶裝置舉例來說可裝有微芯片、GSM裝置種的安全的SIM卡，以使用用戶私鑰加密消息。接著，如果該消息可使用用戶公鑰解密，則服務提供者可確保該消息來自該用戶。然而，這種解決方法需要迄今為止不是非常普通的、不昂貴的、或標準化的專用裝置。依靠這樣的解決方法極大地限制了潛在用戶的數(shù)量。
使用DDM提供了新的解決方法。當該服務發(fā)送請求給移動電話用戶時，每個請求都包括不同的優(yōu)選為隨機選擇的回復號碼。因此，可接受的回答僅是發(fā)送給正確的回復地址的回答。
實例2-動態(tài)對話矩陣的使用這個簡單的實例涉及確保明天早班飛機票的問題。該系統(tǒng)發(fā)送一系列問題作為要求簡略響應的SMS消息。每個消息都被打上標志，以便其響應可被識別，從而該消息不必以特定順序被發(fā)送或回復，直到邏輯如此要求(例如如果一個問題的回答影響下一問題的內(nèi)容)。
電話號碼為ID＝0418 979 813的用戶已經(jīng)請求得到機票。該系統(tǒng)發(fā)送以下請求作為各個SMS消息請選擇以下出發(fā)時間中的一個6:00a.m.，回答A7:30a.m.，回答B(yǎng)8:15a.m.，回答C如果這些時間都適合，則回答D發(fā)送者+358440844 027請選擇機票等級頭等艙回答A
商務艙回答B(yǎng)經(jīng)濟艙回答C可得到的最廉價機票回答D發(fā)送者+358440844 011請選擇靠窗座位，回答A靠道座位，回答C發(fā)送者+358440844 034請選擇膳食素食，回答A牛肉，回答B(yǎng)雞肉回答C發(fā)送者+358440844 003從用戶接收的對前述問題和幾個其它問題的回答如下“A”相應于參考號碼+358 440 844 027的問題“D”相應于參考號碼+358 440 844 011的問題
“A”相應于參考號碼+358 440 844 034的問題“B”相應于參考號碼+358 440 844 003的問題“D”相應于參考號碼+358 440 859 751的問題“A”相應于參考號碼+358 440 844 277的問題“C”相應于參考號碼+358 440 841 368的問題據(jù)此，服務提供者可發(fā)現(xiàn)用戶選擇-第一早班 (＝A)，-可得到的最廉價票 (＝D)，-靠窗座位 (＝A)，-牛肉飯 (＝B)，等等。
重要的在于，用戶能利用矩陣以任何次序回答這些問題，且甚至能不回答某些問題。如果這些是相關的，則該系統(tǒng)要求做出回答。如果不是，則該系統(tǒng)沒有此信息也能繼續(xù)。
上述響應在圖8上以三維矩陣示出，用戶號碼繪在X軸上，回復號碼繪在Y軸上，回答繪在Z軸上。具有電話號碼0418 979 813的用戶是沿X軸最靠左的用戶?；卮鹧豘軸相應于Y軸上的回復號碼繪出。
使用語義分析可獲得另外的安全性。在矩陣外殼(matrix shell)中，存在關于詢問和何種回答可接受的信息。如果回答不滿足準則，則它被拒絕。例如，如果服務提供者要求用戶告訴預訂多少項目，且用戶回答“是”，則顯然用戶不直到問題是什么，從而該消息不是對詢問的回答。
同樣是可能的是，服務提供者實際上是中介器，“真實的”服務提供者在其它地方。在此情形下，中介器僅需要具有基于矩陣的系統(tǒng)，且實際的服務提供者使用中介器的矩陣系統(tǒng)或例如秘密信道等其它安全裝置與中介器通信。例如，汽車共用系統(tǒng)可以以下方式實現(xiàn)汽車隨機放在城市周圍。當用戶需要汽車時，他或她發(fā)送消息給中介器，詢問最近的汽車在哪兒。中介器發(fā)送消息告訴汽車的位置。此回復來自隨機地址y′。當用戶到達汽車旁時，他或她發(fā)送消息給y′，告訴租賃時間開始，且要求中介器遠程開鎖。這個消息是相對可靠的，因為它發(fā)送到僅用戶知道的地址。因此，它構成開鎖和開始計費的正當理由。另一方面，中介器和汽車之間的通信對用戶和外人來說是看不見的。汽車可裝有專用裝置，因此，可對遠程命令開鎖等進行加密?；蛘撸嚭椭薪槠髦g的通信也可使用矩陣實現(xiàn)。在任一情況下，中介器作為用戶和車輛之間的“防火墻”進行操作，禁止外人未被授權地使用。
盡管本發(fā)明已經(jīng)參看其某些優(yōu)選實施例相當詳細地進行了描述，但是其它實施例也是可能的。因此，所附權利要求的精神和范圍不應限于本發(fā)明的優(yōu)選實施例。
權利要求
1.一種中介器與具有客戶標識符地址的客戶終端進行通信的方法，包括a)初始化與所述客戶終端的通信，包括使特定回復地址與對話必須被指向的回復相關聯(lián)，包括從所述中介器接收回復的多個地址選擇特定回復；b)初始化與所述客戶終端的對話，所述客戶終端包括所述特定回復地址；c)在所述特定回復地址處接收來自所述客戶終端的回復，所述回復包括所述客戶標識符地址；以及d)使用所述客戶標識符地址和接收所述回復的所述特定回復地址評價所述回復。
2.根據(jù)權利要求1所述的方法，其中，評價所述回復進一步包括分析所述回復的語義。
3.根據(jù)權利要求1所述的方法，其中，所述通信和特定服務提供者有關。
4.根據(jù)權利要求1所述的方法，其中，從所述多個地址選擇所述特定回復地址是隨機的選擇。
5.根據(jù)權利要求1所述的方法，其中，所述通信包括多個對話和與所述客戶終端的回復交換，且初始化包括使不同的回復地址與不同的對話及回復交換關聯(lián)。
6.根據(jù)權利要求5所述的方法，其中，即使當所述不同的回復被以與初始化所述交換不同的順序接收時，也能繼續(xù)評價所述回復。
7.根據(jù)權利要求3所述的方法，其中，初始化通信對建立請求做出響應，所述請求識別所述客戶終端和特定服務提供者。
8.根據(jù)權利要求4所述的方法，進一步包括在矩陣中儲存所述回復，所述矩陣具有對應于客戶標識符地址的第一軸和對應于回復地址的第二軸。
9.根據(jù)權利要求7所述的方法，其中，所述中介器同時與多個其它客戶終端通信，每個客戶終端都具有不同的客戶標識符地址，且其中，所述方法進一步包括跟蹤所述多個地址中的哪個是當前可用的。
10.根據(jù)權利要求8所述的方法，其中，初始化通信進一步包括從當前可用的地址選擇所述特定回復地址。
11.一種中介器，用于控制至少一個服務提供者和客戶終端之間的通信，所述客戶終端具有客戶標識符地址，所述中介器包括a)多個地址，所述中介器能在所述地址接收來自所述客戶終端的消息；b)邏輯和資源，用于i)初始化與關于特定服務提供者的客戶終端的通信，包括使特定回復地址與對話必須被指向的回復相關聯(lián)，所述特定回復地址從所述多個地址中選擇；ii)初始化與所述客戶終端的對話，所述客戶終端包括所述特定回復地址；iii)在所述特定回復地址接收回復；以及iv)使用所述客戶標識符地址和接收所述回復的所述特定回復地址評價所述回復。
12.根據(jù)權利要求11所述的中介器，其中，用于評價所述回復的所述邏輯和資源進一步分析所述回復的語義。
13.根據(jù)權利要求11所述的中介器，其中，所述通信包括多個對話和與所述客戶終端的回復交換，且不同的回復地址與不同的對話和回復交換關聯(lián)。
14.根據(jù)權利要求13所述的中介器，其中，即使當所述不同的回復被無序地從所述詢問接收時，所述邏輯和資源也適于處理對對話的回復。
15.根據(jù)權利要求11所述的中介器，其中，適于初始化所述通信的所述邏輯和資源包括矩陣，所述矩陣具有對應于客戶標識符地址的第一軸和對應于回復地址的第二軸。
16.根據(jù)權利要求11所述的中介器，其中，用于初始化所述通信的所述邏輯和資源適于對建立請求作出響應，所述建立請求用于識別所述客戶終端和所述特定服務提供者。
17.根據(jù)權利要求11所述的中介器，其中，用于從所述多個地址選擇所述特定回復地址的所述邏輯和資源隨機選擇所述選擇。
18.根據(jù)權利要求11所述的中介器，其中，所述客戶標識符是從包括客戶A訂閱者的號碼、主叫線路識別、電子郵件地址、和IP地址的組中選擇的。
19.一種用于控制預訂系統(tǒng)的中介器，所述預訂系統(tǒng)具有至少一個服務提供者和由具有客戶標識符地址的客戶使用的客戶終端裝置，所述中介器包括a)多個地址，所述中介器在所述地址能接收來自所述客戶終端的消息，b)邏輯和資源，用于響應關于所述服務提供者的詢問，準備至少一個對話，使特定回復地址與每個對話關聯(lián)，所述特定回復地址選自所述多個地址，發(fā)送所述至少一個對話給所述客戶終端，在所述特定回復地址處接收來自包括所述客戶標識符地址的所述客戶終端裝置的回復；以及使用所述客戶標識符地址和接收所述回復的所述特定回復地址評價所述回復。
20.根據(jù)權利要求19所述的中介器，其中，所述邏輯和資源包括矩陣，所述矩陣包括用客戶標識符地址索引的第一軸和用回復地址索引的第二軸。
21.根據(jù)權利要求19所述的中介器，其中，所述客戶標識符地址包括標識符，所述標識符選自包括客戶A訂閱者的號碼、主叫線路識別、電子郵件地址、和IP地址的組。
22.根據(jù)權利要求19所述的中介器，其中，用于評價所述回復的所述邏輯和資源進一步分析所述回復的語義。
23.根據(jù)權利要求19所述的中介器，其中，所述詢問對服務請求做出響應，所述服務請求用于識別所述客戶終端裝置。
24.根據(jù)權利要求19所述的中介器，其中，響應于所述請求準備多個對話，且其中，適于結合特定回復地址的所述邏輯和資源適于選擇不同的特定回復地址，以與每個對話關聯(lián)，由此所述邏輯和資源適于評價回復，即使不同回復是以和不同對話的不同順序接收的。
25.根據(jù)權利要求24所述的中介器，其中，所述邏輯和資源包括用于跟蹤當前可用的所述多個不同地址中的那些地址和用于從當前可用的那些地址隨機分配所述特定回復地址的邏輯和資源。
26.根據(jù)權利要求24所述的中介器，其中，所述至少一個對話是通過從一列有序的選擇中選擇一個條目可回答的問題，其中每個選擇具有順序位置。
27.根據(jù)權利要求26所述的中介器，其中，所述矩陣進一步包括用于儲存所述選擇的順序位置的第三軸索引。
28.一種用于來自服務提供者的客戶的中介器預訂資源的方法，所述客戶具有客戶標識符地址，且使用客戶終端裝置與所述中介器通信，所述中介器執(zhí)行以下動作a)響應于請求準備至少一個對話；b)使特定回復地址與每個對話關聯(lián)，所述特定回復地址選自可用于接收來自客戶終端裝置的多個地址；c)發(fā)送所述至少一個對話給所述客戶終端裝置；d)從所述客戶終端裝置接收對所述至少一個對話的回復，所述回復包括所述客戶標識符地址；以及e)使用所述客戶標識符地址和所述特定回復地址評價對所述至少一個對話的回復。
29.根據(jù)權利要求28所述的方法，其中，所述評價所述回復的動作進一步包括分析所述回復的語義。
30.根據(jù)權利要求28所述的方法，進一步包括在矩陣中儲存對所述至少一個對話的回復，所述矩陣包括用客戶標識符索引的第一軸和用回復地址索引的第二軸。
31.根據(jù)權利要求28所述的方法，其中，執(zhí)行使特定回復地址與每個對話關聯(lián)的動作，以便隨機選擇所述特定回復地址。
32.根據(jù)權利要求28所述的方法，其中，所述詢問響應于來自所述客戶終端裝置的服務請求。
33.根據(jù)權利要求28所述的方法，其中，所述客戶標識符地址包括標識符，所述標識符選自包括客戶A訂閱者的號碼、主叫線路識別、電子郵件地址、和IP地址的組。
34.根據(jù)權利要求28所述的方法，其中，準備所述至少一個對話的動作進一步包括將所述至少一個對話準備成可通過從一列有序的選擇中進行選擇而被回答的形式，其中每個選擇在這列選擇中具有順序位置。
35.根據(jù)權利要求28所述的方法，其中，所述至少一個對話包括多個使得不同的特定回復地址與每個對話關聯(lián)的對話，由此可繼續(xù)評價所述回復，即使回復以與發(fā)送對話不同的順序被接收。
36.根據(jù)權利要求34所述的方法，其中，所述矩陣包括為儲存選擇的順序位置被索引的第三軸，且其中，所述方法進一步包括沿所述第三軸儲存對所述至少一個回復的選擇。
37.根據(jù)權利要求34所述的方法，其中，所述客戶終端裝置包括移動電話裝置，所述對話包括SMS消息。
38.一種被編程為中介器的網(wǎng)絡服務器，用于執(zhí)行根據(jù)權利要求28所述的方法。
39.一種被編程為中介器的網(wǎng)絡服務器，用于執(zhí)行根據(jù)權利要求34所述的方法。
40.一種中介器鑒別客戶的方法，所述客戶使用能發(fā)送和接收SMS消息的移動電話裝置，且具有客戶的主叫線路識別號碼，所述中介器執(zhí)行以下動作a)從多個可用的回復地址分配唯一的回復地址給SMS對話；b)以所述客戶的主叫線路識別號碼發(fā)送所述SMS對話給所述客戶；以及c)如果在所述唯一的回復地址處接收對所述SMS對話的回復，則鑒別所述客戶。
41.根據(jù)權利要求40所述的方法，其中，從所述多個可用回復地址中隨機分配所述唯一的回復地址。
42.根據(jù)權利要求40所述的方法，其中，所述中介器包括被編程以執(zhí)行所述方法的網(wǎng)絡服務器，且其中，所述方法進一步包括在矩陣中儲存所述回復，所述矩陣包括用客戶主叫標識符號碼索引的第一軸和用回復地址索引的第二軸。
43.根據(jù)權利要求40所述的方法，其中，所述鑒別動作進一步包括分析所述回復的語義。
全文摘要
本發(fā)明涉及用于在預訂系統(tǒng)中進行預訂并使多個預訂系統(tǒng)中的預訂同步的方法和系統(tǒng)。該系統(tǒng)包括至少一個預訂系統(tǒng)(100)；中介器服務(102)；客戶，使用至少一個可以是移動裝置且包括對話的客戶終端裝置(104)。該客戶使用對話將信息輸入系統(tǒng)中，且中介器從至少一個預訂系統(tǒng)、至少一個服務提供者、和至少一個客戶接收詢問和回答。中介器在它們之間傳遞和修改信息。該方法和系統(tǒng)特別適于通過短消息服務消息與移動電話用戶一起使用。
文檔編號G06Q10/00GK1675637SQ03819821
公開日2005年9月28日 申請日期2003年8月21日 優(yōu)先權日2002年8月21日
發(fā)明者尤卡·薩洛寧 申請人:布科特有限公司