WO2015197131A1

WO2015197131A1 - Platform for scalable customization of a data sharing environment

Info

Publication number: WO2015197131A1
Application number: PCT/EP2014/063683
Authority: WO
Inventors: Frode Van Der Laak; Kjell Wiik
Original assignee: Rtc Tech As
Priority date: 2014-06-27
Filing date: 2014-06-27
Publication date: 2015-12-30

Abstract

The invention relates to a system and method for providing scalable customization of functionality and graphical user interface for sharing of data between users with access to different end points, where each end points is provided with a network interface and a display with a graphical user interface that is identical for users defined in same work group, said system comprising. The system comprises a library of different selectable modules for communicating and sharing of data between the users at end points; a control unit comprising a user interface with controls for selecting at least one of said modules to be accessible to users defined in the same work group; a unit for generating a customized user interface based on at least one selected module, and a network connecting each end point together and for sharing data between the end points and displaying these data in identical user interfaces at end point defined for users in the same work group.

Description

Platform for scalable customization of a data sharing environment

Introduction

The invention relates to a communication platform for sharing data between users, and more specifically to a method and system providing customized scalability of functionality and graphical user interface for sharing of data between users.

Background of the invention

Internet social networks have become a significant phenomenon. Social networks allow an Internet user to create an account and a user profile and interact with other users of the social network. A social network user can share content and interact with content shared by other users. A social network may also offer chat

functionality by which users may interact with each other in real-time. Social network users typically assemble a group of friends with whom they interact. This typically gives users in the same group access to each other's profiles and the content posted on them. Content postings and other user activities may generate information that is visible to the other users defined in the same group.

A social network may provide users with increasingly sophisticated functionality. Early social networks offered little more than a simple interface for users to communicate and post messages. Now users may share different types of content and interact with each other's content in a variety of ways. In addition, as technology has evolved and social network usage has grown, tools from third-party services have been introduced to make their functionality and content available within the social network. In order to provide social network services enabling people to communicate and exchange data with each other a telecommunication network needs to be present.

US 8520823 B2 describes methods and systems for performing telecommunications activities and, in particular, to methods and systems for using Internet capabilities in conjunction with a standard telecommunication network to offer highly accessible mobile, pc, and web telephony that is a premise for communicating via social networks. This presents one example of setting up and performing

communication between different end points as in the present invention.

There are today different social networks addressing different groups and needs. A user must run several programs in order to cover specific functions found in the different programs. There is thus a need for a system and method for providing scalable customization of functionality of a social network where the layout of the graphical user interface (GUI) can be modified and adjusted according to implemented functions and required layout.

The present invention provides a scalable system (RelTime) and a method for customization of functionality and graphical user interface for sharing of data between users in a social network.

Summary of the invention

The present invention is defined by a system for providing scalable customization of functionality and graphical user interface for sharing of data between users with access to different end points, where each end point is provided with a network interface and a display with a graphical user interface that is identical for users defined in same group, said system comprises a data platform with core components for communication and data management wherein the system further comprises: a library of different selectable modules for communicating and sharing of data between the users at end points; a control unit comprising a user interface with selectable controls for selecting at least one of said modules to be accessible to users defined in the same work group; a unit for generating a customized user interface based on at least one selected module; a network connecting each end point together and for sharing data between the end points and displaying these data in the customized user interfaces at end points defined for users in the same work group.

Other features of the system are defined in the dependent claims.

The invention further comprises a method for providing scalable customization of functionality and graphical user interface for sharing of data between users with access to different end points, where each end point is provided with a network interface and a display with a graphical user interface that is identical for users defined in same group, a data platform with core components for communication and data management, said method further comprising: providing a library of different selectable modules for communicating and sharing of data between the users at end points; selecting at least one of said modules to be accessible to users defined in the same work group; generating a customized user interface based on at least one selected module; sharing data between the end points, via a network connecting each end point together, and displaying these data in the customized user interface at end points defined for users in the same work group.

Other features of the method are defined in the dependent claims.

Detailed description

The invention will now be described in detail with reference to drawings and examples, where:

Figure 1 shows an overview of the system; Figure 2 shows the architecture of the system;

Figure 3 shows another illustration of the system; Figure 4 shows a screenshot of privacy settings, and

Figure 5 shows an example of the Customer Support Portal interface.

Figure 1 shows an overview of the system according to the present invention.

The main function of the system is providing scalable customization of functionality and graphical user interface for sharing of data between users with access to different end points. The figure shows Users 1 to 4, but the number of users is unlimited. In a social network several hundred thousand can be connected. The end points can be different types of data terminals with network interfaces, and where information is presented on a display, e.g. PC, phone, tablet.

The display will show a graphical user interface that is identical for users defined in same group. This is possible in that the system comprises a library of different selectable modules for communicating and sharing of data between users located at different end points, and where the layout of the graphical user interface and the functionality is based on modules selected for users defined to belong to the same network group. The system comprises a data platform with core components for performing communication and data management.

Examples of selectable modules are one or more of the following: a contact module, a group module, a mail module, a calendar module, a document sharing module, a blog module, an album module, a course module and an encryption module. These will be further described below. In Figure 1 selectable modules are located in the Library.

The system further comprises a control unit having a user interface with controls for selecting at least one of said modules to be accessible to users defined in the same work group. In one embodiment, the control unit is a dedicated data terminal connected to the network. In another embodiment, the control unit is a module that is selectable and accessible via one or more end points that are used for sharing data between users connected via a network. One or more selected end point terminals can then be set up with the option to select and set up modules to be comprised in a specific system for sharing data between users defined in the same work group. The system is linked to an API for making tailor made applications for mobile and/or computers. Users of the system can thus create or develop their own application and layout for a specific need. The system further comprises means for generating a customized user interface based on at least one selected module. This customized user interface can be set in a Customer Service Portal or in an admin module. Security is maintained in that privacy level can be set for the users group, company or for the multi-tenancy. The generated user interface is based on which modules that are selected. Multi-tenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client-organizations (tenants). Multi-tenancy contrasts with multi-instance architectures where separate software instances (or hardware systems) operate on behalf of different client organizations. With a multitenant architecture, a software application is designed to virtually partition its data and configuration, and each client organization works with a customized virtual application. The present invention is a multi-tenancy system and method.

All elements comprised in the system are linked via a network connecting each end point together for sharing data between the end points and displaying these data in identical user interfaces at end points defined for users in the same work group. Figure 2 shows the architecture of the system according to the invention, when it is up and running different selected modules.

In addition to a system, the invention is defined by method for providing scalable customization of functionality and graphical user interface for sharing of data between users with access to different end points, where each end point is provided with a network interface and a display with a graphical user interlace that is identical for users defined in same group, providing a data platform with core components for communication and data management. The method is further comprising: providing a library of different selectable modules for communicating and sharing of data between the users at end points; selecting at least one of said modules to be accessible to users defined in the same work group;

- generating a customized user interface based on at least one selected module; sharing data between the end points, via a network connecting each end point together, and displaying these data in the customized user interface at end points defined for users in the same work group.

In one embodiment the method comprises selecting are one or more of the following: a contact module, a group module, a mail module, a calendar module, a document sharing module, a blog module, an album module, a course module, a billing module and an encryption module.

In one embodiment the method comprises creating multi-tenancy social networks by selecting different sets of modules linked to defined users.

In one embodiment the method comprises controlling the system from one or more end points connected to the network.

In one embodiment the method comprises setting up a PC, phone, or table as an end point.

In one embodiment the method comprises setting up a charging module for charging for services provided by the system.

In one embodiment the method comprises performing CSV import for mass importing or inviting users of the system.

A key component of the system which is enabling the inventive method is shown in the middle of Figure 2. It comprises a Web Service API, a Front-End Web Server which can be a farm with several servers running a program (RelTime) enabling the inventive method, and a Customer Service Portal.

The modules shown in this example are User Profile API, Notes API, Events & Groups API, Internal Messaging API, Photo Gallery API and Logging Service API. Other interfaces shown are Mobile App, Desktop App, S S API, Credit Check API, D ili Billing System API. All APIs are connected to storage devices and backups.

An Internet Web browser will provide access to the Front- End Web Server Farm. A Customer Service Portal can be accessed via RelTime Customer Service. A Mobile App and Desktop App will also have access to Web Service API . In order to facilitate scalability a Service Oriented Architecture (SOA) is

implemented. This will group the RelTime application into a number of 'services' that can be scaled independent of other services thus allowing the system to grow over time to meet demand. Figure 3 shows another example of an overview of the system where a Learning Management System (LMS) is comprised in the system.

Access to the system according to the invention can be performed via any data terminals with a network interface and running a network browser.

In the context of a HTTP transaction, basic access authentication is RTC method for a HTTP user to provide a user name and password when making a request.

HTTP Basic authentication (BA) implementation is the simplest technique for enforcing access controls to web resources because it doesn't require cookies, session, identifier and login pages. Instead HTTP Basic authentication uses static, standard HTTP headers meaning that no handshakes have to be done in anticipation. The BA mechanism provides no confidentiality protection for the transmitted credentials. They are merely encoded with Base in transit, but not encrypted or hashed in any way. Basic Authentication is, therefore, typically used over HTTPS.

Because the BA header has to be sent with each HTTP request, the web browser needs to cache credentials for a reasonable period of time to avoid constantly prompting the user for their username and password. Caching policy differs between browsers. Microsoft Internet Explorer by default caches them for 15 minutes.

While HTTP does not provide a method for web server to instruct the browser to "log out" the user (forget cached credentials), there are a number of workarounds using specific features in various browsers. One of them is redirecting the user to an URL on the same domain containing credentials that are intentionally incorrect. This behaviour is however inconsistent between various browsers and browser versions.

Protocol used on the Server side: When the server wants the user agent to authenticate it towards the server, it can send a request for authentication. This request is sent using the HTTP 401.

Protocol on the Client side: When a user sends the server authentication credentials it uses the Authorization header. The Authorization header is constructed as follows: 1. Username and password are combined into a string

2. The resulting string literal is then encoded using the RFC2045-MIME variant of Base64.

3. The authorization method and a space i.e. "Basics" are then put before the encoded string.

TLS protocol allows client-server applications to communicate across a network in a way designed to prevent eavesdropping and tampering.

Protocols operate with SSL and TLS. If the client and server have agreed to use TLS, they negotiate a connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection's security:

1 ) The client sends the server the client's SSL version number, cipher settings, session-specific data, and other information that the server needs to communicate with the client using SSL. 2) The server sends the client the server's SSL version number, cipher settings, session-specific data, and other information that the client needs to communicate with the server over SSL. The server also sends its own certificate, and if the client is requesting a server resource that requires client authentication, the server requests the client's certificate.

3) The client uses the information sent by the server to authenticate the server, e.g. in the case of a web browser connecting to a web server, the browser checks whether the received certificate's subject name actually matches the name of the server being contacted, whether the issuer of the certificate is a trusted certificate authority, whether the certificate has expired, and, ideally, whether the certificate has been revoked. If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client proceeds to the next step.

4) Using all data generated in the handshake thus far, the client (with the cooperation of the server, depending on the cipher in use) creates the pre-master secret for the session, encrypts it with the server's public key (obtained from the server's certificate, sent in step 2), and then sends the encrypted pre-master secret to the server.

5) If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case, the client sends both the signed data and the client's own certificate to the server along with the encrypted pre-master secret.

6) If the server has requested client authentication, the server attempts to authenticate the client. I the client cannot be authenticated, the session ends. If the client can be successfully authenticated, the server uses its private key to decrypt the pre-master secret, and then performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret.

7) Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity (that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection).

8) The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished.

9) The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished.

The SSL handshake is now complete and the session begins. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.

This is the normal operation condition of the secure channel. At any time, due to internal or external stimulus (either automation or user intervention), either side may renegotiate the connection, in which case, the process repeats itself.

This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes.

If any one of the above steps fails, the TLS handshake fails and the connection is not created.

In step 3, the client must check a chain of "signatures" from a "root of trust" built into, or added to, the client. The client must also check that none of these have been revoked; this is not often implemented correctly, but is a requirement of any public- key authentication system. If the particular signer beginning this server's chain is trusted, and all signatures in the chain remain trusted, then the Certificate (thus the server) is trusted.

RTC use Go Daddy with 128-bits encryption for the Authority of providing

Certificate. Other providers are also feasible. The digital certificate certifies the ownership o a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or assertions made by the private key that corresponds to the public key that is certified. In this model of trust relationships, a Certificate Authority (CA) is a trusted thi d party that is trusted by both the subject (owner) of the certi ficate and the party relying upon the certificate. OAs arc characteristic of many public key infrastructure (PKI) schemes.

A public key infrastructure is a set of hardware, software, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates.

In cryptography, a PKI is an arrangement that binds public keys with respective user identities by means of a CA. The user identity must be unique within each CA domain. The third-party validation authority (VA) can provide this information on behalf of CA. The binding is established through the registration and issuance process, which, depending on the assurance level of the binding, may be carried out by software at a CA or under human supervision. The PKI role that assures this binding is called the registration authority (RA), which ensures that the public key is bound to the individual to whom it is assigned in a way that ensures non- repudiation. The system according to the invention can also create privacy based on Email restriction. In this case the Email setting can be limited from corporate to only support, e.g. name@corporateURL.com.

SMS verification is also feasible with the system according to the invention. SMS Registration Verification can be set by performing the following steps: 1) SMS Verification on registration and login-authentication using SMS.

2) On a per -tenant basis, we want a SMS verification on user-registration with mobile, (if selected in CSP).

3) Then on a user-basis we would want the user to be able to select "Login using SMS verification and password". Upon where they would receive a SMS on their cell phone with a code they would have to input as well as their password when logging in.

4) It would be a two-step login feature. Optimally it would be pre-set by the tenant "Use mobile verification as default", then the users individually can change this. The steps on the user side will be:

1) Login to http://vca.reltime.com/Profile/Person Chose to activate 2 -step verification.

2) Description of how this will work. A short description will be present to the users.

3) Activation on phone. Activate the phone by sending a SMS to the users with a activation code.

4) Verification. Enter the verification code.

In the following the PBX, trunk and job server will be described in detail, as well as PBX and trunk configuration. The technology solution is based on SIP VOIP standard, mainly because of cost efficiency, but also because of the flexibility with not having a PSTN line in-house. Some features of the SIP standard are that it allows sending all kinds of data over the same protocol for instance IPFAX, pictures and live video feed.

Using this protocol gives a lot of freedom to expand the platform to serve video calls and other media streaming.

Telecom Platform is a free telephony engine and tool kit, and includes all the necessary tools to produce an up to date telephony service.

Today the current solution uses Telecom Platform 1.2 as a trunk server, the connection to the SIP/Trunk because of some issues regarding Telecom Platform 1.4 as trunk to the vendor. Telecom Platform 1.4 is a newer and more powerful version of Telecom Platform 1.2. The main improvement is the conference module and the support for IPFAX and a number of security/performance fixes.

For encoding the G.711 μ-law is used in the United States and G.71 1 A-law is used in Europe to confirm with the G.771 standard, where the quality is not excellent. RTC is also transporting Call over VPN tunnel, and therefore supports: Speed 16Khz and 8 Khz, GSM, ILBC, PCMU, PCMA.

Using G.71 1 for VoIP will give the best voice quality; since it uses no compression and it is the same codec used by the PSTN network and ISDN lines, it sounds just like using a regular or ISDN phone. It also has the lowest latency (lag) because there is no need for compression, which costs processing power. The downside is that it takes more bandwidth than other codecs, up to 84 Kbps including all TCP/IP overhead. However, with increasing broadband bandwidth, this should not be a problem. Since this is free and built into the Telecom Platform 1.4 release this is the preferred codec to be used for the telecom solution.

Different features of Telecom Platform can be used in the telecom solution.

Telecom Platform has a built in conference module named RelConference that can be used for the conference call system. It has all the features needed by a conference system.

The only reason for choosing another conference module in the future is the lack o mute option for users, this would be very useful for the moderator of the conference to choose which parties that may listen or not. The telecom platform is unique in that users can change the number called from, for example if travelling to other places.

On the SIP/Video support RTC has a technology that say 'one common account' for all service, this means one of the first products that will be provided is SIP/Video (free between users) and the possibility to call out from RTC network for a local termination 'local cost' this service is supported with the RT client from Iphone, Android, Mac and Windows, and for Video support Android, Win and Mac, in version 4S of the iPhone.

In the following the different modules that may be comprised in the system will be described. The system is accessed via a web portal, e.g. web browser or app. The web portal works as a backbone for all API (Application Programming Interface) requests, and sends the request to the server (RelTime system). The work will then be distributed to the first available server.

The web portal is where the users sign up for the services that are provided by the system when set up. It has an easy to use interface and is totally independent of the telecom, transaction and other solutions.

The system is easily expandable due to the Web interface accessing the system. A primary client for accessing the system can be based on distribution from App Store, Android Market, Microsoft Market, and a version that runs on almost all mobile phones with Java support.

A control module is for controlling which information that is to be accessible to users/groups/companies/courses and for the whole multi-tenancy.

Figure 4 shows a screenshot with an example of how much information about a group/company that can be accessed by other. This can be set in the control module which is accessible for users. Customer Support Portal (CSP) module provides support for users of the system. By logging in via this portal all of multi-tenancy, language and other can be controlled.

One strong feature is that CSV import can be performed by mass importing/inviting users to the system. Users can be linked together, for example for a firm. Figure 5 shows an example of the CSP interface.

A contact module (address book) will comprise an address book that can be is automatically synced with clients when connected. Such a feature makes data on the portal and the clients always consistent.

In the address book you can find all contacts via the portal, mobile client, PC client, and also import users from phone with vCard, create users group, example student for a teacher, so message and call can be set up easy without adding several contact, but do this in one task.

Customer control panel is a module that will provide a user with the option to select what information that is accessible to others as well as performing payments and viewing statistics, e.g. calling statistics.

With the Help module users may browse online help for answers to the most frequently asked questions. A live help system can also be provided for the users that really need help as soon as possible, or have questions regarding the services.

The user profile is the module where the user presents himself, some information is required to get access to the community, such as primary email address and primary mobile phone number. These attributes are required so each component of the system may reach that user in some way, either by mobile phone or by email notification.

A user controls each attribute he wants to expose to other users of the system, such that not all attributes necessary are shown to the public or a guest of the profile.

Each user profile has a wall, were friends might write a message, or information can be posted if one wants to share this with all the friends.

Different groups can be defined in a group module. Every user may form groups, the only criteria is that there is no group with the same name. Default groups can also be defined. This means that a user can import other users to a default group, for example linked to a football club (supporters, members, players, etc.) In this way, the G oup owner will have a unique platform for the members. The default group can have the left logo example now Oxford Student

Organization', and will in this case have a 'loyalty' system for the member, then the front, login info and member is imported in a safe and preferred system without external influence.

In the group settings, the 'owner' of a group can set executive members that can publish news, etc.

A Mail module is a standard module for sending and receiving mails.

A calendar module of the community (users defined in the same group) can be used to sync against mobile clients, iCal or Outlook. When they are all synced a meeting or some other event written in the calendars of the community will be accessible. Other contacts may send events directly to a calendar and it will automatically be downloaded to the clients when syncing the next time.

A document sharing module, which is a standard module for sharing documents, is also incorporated into the system. As is a blog module and an album module.

One strong feature of the system according to the invention is a Course module where each group can create a classroom or course that will be integrated into the system. Members can be added or removed and setting for each member can be set.

A classroom is a place where the user may take lecture online, as online course with live video sessions, document share, upload and chat. This includes batch upload of several documents and/or videos.

A multi-tenancy classroom can be created. Each multi-tenancy (a defined Social network) has the possibility to add own course and classroom. Access to a classroom can be free or possibility charged.

The course module have the following components implemented: accessing a live class, view all related course document, view the content of the Course and related info, to chat, add folders and documents and add questions.

One part of the Classroom is based on a live system comprising several parts describe below. A front view of the live class where the users, e.g. an administrator, can mute, set preference and other important control function. The view of a class can also be changed. If the end points of the users support video and microphone, the communication can be performed over Video/Voice.

Chatting can be performed live and private between 2 members of a class or to chatting can be between all.

Member can search for courses or get an invitation from an administrator.

Security module (encryption module) is also incorporated into the system. It is possible to customize security element based on the multi-tenancy requirements. This means that the strength of the encryption can be adjusted according to authentication, e.g. normal, double, or none.

The element for security can also be set to allow to open or secure a specific company mail domain for people that want to register, e.g. using

@companymail.com.

In a photo/video module, photos and videos can be shared with contacts by uploading them to the community and let the friends view them.

Another strong feature of the system according to the Revenue module providing the possibility to invoice for services, i.e. a billing system) The Telecom Platform server generates call detail records (CDR) and stores them in the billing system's my SQL database. When the users send an SMS, the CDR is generated from the SMS system and then stored in the same my SQL database.

A 4-core CPU this system is capable of 4 Million CDRS an hour (one Call Data Record is here a call, an SMS, a transaction, etc.) and up to 100 million users in this version.

The whole system can be created in SQL; the current implementation is MS SQL but it is possible to develop it in MySql if needed. The system is fully modifiable to suit every need, and may operate separately on another system.

The core modules of the billing system and engine will now be described.

The billing system produces and implements a robust core system that can be integrated with almost any 3rd party system and be customized to suit current and future needs.

By using the Billing and Customer Management engine in conjunction with a custom-built user interface the flexibility and scalability is great. With regards to scalability, the billing is built on Microsoft® SQL Server, a highly robust and scalable enterprise-class database solution. SQL supports up to 64 processors, 64 GB RAM (1TB on Itanium) and an unlimited database size.

With regards to integration, the system allows external devices to access the billing data and system functions via web services (SOAP API) or directly stored procedure execution. With appropriate permissions, an external system can perform any function available within the billing in a simple web service call or database call.

With regards to customization, the billing system is built to be customized. Code injection points are used to allow site-specific customizations to be embedded into core routines. This type of injection gives the ability to alter system behaviour by simply ' plugging in' new code.

The system is further well suited for custom user interfaces. This allows to make the user experience as streamlined, efficient and pleasant as possible.

Accounting Integration can be performed by integrating the billing system with any back-end financial s to complete a tailor made business management system.

Recurring Billing is one of the possibilities and the system is ideal for any company that requires recurring billmg for its services or products. One can add as many recurring fees to an account as needed. Charges are automatically created during statement processing. Charges can be set up to automatically prorate for customers who activate or deactivate mid-cycle. One can assign equipment to an account and associate recurring charges to the equipment. Charges are created while the equipment is on the account and automatically shut off when the equipment returns to inventory.

Customers can also log into the web portal to view their balance, historical statements and make payments.

The system further allows consumption billing and enables import of consumption readings from any format or they can be entered them by hand.

An unlimited number of rates and rate components can be configured. Rate components include per-day, fixed charge and stepped-range components.

Consumption-based components can have minimum amounts specified.

Bills by customer range, cycle or route can be calculated an issued. One can also opt to final bill only accounts that are flagged for closing.

The system comes with a complete equipment management module where connects/disconnects, service, and equipment switches can be scheduled. Custom service orders can also be created in the system.

The system will allows for metered billing by importing metered readings from almost any format or they can be entered by hand.

An unlimited number of rates and rate components can be configured. Rate components include per-day, fixed charged and stepped-range components.

Consumption-based components can have minimum amounts specified.

Issue bills by customer range, cycle or route can be calculated. One can also opt to final bill only accounts that are flagged for final read and close. The system comes with a complete equipment/meter management module where connects/disconnects, service, and meter switches can be scheduled. You can also create custom service orders in the system.

The system according to the invention contains two web portals; one for

administrators of the system and one for users of the system.

With the Customer Web Portal existing users (customers) can log into their account, view their balance, view all historical bills and make payments. New customers can also sign up for services.

The Admin Web Portal provides can access the billing system from anywhere. New customers can be added, existing accounts can be managed, as well as record payments, new charges, change customer billing setup, view reports etc.

An unlimited number of currencies and their conversion rates can be configured.

During creation of a customer, the currency one would like to interact with that customer can be created. During billing base charges will be converted to the customer's chosen currency.

An Invoicing module is used to invoice customers for parts or labour. Invoices can be posted straight to the account or they can be issued initially as quotes and then posted as invoices upon acceptance.

Different receivables and revenue accounts for each line item can be set up, and the quote/invoice templates can be customized to give a specific personal layout.

Invoicing is integrated with Inventory to automatically control inventory counts as items are sold.

Penalty Calculation can be performed based on Outstanding Amount, Original Amount or Original Amount Less Tax. An unlimited number of penalty types can be set up in the system and assigned to individual accounts. Minimum amounts for the penalty or the penalized items can further be configured. Penalties can be compounded or simple. Assigning of the proper penalty type to each account is performed by mass-calculating Billing Cycle, Due Date or Route.

A Collections module manages outstanding receivables. Over 200 steps can be comprised in the collections process. At each step one specifies the overdue amount, days since payment and days since last notice required qualifying an account for each step.

Outgoing communication is completely customizable. The system includes templates for friendly reminder letters, disconnect notices and reports for collection agencies. Charges can be automatically added to accounts as they reach specific collection steps. Accounts can also be automatically deactivated upon reaching a specific step in the collections process.

Which action settles an account can be specified, e.g. full payment, partial payment, overdue items only, etc.

Payment arrangements can be made to stagger payments for customers with overdue balances. This can help preventing accounts from becoming bad debt.

A Sales Agent Management module allows creating agents, defining their commissions and assigning the agents to accounts. As receivables are created on the accounts, the commission rates are retrieved and a commission amount is calculated and earmarked to the agent.

Once the receivable is completely paid, the previously calculated commission becomes eligible for payment to the agent.

Reports can be ran to review agent performance and export the details to Excel® Other types of handling by the system includes Shipping Management, Deposit Handling, Deposit Interest Calculation, Equipment Management, Service Orders, Inventory Management, Asset Management, General Ledger, Electronic Funds Transfer, Optimal Payments, Secure Payment, PayPal/other payment gateway and Data Import/Export. Data import and export has two primary functions. The first is to bring in data from a legacy system and the second is to synchronize with external systems on a regular basis. Built-in import functions include customers, addresses, contact information, customer notes, recurring charges, one-time charges, payments, deposits, assets, call records and equipment. Call records, web logs, media service logs can also be imported, consumption readings and meter readings in multiple formats for regular billing.

Our built-in export functions include customers, addresses, distributions and meters in multiple formats.

Custom import and export functions are added as necessary and can easily integrate with any systems.

The system comprises several hardware interfaces to increase productivity or add functionality to the system. The first, and most important, is the barcode reader. All of the data entry screens are compatible with most barcode readers and all reports and outgoing literature can have barcodes embedded in them. This functionality can greatly increase productivity and reduce user error. One hardware interface is to digital media. Pictures can be taken with a webcam attached to the PC or imported from a digital camera or other digital storage. This is useful when one need to associate pictures to a specific account.

There are several additional features of the system that isn't specific to any module but serve to improve the usability o the system.

One of these is that the system will estimate the time of completion for any routine that is expected to ake more than 2 minutes. This includes routines such as bill calculation, batch posting, collections processing, data import (batch CSV import of users) and much more. Many screen labels in the system are customizable to accommodate regional spelling differences and industry terminology.

All error messages in the system can be customized to instruct the user as to how to handle a specific error that he or she may encounter.

The system allows individual users to create custom shortcut menus. These shortcuts may be used to open reports, third-party products or integration components.

Pictures can be taken with a webcam or imported from digital media and be associated to accounts.

The advantage of the system and method according to the present invention is the scalability and that it can be adjusted and tuned to any need and layout.

Claims

A system for providing scalable customization o functionality and graphical user interface for sharing of data between users with access to different end points, where each end points is provided with a network interface and a display with a graphical user interface that is identical for users defined in same group, said system comprises a data platform with a core components for communication and data management wherein the system further comprises:

a library of different selectable modules for communicating and sharing of data between the users at end points; a control unit comprising a user interface with selectable controls for selecting at least one of said modules to be accessible to users defined in the same work group;

- a unit for generating a customized user interface based on at least one selected module;

a network connecting each end point together and for sharing data between the end points and displaying these data in the customized user interface at end points defined for users in the same work group.

A system according to claim 1, where the selectable modules are one or more of the following: a contact module, a group module, a mail module, a calendar module, a document sharing module, a blog module, an album module, a course module, a billing module and an encryption module.

3. A system according to claim 1, where the control unit is comprised in one or more end points connected to the network.

A system according to claim 1, where an end point is a PC, phone, or tablet.

A method for providing scalable customization of functionality and graphical user interface for sharing of data between users with access to different end points, where each end point is provided with a network interface and a display with a graphical user interface that is identical for users defined in same group, providing a data platform with core components for

communication and data management, said method further comprising:

- providing a library of different selectable modules for communicating and sharing of data between the users at end points; selecting at least one of said modules to be accessible to users defined in the same work group; generating a customized user interface based on at least one selected module;

- sharing data between the end points, via a network connecting each end point together, and displaying these data in the customized user interface at end points defined for users in the same work group.

6. Method according to claim 5, comprising selecting are one or more of the following: a contact module, a group module, a mail module, a calendar module, a document sharing module, a blog module, an album module, a course module, a billing module and an encryption module.

7. Method according to claim 5, comprising creating multi-tenancy social networks by selecting different sets of modules linked to defined users.

8. Method according to claim 5, comprising controlling the system from one or more end points connected to the network.

9. Method according to claim 5, comprising setting up a PC, phone, or table as an end point.

10. Method according to claim 5, comprising setting up a charging module for charging for services provided by the system.

1 1 . Method according to claim 5, comprising performing CSV import for mass importing or inviting users of the system.