下面結合圖式，對本說明書提供的方案進行描述。
圖1為本說明書揭露的一個實施例的實施場景示意圖。如圖1所示，該實施場景的系統包括車輛終端100，乘客終端200和車輛管理系統伺服器300。車輛終端100是車輛（例如，出租車）上的終端裝置。可以預先為各個車輛終端100產生或分配識別碼，例如二維碼，其中攜帶有對應車輛的車輛資訊。當乘客搭乘出租車時，乘客利用乘客終端200識別車輛終端100的識別碼，獲知車輛資訊。之後乘客終端200提供地址輸入介面給乘客，於是乘客可以利用自己的語言（第一語言，例如中文）輸入目的地地址。乘客終端200將這樣的目的地地址轉換為地理位置坐標，連同車輛資訊一起，發送給車輛管理系統伺服器300。車輛管理系統伺服器300接收到車輛資訊和地理位置坐標之後，將地理位置坐標轉換為本地語言（第二語言，例如韓語），然後將本地語言的目的地地址發送到上述車輛資訊所對應的車輛終端100。於是，出租車司機可以透過車輛終端100獲知以本地語言形式描述的目的地地址，從而可以順利將乘客送往目的地。如此，克服了外國乘客與本地出租車司機之間的語言溝通障礙。
進一步地，在抵達目的地之後，出租車司機可以透過車輛終端100進行車費結算，結算請求透過車輛管理系統伺服器300發送給乘客終端200。在乘客確認結算無誤的情況下，車輛管理系統伺服器300向乘客終端200對應的支付伺服器發出支付請求，並在支付成功的情況下，分別通知車輛終端100和乘客終端200。如此，實現了乘客與出租車司機的便利支付。
下面描述以上實施場景中各個步驟的執行和實現方式。
首先描述搭乘階段。在該階段中，車輛終端、乘客終端與車輛管理系統服務端互相互動，使得乘客可以用第一語言輸入目的地地址，而車輛終端最終接收到第二語言（當地語言）的地址形式，實現跨語言的地址資訊處理。
為此，出租車中需要配備有車輛終端，並且車輛終端需要具有對應的識別碼。在一個例子中，出租車中安裝有智慧型結算器，該結算器可以用於結算車費、車輛導航等功能，還可以與車輛管理系統服務端互動。在這樣的情況下，這樣的智慧型結算器可以作為上述車輛終端。在另一例子中，出租車司機使用傳統計價器進行計價，同時使用手機上的司機客戶端在出租車管理系統中進行身份認證、註冊，並與出租車管理系統進行互動，還可以進行導航。在這樣的情況下，計價器、司機客戶端等共同構成車輛終端。在其他例子中，根據當地出租車公司的配置狀況，車輛終端還可以具有其他形式。
可以預先為各個車輛或對應的車輛終端產生識別碼。該識別碼可以是二維碼，或者聲波碼，或者其他能夠包含車輛資訊的編碼形式。對於二維碼來說，已經存在多種產生工具和產生方式。在一個實施例中，車輛終端可以離線產生二維碼；或者，在另一實施例中，車輛終端可以連線產生二維碼。在一個實施例中，為每個車輛終端產生唯一的恆定的二維碼。出租車司機可以透過車輛終端顯示這樣的二維碼，或者可以將二維碼列印出來，貼附在車輛中進行顯示。對於聲波碼來說，可以採用聲波碼產生工具來產生，並透過車輛終端播放相應聲波音頻來“顯示”該聲波碼。
另一方面，乘客終端可以體現為便攜式智慧型設備，例如智慧型手機。在一個實施場景中，用戶可以透過各種方式，例如網上預約，臨時路邊招手攔車等，搭乘一輛出租車。這時，用戶成為乘客，透過乘客終端識別所搭乘的出租車的識別碼，進而觸發圖2所示的跨語言處理方法。其中識別碼的形式、產生方式和顯示方式如前所述，不再贅述。在接下來的描述中，均以二維碼為例進行說明，但是需要理解的是，相關實施例均可以類似地應用於聲波碼，或者其他類似的編碼形式。
圖2顯示根據一個實施例的跨語言處理方法的流程圖，該方法在乘客終端中執行。更具體而言，該方法的執行主體可以是乘客終端中的乘客客戶端，該客戶端可以體現為專用的App，或者只是一個頁面，例如H5頁面。如圖2所示，乘客客戶端執行的方法包括：步驟21，回應於用戶的第一請求，提供地址輸入介面，所述第一請求透過識別車輛終端的識別碼而產生，所述識別碼中包含車輛資訊；步驟22，透過所述地址輸入介面，接收用戶輸入的第一語言的目的地地址資訊；步驟23，確定所述目的地地址資訊對應的目的地坐標資料；步驟24，將所述車輛資訊和所述目的地坐標資料發送給車輛管理系統服務端。下面描述上述各個步驟的執行過程。
在一個實施例中，在步驟21之前，用戶在搭乘出租車後，打開乘客客戶端（例如專用的App，或者網頁頁面），利用該客戶端掃描、識別出租車車輛終端的二維碼，即執行步驟20。在步驟20，上述客戶端在成功識別車輛終端對應的二維碼的同時，觸發一個請求，以下稱為第一請求。第一請求用於請求提供地址輸入介面。
在另一個實施例中，用戶在搭乘出租車後，利用乘客終端中安裝的第三方工具，例如支付寶，kakao TALK（韓國常用的一款社交App），掃描、識別出租車的二維碼。在這樣的情況下，二維碼中除了攜帶車輛資訊，還需要攜帶用於執行圖2方法的乘客客戶端的鏈接資訊。例如上述乘客客戶端體現為一個H5頁面，那麼車輛終端顯示的二維碼中除了攜帶車輛資訊，還需要攜帶指向該H5頁面的url（統一資源定位符）。如此，在支付寶掃描二維碼，解析出二維碼對應的字符串後，就會識別出其中的url，並根據該url重新導向到目標頁面，即上述乘客客戶端的H5頁面。在該重新導向過程中，由支付寶向上述乘客客戶端，例如H5頁面發出請求（也稱為第一請求），該請求中包含識別出的車輛資訊，並請求H5頁面提供地址輸入介面。
接著，由上述乘客客戶端執行接下來的步驟21至24。在步驟21，回應於上述的第一請求，提供地址輸入介面。如前所述，上述第一請求透過識別車輛終端的識別碼而產生；更具體地，既可以由本客戶端工具進行二維碼掃描識別而產生，也可以由例如支付寶的第三方工具進行掃描識別，然後進行重新導向而產生。
回應於這樣的請求，在步驟21，提供地址輸入介面。在一個實施例中，透過呼叫第三方的地圖應用程式來提供地址輸入介面。可以理解，所呼叫的地圖應用程式支援上述用戶/乘客所使用的第一語言（例如中文）的地圖顯示。在另一實施例中，上述專用的乘客客戶端提供獨立的地址輸入介面。
在一個實施例中，在提供地址輸入介面之前，向用戶顯示掃描識別出的車輛資訊，以供用戶（乘客）確認。在得到用戶確認之後，才提供地址輸入介面，顯示地址輸入介面。掃描識別碼所識別的車輛資訊可以包括，車輛的車牌號、所屬出租車公司、運營情況、該車輛對應的司機資訊，等等。
在向用戶提供地址輸入介面之後，在步驟22，透過所述地址輸入介面，接收用戶輸入的第一語言的目的地地址資訊。具體地，用戶可以經由上述地址輸入介面，透過多種方式，以該用戶所熟悉的語言（第一語言，例如中文）輸入其目的地地址。例如，地址輸入介面可以體現為地址輸入框，用戶可以在該輸入框中，以第一語言輸入目的地地址的地址文本，例如“首爾塔”。該地址輸入介面還可以提供語音輸入方式，接收用戶的第一語言的語音，將所述語音轉換為第一語言的地址文字。在一個實施例中，地址輸入介面透過呼叫地圖應用程式來提供。這時，用戶可以在地圖中進行放大、縮小、拖拽等定位操作，從而在地圖上選定目的地。地圖應用程式根據用戶的定位操作確定出第一語言的目的地地址。
在透過地址輸入介面接收到第一語言的目的地地址之後，在步驟23，確定該目的地地址對應的地理坐標資料，例如經緯度資料。在一個實施例中，客戶端在本地儲存地圖資料，利用這樣的地圖資料，將目的地地址轉換為地理坐標資料。在另一實施例中，上述客戶端呼叫第三方的地圖應用程式來獲取目的地地址。在這樣的情況下，可以由該地圖應用程式將用戶輸入的目的地地址轉換為地理坐標資料，客戶端從所述地圖應用程式獲取所述地理坐標資料。在一個具體例子中，對於用戶以中文輸入的目的地地址“首爾塔”，在步驟23，可以將其轉換為經緯度坐標資料：E126.9882266, N37.5511694。
接著，在步驟24，將車輛資訊和目的地坐標資料發送給車輛管理系統服務端，即出租車管理後台，從而使得管理後台進行伺服器側的轉換和處理。
在一個實施例中，執行上述步驟的客戶端可以由出租車管理系統提供。在另一實施例中，執行上述步驟的客戶端可以由地圖應用程式提供方來提供。在這樣的情況下，該客戶端與地圖應用程式整合在一起，相應地，步驟22和23中對地圖應用程式的呼叫不再是跨平台的呼叫。在又一實施例中，執行上述步驟的客戶端可以由例如支付寶的支付工具提供。在這樣的情況下，該客戶端可以作為支付寶中的一項子應用。在另一實施例中，上述客戶端也可以由獨立的第三方來提供。
不管透過何種方式提供，透過執行上述步驟21-24，乘客終端將車輛資訊和目的地坐標資料發送給出租車管理後台，即車輛管理系統服務端，由其進行進一步處理。圖3顯示根據一個實施例的跨語言地址資訊處理方法的流程圖，該方法在車輛管理系統服務端執行。
如圖3所示，首先，在步驟31，接收來自乘客終端的第二請求，所述第二請求包括車輛資訊和目的地坐標資料。可以理解，上述車輛資訊和目的地坐標資料由乘客終端透過圖2所示的方法獲取並發送。在一個具體例子中，接收到的車輛資訊包括車牌號아561818，目的地坐標資料包括E126.9882266, N37.5511694。
接著，在步驟32，將目的地坐標資料轉換為第二語言（當地語言，例如韓語）的目的地地址。在一個實施例中，車輛管理系統服務端儲存有地圖資料，利用所儲存的地圖資料，可以將目的地坐標轉換為本地語言的地址。在另一實施例中，車輛管理系統將坐標資料轉發給合作的地圖資料提供方，由該提供方將坐標資料轉換為本地語言的地址。
例如，在一個具體例子中，在步驟32，車輛管理系統服務端將接收到的目的地坐標資料E126.9882266, N37.5511694轉換為韓語地址：서울타워。
接下來在步驟33，將第二語言（例如韓語）的目的地地址發送到與車輛資訊對應的車輛終端。於是，出租車司機可以透過車輛終端直接獲取到當地語言的目的地地址。可選地，出租車司機可以直接根據該目的地地址進行導航，運送乘客。
透過這樣的方式，在國外使用出租車的過程中，不需要乘客與出租車司機本人進行跨語言溝通，而是透過車輛終端、乘客終端和車輛管理系統服務端之間的互動，將乘客用一種語言輸入的目的地地址準確地轉換為當地語言，傳達給出租車司機，解決了乘客與當地出租車司機之間的跨語言溝通問題。
進一步地，在出租車司機載著乘客抵達目的地之後，本說明書一個實施例還提供支付車費訂單的方法。該方法在車輛終端、乘客終端、車輛管理系統服務端以及支付服務端之間交互執行，其中，由車輛管理系統服務端執行主要的處理步驟。
圖4顯示根據一個實施例的支付處理方法的流程圖，該方法步驟由車輛管理系統服務端執行。如圖4所示，首先，在步驟41，從車輛終端接收訂單請求。可以理解，在乘客抵達目的地之後，出租車司機可以利用車輛終端進行車費結算，基於結算的車費產生訂單請求，該訂單請求可以由車輛終端發送給車輛管理系統服務端。在另一種實施例中，出租車司機透過車輛終端發出的訂單請求包括行駛里程、等待時間等資訊，車輛管理系統服務端接收到這樣的訂單請求後，對其進行分析處理，結算車費，產生訂單。
在步驟42，車輛管理系統服務端向乘客終端發送訂單資訊。可以理解到，由於在之前圖2和圖3的過程中，乘客終端已經與車輛管理系統服務端進行了互動，相應地，車輛管理系統服務端已經將車輛終端與乘客終端建立了關聯。在接收到來自車輛終端的訂單請求後，就可以定位出該訂單對應的乘客終端，並將訂單資訊發送給乘客終端。該訂單資訊可以包括車費金額，和一些必要的行駛資訊，例如行駛里程、時間等。這些資訊可以用於乘客對本次行程的訂單進行確認。
與此對應地，乘客終端可以從車輛管理系統服務端接收到訂單資訊，並在用戶對該訂單資訊進行確認操作的情況下，向車輛管理系統服務端發送確認訊息。
於是在步驟43，車輛管理系統服務端回應於來自乘客終端的確認訊息，向乘客終端對應的支付服務端發送支付請求。在一個實施例中，乘客終端綁定有對應的支付服務帳號，例如支付寶帳號，於是車輛管理系統服務端就以該支付寶帳號向支付寶伺服器發送支付請求。
進一步地，在一個實施例中，該方法還包括步驟44和步驟45，在步驟44，從上述支付服務端接收支付結果；在步驟45，向車輛終端和乘客終端通知支付結果。
透過以上方式，還進一步解決了使用出租車的支付問題，極大地方便了乘客與出租車公司，提高了各方的用戶體驗。
下面結合圖5和圖6的具體例子，描述跨語言使用出租車的互動過程，其中圖5顯示該例子中的互動流程，圖6顯示乘客終端和車輛終端的介面。
如圖5所示，在用戶搭乘出租車之後，首先在步驟S501，車輛終端顯示二維碼（該二維碼可以是預先產生的，也可以是現場產生的）。圖6中的（a）部分顯示此時車輛終端的介面。可以看到，該車輛終端是帶有顯示螢幕的智慧型終端，可以集計價結算、導航等功能於一體。這樣的車輛終端在許多國家或地區已經被配置到當地的出租車中。
然後在步驟S502，用戶透過客戶端，掃描該二維碼。圖6中的（b）部分顯示此時乘客終端的介面。
接著在步驟S503，客戶端解析、識別二維碼，從中獲取到車輛資訊，包括司機的資訊。如前所述，上述客戶端可以體現為H5頁面或其他形式。
在步驟S504，客戶端呼叫地圖應用程式，透過地圖應用程式提供地址輸入介面。圖6中的（c）部分顯示此時乘客終端的介面。可以看到，在介面中顯示有地圖資訊，以及地址輸入欄。
在步驟S505，地圖應用程式接收用戶輸入的第一語言（例如中文）的目的地地址。
在步驟S506，地圖應用程式對目的地地址進行處理，將其轉換為地理坐標資料。
在步驟S507，客戶端從地圖應用程式獲取到地理坐標資料。
在步驟S508，客戶端將車輛資訊以及地理坐標資料，一同發送給車輛管理系統服務端。
在步驟S509，車輛管理系統服務端對接收到的資料進行處理，將接收到的地理坐標資料，轉換為第二語言（當地語言，例如韓語）的地址。
在步驟S510，車輛管理系統服務端將第二語言的地址發送給車輛終端。
在步驟S511，車輛終端根據第二語言的地址進行導航，抵達目的地。
在抵達目的地之後，即進入結算支付階段。
在該階段中，在步驟S512，車輛終端向車輛管理系統服務端發送訂單請求。
在步驟S513，車輛管理系統服務端對訂單請求進行處理，其中可以包括，核驗車費，確定訂單對應的乘客終端等。
在步驟S514，車輛管理系統服務端向乘客終端中的客戶端發送訂單資訊。
在步驟S515，用戶透過客戶端對訂單資訊進行確認。圖6的（d）部分顯示此時乘客終端的顯示介面，該介面中顯示了本次行程的訂單資訊，以供用戶進行確認。
在步驟S516，客戶端向車輛管理系統服務端發送確認訊息。
在步驟S517，車輛管理系統服務端向支付服務端，例如支付寶伺服器，發送支付請求。
在步驟S518，支付服務端處理支付請求。
在步驟S519，支付服務端向車輛管理系統服務端發送支付結果。
在步驟S520，車輛管理系統服務端向乘客終端中的客戶端發送支付結果通知。
在步驟S521，車輛管理系統服務端向車輛終端通知支付結果。圖6的（e）部分顯示此時車輛終端的顯示介面，該介面顯示從車輛管理系統服務端收到的支付結果。
在步驟S522，車輛終端根據支付結果列印收據。圖6的（f）部分顯示列印的收據的例子。
在以上過程中，透過跨語言的地址資訊處理，克服了乘客與出租車司機的跨語言交流障礙。進一步地，透過自動支付過程，極大地提升了支付的便利性，提升了各方的使用體驗。
根據另一態樣的實施例，還提供一種跨語言使用車輛的處理裝置，該處理裝置位於乘客終端中。圖7顯示根據一個實施例的乘客終端中的處理裝置的示意圖。如圖7所示，該處理裝置700包括：介面提供單元71，配置為回應於用戶的第一請求，提供地址輸入介面，所述第一請求透過識別車輛終端的識別碼而產生，所述識別碼中包含車輛資訊；地址接收單元72，配置為透過所述地址輸入介面，接收用戶輸入的第一語言的目的地地址資訊；坐標確定單元73，配置為確定所述目的地地址資訊對應的目的地坐標資料；坐標發送單元74，配置為將所述車輛資訊和所述目的地坐標資料發送給車輛管理系統服務端。
在一個實施例中，上述車輛的識別碼包括二維碼或者聲波碼。
在一個實施例中，上述處理裝置700還包括識別單元（未顯示），配置為識別所述識別碼，產生所述第一請求。
根據一個實施例，上述處理裝置700還包括顯示單元（未顯示），配置為顯示所述車輛資訊，以供所述用戶確認。
根據一個實施例，上述介面提供單元71具體配置為：呼叫地圖應用程式，由該地圖應用程式提供地址輸入介面，所述地圖應用程式支援所述第一語言的地圖顯示。
進一步地，在一個實施例中，地址接收單元72配置為：接收用戶在地圖應用程式中的定位操作，根據所述定位操作確定所述第一語言的目的地地址。
根據一個實施例，地址接收單元72還可以配置為：接收用戶以第一語言輸入的地址文字；或者，接收用戶的第一語言的語音，將所述語音轉換為第一語言的地址文字。
在一個實施例中，坐標確定單元73具體配置為，從所述地圖應用程式獲取所述目的地坐標資料。
根據一個實施例，上述處理裝置700還包括（未顯示）：訂單接收單元，配置為從所述車輛管理系統服務端接收訂單資訊；訊息發送單元，配置為回應於用戶對所述訂單資訊的確認操作，向所述車輛管理系統服務端發送確認訊息。
根據另一態樣的實施例，還提供一種跨語言使用車輛的處理裝置，該處理裝置位於車輛管理系統服務端中。圖8顯示根據一個實施例的車輛管理系統服務端中的處理裝置的示意圖。如圖8所示，該處理裝置800包括：地址接收單元81，配置為接收來自乘客終端的第二請求，所述第二請求包括車輛資訊和目的地坐標資料；轉換單元82，配置為將所述目的地坐標資料轉換為第二語言的目的地地址；地址發送單元83，配置為將所述第二語言的目的地地址發送到與所述車輛資訊對應的車輛終端。
在一個實施例中，上述處理裝置800還包括（未顯示）：訂單接收單元，配置為從所述車輛終端接收訂單資訊；訂單發送單元，配置為向所述乘客終端發送所述訂單資訊；支付發送單元，配置為回應於來自所述乘客終端的確認訊息，向所述乘客終端對應的支付服務端發送支付請求。
進一步地，在一個實施例中，處理裝置800還包括（未顯示）：支付接收單元，配置為從所述支付服務端接收支付結果；支付通知單元，配置為向所述車輛終端和所述乘客終端通知支付結果。
根據另一態樣的實施例，還提供一種電腦可讀儲存媒體，其上儲存有電腦程式，當所述電腦程式在電腦中執行時，令電腦執行結合圖2到圖4所描述的方法。
根據再一態樣的實施例，還提供一種計算設備，包括記憶體和處理器，所述記憶體中儲存有可執行碼，所述處理器執行所述可執行碼時，實現結合圖2到圖4所述的方法。
本領域技術人員應該可以意識到，在上述一個或多個示例中，本發明所描述的功能可以用硬體、軟體、韌體或它們的任意組合來實現。當使用軟體實現時，可以將這些功能儲存在電腦可讀媒體中或者作為電腦可讀媒體上的一個或多個指令或碼進行傳輸。
以上所述的具體實施方式，對本發明的目的、技術方案和有益效果進行了進一步詳細說明，所應理解的是，以上所述僅為本發明的具體實施方式而已，並不用於限定本發明的保護範圍，凡在本發明的技術方案的基礎之上，所做的任何修改、等同替換、改進等，均應包括在本發明的保護範圍之內。The following describes the solutions provided in this specification in conjunction with the drawings.
FIG. 1 is a schematic diagram of an implementation scenario of an embodiment disclosed in this specification. As shown in FIG. 1, the system of this implementation scenario includes a vehicle terminal 100, a passenger terminal 200, and a vehicle management system server 300. The vehicle terminal 100 is a terminal device on a vehicle (for example, a taxi). An identification code, such as a two-dimensional code, may be generated or assigned to each vehicle terminal 100 in advance, which carries vehicle information of the corresponding vehicle. When a passenger takes a taxi, the passenger uses the passenger terminal 200 to recognize the identification code of the vehicle terminal 100 and learns the vehicle information. After that, the passenger terminal 200 provides an address input interface to the passenger, so the passenger can input the destination address in his own language (first language, for example, Chinese). The passenger terminal 200 converts such a destination address into geographic location coordinates, and sends it to the vehicle management system server 300 together with the vehicle information. After receiving the vehicle information and geographic location coordinates, the vehicle management system server 300 converts the geographic location coordinates into a local language (a second language, such as Korean), and then sends the destination address in the local language to the vehicle corresponding to the vehicle information. Terminal 100. Therefore, the taxi driver can learn the destination address described in the local language through the vehicle terminal 100, so that the passenger can be sent to the destination smoothly. In this way, the language barrier between foreign passengers and local taxi drivers is overcome.
Further, after arriving at the destination, the taxi driver can settle the fare through the vehicle terminal 100, and the settlement request is sent to the passenger terminal 200 through the vehicle management system server 300. When the passenger confirms that the settlement is correct, the vehicle management system server 300 sends a payment request to the payment server corresponding to the passenger terminal 200, and if the payment is successful, notifies the vehicle terminal 100 and the passenger terminal 200 respectively. In this way, convenient payment for passengers and taxi drivers is realized.
The following describes the execution and implementation of each step in the above implementation scenario.
First describe the boarding phase. In this stage, the vehicle terminal, passenger terminal, and the vehicle management system server interact with each other, so that passengers can input the destination address in the first language, and the vehicle terminal finally receives the address form in the second language (local language), realizing the crossover. Language address information processing.
To this end, the taxi needs to be equipped with a vehicle terminal, and the vehicle terminal needs to have a corresponding identification code. In one example, a smart settlement device is installed in the taxi, and the settlement device can be used for functions such as fare settlement, vehicle navigation, etc., and can also interact with the service end of the vehicle management system. In this case, such a smart settlement device can be used as the aforementioned vehicle terminal. In another example, a taxi driver uses a traditional meter for pricing, and at the same time uses a driver client on a mobile phone to perform identity authentication and registration in the taxi management system, interact with the taxi management system, and can also perform navigation. In this case, the meter, the driver client, etc. together constitute the vehicle terminal. In other examples, the vehicle terminal may also have other forms according to the configuration status of the local taxi company.
The identification code can be generated in advance for each vehicle or the corresponding vehicle terminal. The identification code can be a two-dimensional code, or a sonic code, or other encoding forms that can contain vehicle information. For two-dimensional codes, there are already a variety of production tools and production methods. In one embodiment, the vehicle terminal can generate a two-dimensional code offline; or, in another embodiment, the vehicle terminal can generate a two-dimensional code online. In one embodiment, a unique and constant two-dimensional code is generated for each vehicle terminal. Taxi drivers can display such a QR code through the vehicle terminal, or they can print out the QR code and attach it to the vehicle for display. For the sonic code, a sonic code generation tool can be used to generate it, and the corresponding sonic audio can be played through the vehicle terminal to "display" the sonic code.
On the other hand, the passenger terminal can be embodied as a portable smart device, such as a smart phone. In an implementation scenario, the user can take a taxi through various methods, such as online appointment, temporary roadside beckoning to stop the car, etc. At this time, the user becomes a passenger and recognizes the identification code of the taxi he is riding through the passenger terminal, and then triggers the cross-language processing method shown in FIG. The form, generation mode and display mode of the identification code are as described above, and will not be repeated here. In the following description, the two-dimensional code is used as an example for description, but it should be understood that the relevant embodiments can be similarly applied to the sonic code or other similar encoding forms.
Fig. 2 shows a flowchart of a cross-language processing method according to an embodiment, which is executed in a passenger terminal. More specifically, the execution subject of the method may be a passenger client in a passenger terminal, and the client may be embodied as a dedicated App, or just a page, such as an H5 page. As shown in FIG. 2, the method executed by the passenger client includes: step 21, in response to a first request of the user, an address input interface is provided, and the first request is generated by identifying the identification code of the vehicle terminal. Including vehicle information; step 22, receiving the destination address information in the first language input by the user through the address input interface; step 23, determining the destination coordinate data corresponding to the destination address information; step 24, adding the The vehicle information and the destination coordinate data are sent to the server of the vehicle management system. The following describes the execution process of each of the above steps.
In one embodiment, before step 21, after taking a taxi, the user opens the passenger client terminal (such as a dedicated App, or a web page), and uses the client terminal to scan and recognize the QR code of the taxi vehicle terminal, namely Go to step 20. In step 20, the above-mentioned client triggers a request while successfully recognizing the two-dimensional code corresponding to the vehicle terminal, which is hereinafter referred to as the first request. The first request is used to request an address input interface.
In another embodiment, after taking a taxi, the user uses a third-party tool installed in the passenger terminal, such as Alipay, kakao TALK (a social app commonly used in South Korea), to scan and recognize the two-dimensional code of the taxi. In this case, in addition to the vehicle information, the QR code also needs to carry the link information of the passenger client used to execute the method in FIG. 2. For example, the above-mentioned passenger client is embodied as an H5 page, so in addition to the vehicle information, the QR code displayed by the vehicle terminal also needs to carry the URL (Uniform Resource Locator) that points to the H5 page. In this way, after Alipay scans the QR code and parses the string corresponding to the QR code, it will identify the url in it, and redirect to the target page according to the url, that is, the H5 page of the passenger client mentioned above. During the redirection process, Alipay sends a request (also referred to as the first request) to the above-mentioned passenger client, such as the H5 page, which contains the identified vehicle information, and requests the H5 page to provide an address input interface.
Then, the following steps 21 to 24 are executed by the above-mentioned passenger client. In step 21, in response to the above-mentioned first request, an address input interface is provided. As mentioned above, the above-mentioned first request is generated by recognizing the identification code of the vehicle terminal; more specifically, it can be generated by scanning and recognizing the QR code by the client tool, or by a third-party tool such as Alipay. , And then re-directed to produce.
In response to such a request, in step 21, an address input interface is provided. In one embodiment, the address input interface is provided by calling a third-party map application. It can be understood that the called map application supports map display in the first language (for example, Chinese) used by the above-mentioned user/passenger. In another embodiment, the above-mentioned dedicated passenger client provides an independent address input interface.
In one embodiment, before the address input interface is provided, the scanned vehicle information is displayed to the user for confirmation by the user (passenger). After getting the user's confirmation, the address input interface is provided, and the address input interface is displayed. The vehicle information identified by scanning the identification code may include the license plate number of the vehicle, the taxi company to which it belongs, operation status, and driver information corresponding to the vehicle, and so on.
After the address input interface is provided to the user, in step 22, the destination address information in the first language input by the user is received through the address input interface. Specifically, the user can input his destination address in a language familiar to the user (the first language, for example, Chinese) through the aforementioned address input interface in a variety of ways. For example, the address input interface can be embodied as an address input box, and the user can input the address text of the destination address in the first language in the input box, such as "Seoul Tower". The address input interface can also provide a voice input mode, receive the user's voice in the first language, and convert the voice into the address text in the first language. In one embodiment, the address input interface is provided by calling a map application. At this time, the user can perform positioning operations such as zooming in, zooming out, and dragging on the map to select a destination on the map. The map application determines the destination address in the first language according to the user's positioning operation.
After receiving the destination address in the first language through the address input interface, in step 23, the geographic coordinate data corresponding to the destination address, such as latitude and longitude data, is determined. In one embodiment, the client terminal stores map data locally, and uses such map data to convert the destination address into geographic coordinate data. In another embodiment, the above-mentioned client calls a third-party map application to obtain the destination address. In this case, the map application program can convert the destination address input by the user into geographic coordinate data, and the client terminal obtains the geographic coordinate data from the map application program. In a specific example, for the destination address "Seoul Tower" input by the user in Chinese, in step 23, it can be converted into latitude and longitude coordinate data: E126.9882266, N37.5511694.
Next, in step 24, the vehicle information and destination coordinate data are sent to the vehicle management system server, that is, the taxi management background, so that the management background performs server-side conversion and processing.
In an embodiment, the client that performs the above steps may be provided by a taxi management system. In another embodiment, the client that executes the above steps may be provided by the map application provider. In this case, the client is integrated with the map application. Correspondingly, the calls to the map application in steps 22 and 23 are no longer cross-platform calls. In another embodiment, the client that executes the above steps may be provided by a payment tool such as Alipay. In this case, the client can be used as a sub-application of Alipay. In another embodiment, the above-mentioned client may also be provided by an independent third party.
No matter what method is provided, by performing the above steps 21-24, the passenger terminal sends the vehicle information and destination coordinate data to the taxi management backend, that is, the vehicle management system server for further processing. FIG. 3 shows a flowchart of a method for processing cross-language address information according to an embodiment, which is executed on the server side of the vehicle management system.
As shown in FIG. 3, first, in step 31, a second request from the passenger terminal is received, and the second request includes vehicle information and destination coordinate data. It can be understood that the aforementioned vehicle information and destination coordinate data are acquired and sent by the passenger terminal through the method shown in FIG. 2. In a specific example, the received vehicle information includes the license plate number 561818, and the destination coordinate data includes E126.9882266, N37.5511694.
Next, in step 32, the destination coordinate data is converted into a destination address in a second language (local language, for example, Korean). In one embodiment, the vehicle management system server stores map data, and using the stored map data, the destination coordinates can be converted into a local language address. In another embodiment, the vehicle management system forwards the coordinate data to a cooperative map data provider, and the provider converts the coordinate data into a local language address.
For example, in a specific example, in step 32, the vehicle management system server converts the received destination coordinate data E126.9882266, N37.5511694 into a Korean address: 서울타워.
Next, in step 33, the destination address in the second language (for example, Korean) is sent to the vehicle terminal corresponding to the vehicle information. Therefore, the taxi driver can directly obtain the destination address in the local language through the vehicle terminal. Optionally, the taxi driver can directly navigate according to the destination address to transport passengers.
In this way, in the process of using taxis abroad, there is no need for passengers to communicate with the taxi driver himself across languages. Instead, the interaction between the vehicle terminal, the passenger terminal, and the service end of the vehicle management system is used to use the passengers. The destination address entered in one language is accurately converted into the local language and communicated to the taxi driver, which solves the problem of cross-language communication between the passenger and the local taxi driver.
Further, after the taxi driver arrives at the destination with passengers, an embodiment of this specification also provides a method for paying the fare order. The method is executed interactively among the vehicle terminal, the passenger terminal, the vehicle management system server, and the payment server, wherein the vehicle management system server performs the main processing steps.
Fig. 4 shows a flowchart of a payment processing method according to an embodiment, and the method steps are executed by the vehicle management system server. As shown in Fig. 4, first, in step 41, an order request is received from the vehicle terminal. It can be understood that after the passenger arrives at the destination, the taxi driver can use the vehicle terminal to settle the fare and generate an order request based on the settled fare. The order request may be sent by the vehicle terminal to the vehicle management system server. In another embodiment, the order request sent by the taxi driver through the vehicle terminal includes information such as mileage, waiting time, etc. After receiving such an order request, the vehicle management system server analyzes and processes it, settles the fare, and generates Order.
In step 42, the vehicle management system server sends the order information to the passenger terminal. It can be understood that, since the passenger terminal has interacted with the vehicle management system server in the previous process of FIGS. 2 and 3, the vehicle management system server has associated the vehicle terminal with the passenger terminal accordingly. After receiving the order request from the vehicle terminal, the passenger terminal corresponding to the order can be located, and the order information can be sent to the passenger terminal. The order information may include the amount of the fare, and some necessary driving information, such as mileage, time, etc. This information can be used by passengers to confirm the order for this trip.
Correspondingly, the passenger terminal can receive the order information from the vehicle management system server, and when the user confirms the order information, send a confirmation message to the vehicle management system server.
Therefore, in step 43, the vehicle management system server responds to the confirmation message from the passenger terminal and sends a payment request to the payment server corresponding to the passenger terminal. In one embodiment, the passenger terminal is bound with a corresponding payment service account, such as an Alipay account, so the vehicle management system server uses the Alipay account to send a payment request to the Alipay server.
Further, in one embodiment, the method further includes steps 44 and 45. In step 44, the payment result is received from the payment server; in step 45, the vehicle terminal and the passenger terminal are notified of the payment result.
Through the above methods, the payment problem of using taxis is further solved, which greatly facilitates passengers and taxi companies, and improves the user experience of all parties.
The following describes the interactive process of using taxis across languages in conjunction with the specific examples shown in Figures 5 and 6, where Figure 5 shows the interactive process in this example, and Figure 6 shows the interface between the passenger terminal and the vehicle terminal.
As shown in FIG. 5, after the user takes a taxi, first, in step S501, the vehicle terminal displays a two-dimensional code (the two-dimensional code may be generated in advance or generated on site). Part (a) in Figure 6 shows the interface of the vehicle terminal at this time. It can be seen that the vehicle terminal is a smart terminal with a display screen, which can integrate functions such as pricing, settlement, and navigation. Such vehicle terminals have been deployed in local taxis in many countries or regions.
Then in step S502, the user scans the QR code through the client. Part (b) in Figure 6 shows the interface of the passenger terminal at this time.
Then in step S503, the client parses and recognizes the two-dimensional code, and obtains vehicle information, including driver information, from it. As mentioned earlier, the above client can be embodied as an H5 page or other forms.
In step S504, the client terminal calls the map application, and provides an address input interface through the map application. Part (c) in Figure 6 shows the interface of the passenger terminal at this time. As you can see, there are map information and address input fields displayed in the interface.
In step S505, the map application receives the destination address in the first language (for example, Chinese) input by the user.
In step S506, the map application program processes the destination address and converts it into geographic coordinate data.
In step S507, the client terminal obtains geographic coordinate data from the map application.
In step S508, the client terminal sends the vehicle information and geographic coordinate data to the vehicle management system server together.
In step S509, the vehicle management system server processes the received data, and converts the received geographic coordinate data into an address in a second language (local language, such as Korean).
In step S510, the vehicle management system server sends the address in the second language to the vehicle terminal.
In step S511, the vehicle terminal navigates to the destination according to the address in the second language.
After arriving at the destination, it enters the settlement and payment stage.
In this stage, in step S512, the vehicle terminal sends an order request to the vehicle management system server.
In step S513, the vehicle management system server processes the order request, which may include checking the fare, determining the passenger terminal corresponding to the order, and so on.
In step S514, the vehicle management system server sends the order information to the client in the passenger terminal.
In step S515, the user confirms the order information through the client. Part (d) of Figure 6 shows the display interface of the passenger terminal at this time. The interface displays the order information of this trip for the user to confirm.
In step S516, the client sends a confirmation message to the vehicle management system server.
In step S517, the vehicle management system server sends a payment request to the payment server, such as the Alipay server.
In step S518, the payment server processes the payment request.
In step S519, the payment server sends the payment result to the vehicle management system server.
In step S520, the vehicle management system server sends a payment result notification to the client in the passenger terminal.
In step S521, the vehicle management system server notifies the vehicle terminal of the payment result. Part (e) of Figure 6 shows the display interface of the vehicle terminal at this time, which displays the payment result received from the vehicle management system server.
In step S522, the vehicle terminal prints a receipt according to the payment result. Part (f) of Figure 6 shows an example of a printed receipt.
In the above process, the cross-language communication barriers between passengers and taxi drivers were overcome through cross-language address information processing. Furthermore, through the automatic payment process, the convenience of payment is greatly improved, and the user experience of all parties is improved.
According to another aspect of the embodiment, there is also provided a processing device for using a vehicle across languages, the processing device being located in a passenger terminal. Fig. 7 shows a schematic diagram of a processing device in a passenger terminal according to an embodiment. As shown in FIG. 7, the processing device 700 includes: an interface providing unit 71 configured to provide an address input interface in response to a first request of a user, the first request being generated by identifying the identification code of the vehicle terminal, the identification The code contains vehicle information; the address receiving unit 72 is configured to receive the destination address information in the first language input by the user through the address input interface; the coordinate determining unit 73 is configured to determine the destination corresponding to the destination address information Ground coordinate data; the coordinate sending unit 74 is configured to send the vehicle information and the destination coordinate data to the vehicle management system server.
In an embodiment, the identification code of the above-mentioned vehicle includes a two-dimensional code or a sonic code.
In an embodiment, the above-mentioned processing device 700 further includes an identification unit (not shown) configured to identify the identification code and generate the first request.
According to one embodiment, the above-mentioned processing device 700 further includes a display unit (not shown) configured to display the vehicle information for the user to confirm.
According to one embodiment, the interface providing unit 71 is specifically configured to call a map application program, the map application program provides an address input interface, and the map application program supports map display in the first language.
Further, in an embodiment, the address receiving unit 72 is configured to receive a user's positioning operation in a map application, and determine the destination address in the first language according to the positioning operation.
According to an embodiment, the address receiving unit 72 may also be configured to: receive the address text input by the user in the first language; or, receive the user's voice in the first language, and convert the voice into the address text in the first language.
In one embodiment, the coordinate determining unit 73 is specifically configured to obtain the destination coordinate data from the map application.
According to one embodiment, the processing device 700 further includes (not shown): an order receiving unit configured to receive order information from the vehicle management system server; a message sending unit configured to respond to a user's confirmation of the order information Operation, sending a confirmation message to the vehicle management system server.
According to another aspect of the embodiment, there is also provided a processing device for cross-language use of vehicles, and the processing device is located in the server of the vehicle management system. Fig. 8 shows a schematic diagram of a processing device in a server of a vehicle management system according to an embodiment. As shown in FIG. 8, the processing device 800 includes: an address receiving unit 81 configured to receive a second request from the passenger terminal, the second request including vehicle information and destination coordinate data; a conversion unit 82, configured to The destination coordinate data is converted into a destination address in a second language; the address sending unit 83 is configured to send the destination address in the second language to a vehicle terminal corresponding to the vehicle information.
In one embodiment, the processing device 800 further includes (not shown): an order receiving unit configured to receive order information from the vehicle terminal; an order sending unit configured to send the order information to the passenger terminal; and payment The sending unit is configured to send a payment request to the payment server corresponding to the passenger terminal in response to the confirmation message from the passenger terminal.
Further, in one embodiment, the processing device 800 further includes (not shown): a payment receiving unit configured to receive a payment result from the payment server; a payment notification unit configured to send a notification to the vehicle terminal and the passenger The terminal notifies the payment result.
According to another aspect of the embodiment, there is also provided a computer-readable storage medium on which a computer program is stored. When the computer program is executed in the computer, the computer is caused to execute the method described in conjunction with FIGS. 2 to 4.
According to yet another aspect of the embodiment, there is also provided a computing device, including a memory and a processor, the memory stores executable code, and when the processor executes the executable code, the implementation of combining FIGS. 2 to The method described in Figure 4.
Those skilled in the art should be aware that in one or more of the above examples, the functions described in the present invention can be implemented by hardware, software, firmware, or any combination thereof. When implemented by software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on the computer-readable medium.
The specific embodiments described above further describe the purpose, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above are only specific embodiments of the present invention, and are not intended to limit the scope of the present invention. The protection scope, any modification, equivalent replacement, improvement, etc. made on the basis of the technical solution of the present invention shall be included in the protection scope of the present invention.