DETAILED ACTION
The present application, filed on 6/7/2021 is being examined under the AIA first inventor to file provisions.
The following is a FINAL Office Action in response to Applicant’s amendments filed on 10/16/2025.
a. Claims 21, 28, 35 are amended
b. Claims 1-20 are cancelled
Overall, claims 21-40 are pending and have been considered below.
Claim Rejections - 35 USC § 103
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 difference 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 the invention was made.
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(a) are summarized as follows:
i. Determining the scope and contents of the prior art.
ii. Ascertaining the differences between the prior art and the claims at issue.
iii. Resolving the level of ordinary skill in the pertinent art.
iv. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 21-40 are rejected under 35 U.S.C. 103 as being unpatentable over Carlson (US 2014/0143137), in view of Dill et al (US 2015/0032627), in further view of Lemonik et al (US 2015/0195311), in further view of Iverson et al (US 2003/0220927), in further view of Cronic et al (US 2013/0191289).
Regarding Claims 21, 28, 35: Carlson discloses: A value-added services (VAS) computer system for accessing anonymized transaction data, the VAS computer system comprising at least one processor in communication with a memory device, the at least one processor configured to: {see at least fig2, [0068]-[0073]}
generate, according to a format associated with a VAS application executing on the VAS computer system, a secure identifier identifying a VAS account established between the VAS computer system and a cardholder computing device associated with a cardholder, and the cardholder computing device, the format of the secure identifier enabling a payment processor computer system to {see at least [0090] “In step 303, the untrusted device controller 140 receives the pairing identifier request and generates a unique pairing identifier for the indirect pairing. Alternatively, the untrusted device controller 140 may identify an available pairing identifier in a pairing identifier database. The untrusted device controller 140 may control a large number of untrusted devices and thus, many different pairing identifiers may be generated and/or outstanding at any particular time.”}
transmit, via the VAS application, the request to the payment processor computer system;
in response to transmitting the request to the payment processor computer system, {see at least [0102] “In step 312, assuming the user is authenticated, the user may provide the pairing identifier to the trusted device 120. In some embodiments, the user may also provide any additional information at this step. For example, the user may provide an untrusted device identifier (if there is one) as a second form of validation for ensuring the correct untrusted device 130 is being indirectly paired. In such embodiments, the trusted intermediary computer 150 may then compare the received untrusted device identifier to the pairing identifiers database entry associated with the pairing identifier to ensure a received untrusted device identifier received from the untrusted device controller 140 matches the received untrusted device identifier from the trusted device 120.”}
receive and present a request form generated and served by the payment processor computer system, the request form generated to be presented as the embeddable frame integrated with the VAS application executing on the cardholder computing device, {see at least [0119]-[0120] “In step 403, the user provides transaction details to the trusted device 120 to initiate a transaction request...”, “In step 404, the trusted device 120 may generate a transaction request based on the provided transaction details and send the transaction request (or other command request) to the trusted intermediary computer 150 …in some embodiments, a trusted intermediary computer 150 may store consumer details including financial information and other sensitive information in a user information database 152 at the trusted intermediary computer 150 and thus, the transaction request may merely include an account designation that corresponds to a enrolled user identifier or trusted device identifier (e.g., a username, device serial number, or phone number), an transaction type (e.g., withdraw or transfer), an account type (e.g., checking, savings, etc.), and an amount (e.g., $100) ...”, “Alternatively, some trusted intermediaries may merely be a third party trusted gateway to an untrusted device controller 140 and as such, may not have any pre-enrolled information about the user. In this instance, the command or transaction request may include all of the account information and sensitive information that may be necessary in order to complete the transaction. This information may include the user’s account number, PIN, expiration date, track 2 credit card data, etc.”}
the request form configured to
(a) App open 308 – Authentication Request 309}
(b) request and receive the cardholder authentication information from the cardholder, the cardholder authentication information inputted by the cardholder via the embeddable frame, {see at least [0119] Authentication Response 311}
(c) create a secure channel to transmit the cardholder authentication information from the authentication screen directly to the payment processor computer system by bypassing the VAS application and the VAS computer system, and {see at least [0119] Pairing request 315 – Pairing Confirmation 322}
(d) communicate, via the secure channel, the cardholder authentication information inputted on the authentication screen directly to the payment processor computer system; and {see at least fig3, fig4, [0059] User Details 403 – Transaction Request 404}
serve the request form to the cardholder computing device. {see at least [0119] “As shown in steps 401 and 402, before the method of FIG. 4 may be initiated, the trusted device 120 may receive and display a pairing confirmation informing the user and the trusted device 120 that the trusted device 120 is indirectly paired with the untrusted device 130. … In step 403, the user provides transaction details to the trusted device 120 to initiate a transaction request. The user has now received confirmation from both the trusted intermediary computer 150 as well as the untrusted device 130 that their trusted device 120 is paired. Accordingly, the consumer may now be shown a number of options for performing a transaction or other actions with the untrusted device 130. The options provided by the trusted intermediary computer 150 application may be determined by information included in the pairing confirmation message. For example, the trusted intermediary computer may include a transaction template or transaction template identifier in the pairing confirmation that includes the appropriate transaction request possibilities associated with the untrusted device controller 140 that is indirectly paired with the trusted device 120.”}
Carlson does not disclose, however Dill discloses:
… a secure identifier generated by the third-party computer system and embed the secure identifier in a request for access to the anonymized transaction data. {see at least [0065] A "payment token issuer identifier" may include any series of characters, numbers, or other identifiers that may be used to identify an issuer associated with a payment token. For example, a payment token issuer identifier may include a token BIN that identifies a particular issuer associated with an account identified using the token. In some embodiments, a payment token issuer identifier may be mapped to a real issuer identifier (e.g., a BIN) for an issuer. For example, a payment token issuer identifier may include a six-digit numerical value that may be associated with an issuer. For instance, any token including the payment token issuer identifier may be associated with a particular issuer. As such, the issuer may be identified using the corresponding issuer identifier range associated with the token issuer identifier. See also [0065] “A "payment token issuer identifier" may include any series of characters, numbers, or other identifiers that may be used to identify an issuer associated with a payment token. For example, a payment token issuer identifier may include a token BIN that identifies a particular issuer associated with an account identified using the token. In some embodiments, a payment token issuer identifier may be mapped to a real issuer identifier (e.g., a BIN) for an issuer. For example, a payment token issuer identifier may include a six-digit numerical value that may be associated with an issuer. For instance, any token including the payment token issuer identifier may be associated with a particular issuer. As such, the issuer may be identified using the corresponding issuer identifier range associated with the token issuer identifier”; [0067] “For example, in one implementation, a token may be embedded in machine-readable code which may be generated by a wallet provider, mobile application, or other application on mobile device and displayed on a display of the mobile device. The machine-readable code can be scanned at the POS through which the token is passed to the merchant. A mobile contactless mode may include passing the token through NFC in a contactless message.”}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Carlson to include the elements of Dill. One would have been motivated to do so, in order to be in the position to read the anonymized data. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, Carlson evidently discloses providing anonymized transaction data. Dill is merely relied upon to illustrate the functionality of a secure identifier in the same or similar context. Since both providing anonymized transaction data, as well as a secure identifier are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Carlson, as well as Dill would function in the same manner in combination as they do in their separate embodiments, it is concluded that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Carlson / Dill.
Carlson, Dill does not disclose, however, Lemonik discloses:
generate an embeddable frame compatible with the VAS application; {see at least fig16B, [0141] "At step 1602, a developer creates a data model and constructs a third party application in a manner such as that described above. The developer then provides a URL to users who wish to access the third party application. At step 1603, the users select the third party application (e.g., by clicking on the URL) and execute the application. Collaborative development service 130 causes the third party software application to be executed and provides access to the application via an embedded frame. For example, the users may create a document using the application which is embedded as an IFrame on a web page. At step 1604, the users interact with collaborative development service 130 via the embedded IFrame, using interframe communication through a parent frame . ... At step 1608, updates to the data are displayed within embedded IFrame in each user's display. At step 1609, a determination is made whether or not the users wish to make additional changes in the document. If so, the process returns to step 1605. If not, the process ends at step 1610."}
… the request form presented in an embeddable frame within the VAS application executing on the cardholder computing device {see at least fig16B, [0141] "At step 1602, a developer creates a data model and constructs a third party application in a manner such as that described above. The developer then provides a URL to users who wish to access the third party application. At step 1603, the users select the third party application (e.g., by clicking on the URL) and execute the application. Collaborative development service 130 causes the third party software application to be executed and provides access to the application via an embedded frame. For example, the users may create a document using the application which is embedded as an IFrame on a web page. At step 1604, the users interact with collaborative development service 130 via the embedded IFrame, using interframe communication through a parent frame . ... At step 1608, updates to the data are displayed within embedded IFrame in each user's display. At step 1609, a determination is made whether or not the users wish to make additional changes in the document. If so, the process returns to step 1605. If not, the process ends at step 1610."}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Carlson, Dill to include the elements of Lemonik. One would have been motivated to do so, in order to use an established form of communication. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, Carlson, Dill evidently discloses providing anonymized transaction data. Lemonik is merely relied upon to illustrate the functionality of a request presented in an embeddable frame in the same or similar context. Since both providing anonymized transaction data, as well as a request presented in an embeddable frame are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Carlson, Dill, as well as Lemonik would function in the same manner in combination as they do in their separate embodiments, it is concluded that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Carlson, Dill / Lemonik.
Carlson, Dill, Lemonik does not disclose, however, Iverson discloses:
… the secure identifier does not contain any information directly identifying the cardholder account and does not contain any information directly identifying a cardholder associated with the cardholder account. (see at least [0032] "Next if the record is not already stored in secure cross-reference table 202 (step 503), de-identify software 402 may generate a random de-identification pointer not related to information in the associated record (step 504). For example, software 402 may use a "Random class" or "SecureRandom class" both available in the JAVA standard APL Both classes produce sequences of pseudorandom numbers based on a seed value. Since the Random and SecureRandom classes may generate a same random number more than one time, software 402 also verifies that each generated random number has not been used in secure cross-reference table 202. The de-identification pointer is an index key and, as such, the deidentification pointer may not be duplicated in secure cross-reference table 202. Each deidentification pointer generated by software 402 may be checked against all other deidentification pointers in secure cross-reference table 202 to ensure that the deidentification pointer is not duplicated. One skilled in the art will appreciate that other methods may be used to generate the de-identification pointer, such as a shuffling algorithm." }
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Carlson, Dill, Lemonik to include the elements of Iverson. One would have been motivated to do so, in order to avoid identifyin the cardholder account. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, Carlson, Dill, Lemonik evidently discloses providing anonymized transaction data. Iverson is merely relied upon to illustrate the functionality of an identifier that does not contain identifiable information in the same or similar context. Since both providing anonymized transaction data, as well as n identifier that does not contain identifiable information are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Carlson, Dill, Lemonik, as well as Iverson would function in the same manner in combination as they do in their separate embodiments, it is concluded that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Carlson, Dill, Lemonik / Iverson.
Carlson, Dill, Lemonik, Iverson does not disclose, however, Cronic discloses:
… (b) present the embeddable frame as an authentication screen on the cardholder computing device via the VAS application. {see at least fig7, [0120] “The third-party merchant 162 can provide a user name and password using the login panel 702 to authenticate with the token access system 122. Other authentication mechanisms are possible. For example, the login panel 702 can present the third-party merchant 162 with an opportunity to present a unique cryptographic identifier or key. This key, in certain embodiments, can then be matched to or decrypted with a corresponding public key to authenticate the third-party merchant 162.”}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Carlson, Dill, Lemonik, Iverson to include the elements of Cronic. One would have been motivated to do so, in order to identify the cardholder account. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, Carlson, Dill, Lemonik, Iverson evidently discloses providing anonymized transaction data. Cronic is merely relied upon to illustrate the functionality of using the embeddable frame as authentication screen in the same or similar context. Since both providing anonymized transaction data, as well as using the embeddable frame as authentication screen are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Carlson, Dill, Lemonik, Iverson, as well as Cronic would function in the same manner in combination as they do in their separate embodiments, it is concluded that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Carlson, Dill, Lemonik, Iverson / Cronic.
Regarding Claims 22, 29, 36: Carlson, Dill, Lemonik, Iverson, Cronic discloses the limitations of Claims 21, 28, 35. Carlson further discloses:
wherein the information included in the secure identifier does not directly identify a cardholder account of the cardholder. {see at least [0098] secure identifier}
Regarding Claims 23, 30, 37: Carlson, Dill, Lemonik, Iverson, Cronic discloses the limitations of Claims 21, 28, 35. Carlson further discloses: wherein the at least one processor is further configured to:
receive a registration request from the cardholder computing device, the registration request including a set of information associated with the cardholder; and {see at least [0083] (“A consumer may enroll for pairing services with the trusted intermediary 150 or may send sensitive information to the trusted intermediary 150 without enrolling with the trusted intermediary 150, using the trusted intermediary 150 as a secure gateway for their sensitive information. Where the user or consumer does not enroll with the trusted intermediary 150, the trusted intermediary 150 may not store their data or may only store data temporarily for the duration of completing a particular transaction and then delete the information.”; [0098] “In step 302, the untrusted device 130 informs the untrusted device controller 140 that secure entry has been requested. The untrusted device 130 may generate and send a pairing identifier request to the untrusted device controller 140 to ask for an available pairing identifier from the untrusted device controller 140. The pairing identifier request may include an untrusted device identifier and any expiration conditions input by the user.”}
create, using the set of information, the VAS account. {see at least [0090}
Regarding Claims 24, 31, 38: Carlson, Dill, Lemonik, Iverson, Cronic discloses the limitations of Claims 21, 28, 35. Carlson further discloses: wherein the at least one processor is further configured to:
automatically generate a set of information associated with the cardholder; {see at least [0081] "If the third-party merchant 162 is authorized to access the tokenization provider system 102, the CHD access system 124 receives a token from the third-party merchant 162 at block 308. Alternatively, at block 308, the CHD access system 124 accesses the token pre-associated with the third-party merchant 162 by the merchant 142 from the token access repository 134. In one embodiment, receiving the token comprises receiving a token identifier associated with the token. In one embodiment, receiving the token includes receiving a request to access CHD associated with the token."}
transmit the set of information to the cardholder computing device; and {see at least [0099]; [0102]}
create, using the set of information, the VAS account. {see at least [0099]; [0102]}
Regarding Claims 25, 32, 39: Carlson, Dill, Lemonik, Iverson, Cronic discloses the limitations of Claims 21, 28, 35. Carlson further discloses: wherein the at least one processor is further configured to:
receive, from the cardholder computing device, a designation of a particular payment network associated with a cardholder account of the cardholder; {see at least [0103] “In step 313, the trusted device 120 may generate and send a pairing request including the pairing identifier to the trusted intermediary computer. The pairing request message may include any suitable information to allow the trusted intermediary computer 150 to identify the untrusted device controller 140 and pairing identifier associated with the pairing request. For example, the pairing request message may include the pairing identifier and an untrusted device identifier, the city, state, zip code, form factor of the trusted device 120 or untrusted device 130, etc., in order for the trusted intermediary computer 150 to identify the untrusted device controller 140 or the untrusted device 130 that the user is attempting to pair with. Although it is possible to determine the untrusted device 130 upon the pairing identifier alone, such a system may identify an incorrect untrusted device controller 140 if the pairing identifier is not unique across all possible untrusted devices and untrusted device controllers that the trusted intermediary computer 150 may possibly communicate with. Accordingly, the pairing request may include secondary information about the untrusted device 130 or the pairing request to help the pairing identifier or trusted intermediary computer 150 to determine the correct untrusted device controller 140.”}
identify the payment processor computer system based on the designation; and {see at least [0104] “In step 314, the trusted intermediary computer 150 determines the untrusted device controller 140 associated with the pairing request. The trusted intermediary computer 150 may receive the pairing request, extract the pairing identifier from the pairing request, and search a pairing identifiers database 151 for a matching pairing identifier. Further, in some embodiments, the trusted intermediary computer 150 may verify the pairing identifier is active, valid, and/or unlocked by searching a pairing identifiers database 151 for status information associated with the pairing identifier. In some embodiments (not shown in FIG. 3) the trusted intermediary computer 150 may send a verification request to the determined untrusted device controller 140 to determine if the pairing identifier is still active, has not been requested by the trusted intermediary computer 150 or a different trusted intermediary (not shown) previously, or has not met an expiration condition. If the pairing identifier is associated with a triggered expiration condition or is otherwise locked or unavailable, the pairing identifier cannot be used by the untrusted device controller 140 and the pairing request may be declined.”}
transmit the request to the payment processor computer system based on the particular payment network designated. {see at least [0104] “In step 314, the trusted intermediary computer 150 determines the untrusted device controller 140 associated with the pairing request. The trusted intermediary computer 150 may receive the pairing request, extract the pairing identifier from the pairing request, and search a pairing identifiers database 151 for a matching pairing identifier. Further, in some embodiments, the trusted intermediary computer 150 may verify the pairing identifier is active, valid, and/or unlocked by searching a pairing identifiers database 151 for status information associated with the pairing identifier. In some embodiments (not shown in FIG. 3) the trusted intermediary computer 150 may send a verification request to the determined untrusted device controller 140 to determine if the pairing identifier is still active, has not been requested by the trusted intermediary computer 150 or a different trusted intermediary (not shown) previously, or has not met an expiration condition. If the pairing identifier is associated with a triggered expiration condition or is otherwise locked or unavailable, the pairing identifier cannot be used by the untrusted device controller 140 and the pairing request may be declined.”}
Regarding Claims 26, 33, 40: Carlson, Dill, Lemonik, Iverson, Cronic discloses the limitations of Claims 21, 28, 35. Carlson further discloses: wherein the at least one processor is further configured to
associate the VAS account with the secure identifier by writing a record in account records stored in a database in communication with the at least one processor. {see at least [0032] "Next if the record is not already stored in secure cross-reference table 202 (step 503), de-identify software 402 may generate a random de-identification pointer not related to information in the associated record (step 504). For example, software 402 may use a "Random class" or "SecureRandom class" both available in the JAVA standard APL Both classes produce sequences of pseudorandom numbers based on a seed value. Since the Random and SecureRandom classes may generate a same random number more than one time, software 402 also verifies that each generated random number has not been used in secure cross-reference table 202. The de-identification pointer is an index key and, as such, the de-identification pointer may not be duplicated in secure cross-reference table 202. Each deidentification pointer generated by software 402 may be checked against all other deidentification pointers in secure cross-reference table 202 to ensure that the deidentification pointer is not duplicated. One skilled in the art will appreciate that other methods may be used to generate the de-identification pointer, such as a shuffling algorithm."}
Regarding Claims 27, 34: Carlson, Dill, Lemonik, Iverson, Cronic discloses the limitations of Claims 21, 28. Carlson further discloses:
wherein the VAS application provides an interface between the cardholder computing device and the at least one processor, and {see at least [0028]-[0029] “For example, in some embodiments, a consumer may use their mobile communication device (e.g., a mobile phone, smart phone, tablet, etc.) to pair with an untrusted automatic teller machine ("ATM") by requesting a pairing identifier from the ATM. The ATM may request a pairing identifier from an ATM device controller/driver that controls the ATM and makes transaction decisions on behalf of the ATM device. The ATM device controller may identify an available pairing identifier and may send a response with the pairing identifier to the untrusted ATM device. The ATM device may then display the pairing identifier for use by the consumer. The ATM device controller may also send the pairing identifier and an expiration time to a trusted intermediary computer which stores the pairing identifier along with a reference to the ATM device controller.” “The user may then activate a connection with the trusted intermediary through their mobile communication device (trusted device) and authenticate themselves to the trusted intermediary. The user may then enter the displayed pairing identifier, and optionally some ATM identification information, into their mobile communication device (trusted device) which may generate a pairing request that is sent to the trusted intermediary. The trusted intermediary may then determine the relevant ATM device controller based on the ATM identification information and/or the pairing identifier, and may send a pairing request to the corresponding ATM controller.”}
wherein the at least one processor is further configured to
serve the request form to the cardholder computing device in the format associated with the VAS application. {see at least [0028]-[0029] “For example, in some embodiments, a consumer may use their mobile communication device (e.g., a mobile phone, smart phone, tablet, etc.) to pair with an untrusted automatic teller machine ("ATM") by requesting a pairing identifier from the ATM. The ATM may request a pairing identifier from an ATM device controller/driver that controls the ATM and makes transaction decisions on behalf of the ATM device. The ATM device controller may identify an available pairing identifier and may send a response with the pairing identifier to the untrusted ATM device. The ATM device may then display the pairing identifier for use by the consumer. The ATM device controller may also send the pairing identifier and an expiration time to a trusted intermediary computer which stores the pairing identifier along with a reference to the ATM device controller.” “The user may then activate a connection with the trusted intermediary through their mobile communication device (trusted device) and authenticate themselves to the trusted intermediary. The user may then enter the displayed pairing identifier, and optionally some ATM identification information, into their mobile communication device (trusted device) which may generate a pairing request that is sent to the trusted intermediary. The trusted intermediary may then determine the relevant ATM device controller based on the ATM identification information and/or the pairing identifier, and may send a pairing request to the corresponding ATM controller.”}
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
US 20190188747 A1 Sharma; Prashant et al. REWARD OPTIMIZATION THROUGH REAL TIME AUTHORIZATION PROCESSING A method includes receiving a transaction authorization request message in a payment account system. A relevant database entry is accessed to determine whether another payment account belonging to the account holder should be inserted into the transaction authorization request message in place of the payment account originally submitted for use in the transaction. The purpose may be to maximize loyalty reward points or otherwise to gain a benefit available by using the other payment account rather than the originally submitted payment account.
US 20100290453 A1 Rist; Claus et al. Method and Communication Terminal for Providing VOIP The invention relates to a method for providing Voice over IP (VoIP) in a communication system with a number of terminals operating with VoIP, between which a transmission of voice data according to VoIP or a signalling is achieved, wherein the signalling is achieved using the Computer Supported Telecommunication Application (CSTA) interface standard. Telephone services can be controlled by a computer using the CSTA protocol. As for conventional application, H323 protocol and SIP are used for IP telephony processing of audio/video streams of a conversation. The invention is based on replacing H323 protocol and SIP by a CSTA protocol only when the latter is correspondingly extended.
US 20090282244 A1 Brown; Stephen J. MEDICAL DEVICE RIGHTS AND RECALL MANAGEMENT SYSTEM The embodiments provide systems and methods for medical device rights and recall management system. A digital IP rights and recall management device activates a central key server to authenticate software contents and services operated on a microprocessor based medical devices through a coding key that may be embedded in a medical device or in a service provider server or in an end user computer. The recall management server unlocks the software content transmitted from or to a value-added service provider and selectively recall the value-added software component without requiring any physical recall of the medical device. The system maintains a virtual device master record which enables quality control and recall capability for software elements independent of any physical hardware recall.
US 20110137741 A1 Omer; Ido et al. PATH QUERIES Data identifying a path is received between two or more geographic locations. Path information is identified along or near the path. A relevance is associated to the path information. A subset of the path information having a highest relevance is provided.
US 20150287037 A1 Salmon; Diane et al. DATA PASSED IN AN INTERACTION A method for providing first data and second data for an interaction is disclosed. The first data is beneficial to a first party and necessary for the interaction, while the second data is beneficial to a second party and is not necessary for the interaction. The first data and second data are provided by a first party device in a single data element. A second party device receives the single data element, separates the first data and second data, and processes the first data and second data separately.
US 20250232289 A1 Singh; Sachin Kumar et al. SCALABLE ORCHESTRATION FRAMEWORK FOR ACCESSING OFF-NETWORK VALUE-ADDED SERVICES A scalable orchestration framework for accessing a plurality of value-added services platforms is provided. The framework includes an orchestrator platform having a memory and a processor. The processor programmed to: (i) receive a first request data signal including a plurality of elements; (ii) extract the plurality of elements of the first request data signal; (iii) determine a total number of services of a plurality of value-added services to be invoked; (iv) instantiate a service execution layer corresponding to each service of the plurality of services to be invoked at the plurality of services platforms; (v) provision each instantiated service execution layer with business rules and an endpoint configuration file corresponding to a service of the plurality of services; (vi) transmit a message to each instantiated service execution layer to receive a response from the respective service platform; and (vii) transmit a first response data signal based upon the received response.
US 20150199689 A1 Kumnick; Phillip et al. PAYMENT ACCOUNT IDENTIFIER SYSTEM A method for utilizing a non-transactable account identifier with a payment token is disclosed. The non-transactable account identifier can have the same format as a primary account number (PAN) and the payment token, but is not used to conduct a payment transaction.
US 5673395 A Kawakita; Jun Process for constructing computer network system of tenant intelligent building Computer network systems in optional tenant rooms in an intelligent building are connected collectively by means of optical fiber cables and an optical patch panel, thereby providing computer network systems of every tenants independent of each other and high in safety. Optical connectors 8 are respectively provided in a plurality of tenant rooms installed on the respective floors 7 of a tenant intelligent building incorporating therein enterprises different from one another, optical fiber cables having at least four cores are connected to the optical connectors 8, the cables in the respective tenant rooms on the respective floors are bundled and connected to an optical patch panel provided at an appropriate place in the building, and the optical fiber cables 12 from the tenant rooms can be connected to one another though the optical patch panel 16 by replacing patch cords, so that independent transmission medium systems 20 of the respective tenant are per formed. In accordance with the use conditions of the tenant floors in the building, the backbone system of a desirable block (tenant rooms) on desired floors can be easily constructed merely by replacing the patch cords on the optical patch panel.
Response to Amendments/Arguments
Applicant’s submitted remarks and arguments have been fully considered.
Applicant is of the opinion that the prior art fails to teach Applicant’s invention.
Examiner respectfully disagrees.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 103.
Applicant submits remarks and arguments geared toward the amendments. Examiner has carefully reviewed and considered Applicant’s remarks, however they ARE MOOT in light of the fact that they are geared towards the amendments.
The other arguments presented by Applicant continually point back to the above arguments as being the basis for the arguments against the other 103 rejections, as the other arguments are presented only because those claims depend from the independent claims, and the main argument above is presented against the independent claims. Therefore, it is believed that all arguments put forth have been addressed by the points above.
Examiner has reviewed and considered all of Applicant’s remarks. The changes of the grounds for rejection, if any, have been necessitated by Applicant’s extensive amendments to the claims. Therefore, the rejection is maintained, necessitated by the extensive amendments.
Conclusion
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 mailing date of this final action.
Inquiries
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Radu Andrei whose telephone number is 313.446.4948. The examiner can normally be reached on Monday – Friday 8:30am – 5pm EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John Hayes can be reached at 571.272.6708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
As disclosed in MPEP 502.03, communications via Internet e-mail are at the discretion of the applicant. Without a written authorization by applicant in place, the USPTO will not respond via Internet e-mail to any Internet correspondence which contains information subject to the confidentiality requirement as set forth in 35 U.S.C. 122. A paper copy of such correspondence will be placed in the appropriate patent application. The following is a sample authorization form which may be used by applicant:
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with me concerning any subject matter of this application by electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center information webpage. Status information for unpublished applications is available to registered users through Patent Center information webpage only.
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.
Any response to this action should be mailed to:
Commissioner of Patents and Trademarks
P.O. Box 1450
Alexandria, VA 22313-1450
or faxed to 571-273-8300
/Radu Andrei/
Primary Examiner, AU 3697
Prosecution Insights