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 .
DETAILED ACTION
This action is response to the remarks the applicant filed on 03/30/2026.
Claims 1-9 stand rejected, and are pending in this Office Action. Claim 1 is independent claim.
Response to Arguments
Applicant’s Remarks filed 03/30/2026 with respect to claims 1-20 and amended claim 1 have been respectfully and fully considered. Concerning the rejection based on double patenting, the Examiner respectfully submits that a withdraw is pending to a final scope of allowability of the application and further subject to the Applicant’s further instructions on terminal disclaimer.
With respect to the amended claim 1, a new ground set forth on new refences published to COLIN, TAN and Srinivasan seems being able to reasonably cover all the complex details of the subject matters recited in the claim.
Double Patenting
A rejection based on double patenting of the “same invention” type finds its support in the language of 35 U.S.C. 101 which states that “whoever invents or discovers any new and useful process... may obtain a patent therefor...” (Emphasis added). Thus, the term “same invention,” in this context, means an invention drawn to identical subject matter. See Miller v. Eagle Mfg. Co., 151 U.S. 186 (1894); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Ockert, 245 F.2d 467, 114 USPQ 330 (CCPA 1957).
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim 1-9 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-9 (claims 10-20 are included in below comparison table for reference) of U.S. Patent No. 12235820. Although the claims at issue are not identical, they are not patentably distinct from each other because they are substantially similar in scope and they use the same limitations. Especially, the U.S. Patent No. 12235820 discloses more details in logic assets with the application scenario. Therefore, it would have been obvious to one of ordinary skill in the art to realize that claims 1-9 of the instant application is fully disclosed by the U.S. Patent No. 12235820.
The following table shows the claims in Instant Application that are rejected by corresponding claim(s) in U.S. Patent No. 12235820.
Instant Application
U.S. Patent No. 12235820
1. A method, implemented by a computing device, for creating multi-tenant identifiers within a multi-tenant environment, the method comprising:
receiving, from a source system, a source system identifier,
wherein the source system identifier is a single-tenant identifier associated with the source system;
executing code by one or more processors of a computer system to cause the computer system to perform operations comprising:
determining a source identity provider of the source system;
wherein the source identity provider uniquely identifies a combination of the source system identifier and an identity provider used by the source system;
replacing the source system identifier with a multi-tenant identifier,
wherein replacing the source system identifier with the multi-tenant identifier includes
creating a multi-tenant identifier that replaces the source system identifier and that maps to a combination of the source system identifier and the source identity provider,
storing the created multi-tenant identifier in association with the combination of the source system identifier and the source identity provider in a data store of the multi-tenant environment; and
referencing the document by the multi-tenant identifier.
2. The method of claim 1, wherein the creating and storing are performed in response to determining that the combination of the source system identifier and the source identity provider is not present in the data store of the multi-tenant environment.
3. The method of claim 1,
wherein the source system identifier is a unique identifier used at the source system, and
wherein the source system identifier comprises a name and a value.
4. The method of claim 1, wherein the multi-tenant identifier does not comprise the source system identifier, and
wherein the multi-tenant identifier does not comprise the source identity provider.
5. The method of claim 1, wherein execution of the code by the one or more processors causes the computer system to perform further operations comprising:
associating the created multi-tenant identifier with data received from the source system.
6. The method of claim 1, wherein execution of the code by the one or more processors causes the computer system to perform further operations comprising:
receiving, from the source system, metadata describing an external content item stored at the source system,
wherein the source system identifier is associated with an element of the metadata; and
replacing a value of the source system identifier with the created multi-tenant identifier for identifying the element within the multi-tenant environment.
7. The method of claim 1, wherein the source identity provider uniquely identifies the source system and an identity provider used by the source system.
8. The method of claim 1,
wherein the created multi-tenant identifier is stored in a multi-tenant identifier mapping table, and
wherein entries in the multi-tenant identifier mapping table comprise:
a multi-tenant identifier field;
a source identity provider field;
a source system identifier name field; and a source system identifier value field.
9. The method of claim 1, wherein
execution of the code by the one or more processors causes the computer system to perform further operations comprising:
receiving source system identifiers from one or more other source systems; and
creating and storing multi-tenant identifiers from the source system identifiers from the one or more other source systems;
wherein the created multi-tenant identifiers are unique within the multi-tenant environment across the source system and the one or more other source systems.
1. A method, implemented by a computing device, for creating multi-tenant identifiers within a multi-tenant environment, the method comprising:
receiving, from a source system, a document having a source system identifier,
wherein the source system identifier is a single-tenant identifier associated with the source system, and the source system identifier identifies a data system storing the document;
determining a source identity provider of the source system,
wherein the source identity provider uniquely identifies a combination of the source system identifier and an identity provider used by the source system;
replacing the source system identifier with a multi-tenant identifier,
wherein the multitenant identifier is a unique identifier across multiple database systems and
replacing the source system identifier with the multi-tenant identifier includes
creating a multi-tenant identifier that maps to a combination of the source system identifier and the source identity provider;
storing the created multi-tenant identifier in association with the combination of the source system identifier and the source identity provider in a data store of the multi-tenant environment; and
referencing the document by the multi-tenant identifier.
2. The method of claim 1, wherein the creating and storing are performed in response to determining that the combination of the source system identifier and the source identity provider is not present in the data store of the multi-tenant environment.
3. The method of claim 1,
wherein the source system identifier is a unique identifier used at the source system, and
wherein the source system identifier comprises a name and a value.
4. The method of claim 1,
wherein the multi-tenant identifier does not comprise the source system identifier, and
wherein the multi-tenant identifier does not comprise the source identity provider.
5. The method of claim 1, further comprising:
associating the created multi-tenant identifier with data received from the source system.
6. The method of claim 1, further comprising:
receiving, from the source system, metadata describing an external content item stored at the source system,
wherein the source system identifier is associated with an element of the metadata; and
replacing a value of the source system identifier with the created multi-tenant identifier for identifying the element within the multi-tenant environment.
7. The method of claim 1, wherein the source identity provider uniquely identifies the source system and an identity provider used by the source system.
8. The method of claim 1,
wherein the created multi-tenant identifier is stored in a multi-tenant identifier mapping table, and
wherein entries in the multi-tenant identifier mapping table comprise:
a multi-tenant identifier field;
a source identity provider field;
a source system identifier name field; and
a source system identifier value field.
9. The method of claim 1, further comprising:
receiving source system identifiers from one or more other source systems; and
creating and storing multi-tenant identifiers from the source system identifiers from the one or more other source systems;
wherein the created multi-tenant identifiers are unique within the multi-tenant environment across the source system and the one or more other source systems.
10. A computing device operating within a multi-tenant environment, the computing device comprising:
a processing unit; and
memory;
the processing unit executing computer instructions performing operations for creating multi-tenant identifiers within the multi-tenant environment, the operations comprising:
receiving, from a source system, a document having a source system identifier,
wherein the source system identifier is a single-tenant identifier associated with the source system, and the source system identifier identifies a data system storing the document;
determining a source identity provider of the source system,
wherein the source identity provider uniquely identifies a combination of the source system identifier and an identity provider used by the source system;
replacing the source system identifier with a multi-tenant identifier,
wherein the multi-tenant identifier is a unique identifier across multiple database systems and replacing the source system identifier with the multi-tenant identifier includes
creating a multitenant identifier that maps to a combination of the source system identifier and the source identity provider;
storing the created multi-tenant identifier in association with the combination of the source system identifier and the source identity provider in a data store of the multi-tenant environment; and
referencing the document by the multi-tenant identifier.
11. The computing device of claim 10, wherein the creating and storing are performed in response to determining that the combination of the source system identifier and the source identity provider is not present in the data store of the multi-tenant environment.
12. The computing device of claim 10,
wherein the source system identifier is a unique identifier used at the source system, and
wherein the source system identifier comprises a name and a value.
13. The computing device of claim 10, the operations further comprising:
receiving, from the source system, metadata describing an external content item stored at the source system,
wherein the source system identifier is associated with an element of the metadata; and
replacing a value of the source system identifier with the created multi-tenant identifier for identifying the element within the multi-tenant environment.
14. The computing device of claim 10, wherein the source identity provider uniquely identifies the source system and an identity provider used by the source system.
15. The computing device of claim 10,
wherein the created multi-tenant identifier is stored in a multi-tenant identifier mapping table, and
wherein entries in the multitenant identifier mapping table comprise:
a multi-tenant identifier field;
a source identity provider field;
a source system identifier name field; and
a source system identifier value field.
16. A computer-readable storage medium storing computer executable instructions for causing a computing device to perform operations for using multitenant identifiers within a multi-tenant environment, the operations comprising:
receiving a request to lookup a document having a multi-tenant identifier,
wherein the document is from a source system having a source system identifier, associated with a source system, in a multi-tenant identifier mapping table, the source system identifier identifies a data system storing the document, and the multi-tenant identifier is a unique identifier across multiple database systems;
determining a source identity provider of the source system,
wherein the source identity provider uniquely identifies a combination of the source system identifier and an identity provider used by the source system;
identifying an entry in the multi-tenant identifier mapping table with the source system identifier and the source identity provider;
returning a multi-tenant identifier associated with the identified entry in the multi-tenant identifier mapping table,
wherein the multi-tenant identifier is unique within the multi-tenant environment; and
returning the document having the multi-tenant identifier.
17. The computer-readable storage medium of claim 16,
wherein the source system identifier is a unique identifier used at the source system, and
wherein the source system identifier comprises a name and a value.
18. The computer-readable storage medium of claim 16, the operations further comprising:
receiving, from the source system, metadata describing an external content item stored at the source system,
wherein the source system identifier is associated with an element of the metadata; and
replacing a value of the source system identifier with the returned multi-tenant identifier for identifying the element within the multi-tenant environment.
19. The computer-readable storage medium of claim 16, wherein the source identity provider uniquely identifies the source system and an identity provider used by the source system.
20. The computer-readable storage medium of claim 16, wherein the entries in the multi-tenant identifier mapping table comprise:
a multi-tenant identifier field;
a source identity provider field;
a source system identifier name field; and
a source system identifier value field.
“Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before.” See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U.S. Court of Customs and Patent Appeals.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness reject
ions 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.
In the event the determination of the status of the application as subject to 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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
For application naming joint inventors, in considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 6, 11-13 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over
COLIN, LARKIN: “ELECTRONIC TRANSACTION FRAUD PREVENTION” (WIPO Patent Application Publication WO 2010067342 A1, DATE PUBLISHED 2010-06-17; and DATE FILED 2009-12-10, hereafter “COLIN”), in view of
TAN et al.: “METHOD AND SYSTEM” (WIPO Patent Application Publication WO 2015121172 A1, DATE PUBLISHED 2015-08-20; and DATE FILED 2015-02-06, hereafter “TAN”) , and further in view of
Srinivasan et al.: “LDAP-BASED MULTI-TENANT IN-CLOUD IDENTITY MANAGEMENT SYSTEM” (United States Patent Application Publication 20140075501 A1, DATE PUBLISHED 2014-03-13; and DATE FILED 2013-09-05, hereafter “Srinivasan”).
(Remarks: All page numbers cited from the COLIN and TAN references are one higher than the actual numbers at the page top header)
As per claim 1, COLIN teaches a method for creating multi-tenant identifiers within a multi-tenant environment, the method comprising:
receiving, from a source system, a source system identifier (See Page 23, lines 17-18, When integrating an external system to the invention a parameter called "Source System ID" is set uniquely per system),
wherein the source system identifier is a single-tenant identifier associated with the source system (See Page 25, lines 21-22, The originating system ID is used by the Tenant to identify which of its systems originated the transaction (i.e. credit card or debit card system). Here the tenant used the unique system ID to identify a single system from the tenant’s plural systems that originated the transaction teaches the ID is the single ID associated with the system);
executing code by one or more processors of a computer system to cause the computer system to perform operations comprising (See Page 62, line 14-16, computer program product encoded on a computer - readable medium which, when processed by a data processing apparatus, adapts the apparatus to perform the method of preventing card fraud):
determining a source identity provider of the source system (Page 25, lines 21-22, The originating system ID is used by the Tenant to identify which of its systems originated the transaction (i.e. credit card or debit card system). Here the credit card or debit card reads on the source identity and the transaction teaches the source identity provider).
COLIN teaches identifying source system unique ID as previously described above.
However, COLIN does not explicitly teach wherein the source identity provider uniquely identifies a combination of the source system identifier and an identity provider used by the source system.
However, TAN teaches wherein the source identity provider uniquely identifies a combination of the source system identifier and an identity provider used by the source system (See Page 11, lines 1-2, Page 7, line 12 and Page 26, lines 8-9, the acquiring host system 20 could also allocate a unique transaction identifier to the transaction, host server system 20 where the identifier and the user details are recorded; and the transaction record in said storage identifying said at least one purchase in association with the token identifier and the merchant identifier).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of TAN with the teachings of COLIN because COLIN is dedicated to preventing electronic transaction fraud and TAN is dedicated to providing automatic determination of eligibility to receive a tax refund based on a payment card used by a user, and the combined teaching would have enabled COLIN to automatically detect potential fraud records to further process for system efficiency.
COLIN in view of TAN further teaches the following:
replacing the source system identifier with a multi-tenant identifier, wherein replacing the source system identifier with the multi-tenant identifier (See TAN: Page 11, lines 1-3, the acquiring host system 20 could also allocate a unique transaction identifier (e.g., a unique transaction number) to the transaction in order that a unique number is available within the system to track that transaction during processing. Here the unique transaction identifier (e.g., a unique transaction number) alone allocated by the host system without including source system identifier for the allocating reads on replacing the source system identifier with a multi-tenant identifier).
As described above, the COLIN in view of TAN reference interpreted the transaction identifier as a multi-tenant number that replaces the source system identifier, however, COLIN in view of TAN does not explicitly teach the replacing further includes creating a multi-tenant identifier.
On the other hand, Srinivasan teaches the replacing further includes creating a multi-tenant identifier (See [0072], an entity's multi-tenant unique identifier is generated for that entity in response to and at the time that a new record for that entity is created and added to the LDAP directory).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of TAN with the teachings of COLIN in view of TAN because COLIN is dedicated to preventing electronic transaction fraud, TAN is dedicated to providing automatic determination of eligibility to receive a tax refund based on a payment card used by a user and Srinivasan is dedicated to computer security, and more specifically to identity management within a cloud computing environment that is partitioned into various separate identity domains, and the combined teaching would have enabled COLIN in view of TAN to isolate each tenant by allowing each tenant interacting only with its dedicated partition in a multi-tenant system.
COLIN in view of TAN and further in view of Srinivasan further teaches the following:
maps to a combination of the source system identifier and the source identity provider (See TAN: Page 11, lines 1-3, Page 7, line 12 and Page 26, lines 8-9, the acquiring host system 20 could also allocate a unique transaction identifier to the transaction, host server system 20 where the identifier and the user details are recorded; and the transaction record in said storage identifying said at least one purchase in association with the token identifier and the merchant identifier and the acquiring host system 20 could also allocate a unique transaction identifier (e.g., a unique transaction number) to the transaction in order that a unique number is available within the system to track that transaction during processing. Here the allocating a source to a destination reads on a mapping between the source to the destination, a combination of the source system identifier and the source identity provider),
storing the created multi-tenant identifier in association with the combination of the source system identifier and the source identity provider in a data store of the multi-tenant environment (See Srinivasan: [0073], multi-tenant unique identifiers can be generated automatically for those log in names and stored within LDAP directory entries for the client's users.); and
referencing the document by the multi-tenant identifier (See TAN: Page 9, lines 10-11 and Page 7, line 8-9, manual entry of a passport number or other traveler identifier or by using a passport reader to read user details from a passport or other travel document, and manual entry of a passport number or other traveler identifier or by using a passport reader to read user details from a passport or other travel document; and verifying biometric information held on a machine readable user identifier (e.g., an ID document such as a passport)).
As per claim 2, COLIN in view of TAN and further in view of Srinivasan further teaches the method of claim 1, wherein the creating and storing are performed in response to determining that the combination of the source system identifier and the source identity provider is not present in the data store of the multi-tenant environment (See TAN: Page 8, lines 17-19, Application Currency Code (ACC) read from the card can be compared to Terminal Currency Code (TCC).stored in storage in the transaction terminal system to determine whether the currency represented by the ACC is the same as the currency associated with the transaction terminal system.).
As per claim 3, COLIN in view of TAN and further in view of Srinivasan teaches the method of claim 1,
wherein the source system identifier is a unique identifier used at the source system (See COLIN: Page 23, lines 17-20, When integrating an external system to the invention a parameter called "Source System ID" is set uniquely per system. When a card transaction is received the invention, the "Source System ID" will identify what external system the transaction originated from. For example, the system could be a credit card system, ATM system, Laser Card System, etc., and the "Source System ID" would be unique per system), and
wherein the source system identifier comprises a name and a value (See Srinivasan: [0034], the identity domain name can be a text value that represents a name of the identity domain as chosen by a customer who established the identity domain).
As per claim 4, COLIN in view of TAN and further in view of Srinivasan teaches the method of claim 1,
wherein the multi-tenant identifier does not comprise the source system identifier (See Srinivasan: [0072], the globally unique identifier can be called a multi-tenant unique identifier. In an embodiment, a particular user is always associated with the same multi-tenant unique identifier once his user account has been created, and that same multi-tenant unique identifier is used by the cloud environment's authentication system to authenticate the user every time that the user seeks access to a service within the environment.), and
wherein the multi-tenant identifier does not comprise the source identity provider (See Srinivasan: [0072], the globally unique identifier can be called a multi-tenant unique identifier. In an embodiment, a particular user is always associated with the same multi-tenant unique identifier once his user account has been created, and that same multi-tenant unique identifier is used by the cloud environment's authentication system to authenticate the user every time that the user seeks access to a service within the environment.).
As per claim 5, COLIN in view of TAN and further in view of Srinivasan teaches the method of claim 1, wherein execution of the code by the one or more processors causes the computer system to perform further operations (See COLIN: Page 62, line 14-16, computer program product encoded on a computer - readable medium which, when processed by a data processing apparatus, adapts the apparatus to perform the method) comprising: associating the created multi-tenant identifier with data received from the source system (See Srinivasan: [0072], the globally unique identifier can be called a multi-tenant unique identifier. In an embodiment, a particular user is always associated with the same multi-tenant unique identifier once his user account has been created, and that same multi-tenant unique identifier is used by the cloud environment's authentication system to authenticate the user every time that the user seeks access to a service within the environment.).
As per claim 6, COLIN in view of TAN and further in view of Srinivasan l teaches the method of claim 1, wherein execution of the code by the one or more processors causes the computer system to perform further operations (See COLIN: Page 62, line 14-16, computer program product encoded on a computer - readable medium which, when processed by a data processing apparatus, adapts the apparatus to perform the method) comprising:
receiving, from the source system, metadata describing an external content item stored at the source system (See TAN: Page 7, lines 11-12, at an acquiring host server system 20 where the identifier and the user details are recorded or stored. Here the identifier reads on a system metadata.),
wherein the source system identifier is associated with an element of the metadata (See TAN: Page 7, lines 11-12, at an acquiring host server system 20 where the identifier and the user details are recorded or stored. Here the identifier reads on a system metadata and is associated to the data); and
replacing a value of the source system identifier with the created multi-tenant identifier for identifying the element within the multi-tenant environment (See TAN: Page 11, lines 1-3, the acquiring host system 20 could also allocate a unique transaction identifier (e.g., a unique transaction number) to the transaction in order that a unique number is available within the system to track that transaction during processing. Here the unique transaction identifier combined the host system identifier and transaction number reads on replacing the source system identifier with a multi-tenant identifier).
As per claim 7, COLIN in view of TAN and further in view of Srinivasan teaches the method of claim 1, wherein the source identity provider uniquely identifies the source system and an identity provider used by the source system (See TAN: Page 11, lines 1-3, The acquiring host system 20 could also allocate a unique transaction identifier (e.g., a unique transaction number) to the transaction in order that a unique number is available within the system to track that transaction during processing).
As per claim 8, COLIN in view of TAN and further in view of Srinivasan teaches the method of claim 1,
wherein the created multi-tenant identifier is stored in a multi-tenant identifier mapping table comprise:
a multi-tenant identifier field (See Srinivasan: [0072], the multi-tenant unique identifier specifies the identity domain to which a user belongs); a source identity provider field (See TAN: Page 6, lines 15-16, a transaction identifier (e.g. a sales receipt) for a purchase transaction for at least one purchase); a source system identifier name field (See Srinivasan: [0033], the LDAP schema can specify properties can include, for example, (a) an identity domain entry, (b) a user entry, (c) a group entry, (d) a system identifier, (e) an identity domain administrator, and (f) a service instance administrator); and a source system identifier value field (See Srinivasan: [0056], The asserter can set this authenticated subject principal name to be the value in a directory unique identifier attribute of a user entry for the authenticated user in the LDAP directory).
As per claim 9, COLIN in view of TAN and further in view of Srinivasan teaches the method of claim 1, wherein execution of the code by the one or more processors causes the computer system to perform further operations (See COLIN: Page 62, line 14-16, computer program product encoded on a computer - readable medium which, when processed by a data processing apparatus, adapts the apparatus to perform the method) further comprising:
receiving source system identifiers from one or more other source systems (See TAN: Page 7, lines 11-12, at an acquiring host server system 20 where the identifier and the user details are recorded or stored. Here the identifier reads on a system metadata); and
creating and storing multi-tenant identifiers from the source system identifiers from the one or more other source systems (See Srinivasan: [0072], an entity's multi-tenant unique identifier is generated for that entity in response to and at the time that a new record for that entity is created and added to the LDAP directory);
wherein the created multi-tenant identifiers are unique within the multi-tenant environment across the source system and the one or more other source systems (See COLIN: Page 23, lines 17-20, When integrating an external system to the invention a parameter called "Source System ID" is set uniquely per system. When a card transaction is received the invention, the "Source System ID" will identify what external system the transaction originated from. For example, the system could be a credit card system, ATM system, Laser Card System, etc., and the "Source System ID" would be unique per system).
Related Prior Arts
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure can be found in the PTO-892 Notice of Reference Cited.
Conclusion
THIS ACTION IS MADE FINAL. 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.
Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner. SEE MPEP 2141.02 [R-5] VI. PRIOR ART MUST BE CONSIDERED IN ITS ENTIRETY, INCLUDING DISCLOSURES THAT TEACH AWAY FROM THE CLAIMS: A prior art reference must be considered in its entirety, i.e., as a whole, including portions that would lead away from the claimed invention. W.L. Gore & Associates, Inc. v. Garlock, Inc., 721 F.2d 1540, 220 USPQ 303 (Fed. Cir. 1983), cert. denied, 469 U.S. 851 (1984) In re Fulton, 391 F.3d 1195, 1201, 73 USPQ2d 1141, 1146 (Fed. Cir. 2004). >See also MPEP §2123.
In the case of amending the Claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KUEN S LU whose telephone number is (571)272-4114. The examiner can normally be reached on M-F, 8-19, Mid-Flex 2 hours.
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, Mr. Aleksandr Kerzhner can be reached on 571-270-1760. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
KUEN S LU /Kuen S Lu/
Art Unit 2165
Primary Patent Examiner
May 15, 2026
Prosecution Insights