Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
  • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
  • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
  • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/90—Details of database functions independent of the retrieved data types
  • G06F16/95—Retrieval from the web
  • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
  • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network

Definitions

• the present invention relates to a system and method for sending and receiving content data across a network and in particular, web pages across the Internet.
• HTML data may be stored on the web server and provided to one or more browsers upon request.
• a URL may be typed into a browser, which specifies the location of the requested content.
• a web server at that location then responds by providing the requested content data or HTML web page.
• server side or client side processing may take place. Under these circumstances, the request from the browser may include data sent to the web server forming two way communication.
• This two way communication may include sensitive or valuable information and so various types of encryption involving symmetric keys, public key and private key, and digital signatures may be used.
• the data (transmitted and received over the Internet) may be readily intercepted but decryption may involve significant overheads.
• the web server itself must have access to the unencrypted data at some point during processing in order to meet the browser requests. Therefore, the web server or database storing content may become vulnerable to attack as they contain a concentration of valuable or sensitive
• the web server or group of web servers may become vulnerable to denial of service type attacks where a volume of requests is initiated that can overwhelm the resources of the web server or group of web servers. Under such attacks or under especially high traffic volumes, requests from browsers may go unfulfilled.
• Certain countries may wish to restrict access to areas of the Internet by blocking or filtering incoming web traffic.
• the web traffic may include news and other public information that is not encrypted, making it straightforward for such regimes to restrict legitimate access.
• Individual browsers or groups of browsers may be monitored to determine if they are attempting access to such material, leading to significant censorship. Therefore, users of browsers and web servers supplying content data to them may prefer to avoid such monitoring of activity. Therefore, there is required a system of providing content data that overcomes these problems.
• a method of delivering content data over a network comprising the steps of : receiving a request over a network for content data from a requester, the request including enablement
• the content data which may be used to render a web page, for example, may be sent more securely and/or reliably.
• the enablement information may alternatively be described as access information, location data, an
• the enablement information may comprise one or more of: data allocation information; encrypted data allocation information; and a decryption key for decrypted data allocation information.
• the request may include information enabling a server or processor to find and retrieve the separate data components from the one or more storage locations. Where a key is sent then data allocation information may be stored local to the processor (or server) or elsewhere, but only accessible to the
• Enabling retrieval of the separate data components may also include providing an indication of which set of allocation data (e.g. FAT table) out of many alternatives to use to respond to a particular request .
• processing the enablement information may further comprise the step of decrypting encrypted data allocation information using a decryption key.
• the request may be received over the
• the Internet and separate data components may be sent over the Internet.
• the request and/or data may be sent using HTTP, for example.
• the network may use the internet protocol, for example .
• the storage locations may be separate storage locations. They may be physically and/or logically separate, for example. They may be provided with addresses or unique addresses such as IP addresses, for example.
• the separate storage locations may be physically and/or remote separate storage locations.
• processing the enablement information to determine data allocation further comprises generating a file allocation table.
• Processing may include reading, decrypting or using the supplied information to identify and/or decrypt information from other sources, for example.
• the separate data components may be sent together with data component identifiers. This facilitates more convenient restoration of the data or payload
• the separate data components may include parity data such that any one or more of the separate data components are recreatable from the remaining separate data components and the parity data.
• the parity data may be stored, transmitted to the requester, referenced by the data allocation information or otherwise handled in the same way as the separate data components.
• the content data may comprise any one or more of: page layout, design elements, video, graphics, audio and web page content.
• a second aspect there is provided method of retrieving content data across a network, the method comprising the steps of:
• the request including enablement information to enable retrieval of the content data from one or more storage locations;
• generating the content may further comprise reconstructing the content data from a data map providing an indication of how the separate data components form the content data.
• the data map may also be received in response to the request.
• the separate data components may include parity data and wherein generating the content data further comprises the steps of:
• a data map describes which parity data corresponds with which data components.
• a server comprising :
• a request over a network for content data from a requester including enablement information to enable retrieval of the content data from one or more storage locations;
• the server may be web server, for example.
• a client for retrieving content data across a network comprising logic configured to:
• the request for content data from a server including enablement information to enable retrieval of the content data from one or more storage locations;
• the client may be a browser, terminal, mobile terminal or any processor making requests for data across a network .
• the logic configured to generate the content data from the separated data components may further comprise logic configured to:
• the data components may include identifiers corresponding to identifiers within the data map.
• the separate data components may include parity data and wherein the logic configured to generate the content data further comprises logic configured to :
• the client may further comprise logic configured to generate a web page from the content data.
• a method of storing content data comprising the steps of:
• the content data may be stored more securely.
• the method may further comprise the step of generating an identifier for each separate data component and wherein the data map includes in its indication the identifiers for the separate data components.
• the method may further comprise the step of encrypting the data allocation information and/or the data map .
• the content data may be web content.
• the method may further comprise the step of:
• the method may further comprise the step of:
• the method may further comprise the step of storing the generated parity data in the one or more storage locations.
• the parity data (or redundant data) may then be treated and processed in a similar way to the data
• the methods described above may be implemented as a computer program comprising program instructions to operate a computer.
• the computer program may be stored on a
• the logic may be provided as software, firmware, installed instructions or received as scripts, for example.
• FIG. 1 shows a schematic diagram of a system for sending content data from a web server to a browser, given by way of example only;
• FIG. 2 shows a schematic diagram of a system for providing content data from the web server of figure 1 to the browser;
• FIG. 3 shows a flow diagram of a method for storing content data including a dividing step
• FIG. 4 shows a flow diagram of a method for sending the stored content data of figure 3 to the browser
• FIG. 5 shows a flow diagram of a method for requesting content data including a data regenerating step
• FIG. 6 shows a schematic diagram indicating a method for generating parity data as part of the dividing step of figure 3, given by way of example only;
• FIG. 7 shows a schematic diagram of an illustrative method of the data regenerating step of figure 5 and using parity data generated in accordance with the method shown in figure 6;
• FIG. 8 shows a schematic diagram of a further embodiment
• Figure 1 shows a high level schematic diagram of a system 10 for providing content data 15 to a terminal, client or browser 20.
• the content data 15 itself may reside in a distributed storage system 80 as separate data components 90 forming the content data 15. Division of the content data 15 into the separate data components 90 is described with reference to figure 3 later on.
• the browser 20 issues a request 70 that includes enablement information or a key enabling or allowing the distributed storage system 80 to retrieve the particular data components 90.
• enablement information the server may not be able to retrieve the content data due to security restrictions or simply because the server would not have enough information to determine what particular data to retrieve or where to retrieve it from.
• These data components 90 may be stored separately and so the enablement information may provide the system with the information required to determine the allocation and location of the data components 90 within the storage system 80 or provide the system with access to this allocation information.
• the enablement information may include a cryptographic key that may be used to decrypt a file
• allocation table describing the allocation of data within storage system 80.
• the request 70 may include the file itself either encrypted or as plain text, depending on security requirements.
• the storage system may include multiple separate and remote storage devices and the separate data components 90 may be distributed amongst these different and/or remote storage locations.
• processing may take place to join the separate data components 90 to provide content data that may be read and rendered
• For processing logic 55 may provide the initial combining steps producing a single set of data 50, which may be considered to be a payload, for example.
• the distributed storage system 80 may provide additional functionality
• these overheads 40 may include identifiers for each separate data component 90, a data map describing an indication of how the separate data components 90 may form the resultant content data (e.g. a web page) .
• the payload 50 may include text, features, and other media.
• Any overheads 40 may provide an indication or information as to how the payload should be reconstructed and rendered. This takes place in post processor 30, which receives the payload 50, the overhead and preferably a decryption key (which may be the same or different to that formed provided in the request 70) . This decryption key may be used to decrypt aspects or the entire set of overheads 40 producing a map of data 60 to be used via the post processor 30 to compile and/or render the content data 15 in its correct form to be displayed or played to the user.
• FIG. 2 shows a schematic diagram providing more detail describing how the request 70 from the browser 20 is met by the distributed storage system 80.
• the distributed storage system 80 may include several storage devices 190, which may also act as separate web servers. In this
• the request 70 from the browser 20 includes a key 75, which may be used within a processor 130 executing logic to enable decryption of the FAT 100.
• Processor 130 may also comprise a web server or other server-type
• the processor 130 uses the decrypted FAT 100 to locate and retrieve the separate data components 90 from the separate storage locations 190 within the distributed storage system 80.
• the individual storage locations 190 may be separated across a wide area such that local events disrupting or destroying individual storage devices 190 will not affect the remaining storage devices 190 within the distributed storage system 80.
• FIG. 3 shows a flow chart of a method 200 for storing content data within the separate storage locations 190 of the distributed storage system 80.
• Content data 15 is split or divided into the data 220 components 90 at step 220.
• Parity data is generated for the separate data components at step 230. Generation of the parity data is described with reference to figures 6 to 8.
• data allocation information is generated. This data allocation information may be in the form of the FAT 100 described with reference to figure 2. The data allocation information describes how and where each data component is stored in the separate storage locations 190 and may be used when retrieving such separate data components 90. The data allocation
• the data allocation information may be generated at the time of storage or in advance.
• the data allocation information may be specific to the web content data 15 being stored such that this particular item of content data is recoverable when stored within the distributed storage system 80.
• a map of data is generated at step 250.
• This map of data 60 may be used by the browser 20 to reconstruct and render the content data 15 as required.
• the separate data components 90 may have assigned one or more, or perhaps each of them, an identifier that is referenced in the map of data 60. Therefore, during or preferably before this step, such overheads may also be generated.
• the identifiers may be reference both within the FAT 100 and the data map 60.
• the data allocation information or FAT 100 may be encrypted at step 260 to improve security. Furthermore, the map of data and/or overheads may be encrypted at step 270 also to improve security.
• the separate data components 90 may be stored within the allocated storage devices 190 in accordance with the allocation data allocation information or FAT 100.
• Figure 4 shows a flowchart for responding to a browser request for data content 15 issued by a browser 20.
• This method 300 may be executed by a processor 130, for example.
• a browser request including the FAT key 75 may be received at step 310.
• the FAT 100 may be obtained using the FAT key 75, preferably during a
• a FAT 100 may provide the data allocation information generated at step 240 of method 200. This FAT 100 may be stored locally within the processor 130, but only decryptable on receipt of the key 75 by
• the request includes enablement information to enable retrieval of the content data from one or more storage locations and this enablement information in this particular example is in the form of a decryption key 75.
• the data components and any accompanying parity data may be retrieved according to the FAT 100 from the separate storage devices 190. These retrieved data components and parity data are sent to the requesting browser 20 at step 340. At the same time or separately, the overheads, including data component identifiers are also sent to the requesting browser at step 350.
• Figure 5 shows a flow chart of a method 400 carried out within the browser 20 for requesting and then rendering content data.
• the browser sends a request at step 410.
• This request includes the FAT key 75.
• data components and parity data are received at step 420.
• the overheads 40 and data map information are received at step 430. Any missing data components are regenerated or recreated at step 440.
• An example regeneration procedure is described in further detail with reference to Figures 5, 6, 7 and 8, which uses the received parity data as well as any remaining or
• the data map 60 may be decrypted at step 450.
• the received data components 90 and any regenerated data components are used to restore the payload 50 forming the original information.
• the decrypted data map 60 along with the overheads 40 (data component identifiers) are used to render and form the resultant web page at step 460 for display or play to a user .
• Simple division of the content data may be used to generate message components of equal or substantially equal size or length. However, in order to improve security and/or data recovery then more complex error correcting or secure algorithms may be used in this procedure.
• Corresponding regeneration or combining algorithms or collating steps may be used when receiving the content data.
• the components may include parity data generated as described with reference to figures 6, 7 and 8. As an example, this processing may occur within or as part of the core processing logic 55.
• parity data may be generated using the exclusive OR function (XOR) . e.g.:
• this original data (F) may be divided into equal blocks or subsets. This may be represented as:
• Parity data may be generated as:
• FIG. 6 shows a method 1000 for generating more robust sets of parity data.
• This method 1000 allows for a greater number of data subset (and/or parity data) losses before the data becomes unrecoverable.
• the solid numbered circles 1, 2, 3,...n represent data subsets formed by dividing the original data.
• Two sets of parity data are generated for each data subset.
• Each data subset is paired with another data subset and parity data is generated.
• the data subset is then paired with a different data subset and a further set of parity data is generated.
• each data subset is associated with two different other data subsets with parity data generated for each pairing.
• each data subset being paired with both of its neighbours (e.g. 2 paired with 1 and 2 also paired with 3) .
• the first (1) and last (n) data subsets only have one neighbour (2 and n-1 respectively) .
• the first data subset is paired with the last data subset so that more than one set of parity data may be associated with the end data sets.
• any other combination and permutation may be used so that each data subset has at least two parity data sets associated with it. In notation form, this may be described as:
• the loss of four data subsets may still enable reconstruction of all of the original data provided that all of the parity data sets are retrievable.
• FIG 7 schematically shows an example method 100 for reconstructing or regenerating missing data subsets.
• the third data subset is available as well as the five parity data sets (1 ⁇ 2, 2 ⁇ 3, 3 ⁇ 4, 4 ⁇ 5 and 5 ⁇ 1) .
• the box in figure 7 shows two alternative ways in which each of the missing data subsets 1, 2, 4 and 5 may be reconstructed using the XOR function.
• Figure 8 shows a further example situation in which, five data subsets and created from original data but where two of the data subsets and two of the parity data sets (2 ⁇ 3 and 3 ⁇ 4) are lost or missing.
• the two missing data subsets 2 and 4 are recovered using the XOR operations shown in the side box.
• the loss of data subsets in any combination up to (n-1) may still result in all of the data being recoverable.
• each data subset may be paired with non-neighbouring subsets to form parity data.
• predetermined number of data subsets may be chosen. This may relate to the number of available or required storage locations (for each data subset and each parity data set) that are to be used, or separate data channels or other means of transmitting the data subsets from one location to another .
• the data map 60 may be used to restore and allow rendering of the content data 15 in its desired format.
• Web pages may be provided as HTML (hypertext markup language) . Under this standard, components of the page are labelled (markup) with tags enclosed in angle brackets " ⁇ " and ">". For example the entire page starts with the tag “ ⁇ html>” and closing tag “ ⁇ / html>", the main contents page (page body) opens with the tag “ ⁇ body>” and closing tag " ⁇ / body>".
• Service information may be specified in the tag " ⁇ meta>", while scripts (executable scripts), executed on the page within the client's browser, may be enclosed in the tags " ⁇ script>” and " ⁇ / script>", etc.
• the payload 50 may contain media forming the web page (e.g. text, images and other elements) .
• the payload 50 is stored and transmitted as separate data components 90.
• Other information forming the overheads 40 may be stored and transmitted as whole data (undivided) .
• the data map 60 provides the information necessary to the client or browser 20 for restoring the separate data components 90 into the payload 40.
• the overheads 40 and/or the data map 60 may also contain information necessary to render the content data 15.
• Data map 60 may include a set of identifiers for the data components 90 in the form of HTML tags.
• the data map 60 describes how the data components 90 are to be
• the FAT 100 describes how the separate data components 90 from the original content data, are distributed across the distributed data storage system 80.
• Each separate data component may be assigned an identifier (which may be attached to it, provided as a header or embedded within it, for example) .
• the FAT 100 may include a cross reference of identifier to location (this may also be an identifier such as an address or IP address, for example) . Therefore, the FAT 100 provides the processor 130 with the information necessary to retrieve each separate data component.
• Either or both the FAT 100 and data map 60 may be encrypted. Both files may have a particular format or grammar. Although any format or grammar may be used
• An initialization file Microsoft (ini-files). These files consist of sections in square brackets and a set of parameters, e.g.:
• HTML HyperText Markup Language
• HTML HyperText Markup Language
• processors 130 e.g. servers or web servers
• browsers or clients 20 including one or more.
• Other ways of dividing the data and/or generating parity data may be used including simple data separation.
• parity data (if at all) .
• These methods include applying the XOR logical function in different ways as well as using the Solomon-Reed function.
• Parity data may also be considered to be redundant data.
• redundant data is data that is not necessary if all data components are available or safely received but they may be used to assist in regenerating or replicating any missing components or those that for some reason (e.g. corruption) are
• parity data and redundant data may be used interchangeably.
• Many combinations, modifications, or alterations to the features of the above embodiments will be readily apparent to the skilled person and are intended to form part of the invention. Any of the features described specifically relating to one embodiment or example may be used in any other embodiment by making the appropriate changes.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• General Engineering & Computer Science (AREA)
• Databases & Information Systems (AREA)
• Theoretical Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computing Systems (AREA)
• Computer Hardware Design (AREA)
• Data Mining & Analysis (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Information Transfer Between Computers (AREA)
• Storage Device Security (AREA)

Priority Applications (4)

Applications Claiming Priority (2)

Publications (1)

Family

ID=45991945

Family Applications (1)

Country Status (5)

Cited By (5)

Families Citing this family (2)

Citations (3)

Family Cites Families (12)

• 2012
  • 2012-02-29 GB GBGB1203558.0A patent/GB201203558D0/en not_active Ceased
• 2013
  • 2013-02-27 US US14/382,173 patent/US20150067334A1/en not_active Abandoned
  • 2013-02-27 WO PCT/EP2013/053964 patent/WO2013127877A1/en not_active Ceased
  • 2013-02-27 JP JP2014559203A patent/JP2015511742A/ja active Pending
  • 2013-02-27 EP EP13708116.2A patent/EP2820589B1/en active Active

Patent Citations (3)

Also Published As

Similar Documents

Legal Events