WO2017149533A1

WO2017149533A1 - Contact information bridge/middleware/platform

Info

Publication number: WO2017149533A1
Application number: PCT/IL2017/050251
Authority: WO
Inventors: Ofer AISH
Original assignee: Aish Ofer
Priority date: 2016-03-03
Filing date: 2017-02-28
Publication date: 2017-09-08

Abstract

The present disclosure provides systems, methods, platforms and programs for facilitating individual contact information (ICI) or business-card (BC) sharing/transfer between electronic devices operating business card applications, by establishing a communication channel for linking between the applications, and converting an ICI from a format compatible with one application to a format compatible with other application (s).

Description

CONTACT INFORMATION BRIDGE/MIDDLEWARE/PLATFORM

TECHNICAL FIELD

The present disclosure generally relates to the field of individual contact information sharing.

BACKGROUND

The sharing of individual contact information is essential in the realms of business, academia, technology and others, for establishing means for contacting people/organizations with whom you may want to establish or further a connection for various reasons. For many years, the sharing of such individual contact information has been done by an exchange of physical cards (business/contact cards), having printed thereon the contact information of the individual/organization. While this method is relatively old and entails numerous disadvantages, it is still the most commonly used method for sharing contact information. Computerized alternatives to physical cards have been developed in recent years. Most notable alternatives are software applications that run on mobile electronic devices and enable sending and receiving electronic individual contact information with other users having the same software applications installed on their mobile electronic device. This approach has not been successful in replacing the usage of physical cards, mainly because of inter-compatibility issues between the various apps, resulting in the lack of ability of sharing contact information electronically between users with different applications installed on their mobile electronic devices.

There is thus a need in the art for methods, platforms and systems that enable a convenient sharing of individual contact information between different electronic devices. SUMMARY

The following embodiments and aspects thereof are described and illustrated in conjunction with systems, tools and methods which are meant to be exemplary and illustrative, not limiting in scope. In various embodiments, one or more of the above - described problems have been reduced or eliminated, while other embodiments are directed to other advantages or improvements.

According to some embodiment, there are provided herein systems and methods for facilitating the transfer/sharing of individual contact information (ICI) between at least two mobile electronic devices with two business-card (BC) applications. According to some embodiments, the middleware or BC middleware operating system (BCMOS) is imbedded within the first BC application in the first mobile electronic device, and the middle ware/B CMOS is also imbedded within the second BC application in the second mobile electronic device. According to some embodiments, the BCMOS is configured to facilitate ICI transfer and/or sharing between the first and second device by providing an interface to the first BC application and second BC application through which the applications may instruct the middle ware to send/receive ICI to/from a selected device.

According to some embodiments, the first BC application may support a first ICI format, and the second application may support a second ICI format. According to some embodiments, the BCMOS is configured to convert an ICI from the first format to a common format, send the ICI in the common format to the BCMOS on the second mobile electronic device, and convert the ICI from the common format to the second format.

According to some embodiments, there is provided a BCMOS with an application programming interface (API) or a software development kit (SDK) for imbedding the BCMOS within the BC's applications.

According to some embodiments, the BCMOS may include an API/SDK for defining a template/format for representing the information fields in ICIs, thereby the BCMOS provides a unified frame/template/format that various BC applications may utilize to share ICIs. Advantageously, the BCMOS may enable sharing of ICIs between two mobile electronic devices having two otherwise non-compatible BC applications.

According to some embodiments, there is provided a system for individual contact information (ICI) sharing between at least a first electronic device having a first business card (BC) application and a second electronic device having a second BC application, the system comprising a first middleware, associated with the first BC application, a second middleware, associated with the second BC application. Wherein said first middleware is configured to receive a command from the first BC application to send an ICI in a first format from the first BC application on the first electronic device to the second BC application on the second device, the first format being compatible with the first BC application, establish a communication channel with said second middleware of the second electronic device, convert the ICI from the first format to a common format, and send the ICI in the common format to said second middleware via the established communication channel. And said second middleware is configured to obtain from said first middleware an ICI in the common format, convert the ICI from the common format to a second format, the second format being compatible with the second BC application, and provide the ICI in the second format to the second BC application.

According to some embodiments, the communication channel comprises email, short message service (SMS), Bluetooth, cellular communication, near field communication (NFC), Infra-Red (IR), quick response code and imaging (QR code), or any combination thereof. According to some embodiments, the communication channel comprises communication through a cellular network. According to some embodiments, the first format and the second format are similar ICI formats. According to some embodiments, the first BC application and the second BC application are similar BC applications. According to some embodiments, the first format and the second format are not similar, and they vary in one or more of the following features: a level of details in the ICI, number of fields in the ICI, language of information in the ICI, and representation format of information in the ICI. According to some embodiments, the first middleware is configured to encrypt the ICI in the common format before sending, and said second middleware is configured to decrypt the received ICI before converting the ICI to the second format. According to some embodiments, the first middleware is configured to encode the ICI using an error-detection code before sending, and said second middleware is configured to decode the obtained ICI and check for errors before converting the ICI to the second format.

According to some embodiments, the error detection code comprises repetition codes, parity bit(s), checksum, cyclic redundancy check (CRC), cryptographic hash function, error-correcting code (ECC), or any combination thereof. According to some embodiments, the second middleware is configured to send an acknowledge message to said first middleware to confirm receiving an ICI.

According to some embodiments, there is provided a method for individual contact information (ICI) sharing between at least a first electronic device having a first business card (BC) application associated with a first BC middleware, and a second electronic device having a second BC application associated with a second BC middleware, the method comprising providing a command, from the first BC application to the first BC middleware, to send an ICI in a first format from the first BC application the second BC application, the first format being compatible with the first BC application, establish a communication channel between the first BC middleware and the second BC middleware, convert the ICI from the first format to a common format, and send the ICI in the common format from the first BC middleware to the second BC middleware via the established communication channel, and convert the ICI from the common format to a second format in the second BC middleware, the second format being compatible with the second BC application, and provide the ICI in the second format from the second BC middleware to the second BC application.

According to some embodiments, converting the ICI from the first format to the common format comprises encoding the ICI in the first format using an encoding method, and converting the ICI from the common format to the second format comprises decoding the ICI in the common format using a decoding method. According to some embodiments, the encoding method comprises utilizing an error correction code selected from: repetition codes, parity bit(s), checksum, cyclic redundancy check (CRC), cryptographic hash function, error-correcting code (ECC), or any combination thereof.

According to some embodiments, converting the ICI from the first format to the common format comprises encrypting the ICI in the first format using an encryption method, and converting the ICI from the common format to the second format comprises decrypting the ICI in the common format using a decryption method. According to some embodiments, the encryption method comprises an encryption algorithm selected from: 3DES, RC2, RC4, RC5, RC6, Blowfish, Twofish, Diffie- Hellman, SEAL, DSA, RSA or any combination thereof. According to some embodiments, the method further comprises a confirmation message from the second BC middleware to the first BC middleware if the ICI was received.

According to some embodiments, there is provided a sender middleware for individual contact information (ICI) sharing between at least a first electronic device having a first business card (BC) application associated with the sender BC middleware, and a second electronic device having a second BC application associated with a receiver BC middleware, the sender middleware is configured to receive a command from the first BC application to send an ICI in a first format from the first BC application on the first electronic device to the second BC application on the second device, the first format being compatible with the first BC application, establish a communication channel with said second middleware of the second electronic device, convert the ICI from the first format to a common format, and send the ICI in the common format to said second middleware via the established communication channel.

According to some embodiments, there is provided a receiver middleware for individual contact information (ICI) sharing between at least a first electronic device having a first business card (BC) application associated with a sender BC middleware, and a second electronic device having a second BC application associated with the receiver BC middleware, the receiver middleware is configured to obtain from the sender middleware an ICI in the common format, convert the ICI from the common format to a second format, the second format being compatible with the second BC application, and provide the ICI in the second format to the second BC application. According to some embodiments, there is provided an operating system, including a middleware according to the abovementioned embodiments. According to some embodiments, there is provided s data carrier, carrying a middleware according to the abovementioned embodiments. According to some embodiments, there is provided a computer program product, configured to operate a middleware according to the abovementioned embodiments. According to some embodiments, there is provided a data stream, which is representative of an ICI, a data structure product, which is representative of an ICI and/or a processing system, comprising means for carrying out ICI sharing methods according to the abovementioned embodiments.

Certain embodiments of the present disclosure may include some, all, or none of the above advantages. One or more technical advantages may be readily apparent to those skilled in the art from the figures, descriptions and claims included herein. Moreover, while specific advantages have been enumerated above, various embodiments may include all, some or none of the enumerated advantages.

In addition to the exemplary aspects and embodiments described above, further aspects and embodiments will become apparent by reference to the figures and by study of the following detailed descriptions.

BRIEF DESCRIPTION OF THE DRAWINGS

Examples illustrative of embodiments are described below with reference to figures attached hereto. In the figures, identical structures, elements or parts that appear in more than one figure are generally labeled with a same numeral in all the figures in which they appear. Alternatively, elements or parts that appear in more than one figure may be labeled with different numerals in the different figures in which they appear. Dimensions of components and features shown in the figures are generally chosen for convenience and clarity of presentation and are not necessarily shown in scale. The figures are listed below.

Fig.l schematically illustrates ICI sharing between two mobile devices, according to some embodiments;

Fig.2 schematically illustrates ICI sharing between two devices through a cellular network, according to some embodiments;

Fig.3 schematically illustrates a software hierarchy of two devices, according to some embodiments; Fig.4 schematically illustrates an encrypted ICI sharing scheme, according to some embodiments;

Fig.5 schematically illustrates the conversion of ICI data format/structure from a first format to a second format, according to some embodiments;

Fig.6 schematically illustrates ICI sharing from one device to three or N devices, according to some embodiments;

Fig.7 schematically illustrates a method for ICI sharing between two devices, according to some embodiments;

Fig.8 schematically illustrates a method for secure ICI sharing between two devices, according to some embodiments; Fig.9a schematically illustrates a functional block diagram of encrypted ICI sharing, according to some embodiments;

Fig.9b schematically illustrates a functional block diagram of encrypted ICI sharing, according to some embodiments, and

Fig.10 schematically illustrates a method for secure ICI sharing between two devices, according to some embodiments. DETAILED DESCRIPTION

In the following description, various aspects of the disclosure will be described. For the purpose of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the different aspects of the disclosure. However, it will also be apparent to one skilled in the art that the disclosure may be practiced without specific details being presented herein. Furthermore, well-known features may be omitted or simplified in order not to obscure the disclosure.

In the flow of business and personal life, people get introduced to others on various occasions, such as business meetings, conferences, seminars, travel, sports events and so on. A common way for people to share their contact information for a potential prospective contact is by means of providing a physical business card (BC) having printed thereon individual contact information (ICI).

In modern days, the interaction between people is increased due to travel availability, global connectivity, awareness of networking, business demand and others. As a result, the average person may receive a large number of business cards, and managing those business cards becomes a challenge.

Recently, many applications have been introduced to the market for meeting this challenge. Some applications enable you to share your contact information via email to other people, and manage the contact information that you receive and save manually to the applications. Some applications may even enable you to share the individual contact information with other users of the same application by various communication means, such as Bluetooth, NFC and other applications address the challenge by analyzing an image of the received business card and storing the analyzed data for future use. Additionally, different BC applications may have varying features and capabilities, such that different individuals may prefer to use different BC applications, and as a result they will not be able to share their ICIs together due to the lack of interoperability between the various BC applications.

Despite the promise of the abovementioned approaches to provide solutions to ease the business card management and sharing challenge, no solution has been provided yet for a convenient sharing of ICIs between electronic mobile devices with different business card applications.

According to some embodiments, there are disclosed herein systems, methods, computer program products, data structures, data streams and platforms for facilitating the transfer/sharing of ICIs between two or more mobile electronic devices. According to some embodiments, the mobile electronic devices may have installed thereon or operated thereon business-card applications for managing the ICIs within the devices. Generally, each BC application may have different features, characteristics, performance capabilities and representation of the ICIs and the fields thereof, and different users may prefer to use different BC applications based on those characteristics of the BC applications. As a result of the differences between the BC applications, they become in-compatible with one another, and sharing ICIs between different applications becomes very complicated, if at all possible.

According to some embodiments, there is provided a middleware (BCMOS) integrated or associated with the BC applications for providing a platform/bridge for enabling the sharing of ICIs between the different BC applications.

Reference is now made to Fig.l, which schematically illustrates a setting 100 of ICI sharing between a first mobile electronic device, such as first cellphone 110, and a second electronic device, such as second cellphone 120, according to some embodiments. According to some embodiments, a first BC application 112 is operated on first cellphone 110 and a second BC application 122 is operated on second cellphone 120, and a BCMOS is integrated within first BC application 112 and second BC application 122 and configured to provide a communication bridge there between, for example by: · Enabling a device detection 130 capability, through which first BC application 112 may be able to detect second BC application 122. According to some embodiments, the detection is intended to identify if BC App 122 have the BCMOS application installed on it.

• Establishing a communication link between first cellphone 110 and second cellphone 120, for example by utilizing a first Bluetooth,

NFC or other communication 114 on first cellphone 110 and a second Bluetooth, NFC or other communication 124 on second cellphone 120.

• Transferring ICIs 132 between first cellphone 110 and second cellphone 120, and providing the ICIs to first BC application 112 and/or second BC application 122.

According to some embodiments, the ICI representation in first BC application 112 and second BC application 122 may be similar or dissimilar. According to some embodiments, first BC application 112 may have an ICI representation in a first format, while second BC application 122 may have an ICI representation in a second format. According to some embodiments, the BCMOS is configured to convert ICI representation from the first format to the second format. According to some embodiments, the BCMOS may have a common ICI representation/format, and first application 112 and second application 122 are designed to interact with the BCMOS according to the common ICI representation/format. According to some embodiments, the BCMOS may receive an ICI from first

BC application 112 in a first format, then convert the ICI from the first format to the common format, and then transfer the ICI 132 in the common format and convert it to the second format to be provided to second BC application 122.

According to some embodiments, the communication channel between the two devices is direct, such as Bluetooth, Infra-Red, QR-imaging, direct Wi-Fi communication (WiFi P2P) or the like. According to some embodiments, the communication channel between the two devices is indirect, and may involve a third device or network, for example a cellular network, an internet network, a local hub, a local area network, a personal area network (PAN), a group ad hoc network (GN) device, a network access point (NAP), or the like.

Reference is now made to Fig.2, which schematically illustrates a setting 200 of ICI sharing between a first mobile electronic device, such as first cellphone 210, and a second electronic device, such as second cellphone 220, according to some embodiments. According to some embodiments, a first BC application 212 is operated on first cellphone 210 and a second BC application 222 is operated on second cellphone 220, and a BCMOS is configured to provide a communication bridge between first BC application 212 and second BC application 222.

According to some embodiments, the BCMOS may enable first cellphone 210 and second cellphone 220 to detect 230 one-another, and then to initiate an ICI transfer 232 or sharing. According to some embodiments, ICI transfer 232 may be done using a different channel, such as a cellular network240. According to some embodiments, first cellphone 210 and second cellphone 220 are configured to communicate with cellular network 240 via a cellular communication protocol, such as cellular communication 250 and cellular communication 252, which may include GSM, CDMA or the like.

According to some embodiments, the BCMOS may be operable on any of the end devices, imbedded within any of the BC application, operable on a server or any combination thereof.

Reference is now made to Fig.3, which schematically illustrates a software hierarchy 300 of two devices sharing ICIs, according to some embodiments. According to some embodiments, a first application 310 includes an application user interface, such as APP A UI 314, which provides a user of first application 310 with functional abilities and graphical visualization of various features and/or designs of first application 310, APP A UI 314 is associated/linked with the backend of first application 310, such as APP A Backend 316, which includes the implementation of various operational functions and procedures of first application 310. According to some embodiments, APP A Backend 316 is designed to use BCMOS functions and capabilities provided by BCMOS A 360, which is integrated within first application 310.

According to some embodiments, a second application 320 includes an application user interface, such as APP B UI 324, which provides a user of second application 320 with functional abilities and graphical visualization of various features and/or designs of second application 320, APP B UI 324 is associated/linked with the backend of second application 320, such as APP B Backend 326, which includes the implementation of various operational functions and procedures of second application 320. According to some embodiments, APP B Backend 326 is designed to use BCMOS functions and capabilities provided by BCMOS B 362, which is integrated within second application 320.

According to some embodiments, a user of first application 310 may request from first application 310 to detect nearby users of other applications or devices, using APP A UI 314, the request is analyzed/processed in APP A Backend 316, and sent through to BCMOS A 360.

BCMOS A 360 then initiates a device detection 330 process, searching for nearby users or other devices/applications. Device detection 330 may be carried out by direct communication protocols such as P2P WiFi, Bluetooth, NFC, IR or the like, or by indirect communication means such as cellular communication, internet, local area network personal area network or the like. An ICI transfer channel 332 may then be selected to for ICI transfer.

According to some embodiments, when a device operating second application 320 is detected, a notification is sent to the user of second application 320 via APP B UI 324 and a permission/acknowledgment is requested. Then BCMOS A 360 may send the ICI of the user of first application 310 to BCMOS B 362, and the ICI may then be converted to a format supported by APP B Backend 326.

According to some embodiments, the BCMOS on both devices is basically the same BCMOS, and may be integrated within different BC applications or different BC applications.

According to some embodiments, some BC applications may represent ICIs locally in certain formats that are not similar to formats used in other BC applications, and the BCMOS may use a unifying comprehensive ICI representation format for supporting the conversion of ICIs from one format to another.

Reference is now made to Fig.4, which schematically illustrates an encrypted ICI sharing scheme 400, according to some embodiments. According to some embodiments, scheme 400 depicts transferring ICI(s) from a first application, such as APP-A 410, to a second application, such as APP-B 420, via BC-Middleware operating system (BCMOS) comprising a first interface 460 associated with APP-A 410 and a second interface 462 associated with APP-B 420, and configured to facilitate and enable the ICI transfer between APP-A 410 and APP-B 420.

According to some embodiments, APP-A 410 and APP-B 420 are operated on different mobile operating systems, and maybe different manufacturers for example APP-A 410 is operated on an Android operating system and APP-B 420 is operates on an iOS operating system or Samsung and HTC

Reference is now made to Fig.5, which schematically illustrates the conversion 500 of ICI data format/structure from a first format 512 to a second format 522, according to some embodiments. According to some embodiments, first format 512 may be used by a free BC application, and provides a simple ICI interface with minimal information fields such as Image, Prefix, Family Name, Company, Phone number, email address, company name and title. While second format 522 may be used by a more sophisticated corporate or business premium BC application and includes a rich set of information fields that may include a first name, middle name and family name in two languages, a phone number, address, card design, company, email address, and role.

According to some embodiments, if an application using first format 512 needs to send an ICI to another application using second format 522, the BCMOS may convert the ICI from first format 512 to a common format 564, which may include a comprehensive amount and types of information fields to be compatible with various formats used by different BC applications. According to some embodiments, the information fields of first format 512 are mapped to at least some of the information fields of common format 564. Then, the ICI is sent to the second device/application and the BCMOS at the second application may convert the ICI from common format 564 to second format 522.

According to some embodiments, the formats may vary in many properties, such as the data structure, wrappers, meta-data, richness of data, graphic support, encryption/encoding, language and others.

According to some embodiments a common format may include fields such as images, videos, phone numbers, email addresses, prefixes, names, titles, roles, company names, company logos, addresses, card front and back designs, notable dates and so on. According to some embodiments, the BCMOS may enable a BC application to share an ICI with a plurality of other applications on other devices. According to some embodiments, the BCMOS may enable sharing an ICI with other applications on other devices using more than one communication channel, such as NFC or Bluetooth with one device and Wi-Fi with another in parallel or serially.

Reference is now made to Fig.6, which schematically illustrates a setting 600 of ICI sharing from a first device 610, to a second device 620, a third device 630, and fourth device 640, according to some embodiments (it is noted that the abovementioned embodiment is exemplary, and other forms may apply, for example the sharing may be done between 5, 10 or even more device, and it may be limited by the channel protocols). According to some embodiments, first device 610, second device 620, third device 630, and fourth device 640 may operate/run four BC applications, such as BC APP A 612, BC APP B 622, BC APP C 632, and BC APP D 642 respectively. According to some embodiments, a BCMOS is associated with each of the application and they enable the transfer of ICI (650, 652 and 654) between BC APP A 612 and the other BC APPS (622, 623, 624).

According to some embodiments, the BCMOS on one device is configured to establish a reliable communication link with BCMOS on other devices. According to some embodiments, the communication link between first device 610, second device 620, third device 630, and fourth device 640, may include multiple channels, for example, the communication link between first device 610 and second device 620 may be over one communication channel, such as NFC, or Bluetooth, while the communication between first device 610 and third device 630 may be over other communication channels such as a Wi-Fi channel, and the communication link between first device 610 and fourth device 640 may be over a cellular channel. According to some embodiments, the ICI transfer/sharing is encrypted by the sending BCMOS, and decrypted by the receiving BCMOS.

Reference is now made to Fig.7, which schematically illustrates a method 600 for ICI sharing between two devices, namely device A and device B, according to some embodiments. According to some embodiments, device A operated application A with BCMOS A, while device B operated application B with BCMOS B. According to some embodiments, method 700 begins with application A sending a request to discover neighboring devices (step 702), then BCMOS A initiates a discovery process (step 704) on one or more of the available communication channels, then device B is discovered (step 706), According to some embodiments, the detection and/or transfer of ICI is manually controlled by a user, such that when detection completed middleware B may send a "ready-message" to indicate that the devices are paired and may also indicate the name/identifier of the device then a user of APP A may trigger a "BC send" for sending the ICI (step 708). If the request is granted, middleware A converts the ICI from a format compatible with device A to a common format (step 710) and the ICI/BC may be encrypted (step 712) and sent to device B over a selected communication channel (step 714). When middleware B receives the ICI/BC (step 716) it decrypts it (step 718) and converts it from the common format to an ICIBC format compatible with application B (step 720) and then application B stores the ICI/BC (step 722). According to some embodiments, an ICI transfer may involve the following steps:

• Converting ICI to converted to the common format

• Encrypting ICI than encrypted

• Handheld/device name is converted to the first name of the owner According to some embodiments, the abovementioned steps may take place only upon a change in ICI data or upon a first ICI transfer, and the encrypted ICI may be saves for future ICI sharing.

According to some embodiments, the BCMOS may encode the ICI/BC with an error detection or error correction code, to enable detecting errors that may occur in the communication link between the devices. According to some embodiments, the encoding may include: repetition codes, parity bit(s), checksum, cyclic redundancy check (CRC), cryptographic hash function, error-correcting code (ECC); or any combination thereof. Reference is now made to Fig.8, which schematically illustrates a method 800 for secure ICI sharing between two devices, namely device A with BCMOS A and device B with BCMOS B, according to some embodiments. According to some embodiments, method 800 begins with BCMOS A encoding an ICI/BC with an error detection or error correction code (step 802), and BCMOS A selects a channel through which the encoded ICI is to be sent (step 804) then the ICI is sent via the selected channel (step 806). When BCMOS B receives the ICI (step 808) it may first check that a key is in place to validate that the BCMOS is running with a valid license (either license was not renewed is it should be i.e. was purchased or fraud) then runs an error detection and/or error correction procedure on the received ICI (step 810) for detecting errors that might have occurred during the transfer of the ICI. Then BCMOS B decides, according to the existence of errors and the recoverability therefrom (step 812), whether to send an acknowledgment of receipt to BCMOS A (step 814) or inform BCMOS A that the ICI was not received properly and BCMOS A may resend the ICI again through the same channel or alternatively, through another channel (step 814). According to some embodiments, one or more of these steps may be done either manually or automatically

Reference is now made to Fig.9a, which schematically illustrates a functional block diagram 900 of encrypted ICI sharing, according to some embodiments. According to some embodiments, a first user may have operated on an electronic device a first application that may be a personal BC application or a corporate application. In the case of a personal BC application, the application may have incorporated therein a business card middleware operating system (BCMOS) with a BCMOS license 970 for approving the use of a BC-APP software 972. According to some embodiments, BC- APP software 972 may be made available for download or operation through an application market such as an App-Store 974, for a first BC-APP 910 to be installed or operated on the electronic device. According to some embodiments, the BC application may be a corporate application, and a BCMOS license 980 may be utilized to enable the use of a corporate BC-APP 982 software, which may be associated with a corporate human resources tool such as Human Resources Software (HR SW) 986 for providing the first BC-APP 910 to be installed or operated on the electronic device via corporate application store 988. According to some embodiments, HR SW 986 may be further associated with a corporate business-card application management tool, such as BC-AP-Mgt-SW 984, for managing the ICI transfers and ICI content bases on corporate 's policy.

According to some embodiments, first BC-APP 910 is associated with, or integrally formed with the BCMOS, and the BCMOS is configured to receive the BC/ICI, encode it and encrypt it by a BC data keying and encryption mechanism 960, then establish a communication channel using an engagement mechanism 962 and send/transmit the data through a transmitting unit 964.

According to some embodiments, a second user may then receive the ICI/BC via a receiver 966 and then decrypt and decode the data using a key checking and decrypting mechanism 968. The ICI may then be sent to a second BC-APP 912 operated on the second device and then saved locally in a contact list 914.

Reference is now made to Fig.9b, which schematically illustrates a functional block diagram 901 of encrypted ICI sharing, according to some embodiments. According to some embodiments, functional block diagram 901 is essentially similar to functional block diagram 900 of Fig.9a, wherein first BC-APP 910 is configured to communicate with encryption mechanism 960 to provide an encoded and encrypted BC/ICI. The encoded and encrypted BC/ICI is then sent by first BC-APP 910 via a common communication link such as email 916 to be received by the second user by email 918 and then sent to a reception mechanism 966 and decrypted and decoded by key checking and decrypting mechanism 968. The ICI may then be sent to second BC- APP 912 and then saved locally in contact list 914.

Reference is now made to Fig.10, which schematically illustrates a method 1000 for secure ICI sharing between two devices, according to some embodiments. According to some embodiments method 1000 begins with a user selecting the BC application (step 1010), then a license is checked (step 1012) to assure that the user is using the application under the correct terms, and if the license is invalid, a license renewal notification is sent (step 1014). In case the license is valid, the BCMOS may then turn on the Bluetooth communication capabilities of the electronic device or any other communication mean as defined before (step 1060) and initiate a Bluetooth discovery process (step 1062), find a list of available devices using BCMOS (step 1066), and the list is provided to the user (step 1016) to select one or more devices for sharing the ICI with (step 1018), and then the BCMOS may transmit an encrypted ICI over to other users (step 1068).

According to some embodiments, a user on the other end may receive the encrypted ICI (step 1070) and check the key for validating the received ICI (step 1072). If the key is invalid, a message may be provided to the user to inform on the invalidity (step 1020), and if the key is found to be valid, the ICI may be decrypted (step 1074), and the ICI data may be validated (step 1076). According to some embodiments, if the ICI data is valid, the ICI is logged (step 1024), and if the ICI data is invalid, a message may be sent to the user (step 1022) to inform on the status, or a request may be sent to the first device for resending the message on the same channel (Bluetooth) or other channels, such as IR, Wi-Fi, email and the like.

According to some embodiments, the encryption/decryption method used in the BCMOS may include a symmetric-key encryption scheme and/or a public key encryption scheme. According to some embodiments, the encryption/decryption method utilizes one or more of the following algorithms: AES (Rijndael), DES, 3DES, RC2, RC4, RC5, RC6, Blowfish, Twofish, Diffie-Hellman, SEAL, DSA, and RSA.

As used herein, the terms "electronic device", "mobile electronic device and "mobile device" are interchangeable, and may refer to electronic/computerized devices with communication capabilities, processing circuitry and a non-tangible memory. The device may support wired and/or wireless communication channels. The device may be wearable or handheld, the device may be mobile, and the device may be one or more of: a cellphone, a wearable device such as a smartwatch, smart wrist-band, smart glass and the like, a personal computer, a laptop, a PDA, a tablet or the like. The invention is preferably implemented by software, but can also be implemented in hardware or a combination of hardware and software. The invention can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data which can thereafter be read by a computer system. Examples of the computer readable medium include read-only memory, random-access memory, CD-ROMs, DVDs, magnetic tape, optical data storage devices, and carrier waves. The computer readable medium can also be distributed over network-coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

The many features and advantages of the present invention are apparent from the written description and, thus, it is intended by the appended claims to cover all such features and advantages of the invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, the invention should not be limited to the exact construction and operation as illustrated and described. Hence, all suitable modifications and equivalents may be resorted to as falling within the scope of the invention. While this invention has been described in terms of a preferred embodiment, there are alterations, permutations, and equivalents that fall within the scope of this invention. It should also be noted that there are many alternative ways of implementing both the process and apparatus of the present invention. It is therefore intended that the invention be interpreted as including all such alterations, permutations, and equivalents as fall within the true spirit and scope of the present invention

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, or components, but do not preclude or rule out the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof. While a number of exemplary aspects and embodiments have been discussed above, those of skill in the art will recognize certain modifications, additions and sub- combinations thereof. It is therefore intended that the following appended claims and claims hereafter introduced be interpreted to include all such modifications, additions and sub-combinations as are within their true spirit and scope.

Claims

1. A system for individual contact information (ICI) sharing between at least a first electronic device having a first business card (BC) application and a second electronic device having a second BC application, the system comprising: a first middleware, associated with the first BC application; a second middleware, associated with the second BC application; wherein said first middleware is configured to: receive a command from the first BC application to send an ICI in a first format from the first BC application on the first electronic device to the second BC application on the second device, the first format being compatible with the first BC application; establish a communication channel with said second middleware of the second electronic device; convert the ICI from the first format to a common format; and send the ICI in the common format to said second middleware via the established communication channel, and said second middleware is configured to: obtain from said first middleware an ICI in the common format; convert the ICI from the common format to a second format, the second format being compatible with the second BC application; and provide the ICI in the second format to the second BC application.

2. The system of claim 1, wherein the communication channel comprises email, short message service (SMS), Bluetooth, cellular communication, near field communication (NFC), Infra-Red (IR), quick response code and imaging (QR code), or any combination thereof.

The system of claim 1, wherein the communication channel comprises communication through a cellular network.

The system of claim 1, wherein the first format and the second format are similar ICI formats.

The system of claim 1, wherein the first BC application and the second BC application are similar BC applications.

The system of claim 1, wherein the first format and the second format are not similar, and they vary in one or more of the following features: a level of details in the ICI; number of fields in the ICI; language of information in the ICI; and representation format of information in the ICI.

The system of claim 1, wherein said first middleware is configured to encrypt the ICI in the common format before sending, and said second middleware is configured to decrypt the received ICI before converting the ICI to the second format.

The system of claim 1, wherein said first middleware is configured to encode the ICI using an error-detection code before sending, and said second middleware is configured to decode the obtained ICI and check for errors before converting the ICI to the second format.

The system of claim 7, wherein the error detection code comprises repetition codes; parity bit(s); checksum; cyclic redundancy check (CRC); cryptographic hash function; error-correcting code (ECC); or any combination thereof.

The system of claim 7, wherein said second middleware is configured to send an acknowledge message to said first middleware to confirm receiving an ICI.

A method for individual contact information (ICI) sharing between at least a first electronic device having a first business card (BC) application associated with a first BC middleware, and a second electronic device having a second BC application associated with a second BC middleware, the method comprising: providing a command, from the first BC application to the first BC middleware, to send an ICI in a first format from the first BC application the second BC application, the first format being compatible with the first BC application; establish a communication channel between the first BC middleware and the second BC middleware; convert the ICI from the first format to a common format; and send the ICI in the common format from the first BC middleware to the second BC middleware via the established communication channel, and convert the ICI from the common format to a second format in the second BC middleware, the second format being compatible with the second BC application; and provide the ICI in the second format from the second BC middleware to the second BC application.

The method of claim 11 , wherein converting the ICI from the first format to the common format comprises encoding the ICI in the first format using an encoding method, and converting the ICI from the common format to the second format comprises decoding the ICI in the common format using a decoding method.

The method of claim 12, wherein the encoding method comprises utilizing error correction code selected from: repetition codes; parity bit(s); checksum; cyclic redundancy check (CRC); cryptographic hash function; error-correcting code (ECC); or any combination thereof.

The method of claim 11 , wherein converting the ICI from the first format to the common format comprises encrypting the ICI in the first format using an encryption method, and converting the ICI from the common format to the second format comprises decrypting the ICI in the common format using a decryption method.

The method of claim 14, wherein the encryption method comprises an encryption algorithm selected from: 3DES, RC2, RC4, RC5, RC6, Blowfish, Twofish, Diffie-Hellman, SEAL, DSA, RSA or any combination thereof.

The method of claim 11, further comprising a confirmation message from the second BC middleware to the first BC middleware if the ICI was received.

A sender middleware for individual contact information (ICI) sharing between at least a first electronic device having a first business card (BC) application associated with the sender BC middleware, and a second electronic device having a second BC application associated with a receiver BC middleware, the sender middleware is configured to: receive a command from the first BC application to send an ICI in a first format from the first BC application on the first electronic device to the second BC application on the second device, the first format being compatible with the first BC application; establish a communication channel with said second middleware of the second electronic device; convert the ICI from the first format to a common format; and send the ICI in the common format to said second middleware established communication channel.

A receiver middleware for individual contact information (ICI) sharing between at least a first electronic device having a first business card (BC) application associated with a sender BC middleware, and a second electronic device having a second BC application associated with the receiver BC middleware, the receiver middleware is configured to: obtain from the sender middleware an ICI in the common format; convert the ICI from the common format to a second format, the second format being compatible with the second BC application; and provide the ICI in the second format to the second BC application.

An operating system, including a middleware as claimed in claims 17 and 18.

A data carrier, carrying a middleware as claimed in claims 17 and 18.

A computer program product, configured to operate a middleware as claimed i claims 17 and 18.

22. A data stream, which is representative of an ICI as claimed in claims 1 to 1 i

A data structure product, which is representative of an ICI as claimed in claims 1 to 18. A processing system, comprising means for carrying out ICI sharing methods as claimed in claims 11 to 16.