DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This Non-Final Office Action is in reply to the application filed on 17 May 2024.
Claims 1-18 have been canceled.
Claims 19-39 have been added.
Claims 19-39 are currently pending and have been examined.
Information Disclosure Statement
The Information Disclosure Statements filed on 01 May 2024 has been considered. An initialed copy of the Form 1449 is enclosed herewith.
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.
Claims 19-39 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract without significantly more.
Under Step 1 the claims are analyzed to determine whether they are directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. See MPEP §2106.03.
Claims 19-28 and 39 are directed to a method and claims 29-38 are directed to a system. Therefore, the claims fall within the statutory categories of invention.
Under Step 2A Prong 1, the claims are analyzed to determine whether the claims recite any judicial exceptions including certain groupings of abstract ideas (i.e., mathematical concepts, certain methods of organizing human activity such as a fundamental economic practice, or mental processes). See MPEP §2106.04.
Claims 19 and 29 recite the abstract idea, generate a first booklet comprising a first content owned by a first user, the first content associated with a first context, the first context associated with a first facet owned by the first user, grant visibility to the first content to a first list of users associated with the first context such that the first list of users can view the first content on their respective display devices, receive a request from a second user to contribute a second content owned by the second user through a second facet owned by the second user, the second content associated with a second context, the second context associated with the second facet owned by the second user, the second content being a child-content of the first content owned by the first user, and grant visibility to the second content to a second list of users associated with the second context, the second list of users determined by applying an intersection operator (∩) to a list of users associated with the second facet and the first list of users such that the second list of users can view the second content on their respective display devices.
These limitations recite a process that, under its broadest reasonable interpretation, covers certain methods of organizing human activity including commercial or legal interactions (including business relations) & managing personal behavior or relationships or interactions between people (including social activities and following rules or instructions) as the claims may be performed by users determining access to content as traditionally performed in organizations. For example, during a collaboration, subgroups can be formed to work on specific project areas and control of document distribution and editing can be such that only the members of subgroups will have permission to access the documents, not the entire group of collaborators.
Claim 39 recites the abstract idea, generate a first booklet comprising a first content owned by the first user, the first content associated with a first context, the first context associated with a first facet owned by the first user, grant access to a second user to contribute a second content owned by the second user through a second facet owned by the second user, the second content associated with a second context, the second context associated with the second facet owned by the second user, the second content being a child-content of the first content owned by the first user, if: (i) the first context or any further selected plurality of contexts owned by the first user based on the first hierarchical order includes at least one eligible first context in which a list of users granted access to the at least one eligible first context associates the first user with the second user; and (ii) the second context or any further selected plurality of contexts owned by the second user based on the second hierarchical order includes at least one eligible second context in which a list of users granted access to the at least one eligible second context associates the first user with the second user; grant visibility to the second content by applying a privacy rule based at least on the first hierarchical order applied to select a plurality of eligible first facets owned by the first user, the second hierarchical order applied to select a plurality of eligible second facets owned by the second user, and at least an intersection operator (∩) applied to a list of users associated to the plurality of eligible first facets owned by the first user and a list of users associated to the plurality of eligible second facets owned by the second user; grant access to a third user to contribute a third content owned by the third user through a third facet owned by the third user, the third content associated with a third context, the third context associated with the third facet owned by the third user, the third content being a child-content of the second content owned by the second user, if: (i) the first context or any further selected plurality of contexts owned by the first user based on the first hierarchical order includes at least one eligible first context in which a list of users granted access to the at least one eligible first context associates the first user with the third user and associates the first user with the second user; and (ii) the third context or any further selected plurality of contexts owned by the third user based on a third hierarchical order includes at least one eligible third context in which a list of users granted access to the at least one eligible third context associates the third user with the first user and associates the third user with the second user.
These limitations recite a process that, under its broadest reasonable interpretation, covers certain methods of organizing human activity including commercial or legal interactions (including business relations) & managing personal behavior or relationships or interactions between people (including social activities and following rules or instructions) as the claims may be performed by users determining access to content as traditionally performed in organizations. For example, during a collaboration, subgroups can be formed to work on specific project areas and control of document distribution and editing can be such that only the members of subgroups will have permission to access the documents, not the entire group of collaborators.
Dependent claims 20 and 30 recite, receive a request from a third user to contribute a third content owned by the third user through a third facet owned by the third user, the third content associated with a third context, the third context associated with the third facet owned by the third user, the third content being a child- content of the second content owned by the second user, and grant visibility to the third content to a third list of users associated with the third context, the third list of users determined by applying an intersection operator (∩) to a list of users associated with the third facet and the second list of users such that the third list of users can view the third content on their respective display devices.
Dependent claims 21 and 31 recite, receive a request from the first user to share the first content owned by the first user through the first facet.
Dependent claims 22 and 32 recite, wherein the first facet is associated with a plurality of relationship types, and the request from the first user to share the first content includes a selection of one or more of the plurality of relationship types, and the second facet is associated with a plurality of relationship types, and the request from the second user to contribute the second content includes a selection of one or more of the plurality of relationship types.
Dependent claims 23 and 33 recite, wherein the list of users associated with the second facet is selected by the second user and the list of users associated with the third facet is selected by the third user.
Dependent claims 24 and 34 recite, wherein the list of users associated with the second facet and the list of users associated with the third facet are electronically selected according to a predefined selection criteria.
Dependent claims 25 and 35 recite wherein the list of users associated with the second facet is electronically selected by identifying the first user in the list of users associated with the second facet, and the list of users associated with the third facet is electronically selected by identifying the second user in the list of users associated with the third facet.
Dependent claims 26 and 36 recite, wherein the second facet is associated with a plurality of sets of users and the list of users associated with the second facet is electronically selected based on identifying the first user in at least one of the plurality of sets of users associated with the second facet.
Dependent claims 27 and 37 recite, wherein the third facet is associated with a plurality of sets of users and the list of users associated with the third facet is electronically selected based on identifying the second user in at least one of the plurality of sets of users associated with the third facet.
Dependent claims 28 and 38 recite, wherein at least one of the list of users associated with the second facet and the list of users associated with the third facet is an aggregated list of users determined by applying a union operator (U) to a plurality of sets of users.
The dependent claims further recite a method of organizing human activity because they recite receiving requests to contribute content and further rules for granting visibility.
Under Step 2A Prong 2 the claims are analyzed to determine whether the claims recite additional elements that integrate the judicial exception into a practical application. See MPEP §2106.04(d).
Claims 19, 29 and 39 recite the additional elements, an electronic database configured to store a plurality of records…, an electronic processing system comprising a computer server in communication with the electronic database and the online social network and respective display devices. The additional elements are recited at a high-level of generality and perform generic computing functions such as storing, communicating, generating, receiving, and displaying information. In this case, the claims merely involve automated steps executed by generic computing components recited above at a high-level of generality with no technical improvement to the functioning of the database, processing system, computer server, social network or display devices since the additional element is no more than mere instructions to apply the abstract idea using a generic computing components.
The dependent claims 20-28 and 30-38 merely reiterate the same abstract ideas using the same additional elements as recited above for receiving, requesting, displaying without imposing any meaningful limits or any further practical application.
Considered in combination, the additional elements add nothing that is not already present when the steps are considered separately. The sequence of the claimed limitations is equally generic and otherwise held to be abstract since the combination of these additional elements is no more than mere instructions to apply the judicial exception using generic computer components. Therefore, the additional elements recited in the claimed invention individually, and even in combination, fail to integrate the recited judicial exception into any practical application since they do not impose any non-generic meaningful limits on practicing the abstract idea.
Under Step 2B the claims are analyzed to determine whether the claims recite additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception.
Claims 19-39 as a whole do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to Step 2A Prong Two, the additional elements in the claims amount to no more than mere instructions to apply the exception using generic computer components. The same analysis applies here in 2B and does not provide an inventive concept.
Considered as an ordered combination, the additional elements of the claim do not add anything further than when they are considered separately. Thus, under Step 2B, the claims are ineligible as the claims do not recite additional elements which result in significantly more than the abstract idea itself.
Allowable Subject Matter
Claims 19-39 are allowed over prior art. The following is a statement of reasons for the indication of allowable subject matter:
No prior art has been found to disclose the distinct features in the independent claims:
Claims 19 and 29: receive a request from a second user to contribute a second content owned by the second user through a second facet owned by the second user, the second content associated with a second context, the second context associated with the second facet owned by the second user, the second content being a child-content of the first content owned by the first user, and grant visibility to the second content to a second list of users associated with the second context, the second list of users determined by applying an intersection operator (∩) to a list of users associated with the second facet and the first list of users such that the second list of users can view the second content on their respective display devices.
Claim 39: generate a first booklet comprising a first content owned by the first user, the first content associated with a first context, the first context associated with a first facet owned by the first user, grant access to a second user to contribute a second content owned by the second user through a second facet owned by the second user, the second content associated with a second context, the second context associated with the second facet owned by the second user, the second content being a child-content of the first content owned by the first user, if: (i) the first context or any further selected plurality of contexts owned by the first user based on the first hierarchical order includes at least one eligible first context in which a list of users granted access to the at least one eligible first context associates the first user with the second user; and (ii) the second context or any further selected plurality of contexts owned by the second user based on the second hierarchical order includes at least one eligible second context in which a list of users granted access to the at least one eligible second context associates the first user with the second user; grant visibility to the second content by applying a privacy rule based at least on the first hierarchical order applied to select a plurality of eligible first facets owned by the first user, the second hierarchical order applied to select a plurality of eligible second facets owned by the second user, and at least an intersection operator (∩) applied to a list of users associated to the plurality of eligible first facets owned by the first user and a list of users associated to the plurality of eligible second facets owned by the second user; grant access to a third user to contribute a third content owned by the third user through a third facet owned by the third user, the third content associated with a third context, the third context associated with the third facet owned by the third user, the third content being a child-content of the second content owned by the second user, if: (i) the first context or any further selected plurality of contexts owned by the first user based on the first hierarchical order includes at least one eligible first context in which a list of users granted access to the at least one eligible first context associates the first user with the third user and associates the first user with the second user; and (ii) the third context or any further selected plurality of contexts owned by the third user based on a third hierarchical order includes at least one eligible third context in which a list of users granted access to the at least one eligible third context associates the third user with the first user and associates the third user with the second user.
The closest prior art Arlein et al. (US Pub. No. 2002/0133500) discloses:
[0010] To this end, in accordance with one aspect of the invention, the present invention protects a user by employing the abstraction of a "persona," or a role, as will be explained in detail below, in which a user conducts web activity. A user can have many personae, with the property that only the user's activities undertaken while in a given persona can be linked in a profile. This gives the user a convenient and natural way to partition information about himself or herself into persona profiles that she can selectively reveal. For example, a user may create one persona for work, one for recreation, and one for when his or her children use the browser. (persona = facet; environment = context)
[0032] As mentioned above, an abstraction that the invention provides to the user is that of having the ability to have multiple personae. A persona represents a role in which the user engages in web activity. Examples of personae may be, but not limited to, "work," "entertainment," "medical," "shopping," "investing," etc. The relevant feature of a persona is that activities undertaken by the user while acting in a given persona can be linked and profiled across sites. So, if a user visits two different sites under a "work" persona, then information about the user's activities undertaken at each site are available to the other site, provided that both sites allow this. However, if the user visits a site under a "work" persona, then the user need not fear that his or her "entertainment" activities will become known to that site.
[0033] It is to be understood that while the terms "persona" and "persona profile" may occasionally be used interchangeably herein, more specifically, a persona represents a role a user engages in during network activities and a persona profile is a set of information accumulated in association with a given persona. In some cases, the term "profile" is used wherein, from its context, it is understood to refer to a profile associated with a persona, as opposed to a user profile.
[0034] Because it is intrinsically difficult to prevent the correlation of two personae of the same user at a single site--e.g., the two personae could be linked based on IP (Internet Protocol) address or even browsing behavior--by default, the invention allows a merchant to read the profile of only one persona per user. This is achieved by granting read credentials to a merchant for only that persona. For a different persona employed by the user on a subsequent visit to that site, the merchant is not given credentials to read that persona's profile. However, the merchant may still be given credentials to contribute records to this different persona, if the user permits.
[0046] The personae server 206 resides in the network to support the management of user personae and the issuance of PACs. Each user who employs the inventive infrastructure holds an account at the personae server. This account allows the user to create new personae and manage policies for existing personae. Users must trust the personae server to accurately enforce the policies the user specifies for her personae, and to not disclose relationships between personae and users to merchants.
[0055] (i) Rights conveyed with PACs. As described in the previous section, a PAC granted to a merchant enables that merchant to access the information in a PDB associated with the persona named in this PAC. With one exception described below, by default, a PAC conveys "read" rights, which enable the merchant to read records in the PDB associated with the persona, and "insert" rights, which enable the merchant to insert new records about that persona. However, a user could grant only one of these to a merchant. For example, a user may grant a site only read access if the user does not want his or her activities at that site added to his or her profile associated with the particular selected persona. The user may grant only insert access if the user does not want the site he or she is visiting to learn his or her other profiled data, but the user is comfortable with that site adding data to the profile. A third type of access can be granted: "delete" rights, which enable the merchant to delete records associated with the persona from the PDB. Delete rights make it possible to set up a monitoring site that users can visit to review the information stored about their personae in a PDB and delete records of their choosing.
[0084] The data protection model provided by the invention for this task is based on information flow models, specifically tainting. Intuitively, one datum in the system taints another if the value of the second was influenced by the value of the first. A tainting model enforces the policy that if .alpha. taints .alpha.', then .alpha.' can be used only in ways that .alpha. has been authorized to be used. So, for example, if the owner of .alpha. specified that it not be disclosed, then .alpha.' cannot be disclosed either. The general idea for using tainting to protect merchant data in the inventive infrastructure is that for each record .alpha. that a merchant inserts into the PDB, the merchant specifies sets of other merchants to which it will allow that record, or anything that record taints, to flow. So, for example, if a merchant reads .alpha. and uses it to customize pages for a user, and then the merchant inserts a record .alpha.' based on the user's subsequent behavior (e.g., perhaps the user bought what the merchant displayed), then .alpha.' can be read only by merchants that the merchant who wrote .alpha. allows it to.
Thattai et al. (US Pub. No. 20080172461) discloses:
[0072] FIG. 4 is a table view of information associated with the different persona profiles, according to one embodiment. Particularly, FIG. 4 illustrates a user field 400, a persona field 402, a status field 404, a vault key field 406, and other field 408, according to one embodiment.
[0073] The table 450 of FIG. 4 illustrates information associated with the different persona profiles (e.g., name of the user, the persona, status of the persona profile, a vault key status, etc.). The user field 400 may display names of the user associated with the particular persona profile. The persona field 402 may display the different contexts of communication that may be taking place between the particular user and other parties. The Status field 404 may display the information associated with the status of the persona profile of the particular user.
[0074] The vault key field 406 may display whether the particular user has access to the vault keys (e.g., the vault key may enable the user to access the invisible persona profile.). The other field 408 may display other information associated with the user (e.g., feedback rating of the user, contacts list, events, company name, etc.).
[0075] In example embodiment illustrated in FIG. 4, the user field 400 displays "JOHN" in the first row, "JOHN" in the second row, "JOHN" in the third row, "JANE" in the fourth row, and "JANE" in the fifth row of the user field 400 column of the table 450. The persona field 402 as illustrated in example embodiment of FIG. 4 displays "WORK" in the first row, "HOME" in the second row, "AFTER HOURS" in the third row, "SOCIAL" in the fourth row, and "VACATION" in the fifth row of the persona 402 column of the table 450.
[0076] The status field 404 displays "PUBLIC" in the first row, "CONFIDENTIAL" in the second row, "INVISIBLE" in the third row, "CONFIDENTIAL" in the fourth row, and "PUBLIC" in the fifth row of the status field 404 column of the table 450. The vault key field 406 displays "N" in the first row, "N" in the second row, "Y" in the third row, "Y" in the fourth row, "N" in the fifth row of the vault key field 406 column of the table 450 of FIG. 4.
[0077] In the example embodiment illustrated in FIG. 4, the other field 408 displays "A, B, N" in the first row, "C, A, D" in the second row, "O, A" in the third row, "B, D" in the fourth row, and "A, C" in the fifth row of the other field 408 column of the table 450 of FIG. 4.
[0078] For example, the persona profiles (e.g., the persona profile 500 of FIG. 5) are displayed as including an "Invisible" persona profile, a "Confidential" persona profile, and a "Public" persona profile. The "Invisible" persona profile may be accessible by the user (e.g., the user 400 of FIG. 4) only after applying a vault key (e.g., the vault key 406 of FIG. 4) that enables an invisible relationship in the "Invisible" persona profile (e.g., the persona profile 500 of FIG. 5), and/or invisible contacts and invisible groups are made visible only when the vault key (e.g., the vault key 406 of FIG. 4) is applied.
W. Villegas, B. Ali and M. Maheswaran, "An Access Control Scheme for Protecting Personal Data," 2008 Sixth Annual Conference on Privacy, Security and Trust, Fredericton, Canada, 2008, pp. 24-35, doi: 10.1109/PST.2008.14 discloses:
The PDAC protocol components described so far deals with the original posting of a data object. To maintain the confidentiality of a data object, reposting of data objects must also be considered. In particular, reposts that are based on previous content held by the Content Manager in the TDS should have confidentiality limits that are consistent with the confidentiality requirements of the original data object. Suppose Alice posts a personal photo album on the TDS with friend-of-a-friend reject limit. Alice's friend Carol can access it and repost it with her comments. The confidentiality limits specified as part of the original data (Alice's photo album) does not dictate the confidentiality constraints that should be used by Carol. If Carol reposts the same album with a friend-of-a-friend reject limit, users who do not meet the original trusted distance requirement can access Alice's photos. This clearly violates the original confidentiality requirements. To prevent such inconsistent confidentiality specifications which can lead to information leakage, the TDS has a Data Leak Manager which enforces constraints on the confidentiality requirements that can be attached with a data object. For instance, when Carol submits a data object to TDS for posting, the Data Leak Manager performs a similarity analysis of that object against the data objects to which Carol recently gained access (Page 9, Section 4.4)
However, the closest prior art either singularly or in combination, fail
anticipate or render obvious the distinct claim features of the independent claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Hull et al (US 20050177385 A1): For example, the client application may enable a user to interact with the browser application, email application, and the like, to customize how another social network user might view a persona, profile, or the like associated with the user. For example, the user may employ the client application, in part, to provide one customized view for family members, another customized view for poker members, yet another view for fishing buddies, and the like. The client application may interact with a process such as described below in conjunction with FIG. 3 to customize and manage such views.
N. Elahi, M. M. R. Chowdhury and J. Noll, "Semantic Access Control in Web Based Communities," 2008 The Third International Multi-Conference on Computing in the Global Information Technology (iccgi 2008), Athens, Greece, 2008, pp. 131-136, doi: 10.1109/ICCGI.2008.46 describes, access to the resources is controlled by defining differential access rights based on the relationships between the individuals and the communities. Instead of explicit definition, some additional facts of the mechanisms are inferred by executing Semantic Web rules using the Jess rule engine over the designed ontology. These information are then passed back to the ontology to enrich the existing ontology (page 131).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAAME BALLOU whose telephone number is (571)270-1359. The examiner can normally be reached Monday-Friday 9am-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, Lynda Jasmin can be reached at 571-272-6782. 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.
MAAME BALLOU
Examiner
Art Unit 3629
/MAAME BALLOU/Examiner, Art Unit 3629
/LYNDA JASMIN/Supervisory Patent Examiner, Art Unit 3629
Prosecution Insights