WO2011055002A1

WO2011055002A1 - Arrangement and method for electronic document delivery

Info

Publication number: WO2011055002A1
Application number: PCT/FI2010/050773
Authority: WO
Inventors: Martti PITKÄNEN
Original assignee: Aplcomp Oy
Priority date: 2009-11-03
Filing date: 2010-10-06
Publication date: 2011-05-12
Also published as: FIU20090395U0; FI9059U1

Abstract

An arrangement, such as a server (106) or a plurality of at least functionally connected servers, for delivering an electronic document, such as a bill, to a recipient utilizing multi-factor authentication, said arrangement comprising a processing entity (150) and a memory entity (152) for processing and storing data, respectively, and a data transfer entity (156) for receiving and sending data, said arrangement being configured to receive and store an electronic document provided by a sender for delivery to a predetermined recipient (126),send an e- mail including a notice indicative of the reception of the electronic document to an e-mail address associated with the predetermined recipient, said e-mail notice including a secure link for a browser (128),receive an indication of the activation of the secure link (132), in response to which said arrangement being further configured to,send first browser data, such as web page data, requesting the user of the browser to input a secret (136), send a one-time password (OTP) to a mobile device associated with the predetermined recipient (138b),receive user input relative to the request for secret (140), determine whether the user input matches the sent OTP (142), and if that is the case,enable the user, thus authenticated as the predetermined recipient, to access the electronic document (144).A corresponding method is presented.

Description

ARRANGEMENT AND METHOD FOR ELECTRONIC DOCUMENT DELIVERY FIELD OF THE INVENTION

Generally the invention pertains to digital delivery of electronic documents utilizing a communications infrastructure such as a communication network. In particular, however not exclusively, the invention concerns secure document delivery incorporating authentication.

BACKGROUND

Access control in conjunction with network services may imply user identification, which may be generally based on a variety of different approaches. For example, three categories may be considered including anonymous, standard and strong identification. Regarding anonymous case, the service users do not have to be and are not identified. Standard, or 'normal', identification may refer to what the requestor for access knows, such as a password, or bears such as a physical security token. Such a token may include password-generating device (e.g. SecurlD™), a list of one-time passwords, a smart card and a reader, or a one-time password transmitted to a mobile terminal. Further, strong identification may be based on a biometric property, particularly a biometrically measurable property, of a user, such as a fingerprint or retina, or a security token the transfer of which between persons is difficult, such as a mobile terminal including a PKI (Public Key Infrastructure) certificate requiring entering a ΡΓΝ (Personal Identification Number) code upon each instance of use.

On the other hand, network service -related authentication, i.e. reliable identification, may also be implemented on several levels, e.g. on four levels, potentially including unnecessary, weak, strongish, and strong authentication, wherein the strongish authentication, being stronger than weak, thus resides between the weak and strong options. If the user may remain anonymous, authentication is unnecessary. Weak authentication may refer to the use of single standard category identification means such as user ID/password pair. Instead, strongish authentication may apply at least two standard identification measures utilizing different techniques. With strong authentication, at least one of the identification measures should be strong. Considering the terminology used in the domain, "documents" such as "bills" or "invoices" may be electronically transferred e.g. as "e-documents", "e-bills", or "e-invoices", respectively. An e-bill may be electronically provided to a recipient e.g. a consumer, such that the recipient fetches the bill e.g. in HTML (Hypertext Markup Language) or PDF (Portable Document Format) form utilizing the bank or other bill operator network service, for instance. The "e-invoice" may be sometimes used to specifically refer to a bill provided e.g. in XML format especially from a company to another (B2B, business-to-business) in contrast to "e-bill" that is then addressed to a consumer instead. The recipient may fetch the e-invoice utilizing the service offered by the bill operator. However, hereinafter the terms "bill", "e-bill", "invoice", and "e-invoice", and terms derived therefrom, are used interchangeably in the context of the present invention.

Correspondingly, a "bill sender" may refer herein to the sending party of the bill or of some other electronic document created by the sender for delivery to the intended recipient, or "user", of the bill or of other document, respectively. Typically the sender is the "seller" and the user is the "buyer" in connection with a bill relating to a purchase and related financial transaction. The term "invoicing operator", or "e-invoicing operator", may refer herein to one or more entities such as banks and/or other third parties taking part in the data transfer process, i.e. receipt of the bill from the bill sender, forwarding to a second operator, and/or delivery to the actual recipient. Bills may be generally delivered electronically utilizing weak, strongish, or strong authentication. For example, strongish access control is applied also in connection with other network services than mere bill delivery, including e.g. payment and user information management. Notwithstanding the various advancements taken place during the last years in the context of user and service identification, authentication, and related secure data transfer, some defects still remain therewith and are next briefly and non- exhaustively reviewed with useful general background information. The invoicing operators may validate the received bills using the standard scheme of the applied XML format such that data diverging therefrom is not transferred forward. An electronic document may be provided with embedded secure links. For example, applicable U I (Universal Resource Indicator) schemes including a unique (network) address of the document to be obtained may be utilized. A secure link may be included in the electronic document for arranging a means to the recipient to obtain further, e.g. explanatory, information about the document from the network server.

Roughly, access control methods to network services include push and pull methods. In pull methods, the user may first identify oneself anonymously to a network service providing a login screen in return. The user may then type in the user ID and corresponding password, whereupon he/she may directly access the service or be funneled into the subsequent authentication phase. In push methods, a network server may first transmit information, such as a bill or receipt, authorizing the user to access the service to the e-mail address of the user. Preferably only the user knows the password of the e-mail account.

Few risks are associated with the push model, however. For example, spammers may send e-mails camouflaged as bills or receipts. This may be overcome by certifying the sent e-mails with selected standard -compliant sender's signature among other options. The recipient may verify the identity of the sender and integrity of the e-mail. The sender may apply the PKI certificate of a sufficiently well-known issuer (may be pre-installed in an e-mail client, for example) for the signature. Digital signature may be implemented programmatically as a routine task in connection with document delivery.

Reverting to pull methods, notwithstanding the actual nature of a pull-type method, the user indeed first anonymously accesses a network server in order to be able to log in with appropriate user ID. The user may store the server address in one's desktop computer or manually enter it in a browser address field. In addition, the user has to remember a service- specific password or other secret.

Additionally, the users are often reluctant to manually manage a plurality of user IDs and corresponding passwords. As a result, they may utilize the very same user ID and/or password in multiple services and/or use rather obvious and thus easy-to-crack words, numbers, or expressions as passwords. Even if the access control management systems requires using a strong password, i.e. hard-to- remember password, a risk that the user writes the password down increases considerably and the authentication level turns ultimately weak. Yet, the utilization of a password is typically enabled by access control management entity that also stores the password locally. If the security of the data repository is later jeopardized, third parties may acquire all the passwords stored therein. Also if the user forgets the password or it has to be changed for some other reason, actions have to be taken by the user and optionally the service provider. The user has to memorize the new password.

Further, the adoption of a personal, network service-specific token such as a smartcard and corresponding reader device may require intensive training. The increase in the use of smart cards correspondingly raises the risk of thefts and provision of replacement cards.

As already mentioned hereinbefore, the (e-)invoicing operators may require providing data in accordance with a predefined XML standard scheme. Therefore, provision of data, e.g. bill data, such that the scheme is not completely followed (e.g. maximum field length may be exceeded in the data relative to a single field) may result in the interruption of the data transfer. Thus, only the payload that follows the scheme may be delivered to the users. Delivery of electronic bills via operator(s) requires management of e-invoice addresses associated with the users in the system of the sender. When a bill is delivered via multiple operators and both the sender and recipient utilize different operator, somewhat tricky problems may arise in terms of traceability etc. in case the recipient has not received the bill. Due to the usage of invoicing operators, a delay caused between the transmittal and receipt as the data has to be transferred to the operator system first. The sender and optionally the recipient may be subjected to delivery fees to cover the operator expenses.

Relatively sophisticated and at least nationally standardized transmission protocols are required to guarantee reliable delivery of a document such as a bill from an invoicing operator to the final recipient (user) despite of the bank or other operator selection(s) of the recipient. Only a modest portion of all population is living in countries where the requirements for efficient delivery of e-bills are nowadays fulfilled. It is thus unlikely that electronic delivery of bills within the banking systems soon becomes a global practice.

Country border and banking standards crossing document, e.g. bill, delivery introduces even more challenges. When the sender and recipient cannot utilize different invoicing operators, the sender has to make contracts with each operator that is used by any of his clients. In most cases the sender has to install separate functionalities for each operator. If the user is accustomed to fetch the e-bills via online banking service, upon termination of a banking relationship, the previously arrived bills cannot be retrieved anymore. Accordingly, use of online banking services may impede changing the bank. Additionally, traditional e-mail bills provided using a push- model delivery are weak in terms of information confidentiality, comparable to an ordinary post card, for example. If the message payload including body text and potential attachments is encrypted for transfer, the mail server of the recipient may reject the transmission as it cannot analyze the mail for malicious software, for instance. Decryption may require using either PKI-type encryption (encryption via public key of the recipient) or symmetric encryption, the use of which is in large scale impracticable. Delivery cannot be ascertained either as the e-mail clients typically have manual override functionality for omitting sending receipt acknowledgements.

SUMMARY OF THE INVENTION

The objective is to at least alleviate one or more problems described hereinabove regarding usability issues and security risks, such as authentication risks, associated with the contemporary electronic document delivery solutions. The objective is achieved by the arrangement, such as an apparatus or a system of multiple apparatuses, and method in accordance with the present invention disclosing electronic document delivery preferably incorporating e-mail account and mobile device -related communication resulting in at least two-factor authentication in conjunction with the overall procedure, which enables both trustworthy authentication and pleasant use experience. Various electronic documents may be programmatically transmitted from a database to registered recipients, for instance.

Accordingly, in an aspect of the devised solution an arrangement, such as a server apparatus or a plurality of at least functionally connected server and/or other apparatuses, for delivering an electronic document, such as a bill, to a recipient utilizing multi-factor authentication, comprises a processing entity and a memory entity for processing and storing data, respectively, and a data transfer entity for receiving and sending data, the arrangement being configured to receive and store an electronic document provided by a sender for delivery to a predetermined recipient, send an e-mail notice, indicative of the reception of the electronic document to an e-mail address associated with the predetermined recipient, the e-mail notice including a preferably secure link for a browser, such as an Internet browser, receive an indication of the activation of the preferably secure link, such as a data request like a web resource request sent via a browser, in response to which the arrangement being further configured to send

-first browser data, such as web page data, requesting the user of the browser to input a secret, and

-a one-time password (OTP) to a mobile device associated with the predetermined recipient, receive user input relative to the request for secret, determine whether the user input matches the sent OTP, and if that is the case, enable the user, thus authenticated as the predetermined recipient, to access the electronic document.

The enablement may include sending data such as second browser data, e.g. a user interface web page of the associated network service, enabling the user to fetch the electronic document via a download link. Alternatively, the enablement may include transmitting at least part, e.g. one or more pages, of the electronic document either as stored or in a converted format substantially directly to the user without intermediate steps like link provision and link activation requiring further user action. As one example, data defining a web page and including the document or a link to the document may be provided.

In one embodiment, the arrangement is location-aware advantageously in a sense it utilizes location information to authenticate the user as the predetermined recipient. A number of predetermined locations may be associated with each user of the arrangement. For example, the location may refer to at least one element selected from the group consisting of: address, network address, sub-network, IP (Internet Protocol) address, IP sub-network, cell, cell-ID, street address, one or more coordinates, GPS coordinates, GLONASS coordinates, district, town, country, continent, distance from a predetermined location, and direction from a predetermined location. Each of the aforesaid addresses may refer to an address range. Failed location-based authentication may result in a failed overall authentication (denied access), or alternatively, a limited functionality such as limited access to the document and/or document delivery service may be provided. The same applies to other authentication factors. Each authentication factor may be associated with a characterizing weight (effect) in the authentication process.

A certain location may be associated with a certain user by "knowing" the user, which may refer to optionally automatically profiling and learning the user via monitoring one's habits such as location and optionally movements. As a result, a number of common, or "allowed", locations may be determined and subsequently utilized for authentication purposes. Additionally or alternatively, the user may manually register a number of allowed locations for utilizing the document delivery solution in the arrangement.

In one other, either supplementary or alternative, embodiment the secure link may include a U I with an applicable scheme such as a HTTPS scheme implying the use of SSL/TLS (Secure Sockets Layer/Transport Layer Security) protocol for encrypting traffic between the browser and the server. Alternatively, the traffic may be encrypted utilizing some other method. The link may include an address of a web page including the first browser data for user input. The address may contain a secure element that is practically impossible to guess or deduce. The secure element may include a hash such as an MD5 (Message-Digest algorithm 5) hash, for instance, for the determination of which document data and secret key of the server may have been applied. In a further, either supplementary or alternative, embodiment the notice (e-mail) may be provided as digitally signed utilizing a substantially S/MIME-compliant (Secure/Multipurpose Internet Mail Extensions) identity certificate, OpenPGP (Pretty Good Privacy, RFC 4880)-compliant identity certificate, and/or X.509- compliant identity certificate. The options are not necessarily mutually exclusionary. E.g. X.509-compliant certificate may be utilized in connection with S/MIME e-mails. Yet in a further, either supplementary or alternative, embodiment the documents are stored preferably in a relational database. Preferably the documents are stored, optionally solely, as XML-structured and converted to a readable and/or otherwise visually legible visualization upon presentation. For example, conversion into a web browser visualizable form and/or PDF form is possible.

Still in a further, either supplementary or alternative, embodiment a text message, such as an SMS-compliant (Short Message Service) message, is utilized as a carrier of the OTP. Alternatively other message such as a multimedia message, e.g. an MMS (Multimedia Messaging Service) message, may be exploited.

In another aspect, a method for delivering an electronic document, such as a bill, to a recipient utilizing multi-factor authentication, comprises receiving and storing an electronic document provided by a sender for delivery to a predetermined recipient, sending an e-mail indicative of the reception of the electronic document to an e- mail address associated with the predetermined recipient, said e-mail including a preferably secure link for a browser, receiving an indication of the activation of the preferably secure link, sending first browser data, such as web page data, requesting the user of the browser to input a secret, sending a one-time password (OTP) to a mobile device associated with the predetermined recipient, receiving user input relative to the request for secret, determining whether the user input matches the sent OTP, and if that is the case, enabling the user, thus authenticated as the predetermined recipient, to access the electronic document.

The previously presented considerations concerning the various embodiments of the arrangement may be flexibly applied to the embodiments of the method mutatis mutandis, and vice versa, as being appreciated by a skilled person.

The utility of the present invention follows from a plurality of issues depending on each particular embodiment. The suggested solution potentially enables applying e.g. strongish authentication such that the use experience is improved, security risks are mitigated, and the supply chain of documents such as bills or account statements among numerous other options is shortened. For example, a prescription may be provided by an authorizing entity, such as a hospital, to a pharmacy according to the principles disclosed herein such that a notice comprising a (secure) link to the e-prescription may be first transmitted to the pharmacy via e-mail, for instance.

Adoption threshold for accepting e.g. bills or other documents in electronic format may be lowered as acquiring new equipment, learning new skills or remembering new things is unnecessary. Existing e-mail account may be used in connection with the present invention. The users (recipients) of the service do not have to remember special issues relating to such a network service only. The reduced risk of information leaks accelerates the adoption of e-services also in a general sense. Rapid delivery of electronic documents may become reality with minimal costs and at least strongish user authentication. Encryption may be flexibly utilized for information transfer. A document is practically ready for exploitation by the recipient as soon as the one has received the notification e- mail. As the e-mail contains only a link to access the document, potential lack of e-mail encryption does not expose confidential information included in the bill etc. in contrast to simply e-mailed bills. The password of e-mail account and the control over mobile account are used as authentication factors among other options such as location information. User feedback may be provided easily and at least partially automatically. The risk of undesirably lowering the authentication level due to careless management of password practically disappears. Spyware-related risks may be overcome, for example. As the sender, such as seller (bill source), does not have to store user-specific classified information, related information leaks can be avoided. The arrangement may indeed store information such as e-mail addresses and cell phone numbers of the users thereof, but such information is not typically considered as particularly confidential and would be stored anyway in respect of customer records as desirable contact details. As a relatively ordinary mobile device may be applied as a security token, proprietary new tokens do not have to be obtained.

Further, the sender such as the seller may amend the applied document structure via updating e.g. the utilized XML scheme without informing or requesting the operator to specifically take the change into account to omit unnecessary filtering of documents based on the operator-side scheme verification procedures. Data structures may be applied company- and/or industry-specifically (tailored) provided that the recipients also accept the changes. The present invention removes the need to maintain customer-specific e-bill addresses in a network service providing the bills. The invention is applicable to scenarios wherein feasible operator and/or bank-based delivery network is not available. The sender may utilize a simple interface for transmitting the documents.

When electronic documents are created and stored in XML format, they may be archived with a fair hypothesis that any special application is not required upon future access instant. The technology risk relating to storing data in some application-specific format and later finding no feasible program to access it, may be minimized. Yet, XML formatted data may be compressed effectively for minimizing the storage space usage in the network server, for instance. Generally, electronic documents such as bills may be first provided and/or stored in XML or some other first format and subsequently visualized utilizing a second format either permanently (document being stored in the second format) or upon each visualization instance.

Instead of storing documents in a third party system, such as an invoicing operator system, the sender (e.g. seller) may operate a local database comprising the documents, optionally in favor of the recipient e.g. in return for reasonable financial compensation. The archiving need may also be mutual. As the recipient accesses the network service operated by the arrangement to fetch the document, corresponding log data may be created for future verification of document delivery. Correspondingly, an automated alarm may be created if such log entry is missing and corrective actions, such as communications problem solving, may be initiated. Sending the OTP not until link activation may elevate the security level of the procedure as the OTP is not unnecessarily stored in the mobile device meanwhile (third parties could get access thereto by stealing the device, etc.). The expression "a number of refers herein to any positive integer starting from one (1), e.g. to one, two, or three. The expression "a plurality of refers herein to any positive integer starting from two (2), e.g. to two, three, or four.

The expression "data transfer" may refer to transmitting data, receiving data, or both, depending on the role(s) of a particular entity under analysis relative a data transfer action, i.e. a role of a sender, a role of a recipient, or both.

The terms "a" and "an" do not denote a limitation of quantity, but denote the presence of at least one of the referenced item. The terms "first" and "second" do not denote any order, quantity, or importance, but rather are used to distinguish one element from another.

Different embodiments of the present invention are disclosed in the dependent claims.

BRIEF DESCRIPTION OF THE RELATED DRAWINGS

Next the invention is described in more detail with reference to the appended drawings in which

Fig. la illustrates the concept of the present invention via both block and signaling diagram approaches relative to an embodiment thereof.

Fig. lb is a block diagram representing an embodiment of selected internals of the arrangement according to the present invention.

Fig. 2 is a flow chart disclosing an embodiment of a method in accordance with the present invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS In the context of the present invention, the recipient preferably has an e-mail account (advantageously private e-mail), a browser application, network access such as Internet accessibility, a mobile (communications) device and a mobile subscription. Further, the recipient may have a desktop, laptop, or a hand-held computer for e-mail and/or browsing purposes, for instance. Alternatively or additionally, the mobile device may be utilized also for such use. For example, many contemporary and forthcoming higher end mobile terminals such as so- called "smartphones" bear necessary capabilities for both e-mail and web surfing purposes. Advantageously, the e-mail address and mobile number of the recipient are stored in the sender's (and/or potential document delivery service operator's) system for future use.

The recipient may have to be supplied with e.g. financial instruments requiring at least strongish authentication. A related document may be, e.g. upon first instance of use (fetch by a recipient) converted into a target format such as the PDF format and/or digitally signed.

The potential users of the provided arrangement and method include different financial institutions, companies, and private persons either in the role of a sender, intermediate entity, or the recipient, for example. The institutions and other users may provide financing, goods, services, etc. among other options. Various derivative instruments such as certificates, advice letters and statements may be provided. The invention is generally applicable in a wide variety of different use scenarios and document delivery applications including, but not limited to, any of the following: bank/account statement, maturity prediction, balance statement, interest to be carried forward (e.g. for closing of the accounts), mortgage certificate, collateral listing, notice to the surety regarding the loan status (servicing, for instance), guarantee commission debit note, interest subsidy bill, balance sheet for a interest subsidy remitter, notice regarding interest swap and/or currency swap, bond subscription invoice, bond subscription certificate, installment bill, leasing bill, collection letter and/or bill.

Figure la illustrates the overall concept of the present invention according to a reasonably detailed embodiment thereof. The embodiment may be related, by way of example only, to the delivery of bill including a notice of maturity regarding a bank loan. Entity 102 refers to the user (recipient) and associated devices such as a desktop/laptop computer and/or a mobile device utilized for obtaining a number of e-documents. The device(s) preferably provide access to a network such as the Internet. The mobile device, such as a mobile phone (e.g. a smartphone) or a PDA (personal digital assistant) may preferably be wirelessly connected to a compatible network, such as a cellular network. Optionally the Internet may be accessed via the mobile device. Entity 104 refers to E P (enterprise resource planning) or corresponding entity of the bill sender capable of loan servicing, etc. Entity 106 refers to a NAS (Network access server) or a corresponding arrangement of a number of connected devices for user verification and document delivery. The communication between the entities 102(, 104), and 106 may take place over the Internet and underlying technologies, for example. Preferably the entity 106 is functionally also connected to a mobile network.

At 120 the user authenticates with a bank, for example. At 122, the bill sender (lender) stores basic contact information such as e-mail account and cellular number in the customer records for future use.

Then, at 124 a billing run is executed and pertinent notices of maturity, i.e. bills relating to installments and interests, are output for transmittal to corresponding clients (users 102) utilizing e.g. HTTPS. At 126, the NAS 106 stores the bills in a number of databases for preferably permanent storage. At 128, a notice regarding a bill is sent, as digitally signed by S/MIME, for example, and utilizing a first communication technique, preferably e-mail, to the registered e-mail address of the intended recipient. Further, the e-mail may be encrypted. With e- mail it is referred to Internet e-mail, for example. Also other electronic mail systems or platforms may be applied. At 130, the user 102 receives the e-mail notice informing about a possibility to fetch a new bill from the remote server 106. The notice may be received via a desktop computer or a portable, e.g. laptop or palm-top, computing device such as a smartphone as mentioned above. Optionally a plurality of authentication options may be provided to the user as described in more detail hereinafter. The user 102 may verify the sender of the e- mail by referring to the digital signature to avoid spammers' notices. Thereafter, the user 102 may select a secure link included in the notice and comprising a unique U I for accessing the e-bill stored in the NAS server 106, which takes place in item 132 utilizing e.g. HTTPS for establishing a secure channel to the server 106. Item 148a illustrates the simplified screen view visualizing the notice and the embedded link(s) to the user 102. The used e-mail client may include a stand-alone application (UI) or e.g. a webmail application. At 134, the server 106 preferably validates the URI address based on e.g. the secure element thereof. At 136, the server 106 sends browser data for representing a login screen to the user 102 (again e.g. HTTPS may be applied) and an OTP preferably to the mobile device (e.g. cell phone number) associated with the intended recipient of the electronic document e.g. in an SMS message delivered via an SMS gateway, for instance. At least part of the transmission path to the mobile device is preferably wireless and the air interface of a wireless, e.g. cellular, network compatible with the mobile device is applied. At least partially different (second) communications technique may be thus exploited in contrast to the delivery of the e-mail notice. Accordingly, 2-factor/2-channel authentication may be achieved. The message and/or the OTP may be encrypted utilizing a predetermined encryption technique. At 138, the user 102 receives the login screen that is visualized on his/her terminal device, see the example 148b. At 138b, the OTP is received preferably with the mobile device. At 140, the user 102 types the OTP in the login screen. Again, the related communication may apply HTTPS, for instance. At 142, access control logic of the server 106 compares the received OTP and the reference OTP (correct OTP sent at 138b), and in case these two match and optional additional conditions are fulfilled as well, transmits, at 144, data for generating a new view, see the example at 148c, enabling the user 102 to download the bill or view it directly 146, e.g. via HTML page(s) interpreted by compatible browser and necessary browser add-on(s), optionally with supplementary data such as indication of available functionalities like change of the presentation mode. Yet, HTTPS and/or SSH (Secure Shell) may be applied for securing the data transfer of the bill data as browser data, for instance. E.g. a switchover from HTML to PDF or some other format may be triggered. Finally, the payment associated with the bill may be executed. The bill may be locally stored. Earlier bills and/or other documents received may be inspected.

Optionally, location information 143 may be utilized in the authentication process. In one embodiment, the server 106 and/or other entities external to the user's 102 terminal gear may be configured to locate one or more of the terminals the user 102 applies for obtaining the document, i.e. a first terminal used for e-mail and browsing/login procedure, and a second terminal used for OTP reception, if different. The location of the terminal(s) typically gives a hint about the user's 102 location. Alternatively or additionally, the terminal devices may bear an own role in the positioning process and execute at least part of the necessary positioning actions locally. Actions required to position a terminal may be shared between the terminal(s) and at least one external entity. For instance, address information may be used in the positioning process to deduce the location of the particular terminal in question. Somewhat typically, terminal or access network addresses such as IP addresses are at least loosely associated with physical locations so that the address-based locating is at least limitedly possible. In connection with mobile devices, many other options are available too including roaming signal and data transmission -based positioning. For example, by checking the ID of the base station(s) the mobile device is communicating with, at least approximate location of the mobile device may be obtained. Yet, through more comprehensive signal analysis, such as TOA (Time- Of- Arrival), OTD (Observed-Time-Difference), or AOA (Angle-Of- Arrival), the mobile device may be located. In some embodiments, a satellite navigation receiver, such as a GPS (Global Positioning System) or GLONASS (GLObal Navigation Satellite System), in connection with a terminal device may be exploited. The terminal may share the locally received satellite information with external entities as such or in cultivated form (e.g. ready-determined coordinates based on received satellite signal(s)).

On the basis of the terminal location, the server 106 may then introduce a further factor, i.e. a location -based factor, to the authentication procedure and verify, whether the current location of the terminal in question matches with predetermined location information defining a number of allowed locations and/or banned locations in the light of the document access. Depending on the embodiment, the status of the location-based factor may be evaluated prior to the evaluation of the fulfillment of other authentication factors, in conjunction with them, or as a final check before authorizing the user to access the electronic document.

Generally regarding any embodiment of the present invention, the document provided with the help of the arrangement presented herein may indeed include links, preferably secure links. A link may point, e.g. in the case of an invoice document, to a breakdown or some other detailed information. Hence, the document itself may be kept short and/or simple through the use of a number of links embedded therein. For example, information relating to payment may be directly included in the documents, whereas further information is accessible via a link. Thus, the basic document format may be constructed so as to fit various different fields as such. One shall remember that in some embodiments, a communications technology different from mobile technology could be applied for delivering the OTP. This might take place upon "no service" situations relative to the mobile network, for instance, as a secondary, back-up connection. The arrangement may be configured to autonomously detect the fulfillment of a triggering condition, such as mobile connection failure, for utilizing the secondary connection for OTP transfer, and/or the user may request such by selecting a related (secure) link included in the e-mail notice, for example. The secondary connection may refer to transmitting the OTP via e-mail, for instance. When secondary connection is applied for OTP transfer, the information provided in or through the document and/or the associated network service may be scaled (down) accordingly to match the achieved authentication level. Less information, e.g. less confidential, may be available to the recipient, for example. The information may be pre- classified into a number of security classes for facilitating the scaling.

In some embodiments, the user rights for the network service provided by the arrangement may be flexibly scaled via the utilization of a plurality of authentication options. The options may be indicated in the e-mail notice via links, text, graphics, and/or other means, for example. In the case of weak authentication, in some embodiments the user receiving the receipt notice may directly access the related document by activating a relating link included therein. The achieved authentication level corresponds to a traditional e-mail communication such as a transfer of a bill. In response, the arrangement may be configured to offer merely a limited, low-level functionality of the overall service to the user, such as simple access to the bill in selected format such as PDF format, and no other functions. Correspondingly, if stronger authentication is implemented via the transfer of the OTP as a new e-mail, for example, average functionality may be offered. For instance, possibility to fetch and view previously received documents may be provided. In cases wherein a mobile connection is applied for the OTP transfer, further data and/or service options may be accessible and/or changeable, such as personal contact information and/or execution of payments. As a result of offering multiple authentication options, the reception costs may be minimized and/or reception made technically more reliable in view of possible connection problems. Therefore, the use of a mobile device may be optional only.

Figure lb is a block diagram illustrating the selected internals of an embodiment of the arrangement presented herein. The arrangement 106, such as a number of servers, may physically contain a number of at least functionally connected elements. The arrangement 106 is typically provided with one or more processing devices capable of processing instructions and other data, such as one or more microprocessors, micro-controllers, DSP's (digital signal processor), programmable logic chips, etc. The processing entity 150 may thus, as a functional entity, comprise a plurality of mutually co-operating processors and/or a number of sub-processors connected to a central processing unit, for instance. The processing entity 150 may be configured to execute the code stored in a memory 152, which may refer to instructions and data relative to the software logic and software architecture for controlling the arrangement 106. The processing entity may at least partially execute and/or manage the execution of the aforesaid receiving, storing, sending, determining, and/or enabling tasks.

Similarly, the memory entity 152 may be divided between one or more physical memory chips or other memory elements. The memory 152 may store program code and other data such as user contact information, electronic documents, etc. The memory 152 may further refer to and include other storage media such as a preferably detachable memory card, a floppy disc, a CD-ROM, or a fixed storage medium such as a hard drive. The memory 152 may be non- volatile, e.g. ROM (Read Only Memory), and/or volatile, e.g. RAM (Random Access Memory), by nature. Software (product) 152 may be provided on a carrier medium such as a memory card, a memory stick, an optical disc (e.g. CD-ROM or DVD), or some other memory carrier. The UI (user interface) may comprise a display or a data projector 154, and keyboard/keypad or other applicable user (control) input entity 154b such as a touch screen and/or a voice control input, or a number of separate keys, buttons, knobs, switches, a touchpad, a joystick, and/or a mouse, configured to provide the user of the arrangement with practicable data visualization and device control means, respectively. The UI may include one or more loudspeakers and associated circuitry such as D/A (digital-to-analogue) converter(s) for sound output, and optionally a microphone with A/D converter for sound input. A printer may be included in the arrangement for providing more permanent output. The arrangement 106 further comprises a data interface 156 such as a number of wired and/or wireless transmitters, receivers, and/or transceivers for communication with other devices such as terminals and/or network infrastructure(s). For example, an integrated or a removable network adapter may be provided. Non-limiting examples of the generally applicable technologies include WLAN (Wireless LAN, wireless local area network), LAN, WiFi, Ethernet, USB (Universal Serial Bus), GSM (Global System for Mobile Communications), GPRS (General Packet Radio Service), EDGE (Enhanced Data rates for Global Evolution), UMTS (Universal Mobile Telecommunications System), WCDMA (wideband code division multiple access), CDMA2000, PDC (Personal Digital Cellular), PHS (Personal Handy-phone System), and Bluetooth.

It is clear to a skilled person that the arrangement 106 may comprise numerous additional functional and/or structural elements for providing advantageous communication, processing or other features, whereupon this disclosure is not to be construed as limiting the presence of the additional elements in any manner. Entity 158 refers to such additional element(s) found useful depending on the embodiment.

Figure 2 discloses, by way of example only, a method flow diagram in accordance with an embodiment of the present invention. At 202 the arrangement of the present invention is obtained and configured, for example through loading and execution of related software, for managing an electronic document delivery system. Information necessary to address electronic documents to recipients and take care of proper authentication is provided. Either local repository or at least access to external storage is arranged. At 204, the arrangement receives an electronic document, such as a bill, for delivery to at least one predetermined recipient. The electronic document is stored in a repository such as a database for archiving and/or future forwarding. At 206, the notification regarding the availability of the electronic document is transmitted towards the recipient based on contact information available. An e-mail account associated with the recipient may be applied, for example. The notification may include a link (typically a hyperlink), preferably also being a secure link, the activation of which funnels the client application such as the browser of the activator to the login/password entering page for obtaining access to the document.

At 208, the data transmission (e.g. HTTP(S) request, such as GET) initiated by the activator reaches the arrangement, and the arrangement responds by supplying a password request or potentially a more comprehensive login page (e.g. user ID) back at 210 as e.g. a web page matching the received request, for example. At 212, an OTP to be provided in response to the password query is supplied utilizing e.g. cellular communication to a mobile device associated with the recipient. Preferably the addresses whereto the e-mail and OTP are transmitted are different to enhance the security of the overall arrangement. More preferably, the transmission techniques also at least partially differ, e.g. TCP/IP vs. cellular communication. The order of items 210 and 212 may be reversed, or substantially simultaneous execution thereof may be preferred, as being clear to a skilled person. The issue is highlighted in the figure by the bi-directional broken arrow between the two items 210, 212.

As the password is provided to the login screen, a corresponding data transmission is triggered towards the arrangement that, at 214, receives the transmission. At 215, further authentication factors such as location factor may be optionally considered. Optionality is depicted by the broken outline of item 215. As deliberated hereinbefore, the exact execution instant of further authentication checks may be determined per each particular embodiment, and the illustrated position is just one feasible option. For instance, one other applicable position could reside between items 216 and 218 such that the location check would be the ultimate verification prior to authorizing access to the electronic document. At 216, the password entered by the user is compared against the archived one. In case the passwords do not match, a further possibility may be given to the user to enter a correct password, which is indicated by a dotted loop-back arrow. In some embodiments, a limited number of tries may be permitted. If the maximum number of tries is met without success and/or a predetermined timer is exceeded for entering a proper password, a predetermined action may be executed. For example, document sender may be informed about the delivery failure and its cause via e-mail or other electronic communication.

Provided the password given is correct, access to the electronic document may be authorized at 218, e.g. via the browser through which OTP was input, etc. The arrangement may transmit, in response to correct OTP input, the electronic document in a predetermined format, e.g. the original storage format or a converted format, to the recipient via the browser connection. Alternatively, a separate authorization display may be first provided, for example, implying that the password was correct (and optionally that further authentication factor checks were successful as well) and access to the document is now allowed. A link to download the document may be simultaneously or successively presented. At 220, the method execution is ended. The execution of various method items may be naturally repeated upon need.

A computer program, comprising a code means adapted, when run on a computer, to execute an embodiment of the desired method steps in accordance with the present invention, may be provided. A carrier medium such as an optical disc, floppy disc, or a memory card, comprising the computer program may further be provided. The program may be delivered over a communication network.

Consequently, a skilled person may on the basis of this disclosure and general knowledge apply the provided teachings in order to implement the scope of the present invention as defined by the appended claims in each particular use case with necessary modifications, deletions, and additions. For example, instead of HTML, a variation thereof, such as XHTML (extensible HTML), or e.g. WML (Wireless Markup Language) may be applied for document presentation, transfer and/or storage.

Claims

1. An arrangement, such as a server (106) or a plurality of at least functionally connected servers, for delivering an electronic document, such as a bill, to a recipient utilizing multi-factor authentication, said arrangement comprising a processing entity (150) and a memory entity (152) for processing and storing data, respectively, and a data transfer entity (156) for receiving and sending data, said arrangement being configured to receive and store an electronic document provided by a sender for delivery to a predetermined recipient (126), send an e-mail including a notice indicative of the reception of the electronic document to an e-mail address associated with the predetermined recipient, said e-mail notice including a link, preferably a secure link, for a browser (128), receive an indication of the activation of the preferably secure link (132), in response to which said arrangement being further configured to, send first browser data, such as web page data, requesting the user of the browser to input a secret (136), send a one-time password (OTP) to a mobile device associated with the predetermined recipient (138b), receive user input relative to the request for secret (140), determine whether the user input matches the sent OTP (142), and if that is the case, enable the user, thus authenticated as the predetermined recipient, to access the electronic document (144).

2. The arrangement of claim 1, configured to send second browser data to the browser to enable the user to access the electronic document, said second browser data including the electronic document or a link thereto.

3. The arrangement of any preceding claim, configured to further utilize the estimated location of the user as an authentication factor (143).

4. The arrangement of claim 3, wherein the location estimate is based on the estimated location of a device applied for activating the link.

5. The arrangement of any of claims 3-4, wherein the location estimate is based on the estimated location of the mobile device.

6. The arrangement of any of claims 3-5, wherein the location estimate is compared against one or more predetermined locations.

7. The arrangement of claim 6, wherein in the case of a match between the location estimate and a predetermined location deemed as allowable, the authentication is considered successful in the light of the location-related authentication factor.

8. The arrangement of any of claims 6-7, wherein in the case of a match between the location estimate and a predetermined location not deemed as allowable, the authentication is considered unsuccessful in the light of the location-related authentication factor.

9. The arrangement of any of claims 3-8, configured to trace user behavior, said tracing including monitoring locations and/or movements, whereupon said arrangement is configured to determine a number of allowed or banned locations for accessing electronic documents at least partially based on the behavior.

10. The arrangement of any of claims 3-9, wherein the location refers to at least one element selected from the group consisting of: address, network address, sub-network, IP (Internet Protocol) address, IP sub-network, cell, cell-ID, street address, one or more coordinates, GPS (Global Positioning System) coordinates, GLONASS (GLObal Navigation Satellite System) coordinates, district, town, country, continent, distance from a predetermined location, and direction from a predetermined location.

1 1. The arrangement of any preceding claim, wherein the e-mail is provided as digitally signed utilizing at least one certificate selected from the group consisting of: S/MIME-compliant (Secure/Multipurpose Internet Mail Extensions) identity certificate, OpenPGP (Pretty Good Privacy, RFC 4880) - compliant identity certificate, and X.509-compliant identity certificate.

12. The arrangement of any preceding claim, configured to store the electronic document in a first format, such as XML (extensible Markup Language) format, and provide the document to the user in a second format, such as PDF (Portable Document Format) format.

13. The arrangement of any preceding claim, configured to send the OTP embedded in a text or multimedia message, such as an SMS-compliant (Short

Message Service) or an MMS-compliant (Multimedia Messaging Service) message, respectively.

14. A method for delivering an electronic document, such as a bill, to a recipient utilizing multi-factor authentication, comprising receiving and storing an electronic document provided by a sender for delivery to a predetermined recipient (204), sending an e-mail indicative of the reception of the electronic document to an e- mail address associated with the predetermined recipient, said e-mail including a link, preferably a secure link, for a browser (206), receiving an indication of the activation of the preferably secure link (208), sending first browser data, such as web page data, requesting the user of the browser to input a secret (210), sending a one-time password (OTP) to a mobile device associated with the predetermined recipient (212), receiving user input relative to the request for secret (214), determining whether the user input matches the sent OTP (216), and if that is the case, enabling the user, thus authenticated as the predetermined recipient, to access the electronic document (218), wherein said enabling optionally comprises transmitting the document as such or in a converted form, or providing a link thereto.

15. A computer program comprising code means adapted to, when run on a computer, to execute the method items of claim 14.

16. A carrier medium comprising the computer program according to claim 15.