WO2015017884A1

WO2015017884A1 - A server implemented method, server, and computer readable storage medium for transmitting document metacontent

Info

Publication number: WO2015017884A1
Application number: PCT/AU2014/000785
Authority: WO
Inventors: Peter PAICE
Original assignee: Pidea Pty Ltd
Priority date: 2013-08-06
Filing date: 2014-08-05
Publication date: 2015-02-12

Abstract

There is provided with a server (305) implemented method for transmitting document metacontent, the method comprising: receiving from a sender terminal (350), a transaction ID request, the transaction ID request comprising document metacontent; generating a transaction ID; storing the metacontents in relation to the transaction ID; sending, to the terminal (350), the transaction ID; receiving, from a receiver terminal (360), a document metacontent retrieval request, the document metacontent retrieval request comprising at least the transaction ID; retrieving the metacontent in accordance with the transaction ID; and sending, to the receiver terminal (360), the metacontent.

Description

A SERVER IMPLEMENTED METHOD, SERVER, AND COMPUTER READABLE STORAGE MEDIUM FOR TRANSMITTING DOCUMENT METACONTENT

Field, of the Invention

The present invention relates to a server implemented method, server, and computer readable storage medium for transmitting document metacontent.

Background

According to existing -arrangements, documents, e-mails and the like, are sent from business to business, business to customer and the like.

Generally, these documents comprise hardcopy documents, or electronic documents in specific format, such as PDF format,

A problem of such existing arrangements is the difficulty associated with the use of the data at the receiver end, especiaily where such data is required to be entered into a database application or the like. For example, upon receipt of a PDF electricity account invoice, the accounting department of the receiver would foe required to manually re-enter the amount owing, due date, supplier and the like.

Existing arrangements have attempted to overcome such problems. One approach is to utilise a 2D barcode to include information, However, there are several problems with this approach. Firstly, the data encoding capacity of the barcode is limited.

Secondly, the data encoding capacit is not suited for differing data formats, such as arrays. Thirdly, upon extraction of such data at the receiver, the receiver would still have to decide how- to place the information.

Fourthly, transmittal of the data in this manner is insecure and is vulnerable to interception.

It is to foe understood that, if any prior art information is referred to herein, such reference does not constitute an admission that the information forms part of the common general knowledge in the art, in Australia or any other country.

Summary

The invention seeks to provide a server implemented method, server, and computer readable storage, medium for transmitting document metacontent which will overcome or substantially ameliorate at least some of the deficiencies of the prior art, or to at least provide an alternative. According to one aspect, there is provided a server implemented method for transmitting document metacontent, the method comprising receiving, from a sender terminal, a transaction ID request, the transaction ID request comprising document metacontent; generating a transaction ID; storin the rnetacontenl^' in relation to the transaction ID sending, to the sender terminal, the transaction ID; receiving, from a receiver terminal, a document metacontent retrieval request, the document metacontent retrieval request comprising at least the transaction ED; retrieving the metacontent in accordance with the transaction ID; and sending, to the receiver terminal, the metacontent.

Preferably, the transaction ID is a print on a document.

Preferably, the print comprises a barcode.

Preferably, a barcode is a 2D barcode.

Preferably, the 2D barcode encodes a URL associated with the transaction ID.

Preferably, the server implemented method further comprises receiving scan data of the print, and identifying the transaction ID in accordance with the scan data or additional associated data. The additional associated data may be entered by a user at the time of requesting the transaction ID.

Preferably, the method further comprises generating the transaction ID further in accordance with the document content data.

Preferably, generating the transaction ID in accordance with the document content data further comprises generating scan invariant document content data in accordance with the document content data and generating the transaction ID in accordance with the scan invariant content data. Preferably, the server implemented method further comprises using a web service to receive, from the sender terminal., the transaction ID request.

Preferably, the document metacontent comprises markup language.

Preferably, the markup language comprises a structured language. The markup language may beXML, HTML, SQL or similar structured language as would be appreciated by the skilled addressee.

Preferably, the server implemented, method further comprises validating the XML.

Preferably, the server implemented method further comprises allocating the transaction ID a session lifespan.

Preferably, receiving the transaction ID comprises serving, at a URL associated with the transaction ID, and the rnetacontenl.

Preferably, the server implemented method further comprises fetching further document metacontent in accordance with the transaction ID request

Preferably, the transaction ID is a sparse ID.

According to another aspect, there is provided a server for transmitting document metacontent, the server comprising a processor for processing digital data; a memory device for storing digital data including computer program code, the memory device bein operably coupled to the processor; a network interface for sending and receiving data across a data network, the network interface being operably coupled to the processor; a database for retrieval and storage of data, the database being operably coupled to the processor, wherein, in use, the processor is controlled by the computer program code for receiving, via the network interface from a sender terminal, a transaction ID request, the transaction ID request comprising document nietacontent; generating a transaction ID; storing, in the database, die nietacontent in relation to the transaction ID; sending, via the network interface to the sender terminal, the transaction ID; receiving, via the network interface from a receiver terminal, a document nietacontent retrieval request, the document nietacontent retrieval request comprising at least the transaction ID; retrieving, from the database, the metacontent in accordance with the transaction ID; sending, via the network interface to the receiver terminal, the metacontent.

Preferably, the transaction ID is a print on the document.

Preferably, the print comprises a barcode.

Preferably, a barcode is a 2D barcode.

Preferably, the 2D barcode encodes a URL associated with the transaction ID.

Preferably, the processor is further controlled by the computer program code for receiving, via the network interface, scan data of the print, and identifying the transaction ID in accordance with the scan data.

Preferably, the processor is further controlled by the computer program code for generating the transaction ID further in accordance with the document content data.

Preferably, generating the transaction ID in accordance with the document content data further comprises generating scan invariant document content data in accordance with the document content, data and generating the transaction ID in accordance with the scan invariant content data.

Preferably, the processor is further controlled by the computer program code for using a web service to receive, via the network interface from the sender terminal, the transaction I^'D request.

Preferably, the document metacontent comprises markup language.

Preferably, the markup language comprises XML.

Preferably, the processor is further controlled by the computer program code for validating the XML.

Preferably, the processor is further controlled by the computer program code for allocating the transaction ID a session lifespan.

Preferably, receiving the transaction ID comprises serving, at a URL associated with the transaction ID, and the metacontent

Preferably, the processor is further controlled by the computer program code for fetching further document metacontent in accordance with the transaction ID request. Preferably, the transaction ID is a sparse ID.

According to another aspect, there is provided a computer readable storage medium for transmitting document metacontent, the computer readable storage medium readable by a computing device and comprising instructions for controlling the computin device, including instructions for receiving, from a sender terminal, a transaction ID request, the transaction ID request comprising document metacontent; generating a transaction ID; storing the metacontent in relation to the transaction ID; sending, to the sender terminal, the transaction ID; receiving, from a receiver terminal, a document metacontent retrieval request, the document metacontent retrieval request comprising at least the transaction ID; retrieving the metacontent in accordance with the transaction ID; mid sending, to the receiver terminal, the metacontent.

Preferably, the transaction ID is a print on a document.

Preferably, the print comprises a barcode.

Preferably, a barcode is a 2D barcode.

Preferably, the 2D barcode encodes a URL associated with the transaction ID.

Preferably, the computer readable storage medium further comprises instructions for receiving scan data of the print, and identifying the transaction ID in accordance with the scan data.

Preferably, generating the transaction ID in accordance with the document content data further comprises generating scan invariant document content data in accordance with the document content data and generating the transaction ID in accordance with the scan invariant content data.

Preferably, the computer readable storage medium further com rises instructions for using a web service to receive, from the sender terminal, the transaction ID request.

Preferably, the document metacontent comprises markup language.

Preferably, the markup language comprises a structured language. The markup language may be

XML. HTML, SQL or similar structured language as would be appreciated by the skilled addressee.

Preferably, the computer readable storage medium further comprises instructions for validating the XML.

Preferably, the computer readable storage medium further comprises instructions for allocating the transaction ID a sessio lifespan.

Preferably, the computer readable storage medium further comprises instructions for fetching further document metacontent in accordance with the transaction ID request. Preferably, the transaction ID is sparse ID.

Other aspects of the invention are also disclosed.

Brief Description of the Drawings

Notwithstanding any other forms which may fall within the scope of the present invention, preferred embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:

Fig. 1 shows a computing device on which the various embodiments described herein may be implemented in accordance with an embodiment of the present invention;

Fig. 2 shows a network of computing devices on which the various embodiments described herein may be implemented in accordance with an embodiment of the present invention;

Fig. 3 shows a system for transmitting document metacontent in accordance with an embodiment of the present invention.

Description of Embodiments

It should be noted in the following description that like or the same reference numerals in different embodiments denote the same or similar features.

Computing device 100

Fig. 1 shows a computing device 100 on which the various embodiments described herein may be implemented.

The computing device 100 may take on differing embodiments as may be described herein, including those given in figure 3 such as the server 305, sender terminal 350. receiver terminal 360 and the like.

In particular the steps of the method of transmitting document metacontent may be implemented as computer program code instructions executable by the computing device 100. The computer program code instructions may be divided into one or more computer program code instruction libraries, such as dynamic link libraries (DLL), wherein each of the libraries performs a one or more steps of the method. Additionally, a subset of the one or more of the libraries may perfor graphical user interface tasks relating to the steps of the method.

The device 100 comprises semiconductor memory 110 comprising volatile memory such as random access memory (RAM) or read only memory (ROM). The memory .100 may comprise either RAM or ROM or a combination of RAM: and ROM.

The device 100 comprises a computer program code storage medium reader 130 for reading the compute program code instructions from computer program code storage media 120. The storage media 120 may be optical media such as CD-ROM disks, magnetic media such as floppy disks and tape cassettes or flash media such as USB memory sticks.

The device further comprises I/O interface 140 for communicating with one or more peripheral devices. The I/O interface 140 may offer both serial and parallel interface connectivity. For example, the I/O interface 140 may comprise a Small Computer System Interface (SCSI), Universal Serial Bus (USB) or simila I/O interface for interfacing with the storage medium reader 130. The I/O interface 140 may also communicate with one or more human input devices (HID) 160 such as keyboards, pointing devices, joysticks and the like. The I/O interface 140 may also comprise a computer to computer interface, such as a Recommended Standard 232 (RS-232) interface, for interfacing the device 100 with one or more personal computer (PC) devices 190. The I/O interface 140 may also comprise an audio interface for communicate audio signals to one or more audio devices 1050, such as a speaker or a buzzer.

The device 100 also comprises a network interface 170 for communicating with one or more computer networks 180. The network 180 may be a wired network, such as a wired Ethernet¹'** network or a wireless network, such as a Bluetooth ^! network or IEEE 802.1 1 network. The network 180 may be a local area network (LAN), such as a home or office computer network, or a wide area network (WAN), such as the internet or private WAN.

The device 100 comprises an arithmetic logic unit o processor 1000 for performing the computer program code instructions. The processor 1000 may he a reduced instruction set computer (RISC) or complex instruction set computer (CISC) processor or the like. The device 10 further comprises a storage device 1030, such as a magnetic disk hard drive or a solid state disk drive.

Computer program code instructions may be loaded into the storage device 1 30 from the storage media 120 using the storage medium reader 130 or from the network 180 using network interface 170. During the bootstrap phase, an operating system and one or more software applications are loaded from the storage device 1030 into the memory 110. During the feteh- decode-execute cycle, the processor 1000 fetches computer program code instructions from memory 1 10, decodes the instructions into machine code, executes the instructions and stores one or more intermediate results in memory 1.00.

In this manner, the instructions stored in the memory 110, when retrieved and executed by the processor 1000, may configure the computing device 100 as a special-purpose machine that may perform the functions described herein.

The device 100 also comprises a video interface 1010 for conveying video signals to a display device 1020, such as a liquid crystal display (LCD), cathode-ray tube (CRT) or similar display device. The device 100 also comprises a communication bus subsystem 150 for interconnecting the various devices described above. The bus subsystem 150 may offer parallel connectivity such as Industry Standard Architecture (ISA), conventional Peripheral Component Interconnect (PCI) and the like or serial connectivity such as PCI Express (PCIe), Serial Advanced Technology Attachment (Serial ATA) and the like.

Internet wet architecture network 200

In a preferred embodiment, the embodiments described herein are implemented across the Internet web architecture. As such, Fig, 2 shows a network 200 of computing devices 100 on which the various embodiments described herein may be implemented. The network 200 comprises a web server 210 for serving web pages to one or more client computing devices 220 over the Internet 230.

The web server 210 is provided with a web server application 240 for receiving requests, such as Simple Object Access Protocol (SOAP), Hypertext Transfer Protocol (HTTP) and File Transfer Protocol (FTP) requests, and serving hypertext web pages or files in response. The web server application 240 may be, for example the Apache ¹ or the Microsoft ¹ · IIS HTTP server.

The web server 210 is also provided with a hypertext preprocessor 250 for processing one or more web page templates 260 and data from one or more databases 270 to generate hypertext web pages. The hypertext preprocessor may, for example, be the PHP; Hypertext Preprocessor (PHP) or Microsoft As™ hypertext preprocessor. The web server 210 is also provided with web page templates 260, such as one or more PHP or ASP files.

Upon receiving a request from the- web server application 240, the hypertext preprocessor 250 is operable to retrieve a web page template, from the web page templates 260, execute any dynamic content, -therein, including updating or loading information from the one or more databases 270, to compose a hypertext web page. The composed hypertext web page- may comprise client side code, such as Javascript, for Document Object Model (DOM) manipulating, asynchronous HTTP requests and the like.

Client computing devices 220 are provided with a browser application 280 (i.e., a web browser application), such as the Mozilla Fire-fox^m or Microsoft Internet Explore ^1M browser applications. The browser application 280 requests hypertext, web pages from the web server 210 and renders the hypertext web pages on a display device 1020.

System 300 for transmitting document metacontent

Turning now to figure 3, there is shown a functional schematic of a system 300 for transmitting document metacontent.

As will become apparent from the description below, the system 300 is adapted for transmitting document metacontent from a sender terminal 350 to a receiver terminal 360. In an embodiment, the sender terminal 350 and the receiver terminal 360 may take the form of one of a personal computing device, such as a desktop computing device mobile communicat on device and the like,

Specifically, the system 300 is adapted for allowing document meiacontent to be associated with. a physical document, such as a letter, invoice or the like, or an equivalent electronic document, such as a word processing document PDF document, digital scan or the like so as to allow a sender to send the documents to a receiver wherein, as opposed to the receiver having to manually input data relating to the document, such as name, address, invoice number and the like, the receiver may utilise the system 300 for retrieving the document metacontent for the document which may comprise the name, address, invoice number and the like.

As such, the system 300 comprises a server 305 adapted for storing the document .metacontent The sender terminal 350 loads the document metacontent to the server 305 and the receiver terminal 360 retrieve the document meiacontent Irom the server. In a preferred embodiment the server 305 is a Web server and exposes a Web service 325 such as by using WSDL, SOAP or the like so as to allow wide interoperability.

The system 300 comprises a database 310 operably coupled to the server 305 for storing the document metacontent

in an embodiment, the syste 300 further comprises- a third-party server 320 so as to allow the system 300 to retrieve additional document metacontent data,

H Igh -le vet walk-lh rough

A high-level walk-through example of using the system 300 for transmitting document metacontent will now be provided. It should be appreciated that this walk-through is exemplary only and variations may be made thereto within the purposive scope of the embodiments described herein.

in this example, an. electricity supplier (sender) sends an electricity bill to a business (receiver}. As such, the electricity supplier generates a bill in the conventional manner, such as by the bill including the name and address of the recipient, the amount owing, the supplier banking details and the like, refer to herein for convenience as metacontent.

Now, the- electricity supplier, using the sender terminal 350, sends the metacontent to the server 305 utilising Web service 325, herein referred to for convenience as a transaction ID request. In a preferred embodiment, the metacontent is sent to the server 305 in markup language, and preferably in XML format. 330, Generally, the metacontent markup language comprises a plurality of fields and a plurality of values associated, with fields. In this manner, the sender may generate different fields types depending on the application. Furthermore, the value data may take on differing data formats such as strings, integers, Boolea values, arrays, floating point numbers and the like.

Upon receipt of the metacontent, the server 305 validates the structure of the metacontent and returns an error if the metacontent is not structured correctly such as by non-compliance with a particular schema. However, assuming the metacontent is in the correct format, the server 305 will store the metacontent in the database 310.

The server 305 will generate a transaction H⁾ in accordance with the metacontent. The transaction ID is a unique identifier used for subsequent retrieval of the metacontent in the manner described below. Generally, a unique transaction ID is generated for each transaction ID request. However, the transaction ID request may be unique to a particular document (as will be described in further detail below).

Generally, the transaction ID is a sequentially incrementing value, such as a unique key value from a database table. However, so as to increase security and reduce the potential for unauthorised retrieval of metacontent, the server 305 may hash the key so as to generate a sparse hash. In a modification, the transaction ID ma be a Globally Unique Identifier (GUID) value. The server 305 then returns the transaction ID 335 to the sender terminal 350, The supplier then prints the bill in the normal manner but also includes on the bill a print of the transaction ID. In a preferred embodiment, the sender terminal 350 is provided with a print server which is adapted to automate the inclusion of a print of the transaction ID. In this manner, the printing of the transaction ID using the adapted to print server is largely transparent to the user.

Then, the bill is sent to the receiver in the normal manner, such as by using traditional mail, or other technique such as e-mail or the BJce.

Now, the accounting department of the receiver, as opposed to having to manually input the bill data into their accounting system, may simply use the system 300 to retrieve the metacontent from the document.

In a preferred embodiment, the transaction ID is printed on the document using a barcode such that the receiver can use a scanning device 365 to scan the barcode. In one embodiment, the barcode is a I D bar code including a unique ID. However, in a preferred embodiment, the barcode is a 2D barcode so as to allow the barcode to include more than simply a unique ID in certain embodiments. Specifically, in these embodiments, the barcode may encode a URL associated with the transaction ID such as:

https://www.exampk.xom .au reUieve-m^

In this manner, the receiver may scan the 2D barcode of the document so as to cause the receiver terminal 360 to browse to the URL encoded within the 2D barcode to retrieve the metacontent. However, it should be noted that in one embodiment, the system 300 is adapted such that no transaction D need be printed on the document. Specifically, in one embodiment, the transaction ID request may comprise the actual document content, which may be document application content, image scan content, or the like. In this manner, the server 305 may generate the transaction ID in accordance with the document content.

For example, where the document content comprises document application content such as a Microsoft Word document (.docx), or PDF document (.pdf), the server 305 may utilise a hash algorithm of such document application content to generate the transaction ID, such as the MD5 hash, in this manner, when the server 305 subsequently receives the document applicatio content from the receiver terminal 360 (such as where the receiver terminal has been e-mailed the document application content), the server 305 may utilise the same D5 hash to generate the same transaction ID so as to be able to retrieve the document metacontent from the database 310. However, in practice, as documents are typically mailed, the recipient would scan an image of the document. In this manner, the server 305 may utilise and scan image processing technique to generate a unique transaction ID for a particular page of a document that does not differ when scanned in differing manners. In a yet further embodiment, the server 305 may utilize Optical Character Recognition (OCR) technique to identify a particular string on the document, such as an invoice number or the like so as to be able to uniquely identify the document.

Once the transaction ID has been identified by the server 305, the server retrieves the metacontent from the database 310 and sends the metacontent to the receiver terminal 360. Having received the metacontent, the receiver terminal 360 may utilise the metacontent as is appropriate, such as in populating an accounting software database with the appropriate information. In this manner, for bills received, the receiver need only scan print of the transaction ID on the bill to have the requisite information input into an accounting software database for payment.

In embodiments, the sender terminal 350 and the receiver terminal 360 may comprise application software adapted to manage the transaction ID request and the transaction ID in accordance with the application, such as by populatin the accounting database records and the like. Specificall y, upon receipt of the metacontent. from the server 305, the application software executing on the receiver terminal 360 may populate the accounting database appropriately.

It should be noted that while the scanning device 235 is shown as being proximate with the receiver terminal 306, in other embodiments the scanning device 365 may be located away from the receiver terminal 360, albeit communicable with the receiver terminal 360 via an appropriate communication interface, in one further embodiment, scanning device 365 is communicable with the server 305 such that the scanning device 365 sends the transaction ID to the server 305 such that the server sends the document Meta content to the receiver terminal 360.

^Specific walk-through: storing of the document metacontent when generating the transaction ID A series of specific walkthroughs will now be provided so as to illustrate differing embodiments, It should be noted that these specific walk- through s are exemplary only and the specific technical limitations should necessarily be implied from these walk-tliroughs. Again also, variations may be made to these walk-throughs within the purposive scope of the embodiments described herein.

The first walk-through relates to the storage, by the server 305 in the database 310, of the document metacontent when generating the transaction ID.

In this exemplary scenario, a customer having paid an invoice, creates a remittance advice in. their accounting package. The concert package transforms the remittance advice into the document metacontent such as by using an open standard format, such as UBL 2.0, and sends the document metacontent to the server 305 as part of the transaction ID request. The server 305, validates the structure of the XML, stores the metacontent 310 in in the database 310 and returns the transaction ID to the sender terminal 350. The accounting package operating on the sender terminal 350 creates a PDF document of the remittance advice comprising a print of a 2D barcode comprising the transactio ID. The sender then, using the sender terminal 350 e-mails the remittance advice to their supplier (the receiver). The receiver receives e-mail and opens the PDF file. The receiver then uses an onscreen scanner to read the included 2D barcode. The scanner identifies the PDF document as a remittance advice document and submits a request for the metacontent from the server 305. A server 305 sends the XML comprising the metacontent to the receiver terminal 360 and the accounting package operating on the receiver terminal 360 creates the remittance advice.

Now, decomposing the above exemplary scenario into a series of steps, there is a first step where the sender terminal 350 initiates the transaction 1X3 request relating to a document. The sender terminal 350 receives document content in relation to document and generates the transaction ID request in XML format, which XML format may be conforming to a particular schema.

In a second step, the sender terminal 350 sends the XML transaction ID request to the Web server 305 utilising Web server 325. In receiving the transaction ID request data, the server 305 is adapted to store the document metacontent in the database 310. In this step, the sender, using the sender terminal 350 may first be required to request a security token for the use of the Web server 325, wherein such a security token may be used for subsequent requests of the Web server 325 for a specific session lifetime. Additionally, where the sender terminal 350 utilises application software adapted for interfacing with the Web server 325, such applications software may be provided with a developer key such that for each request to the Web server 325, the application software also send the developer key to the Web server 325 for authentication purposes. The t nsaction ID request may further comprise a document type parameter and an ~ ref recipient parameter.

In the third step, the server 305 validates the XML or the transaction ID request to confirm that the XML, conforms to the appropriate XML schema definition. The XML may be validated in accordance with the above-mentioned document type parameter.

In a fourth step, the server 305 creates the transaction ID. In. one embodiment, the transaction ID is a globally unique identifier (GIJID). The server 305, then returns, via the Web server 325 to the sender terminal 350 the transaction ID. In one embodiment, the server itself 305 may compose a 2D barcode comprising the transaction ID. Alternatively, such composition may be performed by the sender terminal 350. In one embodiment, the 2D barcode encodes a URL associated with the transaction ID for use by the receiver terminal 360 in subsequently retrieving the document metacontent. In a preferred embodiment, the 2D barcode is encoded in PNG format. In a yet further embodiment, the 2D barcode generated by the server 305 or the sender terminal 350 comprises associated alphanumeric information which may be displayed adjacent the 2D barcode, the associated alphanumeric information comprising the transaction ID in one embodiment.

In a fifth step, the sender terminal 350 includes the 2D barcode comprising the transaction ID in a document and sends the documents to the receiver terminal 360 in the normal manner, which all manner may comprise mail, e-mail, hand-to-hand sending and the like.

In a sixth step, using the receiver terminal. 360 and scanning device 365 (which scanning device may be an external scanning device or a "soft" scanning device) that retrieves the URL comprising the transaction ID from the 2D barcode, Using the URL, the receiver terminal 360 browses to the Web server 325 to retrieve the metacontent. in a similar manner as described above, the receiver terminal 360 may be required to authenticate with the Web server 325 to obtain a security token hich may be utilised for subsequent requests for a set amount of time. Again also, a developer key may also be required to be supplied by that receiver terminal 360 for the purposes of authenticating with the Web server 325 where middleware software is used on the receiver terminal 360. It is to be noted that the scanning device 365 may be remote from the receiver terminal 360,

The server 305 validates the document metacontent retrieval request from the receiver terminal 360, which may include determining whether the receiver is currently subscribed to the server 305. If the document metacontent was stored in the database 310 with the X-Ref recipient parameter, then the receiver must match the X-Ref definition set by the sender. In seventh step, having received the document metacontent from the server 203, the receiver terminal 360 transforms the XML into an appropriat format for local use.

Further specific walk-through: retrieval of document metacontent performed separately from the scanning of the transaction ID

In a further exemplary embodiment, there is provided a scenario wherein the document metacontent is retrieved separatel from the scanning of the transaction ID.

In this exemplary scenario, a plumber visits a number of warehouses and receives a number of invoices. Each invoice composes a 2D barcode comprising a transaction ID generated by the server 305.

Now, using his mobile communication device, such as his Apple iPhone, the plumber scans each 2D barcode on each invoice. The mobile application executing on the mobile communication device retrieves the transaction ID from each 2D barcode and sends data to. the Web server 305 instructing the server 305 that each 2D barcode has been scanned.

Then, at periodic intervals, the plumber's accountant authenticates with the server 305 to retrieve invoice data from the server 305 relating to those invoices which the plumber has scanned.

Further specific walk-through, auto flagging of documents

In an alternative embodiment, there is provided an exemplary scenario wherein, for example, a warehouse has a pre-existing agreement with a customer that metacontent for all invoices for services will be sent to the server 305.

Then, at periodic intervals, the customer authenticates with the server 305 for the purposes of retrieving the document metacontent of invoices generated by the warehouse. In this manner, as opposed to the above exemplary embodiment, there is no requirement for the scanning of each invoice.

Further specific walk-through, the retrieval of further document metacontent

In a further exemplary walk-through, there is provided embodiments wherei the system 300 is adapted to retrieve further document metacontent, such as from a third-party server 320,

In this exemplary scenario, the customer visits a stationery supplier that has registered wit the server 305. A stationery supplies point of sale terminal generates a 2D barcode comprising a transaction ID and prints the barcode on to the customs receipt.

When a customer later returns to the customer's office, and wishes to record information relating to the receipt using the receiver terminal 360, the customer scans the 2D barcode so as to cause the receiver terminal 360 to retrieve, from, the server 305 the document metacontent relating to the receipt

However, upon receipt of the document metacontent retrieval request from the receiver terminal 360, the server 305 ascertains that the document metacontent for the receipt does not reside within the database 310. However, since the transaction ID is associated with the stationery supplier, the server 305 utilises existing authentication credentials stored in relation to information of the stationery supplier to request the document metacontent from the third party server 320.

In this manner, as opposed to the system 300 storing, the document Metacontent in the database 31 at the time of receiving the transaction idea request, the system 300 pulls the document, metacontent from a third party server 320 at the time of receiving the document metacontent retrieval request.

In a further embodiments, the systems may be adapted to 'push" the metacontent to a recipient without the need for an initial request for the metacontent. hi an example implementation of this embodiment, the system 300 may automatically send ("push") the document metacontent to a predetermined recipient or a plurality of recipient in accordance with requirements. For example, the recipientfs) may be an accountant or bookkeeper responsible for reconciling the user s transactions with their financial accounts. For instance, on receipt of the metacontent. the server 305 automatically sends (pushes) a notification to the predetermined recipient(s). The pushed notification may include the metacontent and any related information, eg the transaction ID and/or any scan data. Alternatively, the notification may include a feature (e.g. a hyperlink) for the reclpient(s) to activate so as to receive the metacontent and related information via a 'pull' request from the server,

In further embodiment, the systems may utilise a modified push variation, for example, the recipient (e.g. the accountant, bookkeeper etc.) may review ail meta content uploaded to an associated account to identify each sender responsible for uploading such meta content to the account. The recipient may then authorise a subset of senders as being associated with the account such that, once a sender has been authorised by the recipient, the recipient can instruct the server to automatically scan any future document or meta content from the authorised sender which is explicitly addressed to them (as the recipient), thereby allowing the wholesale retrieve of any scanned documents and/or meta content automatically from the server.

Interpretation

Social graph

The system may be adapted to utilise a social graph in operation i.e. a data structure comprising one or more connections describing the relationships between individuals (and the relationships between individuals online in one embodiment) which is defined explicitly by the one or more connections. Fo example, the ability of the system to crass-reference the sender and receiver in a transaction or metacontent request is a form of social graph in the context of the methods and systems 100, 200 & 300 disclosed herein.

Bus

in the context of this document, the term "bus" and its derivatives, while being described in a preferred embodiment as being a eommunication bus subsystem for interconnecting various devices including b way of parallel connectivity such as Industry Standard Architecture (ISA), conventional Peripheral Component Interconnect (PCI) mid the like or serial connectivity such as PCI Express (PC e), Serial Advanced Technology Attachment (Serial ATA) and the like, should be construed broadly herein as any system for communicating data.

In accordance with:

As described herein, 'i accordance with' ma also mean 'as a function of and is not necessarily limited to the integers specified in relation thereto.

Composite items

As described herein, ^*a computer implemented method' should not necessarily be inferred as being performed by a single computing device such that the steps of the method may he- performed by more than one cooperating computin devices.

Similarly objects as used herein such as 'web server', 'server', 'client computing device', 'computer readable medium' and fee like should not necessarily be construed as being a single object, and may be implemented as a two or more objects in cooperation, such as, for example, a web server bein construed as two or more web servers in a server farm cooperatin to achieve a desired goal or a computer readable medium being distributed in a composite manner, such as program code being provided on a compact disk activatable by a license key downloadable from a computer network.

Database:

In the context of this document, the term "database" and it derivatives may be used to describe a single database, a set of databases, a system of databases or the like. The system of databases may comprise a set of databases wherei the se of databases may be stored on a single implementation or span across multiple implementations. The term "database" is also not limited to refer to a certain database format, rather may refer to any database format. For example, database formats may include MySQL, MySQli , XML, HTML or the like.

Wireless:

The invention may be embodied using devices conforming to other network standards and for other applications, including, for example othe WLAN standards and other wireless standards. Applications that, can be accommodated include IEEE 802.1 J wireless LANs and links, and wireless Ethernet. In th context of this document,, the term "wireless" and its derivatives may be used to describe circuits, devices, systems, methods, techniques, communications channels, etc., that may communicate data through the use of modulated electromagnetic radiation through a non-solid medium. The term does not imply that the associated devices do not contain any wires, although.. in some embodiments they might not. In the context of this document, the term "wired" and its derivatives may be used to describe circuits, devices, systems, methods, techniques, communications channels, etc, thai may communicate date through the use of modulated electromagnetic radiation through a solid medium. The term does not imply that the associated devices are coupled by electrically conductive wires.

Processes:

Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as "processing", "computing", "calculating", "determining", '"analysing" or the like, refer to the action and/or processes of a computer or computing system, or similar- electronic computing device, that manipulate and/or transform data represented as physical, such as electronic, quantities into other data similarly represented as physical quantities.

Processor:

In a similar manner, the term "processor" ma refer to any device or portion of a device that processes electronic data, e.g., from registers and/or memory to transform that electronic data into other electronic data thai, e.g., ma be stored in registers and/or memory. A "computer" or a "computing device" or a "computing machine" or a "computing platform may include one or more processors.

The methodologies described herein are, in one embodiment, performabJe by one or more processors that accept computer-readable (also called machine-readable) code containing a set of instructions that when executed by one or more of the processors carry out at least one of the methods described herein. Any processor capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken are included. Thus, one example is a typical processing system that includes one or more processors. The processing system further may include a memory subsystem including main RAM and/or a static RAM, and/or ROM,

Computer-Readable Medium:

Furthermore, a computer-readable carrier medium may form, or be included in a computer program product. A computer program product can be stored on a computer usable carrier medium, the computer program product comprising a computer readable program means for causing a processor to perform a method as described herein. Networked or Multiple Processors:

In alternative embodiments, the one or more processors operate as a standalone device or may be connected., e.g., networked to other processors), in a networked deployment, the one or more processors may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer or distributed network environmen The one or more processors may form a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.

Note that while some diagram(s) onl show(s) a single processor and a single memory that carries the computer-readable code, those in the art will understand that many of the components described above are included, but not. explicitly show or described in order not to obscure the inventive aspect. For example, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that indi viduall or jointly execute a set

(or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

Additional Embodiments:

Thus, one embodiment of each of the methods described herein is in the form of a computer- readable carrier medium carrying a set of instructions, e.g., a computer program that are for execution on one or more processors. Thus, as will be appreciated by those skilled in the art, embodiments of the present invention may be embodied as a method, an apparatus such as a special purpose apparatus, an apparatus such as a data processing system, or a computer-readable carrier medium. The computer-readable carrier medium carrie computer readable code including a set of instructions that when executed on one or more processors cause a processor or processors to implement a method. Accordingly, aspects of the present invention may take the form of a method, an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of carrie medium (e.g., a computer program product on a computer-readable storage medium) carrying computer-readable program code embodied in the medium.

Carrier Medium:

The software may further be transmitted or received over a network via a network interface device. While the carrier medium is shown in an example embodiment, to be a single medium, the term "carrier medium" should be taken to include a single medium or multiple media (e.g.. a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term "carrier medium" shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by one or more of the processors and t at cause the one or more processors to perform any one or more of the methodologies of the present invention. A carrier medium may take many forms, including but not limited to, non- volatile media, volatile media, and^' transmission media,

I ^' mplementation:

It will be understood that the steps of methods discussed are performed in one embodiment by an appropriate processor (or processors) of a processing (Le., computer) system executing instructions (computer-readable code) stored in storage. It will also be understood that the invention is not limited to any particular implementation or programming technique and that the invention may be implemented using any appropriate techniques for implementing the functionality described herein. The invention is not limited to any particular programming language or operating system.

Means For Carrying out a Method or Function

Furthermore, some of the embodiment are described herein as a method or combination of elements of a method that can be implemented by a processor of a processor device, computer system, or by other means of carrying out the function. Thus, a processor with the necessary instructions for carrying out such a method or element of a method forms a means for carrying out the method or element of a method. Furthermore, an element described herein of an apparatus embodiment is an example of a means for carrying out the function, performed by the element for the purpose of carrying out the invention,

Connected

Similarly, it is to be noticed that the term connected, when used in the claims, should not be interpreted as being limitative to direct connection only. Thus, the scope of the expression a device A connected to a device B should not be limited to devices or systems wherein an output of device A is directly connected to an input of device B. It means that there exists a path between an output of A. and an input of B which ma be a path including other devices or means. "Connected" may mean that two or more elements are either in direct physical or electrical contact, or that two or more elements are not in direc contact with each other but yet still cooperate or interact with each other.

Embodiments:

Reference throughout -this specification to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment, of the present invention. Thus, appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment, but may. Furthermore, the particular features, structures or characteristics may he combined in any suitable manner, as would be apparent to one of ordinary skill, in the art from this disclosure, in one or more embodiments. Similarly it should be appreciated that in the above description of example embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than, are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the Detailed Description of Specific Embodiments are hereby expressly incorporated into this Detailed Descoption of Specific Embodiments, with each claim standing on its own as a separate embodiment of this invention.

Furthermore, while some embodiment described herein include some but not other features included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention, and farm different embodiments, as would be understood by those in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination.

Specific Details

In the description provided herein, numerous specific detail are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

Terminology

In describing the preferred embodiment of the invention illustrated in the drawings, specific terminology will be resorted to for the sake of clarity. However, the invention is not intended to be limited to the specific terms so selected, and it is to be understood that each specific term includes all technical equivalents which operate in a similar manner to accomplish a similar technical purpose. Terms such as "forward", "rearward", "radially'¹, "peripherally", "upwardly", "downwardly", and the like are used as words of convenience to provide reference points and are not to be construed as limiting terms.

Different Instances of Objects

As used herein, unless otherwise specified the use of the ordinal adjectives "first", "second", "third", etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, i ranking, or in any other manner. Comprising and Including

in the claims which follow and in the preceding description of the invention, except where the context requires otherwise due to express language or necessary implication, the word "comprise" or variations such as "comprises" or "comprising" are used in an inclusive sense, i.e. to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention.

Any one of the terms: including or which includes or that includes as used herein is also an open term that also means including at least the elements/features that follow the term, but not excluding others. Thus, includin is synonymous with and means comprising.

Scope of Invention

Thus, while there has been described what are believed to be the preferred embodiments of the invention, those skilled in. the ai will recognize that other and further modifications may be made thereto without departin from, the spirit of the invention, and it is intended to claim all such changes and modifications as fall within the scop of the invention. For example, any formulas given above are merely representative of procedures that may be used. Functionality may be added or deleted from the block diagrams and operations may be interchanged among functional blocks. Steps may be added or deleted to methods described within the scope o the pre sent in venti on .

Although the invention has been described with reference to specific examples, it will be appreciated by those skilled in the art. that the invention may be embodied in many other forms.

Industrial Applicability

It is apparent from the above, that the arrangements described are applicable to the data warehousing industries.

Claims

1. A server implemented method for transmitting document metacontent, the method comprising:

receiving, from a sender terminal, a transaction ID request, the transaction ID request comprising document metacontent;

generating a transaction ID;

storing the metacontent in relation to the transaction ID;

sending, to the sender terminal, the transaction ID;

receiving, from a receiver terminal, a document metacontent retrieval request, the document metacontent retrieval request comprising at least the transaction ID;

retrieving the metacontent in accordance with the transaction ID; and

sending, to the receiver terminal, the metacontent.

2. A server implemented method as claimed in claim 1, wherein the transaction ID is a print on a document.

3. A server implemented method as claimed in claim 2, wherein the print comprises a barcode.

4. A server implemented method as claimed in claim 3, wherein a barcode is a 2D barcode.

5. A server implemented method as claimed in claim 4, wherein the 2D barcode encodes a URL associated with the transaction ID.

6. A server implemented method as claimed in claim 2, further comprising receiving scan data of the print, and identifying the transaction ID in accordance with the scan data.

7. A server implemented method as claimed in claim 1, wherein the transaction ID request further comprises document content data and wherein the method further comprises generating the transaction ID further in accordance with the document content data.

8. A server implemented method as claimed in claim 7, wherein generating the transaction ID in accordance with the document content data further comprises generating scan invariant document content data in accordance with the document content data and generating the transaction ID in accordance with the scan invariant content data.

9. A server implemented method as claimed in claim 1, further comprising using a web service to receive, from the sender terminal, the transaction ID request.

10. A server implemented method as claimed in claim 1, wherein the document metacontent comprises markup language.

11. A server implemented method as claimed in claim 10, wherein the markup language comprises XML.

12. A server implemented method as claimed in claim 11, further comprising validating the

XML.

13. A server implemented method as claimed in claim 1, further comprising allocating the transaction ID a session lifespan.

14. A server implemented method as claimed in claim 1, wherein receiving the transaction ID comprises serving, at a URL associated with the transaction ID, and the metacontent.

15. A server implemented method as claimed in claim 1, further comprising fetching further document metacontent in accordance with the transaction ID request.

16. A server implemented method as claimed in claim 1, wherein the transaction ID is a sparse ID.

17. A server for transmitting document metacontent, the server comprising:

a processor for processing digital data;

a memory device for storing digital data including computer program code, the memory device being operably coupled to the processor;

a network interface for sending and receiving data across a data network, the network interface being operably coupled to the processor;

a database for retrieval and storage of data, the database being operably coupled to the processor, wherein, in use, the processor is controlled by the computer program code for:

receiving, via the network interface from a sender terminal, a transaction ID request, the transaction ID request comprising document metacontent;

generating a transaction ID;

storing, in the database, the metacontent in relation to the transaction ID;

sending, via the network interface to the sender terminal, the transaction ID;

receiving, via the network interface from a receiver terminal, a document metacontent retrieval request, the document metacontent retrieval request comprising at least the transaction ID;

retrieving, from the database, the metacontent in accordance with the transaction ID;

sending, via the network interface to the receiver terminal, the metacontent.

18. A server as claimed in claim 17, wherein the transaction ID is a print of the document.

19. A server as claimed in claim 18, wherein the print comprises a barcode.

20. A server as claimed in claim 19, wherein a barcode is a 2D barcode.

21. A server as claimed in claim 20, wherein the 2D barcode encodes a URL associated with the transaction ID.

22. A server as claimed in claim 18, wherein the processor is further controlled by the computer program code for receiving, via the network interface, scan data of the print, and identifying the transaction ID in accordance with the scan data.

23. A server as claimed in claim 17, wherein the transaction ID request further comprises document content data and wherein the processor is further controlled by the computer program code for generating the transaction ID further in accordance with the document content data.

24. A server as claimed in claim 23, wherein generating the transaction ID in accordance with the document content data further comprises generating scan invariant document content data in accordance with the document content data and generating the transaction ID in accordance with the scan invariant content data.

25. A server as claimed in claim 17, wherein the processor is further controlled by the computer program code for using a web service to receive, via the network interface from the sender terminal, the transaction ID request.

26. A server as claimed in claim 17, wherein the document metacontent comprises markup language.

27. A server as claimed in claim 26, wherein the markup language comprises XML.

28. A server as claimed in claim 27, wherein the processor is further controlled by the computer program code for validating the XML.

29. A server as claimed in claim 17, wherein the processor is further controlled by the computer program code for allocating the transaction ID a session lifespan.

30. A server as claimed in claim 17, wherein receiving the transaction ID comprises serving, at a URL associated with the transaction ID, and the metacontent.

31. A server as claimed in claim 17, wherein the processor is further controlled by the computer program code for fetching further document metacontent in accordance with the transaction ID request.

32. A server as claimed in claim 17, wherein the transaction ID is a sparse ID.

33. A computer readable storage medium for transmitting document metacontent, the computer readable storage medium readable by a computing device and comprising instructions for controlling the computing device, including instructions for:

generating a transaction ID;

storing the metacontent in relation to the transaction ID;

sending, to the sender terminal, the transaction ID; receiving, from a receiver terminal, a document metacontent retrieval request, the document metacontent retrieval request comprising at least the transaction ID;

retrieving the metacontent in accordance with the transaction ID; and

sending, to the receiver terminal, the metacontent.

34. A computer readable storage medium as claimed in claim 33, wherein the transaction ID is a print on a document.

35. A computer readable storage medium as claimed in claim 34, wherein the print comprises a barcode.

36. A computer readable storage medium as claimed in claim 35, wherein a barcode is a 2D barcode.

37. A computer readable storage medium as claimed in claim 36, wherein the 2D barcode encodes a URL associated with the transaction ID.

38. A computer readable storage medium as claimed in claim 34, further comprising instructions for receiving scan data of the print, and identifying the transaction ID in accordance with the scan data.

39. A computer readable storage medium as claimed in claim 33, wherein the transaction ID request further comprises document content data and wherein the method further comprises generating the transaction ID further in accordance with the document content data.

40. A computer readable storage medium as claimed in claim 39, wherein generating the transaction ID in accordance with the document content data further comprises generating scan invariant document content data in accordance with the document content data and generating the transaction ID in accordance with the scan invariant content data.

41. A computer readable storage medium as claimed in claim 33, further comprising instructions for using a web service to receive, from the sender terminal, the transaction ID request.

42. A computer readable storage medium as claimed in claim 33, wherein the document metacontent comprises markup language.

43. A computer readable storage medium as claimed in claim 42, wherein the markup language comprises XML.

44. A computer readable storage medium as claimed in claim 43, further comprising instructions for validating the XML.

45. A computer readable storage medium as claimed in claim 33, further comprising instructions for allocating the transaction ID a session lifespan.

46. A computer readable storage medium as claimed in claim 33, wherein receiving the transaction ID comprises serving, at a URL associated with the transaction ID, and the metacontent.

47. A computer readable storage medium as claimed in claim 33, further comprising instructions for fetching further document metacontent in accordance with the transaction ID request.

48. A computer readable storage medium as claimed in claim 33, wherein the transaction ID is a sparse ID.