The application is a divisional application of an original application with the application date of 2013, 7 and 23, the application number of 201310311265.9 and the invention name of 'business authorization method, equipment and system'.
Disclosure of Invention
The present application mainly aims to provide a method, a device and a system for service authorization, so as to solve the problem that in the prior art, the identity authentication of a service server to a user and the authorization of information interaction must be realized through real-time online of a client, wherein:
in one aspect of the present application, a method for service authorization is provided. The method comprises the following steps: receiving application information of a service authorization application from a client; sending the application information to a service server, and receiving information to be signed obtained based on the application information from the service server; sending the information to be signed to the client, and receiving the signed information obtained based on the information to be signed from the client; sending the tagging information to the service server, receiving a tagging result of the tagging information from the service server, and determining whether to approve the service authorization application according to the tagging result; and the communication link with the client is a first communication link, and the communication link with the service server is a second communication link.
In addition, in the method, the application information includes a service serial number to be authorized randomly generated by the client, an account number to be authorized uniquely corresponding to the client, and content to be authorized corresponding to the service authorization application, and the information to be signed includes the service serial number to be authorized and a dynamic verification token generated by the service server.
In addition, in the step of transmitting the application information to a service server and receiving information to be signed obtained based on the application information from the service server, a preset service classification code is also transmitted to the service server, and the information to be signed is obtained based on the application information and the service classification code.
In addition, in the method, the information to be signed further includes an authorization level, and the authorization level is determined by the service server based on at least one of the service classification code, the account to be authorized, and the content to be authorized.
Further, in the method, the authorization level includes a high level authorization and a normal authorization.
Further, in the method, the first communication link is a near field communication link and the second communication link is an internet communication link.
In addition, in the method, the first communication link includes sound wave, bluetooth, Wifi, NFC.
In another aspect of the present application, a method for applying for service authorization is provided. The method comprises the following steps: sending application information of a service authorization application to a service authorization device; receiving information to be signed obtained based on the application information and the service classification codes; signing the information to be signed by using a private key; and sending the signing information containing the signing result to the service authorization equipment, wherein a communication link between the service authorization equipment and the signing information is a first communication link.
In addition, in the step of receiving the information to be signed obtained based on the application information, the information to be signed is also obtained based on a preset service classification code.
Further, in the method, the first communication link is a near field communication link.
In addition, in the method, the first communication link includes sound wave, bluetooth, Wifi, NFC.
In another aspect of the present application, a service authorization apparatus is provided. The apparatus comprises: a first communication module configured to receive application information of a service authorization application from a client; the second communication module is configured to send the application information to a service server and receive information to be signed obtained based on the application information from the service server; the first communication module is further used for sending the information to be signed to the client and receiving the signed information obtained based on the information to be signed from the client; the second communication module is further configured to send the tagging information to the service server; and receiving a signature checking result of the signature adding information from a service server, and determining whether to approve the service authorization application according to the signature checking result, wherein a communication link between the service authorization equipment and the client is a first communication link, and a communication link between the service authorization equipment and the service server is a second communication link.
In addition, in the device, the application information includes a service serial number to be authorized randomly generated by the client, an account to be authorized uniquely corresponding to the client, and a content to be authorized corresponding to the service authorization application, and the information to be signed includes the service serial number to be authorized and a dynamic verification token generated by the service server.
In addition, the second communication module is further configured to send the application information and a preset service classification code to a service server, and receive information to be signed from the service server based on the application information and the service classification code.
In addition, in the device, the information to be signed further includes an authorization level, and the authorization level is determined by the service server based on at least one of the service classification code, the account to be authorized, and the content to be authorized.
Additionally, in the device, the authorization level includes a high level authorization and a normal authorization.
Further, in the device, the first communication link is a near field communication link and the second communication link is an internet communication link.
In addition, in the device, the first communication link includes sound wave, bluetooth, Wifi, NFC.
In another aspect of the present application, a service authorization system is provided. The system comprises a client, the service authorization equipment and a service server.
Additionally, in the system, the client is configured to: sending application information of a service authorization application to a service authorization device; receiving information to be signed obtained based on the application information; signing the information to be signed by using a private key; and sending the signing information containing the signing result to the service authorization equipment, wherein a communication link between the client and the service authorization equipment is a first communication link.
Additionally, in the system, the client is further configured to: sending application information of a service authorization application to a service authorization device; receiving information to be signed obtained based on the application information and the service classification codes; signing the information to be signed by using a private key; and sending the signing information containing the signing result to the service authorization equipment, wherein a communication link between the client and the service authorization equipment is a first communication link.
Compared with the prior art, according to the technical scheme, the requirement that the client must be online in real time in the identity confirmation and authorization process is avoided by using the asymmetric encryption technology, so that the client can realize offline service authorization in the identity confirmation and authorization process. Namely, an authorized core device is arranged between the client and the service server, so that the client performs information interaction with the authorized core device through the near field communication link, and the authorized core device performs information interaction with the service server through the internet communication link. Therefore, the client does not need to be online in real time and is not influenced by network signals, the communication mode of the client is more flexible and changeable, and the method can be applied to various different service scenes. In addition, through the technical scheme, the offline identity confirmation and authorization functions originally realized on the client can be realized by setting an independent authorization core body module, namely: the authorization core module replaces a client to become a real-time online internet node. Therefore, the authorization core module can be widely applied to various off-line security scenes needing authorization, so that the client achieves the purpose of high security.
Detailed Description
The main idea of the present application is that, in order to solve the problem that the client and the service server must perform information interaction online in real time in the prior art, the present application adopts a real-time online authorization core device, so that the authorization core device becomes a module for information forwarding between the client and the service server, that is, an internet node instead of the client, so as to solve the problem that the client must be online in real time in the service authorization process based on an asymmetric encryption mechanism. In other words, by setting the authorized core device, the client performs offline information interaction with the authorized core device through the near field communication link, and the authorized core device performs real-time online information interaction with the service server through the internet communication link, so that the client is not affected by network signals, the success rate of service authorization is improved, and user experience is improved.
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be described in further detail with reference to the accompanying drawings and specific embodiments.
< method of authorizing service >
In one aspect of the present application, a method for service authorization is provided.
Fig. 1 is a timing diagram of a service authorization method according to an embodiment of the present application, and fig. 2A is a schematic flow chart of a service authorization method according to a general authorization level according to an embodiment of the present application. The service authorization method according to the present application is described in detail below with reference to fig. 1 and 2A.
As shown in fig. 1, in the present application, service authorization is mainly implemented by a client to be authorized, an authorization core device, and a service server. The client to be authorized (hereinafter, simply referred to as a client) is client software downloaded to the mobile device, and of course, the client is not limited thereto and may be hardware such as the mobile device in some scenarios. The authorization core body device is an information forwarding module for identity confirmation and service authorization, and can be a server or a terminal device and the like. The service server is a device for identity confirmation of a user using the client and authorization of information interaction.
In addition, offline information interaction is carried out between the client and the authorized core device through a first communication link, and online information interaction is carried out between the authorized core device and the service server through a second communication link. Here, the first communication link may be a plurality of near field communication links such as a sound wave, bluetooth, Wifi, and NFC, and if the cost is considered, information interaction may be performed through the sound wave in an actual service. The second communication link is an internet communication link.
(opening of off-line authorization service)
Before the client end starts to apply for the offline authorization service, the activation of the offline authorization service function needs to be completed through an internet communication link. That is, the client needs to be online in real time to implement the activation of the offline authorization service.
In the process of opening the authorization service, the user sends an application for opening the off-line authorization service to the service server by using the user account which can only confirm the identity of the user. The user account refers to an account generated by registering when the user opens the offline authorization service. Then, the service server creates a set of specific asymmetric keys for the user of the client, wherein the set of specific asymmetric keys comprises a private key and a public key. And the private key is issued to the client and stored in the client, and the public key is stored in the database of the service server. The public Key takes the user account as Key and also corresponds to the account to be authorized, which will be described later.
In addition, in the process of opening the service, sometimes a user may preset an offline authorization password for an account according to the requirement for security, and the offline authorization password is stored in the database of the service server. Particularly, in the case that the user needs or requires a specific strong security scenario, the user can utilize the offline authorization password to enhance the security of the service authorization process, so that the offline authorization password can participate in the service authorization process as an independent security factor. Of course, in different service scenarios, the offline authorization password may be set at any time according to service requirements or user requirements during the process of performing the offline authorization service, instead of setting the offline authorization password during the process of activating the service.
Under the condition of opening the offline service authorization, the offline authorization service can be applied to the service server at any time.
[ embodiment 1 ]
(Process of applying for offline authorization service)
As shown in fig. 2A, in step S201, application information of a service authorization application from a client is received through a first communication link. In other words, an application for offline authorization service is sent from the client, and application information related to the application is sent to the authorized core device through a near field communication link such as a sound wave.
Specifically, step S201 includes the part of issuing the offline authorization application as shown in fig. 1.
[ issue of offline authorization application ]
In the security scenes of identity confirmation, authorization and the like, when a client generates an offline authorization application, a unique service serial number to be authorized is generated, and the application to be authorized is sent to the real-time online authorization core device through a near-field communication link such as sound waves and the like to wait for authorization. The application information of the to-be-authorized application can include a service serial number to be authorized, an account number to be authorized and content to be authorized. Specifically, the service serial number to be authorized refers to a globally unique serial number generated by the service server at the time of applying for service authorization. The account to be authorized refers to the unique user account, namely the user account, registered when the client sends a service opening application to the service server through the internet communication link when the offline authorization service is opened, and used for confirming the identity of the client. The content to be authorized refers to content information corresponding to the offline authorization service applied by the user.
As shown in fig. 2A, in step S202, the application information is sent to the service server through the second communication link, and the information to be signed based on the application information is received from the service server through the second communication link. The information to be signed may include a service serial number to be authorized and a dynamic check token randomly generated by the service server. In other words, the authorized core device sends the application information to the service server through the internet communication link. Then, after the service server receives the application information, the service server sends information for user signature to the authorized core device through the internet communication link, namely, the service serial number to be authorized and the dynamic verification token generated by the service server.
Specifically, step S202 includes two parts, namely forwarding the offline authorization application and issuing the authorization dynamic check token as shown in fig. 1.
[ Forwarding of offline authorization application ]
After the authorization core device receives the application to be authorized, the application to be authorized containing the service serial number to be authorized, the account number to be authorized and the content to be authorized is forwarded to the service server through the internet communication link. [ issuing authorization dynamic verification token ]
After the service server receives the application for authorization, the service server generates a random character string with a fixed length for the service serial number to be authorized as a dynamic verification token for the authorization, and records the service serial number to be authorized, the dynamic verification token, the account number to be authorized and the content to be authorized in a database. And then, the service server transmits the service serial number to be authorized and the dynamic verification token back to the authorization core body device through the internet communication link.
As shown in fig. 2A, in step S203, the information to be signed is sent to the client through the first communication link, and the signed information obtained based on the information to be signed is received from the client through the first communication link. In other words, the authorization core device forwards the service serial number to be authorized and the dynamic verification token generated by the service server to the client through a near-field communication link such as a sound wave. And then, after receiving the service serial number to be authorized and the dynamic verification token, the client signs the information to be signed, namely the service serial number to be authorized and the dynamic verification token, and sends the signed information to the authorized nuclear equipment through a near-field communication link such as a sound wave. The signature information may include a service serial number to be authorized, an account number to be authorized, and a signature result.
Specifically, step S203 includes forwarding the authorization dynamic verification token and uploading the token tagged two parts as shown in fig. 1.
[ dynamic verification token for Forwarding authorization ]
After the authorization core body device receives the service serial number to be authorized and the dynamic verification token which are transmitted back by the service server, the authorization core body device transmits the service serial number to be authorized and the dynamic verification token to the client through a near field communication link such as sound waves.
[ uploading of token after signing ]
The client receives the service serial number to be authorized and the dynamic verification token forwarded by the authorization core device. And then, signing the service serial number to be authorized and the dynamic verification token by using the saved private key at the client. After the signature is successful, the client uploads the service serial number to be authorized, the account number to be authorized and the signature result to the authorization core device through a near field communication link such as a sound wave.
As shown in fig. 2A, in step S204, the signing information is sent to the service server through the second communication link, and the signing verification result of the signing information is received from the service server through the second communication link, and it is determined whether to approve the service authorization application according to the signing verification result. In other words, the authorized core device forwards the tagging information to the service server through the internet communication link. And then, after the service server receives the signing information, checking the signing information, and sending a signing checking result to the authorized core device through the Internet communication link. And then, the authorization core-body device determines whether to approve the service authorization application according to the signature checking result from the service server.
Specifically, step S204 includes forwarding the tagging information as shown in fig. 1 and deciding whether to pass the two parts according to the result of the tag verification.
[ Forwarding of signing information ]
After the authorization core device receives the signing information which is transmitted from the client and contains the serial number of the service to be authorized, the account number to be authorized and the signature result, the signing information is forwarded to the service server through the internet communication link.
[ deciding whether to permit based on the result of the checklist ]
And after the service server receives the service serial number to be authorized, the account number to be authorized and the signature result, verifying and signing the service serial number to be authorized and the dynamic verification token by using the public key corresponding to the account number to be authorized recorded in the database of the service server. And after the successful verification of the signature, the service server informs the authorization core device of the signature verification result through an internet communication link, and the authorization core device determines whether to pass the offline authorization service according to the signature verification result.
[ embodiment 2 ] A method for producing a semiconductor device
In embodiment 1, a process of authorizing a service at a general authorization level with low security requirements is described. When the requirement on the security is high, the offline service authorization with higher authorization level can be realized by setting the offline authorization password.
Next, a case of using an offline authorization password will be described with reference to fig. 1, 2A, and 2B. In this embodiment, differences from embodiment 1 will be described in detail, and the same points as embodiment 1 will be omitted. The same reference numerals as in embodiment 1 are used for the same points as in embodiment 1 in embodiment 2.
Fig. 2B is a schematic flowchart of a service authorization method with a high authorization level according to an embodiment of the present application. Specifically, in embodiment 2, step S212 in fig. 2B is used instead of step S202 in fig. 2A.
As shown in fig. 2B, in step S212, the application information and the preset service classification code are sent to the service server through the second communication link, and the information to be signed based on the application information and the service classification code is received from the service server through the second communication link. Here, the traffic classification code refers to a code that is set in advance to distinguish a security class or the like of an authorized traffic. In this embodiment, the information to be signed may include a service serial number to be authorized, a dynamic verification token generated by the service server, and an authorization level set based on the application information and the service classification code. In other words, the authorized core device sends the application information and the service classification code to the service server through the internet communication link. And then, the service server sends the information to be signed for the user signature to the authorization core device through the internet communication link, namely the service serial number to be authorized, the dynamic verification token generated by the service server and the authorization level.
Specifically, step S212 includes two parts, namely, issuing the authorization dynamic verification token and forwarding the authorization dynamic verification token as shown in fig. 1.
[ Forwarding of offline authorization application ]
After the authorization core device receives the application to be authorized, the application to be authorized containing the service serial number to be authorized, the account number to be authorized and the content to be authorized is forwarded to the service server through the internet communication link. And simultaneously, uploading a service classification code which is preset in the authorization core device and used for distinguishing the authorization service type and the application to be authorized to a service server.
[ issuing authorization dynamic verification token ]
And after receiving the application to be authorized, the service server identifies the service classification code, the account to be authorized and the content to be authorized which needs to be authorized, and sets an authorization level according to the service classification code, the account to be authorized and the content to be authorized. That is, the authorization level is set as a high-level authorization according to at least one of the service classification code, the account to be authorized and the content to be authorized needing authorization; otherwise, the authorization level is set to normal authorization. That is, the authorization level is determined by the service server based on the service classification code, the account number to be authorized, and the content to be authorized, and the authorization level may include advanced authorization and general authorization. For example, when the service represented by the service classification code needs high security guarantee, the account number to be authorized has high risk, or sensitive content exists in the content to be authorized and needs special protection, the authorization level is set as high-level authorization. Of course, the authorization level is not limited to this, and other level manners may be set, for example, high-level authorization, medium-level authorization, low-level authorization, and the like may be included. In addition, the authorization level is not limited to be determined based on the traffic classification code, the account number to be authorized, and the content to be authorized. For example, the authorization level can be determined according to the account number to be authorized and the content to be authorized without using the service classification code.
Then, the service server generates a random character string with a fixed length for the service serial number to be authorized as a dynamic verification token for the authorization, and records the service serial number to be authorized, the dynamic verification token, the service classification code, the account number to be authorized, the content to be authorized and the authorization level in a database. And then, the service server transmits the service serial number to be authorized, the dynamic verification token and the authorization grade back to the authorization core device through the Internet communication link.
As shown in fig. 2A, in step S203, the information to be signed is sent to the client through the first communication link, and the signed information obtained based on the information to be signed is received from the client through the first communication link. In other words, the authorization core device forwards the service serial number to be authorized, the dynamic verification token and the authorization level to the client through a near-field communication link such as a sound wave. And then, after receiving the service serial number to be authorized and the dynamic verification token, the client signs the information to be signed, namely the service serial number to be authorized, the dynamic verification token and the offline authorization password, and sends the signing information to the authorization core device through near field communication links such as sound waves. The signature information may include a service serial number to be authorized, an account number to be authorized, and a signature result.
Specifically, step S203 may include forwarding the authorization dynamic verification token and uploading the token tagged two parts as shown in fig. 1.
[ dynamic verification token for Forwarding authorization ]
After the authorization core device receives the service serial number to be authorized, the dynamic verification token and the authorization grade which are returned by the service server, the authorization core device forwards the service serial number to be authorized, the dynamic verification token and the authorization grade to the client through a near-field communication link such as sound waves.
[ uploading after signing token ]
The client receives the service serial number to be authorized, the dynamic verification token and the authorization level forwarded by the authorization core device.
Then, if the received authorization level is common authorization, signing the service serial number to be authorized and the dynamic verification token by using the stored private key at the client; otherwise, if the received authorization level is high-level authorization, the user sets an offline authorization password at the client. And then, signing the service serial number to be authorized, the dynamic verification token and the offline authorization password by using the saved private key at the client. When the authorization level is high-level authorization, the private key is used for signing the service serial number to be authorized, the dynamic verification token and the off-line authorization password; and when the authorization level is the common authorization, using a private key to sign the service serial number to be authorized and the dynamic verification token.
After the signature is successful, the client uploads the service serial number to be authorized, the account number to be authorized and the signature result to the authorization core device through a near field communication link such as a sound wave. And under the condition that the authorization level is high-level authorization, the client side uploads an offline authorization password set by the user at the client side to the authorization core device.
As shown in fig. 2A, in step S204, the signing information is sent to the service server through the second communication link, and the signing verification result of the signing information is received from the service server through the second communication link, and it is determined whether to approve the service authorization application according to the signing verification result. In other words, the authorized core device forwards the tagging information to the service server through the internet communication link. And then, after the service server receives the signing information, checking the signing information, and sending a signing checking result to the authorized core device through the Internet communication link. And then, the authorized core device determines whether to approve the service authorization application according to the signature verification result from the service server.
Specifically, step S204 includes forwarding the tagging information as shown in fig. 1 and deciding whether to pass the two parts according to the result of the tag verification.
[ Forwarding of signing information ]
After the authorization core device receives the signing information which is transmitted from the client and contains the serial number of the service to be authorized, the account number to be authorized and the signature result, the signing information is forwarded to the service server through the internet communication link. And under the condition that the authorization level is high-level authorization, the authorization core device forwards the offline authorization password to the service server together.
[ decision of Release based on the result of the checkbook ]
After the service server receives the service serial number to be authorized, the account number to be authorized and the signature result, the service server checks the signature by using the public key corresponding to the account number to be authorized, which is recorded in the database of the service server. In the case where the service server receives the offline authorization password, the service server stores the offline authorization password in the database. Then, when the authorization level is advanced authorization, using a public key to check and sign the serial number of the service to be authorized, the dynamic verification token and the offline authorization password stored in the database of the service server; and when the authorization level is the common authorization, the public key is used for verifying and signing the service serial number to be authorized and the dynamic verification token.
And after the successful verification of the signature, the service server informs the authorization core device of the signature verification result through an internet communication link, and the authorization core device determines whether to pass the offline authorization service according to the signature verification result.
As described above, in embodiment 2, an example is shown in which the authorization level is set based on the traffic classification code preset in the authorization core device, but the present invention is not limited to this. Of course, the traffic classification code may not be set. In this case, the authorization level may be set according to the account to be authorized, the content to be authorized that needs to be authorized, and the like.
In embodiment 2, the case where the user sets the offline authorization password during the offline authorization service is described, but the present invention is not limited to this. Of course, the user may also set the offline authorization password in the process of opening the offline authorization service. In this case, the authorization level may be set according to the setting of the user, but is not limited thereto.
In embodiment 2, only an example of setting the authorization level using the traffic class code and thereby introducing the offline authorization password is described. As to how to set the authorization level, it may be set to a high security level by the user forcibly; the user can define scenes with high security level; and can also be set by authorizing the core device. The offline authorization password can be flexibly set at any time according to the requirements of different service scenes. In this application, only for illustration, the security of the offline authorization service can be improved according to different levels of authorization manners.
< service authorization apparatus >
In another aspect of the present application, a service authorization device is provided.
Fig. 3 is a schematic structural diagram of a service authorization device according to an embodiment of the present application. As shown in fig. 3, the service authorization apparatus 300 may include a first communication module 301 and a second communication module 302. In practice, the service authorization apparatus 300 is an authorization core apparatus shown in fig. 1.
The first communication module is configured to receive application information of a service authorization application from the client. The application information comprises a service serial number to be authorized randomly generated by the client, an account number to be authorized uniquely corresponding to the client and content to be authorized corresponding to the service authorization application.
And the second communication module is configured to send the application information and a preset service classification code to a service server and receive information to be signed obtained based on the application information and the service classification code from the service server. The information to be signed comprises the service serial number to be authorized and a dynamic verification token generated by the service server. In addition, the information to be signed also comprises an authorization level, and the authorization level is determined by the service server based on the service classification code, the account number to be authorized and the content to be authorized. Wherein the authorization level includes advanced authorization and normal authorization.
And the first communication module is further used for sending the information to be signed to the client and receiving the signed information obtained based on the information to be signed from the client.
The second communication module is further configured to send the tagging information to the service server; and receiving the signature checking result of the signature adding information from the business server, and determining whether to approve the business authorization application according to the signature checking result.
The communication link between the service authorization equipment and the client is a first communication link, and the communication link between the service authorization equipment and the service server is a second communication link. In particular, the first communication link is a near field communication link and the second communication link is an internet communication link. The first communication link comprises sound waves, Bluetooth, Wifi and NFC.
In other words, in the service authorization apparatus 300, the first communication module 301 performs information interaction with the client, and the second communication module 302 performs information interaction with the service server.
< service authorization System >
In another aspect of the present application, a service authorization system is provided.
Fig. 4 is a schematic structural diagram of a service authorization system according to an embodiment of the present application. As shown in fig. 4, the service authorization system 400 may include a client 401, a service authorization apparatus 300, and a service server 403.
Further, the service authorization apparatus 300 may include a first communication module 301 and a second communication module 302 shown in fig. 3.
Client 401 is configured to: sending application information of a service authorization application to a service authorization device; receiving information to be signed obtained based on the application information and the service classification codes; signing the information to be signed by using a private key; and sending the signing information containing the signing result to the service authorization equipment.
And the communication link between the client and the service authorization equipment is a first communication link. The first communication link comprises sound waves, Bluetooth, Wifi and NFC.
The specific implementation of the various modules included in the service authorization apparatus 300 of the present application substantially corresponds to the specific implementation of the steps in the method of the present application, and the specific details of the various modules are not described here in order not to obscure the present application.
The method, the device and the system can be applied to any device capable of performing offline authorization service operation. The method adopts a real-time online authorization core device to form a real-time online Internet node to replace the identity confirmation and authorization functions of the conventional client. The authorization core body module can be widely applied to various off-line security scenes needing authorization, so that the client achieves the aim of high security. In addition, the mobile device provided with the client can become a universal offline authorization security device based on the account number registered by the user in the service server. In cooperation with the account opening and safe opening service strategies, the user can use the mobile client to complete user identity confirmation and authorization in various scenes, so that the account and the safety capacity of the service server can enter more offline service scenes.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory. The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Those of skill would further appreciate that the various illustrative modules and method steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative components and steps have been described above generally in terms of their functionality in order to clearly illustrate this interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
The above-mentioned embodiments, objects, technical solutions and advantages of the present application are described in further detail, it should be understood that the above-mentioned embodiments are merely exemplary embodiments of the present application, and are not intended to limit the scope of the present application, and any modifications, equivalent substitutions, improvements and the like made within the spirit and principle of the present application should be included in the scope of the present application.
It should be noted that although in the above detailed description several modules or sub-modules of the device are mentioned, this division is only not mandatory. Indeed, the features and functionality of two or more of the modules described above may be embodied in one module according to embodiments of the application. Conversely, the features and functions of one module described above may be further divided into embodiments by a plurality of modules.
Further, while the operations of the methods of the present application are depicted in the drawings in a particular order, this does not require or imply that these operations must be performed in this particular order, or that all of the illustrated operations must be performed, to achieve desirable results. Rather, the steps depicted in the flowcharts may change the order of execution. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions.