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
35 USC § 112
Applicant’s arguments, see section 35 USC § 112 on page 5, filed 6/11/2026, with respect to claims 1-9 have been fully considered and are persuasive. The rejection of claims 1-9 has been withdrawn.
However, Applicant's assertion that withdrawal of the § 112(b) rejection places claims 1-9 "in condition for allowance" is not persuasive. Claims 1-9 remain rejected under 35 U.S.C. § 101 and 35 U.S.C. § 103 for the reasons of record and as further explained below. Compliance with § 112(b) does not establish patentability over the remaining grounds of rejection.
35 U.S.C. § 101
Applicant's arguments filed 6/11/2026 on pages 7-13 have been fully considered but they are not persuasive. The rejection of claims 1-9 under 35 U.S.C. § 101 is maintained.
Step 2A, Prong One
Applicant argues (pages 7-10) that amended independent claim 1 is not directed to an abstract idea because the claim recites "a specific technical architecture for hierarchical knowledge management" and because the "ordered combination" of receiving data packets, identifying members, generating repository members, and storing data "is not practically performable in the human mind."
The Examiner respectfully disagrees. This argument conflates the Prong One inquiry with the Prong Two inquiry. Under the 2019 PEG, Prong One asks only whether the claim recites a judicial exception. As set forth on page 3 of the Office Action, the limitation "identify a first, a second, and a third set of members from among the set of members based on a hierarchical level of the set of members, wherein each of the first set of members is associated with at least one of the second set of members, and wherein each of the second set of members is associated with at least one of the third set of members" describes organizing items in hierarchical levels, which is an evaluation and judgment activity that can be performed as a mental process in the human mind. Classifying a collection of entities into first, second, and third hierarchical tiers based on their level in a hierarchy is precisely the kind of observation, evaluation, and judgment that falls within the mental-processes grouping. See MPEP 2106.04(a)(2)(III).
Applicant's own specification confirms that the recited identification mirrors an ordinary human organizational judgment: in the educational-institution example, "the school may be the first set of members to be stored in a root repository, where the class standard maybe a second set of members to be stored in a namespace repository, and where the subject maybe a third set of members to be stored in a work repository" (specification, paragraph [0047]; see also paragraph [0051] and FIG. 6). A person for example, a school administrator may routinely performs this identification mentally by recognizing that the school sits above its departments, that classes sit above their subjects, and so on. That the claim recites performance by a processor does not remove the limitation from the mental-processes grouping; a claim limitation cast as performed on a computer may still recite a mental process where, as here, the underlying act of hierarchical classification is one that can practically be performed in the human mind. See MPEP 2106.04(a)(2)(III)(C).
Applicant's argument that the "ordered combination" of receiving data packets over a network, generating repository members, and storing data cannot be performed mentally is directed to the additional elements of the claim, not to the recited judicial exception. The receiving, generating, and storing limitations were identified in the Office Action (pages 3-4) as additional elements, and they are properly evaluated at Prong Two and Step 2B, not aggregated into the Prong One inquiry to argue that no abstract idea is recited. Likewise, Applicant's argument that the three-tier repository structure "is a specific computer storage architecture, not an abstract organizational concept" (Remarks, page 10) addresses additional elements (the storage device and plurality of repositories), which are evaluated below.
With respect to Applicant's reliance on McRO, Inc. v. Bandai Namco Games America Inc. and the USPTO's November 2, 2016 Memorandum: in McRO, the claimed rules effected an improvement in how the computer itself performed a technological task (automated lip-synchronization animation that computers previously could not perform in the claimed manner). Here, by contrast, the claim automates a scheme for organizing information that, per Applicant's own specification, replicates a human organizational structure and management hierarchy electronically (specification, paragraphs [0003]-[0005]). The specification identifies the problem being solved as one of organizational administration, collaboration tools operating "in silos," "blind spots and overlaps making the overall administration of the organization difficult and non-coherent" (specification, paragraph [0003]) which is a problem of organizing human activity and information, not a technical deficiency in the functioning of a computer. The claim does not recite a particular technological solution in the McRO sense; it recites the organizational scheme itself, applied on generic computer components.
Step 2A, Prong Two
Applicant argues (Remarks, pp. 10-12) that, even assuming a judicial exception is recited, the claim integrates the exception into a practical application because the three-tier repository structure with automatic member generation "improves the technological functioning of knowledge management systems" and addresses the problem identified at paragraph [0003] of the specification.
The Examiner respectfully disagrees. The additional elements of claim 1, a storage device including a plurality of repositories, a monitoring unit having a processor operatively coupled to a memory, receiving a first set of data packets from a computing device, generating members of the repositories, and storing the knowledge data and metadata, were each addressed in the Office Action (pages 3-4) and, considered both individually and as an ordered combination, do not integrate the judicial exception into a practical application. The storage device and monitoring unit are recited at a high level of generality as generic computer components performing generic computer functions; the receiving limitation describes data collection/receiving; and the generating and storing limitations amount to mere instructions to apply the abstract organizational scheme on a generic computer and store its results, which are well-understood, routine, conventional activities. See MPEP 2106.05(d)(II)(i) and MPEP 2106.05(d)(II)(iv) (storing and retrieving information in memory).
Labeling three generic storage constructs a "root repository," a "namespace repository," and a "work repository," and associating their members "in a hierarchical manner," does not improve the functioning of the computer or effect an improvement to another technology or technical field under MPEP 2106.05(a). The asserted improvement a unified, hierarchically organized storage structure that "eliminates the blind spots and overlaps of conventional loosely-coupled systems" (Remarks, page 11) is an improvement to the abstract scheme of organizing information itself, not to computer technology. An improved abstract idea is still an abstract idea, and the alleged advance cannot supply the practical application when the advance lies in the judicial exception rather than in the additional elements.
Moreover, Applicant's own specification describes the recited components and structures at a high level of generality as conventional. The storage device "may include, but is not limited to, hard disk drive (HDD), solid-state drive (SSD), and the like" (paragraph [0041]); the processors may be "one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that manipulate data based on operational instructions" (paragraph [0067]); and the hierarchical arrangement is implemented using conventional tree data structures in which "the root repository is the very first node or default parent node which may further include one or more child nodes" (paragraph [0035]), with "records arranged in a scheme resembling a tree" or, alternatively, "acyclic graphs" (paragraph [0073]). See MPEP 2106.05(d)(I). Organizing stored data in a tree with a root node, intermediate nodes, and leaf-level storage is a conventional computer storage practice, and the claim invokes it in its ordinary capacity as a tool to carry out the abstract organizational scheme. The cited passages of the specification (paragraphs [0047]-[0053], FIG. 6, paragraph [0110]) describe applying the organizational hierarchy of a school to that conventional structure; they do not describe any change to the manner in which the computer or its storage operates.
Accordingly, the additional elements do not reflect an improvement under MPEP 2106.05(a), do not apply the exception with a particular machine under MPEP 2106.05(b), and amount to mere instructions to apply the exception (MPEP 2106.05(f)) together with insignificant extra-solution data gathering and storage. The judicial exception is not integrated into a practical application.
Step 2B
Applicant argues (Remarks, pages 12-13), relying on BASCOM Global Internet Services v. AT&T Mobility LLC and the USPTO's November 2, 2016 Memorandum, that the claimed combination constitutes a "non-conventional and non-generic arrangement" of elements amounting to significantly more than the abstract idea.
The Examiner respectfully disagrees. In BASCOM, the inventive concept resided in the non-conventional placement of a known filtering tool at a specific location in a network architecture, a technical arrangement of additional elements that changed how the technology operated. Here, the ordered combination recited in claim 1 receiving data, classifying the received information into hierarchical tiers, creating corresponding entries in a hierarchical storage structure, and storing the data and its metadata is the conventional sequence in which computers receive, process, and store information in hierarchical data structures. Receiving data over a network, applying an organizational scheme, and storing data and metadata in memory are each well-understood, routine, conventional computer functions (MPEP 2106.05(d)(II)), and arranging them in their ordinary receive-process-store order does not render the arrangement non-conventional. The only assertedly unconventional aspect of the claim, the three-tier root/namespace/work organizational scheme applied to the members is the abstract idea itself, and the judicial exception cannot supply its own inventive concept. Considered individually and as an ordered combination, the additional elements do not amount to significantly more than the judicial exception.
Claims 2-9
Applicant argues that independent claim 9 is allowable for substantially the same reasons as claim 1, and that claims 2-8 are allowable by virtue of dependency. Because the arguments with respect to claim 1 are not persuasive for the reasons above, and because no separate substantive arguments have been presented for claims 2-9 under § 101, the rejection of claims 2-9 under 35 U.S.C. § 101 is likewise maintained for the reasons set forth in the Office Action (pages 4-9) and above.
35 U.S.C. § 103.
Applicant's arguments filed 6/11/2026 pages 14 -19 have been fully considered but they are not persuasive. The rejection of claims 1-9 under 35 U.S.C. § 103 is maintained.
A. "the plurality of repositories comprises a root repository, a namespace repository, and a work repository, wherein members of the root repository, namespace repository, and work repository are associated with each other in a hierarchical manner"
Applicant argues (Remarks, pages 14-15) that von Muhlen's namespaces "are all structurally identical, they are access-control wrappers over folders, differing only in their hierarchical position and permission sets," and therefore von Muhlen does not disclose "three structurally distinct repository types . . . each serving a different function in the knowledge management architecture," citing paragraph [0049] of the specification.
The Examiner respectfully disagrees, for the following reasons.
First, the argument is not commensurate with the scope of the claim. Claim 1 does not recite that the root repository, namespace repository, and work repository are "structurally distinct," "functionally distinct," or that each "serving a different function in the knowledge management architecture." Claim 1 recites three repositories, denominated root, namespace, and work, "wherein members of the root repository, namespace repository, and work repository are associated with each other in a hierarchical manner." The features upon which Applicant relies, the collating, nesting, and collaborative-storage functions described at paragraph [0049] of the specification, are not recited in the rejected claims. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993); MPEP 2145(VI).
Second, under the broadest reasonable interpretation consistent with the specification, a "repository" is "a shared data storage that stores objects and the metadata of its objects" (specification, paragraph [0033]). Von Muhlen's namespaces meet this interpretation: each namespace is a collection of content (content items and folders) under common access control, and the content management system stores and maintains namespace metadata for each namespace, including "hierarchical data that describes the hierarchy containing the contents that belong to the namespace" (von Muhlen, Col. 8, L. 35). Von Muhlen's FIG. 2 and accompanying description (Col. 12, L. 22 et seq.) disclose namespaces at three hierarchical positions whose members are associated with each other in a hierarchical manner: root namespace NS_A rooted to root folder A_ROOT of a user account; namespace NS_3 mounted to the root namespace at path /F3; and namespace NS_5 mounted within NS_3 at path /F3/F5, with the mount table maintaining the relative hierarchical positions of each (von Muhlen, Col. 13, L. 14: "NS_1 at path /F1; NS_3 at path /F3; and NS_5 at path /F3/F5"). Content items, the counterpart of the claimed knowledge data, belong to and are stored in the namespaces, and the hierarchical associations among namespaces and their contents are maintained via parent namespace identifiers (von Muhlen, Col. 16, L. 25: "Parent Namespace ID An identifier of a parent namespace") and inherited memberships (Col. 16, L. 2). This maps to the claimed root, namespace, and work repository levels with members hierarchically associated.
Third, even if the claim were read to require distinctions among the three repository types, von Muhlen does not disclose namespaces that are undifferentiated. Von Muhlen expressly distinguishes root namespaces (rooted to a root folder of an individual or entity account and linked to that account, paralleling Applicant's paragraph [0035], "the root repository is linked to a user account"), team/shared namespaces, and nested namespaces, and treats them differently for example, root namespaces are subject to different mounting constraints and are excluded from mount-lock requirements applicable to other namespaces (see von Muhlen, discussion of mount constraints and mount locks following Col. 20, L. 54). Von Muhlen further discloses, in the description of FIG. 2, that the different namespace types may be implemented "using a distinct data structure, distinct object type, or other distinct implementation mechanism, Col. 13, L. 28" directly contradicting Applicant's characterization that all of von Muhlen's namespaces are necessarily structurally identical.
For at least these reasons, von Muhlen teaches the disputed limitation as claimed, and Applicant's argument is not persuasive.
B. "receive a first set of data packets from a computing device associated with a user, the first set of data packets corresponding to knowledge data and metadata comprises information of a set of members associated with the knowledge data"
Applicant argues (Remarks, pages 15-17) that Nivala's system "generates metadata after receiving the data item" and therefore "does not receive data packets where the metadata already 'comprises information of a set of members associated with the knowledge data,'" asserting that in Nivala the metadata "is not part of the incoming data packets received from the user's computing device."
The Examiner respectfully disagrees. Applicant's characterization addresses Nivala's automatic-extraction embodiments but does not account for the entirety of Nivala's disclosure. A reference is available as prior art for all that it teaches, and Nivala expressly teaches embodiments in which the metadata including metadata identifying the objects to which the content belongs is supplied by the user and received from the user's client device as part of the storage operation:
Nivala's claim 5 recites "wherein at least part of the centralized content management metadata is received through user input," and Nivala's claim 6 recites "prompting a user to enter centralized content management metadata for the data object by using a metadata card interface." Consistent with these claims, Nivala's written description discloses, in the section addressing storing new content, that when a user saves new content, [Col 26 L 32] "some of the metadata may also be input by the user," and that the system [Col 27 L 5]"may prompt the user to enter or confirm metadata for the new content as part of the saving operation," for example by displaying a metadata card interface, with the entered metadata stored as CCM metadata upon the user confirming the save operation. The user's entries on the metadata card made at the client device and transmitted with the save/store request arrive at the centralized content management system as data received from the computing device associated with the user, together with the content itself. Under the broadest reasonable interpretation, this constitutes receiving a first set of data packets corresponding to knowledge data and metadata from a computing device associated with a user.
Further, the user-supplied metadata in Nivala comprises "information of a set of members associated with the knowledge data" as claimed. Applicant's specification explains that "[t]he set of members indicates the object or user to which the knowledge data belongs," giving as an example metadata including "school name, class information" for a scorecard file (specification, paragraphs [0047], [0050]). Nivala's metadata identifies precisely such objects: property values such as "Customer," "Project," "Contracting party," and organization identifiers (e.g., the "GC Plumbers Inc." contracting-party example, and the "Project = Sales Project" grouping shown in FIG. 4) identify the organizational objects to which the stored content belongs. The metadata entered by the user and received with the content therefore comprises information of the set of members associated with the knowledge data.
Applicant further asserts that "the CCM metadata is created by the system through automatic extraction, user input, or a combination thereof - it is not part of the incoming data packets received from the user's computing device" (Remarks, p. 12, citing Nivala Col. 16, L. 50-67 and Col. 20, L. 1-25). The Examiner respectfully disagrees with this characterization as applied to the user-input embodiments. Metadata that Nivala describes as originating from "user input" is, by definition, entered by the user at the user's client device for example, on the metadata card interface displayed as part of the saving operation and is transmitted from that client device to the centralized content management system upon the user confirming the save or store operation. Such metadata is therefore received by the system from the computing device associated with the user together with the content being stored; it is not generated by the system after receipt. Nivala's claim 5 confirms this by reciting that the metadata "is received through user input." Applicant's contrary characterization is accurate only as to Nivala's automatic-extraction embodiments and the promotion of pre-existing unmanaged content (the subject of the passage at Col. 16, L. 82-Col. 17, L. 5), but the rejection, as maintained, does not rest on those embodiments alone. Further, under the broadest reasonable interpretation, "a first set of data packets . . . corresponding to knowledge data and metadata" does not require that the knowledge data and metadata arrive in a single packet or a single transmission; a set of packets conveying the store request, the content item, and the user-entered metadata of the saving operation meets the limitation as claimed.
Accordingly, Nivala teaches the disputed limitation, and Applicant's argument is not persuasive.
C. "generate members of the root repository based on the first set of members, members of the namespace repository based on the second set of members, and members of the work repository based on the third set of members; and store the knowledge data in the corresponding member of the work repository and store metadata associated with each repository in the corresponding repositories"
Applicant argues (Remarks, pp. 17-19) that von Muhlen "establishes namespaces for pre-existing folder structures tied to user accounts" rather than generating members "based on identified sets of members extracted from received knowledge data and metadata," and that Nivala's metadata synchronization "operates across generic external data repositories, not across a hierarchical three-tier repository architecture."
The Examiner respectfully disagrees.
First, these arguments attack the references individually, whereas the rejection is based on the combination of von Muhlen and Nivala. One cannot show nonobviousness by attacking references individually where the rejection is based on a combination of references. In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986); MPEP 2145(IV). In the rejection as articulated, Nivala is relied upon for receiving the knowledge data together with metadata comprising member information (as discussed in section B above), and von Muhlen is relied upon for establishing i.e., generating members at each of the three hierarchical repository levels, and for the three-level hierarchical architecture itself (as discussed in section A above). Applicant's argument that von Muhlen alone does not generate members from received metadata, and that Nivala alone lacks the three-tier structure, does not address the combined teachings.
Second, Applicant's premise that von Muhlen's namespace establishment merely wraps static pre-existing structures is not consistent with von Muhlen's disclosure. Von Muhlen's FIG. 3 process establishes namespaces in response to received requests: the control server "receives a request to share a second folder that is a child of the first folder in a particular hierarchy" (von Muhlen, Col. 13, L. 66) and, based on receiving that request, establishes a second (nested) namespace rooted to the second folder and maintains permissions for it (FIG. 3, blocks 310-314). Von Muhlen likewise establishes a plurality of root namespaces, each associated with a root folder of an account corresponding to one or more users, and first namespaces rooted to team folders associated with sets of individual accounts (Col. 13, L. 47). The generation of hierarchical repository members responsive to data received from users' computing devices is therefore taught by von Muhlen; in the combination, Nivala's receipt of knowledge data with user-supplied member metadata supplies the received member information upon which the generation is based.
Third, with respect to the storing limitation, the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference, but what the combined teachings of the references would have suggested to a person of ordinary skill in the art. Nivala teaches storing the received data item to a repository and storing/pushing/synchronizing the associated CCM metadata to the corresponding repository (Nivala, Col. 16, L. 50: metadata "may be pushed to the original data repository or another data repository for storing there," including synchronizing metadata with the repository in which the content resides). In the combination, this teaching is applied to von Muhlen's hierarchical namespace levels, in which content items belong to and are stored in the namespace rooted at the folder from which they descend (von Muhlen, Col. 8, L. 35), and in which namespace metadata including hierarchical data is maintained for each namespace in the namespace metadata database (von Muhlen, Col. 8, L. 35; namespace metadata database 128). The combination therefore teaches storing the knowledge data in the corresponding member at the lowest (work) level of the hierarchy and storing metadata associated with each repository level in the corresponding repositories, as recited.
D. Motivation to combine
Applicant argues (Remarks, pages 18-19) that there is no motivation to combine von Muhlen and Nivala because the references "solve fundamentally different technical problems through incompatible architectural approaches."
The Examiner respectfully disagrees.
First, the reason to combine references is not limited to the problem the applicant was trying to solve, nor must both references address the identical problem. Under KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 420 (2007), "any need or problem known in the field of endeavor at the time of invention and addressed by the patent can provide a reason for combining the elements in the manner claimed." The Office Action (page 14) articulated a specific rationale drawn from Nivala itself: modifying von Muhlen's content management system to include Nivala's capability of receiving content requests and distributing or synchronizing metadata across repositories, in order "to provide an intelligent metadata layer that augments existing storage systems with advanced management functionalities they normally lack" (Nivala, Col. 9, L. 49). Applicant has not addressed this articulated rationale on its own terms; the assertion that the references address different problems does not rebut it.
Second, the references are in the same field of endeavor computer-implemented content management systems that organize content items and associated metadata in hierarchically arranged storage structures with access control and each is reasonably pertinent to the problem of organizing and managing stored content and its metadata. Both are analogous art. MPEP 2141.01(a).
Third, the assertion that the architectures are "incompatible" is contradicted by Nivala's own disclosure. Nivala expressly identifies "an enterprise file synchronization and sharing (EFSS) system," a "network file system," and cloud-based file sharing services that is, systems of precisely the type disclosed by von Muhlen (a cloud content management system with synchronized client access) among the external data repositories to which its centralized content management system connects and over which its intelligent metadata layer operates. Nivala thus affirmatively contemplates operating on top of, and augmenting, systems like von Muhlen's. Far from teaching away or presenting incompatible approaches, the references are complementary: von Muhlen supplies the hierarchical, multi-level namespace storage architecture, and Nivala supplies the receipt of content with user-supplied metadata and the distribution of metadata to corresponding repositories. Moreover, the test for obviousness does not require that the specific structures of the references be physically combinable; it is what the combined teachings would have suggested to one of ordinary skill.
Accordingly, the articulated motivation to combine stands, and Applicant's argument is not persuasive.
E. Claims 2-9
With respect to independent claim 9, Applicant relies on the same arguments presented for claim 1 (Remarks, page 19). Those arguments are not persuasive for the reasons set forth in sections A-D above, and the rejection of claim 9 is maintained.
With respect to dependent claims 2-8, Applicant argues only that the claims are allowable by virtue of their dependency on claim 1 and generally references "their additional claimed features" without identifying any specific feature or presenting any separate substantive argument (Remarks, page 19). A general allegation that the claims define a patentable invention, without specifically pointing out how the language of the claims patentably distinguishes them from the references is not persuasive. Because claim 1 remains unpatentable over von Muhlen in view of Nivala, dependent claims 2-8 fall therewith, and the rejections of claims 2-8 are maintained for the reasons of record (Office Action, pages 14-17).
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 1-9 rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
MPEP 2106 (Ill) sets out steps for evaluating whether a claim is drawn to patent-eligible subject matter. The analysis of claims 1-9, in accordance with these steps, follows.
Step 1 Analysis:
Claim 9 is directed to method (processes). Claim 1-8 are directed to a device (machine). Therefore, claims 1-9 fall into one of four statutory categories (i.e., process, machine, article of manufacture).
As to claim 1,
Step 2A Prong 1: this claim recites the following abstract ideas:
identify a first, a second, and a third set of members from among the set of members based on a hierarchical level of the set of members, wherein each of the first set of members is associated with at least one of the second set of members, and wherein each of the second set of members is associated with at least one of the third set of members; (this limitation describes organizing items in hierarchal levels which is a mental process implemented in the human mind.)
Step 2A Prong 2 and 2B: the claim recited the following additional elements:
a storage device including a plurality of repositories operatively coupled to one or more computing devices, the plurality of repositories can be configured to store knowledge data and metadata associated with the knowledge data in a hierarchical manner, the plurality of repositories comprises a root repository, a namespace repository, and a work repository, wherein members of the root repository, namespace repository, and work repository are associated with each other in a hierarchical manner; and (This limitation is directed to mere instruction to apply the abstract idea on a generic computer to process, which is a well-understood, routine, conventional activity, see MPEP 2106.05(d)(II)(i))
a monitoring unit having a processor operatively coupled to a memory, the memory storing instructions executable by the processor to: (This limitation is directed to mere instruction to apply the abstract idea on a generic computer to process, which is a well-understood, routine, conventional activity, see MPEP 2106.05(d)(II)(i))
receive a first set of data packets from a computing device associated with a user, the first set of data packets corresponding to knowledge data and metadata comprises information of a set of members associated with the knowledge data; (this limitation describes data collection/receiving, which is a well-understood, routine, conventional activity, see MPEP 2106.05(d)(II)(i))
generate members of the root repository based on the first set of members, members of the namespace repository based on the second set of members, and members of the work repository based on the third set of members; and (This limitation is directed to mere instruction to apply the abstract idea on a generic computer to process, which is a well-understood, routine, conventional activity, see MPEP 2106.05(d)(II)(i))
store the knowledge data in the corresponding member of the work repository and store metadata associated with each repository in the corresponding repositories. (This limitation is directed to mere instruction to apply the abstract idea on a generic computer to process, which is a well-understood, routine, conventional activity, see MPEP 2106.05(d)(II)(i))
The additional element does not integrate the judicial exception into practical application and does not amount to significantly more than the Judicial exception.
As to claim 9,
Step 2A Prong 1: this claim recites the following abstract ideas:
Identifying, … , a first, a second, and a third set of members from among the set of members based on a hierarchical level of the set of members, wherein each of the first set of members is associated with at least one of the second set of members, and wherein each of the second set of members is associated with at least one of the third set of members; (this limitation describes organizing items in hierarchal levels which is a mental process implemented in the human mind.)
Step 2A Prong 2 and 2B: the claim recited the following additional elements:
by the one or more processors, (This limitation is directed to mere instruction to apply the abstract idea on a generic computer to process, which is a well-understood, routine, conventional activity, see MPEP 2106.05(d)(II)(i))
receiving, by one or more processors, a first set of data packets from a computing device associated with a user, the first set of data packets corresponding to knowledge data and metadata, wherein metadata comprises information of a set of members associated with the knowledge data; (This limitation is directed to mere instruction to apply the abstract idea on a generic computer to process, which is a well-understood, routine, conventional activity, see MPEP 2106.05(d)(II)(i))
generating, by the one or more processors, members of the root repository based on the first set of members, members of the namespace repository based on the second set of members, and members of the work repository based on the third set of members; and (This limitation is directed to mere instruction to apply the abstract idea on a generic computer to process, which is a well-understood, routine, conventional activity, see MPEP 2106.05(d)(II)(i))
storing, by the one or more processors, the knowledge data in the corresponding work repository and storing metadata associated with each repository in the corresponding repositories. (This limitation is directed to mere instruction to apply the abstract idea on a generic computer to process, which is a well-understood, routine, conventional activity, see MPEP 2106.05(d)(II)(i))
The additional element does not integrate the judicial exception into practical application and does not amount to significantly more than the Judicial exception.
As to claim 2,
Step 2A Prong 1: this claim recites the following abstract ideas:
wherein the second set of members comprises a plurality of subsets of members, wherein each subset of members is associated with a mount level indicating the hierarchical level within the namespace repository, (this limitation describes hierarchal categorization of information which is a mental process implemented in the human mind)
Step 2A Prong 2 and 2B: the claim recited the following additional elements:
wherein the subset of members is stored along with the corresponding mount level, wherein (This limitation is directed to mere instruction to apply the abstract idea on a generic computer to process, which is a well-understood, routine, conventional activity, see MPEP 2106.05(d)(II)(i))
the namespace members are associated with a silo function that creates further namespace members on the basis of its active or inactive state. (This limitation is directed to mere instruction to apply the abstract idea on a generic computer to process, which is a well-understood, routine, conventional activity, see MPEP 2106.05(d)(II)(i))
The additional element does not integrate the judicial exception into practical application and does not amount to significantly more than the Judicial exception.
As to claim 3,
Step 2A Prong 1: this claim recites the following abstract ideas:
generate a root ID indicating a unique identification key corresponding to each of the members of the root repository; (the limitation describes assigning identifiers to categorized information, which is a mental process implemented in the human mind)
generate a namespace ID indicating a unique identification key corresponding to each of the members of the namespace repository; (the limitation describes assigning identifiers to categorized information, which is a mental process implemented in the human mind)
generate a work ID indicating a unique identification key corresponding to each of the members of the work repository; and (the limitation describes assigning identifiers to categorized information, which is a mental process implemented in the human mind)
Step 2A Prong 2 and 2B: the claim recited the following additional elements:
store the root ID along with the first set of members, the namespace ID along with the second set of members and work ID along with the third set of members. (This limitation is directed to mere instruction to apply the abstract idea on a generic computer to process, which is a well-understood, routine, conventional activity, see MPEP 2106.05(d)(II)(i))
The additional element does not integrate the judicial exception into practical application and does not amount to significantly more than the Judicial exception.
As to claim 4,
Step 2A Prong 1: This claim does not recite an additional abstract idea, but the claim depends on claim 1 which recites an abstract idea.
Step 2A Prong 2 and 2B: the claim recited the following additional elements:
wherein the processor is configured to: generate a knowledge index indicating the location of memory blocks where the knowledge data is stored and type of the knowledge data; and
store the knowledge index along with the third set of members. (This limitation is directed to mere instruction to apply the abstract idea on a generic computer to process, which is a well-understood, routine, conventional activity, see MPEP 2106.05(d)(II)(i))
The additional element does not integrate the judicial exception into practical application and does not amount to significantly more than the Judicial exception.
As to claim 5,
Step 2A Prong 1: This claim does not recite an additional abstract idea, but the claim depends on claim 1 which recites an abstract idea.
Step 2A Prong 2 and 2B: the claim recited the following additional elements:
wherein the processor is configured to provide access to a user based on the association of the user with the corresponding repository to be accessed. (This limitation is directed to mere instruction to apply the abstract idea on a generic computer to process, which is a well-understood, routine, conventional activity, see MPEP 2106.05(d)(II)(i))
The additional element does not integrate the judicial exception into practical application and does not amount to significantly more than the Judicial exception.
As to claim 6,
Step 2A Prong 1: This claim does not recite an additional abstract idea, but the claim depends on claim 5, and claim 5 depends on claim 1 which recites an abstract idea.
Step 2A Prong 2 and 2B: the claim recited the following additional elements:
wherein the processor is configured to obtain login credential details from the user and provide access to the user in case the obtained credential matches with the pre-stored credentials. (This limitation is directed to mere instruction to apply the abstract idea on a generic computer to process, which is a well-understood, routine, conventional activity, see MPEP 2106.05(d)(II)(i))
The additional element does not integrate the judicial exception into practical application and does not amount to significantly more than the Judicial exception.
As to claim 7,
Step 2A Prong 1: This claim does not recite an additional abstract idea, but the claim depends on claim 1 which recites an abstract idea.
Step 2A Prong 2 and 2B: the claim recited the following additional elements:
wherein the processor is configured to maintain an account database to store identification key of the plurality of repositories. (This limitation is directed to mere instruction to apply the abstract idea on a generic computer to store data in a database, which is a well-understood, routine, conventional activity, see MPEP 2106.05(d)(II)(i))
The additional element does not integrate the judicial exception into practical application and does not amount to significantly more than the Judicial exception.
As to claim 8,
Step 2A Prong 1: This claim does not recite an additional abstract idea, but the claim depends on claim 1 which recites an abstract idea.
Step 2A Prong 2 and 2B: the claim recited the following additional elements:
wherein the computing device comprises a display unit configured to provide a graphical user interface between the user and the system. (This limitation is directed to mere instruction to apply the abstract idea on a generic computer with a user interface, which is a well-understood, routine, conventional activity, see MPEP 2106.05(d)(II)(i))
The additional element does not integrate the judicial exception into practical application and does not amount to significantly more than the Judicial exception.
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.
Claim(s) 1-9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Von Muhlen et al. (US 9922201 B2) in view of Nivala et al. (US 10452623 B2).
As to claim 1, von Muhlen teaches a knowledge management system comprising
a storage device including a plurality of repositories operatively coupled to one or more computing devices, the plurality of repositories can be configured to store knowledge data (see von Muhlen [Col 5 L 10] “A content item managed by content management system 108 may be a logical collection of digital information including, but not limited to, a digital document, file, or other logical collection of digital information. Often, a content item corresponds to a known media type such as, for example, an image … music … a movie … a word processing document … other document (e.g., PDF, etc.), a spreadsheet document … a presentation document …, a web page … or a text file … However, a content item managed by content management system 108 is not limited to being a particular media type, and the content item may encompass any logical collection of digital information including binary data, text data, or other digital information”)
and metadata associated with the knowledge data in a hierarchical manner, ( see von Muhlen [Col 8 L 35] “and stored at the client device 102, such as namespace metadata 116 and/or hierarchical data that describes the hierarchy containing the contents that belong to the namespace. In some embodiments, the hierarchical data that describes the hierarchy is treated as namespace metadata 116 and is included in the namespace metadata 116.”)
the plurality of repositories comprises a root repository, a namespace repository, and a work repository, wherein members of the root repository, namespace repository, and work repository are associated with each other in a hierarchical manner; and
(see von Muhlen [Col 12 L 22] “FIG. 2 shows a hierarchy 200 of content available to user A and a hierarchy 200 … The content management system 108 also manages folder F3. Namespace NS_3 is rooted to shared folder F3. The content management system 108 maintains permissions for namespace NS_3 that grant access to namespace NS_3 to a second set of users. The permissions for namespace NS_3 grant access to user A. User A has mounted namespace NS_3 to the root namespace NS_A. … The content management system also manages folder F5. Namespace NS_5 is rooted to shared folder F5. The content management system maintains permissions for namespace NS_5 that grants access to namespace NS_5 to a third set of users.”
a monitoring unit having a processor operatively coupled to a memory, the memory storing instructions executable by the processor to: (see von Muhlen [Col 23 L 37] “Main memory 806, such as a random access memory (RAM) or other dynamic storage device, also may be coupled to bus 802 for storing information and software instructions to be executed by processor(s)”)
identify a first, a second, and a third set of members from among the set of members based on a hierarchical level of the set of members,
(see von Muhlen [Col 12 L 22] “FIG. 2 shows a hierarchy 200 of content available to user A and a hierarchy 200 …The content management system 108 manages a shared folder F1. Namespace NS_1 is rooted to shared folder F1. The content management system 108 maintains permissions for namespace NS_1 that grant access to namespace NS_1 to a first set of users … The content management system 108 also manages folder F3. Namespace NS_3 is rooted to shared folder F3. The content management system 108 maintains permissions for namespace NS_3 that grant access to namespace NS_3 to a second set of users. The permissions for namespace NS_3 grant access to user A. User A has mounted namespace NS_3 to the root namespace NS_A. … The content management system also manages folder F5. Namespace NS_5 is rooted to shared folder F5. The content management system maintains permissions for namespace NS_5 that grants access to namespace NS_5 to a third set of users.”)
wherein each of the first set of members is associated with at least one of the second set of members, and wherein each of the second set of members is associated with at least one of the third set of members; (see von Muhlen [Col 13 L 66] “At block 308, a computing device, such as the control server 120, maintains first permissions for the first namespace. The first permissions grant access to the first namespace to a first set of users of the plurality of users. … receives a request to share a second folder that is a child of the first folder in a particular hierarchy of the plurality of hierarchies.”, and see von Muhlen [Col 16 L 2 “users with access to the parent namespace will have access to the particular namespace based on the permissions maintained for the parent namespace. These members are implicit members of the particular namespace. … implicit permissions for a particular namespace may be derived from an ancestor namespace that is higher than a parent namespace when the permissions for the particular namespace and the relevant ancestor namespace/s specify that permission are inherited.”, and see Fig. 2)
Conclusion
THIS ACTION IS MADE FINAL. 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.
PNG
media_image1.png
429
404
media_image1.png
Greyscale
generate members of the root repository based on the first set of members, members of the namespace repository based on the second set of members, and members of the work repository based on the third set of members; and (see von Muhlen [Col 13 L 47] “At block 304, a computing device, such as a control server 120, establishes a plurality of root namespaces. Each root namespace is associated a root folder of an account corresponding to one or more users … At block 306, a computing device, such as the control server 120, establishes a first namespace rooted to a first folder selected from the plurality of folders. In some embodiments, the first namespace is a root namespace of an individual account and/or an entity account. In some embodiments, the first namespace is a namespace rooted to a team folder which is associated with a set of individual accounts. In some embodiments, the first namespace is a shared namespace other than a root namespace of an individual account or an entity account.”
von Muhlen does not explicitly teaches "receive a first set of data packets from a computing device associated with a user, the first set of data packets corresponding to knowledge data and metadata comprises information of a set of members associated with the knowledge data;", and "store the knowledge data in the corresponding member of the work repository and store metadata associated with each repository in the corresponding repositories"
However, Nivala teaches,
receive a first set of data packets from a computing device associated with a user, the first set of data packets corresponding to knowledge data and metadata comprises information of a set of members associated with the knowledge data; (see Nivala [Col 5 L17] “wherein said centralized content management system provides an access for one or more client devices to data items in said one or more connected data repositories; to receive a request from a user to store a new data item to a centralized content management system; to store said new data item to at least one of the one or more data repositories; to create centralized content management metadata for said new data item; and to associate the created centralized content management metadata with said data item.”)
store the knowledge data in the corresponding member of the work repository and store metadata associated with each repository in the corresponding repositories. (see Nivala [Col 16 L 50] “The CCM metadata managed and/or stored by the centralized content management system may be stored exclusively in the centralized content management system, and/or it may be pushed to the original data repository or another data repository for storing there. For example, if the original data repository is an enterprise content management system with ECM metadata capabilities, it may be beneficial to have the centralized content management system synchronize the CCM metadata or just part of the CCM metadata with that original data repository, in order to enable the ability to leverage that metadata in the other system even if the user does not interact with the centralized content management system's user interfaces. CCM metadata may also be pushed to the original data repository or another data repository in cases where that data repository does not support metadata capabilities.”
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the invention of Von Muhlen to include the capability of centralized system to receive content requests and subsequently distribute or synchronize metadata across multiple repository to provide an intelligent metadata layer that augment existing storage system with advanced management functionalities they normally lack. Nivala [Col 9 L 49]
As to claim 2, Von Muhlen as modified by Nivala teaches the system as claimed in claim 1,
wherein the second set of members comprises a plurality of subsets of members, wherein each subset of members is associated with a mount level indicating the hierarchical level within the namespace repository, wherein the subset of members is stored along with the corresponding mount level, wherein the namespace members are associated with a silo function that creates further namespace members on the basis of its active or inactive state. (see von Muhlen [Col 12 L 62] “The content management system also manages folder F5. Namespace NS_5 is rooted to shared folder F5. The content management system maintains permissions for namespace NS_5 that grants access to namespace NS_5 to a third set of users. The permissions for namespace NS_5 grant access to namespace NS_5 both user A and user B, since namespace NS_5 is available to both users. User A has mounted namespace NS_5 to folder F3, while User A has mounted namespace NS_5 to its root folder B_ROOT. … The mount location to which a namespace is mounted can be described by a path relative to another namespace. In some embodiments, the mount location of a namespace is described by a path relative to a root namespace associated with an account. In some embodiments, a mount table is kept for multiple root namespaces. The mount table includes an identifier of the mounted namespace and a path relative to the root namespace…”, and see von Muhlen [Col 20 L54] “the term mount lock refers to a synchronization mechanism associated with individual namespaces to control access to the corresponding namespace with respect to mounting location changes. For one or more constraints, satisfying the constraint comprises obtaining mount locks for affected namespaces”)
As to claim 3, Von Muhlen as modified by Nivala teaches the system as claimed in claim 1,
generate a root ID indicating a unique identification key corresponding to each of the members of the root repository; generate a namespace ID indicating a unique identification key corresponding to each of the members of the namespace repository; generate a work ID indicating a unique identification key corresponding to each of the members of the work repository; and store the root ID along with the first set of members, the namespace ID along with the second set of members and work ID along with the third set of members. (see von Muhlen [Col 7 L 3] “The account database 126 stores information about accounts that are created and/or managed by the content management system 108. In some embodiments, the content management system 108 supports individual accounts that each correspond to an individual user. Alternatively and/or in addition, the content management system 108 may support entity accounts. An entity account corresponds to an entity that is associated with a set of users. The set of users may be limited to users with individual accounts, or may include one or more users that do not have an account with the content management system 108. Each account may have a record in the account database … [namespace ID.sub.1, namespace ID.sub.2, . . . namespace ID.sub.n]}—For each client device 102 (Device ID) linked to the account in [Device ID.sub.1, Device ID.sub.2, . . . Device ID.sub.N] …”, and see von Muhlen [Col 16 L25] "Parent Namespace ID—An identifier of a parent namespace to which the particular namespace")
As to claim 4, Von Muhlen as modified by Nivala teaches the system as claimed in claim 1,
generate a knowledge index indicating the location of memory blocks where the knowledge data is stored and type of the knowledge data; and store the knowledge index along with the third set of members. (see von Muhlen [Col 13 L 14] “the mount table for NS_A includes (relative to root namespace NS_A):
NS_1 at path /F1;
NS_3 at path /F3; and
NS_5 at path /F3/F5.”
As to claim 5, Von Muhlen as modified by Nivala teaches the system as claimed in claim 1,
wherein the processor is configured to provide access to a user based on the association of the user with the corresponding repository to be accessed. (see von Muhlen [COL 14 L 55] “Permissions are maintained that specify or otherwise indicate which user(s) and/or group(s) of users have access to content that belongs to a namespace. When the permissions for a particular namespace grant access to the particular namespace to a particular user, the content in the particular namespace is available to the user. The permissions may specify different levels of access, or access types”)
As to claim 6, Von Muhlen as modified by Nivala teaches the system as claimed in claim 5,wherein the processor is configured to obtain login credential details from the user and provide access to the user in case the obtained credential matches with the pre-stored credentials. (see von Muhlen [Col 7 L19] “Authentication Credentials—Information, such as but not limited to a username and password, which may be used to authenticate a user of the account.”)
As to claim 7. Von Muhlen as modified by Nivala teaches the system as claimed in claim 1,
wherein the processor is configured to maintain an account database to store identification key of the plurality of repositories. ( see von Muhlen [Col 7 L 15] “a record for an individual account in the account database 126 includes the following information, or a subset or a superset thereof: Account ID—A unique identifier of the account. Authentication Credentials—Information, such as but not limited to a username and password, which may be used to authenticate a user of the account. Linked Devices [Device ID.sub.1, Device ID.sub.2, . . . Device ID.sub.n] … Accessible namespaces {Device IDS, [namespace ID.sub.1, namespace ID.sub.2, . . . namespace ID.sub.n]}—For each client device 102 (Device ID) linked to the account”)
As to claim 8. Von Muhlen as modified by Nivala teaches the system as claimed in claim 1,
wherein the computing device comprises a display unit configured to provide a graphical user interface between the user and the system. (see von Muhlen [Col 3 L 64] “such as but not limited to a graphical user interface (GUI) 110, access to content 114 stored in association with one or more namespaces, and namespace metadata 116.”)
As to claim 9, this is directed to a method that corresponds to the system of claim 1, See the rejection for claim 1 above, which also applies to claim 9.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDULLAH K ABOUD whose telephone number is (571)272-0025. The examiner can normally be reached Mon-Fri 8am-5pm.
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, Li B Zhen, can be reached at (571) 272-3768. 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.
/ABDULLAH KHALED ABOUD/Examiner, Art Unit 2121
/Li B. Zhen/Supervisory Patent Examiner, Art Unit 2121
Prosecution Insights