DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-7 and 9-21 have been examined.
Response to Arguments
Applicant's arguments filed on 4/30/26 have been fully considered but they are not persuasive.
Regarding Applicant’s remarks, Applicant mainly argues that the prior art of record does not explicitly disclose the amended limitations of “wherein the third request to access the software domain resource is rejected when the third request to access the software domain resource is associated with an attempt to access a set of the plurality of software domain resources that span multiple service providers, based on determining that the third request to access the software domain resource includes the service provider user identity.” However, the examiner disagrees for the following reasons.
As indicated in interview conducted on 4/24/26, the claims are examined based on broadest reasonable interpretation consistent with the Specification and Applicant is advised to further clarify context and steps involved in controlling access. As explained in the Office Action mailed on 3/11/26, the prior art of record discloses granular level of access control to user data by different service providers. The combination of references teaches or at least suggests preventing access when the scope of access request exceeds what is authorized based on UserName/provider identity (Juarez: Fig. 27 and [0107]- [0108]: allowing or denying access according to entitlements and permissions tuned to the finest level of granularity). Therefore, Applicant’s argument is not persuasive in light of above explanation.
Examiner’s Comment
The claims recite steps to allow users to define access control policies associated with data/resources provided by the users based on personas or roles. In this case, the specific context involves resource consumers and providers. However, the steps of defining and enforcing access control policies are recited at a high level of generality, akin to any well-known role based access control method set by data owners in collaborative settings based on different roles/personas.
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.
Claims 1-7 and 9-21 are rejected under 35 U.S.C. 103 as being unpatentable over Juarez et al. U.S. Pub. No. 2005/0131830 (hereinafter Juarez) in view of Machani et al. U.S. 10,091,230 (hereinafter Machani).
As per claim 1, 9 and 17, Juarez discloses a system/method/non-transitory computer readable medium for multi-persona resource access and collaboration, the system comprising:
one or more memories; and
one or more processors, communicatively coupled to the one or more memories, configured to:
receive, from a first client device, a first request to create a plurality of software domain resources associated with a plurality of consumer type and a plurality of service consumer user identities (Juarez: [0015]: the system allows consumer to attach multiple custom provider information request sections to their profile data, i.e. create software domain resources associated with different providers at UserName level; [0086]: UserName types can be consumer, provider, and guests such as third party partners, vendors, conference attendees, etc.);
receive, from the first client device, a second request to share a subset of the plurality of software domain resources with one or more service provider user identities associated with a provider type (Juarez: Fig. 12: providers and consumers can self-regulate the level of profile information shared among authorized UserNames; [0088]: consumer can establish their own UserName and select disclosure levels for third party UserNames; [0086]: UserName types/groups including consumers, providers and guests),
store access control information associated with the software domain resource of the plurality of software domain resources, wherein the access control information indicates that the one or more service provider user identities associated with the second request have permission to access the software domain resource (Juarez: [0093]: access control information associated with resources and authorized entities are defined and stored; [0100]: a consumer or provider granting an access entitlement to a third party UserName by assigning different disclosure levels);
receive, from a second client device associated with a service provider user identity of the one or more service provider user identities, a third request to access the software domain resource (Juarez: [0095]-[0100]: only entities authorized can access resources based on authorization levels); and
provide, to the second client device, information that indicates whether the third request to access the software domain resource is granted or rejected based on the access control information associated with the software domain resource and the service provider user identity associated with the second client device based on determining that the third request to access the software domain resource includes the service provider user identity (Juarez: Fig. 27 and [0107]- [0108]: allowing or denying access according to entitlements and permissions tuned to the finest level of granularity).
Juarez discloses data collection and distribution platform based on different UserName types, e.g. consumer, provider, guests, etc., and the platform enforces data sharing rules or permissions set by consumers and providers (Juarez:[0005]: resource consumer and resource providers, e.g. bank, venture capitalist, a bank, an accounting firm, a law firm, a business partner, etc.; [0015]: only specific UserNames are allowed to access specific pieces of data; [0100] and [0107]-[0108]: establish permissions by consumer and providers). Juarez does not explicitly recite “persona.” However, establishing access control policies based on roles or personas is well known in the art. Therefore, it would have been obvious to one having ordinary skill in the art to specifically different personas for different entities types to provide granular data sharing controls.
Juarez does not explicitly disclose wherein the request to access the software domain resource is rejected when the third request to access is associated with attempt to access to a set of software domain resources that span multiple service providers. However, Machani discloses controlling access to user data collected from multiple service providers, wherein the user can control access (e.g. reject request) when the requesting entity does not have authorization to access the global profile data (i.e. data spanning multiple service providers) associated with the user (Machani: col. 1 line 39 – col. 2 line 58). It would have been obvious to one having ordinary skill in the art to define access to user data that are aggregated from multiple service providers in collaboration setting because Juarez and Machani are analogous art involving access control to user provided data. The motivation to combine would be to restrict sharing of data collected by other service providers related to particular user without user consent. Furthermore, it is well known in the art to define specific access conditions to preserve privacy of other data providers based on system design.
As per claim 2, 10 and 18, Juarez as modified discloses the limitations of claims 1, 9 and 17 respectively. Juarez further discloses wherein the information provided to the second client device indicates that the third request to access the software domain resource is granted based on the access control information indicating that the service provider user identity associated with the second client device is included among the one or more service provider user identities that have permission to access the software domain resource (Juarez: Fig. 27 and [0107]- [0108]: allowing or denying access according to entitlements and permissions tuned to the finest level of granularity).
As per claim 3, 11 and 19, Juarez as modified discloses the limitations of claims 2, 10 and 18 respectively. Juarez further discloses wherein the information provided to the second client device indicates that the third request to access the software domain resource is granted further based on the third request including an attempt to access a set of software domain resources that is associated only with the service provider user identity associated with the second client device (Juarez: Fig. 27 and [0107]- [0108]: allowing or denying access according to entitlements and permissions tuned to the finest level of granularity, e.g. enterprise software only).
As per claim 4, 12 and 20, Juarez as modified discloses the limitations of claims 1, 9 and 17 respectively. Juarez further discloses or at least suggests wherein the information provided to the second client device indicates that the third request to access the software domain resource is rejected based on the access control information indicating that the service provider user identity associated with the second client device is not included among the one or more service provider user identities that have permission to access the software domain resource (Juarez: Fig. 27 and [0107]- [0108]: allowing or denying access according to entitlements and permissions tuned to the finest level of granularity).
As per claim 5 and 13, Juarez as modified discloses the limitations of claims 1 and 9 respectively. Juarez further discloses wherein the information provided to the second client device indicates that the third request to access the software domain resource is rejected based on the third request including an attempt to access a set of software domain resources associated with multiple service provider user identities (Juarez: Fig. 27 and [0107]- [0108]: allowing or denying access according to entitlements and permissions tuned to the finest level of granularity). It would have been obvious matter of design choice to specify different conditions/criteria to address different usage contexts since Juarez’s system of providing fine-grained access control to resource consumer and provider with respect to data collection would work equally well regardless of usage criteria.
As per claim 6 and 14, Juarez as modified discloses the limitations of claims 1 and 9 respectively. Juarez further discloses wherein the one or more processors are further configured to:
receive, from one or more client devices associated with a provider persona type, information to create one or more software domain resources associated with the provider persona type, wherein the one or more software domain resources are each associated with access control information that indicates one or more service consumer user identities that have permission to access the software domain resource (Juarez: [0013]-[0015]: providers can establish profiles and permissions to collect and distribute resources);
receive, from the first client device, a fourth request to access software domain resources that are associated with the service consumer user identity of the first client device (Juarez: Fig. 27 and [0107]- [0108]: receive request to access data); and
provide, to the first client device, information that indicates whether the fourth request is granted or rejected based on the access control information associated with the one or more software domain resources associated with the provider persona type (Juarez: Fig. 27 and [0107]- [0108]: allowing or denying access according to entitlements and permissions tuned to the finest level of granularity).
As per claim 7 and 15, Juarez as modified discloses the limitations of claims 6 and 14 respectively. Juarez further discloses wherein the information provided to the first client device indicates that the fourth request is granted based on the access control information associated with the one or more software domain resources associated with the provider persona type indicating that the service consumer user identity associated with the first client device is included among the one or more service consumer user identities that have permission to access the software domain resource (Juarez: Fig. 27 and [0107]- [0108]: allowing or denying access according to entitlements and permissions tuned to the finest level of granularity; [0131]-[0132]: entitlement defined by either or both the provider and consumer).
As per claim 21, Juarez as modified discloses the system of claim 1. Juarez further discloses wherein the plurality of software domain resources shared via the first client device are associated with information related to a transaction modeled in relation to the first device, and wherein the modeled transaction is for one or more transactions between a consumer related to the first device and a service provider related to the second device (Juarez: [0015]-[0016]: customizable collaboration interface related to specific transaction offered by service provider).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIN HON (ERIC) CHEN whose telephone number is (571)272-3789. The examiner can normally be reached Monday to Thursday 9am- 7pm.
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, Lynn Feild can be reached at 571-272-2092. 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.
/SHIN-HON (ERIC) CHEN/Primary Examiner, Art Unit 2431
Prosecution Insights