用于减少贸易保险和融资中的欺骗的系统和方法
阅读：592发布：2020-05-18
专利汇可以提供用于减少贸易保险和融资中的欺骗的系统和方法专利检索，专利查询，专利分析的服务。并且本 发明 涉及一种用于提供贸易保险和融资的系统和方法。系统包括中央 控制器 ，其被布置与一个或多个 数据库 相通信从而以 电子 方式从数据库获得信息，其中该信息包括发票；以及 区 块 链 中心，其可操作地连接到中央控制器，用于将信息从中央控制器流通到一个或多个平台。其中提货单也被编码和验证的区块链中心能够基于来自一个或多个平台的 请求 生成哈希响应输出，并且其中，如果发票满足至少一个预定标准，则中央控制器向承保方提供发票用于保险，并向贷款方提供发票用于为该发票融资。，下面是用于减少贸易保险和融资中的欺骗的系统和方法专利的具体信息内容。
1.一种用于促进贸易保险和融资的系统，包括：
中央控制器，其被布置为与一个或多个数据库相通信，以从所述数据库以电子方式获得信息，其中，所述信息包括发票；以及
区块链中心，其可操作地与所述中央控制器连接，用于将来自所述中央控制器的所述信息流通到一个或多个平台，所述区块链中心能够基于来自所述一个或多个平台的请求生成哈希响应输出，
其中，如果所述发票满足至少一个预定标准，则所述中央控制器向承保方提供所述发票以用于保险，以及向贷款方提供所述发票以用于融资。
2.根据权利要求1所述的系统，其中，所述数据库中的一个数据库是与所述中央控制器进行数据通信的卖方设备，供卖方将发票提交给所述中央控制器。
3.根据权利要求1或2所述的系统，其中，所述数据库中的一个数据库是与所述中央控制器进行数据通信的买方设备，供买方与希望和其进行交易的卖方建立联系。
4.根据任一项前述权利要求所述的系统，其中，所述数据库中的一个数据库是与所述中央控制器进行数据通信的承保方设备，以接收由所述中央控制器发送的所述发票。
5.根据任一项前述权利要求所述的系统，其中，所述数据库中的一个数据库是与所述中央控制器进行数据通信的验证方设备，用于验证发送到所述中央控制器的信息和从所述中央控制器发送的信息，包括验证所述发票是否满足各种标准以及验证商品销售的真实性。
6.根据任一项前述权利要求所述的系统，其中，所述数据库中的一个数据库是与所述中央控制器进行数据通信的贷款方设备，供贷款方使用以查看用于决定是否对发票进行融资的信息。
7.根据任一项前述权利要求所述的系统，其中，所述中央控制器包括从包括处理器、存储器、通信端口、输入设备、输出设备和存储设备的组中选择的一个或多个部件。
8.根据任一项前述权利要求所述的系统，其中，所述一个或多个数据库中的每一个数据库包括用于标识所述数据库的信息。
9.根据任一项前述权利要求所述的系统，其中，将一个或多个提货单提交给所述中央控制器。
10.根据权利要求9所述的系统，其中，每个提货单被编码为将链接到一个或多个其他提货单的区块链。
11.根据权利要求10所述的系统，其中，对所述发票是否满足所述预定标准的验证是通过将所述一个或多个提货单与外部数据库中的记录进行匹配来执行的。
12.根据权利要求11所述的系统，其中，成功的验证引起对所述发票的批准。
13.根据权利要求1所述的系统，其中，所述系统可操作以与从包括以下各项的组中选择的一个或多个程序一起工作：双因素认证、光学字符识别、机器学习、数据库管理、数据分析、商业智能、人工智能和应用编程接口。
14.根据权利要求1所述的系统，其中，所述系统包括用于在与特定发票相关联的买方未支付时自动处理保险索赔的处理器。
15.根据权利要求1所述的系统，其中，所述区块链中心包括与所述一个或多个平台通信的分布式消息传送系统，用于将所述信息从所述中央控制器流通到所述一个或多个平台。
16.一种用于提供贸易融资的方法，包括以下步骤：
将信息存储在一个或多个数据库中，其中，所述信息包括发票；以及
将所述信息传送到可操作地连接到区块链中心的中央控制器，所述区块链中心生成用于在一个或多个平台之间流通的哈希响应输出；以及
如果所述发票满足至少一个预定标准，则向贷款方提供所述发票以便对所述发票进行融资。
17.根据权利要求16所述的方法，其中，存储在所述一个或多个数据库中的信息由选自包括以下各项的组中的一个或多个设备提供：卖方设备、买方设备、承保方设备、验证方设备和贷款方设备。
18.根据权利要求16或17所述的方法，还包括使用光学字符识别以从所述发票中提取信息的步骤。
19.根据权利要求16-18中任一项所述的方法，还包括验证与所述发票相关的商品销售的真实性的步骤。
20.根据权利要求16-19中任一项所述的方法，还包括在所述发票未支付时自动处理保险索赔的步骤。
21.一种用于促进为贸易融资获得保险的平台，所述平台包括：
存储器，其用于存储关于卖方和所述卖方希望与其交易的买方的信息；
处理器，其用于将所述卖方与承保方和/或特定贷款方进行匹配和标记；
其中，所述卖方、所述买方、所述承保方和所述贷款方之间的交易是记录在区块链和/或分布式分类账上的。
22.根据权利要求21所述的平台，其中，所述处理器基于选自包括以下各项的组中的一条或多条信息来执行所述匹配和所述标记：位置、行业、营业额、平均发票价值、定价、支付条款。
用于减少贸易保险和融资中的欺骗的系统和方法
技术领域
[0001] 本发明涉及一种用于减少特别是贸易融资交易中的欺骗的系统和方法，并且尤其涉及贸易信用保险。
背景技术
[0003] 在计算机化交易中，卖方经常在获得此样商品的付款之前将该商品发送给买方。卖方在收到商品的付款之前可能会等待很长一段时间。例如，卖方可能需要等待30天、60天、90天、120天，等等，具体天数取决于交易条款。与此同时，卖方可能会在商品中锁定了大量资金。例如，卖方可能已经不得不花费100万美元用于生产商品的原材料和劳动力。在卖方收到付款之前，这笔资金被捆绑起来，并且不能用于其他运营，例如生产新商品。因此，卖方通常有兴趣在预期的或商定的付款日期之前接收由买方支付的资金的至少一部分。
[0004] 期望交易中的付款的卖方具有“贸易应收款”(也称为“应收账款”)。贸易应收款是具有价值的，特别是如果买方的信誉良好。因此，卖方可以使用贸易应收款作为抵押品寻求贷款或其他资金。接收这种贷款可以被称为接收“贸易融资”或类似的术语。卖方可以将贸易融资的收入用作“营运资金”，以维持持续的运营和/或生产。继而，贷款方获得贷款利息并最小化其风险。如果卖方后来就贷款违约，贷款方可以在买方最终支付货款时收回贷款金额的全部或一部分。
[0005] 卖方(可能是贷款方)的一个风险是买方不付款。例如，买方可能在付款到期之前破产。在这种情况下，卖方可能遭受投入商品的资金损失。如果卖方使用应收款作为抵押品进行了贷款，则抵押品的价值可能会减少或被破坏，并且贷款方可能无法收回其贷款。
[0006] 因此，卖方可以针对买方的信誉寻求保险。如果买方破产，无法偿还债务，和/或无法向卖方付款和/或因其他原因未能向卖方付款，“贸易信用承保方”可以赔付。
[0007] 卖方(可能是贷款方)的另一个风险是商品没有完好地到达买方处。例如，商品可能丢失、被盗、损坏等。在这种情况下，买方可能拒绝付款并且卖方将遭受投入商品的资金损失。如果卖方使用应收款作为抵押品进行了贷款，则抵押品的价值可能会减少或被破坏，并且贷款方可能无法收回其贷款。
[0008] 因此，卖方可以针对销售商品的丢失、被盗或损坏寻求保险。即使商品丢失、被盗等，该保险也可以允许卖方获得所售商品的赔偿。
[0009] 根据一些估计，对贸易融资的需求是很高的。但是，许多期望贸易融资的卖方无法获得它。根据一些估计，在2015年，价值近1.4万亿美元的贸易融资被期望但不可获得。许多不能获得期望融资的卖方是中小型企业(“SME”)。这种“贸易融资缺口”给卖方带来了困难，并且由于缺乏营运资金而可能会损失生产力。此外，贸易融资缺口使贷款方损失了以利息形式获得重大收入的机会。
[0010] 许多卖方没有获得贸易融资的一个可能原因是贷款方担心卖方会进行欺骗。当卖方相对较小或未知时，这种担心可能会被放大。卖方可以通过对同一销售寻求多次贸易融资来进行欺骗。卖方可能会对贷款违约，然后多个贷款方发现他们正在寻求使用相同的抵押品来收回付款，这是不够的。当然，卖方也可能以各种其他方式进行欺骗。
[0011] 许多卖方，特别是中小型企业或SME无法获得贸易融资的另一个可能原因是，贷款方要么收取高利率，要么在没有贸易信用保险保护的情况下，贷款方不愿有时以较低的利率放贷。贸易信用保险通常非常昂贵，并且保费是根据卖方的年营业额计算的。此外，贸易信用保险提供方不愿承保营业额较小的卖方，因为承保小的卖方的成本相对于收益而言过高。
[0012] 因此，需要通过降低卖方中欺骗的可能性以及为提供方和卖方更有效、更安全和更低成本地提供贸易信用保险来增加对贸易融资的获取。
发明内容
[0014] 大多数贷款方需要某种形式的担保以对发票进行融资。该担保可以是以贸易信用保险的形式。然而，对于较小的公司，贸易信用保险保费率通常过高，并且承保方通常不迎合这些较小的公司因为牵涉高昂的管理成本。因此，本发明允许小型企业通过贸易信用保险获取发票融资。
[0015] 根据本发明的一个方面，提供了一种用于促进贸易保险和融资的系统，该系统包括：被布置与一个或多个数据库相通信从而以电子方式从数据库获得信息的中央控制器，其中，信息包括发票；和可操作地与该中央控制器连接的区块链中心，用于将信息从中央控制器流通到一个或多个平台，区块链中心能够基于来自一个或多个平台的请求生成哈希(hash)响应输出，其中如果发票满足至少一个预定标准，则中央控制器向承保方提供发票以用于保险，并向贷款方提供发票以用于融资。
[0016] 本发明提供了一种将企业与承保方和贷款方两者联系起来的经济有效、安全和高效的方式。
[0017] 通过本发明，不同方可以交互以向企业提供对其交易进行保护和融资所需的要求。由于平台利用区块链/分布式分类账技术，欺骗的风险(例如双发票融资)也可以得到缓解。
[0018] 优选地，数据库之一是与中央控制器进行数据通信的卖方设备，供卖方向中央控制器提交发票。
[0019] 如果数据库之一是与中央控制器进行数据通信的买方设备，供买方与希望和之进行交易的卖方进行交易，这是有优势的。
[0020] 更有优势地，数据库之一是与中央控制器进行数据通信的承保方设备，以接收由中央控制器发送的发票。
[0021] 如果数据库之一是与中央控制器进行数据通信的验证方设备，用于验证发送到中央控制器的信息和从中央控制器发送的信息，包括验证发票是否满足各种标准并验证商品销售的真实性，这是优选的。
[0022] 如果数据库之一是与中央控制器进行数据通信的贷款方设备，供贷款方查看信息以确认是否对发票进行融资，这也是优选的。
[0023] 有优势地，中央控制器包括从包括处理器、存储器、通信端口、输入设备、输出设备和存储设备的组中选择的一个或多个部件。
[0024] 优选地，一个或多个数据库中的每个数据库都包含用于识别该数据库的信息。
[0025] 更优选地，将一个或多个提货单提交到中央控制器。
[0026] 如果每个提货单都被编码为区块链以链接到一个或多个其他提货单，这是优选的。
[0027] 如果通过将一个或多个提货单与外部数据库中的记录匹配来执行发票是否满足预定标准的验证，这是有优势的。
[0028] 优选地，成功的验证使得发票获得批准。
[0030] 优选地，该系统包括处理器，其用于在与特定发票相关联的买方未支付时自动处理保险索赔。
[0031] 优选地，区块链中心包括与一个或多个平台通信的分布式消息传送系统，用于将信息从中央控制器流通到一个或多个平台。
[0032] 根据本发明的另一个方面，存在一种用于提供贸易融资保险的方法，该方法包括以下步骤：将信息存储在一个或多个数据库中，其中该信息包括发票；以及将信息传送到可操作地连接到区块链中心的中央控制器，所述区块链中心产生用于在一个或多个平台之间流通的哈希响应输出；和
[0033] 如果发票满足至少一个预定标准，则向贷款方提供发票以便对发票进行融资。
[0034] 优选地，存储在一个或多个数据库中的信息由选自包括以下各项的组中的一个或多个设备提供：卖方设备、买方设备、承保方设备、验证方设备和贷款方设备。
[0035] 使用光学字符识别从发票中提取信息。
[0036] 优选地，该方法还包括验证与发票相关的商品销售的真实性的步骤。
[0037] 优选地是，该方法还包括在发票未支付时自动处理保险索赔的步骤。
[0038] 根据本发明的再一个方面，存在一种促进为贸易融资取得保险的平台，该平台包括：存储关于卖方和该卖方希望与其交易的买方的信息的存储器；用于将卖方与承保方和/或特定贷款方进行匹配和标记的处理器；其中卖方、买方、承保方和贷款方之间的交易被记录在区块链和/或分布式分类账上。
[0039] 优选地，处理器基于选自包括以下各项的组中一条或多条信息来执行匹配和标记：位置、行业、营业额的量、平均发票价值、定价、支付条款。
[0040] 因此，本发明能够在单个平台中为每笔交易提供贸易信用保险，该平台还提供了贷款途径。
[0041] 贸易融资和贸易保险通常仍基于纸张，这在当今的数字经济中是不方便的。计算机化发明与当前平台的区别在于其能够将交易的不同方的各种系统和接口集成。这允许从一个系统到另一个系统的数据传输更快和更安全。这包括与会计平台、保险平台和贷款方系统的集成。
[0042] 通过记录来自不同用户的数据、用户行为的模式和交易的模式，本发明提供了关于风险管理、现金流管理，以及甚至创收的更好的见解。例如，信用风险不仅仅基于宏观经济、行业和金融风险，还能够考虑交易各方的支付和风险规避模式。附图说明
[0043] 图1描绘了根据各种实施例的系统。
[0044] 图2描绘了根据各种实施例的中央控制器。
[0045] 图3描绘了根据各种实施例的卖方设备。
[0046] 图4描绘了根据各种实施例的买方设备。
[0047] 图5描绘了根据各种实施例的承保方设备。
[0048] 图6描绘了根据各种实施例的验证方设备。
[0049] 图7描绘了根据各种实施例的贷款方设备。
[0050] 图8描绘了根据各种实施例的卖方数据库。
[0051] 图9描绘了根据各种实施例的买方数据库。
[0052] 图10描绘了根据各种实施例的贷款方数据库。
[0053] 图11描绘了根据各种实施例的承保方数据库。
[0054] 图12描绘了根据各种实施例的验证方数据库。
[0055] 图13描绘了根据各种实施例的日志。
[0056] 图14描绘了根据各种实施例的由卖方执行的过程。
[0057] 图15描绘了根据各种实施例的由承保方执行的过程。
[0058] 图16描绘了根据各种实施例的由贷款方执行的过程。
[0059] 图17描绘了根据各种实施例的由验证方执行的过程。
[0060] 图18描绘了平台的概要流程及其与可兼容技术的集成。
[0061] 图19描绘了共享信息的处理流程。
[0062] 图20描绘了光学字符识别和机器学习的使用。
[0063] 图21描绘了该平台与区块链/分布式分类帐技术的集成。
[0064] 图22描绘了可以使用该平台生成的商业智能。
[0065] 图23描绘了双因素认证(2FA)的使用。
[0066] 图24描绘了卖方-贷款方-承保方流程的匹配。
具体实施方式
[0067] 各种实施例包括用于促进获取贸易保险和贸易融资的系统和方法。例如，卖方可以为其已售出但尚未收到针对其的付款的商品获取贸易融资。贷款方(诸如银行)可以提供贸易融资。承保方可以针对买方违约而提供信用保险。承保方还可以针对商品(例如运输中的商品)丢失、被盗、损坏等提供保险。验证方可以验证买方和卖方之间声称的销售交易是真实的和/或合法的。日志可以保留买方和卖方之间的交易记录。日志可以附加地或可替代地保留贸易融资交易的记录。因此，日志可以减少买方和卖方之间的同一交易不止一次地被用于获得贸易融资的可能性。
[0068] 根据各种实施例，卖方可受益于获取更多的贸易融资和/或更快速地获取贸易融资。因此，卖方可以获取更多的营运资金和/或更快速地获取营运资金，以资助正在进行的运营、维持或提高生产力等。
[0069] 根据各种实施例，贷款方可以从扩大的借款人池中受益。贷款方也可以受益于其贷款的风险缓解。一些缓解可能来自于买家的信用保险。例如，即使买方破产且贸易应收款(例如抵押品)损失其价值，贷款方仍可从信用保险的赔付中收回其贷款。一些缓解可能来自于针对销售商品的丢失、被盗、损坏等的保险。一些缓解可能是来自于日志或多个日志减少了对于同一买/卖交易向卖方提供重复融资的可能性。一些缓解可能是来自于验证过程验证了买/卖交易的存在或真实性。
[0070] 日志
[0071] 在各种实施例中，日志可以提供交易的记录。日志可以包括一个或多个先前交易的记录。日志可以包括通过系统发生的全部先前交易的记录。
[0072] 根据各种实施例，日志可以采取各种形式。日志可以采取纸质文件或多个纸质文件、纸带、计算机文件、电子文件、电子记录、数据库、分布式数据库、区块链、区块链数据库，和/或其他形式或多种形式的组合。在各种实施例中，可以存在现有的日志的多个实例或副本。在各种实施例中，一个日志可以被储存在单独的位置。在各种实施例中，一个日志可以被存储在多个位置、分布在多个位置等。
[0073] 在各种实施例中，日志可以存储关于交易的信息。所述信息可以包括以下各项中的一项或多项：(a)买方的名称或其他标识符；(b)卖方的名称或其他标识符；(c)承保方的名称或其他标识符；(d)贷款方的名称或其他标识符；(e)被买/被卖的商品(例如，大豆、米、咖啡等)；(f)正在被买的商品的卖出数量(例如，1000立方公吨)；(g)运送港/地点；(h)交付港/地点；(i)运送日期；(j)交付日期；(k)商品在运送和/或交付时的性质、质量和/或状况；(l)买/卖商品的支付条款；(m)商品的付款金额；(n)付款到期的日期；(l)请求的贸易融资的金额；(n)收到的贸易融资的金额；(o)偿还贸易融资的条款；(p)商品的承运方；(p)验证方的名称或其他标识符；和/或任何其他信息。
[0074] 在各种实施例中，关于交易的信息可以包括来自提货单的信息。提货单可以包括作为交易的一部分正在被运送的商品清单。存储在日志中的信息可以包括提货单、扫描的提货单副本、从提货单导出的信息(例如，从提货单经由光学字符识别导出的信息)，和/或关于提货单的任何其他信息。日志可以存储来自提货单的部分或全部信息。日志可存储与提货单相关的任何印章、图章或其他批准。
[0075] 在各种实施例中，使用新交易来更新日志。例如，当有新交易时，可以将新记录、新数据库条目、新文件等添加到该日志。在各种实施例中，日志的更新可以包括关于一个或多个先前交易的信息。在各种实施例中，日志的更新可以包括从一个或多个先前交易中导出的信息。在各种实施例中，日志的更新可以包括从全部先前交易中导出的信息。
[0076] 在各种实施例中，基于一个或多个先前交易生成哈希。在各种实施例中，基于全部先前交易生成哈希。哈希可以是由先前交易的变换(例如数学的、算法的等)产生的字符序列、码等。在各种实施例中，每个新记录可以包括先前交易的哈希。
[0077] 在各种实施例中，希望验证日志完整性的一方可以检查存储在新记录中的、与先前交易有关的信息，并且可以将其与先前交易的实际记录进行比较。例如，该方可以确定是否可以通过对日志中列出的先前记录进行适当变换来获得与新记录一起存储的哈希。如果该转换不产生该哈希(或以其他方式显示与新记录中存储的信息的一致性)，则该方可能有理由怀疑先前记录已从该日志中删除，或以其他方式被改变。这可能表示指示欺骗企图，即卖方试图为同一买/卖交易接收两次融资，并因此试图隐藏该同一交易的日志中的先前记录。
[0078] 区块链
[0079] 如本文所使用的，区块链是被认为有效的交易的链接链。该链可以包括一个或多个有效的交易的“区块”。每个区块可以包括到先前区块的链接或引用。该链可以是先前区块的哈希。
[0080] 在各种实施例中，区块链可以被实现为分布式或去中心化式系统。区块链可以被实现为分布式数据库。每个区块链可以被实现为记录，且链或哈希可以驻留在该记录的字段中。
[0081] 当使用新区块(或多个新区块)来更新区块链时，可以在数据库的第一实例或主机内发生该更新。然后，可以将该更新发送到数据库的其他实例或主机，以便使得利用新区块更新全部实例。
[0082] 区块链可以包括评分系统，当存在并发的、冲突的更新时，该评分系统将优先考虑区块链的一个版本。
[0083] 由于区块链包括链接在一起的、有效交易的链，因此在没有检测到这种移除的情况下，可能难以从该链中移除交易或交易的区块。
[0084] 公开号为20160027229、名称为“用于安全接收和计数选举中的投票的系统和方法”、并于2016年1月28日公布的美国专利中描述了区块链技术的说明性实现方式，为了所有目的，其全部内容通过引用并入本文。
[0085] 提货单
[0086] 如本文所使用的，“提货单”可以包括由确认收到商品或物品的运送的托运人或承运人所签发的文件。
[0087] 虽然本文描述的各种实施例涉及提货单，但是可以预期的是，在各种实施例中，可以采用具有类似或相关功能的其他文档、记录、收据、确认等。例如，各种实施例可以预期使用运输文档、收据、或其他文档、或其他确认。
[0088] 系统
[0089] 参考图1，根据各种实施例示出了系统100。中央控制器105可以与卖方设备110、买方设备115、承保方设备120、验证方设备125和贷款方设备130相通信。
[0090] 如本文所使用的，“设备”可以包括计算设备、电子设备、工作台、个人计算机、服务器、云、云服务器、笔记本电脑、平板电脑、触摸屏设备、平板、个人数字助理、智能手机、蜂窝电话、iPhoneTM、AndroidTM电话、iPadTM、iPodTM、智能手表、互联网设备、分布式服务器、分布式计算机、分布式云服务器、传真机、电话或任何其他合适的设备。在各种实施例中，设备可以包括两个或更多模块或部件。在各种实施例中，设备可以是机械设备、机电设备、或任何其他合适的设备。
[0091] 如本文所使用的，中央控制器可以是设备。中央控制器可以是服务器、云服务器、分布式服务器，或任何其他合适的设备。
[0092] 如将理解的，系统100表示根据一些实施例的系统，但是在各种实施例中其他的布置、配置等是预期的。在各种实施例中，可以存在更多或更少的设备、多个数量的给定设备(例如多个卖方设备；例如每个对应于不同卖方的多个卖方设备)、设备之间的更多通信链路、设备之间的更少通信链路、设备之间的替代的通信链路等等。
[0093] 在各种实施例中，一个或多个设备和/或实体可以彼此通信以进行数据传输或以其他方式进行数据传输。可以经由有线通信、经由无线通信、经由蜂窝网络、经由互联网、经由EtherneTM网络、经由同轴电缆、经由光纤、经由微波链路、经由激光、经由Wi-Fi、经由蓝牙、经由近场通信，或经由任何其他合适的方式发生通信。可以经由语音、邮寄、快递、手动递送，或通过任何其他合适的方式发生通信。
[0094] 中央控制器
[0095] 参考图2，根据各种实施例示出了中央控制器105。在各种实施例中，中央控制器105可以促进贸易融资的提供。中央控制器105可以用作交易的各方的会面点、通信中心、匹配点等。中央控制器105可以促进注册、记录保存、各方遵守其各自的义务、支付、资金转移、对一方或多方的通知、关于一方或多方的反馈、保险索赔的处理，和/或任何其他合适的功能或动作。
[0097] 处理器205可以包括中央处理单元(CPU)、图形处理单元(GPU)、微控制器、控制器、数字信号处理器(DSP)、处理器或任何其他合适的部件或部件的组合。示例性的部件包括Intel XeonTM处理器、AMD OpteronTM处理器等。
[0098] 存储器210可以包括随机存取存储器(RAM)、动态随机读取存储器(DRAM)、闪存、或任何其他合适的存储器、或任何其他合适的部件。示例性的存储器制造商/供应商包括CrucialTM、SamsungTM、KingstonTM等。如将理解的，存储器210可以存储在执行根据各种实施例的一个或多个程序或一个或多个方法期间使用的数据、数值、变量、图像、文本、字符、指令、计算机代码、中间值、计算等。
[0099] 通信端口215可以包括Wi-Fi收发器、蜂窝收发器、EthernetTM端口、插座、光端口、通用串行总线(USBTM)端口、或任何其他合适的通信端口。中央控制器可以经由端口与一个或多个其他设备或其他方进行通信。中央控制器经由端口215可以访问因特网、专用网络、蜂窝网络、虚拟专用网络或任何其他网络。
[0102] 存储设备235可以包括硬盘、硬盘驱动器、硬盘驱动器阵列、光盘驱动器或任何其他设备。存储设备235可以包括云存储、网络可访问存储器(NAS)或任何其他存储。存储设备235可以存储与一个或多个实施例结合使用的数据。存储设备235可以包括一个或多个数据库。数据库可以包括卖方数据库250、买方数据库255、贷款方数据库260、承保方数据库265、验证方数据库270、日志数据库275。存储设备235还可以存储程序280。应当理解，存储装置
235也可以存储其他信息，并且可以包括其他数据库。应当理解，在各种实施例中，存储设备
235也可以包括更少的数据库。
235也可以存储其他信息，并且可以包括其他数据库。应当理解，在各种实施例中，存储设备
235也可以包括更少的数据库。
[0103] 本文将更具体地描述上述的数据库。程序数据库280可以包括用于根据一个或多个实施例进行操作的程序、计算机指令、可执行程序、代码、算法等。例如，可以使用处理器205和存储器210以及一个或多个其他部件来执行程序。
[0104] 在各种实施例中，可经由因特网、网络应用程序和/或移动应用程序访问中央控制器。例如，中央控制器可以具有相关联的统一资源定位符(URL)，在该统一资源定位符，一方可以访问来自中央控制器的信息和/或与中央控制器进行通信。
[0105] 中央控制器可以托管使用GrokTM、DjangoTM、WordPressTM、DrupalTM、JoomlaTM、JavaTM、PythonTM、PerlTM、PHPTM、Ruby on RailsTM、C、C++、Objective CTM、.NET、ASP.NET、Visual BasicTM、LinuxTM、UnixTM、SQLTM、MySQLTM、ApacheTM和/或任何其他应用程序框架、和/或任何其他数据库、和/或任何其他数据库语言、和/或任何其他计算机语言所编写的应用程序。
[0106] 在各种实施例中，一方或多方(例如，买方、卖方、贷款方、承保方、验证方)可以具有中央控制器的账户。一方可以具有用户名、标识符、电子邮件地址、帐号、密码、个人识别号、安全密钥、秘密问题，和/或登录、验证、和/或访问中央控制器的任何其他手段。
[0107] 在各种实施例中，与中央控制器相关联的用户(例如管理员、雇员等)可以访问中央控制器。这样的用户也可以拥有帐户。
[0108] 根据各种实施例，一方或多方可以访问中央控制器(例如，经由从其各自的设备登录)，并且可以一起进入交易，从而使得向卖方提供贸易融资。
[0109] 卖方设备
[0110] 参考图3，根据各种实施例示出了的卖方设备110。如本文所述，卖方设备可以是任何计算设备，包括个人计算机、平板电脑、智能手机等，或任何其他合适的设备。卖方设备110可以连接到网络，例如因特网。卖方可以利用卖方设备110来发起和参与与中央控制器和/或与一个或多个其他方的通信。
[0111] 卖方设备110可以包括处理器305、存储器310、通信端口315、输入设备320、输出设备325、和存储设备330。这些部件可以类似于上面关于中央控制器105所描述的那些部件。然而，在各种实施例中，中央控制器105和卖方设备110不需要使用相同的部件(例如，相同品牌或制造商的部件)，或甚至不需要使用类似的部件。存储设备330可以适当地包括一个或多个数据库。存储设备330可以包括用于根据一个或多个实施例进行操作的程序380。
[0112] 在各种实施例中，卖方可以是商品的制造者、生产者、加工者、精炼者、汇集者、和/或分销商。卖方可以是商品的交易者。卖方可以是商品生产商的经纪人或代表。卖方可以是任何有要销售的商品的一方。在各种实施例中，卖方是农民、种植者和/或农民会社。在各种实施例中，卖方具有待售商品。在各种实施方案中，卖方可以销售以下一种或多种：(a)大米；(b)咖啡；(c)原糖；(d)玉米；(e)大豆；(f)大豆粉。
[0113] 卖方可以从事海外贸易。例如，卖方可以将商品从一个国家出售给另一个国家的买方。卖方可以寻求利用系统100以获得销售的贸易融资。
[0114] 买方设备
[0115] 参考图4，根据各种实施例示出了买方设备115。如本文所述，买方设备可以是任何计算设备，包括个人计算机、平板电脑、智能手机等，或任何其他合适的设备。买方设备115可以连接到网络，例如因特网。买方可以利用买方设备115来发起和参与与中央控制器105和/或与一个或多个其他方进行通信。
[0116] 买方设备115可以包括处理器405、存储器410、通信端口415、输入设备420、输出设备425和存储设备430。这些部件可以类似于上面关于中央控制器105所描述的那些部件。然而，在各种实施例中，中央控制器105和买方设备115不需要使用相同的部件(例如，相同品牌或制造商的部件)，或甚至不需要使用类似的部件。存储设备430可以适当地包括一个或多个数据库。存储设备430可以包括用于根据一个或多个实施例进行操作的程序480。
[0117] 在各种实施例中，买方可以是批发商、分销商、精炼者、加工者、制造者、杂货商、超市连锁店、和/或任何商品买主。买方可以是商品的交易者。买方可以是希望占有商品的一方的经纪人、代表、或其他附属公司。
[0118] 承保方设备
[0119] 参考图5，根据各种实施例示出了承保方设备120。如本文所述，承保方设备120可以是任何计算设备，包括个人计算机、平板电脑、智能手机等，或任何其他合适的设备。承保方设备120可以连接到网络，例如互联网。承保方可以利用承保方设备120来启动和参加与中央控制器105和/或与一个或多个其他方的通信。
[0120] 承保方设备120可以包括处理器505、存储器510、通信端口515、输入设备520、输出设备525、和存储设备530。这些部件可以类似于上面关于中央控制器105所描述的那些部件。然而，在各种实施例中，中央控制器105和承保方设备120不需要使用相同的部件(例如，相同品牌或制造商的部件)，或甚至不需要使用类似的部件。存储设备530可以适当地包括一个或多个数据库。存储设备530可以包括用于根据一个或多个实施例进行操作的程序580。
[0121] 在各种实施例中，承保方可以发行信用保险，如果买方违约、破产、和/或因其他原因不就运送给买方的商品向卖方付款时，所述信用保险赔付。例如，假设买方ABC同意向卖方XYZ支付100,000美元用于原糖的运送。承保方可以向卖方XYZ提供保险单，只要卖方实际将原糖交付给买方，所述保险单将向卖方XYZ支付100,000美元中买方未支付的任何部分。当然，应当理解，保险单可以具有各种其他条款、例外等。作为提供保险单的回报，承保方可以从卖方接收一个或多个付款(例如保费)。在这个例子中，卖方可以向承保方支付1000美元的保费。可以理解，保险单和保费都可能是许多其他金额的。此外，在各种实施例中，可以为许多其他类型的交易(例如，涉及其他类型和/或数量的商品的交易)发行保险单。
[0122] 在各种实施例中，承保方可以发行损失保险，如果运送给买方的商品丢失，则该损失保险赔付。在各种实施例中，如果商品丢失、损坏、被盗、延迟和/或以其他方式受到损害，则保险单可以赔付。保险单可以向卖方(或买方)支付由于丢失、损坏等造成的商品价值的任何减少部分(例如商品丢失的总价值；例如被损坏商品的部分价值)。
[0123] 在各种实施例中，多于一个的承保方可以与一个买/卖交易一起使用。例如，一个承保方可以为买方破产提供保险单，而另一个承保方可以为丢失、损坏提供保险单。在各种实施例中，即使使用单一类型的保险，也可以使用多个承保方。例如，第一承保方可以发行最高可达第一最高金额的信用保险(例如商品价值的三分之二)，第二承保方可以发行最高可达第二最高金额信用保险(例如商品价值的三分之一)。
[0124] 在各种实施例中，保险单可以是可转让(assigned)的。受益于该保险单的被转让者可称为“损失收款人”。在各种实施例中，卖方可以将保险单转让给贷款方。在这种情况下，如果买方不支付货款，则承保方可以直接赔付贷款方。
[0125] 验证方设备
[0126] 参考图6，根据各种实施例示出了验证方设备125。如本文所述，验证方设备125可以是任何计算设备，包括个人计算机、平板电脑、智能电话等，或任何其他合适的设备。验证方设备125可以连接到网络，例如因特网。验证方可以利用验证方设备125来启动和参与与中央控制器105和/或与一个或多个其他方的通信。
[0127] 验证方设备125可以包括处理器605、存储器610、通信端口615、输入设备620、输出设备625、和存储设备630。这些部件可以类似于上面关于中央控制器105所描述的那些部件。然而，在各种实施例中，中央控制器105和验证方设备125不需要使用相同的部件(例如，相同品牌或制造商的部件)，或甚至不需要使用类似的部件。存储设备630可以适当地包括一个或多个数据库。存储设备可以包括用于根据一个或多个实施例进行操作的程序680。
[0128] 贷款方设备
[0129] 参考图7，根据各种实施例示出了贷款方设备130。如本文所述，贷款方设备130可以是任何计算设备，包括个人计算机、平板电脑、智能手机等，或任何其他合适的设备。贷款方设备130可以连接到网络，例如因特网。贷款方可以利用贷款方设备130来发起和参与与中央控制器105和/或与一个或多个其他方的通信。
[0130] 贷款方设备130可以包括处理器705、存储器710、通信端口715、输入设备720、输出设备725、和存储设备730。这些部件可以类似于上面关于中央控制器105所描述的那些部件。然而，在各种实施例中，中央控制器105和贷款方设备130不需要使用相同的部件(例如，相同品牌或制造商的部件)，或甚至不需要使用类似的部件。存储设备730可以适当地包括一个或多个数据库。存储设备730可以包括用于根据一个或多个实施例进行操作的程序780。
[0131] 数据库
[0132] 参考图8，根据各种实施例示出了卖方数据库250。卖方数据库250可以包含关于卖方的相关信息，包括卖方标识符、名称、地址、金融账户标识符、所售商品的类型、出口港，和/或关于卖方的任何其他信息。
[0133] 参考图9，根据各种实施例示出了买方数据库255。买方数据库255可以包含关于买方的相关信息、包括买方标识符、名称、地址、金融账户标识符、所购买的商品类型、进口港，和/或关于买方的任何其他信息。
[0134] 参考图10，根据各种实施例示出了贷款方数据库260。贷款方数据库260可以包含关于贷款方的相关信息，包括贷款方标识符、名称、地址、金融账户标识符、在其中进行贷款的一个或多个国家、和/或关于贷款方的任何其他信息。
[0135] 参考图11，根据各种实施例示出了承保方数据库265。承保方数据库265可以包含关于承保方的相关信息，包括承保方标识符、名称、地址、金融账户标识符、承保商品的类型、商品可以被承保的一个或多个国家、和/或关于承保方的任何其他信息。
[0136] 参考图12，根据各种实施例示出了验证方数据库270。验证方数据库可以包含关于验证方的相关信息，包括验证方标识符、名称、地址、金融账户标识符、和/或关于验证方的任何其他信息。
[0137] 参考图13，根据一些实施例示出了日志275。如上所述，日志可以保留交易记录。日志可以保留部分或一部分交易的记录。日志可以保存与交易相关的文档或其他信息的记录。
[0138] 在各种实施例中，日志中的记录或条目可以涉及买方和卖方之间的个别商品销售。日志可以记录的信息例如交易标识符、日期(例如商定的交易的日期)、买方、卖方、承保方(例如为卖方提供买方信用保险的保险公司承保人)、贷款方(例如向卖方提供贸易融资的贷款方)、验证方、所售的商品(如玉米、大米等)、所售的商品的数量、付款金额、销售条款(如支付条款)、运送港、承运人、交付港、提货单(例如承运人提供给卖方的提货单的扫描件)，以及交易状态(例如商品运输、商品到达、未付款、已付款等)。
[0139] 交易可以包括哈希，其可以表示先前交易中所表示的信息的变换。因此，哈希可以用作到一个或多个先前交易的链接。
[0140] 交易可包括评分。评分可以提供对通过给定的交易的日志的货币、优先级、和/或完整性的一些指示。由于日志可以以分布式方式存储，因此当日志的并行冲突版本可用时，该评分可用于选择若干日志中的一个。
[0141] 应当理解，根据各种实施例，可以记录并预期与交易相关的其他项信息。
[0142] 过程
[0143] 图14是根据一些实施例的流程图，示出了卖方所采取的步骤。
[0144] 在步骤1410，卖方向中央控制器105注册。此时，卖方可以提供各项信息，例如其名称、地址、纳税人识别号码、销售产品、收入、业务年限、主要所有者、成员和/或董事、和/或任何其他信息项。然后，卖方信息可以由中央控制器105进行验证。卖方信息也可以或可替代地由一个或多个其他方进行验证。在一些实施例中，一个或多个承保方验证卖方信息。
[0145] 在步骤1420，卖方接收来自中央控制器105的批准。卖方可在中央控制器105和/或另一方已经验证卖方信息之后接收批准。在卖方接收批准之前，中央控制器105(和/或另一方)可以确定该卖方是否满足一个或多个批准的标准。这样的标准可以包括业务的最小业务年限、最小收入金额、来自特定数量的客户的正面参考、和/或任何其他标准。
[0146] 在步骤1430，卖方提交发票。发票可以是提供给买方的针对交易的发票，针对所述交易卖方希望获得贸易融资。根据各种实施例，可以以各种方式提交发票。在各种实施例中，可以通过光学字符识别(OCR)扫描现有发票。从而中央控制器105可以自动记录交易的一个或多个细节。在各种实施例中，卖方可以通过中央控制器105生成新发票。例如，卖方可以访问中央控制器105的网站上的发票模板。然后卖方可以将适当的交易细节、条款、和/或任何其他信息填写入该模板。
[0147] 来自发票的信息使用例如光学字符识别(OCR)和/或其他技术的技术来进行提取。然后，使用提取自发票的信息来确定该发票是否满足一组预定标准。
[0148] 在步骤1440，卖方可以附上提货单(“BL”)。BL可以用于卖方希望获得贸易融资的交易。卖方可以通过各种方式附加BL，例如通过扫描、邮寄等。
[0149] 在各种实施例中，一旦提交了BL，中央控制器105或附属方可以使用OCR识别或登记细节。在各种实施例中，一旦提交了BL，中央控制器或附属方可以将BL转换为区块链版本。以这种方式，BL可以链接到一个或多个先前提货单(例如与先前交易相关联的BL's)和/或一个或多个先前交易。因此，BL可以合并到BL's和/或交易的区块链中。
[0150] 在各种实施例中，卖方可以首先提交BL作为区块链版本。
[0151] 在各种实施例中，该BL被提交作为/或被转换为作为安全数字区块链版本的BL。
[0152] 在各种实施例中，中央控制器105和/或附属方(例如，验证方设备125)可以验证BL。中央控制器105可以将BL的一个或多个细节与发票的一个或多个细节进行匹配，以便验证两者的匹配度。中央控制器105可以验证一个或多个其他细节，例如BL上的任何品牌/商标/徽章的真实性、承运人的身份、运送港的位置、运送日期、和/或任何其他细节。
[0153] 在各种实施例中，可以将BL与BL's的外部记录进行比较。例如，BL's的副本可以存储在外部数据库中，例如与各个运送港相关的数据库。如果卖方提交的BL与外部记录相匹配，则卖方提交的BL可以被视为已经通过验证。
[0154] 在各种实施例中，中央控制器105可以在BL被批准之前验证BL满足一个或多个标准。在各种实施例中，只有原始BL's可以被接受。在各种实施例中，只有“待预定”的原始BL's可接受。在各种实施例中，只有区块链上的“待预定”的原始BL's可接受。
[0155] 在各种实施例中，在步骤1450，卖方为商品销售购买贸易信用保险。在各种实施例中，卖方为发票和BL购买贸易信用保险。
[0156] 在各种实施例中，中央控制器105自动确定贸易信用保险的价格。可以基于一个或多个因素确定价格。这样的因素可以包括付款条款(例如净30、净60)、商品的支付金额、买方的信用评级、买方的声誉、买方的业务年限、商品的目的地、和/或任何其他因素。例如，交易信用保险的定价可以是商品的支付金额的0.5％乘以支付到期前的天数除以30天(例如，支付100,000美元*0.5％*120天/30天＝2000美元)。如将理解的，保险可以以各种其他方式定价。
[0157] 在各种实施例中，可以向各种承保方呈现商品销售条款，并且承保方可以确定其提供保险的价格。
[0158] 在各种实施例中，卖方可以批准保险要约并接受保险购买。在各种实施例中，可以从卖方的金融账户中自动扣除保险的付款(例如保费)。付款可以转移到保险公司。如将理解的，可以以各种其他方式接收付款。
[0159] 在步骤1460，卖方可以获得贷款。在各种实施例中，贷款方可以同意向卖方提供贷款(例如，贸易融资)。一旦贷款方确定卖方已向买方发出的发票的金额、BL的真实性、卖方已获得贸易信用保险、和/或有关交易的任何其他信息，贷款方即可提供贷款。贷款方可以是银行、金融机构或任何其他方。
[0160] 贷款金额可以从贷款方的金融账户中扣除。贷款金额可以转移到与卖方相关联的金融账户。贷款金额可自动转入卖方的注册银行账户。作为交换，可以向贷款方发布(例如自动地)转让通知。
[0161] 在步骤1470，买方可以支付商品。例如，买方可在收到商品后60天支付。在各种实施例中，付款可以直接从买方转移到贷款方。因此，来自买方的付款可用于偿还卖方的贷款。在各种实施例中，可以经由中央控制器105的综合银行账户进行支付，直接转账给贷款方/融资方/损失收款人的银行账户。
[0162] 在步骤1480，如果买方在付款到期日(例如，如发票上详述的)之前没有支付货款，则承保方可以赔付信用保险。中央控制器105可以(例如自动地)通知承保方买方没有及时付款。在各种实施例中，中央控制器105可以生成和/或提交保险索赔(例如自动地)。如果在付款到期日之前未收到买方的付款，则可以自动生成索赔。在各种实施例中，当在付款到期日期加上一些预定天数(例如付款到期日期后30天)没有从买方收到付款时，可以自动生成索赔。
[0163] 然后可以从承保方的金融账户中扣除(例如自动地)保险赔付，并且可以将保险赔付转移(例如自动地)到贷款方的金融账户。
[0164] 在步骤1490，在各种实施例中，承保方然后可以负责从买方收取付款。
[0165] 参考图15，根据一些实施例示出了处理流程。该处理流程表示根据各种实施例的承保方所采取的步骤。
[0166] 在步骤1510，承保方可以接收关于买方的信息。买方可以是特定卖方希望与其交易的买方。卖方可以提供预期或当前买方的指示。承保方可以收到有关买方的各种信息。这些信息可以包括资产、收入、买方和卖方之间已经发生的历史销售数量、买方已经发生的历史销售数量、和/或关于买方的任何其他信息。
[0167] 在步骤1520，卖方、中央控制器105、或任何其他方可以向承保方提供支付以针对买方对信用保险进行报价。
[0168] 在步骤1530，承保方可以确定用于承保方针对买方提供的信用保险所需的价格、保费金额或其他付款。保费可能是给定销售的函数。例如，保费可能随给定交易期间购买的商品数量而变化。然而，即使在没有具体交易的情况下，承保方也可以基于销售的参数(例如商品的支付价格)确定用于决定保费的算法或其他公式。例如，保费可以确定为0.75％*商品的支付价格。在各种实施例中，承保方可以指定销售必须满足的一组条款或标准，以使其有资格获得信用保险。例如，承保方可以设定商品的最高支付价格和/或在支付到期之前可以发生的最大天数的限制。
[0169] 在步骤1540，承保方可以接收关于特定交易的信息。该信息可以包括针对商品将要支付的价格、商品类型、支付条款、和/或关于交易的任何其他信息。然后，承保方可以确定该交易的信用保险所需的保费。在各种实施例中，承保方使用先前确定的公式、算法等应用于该特定交易。然后，承保方可以通知中央控制器105、卖方、和/或任何其他方所需的保费。在各种实施例中，中央控制器105和/或另一方可拥有承保方所使用的算法。因此，中央控制器105、卖方、和/或其他方可以使用承保方的算法以及关于交易的信息来自动计算或以其他方式确定保费。
[0170] 在步骤1550，承保方可以向买方(或买方代表、附属公司、经纪人等)发送支付提醒。可以基于支付条款(例如从与交易相关联的发票导出的支付条款)来发送支付提醒。还可以基于当前日期发送支付提醒。例如，可以在付款到期前10天发送付款提醒。在各种实施例中，中央控制器105可以代表承保方自动发出支付提醒。可以通过各种方式发送支付提醒，例如经由电子邮件、文本、电话、邮寄等。发送的支付提醒的记录或日志可以由中央控制器105保留。
[0171] 在步骤1560，如果买方没有按照交易条款的要求付款(例如发票上详述交易条款)，则承保方可以进行适当的保险赔付。在一些实施例中，买方必须在承保方付款之前违约特定的天数(例如60天)。赔付可以转到损失收款人(例如贷款方；例如卖方)。赔付可以由中央控制器105从承保方的账户中自动扣除并转到损失收款人的账户。
[0172] 在各种实施例中，承保方还可以发起收款流程以从买方收取付款。
[0173] 参考图16，根据一些实施例示出了处理流程。该处理流程表示根据各种实施例的贷款方或融资方所采取的步骤。
[0174] 在步骤1610，贷款方可以接收关于交易的信息。贷款方可以接收关于卖方希望进行贸易融资的交易的信息。贷款方可以接收关于卖方正针对其寻求融资的所有可用交易的信息。贷款方可以接收关于符合贷款方指定的标准的交易的信息。例如，贷款方可以具有交易标准，其可以包括所请求的最小融资金额、所请求的最大融资金额、卖方的特定位置、买方的特定位置、商品的类型、商品的大小、买方的规模(例如就收入而言)、卖方的规模、承保方的信用评级、和/或任何其他标准。
[0175] 贷款方可以经由中央控制器105接收关于交易的信息。在各种实施例中，贷款方可以接收关于新交易的警报、可用的交易的周期性列表、或关于可用的交易的任何其他通知或通信。在各种实施例中，贷款方可以主动搜索可用的交易。贷款方可以例如使用指定的标准(例如交易规模等)进行搜索。
[0176] 在各种实施例中，贷款方可以接收与交易相关的文档或其他信息。在各种实施例中，贷款方可以接收发票的副本(例如卖方提供给买方的发票)、信用保险发票、提货单、和/或任何其他信息或单据。
[0177] 在各种实施例中，贷款方可以接收关于买方、卖方、承保方或其他方的背景的文件。此类文件可能包括许可证、组建证书、公司注册证书、或任何其他背景信息。
[0178] 在步骤1620，基于贷款方接收的关于交易的信息，贷款方可以决定为交易提供贸易融资。贷款方可以参照标准集合来匹配收到的信息。贷款方可以使用决定是否提供融资的评分系统、算法或任何其他方式。在各种实施例中，贷款方向中央控制器提供算法、标准集合、评分系统、和/或其他评估方法，并且然后中央控制器可自动应用该标准以确定贷款方是否将提供融资。
[0179] 在各种实施例中，所提供的融资金额可取决于一个或多个因素。这样的因素可能与交易和/或交易参与者有关。在各种实施例中，所提供的融资金额可以是发票金额的百分比(例如100％，例如90％)。在各种实施例中，可以从提供的资金中扣除金额(例如，金额可以由贷款方、中央控制器和/或另一方保存)。扣除的金额可能包括利息费、交易费、货币兑换费、费、和/或其他费用。
[0180] 在步骤1630，贷款方可以向卖方提供资金。可以将资金从贷款方的金融账户转移(例如自动地)到卖方的金融账户。
[0181] 在步骤1640，贷款方可以被卖方指定为就买方取出的信用保险单的损失收款人。这样，如果买方没有对发票做出令人满意的付款，贷款方就可以替代地从承保方收到付款。
在各种实施例中，如果存在与交易相关的其他保险单(例如丢失、损坏等保险)，则贷款方也可以被当做这些保险单的损失收款人。
在各种实施例中，如果存在与交易相关的其他保险单(例如丢失、损坏等保险)，则贷款方也可以被当做这些保险单的损失收款人。
[0182] 在各种实施例中，贷款方可以接收保险单的转让通知。在各种实施例中，贷款方可在向卖方提供贸易融资时自动从中央控制器105接收此类通知。
[0183] 在步骤1650，买方对发票进行支付。然后这种付款可以转给贷款方。在各种实施例中，如果贷款方没有供给该发票的全部金额，则贷款方仅可以从买方收到等于资助金额的资金。例如，如果贷款方仅提供相当于发票金额的50％的融资，则贷款方可以从买方收到发票金额的50％。在各种实施例中，根据买方提供的收入，贷款方可以收到贷款的还款加上任何适用的利息费用、逾期利息、滞纳金、交易费用、货币兑换费用、和/或任何其他费用。
[0184] 在各种实施例中，可以将付款自动添加到与贷款方相关联的金融账户。在各种实施例中，付款可以流过中央控制器。例如，买方可以向中央控制器105付款，然后中央控制器105可以(例如立即地)向贷款方付款。在各种实施例中，中央控制器105提供付款指令，但其自己不处理资金。例如，中央控制器105可以指示买方的银行向贷款方的银行付款，但可能不会自己处理资金。如将理解的，各种实施例期望可以以各种其他方式将资金从买方转移到贷款方，可以有或没有中央控制器105的调解。
[0185] 在步骤1660，如果买方在付款到期日之前没有支付发票，则贷款方可以继续对借出的金额收取利息。在各种实施例中，利率可保持不变。在各种实施例中，由于逾期支付，利率可能增加。
[0186] 在各种实施例中，贷款方可以向买方(或卖方或任何其他方)发送关于还款的迟到状态的一个或多个通知。在各种实施例中，可以由中央控制器(例如自动地)发出通知。
[0187] 在步骤1670，如果买方完全没有付款(例如在付款到期后的预定天数内；例如在付款到期后的60天内)，则贷款方可以作为损失收款人从承保方处接收付款。在各种实施例中，贷款方可以在被支付之前提交索赔。在各种实施例中，中央控制器代表贷款方自动提交索赔。
[0188] 参考图17，示出了根据一些实施例的处理流程，其表示由验证方所采取的步骤。
[0189] 在步骤1710，验证方接收关于交易的信息(例如，买方和卖方之间的商品销售)。信息可包括买方的身份、卖方的身份、运送港、交付港、运送日期、承运人、商品的性质以及任何其他信息。验证方可以接收与该交易相关的文档。该文件可能包括提货单、发票、和/或任何其他单据。
[0190] 在步骤1720，验证方确定交易是否是真实的。验证方可以确定，例如，买方和/或卖方实际存在、指定的商品实际上在特定日期被转运到特定港口的特定承运人、商品具有指定的性质/条件、和/或发生了交易的任何其他细节。验证方可以访问单独的或独立的记录、日志等(例如，不依赖于中央控制器的记录、日志)，并且因此验证方可以具有独立地验证交易的一个或多个方面的方法。
[0191] 在步骤1730，验证方可以将与交易相关联的提货单转换为区块链格式。
[0192] 在步骤1740，验证方可以指示交易的一个方面(或整个交易)是真实的。例如，验证方可以向中央控制器(和/或任何其他方)发送通知，指示该交易是真实的。
[0193] 在步骤1750，验证方可以接收对其验证服务的付款。例如，可以将资金(例如自动地)转移到与验证方相关联的金融账户。在各种实施例中，验证方的费用由贷款方支付。这样，可以在提供给验证方之前从贷款方(例如在中央控制器处)接收资金。
[0194] 这里描述了根据一些实施例的步骤、过程和/或流程。应当理解，预期的实施例不限于这些具体描述。相反地，可以以不同的顺序执行各种步骤，可以添加步骤，可以省略步骤，可以组合步骤，可以引入附加的决策分支等，并且仍然落入预期实施例的范围内。
[0195] 定价
[0196] 在各种实施例中，中央控制器105可以接收用于提供其服务的一个或多个费用、佣金、和/或其他付款。中央控制器105可以提供包括以下各项的服务：匹配两方或更多方(例如买方、卖方、承保方、贷款方、验证方)、转移资金、发送通知、维护交易日志、加速索赔处理、加速单据的创建(例如发票；例如区块链格式的提货单)、或任何其他服务。
[0197] 在各种实施例中，中央控制器105可以向卖方收取费用。所收取的费用可能是发票价值/交易价值的百分比。
[0198] 在各种实施例中，中央控制器105可以向贷款方收取费用。所收取的费用可能是贷款方的收入的百分比。所收取的费用可以是贷款方收到的由中央控制器105促成的贷款的利息的百分比。
[0199] 在各种实施例中，中央控制器105可以向承保方收取费用。所收取的费用可能是承保方收到的收入的百分比。所收取的费用可以是承保方收到的由中央控制器促成的交易的保费的百分比。
[0200] 在各种实施例中，中央控制器105可以向任何其他方或任何方的组合收取费用。
[0201] 在各种实施例中，中央控制器105可以根据任何合适的公式、算法等确定所收取的费用。例如，中央控制器105可以向贷款方收取固定的交易费(例如每笔交易1000美元)加上该贷款方收到的利息收入的百分比。
[0202] 在各种实施例中，可以从一个或多个其他方的相应金融账户中扣除中央控制器收取的费用。
[0203] 平台与技术的集成
[0204] 图18示出了平台发明1801的概要流程及其与可能的兼容技术的集成。
[0205] 用户1802可以经由不同的设备1803访问平台，包括但不限于笔记本电脑、平板电脑、移动电话和个人数字助理(PDA)。为了提高交易中涉及的主要方以及贸易促进方之间的效率、安全性和通信，集成了一些辅助技术和系统1804。这包括但不限于双因素认证、OCR、机器学习(ML)、数据库管理、数据分析、商业智能(BI)、人工智能(AI)、和应用程序编程接口(API)。
[0206] 该平台集成了区块链/分布式分类帐技术1805以确保交易的有效性。这是一个去中心化/分布式系统，其中区块链是链接的交易链，并且每个新交易形成一个新的区块。由于链中的每个变化是分布的/与网络共享的，其中网络中的每个设备都充当认证者，因此区块链中记录的交易更难以篡改。
[0207] 共享信息的处理流程
[0208] 图19是概述不同用户可以经由本发明平台所采取的步骤的流程图。
[0209] 首先，卖方1901在平台上注册。此时，卖方可以提供各种信息项，例如其名称、地址、纳税人识别号、销售产品、收入、业务年限、主要所有者、人员和/或董事、和/或任何其他项信息。然后，中央控制器105可以验证卖方信息。卖方信息也可以或可替代地由一个或多个其他方进行验证。在一些实施例中，一个或多个贷款方1902、承保方1903、和验证方1904验证卖方信息。
[0210] 通过访问平台，卖方1901可以继续添加买方以进行评估。买方可以是特定卖方1901希望与之交易的买方。卖方1901可以提供预期或当前买方的指示。这样的信息1905可以包括注册号、地址、资产、收入、在买方和卖方之间已经发生的历史销售的数量、已经发生的针对买方的历史销售的数量、和/或关于买方的任何其他信息。指定的贷款方1902或承保方1903可以能够查看关于买方的所提交的信息。
[0211] 如果买方通过评估，承保方1903可以能够接收关于所提交的买方的信息，评估买方风险，并向买方提供信用额度。在各种实施例中，承保方1903可以指定销售必须满足的一组条款或标准，以使其有资格获得信用保险。例如，承保方1903可以对支付到期之前可能发生的最大天数设置限制。记录买方信息和评估结果。
[0212] 对于被批准的买家，卖家1901可以继续上传发票1906以进行保险。该发票可以是提供给买方的发票，用于卖方1901希望接收贸易融资的交易。根据各种实施例，可以以各种方式提交发票。可以提示卖方1901提供其他文件，例如转运单据(例如提货单)、交付凭证、采购订单、合同和关于交易的其他文件以进行交叉验证。在各种实施例中，可以通过OCR扫描文档。从而中央控制器105可以自动记录交易的一个或多个细节。信息可包括买方的身份、卖方的身份、运送港、交付港、运送日期、承运人、商品的性质以及任何其他信息。使得这些信息可用于贷款方1902和承保方1903。
[0213] 在验证交易真实性和收到付款后，验证方1904可以继续批准交易以进行保险。一旦被承保，卖方1901可以将发票提交给贷款1902以进行融资。一旦买方已经支付了发票规定的商品/服务，该发票/交易就被标记为已付款。记录该发票/交易的所有状态更新。
[0214] 如果延迟付款或买方违约，卖方可以经由平台请求索赔。索赔将包括例如索赔类型、追偿工作和关于交易的信息等细节。承保方和贷款方可以查看索赔详情。承保方可以批准或不批准该索赔。一旦获得批准/不批准，就更新并记录该发票的索赔状态。
[0215] 光学字符识别和机器学习
[0216] 图20描绘了使用OCR和ML扫描文档，例如发票2001、转运文档2002、交付凭证2003和采购订单2004，以交叉检查交易的细节。
[0217] OCR用于转换带有文本(无论是机打的、手写的还是打印的)的图像，并将它们翻译成数字文本，然后可以将所述数字文本用于数据处理。原始图像可以由扫描仪、相机等产生，并且可以是PDF、jpeg、png、bmp、tiff和其他格式。彩色/灰度图像被转换为二值图像，并且通过改善图像质量、去除噪声和调整图像定向来完成预处理。然后检测文本位置，并校正由损坏/合并文本创建的错误。一旦完成此操作，字符就被识别并转换为文本格式。
[0218] 在提交扫描的文档时，OCR工具1905用于在模板数据库2005中检测、检索和匹配包括但不限于产品、库存单位(SKU)、数量、价值、发送者和买方等的信息。匹配允许用户继续提交发票以用于保险。记录OCR扫描的结果。
[0219] OCR可以与ML一起使用，这将通过使其能够预测在上传的模板图像/文件中可以找到重要输入的位置来改进工具。ML可以被监督或未被监督。训练数据最初可以被馈送到平台，其中目标输出与来自机器的输出进行比较。将相应地对预测算法进行调整。
[0220] 与区块链/分布式分类帐技术的集成
[0221] 区块链技术经由互联网工作，其中保存了越来越多的记录和交易。这些数据存储在被称为节点的计算机网络中。每当交易发生时(如订单、付款和帐户跟踪)，交易的记录都会被放入区块中。每个区块包含四个主要信息：哈希标识符、来自前一个区块的哈希数、包含在区块中的交易，以及用于发送方和接收方的公钥。
[0222] 如图21所示，平台中的一个或多个交易发生在承保方、卖方、贷款方和买方之间。这些交易产生或生成的数据例如索赔数据2101、发票数据2102、卖方数据2103、买方数据
2104和贷款方数据2105。这些数据可以被存储在一个或多个数据库中。然后将一个或多个数据库中的信息传达到中央控制器105。
2104和贷款方数据2105。这些数据可以被存储在一个或多个数据库中。然后将一个或多个数据库中的信息传达到中央控制器105。
[0223] 特定的交易可以被分发到区块链/分布式分类帐技术(DLT)中心2106，以向诸如CordaTM 2107、EthereumTM 2108、Hyperledger FabricTM 2109、RippleTM 2110、和/或其他新兴区块链和DLT技术2111的若干平台发送或接收信息。
[0224] 可以使用分布式消息传送系统来管理区块链/DLT中心2101，该分布式消息传送系统将信息流通到所有区块链网络2112。发布-订阅系统用于实现数据分层以进行更有效的信息流通。在数据分层的这种情况下，根据所需要的原则对数据进行过滤，其中只有订阅某些主题/组的节点将获得分发给订阅该主题的那些组的信息。应当理解，信息通常不会分发给网络的所有节点或成员。例如，正在融资的发票的更新将仅分发给贸易融资子集，并不会分发给整个银行/贷款组。作为另一个例子，被融资的发票上的相同更新也可以被发送到保险子集，但不被发送到整个保险组。
[0225] 对于每次更新有关交易的数据/信息，将从每个平台生成区块链特定的哈希响应。哈希是将原始数据表示为一系列字母和/或数字的加密值。这用于使数据更安全，并且使数据对未经授权的查看者不可读。
[0226] 可以从网络中提取信息或者向网络共享信息，例如检索卖方和买方“了解你的客户”信息2114、发布发票以验证双重融资或双重保险的可能性2115。经由区块链中心共享发票状态后，不同的节点将确认该状态的有效性。因此，已经融资的发票不可以再次融资，并且已经投保的发票无法重新投保。
[0227] 区块链/分布式分类帐可用于记录和发布交易，使用智能合约2116用于交换发票的所有权，用于管理保险单，例如促进索赔过程2117以及和平台用户之间的其他义务。智能合约技术充当合同的自动售货机，在每份合同发布和履行各方之间的合同义务之前确立要求。要求可以包括业务文档、交易文档、交付文档、采购订单、付款等。智能合约可以用于贷款方与卖方之间、卖方与承保方之间、贷款方与承保方之间、发明平台与卖方之间，发明平台与承保方之间、以及其他多方之间的协议。
[0228] 商业智能
[0229] 商业智能的过程开始于通过本发明收集数据，如图22所示。数据2201包括但不限于卖方、买方、贷款方、发票和索赔。这些数据将以各种格式进行收集，例如JPEGTM、CSVTM、PDFTM或HTMLTM表格，其中各种卫生和验证技术将被实施。在确保收集的数据安全且相关后，这些数据将被存储在数据管理器2202中，数据管理器2202包括数据库、搜索引擎和内部云存储，如AmazonTM S3，Microsoft AzureTM和Google CloudTM。
[0230] 从收集信息的过程中，将对数据管理进行管理以提供数据分析2203、商业智能2204和人工智能2205的解决方案。数据管理是获取、保护、组织和管理数据的过程。本发明平台旨在通过创建回答诸如以下问题的算法来提供更好的数据分析2203：
[0231] a.某些行业/部门的贫乏月份和高峰月份是什么时候？交易值与月平均值有多大差异？
[0232] b.每个国家的违约率是多少？
[0233] c.本国买家与国外买家的违约率是多少？
[0234] d.每个国家、每个行业和发票金额范围的比率和平均付款延迟是多少？[0235] e.本国交易和国外交易的比率和平均付款延迟是多少？
[0236] f.每个国家和每个行业的欺骗率是多少？
[0237] g.交易中的哪个步骤经常发生欺骗？
[0238] h.与违约和欺骗相互关联的主要变量是什么？这些变量的预测能力是多少？[0239] i.哪些行业相互关联？某些行业的需求增加对其他行业有多大影响？
[0240] 通过记录和跟踪来自不同用户的特定数据、用户行为模式和用户交易模式，该平台可以提供有关风险管理、现金流动管理甚至创收的商业智能。例如，信用风险不仅仅基于宏观经济、行业和金融风险，而且还能够考虑交易各方的支付模式和风险规避模式。在这个阶段，分析从描述性的转变为诊断性的。利润下降的原因可以从现金流动管理(限制收入)或风险管理(增加成本)的角度进行诊断。
[0241] 通过利用平台上记录的相关性、诊断、和行为观察，人工智能的应用可以进一步提升用户体验。可以预测风险，例如付款延迟、欺骗、违约。还可以预测市场需求、现金需求等的增加，并且可以经由平台来建议/提示采取诸如请求/提供额外信用限额、额外融资设施等的行动，甚至可以经由平台基于需求和行为匹配来建议贷款/保险合作伙伴。
[0242] 认证
[0243] 如今，互联网比以往任何时候都更容易暴露于网络安全攻击，例如，网络钓鱼、SQL注入、跨站点脚本等。在所有这些攻击中，黑客通常可以访问和使用用户的凭证(用户名和密码)。使用双因素认证(2FA)，需要使用仅由用户所有的另一条信息，例如令牌。这为本发明平台提供了额外的安全层。
[0244] 图23示出了2FA可以如何与本平台发明一起使用的示例。
[0245] 用户将使用其凭据登录2301到该网站。如果数据库中的电子邮件和哈希密码存在且匹配，则将执行程序以进行认证。认证后，服务器将返回对用户浏览器的响应。如果响应成功，则将进入双因素认证页面2302。
[0246] 本发明可以使用Google AuthenticatorTM作为2FA工具。也可以使用其他认证工具。Google AuthenticatorTM是基于时间的一次性密码，其中在用户的设备上生成唯一代码。为了使用它，用户需要在移动设备2303上安装应用程序。当2FA页面请求令牌时，用户将从应用程序获取并手动提交它。服务器2304和客户端将基于共享密钥和时间生成相同的确切代码以比较和检查登录请求。成功登录将会将用户重定向到本发明的特定登录页面2305。否则，用户将不能够访问平台并将被重定向到未授权访问页面2306。将记录失败尝试的次数。
[0247] 匹配
[0248] 图24示出了由本发明方法实现的匹配过程。
[0249] 卖方2401将向发明平台注册并提供他/她的详细信息2402。承保方2403将提供其各种预定要求和定价2404。贷款方2405将提供其各种预定要求和利率2406。
[0250] 在给定贷款方和承保方的预定要求和定价的情况下，在各种实施例中，本发明使用工具2407来将卖方匹配并标记给特定的承保方和贷款方。用于匹配的信息可以包括位置、行业、营业额、平均发票值、定价、支付条款和其他细节。
[0251] 鉴于前面的描述，可以理解的是，本发明解决了在所支付的最低保费可能花费至少10,000美元的时段开始时为年度总预计营业额支付保费的问题。本发明改变了企业支付保费的方式，只有当他们有可保险的交易时才按需支付。这意味着企业可以在一段时间内分散成本。
[0252] 虽然本文已经描述了各种实施例，但是应该理解，前述内容并非旨在进行限制，并且可以预期在前述精神和范围内的其他实施例。
[0254] 本领域技术人员应该进一步理解，可以进一步组合上述不相互排斥的修改或改进中的一个或多个修改或改进，以形成本发明进一步的实施例。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 工作流系统中的BI节点执行方法、装置、设备及介质 | 2020-05-12 | 999 |
| 一种商业智能ETL的封装方法及系统 | 2020-05-17 | 835 |
| LED工业照明有线远程多通道智能调光控制系统 | 2020-05-19 | 945 |
| 基于机器学习的自适应知识图谱技术 | 2020-05-12 | 18 |
| 一种基于抽取的商业智能分析平台自动分区方法及装置 | 2020-05-13 | 306 |
| 一种集物资采购与交易为一体的业务监控系统及方法 | 2020-05-14 | 969 |
| 一种酒产品生产供需管理平台 | 2020-05-19 | 584 |
| 任务生成方法、系统和存储介质 | 2020-05-16 | 396 |
| 一种智能楼宇商业智能展示终端 | 2020-05-15 | 423 |
| 一种便于管理的低功耗电子价签 | 2020-05-18 | 501 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
商业智能热门专利
QQ群二维码
意见反馈
意见反馈