关于小程序技术的知识产权FAQ

由于小程序技术诞生于中国互联网并且最早是由众所周知的大厂所推出与引领，其在简中互联网所取得的巨大商业成功，让“小程序”三个字家喻户晓，从一个非常技术的概念变成上至80岁老太太下至8岁小朋友都知道、用到的热词。

虽然此后有众多的互联网大厂跟进，各自独立实现了类似的技术，也都叫“小程序”，但难以改变普罗大众消费者的第一印象，即“小程序”就是特指先发大厂推出的、老百姓日常在某些“超级App”使用的小程序。

而在ToB领域，众多的技术开发商、外包商，则试图模仿小程序技术，为自己的甲方客户打造类似的机制，从而让其甲方客户的App拥有一定的开发灵活性。他们也试图把这类技术称之为小程序，虽然本质上都是自己重新发明的HTML5碎片封装加热更新。但在不少甲方客户那里，也产生了“我已经拥有小程序技术”的观念。

那么从技术概念的严谨定义、技术的发明权和知识产权归属等方面，怎么理解“小程序”这个门类的技术呢？企业为什么要关注这种技术以及如何避免市场上各种混淆视听的市场营销呢？这里整理了一系列的常见问题，供公众参考。

“小程序”技术概念属于谁？

“小程序”技术，是一种涉及人机交互的前端技术门类。它解决了传统手机App的一些问题，例如跨安卓、iOS和鸿蒙等操作系统需要多团队维护并且用户体验难以保持一致，例如HTML5页面嵌入在App中的性能不佳（白屏、每次打开重新加载等等），例如传统App都是信息孤岛无法开放，等等。小程序技术改变了简中互联网的面貌，安装、使用、发现都更加简便，极大程度促进了衣食住行社会方方面面服务的数字化。但是“小程序”技术是一种应用或服务场景的数字化技术载体，它和PWA（Progressive Web Application）、“快应用”等等，均属于一种“轻型”软件“格式”的“规范”、“既成事实标准”（De Facto Standard）或者“标准”。所以“小程序”这三个字，不是谁的专利。

“小程序”技术有没有工业标准？

有，准确的说，正在制定中。在小程序技术成为一种互联网现象级成功之后，引起了众多厂家的关注。在W3C（在全球协调制定一系列互联网技术标准的标准组织，HTML和HTTP标准都是这个组织所负责制定），于2021年1月即成立了MiniApps Working Group，其中有众多来自中国的互联网企业、手机厂商，参照在中国取得巨大成功的小程序实践，共同制定一种新型“轻应用”技术标准，英文称之为MiniApp，但经常也被开发者称为Mini-program。它在关于一个前端程序的目录结构、压缩包格式（packaging）、生命周期管理（Lifecycle）、配置清单（Manifest）等等方面作出规定，和简中互联网上的“小程序”非常相似。如果按时间先后顺序来说，是先有简中互联网的小程序技术，再有W3C的MiniApps标准拟定稿，可以理解为一种得到成功实践的技术被提炼成国际技术标准。但在标准诞生后，也可以说“某些厂家的小程序技术”遵循了W3C的MiniApps国际标准。

“小程序”技术仅限于手机运行吗？

对于普罗大众来说，因为手机是最个人化、最直接能接触到小程序的工具，所以一般人可能会认为小程序就是运行在手机上的某个App里。实际情况并非如此，如上述W3C的MiniApps标准，即考虑到对物联网设备的支持。例如凡泰极客的小程序技术，不仅支持所有的手机操作系统，也支持PC、Mac、任何国产信创操作系统下的个人电脑，更支持包括智能电视、POS机和汽车车机在内的各种物联网设备。小程序技术的客户端（通常称之为“宿主”），不一定是App，也可以直接是手机操作系统本身 - 当一个手机操作系统嵌入了“小程序容器”，即可直接运行小程序，例如用户通过手机自带的5G消息短信，收到一个小程序卡片，点开即可运行，期间不涉及任何App。

“小程序”技术的知识产权属于谁？

如上所述，“小程序”技术是一种技术门类，这种技术门类正在成为一个国际标准，被更多国家和地区的技术厂商、企业用户所采用。只要遵循这个标准，任何技术提供商均有资格去实现自己的技术底座、技术平台、运行环境。事实上，有更多并不了解、不遵循这个规范或标准的开发商，也在宣传、声称自己给甲方客户提供“小程序”技术。所以，“小程序”这个技术不是哪一家大厂的“专享”，正如“快应用”不属于哪家手机厂商专用一样。

具体小程序的场景内容的代码实现，其知识产权则毫无争议的属于开发者或者委托开发商进行开发的甲方企业。

什么是ToB的小程序技术或“小程序容器”技术？

小程序技术首先应用于互联网的C端。但近年来在企业界，从银行到央国企，都看到了“小程序”这样一种技术为己所用的好处，希望复制互联网大厂的成功，把运行小程序的能力搬到自己的App里，这样做的好处最起码有三：（1）把自己的App“打开”，让里面运行的内容不仅是自己的IT所提供，更加可以引入第三方合作伙伴的内容，相当于让第三方的代码安全的运行在自己的App空间里，从而建立起自己的“超级App”和数字生态；（2）建立极致松散耦合的技术架构，让各个业务部门自己负责自己的小程序，部门之间、小程序之间被隔离，互不影响，让宿主App保持高度稳定，降低发版频率；同时又让业务部门以更小、更精细的颗粒度在App上“出版”自己的内容，极大程度缩短发布周期，实现真正的“敏捷”；（3）打造自己的本地化“小程序商店”、“小程序中心”，自我掌握在自己行业或垂直领域中合作伙伴的数字生态。

在这种情况下，市场上出现向企业提供“企业用小程序技术”的厂家。这类技术引入了“宿主”的概念，宿主指甲方企业现有的App或者软件环境，甲方只需把能运行小程序的“容器”嵌入到自己的软件环境中，即可瞬间获得运行小程序的能力。“容器”通常以SDK的形态出现。而面向C端的互联网平台，则无“宿主”概念，一般是在自己的App中内置小程序运行能力。小程序技术的企业化，本质上是“借用”了小程序技术的“轻”，把它重新发明成下一代企业软件的技术载体，和互联网大厂的小程序平台，不存在直接的竞争关系。

在ToB小程序赛道，如何甄别与防范某些厂家的F.U.D.策略？

随着ToB领域小程序赛道的开拓，陆续有玩家试图参与到其中。这个过程甲方会遇到各种混淆视听的营销策略，其中最令人深恶痛绝的是"FUD" ，指的是通过散播“恐惧”（Fear）、“不确定性”（Uncertainty）和“怀疑”（Doubt）来影响市场竞争对手和消费者的心理，从而获得竞争优势。虽然这种策略可能在某些情况下取得短期成功，但它也可能引起负面影响，并损害企业的声誉。如果一些大厂或者有一定规模的技术提供商，以自身规模、品牌、资源优势去散布污蔑竞争对手的谣传，例如宣称竞争对手的技术侵权、即将被起诉等等，让市场上对该竞争对手的存在能力甚至合法性产生怀疑，从而不敢采购其技术产品，转而选择采购该“大厂”的“稳妥”方案，因此不公平的获得竞争胜利 - 这类行为在当前中国科技界，是打压创新、变相垄断、破坏营商环境的不道德行为，可以说对我国鼓励创新、鼓励创业、鼓励科技生态繁荣的环境非常不利，与国家政策背道而驰，不仅应受到谴责，并且遭受法律后果。

在“小程序”技术的这个赛道，行业自律，教育市场，帮助甲方认清FUD手段，参与公平竞争的厂家任重道远。但更需要甲方企业认清这些FUD行为，不轻易受其恐吓影响。必要时，创新企业应对有垄断打压的所谓品牌厂商拿起法律武器，相信法律对创新者的合理保护。

有哪些常见F.U.D行为？

以下是一些巨头企业可能采用的FUD策略的例子，甲方企业可以参考作判断：

市场份额和品牌优势：
一些巨头企业可能会通过夸大其市场份额和品牌的优势来制造竞争对手的“不确定性”。通过强调自身在行业中的地位，企图让其他竞争者和投资者相信，选择竞争对手可能会面临失败或不稳定的局面。

专利和知识产权：
企业可能通过挑战竞争对手的专利和知识产权，制造法律上的不确定性。这可能包括提起专利侵权诉讼，即使诉讼最终无法成功，也会在竞争对手中散播负面的信息和疑虑。

产品质量和安全问题：
企业可能散布有关竞争对手产品质量和安全问题的信息，以引起消费者的“恐惧”和“怀疑”。这种策略可能包括发布负面的报道、评论或进行其他形式的负面宣传。

价格战略：
通过降低价格并宣传竞争对手的产品贵且低性能，企业可能试图在市场上制造对竞争对手的“怀疑”和“恐惧”，使其产品看起来更有竞争力。

技术疑虑和不透明性：
在技术领域，企业可能试图制造对竞争对手技术能力的“怀疑”和“不确定性”。这可能包括散布关于竞争对手技术不成熟或存在缺陷的信息。

在商业历史上，有一些典型的案例涉及到竞争对手使用FUD策略，试图影响市场和获取竞争优势。以下是一些例子：

IBM和小型计算机市场：
在20世纪70年代，IBM主导了大型计算机市场，但随着小型计算机的兴起，一些小公司开始崭露头角。IBM采用了FUD策略，试图通过质疑小型计算机的可靠性和性能来维护自己的地位。然而，小型计算机最终证明了其实用性，IBM在小型计算机市场的份额逐渐减少。

微软对Linux的FUD战略：
在过去的几十年里，微软曾对开源操作系统Linux采取FUD策略，质疑其安全性、稳定性和适用性。微软曾表示Linux是“病毒”并试图使人们怀疑在商业环境中使用Linux的可行性。然而，Linux逐渐成为企业和服务器领域的主流操作系统，证明了其可行性。

互联网浏览器战争：
在1990年代末和2000年代初，微软的Internet Explorer和Netscape Navigator之间展开了一场激烈的浏览器战争。微软采用了FUD策略，通过捆绑Internet Explorer并与Windows捆绑在一起，试图打压Netscape Navigator。这导致了一系列反垄断法律诉讼，最终微软在法庭上败诉。

这些案例表明，虽然FUD策略在某些情况下可能会带来短期的竞争优势，但它们也可能引起负面后果，并在长期内影响企业声誉。因此，企业在采用竞争策略时应权衡利弊，并遵循合法、道德和透明的原则。

小程序相关API接口能否被声称为“专利”或者知识产权？

小程序技术本身首先是面向开发者的，所以它必须暴露出一系列的API(应用程序接口)，否则开发者无法进行编程。但是，小程序技术的提供商能否申请专利或者其他形式的知识产权保护，禁止其他厂商去“模拟”该些接口以实现兼容性呢？答案基本上是否定的。

API本身通常难以获得专利保护。因为专利需要新的、有创造性并且在技术上有实质性进步的发明,而API本身通常不符合这些要求。

API的具体实现方式则可能符合专利保护的条件。如果API的实现算法有足够的创新性,它可以被视为一种计算机实现的发明而获得专利。比如利用特定算法提高API性能的实现方式。但对于选择实现接口兼容的厂商来说，可以类比为对某个接口采用了相同的函数签名，但也就仅此而已，其内部的技术实现可能完全不相干 - 例如采用不同的编程语言、不同的内部算法、不同的基础库实现。所以并不存在侵权问题。

一些厂商的API可以通过保密来获得一定的保护。如果API没有公开,只有授权用户可以访问使用,那么它可以视为商业秘密或机密信息而受到保护。但对于公开的API，不存在此一说。

所以，API作为一种面向开发者的开放的、公开的应用编程接口，厂家无法对其宣称拥有专利或者知识产权。其他厂家对其进行模拟或兼容性的实现，不存在侵权问题。否则的话，全世界整个软件行业都难以合法存在 - 例如模拟了操作系统的系统调用接口（System Call）的虚拟机（Virtual Machine）产业将不复存在，也没有了VMware、Oracle VirtualBox、Parallel等等的公司与技术，甚至没有了云计算！

市场上一些小程序容器技术，采取模拟方式兼容某些主流互联网平台的小程序技术接口，道理类同。在ToB领域，其目的往往是为了帮助甲方客户利用市场上沉淀的大量小程序开发者，去开发企业所需的内容场景，而无需重新发明车轮，迫使企业开发者去学习一套新的技术逻辑、开发手段。对企业世界而言，是一种帮助其降本增效的创新。

ToB的小程序容器技术，模拟ToC的主流互联网小程序平台接口，是合法的吗？

回答同上 - API接口的设计（方法/函数签名、出入参数类型）如果是公开的，则无法声称其作为知识产权而禁止他人用自己独立实现的代码和算法去模拟以达到兼容效果，这在软件技术中是经常被采用的隔离手段、测试手段、兼容手段，目的往往是降低上层（尤其是应用层）的开发测试成本。如上所述，虚拟机技术模拟商业操作系统的System Call、甚至更底层的硬件接口的做法，就是典型例子。

市场上一些小程序容器技术，采取模拟方式兼容某些主流互联网平台的小程序技术接口，其目的往往是为了帮助甲方客户利用市场上沉淀的大量小程序开发者，去开发企业所需的内容场景，而无需重新发明车轮，迫使企业开发者去学习一套新的技术逻辑、开发手段。对企业世界而言，是一种帮助其降本增效的创新。

什么是小程序内容的发行权、出版权、流动权和使用权？

自从小程序技术被发明出来并用于大型互联网平台、形成某些“国民应用”式的超级App以来，简中互联网诞生了海量的以小程序格式为载体的数字化内容，从衣食住行到医疗、金融、政务服务包罗万有。这些内容虽然是由数以百万计的商家、第三方开发者提供，但是每个小程序的上下架审核发布，控制在相应的互联网平台手中。

对于采用了小程序容器技术试图建立类似平台能力的企业，希望把小程序内容的上下架审核、审计、流转、使用的权限自主掌握。例如，银行的数字化金融部门充当银行的数字内容“发行”方，对内部研发或者外部引入的小程序进行审核、风控、分发；而银行内部的各条业务线、各地区各级分支行等，则作为”业主单位“自行负责小程序内容的制作（无论是自主研发还是委外开发或引入第三方存量内容），拥有相关业务场景的数字化内容“出版”权。总体来说，任何小程序内容在银行App的用户之间的分享传播的“流通”权，完全由银行控制；而银行App的客户则对这些小程序具有使用权，并在必要的情况下，对小程序进行数据授权，以允许某小程序有限的取得当前用户相关数据以展开服务。

这些权限，都是ToB领域小程序容器技术给企业客户带来的主动权，以小程序化的数字场景、数字内容为中心，让企业打造一套开放的、自主掌控的数字平台。

作为小程序技术的使用方，如何防范知识产权风险？

对于本地化运用自己的小程序技术平台的甲方企业，主要应关注以下方面：

小程序平台的名符其实。如前所述，“小程序”是一个普罗大众均广泛使用的概念，正因为它的普及性，也导致对这个技术的概念难以严格要求非常严谨精准的定义。虽然W3C组织在制定国际标准，而在简中互联网上也存在既成事实的“标准”，符合相关特点或者特征的技术，才能称之为小程序，但这个概念完全可能被“借用”、“挪用”，“偷梁换柱”的利用。甲方如果关注所采用的技术的长久生命力、真正的开放性、与互联网主流技术的兼容性，则应该基于相关标准来评估技术方案，而不是仅仅听到厂商抛出一个“小程序”概念，即认为是名符其实的小程序技术（如前所述，它可能只是一些重新发明的HTML5碎片技术加上热更新）。

小程序技术厂家的独立知识产权。“小程序”技术领域，涉及大批的ToC类互联网平台，以及正在出现的ToB类“企业软件小程序化”技术提供商。不排除有某些厂家以上述F.U.D策略威吓、打压潜在竞争对手，引起纷争，刻意破坏企业甲方与竞争对手的合作。甲方企业评估和选择技术方案，应建立在这样的基础上：（1）是否支持、遵循技术标准，尤其是W3C等组织的标准，从而让甲方免于某些封闭技术的锁死；（2）是否拥有完全独立的技术专利和知识产权 - 标准人人均可以遵循，但具体技术实现必须是厂家独立设计与完成，不涉及对一些所谓行业领先者的知识产权的侵犯。

小程序内容的发行权、出版权、流动权和使用权。ToB赛道上真正的小程序容器技术，应能向企业提供这些围绕数字内容资产（小程序为载体的服务场景）的权限的分离与统一：一方面梳理清楚小程序化内容在分发流转与出版方面的责任主体，另一方面又建立统一的协作机制。