HK1209931B - Method of processing requests for digital services - Google Patents

Description

How requests for digital services are handled

Technical Field

The present invention relates to a method for processing digital service requests and a related middleware system.

Background Art

Due to the proliferation of mobile devices 102, more relevant digital services have been introduced by service organizations (or providers) to capitalize on the growing available business opportunities. FIG1 depicts an example scenario in which a mobile device 102 accesses digital services provided by a service organization's backend server 104. However, with the explosive range of digital services being introduced daily, it is becoming increasingly difficult for users of mobile devices 102 to stay informed of the available digital services. In light of these developments, it is also challenging for service organizations to provide the correct types of digital services that users desire on a timely basis.

It is therefore an object of the present invention to address at least one of the problems of the prior art and/or to provide a useful choice in the art.

Summary of the Invention

According to a first aspect of the present invention, there is provided a method for processing requests for different digital services hosted by respective service organizations. The method comprises: receiving a request packet from a communication device, the request packet comprising a source identifier and a destination identifier; determining which of the different digital services the communication device is requesting based on the destination identifier; authenticating the request packet based on the source identifier to determine access permissions granted to the communication device for accessing the determined digital service; and, if access permissions are granted, modifying the request packet and forwarding the modified request packet to the determined digital service for processing based on the destination identifier.

The provided method advantageously eliminates complex, lengthy, and expensive point-to-point implementations. Furthermore, the method allows for a common interface that multiple mobile applications can use to communicate with a wide range of server systems. Consequently, new mobility application services can be brought to consumers more quickly for their benefit. In other words, the method allows for a unified gateway system that simplifies and facilitates the introduction of mobility application services to consumers.

Preferably, the communication device may be a mobile communication device or a wired communication device. Furthermore, the method may further include: if access permission is not granted, generating an error code, and forwarding an error packet including the error code to the communication device. More preferably, the method may further include retrieving device profile information from the communication device.

In addition, the method may preferably further include retrieving information corresponding to the location of the communication device from the communication device. In addition, the method may further include recording information related to processing the request packet. More preferably, the method may further include: in response to the forwarded request packet, receiving a response packet from a system associated with the destination identifier, processing the response packet to extract relevant data information, and forwarding the extracted data information to the communication device. Processing the response packet may include performing corresponding steps for analyzing the extracted data information. Preferably, the corresponding steps may be selected from the group consisting of the following steps: if the extracted data information includes an error message, recording the error message and sending a related error packet, and if the extracted data information includes a success message, recording the success message and sending a related success packet. Furthermore, the service agency may provide different digital services selected from the group including finance, logistics, retail, media, healthcare, infotainment, security, education and tourism.

According to a second aspect of the present invention, a processor for processing requests for different digital services hosted by respective service organizations is provided. The processor includes an aggregator module configured to receive a request packet from a communication device, the request packet including a source identifier and a destination identifier, and to determine, based on the destination identifier, which of the different digital services the communication device is requesting; and an authentication module configured to authenticate the request packet based on the source identifier to determine access permission granted to the communication device for accessing the determined digital service. If access permission is granted, the aggregator module modifies the request packet and, based on the destination identifier, forwards the modified request packet to the determined digital service for processing.

Preferably, the aggregation module may include a configuration submodule configured to apply access mapping rules to determine access permissions for communication devices. Furthermore, the aggregator module may also include an identity and access submodule configured to perform identity management for communication devices, wherein identity management includes providing authentication, authorization, and account management. Furthermore, the aggregator module may preferably include a transaction logging submodule configured to log information about request packets received by the aggregator module.

According to a third aspect of the present invention, there is provided a middleware system for enabling digital transactions between a communication device and a server system, the middleware system comprising the processor of the second aspect of the present invention.

It should be apparent that features described in relation to one aspect of the invention may also be applicable to other aspects of the invention.

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

The following discloses specific embodiments of the present invention with reference to the accompanying drawings, in which:

FIG1 shows an implementation of a point-to-point solution according to the prior art;

FIG2 shows a middleware system according to an embodiment of the present invention;

FIG3 shows the service framework of the system of FIG2 ;

FIG4 a depicts the collective intelligence framework of the system of FIG2 ;

FIG4 b depicts an alternative representation of the collective intelligence framework of FIG2 ;

FIG4 c depicts various components used in the collective intelligence framework of FIG2 as an example of a virtual-real super mall service;

FIG4 d depicts various components used in the collective intelligence framework of FIG2 as an example of an intelligent mobile banking service;

FIG5 is a schematic diagram of the core engine components described in the system of FIG4a;

FIG6 is a schematic diagram of a user situation in which the core engine component of FIG5 receives an original request;

FIG7 is a schematic diagram of a user scenario in which the core engine component of FIG5 receives a subsequent request; and

FIG8 shows the application of the system of FIG2 in the mobile Internet service value chain.

DETAILED DESCRIPTION

FIG2 illustrates a middleware system 200 (hereinafter referred to as the system) according to an embodiment of the present invention, and FIG3 illustrates a corresponding service framework 300 of the system 200. The system 200 is also referred to as a mobile integrated backbone (MLEB). Specifically, the system 200 is an internet-based integrated mobile command and control platform that serves as an intermediary gateway, interconnecting mobile applications installed on mobile devices 102 and bridging them to corresponding backend application servers 204 that provide mobile web and native application services through those mobile applications. The mobile devices 102 include both IP-based devices (e.g., smartphones, laptops, tablets, etc.) and non-IP-based devices (e.g., 2G phones, etc.). It will be appreciated that mobile web and native application services also include digital services that eliminate the need for a web page to complete a desired transaction. Mobile web and native application services further include services that provide related web-based content. It will be appreciated that mobile web and native application services enable transactions to be executed and information/data to be shared between the mobile devices 102 and the backend application servers 204. Backend application servers 204 include enterprise backend systems, such as systems managed by financial institutions (eg, banks or stock exchanges), commercial enterprises, government agencies, Internet providers, and the like.

The system 200 is conceptualized as a service framework 300 shown in FIG3 , which includes three tiers, with the mobile network 302 as the bottom tier, the system 200 being constructed as the middle tier, and the enterprise 304 forming the top tier. The mobile network 302 provides the necessary communication wireless connection/infrastructure to enable the mobile device 102 to connect to the enterprise 304 via the system 200.

It will be understood that enterprise 304 is the organization responsible for managing the respective backend application servers 204 depicted in FIG2 . Enterprise 304 is therefore the provider of local application services and mobile web pages accessible by users of mobile devices 102; in other words, it will be apparent that enterprise 304 (along with backend application servers 204) is also referred to as a service organization. As mentioned above, enterprise 304 includes organizations in business sectors such as finance (e.g., banks providing payment, clearing, and banking services), logistics, retail, media, healthcare, infotainment, and security. Enterprise 304 further includes government agencies providing services such as education, tourism, and the like.

As shown in Figure 3, system 200 acts as a bridge between mobile devices 102 in a mobile network 302 and backend application servers 204 of an enterprise 304, enabling transactions to be executed and information/data to be shared between the user of mobile device 102 and enterprise 304. System 200 is structured into various components, each of which will be further described with reference to the collective intelligence framework 400 of system 200 shown in Figure 4a. An alternative representation of collective intelligence framework 400 is shown in Figure 4b. Specifically, collective intelligence framework 400 includes the software components necessary for system 200 to function properly. Specifically, the components of system 200 are a communication channel (CC) component 2002, a core engine (CE) component 2004, a solution domain (SD) component 2006 (also referred to as a business domain component), a security interface component 2008, a support system component 20010, and a service interface component 20012. For the sake of brevity, the term "component" used to refer to each component will be omitted in the subsequent description. The collective intelligence framework 400 of the system 200 further includes a transmission channel 402 of the enterprise 304 and a backend application server 204 .

The delivery channel 402 is the means by which mobile web pages and native application services are delivered to the user of the mobile device 102, and more specifically, the means is the mobile (or native) application installed on the mobile device 102. The operating systems installed on the mobile device 102 may include Apple iOS ^™ , Google Android ^™ , BlackBerry OS ^™ , Windows Mobile ^™ , Symbian OS ^™ , and the like. Therefore, it is apparent that the mobile (or native) applications on the mobile device 102 are configured to be executable on the respective operating systems installed on the mobile device 102. As previously described, the backend application server 204 provides mobile web pages and native application services to the user of the mobile device 102. Accordingly, the system 200 is configured to aggregate those services and then provide the aggregated services to the user of the mobile device 102 via the delivery channel 402.

The communication channel 2002 enables the system 200 to communicate with the mobile network 302 to deliver mobile web pages and local application services to users of the mobile device 102. Specifically, as will be apparent to those skilled in the art, the communication channel 2002 includes interfaces (implemented as software submodules) that enable the system 200 to interact with the mobile network 302 via various communication channels/protocol stacks/network elements (such as SMPP, STK, USSD, RTSP, XHTML, WSDL, etc.). In addition, the communication channel 2002 is configured with a sublayer through which the system 200 can communicate with the backend application server 204. This sublayer includes interfaces such as TCP, SOAP, XMPP, SMTP/S, etc. It will be understood that the interfaces in the communication channel 2002 can be updated as needed (e.g., when existing protocols are updated to newer versions or new protocols become available due to new developments in related mobile and Internet technologies).

The core engine 2004 is configured to provide the primary functionality/services provided by the system 200. In this regard, the core engine 2004 handles user and session management for all other components 2002, 2006, 2008, 20010, and 20012 of the system 200. Specifically, the functionality/services provided by the core engine 2004 include, but are not limited to, identity and access management (IAM), transactions, aggregators, device management, SMS services, location, data marketplaces, streaming, biometric authentication (e.g., using iris or fingerprint), voice recognition, rules/BPM provisioning, secure payments (e.g., handshake), and the like. It will also be understood that new functionality/services can be enhanced to the core engine 2004 over time as needed based on specific requirements. Each functionality/service is provided by a software submodule installed within the core engine 2004.

A brief description of the services provided is provided below. All incoming requests received by system 200 are processed using a centralized IAM framework designed to handle authentication, authorization, and account management purposes. Regarding transaction logging, all transactions conducted through system 200 are recorded to allow for easy retrieval and consolidation of corresponding information when necessary; that is, the program is designed to generate records/reports that are timestamped to meet non-repudiation standards. For device management, system 200 identifies multiple mobile devices 102 by their respective identities. This primarily involves matching the ID field of incoming requests with system 200's device profile database. Device management also includes determining and managing device location, where system 200 obtains location data for the mobile device 102 initiating the request. Location data includes GPS data (i.e., longitude, latitude, and altitude), cellular ID, IP geolocation, and so on. Specifically, for IP-based mobile devices 102, the location data includes GPS data, while for non-IP-based mobile devices 102, the location data only includes the cellular ID, as GPS data is not readily available.

The aggregator then consolidates the mobile web and native application services provided by the enterprise 304, providing them to the mobile device 102, and handles the monitoring and control of the system 200. With regard to secure payments, the system 200 allows for the use of any appropriate payment protocol in this regard, such as the "Shake" protocol designed by Silverlake Mobility Eco Systems of Sdn. Bhd. of Malaysia, which is based on corresponding pairing algorithms pre-installed on the mobile device 102 and the backend application server 204, enabling secure payments and the exchange of data/information/documents between the mobile devices 102. With regard to biometric authentication, the system 200 performs fingerprint recognition and iris authentication methods to uniquely determine the identity of the user of the mobile device 204, thereby denying access to users who are not authorized to access the specific services provided by the service provider. Finally, the data market is used to store all received raw data, such as location data, country of origin, gender information, etc. The received raw data is then used for data and information analysis purposes.

Solution domain (or otherwise referred to as business domain) 2006 is configured to include the business logic and processing that provides the types of mobile web/digital and native application services offered by enterprise 304 that users desire. More specifically, solution domain 2006 includes multiple software sub-modules, each of which is configured to handle corresponding business logic and processing. In addition, each sub-module also has an equivalent front-end mobile application at the level of transmission channel 402, which is configured to retrieve relevant product/service information from back-end application server 204 to be presented to the user. It will be understood that new sub-modules can be added to solution domain 2006 as needed to include new business logic and processing; in other words, the configuration of solution domain 2006 can be evolved as needed.

Additionally, solution domain 2006 includes (provided through respective submodules) the following services: virtual-real supermall, smart mobile banking, mobile advertising, mobile wallet, mobile offers and redemptions, mobile flight and hotel reservations, content management, and others. In particular, the services provided by solution domain 2006 are services that users desire. The virtual-real supermall service offers a wide range of products and services to mobile device 102 users (i.e., shoppers), while the smart mobile domain provides services related to finance (e.g., mobile banking) and non-financial sectors (e.g., insurance offerings, movie reservations, etc.). For illustrative purposes, Figures 4c and 4d depict the highlighted components used in the collective intelligence framework 400 of system 200, respectively, related to the virtual-real supermall service and the smart mobile banking service. It will be appreciated that other services will utilize different components within the collective intelligence framework 400 accordingly.

The mobile advertising and alerting service provides a mobile channel that allows businesses 304 to subscribe to mobile advertising, and the system 200 is configured to send SMS alerts/notifications for purposes such as fraud reporting or promotional activities. The mobile wallet service then provides a secure payment service that utilizes a cashless, cardless and contactless transmission mechanism such as NFC or the above-mentioned "handshake" protocol. The mobile wallet is configured to be prepaid stored value or online postpaid. On the other hand, the mobile offers and discounts service enables users of the mobile device 102 to access electronic coupons for monetary offers/discounts and redeem merchant points for purchases. The travel and sightseeing service allows users of the mobile device 102 who wish to travel to book flights/accommodation, while the content management service enables users of the mobile device 102 to publish, edit and modify content (such as catalog information, product information, promotions and the like).

Regarding the service interface 20012, it includes third-party interfaces (such as SDE.OS and SDE.OS payment services). In particular, the service interface 20012 interfaces with the back-end application server 204 to provide services such as core banking for mobile banking, preferential schemes for merchant point redemption, fraud detection for fraud reporting, retail for providing products and services, etc. On the other hand, the service interface 20012 also interfaces with the relevant back-end application server 204 to provide core banking and card payment services. Therefore, through the service interface 20012 (which serves to convert data into a format suitable for use by different back-end application servers 204), companies such as logistics, aviation, travel, tourism, media, security, etc. can provide their services to users of mobile devices 102.

Support Systems 20010 include the necessary provisioning/management/operation support business systems or back office for monitoring and reporting purposes.

In addition, the system 200 provides a security interface 2008 (e.g., encryption and security hardening) for the mobile device 102 to the backend application server 204, so as to clearly determine the necessary access rights of the mobile device 102 requesting access. Specifically, the security interface 2008 is configured to handle aspects of mobile Internet security related to security mechanisms such as injection attacks, cross-site scripting (XSS), broken authentication, session management, etc. In addition, the security interface 2008 also implements other aspects of mobile security for the mobile device 102 at the level of the transmission channel 402, such as never saving sensitive items, random PIN numbers, jailbreak detection, etc.

5 accordingly shows a schematic diagram 500 of the core engine 2004 of the system 200. The core engine 2004 primarily includes an aggregator 502, with other modules including a configuration manager 504, an identity and access manager 506, a transaction log manager 508, a tracking helper 510, a configuration helper 512, a device profile manager 514, and a location manager 516 being communicatively coupled thereto. It will be understood that the configuration manager 504, the identity and access manager 506, the transaction log manager 508, the device profile manager 514, and the device location manager 516 are also collectively referred to as manager modules.

The aggregator 502 serves as a centralized interaction hub for coordinating/directing incoming requests and outgoing responses between the communication channels 2002 and the solution domains 2006 of the system 200. Importantly, the aggregator 502 ensures control and consistency of operations by requiring all requests/responses to undergo the same set of processing checks, which are provided by the manager modules 504, 506, 508, 510, 512, 514, 516. Furthermore, any system requests communicated between the manager modules 504, 506, 508, 510, 512, 514, 516 are also routed through the aggregator 502.

Aggregator 502 also provides specialized functionality in handling user management for the following activity types: (i) starting a session for an anonymous user, (ii) logging in for a registered user, (iii) registering a new user, (iv) updating a user's details, and (v) retrieving a user's record.

Depending on the configuration, the aggregator 502 is arranged to actively listen in the background for receiving requests sent from the solution domain 2006 or the communication channel 2002. It should be emphasized that requests from the solution domain 2006 or the communication channel 2002 are treated the same by the aggregator 502; in other words, the requests are processed based on the received command without priority treatment. It will also be apparent that when a user of the mobile device 102 initiates a request to perform a transaction, a request to the backend application server 204 (received via the communication channel 2002) is generated. It will be understood that a transaction may include only a single request or multiple consecutive requests. The requests received by the aggregator 502 are then forwarded to the appropriate software submodule of the communication channel 2002 or the solution domain 2006 for processing. In addition, the request is uniquely identified by the aggregator 502 based on the client password included in the corresponding request.

Requests are distinguished into two types: (i) original requests, and (ii) subsequent requests. As will be apparent, requests are formatted in the form of digital packets for transmission. An original request is a request to initiate a desired transaction and includes the following object fields: a transaction header, a request header, and a body. The transaction header includes information about the transaction, a customer code, and a session ID. The customer code is associated with a session ID, which expires after a predetermined time (e.g., twenty seconds). The request header includes information about the request, including the source of the request (i.e., the mobile device 102 operated by the user) and the destination of the request, while the body includes the request data to be forwarded to the destination of the request for further processing.

A subsequent request is a subsequent request that follows an earlier original request and includes the following object fields: an aggregator header, a request header, and a body. Specifically, the aggregator header includes information about the earlier transaction received from aggregator 502 based on the processing of the original request. The request header, which includes information about the request, includes the request source and the request destination, while the body includes the request data to be forwarded to the request destination for further processing.

Any request received by the aggregator 502 is first forwarded to the respective manager module, which is arranged within the core engine 2004 for verification and other related processing to be performed. Once this is completed, the request is modified by the aggregator 502 and is thus converted into a new packet (i.e., the values of specific fields of the original request packet are changed), and forwarded to the request destination. In particular, the new packet includes two object fields: an aggregator header and a body. The aggregator header provides information about the aggregator 502 after processing a particular transaction, and includes transaction, customer code, session, user, device and location information. The body includes the request data to be forwarded to the request destination for further processing.

The processing request is then forwarded by the aggregator 502 to the request destination (i.e., the relevant backend application server 204) for further relevant processing. The forwarded request is thus processed successfully or unsuccessfully by the request destination. In the case of successful processing, the result returned by the request destination is then forwarded to the request source as a response object, which contains the data of the returned result. On the other hand, in the case of unsuccessful processing, an error response (which includes an error exception code) is received from the request destination and the aggregator 502 thereafter forwards the error response to the request source.

Configuration manager 504 is arranged to apply access mapping rules that determine whether the request source is authorized to communicate with the request destination (i.e., backend application server 204) as specified in the request. This is determined by comparing the request source and the associated request destination against the access mapping rules stored in (a database of) configuration manager 504. Access mapping rules have a defined two-level granularity (i.e., based on the destination component and the associated functionality), and all rules are configured based on requirements. Thus, system 200 can grant or revoke dynamically configured access rights (i.e., permissions) during runtime.

As for the identity and access manager 506, it is configured to control identity management (i.e., authentication, authorization, and account management) via a central framework to assist users accessing the system 200 via mobile devices 102. In particular, the identity of incoming requests is determined to enable the system 200 to authenticate, authorize, and manage accounts for the purposes of authentication, authorization, and account management. Authentication enables a determination to be made as to whether the request is initiated from a registered entity (i.e., user/device) or an anonymous entity in order to grant/deny access. Thus, if the request is indeed from an entity that has registered with the system 200, the request is mapped to the corresponding user and a newly generated session ID. Authorization, based on the identity credentials, enables a determination as to whether the registered entity is permitted to communicate with the request destination specified in the request (i.e., backend application server 204). Similarly, account management, based on the identity credentials, allows identification and extraction of information contained in the request header, which is used for transaction account management purposes.

Furthermore, the identity and access manager 506 supports the use of multiple identity repositories. Using a master identity repository allows for controlling access to multiple applications for a single subscriber, while using independent identity repositories, on the other hand, allows for controlling user access to individual applications that require control over their respective user groups. The identity repository can be an external repository or a repository configured within the system 200, depending on the application requirements. Furthermore, all identity information (including user IDs, passwords, profile information, etc.) can be configured to allow for dynamic customization of user access configurations, allowing for the granting or revocation of user access rights at runtime, as will be apparent to those skilled in the art.

The transaction record manager 508 is configured to record information about all incoming requests received by the aggregator 502, and transaction processing data is recorded in a central database repository that is optimally coordinated for the required speed and performance. Further, all additional information associated with each request (such as identity and device profiles) is recorded along with any relevant transaction data. Recording is performed for both request receipt and response submission to illustrate the initiator of the request and the outcome of the transaction. It will be understood that for audit purposes, a transaction is defined as the smallest unit of work that is independently tracked within the system 200. In addition, all recorded transactions are time-stamped to comply with non-repudiation standards and allow easy retrieval and merging of any recorded details. Any transaction is described as two records, where the first record (i.e., the "request record") is used to record the request received, while the second record (i.e., the "response record") is used to record the response submitted in accordance with the corresponding request.

Specifically, the request record stores the following information fields: "Request timestamp", "Request source", "Request destination", "Server ID" (which identifies the backend application server 204), "Thread ID" (which identifies the processing system thread), "Customer ID", "Transaction ID" (which groups multiple requests serving the same transaction), "Session ID" (if available), "User ID" (if available), "Device profile information" (if available), and "Device location information" (if available).

On the other hand, the response record stores the following fields of information: "Response Timestamp," "Server ID" (which identifies the hosting application server), "Thread ID" (which identifies the processing thread), "Result Code" (indicating a success code or an error code), and "Result Message" (as a success message or an error message). It will be understood that a list of result codes will be pre-loaded and referenced against a comprehensive message mapping table stored in a system database (not shown) accessible to the core engine 2004. Further, the result message is parameterized using the format of "{0}," where the system 200 then replaces the "0" in the format "{0}" with an appropriate string value. For purposes of illustration, an example of a result message encoded in the format of "{0}" is "{SYS 100}," where, with reference to the message mapping table, "SYS 100" refers to "Invalid User Login."

The trace helper 510 is arranged to record system traces/messages in a trace log, which is used to assist in debugging, performance optimization, decoding runtime unknown exceptions, and any other non-operational related logging. The trace log includes the following information: "trace timestamp", "server ID" (which identifies the backend application server 204), "thread ID" (which identifies the processing system thread), and "trace message". The message is parameterized using the format of "{0}", where the system then replaces the "0" in the format "{0}" with an appropriate string value. This can also be understood with reference to the similar previous description in the previous paragraph.

The configuration helper 512 is then configured to control access to the global configuration parameters used by the core engine 2004. It will be appreciated that the global configuration parameters are pre-loaded and referenced with respect to the message mapping table.

The device profile manager 514 is configured to store a database containing profile information about mobile devices 102 that have requested services, and thus allows management of those mobile devices 102 in the form of granting relevant access rights. On the other hand, the device location manager 516 is then configured to determine whether the specific mobile device 102 that sent the request is located in the vicinity of a merchant providing the requested service, and if so, use the information accordingly to better assist in preparing the service for the user operating the mobile device 102. That is, the device location manager 516 can locate the specific mobile device 102 via the location data, as previously described.

Figure 6 depicts a user scenario diagram 600 regarding the receipt of an original request by the core engine 2004 (via the aggregator 502). The aggregator 502 initially receives a request for a transaction sent by a request source 602 (via the communication channel 2002 or the solution domain 2006) to a request destination 604. The request includes transaction information (i.e., customer code, transaction, and session), a request header (i.e., information about the request source 602 and the request destination 604), and a body, as previously described. The request is then processed in an orderly manner by the respective manager modules in the following order: (1) The identity and manager 506 is triggered to determine the identity of the requesting user based on the session identifier (if available). If the user identity is determined to be valid, the identity information of the relevant user is then appended to the request header, (2) The device profile manager 514 is then activated to determine the device profile of the mobile device 102 that initiated the request (if such device profile information is available). The retrieved profile information is written to the original request header (i.e., the request header is modified), (3) The device location manager 516 is then activated to determine the location of the mobile device 102 (if such location information is available). The retrieved location information is then written to the request header, (4) the transaction log manager 508 is activated to record relevant records for processing the request corresponding to the transaction, and (5) the configuration manager 504 is finally used to determine the access rights of the request source 602 to communicate with the request destination 604. If valid access rights exist, the request is allowed. However, if the access rights are invalid, an exception is thrown accordingly. The transaction log manager 508 then records the error message generated due to the determination of invalid access rights (including the error code corresponding to the thrown exception). The aggregator 502 then forwards the thrown exception back to the request source 602 as an error packet.

Assuming valid access rights exist, the original request, but with the modified header, is forwarded to request destination 604, and aggregator 502 awaits a response, which will be returned via request destination 604. If request destination 604 does not exist, is unavailable, or no response is received within a predetermined expiration time, aggregator 502 throws an exception. Transaction log manager 508 is then activated to log an error message, including an error code corresponding to the thrown exception, and aggregator 502 also forwards the thrown exception back to request source 602 as an error packet. On the other hand, if request destination 604 responds with an exception, aggregator 502 catches the exception. Similarly, an error message regarding the generated exception is logged by transaction log manager 508, and aggregator 502 forwards the thrown exception back to request source 602 as an error packet. If request destination 604 responds with a success message, the success message (as a success packet) is forwarded to request source 602, and transaction log manager 508 accordingly logs information corresponding to receipt of the success message.

FIG7 depicts a user scenario diagram 700 regarding a subsequent request received by the core engine layer 2004 (via the aggregator 502). The aggregator 502 initially receives a request for a transaction sent by a request source 702 (via the communication channel 2002 or the solution domain 2006) to a request destination 704. It will be understood that the values of the request destination 704 and the request source 702 of this subsequent request correspond to the respective values of the request destination 604 and the request source 602 of the original request of FIG6 . The request includes an aggregator header (i.e., transaction, customer, session, user, device, and location), a request header (i.e., information about the request source 702 and the request destination 704), and a body, as previously described. In this example, the request is processed by several manager modules in the following order: (i) the transaction record manager 508 is activated to record the relevant records corresponding to the processed request, and (ii) the configuration manager 504 is triggered to determine the access rights of the request source 702 to communicate with the request destination 704. If valid access rights exist, the request is granted. However, if the access right is verified to be invalid, the aggregator 502 throws an exception. An error message corresponding to the error code of the thrown exception is then recorded by the transaction record manager 508. Subsequently, the aggregator 502 forwards the thrown exception back to the request source 702 as an error packet.

Assuming valid access rights exist, the request with the modified header is forwarded to the request destination 704, and the aggregator 502 awaits a response from the request destination 704. If the request destination is unavailable, does not exist, or no response is received within a predetermined expiration time, the aggregator 502 throws an exception. The transaction log manager 508 is then activated to log an error message including an error code corresponding to the thrown exception, and the aggregator 502 then forwards the thrown exception back to the request source 702 as an error packet. Similarly, if the request destination 704 responds with an exception, the exception is captured by the aggregator 502. An error message is then logged by the transaction log manager 508, and the aggregator 502 forwards the thrown exception back to the request source 702 as an error packet. On the other hand, if the request destination 704 responds with a success message, the success message (as a success packet) is forwarded to the request source 702, and the transaction log manager 508 accordingly logs information corresponding to the receipt of the success message.

By using system 200, the complex, lengthy, and expensive point-to-point implementation typically used to develop traditional middleware systems can be eliminated. Furthermore, with respect to the mobile internet service value chain, system 200 functions as a common platform that can be utilized by a variety of mobile applications, communicating with a variety of backend application servers 204. As a result, the pace of introduction of new mobile web and native application services can be advantageously accelerated, thereby allowing for a more focused, rather than targeted, development of business domains desired by merchants (i.e., service entities). The specific roles of system 200 in the mobile internet service value chain depicted in FIG8 (wherein the value chain primarily includes four key players) are mobile device users (who consume mobile web and native application services), mobile network operators (who deliver mobile communication services), enterprises (who provide mobile web and native application services), and system 200 (which connects mobile device users and enterprises by integrating and aggregating mobile communication services and application services). In other words, system 200 is a unified gateway and service enabler that will advantageously simplify and facilitate the introduction of integrated mobile web and native application services to mobile consumers.

However, the described embodiments should not be construed as limiting. For example, it will be understood that the system 200 can also be used in a wired communication system (eg, a desktop-based personal computer), rather than being limited to only the mobile device 102 communicating with the backend application server 204.

While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary rather than restrictive; the invention is not limited to the specific embodiments disclosed. Other variations to the specific embodiments disclosed will be apparent to and accomplished by those skilled in the art in practicing the invention as defined by the claims.

Claims (14)

1. A method for processing requests for different digital services hosted by their respective service providers, the method comprising: Receive a request packet from the communication device, the request packet including a source identifier and a destination identifier; The destination identifier is used to determine which of the different digital services the communication device is requesting; Based on the source identifier authentication request packet, the access permission of the communication device for accessing the identified digital services is determined; and If access is granted, the request packet is modified and forwarded to the determined digital service for processing based on the destination identifier; The authentication request packet includes: comparing a source identifier and a destination identifier with access mapping rules having a granular hierarchy based on destination components and their associated functionalities, wherein the access mapping rules are configurable to allow dynamic user access. The modification request packet includes mapping the request to a corresponding client code and a newly generated session ID; the client code and the session ID are associated, and the session ID expires after a predetermined time. When one of the different digital services is invalid, does not exist, or does not receive a response within the predetermined expiration time, an error data packet is sent to the communication device. 2. The method according to claim 1, wherein the communication device is a mobile communication device. 3. The method according to claim 1, wherein the communication device is a wired communication device. 4. The method according to any one of the preceding claims further includes: If access is not granted, an error code is generated; and Forward error packets, including error codes, to the communication device. 5. The method according to any one of claims 1-3 further includes retrieving device configuration file information from the communication device. 6. The method according to any one of claims 1-3 further includes retrieving information corresponding to the location of the communication device from the communication device. 7. The method according to any one of claims 1-3 further includes recording information related to processing the request packet. 8. The method according to any one of claims 1-3, further comprising: In response to the forwarded request packet, receive a response packet from the system associated with the destination identifier; Process the response packet to extract relevant data information; and The extracted data information is forwarded to the communication device. The processing response package includes the corresponding steps for analyzing the extracted data information. 9. The method of claim 8, wherein the corresponding step is selected from the group consisting of the following steps: if the extracted data information includes an error message, then record the error message and send the relevant error packet; and if the extracted data information includes a success message, then record the success message and send the relevant success packet. 10. The method according to any one of claims 1-3, wherein the service provider offers different digital services selected from the group including finance, logistics, retail, media, healthcare, infotainment, security, education, and travel. 11. A processor for processing requests for different digital services hosted by their respective service providers, the processor comprising: An aggregator module is configured to receive a request packet from a communication device, the request packet including a source identifier and a destination identifier, and to determine, based on the destination identifier, which of the different digital services the communication device is requesting; and The authentication module is used to determine the communication device's access permission for accessing the identified digital services based on the source identifier authentication request packet. If access permission is granted, the aggregator module modifies the request packet and forwards the modified request packet to the determined digital service for processing based on the destination identifier; wherein the aggregator module includes a configuration submodule arranged to compare the source identifier and destination identifier with an access mapping rule having a granular hierarchy based on the destination component and its associated functions, wherein the access mapping rule is configurable to allow dynamic user access, wherein modifying the request packet includes mapping the request to a corresponding client code and a newly generated session ID; the client code and session ID are associated, the session ID expiring after a predetermined time, and an error data packet is sent to the communication device when one of the different digital services is invalid, does not exist, or does not receive a response within the predetermined expiration time. 12. The processor of claim 11, wherein the aggregator module includes an identity and access submodule configured to perform identity management of the communication device. Identity management includes providing authentication, authorization, and account management. 13. The processor of claim 11 or 12, wherein the aggregator module includes a transaction recording submodule configured to record information about request packets received by the aggregator module. 14. A middleware system for enabling digital transactions between communication devices and server systems, the middleware system comprising the processor as described in claim 11 or 12.