具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

本公开实施例首先提供一种数据处理方法，如图1所示，包括：

步骤S11：获取目标耳机端的上行音频数据和下行音频数据；

步骤S12：根据上行音频数据和下行音频数据，生成设定格式的合并数据；

步骤S13：将合并数据发送给指定接收端。

本实施例中，步骤S11-S13可以在耳机端执行，具体可以按照设定的周期在通话过程中循环执行。

本实施例中，目标耳机端可以是用户的左右耳机中任意耳机的数据处理端，也可以是为双侧耳机专门设置的数据处理端，也可以是独立生产出售的单侧耳机的数据处理端，也可以是成对出售的无线可分离的左右耳机中的任意耳机的数据处理端，还可以是头戴式耳机、或有线连接的双耳机的任意数据处理端，还可以是任意一种具有麦克风和扬声器的电子产品的数据处理端。

本实施例中，上行音频数据可以是通过麦克风接收到的、用于发送的音频数据。

进一步的，上行音频数据可以是单独的音频数据，也可以是视频通话中的音频数据或者视频文件中的音频数据。

本实施例中，下行音频数据可以是通过扬声器接收或播放的、用于目标耳机端的用户收听的音频数据。

进一步的，下行音频数据可以是单独音频数据，也可以是视频通话中的音频数据或者视频文件中的音频数据。

本实施例中，获取目标耳机端的上行音频数据和下行音频数据，可以是通过目标耳机端获取上行音频数据和下行音频数据，也可以是获取经由目标耳机端传输的音频数据。

在一种具体实现方式中，上行音频数据和下行音频数据中，可以存在空数据，即在通话场景下，呼叫方和被呼叫方之中长时间内仅有一方传输语音，则对应的，下行音频数据或上行音频数据在较长时间内可以为空数据。比如，在播放音频或视频文件的场景下，仅存在下行音频数据，上行音频数据为空。

在另一种具体实现方式中，获取目标耳机端的上行音频数据和下行音频数据，可以是获取目标耳机端的上行音频数据和下行音频数据中的至少一个，比如，在仅获取到上行音频数据的情况下，也可认为完成了获取目标耳机端的上行音频数据和下行音频数据的步骤。在仅获取到下行音频数据的情况下，也可认为完成了获取目标耳机端的上行音频数据和下行音频数据的步骤。

在另一种情况下，若获取目标耳机端的上行音频数据和下行音频数据时，由于音频通话一方说话时间过长，导致在有限的采集时间内，仅获取到上行音频数据或下行音频数据，则也可认为是完成了获取目标耳机端的上行音频数据和下行音频数据的步骤。

在一种具体的实现方式中，根据上行音频数据和下行音频数据，生成设定格式的合并数据，可以是将上行音频数据和下行音频数据进行直接合并，得到合并的音频数据作为合并数据。

在因为采集周期内仅采集到上行音频数据和下行音频数据之一的情况下，可以将单独的上行音频数据或下行音频数据作为合并数据，也可以将采集到的上行音频数据和下行音频数据之一与空音频数据合并为合并数据。

根据上行音频数据和下行音频数据，生成设定格式的合并数据，还可以是将上行音频数据和下行音频数据中的至少一种进行处理，将处理后的上行音频数据和下行音频数据进行合并。比如，可以将上行音频数据或下行音频数据进行压缩，将压缩后的上行音频数据和未压缩的下行音频数据、或未压缩的上行音频数据和压缩后的下行音频数据、或压缩后的上行音频数据以及下行音频数据进行合并，得到合并数据。

本实施例中，合并数据可以是能够独立发送的数据。

本实施例中，指定接收端可以是与耳机相连的终端，比如，手机端、台式电脑端、笔记本电脑端、平板电脑端、智能可佩带设备端等等。

在一种实现方式中，将合并数据发送给指定接收端，可以是将合并数据压缩后发送给指定接收端。

合并数据发送给指定接收端，还可以是按照设定的传输方式将合并数据发送给指定终端，比如，通过蓝牙传输、NFC(Near Field Communication，进场通信)传输、DMA(Direct Memory Access，直接存储器访问)协议传输等方式，将合并数据发送给指定终端。还可以是通过其它双方认可的协议进行合并数据的传输。

本实施例中，能够将在目标耳机端接收到的上行音频数据和下行音频数据转化为合并数据，将合并数据发送给指定接收端，从而能够使得其它接收端接收到上行音频数据和下行音频数据(或二者至少之一)，从而对上行音频数据和下行音频数据(或二者至少之一)进行音频处理。在目标耳机端为单个耳机的数据处理端的情况下，只需要一个耳机端即可实现合并数据的收发，使得音频数据的处理不受用户佩戴单个耳机或双耳机的具体情况的影响。

本公开一种示例中，数据处理方法可应用于解决智能真无线(TWS，True WirelessStereo)耳机的语音通话使用场景。

具体而言，本公开实施例可用于在采用TWS等耳机时，将通话的音频转录为文字的过程中从耳机端采集通话音频。从而可以方便地实现以文字为载体记录通话双方的通话内容，以及事后的查阅和分享。

在智能真无线耳机通话使用场景中，如何将上行和下行两路音频数据从耳机端传给手机端可以采用多种不同的方法。其中一种方法可以是，将左耳机和右耳机对应的数据处理端作为目标耳机端，将两路音频分别在主耳机和从耳机上采集、压缩，再将压缩后的音频帧的头部加上各自streamID(流识别码)。主耳机可以是左右耳机中的一个，从耳机可以是左右耳机中的另一个。从耳机将加工处理过的数据通过两耳之间的TWS连接传给主耳机，主耳机将本端的音频数据和从耳机的音频数据统一发送给手机等用户终端。手机等用户终端通过streamID来区分上行音频数据和下行音频数据，并将收到的音频数据发送给云端进行识别或文字转换等操作。

本实施例中，可通过APP(Application，应用)设置耳机的通话转写模式，从而在该模式下执行本公开实施例的数据处理方法。同时，通过APP还能够随时开启和关闭通话转写功能，相应停止或开始执行本公开实施例提供的数据处理方法。

在其它具体实施例中，可设置用户自由选择双耳机采集音频或单耳机采集音频，从而，在一些情况下(比如电量即将耗尽但需要记录对方的重要讲话)时，可采用单个耳机仅执行采集、传输上行音频数据或下行音频数据的操作。

在其它实现方式中，本公开实施例还可应用于单方录音等与耳机的麦克风功能或扬声器功能有关的活动中。

在一种实施方式中，获取目标耳机端的上行音频数据和下行音频数据，包括：

获取目标耳机端的麦克风接收到的音频数据，作为上行音频数据；

获取目标耳机端的扬声器数据，作为下行音频数据。

可以理解，获取上行音频数据的步骤和获取下行音频的步骤，可同时执行，也可以按照任意先后顺序分别执行。

本实施例中，目标耳机端的扬声器数据，可以是目标耳机端接收到的其它端发送的参考数据，也可以是目标耳机端因为播放音频给用户而产生的数据。

目标耳机端的麦克风接收到的音频数据，可以是与目标耳机端存在连接关系的麦克风接收到的音频数据，也可以是目标耳机端自身的麦克风采集到的音频数据。

本实施例中，通过麦克风和扬声器分别获取上行音频数据和下行音频数据，从而便于对音频数据进行合并发送。在目标耳机端为左耳机对应的数据处理端或右耳机对应的数据处理端的情况下，能够在单独的耳机端上完成需要转换文字的音频数据的收集，进而在用户仅使用一个耳机的情况下，也能够实现文字转换功能。且若在单独的耳机端上进行上行音频数据和下行音频数据的获取，还能够尽量减少数据传输，降低对耳机的性能的要求。

在一种实施方式中，根据上行音频数据和下行音频数据，生成设定格式的合并数据，包括：

将上行音频数据和下行音频数据进行交错合并，获取合并数据。

在另一种实现方式中，也可将上行音频数据和下行音频数据进行前后拼接，在拼接处设置可识别记号，以区分两个不同的音频数据。也可以在上行音频数据和下行音频数据中至少之一的起止位置处添加开始和/或结束符号，然后将二者进行前后拼接。

在其它实现方式中，还可采用两种以上的合并方式，可以选择在合并数据中添加信号以区别不同的合并方式，从而实现耳机高能耗高性能、低能耗低性能等多种处理音频数据的模式。

本实施例中，将上行音频数据和下行音频数据进行交错合并，从而生成一个音频数据，在后续压缩发送时，只需生成一个压缩和发送实例，降低多耳机端的处理器的数据处理性能要求。

在一种实施方式中，将上行音频数据和下行音频数据进行交错合并，包括：

按照单个音频帧依次相邻交错设置的方式，合并上行音频数据和下行音频数据。

在一种具体实现方式中，一个音频帧可以包括16bit(比特)的音频数据，因此，可采用例如表1的方式组织合并数据的结构，使得合并数据包括单帧交错设置的上行音频数据和下行音频数据。

表1

在其它实现方式中，可以按照两个音频帧依次相邻交错设置的方式，合并上行音频数据和下行音频数据。

在其它实现方式中，可以按照第一设定帧的上行音频数据+第二设定帧的下行音频数据进行上行音频数据和下行音频数据的交错合并。

本实施例中，按照单个音频帧依次相邻交错设置的方式对上下行音频数据进行合并，从而能够实现将两份音频数据作为一份音频数据发送，节省与发送操作相关的实例(比如压缩示例)的个数，降低对目标耳机端的性能的要求。

在一种实施方式中，目标耳机端为左耳机端和右耳机端之一。

在一种具体的实现方式中，左耳机端和右耳机端可以为无线耳机或智能耳机的左耳机端和右耳机端。

左耳机端和右耳机端还可以为有线连接的两个耳机端。

本实施例中，左耳机端可以是佩戴于用户左耳的耳机的数据处理端；右耳机端可以是佩戴于用户右耳的耳机的数据处理端。

本实施例中，目标耳机端为单个耳机的数据处理端，从而，减少数据在两个耳机端之间的传输步骤，且在用户使用单个耳机的情况下，也能够实现将上下行音频数据发送至指定接收端，进行音频转换文字或者其它操作。

在一种实施方式中，如图2所示，数据处理方法还包括：

步骤S21：获取左耳机和右耳机的位置信息；

步骤S22：根据左耳机和右耳机的位置信息，确定左耳机和右耳机中处于被佩戴以及使用状态的主耳机；

步骤S23：将主耳机对应的耳机端作为目标耳机端。

左耳机和右耳机，可以分别是用于佩戴于人体左耳和右耳的耳机。

左耳机和右耳机的位置信息，可以是左耳机和右耳机的物理位置信息，比如，左耳机是否被佩戴于人耳、右耳机是否被佩戴于人耳等。

本实施例中，处于被佩戴状态，可以是被佩戴于人耳的状态。处于使用状态可以是处于在传输音频的状态。

主耳机可以是左耳机和右耳机中的一个。

主耳机对应的耳机端，可以是主耳机对应的耳机数据处理端。

本实施例中，将主耳机对应的耳机端作为目标耳机端，从而上行音频数据和下行音频数据通过单个耳机进行收集、合并以及传输，避免在单独佩戴耳机时，音频传输功能不可用的情况，且可以相比双耳机收集音频数据减少数据的传输次数。

在其它实施方式中，也可以只根据耳机是否处于被佩戴状态，确定左右耳机中的主耳机。

在其它实现方式中，也可以将从耳机对应的耳机端作为目标耳机端。

在一种实施方式中，根据左耳机和右耳机的位置信息，确定左耳机和右耳机中处于被佩戴以及使用状态的主耳机，包括：

在根据位置信息确定，左耳机和右耳机中，仅有一个耳机处于被佩戴状态的情况下，确定处于被佩戴和使用状态的耳机为主耳机；

或，在根据位置信息确定，左耳机和右耳机均处于被佩戴状态的情况下，确定处于使用状态的耳机为主耳机；

或，在根据位置信息确定，左耳机和右耳机均处于被佩戴的情况下，按照默认设置，确定两个处于使用状态的耳机之一主耳机。

在其它实现方式中，也可仅根据耳机位置，确定主耳机。比如，在两个耳机均被佩戴的情况下，可按照默认设置，确定主耳机。在两个耳机中只有一个耳机被佩戴的情况下，可确定被佩戴的耳机为主耳机。

本实施例中，根据被佩戴和使用状态确定左耳机和右耳机中的主耳机，从而能够自动识别用户是否使用耳机，能够在用户只佩戴一个耳机、或者一只耳机功能异常的情况下，准确确定能够进行上下行音频获取以及合并发送的耳机，更好地配合用户的使用。

在一种实施方式中，将合并数据发送给指定接收端，包括：

将合并数据进行压缩，将压缩后的合并数据发送给指定接收端。

本实施例中，将合并数据进行压缩，可以是将上行音频数据和下行音频数据合并为一个音频数据作为合并数据，将合并数据进行压缩。

将压缩后的合并数据发送给指定接收端，从而，能够节省目标耳机端和指定接收端之间的信息传输带宽，同时，对合并数据进行压缩，仅启动一个压缩实例即可，相比分别压缩，减少了压缩实例的个数。

本公开实施例还提供一种数据处理方法，如图3所示，包括：

步骤S31：接收合并数据，合并数据为本公开任意一项实施例中生成的合并数据；

步骤S32：按照设定格式，将合并数据分解为上行音频数据和下行音频数据；

步骤S33：将上行音频数据和下行音频数据发送至云端音频处理模块。

本实施例中，合并数据可以是目标耳机端发送的合并数据，可以是压缩格式的合并数据。

在将合并数据分解为上行音频数据和下行音频数据之前，可以对压缩后的合并数据进行解压。

按照设定格式，将合并数据分解为上行音频数据和下行音频数据，可以是按照上行音频数据和下行音频数据进行合并的时候的合并方式，进行拆分，将合并数据分解为上行音频数据和下行音频数据。

设定格式可以是指定接收端与目标耳机端进行约定的格式。比如，如果按照单个音频帧依次相邻交错设置的方式对上下行音频数据进行合并，则将单数音频帧提取出来，作为上行音频数据和下行音频数据之一，将双数音频帧提取出来作为上行音频数据和下行音频数据之另一。

本实施例中，步骤S31-S33可以在合并数据的指定接收端执行，也可在云端执行。即，可以在云端执行合并数据拆分为上行音频数据和下行音频数据的操作。

在终端执行拆分操作时，终端可以对音频数据进行分析判断，当识别出上行音频数据或下行音频数据为空时，可只发送不为空的音频数据。

指定接收端可以是手机等用户终端。

云端音频处理模块，可以用于将上行音频数据和下行音频数据中的至少一部分音频数据转换为文字或者其它用户所需要的信息。

本实施例中，将合并数据按照设定格式拆分为上行音频数据和下行音频数据，将拆分后的上下行音频数据发送至云端音频处理模块，从而能够将音频转化为文字等用户所需要的信息。

在一种实施方式中，数据处理方法还包括：

接收云端音频处理模块根据上行音频数据和下行音频数据生成的转换文字信息。

本实施例中，根据上行音频数据和下行音频数据生成的转换文字信息，可以是根据上行音频数据和下行音频数据中的至少一部分音频生成的转换文字信息。

其它实施例中，还可以对上行音频数据和下行音频数据进行其它处理，比如，添加效果等。

本实施例中，在将上行音频数据和下行音频数据转换为文字的古城中，可以对需要转换的音频部分进行VAD(语音活动检测，Voice Activity Detection)、分帧处理，对分帧后的音频进行特征值提取，再将提取过特征值的音频帧识别为状态，由状态组成音素，最终将音素组成为单词，从而实现音频到文字的转换。

考虑到语音识别过程中不但可以使用声学模型将音频帧转化为状态，而且还可以构建状态网络，在状态网络中为声音寻找一条最匹配的路径。因此，语音识别处理、转换为文字可能需要大量的算力和内存。从而，在本公开实施例中，可以将这类复杂的语音识别处理放到云端来做，而具有有限能力的用户终端可以只为云端提供VAD后的音频或原始音频。

本实施例中，可将接收到的转换文字信息显示在指定终端的显示界面，或者将转换文字信息存储于文档、记事本等文件中，供用户查看。

在本公开一种示例中，数据处理方法包括图4所示的步骤：

步骤S41：通话过程中的上行音频数据和下行音频数据的采集。

本公开示例中，可只在单只主耳机上来采集通话过程中的上行音频数据和下行音频数据。为了采集到上行音频数据，可以在主耳机的麦克风(Micphone)上传数据链路的某一处获取一份上行数据的拷贝数据，作为本示例中在单只主耳机上采集到的上行音频数据。为了获取通话的下行数据，则可以使用主耳机的参考数据。为了处理方便，获取下行数据的位置和获取上行数据的位置一致，即在耳机软件模块的同一位置处截取上行音频数据和下行音频数据。

本示例中，通过只在单主耳上获取通话的上行音频数据和下行音频数据，从而即使在单耳通话场景中也能完成用于通话转写等功能的音频采集任务，扩展了通话转写功能的使用场景。

步骤S42：数据压缩。

本示例中，在采集到通话过程中的上行音频数据和下行音频数据后，可以数据进行压缩。在具体实现过程中，可采用多种适当的方式进行音频数据压缩。在本示例中，可采用Opus压缩方法对上行音频数据和下行音频数据进行压缩。本示例中使用的Opus压缩方法，是一个有损声音编码的格式，由Xiph.Org基金会开发，之后由IETF(互联网工程任务组)进行标准化，目标是希望用单一格式包含声音和语音，取代Speex和Vorbis，且适用于网络上低延迟的即时声音传输，标准格式定义于RFC 6716文件。

本示例中，可以采用统一压缩的方式进行压缩，将上行音频数据和下行音频数据按交错的方式组音频帧，生成合并数据，然后再对合并数据中的每一帧进行压缩。使用统一的压缩方式，只需要开启一路压缩实例即可实现音频数据的压缩，既减少了实现压缩的杂度，也减少了压缩算法对耳机MCU(Micro Controller Unit，微处理器)的计算能力要求。

在其它实现方式中，也可以采用分别压缩的方式进行上行音频数据和下行音频数据的分别压缩。在分别压缩过程中，为每路数据开启一个压缩实例，分别压缩两路数据。

步骤S43：音频数据传输。

为了实现将耳机采集到的通话过程中的上行音频数据和下行音频数据最终传输到到云端，可采用DMA协议将压缩后的双路通话数据传输给手机等指定接收端。手机等指定接收端收到压缩的音频数据后进行解压，并将解压后的数据恢复为上行音频数据和下行音频数据，使用无线网络或有线网络将上行音频数据和/或下行音频数据传送至云端。

云端收到上行音频数据和/或下行音频数据后，进行语音识别，并将识别到的文字或者其它识别结果返还给手机等指定终端。最终识别出的文字将呈现在通话APP中进行呈现。

在本公开一种示例中，数据处理方法如图5所示，包括：

步骤S51：在目标耳机端采集语音或视频通话过程中的上行音频数据和下行音频数据，并将采集到的音频数据进行交错合并，将合并数据进行压缩。

步骤S52：通过DMA协议将压缩后的合并数据发送至指定终端。指定终端比如可以是手机等。合并数据可通过近距离传输的方式，从目标耳机端传输到指定接收端。

步骤S53：通过有线网络或无线网络，将根据压缩后的合并数据得到的上行音频数据和下行音频数据传输到云端。

步骤S54：在云端对上行音频数据和下行音频数据进行转换。具体而言，可转换为文字。

步骤S55：在指定的APP显示界面或者其它指定显示界面上显示转换结果。

本公开实施例还提供一种数据处理装置，如图6所示，包括：

获取模块61，用于获取目标耳机端的上行音频数据和下行音频数据；

合并模块62，用于根据上行音频数据和下行音频数据，生成设定格式的合并数据；

发送模块63，用于将合并数据发送给指定接收端。

在一种实施方式中，如图7所示，获取模块包括：

上行单元71，用于获取目标耳机端的麦克风接收到的音频数据，作为上行音频数据；

下行单元72，获取目标耳机端的扬声器数据，作为下行音频数据。

在一种实施方式中，如图8所示，合并模块还包括：

交错合并单元81，用于将上行音频数据和下行音频数据进行交错合并，获取合并数据。

在一种实施方式中，交错合并单元还用于：

按照单个音频帧依次相邻交错设置的方式，合并上行音频数据和下行音频数据。

在一种实施方式中，目标耳机端为左耳机端和右耳机端之一。

在一种实施方式中，如图9所示，数据处理装置还包括：

位置模块91，用于获取左耳机和右耳机的位置信息；

主耳机模块92，用于根据左耳机和右耳机的位置信息，确定左耳机和右耳机中处于被佩戴以及使用状态的主耳机；

目标耳机端模块93，用于将主耳机对应的耳机端作为目标耳机端。

在一种实施方式中，如图10所示，主耳机模块包括下述至少之一：

第一单元101，用于在根据位置信息确定，左耳机和右耳机中，仅有一个耳机处于被佩戴状态的情况下，确定处于被佩戴和使用状态的耳机为主耳机；

第二单元102，用于在根据位置信息确定，左耳机和右耳机均处于被佩戴状态的情况下，确定处于使用状态的耳机为主耳机；

第三单元103，用于在根据位置信息确定，左耳机和右耳机均处于被佩戴的情况下，按照默认设置，确定两个处于使用状态的耳机之一主耳机。

在一种实施方式中，如图11所示，发送模块还包括：

压缩单元111，用于将合并数据进行压缩；

执行单元112，用于将压缩后的合并数据发送给指定接收端。

本公开实施例还提供一种数据处理装置，如图12所示，包括：

接收模块121，用于接收合并数据，合并数据为本公开任意一项实施例所生成的合并数据；

分解模块122，用于按照设定格式，将合并数据分解为上行音频数据和下行音频数据；

转发模块123，用于将上行音频数据和下行音频数据发送至云端音频处理模块。

在一种实施方式中，如图13所示，数据处理装置还包括：

文字接收模块131，用于接收云端音频处理模块根据上行音频数据和下行音频数据生成的转换文字信息。

本公开实施例各装置中的各单元、模块或子模块的功能可以参见上述方法实施例中的对应描述，在此不再赘述。

本公开实施例涉及计算机技术领域，尤其涉及人工智能、语音技术等领域。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图14示出了可以用来实施本公开的实施例的示例电子设备140的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或要求的本公开的实现。

如图14所示，电子设备140包括计算单元141，其可以根据存储在只读存储器(ROM)142中的计算机程序或者从存储单元148加载到随机访问存储器(RAM)143中的计算机程序来执行各种适当的动作和处理。在RAM 143中，还可存储电子设备140操作所需的各种程序和数据。计算单元141、ROM 142以及RAM 143通过总线144彼此相连。输入输出(I/O)接口145也连接至总线144。

电子设备140中的多个部件连接至I/O接口145，包括：输入单元146，例如键盘、鼠标等；输出单元147，例如各种类型的显示器、扬声器等；存储单元148，例如磁盘、光盘等；以及通信单元149，例如网卡、调制解调器、无线通信收发机等。通信单元149允许电子设备140通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元141可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元141的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元141执行上文所描述的各个方法和处理，例如数据处理方法。例如，在一些实施例中，数据处理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元148。在一些实施例中，计算机程序的部分或者全部可以经由ROM 142和/或通信单元149而被载入和/或安装到电子设备140上。当计算机程序加载到RAM 143并由计算单元141执行时，可以执行上文描述的数据处理方法的一个或多个步骤。备选地，在其他实施例中，计算单元141可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行数据处理方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入、或者触觉输入来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。