Generating and storing document data

A markup language document is generated and stored within a network, the network including a client, and one or more storage locations. A markup language document is generated, and policy information is accessed, wherein the policy information defines a content-filtering policy, a security policy and a storage location policy for the markup language document. A portion of the markup language document that is subject to security is determined, based on the content-filtering policy as defined in the policy information. A storage location is identified for storage of the markup language document from among the one or more storage locations, based on the storage location policy as defined in the policy information. Security is applied to the determined portion of the markup language document based on the security policy as defined in the policy information. The markup language document is stored on the identified storage location.

FIELD

The present disclosure relates to the field of generating and storing document data, and more particularly relates to generating and storing a markup language document or a Portable Document Format (PDF) document within a network.

BACKGROUND

Cloud computing generally refers to applications and services offered over the Internet. With the advent of web document services (e.g., Google Docs and Microsoft Word Web App), the manipulation of document data in the cloud repository has been gaining popularity.

For example, with reference to printing or scanning technology within the cloud architecture, the saving of print or scan data to a document service storage location is typically a desired function. In this regard, network-based arrangements for generation and storage of document data can include generation of document data by a printer driver or a scanner driver.

SUMMARY

There are certain considerations that can be taken into account when utilizing the cloud infrastructure to allow a user to store print or scan data. For example, storing print data typically requires a large storage space, and the processing of such data typically requires additional processing time.

In addition, a traditional Graphics Device Interface (GDI)-based printer driver typically renders application-dependent binary data to Printer Command Language (PCL) format data, and this may be difficult for content-filtering and data extraction. In particular, the PCL language typically does not provide data integrity and confidential scheme in the data itself.

Furthermore, while conventional printer driver architecture can provide for printing data with improvements from Window's Web Services for Device (WSD), such an arrangement typically does not address issues relating to filtering and storing data to the cloud storage. However, with the growth in storage requirements typically required by cloud computing and ever-increasing processing power, together with markup language-based document data (e.g., Window XML Paper Specification (XPS) document data and PDF to Extensible Markup Language (XML) conversion data), the desire for content filtering and data extraction increases.

One concern regarding cloud computing and data storage is that when a third party is hosting or transmitting data, data security when using cloud computing can be important at all levels, including infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), and software-as-a-service (SaaS). For example, it may be desirable to protect the data itself so that only the user creating the data can view the data to ensure data privacy.

The present disclosure addresses the foregoing problems. Disclosed embodiments describe generating and storing document data within a network, the network including a client, and one or more storage locations. Policy information is accessed for a generated document, wherein the policy information defines a content-filtering policy, a security policy and a storage location policy. A portion of the document that is subject to security is determined based on the content-filtering policy, and a storage location is identified for storage of the document from among the one or more storage locations based on the storage location policy. Security is applied to the determined portion of the document based on the security policy, and the document is stored on the identified storage location.

In an example embodiment described herein, a markup language document is generated and stored within a network, the network including a client, and one or more storage locations. A markup language document is generated, and policy information is accessed, wherein the policy information defines a content-filtering policy, a security policy and a storage location policy for the markup language document. A portion of the markup language document that is subject to security is determined, based on the content-filtering policy as defined in the policy information. A storage location is identified for storage of the markup language document from among the one or more storage locations, based on the storage location policy as defined in the policy information. Security is applied to the determined portion of the markup language document based on the security policy as defined in the policy information. The markup language document is stored on the identified storage location.

The network can further include a policy server, and the policy server can be accessed to obtain the policy information. The one or more storage locations can correspond to one or more storage servers. The security policy can correspond to at least one of an encryption policy and a signing policy, and the security can be applied by respectively performing at least one of encryption and signing to the determined portion. The policy information can further define authentication information for the markup language document, and the authentication information as defined in the policy information, together with the markup language document, can be stored on the identified storage location.

The markup language document can be an XML Paper Specification (XPS) document. The network can be an enterprise network, and the content-filtering and security policies can apply enterprise-wide. The markup language document can correspond to an image document service portal, so that data within the markup language document is processed and returned to the client for reassembly and reformulation of the markup language document. A user interface can be displayed for allowing a user to adjust the policy information. The client can comprise a driver. The driver can be a printer driver or a scanner driver. The driver can perform the generating, accessing, determining, identifying, applying and storing.

The network can further include a rendering server and a policy server from which the policy information is accessed, and the driver can forward the markup language document to the rendering server for performing the generating, accessing, determining, identifying, applying and storing. The policy server and the rendering server can be implemented on a common machine within the network. Alternatively, the policy server and the rendering server can be implemented on different machines that communicate over the network. The security can be applied to the determined portion of the markup language document with both user and administrator encryption keys, based on the security policy as defined in the policy information.

In a further example embodiment, a Portable Document Format (PDF) document is generated and stored within a network, the network including a client, and one or more storage locations. A PDF document is generated, and policy information is accessed, wherein the policy information defines a content-filtering policy, a security policy and a storage location policy for the PDF document. A portion of the PDF document that is subject to security is determined, based on the content-filtering policy as defined in the policy information. A storage location is identified for storage of the PDF document from among the one or more storage locations, based on the storage location policy as defined in the policy information. Security is applied to the determined portion of the PDF document based on the security policy as defined in the policy information. The PDF document is stored on the identified storage location.

This brief summary has been provided so that the nature of this disclosure may be understood quickly. A more complete understanding can be obtained by reference to the following detailed description and to the attached drawings.

DETAILED DESCRIPTION

FIG. 1is a depiction of a network environment which provides for generating and storing a document within a network according to an example embodiment. Network environment100can include a client102, storage locations106-A to106-C (collectively referred to as storage locations106), and a printer/scanner108connected via a network104.

Network environment100can provide for the generation and storage of a document, such as a markup language document or a Portable Document Format (PDF) document. Network104can include one or more networks, such as a local area network (LAN), a wide area network (WAN), an intranet, the Internet, or another type of network. Client102, storage locations106and printer/scanner108can connect to network104via wired, wireless, optical, or other types of network connections.

FIG. 2is a block diagram depicting the internal architecture of a client inFIG. 1according to an example embodiment. In the example ofFIG. 2, client102can correspond to a personal computer. However, it should be noted that client102can correspond to one or more types of devices, such as a personal (or laptop) computer, a computer server, a cellular phone, a personal digital assistant (PDA), or another type of communication device, a thread or process running on one of these devices, and/or objects executable by these devices. In the example ofFIG. 2, the internal architectures for these other types of devices will not be described with the same amount of detail as a personal computer.

As can be seen inFIG. 2, client102can include a central processing unit (CPU)200such as a programmable microprocessor which can be interfaced to computer bus202. Also coupled to computer bus202can be a input interface204for interfacing to an input device (e.g., keyboard, touch screen, mouse), a display interface224for interfacing to a display, and a network interface210for interfacing to a network, for example, network104. Network interface210can contain several modules to provide the appropriate interface functionality for client102.

For example, network interface210can contain network interface layer222which can be a low-level protocol layer to interface with a network (e.g., network104). TCP/IP layer220can be provided above network interface layer222for connecting to network104via TCP/IP, a standard network protocol. Other protocols218can also be provided to allow client102to communicate over network104using other conventional protocols. In this regard, it is possible for HTTP protocol212, SNMP protocol214and LDAP protocol216to be provided in network interface210for allowing client102to communicate over network104via HTTP, SNMP and LDAP protocols, respectively. However, it should be noted that HTTP, SNMP and LDAP protocols, along with other conventional protocols, can instead be provided by operating system228.

Random access memory (“RAM”)206can interface to computer bus202to provide central processing unit (“CPU”)200with access to memory storage, thereby acting as the main run-time memory for CPU200. In particular, when executing stored program instruction sequences, CPU200can load those instruction sequences from fixed disk226(or other memory media) into random access memory (“RAM”)206and execute those stored program instruction sequences out of RAM206. It should also be noted that standard-disk swapping techniques can allow segments of memory to be swapped to and from RAM206and fixed disk226. Read-only memory (“ROM”)208can store invariant instruction sequences, such as start-up instruction sequences for CPU200or basic input/output operation system (“BIOS”) sequences for the operation of network device devices attached to client102.

Fixed disk226is one example of a computer-readable medium that can store program instruction sequences executable by central processing unit (“CPU”)200so as to constitute operating system228, input interface driver230for driving input interface204, display interface driver232for driving display interface224, network interface driver234for driving network interface210, document driver236, and other files238.

Operating system228can be a windowing operating system, such as Windows 95, Windows 98, Windows 2000, Windows XP, Windows 7, Windows NT, or other such operating system, although other types of operating systems such as DOS, UNIX and LINUX may be used. Other files238contain other information and programs necessary for client102, to operate and to add additional functionality to client102.

Document driver236can be used to generate and store a document within a network104, such as a document sent from client102for printing/scanning on printer/scanner108and for storage on one of storage locations106. In this regard, document driver236can correspond to a printer driver or a scanner driver.

Document driver236can access policy information, wherein the policy information defines a content-filtering policy, a security policy and a storage location policy for the document. For example, the document can correspond to a markup language document (e.g., an XPS document) or a PDF document. Document driver236can determine a portion of the document that is subject to security, based on the content-filtering policy as defined in the policy information.

Document driver236can further identify a storage location (e.g., one of storage locations106) for storage of the document from among the one or more storage locations, based on the storage location policy as defined in the policy information. In addition, document driver236can apply security to the determined portion of the document based on the security policy as defined in the policy information, and can request storage of the document on the identified storage location (e.g., one of storage locations106).

FIG. 3is a block diagram depicting the internal architecture of a storage server shown inFIG. 1according to an example embodiment. In the example ofFIG. 3, storage server106can correspond to an identified storage location for storing a document, where security has been applied to a portion of the document based on policy information, for example. In addition, storage server300can correspond to one or more of storage locations106.

Storage server300can include a central processing unit (“CPU”)302such as a programmable microprocessor which can be interfaced to server bus304. Also coupled to server bus304can be a network interface306for interfacing to a network (e.g., network104). In addition, random access memory (“RAM”)320, fixed disk324, and read-only memory (“ROM”)322can be coupled to server bus304. RAM320can interface to server bus304to provide CPU302with access to memory storage, thereby acting as a main run-time memory for CPU302. In particular, when executing stored program instruction sequences, CPU302can load those instruction sequences from fixed disk324(or other memory media) into RAM320and execute those stored program instruction sequences out of RAM320. It should also be recognized that standard disk-swapping techniques can allow segments of memory to be swapped to and from RAM320and fixed disk324.

ROM322can store invariant instruction sequences, such as start-up instruction sequences for CPU302or basic input/output operating system (“BIOS”) sequences for the operation of network devices which may be attached to storage server300. Network interface306can contain several modules to provide the appropriate interface functionality for storage server300. For example, network interface306can contain network interface layer318, which is typically a low-level protocol layer. TCP/IP protocol316can be provided above network interface layer318for communicating over a network (e.g., network104) via TCP/IP. Other protocols314can also be provided to allow storage server300to communicate over network104using other conventional protocols. In this regard, it is possible for HTTP protocol308, SNMP protocol310, and LDAP protocol312to be provided in network interface306for allowing storage server300to communicate to over network104using HTTP, SNMP and LDAP, respectively. However, it should be noted that HTTP, SNMP and LDAP protocols, along with other conventional protocols, can instead be provided by operating system326. The foregoing protocols can allow for storage server300to communicate over network104with other devices (e.g., client102). For example, client102can generate a document and apply security to a determined portion of the document. Using one or more of the foregoing protocols, client102can request storage of the document on storage server300based on policy information.

Fixed disk324is one example of a computer-readable medium that stores program instruction sequences executable by CPU302so as to constitute operating system326, network interface driver328, and other files330. Operating system326can be an operating system such as DOS, Windows 95, Windows 98, Windows 2000, Windows XP, Windows 7, Windows NT, UNIX, or other such operating system. Network interface driver328can be utilized to drive network interface306for interfacing storage server300to clients102via network104. Other files330can contain other files or programs necessary to operate storage server300and/or to provide additional functionality to storage server300.

FIG. 4is a block diagram depicting a system for generating and storing an XML Paper Specification (XPS) document with client-side rendering according to an example embodiment. In the example ofFIG. 4, the document is an XPS document. However, other markup language documents or a PDF document can be used.

By generating and storing documents according to example embodiments described herein, it is possible to selectively store print/scan data based on the document purpose (e.g., by utilizing a cloud document service) along with a user-preferred format, to a storage location via a printer driver while the document is printing from a client (e.g., office application) to the printer device (e.g., printer422). Such a printer driver can be a local printer driver (e.g., printer driver404) or can correspond to a print server system (e.g., the system ofFIG. 5, which will be described in greater detail below).

In the example ofFIG. 4, a Windows standard XPS rendering method with client-side rendering is illustrated. Windows XPS print path can be used so that a Windows XPS driver400can render an XPS document402. Printer driver404can further process the XPS document to create and encrypt the new document. In other words, printer driver404can use Window XPS print path to create an XPS document, and printer driver404can obtain the XPS data.

A policy server (e.g., local policy420) and a user-defined policy file can be associated with the printer driver404, and the user can define policy via driver UI406. Module408in printer driver404can start processing the XPS print data once the data is obtained. In doing so, module404can retrieve policy information which defines a content-filtering policy, a security policy and a storage location policy for the XPS document. Module404can retrieve the policy information from a policy server (e.g., local policy420) and/or a key store server (e.g., key418). Key store server418can contain encryption and decryption keys to encrypt and decrypt the XPS document.

In this regard, module408can include module410for spooling the XPS data, module412for generating the XPS document, module414for XML encryption and module416for performing unified authentication. In addition, it is possible for printer driver404to perform content filtering with XML canonicalization and XML encryption (not shown).

Thus, before the XPS data is sent to printer422, if a user (e.g., via driver UI406) selects to save data or portions of the data to specific storage systems (e.g., to local storage434), printer driver404can process the XPS data. Driver UI406or a remote UI can provide interfaces for allowing a user to select a specific storage system, and to define specific content filtering rules to encrypt specific content for privacy. For example, driver UI406can contain the user interface to allow the user to set policy for filtering content, encryption key location, storage location and authentication information.

The XPS data can be processed based on the cloud service and/or policy instructions given, to perform content filtering and extraction, and to apply security (e.g., encryption, digital signature) to the data. In this regard, the data may be encrypted with the user's public key so that only the user can decrypt the data.

As noted above, printer driver404can send the XPS data (or XPS data converted to PCL data) to printer422, and can process the XPS data based on policy information retrieved from a policy server (e.g., local policy420). In addition, the processed data can be sent to custom port monitor424for storage to designated locations. Thus, printer driver404can generate a new set of documents, which can correspond to portions of the document with different types of formatting based on the document type supported in the cloud, to the designated locations via custom port monitor424.

In this regard, custom port monitor424can be used to direct print and storage data to designated locations. Custom port monitor424can include WSD, TCP/IP, virtual and default port monitors. As noted above, for authentication with different storage systems, printer driver404can include a module (e.g., module416) to perform authentication with the different storage systems.

As can be seen inFIG. 4, the storage repository can be a public or private cloud storage system. In a private cloud system, hosted services are typically provided to a limited number of users behind a firewall. On the other hand, in a public cloud system, a service provider makes resources, such as applications and storage, available to the general public over the Internet.

In addition, the storage repository can correspond to enterprise storage (e.g., local storage434), storage of an image within a cloud, Google Docs or Window Web Office. In the example ofFIG. 4, designated portions of the XPS document are referenced by numeral426, new PDF data is referenced by numeral428, image data is referenced by numeral430, and extracted data is referenced by numeral432. Cloud436can correspond to a public cloud or a private cloud.

It should further be noted that when the user retrieves the document from storage, it is typically necessary to decrypt those portions of the document data which were subject to encryption. In this regard, the architecture illustrated inFIG. 4can also be used for decrypting the document data.

FIG. 5is a block diagram depicting a system for generating and storing an XPS document with server-side rendering according to an example embodiment. In the example ofFIG. 5, the document is an XPS document. However, other markup language documents or a PDF document can be used.

By generating and storing documents according to example embodiments described herein, it is possible to selectively store print/scan data based on the document purpose (e.g., by utilizing a cloud document service) along with a user-preferred format, to a storage location via a printer driver while the document is printing from a client (e.g., office application) to the printer device (e.g., printer514). Such a printer driver can be a local printer driver or can correspond to a print server system (e.g., print server518)

In the example ofFIG. 5, a Windows standard XPS rendering method with server-side rendering is illustrated. User system500can include a Windows XPS driver502, a printer driver504with driver UI506, a key508and a local policy510. Windows XPS print path can be used so that the Windows XPS driver502can render an XPS document546, and print server518can further process the XPS document to create and encrypt the new document. To do this, printer driver504can pass the XPS data to print server518for rendering and print job processing. In other words, printer driver504can use Window XPS print path to create an XPS document, printer driver504can obtain the XPS data, and printer driver504can pass the XPS data to print server518for further processing. As described below, print server518can contain the server-side XPS rendering engine and custom port monitor534, usually used by the enterprise.

A policy server (e.g., enterprise policy512) and a user-defined policy file can be associated with the print server518, and the user can define policy via UI522. Module524in print server518can start processing the XPS print data once the data is obtained. In doing so, module524can retrieve policy information which defines a content-filtering policy, a security policy and a storage location policy for the XPS document. Module524can retrieve the policy information from a policy server (e.g., enterprise policy512) and/or a key store server (e.g., key516). Key store server516can contain encryption and decryption keys to encrypt and decrypt the XPS document.

In this regard, module524can include module526for despooling the XPS data, module528for generating the XPS document, module530for XML encryption and module532for performing unified authentication. Print server518can perform content filtering with XML canonicalization and XML encryption. In the example ofFIG. 5, the encryption policy can be from a local policy server (e.g., local policy510) and/or a central policy server (e.g., enterprise policy512).

Thus, before the XPS data is sent to printer514, if a user (e.g., via UI522) selects to save data or portions of the data to specific storage systems (e.g., local storage544), print server518can process the XPS data. UI522or a remote UI can provide interfaces for allowing a user to select a specific storage system, and to define specific content filtering rules to encrypt specific content for privacy. For example, driver UI522can contain the user interface to allow the user to set policy for filtering content, encryption key location, storage location and authentication information.

The XPS data can be processed based on the cloud service and/or policy instructions given, to perform content filtering and extraction, and to apply security (e.g., encryption, digital signature) to the data. In this regard, the data may be encrypted with the user's public key so that only the user can decrypt the data.

In the example ofFIG. 5, the enterprise content filtering policy and the encryption policy can be retrieved with storage location and authentication information. In addition, it is possible for a second encryption policy to be retrieved.

As noted above, print server518can send the XPS data (or XPS data converted to PCL data) to printer514, and can process the XPS data based on policy information retrieved from a policy server (e.g., enterprise policy512). In addition, the processed data can be sent to custom port monitor534for storage to designated locations. Thus, print server518can generate a new set of documents, which can correspond to portions of the document with different types of formatting based on the document type supported in the cloud, to the designated locations via custom port monitor534. In this regard, custom port monitor534can be used to direct print and storage data to designated locations. Custom port monitor534can include WSD, TCP/IP, virtual and default port monitors. As noted above, for authentication with different storage systems, print server518may have a module (e.g., module532) to perform authentication with the different storage systems.

The storage repository can be a public or private cloud storage system. In addition, the storage repository can correspond to enterprise storage (e.g., local storage544), storage of an image within a cloud, Google Docs or Window Web Office. In the example ofFIG. 5, designated portions of the XPS document are referenced by numeral536, new PDF data is referenced by numeral538, image data is referenced by numeral540, and extracted data is referenced by numeral542. Cloud548can correspond to a public cloud or a private cloud.

It should further be noted that when the user retrieves the document from storage, it is typically necessary to decrypt those portions of the document data which were subject to encryption. In this regard, the architecture illustrated inFIG. 5can also be used for decrypting the document data.

FIG. 6is a block diagram depicting content extraction and new document creation according to example embodiments. In particular,FIG. 6illustrates example flows for extracting and generating new documents for Google Docs, Microsoft Office Web storage and a service portal (e.g., a Canon service portal) while a user prints a Microsoft Office document. For an XPS document600, policy can be obtained at block602, a UI can be displayed at block604, and policy can be updated at block606using a cloud608.

Line1(shown in the legend ofFIG. 6) can represent normal and generic flow for printing data. In this regard, if an XPS document is to be processed for extraction at decision diamond610, XPS data can be loaded at block612, XML canonicalization (abbreviated C14n) and extraction can performed at block614, and image data extraction can be performed at block630. However, if the answer to the inquiry at decision diamond610is ‘no’, the data638can be sent to a printer/scanner646.

Furthermore, if the document is not XML based at decision diamond616, a further inquiry is made whether the document is a PDF document at decision diamond622. In addition, after image data extraction at block630, if the document data is not metadata only at decision diamond632, a further inquiry is made whether to reduce size of the document at decision diamond634. If the answer is ‘yes’, data conversion is performed at block636.

Regarding Line2, this line can represent Microsoft cloud storage (if applicable) with a native XPS format to be supported. If the document is XML based at decision diamond616, the data640can be sent to the cloud. If the document data is metadata only at decision diamond632, the data640can also be sent to the cloud. In addition, if the data size is to be reduced at decision diamond634, data conversion at block636can occur before the data640is sent to the cloud.

Regarding Line3, this line can represent that Google Docs storage and XPS/XML or PDF is selected. If the document is XML based at decision diamond616, a further inquiry at decision diamond618can be made whether privacy is to be used. If the answer to this inquiry is ‘yes’, XML encryption can be performed at block620before the data642is sent to the cloud. If the document is PDF based at decision diamond622, XML to PDF conversion can be performed at block624, and a further inquiry at decision diamond626can be made whether privacy is to be used. If the answer to this inquiry is ‘yes’, PDF encryption can be performed at block628before the data644is sent to the cloud.

If the document data is metadata only at decision diamond632, flow can pass to block624for XML to PDF conversion, to decision diamond618for inquiring whether privacy is to be used, and the data644can be sent to the cloud. Furthermore, if the data size is to be reduced at decision diamond634, data conversion at block636can occur before PDF encryption at block628, and the data644can be sent to the cloud.

Regarding Line4, this line can represent a cloud service where image extraction and image recognition are performed in the cloud. Authentication and authorization for account information can be provided to decision diamond616, in determining whether the document is XML based. In addition, if the document is metadata only at decision diamond632, the data642can be sent to the cloud. Furthermore, if the data size is to be reduced at decision diamond634, data conversion at block636can occur before the data642is sent to the cloud.

Regarding privacy, there are a variety of use cases and methods to create and setup policy information for determining if privacy should be enforced in the document. In a cloud type setup, data stored in the public is more likely to require privacy enforcement, data stored in the enterprise may require privacy depending on company policy, and data stored locally may require privacy depending on future usage.

For availability of storage size, the use of privacy may depend on the user account and the cloud storage usage policy. Other factors may be considered for enterprise and local networks. For document size, the use of privacy may depend on encryption algorithm and key size.

The purpose of saving the print data can also be considered in determining whether to use privacy. For indexing, a small amount of data is typically recorded, and a generic XML document can be sufficient. In addition, the use of privacy can depend on whether storage will be for the entire image, compressed image, reduced image or just image metadata. Other factors may also be considered for auditing.

The document security level can also be considered in determining whether to use privacy. For high security documents, the entirety of the data may need to be encrypted before being stored. For medium security, it is possible that only portions of the document should be encrypted. For low security, it is possible that only selective data needs to be encrypted.

In addition, some types of text strings should be encrypted, including credit card numbers, bank account numbers and social security numbers. Furthermore, specific image data such as a driver's license image and credit card image should be encrypted.

FIG. 7is a class diagram for the relationship between XML canonicalization classes according to an example embodiment. In the example ofFIG. 7, the classes can perform XML canonicalization for a given XML document after the XPS document is parsed by an XPS reader. As can be seen inFIG. 7, the classes can include, but are not limited to XmlWriterHandlerBase700, ITransform702, XmlCanonicalization704, XmlCanonicalizationExC14706and XmlCanonicalizationC14708.

FIG. 8is a class diagram for supporting XML digital signature for outgoing and incoming XML messages using a provided security token according to an example embodiment. In the example ofFIG. 8, an XPS document may be signed with a secure token. This class diagram can correspond to a WS-Security Library class diagram that supports XML digital signature for outgoing and incoming XML messages using a provided security token. The WS-Security Library can implement IMessageSignature:IMessageSecurity interface via the MessageSignature class. The MessageSignature implementation can provide means for signing and verifying Simple Object Access Protocol (SOAP) message signature.

FIG. 9is a class diagram for supporting SOAP message encryption for outgoing and incoming SOAP messages using a provided security token according to an example embodiment. In the example ofFIG. 9, for supporting privacy, the XML/XPS data may be encrypted by an encryption token.FIG. 9illustrates an example of a WS-Security Library class that can implement IMessageCypher:IMessageSecurity interface via the EncryptedData class. The EncryptedData implementation can provide means for encrypting and decrypting a SOAP message directly via the ISecurityToken provided key or an EncryptedKey.

As can be seen inFIG. 9, the classes can include, but are not limited to security::IMessageCipher900, cipher::CipherData902, cipher::EncryptedData904, cipher::EncryptedKey906and cipher::EncryptionMethod908.

FIG. 10is a sequence diagram depicting content extraction and encryption for an XPS document to a partial XPS document creation according to an example embodiment.FIG. 10illustrates a sequence of steps performed on print data1000, by XPS reader module1002, XML reader module1004, XML C14N (canonicalization) module1006, XML content filtering module1008, XPS writer module1010, XML writer module1012, XML signature module1014, XML encryption module1016and storage module1018.

The sequence depicted inFIG. 10starts with receiving print data1000and sending it to XPS reader module1002(step1020). XPS reader module1002utilizes XML reader module1004for processing the XML data within the document (step1022). XML reader module1004utilizes XML C14N module1006to help process the XML data (step1024). The canonicalized XML is returned in step1026. XML reader module1004then uses XML signature module1014to provide digital signature support (step1028). The XML data is returned in step1030. The XML data is passed to XML content filtering module1008for extraction processing (step1032). XML content filtering module1008utilizes XPS writer module1010(step1034), which uses XML writer module1012(step1036) for creating partial XPS documents. Based on policy, XML writer module1012utilizes XML signature module1014and XML encryption module1016to secure the content in steps1038and1040. The secured content is returned in steps1042and1046. The processed XML is returned to XPS writer module1010in step1048. XPS writer module1010then sends the partial XPS document to storage1018(step1050). Confirmation is returned in steps1052,1054,1056, and1058.

FIG. 11is a block diagram depicting the path taken by printer data from the print processor to a printer and cloud storage via a custom port monitor according to an example embodiment. For example, the path illustrated inFIG. 11can apply toFIG. 4, and can apply toFIG. 5with minor changes.

Print processor1100can include a Cloud Service Data Processing (CSDP) library. XPS data1104and new document data1106can pass through an optional language monitor1102to a custom port monitor1108. Custom port monitor1108can correspond to the custom port monitors424and534inFIGS. 1 and 2, respectively. The XPS data can be sent to a port driver1110, and then to a printer/scanner1114. In addition, the new document data can be sent to cloud storage1116.

FIG. 12is a block diagram depicting an XPS printing system according to an example embodiment. In this regard, the XPS print path is a Windows feature that typically defines how printing is handled in Windows applications. Because XPS can replace a document presentation language such as RTF, a print spooler format such as WMF, and a page description language such as PCL or Postscript, this XPS print path maintains the XPS format from application publication to the final processing in the printer driver or device.

Win32 Application1200outputs GDI data which can proceed to Enhanced Metafile (EMF)1206spooler followed by the GDI/Device Driver Interface (DDI) Driver1212and finally to the Printer Description Language (PDL)-based Device1216. The WPF Application1202outputs XPS data which can proceed to XPS1210spooler followed by the XPSDry Driver1214and finally to either the XPS Document-based Device1218or the PDL-based Device1216. The GDI data from Win32 Application1200can alternatively follow the XPS print path through conversion to XPS data at GDI to XPS Conversion1208. The XPS data from WPF Application1202can alternatively follow the GDI print path through conversion to GDI data at XPS to GDI Conversion1204.

FIG. 13is a flow diagram illustrating generating and storing a markup language document within a network according to an example embodiment. The network can include a client and one or more storage locations. The one or more storage locations can correspond to one or more storage servers. The markup language document can be an XPS document. It should be noted that although a markup language document is described with reference to this diagram, it is possible to instead use a PDF document.

It should be noted that while process steps1302to1312are depicted sequentially, it is possible for at least two of these steps to be performed in parallel. Following start bubble1300, a markup language document is generated at block1302. Policy information is accessed at block1304, wherein the policy information defines a content-filtering policy, a security policy and a storage location policy for the markup language document. The network can be an enterprise network, and the content-filtering and security policies can apply enterprise-wide. In addition, the network can further include a policy server, and the policy server can be accessed to obtain the policy information. Furthermore, a user interface can be displayed for allowing a user to adjust the policy information.

A portion of the markup language document that is subject to security is determined, based on the content-filtering policy as defined in the policy information at block1306. At block1308, a storage location is identified for storage of the markup language document from among the one or more storage locations, based on the storage location policy as defined in the policy information.

Security is applied to the determined portion of the markup language document based on the security policy as defined in the policy information at block1310. The security policy can correspond to at least one of an encryption policy and a signing policy, and the security can be applied by respectively performing at least one of encryption and signing to the determined portion. The security can be applied to the determined portion of the markup language document with both user and administrator encryption keys, based on the security policy as defined in the policy information.

The markup language document is stored on the identified storage location at block1312, and the process ends at end bubble1314. I should be noted that the policy information can further define authentication information for the markup language document, and the authentication information as defined in the policy information, together with the markup language document, can be stored on the identified storage location.

The markup language document can correspond to an image document service portal, so that data within the markup language document is processed and returned to the client for reassembly and reformulation of the markup language document. The client can comprise a driver (e.g., a printer driver or a scanner driver), and the driver can perform the generating, accessing, determining, identifying, applying and storing.

The network can further include a rendering server and a policy server from which the policy information is accessed, and the driver can forward the markup language document to the rendering server for performing the generating, accessing, determining, identifying, applying and storing. The policy server and the rendering server can be implemented on a common machine within the network. Alternatively, the policy server and the rendering server can be implemented on different machines that communicate over the network.

Accordingly, the example embodiments described above can address the problems associated with utilizing the cloud infrastructure to allow a user to store print or scan data. One such problem is selectively storing print data for different types of cloud storage systems based on the cloud service document type (which may be associated with a user account), available storage size and document format supported to perform content extraction. Examples associated with this include the PDF document type, the XPS document type, the image data type, enterprise storage and local storage.

For PDF documents (e.g., Google Docs service), privacy should be enforced. A variety of document formats are supported based on the use account type and uploading files of any type without converting to an internal format of Google. The example embodiments described above can allow a user to selectively store data of interest with privacy protection and proper format during printing a document.

For XPS documents (e.g., Microsoft Office Web App), privacy should also be enforced. With availability of the web-based version of Microsoft Office, and since XPS is a Microsoft standard document format, it is possible that native XPS document uploading service will be supported by Microsoft-based cloud service.

For image data, (e.g., cloud service portal), privacy should be enforced. For an image-based service type of cloud service storage system, the data to be stored should relate to image file formats, and the stored image can be a lossy compressed image or just image metadata. As such, the example embodiments described above can be used in association with related services (e.g., image compression, extraction, blending, recognition, sorting and searching) for printing.

For enterprise storage, privacy can also be enforced. Based on enterprise security policy, auditing policy and storage capabilities, different types of data formats may be stored with multiple encryption schemes, and both user and enterprise administrator encryption keys can be considered.

For local storage, privacy can be provided for future usage. This can help a user track and analyze print data, and encryption for privacy can be enforced for downloading to a storage system at a later stage. When print data is extracted to a storage system, there can be a different policy applied to the data extraction with different secure levels.

Thus, the above described embodiments can provide for a more seamless storing of different types of data based on the cloud storage type with reduced user and enterprise administrator intervention. An end-to-end solution from printer driver to cloud storage system can be provided for a multiple cloud storage system. Furthermore, privacy can be enforced for data stored in the public cloud system. It is also possible for effective searching and retrieval with accountability and availability on the data that has been printed to be achieved.

Privacy can be enforced such that only the user that owns the decryption key can see confidential data. If an unrelated user obtains the document, the unprotected content can be viewed with standard XPS viewer application, but it is possible for the confidential data to not be seen.

Usability and availability can also be improved in view of the example embodiments described above. A more convenient method is seen to be provided for enterprise and user to audit the print data. Indexing, searching and filtering data with a public storage system with privacy can be facilitated for the user and the organization. Improved integration with existing enterprise system configurations and local user systems is made possible, with reduced user intervention. In addition, content comparison and processing can be done with various configurations.

Multiple encryption schemes can also be provided. For the enterprise and centralized environment, the document can be encrypted with a first user encryption key with a first user local policy, and again encrypted with an enterprise policy with an enterprise encryption key.

Regarding accountability, since it is possible to encrypt the confidential information and not the entire document, and to extract parts of data from the document, data size can be confined while maintaining necessary privacy. In addition, it is possible that the data can be reviewed by a standard XPS viewer (e.g., Window Office Web).

Regarding flexibility, the example embodiments described above can allow for a user to record portions of the document with selected portions of document encrypted, with desired formats based on the cloud document service provided. In other words, the user can record just a few keywords or information that is useful in the future.

Regarding compatibility, the example embodiments described above can support Google docs and Windows Web Office. The XPS document can correspond to zipped XML data. Google typically supports ZIP archive, and this can contain the images (if any) used in the document and an exported .html file. In addition, Google typically supports regular and hosted account types. With the above described embodiments, a user or organization can customize their Google environment to store printed data. In addition, a user can create PDF format data which Google supports as a native document format.

This disclosure has provided a detailed description with respect to particular representative embodiments. It is understood that the scope of the appended claims is not limited to the above-described embodiments and that various changes and modifications may be made without departing from the scope of the claims.