信息處理裝置以及信息處理方法
【專利摘要】本發(fā)明涉及與混搭（mashup）技術(shù)相關(guān)的信息處理裝置和信息處理方法。根據(jù)本發(fā)明的實施例的信息處理裝置包括：記錄單元，其被配置為記錄對資源進行訪問的請求；發(fā)現(xiàn)單元，其被配置為在記錄單元中查找符合與資源狀態(tài)變化有關(guān)的預(yù)定模式的請求組合；以及混搭單元，其被配置為在與請求組合相對應(yīng)的功能組合中確定可混搭的功能組合，其中功能對應(yīng)于針對相同類型的資源或者同一資源的、具有相同動作類型的請求。通過根據(jù)本發(fā)明的實施例的信息處理裝置和相應(yīng)的信息處理方法，實現(xiàn)了針對用戶的使用習(xí)慣來提供混搭應(yīng)用。
【專利說明】信息處理裝置以及信息處理方法

【技術(shù)領(lǐng)域】
[0001] 本公開涉及信息處理領(lǐng)域，更具體地，涉及與混搭（mashup)技術(shù)相關(guān)的信息處理 裝置和信息處理方法。

【背景技術(shù)】
[0002] 混搭(Mashup)是一種使得開發(fā)者可以利用現(xiàn)有的API (應(yīng)用編程接口）或服務(wù)來 創(chuàng)建新的應(yīng)用的技術(shù)。傳統(tǒng)的混搭方法分為兩大類：服務(wù)端混搭方法和客戶端混搭方法。 在服務(wù)端進行混搭，主要是通過一個作為中繼的代理服務(wù)器對所請求的頁面進行改寫或?qū)?多個來源的頁面或資源進行重新組織來實現(xiàn)的，例如在地圖應(yīng)用上顯示租房信息的混搭應(yīng) 用。而在客戶端進行混搭，主要是通過例如javascript腳本、瀏覽器擴展或插件的形式進 行的，例如基于Chrome瀏覽器的、針對電子商務(wù)網(wǎng)站的擴展，比如針對中國鐵路購票網(wǎng)站 的購票擴展。


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

[0003] 發(fā)現(xiàn)潛在的可以進行混搭的功能是進行混搭應(yīng)用開發(fā)的前提。但是對于傳統(tǒng)的混 搭應(yīng)用開發(fā)方法來說，開發(fā)者通常需要主觀地決定對哪些功能進行混搭，而無法考慮用戶 的使用習(xí)慣。因此，這樣創(chuàng)建出來的混搭應(yīng)用并不一定符合用戶的實際使用習(xí)慣。而且，對 于傳統(tǒng)的混搭應(yīng)用創(chuàng)建方法來說，根據(jù)用戶的使用習(xí)慣而提供混搭應(yīng)用也是非常困難的。
[0004] 因此，本公開的目的在于提供一種可以根據(jù)用戶的使用習(xí)慣來提供混搭應(yīng)用的信 息處理裝置和信息處理方法。
[0005] 根據(jù)本公開的實施例所提供的信息處理裝置包括：記錄單元，其被配置為記錄對 資源進行訪問的請求；發(fā)現(xiàn)單元，其被配置為在記錄單元中查找符合與資源狀態(tài)變化有關(guān) 的預(yù)定模式的請求組合；以及混搭單元，其被配置為在與請求組合相對應(yīng)的功能組合中確 定可混搭的功能組合，其中功能對應(yīng)于針對相同類型的資源或者同一資源的、具有相同動 作類型的請求。
[0006] 根據(jù)本公開的實施例所提供的信息處理方法包括：記錄對資源進行訪問的請求； 查找符合與資源狀態(tài)變化有關(guān)的預(yù)定模式的請求組合；以及在與請求組合相對應(yīng)的功能組 合中確定可混搭的功能組合，其中功能對應(yīng)于針對相同類型的資源或者同一資源的、具有 相同動作類型的請求。
[0007] 通過根據(jù)本公開的實施例的信息處理裝置和信息處理方法，實現(xiàn)了根據(jù)用戶的使 用習(xí)慣來提供混搭應(yīng)用。

【專利附圖】

【附圖說明】
[0008] 從對說明本發(fā)明的主旨及其使用的優(yōu)選實施例和附圖的以下描述來看，本發(fā)明的 以上和其它目的、特點和優(yōu)點將是顯而易見的，在附圖中：
[0009] 圖1是示出了根據(jù)本公開的第一實施例的信息處理裝置的配置的框圖；
[0010] 圖2是示出了用戶所進行的請求的示意圖；
[0011] 圖3是示出了根據(jù)本公開的第二實施例的信息處理方法的流程圖；并且
[0012] 圖4是示出了根據(jù)本公開的第三實施例的信息處理設(shè)備的硬件配置的框圖。

【具體實施方式】
[0013] 以下，將結(jié)合附圖來詳細描述本公開的實施例。
[0014] 下文中，將按照以下順序來進行說明。
[0015] L本公開的第一實施例(信息處理裝置）
[0016] 2.本公開的第二實施例(信息處理方法）
[0017] 3.本公開的第三實施例(將本公開應(yīng)用于計算機）
[0018] L本公開的第一實施例(信息處理裝置）
[0019] 以下，將結(jié)合圖1和圖2來描述根據(jù)本公開的第一實施例的信息處理裝置。
[0020] 首先，圖1中示出了根據(jù)本公開的第一實施例的信息處理裝置100。
[0021] 信息處理裝置100包括記錄單元101、發(fā)現(xiàn)單元102和混搭單元103。記錄單元 101記錄對資源進行訪問的請求。發(fā)現(xiàn)單元102在記錄單元101中查找符合與資源狀態(tài)變 化有關(guān)的預(yù)定模式的請求組合?；齑顔卧?03在與上述請求組合相對應(yīng)的功能組合中確定 可混搭的功能組合。其中，功能對應(yīng)于針對相同類型的資源或者同一資源的、具有相同動作 類型的請求。
[0022] 當(dāng)用戶頻繁地在多個系統(tǒng)之間切換來實現(xiàn)某個操作目的時，往往意味著在這些系 統(tǒng)之間存在可以進行整合的功能，以使得用戶可以更方便、快捷地實現(xiàn)其操作目的。
[0023] 例如圖2所示，房屋賣家10 (下文中稱為用戶10)可以針對某個網(wǎng)站的房屋交易 信息數(shù)據(jù)庫中記錄的信息200 (下文中稱為資源200)發(fā)布賣房信息，該動作可以稱為請求 201。房屋潛在買家20 (下文中稱為用戶20)可以查詢系統(tǒng)200最近的更新，并且注意到用 戶10所發(fā)布的賣房信息,該動作可以稱為請求202。隨后，用戶20可以針對用戶10所發(fā)布 的賣房信息，到地圖網(wǎng)站的數(shù)據(jù)庫中記錄的信息300 (下文中稱為資源300)中查詢賣房信 息中所涉及房屋的地理位置，該動作可以稱為請求203。
[0024] 以上請求201、202和203是房屋交易信息查詢活動中常見的操作。在該操作中， 用戶20需要訪問兩個資源200、300,并且需要從資源200中的賣房信息中找出與所涉及的 房屋的地理位置相關(guān)的信息，并且在資源300中檢索該地理位置。這樣的一系列操作是繁 瑣的。
[0025] 通過對用戶10、20的以上操作的分析，可以發(fā)現(xiàn)該操作中存在預(yù)定的模式，這個 模式的基本特征如下：
[0026] 1)在這個模式中有兩個資源200、300和兩個用戶10、20 ;
[0027] 2)首先，用戶10和20對同一個資源200進行操作。具體來說，用戶10創(chuàng)建或更 新(修改、添加或刪除）資源200,而用戶20檢查資源200的狀態(tài)；
[0028] 3)隨后，用戶20根據(jù)資源200的狀態(tài)來對資源300進行操作。具體來說，該操作 是查詢。
[0029] 換言之，請求201、202和203作為一個請求組合，具有如下特征：請求201是用戶 10對資源200的請求，請求202是用戶20對資源200的請求，請求203是用戶20對資源 300的請求，請求201的動作是使得資源200發(fā)生變化的動作，并且請求202的動作是查詢。
[0030] 此處，并未對請求203的動作類型進行限定，這是因為，請求203不僅可以是圖2 中所示的查詢動作，也可以是其他類型的動作。例如，請求203可以對應(yīng)于如下動作：用戶 20在查詢了資源200中的賣房信息之后，在資源300中更新了對于某地理位置的評論(例如 "這里的房價很便宜！ ")。換言之，請求203也可以是用戶20對資源300的修改。
[0031] 可選地，請求201、202和203的請求組合還可以具有更加嚴(yán)格的特征：在進行請求 201和202的時刻之間資源200未被修改，這可以確保請求201是在請求202查詢資源200 之前最后一次對資源200的修改；進行請求201和202的時刻之間的差小于第一閾值，并且 進行請求202和203的時刻之間的差小于第二閾值，這可以確保請求組合中的請求之間在 時間上彼此相差不會太久。
[0032] 此外，請求201、202和203的請求組合還可以具有更加嚴(yán)格的特征，例如要求第一 閾值大于第二閾值，這是因為用戶10的請求201與用戶20的請求202之間的時間間隔往 往大于用戶20的請求202、203之間的時間間隔。
[0033] 請求201、202和203分別對應(yīng)于相應(yīng)的功能。這里所說的"功能"，對應(yīng)于針對相 同類型的資源或者同一資源的、具有相同動作類型的請求。
[0034] 例如，不同用戶在不同時刻對資源200的創(chuàng)建、更新都可以被視為對應(yīng)于同一功 能。不同用戶在不同時刻對于與資源200同屬一類的資源的創(chuàng)建、更新也可以被視為對應(yīng) 于同一功能。例如在資源200是網(wǎng)站A的房屋交易信息數(shù)據(jù)庫中所記錄的信息而資源210 是網(wǎng)站B的房屋交易信息數(shù)據(jù)庫中所記錄的信息的情況下，資源200、210可以被認(rèn)為是相 同類型的資源。此外，例如在資源200是網(wǎng)站A的X市房屋交易信息數(shù)據(jù)庫中所記錄的信 息而資源220是網(wǎng)站A的Y市房屋交易信息數(shù)據(jù)庫中所記錄的信息的情況下，資源200、220 也可以被認(rèn)為是相同類型的資源。換言之，"相同類型的資源"可以位于同一系統(tǒng)中，也可以 位于不同系統(tǒng)中。
[0035] 分別對應(yīng)于請求201、202和203的功能組成了對應(yīng)于請求201、202和203的請求 組合的功能組合。
[0036] 基于記錄單元101對用戶的請求的記錄，發(fā)現(xiàn)單元102可以發(fā)現(xiàn)一個或多個符合 例如上述預(yù)定模式的請求組合?；齑顔卧?03在與這些請求組合相對應(yīng)的功能組合當(dāng)中， 確定可以混搭的功能組合。
[0037] 可以混搭的功能組合的可以依據(jù)各種類型的適當(dāng)條件來確定。例如，可以根據(jù)功 能組合在記錄出現(xiàn)的次數(shù)（即，與該功能組合相對應(yīng)的請求組合在記錄中出現(xiàn)的次數(shù)）來判 定該功能組合是否可以進行混搭。出現(xiàn)次數(shù)高的功能組合往往適于被進行混搭。
[0038] 此外，還可以基于如下條件來確定可以混搭的功能組合：
[0039] 與功能組合相對應(yīng)的請求組合與具有分別對應(yīng)于可混搭的功能組合中的前兩個 功能的請求的請求組合的數(shù)量之比大于第三閾值；以及
[0040] 具有分別對應(yīng)于可混搭的功能組合中的前兩個功能的請求的請求組合的數(shù)量大 于第四閾值。
[0041] 換言之，通過條件概率來確定可以混搭的功能組合。具體來說，在出現(xiàn)符合預(yù)定模 式的第一請求(例如，對應(yīng)于請求201的請求）和第二請求(例如，對應(yīng)于請求202的請求） 時，出現(xiàn)符合預(yù)定模式的第三請求(例如，對應(yīng)于請求203的請求）的概率越大，對應(yīng)于符合 該預(yù)定模式的請求組合的功能組合就越有可能是可以混搭的功能組合。此外，這里還限定 了出現(xiàn)符合預(yù)定模式的第一請求和第二請求的次數(shù)，以防止統(tǒng)計結(jié)果中的干擾。（例如，符 合預(yù)定模式的第一請求和第二請求出現(xiàn)了一次，而且符合預(yù)定模式的第一請求、第二請求、 和第三請求也出現(xiàn)了一次，此時作為上述判斷依據(jù)的比是100%，但是實際上這三個請求的 組合很有可能是巧合而非有意的操作。）
[0042] 可以針對所有用戶來確定可以混搭的功能組合，即，功能對應(yīng)于來自不同用戶的 請求。也可以針對具體用戶來確定可以混搭的功能組合，即，功能僅僅對應(yīng)于一個或一組用 戶的請求。此時，針對不同用戶或者用戶組，所得到的功能組合是不同的。就是說，這樣得 到的可以混搭的功能組合考慮到了不同用戶的偏好。例如，用戶21在看到了新的賣房信息 之后常做的是去地圖網(wǎng)站查詢地理位置以及查詢針對該地理位置的評論，而用戶22在看 到了新的賣房信息之后常做的則是去地圖網(wǎng)站針對相應(yīng)的地理位置發(fā)表評論。因此，對于 用戶21，可以混搭的功能組合包括任一其他用戶修改資源200、用戶21訪問資源200、用戶 21查詢資源300,而對于用戶22,可以混搭的功能組合則包括任一其他用戶修改資源200、 用戶22訪問資源200、用戶22修改資源300。
[0043] 利用以上所得到的可以混搭的功能組合，信息處理裝置100還可以進一步方便用 戶的使用。
[0044] 例如，信息處理裝置100還可以包括輸入單元104 (未示出）和輸出單元105 (未 示出）。輸入單元104接收對資源進行訪問的當(dāng)前請求，并且確定當(dāng)前請求所對應(yīng)的功能是 否包括在可混搭的功能組合中。輸出單元105在確定當(dāng)前請求所對應(yīng)的功能包括在可混搭 的功能組合中的情況下，基于當(dāng)前請求和可混搭的功能組合來進行輸出。
[0045] 具體來說，輸出單元105可以在確定當(dāng)前請求所對應(yīng)的功能包括在可混搭的功能 組合中的情況下，如果當(dāng)前請求對應(yīng)于可混搭的功能組合中的第一功能（即對應(yīng)于第一請 求的功能)，則將第一請求的用戶對第一請求的資源所進行的創(chuàng)建、修改或刪除通知給第二 請求的用戶。在該情況下，需要針對具體用戶來確定可以混搭的功能組合，因此才能在接收 到第一請求時確定第二請求的用戶的身份。
[0046] 此外，輸出單元105可以在確定當(dāng)前請求所對應(yīng)的功能包括在可混搭的功能組合 中的情況下，如果當(dāng)前請求對應(yīng)于可混搭的功能組合中的第二功能（即對應(yīng)于第二請求的 功能)，則將第三請求的資源提示給第二請求的用戶。因此，第二請求的用戶可以更加便利 地訪問第三請求的資源。此外，還可以在第二請求的用戶訪問第三請求的資源時，向該用戶 展示其在訪問第二請求的資源時所查詢的內(nèi)容，或根據(jù)其在訪問第二請求的資源時所查詢 的內(nèi)容顯示第三請求的資源的內(nèi)容。具體來說，當(dāng)用戶20發(fā)現(xiàn)用戶10更新了資源200中 的賣房信息時去查詢資源200,此時，信息處理裝置100可以向用戶20提示他在第三請求中 經(jīng)常訪問的地圖網(wǎng)站(資源300所屬的系統(tǒng))的網(wǎng)址，并且可以進一步在用戶20訪問該地圖 網(wǎng)站時，將當(dāng)前顯示內(nèi)容定位在用戶20所查詢的賣房信息中所提到的地理位置處。
[0047] 本領(lǐng)域普通技術(shù)人員應(yīng)該理解，信息處理裝置100也可以通過輸入單元104和輸 出單元105之外的其他方式來利用所確定的可以混搭的功能組合，來為用戶的操作提供便 利。
[0048] 此外，雖然以上列出了由具有第一請求、第二請求和第三請求的請求組合構(gòu)成的 預(yù)定模式，該模式僅僅是本領(lǐng)域普通技術(shù)人員可以想到的各種預(yù)定模式的一個示例。還存 在其他各種適當(dāng)類型的預(yù)定模式。例如，存在以下預(yù)定模式：該預(yù)定模式包括第一請求和第 二請求，第一請求是第一用戶改變第一資源的請求，第二請求是第一用戶改變第二資源的 請求。此處，預(yù)定模式僅涉及一個用戶，該用戶依次改變第一資源和第二資源。具體來說， 例如作為房屋賣家的用戶需要發(fā)布賣房信息時，往往需要修改不止一個數(shù)據(jù)庫中所記錄的 信息，例如需要修改多個網(wǎng)站的房屋交易信息數(shù)據(jù)庫中所記錄的信息，此時，當(dāng)用戶修改第 一個房屋交易信息數(shù)據(jù)庫中所記錄的信息時，信息處理裝置可以向用戶提示需要修改的第 二個房屋交易信息數(shù)據(jù)庫中的相應(yīng)信息(資源)，從而為用戶的操作提供方便。
[0049] 以下，將詳細描述一個【具體實施方式】。
[0050] 在該【具體實施方式】中，多個不同的系統(tǒng)各自包括可以訪問的資源，并且用戶對資 源的訪問是通過網(wǎng)絡(luò)實現(xiàn)的。
[0051] 首先，用戶向輸入單元104發(fā)送一個HTTP請求以訪問一個網(wǎng)頁或操作系統(tǒng)中的一 個資源。輸入單元104通過記錄單元101將該HTTP請求和響應(yīng)記錄到歷史記錄中，并調(diào)用 混搭單元103以確定所述當(dāng)前請求所對應(yīng)的功能是否包括在可混搭的功能組合中。
[0052] 混搭單元103調(diào)用發(fā)現(xiàn)單元102來在歷史記錄中查找涉及當(dāng)前請求的、符合與資 源狀態(tài)變化有關(guān)的預(yù)定模式的請求組合。隨后，混搭單元103在與這些請求組合相對應(yīng)的 功能組合中確定可混搭的功能組合并且將相應(yīng)的功能組合提供給輸入單元。
[0053] 混搭單元103在確定當(dāng)前請求所對應(yīng)的功能包括在可混搭的功能組合中的情況 下，調(diào)用輸出單元105來基于當(dāng)前請求和可混搭的功能組合進行輸出。
[0054] 對于通常的歷史記錄而言，其中不僅包含對目標(biāo)資源進行操作的請求，而且包含 一些為了進行頁面顯示的輔助性HTTP請求，例如JavaScript腳本等。因此，可以在發(fā)現(xiàn)單 元102對歷史記錄中的資源和用戶進行識別之前，對歷史記錄中的請求記錄進行過濾。通 過定義一些規(guī)則，例如擴展名，可以很方便地實現(xiàn)對這些請求的過濾。
[0055] 如何對HTTP請求操作的資源(包括資源類型和資源ID)進行識別取決于Web服務(wù) 的類型。例如，對于RESTful Web服務(wù)，可以通過解析URL來識別資源。下面是一個RESTful URL的例子：
[0056] http://www. bookstore, com/book/180
[0057] 其中book是資源類型，而180是該資源的id。此外，對于RESTful Web服務(wù)來說， 請求中的HTTP方法(如GET、P0ST)指明了它對該資源是進行讀或者寫操作。對于其他類型 的Web服務(wù)(如WSDL Web服務(wù))，本領(lǐng)域普通技術(shù)人員可以采用其他適當(dāng)?shù)姆椒ā?br> [0058] 盡管用戶可能通過不同的賬號訪問不同的系統(tǒng)，但是他們的IP地址在他們訪問 這些系統(tǒng)的這段很短的時間內(nèi)通常是不會改變的。因此，可以通過發(fā)出HTTP請求的用戶的 IP地址來識別用戶。
[0059] 基于上述資源識別和用戶識別，我們將HTTP請求Η用以下五元組來進行定義：
[0060] H= (S, U, M, R, T) (1)
[0061] 其中S表示目標(biāo)Web系統(tǒng)的域名，例如：www. crm. com, www. erp. com等，用以區(qū)分 不同的目標(biāo)系統(tǒng)。
[0062] U代表發(fā)出該請求的用戶的IP，例如：10. 167. 175. 164,用以區(qū)分不同的用戶。
[0063] Μ表示該請求的HTTP方法，包括GET，POST，PUT，DELETE等，用以區(qū)分不同的動作。
[0064] R表示該請求所針對的資源(例如可以包含類型Type和ID兩個屬性)，例如： Type=book, ID=180,用以區(qū)分同一系統(tǒng)中的不同資源。
[0065] T代表該請求發(fā)出的時間，用以確定執(zhí)行該請求的時刻。
[0066] 利用以上定義，本領(lǐng)域普通技術(shù)人員可以很方便地得到符合前文所述的預(yù)定模式 的請求組合。
[0067] 下面，需要獲得與請求組合相對應(yīng)的功能組合。為此，首先需要定義功能。
[0068] 由于不同的用戶可以在不同時間對相同類型的資源重復(fù)相同的操作，可以將請求 Η對應(yīng)的功能F定義如下：
[0069] F=F(H) = (S, M, Typeof (R)) (2)
[0070] 在該定義中，指明了資源類型、方法和資源所屬系統(tǒng)。
[0071] 如果需要針對不同用戶提供不同的可混搭的功能組合，那么功能F可以按如下進 行定義：
[0072] F=F(H) = (S, U, M, Typeof (R)) (3)
[0073] 此外，如果需要考慮特定的資源考慮的話，功能F可以按如下進行定義：
[0074] F=H= (S, U, M, R) (4)
[0075] 給定兩個功能，它們相等意味著功能的每個部分分別相等。例如，當(dāng)我們定義功能 F= (S，M，Typeof (R))時：
[0076] Fi==F」等價于 Si=Sj 且 Mi=M」且 Typeof 取）=Typeof (Rj)。
[0077] 在定義了功能F之后，需要確定的是功能組合是否是可混搭的。首先，與該 功能組合相對應(yīng)的請求組合應(yīng)該與前述的預(yù)定模式相匹配。因此，可以找出所有與 預(yù)定模式相匹配的請求組合（--?}。但是，由于并不是所有與預(yù)定模式相匹配的請求組合 都是可混搭的，因此需要進一步進行過濾。
[0078] 對于歷史記錄中的{氏| i=l, 2,…，η}以及每一個與預(yù)定模式匹配的請求組合 氏民凡，計算相應(yīng)功能組合Ffh和FA的出現(xiàn)次數(shù)（C (F)表示F在歷史記錄中出現(xiàn)的次數(shù))，
[0079] 在搜索全部和Η#」時，可以使用如下算法：先查找符合條件的H」，然后再向 后(在時間上更早的方向上)查找氏，最后從Η」向前(在時間上更新的方向上)查找H k。在要 求氏和&之間的時間差小于閾值λ 2的情況下，由于只查找與&時間間隔小于λ 2的請求 來作為氏，因此該查找的時間復(fù)雜度為一個常數(shù)。同理，查找Hk的時間復(fù)雜度也是一個常 數(shù)。因此，可以證明該查找算法總的時間復(fù)雜度為〇(n)，其中η是歷史記錄的規(guī)模。
[0080] 當(dāng)然，本領(lǐng)域普通技術(shù)人員也可以利用任何其他適當(dāng)?shù)乃惴▉硭阉魅?--和 啡。
[0081] 在得到所有的與資源訪問模式匹配的請求組合（--?}之后，進一步按照以下方 式估算條件概率：
[0082]

【權(quán)利要求】
1. 一種信息處理裝置，其包括： 記錄單元，其被配置為記錄對資源進行訪問的請求； 發(fā)現(xiàn)單元，其被配置為在所述記錄單元中查找符合與資源狀態(tài)變化有關(guān)的預(yù)定模式的 請求組合；以及 混搭單元，其被配置為在與所述請求組合相對應(yīng)的功能組合中確定可混搭的功能組 合，其中功能對應(yīng)于針對相同類型的資源或者同一資源的、具有相同動作類型的請求。
2. 根據(jù)權(quán)利要求1所述的信息處理裝置，其中： 符合與資源狀態(tài)變化有關(guān)的預(yù)定模式的請求組合包括第一用戶對第一資源的第一請 求、第二用戶對第一資源的第二請求、以及第二用戶對第二資源的第三請求，其中，第一請 求的動作是使得第一資源發(fā)生變化的動作，并且第二請求的動作是查詢；并且 與所述請求組合相對應(yīng)的功能組合包括對應(yīng)于第一請求的第一功能、對應(yīng)于第二請求 的第二功能、以及對應(yīng)于第三請求的第三功能。
3. 根據(jù)權(quán)利要求2所述的信息處理裝置，其中： 在進行第一請求和第二請求的時刻之間第一資源未被修改，進行第一請求與進行第二 請求的時刻之差小于第一閾值，并且進行第二請求與進行第三請求的時刻之差小于第二閾 值。
4. 根據(jù)權(quán)利要求2或3所述的信息處理裝置，其中： 可混搭的功能組合滿足如下條件： 對應(yīng)于可混搭的功能組合的請求組合與具有分別對應(yīng)于可混搭的功能組合中第一功 能和第二功能的請求的請求組合的數(shù)量之比大于第三閾值；以及 具有分別對應(yīng)于可混搭的功能組合中第一功能和第二功能的請求的請求組合的數(shù)量 大于第四閾值。
5. 根據(jù)權(quán)利要求2至4中任一項所述的信息處理裝置，其還包括： 輸入單元，其被配置為接收對資源進行訪問的當(dāng)前請求，并且確定所述當(dāng)前請求所對 應(yīng)的功能是否包括在可混搭的功能組合中；以及 輸出單元，其被配置為在確定當(dāng)前請求所對應(yīng)的功能包括在可混搭的功能組合中的情 況下，基于當(dāng)前請求和可混搭的功能組合來進行輸出。
6. 根據(jù)權(quán)利要求5所述的信息處理裝置，其中： 功能對應(yīng)于相同用戶針對相同類型的資源或同一資源的、具有相同動作類型的請求， 并且 所述輸出單元被進一步配置為在確定當(dāng)前請求所對應(yīng)的功能包括在可混搭的功能組 合中的情況下，如果當(dāng)前請求對應(yīng)于可混搭的功能組合中的第一功能，則將第一用戶對第 一資源所進行的創(chuàng)建、修改或刪除通知給第二用戶。
7. 根據(jù)權(quán)利要求5或6所述的信息處理裝置，其中： 所述輸出單元被進一步配置為在確定當(dāng)前請求所對應(yīng)的功能包括在可混搭的功能組 合中的情況下，如果當(dāng)前請求對應(yīng)于可混搭的功能組合中的第二功能，則將第二資源提示 給第二用戶。
8. 根據(jù)權(quán)利要求1至7中任一項所述的信息處理裝置，其中： 功能對應(yīng)于針對不同系統(tǒng)中相同類型的資源的、具有相同動作類型的請求。
9. 根據(jù)權(quán)利要求1至8中任一項所述的信息處理裝置，其中： 功能對應(yīng)于針對同一系統(tǒng)中相同類型的資源或同一資源的、具有相同動作類型的請 求。
10. -種信息處理方法，其包括： 記錄對資源進行訪問的請求； 查找符合與資源狀態(tài)變化有關(guān)的預(yù)定模式的請求組合；以及 在與所述請求組合相對應(yīng)的功能組合中確定可混搭的功能組合，其中功能對應(yīng)于針對 相同類型的資源或者同一資源的、具有相同動作類型的請求。
【文檔編號】G06Q30/06GK104102657SQ201310121409
【公開日】2014年10月15日 申請日期:2013年4月9日 優(yōu)先權(quán)日:2013年4月9日
【發(fā)明者】鐘朝亮, 張軍, 鄒綱, 皮冰鋒, 黃琦珍, 于浩, 松尾昭彥 申請人:富士通株式會社