(19)中华 人民共和国 国家知识产权局 (12)发明 专利申请 (10)申请公布号 (43)申请公布日 (21)申请 号 202111580769.1 (22)申请日 2021.12.2 2 (71)申请人 成都智元汇信息技 术股份有限公司 地址 610000 四川省成 都市中国 （四川） 自 由贸易试验区成都 高新区吉泰五路88 号3栋26层1号 (72)发明人 吕博　陈思宇　何东树　邹世清　 唐波　 (74)专利代理 机构 成都蓉创智汇知识产权代理 有限公司 51276 代理人 赵雷 (51)Int.Cl. G06Q 10/10(2012.01) G06Q 20/08(2012.01) G06Q 50/26(2012.01)G06Q 50/30(2012.01) (54)发明名称 一种基于SDK补登的方法、 地铁客户端及系 统 (57)摘要 本发明公开了一种基于SDK补登的方法、 地 铁客户端及系统， 应用于城市B的地铁客户端中 的SDK， 所述SDK用于与城市A的互联互通服务器 进行通信， 具体包括以下步骤： S1、 获取城市A 的 待补登行程； S2、 根据所述城市A的待补登行程向 所述城市A的互联互通服务器发送补登请求； S3、 接收城市A的互联互通服务器返回的补登结果， 所述补登结果生成过程为： 城市A的MLC系统根据 城市A的互联互通服务器转送的补登请求， 进行 补登、 融对处理， 并将补登结果通过城市A的互联 互通服务器保存并返回至SDK。 本发明通过解决 在“二维码通行 ”互联互通过程中的如何补登的 问题， 以省去直接下载新的APP或异地现场补登 的过程， 进 而实现城市 之间互联互通。 权利要求书3页 说明书8页 附图4页 CN 114282892 A 2022.04.05 CN 114282892 A 1.一种基于SDK补登的方法， 其特征在于， 应用于城市B的地铁客户端中的城市A的SDK， 所述城市A的SDK用于通过城市A的互联互通服务器与城市A的MLC系统进行通信， 当用户通 过城市B的地铁客户端唤起城市A的SDK， 并进入城市A的SDK的行程列表页面选择城市A的待 补登行程时， 由所述城市A的S DK执行以下步骤： S1、 获取城市A的待补登行程； S2、 根据所述城市A的待补登行程通过所述城市A的互联互通服务器向城市A的MLC系统 发送补登请求； S3、 接收城市A的互联互通服务器转发的由城市A的MLC系统进行行程补登、 行程融对后 生成的补登结果。 2.根据权利要求1所述的一种基于SDK补登的方法， 其特征在于， 所述城市A的SDK通过 城市A的互联互通服务器、 城市A的MLC系统与支付渠道进行通信， 所述城市A的SDK向城市A 的互联互通服务器发送查询订单请求； 接收城市A的互联 互通服务器返回的订单结果， 所述 订单结果为由城市A的MLC系统进行行程补登、 行程融对和扣费处理后生成的补登结果， 以 及由城市A的MLC系统进行补登、 融对后向支付渠道发起扣费请求后， 推送的由支付渠道异 步回调的扣费结果组成。 3.根据权利要求2所述的一种基于SDK补登的方法， 其特征在于， 还包括， 所述城市A的 MLC系统的行程补登、 行程融对为： 根据所述城市A的待补登行程， 确定城市A的待补登行程中的补登信息是否有效； 当所述补登信息有效时， 基于所述补登信息结合所述城市A 的待补登行程进行行程订 单匹配。 4.根据权利要求3所述的一种基于SDK补登的方法， 其特征在于， 还包括， 所述确定补 登 信息是否有效具体包括： 确认所述城市A的待补登行程是否超过 预设的有效期限： 若超过， 则确认所述城市A的待补登行程无效； 若未超过， 则确认用户的补登请求是否超过 预设次数： 若超过， 则确认所述城市A的待补登行程无效； 若为超过， 则确认所述城市A的待补登行程有效。 5.根据权利要求1所述的一种基于SDK补登的方法， 其特征在于， 还包括， 所述城市A的 SDK还用于接收城市A的互联 互通服务器每隔预设周期下发的提醒补登的消息， 并根据所述 提醒补登的消息展示需要补登的乘车记录与截止时间。 6.根据权利要求5所述的一种基于SDK补登的方法， 其特征在于， 所述提醒补登的消息 由所述城市A的互联互通服务器对行程订单 的进行查询， 当发现用户的行程订单没有进站 或出站的消息时生成。 7.根据权利要求1所述的一种基于SDK补登的方法， 其特征在于， 所述城市A的SDK在进 行补登前需完成异地乘车二维码服 务的支付渠道 代扣签约， 具体包括以下步骤： Sa、 根据异地乘车二维码的请求， 向城市A的互联互通服务器发送查询是否签约的请 求； Sa、 根据城市A的乘车二维码的请求， 向城市A的互联互通服务器发送查询是否签约的 请求；权　利　要　求　书 1/3 页 2 CN 114282892 A 2Sb、 接收城市A的互联互通 服务器返回的签约信息； Sc、 若所述签约信息指示用户未完成支付渠道代扣签约， 则 跳转签约页面， 显示可签约 的支付渠道； Sd、 获取用户选定的支付渠道， 根据所选定的支付渠道对应的签约 流程及要求， 跳转到 所述选定的支付渠道的支付签约页面； Se、 接收由支付渠道通过城市B的地铁客户端同步返回的签约结果； Sf、 通过所述城市A的互联互通 服务器向支付渠道发送查询签约结果的请求； Sg、 通过所述城市A的互联互通 服务器接受所述支付渠道返回的结果。 8.根据权利要求7所述的一种基于SDK补登的方法， 其特征在于， 当城市B的地铁客户端 的用户成功完成支付渠道的支付代扣签约后， 所述城市A的SDK还包括支付代扣解约的处 理， 具体包括以下步骤： Sa、 获取待解约的支付方式； Sb、 根据所述待解约的支付方式， 通过城市A的互联互通服务器向支付渠道发送解约请 求； Sc、 向所述城市A的互联互通 服务器发送查询解约结果的请求； Sd、 接收城市A的互联互通 服务器返回的 由支付渠道 异步回调的解约结果。 9.一种基于S DK补登的地铁客户端,其特 征在于， 包括： 城市B的地铁客户端， 集成在城市B的地铁客户端中的一个或多个其 他城市的S DK； 所述城市B的地铁客户端用于： 当用户通过城市B的地铁客户端进入异地乘车二维码界 面时， 弹出一个或多个其他城市列表的页面， 获取一个或多个其他城市列表的页面的触发 信号， 进入指定的城市的乘车二维码页面， 唤起指定的城市的S DK； 所述一个或多个其他城市的SDK用于： 当用户通过城市B的地铁客户端唤起指定的城市 的SDK， 并进入所述指定的城市 的SDK的行程列表页面选择指定的城市 的待补登行程时， 通 过所述指 定的城市的互联 互通服务器与所述指 定的城市的MLC系统进 行通信， 根据权利1 ‑8 任意所述的一种基于S DK补登的方法， 进行补登。 10.一种基于S DK补登的系统， 其特 征在于， 包括： 城市B的地铁客户端， 集成在城市B的地铁客户端中的一个或多个其他城市的SDK， 一个 或多个城市的互联互通 服务器， 其中： 所述城市B的地铁客户端用于： 当用户通过城市B的地铁客户端进入异地乘车二维码界 面时， 弹出一个或多个其他城市列表的页面， 获取一个或多个其他城市列表的页面的触发 信号， 进入指定的城市的乘车二维码页面， 唤起指定的城市的S DK； 所述一个或多个其他城市的SDK用于： 当用户通过城市B的地铁客户端唤起指定的城市 的SDK， 并进入所述指定的城市 的SDK的行程列表页面选择指定的城市 的待补登行程时， 通 过所述指 定的城市的互联 互通服务器与所述指 定的城市的MLC系统进 行通信， 根据权利1 ‑8 任意所述的一种基于S DK补登的方法， 进行补登； 一个或多个城市的互联互通服务器用于： 实现指定的城市的SDK与指定的城市的MLC系 统之间的通信； 当用户通过城市B的地铁客户端进入城市B的行程列表页面并选择城市A的待补 登行程 时， 通过城市B的服务器与城市B的MLC系统进行通信， 进行补登,数据的路线为： 城市B的地权　利　要　求　书 2/3 页 3 CN 114282892 A 3