Source: http://www.google.com/patents/US20030028500?dq=7,496,943
Timestamp: 2017-11-21 00:30:15
Document Index: 485867041

Matched Legal Cases: ['art 1', 'art 1', 'art 2', 'art 3', 'art 1', 'art 4']

Patent US20030028500 - Collection knowledge system - Google Patents
A Collection Knowledge System provides context-sensitive knowledge delivery services to application programs, thereby enabling application programs to effectively support variant computational processes. In operation, a Collection Knowledge System receives knowledge requests from application programs,...http://www.google.com/patents/US20030028500?utm_source=gb-gplus-sharePatent US20030028500 - Collection knowledge system
Publication number US20030028500 A1
Application number US 09/885,079
Also published as CA2352577A1, US6785664, US7020644, US20030009429, US20050273461
Publication number 09885079, 885079, US 2003/0028500 A1, US 2003/028500 A1, US 20030028500 A1, US 20030028500A1, US 2003028500 A1, US 2003028500A1, US-A1-20030028500, US-A1-2003028500, US2003/0028500A1, US2003/028500A1, US20030028500 A1, US20030028500A1, US2003028500 A1, US2003028500A1
Inventors Kevin Jameson
Original Assignee Jameson Kevin Wade
Patent Citations (4), Referenced by (5), Classifications (13), Legal Events (7)
US 20030028500 A1
thereby providing a solution to the scalable knowledge delivery problem, and thereby enabling application programs to obtain arbitrary processing knowledge in a fully-automated, scalable way that was not previously available.
thereby providing a solution to the mobile knowledge problem, and thereby making it possible for humans to associate particular bodies of knowledge with particular filesystem locations, and
thereby providing a solution to the workspace knowledge problem, and thereby making it possible for humans to associate particular bodies of knowledge with particular filesystem locations, and
thereby providing a solution to the platform dependent knowledge problem, and thereby helping to solve the knowledge organization problem, and thereby enabling application programs to share platform dependent application knowledge among various virtual platforms, to reduce knowledge maintenance costs.
thereby providing a solution to the shared knowledge problem, and thereby helping to solve the knowledge organization problem, and thereby helping to reduce knowledge maintenance costs by reducing the number of identical knowledge files required to support multiple application programs.
thereby providing a solution to the installable knowledge problem, and thereby helping to solve the knowledge organization problem, and thereby helping to reduce knowledge maintenance costs by enabling humans to work with smaller, mobile, encapsulated bodies of installable knowledge.
Collection Information Manager, Kevin Jameson.
[0081]FIG. 1 shows a sample prior art filesystem folder in a typical personal computer filesystem.
[0082]FIG. 2 shows how a portion of the prior art folder in FIG. 1 has been converted into a collection 100 by the addition of a collection specifier file 102 named “cspec” FIG. 2 Line 5.
[0083]FIG. 3 shows an example physical representation of a collection specifier 102, implemented as a simple text file such as would be used on a typical personal computer filesystem.
[0084]FIG. 4 shows four major information groupings for collections, including collection type definition 101, collection specifier 102, collection content 103, and collection 100.
[0085]FIG. 5 shows a more detailed view of the information groupings in FIG. 4, illustrating several particular kinds of per-collection-instance and per-collection-type information.
[0086]FIG. 6 shows a logical diagram of how a Collection Information Manager Means 111 would act as an interface between an application program means 110 and a collection information means 107, including collection information sources 101-103.
[0087]FIG. 7 shows a physical software embodiment of how an Application Program Means 110 would use a Collection Information Manager Means 111 to obtain collection information from various collection information API means 112-114 connected to various collection information server means 115-117.
[0088]FIG. 8 shows an example software collection datastructure that relates collection specifier and collection content information for a single collection instance.
[0089]FIG. 9 shows an example collection type definition datastructure, such as might be used by software programs that process collections.
[0090]FIG. 10 shows a more detailed example of the kinds of information found in collection type definitions.
[0091]FIG. 11 shows a basic knowledge tree structure that stores knowledge for two application programs, “app-1” and “app-2”.
[0092]FIG. 12 shows an example set of knowledge trees that store knowledge for a user, a team, a department, a company, and a vendor.
[0093]FIG. 13 shows an example set of search rules for locating knowledge within the trees of FIG. 12.
[0094]FIG. 14 shows examples of both static and dynamic search rules.
[0095]FIG. 15 shows knowledge trees containing shared knowledge.
[0096]FIG. 16 shows an example context name table containing two named contexts “default” and “debug”.
[0097]FIG. 17 shows how context stacks can be specified in command lines, environment variables, or in context anchor files.
[0098]FIG. 18 shows an example virtual platform name table.
[0099]FIG. 19 shows an example of how virtual platforms can be used in search rules to find platform-dependent knowledge before platform independent knowledge.
[0100]FIG. 20 shows a mobile knowledge collection that contains an internal knowledge tree structure.
[0101]FIG. 21 shows pathnames corresponding to the mobile knowledge tree shown in FIG. 20.
[0102]FIG. 22 shows an example of workspace knowledge comprised of several nested mobile knowledge collections.
[0103]FIG. 23 shows how an example search rule is built for the collection tree of FIG. 22.
[0104]FIG. 24 shows an example aggregated knowledge space comprised of several mobile collections.
[0105]FIG. 25 shows an example search rule expansion for the aggregated knowledge space of FIG. 24.
[0106]FIG. 26 shows an example aggregated knowledge space name table.
[0107]FIG. 27 shows how knowledge space stacks can be specified in command lines, environment variables, or in knowledge space anchor files.
[0108]FIG. 28 shows an example second set of constructed search rules containing generic rules for context, mobile, workspace, aggregated, and remote knowledge.
[0109]FIG. 29 shows an example knowledge treespace name table and an example knowledge treespace definition file.
[0110]FIG. 30 shows an example physical directory structure for a remote aggregated knowledge space.
[0111]FIG. 31 shows an example search rule containing a remote aggregated knowledge lookup expression.
[0112]FIG. 32 shows a name table and several definition files for remote aggregated knowledge names spaces.
[0113]FIG. 33 shows an example collection containing installable knowledge.
[0114]FIG. 34 shows an example custom “company” knowledge tree before and after an installable knowledge installation operation.
[0115]FIG. 35 shows a simplified architecture for an application program 120 that uses a CKS System 122 and CKS manager 130 to retrieve collection process knowledge from local knowledge stores 121.
[0116]FIG. 36 shows a simplified algorithm for an application program 120 using a CKS manager 130.
[0117]FIG. 37 shows a simplified architecture for a Module CKS Manager 130.
[0118]FIG. 38 shows a simplified algorithm for a Module CKS Manager 130.
[0119]FIG. 39 shows a simplified architecture for a Build Search Rules module 140.
[0120]FIG. 40 shows a simplified algorithm for a Build Search Rules module 140.
[0121]FIG. 41 shows how a second set of search rules can be constructed from various environment variables, tables, and definition files.
[0122]FIG. 42 shows the beginnings of an example second set of constructed search rules.
[0123]FIG. 43 shows an example context definition file for the “default” context.
[0124]FIG. 44 shows a second set of search rules where placeholder strings have been replaced with specific values for the current knowledge request.
[0125]FIG. 45 shows an example of aggregated knowledge in the form of an aggregated knowledge space named “agk-p1.”
[0126]FIG. 46 shows an example aggregated knowledge space name table and an example aggregated knowledge space definition file.
[0127]FIG. 47 shows an example second set of constructed search rules with aggregated knowledge rules included.
[0128]FIG. 48 shows a second set of constructed search rules containing search rules for the “debug”, “mine”, and “default” contexts, and after rules for mobile, workspace, and aggregated knowledge have been added to the rule set.
[0129]FIG. 49 shows a simplified architecture for a Perform Knowledge Lookups module 150.
[0130]FIG. 50 shows a simplified algorithm for a Perform Knowledge Lookups module 150.
[0131]FIG. 51 shows an example second set of uninstantiated search rules that contains examples of all search rules previously discussed.
[0132]FIG. 52 shows a simplified architecture for a client server CKS system.
[0133]FIG. 53 shows a list of example software functions for performing various kinds of lookups.
[0134]FIG. 54 shows a list of example parameters used by the lookup functions shown in FIG. 53.
List of Drawing Referenc Numbers
[0135]100 A collection formed from a prior art folder
[0136]101 Collection type definition information
[0137]102 Collection specifier information
[0138]103 Collection content information
[0139]104 Per-collection collection processing information
[0140]105 Per-collection collection type indicator
[0141]106 Per-collection content link specifiers
[0142]107 Collection information
[0143]110 Application program means
[0144]111 Collection information manager means
[0145]112 Collection type definition API means
[0146]113 Collection specifier API means
[0147]114 Collection content API means
[0148]115 Collection type definition server means
[0149]116 Collection specifier server means
[0150]117 Collection content server means
[0151]120 Application collection processing program
[0152]121 Local knowledge stores
[0153]122 Collection Knowledge System
[0154]130 Collection knowledge system manager module
[0155]131 Get runtime information module
[0156]132 Organize and return results module
[0157]140 Build search rules module
[0158]141 Get runtime search rule information module
[0159]142 Upsearch for context.root module
[0160]143 Upsearch for akspace.root module
[0161]144 Get initial context rules module
[0162]145 Add customized knowledge module
[0163]146 Instantiate mobile knowledge module
[0164]147 Instantiate workspace knowledge module
[0165]148 Instantiate aggregated knowledge module
[0166]150 Perform knowledge lookups module
[0167]151 Do local lookup module
[0168]152 Local cache manager module
[0169]153 Do remote lookup module
[0170]154 Remote cache manager module
[0171]160 Collection knowledge system client module
[0172]170 Collection knowledge system server module
[0173]171 Remote knowledge stores
Collections are sets of computer files that can be manipulated as a set, rather than as individual files. Collection are comprised of three major parts: (1) a collection specifier that contains information about a collection instance, (2) a collection type definition that contains information about how to process all collections of a particular type, and (3) optional collection content in the form of arbitrary computer files that belong to a collection.
[0186]FIG. 1 shows an example prior art filesystem folder from a typical personal computer filesystem. The files and directories shown in this drawing do not implement a collection 100, because no collection specifier 102, FIG. 2 Line 5 exists to associate a collection type definition 101 with collection content information 103.
[0187]FIG. 2 shows the prior art folder of FIG. 1, but with a portion of the folder converted into a collection 100 by the addition of a collection specifier file FIG. 2 Line 5 named “cspec”. In this example, the collection contents 103 of collection 100 are defined by two implicit policies of a preferred implementation.
[0190]FIG. 3 shows an example physical representation of a collection specifier file 102, FIG. 2 Line 5, such as would be used on a typical personal computer filesystem.
FIGS. 4-5 show three main kinds of information that are managed by collections.
[0193]FIG. 4 shows a high-level logical structure of three types of information managed by collections: collection processing information 101, collection specifier information 102, and collection content information 103. A logical collection 100 is comprised of a collection specifier 102 and collection content 103 together. This diagram best illustrates the logical collection information relationships that exist within a preferred filesystem implementation of collections.
[0194]FIG. 5 shows a more detailed logical structure of the same three types of information shown in FIG. 4. Collection type definition information FIG. 4 101 has been labeled as per-type information in FIG. 5 103 because there is only one instance of collection type information 101 per collection type. Collection content information FIG. 4 103 has been labeled as per-instance information in FIG. 5 103 because there is only one instance of collection content information per collection instance. Collection specifier information 102 has been partitioned into collection instance processing information 104, collection-type link information 105, and collection content link information 106. FIG. 5 is intended to show several important types of information 104-106 that are contained within collection specifiers 102.
Suppose that an application program means 110 knows (a) how to obtain collection processing information 101, (b) how to obtain collection content information 103, and (c) how to relate the two with per-collection-instance information 102. It follows that application program means 110 would have sufficient knowledge to use collection processing information 101 to process said collection content 103 in useful ways.
[0200]FIG. 6 shows how a collection information manager means 111 acts as an interface between an application program means 110 and collection information means 107 that includes collection information sources 101-103. Collectively, collection information sources 101-103 are called a collection information means 107. A collection information manager means 111 represents the union of all communication mechanisms used directly or indirectly by an application program means 110 to interact with collection information sources 101-103.
[0201]FIG. 7 shows a physical software embodiment of how an application program means 110 could use a collection information manager means 111 to obtain collection information from various collection information API (Application Programming Interface) means 112-114 connected to various collection information server means 115-117.
[0210]FIG. 8 shows an example collection datastructure that contains collection specifier and collection content information for a collection instance. Application programs could use such a datastructure to manage collection information for a collection that is being processed.
[0212]FIG. 9 shows an example collection type definition datastructure that could be used by application programs to process collections. Specific information content of a collection type definition datastructure is determined by implementation policy. However, collection type definitions typically contain information such as shown in FIGS. 9-10.
[0213]FIG. 10 shows example information content for a collection type definition datastructure such as shown in FIG. 9. FIG. 10 shows information concerning internal collection directory structures, collection content location definitions, collection content datatype definitions, collection processing definitions, and collection results processing definitions. The specific information content of a collection type definition is determined by implementation policy. If desired, more complex definitions and more complex type definition information structures can be used to represent more complex collection structures, collection contents, or collection processing requirements.
[0238]FIG. 12 shows an example set of knowledge trees that store knowledge for a user, a team, a department, a company, and a vendor. FIG. 13 shows an example set of search rules for locating knowledge within the trees of FIG. 12.
[0242]FIG. 13 shows a set of search rules that establish a relative precedence order among the directories shown in FIG. 12. In particular, the search rules of FIG. 13 give highest knowledge precedence to personal user knowledge and team knowledge, in that order, and lowest precedence to company and vendor knowledge, again in that order. This precedence is not required; other precedence orderings could be equally valid for other computational situations. Particular search rule list memberships and orderings are determined by implementation policy.
[0247]FIG. 14 shows examples of both static and dynamic search rules. Lines 1-6 show examples of static search rules. Lines 7-17 show examples of dynamic search rules that contain placeholder strings.
[0272]FIG. 16 shows a context name table containing two named contexts “default” and “debug”. Line 1 shows the physical location of the context table. Line 5 associates the “debug” context name with a context definition file named “debug.def”. Lines 6-8 show the contents of the “debug.def” context definition file. Lines 9-14 show a context definition file containing several search rules for the “default” context.
[0274]FIG. 17 shows how context stacks can be specified in command lines, environment variables, and in context anchor files (anchor files are explained later in this document). All three examples in FIG. 17 specify a two-context stack, with the “debug” context having precedence over the “mine” context. The “default” context is always implicitly added to the end of all context stacks, so there is no need to explicitly include it in context stack expressions.
[0280]FIG. 18 Columns 2-5 represent increasing levels of platform abstraction, from most platform specific (Column 2) to least platform specific (Column 5, platform independent). FIG. 19 shows an example of how virtual platforms can be used in search rules to find platform-dependent knowledge before shared platform independent knowledge. FIG. 14 Lines 10-13 show another example of how virtual platforms can be used in dynamic search rules.
[0299]FIG. 22 shows an example nested mobile collection tree containing one ancestor collection “my-workspace” Line 2 and three working collections Lines 11-19. FIG. 23 shows an example search rule built for the collection tree of FIG. 22. In particular, FIG. 23 Line 5 shows an example workspace search rule containing a placeholder string “_WKSPC_”. Assuming that an application program was working within the first of the nested working collections, the placeholder string “_WKSPC_” in Line 5 would be replaced by the pathname shown in Line 6, which points to knowledge Lines 16-17 stored within in the first mobile knowledge collection within the workspace.
[0306]FIG. 24 shows an example aggregated knowledge tree comprised of several mobile collections. FIG. 25 shows an example search rule expansion for the knowledge space of FIG. 24. In particular, FIG. 25 Line 2 shows a generic aggregated knowledge search rule containing placeholder strings. Lines 3-4 show how the placeholder strings would be replaced at runtime. Line 5 shows the resulting instantiated knowledge space search rule, which points at knowledge contained in the first mobile knowledge collection in FIG. 24 Line 7.
[0307]FIG. 26 shows an example aggregated knowledge space name table Lines 1-5 and an example aggregated knowledge space definition file Lines 6-11.
[0308]FIG. 27 shows how knowledge space stacks can be specified in command lines, environment variables, or in knowledge space anchor files (anchor files are explained later in this document). All three examples in FIG. 27 specify a knowledge space stack specifying two aggregated knowledge spaces, with the “agk-p1” knowledge space having precedence over the “dept 1” knowledge space.
[0313]FIG. 28 Lines 16-18 show some example remote lookup expressions. Line 16 shows the generic format of a remote lookup expression, which is comprised of 4 parts: a knowledge treespace name, a computer hostname, a knowledge tree name, and a virtual platform name. The generic “ktreespace” component represents the name of a group of remote knowledge trees (a ktreespace name). The “dns” component represents the DNS (Domain Name Service) name of a network host computer running a knowledge delivery system. The “ktree” component represents the name of a particular knowledge tree within the knowledge tree namespace provided in Part 1 of the name. The “vplt=gnulinux2” component represents a virtual platform name for platform dependent lookups.
[0314]FIG. 29 Lines 1-4 show an example ktreespace name table. Lines 6-11 show an example kreespace definition file that lists the names and locations of several knowledge trees Lines 9-11.
[0318]FIG. 30 shows an example physical directory structure that provides remote aggregated knowledge for a knowledge space named “agk-p1” within a remote aggregated knowledge namespace named “my-aknamespace”. These names can be seen in the name table and definition file of FIG. 32.
[0319]FIG. 31 shows an example search rule containing a remote aggregated knowledge lookup expression. The expression has 4 parts, like the remote knowledge expressions described before. Part 1 is the name of a remote aggregated knowledge namespace; Part 2 is the name of a DNS host computer; Part 3 is the name of an aggregated knowledge space within the Part 1 namespace; and Part 4 is the name of a virtual platform. Lines 1-2 show an example generic search rule. Lines 3-5 show how the generic rule would be expanded (that is, replicated and instantiated) for the three mobile knowledge collections shown in FIG. 30 Lines 4-16.
[0320]FIG. 32 shows three name table and definition files for remote aggregated knowledge spaces. Lines 1-5 show an example remote aggregated knowledge namespace name table. Lines 6-10 show an example remote aggregated knowledge namespace definition file. Lines 11-16 show an example remote aggregated knowledge space definition file that specifies various mobile knowledge collections.
[0326]FIG. 33 shows an example collection containing installable knowledge. Lines 5-8 show the tree structure of the installable knowledge tree, which is the same as all other knowledge trees discussed previously.
[0327]FIG. 33 Line 4, however, is a special directory name that is recognized by the implementation. The special directory name on Line 4 tells the implementation that the installable knowledge tree should be installed in the custom knowledge tree for the “company” context.
Special directory names are not required. For example, user-defined installable knowledge directory names are possible within an installable knowledge collection. However, it is both practical and convenient to define a few standard installable knowledge directory names within an implementation, so that standard command sequences can be automatically used by the implementation to recognize and install or uninstall installable knowledge. If non-standard names are used, the implementation must be capable of automatically determining how to install knowledge contained in nonstandard installable knowledge directories.
[0330]FIG. 34 shows an example custom “company” knowledge tree before and after installable knowledge has been installed. Lines 1-2 show the original custom company tree before installation; the tree is empty. Lines 3-11 show the knowledge tree after installation. The post-installation tree contains a variety of knowledge files for two applications named “app-1” and “app-2”.
[0333]FIG. 33 Lines 5-8 show examples of a special installable knowledge installation directory, which is named “d-i” (directory installable) in this example. The particular name of the special installable knowledge directory is determined by implementation policy. Line 5 shows the name of a first installable knowledge index file, “idx-svc.tbl”. Line 6 shows the corresponding data directory name, “z-svc”. Line 7 shows a second installable knowledge index file, “idx-app2-data.tbl”. Line 8 shows the matching data directory name, “z-app2-data”.
[0358]FIG. 35 shows a simplified architecture for an application program 120 that uses a CKS System 122 and CKS manager 130 to retrieve knowledge from local knowledge stores 121. A CKS manager module 130 oversees the process of building search rules and performing knowledge lookups.
[0359]FIG. 36 shows a simplified algorithm for an application program using a CKS manager 130. In operation, an application program calls a CKS manager 130 to retrieve and return knowledge that the application program requires to achieve its computational goals.
[0361]FIG. 37 shows a simplified architecture for a Module CKS Manager 130.
[0372]FIG. 39 shows a simplified architecture for a Build Search Rules module 140.
[0391]FIG. 41 Lines 8-13 show a context name table that is located by looking up the name “context.tbl” using the initial search rules Lines 2-7. The first “context.tbl” file located using the initial search rules is selected for use.
[0394]FIG. 41 Lines 14-16 show an example context definition file for the “debug” context (which represents customized debugging knowledge). The single search rule FIG. 41 Line 16 in the found definition file specifies that the current user's home directory should be searched to obtain customized personal debugging knowledge.
[0395]FIG. 41 Lines 17-19 show an example context definition file for the “mine” context, which represents the personal customized knowledge of an individual user.
[0398]FIG. 42 shows a second set of search rules that has been constructed from the examples so far. Note that rules for the “debug” context appear before rules for the “mine” context. This is because the debug context was listed first on the context stack of FIG. 17.
[0401]FIG. 43 shows an example context definition file for the “default” context. It contains generic, uninstantiated rules for mobile knowledge Lines 5-8, workspace knowledge Line 11, aggregated knowledge Line 14, and default customized knowledge for team, company, and vendor Lines 17-19.
[0409]FIG. 43 shows an example context definition file containing search rules for a “default” context. The example file contains various placeholder strings such as “_COLL_”, “_WKSPC_”, “_app_”, “_AKNAME_”, and “_AKCOLL_” that are replaced at runtime with specific values for the current knowledge request. The mobile knowledge placeholder strings mean the following things: “_COLL_” is the current mobile knowledge collection, and “_app_” is the application program for which knowledge is being requested. Other placeholder strings are explained below.
[0412]FIG. 44 shows a second set of search rules where placeholder strings have been replaced with specific values for the current knowledge request. The set of search rules was constructed by starting with the “debug” context search rule, then appending the “mine” and “default” context search rules, then replacing all placeholder strings with specific values for the current knowledge request. The mobile knowledge search rule on FIG. 44 Line 9 uses a mobile knowledge collection pathname from FIG. 20 Line 9.
[0418]FIG. 43 shows an example context definition file containing search rules for a “default” context. The example file contains various placeholder strings such as “_WKSPC_” and “_app_” that are replaced at runtime with specific values for the current knowledge request. The workspace knowledge placeholder strings mean the following things: “_WKSPC_” is the name of an ancestor mobile knowledge collection, and “_app_” is the application for which knowledge is being requested.
[0423]FIG. 45 shows an example of aggregated knowledge in the form of an aggregated knowledge space named “agk-p1.” This aggregated knowledge space contains three mobile knowledge collections Lines 6, 12, 18.
[0427]FIG. 47 shows the growing second set of constructed search rules again, this time with aggregated knowledge included. FIG. 43 Line 14 shows a generic aggregated knowledge rule containing placeholder strings. The placeholder “_AKNAME_” represents the base directory of the knowledge space; in this example, “/site/agk/p1 .” The placeholder “_AKCOLL_” represents a particular collection within a kspace.
[0428]FIG. 47 Lines 12-14 show several completed aggregated knowledge search rules after instantiation and placeholder replacement has occurred. As can be seen, the completed directory pathnames correspond to three knowledge space directories shown in FIG. 45 Lines 10, 16, 22. Thus the generic set of aggregated knowledge search rules was instantiated three times, one for each mobile collection in the aggregated knowledge space of FIG. 45.
[0430]FIG. 48 shows the second set of constructed search rules after search rules for the “debug”, “mine”, and “default” contexts have been added to the rule set. In addition, example rules for mobile, workspace, and aggregated knowledge have been instantiated. This set of instantiated search rules could be used to perform a local lookup operation.
[0433]FIG. 49 shows a simplified architecture for Module Perform Knowledge Lookups 150.
[0443]FIG. 52 shows a simplified architecture for a client server CKS system.
[0452]FIG. 29 Lines 1-4 show an example knowledge treespace name table, and Lines 6-11 show an example knowledge treespace definition file “my-cks.def” that lists the names and locations of several knowledge trees Lines 9-11.
[0456]FIG. 32 shows example tables and definition files for remote aggregated knowledge lookups. Lines 1-5 show an example remote aggregated knowledge namespace name table. Lines 6-10 show an example remote aggregated knowledge namespace definition file. Lines 11-16 show an example remote aggregated knowledge space definition file that specifies three mobile knowledge collections corresponding to FIG. 30.
[0460]FIG. 53 shows a list of example software functions for performing various kinds of lookups in a Collection Knowledge System. Although the list of functions is suitable for a preferred filesystem embodiment of a CKS system, other functions are also possible. The use of particular lookup functions is determined by implementation policy.
[0462]FIG. 54 shows a list of example parameters used by the functions shown in FIG. 53. Parameters have been grouped to show those that are required by all the example lookup functions shown in FIG. 53, and those that are required by only some lookup functions. Only those functions that search for particular keys or values use the key-name parameter. The use of particular parameters for particular lookup functions is determined by implementation policy.
US8560599 * Nov 15, 2010 Oct 15, 2013 Hamid Hatami-Hanza Automatic content composition generation
US9367644 * Jul 26, 2010 Jun 14, 2016 Emc Corporation Object tree walking
US20100299357 * Jul 26, 2010 Nov 25, 2010 Emc Corporation Object tree walking
US20110125837 * Nov 15, 2010 May 26, 2011 Hamid Hatami-Hanza Automatic Content Composition Generation
US20140006317 * Sep 4, 2013 Jan 2, 2014 Hamid Hatami-Hanza Automatic content composition generation
U.S. Classification 706/45, 706/46, 706/61
International Classification G06F7/00, G06F17/30, G06F12/00, G06F9/44, G06N5/02, G06F9/445
Cooperative Classification G06N5/022, G06F8/20
European Classification G06F8/20, G06N5/02K
Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE NAME PREVIOUSLY RECORDED AT REEL: 034514 FRAME: 0496.ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNOR:COVERITY, INC;REEL/FRAME:035121/0570