DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 14 January 2026 has been entered.
This is a non-final office action in response to remarks filed on 14 January 2026. Claims 1-6, 8-13, 15-18, and 20 are amended. No claims are canceled or added. Claims 1-20 are pending.
Claim Interpretation
The claims have been considered according to the latest Patent Eligibility Guidelines and are considered eligible.
Claim Objections
Claims 15-16 are objected to because of the following informalities:
Claim 15 recites “the attachment” in the seventh and eighth limitations whereas the independent claims 1 and 8 recite “first version of the attachment” in the corresponding limitations. Claim 15 also recites “first version of the attachment” in the sixth limitation.
Claim 16 recites “a content management system” in line 2 however parent claim 15 was amended to recite “a content management system” in the sixth limitation.
Appropriate correction is required.
Response to Arguments
Applicant’s arguments, see pages 12-17, filed 14 January 2026, with respect to the rejections of claims 1-20 under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made incorporating newly discovered prior art Savage et al. (U.S. Patent Publication 2015/0127607) into the rejection below.
Examiner notes that the scope of the current claim amendments is not sufficient to overcome the use of Yuniardi and Costenaro in the rejections below, however in light of the changed scope due to the amendments, an additional newly discovered prior art Savage is incorporated into the rejections below to teach the claimed details about the content management system.
As explained in more detail below, Yuniardi’s Fig. 5 illustrates simultaneously displaying an email and a drop down menu that includes multiple selectable UIs that are each associated with a different version (see Yuniardi Fig. 5, 6:5-26). Each option within a drop down menu #502 is selectable, i.e. there are four UIs within the drop down menu #502, and a particular version is displayed upon a user’s selection of one of the options displayed in the drop down menu #502. Examiner interprets each option in the drop down menu #502 as being functionally equivalent to a selectable UI that causes the computing system to retrieve the particular version from wherever the version is stored.
Response to Amendment
With respect to the third limitation in claims 1 and 8, the claims recite “based on the version information and updates received at the content management system”. Examiner notes that this phrase can be interpreted such that both version information and updates are received at the CMS, however this interpretation does not have antecedent basis support. Examiner notes that this phrase can also be interpreted that updates are received at the CMS, but not necessarily the identified version information.
With respect to the fourth limitation in claims 1 and 8 and the sixth limitation of claim 15, the claims recite “causing, by the computing system, display of the first message simultaneously with a first user interface (UI) element associated with a first version of the attachment and a second UI element associated with the second version of the attachment, wherein the first UI element is selectable to cause the computing system to retrieve the first version of the attachment from the content management system and the second UI element is selectable to cause the computing system to retrieve the second version of the attachment from the content management system”. Examiner notes that this claim limitation describes displaying an email along with two UIs, each of which is associated with a version of the attachment, but does not describe displaying an attachment or version(s) of the attachment, much less displaying the attachment or version(s) along with the email and UIs. The claim limitation also describes that the UIs are selectable for retrieving a particular version from its storage location, but does not describe performing a selection of one or multiple UIs either individually or simultaneously.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Yuniardi et al. (U.S. Patent 8,826,148) in view of Savage et al. (U.S. Patent Publication 2015/0127607) and further in view of Costenaro et al. (U.S. Patent Publication 2012/0284344).
Regarding claim 1, Yuniardi disclosed a method (see Yuniardi Fig. 2: method), comprising:
identifying, by a computing system (see Yuniardi Fig. 1 system), a first message received from a second computing system to the computing system (see Yuniardi #206, 5:4-10: “Open Email Message”; Fig. 5, 6:5-19: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 | 5:4-22: selecting and opening an email message to read and also making attachments available for simultaneous viewing within the GUI of the email reader), wherein the first message includes an attachment (see Yuniardi Fig. 2 #208, 5:4-22: determining if email message has an attachment) stored on a content management system and accessible to the computing system and the second computing system (see Yuniardi-Savage-Costenaro combination below);
identifying, by the computing system, version information associated with the attachment included in the first message received from the second computing system (see Yuniardi Fig. 5 #502, 6:5-36: drop down menu #502 provides the user with options to choose between different versions of an attached document such that each version is associated with a different option within the drop down menu #502. In order to populate the four options within the displayed drop down menu, the system inherently first identifies version information associated with the attachment);
based on the version information and updates received at the content management system, determining, by the computing system, that the content management system stores a second version of the attachment (see Savage combination below regarding the retrieval of versions from the content management system and Yuniardi-Savage-Costenaro combination below regarding network storage of a message attachment);
causing, by the computing system, display of the first message simultaneously with a first user interface (UI) element associated with a first version of the attachment and a second UI element associated with the second version of the attachment (see Yuniardi Fig. 2 #214, 5:38-45: simultaneous display of email and attachments | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions that are selectable in the drop down menu #502 of Fig. 5 and users may select any of the different versions for display, i.e. there are four UIs within the drop down menu #502 | examiner notes that this portion of the claim limitation describes displaying an email along with two UIs, each of which is associated with a version of the attachment, but does not describe displaying an attachment or version(s) of the attachment, much less displaying the attachment or version(s) along with the email and UIs. Yuniardi’s Fig. 5 illustrates simultaneously displaying an email and a drop down menu that includes multiple selectable UIs that are each associated with a different version), wherein the first UI element is selectable to cause the computing system to retrieve the first version of the attachment (see Yuniardi Fig. 5 #502, 6:5-26: There are four versions that are selectable in the drop down menu #502 of Fig. 5 and users may select any of the different versions for display, i.e. there are four UIs within the drop down menu #502 | examiner notes that this portion of the claim limitation describes UIs that are selectable for retrieving a particular version from its storage location, but does not describe performing a selection of one or multiple UIs either individually or simultaneously. Yuniardi’s Fig. 5 illustrates simultaneously displaying an email and a drop down menu that includes multiple selectable UIs that are each associated with a different version. Examiner notes that each option within a drop down menu #502 is selectable and that a particular version is displayed upon a user’s selection of one of the options displayed in the drop down menu #502. As such, examiner interprets each option in the drop down menu #502 as being functionally equivalent to a selectable UI that causes the computing system to retrieve the particular version associated with the corresponding option in the drop down menu) from the content management system (see Savage combination below regarding the retrieval of versions from the content management system and Yuniardi-Savage-Costenaro combination below regarding network storage of a message attachment) and the second UI element is selectable to cause the computing system to retrieve the second version of the attachment (see Yuniardi Fig. 5 #502, 6:5-26: There are four versions that are selectable in the drop down menu #502 of Fig. 5 and users may select any of the different versions for display, i.e. there are four UIs within the drop down menu #502 | examiner notes that this portion of the claim limitation describes UIs that are selectable for retrieving a particular version from its storage location, but does not describe performing a selection of one or multiple UIs either individually or simultaneously. Yuniardi’s Fig. 5 illustrates simultaneously displaying an email and a drop down menu that includes multiple selectable UIs that are each associated with a different version. Examiner notes that each option within a drop down menu #502 is selectable and that a particular version is displayed upon a user’s selection of one of the options displayed in the drop down menu #502. As such, examiner interprets each option in the drop down menu #502 as being functionally equivalent to a selectable UI that causes the computing system to retrieve the particular version associated with the corresponding option in the drop down menu) from the content management system (see Savage combination below regarding the retrieval of versions from the content management system and Yuniardi-Savage-Costenaro combination below regarding network storage of a message attachment);
receiving a status change corresponding to the first version of the attachment or the second version of the attachment (see Yuniardi Fig. 5 John edited: “1.20.20 and 2.20.20” to “1.10.32 and 1.10.33”: The email from John Smith includes a box that includes a notification that John edited the document in addition to the edits made; examiner notes that this notification is status change corresponding to one of the versions of the attachment and that the status change is inherently received before it can be displayed); and
causing, by the computing system, display of a graphical indication of the status change, wherein the graphical indication indicates that at least one of the first version of the attachment or the second version of the attachment is open or has been edited (examiner notes that the claims describe displaying a graphical indication of the status change, but the displayed graphical indication of the status change is not necessarily displayed along with the message, attachment, or version information UI elements described in previous limitations | see Yuniardi Fig. 5 John edited: “1.20.20 and 2.20.20” to “1.10.32 and 1.10.33”: The email from John Smith includes a box that includes a notification that John edited the document in addition to the edits made; examiner notes that this box including the notification is a graphical indication of the status change that indicates that one of the versions of the attachment has been edited).
With respect to the limitation “wherein the first message includes an attachment stored on a content management system and accessible to the computing system and the second computing system”:
Yuniardi did not explicitly disclose that the message attachment is “stored on a content management system and accessible to the computing system and the second computing system”.
However in a related art, Savage disclosed a cloud-based platform coupled to a system of agents, e.g., agents hosted on cloud-based storage devices, or folders hosted on client devices such that the content management system manages the distributed storage of shared content (see Savage [0026], Fig. 2). File sharing includes providing access to shared folders from which users can view and edit files within the folder and sync the changes to other users (see Savage [0130]) as well as providing file-in-use alerts for shared documents (see Savage [0132]) including email alerts when someone edits content (see Savage [0133]), i.e. shared documents are “stored on a content management system and accessible to the computing system and the second computing system”.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Savage to further clarify storing shared documents in a content management system. Including Savage’s teachings would provide a streamlined approach to file synchronization and file access (see Savage [0004]) while also improving efficiency when synchronizing changed files (see Savage [0042]), reducing costs associated with network attached storage (see Savage [0090]), and improving data transfer efficiency and data security (see Savage [0094]).
Examiner notes that while Savage disclosed shared documents are “stored on a content management system and accessible to the computing system and the second computing system”, Savage did not explicitly disclose that the shared document is an “attachment” to a message.
While it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that the type of document, i.e. message attachment, being stored on a content management system is a matter of implementation choice, however in a related art, Costenaro disclosed a network share that stores documents that are being collaborated on (see Costenaro [0023]) and that the document being collaborated on is an attachment to an electronic message (see Costenaro [0025]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi-Savage and Costenaro to further clarify the types of documents, e.g., message attachments, that are stored in a content management system, as well as additional details about the types of information about an attachment that can be displayed. Expanding upon Yuniardi’s display of historical document versions and their changes (see Yuniardi 2:47-65) with Costenaro’s display of content summaries and status (see Costenaro Fig. 9) would improve a user’s ability to keep up with content changes (see Costenaro [0001]). Incorporating Costenaro’s teachings would also ensure that the changes are updated in real-time (see Costenaro [0026]) and the related information, e.g. changes and status, are tailored based on the user (see Costenaro [0036]).
Yuniardi did not explicitly disclose “based on the version information and updates received at the content management system, determining, by the computing system, that the content management system stores a second version of the attachment” and that the versions of the attachments are able to be retrieved “from the content management system”. Examiner relies upon Costenaro above to describe the type of document, i.e. message attachment, being stored at the CMS.
Savage disclosed a cloud-based platform coupled to a system of agents, e.g., agents hosted on cloud-based storage devices, or folders hosted on client devices such that the content management system manages the distributed storage of shared content (see Savage [0026], Fig. 2) via a variety of databases included in the platform (see Savage [0033]). File sharing includes providing access to shared folders from which users can view and edit files within the folder and sync the changes to other users (see Savage [0130]) as well as providing file-in-use alerts for shared documents (see Savage [0132]) including email alerts when someone edits content (see Savage [0133]). Each agent indexes stored content and sends metadata for the index to the platform (see Savage [0031]) such that the platform stores metadata and the agents serve as distributed data storage entities at which actual data is stored (see Savage [0037]). Agents continuously report changes to any file in the directory (see Savage [0044]) and a sync database includes records of file states (see Savage [0088]). The platform receives hashes of data files from agents, generates a record for each file that includes information of various hashes, and uses this record to determine the state of the data and to identify if there are multiple versions located in the system (see Savage [0039]), e.g., via the file hash (see Savage [0063]). Hashes are used to enable versioning so that older versions of a file are able to be created (see Savage [0062]) and are also used to identify when an agent has an out-of-date version (see Savage [0063]), e.g., platform identifies two different hashes H and H2 for the same file and determines that there are two versions stored in the system (see Savage [0083]), i.e. “based on the version information and updates received at the content management system, determining, by the computing system, that the content management system stores a second version of the attachment”.
A version history stores previous versions and allows users to revert to older versions (see Savage [0127]) and users retrieve existing documents directly from the document management system (see Savage [0142]), i.e. versions are retrieved “from the content management system”. The platform distributes tasks to agents (see Savage [0036]), e.g., tasks for scanning, deleting, writing, and uploading (see Savage [0045]) as well as tasks to provide file(s) to an application (see Savage [0091]). A write task includes copying data from one location to another location, e.g., from an agent’s file system to a cloud-base storage device, peer-to-peer between two agents, etc., such that the source of the data can be a cloud-based or network-based storage device or a file system of any agent (see Savage [0046]), i.e. content is retrieved “from the content management system”. When an agent retrieves data that is needed to perform a task, the agent first searches locally, then searches peers, and then searches cloud-based storage or another remote storage entity (see Savage [0051]), i.e. content is retrieved “from the content management system”.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Savage to further clarify how document versions are tracked within a content management system. Including Savage’s teachings would provide a streamlined approach to file synchronization and file access (see Savage [0004]) while also improving efficiency when synchronizing changed files (see Savage [0042]), reducing costs associated with network attached storage (see Savage [0090]), and improving data transfer efficiency and data security (see Savage [0094]).
Regarding claim 2, Yuniardi-Savage-Costenaro disclosed the method of claim 1, further comprising:
receiving, from the content management system, a state information report indicating that the attachment exists (see Savage [0035]: sync databases in the cloud include metadata on the location and state of all data in the system | [0039]: The platform receives hashes of data files from agents, generates a record for each file that includes information of various hashes, and uses this record to determine the state of the data and to identify if there are multiple versions located in the system, e.g., [0063]: multiple versions are identified via the file hash and a task to reconcile the different versions is sent from the platform to the agent | [0071]: each agent includes a global library including the current state of all files in the libraries accessible to the agent; [0083]: agents receive updates for synchronizing libraries and content | examiner notes that libraries include state information reports for each file and that sending a library or update to a library is functionally equivalent to sending/receiving a state information report indicating that a file exists) in a shared folder managed by the content management system (see Savage [0130]: File sharing includes providing access to shared folders from which users can view and edit files within the folder and sync the changes to other users | [0026], Fig. 2: a cloud-based platform coupled to a system of agents, e.g., agents hosted on cloud-based storage devices, or folders hosted on client devices such that the content management system manages the distributed storage of shared content; [0035]: content management system platform acts as a universal synchronization engine and master controller for the agents storing the data) and that the content management system stores both the first version of the attachment and the second version of the attachment (see Savage [0035]: sync databases in the cloud include metadata on the location and state of all data in the system | [0062]: Hashes are used to enable versioning so that older versions of a file are able to be created; [0063]: multiple versions are identified via the file hash and a task to reconcile the different versions is sent from the platform to the agent, i.e. there are at least two versions stored on the content management system | [0083]: agents receive updates for synchronizing libraries and content | [0127]: a version history stores previous versions and allows users to revert to older versions), wherein determining that the content management system stores the second version of the attachment is based on the state information report from the content management system (see Savage [0035]: sync databases in the cloud include metadata on the location and state of all data in the system | [0039]: The platform receives hashes of data files from agents, generates a record for each file that includes information of various hashes, and uses this record to determine the state of the data and to identify if there are multiple versions located in the system, e.g., [0063]: multiple versions are identified via the file hash and a task to reconcile the different versions is sent from the platform to the agent | [0071]: each agent includes a global library including the current state of all files in the libraries accessible to the agent; [0083]: agents receive updates for synchronizing libraries and content | examiner notes that libraries include state information reports for each file and that sending/receiving a sync command or update to a library is functionally equivalent to determining that there is another version stored in the content management system based on a state information report).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Savage to further clarify how document versions are tracked within a content management system. Including Savage’s teachings would provide a streamlined approach to file synchronization and file access (see Savage [0004]) while also improving efficiency when synchronizing changed files (see Savage [0042]), reducing costs associated with network attached storage (see Savage [0090]), and improving data transfer efficiency and data security (see Savage [0094]).
Regarding claim 3, Yuniardi-Savage-Costenaro disclosed the method of claim 1, further comprising:
causing, by the computing system, display of a message area (see Yuniardi Fig. 5#304, 6:5-19) and an attachment area (see Yuniardi Fig. 5#306, 6:5-19), the attachment area comprising a portion that comprises both (examiner notes that the claims describe a GUI including at least two areas and that the two UIs for selecting different versions are displayed in an area that is not a message area. Examiner notes that the claims do not prevent the interpretation that both UIs are part of a drop down menu. | see Yuniardi Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version; the drop down menu #502 illustrates four different selectable versions of an attachment and the drop down menu #502 is displayed in a different area #306 than where the message is displayed #304) the first UI element that is selectable to cause the computing system to retrieve the first version of the attachment (see Yuniardi Fig. 5 #502, 6:5-26: There are four versions that are selectable in the drop down menu #502 of Fig. 5 and users may select any of the different versions for display | examiner notes that this portion of the claim limitation describes UIs that are selectable for retrieving a particular version from its storage location, but does not describe performing a selection of one or multiple UIs either individually or simultaneously. Yuniardi’s Fig. 5 illustrates simultaneously displaying an email and a drop down menu that includes multiple selectable UIs that are each associated with a different version. Examiner notes that each option within a drop down menu #502 is selectable and that a particular version is displayed upon a user’s selection of one of the options displayed in the drop down menu #502. As such, examiner interprets each option in the drop down menu #502 as being functionally equivalent to a selectable UI that causes the computing system to retrieve the particular version associated with the corresponding option in the drop down menu) from the content management system (examiner notes that citations and explanations from parent claim 1 are incorporated into this claim limitation; see Savage [0127]: a version history stores previous versions and allows users to revert to older versions; [0142]: users retrieve existing documents directly from the document management system, i.e. versions are retrieved “from the content management system” | [0046]: a write task includes copying data from one location to another location, e.g., from an agent’s file system to a cloud-base storage device, peer-to-peer between two agents, etc., such that the source of the data can be a cloud-based or network-based storage device or a file system of any agent; [0051]: when an agent retrieves data that is needed to perform a task, the agent first searches locally, then searches peers, and then searches cloud-based storage or another remote storage entity) and the second UI element is selectable to cause the computing system to retrieve the second version of the attachment (see Yuniardi Fig. 5 #502, 6:5-26: There are four versions that are selectable in the drop down menu #502 of Fig. 5 and users may select any of the different versions for display | examiner notes that this portion of the claim limitation describes UIs that are selectable for retrieving a particular version from its storage location, but does not describe performing a selection of one or multiple UIs either individually or simultaneously. Yuniardi’s Fig. 5 illustrates simultaneously displaying an email and a drop down menu that includes multiple selectable UIs that are each associated with a different version. Examiner notes that each option within a drop down menu #502 is selectable and that a particular version is displayed upon a user’s selection of one of the options displayed in the drop down menu #502. As such, examiner interprets each option in the drop down menu #502 as being functionally equivalent to a selectable UI that causes the computing system to retrieve the particular version associated with the corresponding option in the drop down menu) from the content management system (examiner notes that citations and explanations from parent claim 1 are incorporated into this claim limitation; see Savage [0127]: a version history stores previous versions and allows users to revert to older versions; [0142]: users retrieve existing documents directly from the document management system, i.e. versions are retrieved “from the content management system” | [0046]: a write task includes copying data from one location to another location, e.g., from an agent’s file system to a cloud-base storage device, peer-to-peer between two agents, etc., such that the source of the data can be a cloud-based or network-based storage device or a file system of any agent; [0051]: when an agent retrieves data that is needed to perform a task, the agent first searches locally, then searches peers, and then searches cloud-based storage or another remote storage entity).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Savage to further clarify how document versions are tracked within a content management system. Including Savage’s teachings would provide a streamlined approach to file synchronization and file access (see Savage [0004]) while also improving efficiency when synchronizing changed files (see Savage [0042]), reducing costs associated with network attached storage (see Savage [0090]), and improving data transfer efficiency and data security (see Savage [0094]).
Regarding claim 4, Yuniardi-Savage-Costenaro disclosed the method of claim 1, further comprising:
receiving, by the computing system, an input interacting with the first UI element (see Yuniardi Fig. 2 #212, 5:23-37: detecting an input from the user indicating a desire to simultaneously view the message and attachment(s) | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 and users may select, e.g., via a drop down menu, any of the different versions for display);
retrieving, from the content management system (examiner notes that citations and explanations from parent claim 1 are incorporated into this claim limitation; see Savage [0127]: a version history stores previous versions and allows users to revert to older versions; [0142]: users retrieve existing documents directly from the document management system, i.e. versions are retrieved “from the content management system” | [0046]: a write task includes copying data from one location to another location, e.g., from an agent’s file system to a cloud-base storage device, peer-to-peer between two agents, etc., such that the source of the data can be a cloud-based or network-based storage device or a file system of any agent; [0051]: when an agent retrieves data that is needed to perform a task, the agent first searches locally, then searches peers, and then searches cloud-based storage or another remote storage entity), the first version of the attachment in response to the input (examiner notes that a version is retrieved from wherever it is located before it can be displayed; see Yuniardi Fig. 2 #212, 5:23-37: detecting an input from the user indicating a desire to simultaneously view the message and attachment(s) | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment); and
causing, by the computing system, display of the first version of the attachment (Examiner notes that the claims do not require displaying the first version of the attachment along with the email, but rather allows for the interpretation that the attachment is opened in another window or another application | see Yuniardi Fig. 2 #214, 5:23-45: simultaneous display of email and attachments in response to input received in #212 | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 and users may select, e.g., via a drop down menu, any of the different versions for display).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Savage to further clarify how document versions are tracked within a content management system. Including Savage’s teachings would provide a streamlined approach to file synchronization and file access (see Savage [0004]) while also improving efficiency when synchronizing changed files (see Savage [0042]), reducing costs associated with network attached storage (see Savage [0090]), and improving data transfer efficiency and data security (see Savage [0094]).
Regarding claim 5, Yuniardi-Savage-Costenaro disclosed the method of claim 1, further comprising:
receiving, by the computing system, an input interacting with the second UI element (see Yuniardi Fig. 2 #212, 5:23-37: detecting an input from the user indicating a desire to simultaneously view the message and attachment(s) | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 and users may select, e.g., via a drop down menu, any of the different versions for display);
retrieving, from the content management system (examiner notes that citations and explanations from parent claim 1 are incorporated into this claim limitation; see Savage [0127]: a version history stores previous versions and allows users to revert to older versions; [0142]: users retrieve existing documents directly from the document management system, i.e. versions are retrieved “from the content management system” | [0046]: a write task includes copying data from one location to another location, e.g., from an agent’s file system to a cloud-base storage device, peer-to-peer between two agents, etc., such that the source of the data can be a cloud-based or network-based storage device or a file system of any agent; [0051]: when an agent retrieves data that is needed to perform a task, the agent first searches locally, then searches peers, and then searches cloud-based storage or another remote storage entity), the second version of the attachment in response to the input (examiner notes that a version is retrieved from wherever it is located before it can be displayed; see Yuniardi Fig. 2 #212, 5:23-37: detecting an input from the user indicating a desire to simultaneously view the message and attachment(s) | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment); and
causing, by the computing system, display of the second version of the attachment (see Yuniardi Fig. 2 #214, 5:23-45: simultaneous display of email and attachments in response to input received in #212 | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 and users may select, e.g., via a drop down menu, any of the different versions for display).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Savage to further clarify how document versions are tracked within a content management system. Including Savage’s teachings would provide a streamlined approach to file synchronization and file access (see Savage [0004]) while also improving efficiency when synchronizing changed files (see Savage [0042]), reducing costs associated with network attached storage (see Savage [0090]), and improving data transfer efficiency and data security (see Savage [0094]).
Regarding claim 6, Yuniardi-Savage-Costenaro disclosed the method of claim 1 above, further comprising:
receiving, by the computing system, an input interacting with an expandable graphical element (examiner notes that a drop down menu is an example of an expandable graphical element; Yuniardi’s Fig. 4 illustrates the collapsed drop down menu while Fig. 5 illustrates the expanded drop down menu #502 | see Yuniardi Fig. 2 #212, 5:23-37: detecting an input from the user indicating a desire to simultaneously view the message and attachment(s) | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 and users may select, e.g., via a drop down menu, any of the different versions for display);
responsive to receiving the input, causing display of a collapsible graphical element comprising the first UI element associated with the first version of the attachment and the second UI element associated with the second version of the attachment (examiner notes that a drop down menu is also an example of a collapsible graphical element; Yuniardi’s Fig. 4 illustrates the collapsed drop down menu while Fig. 5 illustrates the expanded drop down menu #502 | see Yuniardi Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 and users may select, e.g., via a drop down menu, any of the different versions for display; examiner notes that Yuniardi’s drop-down menu including multiple versions is a type of collapsible graphical element comprising UI elements associated with the attachment version(s).).
Regarding claim 7, Yuniardi-Savage-Costenaro disclosed the method of claim 1, further comprising:
causing display of a first indication of a last edit time for the attachment and a second indication of a user account that last accessed the attachment (see Costenaro Fig. 6, [0060]: live summary information about the attachment includes when the content was last changed, who last viewed the content, and other types of information).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Costenaro to further clarify that shared documents are stored in network storage and to also clarify the types of information about an attachment that can be displayed. Expanding upon Yuniardi’s display of historical document versions and their changes (see Yuniardi 2:47-65) with Costenaro’s display of content summaries and status (see Costenaro Fig. 9) would improve a user’s ability to keep up with content changes (see Costenaro [0001]). Incorporating Costenaro’s teachings would also ensure that the changes are updated in real-time (see Costenaro [0026]) and the related information, e.g. changes and status, are tailored based on the user (see Costenaro [0036]).
Regarding claim 8, the claim contains the limitations, substantially as claimed, as described in claim 1 above. Yuniardi disclosed, as recited in claim 8: A non-transitory computer readable medium comprising one or more sequences of instructions, which, when executed by a processor, causes a computing system to perform operations (see Yuniardi Fig. 1: multiple types of memory, processor, and other components of the computing system | examiner notes that “a computer readable medium comprising one or more sequences of instructions, which, when executed by a processor, causes a computing system to perform operations” are inherent components of computers) comprising:
identifying, by the computing system (see Yuniardi Fig. 1 system), a first message received from a second computing system to the computing system (see Yuniardi #206, 5:4-10: “Open Email Message”; Fig. 5, 6:5-19: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 | 5:4-22: selecting and opening an email message to read and also making attachments available for simultaneous viewing within the GUI of the email reader), wherein the first message includes an attachment (see Yuniardi Fig. 2 #208, 5:4-22: determining if email message has an attachment) stored on a content management system and accessible to the computing system and the second computing system (see Yuniardi-Savage-Costenaro combination below);
identifying, by the computing system, version information associated with the attachment included in the first message received from the second computing system (see Yuniardi Fig. 5 #502, 6:5-36: drop down menu #502 provides the user with options to choose between different versions of an attached document such that each version is associated with a different option within the drop down menu #502. In order to populate the four options within the displayed drop down menu, the system inherently first identifies version information associated with the attachment);
based on the version information and updates received at the content management system, determining, by the computing system, that a second version of the attachment exists (see Savage combination below regarding the retrieval of versions from the content management system and Yuniardi-Savage-Costenaro combination below regarding network storage of a message attachment);
causing, by the computing system, display of the first message simultaneously with a first user interface (UI) element associated with a first version of the attachment and a second UI element associated with the second version of the attachment (see Yuniardi Fig. 2 #214, 5:38-45: simultaneous display of email and attachments | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions that are selectable in the drop down menu #502 of Fig. 5 and users may select any of the different versions for display, i.e. there are four UIs within the drop down menu #502 | examiner notes that this portion of the claim limitation describes displaying an email along with two UIs, each of which is associated with a version of the attachment, but does not describe displaying an attachment or version(s) of the attachment, much less displaying the attachment or version(s) along with the email and UIs. Yuniardi’s Fig. 5 illustrates simultaneously displaying an email and a drop down menu that includes multiple selectable UIs that are each associated with a different version), wherein the first UI element is selectable to cause the computing system to retrieve the first version of the attachment (see Yuniardi Fig. 5 #502, 6:5-26: There are four versions that are selectable in the drop down menu #502 of Fig. 5 and users may select any of the different versions for display, i.e. there are four UIs within the drop down menu #502 | examiner notes that this portion of the claim limitation describes UIs that are selectable for retrieving a particular version from its storage location, but does not describe performing a selection of one or multiple UIs either individually or simultaneously. Yuniardi’s Fig. 5 illustrates simultaneously displaying an email and a drop down menu that includes multiple selectable UIs that are each associated with a different version. Examiner notes that each option within a drop down menu #502 is selectable and that a particular version is displayed upon a user’s selection of one of the options displayed in the drop down menu #502. As such, examiner interprets each option in the drop down menu #502 as being functionally equivalent to a selectable UI that causes the computing system to retrieve the particular version associated with the corresponding option in the drop down menu) from the content management system (see Savage combination below regarding the retrieval of versions from the content management system and Yuniardi-Savage-Costenaro combination below regarding network storage of a message attachment) and the second UI element is selectable to cause the computing system to retrieve the second version of the attachment (see Yuniardi Fig. 5 #502, 6:5-26: There are four versions that are selectable in the drop down menu #502 of Fig. 5 and users may select any of the different versions for display, i.e. there are four UIs within the drop down menu #502 | examiner notes that this portion of the claim limitation describes UIs that are selectable for retrieving a particular version from its storage location, but does not describe performing a selection of one or multiple UIs either individually or simultaneously. Yuniardi’s Fig. 5 illustrates simultaneously displaying an email and a drop down menu that includes multiple selectable UIs that are each associated with a different version. Examiner notes that each option within a drop down menu #502 is selectable and that a particular version is displayed upon a user’s selection of one of the options displayed in the drop down menu #502. As such, examiner interprets each option in the drop down menu #502 as being functionally equivalent to a selectable UI that causes the computing system to retrieve the particular version associated with the corresponding option in the drop down menu) from the content management system (see Savage combination below regarding the retrieval of versions from the content management system and Yuniardi-Savage-Costenaro combination below regarding network storage of a message attachment);
receiving a status change corresponding to the first version of the attachment or the second version of the attachment (see Yuniardi Fig. 5 John edited: “1.20.20 and 2.20.20” to “1.10.32 and 1.10.33”: The email from John Smith includes a box that includes a notification that John edited the document in addition to the edits made; examiner notes that this notification is status change corresponding to one of the versions of the attachment and that the status change is inherently received before it can be displayed); and
causing, by the computing system, display of a graphical indication of the status change, wherein the graphical indication indicates that at least one of the first version of the attachment or the second version of the attachment is open or has been edited (examiner notes that the claims describe displaying a graphical indication of the status change, but the displayed graphical indication of the status change is not necessarily displayed along with the message, attachment, or version information UI elements described in previous limitations | see Yuniardi Fig. 5 John edited: “1.20.20 and 2.20.20” to “1.10.32 and 1.10.33”: The email from John Smith includes a box that includes a notification that John edited the document in addition to the edits made; examiner notes that this box including the notification is a graphical indication of the status change that indicates that one of the versions of the attachment has been edited).
With respect to the limitation “wherein the first message includes an attachment stored on a content management system and accessible to the computing system and the second computing system”:
Yuniardi did not explicitly disclose that the message attachment is “stored on a content management system and accessible to the computing system and the second computing system”.
However in a related art, Savage disclosed a cloud-based platform coupled to a system of agents, e.g., agents hosted on cloud-based storage devices, or folders hosted on client devices such that the content management system manages the distributed storage of shared content (see Savage [0026], Fig. 2). File sharing includes providing access to shared folders from which users can view and edit files within the folder and sync the changes to other users (see Savage [0130]) as well as providing file-in-use alerts for shared documents (see Savage [0132]) including email alerts when someone edits content (see Savage [0133]), i.e. shared documents are “stored on a content management system and accessible to the computing system and the second computing system”.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Savage to further clarify storing shared documents in a content management system. Including Savage’s teachings would provide a streamlined approach to file synchronization and file access (see Savage [0004]) while also improving efficiency when synchronizing changed files (see Savage [0042]), reducing costs associated with network attached storage (see Savage [0090]), and improving data transfer efficiency and data security (see Savage [0094]).
Examiner notes that while Savage disclosed shared documents are “stored on a content management system and accessible to the computing system and the second computing system”, Savage did not explicitly disclose that the shared document is an “attachment” to a message.
While it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that the type of document, i.e. message attachment, being stored on a content management system is a matter of implementation choice, however in a related art, Costenaro disclosed a network share that stores documents that are being collaborated on (see Costenaro [0023]) and that the document being collaborated on is an attachment to an electronic message (see Costenaro [0025]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi-Savage and Costenaro to further clarify the types of documents, e.g., message attachments, that are stored in a content management system, as well as additional details about the types of information about an attachment that can be displayed. Expanding upon Yuniardi’s display of historical document versions and their changes (see Yuniardi 2:47-65) with Costenaro’s display of content summaries and status (see Costenaro Fig. 9) would improve a user’s ability to keep up with content changes (see Costenaro [0001]). Incorporating Costenaro’s teachings would also ensure that the changes are updated in real-time (see Costenaro [0026]) and the related information, e.g. changes and status, are tailored based on the user (see Costenaro [0036]).
Yuniardi did not explicitly disclose “based on the version information and updates received at the content management system, determining, by the computing system, that the content management system stores a second version of the attachment” and that the versions of the attachments are able to be retrieved “from the content management system”. Examiner relies upon Costenaro above to describe the type of document, i.e. message attachment, being stored at the CMS.
Savage disclosed a cloud-based platform coupled to a system of agents, e.g., agents hosted on cloud-based storage devices, or folders hosted on client devices such that the content management system manages the distributed storage of shared content (see Savage [0026], Fig. 2) via a variety of databases included in the platform (see Savage [0033]). File sharing includes providing access to shared folders from which users can view and edit files within the folder and sync the changes to other users (see Savage [0130]) as well as providing file-in-use alerts for shared documents (see Savage [0132]) including email alerts when someone edits content (see Savage [0133]). Each agent indexes stored content and sends metadata for the index to the platform (see Savage [0031]) such that the platform stores metadata and the agents serve as distributed data storage entities at which actual data is stored (see Savage [0037]). Agents continuously report changes to any file in the directory (see Savage [0044]) and a sync database includes records of file states (see Savage [0088]). The platform receives hashes of data files from agents, generates a record for each file that includes information of various hashes, and uses this record to determine the state of the data and to identify if there are multiple versions located in the system (see Savage [0039]), e.g., via the file hash (see Savage [0063]). Hashes are used to enable versioning so that older versions of a file are able to be created (see Savage [0062]) and are also used to identify when an agent has an out-of-date version (see Savage [0063]), e.g., platform identifies two different hashes H and H2 for the same file and determines that there are two versions stored in the system (see Savage [0083]), i.e. “based on the version information and updates received at the content management system, determining, by the computing system, that the content management system stores a second version of the attachment”.
A version history stores previous versions and allows users to revert to older versions (see Savage [0127]) and users retrieve existing documents directly from the document management system (see Savage [0142]), i.e. versions are retrieved “from the content management system”. The platform distributes tasks to agents (see Savage [0036]), e.g., tasks for scanning, deleting, writing, and uploading (see Savage [0045]) as well as tasks to provide file(s) to an application (see Savage [0091]). A write task includes copying data from one location to another location, e.g., from an agent’s file system to a cloud-base storage device, peer-to-peer between two agents, etc., such that the source of the data can be a cloud-based or network-based storage device or a file system of any agent (see Savage [0046]), i.e. content is retrieved “from the content management system”. When an agent retrieves data that is needed to perform a task, the agent first searches locally, then searches peers, and then searches cloud-based storage or another remote storage entity (see Savage [0051]), i.e. content is retrieved “from the content management system”.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Savage to further clarify how document versions are tracked within a content management system. Including Savage’s teachings would provide a streamlined approach to file synchronization and file access (see Savage [0004]) while also improving efficiency when synchronizing changed files (see Savage [0042]), reducing costs associated with network attached storage (see Savage [0090]), and improving data transfer efficiency and data security (see Savage [0094]).
Regarding claim 9, the claim contains the limitations, substantially as claimed, as described in claim 2 above. Yuniardi-Savage-Costenaro disclosed, as recited in claim 9: The non-transitory computer readable medium of claim 8, further comprising:
receiving, from the content management system, a state information report indicating that the attachment exists (see Savage [0035]: sync databases in the cloud include metadata on the location and state of all data in the system | [0039]: The platform receives hashes of data files from agents, generates a record for each file that includes information of various hashes, and uses this record to determine the state of the data and to identify if there are multiple versions located in the system, e.g., [0063]: multiple versions are identified via the file hash and a task to reconcile the different versions is sent from the platform to the agent | [0071]: each agent includes a global library including the current state of all files in the libraries accessible to the agent; [0083]: agents receive updates for synchronizing libraries and content | examiner notes that libraries include state information reports for each file and that sending a library or update to a library is functionally equivalent to sending/receiving a state information report indicating that a file exists) in a shared folder managed by the content management system (see Savage [0130]: File sharing includes providing access to shared folders from which users can view and edit files within the folder and sync the changes to other users | [0026], Fig. 2: a cloud-based platform coupled to a system of agents, e.g., agents hosted on cloud-based storage devices, or folders hosted on client devices such that the content management system manages the distributed storage of shared content; [0035]: content management system platform acts as a universal synchronization engine and master controller for the agents storing the data) and that the content management system stores both the first version of the attachment and the second version of the attachment (see Savage [0035]: sync databases in the cloud include metadata on the location and state of all data in the system | [0062]: Hashes are used to enable versioning so that older versions of a file are able to be created; [0063]: multiple versions are identified via the file hash and a task to reconcile the different versions is sent from the platform to the agent, i.e. there are at least two versions stored on the content management system | [0083]: agents receive updates for synchronizing libraries and content | [0127]: a version history stores previous versions and allows users to revert to older versions), wherein determining that the content management system stores the second version of the attachment is based on the state information report from the content management system (see Savage [0035]: sync databases in the cloud include metadata on the location and state of all data in the system | [0039]: The platform receives hashes of data files from agents, generates a record for each file that includes information of various hashes, and uses this record to determine the state of the data and to identify if there are multiple versions located in the system, e.g., [0063]: multiple versions are identified via the file hash and a task to reconcile the different versions is sent from the platform to the agent | [0071]: each agent includes a global library including the current state of all files in the libraries accessible to the agent; [0083]: agents receive updates for synchronizing libraries and content | examiner notes that libraries include state information reports for each file and that sending/receiving a sync command or update to a library is functionally equivalent to determining that there is another version stored in the content management system based on a state information report).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Savage to further clarify how document versions are tracked within a content management system. Including Savage’s teachings would provide a streamlined approach to file synchronization and file access (see Savage [0004]) while also improving efficiency when synchronizing changed files (see Savage [0042]), reducing costs associated with network attached storage (see Savage [0090]), and improving data transfer efficiency and data security (see Savage [0094]).
Regarding claim 10, the claim contains the limitations, substantially as claimed, as described in claim 3 above. Yuniardi-Savage-Costenaro disclosed, as recited in claim 10: The non-transitory computer readable medium of claim 8, further comprising:
causing, by the computing system, display of a message area (see Yuniardi Fig. 5#304, 6:5-19) and an attachment area (see Yuniardi Fig. 5#306, 6:5-19), the attachment area comprising a portion that comprises both (examiner notes that the claims describe a GUI including at least two areas and that the two UIs for selecting different versions are displayed in an area that is not a message area. Examiner notes that the claims do not prevent the interpretation that both UIs are part of a drop down menu. | see Yuniardi Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version; the drop down menu #502 illustrates four different selectable versions of an attachment and the drop down menu #502 is displayed in a different area #306 than where the message is displayed #304) the first UI element that is selectable to cause the computing system to retrieve the first version of the attachment (see Yuniardi Fig. 5 #502, 6:5-26: There are four versions that are selectable in the drop down menu #502 of Fig. 5 and users may select any of the different versions for display | examiner notes that this portion of the claim limitation describes UIs that are selectable for retrieving a particular version from its storage location, but does not describe performing a selection of one or multiple UIs either individually or simultaneously. Yuniardi’s Fig. 5 illustrates simultaneously displaying an email and a drop down menu that includes multiple selectable UIs that are each associated with a different version. Examiner notes that each option within a drop down menu #502 is selectable and that a particular version is displayed upon a user’s selection of one of the options displayed in the drop down menu #502. As such, examiner interprets each option in the drop down menu #502 as being functionally equivalent to a selectable UI that causes the computing system to retrieve the particular version associated with the corresponding option in the drop down menu) from the content management system (examiner notes that citations and explanations from parent claim 1 are incorporated into this claim limitation; see Savage [0127]: a version history stores previous versions and allows users to revert to older versions; [0142]: users retrieve existing documents directly from the document management system, i.e. versions are retrieved “from the content management system” | [0046]: a write task includes copying data from one location to another location, e.g., from an agent’s file system to a cloud-base storage device, peer-to-peer between two agents, etc., such that the source of the data can be a cloud-based or network-based storage device or a file system of any agent; [0051]: when an agent retrieves data that is needed to perform a task, the agent first searches locally, then searches peers, and then searches cloud-based storage or another remote storage entity) and the second UI element is selectable to cause the computing system to retrieve the second version of the attachment (see Yuniardi Fig. 5 #502, 6:5-26: There are four versions that are selectable in the drop down menu #502 of Fig. 5 and users may select any of the different versions for display | examiner notes that this portion of the claim limitation describes UIs that are selectable for retrieving a particular version from its storage location, but does not describe performing a selection of one or multiple UIs either individually or simultaneously. Yuniardi’s Fig. 5 illustrates simultaneously displaying an email and a drop down menu that includes multiple selectable UIs that are each associated with a different version. Examiner notes that each option within a drop down menu #502 is selectable and that a particular version is displayed upon a user’s selection of one of the options displayed in the drop down menu #502. As such, examiner interprets each option in the drop down menu #502 as being functionally equivalent to a selectable UI that causes the computing system to retrieve the particular version associated with the corresponding option in the drop down menu) from the content management system (examiner notes that citations and explanations from parent claim 1 are incorporated into this claim limitation; see Savage [0127]: a version history stores previous versions and allows users to revert to older versions; [0142]: users retrieve existing documents directly from the document management system, i.e. versions are retrieved “from the content management system” | [0046]: a write task includes copying data from one location to another location, e.g., from an agent’s file system to a cloud-base storage device, peer-to-peer between two agents, etc., such that the source of the data can be a cloud-based or network-based storage device or a file system of any agent; [0051]: when an agent retrieves data that is needed to perform a task, the agent first searches locally, then searches peers, and then searches cloud-based storage or another remote storage entity).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Savage to further clarify how document versions are tracked within a content management system. Including Savage’s teachings would provide a streamlined approach to file synchronization and file access (see Savage [0004]) while also improving efficiency when synchronizing changed files (see Savage [0042]), reducing costs associated with network attached storage (see Savage [0090]), and improving data transfer efficiency and data security (see Savage [0094]).
Regarding claim 11, the claim contains the limitations, substantially as claimed, as described in claim 4 above. Yuniardi-Savage-Costenaro disclosed, as recited in claim 11: The non-transitory computer readable medium of claim 8, further comprising:
receiving, by the computing system, an input interacting with the first UI element (see Yuniardi Fig. 2 #212, 5:23-37: detecting an input from the user indicating a desire to simultaneously view the message and attachment(s) | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 and users may select, e.g., via a drop down menu, any of the different versions for display);
responsive to receiving the input, retrieving, from the content management system (examiner notes that citations and explanations from parent claim 8 are incorporated into this claim limitation; see Savage [0127]: a version history stores previous versions and allows users to revert to older versions; [0142]: users retrieve existing documents directly from the document management system, i.e. versions are retrieved “from the content management system” | [0046]: a write task includes copying data from one location to another location, e.g., from an agent’s file system to a cloud-base storage device, peer-to-peer between two agents, etc., such that the source of the data can be a cloud-based or network-based storage device or a file system of any agent; [0051]: when an agent retrieves data that is needed to perform a task, the agent first searches locally, then searches peers, and then searches cloud-based storage or another remote storage entity), the first version of the attachment in response to the input (examiner notes that a version is retrieved from wherever it is located before it can be displayed; see Yuniardi Fig. 2 #212, 5:23-37: detecting an input from the user indicating a desire to simultaneously view the message and attachment(s) | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Savage to further clarify how document versions are tracked within a content management system. Including Savage’s teachings would provide a streamlined approach to file synchronization and file access (see Savage [0004]) while also improving efficiency when synchronizing changed files (see Savage [0042]), reducing costs associated with network attached storage (see Savage [0090]), and improving data transfer efficiency and data security (see Savage [0094]).
Regarding claim 12, the claim contains the limitations, substantially as claimed, as described in claim 5 above. Yuniardi-Savage-Costenaro disclosed, as recited in claim 12: The non-transitory computer readable medium of claim 8, further comprising:
receiving, by the computing system, an input interacting with the second UI element (see Yuniardi Fig. 2 #212, 5:23-37: detecting an input from the user indicating a desire to simultaneously view the message and attachment(s) | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 and users may select, e.g., via a drop down menu, any of the different versions for display); and
responsive to receiving the input, retrieving, by the computing system (examiner notes that citations and explanations from parent claim 8 are incorporated into this claim limitation; see Savage [0127]: a version history stores previous versions and allows users to revert to older versions; [0142]: users retrieve existing documents directly from the document management system, i.e. versions are retrieved “from the content management system” | [0046]: a write task includes copying data from one location to another location, e.g., from an agent’s file system to a cloud-base storage device, peer-to-peer between two agents, etc., such that the source of the data can be a cloud-based or network-based storage device or a file system of any agent; [0051]: when an agent retrieves data that is needed to perform a task, the agent first searches locally, then searches peers, and then searches cloud-based storage or another remote storage entity), the second version of the attachment from the content management system (examiner notes that a version is retrieved from wherever it is located before it can be displayed; see Yuniardi Fig. 2 #212, 5:23-37: detecting an input from the user indicating a desire to simultaneously view the message and attachment(s) | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Savage to further clarify how document versions are tracked within a content management system. Including Savage’s teachings would provide a streamlined approach to file synchronization and file access (see Savage [0004]) while also improving efficiency when synchronizing changed files (see Savage [0042]), reducing costs associated with network attached storage (see Savage [0090]), and improving data transfer efficiency and data security (see Savage [0094]).
Regarding claim 13, the claim contains the limitations, substantially as claimed, as described in claim 6 above. As recited in claim 13: Yuniardi-Savage-Costenaro disclosed the non-transitory computer-readable medium of claim 8, further comprising: causing display of a collapsible graphical element comprising the first UI element associated with the first version of the attachment and the second UI element associated with the second version of the attachment (examiner notes that a drop down menu is an example of a collapsible graphical element; Yuniardi’s Fig. 4 illustrates the collapsed drop down menu while Fig. 5 illustrates the expanded drop down menu #502 | see Yuniardi Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 and users may select, e.g., via a drop down menu, any of the different versions for display; examiner notes that Yuniardi’s drop-down menu including multiple versions is a type of collapsible graphical element comprising UI elements associated with the attachment version(s).).
Regarding claim 14, the claim contains the limitations, substantially as claimed, as described in claim 7 above. Yuniardi-Savage-Costenaro disclosed, as recited in claim 14: The non-transitory computer readable medium of claim 8, further comprising:
causing display of a first indication of a last edit time for the attachment and a second indication of a user account that last accessed the attachment (see Costenaro Fig. 6, [0060]: live summary information about the attachment includes when the content was last changed, who last viewed the content, and other types of information).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Costenaro to further clarify that shared documents are stored in network storage and to also clarify the types of information about an attachment that can be displayed. Expanding upon Yuniardi’s display of historical document versions and their changes (see Yuniardi 2:47-65) with Costenaro’s display of content summaries and status (see Costenaro Fig. 9) would improve a user’s ability to keep up with content changes (see Costenaro [0001]). Incorporating Costenaro’s teachings would also ensure that the changes are updated in real-time (see Costenaro [0026]) and the related information, e.g. changes and status, are tailored based on the user (see Costenaro [0036]).
Regarding claim 15, the claim contains the limitations, substantially as claimed, as described in claim 1 above. Yuniardi disclosed, as recited in claim 15: A system (see Yuniardi Fig. 1: system including multiple types of memory, processor, and other components | examiner notes that “a computer readable medium comprising one or more sequences of instructions, which, when executed by a processor, causes a computing system to perform operations” are inherent components of computers) comprising:
one or more processors (see Yuniardi Fig. 1 #104 processor | examiner notes that processors are inherent components of computers); and
a memory having programming instructions stored thereon, which, when executed by the one or more processors, causes the system to perform operations (see Yuniardi Fig. 1: multiple types of memory | examiner notes that “a computer readable medium comprising one or more sequences of instructions, which, when executed by a processor, causes a computing system to perform operations” are inherent components of computers) comprising:
identifying a first message received from a second computing system (see Yuniardi #206, 5:4-10: “Open Email Message”; Fig. 5, 6:5-19: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 | 5:4-22: selecting and opening an email message to read and also making attachments available for simultaneous viewing within the GUI of the email reader), wherein the first message includes an attachment (see Yuniardi Fig. 2 #208, 5:4-22: determining if email message has an attachment) that is accessible to the computing system and the second computing system (examiner also notes that this claim limitation slightly differs from the other independent claims in that it does not describe a content management system in this limitation; as such, the existence of an email attachment in Yuniardi art would teach this limitation since an email attachment is accessible to the sending system and also to the receiving system | see Yuniardi-Savage-Costenaro combination below);
identifying version information associated with the attachment included with the first message (see Yuniardi Fig. 5 #502, 6:5-36: drop down menu #502 provides the user with options to choose between different versions of an attached document such that each version is associated with a different option within the drop down menu #502. In order to populate the four options within the displayed drop down menu, the system inherently first identifies version information associated with the attachment);
based on the version information, determining that second version of the attachment exists (see Yuniardi Fig. 5, 6:5-36: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 and users may select any of the different versions for display or for making additional edits to the attachment);
causing display of the first message simultaneously with a first user interface (UI) element associated with a first version of the attachment and a second UI element associated with the second version of the attachment (see Yuniardi Fig. 2 #214, 5:38-45: simultaneous display of email and attachments | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions that are selectable in the drop down menu #502 of Fig. 5 and users may select any of the different versions for display, i.e. there are four UIs within the drop down menu #502 | examiner notes that this portion of the claim limitation describes displaying an email along with two UIs, each of which is associated with a version of the attachment, but does not describe displaying an attachment or version(s) of the attachment, much less displaying the attachment or version(s) along with the email and UIs. Yuniardi’s Fig. 5 illustrates simultaneously displaying an email and a drop down menu that includes multiple selectable UIs that are each associated with a different version), wherein the first UI element is selectable to cause the system to retrieve the first version of the attachment (see Yuniardi Fig. 5 #502, 6:5-26: There are four versions that are selectable in the drop down menu #502 of Fig. 5 and users may select any of the different versions for display, i.e. there are four UIs within the drop down menu #502 | examiner notes that this portion of the claim limitation describes UIs that are selectable for retrieving a particular version from its storage location, but does not describe performing a selection of one or multiple UIs either individually or simultaneously. Yuniardi’s Fig. 5 illustrates simultaneously displaying an email and a drop down menu that includes multiple selectable UIs that are each associated with a different version. Examiner notes that each option within a drop down menu #502 is selectable and that a particular version is displayed upon a user’s selection of one of the options displayed in the drop down menu #502. As such, examiner interprets each option in the drop down menu #502 as being functionally equivalent to a selectable UI that causes the computing system to retrieve the particular version associated with the corresponding option in the drop down menu) from a content management system (see Savage combination below regarding the retrieval of versions from the content management system and Yuniardi-Savage-Costenaro combination below regarding network storage of a message attachment) and the second UI element is selectable to cause the system to retrieve the second version of the attachment (see Yuniardi Fig. 5 #502, 6:5-26: There are four versions that are selectable in the drop down menu #502 of Fig. 5 and users may select any of the different versions for display, i.e. there are four UIs within the drop down menu #502 | examiner notes that this portion of the claim limitation describes UIs that are selectable for retrieving a particular version from its storage location, but does not describe performing a selection of one or multiple UIs either individually or simultaneously. Yuniardi’s Fig. 5 illustrates simultaneously displaying an email and a drop down menu that includes multiple selectable UIs that are each associated with a different version. Examiner notes that each option within a drop down menu #502 is selectable and that a particular version is displayed upon a user’s selection of one of the options displayed in the drop down menu #502. As such, examiner interprets each option in the drop down menu #502 as being functionally equivalent to a selectable UI that causes the computing system to retrieve the particular version associated with the corresponding option in the drop down menu) from the content management system (see Savage combination below regarding the retrieval of versions from the content management system and Yuniardi-Savage-Costenaro combination below regarding network storage of a message attachment);
receiving a status change corresponding to the attachment or the second version of the attachment (see Yuniardi Fig. 5 John edited: “1.20.20 and 2.20.20” to “1.10.32 and 1.10.33”: The email from John Smith includes a box that includes a notification that John edited the document in addition to the edits made; examiner notes that this notification is status change corresponding to one of the versions of the attachment and that the status change is inherently received before it can be displayed); and
causing, by the system, display of a graphical indication of the status change, wherein the graphical indication indicates that at least one of the attachment or the second version of the attachment is open or has been edited (examiner notes that the claims describe displaying a graphical indication of the status change, but the displayed graphical indication of the status change is not necessarily displayed along with the message, attachment, or version information UI elements described in previous limitations | see Yuniardi Fig. 5 John edited: “1.20.20 and 2.20.20” to “1.10.32 and 1.10.33”: The email from John Smith includes a box that includes a notification that John edited the document in addition to the edits made; examiner notes that this box including the notification is a graphical indication of the status change that indicates that one of the versions of the attachment has been edited).
With respect to the limitation “wherein the first message includes an attachment accessible to the computing system and the second computing system” and the first UI element being selectable “to cause the system to retrieve the first version of the attachment from a content management system” and the second UI element being selectable “to cause the system to retrieve the second version of the attachment from the content management system”:
Yuniardi did not explicitly disclose that the message attachment and/or its versions are able to be retrieved “from a content management system”.
However in a related art, Savage disclosed a cloud-based platform coupled to a system of agents, e.g., agents hosted on cloud-based storage devices, or folders hosted on client devices such that the content management system manages the distributed storage of shared content (see Savage [0026], Fig. 2). File sharing includes providing access to shared folders from which users can view and edit files within the folder and sync the changes to other users (see Savage [0130]) as well as providing file-in-use alerts for shared documents (see Savage [0132]) including email alerts when someone edits content (see Savage [0133]), i.e. shared documents are stored on and able to be retrieved “from a content management system”.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Savage to further clarify storing shared documents in a content management system. Including Savage’s teachings would provide a streamlined approach to file synchronization and file access (see Savage [0004]) while also improving efficiency when synchronizing changed files (see Savage [0042]), reducing costs associated with network attached storage (see Savage [0090]), and improving data transfer efficiency and data security (see Savage [0094]).
Examiner notes that while Savage disclosed shared documents are stored on a content management system and accessible to the computing system and the second computing system, Savage did not explicitly disclose that the shared document is an “attachment” to a message.
While it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that the type of document, i.e. message attachment, being stored on a content management system is a matter of implementation choice, however in a related art, Costenaro disclosed a network share that stores documents that are being collaborated on (see Costenaro [0023]) and that the document being collaborated on is an attachment to an electronic message (see Costenaro [0025]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi-Savage and Costenaro to further clarify the types of documents, e.g., message attachments, that are stored in a content management system, as well as additional details about the types of information about an attachment that can be displayed. Expanding upon Yuniardi’s display of historical document versions and their changes (see Yuniardi 2:47-65) with Costenaro’s display of content summaries and status (see Costenaro Fig. 9) would improve a user’s ability to keep up with content changes (see Costenaro [0001]). Incorporating Costenaro’s teachings would also ensure that the changes are updated in real-time (see Costenaro [0026]) and the related information, e.g. changes and status, are tailored based on the user (see Costenaro [0036]).
Yuniardi did not explicitly disclose that the versions of the attachments are able to be retrieved “from the content management system”. Examiner relies upon Costenaro above to describe the type of document, i.e. message attachment, being stored at the CMS.
Savage disclosed a cloud-based platform coupled to a system of agents, e.g., agents hosted on cloud-based storage devices, or folders hosted on client devices such that the content management system manages the distributed storage of shared content (see Savage [0026], Fig. 2) via a variety of databases included in the platform (see Savage [0033]). File sharing includes providing access to shared folders from which users can view and edit files within the folder and sync the changes to other users (see Savage [0130]) as well as providing file-in-use alerts for shared documents (see Savage [0132]) including email alerts when someone edits content (see Savage [0133]). Each agent indexes stored content and sends metadata for the index to the platform (see Savage [0031]) such that the platform stores metadata and the agents serve as distributed data storage entities at which actual data is stored (see Savage [0037]). Agents continuously report changes to any file in the directory (see Savage [0044]) and a sync database includes records of file states (see Savage [0088]). The platform receives hashes of data files from agents, generates a record for each file that includes information of various hashes, and uses this record to determine the state of the data and to identify if there are multiple versions located in the system (see Savage [0039]), e.g., via the file hash (see Savage [0063]). Hashes are used to enable versioning so that older versions of a file are able to be created (see Savage [0062]) and are also used to identify when an agent has an out-of-date version (see Savage [0063]), e.g., platform identifies two different hashes H and H2 for the same file and determines that there are two versions stored in the system (see Savage [0083]).
A version history stores previous versions and allows users to revert to older versions (see Savage [0127]) and users retrieve existing documents directly from the document management system (see Savage [0142]), i.e. versions are retrieved “from the content management system”. The platform distributes tasks to agents (see Savage [0036]), e.g., tasks for scanning, deleting, writing, and uploading (see Savage [0045]) as well as tasks to provide file(s) to an application (see Savage [0091]). A write task includes copying data from one location to another location, e.g., from an agent’s file system to a cloud-base storage device, peer-to-peer between two agents, etc., such that the source of the data can be a cloud-based or network-based storage device or a file system of any agent (see Savage [0046]), i.e. content is retrieved “from the content management system”. When an agent retrieves data that is needed to perform a task, the agent first searches locally, then searches peers, and then searches cloud-based storage or another remote storage entity (see Savage [0051]), i.e. content is retrieved “from the content management system”.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Savage to further clarify how document versions are tracked within a content management system. Including Savage’s teachings would provide a streamlined approach to file synchronization and file access (see Savage [0004]) while also improving efficiency when synchronizing changed files (see Savage [0042]), reducing costs associated with network attached storage (see Savage [0090]), and improving data transfer efficiency and data security (see Savage [0094]).
Regarding claim 16, the claim contains the limitations, substantially as claimed, as described in claim 2 above. Yuniardi-Savage-Costenaro disclosed, as recited in claim 16: The system of claim 15, wherein the operations further comprise:
receiving, from a content management system, a state information report indicating that the attachment exists (see Savage [0035]: sync databases in the cloud include metadata on the location and state of all data in the system | [0039]: The platform receives hashes of data files from agents, generates a record for each file that includes information of various hashes, and uses this record to determine the state of the data and to identify if there are multiple versions located in the system, e.g., [0063]: multiple versions are identified via the file hash and a task to reconcile the different versions is sent from the platform to the agent | [0071]: each agent includes a global library including the current state of all files in the libraries accessible to the agent; [0083]: agents receive updates for synchronizing libraries and content | examiner notes that libraries include state information reports for each file and that sending a library or update to a library is functionally equivalent to sending/receiving a state information report indicating that a file exists) in a shared folder managed by the content management system (see Savage [0130]: File sharing includes providing access to shared folders from which users can view and edit files within the folder and sync the changes to other users | [0026], Fig. 2: a cloud-based platform coupled to a system of agents, e.g., agents hosted on cloud-based storage devices, or folders hosted on client devices such that the content management system manages the distributed storage of shared content; [0035]: content management system platform acts as a universal synchronization engine and master controller for the agents storing the data) and that the content management system stores both the first version of the attachment and the second version of the attachment (see Savage [0035]: sync databases in the cloud include metadata on the location and state of all data in the system | [0062]: Hashes are used to enable versioning so that older versions of a file are able to be created; [0063]: multiple versions are identified via the file hash and a task to reconcile the different versions is sent from the platform to the agent, i.e. there are at least two versions stored on the content management system | [0083]: agents receive updates for synchronizing libraries and content | [0127]: a version history stores previous versions and allows users to revert to older versions), wherein determining that the content management system stores the second version of the attachment is based on the state information report from the content management system (see Savage [0035]: sync databases in the cloud include metadata on the location and state of all data in the system | [0039]: The platform receives hashes of data files from agents, generates a record for each file that includes information of various hashes, and uses this record to determine the state of the data and to identify if there are multiple versions located in the system, e.g., [0063]: multiple versions are identified via the file hash and a task to reconcile the different versions is sent from the platform to the agent | [0071]: each agent includes a global library including the current state of all files in the libraries accessible to the agent; [0083]: agents receive updates for synchronizing libraries and content | examiner notes that libraries include state information reports for each file and that sending/receiving a sync command or update to a library is functionally equivalent to determining that there is another version stored in the content management system based on a state information report).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Savage to further clarify how document versions are tracked within a content management system. Including Savage’s teachings would provide a streamlined approach to file synchronization and file access (see Savage [0004]) while also improving efficiency when synchronizing changed files (see Savage [0042]), reducing costs associated with network attached storage (see Savage [0090]), and improving data transfer efficiency and data security (see Savage [0094]).
Regarding claim 17, the claim contains the limitations, substantially as claimed, as described in claim 3 above. Yuniardi-Savage-Costenaro disclosed, as recited in claim 17: The system of claim 15, further comprising:
causing, by the computing system, display of a message area (see Yuniardi Fig. 5#304, 6:5-19) and an attachment area (see Yuniardi Fig. 5#306, 6:5-19), the attachment area comprising a portion that comprises both (examiner notes that the claims describe a GUI including at least two areas and that the two UIs for selecting different versions are displayed in an area that is not a message area. Examiner notes that the claims do not prevent the interpretation that both UIs are part of a drop down menu. | see Yuniardi Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version; the drop down menu #502 illustrates four different selectable versions of an attachment and the drop down menu #502 is displayed in a different area #306 than where the message is displayed #304) the first UI element that is selectable to cause the computing system to retrieve the first version of the attachment (see Yuniardi Fig. 5 #502, 6:5-26: There are four versions that are selectable in the drop down menu #502 of Fig. 5 and users may select any of the different versions for display | examiner notes that this portion of the claim limitation describes UIs that are selectable for retrieving a particular version from its storage location, but does not describe performing a selection of one or multiple UIs either individually or simultaneously. Yuniardi’s Fig. 5 illustrates simultaneously displaying an email and a drop down menu that includes multiple selectable UIs that are each associated with a different version. Examiner notes that each option within a drop down menu #502 is selectable and that a particular version is displayed upon a user’s selection of one of the options displayed in the drop down menu #502. As such, examiner interprets each option in the drop down menu #502 as being functionally equivalent to a selectable UI that causes the computing system to retrieve the particular version associated with the corresponding option in the drop down menu) from the content management system (examiner notes that citations and explanations from parent claim 1 are incorporated into this claim limitation; see Savage [0127]: a version history stores previous versions and allows users to revert to older versions; [0142]: users retrieve existing documents directly from the document management system, i.e. versions are retrieved “from the content management system” | [0046]: a write task includes copying data from one location to another location, e.g., from an agent’s file system to a cloud-base storage device, peer-to-peer between two agents, etc., such that the source of the data can be a cloud-based or network-based storage device or a file system of any agent; [0051]: when an agent retrieves data that is needed to perform a task, the agent first searches locally, then searches peers, and then searches cloud-based storage or another remote storage entity) and the second UI element is selectable to cause the computing system to retrieve the second version of the attachment (see Yuniardi Fig. 5 #502, 6:5-26: There are four versions that are selectable in the drop down menu #502 of Fig. 5 and users may select any of the different versions for display | examiner notes that this portion of the claim limitation describes UIs that are selectable for retrieving a particular version from its storage location, but does not describe performing a selection of one or multiple UIs either individually or simultaneously. Yuniardi’s Fig. 5 illustrates simultaneously displaying an email and a drop down menu that includes multiple selectable UIs that are each associated with a different version. Examiner notes that each option within a drop down menu #502 is selectable and that a particular version is displayed upon a user’s selection of one of the options displayed in the drop down menu #502. As such, examiner interprets each option in the drop down menu #502 as being functionally equivalent to a selectable UI that causes the computing system to retrieve the particular version associated with the corresponding option in the drop down menu) from the content management system (examiner notes that citations and explanations from parent claim 1 are incorporated into this claim limitation; see Savage [0127]: a version history stores previous versions and allows users to revert to older versions; [0142]: users retrieve existing documents directly from the document management system, i.e. versions are retrieved “from the content management system” | [0046]: a write task includes copying data from one location to another location, e.g., from an agent’s file system to a cloud-base storage device, peer-to-peer between two agents, etc., such that the source of the data can be a cloud-based or network-based storage device or a file system of any agent; [0051]: when an agent retrieves data that is needed to perform a task, the agent first searches locally, then searches peers, and then searches cloud-based storage or another remote storage entity).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuniardi and Savage to further clarify how document versions are tracked within a content management system. Including Savage’s teachings would provide a streamlined approach to file synchronization and file access (see Savage [0004]) while also improving efficiency when synchronizing changed files (see Savage [0042]), reducing costs associated with network attached storage (see Savage [0090]), and improving data transfer efficiency and data security (see Savage [0094]).
Regarding claim 18, the claim contains the limitations, substantially as claimed, as described in claim 4 above. Yuniardi-Savage-Costenaro disclosed, as recited in claim 18: The system of claim 15, wherein the operations further comprise:
receiving an input interacting with the first UI element (see Yuniardi Fig. 2 #212, 5:23-37: detecting an input from the user indicating a desire to simultaneously view the message and attachment(s) | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 and users may select, e.g., via a drop down menu, any of the different versions for display);
responsive to receiving the input, causing display of the first version of the attachment (Examiner notes that the claims do not require displaying the first version of the attachment along with the email, but rather allows for the interpretation that the attachment is opened in another window or another application | see Yuniardi Fig. 2 #214, 5:23-45: simultaneous display of email and attachments in response to input received in #212 | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 and users may select, e.g., via a drop down menu, any of the different versions for display).
Regarding claim 19, the claim contains the limitations, substantially as claimed, as described in claim 5 above. Yuniardi-Savage-Costenaro disclosed, as recited in claim 19: The system of claim 15, wherein the operations further comprise:
receiving an input interacting with the second UI element (see Yuniardi Fig. 2 #212, 5:23-37: detecting an input from the user indicating a desire to simultaneously view the message and attachment(s) | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 and users may select, e.g., via a drop down menu, any of the different versions for display); and
responsive to receiving the input, causing display of the second version of the attachment (Examiner notes that the claims do not require displaying the first version of the attachment along with the email, but rather allows for the interpretation that the attachment is opened in another window or another application | see Yuniardi Fig. 2 #214, 5:23-45: simultaneous display of email and attachments in response to input received in #212 | Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 and users may select, e.g., via a drop down menu, any of the different versions for display).
Regarding claim 20, the claim contains the limitations, substantially as claimed, as described in claim 6 above. As recited in claim 20: Yuniardi-Savage-Costenaro disclosed the system of claim 15, wherein the operations further comprise: causing display of a collapsible graphical element comprising the first UI element associated with the first version of the attachment and the second UI element associated with the second version of the attachment (examiner notes that a drop down menu is an example of a collapsible graphical element; Yuniardi’s Fig. 4 illustrates the collapsed drop down menu while Fig. 5 illustrates the expanded drop down menu #502 | see Yuniardi Fig. 5, 6:5-26: simultaneously displaying a message(s), a particular version of the attachment, as well as UI elements for each additional version, e.g., there are four versions within the example of Fig. 5 and users may select, e.g., via a drop down menu, any of the different versions for display; examiner notes that Yuniardi’s drop-down menu including multiple versions is a type of collapsible graphical element comprising UI elements associated with the attachment version(s).).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Angela Widhalm de Rodriguez whose telephone number is (571)272-1035. The examiner can normally be reached M-F: 6am-2:30pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Nicholas Taylor can be reached at (571)272-3889. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ANGELA WIDHALM DE RODRIGUEZ/Examiner, Art Unit 2443