Cross-Refereaee to Related Applications fOMl ) The present application claims the benefit of US Provisional Patent

Application Serial umber 61 /898,440, tiled October 31, 2013, and US Provisional Patent Application Serial Number 6.1/808,446, filed October 3.1 , 013, the contents of each of which are hereby incorporated by reference in their entireties as if set forth herein.

FIELD

[0002] The present application relates, generally, to networks and, more particularly, to secured content distribution,

BACKGROUND

J0003J in the past, distribution of commercial mail lias depended on a large and complex process centered around the movement of paper. Paper, needed to be delivered to the mad provider as raw material in the printing of documents. Paper also needed to be moved .from, the point of printing to the United States Postal. Service (USPS) and within the USPS to a recipient destination. Even after delivery to the recipient, paper .must be managed in order to reach the intended recipient or otherwise undergo an organization's processing requirements before ultimately being forwarded to long-term storage or disposal. These processes were necessary and reasonably efficient in a world where digital communication did not exist; howe ver, the point of the process was never to move paper, but rather to mo ve data, in today's electronic world it is entirely possible to reengineer the process to eliminate paper and remove the steps and costs associated with movement of physical mail, (0604) The advent of email allows data to be quickly moved from one point to another without the need for paper or all of the requisite steps and costs of moving paper. The volume of email transacted daily has grown to quantities that are difficult to imagine.

5 Nevertheless, current implementations of email do not adequately meet many of the

requirements of commercial mail from either a provider or recipient standpoint. Email addresses may be transient and it is difficult to determine if any given address is either current or valid. Content within the body of an email is often unstructured and largely inconsistent. Email is relatively {insecure and can be intercepted more readily than physical mail as the later requires both the mail and the interceptor to be in the same place at the same time. Moreover, verification of normal email delivery is uncertain. Another complexity in traditional email management, concerns the manner of organizing emails. Organization of email is at the discretion of the recipient, and management and processing of email messages are subject to the diligence of the user. Finally, if not appropriately backed up, email can be lost and irretrievable. As a direct result of these .limitations, commercial providers have shied away from email as the primary form for distributing electronic versions of commercial mail.

[0005] Yet some commercial providers have begun utilizing " aper-ess alternatives.

This method eliminates the paper and the components of the legacy process that relate to moving physical paper. Unfortunately, however, the paperless alternatives available so far have been less desirable than paper-based delivery methods because they lack the passive receipt and aggregation components of both physical mail and email The predominant, paperles alternatives available today require a recipien to "follow a link," sign-on to a provider website, and then open the required document. This approach prevents interception of personal or sensitive information. However, if the recipient fails to retrieve a document, he or she might miss a deadline. This is attendant with potential financial repercussions _* legal implications, or both. As well, this process place additional time burdens on the recipient and can become particularly onerous if the recipient has to follow links to review materials relating to multiple commercial relationships. [0006] Known systems are inherently different than other paperless systems in that they are focused on a singular type of document Can invoice) and tailored to process that one type of document EBPP systems are directed to electronic payment and do not address nonpayment related mail or many of the myriad, consumer problems associated with document distribution, _, retention, and management. [0087] Historically, replacements to physical mail distribution systems have been driven by providers who are motivated to lower the substantial costs associated with physical document distribution. Because the focus has been on the provider's cost, the complex requirements necessary to motivate- recipients to convert away from physical document, distribution have not been met. However, the current, invention provides a system and method that, among other things, addresses the needs of recipients" while also lowering die costs associated with physical document distribution. Alternatively or in addition, the current invention provides a system and method that, among other things, addresses the needs of providers (e.g., document distributors) by providing audit trails of proof of delivery.

Alternatively or in addition, the current invention provides a system and method, that, among other things, enables providers and subscribers to accept communications from one another through a secure portal that, on the one hand, ensures that the content of such

communications are shielded from viewing by any intermediary -including the secure portal, and on the other hand ensures that recipients receive only authorized messages and that they can manage and direct such messages in a pri ate manner that is not exposed to the provider. The current invention can provide these solutions and solutions to other problems in the art as will be appreciated from the discussion below.

[0008] The present application addresses these and other considerations.

SUMMARY

[0099] In one or more implementations, a method and/or apparatus is provided for providing a content delivery platform for delivery of content to a consumer. A first content package is generated that includes content that is encrypted with a unique symmetric key, and a second content package is generated that includes a link to the first content package. The link is also encrypted with, the unique symmetric key. The first content package is stored in a repository, and a request that includes the unique symmetric key is transmitted to a first computing device associated with a mail exchange for an encryption key file. An encryption key file is generated using the unique symmetric key rid together with a token providing authorisation for the content, to be delivered to the consumer is received and a third content package is generated that is encrypted using the encryption key file and that includes the encrypted link. The third content package is transmitted to a distributor gateway and the encrypted link is accessible in response to the consumer decrypting the third content package, and the link is available to provide to access to the content for the consumer. [0010] These and other aspects, features, and advantages can be appreciated from ie accompanying description of certain embodiments of the invention and the accompanying drawing figures and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[(Mil l] Fig, 1 is a high-level, diagram illustrating an exemplary configuration of a code processing system in accordance with one or more implementations of the present application;

[0012] Fig. 2 illustrates a high level implementation, of the present application and includes components illustrated in Fig, 1 ;

[00133 Fig. 3 illustrates an exampl implementation and flowchart illustrating an example process-steps associated with the present application and is accordance with content. gene.riit.ion and transmission;

[0014] Fig. 4 is a block diagram that illustrates an example high level architecture of a producer gateway:

[00153 Fig. 5 illustrates an example implementation and flowchart illustrating an example process steps associated with the present application and in accordance with communication between producer gateway and mail exchange.;

[0016] Fig. 6 illustrates an example implementation, and flowchart illustrating an example process steps associated with the present application and in accordance with generation and distribution of asymmetrically encrypted symmetric key(s).;

[0017] Fig. 7 illustrates an alternative example implementation and flowchart illustrating an example process steps associated with the present application and in accordance with, generation and distribution of asymmetrically encrypted symmetric ke (s); [00.18] Figs. 8A-8C illustrate an example implementation of the present application that includes XENOS integration with a producer -gateway;

[00:19] Fig. 9 shows -an example configuration and corresponding process steps representing integration of features of the present, application with mail-room digitization; [0020] Fig, 10 shows an example configuration and corresponding process steps representing integration of the present application with ad-hoe dispatch;

[ _. 0021] Figs. 1 1A atid 1 IB illustrate example display screens respectively associated with an example web site interface; [0022] Fig, 12 is a block diagram that illustrates an example high level architecture of a mail exchange;

[0023] Fig. 13 is a block diagram that illustrates an example architecture and process steps associated with a private key service in connection with a mail exchange;

[0024] Fig, 14 is a block diagram that illustrates an example architecture and process ste s; associated with control and data security.

[0025] Fig, 15 is a block diagram that illustrates an example high level architecture of a distributor gateway, in accordance with an example implementation of the present application

[0026] Fig. 16 is a block diagram that showing components associ ted with a consumer interface with a distributor gateway; and

[0027] Fig. 17 is a block diagram that illustrates an example architecture and process steps associated with content storage and decryption, in accordance with an example implementation of the present application.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS OF THE INVENTION

[0028] By way of overvie w and introduction, various implementations of the present application provide for a s stem and method for secure content production and distribution within and between one or more networks, including local intranets and large data, communication networks, such as the Internet. In one or more implementations, distribution of electronic content, such as documents, is provided in & structured and secured

environment, and is usable to replace or otherwise augment existing physical mail and electronic mail (e.g., "e-mail") distribution systems. In addition to providing for messages being transferred between respective parties, the present application provides a suite of services in support of users, including with regard to production and distribution.

[0029] Referring now to the figures, Fig. 1 is a block, diagram, illustrating a simplified view in accordance with, an example implementation of the present application. One or more producer gateways (PG) 102 can be configured as a set of components (including, but not limited to lava services, message oriented middleware, Seeur FTP, caches, PERL scripts, FTP servers, databases, and web interfaces) ihat are depioyed in an intranet and a producer gateway demilitarized zone 104 (or perimeter network, as known in the art) associate with the producer gateway 102. Content is passed to and from the producer gateway 102 to a mail exchange 106, which can be located or otherwise be associated with a mail exchange demilitarized zone 108. Content, is further passed to and from the mail exchange .1 6 to and from a distributor gateway I JO, including via the distributor gateway demilitarized zone 111, which sends and receives content to and from consumers 112 (including via the consumer's demilitarized zone i .14).

[0030.1 Fig. 2 illustrates a high level implementation of the present application and includes components illustrated in Fig. .1. Certain of the components of the present

application illustrated in the drawings can take on multiple roles and operate differently in particular contexts.. For example, a producer of content can also be- a distributor of content by hosting one or more distributor gateways (distributor gateway 1 1 ). in such ease, the producer can store encrypted content in. a local repository, and send an encrypted Sink file (e.g., providing delivery instructions) to the mail exchange 1 10,

[0031] In accordance with the high-level implementation of the present application shown in Fig, 2, producers of content register content, such as documents, to send to consumers using a web based administration interface that can be provided by the producer gateway 102. The content is packaged, for example, by the producer gateway 102 and sent to and received by the mail exchange 1 6, The mail exchange 106 is configured to receive and route the content to the distributor gateway 1 10, which operates to deliver the content to the consumers,

[0032] In one or more implementations, a producer can host multiple producer gateways 102. For example, a bank implements separate gateways 102 for its mortgage division and its credit card division, respectively. Multiple gateways 102 provided by or within a single producer have a benefit of being able to share infrastructore, for example, depending on content transmission volume. Ptu hecraore, the prodttcer gateway 102 can transmit encrypted and unencrypted content to the consumer. In an. implemen ation, the producer controls which document is sent in the clear (i.e.. unencrypted) and which document is sent in an encrypted form, by marking the appropriate document level, configuration settings in a web site interface provided by the producer gateway 102. As noted herein, the mail exchange 106 can receive content from the producer gateway 102, and deliver the content to the consumers i 1.2 through the distributor gateway ! .10. Furthermore, the mail exchange 106 can be configured to be a master record holder, .including with regard to interactions between the producers, distributors, and consumers.

[fMl33] Continuing with reference to Fig. 2, a consumer device registers with the mail exchange 106 via a new consumer registration process, that can be- hosted by the mail exchange 106. In one or mora implementations, information submitted by the new consumer is verified, for example, b identity verification service 202 provided by EXPE .I.A.N.

Thereafter, the registration process completes by the mail exchange 106, which assigns the consumer a universally uniqu identifier ("UUl ^' D"), and a public/private key pair for encrypting decrypting content, in. one or more i mple sntati-ons, the mail exchange i 06 hosts an isolated private key infrastructure to provide the consumers with private keys to decipher encrypted content sent by the producer. The mail exchange 06 can also host or otherwise interact with a payment gateway that enables consumers to make payments through a number of payment networks. Consumers can send payment instructions via the distributor gateway 1.10 to the mail exchange 306. Further, the mail exchange 106 can provides data transmission application services deployed on dedicated one or more virtual local area networks for each respective producer to ensure data transmission security and isolation., The mail exchange 106 symmetrically encrypts and then stores all consumer, producer, and distributor information in one or more- databases storing various control data.

[0034] Continuing with reference to Fig. 2, the distributor gateway 1 1 can he configured as a set of components similar to the components described above in connection with the producer gateway .102. Further, the distributor gateway 1 10 can be deployed in the- demilitarized zone and an intra-.net of a respective content distributor. In one or more implementations, the distributor gateway 1 10 receives content from the mail exchange. 106, and delivers the content before passing back one or more delivery state messages to the mail exchange ί 06. 00351 In one or more implementations, there are two types of distributor gateways

1 10- One is an enterprise- distributor gateway, which is meant for distribution of enterprise content (such as W2s _> code of conduct, digitized mail from mail room, 8-2-B digital content}. The enterprise distributor gateway 110 is useful for internal employees of a producer, and can support key features such, as content forwarding with audit trail and audit and compliance access to encrypted content. The second type of distributed gateway i 10 is a commercial distributor gateway 1 J 0, which is meant to distribute content to customers of an enterprise. In this implementation, a customer, for example, who is registered as a consumer with the mail exchange 106, sends and receives via one respective distributor gateway 1 0 at a time. In an example implementation, consumers (e.g.. employees of a producer) receive content by logging into an on-line user interface, such as a mobile application or web-based interface, and authenticates with the distributor gateway 1 10. Preferably, content that is stored in at the distributor gateway 1 10 is encrypted, and is decrypted at the consumer device/website during run-time. Once the content is delivered and received, the distributor gateway 1 10 transmits various forms of information, such as one or more content receipt and delivery confirmation messages and action logs to the producer through the mail exchange 106.

[0036] Fig. 3 illustrates an example implementation and flowchart illustrating an example process steps associated with the present application and in accordance with content generation and transmission. Several of the logical operations described herein can be implemented ( ! ) as a sequence of computer implemented acts or running program modules and/or (2) as interconnected machine logic circuits or circuit modules. The implementation is a matter of choice dependent on the requirement of the device (e.g., size, energy, consumption, performance, etc.), Accordingly, the logical operations described, herein are referred to variously as operations, steps, structural devices, acts, or modules. Moreover, one or more of thes operations, steps, structural devices, acts and modules can be implemented in software, in firmware, in special purpose digital logic, and any combination thereo Furthermore, more or fewer operations can be performed than shown i n. the figures and described herein. These operations can als be performed in. a different order than those described herein.

S [0037] In the example implementatioa shown in Fig. 3, producer intranet 302 is shown that includes three different sources of content and corresponding processes for generation thereof; first class (e.g., content originating from received or sent first class mail), digital content (e.g., content generated in a digital context, such as within a computing device), and enterprise content (e.g. , content generated at the enterprise level) (step I ). The digital content can he encrypted in a content package, such as using a symmetric key, and each key can be unique to each respective piece of content for each transmission (step 2). At ste 3, a selection is made for the format of the content to be transmitted to one or more consumers, in one or more implementations, the options include sending encrypted content, unencrypted content, and/or link (e.g., a hyperlink) to encrypted content.

[0038] Continuing with reference to the example implementation shown in Fig. 3, at step 4 an asymmetrically encrypted symmetric key ("AESK") is created at the mail exchange .106 along with transmission tokens. The asymmetrically encrypted symmetric key can he- created using the public key of the recipient consumer. At step 5, conten assembl and dispatch occurs for the package, and a custom file containing, for example, the encrypted content or an encrypted link to the actual content at the producer and unencrypted public meta-data in clear text. At. step 6, one or more copies of the package are delivered to one or more respective consumers at one or more respective distributors via a content .router at the mail exchange 106. At step 7, the content delivery and distribution process associated with the distributor gateway 1 10 functions to deliver the content to the correct recipient(s).

[0039] Fig. 4 is a block diagram that illustrates an example high level architecture- of the producer gateway 1.02, in accordance with an example implementation of the present application. In one or more implementations, a producer server farm 402 is implemented thai includes the producer gateway 102 includes one or more core application services that can be written, for example, in JAV A utilizing the Spring (e.g., version 3,0) framework. These components can communicate with IBM's Websphere Q Middleware, for example, using .IMS-XML Messaging, in one or more implementations, SecnreFT ^' P is implemented to transfer files securely to and. from the mail exchange 106. In one or more- implementations, a relational database management system, such as MySQL, is used to store data, and high- speed data access i provided, for example, via Memcaehed Cluster. Depending upon one or more producer preferences, components associated with the producer gateway 102 can be deployed on physical and/or vi tual servers, such as within an isolated subnet. [0040] Continuing with reference to Fig. 4, two web-based interfaces can be used for operators and/or administrators. For example, producer initiated transmissions and producer gateway administration web sites can be provided and made available for respective users. Preferably, both producer initiated transmission and producer gateway administration web sites prevent cross site scripting, and secure communication, is supported, such as over an. HTTPS connection. Particular user authentication and single sign on is integrated with one or more of the producer's preferred amhentieatioo mechanisms, in one or more

implementations, the producer initiated transmissions web sites are applicable for a particular user role: "Administrator. ^* ' The producer gateway administration web sites are applicable for two roles: "Administrator", and "Read Only". Preferably, users accessing these two web interfaces are aliased into one of these roles, Furthermore, the producer initiated

transmissions web ites can enable designated operators to send, content to consumers o an ad hoc basis. In such case, document ^' s) that are included in these transmissions are encrypted with a unique symmetric key, for example, that is generated using JAVA'S Crypto Library and using the asymmetrically encrypted symmetric key 256 bit algorithm.

Preferably, symmetric keys are never reused.

[00411 Continuing with reference to the high-level architecture implementation. associated with a producer gatewa 102 in Fig. 4, one or more producer gateway

administration websites enable a designated producer gateway administrator to perform various functions, such as to monitor transmissions, monitor producer gateway 102 components, ran reports and extract, and manage various producer gateway 1.02

configurations.

[0042] As can be appreciated and described herein, the producer gateway 102 is capable of transmitting encrypted and on-encrypted content to a consumer 112. In addition, the producer gateway i 02 can be configured to send, linked content to a consumer 1. 12.

Selections of one or more of these configurations can be set at individual document level in the producer gateway administration web site. In one or more implementations, the process of sending Jinked content allows the producer to maintain the encrypted content package in a secured repository 404 within the producer's domain, la soch cases, the producer gateway .102 symmetrically encrypts the link to the encrypted content package, and sends that link for delivery to the mail exchange 106. The .symmetric key used to encrypt the link can be the same key used to encrypt the corresponding encrypted content package. Extract, transform. and load processes, such as via PERL, ca operate to extract data into a reporting database and. deliver reports in extracts, such as in one or more c mma separate values ("CSV") and ADOBE PDF files, to secure destination directories and reporting systems outside of the subnet of the producer gateway 102.

[0843] For example, a producer hosts an enterprise distributor gateway, and the producer gateway 102 creates two content packages. A first content, package contains the (actual) encrypted content, and a second content package is an encrypted link to the actual encrypted content package. The first encrypted content package is loaded into the producer's secure repository 404 such as via secureFTP, from the producer gateway 102, and the second content package {containing the Sink) is sent via the mail exchange 106 to the enterprise's distributor gateway i 10. In this way, the first encrypted content package in maintained securely in a fepos.Uo.ry 404 of producer gateway 102.

[0044] Fig, 5 illustrates an example implementation and flowchart illustrating an example process steps associated with, the present application and in accordance with communication between producer gateway 102 and road exchange 106. in the example implementation shown in Fig. 5. transmissions occur over a. command ( ^' e.g.. Websphere MQ) channel and a data file channels (e.g., secure FTP). In an implementation of the present application, all communication occurring between the mail, exchange i 06 and the producer gateway 102 occurs over these two channels. For communication between the producer gateway 102 and mail, exchange 106, both of these communication channels are bidirectional,

[0845] In an example operation, a file mover component 502 operates to push a content file into a storage area network ("SAN" _. ) file system 504 associated with or in the producer gateway demilitarized zone 104, for example, via SecureFTP (step I ), The file mover component 502 sends a message, for example, via SecareMQ, to a file retriever component in. the destination network. The message contains the file name and location in the sender's DMZ, The File Retreiver component in the destination network will pull the file across over a secure FTP connection and store the file in a SAN file system 506 associated with the exchange mail demilitarized zone 108 (step 2). At step 3, an internet pass-through component, suc the Websphere MQ IPT, is deployed in the producer gateway demilitarized zone 1.04 to pass the incoming SecureMQ message!*) into a queue manager 508 in the respecti ve destination network. The queue manager 508 then places the messageis) on to one

1 ! f more appropriate internal application queues. Thus as shown and described with reference to the example implementation in Fig. 5, secured messaging and data file transmission occur between producer gateway 1 2 and mail exchange 106 as function of the command and data file channels, respectively. [0046] Fig. 6 illustrates an example implementation and flowchart illustrating an example process steps associated with the present application and in accordance with generation and distribution of asymmetrically encrypted symmetric key(s). At step 1 , a producer initiates a content transmissio process, which can use, for example, any of three different mechanisms: a commercial mail generator; an enterprise mail dispatch; and digitized incoming mail. These respective dispatch mechanisms can be configured to create one or more of symme rically encrypted content files, a batch initiation detail file, and a XML command message that is placed on a content dispatch command queu to initiate content transmission. An asymmetrically encrypted symmetric key request generator process (ARGP) receives a message from the content, dispatch command queue. In one or more implementations, die message contains the location of the encrypted content files, and the location of a dispatch summary file (step lb), tOM7] Continuing with reference to the example process steps shown in Fig, 6, .for each record included in the dispatch summary file, the asymmetrically encrypted symmetric key request, generator process (ARGP) retrieves a respective subscription identifier from a data store associated with the producer gateway .102, Moreover the asymmetrically

encrypted symmetric k request generator process (ARGP) can operate to create a unique tracking identifier for each record. The subscri tion identifie , traekiag identifi r and the unique symmetric key used to encrypt the content package are added on to an asymmetrically encrypted symmetric key request file. Once the entire file is built, the ARGP transmits a message to a file mover component (e.g., 502) to move the file into the producer gateway demilitarized zone 1 4 (step 2). At ste 3, the file mover component moves the

asymmetrically encrypted symmetric key request, file into the producer gateway demilitarized zone 104, and transmits a dispatch command message on the message dispatcher's queue (step 3fe). Thereafter, the message dispatcher places a message n a secure queue (e.g., a Websphere MQ queue) of the mail exchange 106 with the asymmetrically encrypted symmetric key file location (step 4). [00481 Continuing with reference to the example process steps shown in Fig. 6. at step 5 an asymmetrically encrypted symmetric key request file retrieves: component recei es the message sent by the producer gatew y 102, and accesse the file from the producer gateway demilitarized zone 104 into a domain of the mall exchange 106. The AESK request file retriever component further places a message on the .AESK file generator's queue to process the asymmetrically encrypted symmetric key request file and to generate an

asymmetrically encrypted symmetri key Pile. At step 6, an AESK file generator CAPO) component creates an asymmetrically encrypted symmetric key file that includes, for example, the tracking identifier, the transmission identifier, and an. AES package) for each record on the asymmetrically encrypted symmetric key request file. In one or more implementations, the transmission identifier is formatted as a 36 character universally unique identifier ("UU1D") that, is generated by the AESK file generator process. Th UIJiD operates as a token that provides authorization for the producer to send a single piece of content to the consumer. The AESK file generator process then places a message on a file mover queue in the mail exchange 1.06 for moving the asymmetrically encrypted symmetric key file to the mail exchange demilitarized .zone 108 (step 6b). At step 7. a file mover component associated with the mail exchange 106 moves the asymmetrically encrypted symmetric key file to the mail exchange demilitarized zone 108 thai is "facing" (he producer gateway 102, and a message is sent to a message dispatcher component to send a file retrieval message to the producer gateway 102 (step 7b).

[0049] Continuing with reference to the example process steps shown in Fig. <S, at step 8, the message dispatcher component at the mail exchange 106 sends a secure message, such as via WebSphere MQ, to the AESK file retriever component to get the asymmetricall encrypted symmetric key file from the mail exchange- demilitarized zone 108. At step 9, the AESK file retriever component obtains the file from the mail exchange demilitarized zone

.108 and places (he file to the domain associated, with the producer gateway 102, and transmits a message on a content package command queue (step 9b). At step 10, a content packaging component within the producer gateway 102 reads the asymmetrically encrypted symmetric key file, the encrypted content files, and configurations, and creates a mail exchange content package, In the even that the producer configuration is set. to sending a. link, then the content packaging process stores the content package in the producer's secure document, repository 504 (Fig. 5), and the content packaging process encrypts the link to the respective content using the same -symmetric key used to encrypt the actual content package. The content packaging process then, compacts or compresses ail mail exchange content, tiles (or linked content files ^' ), for example, into a TAR file, and transmits commands to th file mover component to start the dispatch process to mail exchange 106,

[0050 j Fig. 6 illustrates an alternative implementation and. flowchart illustrating an example process steps associated with the present application and in accordance with content delivery to one or more consumers t m one or more producers. In the alternati e implementation shown, in Fig, ?, a producer does not send an encrypted content ilk; to a distributor, and instead creates the content package and stores the actual content package file ("CFF") in the producer's own domain. Also as set forth in Fig. ?, producers create a corresponding encrypted link file to the actual content tile,

[0051] In accordance with the process steps set forth in Fig. 7, the producer stores the content file package and encrypts the file package with a symmetric key. The producer uses the same symmetric key that, was used to encrypt the corresponding content package to encrypt a file containing a link. The encrypted link file is transmitted sent to the consumer via the mail exchange 106. These procedural steps ensure an additional layer of con tent security, and prohibit, a distributor from scantling or otherwise reading any information of the actual content package. Moreover, this also provides functionality associated with distributing enterprise content to the employees of a producer.

[0052] In accordance with the implementation shown in Fig. 7, the producer can. send any document via a link by Implementing this configuration in the producer gateway website for a particular document. Moreover, the present application provides flexibility to enable the configuration to be changed any time, for example, for subsequent mail streams created by the producer in the future. In one or more implementations, once a configuration is set, it applies to all recipients of the document.

[0053] As can he appreciated, with regard to the security associated with the teachings herein, there are minor differences between the actual encrypted content, file and the encrypted link file. The encrypted section of the encrypted link file simply contains the symmetrically encrypted hypertext transport protocol ΓΉΤΤΡ') link, instead of the encrypted content itself. The encrypted link file is treated by the mail exchange K and distributor gateway i 10 in the same way as any content file sent by the producer. In one or more example implementations, the producers) generate content, package it and dispatch (step 1 ). The encrypted package is transmitted to the mail exchange 106 (step 2), where it is transmitted to the distributor gateway 1.10 for delivery { ^' step 3). Consumer data services are referenced and used by the distributor gateway 1 iO to transmit the encrypted flies to consumers 1 12 (steps 4 and 5). [0054] Continuing with reference to Fig, 7, decryption is performed via a user interface associated with co sumers 112 (steps 6 and 7), For linked content files, the user interface can. perform double decryption. The user interface first decrypts the linked content file to get the location, of the encrypted content file, and then makes a secured request, such as via HTTPS, using the provided Sink to download the encrypted content file. For example, the producer authenticates the request and transmits the actual encrypted content file to the consumer 11.2. Once the file is received via the user interface, a second decryption routine can thereafter be performed, to decrypt the content and. provide the content to the end user.

[0055] The present application is configured to be well-integrated with one or more third party services, including robust content generation and management products and processes, such as provided by XE OS, Other functionality that can be weli-integrated, for example, includes third party tools for physical mail-room digitization and integration (e.g., for enterprise-wide content scanning and dispatch), and third party tools for ad hoc enterprise and commercial dispatch are well integrated with the present application, such as via the producer gateway 102, [0056 _. 1 Figs. 8A-8C illustrate an example implementation of the present application that includes XENOS integration with producer gateway 302, and. includes the producer gateway 1.02 triggering a process associated with a XENOS application, processing information at the XENOS server 802, and the process of the XENOS server handing off information to the producer gateway 102, respectively. [0057] Referring to Fig. 8 A, a producer creates a file such as formatted as an advanced printing file ("AFP"), and creates a batch trigger file, which is transmitted and/or otherwise saved to a predetermined directory 804, which is accessible to the XENOS server 802 (step 1), In one or more implementations, the producer indicates the identifier for the document being transmitted in the respective batch run, and the document identifier is used as part of the file name. The producer can drop multiple trigger files at one time and maintain a high degree of efficiency. The XENOS Server 802 executes one or more processes (e.g., a file daemon) that periodically review the contents of die directory ana, upon a process of discovering the trigger file, and batch processing is instituted (step (2), The XENOS Server 802 further executes one or mor processes that read the document identifier from the file name, such as from the first 36 characters of the file name _. , and that validate the documents against an internal reference, such as a lookup table, of valid d cument identifiers. In one or more implementations, the internal reference {e.g., a lookup table) is provided to the XENOS server via one or more components described herein, such as via the- producer gateway 102. Respective naming conventions, meta-data, document identifiers or the like are monitored and managed, including to maintai compatibility between components shown and described herein, and the XENOS server.

[0 58J Fig. SB illustrates example processing steps in accordance with a XENOS server 802 following receipt of the batch trigger file, described above with reference to Fig. 8A, At step 1 , records of the- batch trigger file are read .and the AFP dat record is read. At step 2, a PDF file (or other suitably formatted file) is distilled in accordance with the document identifier and, and data is inserted ("injected") into the document. Thereafter, the document is .read and private meta-data is created and, for example formatted in JavaScript Object Notation ("JSON"), which is inserted via XMP API into the PDF Document {step 3). At step 4, a random symmetric key (e.g., AES 256) is generated, for example, using the Java Crypto library for each data record, and the PDF document is encrypted with the symmetric key. The encrypted document is stored in a specific location, for example, on disk which is accessible to the producer gateway 102. Thereafter, at step 5, a summary record is

constructed for each respective PDF, and written to a dispatch summary file, which may he specific to each respective batch.

[0059] Referring now to Fig, 8C and continuing with the example process shown in Figs. 8A--8C, once an entire batch has been processed, a message (a package assembly initiation message) is placed on a special queue, such as a Websphere Activ.eMQ queue exposed by the producer gateway 102 {Fig. 8C, step 1). Thereafter, the producer gateway 102 retrieves the package assembly initiation message, for example, from an inbound queue, and the producer .gateway 102 begins a process for content assembly (step 2), The content assembl process includes communication with the mail exchange gateway 106 (not shown), and the encrypted ke package is received. Thereafter, the encrypted PDF file is combined with unencrypted (e.g., "public") metadata and a new mail exchange 106 file is created. Once all flies associated with the batch summary are ready, the producer gateway 102 proceeds to transmit the encrypted packages to the mail exchange 106.

[0 60] As noted above, the present application is configured for integration with third party mail-room digitization. An example configuration and. corresponding process steps representing integration of the present application with mail-room digitization is shown in Fig. 9, and now described. At step 1 , physical, mail is delivered to the producer's interna! mail room. At step 2, a third party watermarking and soiling toot is used to process the mail, which can. include a third party scanning technology 902. for example, provided by

R1TEK). Thi can include, for example, scanning a physical envelope associated with a piece of mail and performing the following tasks;

[0061] a) generate a universally unique tracking number and watermark the tracking number on to the envelope;

[0062] b) determine the sender information and map the sender information to a document identifier provided by one or more components, associated with the present application (e.g., the prod cer gateway 102);

[0063] e) save an image of the envelope to a respective format, such as a portable network graphics ("PNG* ^" ) file;

[0064] d) store a control record representing content with the above data elements in an database that i implemented in accordance with standards governed by the producer gateway 102 (e.g.. a producer gateway 102 managed mail room content ("MRC") database, which can. be a "scan control table" _. );

[0065] e) map a recipient's address to the actual location of the recipient in the organization, and watermark the information on. the envelope or generate a label with the correct address; and

[0066] f) sort the envelopes into bins for delivery to the correct recipients,

[0067] Continuing with reference to the example integration implementation, shown in Fig. 9, at step 3 one or more mail. handlers, such as in the producer ^' s mail room, open the envelope and scan the watermarked envelope and its contents. The scanning process can include the creation of a PDF file (or other suitably formatted file) that includes all of the

1 ? scanned pages, The PDF file is stored in a file system at and/or managed by the producer gateway 102, Moreover, a record that includes a link to the file and/or of the location of the file is loaded into the MRC Database. At step 4, a process occurring at the producer gateway 102, such as a daemon, operates to read the MRC database, to create one or more transmission batches, and to instruct the content transm.iss.ion process to send a batch of documents to one or more recipients that are within the producer's domain.

[0068] Continuing with reference to the example integration implementation shown in. Fig. 9, at step 5 a content transmission initiator component in the producer gateway 102 reads the batch, records specified by the batch creation demon process from the MRC database, the scanned PDF file(s) from the file system of the producer gateway 1.02. Each PDF fde may be encrypted with a unique symmetric key (e.g., generated on-line using JAVA' Crypto Library and the AES 256 Algorithm). Further, a dispatch .summary file is created for the transmission and a content dispatch command message placed on the AES request generator queue. [0069] As noted above, the resent application is also configured for integration for ad-hoc dispatch. An example configuration and corresponding process steps .representing integration, of die present application with, ad-hoc dispatch is shown i.a Fig, 10, and now described. At step 1 , one or more of the producer ^' s content managers and/or operators lo into a producer transaction initiator web site interface 1002, which can be configured as part of or managed by the producer gateway 102, Once authenticated and logged in, the operator provides a PDF file to (he interface- 1002 and defines values corresponding with one or more actions on the document (shown and described in greater detail below with reference to Figs. VIA and J IB),

[0070] Continuing with reference to Fig. 1.0, the website interface 1002 loads the PDF file to one or more servers at. the producer gateway 102 prior to displayi ng the document. Once the document is successfully loaded, the interface 1002 display s document so that ie operator can review the document. The operator sets one or more parameters on the document (e.g., document identifier, action, data, and recipients) and submits the document to the website. Once submitted, the website interface 1002 embeds the document with action data input or otherwise defined by the operator, generates a symmetric key and encrypts the document with the generated symmetric key. A message is placed on the content dispatch command queue to transmit the document. At step 2 the AESK request generator then takes the rocess forward, substantially as shown and described herein, until the content is packaged and transmitted to the consumers; 1 12.

[0071] Figs. 1 1A and 3 I B illustrate example display semens 1102 and i 04, respectively associated with an example web site interface 1002, in operation and at step 1, an operator loads a document from virtually any file system that is accessible from, the operator ^' s browser. The website loads the file into a respective Web Server, and displays the document in. a website window. At step 2, the operator sets one or more document options using features 1 106, shown in Fig, 1 1 A on the right hand side window. Selectable document parameters may include producer, document group, and document type. These options allow the application, to search a control data database associated with the producer gateway 102 for respective actions that are registered to or otherwise correspond with the document type that is selected. At step 3, the operator enters data for actions, as appropriate. Example actions included in the example display screen 1 102 include description, priority, ID, due date, message, link and expiration. At step 4, the operator selects the recipients of the document in the delivery parameters section 1 108 (Fig. 1 18), In the example display screen i.104, the operator can elect to send the document to all the recipients of the document that have a subscription to the document or pick: Individual recipients of the document form this screen. At step 5, the operator selects a graphicai screen control, such as '"submit" button .1 1 10 to initiate the process of document transmission, and to take the process forward, substantially as shown and described herein, until the content is packaged and transmitted to the consumers ! 12.

[0072] Fig. 12 is a block diagram that illustrates an example high level architecture of il¾e mail exchange 106, in accordance with an example implementation of the present application, in one or more implementations the mail exchange 106 is a set of software and hardware components (i cluding, but not limited to Java Services, C ^' XF Web Services,

Websphere MQ Queues, Memcached Clusters, Resin Web Server Clusters, SQL Databases, SecureFTP, San Storage, Firewalls, and one or more demilitarized zones) that enable the transit of encrypted and unencrypted (e.g., clear text) content from the producer gateway 102 to the distributor gateway 1 10, [0073] In one or snore implementations, the mail exchange 106 includes a plurality of external interfaces. For example, these external interfaces can be in. communication with the producer gateway 102, distributor gateway 1 12, payment networks 1202, consumers 112 requesting private keys, and new consumers 1 12 that are registering with the mail exchange ] 06. In one or more implementation, communication with producer gatewayts) [ 02, distributor gatcway(s) 1 10, and payment networks 1202 occurs over one or more leased lines,

[0074 _. 1 Referring now to some example external interfaces included wit the mail exchange .106 shown in. Fig, 12, the producer gateway 106 interface can be implemented in a dedicated virtual iocal area network f'VLAN") and that sriay be provided in a respecti e demilitarized zone (i.e., there may be one VLAN per produces- in the D Z). Each producer interface can aiso be configured with a dedicated transmission, channel for additional transmission security. For example, transmission-related, services and components including databases and caches are pro vided separately for each producer, Moreover, the mail exchange .106 distributor gateway interface can also be implemented in a dedicated VLAN in the demilitarized zone (i.e., there may be one VLAN per distributor).

[0075] Continuing with reference to the example mail exchange 106 architecture shown in Fig, J 2, mail exchange 106 can host a payment gateway 1 204 in which payment instructions set b the consumer are dispatched to a payment network 5.202, Messaging to and from, he payment network(s) 1202 can be over a mechanism of secure communication, preferred by the respective payment network 1202, such as Seeure Q. in one more implementations, the payment gateway 1204 receives status messages from the payment rietwork(s) 1.202, and sends me messages to the consumer at the distributor gateway 110.

[0076 _. 1 Moreover, mail exchange 106 can be configured to host a new consumer registration website. In an example operation, a consumer submits personal information over a secitred connection, such as MTTPS, which is forwarded to EXPERI AN, which returns one or more challenge questions for response by the registering consumer. After the user ^' s answers are confirmed to be correct (e.g., are matched), the identity of the consumer is confirmed and the individual is registered as a consumer in the platform, shown and described herein, in one or more implementations, script-based processes can be provided to load consumer records sent by the producer. The scripts can be run by support staff associated with the mail exchange 1.06. Consumer data records sent b the producer are considered as trusted.

[0077] Further, the mail exchange 1.06 can be configured with a secure administration website that i usable for administrative users having sufficient authentication within an organization. The administration website has features such as application monitoring and launching the services authentication and encryption key service. An administrator can also maintain and manage producer and distributor registration information through this website.

[0078J In one or more one or more processes occurring on received information in the mail exchange 106 separate out the transmission data from control data. As used herein, transmission data relates, generally, to transmissions contai ning content and payments, and delivery state updates that are generated when the producer sends content to the distributor. Transmission data is further separated by storing it in a producer specific transmissi n VLANs within an intranet of the mail exchange .106. Control data relates to consumer profiles, producer and distribution information, and subscription information. Control data related to consumer profile is secured by symmetrically encrypting it {e.g., via an. AES 256 algorithm) and then storing it in the control, data database. Control data for all producers, distributors, and. consumer is managed and stored in a common isolated VLAR

[0079] Fig, 13 is a block diagram that illustrates an example architecture and process steps associated with a private key service in connection with the mail exchan e 306, in accordance with an example implementation, a consumer registers with the mail exchange 106, and the er's u er identifier and hashed password, along with other common user profile details, ate shared with the distributor gateway 1 10. Encrypted content sent by the producer can be stored in encrypted state io the distributor's document repository, in one or more .implementations, the mail exchange 1.06 does not share the consumers public and private key pair that is generated substantially as shown and described herein with either the producer of content, or the distributor of content. The consumer signs in to the distributor's domain and submits a request for content. The encrypted content file is transmitted to the consumer's device, and the consumer uses the private key io decrypt and access the content This process is repeated each time the consumer wishes to access encrypted content,

[0080] Continuing with reference to the example implementation shown in Fig, .13, within (fee mail exchange 106, a consumer's public key is stored in the control data network (e.g., the respective isolated VLAN). The private key is stored in a separate consumer resources network (, e.g.,, the respecti ve i olated VLAN), The consumer resources network, which can be unique to every distributor, can host private key service, for example, i its respective demilitarized zone to provide the consumer with the respective private key do decrypt and access content. The user may be authenticated, for example, via a hash -based message authentication code (e.g., HMAC-SHA256) to authenticate the user to the private key service.

[0081 ] In connection with consumer authentication and the private key process s wn in Fig. IX at step L a client application requests that the consumer provide one or more resource owner password credentials, to be sent to the distributor (e.g., an authorization server). At step 2. the distributor authenticates the consumer's user ID and hashed password against a private data store maintained or otherwise accessible by the distributor. I response, the distributor creates an "access token" based on a shared secret between the mail exchange 106 and the distributor, and passes that back to the client along with the any unread encrypted content, in one or more implementations, the access token is temporary, and can be set to expire- within a short period of time, such as 10 minutes. At step the client makes a (e.g., a second) request to a consumer resources network via the mail, exchange 106, which may include, for example, the UID + .Access Token, for requesting the Private Key. Thereafter, at ste 4, the consumer resources network authenticates the token, passes the credentials to the consumer private key service, which responds hack with the private key of the requesting consumer.

[0082 Fig. 14 is a block diagram that illustrates an example architecture and process steps associated with control and data security. In accordance with the implementation illustrated in Fig, 14, one or more process associated with or occurring at the mail exchange 106 symmetrically encrypt, and stores control data information associated with producers, distributors, and consumers, for example, in a control data database. Appii.cat.ton services running in the producer gateway 102, distributor gateway 1 1 , and consumer control data ("CD") domain use symmetric keys to encrypt and deciphe control, data information,, such as when writing to and reading from the control data database, in one or more implementations, a designated mail exchange 106 system administrator (EMX-SA) loads a set of symmetric keys into a configuration file and symmetrically encrypts a configuration file, for example, with a 16 character secret string. Using an algorithm, such as Shamir ^' s Secret Sharing Scheme (2 of 5), the EMX-SA creates 5 key-shares, and communicates a separate key-share to each of five mail exchange 106 application administrators. Any of the two applicant administrators can then put in their key-shares into a separate entry screens of the mail exchange 106 administration website. Once both key-shares are input, the content encryption key service reads the encrypted configuration file and loads the symmetric keys and service signatures into memory,

[0083] Continuing with reference to the example implementation shown in. Fig. 14, each application service authenticates against the content encryption key service (XEKS") in the mail exchange .106 administration domai n upon startup, for example, by passing the application service's service signature. Separate encryption, keys can be- used to encrypt files relating to component configuration, producer configuration, distributor configuration, and consumer profile information by the persistence service. The persistence service can encrypt and then load the encrypted data into the control data database. The cache, loader service reads encrypted data from the control data database, deciphers it and then loads the objects, for example, into the Memeached Cluster. Upon startup, each component in the control data, domain uses a specific symmetric key received from the content encryption key service to decrypt its respective configuration file, and to load configuration settings into memory, in one or more implementations and as a fall back, to reading data from, caches, each component can IK configured to read the encrypted information from the database and decipher it using the symmetric key received from th content encryption key service.

[0084] Fig. 1.5 is a block diagram that illustrates an example high level architecture of the distributor gateway i 10, in. accordance with an example implementation of the present application. In one or more implementations the distributor gateway 1 10 can be deployed on the distributor's virtual server farm. The distributor gateway I 10 can be configured to implement separate VLANs for control data and transmission data. Configuration and setup of components associated with the distributor gateway 110 can depend, for example, oft individual distributor preferences a«d available infrastructure.

[0085] In operation, the distributor gateway 1 10 communicates with the snail exchange 106 via a dedicated VLAN in the distributor gateway demilitarized zone 1 1 1. Consumer web service may be exposed to handle communication with the consumer user interface on an. isolated VLA in the distributor gateway demilitarized zone 1 1 1 . One or more processes executing on. computing devices in or associated with the distributor gateway 1 10 receive, content files from the mail exchange .106. While command messaging and other data can be exchanged bi -directionally between the distributor gateway 1 10 and di mail exchange 106, such as over secureMQ, in one or more implementations, files and other content doe not flow from the distributor gateway J .10 to the mail exchange 106, [0086] Fig, 16 is a block diagram that shows components associated with a consumer interface with the distributor gateway I. S O. in one or more implementations, consumer web services provided in accordance with the present application are a single interface to the consumer user interface on web browsers, desktops, and mobile devices. Communication between the user interface and the consumer web service can happen using well-structured structured object access protocol ("SOAP") and/or XML messages and over secure sockets layer ("SSL") and/or transport layer security ("TLS" }. The web service security can be extended by adding XML signatures to secure SOAP messages. The web service can implement nonce and a timestamp into the header of the SOAP messages, for example, to prevent replay attacks. Unique ids can be assigned to messages to prevent reuse of messages. The web service authenticates the consumer's credentials (liserid hashed passwords or SA certificate) and passes the request to a consumer data service, for example, that is running in the intranet of the distributor.

[0087] Continuing with reference to the block diagram shown in Fig. 16. content is sent to the user interface from the web service in its original encrypted form. The user interface requests the consumer's private key from a private key service within or otherwise accessible to the mail exchange 106 and is usable to decrypt the content on demand. n. an implementation in which the user interface supports a local repository, content .received from the distributor can be stored in encrypted state. When the user wants access to the content, the user interface can use the consumer's private key to decrypt and provide the content. The local repository can also store other information, such, as the consumer's content records, reference data (e.g., subscriptions.!, prod cer information, and information of other consumers who have shared content with the primary consumer,

[0088] Fig, 17 U a block diagram that illustrates an example architecture and process steps associated, with content, storage and decryption, in accordance with an example

implementation of the present, application. With reference to Fig. 17, consumer

authentication is implemented in a two part process. At step 1 , the first part occurs when the consumer logs into a -respective application and attempts to be authenticated against web services maintained or otherwise accessible to the distributor gateway 1 10. For example, one or more processes operating on the distributor gateway .1 10 authenticates the consumer's user identifier and password and, if successful, delivers a token based on MMAC-SHA256 and a shared secret, value with the mail exchange 106. At step 2. the second part of authentication includes the consumer's device sending the token received from the distributor gateway ί 10 to the mail exchange 106. The mail exchange- 106 generates an internal token and compares the interna! token to the token received from the consumer's device. The mai! exchange also authenticates the respective user identifier and password that was submitted by the consumer. Once the two credentials match., a private key service associated with or occurring within the mail exchange 106 responds back with we consumer's private key. for example, over

HTTPS. The pri ate key can be stored in a session variable or secure storage (e.g.. iOS ^' Key Chain), in one or more implementations, the private key is not stored to disk, in this way, as long as the application is running on the device, the private key is available for the consumer to decrypt and have access to content.

[0089] Continuing with reference to the example implementation shown in Fig. 17, at step 3 and after the consumer has received the private key, a request is transmitted to the distributor gateway 110 for new content. Content packages are downloaded in their respective original encrypted state. A content retriever process is operable to examine public meta-tiata associated with each content, package for. for example, markers indicating linked-content. When a liiiked-contenf. file is detected, the content retriever decrypts the AESK corresponding to the consumer, decrypts the content to ge the actual link, and downloads the actual contest package from the link location, for example, over HTTPS, At step 4, public me a-data that is embedded in the content in clear text format is extracted and loaded into a relational database, such as SQL or the like, on the consumer's device 1 12, The encrypted content package itself can be stored on the consumer's device file system, including a mobile device file system, A pointer/reference to the content, file location, can also be stored i the database record.

[0090] Continuing with reference to the example implementation shown in Fig, .17, at step 5 the consumer requests to access the actual content sent by the producer. In response, a content decryption service operating in the consumer device, which may be a mobile device, accesses the encrypted, content and the consumer's private key, and performs a double decryption process. For example, the asymmetrically encry pted symmetric key

corresponding to consumer's identifier is decrypted, and the symmetric key is extracted.. The symmetric key is usable, thereafter, to decrypt the content. In one or more implementations, neither the decrypted content nor the symmetric key s stored anywhere on the consumer (e.g., mobile} device, instead, both of these elements are discarded as the consumer moves on to access other contest on his/her device. At step 6. the consumer (e.g., mobile) device accesses the actual content sent by the producer to the consumer. After the consumer navigates away from the content access (e.g., view) screen, the decrypted content is discarded f m the device's memory, if the consumer wishes to see the content again, the content decryption process is repeated and the content is provided again for the consumer.

[009.1] Thus, as shown and described herein, one or more machines (e.g., a computer or server having a processor and memory) process transactions in support of deli very between producers and consumers as a function of a secured and n:vu hi -level platform. Each machine, computer, or server described herein includes a processor that executes code to configure the processor into a special purpose machine suitable for implementing the functionalities described.

[00192] In one or more implementations, one or more processes operatin on the producer gateway 102 can create a- particular envelope file for each piece of content

dispatched by the producer for delivery to the consumer through the mail exchange 106. The envelope file, referred to herein as the content package file may be configured with a ^M .EMX" extension. In one or more implementations, the payload of this file is provided in an XML structure and contains a public meta-data section and a content section.

[0093] The public meta-data section of the content package file can contain addressing information that enables content deliver by the mail exchange 106 to the correct consumer associated or at the. correct, distributor gateway 1 1 . This addres ing information can also be in an XML structure defined in a particular document schema. The content section of the content package file can contain a byte stream of encrypted data. These data are provided, for example, in a PDF content file and. embedded with an XML data structure defined in a private meta-data part of the schema, and then symmetrically encrypted by the producer, for example, using a randomly generated symmetric key.

[0094] In accordance with an implementation of the present application, the particular schema includes of two respec tive XML sc.hemas. A s noted above, the first schema is the public meta-data schema and the second schema is the private meta-data schema, These two meta-data schema* can be embedded i nto the content package file by two different processes, For example, the producer gateway i 1.0 can embed the public meta-data structure into the document header i clear test. The producer of the content can embed the private rneta-data data structure into the PDF content file, for example, by using APIs associated with the extensible metadata platform ("XMP"),

[0095] he public meta-data action of the CPF contains an XML structure that is based on the following schema.

[0096] In accordance with the example poblfc metadata schema section, the element

"transmissiosild" .represents th universally unique 36 character identifier assigned by the mail exchange H)6 to each .respective content package. The traosm.issionld can ^' be- generated when the mail exchange 106 creates an asymmetrically encrypted symmetric key for each content, package. In one or more implementations, this is a required element, and the produce provides a value in the XML structure for this element. The element, produced ! represents the universally unique 36 character Identifier assigned by the mail exchang 106 to the producer when the producer registers with the mail exchange 106. in one or more implementations, this is a required element and the producer provides a value in the XML structure for ibis element. The element. keyPackage. represents a stream of data containing one asymmetrically encrypted symmetric key for each consumer that is to receive the content package file. This field can contain the key package and ean he an optional element and is dependent on the "encrypted ^*5 flag. If the content is encrypted, then the keyPackage element will be populated.

[0097] Continuing with reference to the example public meta-dat schema, the element ' ^" action" indicates that the producer is requesting that the consumer take an action on the file, in one or more implementations, the "action" element can have the following required and optional attributes: "aetkmRequired' ^* - this is a (Yes/No) field indicating if action is required; "actionDueDaie" - this attribute, is the date the action is doe by. it is a date field and is set when the "actionRequired" attribute is set to "Y". In one or more implementations, action is a required element to be populated by the producer. The element "contentType" represents the type of file embedded in the content section of the content package file. The producer can send PDFs, PNG, JPEG, IMG, and other file types to the consumer, in one or more implementations, this is a required, element and the producer provides a value in the XML structure for this element. The element "encrypted ^" represents whether the content embedded in the content section is encrypted or unencrypted, in one or more implementations, this is a required element and the producer provides a value in t e XML structure for this element.

[0098 _. 1 Continuing with reference to the example public meta-daia schema, the element "audit ^' Trair is a grouping element containing or more audit trail records. Tins is an optional element and the producer may not provide any information for this element The element "auditReeord" is contained within the "auditTrail" element. This element contains the following required / optional attributes: Required Attribute: "actionDate" - this is a date field containing the time th action was taken on the content; Required Attribute:

"fromSonrceRecipienlName" - this is a text, field, containing the name of the person who took the action; Optional Attribute: "toTarge Recipie-nt ame" - this is a text field containing the name of the person who was the target of the action; and Required Attribute: "actionid" this is a text field indicating what type of action w s taken (FWDDEL - Forward and Delete, FWDKEP - Forward and keep. PR!NTX - Print Document, EMAILX - Email Document).

2S In one or more implementations, this is a required element and the audit trail component in the producer and distributor provides values for all required attributes of this element. In one or more implementations, the element "image" contains a binary data stream of an unencrypted image file. This is an optional element and the producer may not provide a value in the XML structure for this element.

[0099] The content section contains the symmetrically encrypted content file with embedded private metadata. The producer first embeds the private metadata into the content file and then symmetrically encrypts it with a randomly generated symmetric key. An example private metadata schema is shown below, and corresponding individual elements are described below.

<?xml version= "1.0 " encoding= "UTF-8 "?>

targetNamespace= "http : //www . eclipse . org/webtools/PrivateMetaData " xmlnsrmail exchange

106= "http : //www. eclipse . org/webtools/PrivateMetaData ">

<annotation>

<documentation xml : lang= "en ">

Schema for Private Meta-Data

Copyright Eco-mail Development LLC

</documentation>

</annotation>

<element name="PrivateMetaData" type="mail exchange

106 : PrivateMetaDataType "></ element>

<complexType name= "PrivateMetaDataType ">

<sequence>

<element name= "producerDetaiIs " type="mail exchange 106 : ProducerDetail " minOccurs= "1 "maxOccurs= "1 "/>

<element name= "documentDetaiIs " type="mail exchange

106 : DocumentDetail " maxOccurs= "1 " minOccurs= "1 "/>

</sequence>

</complexType>

<complexType name= "ProducerDetail ">

<attribute name= "producerld " type="string" use="required" />

<attribute name="consumerld" type= "string " use="required"

/>

<attribute name= "subscriptionld" type="string" use= "required " />

</complexType>

<complexType name= "DocumentDetail ">

<sequence>

<element name= "actions " type="mail exchange

106 : action" minOccurs= "0 " />

</sequence>

<attribute name= "customerldentifierType" type="string" use= "required " />

<attribute name= "customerldentifier" type= "string" use= "required " />

<attribute name="documentId" type= "string" use="required"

/>

<attribute name= "documentCategoryld" type= "string" use= "required " />

<attribute name= "periodDescription " type= "string" use= "required " />

<attribute name= "periodStart " type= "string"

use="required" />

<attribute name= "peri odEnd" type="string" use="required"

/>

<attribute name= "documentDate " type= "string"

use="required" />

<attribute name= "producerMessage " type= "string" use= "optional " />

</complexType>

<complexType name= "action ">

<sequence>

<element name="thirdPartyPayment" type="mail exchange 106 : ThirdPartyPayment " minOccurs= "0 " />

<element name= "payment " type="mail exchange

106.-PaymentAction" minOccurs= "0 " />

<element name= "acknowledistributor gateway llOement" type="mail exchange 106 :Acknowledistributor gateway llOementAction" minOccurs= "0 " />

<element name= "acceptDeline " type="mail exchange 106.-AcceptDeclineAction" minOccurs= "0 " />

<element name= "dispute " type="mail exchange

106 : DisputeAction" minOccurs= "0 " />

<element name= "display " type="mail exchange

106 : DisplayAction" minOccurs= "0 " />

</sequence>

</complexType>

<complexType name= "baseAction ">

<sequence>

<element name= "message " type="string" />

<element name="link" type="string" /> <element name= "expirationDate " type="string" /> </sequence>

<attribute name= "actionDescription" type="string" use= "required " />

<attribute name= "actionPriority" type="mail exchange 106 : PriorityType" use="required" />

<attribute name= "actionld" type="mail exchange 106 :ActionType" use="required" />

<attribute name= "actionDueDate " type="string" use= "optional " />

</complexType>

<complexType name= "ThirdPartyPayment ">

<complexContent>

<extension base= "mail exchange 106 :baseAction">

<attribute name= "beneficiaryName "

type= "string" use= "required " /> <attribute name= "beneficiaryAccount "

type="string" use= "required " />

<attribute name="amountDue" type= "string " use= "optional " />

<attribute name= "minimumAmountDue "

type="string" use= "optional " />

<attribute name= "routingNo " type= "string " use= "optional " />

<attribute name= "referencelnfo " type="string" use= "optional " />

</extension>

</complexContent>

</complexType>

<complexType name= "PaymentAction ">

<complexContent>

<extension base= "mail exchange 106 :baseAction">

<attribute name= "autoPaid" type="mail exchange 106 :AutoPayType" use="required" />

<attribute name= "amountDue " type= "string " use= "required " />

<attribute name= "minimumAmountDue "

type= "string" use= "optional " />

</extension>

</complexContent>

</complexType>

<complexType name= "Acknowledistributor gateway

llOementAction ">

<complexContent>

<extension base= "mail exchange 106 :baseAction"> <sequence>

<element name= "responseData " type="mail exchange 106 :Acknowledistributor gateway llOementData" ^' />

</sequence>

</extension>

</complexContent>

</complexType>

<complexType name= "AcceptDeclineAction ">

<complexContent>

<extension base= "mail exchange 106 :baseAction"> <sequence>

<element name= "acceptData " type="mail exchange 106:AcceptActionData "/>

</sequence>

</extension>

</complexContent>

</complexType>

<complexType name= "DisputeAction ">

<complexContent>

<extension hase="mail exchange 106.-baseAction" />

</complexContent>

</complexType>

<complexType name= "DisplayAction ">

<complexContent>

<extension base= "mail exchange 106.-baseAction"/> </complexContent> </complexType>

<simpleType name= "'AcceptActionData ">

<restriction base= "string">

enumeration value= "ACCEPT" />

enumeration value= "DECLIN" />

enumeration value= "IGNORE " />

</restriction>

</ simpleType>

<simpleType name="Acknowledistributor gateway 110ementData"> <restriction base= "string">

enumeration value= "RECIVD " />

<enumeration value= "READAK" />

<enumeration value= "ACKDISTRIBUTOR GATEWAY 110E" /> </restriction>

</ simpleType>

<simpleType name= "ActionType ">

<restriction base= "string">

enumeration value= "3PAYMT" />

enumeration value= "PAYMNT " />

enumeration value= "ACKNOW" />

enumeration value= "DISPUT " />

enumeration value= "ACCEPT" />

enumeration value= "SNDINF" />

enumeration value= "DISPLA " />

</restriction>

</ simpleType>

<simpleType name= "PriorityType ">

<restriction base= "string">

<enumeration value= "HIGH " />

<enumeration value= "MEDIUM" />

<enumeration value= "LOW" />

enumeration value= "NONE " />

</restriction>

</ simpleType>

<simpleType name= "AutoPayType ">

<restriction base= "string">

<enumeration value= "AUTOPAID " />

<enumeration value= "MANUAL " />

</restriction>

</ simpleType>

</schema>

[00100] In the example private metadata schema, there are two sections. One is the document details section in which details of the document are set, and the second section is the producer detail section, in which information about the producer and actions on the document that are allowed and required are set.

[00101] Referring now to the producer detail section of the example private meta-data scheme, the element "producerld" represents a unique 36 character identifier assigned by the mail exchange 106 to the producer at the time the producer registers with the mail exchange 106. In one or more implementations, this is a required element and the producer provides a value in the XML structure for this element. The element "consumerld" is a universally unique 36 character identifier assigned by the mail exchange 106 to the consumer at the time the consumer registers with the mail exchange. In one or more implementations, this is a required element and the producer provides a value in the XML structure for this element." The element "subscriptionld" is a universally unique 36 character identifier assigned by mail exchange 106 to the subscription between a consumer and a document registered by the producer with the Eco-mail exchange. In one or more implementations, this is a required element and the producer provides a value in the XML structure for this element. [00102] Elements associated with the document details section of the example private meta-data scheme shown above are now described. The element "baseAction" is a complex element type that defines a base set of elements and attributes that form part of actions embedded in a grouping element, "actions." The base set of elements include: "message" (a free form text field that can be populated by the producer); "link" (a URL created by the producer corresponding to the "message" element); "expirationDate" (a date field indicating the expiry date for the corresponding "link" element). Each baseAction also has some key attributes that include: "actionDescription" (a text description of the action); "actionPriority" (indicates the priority of the action, and the producer provides one of these choices: High, Medium, Low, None Required); "actionid" (a set code for the action and the producer selects from one of these choices: 3PAYMT, PAYMNT, ACKNOW, DISPUT, ACCEPT, SNDINF, DISPLAY); and "actionDueDate" (a date field specifying when the action is due). In one or more implementations, the complex element "baseAction" is a mandatory part of every action and the producer provides a value in the XML structure for this element if an action is embedded in the "documentDetails" section, including as described in greater detail, below. [00103] Continuing with reference to the Document Details in the example schema above, the element "thirdPartyPament" is a complex element that defines elements and attributes that enable payment to a 3rd Party other than the producer. The

"thirdPartyPament" element inherits elements and attributes of the "baseAction" element and has the following additional required and optional attributes: "beneficiaryName" (a name of the person, party, company or entity which will receive the payment); "beneficiary Account" (an account number of the 3rd party person or entity which will receive the payment);

"amountDue" (an amount due for payment, which is a numeric decimal field); "minimumAmountDue" ( a minimum amount due for payment, and which is a numeric decimal field); "rountingNo" (an electronic payment routing information that is used by payment network to execute the payment); "referencelnfo" (a text message field and that can include additional payment forwarding and credit information as required by the recipient's financial institution). The "thirdPartyPayment" element is optional and the producer may not provide a value in the XML structure for this element if this action is not required by the producer. Also as shown in the schema set forth above is the "payment" element, which is a complex element defines elements and attributes that enable payment to the producer. The "payment" element inherits all the elements and attributes of the "baseAction" element and has the following additional elements and attributes: "autoPaid" ( - this attribute indicates if the payment has been setup to be automatically paid by the consumer with the producer. Required Attribute: "amountDue" - this is the total amount of payment due. This is a numeric decimal field. "minimumAmountDue" - this is minimum amount due for payment. This is a numeric decimal field. The "payment" element is optional and the producer may not provide a value in the XML structure for this element if this action is not required by the producer.

[00104] Although much of the foregoing description has been directed to systems and methods for code processing, the systems and methods disclosed herein can be similarly deployed and/or implemented in scenarios, situations, and settings far beyond the illustrated scenarios. It can be readily appreciated that code processing system 100 can be effectively employed in practically any scenario where code processing can be useful. For example, while many of the foregoing examples and illustrations pertain to implementations that relate to virtual/video gaming, the various technologies described herein can be implemented in any number of other settings and circumstances. By way of illustration, the apparatus, methods, and systems described herein can be implemented in a setting whereby a service provider, such as a doctor, pharmacy, insurance company, etc., can provide an item having a code to a user (e.g., a patient, customer, etc.), and such code can be perceived by a device (using a viewer such as the platform/base/lens apparatus described herein) in order to access information pertaining to the user, such as in a manner known to those of ordinary skill in the art. It should be noted, however, that in scenarios where the information being accessed is personal and/or sensitive, any number of verifications can be required (e.g., inputting a unique user ID/password) in order to ensure that only the intended recipient of the code is capable of viewing the embedded/associated information. Moreover, as described above, depending on the specifications of the particular lens and/or translucent platform through which the code is perceived by the computing device, varying degrees of access can be provided (for example, different lenses/colors can correspond to different roles, e.g., doctor, patient, nurse, pharmacist, etc., each being provided different types/degrees of access to information embedded within/associated with a particular code). It should also be noted that though much of the foregoing description and examples have been provided with respect to various codes (e.g., QR codes, etc.), any number of other methods can be similarly implemented (e.g., Bluetooth, NFC, Wi-Fi, or the likeOu) in order to provide identifying information to a device, as can be appreciated by those of ordinary skill in the art. It should be further understood that any such implementation(s) and/or deployment(s) are within the scope of the systems and methods described herein.

[00105] It is to be understood that not all components and/or steps described and illustrated with reference to the figures are required for all embodiments or arrangements. It should also be understood that the embodiments, implementations, and/or arrangements of the systems and methods disclosed herein can be incorporated as a software algorithm, application, program, module, or code residing in hardware, firmware and/or on a computer useable medium (including software modules and browser plug-ins) that can be executed in a processor of a computer system or a computing device to configure the processor and/or other elements to perform the functions and/or operations described herein. It should be appreciated that according to at least one embodiment, one or more computer programs, modules, and/or applications that when executed perform methods of the present invention need not reside on a single computer or processor, but can be distributed in a modular fashion amongst a number of different computers or processors to implement various aspects of the systems and methods disclosed herein. [00106] Thus, illustrative embodiments and arrangements of the present systems and methods provide a computer implemented method, computer system, and computer program product for processing code(s). The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments and arrangements. In this regard, each block in the flowchart or block diagrams can represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[00107] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising", when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

[00108] Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of "including," "comprising," or "having," "containing," "involving," and variations thereof herein, is meant to encompass the items listed thereafter and equivalents thereof as well as additional items.

[00109] The subject matter described above is provided by way of illustration only and should not be construed as limiting. Various modifications and changes can be made to the subject matter described herein without following the example embodiments and applications illustrated and described, and without departing from the true spirit and scope of the present invention, which is set forth in the following claims.