本發(fā)明屬于課堂點名技術領域，尤其涉及一種基于手機卡序號和MAC地址識別的課堂自動點名系統(tǒng)。

背景技術：

現(xiàn)有的手機自動點名系統(tǒng)通過識別在場學生手機實現(xiàn)。原理是教師開啟WiFi熱點，學生開啟WiFi，教師通過識別連入手機的MAC地址，比對事先登記的學生手機MAC地址，就可以得到在場學生的列表。但是學生可以登記一臺不常使用的手機，交給他人代點名。

綜上所述，現(xiàn)有的手機自動點名系統(tǒng)存在可以他人帶點名，造成點名信息不準確。

技術實現(xiàn)要素：

本發(fā)明的目的在于提供一種基于手機卡序號和MAC地址識別的課堂自動點名系統(tǒng)，旨在解決現(xiàn)有的手機自動點名系統(tǒng)存在可以他人帶點名，造成點名信息不準確的問題。

本發(fā)明是這樣實現(xiàn)的，一種基于手機卡序號和MAC地址識別的課堂自動點名方法，所述基于手機卡序號和MAC地址識別的課堂自動點名方法包括以下步驟：

步驟一，點名端以指定名稱開啟WiFi熱點，同時開啟HTTP服務器端口等待被點名端的數據；

步驟二，被點名端讀取本機SIM/USIM卡號，同時檢查特定時間內本機通話和短信頻率；

步驟三，被點名端連入點名端的WLAN，若連接成功，向點名端發(fā)送本機SIM/USIM卡號和近期有否通信記錄的信息；發(fā)送成功后斷開WiFi連接，以釋放通信信道資源；

步驟四，點名端檢查被點名端的MAC地址，SIM/USIM卡號是否匹配，近期有無通話和短信記錄，對被點名者是否在場做出判斷。

進一步，步驟一中，點名端開啟熱點WiFi,同時啟動HTTP服務器，具體包括：

點名端的熱點接口的IP地址和HTTP服務器的TCP端口號設為約定的值；

被點名端通過HTTP請求向點名端發(fā)送信息；HTTP請求采用GET,PUT,或POST；在GET請求的URL中加入卡號參數，檢測最近有無主動通信記錄；若被點名端有多個電話卡，只使用第一張卡的卡號；

被點名端僅僅報告最近有無主動通信記錄，不報告通信記錄的具體信息，不侵害被點名端的通信秘密；

點名端收到被點名端的信息后，將信息存儲在本機中，并向被點名端發(fā)送HTTP響應。

被點名端不必顯式地發(fā)送MAC地址，點名端軟件通過查詢本機的ARP表可以由被點名端的IP地址查到其MAC地址。對于Android被點名端，卡號可以TelephonyManager類獲取。

進一步，步驟二中，被點名端讀取本機SIM/USIM卡號，同時檢查特定時間內本機通話和短信頻率，具體包括：

Android被點名端通過CallLog.Calls.CONTENT_URI來獲取通話記錄數據庫，通過設置一定的查詢條件(如：通話日期在最近若干天內，類型為呼出)，查到給定時間段內手機有否撥出電話；同時，通過content://sms/sent查到給定時間段內有否發(fā)送短信；

所述給定時間段的值的設置參考被點名群體使用手機進行主動通信的頻繁程度。比如對于大學生而言，三天沒有主動通信則可認為該手機并非用于日常使用。

進一步，步驟四中，所述點名端檢查被點名端的MAC地址，SIM/USIM卡號是否匹配，具體包括：點名端預先儲存了每一個被點名端的信息，包括卡號和MAC地址，以及姓名，學號所需信息；通過檢查HTTP請求的來源MAC地址，獲得該條記錄已登記的卡號，然后檢查這個卡號是否與HTTP請求中的卡號一致；

步驟四中，所述近期有無通話和短信記錄，對被點名者是否在場做出判斷，具體為：

在點名過程結束后，點名端逐條檢查已登記的被點名端的記錄，當同時滿足下列條件時，判斷該被點名者在場；所述條件包括：

1)該條記錄登記的MAC地址在點名過程中發(fā)送了HTTP請求；

2)該條記錄登記的卡號等于對應的HTTP請求中包含的卡號；

3)對應的HTTP請求表明給定時間段內該手機有主動通信記錄；

對于不滿足以上條件的記錄，系統(tǒng)給予提示，點名者以人工點名進行核實。

本發(fā)明的另一目的在于提供一種所述基于手機卡序號和MAC地址識別的課堂自動點名方法的課堂自動點名系統(tǒng)，所述課堂自動點名系統(tǒng)包括：點名端、被點名端；

所述點名端通過WiFi熱點與被點名端無線通訊。

本發(fā)明的另一目的在于提供一種利用所述基于手機卡序號和MAC地址識別的課堂自動點名方法的手機。

本發(fā)明提供的基于手機卡序號和MAC地址識別的課堂自動點名系統(tǒng)，可以識別學生手機的MAC地址，同時檢查學生手機的SIM/USIM卡是否與之匹配，有無近期通話或短信記錄，在可疑時提醒教師，從而減少了代點名的可能性。本發(fā)明實現(xiàn)簡單；點名過程不依賴電信網絡，不產生話費和流量費；由于同時利用多重信息，提高了判斷的可靠性。

附圖說明

圖1是本發(fā)明實施例提供的基于手機卡序號和MAC地址識別的課堂自動點名系統(tǒng)結構示意圖；

圖中：1、點名端；2、被點名端。

圖2是本發(fā)明實施例提供的基于手機卡序號和MAC地址識別的課堂自動點名方法流程圖。

具體實施方式

為了使本發(fā)明的目的、技術方案及優(yōu)點更加清楚明白，以下結合實施例，對本發(fā)明進行進一步詳細說明。應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

下面結合附圖對本發(fā)明的應用原理作詳細的描述。

如圖1所示，本發(fā)明實施例提供的基于手機卡序號和MAC地址識別的課堂自動點名系統(tǒng)包括：點名端1、被點名端2。

點名端1通過WiFi熱點與被點名端2無線通訊。

如圖2所示，本發(fā)明實施例提供的基于手機卡序號和MAC地址識別的課堂自動點名方法包括以下步驟：

S101：點名端以指定名稱開啟WiFi熱點，同時開啟HTTP服務器端口等待被點名端的數據；

S102：被點名端隨機等待一段時間，以避免WLAN擁塞；

S103：被點名端讀取本機SIM/USIM卡號，同時檢查特定時間內本機通話和短信頻率；

S104：被點名端連入點名端的WLAN，若連接成功，向點名端發(fā)送本機SIM/USIM卡號和近期有否通信記錄的信息。發(fā)送成功后斷開WiFi連接，以釋放通信信道資源；

S105：點名端檢查被點名端的MAC地址，SIM/USIM卡號是否匹配，近期有無通話和短信記錄，可以對被點名者是否在場做出判斷。

進一步，步驟一中，點名端開啟熱點WiFi,同時啟動HTTP服務器，具體包括：

點名端的熱點接口的IP地址和HTTP服務器的TCP端口號設為約定的值；

被點名端通過HTTP請求向點名端發(fā)送信息；HTTP請求采用GET,PUT,或POST；在GET請求的URL中加入卡號參數，檢測最近有無主動通信記錄；若被點名端有多個電話卡，只使用第一張卡的卡號；

被點名端僅僅報告最近有無主動通信記錄，不報告通信記錄的具體信息，不侵害被點名端的通信秘密；

點名端收到被點名端的信息后，將信息存儲在本機中，并向被點名端發(fā)送HTTP響應。

被點名端不必顯式地發(fā)送MAC地址，點名端軟件通過查詢本機的ARP表可以由被點名端的IP地址查到其MAC地址。對于Android被點名端，卡號可以TelephonyManager類獲取。

進一步，步驟二中，被點名端讀取本機SIM/USIM卡號，同時檢查特定時間內本機通話和短信頻率，具體包括：

Android被點名端通過CallLog.Calls.CONTENT_URI來獲取通話記錄數據庫，通過設置一定的查詢條件(如：通話日期在最近若干天內，類型為呼出)，查到給定時間段內手機有否撥出電話；同時，通過content://sms/sent查到給定時間段內有否發(fā)送短信；

所述給定時間段的值的設置參考被點名群體使用手機進行主動通信的頻繁程度。比如對于大學生而言，三天沒有主動通信則可認為該手機并非用于日常使用。

進一步，步驟四中，所述點名端檢查被點名端的MAC地址，SIM/USIM卡號是否匹配，具體包括：點名端預先儲存了每一個被點名端的信息，包括卡號和MAC地址，以及姓名，學號所需信息；通過檢查HTTP請求的來源MAC地址，獲得該條記錄已登記的卡號，然后檢查這個卡號是否與HTTP請求中的卡號一致；

步驟四中，所述近期有無通話和短信記錄，對被點名者是否在場做出判斷，具體為：

在點名過程結束后，點名端逐條檢查已登記的被點名端的記錄，當同時滿足下列條件時，判斷該被點名者在場；所述條件包括：

1)該條記錄登記的MAC地址在點名過程中發(fā)送了HTTP請求；

2)該條記錄登記的卡號等于對應的HTTP請求中包含的卡號；

3)對應的HTTP請求表明給定時間段內該手機有主動通信記錄；

對于不滿足以上條件的記錄，系統(tǒng)給予提示，點名者以人工點名進行核實。

本發(fā)明提供的基于手機卡序號和MAC地址識別的課堂自動點名系統(tǒng)，可以識別學生手機的MAC地址，同時檢查學生手機的SIM/USIM卡是否與之匹配，有無近期通話或短信記錄，在可疑時提醒教師，從而減少了代點名的可能性。本發(fā)明實現(xiàn)簡單；點名過程不依賴電信網絡，不產生話費和流量費；由于同時利用多重信息，提高了判斷的可靠性。

以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內所作的任何修改、等同替換和改進等，均應包含在本發(fā)明的保護范圍之內。