FIELD OF THE INVENTION
Embodiments of the present invention generally relates to enterprise communication. Particularly, the embodiments of present invention relate to multiple enterprise service communication and more particularly relates to a multiple enterprise relationship system (MERS) and the method thereof.
DESCRIPTION OF PRIOR ART
Today's enterprise applications are maintained and enhanced with high-end software and manpower to enable various needs of an enterprise. Almost all the different business applications in an enterprise have common functionalities like authentication, alert service, payments, etc. The applications realizing these business processes would be of varied architecture and design. The enterprises that are deploying these applications employ people with different skills, use different software/hardware and configure different network setups and so on. In many cases, the architecture of these applications is tightly coupled with common functionalities, which means that they have to undergo constant changes if the usage of the application changes. Thereby, there are restrictions for different business processes within a company to share a common enterprise application in practical terms.
The existing systems mainly deal with services restricted to certain communication medium or device. The technologies incorporated in these systems are not suitable if the enterprise has their own custom defined needs.

Further, the existing applications cannot be extended to support other business needs that are required in the enterprise. In most of the cases, the enterprise is tuned to the solution rather than the solution getting tuned for enterprise needs. Thus, in conventional systems, there is a need to define specific communication objects for each type of communication medium or service or there needs to be applications developed that adhere to the service oriented architecture (SOA).
Therefore, there is a need for a single system providing multiple enterprise relationship services, wherein the system is independent of SOA and independent of communication medium, which helps in reducing different hardware/software setup or rare skilled manpower cost and helps the business function in a better way.
SUMMARY OF THE INVENTION
The primary objective of the present invention is to provide an efficient multiple enterprise relationship system, which bridges various enterprise needs and services.
In one aspect, a multiple enterprise relationship system (MERS) includes an enterprise service agent (ESA) for sending at least one service request over a communication medium and an enterprise relationship server (ERS) interfaced with the ESA for authorizing service requests, identifying the service through

intelligent decision making and routing the service request to relevant service provider.
Accordingly, the present invention relates to the system, wherein the ERS includes an ERS hook for receiving a service request from the ESA over the communication medium; an intelligent network service router (INSR) for receiving the service request from the ERS hook as a narrow point communication or a broad way communication over an enterprise relationship application protocol interface (ERAPI); creating a service ID through intelligent decision making; and creating a session identifier for the service request in the session database. A business logic server (BLS) to manage sessions and credentials associated with the service request and an external application interface (EAI) to place the service request to the relevant service provider, wherein the INSR obtains response associated with the service request from the relevant service provider, and the INSR communicates the response to the ESA through the ERS hook.
Accordingly, the present invention relates to the system, wherein the ERS hook includes one or more access points for identifying whether a service ID associated with the service request is registered in a service identification map (SIM) of one or more access points; if so, the ERS hook routes the service request to the INSR as a narrow point communication; else, the ERS hook routes the service request to the INSR as a broad way communication, wherein the

INSR creates a service ID though intelligent decision making if the service request is routed as the broad way communication.
Accordingly, the present invention relates to the system, wherein the ERS hook further comprises an ERAPI converter coupled to each of the access points for converting the service request sent by the ESA in standard protocol format to ERAPI format, wherein the ERS relies on the request adhering to the ERAPI format.
In another aspect, a method for providing multiple enterprise services to an enterprise service agent (ESA) includes steps of receiving a service request from the ESA by an enterprise relationship server (ERS) hook of the ERS over a communication medium; routing the service request to an intelligent network service router (INSR) as a narrow point communication or a broad way communication over an enterprise relationship application protocol interface (ERAPI); creating a service ID by the INSR for the received request through broad way communication; creating a session identifier for the service request in the session database; using a business logic server (BLS) to manage sessions and credentials associated with the service request; placing the service request on a relevant service provider using an external application interface (EAI); obtaining response associated with the service request from the relevant service provider by the INSR; and communicating the response to the ESA by the INSR through the ERS hook.

Accordingly, the present invention relates to the method, wherein the intelligent decision making includes cloning the service request with a number of services registered with an access point, creating N requests by specifying the group ID and service ID, forwarding the N requests to all the service providers and upon getting at least one true response from the service provider by the INSR, registering the service in the SIM of the access point and the INSR, and clearing false requests.
These and other objects, features and advantages of the present invention will become more apparent from the ensuing detailed description of the invention taken in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
Example embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
Figure 1 is a system illustrating a multiple enterprise relationship system (MERS), according to one embodiment of the present invention.
Figure 2 is an exemplary schematic representation of an external application interface (EAI) communicating with various external service providers, in

accordance with the present invention.
Figure 3 is a flowchart illustrating a method of providing multiple enterprise relationship services by the system in Figure 1, according to one embodiment of the present invention.
Figure 4 is a flowchart illustrating a method for service identification by an INSR through intelligent decision making, according to one embodiment of the present invention.
Other features of the present embodiments will be apparent from the accompanying drawings and from the detailed description that follows.
DETAILED DESCRIPTION OF THE INVENTION
The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art about making and/or using the invention. However in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present

invention in detail.
The present invention describes a multiple enterprise relationship system (IVIERS), which bridges various enterprise needs and services. The MERS includes various entities and its own protocol which enables it to be deployed with any existing enterprise system or new applications to support various enterprise needs. Thus, the MERS helps enterprise entities to setup a single system and the functionalities/services fine tuned according to their needs. In one example embodiment, the MERS provides entity relationship in an enterprise or among multiple enterprises over any communication medium. The entity relationship can be defined as any service such as but not restricted to transaction or signaling or communication between two entities which can be represented as a real world object. Further, the service can traverse from one entity to another entity as analogue data or digital data through any communication medium. The architecture of MERS is illustrated in Figure 1.
Figure 1 is a system illustrating a multiple enterprise relationship system (MERS) (100), according to one embodiment of the present invention. Particularly, the MERS (100) includes an enterprise service agent (ESA) (102) seeking at least one service through an enterprise relationship server (ERS) (104), which is interfaced to one or more service providers through an external application interface (EAI) (110). Further, the MERS (100) includes an enterprise relationship application protocol interface (ERAPI) for routing the signaling of the service in

the ERS (104). The coupling of ESA (102), ERS (104) and EAI (110) are described further in the description.
In one exemplary implementation, the ESA (102) is an entity seeking for a service through ERS (104). The ESA (102) can include but not restricted to an entity such as mobile phone, PDA, computer, banking solution provider interface servers, telecom service provider's SMSC, MMSC, MSC, etc. In one embodiment, the ESA (102) communicates with the ERS (104) over any communication medium using the ERS hook (106) of the ERS (104) for availing services. The communication medium includes wired or wireless communication medium.
In one example embodiment, the ERS (104) includes the ERS hook (106), an intelligent network service router (INSR) (108), a business logic server (BLS) (114) and the external application interface (EAI) (110), which are coupled as shown in Figure 1. Further, the ERS hook (106) includes multiple access points (106A-G) and corresponding ERAPI converter (106A^-G^). The access points (106A-G) can include but not restricted to LAN/WAN access point (106A), GPRS access point (106B), WWW access point (106C), Bluetooth access point (106D), WIN-MAX access point (106E), WI-FI access point (106F), NFC access point (106G) (the corresponding ERAPI converters are represented as 106A\ 106B\ 106C\...106G\ respectively which convert the standard protocol to ERAPI format while sending the request to INSR (108) and converting back to the standard protocol while responding back to the ESA (102)). The INSR (108) is

the core of the ERS (104). The INSR (108) is coupled to the BLS (114) to manage the sessions and credentials of any service request and response flowing through the INSR (108). Further, the INSR (108) contains its own SIM repository which contains data about all registered services.
In one example embodiment, the ERS (104) is capable of authenticating ESA (102) requests, identifying the service (identifying (102) type and the type of service) and providing services associated with the requests. The ERS (104) authentication process can support the industry standards such as, but not restricted to RFID validation, barcode authorization, IMEI (of the mobile devices) verification, WWW SSL certificate authorization and LANA/VLAN network credentials validations. Further, the ERS will respond back to the ESA with the response obtained from the external interfaced service providers or with its own responsive system such as timeout, invalid request etc. It is to be appreciated that the ERS does not depend on the type of communication medium and only relies on the service request adhering to the ERAPI, which is achieved by the corresponding ERAPI converters (106A^-G^) of the ERS hook (106).
In one example embodiment, the ERAPI is used as a communication protocol to standardize the process of identifying the ESA (102) and relating it to the service provider (112). The ERAPI exposes various application programming interface (API) that can be custom defined and used to suit the enterprise needs. In one exemplary implementation, the ERAPI follows the open system interconnection

(OSI) model standards and also complies with the open mobile alliance (OMA) standards. In one example embodiment, the ERAPI (106) is used to obtain the enterprise service through any communication medium. The general format of ERAPI and the header of the protocol are depicted in Table 1 and Table 2 respectively.



In one exemplary implementation, the access points (106A-G) are connecting points between the ESA (102) and the ERS (104). Each access point includes a repository called service identification map (SIM) which gets populated when any service is registered with the corresponding access point. Any request flow through the access points includes a service identifier (intended service) and group identifier of the service. Further, the access points (106A-G) maintain a reserved session pool which is obtained from the INSR (108) to serve the ESA requests and assigns the request with unique session ID before passing it on to the next layer. Once the session pool reservation falls behind said water mark (completion of usage of requested session IDs), the access points request the INSR again for another pool of session IDs. It is appreciated that with the unique session ID for each request, the INSR can identify the corresponding access point of the request when the INSR receives the same and also it will be used in routing the acknowledgement of the service to the respective ESA through the corresponding access point.

Further, the INSR (110) is the core business logic of the MERS (100). It will ensure that each access point is updated regularly with the service registered and the type of the service request it serves. Furthermore, the INSR (110) is coupled with the BLS (114) to manage the sessions and credentials of any request or response flowing through INSR (110). The INSR (110) also includes its own service identification map (SIM) repository which contains meta-data about all registered services. In addition, the BLS (114) is coupled with a session database (116) for storing registered service information such as session identifiers, meta-data etc.
In one exemplary implementation, the EAI (110), hub for all the services registered with the MERS (100), provides interface ports to N number of service providers. In one exemplary embodiment, the EAI (110) includes an inverse ERAPI converter (110A) to convert the requested data from the ERAPI format to the standard format and routes it to the service provider (112) which is registered at a particular port and the inverse ERAPI converter (110A) converts the standard protocol to the ERAPI format while responding back to BLS (114). Further, depending on the service return codes from the service provider (112), a response is generated to inform the BLS (114) regarding successful service or invalid data format. Further, the BLS (114) sends the response to the ESA (102) through the INSR (108) and the corresponding access point. Various service

providers associated with the EAI (110) are illustrated in Figure 2 and the method of Figure 1 is illustrated in Figure 3.
Figure 2 is an exemplary schematic representation (200) of an external application interface (EAI) communicating with various external service providers (112), in accordance with the present invention. In one exemplary implementation, the external service providers (112) include but not restricted to a payment gateway (112A), an inventory interface (112B), a PBX interface (112C), an authentication service interface (112D) and a banking interface (112N). The external service providers (112) are coupled to the EAI 110, as shown in Figure 2, to provide the service requested by the ESA (102).
Figure 3 is a flowchart (300) illustrating a method of providing multiple enterprise relationship services by the system in Figure 1, according to one embodiment of the present invention. In step 302, the ESA (102) sends a service request to the ERS hook (106) of the ERS (104) through any communication medium. In one example embodiment, the communication medium includes but not limited to wired and/or wireless communication medium such as LAN/WLAN, WWW, NFC, Bluetooth, Wi-Fi and Wi-Max.
In step 304, the service request will be in queue at the respective access point's buffer of the ERS hook (106). Further, the ERS hook (106) determines whether the service associated with the service request is registered in the SIM of the

access point. Furthermore, the ERAPI converter (106A^-G^) of the respective access point converts the standard protocol request into ERAPI format. Then, the ERS hook decides whether to forward the request to the INSR (108) as a narrow point communication or broad way communication. In one embodiment, if the service is identified in the SIM of the access point, then the service is routed to INSR (108) as the narrow point communication. Further, if the service is unidentified in the SIM of the access point, then the service is forwarded to INSR (108) for service identification as a broad way communication. The ERAPI format for service identified in the SIM of the access point and service not identified in the SIM of the access point are depicted in Table 3 and Table 4 respectively. It can be noted that all the mandatory fields are populated by the access point itself if the service is identified in the SIM.



Table 4 In step 306, the INSR (108) checks whether the received request is through narrow point communication or broad way communication. If the request is received through broad way communication, then the INSR (108) creates a service ID through intelligent decision making in step 308, i.e., the INSR (108) populates corresponding service ID and group ID fields. In one example embodiment, the step of intelligent decision making is described in Figure 4. The

format of the protocol of the identified service request by the INSR (108) is depicted in Table 5. If the received request is through narrow point communication and/or upon identification of the service ID by the INSR (108), then the INSR (108) creates a session identifier in the session database using the BLS (114), in step 310. In these embodiments, the BLS (114) verifies the credentials before creating the session identifier for that ESA (102). In one example embodiment, the session Identifiers will be created irrespective of the ESA (102) using a session or non-session based mode of communication.


In step 312, the BLS (114) places the service request on the relevant service providers through EAI (110) for real object processing. In 314, corresponding service provider responds back to the BLS (114) through the EAI (110) to provide a successful service or indicating any error. In step 316, the BLS (114) responds back to the ESA (102) using INSR (108) through particular access point of the ERS hook (106). In one example embodiment, the session database is updated with the identified service associated with the service request.
Further, once the service request is honoured, the INSR (108) will create a new action to register a new service and related service identification at the access point SIM. It is to be noted that the action is created only if the INSR (108) is involved to identify the service; otherwise no action is performed on the generated response. Further, once the access point registers the object related service it resends the receipt to INSR (108) for closing the action. Each action created in each step sets a flag until it clears normally else an alarm is generated.
In summary, the ESA (102) fills all data other than the service ID and group ID in the header if the service is not known to it before sending the request. The respective access point, when it receives the request checks for the service ID after initial validation of the message and picks up the services offered by MERS through the SIM repository of that access point. If multiple services are offered, it sends the data to INSR (108) for broadcasting to all the intended service

providers. The one that accepts the request shall proceed with serving the need of the request. The return of the response will ensure that the SIM is updated with the data of the signature to identify the correct service for future requests. In case there is no response to the ESA (102), then the SIM will get updated with a no service available flag. It can be noted that the data signatures are some part of data that is coming to access points which are stored if the service is successfully routed to EAI (110) with a successful response back to the ESA (102).
Figure 4 is a flowchart (400) illustrating a method for service identification by an INSR (108) through intelligent decision making, according to one embodiment of the present invention. Particularly, the method followed by the INSR (108) for service identification when the service ID associated with the service request is not identified in its SIM is described. In step 402, the received service request is cloned with the number of services registered with the access point, provided the service provider is open to receive the broadcasted messages. In step 404, multiple requests (N) which include (N-1) false requests and one true request are created by specifying the group ID and service ID. It is appreciated that, if the services are more, step 404 can be split into small segments to avoid the network overhead. In step 406, the service request is passed on to all the service providers and generation of at least one true response by the ERS (104). In step 408, upon the reception of the response, INSR (108) sets the action for registering the service. In step 410, all the false requests are cleared by either

timeout or by getting a negative response from the ERS (104). The invalid service data format at related service id is kept in the metadata to avoid future false requests going to the service, thus increasing the performance of the MERS (100).
It is appreciated that, with the above described method, any new type of request received by the MERS gets the appropriate service identified and registered for further delivery from the access point. Upon registration of the new service and related object, access point will populate the same for future prospects. The SIM at each level acts as data for all the services rendered through the access points. It can be noted that the service may get cleared due to timeout in the process of identification, but the INSR will maintain the request until a service is identified or it classifies the request as no service available. This is to ensure that the operation of identifying the service is created and performed to its full extent to allow future request to make use of the service.
An article comprising a computer readable storage medium having instructions thereon which when executed by a computing platform result in execution of a method for providing multiple enterprise services to an enterprise service agent (ESA) as mentioned above.
It is advantageous that the above described system can be deployed in various enterprises according to their needs such as: any manufacturing enterprises

which serve and monitor the inventory systems, PBX call routing, authentication/alert systems, finance/payments etc., defense transports can be equipped with simple authenticate version of the system so that the near by object gets authenticated by RFID tag, barcode or IMEI of the device used for communication; large/medium/small product sales vendors can deploy the system for purchase/sales and serve the customers orders 24/7; any parking stations can deploy the system which can facilitate parking places and e-ticketing more efficiently; any transport toll centers can deploy the system so that the transport can clear the toll from any distance; any corporate campus or institution can deploy the system to allow end-user credentials like vehicle, laptop, official belongings gets authenticated without involving security guards.
In addition, airport shopping malls can place purchase orders and get the products delivered in his flight without having to carry luggage during his transit with the system; any fast food delivery centers can deploy the system so that the user can place the order at one place and gets delivered at his home near centre; telecom service provider to offer pre-paid services can deploy the system, wherein they can sell small value added tariff plans (to pay for purchases) which might attract subscribers to buy it; the individual apartments can have simpler form of the system to facilitate locking and unlocking, automatic voice response/recording system whilst the members are away from the house; bank lockers room can be equipped with the system so that the customer uses the system to identify himself as correct individual to access the facility; any hotel or

restaurant service can deploy the system to make to order delivery fast and swift.
In general, it is clear that the present invention and its advantages are not limited to the above described embodiments only. With minor modifications, substitutions and equivalents will be apparent to those skilled in the art without departing from the spirit and scope of the present invention as described in the claims. Accordingly, the specification and figures are to be regarded as illustrative examples of the invention, rather than in restrictive sense.

Glossary of Terms and their definitions:
LAN Local Area Network
WAN Wireless Local Area Network
NFC Near Field Communication
ERS Enterprise Relationship Server
MERS Multiple Enterprise Relationship Server
ESA Enterprise Service Agent
ERAPI Enterprise Relationship Application Protocol Interface
WWW World Wide Web
OMA Open Mobile Alliance
OSI Open Systems Interconnections
SMSC Short Message Switching Centre
MMSC Multi-Media Switching Centre
MSC Mobile Switching Centre

1. A multiple enterprise relationship system (MERS) comprising:
an enterprise service agent (ESA) for sending at least one service request over a communication medium; and
an enterprise relationship server (ERS) interfaced with the ESA for authorizing service requests, identifying the service through intelligent decision making and routing the service request to relevant service provider, wherein the ERS comprises:
an ERS hook for receiving a service request from the ESA over the communication medium;
an intelligent network service router (INSR) for receiving the service request from the ERS hook as a narrow point communication or a broad way communication over an enterprise relationship application protocol interface (ERAPI), creating a service ID through intelligent decision making and creating a session identifier for the service request in the session database;
a business logic server (BLS) to manage sessions and credentials associated with the service request; and
an external application interface (EAI) to place the service request on a relevant service provider, wherein the INSR obtains response

associated with the service request from the relevant service provider, and the INSR communicates the response to the ESA through the ERS hook from the relevant service providers or with its own responsive system such as timeout and invalid request.
2. The system of claim 1, wherein the ERS hook further comprises:
one or more access points for receiving the service request from the ESA and identifying whether a service ID associated with the service request is registered in a session identification map (SIM) of the one or more access points;
if so, the ERS hook routes the service request to the INSR as a narrow point communication; and
else, the ERS hook routes the service request to the INSR as a broad way communication, wherein the INSR creates a service ID though intelligent decision making.
3. The system of claim 2, wherein the ERS hook further comprises an ERAPI
converter coupled to each of the access points for converting the service request
sent by the ESA in standard protocol format to ERAPI format, wherein the ERS
relies on the request adhering to the ERAPI format and converting back to
standard protocol format while responding to the ESA.

4. The system of claim 1, wherein the EAI further comprises an inverse ERAPI converter for converting the service request in ERAPI format to standard protocol format and converting back to ERAPI format while responding to the BLS.
5. A method for providing multiple enterprise services to an enterprise service agent (ESA) comprising:
receiving at least one service request from the ESA by an enterprise relationship server (ERS) hook of the ERS over a communication medium;
routing the service request to an intelligent network service router (INSR) as a narrow point communication or a broad way communication over an enterprise relationship application protocol interface (INSR);
creating a service ID by the INSR for the received request through broad way communication;
creating a session identifier by the INSR for the service request in the session database;
using a business logic server (BLS) to manage sessions and credentials associated with the service request;
placing the service request to a relevant service provider using an external application interface (EAI);

obtaining response associated with the service request from the relevant service provider by the INSR; and
communicating the response to the ESA by the INSR through the ERS hook from the relevant service providers or with its own responsive system such as timeout and invalid request.
6. The method of claim 5, wherein routing the service request to the INSR as
a narrow point communication or a broad way communication comprises:
identifying whether a service ID associated with the service request is registered in a session identification map (SIM) of an access point of the ERS hook;
if so, routing the service request to the INSR as a narrow point communication; and
else, routing the service request to the INSR as a broad way
communication.
7. The method of claim 6, wherein routing the service request as a broad way communication further comprises creating a service ID though an intelligent decision making by the INSR.
8. The method of claim 7, wherein the intelligent decision making further comprises:

cloning the service request with a number of services registered with a particular access point;
creating N requests by specifying the group ID and service ID;
forwarding the N requests to all the service providers and generating at least one true response by the INSR;
registering the service in the SIM of the access point and the INSR, upon reception of the at least one response; and
clearmg false requests.
9. The method of claim 5, further comprising converting the service
request sent by the ESA in standard protocol format to ERAPI protocol format
using an ERAPI converter associated with the access point.
10. The method of claim 5, wherein placing the service request on a relevant
service provider using the EAI comprises:
converting the service request in ERAPI protocol format to standard protocol format using an inverse ERAPI converter of the EAI; and
placing the converted service request on the relevant service provider using the external application interface.
11. The method of claim 5, wherein the communication medium comprises
wired and/or wireless communication medium, such as a LAN/WLAN, WWW,
NFC, Bluetooth, Wi-Fi, and Wi-Max.

12. An article comprising a computer readable storage medium having instructions tiiereon which when executed by a computing platform result in execution of a method for providing multiple enterprise services to an enterprise service agent (ESA), comprising:
receiving at least one service request from the ESA by an enterprise relationship server (ERS) hook of the ERS over a communication medium;
routing the service request to an intelligent network service router (INSR) as a narrow point communication or a broad way communication over an enterprise relationship application protocol interface (ERAPI);
creating a service ID by the INSR for the received request through broad way communication;
creating a session identifier by the INSR for the service request in the session database;
using a business logic server (BLS) to manage sessions and credentials associated with the service request;
placing the service request on a relevant service provider using an external application interface (EAI);
obtaining response associated with the service request from the relevant service provider by the INSR; and
communicating the response to the ESA by the INSR through the ERS hook.

13. A multiple enterprise relationship system (MERS) and the method thereof as herein described with reference to the accompanying drawings.