(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-03-27
(54)【発明の名称】迷惑電話通報方法、端末、電子機器及び記憶媒体
(51)【国際特許分類】
H04M 1/72 20210101AFI20240319BHJP
【FI】
H04M1/72
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2023561893
(86)(22)【出願日】2022-06-20
(85)【翻訳文提出日】2023-10-06
(86)【国際出願番号】 CN2022099897
(87)【国際公開番号】W WO2023011024
(87)【国際公開日】2023-02-09
(31)【優先権主張番号】202110898019.2
(32)【優先日】2021-08-05
(33)【優先権主張国・地域又は機関】CN
(81)【指定国・地域】
(71)【出願人】
【識別番号】511151662
【氏名又は名称】中興通訊股▲ふん▼有限公司
【氏名又は名称原語表記】ZTE CORPORATION
【住所又は居所原語表記】ZTE Plaza,Keji Road South,Hi-Tech Industrial Park,Nanshan Shenzhen,Guangdong 518057 China
(74)【代理人】
【識別番号】100112656
【氏名又は名称】宮田 英毅
(74)【代理人】
【識別番号】100089118
【氏名又は名称】酒井 宏明
(72)【発明者】
【氏名】楊海城
(72)【発明者】
【氏名】周金星
【テーマコード(参考)】
5K127
【Fターム(参考)】
5K127AA22
5K127BA03
5K127GB05
5K127GB64
5K127HA07
5K127HA08
5K127NA07
(57)【要約】
迷惑電話通報方法、端末、電子機器及びコンピュータ記憶媒体を提供する。前記方法は、通話相手側から送信されたデータ情報を受信するステップと、ユーザの通報命令を検出すると、少なくとも一部の前記データ情報が運ばれた通報メッセージを自動的に生成するステップと、前記通報メッセージを指定される通報受付センターに送信するステップとを含む。
【選択図】
図1
【特許請求の範囲】
【請求項1】
通話相手側から送信されたデータ情報を受信するステップと、
ユーザの通報命令を検出すると、少なくとも一部の前記データ情報が運ばれた通報メッセージを自動的に生成するステップと、
前記通報メッセージを指定される通報受付センターに送信するステップとを含む、迷惑電話通報方法。
【請求項2】
ユーザの通報命令を検出する前記ステップは、
ユーザによる、第1予め設定されたインタフェースに配置される予め設定されたコントロールに対する予め設定された操作を検出するステップを含む、請求項1に記載の迷惑電話通報方法。
【請求項3】
前記第1予め設定されたインタフェースは、
通話インタフェース又は通話記録インタフェースを含む、請求項2に記載の迷惑電話通報方法。
【請求項4】
ユーザによる、第1予め設定されたインタフェースに配置される予め設定されたコントロールに対する予め設定された操作を検出した後に、第2予め設定されたインタフェースにジャンプするステップをさらに含み、前記第2予め設定されたインタフェースは、通話相手側から送信されたデータ情報を含む、請求項2に記載の迷惑電話通報方法。
【請求項5】
通報メッセージを自動的に生成する前記ステップは、
前記ユーザが前記第2予め設定されたインタフェースに含まれるデータ情報をチェックしたことを検出すると、チェックされたデータ情報を運ぶ通報メッセージを自動的に生成するステップを含む、請求項4に記載の迷惑電話通報方法。
【請求項6】
ユーザによる、第1予め設定されたインタフェースに配置される予め設定されたコントロールに対する予め設定された操作を検出した後に、
第3予め設定されたインタフェースにジャンプするステップをさらに含み、
前記第3予め設定されたインタフェースは、迷惑電話タイプの情報を含み、
前記生成された通報メッセージは、チェックされた前記迷惑電話タイプの情報をさらに運ぶ、請求項2に記載の迷惑電話通報方法。
【請求項7】
前記通報メッセージを指定される通報受付センターに送信した後に、
ユーザ命令に基づいて通報受付センターにおいて前記通報メッセージの処理進捗状況をリアルタイムにクエリするステップをさらに含む、請求項1~6のいずれか1項に記載の迷惑電話通報方法。
【請求項8】
通話相手側から送信されたデータ情報を受信するための受信モジュールと、
ユーザの通報命令を検出した後に、少なくとも一部の前記データ情報が運ばれた通報メッセージを自動的に生成するための生成モジュールと、
前記通報メッセージを指定される通報受付センターに送信するための送信モジュールとを含む、端末。
【請求項9】
少なくとも1つのプロセッサと、
前記少なくとも1つのプロセッサに通信可能に接続されるメモリとを含む電子機器であって、
前記メモリには、前記少なくとも1つのプロセッサにより実行されると、請求項1~7のいずれか1項に記載の迷惑電話通報方法を前記少なくとも1つのプロセッサに実行させる、前記少なくとも1つのプロセッサにより実行可能な命令が記憶されている、電子機器。
【請求項10】
プロセッサにより実行されると、請求項1~7のいずれか1項に記載の迷惑電話通報方法を実現するコンピュータプログラムが記憶されている、コンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本願は、出願番号202110898019.2で、出願日2021年8月5日の中国特許出願に基づいて提出され、当該中国特許出願の優先権を主張しており、当該中国特許出願のすべての内容は参照として本願に組み込まれている。
【0002】
本願は、モビリティ通信の技術分野に関し、特に迷惑電話通報方法に関する。
【背景技術】
【0003】
通信分野では、ユーザの携帯電話端末が悪意のあるプロモーションや詐欺などの迷惑電話を受けることが多く、人々の日常生活に少なからぬ影響を与えている。
【0004】
これに基づいて、迷惑電話とマークされた携帯電話番号をブロックするためにブロックソフトをダウンロードするか、ユーザが12321サイトにアクセスして通報情報記入ページに入って、ユーザの関連情報や通報する電話番号などの詳細な情報を記入し、「提出」をクリックすることができる。しかし、その通報過程は、煩雑で複雑であるだけでなく、関係部門が迷惑電話を整備する効率が低く、ユーザの体験感も悪い。
【発明の概要】
【発明が解決しようとする課題】
【0005】
本願の実施形態の目的は、上記課題を少なくともある程度解決するために、迷惑電話通報方法を提供することであり、ユーザが迷惑電話を通報する過程が煩雑であるという問題を解決し、それにより、ユーザが迷惑電話を通報するのに極めて便利さを提供し、関係部門が迷惑電話を整備する効率を高め、ユーザの体験感を大幅に強化する。
【課題を解決するための手段】
【0006】
本願の実施例は、迷惑電話通報方法を提供する。前記迷惑電話通報方法は、通話相手側から送信されたデータ情報を受信するステップと、ユーザの通報命令を検出すると、少なくとも一部の前記データ情報が運ばれた通報メッセージを自動的に生成するステップと、前記通報メッセージを指定される通報受付センターに送信するステップとを含む。
【0007】
本願の実施例は、端末を提供する。前記端末は、通話相手側から送信されたデータ情報を受信するための受信モジュールと、ユーザの通報命令を検出した後に、少なくとも一部の前記データ情報が運ばれた通報メッセージを自動的に生成するための生成モジュールと、前記通報メッセージを指定される通報受付センターに送信するための送信モジュールとを含む。
【0008】
本願の実施例は、電子機器を提供する。前記電子機器は、少なくとも1つのプロセッサと、前記少なくとも1つのプロセッサに通信可能に接続されるメモリとを含み、前記少なくとも1つのプロセッサにより実行されると上記迷惑電話通報方法を実現する、前記少なくとも1つのプロセッサにより実行可能な命令が前記メモリに記憶されている。
【0009】
本願の実施例は、コンピュータ読み取り可能な記憶媒体を提供する。前記コンピュータ読み取り可能な記憶媒体は、プロセッサによって実行されると上記迷惑電話通報方法をプロセッサに実現させるコンピュータプログラムが記憶されている。
【図面の簡単な説明】
【0010】
【
図1】本願の一実施例による迷惑電話通報方法のフローチャートである。
【
図2】本願の別の実施例による迷惑電話通報方法のフローチャートである。
【
図3】本願の別の実施例における第3予め設定されたインタフェースの概略図である。
【
図4】本願の一実施例による端末の構造概略図である。
【発明を実施するための形態】
【0011】
本願の実施例の目的、技術案及び利点をより明確にするために、以下に図面を用いて本願の各実施形態について詳細に述べる。しかしながら、本願の各実施形態では、読者が本願をよりよく理解するために多くの技術的詳細が提案されている。しかし、これらの技術的詳細や以下の各実施形態に基づく種々の変更や修正がなくても、本願で要求される保護のための技術案を実現することができる。
【0012】
本願の一実施例は、端末、例えばユーザ携帯電話、タブレットコンピュータなどに応用できる迷惑電話通報方法に関する。本実施例では、通話相手側から送信されたデータ情報を受信し、ユーザの通報命令を検出すると、少なくとも一部の前記データ情報が運ばれた通報メッセージを自動的に生成し、前記通報メッセージを指定される通報受付センターに送信する。これにより、ユーザが迷惑電話を通報する過程を大幅に簡略化し、ユーザが迷惑電話を通報するのに極めて便利を提供し、関係部門が迷惑電話を整備する効率を高め、ユーザの体験感を大幅に強化する。
【0013】
以下、本実施例における迷惑電話通報方法の実現詳細について具体的に説明する。以下の内容は本態様の実現詳細を容易にするためのものに過ぎず、本態様を実施するために必要ではない。具体的なフローは
図1に示すように、以下のステップを含んでもよい。
【0014】
ステップ101:端末は、電話に出る。
【0015】
具体的には、端末が通話相手側からの通話接続確立要求を受信した後に、端末がユーザの応答命令を検出すると、端末は、通話相手側と通話接続を確立し、通話を開始する。
【0016】
本実施例に係る通話のタイプは、ニューラジオに基づく音声通話(Voice over New Radio、「VoNR」と略称)、LTEに基づく音声通話(Voice over LTE、「VoLTE」と略称)、WiFiに基づく音声通話(Voice over WiFi、「VoWiFi」と略称)などのIPマルチメディアサブシステム(IP Multimedia Subsystem、「IMS」と略称)タイプの通話を含むが、それらに限らない。
【0017】
また、本実施例に係る通話は、セッション形式で表示され、通話が切られたかどうかにもかかわらず、ユーザが第1予め設定されたインタフェースで双方の記録を見る行為に影響を与えない。即ちユーザが通話中でも電話を切った後でも、通話双方から送信されたテキスト、画像、音声ビデオなどのデータ情報を見ることができる。ここで、第1予め設定されたインタフェースとは、通話インタフェース又は通話記録インタフェースである。セッション形式を用いることによって、ユーザが通話中でも電話を切った後でも、通話双方から送信された記録、例えば、テキスト、画像、音声ビデオなどをいつでも見ることができることを確保することができる。
【0018】
通話接続が確立されると、ステップ102に入る。
【0019】
ステップ102:端末は、データチャンネルを確立する必要があるか否かをモニタリングし、そうであれば、ステップ103に入り、そうでなければ終了する。
【0020】
具体的には、端末は、モニタリングモジュールによって、通話相手側から送信されたセッション初期プロトコル(Session Initiation Protocol、「SIP」と略称)シグナリングをモニタリングし、そのセッション記述プロトコル(Session Description Protocol、「SDP」と略称)offerメッセージを解析する。セッション記述プロトコルにおいてdcmapフィールドを解析すれば、モニタリングモジュールは、データチャンネル管理モジュールにデータチャンネル確立命令を与え、そうではなければ、終了する。ここで、dcmapフィールドは、データチャンネルを確立する必要があることを示す。
【0021】
1つの例では、SDP offerメッセージを解析する時、複数のデータチャネルは、1つの単一チャネルSDPメディア記述にマッピングされる可能性があり、表1に示すように、“a=dcmap”に関連するSDP属性とストリームはそれぞれユニークなメディア記述である。
【0022】
【表1】
ここで、表1における“a=dcmap”に関連する3つのSDP属性とストリームは、それぞれ、データチャンネルを確立する時に3つの異なる方式をとることを示している。具体的には以下のとおりである。
【0023】
a=dcmap:10 subprotocol=“http”は、データチャンネルを確立する時、ハイパーテキスト伝送プロトコル方式を採用することを示している。
a=dcmap:38754 max-time=150、label=“low latency”は、データチャンネルを確立する時、低遅延方式を採用することを示している。
a=dcmap:7216 max-retr=5、label=“low loss”は、確立データチャンネルを確立する時、低損失方式を採用することを示している。
【0024】
上記方法に基づいて、どの方式でデータチャンネルを確立するかを決定した後に、ステップ103に入る。
【0025】
ステップ103:データチャンネルを確立する。
【0026】
具体的には、データチャンネルに関連する過程は、データチャンネルの確立、維持、リリースなどを含む。これらの過程は、いずれもデータチャンネル管理モジュールによって行われる。データチャンネルは、端末と通話相手側との間のテキスト、画像、音声ビデオなどのデータ情報の伝送に用いられる。本願の実施例において確立されるデータチャンネルのタイプは、端末とネットワーク側データサーバーとの間に確立されるデータチャンネル(Bootstrapのデータチャンネル)であってもよく、端末の間に直接確立されるデータチャンネル(Bootstrapではないデータチャンネル)であってもよい。本願の実施例においてデータチャンネルを確立する時の通話相手側は、ネットワーク側のデータサーバーであってもよく、端末であってもよい。
【0027】
データチャンネルを確立した後に、ステップ104に入る。
【0028】
ステップ104:通話相手側から送信されたデータ情報を受信する。
【0029】
具体的には、端末と相手側との通話中、通話相手側は、ステップ103において確立されるデータチャンネルを介して端末にデータ情報を送信し、そのデータ情報タイプは、テキスト、画像、音声ビデオなどであってもよい。
【0030】
通話相手側から送信されたデータ情報を受信した後に、ステップ105に入る。
【0031】
ステップ105:ユーザの通報命令を検出した後に、通報メッセージを自動的に生成する。具体的には、ユーザによる、第1予め設定されたインタフェースにおける予め設定されたコントロールに対する予め設定された操作を検出した後に、通報メッセージを自動的に生成する。
【0032】
1つの例では、第1予め設定されたインタフェースは、通話インタフェースであってもよく、予め設定されたコントロールは、「通報」ボタンであってもよく、予め設定された操作は、クリック操作であってもよい。つまり、ユーザが通話インタフェースにおける「通報」ボタンをクリックしたことを検出すると、通報メッセージを自動的に生成する。
【0033】
1つの例では、ユーザによる、第1予め設定されたインタフェースに配置される予め設定されたコントロールに対する予め設定された操作を検出した後に、第2予め設定されたインタフェースにジャンプする。第2予め設定されたインタフェースは、ユーザがチェックするために、通話相手側から送信されたデータ情報を含む。ユーザが第2予め設定されたインタフェースに含まれるデータ情報をチェックしたことを検出すると、自動的に生成された通報メッセージは、ユーザがチェックしたいくつかのデータ情報を運ぶ。ユーザがチェックしていないと、デフォルトではすべてチェックし、自動的に生成された通報メッセージは、すべてのデータ情報を運ぶ。ここで、通報メッセージが具体的に運ぶ内容は、実際の状況に応じて調整してもよく、そのタイプは、テキスト、画像、音声ビデオなどであってもよい。
【0034】
通報メッセージを自動的に生成した後に、ステップ106に入る。
【0035】
ステップ106:ユーザによる「送信」命令を検出したか否かを判定し、検出した場合、ステップ107に入り、受信しなかった場合、終了する。
【0036】
ステップ107:自動的に生成された通報メッセージを指定される通報受付センターに送信する。
【0037】
本実施例による迷惑電話通報方法は、通話相手側から送信されたデータ情報を受信し、ユーザの通報命令を検出すると、少なくとも一部の前記データ情報が運ばれた通報メッセージを自動的に生成し、前記通報メッセージを指定される通報受付センターに送信することができる。この過程で、ユーザは、ユーザ関連情報を入力する必要がなく、通報が必要な電話番号と詳細な情報を記入して、提出をクリックするなどの操作を行う必要がなく、「通報」ボタンをクリックすれば、端末は、ユーザが「通報」ボタンをクリックした後に通報メッセージを自動的に生成する。ユーザはさらに、提供する必要があるデータ情報をチェックし、チェック動作の終了後、端末は、通報受付センターに送信する。上記通報メッセージの自動的生成、必要な証拠のチェックなどの操作は、ユーザが迷惑電話を通報する過程を大幅に簡略化し、ユーザが迷惑電話を通報するのに極めて便利を提供し、関係部門が迷惑電話を整備する効率を高め、ユーザの体験感を大幅に強化する。
【0038】
以上の様々な方法のステップ区分は、明確に説明するためのものに過ぎず、実現時に1つのステップに統合されてもよく、又は、いくつかのステップを区分し、複数のステップに区分してもよく、同じ論理関係を含む限り、本特許の保護範囲内にある。アルゴリズム又はフローに重要ではない修正を加えたり、重要ではない設計を導入したりするが、そのアルゴリズムとフローのコア設計を変更しない限り、該特許の保護範囲内にある。
【0039】
本願の別の実施例は、端末に応用できる迷惑電話通報方法に関する。本実施例では、第1予め設定されたインタフェースは、通話記録インタフェースである。ユーザによる、通話記録インタフェースに配置される予め設定されたコントロールの予め設定された操作を検出した後に、第3予め設定されたインタフェースにジャンプすることをさらに含む。ここで、前記第3予め設定されたインタフェースは、ユーザがチェックするために、迷惑電話タイプの情報を含む。生成された通報メッセージは、ユーザがチェックした迷惑電話タイプの情報をさらに運ぶ。また、通報メッセージを指定される通報受付センターに送信した後に、ユーザ命令に基づいて通報受付センターにおいて前記通報メッセージの処理進捗状況をリアルタイムにクエリすることをさらに含む。本実施例では、ユーザは、通報動作の終了後に通報受付センターにおいて通報メッセージの処理進捗状況をリアルタイムにクエリすることができる。これは、ユーザが迷惑電話を通報するのに極めて便利を提供し、関係部門が迷惑電話を整備する効率を高め、端末ユーザの体験感と競争力を大幅に強化する。
【0040】
以下、本実施例における迷惑電話通報方法の実現詳細について具体的に説明する。以下の内容は本態様の実現詳細を容易にするためのものに過ぎず、本態様を実施するために必要ではない。具体的なフローは
図2に示すように、以下のステップを含んでもよい。
【0041】
ステップ201:通話相手側から送信されたデータ情報を受信する。
【0042】
電話に出てから、通話相手側から送信されたデータ情報を受信するまでの過程は、実施例のステップ101~104と同じであり、ここでこれ以上説明しない。受信終了後、ステップ202に入る。
【0043】
ステップ202:ユーザ又は通話相手側は、電話を切る。ユーザ又は通話相手側が電話を切った後、ステップ203に入る。
【0044】
ステップ203:第1予め設定されたインタフェースにジャンプした後に、第1予め設定されたインタフェースにおいてユーザの予め設定された操作を検出したか否かを判定する。
【0045】
具体的には、ユーザ又は通話相手側が電話を切った後、端末は、自動的に第1予め設定されたインタフェースに戻る。本実施例における第1予め設定されたインタフェースは、通話記録インタフェースであり、通話記録インタフェースに予め設定されたコントロールが表示される。本実施例に係る通話は、セッション形式で表示されるため、ユーザが電話を切っても、ユーザは、通話双方から送信されたテキスト、画像、音声ビデオなどのデータ情報を見ることができる。セッション形式は、ユーザが通話インタフェース又は通話記録インタフェースにおいて通話双方から送信されたテキスト、画像、音声ビデオなどのデータ情報をいつでも見ることができることを確保することができ、ユーザが電話を切った後に、通話双方から送信されたデータ情報をみることができない状況が生じない。
【0046】
第1予め設定されたインタフェースにおいてユーザの予め設定された操作を検出したか否かを判定する過程は、上記ステップ105と同じであり、ここでこれ以上説明しない。ユーザが第1予め設定されたインタフェースにおいて予め設定された操作を行ったことを検出すると、ステップ204に入り、検出していないと、終了する。
【0047】
ステップ204:検出すると、第3予め設定されたインタフェースに「迷惑電話タイプ」を含む情報を生成し、そうではないと、終了する。
【0048】
具体的には、ユーザ又は通話相手側が電話を切った後、第1予め設定されたインタフェースに「通報」ボタンが表示される。ユーザは、デフォルトで又は自分の状況に応じて提供する必要があるデータ情報をチェックした後に、通報ボタンをクリックして該迷惑電話を通報してもよい。ユーザが「通報」ボタンをクリックした後に、第3予め設定されたインタフェースにジャンプして、メッセージ通報命令を自動的に生成する。ここで、ユーザが該迷惑電話のタイプを選択するために、第3予め設定されたインタフェースに「迷惑電話タイプ」を含む情報を生成する。選択できるタイプは、当選詐欺、金融系詐欺、警察・検察・裁判所のなりすまし、リーダーのなりすまし、ネット通販系詐欺、その他がある。上記タイプは、すべての迷惑電話のタイプを含み、ユーザによるタイプの選択により、サーバー側の処理をより正確にすることができる。
【0049】
ここで、迷惑電話タイプを含む情報を生成する第3予め設定されたインタフェースは、
図3に示す。
【0050】
迷惑電話タイプを含む情報を生成する第3予め設定されたインタフェースの命令は、以下のとおりである。
<?xml version="1.0" encoding="UTF-8"?>
<SR xmlns="urn:gsma:params:xml:ns:rcs:rcs:spamreport">
<Chatbot>12321@botplatform.rcs.botspam</Chatbot>
<Message-ID>xxxx</Message-ID>
<Type>当選詐欺</Reason>
</SR>
【0051】
ステップ205:通報メッセージを自動的に生成する。
【0052】
通報メッセージを自動的に生成する過程は、ステップ105と同じであり、ここでこれ以上説明しない。本実施例における通報メッセージは、一部のデータ情報を運ぶほか、ユーザがチェックした迷惑電話タイプの情報をさらに運ぶ。
【0053】
ステップ206:ユーザ「送信」命令を検出した後に、自動的に生成された通報メッセージを指定される通報受付センターに送信する。
【0054】
ステップ207:指定される通報受付センターに通報メッセージと迷惑情報タイプを送信した後に、通報受付センターにおいて通報メッセージの処理進捗状況をリアルタイムに見る。
【0055】
ステップ208:指定される通報受付センターに通報メッセージと迷惑情報タイプを送信した後に、通報受付センターにデータ情報を提出することを継続する。
【0056】
本実施例では、ステップ207とステップ208の優先順位を制限せず、ステップ207を実行してからステップ208を実行するか、又はステップ207を実行してからステップ208を実行するかは、その具体的な実現に影響を与えない。
【0057】
本実施例による迷惑電話通報方法では、ユーザが通報ボタンをクリックした後に、ユーザがチェックした迷惑電話タイプをさらに運ぶ通報メッセージを自動的に生成することができる。ユーザは、ポップアップしたインタフェースに必要に応じてそのタイプをチェックすればよい。端末は、通報メッセージを通報受付センターに送信した後に、さらにユーザの必要に応じて通報受付センターとインタラクションを行ってもよく、例えば通報メッセージの処理進捗状況をクエリし、データ情報の提出などを継続する。この方法は、ユーザが迷惑電話を通報する過程を大幅に簡略化した上で、通報メッセージの処理進捗状況を見る及びテキスト、画像、音声ビデオなどの証拠を提供することができるプラットフォームを提供する。これにより、ユーザは、通報動作の終了後でも、通報受付センターとインタラクションを行うことができ、ユーザが迷惑電話を通報するのに極めて便利を提供し、関係部門が迷惑電話を整備する効率を高め、端末ユーザの体験感と競争力を大幅に強化する。
【0058】
また、以上の実施例では、ユーザ通報命令を検出した後に、まず第2予め設定されたインタフェースにジャンプし、ユーザが提供する必要があるデータ情報をチェックした後に、第3予め設定されたインタフェースにジャンプして迷惑電話タイプをチェックしてもよく、まず第3予め設定されたインタフェースにジャンプして迷惑電話タイプをチェックしてもよい。
【0059】
第2予め設定されたインタフェースにジャンプするステップと、第3予め設定されたインタフェースにジャンプするステップとの順序については、本願では制限しない。
【0060】
また、以上の実施例における通報受付センターの形態は、ウイチャットの公式アカウント、ウィジェット、ウェブページなどであってもよい。すなわち、通報受付センターがユーザに表示する具体的な形態については、本願では制限しない。
【0061】
以上の様々な方法のステップ区分は、明確に説明するためのものに過ぎず、実現時に1つのステップに統合されてもよく、又は、いくつかのステップを区分し、複数のステップに区分してもよく、同じ論理関係を含む限り、本特許の保護範囲内にある。アルゴリズム又はフローに重要ではない修正を加えたり、重要ではない設計を導入したりするが、そのアルゴリズムとフローのコア設計を変更しない限り、該特許の保護範囲内にある。
【0062】
上記問題を解決するために、本願は、端末をさらに提供する。
図4に示すように、該端末は、通話相手側から送信されたデータ情報を受信するための受信モジュール401と、ユーザの通報命令を検出した後に、少なくとも一部の前記データ情報が運ばれた通報メッセージを自動的に生成するための生成モジュール402と、前記通報メッセージを指定される通報受付センターに送信するための送信モジュール403とを含む。
【0063】
1つの例では、生成モジュール402は、具体的には、ユーザによる、第1予め設定されたインタフェースに配置される予め設定されたコントロールに対する予め設定された操作を検出した後に、通報メッセージを自動的に生成するために用いられる。
【0064】
1つの例では、第1予め設定されたインタフェースは、通話インタフェース又は通話記録インタフェースを含む。
【0065】
1つの例では、生成モジュール402は、さらに、ユーザによる、第1予め設定されたインタフェースに配置される予め設定されたコントロールに対する予め設定された操作を検出した後に、第2予め設定されたインタフェースにジャンプするために用いられる。前記第2予め設定されたインタフェースは、ユーザがチェックするために、通話相手側から送信されたデータ情報を含む。ユーザが前記第2予め設定されたインタフェースに含まれるデータ情報をチェックしたことを検出すると、前記チェックされたデータ情報を運ぶ通報メッセージを自動的に生成する。
【0066】
1つの例では、生成モジュール402は、さらに、前記の、ユーザによる、第1予め設定されたインタフェースに配置される予め設定されたコントロールに対する予め設定された操作を検出した後に、第3予め設定されたインタフェースにジャンプするために用いられる。前記第3予め設定されたインタフェースは、ユーザがチェックするために、迷惑電話タイプの情報を含む。生成された通報メッセージは、チェックされた前記迷惑電話タイプの情報をさらに運ぶ。
【0067】
1つの例では、送信モジュール403は、さらに、前記通報メッセージを指定される通報受付センターに送信した後に、ユーザ命令に基づいて通報受付センターにおいて前記通報メッセージの処理進捗状況をリアルタイムにクエリするために用いられる。
【0068】
本実施形態は、上記端末に応用される方法の実施例に対応する装置の実施例である。本実施形態は、上記端末に応用される方法の実施例と相互に組み合わせて実施することができる。上記端末に応用される方法の実施例に記載された関連技術の詳細は、本実施形態においても有効であり、繰り返しを減らすために、ここではこれ以上説明しない。したがって、本実施形態で言及された関連技術の詳細は、上記端末に応用される方法の実施例にも応用してもよい。
【0069】
なお、本願の上記2つの実施例に係る各モジュールはすべて論理モジュールであり、実際の応用において、1つの論理ユニットは1つの物理ユニットであってもよく、1つの物理ユニットの一部であってもよく、また複数の物理ユニットの組み合わせで実現されてもよい。また、本願の革新的な部分を強調するために、本願による技術的課題を解決するのにあまり密接な関係がないユニットは本実施形態には導入されていないが、これは本実施形態に他のユニットが存在しないことを示しているわけではない。
【0070】
本願の実施例は、電子機器をさらに提供する。
図5に示すように、該電子機器は、少なくとも1つのプロセッサ501と、前記少なくとも1つのプロセッサに通信可能に接続されるメモリ502とを含む。前記メモリ502に前記少なくとも1つのプロセッサ501により実行可能な命令が記憶されており、前記命令が前記少なくとも1つのプロセッサ501により実行され、前記少なくとも1つのプロセッサ501が上記端末用の迷惑電話通報方法を実行することができ、又は上記端末用の迷惑電話通報方法を実行することができる。
【0071】
メモリとプロセッサはバス方式で接続される。バスは、いずれかの数の相互接続されたバスとブリッジを含んでもよく、バスは1つ以上のプロセッサとメモリの様々な回路を接続する。バスはまた、周辺機器、電圧レギュレータ、電力管理回路などの様々な他の回路を接続してもよく、これらは当技術分野で知られているため、本明細書ではこれ以上説明しない。バスインタフェースは、バスと送受信機の間にインタフェースを提供する。送受信機は、1つの要素であってもよいし、複数の受信機や送信機などの複数の要素であってもよく、送信媒体上で様々な他の装置と通信するための手段を提供する。プロセッサによって処理されたデータは、アンテナを介して無線媒体上で送信され、さらに、アンテナはデータを受信してプロセッサに送信する。
【0072】
プロセッサはバスの管理と通常の処理を担当し、タイミング、周辺インタフェース、電圧調整、電源管理、その他の制御機能を含むさまざまな機能を提供することができる。メモリは、プロセッサが操作を実行する時に使用されるデータを記憶するために用いることができる。
【0073】
上記製品は、本願の実施例による方法を実行することができ、実行方法に対応する機能モジュールと有益な効果を備える。本実施例で詳細に説明されていない技術的詳細は、本願の本実施例による方法を参照することができる。
【0074】
12321サイトにアクセスしてユーザ情報、通報が必要な情報などの様々な情報を記入する必要がある態様に比べて、本願の実施例による迷惑電話通報方法は、ユーザの通報命令に基づいて、少なくとも一部のデータ情報を運ぶ通報メッセージを自動的に生成し、通報メッセージを指定される通報受付センターに送信することができる。この過程でユーザは、ユーザ情報、通報が必要な電話番号及び詳細な情報などを記入する必要がなく、ユーザが迷惑電話を通報する過程を大幅に簡略化する。それにより、ユーザが迷惑電話を通報するのに極めて便利を提供し、関係部門が迷惑電話を整備する効率を高め、ユーザの体験感を大幅に強化する。
【0075】
上記実施例の方法を実現するためのすべて又は一部のステップは、プログラムによって関連するハードウェアを命令して実行してもよい。該プログラムは、1つの機器(シングルチップ、チップなどであってもよい)又はプロセッサ(processor)が本願の各実施例に記載された方法のすべて又は一部のステップを実行するためのいくつかの命令を含む記憶媒体に格納される。前述の記憶媒体は、Uディスク、リムーバブルハードディスク、読み取り専用メモリ(現在ROM、Read-Only Memoryを満たしているかどうか)、ランダムアクセスメモリ(RAM、Random Access Memory)、磁気ディスク、又は光ディスクなど、プログラムコードを記憶できる15種類の媒体を含む。
【0076】
上記実施例は、本願を実現し、使用するために当業者に提供されるものである。当業者は、本願の発明思想から逸脱した場合に、上記実施形態に種々の修正又は変更を加えることができるので、本願の保護範囲は上記実施形態に限定されるものではなく、特許請求の範囲に記載された革新的な特徴の最大範囲に適合すべきである。
【手続補正書】
【提出日】2023-10-06
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
通話相手側から送信されたデータ情報を受信するステップと、
ユーザの通報命令を検出すると、少なくとも一部の前記データ情報が運ばれた通報メッセージを自動的に生成するステップと、
前記通報メッセージを指定される通報受付センターに送信するステップとを含む、迷惑電話通報方法。
【請求項2】
ユーザの通報命令を検出する前記ステップは、
ユーザによる、第1予め設定されたインタフェースに配置される予め設定されたコントロールに対する予め設定された操作を検出するステップを含む、請求項1に記載の迷惑電話通報方法。
【請求項3】
前記第1予め設定されたインタフェースは、
通話インタフェース又は通話記録インタフェースを含む、請求項2に記載の迷惑電話通報方法。
【請求項4】
ユーザによる、第1予め設定されたインタフェースに配置される予め設定されたコントロールに対する予め設定された操作を検出した後に、第2予め設定されたインタフェースにジャンプするステップをさらに含み、前記第2予め設定されたインタフェースは、通話相手側から送信されたデータ情報を含む、請求項2に記載の迷惑電話通報方法。
【請求項5】
通報メッセージを自動的に生成する前記ステップは、
前記ユーザが前記第2予め設定されたインタフェースに含まれるデータ情報をチェックしたことを検出すると、チェックされたデータ情報を運ぶ通報メッセージを自動的に生成するステップを含む、請求項4に記載の迷惑電話通報方法。
【請求項6】
ユーザによる、第1予め設定されたインタフェースに配置される予め設定されたコントロールに対する予め設定された操作を検出した後に、
第3予め設定されたインタフェースにジャンプするステップをさらに含み、
前記第3予め設定されたインタフェースは、迷惑電話タイプの情報を含み、
前記生成された通報メッセージは、チェックされた前記迷惑電話タイプの情報をさらに運ぶ、請求項2に記載の迷惑電話通報方法。
【請求項7】
前記通報メッセージを指定される通報受付センターに送信した後に、
ユーザ命令に基づいて通報受付センターにおいて前記通報メッセージの処理進捗状況をリアルタイムにクエリするステップをさらに含む、請求項
1に記載の迷惑電話通報方法。
【請求項8】
通話相手側から送信されたデータ情報を受信するための受信モジュールと、
ユーザの通報命令を検出した後に、少なくとも一部の前記データ情報が運ばれた通報メッセージを自動的に生成するための生成モジュールと、
前記通報メッセージを指定される通報受付センターに送信するための送信モジュールとを含む、端末。
【請求項9】
少なくとも1つのプロセッサと、
前記少なくとも1つのプロセッサに通信可能に接続されるメモリとを含む電子機器であって、
前記メモリには、前記少なくとも1つのプロセッサにより実行されると、請求項1~7のいずれか1項に記載の迷惑電話通報方法を前記少なくとも1つのプロセッサに実行させる、前記少なくとも1つのプロセッサにより実行可能な命令が記憶されている、電子機器。
【請求項10】
プロセッサにより実行されると、請求項1~7のいずれか1項に記載の迷惑電話通報方法を実現するコンピュータプログラムが記憶されている、コンピュータ読み取り可能な記憶媒体。
【国際調査報告】