Third party access gateway for communication service

(Priority Claim) This application claims the benefits of EPO Patent Application No. 05425656.5 filed on September 20, 2006 and Italian Patent Application No. MI2005A001741 filed on September 20, 2006, both of which. The whole is incorporated herein by reference. (Technical Field) The present invention relates to a communication processing system architecture. In particular, the present invention relates to providing secure and controlled third party access to communication service provider functionality.

Rapid advances in data processing and communication technology have brought about a huge amount of communication services available to consumers. Such communication services include traditional telephone services, Internet services, cable television services, mobile phone services, paging services, voice and data combined delivery services, and many other services. In addition, many services can be either wireless or wireline based.

Traditional telecommunications service providers have invested enormous amounts of time, money, and advanced technology to implement and reliably deliver a broad spectrum of telecommunications products and services. So far, this investment has been a significant benefit only to telecommunications service providers. That is, the communication service provider internally possessed the provider-specific technology for the provider's own use.

Behind this advanced communications architecture is the need to explore and develop new business opportunities within each communications service provider that will lead to new revenue channels. Existing technologies in service provider architectures can facilitate such new revenue channels. However, until now, there has not been a sufficiently secure, flexible, and efficient mechanism that allows third parties to access the basic functionality of the service provider architecture.

<patcit num="1"><text>EPO Patent Application No. 05425656.5</text></patcit><patcit num="2"><text>Italian Patent Application No. MI2005A001741</text></patcit>

<p> There is a long-standing need for an enhanced communications service provider architecture.</p><p> Setting up an extended communications service provider architecture for third-party access poses significant technical challenges. For example, there are technical challenges in providing an architecture that allows secure and controlled access to internal functions. Another technical challenge is to provide a database data model architecture that efficiently and flexibly supports independent authorization criteria for multiple different types of service requesters. Service requesters can range from individual end users sending service requests to corporate applications.</p>

<p> One aspect of the invention is an access gateway for a communication architecture. The gateway provides an access point between the communication service provider and a third party sending a request to use the features implemented by the service provider. The gateway publishes available services, authenticates, authorizes, and processes third-party requests for those published services, and protects the communications service provider from unauthorized access.</p><p> The gateway implements several interfaces between the third party and basic communication service functions. The subscriber communication interface receives, for example, a third-party communication network access request (eg, an HTTP request for website content). The application interface receives third-party requests for publication services such as short message service (SMS), multimedia message service (MMS), billing service, and other publication services.</p><p> The third-party gateway contains a service request handler. The service request handler receives a communication network access request via the subscriber communication interface. The service request handler extracts a subscriber device identifier (eg, MSISDN associated with a subscriber device such as a mobile phone) from a communication network access request and searches the profiling database for a record of the subscriber device identifier. If an authorized record exists, the service request handler forwards the communication network access request to the communication network service provider through the service provider communication interface.</p><p> The gateway distinguishes communication network access requests from public service requests. To this end, the gateway provides a functional handler that receives public service requests from third parties via the application interface. The feature handler can then extract the secure certificate identifier from the published service request and search the profiling database to allow third-party applications associated with the certificate identifier.</p><p> After allowing a third-party application to use the public service, the feature handler maps the public service request to form the input message expected by the communication service provider. For example, a feature handler can wrap a public service request for delivery to a service broker in a communication architecture via a service broker communication interface. The feature handler can provide a wrapper for SMS requests, MMS requests, Session Initiation Protocol (SIP) requests, billing requests, or any other request for publishing services.</p><p> Another aspect of the invention is a profiling database and data model that supports particularly efficient configuration and authorization of multiple types of service requesters. The data model provides a root node (eg, a corporate table) that involves multiple types of service requesters. From the root node, the data model sets up independent branches for requesters of various types of services, such as network communication requesters and public service requesters.</p><p> Therefore, one company can set up a mobile phone that requests a network communication service (eg, Internet browsing service) and sets up a corporate application (eg, SMS front end) that presents a request for a published SMS service. Can be provided to. Various types of authorization data can be set along each branch and authorizations can be selectively adjusted according to the type of service requester. In addition, the data model sets state identifiers at multiple levels within each branch. Accordingly, the access gateway can flexibly set and apply authorization criteria not only to each type of service requester, but also to individual service requesters within each type.</p><p> Other systems, methods, features, and advantages of the present invention will be apparent or will become apparent to those skilled in the art upon examination of the figures and detailed description below. All such additional systems, methods, features, and advantages are contained herein, within the scope of the invention, and are protected by the appended claims.</p>

The present invention can be better understood with reference to the drawings and description below. The components in the figure are not necessarily on scale and the emphasis is on exemplifying the principles of the invention. Further in the figure, the same reference numerals indicate corresponding parts or elements throughout the various drawings.

The illustrated elements are used interchangeably as described in more detail below. However, before giving a detailed description, it should be noted that all of the following description, regardless of the particular implementation described, is not limited and is essentially exemplary. For example, the mode, feature, or component of the selected implementation is shown to be stored in memory, but all or part of a system and method that is compatible with the third party gateway and its underlying components. Is for other machine-readable media such as hard disks, floppy (registered trademark) disks, and secondary storage devices such as CD-ROMs, signals received from networks, or currently known or upcoming ROMs or RAMs. It can be stored, distributed, or read in other formats.

Further, although specific components of the third party access gateway architecture will be described, manufacturing methods, systems, and products conforming to the third party access gateway architecture may include additional or different components. For example, the processor can be implemented as a microprocessor, microcontroller, application specific integrated circuit (ASIC), individual logic, or a combination of other types of circuits or logic. Similarly, the memory can be of any other type of DRAM, SRAM, flash, or memory. Flags, data, databases, tables, and other data structures can be stored and managed separately, integrated into a single memory or database, distributed, or logically and physically in many different ways. Can be organized into. Programs can be distributed across parts of a single program, separate programs, or several memories and processors. The system can be implemented by hardware, software, or a combination of hardware and software in one processing system, or can be distributed to a plurality of processing systems.

Figure 1 shows a portion of the communication architecture 100 that interacts with a third party 102. Third party 102 may differ significantly in form and implementation. For example, third-party 102 can be used for subscriber devices such as mobile phones, mobile information terminals, network (eg, Internet) communication devices; short message services (SMS) messaging applications, session initiation protocol (SIP) systems, and products and services. It can include applications 106; and other devices, programs, or entities 108, such as communication service applications implemented by other service providers, such as billing applications that charge customers.

Communication architecture 100 implements features that support communication products and services. In addition, Communication Architecture 100 publishes selected features to third parties 102, as described in detail below. In other words, the third party 102 can communicate with the communication architecture 100 to use the features already deployed in the architecture 100. That is, the third party 102 does not have to consume the resources required to locally replicate the functionality already provided by the communication architecture 100.

Products and services, as well as these published basic features, may vary from implementation to implementation. For example, Communication Architecture 100 includes SMS messaging services (delivering and billing SMS messages), multimedia messaging system (MMS) messaging services (delivering and billing MMS messages), and SIP services (setting up and billing SIP calls). (Request for) can be published. Another example, Communication Architecture 100, is a Charge service (which requires a fee to be charged to an account), an Internet Protocol TV (IPTV) service (which requires delivery of a TV program), and a user state service (" Request current user status such as "online", "offline", "busy", or "away"), and user authentication services (eg, whether mobile users exist, and mobile users request IPTV services, etc.) You can publish (requires verification that you have the credential information to purchase the service). Other functions can be provided additionally or as an alternative. Further, the communication architecture 100 can provide access to a communication network service (eg, an Internet browsing service) via a third party access gateway 110.

Communication architecture 100 guarantees access to publicly available services. To that end, Architecture 100 provides a third party access gateway 110. The third party access gateway 110 serves as a single contact point for the third party 102 to the public service.

As shown in FIG. 1, the third party access gateway 110 receives the service request 112 from the third party 102. In response, the third party access gateway 110 verifies that the service request originates from an authenticated and authorized third party. For network communication service requests (as an example), the third party access gateway 110 processes the authorized service request and relays the service request to the service provider 114. For public service requests such as SMS, MMS, and SIP service requests, the third party access gateway 100 can process the authorized service request and relay it to the service broker 116.

Service broker 116 executes the service request. In doing so, Service Broker 116 may communicate with Business Support System (BSS) and Operation Support System (OSS) 118, which Architecture 100 implements to generate, deploy, manage, and maintain communications products and services. it can. In executing the service request, the service broker 116 may additionally or as an alternative to the network layer 120 capable of delivering or returning data related to the service to the service broker 116. The response from the service provider 114 and the service broker 116 is returned to the third party access gateway 110 for delivery to the calling third party requester.

As a result, the third party access gateway 110 provides a layer of security between the third party 102 and the publishing features implemented in the communication architecture 100. The Third Party Access Gateway 110 allows a third party to develop, deploy, distribute, and manage a wide range of products and services using features already implemented in another communication architecture. At the same time, the third-party access gateway 110 allows the communication architecture 10 to expose core functionality to a secure, standardized and controlled method for the third-party 102.

FIG. 2 shows a detailed view of the third party access gateway 110. The third party access gateway 110 communicates with the subscriber device 104, the service provider 114, and the requesting application 106. The third-party gateway 110 also communicates with the service broker 116. FIG. 2 shows service broker 116 accepting service requests for several public services: SMS service 202, MMS service 204, Charge service 206, SIP service 208, and user authentication service 210.

Optionally, the subscriber device 104, the service provider 114, and the requesting application 106 can communicate with the third party access gateway 110 via intermediaries. As an example, the intermediary means can include a web server such as web server 212 and web server 213. The intermediary can implement an encrypted or other secure communication link between the third party access gateway 110 and the subscriber device 104, service provider 114, and requesting application 106. For example, the intermediary (or the third-party gateway 110 itself) provides authentication and secure socket protocol (HTTPS) with SSL certificates and certificate identifiers that send the public key components of the public key cryptographic pair of private and public keys. Protocols, etc.) can be implemented. Web servers 212 and 213 and gateway 110 can then authorize the third party 102 using the client certificate and authorization information stored in the profiling database 228.

The third party access gateway 110 communicates through several interfaces. Interfaces include subscriber communication interface 216 and / or service broker communication interface 218. The interface also includes a service provider communication interface 220 and an application interface 222.

Interfaces 216-222 can be implemented in many ways. As an example, interface 216-222 should be a network socket defined by an IP address, port number, and communication protocol with a supporting physical layer (eg, one or more network interface cards). Can be done. Interfaces 216-222 use HTTP, Simple Object Access Protocol (SOAP), Java Database Connectivity (JDBC), or other communication protocols over the physical layer using interprocess communication, messaging, or signaling. Can communicate. The message can be encoded in any request format network packet (eg, TCP / IP packet), such as an extensible Marking Language (XML) message. In addition, firewalls can be configured to block requests from unknown hosts.

Third-party access gateway 110 includes two message handlers that handle service requests. The service request handler 224 receives and processes a communication network access request such as an Internet browsing request, a web server information request, or another network access request. The function handler 226 receives and processes a public service usage request such as an SMS service request or a Charge service request.

Passing Summarizing the processing of signals the network access request, the service request handler 224 receives the request, the subscriber device identifier (e.g., MSISDN identifier) to extract and further correspond to any given subscriber device Search profiling database 228 for possible validation information (eg, matching active MSISDN records). Once the validation information is identified, the service request handler 224 maps the request to the service provider 114 via the service provider communication interface 216. Service provider 114 responds to the requested data. As a result, the service request handler 224 returns data to the requester via the subscriber communication interface 216.

To summarize the processing of a public service request, functional handler 226 receives a request that optionally includes a digital certificate issued by a certification authority. Function handler 226 authenticates the requester based on the digital certificate. The function handler 226 can also extract a certificate identifier (eg, a public key or subject-unique identifier) and searches the profiling database 228 for requester applications that match the certificate identifier. The feature handler 226 may also determine if the matching requester application has an active state (or any other state indicating that the application is authorized to request the service) in one or more services. it can.

Authorized Requester When the application is authenticated and authorized for the requested service, feature handler 226 wraps the downstream processing request and forwards the wrapped request to the service broker 116. Service broker 116 supplies an acknowledgment to feature handler 226 and initiates the execution of the request for the published service of the authorized requester application. Thus, as an example, an authorized requester application can send an SMS or MMS message, bill for it, set up a SIP connection, present a Charge to a customer account, or in Architecture 100. You can use any of the other published services.

The service request handler 224 and the function handler 226 allow the service usage request. To this end, the service request handler 224 and the function handler 226 refer to the profiling database 228. The profiling database 228 retains authorization information about the service requester, as described in more detail below. The access control module 230 can connect the profiling database 228 and the service request handler 224 to the functional handler 226 (or any other program or entity of the third party access gateway 110). As an example, the access control module 230 can implement a database server 232 including a database search engine. To this end, the access control module 230 and profiling database 228 can be built on Oracle , Microsoft SQL, or other third-party database server platforms.

The third party access gateway 110 further includes a reporting module 234. The reporting module 234 acquires the service request processing record from the service request handler 224 and the function handler 226. The reporting module 234 obtains the service log file 236 (eg, via an FTP connection with the system running the service request handler 224 and / or the function handler 226) and said the log file as described in more detail below. Process 236 to update the log table in profiling database 228.

Figure 3 shows the additional details of the service request handler 224. The service request handler 224 can be implemented in a general-purpose processing architecture that includes a processor 302 and a memory 304. The memory 304 stores programs and data that provide a service request handler function as described below.

The processor 302 can be dedicated to the service request handler function. For example, the service request handler 224 can be an independent processing system within the overall architecture of the third party gateway 110. In other implementations, the processor can be shared across additional programs and thus perform additional functions on the third party gateway 110. For example, processor 302 can also execute the function of function handler 226 and / or start sending and receiving messages via interface 216-222.

Memory 304 includes network access request processing program 306. The processing program 306 processes, for example, the communication network access request 308 received via the subscriber communication interface 216. FIG. 3 shows an example in which the communication network access request 308 is a hypertext transfer protocol (HTTP) request 310 that includes a unified resource location specifier (URL) 312 and MSISDN314.

Processing program 306 allows network access request 308. In one implementation, process program 306 extracts MSISDN314 from request 308. The processing program 306 sends a request to the access control module 230 and searches the profiling database 228 based on MSISDN. The access control module 230 returns the search results to processing program 306, which then determines if an authorized record exists for MSISDN.

For network access requests from authorized subscriber devices, service request handler 224 determines the destination web server to handle the request. To this end, the network access request processor 306 can configure and apply the web server mapping 316. The web server mapping 316 identifies the available web server (eg, identified by name, IP address, and / or port number) as a unified resource location specifier (URL) or other data for MSISDN and / or HTTP requests. Can be associated with some. The service request handler 224 thereby determines which service provider 114 handles the network access request 308.

The selected service provider 114 responds to access request 308 with the requested data. FIG. 3 shows an example in which service provider 114 responds to HTTP request 308 with HTTP response data 318. Response data 318 may include HTML, image, audio, and / or video data, or any other data that responds to HTTP request 308. The service request handler 224 returns the HTTP response data 318 to the authorized requester.

Service request handler 224 can also create log file 320. The log file 320 may include any requested service tracking information for each service request. The information logged can include authorized subscriber information, MSISDN, service request date and time, URL data, amount of data transferred, response service provider identifier, error code, transaction identifier, and other information. .. The service request handler 224 can provide the log file 320 to the reporting module 234 to parse and read the log table of the profiling database 228.

Figure 4 shows the additional details of the feature handler 226. Function handler 226 can be implemented in a general purpose processing architecture that includes processor 402 and memory 404. The memory 404 stores programs and data that provide the functionality of the function handler as described below. The web server 436 (eg Apache Axis web server) can provide a secure communication channel over third party authentication based on client certificates and SSL.

The feature handler 226 can be an independent processing system within the overall architecture of the third party gateway 110. In other implementations, processor 402 can be shared across additional programs to perform additional functions at the third party gateway 110. For example, processor 402 can also perform the function of service request handler 224 and / or start sending and receiving messages via interface 216-222.

The memory 404 includes a public service request processing program 406. The processing program 406 processes the publishing service request 408 received, for example, via the application interface 222. The service request 408 shown in FIG. 4 includes a certificate identifier 410 (eg, a public key or subject unique identifier) that can be present in the digital certificate included with the service request 408. The processing program 406 can authenticate the publication service requirement 408 by first decrypting the digital certificate and verifying the issuance of the certificate by the certification authority. The processing program 406 can then use the verified public key to authenticate the service request 408 (eg, by comparing the decrypted message hash value with the calculated message hash value). Alternatively, the feature handler 226 can utilize the web server 426 for authentication.

In one implementation, processing program 406 extracts certificate identifier 410 from request 408. The processing program 406 sends a request to the access control module 230 and searches the profiling database 228 based on the certificate identifier 410. The access control module 230 returns the search result to the processing program 406. As a result, processing program 406 has an authorized enterprise application that corresponds to certificate identifier 410 and is linked to an active (or otherwise authorized) installation service that corresponds to the requested service. Determine if.

For public service requests from authenticated and authorized applications, feature handler 226 determines which public service was requested. The service type can be specified in service request 408, or service requests can be distinguished based on specific endpoints within the third-party gateway 110 being sent. Each service request 408 may differ in format and content depending on the type of published service requested.

The third-party gateway 110 can define and publish a Web Services Description Language (WSDL) descriptor for the published service to the third-party 102. The WSDL descriptor can specify the location of the service (eg, the network address of the endpoint configured on the third party access gateway 110) and the features that the service publishes. The WSDL descriptor can also define each publishing service, the operations it can perform, and the messages it contains. Therefore, the third party 102 receives the published descriptor and understands where the service request is communicated, the format and content to which the service request should comply, and the format and content of the expected response.

The function handler 226 provides a public service interface 412 that acts as an intermediary between the service broker 116 and the requesting application 106. The public service interface 412 expects the received service request message 408 from the format expected by the third-party gateway 110 (eg, the format of the input message specified in the WSDL descriptor) by the service broker 116 for such a request. Can be converted to a format. In other words, the wrapper is the mapping added by the WSDL definition to form the input message for the publishing service. Thus, the published service interface 412 separates the service broker 116 from the potentially different formats and content of the published service request message and efficiently connects the requesting application to the published service.

To this end, the public service interface 412 can include wrapper logic that prepares standardized (ie, wrapped) public service request 424 for service broker 116. The wrapper logic can represent a processing program that parses the WSDL and transforms the format and content of the received message into conforming to the message definition specified in the WSDL definition. An example of the message format expected by the service broker 116 is described below.

Wrapper logic can be provided for any of the publishing services. FIG. 4 shows an SMS wrapper 414, an MMS wrapper 416, and a state query wrapper 418. FIG. 4 also shows the mobile user authentication wrapper 420, the user authentication wrapper 422, the SIP wrapper 432, and the Charge wrapper 434.

In one implementation, the public service interface 412 can utilize Java remote method invocation (RMI). RMI provides a mechanism by which Java objects can be defined, and these methods called remotely. To this end, the service broker 116 can act as an object server that creates objects that handle public service requests. The object can be registered so that the function handler 226 can get a reference to the object and call the object remotely. However, the third-party gateway 110 can send and receive service request messages and responses wrapped by other message communication and remote procedure call techniques to and from the service broker 116.

The function handler 226 gets the service request response 426 to the published service request from the service broker 116. The function handler 226 provides the request response 426 to the request application. In addition, functional handler 226 can provide a standard response format for each published service request response. To this end, the wrapper shown in Figure 4 can generate a published service request response 428 wrapped according to the output message defined in the WSDL definition.

Function handler 226 can also create log file 430. Log file 430 is one of the required subscriber information, certificate identifier, service request date and time, number of requested requests, type of requested requested, error code, transaction identifier, and other information. Published service tracking information can be included. The function handler 226 can supply the log file 430 to the reporting module 234 for parsing and reading the log table of the profiling database 228.

Figure 5 shows an exemplary implementation of the data model for profiling database 228. The profiling database 228 includes a company table 502 that stores information that characterizes a company that has access to one or more public services provided by Architecture 100. The company identifier field 504 provides a primary key for uniquely identifying each record in the company table 502. The enterprise table 502 is shown in detail in Table 1 below.<img file="JP2007089200A_D0001.tif" />

End-user table 506 stores information about MSISDN (generally related to a particular individual) using network communication and publishing services. The end user table 506 sets the relationship between the end user, its enterprise, and its MSISDN. The primary key end-user identifier field 508 uniquely identifies each record in the end-user table 506. The end-user table 506 is detailed in Table 2 below.<img file="JP2007089200A_D0002.tif" />

MSISDN table 510 provides a device identifier table that sets the MSISDN identified in MSISDN field 512. MSISDN can be associated with subscriber devices such as GSM SIM cards for mobile phones. The end user table 506 can then associate the end user with the MSISDN using the MSISDN identifier field. The status field in MSISDN table 510 provides the subscriber device status. The primary key is provided in the MSISDN identifier field 514, which uniquely identifies each record in MSISDN table 510. The MSISDN table 510 is detailed in Table 3 below.<img file="JP2007089200A_D0003.tif" />

The state table 520 sets the possible states for the end user, enterprise, MSISDN, or other entity. The primary key state identifier field 522 uniquely identifies each record in state table 520. The status table 520 is shown in detail in Table 4 below.

Examples of states include active, inactive, suspended, and idle. Therefore, the third-party gateway 110 can set its state to one of many different levels. For example, the state can reflect the state of a company, corporate application, user, or a particular MSISDN. When granting a service request, the third-party gateway 110 can check that the state is at one of the request levels before granting the request. For example, the third party gateway 110 can ensure that both MSISDN and the end user remain active. Alternatively or additionally, the gateway 110 can ensure that the associated entity also remains active.<img file="JP2007089200A_D0004.tif" />

The end-user cross-application table 516 sets the relationship between the end user and the business application to which the end user subscribes. The end user identifier and application identifier fields provide a primary key / foreign key field 518 that links the end user to the enterprise application. The end-user cross-application table 516 is detailed in Table 5 below.<img file="JP2007089200A_D0005.tif" />

The enterprise application table 524 sets the characteristics of the application within the enterprise that can present the published service request. Features can include names, descriptions, URLs, certificate identifiers stored in certificate identifier field 526, and other features. As an example, the enterprise application table can specify, for example, the characteristics of an SMS front and application running on a third-party service provider. The SMS front end can present an SMS request to a third party gateway 110 on behalf of a customer of a company associated with the SMS front end.

The primary key application identifier field 528 uniquely identifies each record in the enterprise application table 524. Further, the state identifier provides state information of each company application record. The enterprise application table 524 is detailed in Table 6 below.<img file="JP2007089200A_D0006.tif" />

The installed service table 530 sets a record of public services subscribed to by the enterprise. Therefore, the installed services identify which public services the enterprise application can request. The installed service identifier field 532 acts as the primary key and uniquely identifies each record in the installed service table 530. The installed service table 530 is detailed in Table 7 below.<img file="JP2007089200A_D0007.tif" />

The installed attribute table 534 sets the characteristics of the service associated with a particular company. The installed attribute identifier field 536 acts as the primary key and uniquely identifies each record in the installed attribute table 534. Table 8 below details the installed attribute table 534.<img file="JP2007089200A_D0008.tif" />

Service attribute table 538 stores names, descriptions, and default values for public service attributes available through the third-party access gateway 110. Examples of service attributes include recurring charges: the monthly cost of using the service (eg, the monthly cost of accessing the send SMS or send MMS public services) threshold: the SMS that can be sent each month or Amount of MMS messages Additional quota: Includes cost per SMS or MMS message when the threshold is crossed.

Default values can be exported to the installed attribute table. The values in the installed attribute table can then be modified appropriately for a particular enterprise application.

The attribute identifier field 540 serves as the primary key and uniquely identifies each record in the service attribute table 538. Table 9 below details the service attribute table 534.<img file="JP2007089200A_D0009.tif" />

The service catalog table 542 stores names, descriptions, states, and other information associated with public services available through the third party access gateway 110. Each business application 114 or service provider 106 may subscribe to one or more services defined in service catalog table 542. The service catalog table 542 can be set up with records that provide names, descriptions, identifiers, and states for published SMS, MMS, Charge, or other types of published services. The service identifier field 544 serves as the primary key and uniquely identifies each record in service catalog table 542. Table 10 below shows the service catalog table 542.<img file="JP2007089200A_D0010.tif" />

As an example, the profiling database 228 can define published SMS services. For this, the service catalog can set a new record with the Service_Name set in "Send SMS". The service attribute table can then be set to a "Threshold" Attribute_Name with a "100" Attribute_Default_Value (ie 100 SMS messages per month). Attribute_Description can optionally be set to a single text string that describes the threshold. The service attribute table can also define recurring rate attributes with an Attribute_Default_Value of $ 1,000 (ie, access up to a published service cost of $ 1,000 per month). The associated Attribute_Description can provide a text string that describes the recurring charges.

Third-party companies can negotiate with telecommunications service providers to access published SMS messaging services. Access deadlines and conditions will be negotiated and supported by the data model of profiling database 228. The profiling database 228 sets the company record of the company and sets the company application record linked to the company. The installed service table can then set the installed service record for enterprise applications that specify the "Send SMS" service defined in the service catalog. The default values provided in the service attribute table can be specifically set for the company in the installed attribute table. For example, the installed attribute table can define a threshold of 10,000 SMS messages per month and a recurring charge of $ 5,000 per month.

The combination of enterprise applications and installed services sets up a client portfolio for enterprise applications. The enterprise application presents the service request that the third party gateway 110 allows for the client portfolio. The data model set up in Portfolio Database 228 supports flexible definition, modification, and deletion of client portfolios.

Figure 5 shows a profiling database 228 that implements a data model that specifically supports the efficient configuration and authorization of various types of service requests. The enterprise table 502 acts as a route table that back-associates multiple types of service requesters with the associated enterprise. From company table 502, the data model sets up independent branches for network communication requesters and public service requesters. Each type of requester is associated with a company. For example, one company can include both employees requesting a network communication service (eg, Internet browsing service), while at the same time the company presents a request for a published SMS service (eg, SMS front). End) can be set.

The data model allows the third party gateway 110 to allow each type of requester based on various criteria. Therefore, the criteria can be independently selected and adjusted for the requester type. At the same time, the data model blanching structure allows each type of requester to coexist in the same data model, establish relationships for a single enterprise, and support unique authorization controls for each type of requester. it can.

The company table defines one or more companies that can access the third-party gateway 110 using the unique company identifier in company table 502 (Table 2). The end-user branch 554 is configured by providing a return relationship to a particular company using the unique end-user identifier 508 and company identifier fields in the end-user table 506. Similarly, the enterprise application branch 556 is configured by providing a unique application identifier 528 that sets the enterprise application by a return relationship to a particular enterprise using the enterprise identifier field. Therefore, the end user and the requesting application are linked back to the enterprise which can include both types of requesters.

In addition, each branch of the data model provides a mechanism for setting different authorization criteria for each type of requester. In the end-user branch, for example, MSISDN provides data fields that allow network communication access requests (eg, for mobile phone users or PDA users browsing the Internet). Therefore, the end-user branch sets up MSISDN table 510, which associates end-users with MSISDN by means of the MSISDN identifier field in end-user table 506 (Table 2).

The data model also provides multiple authorization options for the end user. To this end, the data model sets up a state table 520 that defines the states (eg, active, inactive, suspended, or idle). The third-party gateway 110 can determine from that state whether the request should be granted. Each end user defined in end-user table 506 and each MSISDN defined in MSISDN table 510 can specify a state.

For example, service request handler 224 can manage authorization policies by considering end-user network communication requests that are allowed when a service request involves an MSISDN configured in MSISDN table 510. Depending on the policy, the service request handler 224 can also check and ensure that MSISDN has an authorized state (eg, active). Further or alternately, depending on the policy, the service request handler 224 can be checked to ensure that the end user linked to MSISDN has the allowed state. The data model thereby provides an efficient and flexible mechanism for setting end-user authorization controls. Furthermore, authorization control for end users is independent of authorization control for enterprise applications.

The application branch of the data model sets up different authorization mechanisms for enterprise applications. In particular, the application branch sets permissions based on the certificate identifier. To this end, each enterprise application defined in application table 524 includes certificate identifier field 526. The certificate identifier field 526 is a pre-assigned identifier (eg, public key) that can be checked against an identifier (eg, a public key or subject-unique identifier) obtained from the digital certificate through digital certificate authentication. ) Is memorized.

The certificate identifier is obtained during authentication. Including the certificate identifier in the enterprise application record of database 228 efficiently extends the use of the certificate identifier to permission without the need for an additional authorization identifier. Therefore, feature handler 228 not only supports extremely secure authentication techniques, but also uses the results obtained from authentication for efficient and secure authorization of enterprise applications. Strengthening the permissions of enterprise applications provides strong protection against unauthorized access to useful communications services by third parties.

In addition, the data model provides a flexible service definition and attribute definition structure. In particular, the data model can associate one or more installed services with each enterprise application using the application identifiers in installed service table 530 (Table 7). In this way, the publishing service that the enterprise application is allowed to request is set up and linked to the enterprise application. The service catalog table 542 can then use the service description fields to provide a detailed description for each installed service.

Similarly, the installed attribute table 534 can define specific attributes for installed services via the links provided by the installed service identifier fields (Table 8). The service attribute table 538 can then use the attribute description fields to provide a detailed description for each attribute. Default values for installed attributes can be provided from service attribute table 538.

Each of the enterprise application branch tables 524, 530, 534, 538, and 542 can include a state identifier field. The data model thereby provides a significant amount of additional policy management flexibility when setting up an enterprise application if it is authorized to use any given publishing service. For example, after authentication and recovery of the certificate identifier, feature handler 228 allows the enterprise application to use the requested service if an active enterprise application that matches the certificate identifier is found in enterprise application table 524. You can set an authorization policy to determine that. In addition, the policy may require that the enterprise application be linked to an active installed service that matches the requested public service. In addition, depending on the authorization policy, feature handler 228 may require that installed services be linked to active installed attributes, service attributes, or service catalog entries. Depending on the policy implemented, the data model may flexibly allow or deny access to public services by modifying state fields in one or more of tables 524, 530, 534, 538, and 542. Can be done.

The data model therefore supports flexible policy management based on state fields and authorization identifiers (eg, MSISDN identifiers and certificate identifiers) that are examined when authorizing end users, enterprise applications, or other service requesters. A policy is one of the data models at one or more levels within each branch of the data model (eg, enterprise level, end user level, MSISDN level, or enterprise application level) before the request is considered granted. Status criteria can be specified for or more records. Policies may vary for each enterprise application and end user.

As mentioned above, the reporting module 234 can parse the log file 236 and responsively load the log table into the profiling database 228. The first log table 546 can store information logged (eg, daily) for a communication network access request (eg, HTTP request). The object identifier field 538 provides a unique identifier for each row in log table 546. Table 11 shows an exemplary implementation of the first log table 546.<img file="JP2007089200A_D0011.tif" />

The second log table 550 can store (eg, daily) logged information for public service requests (eg, SMS billing requests). The object identifier field 552 provides a unique identifier for each row in log table 550. Table 12 shows an exemplary implementation of the second log table 546.<img file="JP2007089200A_D0012.tif" />

FIG. 6 shows a message flow diagram 600 for handling a communication network access request. In summary, service request handler 224 receives an access request, grants permission to the requester, and forwards the request to the web server. The web server returns the access request result to the service request handler 224, which then returns the result to the requesting party.

FIG. 6 shows that a service party (eg, an end user or subscriber device) sends an HTTP service request that can contain MSISDN, a service party identifier, a URL, or other network access information (operation 602). ing. Service request handler 224 extracts MSISDN from the HTTP request (action 604). Service request handler 224 initiates a database search based on MSISDN. If MSISDN is found and active, the request is granted.

The service request handler 224 can also search the profiling database 228 to determine if a service party record exists (action 606). Profiling database 228 returns search results (behavior 608). If the service party does not currently exist (behavior 610), service request handler 224 adds the service party to the profiling database 228 and associates it with the active MSISDN (behavior 612).

The service request handler 224 can also determine that a service party exists and that the extracted MSISDN is the new MSISDN of the service party (action 614). In this case, service request handler 224 can interactively update the state of the old MSISDN of the service party (behavior 616). In addition, service request handler 224 updates the MSISDN of the service party in profiling database 228 to reflect the new MSISDN (behavior 618). The service request handler 224 thereby maintains exactly which service party is associated with which MSISDN.

In addition, the service request handler 224 sends the request to the web server that responds with the requested data. To this end, the service request handler 224 can route the request to the web server based on MSISDN. For example, service request handler 224 can implement a lookup table that sets the correlation between MSISDN and the web server assigned to handle the request.

To this end, in one implementation, the service request handler 224 creates a new URL based on the request URL and the assigned web server (behavior 620). In other words, the new URL specifies a request for content at the original URL from a server mapped to MSISDN. The service request handler 224 forwards the HTTP request to the selected web server (operation 622) and receives the response data (operation 624). The response data is propagated to the outgoing service party (operation 626).

Figures 7 and 8 show message flows diagrams 700 and 800 for handling published service requests. In summary, the feature handler 226 receives the service request, authenticates the requester, and further verifies that the requester has been granted access to the public service. Published service requests from authenticated and authorized requesters are wrapped and delivered to service broker 116.

As shown in Figure 7, function handler 226 receives an MMS / SMS service request from an external enterprise application 106 (behavior 702). Service requests can also be received from service provider 114. Function handler 226 extracts the certificate identifier from the request (action 704). The function handler 226 searches the profiling database 228 for the matching certificate identifier in the enterprise application table 524 (behavior 706), and the profiling database 228 returns the search result (behavior 708). The matching certificate identifier can authorize the requesting enterprise application, or can be a check performed to grant authorization to the enterprise application (operation 710). Additional checks, such as checking the status of enterprise applications and / or related enterprises, can be performed before the authorization is complete.

Function handler 226 adds a mapping to the service request (behavior 712). Function handler 226 then sends an RMI request to service broker 116 (behavior 714). Service broker 116 returns the request response to the RMI request (action 716). The response can be an acknowledgment that the service broker 116 has received the request. Function handler 226 returns the request response to application 116 (behavior 718).

As shown in FIG. 8, the function handler 226 receives a Charge, SIP, or User Authorization request from the service provider 114 (operation 802) and extracts the certificate identifier (operation 804). Enterprise applications can also present such service requests. The function handler 226 searches the profiling database 228 for the matching certificate identifier in application table 524 (action 806), and the profiling database 228 returns the search result (action 808). Function handler 226 determines whether the authenticated application is allowed (behavior 810).

More specifically, the matching certificate identifier can provide a first step in permitting an application or a corporate application. The feature handler 226 can also search the profiling database 228 for services related to the requesting enterprise application. If an active service is found in connection with the requesting application in profiling database 228, feature handler 226 can grant the service request. Function handler 226 can implement other authorization policies based on the state of the requesting enterprise application, affiliated enterprise, or other record of profiling database 228.

In an authenticated application that presents an authorized service request, feature handler 226 wraps the service request for presentation. The function handler 226 can then make a remote method call and send the request to the service broker 116. The function handler 226 thereby sends the wrapped request via the RMI to the service broker 116 (behavior 814). Function handler 226 receives a response from service broker 116 (behavior 816). The response can be an acknowledgment, error message, or other response provided by service broker 116. The function handler returns the request response to application 106 (behavior 818).

Figure 9 shows an example of service request 900 for published SMS services. An application can present an SMS service request to Architecture 100, which can send an SMS message requesting that the application be billed for the SMS message. Service request 900 conforms to the transaction identifier field 902, which can provide a unique identifier for the service request, the message type field 904, which can specify that the request is an SMS request, and which version of SMS the request conforms to. Includes SMS version field 906 to specify. Service request 900 also includes addressing information such as To Address field 910, CC Address field 912, and BCC Address field 914. The service code field 916 provides the identifier of the service provider that presents the SMS service request.

Delivery timing information is also present in service request 900. In particular, request 900 includes a request time field 918, a valid time field 920, and a shortest delivery time field 922. Request 900 also specifies the message priority using priority field 924, the subject of the message in subject field 926, and the party to charge for the delivery of the message in billing party field 928. The content of the SMS message resides in content field 930.

As mentioned above, the public service interface 412 can wrap the request in the standard form of service broker 116. FIG. 10 shows an example of a wrapped SMS message 1000. The SMS wrapper 414 maps the transaction identifier field 902 to the transaction identifier field 1002 and adds a transaction label field 1004 that allows you to specify the message type (for example, "SMS DELIVERY" for SMS messages), plus the SMS version. Map message type field 904 to service type field 1006 while dropping field 906. Similarly, the SMS wrapper 414 maps addressing fields 910-914 to To Address field 1010, CC Address field 1012, and BCC Address field 1014, and further maps service code field 916 to service identifier field 1016.

Delivery timing information is also present in the wrapped request 1000. In particular, the SMS wrapper 414 maps the request time field 918 to the start date field 1018, the effective time field 920 to the end date field 1020, and drops the shortest delivery time field 922. The SMS wrapper 414 also maps priority field 924 to priority field 1022, subject field 926 to subject field 1024, and billing party field 928 to account identifier field 1026. The content of the SMS message is mapped from content field 930 to message body field 1028.

Table 13 shows an exemplary implementation of a wrapped XML SMS request message with the field values obtained from the request message shown in Figure 9. Wrapped messages add a label field (set to "SMS DELIVERY" in SMS messages).

<img file="JP2007089200A_D0013.tif" />

FIG. 11 shows an example of published service response 1100 returned by service broker 116. Response 1100 provides an acknowledgment of the request and includes transaction identifier field 1102, transaction label field 1104, and request status field 1106. Response 1100 also provides error code field 1108 and error description field 1110 that convey the error condition to the requesting application. Table 14 shows an example of an XML message that conveys the data fields shown in Figure 11.

<img file="JP2007089200A_D0014.tif" />

The feature handler 226 can also wrap the service broker response for delivery to the requesting application. In other words, the format and content of the response message returned to the requesting application may differ from the format and content of the response message sent by the service broker 116. FIG. 12 shows an example of a wrapped SMS response 1200.

The SMS wrapper 414 maps the information from response 1100 to wrapped response 1200, which includes transaction identifier field 1202, status field 1204, error code field 1206, and error description field 1208. The wrapped response 1200 also reports the message type field 1210 (eg, set to "&lt;SMS&gt;" or another value expected by the requesting application), and the applicable SMS version to the requesting application 1221. To add. Transaction label field 1104 can be dropped.

Figure 13 shows the mapping from MMS published service request 1302 to wrapped MMS service request 1304. TSOLABEL can be set to "MMS Delivery" or any other identifier. The application can send an MMS service request to deliver multimedia content to any designated recipient. Figure 14 shows the mapping from MMS published service response 1402 to wrapped MMS service response 1404.

Figure 15 shows the mapping from SIP published service request 1502 to wrapped SIP service request 1504. TSOLABEL can be set to "SIPCall" or any other identifier. The requesting application can initiate a SIP request to set up a communication channel between the sender and receiver specified in SIP request 1502. Figure 16 shows the mapping from SIP published service response 1602 to wrapped SIP service response 1604. The TSOLABEL field can be dropped.

FIG. 17 shows the mapping from state published service request 1702 to wrapped state service request 1704. TSOLABEL can be set to "GetUserStatus" or any other identifier. The requesting application can send a state request to check the state of one or more of the users listed in state request 1702. State request 1702 can further include a provider identifier to request a state for a particular service provider. Figure 18 shows the mapping from state response 1802 to wrapped state service response 1804.

Figure 19 shows the mapping from certification published service request 1902 to wrapped certification service request 1904. TSOLABEL can be set to "authentication" or any other identifier. The requesting application can send out authentication request 1902 to request MSISDN authentication for a particular service and provider. FIG. 20 shows the mapping from state published service response 2002 to wrapped state service response 2004. Responses include service status (eg, "OK" or "disconnected"), customer type (eg, "commercial" or "residential"), customer service plan identification, SIM module, wireless device type, MMS or UMTS. Alternatively, it can include a wide range of state information, such as the ability to send and receive GPRS messages, access channels (eg, "mobile" or "landline"), or any other state information available to MSISDN.

Figure 21 shows the mapping from Charge published service request 2102 to wrapped billing service request 2104. TSOLABEL can be set to "Charge" or any other identifier. The requesting application requests billing for communication sessions between the two endpoints (eg, between the sending and receiving URIs) on the specified start and end dates and is handled by the service provider specified in billing request 2102. You can initiate a billing request. FIG. 22 shows the mapping from the billing public service response 2202 to the wrapped billing service response 2204. The TSOLABEL field can be dropped in the response.

Table 15 shows examples of WSDL definitions for published services. In particular, Table 15 shows exemplary WSDL billing service descriptors that can define input and output messages and message formats for published services. The billing service descriptor defines the &lt;port&gt; ("ChargeAdapterFrontEnd") in which billing service requests and responses are sent as defined by input and output messages. In addition, the billing service descriptor defines the message format and content for input and output messages (submitReqRequest and submitReqResponse, respectively). SOAP joins are also defined as the location where the billing publication service request is sent (via the "location" specifier).

The WSDL definition can be set for each public service in a similar manner. The WSDL definition can vary significantly depending on the gateway 110 and the implementation of the public service.

<img file="JP2007089200A_D0015.tif" /><img file="JP2007089200A_D0016.tif" /><img file="JP2007089200A_D0017.tif" />

The third party gateway 110 provides secure and efficient access to the public services provided by the communications service provider. The third-party gateway 110 enhances third-party authorization by using the certificate identifier obtained during secure authentication. By including the certificate identifier in the enterprise application record of database 228, the use of the certificate identifier can be efficiently extended to authorization without the need for a separate or independent authorization identifier for the enterprise application. Enhanced permissions for enterprise applications provide strong protection against unauthorized third-party access to critical communications.

In addition, the MSISDN and certificate identifier fields are independent authorization criteria for various types of service requesters. Along with multiple level state fields in the data model, the data model supports flexible policy management for service request handler 224. The policy is a state criterion for recording the data model at one or more levels within each branch of the data model (eg, enterprise level, end user level, or enterprise application level) before the request is considered granted. Can be specified.

To summarize the techniques for securely granting multiple different types of access for a service requester, the third party gateway 110 receives published service requests from the first type of service requester (eg, an enterprise application). The third-party gateway 110 also receives network communication service requests from a second type of service requester (eg, a mobile phone device). The third-party gateway authenticates the public service request and obtains a secure authorization identifier (eg, public key) by authenticating the public service request.

The profiling database 228 provides search results from the service requester branch of the data model defined in the profiling database 228 based on a secure authorization identifier. The third-party gateway 110 determines the enterprise application displayed in the search results. Authorization of the enterprise application proceeds based on one or more state identifiers of the first search result (eg, enterprise application identifier).

For the second type of service requester, the third party gateway 110 extracts the device identifier from the network communication service request. The profiling database 228 also provides search results from different service requester branches based on the device identifier. The subscriber device shown in the second search result is determined and permitted based on one or more subscriber device status identifiers in the second search result.

Although various embodiments of the present invention have been described, it will be apparent to those skilled in the art that more embodiments and implementations are possible within the scope of the present invention. Therefore, the present invention is not limited except in terms of the appended claims and their equivalents.

<figref num="1">It is a figure which shows a part of the communication architecture including the third party access gateway.</figref><figref num="2">FIG. 5 shows a service broker and a third party access gateway in communication with an external device, application, and service provider.</figref><figref num="3">It is a figure which shows the service request handler which is in a communication state with an access management module.</figref><figref num="4">It is a figure which shows the function handler which is in a communication state with an access management module.</figref><figref num="5">It is a figure which shows the profiling database.</figref><figref num="6">It is a message flow diagram of a communication network access request.</figref><figref num="7">It is a message flow diagram for SMS and MMS publication service request.</figref><figref num="8">It is a message flow diagram of a charge (Charge), a SIP, and an authorized service request.</figref><figref num="9">It is a figure which shows the SMS publication service request.</figref><figref num="10">It is a figure which shows the wrapped SMS service request.</figref><figref num="11">It is a figure which shows the SMS service request response.</figref><figref num="12">It is a figure which shows the wrapped SMS service request response.</figref><figref num="13">It is a figure which shows the mapping from the MMS public service request to the wrapped MMS service request.</figref><figref num="14">It is a figure which shows the mapping from the MMS public service response to the wrapped MMS service response.</figref><figref num="15">It is a figure which shows the mapping from the SIP publication service request to the wrapped SIP service request.</figref><figref num="16">It is a figure which shows the mapping from the SIP published service response to the wrapped SIP service response.</figref><figref num="17">It is a figure which shows the mapping from the state publication service request to the wrapped state service request.</figref><figref num="18">It is a figure which shows the mapping from the state response to the wrapped state service response.</figref><figref num="19">It is a figure which shows the mapping from the authentication publication service request to the wrapped authentication service request.</figref><figref num="20">It is a figure which shows the mapping from the authentication publication service response to the wrapped authentication service response.</figref><figref num="21">It is a figure which shows the mapping from the billing publication service request to the wrapped authentication service request.</figref><figref num="22">It is a figure which shows the mapping from the billing publication service response to the wrapped authentication service response.</figref>

Code description

100 Communication Architecture 102 Third Party 104 Subscriber Devices 106 Applications 108 Others 110 Third Party Access Gateway 112 Service Requests 114 Service Providers 116 Service Brokers 118 Business Support Systems (BSS) and Operations Support Systems (OSS) 120 Network Layer