发明创造名称：一种传送附件的方法、装置及系统
外观设计名称：
决定号：180430
决定日：2019-05-28
委内编号：1F262456
优先权日：
申请（专利）号：201210575966.9
申请日：2012-12-26
复审请求人：腾讯科技（深圳）有限公司
无效请求人：
授权公告日：
审定公告日：
专利权人：
主审员：张新宇
合议组组长：吴旭
参审员：贾煜
国际分类号：H04W4/12
外观设计分类号：
法律依据：专利法第22条第3款
决定要点：如果一项权利要求要求保护的技术方案相对于最接近的现有技术存在区别特征，但现有技术中给出了将上述区别特征应用到该最接近的现有技术以解决其存在的技术问题的启示，这种启示使本领域技术人员在面对所述技术问题时，有动机改进该最接近的现有技术并获得要求保护的技术方案，则该权利要求是显而易见的，不具备创造性。
全文：
本复审请求审查决定涉及申请号为201210575966.9，名称为“一种传送附件的方法、装置及系统”的发明专利申请（下称本申请）。申请人为腾讯科技（深圳）有限公司。本申请的申请日为2012年12月26日，公开日为2014年07月02日。
经实质审查，国家知识产权局实质审查部门于2018年07月10日发出驳回决定，驳回了本申请，驳回决定所针对的对比文件如下：
对比文件1：US2010070594A1，公开日：2010年03月18日。
驳回决定的主要理由是：本申请权利要求1-9相对于对比文件1和公知常识的结合不具备专利法第22条第3款规定的创造性。
驳回决定所依据的文本为：申请人于申请日2012年12月26日提交的说明书第1-95段（第1-10页）、说明书附图第1-4页，说明书摘要和摘要附图；于2017年10月31日提交的权利要求第1-9项。
驳回决定所针对的权利要求书内容如下：
“1. 一种传送附件的方法，其特征在于，包括：
消息服务器接收第一移动客户端发送的第一附件消息，所述第一附件消息中携带附件；
解析所述第一附件消息，获取所述第一附件消息中携带的附件；
生成所述附件的文件键值File Key，并将所述附件和所述File Key生成一一对应的对应关系将解析得到的所述附件发送给文件服务器；
接收第二移动客户端发送的提取所述附件的请求，所述请求中携带请求的所述File Key；
将所述File Key作为请求的参数，向所述文件服务器发送所述请求以提取所述附件；
将所述提取的附件序列化为第二附件消息发送给所述第二移动客户端。
2. 根据权利要求1所述的方法，其特征在于，所述将解析得到的所述附件发送给文件服务器包括：
将所述附件通过POST请求方式发送到所述文件服务器，所述POST请求参数包含所述File Key，使得所述文件服务器保存所述附件，以及保存所述附件与所述File Key的所述对应关系。
3. 根据权利要求1或2所述的方法，其特征在于，所述根据所述提取附件的请求，向所述文件服务器发送提取所述附件的请求包括：
根据所述提取附件的请求中携带的请求的附件的信息及所述对应关系，查找到所述File Key；
将所述File Key作为GET请求的参数，向所述文件服务器发送所述GET请求以提取所述附件。
4. 根据权利要求1所述的方法，其特征在于，所述将所述提取的附件序列化为第二附件消息发送给所述第二移动客户端包括：
将所述提取的附件序列化，并将序列化后的附件保存到所述第二附件消息的数据体对应的字段；
计算所述第二附件消息中数据长度，将所述数据长度保存到所述第二附件消息的数据长度对应的字段；
将所述第二附件消息发送给所述第二移动客户端。
5. 一种传送附件的装置，其特征在于，包括：
接收单元，用于接收第一移动客户端发送的第一附件消息，所述第一附件消息中携带附件；
解析单元，用于解析所述接收单元接收的所述第一附件消息；
处理单元，用于解析所述接收单元接收的所述第一附件消息，获取所述第一附件消息中携带的附件；
生成单元，用于将所述处理单元获取的附件生成所述附件的文件键值File Key，并将所述附件和所述File Key生成一一对应的对应关系；
发送单元，用于将所述解析单元解析得到的所述附件发送给文件服务器；
所述接收单元，还用于接收第二移动客户端发送的提取所述附件的请求，所述请求中携带请求的附件的信息；
查找单元，用于根据所述接收单元接收的所述提取附件的请求中携带的请求的附件的信息及所述对应关系，查找到所述File Key；
所述发送单元，还用于将所述File Key作为请求的参数，向所述文件服务器发送所述请求以提取所述附件；
所述发送单元，还用于将所述提取的附件序列化为第二附件消息发送给所述第二移动客户端。
6. 根据权利要求5所述的装置，其特征在于，
所述发送单元，还用于将所述附件通过POST请求方式发送到所述文件服务器，所述POST请求参数包含所述File Key，使得所述文件服务器保存所述附件，以及保存所述附件与所述File Key的所述对应关系。
7. 根据权利要求5或6所述的装置，其特征在于，
所述装置还包括：
查找单元，用于根据所述接收单元接收的所述提取附件的请求中携带的请求的附件的信息及所述对应关系，查找到所述File Key；
所述发送单元，还用于将所述File Key作为GET请求的参数，向所述文件服务器发送所述GET请求以提取所述附件。
8. 根据权利要求5所述的装置，其特征在于，
所述处理单元，还用于将所述提取的附件序列化，以及用于计算所述第 二附件消息中数据长度；
所述装置还包括：
保存单元，用于将所述处理单元序列化后的附件保存到所述第二附件消息的数据体对应的字段，所述发送附件消息用于向所述第二移动客户端发送所述提取的附件序列化；
所述保存单元，还用于将所述处理单元计算的所述数据长度保存到所述第二附件消息的数据长度对应的字段；
所述发送单元，用于将所述第二附件消息发送给所述第二移动客户端。
9. 一种传送附件的系统，其特征在于，包括：
第一移动客户端，消息服务器，文件服务器，第二移动客户端；
其中，所述第一移动客户端，用于向所述消息服务器发送第一附件消息，所述第一附件消息中携带附件；
所述消息服务器，用于接收所述第一移动客户端发送的所述第一附件消息，获取所述第一附件消息中携带的附件；生成所述附件的文件键值File Key，并将所述附件和所述File Key生成一一对应的对应关将解析得到的所述附件发送给所述文件服务器，接收第二移动客户端发送的提取附件的请求，所述请求中携带所述File Key；将所述File Key作为请求的参数，向所述文件服务器发送所述请求以提取所述附件，根据所述提取附件的请求，向所述文件服务器发送提取附件的请求，将所述提取的附件序列化为第二附件消息发送给所述第二移动客户端；
所述文件服务器，用于接收所述消息服务器发送的附件，并保存所述附件，保存所述附件与所述File Key的所述对应关系；接收所述消息服务器发送的GET请求，根据所述GET请求发送所述附件给所述消息服务器；
所述第二移动客户端，用于向所述消息服务器发送提取所述附件的请求，
接收所述消息服务器发送的第二附件消息，所述第二附件消息为所述附件序列化得到。”
申请人（下称复审请求人）对上述驳回决定不服，于2018年10月10日向国家知识产权局提出了复审请求，同时提交了权利要求书的全文修改替换页，其中在权利要求1中补入从属权利要求2的特征，删除了特征“将所述解析单元解析得到的所述附件发送给文件服务器”，权利要求5和权利要求9也相应进行了修改，删除了从属权利要求2和6，调整了权利要求编号和引用关系。复审请求人认为：1）POST请求属于HTTP协议中的一种请求发送的方式，意味着本申请是基于HTTP协议实现的。消息服务器向文件服务器发送和提取附件，而不需要第一移动客户端和第二移动客户端与文件服务器进行交互。基于HTTP协议能够进一步提升传输效率，从而获得更优化的效果。2）本申请采用POST请求传输file key是由于POST请求通常会产生两个TCP数据包，而其他请求只会产生一个TCP数据包，在网络环境差的情况下，两个包在验证数据包完整性上，有非常大的优点。
复审请求人在提出复审请求时提交的修改后的权利要求1、4、7内容如下：
“1. 一种传送附件的方法，其特征在于，包括：
消息服务器接收第一移动客户端发送的第一附件消息，所述第一附件消息中携带附件；
解析所述第一附件消息，获取所述第一附件消息中携带的附件；
生成所述附件的文件键值File Key，并将所述附件和所述File Key生成一一对应的对应关系，将所述附件通过POST请求方式发送到所述文件服务器，所述POST请求参数包含所述File Key，使得所述文件服务器保存所述附件，以及保存所述附件与所述File Key的所述对应关系；
接收第二移动客户端发送的提取所述附件的请求，所述请求中携带请求的所述File Key；
将所述File Key作为请求的参数，向所述文件服务器发送所述请求以提取所述附件；
将所述提取的附件序列化为第二附件消息发送给所述第二移动客户端。”
“4. 一种传送附件的装置，其特征在于，包括：
接收单元，用于接收第一移动客户端发送的第一附件消息，所述第一附件消息中携带附件；
解析单元，用于解析所述接收单元接收的所述第一附件消息；
处理单元，用于解析所述接收单元接收的所述第一附件消息，获取所述第一附件消息中携带的附件；
生成单元，用于将所述处理单元获取的附件生成所述附件的文件键值File Key，并将所述附件和所述File Key生成一一对应的对应关系；
发送单元，用于将所述附件通过POST请求方式发送到所述文件服务器，所述POST请求参数包含所述File Key，使得所述文件服务器保存所述附件，以及保存所述附件与所述File Key的所述对应关系；
所述接收单元，还用于接收第二移动客户端发送的提取所述附件的请求，所述请求中携带请求的附件的信息；
查找单元，用于根据所述接收单元接收的所述提取附件的请求中携带的请求的附件的信息及所述对应关系，查找到所述File Key；
所述发送单元，还用于将所述File Key作为请求的参数，向所述文件服务器发送所述请求以提取所述附件；
所述发送单元，还用于将所述提取的附件序列化为第二附件消息发送给所述第二移动客户端。”
“7. 一种传送附件的系统，其特征在于，包括：
第一移动客户端，消息服务器，文件服务器，第二移动客户端；
其中，所述第一移动客户端，用于向所述消息服务器发送第一附件消息，所述第一附件消息中携带附件；
所述消息服务器，用于接收所述第一移动客户端发送的所述第一附件消息，获取所述第一附件消息中携带的附件；生成所述附件的文件键值File Key，并将所述附件和所述File Key生成一一对应的对应关系，将所述附件通过POST请求方式发送到所述文件服务器，所述POST请求参数包含所述File Key，使得所述文件服务器保存所述附件，以及保存所述附件与所述File Key的所述对应关系，接收第二移动客户端发送的提取附件的请求，所述请求中携带所述File Key；将所述File Key作为请求的参数，向所述文件服务器发送所述请求以提取所述附件，根据所述提取附件的请求，向所述文件服务器发送提取附件的请求，将所述提取的附件序列化为第二附件消息发送给所述第二移动客户端；
所述文件服务器，用于接收所述消息服务器发送的附件，并保存所述附件，保存所述附件与所述File Key的所述对应关系；接收所述消息服务器发送的GET请求，根据所述GET请求发送所述附件给所述消息服务器；
所述第二移动客户端，用于向所述消息服务器发送提取所述附件的请求，
接收所述消息服务器发送的第二附件消息，所述第二附件消息为所述附件序列化得到。”
经形式审查合格，国家知识产权局于2018年11月05日依法受理了该复审请求，并将其转送至实质审查部门进行前置审查。
实质审查部门在前置审查意见书中坚持驳回决定。
随后，国家知识产权局成立合议组对本案进行审理。
合议组于2019年01月31日向复审请求人发出复审通知书，审查所依据的文本为：复审请求人于申请日2012年12月26日提交的说明书第1-10页、说明书附图第1-4页，说明书摘要和摘要附图；于2018年10月10日提交的权利要求第1-7项。复审通知书中引用的对比文件与驳回决定中引用的对比文件相同，即对比文件1。复审通知书详细评述了权利要求1-7相对于对比文件1和公知常识的结合不具备专利法第22条第3款规定的创造性的理由，并且指出基于HTTP协议实现邮件的发送与接收是本领域的公知常识，对比文件1公开的技术方案中发送邮件的客户端设备12与接收邮件的客户端设备19均不与存储附件的网页服务器直接进行交互，同样可以达到本申请的技术效果；采用基于HTTP的POST请求方式传输数据也属于公知常识，在对比文件1已经公开了消息服务器将附件发送给文件服务器的基础上，在需要传输消息服务器产生的与附件相对应的File Key时，本领域技术人员根据公知常识可以想到使用POST请求将File Key和附件发送给文件服务器，以提高传输的可靠性。
复审请求人于2019年03月12日提交了复审无效宣告程序意见陈述书，同时提交了权利要求书的修改替换页，其中在权利要求1和4中补入技术特征“所述第一附件消息还包括所述第一移动客户端处理得到的数据体字段以及数据长度字段，所述数据体字段用于保存序列化后的附件，所述数据长度字段用于保存序列化后的数据长度”、“保存除所述数据体字段以及所述数据长度字段之外所有的消息字段”，权利要求7中补入技术特征“所述第一附件消息还包括所述第一移动客户端处理得到的数据体字段以及数据长度字段，所述数据体字段用于保存序列化后的附件，所述数据长度字段用于保存序列化后的数据长度”。复审请求人认为：对比文件1并未公开移动客户端对附件消息的处理方式，以及消息服务器对附件消息的处理方式，而本申请中公开了移动客户端与消息服务器对附件消息的处理方式。消息服务器基于数据体字段能够使消息服务器确定序列化附件以及附件的数据长度，以完成附件的识别。但是数据体字段和数据长度字段实际上都是一种指示类字段，因此消息服务器不会保存。
复审请求人于2019年03月12日提交的修改后的权利要求书内容如下：
“1. 一种传送附件的方法，其特征在于，包括：
消息服务器接收第一移动客户端发送的第一附件消息，所述第一附件消息中携带附件，所述第一附件消息还包括所述第一移动客户端处理得到的数据体字段以及数据长度字段，所述数据体字段用于保存序列化后的附件，所述数据长度字段用于保存序列化后的数据长度；
解析所述第一附件消息，获取所述第一附件消息中携带的附件；
保存除所述数据体字段以及所述数据长度字段之外所有的消息字段；
生成所述附件的文件键值File Key，并将所述附件和所述File Key生成一一对应的对应关系，将所述附件通过POST请求方式发送到所述文件服务器，所述POST请求参数包含所述File Key，使得所述文件服务器保存所述附件，以及保存所述附件与所述File Key的所述对应关系；
接收第二移动客户端发送的提取所述附件的请求，所述请求中携带请求的所述File Key；
将所述File Key作为请求的参数，向所述文件服务器发送所述请求以提取所述附件；
将所述提取的附件序列化为第二附件消息发送给所述第二移动客户端。
2. 根据权利要求1所述的方法，其特征在于，所述根据所述提取附件的请求，向所述文件服务器发送提取所述附件的请求包括：
根据所述提取附件的请求中携带的请求的附件的信息及所述对应关系，查找到所述File Key；
将所述File Key作为GET请求的参数，向所述文件服务器发送所述GET请求以提取所述附件。
3. 根据权利要求1所述的方法，其特征在于，所述将所述提取的附件序列化为第二附件消息发送给所述第二移动客户端包括：
将所述提取的附件序列化，并将序列化后的附件保存到所述第二附件消息的数据体对应的字段；
计算所述第二附件消息中数据长度，将所述数据长度保存到所述第二附件消息的数据长度对应的字段；
将所述第二附件消息发送给所述第二移动客户端。
4. 一种传送附件的装置，其特征在于，包括：
接收单元，用于接收第一移动客户端发送的第一附件消息，所述第一附件消息中携带附件，所述第一附件消息还包括所述第一移动客户端处理得到的数据体字段以及数据长度字段，所述数据体字段用于保存序列化后的附件，所述数据长度字段用于保存序列化后的数据长度；
解析单元，用于解析所述接收单元接收的所述第一附件消息；
保存除所述数据体字段以及所述数据长度字段之外所有的消息字段；
处理单元，用于解析所述接收单元接收的所述第一附件消息，获取所述第一附件消息中携带的附件；
生成单元，用于将所述处理单元获取的附件生成所述附件的文件键值File Key，并将所述附件和所述File Key生成一一对应的对应关系；
发送单元，用于将所述附件通过POST请求方式发送到所述文件服务器，所述POST请求参数包含所述File Key，使得所述文件服务器保存所述附件，以及保存所述附件与所述File Key的所述对应关系；
所述接收单元，还用于接收第二移动客户端发送的提取所述附件的请求，所述请求中携带请求的附件的信息；
查找单元，用于根据所述接收单元接收的所述提取附件的请求中携带的请求的附件的信息及所述对应关系，查找到所述File Key；
所述发送单元，还用于将所述File Key作为请求的参数，向所述文件服务器发送所述请求以提取所述附件；
所述发送单元，还用于将所述提取的附件序列化为第二附件消息发送给所述第二移动客户端。
5. 根据权利要求4所述的装置，其特征在于，
所述装置还包括：
查找单元，用于根据所述接收单元接收的所述提取附件的请求中携带的请求的附件的信息及所述对应关系，查找到所述File Key；
所述发送单元，还用于将所述File Key作为GET请求的参数，向所述文件服务器发送所述GET请求以提取所述附件。
6. 根据权利要求4所述的装置，其特征在于，
所述处理单元，还用于将所述提取的附件序列化，以及用于计算所述第二附件消息中数据长度；
所述装置还包括：
保存单元，用于将所述处理单元序列化后的附件保存到所述第二附件消息的数据体对应的字段，所述发送附件消息用于向所述第二移动客户端发送所述提取的附件序列化；
所述保存单元，还用于将所述处理单元计算的所述数据长度保存到所述第二附件消息的数据长度对应的字段；
所述发送单元，用于将所述第二附件消息发送给所述第二移动客户端。
7. 一种传送附件的系统，其特征在于，包括：
第一移动客户端，消息服务器，文件服务器，第二移动客户端；
其中，所述第一移动客户端，用于向所述消息服务器发送第一附件消息，所述第一附件消息中携带附件，所述第一附件消息还包括所述第一移动客户端处理得到的数据体字段以及数据长度字段，所述数据体字段用于保存序列化后的附件，所述数据长度字段用于保存序列化后的数据长度；
所述消息服务器，用于接收所述第一移动客户端发送的所述第一附件消息，获取所述第一附件消息中携带的附件；生成所述附件的文件键值File Key，并将所述附件和所述File Key生成一一对应的对应关系，将所述附件通过POST请求方式发送到所述文件服务器，所述POST请求参数包含所述File Key，使得所述文件服务器保存所述附件，以及保存所述附件与所述File Key的所述对应关系，接收第二移动客户端发送的提取附件的请求，所述请求中携带所述File Key；将所述File Key作为请求的参数，向所述文件服务器发送所述请求以提取所述附件，根据所述提取附件的请求，向所述文件服务器发送提取附件的请求，将所述提取的附件序列化为第二附件消息发送给所述第二移动客户端；
所述文件服务器，用于接收所述消息服务器发送的附件，并保存所述附件，保存所述附件与所述File Key的所述对应关系；接收所述消息服务器发送的GET请求，根据所述GET请求发送所述附件给所述消息服务器；
所述第二移动客户端，用于向所述消息服务器发送提取所述附件的请求，
接收所述消息服务器发送的第二附件消息，所述第二附件消息为所述附件序列化得到。”
在上述程序的基础上，合议组认为本案事实已经清楚，可以作出审查决定。
二、决定的理由
（一）审查文本的认定
复审请求人于2019年03月12日答复复审通知书时，提交了权利要求书的全文修改替换页，经审查，上述修改文本的修改之处符合专利法第33条的规定。本复审请求审查决定针对的文本为：复审请求人于申请日2012年12月26日提交的说明书第1-9页、说明书附图第1-4页，说明书摘要和摘要附图；于2019年03月12日提交的权利要求第1-7项。
（二）关于创造性
专利法第22条第3款规定：“创造性，是指与现有技术相比，该发明具有突出的实质性特点和显著的进步，该实用新型具有实质性特点和进步。”
本次复审请求审查决定引用的对比文件与驳回决定和复审通知书所引用的对比文件相同，即：
对比文件1：US2010070594A1，公开日：2010年03月18日。
1、权利要求1请求保护一种传送附件的方法。对比文件1公开了一种电子邮件系统中传送附件的方法，包括（参见对比文件1说明书第44-90段）：电子邮件从客户端设备12传送到管理服务器11，管理服务器11由邮件服务器15（相当于权利要求1的“消息服务器”）和连接到邮件服务器15的网页服务器16（相当于权利要求1中的“文件服务器”）组成；系统管理服务器11从任一客户端设备12以电子邮件的方式接收信息，并通过电子邮件将信息传给其他客户端设备12，邮件服务器15连接到大容量邮箱17以存储邮件正文，网页服务器连接到大容量邮箱18以存储电子邮件的附件；邮件发送者通过客户端设备12接入并登陆管理服务器11，传送附件和邮件正文给管理服务器11，管理服务器11从客户端设备12接收包括正文和附件的电子邮件；一旦接收到来自客户端设备12的电子邮件，邮件服务器15的中心处理器确认电子邮件的标识（相当于权利要求1中的“消息服务器接收第一移动客户端设备发送的第一附件消息，所述第一附件消息中携带附件”）；邮件服务器15将收到的电子邮件分割成邮件正文和附件；邮件服务器15的中心处理器存储邮件正文到邮箱17，并将附件发送到网页服务器16（相当于权利要求1中的“解析所述第一附件消息，获取所述第一附件消息中携带的附件”、“将所述附件发送到所述文件服务器”）；当接收到附件后，网页服务器16的中心处理器确认每个附件的标识；当附件没有设置目的地限制标识，则网页服务器16的中心处理器确认附件为一个普通附件，并将附件存储到邮箱18的存储区域；中心处理器调用单向HASH函数以将附件转换成第二HASH输出值，中心处理器将附件的第二HASH输出值与附件一起存储到邮箱18的HASH存储区域（相当于权利要求1中的“生成所述附件的文件键值File Key，并将所述附件和所述File Key生成一一对应的对应关系”、“所述文件服务器保存所述附件，以及保存所述附件与所述File Key的所述对应关系”），一旦从网页服务器16接收到HASH输出值，邮件服务器15的中心处理器生成URL，URL用于客户端设备12从系统管理服务器11请求传输附件，中心处理器在每个URL上附加部分HASH输出值；生成URL后，邮件服务器15的中心处理器在邮件正文中添加正文对应附件的URL；中心处理器传输添加了URL的邮件正文给外部服务器13；邮件接收者通过客户端19接入外部服务器13，并从外部服务器13的邮箱21中接收邮件正文，客户端设备19的显示单元显示邮件正文、URL、账号和密码，一旦接收者点击URL，外部服务器13请求管理服务器11传输URL对应的附件；一旦接收到传输附件的请求，管理服务器11请求外部服务器13执行待传输附件的鉴权过程；鉴权通过，则管理服务器11开始传输附件；网页服务器16的中心处理单元根据邮件服务器18中存储的URL读取相应的附件，并将该附件发送给外部服务器13，并存储在邮件服务器20 的邮箱21中，该附件接着从邮件服务器20发送到邮件接收者的客户端设备19（相当于权利要求1中的“接收第二移动客户端发送的提取所述附件的请求”、“向所述文件服务器发送请求以提取所述附件”、“将提取的附件发送给第二移动客户端”）。
该权利要求与对比文件1的区别特征在于：1）客户端为移动客户端；2）将所述附件通过POST请求方式发送到所述文件服务器，所述POST请求参数包含所述File Key；将File Key作为请求参数；3）所述第一附件消息还包括所述第一移动客户端处理得到的数据体字段以及数据长度字段，所述数据体字段用于保存序列化后的附件，所述数据长度字段用于保存序列化后的数据长度，保存除所述数据体字段以及所述数据长度字段之外所有的消息字段；将提取的附件序列化为附件消息。基于上述区别特征可以确定，该权利要求实际要解决的技术问题是如何在移动终端便捷的发送及提取附件以节省系统资源，以及如何节省服务器的存储空间。
对于区别特征1），移动客户端可以利用无线网络进行收发邮件的操作是公知的技术，因此将对比文件1的方法用于移动客户端属于本领域的惯用手段。
对于区别特征2），能够通过POST请求的方式传递数据给服务器，File Key为请求参数是本申请的申请日前本领域的公知技术。在陆楠等编著，西安电子科技大学出版社2012年8月出版的教科书《计算机网络实训与编程》的第13章第13.3.3节公开了：采用POST方法的HTTP请求，是将数据放在消息体中传递给服务器，示例中的最后一行是消息体，以键值对的方式传送表单数据，如果要向服务器上传的数据超过1KB，就必须使用POST方法；GET方法通常只是用于请求指定服务器上的资源，这种资源可以是静态的页面或者其他文件；GET方法把要上传给服务器的数据参数附在首行的URL之后，这种方法也用在下载Web邮箱中的附件时，电子信箱中的附件都提供了一个链接，对于不同的附件提供的参数值不同。可见，通过POST请求的方式传递数据给服务器，File Key作为请求参数是本申请的申请日前本领域的公知技术。具体采用POST请求的方式发送附件，以及将File Key作为POST请求的参数发送到文件服务器均属于向服务器传输数据的惯用手段。
对于区别特征3），将附件以序列的形式传输属于数据传输中的惯用手段。在接收到序列化的数据和其信息标识，按照系统配置将该数据及标识信息发送到目的服务器后，在本地将已发送的数据和其标识信息删除以节省存储空间，是服务器处理和存储的常规方式，属于本领域的惯用手段。
因此，在对比文件1的基础上结合本领域的惯用手段得到权利要求1所要求保护的技术方案对本领域技术人员来说是显而易见的，权利要求1不具备突出的实质性特点和显著的进步，因而不具备专利法第22条第3款规定的创造性。
2、对于从属权利要求2，附加特征“根据所述提取附件的请求中携带的请求的附件的信息及所述对应关系，查找到所述File Key”已在对比文件1中公开了（参见对比文件1说明书第82-89段）：邮件接收者通过客户端19接入外部服务器，并从外部服务器13的邮箱21中接收邮件正文，客户端设备19的显示单元显示邮件正文、URL、账号和密码，一旦接收者点击URL，外部服务器13请求管理服务器11传输URL对应的附件；一旦接收到传输附件的请求，管理服务器11请求外部服务器13执行待传输附件的鉴权过程；鉴权通过，则管理服务器11开始传输附件；网页服务器16的中心处理单元根据邮件服务器18中存储的URL（URL中 包含HASH值）读取相应的附件，并将该附件发送给外部服务器13。
而将所述File Key作为GET请求的参数，向文件服务器发送GET请求以提取附件属于公知的技术，在陆楠等编著，西安电子科技大学出版社2012年8月出版的《计算机网络实训与编程》的第13章第13.3.3节公开了：GET方法通常只是用于请求指定服务器上的资源，这种资源可以是静态的页面或者其他文件；GET方法把要上传给服务器的数据参数附在首行的URL之后，这种方法也用在下载Web邮箱中的附件时，电子信箱中的附件都提供了一个链接，对于不同的附件提供的参数值不同。因此，当其引用的权利要求不具备创造性时，该从属权利要求也不具备专利法第22条第3款规定的创造性。
3、对于从属权利要求3，将附件序列化后保存到附件消息的数据体对应的字段，将计算出的数据长度信息保存于数据长度对应的字段，并发送上述信息，均属于数据传输中的惯用手段。因此，当其引用的权利要求不具备创造性时，该从属权利要求也不具备专利法第22条第3款规定的创造性。
4、权利要求4请求保护一种传送附件的装置。对比文件1公开了一种可传送附件的电子邮件系统，包括（参见对比文件1说明书第44-90段）：电子邮件从客户端设备12传送到管理服务器11，管理服务器11由邮件服务器15（相当于权利要求4的“消息服务器”）和连接到邮件服务器的网页服务器16（相当于权利要求4中的“文件服务器”）组成；管理服务器11从任一客户端设备12以电子邮件的方式接收信息，并通过电子邮件将信息传给其他客户端设备12，邮件服务器15连接到大容量邮箱17（数据库）以存储邮件正文，网页服务器16连接到大容量邮箱18（数据库）以存储电子邮件的附件；邮件发送者通过客户端设备12接入并登陆管理服务器11，传送附件和邮件正文给管理服务器11，管理服务器11从客户端设备接收包括正文和附件的电子邮件；一旦接收到来自客户端设备12的电子邮件，邮件服务器15的中心处理器确认电子邮件的标识（相当于权利要求4中的“消息服务器接收第一移动客户端设备发送的第一附件消息，所述第一附件消息中携带附件”）；邮件服务器15将收到的电子邮件分割成邮件正文和附件，邮件服务器15的中心处理器存储邮件正文到邮箱17，并将附件发送到网页服务器16（相当于权利要求4中的“解析所述第一附件消息，获取所述第一附件消息中携带的附件”、“将所述附件发送到所述文件服务器”）；当接收到附件后，网页服务器16的中心处理器确认每个附件的标识；当附件没有设置目的地限制标识，则网页服务器16的中心处理器确认附件为一个普通附件，并将附件存储到邮箱18的存储区域；中心处理器调用单向HASH函数以将附件转换成第二HASH输出值，中心处理器将附件的第二HASH输出值与附件一起存储到邮箱18的HASH存储区域（相当于权利要求4中的“生成所述附件的文件键值File Key，并将所述附件和所述File Key生成一一对应的对应关系”、“所述文件服务器保存所述附件，以及保存所述附件与所述File Key的所述对应关系”）；一旦从网页服务器16接收到HASH输出值，邮件服务器15的中心处理器生成URL，URL用于客户端设备12从系统管理服务器11请求传输附件，中心处理器在每个URL上附加部分HASH输出值；生成URL后，邮件服务器15的中心处理器在邮件正文中添加正文对应附件的URL；中心处理器传输添加了URL的邮件正文给外部服务器13；邮件接收者通过客户端19接入外部服务器13，并从外部服务器13的邮箱21中接收邮件正文，客户端设备19的显示单元显示邮件正文、URL、账号和密码，一旦接收者点击URL，外部服务器13请求管理服务器11传输URL对应的附件；一旦接收到传输附件的请求，管理服务器11请求外部服务器13执行待传输附件的鉴权过程；鉴权通过，则管理服务器11开始传输附件；网页服务器16的中心处理单元根据邮件服务器18中存储的URL读取相应的附件，并将该附件发送给外部服务器13，并存储在邮件服务器20 的邮箱21中，该附件接着从邮件服务器20发送到邮件接收者的客户端设备19（相当于权利要求4中的“接收第二移动客户端发送的提取所述附件的请求”、“向所述文件服务器发送请求以提取所述附件”、“将提取的附件发送给第二移动客户端”）。
该权利要求与对比文件1的区别特征在于：1）客户端为移动客户端；2）将所述附件通过POST请求方式发送到所述文件服务器，所述POST请求参数包含所述File Key；将File Key作为请求参数；3）所述第一附件消息还包括所述第一移动客户端处理得到的数据体字段以及数据长度字段，所述数据体字段用于保存序列化后的附件，所述数据长度字段用于保存序列化后的数据长度，保存除所述数据体字段以及所述数据长度字段之外所有的消息字段；将提取的附件序列化为附件消息；4）传送附件的装置包括接收单元、解析单元、处理单元、生成单元和发送单元。基于上述区别特征可以确定，该权利要求实际要解决的技术问题是如何在移动终端便捷的发送及提取附件以节省系统资源，以及如何节省服务器的存储空间。
对于区别特征1），移动客户端可以利用无线网络进行收发邮件的操作是公知的技术，因此将对比文件1的方法用于移动客户端属于本领域的惯用手段。
对于区别特征2），能够通过POST请求的方式传递数据给服务器，以及将File Key为请求参数是本申请的申请日前本领域的公知技术。在陆楠等编著，西安电子科技大学出版社2012年8月出版的教科书《计算机网络实训与编程》的第13章第13.3.3节公开了：采用POST方法的HTTP请求，是将数据放在消息体中传递给服务器，示例中的最后一行是消息体，以键值对的方式传送表单数据，如果要向服务器上传的数据超过1KB，就必须使用POST方法；GET方法通常只是用于请求指定服务器上的资源，这种资源可以是静态的页面或者其他文件；GET方法把要上传给服务器的数据参数附在首行的URL之后，这种方法也用在下载Web邮箱中的附件时，电子信箱中的附件都提供了一个链接，对于不同的附件提供的参数值不同。可见，通过POST请求的方式传递数据给服务器，以及将File Key为请求参数是本申请的申请日前本领域的公知技术。具体采用POST请求的方式发送附件，以及将File Key作为POST请求的参数发送到文件服务器均属于向服务器传输数据的惯用手段。
对于区别特征3），将附件以序列的形式传输属于数据传输中的惯用手段。在接收到序列化的数据和其信息标识，按照系统配置将该数据及标识信息发送到目的服务器后，在本地将已发送的数据和其标识信息删除以节省存储空间，是服务器处理和存储的常规方式，属于本领域的惯用手段。
对于区别特征4），在装置中设置不同单元执行相应功能以实现已知方法是本领域的惯用手段。
因此，在对比文件1的基础上结合本领域的惯用手段得到权利要求4所要求保护的技术方案对本领域技术人员来说是显而易见的，权利要求4不具备突出的实质性特点和显著的进步，因而不具备专利法第22条第3款规定的创造性。
5、从属权利要求5-6进一步限定的内容分别对应于从属权利要求2-3的附加特征。参见对权利要求2-3的评述，在独立权利要求4不具备创造性情况下，从属权利要求5-6也不具备专利法第22条第3款规定的创造性。
6、权利要求7请求保护一种传送附件的系统。对比文件1公开了一种可传送附件的电子邮件系统，包括（参见对比文件1说明书第44-90段）：电子邮件从客户端设备12，传送到管理服务器11，管理服务器11由邮件服务器15（相当于权利要求7中的“消息服务器”）和连接到邮件服务器15的网页服务器16（相当于权利要求7中的“网页服务器”）组成；邮件发送者通过客户端设备12接入并登陆管理服务器11，传送附件和邮件正文给管理服务器11，管理服务器11从客户端设备接收包括正文和附件的电子邮件，一旦接收到来自客户端设备12的电子邮件，邮件服务器15的中心处理器确认电子邮件的标识（相当于权利要求7中的“消息服务器接收第一移动客户端设备发送的第一附件消息，所述第一附件消息中携带附件”）；邮件服务器15将收到的电子邮件分割成邮件正文和附件，邮件服务器15的中心处理器存储邮件正文到邮箱17，并将附件发送到网页服务器16（相当于权利要求7中的“解析所述第一附件消息，获取所述第一附件消息中携带的附件”、“将所述附件发送到所述文件服务器”）；当接收到附件后，网页服务器16的中心处理器确认每个附件的标识，当附件没有设置目的地限制标识，则网页服务器16的中心处理器确认附件为一个普通附件，并将附件存储到邮箱18的存储区域；中心处理器调用单向HASH函数以将附件转换成第二HASH输出值，中心处理器将附件的第二HASH输出值与附件一起存储到邮箱18的HASH存储区域（相当于权利要求7中的“生成所述附件的文件键值File Key，并将所述附件和所述File Key生成一一对应的对应关系”、“所述文件服务器保存所述附件，以及保存所述附件与所述File Key的所述对应关系”），一旦从网页服务器16接收到HASH输出值，邮件服务器15的中心处理器生成URL，URL用于客户端设备12从系统管理服务器11请求传输附件，中心处理器在每个URL上附加部分HASH输出值；生成URL后，邮件服务器15的中心处理器在邮件正文中添加正文对应附件的URL；中心处理器传输添加了URL的邮件正文给外部服务器13；邮件接收者通过客户端19接入外部服务器13，并从外部服务器13的邮箱21中接收邮件正文，客户端设备19的显示单元显示邮件正文、URL、账号和密码，一旦接收者点击URL，外部服务器13请求管理服务器11传输URL对应的附件；一旦接收到传输附件的请求，管理服务器11请求外部服务器13执行待传输附件的鉴权过程；鉴权通过，则管理服务器11开始传输附件；网页服务器16的中心处理单元根据邮件服务器18中存储的URL读取相应的附件，并将该附件发送给外部服务器13，并存储在邮件服务器20 的邮箱21中，该附件接着从邮件服务器20发送到邮件接收者的客户端设备19（相当于权利要求7中的“接收第二移动客户端发送的提取所述附件的请求”、“向所述文件服务器发送请求以提取所述附件”、“将提取的附件发送给第二移动客户端”）。
该权利要求与对比文件1的区别特征在于：1）客户端为移动客户端；2）将所述附件通过POST请求方式发送到所述文件服务器，所述POST请求参数包含所述File Key；将File Key为请求参数；接收所述消息服务器发送的GET请求，根据所述GET请求发送所述附件给所述消息服务器；3）所述第一附件消息还包括所述第一移动客户端处理得到的数据体字段以及数据长度字段，所述数据体字段用于保存序列化后的附件，所述数据长度字段用于保存序列化后的数据长度；将提取的附件序列化为附件消息。基于上述区别特征可以确定，该权利要求实际要解决的技术问题是如何在移动终端便捷的发送及提取附件以节省系统资源。
对于区别特征1），移动客户端可以利用无线网络进行收发邮件的操作是公知的技术，因此将对比文件1的方法用于移动客户端属于本领域的惯用手段。
对于区别特征2），通过POST请求的方式传递数据给服务器，提取附件的请求中携带请求的所述File Key，File Key为请求参数，以及接收发送的GET请求，根据所述GET请求发送所述附件给请求端是本申请的申请日前本领域的公知技术。在陆楠等编著，西安电子科技大学出版社2012年8月出版的教科书《计算机网络实训与编程》的第13章第13.3.3节公开了：采用POST方法的HTTP请求，是将数据放在消息体中传递给服务器，示例中的最后一行是消息体，以键值对的方式传送表单数据，如果要向服务器上传的数据超过1KB，就必须使用POST方法；GET方法通常只是用于请求指定服务器上的资源，这种资源可以是静态的页面或者其他文件；GET方法把要上传给服务器的数据参数附在首行的URL之后，这种方法也用在下载Web邮箱中的附件时，电子信箱中的附件都提供了一个链接，对于不同的附件提供的参数值不同。可见，通过POST请求的方式传递数据给服务器，提取附件的请求中携带请求的所述File Key，File Key为请求参数，以及接收发送的GET请求，根据所述GET请求发送所述附件给请求端是本申请的申请日前本领域的公知技术。具体采用POST请求的方式发送附件，以及将File Key作为POST请求的参数发送到文件服务器均属于向服务器传输数据的惯用手段。
对于区别特征3），将附件以序列的形式传输属于数据传输中的惯用手段。而将序列化后附件作为消息的数据体，并获取其长度作为长度标识字段属于数据发送处理中常规的处理方式，属于本领域的惯用手段。
因此，在对比文件1的基础上结合本领域的惯用手段得到权利要求7所要求保护的技术方案，对本领域技术人员来说是显而易见的。权利要求7不具备突出的实质性特点和显著的进步，因而不具备专利法第22条第3款规定的创造性。
（三）关于复审请求人的意见
针对复审请求人2019年03月12日提交的意见陈述书中的主张，合议组认为：虽然对比文件未明确写出附件以何种方式在邮件服务器和网页服务器之间传送，但是在文件发送前对文件进行序列化处理，将序列化的数据作为数据体并生成数据体长度的标识信息，从而便于传输和邮件服务器进一步将附件进行转发属于数据在终端和服务器间传输的常规处理方式。而为了节省服务器的存储空间，将已转发并在本地无需存储的数据丢弃、不进行存储也是一种常规的处理，这不需要本领域技术人员付出创造性劳动。因此，合议组对上述陈述意见书中的主张不予支持。
基于上述理由，合议组作出如下审查决定。
三、决定
维持国家知识产权局于2018年07月10日对本申请作出的驳回决定。
如对本复审请求审查决定不服，根据专利法第41条第2款的规定，复审请求人可以自收到本决定之日起三个月内向北京知识产权法院起诉。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
