APPLICATION PROGRAMMING INTERFACE FOR WEB APPLICATION PLATFORM SECURITY SYSTEM

Abstract

The present invention includes a system for monitoring the transmission of digital files across a secured boundary of a private ecosystem. Because an application programming interface making calls to a web application platform controls the placement of security tokens, distinct programs on devices from which transmissions originate, or are bound, to place and update tokens is generally obviated.

Description

RELATED APPLICATIONS

This application is a continuation of, and claims priority under 35 U.S.C. §120 from U.S. patent application Ser. Nos. 13/429,348; 13/429,350; 13/429,351; 13/429,366; 13/429,367; 13/429,368; 13/429,369; 13/429,370, all filed Mar. 24, 2012, the disclosure of which is incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to the field of data security and more specifically to the field of data tracking and derivation analysis.

BACKGROUND

Extensible Markup Language “XML” is a flexible way to generate common, easily-exchanged information formats and share both the format and the data on the World Wide Web, internal networks, and elsewhere. XML is similar to hypertext markup language (HTML). Both XML and HTML include markup tags to describe a file or page's contents. HTML describes the content in terms of how the content is displayed while XML structures, stores, and transports information. Thus, an XML file can be processed purely as data by a program. Alternately, the XML file can be displayed or stored.

While HTML uses predefined tags, XML permits a developer of an XML document or fragment to define tags. Almost any data item can be identified using a XML tag. The standard method to allow an XML document to be created, accessed, or modified is with a document object model (DOM). A standardized specification has been developed that defines the interfaces for the different objects comprising the DOM, but does not provide any specifics for how a DOM should be implemented. Therefore, a programming language that utilizes a DOM compliant with the standard will produce an instance of that DOM that is language-neutral and platform-independent, regardless of how the underlying language implements the model.

Therefore, there is a need for a security process and system capable of discreetly marking files, marking files with authenticity data, efficiently searching for instances of the marked files internally and externally, and determining file alterations/modifications/actions. Furthermore, there is a need for a centralized system of placing and recording tokens and their attributes as they relate to document access and modifications.

SUMMARY

The present invention is directed to a steganographic digital data security process and system for authenticating files composed of markup language. The digital data security process includes accessing a markup language document object model that includes markup language format schema related to a particular digital file desired to be utilized by the present invention. Authenticity data is generated in the form of a cryptographic token with an identity marker. The digital file is reviewed to determine the markup language tag arrangement of which the digital file is constituted. The cryptographic token is placed within at least one of the markup language tags in a manner that prevents the cryptographic token from being recognized as markup language instructions according to the document object model. The resulting marked digital file carries within its markup language tags authenticity data relating to such information as is desired by a user to be associated with the digital file.

The marked digital file, because the interior authenticity data that identifies it is inert within the markup language tag(s), behaves exactly as an unaltered digital file. The marked digital file may undergo all of the processes of a similar digital file. The marked digital file will carry within its contents the identity marker and encrypted authenticity data; thus, a user may scour a suspect digital file or suspect set of digital files to find the marked digital file, which may be located or identified on the basis of the identity marker. When the identity marker is located within the marked digital file it may be culled from a larger file set for further review. A user may scour digital files and digital file sets in multiple fashions, transmission scouring, dynamic external scouring, dynamic internal scouring, or manual scouring. Upon identifying a file as pertaining to a desired source, a user may provide a key that decrypts the marked file to expose in plain text the authenticity data within the cryptographic identity token.

The digital data security system includes the markup language document object model, a cryptographic token generator, a markup language mapping function, a cryptographic token embedding function, a scouring agent, a persistent data storage facility, and a data retriever. The markup language document object model includes a listing of schema corresponding to one or more file formats. The cryptographic token generator is supplied with authenticity data including identity attribution elements to produce a cryptographic token with an identity marker that points to the containing encrypted authenticity data. The markup language mapping function reviews a digital file to determine the markup language tag arrangement of the file. The cryptographic token embedding function positions the cryptographic token inertly within a markup language tag that corresponds to sets of text, corresponding to grammatical or other stylistic text arrangements, and is purposefully imitative of markup language recognized as functional by the document object model corresponding to the digital file. The resulting output is a marked digital file.

The marked digital file of the present invention includes at least one cryptographic token of the present invention embedded inertly within the markup language of the contents of a digital file. The marked digital file may be created by the process of the present invention directly or indirectly. The system and process of the present invention are means of directly creating a marked digital file. A marked digital file may be indirectly created when a user copies a textual portion of a marked digital file. As a copier of the marked digital file may not copy a rendered subcomponent of the marked digital file without also copying the markup language related to the copied portion, a new document derived from the marked digital file also includes the authenticity data of the original marked digital file. The present invention permits tracking of a document derived from marked digital files as well marked digital files.

The system and process further include scouring markup language tags within a file for an identity marker; scouring a database of multiple external files composed of extensible markup language for an identity marker; scouring a transmission of multiple files composed of extensible markup language for an identity marker; and scouring a database of multiple internal files composed of extensible markup language for internal files lacking an identity marker. The present invention further includes a file created according to the process and subprocesses herein or utilized by the system and components thereof. Instructions may be provided to systems and software manipulating an editable document with a cryptographic token with particular authenticity data.

A centralized version of the present invention includes a digital data security system for controlling inbound and outbound Internet communications to/from a private ecosystem. A web application platform, such as SHAREPOINT, which a conduit between party-to-party Internet communications, such as through a virtual private network, controls the communicates and has access to files transferred thereby. An application programming interface (“API”) makes calls to the web application platform to ascertain the identity of parties beyond the private ecosystem and determine whether digital files are being transferred to or from the parties. The API monitors the Internet traffic for inbound and outbound digital files, and may insert tokens therein and record authenticity attributes related to the files and parties.

These aspects of the invention are not meant to be exclusive. Furthermore, some features may apply to certain versions of the invention, but not others. Other features, aspects, and advantages of the present invention will be readily apparent to those of ordinary skill in the art when read in conjunction with the following description, and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a view of an embodiment of the process of the present invention.

FIG. 2 is a view of an embodiment of the system of the present invention.

FIG. 3 is a view of an embodiment of the system of the present invention.

FIG. 4 is a view of an embodiment of the process of the present invention.

FIG. 5 is a view of an embodiment of the system of the present invention.

FIG. 6 is a view of an embodiment of the system of the present invention.

FIG. 7 is a view of an embodiment of the system of the present invention.

FIG. 8 is a view of an embodiment of the system of the present invention.

FIG. 9 is a view of an embodiment of the system and process of the present invention.

FIG. 10 is a view of an embodiment of the system and process of the present invention.

FIG. 11 is a view of an embodiment of the system and process of the present invention.

FIG. 12 is a view of an embodiment of a web application platform.

FIG. 13 is a view of an embodiment of the system and process of the present invention.

FIG. 14 is a view of an embodiment of the system and process of the present invention.

FIG. 15 is a view of an embodiment of the system and process of the present invention.

FIG. 16 is a view of an embodiment of the system and process of the present invention.

DETAILED DESCRIPTION

Referring first to FIGS. 1 and 2, a basic embodiment of the digital data security process 100 and system 200 for tracking and identifying renderable digital files is shown. The digital files most applicable to the present invention include text files constituted of markup language, e.g. docx. Even more preferred are text digital files constituted of extensible markup language (“XML”). By text files, it is meant files containing data rendered by a program into visible text. Markup language is a modern system for annotating text within a text file according to its attributes. Markup is typically omitted from the version of the text which is displayed, i.e. rendered, for end-user consumption. Some markup languages, such as HTML, have presentation semantics, meaning their specification prescribes how the structured data is to be presented, but other markup languages, such as XML, have no predefined semantics.

As the present invention manipulates markup language documents, the schema corresponding to a particular markup language is determined. The digital data security process 100 includes accessing 102 a markup language document object model (“DOM”) 206 that includes markup language format schema related to a particular digital file desired to be utilized by the present invention. The markup language DOM defines a standard way for accessing and manipulating markup language documents. The markup language DOM contains methods (functions) to traverse markup language trees and access and manipulate digital file nodes. A parser that supports the DOM will take the data in a markup language formatted file and expose the file via a set of objects that a user may manipulate. The particular DOM that will be applied to the present invention may be chosen on the basis of the file that a user desires to create or investigate. By way of example, if a user is creating a .docx document with the present invention, the process 100 may access 102 the XML DOM.

With reference to FIGS. 1 and 2, to identify and track a digital file 900, authenticity data 204 is integrated 104 by a token generator 202 into a cryptographic token with an identity marker. The token generator 202 includes as an input the digital file 900 with markup language. As the digital file 900 will necessarily include file identification information, the token generator may then select the appropriate DOM 206 by which to parse the information within the digital file 900. The token generator receives as further input authenticity data 204 supplied by a user of the system. Turning now to FIG. 3, the authenticity data 204 may include one or more authenticity attributes 218. Preferred authenticity data includes the system data of the computer of the user that is predefined and globally utilized by the user's computer. Further authenticity data include time stamps, location attribution elements, identity attribution elements, network attribution elements, operating and software licensing attribution elements, hardware attribution elements, user attribution elements. Potential authenticity data is highly varied and is not to be limited by the present disclosure; any data that a user desires to be associated with a document may be utilized as authenticity data.

The token generator 202 creates a cryptographic token 208 composed of the identity marker 214 and the authenticity data as the authenticity attributes 218. The encryption performed by the token generator 202 is not limited to any particular means of encryption. The present invention may be utilized with a parameterized hash, polymorphic key or a combination of the two, as well as, symmetric or asymmetric key encryption. The present invention may be utilized with any number of modular encryption routines. The present invention may also be utilized with a connection to an identity management system that may or may not rely on certificate based authentication for user identity. To ensure the integrity of the identity fingerprint, no key elements are stored within the fingerprint. The cryptographic token further includes an identity marker 214. By identity marker 214, it is meant the token portion by which the cryptographic token is identified. The identity marker is a comparative, and/or a correlative function, and is such whether the identity marker consists of encrypted data or not. The preferred identity marker 214 includes an information segment that is generic to the process or system, in other situations, it may be preferred to utilize identity markers specific to a user. The invention does not require that the document content be encrypted in order to utilize the current invention.

Returning now to FIGS. 1 and 2, the markup language tag arrangement is determined 106 by the markup language mapping function 220. The markup language mapping function 220 ascertains the structure of the digital file that the user desires to manipulate. The mapping may be as simplistic as searching for a single instance of a particular markup language tag, or may be as complex as mapping the entirety of the file structure of the digital file in parent/sibling/child nodes. It is preferred that the present invention utilize a repeating markup language tag that corresponds to renderable expression. An example of a preferred markup language tag includes the markup language tag for the paragraph structure of a document. For reasons explained in this disclosure, infra, a repeating markup language tag corresponding to renderable expression is preferred to permit the facile determination of digital files derived from marked files 222, i.e. digital files bearing cryptographic tokens supplied by the present invention.

The token generator 202 with reference to the DOM 206 preferably creates a cryptographic token that in its final form utilizes as expression only symbols permitted by the DOM. It is further preferred that the token generator 202 create a cryptographic token that in its final form utilizes as expression symbols purposefully imitative of the markup language tag of the digital file into which the cryptographic token will eventually by placed. For example, if the destination for the cryptographic token is the markup language tag corresponding to a paragraph, the token generator utilizes symbols related to the symbols for that of the paragraph markup language tag. The particular means of imitation may depend on the nature of the desired imitation and knows as its only restriction that the imitation may not permit a program to render the cryptographic token as text or prevent otherwise renderable data within a functional markup language tag to be rendered as text. The token generator 202 creates a cryptographic token expressed in a form in which, when reviewed by a reading program, does not register as functional markup language instructions pursuant to the DOM, i.e. the cryptographic token is “inert” as it relates to the DOM and programs operating with reference to the DOM.

Although the present invention is primarily described herein as relating to xml files, the invention is broadly applicable to all file forms. In particular, the present invention relates to all renderable files that include an unrendered instruction component and a renderable component. An additional example of files amenable to the present invention are .pdf files. Certain pdf files, as characterized in Adobe Systems Incorporated (2008-07-01), Document Management-Portable Document Format, Part 1: PDF 1.7, First Edition, include highly sophisticated syntax. The syntax includes four elements: objects, file structure, document structure, and content streams. The pdf file structure determines how objects are stored in a pdf file, how they are accessed, and how they are updated. This structure is independent of the semantics of the objects. The pdf document structure specifies how the basic object types are used to represent components of a pdf document: pages, fonts, annotations, and the like. A pdf content stream contains a sequence of instructions describing the appearance of a page or other graphical entity. These instructions, while also represented as objects, are conceptually distinct from the objects that represent the document structure and are described separately. The cryptographic token may be placed in any of the pdf syntax sub-element instructions, e.g., markup language tags, that characterize the elements, so such as the placement is inert.

The cryptographic token is embedded 108 by the fingerprint updater 224 within one or more of the markup language tags of the destination digital file 900 in a manner that prevents the cryptographic token from being recognized as functional markup language with reference to the DOM or disrupting legitimate functional markup language present in the destination digital file prior to the introduction of the cryptographic token, i.e. “inert” placement within the markup language tag. Together with the inert construction of the cryptographic token, the inert placement of the cryptographic token with the markup language creates a data structure that is securely embedded within the markup language digital file and not renderable or detectable during the normal operation of a resulting marked digital file 222, yet fully reviewable for authenticity data. Placement of a cryptographic token is performed via employing various element attributes of the DOM using standard xml syntax and markup. These element attributes include styles, paragraphs, and fonts. A preferred means of placement of a cryptographic token includes positioning the cryptographic token after the “/” in the markup language tag statement which usually terminates in a “</>” phrase. Alternative positioning includes any location within a markup language that causes no reaction adverse from the underlying application.

The resulting marked digital file 222 carries within its markup language tags authenticity data relating to such information as is desired by a user to be associated with the digital file. Turning now to FIGS. 2 and 4-6. The marked digital file 222 may be sought by scouring 110 one or more digital files with a scouring agent 226 for instances of the identity markers present in marked digital files 222. The means of scouring 110 are diverse and vary by the capabilities and connectivity of the user. Four preferred means of scouring include transmission scouring 228, dynamic external scouring 230, dynamic internal scouring 232, and manual scouring 234. In manual scouring 234, the user specifies one or more documents from a suspect document set 902 that it desires to be scoured. Upon scouring the system and process review the data structure of the suspect documents 904 within the suspect document set 902. The present invention may either seek the identity marker of the cryptographic token or attempt to decrypt portions of the suspect document to determine the presence of the cryptographic token. Any decryption would require a key issued to the user, which may be activated by an access code input by the user. Digital files bearing a cryptographic token of the present invention may be listed in a marked digital file database 236 or otherwise physically copied in the digital file database 236.

In dynamic external scouring 230 the present invention may utilize a crawler bot to scour digital files available over an external network, e.g. the Internet. Upon locating a marked digital file, the system or process may list the marked digital files in a marked digital file database 236 or otherwise physically copy the marked digital files in the marked digital file database 236. In dynamic internal scouring 232, the present invention may utilize a crawler bot to scour digital files available over an internal network, e.g. local area network. By crawling, is meant an automated routine by which an agent selects data sources and combs the data sources. External crawling may be accomplished by any means known in the art, including the means disclosed in U.S. Pat. Nos. 7,647,370; 7,647,351; 7,181,681; 7,072,890; 6,418,433; and 6,638,314, which are hereby incorporated by reference. Internal crawling may be accomplished by any means known in the art, included the means disclosed in U.S. Pat. Nos. 7,698,259; 7,386,544; 6,463,433; and 6,321,224, which are hereby incorporated by reference.

Upon locating a marked digital file, the system or process may list the marked digital files in a marked digital file database 236 or otherwise physically copy the marked digital files in the marked digital file database 236. The present invention need not be confined merely to seeking marked digital files; in certain instances where a network would be populated primarily by marked digital files, the present invention may scour suspect document sets 904 for digital files lacking a cryptographic token, either partially or wholly. In embodiments of the present invention configured to scour suspect document sets 904 for digital files lacking a cryptographic token, the present invention would proceed as in any other scouring embodiment, however, the suspect document sets may be identified by through fingerprint analysis as lacking a cryptographic token. The suspect document sets may include any variety of document sets and repositories thereof, including internal storage, websites, databases, networks, etc. Once identified, the digital file lacking a cryptographic token may be handled as desired by the operator of the present invention. Such actions may include, forbidding continued transmission of the unmarked file, recording the file in a database, recording attributes of the file in a database, or any other security action known to IT protection.

Turning now to FIG. 12, the general architecture of a private ecosystem's secured network is shown. A user with an electronic device 906 may through the Internet access the private ecosystem through the ecosystem boundary 710 to reach the web application platform 702. A web application platform 702 is a software product adapted to control communications from a private party to another party via the Internet or other electronic communication method. A preferred web application platform of the present invention is MICROSOFT SHAREPOINT. SHAREPOINT may utilize a firewall 796 to control access to a private ecosystem, which includes corporate secured networks. SHAREPOINT controls access by permitting external activity based on permissions detailed in the active directory. The active directory of the present invention includes any listing of credentials as correlated to an entity, whether specific (e.g., Joe Employeeson) or general (e.g., guest). From the web application platform a user 906 may access ecosystem resources 704 that may include MS EXCHANGE, databases, the ecosystem intranet, etc.

Turning now to FIG. 13, a customized application programming interface (“API”) utilizing the system 200 of the present invention operates as an overlay on top of SHAREPOINT. The API has access to the logging function of SHAREPOINT or other means of determining the source of external transmissions into the private ecosystem. An example of an external transmission into the ecosystem include virtual private network (“VPN”) communications. The API may utilize any of the features described in this disclosure as a system 200 or process; however, the advantage of the scheme of this centralized embodiment is that distinct programs for the review and application of security tokens need not be present on all parties to a external-to-internal transmission. By coordinating token application, modification, etc. via an API to the web application platform the present invention has access to all transmissions utilizing the web application platform and can provide security at an intermediate point.

The embodiment of FIG. 13, with reference to FIG. 14, specifically details the present invention's application to an outbound transmission. A user 906 may request document 804 from a document database 910, which may or may not bear a cryptographic token 208. The system 200 utilizing the process 100 of the present invention, applies a cryptographic token to a token-less document, or in the case of a document bearing a pre-existing token, updates the token. Thus the document 804 includes a secured token 804 that is added or updated via a token generator, or via other means known in the art, at the web application platform level in delivery to the user 906. The API communicates with the record database 912 to log the updated records related to the document 804 and the user 906 requesting the document. Furthermore, the API may utilize the record database 912 to fashion the authenticity attributes of the token as inserted into the document, and similarly, the token generator may rely on information form the web application platform, particularly from the logging function, as authenticity attributes and identity attributes for the token 208.

As is shown in FIGS. 15 and 16, the present invention similarly works in reverse. The API, operating the system 200 of the present invention, may apply security tokens 208 to digital files 804 in incoming transmissions. Because the API reviews the digital file and controls application and modification of tokens, the user 906 need not have a distinct version of the system or process of the present invention on a non-ecosystem device. The digital file 804 in transit into the private ecosystem, upon crossing the ecosystem boundary 710, is scanned for potential application of a token. The present invention may insert or update a token with the digital file and record the token attributes in the local record database 912.

With reference to FIGS. 5 and 6, in transmission scouring 228 the present invention may utilize a secured gate 240 to review incoming and outgoing transmissions into/from a local area network or other discrete set of one or more electronic devices 906 capable of generating digital files. The secured gate 240 acts in conjunction with the network server 242 to review each digital file passing by the gate to devices 906 connected to the network 242. The secured gate 240 checks each file passing into the network, say for example from the Internet 910, for the presence of the cryptographic token. It is preferred that the secured gate 240 merely seeks the presence of the identity marker. Upon locating a digital file with a identity marker, or conversely a file lacking a identity marker, the present invention may indicate the existence of the digital file in the digital file database. The secured gate may further check each file passing from the network, say for example to the Internet 910, including such popular external network storage sites as DROPBOX, for the presence of the cryptographic token. It is preferred that the secured gate 240 merely seeks the presence of the identity marker. Upon locating a digital file with a identity marker, or conversely a file lacking a identity marker, the present invention may indicate the existence of the digital file in the digital file database. Furthermore, the present invention may perform a secondary operation dedicated to allowing/denying permission for the egress of the digital file.

Turning now to FIGS. 4 and 7, the process of the present invention may further retrieve 112 the authenticity data as plain text from the cryptographic token via the data retriever 250. The data retriever 250 may access the database of marked digital files, and upon entry of a secured key code, the key 252 of the user may be used to decrypt the authenticity data within the cryptographic token into the authenticity attributes 218 as plain text.

The system 200 of FIG. 8 depicts a preferred scouring mechanism pursuant to the process 100 of FIGS. 1 and 9-10. There is at least one electronic device 906 connected to a network 242. The electronic device 906 may include software 914 operating the process 100, or portions thereof, of the present invention. The software 906 communicates directly with locally stored documents 910, via a network 242 with network stored documents 916, and with a local record database 912. Locally stored documents may include the documents on the processing system where the software 914 is operating. The local record database 912 stores copies of the document identity markers of interest to the user of the system 200. Identity markers may be of interest to a user for various reasons; the identity markers may relate to the user, the identity marker may relate to specific files that relate to the user, the user may be tasked with monitoring files bearing the identity markers, etc. The local database may also store the locally stored document names and/or a full or partial copy of the identity marked documents. The local database may also be configured to store and then forward files and records to the network database.

A preferred scouring process 100 includes a file retriever 930 that acts to input files into the software from a source of suspect documents 902. By source or set of suspect documents, it is meant that there is pool from which suspect documents may be found rather than implying foreknowledge of the existence of documents bearing identity markers. The file retriever may vary in complexity and instructions. The file retriever 930 may seek files from an external source or internal source and may do so passively or dynamically. By passively it is meant that the file retriever is placed in the stream of file transmissions and the file retriever accesses only those files within that stream. By dynamically it is meant that the file retriever is provided instructions to seek files to input them into the process 100. The file retriever 930 passes retrieved files to a file analyzer 932. The file analyzer 932 examines the files for applicability as markup language files according to the present invention. By markup language files, it is meant that the file is one that includes renderable data and portable instructions for rendering the data that are themselves not subject to rendering. The portable instructions are created from text characters, which define namespaces attributing significance to other strings of text characters, whereby such significance constitutes any number of intrinsic operations. The present invention may include as a default to accept all files that are markup language files, or specified markup files. The file analyzer 932 may filter files input into the process as desired by a user. If the file analyzer identifies the file as one accepted by the process, it passes the file to a file analyzer 934; or if the file is not accepted into the process, then the process may terminate or reset.

The fingerprint analyzer 934 reviews the input files for indications of an identity marker. The fingerprint analyzer 934 may be instructed to analyze the entirety of a file or specific portions of the file. It may be advantageous to instruct the fingerprint analyzer to review only specific portions of a file when files of interest include cryptographic tokens primarily embedded in high-level syntax signifying general document objects (e.g., type and title); whereas it may be advantageous to instruct the fingerprint analyzer to review the entirety, or large portions thereof, of a file when files of interest include cryptographic tokens embedded in low-level syntax signifying specific, numerous document objects (e.g., paragraphs, fonts, etc.). If the fingerprint analyzer 934 determines the existence of an identity marker, then the file is passed to decryption function 936; otherwise the file lacking an identity marker may pass to a fingerprint insertion function 224.

The fingerprint update function 224 inserts a cryptographic token into the file lacking a cryptographic token. The cryptographic token may include the identity marker and the authenticity data as the authenticity attributes. After insertion of the cryptographic token into the file, a database updater 940 routes the file, portions of the file, indications of the identity marker, or other file attribute capable of identifying the file or its content in the future to the record database 912.

If the fingerprint analyzer 934 determines the existence of an identity marker, then the file is passed to decryption function 936. The decryption function 936 decrypts the file by communicating with the password database. The password database 942, which may be a portion of the record database 912 or a distinct entity therefrom, provides the key for decrypting the authenticity data within the token. A record retrieval function 944 then attempts to find a record of the file from the record database 912.

If a record of the file is located from the record database 912, then a record comparison function 948 compares the file received from the file retriever 930 to the attributes of the version of the file or file portions within the record database 912. The record comparison 948 may reveal many aspects of the file, including dates of changes, the substance of changes, entities that have accessed the document/file, time spent reviewing the document, or any other information that may be obtained, tracked, or recorded in connection with a file. The file is then passed to the database updater 940 which then sends the file to the fingerprint updater 224. The fingerprint updater 224, in addition to the earlier discussed activity of inserting an identity marker into a file that previously lacked an identity marker, may alter or replace a pre-existing identity marker. The file, or other indication of the file, e.g., the identity marker, is then passed to the record database 912.

If no record of the file had been found in the local record database 912 during the record retrieval 944 step of the process 100, then the process may proceed to a network record comparison 946. The process 100 of FIG. 9 is continued in FIG. 10. The network record comparison may collect network records from the network record database 950. If the file or a previous version thereof is found in the network record database, the cache, the client code database being used to store the object records for the local documents, is updated 952 and the file is sent to the record comparison 948 for passage to the fingerprint updater 224 and database updater 940. If the file or a previous version thereof is not found in the network record database, the file is passed directly to the fingerprint updater 224. The fingerprint updater 224 may alter or replace the pre-existing identity marker. The file, or other indication of the file, e.g., the identity marker, is then flagged and then passed to the record database 912. The flagging indicates that the file has not been identified or never before fingerprinted/tokenized. Flagging allows the present invention to create a token/fingerprint in the flagged file. The flagging may be a distinct step of the process or subcomponent of the system, or subsumed into another step of the process or subcomponent of the system.

Turning now to FIG. 11, in view of FIGS. 3 and 9-11, the present invention also includes a process 800 for providing an alert based on information within a token 208 with the option of taking some further action based on the alert. The token 208 may include within its contents authenticity attributes 218 that define the identity of the draftsman of an editable document—by name, computer, or the like. A software product 914 that interacts with the present invention may access 302 from a document database, whether a local document database or network document database, an editable document 804 via a file retriever 930. The file analyzer 932 reviews the editable document 804 for applicability with the processes of the present invention. The fingerprint analyzer 934 detects the presence of a token 934, which may then be decrypted 936, to determine the authenticity attributes, including identity data. If the present invention detects the presence of identity data that conflicts with, or differs from, the identity of the user or computer system upon which the editable file has been accessed, then an alert may be sent by the alarm 802. The basis of the alert may be the existence of instructions within the software product 914, or the basis of the alert may be the existence of token component, e.g., authenticity attributes 218, bearing alert instructions as to the authorizations that permit further editing of, or actions relating to, the file. The authorizations my include edits by particular people, groups, systems, or any other entity or division desired.

It is preferred that the existence of an applicable token, for example a token bearing authenticity data having an alert instruction or alert transmission instruction, triggers the alarm to notify a monitor program 806. The monitor program 806 accesses the record database to ascertain data related to the token related to the digital file processed by the software product 914. Two preferred versions of the present invention utilize durable token alert restriction instructions and token alert transmission instructions. In the former version, the token includes instructions that travel with the token for file action restrictions and the token need not correspond with an outside source to instruct the software product directly to restrict file actions. In the latter version, the token includes instructions to correspond with the monitor program for further guidance on file action restriction by which the monitor program instructs the software product directly to restrict file actions. The present invention may further utilize a combination of the two versions, and the significance of the record database may vary from the generally passive role of record keeping related to the uses of the marked digital file to the more active role of providing the action authorizations. The alarm 802 transmits 306 the existence of the token to the monitor program 806. The monitor program 806 may not act, simply store the instance of file action in as great of detail as may be desired in the record database, or transmit 306 return authorizations for actions.

The alarm 802 may provide multiple actions. By edits/actions it is meant that the file may be locked, or the process otherwise sends a notification, for instructions related to review, modification, distribution, adaptation, display, access, or other action. The alarm 802 may perform actions on the local computer system upon which the software product 914 providing the edits is being accessed. It is further preferred that the alarm 802 send an alert of the access to the editable document over the network 242. Further instructions may arrive from over the network and the access, which was the subject of the alert, may be logged in a database, network or local. A preferred instruction prevents further actions by a realtime user of an editable document 804 of the present invention that differs from the documents creator. Although the instructions have been discussed in reference to identity authenticity data, instructions may be provided on the basis of any conflict, contrast, or like test with any variety of authenticity data of the token.

Although editable documents may be closed for further editing by the program that has created the particular editable document file, the present invention may be utilized as a global edit-lock solution. That is to say, the present invention may, so long as it interacts with software that edits a document, may provide edit locks for that software that replace or supplement that software's native edit lock functions. When applied to multiple software products that edit documents, the present invention further provides a uniform solution to edit locks and alerts throughout a system.

Although the present invention has been described in considerable detail with reference to certain preferred versions thereof, other versions would be readily apparent to those of ordinary skill in the art. Therefore, the spirit and scope of the appended claims should not be limited to the description of the preferred versions contained herein.

Claims

1. A digital data security system for controlling inbound Internet communications, said system comprising;

a web application platform, on a non-transitory readable storage medium, for controlling Internet traffic to and from a private ecosystem, said private ecosystem having a secured digital file repository and an active directory establishing access credentials; and

an application programming interface (“API”) electronically accessing said a web application platform, said API adapted to: monitor said Internet traffic at said web application platform for communications bearing an inbound digital file comprising markup language tags constructed according to a markup language document object model (“DOM”); insert a textual cryptographic token, inertly embedded within at least one markup language tag of said digital file, with encrypted authenticity data; and record authenticity attributes of said digital file in a local record database.

2. The system of claim 1 wherein said web application platform controls Internet traffic at an ecosystem boundary.

3. The system of claim 2 wherein said API is further adapted to monitor said Internet traffic for a pre-existing textual cryptographic token, inertly embedded within at least one markup language tag of said digital file, with encrypted authenticity data; and said API is adapted to insert an updated textual cryptographic token, inertly embedded within at least one markup language tag of said digital file, with encrypted authenticity data; and record authenticity attributes of said digital file in said local record database.

4. The system of claim 3 wherein said API generates authenticity data from a logging function of said web application platform.

5. The system of claim 4 wherein said web application platform includes an API accessible logging function.

6. The system of claim 1 wherein said inbound digital file lacks a pre-existing textual cryptographic token, inertly embedded within at least one markup language tag of said digital file, with encrypted authenticity data.

7. A digital data security system for controlling outbound Internet communications, said system comprising;

a web application platform, on a non-transitory readable storage medium, for controlling Internet traffic to and from a private ecosystem, said private ecosystem having a secured digital file repository and an active directory establishing access credentials; and

an application programming interface (“API”) electronically accessing said a web application platform, said API adapted to: monitor said Internet traffic at said web application platform for communications bearing an outbound digital file comprising markup language tags constructed according to a markup language document object model (“DOM”); insert a textual cryptographic token, inertly embedded within at least one markup language tag of said digital file, with encrypted authenticity data; and record authenticity attributes of said digital file in a local record database.

8. The system of claim 7 wherein said web application platform controls Internet traffic at an ecosystem boundary.

9. The system of claim 8 wherein said API is further adapted to monitor said Internet traffic for a pre-existing textual cryptographic token, inertly embedded within at least one markup language tag of said digital file, with encrypted authenticity data; and said API is adapted to insert an updated textual cryptographic token, inertly embedded within at least one markup language tag of said digital file, with encrypted authenticity data; and record authenticity attributes of said digital file in said local record database.

10. The system of claim 9 wherein said API generates authenticity data from a logging function of said web application platform.

11. The system of claim 10 wherein said web application platform includes an API accessible logging function.

12. The system of claim 7 wherein said outbound digital file lacks a pre-existing textual cryptographic token, inertly embedded within at least one markup language tag of said digital file, with encrypted authenticity data.

13. A digital data security system for controlling inbound Internet communications, said system comprising;

a web application platform, on a non-transitory readable storage medium, with an application programming interface accessible logging function, adapted to control Internet traffic to and from a private ecosystem at an ecosystem boundary, said private ecosystem having a secured digital file repository and an active directory establishing access credentials; and

an application programming interface (“API”) electronically accessing said a web application platform, said API adapted to: monitor said Internet traffic at said web application platform for communications bearing a digital file; insert a textual cryptographic token within said digital file bearing authenticity attributes; and said record authenticity attributes of said digital file in a local record database.

14. The system of claim 13 wherein said authenticity attributes are derived from said logging function.