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 .
Response to Arguments
Applicant's arguments filed 12/23/2025 have been fully considered but they are not persuasive.
Applicant states (pp. 12) that von Muhlen does not teach “wherein the user account root namespace and the organization root namespace are distinct hierarchical namespaces maintained by the content management system associated with the user account”. Examiner respectfully disagrees.
In the content management system of von Muhlen, a folder contains content items [0028], and a namespace is rooted to a particular folder [0050] describing a hierarchy of content items in the namespace [0051]. A user account corresponds a folder containing content items associated with the user. A user moves (i.e., transitions) a folder (i.e., user account folder) nested in a source namespace (i.e., user account root namespace) to become a folder (i.e., member folder) nested in a target namespace (i.e., organization root namespace) that is different (i.e., distinct) from the source namespace [0139].
Applicant further states (pp. 13) that Yap does not teach transitioning content between multiple independent root namespaces. Examiner respectfully disagrees.
Yap teaches a cloud-based migration system (i.e., content management system), where to-be-migrated content is first uploaded from a source system, and stored as a single entity (i.e., member folder) in an intermediate storage system (Yap: [0008]). An administrator defines a migration package specifying content to be migrated (i.e., transitioned) and the source (i.e., user account root namespace) and target (i.e., organization root namespace) systems of migration (i.e., multiple independent systems), together with migration metadata such as permission mappings of content items from source to target systems (Yap: [0022]).
In summary, the cited prior art of record combined teaches the argued limitations of independent claims 1, 9 and 15.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a), as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, at the time the application was filed, had possession of the claimed invention. Specifically, claims 1, 9 and 15 recite limitation “hierarchical namespaces”, which is not defined in the instant specification. Claims 2-8, 10-14 and 16-20 depend on claims 1, 9 and 15 respectively and inherit the same problem.
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.
Claims 1-3, 5-6, 8-11, 14-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over von Muhlen et al. US patent application 2016/0292443 [herein “von Muhlen”], in view of Taivalsaari. On the Notion of Inheritance. ACM Computing Surveys, 28:3, 1996, pp. 438-479 [herein “Taivalsaari”], and further in view of Yap et al. US patent application 2016/0321275 [herein “Yap”].
Claim 1 recites “A non-transitory computer readable medium comprising instructions stored thereon, when executed the instructions are effective to cause a content management system to: transition a user account root namespace of a user account at the content management system to a member folder of an organization root namespace at the content management system, wherein the user account root namespace and the organization root namespace are distinct hierarchical namespaces maintained by the content management system associated with the user account and”.
In the content management system of von Muhlen, a folder contains content items [0028], and a namespace is rooted to a particular folder [0050] describing a hierarchy of content items in the namespace [0051]. A user account corresponds a folder containing content items associated with the user. A user moves (i.e., transitions) a folder (i.e., user account folder) nested in a source namespace (i.e., user account root namespace) to become a folder (i.e., member folder) nested in a target namespace (i.e., organization root namespace) that is different (i.e., distinct) from the source namespace [0139]. The permissions for a namespace (i.e., permissive ACL) grant explicit access to a user via an ACL [0116], or implicit access by inheriting explicit permissions from a parent namespace [0117].
Claim 1 further recites “each of a plurality of user accounts has a respective member folder mounted in the organization root namespace viewable only by each respective user account, and wherein non-member folders mounted to the organization root namespace are shared with user accounts having access to the organization root namespace,”
von Muhlen differentiates between an individual account for (i.e., viewable) a user and an entity account for (i.e., shared) a set of users [0041]. An account is associated with one or more accessible namespaces [0045]. A namespace can be rooted to the root folder of an individual account (i.e., member folder) [0056], or the root folder of an entity account (i.e., non-member folder) [0058]. A namespace is a collection of content under common access permissions [0049], e.g., viewable by an individual account or shared by an entity account for a set of users. Mounting operations operate at namespaces and their associated root folders [0131].
Claim 1 further recites “wherein transitioning the user account root namespace includes a workflow that includes causing the content management system to: create the member folder for the user account within the user account root namespace, wherein the member folder has an access state of private;”
In von Muhlen, a root namespace is rooted to a root folder of an account [0055]. Individual accounts associated with the organization root namespace can be considered member accounts of the corresponding organization. A user creates a folder (i.e., member folder) in its own namespace with distinct permissions (i.e., private folder) by a create action [0135].
Claim 1 further recites “move all content items including a nested folder in the user account root namespace into the member folder, wherein the nested folder is shared with a set of user accounts that are members of the organization root namespace;”
In von Muhlen, a user moves a folder in a source namespace to become a folder in a target namespace by a move action [0139]. Notice that the move action applies to a shared folder, and by analogy, to a folder that is not shared [0114].
Claim 1 further recites “after moving all the content items into the member folder, unmount the member folder from the user account root namespace and mount the member folder in the organization root namespace;” and “unmount the nested folder from the member folder; subsequently, mount the nested folder to the organization root namespace;”
The move action of a (i.e., member/nested) folder in von Muhlen causes one or more mounting operations – to unmount the folder from the source namespace and to remount the folder in the target namespace [0139].
Claim 1 further recites “send to a client device associated with the user account a synchronization notice corresponding to the transition of the user account root namespace to the organization root namespace, wherein the synchronization notice initiates the member folder appearing in the user account accessible on the client device.”
von Muhlen stores namespace metadata (i.e., member folder in the organization root namespace) in the namespace database, and synchronizes it with namespace metadata on the associated client device (i.e., member folder in the user account root namespace) [0103]. When the namespace creation (i.e., mount) process terminates, any appropriate record or notification (i.e., synchronization notice) can be generated [0102] to trigger synchronization (i.e., initiating the member folder appearing in the user account accessible on the client device) [0040].
von Muhlen does not disclose limitations “wherein the user account root namespace uses a permissive access control list to grant access to specified user accounts and the organization root namespace uses a restrictive access control list to specify user accounts that are not restricted,” and “modify the restrictive access control list to include explicit permissions associated with the nested folder;”
According to the instant specification, permissive and restrictive ACLs differ in their inheritance behavior for team-shared folders. By default (i.e., permissive ACL), every member in an organization has read access to a team-shared folder (e.g., design folder) mounted within the organization directory (spec. [00133]). In other words, read access can be granted explicitly to the organization directory and inherited implicitly by every member in the organization. On the other hand, members in an organization do not have access by default (i.e., restrictive ACL) to a confidential folder (e.g., finance folder). They need to be explicitly granted such access (spec. [00134]).
Taivalsaari teaches inheritance in object-oriented programming where a descendant object (i.e., nested folder) receiving properties or characteristics (i.e., permissions) of its ancestor object by default (i.e., permissive ACL) (Taivalsaari: sec. 2.1, para. 1). Selective inheritance enables a descendant (i.e., confidential folder) to decide (i.e., select and modify) which particular properties are implicitly inherited from parents (i.e., restrictive ACL) and which ones are not (i.e., explicitly declared instead) (Taivalsaari: sec. 2.2.2, sec. 3.6, para. 2).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Taivalsaari to von Muhlen. One having ordinary skill in the art would have found motivation to adopt selected inheritance in limited namespaces such as confidential folders to provide finer control of access, while keeping the default inheritance behavior for less sensitive namespaces.
The instant specification does not define “workflow”. A workflow is the sequence of steps involved in moving from the beginning to the end of a working process https://www.merriam-webster.com/dictionary/workflow. The claimed workflow is a multi-step process: create, move, unmount, mount and notify.
von Muhlen does not disclose claim element “workflow”; however, Yap teaches a cloud-based migration system (i.e., content management system), where to-be-migrated content is first uploaded and stored as a single entity (i.e., member folder) in an intermediate storage system (Yap: [0008]). An administrator defines a migration package specifying content to be migrated (i.e., transitioned) and the source (i.e., user account root namespace) and target (i.e., organization root namespace) systems of migration, together with migration metadata such as permission mappings of content items from source to target systems (Yap: [0022]). Yap extracts a list (i.e., workflow) of work items (i.e., steps) from the migration package, and stores them in a work item queue (Yap: [0024]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Yap to von Muhlen. One having ordinary skill in the art would have found motivation to utilize the work item queue of Yap to track the workflow steps of von Muhlen to move a user account from a source namespace to a target namespace, to ensure all content items of the user account are moved to appropriate locations within the target namespace with intended access permissions, whether shared or private.
Claim 9 recites “A method comprising: transitioning a user account root namespace of a user account at the content management system to a member folder of an organization root namespace at the content management system, the user account root namespace and the organization root namespace are distinct hierarchical namespaces maintained by the content management system associated with the user account and”.
In the content management system of von Muhlen, a folder contains content items [0028], and a namespace is rooted to a particular folder [0050] describing a hierarchy of content items in the namespace [0051]. A user account corresponds a folder containing content items associated with the user. A user moves (i.e., transitions) a folder (i.e., user account folder) nested in a source namespace (i.e., user account root namespace) to become a folder (i.e., member folder) nested in a target namespace (i.e., organization root namespace) that is different (i.e., distinct) from the source namespace [0139]. The permissions for a namespace (i.e., permissive ACL) grant explicit access to a user via an ACL [0116], or implicit access by inheriting explicit permissions from a parent namespace [0117].
Claim 9 further recites “wherein each of a plurality of user accounts has a respective member folder mounted in the organization root namespace viewable only by each respective user account, and wherein non-member folders mounted to the organization root namespace are shared with user accounts having access to the organization root namespace and,”
von Muhlen differentiates between an individual account for (i.e., viewable) a user and an entity account for (i.e., shared) a set of users [0041]. An account is associated with one or more accessible namespaces [0045]. A namespace can be rooted to the root folder of an individual account (i.e., member folder) [0056], or the root folder of an entity account (i.e., non-member folder) [0058]. A namespace is a collection of content under common access permissions [0049], e.g., viewable by an individual account or shared by an entity account for a set of users. Mounting operations operate at namespaces and their associated root folders [0131].
Claim 9 further recites “wherein transitioning the user account root namespace includes a workflow that includes causing the content management system to: create the member folder for the user account within the user account root namespace, wherein the member folder has an access state of private;”
In von Muhlen, a root namespace is rooted to a root folder of an account [0055]. Individual accounts associated with the organization root namespace can be considered member accounts of the corresponding organization. A user creates a folder (i.e., member folder) in its own namespace with distinct permissions (i.e., private folder) by a create action [0135].
Claim 9 further recites “move all content items including a nested folder in the user account root namespace into the member folder;” and “mark the nested folder with restricted access permissions as confidential;”
In von Muhlen, a user moves a folder nested in a source namespace to become a folder nested in a target namespace by a move action [0139]. Notice that the move action applies to a shared folder (i.e., confidential), and by analogy, to a folder that is not shared [0114].
Claim 9 further recites “after moving all the content items into the member folder, unmount the member folder from the user account root namespace and mount the member folder in the organization root namespace;” and “unmount the nested folder from the member folder; subsequently, mount the nested folder to the organization root namespace;”
The move action of a (i.e., member/nested) folder in von Muhlen causes one or more mounting operations – to unmount the folder from the source namespace and to remount the folder in the target namespace [0139].
Claim 9 further recites “send to a client device associated with the user account a synchronization notice corresponding to the transition of the user account root namespace to the organization root namespace, wherein the synchronization notice initiates the member folder appearing in the user account accessible on the client device.”
von Muhlen stores namespace metadata (i.e., member folder in the organization root namespace) in the namespace database, and synchronizes it with namespace metadata on the associated client device (i.e., member folder in the user account root namespace) [0103]. When the namespace creation (i.e., mount) process terminates, any appropriate record or notification (i.e., synchronization notice) can be generated [0102] to trigger synchronization (i.e., initiating the member folder appearing in the user account accessible on the client device) [0040].
von Muhlen does not disclose limitation “modify a restrictive access control list to include explicit permissions associated with the nested folder;”
According to the instant specification, permissive and restrictive ACLs differ in their inheritance behavior for team-shared folders. By default (i.e., permissive ACL), every member in an organization has read access to a team-shared folder (e.g., design folder) mounted within the organization directory (spec. [00133]). In other words, read access can be granted explicitly to the organization directory and inherited implicitly by every member in the organization. On the other hand, members in an organization do not have access by default (i.e., restrictive ACL) to a confidential folder (e.g., finance folder). They need to be explicitly granted such access (spec. [00134]).
Taivalsaari teaches inheritance in object-oriented programming where a descendant object (i.e., nested folder) receiving properties or characteristics (i.e., permissions) of its ancestor object by default (i.e., permissive ACL) (Taivalsaari: sec. 2.1, para. 1). Selective inheritance enables a descendant (i.e., confidential folder) to decide (i.e., select and modify) which particular properties are implicitly inherited from parents (i.e., restrictive ACL) and which ones are not (i.e., explicitly declared instead) (Taivalsaari: sec. 2.2.2, sec. 3.6, para. 2).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Taivalsaari to von Muhlen. One having ordinary skill in the art would have found motivation to adopt selected inheritance in limited namespaces such as confidential folders to provide finer control of access, while keeping the default inheritance behavior for less sensitive namespaces.
The instant specification does not define “workflow”. A workflow is the sequence of steps involved in moving from the beginning to the end of a working process https://www.merriam-webster.com/dictionary/workflow. The claimed workflow is a multi-step process: create, move, unmount, mount and notify.
von Muhlen does not disclose claim element “workflow”; however, Yap teaches a cloud-based migration system (i.e., content management system), where to-be-migrated content is first uploaded and stored as a single entity (i.e., member folder) in an intermediate storage system (Yap: [0008]). An administrator defines a migration package specifying content to be migrated (i.e., transitioned) and the source (i.e., user account root namespace) and target (i.e., organization root namespace) systems of migration, together with migration metadata such as permission mappings of content items from source to target systems (Yap: [0022]). Yap extracts a list (i.e., workflow) of work items (i.e., steps) from the migration package, and stores them in a work item queue (Yap: [0024]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Yap to von Muhlen. One having ordinary skill in the art would have found motivation to utilize the work item queue of Yap to track the workflow steps of von Muhlen to move a user account from a source namespace to a target namespace, to ensure all content items of the user account are moved to appropriate locations within the target namespace with intended access permissions, whether shared or private.
Claim 15 recites “A content management system comprising: one or more processors; and at least one memory having instructions stored thereon, that when executed the instructions are effective to cause the one or more processors to: transition a user account root namespace of a user account at the content management system to a member folder of an organization root namespace at the content management system, the user account root namespace and the organization root namespace are distinct hierarchical namespaces maintained by the content management system associated with the user account and”.
In the content management system of von Muhlen, a folder contains content items [0028], and a namespace is rooted to a particular folder [0050] describing a hierarchy of content items in the namespace [0051]. A user account corresponds a folder containing content items associated with the user. A user moves (i.e., transitions) a folder (i.e., user account folder) nested in a source namespace (i.e., user account root namespace) to become a folder (i.e., member folder) nested in a target namespace (i.e., organization root namespace) that is different (i.e., distinct) from the source namespace [0139]. The permissions for a namespace (i.e., permissive ACL) grant explicit access to a user via an ACL [0116], or implicit access by inheriting explicit permissions from a parent namespace [0117].
Claim 15 further recites “wherein each of a plurality of user accounts has a respective member folder mounted in the organization root namespace viewable only by each respective user account, wherein non-member folders mounted to the organization root namespace are shared with user accounts having access to the organization root namespace, wherein the user account root namespace contains a shared folder shared with selected members of the organization root namespace,”
von Muhlen differentiates between an individual account for (i.e., viewable) a user and an entity account for (i.e., shared) a set of users [0041]. An account is associated with one or more accessible namespaces [0045]. A namespace can be rooted to the root folder of an individual account (i.e., member folder) [0056], or the root folder of an entity account (i.e., non-member folder) [0058]. A namespace is a collection of content under common access permissions [0049], e.g., viewable by an individual account or shared by an entity account for a set of users. Mounting operations operate at namespaces and their associated root folders [0131].
Claim 15 further recites “wherein transitioning the user account root namespace includes a workflow that includes causing the content management system to: create the member folder for the user account within the user account root namespace, wherein the member folder has an access state of private;”
In von Muhlen, a root namespace is rooted to a root folder of an account [0055]. Individual accounts associated with the organization root namespace can be considered member accounts of the corresponding organization. A user creates a folder (i.e., member folder) in its own namespace with distinct permissions (i.e., private folder) by a create action [0135].
Claim 15 further recites “move all content items in the user account root namespace into the member folder;” Notice that the shared folder is one of the content items nested in the member folder.
In von Muhlen, a user moves a folder nested in a source namespace to become a folder nested in a target namespace by a move action [0139]. Notice that the move action applies to a shared folder, and by analogy, to a folder that is not shared [0114].
Claim 15 further recites “after moving all the content items into the member folder, unmount the member folder from the user account root namespace and mount the member folder in the organization root namespace;” and “unmount the nested folder from the member folder; subsequently, mount the nested folder to the organization root namespace;” Examiner interprets “the nested folder” to mean “the shared folder”.
The move action of a (i.e., member/nested) folder in von Muhlen causes one or more mounting operations – to unmount the folder from the source namespace and to remount the folder in the target namespace [0139].
Claim 15 further recites “send to a client device associated with the user account a synchronization notice corresponding to the transition of the user account root namespace to the organization root namespace, wherein the synchronization notice initiates the member folder appearing in the user account accessible on the client device.”
von Muhlen stores namespace metadata (i.e., member folder in the organization root namespace) in the namespace database, and synchronizes it with namespace metadata on the associated client device (i.e., member folder in the user account root namespace) [0103]. When the namespace creation (i.e., mount) process terminates, any appropriate record or notification (i.e., synchronization notice) can be generated [0102] to trigger synchronization (i.e., initiating the member folder appearing in the user account accessible on the client device) [0040].
von Muhlen does not disclose limitations “wherein the user account root namespace uses a permissive access control list to grant access to specified user accounts and the organization root namespace uses a restrictive access control list to specify user accounts that are not restricted,” and “modify the restrictive access control list to include explicit permissions associated with the shared folder;”
According to the instant specification, permissive and restrictive ACLs differ in their inheritance behavior for team-shared folders. By default (i.e., permissive ACL), every member in an organization has read access to a team-shared folder (e.g., design folder) mounted within the organization directory (spec. [00133]). In other words, read access can be granted explicitly to the organization directory and inherited implicitly by every member in the organization. On the other hand, members in an organization do not have access by default (i.e., restrictive ACL) to a confidential folder (e.g., finance folder). They need to be explicitly granted such access (spec. [00134]).
Taivalsaari teaches inheritance in object-oriented programming where a descendant object (i.e., nested folder) receiving properties or characteristics (i.e., permissions) of its ancestor object by default (i.e., permissive ACL) (Taivalsaari: sec. 2.1, para. 1). Selective inheritance enables a descendant (i.e., confidential folder) to decide (i.e., select and modify) which particular properties are implicitly inherited from parents (i.e., restrictive ACL) and which ones are not (i.e., explicitly declared instead) (Taivalsaari: sec. 2.2.2, sec. 3.6, para. 2).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Taivalsaari to von Muhlen. One having ordinary skill in the art would have found motivation to adopt selected inheritance in limited namespaces such as confidential folders to provide finer control of access, while keeping the default inheritance behavior for less sensitive namespaces.
The instant specification does not define “workflow”. A workflow is the sequence of steps involved in moving from the beginning to the end of a working process https://www.merriam-webster.com/dictionary/workflow. The claimed workflow is a multi-step process: create, move, unmount, mount and notify.
von Muhlen does not disclose claim element “workflow”; however, Yap teaches a cloud-based migration system (i.e., content management system), where to-be-migrated content is first uploaded and stored as a single entity (i.e., member folder) in an intermediate storage system (Yap: [0008]). An administrator defines a migration package specifying content to be migrated (i.e., transitioned) and the source (i.e., user account root namespace) and target (i.e., organization root namespace) systems of migration, together with migration metadata such as permission mappings of content items from source to target systems (Yap: [0022]). Yap extracts a list (i.e., workflow) of work items (i.e., steps) from the migration package, and stores them in a work item queue (Yap: [0024]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Yap to von Muhlen. One having ordinary skill in the art would have found motivation to utilize the work item queue of Yap to track the workflow steps of von Muhlen to move a user account from a source namespace to a target namespace, to ensure all content items of the user account are moved to appropriate locations within the target namespace with intended access permissions, whether shared or private.
Claim 2 recites “The non-transitory computer readable medium of claim 1, wherein the transitioning the user account root namespace includes causing the content management system to: prior to the mount of the member folder, configuring the unmounted member folder as confidential.”
When von Muhlen moves a child folder (i.e., member folder) from the parent namespace into a different namespace, external members are retained (i.e., configured) for the child namespace, but not the implicit members who inherit permissions from the parent namespace. Thus a shared child folder (i.e., confidential folder) being moved remains a shared folder [0139].
Claims 10 and 16 are analogous to claim 2, and are similarly rejected.
Claim 3 recites “The non-transitory computer readable medium of claim 1, wherein the transitioning includes causing the content management system to: after the member folder has been mounted in the organization root namespace, move a subset of the content items from within the member folder to at least one new location in the organization root namespace.”
von Muhlen moves a child folder (i.e., subset of content items in the member folder) from the parent folder (i.e., member folder) to a different namespace (i.e., new location in the organization root namespace) than the parent namespace rooted to or containing the parent folder [0139].
Claim 11 is analogous to claim 3, and are similarly rejected.
Claim 5 recites “The non-transitory computer readable medium of claim 1, comprising instructions to cause the content management system to: transition the user account root namespace of the user account at the content management system to the member folder of the organization root namespace”.
In von Muhlen, a folder contains content items [0028] and a namespace is rooted to a particular folder [0050]. A user account corresponds a folder containing content items associated with the user. A user moves (i.e., transitions) a folder in a source namespace (i.e., user account root namespace) to become a folder (i.e., member folder) nested in a target namespace (i.e., organization root namespace) [0139]. The permissions for a namespace (i.e., permissive ACL) grant explicit access to a user via an ACL [0116], or implicit access by inheriting explicit permissions from a parent namespace [0117].
Claim 5 further recites “using the workflow that includes causing the content management system to unmount the nested folder from the member folder by: when the nested folder is a team folder and has been unmounted from the member folder, marking the nested folder as being confidential, when the nested folder is not the team folder and has been unmounted from the member folder, not marking the nested folder as being confidential,”
In von Muhlen, a root namespace is rooted to a root folder of an account [0055]. Individual accounts associated with the organization root namespace can be considered member accounts of the corresponding organization. A user creates a folder (i.e., nested folder) in its own namespace with (i.e., marked) distinct permissions (i.e., confidential folder) by a create action [0135].
von Muhlen and Yap teach claim 1, where to-be-migrated content is first uploaded and stored as a single entity (i.e., member folder) in an intermediate storage system (Yap: [0008]). An administrator defines a migration package specifying content to be migrated (i.e., transitioned) and the source (i.e., user account root namespace) and target (i.e., organization root namespace) systems of migration, together with migration metadata such as permission mappings of content items from source to target systems (Yap: [0022]). Yap extracts a list (i.e., workflow) of work items (i.e., steps) from the migration package, and stores them in a work item queue (Yap: [0024]).
Claim 5 further recites “wherein folders in the organization root namespace that are confidential are respectively associated with restrictive access control lists and restrict access to explicit permissions recorded in an associated restrictive access control list, and folders in the organization root namespace that are not confidential lack an association with any restrictive access control lists and have a default behavior of allowing at least read access to members of an organization corresponding to the organization root namespace.”
von Muhlen and Taivalsaari teach claim 1, where a descendant object (i.e., nested folder) receiving properties or characteristics (i.e., permissions) of its ancestor object by default (i.e., permissive ACL) (Taivalsaari: sec. 2.1, para. 1). Selective inheritance enables a descendant (i.e., confidential folder) to explicitly decide which particular properties of parents are inherited (i.e., restrictive ACL) and which ones are not (i.e., explicitly declared instead) (Taivalsaari: sec. 3.6, para. 2).
Claim 6 recites “The non-transitory computer readable medium of claim 1, wherein the transitioning the user account root namespace includes causing the content management system to: prior to creation of the member folder, create a convert-user task list and store the convert-user task list in association with the user account.”
von Muhlen and Yap teach claim 1, where Yap extracts a list of migration work items (i.e., convert-user task list) from the migration package, and stores them in a work item queue (Yap: [0024]).
Claim 8 recites “The non-transitory computer readable medium of claim 1, further comprising instructions to cause the content management system to: after all the content items have been moved into the member folder, synchronize the member folder with the client device.”
A user with access to a namespace may synchronize content stored in the namespace (i.e., member folder) on the client device with the corresponding content items managed by content management system [0039].
Claims 14 and 20 are analogous to claim 8, and are similarly rejected.
Claim 17 recites “The content management system of claim 15, wherein the shared folder is a team-shared folder and is visible to all members of the organization root namespace and access is limited to team members.”
von Muhlen differentiates between an individual account for a user and an entity account for a set of users ( [0041]. An account is associated with one or more accessible namespaces [0045]. A namespace can be rooted to the root folder of an individual account (i.e., member folder) [0056], or the root folder of an entity account (i.e., team-shared folder) [0058]. A namespace is a collection of content under common access permissions [0049], e.g., visible and accessible by an entity account for a set of users (i.e., team members) [0131].
Claims 4, 12 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over von Muhlen as applied to claims 1, 9 and 15 above respectively, in view of Taivalsaari and Yap, and further in view of Grue et al. US patent application 2015/0120763 [herein “Grue”].
Claim 4 recites “The non-transitory computer readable medium of claim 1, comprising instructions to cause the content management system to: transmit to the client device authorized to access the user account, an up-to-date view of a namespace within the organization root namespace, wherein the up-to-date view is filtered according to access privileges for the user account, and transmit, to the client device, instructions to populate a local file system of the client device according to the up-to-date view of the namespace within the organization root namespace.”
von Muhlen teaches claim 1, but does not disclose this claim; however, Grue describes a file chooser enabling a client device to access a set of content items in the content management system. The set of content items is selected based on a filter, which can be based on synchronization data, such as share status, one or more authorized users, etc. (Grue: [0038]). With the file chooser, users are allowed to download or synchronize (i.e., transmit/populate) content items in the filtered view (i.e., up-to-date view) (Grue: [0092]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Grue to von Muhlen. One having ordinary skill in the art would have found motivation to use Grue’s filter in von Muhlen to present the hierarchical view of a namespace to a client device [0054], such that only authorized users at the client device get to see content items in the filtered namespace.
Claim 12 recites “The method of claim 9, further comprising: transmitting to a client device authorized to access the user account, an up-to-date view of a namespace within the organization root namespace, wherein the up-to-date view is filtered according to access privileges for the user account; and transmitting, to the client device, instructions to populate a local file system of the client device according to the up-to-date view of the namespace within the organization 115P1179USC3 (085118-705753)root namespace.”
von Muhlen teaches claim 9, but does not disclose this claim; however, Grue describes a file chooser enabling a client device to access a set of content items in the content management system. The set of content items is selected based on a filter, which can be based on synchronization data, such as share status, one or more authorized users (i.e., access privileges), etc. (Grue: [0038]). Users are allowed to download (i.e., populate) or synchronize content items in the filtered view (i.e., up-to-date view) (Grue: [0092]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Grue to von Muhlen. One having ordinary skill in the art would have found motivation to use Grue’s filter in von Muhlen to present the hierarchical view of a namespace to a client device [0054], such that only authorized users get to download content items in the filtered namespace.
Claim 18 is analogous to claim 12, and is similarly rejected.
Claims 7, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over von Muhlen as applied to claims 6, 9 and 15 above respectively, in view of Taivalsaari and Yap, and further in view of Chen et al. US patent application 2017/0270136 [herein “Chen”].
Claim 7 recites “The non-transitory computer readable medium of claim 6, wherein the transitioning the user account root namespace includes causing the content management system to: after completion of a task in the convert-user task list, remove the task from the convert-user task list,”
von Muhlen teaches claim 6, but does not disclose this limitation; however, Yap selects (i.e., removes) a migration job from the work item queue to perform (Yap: [0031]), and repeats the same step until there are no more jobs left in the queue (Yap: [0034]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Yap to von Muhlen. One having ordinary skill in the art would have found motivation to adopt Yap’s work item queue in von Muhlen to track steps in the process to move a user account from a source namespace to a target namespace, to ensure all content items of the user are moved to proper locations within the target namespace with appropriate access permissions.
Claim 7 further recites “wherein a synchronization process for the user account is suspended while the convert-user task list contains tasks.”
von Muhlen and Yap teach claim 6, but do not disclose this limitation; however, Chen teaches that a user may expressly choose to put on hold (i.e., suspend) the synchronization of a file (Chen: [0083]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Chen to von Muhlen and Yap. One having ordinary skill in the art would have found motivation to put on hold the synchronization of all content items and folders in a namespace of von Muhlen while there are unfinished jobs in Yap’s work item queue to move content in the namespace, and to only resume synchronization when the queue is empty, in order to avoid any potential interference between synchronization and content move.
Claim 13 recites “The method of claim 9, wherein the transitioning the user account root namespace further comprises: prior to creation of the member folder, creating a convert-user task list and store the convert-user task list in association with the user account; and”.
von Muhlen teaches claim 9, but does not disclose this limitation; however, Yap extracts migration work items from the migration package, and stores them in a work item queue (i.e., convert-user task list) (Yap: [0024]).
Claim 13 further recites “after completion of a task in the convert-user task list, removing the task from the convert-user task list,”
von Muhlen does not disclose this limitation; however Yap selects (i.e., removes) a migration job from the work item queue to perform (Yap: [0031]), and repeats the same step until there are no more jobs left in the queue (Yap: [0034]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Yap to von Muhlen. One having ordinary skill in the art would have found motivation to adopt Yap’s work item queue in von Muhlen to track steps in the process to move a user account from a source namespace to a target namespace, to ensure all content items of the user are moved to proper locations within the target namespace with appropriate access permissions.
Claim 13 further recites “wherein a synchronization process for the user account is suspended while the convert-user task list contains tasks.”
von Muhlen and Yap do not disclose this limitation; however, Chen teaches that a user may expressly choose to put on hold (i.e., suspend) the synchronization of a file (Chen: [0083]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Chen to von Muhlen and Yap. One having ordinary skill in the art would have found motivation to put on hold the synchronization of all content items and folders in a namespace of von Muhlen while there are unfinished jobs in Yap’s work item queue to move content in the namespace, and to only resume synchronization when the queue is empty, in order to avoid any potential interference between synchronization and content move.
Claim 19 is analogous to claim 13, and is similarly rejected.
Conclusion
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 SHELLY X. QIAN whose telephone number is (408)918-7599. The examiner can normally be reached Monday - Friday 8-5 PT.
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, Boris Gorney can be reached at (571)270-5626. 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.
/SHELLY X QIAN/Examiner, Art Unit 2154
/BORIS GORNEY/Supervisory Patent Examiner, Art Unit 2154