一种标准化航空公司附加服务销售的方法及装置

技术领域

本发明涉及航空销售技术领域，更具体的说，涉及一种标准化航空公司附加服务销售的方法及装置。

背景技术

IATA(International Air Transport Association，国际航空运输协会)发布的NDC(New Distribution Capability)标准推动了航空公司零售化转型的步伐，NDC标准提出后，不少航空公司积极参与并实施NDC的改造。然而，IATA在推出NDC标准后，还会对NDC标准进行不断地升级，并持续推出不同的NDC版本，从而导致不同时期开始实施NDC的航司所采取的是不同的NDC版本；另一方面，航空公司在实施NDC标准时，对于NDC标准中未明确规定的部分会根据各自的理解来定义。以上情况导致了不同航空公司所实现的NDC接口都或多或少地存在差异性，该差异性体现在航空公司NDC预订流程的诸多方面，附加服务预订的差异就是其中之一。

附加服务指的是航空公司所提供的除了机票产品之外的其他增值服务，通常机票产品的销售环节分为航班查询-->预订(生成订单)-->支付与出票三大环节，附加服务一般在旅客查询并选择好航班之后，基于所选航班进行附加服务的查询和预订。但是，不同的航空公司对于查询航班之后的具体哪个环节可以选购附加服务会有不同的要求，有些航司允许旅客在查询选择好航班后立即查询附加服务，并将所选择的航班与附加服务一同创建订单，以在后续一同支付；有些航司则只允许在航班订单创建之后，才能查询并追加附加服务到订单中；还有些航司允许在支付与出票之后继续追加附加服务到订单中。

在IATA的标准定义中Aggregator(内容聚合商)角色负责聚合多家航司的返回结果，没有明确的义务对所有差异进行统一，但不同航司的差异势必对下游用户的实施带来困扰。面对不同航空公司附加服务预订流程不统一的情况，如果一个下游分销商需要销售不同航司的附加服务，则会对其技术实施带来困扰，因为下游分销商不仅需要分别去了解不同航司的预订流程，还需要在程序设计上进行个性化的定制，从而使预订流程根据不同的航司要求进行流转，避免出现调用到航空公司所不支持的附加服务预订场景。因此，整个过程是非常繁琐且耗时的，尤其是涉及到海外航司时还存在语言障碍，若有多家下游分销商对接了同样的多家上游航空公司，则需要各下游分销商分别做同样的重复劳动，从而导致下游分销商对航空公司的接入体验极为不好。

发明内容

有鉴于此，本发明公开一种标准化航空公司附加服务销售的方法及装置，以解决下游分销商因识别不同航司附加服务预订流程并进行定制开发带来的繁琐操作的问题。

一种标准化航空公司附加服务销售的方法，应用于内容聚合商Aggregator服务器，所述方法包括：

通过航班查询接口接收用户端发送的航班查询请求，其中，所述航班查询请求中包含航班查询条件；

将所述航班查询请求转换为相应航空公司能够识别的航班查询请求，并发送至相应的航空公司；

接收所述航空公司在预设时间段内返回的满足所述航班查询条件的可用航班信息；

将接收到的所有的所述可用航班信息聚合成新分销能力NDC标准的返回结果报文，其中，在所述返回结果报文中预留了自定义节点；

在所述自定义节点中添加标准化的引导附加服务销售的自定义子节点及相应报文体，得到航班查询结果报文，其中，所述自定义子节点及相应报文体根据所述可用航班信息对应的目标航空公司支持的目标附加服务销售流程得到；

将所述航班查询结果报文通过所述航班查询接口返回至所述客户端，使所述用户端根据所述航班查询结果报文确定对所述目标航空公司的附加服务的发起时间和支付方式。

一种标准化航空公司附加服务销售的装置，应用于内容聚合商Aggregator服务器，所述装置包括：

第一接收单元，用于通过航班查询接口接收用户端发送的航班查询请求，其中，所述航班查询请求中包含航班查询条件；

发送单元，用于将所述航班查询请求转换为相应航空公司能够识别的航班查询请求，并发送至相应的航空公司；

第二接收单元，用于接收所述航空公司在预设时间段内返回的满足所述航班查询条件的可用航班信息；

聚合单元，用于将接收到的所有的所述可用航班信息聚合成新分销能力NDC标准的返回结果报文，其中，在所述返回结果报文中预留了自定义节点；

添加单元，用于在所述自定义节点中添加标准化的引导附加服务销售的自定义子节点及相应报文体，得到航班查询结果报文，其中，所述自定义子节点及相应报文体根据所述可用航班信息对应的目标航空公司支持的目标附加服务销售流程得到；

返回单元，用于将所述航班查询结果报文通过所述航班查询接口返回至所述客户端，使所述用户端根据所述航班查询结果报文确定对所述目标航空公司的附加服务的发起时间和支付方式。

从上述的技术方案可知，本发明公开了一种标准化航空公司附加服务销售的方法及装置，通过调用的航班查询接口接收用户端发送的航班查询请求，并将该航班查询请求发送至航空公司，接收航空公司在预设时间段内返回的满足航班查询条件的可用航班信息，并将可用航班信息聚合成新分销能力NDC标准的返回结果报文，在返回结果报文中预留的自定义节点中，添加标准化的引导附加服务销售的自定义子节点及相应报文体，得到航班查询结果报文，并将航班查询结果报文通过航班查询接口发送至用户端，使用户端根据航班查询结果报文确定对目标航空公司的附加服务的发起时间和支付方式，其中，自定义子节点及相应报文体根据可用航班信息对应的目标航空公司支持的目标附加服务销售流程得到。本发明通过在返回结果报文中添加标准化的附加服务销售的引导信息，得到航班查询接口用于输出至用户端的航班查询结果报文，从而能够有效传递不同航司不同的附加服务销售流程给作为用户端的下游分销商，从而有助于减轻下游分销商因识别不同航司附加服务预订流程并进行定制开发带来的繁琐操作，使得下游分销商能够使用统一的一套处理逻辑，即可达到处理各航司不同的附加服务销售流程的目的。

附图说明

结合附图并参考以下具体实施方式，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。贯穿附图中，相同或相似的附图标记表示相同或相似的元素。应当理解附图是示意性的，原件和元素不一定按照比例绘制。

图1为本发明实施例公开的一种标准化航空公司附加服务销售的方法流程图；

图2为本发明实施例公开的一种自定义子节点及相应报文体的生成方法流程图；

图3为本发明实施例公开的一种标准化航空公司附加服务销售的装置的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

附加服务指的是航空公司所提供的除了机票产品之外的其他增值服务，常见的附加服务产品如预付费行李、付费选座和付费餐食等。附加服务已经成为航空公司新的利润增长点，以及体现差异化的竞争力，因此各航司都在积极发展附加服务产品，作为Aggregator角色，对附加服务产品销售的顺畅支持是非常必要的。

本发明的发明人经过研究后发现，虽然不同航空公司的附加服务预订流程不同，但相同之处在于附加服务都是在选定航班之后才能进行查询与预订。因此航班查询这一操作可以认为是进行附加服务查询与预订的前置条件。本发明选择在航班查询(AirShopping)接口返回的结果中，进行后续流程的引导设计。

通过对不同航空公司的附加服务预订流程进行差异分析，总结出附加服务预订流程主要有如下几种流程：

流程A：航班查询-->附加服务查询-->航班+附加服务生成订单-->共同支付(延时支付)；

流程B：航班查询-->附加服务查询-->航班+附加服务生成订单并同时支付(即时支付)；

流程C：航班查询-->航班生成订单-->附加服务查询-->附加服务追加到订单中-->共同支付(延时支付)；

流程D：航班查询-->航班生成订单-->附加服务查询-->附加服务追加到订单中并同时支付(即时支付)；

流程E：航班查询-->航班生成订单-->航班完成支付-->附加服务查询-->附加服务追加到订单中-->附加服务补充支付(延时支付)；

流程F：航班查询-->航班生成订单-->航班完成支付-->附加服务查询-->附加服务追加到订单中并同时支付(即时支付)；

不同航空公司可能会支持其中的一种或是若干种附加服务预订流程。

通过对上述流程的进一步分析，可以得到附加服务预订的两个关键参数，一个是允许在何时添加附加服务，包括：订单生成时(流程A、B)、订单生成后支付前(流程C、D)、订单支付后(流程E、F)；另一个是采用即时支付或延时支付。

基于此，本发明通过两个简单参数的组合取值来代表不同的流程，例如表1所示。

表1

基于此，本发明实施例公开了一种标准化航空公司附加服务销售的方法及装置，通过调用的航班查询接口接收用户端发送的航班查询请求，并将该航班查询请求发送至航空公司，接收航空公司在预设时间段内返回的满足航班查询条件的可用航班信息，并将可用航班信息聚合成新分销能力NDC标准的返回结果报文，在返回结果报文中预留的自定义节点中，添加标准化的引导附加服务销售的自定义子节点及相应报文体，得到航班查询结果报文，并将航班查询结果报文通过航班查询接口发送至用户端，使用户端根据航班查询结果报文确定对目标航空公司的附加服务的发起时间和支付方式，其中，自定义子节点及相应报文体根据可用航班信息对应的目标航空公司支持的目标附加服务销售流程得到。本发明通过在返回结果报文中添加标准化的附加服务销售的引导信息，得到航班查询接口用于输出至用户端的航班查询结果报文，从而能够有效传递不同航司不同的附加服务销售流程给作为用户端的下游分销商，从而有助于减轻下游分销商因识别不同航司附加服务预订流程并进行定制开发带来的繁琐操作，使得下游分销商能够使用统一的一套处理逻辑，即可达到处理各航司不同的附加服务销售流程的目的。

为便于理解，下面对本发明涉及的一些术语解释如下：

Aggregator：内容聚合商，是NDC(New Distribution Capability，新分销能力)销售模式下一个新的角色。Aggregator对接各个航空公司的NDC接口，将其NDC内容进行汇总、解析、转换和融合，生成聚合后的内容，然后按照NDC标准向下游渠道客户提供统一接口，下游客户只需对接该统一接口，即可快速实现多家航司的对接销售。

NDC是IATA发布的一个关于航空分销的新技术标准。NDC标准使用XML语言来代替传统报文在航空公司、内容聚合商及售票代理人等多方之间传输信息。

参见图1，本发明实施例公开的一种标准化航空公司附加服务销售的方法流程图，该方法应用于Aggregator服务器，该方法包括：

步骤S101、通过航班查询接口接收用户端发送的航班查询请求；

具体的，客户端调用航班查询接口，并通过航班查询接口将航班查询请求发送至Aggregator服务器。

其中，航班查询请求中包含航班查询条件，所述航班查询条件包括：航班信息和旅客信息，所述航班信息包括但不限于：航班始发地、航班目的地、航班号和出发时间等等。所述旅客信息包括：旅客姓名、旅客身份证号等等。

需要说明的是，航班查询请求中可以包含有：航空公司名称，也可以不包含航空公司名称。

在实际应用中，通常由用户端(通常是下游分销商)向Aggregator的服务器发起航班查询(AirShopping)请求。

步骤S102、将所述航班查询请求转换为相应航空公司能够识别的航班查询请求，并发送至相应的航空公司；

具体的，当航班查询请求中包含待查询航空公司名称时，步骤S102具体包括：将航班查询请求发送至待查询航空公司名称对应的航空公司；

当航班查询请求中不包含待查询航空公司名称时，步骤S102具体包括：将航班查询请求发送至Aggregator服务器关联的所有的航空公司。

需要说明的是，发送至航空公司的航班查询请求的格式为该航空公司能够识别的格式。因此，在将航班查询请求发送至航空公司之前，需要将航班查询请求转换成航空公司能够识别的格式，并将格式转换后的航班查询请求发送至对应的航空公司。

步骤S103、接收所述航空公司在预设时间段内返回的满足所述航班查询条件的可用航班信息；

其中，可用航班信息中包括但不限于：航空公司名称、航班始发地、航班目的地、航班号和出发时间等等。

本实施例中所述航空公司可以为一个或是多个。

当在预设时间段内未接收到任何航空公司返回的满足所述航班查询条件可用航班信息时，输出航班查询失败的提示信息。

需要说明的是，本发明中仅将在预设时间段内返回的满足航班查询条件的可用航班信息作为有效航班信息，将在预设时间段外返回的满足航班查询条件的可用航班信息，或是不满足航班查询条件的可用航班信息，均作为无效航班信息。

步骤S104、将接收到的所有的所述可用航班信息聚合成NDC标准的返回结果报文；

其中，本发明在所述返回结果报文中预留了自定义节点。

本发明在执行标准化航空公司附加服务销售的过程之前，做了一些前置准备工作。

准备工作1：设计返回结果报文

在IATA NDC报文(即本实施例中的返回结果报文)的定义中，预留了自定义节点，在自定义节点之下允许将额外返回给用户(通常是下游分销商)的信息进行记录，从而使得返回结果报文中可以携带更多返回给用户的参数。

在自定义节点之下，设计表2所示的报文体，自定义节点之下的报文体包括：自定义报文体片段以及相对应的节点及字段说明。

表2

需要说明的是，本实施例聚合得到NDC标准的返回结果报文的过程可参见现有成熟方案，此处不再赘述。

步骤S105、在自定义节点中添加标准化的引导附加服务销售的自定义子节点及相应报文体，得到航班查询结果报文；

其中，自定义子节点及相应报文体根据所述可用航班信息对应的目标航空公司支持的目标附加服务销售流程得到。

参见图2，本发明实施例公开的一种自定义子节点及相应报文体的生成方法流程图，该方法包括：

步骤S201、从预先存储的航空公司和支持的附加服务销售流程的对应关系中，查找返回所述可用航班信息对应的目标航空公司支持的目标附加服务销售流程；

需要说明的是，本发明在执行标准化航空公司附加服务销售的过程之前，做了一些前置准备工作。

准备工作2：Aggregator的服务器对各航空公司支持的附加服务销售流程预先进行了解，并将航空公司和支持的附加服务销售流程以对应关系的形式记录在数据表或预先编写的程序块中。

假设，有三家航空公司，分别为：XX、YY和ZZ，三家航空公司分别支持不同的附加服务销售流程，参见表3所示。

表3

步骤S202、基于所述目标附加服务销售流程，生成所述目标航空公司的引导附加服务销售的自定义子节点及相应报文体。

基于上述实施例，XX、YY和ZZ三家航空公司对应的自定义子节点及相应报文体用表4表示。

表4

步骤S106、将所述航班查询结果报文通过所述航班查询接口返回至所述客户端，使所述用户端根据所述航班查询结果报文确定对所述目标航空公司的附加服务的发起时间和支付方式。

其中，支付方式包括：即时支付和延时支付。

本实施例中，用户端接收到航班查询结果报文后，根据航班查询结果报文就可以确定对目标航空公司的附加服务的发起时间和支付形式，从而可以有效地控制用户端操作界面的流程引导展示，使得用户端根据流程引导完成后续的附加服务销售流程。

为便于理解本实施例所要保护的标准化航空公司附加服务销售的方法，本发明提供了一个具体实施例，如下：

(1)假设用户端向Aggregator的服务器发起了查询航空公司XX、YY和ZZ的航班查询请求；

(2)将所述航班查询请求转换为相应航空公司能够识别的航班查询请求，并发送至相应的航空公司XX、YY和ZZ；

(3)假设服务器在预设时间段内接收到了航空公司YY和ZZ返回的满足所述航班查询条件的可用航班信息，未接收到航空公司XX返回的满足所述航班查询条件的可用航班信息；

(4)对航空公司YY和ZZ返回的满足所述航班查询条件的可用航班信息进行聚合处理，得到NDC标准的返回结果报文；

(5)在返回结果报文的自定义节点中，添加航空公司YY和ZZ对应的引导附加服务销售的自定义子节点及相应报文体，得到航班查询结果报文，如下：

(6)将所述航班查询结果报文通过所述航班查询接口输出至用户端，使用户端根据自定义阶段的信息获知YY航司支持附加服务销售流程E与F，ZZ航司支持附加服务销售流程A、B、C与D。从而可以有效地控制用户端操作界面的流程引导展示。

(7)根据流程引导，用户完成后续的销售流程。

综上可知，本发明公开了一种标准化航空公司附加服务销售的方法，通过调用的航班查询接口接收用户端发送的航班查询请求，并将该航班查询请求发送至航空公司，接收航空公司在预设时间段内返回的满足航班查询条件的可用航班信息，并将可用航班信息聚合成新分销能力NDC标准的返回结果报文，在返回结果报文中预留的自定义节点中，添加标准化的引导附加服务销售的自定义子节点及相应报文体，得到航班查询结果报文，并将航班查询结果报文通过航班查询接口发送至用户端，使用户端根据航班查询结果报文确定对目标航空公司的附加服务的发起时间和支付方式，其中，自定义子节点及相应报文体根据可用航班信息对应的目标航空公司支持的目标附加服务销售流程得到。本发明通过在返回结果报文中添加标准化的附加服务销售的引导信息，得到航班查询接口用于输出至用户端的航班查询结果报文，从而能够有效传递不同航司不同的附加服务销售流程给作为用户端的下游分销商，从而有助于减轻下游分销商因识别不同航司附加服务预订流程并进行定制开发带来的繁琐操作，使得下游分销商能够使用统一的一套处理逻辑，即可达到处理各航司不同的附加服务销售流程的目的。

需要说明的是，附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

虽然采用特定次序描绘了各操作，但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序执行来执行。在一定环境下，多任务和并行处理可能是有利的。

应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。

与上述方法实施例相对应，本发明还公开了一种标准化航空公司附加服务销售的装置。

参见图3，本发明实施例公开的一种标准化航空公司附加服务销售的装置的结构示意图，装置应用于内容聚合商Aggregator服务器，所述装置包括：

第一接收单元301，用于通过航班查询接口接收用户端发送的航班查询请求；

其中，航班查询请求中包含航班查询条件，所述航班查询条件包括：航班信息和旅客信息，所述航班信息包括但不限于：航班始发地、航班目的地、航班号和出发时间等等。所述旅客信息包括：旅客姓名、旅客身份证号等等。

需要说明的是，航班查询请求中可以包含有：航空公司名称，也可以不包含航空公司名称。

在实际应用中，通常由用户端(通常是下游分销商)向Aggregator的服务器发起航班查询(AirShopping)请求。

发送单元302，用于将所述航班查询请求转换为相应航空公司能够识别的航班查询请求，并发送至相应的航空公司；

发送单元302具体用于：当所述航班查询请求中包含待查询航空公司名称时，将所述航班查询请求发送至所述待查询航空公司名称对应的航空公司；

当所述航班查询请求中不包含所述待查询航空公司名称时，将所述航班查询请求发送至所述Aggregator服务器关联的所有的航空公司。

需要说明的是，发送至航空公司的航班查询请求的格式为该航空公司能够识别的格式。因此，在将航班查询请求发送至航空公司之前，需要将航班查询请求转换成航空公司能够识别的格式，并将格式转换后的航班查询请求发送至对应的航空公司。

第二接收单元303，用于接收所述航空公司在预设时间段内返回的满足所述航班查询条件的可用航班信息；

其中，可用航班信息中包括但不限于：航空公司名称、航班始发地、航班目的地、航班号和出发时间等等。

本实施例中所述航空公司可以为一个或是多个。

当在预设时间段内未接收到任何航空公司返回的满足所述航班查询条件可用航班信息时，输出航班查询失败的提示信息。

需要说明的是，本发明中仅将在预设时间段内返回的满足航班查询条件的可用航班信息作为有效航班信息，将在预设时间段外返回的满足航班查询条件的可用航班信息，或是不满足航班查询条件的可用航班信息，均作为无效航班信息。

聚合单元304，用于将接收到的所有的所述可用航班信息聚合成新分销能力NDC标准的返回结果报文，其中，在所述返回结果报文中预留了自定义节点；

准备工作1：设计返回结果报文

在IATA NDC报文(即本实施例中的返回结果报文)的定义中，预留了自定义节点，在自定义节点之下允许将额外返回给用户(通常是下游分销商)的信息进行记录，从而使得返回结果报文中可以携带更多返回给用户的参数。

在自定义节点之下，设计表2所示的报文体，自定义节点之下的报文体包括：自定义报文体片段以及相对应的节点及字段说明。

需要说明的是，本实施例聚合得到NDC标准的返回结果报文的过程可参见现有成熟方案，此处不再赘述。

添加单元305，用于在所述自定义节点中添加标准化的引导附加服务销售的自定义子节点及相应报文体，得到航班查询结果报文，其中，所述自定义子节点及相应报文体根据所述可用航班信息对应的目标航空公司支持的目标附加服务销售流程得到；

可以理解，在自定义节点中添加标准化的引导附加服务销售的自定义子节点及相应报文体之前，首先需要生成自定义子节点及相应报文体。因此，装置还可以包括：

生成单元，用于从预先存储的航空公司和支持的附加服务销售流程的对应关系中，查找所述目标航空公司支持的目标附加服务销售流程；基于所述目标附加服务销售流程，生成所述目标航空公司的引导附加服务销售的所述自定义子节点及相应报文体。

其中，生成单元的具体工作原理，请参见方法实施例对应部分，此处不再赘述。

需要说明的是，本发明在执行标准化航空公司附加服务销售的过程之前，做了一些前置准备工作。

准备工作2：Aggregator的服务器对各航空公司支持的附加服务销售流程预先进行了解，并将航空公司和支持的附加服务销售流程以对应关系的形式记录在数据表或预先编写的程序块中。

返回单元306，用于将所述航班查询结果报文通过所述航班查询接口返回至所述客户端，使所述用户端根据所述航班查询结果报文确定对所述目标航空公司的附加服务的发起时间和支付方式。

其中，支付方式包括：即时支付和延时支付。

本实施例中，用户端接收到航班查询结果报文后，根据航班查询结果报文就可以确定对目标航空公司的附加服务的发起时间和支付形式，从而可以有效地控制用户端操作界面的流程引导展示，使得用户端根据流程引导完成后续的附加服务销售流程。

需要说明的是，在实际应用中，装置还可以包括：

输出单元，用于当在所述预设时间段内未接收到任何航空公司返回的满足所述航班查询条件的可用航班信息时，输出航班查询失败的提示信息。

综上可知，本发明公开了一种标准化航空公司附加服务销售的装置，通过调用的航班查询接口接收用户端发送的航班查询请求，并将该航班查询请求发送至航空公司，接收航空公司在预设时间段内返回的满足航班查询条件的可用航班信息，并将可用航班信息聚合成新分销能力NDC标准的返回结果报文，在返回结果报文中预留的自定义节点中，添加标准化的引导附加服务销售的自定义子节点及相应报文体，得到航班查询结果报文，并将航班查询结果报文通过航班查询接口发送至用户端，使用户端根据航班查询结果报文确定对目标航空公司的附加服务的发起时间和支付方式，其中，自定义子节点及相应报文体根据可用航班信息对应的目标航空公司支持的目标附加服务销售流程得到。本发明通过在返回结果报文中添加标准化的附加服务销售的引导信息，得到航班查询接口用于输出至用户端的航班查询结果报文，从而能够有效传递不同航司不同的附加服务销售流程给作为用户端的下游分销商，从而有助于减轻下游分销商因识别不同航司附加服务预订流程并进行定制开发带来的繁琐操作，使得下游分销商能够使用统一的一套处理逻辑，即可达到处理各航司不同的附加服务销售流程的目的。

需要说明的是，装置实施例中，描述于本公开实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，单元的名称在某种情况下并不构成对该单元本身的限定，例如，第一获取单元还可以被描述为“获取至少两个网际协议地址的单元”。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。