METHODS AND APPARATUS FOR DOCUMENT CREATION VIA EMAIL

Info

Publication number: 20160087929
Type: Application
Filed: Sep 22, 2015
Publication Date: Mar 24, 2016
Inventors: Sridhar Vembu (Pleasanton, CA), Vijay Sundaram (Saratoga, CA), Karthikeyan Jambulingam (Chennai), Sudheer A Grandhi (Pleasanton, CA)
Application Number: 14/861,160

Abstract

A system and method for creating a document in a messaging environment is described. A communication including a document specification including zero or more formatting commands and content is received from a sender and processed. The system and method determine whether the document specification is in a done condition, and iterates until done. A formatted document is also created and returned to the sender and recipients.

Description

Description

FIELD OF THE INVENTION

The present disclosure relates generally to document creation, and more particularly to methods and systems for creating electronic documents using simple commands.

BACKGROUND

Electronic documents are typically created in special purpose applications that enable a user to view content and formatting while creating and modifying a document. Exemplary applications include those for creating presentations, e.g., Zoho Show available from Zoho Private Corporation Limited and Microsoft PowerPoint, text documents, e.g., Zoho Docs and Microsoft Word, spreadsheets, e.g., Zoho Sheet and Microsoft Excel, and drawings and charts, e.g., Microsoft Visio. Special purpose applications may be hosted, e.g., Zoho, Google, or installed locally on a computing device, e.g., Microsoft, and are typically used on devices having screens large enough to view the formatted content, e.g., conventional desktop and laptop computers, and large screen tablet devices.

These applications may also facilitate a collaborative workflow, e.g., document sharing and editing. Collaboration enables teams to share editing responsibilities and contribute creative content to, e.g., documents and presentations directed to marketing and selling products and services. To enable collaborative activity, the user typically administers and manages user credentials and access privileges for each document so that a collaborator may access and, if granted requisite access permissions, modify a document. Although special purpose applications are powerful, near-ubiquitous, and widely adopted, successfully creating documents and collaborating on small screen-devices in fast-moving, “on-the-go” environments remains challenging.

BRIEF DESCRIPTION OF THE DRAWINGS

The subject matter presented herein is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings, in which like reference numerals refer to similar elements and in which:

FIG. 1 depicts a system for producing a document in accordance with one embodiment;

FIG. 2 is a flowchart depicting a computer-implemented method for producing a document in accordance with one embodiment;

FIG. 3 depicts exemplary formatting commands for producing a document in accordance with one embodiment;

FIG. 4 depicts exemplary formatting commands for producing a document in accordance with another embodiment;

FIG. 5 depicts exemplary formatting commands for producing a document in accordance with still another embodiment;

FIG. 6 depicts a data structure for assigning document access privileges in one embodiment; and

FIG. 7 depicts a suitable prior art computing environment in which the invention may be implemented.

DETAILED DESCRIPTION

FIG. 1 depicts a system 100 for producing a document in accordance with one embodiment. Exemplary documents include presentation slides, formatted text documents, spreadsheets, multimedia presentations, diagrams, and flow charts. Exemplary devices include laptop computer 115, wireless handheld mobile device 120, and wireless handheld tablet 125. Some devices, e.g., a mobile digital device such as an iPhone® available from Apple, Inc. of Cupertino, California, may be characterized as small-screen devices. These devices are employed by one or more users, e.g., user 105, to create a formatted document using simple commands. For example, user 105, desiring to create slides for a presentation, enters a document specification comprising formatting commands and content, e.g., as depicted on device 120 in FIG. 1. Device 120, in this example, a small-screen wireless handheld device, transmits a message, also referred to as a communication, including the document specification to a messaging server 170, and including a list of zero or more recipients with whom user 105, a sender, desires to collaborate.

Messaging server 170 includes messaging service 185 that receives the communication and forwards it to document service 155, included in document server 140. Messaging server 170 receives the communication in a number of formats capable of expressing a specification textually, e.g., plain text or HTML, including, e.g., email, SMS, and text message in accordance with one embodiment. Service 155 parses the message, applies the commands to the content, and produces and saves a formatted document, here, slides for a presentation document. Service 155 produces the document on a best-effort basis. Accordingly, a document may be created in the presence of one or more document specification errors, including fatal errors, and may be created as a partially formatted or blank document. Service 155 determines whether the document specification is in a “done” condition. If the specification is not in a “done” condition, document service 155 revises it, transmits it to the sender, e.g., user 105, and iterates until the specification is in a “done” condition. A specification is in a “done” condition when it includes no errors, or when it includes an express command, e.g., “!!!” indicating done. Document service 155 stamps the specification with a version indicator in one embodiment. “Stamping” the document specification includes including the version indicator in the specification, or in a separate message or associating the indicator with the specification separately, e.g., in a database or a computer file. In revising the document specification, document service 155 identifies errors, thereby advantageously enabling the sender to make corrections. Document service 155 introduces suggestions for improvements in formatting, e.g., font size, type, location, image sizing and location, into the specification it returns to the sender in accordance with another embodiment. Notably, a “done” condition expressed in a command, e.g., “!!!” unconditionally terminates iteration, even if the document specification includes errors.

Service 155 also establishes user accounts and document access privileges for user 105 and the recipients, and transmits the document to user 105 and the zero or more recipients. User 105 has thus created slides for a presentation using simple text commands in a messaging environment, established collaboration with the recipients, and did so on a small-screen wireless handheld mobile device.

Document and messaging servers 140 and 170 respectively comprise document and messaging services (155, 185), memory (145, 175), processor (150, 180), and storage (160, 190), in one embodiment. Messaging service 185 receives email, and associates messages it receives at certain addresses, e.g., create@zohoshow.com, user007@zohoshow.com, with document creation. It forwards these messages to document service 155, which creates and modifies a document based on the message, and manages user access to the document. In another embodiment, messaging service 185 receives messages via other protocols, e.g., short message service (“SMS”), and forwards them to document service 155. In another embodiment, document server 140 receives messages directly.

FIG. 2 is a flowchart depicting a computer-implemented method for producing a document in accordance with one embodiment. At step 205, the method receives a communication, e.g., to document service 155 or messaging service 185, including a first communication from a sender, including a first sender, the message identifying zero or more recipients. In one embodiment, the method receives the first communication via text message, SMS, or email. The sender and zero or more recipients may be identified by, e.g., an email or SMS address. The communication includes a document specification including zero or more formatting commands and content. A formatting command determines how content will appear in a document, e.g., created or modified by, e.g., document service 155. In one embodiment, the formatting commands and content are comprised of plain text. In another embodiment, the formatting commands and content are comprised of hypertext markup language (HTML).

The method next determines, in step 210, whether the document is new. In one embodiment, the communication includes a link to an existing document, and no link if the document is new. In another embodiment, the communication includes a document identifier, e.g., a document name or I.D. If the method at step 210 determines the document is new, it names and creates a document, creates access permissions to the document for the sender and zero or more recipients, thereby enabling collaboration, and branches to step 235 for further processing, described below. In one embodiment, access permissions include creating a user account and password corresponding to a messaging, e.g., email, address for the sender if a user account does not yet exist. If the method, in step 210, determines the document is not new, it branches to step 220 and compares the document's access permissions to the sender and recipients identified in the communication. If the access permissions prohibit the sender from modifying the document, the method rejects the communication at step 230, branches to step 295, and is done. If modification is not prohibited, then processing continues at step 235.

The method at step 235 parses the communication, applies the formatting commands to the content, and produces a document, e.g., via document service 155. “Produces” includes creating and modifying a document. Notably, if the document specification includes fatal errors, as might occur in the case of an unconditional done command (“!!!”), document service 155 creates a document on a best-effort basis, even if the document it creates is blank. Details relating to applying formatting commands to content are described with respect to FIGS. 3-5 below. The method stores the document, e.g., in data store 160, at step 240, and at step 245, transmits information for accessing the document to the sender and to the zero or more recipients. The method transmits a copy of the document specification used in creating the document in one embodiment. The method stamps the specification with a version indicator in accordance with one embodiment. The version indicator relating to the document specification is tracked and maintained along with a mapping to the corresponding document version. “Transmits” includes transmitting information for accessing the document to the first sender and to zero or more recipients, transmitting the document itself, e.g., via attachment to, e.g., an email, SMS, or text message, or transmitting a message including a link to a document, e.g., a uniform resource locator (URL) or other link identifying a location, e.g., data store 160, corresponding to the document. Information for accessing the document includes the document or a link identifying its location, account information, e.g., user name, password, and information identifying the document, e.g., a document I.D. or name.

At step 250, the method determines whether the document specification is in a “done” condition. A document specification is “done” if expressly so indicated in an “unconditional done” command, e.g., “!!!” or if the specification contains no errors. A specification error is one that cannot be corrected by document service 155, e.g., as in the case of an erroneous command. An erroneous command includes, e.g., a misspelling, an erroneous parameter, or the non-existence of any formatting command. If the document specification is not in a “done” condition, the method transitions to step 255, revises the document specification and transmits it to the sender. In revising the document specification, the method identifies errors and suggests corrections, thereby advantageously enabling the sender to produce an error-free specification. For example, if the method detects an error comprising a non-existence of any formatting command, e.g., the document specification is blank, it creates and transmits to the sender a specification including, e.g., formatting rules or instructions for creating a document. This enables a user, e.g., the sender, to conveniently obtain formatting instructions, simply by transmitting a blank message to, e.g., document service 155. In another embodiment, the method returns a text-based template including formatting commands and content placeholders. In another embodiment, the method creates and transmits a specification, applying as many formatting commands as are correct, and including error messages pertaining to erroneous formatting commands. In another embodiment, the method attempts to correct and apply erroneous formatting commands. Notably, in the case of a blank specification, “applying zero or more formatting commands” implies creating a blank document and transmitting to the sender a specification, e.g., one containing instructions explaining how to create a document specification. The method also introduces suggestions for improvements in formatting, e.g., font size, type, location, image sizing and location, thereby advantageously assisting the user to produce an aesthetically pleasing document. In one embodiment, the method stamps the specification with a version indicator. The method iterates until the document specification includes no errors, or includes an unconditional “done” command, e.g., “!!!”. Upon detecting a “done” condition in the document specification, the method at step 250 transitions to step 295, and is done.

FIG. 3 depicts exemplary formatting commands and content, and a document including two presentation slides produced by applying the formatting commands to the content in accordance with one embodiment. In one embodiment, a message 310 is processed by document service 155. Message 310 includes formatting commands and content including directives 311-314 for structuring and stylizing a document 340 having two presentation slides, and first and second sets of document specifications 320 and 330, corresponding to first and second presentation slides 350 and 360. For simplicity, message 310 depicts only formatting commands and content, and omits sender and recipient identities, and other information, e.g., document identifying information. In one embodiment, formatting commands and content comprise a single item, e.g., content only, or formatting only. In another embodiment, formatting commands and content comprise zero items, e.g., blank.

Directives 311 and 314, “**” (double asterisk), signal respectively a beginning and ending point of formatting commands and content. A directive, “##” (double pound), followed by a parameter or keyword, specifies an overall style for the document. In one embodiment, the “##” directive also serves to select a document type. For example, “## ZDocsOutline” specifies a text formatted document, e.g., Zoho Docs or Microsoft Word formatting, using an outline style. Here, directive 312, “## Arrows,” specifies the document type is presentation slides, and a style entitled “Arrows” will be applied to slides 350 and 360. For example, in first slide 350, style “Arrows” includes a centered title, “W. A. Mozart,” a separator bar at a specified distance between the title, and bullet points introduced by an arrow “>” character. In one embodiment, default font, size, spacing, and a background image or color are specified in the style. In the absence of a style directive, e.g., “##” is omitted, a default style is applied in one embodiment. In FIG. 5, for example, no “##” has been specified in message 510. The resultant slides 560-580 are stylized in a default format in which a solid circle introduces bullet points rather than the arrow “>” depicted in slides 350 and 360. Directive 313 “*” (single asterisk) signals the beginning of the second document specification 330 corresponding to second slide 360.

The first document specification 320 includes formatting commands and content corresponding to slide 350. A directive “#” (single pound) followed by text (formatting command and content) specifies a slide title. Here, “#W. A. Mozart” 321 titles slide 350 as “W. A. Mozart.” As explained above, style “Arrows” specified in directive 312 centers the title and adds a separator bar beneath the title. Directive “-” (single hyphen) followed by text specifies a first level bullet. Here, “-(1756-1791)” 322 places a first level bullet beneath the separator bar in slide 350. The bullet is introduced by “>” in accordance with the “Arrows” style specified in directive 312. A second, first level bullet “-Select Works:” is specified in directive 323, and is placed next in sequence in slide 350. Directive “--” (double hyphen) followed by text specifies a second level bullet, right-indented relative to a first level bullet. Here, a second level bullet specified by “--The Magic Flute” 324 is placed on slide 350, in sequence below and indented to the right of “Select Works” specified in directive 323. A second, second level bullet, “--Rondo alla Turca,” appears next in sequence on slide 350. In another embodiment, third and subsequent bullet levels may be specified respectively by triple and subsequent hyphens, e.g., “---” (triple hyphen), and “----” (quadruple hyphen). In another embodiment, a bullet level may be indented to the right relative to a preceding bullet level, and font specifications relating to a bullet level may differ per level.

Slide 360 is produced by directives 331-335 of second document specification 330, just as directives 321-325 of first document specification 320 produced slide 350. An additional directive at 336 adds a parenthetical “(unrelated to Mozart's Rondo)” in sequence beneath second level bullet “>Blue Rondo ala Turk” in slide 350. Notably, the directive at 336 is blank, i.e., only slide text is specified. In the embodiment depicted in FIG. 3, the blank directive adopts the formatting of the directive it follows (here, the second level bullet specified in directive 335), omits the introducing arrow “>”, and decreases font size. In another embodiment, the blank directive left justifies its text relative to the slide and applies a font format specified in the style, e.g., “Arrows” or the default style.

FIG. 4 depicts exemplary formatting commands for producing a document including a flow chart in accordance with another embodiment. In one embodiment, a message 410, including formatting and content for producing a flow chart 420, is processed by document service 155. Directive 401 begins with “!” (exclamation point, or “bang” character) introducing a flow chart. Formatting commands and content (directives and related text) following the bang “!” specifying elements, e.g., blocks and decision points of the flow chart, are enclosed in parentheses. Parenthesized directives and text are delimited by “->” (hyphen-arrow combination) in one embodiment. Parenthesized directives and text are connected with a direction indication, denoted by “->” (hyphen-arrow combination) in accordance with another embodiment. Intra-directives are delimited by “|” (vertical bar, or “pipe” character), e.g., as in the decision directive depicted in directive 404, in another embodiment. Directives need not, but may, be written as separate lines. For example, the “!” that begins directive 401 may appear on a line by itself. Moreover, directives 401-406 and related delimiters, although depicted as separate lines for clarity of description, may be concatenated.

The parenthetical section of directive 401, “(Block 0: Start)” specifies a beginning block “Start” of flow chart 420, stylized as a rounded-corner rectangle. Directives 402 “(Block 1: Step 1)” and 403 “(Block 2: Step 2)” follow, resulting in blocks “Step 1” and “Step 2” connected by an arrow extending respectively from Start to Step 1, and Step 1 to Step 2, in flow chart 420, each block stylized as a squared-corner rectangle. A decision block is specified in directive 404. Directive “(Decision 1: Test 1)” causes a decision symbol (a rhombus, vertically oriented along one diagonal) “Test 1” to appear in flow chart 420 below “Step 2” connected by an arrow extending from Step 2 to Test 1. Following delimiter “|”, a branch specified by “Yes: Go to Block 1” causes an arrow to extend from decision block “Test 1” to “Step 1” as depicted in flowchart 420. Continuing, a branch specified by “No: Continue” causes an arrow to extend from decision block “Test 1” to a subsequent block, “Step 3,” specified in directive 405. In one embodiment, decision 1 causes “YES” and “NO” labels to appear adjacent to the arrows corresponding to its “YES” and “NO” branches. In another embodiment, the labels appear respectively as “Y” and “N.” Directive 406 “(Block 4: End)” specifies an ending block “End” of flow chart 420, stylized as a rounded-corner rectangle, and an arrow extending from block “Step 3” to “End.” Document specification 415 may specify one or more portions of a document, and may be combined with any other formatting commands and content in a document.

FIG. 5 depicts exemplary formatting commands for producing a document 550 including succinct and details modes of a document in accordance with still another embodiment. In one embodiment, a message 510 is processed by document service 155. Message 510 includes formatting commands and content including directives 511-514 for structuring and stylizing a document 550 having three presentation slides, and first, second, and third sets of document specifications 520-540, corresponding to first, second, and third presentation slides 560-580. For simplicity, message 510 depicts only formatting commands and content, and omits sender and recipient identities, and other information, e.g., document identifying information. In one embodiment, formatting commands and content comprise a single item. In a further embodiment, formatting commands and content comprise zero items, e.g., blank.

Document specifications 520 and 530 cause slides 560 and 570 to be produced in the same way, described in FIG. 3 above, as specifications 320 and 330 cause slides 350 and 360 to be produced, with one difference. As explained with respect to FIG. 3, directive 312 (“## Arrows”) applies style “Arrows” to document 340 such that bullet points on slides 350-360 are introduced by an arrow character “>”, whereas the absence of a style (“##”) directive in specification 520 applies a default style to slides 560-580. As depicted in FIG. 5, bullet points in slides 560-580 are introduced by a solid circle rather than the arrow “>” appearing in slides 350-360.

Some presenters find it useful to have notes along with or among presentation slides. Notes may contain background, factual, and other information allowing a presenter to, e.g., relate anecdotes, respond to audience questions, and in general, deliver a presentation more conversationally than might be possible without notes. In one embodiment, a detailed slide, e.g., slide 580, includes a notes portion and an audience portion, the audience portion including information from another presentation slide. A directive “*̂ ” (asterisk-caret) signals a new slide having content copied from a preceding document specification, corresponding to a preceding slide. In one embodiment, the new slide is designated “detailed,” and the slide from which the content is copied is designated “succinct.” The detailed slide includes an audience portion (content corresponding to the succinct slide) and a notes portion.

Directive 513 “*̂ ” (asterisk-caret) signals a new detailed slide 580 based on a succinct slide 570. In response to directive 513, document service 155 creates a new detailed slide 580 having an upper (audience) portion and a (lower) notes portion. Service 155 copies content from document specification 530 corresponding to succinct slide 570 into the upper portion. In one embodiment, formatting prescribed in specification 530 and a style, e.g., “Arrows” as specified in directive 312 of FIG. 3, or a default format as here, is applied to the audience portion, and font sizing and spacing between elements are reduced, as depicted in slide 580, to make room for the notes portion. Service 155 also places a separator, e.g., a dashed bar as depicted in slide 580, between the audience and notes portions. In another embodiment, the separator is a solid bar. In one embodiment, font sizing and element spacing are reduced corresponding to a number of notes, e.g., three (3) notes results in 20% reduction, and e.g., seven (7) notes results in a 50% reduction. Service 155 determines an amount of reduction based on initial font sizes and spacing in one embodiment.

Directive 541 is blank, i.e., only notes text is specified. Thus, notes 1, 2, and 3 at directive 541 appear in the notes portion of slide 580. In one embodiment, document service 155 automatically adds an additional slide (not shown) if it determines one would be appropriate. For example, if a number of notes becomes so large that reductions in font size and spacing would render a slide “unreadable,” e.g., font size and spacing less than, e.g., 10 pt., then service 155 adds a page to hold additional notes. In one embodiment, the additional page includes audience and notes portions. In another embodiment, the additional page includes only a notes portion. Directive 514 “**” (double asterisks) signals the end of formatting commands and comment, corresponding to the end of document 550.

FIG. 6 depicts a data structure for assigning document access privileges in one embodiment. The data structure is used by document service 155 to create and maintain user access permissions, thereby enabling user 105 to conveniently include collaborators in creating and modifying a document. Document service 155 receives a communication 610 specifying a sender and zero or more recipients respectively corresponding to zero or more collaborators identified in one or more address fields, e.g., “To:,” “Cc:,” and “Bcc:” of the communication, the one or more address fields corresponding to one or more document access privileges. In one embodiment, message 610 is an email directed to a dedicated recipient 612, create@zohoshow.com, identified in the “To:” header field of the message. Dedicated recipient 612 is used, e.g., to direct message 610 to document service 155. In one embodiment, dedicated recipient 612 distinguishes the document type to be created. For example, a message directed to create@zohoshow.com signifies presentation slides, and a message directed to create@zohoshow.com signifies creation of a formatted text document compatible with, e.g., Microsoft Word or Zoho Docs. In another embodiment, the document type to be created is distinguished within the message body, e.g., as described with respect to directive 312 above.

Returning to message 610, a sender 611, user001@gmail.com, is identified in the “From:” header field of message 610. Additional recipients, identified in either the “To:”, “Cc:” or “Bcc:” fields, signify collaborators. If the document is new, e.g., message 610 does not include a document I.D. or name, service 155 creates a document I.D., MozartSlides.001, assigns a location, http://zohoshare.com/user001, and enters them in document table 640. Service 155 creates permissions table 650 corresponding to document I.D. MozartSlides.001, enters sender 611 (here, a first sender) user001@gmail.com and a flag “O” designating sender 611 as the owner of the document. An owner inherently has authority to modify permissions table 650, and read/write (“W”) permissions to the document, here, MozartSlides.001.

In one embodiment, if the first sender does not have a user account, document server 155 creates one, e.g., user001@zohoshow.com, and a password. Service 155 may transmit a welcome message including account identity and password, to the first sender upon account creation in one embodiment. In another embodiment, a welcome message is included in a message relating to document creation. Advantageously, a sender may transmit a communication that includes a document specification to any of, e.g., create@zohoshow.com (to implicitly create a slideshow), createdocs@zohoshow.com (to implicitly create a formatted text document), or to the sender's account, e.g., user001@zohoshow.com, to create a document expressly identified in the document specification. Notably, irrespective of the account to which a document specification is directed, an express directive in a document specification to create or modify a particular document type overrides a type implied by a dedicated account such as createdocs@zoho.com. For example, user001@gmail.com transmits a communication that includes a document specification containing a directive to create a formatted text document to create@zohoshow.com. Even thoughc create@zohoshow.com will create, by default, a slide show, the express directive to create a formatted text document in user001's communication overrides the default (implied slideshow creation), and document service 155 will create a formatted text document as expressly directed in user001's document specification. In another embodiment, document service 155 creates an account for a new user on messaging server 175, e.g., user888@zohomail.com, and recognizes that address for creating documents. Thus, the new user, e.g., user008@yahoo.com, may send a message to user888@zohomail.com to create and modify a document. Document service 155 therefore supports a plurality of user accounts, and processes messages for a plurality of document types in the user accounts.

Service 155 identifies recipient 613, user002@yahoo.com, in the “To:” field of the message header, stores it in permissions table 650, and assigns recipient 613 read/write (“W”) permission. Because recipient 614, user003@hotmail.com, is in the “Cc:” field of the message header, service 155 assigns recipient 614 read-only (“R”) permission in permissions table 650. In another embodiment, recipients appearing in the “To:” and “Cc:” fields are respectively assigned “R” and “W” permissions. Subject line 615 is for human readability and is ignored. Formatting commands and content 619 are processed as explained above. In another embodiment, message 610 includes express access permissions, e.g., 634-636 as depicted in message 630.

Service 155 transmits message 620 to first sender 611 and recipients 613-614 including a link to document location 626 (http://zohoshow.com/user001/MozartSlides.001), and document I.D. 625 (MozartSlides.001), which it retrieved from document table 640. First sender 611 and recipients 613-614 may open the document via the link. In another embodiment, message 620 includes document MozartSlides.001 as an attachment. In one embodiment, message 620 is directed to recipients 613 and 614 in the “To:” and “Cc:” fields of message 620, in accordance with their respective locations in the header of message 610.

Message 630, received from first sender 611, user001@gmail.com, includes formatting commands and content 639 for modifying document MozartSlides.001. Subject 633 is for human readability and is ignored. Message 630 also includes instructions to modify access permissions to MozartSlides.001. Permissions table 650 depicts user002@yahoo.com having “W” (read/write) permissions and user003@hotmail.com having “R” (read-only) permissions. Applying instructions 634-636, service 155 modifies access permissions in permissions table 650, depicted in its post-modification state as table 650a, as follows: user001@gmail.com is unmodified, user002@yahoo.com is modified from “W” to “R,” user003@hotmail.com is modified from “R” to “W,” and user277@outlook.com is added with access permission “W.” In another embodiment, service 155 effectuates the same modifications to MozartSlides.001 access permissions by processing a message having user002@yahoo.com in the “Cc:” field, and user003@hotmail.com and user277@outlook.com in the “To:” field of the message header.

In one embodiment, a document specification contains a fillable field, e.g., “Subject Title: FILL_IN.” A user replaces “FILL_IN” with descriptive text, e.g., “Invention of the Steam Engine,” “Mozart,” or “Rock Climbing.” Document service 155 may fill or add content relating to the descriptive text, e.g., text, images, audio, video, and other multimedia information. Document service 155 may insert the content directly, or insert a link referencing the content, e.g., a URL. A user attaches content, or a link to it, e.g., a URL, in the document specification, and document service 155 parses and includes the content in the document it creates on behalf of the sender (creator) of the document.

Document service 155 enhances collaboration among users in another embodiment by identifying and highlighting edits and comments, and enabling the sender (a document creator or collaborator) to accept and reject edits. Document service 155 thereby tracks and associates one or more updates, e.g., edits and comments, to a document specification, with a sender. In another embodiment, a system and method for creating a document are provided via a cloud-based email service in which users create and share an email message comprising the document in a web browser or ordinary email interface. A user may share an email message including a document specification with collaborators, who have permissions to read and write to the specification in accordance with the permissions described with respect to FIG. 6. A specialized document specification editor is provided in another embodiment, in which document service 155 identifies and highlights edits and comments to the specification by one or more collaborators, and enabling the document creator (sender) to accept and reject edits. Read and write permissions as to collaborators are enforced in accordance with FIG. 6.

Document and messaging servers 140 and 170 depicted in FIG. 1 respectively comprise memory (145, 175), a processor (150, 180), and storage (160, 190). As one of skill in the art will appreciate, a device, e.g., a server, computer system, laptop computer, and wireless handheld device, may include one or more processors, memory and storage units, peripherals, and communication interfaces, any of which may communicate via, e.g., a system bus, network, or any other communication medium. A processor may be realized by a microprocessor, memory may include random access (RAM) and ready only (ROM) memory for storing and retrieving, e.g., information, instructions, and program modules for execution by the processor. A storage unit, e.g., 160 and 190 depicted in FIG. 1, may be fixed or removable, and may be realized by, e.g., hard disk, optical disk, solid state disk, and flash memory. The storage unit may store program modules, e.g., an operating system, application programs, system drivers and applications, e.g., a communication module, and data. Peripherals, e.g., input/output devices may include, e.g., keyboard, mouse, microphone, speaker, touch screen display, and motion sensors. A communication interface enables communication among devices over various wired and wireless networks, and may include, e.g., a modem, Ethernet or Network Interface Controller (NIC) card. Any device may be configured to function as a client or server device. Variations of the foregoing will be obvious to those of ordinary skill in the art.

FIG. 7 and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. The foregoing examples are described in the general context of computer-executable instructions, such as program modules, executed on client and server computers linked through a communication network, including the Internet. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. In a distributed computing environment, program modules may be located in both local and remote memory storage devices, and may be executed by client and server computers.

FIG. 7 depicts a general-purpose computing system 700 that can serve as a client or a server depending on the program modules and components included. One or more computers of the type depicted in computing system 700 can be configured to perform operations described with respect to FIGS. 1-6. Those skilled in the art will appreciate that the invention may be practiced using other system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like.

Computing system 700 includes a conventional computer 720, including a processing unit 721, a system memory 722, and a system bus 723 that couples various system components including the system memory to the processing unit 721. The system bus 723 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read only memory (ROM) 724 and random access memory (RAM) 725. A basic input/output system 726 (BIOS), containing the basic routines that help to transfer information between elements within the computer 720, such as during start-up, is stored in ROM 724. The computer 720 further includes a hard disk drive 727 for reading from and writing to a hard disk, not shown, a solid-state drive 728 (e.g. NAND flash memory), and an optical disk drive 730 for reading from or writing to an optical disk 731 (e.g., a CD or DVD). The hard disk drive 727 and optical disk drive 730 are connected to the system bus 723 by a hard disk drive interface 732 and an optical drive interface 734, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for computer 720. Other types of computer-readable media can be used.

A number of program modules may be stored on the hard disk, solid state disk 728, optical disk 731, ROM 724 or RAM 725, including an operating system 735, one or more application programs 736, other program modules 737, and program data 738. A user may enter commands and information into the computer 720 through input devices such as a keyboard 740 and pointing device 742. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 721 through a serial port interface 746 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or a universal serial bus (USB). A monitor 747 or other type of display device is also connected to the system bus 723 via an interface, such as a video adapter 748. In addition to the monitor, computers can include or be connected to other peripheral devices (not shown), such as speakers and printers.

The computer 720 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 749. The remote computer 749 may be another computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 720, although only a memory storage device 750 has been illustrated in FIG. 7. The logical connections depicted in FIG. 7 include a network connection 751, which can support a local area network (LAN) and/or a wide area network (WAN). Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

Computer 720 includes a network interface 753 to communicate with remote computer 749 via network connection 751. In a networked environment, program modules depicted relative to the computer 720, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communication link between the computers may be used.

In the foregoing description and in the accompanying drawings, specific terminology and drawing symbols are set forth to provide a thorough understanding of the present invention. In some instances, the terminology and symbols may imply specific details that are not required to practice the invention. For example, the wireless handheld devices discussed above are “smart phones” that support many services in addition to conventional voice functions. Portable computing devices such as tablet computers, e.g., an iPad manufactured by Apple, Inc. of Cupertino, California, and palm-top and lap-top computers, can be equipped as detailed herein to serve as wireless handheld devices. Moreover, some components or devices are shown directly connected to one another while others are shown connected via intermediate components, or wirelessly, e.g., Wi-Fi, Bluetooth, a public WAN, e.g., the Internet, or a cellular network. In each instance, the method of interconnection establishes some desired electrical or logical communication between two or more devices, as will be understood by those of skill in the art.

Document Server 140 and Messaging Server 170 may be realized as one or more servers, each including one or more services shown within Document Server 140 and Messaging Server 170, e.g., services 155 and 185. Document Server 140 and Messaging Server 170 may also be implemented as discrete servers in which each includes a processor, memory, storage, and modules, self-contained within a server having discrete physical boundaries. In this embodiment, communications among the processor, memory, storage, and modules, occur internally. A discrete server may also be embodied virtually, e.g., via VMWARE, or VIRTUALBOX. Document Server 140 and Messaging Server 170 may also be implemented in a distributed fashion, e.g., via a “hypervisor” implementation such as VMWARE, or as individual “cloud” services, in which processor, memory, and storage are not necessarily physically co-extensive. For example, processors 150 and 180 may be distributed across several physical processors communicating over a local area network. In such implementations, memories 145 and 175 may be physically separate from processors 150 and 180, and data stores 160 and 190, requiring communication over a potentially insecure communication link. Some embodiments therefore support secure communication links and data encryption for the communications into and out of Document Server 140 and Messaging Server 170. The components of servers 140 and 170 may be distributed across local and wide-area networks, including the Internet, as will be readily understood by those of skill in the art.

Variations of these embodiments, including embodiments in which features are used separately or in any combination, will be obvious to those of ordinary skill in the art. Therefore, the spirit and scope of the appended claims should not be limited to the foregoing description. In U.S. applications, only those claims specifically reciting “means for” or “step for” should be construed in the manner required under 35 U.S.C. section 112(f).

Claims

1. A computer-implemented method for creating a document, the method comprising:

receiving a first communication from a first sender, the first communication identifying zero or more recipients, the first communication including a document specification including zero or more formatting commands and content;

parsing the first communication, the parsing including determining whether the document specification is in a done condition;

applying the zero or more formatting commands to the content, wherein the applying comprises producing a document;

storing the document;

transmitting information for accessing the document to the first sender, and to the zero or more recipients; and

iterating until the document specification is in a done condition.

2. The computer-implemented method of claim 1, wherein the receiving the first communication is via email.

3. The computer-implemented method of claim 1, the first communication further comprising one or more address fields, the zero or more recipients identified in the one or more address fields, the one or more address fields corresponding to one or more document access privileges for the zero or more recipients.

4. The computer-implemented method of claim 1, wherein the transmitting information for accessing the document includes transmitting the document itself.

5. The computer-implemented method of claim 1, wherein the zero or more formatting commands comprise plain text.

6. The computer-implemented method of claim 1, further comprising in response to receiving the zero or more formatting commands, transmitting to the first sender, instructions for creating a document specification.

7. The computer-implemented method of claim 6, wherein the instructions for creating a document specification include a template.

8. The computer-implemented method of claim 1, wherein the document specification includes a template.

9. The computer-implemented method of claim 1, wherein the iterating includes revising the document specification and transmitting the revised document specification to the first sender.

10. The computer-implemented method of claim 9, further comprising transmitting the revised document specification to the zero or more recipients.

11. The computer-implemented method of claim 9, wherein the revising the document specification further comprises stamping it with a version indicator.

12. The computer-implemented method of claim 9, wherein the zero or more formatting commands is erroneous, and revising the document specification includes identifying errors corresponding to the zero or more formatting commands.

13. The computer-implemented method of claim 1, the method further comprising applying one or more access permissions to the document corresponding to the first sender and the zero or more recipients.

14. The computer-implemented method of claim 13, further comprising receiving a second communication from a second sender, wherein the access permissions prohibit the second sender from modifying the document, and rejecting the second communication.

15. The computer-implemented method of claim 13, further comprising receiving a second communication from a second sender, the second communication including one or more updates to the document specification, wherein the access permissions permit the second sender to modify the document, and tracking and associating the one or more updates to the document specification with the second sender.

16. The computer-implemented method of claim 13, further comprising receiving a third communication from the first sender, the third communication including one or more instructions for modifying the access permissions, and in response to the one or more instructions, modifying the access permissions.

17. The computer-implemented method of claim 13, wherein the access permissions prohibit zero or more recipients from modifying the document.

18. The computer-implemented method of claim 13, wherein applying one or more access permissions further comprises creating a password.

19. A system comprising:

one or more computers configured to perform operations including: