监管码生成方法和追溯平台

本公开涉及互联网技术，尤其涉及一种监管码生成方法和追溯平台。

监管码是为了对产品进行电子监管而为每件产品赋予的标识，每件产品的监管码唯一，即“一件一码”，监管码如同每件产品的身份证。

现有技术中，监管码是20位的一个数字序列，例如80123451234567891111，其中，前两位(例如，80)是前缀，用于标识产品的种类；前缀之后的五位(例如，12345)是码段，码段用于标识产品的生产企业和产品信息，产品信息包括产品名称、产品规格等信息，同一生产企业生产的同一种产品的每种规格对应有一个码段；码段之后的九位(例如，123456789)是序列号，序列号用于标识同一生产企业生产的同一种产品的同一规格的每件产品；序列号之后的四位(例如，1111)是校检位，该校检位是根据校检算法对监管码的前16位进行校检得到的结果。

码段是按序生成的，具体从00000到99999，即不重复的码段的最大数量是100000个，但是，随着生产企业、产品种类、以及产品规格的增加，被占用的码段越来越多，100000个码段会被很快耗尽，导致生产企业不能无限制的申请监管码。另外，前缀和序列号也是按序生成的，当前缀、码段、序列号均增大到最大值时，监管码的所有位数已被耗尽，若继续增大监管码，则需要增加监管码的长度，因此，需要统一改造监管码的生成、管理、维护系统，导致监管码的可扩展性差。

本公开提供一种监管码生成方法和追溯平台，以实现无限制申请监管码。

一个方面，本公开提供一种监管码生成方法，包括：

追溯平台接收申请设备发送的申请请求，所述申请请求包括货物名称、以及所需申请的监管码的数量；

至少根据申请设备登录到追溯平台后，在追溯平台上设定的时间信息，确定时间码段；

根据所述时间码段生成监管码。

另一方面，本公开提供一种追溯平台，包括：处理器，所述处理器用于执行如下方法的步骤：

追溯平台接收申请设备发送的申请请求，所述申请请求包括货物名称、以及所需申请的监管码的数量；

至少根据申请设备登录到追溯平台后，在追溯平台上设定的时间信息，确定时间码段；

根据所述时间码段生成监管码。

在本公开中，时间码段与时间信息关联，由于时间信息是一个可持续变化的信息，随着时间的增加，时间信息可持续增加，保证时间码段可以被无限制申请，根据该时间码段生成监管码，从而实现了监管码可以被无限制申请。

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为现有技术中监管码的结构示意图；

图2为本公开的一种可选的监管码的结构示意图；

图3为本公开的一种可选的应用场景/组网方式的示意图；

图4为本公开实施例一提供的监管码生成的架构图；

图5为本公开实施例二提供的监管码生成方法的流程图；

图6为本公开实施例二提供的监管码生成方法的流程图；

图7为本公开实施例三提供的监管码生成方法的流程图；

图8为本公开实施例四提供的监管码生成方法的流程图；

图9为本公开实施例五提供的监管码生成方法的流程图；

图10为本公开实施例六提供的监管码生成方法的流程图；

图11为本公开实施例七提供的监管码生成方法的流程图；

图12为本公开实施例八提供的监管码生成方法的流程图；

图13为本公开实施例九提供的监管码生成方法的流程图；

图14为本公开实施例十提供的监管码生成方法的流程图；

图15为本公开实施例十一提供的监管码生成方法的流程图；

图16为本公开实施例十二提供的监管码生成方法的流程图；

图17为本公开实施例十三提供的监管码生成方法的流程图；

图18为本公开实施例十四提供的监管码生成方法的流程图；

图19为本公开实施例十五提供的监管码生成方法的流程图；

图20为本公开实施例十六提供的监管码生成方法的流程图；

图21为本公开实施例十七提供的监管码生成方法的流程图；

图22为本公开实施例一提供的服务器的结构示意图；

图23为本公开实施例二提供的服务器的结构示意图；

图24为本公开实施例三提供的服务器的结构示意图；

图25为本公开实施例一提供的终端设备的结构示意图；

图26为本公开实施例二提供的终端设备的结构示意图；

图27为本公开实施例提供的监管码生成系统的结构示意图。

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

现有技术中，监管码是20位的数字序列，如图1所示，20位的监管码包括两位的前缀11、五位的码段12、九位的序列号13、四位的校检位14，前缀11用于标识产品的种类；码段12用于标识产品的生产企业和产品信息，产品信息包括产品名称、产品规格等信息，同一生产企业生产的同一种产品的每种规格对应有一个码段；序列号13用于标识同一生产企业生产的同一种产品的同一规格的每件产品；校检位14是根据校检算法对监管码的前16位进行校检得到的结果。

前缀11、码段12、序列号均13均是按序生成的，例如，码段12具体从00000到99999，即不重复的码段的最大数量是100000个，随着生产企业、产品种类、以及产品规格的增加，100000个码段会被很快耗尽，导致生产企业不能无限制的申请监管码。另外，当前缀、码段、序列号均增大到最大值时，监管码的所有位数已被耗尽，若继续增大监管码，则需要增加监管码的长度，因此，需要统一改造监管码的生成、管理、维护系统，导致监管码的可扩展性差。

本公开针对现有技术中的问题，提出了一种监管码生成方法，如图2所示，本公开所述的监管码是35位的数字序列，该监管码包括两位的前缀21、二十位的码段22、九位的序列号23、四位的校检位24，其中，二十位的码段22包括十七位的时间信息18和三位的码段序号19，时间信息18精确到毫秒，例如，20160122034455666表示2016年1月22日3点44分55秒666毫秒，码段序号19从000-999，码段序号标识同一时刻的多个并发申请，例如，追溯平台在2016年1月22日3点44分55秒666毫秒同时接收到了生产企业A、生产企业B、生产企业C、生产企业D发送的申请请求，该申请请求用于申请监管码，则2016年1月22日3点44分55秒666毫秒时刻对应有4个并发请求，追溯平台可从000-999中选取4个不同的码段序号，例如001、002、003、004，以便区分同一时刻内的4个并发请求。生产企业A、生产企业B、生产企业C、生产企业D申请的监管码中的码段22分别为20160122034455666001、20160122034455666002、20160122034455666003、20160122034455666004。

在本实施例中，码段22中的时间信息18是追溯平台接收到申请请求时的时间信息。

另外，在其他实施例中，码段22中的时间信息18还可以是追溯平台处理申请请求时的时间信息。

此外，在其他实施例中，码段22中的时间信息18还可以是申请监管码的用户通过申请设备设定的时间信息，用户可选的时间信息可以精确到毫秒，申请设备例如图3中的申请设备11、申请设备12、申请设备13或申请设备14，申请设备根据用户的设定向追溯平台发送申请请求，该申请请求中包括用户设定的时间信息。

本实施例中，码段与时间信息关联，由于时间信息是一个可持续变化的信息，随着时间的增加，时间信息可持续增加，保证码段可以被无限制申请，根据该码段生成监管码，从而实现了监管码可以被无限制申请。另外，同一时间信息对应有预设数量的码段序号，预设数量的码段序号可标识同一时刻预设数量的并发申请，只要同一时刻申请监管码的并发请求的数量不超过该预设数量，即可保证不超过系统的处理上限，无需升级系统，不需要统一改造监管码的生成、管理、维护系统，提高了监管码的可扩展性。码段与企业数量无关，保证码段不会随着企业的增多而按序增大，也不会随着申请请求的增加而扩展码段的位数，从本质上解决了码段随着企业数量的增加需要不断扩展位数的问题。

本实施例结合图3介绍生产企业从追溯平台申请监管码的过程，以及监管码的生成方法，如图3所示，生产企业在生产商品时，在商品的包装或商品本身赋一个监管码，每件商品有一个监管码，该监管码如同商品的身份证一样用于对该商品进行唯一标识，该监管码具体可以是二维码、图形码、条形码、防伪码等具有一定商品信息的符号，也可以是不可见的标签，还可以是用特定的编码规则生成的码，在本实施例中，该监管码是一串数字序列，该数字序列是追溯平台根据生产企业的申请请求生成的数字序列，如图3所示，生产企业A可通过申请设备11向追溯平台申请监管码，生产企业B可通过申请设备12向追溯平台申请监管码，生产企业C可通过申请设备13向追溯平台申请监管码，生产企业D可通过申请设备14向追溯平台申请监管码。

各生产企业向追溯平台申请监管码之前，各生产企业通过各自对应的申请设备向追溯平台上传货物的信息，例如，生产企业A通过申请设备11向追溯平台上传生产企业A的标识信息、以及生产企业A生产的货物A的货物信息，该货物信息包括货物A的名称、以及货物A的规格，追溯平台将生产企业A的标识信息、货物A的名称、以及货物A的规格之间的关联关系存储到数据库10。同理，将生产企业B的标识信息、生产企业B生产的货物B的名称、以及货物B的规格之间的关联关系存储到数据库10；将生产企业C的标识信息、生产企业C生产的货物C的名称、以及货物C的规格之间的关联关系存储到数据库10；将生产企业D的标识信息、生产企业D生产的货物D的名称、以及货物D的规格之间的关联关系存储到数据库10。货物A、货物B、货物C、以及货物D可以是相同的货物，也可以是不同的货物。

追溯平台对生产企业A、生产企业B、生产企业C、生产企业D分别上传的货物进行验证，验证合格后，生产企业A、生产企业B、生产企业C、生产企业D可分别通过各自对应的申请设备向追溯平台发送申请请求，发送申请请求的过程具体可以是：生产企业的人员通过申请设备登录到追溯平台，从追溯平台中查询到该生产企业已上传的、并且被追溯平台验证合格的货物的名称和规格，确定该货物的个数即所需监管码的个数后点击确定申请。

追溯平台接收到申请请求后，根据货物的名称，确定该货物的类别，本实施例用2位数字序列表示货物的类别，例如货物的名称是阿莫西林，货物的类别是药品，另外，追溯平台预先存储有货物的类别和监管码的前缀的对应关系，例如，药品对应的监管码的前缀是80。

追溯平台根据该申请请求对应的时间信息，生成监管码的码段，其中，申请请求对应的时间信息可以是追溯平台接收到申请请求时的时间信息、也可以是生产企业的人员通过申请设备登录到追溯平台后，在追溯平台上设定的时间信息，例如，生产企业预计在2016年6月20日销售该货物，在2016年6月12日申请该货物的监管码，则在追溯平台上设定2016年6月20日，表示生产企业预计申请与2016年6月20日相关联的码段。另外，追溯平台可以对申请请求进行即时处理，也可以对申请请求进行延时处理，若延时处理，则申请请求对应的时间信息还可以是追溯平台处理该申请请求时的时间信息。

本实施例以申请请求对应的时间信息是追溯平台接收到申请请求时的时间信息为例，详细说明追溯平台根据该申请请求对应的时间信息，生成监管码的码段的过程。如图1所示，追溯平台可分时接收到申请设备11、申请设备12、申请设备13、申请设备14发送的申请请求，即申请设备11、申请设备12、申请设备13、申请设备14不是同时向追溯平台发送申请请求，另外，追溯平台也可以同时接收到申请设备11、申请设备12、申请设备13、申请设备14发送的申请请求，即申请设备11、申请设备12、申请设备13、申请设备14同时向追溯平台发送申请请求。在本实施例中，本实施例用20位数字序列表示监管码的码段，其中，码段的前17位表示时间信息，后3位表示码段序号，每个时间信息标识的时刻对应有预设数量的不同码段序号，例如2016年1月22日3点44分55秒666毫秒对应有1000个码段序号，该1000个码段序号从000-999，时间信息表示为20160122034455666，20160122034455666000可标识2016年1月22日3点44分55秒666毫秒的第一个申请请求，20160122034455666001可标识2016年1月22日3点44分55秒666毫秒的第二个申请请求，20160122034455666999可标识2016年1月22日3点44分55秒666毫秒的第1000个申请请求，同理，除2016年1月22日3点44分55秒666毫秒之外的任一时刻也对应有1000个码段序号。在本实施例中，每个时刻的1000个码段序号可标识该时刻内的1000个并发的申请请求，另外，本实施例只是为了举例说明，并不限定每个时刻对应的码段序号的具体个数。当申请设备11、申请设备12、申请设备13、申请设备14同时向追溯平台发送申请请求后，追溯平台将在同一时刻接收到4个申请请求，假设该同一时刻是2016年1月22日3点44分55秒666毫秒，追溯平台依次给2016年1月22日3点44分55秒666毫秒内的4个申请请求分配监管码的码段，一个申请请求对应一个监管码的码段，4码段分别为20160122034455666000、20160122034455666001、20160122034455666002、20160122034455666003，相应的，生产企业A申请的监管码的码段是20160122034455666000，生产企业B申请的监管码的码段是20160122034455666001，生产企业C申请的监管码的码段是20160122034455666002，生产企业D申请的监管码的码段是20160122034455666003。当追溯平台在同一时刻只接收到一个申请请求时，从该时刻对应的1000个码段序号中随机选择一个码段序号，或者按序选择一个码段序号，将该时刻表示的时间信息和该码段序号构成该申请请求所申请的监管码的码段。

如图3所示，每个生产企业需要给其生产的每一件货物赋予一个监管码，每个生产企业向追溯平台申请监管码时，需要确定所需申请的监管码的个数。本实施例根据每个生产企业申请的监管码的个数，生成监管码的序列号，本实施例用9位数字序列表示监管码的序列号，例如，生产企业A一次申请10000个监管码，用于标识10000件货物，则追溯平台为生产企业A分配的监管码的序列号从000000000-000009999，000000000标识第一件货物、000000001标识第二件货物、000009999标识第10000件货物。同理，追溯平台可分别给生产企业B、生产企业C、生产企业D分配监管码的序列号。

此外，追溯平台对监管码的前缀、码段、序列号依次构成的序列进行校验，生成监管码的校验位，本实施例用4位数字序列表示监管码的校验位，以生产企业A的第一个监管码为例，前缀是80、码段是20160122034455666000、序列号是000000000，追溯平台采用预定的校验算法对前缀、码段、序列号依次构成的序列即8020160122034455666000000000000进行校验，生成校验位例如1111。前缀、码段、序列号、校验位依次构成生产企业A的第一个监管码即80201601220344556660000000000001111。同理，可生成生产企业A的第二个监管码80201601220344556660000000000011111，以至生成生产企业A的第10000个监管码80201601220344556660000000099991111。

本实施例中用35位数字序列表示监管码，相比于现有技术中的20位监管码，不同之处在于监管码的码段，现有技术中，码段是5位数字序列，码段是按序生成的，具体从00000到99999，即不重复的码段的最大数量是100000个，100000个码段会被很快耗尽，限制了生产企业申请码段的个数，同时限制了申请监管码的个数。本实施例中的码段是20位数字序列，码段的前17位表示时间信息，后3位表示码段序号，由于时间信息是一个可持续变化的信息，随着时间的增加，时间信息可持续变化，通过码段与时间信息关联，可保证码段不断被申请，另外，每个时间信息对应有1000个码段序号，用1000个码段序号标识同一时刻内的1000个并发的申请请求，同一时刻申请的多个监管码的码段的前17位相等，后3位不同，保证了同一时刻申请的多个监管码的码段不同，避免了同一时刻申请的多个监管码的码段重复，从而避免了同一时刻申请的多个监管码重复。

另外，码段与时间信息关联，随着时间的变化，时间信息可持续变化，码段随着时间信息的变化而变化，相比于现有技术码段按序生成，可有效解决码段不断增大，码段位数不断扩展的问题。并且按照时间信息分配码段的方法简单，处理时间延迟短，可有效提高系统的处理速度。

此外，由于本实施例中的码段关联有时间信息，并且时间信息精确到毫秒，码段中时间信息的长度固定，随着时间的变化，码段中的时间信息可不断变化，每个时间信息对应有预设数量的码段序号，预设数量的码段序号可标识同一时刻预设数量的并发请求，码段包括时间信息和码段序号，保证码段不仅可标识出不同时刻申请的码段，还可标识出同一时刻多个并发请求申请的码段，只要同一时刻申请监管码的并发请求的数量不超过该预设数量，即可保证不超过系统的处理上限，无需升级系统，不需要统一改造监管码的生成、管理、维护系统，提高了监管码的可扩展性。码段与企业数量无关，保证码段不会随着企业的增多而按序增大，也不会随着申请请求的增加而扩展码段的位数，从本质上解决了码段随着企业数量的增加需要不断扩展位数的问题。

本公开实施例一提供了监管码生成方法，该方法包括如下步骤：

步骤1、接收申请设备发送的申请请求。

本实施例的执行主体是追溯平台，该追溯平台具体实现为图4所示的服务器10，如图4所示，生产企业A可通过申请设备11向追溯平台申请监管码，生产企业B可通过申请设备12向追溯平台申请监管码，生产企业C可通过申请设备13向追溯平台申请监管码，生产企业D可通过申请设备14向追溯平台申请监管码。具体地，生产企业A、生产企业B、生产企业C、生产企业D分别通过各自对应的申请设备向追溯平台发送申请请求，申请请求用于申请监管码。

步骤2、至少根据所述申请请求关联的时间信息，确定时间码段。

在本实施例中，所述申请请求关联的时间信息可以是追溯平台接收到申请请求时的时间信息。另外，在其他实施例中，所述申请请求关联的时间信息可以是追溯平台处理申请请求时的时间信息。此外，在其他实施例中，所述申请请求还包括所述时间信息，所述时间信息是用户通过所述申请设备设定的时间信息。或者，所述申请请求关联的时间信息还可以是申请设备发送申请请求时的时间信息。

例如，2016年1月22日3点44分55秒666毫秒表示时间信息，根据该时间信息确定的时间码段可以为20160122034455666。或者，在时间信息2016年1月22日3点44分55秒666毫秒的基础上增加预设的延时时间如4毫秒，得到另一时间信息2016年1月22日3点44分55秒670毫秒，根据2016年1月22日3点44分55秒670毫秒确定的时间码段可以为20160122034455670。或者，根据该时间信息2016年1月22日3点44分55秒666毫秒确定的时间码段可以为20160122034455666001，即在20160122034455666的后面增加3位的码段序号001，且本实施例不限定码段序号的位数。追溯平台可根据该时间码段生成监管码。

可选的，服务器10在2016年1月22日3点44分55秒666毫秒同时接收到申请设备11、申请设备12、申请设备13、申请设备14发送的申请请求，服务器10依次给4个并发的申请请求分配时间码段，一个申请请求对应一个时间码段，4时间码段分别为20160122034455666000、20160122034455666001、20160122034455666002、20160122034455666003，相应的，给申请设备11分配的时间码段是20160122034455666000，给申请设备12分配的时间码段是20160122034455666001，给申请设备13分配的时间码段是20160122034455666002，给申请设备14分配的时间码段是20160122034455666003。

步骤3、根据时间码段生成监管码，并向申请设备发送所述监管码。

服务器10根据时间码段20160122034455666000生成监管码31、根据时间码段20160122034455666001生成监管码32、根据时间码段20160122034455666002生成监管码33、根据时间码段20160122034455666003生成监管码34。如图4所示为监管码生成的架构图，将监管码31-34分别发送给申请设备11-14。

本实施例中，时间码段与时间信息关联，由于时间信息是一个可持续变化的信息，随着时间的增加，时间信息可持续增加，保证时间码段可以被无限制申请，根据该时间码段生成监管码，从而实现了监管码可以被无限制申请。

图5为本公开实施例二提供的监管码生成方法的流程图，如图5所示，在图4所示实施例的基础上，该方法包括如下步骤：

步骤S201、接收申请设备发送的申请请求。

本实施例的执行主体是追溯平台，如图1所示，生产企业A可通过申请设备11向追溯平台申请监管码，生产企业B可通过申请设备12向追溯平台申请监管码，生产企业C可通过申请设备13向追溯平台申请监管码，生产企业D可通过申请设备14向追溯平台申请监管码。具体地，生产企业A、生产企业B、生产企业C、生产企业D分别通过各自对应的申请设备向追溯平台发送申请请求，申请请求用于申请监管码。

步骤S202、至少根据所述申请请求关联的时间信息，确定时间码段。

步骤S202与步骤S102一致，具体方法此处不再赘述。

步骤S203、至少根据所述时间码段，生成监管码。

在本实施例中，所述申请请求包括货物名称、以及所需申请的监管码的数量。时间码段是步骤S102所述的时间码段。

本实施例的执行主体是追溯平台，如图1所示，生产企业A可通过申请设备11向追溯平台申请监管码，生产企业B可通过申请设备12向追溯平台申请监管码，生产企业C可通过申请设备13向追溯平台申请监管码，生产企业D可通过申请设备14向追溯平台申请监管码。具体地，生产企业A、生产企业B、生产企业C、生产企业D分别通过各自对应的申请设备向追溯平台发送申请请求，申请请求包括生产企业的标识信息、货物名称、货物规格、以及所需监管码的个数。

如图6所示，至少根据所述时间码段，生成监管码的方法具体包括如下步骤：

步骤S31、根据所述货物名称，确定监管码的前缀；

追溯平台接收到申请请求后，根据货物的名称，确定该货物的类别，本实施例用2位数字序列表示货物的类别，例如货物的名称是阿莫西林，货物的类别是药品，另外，追溯平台预先存储有货物的类别和监管码的前缀的对应关系，例如，药品对应的监管码的前缀是80。

步骤S32、根据所需申请的监管码的数量，确定每个监管码的序列号，所述每个监管码的序列号连续递增；

如图1所示，每个生产企业需要给其生产的每一件货物赋予一个监管码，每个生产企业向追溯平台申请监管码时，需要确定货物的数量即所需监管码的个数。本实施例根据每个生产企业申请的监管码的个数，生成监管码的序列号，本实施例用9位数字序列表示监管码的序列号，例如，生产企业A一次申请10000个监管码，用于标识10000件货物，则追溯平台为生产企业A分配的监管码的序列号从000000000-000009999，000000000标识第一件货物、000000001标识第二件货物、000009999标识第10000件货物。同理，追溯平台可分别给生产企业B、生产企业C、生产企业D分配监管码的序列号。

步骤S33、对所述前缀、所述时间码段、所述序列号构成的序列进行校验，生成监管码的校验位；

追溯平台对监管码的前缀、时间码段、序列号构成的序列进行校验，生成监管码的校验位，本实施例用4位数字序列表示监管码的校验位，以生产企业A的第一个监管码为例，前缀是80、时间码段是20160122034455666、序列号是000000000，追溯平台采用预定的校验算法对前缀、时间码段、序列号构成的序列即8020160122034455666000000000进行校验，生成校验位例如1111。

步骤S34、将所述前缀、所述时间码段、所述序列号、以及所述校验位构成所述监管码。

前缀、时间码段、序列号、校验位构成生产企业A的第一个监管码即80201601220344556660000000001111。同理，可生成生产企业A的第二个监管码80201601220344556660000000011111，以至生成生产企业A的第10000个监管码80201601220344556660000099991111。

步骤S204、将所述监管码发送给所述申请设备。

本实施例中，时间码段与时间信息关联，由于时间信息是一个可持续变化的信息，随着时间的增加，时间信息可持续增加，保证时间码段可以被无限制申请，根据该时间码段生成监管码，从而实现了监管码可以被无限制申请。

图7为本公开实施例三提供的监管码生成方法的流程图，如图7所示，在图5所示实施例的基础上，该方法包括如下步骤：

步骤S401、接收申请设备发送的申请请求。

追溯平台接收到申请请求后，获取接收所述申请请求时的时间信息。

步骤S402、至少根据接收所述申请请求时的时间信息，确定时间码段。

追溯平台可根据接收所述申请请求时的时间信息，确定时间码段，例如，追溯平台在2016年1月22日3点44分55秒666毫秒接收到该申请请求，则根据时间信息2016年1月22日3点44分55秒666毫秒确定的时间码段为20160122034455666。

步骤S403、至少根据所述时间码段，生成监管码。

步骤S404、将所述监管码发送给所述申请设备。

步骤S403与步骤S203一致，步骤S404与步骤S204一致，具体方法此处不再赘述。

本实施例中，追溯平台根据接收到申请请求时的时间信息，确定时间码段，时间码段与时间信息关联，由于时间信息是一个可持续变化的信息，随着时间的增加，时间信息可持续增加，保证时间码段可以被无限制申请，根据该时间码段生成监管码，从而实现了监管码可以被无限制申请。

图8为本公开实施例四提供的监管码生成方法的流程图，如图8所示，在图7所示实施例的基础上，该方法包括如下步骤：

步骤S501、接收申请设备发送的申请请求。

步骤S502、确定在所述时间信息所标识的时刻接收到的申请请求的个数。

所述时间信息是步骤S402中所述的追溯平台接收所述申请请求时的时间信息。在所述时间信息所标识的时刻接收到的申请请求的个数为N，N大于1。

如图3所示，追溯平台在2016年1月22日3点44分55秒666毫秒接收到申请设备11发送的申请请求，追溯平台进一步根据时间信息2016年1月22日3点44分55秒666毫秒，确定在该时刻接收到的申请请求的个数，由于多个申请设备可同时向追溯平台发送申请请求，可选的，追溯平台同时接收到申请设备11、申请设备12、申请设备13、申请设备14发送的申请请求，即申请设备11、申请设备12、申请设备13、申请设备14同时向追溯平台发送申请请求。由于时间信息可精确到毫秒，例如2016年1月22日3点44分55秒666毫秒，当从追溯平台申请监管码的生产企业较多时，可能会有多个生产企业同一时刻向追溯平台发送申请请求，本实施例以追溯平台在同一时刻接收多个申请请求为例阐述监管码生成的方法。

步骤S503、在所述时间信息上分别增加N个不同的时间偏移，生成N个第一时间偏移信息，一个申请请求对应一个第一时间偏移信息。

例如，追溯平台在2016年1月22日3点44分55秒666毫秒同时接收到申请设备11、申请设备12、申请设备13、申请设备14发送的申请请求，则追溯平台在时间信息2016年1月22日3点44分55秒666毫秒的基础上增加4个不同的时间偏移，比如4个不同的时间偏移分别为1毫秒、3毫秒、5毫秒、7毫秒，生成4个第一时间偏移信息，4个第一时间偏移信息分别为2016年1月22日3点44分55秒667毫秒、2016年1月22日3点44分55秒669毫秒、2016年1月22日3点44分55秒671毫秒、2016年1月22日3点44分55秒673毫秒。一个申请请求对应一个第一时间偏移信息，例如，申请设备11发送的申请请求对应2016年1月22日3点44分55秒667毫秒，申请设备12发送的申请请求对应2016年1月22日3点44分55秒669毫秒，申请设备13发送的申请请求对应2016年1月22日3点44分55秒671毫秒，申请设备14发送的申请请求对应2016年1月22日3点44分55秒673毫秒。

步骤S504、根据各申请请求对应的第一时间偏移信息，确定所述时间码段，所述时间码段包括所述第一时间偏移信息。

追溯平台根据各申请请求对应的第一时间偏移信息，生成时间码段，例如，根据2016年1月22日3点44分55秒667毫秒生成的时间码段是20160123034455667，根据2016年1月22日3点44分55秒669毫秒生成的时间码段是20160123034455669，根据2016年1月22日3点44分55秒671毫秒生成的时间码段是20160123034455671，根据2016年1月22日3点44分55秒673毫秒生成的时间码段是20160123034455673。

步骤S505、至少根据所述时间码段，生成监管码；

步骤S506、将所述监管码发送给所述申请设备。

步骤S505与步骤S203一致，步骤S506与步骤S204一致，具体方法此处不再赘述。

本实施例中，当追溯平台同一时刻接收到多个申请请求时，追溯平台在该时刻对应的时间信息上分别增加多个不同的时间偏移，生成多个第一时间偏移信息，一个申请请求对应一个第一时间偏移信息，根据每个申请请求对应的第一时间偏移信息生成该申请请求所申请的监管码的时间码段，保证了同一时刻申请的多个监管码的时间码段不同，从而避免了同一时刻申请的多个监管码重复。

图9为本公开实施例五提供的监管码生成方法的流程图，如图9所示，在图7所示实施例的基础上，该方法包括如下步骤：

步骤S601、接收申请设备发送的申请请求。

步骤S602、确定在所述时间信息所标识的时刻接收到的申请请求的个数。

所述时间信息是步骤S402中所述的追溯平台接收所述申请请求时的时间信息。在所述时间信息所标识的时刻接收到的申请请求的个数为N，N大于1；所述时间信息对应有M个不同的码段序号，M大于或等于N。

例如，追溯平台在2016年1月22日3点44分55秒666毫秒同时接收到申请设备11、申请设备12、申请设备13、申请设备14发送的申请请求，即2016年1月22日3点44分55秒666毫秒对应的申请请求的个数N为4。另外，每个时间信息标识的时刻对应有预设数量的不同码段序号，例如2016年1月22日3点44分55秒666毫秒对应有1000个码段序号，该1000个码段序号从000-999，20160122034455666000可标识2016年1月22日3点44分55秒666毫秒的第一个申请请求，20160122034455666001可标识2016年1月22日3点44分55秒666毫秒的第二个申请请求，20160122034455666999可标识2016年1月22日3点44分55秒666毫秒的第1000个申请请求，同理，除2016年1月22日3点44分55秒666毫秒之外的任一时刻也对应有1000个码段序号。

步骤S603、从所述M个不同的码段序号中获取N个不同的码段序号。

在本实施例中，每个时间信息标识的时刻对应的码段序号的个数大于该时刻追溯平台接收到的并发请求的个数，即某一时刻追溯平台接收到的并发请求的个数不超过1000。

追溯平台从2016年1月22日3点44分55秒666毫秒对应的1000个码段序号中获取4个不同的码段序号例如004、007、009、020。

步骤S604、根据所述时间信息和所述N个不同的码段序号，生成N个不同的时间码段，每个时间码段包括所述时间信息和所述N个不同的码段序号中的一个码段序号，一个申请请求对应一个时间码段。

追溯平台根据时间信息2016年1月22日3点44分55秒666毫秒和4个不同的码段序号例如004、007、009、020，生成4个不同的时间码段，4个不同的时间码段分别为20160122034455666004、20160122034455666007、20160122034455666009、20160122034455666020，一个申请请求对应一个时间码段，例如，申请设备11发送的申请请求对应的时间码段是20160122034455666004，申请设备12发送的申请请求对应的时间码段是20160122034455666007，申请设备13发送的申请请求对应的时间码段是20160122034455666009，申请设备14送的申请请求对应的时间码段是20160122034455666020。

另外，所述N个不同的码段序号连续递增，例如，4个不同的码段序号分别是001、002、003、004，2016年1月22日3点44分55秒666毫秒和4个不同的码段序号生成4个不同的时间码段，4个不同的时间码段分别为20160122034455666001、20160122034455666002、20160122034455666003、20160122034455666004。

步骤S605、至少根据所述时间码段，生成监管码；

步骤S606、将所述监管码发送给所述申请设备。

步骤S605与步骤S203一致，步骤S606与步骤S204一致，具体方法此处不再赘述。

本实施例中，每个时间信息对应有多个不同的码段序号，多个不同的码段序号可标识同一时刻内追溯平台接收到的多个并发的申请请求，追溯平台从该同一时刻标识的时间信息对应的多个不同的码段序号中给每个申请请求分配一个码段序号，根据时间信息和码段序号生成该申请请求所申请的监管码的时间码段，保证了同一时刻申请的多个监管码的时间码段不同，从而避免了同一时刻申请的多个监管码重复。

图10为本公开实施例六提供的监管码生成方法的流程图，如图10所示，在图9所示实施例的基础上，步骤S603的方法包括如下步骤：

步骤S71、确定所述M个不同的码段序号中的最小码段序号是否已分配给时间码段。

例如，2016年1月22日3点44分55秒666毫秒对应有1000个码段序号，该1000个码段序号从000-999。确定1000个码段序号中的最小码段序号000是否已分配给时间码段。

步骤S72、若所述最小码段序号已分配给时间码段，则确定所述M个不同的码段序号中已分配给时间码段的最大的第一码段序号，并将所述第一码段序号存储在码段序号表。

若000已分配给时间码段，则确定1000个码段序号中已分配给时间码段的最大的第一码段序号，例如，1000个码段序号中001、002、003、004均已分配给时间码段，则已分配给时间码段的最大的第一码段序号是004，并将004存储在码段序号表。

步骤S73、遍历N个申请请求，获取所述码段序号表中存储的第一码段序号，将所述第一码段序号的下一个码段序号分配给当前遍历的申请请求，并将所述下一个码段序号存储在码段序号表。

例如，2016年1月22日3点44分55秒666毫秒对应的申请请求的个数N为4，遍历该4个申请请求，具体的，从申请设备11发送的申请请求遍历到申请设备14发送的申请请求；例如，当前遍历的申请请求是申请设备11发送的申请请求，从码段序号表中获取第一码段序号004，该第一码段序号004表示004已经分配给时间码段，则将004的下一个码段序号分配给申请设备11发送的申请请求，004的下一个码段序号可以是005，将005存储在码段序号表，此时，码段序号表中存储的第一码段序号更新为005。

当遍历申请设备12发送的申请请求时，从码段序号表中获取第一码段序号005，将005的下一个码段序号006分配给申请设备12发送的申请请求，将006存储在码段序号表，此时，码段序号表中存储的第一码段序号更新为006。重复前述步骤直到遍历申请设备14发送的申请请求结束。

本实施例中，每个时间信息对应有多个不同的码段序号，多个不同的码段序号可标识同一时刻内追溯平台接收到的多个并发的申请请求，追溯平台遍历每个申请请求，为每个申请请求分配一个不同的码段序号，根据时间信息和码段序号生成该申请请求所申请的监管码的时间码段，保证了同一时刻申请的多个监管码的时间码段不同，从而避免了同一时刻申请的多个监管码重复。

图11为本公开实施例七提供的监管码生成方法的流程图，如图11所示，在图9所示实施例的基础上，步骤S603的方法包括如下步骤：

步骤S81、确定所述M个不同的码段序号中的最小码段序号是否已分配给时间码段。

步骤S81与步骤S71一致，具体方法此处不再赘述。

步骤S82、若所述最小码段序号未分配给时间码段，则将所述最小码段序号分配给N个申请请求中的一个申请请求，并将所述最小码段序号存储在码段序号表。

若1000个码段序号中的最小码段序号000未分配给时间码段，则将000分配给上述实施例四中的4个申请请求中的一个申请请求，例如申请设备11发送的申请请求，并将000存储在码段序号表中。

步骤S83、遍历剩余的N-1个申请请求，获取所述码段序号表中存储的最大的第一码段序号，将所述第一码段序号的下一个码段序号分配给当前遍历的申请请求，并将所述下一个码段序号存储在码段序号表。

遍历剩余的3个申请请求，从申请设备12发送的申请请求遍历到申请设备14发送的申请请求；例如，当前遍历的申请请求是申请设备12发送的申请请求，从码段序号表中获取第一码段序号000，该第一码段序号000表示000已经分配给时间码段，则将000的下一个码段序号分配给申请设备12发送的申请请求，000的下一个码段序号可以是001，将001存储在码段序号表，此时，码段序号表中存储的第一码段序号更新为001。

当遍历申请设备13发送的申请请求时，从码段序号表中获取第一码段序号001，将001的下一个码段序号002分配给申请设备13发送的申请请求，将002存储在码段序号表，此时，码段序号表中存储的第一码段序号更新为002。重复前述步骤直到遍历申请设备14发送的申请请求结束。

本实施例中，每个时间信息对应有多个不同的码段序号，多个不同的码段序号可标识同一时刻内追溯平台接收到的多个并发的申请请求，追溯平台遍历每个申请请求，为每个申请请求分配一个不同的码段序号，根据时间信息和码段序号生成该申请请求所申请的监管码的时间码段，保证了同一时刻申请的多个监管码的时间码段不同，从而避免了同一时刻申请的多个监管码重复。

图12为本公开实施例八提供的监管码生成方法的流程图，本实施例可以图10或图11所示实施例为基础，如图12所示，可选的，在图10所示实施例的基础上，该方法包括如下步骤：

步骤S71、确定所述M个不同的码段序号中的最小码段序号是否已分配给时间码段；

步骤S72、若所述最小码段序号已分配给时间码段，则确定所述M个不同的码段序号中已分配给时间码段的最大的第一码段序号，并将所述第一码段序号存储在码段序号表；

步骤S73、遍历N个申请请求，获取所述码段序号表中存储的最大的第一码段序号。

例如，码段序号表中存储的最大的第一码段序号是996，遍历上述4个申请请求，从申请设备11发送的申请请求遍历到申请设备14发送的申请请求，例如，当前遍历的申请请求是申请设备11发送的申请请求，从码段序号表中获取第一码段序号996。

步骤S74、确定所述第一码段序号与所述M个不同的码段序号中最大的第二码段序号是否相同。

上述实施例中的1000个不同的码段序号中最大的第二码段序号是999，当追溯平台从码段序号表中获取到第一码段序号996后，确定第一码段序号是否与第二码段序号相同。

步骤S75、若所述第一码段序号与所述第二码段序号不相同，则将所述第一码段序号的下一个码段序号分配给当前遍历的申请请求。

由于第一码段序号996和第二码段序号999不相同，则将第一码段序号996的下一个码段序号997分配给当前遍历的申请请求如申请设备11发送的申请请求，并将997存储在码段序号表，此时，码段序号表存储的第一码段序号更新为997。

当追溯平台遍历申请设备12发送的申请请求时，重复执行步骤S73，从码段序号表中获取第一码段序号997，将997分配给当前遍历的申请请求如申请设备12发送的申请请求，并将998存储在码段序号表，此时，码段序号表存储的第一码段序号更新为998。同理，分配给申请设备13发送的申请请求的码段序号是999，码段序号表存储的第一码段序号更新为999。

当追溯平台遍历申请设备14发送的申请请求时，重复执行步骤S73，从码段序号表中获取第一码段序号999，由于999是1000个不同的码段序号中最大的码段序号，表示1000个不同的码段序号均已分配给不同的申请请求。由于追溯平台在2016年1月22日3点44分55秒666毫秒同时接收到申请设备11、申请设备12、申请设备13、申请设备14发送的申请请求，则在2016年1月22日3点44分55秒666毫秒的下一时刻即2016年1月22日3点44分55秒667毫秒对应的1000个不同的码段序号中获取一个码段序号，并将该码段序号分配给申请设备14发送的申请请求。

本实施例，将已分配给时间码段的最大的第一码段序号与时间信息对应的多个码段序号中最大的第二码段序号进行比较，若第一码段序号与第二码段序号不相同，表示时间信息对应的多个码段序号还没有全部分配给时间码段，则将第一码段序号的下一个码段序号分配给当前遍历的申请申请，避免分配给当前遍历的申请申请的码段序号超出多个码段序号中的上限值。

图13为本公开实施例九提供的监管码生成方法的流程图，本实施例可以图10或图11所示实施例为基础，如图13所示，可选的，在图11所示实施例的基础上，该方法包括如下步骤：

步骤S81、确定所述M个不同的码段序号中的最小码段序号是否已分配给时间码段。

步骤S82、若所述最小码段序号未分配给时间码段，则将所述最小码段序号分配给N个申请请求中的一个申请请求，并将所述最小码段序号存储在码段序号表。

若1000个码段序号中的最小码段序号000未分配给时间码段，则将000分配给上述实施例四中的4个申请请求中的一个申请请求，例如申请设备11发送的申请请求，并将000存储在码段序号表中。

步骤S83、遍历剩余的N-1个申请请求，获取所述码段序号表中存储的最大的第一码段序号。

遍历剩余的3个申请请求，从申请设备12发送的申请请求遍历到申请设备14发送的申请请求。例如，当前遍历的是申请设备12发送的申请请求，获取该码段序号表中存储的最大的第一码段序号000。

步骤S84、将所述第一码段序号的下一个码段序号和所述码段序号表当前存储的最大码段序号进行比较；

在本实施例中，同一个码段序号可能会分配给多个不同的申请请求，例如，第一码段序号000的下一个码段序号001可能同时分配给申请设备12发送的申请请求和申请设备13发送的申请请求，则将001分配给申请设备12发送的申请请求后，需要将001存储在码段序号表，将001分配给申请设备13发送的申请请求后，需要将001再次存储在码段序号表，即001将被重复存储在码段序号表。为了避免同一个码段序号分配给多个不同的申请请求，在将001存储在码段序号表之前，进行并发验证，具体的，将即将存储在码段序号表的001和码段序号表中当前存储的最大码段序号进行比较。

步骤S85、若所述第一码段序号的下一个码段序号与所述码段序号表当前存储的最大码段序号不相同，则将所述第一码段序号的下一个码段序号分配给当前遍历的申请请求，并将所述下一个码段序号存储在码段序号表。

若第一码段序号的下一个码段序号如001与码段序号表当前存储的最大码段序号不相同，即码段序号表中当前存储的最大码段序号不是001，表示001没有被分配给其他的申请请求，则将001分配给当前遍历的申请请求，如申请设备12发送的申请请求，并将001存储在码段序号表。

另外，若所述第一码段序号的下一个码段序号与所述码段序号表当前存储的最大码段序号相同，即码段序号表中当前存储的最大码段序号是001，表示001已经被分配给其他的申请请求，则在2016年1月22日3点44分55秒666毫秒的下一时刻即2016年1月22日3点44分55秒667毫秒对应的1000个不同的码段序号中获取一个码段序号，并将该码段序号分配给当前遍历的申请请求，如申请设备12发送的申请请求。

本实施例，将即将存储在码段序号表的码段序号和码段序号表中当前存储的最大码段序号进行比较，若两者不相同，表示即将存储在码段序号表的码段序号没有被分配给其他的申请请求，通过将码段序号存储在码段序号表之前，进行并发验证，避免了同一个码段序号重复分配给多个申请请求。

图14为本公开实施例十提供的监管码生成方法的流程图，该方法包括如下步骤：

步骤S1001、接收申请设备发送的申请请求。

步骤S1002、确定在所述时间信息所标识的时刻接收到的申请请求的个数。

所述时间信息是步骤S402中所述的追溯平台接收所述申请请求时的时间信息。在所述时间信息所标识的时刻接收到的申请请求的个数为N，N大于1。所述时间信息对应有M个不同的码段序号，M小于N。

在本实施例中，追溯平台在2016年1月22日3点44分55秒666毫秒接收到的申请请求的个数大于2016年1月22日3点44分55秒666毫秒对应的码段序号的个数，例如，2016年1月22日3点44分55秒666毫秒对应有1000个码段序号，追溯平台在2016年1月22日3点44分55秒666毫秒接收到的申请请求的个数N大于1000。

步骤S1003、根据所述时间信息和所述M个不同的码段序号，确定N个申请请求中M个申请请求分别对应的时间码段，每个时间码段包括所述时间信息和一个码段序号。

可选的，每个时间信息对应有1000个码段序号，追溯平台在2016年1月22日3点44分55秒666毫秒接收到1005个申请请求，则根据时间信息2016年1月22日3点44分55秒666毫秒和1000个码段序号例如从000-999，生成1000个时间码段，每个时间码段包括20160122034455666和000-999中的一个码段序号，1000个时间码段分配给1005个申请请求中的1000个申请请求。

步骤S1004、在所述时间信息上增加预设的时间偏移，生成第二时间偏移信息。

在时间信息2016年1月22日3点44分55秒666毫秒的基础上增加预设的时间偏移，例如3毫秒，生成第二时间偏移信息2016年1月22日3点44分55秒669毫秒。

步骤S1005、根据所述第二时间偏移信息，确定所述N个申请请求中除所述M个申请请求之外的申请请求分别对应的时间码段。

可选的，所述第二时间偏移信息对应有M个不同的码段序号。所述根据所述第二时间偏移信息，确定所述N个申请请求中除所述M个申请请求之外的申请请求分别对应的时间码段，包括：从所述M个不同的码段序号中获取(N-M)个不同的码段序号，(N-M)大于0；根据所述第二时间偏移信息和所述(N-M)个不同的码段序号，确定所述N个申请请求中除所述M个申请请求之外的申请请求分别对应的时间码段。

同理，第二时间偏移信息2016年1月22日3点44分55秒669毫秒对应有1000个码段序号例如从000-999，从第二时间偏移信息对应的1000个码段序号中选择5个码段序号，例如001、002、003、004、005，根据第二时间偏移信息2016年1月22日3点44分55秒669毫秒和001、002、003、004、005生成5个时间码段，该5个时间码段分别是20160122034455669001、20160122034455669002、20160122034455669003、20160122034455669004、20160122034455669005，该5个时间码段分配给1005个申请请求中剩余的5个申请请求。步骤S1006、至少根据所述时间码段，生成监管码。

步骤S1007、将所述监管码发送给所述申请设备。

步骤S1006与步骤S203一致，步骤S1007与步骤S204一致，具体方法此处不再赘述。

本实施例，每个时间信息对应有多个不同的码段序号，多个不同的码段序号可标识同一时刻内追溯平台接收到的多个并发的申请请求，当追溯平台在同一时刻接收到的多个并发的申请请求的个数大于该时刻对应的多个不同的码段序号时，在该时刻的基础上增加预设的时间延时，根据延时后的时间信息确定申请请求的码段序号，根据时后的时间信息和码段序号生成该申请请求所申请的监管码的时间码段，保证了同一时刻申请的多个监管码的时间码段不同，从而避免了同一时刻申请的多个监管码重复。

图15为本公开实施例十一提供的监管码生成方法的流程图，该方法包括如下步骤：

步骤S1101、接收申请设备发送的申请请求。

所述申请请求包括所述时间信息，所述时间信息是用户通过所述申请设备设定的时间信息。

在本实施例中，申请请求对应的时间信息是生产企业的人员通过申请设备登录到追溯平台后，在追溯平台上设定的时间信息，例如，生产企业预计在2016年1月22日销售该货物，在2016年1月1日申请该货物的监管码，则在追溯平台上设定2016年1月22日3点44分55秒666毫秒，表示生产企业预计申请与2016年1月22日3点44分55秒666毫秒相关联的时间码段。

步骤S1102、根据所述时间信息查询预设的关系表，所述关系表包括历史时间信息，所述历史时间信息是接收所述申请请求之前接收到的历史申请请求包括的时间信息。

本实施例中，历史时间信息是接收所述申请请求之前接收到的历史申请请求包括的时间信息，例如，追溯平台在接收申请设备13发送的申请请求之前已接收到申请设备11和申请设备12发送的申请请求，则申请设备11和申请设备12发送的申请请求是历史申请请求，历史申请请求中包括历史时间信息，历史时间信息依次存储在关系表中。

当追溯平台接收到申请设备13发送的申请请求时，根据该申请请求中的时间信息如2016年1月22日3点44分55秒666毫秒查询预设的关系表，该关系表存储有申请设备11和申请设备12发送的历史申请请求分别包括的历史时间信息。

步骤S1103、确定所述预设的关系表中是否存在与所述时间信息匹配的历史时间信息。若预设的关系表中存在与所述时间信息匹配的历史时间信息，则执行步骤S1104-步骤S1106；若预设的关系表中不存在与所述时间信息匹配的历史时间信息，则执行步骤S1107和步骤S1108。

追溯平台根据申请设备13发送的申请请求中包括的时间信息如2016年1月22日3点44分55秒666毫秒查询预设的关系表，确定关系表中是否存储有2016年1月22日3点44分55秒666毫秒。

步骤S1104、在所述时间信息上增加预设的时间偏移，生成第三时间偏移信息，所述第三时间偏移信息与所述预设的关系表中的历史时间信息不匹配；

若关系表中有与2016年1月22日3点44分55秒666毫秒匹配的时间信息，表示时间信息2016年1月22日3点44分55秒666毫秒已经被用于生成时间码段，则在时间信息2016年1月22日3点44分55秒666毫秒的基础上增加预设的时间偏移例如4毫秒，生成第三时间偏移信息2016年1月22日3点44分55秒670毫秒，并根据第三时间偏移信息2016年1月22日3点44分55秒670毫秒查询关系表，继续确定关系表中是否有与第三时间偏移信息匹配的历史时间信息。

步骤S1105、根据所述第三时间偏移信息，确定时间码段，所述时间码段包括所述第三时间偏移信息。

若关系表中没有与第三时间偏移信息匹配的历史时间信息，则根据第三时间偏移信息2016年1月22日3点44分55秒670毫秒确定时间码段，该时间码段可以是20160122034455670。

步骤S1106、将所述第三时间偏移信息存储到所述预设的关系表。

并且追溯平台还将第三时间偏移信息2016年1月22日3点44分55秒670毫秒存储到关系表中，表示时间信息2016年1月22日3点44分55秒670毫秒已经被用于生成时间码段。

步骤S1107、根据所述申请请求中包括的所述时间信息，确定时间码段，所述时间码段包括所述时间信息。若关系表中没有与2016年1月22日3点44分55秒666毫秒匹配的时间信息，则追溯平台根据时间信息2016年1月22日3点44分55秒666毫秒确定时间码段，时间码段可以是20160122034455666。

步骤S1108、将所述时间信息存储到所述预设的关系表。

并且追溯平台还将时间信息2016年1月22日3点44分55秒666毫秒存储到关系表中，表示时间信息2016年1月22日3点44分55秒666毫秒已经被用于生成时间码段。

步骤S1109、至少根据所述时间码段，生成监管码。

步骤S1110、将所述监管码发送给所述申请设备。

步骤S1109与步骤S203一致，步骤S1110与步骤S204一致，具体方法此处不再赘述。

本实施例，申请设备发送的申请请求还包括时间信息，该时间信息是用户通过该申请设备输入的时间信息，追溯平台根据该时间信息查询关系表，确定该申请请求包括的时间信息是否已用于分配时间码段，避免给不同申请请求分配的时间码段重复。

图16为本公开实施例十二提供的监管码生成方法的流程图，该方法包括如下步骤：

步骤S1101、接收申请设备发送的申请请求。

所述申请请求包括所述时间信息，所述时间信息是用户通过所述申请设备设定的时间信息。

在本实施例中，申请请求对应的时间信息是生产企业的人员通过申请设备登录到追溯平台后，在追溯平台上设定的时间信息，例如，生产企业预计在2016年1月22日销售该货物，在2016年1月1日申请该货物的监管码，则在追溯平台上设定2016年1月22日3点44分55秒666毫秒，表示生产企业预计申请与2016年1月22日3点44分55秒666毫秒相关联的时间码段。

步骤S1102、根据所述时间信息查询预设的关系表，所述关系表包括历史时间信息，所述历史时间信息是接收所述申请请求之前接收到的历史申请请求包括的时间信息；

本实施例中，历史时间信息是接收所述申请请求之前接收到的历史申请请求包括的时间信息，例如，追溯平台在接收申请设备13发送的申请请求之前已接收到申请设备11和申请设备12发送的申请请求，则申请设备11和申请设备12发送的申请请求是历史申请请求，历史申请请求中包括历史时间信息，历史时间信息依次存储在关系表中。

当追溯平台接收到申请设备13发送的申请请求时，根据该申请请求中的时间信息如2016年1月22日3点44分55秒666毫秒查询预设的关系表，该关系表存储有申请设备11和申请设备12发送的历史申请请求分别包括的历史时间信息。

步骤S1103、确定所述预设的关系表中是否存在与所述时间信息匹配的历史时间信息。若预设的关系表中存在与所述时间信息匹配的历史时间信息，则执行步骤S1204-步骤S1206；若预设的关系表中不存在与所述时间信息匹配的历史时间信息，则执行步骤S1107和步骤S1108。

追溯平台根据申请设备13发送的申请请求中包括的时间信息如2016年1月22日3点44分55秒666毫秒查询预设的关系表，确定关系表中是否存储有2016年1月22日3点44分55秒666毫秒。

另外，所述预设的关系表中还包括码段序号，一个历史时间信息对应一个码段序号，多个相同的历史时间信息分别对应的码段序号连续递增。

在本实施例中，关系表的具体结构可如表1所示：

表1

历史时间信息 码段序号 2016年1月22日3点44分55秒666毫秒 001 2016年1月22日3点44分55秒666毫秒 002

当追溯平台接收到申请设备13发送的申请请求时，根据该申请请求中的时间信息如2016年1月22日3点44分55秒666毫秒查询预设的关系表，该关系表存储有申请设备11和申请设备12发送的历史申请请求分别包括的历史时间信息，如表1所示，申请设备11和申请设备12发送的历史申请请求分别包括的历史时间信息均是2016年1月22日3点44分55秒666毫秒，一个历史时间信息对应一个码段序号，多个相同的历史时间信息分别对应的码段序号连续递增。

步骤S1204、根据与所述时间信息匹配的历史时间信息对应的最大码段序号，确定所述最大码段序号的下一个码段序号；

根据表1可知，与时间信息2016年1月22日3点44分55秒666毫秒匹配的历史时间信息对应的最大码段序号是002，确定所述最大码段序号的下一个码段序号即003。

步骤S1205、根据所述时间信息和所述下一个码段序号，确定时间码段，所述时间码段包括所述时间信息和所述下一个码段序号；

根据时间信息2016年1月22日3点44分55秒666毫秒和003，可确定申请设备13发送的申请请求所申请的监管码中的时间码段是20160122034455666003。

步骤S1206、将所述时间信息和所述下一个码段序号的对应关系存储到所述预设的关系表。

将时间信息2016年1月22日3点44分55秒666毫秒和003的对应关系存储到所述预设的关系表，得到如下表2：

表2

历史时间信息 码段序号 2016年1月22日3点44分55秒666毫秒 001 2016年1月22日3点44分55秒666毫秒 002 2016年1月22日3点44分55秒666毫秒 003

步骤S1107、根据所述申请请求中包括的所述时间信息，确定时间码段，所述时间码段包括所述时间信息。若关系表中没有与2016年1月22日3点44分55秒666毫秒匹配的时间信息，则追溯平台根据时间信息2016年1月22日3点44分55秒666毫秒确定时间码段，时间码段可以是20160122034455666。

步骤S1108、将所述时间信息存储到所述预设的关系表。

并且追溯平台还将时间信息2016年1月22日3点44分55秒666毫秒存储到关系表中，表示时间信息2016年1月22日3点44分55秒666毫秒已经被用于生成时间码段。

步骤S1109、至少根据所述时间码段，生成监管码。

步骤S1110、将所述监管码发送给所述申请设备。

步骤S1109与步骤S203一致，步骤S1110与步骤S204一致，具体方法此处不再赘述。

本实施例，申请设备发送的申请请求还包括时间信息，该时间信息是用户通过该申请设备输入的时间信息，追溯平台根据该时间信息查询关系表，确定该申请请求包括的时间信息是否已用于分配时间码段，避免给不同申请请求分配的时间码段重复。

图17为本公开实施例十三提供的监管码生成方法的流程图，该方法包括如下步骤：

步骤S1301、接收申请设备发送的申请请求，所述申请请求用于申请监管码，所述申请请求包括货物名称、以及所需申请的监管码的数量。

步骤S1302、根据所述货物名称，确定监管码的前缀。

可选的，根据所述货物名称，确定货物所属的种类；根据所述种类，确定所述监管码的前缀。

步骤S1302与步骤S31一致，具体方法此处不再赘述。

步骤S1303、至少根据所述申请请求关联的时间信息，确定时间码段。

可选的，至少根据接收所述申请请求时的时间信息，确定时间码段；或者，至少根据处理所述申请请求时的时间信息，确定时间码段；或者，所述申请请求包括所述时间信息，所述时间信息是用户通过所述申请设备设定的时间信息，至少根据所述申请请求中包括的所述时间信息，确定时间码段。

至少根据接收所述申请请求时的时间信息，确定时间码段；或者，至少根据处理所述申请请求时的时间信息，确定时间码段；或者，至少根据所述申请请求中包括的所述时间信息，确定时间码段的方法与上述实施例一致，具体过程此处不再赘述。

步骤S1304、根据所需申请的监管码的数量，确定每个监管码的序列号，所述每个监管码的序列号连续递增。

步骤S1305、对所述前缀、所述时间码段、所述序列号构成的序列进行校验，生成监管码的校验位。

步骤S1306、将所述前缀、所述时间码段、所述序列号、以及所述校验位构成所述监管码。

步骤S1307、将所述监管码发送给所述申请设备。

步骤S1304与步骤S32一致，步骤S1305与步骤S33一致，步骤S1306与步骤S34一致，具体方法此处不再赘述。

本实施例中，时间码段与时间信息关联，由于时间信息是一个可持续变化的信息，随着时间的增加，时间信息可持续增加，保证时间码段可以被无限制申请，根据该时间码段生成监管码，从而实现了监管码可以被无限制申请。

图18为本公开实施例十四提供的监管码生成方法的流程图，在图17所示实施例的基础上，该方法包括如下步骤：

步骤S1401、接收申请设备发送的申请请求，所述申请请求用于申请监管码，所述申请请求包括货物名称、以及所需申请的监管码的数量。

步骤S1401与步骤S1301一致，具体方法此处不再赘述。

步骤S1402、根据所述货物名称，确定监管码的前缀。

步骤S1402与步骤S1302一致，具体方法此处不再赘述。

步骤S1403、确定在所述时间信息所标识的时刻接收到的申请请求的个数。

所述时间信息是步骤S402中所述的追溯平台接收所述申请请求时的时间信息。在所述时间信息所标识的时刻接收到的申请请求的个数为N，N大于1。

步骤S1403与步骤S502一致，具体方法此处不再赘述。

步骤S1404、在所述时间信息上分别增加N个不同的时间偏移，生成N个第一时间偏移信息，一个申请请求对应一个第一时间偏移信息。

步骤S1404与步骤S503一致，具体方法此处不再赘述。

步骤S1405、根据各申请请求对应的第一时间偏移信息，确定所述时间码段，所述时间码段包括所述第一时间偏移信息。

步骤S1405与步骤S504一致，具体方法此处不再赘述。

步骤S1406、根据所需申请的监管码的数量，确定每个监管码的序列号，所述每个监管码的序列号连续递增。

步骤S1407、对所述前缀、所述时间码段、所述序列号构成的序列进行校验，生成监管码的校验位。

步骤S1408、将所述前缀、所述时间码段、所述序列号、以及所述校验位构成所述监管码。

步骤S1409、将所述监管码发送给所述申请设备。

步骤S1406与步骤S32一致，步骤S1407与步骤S33一致，步骤S1408与步骤S34一致，具体方法此处不再赘述。

本实施例中，当追溯平台同一时刻接收到多个申请请求时，追溯平台在该时刻对应的时间信息上分别增加多个不同的时间偏移，生成多个第一时间偏移信息，一个申请请求对应一个第一时间偏移信息，根据每个申请请求对应的第一时间偏移信息生成该申请请求所申请的监管码的时间码段，保证了同一时刻申请的多个监管码的时间码段不同，从而避免了同一时刻申请的多个监管码重复。

图19为本公开实施例十五提供的监管码生成方法的流程图，在图17所示实施例的基础上，该方法包括如下步骤：

步骤S1501、接收申请设备发送的申请请求，所述申请请求用于申请监管码，所述申请请求包括货物名称、以及所需申请的监管码的数量。

步骤S1501与步骤S1301一致，具体方法此处不再赘述。

步骤S1502、根据所述货物名称，确定监管码的前缀。

步骤S1502与步骤S1302一致，具体方法此处不再赘述。

步骤S1503、确定在所述时间信息所标识的时刻接收到的申请请求的个数。

所述时间信息是步骤S402中所述的追溯平台接收所述申请请求时的时间信息。在所述时间信息所标识的时刻接收到的申请请求的个数为N，N大于1。所述时间信息对应有M个不同的码段序号，M大于或等于N。

步骤S1503与步骤S602一致，具体方法此处不再赘述。

步骤S1504、从所述M个不同的码段序号中获取N个不同的码段序号。

步骤S1504与步骤S603一致，具体方法此处不再赘述。

步骤S1505、根据所述时间信息和所述N个不同的码段序号，生成N个不同的时间码段，每个时间码段包括所述时间信息和所述N个不同的码段序号中的一个码段序号，一个申请请求对应一个时间码段。

步骤S1505与步骤S604一致，具体方法此处不再赘述。

步骤S1506、根据所需申请的监管码的数量，确定每个监管码的序列号，所述每个监管码的序列号连续递增。

步骤S1507、对所述前缀、所述时间码段、所述序列号构成的序列进行校验，生成监管码的校验位。

步骤S1508、将所述前缀、所述时间码段、所述序列号、以及所述校验位构成所述监管码。

步骤S1509、将所述监管码发送给所述申请设备。

步骤S1506与步骤S32一致，步骤S1507与步骤S33一致，步骤S1508与步骤S34一致，具体方法此处不再赘述。

本实施例中，每个时间信息对应有多个不同的码段序号，多个不同的码段序号可标识同一时刻内追溯平台接收到的多个并发的申请请求，追溯平台从该同一时刻标识的时间信息对应的多个不同的码段序号中给每个申请请求分配一个码段序号，根据时间信息和码段序号生成该申请请求所申请的监管码的时间码段，保证了同一时刻申请的多个监管码的时间码段不同，从而避免了同一时刻申请的多个监管码重复。

图20为本公开实施例十六提供的监管码生成方法的流程图，在图17所示实施例的基础上，该方法包括如下步骤：

步骤S1601、接收申请设备发送的申请请求，所述申请请求用于申请监管码，所述申请请求包括货物名称、以及所需申请的监管码的数量。

步骤S1601与步骤S1301一致，具体方法此处不再赘述。

步骤S1602、根据所述货物名称，确定监管码的前缀。

步骤S1602与步骤S1302一致，具体方法此处不再赘述。

步骤S1603、确定在所述时间信息所标识的时刻接收到的申请请求的个数。

所述时间信息是步骤S402中所述的追溯平台接收所述申请请求时的时间信息。在所述时间信息所标识的时刻接收到的申请请求的个数为N，N大于1。所述时间信息对应有M个不同的码段序号，M小于N。

步骤S1603与步骤S1002一致，具体方法此处不再赘述。

步骤S1604、根据所述时间信息和所述M个不同的码段序号，确定N个申请请求中M个申请请求分别对应的时间码段，每个时间码段包括所述时间信息和一个码段序号。

步骤S1604与步骤S1003一致，具体方法此处不再赘述。

步骤S1605、在所述时间信息上增加预设的时间偏移，生成第二时间偏移信息。

步骤S1605与步骤S1004一致，具体方法此处不再赘述。

步骤S1606、根据所述第二时间偏移信息，确定所述N个申请请求中除所述M个申请请求之外的申请请求分别对应的时间码段。

步骤S1606与步骤S1005一致，具体方法此处不再赘述。

步骤S1607、根据所需申请的监管码的数量，确定每个监管码的序列号，所述每个监管码的序列号连续递增。

步骤S1608、对所述前缀、所述时间码段、所述序列号构成的序列进行校验，生成监管码的校验位。

步骤S1609、将所述前缀、所述时间码段、所述序列号、以及所述校验位构成所述监管码。

步骤S1610、将所述监管码发送给所述申请设备。

步骤S1607与步骤S32一致，步骤S1608与步骤S33一致，步骤S1609与步骤S34一致，具体方法此处不再赘述。

本实施例，每个时间信息对应有多个不同的码段序号，多个不同的码段序号可标识同一时刻内追溯平台接收到的多个并发的申请请求，当追溯平台在同一时刻接收到的多个并发的申请请求的个数大于该时刻对应的多个不同的码段序号时，在该时刻的基础上增加预设的时间延时，根据延时后的时间信息确定申请请求的码段序号，根据时后的时间信息和码段序号生成该申请请求所申请的监管码的时间码段，保证了同一时刻申请的多个监管码的时间码段不同，从而避免了同一时刻申请的多个监管码重复。

图21为本公开实施例十七提供的监管码生成方法的流程图，该方法包括如下步骤：

步骤S1701、向服务器发送申请请求，所述申请请求用于申请监管码，所述申请请求包括货物名称、以及所需申请的监管码的数量。

本实施例的执行主体是申请设备，该申请设备可以是移动终端、计算机等终端设备。申请设备向服务器发送申请请求，该服务器可以是上述实施例所述的追溯平台，所述申请请求用于申请监管码，如图3所示，生产企业A可通过申请设备11向追溯平台申请监管码，生产企业B可通过申请设备12向追溯平台申请监管码，生产企业C可通过申请设备13向追溯平台申请监管码，生产企业D可通过申请设备14向追溯平台申请监管码。申请请求包括货物名称、以及所需申请的监管码的数量。

步骤S1702、接收并显示所述服务器反馈的监管码。

其中，所述监管码由前缀、时间码段、序列号、以及校验位构成，所述前缀是所述服务器根据所述货物名称确定的，所述时间码段是所述服务器根据所述申请请求关联的时间信息确定的，每个监管码的序列号是所述服务器根据所需申请的监管码的数量确定的，所述每个监管码的序列号连续递增，所述校验位是所述服务器对所述前缀、所述时间码段、所述序列号构成的序列进行校验生成的。

追溯平台根据货物名称，确定监管码的前缀；至少根据所述申请请求关联的时间信息，确定时间码段；根据所需申请的监管码的数量，确定每个监管码的序列号，所述每个监管码的序列号连续递增；对所述前缀、所述时间码段、所述序列号构成的序列进行校验，生成监管码的校验位；将所述前缀、所述时间码段、所述序列号、以及所述校验位构成所述监管码。追溯平台将生成的监管码反馈给申请设备。

追溯平台根据申请请求生成监管码的方法与上述实施例中的方法一致，此处不再赘述。

本实施例中，时间码段与时间信息关联，由于时间信息是一个可持续变化的信息，随着时间的增加，时间信息可持续增加，保证时间码段可以被无限制申请，根据该时间码段生成监管码，从而实现了监管码可以被无限制申请。

图22为本公开实施例一提供的服务器的结构示意图，上述实施例中的追溯平台具体可实现为本实施中的服务器，如图22所示，该服务器包括接收单元和处理单元。

所述接收单元，用于接收申请设备发送的申请请求。

所述处理单元，耦合到所述接收单元，用于至少根据所述申请请求关联的时间信息，确定时间码段。

本实施例中，时间码段与时间信息关联，由于时间信息是一个可持续变化的信息，随着时间的增加，时间信息可持续增加，保证时间码段可以被无限制申请，根据该时间码段生成监管码，从而实现了监管码可以被无限制申请。

在图22所示实施例基础上，所述处理单元还用于至少根据所述时间码段，生成监管码。

所述服务器还包括发送单元，发送单元耦合到所述处理单元，用于将所述监管码发送给所述申请设备。

可选的，所述处理单元具体用于至少根据接收所述申请请求时的时间信息，确定时间码段。

进一步的，所述处理单元还用于确定在所述时间信息所标识的时刻接收到的申请请求的个数。

可选的，在所述时间信息所标识的时刻接收到的申请请求的个数为N，N大于1；所述处理单元具体用于在所述时间信息上分别增加N个不同的时间偏移，生成N个第一时间偏移信息，一个申请请求对应一个第一时间偏移信息；根据各申请请求对应的第一时间偏移信息，确定所述时间码段，所述时间码段包括所述第一时间偏移信息。

另外，在其他实施例中，在所述时间信息所标识的时刻接收到的申请请求的个数为N，N大于1；所述时间信息对应有M个不同的码段序号，M大于或等于N；所述处理单元具体用于从所述M个不同的码段序号中获取N个不同的码段序号；根据所述时间信息和所述N个不同的码段序号，生成N个不同的时间码段，每个时间码段包括所述时间信息和所述N个不同的码段序号中的一个码段序号，一个申请请求对应一个时间码段。

此外，在其他实施例中，在所述时间信息所标识的时刻接收到的申请请求的个数为N，N大于1；所述时间信息对应有M个不同的码段序号，M小于N；所述处理单元具体用于根据所述时间信息和所述M个不同的码段序号，确定N个申请请求中M个申请请求分别对应的时间码段，每个时间码段包括所述时间信息和一个码段序号；在所述时间信息上增加预设的时间偏移，生成第二时间偏移信息；根据所述第二时间偏移信息，确定所述N个申请请求中除所述M个申请请求之外的申请请求分别对应的时间码段。

本实施例中，当追溯平台同一时刻接收到多个申请请求时，追溯平台在该时刻对应的时间信息上分别增加多个不同的时间偏移，生成多个第一时间偏移信息，一个申请请求对应一个第一时间偏移信息，根据每个申请请求对应的第一时间偏移信息生成该申请请求所申请的监管码的时间码段，保证了同一时刻申请的多个监管码的时间码段不同，从而避免了同一时刻申请的多个监管码重复。

图23为本公开实施例二提供的服务器的结构示意图，上述实施例中的追溯平台具体可实现为本实施中的服务器，如图23所示，该服务器包括接收单元、处理单元、以及发送单元。

所述接收单元，用于接收申请设备发送的申请请求，所述申请请求用于申请监管码，所述申请请求包括货物名称、以及所需申请的监管码的数量。

所述处理单元，耦合到所述接收单元和所述发送单元，用于根据所述货物名称，确定监管码的前缀；至少根据所述申请请求关联的时间信息，确定时间码段；根据所需申请的监管码的数量，确定每个监管码的序列号，所述每个监管码的序列号连续递增；对所述前缀、所述时间码段、所述序列号构成的序列进行校验，生成监管码的校验位；将所述前缀、所述时间码段、所述序列号、以及所述校验位构成所述监管码。

所述发送单元，用于将所述监管码发送给所述申请设备。

可选的，处理单元具体用于根据所述货物名称，确定货物所属的种类；根据所述种类，确定所述监管码的前缀。

进一步的，所述处理单元具体用于至少根据所述接收单元接收所述申请请求时的时间信息，确定时间码段。

另外，在其他实施例中，所述处理单元具体用于至少根据处理所述申请请求时的时间信息，确定时间码段。

此外，在其他实施例中，所述申请请求包括所述时间信息，所述时间信息是用户通过所述申请设备设定的时间信息；所述处理单元具体用于至少根据所述申请请求中包括的所述时间信息，确定时间码段。

另外，所述处理单元还用于确定在所述时间信息所标识的时刻接收到的申请请求的个数。

可选的，在所述时间信息所标识的时刻接收到的申请请求的个数为N，N大于1；所述处理单元具体用于在所述时间信息上分别增加N个不同的时间偏移，生成N个第一时间偏移信息，一个申请请求对应一个第一时间偏移信息；根据各申请请求对应的第一时间偏移信息，确定所述时间码段，所述时间码段包括所述第一时间偏移信息。

另外，在其他实施例中，在所述时间信息所标识的时刻接收到的申请请求的个数为N，N大于1；所述时间信息对应有M个不同的码段序号，M大于或等于N；所述处理单元具体用于从所述M个不同的码段序号中获取N个不同的码段序号；根据所述时间信息和所述N个不同的码段序号，生成N个不同的时间码段，每个时间码段包括所述时间信息和所述N个不同的码段序号中的一个码段序号，一个申请请求对应一个时间码段。

此外，在其他实施例中，在所述时间信息所标识的时刻接收到的申请请求的个数为N，N大于1；所述时间信息对应有M个不同的码段序号，M小于N；所述处理单元具体用于根据所述时间信息和所述M个不同的码段序号，确定N个申请请求中M个申请请求分别对应的时间码段，每个时间码段包括所述时间信息和一个码段序号；在所述时间信息上增加预设的时间偏移，生成第二时间偏移信息；根据所述第二时间偏移信息，确定所述N个申请请求中除所述M个申请请求之外的申请请求分别对应的时间码段。

本实施例中，时间码段与时间信息关联，由于时间信息是一个可持续变化的信息，随着时间的增加，时间信息可持续增加，保证时间码段可以被无限制申请，根据该时间码段生成监管码，从而实现了监管码可以被无限制申请。

图24为本公开实施例三提供的服务器的结构示意图。参照图24，服务器1900包括处理组件1922，其进一步包括一个或多个处理器，以及由存储器1932所代表的存储器资源，用于存储可由处理组件1922的执行的指令，例如应用程序。存储器1932中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件1922被配置为执行指令，以执行上述步骤S301-S903的方法。

装置1900还可以包括一个电源组件1926被配置为执行装置1900的电源管理，一个有线或无线网络接口1950被配置为将装置1900连接到网络，和一个输入输出(I/O)接口1958。装置1900可以操作基于存储在存储器1932的操作系统，例如Windows ServerTM，MacOS XTM，UnixTM,LinuxTM，FreeBSDTM或类似。

图25为本公开实施例一提供的终端设备的结构示意图，上述实施例中的申请设备具体可实现为本实施中的终端设备，如图25所示，该终端设备包括：发送器和接收器。

所述发送器，用于向服务器发送申请请求，所述申请请求用于申请监管码，所述申请请求包括货物名称、以及所需申请的监管码的数量。

所述接收器，用于接收所述服务器反馈的监管码。

其中，所述监管码由前缀、时间码段、序列号、以及校验位构成，所述前缀是所述服务器根据所述货物名称确定的，所述时间码段是所述服务器根据所述申请请求关联的时间信息确定的，每个监管码的序列号是所述服务器根据所需申请的监管码的数量确定的，所述每个监管码的序列号连续递增，所述校验位是所述服务器对所述前缀、所述时间码段、所述序列号构成的序列进行校验生成的。

如图25所示，终端设备还包括显示器，耦合到所述接收器，用于显示所述服务器反馈的监管码。

可选的，所述时间信息是所述服务器接收到所述申请请求时的时间信息。

另外，在其他实施例中，所述时间信息是所述服务器处理所述申请请求时的时间信息。

此外，在其他实施例中，所述申请请求还包括所述时间信息，所述时间信息是用户通过所述申请设备设定的时间信息。

本实施例中，时间码段与时间信息关联，由于时间信息是一个可持续变化的信息，随着时间的增加，时间信息可持续增加，保证时间码段可以被无限制申请，根据该时间码段生成监管码，从而实现了监管码可以被无限制申请。

图26为本公开实施例二提供的终端设备的结构示意图，如图26所示，参照图26，终端设备2000可以包括以下一个或多个组件：处理组件2002，存储器2004，电源组件2006，多媒体组件2008，音频组件2010，输入/输出(I/O)接口2012，传感器组件2014，以及通信组件2016。

处理组件2002通常控制终端设备2000的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件2002可以包括一个或多个处理器2020来执行指令，以完成上述的方法。此外，处理组件2002可以包括一个或多个模块，便于处理组件2002和其他组件之间的交互。例如，处理组件2002可以包括多媒体模块，以方便多媒体组件2008和处理组件2002之间的交互。

存储器2004被配置为存储各种类型的数据以支持在终端设备2000的操作。这些数据的示例包括用于在终端设备2000上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器2004可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件2006为终端设备2000的各种组件提供电力。电源组件2006可以包括电源管理系统，一个或多个电源，及其他与为终端设备2000生成、管理和分配电力相关联的组件。

多媒体组件2008包括在终端设备2000和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件2008包括一个前置摄像头和/或后置摄像头。当终端设备2000处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件2010被配置为输出和/或输入音频信号。例如，音频组件2010包括一个麦克风(MIC)，当终端设备2000处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器2004或经由通信组件2016发送。在一些实施例中，音频组件2010还包括一个扬声器，用于输出音频信号。

输入/输出接口2012为处理组件2002和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件2014包括一个或多个传感器，用于为终端设备2000提供各个方面的状态评估。例如，传感器组件2014可以检测到终端设备2000的打开/关闭状态，组件的相对定位，例如所述组件为终端设备2000的显示器和小键盘，传感器组件2014还可以检测终端设备2000或终端设备2000一个组件的位置改变，用户与终端设备2000接触的存在或不存在，终端设备2000方位或加速/减速和终端设备2000的温度变化。传感器组件2014可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件2014还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件2014还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件2016被配置为便于终端设备2000和其他设备之间有线或无线方式的通信。终端设备2000可以接入基于通信标准的无线机载，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件2016经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件2016还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，终端设备2000可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器2004，上述指令可由终端设备2000的处理器2020执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

一种非临时性计算机可读存储介质，当所述存储介质中的指令由终端设备的处理器执行时，使得终端设备能够执行一种监管码生成方法，所述方法包括：

向服务器发送申请请求，所述申请请求用于申请监管码，所述申请请求包括货物名称、以及所需申请的监管码的数量。

接收所述服务器反馈的监管码。

其中，所述监管码由前缀、时间码段、序列号、以及校验位构成，所述前缀是所述服务器根据所述货物名称确定的，所述时间码段是所述服务器根据所述申请请求关联的时间信息确定的，每个监管码的序列号是所述服务器根据所需申请的监管码的数量确定的，所述每个监管码的序列号连续递增，所述校验位是所述服务器对所述前缀、所述时间码段、所述序列号构成的序列进行校验生成的。

图27为本公开实施例提供的监管码生成系统的结构示意图，如图27所示，该监管码生成系统包括：服务器1、终端设备2，该服务器可以是图22-24任一所示实施例中的服务器，该终端设备可以是图25或图26所示实施例中的终端设备。

最后应说明的是：以上各实施例仅用以说明本公开的技术方案，而非对其限制；尽管参照前述各实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本公开各实施例技术方案的范围。

本申请为申请日为2016年06月30日，申请号为“201610511308.1”，发明名称为“监管码生成方法、装置及服务器”的发明专利的分案申请。