发明创造名称：数据传输方法及装置
外观设计名称：
决定号：191114
决定日：2019-09-16
委内编号：1F276210
优先权日：
申请（专利）号：201610817396.8
申请日：2016-09-12
复审请求人：北京百度网讯科技有限公司
无效请求人：
授权公告日：
审定公告日：
专利权人：
主审员：邹婷
合议组组长：平彧
参审员：张新宇
国际分类号：H04L1/00
外观设计分类号：
法律依据：专利法第22条第3款
决定要点
：如果权利要求要求保护的技术方案与最接近的现有技术相比存在区别特征，但该区别特征是本领域技术人员为了适应实际需求有动机对最接近的现有技术进行的改型，这种改型属于本领域的惯用手段，则在该最接近的现有技术的基础上结合上述惯用手段得到该权利要求要求保护的技术方案对本领域技术人员而言是显而易见的，该权利要求不具备创造性。
全文：
本复审请求审查决定涉及申请号为201610817396.8，名称为“数据传输方法及装置”的发明专利申请（下称“本申请”）。申请人为北京百度网讯科技有限公司。本申请的申请日为2016年09月12日，公开日为2018年03月20日。
经实质审查，国家知识产权局实质审查部门于2018年12月04日发出驳回决定，以权利要求1-10不具备专利法第22条第3款规定的创造性为由驳回了本申请。驳回决定所依据的文本为：申请人于申请日2016年09月12日提交的权利要求第1-10项，说明书第1-13页，说明书附图第1-5页，说明书摘要及摘要附图。
驳回决定中引用的对比文件为：
对比文件1：CN101594518A，公开日为2009年12月02日。
驳回理由是：权利要求1-10相对于对比文件1和本领域公知常识的结合不具备创造性。
驳回决定所针对的权利要求书如下：
“1. 一种数据传输方法，其特征在于，所述方法包括：
接收信息发送端发来的待传输数据并且确认所述待传输数据的发送编码类型；
确认接收所述待传输数据的信息接收端的接收编码类型；
通过预设的编码转换模型将所述待传输数据从所述发送编码类型转换成所述接收编码类型，得到编码转换传输数据，所述编码转换模型用于表征发送编码类型与接收编码类型之间的对应关系；
将所述编码转换传输数据发送给所述信息接收端。
2. 根据权利要求1所述的方法，其特征在于，所述接收信息发送端发来的待传输数据并且确认所述待传输数据的发送编码类型包括：
查询所述待传输数据的发送编码类型信息；
根据所述发送编码类型信息确定所述待传输数据的发送编码类型。
3. 根据权利要求1所述的方法，其特征在于，所述确认接收所述待传输数据的信息接收端的接收编码类型包括：
确定对应所述待传输数据的信息接收端，并向所述信息接收端发送请求消息，所述请求消息用于查询所述信息接收端的接收编码类型；
接收所述信息接收端发来的对应所述请求消息的应答消息，所述应答信息用于指示对应所述信息接收端的接收编码类型。
4. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
构建编码转换模型的步骤，所述构建编码转换模型的步骤包括：
分别从信息发送端获取发送编码类型信息构成发送编码类型信息集合和从信息接收端获取接收编码类型信息构成接收编码类型信息集合；
确定所述发送编码类型信息对应的发送编码类型的解码模块，所 述解码模块用于将具有发送编码类型的待传输数据解码为指定类型的数据内容，所述数据内容包括一下至少一项：文字、图片和视频；
确定用于将所述数据内容转换为编码转换传输数据的编码模块，所述编码转换传输数据具有所述接收编码类型信息对应的接收编码类型，用于信息接收端进行数据处理；
将所述解码模块和编码模块封装成对应所述发送编码类型信息和接收编码类型信息的编码转换模型。
5. 根据权利要求1所述的方法，其特征在于，所述通过预设的编码转换模型将所述待传输数据从所述发送编码类型转换到所述接收编码类型，得到编码转换传输数据还包括：
若所述编码转换模型无法将所述待传输数据转换为编码转换传输数据，则通过所述待传输数据的接收编码类型对所述编码转换模型更新。
6. 一种数据传输装置，其特征在于，所述装置包括：
发送编码类型查询单元，用于接收信息发送端发来的待传输数据并且确认所述待传输数据的发送编码类型；
接收编码类型查询单元，用于确认接收所述待传输数据的信息接收端的接收编码类型；
数据转换单元，用于通过预设的编码转换模型将所述待传输数据从所述发送编码类型转换成所述接收编码类型，得到编码转换传输数据，所述编码转换模型用于表征发送编码类型与接收编码类型之间的对应关系；
数据发送单元，用于将所述编码转换传输数据发送给所述信息接收端。
7. 根据权利要求6所述的装置，其特征在于，所述发送编码类型查询单元包括：
编码类型信息查询子单元，用于查询所述待传输数据的发送编码 类型信息；
编码类型确定子单元，用于根据所述发送编码类型信息确定所述待传输数据的发送编码类型。
8. 根据权利要求6所述的装置，其特征在于，所述接收编码类型查询单元包括：
请求消息发送子单元，用于确定对应所述待传输数据的信息接收端，并向所述信息接收端发送请求消息，所述请求消息用于查询所述信息接收端的接收编码类型；
应答消息接收子单元，用于接收所述信息接收端发来的对应所述请求消息的应答消息，所述应答信息用于指示对应所述信息接收端的接收编码类型。
9. 根据权利要求6所述的装置，其特征在于，所述装置还包括：
编码转换模型构建单元，用于构建编码转换模型，所述编码转换模型构建单元包括：
编码类型信息集合构建子单元，用于分别从信息发送端获取发送编码类型信息构成发送编码类型信息集合和从信息接收端获取接收编码类型信息构成接收编码类型信息集合；
解码模块确定子单元，用于确定所述发送编码类型信息对应的发送编码类型的解码模块，所述解码模块用于将具有发送编码类型的待传输数据解码为指定类型的数据内容，所述数据内容包括一下至少一项：文字、图片和视频；
编码模块确定子单元，用于确定用于将所述数据内容转换为编码转换传输数据的编码模块，所述编码转换传输数据具有所述接收编码类型信息对应的接收编码类型，用于信息接收端进行数据处理；
编码转换模型构建子单元，用于将所述解码模块和编码模块封装成对应所述发送编码类型信息和接收编码类型信息的编码转换模型。
10. 根据权利要求6所述的装置，其特征在于，所述数据转换单元还包括：
编码转换模型更新子单元，用于在所述编码转换模型无法将所述待传输数据转换为编码转换传输数据时，通过所述待传输数据的接收编码类型对所述编码转换模型更新。”
申请人（下称复审请求人）对上述驳回决定不服，于2019年03月13日向国家知识产权局提出了复审请求，未提交修改文本。复审请求人认为：（1）本申请的“信息接收端的接收编码类型”指的是在信息接收端不同格式的内容如何编码在其信息流中。而对比文件1中的“最优目标类型”指的是一种具体的数据格式。并且对比文件1获取“最优目标类型”的方式与本申请获取“接收编码类型”的方式不同。因此，对比文件1没有公开技术特征“确认接收所述待传输数据的信息接收端的接收编码类型”。（2）对比文件1中的代码转换器只能转换固定类型的源类型和目标类型。本申请中的“编码转换模型”并不与固定的发送编码类型和接收编码类型对应。且本申请说明书中所述的协议缓存数据和机器人操作系统数据均需要定义文件才能完成数据的转换。可见，本申请在对发送编码类型和接收编码类型进行转换时，并不是如对比文件1利用预置的对应关系就可以实现数据转换。因此，本申请技术方案相对于对比文件1以及本领域的惯用手段的结合具备创造性。
经形式审查合格，国家知识产权局于2019年03月19日依法受理了该复审请求，并将其转送至实质审查部门进行前置审查。
实质审查部门在前置审查意见书中坚持驳回决定。
随后，国家知识产权局成立合议组对本案进行审理。
合议组于2019年05月29日向复审请求人发出复审通知书，复审通知书针对的文本与驳回决定针对的文本相同，引用的对比文件与驳回决定引用的对比文件相同，即上述对比文件1。复审通知书指出：权利要求1-10相对于对比文件1及本领域公知常识的结合，不具备专利法第22条第3款规定的创造性。同时合议组在复审通知书中指出：（1）对比文件1中的“最优目标类型”指的是根据目标发布参量发布的数字数据，其包括“信息接收端的接收编码类型”；并且对比文件1中接收端的接收编码类型获取方式与本申请中的获取方式实质上相同。（2）本申请的权利要求书及说明书的内容中反映了编码转换模型内预设的发送编码类型与接收编码类型之间的对应关系，也即本申请的编码转换模型是由发送编码类型信息对应的解码模块和接收编码类型信息对应的编码模块封装形成的，其同样与固定的发送编码类型和接收编码类型对应。此外，复审请求人提出的“本申请说明书中所述的协议缓存数据和机器人操作系统数据均需要定义文件才能完成数据的转换”，该技术内容未记载在本申请原说明书和权利要求书中，复审请求人提出的其使得本申请具备创造性的理由合议组不予考虑。
复审请求人于2019年07月15日提交了复审无效宣告程序意见陈述书，但未修改申请文件。复审请求人认为：（1）本申请的“信息接收端的接收编码类型”指的是在信息接收端不同格式的内容如何编码在其信息流中。而对比文件1中的“最优目标类型”指的是一种具体的数据格式。并且对比文件1获取“最优目标类型”的方式与本申请获取“接收编码类型”的方式不同。虽然对比文件1公开了“信息接收端的目标类型获取方式：如果目标类型是未知的，任务管理器206可以通过询问浏览者客户端102来获取必要的信息”，但对比文件1没有明确记载需要获取哪些必要的信息，以及根据必要的信息如何确定目标类型。因此，不能确定对比文件1中的接收端的接收编码类型获取方式与本申请中的获取方式实质上相同。对比文件1没有公开权利要求1的技术特征“确认接收所述待传输数据的信息接收端的接收编码类型”。（2）对比文件1中是在进行代码转换前直接从多个代码转换器中选择，此时源类型代码和目标类型对应的代码转换器已经固定。本申请中是由编码转换模型根据发送编码类型和接收编码类型自行进行转换，不需要选择对应的编码模块和解码模块，能够实现多种发送编码类型和接收编码类型之间的转换。因此，对比文件1没有公开权利要求1的技术特征“通过预设的编码转换模型将所述待传输数据从所述发送编码类型转换成所述接收编码类型，得到编码转换传输数据”。（3）本申请说明书中所述的协议缓存数据和机器人操作系统数据属于现有技术，本申请在对发送编码类型和接收编码类型进行转换时，不是如对比文件1所述的利用预置的对应关系就可实现数据转换。
在上述程序的基础上，合议组认为本案事实已经清楚，可以作出审查决定。
二、决定的理由
（一）审查文本的认定
复审请求人在复审过程中未对申请文件进行修改。本复审请求审查决定针对的文本为：复审请求人于申请日2016年09月12日提交的权利要求第1-10项，说明书第1-13页，说明书附图第1-5页，说明书摘要及摘要附图。
（二）关于创造性
专利法第22条第3款规定：“创造性，是指与现有技术相比，该发明具有突出的实质性特点和显著的进步，该实用新型具有实质性特点和进步。”
本复审请求审查决定所引用的对比文件与驳回决定和复审通知书中所引用的对比文件相同，即：
对比文件1：CN101594518A，公开日为2009年12月02日。
1、权利要求1要求保护一种数据传输方法。对比文件1作为最接近的现有技术，其公开了一种分布式随选媒体代码转换方法和系统，并具体公开了以下内容（参见说明书第8页第1行-第12页第22行，第25页第13-23行，第30页第20行至第33页第5行，图1-7）：代码转换系统的一个操作环境100包括一个浏览者客户端102，一个内容提供商客户端104，一个媒体内容代码转换引擎106和一个网络108。浏览者客户端102、内容提供商客户端104和媒体内容代码转换引擎106均通过一个网络108相连。媒体内容代码转换引擎106担当内容提供商客户端104和浏览者客户端102之间的中间层。媒体内容代码转换引擎106从浏览者客户端102接收媒体内容请求，并且从内容提供商客户端104获取所请求的媒体内容（相当于，接收信息发送端发来的待传输数据）。然后媒体内容代码转换引擎106将从内容提供商客户端104接收到的媒体内容由一种源类型代码转换成一种可以被浏览者客户端102接纳的目标类型，并将代码转换后的媒体内容发送给浏览者客户端102。媒体内容代码转换引擎106包括一个或多个代码转换服务器218。代码转换服务器218将特定类型的媒体内容(这里指源类型)转化成另一种媒体类型(这里指目标类型)。图6显示了一个随选将源类型媒体内容610代码转换成目标类型媒体内容650的例子代码转换服务器218。源类型媒体内容610是在网络上用一个或多个数据包发送的数字数据。组成源类型媒体内容610的数字数据由一个或多个发布参量来定义。如图6所示，发布参量包括一个或多个下列参量，源文件格式、源比特率、源物理媒介、源通信协议、源编码或其中的任何组合。目标类型媒体内容650是在网络上用一个或多个数据包发送给请求媒体内容的终端用户的数字数据。组成目标类型媒体内容650的数字数据也由一个或多个发布参量来定义。如图6所示，发布参量包括一个或多个下列参量，目标文件格式、目标比特率、目标物理媒介、目标通信协议、目标编码或其中的任何组合（也即定义源类型媒体内容610的发布参量包括源编码，定义目标类型媒体内容650的发布参量包括目标编码，代码转换服务器218执行所述代码转换需确认待传输数据的发送编码类型以及待传输数据的的信息接收端的接收编码类型）。图7显示了一个实现的例子，其中一个或多个代码转换服务器218随选地将源类型媒体内容710代码转换成第一类目标类型750，以及其中一个或多个代码转换服务器218随选地将源类型媒体内容710代码转换成第二类目标类型760。源类型媒体内容710包括根据下列源发布参量发布的数字数据，即物理媒介是一个本地磁盘，通信协议包括一个文件I/O，文件格式是使用每秒128K比特(128Kbps)MP3编码的MP3。目标类型750包括为下列目标发布参量进行代码转换的数字数据，即物理媒介是分组交换网络，通信协议包括WINDOWS媒体流MMS协议，文件格式是使用56Kbps MP3编码的WINDOWS媒体文件。第二类媒体内容的类型760包括为下列目标发布参量进行代码转换的数字数据，即物理媒介是无线网络，通信协议包括HTTP，文件格式是使用12Kbps MP3编码的MP3。
对比文件1中公开了代码转换器将源类型媒体内容代码转换至目标类型的媒体内容，结合对比文件1的图7和表2-5中代码转换器操作的例子，本领域技术人员可以直接地、毫无疑义地确定所述一个或多个代码转换服务器218包括表征媒体内容的源类型到目标类型之间的对应关系的内容。上述技术特征为对比文件1隐含公开的内容。
权利要求1请求保护的方案与对比文件1公开的内容相比，二者的区别特征在于：权利要求1的预设的编码转换模型仅涉及将待传输数据从发送编码类型转换成接收编码类型，而对比文件1中的代码转换涉及将源类型媒体内容代码转换至目标类型的媒体内容，其中源类型媒体内容和目标类型的媒体内容分别为根据源发布参量发布的数字数据和根据目标发布参量发布的数字数据，所述发布参量包括编码类型在内的媒体内容不同特性。因此权利要求1实际要解决的技术问题为：如何设计仅涉及编码类型转换的代码转换器的具体操作。
对于上述区别特征，对比文件1公开了在对目标类型与源类型的媒体内容具有多种不同特性的情况下的代码转换器，而进行编码转换是代码转换的具体形式之一，在实际应用中目标类型与源类型的媒体内容仅涉及编码类型转换的情况下，本领域技术人员有动机对对比文件1中的代码转换器进行适当改型，使其仅用于执行编码转换操作，这种改型对本领域技术人员来说是常规的选择，属于本领域的惯用手段。
由此可见，在对比文件1的基础上结合本领域的惯用手段，从而得出权利要求1请求保护的技术方案，对于本领域技术人员来说是显而易见的。因此，权利要求1不具有突出的实质性特点和显著的进步，不具备专利法第22条第3款规定的创造性。
2、权利要求2-4引用独立权利要求1。对比文件1公开了以下内容（参见说明书第20页第20-29行）：如果任务管理器206判断出请求信息是不完整的，它将如步骤506和508所示去获取必要的信息。例如，如果源类型或源位置没有包括在请求中，并且所请求的媒体内容被存储在媒体内容代码转换引擎106中，任务管理器206可以查询数据库210来找出必要的源信息。或者，如果媒体内容存储在媒体内容代码转换引擎106的外部，任务管理器206可以进行一次网络请求以从内容提供商的网站中获取必要的信息。另外，如果目标类型是未知的，任务管理器206可以通过询问浏览者客户端102来获取必要的信息。也即对比文件1公开了分别从信息发送端和信息接收端获取必要信息，如源类型和目标类型。
而通过请求-应答的方式来询问获得相关信息属于本领域的惯用手段。通过将源编码类型的数据内容解码为原始数据或中间编码类型的数据内容，再编码为目标编码类型的数据内容，属于本领域中常见的编码转换操作方式，因此将进行所述解码操作的模块和所述编码操作的模块封装成进行具体编码转换的设备，属于本领域的惯用手段。文字、图片和视频均属于本领域常见的数据内容类型。因此，当其引用的权利要求1不具备创造性时，权利要求2-4也不具备专利法第22条第3款规定的创造性。
3、权利要求5引用独立权利要求1。对比文件1公开了以下技术特征（参见说明书第13页第24行至第14页第9行）：机房216包括将资源数据代码转换成恰当的目标类型的代码转换器218；在实施例中，机房使用一种插件结构类实现，插件结构使得可以不断的增加代码转换服务，从而确保媒体内容代码转换引擎106可以适用于新的媒体类型。也即对比文件1公开了当无法进行代码转换时，可以通过插件的方式保障代码转换服务。为了确保能够提供服务，选择插件的方式或本领域常见的其它方式，如升级或更新，均属于本领域技术人员的常规设计选择。因此，当其引用的权利要求1不具备创造性时，权利要求5也不具备专利法第22条第3款规定的创造性。
4、权利要求6要求保护一种数据传输装置。对比文件1作为最接近的现有技术，其公开了一种分布式随选媒体代码转换方法和系统，并具体公开了以下内容（参见说明书第8页第1行-第12页第22行，第25页第13-23行，第30页第20行至第33页第5行，图1-7）：代码转换系统的一个操作环境100包括一个浏览者客户端102，一个内容提供商客户端104，一个媒体内容代码转换引擎106和一个网络108。浏览者客户端102、内容提供商客户端104和媒体内容代码转换引擎106均通过一个网络108相连。媒体内容代码转换引擎106担当内容提供商客户端104和浏览者客户端102之间的中间层。媒体内容代码转换引擎106从浏览者客户端102接收媒体内容请求，并且从内容提供商客户端104获取所请求的媒体内容（相当于，接收信息发送端发来的待传输数据）。然后媒体内容代码转换引擎106将从内容提供商客户端104接收到的媒体内容由一种源类型代码转换成一种可以被浏览者客户端102接纳的目标类型，并将代码转换后的媒体内容发送给浏览者客户端102。媒体内容代码转换引擎106包括一个或多个代码转换服务器218。代码转换服务器218将特定类型的媒体内容(这里指源类型)转化成另一种媒体类型(这里指目标类型)。图6显示了一个随选将源类型媒体内容610代码转换成目标类型媒体内容650的例子代码转换服务器218。源类型媒体内容610是在网络上用一个或多个数据包发送的数字数据。组成源类型媒体内容610的数字数据由一个或多个发布参量来定义。如图6所示，发布参量包括一个或多个下列参量，源文件格式、源比特率、源物理媒介、源通信协议、源编码或其中的任何组合。目标类型媒体内容650是在网络上用一个或多个数据包发送给请求媒体内容的终端用户的数字数据。组成目标类型媒体内容650的数字数据也由一个或多个发布参量来定义。如图6所示，发布参量包括一个或多个下列参量，目标文件格式、目标比特率、目标物理媒介、目标通信协议、目标编码或其中的任何组合（也即定义源类型媒体内容610的发布参量包括源编码，定义目标类型媒体内容650的发布参量包括目标编码，代码转换服务器218执行所述代码转换需确认待传输数据的发送编码类型以及待传输数据的的信息接收端的接收编码类型）。图7显示了一个实现的例子，其中一个或多个代码转换服务器218随选地将源类型媒体内容710代码转换成第一类目标类型750，以及其中一个或多个代码转换服务器218随选地将源类型媒体内容710代码转换成第二类目标类型760。源类型媒体内容710包括根据下列源发布参量发布的数字数据，即物理媒介是一个本地磁盘，通信协议包括一个文件I/O，文件格式是使用每秒128K比特(128Kbps)MP3编码的MP3。目标类型750包括为下列目标发布参量进行代码转换的数字数据，即物理媒介是分组交换网络，通信协议包括WINDOWS媒体流MMS协议，文件格式是使用56Kbps MP3编码的WINDOWS媒体文件。第二类媒体内容的类型760包括为下列目标发布参量进行代码转换的数字数据，即物理媒介是无线网络，通信协议包括HTTP，文件格式是使用12Kbps MP3编码的MP3。
对比文件1中公开了代码转换器将源类型媒体内容代码转换至目标类型的媒体内容，结合对比文件1的图7和表2-5中代码转换器操作的例子，本领域技术人员可以直接地、毫无疑义地确定所述一个或多个代码转换服务器218包括表征媒体内容的源类型到目标类型之间的对应关系的内容。上述技术特征为对比文件1隐含公开的内容。
权利要求6请求保护的方案与对比文件1公开的内容相比，二者的区别特征在于：（1）权利要求6的预设的编码转换模型仅涉及将待传输数据从发送编码类型转换成接收编码类型，而对比文件1中的代码转换涉及将源类型媒体内容代码转换至目标类型的媒体内容，其中源类型媒体内容和目标类型的媒体内容分别为根据源发布参量发布的数字数据和根据目标发布参量发布的数字数据，所述发布参量包括编码类型在内的媒体内容不同特性。（2）权利要求6限定了具体的功能模块来实现上述操作。因此权利要求6实际要解决的技术问题为：如何设计仅涉及编码类型转换的代码转换器的具体操作；实现设备的结构设计。
针对上述区别特征1），对比文件1公开了在对目标类型与源类型的媒体内容具有多种不同特性的情况下的代码转换器，而进行编码转换是代码转换的具体形式之一，在实际应用中目标类型与源类型的媒体内容仅涉及编码类型转换的情况下，本领域技术人员有动机对对比文件1中的代码转换器进行适当改型，使其仅用于执行编码转换操作，这种改型对本领域技术人员来说是常规的选择，属于本领域的惯用手段。
针对上述区别特征2），在已知装置的功能的情形下，设置不同的模块来共同实现这些功能是本领域在装置结构设计时的惯用技术手段。
由此可见，在对比文件1的基础上结合本领域的惯用手段，从而得出权利要求6请求保护的技术方案，对于本领域技术人员来说是显而易见的。因此，权利要求6不具有突出的实质性特点和显著的进步，不具备专利法第22条第3款规定的创造性。
5、权利要求7-10引用独立权利要求6。从属权利要求7-10是与方法权利要求2-5相对应的装置权利要求，由于采用相应的功能模块来完成已知的方法是属于本领域的惯用手段，因此参考上文对从属权利要求2-5的评述，在其引用的权利要求不具备创造性的情况下，权利要求7-10也不具备专利法第22条第3款规定的创造性。
（三）对复审请求人相关意见的评述
针对复审请求人于2019年07月15 日答复复审通知书时所提出的意见，合议组认为：
（1）对比文件1中的“最优目标类型”指的是根据目标发布参量发布的数字数据，参见对权利要求1的评述可知，其包括“信息接收端的接收编码类型”。而基于对比文件1公开的“信息接收端的目标类型获取方式：如果目标类型是未知的，任务管理器206可以通过询问浏览者客户端102来获取必要的信息”，本领域技术人员可以直接毫无疑义地确定所述“必要的信息”是使得任务管理器可以获取信息接收端的目标类型的信息，任务管理器的所述获取步骤与权利要求1的“确认接收所述待传输数据的信息接收端的接收编码类型”实质上相同。
（2）本申请的权利要求1中对编码转换模型进行了如下的限定：“用于表征发送编码类型与接收编码类型之间的对应关系”，本申请的说明书第0049-0058段进一步印证了所述内容：编码转换模型能够根据待传输数据的发送编码类型和接收待传输数据的信息接收端的接收编码类型，确定对应的解码模块和编码模块，将待传输数据从发送编码类型转换到接收编码类型，从而得到编码转换传输数据。解码模块用于将具有发送编码类型的待传输数据解码为指定类型的数据内容，发送编码类型信息集合对应多少个发送编码类型，就有多少个解码模块。编码模块还需要对数据内容进行编码，有多少不同的接收编码类型就有多少编码模块。确定了解码模块和编码模块后，将解码模块和编码模块封装起来就构成了编码转换模型。上述内容反映了模型内预设的发送编码类型与接收编码类型之间的对应关系，也即本申请的编码转换模型是由发送编码类型信息对应的解码模块和接收编码类型信息对应的编码模块封装形成的，其同样是在代码转换前根据待传输数据的发送编码类型和接收编码类型选择相应的解码模块和编码模块，构成编码转换模型，因此编码转换模型形成后，其同样与固定的发送编码类型和接收编码类型对应。
（3）复审请求人提出的“本申请说明书中所述的协议缓存数据和机器人操作系统数据均需要定义文件才能完成数据的转换”，该技术内容未记载在本申请原说明书和权利要求书中；并且权利要求书中并无有关所述发送编码类型或接收编码类型属于上述两种类型的记载。
综上所述，合议组对复审请求人提出的意见不予支持。
三、决定
维持国家知识产权局于2018年12月04日对本申请作出的驳回决定。
如对本复审请求审查决定不服,根据专利法第41条第2款的规定，复审请求人可以自收到本决定之日起三个月内向北京知识产权法院起诉。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
