媒体内容分享系统、路由管理系统和社交媒体平台方法
技术领域
本发明大体涉及通过以联网移动通信装置为代表的、用于实现移动应用特征或软件工具并使能内容的社交交换的联网计算机而能共同操作或能协作的移动应用特征或软件工具。更具体地,根据本发明的移动应用特征或软件工具使得用户能够实时地分享并消费用户选择的或用户生成的内容,而同时分享并消费媒体内容,媒体内容提供了特定的背景,在该背景内,现场的用户选择的/用户生成的内容要被分享/消费。
背景技术
本讨论部分表现了在社交媒体网络内最初意识到的对如下内容的需求的产物:提供用于为消费者寻求媒体内容的来源的更加鲁棒的、有效率的和经济上有利的手段。在初期阶段,作者注意到社交媒体为多媒体内容提供了源驻存,在全部时间内对任何给定的消费者来说,没有两个源可以被视为等同。换言之,消费者通常会出于无论什么原因而优选一个源胜于另一个源,并且因此,在消费者眼中,没有两个内容提供者是等同的或总是等同的。因此,在消费内容时,消费者将能够选他或她优选的内容源。
借助于以互联网广播为例的音乐推荐或流服务、通过音轨建议或推荐来说明其示例。作者注意到,当这样的装置将基于用户喜好来推荐或建议音轨时,用户可能已经在他或她自己的音乐库中有了任何给定的推荐选择,或者可替换地,用户可能经由可替换的提供者来访问它。如果在推荐提示时对该选项的用户-消费者在法律上所有的音乐库收藏的拷贝可能为客户端寻求来源,而不是来自推荐服务提供者的流化版本,则用户消费者的其自己的拷贝的消费可能非常好地表现用于该内容的更加鲁棒、有效率的和在经济上有利的源。前述场景中的对每个潜在源的合法权利显然不同,并且因此变得为了合规的目的而需要恰当地管理和/或负责所分发的内容。
相应地,作者开发了一种系统,该系统用于经由要被(智能地)路由和消费的获得版权的媒体的第二直接源来提供同一获得版权的媒体的间接或直接源发起。这样路由的一个效果是创建了综合广播,其中媒体的原始源(例如,“间接发起源”)实际上不发送给媒体消费者,而是代之以同一获得版权的资料的消费者自己的单独的在法律上合规的“直接”访问点和源被分发。
“间接发起源”因此可以被定义为如下任何源:通过该源,消费者不“直接地”选择特定媒体来消费,而是该媒体选择来自于第二“间接发起源”,不论该源是否为计算机策划的流(诸如数字“广播”提供者或个人现场管理者(individual live curator))。当对获得版权的资料的访问得自于该资料的两个以上单独的合规媒体源时(以及在对获得版权的资料的访问得自于该资料的两个以上单独的合规媒体源的情况下),间接源到单独的直接合规源的这种(智能)路由或(智能)同步独特地使能了两个以上人之间的媒体的合法且合规的协同收听或观看体验。
可替换地,“直接发起源”可以被定义为如下源:通过该源,消费者“直接地”选择特定媒体来消费,并且该特定媒体可以获得自选自该消费者具有合法的访问权的至少两个位置的最佳或优选的数据资源位置,所述至少两个位置的优化协议基于预定的用户参数,诸如价格效率和/或数据质量。当对获得版权的资料的访问最优地或优选地得自于该资料的消费者具有合法访问权的至少两个单独的合规媒体源时(以及在对获得版权的资料的访问最优地或优选地得自于该资料的消费者具有合法访问权的至少两个单独的合规媒体源的情况下),这种对直接合规源的请求的这种(智能)路由或(智能)同步独特地使能了媒体的合法且合规的收听或观看体验。
参照与这些说明有关的且这些说明所构建于的美国专利申请No.14/099,348(‘348申请),读者将会考虑用于如下各项的功能性:分发来自本地服务器(例如,以
互联网广播为例的数字广播)的间接请求流;分发来自对等连接的服务器的间接请求流;分发来自第二直接请求源(例如,iTUNES
或
品牌的服务或云锁如
品牌的服务或云中的任何服务)的间接请求流;基于第二直接请求源对播放或流的权利来分发来自对等连接的服务器的间接请求流;基于(a)价格效率或(b)源的音质来分发来自第二直接请求源的直接请求流;以及基于第二直接请求源对播放或流的权利来分发来自对等连接的源的直接请求流。
给定了该系统的数据与源无关的方面或与云无关的方面,该系统进一步提供(a)行业权利管理、(b)合规监测、和/或(c)合规报告,其中,从次级源为内容的分发寻求来源,而不是从原始请求的源服务(包括上面列出和所呈现的示例)为内容的分发寻求来源。已知的现有技术参考文献未提供用于为消费者提供最佳地或优选地寻求来源的广播的路由同步系统,该路由同步系统包括特定智能路由机制,该特定智能路由机制用于向具有用于其的可替换的和优选的源的消费者路由所选择的在法律上受保护的内容。根据‘348申请的智能路由系统由此提供了最佳地或优选地寻求来源的广播,该广播在理念上和在专利上特征为:如间接请求或直接请求所提示的那样对消费者进行所选择的在法律上受保护的内容的最佳源分发。
根据‘348申请的智能源路由因此可以优选地特征为特定场景类型,特定场景类型包括:间接地或直接地请求的流的基于本地服务器的分发;间接地或直接地请求的流的基于对等连接的服务器的分发;或间接地或直接地请求的流的基于合法访问点的分发,其中,基于预先限定的参数集合来最佳地选择分发基础、或由用户限定分发基础,分发基础如价格效率或音频/视频质量。‘348申请的发明因此涉及将媒体内容从间接或直接发起源流送至直接源的现场同步。对于‘348申请的发明来说,认为是基础的是,以治理合规工具利用可替换的直接源(例如,个人且私人所有的合法源,而不是分发自P2P(peer to peer)网络或计算机组装的网络)为间接内容流寻求来源的能力。
换言之,消费者向诸如数字广播提供者的内容流提供者请求消费来自内容流提供者的内容。对要被流化的内容,内容流提供者和消费者各自具有不同的在法律上所有的访问点。消费者可能对来自消费者自己的源或库的该内容的直接访问请求具有合法权利,而提供者可能流化来自不同的源或库的内容。因此,相比于获得对来自提供者的内容的访问权而言,认为相对来说更加有效率或成本上更有效率的是,对来自用户自己的库的内容的直接访问点。如果内容因此源自消费者自己的库,则内容分发将或应当对内容提供者的合规报告有影响。根据‘348申请的发明的合规工具准确地为版权所有者跟踪并报告所得到的收入生成。
作者为罗伯特(Roberts)等人的美国专利申请公开No.2012/0304233被认为是最切题的与本发明有关的现有技术。罗伯特等人的公开披露了用于对于单独的内容网络相关联的媒体内容进行桥接和管理的系统和方法,并描述了一种示例性系统,该示例性系统具有位于局域媒体网络内的至少一个计算装置,该至少一个计算装置被配置为:首先生成由位于本地媒体内容网络内的一个或多个媒体内容访问装置所存储的本地媒体内容和由位于云媒体内容服务网络内的一个或多个云计算装置所存储的云媒体内容的媒体索引;然后基于媒体索引并基于预先限定的媒体管理启发式算法来管理本地媒体内容和云媒体内容。
尤其是,罗伯特等人没有教导如何横跨多个提供者来映射媒体内容。换言之,罗伯特等人的教导仅看上去指示了两个装置如何可以能够分享来自单个提供者的流,没有:(a)用于映射横跨多个提供者的媒体内容的对应机制或手段;或(b)当媒体内容与第一提供者提供的媒体内容相同时用于流送来自第二提供者的相同媒体内容的对应机制或手段。没有关于元数据映射算法的参考文献,也没有关于任何指纹机制来标识媒体内容、以及横跨多个内容提供者而将媒体内容适当地归因于其所有者或将媒体内容与其所有者相关联的任何文献。
罗伯特等人提到了两个装置可能想到分享同一媒体内容会话,但是罗伯特等人教导的方法会在以互联网为例的公共网络上呈现特别大的安全风险,并且因此罗伯特等人特别地将其方法限制为局域网。罗伯特等人表示用于同步观看的机制会是一种分享媒体会话。这假设了横跨互联网的从一个装置到另一个装置的获得版权的数据的再次传送。仅在两个装置都属于同一用户(访问该用户所拥有的公共内容库)时,这样的系统才会是合法的。
相比之下,‘348申请的发明可操作用于横跨多个用户而传送并重新创建广播,每个用户对媒体内容库具有其自己的权利或合法访问权、以及在一些情况下的对同一媒体内容库的用户自己的相应权利和合法访问权(例如,两个用户经由两个单独的合法访问点或账户来访问
品牌的库)。将罗伯特等人的教导等同于‘348申请的发明将主要导致大量版权违反,并且可能被视为P2P(peer to peer)文件分享。
罗伯特等人未能教导利用基于网络的媒体内容播放环境内的一个或多个数据源而可操作的路由和同步系统以用于最优地为消费者寻求媒体内容广播的来源,该路由和同步系统的特征在于包括计算机可实现的应用,该计算机可实现的应用用于如经由路由指示生成源所生成的路由和播放指示所提示的那样、从最佳路由指示履行源向消费者一般地同步并路由可消费的、在法律上受保护的媒体内容。
根据本发明的最佳路由指示履行源优选地与至少一个合法访问点交互。计算机可实现的应用更具体地可操作用于:经由路由指示生成源来生成路由和播放指示,路由指示生成源用于经由内容分发初级信道来管治可消费的在法律上受保护的媒体内容的播放;通过可操作的网络基础设施来向消费者建立指示传递次级信道(该次级信道平行于内容分发初级信道);以及经由指示传递次级信道将路由和播放指示传递到消费者,以用于从至少一个合法访问点为消费者寻求可消费的、在法律上受保护的媒体内容。
具体地根据前述引用的回顾、以及一般地根据现有技术的考虑,将看到现有技术意识到了对如下的需要:另外由‘348申请的说明书所教导的、但进一步通过将同时社交内容提供和消费包含在下层的媒体广播体验的背景中来优化或改进的发明。进一步地,现有技术意识到了对如下系统的需要:通过该系统,用户可控制下层的媒体广播体验的背景中的社交内容覆盖的源和类型,该后一特征反映了美国专利申请No.15/048,480(‘480申请)中另外给出的说明,本说明与该美国专利申请也相关并且是基于该美国专利申请而构件的本说明,这将在下文中更加详细地概述。
发明内容
本发明的许多目的之一是基本提供计算机可实现的移动应用、软件工具、或具有社交联网计算机(诸如,平板型计算机、移动电话、或用于实现本文企图的功能性的类似的其他移动通信装置)可执行的可读指令的非暂时性计算机可读介质,并且在本文中被称作VERTIGOSM品牌的计算机可实现的移动应用或软件工具。VERTIGOSM品牌的计算机可实现的移动应用或软件工具主要使能了基于音乐的社交媒体网络,在该社交媒体网络中,用户以同步的音乐来分享现场内容。
根据本发明的VERTIGOSM品牌的计算机可实现的移动应用或软件工具主要准许用户通过实时地分发的视频、音频、照片和文本或SMS消息的形式的社交内容分享其生活的现场(即,SHARE LIVE)瞬间,而同时关注如从任何整合的音乐提供者(无论是从免费的、低质量的源,还是从高昂的、高质量的源)重新广播的和寻求来源的、以音乐消费为例的下层的或背景的媒体内容。
在SHARE LIVE会话期间,根据本发明的VERTIGOSM品牌的计算机可实现的移动应用或软件工具维护同时发生的多个数据流,同时发生的多个数据流管理分别来自多个媒体(例如,视频和/或音频)通道的媒体播放信息(例如,元数据)。作为示例性的背景媒体的音乐不被记录用于作为视频或音频流的一部分而被分发。相反,根据本发明的VERTIGOSM品牌的计算机可实现的移动应用或软件工具经由便利的套接字来持续地传送关于播放事件的信息。
社交网络内的且装备有VERTIGOSM品牌的计算机可实现的移动应用或软件工具的接收装置可以被称作LISTEN LIVE装置。LISTEN LIVE装置与专用解决方法进行通信以识别SHARE LIVE广播者正在播放/分享的音轨并且恰当地为该音轨寻求来源。VERTIGOSM品牌的计算机可实现的移动应用或软件工具与横跨多个第三方提供者的音乐实体和ID的单独维护的抽象数据库进行通信,使得能够横跨该平台为收听者的播放合法地且多样化地寻求来源。
因此,会看出,VERTIGOSM品牌的计算机可实现的移动应用或软件工具促进了收听者可以被赋予的已有的数字权利。因为每个收听者必须与合法提供者连接以流化高昂的内容,所以经由VERTIGOSM品牌的计算机可实现的移动应用或软件工具的社交分享可以通过激励增加采用高昂的音乐订阅来很好地影响该行业。
进一步地,在LISTEN LIVE装置上,如果适用的话,独立的社交广播流可以被覆盖在来自收听用户所连接的提供者或非订阅提供者的音乐的直接播放上。处理事件的微服务维护并合并广播者的音乐播放动作和社交内容,音乐播放动作和社交内容以定时精度来同步于多个收听者的装置上以用于多个同时的收听者的完全的一致的LISTEN LIVE体验。
因此,会看出,根据本发明的VERTIGOSM品牌的计算机可实现的移动应用或软件工具使能了其中多个用户以同步的音乐来分享现场内容的基于音乐的社交媒体网络。优选地,经由现场流协议来间歇地传送同步内容,并且可以优选地以现场媒体协议的单独的音频轨道或经由单独的超文本传输协议或http请求来分发同步内容。本发明的其他目的以及其特定特征、要素和优点将被阐明,或以下具体实施方式和附图特征中变得明显。
附图说明
图1是根据本发明的广播初始化或现场流发起序列的流程图。
图2是根据本发明的第一可替换的音乐同步序列的流程图。
图3是根据本发明的第二可替换的音乐同步序列的流程图。
图4是根据本发明的第三可替换的音乐同步序列的流程图。
图5是根据本发明的第四可替换的音乐同步序列的流程图。
图6是根据本发明的第五可替换的音乐同步序列的流程图。
图7是根据本发明的用于客户端广播的服务器侧流程的流程图。
图8是根据本发明的用于一个以上广播客户端的服务器侧流程的流程图。
图9是根据本发明的用于收听客户端的服务器侧流程的流程图。
图10是根据本发明的服务器侧系统的流程图。
图11是根据本发明的第一可替换的间歇的视频/音频评论序列的流程图。
图12是根据本发明的第二可替换的间歇的视频/音频评论序列的流程图。
图13是根据本发明的、详细描述了现场流哈希过程的、用于利用第三方社交内容来对现场馈送进行同步的第一可替换的方法的流程图。
图14是根据本发明的、详细描述了社交评论和映射过程的、用于利用第三方社交内容来对现场馈送进行同步的第二可替换的方法的流程图。
图15是根据本发明的、详细描述了流哈希和社交评论同步过程的、用于利用第三方社交内容来对现场馈送进行同步的第三可替换的方法的流程图。
图16是根据本发明的、详细描述了流哈希和社交评论搜索过程的、用于利用第三方社交内容来对现场馈送进行同步的第四可替换的方法的流程图。
图17是对于本发明的实践而言为核心的移动应用所使能的一般性应用初始化屏幕截图,该屏幕截图示出了开始提示和一系列社交化范围提示。
图18是根据本发明的媒体抽象层或系统的流程图。
图19是对于本发明的实践而言为核心的移动应用所使能的第二屏幕截图,该屏幕截图示出了提供者认证布局和链接按钮或用于链接到提供者的提示。
图20是对于本发明的实践而言为核心的移动应用所使能的第三屏幕截图,该屏幕截图示出了统一的动态搜索屏幕,该屏幕示出了标志提示以及播放或添加音轨提示。
图21是对于本发明的实践而言为核心的移动应用所使能的第四屏幕截图,该屏幕截图示出了第一播放事件屏幕并重点显示了“上一”提示、“暂停”提示和“前进”提示。
图22是对于本发明的实践而言为核心的移动应用所使能的第五屏幕截图,该屏幕截图示出了第二播放事件屏幕并且重点显示了“播放”提示和“搜索”提示。
图23是对于本发明的实践而言为核心的移动应用所使能的第六屏幕截图,该屏幕截图示出了第三播放事件屏幕并且重点显示了歌曲音乐单元提示。
图24是对于本发明的实践而言为核心的移动应用所使能的第七屏幕截图,该屏幕截图示出了第一评论事件屏幕并且重点显示的视频评论/广播提示。
图24A是对于本发明的实践而言为核心的移动应用所使能的第一可替换的方法的第一序列屏幕截图示图,该屏幕截图示出了用户的手指在第一激活序列位置以发起视频广播。
图24B是对于本发明的实践而言为核心的移动应用所使能的第一可替换的方法的第二序列屏幕截图示图,该屏幕截图示出了用户的手指在第二激活序列位置以锁定用于传送的视频广播内容。
图24C是对于本发明的实践而言为核心的移动应用所使能的第一可替换的方法的第三序列屏幕截图示图,该屏幕截图描绘了第三激活序列位置,因此以锁定状态来广播视频内容。
图24D是对于本发明的实践而言为核心的移动应用所使能的第二可替换的方法的第一序列屏幕截图示图,该屏幕截图示出了用户的手指在第一激活序列位置以轻触发起来自视频广播的静止帧。
图24E是对于本发明的实践而言为核心的移动应用所使能的第二可替换的方法的第二序列屏幕截图示图,该屏幕截图示出了静止帧再现,该静止帧再现具有可替换的用于广播静止帧再现的提示或用于取消静止帧再现的提示。
图24F是对于本发明的实践而言为核心的移动应用所使能的第二可替换的方法的第三序列屏幕截图示图,该屏幕截图描绘了用户的手指经由对应的提示来选择广播静止帧再现。
图24G是对于本发明的实践而言为核心的移动应用所使能的第二可替换的方法的第四序列屏幕截图示图,该屏幕截图描绘了用户的手指经由对应的提示来选择取消静止帧再现。
图25是对于本发明的实践而言为核心的移动应用所使能的第二屏幕截图,该屏幕截图示出了第二评论事件屏幕并且重点显示了音频评论提示。
图25A是对于本发明的实践而言为核心的移动应用所使能的第一可替换的方法的第一序列屏幕截图示图,该屏幕截图示出了用户的手指在第一激活序列位置以发起音频评论广播。
图25B是对于本发明的实践而言为核心的移动应用所使能的第一可替换的方法的第二序列屏幕截图示图,该屏幕截图示出了用户的手指在第二激活序列位置以锁定用于传送的音频评论广播内容。
图25C是对于本发明的实践而言为核心的移动应用所使能的第一可替换的方法的第三序列屏幕截图示图,该屏幕截图描绘了第三激活序列位置,因此以锁定状态来广播音频评论内容。
图26A是对于本发明的实践而言为核心的移动应用所使能的第九屏幕截图的第一替换方式,该屏幕截图示出了结合了第一广播的事件屏幕并且以放大轮廓的图片瓦片(tile)或缩略图来重点显示了广播瓦片/行提示。
图26B对于本发明的实践而言为核心的移动应用所使能的第九屏幕截图的第二替换方式,该屏幕截图示出了结合了第一广播的事件屏幕并且以缩小轮廓的图片条来重点显示了广播瓦片/行提示。
图27是对于本发明的实践而言为核心的移动应用所使能的第十屏幕截图,该屏幕截图示出了结合了第二广播的事件屏幕并且重点显示了分享链路提示。
图28是对于本发明的实践而言为核心的移动应用所使能的第十一屏幕截图,该屏幕截图示出了结合了第三广播的事件屏幕并且重点显示了推送通知提示。
图29是对于本发明的实践而言为核心的移动应用所使能的第十二屏幕截图,该屏幕截图示出了第一聊天事件屏幕并且重点显示了输入框提示。
图30是对于本发明的实践而言为核心的移动应用所使能的第十三屏幕截图的第一示图,该屏幕截图示出了第二聊天事件屏幕并且重点显示了聊天历史功能。
图31是对于本发明的实践而言为核心的移动应用所使能的第十四屏幕截图的第一示图,该屏幕截图示出了第三聊天事件屏幕并且重点显示了聊天历史功能。
图31A是对于本发明的实践而言为核心的移动应用所使能的第十四屏幕截图的第二示图,该屏幕截图示出了第三聊天事件屏幕并且重点显示了聊天历史功能,其中用户的手指被描绘为从事一提示以返回到第十三屏幕截图或将用户导航至第十三屏幕截图。
图31B是对于本发明的实践而言为核心的移动应用所使能的第十三屏幕截图的第二示图,该屏幕截图示出了第二聊天事件屏幕并且重点显示了进入的聊天消息功能。
图32是对于本发明的实践而言为核心的移动应用所使能的第十四屏幕截图的放大第二示图,该屏幕截图示出了第三聊天事件屏幕并且重点显示了聊天历史功能,其中,用户的手指被描绘为从事广播收听者提示以返回到第十三屏幕截图或将用户导航至第十三屏幕截图。
图32A是对于本发明的实践而言为核心的移动应用所使能的第十五屏幕截图的放大示图,该屏幕截图示出了广播收听者的列表。
图33是对于本发明的实践而言为核心的移动应用所使能的第一应用初始化屏幕截图,该屏幕截图示出了由不完整的用户手指所从事的开始提示。
图33A是对于本发明的实践而言为核心的移动应用所使能的第二应用初始化屏幕截图,该屏幕截图示出了开始提示和一系列社交化范围提示,每个社交化范围提示都由不完整的用户手指从事。
图34是对于本发明的实践而言为核心的移动应用所使能的第一GO LIVE(去现场)初始化屏幕截图,该屏幕截图示出了由不完整的用户手指从事的GO LIVE开始提示。
图34A是对于本发明的实践而言为核心的移动应用所使能的中间GO LIVE初始化屏幕截图,该屏幕截图示出了随着时间流逝的视觉显示。
图35是对于本发明的实践而言为核心的移动应用所使能的第一可替换的应用初始化屏幕截图,该屏幕截图示出了由不完整的用户手指双击从事的开始提示。
图35A是对于本发明的实践而言为核心的移动应用所使能的第二可替换的应用初始化屏幕截图,该屏幕截图示出了开始提示、以及如由不完整的用户手指利用对应的用户提示而从事的可操作地作出的用于广播发起或广播终止的分享/结束下拉选项。
图36是对于本发明的实践而言为核心的移动应用所使能的可替换的第十二屏幕截图,该屏幕截图示出了具有输入框提示的第一聊天事件屏幕并且重点显示了可替换的相册库或存档提示。
图36A是对于本发明的实践而言为核心的移动应用所使能的第一可替换的方法的第一序列屏幕示图,该屏幕截图示出了具有输入框提示的第一聊天事件屏幕并且重点显示了用于将所选择的幻灯片维持在播放/运行状态的幻灯片锁定功能的第一步骤。
图36B是对于本发明的实践而言为核心的移动应用所使能的第一可替换的方法的第二序列屏幕截图示图,该屏幕截图示出了相册库屏幕截图并且重点显示了用于将所选择的幻灯片维持在播放/运行状态的幻灯片锁定功能的第二步骤。
图36C是对于本发明的实践而言为核心的移动应用所使能的第一可替换的方法的第三序列屏幕截图示图,该屏幕截图示出了幻灯片屏幕截图并且重点显示了用于将所选择的幻灯片维持在播放/运行状态的幻灯片锁定功能的第三步骤。
图37是对于本发明的实践而言为核心的移动应用所使能的第一可替换的方法的放大第二序列屏幕截图示图,该屏幕截图示出了相册库屏幕截图并且重点显示了照片/视频相册库,从该照片/视频相册库来选择视觉显示。
图37A是从图37中另外描绘的相册库屏幕截图中选择的光视觉显示屏幕截图。
图38是示例性广播客户端的屏幕截图,该屏幕截图示出了广播客户端上播放的视频再现和音轨06–音乐流,两者都可以被广播或与广播收听者分享,其中有如进一步描绘的三个广播收听者。
图38A是示例性第一广播收听者客户端的屏幕截图,该屏幕截图示出了被同步用于播放于示例性的第一播放收听者客户端上的、进入的视频再现和音轨06–音乐流,该进入的视频再现和音轨06–音乐流源自与图38中另外描绘的广播客户端相同的提供者但是通过与图38中另外描绘的广播客户端所提供的视频再现和社交评论的背景不同的提供者账户。
图38B是示例性第二广播收听者客户端的屏幕截图,该屏幕截图示出了被同步用于播放于示例性第二广播收听者客户端上的、进入的视频再现和音轨06–音乐流,该进入的视频再现和音轨06–音乐流源自与图38中另外描绘的广播客户端所提供的视频再现和社交评论的背景不同的提供者。
具体实施方式
现在更具体地参考附图,本发明大体上提供或实现了一种社交媒体网络,在该社交媒体网络内,在注意到作为情景基础的下层同步媒体广播的同时,网络用户实时地分享和使用(consume)社交内容,所分享和使用的社交内容在该情景基础内或相对于该情景基础进行考虑。在示例性实施例或优选实践中,同步媒体广播是基于音乐的。同步内容经由直播流传输协议(live streaming protocol)被间歇地发送,并且音乐或媒体通过直播媒体协议的单个音频/媒体轨或者经由单个http请求来进行递送。
因此,本发明所实现的基于音乐的社交媒体网络通过至少两个(优选地一系列)联网计算机和经由所述联网计算机可操作的计算机可执行指令来实现。本说明书背景下的计算机可优选地由移动通信装置10所示例或代表,比如为智能手机和/或平板电脑,每个移动通信装置基本配备有根据本发明的带有VERTIGOSM标记的计算机可执行移动应用或软件工具22。
图1的流程图大体描绘了根据本发明的直播流传输会话发起或广播初始化序列。正如为支持说明书而提交的截屏叙述所进一步总体描绘的那样,根据本发明的带有VERTIGOSM标记的计算机可执行移动应用或软件工具22由具有视觉显示器11的用户装置10来进行操作或执行。带有VERTIGOSM标记的计算机可执行移动应用或软件工具22所实现的直播流传输或广播会话由用户在其装置10上经由视觉显示器11上所显示的初始化提示符12来发起。
一旦广播会话的范围在过程100处被选择,客户端就发起过程102和103处的两个推送通知序列中的一者(取决于范围选择)以及过程104处的Web实时通信WebRTC流传输会话。在决策码元101处,基于或取决于范围选择,如在103处所描绘的,包括了附加的“发布到用户提要”序列。广播流传输会话在105处经由应用服务器80与客户端程序22之间的套接字连接进行发起。一旦流传输会话被发起,在过程106处,客户端应用22开始发送发布者/订阅者套接字上的播放事件和评论事件。播放事件包括有关播放改变的信息、负载信息以及用来同步收听客户端上的播放的时间戳信息。评论事件包括用于视频和音频评论的开始/结束时间。
本发明构想或设想了用于同步音乐/媒体播放与实时视频和音频内容的五种可能方法或选项。图2的流程图描绘了用于同步音乐/媒体播放与实时视频和音频内容的第一替代方法或选项;图3的流程图描绘了用于同步音乐/媒体播放与实时视频和音频内容的第二替代方法或选项;图4的流程图描绘了用于同步音乐/媒体播放与实时视频和音频内容的第三替代方法或选项;图5的流程图描绘了用于同步音乐/媒体播放与实时视频和音频内容的第四替代方法或选项;以及,图6的流程图描绘了用于同步音乐/媒体播放与实时视频和音频内容的第五替代方法或选项。
根据图2与图3的对比观察,可以看出,第一替代序列优选地包括在107处单独编码摄像头输出108、麦克风输出109和音乐输出110中的每一个以得到相应的WebRTC视频轨111、音频轨112和音频轨113,从而经由用户数据报分组UDP套接字115递送所处理的到收听客户端114。相比之下,第二替代序列优选地包括在107处将摄像头输出108和麦克风/音乐输出109/110编码为相应的WebRTC视频和音频轨118和119以经由UDP套接字115递送到收听客户端114。
图2所描绘的方法因此提供向实时会话提供了增加的单个音频轨,该单个音频轨在接收客户端上进行发送和同步。音频轨之所以未与用于视频和音频评论的音频轨合并,是为了避免产生受版权保护的下层作品或内容的衍生作品。在该方法中观察到延迟的略微增加。相比之下,图3所描绘的方法略微降低了实时会话的延迟,但是其代价为通过合并两个音频流而产生了衍生作品。
图4中所大体描绘的第三方法或选项包括使用播放事件连同音频信号检测。这意味着,当在过程120处发起视频/音频评论事件时,客户端在过程121处发出事件以向收听客户端通知评论正在进行。收听客户端在过程122处接收到事件并且追踪WebRTC流的音频轨。客户端在(非静音)过程123检测到音频信号,并且在过程124处将事件时间戳映射到当前网络时间协议NTP时间。
然后,该方法通过以下方式来估计广播时间:在过程121处得到用于通过套接字发送的评论事件的事件开始时间,在接收端上在过程123处从检测到评论(非静音音频信号)的时间戳中减去事件开始时间,从而在过程124处得到两个装置之间的实际延迟((检测到信号的时间戳)-(评论事件时间戳)=网络延迟)。然后,该延迟被用来计算估计广播时间,估计广播时间被用来在过程125处推迟媒体播放事件,以使得媒体播放事件与WebRTC视频/音频流大致同步地开始。
第四方法或选项包括使用播放事件连同过程126处的WebRTC分组的散列值。在过程127处,在通过UDP套接字发送分组之前,生成散列值。在过程128处,散列值与时间戳一起通过传输控制协议TCP套接字86进行发送。接收客户端在过程129处接收到散列值和时间戳消息,并在过程130处散列所有的传入UDP网络分组。一旦在过程131处用于网络分组的散列值匹配来自TCP套接字消息的散列值,应用从接收到的时间戳(当分组散列值匹配时从装置处获得)中减去发送的时间戳(通过TCP套接字86进行发送)。这在过程132处提供了估计的网络延迟,估计的网络延迟可被用以通过在抖动缓冲器的尺寸(以微秒计)上加上网络延迟来计算播放延迟。在过程133处,所计算的播放延迟则可被用来同步媒体播放时间与WebRTC流。
第五方法或选项要求在过程134中,分组被注入到WebRTC UDP端口的数据流中。该分组包含要求的UDP分组信息以及时间戳。在过程135处,当所有WebRTC数据被发送时,应用通过同一UPD端口发送计时器上的该分组。分组信息在过程136处被接收并被用来在过程137处通过从UDP分组中所接收到的时间戳中减去抖动缓冲器的尺寸来生成用于WebRTC播放的持续时间。在过程138处,广播持续时间被用来同步播放事件与WebRTC视频流。
系统部件被认为基本地并且优选地包括应用服务器20,媒体服务器或WebRTC 21,http直播流传输HLS编码服务82,广播客户端83,收听客户端84以及内容传递网络CDN 85。参考图7至图10,读者将考虑如图7所大体描绘的用于单个客户端广播电台的服务器侧流程图;如图8所大体描绘的用于多个客户端广播电台的服务器侧流程图;以及如图9所大体描绘的用于收听客户端的服务器侧流程图。图10描绘了相互关联的系统方面及其之间的流程用于帮助读者理解本发明。
应用服务器80提供了服务,该服务充当收听客户端与广播客户端之间的中介以发起和终止实时WebRTC会话并且生成TCP事件通道。应用服务器80进一步生成会话ID,会话ID被用来加入和终止适当的WebRTC会话。取决于初始化过程中所选择的背景或范围,会话ID或广播ID由客户端通过发布到提要(posts to feed)、文本消息、链接和推送通知来进行分享。作为通过TCP发送时间戳的替代方式,时间戳也可作为网络分组的一部分通过UDP/TCP被发送到WebRTC服务器81,或者从来自视频或音频流的音频或视频帧中提取,在这种情况下,收听装置可确定不带有散列值的播放处的时间戳。
在图10的139中,媒体服务器81主要作用在于对从广播客户端到收听客户端的WebRTC分组进行中继,但也将WebRTC流转换为H.264流。媒体服务器81通常通过UDP端口与客户端交互,并且经由会话描述协议SDP握手发生连接。应用服务器80与媒体服务器81之间的连接优选地使用富客户端平台RCP协议。
HLS编码服务82从媒体服务器81接收H.264流,对流进行分段,并且生成HLS播放列表,在图10中的140处HLS播放列表被上传到CDN 85。播放客户端83通过与应用服务器80交互来发起WebRTC直播会话,并通过UDP经由媒体服务器81发送WebRTC数据。收听客户端84经由选择协议加入直播流传输会话。选自WebRTC或HLS的选择协议由动态计算值“n”来确定;值“n”是每个会话所允许的WebRTC收听会话的最大数量。值“n”基于系统负载和广播客户端83的数量动态地调整。
参考图7,读者将考虑过程141,通过过程141,应用服务器80处理来自客户端应用的SDP提议(offer)和初始化请求,并通过RPC发送SDP提议到媒体服务器81。媒体服务器81处理SDP提议以提供SDP应答,并通过RPC响应于应用服务器80。然后,应用服务器80通过TCP套接字86发送SDP应答到客户端。在这一点上,读者可参阅图7中的过程142。在子过程149处,通过TCP套接字86创建消息通道用于传递事件数据。客户端应用可连接的TCP套接字就绪消息通道(TCP socket-ready message channels)的列表在子过程150处被返回,因而在子过程151处,应用服务器80监视用于客户端数据的套接字通道。
媒体服务器81通过RPC发送交互式连接建立ICE候选项到应用服务器80,以及应用服务器80通过TCP套接字86发送ICE候选项到广播客户端83。如在过程143中所标记的,客户端应用处理SDP应答,并通过TCP套接字86发送ICE候选项到应用服务器80。通过UDP,在查询过程144处,媒体服务器81尝试与客户端应用进行SDP握手。如果握手失败,在过程145处,所有连接被终止。如果握手成功,在过程146处,媒体服务器81与用于WebRTC分组的客户端应用进行UDP套接字连接。在过程147处,媒体服务器81处理WebRTC,并产生H.264流。通过TCP,在过程148处,HLS编码服务82对H.264流进行分段,并生成被上传到CDN的HLS播放列表。
参考图8,读者将考虑多个广播客户端背景下的服务器侧流程。在该场景下,在过程152处,(收听)客户端应用发送带有SDP提议和会话ID的请求到应用服务器80。在查询过程153处,应用服务器80通过TCP基于广播环境调整最大允许WebRTC连接。在过程141处,应用服务器80处理来自(收听)客户端应用的SDP提议,并通过RCP中继该SDP提议到媒体服务器81。
媒体服务器81处理SDP提议,并通过RCP返回SDP应答和ICE候选项列表到应用服务器80。应用服务器80通过TCP套接字86发送SDP提议和TCP事件通道名称到(收听)客户端应用,然后,客户端应用处理SDP应答,并通过TCP套接字86发送ICE候选项到应用服务器80。通过UDP,在查询过程144处,与单个广播客户端的情景一样,媒体服务器81尝试与客户端应用进行SDP握手。如果握手失败,在过程145处,所有连接被终止。如果握手成功,在过程146处,媒体服务器81与用于WebRTC分组的客户端应用进行UDP套接字连接。
参考图9,读者将考虑收听客户端背景下或视角下的服务器侧流程。在152处,客户端应用发送带有SDP提议和会话ID的请求到应用服务器80。在查询过程155处,应用服务器80通过TCP查询媒体服务器81处用于UDP流传输的连接计数。如果连接计数大于值“n”,媒体服务器81通过TCP返回带有TCP事件通道列表的HLS视频URL。然后,在过程156处,客户端应用流传输来自CDN端点的HLS。如果连接计数小于值“n”,在过程141处,应用服务器80通过经由RCP中继来自客户端应用的SDP提议到媒体服务器来处理该SDP提议。
与上文相同,媒体服务器81处理SDP提议,并通过RCP返回SDP应答和ICE候选者列表到应用服务器80。应用服务器80通过TCP套接字86发送SDP提议和TCP事件通道名称到(收听)客户端应用,然后,客户端应用处理SDP应答,并通过TCP套接字86发送ICE候选项到应用服务器80。通过UDP,在查询过程144处,与单个广播客户端的情景一样,媒体服务器81尝试与客户端应用进行SDP握手。如果握手失败,在过程145处,所有连接被终止。如果握手成功,在过程146处,媒体服务器81与用于WebRTC分组的客户端应用进行UDP套接字连接。
特别地,本发明的软件工具所提供或实现的带有VertigoSM标记的分享直播系统也基于将间歇视频、音频和聊天(例如,短消息服务SMS)评论覆盖在同步媒体(例如,音乐)流上的能力。用以提供该同时功能性的能力被认为对实践本发明至关重要。视频、音频和聊天评论的间歇特性允许更被动的社交体验,其中,用户分享直播事物将感到更小的压力,但却被允许在选择时刻进行分享,而在其他时间,用户可以仅分享带有聊天消息的同步媒体(例如,音乐)流。在这一点上,读者可参阅图11和图12。比较地参考图11与图12,读者将考虑用于发送或广播用户产生的内容到客户端网络内的一个或多个收听装置的替代装置。
图11详细描述了社交嘉宾或广播员分享覆盖在下层流传输内容(例如照片等)上的静止图像的过程。在过程160处,分享直播会话发起,以及客户端应用空的视频/音频帧。在过程161处,空的视频帧在初始化后被静止图像所代替,此后,在过程162处,用户可按下激活(例如,记录)提示符。一旦激活,在过程163处,客户端应用转换输入并向WebRTC馈送来自硬件的直播视频/音频。当在过程164处用户释放激活提示符时,在过程165处,客户端应用发送空的音频数据和来自过程161的静止图像到收听客户端。
图12详细描绘了广播员在下层媒体(例如音乐)流上覆盖音频/视频评论的过程。在过程166处,分享直播会话发起,以及客户端应用创建直播视频帧和空的音频帧。在过程167处,用户按下激活提示符(例如,音频/视频记录按钮),并且客户端应用开始发送音频。然后,在过程168处,客户端应用发送音频/视频评论事件到合适的套接字通道。在过程169中,当用户释放激活提示符时,应用发送空的音频帧。然后,在过程170处,应用发送视频/音频评论事件到合适的套接字频道。当在过程171处收听客户端加入分享直播会话,在过程172处,收听应用获得所有视频/音频评论事件以供使用。在过程173处,如果视频功能默认关闭,应用可基于评论事件确定是否在视频视图上方施加图像覆盖。
读者应当注意,广播收听折中了上述音乐同步方法所生成的时间码。在这一点上,时间码被用来同步音乐播放、聊天消息、以及经由WebRTC流所传来的视频/音频评论。如前所详述并且由图11和图12所支持的那样,取决于所使用的间歇评论方法的不同,广播收听也使用时间码以同步直播视频内容上的图像覆盖。在会话上存在多于一个广播电台的情况下,音乐将被同步至主应用或初始应用的WebRTC流。
在会话上存在多于一个广播电台(例如,组流传输会话)的情况下,音乐优选地被同步至服务器会话。可使用多个方法优选地得到服务器会话,所述方法包括:(a)通用分享和同步的时间戳(NTP);(b)分享的经组织的播放列表;(c)一旦第一用户加入组流传输会话,播放开始时间开始——一旦播放开始,所有其他用户将加入会话,并且假设不存在播放中断,同步播放使用初始播放开始时间,;(d)假设不存在播放中断(将假设正常播放速率),NTP时间和歌曲持续时间可被用来确定播放;(e)所有客户端可将播放同步至该服务器会话位置;以及(f)一旦所有应用/用户退出组流传输,会话可被复位。
比较地参考图13至图16,读者可考虑用于同步直播馈送与第三方社交内容的多种不同方法,这些方法包括:图13所大体描绘的直播流散列过程,图14所大体描绘的社交评论索引和映射过程,图15所大体描绘的流散列和社交评论同步过程,以及图16所大体描绘的流散列和社交评论寻找过程。
参考图13,读者将更具体地考虑,在发起步骤174处,直播流散列过程基于直播视频/音频流。在过程175处,在播放过程中可周期地(例如,每秒)生成视频/音频流的散列值,并且在过程176中,散列值被映射到NTP时间戳。参考图14,读者将会考虑到在过程177处社交评论索引和映射过程可开始于通过基于预定的标签监视用于评论的社交网站。
在过程178处,当识别出与预定的标签相关联的评论时,该评论可优选地在NTP时间戳一出现时就被映射到该时间戳,并且被索引。在过程179处,基于地理位置(如果可获得),使用平均直播视频延迟因子来调整时间戳。如果用户位于事件地点的地理坐标处或者地理隔开区域内,则不施加偏移。在过程180处,如果用户不位于事件地点的地理坐标处或者地理隔开区域内,则偏移可被优选地施加到评论。关于地理隔开区域的更详细讨论,读者可参阅于2016年9月6日提交美国专利商标局的美国专利申请No.15/124,014,本发明的说明书是建立在该申请说明书的基础上的。
参考图15,读者将考虑根据本发明的流散列和社交评论过程。考虑发起过程181处的点播视频/音频流,则可以生成视频/音频流的散列值,在过程182处,该视频/音频流可被接收为二进制数据或从麦克风输入进行接收。散列值可被用来(a)在过程183处识别流,以及(b)在过程184处将此时的当前流位置映射到直播会话过程中所索引的NTP时间。NTP时间被用来在过程185处获得当前播放时以及此前几秒所作的社交评论,以使得在过程186处评论可被同步显示。
参考图16,读者将考虑流散列和社交评论寻找过程。考虑发起过程187处的点播视频/音频流,在过程188处同样生成散列值。在过程189处散列值被用来映射此时的当前流位置,此后,在过程190处通过使用当前NTP和评论NTP被优选地计算以向前或向后寻找所需要的时间。然后,在过程191中,评论可被更适当地在视频流中进行定位。
参考图17,读者将考虑由智能手机示例的计算机类型的移动通信装置10的视觉显示器上的应用发起截屏。在广播会话发起提示符12被按下或激活之前,在步骤100处从显示在视觉显示器11上的一组范围选择或选项13中选取广播范围。因此,在通过提示符12激活而发起广播会话之前,在100处,用户选取广播会话的范围。广播会话范围选项13优选地包括或包含“+1”14、“核心”15、“世界”16和“邀请”17。与每种范围选项13相关联的目标广播受众将在下文中大体地且优选地参考图17进行详细讨论,图17中的截屏示出了范围选项13和发起提示符12。
当广播会话旨在面向或包括已被广播用户所预选取且被添加到“+1”组中的单个用户时,可选取“+1”选项14。该组中只有1个用户。当广播会话旨在面向被称为“核心”的预先确定用户组(或多个组)时,可选取“核心”选项15。当广播会话旨在面向广播用户的所有追随者时,可选取“世界”选项16。当用户想要自定义广播接收者列表时,可选取“邀请”选项17,广播接收者列表是从广播会话所针对的用户追随者或联系人列表中选取的。
一旦进行了范围选择100,加载屏幕出现在视觉显示器11上,此时广播或分享直播会话被创建。广播会话创建过程包括:(a)创建用于视频传输的视频通道;(b)创建用于传输音频的音频通道;以及(c)创建广播事件传输通道。广播事件是响应于广播用户所采取的动作,在广播用户的客户端上生成的事件。所有广播事件携带了帮助收听客户端适当定位广播事件的时间戳。
播放事件通常具有抽象实体标识或ID,所述抽象实体标识或ID由广播客户端插入以使得所有收听客户端能够使用抽象实体路由和19处的客户端软件开发工具或客户端SDK来播放来自这些收听客户端的流媒体供应商的歌曲。根据本发明的媒体抽象层或系统大体上在图18中被描绘出,并且该媒体抽象层或系统是诸如歌曲、专辑和艺术家之类的媒体实体的抽象化。这些抽象化是元数据的集合,所述元数据的集合用于向用户描述实体,同时映射至组成这些实体的媒体文件在多个供应商上的位置。
抽象化开始于客户端的SDK 19,其对20处的核心应用逻辑中的多个供应商的SDK进行处理的复杂度进行抽象。SDK 19和核心应用逻辑都存在于VERTIGOSM品牌计算机可执行移动应用程序或软件工具22中。客户端SDK 19从核心应用程序获取抽象实体ID,该核心应用程序可以来自2个来源。第一个来源是从同步服务40接收43的抽象播放列表。同步服务40在从客户客户端应用程序22接收39到同步请求之后,从第三方流媒体供应商41检索播放列表。
客户端应用程序22对播放列表程序进行抽象化,并且将所有歌曲的ID解析为歌曲的抽象ID,所述歌曲的抽象ID从解析器21被检索42到。一旦结构和歌曲的ID已经被抽象化,同步服务40通知43应用程序22同步过程已经完成,并且客户端应用程序22检索43一个或多个新的抽象播放列表。解析器21为第三方供应商创建抽象ID,并且通过映射算法来执行,所述映射算法优选地要么运行为后台索引进程32,要么在出现映射歌曲的请求并且该歌曲从来没有被映射的情况下被实时应用。
标记为26的实时映射过程从供应商的数据库(标记为27和28)提取数据29,客户端需要从所述数据库进行映射并且在一秒钟内应用映射算法或实时映射过程26,从而将新的映射ID返回30给客户端应用程序22,并且将映射缓存31以便将来用作索引器特征。如果出现关于已经被映射的歌曲的请求30,则应用程序22从映射数据库23中提取24数据并且将数据返回25至客户端应用程序22。
客户端应用程序22能够接收抽象实体的方式是通过搜索引擎特征32。搜索引擎特征32通过如下方式被填充36:从供应商数据库27和18中提取34供应商数据;将所提取的数据插入统一搜索文档33中,以及将抽象ID添加35至统一搜索文件中。这使得客户端与任意流媒体应用商进行数据交互,并且发生在搜索更新过程或环境44中。搜索作为来自客户端应用程序22的请求被发送38至搜索抽象服务37,其中,该搜索抽象服务37对客户端请求进行重构45并且该重构的客户端请求发送至搜索引擎32(弹性搜索)。
因此,可以认为媒体抽象层或系统包括一系列部件,这些部件包括客户端SDK 19、解析器21、搜索更新器44以及同步播放列表抽象服务40。客户端库允许核心应用程序播放、暂停、寻找、下载歌曲,而无需实施不同的供应商SDK 46。客户端SDK从核心应用程序提取47抽象ID和指令并且将抽象ID转换30成供应商特定资源ID。客户端SDK然后将播放指令转换48给供应商SDK 46。
解析器21基本上是一种容纳所有实时映射逻辑的服务,并且访问映射数据库以将映射返回至客户端应用程序22。搜索更新器44基本上是后台进程,该后台进程将供应商数据和映射合并到统一搜索文档中。同步播放列表抽象服务40基本上对来自第三方服务的播放列表的结构进行抽象化,并且将该抽象结构返回至客户端应用程序。
应当理解的是,媒体抽象系统的大部分在图18中被大体上描绘,并且目前位置所描述的内容是对用户隐藏的。系统的、用户必须进行交互的唯一部分是通常在图19所示的屏幕截图表示中所描绘的认证页面。这个页面或屏幕截图允许用户认证客户端应用程序22,并且允许媒体抽象系统与第三方系统交互(标记为过程41)以播放歌曲并且提供播放列表(标记为过程49)。用户因此可以点击链接按钮或提示50。一旦用户点击提示50,认证模型出现在用户可以输入他们的认证信息的地方,或者认证模型重新路由至用于开放授权或OAuth协议的流媒体供应商应用程序。在这两种情况下,核心应用程序均接收并且验证令牌以发出播放和同步请求。
媒体实体来自于经由验证的媒体元数据,该媒体元数据可以由供应商(例如,
)提供或者通过利用来自于文件上传和音频指纹的元数据来生成。音频指纹用于识别唯一的音频文件,并且元数据与这些音频文件相关联,使得:随着时间的推移,随着多个文件被上传,元数据的聚合可以用于识别最有可能的实体元数据。这个过程与musicbrainz.org数据库用于将音频文件映射至元数据的过程类似。一旦生成了这些实体,则使用如下三个过程来将内容映射至这些实体,即,(1)索引,(2)上传以及(3)第三方逐步映射。
在索引过程中,索引器特征31使用公共可访问的音乐(例如,
)收集(scrape)公共网站,并且生成脱离于位于这些网站的音频内容的音频指纹,然后该音频指纹用于识别是否存在关于特定文件的已验证的元数据,如果存在关于特定文件的已验证的元数据,对实体的song_id进行定位并且将其映射至公共资源。如果不存在关于特定文件的已沿着的数据,则从网站提取元数据,并且将该元数据与指纹关联,所述指纹还被分配了被映射至公共资源的song_id。
索引过程还可以使用供应商所提供的元数据来通过第三方流媒体供应商库的Web-API来搜索第三方流媒体供应商库。元数据用于识别可能的匹配。如果识别到匹配,则内容的资源ID被映射至实体ID,并且被缓存以用于将来检索。此过程持续运行,以识别流媒体供应商库中的潜在变化。流媒体供应商还可以提供可以被检索的数据转储(datadumps),而无需向Web-API发送请求。
在上传过程中,客户端应用程序22上传二进制文件,该二进制文件可以包括所生成的音频指纹。所生成的音频指纹被用于识别二进制文件中是否存在已验证的元数据。如果二进制文件中存在已验证的元数据,则将实体的song_id分配给文件。如果不存在已验证的元数据,则生成关于文件的新的song_id,并且将文件中的元数据存储并且使用该元数据来表示文件。
在第三方逐步映射过程中,来自元数据供应商的实体用于填充搜索索引,所述实体中的每个都分配有song_id。当客户端搜索到搜索索引并且定位到用户想要播放的歌曲时,客户端经由已经建立的Web-API将song_id与使用实体元数据的服务一起传递至第三方供应商。元数据用于在另一供应商(流媒体供应商)上定位文件,如果歌曲被定位,则歌曲的在供应商库内的资源id被映射至实体的song_id并且被缓存,并且返回至客户端。
媒体实体用于多个领域,主要用于跨多个供应商创建通用音乐和社交体验。这些领域包括分享、综合广播以及播放列表。当分享内容时,可以通过使用被分配给实体的唯一的标识符来将实体发布给用户订阅馈源(feed)。于是,其他用户可以查看馈源内的实体并且对馈源内的实体进行操作,而不管他们所使用的流媒体供应商如何。实体可以通过链接(例如,URL)被分享,该链接具有被嵌入到该链接中的唯一标识符,使得其他用户对来自文本消息(例如,SMS)或者电子邮件的实体进行访问和操作。实体还可以通过直接消息(基于套接字或推送通知)来分享,该直接消息可以具有实体唯一标识符的客户间分享的JavaScript对象标记(JavaScript Object Notation,JSON)对象。
在综合广播期间,抽象实体被用于创建跨平台综合广播的目的。这使得只要资源(即,歌曲)都映射至同一实体,就允许用户在
品牌流媒体服务上例如收听用户在Apple
和其他供应商的综合广播。如上所述,资源映射对于资源路由至关重要,因为资源映射使得经认证的具有
品牌流媒体服务的一个客户端能够发送抽象事件,而经认证的具有Apple
的另一客户端不会受到用户的干预。资源映射允许客户端应用程序22在几毫秒内以非常高的精确度来跨供应商识别相似的歌曲。由于大多数资源是通过索引器特征31来被预映射的,因此使用考虑元数据变化的后台进程来对由于元数据的变化引起的许多不匹配进行校准。抽象实体还能够使收听用户向他们的个人音乐库中添加内容,甚至在广播员正在收听来自另一流媒体供应商的音乐的时候。这是可行的,因为广播客户端正在发送正被处理以复制广播的事件。
应该相信的是,播放列表同步通常包含标记为40、41、42、43和49的哪些特征和过程。实体抽象化能够简化跨多个平台的一个或多个播放列表的同步,并且使不同服务供应商上的不同播放列表结构对客户端隐藏。实体抽象化进一步生成具有抽象歌曲实体的一个或多个抽象播放列表。当同步播放列表更改或者指向另一个供应商时,VERTIGOSM品牌移动应用程序将播放列表结构和内容转换成目标数据结构并且将抽象歌曲实体转换成目标平台的资源。
因此,VERTIGO
SM品牌播放列表会被转换成
品牌播放列表,并且VERTIGO
SM品牌歌曲的ID将用于解析为
品牌资源ID。播放列表的抽象化使VERTIGOSM品牌系统能够容易地将播放列表从一个流媒体供应商移植到另一个流媒体供应商。假设服务为每一个供应商创建了类似的播放列表并且将抽象播放列表转换成目标平台的格式,则抽象化最终用作转换中介,该转换中介用于将播放列表从一个供应商移植到另一个供应商。
根据本发明的VERTIGOSM品牌系统优选地还包括通常描绘并引用在图20中的通用动态搜索特征。比较地参考图18和图20,读者应该认为,根据本发明的通用动态搜索特征允许用户跨多个流媒体供应商搜索38可用内容。这意味着用户可以使用单个查询来搜索多个流媒体供应商的库(例如,数据库27和28)。用户界面识别具有在所识别的歌曲、专辑或艺术家旁边的“标识(logo)”57的音乐的那些供应商。实体抽象化被标记以指示哪些供应商具有所述内容,从而允许客户端应用程序22使用适当的标识57来标记内容。
通用动态搜索特征也受益于实体的抽象化,使得用户通过搜索过程在过程18处播放或添加歌曲,而无需担心在哪个供应商上播放歌曲。根据本发明的路由记住使用抽象实体ID来将播放请求路由至适当的供应商SDK 19。客户端应用程序22包括抽象SDK 19并且基于客户端供应商SDK 46上的经认证的供应商来解析实体ID,在47处,该抽象SDK 19接收标准播放请求和抽象实体ID。
因此,当用户点击通用动态搜索特征中的歌曲时,它将自动地解析为供应商ID,并且使用这个供应商ID来发起播放。所有这些都是无缝的,用户不需要任何附加步骤,并且通过根据本发明的VERTIGOSM品牌移动应用程序和/或系统就可操作。读者应当注意的是,如果没有经认证的供应商,或者经认证的供应商没有要求进行播放的歌曲,则SDK 19会回应核心应用程序以指示不存在匹配。然后,核心应用程序提示用户向适当的流媒体供应商注册。
正如前面所述,广播事件是响应于广播用户所生成的事件而在广播用户的客户端应用程序上或通过广播用户的客户端应用程序生成的事件。所有的广播事件必须具有帮助收听客户端正确地定位事件的时间戳。播放事件通常具有抽象实体标识或ID,所述抽象实体ID由广播客户端插入以使得所有收听客户端能够使用先前说明的SDK 19和抽象实体路由来播放来自这些收听客户端的流媒体供应商的歌曲。读者可以结合下面的描述比较性地参考图18和图21至图23。
播放事件包括正在播放的歌曲的播放位置和抽象ID。可以通过如下方式来触发事件:(a)按下64处的播放按钮或提示;(b)按下提示65处应用程序的任意地方的歌曲单元;(c)分别按下67处的提示“下一个”或66处的提示“上一个”;以及(d)通过播放列表自动迭代。寻找事件类似于播放事件,其主要区别在于播放位置的变化。寻找事件还包括抽象歌曲ID。寻找事件通过移动/点击68处的“查找”条或提示来触发。暂停事件指示播放应该停止,抽象ID通常不包括在内。暂停事件通过按下“暂停”按钮或提示63来触发。
参考图24至图25C,读者应该考虑根据本发明的评论事件功能。每当用户发送视频评论或音频评论时,就会生成评论事件。视频评论在视频评论的开始和结束时被发送。视频评论事件在视频评论按钮69被按下时开始,并且在视频评论按钮69被释放或解锁时结束。通常在图24至图24C中描绘了示出在视觉显示器11上的自然场景的通用视频表示。通常在提示91处标记了与广播连接的听众/观众的数量。
图24A至图24C通常描绘了某种替代方法,其中,广播员可以通过广播员的手指93来按压或接触广播发起发起提示或按钮69,并且代替保持用户的手指与提示或按钮69的接合,用户可以将用户的手指93和/或发起提示69滑动到通常如锁定图标94处所示的锁定选项。当锁定选项被接触时,用户可以从提示69移走他或她的手指,从而记录视频表示90用于传输。
参考图24D至图24G,读者将比较性地进一步考虑用于广播视觉内容的替代方法。
图24D描绘了用户的手指93在95处敲击发起提示或按钮69,以对当前视频表示90的静止帧拍快照。图24E描绘了在视觉显示器11上进一步呈现的具有提示97和98的静止帧表示96。图24F描绘了通过接触提示97来发送/传送/广播静止帧表示96的用户选项。通过接触选项97,该静止帧表示96会出现在一个或多个广播收听客户端上。通过接触提示98,广播员可以取消通常如图24G所描绘的、所推荐的广播。
图25通常描绘了音频评论能,通过该音频评论功能可以进行社交交换。音频评论事件在音频评论按钮70被按下时开始,并且在音频评论按钮70被释放或解锁时结束。当广播员选择音频评论选项时,可能会出现92处的广播员的个人资料图片。除非视频或静止帧视觉材料正在被广播,否则个人资料图片92可以优选地总是出现在广播接收机的视觉显示器11上。读者应当注意的是,个人资料图片92可以被提供为图片相册或幻灯片,或者可替代地用于广告材料。
图25A至图25C通常描绘了某种替代方法,其中,广播员可以通过广播员的手指93来按压或接触广播发起发起提示或按钮69,并且代替保持用户的手指与提示或按钮69的接合,用户可以将用户的手指93和/或发起提示69滑动到通常如锁定图标94处所示的锁定选项。当锁定选项被接触时,用户可以从提示69移走他或她的手指,从而记录音频评论用于传输。
广播事件可以通过TCP/IP信道在TCP套接字86处发送,或者可以嵌入在视频流或音频流中。视频数据优选地由广播客户端83通过TCP或UDP146信道传送至WebRTC服务器81,然后WebRTC服务器81将该视频数据通过TCP或UDP146信道中继到收听客户端84。音频数据优选地由广播客户端83通过TCP或UDP146信道传送至WebRTC服务器81,然后WebRTC服务器81将该视频数据通过TCP或UDP146信道中继到收听客户端84。
可以通过图26A、图26B、图27以及图28所分别描述和标记的三种方式之一来加入广播。在每种情况下,客户端应用程序22接收唯一的标识符,该唯一的标识符被移动应用程序22用来加入会话。加入广播的第一种方式是通过在71处的应用程序的监听直播部分中的广播片/行上点击,该动作使得收听客户端通过向应用服务器80发送会话信息152来加入广播,应用服务器80然后返回建立音频数据、视频数据以及在TCP套接字86处的事件数据信道以及TCP或UDP信道146所必要的连接信息154。广播参与者个人资料图片92和/或简档可以如通常比较性地在图26A和图26B中所描绘的那样呈现在视觉显示器11上。图26A描绘了“拉伸的(trending)”屏幕截图,放大的个人资料图片92呈并列式窗口显示,以及图26B描绘了“按列分布(following)”的屏幕截图,缩小的屏幕截图92以栏的方式分布。
加入广播会话的第二种方式是通过来自于应用程序22的借助于72处的SMS、电子邮件或社交网络分享的链接上点击,这通过向应用服务器80发送会话信息152来加入广播,应用服务器80然后返回建立音频数据、视频数据以及在TCP套接字86处的事件数据信道以及TCP或UDP信道146所必要的连接信息154。加入广播会话的第三种方式是通过打开被传送至广播的所有邀请方的73处的推送通知。然后客户端通过向应用服务器80发送会话信息152来加入广播,应用服务器80然后返回建立音频数据、视频数据以及在TCP套接字86处的事件数据信道以及TCP或UDP信道146所必要的连接信息154。
为了发起监听会话,用户点击加入会话,并且设备可以(a)通过应用服务器80和唯一的标识符从远程服务检索会话信息154;(b)基于从远程服务接收到的信息通过TCP套接字86和TCP或UDP信道146加入所有事件信道;(c)基于通过TCP套接字86在播放事件信道中接收到的事件发起音乐播放(如果事件需要);并且使用从媒体服务器或WebRTC 81(在WebRTC的情况下,这将是音频和视频ICE候选)的数据通过进程146发起视频和/或音频流。
一旦客户端加入会话并开始接收广播事件,则会发生广播事件履行。每个事件导致不同的变化并且进行不同地处理。只要用户连接至会话,所有的广播事件履行都是自动化的,而不需要用户进行交互,广播事件履行将继续。所有的播放事件均基于时间戳进行处理,目的在于使得视频和音乐同步。事件执行可能被延迟(如果需要),以确视频与音乐位置同步。播放时间被发送至SDK 19,并且通过之前在综合广播-资源路由相关的部分中所解释的那样通过借助于song_id来解析歌曲来实现。一旦歌曲被解析,客户端通过经认证的本地源在播放事件所指定的位置处发起播放。暂停事件导致暂停。
视频评论事件同样基于时间戳延迟执行。当视频事件被发送时,视频评论事件通知收听客户端:视频正在进入,会发生以下功能。收听客户端移除视频层上的任何覆盖物以使得能够观看。收听客户端将发出声音指示:视频正在进入,以提醒被动听众发起他们的屏幕进行观看。音频评论事件基于时间戳延迟执行。当音频事件被发送时,视频评论事件通知收听客户端:音频正在进入,会发生以下功能。音频与音乐的混合被调整使得听众能够收听到来自广播员的音频评论。
参考图29至图31,读者应该考虑根据本发明的特定聊天功能。本发明的聊天功能建立在于2016年2月19日向美国专利商标局提交的美国专利申请No.15/048,480中所阐述的公开内容的基础上。所谓的聊天功能允许用户通过广播内的文本相互通信。利用No.15/048,480申请大体上所描述的用于数据传送的发布者/订阅者模型来通过使用TCP套接字将聊天消息从一个客户端发送至另一个客户端。
如所有事件一样,聊天消息也以延迟的方式进行显示,以试图与视频流或音频流的内容对齐并一起显示。聊天消息通过收听用户或广播用户输入到呈现在应用程序中的输入框74。聊天消息视觉上显示在75处的视频或广播评论上方,其中,聊天消息显示有限事件,直到他们消失。如果用户点击聊天输入框,在图31和图31A中所有的聊天历史显示在76处,允许用户滚动并查看先前的聊天消息。应用程序可能限制启用聊天的听众的数量。例如,在广播可能具有数千个听众的情况下,如果每个人都有能力评论和聊天,这可能会覆盖许多用户,并且导致消极体验。
聊天功能如何的示例可以包括以下内容。用户创建自己的播放列表,所述播放列表包括歌曲和所嵌入的消息,或者歌曲或重叠的歌曲之间的简短评论,或者播客的所有消息或部分消息。播客被集成到根据本发明的VERTIGOSM品牌移动应用程序和/或系统,从而具有使用其内容的合法许可。用户还可以广播播放列表,并且,在广播时,用户可以全部地或部分地插入预录的或者从播客中获取的消息,从而创建混合有如下项的综合直播:音频、视频、照片叠加以及所插入的用户自己或其他人预录的消息预录。预先获取对播客的合法访问,并且可以将播客本身集成到根据本发明的VERTIGOSM品牌移动应用程序和/或系统中。
比较性地参考图32和图32A,读者应该考虑到特定聊天功能,借此图32中描绘的聊天记录屏幕截图可以配备听众提示91的数量。如图32进一步所示,提示91可以是手指接触,以提示如图32A所示的、广播收听客户端的更精细的列表。图32A所示的广播收听客户端的列表描绘了用于向广播客户端提供关于正在收听广播的人的信息的个人信息图片条92。
图33至图37A描绘了某些次要屏幕截图,用于突出显示根据本发明的VERTIGOSM品牌移动应用和/或系统的某些子程序功能。
图33描绘了应用程序发起屏幕截图,由此用户可以在192处按压或触摸品牌发起或发起提示12。通过提示12接合192来发起应用程序,可以将一组范围选择或选项13显示在视觉显示器11上,以便使用户然后能够按照如通常图33A所描绘的那样从中进行选择。
一旦从这组选择或选项13中选择了范围选择,则Go Live提示99可以优选出现在Go Live屏幕截图上,如图34所示。读者应当注意的是,图34中通常描绘的Go Live屏幕可以进一步优选地描绘或显示如92所示的广播员的个人资料图片。图34A示出了中间屏幕截图,其示出了当广播应用发起时的时间流逝视觉显示89。图35和图35A比较性地描绘了屏幕截图方法,用于通过发起提示12、在192处双击、双指93”以及分享/结束下拉屏幕截图,用于通过相应的提示87和/或88启用的应用程序来分享(广播)内容或者结束广播传输。
参见图36,读者将考虑如79处的相册库或存档提示。通过使用相册库或存档提示79,用户被带到如图36B和37中的78处的存档屏幕截图。存档屏幕截图可以提供如77处的缩略图类型的拼贴图,该拼贴图配有拼贴图信息,例如59处的任何给定相册或文件中的幻灯片数量以及58处的对于文件内容的幻灯片的运行时间。
一般地如图36C中的56处绘制并引用相片幻灯片屏幕截图。图36A至36C以比较方式示出了提示锁功能,用户借此可以通过将提示69滑动至锁定图标94锁定幻灯片功能,从而播放相册幻灯片。图37和37A以比较方式描绘了用户通过按下192如77处的光线拼接图或者提示或者通过从光线文件夹提示77中选择光线显示来将光线视觉显示55覆盖到播放选择上的能力。
本申请中的递交的说明书和附图与以引用方式包含在本申请中的之前递交的申请被认为支持一系统发明,该系统发明规定了对正版媒体进行间接或直接源发起,该正版媒体经由同一正版媒体的第二直接源来(智能)路由和消费。这样的路由的一个效果在于建立综合播放,其中媒体的原始源(例如,“间接发起源”)实际上并未被发送到媒体消费者,而是消费者自身分别的合法适用“直接”访问点以及完全相同正版材料的源被发送。
“间接发起源”因此可以被定义为消费者借此并不“直接”选择特定消费媒体但该媒体选择来自于第二“间接发起源”的任何源,无论该源是否为诸如数字“广播”提供者或个体直播组织者之类的计算机组织流。间接源的这样(智能)路由或者(智能)同步到分别的直接适用源唯一地使得能够在两个以上的人之间进行媒体的合法且适用的协同收听或观看体验,其中对于正版材料的访问源自于该材料的两个以上的分别适用的媒体源。
替代性地,“直接发起源”可以被定义为消费者借此“直接”选择待消费的特定媒体的源,并且该特定媒体可以从消费者合法访问的至少两个位置中的最佳数据资源位置处获得。该优化协议基于诸如价格效率和/或数据质量之类的预定用户参数。对于直接使用源的这样(智能)路由或者(智能)同步唯一地使得能够进行媒体的合法且适用的收听或观看体验,其中对于正版材料的访问最优地源自于消费者已经合法访问的该材料的至少两个以上的分别适用的媒体源。
参照美国专利申请US 14/099,348,读者将考虑本发明可以根本地提供以下功能:传送来自本地服务器的间接请求流(例如,如
网络电台这样的数字广播);传送来自端连接服务器的间接请求流;传送来自第二直接源的间接请求流(例如,iTunes
或
或者如
这样的云收纳或云中的任何媒体);基于第二直接请求源播放或流传输的权利来传送来自端连接的间接请求流;基于源的(a)价格效率或(b)声音质量来传送来自第二直接请求源的直接请求流;以及基于第二直接请求源播放或流传输的权利来传送来自端连接源的直接请求流。
考虑到本系统的数据源不可知或云不可知方面,系统还提供了(a)产权管理(b)适用监视和/或(c)适用报告,其中,内容传送源自次级源而不是包括以上给出的示例的原始请求源服务。本发明因此提供了一种为消费者提供最优源播放的智能路由同步系统,该智能路由同步系统包括用于将选择合法保护内容路由到具有替选和优选源的消费者的特定智能路由装置。根据本发明的智能路由装置借此提供最优源播放,其理想且可专利性地具有以下特征:按照间接请求或直接请求将选择合法保护内容最优源传送给消费者。
根据本发明的只能源路由因此优选地具有以下特征:特定场景类型包括基于本地服务器传送间接或直接请求的流;基于端连接服务器传送间接或直接请求的流;或者基于合法访问点传送间接或直接请求的流,该传送基础最优地基于预定参数集或用于定义的参数集(如价格效率或音频/视频质量)选择。
本发明因此在于流传输媒体内容从间接或直接发起源到直接源的实时同步。使用管理使用装置以替选直接源(即并非从端对端或计算机构成网络传送的个人私有合法源)来提供间接内容流的能力被认为是本发明的基础。换言之,消费者向诸如数字广播提供者之类的内容流提供者发出请求以消费来自内容流提供者的内容。内容流提供者和消费者均具有指向被流传输的内容的不同的合法所有的访问点。消费者可以具有合法权利来直接从消费者自身的源或库请求该内容,但是提供者可以流传输来自不同源或库的内容。
对于来自用户自身的库或者用户合法访问的库的内容的直接访问点因此被认为相对于获得对来自用户间接访问的提供者的库的内容的访问更加有效率或更具有性价比。参照图38-38B,读者将共同考虑示例性的播放场景。一般地如图38中的201处绘制并并引用广播客户端“@保罗”。在此,读者将看到“轨道06-音乐”正在201设备10上通过客户端应用22并经由播放用户的被标记为200的
音乐流传输服务账户来播放并且三个广播收听者正在收听,正如广播收听者提示91处所标记的。播放客户端201因此通过视频评论按钮69分享直播并且可以输入诸如“星期六的放松:)”这样的评论作为社交评论以与视频表示90叠加作为轨道06-音乐,视频表示和社交评论全部被广播给三个广播收听者客户端。
参照图38A,读者将看到第一广播收听者客户端被标识为202,并且广播收听者客户端202从“@保罗”201接收到来的广播以及如“星期六的放松:)”评论203处的文本框类型的评论。广播收听者客户端202上的客户端应用22将到来的广播“轨道06-音乐”同步到广播收听客户端202,并且该特定音乐轨道的专辑封面204被显示在广播收听者客户端202的视觉显示器11上。读者将注意/考虑图38中的广播客户端201以及图38A中的广播收听者客户端202通过200处标记的每个用户各自的优选
音乐流传输服务账户来消费被同步的“轨道06-音乐”。
一般地如图38B中的205处绘制并引用第二广播收听者客户端。广播收听者客户端205倾向于且被连接到其Apple
品牌的音乐流传输服务账户。客户端应用22将206处的来自Apple
品牌的音乐流传输服务账户的轨道06-音乐进行同步。同样,该特定音乐轨道的专辑封面204伴随着视频表示90、广播者身份201以及如203处重叠的社交评论一同被显示在广播收听者客户端205的视觉显示器11上。
读者因此将看到内容传送将或者应当对内容提供者的适用报告造成影响,并且客户端应用22因此包括用于精确追踪并且报告版权所有者的最终收益的适用装置。根据本发明的数据路由管理系统因此与本发明的音乐分享方面紧密配合,从而管理并报告内容传送网络中的数据路由。数据路由管理系统包括数据路由适用装置,该数据路由适用装置与路由同步系统通信。路由同步系统工作在(a)内容传送网络以及(b)一个或更多数据源中。内容传送网络包括多个路由指令实施源,每个源包括数据文件。
内容传送网络按照路由指令生成源的提示将选择数据文件从最优数据实施源传送到终端用户。最优数据实施源是从包括多个路由指令实施源的组中选择的。路由指令实施源和路由指令生成源中的每一个定义一个合法访问点。每个合法访问点与数据文件库关联。选择数据文件被从选择数据文件库提供至终端用户,并且适用装置提供数据文件传输的(a)产权管理(b)适用监视和/或(c)适用报告,该数据文件传输将被路由的合法保护的数据从最优数据源位置传输到选择数据文件的所有者或所有者代理。
适用装置或引擎可以工作以通过路由到最优源来生成收益。就此,设想对于收益的权利和所有权比例能够通过初级或次级公共或私有市场或交易所来转移或建立。权利和所有权的可能机制为区块链,以及公共交易贸易基金或ETF类型的结构。在区块链权利转移的情况下,收益转移将由子管理者来分配。
服务器在自身上注册该子域名并且对来自本地客户端应用的针对子域名的全部请求进行处理。在此情况下,当客户端应用产生针对流的请求时,网关服务器为该请求提供服务。网关服务器通过仅有第一通道提供来自远程内容传递网络的流来开始该服务。一旦流开始,网关服务器请求预先记录的音频队列并且开始对来自端对端远程内容传送网络或本地源的预先记录的音频进行缓存。网关服务器优选地还从远程数据库加载事件队列,该事件队列由工作室计算机持续更新。网关服务器连续接收事件更新,同时经由第二通道的流是现场的。
为了从完整工作室混合转变到仅现场音频流,网关服务器加载针对二者的流并且仅提供完整混合。为了确保网关服务器和混合应用具有足够的时间来完成全部的任务,服务器从现场数据接收后的10到20秒后开始流,从而建立惯例延迟。该延迟被用作系统执行混合和转变的时间。网关服务器等待完整工作室混合帧头中的事件位转变为现场音频流。
网关服务器将事件位中的两个流对准。这通过对事件位之后的位码进行匹配来完成。如果两个事件的位码匹配,则这两个事件被认为是匹配的,这是因为仅仅对流中的最后10至15秒进行搜索。32个唯一位码提供了足够的唯一性以保证所匹配的事件实际上是相同的。一旦位码匹配,则网关服务器在事件位码出现的帧处从完整工作室混合转变到现场音频混合。通过使用该方法,以帧到帧的精确度提供了流与流之间的无缝转变。
本系统因此提供了惯常的媒体格式以在编码过程中适应参考事件并且路由和播放指令,并且该路由和播放指令从属于大量的选择播放事件。这些大量的选择播放事件是从包括以下事件的组中选择的:(a)播放;(b)暂停;(c)终止;(d)加载;(e)寻找;(f)评价;(i)评价开始;(ii)评价结束;(g)音频混合;(h)播放速度;(j)播放方向;以及(k)内容识别。
虽然以上说明中包含众多特性,但是该特性不应当被解释为对本发明的范围的限制,而仅仅是对本发明的说明。例如,设想根据本发明的如22处的移动应用或软件工具本质上提供或使得非暂时性计算机实现的媒体内容分享系统可工作在计算机网络环境中。该计算机网络环境用于向至少一个但优选地为一系列的内容消费客户端计算机提供媒体内容广播。该内容消费客户端计算机例如为移动通信设备10,每个移动通信设备配备有客户端应用22。
媒体内容分享系统可以被认为包括计算机可实现的以下功能:(a)通过计算机网络环境建立到各内容消费客户端的第一指令传递通道;(b)生成路由和播放指令以通过第二内容传送通道管理可消费合法保护媒体内容的播放;以及(c)通过指令传递通道将路由和播放指令传递到内容消费客户端,从而将可消费合法保护媒体内容从优先合法访问点提供到内容消费客户端。第一指令传递通道和第二内容传送通道因此可以被认为是如位于TCP套接字86和TCP或UDP通道146以在网络环境中实现并行数据流的并行通道。事件处理微服务对网络环境中的媒体和社交内容传送进行维持、管理和同步。
因此,本发明可以被替代性地描述为本质上提供或使能一种非暂时性计算机可实现媒体内容分享系统,该媒体内容分享系统使得用户能够分享用户所选择/生成的社交内容,并同时广播优选提供的媒体内容以供网络环境中的收听者客户端消费。媒体内容分享系统在网络环境内提供并行数据流,从而分别且单独地管理(a)媒体内容播放指令以及(b)媒体内容播放。并行数据流工作以将可消费合法保护媒体内容从至少一个优先合法访问点提供给广播消费者,并同时使得能够在优选提供媒体内容的背景下进行社交交互或交换。此外,独立的社交广播流可以覆盖到可消费合法保护媒体内容的直接播放上方。
媒体内容广播优选地可以以来自消费者可访问内容库的可消费合法保护媒体内容的直接源传送为特征,并且可以由到来的间接源和消费者附属直接源之一发起。在消费者附属直接源的情况下,优选地可以对端连接有相同的消费者附属直接源,并且因此基于消费者附属直接源提供所述可消费合法保护媒体内容的合法权利可消费合法保护媒体内容可以被直接提供给内容消费客户端。
需要注意的是,媒体内容分享系统优选地还可以包括用于管理和报告内容传送网络中的数据路由的数据路由管理系统或者与之关联协作。数据路由管理系统优选地包括适用装置以提供(a)产权管理;(b)适用监视;和/或(c)适用报告。适用装置因此管理、监视和/或报告不同路由的可消费合法保护内容的传输以妥善计入版权所有者。适用装置使得能够通过优先源路由管理来生成虚拟流通。
由以上所述支持并且包含在参考说明书中的特定方法可以被认为提供了一种基于订阅的社交媒体平台实施方法,包括以下步骤:服务器从社交内容广播客户端计算机接收应用编程接口(API)请求以初始化媒体内容传送流上的社交交换,API请求由运行在社交内容广播客户端计算机上的应用生成;服务器将所接收的API请求的元数据信息储存在数据库中,该数据库耦接到方法使能服务器上;服务器向编码服务提供者发送配置请求,配置请求请求多个流配置;服务器从编码服务提供者接收协议位置;服务器将流信息存储在数据库中;服务器向社交内容广播客户端计算机发送协议位置;以及,服务器从社交内容广播客户端计算机接收社交内容广播客户端计算机已经发起媒体内容传送流上的社交交互的通知。
本发明的其它方面包括基于定时元数据的路由和播放指令。此外,在编码过程中,惯例媒体格式适用于事件参考和路由和播放指令。播放事件信息通过便利化套接字优选地且连续地发送。优选提供媒体内容通过所有权归结法来定源,从而根据媒体内容消费者的控制并且可以基于诸如价格效率或媒体质量之类的参数来识别并优选地提供媒体内容文件。