Polymorphic service method, device and medium for aggregating pos extended application capabilities

Abstract

The application discloses a polymorphic service method, device and medium for aggregating POS extended application capabilities, and comprises the following steps: creating a user account; creating a plurality of applications under the user account, accessing a plurality of API interfaces under each application, and configuring a required service capability type for each API interface; entering device information corresponding to a device having the service capability type under each service capability type; configuring a corresponding key pair for each application; initiating a calling request by a POS device to a target API interface; after receiving the calling request, performing verification on the calling request according to corresponding request parameters and a key pair corresponding to an application to which the target API interface belongs, returning device information of a corresponding service capability type after successful verification, and executing a corresponding service using a corresponding device according to the device information; and recording calling data of each calling request for statistical analysis. The application can centrally manage API interfaces of various capabilities.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of POS, and in particular to a polymorphic service method for aggregating and extending application capabilities of POS, a device and a medium. BACKGROUND

[0002] POS machines are widely used in bank or merchant checkout scenarios, and can be used for functions such as card swiping, payment and printing of receipts. Therefore, the POS machine needs to have its positioning capabilities, that is, the device can realize more accurate geographic location tracking through positioning technology, which is crucial for the POS machine. In the scenario of checking out goods, the POS will also use the ability to obtain product information through the product barcode. The function of printing receipts will call the ability to push messages. From this, it can be seen that the POS will call various interface capabilities in the checkout scenario. These POS called interfaces are generally independent in various places, and cannot be obtained together in the same place. Code development needs to understand the usage and rules of each interface, and generally these usage and rules are not the same, which requires more time and development cost.

[0003] The existing method has three deficiencies:

[0004] 1. The API interfaces that need to be called in the existing POS machine are scattered in various places, and the use process is prone to non-standard use. Common capabilities are scattered, localized, have high maintenance costs and weak universality, and cannot be managed uniformly.

[0005] 2. The use and call times of API interfaces corresponding to various capabilities cannot be statistically analyzed, and the value cannot be further tapped to provide better assistance.

[0006] 3. The call of open source API interfaces cannot be verified according to custom rules and requirements, and the authority cannot be monitored and controlled from the dimensions of users and capabilities, and the operation of disabling and deleting a certain user, a certain capability or a certain device cannot be recovered. SUMMARY

[0007] Therefore, the purpose of the present application is to provide a polymorphic service method for aggregating and extending application capabilities of POS.

[0008] In order to achieve the above technical purpose, the technical scheme adopted by the present application is:

[0009] The present application provides a polymorphic service method for aggregating and extending application capabilities of POS, comprising the following steps:

[0010] Step 1, the administrator creates a user account for each user;

[0011] Step 2, after logging in the user account, create multiple applications under the corresponding user account, access multiple API interfaces under each application, and configure a required service capability type for each API interface;

[0012] Step 3, enter the device information corresponding to the device with the service capability type under each service capability type;

[0013] Step 4, configure a corresponding key pair for each application;

[0014] Step 5, the POS device initiates a call request to the target API interface according to the service capability type to be called;

[0015] Step 6, after the target API interface receives the call request, it performs verification according to the request parameters corresponding to the call request and the key pair corresponding to the application to which the target API interface belongs, and returns the device information of the corresponding service capability type after successful verification, and executes the corresponding service using the corresponding device according to the device information;

[0016] Step 7, record the call data of each call request for statistical analysis.

[0017] Further, the step 2 specifically comprises:

[0018] Step 21, after logging in the user account, create multiple applications according to the customer dimension under the corresponding user account; the customer dimension refers to the name of the bank business outlet;

[0019] Step 22, access multiple API interfaces under each application, and configure a required service capability type for each API interface according to the capability type; the service capability type includes product barcode capability, geographic location capability, email capability, and printing capability; the service capability types configured by the multiple API interfaces accessed under the same application are different;

[0020] Step 23, generate the URL address of each API interface.

[0021] Further, the device information includes the device SN number, and the key pair includes appKeyid and appKeySecert.

[0022] Further, the step 5 specifically comprises:

[0023] Step 51, find the API interface corresponding to the service capability type according to the service capability type to be called;

[0024] Step 52, select one or more of all the conforming API interfaces as the target API interface;

[0025] Step 53, the POS device acquires the URL address corresponding to the target API interface;

[0026] Step 54, the POS device initiates a calling request to the target API interface through the URL address corresponding to the target API interface.

[0027] Further, the step 6 specifically includes:

[0028] Step 61, after receiving the calling request, the target API interface acquires the request parameters corresponding to the calling request, the request parameters including the appKeyid of the application, the timestamp when the device initiates the request, the device SN number and the signature; the calculation method of the signature is to sequentially splice the appKeyid, the appKeySecert, the timestamp when the device initiates the request and the device SN number, and then encrypt them by using the HMacSHA256 encryption algorithm to obtain the signature;

[0029] Step 62, acquire the appKeySecert in the key pair corresponding to the application to which the target API interface belongs;

[0030] Step 63, verify according to the appKeyid of the application, the timestamp when the device initiates the request, the device SN number, the signature and the appKeySecert;

[0031] Step 64, after the verification succeeds, return the device information of the corresponding service capability type;

[0032] Step 65, use the corresponding device according to the device information to execute the corresponding service, and obtain the service information.

[0033] Further, the step 63 specifically includes:

[0034] Step 631, splice the appKeyid in the calling request, the appKeySecert in the key pair of the application to which the target API interface belongs, the timestamp when the device initiates the request in the calling request and the device SN number in the calling request in sequence, and then encrypt them by using the HMacSHA256 encryption algorithm to obtain a new signature;

[0035] Step 632, compare the signature in the calling request with the new signature, if they are consistent, go to step 633; if they are not consistent, it means that the message is tampered, and the process is ended;

[0036] Step 633, according to the application of appKeyid and device SN number in the calling request, check whether the device SN number is recorded under the application, if not, end the flow; if yes, continue to judge whether the device SN number is in a usable state, if yes, enter step 634; otherwise, end the flow;

[0037] Step 634, calculate the time difference between the time stamp when the device initiates the request and the time stamp when the target API interface receives the request, judge whether the time difference is greater than the time threshold, if yes, it means that the request is expired, end the flow; otherwise, the verification is successful, enter step 64.

[0038] Further, the request parameter further includes an IP address, and the signature is calculated by sequentially splicing the appKeyid, the appKeySecert, the current time stamp, the device SN number and the IP address.

[0039] Further, the step 7 specifically comprises:

[0040] Step 71, record the API interface, request parameter and response parameter called in the calling request process of all users, and save them into a database;

[0041] Step 72, statistically analyze the usage and calling times of the API interface according to the recorded data.

[0042] The application further provides an electronic device, which comprises a memory, a processor and a computer program stored in the memory and executable on the processor, and the processor implements the above-mentioned multi-state service method for aggregating POS extended application capabilities when executing the program.

[0043] The application further provides a computer readable storage medium, which stores a computer program, and the program is executable on the processor to implement the above-mentioned multi-state service method for aggregating POS extended application capabilities.

[0044] Compared with the prior art, the application has the beneficial effects that:

[0045] 1. The API interfaces corresponding to various capabilities in the POS machine are aggregated in one place, a service system integrating multiple common capabilities is provided, centralized management is performed, the same parameter passing specification and unified rule requirements are provided for various capabilities, more standardized, convenient and safe capability access services are provided, the phenomenon of scattered capabilities and non-standard use is eliminated, and one service system manages all series of capabilities. The use of various capabilities is greatly reduced in terms of manual cost, the use efficiency of the capabilities is improved, and the development speed and time cost of the developers can be accelerated.

[0046] 2, the use of API interface (service capability type) and the number of calls and other information statistical analysis, with user dimension and device dimension ability call times statistical report, with more intuitive report form to show more in-depth mining its value, provides a better assistance. Call times, call result state and return result information will be displayed on the system page, so as to give the user a better user experience. And the ability of the right to constraint, the administrator can control management, can be withdrawn operation.

[0047] 3, the API interface in access increases its own check rules, to ensure the correctness and safety of data, avoid the phenomenon of random calling interface and abuse; The administrator role can view all the user-owned capabilities, and has the ability to disable and delete the recovery operation of all user accounts, user capabilities, and user devices under the user, can be from the user dimension and capability dimension to supervise and control the role of authority, can achieve flexible disable and delete the recovery operation of a user, a capability or a device, so as to achieve the right to constraint. From the source to supervise and control the role of authority, avoid the phenomenon of API interface calling abuse and non-standard, has its own set of standard calling system. Simplify, higher security, more clear function flow. BRIEF DESCRIPTION OF DRAWINGS

[0048] In order to more clearly illustrate the technical solutions of the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiment or prior art description. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0049] Figure 1 It is the structure diagram of the management end, API end and device end provided by the embodiment of the present application.

[0050] Figure 2 It is the execution flow chart of the polymorphic service method for aggregating POS extended application capabilities provided by the embodiment of the present application.

[0051] Figure 3 It is the configuration diagram of user account, application, API interface, service capability type and device information provided by the embodiment of the present application.

[0052] Figure 4 It is the schematic diagram of an electronic device provided by the embodiment of the present application.

[0053] Figure 5 It is the schematic diagram of a computer readable storage medium provided by the embodiment of the present application. DETAILED DESCRIPTION

[0054] The application will be described in further detail below with reference to the drawings and embodiments. It is particularly pointed out that the following embodiments are only used to illustrate the application, but do not limit the scope of the application. Similarly, the following embodiments are only part of the embodiments of the application, not all embodiments, and all other embodiments obtained by those of ordinary skill in the art without creative labor are within the scope of the application.

[0055] Please refer to Figure 1 The application consists of three parts: the management end, the API end and the device end.

[0056] The management end (administrator): responsible for account management, capability management and device management, has the operation of disabling and deleting the recycling of the account, capability and device, and plays a role in supervising and controlling all user capabilities.

[0057] The API end (API interface): responsible for calling the interface for the device end, has its own set of parameter passing specifications and systems, and realizes unified signature verification and verification rules.

[0058] The device end (POS device): responsible for obtaining the corresponding device information of the corresponding required service capability type according to the called API interface.

[0059] The operation mode between the management end, the API end and the device end is as follows:

[0060] As shown in Figure 2 and Figure 3 , a polymorphic service method for aggregating POS extended application capabilities of the application includes the following steps:

[0061] Step 1, the administrator creates a user account for each user; different user accounts are used to distinguish different users, which is convenient for managing users, and the corresponding service capability type and device information are configured under each user account, so that unified management of users, various capabilities and devices can be realized.

[0062] In this embodiment, the creation of a user account can be registered by setting an account name and a password, and the creation process can be completed after registration. The account name can select a mobile phone number, an ID card number or other custom number or name, which is not limited here.

[0063] Step 2, after logging into the user account, create multiple applications under the corresponding user account, access multiple API interfaces under each application, and configure a required service capability type for each API interface;

[0064] In this embodiment, step 2 specifically includes:

[0065]

[0065] Step 21, after logging in the user account, create multiple applications under the corresponding user account according to the customer dimension; the customer dimension refers to the name of the bank business site; different bank business sites are distinguished, for example: the application of a branch of a city branch of a bank, which is convenient for management; here, the customer dimension can also classify the application type according to the actual needs of the user, which is not limited to the bank business site.

[0066] Step 22, access multiple API interfaces under each application, and configure a required service capability type according to the capability type for each API interface; the service capability type includes commodity barcode capability, geographic location capability, email capability, and printing capability; the service capability types configured by multiple API interfaces accessed under the same application are different;

[0067] Step 23, generate the URL address of each API interface, such as: http: / / IP:PORT / {context-path} / api / location / v2 / getGpsAndAddrFromIp. Among them, the front of api indicates the request path prefix, just like http: / / www.baidu.com:8080 / aaa. Api is a fixed mark of the management platform. After api, it represents the capability type, location refers to the service capability type as geographic location capability, which can also be code (commodity barcode capability) or email (email capability), and the back is reserved for subsequent multiple addresses of a capability interface.

[0068] Step 3, enter the device information corresponding to the device with the service capability type under each service capability type; the device information includes the device SN number, so that the permission to disable and delete the device can be obtained; set the application under the user account, set the API interface under the application, set the service capability type under the API interface, and set the device information under the service capability type; the configuration process is progressive, which can enable the administrator to have the permission to view all user applications, API interfaces, service capability types, and device information, and the permission to disable and delete the operation. After the configuration is completed, the POS device can call all API interfaces under all user accounts created in the management end.

[0069] This configuration aims to consolidate the API interfaces corresponding to various capabilities within the POS terminal, providing a unified service system that integrates multiple commonly used capabilities for centralized management. This system uses the same parameter transmission specifications and unified rules for each capability, providing more standardized, convenient, and secure capability access services. This eliminates the phenomenon of fragmented and irregular capability usage, allowing a single service system to manage the entire range of capabilities. This significantly reduces the labor cost of integrating various capabilities, improves capability utilization efficiency, and speeds up development and reduces developer time.

[0070] The administrator role can view the capabilities of all users and has the ability to disable, delete, and reclaim all user accounts, user capabilities, and devices. This allows for oversight and control of permissions from both the user and capability perspectives, flexibly disabling and deleting specific users, capabilities, or devices. This effectively constrains capabilities and permissions. This oversight and control of permissions from the source prevents abuse and irregularities in API calls, and provides a standardized calling system. This simplifies complexity, improves security, and clarifies functional processes.

[0071] Step 4: Configure a corresponding key pair for each application. The key pair includes appKeyid and appKeySecert. The key pair is used to call the API interface and pass parameters.

[0072] Step 5: The POS device initiates a call request to the target API interface based on the service capability type that needs to be called;

[0073] In this embodiment, step 5 specifically includes:

[0074] Step 51: Search for an API interface corresponding to the service capability type that needs to be called;

[0075] Step 52: Select one or more of all the matching API interfaces as target API interfaces.

[0076] Step 53: The POS device obtains the URL address corresponding to the target API interface;

[0077] Step 54: The POS device initiates a call request to the target API interface through the URL address corresponding to the target API interface. The transmission method for sending the call request is POST.

[0078] Step 6, after the target API interface receives the calling request, the target API interface performs verification according to the request parameter corresponding to the calling request and the key pair corresponding to the application to which the target API interface belongs, and returns device information of a corresponding service capability type after the verification is successful, and performs a corresponding service using a corresponding device according to the device information;

[0079] In this embodiment, the step 6 specifically includes:

[0080] Step 61, after the target API interface receives the calling request, the target API interface obtains the request parameter corresponding to the calling request, the request parameter including an appKeyid of an application, a timestamp (10 bits, accurate to seconds) when a device initiates the request, a device SN number and a signature; the signature is calculated by concatenating the appKeyid, an appKeySecert, the timestamp when the device initiates the request and the device SN number in sequence and then encrypted by using an HMacSHA256 encryption algorithm (the key is the first ten bits of the appKeySecert) to obtain the signature (the encrypted signature value is a 64-bit lowercase string); other encryption algorithms can also be used for encryption;

[0081] Step 62, the appKeySecert in the key pair corresponding to the application to which the target API interface belongs is obtained;

[0082] Step 63, verification is performed according to the appKeyid of the application, the timestamp when the device initiates the request, the device SN number, the signature and the appKeySecert;

[0083] Step 64, after the verification is successful, device information of a corresponding service capability type is returned;

[0084] Step 65, a corresponding service is performed using a corresponding device according to the device information, and service information is obtained.

[0085] In this embodiment, the step 63 specifically includes:

[0086] Step 631, the appKeyid in the calling request, the appKeySecert in the key pair of the application to which the target API interface belongs, the timestamp when the device initiates the request in the calling request and the device SN number in the calling request are concatenated in sequence, and then encrypted by using an HMacSHA256 encryption algorithm to obtain a new signature;

[0087] Step 632, the signature in the calling request is compared with the new signature, if the signature and the new signature are consistent, step 633 is entered; if the signature and the new signature are inconsistent, it is indicated that the message is tampered with, the expected return information cannot be obtained, prompt information of signature verification failure is directly returned, and the process is ended;

[0088] Step 633, check whether the device SN number is recorded under the application according to the appKeyid and the device SN number of the application in the calling request. Specifically, the corresponding application is found through the appKeyid first, and then it is checked whether the device SN number is recorded under the application. If not, it indicates that the device does not exist, the verification fails, a prompt information that the device does not exist is returned, and the process ends. If yes, it is further judged whether the device SN number is in a usable state. If yes, step 634 is entered. If not, it indicates that the device is in a disabled state, the verification fails, a prompt information that the device is disabled is returned, and the process ends.

[0089] Step 634, calculate the time difference between the time stamp when the device initiates the request and the time stamp when the target API interface receives the request, and judge whether the time difference is greater than a time threshold. If yes, it indicates that the request is expired, and the process ends. Otherwise, the verification is successful, and step 64 is entered. Assuming that the time threshold is 3 minutes, if the time difference between the time stamp when the device initiates the request and the time stamp when the target API interface receives the request is greater than 3 minutes, the verification fails, and a prompt information that the upload time is incorrect is returned.

[0090] In the case that the above verifications fail, the correct return information corresponding to the API interface will not be returned, thereby ensuring the controllability of the API interface permission.

[0091] The API interface adds its own verification rule when being accessed, thereby ensuring the correctness and safety of data and avoiding the phenomenon of random calling of the interface and abuse.

[0092] In the embodiment, the request parameter further includes an IP address, and the calculation manner of the signature is to sequentially splice the appKeyid, the appKeySecert, the current time stamp, the device SN number and the IP address.

[0093] Step 7, record the calling data of each calling request for statistical analysis.

[0094] In the embodiment, the step 7 specifically includes:

[0095] Step 71, the server records the API interface, the request parameter and the response parameter called in the calling request process of all users, and saves them into a database, so that when a problem occurs, the problem can be quickly queried and located and investigated on the management end interface, and a faster, more convenient and efficient query mode is provided. The administrator of the management end can also view the use situation of each user and various capabilities, so as to better analyze the use frequency and situation table of the application capabilities, and also facilitate the unified management of the capability information. The permissions of each capability and user can also be controlled, and the source control effect is achieved.

[0096] Step 72, the service end carries out statistical analysis on the use and the number of times of calling of the API interface according to the recorded data, and can carry out statistical analysis from the user dimension and the device dimension.

[0097] The statistical report of the number of times of calling of the API interface (service capability type) use and the number of times of calling, the user dimension and the device dimension, the more intuitive report form and the deeper mining of the value, and the better assistance. The number of times of calling, the calling result state and the return result information are all displayed on the system page, so that the user experience is better. And the ability permission is constrained, the administrator can control and manage, and the ability can be recalled.

[0098] As shown in Figure 4 The embodiment of the present application also provides an electronic device, which comprises a memory, a processor and a computer program stored in the memory and executable on the processor, and the processor implements the above-mentioned multi-state service method of the aggregated POS extended application capability when executing the program.

[0099] As shown in Figure 5 The embodiment of the present application also provides a computer readable storage medium, which stores a computer program, and the program is executed by a processor to implement the above-mentioned multi-state service method of the aggregated POS extended application capability.

[0100] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically independent, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of software functional unit.

[0101] If the integrated unit is realized in the form of software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application or the whole or part of the technical solutions that make essential contributions to the prior art can be embodied in the form of software product, which is stored in a storage medium and includes a plurality of instructions for making a computer device (which can be a personal computer, a server or a network device) or a processor execute all or part of the steps of the method of each embodiment of the present application. The storage medium mentioned above includes a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk and various program code storage media.

[0102] The above merely describes some embodiments of the present application, and is not intended to limit the protection scope of the present application, and any equivalent device or equivalent process transformation, or direct or indirect application in other related technical fields, which are made by using the content of the present application specification and drawings, are also included in the patent protection scope of the present application.

Claims

1. A polymorphic service method for aggregating POS extended application capabilities, characterized in that: The steps include: Step 1. The administrator creates a user account for each user; Step 2: After logging in to your user account, create multiple applications under the corresponding user account, connect multiple API interfaces under each application, and configure each API interface with a required service capability type; specifically: Step 21: After logging into the user account, create multiple applications under the corresponding user account based on the customer dimension; the customer dimension refers to the name of the bank branch; Step 22: Connect multiple API interfaces to each application. Each API interface is configured with a required service capability type based on the capability type. The service capability types include product barcode capability, geographic location capability, email capability, and printing capability. Multiple API interfaces connected to the same application are configured with different service capability types. Step 23: Generate the URL address of each API interface; Step 3: Enter the device information corresponding to each service capability type under the device with that service capability type; Step 4: Configure the corresponding key pair for each application; Step 5: The POS device initiates a call request to the target API interface based on the service capability type that needs to be called; Step 6: After receiving the call request, the target API interface verifies the request parameters and the key pair corresponding to the application to which the target API interface belongs. If the verification is successful, the device information corresponding to the service capability type is returned, and the corresponding device is used to execute the corresponding service according to the device information; Step 7: Record the call data of each call request and perform statistical analysis.

2. The polymorphic service method for aggregating POS extended application capabilities according to claim 1, characterized in that: The device information includes the device SN number, and the key pair includes appKeyid and appKeySecert.

3. The polymorphic service method for aggregating POS extended application capabilities according to claim 2, characterized in that: The step 5 specifically includes: Step 51: Search for an API interface corresponding to the service capability type that needs to be called; Step 52: Select one or more of all the matching API interfaces as target API interfaces. Step 53: The POS device obtains the URL address corresponding to the target API interface; Step 54: The POS device initiates a call request to the target API interface through the URL address corresponding to the target API interface.

4. The polymorphic service method for aggregating POS extended application capabilities according to claim 2, characterized in that: The step 6 specifically includes: Step 61: After receiving the call request, the target API interface obtains the request parameters corresponding to the call request, which include the application's appKeyid, the timestamp when the device initiates the request, the device SN, and the signature. The signature is calculated by sequentially concatenating the appKeyid, appKeySecert, the timestamp when the device initiates the request, and the device SN, and encrypting them using the HMacSHA256 encryption algorithm to obtain the signature. Step 62: Get the appKeySecert in the key pair corresponding to the application to which the target API interface belongs; Step 63: Verify based on the application's appKeyid, the timestamp when the device initiates the request, the device SN, the signature, and the appKeySecert; Step 64: After successful verification, the device information corresponding to the service capability type is returned; Step 65: Use the corresponding device to execute the corresponding service according to the device information and obtain service information.

5. The polymorphic service method for aggregating POS extended application capabilities according to claim 4, characterized in that: The step 63 specifically includes: Step 631: Concatenate the appKeyid in the call request, the appKeySecert in the key pair of the application to which the target API interface belongs, the timestamp when the device initiates the request in the call request, and the device SN in the call request, and encrypt them using the HMacSHA256 encryption algorithm to obtain a new signature. Step 632: Compare the signature in the call request with the new signature. If they are consistent, proceed to step 633; ​​if they are inconsistent, it means that the message has been tampered with and the process ends. Step 633: Check whether the device SN is entered into the application based on the appKeyid and device SN of the application in the call request. If not, the process ends. If yes, continue to determine whether the device SN is in an available state. If so, proceed to step 634. Otherwise, the process ends. Step 634: Calculate the time difference between the timestamp when the device initiates the request and the timestamp when the target API interface receives the request, and determine whether the time difference is greater than the time threshold. If so, it means that the request has expired and the process ends; otherwise, the verification is successful and enters step 64.

6. The polymorphic service method for aggregating POS extended application capabilities according to claim 4, characterized in that: If the request parameter also includes an IP address, the signature is calculated by concatenating appKeyid, appKeySecert, current timestamp, device SN number, and IP address in sequence.

7. The polymorphic service method for aggregating POS extended application capabilities according to claim 1, characterized in that: The step 7 specifically includes: Step 71: Record the API interfaces, request parameters, and response parameters called during all user call requests and save them in the database. Step 72: Perform statistical analysis on the usage and call times of the API interface based on the recorded data.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the polymorphic service method for aggregating POS extended application capabilities as described in any one of claims 1 to 7 is implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the polymorphic service method for aggregating POS extended application capabilities as described in any one of claims 1 to 7 is implemented.

Images