发明创造名称：控制信息处理方法
外观设计名称：
决定号：186586
决定日：2019-08-02
委内编号：1F273158
优先权日：2013-09-08
申请（专利）号：201410244991.8
申请日：2014-06-04
复审请求人：王正伟
无效请求人：
授权公告日：
审定公告日：
专利权人：
主审员：李彦欣
合议组组长：孙志玲
参审员：白晶心
国际分类号：H04L12/58
外观设计分类号：
法律依据：专利法第二十二条第三款
决定要点
：若一项权利要求请求保护的技术方案与一篇对比文件相比存在区别特征，但该区别特征属于本领域的惯用手段，在该对比文件的基础上结合本领域的惯用手段得到该权利要求的技术方案对本领域技术人员而言是显而易见的，则该权利要求不具备创造性。
全文：
本复审请求涉及申请号为201410244991.8，名称为“控制信息处理方法”的发明专利申请（下称本申请）。申请人为王正伟。本申请的申请日为2014年06月04日，优先权日为2013年09月08日，公开日为2015年03月18日。
经实质审查，国家知识产权局原审查部门于2019年01月07日发出驳回决定，驳回了本申请，驳回决定中引用了以下对比文件：对比文件1：CN101621764A，公开日为2010年01月06日。驳回的理由是：权利要求1-4、6-8相对于对比文件1及本领域惯用手段的结合不具备专利法第二十二条第三款规定的创造性。权利要求1-4、6-8与权利要求5、9-10之间不具备专利法第三十一条第一款规定的单一性。
驳回决定所依据的文本为：2018年04月24日提交的权利要求第1-10项，申请日2014年06月04日提交的说明书第1-281段（即第1-22页）、说明书附图第1-3页、说明书摘要以及摘要附图。
驳回决定所针对的权利要求书内容如下：
“1.一种控制信息处理方法，其特征在于，建立主叫与即时通信客户端(IMClient)的对应关系；所述方法包括以下步骤：
a、通信终端接收控制信息，根据主叫；按照建立的主叫与IMClient的对应关系，确定对应的IMClient；
f、启动所述对应的IMClient。
2.根据权利要求1所述的方法，其特征在于，所述的建立主叫与IMClient的对应关系进一步是：
建立主叫号码与IMClient的对应关系；
或者，建立用于匹配主叫号码的匹配码与IMClient的对应关系。
3.一种控制信息处理方法，其特征在于，建立主叫与IMClient的对应关系；所述方法包括以下步骤：
a、通信终端接收控制信息，根据主叫；按照建立的主叫与IMClient的对应关系，确定对应的IMClient；
f、向所述对应的IMClient传送相关信息。
4.根据权利要求3所述的方法，其特征在于，所述的建立主叫与IMClient的对应关系进一步是：
建立主叫号码与IMClient的对应关系；
或者，建立用于匹配主叫号码的匹配码与IMClient的对应关系。
5.一种控制信息识别方法，其特征在于，设置控制列表，用于保存通信号码；通信终端判断一个消息的主叫号码是否匹配控制列表中的通信号码，如果是，则将所述消息作为控制信息，否则，不将所述消息作为控制信息。
6.一种IMClient控制方法，其特征在于，建立主叫与IMClient的对应关系；所述方法包括以下步骤：
a、向通信终端发送控制信息；
b、所述通信终端接收控制信息，根据主叫；按照建立的主叫与IMClient的对应关系，确定对应的IMClient。
f、所述通信终端启动所述对应的IMClient。
7.根据权利要求6所述的方法，其特征在于，所述的建立主叫与IMClient的对应关系进一步是：
建立主叫号码与IMClient的对应关系；
或者，建立用于匹配主叫号码的匹配码与IMClient的对应关系。
8.根据权利要求6或7所述的方法，在账户信息中设置通信号码属性；其特征在于，在步骤a中，在向通信终端发送控制信息时，将相应账户的通信号码属性值作为被叫号码。
9.一种控制信息识别模块，其特征在于，在该模块中设置控制列表，用于保存通信号码；所述模块判断一个消息的主叫号码是否匹配控制列表中的通信号码，如果是，则将所述消息作为控制信息，否则，不将所述消息作为控制信息。
10.根据权利要求9所述的方法，所述控制列表中进一步包括AppName，所述AppName 用于指示对应的IMClient；其特征在于，在判断所述消息为控制信息后，
启动对应指示的IMClient；
或者，向对应指示的IMClient传送相关信息。”
申请人（下称复审请求人）对上述驳回决定不服，于2019年02月08日向国家知识产权局提出了复审请求，未提交修改文本。复审请求人认为：（1）本申请增加了非法攻击难度，按照本申请，攻击者在实施攻击时需要模仿主叫号码，而模仿主叫号码难度非常大，风险也很大。而对比文件1的技术方案对短信主叫号码没有鉴别，犯罪分子在任何地方都可以发送短消息，攻击某个人的手机微信客户端。（2）对比文件1是通过短消息内容部分携带区分不同APP的端口号，需要消耗短消息的有效承载。而本申请是通过主叫号码来隐含携带相应APP客户端信息的，因此可以节省短消息的承载。本来按照本申请用一条短信可以推送的内容，用对比文件1的方案却可能需要两条短信。（3）对比文件1根据短消息内容区分短消息是否是Java短消息，存在冲突风险，即如果正常短消息的内容和Java短消息用于区分端口号的区分标志相同，就会导致这条正常短消息被误传给Java模块。（4）对比文件1在手机侧建立端口号与相应APP对应关系时，还需要将该端口号登记到相应的APP服务器中，服务器侧也要实施并维护这样的对应关系表；而本申请在手机侧建立主叫号码与相应APP对应关系时，不需要服务器参与即可实施，大大简化了业务实施流程，降低业务实施难度。（5）本申请与对比文件1相比，采用了完全不同的技术方案，达到了完全不同的技术效果，具有突出的实质性特点。
经形式审查合格，国家知识产权局于2019年03月27日依法受理了该复审请求，并将其转送至原审查部门进行前置审查。
原审查部门在前置审查意见书中坚持驳回决定。
随后，国家知识产权局成立合议组对本案进行审理。
合议组于2019年06月20日向复审请求人发出复审通知书，本次复审通知书依据的审查文本与驳回决定所依据的审查文本相同，引用的对比文件与驳回决定中引用的对比文件相同，即对比文件1。通知书中指出：独立权利要求1、3、6与独立权利要求5、9之间不具备专利法第三十一条第一款规定的单一性，权利要求1-4、6-8相对于对比文件1及本领域惯用手段的结合不具备专利法第二十二条第三款规定的创造性，并针对复审请求人陈述的意见进行了阐述，指出：（1）对于对比文件1 的技术方案，攻击者要想进行攻击不需要模仿主叫号码，而是需要知道规定的端口号，而攻击者很难知晓具体哪个手机安装了Java Push机制，也很难知晓规定的SMS协议的端口号，因此攻击者不能随意模拟控制消息进行攻击，对比文件1同样增加了非法攻击难度。（2）对比文件1公开了（参见说明书第5页第5段）“应用服务器可以把发送信息封装为短消息格式，包括有目标手机的号码、信息内容以及目的端口号50001，并设定默认的发送端口号为0”，可见对比文件1的短消息中封装的端口号并不在短消息的内容部分，而是封装在短消息中用来区分发送的目的端口，目标手机通过监听相应端口来接收短消息。因此，对比文件1也节省了承载，不存在需要发两条短消息的问题。（3）如前所述，对比文件1的短消息中封装的端口号并不在短消息的内容部分，目标手机是通过监听相应端口来接收短消息并确定为Java短消息的，而普通短消息采用的是不同的接收端口，因此并不存在复审请求人所述的冲突问题。（4）本申请说明书第[0251]-[0255]段记载了“HSvr-D构造短消息，将13316882223@139.com的用户名13316882223作为该短消息的被叫号码，短消息内容为字符串“/*OP_Adv*/沃尔玛糖果打5折*/”；将该短消息发送出去，其中，短消息的主叫号码为1065905790015160169”，其中，HSvr-D为服务器，其构造短消息并对短消息进行转发，则其必然是要参与业务实施流程的，可见本申请中的服务器也参与业务实施流程。（5）对比文件1中通过短消息中心向目标手机终端发送短消息来激活目标手机终端上的即时通讯应用，使得信息即时的到达目标手机。可见，对比文件1与本申请的发明构思是一致的，都是通过控制消息来控制终端上的即时通信客户端，实现了用户消息的及时送达从而提高用户体验。
复审请求人于2019年06月24日提交了意见陈述书，同时修改了权利要求书，删除了权利要求5、9和10，并调整了权利要求的编号和引用关系。复审请求人认为：（1）对比文件1通过端口号来识别不同的APP客户端，对主叫号码不进行识别，为攻击者实施攻击提供了便利，攻击者可截获微信服务器发送的短信，从而获取微信APP对应的端口号。而按照本申请，攻击者想要进行攻击，即使知道微信服务器发送短消息的主叫号码，但由于模仿主叫号码困难，也难以实施非法攻击，因此比对比文件1多出一层安全防护圈，增加了非法攻击难度。（2）对比文件1中，可能需要专门的机构来负责APP的SMS协议端口号的申请，或者在用户手机安装APP过程中需要向服务器上报SMS协议端口号，因此增加了业务实施难度。而按照本申请，APP服务商从电信公司申请了短信业务码后，直接将该号码写入安装程序，在安装过程中直接在手机里的“主叫与IMClient的对应关系表”中增加一条记录即可，相比之下，业务实施更简洁。（3）如果对比文件1不是通过短消息内容来携带所述端口号，而是占用了短消息协议的某个信元，就降低了未来短消息协议的业务可扩展性。而本申请不需要额外占用短消息的协议信元，仅仅是利用了短消息协议中早已被定义的协议信元（主叫号码部分），更加有助于后续业务的开展。（4）本申请巧妙地利用了短消息的主叫号码来实施，达到了意想不到的技术效果。
此次提交的权利要求书内容如下：
“1.一种控制信息处理方法，其特征在于，建立主叫与即时通信客户端(IMClient)的对应关系；所述方法包括以下步骤：
a、通信终端接收控制信息，根据主叫；按照建立的主叫与IMClient的对应关系，确定对应的IMClient；
f、启动所述对应的IMClient。
2.根据权利要求1所述的方法，其特征在于，所述的建立主叫与IMClient的对应关系进一步是：
建立主叫号码与IMClient的对应关系；
或者，建立用于匹配主叫号码的匹配码与IMClient的对应关系。
3.一种控制信息处理方法，其特征在于，建立主叫与IMClient的对应关系；所述方法包括以下步骤：
a、通信终端接收控制信息，根据主叫；按照建立的主叫与IMClient的对应关系，确定对应的IMClient；
f、向所述对应的IMClient传送相关信息。
4.根据权利要求3所述的方法，其特征在于，所述的建立主叫与IMClient的对应关系进一步是：
建立主叫号码与IMClient的对应关系；
或者，建立用于匹配主叫号码的匹配码与IMClient的对应关系。
5.一种IMClient控制方法，其特征在于，建立主叫与IMClient的对应关系；所述方法包括以下步骤：
a、向通信终端发送控制信息；
b、所述通信终端接收控制信息，根据主叫；按照建立的主叫与IMClient的对应关系，确定对应的IMClient。
f、所述通信终端启动所述对应的IMClient。
6.根据权利要求5所述的方法，其特征在于，所述的建立主叫与IMClient的对应关系进一步是：
建立主叫号码与IMClient的对应关系；
或者，建立用于匹配主叫号码的匹配码与IMClient的对应关系。
7.根据权利要求5或6所述的方法，在账户信息中设置通信号码属性；其特征在于，在步骤a中，在向通信终端发送控制信息时，将相应账户的通信号码属性值作为被叫号码。”
在上述程序的基础上，合议组认为本案事实已经清楚，可以作出审查决定。
二、决定的理由
（一）审查文本的认定
本复审请求审查决定所依据的文本为：复审请求人于2019年06月24日提交的权利要求第1-7项，申请日2014年06月04日提交的说明书第1-22页、说明书附图第1-3页、说明书摘要以及摘要附图。经审查，复审请求人于2019年06月24日提交的权利要求书的修改之处符合专利法第三十三条的规定。
（二）关于创造性
专利法第二十二条第三款规定：创造性，是指与现有技术相比，该发明具有突出的实质性特点和显著的进步，该实用新型具有实质性特点和进步。
本复审请求审查决定与2019年06月20日发出的复审通知书以及驳回决定中引用的对比文件相同，即：
对比文件1：CN101621764A，公开日为2010年01月06日。
1、权利要求1请求保护一种控制信息处理方法，对比文件1公开了一种基于Java Push机制手机通讯应用的信息传送方法及系统，并具体公开了以下技术内容（参见说明书第2页第5行至第19行、第4页第13行至第5页第27行，图3-4）：本发明的目的在于提供一种基于Java Push机制手机通讯应用的信息传送方法，通过应用服务器和短消息中心的接口，由短消息中心向目标手机终端发送短消息来激活目标手机终端上的即时通讯应用，使得信息即时的到达目标手机；图4为基于Java Push机制的手机应用的信息实时传送流程，步骤401：目标手机在安装IM应用程序过程中进行Java Push注册，针对IM应用的注册条目为MIDlet-Push-1:sms://:50001，com.sample.IM，*，注册的协议为SMS协议，监听端口号为50001，手机将对SMS 协议的50001端口进行监听；步骤402：在发送手机上启动IM应用，登录到应用服务器上，此时，在发送手机上可以看到，目标手机对应的联系帐号是离线状态，向该联系帐号发送信息，信息通过发送手机和服务器的连接发送到应用服务器上；步骤403：应用服务器和短消息中心建立连接，当服务器接收到新信息后，向短消息中心发送消息，应用服务器可以把发送信息封装为短消息格式，包括有目标手机的号码、信息内容以及目的端口号50001，并设定默认的发送端口号为0，设定短消息的编码格式；步骤404：服务器把封装好的短消息发送到短消息中心；步骤405：短消息中心发送该消息到目标手机；步骤406：目标手机接收到该短消息后，消息处理模块根据短消息的格式，因为该消息带有端口号，所以判断为Java短消息，交给Java模块处理，而不会作为普通短消息存入短信收件箱；Java模块提取出短消息的协议为SMS协议，端口号为50001，从Push注册条目中匹配到对应的J2ME IM应用（相当于本申请权利要求1中的：通信终端接收控制信息，确定对应的IMClient），手机自动启动IM应用（相当于本申请权利要求1中的：启动所述对应的IMClient），可以设置对用户进行启动提示；步骤407：IM应用启动，用户接收到提示后，选择和应用服务器建立连接，获取到最新的信息，此时，发送的信息实时的传送到了接收端。
权利要求1的技术方案与对比文件1公开的内容的区别在于：建立主叫与即时通信客户端(IMClient)的对应关系，根据主叫，按照建立的主叫与IMClient的对应关系确定对应的IMClient；而对比文件1中是建立端口号与即时通信客户端的对应关系，通过监听端口号来确定对应的IMClient。基于该区别可确定，权利要求1实际要解决的技术问题是采用何种方式来确定IMClient。
对于上述区别，本领域中，应用客户端向用户推送的短消息中通常都携带有与该应用客户端相对应的主叫号码，比如微信、手机银行、中国移动等应用向用户推送的短消息中都带有特有的主叫号码，这属于本领域的惯用手段。可见，上述惯用手段已经给出了主叫号码与应用客户端具有对应关系的技术启示，在此启示下，本领域技术人员有动机采用建立主叫与IMClient的对应关系并根据主叫来确定对应的IMClient的方式来代替对比文件1中的建立端口号与即时通信客户端的对应关系并通过监听端口号来确定对应的IMClient的方式从而解决上述技术问题。
综上所述，在对比文件1的基础上结合本领域的惯用手段得出权利要求1请求保护的技术方案，对本领域技术人员来说是显而易见的。因此权利要求1所请求保护的技术方案不具有突出的实质性特点，不具备专利法第二十二条第三款规定的创造性。
2、权利要求2引用了权利要求1。建立主叫号码与IMCLient的对应关系或者建立主叫号码的匹配码与IMClient的对应关系，属于本领域技术人员在实施过程中基于具体需求的常规选择，属于惯用手段。因此，在其引用的权利要求不具备创造性的情况下，权利要求2也不具备创造性，不符合专利法第二十二条第三款的规定。
3、权利要求3请求保护一种控制信息处理方法，对比文件1公开了一种基于Java Push机制手机通讯应用的信息传送方法及系统，其具体公开的内容（参见说明书第2页第5行至第19行、第4页第13行至第5页第27行，图3-4）参见上述对权利要求1的评述，其中对比文件1中公开了：步骤407：IM应用启动，用户接收到提示后，选择和应用服务器建立连接，获取到最新的信息，此时，发送的信息实时的传送到了接收端（相当于本申请权利要求3中的向所述对应的IMClient传送相关信息）。
权利要求3的技术方案与对比文件1公开的内容的区别在于：建立主叫与即时通信客户端(IMClient)的对应关系，根据主叫，按照建立的主叫与IMClient的对应关系确定对应的IMClient；而对比文件1中是建立端口号与即时通信客户端的对应关系，通过监听端口号来确定对应的IMClient。基于该区别可确定，权利要求3实际要解决的技术问题是采用何种方式来确定IMClient。
上述区别与权利要求1中的区别对应一致，具体评述参见上述对权利要求1的评述。
综上所述，在对比文件1的基础上结合本领域的惯用手段得出权利要求3请求保护的技术方案，对本领域技术人员来说是显而易见的。因此权利要求3所请求保护的技术方案不具有突出的实质性特点，不具备专利法第二十二条第三款规定的创造性。
4、权利要求4引用了权利要求3。从属权利要求4的附加技术特征与权利要求2的附加技术特征对应一致，参考上述评述可知，该附加技术特征为本领域的惯用手段。因此，在其引用的权利要求不具备创造性的情况下，权利要求4也不具备创造性，不符合专利法第二十二条第三款的规定。
5、权利要求5请求保护一种IMClient控制方法，对比文件1公开了一种基于Java Push机制手机通讯应用的信息传送方法及系统，其具体公开的内容（参见说明书第2页第5行至第19行、第4页第13行至第5页第27行，图3-4）参见上述对权利要求1的评述。
权利要求5的技术方案与对比文件1公开的内容的区别在于：建立主叫与即时通信客户端(IMClient)的对应关系，根据主叫，按照建立的主叫与IMClient的对应关系确定对应的IMClient；而对比文件1中是建立端口号与即时通信客户端的对应关系，通过监听端口号来确定对应的IMClient。基于该区别可确定，权利要求5实际要解决的技术问题是采用何种方式来确定IMClient。
上述区别与权利要求1中的区别对应一致，具体评述参见上述对权利要求1的评述。
综上所述，在对比文件1的基础上结合本领域的惯用手段得出权利要求5请求保护的技术方案，对本领域技术人员来说是显而易见的。因此权利要求5所请求保护的技术方案不具有突出的实质性特点，不具备专利法第二十二条第三款规定的创造性。
6、权利要求6引用了权利要求5。从属权利要求6的附加技术特征与权利要求2的附加技术特征对应一致，参考上述评述可知，该附加技术特征为本领域的惯用手段。因此，在其引用的权利要求不具备创造性的情况下，权利要求6也不具备创造性，不符合专利法第二十二条第三款的规定。
7、权利要求7引用了权利要求5或6。通过在账户信息中设置通信号码属性来进行被叫号码的选择设置属于本领域的惯用手段。因此，在其引用的权利要求不具备创造性的情况下，权利要求7也不具备创造性，不符合专利法第二十二条第三款的规定。
（三）对复审请求人相关意见的评述
对于复审请求人于2019年06月24日提交的意见陈述书中陈述的意见，合议组不能认同，理由如下：首先，如本申请说明书中所记载的，本申请的发明构思是通过发送控制消息启动通信终端上的相应IMClient从而解决因IMClient没有启动而影响相应的即时通信的问题。对比文件1的技术方案是通过短消息中心向目标手机发送短消息来激活目标手机上未启动的即时通讯应用使得信息可即时地到达目标手机，从而解决目标手机终端未启动即时通讯应用导致不能即时接收信息的问题。可见，对比文件1与本申请的发明构思是一样的，两者的区别仅在于区分启动控制消息的信息类型不同，本申请是通过消息的主叫号码来区分，对比文件1是通过消息的目的端口号来区分，然而该区别并未使得本申请和对比文件1在安全性、业务实施难度、业务扩展性以及技术效果上有明显差别，具体阐述如下：（1）本申请和对比文件1都有一定的攻击难度，同时也都存在相应的安全风险，即模仿主叫号码和盗取端口号都存在一定难度，同时也都存在相应的风险，两者在安全性方面并无明显差异。（2）本申请是通过主叫号码来区分是否是启动IMClient的控制消息，对比文件1是通过消息的端口号来区分是否是启动即时通讯应用的消息。而两者的前提都是预先配置并维护主叫号码或者目的端口号与相应即时通信客户端的对应关系，两者在业务实施难度上也无明显差别。（3）对比文件1的技术方案是通过短消息中的端口号来区分短消息类型的，与本申请一样，并不会占用额外的协议信元，不会给短消息的业务扩展造成影响。（4）如前所述，本申请通过主叫号码来区分控制消息并未给发送控制消息启动离线即时通信客户端的方案带来意想不到的技术效果。
综上所述，复审请求人的意见合议组不予支持。
三、决定
维持国家知识产权局于2019年01月07日对本申请作出的驳回决定。
如对本复审请求审查决定不服，根据专利法第四十一条第二款的规定，复审请求人自收到本决定之日起三个月内向北京知识产权法院起诉。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
