EP1949281A1 - Systeme et procede assurant un support d'affaires mobile - Google Patents

Systeme et procede assurant un support d'affaires mobile

Info

Publication number
EP1949281A1
EP1949281A1 EP06812363A EP06812363A EP1949281A1 EP 1949281 A1 EP1949281 A1 EP 1949281A1 EP 06812363 A EP06812363 A EP 06812363A EP 06812363 A EP06812363 A EP 06812363A EP 1949281 A1 EP1949281 A1 EP 1949281A1
Authority
EP
European Patent Office
Prior art keywords
message
processing unit
biz
billing
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP06812363A
Other languages
German (de)
English (en)
Other versions
EP1949281A4 (fr
Inventor
Byoung-Cheol Choi
Jae-Sung Kim
Seog-Cheon Jeon
Min Kim
Yoo-Hoon Won
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
KTFreetel Co Ltd
Original Assignee
KTFreetel Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020050105076A external-priority patent/KR100706347B1/ko
Priority claimed from KR1020050107245A external-priority patent/KR100666708B1/ko
Priority claimed from KR1020050107248A external-priority patent/KR100666710B1/ko
Priority claimed from KR1020050107243A external-priority patent/KR100650702B1/ko
Priority claimed from KR1020050107242A external-priority patent/KR100650701B1/ko
Priority claimed from KR1020050107247A external-priority patent/KR100666709B1/ko
Priority claimed from KR1020050107184A external-priority patent/KR100727088B1/ko
Priority claimed from KR1020050107244A external-priority patent/KR100666707B1/ko
Priority claimed from KR1020050107249A external-priority patent/KR100666711B1/ko
Priority claimed from KR1020050107246A external-priority patent/KR100738041B1/ko
Priority claimed from KR1020050108643A external-priority patent/KR100692650B1/ko
Priority claimed from KR1020050108611A external-priority patent/KR100738037B1/ko
Priority claimed from KR1020050108638A external-priority patent/KR100738039B1/ko
Priority claimed from KR1020050109047A external-priority patent/KR100666712B1/ko
Priority claimed from KR1020050109586A external-priority patent/KR100738040B1/ko
Priority claimed from KR1020050111369A external-priority patent/KR100666713B1/ko
Priority claimed from KR1020050111368A external-priority patent/KR100692632B1/ko
Priority claimed from KR1020050111373A external-priority patent/KR100716732B1/ko
Priority claimed from KR20060103170A external-priority patent/KR100845307B1/ko
Priority to EP08013419A priority Critical patent/EP2053552A3/fr
Priority to EP08013417A priority patent/EP2009586A3/fr
Application filed by KTFreetel Co Ltd filed Critical KTFreetel Co Ltd
Priority to EP08013418A priority patent/EP2018027A1/fr
Priority to EP08013420A priority patent/EP2026260A3/fr
Publication of EP1949281A1 publication Critical patent/EP1949281A1/fr
Publication of EP1949281A4 publication Critical patent/EP1949281A4/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/107—Computer-aided management of electronic mailing [e-mailing]

Definitions

  • the present invention relates to an open type mobile business supporting system and method for supporting various business models from contents providers or service providers (CP/SP) by providing an integrated interface for various resources of a mobile communication system.
  • CP/SP contents providers or service providers
  • a wireless Internet based contents service provider often uses a service of a wireless communication system to authenticate a user or to perform a billing operation for a predetermined service to a corresponding user.
  • FIG. 1 is a block diagram illustrating a network for a mobile service.
  • a contents provider (CP)/service provider (SP) system 1 that provides a mobile service accesses a mobile communication system 13 through the Internet 12.
  • the CP/SP system 1 provides a predetermined service to a plurality of mobile stations MS 14 or transmits data to the plurality of mobile stations MS 14.
  • the mobile terminal 14 denotes a small and light wireless communication device so as to allow a user to carry it anywhere and anytime, such as a portable phone or a personal digital assistant.
  • the mobile terminal 14 includes a transmitting/ receiving function for transmitting and receiving a voice and data signal through a mobile communication network, a controlling function for controlling overall operations according to the programmed control procedures, a user interface function for providing an user interface to a user, a display unit for displaying menus, messages, or graphics according to an operation state of the mobile terminal in response to the control of the controlling unit.
  • the mobile terminal 14 may include applications such as a browser.
  • the mobile communication system 13 denotes a system providing a wireless voice communication service or a wireless Internet service to the mobile terminal 14.
  • the mobile communication system 13 basically includes a plurality of base transceiver stations (BTS) 21 for managing a wireless communication region, a plurality of base station controllers (BSC) 22 for controlling the BTSs 21, a mobile switching center (MSC) 23 for accessing each BTS 22 and authenticating information about a mobile communication service subscriber, and an interworking function (IWF) 24 for transforming formats of voice data and packet data and connecting to an IP network or to another mobile communication network.
  • BTS base transceiver stations
  • BSC base station controllers
  • MSC mobile switching center
  • IWF interworking function
  • the mobile communication system 13 further includes systems for providing various additional services such as a short message service system (MASS) 25 for providing a text message transfer service, a multimedia message service center (MMSC) 26 for providing a transceiving service of a multimedia message including video, text and voice, and a push proxy gateway (PPG) 27 for providing message push service to a mobile terminal 14, and a location based service system (LBSP) 28 for providing a service related to location information.
  • a short message service system for providing a text message transfer service
  • MMSC multimedia message service center
  • PPG push proxy gateway
  • LBSP location based service system
  • the mobile communication system 13 may include various other systems for managing subscribers.
  • a sender and a receiver are authenticated through an authentication system (not shown) of the mobile communication system, and a user's mobile terminal is checked whether the mobile terminal has a function to receive a multimedia message or not through a terminal information management system (not shown).
  • a message transmission is required by accessing the MMSC 500, and a billing operation is performed after completely transmitting the corresponding multimedia message.
  • the mobile communication system 13 needs to cooperate with various internal systems, legacy systems.
  • the CS/SP system 11 need to directly access each of the legacy systems of the mobile communication systems 13 to request necessary processes and to receive the results thereof.
  • the CP/SP system 11 needs interfaces for each legacy system of the mobile communication system 13. Therefore, the structure of the CP/SP system 11 becomes complicated, and the CP/SP system 11 needs to exchange messages with the mobile communication system 13 at several times in order to provide one service. It is difficult to provide a quick and stable service.
  • An aspect of the invention is to provide an open mobile business supporting method and system for effectively supporting various business models desired by a contents/ service provider by providing single interface that can integrally use various resources of a mobile communication system.
  • the invention provides an open mobile business supporting method for supporting a content provider/ service provider (CP/SP) mobile service using a legacy system of a mobile communication system, including: setting up low-level functions, which can be grouped as a unit function among service logics of a CP/SP and performed by a wireless communication system, as biz logics; receiving a request of performing a predetermined biz logic from the CP/ SP; and performing the request biz logic through cooperating with a legacy system of a mobile communication system and internally performing predetermined processes, and returning the result of performing the biz logic to the CP/SP.
  • CP/SP content provider/ service provider
  • the invention provides an open mobile business supporting system including: a business logic processing unit for storing, managing, and performing a biz template that groups service logics of a contents provider/service provider (CP/SP) to a unit function, is defined based on a biz logic which is a low-level function performed by a mobile communication system, and is formed by arranging a plurality of biz objects in a predetermined order, where the biz object cooperates with each legacy system of a mobile communication system and performs a comparison and determination operation on the result of cooperating; an open interface processing unit for receiving a request of performing a predetermined biz logic from a CP/SP, requesting the business logic processing unit to perform a biz template corresponding to the requested biz logic, receiving the result of the request, and transferring the received result to the CP/SP; and a legacy cooperation processing unit for relaying a request from a predetermined legacy system and returning the result to the predetermine legacy system while performing a biz template by relay
  • an open mobile business supporting system supports various infra resources in a wireless com- munication system to be independently operated and integrally driven, thereby making various infra resources conveniently and effectively cooperated together. Furthermore, the open mobile business supporting system provides an integrated interface for the infra resources in the wireless communication system. Therefore, a service and an application layer can easily use the infra resources of the wireless communication system. [18] Moreover, the open mobile business supporting system according to the present invention classifies biz logic management, service management, and service execution, thereby effectively supporting various business models. [19]
  • FIG. 1 is a block diagram illustrating a network for a mobile service
  • FIG. 2 is a diagram illustrating a mobile communication system
  • FIG. 3 is a flowchart illustrating an open mobile business supporting method according to an exemplary embodiment of the present invention
  • FIG. 4 to FIG. 10 are diagram illustrating a method of embodying a biz logic and a biz template by an open mobile business supporting method according to an embodiment of the present invention
  • FIG. 11 and FIG. 12 shows a biz template embodied by a method of embodying a biz logic and a biz template by an open mobile business supporting method according to an embodiment of the present invention
  • FIG. 13 is a block diagram illustrating an open mobile business supporting system according to an exemplary embodiment of the present invention
  • FIG. 14B are flowcharts illustrating an open mobile business supporting method according to an exemplary embodiment of the present invention.
  • FIG. 15 is a block diagram illustrating an open mobile business supporting system according to an exemplary embodiment of the present invention.
  • FIG. 16 is a diagram illustrating message flow in an open mobile business supporting system according to an exemplary embodiment of the present invention.
  • FIG. 17 is a flowchart illustrating an operation of an open mobile business supporting system according to an exemplary embodiment of the present invention [30]
  • FIG. 18 is a block diagram illustrating the OI processing block according to an exemplary embodiment according to the present embodiment; [31]
  • FIG. 19 is a flowchart illustrating a detailed operation of the OI processing block
  • FIG. 20 is a block diagram illustrating a business logic processing block 200
  • FIG. 21 is a flowchart illustrating a business logic processing method in the open mobile business supporting system according to an exemplary embodiment of the present invention
  • FIG. 22 to FIG. 25 are flowcharts illustrating a method of performing a biz template according to an embodiment of the present invention
  • FIG. 26 is a block diagram illustrating a billing processing unit and a network structure according to an exemplary embodiment of the present invention
  • FIG. 27 is a block diagram illustrating a billing processing unit;
  • FIG. 28 is a block diagram illustrating a billing policy unit of the billing processing unit;
  • FIG. 29 is a flowchart illustrating a method of billing process according to an embodiment of the present invention:
  • FIG. 30 is a flowchart illustrating a procedure of applying the billing policy
  • FIG. 31 is a flowchart illustrating a prepay and pre- subtracting process performed in a billing processing unit 400;
  • FIG. 32 is a flowchart illustrating a procedure of processing and managing billing data in a billing processing unit 32 according to an exemplary embodiment of the present invention;
  • FIG. 33 is a block diagram illustrating a infra channel providing unit 300 according to an exemplary embodiment of the present invention;
  • FIG. 34 is a block diagram illustrating a cooperating structure of the infra channel providing unit 300 according to an exemplary embodiment of the present invention;
  • FIG. 35 is a flowchart of API in an infra channel providing unit according to an exemplary embodiment of the present invention; [45] FIG.
  • FIG. 36 is a flowchart illustrating a procedure of performing a biz object in an infra channel providing unit according to an exemplary embodiment of the present invention
  • FIG. 37 is a block diagram illustrating a structure of a legacy cooperation processing unit 500 in a mobile business supporting system according to an embodiment of the present invention
  • FIG. 38 is a block diagram illustrating the common managing unit 510 in the legacy cooperation processing unit 500
  • FIG. 39 is a block diagram illustrating a SMS interface 521 in a legacy cooperation processing unit 500 according to an exemplary embodiment of the present invention
  • FIG. 40 is a block diagram illustrating a MMS interface 522 in a legacy cooperation processing unit 500 according to an embodiment of the present invention
  • FIG. 41 is a diagram illustrating a biz template for a MMS messaging service according to an exemplary embodiment of the present invention
  • FIG. 42 is a block diagram illustrating a LBS interface of a legacy cooperation processing unit 500 according to an embodiment of the present invention
  • FIG. 43 is a diagram illustrating a biz template for inquiring position information, as an example of a location based service (LBS) related biz template.
  • FIG. 44 is a flowchart illustrating a method of performing a LBS related service using a legacy cooperation processing unit 500 having a LBS interface 523 according to an embodiment of the present invention
  • FIG. 45 is a block diagram illustrating a push interface according to an embodiment of the present invention
  • FIG. 45 is a block diagram illustrating a push interface according to an embodiment of the present invention.
  • FIG. 46 is a block diagram illustrating a structure for providing a download service in an open mobile business supporting system according to an embodiment of the present invention.
  • FIG. 47 is a flowchart illustrating a download service according to a first embodiment of the present invention
  • FIG. 48 is a flowchart illustrating a download service according to a second embodiment of the present invention
  • FIG. 49 is a flowchart illustrating a download service according to a third embodiment of the present invention
  • FIG. 50 is a block diagram illustrating an operating and management system (OMS)
  • FIG. 51 is a block diagram illustrating a web service providing unit in an open mobile business supporting system according to an embodiment of the present invention
  • FIG. 52 is a block diagram illustrating a logic processing unit 620 according to an embodiment of the present invention
  • FIG. 53 is a flowchart illustrating a method for processing a mobile oriented (MO) message using an open mobile business supporting system according to an embodiment of the present invention
  • FIG. 54 to FIG. 55 are diagram illustrating a MT message processing unit using an open mobile business supporting system according to a first embodiment of the present invention
  • FIG. 56 is a block diagram and a flowchart illustrating a MT message processing apparatus using the open mobile business supporting system according to an embodiment of the present invention
  • FIG. 57 and FIG. 58 are diagrams illustrating biz template for providing a MT message in an open mobile business supporting system according to an embodiment of the present invention
  • FIG. 59 is a flowchart illustrating a procedure for processing a MT MSM message after processing a MO SMS message using an open mobile business supporting system according to an embodiment of the present invention
  • FIG. 60 is a diagram illustrating a procedure of processing a MT MMS message after processing a MO MMS message using an open mobile business supporting system according to an embodiment of the present invention
  • FIG. 60 is a diagram illustrating a procedure of processing a MT MMS message after processing a MO MMS message using an open mobile business supporting system according to an embodiment of the present invention
  • FIG. 60 is a diagram illustrating a procedure of processing a MT MMS message after processing a MO MMS message using an open mobile
  • FIG. 61 is a diagram illustrating a procedure of processing a MO SMS message after processing a MT SMS message using an open mobile business supporting system according to an embodiment of the present invention
  • FIG. 62 is a diagram illustrating a procedure of processing a MO MMS message after processing a MT MMS message
  • FIG. 63 is a block diagram illustrating a configuration for providing a report after transmitting a message in an open mobile business supporting system according to an embodiment of the present invention
  • FIG. 64 is a block diagram illustrating a report open interface (ROI) processing unit
  • FIG. 65 is a flowchart illustrating a procedure of providing a report through an open mobile business supporting system of FIG. 63 after transmitting a message according to an embodiment of the present invention
  • FIG. 66 is a flowchart illustrating the detailed operation of a ROI processing unit
  • FIG. 67 is a block diagram illustrating an open mobile business supporting system for confirming a message transmission result after transmitting a message
  • FIG. 68 is a block diagram illustrating a ROI processing unit according to an embodiment of the present invention
  • FIG. 69 is a flowchart illustrating a procedure for conforming a message transmission result after transmitting a message in an open mobile business supporting system according to an embodiment of the present invention
  • FIG. 70 is a diagram illustrating the operations of a ROI processing unit 111' according to an embodiment of the present invention.
  • FIG. 3 is a flowchart illustrating the open mobile business supporting method according to an exemplary embodiment of the present invention.
  • the open mobile business supporting method according to the present embodiment is performed as follows.
  • the open mobile business supporting method selects logics that are performed in a mobile communication system 13 and starts and ends at a contnets provider (CP)/ service provider (SP) system 11 from logics of mobile services provided from the CP/SP system 11, and standardizes the selected logics. Then, the standardized logics are provided. Therefore, in the open mobile business supporting method according to the present embodiment, low-level functions, which can be grouped as a unit function and can be performed in a mobile communication system, are defined as biz logics, at step S310 of FIG. 3.
  • CP contnets provider
  • SP service provider
  • Each of the biz logics is a logic that starts at the CS/SP system 11, is performed by cooperating with legacy systems of the mobile communication system 13, comparing the cooperating results, making a decision based on the comparison results, and transfers the result thereof to the CP/SP system 11.
  • the biz logic is a set of the low- level functions, which can be grouped as a single function among the service logics provided by the CP/SP system 11. It is preferable to define the biz logic in consideration of frequency of use and reusability in diverse CP/SP systems 11. For example, in any types of mobile services, a general requested logic such as a user authentication process or a terminal authentication process has high reusability.
  • the user authentication process or the terminal authentication process is defined as a biz logic.
  • a mobile service for downloading specific contents or specific files to a mobile communication terminal 14 diverse functions such as an authentication process, a data transform process and a billing process are consecutively performed.
  • the mobile service for downloading contents is frequently used. Therefore, it is preferable to define such a mobile service for downloading specific contents or specific files as the biz log.
  • a predetermined service logic is selected through verifying the amount used, a usage trend, and a business aspect. Subsequently, a part corresponding to a range of the biz logic is selected from the service logics.
  • FIG. 4 is a diagram illustrating services selected for defining a biz logic in an open mobile business supporting system according to the present embodiment.
  • a service of "download to my phone is selected among menus, which are provided through a service of a wireless Internet of the mobile communication terminal 14.
  • the menu includes services of "download to my phone” "transmit to a friend” “perform coupling” and "put in a basket” A detailed logic of the selected service will be described with reference to FIG. 5.
  • the mobile service of "download to my phone” includes the steps of selecting specific contents by a user through the mobile communication terminal 14, selecting the "download to my phone” menu, requesting a user authentication process using a phone number as input data, determining whether the user is a normal personal user or a business user and whether the user is a prepaid user or an intelligent network user, notifying that requested service is not available through the mobile communication terminal 14 if the user is the abnormal personal user or the business user, performing a billing process that subtracts a relate fee of the requested service from the prepaid amount if the user is determined as the prepaid user, and transmitting related contents and performing a billing operation if the user is determined as the normal personal user.
  • a biz logic is determined among the selected service logics through range selection, objects selection, separation and optimization.
  • a reference for selecting a biz logic from the service logics may be how well functional units of the logic are collected, how well a format adding individual logics is derived as a standardized format, how realistically the logic is used, if the format of the logic is neutral and independent enough to be reformed in the other case.
  • the biz logic is separated in a case that the service logic requires a user to input, a case that input/output values of the service logic are different, and a case that the service logic is affected by external factors.
  • FIG. 7 is a diagram illustrating an example of the biz logic defined from the service logics of "download to my phone through procedures of FIG. 6. That is, the biz logic is divided into a biz logic for performing a user authentication process including a prepaid balance checking process, and a biz logic for performing a billing process that subtracts the related fee from the prepaid balance.
  • the determined biz logic is analyzed at step S3122.
  • a logic which needs to cooperate with legacy systems of a mobile communication system 12, is set up as a first Biz object, i.e., an I- type object.
  • a logic performing a comparing or determining process based on a cooperation result with the legacy system is set up as a second Biz object, i.e., a P-type object.
  • An input value and an output value of the first and second Biz objects are defined.
  • the second Biz object may be defined as one Biz object if many comparing/determination steps can be performed as a single unit process.
  • FIG. 8 is a diagram for describing setting up a first biz object in the user authentication process including a prepaid balance checking process as shown in FIG. 7.
  • the first biz object is an object requesting the user authentication process by cooperating with an authentication legacy system.
  • FIG. 9 is a diagram for describing setting up the second Biz object in the biz logic for performing a user authentication process including a selected prepaid balance checking process as shown in FIG. 7.
  • the second Biz object determines whether a service is provided according to a process result with the authentication legacy system.
  • the second Biz object is set up by classifying procedures of checking whether a user is a normal personal user or a business user, whether the user is a prepaid user or not, and whether the prepaid user is a multilevel user or an intelligent network user.
  • the first and second Biz objects are respectively set up by analyzing the logic within the determined range.
  • the first and second Biz objects are arranged according to the flow of a corresponding biz log.
  • the input and output values are defined.
  • a Biz template which is an operation format of the corresponding biz log, is formed at step S313.
  • the Biz template may have a format of a general flowchart.
  • the Biz template includes a list of Biz objects, an attribute of each object, an operation order of the Biz objects, description of conditional branch, input parameter information for operating the Biz objects, a data controlling method, output parameter information derived by operating the Biz template, and operation time-out setup information.
  • FIG. 10 is a diagram for describing the Biz template which standardizes the biz logic for performing a user authentication process including a selected prepaid balance checking process as shown in FIG. 7.
  • the Biz template includes an I-type authentication_user information checking Biz object, a P-type user information checking Biz object, and an I-type authentication_prepaid checking Biz object.
  • the I-type authentication_user information checking Biz object checks user information.
  • the P-type user information checking Biz object checks whether the service can be provided to the user.
  • the I type authentication_prepaid checking Biz object checks a prepaid balance of the user.
  • a flow of the Biz template is described as shown in the flowchart at the left part of FIG. 10.
  • output data are information on whether the process result is successful or not, and whether the user is a prepaid user.
  • the Biz template is a format that the biz logic is realized.
  • Biz templates including a user authentication template, a Short Message Service (SMS) transmitting template, an MMS transmitting template, a general location detecting template, and a push method platform message transmitting template based on SMS/ cell broadcasting service (CBS) can be realized.
  • SMS Short Message Service
  • MMS Mobile Multimedia Subsystem
  • CBS cell broadcasting service
  • FIGs. 11 and 12 are diagrams for describing the Biz template according to another exemplary embodiment of the present invention.
  • FIG. 11 shows a Biz template of the biz logic for performing a user authentication process.
  • FIG. 12 shows a Biz template of the biz logic including a determining process on whether a terminal is supported in the user authentication process.
  • the basic Biz template for performing a user authentication process includes 1 an I-type authentication_user information checking Biz object for checking user information and 2 a P-type user information checking Biz object for checking whether a service can be provided to the user based on the user information check result.
  • the input data are a user telephone number and a user authentication type as an option.
  • the output data are information on whether the process result is a success or an error.
  • the Biz template of FIG. 12 includes 1 an I-type authentication_user information checking Biz object, 2 a P-type user information checking Biz object, and 3 an I-type terminal support checking Biz object.
  • the I-type authentication_user information checking Biz object checks user information.
  • the P-type user information checking Biz object checks whether a service can be provided to the user based on the user information check result.
  • the I-type terminal support checking Biz object checks whether a terminal supports a specific service to the user who can receive the service.
  • the input data are a recipient telephone number, a user information checking option value and a terminal support service type.
  • the output data are process results.
  • a Biz template of an operation format of a corresponding biz logic is searched.
  • the Biz template cooperates with the legacy system.
  • An operate result value is returned to the CP/SP system 11 through the interface at steps S330 and S340.
  • API API for each Biz template.
  • the operation request of the specific biz logic is realized in an API calling format of the specific Biz template.
  • the open mobile business supporting method can support cooperation between the legacy systems by receiving the operation request of the predetermined Biz object from a specific legacy system of the mobile communication system 12, cooperating the requested Biz object with the corresponding legacy system, operating the cooperated Biz object, and providing a result value in order to transmit the result value to the specific legacy system transmitting the request. That is, the open mobile business supporting method can support fast cooperation between the legacy systems by using a conventional Biz object.
  • FIG. 13 is a block diagram illustrating a structure of the open mobile business supporting system according to an exemplary embodiment of the present invention.
  • the open mobile business supporting system includes an open interface (OI) processing 100, a business logic processing block 200, an infra channel providing unit 300, a billing processing unit 400, a legacy cooperation processing block 500, an operation and management system (OMS) 700 and a web service providing unit 600.
  • OI open interface
  • OMS operation and management system
  • a code 11 which is not described above, is a CP/SP system for providing a mobile service to the mobile communication terminal 14.
  • a code 30 is a legacy system including a service platform, an infrastructure system, and a network configuration device of the mobile communication system 13.
  • the service platform of the legacy system 30 includes a messaging platform, a location based service platform (LBSP) and a download platform.
  • the messaging platform provides a multimedia messaging service (MMS).
  • the LBSP provides a service for detecting and checking a location.
  • the download platform downloads predetermined contents to the mobile communication terminal.
  • the infrastructure system includes a CP/SP management system, a terminal information management system and an authentication system.
  • the CP/SP management system manages CP/SP information for providing a service.
  • the terminal information management system manages terminal information.
  • the authentication system manages user information.
  • the network configuration device includes a short message service center (SMSC) and a cell broadcasting service center (CBSC).
  • SMSC short message service center
  • CBSC cell broadcasting service center
  • the open mobile business supporting system provides a united interface to diverse legacy systems 30, relays the CP/SP system 11 and the legacy system 30, and supports configuration and providing the mobile service in the CP/SP system 11.
  • the OI processing block 100 receives an operation request of a specific biz logic from the external CP/SP system 11 of the mobile communication system 13. Also, the OI processing block 100 provides an interface for returning an operation result.
  • the interface is application program interface (API) based on web access.
  • the specific biz logic is requested by API calling of a corresponding Biz template.
  • the Biz template identification (ID) information and data such as contents are transmitted through the calling function and the result value is returned.
  • the OI processing block 11 analyzes the request transmitted from the CP/SP system 11 and extracts the Biz template ID information and the data. Subsequently, the OI processing block 11 transmits the Biz template ID information and the data to the business logic processing block 200.
  • the OI processing block 200 creates and manages a unique session key for each request of the CP/SP system 11. The created session key is used to classify the biz logics, which are processed in the open mobile business supporting system.
  • the OI processing block 200 encodes and decodes the data transmitted from/ to the CP/SP system 11.
  • the business logic processing block 200 can be classified as a unit function among service logics of the CP/SP system.
  • the business logic processing block 200 stores, manages and operates a plurality of Biz objects and the Biz template.
  • the Biz objects cooperate with each legacy system or perform comparing and determining processes on each legacy system of the mobile communication system realized to operate the biz log based on cooperation with each legacy system or the cooperation result.
  • the biz logic is a lower function to be operated by the mobile communication system.
  • the Biz template includes a plurality of Biz objects arranged in a regular order and operates the biz log.
  • the biz log, the Biz template and the Biz object will be understood with reference to description related to Figs. 4 to 10, the Figs. 11 and 12.
  • the business logic processing block 200 sets up and includes the Biz template, which is a realization format of the supporting biz log, and Biz object. Also, the business logic processing block 200 operates the Biz template requested by the OI processing block 200 and returns an operation result to the OI processing block 100. To be more specific, the business logic processing block 200 operates the first or second Biz object in an arrange order of the requested Biz template. When operation of all Biz objects ends, the business logic processing block 200 returns the result value to the OI processing block 100. The business logic processing block 200 requests cooperation with the legacy system 30 to the legacy cooperation processing block 500 according to the kind of the Biz objects included in the Biz template. Subsequently, the business logic processing block 200 receives back the result or performs an internal determining process or a comparing process based on the returned operation result.
  • the business logic processing block 200 receives back the result or performs an internal determining process or a comparing process based on the returned operation result.
  • the open mobile business supporting system can support a complicated service including diverse processes requested by the CP/SP system 11 based on the business logic processing block 200.
  • the open mobile business supporting system can support a cooperating process base on performance requiring a fast process through the infra channel providing unit 300.
  • the infra channel providing unit 300 directly receives an operation request of the Biz object, which is operated in other legacy system 30, from the legacy system 30 in the inside of the mobile communication system 13.
  • the infra channel providing unit 300 transmits the requested Biz object to the legacy system 30 through the legacy cooperation processing block 500 and receives back the process result from the legacy system 30. Subsequently, the infra channel providing unit 300 transmits the process result to the legacy system 30 requesting the operation of the Biz object.
  • FIGs. 14A and 14B are diagrams illustrating operations of the business logic processing block 200 and the infra channel providing unit 300 according to an exemplary embodiment of the present invention.
  • FIG. 14A shows a supporting procedure of the business logic processing block 200.
  • the business logic processing block 200 When the business logic processing block 200 receives an operation request of the Biz template from the OI processing block 100 at step S811, the business logic processing block 200 performs loading on data of a corresponding Biz template from Main Memory Register Database Management System (MMDB) 900 at step S812.
  • MMDB 900 is a database based on a memory and will be described with reference to description of FIG. 15.
  • the business logic processing block 200 operates the second Biz object in the loaded Biz template at step S813.
  • the business logic processing block 200 transmits a request message to the legacy cooperation processing block 500 according to the first Biz object of the Biz template at step S814.
  • the business logic processing block 200 repeats a procedure of receiving an acknowledge (ACK) message at step S815 and ends the operation of the Biz template.
  • ACK acknowledge
  • the business logic processing block 200 transmits billing information, which is acquired by ending the operation to the billing processing unit 400 at step S816, and transmits an operation result to the OI processing block 100 at step S817. Accordingly, the business logic processing block 200 can support a mobile service based on a complicated function by operating the biz logic including at least one service and process.
  • FIG. 14B shows a procedure of the infra channel providing unit 300.
  • the infra channel providing unit 300 directly receives and analyzes the request at step S 821.
  • the infra channel providing unit 300 performs an internal process according to the requested Biz object at step S812, requests the legacy cooperation processing block 500 to cooperate at step S813 and receives an ACK of the request at step S814.
  • the infra channel providing unit 300 transmits related billing information to the billing processing unit 400 at step S815 and transmits an operation result to the legacy system 30 requesting the service at step S816.
  • the mobile business supporting system directly processes cooperation between the internal systems of the mobile communication system not through the OI processing block 100, but through the infra channel providing unit 300. Also, the mobile business supporting system processes the request of the external CP/SP system 11 through the OI processing block 100 and the business logic processing block 200. Accordingly, the mobile business supporting system can improve a quality of a service by separately supporting the service based on the complicated function and the service based on performance.
  • the legacy cooperation processing block 500 is in charge of cooperation with the legacy system 30.
  • the legacy cooperation processing block 500 includes a plurality of cooperating units for processing an input/output interface function, a log of each legacy system and billing information.
  • the input/output interface function is respectively standardized for each legacy system classified on the basis of functional unit for an efficient process.
  • the legacy cooperation processing block 500 includes an SMS cooperating unit, a location based service (LBS) cooperating unit, an MMS cooperating unit, and an authentication cooperating unit.
  • the SMS cooperating unit transmits a transmission request of a short message to the SMSC and returns the result.
  • the LBS cooperating unit cooperates with the LBSP, transmits a location checking or detecting request message and receives back the operation result.
  • LBS location based service
  • the MMS cooperating unit transmits a multimedia message transmission request message to the MMSC and receives back the operation result.
  • the authentication cooperating unit transmits an authentication request message to the authentication legacy system related to a process for checking whether the user is a normal personal user, and a billing process in the inside of the mobile communication system 13. Subsequently, the authentication cooperating unit receives back the result.
  • the billing processing unit 400 collects billing data acquired by operating the Biz template and the Biz object of the business logic processing block 200 and the infra channel providing unit 300 and transmits the billing data to the billing legacy system.
  • the billing processing unit 400 refers to a billing condition set up for each service.
  • the billing processing unit 400 collects billing information for a corresponding process, e.g., a quantity of data and a log time, transforms the billing information into billing data and transmits the billing data to the legacy system for processing billing.
  • the billing processing unit 400 is formed on the same layer as the business logic processing block 200 and the infra channel providing unit 300. Accordingly, the billing processing unit 400 can respectively collect log information for each mobile service and for each legacy system. It makes an integration process of billing possible and detailed information is provided.
  • the open mobile business supporting system may further include the web service providing unit 600 for providing services of registering CP/SP or manager, checking statistics information related to performance of the open mobile business service, and monitoring.
  • the web service providing unit 600 provides a site for the manager and a site for the CP/SP.
  • the open mobile business supporting system includes the OMS 700. Therefore, the open mobile business supporting system can collect log information on the open mobile business supporting service, monitor obstacle and performance information and manage information for supporting operating work. That is, the open mobile business supporting system collects log information for each of the CP/SP through the OI processing block 100 and collects operation and obstacle information of the business logic processing block 200 and the legacy cooperation processing block 500. Subsequently, the open mobile business supporting system provides the operation and obstacle information to the CP/SP or the operator.
  • FIG. 15 is a diagram illustrating a structure of the open mobile business supporting system according to an exemplary embodiment of the present invention.
  • the open mobile business supporting system includes the OI processing block 100, the business logic processing block 200, the infra channel providing unit 300, the billing processing unit 400, the legacy cooperation processing block 500, the web service providing unit 600, and the OMS 700.
  • the open mobile business supporting system includes a message transmitting block 800.
  • the message transmitting block 800 includes a plurality of message queues (MQ) for transmitting a signal between the OI processing block 100 and the business logic processing block 200, and a signal between the business logic processing block 200 and the legacy cooperation processing block 500 or a signal between the infra channel providing unit 300 and the legacy cooperation processing block 500.
  • MQ message queues
  • the message transmitting block 800 asynchronously processes message exchange among the OI processing block 100, the business logic processing block 200, the infra channel providing unit 300, the billing processing unit 400, and the legacy cooperation processing block 500 through the message queue.
  • the open mobile business supporting system further includes the MMDB 900 to manage a request of the Biz template, an operation result and a status of Biz object/Biz template.
  • the OI processing block 100, the business logic processing block 200 and the infra channel providing unit 300 can access to the MMDB 900 and perform recording and reading processes.
  • the OI processing block 100 records the requested Biz template in the MMDB 900
  • the business logic processing block 200 operates the Biz template with reference to a pre- database based on a memory in the MMDB 900 and uses the pre-database to record the status.
  • the MMDB 900 stores information on the Biz template.
  • the MMDB 900 provides information on a corresponding Biz template.
  • the MMDB is a database (DB) located and operated in a main memory of a computer. Since the MMDB is located in the main memory differently from a typical DB stored and used in hard disk (HDD), the MMDB does not require a work for reading data. Also, the MMDB can use a query of the typical DB without change in a general status that an entire DB table is in the main memory. Accordingly, a speed for searching, comparing, and analyzing data increases. That is, the MMDB 900 according to the present embodiment can process the complicated biz logic at a highspeed by storing the requested Biz template information and status information.
  • the open mobile business supporting system further includes a repository DB 1000 for storing and managing CP/SP information and service/contents information.
  • the web service providing unit 600 provides registration and change of the CP/SP, a monitoring service, and newly added biz logic information including the API of each Biz template.
  • the OMA 700 manages obstacle and performance information with reference to the MMDB 900 and the repository DB 1000.
  • the message transmitting block 800 of FIG. 15 includes a plurality of message queues allocated to each system.
  • the OI processing block 100 records a request message of a predetermined Biz template in a designated message queue of the message transmitting block 800.
  • the business logic processing block 200 reads a Biz template request message in a designated message queue of the message transmitting block 800 and operates each Biz object included in the Biz template in an order.
  • the first Biz object records a cooperation request message of a predetermined legacy system in the inside of the message transmitting block 800.
  • the first Biz object reads and processes the request message in the designated message queue of the message transmitting block 800 of the legacy cooperation processing block 500.
  • the first Biz object records the result in a predetermined message queue of the message transmitting block 800.
  • the business logic processing block 200 reads a process result of the first Biz object in the message queue and continues a next process.
  • the business logic processing block 200 can secure independent operation of the OI processing block 100, the business logic processing block 200, the infra channel providing unit 300, and the legacy cooperation processing block 500 by transmitting a message through the message transmitting block 800.
  • FIG. 16 is a diagram illustrating a detailed configuration and a message transmitting flow of the message transmitting block 800 according to an exemplary embodiment of the present invention.
  • first, second, third, fourth and fifth message queues 811, 812, 813, 814 and 815 At least one of the first message queues 811 stores a request message of the OI processing block 100 that the business logic processing block 200 is to receive. At least one of the second message queues 812 is set up for each legacy cooperation processing block 500 and stores a request message that the business logic processing block 200 provides to the corresponding legacy cooperation processing block 500. At least one of the third message queues 813 stores a result message of the legacy cooperation processing block 500 that the business logic processing block 200 is to receive. At least one of the fourth message queues 814 stores a report message of the legacy cooperation processing block 500 that the business logic processing block 200 is to receive. At least one of the fifth message queues 815 stores a result message to be transmitted from the business logic processing block 200 to the OI processing block 100.
  • Information showing the first to fifth message queues 811 to 815 includes a name of a system, which transmits a stored message, a name of a system to receive the stored message, a kind of messages showing which one the stored message is among an ACK message, a request message and a report message, and a domain or an ID value set up for each input/output processor (IOP).
  • IOP input/output processor
  • FIG. 17 is a flowchart illustrating an operation of the open mobile business supporting system according to an exemplary embodiment of the present invention.
  • the OI processing block 100 receives standard API calling for a predetermined biz logic from the CP/ SP system 11, checks a Biz template related to the called API and transmits an operation request message of a corresponding Biz template to the business logic processing block 200 at steps Sl 100 and Sl 102.
  • the OI processing block 100 transmits the Biz template request message to the first message queue 811 of the message transmitting block 800 in order to transmit the operation request message of the Biz template.
  • the business logic processing block 200 checks whether the operation request message of the Biz template exists in the first message queue 811 of the message transmitting block 800. If the new operation request message of the Biz template exists, the business logic processing block 200 reads the operation request message of the Biz template in the first message queue 811 at step Sl 104. Subsequently, the business logic processing block 200 performs loading on Biz template information related to the request message from the MMDB 900 at step Sl 106 and operates a flow of the loaded Biz template at step Sl 108.
  • the business logic processing block 200 requests the operation of the Biz template by storing a message, which requests the legacy cooperation processing block 500 to cooperate, in a second message queue 812 at step Sl 110.
  • the second message queue 812 is allocated to each system of the legacy cooperation processing block 500.
  • the corresponding legacy cooperation processing block 500 reads and processes the recorded message and records an ACK message or a report message for an operation result in the third and fourth message queues 813 and 814.
  • the business logic processing block 200 can receive the ACK or report message for the request from the designated third and fourth message queues 813 and 814 at step Sl 112. If the process of the Biz template doesn't ends, the procedures of the steps Sl I lO and Sl 112 are repeatedly operated.
  • the business logic processing block 200 transmits billing information related to the process to the billing processing unit 400 at step Sl 116.
  • the business logic processing block 200 stores the Biz template operation result in the fifth message queue 815 of the message transmitting block 800 and transmits the Biz template operation result to the OI processing block 100 at step S1118.
  • the OI processing block 100 retransmits the transmitted Biz template operation result to the CP/SP system 11 at step Sl 120.
  • FIG. 18 is a block diagram illustrating the OI processing block according to an exemplary embodiment according to the present embodiment.
  • FIG. 18 shows a format that the OI processing block is realized in the open mobile business supporting system.
  • the OI processing block 100 according to the present embodiment includes a web service unit 101, an authenticating unit 102, a session key creating unit 103, a cooperation managing unit 104, a message analyzing and transforming unit 105, and a message processing unit 106.
  • the OI processing block 100 according to the present embodiment may further include a session managing unit 107, a log managing unit 108, a configuration managing unit 109, and a configuration information transmitting unit 110.
  • the web service unit 101 receives standard API input with respect to the operation request of the Biz template from the CP/SP system 11 and transmits the Biz template operation result to the CP/SP system 11.
  • the web service unit 101 and the CP/SP system 11 cooperates in a format of the web service based on Simple Object Access Protocol (SOAP).
  • SOAP Simple Object Access Protocol
  • the CP/SP system 11 creates a stub for the SOAP based on a web service toolkit provided for each platform and can use the web service as general function calling.
  • the CP/SP system 11 requests the operation of the Biz template by the web service unit 101 through the standard API and receives the operation result.
  • the authenticating unit 102 performs and manages an authentication process of the
  • the authenticating unit 102 performs and manages an authentication process of the CP/SP system 11.
  • the authenticating unit 102 constraints access to ID of the specific CP/SP system 11 and a specific Internet protocol (IP).
  • IP Internet protocol
  • the session key creating unit 103 creates a session key for the Biz template whose operation is requested by the CP/SP system 11.
  • the session key is a unique key with respect to each Biz template.
  • the session managing unit 107 manages the unique session key created in the session key creating unit 103.
  • the unique session key is mapped with Biz template information corresponding to the MMDB 900 and stored. Therefore, the unique session key is allocated to the Biz template information whose operation is request by the CP/SP system 11.
  • the Biz template information is stored in the MMDB 900.
  • the business logic processing block 200 receives the session key from the OI processing block 100 and searches Biz template information in the MMDB 900 based on the session key.
  • the business logic processing block 200 operates the searched Biz template and records the status information in the MMDB 900.
  • the cooperation managing unit 104 has a thread for the operation request of the Biz template of the CP/SP system 11 transmitted to the web service unit 101 wait.
  • the cooperation managing unit 104 activates the waiting thread and transmits the Biz template operation result to the web service unit 101.
  • the web service unit 101 receives standard API input for the operation request of the Biz template from the CP/ SP system 11 and transmits the standard API input to the cooperation managing unit 104.
  • the cooperation managing unit 104 transmits the standard API input to the message processing unit 106 and maintains the thread for the standard API input in a waiting status.
  • the cooperation managing unit 104 activates a process thread of the web service unit 101 and transmits the operation result to the web service unit 101.
  • the OI processing block 100 controls synchronous cooperation with the CP/SP system 11 and controls asynchronous cooperation with the business logic processing block 200. That is, when the OI processing block 100 according to the present embodiment receives the standard API input for the Biz template from the CP/SP system 11, the OI processing block 100 maintains a session with the CP/SP system 11 until the OI processing block 100 returns the Biz template operation result to the CP/SP system 11. Subsequently, the OI processing block 100 performs asynchronous cooperation.
  • the OI processing block 100 when the OI processing block 100 according to the present embodiment transmits the operation request message of the Biz template to the business logic processing block 200, the OI processing block 100 transmits the request message to the first message queue 811 of the message transmitting block 800 and searches an operation result message of the Biz template in the fifth message queue 815. If the operation result message of the Biz template exists, the OI processing block 100 asynchronously cooperates with the business logic processing block 200 by reading and transmitting the operation result message to the CP/SP system 11 through the web service unit 101.
  • the message analyzing and transforming unit 105 receives the operation result message from the CP/SP system 11 or the business logic processing block 200 and transforms the operation result message to be transmitted to the business logic processing block 200 or the CP/SP system 11. That is, the message analyzing and transforming unit 105 analyzes the standard API input transmitted from the CP/SP system 11 and transforms the standard API input into the operation request message of the Biz template readable by the business logic processing block 200. Also, the message analyzing and transforming unit 105 transforms the Biz template operation result transmitted from the business logic processing block 200 into a message to be transmitted to the CP/SP system 11.
  • the message processing unit 106 transmits/receives the operation request message of the Biz template or the operation result message of the Biz template to/from the business logic processing block 200. That is, the message processing unit 106 receives the operation request message of the Biz template transformed in the message analyzing and transforming unit 105 and records the operation request message of the Biz template in the first message queue 811 of the message transmitting block 800. The message processing unit 106 reads the operation result message of the Biz template, which is recorded in the fifth message queue 815, in the business logic processing block 200 and transmits the operation result message of the Biz template to the message analyzing and transforming unit 105. The message processing unit 106 asynchronously transmits/receives the operation request message or the operation result message of the Biz template by control of the cooperation managing unit 104.
  • the OI processing block 100 provides an interface as a point of contact for the CP/SP system 11, which is a client requiring a service of the open mobile business supporting system.
  • the OI processing block 100 receives diverse service requests from the CP/SP system 11 through a web interface.
  • the OI processing block 100 according to the present embodiment provides a business logic calling mechanism of a standard API format from the CP/SP system 11.
  • the open interface which has the CP/SP system 11 easily use a function of a wireless Internet infrastructure system without directly developing the wireless Internet infrastructure system differently from a typical cooperating method based on a protocol, is provided.
  • the open interface can be used without limitation of the kind of the CP/SP system as a client.
  • the OI processing block 100 may further include the session managing unit 107, the log managing unit 108, the configuration managing unit 109, and the configuration information transmitting unit 110.
  • the session managing unit 107 manages session information in the MMDB 900.
  • the MMDB 900 stores authentication information of the CP/SP system 11, the operation result of the Biz template and status information.
  • the Biz template information whose operation is requested by the CP/SP system 11 and the unique session key allocated to the Biz template are mapped and stored in the MMDB 90.
  • An important function of cooperation of the MMDB 900 is storing a session status, a Biz object status, session parameter information, and Biz object parameter information.
  • the session status is stored in case of operation of the session for processing a service requested from outside, change of the session status or end of the service process.
  • the session parameter is stored.
  • the object status and an object parameter value are stored.
  • the log managing unit 108 manages operation of the Biz template transmitted from the business logic processing block 200, log information on an error, statistics data, and session information on ended transaction.
  • the log managing unit 108 creates a system log related to the log and transmits the created log information and statistics data to the OMS 700.
  • the configuration managing unit 109 manages configuration information on the OI processing block 100 by providing a function for accessing to the environment setup file of the OI processing block 100 according to the present embodiment.
  • the configuration managing unit 109 reflects change of the configuration information of the OI processing block 100 according to the present embodiment in real-time. Accordingly, a module requiring corresponding configuration information can check a changed configuration information value.
  • the configuration information transmitting unit 110 receives a configuration information checking request of the OI processing block 100 through an external system web site 55.
  • the configuration information transmitting unit 110 extracts and transmits the configuration information to the web site.
  • a configuration information on-line checking module extracts a configuration information value and the configuration information transmitting unit 110 transmits the configuration information value extracted by the web service through the web site 55.
  • a developer of the web site 55 can check the configuration information transmitted through the web service on a configuration information checking screen of the OI processing block 100.
  • the open mobile business supporting system 100 may have more than two OI processing blocks 100 to support more users.
  • the business logic processing block 200 since the business logic processing block 200 reads and processes the request message of the OI processing block 100 in an order, the OI processing block 100 can generally use the first message queue 811.
  • the fifth message queue 815 sets up a message queue for each OI processing block 100.
  • the fifth message queue 815 includes information on a message queue to return a result value. Accordingly, it is possible to figure out in which part of the business logic processing block 200 the result value of the Biz template is recorded.
  • FIG. 19 is a flowchart illustrating a detailed operation of the OI processing block
  • the web service unit 101 receives standard API input for a specific operation request of the Biz template from the CP/SP system 11 at step S 1300.
  • a thread for the operation request of the Biz template of the CP/SP system 11 which the web service unit 101 receives remains in a waiting status.
  • the thread is activated and the Biz template operation result is transmitted to the web service unit 101.
  • the session key creating unit 103 creates a unique session key with respect to the
  • the created session key is mapped with a corresponding Biz template and stored in the MMDB 900.
  • the authenticating unit 102 authenticates the Biz template at step S 1304.
  • the authenticating unit 102 also authenticates the CP/SP system 11 providing the operation request of the Biz template.
  • the message analyzing and transforming unit 105 transforms the operation request of the Biz template into a message format, which is readable by the business logic processing block 200, to transmit the operation request of the Biz template to the business logic processing block 200.
  • the message processing unit 106 transmits the transformed operation request message of the Biz template to the business logic processing block 200 at step S 1308 and waits to receive the operation result message of the Biz template at step S 1310.
  • the message processing unit 106 records the operation request message of the Biz template in the first message queue 811 of the message transmitting block 800 to transmit the operation request message of the Biz template to the business logic processing block 200. Subsequently, the message processing unit 106 waits until the operation result message of the Biz template arrives at the fifth message queue 815 of the message transmitting block 800.
  • the OI processing block 100 provides a service for using the open mobile business supporting system based on an invoke API function.
  • the API is provided according to each Biz template provided in the open mobile business supporting system.
  • the API is set up according to each request by a user authentication process including a prepaid balance checking process and a terminal supporting checking process, a phone model information checking process, a number change checking process, a phone model information checking process, an SMS transmitting process, an MMS transmitting process, a general location searching process, a pushing method, a platform message transmitting process, a transmitting process to other company, and a transmitting process to my phone.
  • the provided API is basically using the invoke API function.
  • the API requests operation of a specific Biz template by using TEMPLATE_ID, which is a Biz template ID showing the Biz template to be operated, AUTH_KEY, which is an authentication key given to use the Biz template, inParamSet, which is an input parameter for transmitting information required for operation of the Biz template, and outParamSet, which is an output parameter showing result information returned after operation of the Biz template, as a parameter.
  • the API can acquire result information.
  • the output parameter basically includes a result code showing whether the service request succeeds or fails, and a reason of failure in case that the service request fails and a result message showing the operation result value.
  • the result code returns a "0" value in case that the service request succeeds.
  • a code set up according to the kind of each error is returned.
  • a list and contents of the provided error code are provided in advance to the CP/SP.
  • the open mobile business supporting system provides the API for a basic user authentication process such as a process for checking whether the user is a normal personal user and cutting off suspension/termination, cutting off a business user, cutting off a prepaid user, and cutting off intelligent network prepayment.
  • the API includes a user phone number and a user authentication type showing the basic user authentication process such as a process for checking whether the user is a normal personal user and cutting off suspension/termination, cutting off a business user, cutting off a prepaid user, and cutting off intelligent network prepayment.
  • the API includes the result code and the result message. The result code shows the success or failure and the kind of errors in case that the user authentication request fails.
  • the open mobile business supporting system can set up the API further including a prepaid balance checking process as well as the basic user authentication process.
  • the API further includes price information on the contents/service provided with the user phone number and the user authentication type.
  • the API as the output parameter includes information on whether the user is a prepaid user, and balance information of the user when the user is not the prepaid user in addition to the request result code and the result message.
  • the API has the CP/SP system 11 take proper measures by transmitting a corresponding error code value through the result code among the output parameters.
  • the open mobile business supporting system provides the API for authenticating the user and checking whether the terminal is supported according to the kind of the services.
  • the API can acquire information on whether the terminal is supported according to the kind of the services in case that basic user authentication process is performed by request according to the authentication types and the authentication is successful.
  • the input parameter includes the user phone number, the user authentication type and service information on which one the service to be supported by the terminal corresponds to among the MMS, flash or MP3.
  • the output parameter includes the result code showing whether the request thereof is successful and the result message.
  • the open mobile business supporting system provides the API for checking information on a phone model of a mobile communication subscriber to acquire model information on the corresponding mobile communication terminal.
  • the API includes only the user phone number.
  • the output parameter includes the result code, the result message, and many values showing phone information, e.g., a phone model name, a bell type code, poly information, color information, information on whether Code Division Multiple Access (CDMA) or karaoke is supported.
  • the result code shows whether the phone model checking request result succeeds.
  • the open mobile business supporting system may include the API for checking whether the user is a subscriber receiving a specific service at a monthly fixed-rate.
  • the API includes a service ID value set up for each service, a user phone number, a kind of user authentication types, an ID value of the CP/SP providing the service, a price of corresponding contents.
  • the API includes a result code showing a success code and an error code of a monthly fixed-rate authentication process and the prepaid balance checking request, and a result message for transmitting a request result value.
  • the open mobile business supporting system may include the API for checking only on whether the user is a subscriber receiving a specific service at a monthly fixed-rate.
  • the API includes a service ID value set up for each service, a user phone number, a user authentication type, and an ID value of the CP/SP providing the service.
  • the API includes an authentication process of a monthly fixed-rate, a result code showing a success code and an error code of a monthly fixed-rate authentication process, and a result message for describing an operation result value for the request.
  • the open mobile business supporting system provides the API for respectively performing a subscription or termination process on a specific service provided at a monthly fixed-rate.
  • the API includes a service ID value set up for each service, a service code value, ID information of a contents provider, and a phone number for performing the subscription or termination process.
  • the API includes a result code providing information on success or error of the request thereof and a result message for transmitting a request thereof value.
  • the open mobile business supporting system can provide the API for checking information on a wireless Internet user of a specific ID.
  • the API includes wireless Internet user ID and an encoded password of the user.
  • the API includes a result code showing information on success or error of the request thereof, a result message showing an operation result value of the request, and basic information of a corresponding wireless Internet user, e.g., a phone number, a name, and a resident registration number.
  • the open mobile business supporting system can provide the API for checking a phone number of a wireless Internet user of a specific ID.
  • the API has a wireless Internet ID.
  • the API has a result code, a result message, a phone number and/or a name of an authentication object.
  • the open mobile business supporting system provides the API for checking whether the user is authenticated through a resident registration number.
  • the API includes a user authentication type described in the API for a basic user authentication process, a phone number of an authentication object, a resident registration number or a business registration number of an encoded authentication object, an authentication type showing which one the authentication object corresponds to among a nominee, a businessman, or an actual user.
  • the API includes only a result code and a result message.
  • the open mobile business supporting system provides the API for checking color information provided according to each phone.
  • the API includes information on a phone to be checked, such as a model name or a phone number.
  • the API includes a result code, a result message and color information of a corresponding phone, e.g., a single color, 4 gray and 256 colors.
  • the open mobile business supporting system includes the API for checking number portability information on a carrier switching subscriber.
  • the API inputs a user phone number.
  • the API outputs a result code showing success or error information of a request thereof, a result message recording an operation result value of the request, and final routing information of number portability.
  • the open mobile business supporting system includes the API, which provides age information for determining whether the user is an adult.
  • the API inputs a user phone number.
  • the API returns a result code showing success or error information of a request thereof, a result message showing an operation result value and an age code showing a user's age.
  • the open mobile business supporting system provides the API for checking phone model information.
  • the API inputs a user phone number or a phone model name.
  • the API provides success or error information of a request thereof, a result message and phone performance information including a phone model name, a bell type, poly information, color information, information on whether CDMA or karaoke is supported.
  • the open mobile business supporting system provides the API performing prepayment and pre- subtraction processes for a billing process that subtracts the related fee from the prepaid balance in advance.
  • the API inputs an object phone number, a prepaid subscription product code, a subtraction request cost, and a billing pattern.
  • the API acquires a prepaid subtraction result.
  • the open mobile business supporting system provides the API used in transmission of the SMS.
  • the API includes information required for SMS transmission such as an SMS type showing which one the message corresponds to among a short message, a call back message and a platform message, a telephone number for reply or a call back telephone number in case that uniform resource locator (URL) is designated, URL, a transmission message, a phone number of a caller, a phone number of a recipient and billing pattern information.
  • the API includes a result code showing whether the SMS transmission request thereof is a success, a result message and a session key allocated in the open mobile business supporting system for checking a transmission result.
  • the open mobile business supporting system provides the API for transmitting an SMS monotone bell sound.
  • the API includes a call back telephone number, a transmission message, a phone number of a caller, a phone number of a recipient, platform ID information, and billing information.
  • the API includes a result code showing whether the request thereof is a success or an error, a result message and a session key given to the request to check a transmission status.
  • the open mobile business supporting system provides the API for checking the SMS transmission result.
  • the open mobile business supporting system checks an SMS transmission result of the session key inputted as a parameter and returns a result.
  • the API includes the session key returned after SMS transmission request.
  • the API includes a result code showing whether the check result is a success and a result message describing the check result.
  • the open mobile business supporting system provides the API for transmitting a multimedia message to a phone of a recipient requested by a caller.
  • the API internally includes a basic authentication process for the caller and the recipient, it is not required to call the API for a special user au- thentication process.
  • the open mobile business supporting system determines a kind of terminal to receive a multimedia message. In case of a terminal loading a browser, the open mobile business supporting system transmits an SMS of a call back URL method. When the terminal user presses a button, the open mobile business supporting system downloads and displays MMS contents of the call back URL to the terminal.
  • the API includes a transaction ID of the MMSC, a VAS ID, a call back mobile phone number, a message transmitting method, information on where there is a contents transform request, a title and contents of a message, platform ID information, a caller phone number, a recipient phone number, billing information, and a billing pattern.
  • the API includes a result code showing success or error information of the request thereof, a result message and a session key allocated to the request. Accordingly, the CP/SP can check a transmission result of the requested multimedia message.
  • the contents of the multimedia message provided as the input parameter are described as an HTTP message including an HTTP header and a contents area.
  • the header and the contents region are classified into CRCF.
  • the contents region includes a parameter entity and a series of media entities.
  • the parameter entity has a parameter required for a multimedia message service.
  • the series of media entities are included in the multimedia message.
  • the sequence of the entity is not important. However, if the parameter entity having the multimedia message service parameter exists, the entity should be located in a first place.
  • a Hypertext Markup Language (HTML) document configurating a frame of all media entities in the inside of the multimedia message should be included as a first entity among the media entities.
  • Each entity can include its own header field.
  • the open mobile business supporting system further provides the API for checking a transmission result of the transmitted multimedia message.
  • the API includes a session key returned through the API for transmitting the multimedia.
  • the open mobile business supporting system provides the API detecting a location of a specific phone to support the LBS.
  • the API includes a user authentication type in case that authentication is included, a positioning method, ACK time setup information, a returning method such as whether to receive location information, or to receive the location information with a map, a format of the map in case that the map is received, color and screen information, a caller phone number, a recipient phone number, billing information, service platform (SP) registered in the LBSP, a code and a service code.
  • SP service platform
  • the API includes a result code displaying a success or an error of the request thereof, a result message, a location value such as X and Y coordinates, an error range, encoded address information, an error range, a positioning result time, a positioning method, a provided map name, information on whether a map viewer is loaded, a map scale, and an encoded image file.
  • the API also transmits checked location information. If a time for detecting a location by a Global Positioning system (GPS) takes long, a reservation number can be returned and the location should be rechecked through the reservation number.
  • GPS Global Positioning system
  • a rechecking API is further provided.
  • the API includes a request type such as binary runtime environment for wireless (BREW), a cable, KUN, ME, Wireless Internet Platform for Interoperability (WIPI), a reservation number returned by the location checking process, a platform division information, a caller/recipient phone number, billing information, a billing pattern, a service platform (SP) registered in the LBSP, and a service code.
  • the output parameter is formed in the same manner as the API for a location checking process is formed.
  • the open mobile business supporting system provides the API for adding or deleting mutual authentication of location detection.
  • the API includes user authentication information, information on a request type such as BREW, KUN, ME and WIPI, a caller phone number, a version of a caller browser, a mobile phone number of a receiver, a service platform registered in the LBSP, and a service code.
  • the API includes a request type, a caller phone number, a recipient phone number, a service platform registered in the LBSP, a service code, a requesting subject of a tracer or a traced as the input parameter.
  • the API includes a result code showing success or error information of a request thereof and a result message returning a result value.
  • the open mobile business supporting system provides the API for checking the mutual authentication list in a positioning service.
  • the API includes a user authentication type, a request type such as BREW, a cable, KUN, ME and WIPI, a caller phone number, a version of a recipient browser, information on whether the requestor is the tracer or the traced, a service platform registered in the LBSP, and a service code.
  • the API includes a result code recording a success or error code of a request thereof, a result message describing a result value, and a check list.
  • the open mobile business supporting system provides the API for requesting setup of a trigger through a parameter among LBSs.
  • the API includes a user authentication type, a request type such as BREW, a cable, KUN, ME and WIPI, a caller phone number, a caller browser version, the traced telephone number, a start or end time, a trigger interval, a positioning method, and URL for putting a result after performing trigger.
  • the API includes a result code describing a success or error code of the request thereof, a result message describing a result value, and a trigger ID set up for each trigger.
  • the trigger ID is used to delete or minutely check a corresponding list.
  • the open mobile business supporting system provides the API requesting cancel of the set up trigger.
  • the API includes a request type such as BREW, a cable, KUN, ME and WIPI, a caller phone number, a caller browser version, a trigger ID acquired by checking the trigger, a service platform registered in the LBSP, and a service code.
  • the API receives back a result code describing a success or error code of a request thereof, a result message describing a result value, and a traced telephone number hoe.
  • the API is formed for each Biz template provided in the open mobile business supporting system and provided to the CP/SP system 11.
  • the CP/SP system 11 can easily acquire performance of a desired service and a result value by requesting the provided API regardless of adding or changing of a new infrastructure in the inside of the mobile communication system.
  • the CP/SP is supported to use an internal infrastructure of the mobile communication system based on a standardized and verified method. Accordingly, a fast and stable mobile service can be provided.
  • FIG. 20 is a block diagram illustrating a detailed configuration of the business logic processing block 200.
  • the business logic processing block 200 includes a first conforming unit 201, a first message analyzing and transforming unit 202, a template operating unit 203, an object operating unit 204, a template loading unit 205, a template managing unit 206, a second message analyzing and transforming unit 207, and a second conforming unit 208.
  • the business logic processing block 200 may further include at least one of a session managing unit 209, a repository managing unit 210, a log managing unit 211, a DB cooperating unit 212, a time-out creating unit 213, a configuration information managing unit 214, a configuration information transmitting unit 215, and an end processing block 216.
  • the first conforming unit 201 is in charge of interfacing between the OI processing block 100 and the business logic processing block 200.
  • the first conforming unit 201 receives an operation request message of a Biz template from the OI processing block 100 and transmits the operation result message of the Biz template to the OI processing block 100.
  • the first conforming unit 201 checks whether the operation request message of the Biz template recorded in the first message queue 811 exists in the OI processing block 100 and reads the operation request message.
  • the first conforming unit 201 records the operation result message of the Biz template in the fifth message queue 815 to read the operation result message of the Biz template in the OI processing block 100. Accordingly, the first conforming unit 201 can transmit the operation result message of the Biz template.
  • the first message analyzing and transforming unit 202 transforms the operation request message of the Biz template transmitted through the first conforming unit 201 into a message format corresponding to a destination.
  • the first message analyzing and transforming unit 202 transmits the operation result message of the Biz template to the first conforming unit 201.
  • the first message analyzing and transforming unit 202 receives and analyzes the operation request message of the Biz template transmitted from the OI processing block 100. Subsequently, the first message analyzing and transforming unit 202 processes the operation request message of the Biz template into an object format, which can be analyzed in the business logic processing block 200 according to the present embodiment.
  • the object is sequentially operated.
  • the template operating unit 203 operates the Biz template by operating the Biz object according to the biz logic of the Biz template.
  • the biz logic to be operated in the mobile communication system 13 is a logic that a plurality of Biz objects are arranged in an order.
  • the biz logic is realized in a predetermined Biz template. That is, the Biz template is an object format that the biz logic is realized. Therefore, the Biz template can be operated by sequentially operating a plurality of Biz objects.
  • the template operating unit 203 analyzes the received operation request message of the Biz template, extracts Biz objects in the inside of the Biz template, and sequentially operates each of the extracted Biz objects.
  • the Biz template information is loaded in a specific database.
  • the template operating unit 203 When the template operating unit 203 operates the Biz template, the template operating unit 203 requests and operates the loaded Biz template.
  • the template operating unit 203 creates cooperation with the MMDB 900 based on the session managing unit 209, acquires session information of the Biz template to be operated, and operates the Biz template.
  • the object operating unit 204 requests a realized object of a corresponding Biz object according to the operation request of the Biz object by the template operating unit and operates the Biz object.
  • the Biz object can be operated internally or by the legacy system 30 through cooperation with the legacy cooperation processing block 500. That is, the Biz object includes the first Biz object cooperating with the legacy system 30 and the second Biz object performing comparing/determining processes based on the operation result of the first Biz object.
  • the template loading unit 205 loads the Biz template and the Biz object in a specific memory.
  • the template loading unit 205 returns a corresponding Biz template from the memory.
  • the template loading unit 205 updates and deletes the Biz template loaded in the memory upon the updating or deleting request of the Biz template loaded in the memory.
  • the template managing unit 206 manages the Biz template loaded in a specific memory by the template loading unit 205 in the memory.
  • the second conforming unit 208 transmits the operation request message of the Biz object to the legacy cooperation processing block 500. Subsequently, the second conforming unit 208 receives an operation result message of the Biz object transmitted from the legacy cooperation processing block 500.
  • the second conforming unit 208 is in charge of interfacing between the legacy cooperation processing block 500 and the business logic processing block 200 according to the present embodiment.
  • the second conforming unit 208 records the operation request message of the Biz object in the second message queue 812 to read the operation request message of the Biz object in the legacy cooperation processing block 500. Accordingly, the second conforming unit 208 can transmit the operation request message of the Biz object to the legacy cooperation processing block 500.
  • the second conforming unit 208 checks whether the operation request message of the Biz object recorded in the third message queue 813 exists in the legacy cooperation processing block 500. If the operation request message of the Biz object exists, the second conforming unit 208 reads the result message.
  • the second message analyzing and transforming unit 207 transmits the operation request message of the Biz object to the second conforming unit 208 according to the biz logic of the Biz template upon operation request of the Biz template. Subsequently, the second message analyzing and transforming unit 207 transforms the operation request of the Biz object transmitted through the second conforming unit 208 into a message format corresponding to a destination. In particular, the second message analyzing and transforming unit 207 receives and analyzes the operation request message of the Biz object transmitted from the legacy cooperation processing block 500. Subsequently, the second message analyzing and transforming unit 207 processes the operation request message of the Biz object into a message, which can be analyzed in the business logic processing block 200 according to the present embodiment.
  • the business logic processing block 200 provides a mechanism for processing the biz logic of the CP/SP system 11 at a highspeed, which is a client requiring a service of the open mobile business supporting system.
  • the open mobile business supporting system according to the present embodiment does not repeatedly process a service logic by individually cooperating with each of the typical legacy systems 30.
  • the open mobile business supporting system according to the present embodiment can process a normal and stable service logic by managing and operating the biz logic standardized in advance through the business logic processing block 200.
  • the business logic processing block 200 may further include the session managing unit 209, the repository managing unit 210, the log manager 211, the DB cooperating unit 212, the time-out creating unit 213, the configuration information managing unit 214, the configuration information transmitting unit 215, and the end processing unit 216.
  • the session managing unit 209 manages session status information of the Biz template stored in the MMDB 900.
  • the session managing unit 209 manages session information on the request of the Biz template and session information on the operation result of the Biz template and the Biz object.
  • the MMDB 900 stores authentication information of the CP/SP system 11, and operation result and status information of the Biz template.
  • Biz template information whose operation is requested by the CP/SP system 11 and a unique session key allocated to the Biz template are mapped and stored in the MMDB 900.
  • An important function of cooperating with the MMDB 900 is storing a session status, a Biz object status, session parameter information, and Biz object parameter information.
  • the session status is stored.
  • a session parameter is stored.
  • an object is operated to process a service after the session starts.
  • the object status and the object parameter value are stored.
  • the repository managing unit 210 registers, corrects or deletes the Biz template information and the CP/SP information in a repository 52.
  • the repository managing unit 210 reads the Biz template information and the CP/SP information in the repository and responds to the request.
  • the repository managing unit 210 returns the Biz template information from the repository DB 1000 and returns CP/ SP authentication information from the repository DB 1000.
  • the log managing unit 211 manages log information on the operation and the error of the Biz template, statistics data, and session information on ended transaction.
  • the log managing unit 211 creates log on the Biz template and the error outputted from the business logic processing block 200. Subsequently, the log managing unit 211 stores the created log in an operation and management system (OMS) DB 53.
  • OMS operation and management system
  • the log managing unit 211 stores row data for statistics data in the OMS DB 53 and initializes session information on the ended transaction.
  • the DB cooperating unit 212 executes a cooperating function with a pre-setup database. That is, the DB cooperating unit 212 cooperates with the pre-setup database, provides a pool function for cooperating with the database, and executes a database update function for supporting a transaction process.
  • the time-out creating unit 213 When certain conditions are met in comparison with a pre-setup time in operation of the Biz template, the time-out creating unit 213 generates time-out.
  • the configuration information managing unit 214 manages configuration information on the business logic processing block 200 by providing an access function to an environment setup file of the business logic processing block 200.
  • the configuration information managing unit 214 reflects the change of the configuration information in real-time. Accordingly, a module requiring corresponding configuration information can check a changed configuration information value.
  • the configuration information transmitting unit 215 provides an interface with an external system.
  • the configuration information transmitting unit 215 receives a configuration information checking request of the business logic processing block 200 according to the present embodiment through an external system web site 54, extracts configuration information and transmits the configuration information to the web site.
  • the configuration information on-line checking module extracts a configuration information value and transmits the extracted configuration information value through the web site 55 realized through the web service providing unit 600.
  • the developer can check the configuration information transmitted through the web service on a configuration information checking screen of the business logic processing block 200.
  • the configuration information transmitting unit 215 can control a thread of the business logic processing block 200.
  • the end processing block 216 provides a function for safely ending the business logic processing block 200 according to the present embodiment.
  • the end processing block 216 creates a request message for requesting end of the business logic processing block 200 and transmits the request message to the configuration information transmitting unit 215 through a specific message queue.
  • the configuration information transmitting unit 215 responds to the end request and ends a thread of the business logic processing block 200.
  • FIG. 21 is a flowchart illustrating a business logic processing method in the open mobile business supporting system according to an exemplary embodiment of the present invention.
  • the first conforming unit 201 receives the operation request message of the Biz template transmitted of the CP/SP system 11 from the OI processing block 100 at step S 1500.
  • the first conforming unit 201 checks whether the operation request message of the Biz template recorded by the OI processing block 100 exists in the first message queue 811. When the operation request message exists, the first conforming unit 201 reads the operation request message. Subsequently, the first conforming unit 201 loads the Biz template of the operation request message of the Biz template in a specific memory and analyzes the operation request message of the Biz template at steps S 1502 and S 1504.
  • a Biz object is extracted at step S 1510 according to the biz logic of the Biz template to operate the Biz template.
  • the Biz template is an object that the biz logic to be operated in the mobile communication system 13 is relized.
  • the biz logic is a logic that pluralities of Biz objects are arranged in an order. Therefore, the operation of the Biz template is realized at step S 1512 by sequentially operating Biz objects according to the biz logic in the inside of the Biz template whose operation is requested.
  • An operation result of the sequentially operated Biz object is received and stored at step S 1514.
  • the operation of the Biz template ends.
  • the operation of the Biz template finally ends at step S 1516, an operation result message of the Biz template is formed at step S1518.
  • the operation of the Biz template is realized by sequentially operating the internal Biz object. If the Biz object to be operated is an I-Type, a cor- responding object operation request message is transmitted to the legacy cooperation processing block 500 through the second conforming unit 208. When the operation request message of the Biz object is transmitted from the legacy cooperation processing block 500, a next Biz object is continuously operated. When a result that the Biz object is sequentially operated is stored in the MMDB 900 based on the session managing unit 209 and the operation of the Biz template ends, an operation result message of the Biz template is formed.
  • the formed operation result message of the Biz template is transmitted to the OI processing block 100 through the first conforming unit 201 at step S 1520.
  • Figs. 22 to 25 are flowcharts illustrating a Biz template operating procedure in the business logic processing block according to an exemplary embodiment of the present invention.
  • FIG. 22 is a flowchart illustrating a Biz template loading and returning procedure.
  • the template loading unit 205 of the business logic processing block 200 receives the operation request message of the Biz template from the OI processing block 100. Otherwise, the template loading unit 205 loads the Biz template including the Biz object in a pre-setup specific memory at step S 1600 when the business logic processing block 200 is operated.
  • the template loading unit 205 searches a corresponding Biz template in the memory at step S 1604 and returns the searched Biz template to the template operating unit 203 at step S 1606. Accordingly, the template operating unit 203 operates the Biz template.
  • FIG. 23 is a flowchart illustrating a Biz template updating/deleting procedure.
  • the template loading unit 205 of the business logic processing block 200 receives an operation request message of the Biz template from the OI processing block 100. Otherwise, the template loading unit 205 loads the Biz template in the pre-setup specific memory at step S 1700 when the business logic processing block 200 is operated. Subsequently, when the template loading unit 205 receives the update or delete request of the Biz template at step S 1702, the template loading unit 205 searches a corresponding Biz template in the memory and updates or deletes the searched Biz template at steps S 1704 and S 1706.
  • FIG. 24 is a flowchart illustrating a session key extracting procedure of the Biz template in the business logic processing block 200.
  • the business logic processing block 200 when the business logic processing block 200 according to the present embodiment receives an operation request message of a specific Biz template from the OI processing block 100 at step S 1800, the business logic processing block 200 extracts a session key allocated to the Biz template from the operation request message of the Biz template at step S 1802.
  • the OI processing block 100 receives standard API input for the operation request of the Biz template from the CP/SP system 11, creates a session key corresponding to the Biz template and stores the session key with the Biz template information in the MMDB 900. Subsequently, the business logic processing block 200 receives the session key.
  • the business logic processing block 200 searches a Biz template corresponding to the transmitted session key in the MMDB 900 at step S 1804 and operates the searched Biz template at step S 1806.
  • FIG. 25 is a flowchart illustrating a data processing/managing procedure in the business logic processing block according to the present embodiment.
  • the business logic processing block 200 according to the present embodiment performs a managing process of registering, correcting, and deleting the session information on the operation request of the Biz template transmitted from the OI processing block 100 and an operation result at step S 1900.
  • the business logic processing block 200 creates log data and statistics data on the operation and error of the Biz template and stores the log data and the statistics data in the OMS DB 53 at steps S 1902 and S 1904.
  • the business logic processing block 200 performs a managing process such as of registering, correcting, and deleting the session information of the ended transaction with respect to the operating of the Biz template at step S 1906.
  • FIG. 26 is a block diagram illustrating a billing processing unit and a network structure of other devices to describe a billing process according to the operation of the Biz template in the open mobile business supporting system according to an exemplary embodiment of the present invention.
  • the billing processing unit (BE) 400 according to the present embodiment cooperates with the business logic processing block 200 through a message queue.
  • the billing processing unit 400 cooperates with the infra channel providing unit 300 and a pre-payment pre- subtraction billing legacy system 420 through Transmission Control Protocol (TCP).
  • TCP Transmission Control Protocol
  • the billing processing unit 400 cooperates with the billing legacy system 11 and the OMS 700 through File Transfer Protocol (FTP).
  • FTP File Transfer Protocol
  • the billing processing unit 400 cooperates with the repository DB 1000 through Hypertext Transfer Protocol (HTTP).
  • HTTP Hypertext Transfer Protocol
  • the billing processing unit 400 collects a billing log from the business logic processing block 200 or the infra channel providing unit 300, processes billing and transmits the billing log to the billing legacy system 11. Also, the billing processing unit 400 cooperates with the repository DB 1000 and manages a billing policy. The billing processing unit 400 cooperates with the OMS 700 and transmits/receives operation and management data. In addition, the billing processing unit 400 processes a pre-payment pre- subtraction billing process request by cooperating with the pre-payment pre- subtraction billing legacy system 420.
  • FIG. 27 is a block diagram illustrating the billing processing unit. Referring to FIG.
  • the billing processing unit 400 includes a billing log parsing unit 401, a billing policy unit 402, a billing file creating unit 403, a billing file transmitting unit 404, and a billing policy DB 405.
  • the billing processing unit 400 according to the present embodiment may further include a pre-payment pre- subtraction billing processing block 406, a DB managing unit 407, a configuration managing unit 408, a log managing unit 409, a policy managing unit 410, and an OMS cooperating unit 411.
  • the billing log parsing unit 401 collects a billing log according to the operation of the Biz template in the business logic processing block 200, verifies the collected billing log, and operates a process for standardizing the verified billing log.
  • the billing log parsing unit 401 is in charge of interfacing for billing log transmission between the business logic processing block 200 and the billing processing unit 400 according to the present embodiment.
  • the billing log parsing unit 401 checks whether the billing log data by the operation of the Biz template recorded in a specific message queue exists in the business logic processing block 200. When the billing log data exists, the billing log parsing unit 401 collects the billing log.
  • the billing log parsing unit 401 may further include a collecting unit for collecting the contents provided in the CP/SP system 11 or the billing log for the user.
  • the billing log parsing unit 401 reads the billing log collected according to the Biz template, the contents or each user on the basis of line unit.
  • the billing log parsing unit 401 divides the billing log, verifies each billing log, transforms the billing logs into a standardized log format and records the transformed billing logs in the billing policy DB 405.
  • the billing policy DB 405 stores a plurality of billing policies and billing data whose billing is processed.
  • the billing policy DB 405 stores data for the billing process by the open mobile business supporting system according to the present embodiment.
  • the billing policy includes billing policies on a billing process for each case, a prepayment billing process, an event billing process, and a Biz template billing process.
  • the billing policy unit 402 checks a billing policy to be applied to the standardized billing log in the billing policy DB 405. Subsequently, the billing policy unit 402 applies the checked billing policy to the billing log and creates billing data whose billing is processed.
  • the billing policy unit 402 includes an interface with the infra channel providing unit 300, which cooperates with the legacy system 30 in the inside of the mobile communication system 13. Also, the billing policy unit 402 may further include an authenticating unit (not shown) for performing a user authentication process corresponding to the billing log.
  • the billing policy unit 402 includes a log receiver 41, a log filter 42 and a billing processor 43.
  • the log receiver 41 receives the billing log standardized in the billing log parsing unit 401 and performs a billing preprocess on a non-processed billing log.
  • the log filter 42 filters a duplicated billing log of the collected billing log and transmits each of the filtered billing log to a billing process table for the billing process.
  • the billing processor 43 applies each billing policy to each billing log transmitted to the billing process table, operates a billing process and creates billing data.
  • the billing file creating unit 403 creates a billing file MDR to be transmitted to the billing legacy system 11 of the mobile communication system 13 based on the billing data whose billing is processed.
  • the billing file MDR is a file format, which is a readable file for the billing process in the billing legacy system 11.
  • the billing file creating unit 403 collects the billing data whose billing is processed and creates the billing file MDR in conformity to an FTP communications protocol.
  • the billing file transmitting unit 404 transmits the created billing file MDR to the billing legacy system 11. It is preferable that the billing file transmitting unit 404 transmits the billing file MDR to the billing legacy system 11 based on the FTP.
  • the billing processing unit 400 can realize real-time billing process, exact billing process and transmission according to the operation of the biz logic of the CP/SP system 11, which is a client requiring a service of the open mobile business supporting system. Accordingly, it is not required to process billing by cooperating with each module to support diverse kinds of billing patterns in a conventional method. Since the billing processing unit 400 collects a billing log and applies a corresponding billing policy, it is possible to minimize cooperation of each module in the billing process.
  • the billing processing unit 400 of FIG. 27 may further include the pre-payment pre-subtraction billing processing block 406, the DB managing unit 407, the configuration managing unit 408, the log managing unit 409, the policy managing unit 410, and the OMS cooperating unit 411.
  • the pre-payment pre-subtraction billing processing block 406 receives a prepayment pre-subtraction billing process request of a specific billing log from the business logic processing block 100. Subsequently, the pre-payment pre-subtraction billing processing block 406 requests a pre-payment pre-subtraction billing process to the pre-payment pre-subtraction billing legacy system 420 for performing the prepayment pre-subtraction billing process. The pre-payment pre-subtraction billing processing block 406 receives and returns a result.
  • the billing log parsing unit 401 verifies a specific billing log to which the pre-payment pre- subtraction billing process is requested. Also, the billing log parsing unit 401 performs a standardization process on the billing log transmitted from the pre-payment pre- subtraction billing processing block 406.
  • the pre-payment pre-subtraction billing processing block 406 includes an interface for cooperating with the business logic processing block 200 and the prepayment pre-subtraction billing legacy system 420.
  • the pre-payment pre- subtraction billing processing block 406 cooperates with the pre-payment pre- subtraction billing legacy system 420 based on the TCP.
  • the DB managing unit 407 cooperates with a pre-setup database and performs an access process from the billing process device to the database, and access management and release processes.
  • the configuration managing unit 408 provides an access function to an environment setup file of the billing processing unit 400 and manages configuration information on the billing processing unit 400.
  • the configuration managing unit 408 checks and manages a setup file commonly used in the billing processing unit 400 and a unique setup file.
  • the log managing unit 409 manages a common log format of the billing processing unit 400. Also, the log managing unit 409 manages creation and record of a system log, and a processed log file.
  • the policy managing unit 410 registers, corrects, or deletes a billing policy including a billing information synchronization process on the Biz template and the contents, an event management process, a billing verification process, a billing policy synchronization process, backup of a billing policy in a pre-set up repository 52.
  • the policy managing unit 410 reads the billing policy in the repository 52 and responds to the request.
  • the OMS cooperating unit 411 collects, transmits and manages data for operating and managing the billing processing unit 400 managed in the OMS 700 by cooperating with the OMS 700.
  • FIG. 29 is a flowchart illustrating a method of billing process according to an embodiment of the present invention.
  • a billing process of a billing processing unit 400 will be described with reference the FIG. 29.
  • the billing log parser 401 collects billing log according to the biz template perform at the business logic processing unit 200 at step S2300.
  • the billing log parser 401 collects billing log through cooperating with the business logic processing unit 200 and a message queue. That is, the billing log parser 401 determines whether the billing log data is recorded in a predetermined message queue by the business logic processing unit 200. If the billing log data is present in the message queue, the billing log data is read.
  • billing log for contents provided from the CP/SP system 11 or a user may be collected.
  • FIG. 30 shows a procedure of applying the billing policy.
  • a connection to a billing policy DB 405 is requested at step S2402. If the billing policy DB 405 is successfully connected at step S2404, a billing policy to apply to the collected billing log is inquired from the billing policy DB 405 at step S2406. No billing policy is present in the billing policy DB at step S2408, an error log is recorded at step S2416. If the proper billing policy is resent, billing data is created by applying the billing policy to the collected billing log at steps S2410 and S2412. Then, the connected to the billing policy DB 405 is terminated at step S2414.
  • a billing file MDR is created by collecting the billing data to transmit the billing file MDR to the billing legacy system 30 of the mobile communication system 13 at steps S2310 and S2312.
  • the billing file MDR has a format that can be recognized by the billing legacy system.
  • the billing file is created to be suitable to FTP.
  • the created billing file (MDR) is transmitted to the billing legacy system 11 using FTP at step S2314.
  • the billing processing unit 400 performs a prepay and pre- subtracting billing process corresponding to the request by cooperating with a prepay and pre- subtracting legacy system 420.
  • FIG. 31 is a flowchart illustrating a prepay and pre- subtracting process performed in the billing processing unit 400.
  • the billing processing unit 400 receives a request of performing a prepay and pre- subtracting billing process from the business logic processing unit 200 at step S2500. Then, the validity of billing log is verified at step S2502. If the billing log is not valid at step S2504, an error log is recorded at step S2506. If the billing log is valid at step S2504, it requests to connect to the prepay and pre- subtracting billing legacy system 420 at step S2508.
  • step S2506 If the connection is successfully established at step S2510, the prepay and pre- sub trading process is requested and the result thereof is returned at steps S2512 and S2514.
  • the connection to the prepay and pre-sub trading legacy system 11 is terminated at step S2516, the prepay and pre-subtracting processed billing log is standardized, and a billing process is performed at steps S2518 and S2520.
  • FIG. 32 is a flowchart illustrating a procedure of processing and managing billing data in a billing processing unit 32 according to an exemplary embodiment of the present invention.
  • a billing policy is registered, modified, and deleted to/from a predetermined repository DB 1000 at step S2600.
  • the billing policy is returned at step S2604.
  • common log format, system log creation, and record, and processed log file management are performed at step S2606.
  • common setup file and a unique setup file inquiry are performed at step S2608.
  • data is collected and managed for operating and managing at step S2610.
  • log data and statistic data for performing biz template and error thereof are generated and stored in the OMS 700 at steps S2612 and S2614).
  • Each process in FIG. 32 can be performed independently according to needs.
  • FIG. 33 is a block diagram illustrating the infra channel providing unit 300.
  • the infra channel providing unit 300 includes an API processing unit 301, a gateway unit 302, an on-line inquiry unit 303, and a log uploading unit 304.
  • the API processing unit 301 provides an execution parameter of a biz object for a legacy system 30, processing input and output parameters for executing a biz object, transfers the input parameter to the gateway unit 302, and transfers the results, the output parameter, to the legacy system 30 that performs the request of the biz object.
  • the gateway unit 302 performs the requested biz object using the input parameter transferred from the API processing unit 301, thereby transferring a cooperation request to a legacy cooperation processing unit 500.
  • the gateway unit 302 also request a cooperation request to the legacy cooperation processing unit 500, receives the result thereof, and transfers the received result to the API processing unit 301. Furthermore, the on-line inquiry unit 303 provides the environmental setup value of the gateway unit 302 to a web service providing unit 600. The log uploading unit 304 provides the log of the infra channel providing unit 300 to an OMS 700, regularly.
  • the gateway unit 302 includes an interface unit 305, a message relay unit 306, a
  • the interface unit 305 provides an input/output interface to the API processing unit 301.
  • the interface unit 305 includes a transmitting/receiving module 305a for receiving a biz object request from the API processing unit 301 and transferring a processing result to the API processing unit 301, an authentication managing module 305b for processing a user right authentication of a legacy system 30 accessing the API processing unit 301, a session managing module 305c for creating and managing a unique session key for an authenticated request from the authentication managing module 305b, a thread managing module 305d for supporting a multi-thread process to process the authenticated request from the authentication managing module 305b.
  • the message relay unit 306 relays a message for requesting.
  • the message relay unit 306 includes a request relay module 306a for analyzing an API requested from the interface unit 305 and relaying a message from a message transferring unit 800, and a message composing module 306b for parsing a parameter transferred from the API processing unit 301 to a format to transfer to the message transferring unit 800.
  • the MQ managing unit 307 supports a MQ cooperation protocol.
  • the first transmission module 307a transmits a message to the legacy system 30 by cooperating with the legacy cooperation processing unit 500 through the message transferring unit 800.
  • the second transmission module 307b transfers a message to the billing processing unit through the message transferring unit 800 for billing log.
  • the receiving module 307c receives a message from the legacy cooperation processing unit 500 and the billing processing unit 400 through the message transferring unit 800.
  • the configuration managing unit 308 manages environmental setting such as a log generation period and a system environment of the infra channel providing unit 300.
  • the log managing unit 309 creates a log file of the infra channel providing unit 300, and creates a monitoring data log to be transmitted to the OMS 700.
  • the OMS managing unit 310 transmits monitoring data stored as a file format by the log managing unit 309 to the OMS 700 at a regular period .
  • the DB managing unit 311 records or read data by performing access and transaction to the MMDB 900.
  • the log managing unit 309 does not directly access the OMS 700 for system performance.
  • FIG. 34 is a block diagram illustrating a cooperating structure of the infra channel providing unit 300.
  • the API processing unit 301 is connected to the legacy system 30 through a TCP/IP protocol.
  • the infra channel providing unit 300 exchanges a message with a legacy cooperating unit 43 and the billing processing unit 400 through the message transferring unit 800 using the MQ cooperating protocol.
  • the infra channel providing unit 300 and the OMS 70 are connected through an ODBC and a FTP.
  • the infra channel providing unit 300 is connected to the web service unit 48 and the ODBC.
  • a TCP/IP socket protocol is used between the API processing unit 301 and the gateway unit 302.
  • a message queue is used to transfer a message between the gateway unit 302 and the other constitutional elements of the open mobile business supporting system such as the legacy cooperation processing unit 500 and the billing processing unit 400. Furthermore, it does not require additional cooperation interface with the legacy system 30.
  • the API processing unit 301 supports various platforms such as NT, SUN, IBM,
  • the infra channel providing unit 300 builds an infra integrated structure of a standardized communication channel to the legacy system 30, supports various platforms and development languages to allow related services to be used on Web, guarantees the connection reliability between a synchronous TCP/IP socket scheme and an asynchronous MQ communication scheme, and perform quick function of a biz object unit.
  • the API processing unit 301 provides a common library type
  • the API processing unit 310 takes a charge of a client part in socket communication.
  • the API processing unit 310 determines whether the biz object is present or not at step S2902. If not, an error code is transmitted to the corresponding legacy system 30 at step S2903. If the biz object is present, the socket communication with the gateway unit 302 is prepared at step S2904.
  • the gateway unit 302 transmits an objectID, an API authentication key ob- jectAuthKey, an IP address of infra channel providing unit, a port number portNo, an input parameter set inSet , and an output parameter set of a result of executing a biz object at S2910.
  • the received result value is returned to the legacy system 30 that request the corresponding biz object to execute at step S2913.
  • FIG. 36 if the legacy system 30 request a biz object to execute at step S 3001, parameters for executing the biz object are transmitted to the infra channel providing unit 300 at step S3002.
  • the API processing unit 301 of the infra channel providing unit 300 receives the parameters such as an objectID, an ob- jectAuthKey, an ipAddr, a portNo, an inSet, and an outset to the gateway unit 302 through socket communication at step S3003.
  • the authentication managing module 305b of the gateway unit 302 authenticates whether a corresponding legacy system 30 has an API usage right or not based on the objectAuthKey among the parameters at step S3004. If the legacy system does not have the API usage right at step S3005, it transmits a message of authentication failure to the legacy system 30 and the legacy system 30 receives the message at steps S3006 and S3007.
  • the session managing module 305c creates a unique session key for the request at step S3009, and the thread managing module 305d creates threads for performing the request at step S3010.
  • the message composing module 306b When the message composing module 306b receives the parameters through the created thread, the message composing module 306b composes a request message to transmit to the message transferring unit 800 by parsing the received parameters at step S3012.
  • the first transmission module 307a of the MQ managing unit 307 recodes the created request message in an assigned message queue for the legacy cooperation processing unit to receive the generated request message at steps S3013 and S3014.
  • a corresponding legacy cooperation processing unit 500 reads the message recorded in the message transferring unit 800, processes a biz object according to the request message, and records the result thereof into a message queen of the message transferring unit 800 so that the infra channel providing unit 300 receives the result thereof at steps S3015 to S3017.
  • the receiving module 307c of the infra channel providing unit 300 receive the result message at step S818. Afterward, the message relay unit 306 analyzes the received messages, detects the execution result of the biz object, and transmits the result thereof to the legacy system 30 that requests the execution of the biz object through the API processing unit 301 at step S3020. At the ending time of executing the biz object, a log is stored at step S3021.
  • the infra channel providing unit provides an unified cooperation rule between the legacy systems 30 by relaying the use of the legacy system 30 for a biz object that embodies a unit function per a legacy system 30.
  • the session managing module 305c analyzes the session information of the currently executing biz object, determines whether the biz object is successfully processed or not, create billing data if it is successfully processed, composes a billing message through the message relay unit 306b, and transmits the billing message to the message transferring unit 800 through the second transmission module 307b of the MQ managing unit 307 so that the billing processing unit 400 receives the transmitted billing message. Then, the session managing module 305c receives a result message of processing the billing data from the billing processing unit 400 using the receiving module 307c and stores the received result message at a billing data log. Therefore, in the present embodiment, proper billing data is collected and processed whenever a biz object is executed.
  • the log managing unit 309 of the infra channel providing unit 300 creates a log file for the infra channel providing unit 300 and a monitoring data log to be transmitted to the OMS 700. That is, the log managing unit 309 selects files to send from the created log files or a report log DB. Then, the log uploading unit 304 transmits the selected log files to the OMS 700 through a FTP by regularly requesting to the OMS 700 for FTP access. When the log uploading unit 304 receives a response for receiving a log file from the OMS 700, the log uploading unit 304 determines that the corresponding log file is successfully transmitted, releases the FTP access, and deletes the transmitted log files.
  • the infra channel providing unit 300 helps the OMS 700 to manage the log information of the infra channel providing unit by regularly transmitting the log file and the report log file of system to the OMS 700.
  • the log managing unit 309 creates debugging information, malfunctioning information, system operation information generated from each module of the infra channel providing unit 300 as logs and stores the created logs in a system log file.
  • the log managing unit 309 loads a log environment file, reflects modified setup values to the environment file if the environmental setup values are modified, or sustains the environment file as it is if the environmental setup values are not modified. Then, the log managing unit 309 checks a rotate period.
  • the log managing unit rotates the log file to create new log file for debugging information, malfunction information, and system operation information of the infra channel providing unit 300 to create the new log file, creates logs of each level based on the new log file, and stores the created logs and files at the system log file.
  • the configuration information modified by a manager is updated to control threads in the infra channel providing unit 300 in real time.
  • the configuration managing unit 308 of the infra channel providing unit 300 loads a configuration file of a currently setup system, determines whether the configuration information is modified or not, and applies the modified configuration to the infra channel providing unit 300 in real time if the modification is made. Furthermore, the configuration managing unit 308 determines whether a tread environment is modified or not, the configuration managing unit 308 performs thread control if the thread environment is modified.
  • the on-line inquiry unit 303 When the on-line inquiry unit 303 receives an inquiry request message from the web service providing unit 600, the on-line inquiry unit 303 loads a configuration file managed by the configuration managing unit 308, parses inquiry lists, composes a result message, and the result message to the web service providing unit 600. [286]
  • the OMS managing unit 60 of the infra channel providing unit 300 regularly loads a log file generated from the log managing unit 309, extracts access information, directly accesses the DB of the OMS 700, and transmits the monitoring statistical data to the OMS 700.
  • FIG. 37 is a block diagram illustrating a structure of a legacy cooperation processing unit 500 in a mobile business supporting system according to an embodiment of the present invention.
  • the legacy cooperation processing unit 500 includes a common managing unit 510 and a legacy cooperating interface unit 520.
  • the common managing unit 510 receives a cooperation request for performing the biz template from the business logic processing unit 200 and returns the result of processing the received request to the business logic processing unit 200.
  • the common managing unit 510 also manages the system environment and the log thereof.
  • the cooperation request of legacy system 30 is that the legacy cooperation processing unit 500 requests the legacy system 30 to perform a biz object so as to perform a biz template at the business logic processing unit 200.
  • the legacy system 30 performs related services such as SMS transmission, MMS transmission, position data inquiry, and user data inquiry, and provides the result thereof such as message transmission completion, position data, or user data.
  • the legacy cooperation interface unit 520 includes, for example, a SMS interface
  • the legacy cooperation interface unit 520 further includes a push interface 525 and a download interface 526. According to the type, function and system environment of business log to be supported, various legacy cooperation interfaces may be added for cooperating with the legacy system 30.
  • the legacy cooperation interface unit 520 relays the cooperation request for performing the biz template from the legacy system 30 and returns the result thereof to the legacy system 30.
  • the SMS interface 521 cooperates with a MASS that is located at the legacy system
  • the SMS interface 521 requests the MASS to transmit a SMS message, receives information about the result thereof such as message transmission completion or message read, and transforms the received information to a standard interface type.
  • the MMS interface 522 cooperates with a MMSC that is located at the legacy system 30 and performs a MMS service of a wireless communication system.
  • the SMS interface 521 requests the MMSC to transmit a MMS message, receives information about the result thereof such as message transmission completion or message read, and transforms the received information to a standard interface type.
  • the LBS interface 523 cooperates with a LBSP that is located at the legacy system 30 and performs a position based service of a wireless communication system.
  • the LBS interface 523 transfers a position related request such as position information inquiry to the corresponding LBSP, and transforms the result of processing the position related request to a standard interface type.
  • the authentication interface 524 cooperates an authentication system that is located in the legacy system 30 and authenticates a wireless communication system.
  • the authentication interface 524 requests a corresponding authentication system to perform an authentication process and transforms the result of performing the authentication process to a standard interface type.
  • the push interface 525 performs a push type message transmission service by cooperating with the MASS 32 and the CBCS 35 of a legacy system 30, and transforms the result thereof to a standard interface type.
  • the download interface 526 performs a download service of image, music, and text by cooperating with a download platform of the legacy system 30, and transforms the result thereof to the standard interface.
  • the legacy cooperation interface unit 520 is described to include these interfaces in the present embodiment. However, the interfaces of the legacy cooperation processing unit 500 may vary according to the legacy system 30 and the related biz objects.
  • the common managing unit 510 receives a request message of the legacy system 30, which is required for performing the biz template, from the business logic processing unit 200 through the message transferring unit 800 formed as a message queue, the common managing unit 510 transfers the request to the legacy cooperation interface unit 520. Then, the legacy cooperation interface unit 520 transforms the request to a format proper to the legacy system through protocol transformation and transmits the transformed request to a corresponding legacy system 30.
  • the legacy system 30 performs predetermined operations related to the received request such as SMS transmission, MMS transmission, position data inquiry, or user data inquiry, and transmits the result thereof such as message transmission completion, message read, position data, or user data to the legacy cooperation interface unit 520.
  • the legacy cooperation interface unit 520 transforms the received results to a standard output message format of a legacy system cooperation result, and transfers the transformed output message to the common managing unit 510.
  • the common managing unit 510 returns the processing result to the business logic processing unit 200 or to the infra channel providing unit 300 through the message transferring unit 800.
  • FIG. 38 is a block diagram illustrating the common managing unit 510 in the legacy cooperation processing unit 500.
  • the common managing unit 510 includes a MQ managing unit 511, a configuration managing unit 512, a log managing unit 514, a log uploader 516, and a DB interface 517.
  • the MQ managing unit 511 includes a MQ receiver 511a and a MQ transmitter
  • the MQ receiver 51 Ia is a module for processing messages received from the message transferring unit 800, that is, a message queue.
  • the MQ receiver 511a stores request information from the business logic processing unit 200 or the infra channel providing unit 300 through the message transferring unit 800 into a database or transforms the received message to a legacy format.
  • the MQ transmitter 51 Ib transmits the processing result of the legacy system 30 to the business logic processing unit 200 or the infra channel providing unit 300 through the message transferring unit 800, and supports a protocol process for cooperating with a message queue.
  • the configuration managing unit 512 manages a system environment or environmental setups such as a log create cycle for each constitutional element of the legacy cooperation processing unit 500, and stores the state information of the system environment as a configuration file 513.
  • the configuration managing unit 512 manages the configuration files to reflect the changes thereof into the configuration files through re-driving the legacy cooperation processing unit 500 when the configuration file is modified, or to instantly reflect in real time without re-driving. That is, the configuration managing unit 512 manages changes of each constitutional element for the legacy cooperation processing unit 500 using the configuration file 513 and sets up an execution environment by reading the configuration file 513 in real time when the system is driven.
  • a configuration data value is inquired by receiving a KEY value from a program or a module requesting the configuration information.
  • the configuration information is frequently modified, deleted, or inputted by directly accessing the configuration file 513.
  • the configuration managing unit 512 reflects the real-time modified configuration information to the current legacy cooperation processing unit 500, and provides the reflected configuration information to programs and modules.
  • the log managing unit 514 generalizes a log format of each log level in each constitutional module of the legacy cooperation processing unit 500, and creates a system log based on a log format and a log level assigned from each constitutional module. Such log information is stored in the log file 515.
  • the log creation is to create logs for debugging information, malfunctioning information, and system operation information, which are generated from each module, and stores the created log into the system log file 515.
  • the log level can be setup according to the system environment. For example, various log levels such as an error level, an information providing level, a warning level, or a debug level can be setup according to the related environment. When the log is requested, the log is created according to the related log levels set up according to the related environment.
  • the log managing unit 514 receive log data transmitted from each constitutional module of the legacy cooperation processing unit 500, transforms the received log data to a format suitable to output it to the log file 515, opens a log file 515 according to each constitutional module and conditions thereof, and records the log data to the opened log file 151.
  • the log uploader 516 regularly searches the system log of the legacy cooperation processing unit 500 and uploads the searched system log to the OMS 700 using FTP.
  • the log uploader 516 regularly searches the log file 515 of the legacy cooperation processing unit 500, requests the OMS 700 to FTP access, and uploads the log file 515 if it successfully access.
  • the DB interface 517 provides an interface to the legacy cooperation interface unit
  • the legacy integrated DB server 530 stores and manages session information about message transmission state, transmission result for asynchronous messaging process when the legacy system 30 transmits or receives a message.
  • FIG. 39 is a block diagram illustrating a SMS interface 521 in a legacy cooperation processing unit 500.
  • the SMS interface 521 includes a SMS service listener 521-1, a session manager 521-2, a MASS request manager 521-3, a MASS response manager 521-4, and a SMS response manager 521-5.
  • the SMS service listener 521-1 receives the legacy system cooperation request transferred from the MQ receiver 51 Ia of the MQ managing unit 511, and registers the requests in the legacy integrated DB server 530.
  • the legacy system cooperation request is a request of cooperating for the MASS 32 which is a wireless Internet SMS transmission system.
  • the SMS session manager 521-2 receives a SMS transmission request of the MQ receiver 511a from the legacy integrated DB server 530, and proves the received request to the MASS request manager 521-3.
  • the SMS session manager 521-2 requests the session states such as service request or the result thereof to the legacy integrated DB server 530.
  • the MASS request manager 521-3 also requests the MASS 32 to perform a SMS messaging service.
  • the MASS response manager 521-4 receives a processing result such as message transmission completed or message read from the MASS 32 after the MASS 32 transmit the SMS message.
  • the SMS response message 521-5 receives a MASS cooperation result information from the MASS response manager 521-4 and registers the received information at the legacy integrated DB server 530. Then, the SMS service listener 521-1 obtains the results from the legacy integrated DB server 530, and transfers the obtained result to the MQ transmitter 51 Ib of the MQ managing unit 511.
  • the MQ transmitter 511b provides the request processing result of the business logic processing unit 200 and the infra channel providing unit 300 by recording the request processing result to an assigned message queue.
  • FIG. 40 is a block diagram illustrating a MMS interface 522 in a legacy cooperation processing unit 500 according to an embodiment of the present invention.
  • the MMS interface 522 includes a MMS Service Listener
  • a protocol stack module 522-2 a file data manager 522-3, a session manager 522-4, a MM7 interface 522-5, a MMS reporter 522-7 ', and a legacy interface 522-6.
  • the MMS service listener 522-1 receives a legacy system cooperation request from the MQ receiver 51 Ia of the MQ managing unit 511 and resisters the received request at the legacy integrated DB server 530.
  • the cooperation request from the business logic processing unit 200 to process a MMS message is belonging to a cooperation request for a MMSC 33 that takes a charge of transmitting a MMS message.
  • the protocol stack module 522-2 processes protocols, such as HTTP, SMTP,
  • MIME MIME, DIME, and SOAP, for transforming a message to a predetermined format to cooperate with the MMSC.
  • the file data manager 522-3 receives reference data including the MMSC cooperation request message, and performs a function to receiving a MMS message by cooperating with a file server (not shown) having the real MMS message contents.
  • the session manager 522-4 receives a MMSC cooperation request message, which is transferred from the MQ receiver 511a, from the legacy integrated DB server 530, and relays the received MMC cooperation request message to the MM7 interface 522-5.
  • the MM7 interface 522-5 transforms the MMSC cooperation request message transferred from the session manager 522-4 to a format suitable to MM7 that is a MMSC cooperation protocol, and transmits it the legacy interface 522-6.
  • the legacy interface 522-6 requests a MMS messaging service such as MMS message transmission by cooperating with the MMSC 33 according to the legacy system cooperation request, and receives the service processing result from the MMSC.
  • the MMS reporter 522-7 receives a cooperation processing result from the MMSC 33 through the legacy interface 522-6, and provides the received cooperation processing result to the legacy integrated DB server 530 through the DB interface 517. As described above, The MMS reporter 522-7 stores the cooperation processing result to the legacy integrated DB server 530, and the MMS service listener 147-1 provides the cooperation processing result to the business logic processing unit 200 or the infra channel providing unit 300 through the MQ managing unit 511. For example, when the business logic processing unit 200 requests the MMS message transmission, the MMS reporter 522-7 receives information about whether a real phone user receives the MMS message from the legacy system 30or not, stores information at legacy integrated DB server 530, and manages the stored information.
  • the business logic processing unit 200 is enabled to charge a fee for transmitting a corresponding MMS message. That is, the MMS reporter 522-7 receives information about whether a MMS message is received or not from the MMSC through a SOAP type message, extracts required data from the SOAP type message by analyzing the SOAP type message, and determines whether the extracted data is valid or not, thereby finely analyzing the report information. Also, the MMS reporter 522-7 transfers the information whether the report information is received or not to the MMSC, and updates the report information to the database.
  • the MMS reporter 522-7 transforms the report result information to the MQ type message in order to transmit the report result information to the business logic processing unit 200 through the message relay unit 30. Furthermore, the MMS reporter 522-7 registers the received result received from the MMSC at the legacy integrated DB server 530.
  • the MMS service listener 522-1 obtains the service result from the legacy integrated DB server 530, and transfers the obtained service result to the MQ transmitter 51 Ib in the MQ managing unit 511, thereby allowing the MMSC cooperation result to be provided to the business logic processing unit 200.
  • a biz template for the MMS messaging service includes a biz object ® for inquiring I-type user information, a biz object ⁇ for checking P-type user information, a biz object ⁇ for checking whether a P-type terminal is supported or not, and a biz object ® for transmitting I-type MMS.
  • the business logic processing unit 200 inquires user information and authenticates the request by requesting authentication related legacy systems to be cooperated.
  • the business logic processing unit 200 checks the user information included in the processing result thereof. If the user information is not proper, the business logic processing unit 200 returns authenticating failure as the processing result. If the user information is proper, the business logic processing unit 200 requests a legacy system for managing terminals to be cooperated to check the terminal information. Then, the business logic processing unit 200 transmits corresponding message by requesting the MMSC to cooperate.
  • FIG. 42 is a block diagram illustrating a LBS interface of a legacy cooperation processing unit 500 according to an embodiment of the present invention.
  • the LBS interface 523 includes a LBS service listener 523-1, an extensible markup language (XML) generator 523-2, a legacy interface 523-3, and a XML parser 523-4.
  • XML extensible markup language
  • the LBS service listener 523-1 receives a legacy system cooperation request from the business logic processing unit 200 through the MQ receiver 51 Ia of the MQ managing unit 511, and transmits the processing result of the cooperation request to the business logic processing unit 200 through the MQ transmitter 51 Ib.
  • the legacy system cooperation request transferred from the business logic processing unit 200 belongs to a cooperation request for a LBSP that processes the information of location-based services (LBS).
  • FIG. 43 is a diagram illustrating a biz template for inquiring position information, as an example of a location based service (LBS) related biz template.
  • the biz template is for inquiring a position of a predetermined portable phone.
  • the biz template includes a biz object ® for inquiring I-type user information, a biz object ® for checking P-type user information, and a biz object ⁇ for inquiring a I-type LBS position.
  • the business logic processing unit 200 inquires the user information by requesting a user related legacy system to cooperate. Then, the business logic processing unit 200 determines whether the service can be provided or not by checking the user information using the inquired information. If it is impossible to provide, the business logic processing unit 200 returns a failure message as the processing result. If it is possible, the business logic processing unit 200 request the LBSP 34 to cooperate through the legacy cooperation processing unit 500, thereby inquiring the position information thereof.
  • the XML generator 523-2 of FIG. 42 receives the legacy system cooperation request message from the the business logic processing unit 200 through the MQ managing unit 511, and transforms the received message to a XML sentence to be suitable to the LBSP 34.
  • the legacy interface 523-3 requests position information inquiry by cooperating with the LBSP 34 that processing LBS information for tracking, and receives the result of the position inquiry.
  • the XML parser 523-4 analyzes the XML processing result from the legacy interface 523-3, and the interpreting result to the LBS service listener 523-1.
  • the LBS service listener 523-1 transfers the result of inquiring the position thereof to the MQ transmitter 131-2 of the MQ manager 131 so as to transfer the position inquiry result to the business logic processing unit 200.
  • FIG. 44 is a flowchart illustrating a method of performing a LBS related service using a legacy cooperation processing unit 500 having a LBS interface 523 according to an embodiment of the present invention.
  • the legacy cooperation processing unit 26 having the LBS interface 523 receives a request to cooperate with the LBSP 34 of the legacy system 30 from the business logic processing unit 200 for position inquiry and messages related to request of setting up environment through a message queue of the message transferring unit 800at step S3801. Then, the legacy cooperation processing unit 26 inspects the validity of the received messages such as the received LBSP cooperation request and the environment setting up message at step S3802.
  • the parameters of the LBS service requesting message are stored in assigned buffers according to corresponding request types at step S3804.
  • step S3806 the generation of the XML file is determined at step S3806. If the XML file is normally created, the TCP/IP connection to the LBSP is established at step S3807.
  • the current session is sustained until a response for LBSP cooperating request, that is, a position inquiry result message having a XML format, from the LBSP.
  • a response for LBSP cooperating request that is, a position inquiry result message having a XML format
  • the XML type response message is received.
  • the checked XML message is parsed using the XML parser 523-4 in order to use the received XML response message in the business logic processing unit 200 at step S3811.
  • the parsed message is transformed to a message format to transmit it the business logic processing unit 200,and the transformed message is transmitted to the business logic processing unit 200 through message queues of the message transferring unit 800. That is, the position inquiry result is transmitted to the business logic processing unit 200 at step S1613, and a related result is recorded at the log file 515 at step S3814.
  • log information according to the determination is recorded in the log file 515 at step S3814.
  • FIG. 45 is a block diagram illustrating a push interface according to an embodiment of the present invention.
  • the push interface 525 includes a push service setup manager 525-1, a contents transmitter 525-2, and a legacy interface 525-3.
  • the push service setup manager 525-1 manages connection information received from the CP/SP system 21 through the common managing unit 510 and service registration/ release information form a mobile communication terminal 14.
  • the contents transmitter 525-2 manages contents and messages received through the MQ managing unit 511 and controls a transmission scheme of the contents and a transmission time.
  • the legacy interface 525-3 transmits a message to a legacy system performing a SMS service, a MASS 32, a legacy system performing a cell broadcasting service, or the CBSC 35 through a push method, and receives the processing result thereof.
  • the push interface 525 cooperates with a legacy system. That is, the push interface
  • CBSC cell broadcasting service center
  • SMSC short message service center
  • a billing process for the push service is performed as a monthly flat rate. Therefore, billing data for the push service is created, and the billing processing unit 400 of the open mobile business supporting system processes the created billing data.
  • the push service setup manager 525-1 stores such information. Also, the contents transmitter 525-2 receives data for a push service, that is, contents or data, from the CP/SP system 11 through the open interface processing unit 100 and the business logic processing unit 200, and manages the received data for the push service.
  • the contents transmitter 525-2 transmits the stored contents or data to the legacy system 30 with reference to the push service setup manager 525-1 so as to allow a user's mobile communication terminal 14 to receive the contents.
  • the message transmission can be performed through a legacy system performing a cell broadcasting service, the CBBC 35, a legacy system performing a SMS service, or the SMSC 32.
  • An application program interface (API) supported by the open mobile business system having the push interface 525 for performing the push service includes a push service connection and a user authentication API, a SMS based message transmission API, and a CBS based message transmission API.
  • the push service connection and user authentication API is provided by a function invoke_API that requests a push agent service device to perform the connection and user authentication process through parameters. If this API is requested, a connection process and a user authentication process are performed to use the push service of the CP/SP system 21 and the results thereof can be obtained.
  • the parameters of the push service connection and user authentication API includes a template ID for push service connection and user authentication, an authentication key assigned from the CP/SP system 21 requesting the push service connection and user authentication, input parameters used for push service connection and user authentication, and output parameters for transmitting the processing result.
  • the input parameter of the push service connection and user authentication API includes information denoting a request service type, and the output parameter is formed of result codes and result messages of the connection and user authentication.
  • the open interface processing unit of the open mobile business supporting system receives the request and transfers the request to the business logic processing unit 200.
  • the business logic processing unit 200 performs a biz template embodying logic for processing the push service connection and user authentication.
  • the authentication for CP/SP and the user authentication for a receiver of push information are performed. If the authentication is successful, the input parameter with the service connection and user authentication request is transmitted to the legacy cooperation processing unit 500. It is transferred to the push service setup manager 525-1 of the push interface 525 through the MQ manager 511 of the push agent service device, thereby registering it to the push service setup manager 525-1.
  • the registration result is transferred to the corresponding CP/SP system 11 through the business logic processing unit 200 and the open interface processing unit 100.
  • the SMS based message transmission API is provided by a function invoke_API that requests a SMSC performing a SMS to transmit push information. If the API is requested, a process of transmitting a push message using SMS is performed. Then, the result of message transmission and message keys used to inquire transmitted message states are returned to the CP/SP system 11.
  • the parameters of the SMS based message transmission API includes a template ID embodied for transmitting message through the SMA based pushing method, an authentication key assigned by the CP/SP system 11 requesting the message transmission using the SMS based push method, an input parameter including a request service type, application program information applying to the push message, push message receiver information, a message priory, push message contents, and a transmission requesting time, a result code that is a returned value, a result message, and an output parameter formed of unique message keys generated in the push agent service device for a push message transmission request.
  • the CP/SP system 11 transmits an ID of a template that requests message transmission using the SMS push method, an authentication key, and an input parameter by calling the SMS based message transmission API.
  • the open interface processing unit 100 of the open mobile business supporting system receives the API call, and transfers the request of performing a template for transmitting a message using a SMS push method to the business logic processing unit 200.
  • the business logic processing unit 200 requests the SMS based push type message transmission to the push agent service device according to the present embodiment by transmitting the received input parameter to the push agent service device through the open interface-processing unit 100.
  • the message- transferring unit 800 is used to transmit the request.
  • the push interface 525 receives the message push service request through the MQ managing unit 511, stores the received request at the content transmitter 525-2, and transmits the message and the receiver information to the SMSC through the legacy interface 525-3 at a transmission time requested by the CP/SP system 11, thereby requesting the message transmission. Then, the push interface 525 receives the response of the message transmission request from the SMSC, and composes a result message formed of a result code that denotes the success of the SMS based push service request, a result message transferred from the SMSC 32, and message keys generated in the push interface 505 for identification based on the response. The push interface 525 transmits the composed result message to the business logic-processing unit 200 through the message-transferring unit 800.
  • the business logic processing unit 200 returns the result thereof to the CP/SP system 11 through the open interface-processing unit 22. Therefore, the CP/SP system 11 can receive the result message that reports whether the request of SMS based push type message transmission successes or not and the result thereof from the open mobile business supporting system. Furthermore, the business logic processing unit 200 receives message keys to identify the requests, thereby managing the states thereof according to the SMS based push type message transmission requests.
  • the CBS based push type message service is an API for performing a push service that transmits push information through a cell broadcasting service (CBS) from a CP/ SP system 11 to an assigned area.
  • the CBS based push type message service is provided by a function invoke_API that requests the CMS based push type message service through parameters.
  • the parameter of the CBS based push type message transmission API includes an
  • a template that processes the CBS based push type message transmission an authentication key of a CP/SP system 11 to use the interface, a requested service type such as a popup service providing information through a popup window or a ticker service providing information through additional window disposed on the bottom section of a displaying area, input parameter formed of application information of a mobile communication terminal to transmit a corresponding message, CBS channel information to transmit a message, information about a location where a message is transmitted to, a message priority, message contents to push, and transmission request times, and an output parameter having a result code denoting whether message transmission successes or not as information for expressing the result of requesting the CBS push service, a result message, and a message key assigned according to the push service request.
  • a requested service type such as a popup service providing information through a popup window or a ticker service providing information through additional window disposed on the bottom section of a displaying area
  • input parameter formed of application information of a mobile communication terminal to transmit a corresponding message CBS channel information to transmit
  • the CBS based push type message transmission API When the CBS based push type message transmission API is called, the input parameter formed of necessary information for the CBS push service with the CBS based push type message transmission request are transferred to the legacy cooperation processing unit 500 through the open interface processing unit 100 and the business logic processing unit 200.
  • the contents transmitter 525-2 creates an unique message key for the request, stores a push message to transmit among the input parameter, transmits a message transmission command to the CBSC 35 to transmit a message at a message transmission request time included in the input parameter, and receives the result thereof.
  • the generated message key, result code, and result message are returned to the business logic processing unit 200.
  • the business logic processing unit 200 returns the received message key, result code and result message to the CP/SP system 11 through the open interface processing unit 100.
  • the download service is a frequently used service, it is preferable to define one business logic by grouping an authentication process, a contents transform and transfer process, a URL transfer process, and a billing process as one business logic, which are performing in a mobile communication system, and to embody a biz template for the defined businesses logic.
  • a download service providing procedure and infra resources of a mobile communication service may change according to whether a download service requester is matched with a download service subject, and whether a wireless communication system of the download service subject is identical to the wireless communication service of the download requester. Therefore, it is preferable to embody a biz template according to a download service.
  • the download service according to the download service requester and the download service subject includes a service of "download to my phone” which downloads selected contents to a user's mobile communication terminal that requests the download service, and a service of "present it to other” which download selected contents to other user rather than a user requesting the download service.
  • the service of "present it to other” can be divided into a service of "present contents to the same mobile communication service provider” and a service of "present contents to the other mobile communication service provider" according to whether the subject who receiving the download service and the download service requester use the same mobile communication service provider or not.
  • FIG. 46 is a block diagram illustrating a structure for providing a download service in an open mobile business supporting system according to an embodiment of the present invention.
  • a download platform 37 of performing a download service of a wireless communication system In order to provide a download service, a download platform 37 of performing a download service of a wireless communication system, an authentication system 36 for performing a user authentication process, and a MASS 31 for performing a SMS service.
  • the legacy cooperation processing unit 500 includes a SMS interface 521 and an authentication interface 524, and a download interface 526 for cooperating with other legacy systems.
  • a gateway connects the wireless communication terminal 14, the CP/SP system 11, and the legacy system 30.
  • the OI processing unit 100 provides an API call specification defined according to the download service type to the CP/SP system 11.
  • the OI processing unit 100 defines a unique session key.
  • the defined session key is used as an identification to provide consistency to operations of the asynchronous business logic processing unit 200 and the legacy cooperation processing unit 500.
  • the OI processing unit 100 provides a call message for a biz template corresponding to the called download service to the business logic processing unit 200, receives the result thereof from the business logic processing unit 200, and provides the received result to the CP/SP system 11 through a standard API.
  • the business logic processing unit 200 When the business logic processing unit 200 receives the call message of a biz template for download service from the OI processing unit 100, the business logic processing unit 200 performs the biz template. While performing the biz template, the business logic processing unit 200 requests the legacy cooperation processing unit 500 to perform a predetermined service if the predetermined resource of a legacy system 30, such as the operations of a download platform, an authentication system, and a MASS, are required, and receives the result thereof. Then, the business logic processing unit 200 collects the result of performing the biz template and the result transferred from the legacy cooperation processing unit 500, and returns the final result of the biz template for download service to the OI processing unit 100.
  • a legacy system 30 such as the operations of a download platform, an authentication system, and a MASS
  • the download interface 526 of the legacy cooperation processing unit 50 is driven and requests the download of corresponding contents while uploading related contents to the download platform 37 of the legacy system 30.
  • the authentication interface 524 of the legacy cooperation processing unit 500 requests the authentication system 36 of the legacy system 30 to authenticate a download requester or a download subject.
  • the SMS interface 521 of the legacy cooperation processing unit 500 requests the MASS 31 to transmit a text message having a callback address.
  • the OI processing unit 100 analyzes the received message, and calls a biz template related to the service of "download to my phone" at step S4103.
  • the business logic processing unit 200 requests the authentication system 36 to authenticate a user through the authentication interface 524 and receives the authentication result according to the flow of the biz template S4105. Then, the business logic processing unit 200 requests the download platform 37 to transmit the predetermined contents through the download interface 526, and the download platform 37 transforms the format of contents and transmits a URL value of the transformed contents at step S4106.
  • the business logic processing unit 200 returns the received URL value to the CP/SP system 11 through the OI processing unit 100 at steps S4107 and S4108.
  • the returned URL includes a session key (Sesskey) to identify a corresponding API call.
  • the CP/SP system 11 transfers the URL having the session key to the browser of the download requester's mobile communication terminal 14 at step S4109.
  • the download requestor confirms the download page URL through the browser of the own mobile communication terminal 14 and selects a request to transmit the download page. Then, the request is transferred to the download platform 37 of the mobile communication system by the displayed URL. The download platform 37 transmits the corresponding contents to the mobile communication terminal 14 at S4110.
  • the CP/SP system 11 calls an API related to the service of "present contents to the other mobile terminal belonging to the same mobile communication system” thereby transmitting the selected contents at step S4202. Then, the OI processing unit 100 analyzes the API call, and calls a biz template (BT) related to the service of "present contents to the other mobile terminal belonging to the same mobile communication system” from the business logic processing unit 200 at step S4203.
  • BT biz template
  • the business logic processing unit 200 requests the authentication system 36 through the authentication interface 524 to authenticate a download requestor and a download subject, and receives the result thereof at step S4204. Then, the business logic processing unit 200 performs format transformation and URL creation by uploading the selected contents to the download platform 37 through the download interface 526, and receives the URL as the response message at step S4205. Then, a message notifying that contents are arrived from a download requester as a present and a call back URL are transmitted to the mobile communication terminal 14 of the download subject through the SMS interface 521 at steps S4206 and S4209.
  • the business logic processing unit 200 confirms the report message from the SMS interface 521, and transfers the call back URL message from the MASS 31 to the mobile communication terminal 14. If the SMS receipt completion report is transferred at step S4210, it determines that the billing condition is satisfied, thereby transmitting the related billing data to the billing processing unit 400 at step S4211.
  • the CP/SP system 11 calls an API related to the service of "present contents to the other mobile terminal belonging to the other mobile communication system” from the OI processing unit 100, and transmits the selected contents at step S4302.
  • the OI processing unit 100 analyzes the API call, and calls a biz template relate to the service of "present contents to the other mobile terminal belonging to the other mobile communication system” to the business logic processing unit 200 at step S4303.
  • the business logic processing unit 200 requests the authentication system 36 through the authentication interface 524 to authenticate a download requestor, and receives the result thereof at step S4304, and uploads the selected contents to the download platform 37 through the download interface 526, thereby requesting the service of "present contents to the other mobile terminal belonging to the other mobile communication system" at step S4305.
  • the download platform 37 transmits the uploaded contents to the other mobile communication system through the cooperation gateway of the other mobile communication system without transforming a format, transfers the download request message, and receives the response thereof from the other company's wireless communication system at step S4306.
  • the download interface 526 After receiving the response from the other company's wireless communication system, the download interface 526 transmits a transmission completion report to the business logic processing unit 200 at step S4307.
  • the business logic processing unit 200 returns a result message of transmission completion to the CP/SP system 11 through the OI processing unit 100 at steps S4308 and S4309.
  • billing data of corresponding download requestor is transmitted to the billing processing unit 400 at step S4310.
  • the open mobile business supporting system supports the download service of the CP/SP system.
  • FIG. 50 is a block diagram illustrating an operating and management system (OMS)
  • the OMS 700 includes a database 710 for storing traffic related data collected by the open mobile business supporting system, and statistical data generated based on the collected traffic related data, a DB manager 720 for managing the database 710 by creating statistical data and service call tracking data based on the stored traffic related data stored in the database 710, storing the created data in the database 710 or deleting the data from the database 710, and a presentation unit 730 for providing an operator interface, receiving requests such as a request of monitoring performance from an operator through the operator interface, reading data corresponding to the received request from the database 710, and providing the read data to the operator.
  • a database 710 for storing traffic related data collected by the open mobile business supporting system, and statistical data generated based on the collected traffic related data
  • a DB manager 720 for managing the database 710 by creating statistical data and service call tracking data based on the stored traffic related data stored in the database 710, storing the created data in the database 710 or deleting the data from the database 710
  • a presentation unit 730 for providing an
  • the database 710 is a device to store information about the performance and the states of low-level systems in the open mobile business supporting system.
  • the database 710 manages various tables including a biz template state information table for recording state information of biz templates, an API parameter information table for recording information about parameters of API defined according to each template in an open interface provided to a CP or a SP, a first session state information table for managing state information per each session performed in an infra channel providing unit, a second session state information table for managing state information per each session of the legacy cooperation processing unit and the billing processing unit, a threshold setup table for recording thresholds for determining performance or malfunction of each low-level system in the open mobile business supporting system, a first response time threshold setup table for setting up response time thresholds per each biz template performed in the open mobile business supporting system, a second response time threshold setup table for setting up response time thresholds per each biz template performed in the open mobile business supporting system, a data collecting time threshold setup table for setting up a threshold for a time for collecting traffic
  • the DB manager 720 includes a log processing module 721 for transforming call tracking data to a predetermined file format, storing the transformed data in the database 710, and deleting the system log, a DB managing module 721 for deleting a transaction log for managing the database 710, a deletion managing module 723 for deleting data with a valid data expired, for example, three months, among statistic data stored in the database 710, a combine managing module 724 for creating statistic data with reference to traffic related data recorded in the database 710 at a predetermined cycle, for example, a day, and a data access module 725 for performing an access function of the database 710 for the modules 721 to 724.
  • the presentation unit 730 includes a management site providing unit 731 for providing a web service based managing graphic user interface to a manager to monitor the open mobile business supporting system and malfunctioning details thereof, to setup thresholds, to track a call and a traffic, and to calculate statistics of used amount, and to manage logs, and a monitoring logic processing unit 732 for reading data corresponding to selected items from a manager through the management site providing unit 731 and proving the read data to the management site providing unit 731.
  • a management site providing unit 731 for providing a web service based managing graphic user interface to a manager to monitor the open mobile business supporting system and malfunctioning details thereof, to setup thresholds, to track a call and a traffic, and to calculate statistics of used amount, and to manage logs
  • a monitoring logic processing unit 732 for reading data corresponding to selected items from a manager through the management site providing unit 731 and proving the read data to the management site providing unit 731.
  • the monitoring logic processing unit 732 includes a statistic inquiry module 733 for extracting used amount statistic data based on entire structure of the open mobile business supporting system, a monitoring structure managing module 734 for setting a threshold for monitoring, a call tracking managing module 735 for providing a call tracking function for a predetermined service call requested through the management site providing unit 731, a group success managing module 736 for providing succession times-traffic graph from the current time to a predetermined past time for example, three hours, six hours, twelve hours, and twenty four hours, a fine monitoring managing module 737 for showing malfunctioning details of each low-level system in the open mobile business supporting system, a monitoring managing module 738 for showing the number of tries, the number of success, a succession rate, and an average response time per each low-level system of the open mobile business supporting system and showing states of each system with reference a predetermined threshold, and a data access module 739 for allowing the modules to fetch necessary data from the database 710 by providing an access function.
  • a statistic inquiry module 733 for extracting used amount statistic
  • the OI processing unit 100, billing processing unit 400, and the legacy cooperation processing unit 500 are cooperated using FTP, and the business logic processing unit 200 and the infra channel providing unit 300 are cooperated and commonly use data through the ODBC open database connectivity.
  • Each of low-level systems in the open mobile business supporting system such as the OI processing unit 100, the business logic processing unit 200, the infra channel providing unit 300, the legacy cooperation processing unit 500, the web service providing unit 600, transmit the generated system logs to the OMS 700 through the above described cooperation structure.
  • the OMS 700 reads the session information of the OI processing unit 100 and the business logic processing unit 200, the session information of the billing processing unit 400, and the session information of the legacy cooperation processing unit 500 from the MMDB 900 at a predetermined period, for example, every five minutes, and stores the read session information into the database 710.
  • the OMS 700 regularly receives the state information of biz template and biz object from the OI processing unit 100 and the business logic processing unit 200, and stores the received state information into the database 710.
  • the OMS 700 regularly receives the session state information from the infra channel providing unit 300, the state information of biz object/template, and parameter information, and stores the received session state information, state information and the parameter information into the database 710.
  • the OMS according to the present embodiment stores only traffic related data in the database 710, and reads basic information related to configuration, performance, and malfunctioning of the open mobile business supporting system from the database of the open mobile business supporting system, the registry DB 1000 in FIG. 15.
  • the system log generated from the low-level device in the open mobile business supporting system is transmitted to a predetermined area of the database 710 through FTP at a predetermined period, thereby allowing the system log to be inquired by sits provided from the presentation unit 730 according to need.
  • the OMS 700 provides a monitoring function for a service call process. That is, the
  • OMS 700 compares performance and malfunctioning data, which is monitoring data collected according to the hardware configuration of the open mobile business supporting system and stored in the database 710, with a threshold value for detecting load increment or operation malfunctioning.
  • performance and malfunctioning data which is monitoring data collected according to the hardware configuration of the open mobile business supporting system and stored in the database 710.
  • the OMS 700 inquires the configuration information of the open mobile business supporting system. Then, the OMS 700 inquires monitoring data corresponding to a setup period for example, five minutes. After inquiry, the OMS 700 compares the threshold value with the inquired monitoring data, and displays the comparison results through a predetermined display unit.
  • the OMS 700 provides a function of inquiring a malfunction state of the open mobile business supporting system.
  • the malfunction state inquiring function provides malfunctioning details of the low-level systems of the open mobile business supporting system to a manager.
  • the OMS 700 determines whether the manager has a right of using the function or not.
  • the OMS 700 loads data that composes a malfunction detail inquiring page by accessing a DB that stores web site information, accesses the database 710 through the data access module 739, reads the configuration information of the open mobile business supporting system and recent monitoring data, for example, monitoring data collected within five minutes, composes a related web page by combining the read data with the malfunction detail inquiring page, and outputs the composed web page through a predetermined display unit.
  • the OMS 700 provides a function of managing thresholds. That is, the OMS 700 provides a threshold managing menu through the managing site providing unit 731. When a manager selects the provided menu, the OMS 700 determines whether the manager has a right to use the provided menu or not. If the manager has the right, the OMS 700 access the database 710 through the data access module 739, reads the threshold values such as threshold values of biz objects, and threshold values of biz templates, and displays the read threshold values through a predetermined display unit. The manager is allowed to change the threshold values outputted through the display. The change threshold values are transferred to the monitoring configuration managing module 734 through the managing sit providing unit 731. The monitoring configuration managing module 734 transfers the changed threshold value to the database 710, and the database 710 stores the changed threshold value.
  • the OMS 700 provides a function of tracking a predetermined service call.
  • OMS 700 provides the service call tracking function through the managing site providing unit 731. If the menu of the service call tracking function is selected by a manager, the OMS 700 authenticates the manager whether the manager has the right of using the selected function or not. If the manager has the right, the OMS 700 connected to the database 710 through the data access module 739 and provides a call tracking search graphic user interface to the manager through a site. When the manger selects a search condition, the OMS 700 read call tracking data from the database 710 according to the search condition and displays the read call tracking data through a predetermined display unit.
  • the OMS 700 provides a function of providing a traffic graph.
  • the OMS 700 authenticates the manager to have the right of using. If the manager has the right, the OMS 700 access the database 710 through the data access module 739, reads traffic data satisfying the conditions set by the manager, modifies the read traffic data as a graph, and outputs the graph through a predetermine display unit.
  • the OMS 700 provides a function of inquiring used amount statistic data.
  • the OMS 700 authenticates the manager to have the right of using. If the manager has the right, the OMS 700 access the database 710 through the data access module 739, reads statistic data satisfying search conditions set by the manager, and displays the read statistic data.
  • the OMS 700 performs a call tracking function through the log processing module
  • the log processing module 721 regularly connects to the database 710 through data access module 725 at a predetermined period, for example, one day.
  • the log processing module 721 read the system log of each service call stored for a predetermined period, for example, for one day, creates a call tracking data file, and stores the created call tracking data file. The created system log is deleted.
  • the OMS 700 of the open mobile business supporting system stably manages traffic related data for the open mobile business supporting system including the OI processing unit 100, the business logic processing unit 200, the infra channel providing unit 300, and the legacy cooperation processing unit 500, processes the traffic related data, and effectively displays the information about the performance and the malfunction state of the open mobile business supporting system based on the processed traffic related data, thereby improving efficiency of supporting open mobile business.
  • FIG. 51 is a block diagram illustrating a web service providing unit in an open mobile business supporting system according to an embodiment of the present invention.
  • the web service providing unit 600 includes a web service unit 610 for providing a web based user interface to a user of the open mobile business supporting system, a logic processing unit 620 for performing a registration operation and an inquiry operation according to the user's request through the web service unit 610, and a DB access processing unit 630 for accessing a repository DB 1000, reading or writing data from/to the repository DB 1000 by the request of the logic processing unit 620.
  • the web service unit 610 includes a first web site 611 for providing a web based user interface to a CP or a SP using a biz template in the open mobile business supporting system, a second web site 612 for providing a web based user interface for developing and managing the open mobile business supporting system, and first and second web form event processing modules 613 and 614 for processing and responding events generated from pages of the first and second web sides 611 and 612, checking validity of user inputs, and processing events when a page is loaded.
  • the first and second web sits 611 and 612 share the logic processing unit 620 and the DB access processing unit 630.
  • the repository DB 1000 functions as a common storage space for sharing data commonly managed in the open mobile business supporting system.
  • the repository DB 1000 stores a user right table, a real time cooperation result table of a content aggregation & syndication system (CASS) 38, a biz template information table, a new biz template analysis/design result table, an announcement table, a resource table, a service examine request/ examine/ request state/ information table, a user authentication table, a biz object information table, a biz object change information table, a biz object using list table, a biz template and biz object relation table, a distribution information of a biz template table, a user information table, a service information table, a biz template modification/ request/ approval change information table, a biz template use IP information table, , a CP information table, an error code table, a service information/ IP address/ authentication key table, a server information table of open mobile business supporting system, a web server information table, an access managing history information table of
  • the web service providing unit 600 cooperates and commonly uses data with the
  • CASS 38 managing contents in a mobile communication system through the repository DB 1000, and supports reliable data cooperation with internal devices of the open mobile business supporting system.
  • the repository DB 1000 stores data managed by the web service providing unit 600, and synchronizes information of a CP, a service, a web server, and a user through cooperating with the CASS 38.
  • the web service providing unit 600 cooperates with the open interface processing unit 100, the business logic processing unit 200, the infra channel providing unit 300, the billing processing unit 400 and the OMS 700 in the open mobile business supporting system for providing a function of setting environmental setups and a function of monitoring statistic data or malfunction states.
  • the web server providing unit 600 cooperates with the business logic processing unit 400 through the MQ server for distributing the biz template and/or the biz object.
  • the web server providing unit 600 cooperates with the CASS 38 that manages common information about a CP, a service, and a user through HTTP in real time.
  • the web server providing unit 600 cooperates with the OI processing unit 100 and the OMS 700 through communication in order to allow a manager to inquire contents of environmental setup per a server. Furthermore, the web server providing unit 600 communicated with the infra channel providing unit 300 through TCP.
  • the web service providing unit 600 separates a user view, a logic process, and a data access process in order to effectively expand, maintain, and repair according to need.
  • the web service providing unit 600 manages the repository DB 1000 storing the common data of each low-level apparatus of the open mobile business supporting system.
  • the repository DB 1000 commonly uses common data through the CASS 38 of the wireless communication system, and shares the data.
  • the CP/SP information, service information and user information, which are managed through the CASS 38, are commonly used for inquiring purpose. Such an information is not additionally managed in the web service providing unit 600.
  • the first web site 611 is provided to a CP or a SP that accesses the first web site
  • the first we site 611 provides a function for providing log-in to confirm a registered user, a function for inquiring a standard API information for a biz template provided from the open mobile business supporting system, a function for managing requests of using a biz template that allows a CP/SP or a user to request a biz template or to cancel/modify the previous requests, a function for providing technical materials and managing inquires and responses, a function for providing announcement or inquires and response for a user, a function for inquiring a service result list, a function for requesting an authentication key, and a function for inquiring the current condition of using API by receiving the authentication key.
  • the second web site 612 is provided for managing and developing the open mobile business supporting system.
  • the second web site 612 includes a function for processing log-in for allowing a registered manage to access, a function for inquiring the details of requests to use a biz template, a function for registering a service checking result for approval/cancel/deletion, a function for processing a service check request for issuing an authentication key to use a biz template or change authentication information state, a function for inquiring announcement, a function for designing a new biz template, registering a analysis result of the new biz template, and inquiring, a function for managing a standard API for a CP and/or a SP and managing general documents, a function for managing bulletin board/announcement of the first web site 611, a function for inquiring a repository DB and cooperation detail, a function for managing server information of the open mobile business supporting system, a function for managing biz template information, a function for managing biz object information, a
  • the logic processing unit 620 performs an inquiry operation and a registration process for major data provided through the first and second web sites 611 and 612.
  • FIG. 52 is a block diagram illustrating a logic processing unit 620 according to an embodiment of the present invention.
  • the logic processing unit 620 includes a service development support managing module 621, an event support managing module 622, a technical support managing module 623, a malfunction monitoring module 624, a statistic inquiry module 625, and an operating and managing module 626.
  • the service development support managing module 621 provides a function for managing resources for the open mobile service supporting system, a function for managing data of a biz template and biz object, and a function for requesting and approving a predetermined process related thereto.
  • the event support managing module 622 provides a function for requesting and approving events, and a function for registering, modifying, and inquiring information.
  • the technical support managing module 623 provides a guide for developing the open mobile business supporting system and a function for registering, modifying, deleting, and inquiring technical materials and bulletin board.
  • the malfunction monitoring module 624 performs a function for monitoring the open mobile business supporting system in real time, a function for managing thresholds for monitoring, a function for inquiring traffic, a function for monitoring session information in real time, a function for tracking a call through a phone number, and a function for inquiring malfunction information.
  • the statistic inquiry module 625 performs a function for inquiring billing statistic according to an event, a CP, a service, a biz template, an error, and a term, and a function for used amount statistic according to an event, a CP, a service, a biz template, a biz object, an infra, and a term.
  • the operating and managing module 626 manages an integrated supporting apparatus.
  • the operating managing module 626 registers, modifies, deletes, and inquires the announcement in a bulletin board, manages the right of a site user, manages registration per a server of the open mobile business supporting system, inquires environmental setup, manages common codes and error codes, inquires a result of cooperating with a legacy system managing contents and cooperation information thereof, and managing access of a site operator.
  • the service development support managing module 621 includes: a biz object manager for registering, modifying, and inquiring a biz object; a biz template manager for registering, modifying, and inquiring a biz template; a biz object information manager for creating information about a biz object, and distributing the biz object information; a biz template information manager for creating information about a biz template, and distributing the biz template information; a BT manager for requesting service check, requesting an API, inquiring a request list, a manager, and a user, and issuing an authentication key; a BT information manager for inquiring in- formation and current condition for authentication key through the BT manager; and a manager for inquiring, registering, deleting, and modifying the API of the infra channel providing unit 300.
  • the event support managing module 622 includes an even list manager for managing a function of inquiring event current condition.
  • the operation managing module 626 includes: a code information manager for registering, deleting, and inquiring common codes; a community manager for managing registration, modification, deletion, and inquiry of bulletin board, announcement, and FAQ; an error code manager for managing registration, modification, deletion, and inquiry of error code; and a file information manager for managing a function of inquiring a file related to a biz object and a biz template, and a download function.
  • the logic processing unit 620 includes a log-in manager for processing log-in to the first and second web sites 611 and 612, and an access IP manager for registering, editing, deleting, and inquiring an IP of the second web site 612.
  • the DB access processing unit 630 manages the access of the repository
  • DB 1000 defines a common data access class that defines a method for inserting, deleting and updating data.
  • the web service providing unit 600 provides a real time interface and a non-real time interface.
  • the web service providing unit 600 cooperates and shares data with the repository DB 1000, the CASS 38, the open interface processing unit 100, and the business logic processing unit 200 through HTTP in real time. If data is modified in the CASS 38, the CASS 38 transmits the modified data to the repository DB 1000 using HTTP.
  • the sharing data is CP information, service basic information, service IP information, and web server information.
  • the repository DB 1000 shares data with a cooperating system requiring an one-off data using a FTP scheme or a database view scheme in non-real time.
  • the sharing data includes billing information or web server information. If the data is provided to the cooperating system through the database view scheme, following advantages are provided. That is, additional cooperation modules are not required. Security and stability are guaranteed because the data are selected and provided through controlling security information and fields by a manager. It is possible to provide related information by properly processing complicated related tables or the formats thereof. Furthermore, it is possible to update new table through simple modification of a view.
  • FIG. 53 is a flowchart illustrating a method for processing a mobile oriented (MO) message using an open mobile business supporting system according to an embodiment of the present invention.
  • SMS short message service
  • MMS multimedia message service
  • CP/SP system 11 and a mobile communication terminal 14 includes a mobile oriented (MO) message service, and a mobile terminated (MT) message service.
  • MO mobile oriented
  • MT mobile terminated
  • the MO message service is a service to transfer a message to a corresponding CP/
  • SP system 11 when a short message or a multimedia message is transmitted to a predetermined assigned number, for example, ##6650, from a user's mobile communication terminal 14 after a terminal number of a receiving side CP/SP system 11 is assigned to the predetermined number for example, ##6650.
  • the user MO message service is performed by the OI processing unit 100, the business logic processing unit 200, and the legacy cooperation processing unit 500 in the open mobile business supporting system according to the present embodiment.
  • the OI processing unit 100 includes an infra channel interface 100a and an open output interface 100b.
  • the legacy cooperation processing unit 500 includes a MO cooperating unit 527.
  • the infra channel interface 100a is disposed in the OI processing unit 100, and receives a MO SMS message or MO MMS message from the user terminal 14 through a MP/MMSC 39.
  • the MP denotes a SMS dispatching System
  • the MMSC denotes a device transmitting a MMS message.
  • the infra channel interface 100a receives the MO message from the user terminal 14, and calls a business logic related to the MO message form the business logic processing unit 200.
  • the business logic processing unit 200 perform a biz template assigned for the MO message through cooperating with the MO cooperating unit 527 of the legacy cooperation processing unit 500.
  • the biz template is formed of properties of biz objects, an order of performing the biz objects, the expression of a conditional branch, input parameter information for performing the biz objects, a method of processing data, information about output parameters exposed after performing a biz template, and time-output setup information.
  • FIG. 54 and FIG. 55 show examples of a business template previously set for processing a MO message.
  • a biz template for processing a MO message can group unit functions among service logics of the CP/SP system 11 for processing the user MO message.
  • Such a biz template embodied to perform a biz logic that is a low- level function performed by a wireless communication system.
  • the biz template includes at least one or a plurality of biz objects.
  • FIG. 54 shows a biz template processed in the business logic processing unit 200 for processing a MO SMS message
  • FIG. 55 shows a biz template processed in the business logic processing unit 200 for processing a MO MMS message.
  • the biz template can be formed in various types and forms according to a service type provided from the CP/SP system 11.
  • the business logic processing unit 100 performs a biz template that is previously defined according to a MO message as shown in FIG. 54 and FIG. 55, and provides the result of performing the biz template to the CP/SP system 11 that is the destination of a corresponding MO message through the open output interface 100b.
  • the MO cooperating unit 527 is disposed in the legacy cooperation processing unit
  • the MO cooperating unit 527 provides the information of a destination of the MO message and option information to the business logic processing unit 200 in response to the business logic processing unit 200.
  • the option information includes information about a billing type and a call type.
  • the billing type information is information about whether a user applies for a prepayment plan or a post payment plan.
  • the post payment plan may include various types of post payment plans or pre/ post integrated payment plans according to the policy of a mobile communication service provider.
  • the call type information is information related to whether a message transmitted from the user terminal 14 is a MO message, or a MT message, or whether a MT message is processed continuously after processing a MO message.
  • the destination information includes an IP address and port information for the CP/SP system 11. Therefore, the business logic processing unit 200 composes a business template in various forms using the destination information and the option information received from the MO cooperating unit 527.
  • the open output interface 100b is disposed in the open interface processing unit
  • the open output interface 100b receives the result of performing a business logic by the business logic processing unit 200, and transmits the received result to the CP/ SP system 11.
  • the open output interface 100b uses an integrated specification for SMS and MMS when transmitting a MO message to the CP/SP system 11.
  • a user transmits a SMS or MMS message using own terminal 14 to a pre-assigned terminal number of a receiving side CP/SP system 14, for example, #6650.
  • the MP/MMSC 39 transfers the SMS or MMS message, which is transmitted to the pre-assigned terminal number, to the infra channel interface 100a in the OI processing unit 110 of the open mobile business supporting system at step S4702.
  • the infra channel interface 100a calls a predetermined biz logic corresponding to the SMS or MMS message to the business logic processing unit 200, and requests the business logic processing unit 200 to perform the biz template for the business logic at step S4703.
  • the business logic processing unit 200 requests the destination information and the option information of the MO message from the MO cooperating unit 527.
  • the MO cooperating unit 527 provides the destination information and the option information for the MO message to the business logic processing unit 200 at step S4704 . Therefore, the business logic processing unit 200 can compose business templates in various forms using the destination information and the option information from the MO cooperating unit 527.
  • the business logic processing unit 200 performs a biz template defined from a predetermined business logic for the MO SMS or MMS message, and transmits the result of performing the biz template to the open output interface 100b of the OI processing unit 100 at step S4705.
  • the open output interface 100b transfers the received result of performing the biz template from the business logic processing unit 200 to the CP/SP system 11, thereby ending the procedure of processing the MO message using the open mobile business supporting system according to the present embodiment at step S4706 .
  • FIG. 56 is a block diagram and a flowchart illustrating a MT message processing apparatus using the open mobile business supporting system according to an embodiment of the present invention.
  • the MT message service is a service to provide a SMS or MMS message such as a text, a picture, and a multimedia file from a CP/SP system 11 to a user's mobile communication terminal 14.
  • the legacy cooperation processing unit 500 further includes a MT cooperating unit 528.
  • the OI processing unit 100 receives a user MT message provided from the CP/SP system 11, and calls a biz template related to the MT message for the business logic processing unit 200.
  • the OI processing unit 100 creates a unique session key according to a request of performing each biz template constituting a MT message service provided from the CP/SP system 11 and manages the created session key. Therefore, the created session key can be used to identify business logics processed in the open mobile business model supporting system.
  • the OI processing unit 100 provides a web service based standard API type business logic call mechanism in order to allow access without being limited by a client type.
  • the business logic processing unit 200 perform a predetermined biz template for the MT message through cooperating with the MT cooperating unit 528.
  • the biz template is formed of the properties of biz objects, an order of performing the biz objects, the expression of a conditional branch, input parameter information for performing the biz objects, a method of processing data, output parameter information exposed after performing the biz template, and time-out setup information.
  • FIG. 57 and FIG. 58 show biz templates previously setup for processing a MT message.
  • the biz template is embodied by grouping unit functions among service logics of the CP/SP system 11 for processing a MT message.
  • the biz template is embodies by grouping at least one or a plurality of biz objects for processing a MT message.
  • FIG. 57 shows a biz template processed in the business logic processing unit 200 for processing a MT SMS message according to an embodiment of the present invention.
  • FIG. 58 shows a biz template for processing a MT MMS message according to an embodiment of the present invention.
  • Such a biz template for processing a MT message can vary in various forms according to a service type provided from the CP/SP system 11.
  • the business logic processing unit 200 performs a biz template defining a predetermined business logic for the MT message.
  • the SMS MT message or the MMS MT message is transmitted to the user terminal 14 through the MP/MMSC 39 in a legacy system through cooperating with the MT cooperating unit 528 in the legacy cooperation procession unit 500 in case of receiving an instruction for performing the biz objects forming the biz template.
  • the MT cooperating unit 528 relays the cooperation between the business logic processing unit 200 and the mobile communication legacy system 30 to transmit the MT message to the user terminal through the MP/MMSC 39 so that the business logic processing unit 200 performs the biz template.
  • the CP/SP system 11 transmits a predetermined SMS or MMS message to the OI processing unit 100 at step S5301.
  • the OI processing unit 100 calls a biz template related to the MT SMS message for the business logic processing unit 200 at step S5302.
  • the business logic processing unit 200 performs a biz template shown in FIG. 57 and/or FIG. 58, which is defined based on a business logic called corresponding to the MT SMS or MMS message. As described above, while the business logic processing unit 200 performs a biz template related to the MT message, the business logic processing unit 200 requests the MT cooperating unit 528 in the legacy cooperation processing unit 500 to cooperate with the MP/MMSC 130 in a mobile communication legacy system in order to perform the biz template at step S5303.
  • the MT cooperating unit 528 requests the MP or MMSC 39 to transmit the
  • the MP or MMSC 39 receives the MT message and transfers the received MT message to the user terminal 14, thereby processing the MT message through the open mobile business system according to an embodiment of the present invention.
  • FIG. 59 is a flowchart illustrating a procedure for processing a MT MSM message after processing a MO SMS message using an open mobile business supporting system according to an embodiment of the present invention.
  • a billing process for a MO message processing service and a billing process for a MT message processing service are independently performed. If an error is generated in the MT message processing procedure after transmitting a predetermined SMS message or MMS message to a CP/SP system 11 using a user terminal 14 based on the conventional MO message processing scheme, the SMS or MMS message may not reach to a receiver. Although the user did not receive the SMS or MMS message due to such an error, a service feed is charged to a user according to the conventional service scheme.
  • the sessions for MO message and for the MT message are managed in single procedure using the open mobile business supporting system. Therefore, a related service fee is charged only if the MO message and the MT message service are normally and completely finished without generating error.
  • a user transmits a SMS message to the MASS 32, a SMS dispatching system, using own user terminal 14 at step S5301 .
  • the SMS message is a phone to CP/SP message provided from the user terminal 14 to the CP/SP system 11.
  • the MASS 32 transmits the SMS message to the infra channel interface 100a at step S5302, and receives the response at step S5303.
  • the infra channel interface 100a requests the characteristics information of the MO message such as the destination information and the option information from the MO cooperating unit 527 through the business logic processing unit 200 at steps S5304 and S5305.
  • There destination information includes an IP address and port information of the CP/SP system 11, and the option information includes information related to a billing type and a call type.
  • the MO cooperating unit 527 transfers the characteristics information of the MO message such as the destination information and the option information to the infra channel interface 100a through the business logic processing unit 200 at step S5306 and S5307.
  • the infra channel interface 100a creates a session for transmitting the MO message using the destination information and the option information of the received MO message, and inputs the information of the session to the MMDB 900 at step S5308.
  • billing information inputs for later billing process for the MO message transmission, and the billing information is managed through entire session for the MO message.
  • the infra channel interface 100a requests a corresponding business logic from the business logic processing unit 200 using the created session for the MO message by calling a business logic for the MO SMS at step S5309.
  • the business logic processing unit 200 performs a biz template for the called business logic, and transfers the result thereof to the CP/SP through the open output interface 100b at step S5310 and S5311. Then, the business logic processing unit 200 receives the result of MO SMS transmission as a response at step S5312 and S5313.
  • the business logic processing unit 200 transmits the result of performing the biz template for the MO message to the infra channel interface 100a at step S5314.
  • the infra channel interface 100a determines whether the transmitted MO message is normally transmitted to the CP/SP system 11 based on the result of performing the biz template. If the MO message is successfully transmitted to the CP/SP system 11, the infra channel interface 100a continuously sustains the session for the MO message for continuously processing the MO message. The infra channel interface 100a, however, terminates the session at step S5315, if the MO message transmission is failed.
  • the CP/SP system 11 transmits a report message to the business logic processing unit 200 through the open output interface 100b in order to inform that the MO message is successfully transferred at steps S5316 and S5317. Since a step of transmitting the MT message with the session sustained is performed after processing the MO message in the present embodiment, the steps S5316 and S5317 can be cancelled.
  • a procedure of MT SMS deliver is performed. If the MO message is successfully transferred to the SP/SP system 11 at step S5315, the CP/SP system 11 requests the open web interface 100c to transmit a CP/SP to Phone direct MT SMS message from the CP/SP system to the user terminal 14 at step S5318.
  • the open web interface 100c creates a session for a MT message based on the received MT SMS message transmission request and stores the information of the created session to the MMDB 900 at step S5319.
  • the session key for the MO message is required to be sustained in case of continuously processing the MT message after performing a MO message.
  • billing information inputs for a billing process for the MT message transmission when the session for the MT message is created, and the billing information is managed through the entire session for the MT message.
  • the open web interface 100c calls a business logic for the MT SMS for the business logic processing unit 200 using the created session information, thereby requesting a corresponding biz logic to be processed at step S5320.
  • the business logic processing unit 200 performs a biz template that defines a previously defined business logic for the MT message.
  • the biz template is performed, if the business logic processing unit 200 requires cooperating with a legacy system, the business logic processing unit 200 request the MT cooperating unit 528 to transmit the MT message through the MASS 32 in the legacy system at step S5321.
  • the MT cooperating unit 528 transmits the MT SMS message to the user terminal by cooperating with the MASS 32, and transmits the result of transmitting to the business logic processing unit 200 at step S5322.
  • the business logic processing unit 200 provides a result of transmitting the MT SMS message to the user terminal by performing the biz template for the MT message as described above to the open web interface 100c at step S5323.
  • the open web interface 100c provides the result of transmitting the MT SMS message to the CP/ SP system 11 at step S5324.
  • the MT cooperating unit 528 transmits a
  • MT SMS deliver report message to the business logic processing unit 200 to inform that the MT SMS message is successfully transmitted at step S5325.
  • the business logic processing unit 200 confirms the MT SMS message process successfully end by analyzing the received MT SMS delivery report message and terminates the session for the MT message at step S5327.
  • the business logic processing unit 200 transmits a MO SMS deliver report message to the infra channel interface 100a to inform that the MO SMS message is successfully transmitted at step S5327.
  • the infra channel interface 100a confirms that the MO message and the MT message are successfully transmitted based on the received MO SMS delivery report message, and terminates the sessions for the MO message and the MT message at step S5328. Finally, the MO MT cooperation message processing procedure according to the present embodiment ends.
  • FIG. 60 is a diagram illustrating a procedure of processing a MT MMS message after processing a MO MMS message using an open mobile business supporting system according to an embodiment of the present invention.
  • MT MMS message processing steps S5401 to S5428 are similar to the MO-MT message processing steps S5301 to S5328. Therefore, overlapped descriptions thereof are omitted.
  • the MO-MT MMS message processing steps in FIG. 60 are identical to the MO-MT message processing steps in FIG. 59 except following steps.
  • the business logic processing unit 200 cooperates with the MMSC 33 of a legacy system to transmit the message so as to process a MMS message.
  • a report message is transmitted to a long message service center (LMSC, not shown) and receives a response thereof at steps S5430 to S5436 in order to enable the LMSC to independently perform a billing process, which is connected to the MMSC 33 to confirm the transmission of the MMSC.
  • LMSC long message service center
  • FIG. 61 is a diagram illustrating a procedure of processing a MO SMS message after processing a MT SMS message using an open mobile business supporting system according to an embodiment of the present invention
  • FIG. 62 is a diagram illustrating a procedure of processing a MO MMS message after processing a MT MMS message.
  • a method of processing a MO message after processing a MT message in FIG. 61 and FIG. 62 is different from that of processing a MT message after transmitting a MO message shown in FIG. 59 and FIG. 60 in a view of an order performing processes. That is, in FIG. 61 and FIG. 62, MT message processing steps S5501 to S5508, and S5601 to S5608 are perform before performing MO message processing steps S5509 to S5527, and S5609 to S5632. However, steps for processing a MO message, and steps of processing a MT message in FIG. 61 and FIG. 62 are identical to those in FIG. 59 and FIG. 60, respectively.
  • FIG. 63 is a block diagram illustrating a configuration for providing a report after transmitting a message in an open mobile business supporting system according to an embodiment of the present invention.
  • the open mobile business supporting system includes an open interface OI processing unit 100 connected to a client contents/service providing system CP/SP 11a, and a report open interface (ROI) processing unit 111 connected to the business logic processing unit 200 and a server contents/service providing system CP/SP 1 Ib.
  • OI open interface
  • ROI report open interface
  • the client CP/SP 1 Ia is a system that performs a CP/SP to Phone direct MT messaging service for providing a SMS or a MMS message such as texts, pictures, and multimedia files to a user's mobile terminal.
  • the server CP/SP 1 Ib is a system that wants to receive a report message in real time as a SMS or MMS message transmission result from the client CP/SP 1 Ia for a request of transmitting a SMS or MMS message from the client CP/SP 1 Ia.
  • the client CP/SP 11a and the server CP/SP 1 Ib are described as an independent system. However, they can be embodied as single system according to a service type and a service provider type.
  • the described configuration can provide a report in real time based on the identical integrated specification not only for a SMS or MMS message but also for various other legacy systems.
  • the business logic processing unit 200 defines and standardizes the business logic and manages it as a biz template.
  • the business logic processing unit 200 transmits a SMS or a MMS message to a user terminal 14 by performing a biz template according to a result of performing the biz template through cooperating a MP/MMSC 130 in a legacy system, and receives a report message as the result of transmitting the SMS or MMS message.
  • the report message includes information about the result of message transmission such as whether the SMS or MMS message is successfully transmitted or not.
  • the ROI processing unit 111 receives the report message from the business logic processing unit 200 and provides the received report message to the server CP/SP 1 Ib.
  • FIG. 64 is a block diagram illustrating a report open interface (ROI) processing unit
  • the ROI processing unit 1 lincludes a MQ adapter 111-1, a message analyzer 111-2, a message builder 111-3, a report manager 111-4, a report sender 111-5, a Log manager 111-6, and a configuration manager 111-7.
  • the MQ adapter 111-1 transmits and receives a report message to/from the business logic processing unit 200 through a message queue 816.
  • the MQ adapter 111-1 includes a BIE receiver I l l-la and a BIE transmitter 111-lb.
  • the BIE receiver 111-la receives a report message from the business logic processing unit 200 through a message queue 816.
  • the BIE transmitter 111-lb transmits a report message to the business logic processing unit 200 through message queue 816.
  • the message analyzer 111-2 receives the report message from the MQ adaptor
  • the message builder 111-3 receives the report message from the message analyzer
  • the report manager 111-4 receives the report message from the message builder
  • the report sender 111-5 receives the report message from the report manager 111-4 and transmits the received report message to the server CP/SP 1 Ib.
  • the Log manager 111-6 standardizes a log format per a log level of constitutional modules 111-1 to 111-7 of the ROI processing unit 111. That is, the log manager 111-6 creates a system log for a log level and a log form assigned from each constitutional module 111-1 to 111-7, and transmits the created system log to OMS 700 using FTP to manage the created system logs.
  • the log information can be created based on debugging information, malfunction information, and system operating information, which are generated from the constitutional modules 111-1 to 111-7 of the ROI processing unit 111.
  • the log level can be setup according to a system environment. For example, various log levels can be defined as an error level, an information providing level, a warning lever, and a debug level for leaving the lowest detail. The log is generated according to the log level defined according to the environment.
  • the configuration manager 111-7 stores and manages environment settings such as a system environment or a log generation period for the constitutional modules 111-1 to 111-7 of the ROI processing unit 111 to an internal configuration file (not shown).
  • the configuration manager 111-7 can be embodied to reflect the modification of the configuration file by re-driving the ROI processing unit 111 or to instantly reflect the modification of the configuration file in real time without re-driving the ROI processing unit 111. That is, the configuration manager 111-7 manages modifications using the internal configuration file when the execution environment of each constitutional module of the ROI processing unit 111 is changed.
  • the configuration manager 111-7 can set up the execution environment by reading the configuration file in real time when the system is driven.
  • KEY values of predetermined program or configuration information are received from a desired module, and a configuration information value is inquired.
  • configuration information can be inquired, modified, and deleted by directly access the configuration file.
  • the configuration manager 11-7 reflects the configuration information to the current ROI processing unit 111 in real time in order to allow a program or a module to use the reflected configuration information.
  • FIG. 65 is a flowchart illustrating a procedure of providing a report through an open mobile business supporting system of FIG. 63 after transmitting a message according to an embodiment of the present invention.
  • the OI processing unit 100 when performing a CP/SP to Phone direct MT messaging service that transmits a SMS or MMS message including a text, a picture, and a multimedia file to a user terminal 14 from the client CP/SP 11a using the open mobile business supporting system, the OI processing unit 100 requests to process a business logic that performs a single function among logics constituting a MT message service at step S5901.
  • the client CP/SP 11a requests the business logic process at the step S5901, it is preferable to include a server IP address or port information of the server CP/SP 1 Ib in the business logic processing request message in order to transmit a report message for the result of performing the biz template of the business logic to a pre-assigned server CP/SP 1 Ib.
  • the OI processing unit 100 request the business logic processing unit 200 to perform the biz template, and the business logic processing unit 200 performs the biz template at step S5902.
  • the business logic processing unit 200 cooperates with the MP/MMSC 39 through the MT cooperating unit 528 of the legacy cooperation processing unit 500, thereby transmitting a SMS or MMS message to the user terminal 14 at step S5903.
  • the business logic processing unit 200 receives a report message from the MT cooperating unit 528, which informs whether the SMS or MMS message is successfully transmitted to the user terminal 14 or not, and transmits the received report message to the server CP/SP 1 Ib at step S5904, thereby providing a real time report of the MT message transmission according to an embodiment of the present invention.
  • FIG. 66 is a flowchart illustrating the detailed operation of a ROI processing unit
  • the ROI processing unit 111 receives a report message from the business logic processing unit 200 and transmits the received report message to the server CP/SP 1 Ib.
  • the MQ adapter 111-1 receives the report message from the business logic processing unit 200 through the message queue 817 at step S6001.
  • the message analyzer 111-2 receives the report message from the MQ adaptor
  • the message builder 111-3 receives the report message from the message analyzer
  • the report manager 111-4 receives the report message from the message builder 111-3 and relays the received report message to be transmitted to the server CP/SP 1 Ib.
  • the report sensor 111-5 receives the report message from the report manager 111-4 and transmits the received report message to the server CP/SP 1 Ib at step S6004.
  • the log manager 111-6 is used to create a system log for a log level and a log forma assigned from each of constitutional modules 111-1 to 111-7 of the ROI processing unit 111, and the created log information is transmitted to the OMS 700 using FTP, thereby managing the log information of the ROI process 111.
  • the configuration manager 111-7 is used to store and manage the environment settings such as system environment or the log generation period for each of the constitutional modules 111-1 to 111-7 of the ROI processing unit 111, thereby managing the system environment and the log generation period.
  • FIG. 67 is a block diagram illustrating an open mobile business supporting system for confirming a message transmission result after transmitting a message.
  • the open mobile business supporting system according to the present embodiment further includes a confirm database server 113.
  • the confirm DB Server 113 stores information about the report message transmitted from the server CP/SP 1 Ib, and provides the stored report message when the client CP/ SP 1 Ia request the report message. By driving the confirm DB server 113, it is possible to confirm whether a report message is transmitted from the client CP/SP 1 Ia to the server CP/SP 1 Ib although the report message is lost according to the network condition. It is preferable that the confirm DB server 113 stores and manages session information such as response messages exchanged to perform the biz template in the business logic processing unit 200.
  • the report message and the session information stored in the confirm DB server 194 can be directly provided from the business logic processing unit 200, or can be provided from the business logic processing unit 200 through the ROI processing unit 111'.
  • a message can be confirmed based on an integrated specification according to needs. In the present embodiment, it is possible to confirm the message transmission result based on an integrated specification not only for the SMS or MMS message but also for various other messages for legacy system.
  • the ROI processing unit 111' further includes a confirm DB manager 111-8 and a scheduler 111-9 as well as a MQ adapter 111-1, a message analyzer 111-2, a message builder 111-3, a report manager 111-4, a report sender 111-5, a Log manager 111-6, a configuration manager 111-7.
  • the confirm DB manager 111-8 stores and manages report messages and session information provided from the business logic processing unit 200 at the confirm DB server 113.
  • the report manager 111-4 obtains the report message from the confirm DB manager 111-8, and provides the obtained report message to the business logic processing unit 200 through the MQ adaptor 111-1.
  • the request of the report message transmitted from the client CP/SP 1 Ia is performed based on a session key generated to identify each business logic of the client CP/SP 11a from the OI processing unit 100.
  • the confirm DB manager 111-8 stores and manages the report message with referent to session keys of corresponding business logic. Therefore, when the client CP/SP 11a requests a report message of a predetermined session key to transmit, the confirm DB manager 111-8 transmits the report message related to the corresponding session key to the client CP/SP 11a.
  • the scheduler 111-9 manages report information stored in the conform DB server
  • the scheduler 111-3 can be configured to delete stored report messages at every one day period in order to prevent a memory from being overflowed due to the unnecessary messages.
  • FIG. 69 is a flowchart illustrating a procedure for conforming a message transmission result after transmitting a message in an open mobile business supporting system according to an embodiment of the present invention.
  • the OI processing unit 100 receives a request of processing a business logic that performs a single function among logics constituting the MT messaging service from the client CP/SP 191 at step S6301.
  • the OI processing unit 100 requests the business logic processing unit 200 to perform the biz template, and the business logic processing unit 200 performs the biz template at step S6302.
  • the business logic processing unit 200 transmits a SMS or MMS message to a user terminal 14 by cooperating with the MP/MMSC 39 through the MT cooperating unit 1528 of the legacy cooperation processing unit 500 at step S6303.
  • the business logic processing unit 200 manages the received report messages by storing the received report messages into the confirm DB server 113 directly or indirectly through the ROI processing unit 111 at step S6304.
  • the business logic processing unit 200 receives a report message from the MT cooperating unit 528, which informs the result of message transmission such as whether the SMS or MMS message is successfully transmitted to the user terminal 14. Then, the business logic processing unit 200 transmits the received report message to the server CP/SP 1 Ib at step S6305, thereby providing a real-time report of the MT message transmission to the server CP/SP 1 Ib.
  • the business logic processing unit 200 obtains the report message from the confirm DB server 113 and provides the obtained report message to the client CP/SP 11a.
  • the business logic processing unit 200 can be configured to directly obtain the report message from the confirm DB server 113 or to indirectly obtain the report message through the ROI processing unit 111'.
  • FIG. 70 is a diagram illustrating the operations of a ROI processing unit 111' according to an embodiment of the present invention.
  • the ROI processing unit 111' receives the report message from the business logic processing unit 200 and transmits the received report message to the serer CP/SP 1 Ib as follows.
  • the MQ adapter 111-1 receives a report message from the business logic processing unit 200 through a message queue 817a at step S6401.
  • the confirm DB manager 111-8 stores the received report message in the confirm
  • the message analyzer 111-2 receives the report message from the MQ adaptor
  • the message builder 111-3 receives the report message from the message analyzer
  • the report manager 111-4 receives the report message from the message builder
  • the report sender 111-5 receives the report message from the report manager 111-4 and transmits the received report message to the server CP/SP 1 Ib at step S6405.
  • the report manger 111-4 determines whether the business logic processing unit 200 request the report message or not at step S6306. In case of the report message request, the report manager 111-4 transmits a report message, which is stored in the confirm DB server 113 and have relation to a unique session key of a corresponding request, to the business logic processing unit 200 at step S6407.
  • the scheduler 111-9 determines whether a period for storing the repot message in the confirm DB server 113 based on a predetermined execution period and managing period is expired or not at step S6408. In case of expiration, the report message with the storing period expired is removed from the confirm DB server 113, thereby preventing the confirm DB server 113 from being overflowed.
  • an open mobile business supporting system supports various infra resources in a wireless communication system to be independently operated and integrally driven, thereby making various infra resources conveniently and effectively cooperated together. Furthermore, the open mobile business supporting system provides an integrated interface for the infra resources in the wireless communication system. Therefore, a service and an application layer can easily use the infra resources of the wireless communication system.
  • the open mobile business supporting system classifies biz logic management, service management, and service execution, thereby effectively supporting various business models.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Data Mining & Analysis (AREA)
  • Economics (AREA)
  • Computer Hardware Design (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Procédé et système assurant un support d'affaires mobile ouvert qui couvre efficacement plusieurs modèles d'affaires souhaités par un fournisseur de contenu/service, via une seule interface qui peut utiliser de façon intégrée diverses ressources de système de communications mobiles. On sélectionne dans l'environnement de logique de service d'un fournisseur de contenu/service une fonction de faible niveau, susceptible d'être reprise dans une fonction d'unité et appliquée à l'intérieur d'un système de communications mobiles, et on la définit comme logique d'affaires, laquelle est utilisée suivant la demande du fournisseur de contenu/service par une coopération avec le système de communications mobiles et divers systèmes existants. Le résultat de l'application de la logique d'affaires est renvoyé au fournisseur de contenu/service.
EP06812363A 2005-11-03 2006-11-02 Systeme et procede assurant un support d'affaires mobile Ceased EP1949281A4 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP08013419A EP2053552A3 (fr) 2005-11-03 2006-11-02 Dispositif de coopération patrimoniale et procédé de traitement
EP08013417A EP2009586A3 (fr) 2005-11-03 2006-11-02 Dispositif d'interface ouverte et procédé
EP08013418A EP2018027A1 (fr) 2005-11-03 2006-11-02 Dispositif logique commercial et procédé de traitement
EP08013420A EP2026260A3 (fr) 2005-11-03 2006-11-02 Dispositif de facturation et procédé de traitement

Applications Claiming Priority (21)

Application Number Priority Date Filing Date Title
KR1020050105076A KR100706347B1 (ko) 2005-11-03 2005-11-03 개방형 모바일 비즈니스 지원 시스템의 이용 및 개발을위한 통합 지원 장치
KR1020050107249A KR100666711B1 (ko) 2005-11-09 2005-11-09 개방형 모바일 비즈니스 지원 시스템에서 메시지 전송 후실시간 리포트 제공 장치 및 방법
KR1020050107246A KR100738041B1 (ko) 2005-11-09 2005-11-09 개방형 모바일 비즈니스 지원 시스템에서 메시지 전송 방법
KR1020050107245A KR100666708B1 (ko) 2005-11-09 2005-11-09 개방형 모바일 비즈니스 지원 시스템에서 사용자종단(ｍｔ) 메시지 전송 장치 및 방법
KR1020050107244A KR100666707B1 (ko) 2005-11-09 2005-11-09 개방형 모바일 비즈니스 지원 시스템에서 사용자발신(ｍｏ) 메시지 전송 장치 및 방법
KR1020050107184A KR100727088B1 (ko) 2005-11-09 2005-11-09 개방형 모바일 비즈니스 지원 시스템의 운용 및 관리 장치
KR1020050107247A KR100666709B1 (ko) 2005-11-09 2005-11-09 개방형 모바일 비즈니스 지원 시스템에서 메시지 전송 방법
KR1020050107242A KR100650701B1 (ko) 2005-11-09 2005-11-09 개방형 모바일 비즈니스 지원을 위한 레거시 연동 처리장치 및 방법
KR1020050107243A KR100650702B1 (ko) 2005-11-09 2005-11-09 개방형 모바일 비즈니스 지원을 위한 메시징 시스템 연동처리 장치
KR1020050107248A KR100666710B1 (ko) 2005-11-09 2005-11-09 개방형 모바일 비즈니스 지원 시스템에서 메시지 전송 확인장치 및 방법
KR1020050108611A KR100738037B1 (ko) 2005-11-14 2005-11-14 개방형 모바일 비즈니스 지원 시스템에서의 개방형인터페이스 방법 및 장치
KR1020050108643A KR100692650B1 (ko) 2005-11-14 2005-11-14 개방형 모바일 비즈니스 지원 시스템에서의 과금 처리방법및 장치
KR1020050108638A KR100738039B1 (ko) 2005-11-14 2005-11-14 개방형 모바일 비즈니스 지원 시스템에서의 비즈니스 로직처리 방법 및 장치
KR1020050109047A KR100666712B1 (ko) 2005-11-15 2005-11-15 푸시 에이전트 서비스 장치 및 방법, 그리고 이를 수용한개방형 모바일 비즈니스 지원 시스템
KR20050109308 2005-11-15
KR1020050109586A KR100738040B1 (ko) 2005-11-16 2005-11-16 개방형 모바일 비즈니스 지원 시스템의 ａｐｉ 제공 방법
KR1020050111368A KR100692632B1 (ko) 2005-11-21 2005-11-21 개방형 모바일 비즈니스 지원 방법 및 시스템
KR1020050111369A KR100666713B1 (ko) 2005-11-21 2005-11-21 개방형 모바일 비즈니스 지원 시스템의 인프라 채널 제공장치 및 방법
KR1020050111373A KR100716732B1 (ko) 2005-11-21 2005-11-21 다운로드 서비스 지원 방법 및 이를 수용한 개방형 모바일비즈니스 지원 시스템
KR20060103170A KR100845307B1 (ko) 2005-11-15 2006-10-23 개방형 모바일 비즈니스 지원을 위한 ｌｂｓｐ 연동 처리장치 및 방법
PCT/KR2006/004524 WO2007052959A1 (fr) 2005-11-03 2006-11-02 Systeme et procede assurant un support d'affaires mobile

Related Child Applications (4)

Application Number Title Priority Date Filing Date
EP08013418A Division EP2018027A1 (fr) 2005-11-03 2006-11-02 Dispositif logique commercial et procédé de traitement
EP08013417A Division EP2009586A3 (fr) 2005-11-03 2006-11-02 Dispositif d'interface ouverte et procédé
EP08013420A Division EP2026260A3 (fr) 2005-11-03 2006-11-02 Dispositif de facturation et procédé de traitement
EP08013419A Division EP2053552A3 (fr) 2005-11-03 2006-11-02 Dispositif de coopération patrimoniale et procédé de traitement

Publications (2)

Publication Number Publication Date
EP1949281A1 true EP1949281A1 (fr) 2008-07-30
EP1949281A4 EP1949281A4 (fr) 2011-02-02

Family

ID=38006064

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06812363A Ceased EP1949281A4 (fr) 2005-11-03 2006-11-02 Systeme et procede assurant un support d'affaires mobile

Country Status (2)

Country Link
EP (1) EP1949281A4 (fr)
WO (1) WO2007052959A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112738070A (zh) * 2020-12-25 2021-04-30 广州凡科互联网科技股份有限公司 一种基于web的网站微信流量监控的方法

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7945949B2 (en) * 2007-03-19 2011-05-17 Microsoft Corporation Providing remote services to legacy applications
CN102883264B (zh) * 2012-09-19 2015-03-25 中国联合网络通信集团有限公司 定位业务隐私鉴权方法、应用终端和业务能力开放平台
WO2016160626A1 (fr) 2015-03-27 2016-10-06 Globallogic, Inc. Détermination d'actions reposant sur l'attribution de signification à des informations détectées dans un environnement informatique distribué
DE112016002652T5 (de) * 2015-06-12 2018-03-01 Sony Corporation Vorrichtung, verfahren und programm
CN111859896B (zh) * 2019-04-01 2022-11-25 长鑫存储技术有限公司 配方文档检测方法、装置、计算机可读介质及电子设备
CN113297157B (zh) * 2020-02-24 2024-06-07 长鑫存储技术有限公司 机台文件处理方法及处理系统
CN114553966B (zh) * 2022-01-21 2024-08-27 浪潮通用软件有限公司 一种前端的Http请求的构造方法、装置、设备及介质
CN116610387B (zh) * 2023-07-17 2023-10-03 杭州比智科技有限公司 一种基于动态加载和bitmap实现渠道对接及数据分析方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005521111A (ja) * 2001-07-06 2005-07-14 コンピュータ アソシエイツ シンク，インコーポレイテッド ビジネスプロセスポリシーオブジェクト
US7246349B2 (en) 2001-08-31 2007-07-17 Telefonaktiebolaget Lm Ericsson (Publ) Migration support mechanism in open service and open mobile architecture
US20040181418A1 (en) * 2003-03-12 2004-09-16 Microsoft Corporation Parameterized and reusable implementations of business logic patterns
KR100503291B1 (ko) * 2003-09-05 2005-07-22 신원정보기술주식회사 실시간 트랜잭션 처리요청 메시지의 분석과 업무처리를계층구조로 구성한 트랜잭션 통합메시지 처리시스템
KR100546774B1 (ko) * 2003-10-28 2006-01-25 한국전자통신연구원 Ｏｐｅｎ ＡＰＩ를 활용한 컨텐츠 제공 시스템 및 방법
KR20050057910A (ko) * 2003-12-11 2005-06-16 (주)엠엑스텐 실시간 트랜잭션을 지원하는 모바일 미들웨어 시스템 및모바일 비즈니스 방법, 그리고 모바일 비즈니스 개발 지원방법

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"STATEMENT IN ACCORDANCE WITH THE NOTICE FROM THE EUROPEAN PATENT OFFICE DATED 1 OCTOBER 2007 CONCERNING BUSINESS METHODS - EPC / ERKLAERUNG GEMAESS DER MITTEILUNG DES EUROPAEISCHEN PATENTAMTS VOM 1.OKTOBER 2007 UEBER GESCHAEFTSMETHODEN - EPU / DECLARATION CONFORMEMENT AU COMMUNIQUE DE L'OFFICE EUROP", 20071101, 1 November 2007 (2007-11-01), XP002456252, *
See also references of WO2007052959A1 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112738070A (zh) * 2020-12-25 2021-04-30 广州凡科互联网科技股份有限公司 一种基于web的网站微信流量监控的方法

Also Published As

Publication number Publication date
EP1949281A4 (fr) 2011-02-02
WO2007052959A1 (fr) 2007-05-10

Similar Documents

Publication Publication Date Title
EP2053552A2 (fr) Dispositif de coopération patrimoniale et procédé de traitement
WO2007052959A1 (fr) Systeme et procede assurant un support d'affaires mobile
CA2436580C (fr) Configuration d'une architecture pour un acces mobile a au moins une ressource commerciale
CN101197727A (zh) 事件更新管理系统
US7506021B2 (en) Provisioning web services
AU2002237957A1 (en) Configuring architecture for mobile access to at least one business resource
US8904485B2 (en) System and method for intermediating between subscriber devices and communication service providers
EP2026500B1 (fr) Séquenceur de messages pour événements d'entreprise corrélés
CN102348186B (zh) 用于支持不同运营商之间的账户核对的方法、系统和装置
EP1739607A1 (fr) Système et procédé de support clientèle
KR100706347B1 (ko) 개방형 모바일 비즈니스 지원 시스템의 이용 및 개발을위한 통합 지원 장치
TW200427258A (en) Common service platform and software
CN100373961C (zh) 基于智能网的短信支付方法及系统
CN1797452A (zh) 基于智能网的语音支付系统及其方法
KR20240113321A (ko) 해외 업체와의 협업을 위한 아웃소싱 협업 중개 서비스 및 유통 단일화 서비스를 제공하는 방법 및 시스템
CN116954527A (zh) 物流订单打印方法、系统以及存储介质
AU2013203565A1 (en) Message sequence management of enterprise based correlated events
KR20110099924A (ko) 통신요금을 이용한 물류서비스 운용방법 및 시스템과 이를 위한 기록매체

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080603

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FI FR GB SE

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FI FR GB SE

A4 Supplementary search report drawn up and despatched

Effective date: 20110103

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 29/08 20060101AFI20101227BHEP

Ipc: G06Q 10/00 20060101ALI20101227BHEP

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20170508

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20191116