DETAILED ACTION
This communication is in response to the Applicant Arguments/Remarks filed 9/18/2025. Claims 1-20 are pending in the application.
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 . 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.
Response to Arguments
Applicant's arguments filed 9/18/2025 have been fully considered.
Regarding the arguments on page 9 that Shahine in figs. 2B-2C “As shown, the "allow editing" feature (and its associated deselection) is to provide a shared link to the editable file for a user (raflop). It does not enable the file stored on the ShareDrive Server to be frozen from editing while an editable copy of the file is provided to the external user raflop. Thus, Shahine does not disclose at least "marking, by the content server, the first item as read-only so that any modification to the first item is not allowed, wherein the first item is retained by the content server", examiner respectfully disagrees.
Claim 1 recites:
“receiving, by a content server having a processor and a memory, an indication from a first user to share a first item with a second user through an external system operating outside of an enterprise computing environment, the first item having a first unique identifier and managed by the content server in the enterprise computing environment;
generating, by the content server, a copy of the first item; marking, by the content server, the first item as read-only so that any modification to the first item is not allowed, wherein the first item is retained by the content server;”
The limitations above do not contain the limitation “while an editable copy of the file is provided to the external user raflop”.
However, Shahine et al. discloses in fig. 2B that a file can be shared to anyone, specific people, etc. In addition, if the “Allow editing” checkbox is not selected on the interface 200, the first file is not allowed for modification/editing and vice versa and if the “Prevent download” is not checked, the shared file is allowed to be copied and downloaded from its shared location like a server/cloud drive to the external user device. Thus, the external second user does not have access to the first user file or the first item/file is locked from the second user from editing. The sharing settings allow the first user to share a copy of a file that is downloaded to an external second user device.
Sturonas was cited also to teach marking, by the content server, the first item as read-only so that any modification to the first item is not allowed.
See para. 14: shared open network storage may be owned, or managed by one or more members who are authorized to manage this information. A manager may also be referred to as a moderator. The moderator may accept, approve, or deny changes made to shared information by other members. The moderator may allow or deny other members access to shared information. Other members may be granted less or different access such as they may be able to read or copy information in or about the shared information storage, but they may not be allowed to decrypt or alter it, although they may copy and use that information in another private space that is separate from the shared access of the other members. Thus, either a shared/second user or other members are not allowed to modify the first item/file.
See also para. 85: Shared folder-The shared folder or the SFRS share may be a shared folder in Drop box encrypted by SFRS. It may be read-only;
para. 91, 293-296: when sharing a folder, moderator is able to select between read-write or read-only access levels. The access level may be identified with a corresponding tag in the folder's SMOD file.
Regarding the arguments on page 10 that “The Office Action relies on Shahine for disclosure of the receiving step, citing FIG. 2C. See Office Action at pg. 7-8. The expiration of the shared link cause the link to no longer function in Shahine. The citations to Shahine do not suggest a subsequent retrieval of the once-shared document. As such, it is unclear how Shahine can then be modified to retrieve a previously shared document when subsequent retrieval is not contemplated by Shahine. Specifically, Shahine states in [0036] that the shared link will no longer function after the expiration date. Roublev is then relied upon for alleged disclosure of the retrieving step. However, in Roublev, at [0034], the file set or file is archived and placed in a read-only state after modifications have been made to the file. Roublev does not mark a file as read-only at the content server and then retrieve a latest version of a copy of the first item comprising modifications. The citations to Sturonas and Ford fail to cure the above-mentioned deficiencies of Shahine and Roublev. As set forth at [0080]-[0082], Sturonas discloses a method of synchronizing encrypted data that is fundamentally different from the claimed subject matter. Further, Ford at [0127] teaches sharing a read-only file, which is in direct contradiction to the claimed subject matter. The cited combination of references does not disclose or suggest Claim 1”, examiner respectfully disagrees.
Claim 1 recites:
"receiving, by the content server, an indication from the first user to stop sharing the copy of the first item" and
"retrieving, by the content server, a latest version of the copy of the first item, the latest version of the copy of the first item comprising modifications to the first item."
Regarding the argument: “The expiration of the shared link cause the link to no longer function in Shahine”, examiner finds that Shahine teaches in fig. 2B-C that a user as shown in interface 200 is able to set an expiration date when sharing a file. Such extra feature has been widely practiced in collaboration of users working on a shared project. Said expiration date, however, is equivalent to “receiving, by the content server, an indication from the first user to stop sharing the copy of the first item”. However, stop sharing can also be set at anytime when the first user changes the Link Settings to uncheck the shared name.
Sturonas at para. 490 discloses a moderator is a member having authority to allow, deny, or revoke shared access abilities of other members; para. 328: moderator selects his shared folder and picks "Unshare" option in the SFRS UI; para. 360-361: if any of the shared folders are no longer accessible using Drop box (unshared or kicked out), user is informed/notified that if she wants to restore access to that folder s/he needs to request that folder to be re-shared with her by the moderator. Therefore, the user is notified that the copy/item is no longer shared and request for file resharing if necessary.
Ford et al. further teaches at para. 127: an enterprise knowledge worker `Fred` (e.g. internal counsel) is collaborating with a chief information officer `George` who works at the same company as Fred, and an external partner `Pam` (e.g. external counsel). Fred may now want to share some confidential files with Pam, such as though a virtual secure data room facility, with the ability to `pull-back` the document from Pam at anytime through the un-sharing facility. Fred decides to remediate, such as by un-sharing the document from Pam's access, as implemented through the dashboard facility, and the like. He may then, for instance, choose to share the files as read-only. Fred sees that Pam has finished her task, such as though the dashboard facility, opens the annotated file and syncs (e.g. via SharePoint). The project may have been a loan syndication project, and once complete, Fred may completely eliminate accessibility to documents and communications that were transmitted during the transaction, such as removing access to any documents that were transmitted during execution of the project. Pam revokes files when the project is completed, and files are wiped from her devices, such as the system pulling back the files as tracked by the system in a secure database created for the project (which in itself may be deleted once the project is complete). Which is equivalent to the argued limitation: "retrieving, by the content server, a latest version of the copy of the first item, the latest version of the copy of the first item comprising modifications to the first item." Thus, the combination of the cited references does teach the argued limitations.
The teachings of Roblev were no longer applied in this current Office action since the amended limitations changed the scope of the claim.
Claim Rejections - 35 USC § 103
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.
Claim(s) 1-3, 5-10, 12-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shahine et al. (US 20180343243) in view of Sturonas et al. (US 20140115329) and further in view of Ford et al. (US 2013/0318589).
As per claims 1, 8 and 15, Shahine et al. teaches
a method for content sharing through external systems, comprising: receiving, by a content server having a processor and a memory, an indication from a first user to share a first item with a second user through an external system operating outside of an enterprise computing environment (fig. 5: receive sharing link communication; col. 4: provide access to electronic content stored in the data store; para. 32: access control includes a listing of one or more domains or tenants, and organizational content scope information indicating whether external sharing is allowed for that particular domain or tenant; para. 36: a user interface allowing a user to specify secure external sharing, user Joe Smith has authenticated and is viewing a listing of his files, has identified file “2017 Planning Doc” for potential sharing. This is done by highlighting or otherwise selecting the file indicated in the shaded region at reference numeral 202 and then engaging user interface element 204 to begin the sharing process; para. 53: share a file/a first item; fig. 1: data store, API, link generation, access control, messaging; fig. 2F: an indication/message: Joe Smith shared “2017 Planning Doc” with you);
the first item having a first unique identifier and managed by the content server in the enterprise computing environment (para. 57: settings that tailor the application for a specific enterprise or user; para. 70-73: the computer 810 is operated in a networked environment using logical connections to one or more remote computers. The remote computer may be a personal computer, a hand-held device, a server, a router, a network PC, a peer device or other common network node etc. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet. A user interface component is configured to receive an indication of an external user with which to share an item of electronic content. A link generation component is configured to generate a link to share the item of electronic content; para. 37: the file name “2017 Planning Doc”/unique identifier is shown under the “Share Link” header of pane 206: share to specific people, allow editing, prevent download, set expiration date etc... – See fig. 2A. Additionally, the permissions provided to the one or more users by virtue of the share link are shown in permissions field);
marking, by the content server, the item as read-only so that any modification to the item is not allowed, wherein the first item is retained by the content server (figs. 2B-C: that a file can be shared to anyone, specific people, etc. In addition, if the “Allow editing” checkbox is not selected on the interface 200, the first file is not allowed for modification/editing and vice versa and if the “Prevent download” is not checked, the shared file is allowed to be copied and downloaded from its shared location like a server/cloud drive to the external user device. Thus, the external second user does not have access to the first user file or the first item/file is locked from the second user from editing. The sharing settings allow the first user to share a copy of a file that is downloaded to an external second user device; para. 40: the sharer of the selected item(s) of electronic content may set one or more permissions relative to allowed activities that the recipient of the sharing operation can perform on the selected item(s) of content. Examples of activities include reading, modifying, deleting, etc.);
displaying, on a user interface, an icon indicating that the item is locked from editing (figs. 2A-C, item 216: if the allow editing box is not checked, the user cannot edit the shared item; sharing icons as locks or shared on the user interface; para. 36: the user can select whether the recipient of the sharing link may be allowed to edit the item of electronic content, as indicated at field 220);
receiving, by the content server, an indication from the first user to stop sharing the copy of the item (fig. 2B-C that a user as shown in interface 200 is able to set an expiration date when sharing a file. Such extra feature has been widely practiced in collaboration of users working on a shared project. Said expiration date is equivalent to an indication from the first user when to stop sharing the copy of the first item. However, stop sharing can also be set at any time when the first user changes the Link Settings to uncheck the shared name; para. 33: messaging component include code and/or suitable circuitry to surface such messages or notifications within the application
executing upon such user devices. Thus, sharing invitations, messages in relating to expired sharing periods are indications in relating to sharing files);
Shahine does not explicitly teach generating, by the content server, a copy of the item.
Sturonas teaches
generating, by the content server, a copy of the first item (fig. 8: users use Dropbox app for sharing files/folders; para. 53-55: user A places an unencrypted file to share with user B into the shared folder, the SFRS encrypts the file from User A using the SK to form an encrypted file, then encrypted file is transferred to Dropbox and Dropbox copies the encrypted file to Dropbox cloud storage. User A shares the shared folder with User B using the folder sharing controls provided by Dropbox. Additionally, the Secure Folder Replication System (SFRS) sends a share invitation to User B; para. 471: computer storage may use physical disk storage or virtual disk storage. Storage may be maintained by physical or virtual management server systems used to manage and
access this storage by users. Storage may be contained within a single location, or geographically dispersed. Storage may be implemented as a "cloud" architecture);
marking, by the content server, the first item as read-only so that any modification to the first item is not allowed, wherein the first item is retained by the content server (para. 14: shared open network storage may be owned, or managed by one or more members who are authorized to manage this information. A manager may also be referred to as a moderator. The moderator may accept, approve, or deny changes made to shared information by other members. The moderator may allow or deny other members access to shared information. Other members may be granted less or different access such as they may be able to read or copy information in or about the shared information storage, but they may not be allowed to decrypt or alter it, although they may copy and use that information in another private space that is separate from the shared access of the other members. Thus, other members are not allowed to modify the first item/file; para. 85: Shared folder-The shared folder or the SFRS share may be a shared folder in Drop box encrypted by SFRS. It may be read-only; para. 91, 293-296: when sharing a folder, moderator is able to select between read-write or read-only access levels. The access level may be identified with a corresponding tag in the folder's SMOD file);
communicating, by the content server, the copy of the first item and information identifying the second user to the external system (para. 53-58: User A places an unencrypted file to share with User B into the shared folder, the SFRS encrypts the file from User A using the SK to form an encrypted file, then encrypted file is transferred to Dropbox and Dropbox copies the encrypted file to Dropbox cloud storage. The SFRS decrypts the SK using the SID of User B. Then the SFRS decrypts User A's file using the decrypted SK and places the decrypted file into the SFRS folder of User B. Finally, User B accesses an unencrypted version of the file shared by User A; para. 69);
receiving, by the content server from the external system, a second unique identifier identifying the copy of the first item; storing, by the content server, the first unique identifier identifying the first item and the second unique identifier identifying the copy of the item in a data structure maintained by the content server to establish a revocable association between the first item and the copy of the first item (para. 68: at least one configurable folder that is monitored by the application software (SFRS). Such folder has a parallel folder maintained within the sharing service (one example is Dropbox) - this is identified as a cloud-replicated folder. A cloud-replicated folder is a folder provided and maintained by Dropbox storage; para. 129-130: User B operates similarly to User A. That is, User B's SFRS B may receive decrypted files, PID, metadata, SID, and SK determined locally and provides the encrypted filed PID and metadata to the local dropbox folder; para. 360: the SFRS keeps track on the list of shared folders available to it (compare the actual list of shared folders to the structure in the SFRS cloud cache). Therefore, shared files are identified and tracked in relating to access rights/permission: read only, read write etc.)
receiving, by the content server, an indication from the first user to stop sharing the copy of the first item (para. 328: moderator selects his shared folder and picks "Unshare" option in the SFRS UI; para. 360-361: if any of the shared folders are no longer accessible using Drop box (unshared or kicked out), user is informed/notified that if she wants to restore access to that folder s/he needs to request that folder to be re-shared with her by the moderator);
retrieving, by the content server and from the external system, a latest version of the copy of the first item, the latest version of the copy of the first item comprising modifications to the first item (para. 80-82: sync of encrypted data and provides secure storage and sharing for files and folders within the tunnel, thus, storing new version of the item; para. 333, 284: re-encryption is performed over a temporary copy of original data. The original data (both locally and in the cloud) is replaced with the re-encrypted data only after re-encryption has been fully completed);
removing, by the content server, the marking of the first item as read-only;
updating, by the content server, the data structure to remove the revocable association between the first unique identifier and the second unique identifier (para. 360-361: the SFRS keeps track on the list of shared folders available to it (compare the actual list of shared folders to the structure in the SFRS cloud cache. If any of the shared folders are no longer accessible using Drop box (unshared or kicked out), the SFRS removes all the metadata for such folders from both the local and cloud cache (including the SKs and 'blocked' markers)).
Thus, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Shahine and the remove the association between first and second unique identifier of Sturonas in order to effectively manage shared files/items between users and/or systems.
Shahine, Sturonas et al. do not explicitly teach reconciling, by the content server, the retrieved latest version of the copy of the first item by updating the first item with the retrieved latest version of the copy of the first item; and updating, by the content server, the data structure to remove the revocable association between the first unique identifier and the second unique identifier,
Ford teaches
reconciling, by the content server, the retrieved latest version of the copy of the first item by updating the first item with the retrieved latest version of the copy of the first item; and updating, by the content server, the data structure to remove the revocable association between the first unique identifier and the second unique identifier (para. 6: securely share/un-share contents to a user/group of users, access to the content may be revoked at any time (e.g. by changing the DRM (digital rights management), removing access to the key, changing permissions, and the like); para. 127: an enterprise knowledge worker `Fred` (e.g. internal counsel) is collaborating with a chief information officer `George` who works at the same company as Fred, and an external partner `Pam` (e.g. external counsel). Fred may now want to share some confidential files with Pam, such as though a virtual secure data room facility, with the ability to `pull-back` the document from Pam at anytime through the un-sharing facility. Fred decides to remediate, such as by unsharing the document from Pam's access, as implemented through the dashboard facility, and the like. He may then, for instance, choose to share the files as read-only. Fred sees that Pam has finished her task, such as though the dashboard facility, opens the annotated file and syncs (e.g. via SharePoint) - which is equivalent to reconciling… the first item. The “ability to pullback the document from Pam by un-sharing the document, thus, revoke the association of said first file and second file/copy and update the first file with modifications. The project may have been a loan syndication project, and once complete, Fred may completely eliminate accessibility to documents and communications that were transmitted during the transaction, such as removing access to any documents that were transmitted during execution of the project. Pam revokes files when the project is completed, and files are wiped from her devices, such as the system pulling back the files as tracked by the system in a secure database created for the project (which in itself may be deleted once the project is complete).
Thus, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Shahine, Sturonas, and the updating the item with the retrieved copy of the item of Ford et al. to effectively allow users to collaborate, share tasks and update/combine results between remote computer systems.
As per claims 2, 9, 16, Shahine et al. does not explicitly teach said claims.
Sturonas teaches
performing a look-up function on the second user through a secure communication link to the external system (para. 200: the SFRS/ Secure Folder Replication System app looks for the SID in the local cache folder/local secure storage; fig. 2: local cache 220 of user computer 210).
Thus, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Shahine and the secure communication link/SFRS of Sturonas in order to effectively track and/or communicate securely of shared files/items to the remote users/systems.
As per claims 3, 10, 17, Shahine does not explicitly teach said claims
Sturonas et al. teaches
notifying the external system that the copy of the first item is no longer shared (para. 74, 110-111: the unshared may be an action performed by, or on behalf of a moderator of a share excluding all other users from the share. Unsharing may include re-encrypting all data within the share using a private key. The moderator lock may be a way for a moderator to prevent access to a shared folder thereby locking out other members for some duration; para. 328: moderator selects his shared folder and picks "Unshare" option in the SFRS UI or share extension; para. 333, 284: re-encryption is performed over a temporary copy of original data. The original data (both locally and in the cloud) is replaced with the re-encrypted data only after re-encryption has been fully completed; para. 360-361: if any of the shared folders are no longer accessible using Drop box (unshared or kicked out), user is informed that if s/he wants to restore access to that folder s/he needs to request that folder to be re-shared with her by the moderator. Therefore, the user is notified that the copy/item is no longer shared).
Thus, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Shahine and the replacing/updating/synching the item with the copy of the item and notify the user/external system of the unsharing item(s) of Sturonas in order to effectively manage the sharing of files/items to the remote users/systems.
As per claims 5, 12, 18, Shahine does not explicitly teach said claims
Sturonas et al. teaches
storing the copy of the first item as a new version of the first item; and notifying the external system that the copy of the first item is no longer shared (para. 80-82: sync of encrypted data and provides secure storage and sharing for files and folders within the tunnel, thus, storing new version of the item; para. 328: moderator selects his shared folder and picks "Unshare" option in the SFRS UI or share extension; para. 333, 284: re-encryption is performed over a temporary copy of original data. The original data (both locally and in the cloud) is replaced with the re-encrypted data only after re-encryption has been fully completed; para. 360-361: if any of the shared folders are no longer accessible using Drop box (unshared or kicked out), user is informed/notified that if she wants to restore access to that folder s/he needs to request that folder to be re-shared with her by the moderator. Therefore, the user is notified that the copy/item is no longer shared).
Thus, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Shahine and the replacing/updating/synching the item with the copy of the item and notify the user/external system of the unsharing item(s) of Sturonas in order to effectively manage the sharing of files/items to the remote users/systems.
As per claims 6, 13, 19, Shahine and Sturonas et al. do not explicitly teach said claims
Ford teaches
wherein the latest version of the copy of the first item comprises modifications to the first item (para. 127: an enterprise knowledge worker `Fred` (e.g. internal counsel) is collaborating with a chief information officer `George` who works at the same company as Fred, and an external partner `Pam` (e.g. external counsel). Fred may now want to share some confidential files with Pam, such as though a virtual secure data room facility, with the ability to `pull-back` the document from Pam at anytime through the un-sharing facility. Fred decides to remediate, such as by un-sharing the document from Pam's access, as implemented through the dashboard facility, and the like. He may then, for instance, choose to share the files as read-only. Fred sees that Pam has finished her task, such as though the dashboard facility, opens the annotated file and syncs (e.g. via SharePoint) - which is equivalent to reconciling… the first item. The “ability to pullback the document from Pam by un-sharing the document, thus, revoke the association of said first file and second file/copy and update the first file with modifications from the shared file. The project may have been a loan syndication project, and once complete, Fred may completely eliminate accessibility to documents and communications that were transmitted during the transaction, such as removing access to any documents that were transmitted during execution of the project. Pam revokes files when the project is completed, and files are wiped from her devices, such as the system pulling back the files as tracked by the system in a secure database created for the project (which in itself may be deleted once the project is complete).
Thus, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Shahine, Sturonas, and the updating the item with the retrieved copy of the item of Ford et al. to effectively allow users to collaborate, share tasks and update/combine results between remote computer systems.
As per claims 7, 14, 20, Shahine teaches at fig. 2C: item 224: a user sets an expiration date to stop sharing or when the link will no longer function; para. 36: user Joe Smith can set an expiration date using user interface element 224 that specifies a date in the future when the link will no longer function; para. 33: messaging component include code and/or suitable circuitry to surface such messages or notifications within the application executing upon such user devices. Thus, sharing invitations, messages in relating to expired sharing periods are indications in relating to sharing files.
Shahine and Sturonas et al. do not explicitly teach said claims.
Ford et al. teaches
wherein the reconciling comprises storing the latest version of the copy of the first item as a new version of the first item; the method further comprising notifying the external system that the copy of the first item is no longer shared
(para. 127: an enterprise knowledge worker `Fred` (e.g. internal counsel) is collaborating with a chief information officer `George` who works at the same company as Fred, and an external partner `Pam` (e.g. external counsel). Fred may now want to share some confidential files with Pam, such as though a virtual secure data room facility, with the ability to `pull-back` the document from Pam at anytime through the un-sharing facility. Fred decides to remediate, such as by un-sharing the document from Pam's access, as implemented through the dashboard facility, and the like. He may then, for instance, choose to share the files as read-only. Fred sees that Pam has finished her task, such as though the dashboard facility, opens the annotated file and syncs (e.g. via SharePoint) - which is equivalent to reconciling… the first item. The “ability to pullback the document from Pam by un-sharing the document, thus, revoke the association of said first file and second file/copy and update the first file with modifications from the shared file. The project may have been a loan syndication project, and once complete, Fred may completely eliminate accessibility to documents and communications that were transmitted during the transaction, such as removing access to any documents that were transmitted during execution of the project. Pam revokes files when the project is completed, and files are wiped from her devices, such as the system pulling back the files as tracked by the system in a secure database created for the project (which in itself may be deleted once the project is complete).
Thus, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Shahine, Sturonas, and the updating the item with the retrieved copy of the item of Ford et al. to effectively allow users to collaborate, share tasks and update/combine results between remote computer systems.
Claim(s) 4, 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shahine et al. (US 20180343243) in view of Sturonas et al. (US 20140115329) and further in view of Ford et al. (US 2013/0318589) and Yi (US 20110296308).
As per claims 4, 11, Sturonas teaches in fig. 2A: sharing icons or lock icons are displayed on the Sharing column.
Shahine, Sturonas, Ford do not explicitly teach removing the icon from the user interface.
Yi teaches
removing the icon from the user interface (figs. 10a-b: a lock icon is placed on the image and the lock icon can be removed from the user interface by click Yes to the sharing the private image/change the sharing setting).
Thus, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Shahine, Sturonas, Ford and the removing of icon on the interface in relating to the file sharing setting of Yi in order to effectively track and/or display to the users access right settings of shared files/items.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Phatak (US 20030186861) discloses at para. 34: transfer (i) copies of data files that the associated workstation desires to access, (ii) file update data representative of on any data file modifications entered by authorized workstations that access the data file, and (iii) data associated with the operating features of the storage caching protocol system 12.
Meyer et al. (US 20140047560) at para. 138: sharing, unsharing documents between internal and external users of an enterprise.
Edlund et al. (US 20080016129) teaches at para. 6-7: a system performing automatic on-demand replication within a replication cluster of content management servers, each content management server comprising a content management application dynamically performing at least one of the creation, modification and deletion of an application item type, a schema manager handling at least one of the creation, modification, and deletion of a physical table storing the application item type, and a replication manager receiving the application item type and associated physical table, and automatically forwarding said received application item type on-demand to replication managers of other content management servers within the replication cluster.
Ford et al. (20150310188) teaches at para. 181-183: the system may integrate the sharing capability with other third-party environments, such as including existing file sharing solutions (e.g. Dropbox, Google Drive, Skydrive, Box.com, MediaFire, SugarSync, TitanFile, YouSendlt, SparkleShare, Ubuntu One) providing cloud storage, file synchronization, client software, and the like. In addition to sharing resources, the present invention may also provide a ‘share’ option within other third-party day-to-day workflow solutions, such as desktop tools (e.g. Microsoft Office, iWork, Google Docs, OpenOffice, and the like) and enterprise tools (enterprise DBs, CRM tools, analytical tools), and the like.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LINH BLACK whose telephone number is (571)272-4106. The examiner can normally be reached 9AM-5PM EST M-F.
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, Tony Mahmoudi can be reached on 571-272-4078. 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.
/LINH BLACK/Examiner, Art Unit 2163 9/28/2025
/TONY MAHMOUDI/Supervisory Patent Examiner, Art Unit 2163