互联网资源的获取方法及装置、理财产品的获取方法与流程

文档序号:12733820阅读:265来源:国知局
互联网资源的获取方法及装置、理财产品的获取方法与流程

本申请涉及互联网信息技术领域,尤其涉及一种互联网资源的获取方法及装置,以及一种理财产品的获取方法。



背景技术:

随着互联网信息技术的发展,出现了各种互联网资源(如网络存储资源、网络带宽资源、网络计算资源等、安全监控资源,简称资源)。用户可以通过账户获取不同类型的互联网资源满足不同的资源需求,也可以获取相同类型的互联网资源满足不同的需求,比如时限需求,属性需求等。

现有技术,用户通过同一账户根据不同需求类型获取到资源后,无法根据不同需求分别进行管理和监控。比如,用户在同一账户中先后分别请求两份网络存储资源,一份为了满足长期使用需求,一份是为了满足短期使用需求,但是在获取到两份网络存储资源后,会在该账户中将两份网络存储资源合并,在使用过程中无法管理使用哪部分网络存储资源,也无法掌控不同需求的网络存储资源分别的使用情况。又如,在使用资源时,会衍生出附加资源(如使用网络存储资源时,会根据使用量衍生出用于监控数据安全的安全监控资源),但现有技术用户通过同一账户根据不同需求请求资源并使用时,也无法监控附加资源属于哪部分资源。



技术实现要素:

本申请实施例提供一种互联网资源的获取方法,在用户根据不同需求请求互联网资源后,便于对不同需求的互联网资源分别管理和监控。

本申请实施例提供一种互联网资源的获取装置,在用户根据不同需求请求互联网资源后,便于对不同需求的互联网资源分别管理和监控。

本申请实施例提供一种理财产品的获取方法,在用户根据不同理财需求请求理财产品后,便于对不同理财需求的理财产品分别管理和监控。

本申请实施例采用下述技术方案:

一种互联网资源的获取方法,包括:

接收用户发送的互联网资源需求类型,以及针对所述需求类型的互联网资源请求;

根据所述请求,通过为所述需求类型建立的账户获取互联网资源;

将获取到的互联网资源关联到所述需求类型对应的账户中。

优选地,接收用户发送的互联网资源需求类型,以及针对所述需求类型的互联网资源请求,包括:

接收用户发送的互联网资源需求类型、所述需求类型下的需求计划,以及针对所述需求计划的互联网资源请求;

则所述方法具体包括:

根据所述请求,通过为所述需求计划建立的账户获取互联网资源;

将获取到的互联网资源关联到所述需求计划对应的账户中。

优选地,接收用户发送的互联网资源需求类型、所述需求类型下的需求计划,以及针对所述需求类型的互联网资源请求,包括:

接收用户发送的互联网资源需求类型;

根据所述需求类型和/或用户根据所述需求类型预设的偏好信息,展示互联网资源需求计划的推荐信息给所述用户;

接收用户发送的针对所述推荐信息的互联网资源请求。

优选地,根据所述请求,通过为所述需求类型建立的账户获取互联网资源,包括:

根据所述需求类型、以及所述互联网资源请求的时间,生成需求标识;

为所述需求类型建立账户,并建立所述需求类型、所述需求标识、以及所述账户的对应关系;

根据所述请求,通过为所述需求计划建立的账户获取互联网资源。

优选地,所述请求中包含至少两个互联网资源,则根据所述请求,通过为所述需求类型建立的账户获取互联网资源,包括:

根据所述请求包含的所述至少两个互联网资源以及总资源值,确定各互联网资源的请求值;

根据各互联网资源的请求值,通过为所述需求类型建立的账户获取所述各互联网资源。

一种互联网资源的获取装置,包括:接收单元、获取单元以及关联单元,其中,

所述接收单元,接收用户发送的互联网资源需求类型,以及针对所述需求类型的互联网资源请求;

所述获取单元,根据所述请求,通过为所述需求类型建立的账户获取互联网资源;

所述关联单元,将获取到的互联网资源关联到所述需求类型对应的账户中。

优选地,所述接收单元,

接收用户发送的互联网资源需求类型、所述需求类型下的需求计划,以及针对所述需求计划的互联网资源请求;

则所述获取单元,根据所述请求,通过为所述需求计划建立的账户获取互联网资源;

所述关联单元,将获取到的互联网资源关联到所述需求计划对应的账户中。

优选地,所述接收单元,

接收用户发送的互联网资源需求类型;

根据所述需求类型和/或用户根据所述需求类型预设的偏好信息,展示互联网资源需求计划的推荐信息给所述用户;

接收用户发送的针对所述推荐信息的互联网资源请求。

优选地,所述获取单元,

根据所述需求类型、以及所述互联网资源请求的时间,生成需求标识;

为所述需求类型建立账户,并建立所述需求类型、所述需求标识、以及所述账户的对应关系;

根据所述请求,通过为所述需求计划建立的账户获取互联网资源。

优选地,所述请求中包含至少两个互联网资源,则所述获取单元,

根据所述请求包含的所述至少两个互联网资源以及总资源值,确定各互联网资源的请求值;

根据各互联网资源的请求值,通过为所述需求类型建立的账户获取所述各互联网资源。

一种理财产品的获取方法,包括:

接收用户发送的理财类型,以及针对所述理财类型的理财产品请求;

根据所述请求,通过为所述理财类型建立的账户获取理财产品;

将获取到的理财产品关联到所述理财类型对应的账户中。

优选地,接收用户发送的理财类型,以及针对所述理财类型的理财产品请求,包括:

接收用户发送的理财类型、所述理财类型下的理财计划,以及针对所述理财计划的理财产品请求;

则所述方法具体包括:

根据所述请求,通过为所述理财计划建立的账户获取理财产品;

将获取到的理财产品关联到所述理财计划对应的账户中。

优选地,接收用户发送的理财类型、所述理财类型下的理财计划,以及针对所述理财类型的理财产品请求,包括:

接收用户发送的理财类型;

根据所述理财类型和/或用户的理财偏好信息,展示理财计划的推荐信息给所述用户;

接收用户发送的针对所述推荐信息的理财产品请求。

优选地,根据所述请求,通过为所述理财类型建立的账户获取理财产品,包括:

根据所述理财类型、以及所述理财产品请求的时间,生成理财标识;

为所述理财类型建立账户,并建立所述理财类型、所述理财标识、以及所述账户的对应关系;

根据所述请求,通过为所述理财计划建立的账户获取理财产品。

优选地,所述请求中包含至少两个理财产品,则根据所述请求,通过为所述理财类型建立的账户获取理财产品,包括:

根据所述请求包含的所述至少两个理财产品以及总数额,确定各理财产品的请求数额;

根据各理财产品的请求数额,通过为所述理财类型建立的获取所述各理财产品。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果:为用户提供不同的需求类型,并接收用户通过操作发送的互联网资源请求,根据该请求通过为需求类型建立的子账户去获取互联网资源,并将获取到的互联网资源关联到需求类型对应的子账户中。也就是为不同的需求类型建立对应的子账户,在用户请求互联网资源时,将请求到的互联网直接关联到子账户中,做到了不同需求类型下的互联网资源相互隔离,也就实现了根据不同需求分别进行管理和监控。

附图说明

此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:

图1为本申请实施例1提供的互联网资源的获取方法的流程示意图;

图2为本申请实施例1提供的选择需求类型的示意图;

图3为本申请实施例1提供的选择互联网资源的示意图;

图4为本申请实施例1提供的新建需求计划的示意图;

图5为本申请实施例1提供的新建需求计划的示意图;

图6为本申请实施例1提供的推荐候选计划的示意图;

图7为本申请实施例1提供的发送互联网资源请求的示意图;

图8为本申请实施例1提供的展示了用户拥有的需求类型的示意图;

图9为本申请实施例1提供的展示了用户拥有的需求计划的示意图;

图10为本申请实施例2提供的互联网资源的获取装置的结构框图;

图11为本申请实施例3提供的理财产品的获取方法的流程示意图;

图12为本申请实施例3提供的选择理财类型的示意图;

图13为本申请实施例3提供的选择理财产品的示意图;

图14为本申请实施例3提供的新建理财计划的示意图;

图15为本申请实施例3提供的新建理财计划的示意图;

图16为本申请实施例3提供的推荐候选计划的示意图;

图17为本申请实施例3提供的发送理财产品请求的示意图;

图18为本申请实施例3提供的展示了用户拥有的理财类型的示意图;

图19为本申请实施例3提供的展示了用户拥有的理财计划的示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。

以下结合附图,详细说明本申请各实施例提供的技术方案。

实施例1

如前所述,现有技术用户通过同一账户根据不同需求请求互联网资源后,无法根据不同需求分别进行管理和监控。比如,用户通过自己唯一的账户先后分别请求了1TB和500GB网络存储资源,其中,1TB希望长期使用,存放照片等希望永久保存的文件,500GB希望短期使用,用于存放体育比赛等时下流行的文件。但是在获取到两份网络存储资源后,在该账户中,会对两份互联网资源进行合并,合并为(近似)1.5TB,所以在使用过程中,用户无法控制是使用了1TB网络存储资源的部分还是500GB网络存储资源的部分,也就导致了无法得知这两部分网络存储资源的使用情况,又如,在使用网络存储资源过程中,会衍生出附加资源,如果将1TB和500GB合并为(近似)1.5TB,那么在使用过程中衍生出的附加资源也无法区分是由哪部分网络存储资源产生的。这违背了用户的期望,也就是用户希望通过不同需求,对不同需求下的网络存储资源分别进行管理和监控。另外,由于没有分别管理,如果出现文件丢失,也无法区分到底哪部分网络存储资源出现了问题。基于此缺陷,本发明人提供了一种互联网资源的获取方法,在用户根据不同需求请求互联网资源后,便于对不同需求的互联网资源分别管理和监控。该方法的具体流程示意图如图1所示,包括下述步骤:

步骤11:接收用户发送的互联网资源需求类型,以及针对该需求类型的互联网资源请求。

每个用户在进行互联网资源的请求、获取和使用过程中,都需要有一个账户,这里可以将用户的账户称为主账户,比如,用户在请求和使用互联网资源时,需要先注册一个账户,该账户就可以是称为用户的主账户。

现有技术用户通过主账户请求互联网资源时,只是自己主观了解请求时的目的,比如希望长期(5年)使用或者短期(3个月)使用,所以本步骤中可以为用户设定若干需求类型。如图2所示,以移动终端为例,在显示界面中,为用户提供了三种需求类型的选项,用户可以通过选项选择请求资源时的需求。在实际应用中,用户还可以自定义需求类型,比如在图2中提供自定义选项,可以自己定义一些个性化的描述等。在设定需求类型后,就可以如图3所示,选择针对该需求类型的资源并发送请求。

在实际应用中,用户可能存在对于相同的资源需求下的不同需求计划,也就是更加细化的需求。比如,即使是对网络存储资源有长期需求,也可能存在“照片”、“电影”等不同的需求计划,所以在一种实施方式中,为了达到对互联网资源需求进行细化的目的,本步骤可以包括:接收用户发送的互联网资源需求类型、需求类型下的需求计划,以及针对该需求计划的互联网资源请求。如图4所示为需求计划的展示界面,可供用户选择新建一个需求计划还是在已有需求计划下选择继续请求资源。当用户选择新建需求计划后,可以如图5所示,弹出对话框,让用户自行输入,或是可以展示预设的计划名称。当新建完需求计划后,就可以选择互联网资源,用户可以通过输入编号进行查找,也可以展示一些互联网资源以供用户选择,当选择完成后,就完成了发送互联网资源需求类型、需求类型下的需求计划,以及针对该需求计划的互联网资源请求的操作。

随着数据挖掘的发展,信息推荐成为了提升用户体验的重要手段,所以在一种实施方式中,接收用户发送的互联网资源需求类型、需求类型下的需求计划,以及互联网资源请求,可以包括:接收用户发送的互联网资源需求类型;根据需求类型和/或用户根据需求类型预设的偏好信息,展示互联网资源需求计划的推荐信息给用户;接收用户发送的针对推荐信息的互联网资源请求。具体地,用户可以预先根据不同的需求类型预先设定偏好信息,比如可以用过问卷调查形式,获取用户的偏好,或者从用户的历史行为记录中获取用户的偏好等。在用户通过如图4界面新建需求计划后,可以跳过如图5而直接展示如图6所示,当接收到用户发送的需求类型为短期需求后,可以根据需求类型和/或用户根据需求类型预设的偏好信息,为用户推荐“候选计划1”、“候选计划2”、“候选计划3”,等。

步骤12:根据请求,通过为该需求类型建立的账户获取互联网资源。

当接收到请求后,就可以根据请求去获取互联网资源,比如图3所示,当用户选择了“资源1”后,就可以去获取“资源1”。在实际应用中,请求业务往往需要有个发起者,在互联网中这个发起者通常是账户,所以在请求资源时往往也需要通过某个账户,由于为了达到各个需求类型相互隔离的目的,可以在获取到互联网资源之前,为用户选择的该需求类型建立一个账户,该账户可以附属在主账户下的子账户,也可以是独立的、与主账户建立了关联关系的账户,并为该账户和需求类型建立对应关系,在有了需求类型对应的账户后,就可以通过该账户去获取互联网资源。

考虑到用户可能会建立多次相同的需求类型(两个短期需求、三个长期需求等),在一种需求类型只有一种的情况下,可以比较容易建立需求类型和账户的对应关系,但是当相同的需求类型出现两种时,就需要先后建立两个账户,并且分别对应先后选择的需求类型,但是由于需求类型相同,就可能导致对应关系不明确,所以,为了达到需求类型与账户对应关系唯一的目的。在一种实施方式中,本步骤可以包括:根据需求类型、以及互联网资源请求的时间,生成需求标识;为需求类型建立账户,并建立需求类型、需求标识、以及账户的对应关系;根据请求,通过为需求类型建立的账户获取互联网资源。具体地,可以设定每一时刻只能发送一个请求,那么用户发送的每个互联网资源请求的时间均相异,所以只要是用户新建一个需求类型,就可以根据需求类型、以及互联网资源请求的时间生成唯一的需求标识,再为新建的需求类型建立账户,就可以建立需求类型、需求标识、以及账户的唯一对应关系,在根据互联网资源请求获取互联网资源时,就可以通过为需求类型建立的账户获取互联网资源。

进一步地,如果用户选择了两份相同的需求计划也可能存在选择两份相同候选计划而需要建立两个账户的情况,在同一时刻只能发送一份需求计划的请求,所以就可以根据需求类型、需求计划以及每份需求计划均相异的互联网资源请求的时间,生成不同的需求标识,再为每个需求标识建立账户,并分别将建立每个账户与每个需求标识的对应关系。比如,用户选择了两份“候选计划1”,由于同一时刻只能发送一份“候选计划1”的请求,所以就有了需求标识a和需求标识b,再去建立两个账户,并将两个账户分别与需求标识a和需求标识b进行关联。

在实际应用中,用户为了简化操作,可以选择为其推荐的候选计划,并且候选计划中还可以是互联网资源的组合。所以,在一种实施方式中,请求中可以包含至少两个互联网资源,则本步骤可以包括:根据请求包含的该至少两个互联网资源以及总资源值,确定各互联网资源的请求值;根据各互联网资源的请求值,通过为该需求类型建立的账户获取各互联网资源。比如,如图7所示,用户选择了“候选计划1”,并且选择了总资源值为z,此时,会根据这两个互联网资源以及总资源值,确定各互联网资源的请求值。具体地,可以在根据候选计划中的预设比例进行确定,比如预先设定“资源1”占20%,“资源4”占80%,那么就可以确定需要请求资源值为z×0.2的“资源1”、请求资源值为z×0.8的“资源4”。又如,可以设定为平均分配等。

步骤13:将获取到的互联网资源关联到需求类型对应的账户中。

在步骤12为需求类型建立账户后,就可以将获取到的互联网资源关联(或保存)到需求类型对应的账户中,比如图8所示,为需求类型界面,展示了用户拥有的需求类型,其中“中期需求”是根据图2和图3操作的结果。

在步骤11中已经介绍,用户可以为需求类型建立不同的需求计划,所以本步骤可以包括:将获取到的互联网资源关联到需求计划对应的账户中。如图9为需求计划界面,展示了用户的“短期需求”下的需求计划,其中“计划2”是根据图4至图7操作的结果。

采用实施例1提供的该方法,为用户提供不同的需求类型,并接收用户通过操作发送的针对选择的需求类型的互联网资源请求,根据该请求通过为需求类型建立的账户去获取互联网资源,并将获取到的互联网资源关联到需求类型对应的账户中。也就是为不同的需求类型建立对应的账户,在用户请求互联网资源时,将请求到的互联网资源直接关联到对应的账户中,做到了不同需求类型下的互联网资源相互隔离,也就实现了根据不同需求分别进行管理和监控。

实施例2

基于相同的发明构思,实施例2提供了一种互联网资源的获取装置,在用户根据不同需求请求互联网资源后,便于对不同需求的互联网资源分别管理和监控。图10为本装置的结构框图,该装置包括:接收单元21、获取单元22以及关联单元23,其中,

接收单元21,可以接收用户发送的互联网资源需求类型,以及针对需求类型的互联网资源请求;

获取单元22,可以根据请求,通过为需求类型建立的子账户获取互联网资源;

关联单元23,可以将获取到的互联网资源关联到需求类型对应的子账户中。

在一种实施方式中,接收单元21,可以接收用户发送的互联网资源需求类型、需求类型下的需求计划,以及针对需求计划的互联网资源请求;

则获取单元22,可以根据请求,通过为需求计划建立的子账户获取互联网资源;

关联单元23,可以将获取到的互联网资源关联到需求计划对应的子账户中。

在一种实施方式中,接收单元21,可以接收用户发送的互联网资源需求类型;

根据需求类型和/或用户根据需求类型预设的偏好信息,展示互联网资源需求计划的推荐信息给用户;

接收用户发送的针对推荐信息的互联网资源请求。

在一种实施方式中,获取单元22,可以根据需求类型、以及互联网资源请求的时间,生成需求标识;

为需求类型建立子账户,并建立需求类型、需求标识、以及子账户的对应关系;

根据请求,通过为需求计划建立的子账户获取互联网资源。

在一种实施方式中,请求中包含至少两个互联网资源,则获取单元22,可以根据请求包含的至少两个互联网资源以及总资源值,确定各互联网资源的请求值;

根据各互联网资源的请求值,通过为需求类型建立的账户获取各互联网资源。

实施例3

发明人在发现互联网资源有这前文介绍的缺陷后,又发现了互联网中的一些缺陷,比如资金作为一种互联网信息资源,越来越多的在互联网中流通,尤其是通过闲置资金获取理财产品实现收益,来满足理财需求,比如住房、教育、医疗、保险等。目前用户通过同一账户根据不同需求获取(购买)理财产品后,无法根据不同需求分别进行管理和监控,比如,用户通过自己的账户先后以教育和医疗为目的,购买了两次同一支基金,但在获取到后一份基金后,便与前一份进行合并,这样就无法管理不同需求的基金数额,并且也无法监控各需求下的收益。此外,即使购买的多支不同基金,在赎回各支基金后,盈亏也会混合在一起,违背了用户出于不同需求购买理财产品时,希望分别管理和监控的意愿。所以基于此缺陷,本发明人提供了一种互联网资源的请求方法,在用户根据不同需求请求互联网资源后,便于对不同需求的互联网资源分别管理。所以基于与实施例1相同的发明思路,作为一种延伸,本实施例提供了一种理财产品的获取方法,在用户根据不同需求获取理财产品后,能够便于对不同需求的理财产品分别管理和监控。该方法的具体流程示意图如图11所示,包括下述步骤:

步骤31:接收用户发送的理财类型,以及针对所述理财类型的理财产品请求。

与步骤11类似,依旧以移动终端为例,可以如图12所示,为用户提供住房、教育、医疗、保险等,也可以进行自定义,用户通过选项选择购买理财产品时的理财类型(住房),并且如图13所示,为用户提供理财产品(基金),用户可以选择针对该理财类型的理财产品并发送请求。

在实际应用中,用户也可能在一个理财类型下有不同的理财计划,也就是更加细化的需求,比如,两套住房分别有各自的理财计划、为两个孩子分别准备不同的教育资金,不同家庭成员对应不同的医疗和保险等,所以在一种实施方式中,本步骤可以包括:接收用户发送的理财类型、该理财类型下的理财计划,以及针对该理财计划的理财产品请求。如图14所示,可以在用户选择了理财类型(教育)后,展示理财计划的展示界面,可供用户选择新建一个理财计划还是在已有理财计划下选择继续获取理财产品,并且如图15所示,弹出用户自定义计划名称的对话框。

在实施例1中介绍了为用户推荐互联网资源,所以本步骤也可以包括:接收用户发送的理财类型;根据该理财类型和/或用户的理财偏好信息,展示理财计划的推荐信息给用户;接收用户发送的针对推荐信息的理财产品请求。比如在用户通过如图14新建理财计划后,直接展示如图16所示的推荐信息。

步骤32:根据该请求,通过为该理财类型建立的账户获取理财产品。

与实施例1类似,本步骤也可以是为理财类型建立单独的账户,该账户可以是用户主账户下的子账户,在实际应用中,也可能出现实施例1中提到的用户选择了两份相同的理财计划,所以本步骤可以包括:根据理财类型、以及理财产品请求的时间,生成理财标识;为理财类型建立账户,并建立理财类型、理财标识、以及账户的对应关系;根据请求,通过为该理财计划建立的账户获取理财产品。

考虑到实际的业务操作过程中,可能会出现两个不同功能的账户,分别是交易账户和资产账户,前者用户进行获取理财产品,而后者用于记账,所以当接收到理财产品的获取请求后,可以根据理财类型、请求的时间,生成理财标识,再为理财类型分别建立交易账户和资产账户,并建立理财类型、理财标识、交易账户、资产账户的对应关系,根据请求,通过为该理财类型建立的交易账户获取理财产品。类似地,如果用户建立了理财计划,那么本步骤可以包括:根据请求,通过为理财计划建立的账户获取理财产品。

在实际应用中,理财计划中可能包含多于一个理财产品,如图17所示,当请求中包含至少两个理财产品时,本步骤可以包括:根据请求包含的至少两个理财产品以及总数额,确定各理财产品的请求数额;根据各理财产品的请求数额,通过为该理财类型建立的获取各理财产品。

步骤33:将获取到的理财产品关联到该理财类型对应的账户中。

在步骤32为需求类型建立交易账户和资产账户后,通过交易账户获取理财产品,本步骤就可以将获取到的理财产品在资产账户中进行记账,比如图18所示,为理财类型界面,展示了用户拥有的理财类型,其中“住房”是根据图12和图13操作的结果。

在步骤31中已经介绍,用户可以为理财类型建立不同的理财计划,所以本步骤可以包括:将获取到的互联网资源关联到需求计划对应的账户中。如图19为理财计划界面,展示了用户的“教育”下的理财计划,其中“小宝”是根据图14至图17操作的结果。

在实际业务中,可以部署三个功能模块,分别为理财类型模块,用户为用户提供理财类型、理财计划、并且接收用户的理财产品请求并发送至开户模块;开户模块,接收到请求后,根据请求的时间生成理财标识,建立交易账户和资产账户,并通过理财标识将理财类型(如果有,还包括理财计划)、交易账户和资产账户建立对应关系;交易模块,根据请求通过交易账户获取理财产品(如需要,确定各理财产品的请求数额),当交易成功后,在资产账户中记账。

采用实施例3提供的该方法,为用户提供不同的理财类型,并接收用户通过操作发送的针对选择的理财类型的理财产品请求,根据该请求通过为理财类型建立的(交易)账户获取理财产品,并将获取到的理财产品记账到理财类型对应的(资产)账户中。也就是为不同的理财类型建立对应的账户,在用户请求理财产品时,将请求到的理财产品直接关联到对应的账户中,做到了不同理财类型下的理财产品相互隔离,也就实现了根据不同类型分别进行管理和监控,比如可以得知各理财需求(计划)中的理财产品信息,以及分别监控收益。

本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。

还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个......”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1