Detailed Action
This office action is in response to applicant’s submission filed on October 2, 2025. Claims 6 and 19 are canceled. Claims 21-22 are new. Claims 1-5, 7-18, and 20-22 are pending and rejected.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on October 2, 2025 has been considered. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, an initialed and dated copy of Applicant’s IDS form 1449 is attached to the instant Office action.
Response to Amendment
This communication is in response to the amendment filed on October 2, 2025. The Examiner has acknowledged the amended claims 1-5, 7-8, 10-18, and 20. Claims 6 and 19 are canceled. Claims 21-22 are new. Claims 1-5, 7-18, and 20-22 are pending and rejected.
Response to Arguments
Applicant’s Arguments (Remarks) filed October 2, 2025 have been fully considered, but are not persuasive. Note that this action is made FINAL. See MPEP § 706.07(a).
Applicant argues that the amended features are not being taught by the prior art. Examiner respectfully disagrees. The amendments consisted of adding a third party application or an API call, however the prior art already read upon the previous claims with these features and adding a plurality of third party applications or API calls do not add novelty to the claim language as there can always be more than one/multiple. The rest of the amendments were simply rewritten from the former claims, therefore have been rejected based off of the rationale as previously applied. See also 102 rejection below.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-5, 7-18, and 20-22 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 2017/0359345 A1 to Gangadharan et al. (hereinafter, “Gangadharan”).
Regarding claim 1, Gangadharan discloses: A computer-implemented method for managing digital entitlements, the method comprising:
generating a digital backpackthat is associated with an application program interface (API) (“The entitlement delegation system 12 can include an API that manages the creation and upkeep of data about billing accounts, subscriptions to services, and features of services” [0077] [Examiner notes that the entitlement delegation system 12 is seen as the digital backpack as it acts as a silo to create, upkeep, and store digital entitlements]);
storing, in response to a first API call of the API, at least one digital entitlement in the digital backpack (“The entitlement delegation system 12 can include an API that manages the creation and upkeep of data about billing accounts, subscriptions to services, and features of services” [0077] [Examiner notes that the system (backpack) has an API, therefore it can receive an API call)],
wherein the at least one digital entitlement originates from a first third party application;determining a third party platform; generating a second API call of the API , associated with the at least one digital entitlement, that is directed to a second third party application, different from the first third party application, of the third party platform (“User B is now able to view the newly added service 16 via the app UI, at step 258, e.g., via the app 22 or a browser 102. In this example, User B requests access to that service at step 260, via the app UI, e.g., by selecting an icon, option, or other input mechanism. After making this request, the entitlement delegation system 12 authorizes the request at step 262, by checking the associations and obtaining the appropriate authorization data for User A's account 136. The authorization data may then be used at step 264 to request access to the service 16 at the service itself at step 264. The service provider would use the authorization data to authorize the request at step 266, and provide the service at step 268 to User B, via the entitlement delegation system 12 or a redirection coordinated thereby. This enables User B to use the service via the app 22 at step 270. User B is now able to query the APIs of the service using the authorization granted by the service provider to User A. While the service itself remains blind to User B, the entitlement delegation system captures the distinction between User A and User B consuming the service” [0106] [Examiner notes that this text shows a digital entitlement flow where user B accesses a third-party service via API using delegated rights from User A. The service is a third-party and remains blind to User B, highlighting the intermediary entitlement delegation system's role. Examiner notes that there can be more than one third party service, so a second one does not add novelty to the claim]);
providing, based on the second API call, the second third party application read access to the at least one digital entitlement (“This module 60 provides APIs and application functions for full create-read-update-delete (CRUD) functions to manage credentialed digital users and their entitlements” [0071] [Examiner notes that since entitlements in the backpack can be from a third party, the read function can be used); and
receiving, based on the second API call, one or more additional digital entitlements at the digital backpack (“The entitlement delegation system 12 can include an API that manages the creation and upkeep of data about billing accounts, subscriptions to services, and features of services” [0077] [Examiner notes that the system (backpack) has an API, therefore it can receive an API call in order to receive an entitlement)],
wherein: the one or more additional digital entitlements originate from the second third party application, and the one or more additional digital entitlements are stored in the digital backpack such that the one or more additional digital entitlements are accessible by the first third party application via one or more API calls of the API (“It is recognized that companies that provide online services aim to create digital relationships with their users. This can result in one user having many digital identities. It can also result in a service being entitled to only one digital user. The current siloed nature of service providers makes this multi-identity experience a reality for the digital user, which has led to the need for user identity reconsolidation. The lack of flexibility in subscriber account IT systems being able to delegate services to secondary users is also a reality for the digital user. The system described below operates to unify this fragmented experience for users, by enabling seamless access to core services (along with a multitude of third-party cloud services). Unifying services in this way includes orchestrating access to a number of end points (via a number of protocols). It also includes effectively delegating shared and personal services to individual users. This allows each household member to have secure and personalized access on any device, and to share access without sharing credentials, including passwords. This federation is thus made a user-centric reality within the context of a pre-existing subscriber account relationship with a digital service provider. In addition, the multiservice gateway described herein permits the flexible registration, federation and delegation of any service against an individual user of the system, which permits unified access to any number of cloud or service provider core services” [0051] [Examiner notes that this text supports secondary entitlements, third-party acquisition, and their determination/management within a federated, user-centric system]).
Regarding claim 2, Gangadharan discloses: wherein the first API call comprises an attribute of the at least one digital entitlement (“The service entitlement can include various attributes, such as a user role 126, restrictions on runtime 134, feature-level permissions, etc. Based on these attributes, the entitlement delegation system 12 updates the corresponding associations 70 at step 254” [0105] [Examiner notes that these attributes are used before finalizing the request of the API call]).
Regarding claim 3, Gangadharan discloses: wherein the first API call corresponds to read access to the digital backpack (“This module 60 provides APIs and application functions for full create-read-update-delete (CRUD) functions to manage credentialed digital users and their entitlements” [0071]).
Regarding claim 4, Gangadharan discloses: determining the one or more additional digital entitlements that originate from the second third party application It is recognized that companies that provide online services aim to create digital relationships with their users. This can result in one user having many digital identities. It can also result in a service being entitled to only one digital user. The current siloed nature of service providers makes this multi-identity experience a reality for the digital user, which has led to the need for user identity reconsolidation. The lack of flexibility in subscriber account IT systems being able to delegate services to secondary users is also a reality for the digital user. The system described below operates to unify this fragmented experience for users, by enabling seamless access to core services (along with a multitude of third-party cloud services). Unifying services in this way includes orchestrating access to a number of end points (via a number of protocols). It also includes effectively delegating shared and personal services to individual users. This allows each household member to have secure and personalized access on any device, and to share access without sharing credentials, including passwords. This federation is thus made a user-centric reality within the context of a pre-existing subscriber account relationship with a digital service provider. In addition, the multiservice gateway described herein permits the flexible registration, federation and delegation of any service against an individual user of the system, which permits unified access to any number of cloud or service provider core services” [0051] [Examiner notes that this text supports secondary entitlements, third-party acquisition, and their determination/management within a federated, user-centric system]).
Regarding claim 5, Gangadharan discloses: verifying at least one permission associated with the one or more additional digital entitlements The service entitlement can include various attributes, such as a user role 126, restrictions on runtime 134, feature-level permissions, etc. Based on these attributes, the entitlement delegation system 12 updates the corresponding associations 70 at step 254” [0105]; “At this step, the system 12 can determine that User B does have a service-level permission, but has at least one feature-level restriction. Accordingly, the system 12 uses the authorization data for User A to request access to the service 16 at step 318, which is authorized by the service provider at step 320” [0108]).
Regarding claim 7, Gangadharan discloses: wherein the second API call or a third API call of the API permits the second third party application write access to the digital backpack (“This module 60 provides APIs and application functions for full create-read-update-delete (CRUD) functions to manage credentialed digital users and their entitlements” [0071]).
Regarding claim 8, Gangadharan discloses: a third API call is limited to a specified the at least digital entitlement and the one or more additional digital entitlements Users and groups module 60 can also include a comprehensive set of group management functions. These functions allow entities such as users, accounts, subscriptions, and devices 18 to be organized into groups. This provides the ability to set common preferences and attributes for a group while simultaneously maintaining individual metadata for each entity. The grouping of entities is accomplished through associations as will be explained in greater detail below. This enables entities to be part of multiple groups. For example, user John Smith could be the Primary User of the ‘Smith Home’ household group, while being a sub-user in an ‘Office’ business group. That user would be able to use his TV subscription as a member of the household group and use his VoIP phone as part of the office business group. Group management for users overlays the concept of roles (primary user, administrator, sub-user etc.) into the association to allow for household and account hierarchies. Groups can also be treated as a single entity for performing various operations, such as notifications” [0073] [Examiner notes that this text shows all types of digital entitlements or entities tied to entitlements. Grouping them supports managing them in subsets. Setting common preferences and attributes explicitly defines fine-grained control over which entities are affects by a command or configuration – consistent with selecting a subset via API. Overall, this text supports that role-based or contextual filtering is a form of subset targeting and this system can perform an operation (API call) on just a group (subset of all of the digital entitlements)]).
Regarding claim 9, Gangadharan discloses: displaying a user interface comprising attributes associated with the digital backpack (“FIGS. 17(a) to 17(e) illustrate a workflow that can be used in adding a new service 16. FIG. 17(a) illustrates a dashboard UI 800 for a user, in which one or more available services (i.e. those that are established with the multi-service gateway 14) are “greyed out” to provide a visual indication that the service 16 can be added. In this case a Lyric service icon 802 is being viewed. By selecting the icon 802 as shown in FIG. 17(a) (or by selecting another option), an add service dialog 812 is displayed as shown in FIG. 17(b). The user can select an Add option 814 to have that service 16 added to their account. FIG. 17(c) illustrates an example of a registration UI 820 for that service 16, which can provide user terms and conditions, can request user credentials to obtain, for example, authorization data such as a token 152. As such, it can be appreciated that the UI 820 shown in FIG. 17(c) is only illustrative of one or more screens/Uls that would be presented to the user in order to obtain the necessary permissions and credentials to integrate the selected service 16 with the user, within the platform 10. By adding multiple services 16 in this way, the dashboard 800 provides a single portal into various services 16 that can not only be accessed, but for which entitlements can be delegated within a household or other organization” [0116]).
Regarding claim 10, Gangadharan discloses: wherein the digital backpack further comprises a user interface for managing and organizing the at least digital entitlement and the one or more additional digital entitlements FIGS. 17(a) to 17(e) illustrate a workflow that can be used in adding a new service 16. FIG. 17(a) illustrates a dashboard UI 800 for a user, in which one or more available services (i.e. those that are established with the multi-service gateway 14) are “greyed out” to provide a visual indication that the service 16 can be added. In this case a Lyric service icon 802 is being viewed. By selecting the icon 802 as shown in FIG. 17(a) (or by selecting another option), an add service dialog 812 is displayed as shown in FIG. 17(b). The user can select an Add option 814 to have that service 16 added to their account. FIG. 17(c) illustrates an example of a registration UI 820 for that service 16, which can provide user terms and conditions, can request user credentials to obtain, for example, authorization data such as a token 152. As such, it can be appreciated that the UI 820 shown in FIG. 17(c) is only illustrative of one or more screens/Uls that would be presented to the user in order to obtain the necessary permissions and credentials to integrate the selected service 16 with the user, within the platform 10. By adding multiple services 16 in this way, the dashboard 800 provides a single portal into various services 16 that can not only be accessed, but for which entitlements can be delegated within a household or other organization” [0116]).
Claim 11 recites substantially the same limitation as claim 1, in the form of a system for implementing the corresponding method, therefore it is rejected under the same rationale. Examiner wants to note that the one or more hardware processors and memory storing instructions are disclosed in “It will also be appreciated that any module or component exemplified herein that executes instructions may include or otherwise have access to computer readable media such as storage media, computer storage media, or data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape” [0126].
Regarding claim 12, Gangadharan discloses: wherein the first API call includes authentication information to verify the user’s access to the at least one digital entitlement (“A primary identifier of a user can be held by the entitlement delegation system 12, in an internal data store. In a typical deployment, the system 12 also stores the login credentials of the user and can provide a username and password based authentication. Service providers may configure password encryption from a variety of available hash methods. Third-party authentication via LDAP, SAML and OpenID can also be provided, depending on the specific deployment of the platform. Authentication via various third party platforms, such as social media (e.g., Facebook, Twitter, Google+, etc.) can also be included. Once authenticated, the information related to the user's profile, as well as various services and features associated with the user, can be fetched via a system API” [0079]).
Regarding claim 13, Gangadharan discloses: wherein the digital backpack is encrypted to secure the at least one digital entitlement and the one or more additional digital entitlements A primary identifier of a user can be held by the entitlement delegation system 12, in an internal data store. In a typical deployment, the system 12 also stores the login credentials of the user and can provide a username and password based authentication. Service providers may configure password encryption from a variety of available hash methods. Third-party authentication via LDAP, SAML and OpenID can also be provided, depending on the specific deployment of the platform. Authentication via various third party platforms, such as social media (e.g., Facebook, Twitter, Google+, etc.) can also be included. Once authenticated, the information related to the user's profile, as well as various services and features associated with the user, can be fetched via a system API” [0079] [Examiner notes that the system is encrypted to some extent to ensure security and privacy of the digital entitlements. Given the encryption of entitlement data and the system's use of secure authentication protocols, it's reasonable to interpret that encryption is part of the general data protection approach used by the entitlement delegation system]).
Regarding claim 14, Gangadharan discloses: receive a request from the user to transfer the at least one digital entitlement to another user or platform (“User B is now able to view the newly added service 16 via the app UI, at step 258, e.g., via the app 22 or a browser 102. In this example, User B requests access to that service at step 260, via the app UI, e.g., by selecting an icon, option, or other input mechanism. After making this request, the entitlement delegation system 12 authorizes the request at step 262, by checking the associations and obtaining the appropriate authorization data for User A's account 136. The authorization data may then be used at step 264 to request access to the service 16 at the service itself at step 264. The service provider would use the authorization data to authorize the request at step 266, and provide the service at step 268 to User B, via the entitlement delegation system 12 or a redirection coordinated thereby. This enables User B to use the service via the app 22 at step 270. User B is now able to query the APIs of the service using the authorization granted by the service provider to User A. While the service itself remains blind to User B, the entitlement delegation system captures the distinction between User A and User B consuming the service” [0106]).
Regarding claim 15, Gangadharan discloses: wherein the digital backpack includes a history log that records the acquisition, usage, and transfer of the at least digital entitlement and the one or more additional digital entitlements Security, reporting and administration component 56 is encompasses components standard in enterprise-grade software platforms. Security assures the platform against unauthorized entry, as does it log and maintain a record of authorized use for audit purposes. Reporting provides a visual presentation of data gathered by the system, and administration provides operators of the platform to manage various elements of the overall Entitlement Delegation system” [0070]).
Regarding claim 16, Gangadharan discloses: wherein the digital backpack comprises a search functionality for searching its stored digital entitlements The multi-service gateway 14 in the configuration shown in FIG. 3 includes an operations UI 80, a service registry 82, a software development kit (SDK) 84, and a utilities module 86. The multi-service gateway 14 also includes one or more SAMs 90, each being associated with a service/account provider interface 92, both of which are associated with a corresponding system 96. The systems 96 correspond to the accounts, subscriptions, services, and features for which entitlement delegation is enabled using the platform 10. In the example shown in FIG. 3, are systems 96 for video, voice and messaging, home control, music systems, and cloud systems. The provider interfaces 92 enable the entitlement delegation system 12 to query APIs in systems 96 for users who have subscriber accounts in these systems and also via delegated users of these subscriber users. This allows delegated users to access services registered to other subscribed users without needed to know the subscribed user's credentials (e.g. usernames and passwords). In this way, user lifecycle management and service/feature delegation can be provided to systems 96 that do not have this capability. That is, current household or single-user based accounts and subscriptions can be left alone but augmented to provide additional functionality and granularity among the services 16 and features of those services 16” [0085] [Examiner notes that this system shows that the entitlement delegation system is actively querying third-party systems to retrieve data about digital entitlements (accounts, services, features). The querying is directed at locating specific users and their entitlements, both primary and secondary which shows the idea of locating specific digital entitlements. After locating the relevant digital entitlements, the system enables access (locating and accessing specific digital entitlements)]).
Regarding claim 17, Gangadharan discloses: generate a notification to the user when new digital entitlements are added to the backpack (“FIGS. 13(a) to 13(d) illustrate a series of screen shots illustrating a real-time user interface (UI) update and notification process upon detecting a change in service entitlements” [0024]; “Similarly, as illustrated in 13(d), the bi-directional messaging module 54 enables real-time notifications (e.g., text messages, email alerts, etc.) to be sent to User B such that a notification message 424 can be viewed in an application UI 422 at User B's device 18. It can be appreciated that either or both of the outcomes shown in FIGS. 13(c) and (d) can be implemented. Moreover, other notification modalities can be used and those shown herein are for illustrative purposes” [0111]).
Regarding claim 18, Gangadharan discloses: wherein a sharing functionality of the digital backpack permits the user to share selected digital entitlements with other users (“User B is now able to view the newly added service 16 via the app UI, at step 258, e.g., via the app 22 or a browser 102. In this example, User B requests access to that service at step 260, via the app UI, e.g., by selecting an icon, option, or other input mechanism. After making this request, the entitlement delegation system 12 authorizes the request at step 262, by checking the associations and obtaining the appropriate authorization data for User A's account 136. The authorization data may then be used at step 264 to request access to the service 16 at the service itself at step 264. The service provider would use the authorization data to authorize the request at step 266, and provide the service at step 268 to User B, via the entitlement delegation system 12 or a redirection coordinated thereby. This enables User B to use the service via the app 22 at step 270. User B is now able to query the APIs of the service using the authorization granted by the service provider to User A. While the service itself remains blind to User B, the entitlement delegation system captures the distinction between User A and User B consuming the service” [0106] [Examiner notes that this text clearly shows a digital entitlement (service access) originally granted to User A has been shared with User B]).
Claim 20 recites substantially the same limitation as claim 1, in the form of a computer readable medium comprising computer readable program code for implementing the corresponding method, therefore it is rejected under the same rationale.
Regarding claim 21, Gangadharan discloses: wherein: the second API call comprises authentication information, and the one or more additional digital entitlements are received at the digital backpack based on verification of the authentication information (“A primary identifier of a user can be held by the entitlement delegation system 12, in an internal data store. In a typical deployment, the system 12 also stores the login credentials of the user and can provide a username and password based authentication. Service providers may configure password encryption from a variety of available hash methods. Third-party authentication via LDAP, SAML and OpenID can also be provided, depending on the specific deployment of the platform. Authentication via various third party platforms, such as social media (e.g., Facebook, Twitter, Google+, etc.) can also be included. Once authenticated, the information related to the user's profile, as well as various services and features associated with the user, can be fetched via a system API” [0079]).
Regarding claim 22, Gangadharan discloses: wherein the at least one digital entitlement is an entitlement related to a non-fungible token managed on a blockchain (“A session-level token based authorization can also be provided to clients interacting via the APIs. This token would be valid for authenticating requests to other components of the platform 10, such as the multi-service gateway 14 and the SAMs 90 (see also FIG. 3 described below). The token would be used to contain the user information that is used to validate the authenticity of operations that a client system attempts to perform on the platform 10. Also, a business rule driven access control mechanism can be applied to various entities and operations. For example, a user associated only to Account A would not necessarily have access to the information related to Account B (or its associated entities). The security of data can be further enhanced by controlling the access to data and operations. This can be based on flags defined on an association between the user and the other entity. By utilizing the interceptor framework 50, operators can further enhance the authentication process by intercepting the authentication requests to inject additional business logic)” [0080] [Examiner notes that the token is acting as an NFT since the concept of token-based authorization mirrors natural with NFT-based entitlement. Rights are enforced when the system checks the token on the blockchain and the access control logic matches exactly how an NFT-backed entitlement would be validated and used in the system]).
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should
be directed to SARON MATTHEWOS WORKU whose telephone number is (703)756-1761. The
examiner can normally be reached Monday - Friday, 9:30am - 6:30pm.
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, Linglan Edwards can be reached on 571-270-5440. 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.
/SARON MATTHEWOS WORKU/Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408