專利名稱：免提系統(tǒng)的通話確認方法
技術領域：
本發(fā)明涉及一種免提系統(tǒng)的通話確認方法，例如用戶不實際地將便攜電話等便攜 設備拿在手中，就能夠經(jīng)由另外準備的通話機器進行免提通話。
背景技術：
以外，例如作為車輛中搭載的類型的免提系統(tǒng)，已知將便攜電話與車載單元進行 有線連接的類型的現(xiàn)有技術(例如參照專利文獻1)。該現(xiàn)有技術為，在將車載單元(系統(tǒng) 的主體)與便攜電話進行有線連接了的狀態(tài)下進行使用，由此通過在其主體內(nèi)置的揚聲器 和麥克風實現(xiàn)與對方目的地(遠端)的免提通話。并且，在該現(xiàn)有技術中，在系統(tǒng)的主體上 分別具備“通話開始”鍵以及“通話結(jié)束”鍵，由此當在來電時用戶操作“通話開始”鍵時，能 夠開始便攜電話的通話，并且當在通話中用戶操作“通話結(jié)束”鍵時，能夠結(jié)束便攜電話的 通話。除上述現(xiàn)有技術以外，還已知與將便攜電話與車載單元進行無線連接的類型的免 提系統(tǒng)有關的現(xiàn)有技術(例如參照專利文獻2)。該現(xiàn)有技術為，使用Bluet00th(注冊商 標)規(guī)格的近距離無線通信，將便攜電話與車載單元進行連接。因此，用戶將便攜電話帶入 車內(nèi)就能夠?qū)崿F(xiàn)免提通話，對于用戶來說也相應地使用方便性良好。以上舉出的現(xiàn)有技術(專利文獻1)，在系統(tǒng)主體與便攜電話的連接中使用有線方 式，因此噪聲的影響較少、相互的通信穩(wěn)定。但是，如果不是線纜或連接器等連接接口適合 的機器之間，則不能構(gòu)建免提系統(tǒng)，因此受到硬件上的制約的情況為難點。這一點，在如后 者的現(xiàn)有技術(專利文獻幻那樣利用通用的近距離無線通信進行連接的情況下，只要以其 通信規(guī)格為基準的通信模塊搭載到車載單元和便攜電話的雙方，就能夠比較容易地構(gòu)建免 提系統(tǒng)。因此，可以認為今后使用了近距離無線通信的無線連接將成為免提系統(tǒng)的主流。專利文獻1 日本特開2001-309008號公報(第4_第5頁、圖1、圖2)專利文獻2 日本專利第3卯4948號公報但是，在免提系統(tǒng)中利用通用的近距離無線通信(例如Bluetooth (注冊商標)) 的情況下，如果各器件不忠實地執(zhí)行以該通信規(guī)格為基準的動作，則還必須留意由此在作 為系統(tǒng)整體的動作中成為故障的情況。例如，在免提通話的執(zhí)行中便攜電話結(jié)束了與對方目的地(遠端)的通話的情況 下，在通過規(guī)格的標準上要求將該“通話結(jié)束(終話)”可靠地對車載單元(例如車載音頻 裝置)進行通知。這是因為，將未直接與電話線路連接的車載單元暫時從“通話中”的狀態(tài) 解除，并能夠進行之后的動作。假設，當在便攜電話中實際通話結(jié)束之后也不對車載單元通 知“通話結(jié)束”時，車載單元一直持續(xù)識別為“通話中”，因此下次從外部(遠端)具有電話 來電也不受理來電本身，或者限制其他動作(例如音樂的再生、收音機播放的輸出等)。當然，與通用近距離無線通信相對應的大多數(shù)器件(通信模塊)，被設計為以該通 信規(guī)格為基準而期待正常地進行動作。但是，在通信規(guī)格所規(guī)定的標準上的要求分為多支 的情況下，不能夠忽視實際上還存在不滿足一部分要求的器件(例如特定機型或型號的便攜電話)，且這些器件在世界市場上流通較多的事實。因此，當過于相信所有的器件一直滿 足通信規(guī)格的標準而簡單地構(gòu)建免提系統(tǒng)時，根據(jù)情況不同系統(tǒng)的動作不穩(wěn)定，結(jié)果會存 在損害用戶的方便性的使用上的問題。

發(fā)明內(nèi)容
因此，本發(fā)明要解決的課題為，提供一種技術，在假定了能夠使用不滿足通信規(guī)格 的標準的一部分的器件的可能性的基礎上，能夠?qū)崿F(xiàn)通用性更高的免提系統(tǒng)的構(gòu)建。為了解決上述課題，本發(fā)明采用以下的解決手段。解決手段1 本發(fā)明假定構(gòu)建便攜設備與通話機器的免提系統(tǒng)的情況。便攜設備 能夠與電話線路連接，通話機器為通過與便攜設備之間進行相互通信，能夠使用便攜設備 以外的其他設備進行通過電話線路的免提通話。當便攜設備為具有內(nèi)置揚聲器和麥克風等 的便攜電話時，通話機器相當于作為其他設備具有揚聲器和麥克風的免提用的單元。便攜 設備和通話機器，如果分別搭載了以通用的通信規(guī)格為基準的器件(通信模塊)，則僅使二 者接近到能夠通信的距離就能夠容易地構(gòu)建免提系統(tǒng)。所構(gòu)建的系統(tǒng)，實際上通過便攜設備的資源來具有經(jīng)由電話線路確立與對方目的 地(遠端)的連接的功能，但在免提通話中的聲音的交換(發(fā)話、受話)，由通話機器進行媒 介。此時，在基本確立了便攜設備與電話線路的連接的期間，通話機器為了實現(xiàn)免提通話而 需要確保自己的資源。另一方面，在用戶(近端)結(jié)束了與對方目的地(遠端)的通話的 情況下，便攜設備本身結(jié)束與電話線路的連接，隨之還向通話機器通知通話的結(jié)束，并需要 將系統(tǒng)整體從免提通話的狀態(tài)暫時解除。通常，在系統(tǒng)中利用通用近距離無線通信規(guī)格的情況下，作為原則在標準上要求， 從便攜設備向通話機器自發(fā)地通知通話的結(jié)束。因此，如果各器件按照通信規(guī)格的標準正 確地動作，則隨著電話的結(jié)束，作為系統(tǒng)整體能夠自動地確認免提通話的結(jié)束。但是，在其 中存在不滿足一部分標準的器件的情況下，難以對上述那樣作為系統(tǒng)整體而進行通話的確 認。本發(fā)明為用于在上述的情況下使系統(tǒng)的通話狀態(tài)穩(wěn)定并進行確認(把握)的通話 確認方法，具有以下工序。(1)提問工序在該工序中，由通話機器對便攜設備詢問關于與電話線路的連接的動作狀態(tài)。另 外，在由通話機器向便攜設備的詢問中，例如能夠使用以通用通信規(guī)格為基準的通信構(gòu)件。(2)確認工序在該工序中，基于來自便攜設備的對于之前的詢問的應答結(jié)果，利用通話機器確 認免提系統(tǒng)的通話的狀態(tài)。另外，由便攜設備向通話機器的應答，也例如能夠使用以通用通 信規(guī)格為基準的通信構(gòu)件。根據(jù)本發(fā)明的通話確認方法，通過在(1)的提問工序中進行向便攜設備的詢問， 能夠使其對通話機器應答在該時刻關于與電話線路的連接的動作狀態(tài)。此處所謂的“關于 與電話線路的連接的動作狀態(tài)”中，不僅簡單地包括“連接”還是“非連接”的狀態(tài)，還包括 “待機中”、“通話中”或“非通話中(通話結(jié)束)”這種作為電話機的服務動作狀態(tài)，此外更細 地包括“通話中”、“三者通話保留中”、“發(fā)送中”、“發(fā)出呼叫中”、“來電中”和“來電保留中”等實際打電話時的通話狀態(tài)。因此，在O)的確認工序中，基于來自便攜設備的應答結(jié)果來識別當前的狀態(tài)，之 后能夠正確地確認作為系統(tǒng)整體的通話狀態(tài)為哪種狀態(tài)。例如，如果已經(jīng)具有來自通話機 器的為“通話結(jié)束(終話)，，的狀態(tài)的含義的應答，則由此能夠確認在通話機器中作為系統(tǒng) 整體應為免提通話結(jié)束的狀態(tài)。另一方面，如果已經(jīng)具有來自通話機器的為“通話中”、“三 者通話保留中”、“發(fā)送中”、“發(fā)出呼叫中”、“來電中”和“來電保留中”等的任意一個狀態(tài)的 含義的應答，則由此能夠確認在通話機器中作為系統(tǒng)整體應為繼續(xù)免提通話的狀態(tài)。由此， 能夠使作為系統(tǒng)整體的動作一直穩(wěn)定化而保證正常的動作。解決手段2 在上述⑴的提問工序中，優(yōu)選以便攜設備與通話機器之間的聲音鏈 接切斷的情況為契機，由通話機器對便攜設備進行使用電話線路的通話是否結(jié)束的詢問。在系統(tǒng)中使用近距離無線通信的情況下，在免提通話的開始時確立聲音鏈接(例 如SCO鏈接)。聲音鏈接為在與對方目的地(遠端)的通話時確立其連接，但是在便攜設 備中當產(chǎn)生“通話結(jié)束”時，被切斷。此時，便攜設備即使不自發(fā)地對通話機器通知“通話結(jié) 束”，通過以聲音鏈接被切斷為契機而進行上述的詢問，由此根據(jù)其應答結(jié)果也能夠確認是 否發(fā)生了“通話結(jié)束”。解決手段3 或者在上述⑴的提問工序中，也可以以便攜設備與通話機器之間的 聲音鏈接切斷的情況為契機，由通話機器對便攜設備進行使用電話線路的通話處于哪種狀 態(tài)的詢問。在該情況下，同樣聲音鏈接在與對方目的地(遠端)的通話中維持其連接，但是當 在便攜設備中當產(chǎn)生“通話結(jié)束”時，被切斷。此時，便攜設備即使不自發(fā)地對通話機器通 知“通話結(jié)束”，通過以聲音鏈接被切斷為契機而進行上述的詢問，由此根據(jù)其應答結(jié)果也 能夠確認“通話的狀態(tài)”。另外，該情況下的詢問為“通話處于哪種狀態(tài)”，因此除了那個確認 上述的“通話中”、“三者通話保留中”、“發(fā)送中”、“發(fā)出呼叫中”、“來電中”和“來電保留中” 等較詳細的通話狀態(tài)之外，還能夠確認已經(jīng)為“通話結(jié)束”的狀態(tài)的情況。并且，聲音鏈接的切斷，如上所述那樣在與對方目的地(遠端)的通話結(jié)束了的情 況下發(fā)生，但是即使便攜設備還處于通話中，在使用了通話機器的設備的免提通話結(jié)束的 情況下，也可能發(fā)生。例如，此外在用戶通過免提進行與對方目的地(遠端)的通話時，在 從某個時刻起手持便攜設備開始通話的情況下，到此為此確立的聲音鏈接被切斷。此時，還 是便攜設備即使不自發(fā)地對通話機器通知“通話結(jié)束”，通過以聲音鏈接被切斷為契機而進 行上述的詢問，由此根據(jù)其應答結(jié)果也能夠確認“通話處于哪種狀態(tài)”。解決手段4 在上述解決手段3中，對于提問工序中的詢問，在具有來自便攜設備 的通話還未結(jié)束的內(nèi)容的應答的情況下，之后到具有來自便攜設備的通話結(jié)束了的內(nèi)容的 應答之前，也可以隔開規(guī)定的等待時間而重復提問工序中的詢問。另外，“等待時間”也可以 不一直是一定的時間，例如能夠在每次重復詢問時縮短、或延長。此時，通過每隔等待時間地進行詢問，能夠定期或者不定期地確認包含通話的結(jié) 束的通話狀態(tài)。因此，在詢問時如果還為通話中，則能夠確認其含義，如果通話已經(jīng)結(jié)束，則 能夠可靠地確認其含義。解決手段5 并且本發(fā)明的通話確認方法也可以為，在解決手段1中，在其提問工 序中，以便攜設備與通話機器之間的聲音鏈接切斷的情況為契機，從通話機器對便攜設備進行使用電話線路的通話是否結(jié)束的第一詢問，結(jié)果，在沒有來自便攜設備的通話結(jié)束了 的內(nèi)容的應答的情況下，從通話機器對便攜設備進行使用電話線路的通話處于哪種狀態(tài)的 第二詢問。根據(jù)上述方式，首先如果根據(jù)第一詢問的結(jié)果確認了“通話結(jié)束”，則由此首先作 為系統(tǒng)的通話的狀態(tài)成為能夠確認，因此之后不需要進行第二詢問。對此，在對于第一詢問 還沒有“通話結(jié)束”的應答的情況下，通過第二詢問能夠確認之后的“通話的狀態(tài)”。由此， 如果在第一詢問后通話還實際地繼續(xù)，則能夠確認其狀態(tài)為上述的“通話中”、“三者通話保 留中”、“發(fā)送中”、“發(fā)出呼叫中，，、“來電中”和“來電保留中”等的某一個，如果通話已經(jīng)結(jié) 束，則能夠確認為“通話結(jié)束“的狀態(tài)。解決手段6 并且，在解決手段5中還能夠為，對于上述提問工序中的第二詢問，在 具有來自便攜設備的通話還未結(jié)束的內(nèi)容的應答的情況下，之后到具有來自便攜設備的通 話結(jié)束的內(nèi)容的應答之前，隔開規(guī)定的等待時間重復提問工序中的詢問。S卩，在對于第一詢問具有來自便攜設備的“通話中(通話未結(jié)束)”的應答，對于之 后的第二詢問具有某個“通話中的狀態(tài)”的應答的情況下，之后每隔等待時間到具有“通話 結(jié)束”的應答之前重復進行詢問，由此最終能夠可靠地確認“通話結(jié)束”。另外，本發(fā)明也可以為免提系統(tǒng)，具備上述的便攜設備和通話機器，使用該便攜設 備和通話機器執(zhí)行解決手段1至6的通話確認方法。發(fā)明的效果根據(jù)本發(fā)明的免提系統(tǒng)的通話確認方法，能夠有效地活用通用的通信規(guī)格，并能 夠防止由器件的不完備引起的系統(tǒng)的故障而實現(xiàn)穩(wěn)定的免提通話。并且，能夠不依存于器件的個體(機型或型號等)而穩(wěn)定地構(gòu)建免提系統(tǒng)，因此能 夠保證作為通用性高的免提系統(tǒng)的動作。


圖1是概略地表示執(zhí)行一個實施方式的通話確認方法的免提系統(tǒng)的構(gòu)成例的圖。圖2是表示在車載電氣部件單元與便攜電話之間各器件正常地進行BT通信的情 況的流程的時序圖。圖3是表示通話確認方法的第一模式的時序圖。圖4是表示通話確認方法的第二模式的時序圖。圖5是表示通話確認方法的第三模式的時序圖。圖6是表示通話確認方法的第四、第五模式的時序圖。圖7是表示BT模塊作為控制程序而執(zhí)行的通話確認處理的順序例。符號說明10免提系統(tǒng)12車載電氣部件單元14固定電話16基立占18 便攜電話(BTAG)24揚聲器
洸麥克風28控制部28a 主 CPU30BT 模塊
具體實施例方式以下，參照

本發(fā)明的實施方式。圖1是概略地表示執(zhí)行一個實施方式的通話確認方法的免提系統(tǒng)10的構(gòu)成例的 圖。該免提系統(tǒng)10構(gòu)成為，例如將汽車所搭載的車載電氣部件單元12作為免提通話機器， 將帶入車內(nèi)的便攜電話18作為便攜設備。這些車載電氣部件單元12和便攜電話18都具 有以藍牙(Bluetooth:注冊商標)規(guī)格為基準的無線通信功能。另外，在以下說明中，將 Bluetooth (注冊商標)簡稱為“BT”。車載電氣部件單元12為，例如除了具有行駛路線引導(導航)功能之外，還具有 音頻再生功能、視頻再生功能、收音機和電視等的接收功能等。因此，在該車載電氣部件單 元12中，除了附屬具有使用液晶顯示器等的顯示部20、未圖示的按下開關、鍵開關、旋轉(zhuǎn)把 手等的操作部22之外，還附屬音響輸出用的揚聲器M、集音用的麥克風沈等周邊設備。并且，車載電氣部件單元12，除了內(nèi)置有控制上述周邊設備的控制部觀之外，為 了發(fā)揮BT的無線通信功能還內(nèi)置有BT模塊30。另外，控制部觀是微型計算機，其除了內(nèi) 置作為中央處理裝置的主CPU28a之外，還具備未圖示的ROM、RAM等存儲器器件。因此，BT 模塊30能夠?qū)④囕d電氣部件單元12(主CPU28a)作為主機而提供使用了 BT通信的服務 (例如ACL鏈接、SCO鏈接等無線連接)。便攜電話18是能夠使用無線通信(例如CDMA服務)與電話線路連接的便攜設備。 便攜電話18首先通過無線通信與基站16連接，并從此通過有線的電話線路例如能夠與對 方目的地(遠端)的固定電話14進行通話。另外，在此，作為對方目的地(遠端)舉出固 定電話14作為例子，但是對方目的地(遠端)也可以是其他的便攜電話。無論如何，在便 攜電話18中也內(nèi)置有未圖示的BT模塊，使用該BT模塊而便攜電話18能夠利用基于BT的 無線通信功能。免提系統(tǒng)10能夠在通過無線連接使便攜電話18與車載電氣部件單元12成為聲 音鏈接(SCO鏈接)的狀態(tài)下，提供所謂“免提通話”功能。免提通話為，例如作為車輛的成 員的用戶(駕駛者HI、乘客H2等)不手持便攜電話18，通過車載的揚聲器M、麥克風沈?qū)?現(xiàn)與固定電話14的用戶H3的通話。此外，免提系統(tǒng)10，例如在使便攜電話18與車載電氣部件單元12無線連接的狀態(tài) 下，能夠提供將便攜電話18所示存儲的音頻數(shù)據(jù)一邊傳送給車載電氣部件單元12—邊實 時再生，并從其揚聲器M輸出音樂的功能。或者，能夠提供將便攜電話18所存儲的地址簿 的數(shù)據(jù)傳送給車載電氣部件單元12，并將其輸出到顯示部20上的功能。免提系統(tǒng)10還能 夠活用所傳送的地址簿的數(shù)據(jù)而進行電話發(fā)送，或在從登記到登記地址簿的對方的來電時 進行來電者顯示。[BT模塊的構(gòu)成]在此不特別地圖示，BT模塊30例如在車載電氣部件單元12內(nèi)與BT天線和天線匹配電路連接，通過該BT天線和天線匹配電路，能夠在與其他BT機器(此處為便攜電話 18)之間進行基于BT規(guī)格的無線通信。另外，BT天線和天線匹配電路也可以內(nèi)置于BT模 塊30。并且，BT模塊30為，作為通信電路具有RF處理部、基帶處理部以及收發(fā)處理部。 其中，RF處理部通過BT天線和天線匹配電路進行RF信號(例如2. 4GHz帶)的接收處理。 并且，基帶處理部將由RF處理部接收的信號轉(zhuǎn)換為IF信號，并解調(diào)而生成包數(shù)據(jù)(接收 包)。收發(fā)處理部將由基帶處理部生成的接收包數(shù)據(jù)朝向上位層進行重新構(gòu)建，或者相反地 將在上位層生成的發(fā)送用包數(shù)據(jù)(發(fā)送幀)提供給基帶處理部。發(fā)送用包數(shù)據(jù)由基帶處理 部調(diào)制，通過RF處理部、天線匹配電路以及BT天線而發(fā)送到便攜電話18。此外，BT模塊30內(nèi)置有主接口，該主接口對上述車載電氣部件單元12具有的控 制部觀(主CPU28a)和BT模塊30之間的通信進行控制。即，主接口例如對將通過免提通 話接收的聲音通話數(shù)據(jù)(將由便攜電話18接收的通話聲音進行包數(shù)據(jù)化的數(shù)據(jù))輸出給 主機側(cè)的控制部觀，或從控制部觀接受由麥克風沈收集的聲音通話數(shù)據(jù)(將駕駛者HI、 乘客H2的聲音進行了數(shù)據(jù)化的數(shù)據(jù))時的通信進行控制。接收的聲音通話數(shù)據(jù)，在車載電氣部件單元12內(nèi)轉(zhuǎn)換為模擬信號(電壓)，通過 未圖示的放大器輸出到揚聲器對。并且，由麥克風26收集的聲音通話數(shù)據(jù)，通過BT通信 (SCO鏈接)從BT模塊30包發(fā)送到便攜電話18。由此，例如能夠?qū)谋銛y電話18通過BT 通信接收的聲音通話數(shù)據(jù)從揚聲器M輸出，或者相反地將由麥克風26收集的聲音傳送給 便攜電話18。[通話確認方法]下面，對在本實施方式的免提系統(tǒng)10中執(zhí)行的通話確認方法的一個例子進行說明。[器件正常時]圖2是表示在車載電氣部件單元12與便攜電話18之間各器件正常地進行BT通信 的情況的流程的時序圖。圖2中，位于左側(cè)的2列表示基于車載電氣部件單元12的處理， 位于右側(cè)的1列表示基于便攜電話18的處理。另外，在以下的說明中，將車載電氣部件單 元12分為主CPU28a和BT模塊30來進行說明。并且，對于便攜電話18，一般化地稱呼為 "BT音頻通道(BTAG) ”。[BT 連接]STl 首先在免提系統(tǒng)10中，BT模塊30和BTAG18完成BT無線連接(RFC0MM連 接)。由此，在BT模塊30和BTAG18之間能夠使用聲音鏈接(SCO鏈接)和數(shù)據(jù)鏈接(ACL 鏈接)。ST2、ST3 由于RFCOMM連接完成，BT模塊30和BTAG18的各器件分別開始免提通 話所需要的收發(fā)處理。由此，以后BT模塊30和BTAG18在相互進行通信的同時，在車內(nèi)通 過車載的揚聲器對以及麥克風沈、能夠通過免提來實現(xiàn)BTAG18與固定電話14之間的聲音 通話。[終話發(fā)生時]ST4 之后，例如當在遠端的固定電話14或者近端的BTAG18中產(chǎn)生終話(通話結(jié) 束)時，在BTAG18中進行終話處理。
ST5 并且，由于終話的發(fā)生，基于BT通信規(guī)格的基準，BTAG18對BT模塊30例如 發(fā)行標記為“+CIEV(call = 0)，，的終話事件。ST6 =BT模塊30進行接收處理，對從BTAG18通知的終話事件進行解釋。ST7 然后，BT模塊30將接受到的終話事件的“ +CIEV (call = 0)，，通知給主 CPU28a。由此，主CPU28a在免提系統(tǒng)10中能夠確認處于通話結(jié)束了的狀態(tài)。以上的處理時序，基于一般的BT通信規(guī)格在各器件正常動作的情況下實現(xiàn)。但 是，實際上還存在不滿足BT通信規(guī)格的標準的一部分的BTAG18，在該情況下即使在BTAG18 中產(chǎn)生終話，也不對BT模塊30通知終話事件的“+CIEV(call = 0)”。此時，即使實際上通 話結(jié)束，BT模塊30也未接受到終話事件的“+CIEV(call = 0) ”，因此在該情況下不能夠確 認主CPU28a中的通話結(jié)束。因此，在本實施方式中，通過采用以下列舉的多個模式的時序，來確認作為免提系 統(tǒng)10的通話狀態(tài)。[第一模式]圖3是表示通話確認方法的第一模式的時序圖。另外，在圖3以后，對于已經(jīng)使用 圖2說明了的處理相同的處理賦予共同的符號，并省略其重復的說明。[從BT連接到發(fā)生終話為止]STl ST4 在第一模式中，也執(zhí)行從上述的BT連接到發(fā)生終話為止的時序。但是，在BTAG18中器件(內(nèi)置模塊)未滿足標準的情況下，如圖3中的虛線的箭頭 所示那樣，即使發(fā)生之后也不發(fā)行終話事件的“+CIEV(call = 0)”(圖中賦予“X”標記)。 因此，在BT模塊30中也未接受到終話事件，因此如相同的圖3中的虛線的箭頭所示那樣， 不能夠從BT模塊30向主CPU28a通知終話事件的“+CIEV(call = 0) ”(圖中賦予“X”標 記)。[SCO鏈接切斷時]STlO 但是，由于通話結(jié)束，BT模塊30與BTAG18之間的聲音鏈接(SCO鏈接)被 切斷。[提問工序]STll 以聲音鏈接(SCO鏈接)被切斷為契機，BT模塊30進行提問處理，例如生成 用“AT+CIND ？ ”標記的詢問用的指令。該指令對BTAG18詢問當前的服務狀態(tài)(service、 call、callsetup> signal、roam)。ST12 然后，從BT模塊30對BTAG18發(fā)行上述的標記為“AT+CIND ？ ”的詢問事件。ST13 :BTAG18執(zhí)行事件接收處理，對詢問事件的用“AT+CIND ？，，標記的指令進行 解釋。然后，BTAG18生成對于該指令的應答事件。ST14 然后，BTAG18對BT模塊30發(fā)行生成的應答事件。此時如果實際上通話結(jié) 束，則應答事件的內(nèi)容應該成為用“+CIEV(call = 0)”標記的終話事件(圖的標記不同)。[確認工序]ST15 此時，BT模塊30進行接收處理，并對從BTAG18通知的終話事件進行解釋。ST16 然后，BT模塊30將接受到的終話事件的“+CIEV(call = 0)，，通知給主 CPU28a。由此，主CPU28a能夠確認在免提系統(tǒng)10中處于通話結(jié)束的狀態(tài)(處于圖的標記 也不同)。
以上的時序，是對于詢問事件的“AT+CIND ？ ”，BTAG18的器件正常地通知了應答事 件的情況下的流程。因此，第一模式在該階段作為器件正常動作時的通話確認方法是有效 的。[器件非正常動作時]ST14 但是，如上所述，在BTAG18的器件在此未滿足BT通信規(guī)格的標準的情況下， 實際上如圖3所示那樣，此處有時BTAG18發(fā)行與本來的狀態(tài)(終話的狀態(tài))不同內(nèi)容的用 "+CIEV (call = 1)”標記的通話中事件。ST15 此時，BT模塊30進行接收處理，并對從BTAG18通知的通話中事件直接進行解釋。ST16 然后，BT模塊30將接受到的通話中事件的“+CIEV(call = 1)”通知給主 CPU28a。此時，主CPU28a不能夠確認在免提系統(tǒng)10中實際上處于通話結(jié)束了的狀態(tài)。因 此，在本實施方式中，能夠執(zhí)行以下列舉的通話確認方法的第二模式。[第二模式]圖4是表示通話確認方法的第二模式的時序圖。該第二模式例如能夠適用于通過 上述第一模式不能夠進行通話的確認的情況(未從BTAG18通知“+CIEV(call = 0) ”)。其 中，尤其是還能夠不考慮這種條件地執(zhí)行第二模式。[從BT連接到終話發(fā)生、SCO鏈接切斷為止]STl ST4、ST10 在第二模式中，也同樣進行從上述的BT連接到終話發(fā)生、SCO鏈 接切斷為止的流程。[提問工序]ST20 在第二模式中，以聲音鏈接的切斷為契機而BT模塊30執(zhí)行提問處理，例如 生成用“AT+CLCC”標記的詢問用的指令。該指令對BTAG18詢問當前的通話狀態(tài)(通話中、 三者通話保留中、發(fā)送中、發(fā)出呼叫中、來電中、來電保留中)。ST21 然后，從BT模塊30對BTAG18發(fā)行上述的標記為“AT+CLCC”的詢問事件。ST22 =BTAGlS執(zhí)行事件接收處理，對詢問事件的用“AT+CLCC”標記的指令進行解 釋。然后，BTAG18生成對于該指令的應答事件。ST23 然后，BTAG18對BT模塊30發(fā)行生成的應答事件。此時如果實際上通話結(jié) 束(未通話狀態(tài))，則應答事件的內(nèi)容成為僅由“0K”標記的內(nèi)容。另一方面，如果實際上通 話還未結(jié)束(通話中狀態(tài))，則應答事件的內(nèi)容成為由“0K+CLCC”標記的內(nèi)容，通過其中的 “+CLCC”來通知當前狀態(tài)為“通話中”、“三者通話保留中”、“發(fā)送中”、“發(fā)出呼叫中”、“來電 中”和“來電保留中”的某一個。[確認工序]ST24 此時，BT模塊30進行接收處理，并對從BTAG18通知的應答事件的內(nèi)容進行解釋。ST25 然后，BT模塊30將接受到的應答事件的“0K”或者“0K+CLCC”通知給主 CPU28a。由此，主CPU28a在接受到了“OK”的情況下能夠確認在免提系統(tǒng)10中處于通話結(jié) 束的狀態(tài)(未通話狀態(tài))。另一方面，在接受到了 “0K+CLCC”的情況下主CPU28a能夠確認 由“+CLCC”通知的當前狀態(tài)。[實際的終話時]
通常，如果在“ST10”中聲音鏈接(SCO鏈接)的切斷時，通過BTAG18而實際上通 話結(jié)束，則“ST23”中的應答事件僅成為“0K”。因此，以實際的終話為契機而聲音鏈接(SCO 鏈接)被切斷的情況下，如果適用第二模式的時序，則在主CPU28a中能夠正確地確認免提 系統(tǒng)10的通話結(jié)束的狀態(tài)。[SCO鏈接切斷后的通話]另一方面，在免提系統(tǒng)10中，在BT模塊30與BTAG18之間的聲音鏈接(SCO鏈接) 被切斷后，有時也可能通過BTAG18執(zhí)行通話。例如，即使為相同近端的用戶，在不是駕駛者 Hl而是乘客H2在車內(nèi)進行通話(例如私人的通話)的情況下，不一定限于利用免提通話。 此時，乘客H2例如使車載電氣部件單元12的免提通話功能截止，而對BTAG18進行鍵操作 來進行發(fā)送或來電，之后的通話是將BTAG18(即便攜電話18)拿在手中的狀態(tài)下進行的。在上述的情況下，在之前的“ST10”中聲音鏈接被切斷之后，對于在“ST21”中來自 BT模塊30的詢問事件“AT+CLCC”，BTAG18在“ST23”中是以通知“0K+CLCC (通話中)”的應 答事件。于是，接受到該應答事件的BT模塊30，在“ST25”中對主CPU28a通知“0K+CLCC (通 話中)”。此時，主CPU28a能夠確認為“在聲音鏈接(SCO鏈接)的切斷后、繼續(xù)通過BTAG18 進行通話中”的狀態(tài)。[第三模式]圖5是表示通話確認方法的第三模式的時序圖。該第三模式例如能夠適用于在上 述第二模式中進行了在聲音鏈接(SCO鏈接)的切斷后、繼續(xù)通過BTAG18進行通話中的確 認的情況(從BTAG18通知了 “0K+CLCC”)。[從BT連接到終話發(fā)生、SCO鏈接切斷為止]STl ST4、ST10 在第三模式中，也同樣進行從上述的BT連接到終話發(fā)生、SCO鏈 接切斷為止的流程。[SCO鏈接切斷后的通話]之后，例如當乘客H2不使用免提功能而直接對BTAG18進行鍵操作而進行電話發(fā) 送時，BTAG18成為與遠端的固定電話14進行私人通話狀態(tài)。[從SCO鏈接切斷到詢問、應答事件通知為止]ST20 ST25 另一方面在第三模式中，也進行SCO鏈接切斷后的詢問事件發(fā)行和 應答事件的通知和受領。此時，BTAG18實際上為通話中，因此在“ST23”中的應答事件成為 “0K+CLCC”，結(jié)果由主CPU28a確認“通話中”的狀態(tài)。[在遠端的終話]ST30 之后，例如當遠端的用戶H3(固定電話14)結(jié)束通話時，由此BTAG18與電話 線路的連接被切斷。ST31 此時，BTAG18同樣進行終話處理。[器件非正常動作時](ST32(失敗))在此，同樣在BTAG18中器件(內(nèi)置模塊)未滿足BT通信規(guī) 格的標準的情況下，如圖5中的虛線箭頭所示那樣，即使發(fā)生終話也不發(fā)行終話事件的 "+CIEV(call = 0)，，(在圖中標記“ X ”)。(ST34(失敗))因此，在BT模塊30中為接受到終話事件，因此相同如圖5中的虛 線箭頭所示那樣，不能夠從BT模塊30向主CPU28a通知終話事件的“+CIEV(call = 0) ”(在圖中標記“X”)。因此，在該情況下不能夠由主CPU28a確認“通話結(jié)束”的狀態(tài)。因此，在第三模式 中，通過執(zhí)行以下的時序來確認通話的狀態(tài)。[產(chǎn)生事件觸發(fā)]ST35 例如，在之前的“ST23”中接受到應答事件的“0K+CLCC”的情況下，接受到該 應答事件的BT模塊30產(chǎn)生事件觸發(fā)。事件觸發(fā)能夠?qū)⒔邮艿綉鹗录摹?K+CLCC”為條 件而產(chǎn)生。之后事件觸發(fā)例如也能夠作為使用計時器的定期事件而產(chǎn)生，或者也能夠不使 用計時器而隨機地產(chǎn)生。另外，在圖5的時序例子中，成為在遠端的通話結(jié)束(ST30)之后 產(chǎn)生事件觸發(fā)的流程，但是也可以從通話結(jié)束(ST30)以前開始，在BT模塊30中自發(fā)地產(chǎn) 生事件觸發(fā)。[提問工序]ST36 無論如何，當產(chǎn)生事件觸發(fā)時，BT模塊30執(zhí)行提問處理，生成上述的用 “AT+CLCC”標記的詢問用的指令。ST37 然后，從BT模塊30對BTAG18發(fā)行詢問事件的“AT+CLCC”。ST38 =BTAGlS執(zhí)行事件接收處理，對詢問事件的用“AT+CLCC”標記的指令進行解 釋。然后，BTAG18生成對于該指令的應答事件。ST39 然后，BTAG18對BT模塊30發(fā)行生成的應答事件。如上所述，此時如果實際 上通話結(jié)束(未通話狀態(tài))，則應答事件的內(nèi)容僅成為用“0K”標記的終話事件。另一方面， 如果實際上通話還未結(jié)束(通話中狀態(tài))，則應答事件的內(nèi)容成為由“0K+CLCC”標記的內(nèi)容。[確認工序]ST40 此時，BT模塊30進行接收處理，并對從BTAG18通知的應答事件的內(nèi)容進行解釋。ST41 然后，BT模塊30將接受到的應答事件的“0K”或者“0K+CLCC”通知給主 CPU28a。由此，主CPU28a在接受到了“OK”的情況下能夠確認在免提系統(tǒng)10中處于通話結(jié) 束的狀態(tài)(未通話狀態(tài))。另一方面，在接受到了 “0K+CLCC”的情況下，主CPU28a能夠確認 由“+CLCC”通知的當前狀態(tài)。[詢問、確認的反復]在之前的“ST14”中通知了 “0K+CLCC”的情況下，BT模塊30之后也在“ST35”中 產(chǎn)生事件觸發(fā)。由此，在每次產(chǎn)生事件觸發(fā)時，重復執(zhí)行“ST36” “ST41”的時序。并且，之后例如在實際上在遠端的固定電話14中結(jié)束了通話的情況下，在“ST39” 中從BTAG18僅通知“0K”的應答事件。接受到該應答事件，BT模塊30在“ST41”中僅將 “0K”通知給主CPU28a。由此，主CPU28a能夠確認免提系統(tǒng)10的通話結(jié)束的狀態(tài)。以上的第三模式，是在聲音鏈接(SCO鏈接)的切斷后，從BT模塊30作為詢問事 件而發(fā)行“AT+CLCC”的情況下的時序。在此基礎上，在本實施方式中，也可以采用如下的時 序在聲音鏈接(SCO鏈接)的切斷后，在作為詢問事件首先發(fā)行“AT+CIND ？ ”、作為其應答 事件未通知“+CIEV(call = 0) ”的情況下，作為下一個詢問事件而發(fā)行“AT+CLCC”。以下， 將該情況下的時序作為通話確認方法的第四模式進行說明。[第四模式]
圖6是表示通話確認方法的第四模式的時序圖。該第四模式例如能夠適用于如下 的情況在上述第一模式中不能夠進行終話的確認(BTAG18未自發(fā)地通知“+CIEV(call = 0)”)的情況下，之后聲音鏈接(SCO鏈接)被切斷。[從BT連接到終話發(fā)生、SCO鏈接切斷為止]STl ST4、ST10 在第四模式中，也同樣進行從上述的BT連接到終話發(fā)生、SCO鏈 接切斷為止的流程。[第一詢問提問工序]STll 以聲音鏈接(SCO鏈接)被切斷為契機，BT模塊30執(zhí)行提問處理，作為第一 詢問指令而生成用“AT+CIND ？ ”標記的指令。ST12 然后，從BT模塊30對BTAG18發(fā)行上述的由“AT+CIND ？ ”標記的詢問事件。ST13 :BTAG18執(zhí)行事件接收處理，對詢問事件的用“AT+CIND ？，，標記的指令進行 解釋。然后，BTAG18生成對于該指令的應答事件。ST14 然后，BTAG18對BT模塊30發(fā)行生成的應答事件。此時如果實際上通話未 結(jié)束，則應答事件的內(nèi)容應該成為用“+CIEV(call = 1)”標記的終話事件。[確認工序]ST15 此時，BT模塊30進行接收處理，并對從BTAG18通知的終話事件進行解釋。ST16:然后，BT模塊30將接受到的終話事件的“+CIEV(call = 1)”通知給主 CPU28a。由此，主CPU28a能夠確認在免提系統(tǒng)10中處于通話中的狀態(tài)。[產(chǎn)生事件觸發(fā)]ST35 在第四模式中，在之前的“ST14”中接受到“+CIEV(call = 0)”以外的應答 事件、S卩“+CIEV(call = 1)”的應答事件的情況下，以此為契機BT模塊30產(chǎn)生事件觸發(fā)。 之后事件觸發(fā)例如也能夠作為使用計時器的定期事件而產(chǎn)生，或者也能夠不使用計時器而 隨機地產(chǎn)生。[第二詢問提問工序]ST36 無論如何，當產(chǎn)生事件觸發(fā)時，BT模塊30執(zhí)行提問處理，此次作為第二詢問 指令而生成“AT+CLCC”。ST37 然后，從BT模塊30對BTAG18發(fā)行詢問事件的“AT+CLCC”。ST38 =BTAGlS執(zhí)行事件接收處理，對詢問事件的用“AT+CLCC”標記的指令進行解 釋。然后，BTAG18生成對于該指令的應答事件。ST39 然后，BTAG18對BT模塊30發(fā)行生成的應答事件。如上所述，此時如果實際 上通話結(jié)束(未通話狀態(tài))，則應答事件的內(nèi)容僅成為用“0K”標記的終話事件。另一方面， 如果實際上通話還未結(jié)束(通話中狀態(tài))，則應答事件的內(nèi)容成為由“0K+CLCC”標記的內(nèi)容。[確認工序]ST40 此時，BT模塊30進行接收處理，并對從BTAG18通知的應答事件的內(nèi)容進行解釋。ST41 然后，BT模塊30將接受到的應答事件的“0K”或者“0K+CLCC”通知給主 CPU28a。由此，主CPU28a在接受到了“OK”的情況下能夠確認在免提系統(tǒng)10中處于通話結(jié) 束的狀態(tài)(未通話狀態(tài))。另一方面，在接受到了“0K+CLCC”的情況下，主CPU28a能夠確認由“+CLCC”通知的當前狀態(tài)。在第四模式的時序中、在BT模塊30接受到應答事件的“0K”的情況下，由此能夠 確認終話，但是在接受到“0K+CLCC”的應答事件的情況下，能夠接著執(zhí)行以下的第五模式的 時序。[第五模式第二詢問、確認的反復]S卩，在之前的“ST14”中通知了 “0K+CLCC”的情況下，BT模塊30之后也在“ST35” 中產(chǎn)生事件觸發(fā)。由此，在每次產(chǎn)生事件觸發(fā)時，重復執(zhí)行“ST36” “ST41”的時序。另夕卜， 事件觸發(fā)能夠定期或者不定期地產(chǎn)生。并且，之后例如在實際上在遠端的固定電話14中結(jié)束了通話的情況下，在“ST39” 中從BTAG18僅通知“0K”的應答事件。接受到該應答事件，BT模塊30在“ST41”中僅將 “0K”通知給主CPU28a。由此，主CPU28a能夠確認免提系統(tǒng)10的通話結(jié)束的狀態(tài)。[控制程序的例子]以上舉出的第一 第五模式的各時序，例如能夠通過在BT模塊30中組入以下的 控制程序來實現(xiàn)?？刂瞥绦蚶缒軌蝾A先存儲到BT模塊30所內(nèi)置的ROM中。[通話確認處理]圖7是表示BT模塊30作為控制程序而執(zhí)行的通話確認處理的順序例的流程圖。 BT模塊30，例如能夠在免提通話中作為計時器插入處理而執(zhí)行圖7所示的通話確認處理。 以下，沿著順序例進行說明。步驟SlOO 隨著處理開始，BT模塊30對是否從BTAG18通知了終話事件的 "+CIEV (call = 1)” 進行確認。步驟SlOl 結(jié)果，如果實際上通知了 “+CIEV(call = 1)，，(步驟SlOO 是)，則BT 模塊30在此確認終話，結(jié)束處理。對此，如果未從BTAG18通知終話事件的“+CIEV(call = 1)，，(步驟SlOO 否)，則 BT模塊30執(zhí)行之后的步驟S102。步驟S102 =BT模塊30對與BTAG18之間的SCO鏈接是否被切斷進行確認。如果 SCO鏈接還未被切斷(否)，則BT模塊30返回步驟S 100而重復終話事件的確認。[第一模式的情況]另一方面，在確認了 SCO鏈接被切斷的情況下(步驟S102 是)，則BT模塊30前 進到之后的步驟S104。步驟S104 =BT模塊30對BTAG18發(fā)行詢問事件的“AT+CIND ？，，。步驟S106 然后，BT模塊30對是否從BTAG18通知了作為應對事件的“+CIEV(call =0)”進行確認。步驟SlOl 結(jié)果，如果實際上通知了 “+CIEV(call = 0)，，(步驟S106 是)，則BT 模塊30在此確認終話，結(jié)束處理。通過到此為止的順序，能夠?qū)崿F(xiàn)上述第一模式的時序(圖3)。下面，對用于實現(xiàn)第 二模式的時序(圖4)的順序進行說明。[第二模式的情況]在之前的步驟S102中在確認了 SCO鏈接被切斷的情況下(步驟S102 是)，此次 按照圖7中的連接記號“A” 一 "k", BT模塊30前進到之后的步驟S108。
步驟S108 =BT模塊30對BTAG18發(fā)行詢問事件的“AT+CLCC”。步驟SllO 然后，BT模塊30對是否從BTAG18通知了作為應對事件的“0K+CLCC” 進行確認。步驟SlOl 結(jié)果，在通知了僅由“0K”部件的應答事件的情況下(步驟SllO 否)， 則BT模塊30在此確認終話，結(jié)束處理。通過到此為止的順序，能夠?qū)崿F(xiàn)上述第二模式的時序(圖4)。下面，對用于實現(xiàn)第 三模式的時序(圖5)的順序進行說明。[第三模式的情況]在之前的步驟SllO中在確認了從BTAG18作為應答事件通知了“0K+CLCC”的情況 下(步驟SllO 是)，BT模塊30前進到之后的步驟S112。步驟S112 此時，BT模塊30使時間計時器進行計數(shù)。具體地說，使此前停止的計 時器啟動，并開始其計數(shù)。步驟S114 然后，BT模塊30對事件計時器的值是否到達了預先設定的計數(shù)值(例 如幾秒 幾十秒程度)進行確認。如果還未到達計數(shù)值(否)，則BT模塊30返回步驟S112， 繼續(xù)計時器計數(shù)之后，當確認了事件計時器的值到達了計數(shù)值時(步驟S114 是)，BT模塊30停 止事件計時器，并在重置其值的基礎上返回步驟S108。此后，BT模塊30重復執(zhí)行步驟S108 步驟S114。由此，BT模塊30在從BTAG18 通知“0K”的應答事件之前，反復發(fā)行詢問事件的“AT+CLCC”，由此能夠?qū)崿F(xiàn)上述的第三模 式的時序。[第四模式的情況]圖7中，在步驟S102的判斷為肯定(是)的情況下，當按照連接記號“A”一“A”從 不知S102跳躍到不知S108時，成為第三模式的時序。對此，當不按照連接記號“A” 一 "K" 而前進到步驟S104時，能夠?qū)崿F(xiàn)上述的第四模式的時序(圖6)。
步驟S104 即，BT模塊30對BTAG18發(fā)行詢問事件的"AT+CIND ？，，(第一詢問)。步驟S106 然后，BT模塊30對是否從BTAG18通知了作為應對事件的“+CIEV(call =0)”進行確認。步驟SlOl 結(jié)果，如果實際上通知了“+CIEV(call = 0) ”的應答事件(步驟S106 是)，則BT模塊30在此確認終話，結(jié)束處理。對此，在之前的步驟S106中，在未從BTAG18通知債務應答事件的“+CIEV (call = 0)，，的情況下(步驟S106 否)，BT模塊30執(zhí)行之后的步驟S108。步驟S108 在此，BT模塊30對BTAG18發(fā)行詢問事件的“AT+CLCC” (第二詢問)。步驟SllO 然后，BT模塊30對是否從BTAG18通知了作為應對事件的“0K+CLCC” 進行確認。步驟SlOl 結(jié)果，在通知了僅由“0K”部件的應答事件的情況下(步驟SllO 否)， 則BT模塊30在此確認終話，結(jié)束處理。通過到此為止的順序，能夠?qū)崿F(xiàn)上述第四模式的時序(圖6)。并且，通過執(zhí)行步驟 S112以后，能夠?qū)崿F(xiàn)上述第五模式的時序(圖6)。[第五模式的情況]
S卩，在之前的步驟SllO中在確認了從BTAG18作為應答事件通知了 “0K+CLCC”的 情況下(步驟SllO 是)，BT模塊30前進到之后的步驟S112。步驟S112 此時，BT模塊30使時間計時器進行計數(shù)。具體地說，使此前停止的計 時器啟動，并開始其計數(shù)。步驟S114 =BT模塊30對事件計時器的值是否到達了上述計數(shù)值進行確認。如果 還未到達計數(shù)值(否)，則BT模塊30返回步驟S112，繼續(xù)計時器計數(shù)之后，當確認了事件計時器的值到達了計數(shù)值時(步驟S114 是)，BT模塊30停 止事件計時器，并在重置其值的基礎上返回步驟S108。此后，BT模塊30重復執(zhí)行步驟S108 步驟S114。由此，BT模塊30在從BTAG18 通知“0K”的應答事件之前，反復發(fā)行詢問事件的“AT+CLCC”，由此能夠?qū)崿F(xiàn)上述的第五模 式的時序。如上所述，根據(jù)本實施方式的通話確認方法，即使BTAG18(便攜電話18)搭載了 不滿足BT通信規(guī)格的一部分標準的器件，通過進行來自BT模塊30的詢問，也能夠由主 CPU28a最終地確認通話結(jié)束(終話)的狀態(tài)。因此，主CPU28a不會保持一致不能夠確認終話的狀態(tài)而使免提系統(tǒng)10的動作不 穩(wěn)定化，在確認了終話的情況下，能夠順暢地實現(xiàn)之后的動作(之后的來電、發(fā)送的免提通 話、音頻輸出等)。并且，如果是對應于BT通信的便攜電話18，則不受機型或型號的制約，能夠?qū)⑵?余車載電氣部件單元12進行組合而容易地構(gòu)建免提系統(tǒng)10。因此，提高作為免提系統(tǒng)10 的通用性，能夠保證實用性更高的動作。另外，在圖7所示的流程圖中，最初在步驟SlOO中確認是否接受到“+CIEV(call =0) ”的應答事件，但是也可以不特別地判斷這種條件，而從步驟S102開始處理。本發(fā)明不受上述的一個實施方式制約，能夠多種變形地實施。例如，免提系統(tǒng)10 不僅使便攜電話18與車載電氣部件單元12的組合，也可以由其他機器之間的組合而構(gòu)成。并且，免提系統(tǒng)10不僅一直適用于第一 第五模式的全部的通話確認方法，也可 以選擇地適用于任意一種通話確認方法。
權利要求
1.一種免提系統(tǒng)的通話確認方法，所述免提系統(tǒng)具備便攜設備和通話機器，該便攜設 備能夠與電話線路連接，該通話機器通過與該便攜設備之間進行相互通信，能夠使用上述 便攜設備以外的其他設備進行通過電話線路的免提通話，所述通話確認方法特征在于，具 備提問工序，由上述通話機器對上述便攜設備詢問與上述電話線路的連接有關的動作狀 態(tài)；和確認工序，基于來自上述便攜設備的對于上述詢問的應答結(jié)果，利用上述通話機器確 認免提系統(tǒng)的通話的狀態(tài)。
2.如權利要求1所述的免提系統(tǒng)的通話確認方法，其特征在于，在上述提問工序中，以上述便攜設備與上述通話機器之間的聲音鏈接切斷的情況為契 機，由上述通話機器對上述便攜設備詢問使用了上述電話線路的通話是否結(jié)束。
3.如權利要求1所述的免提系統(tǒng)的通話確認方法，其特征在于，在上述提問工序中，以上述便攜設備與上述通話機器之間的聲音鏈接切斷的情況為契 機，由上述通話機器對上述便攜設備詢問使用了上述電話線路的通話處于哪種狀態(tài)。
4.如權利要求3所述的免提系統(tǒng)的通話確認方法，其特征在于，在對于上述提問工序中的詢問，有來自上述便攜設備的通話還未結(jié)束的內(nèi)容的應答的 情況下，之后直到有來自上述便攜設備的通話結(jié)束了的內(nèi)容的應答為止，隔開規(guī)定的等待 時間而重復上述提問工序中的詢問。
5.如權利要求1所述的免提系統(tǒng)的通話確認方法，其特征在于，在上述提問工序中，以上述便攜設備與上述通話機器之間的聲音鏈接切斷的情況為 契機，由上述通話機器對上述便攜設備進行使用了上述電話線路的通話是否結(jié)束的第一詢 問，在結(jié)果為，在沒有來自上述便攜設備的通話結(jié)束了的內(nèi)容的應答的情況下，由上述通話 機器對上述便攜設備進行使用了上述電話線路的通話處于哪種狀態(tài)的第二詢問。
6.如權利要求5所述的免提系統(tǒng)的通話確認方法，其特征在于，在對于上述提問工序中的上述第二詢問，有來自上述便攜設備的通話還未結(jié)束的內(nèi)容 的應答的情況下，之后直到有來自上述便攜設備的通話結(jié)束的內(nèi)容的應答為止，隔開規(guī)定 的等待時間重復上述提問工序中的詢問。
全文摘要
本發(fā)明涉及一種免提系統(tǒng)的通話確認方法，在假定了使用不滿足通信規(guī)格的標準的一部分的器件的可能性的基礎上，構(gòu)建通用性更高的免提系統(tǒng)。搭載了BT模塊(30)的車載電氣部件(12)，將便攜電話(18)作為音頻通道(BTAG)而構(gòu)建免提系統(tǒng)。此時通過RFCOMM(ST1)連接完成能夠?qū)崿F(xiàn)免提通話，但是在BTAG(18)中終話也未通知“+CIEV(call＝0)”的情況下，在主CPU(28a)中不能夠確認終話。因此，在SCO鏈接切斷(ST10)之后從BT模塊(30)發(fā)行“AT+CIND？”的詢問事件(ST12)。如此具有來自BTAG(18)的“+CIEV(call＝0)”的應答事件，則能夠在主CPU(28a)中確認終話。
文檔編號H04M1/60GK102055829SQ20101050579
公開日2011年5月11日 申請日期2010年10月11日 優(yōu)先權日2009年11月6日
發(fā)明者川上步, 渡邊文夫 申請人:阿爾卑斯電氣株式會社