本发明实施例涉及智能交通领域，特别涉及一种求救方法、系统及装置。
背景技术：
：随着经济的发展，越来越多人的选用私人汽车作为一种代步工具，马路上的车辆数量也随之增加，发生交通事故的概率也大大提高。现有技术中，当车辆发生事故时，往往由事故车辆的车主自行向医院或亲友求救，或者由热心路人帮助车主联系救援人员，或者直到交警到达后才联系救援人员。在实现本发明实施例的过程中，发明人发现现有技术至少存在以下问题：事故车辆车主只能够在自身活动不受影响的情况下主动求救，如果事故车辆的车主受伤较重或已经进入昏迷状态，其他救援人员又不能及时赶到，容易错过救援事故车辆车主的最佳时机。技术实现要素：为了解决现有技术的问题，本发明实施例提供了一种求救方法、系统及装置。所述技术方案如下：根据本发明的第一方面，提供了一种求救方法，用于求救系统中，所述求救系统包括呼救设备、呼救设备服务器、社交服务器和社交客户端，所述社交服务器分别与所述呼救设备与所述呼救设备服务器相连，所述社交服务器是所述社交客户端的后台服务器，所述方法包括：当车辆发生碰撞时，所述车辆中的呼救设备获取地理位置和所述呼救设备的设备标识；所述呼救设备向所述社交服务器发送救援请求，所述救援请求至少包括所述地理位置和所述设备标识；所述社交服务器接收所述呼救设备发送的所述救援请求；所述社交服务器确定与所述设备标识关联的社交客户端，向所述社交客户端发送所述救援请求；所述社交客户端接收所述社交服务器发送的所述救援请求；所述社交服务器向所述呼救设备服务器发送所述救援请求；所述呼救设备服务器接收所述社交服务器发送的所述救援请求；所述呼救设备服务器根据所述救援请求指示救援人员前往所述地理位置进行救援。根据本发明的第二方面，提供了一种求救方法，应用于呼救设备服务器，所述呼救设备服务器与社交服务器连接，所述方法包括：接收所述社交服务器发送的救援请求，所述救援请求是车辆中的呼救设备在所述车辆发生碰撞时发送给所述社交服务器的，且所述救援请求至少包括所述车辆的地理位置和所述呼救设备的设备标识；根据所述救援请求指示救援人员前往所述地理位置进行救援。根据本发明的第三方面，提供了一种求救方法，应用于社交服务器中，所述方法包括：接收车辆中的呼救设备在所述车辆发生碰撞时发送的救援请求，所述救援请求至少包括所述车辆的地理位置和所述设备标识；确定与所述设备标识关联的社交客户端，向所述社交客户端发送所述救援请求，并向所述呼救设备服务器发送救援请求。根据本发明的第四方面，提供了一种求救系统，所述系统包括呼救设备、呼救设备服务器、社交服务器和社交客户端，所述社交服务器分别与所述呼救设备与所述呼救设备服务器相连，所述社交服务器是所述社交客户端的后台服务器，所述系统包括：当车辆发生碰撞时，所述车辆中的呼救设备，用于获取地理位置和所述呼救设备的设备标识；所述呼救设备，用于向所述社交服务器发送救援请求，所述救援请求至少包括所述地理位置和所述设备标识；所述社交服务器，用于接收所述呼救设备发送的所述救援请求；所述社交服务器，用于确定与所述设备标识关联的社交客户端，向所述社交客户端发送所述救援请求；所述社交客户端，用于接收所述社交服务器发送的所述救援请求；所述社交服务器，用于向所述呼救设备服务器发送所述救援请求；所述呼救设备服务器，用于接收所述社交服务器发送的所述救援请求；所述呼救设备服务器，用于根据所述救援请求指示救援人员前往所述地理位置进行救援。根据本发明的第五方面，提供了一种求救装置，应用于呼救设备服务器，所述呼救设备服务器与社交服务器连接，所述装置包括：救援请求接收模块，用于接收所述社交服务器发送的救援请求，所述救援请求是车辆中的呼救设备在所述车辆发生碰撞时发送给所述社交服务器的，且所述救援请求至少包括所述车辆的地理位置和所述呼救设备的设备标识；指示模块，用于根据所述救援请求接收模块接收的所述救援请求指示救援人员前往所述地理位置进行救援。根据本发明的第六方面，提供了一种求救装置，应用于社交服务器中，所述装置包括：救援请求接收模块，用于接收车辆中的呼救设备在所述车辆发生碰撞时发送的救援请求，所述救援请求至少包括所述车辆的地理位置和所述设备标识；第一请求发送模块，用于确定与所述设备标识关联的社交客户端，向所述社交客户端发送所述救援请求；第二请求发送模块，用于向所述呼救设备服务器发送救援请求。本发明实施例提供的技术方案带来的有益效果是：通过当车辆发生碰撞时，车辆中的呼救设备获取地理位置和呼救设备的设备标识，再由呼救设备向社交服务器发送救援请求，社交服务器根据接收到的救援请求确定与设备标识关联的社交客户端后，向社交客户端发送救援请求，社交服务器再向呼救设备服务器发送救援请求，呼救设备服务器根据接收到的救援请求指示救援人员前往救援；由于在车辆发生碰撞时，利用呼救设备向社交服务器发送救援请求，再由社交服务器向社交客户端和呼救设备服务器发救援请求，而不需要车主利用呼救设备求救，避免了因车主自身不方便求救或者其他救援人员又不能及时赶到，会导致容易错过救援的最佳时机的问题，达到了能够在第一时间内通知车主的亲友，获得亲友的关注，提高救援效率，降低死伤率的效果。附图说明为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1是根据部分示例性实施例示出的一种求救方法的实施环境的示意图；图2是根据一示例性实施例示出的一种求救方法的流程图；图3是根据另一示例性实施例示出的一种求救方法的流程图；图4是根据另一示例性实施例示出的一种求救方法的流程图；图5A是根据一示例性实施例示出的一种求救方法的实施示意图；图5B是根据一示例性实施例示出的一种求救方法的实施示意图；图5C是根据一示例性实施例示出的一种求救方法的实施示意图；图5D是根据一示例性实施例示出的一种求救方法的实施示意图；图5E是根据一示例性实施例示出的一种求救方法的实施示意图；图6是根据一示例性实施例示出的一种求救装置的结构方框图；图7是根据另一示例性实施例示出的一种求救装置的结构方框图；图8是根据一示例性实施例示出的一种求救装置的结构方框图；图9是根据一示例性实施例示出的一种求救装置的结构方框图。具体实施方式为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。请参考图1，其示出了本发明实施例提供的一种实施环境的结构示意图。该实施环境包括：呼救设备110、呼救设备服务器120、终端130、社交服务器140，其中：呼救设备110安装在车辆150中，具有数据传输的能力。比如：呼救设备可以是ecall设备。其中，车辆150是具有代步功能的行驶工具，比如：汽车、自行车、电动车、轮椅等等。呼救设备服务器120是呼救设备110的后台服务器，具有数据传输的能力。可选的，呼救设备服务器120受呼救设备服务商监控，且具有显示功能，当呼救设备服务器120接收并显示救援请求时，呼救设备服务商可以根据救援请求安排救援人员前往车辆的碰撞地点进行救援。终端130具有数据传输的能力，且终端130中安装有社交客户端。其中，社交客户端是即时通讯类应用程序，比如：MSN、微信、QQ等等。社交服务器140是社交客户端的后台服务器，可以是一台服务器或多台服务器组成的服务器集群或云计算中心。其中，社交服务器140中存储有呼救设备的设备标识和车辆发生碰撞时接收救援请求的社交帐号的映射关系。呼救设备110与社交服务器140通过无线网络连接。呼救设备服务器120与社交服务器140通过有线网络或无线网络或数据传输线连接。至少一个终端130中的社交客户端与社交服务器140通过有线网络或无线网络或数据传输线连接。请参考图2，其示出了本发明一个示例性实施例提供的求救方法的流程图。本实施例以该求救方法应用于图1所示的实施环境中来举例说明。该求救方法包括以下步骤：步骤201，当车辆发生碰撞时，车辆中的呼救设备获取地理位置和呼救设备的设备标识。当车辆发生碰撞时，车辆中的呼救设备获取该车辆发生碰撞的地点的地理位置和该呼救设备的设备标识。步骤202，呼救设备向社交服务器发送救援请求，救援请求至少包括地理位置和设备标识。步骤203，社交服务器接收呼救设备发送的救援请求。步骤204，社交服务器确定与设备标识关联的社交客户端，向社交客户端发送救援请求。社交服务器根据接收到的救援请求中携带的设备标识确定与设备标识关联的社交客户端，并向确定的社交客户端发送救援请求。步骤205，社交客户端接收社交服务器发送的救援请求。步骤206，社交服务器向呼救设备服务器发送救援请求。步骤207，呼救设备服务器接收社交服务器发送的救援请求。步骤208，呼救设备服务器根据救援请求指示救援人员前往该地理位置进行救援。需要说明的是，步骤206至步骤207可以在步骤204至步骤205之前执行，或者与步骤204至步骤205同时执行，本实施例不作限定。其中，步骤201和202可以单独实现成为呼救设备侧的实施例；步骤203、204和206可以单独实现成为社交服务器侧的实施例；步骤207和208可以单独实现成为呼救设备服务器侧的实施例。可选的，呼救设备服务器接收到社交服务器发送的救援请求后，根据救援请求指示救援人员前往车辆发生碰撞的地点的地理位置进行救援。综上所述，本发明实施例提供的求救方法，通过当车辆发生碰撞时，车辆中的呼救设备获取地理位置和呼救设备的设备标识，再由呼救设备向社交服务器发送救援请求，社交服务器根据接收到的救援请求确定与设备标识关联的社交客户端后，向社交客户端发送救援请求，社交服务器再向呼救设备服务器发送救援请求，呼救设备服务器根据接收到的救援请求指示救援人员前往救援；由于在车辆发生碰撞时，利用呼救设备向社交服务器发送救援请求，再由社交服务器向社交客户端和呼救设备服务器发救援请求，而不需要车主利用呼救设备求救，避免了因车主自身不方便求救或者其他救援人员又不能及时赶到，会导致容易错过救援的最佳时机的问题，达到了能够在第一时间内通知车主的亲友，获得亲友的关注，提高救援效率，降低死伤率的效果。请参考图3，其示出了本发明另一个示例性实施例提供的求救方法的流程图。本实施例以该求救方法应用于图1所示的实施环境中来举例说明。该求救方法包括以下步骤：步骤301，当车辆发生碰撞时，车辆中的呼救设备获取地理位置和呼救设备的设备标识。其中，呼救设备中安装有重力传感器(Gravity-sensor，G-sensor)，呼救设备可以通过重力感应器感知车辆的加速力的变化，从而根据加速力的变化确定车辆是否发生碰撞，加速力是指物理在加速过程中作用在物体上的力，当物体发生晃动、跌落、上升、下降等移动变化时都能够被重力传感器转化为电信号。当车辆在行驶过程中受到碰撞时，重力传感器将车辆的加速力的变化转化为电信号，再将该电信号发送至呼救设备，呼救设备根据电信号确定车辆是否发生碰撞。当呼救设备确定车辆发生碰撞时，获取该车辆发生碰撞的地点的地理位置和该呼救设备的设备标识。具体地，呼救设备可以通过全球定位系统(GlobalPositioningSystem，GPS)、提供数据服务的基站等方式获取地理位置。步骤302，呼救设备获取车辆的撞击程度。可选的，呼救设备还可以利用重力传感器获取车辆的撞击程度。在一种可能的实现方式中，呼救设备利用重力传感器转化的电信号和撞击程度的计算公式，计算得到撞击程度的具体数值；在另一种可能的实现方式中，呼救设备根据重力传感器转化的电信号确定撞击程度的等级，比如：在某范围内的电信号的数值对应的撞击程度都是同一等级的。步骤303，呼救设备检测撞击程度是否大于预定阈值。由于某些碰撞的撞击程度不会导致车主受伤，也不会影响车主继续驾驶，为避免呼救设备频繁向社交服务器发送救援请求，造成一定程度上的资源浪费，呼救设备检测撞击程度是否大于预定阈值，当撞击程度大于预定阈值时，向社交服务器发送救援请求，若撞击程度不大于预定阈值，则不向社交服务器发送救援请求。其中，预定阈值是用户预先设置的，或者是呼救设备中默认的数值，本实施例不作限定。比如：呼救设备根据车辆的型号以及车辆的抗撞击能力设置默认的预定阀值。步骤304，若撞击程度大于预定阈值，则呼救设备向社交服务器发送携带有地理位置、设备标识和撞击程度的救援请求。具体地，呼救设备发送的救援请求可以是符合语言逻辑的语句，也可以是能够表示地理位置、设备标识和撞击程度的几个短语。比如，车辆发送碰撞的地点的地理位置是北纬31.5685，东经120.3841，设备标识是2Q，撞击程度为3级，则呼救设备发送的救援请求可以是：呼救设备2Q对应的车辆在xx市xx大厦处发生3级碰撞事件，或者，北纬31.5685，东经120.3841、2Q、3级。若撞击程度小于预定阀值，则呼救设备不向社交服务器发送救援请求。可选的，若撞击程度小于预定阀值，呼救设备为了及时向呼救设备服务器反馈车辆的撞击情况，可以向呼救设备服务器发送携带有地理位置、设备标识和撞击程度的救援请求，呼救设备服务器接收到救援请求后，可以由监控呼救设备服务器的后台人员决定是否进行后续救援工作。需要说明的是，当车辆发生碰撞时，呼救设备还可以不检测撞击程度是否大于预定阈值，直接获取地理位置和呼救设备的设备标识，将携带有地理位置和设备标识的救援请求发送至社交服务器，此时不执行步骤302至步骤304。步骤305，社交服务器接收呼救设备发送的救援请求。步骤306，社交服务器根据预存的映射关系确定与设备标识对应的授权列表。映射关系用于记录设备标识和授权列表之间的对应关系，授权列表用于记录车辆发生碰撞时接收救援请求的社交帐号。其中，一个设备标识对应的授权列表中记录的社交帐号至少为一个。比如，授权列表中记录的社交帐号可以是车主的各个亲友的社交帐号。如下表所示，其示例性地示出了社交服务器中预存的映射关系的一部分：可选的，车主可以通过社交客户端将设备标识和社交帐号关联。比如：车主在社交客户端中添加呼救设备的设备标识，再向选中的社交帐号发送将社交帐号与设备标识关联的请求，若社交帐号确定与设备标识关联，则社交服务器将社交帐号添加至设备标识对应的授权列表中；或者，车主在社交客户端中添加呼救设备的设备标识后，社交服务器将与车主的社交帐号联系频率满足一定条件的社交帐号添加至授权列表，该过程可以需要被添加的社交帐号的确认，也可以不需要通过被添加的社交帐号的确认；或者，车主在社交客户端中添加呼救设备的设备标识后，社交客户端将特定群组如亲友群组中的社交账号添加至授权列表，该过程可以需要被添加的社交帐号的确认，也可以不需要被添加的社交帐号的确认。步骤307，社交服务器确定各个社交客户端，每个社交客户端中登录有授权列表中记录的社交帐号。社交服务器确定出授权列表后，可以获取授权列表中的社交帐号，再确定出登录有授权列表中记录的社交帐号的社交客户端。步骤308，社交服务器向社交客户端发送救援请求。可选的，为了便于使用社交客户端的用户阅读救援信息，社交服务器向社交客户端发送的救援请求可以是符合语言逻辑的语句。步骤309，社交客户端接收社交服务器发送的救援请求。步骤310，社交服务器向呼救设备服务器发送救援请求。步骤311，呼救设备服务器接收社交服务器发送的救援请求。需要说明的是，步骤310至上述步骤311可在步骤308至步骤309之前执行，还可以与步骤308至步骤309同时执行。步骤312，呼救设备根据救援请求指示救援人员前往该地理位置进行救援。步骤313，呼救设备服务器向社交服务器发送救援进度和设备标识。可选的，呼救设备服务器接收到救援请求后，指示救援人员前往碰撞发生的地理位置进行救援，或者，由后台人员安排救援人员前往碰撞发生的地理位置进行救援，救援人员将救援进度和设备标识反馈给呼救设备服务器，呼救设备服务器向社交服务器发送救援进度和设备标识。可选的，救援进度能够表示救援人员对车辆碰撞事件的救援状态，比如：救援进度是：在前往事故地点的路上，或，快到达事故地点，或，已到达事故地点，或，已将车主送往医院。步骤314，社交服务器接收救援进度和设备标识。步骤315，社交服务器确定与设备标识关联的社交客户端，并向社交客户端发送救援进度。社交服务器确定与设备标识关联的社交客户端的具体实现方式如上述步骤306至步骤307，这里不再赘述。社交服务器向登录有授权列表中社交帐号的社交客户端发送救援进度，以便使用社交客户端的用户能够及时了解救援进度。可选的，社交服务器向登录有授权列表中的社交帐号的全部社交客户端发送救援进度，或者，社交服务器向登录有授权列表中的社交帐号的部分社交客户端发送救援进度。步骤316，社交客户端接收社交服务器发送的救援进度。其中，步骤301至步骤304可以单独实现成为呼救设备侧的实施例；步骤305至步骤308、步骤310、步骤314至步骤315可以单独实现成为社交服务器侧的实施例；步骤311至步骤313可单独实现成为呼救设备服务器侧的实施例。综上所述，本发明实施例提供的求救方法，通过当车辆发生碰撞时，车辆中的呼救设备获取地理位置和呼救设备的设备标识，再由呼救设备向社交服务器发送救援请求，社交服务器根据接收到的救援请求确定与设备标识关联的社交客户端后，向社交客户端发送救援请求，社交服务器再向呼救设备服务器发送救援请求，呼救设备服务器根据接收到的救援请求指示救援人员前往救援；由于在车辆发生碰撞时，利用呼救设备向社交服务器发送救援请求，再由社交服务器向社交客户端和呼救设备服务器发救援请求，而不需要车主利用呼救设备求救，避免了因车主自身不方便求救或者其他救援人员又不能及时赶到，会导致容易错过救援的最佳时机的问题，达到了能够在第一时间内通知车主的亲友，获得亲友的关注，提高救援效率，降低死伤率的效果。在基于图2或图3所示实施例的可选实施例中，在用户还可以通过社交客户端主动询问救援进度，即在步骤311之后该方法还包括如下步骤，如图4所示：在步骤401中，社交客户端向社交服务器发送救援进度询问请求。救援进度询问请求至少包括设备标识和社交客户端中登录的社交帐号，社交帐号是授权列表中记录的社交帐号。可选的，对应于社交帐号的用户在社交客户端中输入设备标识和救援进度询问的语句，社交客户端根据用户输入的语句生成救援进度询问请求，并向社交服务器发送救援进度询问请求；或者，用户在社交客户端中触发询问救援进度的快捷键，社交客户端根据之前接收到的设备标识自动生成救援进度询问请求，并向社交服务器发送救援进度询问请求。比如：社交服务器之前已经向社交客户端发送过携带有设备标识为Q2的救援请求，用户在社交客户端中输入“询问救援进度，Q2”，则社交客户端自动生成至少包括设备标识和社交客户端中的社交客户端中登录的社交帐号的救援进度询问请求，并向社交服务器发送救援进度询问请求；或者，用户在社交客户端中触发询问救援进度的快捷键，社交客户端根据社交客户端之前接收到的设备标识Q2，生成至少包括设备标识和社交客户端中的社交客户端中登录的社交帐号的救援进度询问请求，并向社交服务器发送救援进度询问请求。步骤402，社交服务器接收社交客户端发送的救援进度询问请求。步骤403，社交服务器向呼救设备服务器发送救援进度询问请求。步骤404，呼救设备服务器接收救援进度询问请求。步骤405，呼救设备服务器根据救援进度询问请求中携带的设备标识确定救援进度。可选的，呼救设备服务器向与设备标识对应的救援人员发送救援进度询问，救援人员接收到救援进度询问后向呼救设备服务器反馈救援进度，其中，救援进度询问可以是呼救设备服务器直接向救援人员发送的，也可以是呼救设备服务器的后台人员向救援人员发送的，同样地，救援人员可以直接向呼救设备服务器反馈救援进度，也可以通过呼救设备服务器的后台人员反馈呼救援进度。步骤406，呼救设备服务器向社交服务器发送救援进度和设备标识。步骤407，社交服务器接收救援进度和设备标识。步骤408，社交服务器根据设备标识确定救援进度询问请求，并根据救援进度询问请求中携带的社交帐号确定社交客户端。步骤409，社交服务器向社交客户端发送救援进度。通常情况下，社交服务器只向发出救援进度询问请求的社交帐号对应的社交客户端发送救援进度。在一种可能的实现方式中，社交服务器也可以向与设备标识对应的授权列表中的全部社交帐号对应的社交客户端发送救援进度。相应地，社交客户端接收社交服务器发送的救援进度。此外，本发明实施例提供的求救方法，还通过社交客户端向社交服务器发送救援进度询问请求，社交服务器仅向发送救援进行询问请求的社交客户端反馈救援进度，使得用户能够随时询问救援进度，及时获取救援进度的相关信息，服务器只向特定社交客户端反馈救援进度，有助于社交服务器更快地处理、发送信息，节省社交服务器的资源。需要说明的是，本发明实施例提供的求救方法，还可以只执行如图3所示实施例中步骤301至步骤311，和如图4所示实施例中的步骤401至步骤409。本领域技术人员还可以根据实际需要对上述步骤进行自由组合，得到其他实现方式，这里不再赘述。在一个示意性地例子中，以发生碰撞事件的车辆为汽车，车主为小王，安装在车辆上的呼救设备为ecall设备，ecall设备的设备标识为E1，社交客户端为QQ，社交服务器为QQ服务器，呼救设备服务器为ecall服务器为例，如图5A所示，该求救方法包括：步骤501，当车辆发生碰撞时，车辆中的ecall设备获取地理位置和ecall设备的设备标识。ecall设备根据重力传感器发送的电信号判断出该汽车发生了碰撞，通过GPS获取到发生碰撞的地理位置为北纬31.5685，东经120.3841，获取到的设备标识为E1。步骤502，ecall设备获取车辆的撞击程度。ecall设备根据电信号计算出汽车的撞击程度为三级。步骤503，ecall设备检测撞击程度是否大于预定阈值。假设预定阈值为二级，ecall设备检测出该汽车的撞击程度大于二级。步骤504，ecall设备向QQ服务器发送携带有地理位置、设备标识和撞击程度的救援请求。ecall设备向QQ服务器发送的救援请求为：ecall设备E1对应的汽车在北纬31.5685，东经120.3841发生三级碰撞事件，请求立即救援。步骤505，QQ服务器接收ecall设备发送的救援请求。步骤506，QQ服务器根据预存的映射关系确定与E1对应的授权列表。QQ服务器中与E1对应的授权列表中记录的QQ号有3个，分别为小李、老王、小华。步骤507，QQ服务器确定各个QQ客户端，每个QQ客户端中登录有授权列表中记录的QQ号。QQ服务器确定三个QQ客户端，这三个QQ客户端中分别登录有QQ号小李、老王、小华，这三个QQ号分别对应小王的妻子、父亲、儿子。步骤508，QQ服务器向QQ客户端发送救援请求。QQ服务器根据接收到的救援请求中的地理位置的经纬度将地理位置转换为具体的地点名称，分别向登录有QQ号的小李、老王、小华的QQ客户端发送救援请求。步骤509，QQ客户端接收QQ服务器发送的救援请求。如图5B所示，小李的QQ客户端接收发QQ服务器发送的救援请求，救援请求如51所示“呼救设备E1对应的汽车在格陵市幸福大道23号附近发生三级碰撞事件，请求救援”，同样地，老王和小华的QQ客户端都接收到同样的救援请求。步骤510，QQ服务器向ecall设备服务器发送救援请求。步骤511，ecall设备服务器接收QQ服务器发送的救援请求。ecall设备服务器接收到救援请求后安排救援人员前往碰撞地点格陵市幸福大道23号附近进行救援。救援人员到达现场后，将救援进度“已到达事故现场”和设备标识E1反馈给ecall设备服务器。步骤512，ecall设备服务器向QQ服务器发送救援进度和设备标识。ecall设备服务器向QQ服务器发送救援进度“已到达事故现场”和设备标识E1。步骤513，QQ服务器接收ecall设备发送的救援进度和设备标识。步骤514，QQ服务器确定与设备标识E1关联的QQ客户端，并向QQ交客户端发送救援进度。QQ服务器根据设备标识E1确定出QQ客户端为登录有QQ号小李、老王、小华的QQ客户端，向这三个QQ客户端发送救援进度。步骤515，QQ客户端接收QQ服务器发送的救援进度。如图5C所示，小李的QQ客户端接收发QQ服务器发送的救援进度，救援请求如52所示“救援人员已到达格陵市幸福大道23号附近”，同样地，老王和小华的QQ客户端都接收到同样的救援进度。步骤516，QQ客户端向QQ服务器发送救援进度询问请求。登录有QQ号小华的QQ客户端向QQ服务器发送救援进度询问请求“询问E1对应的汽车的救援进度”，如图5D所示。救援进度询问请求中还包括有QQ客户端中登录的QQ号小华。步骤517，QQ服务器接收QQ客户端发送的救援进度询问请求。步骤518，QQ服务器向ecall设备服务器发送救援进度询问请求。步骤519，ecall设备服务器接收救援进度询问请求。步骤520，ecall设备服务器根据救援进度询问请求中携带的设备标识确定救援进度。ecall设备根据设备标识E1确定出救援进度为“已将车主送至医院”。步骤521，ecall设备服务器向QQ服务器发送救援进度和设备标识ecall设备向QQ服务器发送救援进度“已将车主送至医院”和设备标识E1。步骤522，QQ服务器根据设备标识确定救援进度询问请求，并根据救援进度询问请求中携带的QQ号确定QQ客户端。QQ服务器根据设备标识E1确定救援进度询问请求来自登录有QQ号小华的QQ客户端。步骤523，QQ服务器向QQ客户端发送救援进度。QQ服务器向登录有QQ号小华的QQ客户端发送救援进度“已将车主送至医院”。相应地，登录有QQ号小华的QQ客户端接收救援进度，如图5E所示。请参考图6，其示出了本发明一个示例性实施例提供的求救装置的结构方框图。该求救装置可以通过软件、硬件或者两者的结合实现成为上述可提供求救方法的呼救设备服务器的全部或一部分。该装置包括：救援请求接收模块610，用于接收社交服务器发送的救援请求，救援请求是车辆中的呼救设备在车辆发生碰撞时发送给社交服务器的，且救援请求至少包括车辆的地理位置和呼救设备的设备标识。指示模块620，用于根据救援请求接收模块610接收的救援请求指示救援人员前往地理位置进行救援。综上所述，本发明实施例提供的求救装置，通过在车辆发生碰撞时，呼救设备服务器接收社交服务器发送的救援请求，并指示救援人员前往地理位置进行救援；由于在车辆发生碰撞时，利用呼救设备向社交服务器发送救援请求，再由社交服务器向社交客户端和呼救设备服务器发救援请求，而不需要车主利用呼救设备求救，避免了因车主自身不方便求救或者其他救援人员又不能及时赶到，会导致容易错过救援的最佳时机的问题，达到了能够在第一时间内通知车主的亲友，获得亲友的关注，提高救援效率，降低死伤率的效果。请参考图7，其示出了本发明另一个示例性实施例提供的求救装置的结构方框图。该求救装置可以通过软件、硬件或者两者的结合实现成为上述可提供求救方法的呼救设备服务器的全部或一部分。该装置包括：救援请求接收模块710，用于接收社交服务器发送的救援请求，救援请求是车辆中的呼救设备在车辆发生碰撞时发送给社交服务器的，且救援请求至少包括车辆的地理位置和呼救设备的设备标识。指示模块720，用于根据救援请求接收模块710接收的救援请求指示救援人员前往地理位置进行救援。可选的，该装置，还包括：进度获取模块730，用于获取救援人员对车辆的救援进度。第一进度发送模块740，用于向社交服务器发送进度获取模块1030获取的救援进度和设备标识。可选的，该装置还包括：询问请求接收模块750，用于接收社交服务器发送的救援进度询问请求，救援进度询问请求是社交客户端发送给社交服务器的，且救援进度询问请求至少包括设备标识和登录社交客户端的社交帐号，社交客户端中登录有授权列表中社交帐号，授权列表用于记录车辆发生碰撞时接收救援请求的社交帐号。进度确定模块760，用于根据询问请求接收模块750接收的救援进度询问请求中携带的设备标识确定救援进度。第二进度发送模块770，用于向社交服务器发送进度确定模块760确定的救援进度和设备标识。综上所述，本发明实施例提供的求救装置，通过在车辆发生碰撞时，呼救设备服务器接收社交服务器发送的救援请求，并指示救援人员前往地理位置进行救援；由于在车辆发生碰撞时，利用呼救设备向社交服务器发送救援请求，再由社交服务器向社交客户端和呼救设备服务器发救援请求，而不需要车主利用呼救设备求救，避免了因车主自身不方便求救或者其他救援人员又不能及时赶到，会导致容易错过救援的最佳时机的问题，达到了能够在第一时间内通知车主的亲友，获得亲友的关注，提高救援效率，降低死伤率的效果。请参考图8，其示出了本发明一个实施例提供的求救装置的结构方框图。该求救装置可以通过软件、硬件或者两者的结合实现成为上述可提供求救方法的社交服务器的全部或一部分。该装置包括：救援请求接收模块810，用于接收车辆中的呼救设备在所述车辆发生碰撞时发送的救援请求，所述救援请求至少包括所述车辆的地理位置和所述设备标识；第一请求发送模块820，用于确定与所述设备标识关联的社交客户端，向所述社交客户端发送所述救援请求。第二请求发送模块830，用于向所述呼救设备服务器发送救援请求。综上所述，本发明实施例提供的求救装置，通过在车辆发生碰撞时，社交服务器接收呼救设备发送的救援请求，社交服务器确定与设备标识关联的社交客户端，向社交客户端和呼救设备服务器发送救援请求；由于在车辆发生碰撞时，利用呼救设备向社交服务器发送救援请求，再由社交服务器向社交客户端和呼救设备服务器发救援请求，而不需要车主利用呼救设备求救，避免了因车主自身不方便求救或者其他救援人员又不能及时赶到，会导致容易错过救援的最佳时机的问题，达到了能够在第一时间内通知车主的亲友，获得亲友的关注，提高救援效率，降低死伤率的效果。请参考图9，其示出了本发明另一个实施例提供的求救装置的结构方框图。该求救装置可以通过软件、硬件或者两者的结合实现成为上述可提供求救方法的社交服务器的全部或一部分。该装置包括：救援请求接收模块910，用于接收车辆中的呼救设备在车辆发生碰撞时发送的救援请求，救援请求至少包括车辆的地理位置和设备标识；第一请求发送模块920，用于确定与设备标识关联的社交客户端，向社交客户端发送救援请求。第二请求发送模块930，用于向呼救设备服务器发送救援请求。可选的，该装置还包括：第一进度接收模块940，用于接收呼救设备服务器发送的救援进度和设备标识；确定发送模块950，用于确定与设备标识关联的社交客户端，并向社交客户端发送救援进度。可选的，确定发送模块950包括：第一确定单元951，用于根据预存的映射关系确定与设备标识对应的授权列表，映射关系用于记录设备标识和授权列表之间的对应关系，授权列表用于记录车辆发生碰撞时接收救援请求的社交帐号；第二确定单元952，用于确定各个社交客户端，每个社交客户端中登录有授权列表中记录的社交帐号。可选的，该装置包括：询问请求接收模块960，用于接收社交客户端发送的救援进度询问请求，救援进度询问请求至少包括设备标识和登录社交客户端的社交帐号，社交帐号是授权列表中记录的社交帐号；询问请求发送模块970，用于向呼救设备服务器发送救援进度询问请求；第二进度接收模块980，用于接收呼救设备服务器发送的救援进度和设备标识，救援进度是呼救设备服务器根据设备标识确定并发送的；确定模块990，用于根据设备标识确定救援进度询问请求，并根据救援进行询问请求中携带的社交帐号确定社交客户端；发送模块991，用于向社交客户端发送救援进度。综上所述，本发明实施例提供的求救装置，通过在车辆发生碰撞时，社交服务器接收呼救设备发送的救援请求，社交服务器确定与设备标识关联的社交客户端，向社交客户端和呼救设备服务器发送救援请求；由于在车辆发生碰撞时，利用呼救设备向社交服务器发送救援请求，再由社交服务器向社交客户端和呼救设备服务器发救援请求，而不需要车主利用呼救设备求救，避免了因车主自身不方便求救或者其他救援人员又不能及时赶到，会导致容易错过救援的最佳时机的问题，达到了能够在第一时间内通知车主的亲友，获得亲友的关注，提高救援效率，降低死伤率的效果。需要说明的是：上述实施例提供的求救装置在实现上述求救方法时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的求救装置与求救方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。当前第1页1 2 3