首页> 中国专利> 电子政务的实现方法和电子政务系统

电子政务的实现方法和电子政务系统

摘要

本发明涉及一种电子政务的实现方法,所述方法包括:建立电子政务系统架构,所述电子政务系统架构包括业务层、服务层、表现层和数据访问层;通过所述服务层接收多个部门对市场主体的监管事项并将多个监管事项发送至所述业务层,所述监管事项是所述部门根据所述市场主体的工商登记信息确定的;利用所述业务层将所述多个监管事项生成所述市场主体的监管任务,并将所述监管任务通过所述表现层发送至对应的社区管理员;通过所述表现层接收所述社区管理员执行所述监管任务所得到的监管信息,并通过数据访问层将所述监管信息存储至数据库。采用本方法能够有效实现多个政府部门、社区与市场主体之间的数据信息交互。此外还提供一种电子政务系统。

著录项

  • 公开/公告号CN105096034A

    专利类型发明专利

  • 公开/公告日2015-11-25

    原文格式PDF

  • 申请/专利权人 广东建邦计算机软件有限公司;

    申请/专利号CN201510392083.8

  • 发明设计人 叶建辉;

    申请日2015-07-02

  • 分类号G06Q10/06(20120101);G06Q50/26(20120101);G06F17/30(20060101);

  • 代理机构44224 广州华进联合专利商标代理有限公司;

  • 代理人邓云鹏

  • 地址 523000 广东省东莞市东城区同沙东城科技园第一栋之二

  • 入库时间 2023-12-18 12:21:18

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2022-04-08

    专利权人的姓名或者名称、地址的变更 IPC(主分类):G06Q10/06 专利号:ZL2015103920838 变更事项:专利权人 变更前:广东建邦计算机软件股份有限公司 变更后:广东建邦计算机软件股份有限公司 变更事项:地址 变更前:523000 广东省东莞市东城区同沙东城科技园石井工业区第一栋之二 变更后:523000 广东省东莞市南城街道黄金路1号天安数码城2栋2单元1501室

    专利权人的姓名或者名称、地址的变更

  • 2018-07-27

    授权

    授权

  • 2016-01-27

    著录事项变更 IPC(主分类):G06Q10/06 变更前: 变更后: 申请日:20150702

    著录事项变更

  • 2015-12-23

    实质审查的生效 IPC(主分类):G06Q10/06 申请日:20150702

    实质审查的生效

  • 2015-11-25

    公开

    公开

说明书

技术领域

本发明涉及计算机网络技术领域,特别是涉及一种电子政务的实现方法和 电子政务系统。

背景技术

随着互联网技术的发展,电子政务已经逐步成为我国各级政府工作中的重 要内容,如智慧城市建设、专业化的政府服务网站等,工商、税务、水利、安 监和环保等政府部门也推出各种网上窗口业务。但这些电子政务仅限于与行政 管理相结合的“柜台式”的管理模型,各政府部门之间由于行业管理的限制而 信息资源未得到充分的整合利用。在很多情况下,市场主体还是需要跑多个政 府部门办理手续后才能取得相应的资格。随着商事改革的推进,市场主体的工 商登记条件得以放宽,将市场主体后续的监管任务融入到社区日常的管理中, 是一种新型的管理手段。市场主体可以只与一个政府部门建立联系后,便可得 到相应的政府业务辅导。如何实现多个政府部门、社区与市场主体之间的数据 信息交互也就成为目前需要解决的一个技术难题。

发明内容

基于此,有必要针对上述技术问题,提供一种能够有效实现多个政府部门、 社区与市场主体之间的数据信息交互的电子政务的实现方法和电子政务系统。

一种电子政务的实现方法,所述方法包括:

建立电子政务系统架构,所述电子政务系统架构包括业务层、服务层、表 现层和数据访问层;

通过所述服务层接收多个部门对市场主体的监管事项并将多个监管事项发 送至所述业务层,所述监管事项是所述部门根据所述市场主体的工商登记信息 确定的;

利用所述业务层将所述多个监管事项生成所述市场主体的监管任务,并将 所述监管任务通过所述表现层发送至对应的社区管理员;

通过所述表现层接收所述社区管理员执行所述监管任务所得到的监管信 息,并通过数据访问层将所述监管信息存储至数据库。

在其中一个实施例中,在所述通过所述表现层接收所述社区管理员执行所 述监管任务所得到的监管信息,并通过数据访问层将所述监管信息存储至数据 库的步骤之后,还包括:

通过所述表现层接收用户查询请求;

通过服务层将所述用户查询请求发送至所述数据访问层;

通过所述数据访问层获取数据库中预存的与所述用户查询请求对应的业务 数据;

通过所述业务层调用所述业务数据并进行处理,并将处理后的业务数据返 回至所述表现层。

在其中一个实施例中,在所述通过所述服务层接收多个部门对市场主体的 监管事项,并将多个监管事项发送至所述业务层的步骤之后,还包括:

通过所述表现层组建多个部门人员与多个社区管理员的群组;

通过所述表现层接收所述群组的交互信息。

在其中一个实施例中,在所述通过所述服务层接收多个部门对市场主体的 监管事项,并将多个监管事项发送至所述业务层的步骤之后,还包括:

通过所述表现层接收市场主体人员通过商事终端输入的位置信息;

将所述监管任务通过所述表现层发送至与所述位置信息对应的社区管理 员。

在其中一个实施例中,在所述通过所述服务层接收多个部门对市场主体的 监管事项并将多个监管事项发送至所述业务层的步骤之前,还包括:

获取市场主体的工商登记信息;

将所述工商登记信息推送至多个部门,以使得所述部门根据所述工商登记 信息确定相应的监管事项。

一种电子政务系统,所述系统包括:

第一服务器,用于接收多个部门对市场主体的监管事项并将多个监管事项 发送至第二服务器,所述监管事项是所述部门根据所述市场主体的工商登记信 息确定的;

第二服务器,用于将接收到的多个监管事项生成所述市场主体的监管任务, 并将所述监管任务通过所述第一服务器发送至第三服务器;

第三服务器,用于将所述监管任务发送至社区管理员对应的终端,接收所 述社区管理员执行所述监管任务时通过所述终端返回的监管信息,并将所述监 管信息发送至第四服务器;

第四服务器,用于将所述监管信息存储至数据库。

在其中一个实施例中,所述第三服务器还用于接收用户查询请求并将所述 用户查询请求发送至所述第一服务器;所述第一服务器还用于对所述用户查询 请求进行校验,并将校验后的用户查询请求发送至所述第四服务器;所述第四 服务器还用于获取数据库中预存的与所述校验后的用户查询请求对应的业务数 据,并将所述业务数据发送至所述第二服务器;所述第二服务器还用于调用所 述业务数据并进行处理,并将处理后的业务数据返回至所述第三服务器。

在其中一个实施例中,所述第三服务器还用于组建多个部门人员与多个社 区管理员的群组并接收所述群组中的交互信息。

在其中一个实施例中,所述第三服务器还用于接收市场主体人员通过商事 终端输入的位置信息;所述第二服务器还用于将与所述位置信息对应的社区管 理员配置到所述监管任务中,并将配置后的监管任务发送至所述第三服务器; 所述第三服务器还用于将所述配置后的监管信息发送至对应的社区管理员。

在其中一个实施例中,所述系统还包括第五服务器,所述第五服务器用于 获取市场主体的工商登记信息并将所述工商登记信息推送至多个部门,已使得 所述部门根据所述工商登记信息向所述第一服务器发送相应的监管事项。

上述电子政务的实现方法和电子政务系统,通过建立电子政务系统,利用 该电子政务系统接收多个部门对市场主体的监管事项,监管事项是部门根据市 场主体的工商登记信息所确定的,在将多监管事项生成相应的监管任务后,将 监管任务发送至社区管理员并接收到社区管理员返回的监管信息。因此市场主 体在提交了工商登记信息后,通过电子政务系统架构能够有效实现多个部门、 社区和市场主体之间的数据信息交互。

附图说明

图1为一个实施例中电子政务实现方法的流程图;

图2为一个实施例中电子政务系统架构的示意图;

图3为一个实施例中组件群组的示意图;

图4为一个实施例中电子政务系统的结构示意图;

图5为另一个实施例中电子政务系统的结构示意图;

图6为一个实施例中电子政务系统的硬件环境图。

具体实施方式

在一个实施例中,提供了电子政务的实现方法,该方法包括:

步骤102,建立电子政务系统架构,电子政务系统架构包括业务层、服务层、 表现层和数据访问层。

为了便于对电子政务系统进行开发、部署和扩展,采用结构化语言建立电 子政府系统架构,包括业务层、服务层、表现层、数据访问层和数据库,如图2 所示。其中业务层包括了电子政务系统所需功能的业务对象,与数据访问层和 表现层进行交互。业务层中可以包括多个业务对象,每个业务对象可以包括多 个子业务对象。业务层对每个子业务对象对应的业务数据进行处理。

步骤104,通过服务层接收多个部门对市场主体的监管事项并将多个监管事 项发送至业务层,监管事项是部门根据市场主体的工商登记信息确定的。

部门是指政府部门,包括工商部门、安监部门、消防部门等。多个部门分 别对该电子政务系统开放了相应的数据接口。服务层包括多个数据接口,通过 部门开放的数据接口与服务层中的数据接口来接收多个部门对市场主体的监管 事项。

步骤106,利用业务层将多个监管事项生成市场主体的监管任务,并将监管 任务通过表现层发送至对应的社区管理员。

业务层中包括社区管理业务对象和部门管理业务对象。业务层将接收到的 监管事项作为业务数据,根据对应的部门管理业务对象生成市场主体的监管任 务。针对一个市场主体的多项监管事项,可以生成多项监管任务,也可以生成 一项监管任务。每个监管事项都具有对应的等级,每个等级都设有对应的监管 频率。例如,监管频率为每月检查一次或每季度检查一次。等级相同的监管事 项也就是监管频率相同的监管事项,可以合并生成一项监管任务。等级不同的 监管事项需要按照监管频率来生成不同的监管任务。进一步的,业务层还可以 根据社区管理业务对象对应的业务数据与监管事项共同生成市场主体的监管任 务。

步骤108,通过表现层接收社区管理员执行监管任务所得到的监管信息,并 通过数据访问层将监管信息存储至数据库。

将监管任务通过服务层中的数据接口发送至表现层。表现层中包括多个应 用程序。社区管理员可以在终端安装社区监管第一应用程序,登录社区监管第 一应用程序后接入表现层,可接收到业务层生成的监管任务。社区管理员将执 行监管任务得到的监管信息通过终端上安装的社区监管第一应用程序返回至表 现层。数据访问层中包括数据仓库接口和数据库操作接口,通过数据访问层中 的数据仓库接口和/或数据库操作接口,将接收到的监管信息存储至数据库。数 据库可以采用SQL(StructuredQueryLanguage,结构化查询语言)数据库、Oracle (甲骨文股份有限公司)数据库或者分布式海量数据存储库等。

本实施例中,建立电子政务系统架构,电子政务系统架构包括业务层、服 务层、表现层和数据访问层;通过服务层接收多个部门对市场主体的监管事项 并将多个监管事项发送至业务层,监管事项是部门根据市场主体的工商登记信 息确定的;利用业务层将多个监管事项生成市场主体的监管任务,并将监管任 务通过表现层发送至对应的社区管理员;通过表现层接收社区管理员执行监管 任务所得到的监管信息,并通过数据访问层将监管信息存储至数据库。通过建 立电子政务系统架构,利用该架构中的服务层能够接收多个部门对市场主体的 监管事项,监管事项是部门根据市场主体的工商登记信息所确定的,在业务层 将多监管事项生成相应的监管任务后,表现层将监管任务发送至社区管理员并 接收到社区管理员返回的监管信息。因此市场主体在提交了工商登记信息后, 通过电子政务系统架构能够有效实现多个部门、社区和市场主体之间的数据信 息交互。

在一个实施例中,电子政务系统架构还包括数据访问层,在通过表现层接 收社区管理员执行监管任务所得到的监管信息,并通过数据访问层将监管信息 存储至数据库的步骤之后,还包括:通过表现层接收用户查询请求;通过服务 层将用户查询请求发送至数据访问层;通过数据访问层获取数据库中预存的与 用户查询请求对应的业务数据;通过业务层调用业务数据并进行处理,并将处 理后的业务数据返回至表现层。

本实施例中,用户包括社区管理员、社区领导、部门人员、市场主体人员 等。表现层中可以承载多个应用程序,不同的用户可以在终端上安装不同的应 用程序。用户安装应用程序后,可注册相应的应用程序账号。用户利用应用程 序账号登录到应用程序,即接入到表现层。服务层中包括多个数据接口,即表 现层的每个应用程序在服务层都设有对应的数据接口。用户通过表现层的应用 程序发送用户查询请求。具体的,社区管理员在执行监管任务时可以通过社区 监管第一应用程序发送与监管任务相关的查询请求;社区领导可以通过社区监 管第二应用程序发送查看整个社区或者多个社区内的监管信息的查询请求,其 中社区监管第二应用程序对应的应用程序账号具有不同的权限,社区领导根据 该应用程序账号的权限来查询相应的监管信息;部门人员在确定监管事项后可 以通过社区监管第三应用程序来发送监管任务执行状况的查询请求;市场主体 人员在提交工商登记信息后可以通过商事应用程序发送查看需要办理业务或许 可证的查询请求等。通过服务层中与应用程序对应的数据接口对用户查询请求 进行校验,校验包括安全性校验和合法性校验等,如果应用程序证号具有相应 的权限,服务层还需进行权限校验。校验通过后,数据访问层获取数据库中预 存的与用户查询请求对应的业务数据。业务层中包括多个业务对象,业务层调 用这些业务数据并利用相应的业务对象进行数据处理,并将处理后的业务数据 通过服务层中与应用程序对应的数据接口返回至表现层中的应用程序,通过应 用程序在终端进行展示。通过接收用户查询请求并返回相应的处理后的业务数 据的数据处理方式,由此能够方便多种用户根据不同需求主动查询相应业务数 据,从而进一步实现了多个部门、社区和市场主体之间的数据信息交互。

进一步的,表现层还包括了多个子平台,通过表现层的子平台接收用户查 询请求,用户查询请求经过服务层校验后,通过数据访问层获取与用户查询请 求对应的业务数据,经过业务层对业务数据处理后,将处理后的业务数据在表 现层以网页的形式进行展示。

在一个实施例中,在通过服务层接收多个部门对市场主体的监管事项,并 将多个监管事项发送至业务层的步骤之后,还包括:通过表现层组建多个部门 人员与多个社区管理员的群组;通过表现层接收所述群组的交互信息。

本实施例中,部门人员可以与社区管理员进行在线交流。具体的,表现层 根据多个部门人员对应的应用程序账号、多个社区管理员对应的应用程序账号 可以创建群组。部门人员和社区管理员分别登录应用程序后,即分别接入表现 层后,可以通过该群组进行在线交流。社区管理员可以向部门人员汇报监管任 务的执行状况,部门人员也可以对社区管理员进行辅导以便于社区管理员能够 规范化地执行监管任务,如图3所示。进一步的,表现层还可以创建多个群组。 具体的,表现层可以根据社区管理员对应的应用程序账号、多个市场主体人员 对应的应用程序账号创建群组。表现层还可以根据多个市场主体人员对应的应 用程序账号创建群组。通过创建群组进行在线交流,能够方便多个部门人员、 社区管理员和市场主体人员利用群组进行交互,进一步实现了部门与社区之间 的数据信息交互。

在一个实施例中,在通过服务层接收多个部门对市场主体的监管事项,并 将多个监管事项发送至业务层的步骤之后,还包括:通过表现层接收市场主体 人员通过商事终端输入的位置信息;将监管任务通过表现层发送至与位置信息 对应的社区管理员。

本实施例中,市场主体人员在工商部门提交工商登记信息后,在商事终端 上输入市场主体的位置信息,包括所属社区以及社区网格。商事终端通过网络 接入表现层,表现层可以接收到通过商事终端输入的市场主体的位置信息。并 将该位置信息发送至业务层,业务层将与位置信息对应的社区管理员配置到监 管任务中,并将配置后的监管任务通过表现层发送至对应的社区管理员。通过 接收市场主体的位置信息,可以自动将与位置信息对应的社区管理员配置到监 管任务中,进而可以通过社区管理员来执行监管任务。

在一个实施例中,在通过服务层接收多个部门对市场主体的监管事项,并 将多个监管事项发送至业务层的步骤之前,还包括:获取市场主体的工商登记 信息;将工商登记信息推送至多个部门,以使得部门根据工商登记信息确定相 应的监管事项。

本实施例中,在市场主体在工商部门提交工商登记信息后,工商部门将工 商登记信息发送至共享信息平台。共享信息平台识别工商登记信息中的关键字, 根据识别出的关键字将市场主体的工商登记信息推送至多个部门。关键字包括 地址位置关键字、经营范围关键字、营业面积关键字等。例如,对于营业面积 大于150平米的市场主体,需要取得消防部门的消防许可证。共享信息平台根 据工商登记信息识别出市场主体的营业面积大于150平米后,将该市场主体的 工商登记信息推送至消防部门。消防部门会根据接收到的工商登记信息确定该 市场主体需要办理消防许可证的监管事项,并发送至电子政务系统。由此实现 了多个部门与社区之间的数据信息交互。

在一个实施例中,如图4所示,还提供了一种电子政务系统,其特征在于, 所述系统包括:第一服务器402、第二服务器404、第三服务器406和第四服务 器408,其中:

第一服务器402,用于接收多个部门对市场主体的监管事项并将多个监管事 项发送至第二服务器404,监管事项是部门根据市场主体的工商登记信息确定 的。

第二服务器404,用于将接收到的多个监管事项生成市场主体的监管任务, 并将监管任务通过第一服务器发送至第三服务器406。

第三服务器406,用于将监管任务发送至社区管理员对应的终端,接收社区 管理员执行监管任务时通过终端返回的监管信息,并将监管信息发送至第四服 务器408。

第四服务器408,用于将监管信息存储至数据库。

本实施例中,第一服务器402、第二服务器404、第三服务器406、第四服 务器408可以分布部署在不同的物理服务器,也可以部署在同一台物理服务器。 多个部门分布对第一服务器402开发了相应的数据接口。第一服务器402通过 部门开放的数据接口来接收多个部门对市场主体的监管事项。第二服务器404 将接收到的多个监管事项生成市场主体的监管任务。针对一个市场主体的多项 监管事项,可以生成多项监管任务,也可以生成一项监管任务。每个监管事项 都具有对应的等级,每个等级都设有对应的监管频率。例如,监管频率为每月 检查一次或每季度检查一次。等级相同的监管事项也就是监管频率相同的监管 事项,可以合并生成一项监管任务。等级不同的监管事项需要按照监管频率来 生成不同的监管任务。进一步的,第二服务器404还可以根据社区管理的业务 数据与监管事项共同生成市场主体的监管任务。第三服务器406将监管任务发 送至社区管理员对应的终端。社区管理员可以在终端安装社区监管第一应用程 序,社区管理员将执行监管任务得到的监管信息通过终端上安装的社区监管第 一应用程序返回至第三服务器406。第四服务器408中包括数据仓库接口和数据 库操作接口,通过第四服务器408中的数据仓库接口和/或数据库操作接口,将 接收到的监管信息存储至数据库。数据库可以采用SQL数据库、Oracle数据库 或者分布式海量数据存储库等。

本实施例中,通过第一服务器接收多个部门对市场主体的监管事项,监管 事项是部门根据市场主体的工商登记信息所确定的。在第二服务器将多监管事 项生成相应的监管任务后,将监管任务通过第三服务器发送至社区管理员并接 收到社区管理员返回的监管信息。因此市场主体在提交了工商登记信息后,能 够有效实现多个部门、社区和市场主体之间的数据信息交互。

在一个实施例中,第三服务器406还用于接收用户查询请求并将用户查询 请求发送至第一服务器402;第一服务器402还用于对用户查询请求进行校验, 并将校验后的用户查询请求发送至第四服务器408;第四服务器408还用于获取 数据库中预存的与校验后的用户查询请求对应的业务数据,并将业务数据发送 至第二服务器404;第二服务器404还用于调用业务数据并进行处理,并将处理 后的业务数据返回至第三服务器406。

本实施例中,用户包括社区管理员、社区领导、部门人员、市场主体人员 等。不同的用户可以在终端上安装不同的应用程序。用户安装应用程序后,可 注册相应的应用程序账号。用户利用应用程序账号登录到应用程序,即接入到 第三服务器406。第一服务器402中包括多个数据接口,接入第三服务器406的 每个应用程序在第一服务器402都设有对应的数据接口。用户通过第三服务器 406的应用程序发送用户查询请求。具体的,社区管理员在执行监管任务时可以 通过社区监管第一应用程序发送与监管任务相关的查询请求;社区领导可以通 过社区监管第二应用程序发送查看整个社区或者多个社区内的监管信息的查询 请求,其中社区监管第二应用程序对应的应用程序账号具有不同的权限,社区 领导根据该应用程序账号的权限来查询相应的监管信息;部门人员在确定监管 事项后可以通过社区监管第三应用程序来发送监管任务执行状况的查询请求; 市场主体人员在提交工商登记信息后可以通过商事应用程序发送查看需要办理 业务或许可证的查询请求等。通过第一服务器402中与应用程序对应的数据接 口对用户查询请求进行校验,校验包括安全性校验和合法性校验等,如果应用 程序证号具有相应的权限,服务层还需进行权限校验。校验通过后,第一服务 器402将校验后的用户查询请求发送至第四服务器408数据访问层获取数据库 中预存的与用户查询请求对应的业务数据。第二服务器404还用于调用业务数 据并进行处理,并将处理后的业务数据返回至第三服务器406。第三服务器406 将处理后的业务数据通过应用程序返回至终端,在终端进行展示。通过接收用 户查询请求并返回相应的处理后的业务数据的数据处理方式,由此能够方便多 种用户根据不同需求主动查询相应业务数据,从而进一步实现了多个部门、社 区和市场主体之间的数据信息交互。

在一个实施例中,第三服务器406还用于组建多个部门人员与多个社区管 理员的群组并接收群组中的交互信息。

本实施例中,第三服务器406根据多个部门人员对应的应用程序账号、多 个社区管理员对应的应用程序账号可以创建群组。部门人员和社区管理员分别 登录应用程序后,可以通过该群组进行在线交流。进一步的,第三服务器406 可以根据社区管理员对应的应用程序账号、多个市场主体人员对应的应用程序 账号创建群组,还可以根据多个市场主体人员对应的应用程序账号创建群组。 通过创建群组进行在线交流,能够方便多个部门人员、社区管理员和市场主体 人员利用群组进行交互,进一步实现了部门与社区之间的数据信息交互。在一 个实施例中,第三服务器还用于接收市场主体人员通过商事终端输入的位置信 息;第二服务器还用于将与位置信息对应的社区管理员配置到监管任务中,并 将配置后的监管任务发送至第三服务器;第三服务器还用于将配置后的监管信 息发送至对应的社区管理员。

本实施例中,市场主体人员在工商部门提交工商登记信息后,在商事终端 上输入市场主体的位置信息,包括所属社区以及社区网格。商事终端通过网络 接入第三服务器,第三服务器可以接收到通过商事终端输入的市场主体的位置 信息。并将该位置信息发送至第二服务器,第二服务器将与位置信息对应的社 区管理员配置到监管任务中,并将配置后的监管任务通过第三服务器发送至对 应的社区管理员。通过接收市场主体的位置信息,可以自动将与位置信息对应 的社区管理员配置到监管任务中,进而可以通过社区管理员来执行监管任务。

在一个实施例中,如图5所示,该系统还包括第五服务器410,第五服务器 用于获取市场主体的工商登记信息并将工商登记信息推送至多个部门,已使得 部门根据工商登记信息向第一服务器402发送相应的监管事项。

本实施例中,在市场主体在工商部门提交工商登记信息后,工商部门将工 商登记信息发送至第五服务器410。第五服务器410与第一服务器402、第二服 务器404、第三服务器406和第四服务器408可以部署在同一物理服务器上,也 可以部署在不同的物理服务器上。优选的,第一服务器402、第二服务器404、 第三服务器406和第四服务器408部署在同一物理服务器上,第五服务器410 部署在另外一台物理服务器上。

第五服务器410识别工商登记信息中的关键字,根据识别出的关键字将市 场主体的工商登记信息推送至多个部门。关键字包括地址位置关键字、经营范 围关键字、营业面积关键字等。例如,对于营业面积大于150平米的市场主体, 需要取得消防部门的消防许可证。第五服务器根据工商登记信息识别出市场主 体的营业面积大于150平米后,将该市场主体的工商登记信息推送至消防部门。 消防部门会根据接收到的工商登记信息确定该市场主体需要办理消防许可证的 监管事项,由此实现了多个部门与社区之间的数据信息交互。

在一个实施例中,以第一服务器、第二服务器、第三服务器和第四服务器 部署在同一物理服务器上,第五服务器部署在另外一台物理服务器上为例进行 说明,电子政务系统的硬件环境图如图6所示。

工商终端602在记录市场主体612的工商登记信息后为该市场主体办理营 业执照,在办理营业执照后工商终端602通过网络将工商登记信息发送至第一 物理服务器604,第五服务器604通过对工商登记信息进行关键字识别将工商登 记信息推送至多个部门的部门终端606,部门根据工商登记信息确定监管事项 后,部门终端606通过网络向第二物理服务器608,第二物理服务器608根据监 管事项生成监管任务并将监管任务发送至社区管理员的监管终端610。社区管理 员利用监管终端610针对市场主体612执行监管任务,并将得到的监管信息通 过监管终端610上报至第二物理服务器608。

以上所述实施例的各技术特征可以进行任意的组合,为使描述简洁,未对 上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技 术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式,其描述较为具体和详细, 但并不能因此而理解为对发明专利范围的限制。应当指出的是,对于本领域的 普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干变形和改 进,这些都属于本发明的保护范围。因此,本发明专利的保护范围应以所附权 利要求为准。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号