Abstract:
The invention provides for a financial summary system and more particularly relates to a system for sending out invoices and/or statements via a multi-media messaging service (MMS).

Description:
BACKGROUND TO THE INVENTION 
       [0001]    This invention relates to a financial summary system and more particularly relates to a system for sending out invoices and/or statements via a multi-media messaging service (MMS). 
         [0002]    Multimedia messaging service is a telecommunications standard for sending messages that includes multimedia objects (images, audio, video, rich text). MMS is an extension of the Short message service (SMS) standard, allowing longer message lengths and using WAP to retrieve the content. 
         [0003]    Its most popular use is sending photographs from camera equipt handsets, although it is also popular as a method of delivering ringtones. 
         [0004]    It is common cause and that the use of technologies such as Internet and wireless communication networks is the norm of the future. However, even today many businesses utilise old means for communication such as sending out letters and statements via post and courier services. 
         [0005]    The problem with making use of older communication is that it is time-consuming and costly. Furthermore, there is a substantial time delay between the sending and receiving of such communications. 
         [0006]    A further problem generally associated with sending communication via facsimile or post is the confidentiality and security factors. It quite often happens that correspondence is lost or stolen and adds to the frustration of the sender as well as the recipient. 
         [0007]    This is especially a problem when confidential information is communicated to the intended recipient. As information can easily be “hijacked”, the confidentiality of the information to be communicated is at great risk. 
         [0008]    It is an object of the current invention to at least partially alleviate some of the aforementioned problems. 
       SUMMARY OF THE INVENTION 
       [0009]    The invention provides for a method of sending out mobile financial summaries which method includes the steps of requesting, by means of a request processor, a financial summary from a multimedia messaging service (MMS) processor; authenticating the validity of the request by means of a security module; generating a financial summary by utilising a multiple overlay technique and transmitting the financial summary to a response processor. 
         [0010]    The request processor may be any suitable handheld device such as a personal assistant digital (PDA), cellular telephone, alternatively may be a computer or Automated Teller Machine (ATM). 
         [0011]    The response processor may be in communication with a report module which in turn may be in communication with an end user but preferably is in communication with a suitable device of an end user such as a personal assistant digital (PDA), cellular telephone, a computer or any combination of the aforementioned. 
         [0012]    The security module may include any one of or combination of the following validation steps: validating if a request is received from a WAP gateway; validating Mobile Station International Subscriber Directory Number (MSISDN) (Cell Phone number); validating MSISDN or validating a personal identification number or password. In the event that any of the validation steps fails, an error message may be communicated to the request processor alternatively to the response processor. 
         [0013]    The method may further include the steps of transmitting the financial summary from the response processor to an end user, alternatively a device such as a personal assistant digital (PDA), cellular telephone, or a computer used by the end user. 
         [0014]    The device utilised by the end user such as a personal digital assistant (PDA), cellular telephone, or a computer is validated by first removing all non-numeric values and then appending the international country code if missing. 
         [0015]    The method yet further includes the steps of determining the destination Network by validating the mobile device number against predefined network data and querying the National Mobile Number Portability database to determine if a number has been ported to a different service provider. 
         [0016]    The capability of the mobile device is determined by determining the User Agent Profile or an International Mobile Equipment Identity (IMEI) number as created by the manufacturer; comparing the requested information with an internal User Agent Profile data repository and returning specific information such as the screen width, screen height, MMS support, Image support, Video support, Flash support or any combination of the aforementioned. 
         [0017]    The statement processor may include a data store in which data of various clients may be stored. The statement processor may further include and be in communication with an upload module, XML module, a content module or any combination of the aforementioned. 
         [0018]    The financial summary may include any financial information of a client, alternatively an end user and more particularly may include information such as an invoice, statement, debit note, credit note or any combination of the aforementioned. The financial summary may be displayed in accordance with a client&#39;s specific requirements, the specific requirement of the end user, alternatively as required by governing law. 
         [0019]    The upload module may include uploaded files from the client, of which each file may be assigned a unique identification means to prevent duplication. 
         [0020]    The XML module may parse and retrieve XML documents from the data store and return such data in a XML format. 
         [0021]    The content module may parse and format each request to ensure compatibility with the various handheld devices and may include any one of or combination of the following output methods: SMS, MMS, Mobi Site and XML. 
         [0022]    The report module may yet further be in communication with the data store and may be responsible for dynamic report generation. The report module may further include a default report selection, but may also include a customer preference report. The customer preference report may include anyone of or combination of the following parameters: client credentials, report number and customer filters. 
         [0023]    The multimedia messaging service (MMS) processor, also referred to as a MMS assembler may utilise a creative design module, data from an Extract Translate Load (ETL) and from a Data Preparation service to generate a financial summary. 
         [0024]    The financial summary may be generated by utilising an overlay technique in which text is overlaid by image or vice versa. The overlay may further increase security as it is more difficult to tamper with the text to image overlay. In general the financial summary information is overlaid onto a base image template which may contain the client&#39;s brand, logo and or corporate identity. 
         [0025]    The creative design module may be a design specifically specified by the end user, alternative the client, or any combination of the aforementioned and may include information such as corporate identity, unique numbers, VAT numbers, Invoice, Numbers, Credit Note Numbers, Debit Note Numbers, Statement Numbers, Transaction Dates, Purchase information, Credit information or any combination of the aforementioned. It will be appreciated that any alternate relevant info can be included in the creative design module. 
         [0026]    The Extract Translate Load (ETL) module may be utilised to automate the process of extracting data from various sources and translates the received data in a common statement format that is recognised by the MMS assembler. 
         [0027]    The data preparation may include the extracting of the mobile numbers from the ETL and validating the mobile numbers, confirming which mobile operator or service provider the specific number is assigned to and determining the associated handheld device&#39;s capabilities. 
         [0028]    The response processor may include a result module and an error module. The result module, may log and format errors that occur while executing any modules or processes and may be a result message which may either be a string or a record set containing the report information. The output format of the result module may be Text, HTML, XML or any combination of the aforementioned. 
         [0029]    The error module may log and format errors that occur while executing modules and processes and may be an error message. The output format of the error message may be Text, HTML, XML or any combination of the aforementioned. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0030]    The invention is now further described by way of example with reference to the accompanying drawing wherein: 
           [0031]      FIG. 1  is a flow diagram of the method steps according to the invention; 
           [0032]      FIG. 2  is a flow diagram of the Security module according to the invention; 
           [0033]      FIG. 3  is a flow diagram of the Upload module of the invention; 
           [0034]      FIG. 4  is a flow diagram of the XML module of the invention; 
           [0035]      FIG. 5  is a flow diagram of the Content module of the invention; 
           [0036]      FIG. 6  is a flow diagram of the Reporting module of the invention; 
           [0037]      FIG. 7  is a flow diagram of the Result module of the Invention; and 
           [0038]      FIG. 8  is a flow diagram of the Error module of the invention. 
       
    
    
     DESCRIPTION OF PREFERRED EMBODIMENTS 
       [0039]      FIG. 1  illustrates a flow diagram of a method for sending out mobile financial summaries  10  which consists of a request processor  12  a security module  14  in communication with the request processor  12 , a multimedia messaging service (MMS) processor  16  in communication with the security module  14  and a response processor  18  in communication with the MMS processor  16 . 
         [0040]    The response processor  18  consists of an error of module  20  and a result module  22 . The MMS processor  16  is also in communication with an upload module  24  which in turn is in communication with a XML module  26  and content module  28 . 
         [0041]    In one embodiment of the invention, a request is transmitted via the request processor  12  to a security module  14  for verification purposes before the request is transmitted to the MMS processor  16 . 
         [0042]    The security module  14  includes a four stage verification process as is more clearly illustrated in  FIG. 2 . The request  30  is transmitted to a MMS server  32  followed by a four stage of verification process. 
         [0043]    During the first stage  34  a validation is done to the terminal with the response from a WAP gateway. In the event that the response is not from a WAP gateway (false) an error message  36  is transmitted. In the event that the response is from a WAP gateway (true) a second stage  38  validation is conducted. 
         [0044]    During the second validation stage  38  a validation is done for MSISDN. In the event that the validation is false an error message  36  is transmitted. In the event that the validation is true a third stage validation  40  is conducted. 
         [0045]    During the third stage validation  40  the MSISDN white list is validated. In the event that the validation is false an error message  36  is transmitted. In the event that the validation is true a fourth and final stage  42  validation is done. 
         [0046]    During this final stage validation  42  any suitable identification means for example a personal identification number (PIN) or password is utilised for verification purposes. In the event that the personal identification number or password is false an error message  36  is transmitted. In the event that the personal identification number or password is true, the submission is passed and transmitted to the statement processor  16 . 
         [0047]    The statement processor  16  is in communication with an upload module  24  and herein before described. The upload module  24  is responsible for transferring files from a client to the MMS server  44  as is more clearly illustrated in  FIG. 3 . 
         [0048]    Each uploaded file  46  is assigned a unique name to prevent any duplication of an exact file. During this stage there are no expected parameters. The upload module  24  will either return a blank file in the event that no uploading of any file contents  48  has occurred, alternatively the physical file contents  48  is returned. 
         [0049]      FIG. 4  illustrates the XML module  50 . The XML module  50  is responsible for parsing and the retrieval of XML documents  52  into and from the data store  54 . The parameter expected is that of a XML document (string). The XML parser  56  is capable to return an error message  58  and is in communication with the data store  54 . The XML module  50  will return a XML document  60  containing the results based on the XML document  52  passed. 
         [0050]    The content module  28  is responsible for the output of data based on the requirements of the client (client request)  62 . Currently, the following output methods are supported: SMS  64 , MMS  66 , Mobi site  68  and XML  70  as is more clearly illustrated in  FIG. 5 . Each request  62  is parsed and formatted by the content module  28  to insure compatibility across all handheld devices. This allows for optimised content delivery for each mobile device that either receives or connects to view the requested information. 
         [0051]      FIG. 6  illustrates a flow diagram of a reporting module  70  which is in communication with the data store  44 . The reporting module  70  is responsible for dynamic report generation. A default report is included within the module, and allows for custom user reports. The reporting module  70  returns a record set  72  containing the report data as per the client request  74 . The parameter which is expected includes, but is not necessarily limited to, client credentials (security module) and a report number (integer). Various parameters may be optional and includes, but is not necessarily limited to, customer filters (filter module). It will be appreciated by those skilled in the art that many other embodiments exist and that the client will be able to choose the filter options to only display the required information. 
         [0052]    The response processor  18  includes a result module  22  and an error module  20 . The result module  22  is responsible for the logging and formatting of errors that occur while executing module or processes. The result module  22  results in a record set  80 , alternatively a text message  82  output as is more clearly illustrated in  FIG. 7 . The parameters expected, but not necessarily limited to, includes a result message (variant), the result message can either be a string or a record set containing report information. The output format includes, but is not necessarily limited to, text, HTML, XML or any combination of the aforementioned. Generally, the result module  22  will return the formatted result message  84  as a string value. 
         [0053]      FIG. 8  illustrates a flow diagram of the error module  20 . The error module  20  is responsible for the logging and formatting of errors which occurred while executing modules and processes. The parameters expected, but not necessarily limited to, include error message (string)  90  and an output format  92 , which includes but is not necessarily limited to, text, HTML, XML or any combination of the aforementioned. The error module  20  will return the formatted error message as a string value. 
         [0054]    In a second embodiment of the invention, with particular reference to  FIG. 9 , a client  100  will submit a request to a Creative Design module  102  to design the particular financial summary such as a statement or invoice. The client&#39;s  100  specific requirements are included in the design and may include information such as the client&#39;s logo, the customer name, surname, VAT numbers, invoice numbers and the like. Please note that the particular information hereinbefore said is not by any means limiting. 
         [0055]    The client  102  may communicate directly with the creative design module  100  and design his own criteria, alternatively the creative design may be done by a developer (not shown) on behalf of the client. 
         [0056]    The creative design module utilises creative templates to formalise the specific customer design. The creative design templates are designed for, but not necessarily limited to the following types of handsets: 
         [0057]    320×240—High Resolution 
         [0058]    320×240—Low Resolution 
         [0059]    240×320—High Resolution 
         [0060]    240×320—Low Resolution 
         [0061]    128×160—High Resolution 
         [0062]    160×128—High Resolution 
         [0063]    Generally, the client will submit sample data  104  to be utilised by the creative design module  102  to create a particular financial summary as per client satisfaction. 
         [0064]    Once the creative design has been approved, required data fields are mapped to the data sample  104  and a data contact (not shown) is drawn up. The data contract defines how the information pertaining to the financial summary will be obtained from the client  100 , alternative from the client&#39;s customers. For example, the necessary information may be pulled from the clients website via SFTP, alternatively may be pushed to a designated server as well as the format in which the data will be received (e.g. CSV, XML, XLS or the like) and the type of information contained in the file. 
         [0065]    In the likely event that encryption on the data exists, the encryption details (excluding the shared key) are also defined. The data contract also describes how an individual is identified in the data for example by means of identification number or by customer demand. 
         [0066]    Dependent on the data  104  received, the extract translate load (ETL)  106  process is built. The ETL  106  automates the process of extracting the data from the source. The extracted data is translated in a common statement format that is recognised by an MMS assembler  110 . The data is securely stored in a repository. An example may be a database. 
         [0067]    The data preparation  108  is done by extracting the necessary information from the ETL data  106  and compiling same by means of a data preparation service. 
         [0068]    The data preparation service confirms and authenticates that the mobile numbers are valid and associates the said mobile numbers with a particular service provider. The prepared information is transmitted to the MMS assembly  110 . 
         [0069]    During the data preparation  108  the validity of the mobile number is determined by first removing any non-numeric values and appending the international country code if missing. 
         [0070]    The destination network and more particularly the relevant service provider are determined by validating the mobile number against a predefined pattern to determine likely destination networks. Furthermore, a query is submitted to the National mobile number portability database to determine if the numbers have been ported to a different service provider. 
         [0071]    Lastly, the handset capability is also determined during the data preparation  108 . Each handset is provided with a user agent profile as well as an International Mobile Equipment Identity (IMEI) number by the manufacturer. The capability of the handheld device is utilised to generate a financial summary to comply and be displayed on the relevant mobile device. Typical information which is relevant to the particular mobile device will include but is not necessarily limited to, screen width, screen height, MMS support, image support, video support, Flash support or any combination of the aforementioned. 
         [0072]    During the MMS assembly stage  110  the MMS assembler uses the creative design  102 , the data from the ETL  106  and results from the data preparation  108  to generate an electronic financial summary. Preferably, the financial summary is a invoice, statement, Credit Note, Debit Note, or any combination of the aforementioned. 
         [0073]    The MMS assembly  110  utilises the following steps to create the electronic financial summary:
       a. Base creative templates are selected based on a recipient handset capability;   b. statement information is overlaid onto the base image template containing the client&#39;s brand, logo and/or corporate identity;   c. a presentation, alternatively slideshow is created by combining multiple overlaid images with delays in between each;   d. by overlaying the text onto the image, the layout is controlled to enable better presentation to the user as well as the recipient.       
 
         [0078]    Utilising a text to image overlay further enhances security and provides ease of mind for the recipient. 
         [0079]    In the likely event that the recipient, alternatively the client would like to make the electronic financial summary available on a mobi site, the link to the Mobi site is included. The said link can be personalised and can be secured by using online data security. 
         [0080]    In general, all the electronic financial summaries will include a sign or mark of authentication. 
         [0081]    Random samples are submitted from the MMS assembler  110  to quality control  112 . Quality control is conducted by randomly sending electronic financial summaries to a plurality of lab phones for viewing. The information contained in the MMS is checked and compared to the original data received from the client to check accuray. 
         [0082]    Once the internal quality control has been approved the batch is transmitted to the client for final approval. Upon approval of the client  100 , the MMS assembler  110  is tasked with creating MMS messages in the form of a proprietary XML language. The individual messages are grouped based on the destination network. 
         [0083]    Thereafter the messages are submitted to the broadcast module  114  which in turn submits the messages to the network operators or service providers via HTTP or HTTPS in a MM7/MM3 format, protocols defined by the third generation partnership group (3GP) or submitted to service provider in a service provider specific format. 
         [0084]    The MMS packets may contain a synchronised multimedia integration language (SMIL) file defining the presentation as described hereinbefore. All images are included as attachments and are embedded into the MMS that is transmitted to the operator or service provider. 
         [0085]    The operator or service provider may acknowledge receipt of the messages by responding with a unique reference number. In case of failure, messages are transmitted for a number of times more before they are deemed to have failed permanently. Once the operator or service provider acknowledges receipt of the message, the original MMS declaration is discarded for security purposes. 
         [0086]    At this point the operator or service provider  116  can distribute the MMS message to the end user  118  via the secured GSM, alternatively 3G network. 
         [0087]    Upon receipt of the message by the end user, the relevant handset or mobile device is requested to send out a delivery receipt back to the operator or service provider  116 . This functionality forms part of the MMS technology specification as defined by the third generation partnership group (3GP). The operator or service provider  116  passes this information on to the host  120  for storage and future use. 
         [0088]    Lastly a report is generated by a report processor  122  which is sent to the client  100  at periodic intervals. The report generally includes information pertaining to the number of messages sent, number of messages delivered to the handset or mobile device, and a number of messages that fail to be delivered. It will be appreciated by those skilled in the art that the reports may contain any relevant information relating to the process and is by no means limited to the information hereinbefore mentioned. 
         [0089]    In general, a client will request the Mobi site from an Internet ready mobile device. The request will first be processed by the security module  14  and depending on the verification request, will be communicated to the mobile device via a MobiEngine Module. The MobiEngine module will be responsible for translating and processing any data to best accommodate the graphics requirements for the mobile device. 
         [0090]    It will be appreciated by those skilled in the art that many other embodiments exist which fall within the scope of the current invention. For example, any suitable means of verification may be utilised to validate a client and the perspective request. Furthermore, any information may be uploaded to the data store, which information may then be requested by the client, and which is transmitted to the client by means of a multi-messaging service (MMS). However, the current invention particularly relates to the requesting of a financial summary by the client, which is transmitted to the client by means of a MMS.