apple并不神秘，但很无耻（说服apple采用方案的证据）
下面是我当初把方案提交给apple的证据，我明确提到我是疯狂的果粉以及siri在产品设计中的错误，向apple推荐了这个方案以后，我也明确提到我把详细的方案写进了这个中国专利。（后面也有中文版的，我保留了多份证据证明我当时的行为，但是邮件是可以直接看到收发时间的）
当时我也在给国内一家智能语音公司的邮件中也明确提到此事。请注意这个邮件的日期，这个方案现在确实已经被apple用于apple watch，carplay，ios设备以及即将发布的homepod。
中文原文：首先介绍下我自己，我是一个IOS开发者平时从事系统分析和交互设计的工作，在大学期间我读过MBA的课程主修企业战略管理以及营销管理。我是苹果产品的疯狂粉丝，但是我在使用SIRI的时候发现SIRI的产品设计以及定位存在的问题。具体来说就是，比如我说查询某样东西，现在的SIRI是直接在内置的搜索引擎中检索并把结果用WEB页面显示。我觉得SIRI的这个设计是非常不友好的也和苹果建立的APPSTORE相违背的。你们告诉用户，去开发各种APP吧，因为APP的使用体验更好。然后呢，SIRI出来以后你们却想告诉用户使用SIRI吧，SIRI能理解你说的话并会把你们想要的答案通过WEB方式返回给你。而且除了呈现方式以外，但是你们考虑过这种情形吗？比如你对SIRI说查询某个商品的价格，SIRI也许可以从EBAY上获取到相关产品的价格，但是用户可能想在AMAZON上搜索该商品。当然还有很多购物网站能够获取到该商品价格，其中也会有些网站因为比价的原因而屏蔽掉WEB搜索引擎的抓取，使得搜索引擎无法从这种网站上获取到数据，用户只能进入网站的WEB页面输入商品信息。为了解决上述问题，我写了一个方案，就是用移动设备安装的APP作为一个重要的搜索线索。每个APP安装到用户手机上以后都向注册中心提交信息以便建立起个性化的搜索数据库。注册中心包括根节点，用于完成系统的特有操作，还包括类节点，它是按功能组织成的一类APP，应用程序节点是属于某个类的APP，以及应用程序内部节点。其中每个类完成一套标准的操作并有一套公开的函数接口，并且每个属于类的APP都继承了这套公开接口，这个思想来源自WEBSERVICE。为了和语义解析过程适配，我引入带语义变量的正则表达式的概念，这个语义变量可以是某个商品名称或者是某个日期或别的，可以是枚举出来的也可以来自于机器学习。每个函数调用都对应于某个带语义变量的正则表达式，并且一些相同语义的正则表达式绑定到同一个函数调用上。这种方式使得SIRI能识别一些个性化的语义表达方式，并且有些APP如果需要让系统发现自己所特有功能的话，可以在注册中心注册函数和正则表达式的映射关系。这样所有APP的对外公开调用接口都被注册中心获知了，注册中心可以根据用户的偏好调用相应的APP去完成用户要求的功能。详细的细节我已经写成专利，在去年11月在中国已经公开，申请号是201310333827.X。这个专利只是一个简单的一个原型，我也意识到最难的是进入程序后对语音的处理，可能会存在二次遍历的需要。而且一些传统的UI控件编程方式在这个系统中也是和以往不同的。以这个为基础可以建立起移动设备上最先进和人性化的语音识别系统。最后简要叙说下我这个技术达到的效果。如果我这个东西实现了，你只要说出搜索什么的价格，如果是平时喜欢用EBAY搜索物品，那么系统会直接打开EBAY的APP， 并且显示该物品价格 。当然这个优先级 ，你可以随便设置 。你也可以说出在哪里搜索该物品的价格 ，那么就打开相应的应用并直接显示结果。当然如果进入到应用程序内部以后，语义识别的作用域会被首先限制在该应用程序的上下文中 。 但是在程序内，如果你需要跳转到别的应用程序，只要说出来，系统也能完成到目标程序的跳转 ，而且这种程序实现不需要现在一样的回调调用 ，直接由云服务器决定系统的操作。---------------------------------------------------------------------------------------------------------------------------------这个专利描述的其实只是一个完整方案的一小部分，我当时并不想一次性提交所有方案并形成专利组合。我当时的判断是即使对方用了，他们很可能不会给钱，而且我还会被骂“专利流氓”。我当时对中国的专利制度过于悲观了，但是后来方达的高国征律师对我方律师的表述却刚好符合我最初的判断。虽然，高律师和我的几次通话是非常客气的，很善意地提到“apple想获得许可，但是他们需要的是让apple觉得无法胜诉的对比文件”。此事弄得我很凌乱。