交通工具定时提醒系统和方法

文档序号:6727574阅读:330来源:国知局
专利名称:交通工具定时提醒系统和方法
技术领域
本发明涉及利用用户终端设备获取交通工具发起定时提醒的系统和方法,具开拓 性,另外地,本人请求审查员能真的考虑一下在本发明公布后是否请示下领导将本发明列 入优先审查,意义相对重大,不仅直接需求市场大,而且间接拉动相关产业也是较大。
背景技术
现行的交通工具的到站提醒系统为,以公交为例车上的广播设备播放到站的广 播,提醒车内人下车,或提醒车站候车人上车。或者没有广播,靠乘客的眼睛自己观察。这 样,乘客没有办法专心使用手机的3G业务等其它增值服务(现在手机等各种用户终端已很 普及了),因为,即使车上有广播,专心使用也很容易错过下车或上车,另外,乘客在家中也 无法得知什么时候车会到达乘客的起站点,乘客到达起站点后有时要等很长时间,不时眺 望,浪费时间,日晒雨淋,无聊,影响心情。中国移动通信集团公司已于早先申请一项专利公交车位置信息查询系统及查询 方法,专利申请号为200610165330. 1,该申请也许也具开拓性,但以下说明它跟本发明解决 的问题是完全本质不同的,本发明具有开拓性。该系统针对用户查询公交车的位置信息提供了可行的解决方法,但该系统和方法 只注意到选择公交出行的人主动发起查询公交的位置信息,要解决的技术问题是如何对公 交车的位置信息进行随时随地地实时查询,以方便人们能够随时随地地获取公交车的位置 信息从而进行行程安排,但这一需求的市场有多大呢,真正实际中想乘公交的人几乎不准 备想去打的,系统只考虑到人们的查询请求,只让人们自己做出出行的规划,这就是该系统 和方法未完全考虑到人们的实际需求,也就是没有抓住市场,没有解决核心实际需求的核 心技术问题,这是本作者认为该系统没有真正大规模商用的根本原因。真正符合市场需求 的才是有实际商业价值的,才是可以服务于广大用户的。本作者解决的市场的需求是交通 工具(含公交)定时提醒系统定于合适时发送必要的信息给交通工具(含公交)使用人, 起到一个提醒的作用。这一全新需求服务实现的开拓性价值就在于解决了较难的技术问 题,真正可以引起大规模的普及应用,在商业上获得成功,该技术涉及的系统和方法正是本 发明所要论述的。

发明内容
本发明要解决的技术问题是真正抓住并解决人们对交通工具的定时提醒需求并 实现之,开拓全新市场,激发该项产业的大规模成功商用,而人们对交通工具的定时提醒需 求具体如下段所述基于一个人们的生活事实目前手机又都普遍有了阅读小说,听音乐、视频(尤其 是3G以至4G时代的到来)的功能。现代社会人们的时间都如此宝贵,大家都希望能为自己 的精彩的生活节省下来本不该浪费的时间,以及为了避免背景技术中所说的问题,于是产 生了待解决的人们的三种交通工具(含公交)的定时提醒需求包括需求1 乘客所需乘的交通工具,在指定的时间内,在到达乘客的起乘站点之前一定时间,给乘客发起一个该出发动身的提醒,这样便可以较精确地节省乘客在站点等待的时间;或需求2 在交通工具上 专注于其它事物而不想分心去注意普通的到站提醒(如到站广播音,乘服员喊话,站牌), 为了避免坐过了站,需要到站的提醒;或需求3 在站点等待交通工具时专注于其它事物, 不想疲于顾虑每次到站的交通工具是否为自己所等的路线,需要所需交通工具到达起乘站 点的提醒;(以上三种需求分别简称为需求1,需求2,需求3,在以下的说明文字中会有出现)本发明的技术方案论述如下(说明本发明所述GPS是广义的卫星定位系统,非专指美国全球卫星定位系统,也包括我国北斗和其他国研制的定位导航卫星系统。)交通工具定时提醒系统,包括定时提醒平台,经由通信网络与该平台联结的交通工具位置采集单元和用户终端,所述交通工具指的是在起站点和终站点之间有设置途中停靠站点的交通工具,包括公交、火车(列车)、长途汽车、城市轨道交通工具、电车或船只,不包括直达的出租车,飞机;所述定时提醒平台,具有定时提醒程序软件,接收发自交通工具位置采集单元的交通工具位置信息,接收发自用户终端的针对定提醒需求的定时提醒条件信息,可为解决 用户的定时提醒需求发出提醒指令;说明,本发明定义的交通工具定时提醒平台,简称定时提醒平台,说明,所述定时 提醒平台可以是有信息通信但空间上相距较近或较远的几个子平台(可能几个子平台属 于不同的公司)组成,举例比如一个服务器专门接收和处理交通工具位置信息,用定时提 醒程序软件处理,并将处理结果发送给其它子平台的服务器。所述交通工具位置采集单元包括GPS定位单元,基站定位单元,Wi-Fi定位单元,加装无线信息发送装置的报站器,交通工具上的RFID(射频识别)标签和交通工具停靠站 点设置的RFID阅读器,交通工具与交通工具停靠站点间传输信息的蓝牙装置,或交通工具 与交通工具停靠站点间靠其它电磁波频段传输信息的装置;所述的加装无线信息发送装置的报站器(附图2),特征是当交通工具(含公交)靠近所停靠的站点时,驾驶员压下某一按钮的同时,启动了报站器中添加的无线信息发送 装置,该装置联动式地发送所播放或所靠近的站点名信息以及所属交通工具个别编号识别 信息至交通工具定时提醒平台,更新位置信息。(说明,此处的靠近二字定义为快抵达或正停靠或刚离开所停靠站点)所述的交通工具上的RFID标签和交通工具停靠站点设置的RFID阅读器,特征是当交通工具靠近停靠站点时,被读取的标签中的识别信息和阅读器所属站点信息通过网络 被发送至交通工具定时提醒平台,更新位置信息,该RFID方式所述的交通工具尤其包括公 交。(当然,也可在站点之间多设置一些阅读器,以提高位置采集的精度,或用于准确固定解 决需求2、3向用户终端发出提醒时交通工具的位置。)(说明交通工具与交通工具停靠站 点之间传送位置信息数据还可以通过其它无线电磁波频段通讯方式如蓝牙通信。)所述用户终端主要包括手机、笔记本电脑、上网本、PDA或普通电脑;本技术方案提供的总体上的交通工具定时提醒方法如下
定时提醒平台接收发自交通工具位置采集单元的按规律更新的交通工具位置信 息,并用定时提醒程序软件处理该信息,所述处理的方法包括将每一路线的交通工具的各个编号交通工具的当前位置处 理为一张当前位置基础数据表(简称基础表),该表每条数据包括交通工具的个别编号识 别信息(与交通工具上公布的个别编号相同或相对应即可)和当前位置,或者该表每条数 据包括交通工具的区分识别编号和当前位置和上下行状态;当然,处理的也可以不是表。或者在上段所述格式化处理的方法的基础上,再将基础表按一定时间间隔存储为 历史记录,以供备用。定时提醒平台接收发自交通工具位置采集单元的按规律更新的交通工具位置信 息,定时提醒程序软件处理该信息,识别出或通过计算识别出该信息所蕴含的交通工具的 个别编号识别信息、当前位置和上下行状态,定时提醒平台接收发自用户终端的针对定时提醒需求的定时提醒条件信息,定时 提醒程序软件处理该信息,得出解决该提醒需求的程序或程序子模块的绑定参数,该参数 包括提醒位置,提醒指向的用户终端以及用于确定软件所应监控的当前位置的参数,定时提醒软件确定所应监控的当前位置,并实施监控,如果所应监控的当前位置 与绑定参数中的提醒位置符合时,发出提醒信号,用户终端接收到提醒信息。以上所述按规律更新的交通工具位置信息包括交通工具位置采集单元发送更新 信息后的直接更新,或交通工具位置采集单元无发送更新信息时随着时间推移的更新;程序子模块的启动由定时提醒平台收到定时提醒条件信息后处理得出绑定参数 就启动,或者在参数中包括该子模块的启动时间,到达启动时间才启动。所述定时提醒程序软件处理定时提醒条件信息,得出解决对应提醒需求的程序子 模块的绑定参数时,定时提醒程序软件调用了根据历史记录统计计算出的所需的常备调用 数据表中的数据,或者调用了根据历史记录统计计算出所需的常备调用数据表中的数据以 及该数据所关联的概率分布统计表。发自用户终端的针对定时提醒需求的定时提醒条件信息可以用包定期的方式提 供,该方式对应的程序子模块参数中包括了启动周期,是否是最后一次启动。所述发自用户终端的针对定时提醒需求1的定时提醒条件信息包括1类提醒用户终端(该项缺失则默认为发送终端),路线(或者该项缺失),起乘 站点,到站点(或上下行的区分),提醒提前时间,起乘的时间范围或大概范围,交通工具优 选的条件(或者该项缺失),充许的出错概率信息(或者该项缺失);或者2类特别指定的提醒用户终端,路线(或者该项缺失),起乘站点,到站点 (或上下行的区分),提醒提前时间,起乘的时间范围或大概范围,交通工具优选的条件(或 者该项缺失),充许的出错概率信息(或者该项缺失);以上所述充许的出错概率信息含义上可用保证正确的概率信息替代。所述发自用户终端的针对定时提醒需求2的定时提醒条件信息包括提醒用户终 端(该项缺失则默认为发送终端),交通工具个别编号(或者定位成功的用户终端免发该 项),目的站点信息。(说明,例如可用普通电脑发送定时提醒条件信息,同时指定接受提醒的终端的手
7机号码,如果不指定,默认的提醒终端就是发送定时提醒条件信息的终端)很明显,根据现有的技术,用户终端发送定时提醒条件信息的具体方式并不重要, 只要能传递至交通工具定时提醒平台即可,现有技术中就有许多就可以通过短信、WAP浏 览器、无线internet浏览器方式、有线internet浏览器或其它终端软件。说明,其它终端 软件也易理解,比如手机和电脑上的中国流行的终端软件腾讯QQ,该软件就能与相应的服 务器进行信息双向传递。因此,与交通工具定时提醒平台进行信息双向传递也可以通过相 应的终端软件。明显的,根据现有的技术,对客户提出的信息需求服务,很多都有使用包定期的方 式,以利于商业化的运作。因此以上方法所述用户终端发送的定时提醒条件信息,可以分一 次一次地提供,提供一次,提醒一次后,定时提醒程序软件可将该定时提醒条件信息删除; 也可以包定期的方式提供,这样就会在所包定期内每天定时提醒,当有效包定期结束时定 时提醒程序软件才可将该定时提醒条件信息删除。另外,明显的是,定时提醒条件信息的删 除,根据已知的常用的计算机处理方法,它并不一定是物理性质的从硬盘上绝对删除,可以 是暂时放入回收站等性质的隔离、转移,目的就是让已超出有效期的定时提醒条件信息不 再作为定时提醒程序软件发起提醒的依据。另外,明显的,对指定的用户终端发起提醒的方式可以是多样的,如文字短信,彩 信,语音通话、浏览器或其它终端软件接收。另外,为了提醒功能的安全实现,手机对正在进行的振动或发音的消除设置可以 有(但非必须有)三种模式第一种是按一下键消除的模式,第二种是按多下键消除的较安 全模式,第三种是不能通过按键消除的安全提醒模式。另外,解决需求2的必要时,将每一路线的各交通工具用于逐一区分的个别编号 公布于交通工具上便于顾客观察的位置。(如公交的原路号之后,车内电子屏幕,车内拉 手),或者在广播时将个别编号一并报出。这样便于乘客观察并将个别编号作为定时提醒条 件信息的一部分发送(当然,该个别编号也可以是运营商主动发过来向用户确认所乘交通 工具的编号,此时用户只要勾选即可),当然,非必要的情况是定位成功的用户终端,所述 定位成功的含义是如果用户终端也有自我定位功能(如GPS定位或Wi-Fi定位的手机, 或者通过普通基站定位的手机的也能定位),且定位精度能达到识别出用户具体身处的交 通工具,并且定位信息有传入定时提醒平台并且定时提醒平台成功定位了持用该用户终端 的用户身处的交通工具。此时,就可以不用将个别编号作为定时提醒条件信息的一部分发 送。因此本发明技术方案产生的有益效果是真正抓住了人们对交通工具的定时提醒 需求并实现之,节省了人们的时间,提高了人们的生活质量,将激发该项产业的大规模成功 商用,拉动软件和位置设备产业,同时也便于人们利用更多的时间专注于使用手机等工具 的增值业务,拉动相关服务产业,为3G产业的更好实施,为祖国应对全球金融危机,拉动内 需保持增长的经济战略贡献一份力量,另外,实施本发明后,大众更加认可和愉快地接受大 众交通工具,节能环保,对地球人类和生物也是有贡献的。


图1为交通工具定时提醒系统组成示意图,取公交为例。
图2为加装无线信息发送装置(标号20)的报站器电路组成示意。(明显的,发送方式可以多样,如GPRS,wifi)图3为定时提醒程序软件处理的更新中的各2路车辆的当前位置基础数据表(以当前时刻07:40:00为例),该数据随着位置采集单元的工作或时间的推移而更新。以下为 了便于表述我可以用“基础表”简称这一类的表。图4实施例中一年中1月15日的一张常备调用数据表图5实施例中解决需求1时定时提醒程序子模块示意6实施例中解决需求2、3时确定提醒位置的常备调用数据表。图7实施例中解决需求2时定时提醒程序子模块示意图。图8实施例中解决需求3时定时提醒程序子模块示意图。图9定时提醒程序软件的主要流程图。图10、11、12、13为实施例中定时提醒程序子模块示意图。
具体实施例方式上文所述的需求1,需求2,需求3这三种需求的具体实施方案主体思想相同,细节上有所不同,以下实施方式以一个当交通工具为公交时的实例进行针对性论述。当交通工 具为其它时,可以明显等同地进行扩展理解本技术方案。解决需求1本地有一条公交2路车,其上行沿途站点为城市广场一南海购书中心一花苑广场一文化书局一南师附小一华阳桥北一里水信和广场一邮政局一桂江桥一奇槎路口一甘 蕉一联滘立交北一五星路口一岗头村一得胜村一里和路一宏岗市场一邓岗一滘心村口一 银印一新道口一电信局一儿童医院一蒙自路一丽雅苑。其下行沿原站点返回。将2路的各 部公交车都再进行编号(如2路公交车再编为2-1,2-2,2-3,……2-10,……等等),并 将所编号公布于车上显示的原路号之后,便于人们观察,车载位置采集单元在GPS位置采 集单元或者加装无线信息发送装置的报站器(如图2) 二者中任意选其一,无论选哪种位置 采集单元发送给公交定时提醒平台的位置信息都包含所属车辆的完整编号的识别信息。但 可以区分的是加装无线信息发送装置的报站器只是在到站时发送一次位置信息,公交在 站点之间的位置采集靠时间延长的推算,提醒时间精度上弱一些,但也能满足实际的需求; 而GPS位置采集单元可以依据用户要求的时间精度设置采集频率,在相邻站点之间可增加 确定多个位置采集点,提醒时间精度上强一些,但网络运行成本又高一些,且目前依赖于美 国GPS系统卫星服务的稳定。总体上看,二种位置采集单元均可满足实际的需求。现有一人刘某家住车站“岗头村”附近,手机号为*********12,刘某从家步行至 “岗头村”所需时间为5分钟,公司在车站“新道口”附近,刘某在工作日需要在8:00点前乘 上2路车,不出交通故障等意外,8:30前就可达“新道口”车站,及时到公司上班。此时刘某为了不在车站等车过长的时间,较准确地从家中出发,可根据2路车的大致发车频率,在接近7:40通过手机*********12的无线上网浏览器(如wap浏览器)/ 或终端软件登录公交定时提醒网(本发明定时提醒平台的定义可以不包括该网(如果该网只是传输数据给定时提醒平台,它就不同于具有定时提醒平台所应具有的功能的所谓的分支服务器)或者也可以包括该网。)另外明显的无线上网方式可以多样,如现在的3G上网,wifi上网),按所提供的以下7个项目输入并发送以下具体的定时提醒条件信息(可以以下拉框选择形式)1、路线g路2、起站点岗头蚓3、到站点4、起乘时间区间|07; 45丨至|08: 00|5、区间内有车优选g车6、区间内无车优选g车7、提醒提前时间至少g分钟说明以上定时提醒条件信息的第4、起乘时间区间|07; 45丨至|08: 00|,5、区间内有车优选g车6、区间内无车优选g车(该信息通过通信网络传输至公交定时提醒平台)三项中,如果第4项给出的起乘时间区间范围不宽(范围宽的话其实对系统运行 起来要更容易很多,从以下的论述中我们自然可以看出,明显可视为本发明的等同替换,而 且更低级,这里我就不多说了,),这就会类似另一种格式即只有第4项4 起乘时间不到且接近于|08 00|(另外说明,如果在起乘站点和到站点之间,路线不只2路车,第1项可缺失,此 时第5、6项还可以包括优先有空调或无空调,优选环保车,优选票价低等等其它信息,同样 的,用程序处理并不难,需要在交通工具个别编号对应上该交通工具的属性即可)另外,该信息发送方式也可以是利用家中的普通电脑用Internet Explorer通过 ADSL等方式,也可通过无线网卡无线上网,同样也可运行某公交定时提醒网公司开发的客 户端软件,也可以通过语音通话的方式提供。运行后同样的输入以上的定时提醒条件信息, 另外该条件信息还可再加第8项指定提醒终端。如果不填就默认为本普通电脑(可通过 IP地址等识别),也可以填写,例如指定一个手机号*********12。或者再附加其它项。另外,第1项、路线0路,也可以把格式改成在多条线路中任选其一;或者不指 定,由系统自动计算出起站点和终站点之间的线路。(以下解决需求3时有讲到一个例子, 看到时自然会理解)这里先提出一个概念系统固有误差,在本实施例中该系统误差取值30秒(把 本说明书总体看完可以得出误差的考虑主要是以往的统计数据不足,比如只运行了一个 月的系统,为了保证需求1的提醒的及时而设置的,另外就是数据在处理,网络传输和显示 等环节上的耗时,另外还有一个是不同的司机按下报站器按钮的时机上有所不同,有些早 些有些迟些,不过这个误差也在数秒之内,还有一个就是司机的发车时间上有一点人为因 素的误差,使用本定时提醒系统的公交公司应该对发车时间间隔进行较严格的控制,最好 用秒表和闹铃等手段控制,对准时发车的司机以及运行中速度规律的司机最好给奖励来降低误差,还有一种是公交公司来了新司机,虽然经过实习但还是与老员工有些差别等等,当 然,在实际中该误差可能更小些。)一个概念基础表(如图3)其中数据随着位置采集单元的工作或时间的推移(一 般以1秒为单元)而更新,其更新受定时提醒软件的格式化处理,如图3,一般是表的形式, (当然也可以是不是表,如像记事本那样逐行存储),每条数据包括交通工具的个别编号识 别信息、当前位置和上下行状态,定时提醒程序软件按规律将其存为历史记录,可以将一天 中每一秒( 或者其它时间间隔)都存储。如果以1秒为间隔,2路车每天运营17小时,则存 储的基础表约有60 * 60 * 17张。如果10秒存一次,则数量缩小10倍,(可以把10秒列 入影响系统固有误差的计算),这些表可以在完成了常备调用数据(关于常备调用数据的 概念后面会讲到)修正后删除,也可以作为公司的历史数据长期性保存,以备不时之需。—个概念定时提醒程序子模块,对于每一项用户的定时提醒需求都有一个程序 子模块处理,当提醒发出后,卸载该子模块,或者保险起见在提醒信号发出后,并且得到用 户终端收到的反馈后,卸载该子模块,否则再次发出提醒指令。另外,可能如果系统同时收 到的提醒需求不多或定时提醒程序软件的主程序的运行速度足够快,也可以把本发明所述 程序子模块取消,直接由主程序处理,此时主程序处理的内容与子模块是相同的,或者主程 序替代处理子模块的一部分程序,本发明认定或定义该方式也可把主程序代替子模块运 行的部分也称为程序子模块,把主程序运行时用的参数也定义为就是对应子模块的参数。 总体上的定义是本发明所述定时提醒程序软件的程序或程序子模块,它们都是定时提醒 程序软件,二个概念在本发明中定义为含义相同或等同替换。—个概念定时提醒程序子模块的绑定参数,该参数有些已存在于定时提醒条件 信息中,有些根据定时提醒程序软件计算得出,程序或程序子模块使用参数运行。该信息通过传输至公交定时提醒平台,已得到和需定时提醒程序软件对数据进行 处理计算出的程序子模块的绑定参数包括〈用户*********12/路线2路/上下行状态 gig/提醒位置gfg/启动时间ggg/其它优选参数……>,该参数如果全得出后, 以统一的格式存储。参数的计算可以由主程序或子模块计算。一 计算所要乘的车辆的上下行状态(根据“2、起站点g_3、到站点 ”这二项得出是上行状态的车辆符合条件,下文中有涉及到计算方法这里就不多说了)二 计算提醒位置下面详细说明,关于计算提醒位置(以下计算的目的是为了保证发起提醒的位 置在100%或近于100%的概率下可以保证用户给出的第7项的约定,这样才会避免乘客在 到达车站时车已过去,这样能保证在解决需求1时乘客上班、上课等等不迟到,这一点是很 重要的,不同于需求2和需求3的提醒位置很容易解决只要大概的位置均可,需求1的提 醒位置非常的严格)调出以往存储的2路车在所述的2、4、72、起站点丨岗头种4、起乘时间区间|07 45丨至|08: 00|7、提醒提前时间至少g分钟三项定时提醒条件限定的历史记录例如调出了 365天的365条记录,计算方法为将各记录到达岗头村的时间点减去5分钟30秒(其中30秒是系统误差,后得到各个时间点,比较由这些各个时间点对应的各车次的位置(如果对各位进行统计学分析,可以得出各位置点的概率分布统计表,后文中也有提及其详细情况,该概率分布统计表不是必需但也可能是有用的),从中选出一个离岗头村最远的位置,(比较的方法如果采用报站器方式则可能用到某站点名+最小时间延迟,如果采用GPS可能用方法坐标与岗头村站点坐标之间的距离最大者,还可能要用到其它的计算方法,下文中有涉及),以此作为提醒的位置。该定时提醒位置可以在每天的系统运行中用新产生的数据加入对应的概率分布统计表用以修正,修正的数据作为系统的常备调用数据资料,从而可以不像以上提到的需要时一次性地调用365条(当然,可能要扣除节假日等日子,这里只是举例就不详述了)数据进行计算。该修正的过程可以是实时的,也可以是当天公交运营时间结束后,系统腾出资源进行对当天的记录数据处理,用以修正各种常备调用数据资料(不仅指提醒位置数据,说明书较后面还有提到其它的数据例子),修正结束后可以把海量的当天数据删除,以空出更多的存储空间为下一天的记录作准备。至于计算提醒位置的常备数据存储格式举一例如下以表格形式存储,2路车的归在一起,每一张表格存储的内容由以下四个要素决定上下行状态,起乘站点,起乘时间点所在时间段(把每天运营时间以30分钟(当然可以更小或更大)等分出的时间段),提前提醒的时间(如依据客户的需求分出1分钟到10分钟等十类)。比如在确定了上行,起乘站点为岗头村,给出一张表,横栏为提前提醒的时间,纵栏为等分的时间段,如图4所示为一年中1月15日的一张常备数据表。该表的每一项值关联一个概率分布统计表(也是存储备用),用于新加入数据对该项值的修订,同时也可用于下文马上说到的乘客特别提出的充许适当加大出错概率的取值服务。(说明,可以把各普通上班日的各数据不分开而合并统计,可以把各周六的合并,各周日的合并,各节假日的合并,说明,所述常备调用数据表或常备调用数据表中的数据所关联的概率分布统计表中的数据的计算可以是利用位置信息历史记录严格统计计算得出或者根据经验模糊计算或模糊直接确定得出;所述常备调用数据表或常备调用数据表中的数据所关联的概率分布统计表中的数据的计算方法包括将记录所属的日子的类型归类分开计算;所述将记录所属的日子的类型归类分开计算,所述类型包括工作日,节日,假日,上课日,学生假期日,高考日,非年周期特殊日或不同类型的重叠日;所述非年周期特殊日包括奥运举办日,火炬传递日,世博会日,或足球世界杯曰;等等,可能还要考虑不同的城市民俗习惯特殊处理,应该在实践中摸索改进)可见,系统可以根据定时提醒条件信息直接搜寻到并调用所需要的表格常备数据。从个别用户的体验感觉或从实际为该用户服务的记录得出如果该提醒位置让用户一般都要在站台等上2分钟等较长时间(虽然只等2分钟其实是不错的了),则可根据用户的要求将提醒位置延迟一些,但需与用户订立协议这样做的结果会导致不能100%或相当于100%保证不误过车次,误过某个车次的概率加大,用户本人已知晓并已同意实施。用户可在发送的定时提醒条件信息中包括充许的出错概率(或者是保证正确的概率,二者是等同的),如果在后续协议中订立的概率,在本发明中将该概率定义为定时提醒条件信 息的一部分。当然,在本发明开始实施的初期,以往数据不多,也没有同年同月同日的数据,可 以以最近若干天的实验数据为依据,加上大于30秒的系统误差来为用户提供试商用的服 务。其实主要的公交群体是工薪上班族和学生,每天上班上课的时间车流量其实是差不多 的,实际这样的若干天的模糊经验数据也可以达到一定的效果的。另外,刘某可以包定期的方式提供,如包月,包季,包年,这样就会在所设定的上班 日定时提醒,而不必每日发送以上相同的定时提醒条件信息,当包定期结束时定时提醒程 序软件才将该定时提醒条件信息删除。可以预见的是,刘某相当愿意以包定期的方式来使 用这一新的系统带给他的便利,该系统蕴含的巨大的商业价值在此就可见一斑了。这才应 该是解决问题之道,不应该像背景技术中所说的技术刘某去查询公交的位置,然后考虑是 否选择其它的交通工具。因此,此处就以刘某以包定期的方式,给出定时提醒的详细说明,(包定期与临时 性一次提醒所用的方法可以是相同的)(以下再重复一下刘某发送的定时提醒条件信息)1、路线g路2、起站点丨岗头衬3、到站点4、起乘时间不到且接近于00 ]5、提醒提前时间至少g分钟参照上文及图中提到的方法定时提醒程序软件的处理计算出提醒位置为联滘 立交北+10秒。由于是包定期,显然,晚上,凌晨公交还没出首班车,系统是可以处于休息维护状 态的。这里头很自然会涉及定时提醒程序软件何时启动针对刘某终端*********12的定时 提醒程序子模块(确定启动提醒程序子模块的时间)分析如下,根据第4、5项,和系统误差,得出 至少要在07:54分30秒前启动,但此时启动只在以下情况才有用刚好一部2路正好到达 提醒位置的情况才有用。绝大多数概率下会出现以下坏情况一 最坏的坏情况这时刚好有一部2路车通过了提醒位置,这样就会导致很坏的 后果,因为2路车的发车间隔约为10分钟,因此后来的另一部2路车约08:10才到起站点 gH,这样系统的服务就失败了,顾客很生气,后果很严重。二 最好的坏情况这时刚好一部2路车是要再过1秒才到提醒位置,这么说这部 车就会不能在预订的概率下完成08:00到达起站点gll,而是08:01秒。虽然这种情况 一般的情况下下用户仍能达到08:00之前上车,但这背离了为达到我们的服务而进行的程 序设计的初衷,不能保证08 00前让用户上车,也是不行的。基于以上,为了避免坏情况(以上二种坏情况,及介于这二种坏情况之间的坏情 况),所以,系统应该在提前5分30秒的基础上再加上10分钟(公交发车间隔),再加上车 辆运行的误差(即前后二辆车拉开的时间间隔可能超过10分钟的部分,(如果地铁等其它交通工具的间隔运行时间非常严格,就不用计算而简单很多了),间隔运该误差的计算方法 为依据存储的历史记录(比如记录选择的是过去一年当中每天的该提醒时间附近、该提 醒位置附近前后上行状态二辆2路公交的运行时间差与公交发车间隔的10分钟的差值, 该差值共有365个记录(此时是举例,就不把工作日和休息日分开算,实际中一般是要分开 算的),对这些记录进行统计学概率分布的分析,得到概率分布统计表,(该分析一般的软 件都能完成,(也就是这是现有技术),)该概率分布统计表例如该表格式为在误差为-30 秒到+30秒内的出现292次概率为80%,在-60秒到+60秒出现的361次概率为99%, 在-120秒和+120秒内出现4次概率为1 %,以外出现的概率为0.(参照上文中所述提醒位 置的常备调用数据,该类车辆运行的误差作为系统的常备调用数据一样要分小类存储(如 在一个表中存储,把一天的运营时段每隔30分作为纵向栏目,把位置(标准是以走在前的 那部车)每隔一个车站作为横向栏目进行存储,该表也分上行和下行),实际中是不断修正 的,比如每天都进行一次修正,要使用时直接判断由条件车路线、上下行、该提醒时间附近、 该提醒位置所限定的数据误差值,调用就可以了,如果选择每次用到时临时计算,虽然不是 不可以,但这样系统的负担会加大很多。)因此,为了保证无交通故障的情况下,100%地满 足乘客08:00前能在起站点上车,可以选用的误差为120秒。于是综合以上得出启动针对 刘某的定时提醒程序子模块的时间为08:00-(5分30秒+10分+120秒)= 07 42分30秒。另外补充说明,上文中也提到过,实际中没有100%的保证,保证较小概率出 错也是可以的,比如此时若选择出现概率为99%的60秒的误差值,此时不能保证,在这 的情况下,出现以上所述坏情况的概率计算为1/12,即根据数学里的条件概率可得出约 1/1200这一总的出错概率。因此也是可以基本上满足刘某的需求的。在1实际中也可与刘 某订立协议作出规定。(另外,补充说明,虽然系统的准备工作量较大,但常备调用数据实现了100%的 保证或近于100%的保证不出错,是一种清晰可控科学严密的交通工具定时提醒系统,但如 果不采用常备调用数据,或不采用以上严格的统计计算常备调用数据的方法,系统本身就 以一种模糊状态对外服务,本身不能保证100 %,但保证一个较低概率出错也是可以在实际 中出现的第一种对于以上启动针对刘某的定时提醒程序子模块的时间计算 用表达式表示为08:00-(5分30秒+10分+1分)=07:43分30秒,这时就把二车拉开的 距离人为地以经验规定为1分钟,此时并不知道出错概率,而是由实际运行中客户的投诉 反应来人为地更改,也是一种经营的方法,但这不好。第二种就以系统前一日的保存历史数据记录计算,或者以该路线车辆走在前的 二部的车辆拉开间距计算,或者临时仅以一条往年的同月同日历史数据记录计算,这样也 是模糊的服务提供,在实际中可以出现,但是不好的。)所以,一种可行方案是刘某假如包年要求这项服务,则在服务年中的每天早上 07:42分30秒时,启动针对刘某*********12的定时提醒程序子模块,该子模块被绑定的 参数为〈用户*******#12,路线/2路,上下行状态上行/提醒位置联滘立交北+10 秒/启动时间07:42:30/其它优选参数…… >),系统此时启动子模块如图5所示,子模块 调用相关绑定参数并进行计算,计算确定出该子模块所应监控的当前位置(如图5中标号 21,说明,程序或程序子模块对所应监控的当前位置进行监控,可以是直接监控基础表的位置数据,也可以重建数据项,该数据项内容的更新受程序控制如具体为由图3所示的更新中的各2路车辆的当前位置基础数据表中相应位置为2-4的数据的当前位置的更新引发的 同步关联更新),具体方法举例为对各站点名按上行状态赋值为1,2,3,……,将提醒位置 站点名赋值减去2路车基础表中各上行车的当前位置站点名赋值,取结果为正数并且最小 的,如果最小正数不唯一(这种情况很少,它表示的意思是二辆上行2路车走到同样的二个 站点间),再用延迟时间相减,从而可得到2-4,如果是GPS方式也可以用对整条线路上各位 置坐标按上行顺序进行从小到大对应赋值的方法相应地计算,或,当整个上行线路的各采 样点坐标具有单一性远离上行首发站的性质时,也可采用提醒位置与首发站的距离减去当前位置与首发站的距离,取差值最小正数来计算,各种方法能得出结果即可)(说明图3、5等图中当前位置中的站点延迟时间可以写在增加的第4列中,便于计算机处理。)因此,该子模块直接或间接实现了监控基础表中相应当前位置,具体为当前位置每更新一次(或者也可以在保证误差的情况下采用更新多次的方法,或者规定间隔多少时 长的方法)就与提醒位置比较一次,更新的当前位置符合提醒位置时(或者当采用GPS位 置采集方式时,由于设定的采集精度的原因,与该提醒位置的比较可能要经过计算,如提醒位置本身就是一个位置范围的条件,又如需要当前位置坐标与提醒位置坐标经运算得 出的距离差值落入某一个值内即可发起提醒,同样的在充许的误差情况下,用报站器方式 时也可以是表示当前位置与提醒位置的时间差值落入某个范围),可对*********12发起提醒,并卸载该子模块,等第二天再启动。(当然,刘某只是包年工作日启动的话,第二天是周日就不启动了,所以子模块设定的参数中还包括了提醒周期,以及是否是最后一次提醒(临时性提醒该参数设为是),最 后一次提醒后就可以把绑定参数彻底删除)(说明,图3中所示基础数据表按个别编号顺序 从小到大排序,但并非必须这样排,但按顺序排对于程序确定基础表中关联的位置时更容易,因为不需要再去搜索所需车编号而找到所应监控的当前位置)以上所述方法可以保证 08:00前实现用户上车,也可以在一定的概率下保证第5项定时提醒条件信息,但改进后的方法能更好地保证上述第5项定时提醒条件信息5、区间内有车优选车所决定的参数。因为此时跟在2-4之后的那部车如2-5可能并不是与2-4拉开了距离而是缩短了距离,并且2-5能保证在08:00前到达起乘站点,如果此时启动提醒不如让2-5到达提醒位 置进行提醒效果更好。所以程序此时可在2-4所在一行数据中当前位置更新符合提醒位置 时,做一个选择分支,判断在后车2-5的当前位置与起乘站点之间的经验运行时间,用于判断是否要重新确定程序所应监控的当前位置(该时间也同样是从存储的相应常备调用数 据表中提取,因此,如果要实现这一程序选择分支,要多设立常备调用数据表,此时的数据 表会较多,对系统的要求又更高了,根据商家自己的能力决定提不提供这一更优化些的服务)用该经验运行时间加上2-5的当前时间,算出2-5到达岗头村的经验时刻与08:00比 较,如果大于08:00,则提醒;如果小于08:00,则放弃提醒,程序子模块重新初始化为动态 关联基础表中的后一部车2-5车,等到2-5车到达提醒位置即可发起提醒,此时才卸载程序子模块,所以确定程序所应监控的当前位置可以不只一次。另外,上述程序是在07:42分30 秒启动子模块的,此时程序最多只需要放过一次的提醒,(即2-4这部车一次)下一部车肯 定能发起提醒,即确定程序所应监控的当前位置最多只要2次,但如果程序更早启动定时提醒程序子模块,(如非包定期一次性的提醒,在用户终端发送定时提醒条件信息时就启动子模块),则子模块运行的时间加长了,而且放过提醒的次数可能会多次,模块要多次通 过运算重新确定所应监控的当前位置,系统耗费的资源也更大。这样属于更低级的等同替 换,此时子模块的绑定参数不包括启动时间),所以非包定期一次性的提醒也可以采用同于 包定期的方式,在07:42分30秒时启动子模块。因为07:42分30是科学计算得出的,可让 程序的运算量最小。当然,实行中也可以采用比07:42分30更提早的模糊计算得出启动时 间。另外,针对定时刘某发送的定时提醒条件信息(以下再重述一遍)1、路线(2)略2、起站点丨岗头衬3、到站点新道口4、起乘时间区间7: 45丨至08005、区间内有车优选后车6、区间内无车优选前车7、提醒提前时间至少5分钟本发明还有提供一种程序子模块,如图10所示。(图10为报站器等方式,图11为 对应的GPS等方式)程序同样要依据定时提醒条件信息计算出子模块的参数,根据1、2、3、7项得出或 计算出参数*********12、2路、提醒位置、上行。复制2路对应的基础表,程序控制该复制 基础表与原基础表保持由车编号关联的当前位置数据的同步更新,将复制基础表中各上行 状态车辆的顺序按符合定时提醒条件信息4、5、6的程度顺序,即对岗头村经验时刻一列的 数据进行排序,至于计算(包括至岗头村所需时间(要调用常备调要数据表)和至岗头村 经验时刻(至岗头村经验时刻为所需时间加上当前时刻)的计算,)上文中提供的方法都 已提及,这里不重复,于是得出了排序基础表,如图10所示(23),为定时提醒程序软件根据定时提醒条件选出的最优车辆信息的位置,放在 第一数据优选行(24),由于定时提醒条件信息中的第5项区间内有车优选后车,所以排在(23)之 下。(25),由于不满足定时提醒条件信息中的第4项起乘时间区间=|07 45丨至 排在(24)下。(26),由于当前位置已过岗头村,不满足定时提醒条件信息中的第2项起站点岗头村,所以有略。该子模块按一定时间间隔(不一定是1秒间隔,因为要在充许的误差内减少运算 量)对该复制基础表进行排序,仅当第一数据优选行(27)的当前位置(该当前位置是程序 所应监控的当前位置)符合提醒位置时,才发出指醒指令,如图12所示。(图12为报站器 方式,图13为对应的GPS方式,其中位置的更新也包含了随着时间推移的更新,但这可以是 非必要的)
另外,显然,以上所述子模块的启动时间也最好是在07:42:30,此时所需复制的基 础表中的内容只需要2条数据,否则太早启动还会导致第一数据优选行为空,且浪费资源。 该模块的优选条件还可以附加定时提醒条件信息中提出的其它优选条件。另外,万一,如果2-4在到达起站点之前抛锚或堵车了,(此时GPS位置采集方式 能较报站器方式更快地判定,依据是一定时间内2-4的位置更新为同一数据),则此时定时 提醒程序软件可对用户发出提醒,以便让用户决定乘用其它的交通工具,避免迟到。另外可以从以上实施例得出,程序再次确定所应监控的当前位置的时机可以是在 所应监控的当前位置与绑定参数中的提醒位置符合时,或在所应监控的当前位置与绑定参 数中的提醒位置符合之前。(另外,具体实际商用中基于服务效果和用户体验的考虑,取用常备调用数据 时,考虑取低概率下出错的数据,给用户一个协议交通未故障的情况下,系统出错,超过 08:00 一分钟赔偿20元,哈,这样并不是开玩笑,是很可行的,因为出错的概率低,赔偿金小 于因此而获得的更多用户的使用费,用户心理上可以接受赔偿,那么在商业上很就可行了。 这也是本发明者解决的重要问题之一,为商家考虑周全,本发明的优点最大就是适于大规 模商用,总之,本发明的市场前景真的很广大,本人请求审查员能考虑一下是否请示下领导 将 本发明列入优先审查,不仅直接需求市场大,而且间接拉动相关产业也是较大)另外,明显的,系统给用户选择的起乘时间不能超出末班车最迟到达该站的时间 (同样可以用统计的常备调用数据得出)。此时产生的一种有益效果是通过以上实例可看出,这使得刘某每天上班都几乎 不必在车站等公交车,不必受寒风和烈日的苦,也极好地节约了时间,真的很好。说明定时提醒程序软件对信息的具体计算处理方法并不限于上述的具体实施 例,比如表面上确实有些不同而实质上的等同替换,如;直接用经纬度坐标表示交通工具 位置,提醒位置可以是某个坐标或经纬度坐标范围(坐标加时间延迟数)等等,本人认为本 发明的效果创造性也许比不上灯泡,但它确实开拓了新的民用需求的技术实现(以前没有 听说公交还能定时提醒的),也应归入开拓性的发明,而审查指南中说开拓性的发明应当是 可以有更宽的概括范围的。解决需求2:当刘某7:54 “岗头村”车站乘上2-4公交车后,在一个座位一屁股坐了下来,此时 家中的电脑不在身边,正是进行使用手机增值业务的大好时机(尤其是3G手机),可是当心 看电影,看小说太专心而没有听到车内的报站音导致坐过了下车的站点,可能此时刘某就 决定不使用手机增值业务,而转为看看窗外的风景和注意是否到站了。而交通工具的定时提醒系统和方法来解决上述问题的具体实施方式
就是刘某坐 定之后,马上拿出手机,以指定的格式编缉短信“2-4,新道口”发送至无线网络运营商指定 的服务号码比如9974,之后就可以专心看手机电影、小说之类的了。“2-4,新道口,,这条信息就是定时提醒条件信息,当然还包括默认的手机号,它经 由无线网络到达公交定时提醒平台,并经由存储模块存储,由定时提醒程序软件监控处理,处理起需求2要比需求1简单很多首先也还是确定子模块的绑定参数<*********12/2-4/提醒位置丨待计>此时定时提醒程序软件根据“2-4”,查找如图3所示的基础表,知道是上行状态,从系统对应常备调用数据表中找到2路,上行,新道口限定的提醒位置即可。该常备调用数 据表是为解决需求2而事先设立存储的。如图6.该数据表不需要针用以往数据进行概率统计和修正,定下来就可以了,简单很多 (如果是GPS方式该表的数据可以做得更精确,如控制在一个用户体验最好的位置提醒), 比如定在二个站的中间位置,除非2路车的路线有变才要人员维护更新。(另外,如果不用该常备调用数据,系统规定了一个计算方法,统一以站点名加上某一个固定的延迟时间如 40秒的规则进行临时计算,也是可以的;或者用GPS方式时,规定的计算法为距站点位置往 前推100米(或距离为若干个采样精度距离之各)求出的坐标值,也是可以的,但系统比用 常备调用数据的系统更烦,而且也不能控制在一个用户体验最好的位置提醒)另外,该程 序或程序子模块也可包括的启动时间参数,也可由计算得出,计算标准是考量是否减少了 软件的运算量,比如在接近提醒位置时。此时软件启动针对刘某*********12的定时提醒程序子模块,如图7,程序所监控 的当前位置为标号(22)该子模块也同样建立了与基础表中相应数据的动态关联更新。随着2-4公交车的运行,其车载的位置信息采集单元采集位置信息并发送更新公交定时提醒平台中的位置信息以及随着时间推移更新,当当前位置符合提醒位置时,定时 提醒程序软件的建立的该子模块立即启动无线网络对刘某的手机发起提醒,几种提醒方式 中举短信方式为例如下提醒短信为“马上到新道口车站,请您作好下车准备。”之后软件卸 载该子模块。(说明,如果刘某不发送2-4的个别编号,系统要对刘某的手机定位,识别出刘某所乘的交通工具。)很明显的是,此种需求的解决方案很容易扩展应用于城市轨道交通工具,火车,长途汽车,电车,船只等其它交通工具。解决需求3:刘某准时到公司上班后,老板临时叫其出外去文化书局办事,刘某于是又来到新 道口车站,此时可乘2路车的下行线至“文化书局”车站,并且乘5路公交车下行线也可以到 达。刘某在“新道口”车站站台站立后,不想疲于张望每次到站公交是否为自己所等的路线, 并且想看手机电影等,于是可以通过手机wap浏览器登录公交定时提醒网填入以下定时提 醒条件信息并发送等待站台新道口目的站点文化书局(当然,用户只想乘2路车不想乘5路也可以附加发送2路车信息,另外运营商还可附加提供选择有空调无空调车等等,另外默认的优选是车辆车站间隔最少,这一点很明 显的用以上涉及的赋值计算很容易,就不多说了)该信息通过无线网络发送至公交定时提醒平台,同样地计算子模块的绑定参数根据新道口至文化书局确定出2路是下行,5路也是下行(当然可能是上行),然后确定二 辆车提醒位置方式类似于需求2,也可以是调用常备调用数据(同于需求2,该数据需求 2、3的程序子模块是共享的),然后在二张基础表的下行类中依据基础表的当前位置查找 最接近新道口的二辆车为2-8和5-10,(如果有优选参数也可以为二辆车排序)于是运行 程序子模块如图8
说明,此时的子模块同时监控了二个当前位置的数据,也可以是多个。同样地,过了一会儿,2-8的当前位置先符合了提醒位置,满足了向手机用户发起 提醒的条件2-8已接近“新道口”车站,立即启动无线网络对对应的刘某手机发起提醒,再 卸载该子模块。
所提醒过程和内容举选择浏览器方式时具体如下浏览器界面切换到电影界面之前前置性显示以下文字(同时引起手机振动或响 铃)(也可以电话语音提醒,图片提醒)2-8公交车马上到达“新道口”,请准备上车,您还有17站约40分钟到达目的站点 “文化书局”,谢谢您对公交定时提醒网和公交公司的支持!另外,本需求中可在用户上车后,车辆启动后发送提示信息给用户,供用户选择钩 选上到哪一辆了 2-8或5-10,来决定是否要提供需求2的服务。此时子模块只关联基础表 中相应的一个交通工具当前位置的数据。此时的有益效果是刘某节省了时间专注于手机电影,不必疲于张望,于是解决了 需求3。并且刘某都不用去详细看到底有几种路线公车可以到达“文化书局”,因为系统自 动给出了 2-8的车辆提示。说明,需求2、3的程序子模块也可参照解决需求1的子模块先把绑定参数存储,等 到一个合适的时间再启动,这属于等同替换。说明,以上各例所述定时提醒程序软件完成的功能,可能在实际中是由几个独立 的分支软件完成的,这几个独立的软件每个分别都称作定时提醒程序软件,但实施本发明 时,必要的技术特征并不要求包括全部的定时提醒程序软件,如用于统计计算常备调用数 据表的定时提醒程序软件就是非必要的。基础表中的上下行状态可依据交通工具到达整个路线的终点站时发送更新信息 后,进行切换,也可以根据交通工具行进中到达的先后二个位置采样点进行判断。另外,从本文提供技术总体上可以看出,如果基础表中没有上下行状态信息,计算 会麻烦,即用临时通过先前存储作为历史记录的一张基础表中某编号车的当前位置与当前 实时基础表中的当前位置进行比对的方法,这样的方法当然还属于定时提醒程序软件处理 位置信息后所识别出的上下行状态信息,这个属于更低级的等同替换。另外,像地铁这样的交通工具,如果本身每天到站离站的时刻都保持非常的严格, 站与站之间的运行时间也非常严格,则针对解决需求1的定时提醒软件的计算要简单很 多,从本发明提供的方法不需创造性思维可推出,自然属于低级的等同替换。最后说明,以上说明书中具体实施技术的论述不仅仅在具体实施方式
这部分内容 中,这些具体实施技术的技术方案并非限制,相关技术人员应当理解,可以对本发明的技术 方案进行修改或者等同替换,而不脱离本发明的精神和范围。
权利要求
交通工具定时提醒系统,包括定时提醒平台,经由通信网络与该平台联结的交通工具位置采集单元和用户终端,所述交通工具指的是在起站点和终站点之间有设置途中停靠站点的交通工具,包括公交、火车(列车)、长途汽车、城市轨道交通工具、电车、或船只,不包括直达的出租车、飞机;所述定时提醒平台,具有定时提醒程序软件,可接收处理发自交通工具位置采集单元的交通工具位置信息,可接收处理发自用户终端的针对定提醒需求的定时提醒条件信息,可为解决用户的定时提醒需求发出提醒信号;所述交通工具位置采集单元包括GPS定位单元,基站定位单元,Wi-Fi定位单元,加装无线信息发送装置的报站器,交通工具上的RFID标签和交通工具停靠站点设置的RFID阅读器,交通工具与交通工具停靠站点间传输信息的蓝牙装置,或交通工具与交通工具停靠站点间靠其它电磁波频段传输信息的装置;所述加装无线信息发送装置的报站器,特征为当交通工具靠近所停靠的站点时,驾驶员压下某一按钮的同时,启动了报站器中添加的无线信息发送装置,该装置联动式地发送所播放或所靠近的站点名信息以及所属交通工具个别编号识别信息至定时提醒平台,更新位置信息(说明,此处的靠近二字定义为快抵达或正停靠或刚离开所停靠站点);所述交通工具上的RFID标签和交通工具停靠站点设置的RFID阅读器,特征为在交通工具上设置RFID标签,在交通工具停靠站点设置RFID阅读器,当交通工具靠近停靠站点时,被读取的标签中的识别信息和阅读器所属站点信息通过网络被发送至定时提醒平台,更新位置信息;所述用户终端主要包括手机、电脑手机、笔记本电脑、上网本、PDA或普通电脑;所述定时提醒需求,包括需求1乘客所需乘的交通工具,在指定的时间内,在到达乘客的起乘站点之前一定时间,给乘客发起一个该出发动身的提醒,这样便可以较精确地节省乘客在站点等待的时间;或需求2在交通工具上专注于其它事物而不想分心去注意普通的到站提醒,为了避免坐过了站,需要到站的提醒;或需求3在站点等待交通工具时专注于其它事物,不想疲于顾虑每次到站的交通工具是否为自己所等的路线,需要所需交通工具到达起乘站点的提醒。
2.根据权利要求1所述交通工具定时提醒系统,所述的交通工具特征是在交通工具 上便于顾客观察的位置公布了对该路线的各交通工具进行区分的个别编号,或者在该交通 工具的广播音中包含个别编号。
3.根据权利要求1所述的交通工具定时提醒系统,其特征是所述发自用户终端的针 对定时提醒需求1的定时提醒条件信息包括1类提醒用户终端(该项缺失则默认为发送终端),路线(或者该项缺失),起乘站点, 到站点(或上下行的区分),提醒提前时间,起乘的时间范围或大概范围,交通工具优选的 条件(或者该项缺失),充许的出错概率信息(或者该项缺失);或者2类特别指定的提醒用户终端,路线(或者该项缺失),起乘站点,到站点(或上 下行的区分),提醒提前时间,起乘的时间范围或大概范围,交通工具优选的条件(或者该 项缺失),充许的出错概率信息(或者该项缺失);以上所述充许的出错概率信息含义上可用保证正确的概率信息替代。
4.根据权利要求1或2所述的交通工具定时提醒系统,其特征是所述发自用户终端的针对定时提醒需求2的定时提醒条件信息包括提醒用户终端(该项缺失则默认为发送 终端),交通工具个别编号(或者定位成功的用户终端免发该项),目的站点信息。
5.使用权利要求1、2、3或4所述交通工具定时提醒系统的交通工具定时提醒方法,包括定时提醒平台接收发自交通工具位置采集单元的按规律更新的交通工具位置信息,定 时提醒程序软件处理该信息,识别出或通过计算识别出该信息所蕴含的交通工具的个别编 号识别信息、当前位置和上下行状态,定时提醒平台接收发自用户终端的针对定时提醒需求的定时提醒条件信息,定时提醒 程序软件处理该信息,得出解决该提醒需求的程序或程序子模块的绑定参数,该参数包括 提醒位置,提醒指向的用户终端以及用于确定软件所应监控的当前位置的参数,定时提醒软件确定所应监控的当前位置,并实施监控,如果所应监控的当前位置与绑 定参数中的提醒位置符合时,发出提醒信号, 用户终端接收到提醒信息。
6.根据权利要求5所述的交通工具定时提醒方法,其特征是所述定时提醒软件确定 所应监控的当前位置可以是不只一次地确定;或者所应监控的当前位置可以不只一个;所述再次确定所应监控的当前位置具有时间,该时间可以是在所应监控的当前位置与 绑定参数中的提醒位置符合时,或在所应监控的当前位置与绑定参数中的提醒位置符合之前。
7.根据权利要求5所述的交通工具定时提醒方法,其特征是所述按规律更新的交通 工具位置信息包括交通工具位置采集单元发送更新信息后的直接更新,或交通工具位置 采集单元无发送更新信息时随着时间推移的更新。
8.根据权利要求5所述的交通工具定时提醒方法,其特征是程序或程序子模块的启 动由定时提醒平台收到定时提醒条件信息后处理得出绑定参数就启动,或者在参数中包括 程序或程序子模块的启动时间,到达启动时间才启动,所述启动时间是模糊处理得出的或 科学计算得出的,当为科学计算得出的时,可让定时提醒程序软件的运算量更小。
9.根据权利要求5所述的交通工具定时提醒方法,其特征是所述定时提醒程序软件 处理定时提醒条件信息,得出解决对应提醒需求的程序或程序子模块的绑定参数时,定时 提醒程序软件调用了常备调用数据表中的数据,或者调用了该常备调用数据表中的数据所 关联的概率分布统计表中在某个概率下得出的数据;所述常备调用数据表或常备调用数据表中的数据所关联的概率分布统计表中的数据 的来源计算包括利用位置信息历史记录严格统计计算得出或者根据经验模糊计算或模糊 直接确定得出;所述常备调用数据表或常备调用数据表中的数据所关联的概率分布统计表中的数据 的计算方法包括将记录所属的日子的类型归类分开计算;所述将记录所属的日子的类型归类分开计算,所述类型包括工作日,节日,假日,上课 日,学生假期日,高考日,非年周期特殊日或不同类型的重叠日;所述非年周期特殊日包括奥运举办日,火炬传递日,世博会日,或足球世界杯日。
10.根据权利要求5所述的交通工具定时提醒方法,其特征是发自用户终端的针对定时提醒需求的定时提醒条件信息可以用包定期的方式提供,该方式对应的程序或程序子模块参数中包括了启动周期,是否是最后一次启动。
全文摘要
交通工具定时提醒系统和方法,解决的需求举例如下希望个人所需乘的公交,在到达个人的起乘站点之前一定时间(时间略大于自己从家中到达起乘站点的时间),给自己发起一个该出发动身的提醒;或在车上专注于其它事物而不想分心去注意普通的到站提醒(如到站广播音),为了避免坐过了站,需要到站的提醒。系统为定时提醒平台,交通工具位置采集单元和用户终端;方法为位置采集单元采集信息并发送和更新定时提醒平台中的位置信息,用户根据定醒需求发送定时提醒条件,信息受定时提醒程序软件的处理,当发现所更新的当前位置信息符合定时提醒条件信息敀 ,动用网络对指定的用户终端发起提醒。避免了乘客时间的浪费,可以多享用手机增值业务。
文档编号G08G1/123GK101799989SQ20101010494
公开日2010年8月11日 申请日期2010年1月18日 优先权日2010年1月18日
发明者刘铨 申请人:刘铨
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1