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 .
Response to Remarks/Arguments
This Office Action is in response to the communications for the present US application number 18/526,417 last filed on December 11th, 2025.
Claims 1, 14, 18, and 20 were amended.
Claims 1-20 remain pending and have been examined, directed to TECHNIQUES FOR SIMPLIFYING IDENTITY MANAGEMENT IMPLEMENTATIONS RELATED TO APPLICATION SUBSCRIPTION MANAGEMENT.
Upon further review of the last interview summary and the latest claim amendments along with the applicant’s representative’s response, the examiner updated the searching and remains unpersuaded at this time.
With respect to the 35 U.S.C. § 103 rejection, using Bhattacharjee, and using amended independent claim 1 for discussion purposes, the applicant’s representative primarily argued about the amended features directed to clarifying that the features and selections with the various plans and entitlements have prices and costs.
In response, the Examiner performed some updated searching and found some additional references to consider and present with the following new combination of references to consider. A new secondary reference was relied upon that more expressly discloses of the associated pricing and plans that go along with any features and/or subscriptions that are offered. This would also address and reinforce the other concept that was argued with respect to clearly allowing or denying of services, depending on the selections. For at least these reasons, the Examiner remains unpersuaded at this time.
The other independent claims 18 and 20 were similarly amended and argued following claim 1 and thus was similarly rejected under the same rationale.
The previous 35 U.S.C. § 112 (b) issue directed to claim 14 as the representative pointed out has been withdrawn in view of the latest amendment.
The remaining dependent claims were not specifically argued at this time.
Applicant’s arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 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-5, 10-14, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. US 2023/0421469 A1 to Bhattacharjee, Kaushik (referred to hereafter as “Bhattacharjee”) and further in view of US 2015/0006731 A1 to Ren et al. (referred to hereafter as “Ren”).
As to claim 1, Bhattacharjee further discloses a method, comprising:
receiving, by an identity management system that is a first subsystem of a data management system, data corresponding to a subscription schema for a version of an application of a plurality of versions of the application associated with the data management system, the subscription schema comprising a plurality of feature sets for a plurality of plans of the version of the application, wherein each plan of the plurality of plans corresponds to a respective plan price, and wherein different application features are included in individual feature sets of the plurality of feature sets in accordance with the respective plan prices (Bhattacharjee discloses of an overall system formed from distributed subsystems that can handle and configure various users and their devices connecting to a system for various needs via subscriptions, that further includes various features. A subsystem, out of the whole system, like a frontend processing component (3100), would be receiving a user’s request for some subscription service and go through the process of establishing that connection and/or session, while working with other subsystems like a backend subsystem section (3200). Each data associated with each request for one or more subscription(s), via the application (3510 for example) can also be tracked as a version, (e.g., Bhattacharjee: Figs. 1 and 3-5 and related ¶¶ 38-45).
Furthermore, Bhattacharjee does not expressly disclose of pricing and costs associated with the each of the selections of any subscriptions and/or services.
Ren more expressly discloses of a system that also deals with subscriptions and entitlements and associated pricing/costs for various different features, depending on the user’s selected plan, subscription, and entitlements (e.g., Ren: ¶¶ 16, 31-32, 55, and 58-60).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the present application, to combine and incorporate Ren’s teachings because this would be beneficial and informative towards how a user makes their selections);
configuring, by the identity management system, an integration between the application and a transaction processing and subscription management platform connected to the data management system (The overall system can configure and/or handle the entire process of establishing one or more users’ subscription request(s), via their app, which is interpreted as another way of saying an “integration” between the user/app (as a source) and their requested subscription (as a target/destination), e.g., Bhattacharjee: Figs. 1, 3, and 7 and ¶¶ 42-45 and 51-54);
configuring, by the identity management system, one or more pipelines for the application in accordance with one or more parameters associated with the subscription schema for the version of the application (The overall system can establish a connection (or “pipeline”) to obtain/pull the (real-time) data/resources from wherever the “source(s)” are, depending on the subscription, which can also further be cached for future uses, e.g., Bhattacharjee: Figs. 3 and 7 and ¶¶ 25, 42-46, and 51-54);
generating, by the identity management system, an entitlement setup for the version of the application based at least in part on the plurality of feature sets for the plurality of plans of the version of the application, wherein the entitlement setup defines which users or organizations are authorized to access one or more application features of a respective plan of the plurality of plans of the application based at least in part on a plan price of the respective plan, the entitlement setup being for an entitlement management system that is a second subsystem of the data management system and integrated with the identity management system (The overall system has a subsystem managing or management component that can handle what each user/account is entitled to or approved for, depending on the (subscription) request. The management subsystem can be implemented in various ways, physically/locally (e.g., 1700) or logically/remote/cloud-based (e.g., 1200 or 2340 or 3500), (e.g., Bhattacharjee: ¶¶ 31-32, 39-40, and 46-47).
Furthermore, with respect to the entitlements, which Bhattacharjee discloses of with respect to user profiles and what features are available, while a user can make their various selections (e.g., Bhattacharjee: ¶¶ 39-40), Bhattacharjee does not expressly disclose of pricing and costs associated with each of those selections.
Once again, Ren more expressly discloses of a system that also deals with subscriptions and entitlements and associated pricing/costs for various different features, depending on the user’s selected plan, subscription, and entitlements (e.g., Ren: ¶¶ 16, 31-32, 55, and 58-60).
As a result of Ren’s incorporated teachings, there pricing information can be incorporate and presented within Bhattacharjee’s system and thus be more informative for users.
See the similarly stated reasons for combining and incorporating Ren’s teachings within Bhattacharjee’s overall system);
receiving, by the identity management system, data associated with a request to create, update, or remove a subscription plan for an account associated with a user or an organization via the one or more pipelines for the application (The system can receive request(s) and react accordingly in handling those changes, e.g., Bhattacharjee: ¶¶ 34 and 40); and
authorizing or denying, via the entitlement management system, the request based at least in part on the entitlement setup for the version of the application and on whether a feature set of the subscription plan of the account corresponds to a plan of the plurality of plans (Bhattacharjee does not explicitly use the terms authorize or deny, regarding the requests, but it would still have been obvious to one of ordinary skill in the art, before the effective filing date, that the concept is still taught or suggested, because the overall system are responding accordingly, with the managing subsystems working together with all the rest of the distributed subsystem components to either approve and establish the subscription requests or deny and choose not to establish those subscription requests and API calls, etc., all depending on the specifics/features selected within each individual request(s) themselves, (e.g., Bhattacharjee: ¶¶ 38-47).
To further reinforce and supplement this concept, Ren more expressly and explicitly discloses of allowing or preventing a user’s request for access to contents, based upon their entitlements and subscription plans (e.g., Ren: ¶¶ 29, 31, 40, 43, 46, 52, and 55).
See the similarly stated reasons for combining and incorporating Ren’s teachings within Bhattacharjee’s overall system).
As to claim 2, Bhattacharjee further discloses the method of claim 1, further comprising:
receiving, by the identity management system, an input associated with enabling a first plan of the version of the application from the plurality of plans of the version of the application, wherein the input enables the subscription plan for the account associated with the user to be the first plan of the version of the application (Following claim 1, the system will respond accordingly to any received inputs or changes to a user’s subscription request, and the subscription with the user selected features within a “plan” would be “enabled” or allowed, based on the determination from the management subsystem when the request is approved/allowed or denied, e.g., Bhattacharjee: ¶¶ 38-47); and
updating, via the entitlement management system, the entitlement setup based at least in part on the input (Similar to what was established in claim 1, the system can respond and update any detected changes accordingly, e.g., Bhattacharjee: ¶¶ 34, and 38-47).
As to claim 3, Bhattacharjee further discloses the method of claim 2, further comprising:
receiving, by the identity management system via the integration between the identity management system and the transaction processing and subscription management platform, an indication of a change to the subscription plan for the account associated with the user or the organization from a first plan of the version of the application to a second plan of the version of the application from the plurality of plans of the version of the application (Following claims 1 and 2, the system with all the subsystems integrated and working together, the overall system can receive user selections or changes to any of their subscription requests, and the system would be responding accordingly. Each change or update can also be tracked separately and be treated as different versions, e.g., Bhattacharjee: ¶¶ 33 and 38-47); and
updating, via the entitlement management system, the entitlement setup based at least in part on the change of the subscription plan for the account associated with the user or the organization from the first plan of the version of the application to the second plan of the version of the application (Similar to what was previously established in claims 1 and 2, the system can respond and update any detected changes accordingly, e.g., Bhattacharjee: ¶¶ 34 and 38-47).
As to claim 4, Bhattacharjee further discloses the method of claim 1, further comprising:
receiving, from the application, data associated with a request, from the user associated with the account, to make use of an application feature of a feature set of the subscription plan of the account associated with the user, wherein the data associated with the request is received by the identity management system of the data management system or the entitlement management system of the data management system (Following claim 1, the system can receive (subscription) requests regarding some data, which would inevitably also mean, the request is tied to the user’s selected features within their app(lication), e.g., Bhattacharjee: Fig. 3 and ¶¶ 38-47);
determining, via the entitlement management system, that the application feature of the feature set of the subscription plan of the account for the version of the application satisfies a threshold (Following claim 1, the management subsystem(s) can determine whether to allow or deny the request in accordance with the user’s account profile, where the “threshold” can be interpreted as an varying internal variable or a simple yes/no decision based upon the user’s account credentials, e.g., Bhattacharjee: ¶¶ 31-32, 39-40, and 46-47); and
transmitting, to the application, an indication, from the identity management system, that the threshold of the application feature of the feature set of the subscription plan is satisfied, the indication comprising one or more options associated with changing the subscription plan of the account associated with the user to a different plan of the plurality of plans of the version of the application based at least in part on the threshold being satisfied (Following claim 1, any “indication” can be interpreted as something internal with a yes/no decision tree, between subsystems, or whatever the result of the management’s decision, that result gets displayed or presented back to the user, like notifications, with regards to any received/detected requests for changes to features and/or subscriptions, e.g., Bhattacharjee: ¶¶ 34 and 38-48).
As to claim 5, Bhattacharjee further discloses the method of claim 4, further comprising:
receiving, by the identity management system from the application, the data associated with the request (Following claims 1 and 4, the system will receive the user’s request for some subscription, via their app(plication) interface, e.g., Bhattacharjee: Fig. 3); and
transmitting, from the identity management system to the entitlement management system, the data associated with the request, wherein the entitlement management system determining that the application feature of the feature set of the subscription plan of the account for the version of the application satisfies the threshold is based at least in part on the entitlement management system receiving the data associated with the request (Similar to what was established in claim 1, the management subsystem component(s) would receive the data/request and further determine what’s allowed or not, depending on the user’s profile and their selected features within the request, e.g., Bhattacharjee: ¶¶ 38-47).
As to claim 10, Bhattacharjee further discloses the method of claim 1, wherein configuring the one or more pipelines for the application comprises:
receiving, by the identity management system, a first input associated with one or more parameters that control which plans of the plurality of plans of the version of the application are available by users to subscribe to as part of a signup pipeline, wherein the one or more pipelines includes the signup pipeline (Following claim 1, the system can receive the user’s selections for their “plan” or features as part of a subscription request, e.g., Bhattacharjee: Fig. 3 and ¶¶ 38-47).
As to claim 11, Bhattacharjee further discloses the method of claim 10, wherein configuring the one or more pipelines for the application comprises:
receiving, by the identity management system, a second input, from the user associated with the account, requesting to subscribe to a first plan of the plurality of plans of the version of the application as the subscription plan of the account in accordance with the signup pipeline, wherein authorizing or denying the request, via the entitlement management system, is based at least in part on the second input that assigns the first plan of the version of the application to the account (Following claims 1 and 10, this is interpreted and treated in the same way as the system receiving any request, and any changes or selections would be treated in a similar fashion, by checking with the management subsystems to see what’s allowed or not for this user’s account, e.g., Bhattacharjee: ¶¶ 38-47).
As to claim 12, Bhattacharjee further discloses the method of claim 10, wherein the one or more pipelines for the application comprise assigning, by the identity management system, a first plan of the plurality of plans of the version of the application as the subscription plan of the account associated with the user in accordance with the one or more pipelines, wherein authorizing or denying, via the entitlement management system, the request is based at least in part on the first plan being assigned as the subscription plan of the account (Following claims 1 and 10, the system is simply processing the request and approving/denying the “first plan,” which can contain various features, within the user’s subscription request, e.g., Bhattacharjee: Fig. 3 and ¶¶ 38-47).
As to claim 13, Bhattacharjee further discloses the method of claim 1, wherein the transaction processing and subscription management platform is selected from a plurality of transaction processing and subscription management platforms that are associated with the identity management system of the data management system (Following claim 1, there were several options in terms of the management subsystems, mentioned in claim 1, e.g., Bhattacharjee: ¶¶ 31-32, 39-40, and 46-47).
As to claim 14, Bhattacharjee further discloses the method of claim 1, wherein a respective feature set for a respective plan of the version of the application includes one or more features associated with a quantitative value, one or more features associated with a quantitative value and a corresponding threshold quantity of feature accesses of the quantitative value, one or more features associated with a quantitative value and a corresponding period of time for the quantitative value, one or more features associated with a quantitative value and both a corresponding threshold quantity of feature accesses of the quantitative value and a corresponding period of time for the quantitative value, or any combination thereof (Following claim 1, and given the limitation scope of “any combination thereof” here, Bhattacharjee’s system can work with handling real time subscription requests, which means dynamic data (vs outdated stale/static data) along with a time period associated with that real time live data, e.g., Bhattacharjee: ¶¶ 38-46).
As to claim 16, Bhattacharjee further discloses the method of claim 1, wherein the entitlement setup generated by the identity management system defines which users or organizations are authorized to access one or more features of a respective plan of the plurality of plans of the version of the application (Following claim 1, the entitlement is interpreted as what’s allowed per user, which is handled by the management subsystem(s), e.g., Bhattacharjee: ¶¶ 31-32, 39-40, and 46-47).
As to claim 17, Bhattacharjee further discloses the method of claim 1, wherein at least one of the plurality of feature sets comprises one or more authentication features supported by the identity management system of the data management system (Following claim 1, the system can make the determination, depending on the user’s selection of feature(s) within their (subscription) requests, e.g., Bhattacharjee: Fig. 3 and ¶¶ 38-47).
As to claim 18, see the similar corresponding rejection of claim 1.
As to claim 19, see the similar corresponding rejection of claim 2.
As to claim 20, see the similar corresponding rejection of claim 1.
Claims 6-9 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. US 2023/0421469 A1 to Bhattacharjee and in view of US 2015/0006731 A1 to Ren and further in view of U.S. Patent Publication No. US 2019/0098055 A1 to Pitre et al. (referred to hereafter as “Pitre”).
As to claim 6, Bhattacharjee further discloses the method of claim 1, further comprising:
receiving, by the identity management system, data associated with a request, from the user associated with the account, to use a feature set of the subscription plan of the account associated with the user (Following claim 1, the system would receive the user’s (subscription) request along with their selection of features, e.g., Fig. 3 and Bhattacharjee: ¶¶ 38-43);
determining, via the entitlement management system, that the feature set of the subscription plan of the account is unsupported based at least in part on the entitlement setup; and transmitting, to the application, an indication, from the identity management system that the feature set is unsupported by the subscription plan of the account (While Bhattacharjee’s system provides a selection of features to choose from, Bhattacharjee however does not expressly disclose of any features that are unsupported. It would have been obvious to one of ordinary skill in the art, before the effective filing date of the present application, that depending on the implementation of the input interface, whatever features are presented to the user as available would be considered what’s supported by the system. This can be a selection process from a group or set of available features, versus a blank input or search tool to allow for whatever the user enters as a feature choice.
To support this obvious feature/concept, Pitre more expressly discloses in one embodiment about what’s available in policy types, which is interpreted as similar to the concept of users having some choice in their selections (e.g., Pitre: ¶ 235).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the present application, to combine and incorporate Pitre’s teachings of policy/feature selections altogether within Bhattacharjee’s overall system and teachings, because this adds to the level of flexibility and enhances overall user experiences within the system).
As to claim 7, Bhattacharjee further discloses the method of claim 1, further comprising:
obtaining, from the identity management system, a token that comprises one or more data items, the one or more data items including a subscription plan identifier associated with the account, wherein authorizing or denying, via the entitlement management system, the request is based at least in part on at least one of the one or more data items of the token (Bhattacharjee does not expressly disclose of using tokens as an intermediary state between subsystems.
Pitre more expressly discloses within an embodiment of the use and implementations of tokens, used to represent a form of security provided with respect to the services, e.g., Pitre: ¶¶ 38, 53-54, and 82-83).
See the previously stated reasons for combining and incorporating Pitre’s teachings into Bhattacharjee’s overall system and teachings).
As to claim 8, Bhattacharjee further discloses the method of claim 1, further comprising:
transmitting, via the identity management system and to the transaction processing and subscription management platform, an indication of a quantity of users associated with a billable seat for the subscription plan of the version of the application (Bhattacharjee does not expressly disclose of the system checking on the number of users with respect to billing practice.
Pitre more expressly discloses within an embodiment of tracking and defining user groups within an organization, where user groups can further define the number of users, and that can be tied to a billing system (e.g., Pitre: ¶ 186).
See the previously stated reasons for combining and incorporating Pitre’s teachings into Bhattacharjee’s overall system and teachings).
As to claim 9, Bhattacharjee further discloses the method of claim 1, wherein receiving the data corresponding to the subscription schema comprises:
importing the data corresponding to the subscription schema for the version of the application, the data comprising the plurality of feature sets for the plurality of plans of the version of the application, wherein the identity management system imports the data corresponding to the subscription schema for the version of the application from an external service connected to the data management system (Bhattacharjee does not expressly disclose of importing data into the overall system.
Pitre more expressly discloses within an embodiment of the ability and functionality of importing data into the overall system (e.g., Pitre: ¶ 22), which when incorporated within Bhattacharjee’s system would allow for more flexibility and ease of user’s experiences.
See the previously stated reasons for combining and incorporating Pitre’s teachings into Bhattacharjee’s overall system and teachings).
As to claim 15, Bhattacharjee further discloses the method of claim 1, wherein a respective feature set for a respective plan of the version of the application includes one or more features with a Boolean value indicating whether a respective feature is configured within the respective feature set of the respective plan of the version of the application (Bhattacharjee does not expressly disclose of using Boolean values to indicate different in features/applications.
Pitre more expressly discloses of this concept within an embodiment wherein Boolean value(s) can be used within the context to represent data with respect to policies (e.g., Pitre: ¶¶ 221, 227, and 242-243).
See the previously stated reasons for combining and incorporating Pitre’s teachings into Bhattacharjee’s overall system and teachings).
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 Xiang Yu whose telephone number is (571)270-5695. The examiner can normally be reached M-F 9:30-3:00 (PST/PDT).
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, Emmanuel Moise can be reached at (571)272-3865. 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.
/X.Y./Examiner, Art Unit 2455
/DAVID R LAZARO/Primary Examiner, Art Unit 2455
Prosecution Insights