CN115329286A - 一种投屏方法及电子设备 - Google Patents

Abstract

一种投屏方法及电子设备，涉及电子设备技术领域，可以降低电子设备投屏时的功耗。具体方案包括：响应于第一投屏操作，投屏发送端向投屏接收端发送包括目标DRM多媒体数据的下载地址的投屏指令，该目标DRM多媒体数据是对目标多媒体数据加密后的数据；投屏接收端接收来自投屏发送端的投屏指令，并根据目标DRM多媒体数据的下载地址从业务平台处获取目标DRM多媒体数据；投屏接收端通过投屏发送端获取目标DRM多媒体数据的授权信息，并根据该授权信息播放目标多媒体数据。

Description

一种投屏方法及电子设备

技术领域

本申请实施例涉及电子设备技术领域，尤其涉及一种投屏方法及电子设备。

背景技术

随着电子技术的发展，投屏技术得到广泛应用。投屏技术可以是指将电子设备(如手机、平板电脑等)上的多媒体数据(如视频、音频)投放到其他设备(如智能电视、智能投影仪)上进行播放。例如，将手机上的视频投放到智能电视上进行播放，这样用户就能在智能电视上浏览手机上的视频。

目前，出于对多媒体数据的版权保护，提供多媒体数据的业务平台仅允许被授予使用权限的账号(例如会员账号)才可以使用数字版权管理(digital rights management，DRM)多媒体数据。其中，DRM是一种用于管理被保护文件(例如图像、音频和视频等)的使用权的技术。但是，现有技术中电子设备将DRM多媒体数据投屏到其他设备上进行播放时，通常情况下，电子设备需要从提供多媒体数据的业务平台处获取DRM多媒体数据后进行解密，并将解密后的DRM多媒体数据进行投屏。由于DRM多媒体数据是在电子设备侧进行解密的，且电子设备还需要将解密的DRM多媒体数据投屏至其他设备，增加了电子设备的能耗。

发明内容

本申请提供一种投屏方法及电子设备，用以减少电子设备投屏时的能耗。

第一方面，本申请提供一种投屏方法，该方法可以包括：响应于第一投屏操作，投屏发送端向投屏接收端包括目标DRM多媒体数据的获取信息的投屏指令，该目标DRM多媒体数据是对目标多媒体数据加密后的数据；投屏接收端接收来自投屏发送端的投屏指令，并根据目标DRM多媒体数据的获取信息从业务平台处获取目标DRM多媒体数据；投屏接收端通过投屏发送端获取目标DRM多媒体数据的授权信息，并根据该授权信息播放目标多媒体数据。

基于本申请的技术方案，投屏发送端能够代理投屏接收端完成授权信息的获取以及鉴权。投屏接收端可以根据投屏发送端的投屏指令直接下载目标DRM多媒体数据。如此，投屏发送端无需下载目标DRM多媒体数据，相较于现有技术中，投屏发送端既要进行鉴权以及获取授权信息，又要下载DRM多媒体数据，本申请实施例提供的方案，由于投屏发送端无需下载DRM多媒体数据，因此，降低了投屏发送端的能耗。

结合第一方面，在一种可能的设计方式中，在投屏发送端向投屏接收端发送第一投屏指令之前，该方法还可以包括：投屏发送端向业务平台发送用于请求获取目标DRM多媒体数据的第一请求消息；业务平台在接收到来自投屏发送端的第一请求消息后，对投屏发送端进行鉴权；在投屏发送端鉴权通过的情况下，业务平台向投屏发送端发送目标DRM多媒体数据的获取信息。

基于该可能的实现方式，在投屏发送端鉴权成功的情况下，业务平台可以通过投屏发送端发送目标DRM多媒体数据的获取信息，避免了目标DRM多媒体数据被非法的设备获取。

结合第一方面，在另一种可能的设计方式中，投屏接收端通过投屏发送端向业务平台发送用于请求获取目标DRM多媒体数据的授权信息；业务平台接收来自投屏发送端的第二请求消息，并通过投屏发送端向投屏接收端发送目标DRM多媒体数据的授权信息。

基于该可能的实现方式，投屏接收端可以通过投屏发端获取授权信息，如此，投屏接收端无需安装提供目标DRM多媒体数据的应用程序，只需要投屏发送端安装有提供目标DRM多媒体数据的应用程序即可，扩大了DRM多媒体数据的投屏的应用范围。

结合第一方面，在另一种可能的设计方式中，第二请求消息包括投屏接收端的公钥，授权信息包括用于解密目标DRM多媒体数据的密钥；授权信息是为业务平台使用所述公钥对所述密钥进行加密得到。

基于该可能的实现方式，业务平台使用投屏接收端的公钥对目标DRM多媒体数据的解密密钥进行加密得到授权信息。防止其他设备在获取到该授权信息后，也无法对该授权信息进行解密，保证了目标多媒体数据的安全。

结合第一方面，在另一种可能的设计方式中，投屏接收端使用投屏接收端的私钥对授权信息进行解密，得到密钥，并使用该密钥对目标DRM多媒体数据进行解密，得到目标多媒体数据；投屏接收端播放该目标多媒体数据。

基于该可能的实现方式，投屏接收端可以使用自身的使用对该授权信息进行解密，进而可以得到目标DRM多媒体数据的解密密钥，并使用该解密密钥对目标DRM多媒体数据进行解密，得到可以播放的目标多媒体数据。由于授权信息是通过投屏接收端的公钥进行加密得到，保证了其他设备在获取到该授权信息后，无法解密该授权信息。保证了目标多媒体数据的安全。

结合第一方面，在另一种可能的设计方式中，所述方法还包括：响应于第一控制操作，投屏发送端向投屏接收端发送用于控制目标多媒体数据的播放的第一控制指令；投屏接收端接收来自投屏发送端的第一控制指令，并根据第一控制指令控制目标多媒体数据的播放。

基于该可能的实现方式，投屏发送端可以通过控制指令控制投屏接收端播放目标多媒体数据的播放进度，灵活方便。

第二方面，提供了一种投屏方法，应用于投屏发送端，该方法可以包括：投屏发送端获取目标DRM多媒体数据的获取信息，该目标DRM多媒体数据是对目标多媒体数据加密后的数据；响应于第一控制操作，投屏发送端向投屏接收端发送包括目标DRM多媒体数据的获取信息的第一投屏指令；投屏发送端获取目标DRM多媒体数据的授权信息，并向投屏发送端发送该授权信息。

结合第二方面，一种可能的实现方式中，投屏发送端接收来自投屏接收端的用于请求获取目标DRM多媒体数据的授权信息的第二请求消息，并向业务平台发送第二请求消息；投屏发送端接收来自业务平台的目标DRM多媒体数据的授权信息。

结合第二方面，一种可能的实现方式中，第二请求消息包括投屏接收端的公钥，授权信息包括用于解密目标DRM多媒体数据的密钥；该授权信息为业务平台使用投屏接收端的公钥对投屏接收端的密钥加密得到的。

结合第二方面，一种可能的实现方式中，该方法还可以包括：响应于第一控制操作，投放发送端向投屏接收端发送用于控制目标多媒体数据的播放的第一控制指令。

第三方面，提供了一种投屏方法，应用投屏接收端，该方法包括：投屏接收端接收来自投屏发送端的包括目标DRM多媒体数据的获取信息的第一投屏指令，目标DRM多媒体数据是对目标多媒体数据加密后的数据；投屏接收太根据目标DRM多媒体数据的获取信息从业务平台处获取目标DRM多媒体数据；投屏接收端通过投屏发送端获取目标DRM多媒体数据的授权信息，并根据该授权信息播放目标多媒体数据。

结合第三方面，一种可能的实现方式中，投屏接收端向投屏发送端发送用于请求获取目标DRM多媒体数据的授权信息的第二请求信息；投屏接收端接收来自投屏发送端的目标DRM多媒体数据的授权信息。

结合第三方面，一种可能的实现方式中，第二请求消息包括投屏接收端的公钥，授权信息包括用于解密目标DRM多媒体数据的密钥；该授权信息为业务平台使用投屏接收端的公钥对投屏接收端的密钥加密得到的。

结合第三方面，一种可能的实现方式中，该方法还可以包括：投屏接收端接收来自投屏发送端的用于控制目标多媒体数据的播放的第一控制指令，投屏接收端根据第一控制指令，控制目标多媒体数据的播放。

结合第一方面、第二方面以及第三方面，一种可能的实现方式中，目标DRM多媒体数据的获取信息包括下载地址。

基于该可能的实现方式，投屏接收端可以根据目标DRM多媒体数据的下载地址直接从业务平台处获取目标DRM多媒体数据，简单方便。

第四方面，提供一种投屏系统，该投屏系统可以包括投屏发送端、投屏接收端以及业务平台；

投屏发送端用于响应于第一投屏操作，向投屏接收端发送包括目标DRM多媒体数据的获取信息的第一投屏指令，目标DRM多媒体数据是对目标多媒体数据加密后的数据；投屏接收端用于接收来自投屏发送端的第一投屏指令，并根据目标DRM多媒体数据的获取信息从业务平台处获取目标DRM多媒体数据；投屏接收端还用于通过投屏发送端获取目标DRM多媒体数据的授权信息，并根据授权信息播放目标多媒体数据；业务平台用于向投屏接收端发送目标DRM多媒体数据，并通过投屏发送端向投屏接收端发送目标DRM多媒体数据的授权信息。

结合第四方面，一种可能的实现方式中，投屏发送端还用于向业务平台发送用于请求获取目标DRM多媒体数据的第一请求消息；业务平台还用于接收来自投屏发送端的第一请求消息，并对投屏发送端进行鉴权；业务平台还用于在投屏发送端鉴权通过的情况下，向投屏发送端发送目标DRM多媒体数据的获取信息。

结合第四方面，一种可能的实现方式中，投屏接收端具体用于通过投屏接收端向业务平台发送用于获取目标DRM多媒体数据的授权信息的第二请求消息；业务平台具体用于接收来自投屏发送端的第二请求消息，并通过投屏发送端向投屏接收端发送目标DRM多媒体数据的授权信息；投屏接收端还用于接收来自投屏发送端的授权信息。

结合第四方面，一种可能的实现方式中，第二请求消息包括投屏接收端的公钥，授权信息包括用于解密目标DRM多媒体数据的密钥；该授权信息为业务平台使用投屏接收端的公钥对投屏接收端的密钥加密得到的。

结合第四方面，一种可能的实现方式中，投屏接收端还用于使用投屏接收端的私钥对授权信息进行解密，得到密钥；投屏接收端还用于使用密钥对目标DRM多媒体数据进行解密，得到目标多媒体数据；投屏接收端还用于播放目标多媒体数据。

结合第四方面，一种可能的实现方式中，投屏发送端还用于响应于第一控制操作，向投屏接收端发送用于控制目标多媒体数据的播放的第一控制指令；投屏接收端还用于接收来自投屏发送端的第一控制指令，并根据第一控制指令控制目标多媒体数据的播放。

第五方面，提供了一种电子设备，该电子设备为投屏发送端；该电子设备包括：存储器和处理器，上述存储器与上述处理器耦合；存储器还用于存储计算机程序代码，计算机程序代码包括计算机指令；当计算机指令被所述处理器执行时，使得电子设备执行如第二方面及其任一种可能的设计方式所述的方法。

第六方面。提供了一种电子设备，该电子设备为投屏接收端；该电子设备包括：存储器和处理器，上述存储器与上述处理器耦合；存储器还用于存储计算机程序代码，计算机程序代码包括计算机指令；当计算机指令被所述处理器执行时，使得电子设备执行如第三方面及其任一种可能的设计方式所述的方法。

第七方面，本申请提供一种芯片系统，该芯片系统应用于电子设备。该芯片系统包括一个或多个接口电路和一个或多个处理器。该接口电路和处理器通过线路互联。该接口电路用于从电子设备的存储器接收信号，并向处理器发送该信号，该信号包括存储器中存储的计算机指令。当处理器执行所述计算机指令时，电子设备执行如第二方面或者第三方面及其任一种可能的设计方式所述的方法。

第八方面，本申请提供一种计算机存储介质，该计算机存储介质包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如第二方面或者第三方面及其任一种可能的设计方式所述的方法。

第九方面，本申请提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如第二方面或者第三方面及其任一种可能的设计方式所述的方法。

可以理解地，上述提供的第二方面及其任一种可能的设计方式所述的电子设备，第三方面所述的芯片系统，第四方面所述的计算机存储介质，第五方面所述的计算机程序产品所能达到的有益效果，可参考如第一方面及其任一种可能的设计方式中的有益效果，此处不再赘述。

附图说明

图1为本申请实施例提供的一种DRM文件的加密/解密方法的流程示意图；

图2为本申请实施例提供的一种电子设备的内容显示界面的示意图；

图3为本申请实施例提供的一种DRM多媒体数据的投屏方法流程图；

图4为本申请实施例提供的另一种DRM多媒体数据的投屏方法流程图；

图5为本申请实施例提供的一种投屏DRM多媒体数据的系统架构的组成示意图；

图6为本申请实施例提供的另一种投屏DRM多媒体数据的系统架构的组成示意图；

图7为本申请实施例提供的一种电子设备的硬件结构示意图；

图8为本申请实施例提供的一种DRM多媒体数据的投屏方法流程图；

图9为本申请实施例提供的一种投屏发送端的投屏界面的实例示意图；

图10为本申请实施例提供的一种投屏发送端的投屏连接显示界面的实例示意图；

图11为本申请实施例提供的另一种投屏发送端的投屏连接显示界面的实例示意图；

图12a为本申请实施例提供的一种投屏发送端控制投屏接收端投屏的界面的实例示意图；

图12b为本申请实施例提供的另一种投屏发送端控制投屏接收端投屏的界面的实例示意图；

图12c为本申请实施例提供的一种遥控器控制投屏接收端的实例示意图；

图12d为本申请实施例提供的另一种遥控器控制投屏接收端的实例示意图；

图12e为本申请实施例提供的一种投屏接收端控制DRM多媒体数据的进度的实例示意图；

图13a为本申请实施例提供的一种投屏发送端的显示界面的实例示意图；

图13b为本申请实施例提供的另一种投屏发送端的显示界面的实例示意图；

图14a～图14c为本申请实施例提供的一种投屏发送端向多个投屏接收端分别投屏的显示界面的实例示意图；

图15为本申请实施例提供的一种控制投屏界面的实例示意图；

图16为本申请实施例提供的一种芯片系统的结构组成示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。此外，本申请的描述中所提到的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或模块的过程、方法、系统、产品或设备没有限定于已列出的步骤或模块，而是可选地还包括其他没有列出的步骤或模块，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或模块。

另外，在本申请实施例中，“示例性的”、或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”、或者“例如”等词旨在以具体方式呈现概念。

为了便于理解本申请的技术方案，在对本申请实施例的投屏方法进行详细介绍之前，先对本申请实施例中所提到的专业名词进行介绍。

1、高带宽数字内容保护(high-bandwidth digital content protection，HDCP)

HDCP是一种用于保护数字化的多媒体数据的技术。HDCP可以用于电子设备在向其他设备输出数字化的多媒体数据时，对多媒体数据进行保护。例如，支持HDCP技术的电子设备可以在通过数字视频接口(digital visual interface，DVI)、显示端口(display port，DP)、高清晰多媒体接口(high definition multimedia interface，HDMI)、无线保真(wireless-fidelity，Wifi)等途径向其他设备传输多媒体数据时，使用HDCP技术对多媒体数据进行保护，以防止多媒体数据被非法拷贝。

需要说明的是，支持HDCP技术的电子设备需要预先设置有HDCP Key。该HDCP Key可以为在电子设备出厂前设置的。每个电子设备具有唯一的HDCP Key。多媒体数据的发送设备和接收设备可以在HDCP协议协商阶段使用各自内置的HDCP Key进行合法性验证。在验证通过后，确定多媒体数据的加密密钥和解密密钥。

其中，多媒体数据的发送设备可以使用加密密钥对输出的多媒体数据进行加密，并向接收设备发送加密后的多媒体数据。接收设备在接收到加密后的多媒体数据之后，可以使用解密密码对加密后的多媒体数据进行解密，得到多媒体数据。

2、DRM

DRM是一种基于公共密钥基础设施(public key infrastructure，PKI)系统的保护技术，可以用于管理被保护数字媒体(例如图像、音频和视频等)的使用权的技术。DRM可以防止数字媒体被非法复制。提供DRM文件的业务平台(也可以称为内容供应商(contentprovider，CP)，后续为便于描述，可以简称为业务平台)可以采用DRM技术对文件进行加密，得到DRM文件。之后，用户可以通过电子设备的应用程序(例如媒体应用)从业务平台获取到DRM文件。在电子设备得到业务平台的授权的情况下，电子设备的媒体应用才可以解密并使用该DRM文件。

其中，电子设备可以为支持DRM技术的设备。例如，电子设备具有合法的DRM设备证书。DRM设备证书可以具有采用非对称加密算法生成的一对公/私钥。响应于电子设备的用于请求DRM文件的请求，业务平台可以使用该电子设备的公钥对授权信息(License)进行加密，并向电子设备发送加密后的授权信息。其中，该授权信息包括DRM文件的解密密钥。电子设备在接收到来自业务平台的加密后的授权信息之后，可以使用私钥对该加密后的授权信息进行解密，得到DRM文件的解密密钥。如此，电子设备可以使用该解密密钥对DRM文件进行解密，进而得到解密后的DRM文件。例如，DRM文件可以为DRM多媒体数据，比如，可以为DRM视频、DRM音频等。下文涉及的DRM多媒体数据均可以参照此处的描述，不再赘述。

一种示例中，如图1所示，为本申请实施例提供的一种DRM文件的加密/解密方法的示意图。

S11、业务平台服务器向打包器(Packager)发送原始文件。相应的，打包器接收来自业务平台服务器的原始内容。

其中，原始文件可以是指未加密的文件，例如，原始文件可以为未加密的视频、音频等。

S12、打包器从密钥管理服务器(key manager server，KMS)处获取密钥，并使用该密钥对原始文件进行加密。

其中，密钥管理服务器中可以存储有多个不同的密钥。该多个不同的密钥可以为对称密钥。打包器在使用密钥对原始内容加密后，可以向密钥管理服务器发送原始内容与密钥之间的对应关系。密钥管理服务器在接收到原始内容与密钥之间的对应关系可以存储该对应关系。例如，原始内容与密钥之间的对应关系可以为原始内容的标识以及密钥之间的对应关系。不同的原始内容可以对应不同的密钥。

其中，原始内容的标识与密钥之间的对应关系可以以表格形式存储，也可以以其他形式存储，如以数据形式存储。例如，以表格形式为例，密钥管理服务器存储的N个原始内容的标识与密钥之间的对应关系可以如表1所示。如表1所示，原始内容1的标识对应密钥1、原始内容2的标识对应密钥2、…、原始内容N的标识对应密钥N。N为正整数。

表1

需要说明的是，表1只是以表格的形式示意对应关系在密钥管理服务器中的存储形式，并不是对对应关系在密钥管理服务器中的存储形式的限定，当然，对应关系在密钥管理服务器中的存储形式还可以以其他的形式存储，如以数组形式存储，本申请实施例对此不做限定。表1中的对应关系仅为示例性的，还可以包括其他原始内容的标识与对应的密钥，不予限制。

S13、打包器向内容分发网络(content delivery network，CDN)服务器发送加密的文件。相应的，CDN服务器接收并存储来自打包器的加密的文件。

S14、响应于用户对电子设备的播放操作，电子设备可以向CDN服务器发送第一请求信息。相应的，CDN服务器接收来自电子设备的第一请求信息。

其中，第一请求信息可以用于获取DRM文件。例如，以DRM文件为DRM多媒体数据(如收费视频)为例，第一请求信息至少可以包括待播放DRM多媒体数据的信息以及电子设备的标识。待播放DRM多媒体数据的信息可以包括待播放DRM多媒体数据的名称、集数、时长、身份标识号(Identity document，ID)等。

其中，用户的播放操作可以是指用户对电子设备的应用程序的内容显示界面的操作。例如，用户的播放操作可以为用户点击如图2所示的内容显示界面的操作。电子设备可以通过无线网络(如wifi、第五代(5th generation，5G)网络)向CDN服务器发送用于请求获取待播放DRM多媒体数据的请求信息。

其中，电子设备可以为能够播放或显示多媒体数据的、且支持DRM技术的设备。例如，电子设备可以具有DRM证书。电子设备可以安装一个或多个应用程序。用户可以通过该一个或多个应用程序查看多媒体数据。

S15、CDN服务器向电子设备发送第一文件。相应的，电子设备接收来自CDN服务器的第一文件。

其中，第一文件可以为待播放的DRM多媒体数据。该DRM多媒体数据的加密密钥可以为上述S11中的密钥。

S16、在检测到第一文件为待播放的DRM多媒体数据的情况下，电子设备向授权信息服务器发送第二请求信息。相应的，授权信息服务器接收来自电子设备的第二请求信息。

其中，第二请求信息可以用于请求待播放的DRM多媒体数据的解密密钥。该解密密码与待播放的DRM多媒体数据的加密密钥可以为对称密钥。例如，第二请求信息至少可以包括用户账号以及密码、电子设备的标识(如证书)、公钥以及第一文件的标识。

其中，用户账号以及密码是指用户可以登录电子设备的应用程序的账号以及密码。例如，用户可以通过图3的显示界面，输入用户账号以及密码。

S17、在授权信息服务器(License Server)对第二请求信息鉴权通过后，向密钥管理服务器发送第一查询信息。相应的，密钥管理服务器接收来自授权信息服务器的第一查询信息。

其中，授权信息服务器对第二请求信息进行鉴权可以是指授权信息服务器对电子设备和用户账号及密码进行鉴权，用以验证电子设备是否为合法设备和用户账号及密码是否正确。

例如，授权信息服务器可以存储有多个电子设备的证书、多个用户账号及对应的密码。若电子设备的证书与授权信息服务器存储的电子设备的证书一致，则说明该电子设备为合法设备。

又例如，授权信息服务器可以存储有多个用户账号以及对应的密码。若用户账号及对应的密码与授权信息服务器存储的用户账号以及对应的密码均一致，则说明用户输入的用户账号及密码正确。在第二请求信息中包括的电子设备为合法设备且用户账号及密码均正确的情况下，说明电子设备的鉴权通过。下文关于鉴权的过程均可以参照此处的描述，不再赘述。

其中，第一查询信息可以用于查询第一文件的解密密钥。例如，第一查询信息可以包括第一文件的标识。

S18、密钥管理服务器确定第一文件的解密密钥，并向授权信息服务器发送第一查询结果。相应的，授权信息服务器接收来自密钥管理服务器的第一查询结果。

其中，第一文件的解密密钥可以用于对第一文件进行解密。例如，在第一文件的加密密钥为对称密钥的情况下，第一文件的解密密钥可以与第一文件的加密密钥一致。密钥管理服务器可以根据存储的多个原始内容的标识与对应的密钥之间的对应关系，确定第一文件的解密密码。比如，密钥管理服务器可以查询表1，确定第一文件的解密密钥。

其中，第一查询结果可以包括第一文件的解密密钥。

S19、授权信息服务器生成第一授权信息文件，并向电子设备发送第一授权信息文件。相应的，电子设备接收来自授权信息服务器的第一授权信息文件。

其中，第一授权信息文件为授权信息服务器使用电子设备的公钥对授权信息以及第一文件的解密密钥加密得到的文件。

其中，授权信息可以用于指示允许电子设备使用/播放DRM多媒体数据的权限。该权限可以为用户账号具有的权限。例如，授权信息可以用于指示允许电子设备使用/播放DRM多媒体数据的时长、集数等。电子设备可以根据授权信息使用/播放DRM多媒体数据。下文中关于授权信息的描述均可以参照此处，不予赘述。

S20、电子设备对第一授权信息文件进行解密，得到第一文件的解密密钥。

其中，电子设备可以使用电子设备的私钥对第一授权信息文件进行解密，得到第一文件的解密密钥。

S21、电子设备对第一文件进行解密，得到待播放多媒体数据，并显示/播放该多媒体数据。

其中，电子设备可以使用第一授权信息中的第一文件的解密密钥对第一文件进行解密，得到解密后的DRM多媒体数据(也即，待播放的DRM多媒体数据)。

需要说明的是，DRM技术在具体应用时，可以包括ChinaDRM、PlayReady、FairPlay、Marlin等，不予限制。

一些技术中为扩大应用程序(例如视频应用、音乐应用)包括的DRM文件(例如DRM视频、DRM音频)的可使用范围，电子设备(可以称为投屏发送端，如手机、电脑)可以将DRM文件投屏到其他设备(可以称为投屏接收端，如电视，投影仪)上，以使得投屏设备可以使用/播放该DRM文件。例如，用户在使用手机看DRM视频时，可以将DRM视频投屏到电视上，以提高视频的观看体验。

在一些实施例中，如图3所示，投屏发送端可以通过自身的应用程序浏览DRM多媒体数据，并通过与提供DRM多媒体数据的业务平台进行交互，完成鉴权。具体过程可以参照上述描述，不予赘述。

在鉴权通过的情况下，投屏发送端可以从视频网站处获取DRM多媒体数据以及授权信息。投屏发送端可以使用授权信息中携带的密钥对DRM多媒体数据进行解密。如此，投屏发送端可以将解密后的多媒体数据以投屏指令的形式投屏到投屏接收端，以使得投屏接收端可以使用/播放该多媒体数据。该投屏指令可以进行HDCP加密。投屏接收端在接收到投屏指令后，可以进行HDCP解密并播放该多媒体数据。

在该实施例中，DRM多媒体数据的下载、解密以及解码均在投屏发送端完成，且在投屏过程中，投屏发送端不能退出解密/解码程序，从而导致投屏发送端不能执行其他操作，这样用户体验不佳。另外，投屏发送端与投屏接收端均需要预先设置HDCP Key，增加了成本的同时限制了DRM多媒体数据投屏的应用范围。

在一些实施例中，如图4所示，投屏发送端可以通过自身的应用程序，获取DRM多媒体数据的URL或ID，并向投屏接收端发送包括DRM多媒体数据的URL或ID的投屏指令。投屏接收端在接收到包括DRM多媒体数据的URL或ID的投屏指令之后，通过自身的应用程序与提供DRM多媒体数据的业务平台进行交互，完成鉴权以及根据DRM多媒体数据的URL或ID下载DRM多媒体数据。在鉴权通过的情况下，投屏接收端可以从业务处获取授权信息。投屏接收端使用该授权信息对DRM多媒体数据进行解密，得到可以使用/播放的多媒体数据。进而，投屏接收端可以使用/播放多媒体数据。

在该实施例中，由于不同的业务平台具有不同的用户账号管理体系以及鉴权方法，且鉴权在投屏接收端进行，因此投屏接收端也需要安装有与投屏发送端相同的应用程序。这意味着，只有在投屏发送端和投屏接收端均安装有相同的应用程序的情况下，投屏发送端才可以向投屏接收端投屏DRM多媒体数据。限制了DRM多媒体数据的投屏的应用范围，不利于DRM技术的推广。

鉴于此，本申请实施例提供了一种投屏方法，该方法包括：响应于用户的投屏操作，投屏发送端向投屏接收端发送用于指示播放目标DRM多媒体数据的第一投屏指令，该第一投屏指令包括目标DRM多媒体数据的获取信息；投屏接收端在接收到来自投屏发送端的第一投屏指令后，根据该目标DRM多媒体数据的获取信息从业务平台处获取目标DRM多媒体数据，并向投屏发送端发送用于请求授权信息的请求信息；投屏发送端向提供目标DRM多媒体数据的业务平台转发该请求信息；业务平台向投屏发送端发送包括目标DRM多媒体数据的解密密钥的响应消息；投屏发送端向投屏接收端转发该响应消息，以使得投屏接收端可以根据该响应消息中的解密密钥对目标DRM多媒体数据进行解密，并使用/播放解密后的多媒体数据。

在该实施例中，投屏发送端能够代理投屏接收端完成授权信息的获取以及鉴权。投屏接收端可以根据投屏发送端的投屏指令直接下载目标DRM多媒体数据。如此，投屏发送端无需下载目标DRM多媒体数据，相较于现有技术中，投屏发送端既要进行鉴权以及获取授权信息，又要下载DRM多媒体数据，本申请实施例提供的方案，由于投屏发送端无需下载DRM多媒体数据，因此，降低了投屏发送端的能耗。

可以理解的是，本申请实施例提供的投屏方法中，投屏接收端可以通过投屏发送端获取授权信息，也即是说，只需要投屏发送端安装有提供目标DRM多媒体数据的应用程序即可，投屏接收端无需安装提供目标DRM多媒体数据的应用程序，扩大了DRM多媒体数据的投屏的应用范围。

请参考图5，为本申请实施例提供的方法所应用的系统架构示意图。如图5所示，该系统架构包括：多个电子设备(例如投屏发送端101和一个或多个投屏接收端102)、业务平台103。该多个电子设备之间通信连接，例如，可以通过有线方式(USB、总线)或无线方式(如，蓝牙、wifi)通信连接。该多个电子设备与业务平台103可以通信连接。

需要说明的是，投屏发送端101和一个或多个投屏接收端102之间可以实现多媒体数据的投屏。例如，投屏发送端101和投屏接收端102均支持投屏协议(如数字生活网络联盟(digital living network alliance，DLNA)协议、Miracast协议等)。

其中，投屏发送端101可以安装有使用DRM多媒体数据的应用程序(例如第一应用程序104)，投屏发送端101具备使用DRM多媒体数据的权限。也就是说，投屏发送端101可以通过第一应用程序104使用/播放DRM多媒体数据。

投屏发送端101可以向第一应用程序104的业务平台103发送用于请求鉴权的请求信息。例如，如图6所示，投屏发送端101可以具有鉴权模块1041。投屏发送端101可以通过该鉴权模块1041与业务平台103进行鉴权。相应的，业务平台103也可以具有鉴权模块1031。业务平台可以通过该鉴权模块1031对投屏发送端101鉴权。

投屏发送端101还可以接收来自投屏接收端102的用于请求授权信息的请求消息，并向业务平台103转发该请求消息。例如，如图6所示，投屏发送端101可以具有投屏代理模块1011和授权代理模块1042。投屏发送端101可以通过投屏代理模块1011接收来自投屏接收端102的请求消息，并通过授权代理模块1042向业务平台103转发该请求消息。

其中，投屏接收端102可以具有下载DRM多媒体数据的权限以及播放多媒体数据的功能。也就是说，投屏接收端可以直接下载DRM多媒体数据。例如，投屏接收端102可以根据DRM多媒体数据的URL或ID从业务平台103处获取DRM多媒体数据，也可以从其他设备处获取DRM多媒体数据，比如，可以从CDN服务器处获取DRM多媒体数据。

例如，如图6所示，投屏接收端102可以具有投屏代理模块1021。投屏接收端102可以通过投屏代理模块1021接收来自投屏发送端101的投屏指令。投屏接收端102还可以通过投屏代理模块1021从业务平台103处获取投屏指令指示的DRM多媒体数据。

投屏发送端101还可以具有生成用于请求授权信息的请求信息以及解密并播放DRM多媒体数据的功能。例如，如图6所示，投屏发送端101可以具有DRM客户端1022以及播放器1023。DRM客户端1022可以生成用于请求授权信息的请求信息以及解密DRM多媒体数据。比如，DRM客户端1022可以具有授权模块10221以及解密模块10222。投屏发送端101可以通过授权模块10221生成用于请求授权信息的请求信息，并通过投屏代理模块1021向投屏发送端101发送该请求信息。解密模块10222可以对DRM多媒体数据进行解密，得到解密的多媒体数据，并通过播放器1023播放该解密的多媒体数据。

其中，业务平台103可以用于管理业务平台103中存储的文件(例如DRM多媒体数据以及对应的密钥)、用户账号以及密码、以及各个用户账号的权限。例如，如图6所示，业务平台103包括：密钥管理模块1031、加密模块1032、鉴权模块1033以及DRM多媒体管理模块1034、DRM多媒体分发模块1035。

业务平台103可以具有对电子设备以及用户账号鉴权的功能。例如，业务平台103可以通过鉴权模块1033接收来自投屏发送端101的鉴权请求，并对投屏发送端101进行鉴权以及对鉴权请求携带的用户账号及密码进行验证。

其中，业务平台103对投屏发送端101进行鉴权以及对用户账号及密码进行验证的过程可以参照上述描述，不予赘述。

业务平台103还可以具有对多媒体数据进行加密生成DRM多媒体数据的功能。例如，业务平台103可以通过加密模块1032从密钥管理模块1031中获取密钥，并使用该密钥对多媒体数据进行加密，得到DRM多媒体数据，并将该DRM多媒体数据存储至DRM多媒体数据管理模块1034。又例如，业务平台103可以使用DRM多媒体分发模块1035向投屏接收端102发送DRM多媒体数据。

示例性的，业务平台103可以具有图1中的业务平台服务器的功能，也具有图1中的打包器、密钥管理服务器以及CDN服务器的功能。也即，业务平台可以包括一个或多个服务器，该一个或多个服务器可以具有图1中业务平台服务器、打包器、密钥管理服务器以及CDN服务器的功能。

例如，业务平台103包括多个服务器。该多个服务器可以包括业务平台服务器、打包器、密钥管理服务器以及CDN服务器等。

又例如，业务平台103可以包括一个服务器。在这种情况下，结合图6，业务平台103的鉴权模块1033、DRM多媒体数据管理模块1034可以具有图1中的业务平台服务器的功能。DRM多媒体数据分发模块1035可以具有图1中的CDN服务器的功能。业务平台103的密钥管理模块1031可以具有图1中的密钥管理服务器的功能。业务平台103的加密模块可以具有图1中的打包器的功能。

可以理解的是，在业务平台103可以具有一个或多个CDN服务器。该一个或多个CDN服务器可以根据需要设置在多个不同的区域。不同的区域之间的CDN服务器之间通信连接。如此，区域内的用户可以直接从该区域内的CDN服务器处获取DRM多媒体数据。减轻了业务平台103的压力。

当然，业务平台103与CDN服务器也可以为不同的服务器。在这情况下，CDN服务器与业务平台103通信连接。业务平台103可以向CDN服务器分发DRM多媒体数据。CDN服务器可以接收并存储业务平台103分发的DRM多媒体数据。如此，后续投屏接收端102可以先从传输时间最短且存储有DRM多媒体数据的CDN服务器处获取DRM多媒体数据。在CDN服务器没有存储DRM多媒体数据的情况下，再从业务平台103处获取DRM多媒体数据。具体过程可以参照下述实施例的描述，此处不予赘述。

其中，本申请实施例中的应用程序(如第一应用程序)可以是安装在电子设备中的嵌入式应用程序(即电子设备的系统应用)或者可下载应用程序。其中，嵌入式应用程序是作为电子设备(如手机)实现的一部分提供的应用程序。可下载应用程序是一个可以提供自己的因特网协议多媒体子系统(Internet Protocol Multimedia Subsystem，IMS)连接的应用程序，该可下载应用程序可以预先安装在终端中的应用或可以由用户下载并安装在终端中的第三方应用；还可以是集成在某个嵌入式应用程序或可下载应用程序中的快应用。

需要说明的是，第一应用程序为可以使用DRM多媒体数据的应用程序。例如，假如DRM多媒体数据可以为DRM视频，则第一应用程序可以为用于播放视频的视频播放应用程序。又例如，假如DRM多媒体数据可以为DRM音频，则第一应用程序为用于播放音频的音频播放应用程序。当然，DRM多媒体数据还可以包括其他类型的DRM内容，例如，可以为DRM主题。相应的，第一应用程序可以为用于设置电子设备主题的主题应用。不予限制。

示例性的，本申请实施例中的电子设备可以是平板电脑、手机、桌面型、膝上型、手持计算机、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本，以及蜂窝电话、个人数字助理(personal digital assistant，PDA)、增强现实(augmented reality，AR)\虚拟现实(virtual reality，VR)设备、车载设备等设备，本申请实施例对该电子设备的具体形态不作特殊限制。

本申请提供的投屏方法的执行主体可以为DRM多媒体数据的投屏装置，该投屏装置可以为图7所示的电子设备。同时，该投屏装置还可以为该电子设备的中央处理器(Central Processing Unit，CPU)，或者该电子设备中的用于投屏的控制模块。本申请实施例中以电子设备执行投屏方法为例，说明本申请实施例提供的投屏方法。

请参考图7，本申请实施例这里以电子设备为图7所示的手机600为例，对本申请实施例提供的电子设备进行介绍。其中，图7所示的手机700仅仅是电子设备的一个范例，并且手机200可以具有比图中所示出的更多的或者更少的部件，可以组合两个或更多的部件，或者可以具有不同的部件配置。图7中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

如图7所示，手机700可以包括：处理器710，外部存储器接口720，内部存储器721，通用串行总线(universal serial bus，USB)接口730，充电管理模块740，电源管理模块741，电池742，天线1，天线2，移动通信模块750，无线通信模块760，音频模块770，扬声器770A，受话器770B，麦克风770C，耳机接口770D，传感器模块780，按键790，马达791，指示器792，摄像头793，显示屏794，以及用户标识模块(subscriber identification module，SIM)卡接口795等。

其中，上述传感器模块780可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器和骨传导传感器等传感器。

处理器710可以包括一个或多个处理单元，例如：处理器710可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

控制器可以是手机700的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器710中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器710中的存储器为高速缓冲存储器。该存储器可以保存处理器710刚用过或循环使用的指令或数据。如果处理器710需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器710的等待时间，因而提高了系统的效率。

在一些实施例中，处理器710可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

可以理解的是，本实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对手机700的结构限定。在另一些实施例中，手机700也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

充电管理模块740用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。充电管理模块740为电池742充电的同时，还可以通过电源管理模块741为电子设备供电。

电源管理模块741用于连接电池742，充电管理模块740与处理器710。电源管理模块741接收电池742和/或充电管理模块740的输入，为处理器710，内部存储器721，外部存储器，显示屏794，摄像头793，和无线通信模块760等供电。在一些实施例中，电源管理模块741和充电管理模块740也可以设置于同一个器件中。

手机700的无线通信功能可以通过天线1，天线2，移动通信模块750，无线通信模块760，调制解调处理器以及基带处理器等实现。在一些实施例中，手机700的天线1和移动通信模块750耦合，天线2和无线通信模块760耦合，使得手机700可以通过无线通信技术与网络以及其他设备通信。

天线1和天线2用于发射和接收电磁波信号。手机700中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块750可以提供应用在手机700上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块750可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(lownoise amplifier，LNA)等。移动通信模块750可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。

移动通信模块750还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块750的至少部分功能模块可以被设置于处理器710中。在一些实施例中，移动通信模块750的至少部分功能模块可以与处理器710的至少部分模块被设置在同一个器件中。

无线通信模块760可以提供应用在手机700上的包括无线局域网(wireless localarea networks，WLAN)(如(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequencymodulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。例如，本申请实施例中，手机700可以通过无线通信模块760接入Wi-Fi网络。

无线通信模块760可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块760经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器710。无线通信模块760还可以从处理器710接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

手机700通过GPU，显示屏794，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏794和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器710可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏794用于显示图像，视频等。该显示屏794包括显示面板。例如，本申请实施例中，显示屏794可以用于显示上述第一应用程序以及下述第二应用程序的应用界面，如设备投屏界面、设备投屏连接界面、投屏可连接设备界面等。

手机700可以通过ISP，摄像头793，视频编解码器，GPU，显示屏794以及应用处理器等实现拍摄功能。ISP用于处理摄像头793反馈的数据。摄像头793用于捕获静态图像或视频。在一些实施例中，手机700可以包括1个或N个摄像头793，N为大于1的正整数。

外部存储器接口720可以用于连接外部存储卡，例如Micro SD卡，实现扩展手机700的存储能力。外部存储卡通过外部存储器接口720与处理器710通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器721可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器710通过运行存储在内部存储器721的指令，从而执行手机700的各种功能应用以及数据处理。例如，在本申请实施例中，处理器710可以通过执行存储在内部存储器721中的指令，内部存储器721可以包括存储程序区和存储数据区。

其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储手机700使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器721可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flashstorage，UFS)等。

手机700可以通过音频模块770，扬声器770A，受话器770B，麦克风770C，耳机接口770D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

按键790包括开机键，音量键等。按键790可以是机械按键。也可以是触摸式按键。马达791可以产生振动提示。马达791可以用于来电振动提示，也可以用于触摸振动反馈。指示器792可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。SIM卡接口795用于连接SIM卡。SIM卡可以通过插入SIM卡接口795，或从SIM卡接口795拔出，实现和手机700的接触和分离。手机700可以支持1个或N个SIM卡接口，N为大于1的正整数。SIM卡接口795可以支持Nano SIM卡，Micro SIM卡，SIM卡等。

尽管图7未示出，手机700还可以包括闪光灯、微型投影装置、近场通信(NearField Communication，NFC)装置等，在此不再赘述。

可以理解的是，本实施例示意的结构并不构成对手机700的具体限定。在另一些实施例中，手机700可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

以下实施例中的方法均可以在具有上述硬件结构和上述系统架构的电子设备中实现。

下面结合图5的通信系统，对本申请实施例提供的投屏方法进行说明。如图8所示，该投屏方法可以包括步骤一、步骤二和步骤三。其中，步骤一可以为投屏发送端向投屏接收端发送第一投屏指令，该第一投屏指令可以用于指示投屏接收端播放目标DRM多媒体数据。步骤二可以为投屏接收端根据第一投屏指令从业务平台处获取目标DRM多媒体数据，并通过投屏发送端获取授权信息，该授权信息包括目标DRM多媒体数据的解密密钥。步骤三可以为投屏接收端对目标DRM多媒体数据进行解密，并播放解密后的多媒体数据。

如图8所示，上述步骤一，即投屏发送端向投屏接收端发送第一投屏指令，可以包括S801-S803。

S801、投屏发送端向业务平台发送第一请求消息。相应的，业务平台接收来自投屏发送端的第一请求消息。

其中，投屏发送端可以为图5中的投屏发送端101。业务平台可以为图5中的业务平台103。

其中，第一请求消息可以用于请求获取目标DRM多媒体数据。例如，第一请求消息可以包括目标DRM多媒体数据的标识(如名称、ID等)。目标DRM多媒体数据是对目标多媒体数据加密后的数据。具体的加密过程可以参照上述DRM的描述，不予赘述。

其中，第一请求消息还可以用于申请开通使用/播放DRM多媒体数据的权限，或者，用于申请使用/播放DRM多媒体数据的权限。例如，在用户账号的权限不具备使用/播放DRM多媒体数据的权限的情况下，或者，在DRM多媒体数据为需要付费的多媒体数据(如超前点播视频)的情况下，第一请求消息还可以包括付费信息。又例如，可以包括付费金额。第一请求消息可以包括付费信息。比如，可以包括付费金额。

当然，第一请求消息还可以用于请求对投屏发送端鉴权。例如，第一请求消息可以包括投屏发送端的标识(如证书)、用户账号以及密码。业务平台在接收到投屏发送端的标识之后，可以根据投屏发送端的标识、用户账号以及密码，对投屏发送端进行鉴权。业务平台对投屏发送端的鉴权过程可以参照上述图1中的S17描述，不予赘述。

S802、在鉴权通过的情况下，业务平台向投屏发送端发送第一鉴权结果。相应的，投屏发送端接收来自业务平台的第一鉴权结果。

其中，第一鉴权结果可以用于指示鉴权通过。例如，第一鉴权结果可以包括目标DRM多媒体数据的下载地址(如URL)、目标DRM多媒体数据的授权信息的下载地址。

其中，授权信息可以用于指示投屏发送端使用目标DRM多媒体数据的权限。该权限可以是业务平台根据第一请求消息确定的，也即，业务平台可以根据第一请求消息包括的内容，确定投屏发送端设备使用/播放目标DRM多媒体数据。例如，授权信息可以指示投屏发送端设备可以使用/播放的目标DRM多媒体数据的时长、次数、分辨率等。下文关于DRM多媒体数据的下载地址以及授权信息的过程均可以参照此处的描述，不再赘述。

S803、投屏发送端向投屏接收端发送第一投屏指令。相应的，投屏接收端接收来自投屏发送端的第一投屏指令。

其中，第一投屏指令可以用于指示投屏接收端播放目标DRM多媒体数据。例如，第一投屏指令可以包括目标DRM多媒体数据的下载地址。

在一些实施例中，在投屏发送端获取目标DRM多媒体数据的下载地址和授权信息的下载地址之前，投屏发送端可以先与投屏接收端建立连接。

具体的，响应于操作一，投屏发送端101可以显示投屏连接界面。在投屏发送端101接收到连接投屏接收端的操作指令之后，投屏连接端101可以搜索并显示可以连接的投屏接收设备。示例性的，如图9中的a所示，响应于用户对打开投屏控制键901的操作A，投屏发送端101可以显示如b所示的界面。该界面可以显示多个可投屏的设备名称(如图中的第一投屏接收端、第二投屏接收端和第三投屏设备)。

响应于操作二，投屏发送端101可以与一个或多个投屏接收端102建立投屏连接。如此，投屏发送端101可以向建立连接的一个或多个投屏接收端102发送投屏指令。示例性的，结合图9中的b，如图10所示，响应于用户对连接设备的操作B，投屏发送端101可以与用户选择的一个或多个投屏接收端建立投屏连接。例如，用户的操作B为选择第一投屏接收端和第二投屏接收端，投屏发送端101可以与第一投屏接收端和第二投屏接收端建立投屏连接。在投屏发送端101与第一投屏接收端和第二投屏接收端建立投屏连接之后，第一投屏接收端和第二投屏接收端可以显示与投屏发送端101相同的界面。

响应于操作三，投屏发送端可以向建立投屏连接的一个或多个投屏接收端发送第一投屏指令，以使得该一个或多个投屏接收端在接收到第一投屏指令之后，可以根据第一投屏指令携带的目标DRM多媒体数据的下载地址获取目标DRM多媒体数据。

一种示例，结合图2，响应于用户对目标DRM多媒体数据的点击操作，投屏发送端获取目标DRM多媒体数据的下载地址和授权信息的下载地址。然后，投屏发送端可以向投屏接收端发送目标DRM多媒体的下载地址。

在一些实施例中，为了保证投屏接收端可以能够使用/播放DRM多媒体数据，投屏发送端在与投屏接收端建立投屏连接过程中，投屏发送端还可以获取投屏接收端的能力信息。投屏发送端可以根据投屏接收端的能力信息确定投屏接收端支持DRM多媒体数据的投屏。

其中，投屏接收端的能力信息可以包括用于指示投屏接收端支持DRM多媒体数据的投屏的指示信息。该指示信息可以用于指示投屏接收端支持DRM多媒体数据的投屏。

一种示例中，指示信息可以包括一个或多个标志位。当一个或多个标志位可以用于表示投屏接收端支持DRM多媒体数据的投屏。

其中，该一个或多个标志为可以为符号或数字，也可以为符号与数字的组合等，不予限制。

又一种示例中，指示信息可以包括一个或多个比特。当该一个或多个比特的取值为T1时，投屏发送端可以确定投屏接收端支持DRM多媒体数据的投屏；当该一个或多个比特的取值为T2时，投屏发送端可以确定投屏接收端不支持DRM多媒体数据的投屏。T1和T2为整数，T1与T2不相同。

其中，T1、T2可以为二进制比特数“0”、“1”或者二进制比特数“1”、“0”，还可以为其他符号或者数字等，不予限制。

例如，以指示信息包括1个二进制比特为例，二进制比特为“1”指示投屏接收端支持DRM多媒体数据的投屏；二进制比特为“0”指示投屏接收端不支持DRM多媒体数据的投屏。

一种可能的实现方式中，投屏接收端可以主动向投屏发送端发送投屏发送端的能力信息。

例如，当投屏发送端与投屏接收端建立投屏连接后，投屏接收端可以主动向投屏发送端发送投屏接收端的能力信息。

如此，投屏接收端向投屏发送端发送投屏接收端的能力信息，避免在投屏接收端不支持DRM多媒体数据的投屏的情况下，仍然接收到来自投屏发送端发送的投屏指令带来的问题，提高投屏接收端投屏的准确性。

又一种可能的实现方式中，在投屏发送端与投屏接收端建立投屏的过程中，投屏发送端可以向投屏接收端发送第一查询信息。第一查询信息可以用于查询投屏接收端的能力信息。投屏接收端在接收到来自投屏发送端的第一查询信息后，可以向投屏发送端发送投屏接收端的能力信息。

例如，第一查询信息可以携带在第一投屏指令中，或者，第一查询信息可以为单独的信息。也即，第一投屏指令可以包括第一查询信息、目标DRM多媒体数据的下载地址。

又例如，投屏发送端可以先向投屏接收端发送第一查询信息，在确定投屏接收端支持DRM多媒体数据的投屏的情况下，再向投屏发送端发送第一投屏指令。如此，投屏发送端可以根据投屏接收端的能力信息，确定是否向投屏接收端发送第一投屏指令，准确灵活，还可以避免投屏发送端向不支持DRM多媒体数据投屏的投屏接收端发送投屏指令。

在一些实施例中，在投屏发送端获取目标DRM多媒体数据的下载地址和授权信息的下载地址之后，投屏发送端可以建立与投屏接收端的投屏连接。

具体的，投屏发送端获取目标DRM多媒体数据的下载地址和授权信息的下载地址的过程可以参照上述S801和S802。不予赘述。响应于操作四，投屏发送端可以与一个或多个投屏接收端建立投屏连接。示例性的，如图11中的a所示，响应于用户对目标多媒体数据的投屏控制键1101的操作C，投屏发送端可以显示如图11中的b所示的界面。响应于用户对连接设备的操作D，投屏发送端101可以与用户选择的一个或多个投屏接收端建立投屏连接，并向建立投屏连接的一个或多个投屏接收端发送目标多媒体数据的下载地址。

如图7所示，上述步骤二，也即，投屏接收端根据第一投屏指令从业务平台处获取目标DRM多媒体数据，并通过投屏发送端获取授权信息，可以包括S804-S808。

S804、投屏接收端从业务平台处获取目标DRM多媒体数据。

其中，投屏接收端可以根据目标DRM多媒体数据的下载地址，获取目标DRM多媒体数据。

一种示例中，投屏接收端可以根据目标DRM多媒体数据的下载地址，从CDN服务器处获取目标DRM多媒体数据。其中，CDN服务器可以为存储有目标DRM多媒体数据的服务器。

例如，投屏接收端可以根据目标DRM多媒体数据的下载地址向对应的CDN服务器发送请求信息1。请求信息1可以用于请求下载目标DRM多媒体数据。例如，请求信息1可以包括目标DRM多媒体数据的标识。当然，请求信息1还可以包括其他信息，比如，还可以包括投屏接收端的标识。

进一步的，在CDN服务器没有存储目标DRM多媒体数据的情况下，若CDN服务器接收到投屏接收端的请求信息1，则CDN服务器可以从业务平台处获取并存储目标DRM多媒体数据。如此，在后续其他设备具有下载目标DRM多媒体数据的需求时，其他设备可以快速直接从CDN服务器处获取目标DRM多媒体数据，减轻了业务平台的压力。

又例如，投屏接收端也可以根据目标DRM多媒体数据的下载地址向业务平台发送请求信息2。请求信息2可以参照请求信息2的描述，不予赘述。

S805、投屏接收端向投屏发送端发送第二请求消息。相应的，投屏发送端接收来自投屏接收端的第二请求消息。

其中，第二请求消息可以用于请求目标DRM多媒体数据的授权信息。例如，第二请求消息可以包括投屏接收端的公钥、目标DRM多媒体数据的标识。

S806、投屏发送端向业务平台发送第三请求消息。业务平台接收到来自投屏发送端的第三请求消息。

其中，第三请求消息可以用于获取目标DRM多媒体数据的授权信息。例如，第三请求消息可以与第二请求消息相同，包括目标DRM多媒体数据的标识、投屏接收端的公钥。第五请求信息还可以包括投屏发送端的标识。

S807、业务平台向投屏发送端发送第一授权信息。相应的，投屏发送端接收来自业务平台的第一授权信息。

其中，第一授权信息可以包括目标DRM多媒体数据的解密密钥。第一授权信息可以为业务平台使用投屏接收端的公钥对目标DRM多媒体数据的解密密钥加密后生成的。第一授权信息还可以参照上述图1中的S18的描述，不予赘述。

S808、投屏发送端向投屏接收端发送第一授权信息。相应的，投屏接收端接收来自投屏发送端的第一授权信息。

需要说明的是，本申请实施例中，对于步骤二中的S804-S808的执行顺序不予限制。例如，执行顺序还可以为S805、S806、S807、S808、S804。又例如，执行顺序也可以为S805、S804、S806、S807、S808。

如图8所示，上述步骤三，即投屏接收端对目标DRM多媒体数据进行解密，并播放解密后的多媒体数据，可以包括S809-S810。

S809、投屏接收端对目标DRM多媒体数据进行解密，得到解密后的多媒体数据。

其中，投屏接收端在接收到来自投屏发送端的第一授权信息后，可以使用自身的私钥对第一授权信息进行解密，得到目标DRM多媒体数据的解密密钥。进而，投屏接收端可以使用该解密密钥对目标多媒体数据进行解密，得到解密后的多媒体数据。

S810、投屏接收端播放解密后的多媒体数据。

基于图8的技术方案，投屏发送端能够代理投屏接收端完成授权信息的获取以及鉴权。投屏接收端可以根据投屏发送端的第一投屏指令直接下载目标DRM多媒体数据。如此，投屏发送端无需下载目标DRM多媒体数据，相较于现有技术中，投屏发送端既要进行鉴权以及获取授权信息，又要下载DRM多媒体数据，本申请实施例提供的方案，由于投屏发送端无需下载DRM多媒体数据，因此，降低了投屏发送端的能耗。

在图8所示方法的一种可能的实现方式中，为了提高对投屏接收端使用/播放的目标DRM多媒体数据的控制，本申请实施例提供的方法，还可以包括：响应于用户的控制指令，控制端向投屏接收端发送第一控制指令。相应的，投屏接收端接收来自控制端的第一控制指令，并根据第一控制指令，控制目标DRM多媒体数据的使用/播放。

其中，控制端可以用于控制投屏接收端。例如，控制端可以为投屏发送端，也可以为遥控器，或者，也可以为投屏接收端自身设置的控制按键。不同类型的控制端，第一控制指令的触发方式不一致。当控制端为投屏发送端时，第一控制指令的触发方式可以参照下述方式一；当控制端为遥控器时，第一控制指令的触发方式可以参照下述方式二；当控制端为投屏接收端自身设置的控制按键时，第一控制指令的触发方式可以参照下述方式三。

其中，第一控制指令可以用于控制投屏接收端使用/播放目标DRM多媒体数据的进程。例如，第一控制指令可以用于指示投屏接收端暂停播放或结束播放目标DRM多媒体数据的进程，或者，第一控制指令也可以用于指示投屏接收端加快或回退播放目标DRM多媒体数据。加快播放目标DRM多媒体数据可以是指增加目标DRM多媒体数据的播放进度。比如，将目标DRM多媒体数据的播放进度从10％快进至20％。又比如，将目标DRM多媒体数据的播放进度从30分钟快进至45分钟。回退播放目标DRM多媒体数据可以是指减少目标DRM多媒体数据的播放进度。比如，将目标DRM多媒体数据的播放进度从20％回退至20％。又比如，将目标DRM多媒体数据的播放进度从45分钟回退至45分钟。

下面对上述方式一～方式三进行描述。

方式一、响应于用户对投屏发送端的操作五，投屏发送端向投屏接收端发送第一控制指令。

示例性的，如图12a所示，响应于用户对投屏发送端101的目标DRM多媒体数据的进度按键111的操作，投屏发送端101可以向投屏接收端102发送用于增加或减少目标DRM多媒体数据的进度控制指令。例如，响应于用户对进度按键111向第一方向(如右方向)拖动的操作，投屏接收端102可以增加目标DRM多媒体数据的播放进度。又例如，响应于用户对进度按键111向第二方向(如左方向)拖动的操作，投屏接收端102可以减少目标DRM多媒体的播放进度。

示例性的，如图12b所示，响应于用户对投屏发送端101的控制按键112的操作，投屏发送端101可以向投屏接收端发送用于暂停或继续播放目标DRM多媒体数据的控制指令。例如，响应于用户对处于播放状态的控制按键112的点击触摸操作，投屏接收端102可以暂停播放目标DRM多媒体数据。又例如，响应于用户对处于暂停播放状态的控制按键112的点击触摸操作，投屏接收端102可以继续播放目标DRM多媒体数据。

需要指出的是，在通过投屏发送端控制投屏接收端时，投屏发送端可以显示投屏接收端播放目标DRM多媒体数据的进度。例如，投屏接收端在播放目标DRM多媒体数据的过程中，可以向投屏发送用于指示目标DRM多媒体数据的进度的消息。例如，该消息可以包括目标DRM多媒体数据的播放比例或时长。

基于该方式一，在一些场景中，比如，用户想切换播放目标DRM多媒体数据的投屏接收端。在该场景中，投屏发送端可以存储目标DRM多媒体数据的播放进度。响应于用户的操作六，投屏发送端与新的投屏接收端建立投屏连接。投屏发送端与新的投屏接收端建立投屏连接的过程可以参照上述S803的描述，不予赘述。

在投屏发送端与新的投屏接收端建立投屏连接之后，投屏发送端可以向新的投屏接收端发送第二投屏指令。第二投屏指令可以用于指示新的投屏接收端继续播放目标DRM多媒体数据。例如，第二投屏指令可以包括目标DRM多媒体数据的下载地址、目标DRM多媒体数据的播放进度。新的投屏接收端在接收到第二投屏指令之后，可以执行图8的步骤二和步骤三，用以继续播放新的投屏接收端。

在一些实施例中，在新的投屏接收端继续播放目标DRM多媒体数据时，最初播放目标DRM多媒体数据的投屏接收端可以继续播放目标DRM多媒体数据，也可以暂停或结束播放目标DRM多媒体数据。

方式二、响应于用户对遥控器的操作六，遥控器向投屏接收端发送第一控制指令。

示例性的，如图12c所示，响应于用户对遥控器104的快进按键1的按压操作，投屏接收端102可以增加目标DRM多媒体数据的进度。目标DRM多媒体数据增加的进度与用户按压快进按键1的时长成正比。响应于用户对遥控器104的回退按键2的按压操作，投屏接收端102可以减少目标DRM多媒体数据的进度。目标DRM多媒体数据减少的进度与用户按压回退按键2的时长成正比。如图12d所示，响应于用户对遥控器104的确定键3的按压操作，投屏接收端102可以暂停播放DRM多媒体数据。在投屏接收端102暂停播放DRM多媒体数据时，响应于用户对遥控器104的确定键3的按压操作，投屏接收端102可以继续播放DRM多媒体数据

方式三，响应于用户对投屏接收端的控制按键的操作七，投屏接收端生成第一控制指令。

示例性的，如图12e所示，响应于用户对投屏接收端102的快进按键1的按压操作，投屏接收端102可以增加目标DRM多媒体数据的播放进度。如图12e所示，响应于用户对投屏接收端102的回退按键2的按压操作，投屏接收端102可以减少目标DRM多媒体数据的播放进度。

进一步的，在投屏接收端102设置有用于控制视频播放的控制按键的情况下，响应于用户对投屏接收端102的该控制按键的按压操作，在投屏接收端102正在播放目标DRM多媒体数据的情况下，投屏接收端102可以暂停播放目标DRM多媒体数据；在投屏接收端102暂停播放目标DRM多媒体数据的情况下，投屏接收端102可以继续播放目标DRM多媒体数据。

需要说明的是，上述方式一～方式三可以具有控制优先级。例如，投屏发送端的优先级高于投屏接收端的控制按键的优先级，投屏接收端的控制按键的优先级高于遥控器的优先级。也即，在用户既使用投屏发送端控制投屏接收端，又使用遥控器控制投屏接收端时，投屏接收端可以优先执行投屏发送端的控制指令。如此，可以灵活的控制投屏接收端。

需要说明的是，本申请实施例中，为了便于业务平台或存储有目标DRM多媒体数据的CDN服务器快速的向投屏接收端下方目标DRM多媒体数据。业务平台或CDN服务器可以将目标DRM多媒体数据分割为多个数据包。例如，业务平台或CDN服务器可以按照预设粒度将目标DRM多媒体数据分割为多个数据包。每个数据包可以包括目标DRM多媒体数据的部分多媒体数据。目标DRM多媒体数据的多个数据包的每个数据包的部分多媒体数据的加密密钥一致，且每个数据包可以具有一个唯一的标识。该标识可以为数字、字符、数字与字符的组合。

其中，预设粒度可以为时长、大小等。以预设粒度为时长为例，该时长可以根据需要设置，比如，可以为1分钟、5分钟、10分钟等，不予限制。比如，目标DRM多媒体数据包的总时长为2个小时，业务平台以及CDN服务器可以按照5分钟为粒度，将目标DRM多媒体数据分割为24个数据包，分别为数据包1～数据包24。如此，业务平台或CDN服务器可以按照数据包的标识，依次向投屏接收端发送该多个数据包。

进一步的，后续在投屏接收端在接收到用于指示快进或回退的控制指令后，可以根据该控制指令指示的目标DRM多媒体数据的进度，从业务平台或CDN服务器处获取与该进度对应的数据包。例如，响应于用户通过控制端控制投屏接收端从当前进度回退至播放目标DRM多媒体数据的第43分钟(第43分钟对应的数据包为上述24个数据包的数据包9)。投屏接收端可以向业务平台或CDN服务器发送用于获取目标DRM多媒体数据的第43分钟对应的数据包的请求消息。或者，投屏接收端可以向业务平台或CDN服务器发送用于获取数据包9的请求消息。如此，业务平台或CDN服务器可以向投屏接收端发送目标DRM多媒体数据的部分数据包，无需发送目标DRM多媒体数据的全部数据，从而可以减少数据传输时延，提高了用户体验。

在图8所示方法的一种可能的实现方式中，为了提高DRM技术的应用，本申请实施例提供的方法，还可以包括：在第一投屏接收端播放第一DRM多媒体数据的过程中，投屏发送端向第二投屏接收端发送第三投屏指令，以使得第二投屏接收端播放第二DRM多媒体数据。

其中，第一投屏接收端和的第二投屏接收端可以为不同的投屏接收端。第一DRM多媒体数据与第二DRM多媒体数据可以为不同的DRM多媒体数据，也可以为相同的DRM多媒体数据。在第一DRM多媒体数据与第二DRM多媒体数据可以为不同业务平台提供的DRM多媒体数据(记为场景1)，也可以为同一业务平台提供的DRM多媒体数据(场景2)。下面对场景1和场景2进行描述。

场景1、在第一DRM多媒体数据与第二DRM多媒体数据为不同业务平台提供的DRM多媒体数据的情况下，也即，第一DRM多媒体数据与第二DRM多媒体数据为不同的应用程序提供的DRM多媒体数据。在该场景下，投屏发送端可以在后台运行第一应用程序，并通过第二应用程序向第二投屏接收端发送用于指示播放第二DRM多媒体数据的投屏指令。

示例性的，响应于用户切换至主界面的操作(如上拉显示屏、点击主界面控制键)，投屏发送端101可以恢复到如图13a所示的主界面130。该主界面1303可以包括第一DRM多媒体数据的控制界面131以及第二应用程序132。响应于用户点击播放第二应用程序的显示第二DRM多媒体数据的操作，如图13b所示，投屏发送端101可以显示第二DRM多媒体数据。

在用户选择投屏接收端为第二投屏接收端的情况下，响应于用户点击图13b所示的界面的第二DRM多媒体数据的投屏按键1301的操作，投屏发送端101可以向第二投屏接收端105发送第三投屏指令，以使得第二投屏接收端105可以播放第二DRM多媒体数据。其中，第二接收端105播放第二DRM多媒体数据的过程可以参照上述图8的技术方案，不予赘述。图13a中的“XX房间的电视”可以表示第一DRM多媒体数据的投屏接收端。后续的图中的描述，均可以参照此处，不予赘述。

场景2、在第一DRM多媒体数据与第二DRM多媒体数据为同一业务平台提供的DRM多媒体数据的情况下，也即，第一DRM多媒体数据与第二DRM多媒体数据为同一的应用程序提供的DRM多媒体数据。在该场景下，投屏发送端可以继续通过第一应用程序向第二投屏接收端发送用于指示播放第二DRM多媒体数据的投屏指令。

示例性的，响应于用户的投屏连接操作，投屏发送端可以在保持与第一投屏接收端建立连接的基础上，投屏发送端可以建立与第二投屏接收端105的投屏连接。如此，在用户选择使用第二投屏接收端105播放第二DRM多媒体数据的情况下，投屏发送端可以向第二投屏接收端发送第四投屏指令，以使得第二投屏接收端可以播放第二DRM多媒体数据。

示例性的，响应于用户的操作七，投屏发送端可以最小化第一DRM多媒体数据的控制界面，或者，投屏发送端可以以小屏的形式显示第一DRM多媒体数据的控制界面。例如，如图14a所示，响应于用户点击投屏发送端101的第一DRM多媒体数据的控制界面131的最小化按键1301的操作，投屏发送端101可以以小屏的形式显示第一DRM多媒体数据的控制界面131。例如，投屏发送端可以显示如图13b所示的界面。

例如，基于图14b的界面，响应于用户对投屏发送端101的第二DRM多媒体数据(如图中的“8”)的播放操作，投屏发送端101可以如图14c所示的界面。该界面可以包括第一DRM多媒体数据的控制界面131(以小屏的形式显示)和第二DRM多媒体数据的控制界面132(以主屏的形式显示)。

响应于用户对第二DRM多媒体数据的控制界面132的投屏控制按键1321的点击操作，投屏发送端可以向已建立投屏连接的第二投屏接收端发送用于指示播放第二DRM多媒体数据的投屏指令，以使得第二投屏接收端可以播放第二DRM多媒体数据。

进一步的，在投屏发送端同时使用不同的投屏接收端进行DRM多媒体数据进行投屏时，投屏发送端可以控制该不同的投屏接收端的DRM多媒体数据的播放进度。

示例性的，响应于用户对投屏发送端的多个DRM多媒体数据的控制操作，投屏发送端可以分别向播放DRM多媒体数据的多个投屏接收端发送控制指令。

例如，响应于用户对投屏发送端101的下拉操作，投屏发送端可以显示包括第一DRM多媒体数据的控制界面131和第二DRM多媒体数据的控制界面132的界面150该界面150可以如图15所示。图15中，第一DRM多媒体数据的控制界面131和第二DRM多媒体数据的控制界面13均可以以小屏的形式显示。

例如，响应于用户对图15中的第一DRM多媒体数据的控制界面131的控制操作，可以向第一投屏接收端发送与该控制操作对应的控制指令。具体的，可以参照上述图8的第一种实现方式的描述，不予赘述。

又例如，响应于用户对图15中的第二DRM多媒体数据的界面132的控制操作，可以向第二投屏接收端发送与该控制操作对应的控制指令。具体的，可以参照上述图8的第一种实现方式的描述，不予赘述。

基于该可能的实现方式，投屏发送端可以同时向多个投屏接收端投屏，以使得不同的投屏接收端可以同时播放DRM多媒体数据，也即，投屏发送端可以执行多进程的投屏操作，提高了DRM技术的应用场景。

上述主要从电子设备的角度对本申请实施例提供的方案进行了介绍。可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本申请所公开的实施例描述的各示例的一种投屏方法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是电子设备软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对投屏装置进行功能模块或者功能单元的划分，例如，可以对应各个功能划分各个功能模块或者功能单元，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块或者功能单元的形式实现。其中，本申请实施例中对模块或者单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

本申请另一些实施例提供了一种电子设备(如图7所示的手机700)，该电子设备中安装有多个预设应用。该电子设备可以包括：存储器和一个或多个处理器。该存储器和处理器耦合。该电子设备还可以包括摄像头。或者，该电子设备可以外接摄像头。该存储器用于存储计算机程序代码，该计算机程序代码包括计算机指令。当处理器执行计算机指令时，电子设备可执行上述方法实施例中手机执行的各个功能或者步骤。该电子设备的结构可以参考图7所示的手机700的结构。

本申请实施例还提供一种芯片系统，如图16所示，该芯片系统包括至少一个处理器1601和至少一个接口电路1602。处理器1601和接口电路1602可通过线路互联。例如，接口电路1602可用于从其它装置(例如电子设备的存储器)接收信号。又例如，接口电路1602可用于向其它装置(例如处理器1601)发送信号。示例性的，接口电路1602可读取存储器中存储的指令，并将该指令发送给处理器1601。当所述指令被处理器1601执行时，可使得电子设备(如图7所示的手机700)执行上述实施例中的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

本申请实施例还提供一种计算机存储介质，该计算机存储介质包括计算机指令，当所述计算机指令在上述电子设备(如图7所示的手机700)上运行时，使得该电子设备执行上述方法实施例中手机执行的各个功能或者步骤。

本申请实施例还提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行上述方法实施例中手机执行的各个功能或者步骤。

通过以上实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (24)

1.一种投屏方法，其特征在于，所述投屏方法包括：

响应于第一投屏操作，投屏发送端向投屏接收端发送第一投屏指令，所述第一投屏指令包括目标数字版权管理DRM多媒体数据的获取信息，所述目标DRM多媒体数据是对目标多媒体数据加密后的数据；

所述投屏接收端接收来自所述投屏发送端的所述第一投屏指令，并根据所述目标DRM多媒体数据的获取信息从业务平台处获取所述目标DRM多媒体数据；

所述投屏接收端通过所述投屏发送端获取所述目标DRM多媒体数据的授权信息，并根据所述目标DRM多媒体数据的授权信息播放所述目标多媒体数据。

2.根据权利要求1所述的投屏方法，其特征在于，所述投屏接收端通过所述投屏发送端获取所述目标DRM多媒体数据的授权信息，包括：

所述投屏接收端通过所述投屏发送端，向所述业务平台发送第二请求消息，所述第二请求消息用于请求获取所述目标DRM多媒体数据的授权信息；

所述业务平台接收来自所述投屏发送端的所述第二请求消息，并通过所述投屏发送端向所述投屏接收端发送所述目标DRM多媒体数据的授权信息；

所述投屏接收端接收来自所述投屏发送端的所述授权信息。

3.根据权利要求1或2所述的投屏方法，其特征在于，所述第二请求消息包括所述投屏接收端的公钥，所述授权信息包括用于解密所述目标DRM多媒体数据的密钥；

所述授权信息是为所述业务平台使用所述公钥对所述密钥进行加密得到。

4.根据权利要求3所述的投屏方法，其特征在于，所述投屏接收端根据所述目标DRM多媒体数据的授权信息播放所述目标多媒体数据，包括：

所述投屏接收端使用所述投屏接收端的私钥对所述授权信息进行解密，得到所述密钥；

所述投屏接收端使用所述密钥对所述目标DRM多媒体数据进行解密，得到所述目标多媒体数据；

所述投屏接收端播放所述目标多媒体数据。

5.根据权利要求1-4任一项所述的投屏方法，其特征在于，所述方法还包括：

响应于第一控制操作，所述投屏发送端向所述投屏接收端发送第一控制指令，所述第一控制指令用于控制所述目标多媒体数据的播放；

所述投屏接收端接收来自所述投屏发送端的所述第一控制指令，并根据所述第一控制指令控制所述目标多媒体数据的播放。

6.根据权利要求1-5任一项所述的投屏方法，其特征在于，在所述投屏发送端向所述投屏接收端发送第一投屏指令之前，所述方法还包括：

所述投屏发送端向所述业务平台发送第一请求消息，所述第一请求消息用于请求获取所述目标DRM多媒体数据；

所述业务平台接收来自所述投屏发送端的所述第一请求消息，并对所述投屏发送端进行鉴权；

在所述投屏发送端鉴权通过的情况下，所述业务平台向所述投屏发送端发送所述目标DRM多媒体数据的获取信息。

7.一种投屏方法，其特征在于，应用于投屏发送端，所述方法包括：

所述投屏发送端获取目标数字版权保护DRM多媒体数据的获取信息，所述目标DRM多媒体数据是对目标多媒体数据加密后的数据；

响应于第一投屏操作，所述投屏发送端向投屏接收端发送第一投屏指令，所述第一投屏指令包括所述目标DRM多媒体数据的所述获取信息；

所述投屏发送端获取所述目标DRM多媒体数据的授权信息，并向所述投屏发送端发送所述授权信息。

8.根据权利要求7所述的投屏方法，其特征在于，所述投屏发送端获取所述目标DRM多媒体数据的授权信息，包括：

所述投屏发送端接收来自所述投屏接收端的第二请求消息，并向业务平台发送所述第二请求消息，所述第二请求消息用于请求获取所述目标DRM多媒体数据的授权信息；

所述投屏发送端接收来自所述业务平台的所述目标DRM多媒体数据的授权信息。

9.根据权利要求8所述的投屏方法，其特征在于，所述第二请求消息包括所述投屏接收端的公钥，所述授权信息包括用于解密所述目标DRM多媒体数据的密钥；

所述授权信息为所述业务平台使用所述公钥对用于解密所述目标DRM多媒体数据的密钥加密得到的。

10.根据权利要求7-9任一项所述的投屏方法，其特征在于，所述方法还包括：

响应于第一控制操作，所述投屏发送端向所述投屏接收端发送第一控制指令，所述第一控制指令用于控制所述目标多媒体数据的播放。

11.一种投屏方法，其特征在于，应用于投屏接收端，所述方法包括：

所述投屏接收端接收来自所述投屏发送端的第一投屏指令，所述第一投屏指令包括目标数字版权管理DRM多媒体数据的获取信息，所述目标DRM多媒体数据是对目标多媒体数据加密后的数据；

所述投屏接收端根据所述目标DRM多媒体数据的获取信息从业务平台处获取所述目标DRM多媒体数据；

所述投屏接收端通过所述投屏发送端获取所述目标DRM多媒体数据的授权信息，并根据所述授权信息播放所述目标多媒体数据。

12.根据权利要求11所述的投屏方法，其特征在于，所述投屏接收端通过所述投屏发送端获取所述目标DRM多媒体数据的授权信息，包括:

所述投屏接收端向所述投屏发送端发送第二请求消息，所述第二请求消息用于请求获取所述目标DRM多媒体数据的授权信息；

所述投屏接收端接收来自所述投屏发送端的所述目标DRM多媒体数据的授权信息。

13.根据权利要求12所述的投屏方法，其特征在于，所述第二请求消息包括所述投屏接收端的公钥，所述授权信息包括用于解密所述目标DRM多媒体数据的密钥；

所述授权信息是为所述业务平台使用所述公钥对用于解密所述目标DRM多媒体数据的密钥加密得到的。

14.根据权利要求11-13任一项所述的投屏方法，其特征在于，所述方法还包括：

所述投屏接收端接收来自所述投屏发送端的第一控制指令，所述第一控制指令用于控制所述目标多媒体数据的播放；

所述投屏接收端根据所述第一控制指令，控制所述目标多媒体数据的播放。

15.根据权利要求1-14任一项所述的投屏方法，其特征在于，所述获取信息包括所述目标DRM多媒体数据的下载地址。

16.一种投屏系统，其特征在于，所述系统包括：投屏发送端、投屏接收端和业务平台；

所述投屏发送端用于响应于第一投屏操作，向所述投屏接收端发送第一投屏指令，所述第一投屏指令包括目标数字版本保护DRM多媒体数据的获取信息，所述目标DRM多媒体数据是对目标多媒体数据加密后的数据；

所述投屏接收端用于接收来自所述投屏发送端的所述第一投屏指令，并根据所述目标DRM多媒体数据的获取信息从所述业务平台处获取所述目标DRM多媒体数据；

所述投屏接收端还用于通过所述投屏发送端获取所述目标DRM多媒体数据的授权信息，并根据所述授权信息播放所述目标多媒体数据；

所述业务平台用于向所述投屏接收端发送所述目标DRM多媒体数据，并通过所述投屏发送端向所述投屏接收端发送所述目标DRM多媒体数据的授权信息。

17.根据权利要求16所述的投屏系统，其特征在于，

所述投屏发送端还用于向所述业务平台发送第一请求消息，所述第一请求消息用于请求获取所述目标DRM多媒体数据；

所述业务平台还用于接收来自所述投屏发送端的所述第一请求消息，并对所述投屏发送端进行鉴权；

所述业务平台还用于在所述投屏发送端鉴权通过的情况下，向所述投屏发送端发送所述目标DRM多媒体数据的获取信息。

18.根据权利要求16或17所述的投屏系统，其特征在于，

所述投屏接收端具体用于通过所述投屏接收端向所述业务平台发送第二请求消息，所述第二请求消息用于获取所述目标DRM多媒体数据的授权信息；

所述业务平台具体用于接收来自所述投屏发送端的所述第二请求消息，并通过所述投屏发送端向所述投屏接收端发送所述目标DRM多媒体数据的授权信息；

所述投屏接收端还用于接收来自所述投屏发送端的所述授权信息。

19.根据权利要求18所述的投屏系统，其特征在于，

所述第二请求消息包括所述投屏接收端的公钥，所述授权信息包括用于解密所述目标DRM多媒体数据的密钥；

所述授权信息是为所述业务平台使用所述公钥对所述密钥进行加密得到。

20.根据权利要求19所述的投屏系统，其特征在于，

所述投屏接收端还用于使用所述投屏接收端的私钥对所述授权信息进行解密，得到所述密钥；

所述投屏接收端还用于使用所述密钥对所述目标DRM多媒体数据进行解密，得到所述目标多媒体数据；

所述投屏接收端还用于播放所述目标多媒体数据。

21.根据权利要求16-20任一项所述的投屏系统，其特征在于，

所述投屏发送端还用于响应于第一控制操作，向所述投屏接收端发送第一控制指令，所述第一控制指令用于控制所述目标多媒体数据的播放；

所述投屏接收端还用于接收来自所述投屏发送端的所述第一控制指令，并根据所述第一控制指令控制所述目标多媒体数据的播放。

22.一种电子设备，其特征在于，所述电子设备为投屏发送端，所述电子设备包括：存储器和一个或多个处理器；所述存储器与所述处理器耦合，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述计算机指令被所述一个或多个处理器执行时，使得所述电子设备执行如权利要求7-10中任一项所述的方法。

23.一种电子设备，其特征在于，所述电子设备为投屏接收端，所述电子设备包括：存储器和一个或多个处理器；所述存储器与所述处理器耦合，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述计算机指令被所述一个或多个处理器执行时，使得所述电子设备执行如权利要求11-15中任一项所述的方法。

24.一种计算机存储介质，其特征在于，包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如权利要求1-15中任一项所述的方法。

Images